Five Code Signals.
Some best practices that I have learnt the hard way.
The last couple of months have been critical. I sat down for a long time in front of my computer, to push and build the final thing (first product of WhiteShark). In this process, I learnt a few important things regarding the development of a product (a web-based software precisely). I sincerely hope if you are one of those, whose problem statement matches with mine, then this might be helpful for you as well.
Let’s start. Or if you want a cup of coffee, get that now.
1) API’s are fantastic (and necessary). #
Coming from a PHP - MySQL background and always developing quick - fast websites, it’s not very hard to find API’s entirely useless. It’s understandable since we use PHP and several other languages on both server side and client side. And that means if I have to, for instance, delete an item I can directly write code directly for deleting rather than writing an entire RESTful API and having a DELETE method. This is all ok, till the moment there are 1000 lines of code and changing one thing in the code becomes a mammoth task. And maybe changing that piece of code changes behaviour at some other part of the application. So what? You want to keep debugging and keep jumping from one piece of code to another. I guess the answer is NO. That’s where API’s are so important. But the most important reason because which I loved API’s were different. It was the ease of use and similarity patterns.
Think for a second. For any item in this world, either you need to view that item (or maybe all items), add an item, update an item when it’s added and then delete that item as required. For example: As a Facebook user if the item is a friend:
i) I will like to see my all friends (GET method)
ii) Or maybe just a friend (GET method)
iii) Add a new friend (POST method)
iv) Update friends details (PUT method)
v) Delete a friend (DELETE method)
Now every entity in your system (e.g., Friend, User, Group etc.) you have just to write these four methods. Done. And that makes life so easy. Now make a promise today - Whatever language you chose, start with writing an API.
- There is a difference between POST and PUT method. If you are confused head over to http://zacharyvoase.com/2009/07/03/http-post-put-diff/
- If you are using NodeJS, here is one link that I highly recommend for RESTful API: http://pixelhandler.com/blog/2012/02/09/develop-a-restful-api-using-node-js-with-express-and-mongoose/
2) Separate your concerns. #
Ask this question: What is the purpose of a Database?
To save and send the data securely. It’s up to your backend code to run the ALTER and JOIN queries. Because if your DBMS is handling what data to be matched and sent, then that can cause overhead and may lead to a bad design. Initially, when I learnt about Non-Relational Database (MongoDB), I was irritated because it was hard to do so many cool things (run so many precise queries) as it was in a Relational Database like MySQL. But when I realised the fact that it is sending the data in almost the same way (BSON) as I need on the front end (JSON) without adding extra fluff to it, I fell in love with it. Now I spend less time on Database, understanding Schema and running queries and more time on backend code and handling and managing functionality.
Initially, when you start writing this way, it will be difficult. Wait. Hold on. Once you jot it down completely, then you will start appreciating the actual beauty of the code.
3) Have a good editor and at least a couple of monitors. #
If you are a developer, this is one of those things your life will be based on. This is like your axe. And that should not only be sharpened, but it should also be fun to use. Earlier, I used Notepad++. It’s good. But it’s not a code editor, which you can open for a long time and appreciate the design, interface and the colours. I have created a lot of .NET Applications. Visual Studio is an excellent tool for that. But its too heavy. I mean it slows down my computer. And every time I have to install GB’s of a code editor. That’s insane. I mean that’s like installing 5 GB’s of Autodesk 3ds Max when you can do the same thing in 20 MB’s of Blender (just saying!). Neither I can use it on my Linux machine or Mac machine. Sad.
- Sublime Text 2: This is the most popular code editor in the open source community. There are a few really good things about it. One it is available for every Operating system, and it has a consistent look. Once you install the Package Manager http://wbond.net/sublime_packages/package_control, you can highly customise the editor.
Cool Links: i) Sidebar Enhancements ii) Dayle Rees Themes iii) Soda Theme / Phoenix
- Adobe Brackets: Simple, sharp and really beautiful editor. Every three weeks a new update is released, and that keeps the interest. This is not a pro editor like Sublime Text, but that’s the charm. Fewer functions, More work. That being said, Brackets team should work on getting the basic functionality available asap.
- Microsoft Webmatrix: Though it is available only for Windows, it’s a beautiful code editor, that handles the essential functionalities. I like the editors’ code highlighting and the way it integrates git. If you have a windows machine and you don’t want to install Visual Studio, give Webmatrix a try. As the name suggests, the editor is made keeping web in mind.
4) Use a design pattern #
Great coders all around the world are developing awesome apps, and in the process, they are experimenting with so many things. It’s useless to repeat the same mistake. And it’s pretty intelligent to use some of the successful design patterns. If you are using Ruby on Rails, then you are already using the MVC framework.
We are using Backbone JS which is an MV* framework. All I have to do is to define models and collection of models and View(s) that takes the template and renders it on request. Moreover, Backbone Sync helps us to use our RESTful API (in whichever server-side code it may be), without going into their internal details. Most of these frameworks have been written to handle basic needs rather than handling a particular use case. For that, many libraries extend the functionality of these frameworks. In our case, it was Backbone Marionette. The need for Marionette arose to handle composite view and remove zombie views.
The idea is that the problem that you are trying to solve may be solved already. You have to open your browser and search either on StackOverflow or Github. And boom, the problem is solved.
5) Use Browser Developer Tools #
It may be firebug or Chrome developer tools. Whether you are live-editing your CSS or Debugging your web app or checking performance, they inevitably make life easier. Codeschool has a great tutorial (and that too free) on Chrome Dev tools. Give it a shot: http://www.codeschool.com/courses/discover-devtools
I also use a few other chrome extensions like Postman (created by one of my friend - @a85) for testing the RESTful API. If you have not checked it grab it now.
That’s it for now. There are few other things that I have learnt, but most of them are related to a particular language or framework that I use. If you are experiencing all of these five code signals and more, please tell me what I am not using. I will be very thankful. If you are not using one of them, try shifting to them and let me know what changed!
As always I am available at devesh[at]whiteshark.me