Software Engineering

The Inefficiency Factor

Busy day so just a short post for tonight:

room full of typists

The IT industry isn’t a manufacturing industry: it’s a service industry. Whether you’re a developer, a tester, or an ops/sysad, your purpose isn’t just to code, test, or run programs: your purpose is to make sure those programs work well enough to provide tangible benefits to the user.

But what if the software you’re providing poses some problems or negative effects on the users?

No, I’m not talking about malware or crappy software. I’m actually talking about good software that makes processes and tasks much more efficient than they are.

They can cause problems because some people actually thrive on inefficiency.

These are the back room personnel that block any sort of automation process because they know they will be rendered redundant (i.e. fired) once it’s implemented.

These are the software vendors or internal IT departments that refuse to allow third party companies/consultants to fix or replace their buggy systems because the former earns a lot of profit on support call fees.

—

Sadly, I don’t have any quick advice on dealing with these people. I’m just here to point out again that Software Engineering isn’t about technologies and processes: it’s always about people.

Ruby on Windows

Some posts just write themselves. Today’s post comes from my reply to a guy in PhRUG who still thinks you need a Mac before you can develop Rails applications.

windows and ruby

This is probably the biggest problem the Ruby/Rails community has when trying to spread the word in this country: the lack of interest in supporting Windows.

I mean, a typical response to the legitimate question “I’m using Windows, how to I practice RoR?” is the fanboy answer: “Get a Mac!”

And that, my dear readers, is a dick move. If I was an average college student and you told me that, I’ll immediately think “WTF?!? I just want to try out this open-source language and web framework and I need to shell out a couple of years worth of tuition?!?”

Answering “Format your hard drive and install Linux” is less of a dick move, but a dick move nonetheless.

Thus, if we rubyists want to spread the word about Ruby, we’ll have to make Windows a viable OS for Ruby development. Here are a few options available to us:

Continue reading “Ruby on Windows”

My DevCon talk

Yesterday was my third public speaking engagement for this year, the first being in Ignite Manila and the second was a presentation on Haml.

Not much of a background here. Ida just invited me to talk, and since I knew what the audience was like, I felt like talking about preparing for the real world.

My talk was delivered mostly in Tagalog, not only to allow me to convey my ideas clearer, but also to have a deeper effect on the student audience. For this “transcript”, however, I will be paraphrasing my talk to English for the sake of possible foreign visitors.

From Doghouses to Skyscrapers

“Transcript” below the cut.

Continue reading “My DevCon talk”

Why not Mac?

One of the first things I asked myself when I left my job last year was “Should I get a Mac?” With the rise of the Apple App store and the lingering notion that the best developers work on MacBook Pros, I had to decide whether or not I’d shell out enough money to fulfill my needs for a year just to get such a machine for future work.

I eventually decided not to buy one. I did, however, buy a 2nd gen iPod Touch 8GB for 8k to make me think about building iPhone apps. After some months of use, I concluded that I didn’t have the proper skill set to make apps on such a platform, firmly cementing the idea that I didn’t need a Mac for my personal projects. (I still use that device, though, primarily for late night fanfiction reading to lull me to sleep.)

Lately, I’ve had the opportunity to try out using Mac OSX and see what all the fuss is about regarding the platform. After using it for a while, my decision still stands: there’s no reason for me to buy a Mac.

Let’s look at things from a historical standpoint: If you were a serious developer 3-4 years ago, Mac was the way to go. Windows XP was a security nightmare while Windows Vista just sucked. Linux was as user-unfriendly as they get. Mac OS X Tiger beat them hands down.

Fast forward to the present: Windows 7 is both secure and “shiny” while still providing most of the familiar Windows interface. Malware is a lot less of a concern thanks to the unobtrusive and free Microsoft Security Essentials. On the Linux side, Ubuntu 10.04 Lucid Lynx has gone a long way in terms of giving a clean and user friendly interface to desktop Linux. Driver support has improved a lot; you don’t need to recompile kernels anymore. You’ll probably even have more driver problems with a Mac than with a Linux box.

In short, I don’t see a compelling reason to buy a Mac if you’re not a graphics designer/you’re not building Apple-specific software.

More details below the cut…
Continue reading “Why not Mac?”

How to avoid breaking builds

The guy I’m mentoring right now in one of my freelancing gigs is fairly new to software development so I decided to give him a couple of guidelines (conveniently posted on the project’s wiki) on how to properly use git.

Hopefully this should spare me the horrible flashbacks to the days when everyone I was working with was consistently breaking builds everyday.

Best Practices

Commit often. The more you commit, the easier it is to do stuff like rolling back changes or pinpointing where a change was committed.

Put a meaningful comment every commit. You’ll be thankful you did that 3-6 months down the line when you’re trying to verify if a certain piece of code is a bug or a feature.

Push with care. Follow the procedure below to avoid breaking the build i.e. pushing a version of the code which doesn’t work.

Proper Version Control Procedure

Before you push your code to the repository, please follow the following procedure:

If you still haven’t done it yet, commit your changes to your local repository (git add and/or git commit -a -m).

Pull the changes from the remote repository (git pull).

In case of conflict, manually edit the conflicting files.

You may have to collaborate with the other dev for this.

After fixing the conflict, commit the merged changes and go back to step 1 (git pull).

Run the DB migrations.

Run the RSpec tests.

If the specs fail, either fix the code or fix the specs.

After fixing the failing specs, commit the fixes and go back to step 1.

Run the Cucumber tests.

If the specs fail, either fix the code or fix the features.

After fixing the failing features, commit the fixes and go back to step 1.

Do a simple developer test. Open the server, log in, and open a couple of pages.

If the system doesn’t work, find the problem and fix it.

After making the system run smoothly again, commit the fixes and go back to step 1.

You can now push your changes to the remote repository using git push.

You might notice that we’re using RSpec and Cucumber in our project. I’ll talk more about them in a later post.