What Did You Learn In 2008?

I learned a lot of new things in 2008. Here are a few highlights I can think of:

  • The REST concepts became crystal clear in early 2008. Later I wrote the REST 101 series which became one of our more popular series we’ve done on this blog, and then taught a workshop on it down in Austin, TX. (The next one is in Chicago, so sign up now to be notified when registration opens.)
  • I hated, then learned, then loved Git.
  • I hated, then learned, then loved setting up my own VPS on Slicehost.
  • Learned how to write my own DSLs in Ruby. Awesome. I’ve said it before, I’ll say it again. People will look back at 2008 and remember it as the Year of the DSL, when DSLs finally started to get the attention they deserve.
  • Learned a bit about functional programming. I don’t completely get it yet, but I find it fascinating.
  • Learned to play chess better. But I still suck at it. It insists on oscillating along the love-hate spectrum.

Already on my radar for 2009:

  • Learn the ins and outs of using Apache + Passenger for Rails apps.
  • Learn jQuery and how to use Javascript more effectively in Rails apps.
  • Learn a new programming language. I have my sights set on Haskell, but perhaps Erlang.
  • Learn how to not lose at chess quite so badly.

What did you learn this past year? What do you want to learn next?

Rails Envy Podcast – Episode #061: 12/31/2008

Episode 061. Happy New Year! I went a little heavier on the sound effects in this one because I haven’t done that in a while.

Subscribe via iTunes – iTunes only link.
Download the podcast ~15 mins MP3.
Subscribe to feed via RSS by copying the link to your RSS Reader


Sponsored by New Relic
The Rails Envy podcast is brought to you this week by NewRelic. NewRelic provides RPM which is a plugin for rails that allows you to monitor and quickly diagnose problems with your Rails application in real time. Check them out at NewRelic.com.

Call Us! You can reach the podcast voicemail line at 407 409-8440.

Hear us talk about Rails, .NET, and more on the Alt.net Podcast

Photo credit

A little while back, Brian and I were glad to be asked to appear along with James Avery on the ALT.NET Podcast.

We mostly focus on issues that are of interest to those who are straddling that line between day-job .NET and night-time Rails, but we also touch on other topics as well.

So give a kick and a listen to our episode about Rails and let us know what you think of it.

Contest: Free iPhone Oxford Dictionary

I’m not big on publicizing commercial works due to the obvious bias involved, but we’ve recently finished up the Oxford American College Dictionary and Thesaurus for the iPhone and our client was nice enough to give us a few free download codes. Never one to waste free stuff I thought I’d offer them up to my readers.

So here’s the deal – to distribute these free downloads of our Oxford Dictionary for the iPhone (appstore) I’m going to run a little contest: Post your favorite word in the comments along with your preferred usage of the word (like an example sentence). I’ll pick my favorite five entries after a week or so and will email you your promo codes (so be sure to leave your email address in the comment form). Note: I am a sucker for humor and wit, so be liberal in your application of them.

Most real iPhone dictionaries (from respected publications) go for upwards of $20 – $30 so this is a pretty decent value.

Now wow me with your vocabulary.


The winning words are: sesquipedalian, recidivist, floccinaucinihilipilification, obsequious (indirectly) and esquivalience

You guys should be getting your promo codes in a few minutes. Thanks for the submissions everybody! (and, yes, all these words are in the dictionary app)


tags: iPhone,
dictionary


What’s New in Edge Rails: Dynamic Scope Methods


This feature is scheduled for: Rails v2.3/3.0


For quite some time now you’ve been able to perform simple queries using dynamic find_all_by_xx_and_yy methods:

1
2
Article.find_by_published_and_user_id(true, 1)
  #=> "SELECT * FROM articles WHERE published = 1 AND user_id = 1"

These dynamic finders provide an easy way to quickly encapsulate non-reused query conditions (for commonly used query logic you should consider using named scopes). The downside, however, is that you can’t chain query conditions when using these dynamic finders.

With the recent addition of dynamic scopes, however, you now have a way to both quickly specify query logic and chain further conditions. The naming works in the same manner as dynamic finders and the chaining works in the same fashion as conventional named scopes:

