John Cromartie's Tumblr

Insane. And not in a good way.

James Johnson posts a “beginner’s” guide to getting a modern Rails environment up and running, in Rails and Web Development - Take the First Step.

(note: I’m not really trying to poke fun at the tutorial here… the point is that the tutorial is actually mostly accurate: please read on)

Don’t people realize that this is crazy? The steps seem to be as follows:

1. Buy a Mac.

   It’s OK if you don’t have one. They are cheap on Ebay! It will only cost a few hundred dollars to get an old computer to write Ruby like a cool kid. If you want to use Linux, sorry, you’re kind of on your own.

2. Install Xcode.

   We really just need some of the stuff that comes with Xcode. But we’ll just say we need Xcode for brevity. Just download this 1.6GB package and you’ll be rolling along in no time!

3. Open the Terminal.

   Don’t worry about what it is or where it resides on your computer. Spotlight will find it for you. And don’t worry about what you’re going to enter into it. Everything will be fine. Trust me.

   We won’t accidentally delete your home folder or anything like that.

4. Install a package manager.

   What’s that, you ask? Don’t worry about it!

   Just copy and paste this code into your terminal. It will download and evaluate some code that someone posted on a website. It’s fine. Trust me.

   Oh, and if the code that we just blindly downloaded from a site on the Internet asks you any questions? Just hit Enter to say OK.

5. Now install the Ruby Version Manager.

   “But we just used Ruby to download and evaluate some random code from the Internet”, you say? How astute! Yes, you already have Ruby. But you have the wrong Ruby.

   Trust me. You need a new version of Ruby. And you need extra software to juggle all of these Rubies. It’s fine. Everybody does this now.

   And we’re going to run more code straight from the Internet now. Except, this time we’ll feed it straight to the shell. It’s OK. It’s from Github.

6. Now just use an editor you don’t know to open a file you didn’t know you had, to add some code you don’t understand.

7. Now quit the Terminal and re-open it for some reason.

8. Now install that other Ruby we talked about.

   Yes, yes, I know we’ve already been using Ruby in half of these steps. But like I said, we need a new Ruby. Just copy and paste a few more things. They’ll do stuff. It should be fine.

9. Update your gems… whatever those are.

10. Install Rails.

11. Install Bundler (this is something you don’t need; but you’ll need it).

12. Now make a Rails app and run some code that will create about a billion different files that you don’t need to understand.

13. Migrate your database.

    Don’t worry about what a migration is, or where your database came from, or where it is now. It’s fine. Just rest assured that there’s a database somewhere.

14. Start the server and enjoy!

    You’ve touched compilers, blindly downloaded code, modified your environment, installed a parallel version of Ruby, created a CRUD application and an accompanying database (and data model!), and started an application server, all without understanding a single thing!

    You can use that editor you don’t know how to use to look at files that you don’t know the purpose of.

OK. So this got really sarcastic really fast, and maybe a little nasty. Sorry if I have offended, James. I really commend the effort to get folks into programming. I really do. I want to see people programming, and learning to program. But I also want to see them understanding. And I don’t like to see people starting out on a massive undertaking like this with a “hand-wavy” approach to all of the steps.

But again, my point is not to criticize the intentions here. My point is to criticize the astounding complexity and the piles of “magic” involved in getting up and running with a web framework that’s supposed to be the easy one, out of the bunch.

The only thing I’d change out of all these steps is to recommend an easier text editor. Otherwise it’s pretty much correct about what you have to do to get up and running, and to not be in total isolation from the rest of the Rails world. If you develop a Rails app of any size at all, you will be juggling Ruby versions, gem dependencies, plugins, etc..

And that’s crazy.

After downloading gigabytes of software packages and hundreds of thousands of lines of Ruby code, creating an application and a database, you still haven’t even touched the Ruby language, or any programming concepts.

Stay tuned, and I’m going to see what I can do about this…

The passing of Steve Jobs is a really big deal. His contributions to computing made a big impact for me, personally.

We programmed Apple Logo on Apple IIGS computers in the computer lab in 3rd grade. It just “clicked” with me, and nearly 20 years later, I’m still programming (and I have actually come full-circle and picked up Lisp; it turns out Logo is a Lisp). In after-school programs, I tinkered with more advanced (classic) Macs and Hypercard.

After Jobs’ influence had waned, while Apple was cranking out ambiguously-numbered Quadras and LCs and other forgettable machines, I dabbled in programming for DOS and Windows, but nothing stroked my curiosity like those Apple machines. I remained a “computer guy” but nothing much of a programmer.

Fast-forward to high school. I remember the afternoon, waiting with bated breath for OS X 10.0 to be installed on a salvaged Power Mac G3. The UNIX core and NeXTSTEP-descended interface of OS X was the most exciting thing (to me) in computing for a long time. I somehow arranged for a Power Mac G4 as an early graduation present and dove into Xcode, and programming shell scripts, PHP, Ruby, Objective-C, and anything else that I came across.

The promise of being able to make apps that looked like slick Apple apps was motivation enough to learn Objective-C, Cocoa, and Xcode. OS X lit the fire under me to get coding again, and OS X (and attendant hardware; secondary for me, really) have been a constant companion ever since.

