Its been 10 full years since the first version of Rails came out. WOW! 

I began doing web development in Java. Back in 2008. Yes .. in Java. When I decided to do web development, I picked up these two books.

I use to write desktop software in java but did nothing on server side at the time. These two books cleared every little misconception I had on server side development. I read these books as if they are bibles.

There is one more book on Struts framework, I’m not able to recall its author name. I read that to get a hang on Struts specific stuff. 

Thinking about it now, I didn’t have a pleasant experience in Struts.  I always hated writing those XML config files ( I still don’t know how Android guys put up with this stuff these days). I’m trying to re-collect all the pain I had back then when I was using Struts. But I have gotten used to Rails so much, I’m not able to recall all of them. Here are some things i hated with passion in java web development.

1. Writing each and every route as an XML  entry. We map each endpoint to the right Class/Action name. And each route was like 6-7 lines of code. 

2. You have to restart the server every time a change is made. During development, this is a REAL PAIN.

3. I somehow didn’t get a good hang of their ORM. I mean — I couldn’t grab those concepts naturally may be.

Whatever.

As soon as I saw the famous 15 mins rails demo by dhh, I felt - YES THIS IS WHAT I NEED. This is how web development should be done.  

Its not about the defaults. Its not about all those generators and magic that happens inside. It is about separation of concerns done RIGHT. All of the mundane boring sick stuff should be handled by the framework. Leaving behind just the creative part for developers.

I quickly jumped on the Rails bandwagon. Went to its website, downloaded the framework and got started. And since then, there is no turning back. 

The ideas in Rails were so good that other communities started similar projects to derive on them. Also later versions of Struts were supposed to be changing and get some of the ideas from Rails. Not sure what happened there. 

Websites like RailsCasts and PeepCode helped me a lot in understanding the concepts. And StackOverflow was the best part in all of this. I almost always got the best answers quickly with any question i asked. Help was there in every step. 

I always liked the new stuff that came along every six months in Rails. There was nothing stopping the core team in adopting new web standards quickly before anyone else.  Be it REST or Asset Pipeline or any other feature. To a developer willing to contribute immensely to a business, this sort of a framework is a gift.

The dramatic moment as far as I know is Rails and Merb merger. Merb was starting to emerge as alternate Ruby web framework. Instead of fighting for fame and success, the authors decided to merge the good parts of both frameworks. Read this blog post by dhh, if you are interested. The idea of Embracing open source movement and good ideas winning the table will never have a better example than this. 

I wrote a few web services in Rails and started maintaining projects with considerable large codebases. I began writing a few ruby gems as well. One of them has been downloaded more 6500 times so far. 

I badly wanted to contribute to the source code of Rails as well. And I did. 

Most of the successful web companies/businesses around use Rails.  Rails evangelises good software software engineering practices. Best practices are getting derived for almost every part of a web stack. All of this in turn produces a stable product. 

The web industry in someways owes a huge debt to Rails, DHH and 37signals for all this.

Ruby is a beautiful language. Truly speaking, the code i write in ObjectiveC/Javascript, if at all someone finds it expressive, it would definitely be the ideas I learnt in Ruby. Like how Matt quotes it here for Cocoapods, other communities have benefited immensely by Ruby developers. Especially the iOS/Mac community.

Rails is in 4.1.4 now. 

The community has become HUGE. The number of web developers getting involved is growing every day. Conferences/Meetups are getting bigger and better in every country. And with the number of ruby projects growing steadily on Github, it is only going to better in the coming years. 

Cheers! 

Posting this at 3am — so please forgive me for typos. 

3:14 am  •  31 July 2014

This is my primary dev machine. Gorgeously designed one. Total delight when you work on it. Who doesn’t want 8+ hours of battery life?

2:46 pm  •  17 July 2014

Makes most of my day. #music #earpods

10:10 am  •  11 June 2014

I am totally in love with The Breakpoint series.

Check it out - http://www.youtube.com/playlist?list=PLVUliVBcvz1n_DOgB4lb06G_Dc5fQVRRv

Thanks Addy Osmani, Paul Irish and Google!

10:46 am  •  8 June 2014

Lots of people think that Content creation happens on the desktop and Consumption happens on the devices like iPhone and iPad. These are short sighted opinions. 

You touch and move, the object moves under your finger. Devices enabling such direct interactions are the ideal platforms for creation. We just don’t have enough tools in the app store to expose all the power to users.

In fact, the devices can open up completely new class of software and usage patterns. Only a few apps stand out really well - StoreHouse and Fifty three’s Paper. 

I wish my fellow iOS developers wake up to the reality, stop creating the same old NewsReader like consumption apps. And start producing more content creation apps. 

11:33 pm  •  4 February 2014

Errors as they state in classic software engineering books can be classified into 2 groups.

1. Syntax errors
2. Logical errors

Im not going to talk about syntax errors. It is the duty of your favourite editor to stop you from making them in the first place.

