Google Goggles Magic

Last night a friend complained about a curry recipe gone wrong, so I decided to offer up the one I used to make with a certain amount of frequency. It’s from a 1970s Time Life cookbook that I vaguely remember swiping from my friend Jehan in college. I took a picture on my cell phone to send it along.

Chicken Curry Recipe

 

The page is sufficiently stained with turmeric to realize how often it was made.

A little while later I noticed a Goggles Alert on my cell phone, it had scanned the image, and returned the following URL as a hit: http://littlechefapp.com/recipes/144571-chicken-curry-authentic#.UOGjR2JQCoM

Dead on. The future is pretty awesome some times.

Reading Code

When you are learning how to program, you think that most of your time is going to be spent writing code. The reality is most of your coding time is actually spent reading code. Other people’s code. Code with comments that lie. Code with bizarre short cuts. Code whose original authors are long gone or unresponsive.

And that’s the real skill of a good programmer, the ability to read this kind of code, and make sense of it. Maybe even make it a little better as you come across it.

Two Solitudes – CS and Software

Via channels I can’t now remember, I came across this presentation about the very unsolved issue of how Computer Science as a field of study relates in any way to creating software.

With so many colleges in the area, and having a number of friends that are CS professors, and other IT staff at colleges, it continues to amaze me how disconnected these worlds are. All made the stranger by coming into the field sideways from a physics degree.

Plus, I love the term software carpentry.

Wise words about software

From a former Firefox developer, truer words were never spoken:

Software companies would do well to learn this lesson: anything with the phrase “users love our product” in it isn’t a strategy, it’s wishful thinking. Your users do not ”love” your software. Your users are temporarily tolerating your software because it’s the least horrible option they have – for now – to meet some need. Developers have an emotional connection to the project; users don’t.

All software sucks. Users would be a lot happier if they had to use a lot less of it. They may be putting up with yours for now, but assume they will ditch you the moment something 1% better comes along — or the moment you make your product 1% worse.

I gave up Firefox as my main browser when Chrome decided to support WebGL on Linux, and Firefox kept back burnering it. Mozilla is now deprecating Thunderbird, which is the only product of theirs that I still use regularly. Guess that means I’m going to have to get used to GMail’s web interface eventually.

Sad to see something as critical as Mozilla, the beast that cracked the IE hegemony, become an also ran.

Why I became a programmer

Yesterday was not a good day. The reasons (plural) aren’t really important for the sake of this discussion. But at 7pm, with the day behind me, and an hour and a half before my wife   was scheduled to get home from yoga, I switched over to my emacs window, and started going after a problem I’ve been poking at for 2 weeks.

The problem, which had nothing to do with my day job, was how to seemlessly add some javascript to date forms in Drupal to make them more magically. The date forms in Drupal are honestly quite dumb. You get presented with From and To, Date and Time. They are initialized to “now”. But they are 4 fields, unlinked by code. This was the easy way for the developer to write it, but absolutely frustrating for the user. Especially if you’ve used systems where the To dates move forward in time to match changes in the From dates. Set From to Jan 24th, and the To date shouldn’t still be Jan 11th. Making it also move to Jan 24th might not always be right, but it’s almost always more right than leaving it unchanged.

I had figured out how to do this with jquery, with these fields, and have a solution for one of my sites. But this is something that would make a great Drupal module. One that requires no configuration, and just makes your user’s experience better. How to get there, required banging my head a lot on internals, reading a lot of code that I thought might be examples, and not getting anywhere. Last night, frustrated with things that weren’t this problem, I went after it again, this time by brute force. After about 45 minutes of trial and error, I found a hook I could use to patch myself into the execution stream at the right point. Better yet, it seemed like this was probably the right way to do it, not some dodgey hack. By the time Susan got home, I had the shell of this module mostly working. Not releasable yet, but the minimum viable piece was now done, and the rest was about cleaning up for release.

I felt better.

There is a longer story here about how I entered College to be a PhD Physicist, and I exited to do web development for the Sydney Olympics. But the key take away was a realization, late in my Junior year, that when I wanted to relax, I went off and coded something. While I could never point to the day it started happening, I do vaguely remember realizing that my happy place, my retreat from the stress of the world, was deep inside an emacs session for hours at a time.

The fact that the thing that relaxes me, writing software, also happens to be a key piece of a quite profitable profession[1], made me a fortunate individual. Having gone to college and watched the modern internet emerge, which is an even longer story, made me doubly so.

The best piece of advice I ever got was from my friend and mentor, Eric, in college. “The key to happiness is to figure out what you’d do anyway; then find a way to get paid to do it.” Even if this wasn’t my job, I’d be writing software. It’s what relaxes me.

What relaxes you? What would you do if money was no object? Why did you become whatever you call your profession? Drop a comment below, because I’m actually quite interested.

[1] Yes, I’ve been long enough in the Software Engineering space to know programming is a small part of it (especially at a large company), but it’s still a very important part.

 

Maybe it shouldn’t be Computer Science

I had an interesting conversation at lunch yesterday when I met a CS professor at a local college. He’s got nearly 15 years industry experience, in addition to a decade being in academia, so exposure on both sides of the fence. During the course of the conversation I asked him what triggered the transition. His response was that he didn’t really enjoy programming.

There’s nothing wrong with that answer. I’m always jarred by it when I hear it from folks, because programming is what I love. But everyone’s different, an there is a lot more to computer science than just programming.

Over the course of the day that statement kept coming back to me, and I realized I’d heard it a lot of times in the past. The vast majority of CS profs I had during my graduate degree were in the same camp. Friends that are in CS academia, tend to lean the same way.

Art and music programs in liberal arts schools are a combination of practitioners and theorists, attempting to build a well rounded art student on both fronts. So why is CS still mostly theory in these environments?

The theory parts of CS wouldn’t have been my thing as an undergraduate either. Much like calculus being pretty boring in high school, but becoming down right compelling in my college physics classes when it was a tool to solve a problem, and not just theory that stood on it’s own. Without a body of work that’s tangible, the theory is much less relevant.

So maybe it’s time to call it something other than Computer Science. Software Engineering has the no no of the word Engineering, which doesn’t go over well at liberal arts schools. Apparently, Informatics is the monkier in much of Europe, and given the rise of data analysis, that’s probably as good an idea as anything else.

Upcoming Talk: Getting Involved in Open Source

We’re circling around on January again, which means it’s time for my annual talk at MHVLUG. One thing that’s really fascinated me over the last year is recovering and revitalizing open source projects whose maintainer has wandered off. The talk was mostly going to be about that, but after a bunch of conversations, I realized that I probably needed a talk of more broad appeal.

The new talk is going to be: Getting Involved in Open Source. This is going to be both a personal journey, as well as a list of lessons along the way. The successes and failures are going to be basically mine alone. After over a decade working in open source, I’ve got bumps and bruises all over the place, but fortunately no mortal wounds.

I’ve already got slides and talking points spinning in my head, things I haven’t thought about in years. This is going to be a really fun talk, and should be very educational to people with all levels of open source development.