1
2
Article.scoped_by_published_and_user_id(true, 1).find(:all, :limit => 5)
  #=> "SELECT * FROM articles WHERE published = 1 AND user_id = 1 LIMIT 5"

Note how you can hang further chainable query methods off the dynamic scope here? You could also have preceded the dynamic scope with another scope, or even another dynamic scope:

1
2
Article.scoped_by_published(true).scoped_by_user_id(1)
  #=> "SELECT * FROM articles WHERE published = 1 AND user_id = 1"

This is really just another tool to put in your toolbox based on the powerful named_scope functionality of ActiveRecord.

tags: ruby,
rubyonrails


#142 PayPal Notifications

PayPal’s IPN (Instant Payment Notification) service allows your app to get confirmation when an order is processed. In this episode I use IPN to mark a cart as purchased.

#142 PayPal Notifications

PayPal’s IPN (Instant Payment Notification) service allows your app to get confirmation when an order is processed. In this episode I use IPN to mark a cart as purchased.

Managing your Life the Agile Way in 2009

We’re just a few days away from 2009 and it’s that time when we all start looking back at the last year and set goals for the coming new year. I felt like sharing some of my thoughts on how I’m aiming to approach the new year.

Historically, I’ve never been a huge fan of New Years Resolutions because my attempts were always too big to successfully measure. The goals themselves weren’t poorly thought-out, it’s just that it’s really easy to make a list of personal targets, without putting a lot of emphasis on how you’re going to achieve them. The biggest trouble that I’ve had with goals is allocating enough mental energy for implementation planning. (if only I had someone to and wireframe my life…)

Due to this, New Years Resolutions haven’t been a huge success for me. I’ve found it much too easy to pass the buck onto the usual suspects, which consist of: lack of time, energy, too much work, general life changes, health, etc.

So, for 2009… I’m going to try something different by focusing on a set of best practices that I can use on a daily-basis. I suppose that my main goal is to not place too much emphasis on any specific targets and instead place the responsibility on myself to follow these best-practices and see what good (or bad) comes of it.

By rephrasing my internal conversation from, “What did I achieve this last year?” to “Am I doing things the best that I can?” I am confident that the answer will usually be, “not likely.” I do believe that through this subtle change in context, I’ll be better apt to self-evaluate how (and why) I am doing the things that I do and refactor accordingly. If we’re not consistently Refactoring ourselves (as we do with our code), we’re going to retain a lot inefficiencies in our personal and work lives, which make it difficult for us to quickly respond to changes and opportunities.

Our life (personal and work) is just another project that we manage. Much of methodologies that we spend learning about and adopting can easily be translated to these other areas of our lives.

So as I brace myself for 2009, I find myself asking, How can I lead a more Agile life?

I’d love to hear how you’re adopting best-practices inspired by Agile methodologies in your life and I promise to share mine over the coming year.

Related Posts

Rails Envy Podcast – Episode #060: 12/25/2008

Episode 060. Merry Christmas! Happy Holidays! OMFG MERB AND RAILS OMG OMG OMG OMG. And that’s going to be in next week’s episode! LOL!

Subscribe via iTunes – iTunes only link.
Download the podcast ~13:42 mins MP3.
Subscribe to feed via RSS by copying the link to your RSS Reader


Sponsored by New Relic
The Rails Envy podcast is brought to you this week by NewRelic. NewRelic provides RPM which is a plugin for rails that allows you to monitor and quickly diagnose problems with your Rails application in real time. Check them out at NewRelic.com.

Call Us! You can reach the podcast voicemail line at 407 409-8440.

The future of Rails: Rails 3.0

The Merb team joins force with the Rails core team to work on Rails 3.0 and brings many of the modularity and performance concepts from Merb to Rails. At first I thought “Oh, no”, that’s gonna be a mess. But after reading several of the announcements I can see the benefits of the effort and this will make Rails more simple, more modular, more robust, better defined, and certainly faster. Bringing two different teams together is very difficult but the fact that both team are complementary and look for excellence in their work and managed to come up with a great vision of the future of Rails, got me excited about the future of Rails. They gonna make it happen. You can read more about here:

