Tag Archives: rails

Rewriting in Rails 5

I’ve been doing Ruby on Rails work again. Although my indie web projects are all Sinatra, I generally recommend to clients that Rails is the way to go. Rails will be easier for them if someone else ever needs to take over the project.

I don’t like using 2 products that do the same thing, though. That’s why I consolidated my web app hosting to Linode, and my source code to GitHub. Why should I switch between 2 frameworks, especially since Rails has matured so well? I’m enjoying Rails 5.

David Heinemeier Hansson said in an interview on Slashdot, about the rise of JavaScript front-end frameworks:

But it seems like that’s one of the lessons people have to learn by themselves. Just try to string things together on your own a few times and you’ll quickly get an appreciation for what Rails provides as a backend framework. We’ve had tons of programmers try just that and come back for refuge.

It struck home because I’ve had some regrets with choosing Ember.js for my new app. Part of that is my own lack of experience with the framework. But also I’m no longer convinced that the heavily JavaScript-based view layout of something like Ember.js is better than Turbolinks, for example. I plan to rewrite my app in Rails and more classic Ajax at the earliest opportunity.

Doug Engelbart and the pace of change

Dave Winer writes about Doug Engelbart and the pace of changing computing systems:

“If you want to get the most out of great developers like Engelbart, who are productive well into their 80s, you have to stop digging up the streets, moving the goalposts, bombing the cities, starting over just for the sake of starting over.”

While there’s certainly a time to burn the forest for new growth and opportunity, I have little patience for those developers who spend more time breaking old code than creating new value. Maybe it’s a sign I’m getting old — that I’ve lost my taste for innovation at a technical low level — but I don’t look forward to rewriting all my working code again and again.

Very little has changed in this regard since I wrote a blog post about deprecation in 2010, which (fittingly) also linked to Dave Winer.

Will paginate for food

As I mentioned in my “Rails rant last week”:http://www.manton.org/2009/01/rails_4_years_later.html, I have an unhealthy distrust for Rails plug-ins and monkey-patching gems. In addition to often breaking when you upgrade Rails, too many high-level abstractions can make it difficult to understand and debug the code later when things go wrong. For those reasons I will sometimes roll my own solution instead of using someone else’s. (As an aside, I rarely do this with Mac development, perhaps because I understand the internals of Mac frameworks much better than I do for the Rails core.)

But I’ve just been so impressed with the “will_paginate”:http://wiki.github.com/mislav/will_paginate plug-in. It’s fast and there are no obvious compromises — good out-of-the-box defaults and enough hooks that it can be customized.

If you are doing any Ruby on Rails work and haven’t checked it out yet, I think you’ll find that will_paginate is a very elegant solution to something every web app is going to need.

Rails 4 years later

Blog archives don’t lie. It’s been nearly 4 years since I first “blogged about Ruby on Rails”:http://manton.org/2005/02/the_ruby.html. (Three years and 10 months, but I’m not patient enough to wait until February to post this.) Here’s a portion of what I said back then:

“But the PHP people will switch, easily, and with the apparent momentum of Ruby right now, maybe it’s already happening. Forget the enterprise for now. Rails is a perfect fit for anyone who develops for the web on its own terms, and the people behind apps like Basecamp, 43things, and the upcoming Odeo match that profile.”

In that time I’ve increase my use of Rails. At “VitalSource”:http://www.vitalsource.com/ we have a bunch of Xserves running Rails applications. Mac developers have embraced Rails in the form of “PotionStore”:http://www.potionfactory.com/potionstore. Cheap shared hosts have been replaced with virtual servers, “many”:http://www.railsmachine.com/ with an emphasis on Rails hosting.

The community is huge now. What’s not to like?

Plenty! Here are my top gripes about Ruby on Rails.

Deployment. Ask anyone — even its biggest fans — and they will complain about deploying Rails applications. This stems from two points: the overhead to initializing a Rails application, meaning multiple instances have to be fired up and ready, unlike PHP which can process a script at a moment’s notice; and the path of ever-changing deployment strategies littered with the corpses of FCGI, Mongrel, Passenger, Thin, and more.

Upgrades. Rails matured quickly and is constantly improving. That’s great for features, great for best practices, and great for a clean API. The downside is that methods and entire chunks of the framework are deprecated and removed every major release. Forget about backwards compatibility. If you aren’t reading the blogs and keeping up with the latest changes, you’ll pay a price when it comes time to upgrade your application.

Attitude. David Heinemeier Hansson and the Rails core team have been outspoken in their lack of concern for end users. It’s because Rails is not actually a product. It was released and is open source to benefit the community and to grow the framework, but average developers should have no misconception that anyone with Git commit access is looking out for their application. I have great respect for Hansson, as well as the other high-profile developers of Rails, but it helps set expectations to underscore that Rails is not a supported product.

