At first glance, this tweet in response to my previous post looks like a simple joke. But it’s actually true the more you think about it.

Understanding body language is important because software engineering is more about dealing with people than with software itself: almost all failed software projects are due to people problems (e.g. management and client problems) instead of technology problems.

Here are some cases where knowing body language can make a difference:

• A client asks for too many features under an impossible deadline – by gauging the client’s behavior, you can determine if she’s basically bluffing (to which you negotiate a compromise by reducing the scope) or if she’s really that stupid/sadistic (to which you drop the client for better ones).
• A developer puts in too many hours into overtime – depending on the dev’s behavior, a good manager would determine if that dev is simply temporarily getting brownie points for a promotion or upcoming long vacation. On the other hand, it may also mean that that dev is incompetent to the point that he needs more hours to fix his crappy code. At the worst case, it may also mean that that dev is already at stage 2 – 3 of going into burnout.

Another non-technical language you need to learn is Basic English.

Go ahead, laugh. But then recall the last time you’ve seen a “plz send me teh codez” post in a public forum or a job posting full of misspellings and grammatical errors (a big warning sign) and you’ll quickly realize how important it is to have a good grasp of the English language.

Lack of proper written English skills is a somewhat widespread problem in the current generation, with the prevalence of text-speak and the fact that a lot of young people don’t join international community websites/forums/mailing lists/chat rooms. This can be a problem when they enter the corporate world, where semi-formal English is the lingua franca: I’ve even heard of stories of project managers re-writing some of the team members mail before sending them to their foreign counterparts because of their poor English.

Note that your English doesn’t need to be at the level of essayists or other professional writers. In fact, simple, direct to the point (but at the same time, polite) messages is much more effective at communicating to clients or team members when compared to long-winded messages full of highfaluting words. Doubly so when dealing with clients whose primary language isn’t English.

To wrap things up, I just realized that I wrote about a similar topic a few years ago. You don’t need to click that link, as the tl;dr is just the same thing I’ve been saying all the time: developers need to learn more than just coding.

My Game Jam post is waaay overdue but some stuff happened this week (impromptu upgrade, server migration) so I’ll only get around to post about it probably later today.

Anyway, this post is just about the new version up over at RailsFTW. This experimental build is based on TCS’s patched Ruby build which boasted a ~200% increase in performance.

See it for yourself:

Still hung-over from Global Game Jam 2012 (mini-write-up later) when I went to the RailsInstaller site on a whim.

Noticed that it still isn’t using Rails 3.2. So I decided to update my own to be ahead again.

Hopefully this would be the last RailsFTW version (hoping Luis would be able to convince Wayne to include MySQL to RailsInstaller so I won’t need to this anymore LOL).

That little app/wallpaper we made at the code retreat? I’ve published it and it’s now free for download at the Android Marketplace.

At the moment it’s not properly indexed in the Marketplace yet so searching “Game of Life Wallpaper” won’t return the link. A workaround is to search it using the search terms “code retreat“.

No, there won’t be any obvious things here (e.g. the laptop, netbook, tablet, etc). I prefer not-so-obvious items that are mostly relevant to my interests.

–

Ignoring the recent thing with the floods in Thailand, upgrading your hard drive is probably the most practical upgrade you can do with your computer nowadays regardless if you’re using a laptop or a desktop. Mechanical hard drives are getting more efficient in terms of capacity while SSD’s are getting cheaper and faster.

Unfortunately, there’s the problem with what to do with the old hard drives. For instance, when I bought a 2TB drive, I had enough storage space to replace 3 of my hard drives. So then I had 3 hard drives that I didn’t have any use for.

At this point you might guess “oh he’s going to suggest buying an enclosure“.

Sorry, but no. Enclosures are ok if you just have one disk drive on hand. But if you’ve got a bunch of SATA drives, changing drives can be a hassle: you need to open the enclosure to replace the HDD inside.

What I’d suggest is to consider getting a docking station.

Yes, it’s basically a device that turns your spare SATA HDDs into huge flash drives (or diskettes, if you’re from my generation).

At USB 2.0 speed, you’d get around 32MBps transfer speeds which is good enough for backup purposes but too slow for general IO-heavy program use. If you’ve got a motherboard that supports USB 3.0, you may want to check this one out as it supports that newer standard.

–

What if instead of upgrading your hard drive, you instead upgrade your video card to an Eyefinity-equipped AMD card hoping to get some of that single-card triple monitor action.

But what if you chose to get three non-DisplayPort monitors and you didn’t read the online discussions saying that you need at least one DisplayPort monitor to enable triple monitor mode?

Or what if you do get a DisplayPort monitor, say any of these two monitors from PCHub, but realize that your card and monitor doesn’t come bundled with a DisplayPort cable? Sure, there are DisplayPort cables out there, but the only shop I’ve seen carrying them in Makati (Octagon) only carries the 2 meter cables worth P1.2K.

So how do you pull off setup below (relatively) cheaply when you’re living in Metro Manila?