Merry Christmas/Hanukkah/Hollidays!

Daniel.

Rails 3 and Merb

So… Rails and Merb are going to be merged into Rails 3. (link)

Has hell frozen over?

(it has in Portland the last week)

I’m curious about how the revised core team will incorporate the library-agnostic view points into Rails without increasing the complexity for configuration. For example, being able to use a different ORM is great, but at the same time, one of the things that I have really liked about Ruby on Rails was that it did make decisions ahead of time for you. Conventions over Configuration and all that jazz. While they intend to keep these defaults, I really wonder how much more configuration will be involved. Be that as it may, Rails and Merb are run by some of the best developers I’ve ever known… so I am sure these decisions will not be made without some deep consideration.

Rails application don’t all look and smell the same, but it’s nice to know that there is consistency across all of our client applications. What I’m concerned about (from an efficiency standpoint) is that this could lead to project-diversity at the cost of experimenting. Pre-Rails, the development teams that I was a part of was constantly trying out new libraries from client project to project, but this came at a huge cost. We weren’t able to leverage our experience with previous projects like our team does with Ruby on Rails currently. (hell, I even helped write two different ORMs in the two years before Rails for PHP… and still wasn’t satisfied)

But, this isn’t so much a technical problem as much as a people problem. The thing is… is that Rails helped solve a people problem with a technical answer. Having testing, consistency, and other best practices built-in did the world a huge favor. …and all it took was someone like DHH to throw his opinion out there and stick to it. It took me nearly a full year to really embrace a lot of these conventions, but in the end.. it paid off.

While I do feel that it’s in developers best interests to try out new approaches, I just don’t think it should be on your clients dime. This was part of the reason why I quit my last job to start Planet Argon full-time. I really wanted to get away from that cycle.

Since we (Planet Argon) adopted Ruby on Rails four years ago, we’ve been able to build off of every project we had worked on before. We since adopted things like RSpec and JQuery, but our team decided on these changes after someone took the initiative to experiment with these on internal and personal projects. Having this foundation has freed up a lot of our time to focus on other issues as a team, like Interaction Design, Usability, and client collaboration.

As far as Merb itself, I honestly haven’t tried to do anything with it since about 0.2/0.3. I gave up quickly though because the documentation didn’t help me get anywhere and my time is valuable. I’ve since seen that documentation has improved drastically, but I haven’t been able to prioritize the time needed to really play with it. With Merb being merged into Rails 3, it means that I really should spend more time exploring it as we might be able to leverage some of it’s benefits without as much of an investment.

Much of the lack of great interest in Merb was because I felt Rails had consistently provided our team with a solid foundation for a majority of our internal and client applications. The old saying, “if it ain’t broke, don’t fix it.” Not to say that others haven’t expressed a lot of excitement about Merb and it’s benefits, I just didn’t see there being enough of a productivity gain to warrant the time investment required to really learn and use a new framework… and the one thing that I have had trouble with was that it didn’t sound like Merb encouraged a default set of libraries. I could be totally wrong, but that’s been the perception I’ve had based on how it was branded.

But… the best part about this for you, me, and the Rails community? Is that I don’t need to register robbyonmerb.com anytime soon. 😉

I hope that you’re all having a great end to 2008 and am excited to see all the energy in the Ruby/Rails/Merb community. I suspect that between these two (now-merged) teams, we’ll have an even better platform to develop web applications on. I believe this is great news and I’m all in favor of seeing the Ruby community conquer these challenges that lay ahead.

Anyhow, I’m just thinking out loud. What are your thoughts?

What’s New in Edge Rails: Merb!


This feature is scheduled for: Rails v3.0


Wow, from the bombshell department comes the news that Rails and Merb will be merging to form Rails 3. It seems the Rails and Merb teams have acknowledged that there is good in both frameworks and that they can be combined into a singular web framework.

To be honest I don’t love the idea of having less choice in Ruby web-framework world. However, I do think this bodes well for Rails. We can only hope innovation stays alive within the combined team (and that their perspectives only enhance each other and don’t outright conflict).

