BLOG MOVED TO http://dhilipsiva.com/blog/

Hi. I think that this is my last post on this site. This blog had been great. 88k+ hits. But time to move on. From this point forward, I ll be blogging at: http://dhilipsiva.com/blog/

Recursion

Recursion http://bit.ly/12eHv8M

Yet another collaboration tool? Yep, Meet CollabLayer!

Original post is on Tataatsu's official blog. You can find detailed article over here.
 

CollabLayer – Executive Summary

CollabLayer, is a cloud-based collaboration tool for professionals and enterprises.

CollabLayer amplifies enterprise effectiveness by enabling collaborative content consumption, discussions in context and rapid discovery of insight within content in near real-time.

Sign up, follow CollabLayer here or here for updates.

Best Practices

Here are some best practices that I have learnt so far. If you find something to be inappropriate / inaccurate, please comment below so that I may update this post as necessary. Again, these are evolving thoughts and may change as I learn something new. I have put these things on GitHub too.

General

• Always make sure that you name the variables appropriately.
• Follow a general pattern. It should be clear what a function does and returns. stick to the standards.
• Experiment as much as possible before you use some thing in production.
• Open source almost everything as much as possible.
• Composability - Always keep this in your mind.
• Never change a function signature that some one else has written without discussing with your team first. This is the most stupidest thing to do.
• Write kick ass test cases. This will drag you in the beginning, but trust me, this will hold your back in the long run.
• Write as much extensive documentation as possible.
• Build a CI server. Have it test your code each time you commit your code. That way, everyone will immediately know if something is broken.
• Always stick to the standards and general patterns as much as possible. By that way, any new member in the team can figure things on himself without much help from the others.
• If the logic / idea behind the code is not obvious, either write a crystal clear documentation or rewrite the code so it is obvious.
• Remove redundant pieces of code, UI or anything.
• Never update a production server. If there are any compelling reasons to update your server, have an identical staging server, update/ upgrade it, run your kick-ass test cases and if everything seems to be right, then you may continue updating your production server.

Source Control

• Prefer Git unless you have any oher strong reason to use somthing else.
• Keep your runnables on root of your repo.
• Have to main branches - prod (for production) and dev (development) branches.
• And other branches as required - hotfix-* and feature-*
• You NEVER commit directly on prod.
• If there are any severe bugs in prod, then you may checkout hotfix-* from prod, fix the issue and merge it back into prod.
• The only activity on prod branch is to pull from a stable dev or a hotfix-*.
• If you want to add a new feature, then you should checkout feature-* from dev, Implement the feature and merge it back to dev.
• The activities on dev should only pulling from feature-* and pulling from prod which has a hotfix-* merge.
• Avoid usage of GUI tools. GUIs are great for code review. But always use git command line for committing and stuff.
• Try to user --no-ff to preserve branching history.
• We almost always write our new code at the end of the file. This will lead to merge conflict if all of us work on same part of file. Instead, try to write new codes other than the end of file. some where it is more appropriate. This will prevent merge conflict to an extent.
• It is always a good idea to have release notes with a diff of codes. Great for reviews.
• Merge vs. Rebase: Use merge when you want to preserve the branching tree. Using merge will result in a additional merge commit. Use rebase if you dont need preserve the branching tree and avoid the additional merge commit.

Startup

• Get out as soon as possible.
• Build a very minimal viable product and go out as soon as possible. You never know what users want. This will give an opportunity to learn and build more.

UI-UX

• After all, this is the part which users will be seeing.
• DO NOT make the user remember anything.
• Everything should be intuitive.
• Users should accomplish their tasks with as much lesser efforts as possible.
• Keep the interface as much simple as possible.
• Everything should be obvious.

JavaScript

• Make Fewer HTTP Requests
• Use a Content Delivery Network
• Add an Expires Header
• Gzip Components
• Put Stylesheets at the Top
• Put Scripts at the Bottom
• Avoid CSS Expressions
• Make JavaScript and CSS External
• Reduce DNS Lookups
• Minify JavaScript
• Avoid Redirects
• Remove Duplicate Scripts
• Configure ETags
• Make AJAX Cacheable

