If you’re using the MacPorts version of OpenSSL, and have a Ruby installed either by MacPorts or RVM, you’ve probably clashed with the dreaded “SSLv3 read server certificate B: certificate verify failed” message
(Or you’ve forced the verification check off, which is not a good idea )
Quick fix:
port install curl curl-ca-bundle
ln -s /opt/local/share/curl/curl-ca-bundle.crt /opt/local/etc/openssl/cert.pem
(using sudo as needed)
(Originally posted on tumblr)
Now that we have both RVM and Bundler, you’re following the advice in this article and keeping all your gems in source control, right?
No? Why not? “I have a custom fork that I don’t want to put on a public server”? Pfshaw!
1. Put a ‘:git’ option in your Gemfile pointing to your local repo:
gem ‘my_custom_gem’, ’1.0.0′, :git=>’file://path/to/your/repo’
2. Follow the steps in the article:
bundle install –path vendor’
bundler package
Make sure the gem file for your custom gem is in vendor/cache.
3. Remove the :git flag in your Gemfile
gem ‘my_custom_gem’, ’1.0.0′
4. Run
bundle install –path vendor
again to remove the git references from Gemfile.lock.
5. Check in vendor/cache/*, Gemfile, Gemfile.lock, and .bundle/config to source control.
There now, that wasn’t so hard. And now you don’t have to worry about losing the original git repo, or reinstalling the custom gem on every deploy.
Recently at work, I needed to parse ugly data files from an ancient classified-ads database that a predecessor devoted an entire Ruby application to. While painstakingly building regexes, I remembered looking at Treetop a few months ago.
Treetop is a Ruby library for writing Parsing expression grammars. PEGs are another way of constructing grammars and could be thought of as super-regexes: they don’t allow left-lookup or ambiguity in the parse tree, making them not so useful for natural language but killer for computer languages. Around 40 lines of code and 7 rules took the place of what the original author devoted dedicated tempfiles and regex arrow code to.
That being said, PEGs are conceptually harder to get grips on, and Treetop’s documentation is not entirely clear on some hangups you might find. Most of which you can solve using the excellent mailing list, but I know I wished during the past few days that I could get it summed up for me.
Continue reading…
Everybody’s talking about it. Couple of days in jail, whole town changes, etc.
There are two camps over this currently: the Rails side(“Whoo! Chocolate in my peanut-butter! Less magic and plugins that don’t explode randomly between versions!”), and the Merb side(“DHH is going to defenestrate us all! They won’t taste great! These books from the tech section are out-of-date six months earlier than usual!”
I’m mostly in the Rails camp(due to work), with a little of the Merb camp. It would be nice to keep them existing as separate frameworks, if only because of the other elephant in the room: the Rails-branding(read: money) and need to provide splashdown points for decamping Java webapp programmers. However, the Merb team seems to think this won’t be an issue, so I’ll reserve judgment for when the behemoth finally appears.
In any case, the fact that DHH and the Rails team are willing to adopt formal APIs, clearly define module boundaries, and leave monkey-patching behind is a welcome sign.
In Rails, one form helper(well, besides a broken date_select) stands alone as cruel, sadistic, and impossible-to-please with just a simple hash. That form helper’s name: option_groups_from_collection_for_select.
It’s so painful that most people would re-implement it, rather than fall victim to its NoMethodError wails. But that’s not the path for us. When you’re using something like Base Without Table to clean up your email contact forms, you don’t have time to mess around with o_g_f_c_f_s’ hunger for has_many. That’s when you pull out OpenStruct, and cleave the beast in twain.
Continue reading…
Echo-chamber-driven Internet Drama on the rise in the Ruby community. Again.
Giles Bowkett:
original, followup, self-flagellation
_why’s sum-up and thoughts.
Zed’s response to _why’s mention.
_why fires back.
Can we skip this and go straight to the Yo Momma Fight? Loser gets Force-chucked into experts-exchange.com!
Builder is a neat piece of kit but, like most sane libraries, wasn’t designed around the brain-damage that is Business-dialect XML(chock full of custom namespaces and tags devoted solely to attributes).
Builder’s docs seem to imply that a namespaced tag always needs to be in block form:
xml.bqcm :UselessMetadata {|n| n<< "flue"}
or
xml.bqcm :UselessMetadata do xml.text!("flue") end
But you'll end up with wonky indenting because Builder is sensibly expecting that you should take care of the whitespace yourself when using this form:
<bqcm:UselessMetadata>
flue
</bqcm:UselessMetadata>
The clean way to do it is giving the symbol as the first argument:
xml.bqcm(:UselessMetadata, "flue")
which provides:
<bqcm:UselessMetadata>flue</bqcm:UselessMetadata>
EDIT(2:18pm)
"But what if I have attributes AND a simple text value?"
Just make sure the attributes are sent in an explicit hash as the second parameter:
xml.bqcm(:UselessMetadata, {:QuestionableAttribute=>"chimney"}, "flue")
"I still want to send my text like I was doing, and I want proper indenting NOW NOW NOW"
Fair enough:
xml.bqcm :UselessMetadata do
xml.__send__ :_indent
xml.text!("flue")
xml.__send__ :_newline
end
Last time, I was complaining about rSpec refusing to play nice with the TextMate plugin. I owe the team an apology(in the unlikelihood event of them actually reading the entry), as getting it working is a bit confusing.
On my systems, the TM plugin would insist that I had an ancient rails/rubygems version, and to try upgrading. After a long headscratch, I deduced that it was probably seeing the ancient Apple-installed gems even though I have shiny MacPorts-installed gems. For some reason, the TM plugin will ignore your .bash config files and even any TM_RUBY variables you try to set in the project. Instead, you’ll need to add a PATH variable to your underlying MacOSX environment file(~/.MacOSX/environment.plist).
Take your PATH from your bash profile(specifying your preferred location for rSpec/ruby/macports/etc.) and place it into a key just like the other variables in the file. Mine ended up looking like:
<key>PATH</key>
<string>/opt/local/bin:/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bi
n:/usr/sbin</string>
Save the file, then logout/reboot. The TM plugin should now be working.
After getting it working, I can say it’s been a resounding success in my testing. All of the new features for Depot Central have been thoroughly spec’d out, and even though this release will open the floodgates for public posting, it’s been the least problematic so far.
god is my newest favorite tool for server and Rails monitoring, not to mention the entertaining conversations it can produce(“God was spanking the mongrels repeatedly, without letting them fully start”, “god spammed my mailbox with over 700 emails this weekend”, “I’m killing god right now, it should be back in a minute”). One of the last pieces I forgot to include in this setup was Sphinx and, in an apt demonstration of Murphy’s law, it decided to silently die this weekend while I was out of town. So the first thing I did today was to let god manage it as well.
One hurdle people might run into is whether to let god auto-daemonize the process(a useful feature indeed), but our hand is forced by Sphinx already daemonizing itself along with its own PID file(trying to let both god and a process daemonize itself is pretty much crossing the streams). Fortunately, sphinx provides its own “stop” command so we don’t have to go crazy trying to lookup a PID in our god config:
w.start = "searchd -c #{RAILS_ROOT}/config/#{RAILS_ENV}.sphinx.conf"
w.stop = "searchd -c #{RAILS_ROOT}/config/#{RAILS_ENV}.sphinx.conf --stop"
w.pid_file = File.join(RAILS_ROOT, "log/searchd.#{RAILS_ENV}.pid")
Easy peasy. I absolutely adore god’s ability to plug into the event system on OSX, so between god and launchd, I’ve almost got a bulletproof config[1].
[1] “bulletproof” for the value of “resists .22 rounds hand-thrown at it by a grade-schooler”, mind you.
So after wasting spending a few days checking out other test frameworks for Ruby/Rails, I’ve come up with this:
Rspec:
The Textmate plugin is barely useable; it appears to have a completely different manner of loading files versus the standard spec command(placing a spec file next to its target and doing a simple ‘require’ worked for the spec binary; the Textmate plugin waves its hands desperately). Wolf howls and tumbleweed are all that is received from asking about it on the #rspec IRC channel.
The bundle works OK under Rails,but of course now the simple use of cache_fu is freaking it out when coming to fixtures(and not even guarding the acts_as_cached statement with ‘defined?’ works because rSpec hooks into Kernel and does all kind of crazy voodoo).
This post gushes about “rspec leaving TDD in the dust”, I’ll believe it when some more consistency is gained.
rspec’ers are going to accuse me of being another idiot user who can’t set up their system correctly. I’ve setup Mysql multiple times(binary release, DarwinPorts, Macports, version) and made countless other mistakes(and fixed them) on my G4 laptop since 2004; I have a hard time thinking that some obvious mistake I’ve made is gumming up the works.
Shoulda would be a nice alternative(plugs into existing test/unit, but it depends heavily on autotest, and autotest still petulantly refuses to believe in namespaced Rails controllers, despite the availability of a patch. I may try updating the patch in the next day or two and giving it another go, but after two days and negative productivity gains, my gut feels like sticking with Test/Unit and friends, because They Just Work. And Just Working is rated higher in my book, no matter what sexy new features are in abundance(like mocking/stubbing)
