existence, refactored

One of the questions raised during the last Rails training course I held was “Can Ruby on Rails work with XAMPP?”

With this new version of Rails FTW, the answer to that question is YES.

Download Rails For (the) Windows v0.1

latest version is v0.4. grab it here

OK, so this version doesn’t install mod_rails on XAMPP, but it does allow you to get around the headaches involved in making Rails 3 work with MySQL on Windows.

Here’s a basic rundown of the changes from the last installer:

• The mysql2 gem still doesn’t work for Windows so I included the old mysql gem instead.
• Like what I did with SQLite in the previous installer, I’ve included the DLL for MySQL (libmysql.dll) in the bin folder. MySQL 5.1 doesn’t work with the mysql gem so I used the DLL file from the latest “no install” package for MySQL 5.0 (mysql-noinstall-5.0.91-win32.zip).
  I know, Oracle will probably sic their lawyers against us if they catch wind of this project. Hopefully the MariaDB or SkySQL guys would give us an open replacement DLL file in the future.
• I’ve modified the Railties gem to replace instances of mysql2 to mysql (e.g. database.yml, Gemfile).
• Minor change: add a line to config to remove log coloring (useless in Windows)
• Minor change: in the installer, the Add to PATH option is checked by default
• Minor change: remove gems from gem cache to reduce installer size (a facepalm moment -_-)

Rundown of the quick blog app demo using this installer below the cut.
continue reading…

Back in college, we Computer Science guys had the distinction of having the second highest number of Math related classes in the university (BS Math obviously comes first). Given what I said about college education in a recent post, you might think that I would’ve preferred if the curriculum didn’t have those classes, and instead added classes on web development and design patterns.

I actually think otherwise.
continue reading…

Second Rails post of the week. I don’t really mind since it’s just going to be a small post and would let me reach my 2 post per week quota this early.

Remember that post about Ruby on Windows? Well, one thing led to another and PhRUG thought it was a good idea to fork the RubyInstaller to create an installer which includes everything one needs to create a Rails 3 app (Ruby + Rails + SQLite). Being the sneaky guy I am, I decided to create a proof of concept installer by hacking away at the RubyInstaller source code.

Here’s that installer: Rails For (the) Windows, version 0 (edit: latest version is v0.4. grab it here)

With this installer, you can create Rails apps in just a few steps:

1. Download and run the RailsFTW installer.
2. Start Command Prompt with Ruby. If you ticked “Add Ruby executables to your PATH” in the install process, you can simply open a normal command prompt

From there, you can now create the 5-command rails app:

C:\Users\me> rails new blog
C:\Users\me> cd blog
C:\Users\me\blog> rails generate scaffold entry subject:string content:text
C:\Users\me\blog> rake db:migrate
C:\Users\me\blog> rails server

You may have to unblock ruby in the firewall prompt to make the server work.

Open http://localhost:3000/entries to see your new app.

We still have a long way to go before we could supercede InstantRails, but this little hack job looks promising. Luis Lavena, a main contributor to RubyInstaller, even approves of this venture. Maybe later we could move on to other Ruby frameworks… Merb FTW or Sinatra FTW anyone?

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…

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.

I never got around to post the follow-up article on Lean and how it relates to software engineering. Now, over 7 months and a huge scandal that made people skeptical about Toyota’s lean manufacturing later, here’s the post on Agile software development.

continue reading…

Habit #17 Failing to express gratitude

Dale Carnegie liked to say that the two sweetest words in the English language were a person’s first and last name. He maintained that using them liberally in conversation was the surest way to connect with a person and disarm them. After all, who doesn’t like to hear their name on other people’s list?

I’m not sure Dale was right. To me, the sweetest words in the language are “Thank You.” They’re not only disarming and pleasant to the ear, but they help us avoid so many problems. Like apologizing, thanking is a magical super-gesture of interpersonal relations. It’s what you say when you have nothing nice to say—and it will never annoy the person hearing it.

-from “The Twenty Habits That Hold You Back from the Top” from the book “What Got You Here Won’t Get You There”

That book still lies unfinished on my desk because of this section alone. Out of all the business and human relations books I’ve read in the past year, none has been so naive, so misguided, so “let’s feed the fantasies of middle managers everywhere!” than that book, and this section highlights it so well.

continue reading…