Misc

• If you want to succeed as bad as you want to breath, you will.
• If you use any open source projects, give an attribution to them.
• Contribute to their repo or donate something, no matter how small it is. It is these small things that move an open source projects forward.
• Open source your code as much as possible.
• If you are a startup, hire some freshers who are passionate about technology, and guide and mentor them. Turn them into some valuable stuff that a society could use. And make sure he will do the same thing to some other fresher when he is settled.
• Blog about problems you have faced and the approach that you took to solve it. It might help some one else.

Python Libraries: Django, Twisted, Tornado, Flask and Cyclone.

This post will soon be moved here
This blog has moved to http://dhilipsiva.com/blog/

This post is outdated.

NOTE: This post may be modified soon. I suspect that this will start a flamewar. I have written this post as far as I understood these libraries.

I have been writing production applications in python for almost 2 years now. And I have come across quiet a few libraries. I was confused and didn't know what to use at first. So I experimented with as many libraries as possible. So here is what I found until now.


"Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design". If you are building something that is similar to a e-commerce site, then you should probably go with Django. It will get your work done quick. You dont have to worry about too many technology choices. It provides everything thing you need from template engine to ORM. It will be slightly opinionated about the way you structure your app, which is good If you ask me. And it has the strongest community of all the other libraries, which means easy help is available.


"Flask is a microframework for Python based on Werkzeug, Jinja 2 and good intentions". Beware - "microframework" may be misleading. This does not mean that Flask is a half-baked library. This mean the core of flask is very, very simple. Unlike Django, It will not make any Technology decisions for you. You are free to choose any template engine or ORM that pleases you. Even though it comes with Jinja template engine by default, you are always free to choose our own. As far as I know Flask comes in handy for writing APIs endpoints (RESTful rervices).


"Twisted is an event-driven networking engine written in python". This is a high-performance engine. The main reason for its speed is something called as deferred. Twisted is built on top of deferreds. For those of you who dont know about defereds, it is the mechanism through with asynchronous architecture is achieved. Twisted is very fast. But is not suitable for writing conventional webapps. If you want to do something low-level networking stuff, twisted is your friend.

"Tornado is a Python web framework and asynchronous networking library, originally developed at FriendFeed. By using non-blocking network I/O, Tornado can scale to tens of thousands of open connections, making it ideal for long polling, WebSockets, and other applications that require a long-lived connection to each user". Tornado stands some where between Django and Flask. If you want to write something with Django or Flask, but if you need a better performance, you can opt for Tornado. it can handle C10k problem very well if it is architected right.

"Cyclone is a web server framework for Python that implements the Tornado API as a Twisted protocol." Now, what if you want somehting that is nearly as performant as Twisted but easy to write conventional webapps? Say hello to cyclone. I would prefer Cyclone over Tornado. It has an API that is very similar to Tornado. As a matter of fact, this is a fork of Tornado. But the problem is it has relativly small community. Alexandre Fiori is the only main commiter to the repo.

I am working on the tabulation. I ll be updating it as soon as I find time to complete it.

Want me to review any other library? Please leave a comment below.

Comments / Suggestions / Edits welcomed.

Sri Aurobindo tells about staying young.

As soon as you stop advancing, as soon as you stop progressing, as soon as you cease to better yourself, cease to gain and grow, cease to transform yourself, you truly become old, that is to say, you go downhill towards disintegration.

There are young people, who are old and there are old people who are young. If you carry in you this flame for progress and transformation, if you are ready to leave everything behind you so that you may advance with an alert step, if you are always open to a new progress, a new improvement, a new transformation, then you are eternally, Young.

But if you sit back satisfied with what has been accomplished, if you have the feeling that you have reached your goal and you have nothing left to do but enjoy the fruit of your efforts, then already more than half of your body is in the tomb: it is decrepitude and the true death.

~ Sri Aurobindo

SUCCESS

This is an awesome speech by Eric Thomas. Re-posting this so that I can read this whenever I feel down.

There was a young man that wanted to make a lot of money, right? So he went to this guru and told him, “I want to be on the same level that you’re on.”

