Thus, I’ve resurrected some python resources that I’d captured before. But, my main effort right now is watching the MIT OCW class on python, which my son found and started as his “spring break” project.

I’m exceptionally proud of him that he didn’t think it was a ridiculous idea for a bright 8th grader to take a class, however easy, for MIT undergrads. Good for him: that’s the only way to fly.

I’ll update things as I work my way through the lectures too.

I had a heckuva time today trying to migrate a rails app in progress to postgresql so I could deploy it to Heroku. The migration didn’t work, which led to confirming/installing postgresql. That was a couple times.

It still wasn’t working – no rails splash page, even, let alone anything I’d coded.

So I decided to clone the basic heroku test app to confirm where the error was. That triggered a ruby problem, with mine at 2.0.0 and the test app requiring 2.2. That led to updating RVM, and then trying to update Ruby. That led, in turn, to updating brew. So, here are the steps in the right order, so you can avoid the “get error, search stackoverflow, fix error, continue” sequence and do these in the “right” order:

brew upgrade
rvm get head
rvm install ruby-head

At this point, I’m not sure whether postgresql will work at all, but I feel like I’m back in the days of 1992 when my LT buddy would chide me for having spent all afternoon “playing Windows” trying to get something to work (this was back in the days of 3.1 in the Army, so there weren’t many options). That characterization is what eventually led me to OSX about 4–5 years ago (well, not installing printer drivers wasn’t the only thing).

What this post ends with, though, isn’t frustration: it’s deep appreciation for the people who’ve written all these tools to make things easier. Sure, it may be a bit complicated to start to figure things out and get comfortable with the sequence, but the relative ease and speed with which dramatic capabilities can be harnessed to create a development environment is really freaking amazing.

Thanks, everyone. I am looking forward to the time when I’m able to contribute myself.

I sent it back to him today with a pretty decent explanation – maybe 6 paragraphs.

Can you tell I’m procrastinating a bit? I’d been muddled the past few weeks, stuck between deciding to turn my side project efforts to writing the second draft of the startup book or getting the prototype of the startup back underway. The other day, the answer came to me: startup. (I think it has to do with the idea that the more progress I make there, the more I give the team stuff to work with. They’re not entirely waiting on me, but they will certainly do more as I complete more.)

I have figured out why, even though the coding is something I enjoy and what I want to do more of, I procrastinate. It’s because I’m back at the learning phase and trying to figure out stuff, which is a tiny bit disheartening both because it’s sort of like the failure phase (lots of failing as I figure stuff out) and because I’m not able to directly work on the actual problem. But that’s okay – figuring that out and writing it down here helps. And the last bit of hitting publish on this post is a good transition step to pulling up the next instructional videos on Rails that I’m working through to get going again.

It would be good if we (now that I feel I’m almost part of the Rails community) figured out how to do less shooting ourselves in the foot. Let’s turn gems into more service-like systems, so that a dotenv change can switch my authentication choices from one gem to another without requiring a lot of extra work.

This is the same DRY principle I learned, and implement, in the contract drafting world (yes, I’m a lawyer by education). Poorly drafted contracts have lots of bear traps hidden throughout, like a person’s individual name in Section 6.3, and a random sentence added to Section 5.4(a). These are the legal equivalent of hard coding numbers into your excel formulas or using a fixnum instead of a variable in a method (which I understand well because I understand the excel framework so well).

Gems should be more plug and play in basic methods, so that we’re not writing code, and then rewriting code to implement a new gem’s version of the same features. New code for new features, sure. But when I switch my email provider from one imap provider to another, the experience is awfully seamless.

Of course, gem authors aren’t really participants in a self-organizing system, and there’s no DHH to stake out a position for everyone else to either applaud or complain about. (And for that, this newbie says, “Thanks for being the lightning rod, DHH.” I know it can’t be a lot of fun some days.) But we as developers can think about ways to make our gems function more like services to our apps, so that we can replace and upgrade them without triggering lots of additional changes.

It’s not just DRY within an app, it’s also DRY within your app’s ecosystem and even across apps.

Having seen how a very old profession has continued to screw ourselves by poor architecture/design choices, I can see a path to improving the efficiency/value of dev time.