existence, refactored

I’ve mentioned multiple times before that earning more money does not equate to financial stability. You may think that that’s just some theory I picked up in random financial books, but thanks to a certain show of internet drama last week, I now have a good example of why Notorious B.I.G. was right:

• The whining of the rich by Michael O’Hare, and
• a follow up post In Which Mr. Deling Responds to Someone Who Might Be Professor Xxxx Xxxxxxxxx by economist Brad DeLong

For those of you who don’t have time on their hands to read the posts and comments, here’s the summary:

Law professor and his Oncologist wife earns over half a million dollars a year. They’re going to lose the Bush-era tax cuts they have, and so he’s whining that he won’t get to pay for all of his expenses i.e. he’s going to be poor.

Before you go “WTF, I’d be happy to earn just $20K a year!” I would like to point out that the couple’s problem isn’t limited to people earning that much. A lot of middle class people also fall into the same trap as that family.

It all boils down to pride.

Say you’re a twenty-something professional earning PhP 25K a month after taxes. It’s not hard to imagine what type of people you’re hanging around with: yuppies obsessed with getting the latest cellphone models, clubbing and out of town gimiks, and looking forward to getting that promotion/credit limit increase so that they could get a car loan.

You basically have two options here. The “easy” route is to just go with the flow: spend your money like them. Get your monthly cash flow to negative just so you could appear as rich as your friends. Don’t worry about debt: you’ll eventually get promoted later and by then you’d be able to pay all of them off.

But you won’t. By the time you’re earning more, your colleagues have changed too. They’ll be spending more so you’ll also be spending more. Before you know it, you’ll be pulling in a 7 digit yearly salary but still have money problems like the good professor in the story above.

Or you can take the second option: swallow your pride.

The most glaring indication that the professor in question has no financial literacy whatsoever is his insistence to get a loan for a $1M home when he hasn’t even paid off his student loans yet. This irrational focus on appearance has ruined many relatively well-off families (including my family, but that’s a different story altogether).

Don’t think of it as “living below your means”; think of it as “not living beyond your means.” I’m not asking you to take a vow of poverty here; it’s still ok to hang around with your gadget obsessed friends, just don’t get pressured into doing (financially) stupid things.

If all of them are carrying iPhones and Android phones just for show, why should you waste a month’s worth of effort on such a device instead of putting it in better investments? You will be teased, yes, but in the long run, who’s going to have a lot less financial problems when shit hits the fan?

–

Bonus:

Here’s what happens when whole nations get the “get a crapload of money but don’t know how to spend it” dilemma: The Resource Curse.

Busy day so just a short post for tonight:

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.

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.

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…

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.

“Transcript” below the cut.

continue reading…

Very busy week ahead. Here I am coding at 2AM in the morning instead of playing StarCraft or something.

Might as well make a quick post before continuing with work.

I first heard of the Beer Game in a presentation over at InfoQ. While not involving actual beer (boo!), the simple game provides an interesting glimpse at a certain management dilemma.

This game is played by teams of 4 players, each representing a part of a beer distribution supply chain: Factory, Distributor, Wholesaler, Retailer. The object of the game is to minimize the expenses involved in handing orders, namely the costs for stocking and the expenses caused by unfulfilled back orders.

The “kicker” here is that communication between the players are limited, some variations only allow players to order from each other and nothing else, while some variations of the game only allow the players to see the inventory of the next player in the supply chain.

The common result of this is the bullwhip effect: an oscillating period of over and under-stocking. For example:

• Retailer receives an order for 10 cases of beer. To anticipate for future orders, he orders 20 cases of beer from the Wholesaler.
• Having received an order for 20 cases of beer, the Wholesaler orders 40 cases of beer.
• With the same logic, the Distributor orders 80 cases.
• Finally, the Factory produces 160 cases.

Even ignoring the expiration of the product, one can easily see the waste produced by this scheme. There’s the warehouse stocking expenses. There’s also the expense in hiring employees to meet the sudden increase in demand, as well the expense in firing employees and shutting down equipment because of lack of demand.

And so we see the importance of visibility and transparency within a supply chain. When the suppliers upstream have the same information as the Retailer, it’s easier for them to decide how much to actually produce to reduce waste.

Note that this doesn’t just apply to manufacturing. Any situation with a work pipeline (e.g. software development’s Analyst-Developer-QA-Ops) benefits from increased visibility of resource utilization and work load.

I wasn’t able to post a Thursday post because:

• National Holiday (Eid ul-Fitr) meant that I had to be onsite on Thursday instead of Friday, and
• when I turned on my rig that morning, it beeped continuously won’t go to POST once, but booted properly the next time I turned it on.

A quick Google search told me the computer problem was probably a memory error and so I set my PC to run Memtest86 on a loop before going to the office. When I came back, my RAM passed 13 tests with no errors.

And then when I restart the PC the continuous beeping returned. =/

With the memory out of the question, thus began my 3-hour trial and error session to isolate the problem. PSU problem? Nope, multimeter reads normal voltages for all lines. Overheating? Cleaned off the dust from the CPU and video card heatsinks to no avail. Extra devices screwing with the motherboard? Removed all but the HDD and video card but still the continuous beeping happens once every few reboots. Heck, I even tried replacing my HD4850 with my spare GTS8800 to remove the possibility of a busted video card.

Another run through similar problems via Google gave me an idea: what if Memtest86 was wrong and it really was the memory?

And so I tried the Windows Memory Diagnostic that came with Windows 7.

In less than a few minutes, I found out that my RAM really was busted.

Memtest86 was trumped by a Windows utility program. Weird.

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…

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).

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

2. 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).
3. Run the DB migrations.
4. 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.
5. 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.
6. 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.
7. 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.