The guru told him, “If you want to be on the same level I’m on, I’ll meet you tomorrow at the beach.”

So the young man got there at 4 A.M, all ready to rock and roll, got on a suit when he shoulda wore shorts. The old man grabs his hand and says, “How bad do you want to be successful?”

He said, “Real bad”

The old man says, “Walk on out into the water.”

So he walks on out into the water, waist deep. So, to himself, he’s like, “This guy is crazy”

He’s thinkin’, “I wanna make money, he’s got me out here swimming. I don’t want to be a life guard, I want to make money.”

The old man says, “Come out a little further.”

He walked out a little further, out to his shoulder area. He’s thinking, “This old man is crazy, he’s makin’ money but he’s crazy.”

The old man says, “Come out a little further.”

He came out a little further, it’s right at his mouth and he’s thinking, “I’m about to go right back, this guys out of his mind.”

So the old man said, “I thought you wanted to be successful?”

He said, “I do!”

The old man said, “Walk a little further.”

He did, he walked a little further. The old man grabbed his head, under water, held him down, the guy was kickin’ and scratchin’, still holding him down, he had him held down and just before he was about to pass out the old man raised him up.

“When you want to succeed as bad as you want to breath, then you’ll be successful.”

I don’t know how many of you have asthema, you have a asthema attack, you’re short of breath, you’re weezin’, the only thing you’re trying to do is get some air. You don’t care about no basketball games, you don’t care what’s on TV, you don’t care about a party. The only thing you care about when you’re trying to breathe is to get some fresh air, that’s it. And when you get to the point of when you want to be successful as bad as you want to breathe, then you’ll be successful.

And I’m here to tell you, number one, that most of you say want to be successful but you don’t want it bad, you just kind of want it. You don’t want it badder than you want to party, you don’t want it as much as you want to be cool, most of you don’t want success as much as you want to sleep! Some of you love sleep more than you love success. And I’m here to tell you that if you’re going to be successful you’ve got to be willing to give up sleep.

You got to be willing to work off of three hours, two hours, of sleep. If you really want to be successful somedays you’re going to have to stay up for three days in a row! Because if you go to sleep you might miss the opportunity to be successful. That’s how bad you have to want it. You’ve got to want it so bad that somedays you forget to eat.

Beyonce said once, on set, that three days had gone by and she was just doing her thing, she had forgotten to eat! Because she was engaged with her work.

When 50 Cent was doing his movie, did a little research, that when he wasn’t doing his movie, he was doing his soundtrack. And they said, “When do you sleep 50!?”

“Sleep?!”, he said, “Sleep?! Sleep is for those people who are broke. I don’t sleep. I got an opportunity to make a dream a reality.”

Don’t try to quit. You’re already in pain, you’re already hurt. Get a reward from it! Don’t go to sleep until you succeed.

You won’t be successful until you say, pointing to self, “I don’t need that money, because I got it in here.

Related articles

• Weekly Inspiration #1 - How Bad Do You Want Success?

Enable NTFS write support on Mac OS X

This post will soon be moved to here

This blog has moved to http://dhilipsiva.com/blog/
This post is outdated.

That is really annoying, isin't it? I mean, you plug-in your Disk into your mac, and all you know is you cannot write anything on it. Anyways, I have found an utility to enable mac to write on your NTFS Harddisk. its called ntfs-3g. Here are the steps to install it:

• brew info fuse4x-kext
• sudo /bin/cp -rfX /usr/local/Cellar/fuse4x-kext/0.9.2/Library/Extensions/fuse4x.kext /Library/Extensions
• sudo chmod +s /Library/Extensions/fuse4x.kext/Support/load_fuse4x
• mount -t fuse4x
• sudo mv /sbin/mount_ntfs /sbin/mount_ntfs.orig
• sudo rm /sbin/mount_ntfs
• brew install fuse4x sshfs
• sudo kextunload /System/Library/Extensions/fuse4x.kext/
• sudo kextload /System/Library/Extensions/fuse4x.kext/
• brew install ntfs-3g
• sudo ln -s /usr/local/Cellar/ntfs-3g/2012.1.15/sbin/mount_ntfs /sbin/mount_ntfs

