Nimble Code: Tag ruby

Rails Under the Knife

harrisj@nimblecode.com (Jacob Harris) — Thu, 26 Jul 2007 18:20:00 -0700

After months of rehearsing and revising, I finally gave the talk at OSCON. I think it could use another month of refinement, but people seemed to enjoy it, and I actually enjoyed giving it as well. If you were at the talk, thank you for coming and feel free to let me know if you have any feedback or questions.

My talk was Rails Under the Knife, a look at the some of the internals of Rails to get a better idea of 3 powerful Ruby techniques:

Metaprogramming
Reflection
Blocks

You can download the slides at

http://s3.amazonaws.com/harrisj-share/oscon2007.pdf (5mb PDF!)

This talk is aimed at an intermediate Rails programmer who knows the basics of Rails coding (I have another similar talk for beginners called Rubyisms in Rails), but still is a bit unsure about the power trio of serious Rails hackery. Hopefully, this will help to provide some inspiration for you to delve into the Rails code on your own. Enjoy.

Packaging Your First Gem With Hoe

harrisj@nimblecode.com (Jacob Harris) — Wed, 10 Jan 2007 14:36:00 -0800

My name is Jacob Harris, and I am a rubygem addict. I’d estimate I have hundreds of them tooling around on my hard drive, useful little snippets of Ruby or C library wrappers or random noodlings. I might not actually use most of them in any of my projects, but like a vast library of unread books, I enjoy having them around. But for the longest time, I’ve been a freeloader. I’ve downloaded gems, but I’ve never written one, but it’s time I start giving something back.

And so, I’ve written my first gem. It’s nothing incredible – all things have to start simple – but I like it. It’s called Amazon Hacks and it consists of two classes (for now) to benefit people whose sites handle Amazon links. The Amazon::Hacks::Link class contains a few methods to extract an ASIN from any product link, normalize product links, and append an affiliate ID easily. The slightly sillier Amazon::Hacks::Image class puts a convenient Ruby wrapper around the convoluted syntax Amazon uses for its image transformation engine. If you work on a site that links to Amazon product pages (e.g., All Consuming), try it out and let me know if it works for you or it can be improved. It’s simple to get started, simply run

gem install amazon-hacks—include-dependencies

Which brings me to hoe. Last night, I gave a talk on hoe to the NYC.rb group and the slides are here if you want to learn more about the process.

Building Your First Gem With Hoe

Before last week, I had no idea of what it takes to create a gem, but it seemed like a lot, and I had better things to distract myself with. And it does indeed require a fair amount of busy work, what I call administrivia, to turn your snippet of Ruby code into a packaged gem, and this work has to be started anew for each gem you want to create. Now, as pragmatic programmers, we learn to automate menial tasks whenever possible, and hoe makes the creation of gems a lot more manageable by automating the busy-work away via a set of useful rake tests. The result is more time for coding, faster releases, and more likely you’ll release that gem in the first place. So, give hoe a shot, learn about gems, and start writing gems. You’re a brilliant Ruby coder, it’s time to share it with the world. And when you write that gem, I’ve got a cherished spot on my hard drive for it.

Or You Can Cheat

harrisj@nimblecode.com (Jacob Harris) — Wed, 27 Sep 2006 13:08:00 -0700

Wow, long time no blog. Work and home life have just sucked all the mental energy out of me lately. For those of you who still have kept me in your feedrolls or click here from time to time, I have a new set of slides presented for your personal enjoyment.

Last week—transfixed by the horror of an empty slate of speakers—I decided it was time to give another talk to the NYC.rb and so I spent a few days throwing together a presentation I titled Or You Can Cheat. It’s all about how you can write C extensions for Ruby and also how this something you shouldn’t undertake lightly. I have a very interesting approach to presentations: when I want to learn more about a subject, I throw together a presentation on it. I think the combination of casual interest and the abject fear of humiliation in front of my peers is a great personal motivational tool. This talk continues that trend, and while I can not claim to be a definitive expert on C extensions for Ruby, I certainly know a lot more about the subject now and I think you will too.

If you are interested, you can download the talk here

Or You Can Cheat (600K PDF)

This is a bit more silly and off-the-cuff than Rubyisms in Rails, and I really enjoyed it. There are a few references I should clarify though. First, there is the matter of arepas. The arepa is the official food of NYC.rb and it is a rite of passage here to take visiting Ruby eminences to our official supplier, the Caracas Arepa Bar. Asides from being addictively tasty, arepas serve as a perfect metaphor for Ruby extensions, in that they wrap the tasty ingredients inside a pragmatic corn flour shell. They really are that tasty. Yes, I also suppose I was a bit harsh calling Joel Spolsky a troll, but I had no other term to describe his wild extrapolation that current Ruby interpreter performance augurs that Ruby will always be slow, that Rails is a horrible web development framework, and how you should shackle your entire development environment around the slowest part. But he is right that Ruby currently is slow for some uses, and C exensions are a potent way to resolve those edge cases without throwing in the towel.