Java. Developers new to Rails generally come from the two other most popular web development languages: PHP and Java. Many leaders in the community come from that latter group, some of whom I count among my friends. Chad Fowler, in his “interview with Pragmatic”:http://www.pragprog.com/podcasts/show/19, spoke to the baggage that developers bring to a new platform. I think some of this baggage from a more “serious” architecture is leading to new complex abstractions, such as Capistrano. Whether fair or not, I also largely blame the Java developers for using tabs-as-spaces, which is evil. ;-)

Extensibility. The Rails team wisely made a conscious effort to limit the number of features in the core of Rails, instead preferring new optional features to be implemented as gems or plug-ins. The problem is that there are limited hooks to extend the framework. Ruby is great at dynamically extending classes that weren’t designed with extensibility in mind, but there is no gaurantee that one plug-in’s monkey-patch will continue to work in future versions. Ironically, “merging Merb”:http://weblog.rubyonrails.org/2008/12/23/merb-gets-merged-into-rails-3 into Rails 3 will bring better supported APIs for plug-in authors while no doubt breaking a bunch of old stuff.

Speed. I put this one last because I don’t actually think it’s as big of a show-stopper as many people think. Still, it’s true that Ruby is one of the slowest languages out there, falling behind Python, Perl, PHP, Java, and enormously behind compiled languages. ActiveRecord is great, but it also makes developers lazy and requires tweaking the defaults to achieve the same performance as hand-rolled SQL. Projects like “Rails Metal”:http://weblog.rubyonrails.org/2008/12/20/performance-of-rails-metal look very cool, though, so that’s a good sign for the platform.

