Code Reviews are common in software development. One programmer reviews another’s code to find potential issues or to see if the developer could have used something that the system already provided.
With multiple programmers, you can probably expect a versioning system, perhaps a centralized versioning system like SVN or Perforce. With that system, each programmer would make his/her changes and then would check in his/her changes into the repository. From there, the programmer’s peers would review the code.
What’s the problem with this system? The code is already checked in. The pressure is on the peers to ensure that the code is good, and it’s likely that this could slip through the cracks. I mean, those peers are working on getting 10 features complete themselves.
Enter Git
Well, I would argue that Git has a strong code review process built right in. This is due to the process of how distributed version control works.
Read the rest of this entry »
So there I am, wanting to install Photoshop on my laptop, which happens be a Mac with Leopard installed when I see this lovely message:
Read the rest of this entry »
If you are using Google Code, and let’s say that you want an issue addressed, like having ruby supported in GAE. Please, Please, PLEASE, use the star voting and avoid making comments that are simply “+1″. The more stars a defect has, the more attention it has, not the number of comments and especially the number of “+1″s.
Actually, you hurt the initiative to get an issue addressed when you make those comments. You see, when you star an issue, you receive emails when that issue gets updated or commented upon. So if an issue has 100 or so “+1″ comments, then whoever put a star on that defect is going to get 100 or so emails. After getting 20 inane emails, one might decide to remove the star from the issue, thus lowering it’s rating and hurting the campaign.
So please, if you want to help, just star the issue.
Today I played around with Lighthouse, a site for tracking the issues and features of your project. It’s very simple, but in a good way. I have used several issue trackers, like phpBugTracker, Quality Center, and Mantis to name a few and Lighthouse has a different feel about it. In a word, it’s all about simplicity.
Read the rest of this entry »
gotAPI is a nice little resource for searchable documentation for some common programming languages and libraries, like PHP, Ruby, CSS, JavaScript, Protoype and the like. The site does not host the documentation itself, but rather provides an interface to find things on other pages.
What makes this service interesting is that users can help support what gets put on the site. To contribute to their API, you create a simple XML file which lists out all of the classes, properties, members and links to where those elements live.
For a project that I am working on, I required the use of RMagick and then i explored their documentation. The Image class has methods spread across three different pages. So I created the XML document with some curling, awking and other scripting fun and posted it to gotAPI. It was fairly easy and I can find things a little easier now using this site.
Google has released another beta product called Google Image Labeler. The premise is you and a random partner have 90 seconds to get a match on as many pictures as you can. A match is a label or tag that you give to the image is the same as one your partner has given. So it’s a little game you can play in your off-time, and if you sign in, you can use a display name.
This is just genius. By creating a game out of it, Google is having the users of the internet help them find better ways for users to search for images. The other brilliant part is that it only lasts 90 seconds, so you are forced to think quick, and thus you have more of a stream of conscious going on and you are less likly to filter your response.
I have come across the works of Pete Wright, as I have come to know him somewhat. He does a lot of agile and XP development, and that is something that I have been wanting to learn more about. While reading through his blog, he mentioned a book, Getting Real, so I had to take a look and review it over.
The book is a publication from the fine folks at 37signals and brings to light some of their coding philosophies, such as how they do agile development. It is a cheap book and you can achieve instant gratification from purchasing it online because the book is currently only available as a PDF download. The voice of the book takes a stand and casts a very bright light in order to bring out the contrast of other methods of software development and project management. The authors like to shock you up a bit by making claims of saying “no” to your customers or saying “no” to project meetings. It’s like a cold shower for your brain, and once it has gotten its attention, it reasons with you as to why you would want to say no in certain situations and why you would want to say yes.
Read the rest of this entry »