Trevor Burnham » coding

Haml 3 (beta) on Rails 3 (beta)

Trevor — Fri, 23 Apr 2010 03:12:43 +0000

[Note: This post will baffle my usual readers. I intend to bifurcate (trifurcate?) my blog into multiple blogs in the near future: one for development-related stuff, another for startup-related stuff, and another for personal stuff. Until then, I feel that I have a responsibility to help those Googling for solutions to the exact same problems that have been befuddling me in my life as a programmer; this post is entirely for that purpose.]

I love Sass, the stylesheet-generating cousin of Haml. It’s so much syntactically sweeter than CSS, it lets you define variables and mixins like this handy border-radius shortcut, and it works seamlessly in Rails. And Sass 3 is the best version yet, for a number of reasons. Meanwhile, if you’re creating a new Rails project, the Creator Himself has proclaimed that you should be doing it with Rails 3.

But right now, the installation instructions for this lethal combination don’t exactly parse. So here’s what you need to do:

Install the latest Rails (instructions here)
Install the latest Haml/Sass distribution: gem install haml --pre. (If you get an error, try updating RubyGems: gem update --system.)
Run haml -v and note the version number. Mine is 3.0.0.beta.3 (delightfully code-named “Classy Cassidy.”)
Create a Rails project, e.g. with rails ~/MyProject
Open up Gemfile in the project root and add the line gem 'haml', '3.0.0.beta.3', substituting whatever the version number was in step 3.

And that’s it! Running haml --rails ~/MyProject appears to be harmless but unnecessary. If I’m wrong about that, someone please let me know.

Related: If you want to get Ruby 1.9 installed on your Mac, I strongly urge you to use Homebrew. If you’re curious about how to set Rubygems so that you don’t have to sudo it, follow the instructions at this page under the heading “Fixing Rubygems.

Installing SciPy on Snow Leopard

Trevor — Mon, 22 Mar 2010 23:46:37 +0000

This is a post that will interest 0% of my usual blog readers, but I’m hoping that it will save some wandering Googlers much frustration.

Snow Leopard (Mac OS 10.6) comes with Python and NumPy already installed, which is great—except that the versions it comes with aren’t compatible with SciPy. I’ve spent several hours Googling around, trying to build things from source, etc. with no luck. Lots of people have had this problem. Turns out the solution is actually very simple. While I can’t claim credit for it, I can elaborate a bit:

Run the Python 2.6.4 installer. Yes, that really is the version you want. Trust me.
Run the NumPy 1.3.0 installer.
Run the SciPy 0.7.1 installer.

One more thing: The version of Python that came with your system (2.6.1 in /usr/bin) will still be around, and won’t have access to SciPy! What you want to do is run the new version from /usr/local/bin. To verify this, try the command import scipy from each shell.

May you enjoy doing science the Python way as much as I do.

Flicker-free Typekit

Trevor — Fri, 29 Jan 2010 01:26:22 +0000

[Update: On May 14th, 2010, Typekit finally announced an official solution to the “flash of unstyled text” problem. So, the fix below should be considered obsolete.]

I’m a fan of Typekit. Being able to go beyond the old Arial-Verdana-Times-Georgia paradigm, on any modern browser, without Flash (unlike sIFR), and with selectable text (unlike Cufón), is a dream come true.

One problem, though: It takes a few milliseconds to load up and render those fonts. That’s not so bad in itself; what’s bad is that the browser renders everything in non-Typekit fonts first, creating an annoying flicker every time the page loads as the text gets replaced by fancier fonts.

Fortunately, there’s a fairly easy solution (though not an officially supported one—see below). Just add this to your site body:


  
  <script type="text/javascript">
    document.getElementById('domain-com').style.opacity = 0;
    setTimeout("document.getElementById('domain-com').style.opacity = 1", 1000);
    Typekit.load('KIT_ID', {
      afterLoad: function(data) {
      	setTimeout("document.getElementById('domain-com').style.opacity = 1", 1);
      }
    });
  script>

Then substitute your actual domain for domain-com, and (important!) your site’s unique Typekit ID for KIT_ID. You can get this ID by logging in to Typekit, launching the Kit Editor, and clicking the “Embed Code” link; it’s an 8-letter alphanumeric combination.

Here’s a breakdown:

The ID on line 1 isn’t just a good selector; it’s good form. The most common convention is to use your domain (with a dash instead of a dot), which makes things easier for the Greasemonkey types.
The script include on line 2 brings in the Typekit description of your site’s kit. You can move this line up to your section if you want.
Line 4 makes your entire site disappear. Because this is at the top of your body, nothing is going to get rendered. It’s important that this line be here, rather than in another file or even at the foot of your body.
The call to Typekit.load does the actual loading of the fonts, and the afterLoad callback will be executed right after that happens. That’s when we want to make the body opaque again, right? Well, not quite. It seems that there’s a small delay between the callback and text refresh. Fortunately, using setTimeout to add a tiny delay (1ms) seems to eliminate this, finally ridding us of the dreaded flicker.

Caveat: The afterLoad event is currently considered experimental. An official solution for avoiding flicker is likely to be added in the future.

The Most Important IDE Feature

Trevor — Sun, 24 Jan 2010 21:46:44 +0000

Say you’re working on a project with hundreds of files. Changes to one file necessitate changes in others in an unfathomably complex tree structure. Using File -> Open each time you need to switch files is time-consuming, which is why simple text editors have been widely abandoned by programmers in favor of integrated development environments (IDEs) that offer tabs and a widget that shows the file structure at all times. This, more than syntax highlighting, is the reason why few projects are edited in Notepad.

But that’s still not enough. Why navigate the depths of a file tree when you can simply type the name of the file you want? This is the most important feature an IDE can offer. In Eclipse, it’s called Open Resource. In TextMate, it’s called Go to File. In Coda and Apple’s own XCode, it’s aptly dubbed Open Quickly, and goes one step further by performing full-text search on the files in the current project using Spotlight. Personally, I prefer the instantaneous of the Eclipse/TextMate approach; but either way, it’s certainly faster than using the mouse.

If you’re a developer who isn’t using this feature, find it. It will change your life at least as much as I’m guessing Quicksilver already has.

Smalltalk Lives!

Trevor — Tue, 05 Jan 2010 18:49:13 +0000

I was under the impression that these days, you’re more likely to find Smalltalk in the History department than the Computer Science department. That is, until:

I read a great interview with Dan Ingalls, the “mother of Smalltalk” (Alan Kay is the father) in the excellent Coders at Work, in which he discusses all the neat, fun things he’s been doing with the language lately, like Lively Kernel, a browser-based programming learning environment, and Squeak, which powers the One Laptop Per Child laptops, among other things.
I learned that Smalltalk powers DabbleDB. DabbleDB is a cool site that hosts spreadsheets in a much more web-like way than services like Google Spreadsheets, which are just trying to ape Excel in the browser (just as Excel aped Lotus 1–2-3, and Lotus 1–2-3 aped VisiCalc…).
All the other geeks interviewed in Coders at Work and Masterminds of Programming seem to like Smalltalk. C and its descendants (C++, Java…) get a lot of bashing, but Smalltalk is typically treated with unadulterated admiration. If languages were on Rotten Tomatoes, Smalltalk would be 92% fresh.

I don’t think Smalltalk is going to make a Big Comeback (newer languages like Scala are just too cool), but it’s definitely going to stick around for a while. And unlike the sticky, malodorous remnants of COBOL, I have no objection to the clean, classic scent of Smalltalk.

PHP Must Die

Trevor — Sat, 02 Jan 2010 17:35:28 +0000

Ruby" />I’ve been working on a mockup for Theoryville, and I wanted to throw together a server-side script to respond to some simple AJAX requests. My first thought was to do it in PHP, but then I remembered that PHP is the least elegant language in the world. So, I figured, I’ll do it in Ruby! I wrote what I needed, uploaded it to the Apache server, and I was done—except for the minor detail that Apache wasn’t running the code.

I figured that fixing the problem would be a simple matter of adding an AddHandler line to the Apache configuration. At worst, installing some sort of mod_ruby. No such luck. Turns out mod_ruby was abandoned many moons ago. The reason? Efficiency. Starting and shutting down an application every time someone makes a query is a stupid, grossly inefficient way of doing things. But guess what? For many applications, folks don’t give a flying fork how many processes they spawn. They only care about being able to upload something to their existing web space and have it just work.

Example: You could write a fantastic new blogging platform in Ruby, but would it have Wordpress’s Famous 5-Minute Install? No shell access required! Just upload it, go to the instantly available web interface, and tell it how to find your database. You know, the one you set up using phpMyAdmin?

Look, the Ruby community is rightly proud of Rails. I’m not saying that large or high-traffic web applications should run on PHP (though Wikipedia and Facebook somehow manage). But if you’re a Rubyvangelist, you need to fight on every front you can—including the just-upload-it-to-Apache front. It’s great that you’ve made installing and running a specialized web server take just 4 shell commands. But for most folks, that’s 4 too many.

