August 29th, 2009 — Planet
It's really been some time since I wrote something. I've been really busy - more than usual busy with all the projects but additionally busy trying to workout a solution to some of my perennial problems.
I finally managed to read The Passionate Programmer. It almost felt like reading my own notes. Over the past few years I've been talking and writing about quite a number of issues from this book. It's almost unbelievable that somebody has so similar views. Starting with the saxophone experience - I played saxophone for 10 years - I can relate really well to Chad's stories and parallels. Of course, that's not to say that because some things work in music they will work in programming as well. As Martin Fowler once said software development is software development and we shouldn't be comparing ourselves to other industries and drawing misleading or wrong parallels. Anyway, regardless of whether the conclusions are right or wrong the flashbacks to saxophone playing experience added extra level of depth (at least for me).
Out of the many ideas that struck a cord with me...here are a few I noted down
Invest in Learning
The nerve!!! Judging by the reactions I receive whenever I talk about importance of proper education and practice for programmers - it's ranking among the worst insults you can ever make. Every programmer worth his salt knows that learning is for dummies. We were born better than them (basically everybody else). Sarcasm aside, I believe that a lot of programmers would benefit from experience of playing a musical instrument. Daily (i.e. every day) practice and performances. When you're performing on stage without practice - okay let me rephrase that - when you're on stage without hundreds of hours of practice - you're very likely to screw up - and if you do you're like naked. There's nowhere to hide. The whole audience looking at you and everybody knows it was you who screwed up. Believe me, the next time you'll think more than twice before coming on stage without proper practice. When you program without practice (or learn on the job) you're just as likely to screw up...the only difference is that you can blame it on the customer, on the specs, on the technology, or whatever or whoever else around you. Many times you can just comfortably hide behind your boss as he/she is the one facing the customer.
Work expands so as to fill the time available for its completion
This is an interesting concept. In the industry where everybody complains about way too tight deadlines - Chad goes on to say that just by making the deadlines even tighter you can easily double or even triple your productivity. While I am still to meet an employee that would confirm this - it's definitely true for me and all my ex-staff that went independent. It's really fun to see that things that took them several months to finish while being employed can suddenly be done in a month when they're on their own.
Writing Skills
"If you can’t organize your thoughts in your mother tongue so that others can clearly understand them, how can we expect that you can do it in a programming language? The ability to shape an idea and lead a reader through a thought process to a logical conclusion is not much different from the ability to create a clear design and system implementation that future maintainers will be able to understand." While this politically incorrect statement would get you to prison in a number of countries it's surprisingly true. And quite opposite to the geek stereotype. Interestingly enough, ability to speak and organize thoughts clearly has become a very important factor for us. Try to notice the similarities between way people speak and code - if you have a programmer that is very verbose - talking, talking, talking and still not making the point clear - chances are his code will be very similar - long winded, using unnecessary constructs and never quite clear on what it's supposed to do. On the other hand, if you have an introverted programmer that says 10 words a day, chances are his code will be very terse, taking one liners to the whole new level.
Businesses and those who run them are interested in business results
A thing you learn really fast when you're on your own but it's your biggest enemy when you're an employee. I remember a fight I had with one of my employees - his conclusion was that he just wanted to have a life. And he was right. Why should he worry about the deadlines or delivering what the customers needed? His goal was to have a life and the work was one of the main constrains - there was no direct link between his performance and quality of life. Not seeing and understanding this was my biggest failure running the business earlier on. While we had the basic performance based structure in place it was so detached from the company's culture and pretty much left for everybody to make their own interpretation. The challenge is to reorganize from a black box to a concert stage where everybody is crystal clear on how his performance is linked to the achievements of the whole team and how that translates to the distribution of rewards. Chad puts it very bluntly: "Sure, you got it done, but what was it? Why did it matter? How was this so-called accomplishment not just a waste of company time?" He couldn't be more right. I cannot even count how many times people told me that they had been making sacrifices, sitting in the office 8 or 9 hours every day and I still complain about their performance. The issue here was that while they counted hours I was counting closed iterations and customer satisfaction.
It's easy to get hung up on technology choices
Especially when our technology of choice is the underdog... I believe this idea comes from the Pragmatic Programmer - something along the lines of when all you have is a hammer everything starts to look like a nail. I've always tried not to be attached to technology, however, having a 50 projects investment in a technology makes you very close to being dependent on whatever choices you made. Yet, an investment in wrong technology - no matter how much you like it is usually much higher than investment in a different technology that is actually right for the job.
Go independent
This is quite a dangerous point. While definitely true - there are uncountable advantages to running your own show - just go for any motivational seminar by T. Harv Eker, Robert Kiyosaki and the likes - but being the best technician is only a start. Even though, based on the book 50 Great eBusinesses there's a number of teenagers without any experience that are managing billion dollar businesses (or one man shows) out of they're parents living rooms - vast majority of businesses and people are not so lucky. While Chad describes this as natural next step and spends only a few pages explaining the benefits and some of the obvious challenges it's a whole new ball game - one that has very little to do with programming.
Finally, the book got me really thinking. I've been running the software business for 7 years now and while we've been fighting with lots of problems, the single most difficult thing has been to get the right developers. I wrote about different aspects of it in a number of posts analyzing it from many different angles. This books is/says exactly what I've been trying to say and find for all this time. So many people told me that my ideal developer is a mix of too many and too different skills, and that such animals are more rare than a unicorn. On one hand it was very encouraging to see that somebody else has the same ideas and expectations, on the other it's quite a gamble to base your business on something so rare. Yes, it's possible to find one or two and get started. It may even be feasible to hack a new Web 4.5 killer app and sell it to Google for millions of dollars, but it may be much harder create a sustainable business out of it. It may work for huge multinationals that Chad is talking about as they can afford $300,000 packages but hardly any SME can do that.
In fact, I couldn't sleep for almost 2 weeks trying to find a solution questioning my every belief and experience with this business. I tried to unhung my self from the technology, the product, the people and try to weigh the price and the risk of each option today and 10 years from now. It's been quite an exercise - I am now iteratively implementing the changes - if at least 25% of it works out this could be a book that totally changed my business and life. We'll see in half a year :-)
July 18th, 2009 — Planet
Lately, I've been going through a lot of frustrations with Ruby (by ruby I don't meant just the language but the whole ecosystem and infrastructure based on Ruby). I am in a finishing phase on several projects. It's a time when the finer details get addressed. When there's no more time to do it later, differently or drop it all together. It's when everything that is supposed to work should actually work. The problem with Ruby is that it's been in this kind of finishing phase pretty much ever since I started using it (2004). If you look at it from far enough it seems like there is everything in it but when you come closer and actually try using it you'll find out that a lot of it is in less then pre-alpha stage (of course labeled as production). No language is an island unto itself. No matter how great the language you probably don't want to create all the basic libraries from scratch.
When I made a switch in 2004 Ruby was fairly new, Rails was fairly new so I expected this kind of problem, but you could feel the change in the air. Pretty much all the industry heavy weights were talking about it - Rails conf had a better key note line up than any other conference around, number of books was written and the whole Ruby ecosystem was created over almost overnight. Sad truth is that many of the heavy weights are still talking about it today but they're yet to do their first project in Ruby / Rails. Despite the explosion like surge in popularity little has changed in terms of actually usable Ruby libraries (actually I have the same feeling about 1.9 as well). This is a stark contrast to some of the uncelebrated languages out there. For example I find myself writing increasingly more and more code in Python. I don't think Python is the next Ruby, but I was quite surprised how easily it addressed things I struggled with for 5 years in Ruby.
An example could be excel libraries. I still use the same excel libraries I did 5 years ago (for export I switched recently to xlwt, for import because of the changes in roo I've been using JXL for years now switching to xlrd). The export is great only it doesn't support much formatting and breaks on spreadsheets over 10MB (actually somewhere over 6MB) and the files sometimes don't work on later versions of MS Office. There's been a rewrite that is able to go over 10MB but still without formatting I would need and with a license that doesn't allow commercial use. Python's xlwt - despite a very crude and unpolished appearance is able to produce a complete excel spreadsheet with all the formatting (numbers, dates) (including page setup) and all that in much shorter time and with less resources (Ruby 1.8 4m 28s, Ruby 1.9 2m 36s and Python 33s). I have quite a few more examples but I really don't mean this as a Ruby - Python comparison. This experience, however, got me thinking if Ruby is right for the job I've been trying to do (ie uncool enterprise systems). There are pretty much 2 things for me in Ruby (okay - 2.5 the 0.5 being RubyMine - I'll write about it in some other post). One of them is expressiveness of the language and the other is Rails. Ruby as a medium is incredibly expressive, reads almost like English and allows to do pretty much anything (iterating/mapping an array in 1 line, etc). The down side - as Robert C. Martin put it - is that it's really easy to make a mess. After several months of going through somebody's else code I couldn't agree more. A nice entanglement of block and yields and procs can challenge most of the PHP spagetti code any day. While this expressiveness is incredibly powerful, many times I opt for more verbose solution - Java programmer's code on Monday morning as Gregg Pollack would say - that I will be able to understand 2 years down the road - or that my junior developer will understand.
The other thing in Ruby for me is Rails. The only thing with Rails is that after the years it's becoming a bit too entangled, while it made a lot of sense initially to bundle everything together (ORM, routing, templating, etc.) initially now it starting to be a reason why Rails slowly falls behind in certain areas (either that or Rails team has simply decided to focus on Web 2.0 start up market and let others handle enterprise problems). As surprising as it may seems the world around has not been snoozing after Rails was created and many people took the best ideas (just like Rails did from J2EE world) replaced what didn't work and the whole industry moved forward. While few years back Ruby and Rails were pretty much necessities now there's a lot of alternatives and in many different language. To channel out my current frustrations I started experimenting with quite a number of frameworks and platforms. After so many years I really know what I want and how it fits with my existing projects and infrastructure. Very briefly -
- I am looking for a modular framework where I can choose different ORM, different templating engine and so on where each component is developed independently by people who understand that specific area. As each of my project is very different sometimes I need the flexibility to change components. It was a great thing back in my Java times (Spring + Hibernate + Webwork).
- I really need an enterprise friendly dynamic language. Life's just too short to be wasting time trying to force a language to do things it's inventors don't consider important.
- I need a basic ecosystem of libraries (from XML, JSON, through excel, PDF, OO to image manipulation).
- I need a framework that supports TDD out of the box.
- I need a platform with (at least some) formal education and certification available. I need it because I employ people and certification really helped me back in Java times. To pass even the first Java certificate required people to study and to really understand the language and they simply took it as an independent measure of their skills.
- I need a language with a proper IDE. I use Vim every day - BUT not for programming. I've been using RubyMine for more than a month now and I feel like a blind man that got his eye sight back.
- I need reasonable deployment option - both scalable and resource efficient.
- Increasingly more important - I don't want the language/platform community to offend others
It's almost uncanny how many items point back to Java :-). Actually, it's kind of sad that things I took for granted 5 years ago in Java are still not available in the most celebrated and most wildly endorsed language of today. If you look at it - nothing really substantial changed in the way we do the
backend (MC) part of the systems. A lot has changed on the View side, but the models and controllers use the same principles as years back. I've used Python/Pylons quite a lot lately and it scores quite high on a number of areas (only so-so on the IDE, though). It seems much more mature compared to Ruby with more matured libraries supporting the
enterprisey stuff (so ostracized in Rails community). On the other hand it's marketing is nowhere near Ruby's - you don't really hear people talking about wishing to work in Python. I am a bit worried about the performance - but that's something I just have to try on a real project. A big issue still remains the education and certification. I went through this with Ruby already - no matter how easy and great and superior the language you still need to spend some time learning and then even more time working in it before you really understand it. While there's quite a number of books on Python not much of training courses (at least not in Singapore) and there doesn't seem to be any certification around.
July 4th, 2009 — Planet
A few years ago I used to be quite active in Rails community and then I stopped. I haven't been to a Singapore ruby/rails community meet up for 2 years and many of my friends ask me why - if I completely moved from Ruby to Python or simply what happened. Even though, I spend more and more time working with Python, I am still spend 13 - 14 hours a day doing Ruby programming. The actual reason has much more to do with Rails
positioning. Back in April 2007, when the Singapore rails community was just starting to form and we had our first bigger meeting I wrote about it
here. Most of it is now irrelevant but I was quite surprised when I read my 2nd point - purpose of the meetings - especially the part about the community divide to
free hackers and
enterprise developers. Back then I believed both were good and necessary for the community. I still believe it today only the situation has changed. While back then it was pretty much balanced, most of the community today consists of free hackers. After Dave Thomas moved from programming to music (okay - from rails to ruby 1.9) there hasn't been anybody to represent the enterprise interest and the rails community and rails image evolved to a cool web 2.0 free hacker paradise with little interest in enterprise.
This became very clear thanks to
Bob Martin's key note on RailsConf '09 and very nice
rebuttal by DHH. Actually I've listened to that key note for several times now - Robert Martin is so expressive and (using the Smalltalk parallel) so diplomatic delivering something so critical to the community. For the past year and a half, I've been fighting with so many of the things he mentions - so many things I couldn't understand but make so much more sense now.
It makes so much sense what he says about arrogance - I usually call it the 'cool' factor. Not doing the dirty job and only doing the clean things. Belief that our tools are somehow better, that our language is so good that we don't have to follow the rules, we don't have to do the regular (enterprise) things. It may be one of the reasons why Ruby still doesn't have a proper PDF or Excel handling libraries. The problem here is that this kind of arrogance is usually very subtle - but hits really hard and on places you would never expect.
Rails is too easy to make a mess. This single statement pretty much sums up everything I said last week about software development being hard. Yes Rails is easy - in fact so easy that it makes you believe there is nothing you couldn't fix overnight. It's so easy that it makes you believe you don't need to know anything else. The problem is that all that ignorance will come back 3 months down the road (hopefully you'll be able to quit and let somebody else handle the mess).
Clean code. You look at the method it's pretty much what you'd expect.
TDD. As a programmer I pretty much grew up on books and blogs of people like Martin Fowler, Robert Martin, Dave Thomas, Kent Beck and others from the group. TDD was the only way I was able to work. TDD is a No 1 book on my list of books for beginners. Yet I've been having the hardest time selling TDD - even to my own employees. They all know they HAVE to do tests - but only very few of them do it voluntarily or really understand why. TDD is simply not a culture around here (SG) - in fact, many find TDD culturally insensitive - at best a nice theory but totally useless in practice - just go through the Singapore ruby mailing list. Sensitive or not - it made it to our contracts for software developers.
Lastly, the discussion goes to software development as a profession and to what constitutes the professional portion of our job. Surprisingly enough, Robert Martin seems to think it's the discipline, rules and principles, it's the tough things we have to do and it's keeping them up when the pressure of a deadline mounts. While there are people that are against being professional (see the DHH's rebuttal), for many people around me it makes sense. It seems so obvious that no body is really doing it.
June 27th, 2009 — Planet
This is something that's been bothering me for the longest time. And
NOT because I want to feel good about myself telling others how hard my job/work is. The reason is quite opposite. Our company has gone through expansion and shrinking cycle for several times. Each time we change a few things, achieve better results but frankly nowhere near the
ideal situation. The last time round we came up with some important
structural changes, but it doesn't really stop there. Given an appropriate and workable structure, the next question is: what kind of people are we looking for? What are the hard skills and what are the soft skills they should have? What should their
motivation be?
Long time ago I wrote about
10 books to start learning software development. It was an attempt to address the fundamental areas of software development - to take a side in plethora of different possible approaches to them and say this is how we do it here. I really didn't mean to say read those 10 books and you're a top class software developer. I used to start my Ruby on Rails trainings with the following picture:
I found the picture somewhere on the net - but as an ex-java developer I owned and read every single book from the stack (even though I ditched Struts for Spring in 2003 so my stack would have Spring books instead of struts). The ruby stack is pretty much all that was available back then. It would be very nice to think that after reading 2 books you'll know everything you need to know :-). Just for the record, my ruby and rails collection today has exactly 25 books plus a Ruby on Rails Essential Training from Linda.com. Regardless of which stack you're looking at, however, the fundamental problem with the picture is that those books will teach you only very small portion of what you need to know - they only cover 1 area of software development (to be fair the java stack has books on some of the other aspects). They only teach you the language but they are not making you a programmer - just like knowing all 12 notes doesn't make you a musician and being able to write doesn't make you a writer. You still have to add a stack on patterns and principles, databases, testing, basic design, HTML+CSS, object oriented analysis and design, agile techniques and practices, meta-programming, deployment and other aspects. It's extremely important to say that those books are not novels you don't just read them - you really have to work with them, do the examples, play with it try it in different scenarios - basically deep practice with them. Reading in a few hours is totally useless and waste of time.
This is what you have to spend your first 10,000 hours on.
The problem is that after those 10,000 hours you only know HOW ... you still don't know WHAT - a.k.a. the domain. Depending on your job this can very narrow or very broad or your every project may be in a different domain. That's not to say that you have to become a domain expert in every domain - but you can hardly write an accounting software if you refuse to learn about invoices, receivables, GL postings, financial statements and so on. While in traditional model there's system architect (or designer) that is expected to define everything to the last step with screen layouts and function of the last button and programmer simply translates the UML diagrams to code agile models require a very opposite approach. Software developer is no longer just shoveling coal from one pile to another. Instead, he/she is an active part of the development process - sitting with customers, communicating and shaping the final product.
For example, when I was working on my first inventory control system I spent 7 months in the warehouse doing every role from unloading the deliveries from suppliers, preparing deliveries to customers, picking the stock for walk-in customers, through weekly stock checks representing the logistics department on management meetings. I was even a delivery boy for several days to understand what the drivers go through. Doing accounting systems I was a part of accounting department from data entry clerk, going through the end of the month salary preparation stress, working on financial statements for management and going through audits - working with auditors to understand what they need and what's the best way to present it to them. You may say it's totally crazy - and to be perfectly frank many of my (ex)employees do - you did not finish university to be some store clerk and if you wanted to be an auditor you would have studied finance - not programing. As one of my ex-employee (he used to liken himself to Douglas Crockford) put it - I am a luminary programmer - I cannot care about invoices and whatever other domain nonsense.
The problem is that our customers don't give a damn about how luminary programmers we are. They don't know the difference between Java or Ruby, Rails or Spring, Apache or Tomcat. In fact, a few years back when I said I was programming in Java one of my customer asked if it's not too expensive to fly to Java every week and asked if it's because of the environment or cheap massages. They don't need a drill - they need holes. I have long 3 - 5 hours meetings with customers every day but we don't talk about programming - we talk about their issues and their problems. It's about understanding those problems and finding a solution - yet I could hardly find a solution if I had no idea what they're talking about. Problem is that many programmers I know don't even have any interest to understand.
To say it differently - not so long ago I spent 9 months in a restaurant - doing everything from serving, cashier, bar-tending to helping in the kitchen. Kitchen is a single THE most stressful place in the restaurant. Surprisingly the difference between great chefs, mediocre chefs and fired-in-3-days chefs wasn't how well they could fry the fish or roast the beef or how they're goulash tasted - in one word how well they could COOK. They all had to be able and were able to cook. The difference was in preparation. Great chefs would come in as early as 7am and started by cleaning the kitchen, they personally received all the deliveries checking the quality of everything - pretty much smelling every tomato, fish or pork chop. They would check they tools, go through the dishes, cutlery, prepare the condiments and just before opening for lunch sweep the restaurant floor one more time and check every single table one more time just to make sure that it's all perfect and ready. In the afternoon break they would talk to suppliers prepare samples and work on improvements. Mediocre chefs would turn up around 11:00 just in time to defrost the fish heat up the soup and have a cigarette. In the afternoon break they'd be sleeping in the office - because legally, it was they're break.
The software development is very hard - but not because of programming. Being able to program doesn't make you a great programmer just like being able to cook doesn't make you a great chef. It's a given that programmer should be able to write a clean code with tests. What sets them apart is how they approach the other aspects - especially the low glam aspects. I realize that all that I just said goes right against the core values of Rails framework and general perception of Rails. After four years in rails I am very sure I am not a COOL developer working on the next, much COOLER Google or Facebook or Web 3.75 webapp. We do clinically uncool systems - dare I say the word enterprise systems and only a part of the work is actual programming.
I started by asking about motivation - now looking back at what I said - one would have to be crazy just to do all that stuff once - what kind of an insane person would suffer through all this learning and then suffer again on every project (not even mentioning finish stress and starting stress and stress during every iteration - considering a good project is never finished it's like a living organism). Now imagine you find this kind of person, after all there all sorts of crazy people around (like climbers, actors, musicians, etc.) that go through a similar ordeal - how would you pay them? If a fresh grad without any experience asks for $6,000 because he has an option of stress free MNC job (at least here they do) - what can you offer? Martin Fowler once said that they start charging clients on 1 million - when it runs out they charge again. We're almost there - but not quite yet :-)
Last week I read
Talent is Overrated by Geoff Colvin. There is a section dedicated to the the motivation of top performers which is very interesting - so I'll come back with more on this topic (hopefully) soon.
April 5th, 2009 — Planet
When I tried to integrate one of our applications with SMS messages (both incoming and outgoing) several years ago we didn't manage to find not even one SMS gateway provider that would be able to pass our simple criteria. Allow sending (da :-) and receiving of messages with some reasonable notification of received messages (simple webservice / forward to email, anything). The replies should preferably be handled by a local number and sending/forwarding should be within reasonable price range :-) Is it too much to ask?
There is a number of online portals for sending (some support also receiving) SMSes like Clickatel, SMSZilla, SMSCountry. Their pricing per message varies from SGD0.05 - 0.1 which is quite reasonable and some provide nice and easy API for sending (when you think about it how complicated can it get to write a form handler with 3 or 4 fields) - some ask you to pay for API extra. For better or worse they would accomplish the sending but the receiving was either very painful or expensive or both. On top of that sending a hundred messages to and Indian or US number shows on your bill so we had to find something better.
For systems that require only sending we mostly used Singtel Ideas or Starhub Gee. Both are just a little short of and actual webservice, nevertheless worked quite well. Here's an example how to send message using StarHub Gee (12345678 is your phone number)
require 'rubygems'
require 'mechanize'
mech = WWW::Mechanize.new
page = mech.get('http://groupsms.starhubgee.com.sg/VCRLS/login.cgi?cb=http%3A%2F%2Fgroupsms.starhubgee.com.sg%2Fcgi-bin%2Fs.pl')
#login first
form = page.form('loginform')
form.action = "https://login.starhubgee.com.sg/eam/login"
form['cb'] = 'http://groupsms.starhubgee.com.sg/cgi-bin/s.pl'
form['vcid'] = 'groupsms'
form['pudn'] = 'starhubgee'
form['domain'] = 'starhubgee'
form['fake_uid'] = '12345678'
form['uid'] = '12345678@starhubgee'
form['password'] = 'password'
page = mech.submit(form)
page = mech.get("http://groupsms.starhubgee.com.sg/cgi-bin/s.pl")
form = page.form('compose')
form['to']='comma separated recipients numbers'
form['message']= "Your message...."
page = mech.submit(form)This would take care of sending with much lower cost as it utilizes bundled SMSes in the package (400 - 1000 messages) with nothing else required. The problem, however, was still receiving. A little glimpse of hope was SMS+ introduced by SingTel last year, which allows you to auto forward your received messages to email address. This would have been ideal - if not for a small glitch - it only works with messages sent from SingTel numbers. OH MY GOOOOOD!!!!!!!! I almost cried when I found out that.
Lately I found a nice and simple Singaporean provider www.gsmexchange.com able to handle 2 way communication. Nothing to say about sending - just send a http request with username, password, phone numbers and message and you will receive message ID that you can use for tracking. Replies are slightly more complicated as I didn't find any API for reading replies - nevertheless - there is a list page that you can parse with mechanize to get the responses. There is an option to forward messages to email but for 5c per message it's a bit too expensive. Actually, also pricing for sending of the messages is on the higher end 10c per message which makes it much less attractive for our customers.
Luckily I managed to find a much cheaper solution - running my own SMS server :-) See the next post...
August 29th, 2007 — Planet
It may seem like I have nothing much to do, but I volunteered for yet another cool initiative called code::XtremeApps:: competition. It's hard to say what was the main motivation – if the chance to promote Ruby on Rails or to promote software development as such. Either way – a nice challenge around here. Programmers in Singapore are generally in a very very low standing – possibly somewhere around a construction worker :-). The general position(ing) is that programming is a low level blue collar activity facing the same fate as manufacturing and should be outsourced to India, China and only “high level” jobs like sales and project management should be done here. While there's something to it, it's a little strange when most of the people I interviewed said they didn't really like IT and they'd studied computer science to become managers.
Considering this situation I couldn't believe the tremendous response this programming competition received. All our initial estimates were left far far behind – the number of participants for the competition itself, but even more for the accompanying trainings (both Ruby on Rails and Google Gadgets). The training capacity of 120 people was surpassed in less than 48 hours. As for the competition we had to almost double the capacity and as of today there's only a few places left. The training will be this Saturday 01/09/2007 – you can have a look at the agenda here. The training is specifically targeted at the competition participants. Unfortunately, we will have only 1 day and as the competition focus is on innovation and integration we will be mostly covering mostly more advanced topics like AJAX, mash ups and media integration. As such there will be only 3 hours to cover (or discover?) actual RoR framework. I will be doing this training with Choon Keat. It's been a great pleasure working with him as he's not only a great (RoR) programmer but turned out to be very helpful, resourceful and reliable in everything that needed to be done.
The second training is of a very different nature. It's much more in-depth – and much more pragmatic, focused on development of actual business applications rather then competition prototypes. It will be a 2 days training on 15-16/09/2007 and it will provide a much more intimate hands on experience. There's more information here.
The second training has been in the making for around a year now. I started working on it around the time I hit first difficulties when working with Changi Prison and I've been using and improving parts of it on pretty much all my one – to – one trainings. After writing the article about Changi Prison I received a lot of emails asking more about the experience, how it was different from my outside trainings and mostly about my motivation for doing something like that. Strangely enough, I had a strong dejavu experience 2 weeks ago – during the competition launch at SMU. The setting couldn't have been more different – yet somehow it brought back all my memories from my first trainings in prison. When I started my presentation more than 75% of the room (including me :-) was asleep. By the time I finished I don't think there was anybody there that wouldn't want to learn more about RoR or at least try it out. And I guess that is the answer. It's the energy of the people in front of you, their questions and their thirst for more. It's the transformation they go through learning from you and it's the transformation you go through learning from them.
And as much as it is a motivation – it's a responsibility.
April 28th, 2007 — Planet
I finished my first commercial Ruby on Rails application in October 2005 and I've been using it ever since. For most of this time, we've been one of the very very few offering Ruby on Rails in Singapore. Most of our customers are not exactly technical so they wouldn't really care even if we used Cobol :-). What they did care about was the price and delivery time. I don't know why, but writing about advantages of Ruby (and Ruby on Rails) comes very unnatural to me. It feels like saying what everybody knows. At the very minimum, most of the technical people have heard about it – whether they like it or hate it at least the don't go like “You're programming in WHAT???”
The situation seems to be turning even in this part of the world. Thanks to Ruby brigade I met a handful of Ruby on Rails programmers and a few handfuls of wannabes. After almost 2 years in isolation it was really great to see and meet Ruby programmers (other then my own trainees and employees :-). While all this was nice, what really made an impact was ever increasing demand for corporate training. More and more big companies approach me with corporate trainings. The reason is simple...as many are parts of global corporations, many of their internal systems were created elsewhere and now they need a local support. It may come as a shock that MNCs use other systems than just SAP, but it seems to be easier and way cheaper to use a few smaller, independent systems for handling a portion of daily operation.
I started my first Ruby course in April 2005 and for the past 6 months I spent roughly 40% of my time doing training. This has been a major shift for me as only as recently as 1 year back I spent around 90% programming and only 10% on other stuff. I started training in Changi prison and it's almost unbelievable how rewarding this experience has been. I cannot even describe how much the guys have changed. When I walked there the first time I sure saw the potential – around 30 guys doing (or more fighting) with every possible limitation you can think of but still determined to succeed. It may be an old truth that you will appreciate the value of something only after you've lost it but it's really valid. All of the ubiquitous things like Internet connection, access to new books, access to community support (reading the posts or posting questions) – all this is off limits in prison. And yet I didn't find any surviving broken existence in there. So many times I have wished my own employees showed half of the determination, zeal and persistence I could see in there. The more you have, the more you start taking things for granted and the more comfortable you become.
What I felt the guys needed was just better resources and some direction (IT wise). We went through some really tough time – I still remember explaining recursion for the whole Sunday, OOP, TDD and many other things. Well, none of them had any prior formal IT education. But then, maybe it was more to their advantage. Most of the time I find it much harder to work with computer science graduates than with people who never studied IT but have some logical and mathematical thinking. It's surprising how difficult it is to unlearn all the coding cowboy habits as opposed to just starting afresh. This is not to say that OOP or Ruby or design patterns or TDD or agile methodologies or anything else I do is the only way (or that it's correct at all). It's just one of the ways and the one I happened (in reality it took much more then just happen :-) to believe in – but more about that in my other blog posts. Anyway, it's really great to walk in there now. It's completely a different crowd – you see people being able to think, to analyze and to even transform all that into a working product. Sure it's not all wine and roses...but I would really like to see this kind of commitment in many other organizations I worked with.
I realized much of this when talking to people at one of the Ruby Brigade meetings. That's when I realized that I may be running quite a tight ship in regards to development principles – but so far I've really appreciated that nobody on my staff would say things like: “I do tests only when I feel like”, “I've never been into testing much”, “We do bug driven development”, “What's that 'assert' thing mean?” and many others.
To conclude with, I must say that I have always been an extremely fast learner – I've never had problem to learn anything but it's a completely different ball game to teach what you know. One thing is to look at something and understand it and a completely different one is to explain it to somebody else. And I really love it :-). And it finally gives me a reason to start working on my e-learning platform I've been planning since high school.