I’m going to talk about logical errors which causes big to huge losses in software business. Well, a bug in a todo list software does not have the same impact as a bug in an eCommerce system.

It is frustrating to see a bug creeping through the software destroying the whole reputation of your clean good code. And over time it has a good amount of impact on the way others treat you in a team. So it is worth taking the time to learn how to write bug free code.

I have worked on good number of software products for the past 3-4 years in a team and individually. So I believe I can talk about this subject.

The secret is in you.

It all comes down to you, the programmer who has been assigned a task to be completed before a specific date.

How you take up the task, what methods you follow to approach it and finish it on time is where all the secret exist.

First step is to understand that the fact that your job is all about writing components. Components that are going to play well with other components of the software. Be it a bug fix or a new feature. It is a software component.

The second step is to spend considerable amount of time in studying the system around before writing those if’s and for’s. When and where is your code going to run. What are the conditions under which your code is going to be called. And what is the time frame in which your component has to complete its task.

The third step is to actually write the code. In a clean way. I wrote a post before on how to do this well. Read it if you are interested. 

The ideal characteristics that you have to target while writing the component is that, any explosion outside shouldn’t affect the working of your component and any critical bug inside your component should be an implosion and shouldn’t affect the workings of other components around.

The reality is “Ideal cases” never exist. It never exited before and its not going to come into existence in the future. Having said that, the understanding you have about the system around your component matters. Even if you don’t achieve the ideal case, efforts can be put in to get closer to it.

Software engineering has dealt with “Writing bug free software” in many different ways.

Agile development has been one such practice and it has worked. Their bottom line is “we do ship software with bugs in every release. But they will be fixed in future iterations”. I totally buy this idea.

But when you take the right steps to write your code bug free in the first step, it would take less number of iterations to achieve the idea state.

It takes time to do all this. It is ok. Spend it.

After all, we live to receive that happy thank you email from the customer who appreciates the value of your software in his life.

Im not a native english speaker. So please don’t be a grammar nazi and ping me for errors in the post. Im working on this part.  If you have understood the things I wrote above, I’d consider that the Job is Done.

If you have different thoughts on this, share them below in comments section. I’d love to learn from you.

9:21 am  •  28 January 2014

We are Knowledge workers.

Software industry demands us to be creative in picking up good solutions all the time. We need to be committed at what we do continuously for years to come.

So our Mind is the most important asset. There is an absolute necessity to take good care of it.

Our to-do list is always full. We  always throw those extra hours at it coz we love doing it. We  say YES to everything. And we always take those weekends granted for something that can be done on the following monday.

But when the work we produce come out lousy, it starts to show up. Thats the result of a tired mind. The sooner we realise this point, the better it is.

Allocate good number of hours to whatever you work on. And focus on it completely when you are inside of it. But never work on it outside of those hours.

When we set our work patterns like this,

It makes it visible the line between what you can do and what you cannot do.

When we don’t know this line, we don’t know what to expect from ourselves. Thats when stress arrives in and in some worst cases - Burn out.

Prioritisation is an important step in any list we compose. That’s when our decisions start to become sharp and logical. Actions will become quick and confident. And thoughts will be so much more clear.

I believe that you always have to give up something to get something else. It is OK to accept that you can’t do/build everything. You would have to give up some of your secondary items in the list and choose the top most item for better results.

11:33 pm  •  2 December 2013  •  1 note

If you are in any way associated with building software, you must get sketch app and play around. Designing software components in it is super fast. 

Here is why I think it is better than Photoshop.

1. 100% vector. I can zoom 300% into a component and design it to the very detail i want. 

2. Exporting/Slicing is freaking fast and easy.

3. The whole software is less than 20MB. 

Get it here.

Kicker - The creators have put together a neat website to list all the templates for web and mobile design. Checkout sketchappsources.com

9:34 pm  •  13 October 2013

Be it a new product or a new feature or an enhancement or a bug fix, I follow this quite religiously.

1. Make it Work
2. Make it Right
3. Make it Fast

This is not new. Most programmers I follow do this. 

Make it work - first make the product do what you wanted it to do.

Make it right - Refactor it. Cut the duplication and make sure your code is easy to read and understand. It then becomes simple to maintain it.

Make it fast - if your product is slow, you suck. Big time. Measure the code and fix the bottlenecks. You can delight your users only when you finish this step.

Code review is almost always about the last two steps. If your team mate can’t do the first step, your shouldn’t have hired him in the first place. If he cannot do the last two steps - that’s ok. These skills can be acquired. Luckily, I work with good programmers. 

Don’t commit your code until you finish the third thing. You will have a better product if most of your team is convinced about all this.

8:00 am  •  21 August 2013

I wouldn’t have said this better than him.

Developers are not fools. They choose to develop for a platform if

1. They use it.
2. A lot of others use it.
3. They can make a living out of it.

Nexus was my first smartphone. The reason why I stopped using Android and went to iOS is because Android is incomplete. And iOS nails all the above points. Happy ever since I made the move.

10:46 am  •  14 August 2013