For 2015, I solemnly swear that I will read the following titles:
The Pragmatic Programmer
Building APIs You Won’t Hate
Without Their Permission
Mike Hurley has been brewing this new special series of Inquisitive for months and the first episode did not disappoint. The quality of content is just crazy good and the editing, it just raised the bar for podcasting.
The series is about the start of iOS app development and the first episode focused on the introduction of the iPhone and App Store. You’ll hear familiar voices like Marco Arment, Jason Snell, and Guy English.
Can’t wait for the next episode.
Quoted from Daring Fireball:
Astonishing, unprecedented access to Ive personally and his design team at Apple. At nearly 17,000 words it’s closer to a book than an article, and not a single word is wasted. This is a resource we’ll refer to for decades to come.
It’s a must read piece. Have an in-depth look of the life and career of Apple’s greatest product.
So what’s BDD?
BDD is the process of eliminating the translation cost from the business to the developers using the language of examples.
As a software developer, the communication with the client (the business) is probably the trickiest part. You can code hundred lines of code to find out that’s not what the business really wants.
The Three Laws of TDD or Test Driven Development according to Uncle Bob:
- You aren’t allowed to write any production code until you have written a failing units test.
- You aren’t allowed to write more of a unit test than is sufficient to fail. (And not compiling is failing.)
- You aren’t allowed to write more production code than is sufficient to pass the currently failing unit test.
What is Code Kata?
Code Kata is an attempt to bring this element of practice to software development. A kata is an exercise in karate where you repeat a form many, many times, making little improvements in each. The intent behind code kata is similar. Each is a short exercise (perhaps 30 minutes to an hour long). Some involve programming, and can be coded in many different ways. Some are open ended, and involve thinking about the issues behind programming. These are unlikely to have a single correct answer.
Dave Thomas recommended that we have to practice:
In software we do our practicing on the job, and that’s why we make mistakes on the job. We need to find ways of splitting the practice from the profession. We need practice sessions.
The goal is not to arrive with the correct answer (though of course correctness is good) but to just practice coding and learn along the way.
My dearest Triccie wrote this for me a couple of years back:
1989: It was at the end of summer when the first cries were heard from the delivery room of Martinez Hospital. Boy Domingo, he was called then, a name yet to be assigned to that healthy baby that would change the destiny of the human race.
It took a while, but Cyrod John finally made it to the University of His Dreams, where he began plotting his course for world domination. Being surrounded by the best and brightest, it wouldn’t have been hard to do.
But then, in an incident that involved a lab explosion and a French talk show, Cyrod realized that what he really desired was not control over the globe’s resources (or a Google work station), but a better world for him and his friends. Throwing all his dastardly plans into the drain, he joined an organization called Astounding Men of Excellence, where he put his energies into making the world a happier and more productive place alongside his equally brilliant colleagues.
When not busy saving the world, you can see Sir Cyrod (knighted by the Queen for his valuable contributions in the field of World-Improvement) on the shorelines of Puerto Galera with a cold glass of Mogu-Mogu, singing along to the songs of his wife’s band, Paramore.
Actually, I never had the chance to see it in actual print since I didn’t graduate on time and I didn’t bother to claim my copy.
I’ve been checking out Go for the past 2-3 weeks and I’m seriously considering adding it to my technology stack.
So what is Go?
Go is an open source programming language that makes it easy to build simple, reliable, and efficient software.
It looks easy, a simple Hello World program looks like this:
It is like to C, in terms of syntax and speed. Of course, Pointers are included
(I have never been a fan of pointers).
We all like simple tools. Complexity kills. It makes our work difficult and gives us much steeper learning curve. Programmers need to know how things work. Otherwise, they feel insecure. If we work with a complex system, then we have a big gap between “I am using it” and “I know how it works”.