Batch convert PSD to PNG

Recently I needed to convert a bunch of PSDs to PNGs.
Here's how I did it:

I installed ImageMagick along with the dev packages.

Ran the follow command and got the job done.
mogrify -format png *.psd

More info here: http://www.noob2geek.com/how-to/batch-convert-images-using-imagemagick/

Choosing technology stack for your Next Big Idea? Here's help...

Listed are some common decisions that you need to take when you are planning to develop a new web application along with hints at helping you in choosing the right vendors and frameworks:

1. Hosting:

Heroku - Easy deployment + scalability and high availability + plug and play services. But least custom control.

Engineyard - Ease of deployment + Amazing customer service + root access.

Linode - Cheaper than many + variety of server templates to start with + root access. But complicated.

Amazon EC2 (self-managed) - We configure the environment from scratch. Maximum control and easily scale-able but the onus of server management falls on you.

These are just a few common options. I'm sure there are many more...
You can check out this white paper to understand the advantages of using a Platform-as-a-service over self-managed servers. It helps you in reducing the Total-Cost-of-Ownership (TCO). It feels like having the best server engineers dedicated to making your servers more secure and reliable.

2. Monitoring:

New Relic is the de-facto for monitoring the server, identifying bottlenecks and setting up alerts when the performance falls below some threshold. Highly recommended.

3. Data persistence:

Relational Database v/s No SQL. Here's a related discussion and mongodb faq 

Possibility of an application utilizing both Relational database and No SQL as a hybrid persistence. 

4. Choice of Application Frameworks:

Depends upon the technical comfort of the development team and sometimes on the management red-tape involved in the decision making process.

1. Ruby on Rails - Rapid and Agile web application development. Vibrant open source community with plugins for just about anything that you can imagine. Any CPU intensive operations are generally extracted into native code (say written in C) with a ruby wrapper around it.
2. Java/.net - Long list of active enterprise applications to support the credibility.
3. Node.js - This a new contender in the server-side application development technologies. Best suited for serving high volumes of requests with minimal hardware *conditions applied.
   Using Node.js, LinkedIn went from running 15 servers with 15 instances on each physical machine to just 4 instances that can handle twice the traffic. More about it here.

An application can be built on Service Oriented Architecture - where the data can be processed and served by one or many server written in different technologies while being consumed by a modern client-side framework like AngularJS and BackboneJS.

Surviving the management landmines in an Agile environment

Sounds familiar?

This post aims to give YOU - The zen developer / leader - some hints at surviving the management landmines in an Agile environment.

Without implying that your boss is incompetent, the fact is that the Agile way of project management is new and there are a lot of misconceptions lingering around. Here are some things you might hear your boss say and some hints about how to respond to them.

"Agile is flexible." - implying - We can pull people in and out of the teams and can keep changing the requirements at any point of time.

Make it immediately clear that the features and requirements are flexible and can keep changing. But the team and the requirements do get locked in for the duration of an "Agile Sprint" which generally varies from 2-4 weeks.

"There were 10 features out of which 3 could not be delivered in the sprint. You failed!"

Predicting software delivery has never been a walk in the park and when it comes to predicting the delivery in a short period of time it can only mean risks and uncertainties.

"At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly." - Agile Principles

Agile is not magic. An Agile team understands its velocity, improves efficiency and evolves over time. This results in better estimates in future but only when given some stability to the team. Too many new additions (or subtractions) to the team? Make the risks clear to your boss and assure stability over time.

"Its only two days to code delivery date. We don't need automated unit tests. Just write the code, make the UI presentable and we're done."
Agile and BDD/TDD go hand-in-hand. If you don't write tests, the future iterations become unpredictable. In my experience, strict adherence to BDD / TDD helps you deliver faster (once you get a hang of it) or with little deviation from the original estimates. Make your boss aware of the future risks that it would pose to the project deliveries if you do otherwise.

"You wanted three people. Take this guy and these two interns and deliver the project"
Agile assumes that the team is made up of professionals who are highly motivated towards meeting the goals. You may have a few inexperienced people in the team but that arrangement works best if you can pair them up with some highly experienced developers for a few sprints. Make your boss aware that Agile is not a short-term quick fix but a way of delivering quality software in predictable time frames but the team might take a few sprints for it to happen.

Can you recall similar conversations with your boss? I would love to hear about them in the comments.

Ruby on Rails is for Toy Apps. Wtf!

I recently met a guy who told me that "We are making our product in java. I've a great software architect (who develops in java) who told me that Ruby on Rails is for data driven toy applications but when it comes to serious business apps, we use java".