The trick here is that all DisplayPort to VGA adapters are “active” adapters, and thus will be treated as a full DP connection (when you use a “passive” DP to DVI or HDMI adapter, the ones only available in the country, it’s not treated like a DP connected monitor but as another DVI/HDMI connected monitor).

Luckily for me us, CD-R King carries DP to VGA adapters.

–

This last item is like the windmill of the previous list: it’s not really practical, but still pretty notable on its own right.

That is a bladeless Dyson Air Multiplier fan, another innovation from the famed industrial designer. It sells for $299 directly from Dyson.

And that is the bladeless air multiplier fan sold by CD-R King.

Comparing the two products side by side, one can see that they’re practically the same product. While it’s likely that the latter is a cheap knockoff of the former, you can’t totally discount the possibility that these are just rebranded surplus stock of the original, a common MO for CD-R King products. (Update: I have reason to believe that these are Chinese knock-offs. Also you may want to check SM if they have similar knock-offs.)

I’ve seen the fan displayed and demoed in some stores, but honestly, I’m not really impressed. Sure, the dimmer (potentiometer?) switch for fine-tuning the strength of the fan is pretty cool (pun intended) and the lack of blades makes it ideal when around kids (but robs them of the robot voice/ghetto auto-tune experience), but overall, it’s just too expensive for the average person.

Still, it is five times cheaper than the original. For some people, to experience how it feels to have such a device around without paying an extra 10K (or more, thanks to the wonderfully corrupt Philippine customs bureau) may just be worth it.

–

A word of warning, though. The items above are pretty rare and it’s only at the Cubao Farmers branch that I’ve seen all three on display (though not at the same time).

Thanks to a Battlefield 3 Beta losing streak that I blame on my sucky internet connection, I’ve decided to update my hack-job of a standalone Windows installer for Rails.

Now there are two separate installers, a Ruby 1.8.7 + Rails 3.0.10 installer and a Ruby 1.9.2 + Rails 3.1.0. Here’s a table to give a quick comparison between these two installers with RailsInstaller thrown into the mix:

For reference, the previous tutorial can be read here.

–

Every Rails developer knows how to create a Rails app. It’s easy as

rails new APP-NAME-HERE

But how many know how to create an app from scratch that looks good enough to sell to clients i.e. with slick design, authentication, authorization, and all that? Sure, there are tutorials out there that cover those components, but most of them cover them only in isolation from each other. A quick tutorial containing multiple components at a time would be a valuable resource to anyone planning to start a new app.

As the resident dilettante in these parts, I’ve decided to create such a tutorial based on a recent demo I made for a prospective client.

This post will discuss how to create a Rails 3.1 application that looks good enough to sell to clients (of course, YMMV) while still having components found in “professional” apps. This tutorial will cover the following:

• Andrea Franz’s web-app-theme gem – this gem generates themes for your web app (hence the name). The demo and the list of available themes can be found on this page.
• Devise – our authentication module. Authlogic‘s fine, but I find Devise’s approach less obtrusive.
• Haml – replaces Erb. Not perfect (e.g. screws up with inline a tags) but the drastic decrease in code makes passing it up difficult.
• Rspec – replaces Test::Unit. Only setup will be covered in this post, actual usage is left to the reader.
• Kaminari – gem for pagination. We’re going to use it in place of the previous gem will_paginate

Rest of the tutorial is below the cut.

Let’s start by creating our new app with no testing framework and with MySQL as the database:

$ rails new pro-template-app-31 -d mysql -T

Now would be a good time to edit the .gitignore file to exclude files you don’t want to add to Git. Rails 3 already provides some good defaults, but if you want more possible entries there are samples available over at Github.

Once done, it’s time to make the initial commit.

$ git init
$ git add .
$ git commit -am "initial commit"

Setup Gemfile

Now is time to add the needed gems to Gemfile.

source 'http://rubygems.org'

gem 'rails', '3.1.0'
gem 'mysql2'
gem 'haml'
gem 'devise'
gem 'kaminari'

group :development, :test do
  gem 'capybara'
  gem 'rspec-rails'
  gem 'haml-rails'
  gem 'hpricot'
  gem 'ruby_parser'
  gem 'web-app-theme', '~> 0.8.0'
end

I’ve already explained most of the gems above at the beginning of this post. The only thing worth noting would be the addition of hpricot and ruby_parser, both of which are needed by web-app-theme to generate haml files.

Run “bundle install” to install the gems. After the gems are installed, all of our generators will now use Rspec instead of Test::Unit, and it can now generate Haml instead of Erb.

Generate home page

Let’s try out our app first by creating a new root page to replace the default.

$ rails g controller home index
 
$ rm public/index.html

Then edit the config/routes.rb:

ProTemplateApp31::Application.routes.draw do
  root :to => "home#index"
end

Before starting the app, don’t forget to create the database:

$ rake db:create

Start the server.

all pictures are clickable BTW

Generate theme with web-app-theme

Here comes the fun part.