Read what Yehuda, now a Rails core team member, Ezra, Carl and Matt have to say as well.

Little ‘ole Rails is definitely growing up – lots of big stuff coming in Rails 3…

tags: ruby,
rubyonrails


Flex Job: Full time Flex developer in Denver at Videopros.com

Solomon, who also writes on this blog, is currently doing Ruby on Rails work for videopros.com and they are looking to hire a Flex developer to complement their small development team. Here are the details…

VP_Logo_300x100.jpg

We seek a Flex on Rails Kingpin to lead our development team. This is for a full-time or contract-to-hire position. Private consultants should not apply. Depending on skill level and commitment an equity stake is available.

Compensation

  • 70-100K
  • Potential Equity
  • Potential Profit Sharing

Skills and Experience

  • Ruby on Rails | 2.5 Years minimum
  • Flex | 1 Year minimum
  • Web Services
  • Experience as the lead developer for a commercial project.
  • Agile development
  • Subversion (GIT)
  • Linux
  • MySQL
  • XML

Benefits

  • Competitive Salary
  • Health Insurance
  • Long Term Disability Insurance

About Us – The VideoPros Dojo

Dojo means “place of the Way.” Much like a martial arts practice hall, the WAY we operate at VideoPros is a pursuit for mastery in the face of adversity and challenge. The true challenge is not between people and external things – but within ourselves. 

Working at VideoPros means going within yourself and seeing the work you do as a reflection of who you are on the inside. It’s more than “work” or “my job.” We are a place you go to practice being the best you can be – every day.

Apply

VideoPros is motivated to fill this position quickly. To apply, email your resume and one reason why you want to join us at the Dojo to:
Careers{at}VideoPros{dot}com

#141 PayPal Basics

This episode is the first in a series on handling the checkout process for orders. Here we show how to complete purchases through PayPal’s Website Payments Standard service.

#141 PayPal Basics

This episode is the first in a series on handling the checkout process for orders. Here we show how to complete purchases through PayPal’s Website Payments Standard service.

Agile git and the story branch pattern

I’ve been using git for source code management for over a year now and I’m totally hooked. I won’t rave about all the usual reasons WhyGitIsBetterThanX since it’s been done already. Instead, I’m going to share how I use git for easy agile development.

The basic idea is to never do anything in the master branch except use it to move changes between the remote repo and local branches. Keeping master clean takes very little effort and will save your bacon when you get into trouble. The example I’ll use here is working on a story to render title text in a bold style on a page.

1. Locate story “titles are in bold text” in Pivotal Tracker and click Start.

What do you mean you’re not using Pivotal Tracker?

2. Get going with a clean start.

$ git checkout master
$ git pull
$ rake db:migrate   # if there are new migrations
$ rake              # if you don't have a CI server

3. Make a branch to work in.

$ git checkout -b bold_titles

4. Test-drive the story.

Since you are committing locally, you can commit often. Sometimes I like to commit every time I get a test to pass, or after crucial steps in a refactoring.

$ git commit -am "Don't bold empty titles"

We should all know the advantages of frequent commits: when an experiment fails, it’s easy to get back to a previous state where things worked; or when refactoring, you can see how things were before you started changing things around. With git you can also do things like cherry-pick commits, so if you want to grab a single test and its implementation and extract it as a patch or whatever, you can do that.

When you are done…

$ rake
$ git commit -am "Render titles with bold style"

5. Merge with master

When you’re done with the story, you need to integrate your changes with the master branch. You’ll have to fetch and merge the changes from origin/master into your branch.

a. Review changes

I like to review changes to make sure I didn’t leave any debugging cruft in, and as a final check on code quality.

$ git diff master

b. Merge changes

$ git checkout master
$ git pull
$ git checkout bold_titles
$ git rebase master

The four commands above may seem a bit convoluted, but all you’re really doing is merging updates from the remote repo to your story branch by way of the master branch. Now, if you have any merge conflicts, they are all in the story branch where you can work on resolving them in your normal work environment without disturbing the master branch.

If you took enough time resolving merge conflicts that someone else checked in changes to the remote repo, repeat this step until you’re fully merged locally.

