Thoughts on the business and practice of software development

It’s a well-known fact that multitasking is counterproductive to actually accomplishing anything of value. This is particularly true for software developers like me, who tend to juggle multiple projects at once. Case in point: For the past month, I’ve been tinkering with a Web application idea, but for various reasons have been able to get it off the ground.

Well, it’s time to change that.

For the next 48 hours (between now and Saturday morning), my one goal is to get that Web app up and running. I’ll be using Ruby on Rails to build it, of course!

The application - it’s called Foretweet and will live at http://foretweet.com - lets users schedule Twitter messages in advance. The idea grew out of a client project I did recently for a parachurch organization who wanted to send out tweets every day with that day’s Bible reading. The plan at present is to let users schedule up to 10 messages at a time for free, and (later) offer a paid plan that will let you schedule than that.

Stay tuned - I’ll post updates a few times a day and let you know how it’s going. (For more frequent updates, follow me (@mentalVelocity) on Twitter.

{ 0 comments }

I originally wrote this series of posts on my former blog, Usable Web Apps. As I’m retiring that blog, I’m reposting the “Novice to Ninja” series. Look for some new interviews as well!

I met Matthew Bass at RailsConf 2007, where he did a great presentation on Teascript, a Rails app he had developed. Matthew was kind enough to share his answers with us:

Usable Web Apps: What three skills/technologies would you recommend that novice Rails developers focus on mastering to best improve their overall value?

Matthew Bass:1. Discipline. Ruby is a wonderful programming language that gives developers a great deal of flexibility in how things are done. With this power comes great responsibility. Just because Rails enables quick development of web apps does not excuse sloppy code. Being disciplined up front will take you a long way. One of the telltale signs of a newbie Rails developer is extremely long methods, often in the controller. Keep your methods short. Delete unnecessary comments. Don’t leave commented-out code in the project (you can always get it back from source control). Write tests. Run the tests regularly. Fix warnings in the logs.

2. Teaching. One of the best ways to learn something is to teach it. If you don’t have a blog, start one. Even if nobody reads it, post to it regularly. Explain how you solved a particular problem you ran into. Getting a strange error message? When you’ve figured it out, blog it. You might help someone else, and you’ll be keeping a record of the solution for your own future reference. Write a tutorial on a certain topic and split it up into several blog posts. Volunteer to speak at your local user group. If you don’t have a user group, start one. You don’t have to speak about something brilliant or deep. Just share what you’re doing on your latest Rails project. Tell stories of your own experience. People want to hear from you.

3. Switch to a Mac. I did Rails development on a PC for a year before the pain became too great. I was skeptical about switching at first, but I truly cannot imagine doing Rails development on a PC again. The tool support on the Mac is just too good. Having a Unix environment is pure pleasure. Don’t put it off if you’re serious about learning Rails.

Usable Web Apps: What are the biggest mistakes you see novice Rails developers make when trying to strengthen their skill sets?

Matthew Bass: Taking bites that are too large. Rails and the surrounding technologies represent an enormous pile of code. Trying to understand everything too quickly will leave you frustrated. Take it one step at a time, building up your knowledge on a daily basis. In some respects, those who got in at the ground floor of Rails have an advantage because they’ve seen the framework evolve over time and have a deeper understanding of why things are the way they are. But you don’t have to be an “old timer” to use the framework effectively, and even building a small personal project can serve as the catalyst that will trigger interest in other parts of the framework. Don’t give up. Don’t be afraid to ask for help. Be curious. Explore what you’re passionate about. If REST isn’t your thing, don’t worry about it. Maybe you’re more interested in what makes ActiveRecord tick. Explore that and leave REST for later. Subscribe to the Rails Envy podcast to keep updated on what’s going on in the community. If you hear something interesting, check it out. Play with it. Learn from it. Blog about it.

Thanks, Matthew!

{ 0 comments }

I originally wrote this series of posts on my former blog, Usable Web Apps. As I’m retiring that blog, I’m reposting the “Novice to Ninja” series. Look for some new interviews as well!

Next up, we have Nathaniel Talbott, founder of Terralien, a Rails consultancy based in Raleigh, NC. (Terralien also wins my award for “coolest looking website for a Rails shop”.) Nathaniel is a frequent speaker at RailsConf, RubyConf, and has been doing Ruby for several years. (In fact, if memory serves, he wrote the testing framework that became Test::Unit.) Nathaniel was kind enough to share his answers with us:

Usable Web Apps: What three skills/technologies would you recommend that novice Rails developers focus on mastering to best improve their overall value?

Nathaniel Talbott:1. Learn to engage with the community. Find a local Ruby brigade and get involved. In addition to going to meetings, you should leverage the mailing list like crazy: it’ll be a lot lower volume than one of the worldwide lists but usually has lots of experts listening in. And of course, there’s a lot more to local community besides Ruby: you can check out the local web design meetup, attend your local BarCamp, and generally plug in to any community that’s related to what you’re doing.

2. Learn to communicate well with clients. One of the things I love about Ruby is that it allows us to shorten the feedback cycle between idea and implementation, but you have to actively work to leverage that when communicating with clients. So deploy your code every day, code up quick prototypes right in the meeting with a client, or even do 24-48 hour “rumbles” on client projects where you quickly get a big chunk of functionality pushed out. Work to translate your increased productivity in to direct visible gains for the client.

3. The one technical tip I’ll give is this: learn some C. At least dabble with it enough that you could write an extension if you needed to. Ruby has one of the easiest to use C extension schemes out there, and you can use something like RubyInline to make it even easier. It always pays to have at least a basic understanding of the technology that your technology of choice rests on, and for Ruby that means learning C. Beyond the benefits, it’s also a lot of hard-core geeky fun!

Usable Web Apps: What are the biggest mistakes you see novice Rails developers make when trying to strengthen their skill sets?

Nathaniel Talbott: Biggest mistake, related to tip #1 above, is going it alone. While you should always do your due diligence before asking the question, my experience is that new folks tend to wait way to long before asking for help. A lot of times just formulating your question for a larger audience will help you find the answer, and it’s awful to spend hours (or days!) stuck on the same issue. Quick rule of thumb: if you’ve been trying to figure something out for an hour and have made no headway, then wrap it up in to an intelligent question and ask a relevant community for help.

Thanks, Nathaniel!

{ 0 comments }

I originally wrote this series of posts on my former blog, Usable Web Apps. As I’m retiring that blog, I’m reposting the “Novice to Ninja” series. Look for some new interviews as well!

I first met Dave Thomas of the Pragmatic Programmers when he and Mike Clark led the Rails Studio that I attended in February of last year. (For those of you who are looking to learn Rails from scratch, I can’t recommend the Rails Studio highly enough!) Dave was kind enough to give his thoughts on becoming adept in Rails:

Usable Web Apps: What three skills/technologies would you recommend that novice Rails developers focus on mastering to best improve their overall value?

Dave Thomas: 1. This may sound strange, but I think the number one skill that folks need to be effective Rails developers is the ability to program. I see far too many people who’ve never coded before coming to Rails because they hear that it will help them dash off the next Facebook. And rather than invest the time to learn Ruby, they dive in, cut-and-pasting bits of other applications that they see on line. Inevitably, this cargo culting hurts them. And, when they start grumbling that Rails sucks, it hurts Rails too.

2. I think that it’s important to get your applications out there early, and then listen to its users before adding more features. Rails is about being agile, and incremental delivery is one of the cornerstones of agility.

3. Just because Rails makes the 80% easy doesn’t mean you can forget the other 20%. Security, deployment, scaling, testing, and so on are all orthogonal to Rails, and they’re all vital skills to know.

Usable Web Apps: What are the biggest mistakes you see novice Rails developers make when trying to strengthen their skill sets?

Dave Thomas: The biggest mistake is that they don’t try to strengthen their skill sets. And, to be honest, novices shouldn’t be expected to. The Dreyfus model tells us that novices are simply concerned with achieving a result, So building a skill set just doesn’t factor in—they’re thinking tactically, not strategically. But that’s OK. What happens is that,over time, those novices start moving towards expertise, and start thinking more at the meta level. Once that happens, they start really start building skills. And the way to do that is by exposing yourself to as many different areas of the technology that you can: different tools, different techniques, different technologies, different industries. Skill comes from experience—consciously maximize the amount of experience you gain per unit time by constantly adding new strings to your bow.

Thanks, Dave!

{ 0 comments }

I originally wrote this series of posts on my former blog, Usable Web Apps. As I’m retiring that blog, I’m reposting the “Novice to Ninja” series. Look for some new interviews as well!

I’ve started writing Rails applications about two years ago, and I’ve successfully launched three applications for various clients. However, because most of my clients over that time period use Microsoft technologies (.Net or ASP), I’ve never had enough consistent time in the Rails ecosystem to move from a novice-intermediate level to the “guy who really knows his stuff” level. Over the next few months, I intend to move to doing only Rails projects, and in order to get there, I need to make the leap from Rails novice to Rails ninja, as it were.

But as many of you know, mastering Rails means more than just understanding the Rails framework itself. There’s also the Ruby language itself. Testing frameworks like Test/Unit and RSpec. Markup technologies like HAML and Liquid. Popular plugins like restful_authentication and attachment_fu. Git. Mongrel and Thin and Phusion Passenger (oh my!).

So where to begin? I decided to ask those who have either “made it” to Rails ninja status, or those who are much farther along the road than me, and to share those insights with all of you.

First up is Mike Gunderloy of A Fresh Cup. I first met Mike at RailsConf 2007, and over the past two years, he’s successfully made the leap from the .Net world to Rails. Here’s what Mike had to say:

Usable Web Apps: What three skills/technologies would you recommend that novice Rails developers focus on mastering to best improve their overall value?

Mike Gunderloy:1. Learn at least one of the testing libraries well. Rspec or Test::Unit or Shoulda…just so long as you’re getting the notion of TDD/BDD down.

2. If you’re coming from something like .NET, you’ll need to learn some CSS basics, even if you’re bringing in a designer.

3. Knowing what’s actually in Rails, especially ActiveSupport and ActiveRecord, will save you a great deal of reinventing the wheel.

Usable Web Apps: What are the biggest mistakes you see novice Rails developers make when trying to strengthen their skill sets?

Mike Gunderloy:Too much “magpie programming.” It doesn’t help to swipe bits of code from tutorials or blog entries or the Rails API comments if you don’t know what they’re doing.

Thanks, Mike! I’ve sent these questions to a few other “Rails ninjas” out there, and I’ll post their insights as I receive them. If you know of a Rails ninja that I should send the questions to, leave a comment and let me know!

{ 0 comments }

It’s swarming across the land, it threatens to destroy crops, endanger lifestock and decimate livelihoods. I refer, of course, to the “25 random things” posts on Facebook. I’ve been tagged no less than 10 separate times, and it’s time for it to stop. So here, without further ado (and little thought), are 25 random things about me that you probably will wish you never had read:

1. I’m named after my grandfathers. My dad’s dad was John, my mom’s dad was Lawrence.

2.  My childhood nickname was “John John”, to distinguish me from my granddad. (Don’t even think about using that nickname now - you will suffer a horrible fate at my hands.)

3. When I was six, I saw an afterschool special explaining the “facts of life”. Thus informed, I immediately proceeded to relay this information to my older cousin, who told and got me in trouble.

4. In the fifth grade, I was the lead in the school production of “The Pied Piper.” Tights were involved.

5. Also in the fifth grade, I won an award for a poem I had written. For the award, I got my picture in the local newspaper. The problem was that the picture was taken on the day of the dress rehearsal for the school play (see #4), so my picture was taken while in costume.

6. Yet again in grade 5, I won the school spelling bee on the word “coleslaw”. I was knocked out in the first round of the regional spelling bee, appropriately enough, on the word “farewell.”

7. The first movie I ever remember seeing was Star Wars. In the theater. I was 5 years old.

8. When I was in eighth grade, I was home sick one day in January, and went outside to see the shuttle launch, which I could (barely) see from my yard. It blew up.

9. I got my first computer - a Commodore VIC-20 - when I was in sixth grade. I taught myself how to program in BASIC on that computer.

10. In high school, I earned a varsity letter - on the academic team.

11. My favorite breakfast food? Grits and eggs. (Bacon is always appreciated too!)

12. My favorite TV program? LOST.

13. My college degree is in religion and philosophy.

14. My favorite college class:  Greek. (Yes, I can still read it, somewhat.)

15. My favorite hobby: Cooking, especially grilling/barbecuing when the weather permits.

16. I’m a total Food Network junkie.

17. I started wearing glasses when I was 27.

18. I met my wife by dating her roommate.

19. Should I die suddenly, I want two hymns played at my funeral: “And Can It Be” and “What Wondrous Love”.

20. I never took a programming class in college (and the one I took in high school was a joke). I’m almost entirely self-taught as a programmer.

21. When I was a senior in high school, I skipped school one day to attend a pastor’s conference led by John MacArthur. (It was totally worth it.)

22. The last time I preached a sermon was the last Sunday in 2000. The topic was Biblical discernment.

23. I am left-handed.

24. My first car was a 1978 Toyota Corona.

25. For my birthday (coming up in a few weeks), my wife bought me (at my request) an ESV Study Bible. This past Christmas, she bought me an enameled cast iron Dutch oven. I’m not sure which gift I like more, but Naomi is definitely a keeper!

{ 0 comments }

“Jack of all trades, master of none” - old saying of indeterminate origin

“A house divided against itself cannot stand.” - Jesus

For the past two years, I’ve been splitting my time between .Net and Ruby on Rails projects, depending on what my clients at the time were asking for.  The rationale for this bifurcation was that a paying client is better than no client at all, and since I didn’t have enough Rails work to sustain my business, I kept doing .Net work (which was not a bad thing) and also kept soliciting .Net work, which I think was ultimately detrimental.

You see, by not putting all of my business development eggs in the Rails basket, my efforts were seriously diluted, to the point that I not only had no significant presence in the Rails community, but no significant presence in the .Net world as well.  In other words, my marketing efforts didn’t pay off.  My work schedule is largely open, partly due to the shaky economy, but in large part due to my lack of focus.

So, if I’m forced to choose one or the other, why Rails? Why not .Net? Simply put, I enjoy working with Rails. As far as .Net goes, I like C# as a language, but the rest of the Microsoft ecosystem has become so bloated that it sucks the life out of the developer who just wants to get something built.  (Seriously, take a look at the ASP.Net MVC project - it’s better than ASP.Net WebForms, but it’s still a train wreck compared to Rails.)

So today, I’m drawing my line in the sand.  I am henceforth focusing 100% of my marketing and business development efforts on the goal of becoming a 100% Rails development shop.  As long as my schedule is open, I’ll do .Net work, but I’m not going to actively seek it out.

This, of course, is a risk.  I have a family to feed and bills to pay, which means I have to maintain a certain level of cashflow.  In western Washington, there is a strong Microsoft bias, which means .Net is more in demand. But it can be done, and I’m going to do it.

So, if you have a Rails project that needs doing, drop me a line, OK?

{ 2 comments }

I’m working with a prospective client who needs a cross-platform desktop applicationthat will run on both Windows PC’s and Macs that may or may not ever be connected to the Internet.  The application needs a rich UI, and will need full access to files on the host computer. Let’s look at the options:

• WPF. Windows only. FAIL.
• Silverlight. Runs in a browser, and in a sandbox. FAIL.
• Java. Ugly as sin. FAIL, FAIL, FAIL.
• Adobe AIR. Lets me use Flash-y UI, runs on both Mac and Windows, is reasonably robust in terms of functionality, and gives me access to the underlying file system and other system resources. WIN.

To become more familiar with AIR, I decided to build a very simple AIR application that would look up and display Bible verses using the ESV (my Bible version of choice) web services.  So, I installed Adobe Flex Builder 3 and got cracking.  In about 2 hours time, I had a working application that, although it won’t win any beauty contests, does exactly what I wanted it to do.  If you want to take a look, you can download it here.

I did run into one bug (HTTP headers not getting returned on a 302 redirect), but overall it was a pleasant development experience. I already have lots of ideas for applications that could leverage AIR and Flex…

{ 0 comments }

One of the more challenging parts of life as a freelance programmer is staying current on new technologies.  In the past, my mantra has been “learn it when you need it” - and need it referred to work for a paying client.  Inevitably, this strategy leads to stagnation, where you’re writing applications based on decade-old frameworks, hoping that God will be merciful to you and let the roof cave end, relieving you of your misery.

To avoid this unhappy fate, I’ve identified four technologies that I’m going to master in 2009:

• ASP.Net MVC. Two years (part-time) spent developing websites using Ruby on Rails made it really difficult when I had to go back to ASP.Net.  I loved the separation of concerns, improved testability, and cleaner code that an MVC framework provides.  Although (from what I’ve seen thus far) the new ASP.Net MVC framework isn’t quite as robust as Rails, it’s a giant step in the right direction.
• JQuery. I’ve used several Javascript libraries in the past, most notably Prototype due to its inclusion into Rails. But JQuery is a different kind of library. The code is easy to understand, easy to debug, and it just plain feels right. Plus, it’s being released with the ASP.Net MVC framework, and is being embraced by the powers-that-be in Redmond (while still remaining open source).
• WPF. Most of my client applications are currently built using WinForms, which is a great framework. But WPF is clearly the future of Windows apps, and at some point, I need to be aligned with that future. Besides, always hated that I couldn’t use code generation to build stock WinForms forms, but it’s child’s play to build a CodeSmith template that outputs XAML. That alone will boost my productivity quite a bit!
• NHibernate. Most of my current applications use a mix of custom business objects, stored procedures, and code-generated ADO.Net methods to talk to the database. It works and performs well, but is extremely difficult to change! LINQ to SQL shows some promise, but Microsoft has apparently decided to put all of its eggs in the Entity Framework basket, and EF isn’t mature enough for production use. NHibernate is stable, it’s been around for a while, and it is the darling of the ALT.Net crowd. It’s time to take the plunge.

What technologies are you planning to add to your repertoire in the coming year? Drop a note in the comments!

{ 2 comments }