Even with all these critiques, there is something special about Rails and I will continue to use it for many applications. But at the same time, any shame I used to have at using PHP is gone. If I need to do something simple, I will use a simple solution. As a sort of backlash against my frustrations with Rails, I built everything that powers Riverfold (order processing, admin interfaces, the “Wii Codes application”:http://wiitransfer.com/codes/ and Twitter services) off of PHP.

Fancy-pants productivity

There are a few things in this post by “Ryan Norbauer”:http://notrocketsurgery.com/articles/2008/02/26/mention-in-wired-piece-on-37signals (via 37signals) that bother me. One is this idea that “code is meant to be read by humans first and computers only secondarily”. I understand what he is getting at, but even though I respect new advances in productivity, we have to be very careful to keep our core priorities. There’s a word for when the balance shifts away from the user and more to us as programmers: selfishness.

Imagine two programs: one is ugly and hard to read, but it compiles and is bug-free; the other is beautiful and readable, and it also compiles and is bug-free. To the user they are identical. They both succeed.

Now take those two and give them both identical beauty and readability, but accidentally break one so that it either does not compile or runs so horribly buggy and slow that it is useless to everyone. Writing code for other programmers to read isn’t enough. You have to start with code that works before you get all fancy-pants.

This growing trend to raise beautiful code and programmer productivity above the performance or functionality of the final product is dangerous. The final product is what counts. Not how you build it, but what you’ve built: how it scales, how it performs, how it solves a particular problem.

And sure, there are many times when I write slow, lazy code that doesn’t work well. But that’s a compromise you make when you have to meet a deadline, or because you aren’t sure how to optimize yet, not because you start out by deprecating user experience. If you believe Ryan, it sounds like there is a whole “movement” of programmers who toss any potential performance achievements out the window before they even get started.

You can say that great products are complex, and so you need to focus attention on how the software is built and maintained. That is true. When I ported a large application from Carbon to Cocoa a few years ago I made the decision to do so because of future productivity.

You can say that happy programmers create high-quality products. That is also true. When I am feeling most productive I am usually enjoying myself because the work environment I’m in is encouraging.

But don’t put the practice of software development above the actual result, because to do so means you care more about writing code than solving problems.

Rails on shared hosts

“David Heinemeier Hansson writes in detail”:http://www.loudthinking.com/posts/21-the-deal-with-shared-hosts on the problems with Rails in shared hosts:

“Most Rails contributors are not big users of shared hosting and they tend to work on problems or enhancements that’ll benefit their own usage of the framework. You don’t have to have a degree in formal logic to deduce that work to improve life on shared hosting is not exactly a top priority for these people, myself included.”

Although I’ve been building Rails apps for a couple years, and will continue to do so, I made the choice with “Riverfold”:http://www.riverfold.com/ to go PHP-only so that I could deploy on inexpensive shared hosts and easily move my sites. Fact is, you need to dedicate a significant portion of your time to being a system administrator if you run a Rails site.

I find the general “we don’t owe you anything” attitude in the Rails community off-putting. What it means is quite simple: Rails is not a product, despite what it might look like when you “visit the web site”:http://www.rubyonrails.com/. This is fine and consistent with the opinionated nature of Rails (which from a design perspective is what makes Rails excellent), but it also means that features like backwards compatibility are not just ignored but actively discouraged. The message this sends is that the core team values their own personal productivity over the productivity of the general Rails userbase.

Also, make no mistake, the performance questions surrounding Rails are directly related to the web shared host issue. Rails can’t be hosted in the same way that PHP is hosted because it takes so long for a Rails application to be initialized, requiring dedicated long-running app instances and an ever-changing array of “best practice” solutions starting with mod_ruby to FCGI to Mongrel to “Thin”:http://code.macournoyer.com/thin/.

My friends and “co-workers”:http://www.vitalsource.com/ are no doubt sick of me bashing Rails (see “this post on the priorities of the community”:http://www.manton.org/2007/09/rails_and_mac_dev.html), but I still admire Rails and do want to see these problems solved. I would love to use “PotionStore”:http://www.potionfactory.com/potionstore to power the Riverfold site, or to base my registration database and sales tracking in Rails.

Rails and Mac dev communities

“Damon Clinkscales has a write-up”:http://damonclinkscales.com/past/lone-star-charity-workshop-wrap-up/ of the Charity Workshop that took place before the Lone Star Ruby Conference in Austin a couple weekends ago. I skipped the conference and attended these tutorials instead, enjoying some great talks by Marcel Molina, Bruce Williams, and 6 other speakers all packed into 4 hours. I definitely picked up a few good tips on Ruby blocks and ActiveRecord, but I was not-so-secretly relieved that I didn’t attend the full conference.

“Since brunch on Sunday”:http://www.flickr.com/photos/digitalnomad/1352583178/ after the conference, where I got to hear another wrap-up from co-workers, I’ve been thinking about why. Why did I sell my RailsConf ticket and book a flight to Chicago for C4 instead? Why skip a cheap Ruby conference practically in my own backyard? Why have I whittled my Ruby-themed blog subscriptions down to just a few from dozens?

Now I know: it’s about the difference in the communities. The Mac developer community is all about building unique apps, crafting an excellent user experience, and the “indie culture”:http://www.al3x.net/2007/08/c41-friday.html of building something small and useful. The Rails community by contrast seems focused on how few lines of code a controller method is. I’m lucky to work with people who care about that stuff, because it often does yield better applications, but I just don’t wake up in the morning excited about rewriting code, so why would I leave my family for a few days to hear someone talk about it?

There are many kinds of programmers. People who have hacked their whole life, dropping out of school to sell software; traditional developers with a CS degree and big company background; and even fine arts majors who fell into programming by accident as a way to build web sites. Based on that background, or what direction their passion takes them, I believe there is a balance between joy for the act of writing code vs. the pride in seeing the final product, and each programmer leans to one way or the other.

For Rails developers, at least many of the leaders in the industry who came from or were inspired by the extreme programming methodology and test-driven development, it’s the former: the art is found in the lines of code — how efficient can the logic be, how DRY, how RESTful.

For Mac developers, not just the “Delicious Generation”:http://www.rogueamoeba.com/utm/posts/Article/DeliciousGeneration-2006-11-06-10-00 but old school Mac developers as well, it’s the latter: the art is how the final product looks and behaves — being inspired to build something simply because you used another application that was great.

Cutting it this way allows me to see two things very clearly that were confusing before. It puts specifics to why I’ve drifted further away from the Rails cutting edge, and it explains why I get so annoyed with some of the newer crop of Mac developers who proclaim “bindings”:http://cocoadevcentral.com/articles/000080.php and garbage collection as beautiful gifts for programmer productivity even though they have no added value for the user experience.

Rails is a great framework, and I will continue to enjoy switching gears to write web apps in between my Mac projects. But I’m not going to tune back into that community until there is an equal focus on the bigger picture as it impacts the user (more scaling, more UI best practices), or whatever the next big thing to hit web apps ends up being.

RailsConf 2006

Airport sketch I attended “RailsConf”:http://www.railsconf.org/ in Chicago last month. There’s a lot of excitement in the Rails community right now, and it was nice to be there for the first year before it explodes to the even bigger event that the conference will be next year when O’Reilly takes over.

The talks were a mix of great to just okay. “Damon Clinkscales”:http://www.damonclinkscales.com/ provided a solid introduction to migrations, and even though he had previewed the talk for me the night before I still picked up some useful tips. I was finally able to hear first hand what a fantastic speaker “Mike Clark”:http://www.clarkware.com/cgi/blosxom is. James Duncan Davidson rounded out the weekend with a high-level “vision for deployments”:http://duncandavidson.com/essay/2006/06/webaspipe/. I also enjoyed presentations by “Paul Graham”:http://www.paulgraham.com/marginal.html, the music and brilliance of “Why”:http://redhanded.hobix.com/, the closing Rails core team panel, and of course “DHH on REST and embracing CRUD”:http://www.loudthinking.com/arc/000593.html. One of the nice things about open source is that soon after announcing the new ActiveResource framework, David checked in his code so you can immediately see “what he has been working on”:http://dev.rubyonrails.org/svn/rails/trunk/activeresource/ and play along.

As I look back on the schedule, there were many talks I missed completely, so I’m looking forward to catching the audio or video of some of those. Still, you could get a lot out of the conference just by talking to people between or during sessions.

While at the Austin airport, I filled a sketchbook page with random people waiting for the delayed flight. This man on the right was leaning against an abandoned ticket counter.

Mediocrity is the new application platform

Today marks the 4-year anniversary of this weblog. What better way to celebrate than with a discussion of web applications.

Willie Abrams said in a recent Campfire chat: “Web applications automatically have sync.” He hits on the fundamental principle of web applications popularity, and of course that has always been true. But the difference now is that some web apps are actually fast and usable too. (Gasp!)

The rise of rich web applications that seamlessly mix Flash or Ajax while still staying true to the roots of web architecture (REST design, open standards) has upset the traditional desktop market. I first wrote about this in “To-do lists and embracing the network”, which was in a sense a subtle wake-up call to Mac developers: adapt to the always-on internet or any college drop-out with a shared server will obsolete your app after a few late nights of Rails hacking.

But it frustrates me to see such praise given to web applications that, were they traditional, native apps, they’d be laughed away to obscurity or ignored. Ajax is a huge advancement, but that doesn’t mean that every application works well for the web. I’m sure Google engineers spent an incredible amount of work on Google Pages, but compare it to Apple’s iWeb and it becomes obvious how weak web application interfaces still are.

Luckily some people are working through the really tough problems. Ray Ozzie’s Live Clipboard may be the start of a whole new shift in web app functionality, allowing data to move between web sites and even out of the browser. But true drag-and-drop of structured data between a native app and a web site is still a long way off.

Let’s make some lists, starting with the good.

  • Good web applications are data-driven, multiuser, and use URLs everywhere.
  • There is some key component that is about the browsing experience. That might be sifting through large amounts of data, viewing old logs, finding people.
  • The kind of data requires an adaptable user interface, not something with a strict set of traditional widgets. HTML is perfect for this.

On the other side are web applications that might be built by a team of smart people and with a great technology backend, but the application concepts are confused. They don’t know if they belong in a web browser or on the desktop.

  • Mediocre web applications think that a single web browser window is an entire windowing system with movable child windows.
  • No features that actually have anything to do with the web. The result is that it adds no value to the web as a whole.
  • Trying to replace the whole Microsoft Office suite.

Something else is changing in the HTML/CSS/JavaScript platform. In 2004, Joel Spolsky wrote about how instead of picking Mac, Windows, or Linux APIs, developers are building for the web platform and can deploy to any user’s desktop. Cutting-edge web applications push that claim to its breaking point, as differences between Safari, Mozilla, and Internet Explorer often cause headaches for developers. It’s no surprise when Microsoft’s set of Office Live applications require Internet Explorer, but it is note-worthy when Google’s chat interface does not work in Safari. There is now a whole set of web applications that require the latest version of Mozilla and won’t work in anything less.

Five years ago we accepted that web applications were going to be useful but ultimately unfulfilling, joyless experiences. Now most web apps have risen from bad to simply mediocre. The truly great ones have a foundation and design that would still be unrivaled in a desktop app. These amazing apps are not content to reimplement an old application as a web app just to allow use from any machine, but they take it to the next step: rethink the problem, stay agile, and redesign so that it’s not just web-based, but it’s actually better.

Austin on Rails

Rails meeting photo About 20 people met at the Frog Design building downtown a few months ago for the first Austin Ruby on Rails user group meeting, and by the third meeting that number had doubled. Founders Damon, Robert Rasmussen, and Rob Jones have done a great job getting the group off the ground and lining up interesting topics.

Last night was our fourth meeting. Bruce Tate gave a talk on his experience ramping up a Rails team and comparisons to the Java world. As a new experiment on the agenda, afterwards some of us stuck around to hack together a member directory for the web site. I didn’t actively participate in the coding efforts, but I had a good time meeting new people. As usual, it was all followed by drinks at Hickory Street Bar & Grill, where topics of discussion ranged from refactoring to Perl to C++ windowing toolkits to AppleGuide. You know there’s some real substance to Rails when it brings together such a diverse group.

Also just announced: the Rails Happy Hour at SXSW. Should be fun.

Bruce Tate photo
Bruce Tate answers questions after his presentation