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

Over the last couple of weeks since starting this "Learning ColdBox" series, I've been working more extensively with the framework. There's a lot in ColdBox and it took me quite a while to really feel comfortable with it. Having gotten over that initial hurdle, I'm very glad I did. Many thanks to my colleague, Ben Densmore, who has been always willing to answer my naive ColdBox questions -- even at 2.00 AM. I'm by no means an expert; I've just gotten to the point where I'm happy being a bit reckless!

[More]

Before we get into writing the application, I want to ask about logging with LogBox. A while ago, I felt the need for something more than I could get with native logging. During development, I wanted to have the ability to log something. That something might be a simple value, an array, a struct, an object, etc.

While I didn't want logging to occur when code moved to production (for obvious reasons), I did want to leave the code in place (so that, for example, I could turn it on if some anomaly occurred or if I wished to time certain processes while running in production). And finally, I didn't want to wrap logging code in if statements. That's ugly and, with enough of them, could become expensive. What to do?

[More]

With the (very) basics behind, I'm ready to try my hand at a CRUD application. (Hopefully, that won't prove to be prophetically named...) But before I start, I want to explain how I do things presently -- and ask expert ColdBoxers for some guidance as to what should be changed to best use ColdBox.

[More]

In Learning ColdBox: I, we began creating an app by getting ColdBox installed and responding. Today, we're going to go a bit deeper -- adding event handlers and associated events.

[More]

So...my first step is going to the ColdBox site to download the framework: http://www.coldbox.org/download. I created a coldbox directory directly under wwwroot. For now, I'm going with my idea of a Philosopher Battle game (see yesterday's post). (BTW, as Phil Nacelli pointed out, ColdBox comes with several sample applications already! Why not just one of these? See below...) So, let's start with creating a "Philosophy Game" app.

[More]

Lately, I've undertaken to learn ColdBox, as I'll be using it on an upcoming project. ColdBox is a powerful, robust ColdFusion framework. Luis Majano and contributors have done a pretty terrific job, it appears to me. In fact, all FOSS developers could learn a great deal from how well documented the project is.

So I mean the project no disrespect when I say that, as a newb, what would be most welcome is a small but comprehensive sample application. Since version 3.0 was just released, (http://www.coldboxframework.com/), it seems that this would be a perfect time for such a sample app/tutorial.

[More]