$ rails g web_app_theme:theme --engine=haml --app-name="My Latest Web App"

This will generate the layout files using the default theme in haml whose title would be “My Latest Web App”.

(In case you want to use a different theme, add --theme="THEME-NAME" to this and some of the later commands.)

Delete the default layout generated for the rails app:

$ rm app/views/layouts/application.html.erb

then refresh the page.

It looks good, but I think we’re better off using the sample text page from the demo site.

$ rails g web_app_theme:themed home --themed-type=text --engine=haml
 
$ mv app/views/home/show.html.haml app/views/home/index.html.haml

Tweaking web-app-theme v0.8.0

Before we continue, let’s first fix some problems with web-app-theme 0.8.0 when used with Rails 3.1.

First, generate a copy of the current theme to your app so that you could modify them.

$ rails g web_app_theme:assets

Now for the tweaks:

• JavaScript tag doesn’t point to the one generated by the asset pipeline. This is the reason why the sign-out links won’t work if you followed the previous tutorial. Fix here.
• The stylesheet for alert messages are still defined under “error” class. Fix here.
• For some odd reason, the images for buttons were moved to the spec folder. You can bring them back by manually copying them to your project’s web-app-theme asset folder. Here’s one way of doing it:

$ cp $(bundle show web-app-theme)/spec/dummy/public/images/* app/assets/images/web-app-theme/ -r

Add Devise authentication

Let’s install Devise and create our User model in the process.

$ rails g devise:install
 
$ rails g devise user

We also need to customize the login screen. To do this, we must first enable scoped views for Devise.

Then let’s generate the sign-in/sign-out layout:

$ rails g web_app_theme:theme sign --layout-type=sign --engine=haml --app-name="My Latest Web App"

Then let’s add the following files to the config/application.rb file to change the layout for sign-in/sign-up:

    config.to_prepare do
      Devise::SessionsController.layout "sign"
      Devise::RegistrationsController.layout "sign"
    end

At this point, you could generate the Devise views via

$ rails g devise:views

but the generated files are in ERb, not to mention that the layout for the sign-in/sign-up pages are different from what web-app-theme expects.

To save you from the hassle of copying the layout of those two pages, you could just copy-paste what I did here and here.

Restart the server, run rake db:migrate, and try going to the login site (/users/sign_in).

Clicking “Sign up”:

Finishing touches to Devise

Let’s do some finishing touches to the UI.

First, modify the layout such that the logout button actually works.

Now to test if Devise really works. Add the before_filter :authenticate_user! to home_controller.rb to kick us out to the login screen if we’re not logged in. While we’re at it, modify the said controller to set tell sign-out to redirect to the sign-in page.

Create a test user via the rails console.

$ rails c

User.create :email => "test@example.com", :password => "123456", :password_confirmation => "123456"

You should now be able to login and logout.

Theming a CRUD module

Now let’s show how to add the web-app-theme to a new CRUD module. To simplify things, we’ll use the ultra-stupidsimple blog demo.

$ rails g scaffold blog_entry subject:string content:text publish_at:datetime
...
$ rake db:migrate

Overwrite the generated files by running web-app-theme’s generator:

$ rails g web_app_theme:themed blog_entries --will-paginate --engine=haml

Since we’re using kaminari, we need to modify the controller and index page accordingly.

We will also have to modify the kaminari template to match the CSS. First generate the view files via

$ rails g kaminari:views default -e haml

then modify the files to match the layout with the demo page. Here’s one way of doing it.

We also need to modify the layout to take into account the new module.

After that, you can still do a couple of minor tweaks to the pages to deal with their “auto-generated” jagged edges. Then you can also apply the error message fix (don’t forget to restart the server) and test it with the screens.

And that’s it. The complete code generated above can be found at Github.

UPDATE 5/3/12: Changes to make things work in production

Looks like this thing doesn’t work in production. Please see the latest commit in Github (1, 2) for my fixes.

I’ve changed the layout stylesheets to use application instead of web_app_theme and also changed app/assets/stylesheets/web-app-theme/themes/default/style.css to an ERb file using asset_path to point to the precompiled assets.

There’s also a bug in Rails 3.1.0 which requires a change in the production settings. You can choose to either apply that fix, or simply upgrade to a more recent version of Rails 3.1.

The change required is pretty simple actually, just as long as you understand what I did in that tutorial. First, you need to tell Rails to override Devise’s RegistrationsController’s layout to use the “sign” layout (just as what we did with SessionsController which handles the sign in):

    config.to_prepare do
      Devise::SessionsController.layout "sign"
      Devise::RegistrationsController.layout "sign"
    end

Then modify the app/views/devise/registrations/new.html.haml file accordingly. If all goes well, you should get something like:

The steps to convert the “Forgot your password?” page is left to the reader.

Yeah, yeah, so I’m late with updating to the latest security releases…

Just a quick update adding the latest version of RubyGems (1.5) and Rails (3.0.4). Also chose not to remove the cached gems to make bundle install run faster.