WordPress has been good to me however I’m moving my operation to a new web site, railcar88, and a new blog. The chaiapodi name was birthed early on and as things progressed with my business, I decided to change the name to Rail Car 88.

In the new blog, you can count on me to focus on:

Technology – programming, operating systems, software, productivity
Design – css, user interaction, typography, graphic design, architecture
Business – startups, finance, management, freelancing

My goal is to open source my experience as an entrepreneur. I will share my failures and successes by posting through text, podcasts and screencasts. These artifacts will serve as an archive of my experience and a learning tool for visitors and myself.

So please visit me at the new blog for information related to technology, design and business.

So I’ve reverted back to xubuntu. I use the xubuntu alternate install CD. Due to the limited system resources on my Gateway laptop (less than a GB Pentium 3 and 256 KB RAM), I cannot use the regular install CD (it crashes midway through the installation). The alternate install CD works beautifully. I can get the entire install done in about 50 to 55 minutes.

Using Ubuntu as the yardstick for comparison, xubuntu looks great on the desktop. It has a nice blue wall paper. The selection of automatically installed packages is well devised. If I don’t need or want an application I am free to uninstall.

Initially, the screen resolution on my Gateway is set to 800×600 which is a bit too big for my tastes. After reading a multitude of blogs and articles, I have cobbled together a recipe to solve the screen resolution problem specific to my Gateway.
Run this command from a terminal:
sudo vi /etc/X11/xorg.conf
Make modifications to these sections of the file:
Section “Device”
Identifier “ATI Technologies Inc Rage Mobility M4 AGP”
Driver “ati”
BusID “PCI:1:0:0”
EndSection
Section “Monitor”
Identifier “Generic Monitor”
Option “DPMS”
HorizSync 28-64
VertRefresh 43-60
EndSection
Section “Screen”
Identifier “Default Screen”
Device “ATI Technologies Inc Rage Mobility M4 AGP”
Monitor “Generic Monitor”
DefaultDepth 24
SubSection “Display”
Depth 24
Modes “1024×768”
EndSubSection
EndSection

Perform a reboot. The screen resolution should now be set to 1024×768.

Now if only to get WPA2 to work with Network Manager or WICD using my Linksys WPC54G wireless card……..

I REALLY wanted to run OpenBSD on my old Gateway Solo 9500. The OpenBSD philosophy of correctness and security resonates with me.
After fighting the install of 4.2 for many hours and then fighting the first boot for many more hours. I decided to take the path of least resistance (i.e. cut my losses) and try other distributions. I tried xubuntu, fluxbuntu and ubuntulite.

With xubuntu and fluxbuntu, I had major problems with the display resolution (something like 800 x 600 with no option to resize).

I have settled on ubuntulite as the display resolution is perfect and I really like the openbox windows manager. The philosophy of these distributions is to be lite on resource usage so that older machines can still be useful. My Gateway laptop has 256MG RAM. In 2008, that doesn’t take one too far. My requirements are that the screen resolution is adequate (at least 1024 x 768) and that I be able to use vncviewer via wireless connection.

Some outstanding issues that I am still haggling with are:
Most of the time I have to boot numerous times before the machine will go through the entire boot. I can live with this as every ubuntu distro. that I’ve tried on this Gateway laptop has given me the same behavior.

I’m trying to use vncviewer to tap into another box and I am not able to communicate. Although I can connect to the router, I am also unable to ping the given box. What is ironic about this issue is that I did not have this issue with fluxbuntu or xubuntu. I had display resolution issues but the vncviewer worked great.

Anyway, I’m going to give these issues a rest for a while as I have more pressing work in the pipeline. I’ll try to keep my progress updated.

Using ruby on rails as the search criteria, I recently performed a catalog search on the Columbus Metropolitan Library web site.

First, the thumbnails of the books next to the book description and other information have an Amazon/Agile Web Development with Rails:Depot Application look and feel. This method shows the product while giving its corresponding information in a concise manner.

discover_cml_ruby_on_rails.jpg

Second, the graphic on the left shows the search criteria in the center (ruby on rails) and any number of associations, translations, spelling variations that might be connected with it. For instance if one clicks on a spelling variation link (grails), the grails label moves to the center of the graph and its corresponding associations, translations, spelling variations, etc. then display.

