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…
Well, they must be listening to me.
A few months ago, I posted that I was looking to switch mobile services. Well, I switched over to Cingular after a lot of back and forth and have been fairly happy with their service. I opted to get their lowend/entry phone as I wanted to get a nicer phone when I found something that met my requirements.
I wanted…
Well, I hadn’t found anything that really caught my attention. So, I heard rumors about Apple releasing a phone in January. So… I waited.
“Yay Apple! I think I’m in the right office, we’re all sitting here reading the keynote updates.” — Audrey
So, how much is this going to cost us? ..a few of us here came up with our predictions.
Thank you, Apple!
…well… I would have given Apple a hug if I didn’t have to wait til June.
…back to work.
Wow, this is pretty cool.
CDBaby is sponsoring conference passes AND twenty rooms at the Jupiter Hotel in Portland, OR during RailsConf 2007 to the top 20 contributors to the Ruby on Rails project from during January.
Start submitting patches!
During the summer of 2005, I wrote a post that listed several coffee shops in Portland, Oregon that I found to be really good places to work on your laptop at. I’ve gotten bored with my regulars and have recently begun to look for new places to venture to.
{width=”240”
height=”160”}
Pier Coffee is in a weird part of Portland that is somewhat isolated due to the train tracks that will block you in when a long train is moving through town. It’s a very short walk from Allison’s place and they have Oregon Chai, which has become my replacement for drinking coffee. The chairs in Pier Coffee are very comfortable and they have an electrical outlet at most of their tables. When you get bored, you can walk over and play darts, or get a glass of wine. The wireless works really well and when it’s not raining, you can sit out front and overlook the train tracks and downtown, while hacking on your laptop. Pier Coffee is what I would consider an easy place for me to feel productive. There usually isn’t too many people here and I believe most of the customers are from the two condo complexes next to it. The staff is very friendly and their music tastes aren’t annoying.
Backspace is about a half block from the PLANET ARGON office. They don’t serve Oregon Chai, so I usually only get a tea, a viso, or a hot cocoa while there. They have a few tables and couches and I haven’t found this a good place to be productive. It’s a good place to have a short meeting with a coworker though. Music tastes are better here than most places, and they have a food menu now that caters to my vegetarian diet. There are a few electrical outlets, but the seats near them are often occupied.
Three Lions Bakery is about a block from the PLANET ARGON office. They do have Oregon Chai, so I stop by here often in the morning to get my fix. Not many electrical outlets, so your visits are usually not very long. They have a few sandwiches that are quite good. This is a good place to stop by if you’re in the mood to work for about a hour and have some chai and an excellent (and freshly baked) cookie.
If you’re in Portland and have some recommendations, please do share. I’m looking for a few places that are open later in the evening.
I’ve been keeping my eye on a series of blog posts by Chad Fowler, which he calls The Big Rewrite.
Today, Chad posted an entry titled, Who’s Tending the Store? He writes…
“the experts keep the old system running while the new system is being built. So, who builds the new system? Not the experts, that’s who. Usually, it’s people like me: technology experts. And while we’re banging away at the existing system’s UI, trying to figure out what needs to be coded, the domain experts are doing their jobs. Unfortunately, this means the domain experts aren’t watching the Big Rewrite very closely. Regardless of how good the team, if communication is impaired between the domain experts and the technology experts, things are going to move slowly, and wrong software is going to be created.”
I wanted to follow up on this issue as it’s an area of great interest to me.
I feel like this issue runs deeper and while it’s important to be mindful of the communication between domain and technology experts, it’s a good idea for each of us to take a break every few days (or everyday) to assess our perceptions in all areas of the project. More specifically, I’m suggesting that in order for us to be effective in our communication, we must make time to refactor our perceptions about the state of a project. From the design, to the development, to team communication, to the schedule, and all the way to customer satisfaction… or what Martin Fowler calls, Customer Affinity. These things are not static and we must see them as extremely dynamic variables… much more dynamic than our wonderful language of choice.
When Brian Ford and I started discussing Dialogue-Driven Development (d3), we were initially focused on an area that always seems to come up in projects. Client communication. From managing expectations to delivering the right product, d3 has become an essential tool in our team’s tool belt. We refactored our entire Design and Development process (and it’s always evolving) to focus on the things that we felt were the most important to a successful project. Clients come to us in search of expertise and guidance so that we can build them innovative solutions. When it comes to this process, clients deserve simplicity.
If there is one thing that I have learned, it is that our initial perceptions are often misguided. We have to work really hard to think critically, not only of the problem we’re trying to build a solution for, but also of how we, ourselves, are actually looking at the problem. It’s easy to fall victim to tunnel vision. I often find myself having to take a step back from problems on a very regular basis. While I have no scientific proof to back this, it seems to feels natural for us to keep firing once we pull the trigger. It’s important to re-aim.
Chad raises a very important topic and leaves readers to think about the problem. After thinking about this, it’s my opinion that in order for the domain and technology experts to be effective, they need healthy collaboration. But, I feel like this applies to many other areas of our process as well.
So, what is the solution? Better yet, what is the problem? Is there even a problem?
How can we avoid situations where communication becomes impaired? We’ve all been there. We know how to spot impaired communication, but how can we spot it… before we perceive it as too late? How can we recover from it? What causes the communication to break down? What if… it were possible to repair the situation?
These questions don’t have easy answers. These are complicated problems that reach far beyond the development community. These are the same problems that all members of organizations, communities, countries, and planets all face, each and every day.
While it’s important to make sure we’re engaging in healthy dialogue through a project, bad things will happen. They are inevitable. As Agilists, we’re accepting this as a fact of (project) life and should be prepared to take action. If you see communication being impaired, it’s time to step up and help the team out. Otherwise, you’re only hurting yourself… and your colleagues.
“Be the change you wish to see in the world.” — Mahatma Gandhi
If these sorts of topics are of interest to you, I encourage you to join the Dialogue-Driven community and help us figure this stuff out!
Finally, a break from a hectic week at the office. I spent most of my week working on some servers and outlining some of our plans for where we will be taking the hosting side of our business during the first quarter of 2007. Let’s just say, we’re a few months behind schedule and it’s time to get onboard before the train takes off. ;-)
{width=”240”
height=”160”}
Have a safe and exciting New Years!
Yesterday, those of us who were still at the PLANET ARGON office (and not already on vacation) took the afternoon off yesterday to have a few drinks to kick-start the holiday season.
{width=”240”
height=”188”}
{width=”240”
height=”160”}
{width=”160”
height=”240”}
I’m getting ready to head up to Seattle for the holiday weekend. I hope that you all have a safe and fun holiday season!