Tag Archives: ruby

Core Intuition 234 and Vapor

We published Core Intuition 234 today, with a follow-up discussion on Swift, working toward software releases, and more. From the show notes:

Daniel and Manton talk about the question of Swift’s dependence on Objective-C’s dynamism, how it should or will evolve, and their differences in philosophy about Swift and Objective-C. They also take stock of release discipline and managing customer disappointment with an app’s progress. Finally, they talk about the importance and difficulty of winding down old products.

One of the points I brought up on the show — and which I’ve hinted at here on the blog before — is that web developers will push Swift to become more dynamic. There’s a long history of building web server frameworks like Ruby on Rails that depend on dynamically routing requests to controllers and views, and flexible models that automatically adapt from your database schema. These features tend to get messy when faced with a more static, strongly-typed language.

There is good work being done in the Swift web community already, though. Today I spent some time building a sample app with Vapor, which is probably the closest I’ve seen someone get to the usability of existing web frameworks. I’m a little more optimistic now that we might eventually have a single language for server code and native apps.

Swift and sharp knives

David Heinemeier Hansson has a great post today about Ruby’s advanced dynamic features. Some people would criticize Ruby (and Rails) for including “sharp knives in its drawer of features”, but David argues that it’s a worthwhile tradeoff to give developers such power and flexibility:

There’s nothing programmatically in Ruby to stop you using its sharp knives to cut ties with reason. We enforce such good senses by convention, by nudges, and through education. Not by banning sharp knives from the kitchen and insisting everyone use spoons to slice tomatoes.

Given the recent discussions from the Apple community, I couldn’t stop thinking of Swift as I read David’s post. I wouldn’t go as far as saying that Swift is a dull knife; there is a lot to like about the language, and I feel reasonably productive in it now. But David’s “paternalism” line nevertheless rings true to me, that the Swift compiler is trying to protect us from ourselves.

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.

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.

Ta-da List export to TaskPaper

I’ve been using “Ta-da List”:http://www.tadalist.com/ for the last couple of years for all my to-do lists. I have about 100 lists and love the speed of adding new items and some of the subtle smarts it applies to sorting recent lists and cleaning up completed ones.

But I’ve been on the lookout for a desktop app. OmniOutliner has become a bit bloated and all the Getting Things Done apps seem so structured. Along comes “TaskPaper”:http://hogbaysoftware.com/projects/taskpaper today and there’s a lot to like. The plain text file format is refreshing and nicely open.

I wrote a Ruby script to export all my lists from Ta-da into TaskPaper so that I can give it a proper workout. It makes a new document (with a single project) for each list it finds. Make sure to install “Hpricot”:http://code.whytheluckystiff.net/hpricot/ first — there’s no official Ta-da List API so we need to parse HTML a little.

Download: “tadalist_taskpaper.rb”:http://www.manton.org/software/scripts/tadalist_taskpaper.rb

Instructions:

  • Open the file in your favorite text editor and change TADALIST_HOST to whatever your account is.

  • Make sure Safari is running and you have logged into Ta-da. The script reads the cookie value from Safari’s Cookies.plist so that it doesn’t need to simulate a real sign-in.

  • Run from the command line. It will create the new files in the current directory.

  • You will see short status messages for what it is doing. It’s broken if there are any Ruby exceptions.

Enjoy!

RubyCocoa

I write Mac software, but over the last year I’ve increasingly been building Ruby on Rails web apps as well. Today I finally took a look at “RubyCocoa”:http://www.rubycocoa.com/. I wanted to whip up a quick Cocoa app that would involve some text parsing, and a dynamic scripting language like Ruby is a much better fit for text processing than C, C++, or Objective-C.

It turns out RubyCocoa works amazingly well. I have only scratched the surface with a small test app, but I was blown away by its ease-of-use, Xcode integration, example projects, and apparent maturity. You have full access to AppKit from Ruby-based controllers and views, and a single NIB file can even reference both Objective-C and Ruby classes. Fantastic stuff.

I don’t know if it’s ready for commercial software use yet. For distribution, I tested including the RubyCocoa.framework inside the application package and the app launches and runs correctly on a system without the full RubyCocoa install. There may be issues with requiring a recent version of Ruby, but otherwise it’s a fully native app.

My only disappointment was in the Objective-C calling conventions. There are two versions to choose from: a style using underscores to separate named values, and a slightly easier Ruby syntax using symbols and extra parameters. Here they are:

Objective-C:

[my_window setFrame:r display:YES animate:YES]

Ruby Underscores:

my_window.setFrame_display_animate(r, true, true)

Ruby Symbols:

my_window.setFrame(r, :display, true, :animate, true)

In my opinion, a better approach would be to take advantage of Ruby’s trick of allowing the last parameter to be a hash supplied without the curly braces. This feels more readable to me and more closely matches the Objective-C equivalent.

Better:

my_window.setFrame(r, :display => true, :animate => true)

In any case, that’s a minor complaint and doesn’t take much away from the beauty of writing native Mac apps in Ruby.