Merb blog begun: blerb 6
It’s nowhere near being ready yet, but I made my first contributions tonight. I was going to code up one myself, but a couple other caboosers already where planning on it, and since I am somewhat time constrained on personal projects, that was perfect.
Just getting started was quite a bit to bite off, though, as it involved learning git, datamapper, merb, rspec, and how the last three all play together (like how to use rspecs built-in mocking when trying to do controller specs in merb). I got it checked out and my first minor changes specc’ed and made, and pushed back upstream, though, so it should go easier from here out.
I will post more when there is something more to say (like maybe a repo to browse, or a website, or something that is usable as a blog)
Update: The other contributor to blerb so far is John Hornbeck.
Using define_method to overwrite a class' initialize as an example of overwriting a method from your mock, version 2 1
Last year, I wrote an article about redefining an instance method from a module via alias_method. I understand better how extend/include work together now (and the ClassMethods include patterns and whatnot) so I am little embarrassed at my earlier confusion, but there is one concrete thing I wanted to add/simplify.
If you are mocking and don’t need to keep a reference to the old method, using define_method might be marginally cleaner.
def self.included(associator_class)
associator_class.send(:define_method, :initialize, instance_method(:initialize))
end
ClassToBeIntercepted.send :define_method, :method_to_be_nuked, proc {return 'nuked'}
Leopard quicklook from the commandline 2
function ql()
{
qlmanage -p "$@" >& /dev/null
}
Be careful when you paste it to convert curly quotes back to straight quotes. >:|
Validating that at least one attribute in a list is present: validates_presence_of_any
module CustomValidations
def validates_presence_of_any(*attrs)
options = attrs.last.is_a?(Hash) ? attrs.pop.symbolize_keys : {}
attrs = attrs.flatten
send(validation_method(options[:on] || :save)) do |record|
return if options[:if] && !evaluate_condition(options[:if], record)
attr_list = attrs.map{|a| a.to_s.humanize}.to_sentence(:connector => "or", :skip_last_comma => true)
record.errors.add :base, "Either #{attr_list} needed." if attrs.all?{ |attr| record.send(attr).blank?}
end
end
end
validates_presence_of_any :first_attr, :second_attr, :third_attr
Thanks to bitsweat on #caboose for help with a succinct name that follows the convention.
Doing a rails custom validator with-out using validates_each
def self.validates_your_funky_non_validates_each_using_way(*attrs)
options = attrs.last.is_a?(Hash) ? attrs.pop.symbolize_keys : {}
attrs = attrs.flatten
# Declare the validation.
send(validation_method(options[:on] || :save)) do |record|
return if options[:if] && !evaluate_condition(options[:if], record)
#put real code using attrs and record here
record.errors.add :base, "monkey", if record.primate?
end
end
A graphical IE installer for OS X 2
Finally. I had been installing wine using MacPorts, just so I could run the ies4linux script. I ran into some problems with that on Leopard, namely that the wine port was broken for Leopard. But now Mike Kronenberg is maintaining current Darwine builds, and has made a graphical installer for ies4linux, on OS X. From the bottom of my heart, thank you Mike.
Wine on Leopard OS X 10.5 via MacPorts is broken 3
./crtdll.spec:44: external symbol 'CRTDLL__basemajor_dll' is not a function
rails javascript helper - capturing an additional level of block nesting within a content_for
When making a helper that takes a block, the yield causes it to output at the point of being called in the template. If the reason for the helper is to populate a content_for/yield variable, such as to put javascript in the head tag, you get duplicate output: once where it belongs when the content_for is yielded, and once where you call your helper. Instead, make use of capture(&block).
This helper
def javascript(&block)
content_for(:header) do
"<script type=\"text/javascript\">//<![CDATA[#{capture(&block)}//]]></script>"
end
end
<%javascript do%>
alert('hi')
<%end%>
<html>
<head>
<script type=\"text/javascript\">//<![CDATA[
alert('hi')
//]]></script>
bash command completion for rake
complete -C /Users/timconnor/scripts/rake-completion.rb -o default rake
If you use one of the ruby completion scripts (like Lee’s) make sure not to drop it in your bash_completion auto-added folder (/opt/local/etc/bash_completion.d/) as that will choke, expecting a bash script, instead of a ruby one.
Getting camping working with fcgi on a shared host (DreamHost), part 1
Since I’ve been splitting up an app into an rails admin section and a separate camping front-end, I need to get camping working on the host to deploy. And that host, for this app, happens to be DreamHost, which means it’s gotta be fcgi. I’m not all the way done with that, but after a late night last night, I managed to get it running on fcgi locally. I’ll skip over the basics (for one thing, if you haven’t gotten this far yet, you are going to need to struggle through it to be familiar enough with what is happening to have a chance of finishing the process) until I have it all worked out smoothly, but I have to post a couple highlights, to spare some people with the same pain.
First off, no luck running off of edge. The only way I got it working consistently with mongrel, cgi (crucial for debugging and figuring out why things aren’t working), and fcgi, was to use the gem release (1.5.180), and patch that (keep reading). Once I had that running smoothly with the built-in server and then cgi, I got it working with fcgi. If you have the same problem I did, you’ll get an ”`camp_do’: undefined local variable or method `exc’” error. THis is because there is another problem, which is throwing an error, but there is a bug in the exception handling code. Manually fix that (change e on to exc in the exception catching, so that it is defined), and then you can move on to the next issue, since your exceptions will now actually get through to the log, or the screen, depending on how far you’ve made it, and you can use them for more debugging.
If you have my problem, you can track down the next error to the path variable not being populated right in the fastcgi.rb
def camp_do(req)
root, path, dir, app = "/"
if ENV['FORCE_ROOT'] and ENV['FORCE_ROOT'].to_i == 1
path = req.env['SCRIPT_NAME']
else
root = req.env['SCRIPT_NAME']
path = req.env['PATH_INFO']
end
My fix was to set “ENV[“FORCE_ROOT”]=1.to_s” in my dispatch.fcgi, and then change the corresponding “path =” line to match what my set-up was populating -req.env[‘REQUEST_URI’]. I tracked this down by getting things running well enough to get the default error dump to the browser, and then checking over that.
Now I need to duplicate this without using global gems (since I can’t upgrade them on the shared host), and the do more debugging on the actual host.
Articles via rss or email