Rubyists, I urge you: you need to bring back mod_ruby, for all our sakes. Anything PHP can do, Ruby can do better.

[Addendum: It’s worth mentioning that there is a solid mod_python, and it behooves all Apache administrators to install it. Also, I was able to rescue my Ruby script the old-school way: CGI. I added #!/usr/bin/ruby as the first line of the file and changed the extension to .cgi. I feel slightly dirty, but it works.]

[Update 1/9/10: While I thought the title was original (at least, to the extent that any hyperbolic title is), it turns out there was an excellent post also called PHP Must Die back in the dark days of 2004 about how Python and even *shudder* Perl are better languages than PHP. I took this fact as a given for this post. Via Hacker News.]

Always Be Exploring

Trevor — Tue, 29 Dec 2009 23:52:41 +0000

This post by math/CS prof Peter Boothe caught my eye:

What I am claiming here is not just that if you code faster, you will get your solution written faster. I am claiming if you code faster, you will get your solution done MUCH faster. The speedup is greater than linear.

I agreed with the sentiment, but I wasn’t sure about his explanation. Then I read this comment from Matt Kangas:

IMO, the key point is: teach exploratory programming.

That’s the answer! Here’s my experience: I took exactly one CS class as an undergrad; it was so arduous, so time-consuming, that I vowed to myself: Never again. But I kept being drawn to various programming projects, so I learned to code competently on my own time. At some point last summer, I think I hit the 10,000 hours of practice that Malcolm Gladwell posits as a heuristic prerequisite for being really good at something. One thing I learned around hour #7,500 was the importance of testing pieces of code independently as much as possible when building a larger project. Beginners always work at the application level: Change something, re-run the application, see if it works. This is sometimes necessary (if, say, you’re changing the UI), but should be avoided whenever possible. Experts tend to write code in small, unit-testable pieces. Many are test-driven.

Not every test has to be a formal unit test. Just trying out a line or two of code on its own and watching what happens is often useful. This is yet another reason why Java is dead to me as a language. Java is so slanted toward BDUF that when it sprang forth Athena-like from the head of James Gosling, it was blessed (?) with a formal standard for documentation, but no command line interpreter—a feature offered by just about every other language, including Java’s spritely yet statically-typed spawn, Scala.

For those of you building anything big enough for Hofstadter’s Law to apply, my #1 piece of advice would be this: Get your code tested, today!

Bridging the Web

Trevor — Mon, 28 Dec 2009 01:58:02 +0000

I’ve been reading a lot about programming languages lately. Many exciting new languages have come out in recent years, and the use of multiple specialized languages within a single project has become much more common, thanks largely to the polyglot JVM and .NET platforms. It’s an exciting time to be a programmer.

Unless, of course, you’re programming user interfaces for the web. Which everyone is.

As Jeff Atwood has said, “Everything that can be programmed in JavaScript will be.” That’s because the browser is the most popular operating system on the planet, and JavaScript is its lingua franca. But no one likes JavaScript. Or, more precisely, no one falls in love with JavaScript the way that people fall in love with Ruby or Python or (my favorite of late) Scala.

I never fully understood why JavaScript was so kludgy and inelegant until I read the (highly recommended) interview collection Coders at Work. Long story short, one guy at Netscape (Brendan Eich) threw the language together in ten days, with the stated goals of creating something semantically Scheme–like but syntactically Java-like. Good god!

So why are we still, 14-odd years later, still using the same language for all of our webapps? Because even if some backwards-incompatible NewScript were introduced, standardized and embraced by Microsoft, Mozilla, Google and Apple tomorrow, most people would take years to update to a browser sufficiently newfangled to run it. Heck, most people don’t even know what a browser is. Thus, new webapps have to be written in a half-baked language to be run through decade-old interpreters.

But there is a solution. And for all I know, Sergey Brin and Larry Page are already plotting its execution from their orbital battlestation. (Where did you think those Google Earth pics come from?) What we need is a new language for web browsers (or, better yet, a virtual machine standard that could support multiple languages), along with a compiler that can generate JavaScript for the benefit of old-timers. The project would be insanely difficult, but it’s half-done already. Look at GWT, which lets you write Java that compiles to JavaScript. Now suppose that a browser (say, Chrome 5) could run GWT’s Java bytecode directly, bypassing JavaScript altogether. Chrome 5 users would enjoy a much smoother and potentially richer web experience. Meanwhile, older browsers would still present a perfectly usable webapp. And programmers everywhere would rejoice.

That, I hope, is the future of the web. So please, Google, I urge you: Don’t let my children grow up in a world that runs on JavaScript.