And yet, I hope you’re not dropping everything to write them.

Why the lukewarm recommendation? Well, I think Ruby performance has become an all-purpose scapegoat these days. In some cases, this is deserved (we need YARV. Now.), but it’s all too easy to blame Ruby when the real problem is your web server, your database, or some stupid algorithm you wrote that’s wildly inefficient. Rule all that out first before you dive into C extensions for Ruby. Because C is dangerous, C is tricky, and C is just plain no fun. C extensions can be like eating an arepa filled with broken glass if you aren’t careful. But they also are a useful tool for performance and especially for wrapping existing libraries and legacy code.

Which gets me wondering if there are any cool killer apps for C extensions and Ruby. Are there some cool open-source libraries that would be nice with Ruby bindings? How cool would could a combination of Starfish and RubyInline really be? Would we need to use C extensions to create rbsh, a Ruby shell? What other fun things could you do if you had nice Ruby tongs to keep that nasty C code at bay? Let me know if you have any awesome ideas and if you enjoyed these slides. And in return, I’ll try to see if I can actually blog again one of these days. Thanks.

Rubyisms in Rails Redux

harrisj@nimblecode.com (Jacob Harris) — Wed, 02 Aug 2006 09:46:00 -0700

self.promote!

I am pleased to announce that the digital shortcut PDF version (to purchase, you have to go to the Digital Shortcuts page or you can buy it from Safari Sorry!) of my Rubyisms in Rails presentation is finally available for purchase. At 54 pages in length for the low price of $9.99, I guarantee you’ll glean at least 18.5 cents of insight from each page (disclaimer: that’s a mean instructional value; although gorgeous, the title page is not particularly educational in itself).

In addition, the book is also now available in Safari Books Online, and possibly Amazon or other retailers as well. Also, be sure to check out the list of other upcoming Ruby titles.

So, what’s in it? If you’ve read the original presentation, you already have a sense of the scope of material I am covering here, but the shortcut allows me to focus on the material in greater depth. The result is a richer and more thorough examination of the examples presented in the original slides. If you are an intermediate to advanced Rails hacker, you probably know all this stuff already. But if you are a newcomer to Ruby through Rails, or you still find yourself still stuck coding PHP or Java-like Ruby, this ebook might help to align your thinking to the Ruby way.

Will I write another ebook? I’d say yes, but I’ll have to think up another interesting topic. But if you are ever thinking of creating a technical book, I’d recommend starting in a smaller dose like this first. As I discovered, even 54 pages can be a lot of work, and it’s better to test out your time commitments and abilities with something small before you start pitching large references. But that’s a topic for another blog posting. Make me happy: Buy the ebook or read it on Safari and give me your feedback. Thanks!

Update

Fixed purchase link to be go to Shortcuts page (where you can add to cart).

Rubyisms In Rails

harrisj@nimblecode.com (Jacob Harris) — Tue, 25 Apr 2006 10:44:00 -0700

In an apparently blatant attempt to be more like Amy Hoy, I’ve decided it’s time I did some Intro to Rails writing. Tonight I’m going to be giving a little talk on what I’m calling Rubyisms as seen in Ruby on Rails. I think one of the things that makes Rails so cool is how it is built upon some of the best aspects of Ruby’s style: duck typing, symbols, blocks, and metaprogramming. And yet, I think many newcomers to Rails don’t really notice some of the magic going on behind such simple declarations as

<% 30.minutes.from_now %>

or more complicated Rails cases like

class Review < ActiveRecord::Base
  belongs_to :article
  validates_presence_of :author
end

My humble little slideshow goes out to those Rails newcomers hacking code to look like PHP or Java. The conceit is to use some sample Rails code as starting points for deeper explorations into some of the Ruby coolness lurking inside Rails. This is a nice little look under the hood, but I hope it will educate people new to Rails on how to embrace Ruby style for cleaner and cooler code.

I’m posting the slides early for some last minute feedback and I might update these files if any other errors are found. I’d like to thank NYC.rb compatriots Sebastian Delmont, Ryan Raaum, Trotter Cashion, and David Black for their help and corrections as well.

The presentation itself is two parts. I’m releasing it here in two style. The light version is stripped of interstitial chapter screens and is a lot easier on the bandwidth:

