Well, 6 months ago, I undertook to teach programming to 3 non-programmers. The three were: my wife and two stepsons, W and E. I told them that if they persevered, by the end of six months, they would have a new career and be able to find a good-paying job. So, how did they (and I) do?

[More]

I've read a fair amount about workflows with git. It seems the conventional wisdom is to create a branch related to some feature. I've tried to do that with prototyping (see my last post) but feature branches just don't work for me. Rather, I find that either I've made a complete hash out of something -- or I just like an earlier version better. I'm much more likely to say "You know, I like the version I had last night better." But when branches are feature-based, my time-based desires don't match.

That led me to the idea of having larger feature branches with smaller time-based ones. Pretty much all my production code is pair-programmed. We use a little app called Pomodoro on our Macs. It has a voice feature and every half hour, I have it say "OK, guys. Switch. And heeeeerrre we go!"

Before turning over the keyboard, the current typist commits the current branch and creates a new one using the current date and time. Something like "02Dec1430". When that half-hour is done, we switch places and start with "02Dec1500". Occasionally, we'll roll everything up to "develop" and then to "master" -- but I really like having the flexibility of a highly-granular, time-based branching system for git.

I've been a believer in the power of prototyping to deliver software that clients actually want for almost as long as I've been programming. I learned the hard way that any other technique I (or others I observed) tried just didn't work. Despite the best of intentions and tremendous dedication to the project.

I've tried many different prototyping tools, including Justinmind Prototyper, Balsamiq, Azure, Protoshare, Pidoco--well the list could go on and on. It's not that these aren't all good products; they are. Some of them are very good. But somehow, they didn't quite deliver what I wanted in the way I wanted. My latest attempts are proving more successful.

[More]

Several people are asking about my Ruby on Rails, An Immersive Introduction class (see last post). Here's the rundown on what you'll learn:

The class begins at 9.00 and finishes at 6.30 for 5 days.

We provide a catered lunch.

And Aspirin.

What You'll Learn

• Just Enough Ruby: you'll get comfortable with the major constructs of this wonderful language
• Rails MVC Architectural Implementationyou'll learn about the many defined folders and files that make up a Rails app
• Routing, Forwards and Back: initially confusing, Rails routing is tremendously helpful--if you understand how to make use of it (with special emphasis on RESTful end points)
• Configuring Databases: Oracle? SQL Server? MySQL? Postgres? SQLLite? Rails can handle them all -- even different databases for development v. testing v. production
• Migrations: source control for databases? Why didn't someone think of this sooner?
• Models: the heart of your application
• Forms from Models: more labor-saving goodness from Rails
• Model form validations: a bevy of built-in validators -- or create your own, custom validators
• Rails Console: you'll spend lots of time here probing your application
• Layouts: simple, elegant solution for section- or application-wide HTML
• Unit Testing: unit testing is really this simple?
• Sessions and Authentication
• Model Associations: hooking your models up, err...so to speak
• "Getting" Rails ActiveRecord: first, you'll hate it; then you'll love it
• Debugging Rails Applications: Stop the application while it's running, interrogate it to see what's going on under the hood -- one of my favorite aspects of Rails
• The Asset Pipeline: a good and simple idea that I have yet to see explained well
• ActiveRecord Query Interface: why you won't miss SQL (and how to use SQL for those times AR doesn't make sense)
• Events in Rails: learn this and it will revolutionize the way you write applications. Seriously.
• Ajax and Rails: very flexible; very easy

Again, the price is $3500. If you want to attend, send me an email at hal@halhelms.com or call me at 941.716.6909

Location: Austin, TX Dates: Jan 26-30, 2012

Something must be in the air. In the past week, I've heard from four ColdFusion developers who are seriously looking at Ruby on Rails. I'll gush about how great Rails is another time. For this post, I'm just announcing an introductory 5-day Ruby on Rails class in Austin, TX. The class will be an intense learning session and is limited to six developers. The cost is $3500.

If you want to really master Ruby on Rails, contact me at hal@halhelms.com.

Several weeks ago, a crazy idea popped into my head: why don't I teach programming to my family? Here are the list of characters:

G: my wife, a very gifted artistic person. She uses Facebook, but struggles with anything more complicated. She's convinced the computer is out to get her.

E: my stepson, a graduate of Fashion Institute of Technology. He's used computers for Adobe Photoshop, but not much more.

W: my stepson, a year of college. He has a Facebook page and understands a little about how to use a web browser, but nothing more.

I presented the idea to them like this...

[More]

What does a philosophy major do after college? Woodworking, of course! Initial small woodworking projects gave way to larger projects and I found I needed some way of automating the "cut lists" used to pre-cut all the pieces of wood for a project.

My first step was acquiring a Texas Instrument programmable calculator. I forget the exact price -- $300-400 --but it had these things called "variables"! And I could plug them into a formula I wrote to get the exact size of pieces. Amazing stuff.

From there, I went on to write Lotus 1-2-3 macros, then tackled BASIC. From there, it was learning DataCAD and learning their programming language. Finally, I slipped the woodworking tether completely and sold my company. A good friend of mine, a technologist, hired me and shipped me off to this strange place called "Palo Alto Research Center". Xerox PARC was the legendary research facility where Bill Gates and Steve Jobs first saw a windowing system and a mouse, all powered by the language, Smalltalk.

Fast-forward a few years and I found myself the head of "the Web group". One of the early questions was which language we would use. Java was the odds-on favorite, but this was version 1. It was buggy and slow. Steve Jobs was peddling Web Objects, but the cost was much too high. Then, there was this little language, "Cold Fusion", that had a lot of promise (and a fair amount of risk). I decided to risk it.

That was when ColdFusion was at 3.5. During that time, I've seen the language evolve and grow. "Cold Fusion" lost the space in its name; features have been added; the underlying platform has changed. Through all its changes, ColdFusion has never lost sight of its roots: making life easier for developers. And the culture that grew up around ColdFusion has always seemed to me one of its greatest assets. While developers in other languages might tell newbies to RTFM, ColdFusion folks have always been warm and open, ready to share and learn from each other freely.

Thanks to Jeremy, JJ, Ben -- and all those who labored to bring ColdFusion to where it is today.

On July 27, I had the distinct pleasure of meeting with other ColdFusion developers at the Austin CFUG. I wanted to share what I had learned in the process of learning Ruby on Rails. You see, I was tricked into learning Rails. John, a very good friend (and another ColdFusion developer) had learned Rails and tried to interest me in it as well. I would have none of it. I didn't need it and I didn't like it. Further, I didn't like those smug Rails fanboys. I had been working in ColdFusion for almost fifteen years and I had run into very few situations where I needed something else. And I always had Java that I could use if the need arose. So who needed Ruby on Rails? Not me. I thought.

[More]

Recently, I was commissioned by Vin 65 to write up a guide to hiring and cultivating great developers. They were generous enough to allow me to share it with everyone. It's much too long for a blog post, but here's the URL to the PDF: https://github.com/halhelms/Hiring-and-Cultivating-Great-Developers.

I'm not much of an Ayn Rand fan. Although I confess to a certain guilty pleasure reading Atlas Shrugged and The Fountainhead (despite prose that can charitably be called leaden), her thinking I found to be naive in its positivism.

[More]