There are different ways to start your application out right. Some work on TDD methods, some equip their teams with good QAs, the others rely on extremely efficient project management and strong system administration. But the building of a good rails application does not only depend on code alone and its processes…

The blackbook gem, though not really maintained well right now has still been a good solution for my needs in networking stuffs. Although, recently pointed out by Marco Fang was some trouble with Gmail changing the way data is retrieved via the API.

Previously, a query for contacts via..

I’m excited to have found RubyRun! I’ve just got the gem, but haven’t really fiddled with it. I’m gonna have it tested soon. I’ve heard about NewRelic and other stuffs too, but this one is new. We used to work with just bleakhouse, and I’ve tried dike. They are both hard to use and takes a lot of analysis to extract good info from it.

I’ve been a developer for almost 10years now, yet I haven’t done any implementation of an address book importer. Well, this is the first time.

Since I started using symfony, I started to love its framework. Later on, I moved to using Ruby on Rails. Ever since, I loved working on Rails, and see myself wanting to create more Rails applications that would be better and more beautiful each time. That is why I always welcome the things I don’t know. I want to spend more time learning than simply perfecting what I already know.

Enter Rails address book importer.

My site is still young and contents aren't that many right now, but what I really enjoy doing is making all the pages look better and be more usable. One thing that I recently gave thought on were my error pages.

I tried to advertently access a missing page, and I was greeted with my old one liner text and a suggestion to visit my blog. At the bottom of it was my twitter feed. It had the same layout as the rest of my site's pages and had the usual links on the right side. Funny though, when you access this missing page, it did take the usual loading time only to be displayed with such a page. And so I thought it needed a revamp.

Programming in Ruby on Rails introduced me to agile software development. I have been used to development in the traditionally confusing and dirty process of coding system. Agile development is different.

In the good old waterfall model, there is a strict flow of activities and process that is followed in the exact manner as they are described. What I really liked about agile method is that its ability to be adaptive, thereby allowing more programmer sanity. As defined by Wikipedia,

Some of the principles behind the Agile Manifesto are:

* Customer satisfaction by rapid, continuous delivery of useful software
* Working software is delivered frequently (weeks rather than months)
* Working software is the principal measure of progress
* Even late changes in requirements are welcomed
* Close, daily cooperation between business people and developers
* Face-to-face conversation is the best form of communication (Co-location)
* Projects are built around motivated individuals, who should be trusted
* Continuous attention to technical excellence and good design
* Simplicity
* Self-organizing teams
* Regular adaptation to changing circumstances

It has long been a debate on how to describe 'good code'. What are the criteria for declaring a code to be good, neat, and dry?

My advocacy is to promote writing good quality code. It is by painstaking practice and tons of reading that I get to exercise this advocacy. It is but a long journey, but little steps lead you to understanding and qualifying a code to be of high quality. So what are my benchmarks?

• Long codes are less readable and more likely to fail.

Ruby scripts are far smaller and more compact in size compared to Java codes or C++ codes. Trust me, I've seen some and comparing them to Ruby, reading Java codes or C++ codes that are not mine would take me a longer time for understanding (even if docs and other help materials are present). Ruby has good metaprogamming (that sometimes gets abused because of monkey patching) and produce straightforward codes. Each line would end up more like real English sentences.

If you write ruby codes that take up to more than twenty lines.. hmm.. well, its doomed to fail, for sure. Refactor and review!

• Codes that don't look anything like its API source is really smelly.

APIs are there for you to use as a general sitemap. It is your guide to efficiently write code with ease. Usually, APIs are well documented and even provide examples or snippets of codes to demonstrate its use. The lines of codes involved may also be present for you to inspect its process and even predict if it will pass your expectations.

I’m just a new user of Mephisto, and I find that its a mature blogging platform (that still has a lot to improve though). I’m liking it already, but I feel that there aren’t much resources available for the Mephisto users. I had a hard time finding a theme that suits my taste, and so I decided to use my own.

As I was writing my own layout, I had to look at liquid markup and quickly breeze through it so that I could go on with fixing my blog. To my surprise, even the Google Group for Liquid were not so kind enough to post answers to those questions related to “using helper methods in liquid layouts/template”.

Its sad that I had to work on it on my own. And now that I finally learned how to do it, I’m sharing it with you.