PDF Version
Flash Version (Note: Flash version is cutting off bottoms of some slides)

If you like what you see there and want to get the version I’m presenting with images, the full 2MB PDF dump is also available:

Huge PDF Version

Anyhow, I hope you enjoy my little presentation, and as always feedback and corrections are welcome in the comments.

Update (8/2/06)

This presentation is now available for sale as a digital shortcut from Informit (54 pages, $9.99). Please see my Rubyisms Redux for a small pitch and purchasing links. Thank you!

Stop Kicking The Enterprise

harrisj@nimblecode.com (Jacob Harris) — Fri, 06 Jan 2006 13:13:00 -0800

I have to agree with Obie Fernandez when he complains in his posting Enterprise Is Not An Insult about some of the recent derision directed at the Enterprise lately from the avant garde in the Ruby On Rails community lately. The problem is most of the mockery comes over a misunderstanding that “enterprise” means “insanely large”, which Obie points out is completely different from any definition used by people who actually work in enterprise software:

Plenty of us say “enterprise” when referring to internal-facing systems written by corporate IT departments and it doesn’t carry a stigma for being too large or too small, too simple or too complex. Enterprise projects might be large, take years, straddle business units and have global effects or they might be small, departmental efforts with only a handful of end users. So many factors influence the success of enterprise software in a given organization, only few of which have anything to do with technology.

Yes, there are large products that call themselves “enterprise-class software”, but that doesn’t mean that all enterprise software has to be big, slow, and hard to develop. But unfortunately, mocking the state of enterprise software has become an oft repeated dumb joke lately. This is like when a comedian throws out a laugh line – like slamming Microsoft or calling France “surrender monkeys” – to get a quick laugh; it’s funny at first but soon loses its novelty.

Giving a definition of my own, “enterprise software” means “business software.” All businesses want to increase their profits, and they do that by reducing inefficiency (ie, “we can track all of our operations within Excel”) or expanding into new niches (ie, opening overseas offices or offereing new business). Enterprise or B2B software – whether shrink-wrapped or custom – is what helps them get there. The best enterprise software becomes as essential as the CEO or infrastructure to a company’s success. And smart companies look to develop such software as quickly as possible, both to increase their profits quicker and gain advantage over their competitors. Yes, there is slow and clunky enterprise software, but there is also lightweight and rapidly developed enterprise software too. Speaking from personal experience, at Alacra, we work with a lot of vendors both large and small, and I can assure you that agility and profitability are far more important than slavish adherence to some awkward and enormous toolkit. Consider that the agile methodologies of Extreme Programming and Scrum were first heavily used in such large enterprise environments as Chrysler and Honeywell respectively. And I would argue that the success of such radically-new-at-the-time technology like the Web, XML, or Java was entirely due to the B2B community recognizing their value early and embracing them fully.

Which is why I think the jokes have to stop; does Rails want to continue to present itself as a niche tool for small B2C development or does it want to be a B2B player? Why have we gone from Rails does too scale! to Uptime is overrated? Yeah, 99.9999% uptime is overkill for almost all software, but if you’re going to sell to business you shouldn’t mock people if they want 99% uptime. They’re not whinging; they want to make your product an essential tool for their business. And so I think Rails needs to embrace enterprise needs. I think David is right to resist such code additions to the core, but I think it has a place in third-party contributed plugins and code snippets. To be an enterprise player, people will want to plug Rails into working legacy database schemas, handling composite keys, potentially even interfacing with back-end service-oriented architectures; maybe even hacking lightweight support for such horrors as SOAP or CORBA. And I think such work is what Rails needs to really succeed. Maybe you think it’s selling out, but I’d rather see Ruby in the enterprise than C#. There is a middle ground between obscurity and (code) obesity; let’s not mock people for trying to find it.

I'm Finally With The Cool Kids

harrisj@nimblecode.com (Jacob Harris) — Thu, 05 Jan 2006 20:11:00 -0800

It’s been an excellent week for my geeky self-esteem, with beta invitations to both Ma.gnolia (a new bookmarking site) and Measuremap (a blog statistics tracking program). Both are written in Ruby on Rails and both look pretty awesome. That’s all I’m going to say (not sure how much I can legally say yet), but I will close with the observation that there’s an energy for new projects on the web I haven’t seen in years and that the Ruby on Rails community is one of the nicest and most open I’ve ever seen.

Ah well, two down, approximately 100 to go.

Rails and the Distribution Question

harrisj@nimblecode.com (Jacob Harris) — Tue, 23 Aug 2005 01:43:00 -0700