This is not the first time I'm hearing this... So many java developers have been spreading this propaganda that Ruby on Rails applications are slow which is non-sense because the only thing that makes an application slow is the nut coding it.

I've coded in C++, MFC, java and .net before I started coding in Ruby and I've seen many obvious benefits that Ruby and Ruby on Rails gives to the coder and the code -

1. Readability

2. A long list of plugins - Gems we call them. Just think of a use case and there's a already a gem which does that.

3. Speed of development - You start seeing considerable progress within half an hour.

4. Agility - Ruby on Rails has agility at its core given the features of data migrations and built-in unit test suite.

I don't have the stats around it, but I haven't seen any developer community more paranoid about TDD and BDD than ruby community which is the foundation of Agile development and quality code.

Heard that Ruby is slower than Java?

1. There is JRuby - the java implementation of Ruby - it bridges the gap.

2. Did you know that most of the heavy lifting is done in C? And that ruby makes it very easy to wrap in your native extensions as Ruby gems?

So, the next time your java engineers tell you that Ruby / Ruby on Rails is for toy apps. Well, say wtf!

Designing the button - Sign in with Linkedin - using Twitter Bootstrap

in® Sign in with Linkedin

<a href="/third_party_authentication/linkedin" class="btn btn-info btn-large" style="padding-top:3px;padding-bottom:3px;">
  <strong>
    <span style="font-size: 22px">in<span style="font-size:5px">®</span></span>
    <span style="height: 40px;margin: 0 9px;border-right: 1px solid lightgray;border-left: 1px solid slategray;margin-left: 3px"></span>
    Sign in with Linkedin
  </strong>
</a>

How to create Products that Sell

Step 1. Maintain simplicity

A phone needs to be able to make clear calls, a toaster should toast bread, an iPod plays songs.

Its OK not to satisfy everyone on the planet. The biggest reason why many products (mostly consumer software products) die is that they get into this cycle of adding more and more features to the product while the core feature stays the same. It becomes bulky, feels complicated and slowly becomes unusable to everyone.

Does that mean you should just throw away your million dollar add-on? Absolutely not! You can make a new product out of it for the specific target audience. You would not only be able to focus better, but also allow the users feel at home. You can of-course design your related products to snugly fit together if that makes sense.

Step 2. Generate the Craving

The Eye Candy

We all have an innate sense of beauty. You might not be able to put it in words but you just know when something is beautiful.
The product should be likable down to the very fine details.

Take the case of Apple. Their products are an eye candy from the body design down to every pixel on the software that runs on it. Everything looks just perfect. Its sexy and you know it.

Advertising

Watch Rory Sutherland: Life lessons from an ad man
"When you place a value on things like health, love, sex and other things, and learn to place a material value on what you’ve previously discounted for being merely intangible … you realize you’re much, much wealthier than you ever imagined." (Rory Sutherland)

Step 3. Provide Reassurance

We all know that people buy impulsively but what few understand is that most people often do seek re-assurance before making a purchase.

While the warranty / timely service is all very important and influences the decision, the fan-boys play a subtle part. Blogs harping about the success of apple, how Apple is selling the most iPhones in the US, how 90% of internet traffic comes from iPads (based on an unreliable source of statistics and assuming that iOS implies iPad). Since, so many people are happy with it (so you have read), it must be good right?

Later when you come home after buying a new iPad for 500$, you wouldn't want to be reading a blog saying "iPad sucks because it can't multi-task" on your iPad would you?

Make it or fake it, get the ball rolling. Once people see many people writing about the same topic, many others would jump in.

What's your estimate on your project?

The legend has it that in a big corporate meeting the youngest guy in the team stood up against the Senior Director of their business unit over his belief that "Every software is unique and you can't estimate its delivery dates. If you do then if you don't meet the dates, its disheartening for someone working day and night to achieve the goal. So why estimate in the first place? Just press the pedal to the floor and deliver at the earliest.".

But there was a mutual consensus at the end of the meeting that over a period of time, on an average, similar software solutions take similar time to code. Which could only mean that it was possible...

The Director was kind and patient. He later met this junior guy and appreciated the honesty and asked if this junior guy would some day want to lead a team of developers?
The junior guy said "Yes." promptly.
The director then asked if the stakeholders would be eager to know how long the team would be able to deliver the software.
The junior guy said "Yes." again.
The director asked - "So, how would you learn to estimate?"
"By experience" was the reply.
The director asked - "How would you gain that experience?"
This hit the junior guy in the face. Both he and the director knew what he was thinking.
The answer was - "By estimating regularly".

The junior guy had learnt early in his career a very important lesson which later helped him give estimates better that Dilbert.