Skip to content

Recent Articles


Conducting Developer Interviews

Ideal Question Flow

  1. Personal information
  2. Complex projects that he has done
  3. About the particular technology we are hiring
  4. Object oriented questions
  5. Logical / Programming questions
  6. Version control questions
  7. Database concepts
  8. Security related questions
  9. General technology news

Read moreRead more


GIT command autocomplete in mac

In your home folder create / update .profile with the follow

if [ -f /usr/local/git/contrib/completion/git-completion.bash ]; then
  . /usr/local/git/contrib/completion/git-completion.bash


PS1='\[\033[32m\]\u@\h\[\033[00m\]:\[\033[34m\]\w\[\033[31m\]$(__git_ps1)\[\033[00m\]\$ '

if the /usr/local/git/contrib/completion/git-completion.bash is missing you can get that from here



Chrome Trac Extension

Chrome Trac Extension

Tired of refreshing your trac each time to grab new tickets? Chrome Trac Extension is just the one that you need then. Just add the rss feed URL you would like to keep trac of, and this extension will bring your new Tickets/Comments on to your desktop, and show the open ticket count in your browser bar.

Get Chrome Trac Extension


PHP Code review checklist

I love to do code reviews because it give me chance to see how other people write code and improve mine also. I have seen many people who are afraid of doing code review. Which made think of creating a code review checklist for php. Please note this is not full checklist for code review and following all the conditions in this will not end up in a great code. But following this will end up in  code that can be maintained by others in the later stage of code development.

  1. No syntax/runtime errors and warnings in the code
  2. No deprecated functions in  the code – You can get the list of deprecated function in php3 from the url (Thanks for Frank for sharing me this link)
  3. There should be an explanation for any code that is commented out. “Dead Code” should be removed. If it is a temporary hack, it should be identified as such.
  4. Check if code has file/class/function level comments.  And each of this comments should explain what the file/class/function is doing inside it.
  5. Check that each function is doing only a single thing. That is never function named createCustomer should delete the existing customer and create it again
  6. A method should not be larger than 40 lines of code. The basic idea is always a function should  be viewable in single screen with out scrolling.
  7. Always try to initialize the variable before using that in a function.
  8. No public class attributes.
  9. Always try to use constants in the left hand side of the comparison. That is instead of doing if ($variable == 2) always use if (2 == $variable) because this will help to identify the errors in the earlier stage of development even if we miss and “=” from  that statement
  10. Never ever mix the php code and template (view). In ideal condition a view should not contain any logic.
  11. Always try using single quote ( ‘ ) when working with the php string because it has a minor performance improvement when compared to the double quotes ( ” ). The difference come from the factor that ( ” ) can be used to build a string with variables inside it.
  12. There should be no catch blocks which catches an exception  and throw that again. This is because exception can bubble up to the top function call stack automatically.
  13. Never ever throw a general  exception with a custom message. Always try to create a custom exception so that all the other code can handle this situation correctly.
  14. Make sure that the top most code handles all the exceptions correctly shows correct / understandable error messages to the user
  15. In the case of a system crash never ever put up the error information that expose the internal  behavior of the system.
  16. Make sure that a proper and uniform coding standard is followed through out the files. I have seen many projects where people mix up the coding style. For php I usually use PHP Code Sniffer for validating the coding style.
  17. Try using the tools like PMD to identify possible bug, dead code, over complicated expression, suboptimal code, duplicate code.
  18. No magic numbers. There should be no magic numbers like 6,10 etc… any numbers like this should be define as a constant. And Constants should be well commented about the purpose.
  19. Never allow bad code with some good comments
  20. Always try to have unit test for the new piece of code. In ideal condition we should have 100% unit test coverage
  21. Never allow unit test that are written to show 100% coverage and doesn’t do anything that unit test is supposed to do. I have seen unit test code which just call the function to get 100% coverage and doesn’t have any assertions.
  22. Always commit /Rollback database transaction at the earliest. Keep the database transaction short as possible.
  23. Always have an eye on the recursive functions.
  24. Optimizations may often make code harder to read and more likely to contain bugs. Such optimizations should be avoided unless a need has been identified. Has the code been profiled? Check if any over optimization has led to functionality disappearing.
  25. As a reviewer, you should understand the code. If you don’t, the review may not be complete, or the code may not be well commented.
  26. Lastly, when executed, the code should do what it is supposed to.

my .gitconfig

Creating a good .gitconfig file is always a pain in the ass. So I thought of sharing my gitconfig file with world. This gitconfig file is a result of lot of googling and reading

  name = Jose Antony
  email =

  # nice log output
      lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative

  # Search for a given string in all patches and print commit messages
  # example: search for any commit that adds or removes string "foobar"
  #     git searchcommits foobar
  # example: search commits for string "foobar" in directory src/lib
  #     git searchcommits foobar src/lib
  # example: search commits for "foobar", print full diff of commit with 1 line context
  #     git searchcommits foobar --pickaxe-all -U1 src/lib
  searchcommits = "!f() { query=\"$1\"; shift; git log -S\"$query\" \"$@\"; }; f \"$@\""

  ui = auto

[color "branch"]
   current = yellow reverse
   local = yellow
   remote = green

[color "diff"]
  meta = yellow bold
  frag = magenta bold
  old = red bold
  new = green bold
  #Highlight whitespace in diffs
  whitespace = red reverse

[color "status"]
  added = yellow
  changed = green
  untracked = cyan

#Highlight whitespace in diffs

NSLog tip

Many of us have a habit of writing the following code through out the project

#ifdef DEBUG
        NSLog(@"%@",  @"Some debug message");

Instead of copy pasting these 3 lines of code I created a preprocessor that will replace these three line of code to a single line with more information such as the class and function name

        #define debugLog(fmt, ...) NSLog((@"%s [Line %d] " fmt), __PRETTY_FUNCTION__, __LINE__, ##__VA_ARGS__);
        #define debugLog

The out put of debugLog(@”%@”, @”Some Debug Message”). will be

-[ClassName FunctionName] [Line 25] Some Debug Message

GIT – xcode project file

I have worked on iPhone application full time since last year, Most of that time I spent working on team with multiple developers. And we have been strugling to keep the .pbxproj file in sync across the team. A bit of googling, we ended up in creating a .gitattributes file with the following content

*.pbxproj -crlf -diff -merge

The truth is that it’s way more harmful to disallow merging of that .pbxproj file than it is helpful. As you say, when you add a file unless other people get that file, they have to also add it to their project – in an application of any size, that sucks and it also takes away a huge benefit of source code control in that you cannot really revert to a complete earlier project state just through git.

The .pbxproj file is simply JSON (similar to XML). From experience, just about the ONLY merge conflict you were ever get is if two people have added files at the same time. The solution in 99% of the merge conflict cases is to keep both sides of the merge, which for git at least simply involves removing any >>>>, <<<<, and ==== lines. In fact this is so common that I have created a simple shell script to fix a .pbxproj file in a merge state from git, I run this from within the project directory (at the Classes level):


projectfile=`find -d . -name 'project.pbxproj'`

cat $projectfile | grep -v "<<<<<<< HEAD" | grep -v "=======" | grep -v "^>>>>>>> " > $tempfile
cp $projectfile $savefile
mv $tempfile $projectfile

Worst case if it fails (you ask XCode to load the project and it fails to load), you simply delete the .pbxproj file, check out the master from git, and re-add your files. But I’ve never had that happen in many months of use with this script, again working full time on iPhone applications with several other developers.