I like Ruby on Rails a lot. It’s a pretty awesome web development frameworrk and it’s generated a serious amount of buzz for its young age (just over a year). One major milestone that’s ahead for the language will be a 1.0 release that among other things promises to deliver more API stability than there has been with more recent releases (as well as freeing developers and writers from creating code that’s partially outmoded on arrival). Will that mean though that the big development work for Rails will be done? Hardly. If Rails is really to succeed as a development platform, I believe it can only happen if the distribution problems are solved. And Rails 1.0 seems to be a necessary precursor to that.

I like to think with web application frameworks there are 3 Ds that are important for the platform to succeed:

Development – how easy is it to develop?
Deployment – how easy is it to place on your own servers and systems?
Distribution – how easy is it for third-party users to deploy on their servers?

I think Rails has done very well in the first case. In the second case, I think tools like Switch Tower will help to make the second problem as nice as the first. But I think the third problem is the most problematic in Rails right now. Essentially, there are no nice and standard ways for developers to package up their Rails-developed programs for other users to easily install (without Rails experience).

Let me give a concrete example here. As you may know, I recently switched this blog from Wordpress (a PHP-based service) to Typo (a Rails-based service). I currently am hosting on Textdrive, which is rare among hosting providers in that it supports the latest Rails versions, so at least I did not have to fight with my ISP to get Rails as an option. But even then, I must admit that Wordpress’ setup was a dream to use, and not knowing a lick of PHP, I was able to get a blog up, installed, and running in no time. In contrast, I do have some knowledge of Rails, but Typo was definitely harder. For starters, I had to manually create tables in a MySQL database by running a MySQL file to create the tables (good thing I didn’t use one of the more obscure adapters like MS SQL that didn’t have a manually written schema file for them). I had to go an edit the database.yml config file manually in a shell (not confugured via an install script) Importing the data from Wordpress was a bit difficult too, and I had to fix the import script. Finally, I discovered that I have actually been dispatching Rails methods with the FastCGI dispatcher, even though I’m not using it currently. So, my blog went down over the weekend and I didn’t know. Not good.

This is not to trash Typo, which is a truly excellent product. Nor is it to condemn Rails, which is still too young to even explore a thorough solution to the distribution problem yet. But I think if we start thinking about the future of Rails, the distribution problem is important, because without easy distribution, Rails will be doomed by the network effect. What do I mean by that?

There are a lot of PHP developers out there these days, far more than develop for Rails, Django, Seaside or some of the other frameworks out there. Why? Is PHP a better framework? Arguably no. But is PHP in a whole lot of publicly deployed web products, like Wordpress? Or more wikis than you can shake a stick at? Yes. This in turn leads to more people thinking of developing in that language, books being written, etc. which accelerates adoption of PHP even further. The network effect.

I think 37 Signals, Robot Coop and such have done a lot to advance Rails over the last few years. But ultimately, I think it’ll do more to sell their particular style of visual design than Rails as a development platform. Sure, there are people making custom solutions from scratch that might be wowed by the backend magic that makes it all happen. But I think there’s a bigger pool of programmers who might find themselves having to setup a quick Wiki for their intranet or such? Given the choice, how many of them will write a system from scratch in Rails? And how many of them will just grab an existing PHP-based solution? And once they’ve done the latter, how likely is it they’ll look at Rails ever again? The best way for Rails to grow is for there to be many Rails apps to choose from. And to get there, Rails needs to make distribution as easy as development.

(I hope to follow up on this in a few days with some further observations and ideas.)

Moved to Typo

harrisj@nimblecode.com (Jacob Harris) — Thu, 11 Aug 2005 02:50:00 -0700

Just wanted to note that I have moved this blog to Typo, an excellent blogging system written in Ruby on Rails . If you’re not reading this in an RSS reader, the change should be pretty apparent, although I must apologize for not having rethemed yet. Otherwise, I look forward to hopefully spending more time blogging and less time doing maintenance in the future.

Extracted Standards

harrisj — Mon, 02 May 2005 21:39:00 -0700

Still busy, but there is a great article at O'Reilly Radar on how great frameworks are sometimes extracted wholesale from successful applications rather than built from scratch up. That is, it's often better to extract the framework from the application, rather than build the application on top of a framework:

That is, at 37signals, they try to design the usability and function of the application first, and that drives the implementation. And if they can then extract a re-usable framework, all the better. For example, basecamp wasn't built on top of Ruby on Rails. Rather, Ruby on Rails was extracted from basecamp.

This echoes some of the complaints I was making earlier about the unwieldiness of SOAP for web standards. And it fits in with the philosophy of nimble technologies perfectly. Create a product, solve a need, and make it work great and the frameworks will follow, but complicated frameworks in themselves solve nothing.