I’ve slowly switched to Git from Subversion over the last year or so, and lately I have begun to feel dissatisfied with my repository configuration. In this post, I’ll outline how to set up Git in a central repository model, exporting repositories over HTTP(S) and allowing for fine-grained access control.
One of the projects I worked on last year was the iOS SDK for Yahoo! Connected TV. Along with the SDK, Yahoo! wanted to ship an example app that demonstrated use of the SDK. Take a look at the screenshot to the right. See anything a little out of the ordinary?
Several of the buttons, especially the colored ones along the bottom half of the directional pad, are not rectangular.
Just because your configuration file’s contents are written in a DSL does not mean you should pretend it’s not Ruby anymore.
I spend most of my development time split between Rails and iOS. Each offers a rich API that makes building projects much more productive and enjoyable. There is one place, however, that Ruby clobbers Objective-C: testing.
Now that Apple has released the complete set of WWDC 2011 videos to registered developers, those of us who couldn’t make it to the conference have the opportunity to hear about all the new, shiny stuff coming in Mac OS X 10.7 and iOS 5.
Of the handful of plug-ins I’ve written for Rails over the years, the one I install on new projects almost with thinking is sql_logging. I wrote that plug-in almost three years ago and it continues to work on Rails 2.3 apps today.
That isn’t true on Rails 3, though, so over the last few days I’ve taken the time to reevaluate the plug-in and figure out how to do the same work in Rails 3. The result is the new sql-logging gem. The source is hosted on GitHub and the gem itself is available, like any other, on rubygems.org.
If you’ve moved on to Rails 3 and RSpec 2, but have older projects that are still on Rails 2.3 and RSpec 1.3.x, you may notice that script/generate no longer shows the RSpec generators in them, even if you’ve frozen the correct version of rspec and rspec-rails into vendor/gems.
I’m not sure of the proper place to report this bug, but a quickie workaround is to uninstall the newer rspec-rails gem so that 1.3.x is the newest in gem list.
Following up on my post about automatic Subversion revision stamping, here is a modified script for use with Git-based projects.
Following up on my previous post about adapting pre-Bundler workflows to current best practices, Yehuda Katz posted his suggestions on how to approach Bundler in terms of what you used to do. It’s a good read.
One thing that caught me up was the deployment suggestion to require 'bundler/capistrano' in deploy.rb. If you installed Rails 3.0 soon after it was released, you may still have one of the Bundler 1.0 release candidates. I had RC3, and it didn’t include the Capistrano file, which led to a load error. Update your gem, and all will be well.
PostgreSQL is my database of choice. The main reason is that a standard distribution comes with just about everything one could ask for in a free RDBMS, and if what you want isn’t already installed, it’s often in the “contrib” directory. In particular, now that I’m doing a lot of iOS development, and location awareness is a big part of mobile apps, it’s useful to be able to work with coordinates. PostgreSQL does this using the cube data type and earthdistance functions, both in “contrib”.