Also, notice I used rebase instead of merge to integrate the master branch changes, but that choice is up to you. Whether you use rebase or merge is a matter of convention for your project. Doing a rebase will replay your changes on top of the changes you just merged with. That should have a net effect of zero on the final product but has the advantage of keeping all your changes contiguous in the history, and won’t generate a separate merge commit when you merge back to the master branch since the changes come in as a fast-forward.

You can also rebase with the -i (or –interactive) option to squash several (or all) of your commits into a single commit, or to organize your changes as a reduced number of commits. Frequent commits are great to manage your own work and give many checkpoints to roll back to if needed. But adding dozens of commits to the project for a simple feature can be overwhelming for others on your team, and can make it difficult to navigate or understand the project history. For example:

$ git rebase -i master

That will show you an $EDITOR session like this:

# Rebasing 1234abc..3333ccc onto 1234abc
#
# Commands:
#  pick = use commit
#  edit = use commit, but stop for amending
#  squash = use commit, but meld into previous commit
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
pick 1111aaa Use <strong> tag to bold titles
pick 2222bbb Don't render empty titles as bold
pick 3333ccc Use font-weight property on h1.title instead of <strong>

The commits are listed in chronological order, oldest on top. If you want to combine several commits into one, edit the word pick at the start of the line to say squash, and that commit will be merged with the one above it. Since you are seeing all your commits and their messages, you can probably say something useful about the whole set as you package it for pushing to the shared repo. Sometimes you’ll want to squash down to just one commit, others you may want to structure the package as a small number of related commits, say one commit for your feature addition, and another for a refactoring your feature relies on.

Important: Rebasing rewrites history and should never be done to reorder changes you have previously pushed to another repo or shared publicly.

c. Be green

Once done merging, make sure you’re still green.

$ rake

d. Merge early, merge often

If the work on your branch takes long enough, you might want to perform a merge several times. As other people push to origin/master, you can pull those changes and integrate them into your branch incrementally, rather than waiting until the end when you’re done. Whether to do this is a judgement call, and would depend on factors like the nature of the work you’re doing the the kind of changes you’d be integrating. But one of the more valuable practices of agile development is continuous integration, and spending too much time accumulating change on a branch that is cut off from the rest of the development stream can eventually make for a difficult merge at the end of your story.

6. Push

Once you have integrated your changes with those from master, you can merge them back to the master branch and from there to the remote repo.

$ git checkout master
$ git merge bold_titles
$ git push

7. Cleanup

$ git branch -d bold_titles

Delete the story branch, click Finish on the story in Pivotal Tracker, then get up and stretch and get some water.

Caution

Probably the biggest gotcha particular to Rails development on more than one branch is dealing with database migrations. It’s easy to get confused between the state of the database and which migrations are in what branch. I’ll take one of two approaches, depending on how complicated things are. One is to rollback the migration on the current branch before switching to another branch that doesn’t have that migration yet, then run pending migrations on the new branch after switching. But if you’re going to be switching around branches with different migrations a lot, the best thing is to integrate the migration changes so they exist on both branches and it ceases to be an issue.

Discussion

Okay that’s a lot of stuff going on. What’s the point? Well, the point is dealing with the unintended. (I was going to say “unexpected”, but if you’re developing software or working on a team, you should expect crazy things to occur occasionally.) There is obviously overhead in managing multiple branches, and you may wonder what you’re getting for the cost of that overhead. There are a couple things that come to mind that I’ll mention here, but I’d like to hear more in the comments from people about what situations they deal with this way (or other ways).

The first thing this approach helps with is being able to make frequent commits without breaking the build or disrupting the work of teammates. Working with a centralized SCM system like Subversion can force you to choose between checkpointing your work and keeping the state of the project consistent. I know agile developers who swear that making frequent commits to the shared repo is the way to go, and just deal with having to keep the build green and functional on every commit. But I find that approach too constraining, and it can impose an uncomfortable style on how I do my work. I find being able to do frequent commits without worrying about disrupting my teammates’ work with half-finished features lets me concentrate on getting things done, instead of thinking about how big a change I can make without messing up someone else’s work. And I also don’t have to worry about the converse either. Don’t you hate pulling down changes that include a migration and wondering if the relevant model changes to let that migration do the right thing have been made yet?

