If youâre in need of a compelling reason to switch from Test-Driven Development to Behavior-Driven Development. consider this.
âBDD sounds kinkier.â -Michael K. Loukides, Book Editor for OâReilly
âŚon that bombshell⌠I am going to suggest that this be used as the official BDD logo.
There you have it. Deep down⌠the biggest reason that I switched from Test::Unit to RSpec. was the sex appeal. ;-)
What was your reason?
If youâre going to be coming to Portland, Oregon for RailsConf 2007, be sure to check out the new Urban Edibles website. Michael Bunsen gave a short demonstration of it at the Portland Ruby Brigade monthly meeting. If youâre looking for fig and pear trees within the city limits of Portland, this is the site for you!
If youâve spent much time on the Ruby on Rails wiki, you know that the spam situation smells like rotten fruit.
Weâve been using Instiki, the same software as the Rails wiki for the PLANET ARGON Documentation Project and the spam situation was becoming an annoyance. So, weâve switched to JunebugWiki as step one, to see how it holds up. The default styling was a nice improvement because we havenât had much chance to update the instiki one. It might not solve all of our spam problems, but in the short term, it appears to be a more elegant solution. Itâs also the first application built with camping that I have personally deployed.
So⌠I present to you⌠the new PLANET ARGON Documentation Project.
In other news, it appears that RubyURL has caught the eye of spammers, which sucks. Iâm still thinking over a few possible ways to try and prevent that. :-/
I was looking through some old code from over two years ago, when I
was playing with my first Rails applications. I noticed this hidden file
in the public/ directory, called .htaccess.
Do you remember the good âole days?
Trying to finish my book and running PLANET ARGON consumes quite a bit of my time⌠so when the RailsConf people announced that they were accepting proposals for talks, I opted to pass so that it wouldnât distract from my sprint to finish my book. :-)
This decision was even easier for me when Nathaniel Talbot invited me to be part of his proposal for a panel of people that are running companies that specialize with Ruby on Rails. I liked the idea and the other people that were invited were all people that I greatly admired and respected⌠so I said yes. After all, so much of my time and energy goes into this stuff and there isnât any doubt that I spend way more time on the business side of Rails⌠than in code these days.
I just got an email from Nathaniel to let me know that his proposal was accepted.
So, if youâll be at RailsConf 2007 (US), come see me on The Business of Rails panel session.
The following people are planned to be on the panel.
Moderator: Nathaniel Talbott, Terralien Inc.
Panelists include:
I hope that you all send Nathaniel some great (and tough) questions⌠;-)
Iâve been using pound for several months and itâs been a good relationship. Except, for some strange reason, I noticed that I was getting development mode errors when it was running in production mode. I thought there might be an issue with my mongrel cluster⌠but that wasnât the case.
Let me give you a little background to how weâre encouraging customers to handle their deployment on PLANET ARGON.
Most of our hosting customers[^1^](#fn1){#fnref1 .footnote-ref role=âdoc-noterefâ} have three tiers (unless you have your own static IP address), one which we manage, two that you manage.
We handle the main web server/proxy server and proxy to your desired load balancer/proxy/server, which is generally any of the following options⌠depending on your preference.
Each customer has a unique proxy server port and a range of other ports for their mongrel clusters.
So⌠the typical setup isâŚ
Apache(external:80) [proxies to]> Pound(localhost:8050) [proxies to]> Mongrel::Cluster(localhost:10500-10503)
Well, when a request comes in through Apache, it gets passed off to
Pound and each tier has itâs own headers. By the time that it reaches
Mongrel, all the requests appear to be coming from localhost.. not
the remote address of the person using your application. Notice nothing
but localhost requests in your production.log? âŚthis is the reason.
So, what side-effects does this have? Well, aside from every request
looking local⌠Rails will, by default, output a normal
development-mode error message if the request is coming from
localhost.
I was recently asked a few questions by Stacy Cowley, a writer for CRN about the Rails 1.2 release and how our Design and Development team at PLANET ARGON is adopting it. This Q&A session resulted in a brief article titled, Ruby on Rails Gets RESTFul in Major Update, which appeared on the CRN site last Friday afternoon.
Thanks to the Rails Core team and all of those in the community who continue to help make Ruby on Rails an awesome addition in my tool belt.
Yesterday, I announced the new Ruby on Rails Deployment group, which has attracted over 200 people and boasts over 50 messages in just the first 24 hours of itâs life.
While this is a greater turnout than I expected⌠I made a huge mistake yesterday. I forgot to invite the man behind the cutrain.
Our team is working on a new hosting solution[^1^](#fn1){#fnref1 .footnote-ref role=âdoc-noterefâ} for Rails applications. Throughout this process, weâve been reviewing all the various methods that our team and customers have been using to deploy and host applications written with Ruby on Rails. Our team has been able to closely watch the technologies change on our servers for almost two full years to accommodate the latest in deployment solutions.
Recently, a few deployment savvy customers of ours and us decided that it was time to take some of our experiences and conversations out into the public. Weâd like to invite all of you that are interested in Rails deployment to join the new Deploying Rails google group. Whether youâre trying to setup a staging server, deploy to a shared solution like we offer at PLANET ARGON, managing your own VPS, or configuring a cluster of servers for your big launch, weâd love to talk with you about this stuff.
Iâm secretly hoping that all the talented Rails deployment experts, like our friends at Rails Machine and Engine Yard, will join us in our effort. :-)
If youâre still hosting your Rails application on Apache and FCGI in a shared environment, this list is for you! ;-)
UPDATE Zed Shaw has entered the buildingâŚ
Stay tuned in early February... ;-)[âŠď¸](#fnref1){.footnote-back
role="doc-backlink"}
:::
Recently, I wrote about using RSpec and autotest (âŚwhich I think should be called autospec) together to help boost productivity while working on Rails projects. It seems that a few members of the PLANET ARGON team have picked up on using it, which Iâm happy to hear about. :-)
Itâs not the only thing that Iâm happy about though.
I recently came across another gem. Several of my comrades in
#caboose are using
piston to manage external
plugins for Ruby on Rails. Wait! Isnât
this what Subversion externals is meant
for? Well, yes⌠but externals also eat away at productivity. For
example, each day, we may have anywhere from 4-6 designers and
developers working on one client project. When weâre in crunch mode,
this could account for quite a few subversion commits throughout the
day. We all know that we should run svn up on a regular basis to make
sure that weâre keeping things in sync⌠especially when designers and
developers are working really closely and fine tuning something specific
in the application. Well, the one downside to this process is that each
svn up not only checks our repository, but it also checks external
repositories.
âBut wait! Canât you just ignore externals on an update?â
Of course, but who wants to type out âignore-externals each time they
run an update? âŚor perhaps you could make an alias for this in your
shell. In any event, everyone on the team is then left to be responsible
for doing this⌠and an extra 30-60 seconds (if not longer) per svn
update times x number of people on project⌠well⌠time wasted if
youâre closely watching the svn updates. Also, TextMate doesnât have an
option currently (that I could find) to ignore externals, so for those
who manage subversion through it⌠theyâre waiting on externals within
their primary workspace.
Another issue with svn externals is that when a repository goes down, it
really starts to slow stuff down your updates. This is always fun when
you go to deploy your application with Capistrano and realize that you
canât finish the update because it canât connect it to
http://svn.lazyatom.com/public/plugins/acts_as_hasselhoff/ to make
sure that your application has the latest version of the best plugins
available for
Rails.
{width=â240â
height=â160â}
Then there is the whole issue of wanting to make changes to the plugin that youâre including as an external. How does that fit into the whole mix?
Piston encourages you to keep your external plugins in your local repository. Donât worry, it remembers where it retrieved the code from so that you can update from the external repository at any time.
Again, this is really simple like most gems.
Several months ago, I heard that people were using a program called
autotest to
have their tests continue to run as you made changes to your code base,
which comes with ZenTest. Itâs
a really nice tool written by Ryan Davis and I hadnât gotten a chance to
play with it as of yet. Well, our team isnât spending too much time in
the test/ directory these days as we jumped ship near the end of last
summer and found ourselves hanging out on the Isle of
BDD. The
locals are quite
thoughtful
about these sorts of things.
I just started working on a project that has been under development for several months and as Iâm getting to learn the ins/outs of the system, I find myself having to rerun the specs, which can take quite a bit of time watching. Watching your specs or tests run sometimes is as productive as watching your code compile. Oddly enough, this is as close to compilation as we really get when working with Ruby on Rails⌠and itâs a productivity killer for me.
So, I did a quick google search and found an announcement for Rails that ran specs through ZenTest. This was exactly what I was searching for!
Please makes sure that you have the following gems installed in your development environment as they are dependencies to make this all work.
<!-- -->
$ sudo gem install zentest diff-lcs
note Iâm going to assume that you have rspec and rspec for rails installed⌠if not⌠tsk. ;-)
```ruby
$ script/plugin install http://svn.caldersphere.net/svn/main/plugins/rspec_autotest
If you're using subversion, you might consider installing it as an
external.
```bash
```ruby
$ script/plugin install -x http://svn.caldersphere.net/svn/main/plugins/rspec_autotest
### Running RSpec autotest
This is where it gets tricky. ;-)
```bash
```ruby
$ rake spec:autotest
```
Now, you can keep a terminal window open and autotest will watch your application and detect when files change. When they change, itâll attempt to rerun your specs (specifically those that changed). This helps save you the time of having to rerun all your specs throughout the development process and keep your spec:all sanity checks for when youâre about to commit code to your repository.
Iâll post another entry in the next few days to show you how you can use Growl with RSpec Autotest to keep you from having to look at your terminal all the time.
Until then⌠have fun!
Hey! Youâre a cheater!
Well, if youâre not⌠Iâm hoping to make one out of you.
âA thing worth having is a thing worth cheating for.â â W. C. Fields
Iâm a fan of the PDF cheat sheets as I like the consolidated content contained in them. However, I donât like having to read PDFs any more than I have to. Printing them isnât always ideal either as I really donât like to carry around extra paper in my laptop bag. So, what are we to do?
Well, you can cheat the system! âŚand Iâm going to show you how!
Cheat is this really nice command-line tool that outputs a plain text cheat sheet whenever and wherever you want.
Like all the happy and good Rubygems, this is quite simpleâŚ