Capistrano* is a lightweight web application deployment tool suited to all codebases. It's written in ruby and hooks into the rake gem, but you don't need to be deploying a Rails app for it to come in useful. Ruby only needs to be installed on the box doing the deploying. Check out the other assumptions it makes. It's very practical and i highly recommend it for web shops with a cluster of web/db servers.
Having come out of the rails community, it sticks to some of the design principles of said project, including 'convention over configuration'. However, the creator's conventions aren't neccessarily your team's conventions - there was one core convention that didn't hold true in my deployment scenario: Capistrano deploys the latest revision of your repo and uses timestamps to identify the release on the participating servers. However, we use subversion and we deploy 'tags'.
Tags are named snapshots of your repository (more on tags). We typically use version numbers as tags, e.g. 'v1.2.2' or some such scheme. This allows us to say with certainty what is deployed at any one time, without having to scan logs etc. Tags give context to a release name (you can easily associate the release with project milestones) that revision numbers and timestamps do not. Tags are usually kept in a 'tags' subfolder, in the top level of the repository.
I've produced a small task library which allows you to deploy and rollback subversion tags with this kind of syntax:
rake remote:deploy_tag [tagname]
- Your 'releases' folder will hold your releases by tag name, not timestamp.
- The library adds a capistrano variable, 'svn_tag_dir' which defaults to 'tags', to describe your tag subdirectory.
- You can customize the deploy_tag script for your particular deploy scenario.
To install just place the task library in 'lib/tasks' in your particular rails app, and add the following to your 'config/deploy.rb' script:
require 'tasks/capistrano_svn_tags'
You can then use the new deploy_tag task. Assumptions made:
- Your :repository variable will now have to point to the top level of your application's repository.
- Your tag names follow an enumerable convention like v1, v2, v3 (ie sortable by Array#sort)
If you want to use the default capistrano deployment convention again (last revision, timestamps) then just comment out the require statement and use the default deployment tasks.
Download the task library:
* Wins my award for Most Emo Sounding Dev Tool of All Time.
Much talk about RoR and will it go mainstream and blah.
I was recently asked by someone managing a RoR project why it was moving so slowly. When i inquired as to the skill-sets of the programmers involved the manager replied, "they used to be our dreamweaver guys".
OK, i thought, looking worried.
I suggested the quality of the programmers may be a factor. He looked at me puzzled, offended even. THESE GUYS ARE PERFECTLY FINE. THEY ARE WEB PROFESSIONALS. He said this with his eyes. Not with his mouth.
Matter of factly, i said, "You may need better programmers. Ruby is a powerful language."
It was like breaking bad news to a sick child. I felt really bad afterwards.
Right now i program in PHP5 with Zend 5 and the IDE, coupled with the vast array of third party libraries, cancels out the productivity boosts of Ruby the language (which is more powerful than php) and Rails the framework (which is more powerful than our homegrown php framework).
Third party libraries play an important role in all this. GEM is under-populated right now. Though gems seem to be consistently of a higher quality than a lot of the things you'll find on PEAR or CPAN, there's just not enough out there.
Will RoR become mainstream?
All i can say is:
Talent does not scale well.
A good ruby developer has demonstrably better OOP skills than a good php developer. The php developer may be better, you just have no way of knowing, because he hasn't access to as many OOP features. To run a successful RoR project you have to hire high quality ruby programmers, there's no middle ground. IMO a lot of web programmers will not migrate productively to python/ruby. Their heads will hurt and they won't program to the strengths of the language and their design will be off and it'll be PAIN PAIN PAIN for other developers on their team.
More here and here and here.
Java is the legacy code of the next generation of coders.
Lifted from comments hunted down after reading Ruby the Rival on Onjava.com.
Awards are questionable things, but this one was merited. A one man J2EE destruction kit.
Been working with Ruby On Rails on & off for about a fortnight. A few observations for those starting to pick up this framework,
1. Keep Dave Thomas' excellent text by your side at all times
Dave Thomas, co-author of the 'Pragmatic Programmer' series, is a worthy guide to Ruby. This text is excellent - Programming Ruby: The Pragmatic Programmer's Guide. Also keep Matz's original Ruby manual to hand. It's fun.
2. Use Rake
Rake is a ruby makefile-style utility. It's useful. Try rake --tasks to check the available tasks. You can define your own rake tasks in the Rakefile sitting in your application's root directory. You can define dependencies between tasks and files. It's useful for deployment, sql dumps, code stats, documentation generation etc. In addition to the built-in tasks, you can find :deploy and :rollback tasks out there if you root around, allowing you to version your application formally.
3. Use Gem
Gem is the CPAN for Ruby - it fetches 'gems' - ruby modules/extensions. You'll need to use it to get your database adapter and other utilities.
4. Use Rdoc
Rdoc creates documentation from Ruby classes and spits it out in HTML format. I have a bookmark group in my web browser made up of Ruby and Rails standard libraries. Cmd-click in Safari makes all the tabs load in one go. I'm sure Firefox has an equivalent.
Note: All three of these command line utilities (rake/gem/rdoc) are for Ruby in general, and exist independently from Rails. However, they will come with your Rails install.
5. Use the logs
Use the logs in the ./log directory. I always keep a unix screen open with
tail -f ./log/development.log
running in it. This is the best way to get a feel for how ActiveRecord behaves in terms of database calls. To write to the log, use
logger.info("message here")
in your code.
6. Use Rexml for XML parsing
Most projects have some XML parsing going on - REXML is the most complete XML parser for ruby. You'll need to install it - it's not stdlib. Google it.
7. Take the time
RoR is encouraging a whole load of web developers to enter application development. This can be a good thing. However, it's a different ball game, so to speak. For starters, understanding the Model View Controller (MVC) design pattern is crucial to RoR. It's pretty simple, but you need to be able to apply it smartly in order to keep things neat as your application progresses. Understanding the role of testing and code versioning is also really important. Take the time to learn common application development and design techniques/patterns if you're coming from a web background. Your test code should usually outnumber your production code.
8. Get the Ruby syntax highlighting module for BBEDIT
When developing locally i like to use the BBEDIT text editor, because the cli editors start hurting my eyes. You can set up a project using New > File Group. The ruby syntax highlighter is here.
9. Check the irc channel
#rubyonrails at irc.freenode.net - nice people on the whole.
10. Using Webrick/Apache
First off, use the Webrick server while testing. More here. That's another unix screen i have running continually. If you want to test under Apache, turning on fast-cgi is explained here.
Finally
Feel confident. Rails is an enterprise level framework taking it's first steps - don't let the J2EE crew drown you out. Ruby > Java in spirit and in tone, even if Ruby's gem pool still has a long way to go to match the colossal Java API or Perl's extensive CPAN libraries. In terms of RoR: The framework is there. It will grow by virtue of the agility it encourages.
I'm still yet to find any particularly great apps in Rails since the 37Signals ones, but here's a simple code snippets library produced in RoR - Snippets. Keep an eye on the OS X and Ruby sections as they grow. I like the simplicity of this tool.
That little girl is Ruby. She is hacking a PHP corpse to pieces. She is on Rails. It does that to you.
Today i woke to the tune of nausea. It didn't subside for about an hour. I think it's lack of sleep.
Just a couple of days with Ruby on Rails (meme of the month) and i must say: wow.
Unlike most coders i'm an aesthete. I believe strongly in an 'art' of programming. This came down from my father, who in the early eighties used a multi-national's resources to stage a Fractals exhibition. That was in S.America and Fractals were (and possibly remain) the big daddies of computer art. My dad believes in spiritual programming. I'm not sure what this means yet. Then again i am young, dumb and full of CRUD.
Which brings me onto Ruby. And Rails. This framework has style. It feels great. I can't remember the last time i looked at code and thought that. Ruby's syntax is a breath of fresh air in a world of Java tangles and Perl obscurity. And it's powerful. It's not a designer-wants-to-make-a-website kind of tool. It has real depth. Downside: The Ruby libraries look a bit thin. And no webhost is running it.
It was a close call between going with this or Perl's Maypole (a similar MVC framework). But for now, I'm sold. More info on my project soon.
