without_scope

One of the reasons AAR was created was due to the hoops that we had to jump through to effectively version across associations while taking into account our business logic. We ended up with hundreds of lines of very complicated spaghetti code. It wasn't pretty.

Here I'm going to demonstrate how you can very simply version two models together.

We'll provide for Posts which can have multiple Links. Any time a Post is created or modified, a revision of it and it's associated links at the time will be stored. Adding a link to a Post will also trigger a revision.

Changing a link will not trigger a revision of the Post. This is trivial to add and should be considered a task for you (if you want to play with AAR).

Model walk-through

You can grab the complete code for this any time at GitHub but, I'm going to walk through the models now.

post.rb

class Post < ActiveRecord::Base
  acts_as_revisable
  has_many :links, :before_add => :revise!
  after_revise :revise_links!

  private
    def revise_links!
      self.links.each(&:revise!)
    end
end

So first, we're defining our Post, making it revisable and associating it to it's links. We've also added two callbacks.

The first, on the links association, causes the post to be revised before a new link is added. This allows us to grab the state of the links before it changes. So we'll end up with an accurate snapshot of the post.

The second callback is the after_revise callback which simply loops through the links, forcing a revision on them. This allows us to peg a particular post revision with a particular link revision.

Notice there's really no magic here, we're just using the tools acts_as_revisable gives us.

link.rb

class Link < ActiveRecord::Base
  acts_as_revisable

  belongs_to :post
end

Simply declaring our Link, making it revisable and associating it with a post. Nothing special here.

post_revision.rb

class PostRevision < ActiveRecord::Base
  acts_as_revision

  has_many :links, :class_name => "LinkRevision", :foreign_key => "post_id"
end

Now we're explicitly defining our PostRevision class and letting AAR know. Defining the association requires a few more options just to override some of ActiveRecord's defaults. Notice PostRevisions will always be associated with LinkRevisions.

link_revision.rb

class LinkRevision < ActiveRecord::Base
  acts_as_revision

  belongs_to :post, :class_name => "PostRevision"  
  before_create :reassociate_with_post, :if => :post_in_revision?

  private
    def reassociate_with_post
      self.post = self.current_revision.post.find_revision(:previous)
    end

    def post_in_revision?
      self.current_revision.post.in_revision?
    end
end

Here's the most complicated part and even this isn't so bad. We're explicitly defining our LinkRevision and it's association.

Next, we have a before_create callback. Keep in mind, this is the revision model so, before_create in this case is roughly equivalent to before_revise on the Link model. I've defined it this way for the sake of clarity. The work in this callback really concerns the revisions not the revisable. So, while it could be defined in either model, it makes the most sense when reading the code for it to be here.

The reassociate_with_post method being called by the callback is relatively easy to understand if you keep the big picture in mind. A post's links are being revised after the post so, this callback is called after the post has been revised. So, we're simply grabbing the last revision of this post and associating the LinkRevision with that.

Let's see it in action