Yes, I know I did not give much of explanation here. Thats because I doubt if this is going to useful for some one. If you are reading this and need some explanation, let me know. I ll update this post as needed. But for now. This is for my future reference.

Install PostgreSQL on OS X using Homebrew

This post will soon be moved to here
This blog has moved to http://dhilipsiva.com/blog/
This post is outdated.

Strong advice: DO NOT use any "installers" for you development purpose. And by installers, I mean GUI based wizards / drag and drop ones. always rely on command-line. If you are not using Homebrew yet, Start using it immediately. For those who have never used it, is it like an "apt-get" for mac. Technically speaking, it is a package-manager. There is an other alternative to Homebrew called MacPorts. But I have never user MacPorts. I am happy with Homebrew. So I dont know much about MacPorts.  

So before installing through Homebrew make sure that you uninstalled the old version completely and restarted (Just to make sure there are no startup items related to postgres) your mac. Open "Activity Monitor" and ensure there are no "postgres" processes. And follow commands. If required run command "brew doctor" just to make sure that everything is OK with Homebrew.

1. brew update
2. brew install postgresql
3. initdb /usr/local/var/postgres
4. cp /usr/local/Cellar/postgresql/(your-pg-version)/homebrew.mxcl.postgresql.plist ~/Library/LaunchAgents/
5. launchctl load -w ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
6. pg_ctl -D /usr/local/var/postgres -l /usr/local/var/postgres/server.log start

Note: When you use Homebrew to install Postgresql, It does not create a "postgres" user for you. If you really need it, you can create one yourself. But normally the user that you are currently logged in as will  have super-user privileges. It comes in handy during development.

iTerm2 / Bash Line Wrap Bug

UPDATE: Apologies. Looks like this is not a bug. It is an expected behavior. And I failed to read through the documentation properly. Thanks to Jorge for pointing this out. Here is what he replied as you can see in one of the comments below:

    I filed a bug to the iTerm people, and they quickly replied. It turns out is not a bug, just a bash idiosyncrasy. The iTerm2 developers pointed me to this link, where it is clear that the solution is to modify PS1, and surround the non-printing chars between '\[' and '\]', to tell the shell "everything between these escaped square brackets, including the brackets themselves, is a non-printing character.

    I have been using iTerm2 for about some 8 months now. It is the tool that I use for most of my day's work. I kind of dislike IDEs and GUIs. Honestly, I feel that they are sluggish. I love to work on terminal with Vim / Emacs. All these days, I have been ignoring a bug. A bug that is caused by the line that is longer than the width of terminal. And this bug is caused only when you customize the color of your command prompt (PS1). You can have a look at my .bash_profile file. in the first line, I have customized my PS1 as follows:

    `export PS1="\e[1;36m\W\e[m \e[1;35m>\e[m "`

    Lately, I had to break up long lines using `\`. But I sooner found that this was messing up the history too. When you scroll through the history, you can see some weird stuffs happening. Got me really annoyed. Having been annoyed enough, I decided to fix this. I went to iTerm2's GitHub repo. I checked the issue list, there was no issue like that. So I forked the repo and tried running through the source code myself and fix this bug. I went through the code, and there was nothing that I could really find to fix this. Then I had to rely on my old friends Google and StackOverflow. After some lame results, I landed on a SO page where this bug was explained. Looks like it was not an issue with iTerm, but with bash itself. You see, the bash counts the prompt symbols to determine the total line length and breaks the line according to width of terminal and line width. When you set a color \e[1;36m\e[m \e[1;35m[m which is equivalent to blue and pink, bash tends to treat them printable characters and cont it along with the command prompt. While the truth is it does not add length to command prompt, it just adds up color which is not countable. This messes up the buffer and causes the line wrap bug. So I have temporarily changed my prompt to just

    `export PS1=" \W > "`

without any color. I ll wait for some time. If no one else fixes this, I ll have to do it myself. I really need the prompt color. Because, for me, it is a visual distinction between the consecutive commands. I will post my update if I ever fix it. So for now, if you experience this bug, just delete all the colors. And send me a mail, I ll reply you If I happen to fix this.