But why the separate story branches? Isn’t it just as convenient to do all your work in your local master branch and do your local commits there? Up to a point, sure. But keeping a separate branch for work means that you always have a good baseline around for reference, it lets you rebase to manage your changesets easily, and it makes dealing with merge conflicts a bit more sane.

And if you have to share or backup the state of your work in progress, it’s very easy to push your local branch to a branch in the remote repo without disrupting anything.

There’s also the advantage that it’s easier to deal with being interrupted. Say you’re working on a story that’s going to take you all day and someone finds a nasty bug in production. Time to drop everything and get it fixed right away! If you have your work in progress on a branch, it’s simple to do a checkpoint commit, switch back to master, create a new branch for the bugfix, fix the bug, push the fix, then get right back to where you were before.

Push

I’ve been using the story branch pattern for development for most of the last year, and have found it useful, convenient and a lifesaver when things get weird. I’ve also watched teammates that do their work in the master branch, and it is more work for them to deal with issues and avoid making unintended messes. Like all useful practices it takes a little bit of effort up front, but it saves a lot more effort when it really matters.

RailsBoxcar.com 2.0

In case you missed the tweet from Alex

Twitterrific

Our team just designed, developed, and deployed a new site for, Boxcar, our streamlined deployment environment for Ruby on Rails applications.

Boxcar

Feel free to take a tour to learn more about our product plans, which currently start as low as $59/month.

If you have a project that you’ll be launching in the coming months, get in touch with us. 🙂

What’s New in Edge Rails: Rails Metal


This feature is scheduled for: Rails v2.3/3.0


In what is clearly a move to make me irrelevant within the Rails community, news has broken about the new Rails metal feature before I had the time to do a proper write-up. (And for the second time in as many weeks, no less). I need to get on my horse here, many apologies.

So Rails Metal is a way to cut out the fat of the MVC request processing stack (and the all the niceties, too) to get the quickest path to your application logic. This is especially useful when you have a single action that you need to run as quickly as possible and can afford to throw away all the support Rails normally provides in exchange for a very fast response time.

While I could throw out some examples here, I’ll let Jesse Newland of RailsMachine do the heavy lifting with his great writeup (a little morsel – his tests have Metal running 25x faster than the comparable controller-based action).

This is definitely an exciting feature to keep an eye on!

tags: ruby,
rubyonrails


Microblogging on Twitter

Earlier this year, I started using twitter. I was not at all convinced it would be worth my time. I didn’t really understand why I would want to tell people “what I’m doing right now.”

While some people literally tweet what they’re doing every five minutes, I discovered that many people don’t. And so now, I “get it”. I’ve found the key is not follow a lot of people – I currently follow about 70 – otherwise it’s a firehose.

What I get out of twitter is access to conversations that those that I’m interested in are having. It helps me keep up with the news a bit more than reading blogs, although anything important always shows up on a blog at some point anyway. Also, many heated conversations on twitter originate from a blog post.

So I think blogging is here to stay for a while, despite what some may think.

However, it occurred to me that I’ve blogged a lot less in the past couple months, because it’s much more convenient for me to tweet a link or an idea, than it is to write up a blog post. So while both Brian and I will continue to blog here, you should follow us on twitter:

Jeff on twitter

Brian on twitter

Anytime we have something to announce, teach, entertain, or waste your time with that fits into 140 characters or less, we’ll use twitter instead.

I will say that I don’t understand how some people follow 800 other people. Unless you’re watching the stream all day long, or using another tool to analyze/summarize it for you (which is cool).

And I don’t understand tweets like, “Having dinner with my wife.” Imagine, you’re sitting there eating dinner… “Uh huh, yes dear, exactly… hold on a minute, i have to get my cell phone out so i can text something to twitter…”

#140 Rails 2.2 Extras

This episode finishes up the Rails 2.2 series by showing a few miscellaneous additions that I find useful.