discover_cml_grails.jpg

I found this to be a unique way to graphically show the search result and provide other results that may or may not be helpful in providing the customer with the correct search term.

I commend the designer who implemented the redesign of the search result page. I’ve not seen a graphical display like this one that is both helpful and logical.

VIM wins the day

November 4, 2007

In my most recent post I elaborated the glories of the Scribes editor. While I still believe Scribes is a wonderful editor I couldn’t get past one technical requirement….its dependency on gnome. If you are a programmer who only works on machines that run gnome, then go with Scribes.

The VIM (Vi Improved) editor is the editor that I will use. Learning the basic VI commands will come in handy as virtually all unix and unix like systems have it pre-installed. I like the idea of going to any unix machine and being immediately productive. Vi has been used for years by top notch engineers/programmers and has benefited from the accumulated knowledge and improvements of these individuals. As they say, “We stand on the shoulders of those who came before us”. VIM also has numerous scripts for rails that make it even more productive.

For me, the main drawbacks of VIM are the user interface and the steep learning curve. I’ve always wanted to use an editor that was pleasant to look at like Scribes or Textmate. In the end, although the aesthetic of the editor is important it’s not a deal breaker. I’ve always been intimidated by VIM and Emacs due to the sheer number of commands and skill that it takes to get the most out of them. I’m ready to make the time investment so I can take my productivity to the next level. For others, VIM’s use of modes to switch between operations can be disconcerting.

An oft cited advantage of using Vi/VIM is that it is less strenuous on the hands therefore it reduces the chances of repetitive strains on the hands which can lead to long term injury. I like it because I can stay in the home row on the keyboard instead of using the arrow keys to move around in the file.

In my previous posts, I’ve mentioned that my text editor of choice was jEdit. The main reason I chose jEdit was because it is a multi-platform editor, that I could use on windows and Linux machines. It is also very configurable – especially for Ruby/Ruby on Rails development.

For the last few months, I’ve moved on to Scribes. Scribes focuses on providing a great editing experience by keeping things simple and making text editing productive.

Some of the best features are:
Templates/Snippets that allow a user to type just a few characters, hit tab and have the code automatically populated in the file.
Auto-complete for words used more than once in a file.
Numerous shortcut keys.
Moving the editing window around on the screen without the use of the mouse.
Open document browsing and switching
Many more…

To see the editor in action watch the a demo. The creator of the Scribes editor has an opinionated blog. I thoroughly enjoy his design justifications and writing style.

Today I completed Peopleware Productive Projects and Teams by Tom Demarco and Timothy Lister. If you go to Amazon and look at the customer reviews, you will find a five star rating. The second edition of this book was released in 1999 yet the subject matter of the book is just as relevant today as it was then. Demarco and Lister know the software industry and how the process of software development can be improved. They expose problems in the software development industry that hurt productivity and try to provide solutions to improve the process.

The two items I found to be most interesting were:

1. The project estimation section.
2. The importance of the software development work environment.

The premise of the project estimation section is Parkinson’s Law. Parkinson’s Law is the thought that project deadlines need to be set impossibly tightly to create a sense of urgency. The theory is that developers will increase the project work to meet the time allocated for the project. Demarco and Lister cite a University of South Wales study that measures programmer productivity when people in different roles are responsible for estimating the project. It compares projects that were estimated by the programmer hisself/herself, prepared by the supervisor, the programmer and the supervisor or a system analyst. Given these options the projects estimated by the Systems Analyst yielded the highest productivity. The astounding metric is that the highest productivity was achieved when a fifth option was added – no project estimate. It amazes me that in spite of the common wisdom that we must estimate the project or it will not be productive, the most productive method was when no project estimation was performed!

The other subject in the book was about the software development working environment. The summation of the section was that programmers are most productive when they have adequate space, quietness and less distractions such as phone calls and colleagues visiting with needless questions. They also work better when people doing similar work are placed in the same area. Offices with doors are much preferred to open cubicle spaces that increase distraction. I think most programmers would find these conclusions to be common sense. How many of us can say that employers are sensitive to these needs?

