You are viewing a read-only archive of the Blogs.Harvard network. Learn more.

Checking your syntax on commit

A good IDE can spot programming syntax errors and alert you to them before they ever make it into a git commit. However, sometimes when you’re in a hurry, tired, or distracted, these alerts go unnoticed and there is a greater risk that you’ll commit broken files to your git branch. Git makes it a snap to revert changes, but wouldn’t it be nicer if you could prevent it from happening in the first place?

To that end, git has a nice feature called client-side hooks. In particular, you can create a hook known as a pre-commit hook that executes right before you commit something. It gives you the option to abort if something doesn’t look right. Using this feature, I created a simple script to check PHP and Javascript syntax on commit. It’s helpful for those mornings when I haven’t quite had enough coffee yet.

Open Sourcing Now vs Later

We decided a little while ago to open source our projects. We had people asking for it and we kept having to say “sorry, we can’t really do that”. Our software wasn’t written with the understanding that anyone would look at it ever, so like most software it was poorly documented and tightly coupled with proprietary services. So it wouldn’t really be helpful to people and we were embarrassed by our own code (as most people are).

So we decided to rewrite some of our applications and the question came up should we open source it from line one of the code or wait until we were at version 1.0. When talk first started about open sourcing everyone agreed open sourcing from line one was the way to go. We three it out on github and just worked off of that. Then people started asking to see it. And there was some delay because we needed to decide on a license. And then we had a license and no one wanted to release.

I personally wanted to tell people where the code was. That’s the point I thought. But it became increasingly important to everyone else to release a more complete project. The thinking, I believe, is that if we release something that isn’t really useful to anyone from the get go, people aren’t going to ever check back. The thinking is they’ll take one look, say “huh” and never look back.

I can understand that but I still don’t agree with it. If you wait to open source software until it’s in a state you feel comfortable with, it will just keep getting pushed back because we as developers often have a perfectionist complex. It will never be perfect though.

The solution, I believe, is documentation. Not developer documentation, but very simple user documentation that doesn’t take long to read that they can look at and get a good idea at the state of the project and he direction of the project. A properly organized issue list can be very helpful. If peole can take a look at what’s being worked on, they can get a feel for where the project is. Thankfully github facilitates all of this in one place.

Just put it out there, but make it easily understandable what he state of the project is, where it works and where it’s lacking.

Posted in ATG. Tags: , . Comments Off on Open Sourcing Now vs Later »