Apps
Contact
Seminars
RSS FeedAugust 27th, 2011
Code Reviewers’ Pet Peeves
As a code reviewer, certain things tend to bother you more than other things. Here is the list of 3 things that bother the @*(# out of me.
- Using code as the revision control system: Developers tend to comment out code, not delete it. Call it pride of authorship or something else, but it is difficult to delete that excellent, eloquent, functional piece of code that was relevant before your product/project manager decided to change the requirements completely (and completely out of blue, barely x hours after lauding your excellent work!). The main justification that the developers tend to give is, “Well, what if we want to add that feature back?” Well, Joe, no, we are never going to bring that feature back! Never.
Never, ever. Because we never change our mind. But just in the slimmest possible lemon peel of a chance that we do bring that feature back, then we will use the RCS to go hunt for that piece of code, or better, you will redo it from scratch! You wrote such good code the first time around, that I just shudder in awe of the future code that you will write when you have already written that once. So, for now, stop using code as your RCS, be brave and delete the code. If we have to give Developer Medals of Honor (DMoH), then, that should be awarded to the brave developers who have written something fabulous and deleted it from their code when requirements changed, thus relegating that phenomenal piece of code to the deathly hollows of the RCS, and done it without evincing pain. - Using naming conventions that are beyond wrong: This one causes no visible problems, other than sometimes befuddled customers or higgledy-piggledy users who are confused that the browser bar is showing “AddInvoice.jsp” or something similar, when they were clearly trying to edit an existing invoice. Horror of horrors! The customers are just not adept at recreating the thought process of the developer Alice when she was creating the page the very first time, before the first invoice existed at all! So, Alice conveniently called it the AddInvoice page, and since she is a good developer who follows the reuse principle, Alice decided to reuse the same page for editing an invoice. Alice, imaginative as she is, did not consider the possibility that a glasses, jeans/t-shirt wearing user would actually notice the URL when using a part of the application. Clearly, there is no shortage of horror movies in the software world.
- Using single liner if else blocks: This one is the easiest of the problems to fix. Just make this a hall of shame qualifier in your team (or a compiler error in your IDE settings).
No one should write if else logic that does not use curly braces to wrap the pieces of logic that go inside the if and the else blocks. This really is just a code format issue, but the number of times that I have seen this cause sudden bugs to appear in the version X.0.1 when version X.0 seemed to run absolutely fine is far too many to let this go by. Too many times, a developer will add a log statement to the first line of the else block, entirely changing the meaning of the block. This one should be considered the one-liner joke equivalent of the software comedy genre.
December 26th, 2009
Sorry, I don’t git Linus Torvalds
After my previous post on SVN and CVS, I was pointed in two directions (independently) to Git, and Perforce. The suggest to Git came in form of the Tech talk by Linus Torvalds at Google on source code management. In this talk, Linus blasts CVS, SVN, Perforce, Google and the rest of the software industry. 
So, then I got about researching Git. Firstly, its premise is quite faulty – about commit access, etc. Linus spent about 10 minutes solving a problem I don’t have (Reminds me of CueCat!). He says the basic problem is that you don’t want to give commit access to everyone, but then politics comes in, so 
you end up giving commit access anyway. (And hence distributed source code management, and hence Git.) Hmm, that is really weird – I have never heard of this “commit access politics” problem. I don’t have this problem in my current job at NTELX where I am responsible for managing all software products. Further, I have never had that problem in any of the other software jobs that I have had. Checked with a couple of friends at Microsoft and Facebook (combined the questions with happy holidays phone calls) and those friends do not know of this problem either. So, I am forced to assume that this specific “problem” is a problem only for open source software projects. I don’t think it makes any sense for commercial software companies. We have enough carrots and sticks in place, that perhaps open source software projects don’t. I am personally notified of every single commit that happens to the head, and then, if I have the time and inclination, I may do a source code review. Most of the times though, the commit seems to be in line with what product and module the specific team is working on, and you just let it g
o.
So, what carrots and sticks does a commercial company have in place? An obvious stick is the employment itself. If you do make a wrong hiring choice and end up giving “commit access” to someone who should never have had it, as soon as you realize that, you take away the commit access and make the right recommendation to HR, take the stuff happens route, and go back to step 0 (recruitment). Carrot is obviously in form of developer appraisals and bonuses. People are usually happen when they get it. (It is nothing like this Dilbert.) There are many other levels between carrots and sticks, which roughly amount to better training and communication. Most usual error that developers make is of trying to develop without forcing 
that all gaps in the spec be filled, and that can be fixed by telling them exactly that.
All in all, I gave up discounting Git, because I gave up discounting Linus. Half the times I could not be sure whether he was being serious, in which case it would be tremendously arrogant, or if he was being funny, in which case the joke was being pulled on way too long. One way or another, Linus, I don’t know anything about you, but you are no Turing or Tarjan, at least, not yet.
One other point, though played a role in discounting Git. It says that in centralized versioning systems, the central repository is an obvious point of failure. Doesn’t take a genius to figure that out, but it is worth pointing out that since 2000, I have not once had this problem of my central repository going down. Not once. And somehow I am supposed to worry about that? Even if happens right this very day, so what? Our sysadmin will replace the lost disk with the off site backup from 4 hrs ago, developers will recommit the files (that they have on their hard disks anyway), and we will move on. If that is the biggest thing that Git is going to solve for me, then really, it is not that big.
Next, I researched Perforce. I used Perforce a while back at a project, and liked it decently enough. I am still open for using it, and am researching its pricing and cost benefits statement.
December 19th, 2009
Is it the Technology or the Tools? SVN or CVS? Java or Visual Basic?
One more time, the question emerges: is it the technology or the tools that make something popular? On this December day, I am certainly very much biased towards tools. My immediate comparison point is version control systems – CVS and SVN. Subversion is touted to be much superior to CVS, and whether or not that is the case, today, I have decided to move back to CVS, on at least one of the projects. The decision was not based on the technological underpinnings of CVS and SVN, rather only on the simple fact that a simple, free GUI client is not available for SVN, so
mething that is analogous to WinCVS. Of course, there are tools like SmartSVN (excellent tool, I do have a registered copy of it, but not everyone does or is interested in buying one), and Subclipse. Subclipse works reasonably well (nothing like SmartSVN), but I have never been a fan for Eclipse being the center of my life – I do development less than 20% of time, and don’t want a development tool to take place of my file explorer. There is also TortoiseSVN, which as its name suggests, is stupendously slow, and RapidSVN, which as its name suggests, can be very rapidly discarded as a candidate.
This is not the first or the last time a discussion on technology and tools has arisen. Much more commonly, this has been discussed well in the context of Visual C++, C#, Java, Visual Basic and others. Java, since being introduced in 1995-1996, did become popular, but it was certainly in spite of a lack of tools, certainly not due to the tools available with it. Microsoft (am I raising your heart beat frequency yet
?) is definitely the master of bundling tools with technology, to the extent that the students at Bowie State University where I taught CTEC 125 for 4 semesters can absolutely not distinguish between Visual Basic and Microsoft Visual Basic Studio. Giving the credit where it is due, for business majors (who are the main audience for that class) the difference is neither important nor interesting, but what is definitely very important and very interesting is that Visual Basic is one of the easiest languages to learn, and that is due to a combination of the language as well as the IDE. Today, Java has a very good tools/IDEs market, and Eclipse, IDEA, NetBeans and Oracle JDeveloper are all good choices (to be clear, I have not used the last 2 in more than 3 year, but I continue to hear good things about them). And yet, when making a complex GUI application using a WYSIWYG editor, even Eclipse does not come close to the free Microsoft Visual Basic Express Edition. You have to get into Eclipse, and paid plugins like 70$ jigloo (or better yet the $1000 JGo, if your application requires it) to match what MVBEE comes out of the box with. All that said, I have been a user, leader and proponent of all Java based technologies in the last 10+ years, and to repeat it one last time – that part is due to the Java technology, and in spite of the lack of good tools that go with it.
Ok, back to SVN, CVS and tools and technologies. Listen to Sebastien’s rant on why SVN sucks. While I don’t make such a tall claim, the conclusion I am drawing is no different from what Sebastien draws, even if the rationale might be different. In one of the “defends” on that post, Nicholas makes an eloquent, but irrelevant point that Subversion is 
only the server, and the GUI apps are from 3rd party providers. The lack of that distinction (between tools and technology) in itself is the point of this entire post. Who cares who makes what, as long as the technology and the tools together are a sufficient mixture. And when they are not, the nerds will rant, the tweets will flow, all hell will break lose and the (SVN) world itself may come to an end.
October 9th, 2009
Changing CVS Root using find exec
There are a thousand ways to change the CVS Root, and one of them is this:
find . -name CVS -exec cp /tmp/Root {} \;
Obviously, what this does is to find each folder named “CVS” in the current folder, and copies the file /tmp/Root file into that folder.
(Just a handy trick.)
January 8th, 2009
Getting email notifications of CVS commits
I always knew that there must be some such feature already in CVS, but just never got around to checking it out. Until now! So, here it goes:
If you want to get automatic email notifications (or want to do something else) when users check in code into CVS, it is rather simple to do:
- Log in to the CVS server, and go to the CVSROOT folder.
- Edit the loginfo file. By default, this file exists, and has a few comments. You can add a new line at the end, that says something like:
src/com/yourcompay/p1/* echo “File %{sVv}” | mail -s “p1 commit” you@youremail.com
Basically, the sytax of the loginfo record is:
- Pattern of the file to match
- Followed by command that should be run when a file matching the specified pattern is checked in. %s, %V, %v and %t are special variables that stand for full file name (%s), old version number (%V), new version number (%v) and tagname (%t).
The downside of this feature implementation however is that there is no way to filter out by tagname (if you want to get notifications only on certain tag, or trunk). Also, there is no way to filter out just by a person (say, if you have a problem developer). Also, no way to include the CVS diff in the email. Oh well.