So thanks to Steve Jobs for stoking the passion of my hobby and my career.

I found the existing tutorials for using Flixel with MXMLC lacking, so I created this guide. I hope it’s useful.

Yesterday, in his speech at a next-generation car battery factory in MI, President Obama asked people to support passage of patent reforms necessary to enable innovation. My first instinct was to cheer this seemingly out-of-the-blue revelation, assuming that the administration had been paying attention and was advocating the kind of patent reform we actually need to ensure unfettered innovation.

I was wrong.

What Obama actually meant was that we should support passage of the Leahy-Smith America Invents Act. This joke of a reform has already passed the House and is on to the Senate.

Others have summarized the problems with this bill better than I can, so I’ll leave you with these:

• Litigation & Trial analysis
• Lauder Partners analysis

Please contact your Senators and tell them that you do not support this regressive “reform”.

So, a full week after my post last week, and with a good portion of Hacker News waiting to see if I’d actually follow through, I’ve got something.

Smarter Seating

My initial plans were for something not even remotely related to what I put together in the last 24 hours. I spent a good number of hours in my spare time (driving my wife crazy, by the way) building something that I ended up abandoning at the last minute.

What I ended up building was based on a problem that a friend brought to me a few months ago. His wife wanted to seat a whole mess of kids based on the fact that many of them did not get along, or otherwise indicated that they did not want to sit together. I played with the algorithm just for fun, and my friend passed on the suggestion to build a web app.

So, here we are. I’ll post more about the development process later, particularly the experience of using Clojure for web development.

I really enjoyed patio11’s AnyAsq, especially this part:

My most important bit of advice: LAUNCH. Asking me questions is not launching. Reading about the topic is not launching. Launching is launching. All good things come from launching. My business went from conception to launch in 8 days. Put a red mark on your calendar: 8 days from now, a month from now, whatever. Launch something by that day.

This answer resonated with me, because I’ve spent a lot of time reading and thinking and wishing about building something in the past. I’ve tried to build things before, but I never launched, and I think that the answer is not to just try harder but to replace these non-launching activities with just launching.

So, I’ve marked my calendar. And to do it, I am saying “goodbye” to Hacker News and Reddit and other news aggregators, along with various time-wasters with the help of a simple tool I wrote. If I really need help or advice, I’ll use IRC or pick up the phone, but otherwise I’m in the rare state of figure-it-out-yourself mode.

By Saturday the 6th of August, I will release a new public-facing website where people can give me money in exchange for the product or service hosted on that site.

I’ve created this bash script to help me focus on work. It blocks and unblocks a list of websites with a single command. It’s tailored for Mac OS X, but it should work on other platforms if you set up the env vars.

I created an alias for it in my .bash_profile which runs the command in the proper fashion:

alias gsd='sudo -E gsd.sh'

To get to work:

gsd

To slack off again:

gsd --play

It’s based on a similar script, originally written in PHP, that was on Hacker News a while ago.

(The first in a series of posts on Smalltalk, and Seaside in particular)

When programming in Smalltalk, the question of data persistence is not one you have to answer right away. You don’t have to think about serializing your data to disk or to a database to get on with your application. In fact, you can entirely put off the question of data persistence until the last possible moment, when you hit a real limit of live objects in memory. This is really a great thing for agile/lean-style development.

This is in stark contrast to web development in popular environments like ASP.NET or Rails, where the database is often the first thing you have to consider. Starting a new Rails project means writing database migrations. Starting a new ASP.NET project means choosing a persistence approach (such as NHibernate) and generating classes from an existing schema.

Starting a new Smalltalk project means building real, live objects. Right away. You start working and your application grows organically. The question of persistence becomes an “if” and not a “when.”

Safari 5 includes Safari Reader, which turns out to be based on Readability. I am a huge fan of the original and the integration with Safari 5 is a great move by Apple.

The only problem is that there are no options in Safari related to the presentation. If you’re like me and you prefer light text on a dark background in some cases, you might want to customize the Reader.

So I poked around in the app bundle (right-click on Safari.app and select ‘Show Package Contents’) and found Contents/Resources/Reader.html. It’s a pretty straightforward HTML file defining every aspect of the Reader UI. In particular, check out the .page and #hud CSS.

You can customize this to whatever you want. Say what you will about the “closed” nature of Apple lately, but I sure do love the openness of .app bundles.

Like a lot of programmers, I use a subtle color theme in my text editors. But one category usually ends up dimmer, fading into the dark background, slinking off into the shadows: comments.

// variable to hold the number of pages
int numPages = ...;

Why? I think it’s because most comments suck. It’s understandable that you’d want to ignore those and get on with your work. However, it’s entirely the opposite of how comments should work.

In good code, comments contain information that isn’t obvious. This should stand out, because it’s important meta-information that can’t be expressed in the code itself (unless you editorialize in identifiers).

Missing the why of a piece of code, because the comment was hiding in the shadows thanks to your color theme, might mean making a snap decision to “fix” a piece of code by refactoring to something “better” that ends up ignoring the reasoning behind the original implementation, or missing some other details that lead to subtle bugs in the future.

So, editor color theme authors: please do the development community a favor and make comments stand out!