>> p = Post.create(:title => "Simple association versioning with acts_as_revisable")
=> #<Post id: 55, title: "Simple association versioning with acts_as_revisabl...">
>> p.links.create(:url => "http://github.com/rich/aar-demo-1/tree/master")
=> #<Link id: 92, url: "http://github.com/rich/aar-demo-1/tree/master">
>> p.revisions.size
=> 1
>> p.revisions.first.links
=> []
>> p.links
=> [#<Link id: 92, url: "http://github.com/rich/aar-demo-1/tree/master">]
>> p.title = "That was easy"
=> "That was easy"
>> p.save
=> true
>> p.revisions.map {|r| r.links.size}
=> [1, 0]
>> p.revisions.first.links.first
=> #<LinkRevision id: 93, url: "http://github.com/rich/aar-demo-1/tree/master">
>> p.links.create(:url => "http://github.com/rich")
=> #<Link id: 95, url: "http://github.com/rich">
>> p.revisions.map {|r| r.links.size}
=> [1, 1, 0]
>> p.links.size
=> 2
>> p.links.create(:url => "http://github.com/technoweenie/acts_as_versioned/tree/master")
=> #<Link id: 98, url: "http://github.com/technoweenie/acts_as_versioned/tr...">
>> p.links.size
=> 3
>> p.revisions.map {|r| r.links.size}
=> [2, 1, 1, 0]

I have a couple ideas in progress for a followup post but, I'd love some requests if there's interest.

Remember, you can grab the code on GitHub.

Over the years of Rails work I’ve been using a few services that I consider indispensable now. Hoptoad is one of those tools. It beats the hell out of pretty much every cobbled together error notifier I’ve seen. I can’t see launching an application without it.

The Horror

Sometimes, I need to work with PHP. It’s not pleasant but, there it is. One of the things I did to make this a bit more palatable is hack together a Hoptoad notifier for PHP. Recently, with some help from Lou Kosak, I’ve cleaned the code up a bit and think it might be useful in other projects now.

Grab it

You can find the code at http://github.com/rich/php-hoptoad-notifier. Just drop the Hoptoad.php file somewhere in your include_path and include the following code somewhere early in your application:

require_once('Hoptoad.php');

Hoptoad::installHandlers("YOUR_HOPTOAD_API_KEY");

I’ve been working on this on and off for the better part of the last year. Life has intruded many times but, I’ve finally got it to a point that I’m comfortable releasing as a 1.0.

This plugin grew out of Stephen Caudill and my use of Rick Olsen’s ActsAsVersioned. The application was centered around versioning of our user’s resources. Early on, AAV worked great for us but, as our requirements got more complicated we found ourselves hacking AAV more and more.

Eventually Stephen came to the conclusion that we needed to break from AAV and roll our own. So he laid out the requirements and I built it. I’m going to talk about all of AAR’s features through a series of posts but, I thought I’d quickly highlight some of it’s unique features now.

Pervasive Callbacks

AAR was created to help build applications that need precise control of the life-cycle of it’s data. In pursuit of that, there is a full suite of callbacks:

• revisable models
  • before_revise
  • after_revise
  • before_revert
  • after_revert
  • before_changeset
  • after_changeset
  • after_branch_created
  • before_revise_on_destroy
  • after_revise_on_destroy
• revision models
  • before_restore
  • after_restore
• both revisable and revision models
  • before_branch
  • after_branch

AAR callbacks act just like ActiveRecord callbacks. They accept all the same arguments and they can prevent the action being taken just like AR callbacks.

Branching and Changesets

Branching is a well understood concept, no need to go in depth on this, here’s the relevant code:

  @branch = @post.branch
  @branch.branch_source == @post # => true

Changesets are a bit more interesting. In non-trivial code you may end up a block of code that may perform many actions that each cause a revision to be saved. If you wish to group those as a single revision, you can:

  @post.changeset do 
    @post.title = "A post"
    # save would normally trigger a revision
    @post.save
    # update_attribute triggers a save triggering a revision (normally)
    @post.updated_attribute(:title, "Another Title")
    # revise! normally forces a revision to be created
    @post.revise!
  end

Deletes can be stored as a revision

This is pretty simple, #destroy no longer destroys the record. It flags it as deleted. Deleted records can then be accessed through the revision class’ #deleted named_scope.

  class Post < ActiveRecord::Base
    acts_as_revisable :on_delete => :revise
  end

  @post.destroy
  PostRevision.deleted # => [@post]

Explicit is better than implicit

ActsAsRevisable will not, by default, define the revision class for you. The most common configuration is as follows:

  class Post < ActiveRecord::Base
    acts_as_revisable
  end

  class PostRevision < ActiveRecord::Base
    acts_as_revision
  end

If you want to call your revision class something else, you can:

  class Post < ActiveRecord::Base
    acts_as_revisable :revision_class_name => 'OldPost'
  end

  class OldPost < ActiveRecord::Base
    acts_as_revision :revisable_class_name => 'Post'
  end

If you absolutely must have AAR generate the class for you:

  class Post < ActiveRecord::Base
    acts_as_revisable :generate_revision_class => true
  end

All data for a model is stored in one table

There isn’t a separate versions table. This comes from the belief that all Posts (or whatever your model happens to be) are Posts whether or not they’re the current version.

This also makes it much easier to find records whether or not they’re the current version or not:

  Post.find(:all, :conditions => {...}, :with_revisions => true)

Wrapping up, requirements and installing

There’s a lot of flexibility here. In the application AAR was built for we were using it to version entire trees of objects together, not just individual records. I plan on digging into this and more in future posts.

AAR 1.0 requires Rails 2.3. You can take a look at the code on GitHub.

  sudo gem install rich-acts_as_revisable --source=http://gems.github.com

Once the gem is installed you’ll want to activate it in your Rails app by adding the following line to config/environment.rb:

  config.gem "rich-acts_as_revisable", :lib => "acts_as_revisable", :source => "http://gems.github.com"

I’ve been playing with Google Chrome all day. I’ve used it exclusively for about eight hours now. I’m definitely impressed. It’s fast, simple and stable. The UI changes show obvious inspiration from all of the major browsers with solid usability improvements.

The concept and implementation of distinct processes for each plugin and page causes an inappropriate stirring in my loins.

I’m impressed.

I’ve seen those details covered ad-nauseam though and probably better than I ever could. Here’s a decent rundown.

Wrapping Myself in Tinfoil

I don’t think Google wants or expects to gain significant market share with Chrome. I think they’re now trying to drive innovation in the browser world by competing rather than simply consuming.

They’ve been providing carrots to the browser makers in the form of the various Google apps for years. I think they’ve been disappointed at the relatively slow and uninspired developments of IE, Firefox, Opera and Safari.

I believe this is Google’s stick. They’re going to smack the other browser developers with Chrome to drive them in the direction that they believe is most beneficial to Google.

I really don’t think I’m way off in tin-foil hat territory here but I am curious what others think.

Clarifications

Reading what I wrote below I see where my mind was just a few days ago. I wasn’t entirely wrong to talk about where my mind was but, I did trivialize the job offer quite a bit in an effort to get people to backup the idea of consulting.

That was kinda stupid of me to do though. It actually *is* an interesting job with a company in a field I’ve wanted to work in for a long time. It’s a solid group of passionate people and anyone that knows me knows seeing passion for what you’re doing is a big deal for me. These people don’t just have passion though, they seem to have the talent to implement their vision.

So, I’m leaving the post as is for posterity’s sake but, as you read, keep in mind I don’t even agree with a fair bit of what I wrote myself.

---

I’ve been an out of work Ruby developer for about three weeks now. When I got word that my paychecks would stop coming I immediately reached out to some friends and colleagues for a few contracts and this is what I’ve been doing the last few weeks.

Three Weeks

In those three weeks I’ve been working on some truly interesting projects and learning a ton. I’ve been working with other people’s code that borders on pure poetry and some code that appears to be an implementation of “Brainfuck on Ruby on Rails”.

In just three weeks I’ve worked in multiple languages with several technologies I hadn’t touched before. I’ve even found and used a respectable PHP ORM.

More importantly, I’ve gotten a crash course in the contracting business from some smart people that have been doing this for years. I’m also playing “Do The Hustle” on a perpetual loop, thanks Obie.

Doing this for just three weeks of course means I’m still absolutely horrible at the sales process but, it’s a start.

No Plan

So far, I’m loving the contracting thing and I want desperately to make my living doing this for a while. The problem is, I didn’t plan this.

I planned on sticking with JamLab and seeing that through. I planned on a successful launch and supporting a truly awesome product. I planned on getting a steady paycheck and health insurance.

I have all the usual responsibilities of someone my age. I have a wife, a daughter, a mortgage, etc. All these people and things generally want to eat and/or get paid on a pretty regular basis.

Had I planned this and had all the research done and proof that I could handle my responsibilities consistently I wouldn’t be so nervous. I’m fine now but what about tomorrow? The day after?

Is there really that much work for a good developer but horrible sales guy?

My Dilemma

I got a job offer today. Not a great one and not a horrible one. I would still get to use Ruby, which is great, and the work looks interesting. The job does strike me as having the potential of being one of those perpetual crunch time environments though. Really, this post isn’t about this job though, others will come, it’s more about full-time v. contractor.

It would pay the bills though and, I’m assuming, on a pretty regular basis. I just honestly don’t know what to do.

Three weeks ago it was easy, I was a cog in a wheel and didn’t know what I was missing out on. Now I’ve got a taste and I do like it.

So all ten of you that read my blog, tell me what to do. Help me map out my future. Direct me on how to balance my happiness.

Or just post lolcat images, that’s fine too.

This is as much a note to my future self as a warning post to others doomed to make the same mistake I did. I was creating a few methods to extend a has_many association with. Based on the current Rails docs I used the proxy_target accessor to get at the records of the association.

The only problem with that is proxy_target is not populated unless the association had previously been traversed through the same model instance. After I tossed in a line of code into the method that explicitly loaded the association I decided this was a bug in Rails.

It wasn’t a bug

I started thinking about a patch but decided this couldn’t possibly have been missed that long. So instead I googled quite a bit more and eventually found “Should proxy_owner be eager loaded?”. This accurately described my issue.

The answer

Put simply, proxy_target is implied in the scope of association extensions. Here’s some of my own example code that demonstrates:

Also, if you go off the beaten path in the Rails docs a bit you’ll find this behavior is documented in ActiveRecord::Associations::AssociationProxy. This should probably be mentioned in ActiveRecord::Associations::ClassMethods where proxy_target is discussed. Maybe I’ll make my first doc patch tomorrow.

Feel free to use the comments to ridicule me.

I’ve been using Shoulda for some new projects and while it’s a learning experience I’m really pleased with the results. One thing I noticed right away is that I was testing for the presence and functionality of several Rails plugins I chose that are being used on many models.

I ended up writing custom Shoulda macros for three of the plugins: ActsAsTaggableOn, ActsAsCommentable and SaltySlugs. Below are the macros and an example of their usage in a test.

Shoulda Macros

Example Usage

$ ruby -Itest test/unit/album_test.rb 
Loaded suite test/unit/album_test
Started
…………………
Finished in 0.109251 seconds.

21 tests, 32 assertions, 0 failures, 0 errors

Jay Fields originally got me thinking and writing the first draft of this with his “Developers needed; Hackers need not apply” post. By his definition, I’m a long time hacker. I’m in recovery now and feel like I’m far more of a developer at this point.

Confession time…

For too long I worked in very small companies where I was the only developer. A few times I was the only one with any technical experience and yeah, that was in technology startups. This led to them leaning too much on me for the overall direction of the products which in turn led me to think I’m qualified to make those decisions on my own.

If you’re a developer, that’s a path destined for failure. You’ll likely make things more complicated than they need to be which will take longer to develop. Talk to everyone you can about the project and really listen. This sounds absolutely ridiculous and basic when typed out but, some people can’t even make that step, I know I couldn’t.

Recovery

Only through time and frustration did I realize there was something wrong with my thinking. I largely credit getting more involved with the development community as a whole with my real recovery. I think I was too isolated to come to the realization on my own.

Meeting other developers who I truly respected was the real turning point. Stephen Caudill, Chris Saylor, Bruno Miranda and Ryan Leavengood to name a few. These are all incredibly talented developers with varied experiences who’ve taught me the humility all true developers need to be successful.

The Ruby community as a whole deserves credit as well. These ideals are better expressed by this community than any other I’ve seen.

To be a good developer is to be humble. To realize you alone will not make a project successful. Sheer force of will doesn’t translate into a usable interface or a solid brand.

The part where I’m a bit of a contrarian

Shortly after the “Developers” post Jay followed up with “Civics not Cadillacs.” He’s absolutely on point with this post as well but, this one is more of a high-wire act.

Let me really abuse his car metaphor a bit.

What happens when you’re told the airbags and seat-belts should be considered a version 2 feature? How about when you’re asked to propose a stopping mechanism other than brakes with “I saw a promising solution on the Flintstones once” tossed in for good measure.

I know Jay wasn’t suggesting to abandon development best practices at the drop of the hat. I do think that it needs to be clear that some things a good developer just won’t sacrifice.

It’s our jobs as developers to balance the business needs and proper development. That balancing act needs to include extensive collaboration with the rest of the business.

They probably hate you already

Anyone that knows me in person knows that I’m very opinionated. I do tend to tone it down online though. I’ve written several blog posts and chose to scrap them because I worried I would offend someone. Many times it was someone I respected.

I did this because text and my questionable writing skills just don’t convey the tongue-in-cheek nature with which I want to deliver some of my thoughts.

Then I read “Losing Twitter Followers is a Good Thing” by Steve Bristol. Yet again, it’s another simple and obvious concept; just be yourself. I wish I knew why I need other people to blog about common sense for me to finally get it.

As a developer you’re paid for your opinions. Don’t be afraid to share them. Just have the common sense to temper them with the realities of the business while maintaining your integrity.

Simple enough.

I really don’t mean for this blog to devolve into Ruby’s BileBlog. The problem is, more talented bloggers than I seem to have the positive aspects of the Ruby community very well covered and I really don’t want to simply retread well-trodden ground. With that said, there are a few things that I feel like aren’t being shouted from the rooftops the way they should be. Here’s one of them…

Simplicity Rules, Hooray Shoulda

In my opinion, RSpec represents a huge improvement over Test::Unit. I have a thing for aesthetically pleasing code and RSpec’s DSL satisfies me.

Not all is well in RSpec land though. RSpec is a very complicated piece of code and we’ve experienced some very difficult to debug issues with it. For all it’s ugliness, Test::Unit works.

This is where Shoulda comes in. With a relatively small and simple code-base we’re getting syntactic sugar on top of Test::Unit that provides most of the beauty of RSpec.

More importantly, we get an extensive set of Rails specific macros which makes building specs for a Rails app far simpler. Most every Rails macro has a corresponding Shoulda macro.

Very DRY with a clean, easy to understand code-base. I love it. Also, this revelation of mine is a long time coming, many thanks to Bryan Liles and Steven Bristol for putting me in line.

I haven’t had a chance to use it in a project just yet but, I’ve done a lot of testing and research and am really looking forward to my future with Shoulda.

The title here may be a bit misleading, I just really wanted to play with the word “git.” This post will largely be focused on my issues with git.

RTFM NOOB

Git seems to be a new sacred cow. Any complaints are generally responded to with the assumption that the complainer is is definitely the one at fault. This may be attributed to the user’s stupidity or, more creatively, the user’s cleverness.

Most recently I’ve seen PJ Hyett tweet the following:

when people get upset at git, it’s because they’re trying to do something clever and bad things happen. stop trying to be clever.

This may in fact be true in some cases but, claiming this is always the case is foolish at best.

A Tangent on GitHub

Since I just cited one of the minds behind GitHub I thought I should give some thoughts on GitHub.

GitHub is pure unadulterated awesome.

In a way, GitHub is the antithesis of the mess that is Git. The guys behind GitHub seem to pay attention to every little detail of the user interface. Git’s user interface in contrast appears to be put in place grudgingly by the Git developers who are outraged that users even need to interface with their masterpiece.

GitHub seems to be the developer’s social network and I love it.

On User Interface

The most obvious flaw is the lack of consistency in the commands:

git stash apply git rebase --continue git svn clone git commit -a -m

Can we kindly pick one style? Either sub-commands (like apply) or options to commands (like –continue), pick one and stick with it. This reminds me of the inconsistencies in the function naming of PHP. I don’t want to be reminded of PHP, I have enough nightmares as it is.

Other notable issues are displaying files in conflict as “unmerged” instead of say “conflict” as well as using “git add” to resolve conflicts instead of something like “git resolve.”

Another Tangent on user Interface

It seems odd to me that a community obsessed with perfection and beauty the way the Rails community is would accept and in some cases, defend a tool like this.

As Ruby and Rails developers we all know interface, at all levels, matters. I’m also sure we’ve all re-factored working code because it was not idiomatic Ruby, in other words it offended our sense of style and beauty (yes, I’m simplifying the reasons for re-factoring ugly code, I know). So, I’m genuinely curious, when other equally powerful tools exist, what drove the early adoption of Git in the Ruby community?

Oh, There Are Bugs

Please, follow this and tell me what I’m doing wrong:

So, everything goes as expected until the conflict that happens during the rebase-ing of the branch to the latest changes made in master.

At line 50 you see me fix the conflict. I then verify the contents of the conflicted file on line 51. I add the file on line 53. Then I try to continue and the fun begins.

At this point I’ve fixed the conflict and added the file yet, git is swearing no changes have been made. When I first ran across this, it resulted in lots of research trying to figure out what I was doing wrong. Only after far too much time wasted on this did I get desperate and add some random whitespace and add the file again. Turns out this pretty reliably corrects this issue.

Another confidence inspiring issue is also rebase conflict related. Unfortunately, I can’t easily duplicate this issue so you’ll have to take my word for it.

Same circumstances, I fix a conflict and add the file. When I try to continue I get a different error message from above but still suggesting I forgot to use “git add.” Again, after much research and random attempts to move forward, I found “git status” fixes this and allows me to continue.

Yes, you read that right, a command meant to simply report the status of the repo is fixing my repo. It’s obviously updating something, somewhere deep in the .git directory that tells “git rebase –continue” that I have in-fact added the file. This is difficult to duplicate but, I have seen it several times.

“Rich, why do you hate Git?”

I don’t hate Git. I happen to think it’s a great tool and an unbelievable improvement over the tools we used to be saddled with. I just happen to think that there are tools out there that are just that much better than Git.

I’m also posting this because I got a few responses (both public and private) to my complaints on twitter acting like I’m an imbecile with no clue what I’m doing. I’m definitely not a Git power user, I’ll give you that but, I always make an effort to be familiar with my tools and the best practices involved. With my relatively simple usage, I shouldn’t be running into these problems.

The only thing tying me to Git is for compatibility with the broader Ruby community. I obviously don’t expect that to change but, we need to acknowledge issues with our tools and address them, not ignorantly ridicule the people pointing them out.

There’s a joke that I’ve heard several times over the years. I don’t think I’ve ever told it for a laugh, really just as part of a larger discussion. It seems to apply here.

What do you call someone who speaks three languages?
Tri-lingual.

What do you call someone who speaks two languages?
Bi-lingual.

What do you call someone who speaks one language?
American.

Now, as an American who speaks only one language, I feel kind of offended but, I do get the bigger concept of the joke. That concept appeals to me as a developer. I’ve always found value in being familiar with multiple languages and tools; it’s always made it easier to chose the right tool for the job.

While the ideas here apply to developers in general, being part of the Ruby/Rails community I’m going to focus on that community.

Observing the Herd

I’ve always been bothered by the disdain shown for “foreign” technologies by the Rails community. The two biggest being the database and JavaScript.

The cheers I heard at the RailsConf MagLev presentation to someone shouting “screw relational databases” represent this problem well. There were many interesting aspects to MagLev but, what I heard the most about was the potential to do away with relational databases and do everything in Ruby. This is only the tip of the ice-burg as far as hating relational databases in the community.

The impetus for writing this post itself was a friend and fellow Ruby developer tweeting “wishing i could write iPhone apps in ruby.” Hearing something along those lines is all too common.

There are obviously exceptions and I applaud those exceptions but, I’m not talking about them in this post.

A Crippling Love For Ruby

The Rails JavaScript helpers have always been a sensitive topic for me. I’ve honestly never used them beyond the prototype phase in a project. I’ve always tried to go the unobtrusive route and hand-code my JavaScript. I do use jQuery though, I’m a bit insane but I’m not a masochist. Put simply, I’m a web developer and JavaScript is the language for programming in a web browser.

Another sore spot is the database. The common Rails idiom seems to be to do everything in Ruby and to avoid things that can’t be expressed in Ruby. This can lead to incredibly naive implementations that would run exponentially better in the database.

Before I hear the bellows of “premature optimization.” Knowing your tools and using them appropriately is not premature optimization. Things such as triggers and stored procedures can be incredibly powerful and should seriously considered.

Even indices seem to commonly trip up seasoned Rails developers. I’ve heard of at least a dozen instances of an application being sped up simply by properly indexing the tables. It’s just plain sad that something as simple as an index turns into a real stumbling block. This happens because the database is seen simply as a necessary evil that can be ignored until performance demands giving it a little attention.

To be continued…

I have a lot more I could cover here but, I see this post as simply the start of a much larger discussion. So, what do you think?

This was my second RailsConf and the change in the community are stunning. Last year was all about “fuck everyone else, we know the way.” As a rule, I like this attitude. The problem was that it was applied to things such as “sound engineering” and “good ideas.”

Last year there was very little interest in alternatives. Alternatives to ruby, rails and rails’ ideology were all soundly shat on by everyone I spoke to. This year things like JRuby, Rubinius, MagLev, Merb and DataMapper all had solid showings, large crowds and lots of excitement.

Things have changed

The general tone was more accepting of new ideas. The Rails Core panel showed the trademark cockiness [well-deserved in my opinion] but, expressed finally openness to real valuable changes to things like ActiveRecord.

Not much in this world could excite me more than discussion of an identity map in ActiveRecord.

I also saw real excitement over the alternative Ruby implementations. I’m sure this has something to do with their massive progress but, it really seemed people were finally ready to hear new ideas. I didn’t hear a single person expressing anything but excitement about these project.

Everyone loves the enterprise…

…not just enterprise software, although there was actual praise for the concept of the enterprise (a big change in this community) but, more traditional software engineering ideas as well.

The keynotes by Joel Spolsky and Kent Beck were great. More surprisingly, I’m in the solid majority with that opinion.

I have arrived… kinda

I did a lightning talk on a JamLab project and it was very well received. There’s actual interest and there was almost no laughing. To be honest, I was shaking while giving my stupid little five minute talk. I’ve never talked in front of a crowd that big before. I definitely have a new found respect for the people that get up and talk for an hour.

In the talk “The Worst Rails Code You’ve Ever Seen (and How Not To Write It Yourself)” by Obie Fernandez he talked about my plugin for almost a whole 3 seconds and I felt like a 90s schoolgirl at a NKOTB concert.

I also worked much harder at meeting people and talking to people. I’m not a social person so, it’s not easy but, the awesome Oregon beers and meeting great people like Steven Bristol, Grame Mathieson and Jim Weirich made things a bit easier on me.

That reminds me

Jim Weirich, Joe O’Brien and Chris Nelson gave, what is in my opinion, the best “better your craft” talk I’ve ever seen. It was called “Dialogue Concerning the Two Chief Modeling Systems.” Words don’t do it justice, especially not mine. There’s a decent summary here but, it’s not just the content that made this talk a thing of legends.

More to come

I just wanted to get some of my initial thoughts posted. I have some more specific technical issues I want to mull over before posting about. I can’t say my level of excitement after RailsConf this year matches last year but, my hope for and interest in the community as a whole has grown tremendously. I need to try a pull my weight by contributing more.

A lot has changed since I started this blog so I think I need to give this a renewed effort. I’m going to try and temper my obsession with getting everything perfect. My previous approach to blogging has resulted in 4 published posts in 9 months and about 40 drafts. What a fucking waste.

So from now on the content will be significantly shittier than it was and far more frequent, like a stomach flu. Here’s to fresh starts.

An unoriginal weird idea

I needed to do something weird in a plugin I wrote. I needed two models to represent the same table. I needed models that act like views. I’ve seen plugins that try to accomplish that goal but they have one of two problems:

• Muck around with ActiveRecord internal data structures
• Are pretty much all or nothing (no way of getting at the whole table through a scoped model)

The second issue I could have hacked around.

The first is a show stopper for me. Ruby gives you a ton of power to monkey-patch but, I think those changes should be kept as close to the public API as possible and never ever directly manipulate internal (to what you’re patching) data structures.

One day this may be promoted to “bad idea”

So I wrote my own. I’m not even convinced this is of general interest. So much so that it’s actually part of a larger plugin I wrote, just an implementation detail of that plugin really. That said, if there is a positive response, I’ll wrap it up and spec it out properly. For now, I’m going to go the worst possible route for software distribution, uploading it as an asset for my blog. Classy, huh?

scoped_model.rb

Just a simple ActiveRecord::Base.send(:include, JamLab::ActsAsScopedModel) and you’re off and running.

Usage is exactly like #with_scope

class DumbUsers < ActiveRecord::Base
  acts_as_scoped_model :find => {:conditions => {:is_dumb => true}}
end

Now use the model as usual and the proper scope is used everywhere. It makes absolutely zero attempt to control the creation of records in any way. You can create a record using a scoped model that does contradict the assigned scope.

An important note, I’m not using this in production yet so, this may be riddled with bugs. If you do find any, drop me a line.

Some guy blogged about JRuby and CPython performance. For the most part he’s gloating that his stunning prediction that jruby would be slower than cpython has come to pass.

Get this man a Nobel…

Is there a single person in the Ruby, Python or Java communities that is surprised by this? At a minimum I’d argue that comparing Jython would be more appropriate but quite honestly, who cares? No one is using Ruby, or Python for that matter, for their blazing speed. It’s well known that both languages have speed issues and Ruby is definitely the slower of the two.

Hand tuned assembler may be faster than Jython

If you want speed, don’t use Ruby or Python. People aren’t turning to these languages for their performance characteristics. They’re using them for the sheer joy of working in these environments. I like both Python and Ruby, they have their strengths and weaknesses. In Ruby I find myself wishing for Twisted all the time. In Python it’s Ruby on Rails, I’m sorry Django, you’re beautiful but it’s really a personal style call at this point.

I can has pots and kettles?

Seriously, this is like a bunch of tortoises arguing who’s fastest. You’re all fucking slow compared to your competitors. Get over it and pick your fights more carefully. Focus on your strengths. The Ruby and Python communities have a lot in common and should focus on common ground instead of arguing who sucks at performance least.

updated The approach to staging deployments with Vlad in this post is ridiculously dumb and complicated compared to this one.

Recently I've been reading about Vlad the Deployer. Like many in the Ruby community I was a bit put off by how they've chosen to promote Vlad. Anyone who knows me, knows there's nothing I like more than a bit of well placed arrogance and trash-talking but, I figured Capistrano was fine so why all the big talk against Cap?

Then I looked inside the beast...

At this point I don't even remember why but, I looked through the Capistrano source. Now, I feel pretty confident in my knowledge of Ruby and software architecture in general but, the Capistrano source gave me a migraine. Don't get me wrong, it's very well written code, it's just architected in a way that only the original author could really feel comfortable with it (yes, I'm putting this far nicer than I usually would because I have tremendous respect for Jamis Buck, Capistrano's author).

I can honestly follow the Rails routing code easier than I can Capistrano but that's another topic for another post.

Rule #n+1: Use the tools you have

Vlad makes great use of Rake. By using one of the best Ruby libraries out there, they got a lot for free. For example, instead of special casing the before_* and after_* tasks, they used Rake's dependencies and it's ability to extend a defined task.

They also use the ssh command instead of Net::SSH. Net::SSH is a really interesting piece of code, especially as one of the few examples of dependency injection (via Needle) in Ruby. However, there have been issues with using Net::SSH in Capistrano. I'm not going to question the value of having a native SSH implementation but, I'm not entirely sure why Capistrano should use it when it can accomplish it's goals by shelling out to the ssh cli.

A minor contribution - Deployment Targets (ex. Staging Environments)

Nothing speaks louder than a contribution and I have a small but valuable one. While talking with Chris Saylor we came to the conclusion that implementing support for staging environments in Vlad wouldn't be all that difficult. With a little bit of research, on Rake not Vlad, I came up with this.

This should go in RAILS_ROOT/Rakefile

    namespace "vlad" do
      desc "Setup the deploy target overrides"
      task :target

      rule "" do |task|
        if task.to_s.match(/vlad:target:([a-z_-]+)/i)
          override_path = File.join(RAILS_ROOT, 'config', "deploy.#{$1}.rb")
          Kernel.load override_path if File.exists? override_path
        end
      end
    end

Thank you Geoffrey Grosenbach for the Rake version of method_missing.

With this code in place you setup your deploy.rb with your production config, as usual. You can also setup as many deploy.*.rb files as you like. Off the top of my head, deploy.staging.rb and deploy.qa.rb may be useful. These files contain the settings that differ from your config.rb. You would then use Rake's ability to chain commands.

config/deploy.rb

set :application, "example"
set :domain,      "example.com"
set :deploy_to,   "/var/www/apps/#{application}"
set :repository,  "svn+ssh://svn.example.com/var/svn/#{application}/trunk"

config/deploy.staging.rb

set :domain,      "staging.example.com"

Deploying to your staging environment from scratch:

rake vlad:target:staging vlad:setup vlad:update vlad:migrate vlad:start

Simple, easy to understand how it works and it's all standard Rake, no real Vlad magic involved.