There are many other interesting subjects in this book and I highly recommend it to programmers and programming managers alike.

I must say I truly enjoyed the autobiography of James Dyson. He is the British designer/manufacturer of a line of fast selling, high technology vacuum cleaners.

Dyson makes a point of being different…not for the sake of being different but for the sake of his own convictions. This led him to question conventional paradigms. He embraces the individual as the underdog against the big corporations. He laments the diminution of the inventor versus the power of multinational corporations. He challenged industries that were ingrained in the psychology of culture. He aggressively improved the common wheelbarrow. He has all but conquered the vacuum cleaner market by not only inventing better technology but by making the vacuum cleaner an object of design envy. Now he is giving the common washing machine a design and engineering makeover.

This book is all about design, engineering, business, marketing, manufacturing and distribution. James Dyson seems to brilliantly do well at all of these disciplines. These skills did not come automatically for Mr. Dyson overcame many setbacks and doggedly pursued his goals on his own terms. This book chronicles his ascent to success and also shows how Mr. Dyson’s personality marks his company and his products.

I found this book to be an education and an inspiration. I would recommend it to anyone who aspires to be an entrepreneur.

This is my response to the Humanized Blog – Good Service — Bad Software

A provider of proprietary software has every incentive to keep the customer a happy user. Many times that means understanding that software users come with various skill levels. Some read the manual and scour the web for answers before calling for support. Some users just aren’t as inquisitive, have extreme time constraints or are jack of all trades generalists. These users require hand holding and since they paid for the software have an inherent right to expect a company to help them use the product otherwise they won’t be paying the subscription or buying the upgrade. They also expect that a company support person won’t give them a condescending attitude, tell them to read the manual or make other wise cracks – no matter how simplistic the support question.

I’d like to say that I am a happy user of open source and proprietary software. I appreciate the skill and brain power that is required to produce such magnificent software tools. In the proprietary world, my appreciation is largely shown through my monetary investment in the software. Some of the real ways I can pay the creators of open source software are to make donations, contribute code to the project, or promote the software through blogs, word of mouth etc. All of these forms of compensation are acceptable and valuable however they don’t form an implicit contract between the makers of the software and the user. As a user I cannot hold anyone accountable if I am not receiving the open source support that I would expect from proprietary software makers. I must depend upon the kindness, good graces and mercy of the user community and the authors of the software. I don’t have leverage in the relationship.

The maker of open source is not beholden to the user. Of course the makers of open source software understand their own software. The users of the software must largely conform to the vision and design of the software maker. If they don’t like the design they are free to change it themselves – the source is provided. If they have a question they can ask but are not guaranteed an answer.

The power in the relationship rests largely with the makers of the software. The makers do not have a vested interest in either creating user friendly software or providing user friendly support. This relationship between the maker and the user is fertile ground for user frustration.

I am left to an old adage, “there is no free lunch”. Open source is wonderfully free. The cost often comes in the form of less than desirable usability and hit or miss support.

Days ago, I decided to install RMagick in my environment with the goal of working with Gruff Graphs for Ruby. Initially I was getting segmentation faults. Something I (sadly I was unable to track this down) did removed that error and then for the longest time I was dealing with an error that involved rmagick.so and libMagick. The error message said that I needed to recompile using -fPIK and also something about not being able to share a file. As I did Google search after Google search, I was able to cobble some background information that helped solve the problem but not the solution to the issue. Unfortunately, I did not save this error message otherwise I would provide it in this post.

I found the solution in this post at the RMagick forum at Ruby Forge. The solution was not to install both GraphicsMagick and ImageMagick because it can confuse RMagick at install time. After reading the post from the RMagick Forum, I uninstalled both GraphicsMagick and ImageMagick. I then reinstalled ImageMagick from source tar ball and finally I successfully installed the RMagick Gem.

These are the more helpful links to get RMagick running:
RMagick FAQ
RMagick Project
ImageMagick Project (or if you prefer GraphicsMagick Project)

and for any issues:
RMagick Forum

Many thanks to Tim Hunter for RMagick and for being so patient and responsive to RMagick users.