Scratched my head for a tick when I noticed that Ruby’s Date::strftime doesn’t include a ordinal formatting option (eg. “January 1st, 2008”). To get the “st/nd/th/rd” in the formatted output, do this:
date.strftime("%B #{date.day.ordinalize}, %Y")
Hope this helps someone out there!
Just a quick note to say that RESTful_ACL has been updated. This latest version supports securing non-CRUD actions. It’s a slight cop out of sorts; essentially if the user in question can read an object, they will also be able to do the non-CRUD action. It’s not the best solution to the problem, but it will work for the moment. Maybe there is a slick way to pass in a function name as a hash/block thing that I’m not sure of. Hrm.
Just a quick update to let you know that RESTful_Acl has been updated. I removed the mapped urls option in favor of manually opting out of the ACL check on actions that are to be public. The full write-up can be found at the usual location. Just a heads up!
I’d like to announce my very first Ruby on Rails plugin; RESTful_Acl.RESTful_Acl is a simple Access Control Layer for Ruby on Rails, it allows you to restrict access on a fine-grained level to any RESTful MVC stack. While the ACL structure and engine are provided by this plugin, the implementation is fully up to the user. Every application is different and everyone likes to setup their User / Account / Role resources differently; this plugin will allow you to do your thing and keep that thing locked down.The full write up is available here!
So it seems that my MacBook (2Ghz Core2 Duo, 2G RAM) runs 4707 Rspec tests in 67.5 seconds. My CentOS server (4200+ Core2 Duo, 2GB RAM) runs the same tests in 91.7 seconds. Both are running the latest version of MySQL. How odd is that?
89 database tables, 93 fully RESTed objects, 4740 successful tests. Life is grand.I’ve spent years working in web development with PHP (as I’ve describe ad naseum), and I’d hate to admit it, but I’ve never written a test. Ever. My stuff works, but soon after every launch, small cracks start to appear. The worst part is that these small cracks are always found by my users. This is not only embarrassing, but it leads to me furiously debugging a live system with active users, trying to quickly recreate the conditions that caused the error. I like my hair and I’ve losing it fast enough, thank you.Enter RSpec and Behavior Driven Development (BDD). RSpec makes writing tests a joy. Yes, I know, I know, but testing can be a real joy. It’s like working out; it always seems super difficult to start, and you stall and think of a billion other things to do, but once you actually start you feel really good and alive.BDD makes testing second nature, and RSpec makes writing these tests intuative. You know those meetings you have with your clients and you try to distill what they truly need from what they tell you they need? BDD gives you a language that both you and your clients can speak; you simply describe how an object should behave:A Car not only has a color, it also should not be driveable with one tire and it should only be driveable by a licensed driver.
describe "A Car" dobefore(:each) do@car = mock_model(Car)@driver = mock_model(Driver)endit "should have a color" do@car.color = nil@car.should_not be_validendit "should not be driveable with one tire" do@car.tires = 1@car.is_driveable?.should_not be_trueendit "should be driveable with four tires" do@car.tires = 4@car.is_driveable?.should be_trueendit "should not be driveable by an unlicensed driver" do@driver.stub!(:license_active?).and_return(false)@car.stub!(:driver).and_return(@driver)@car.is_driveable?.should be_falseendit "should be driveable by a licensed driver" do@driver.stub!(:license_active?).and_return(true)@car.stub!(:driver).and_return(@driver)@car.is_driveable?.should be_trueendendSee? Simple. As with most Ruby code, RSpec features English like statements that are immediately comprehensible to anyone—even clients. You know what the best thing is about RSpec though? It not only tests your code, it documents your code. Just look:
A Carshould have a colorshould not be driveable with one tireshould be driveable with four tiresshould not be driveable by an unlicensed drivershould be driveable by a licensed driverImagine testing and documenting your code at the same time! Two things that many programmers skip altogether! That alone makes the Ruby on Rails framework and mindset the most attractive choice today.
One thing that annoys me when using the RSpec bundle for TextMate is the ‘it’ snippet. I think that any new spec should at least register as ‘Pending’ when it is run, not automatically pass. Having a blank test pass is really kind of dumb. So I’ve tweaked the ‘it’ snippet just a hair to automatically insert a ‘Pending’ statement into a newly created ‘it…do’ block. The description will be highlighted first, then the entire ‘pending’ statement so it will be easy to enter your data.
To use this snippet, just do CTRL + Command + Option + B in TextMate, go to the RSpec listing, and click on the ‘it’ snippet. Copy and paste the below text and you’re in business.
it "${0:should ${1:description}}" ${3:do
${2:pending("Needs to be written")}
end}
After a month of searching, I finally found a method to install Ruby MySQL bindings on Leopard!
$ ARCHFLAGS="-arch i386"<br/>$ ruby extconf.rb --with-mysql-dir=/usr/local/mysql<br/>$ make<br/>$ sudo make installTaken from: Macosforge.org
Now that grad school is over with, I’ve already felt the need to find a new challenge to tackle. As you might guess, I get bored very quickly. I’ve chosen to learn Ruby and Rails. I’ve attempted to tackle this challenge in the past but I’ve always ended up frustrated enough to quit. To celebrate the release of Rails 2.0, I figured I would try once again.
I’ve been working with Ruby and Rails 2.0 for the last two days, and I am already a convert. I’ve ported the existing development of my company’s Intranet application from PHP / CakePHP to Ruby / Rails in less than one day. That one day was the first day I worked with RoR, if that tells you anything.
There is currently a holy war surrounding PHP / CakePHP and Ruby on Rails. Having used PHP for eight years and CakePHP for one year I was basically in a mental bind. PHP is great and definitely does the job at hand, but at times it shows its hacked-together nature. One of the main differences between PHP and Ruby is that Ruby is truly an object oriented programming language while PHP is a scripting language. What does this mean? Basically, Ruby handles dealing with logical code elements in a much more refined, repeatable, and logical way.
For example, in CakePHP, an Object (say ‘User’) only lasts as long as it takes for the framework to conjure it from the database. From then on, you’re dealing with an elaborate array of specific information:
// Load User from the database
$user = $this->User->findById(121);// Set User's last login time
$user['User']['last_login'] = date('Y-m-d g:i:s');// Save User back to the database
$this->User->save($user);
Which language looks more friendly and logical to you? Exactly.
- Load User from the database
user = User.find 121- Set User's last login time user.last_login = Time.now
- Save User back to the database user.save
CakePHP is a godsend to the PHP community, and anyone stuck on/with PHP should be using it for every single project they work on. It’s a miracle. That being said, it is a poor clone of Rails in many ways.
Most of CakePHP’s shortcomings are due to PHP itself. PHP is not object oriented, so the CakePHP developers are coding with their hands tied from the start. Another major detraction from the framework is the severe lack of documentation. CakePHP 1.1 (the recommended stable version) does have a fair amount of documentation and an API available, but the latest and greatest version 1.2 does not have any official ‘manual’.
To be fair, most of 1.1’s documentation can be extrapolated to 1.2; however the features that make 1.2 desirable are scarcely documented. Developers close to the project post blogs that are helpful but this is far from a ideal situation. And yes, I do understand that 1.2 is in heavy development. This point is also won by RoR for its wonderful built-in documentation system that makes generating documentation effortless.
RoR is more mature feeling with a robust set of tools and documentation. Ruby itself is amazingly powerful and has a huge plugin library available. Rails has built-in support for the Prototype and script.aculo.us libraries so designing towards ‘Web 2.0’ standards is a cinch. After failing many times to do anything meaningful with Ajax in CakePHP I have already created a CRUD UI for an important Object in my Intranet application. Keep in mind, again, that I started with RoR yesterday and more specifically with Ajax this morning.
There are many more points in which RoR beats Cake/PHP; a few that spring to my mind:
1. Unit testing is built-in (no external libraries are needed)
2. Creating a new application is as easy as running ‘rails project_name’
3. Built-in web server
4. Much more robust debugging and query tracing (great for finding bottlenecks!)
5. Plugin installation is a breeze
The bottom line? If you’re stuck with PHP for you projects, use CakePHP. It’s a miracle for PHP. If you are not stuck with PHP, give Ruby on Rails a whirl. It makes coding fun again and you’ll be amazed on how quickly you’ll pick it up. I’ll be using it for all of my upcoming projects.
I think I’m in love. I will remember 2007 as the year that I dumped Windows and PHP and set myself free. I tend to ignore fanboys, but switching to Mac and Ruby on Rails has made my job exponentially easier and my day much brighter. I’m blissed out.
Slash by Slash