Now that I have that done, I get to play around to see what all the buzz is about.

Single file scripts are fairly easy to manage.  If you notice a new version of your script is released, then simply replace your file with the new version.  Likewise, it’s very easy to remove the script if you want to just try it out.  However, scripts spanning multiple files are much harder to manage.  For one, the script’s files get merged in with all of your other script files.

To help know what files are apart of what plugin, I manage my vim scripts in git.  Another way to keep track of things is to use a vimball.

What Are Vimballs?

Vimballs are essential vim script installers.  Each vimball contains all of the files that are needed for the script to work.  Not only that, but it also has a hook for you to easily uninstall the script as well.

Tail Bundle is a script that mimics tail -f for vim.  The downloadable artifact is a vba file.  That file is the vimball.  To actually install the file:

1. vim tail-03.vba
2. :so %
3. :q

So what that all means is that you’re opening the vimball in vim.  From there, you’re executing the instructions that are in the file.  Lastly, you’re just quitting.  You see, a vimball is a vim script in of itself.  So executing it writes everything out to where it’s supposed to go.

While the tail bundle makes use of the vimball, not every script does.  Luckily, it’s easy to make vimballs out of most script downloads.

Converting Scripts to a Vimball

In order to make a vimball, it’s quite easy. List out all of the files you want to include in your bundle, relative to where your current directory is.  For instance:

doc/myawesomeplugin.txt
plugin/myawesomeplugin.vim
syntax/myawesomeplugin.vim

Next thing, while in visual mode, type ggVG:MkVimball myawesomeplugin. The ggVG is a akin to doing a “select all”.

This will create your install file named myawesomeplugin.vba.  Now just install it like any other vimball.

You don’t have to just make vimballs for your own scripts.  I love xpt, but there are so many files to manage.  Well, you can make the vimball script even when the author does not.

Open a new buffer and use the command :r! find . -type f.  This will find all of the files and print them out into the buffer.  If you want to do any cleanup, like remove blank lines and removing the extra ./ before each entry, feel free to do so.  Now that you easily got a list of all the files, create the vimball from that.

Now you have records of what went in with the script and you have a super easy way of uninstalling the script too.  Speaking of which…

Removing Scripts

To remove a vimball script, simply execute :RmVimball myawesomeplugin.  That will go through and delete all files created by the plugin.

After figuring this out, I now know that when I want to use and install vim scripts, I’m going to do so via vimballs.  It’s too easy not to, and the benefit of having a way to back-out scripts is just too tempting.

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.

Programmer A creates a fork of the master project. A makes his changes and commit his code; however, the code is committed to his local repository and not the master origin. This is because A does not have write access to that repository.

A has to contact programmer B, who has write access. A tells B that he should pull his code. Since B has to pull the code, this means that B has to review the code coming in.

It’s this workflow that promotes code review. Now that’s not to say that you can’t do code reviews in a centralized model, it just fits a little better in a distributed model

So what does “This software cannot be installed because the file system of the OS volume is not supported” even mean???!?! I tell you what it means, it means that Photoshop will not run if you happened to have formatted your file system to be case sensitive Thanks for the clear error!

I don’t even want to begin on how insane that sounds to me? So what’s a person to do?

Well, my friend James Gibson suggested that I install Photoshop in Windows and use Photoshop through WMware Another possibility is to rename directories to make CS3 work

I think I’m leaning towards the first option as some people are having some issues with the renaming method. Either way, it’s kinda lame.

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.

Tagging

For one, Lighthouse has but a few options for the ticket status: _new_, _open_, _closed_, _invalid_, and _on hold_. Other than categorizing which milestone the issue can be delegated to, there’s not much left for structured organization. There is no severity, no priority; however, there are tags. Tags are your way to add any kind of priority or severity. *The good*: You can add any organization that you want. *The bad*: You can add _any organization that you want_. That means that communication would have to be very good between the team as to what conventions are used if you want to rely on tagging for additional classifications.

Application Integration

I’m a SVN(Subversion) user, so I was pleased to see that Lighthouse and SVN can play nice together Simply create a post-commit script in your subversion repository to submit your changeset to Lighthouse and it works. The magic really isn’t in that it sends the changeset to Lighthouse, but rather that you can add commands in your comments to change the status of a ticket. You can change the state, add a tag, and set the milestone for an issue all in the comments. No need to go back to Lighthouse to update it.

There is also supposed to be integration with emails. Upon getting an email notification on an issue, you can reply to that email and then that message will be added to the ticket too. I say “supposed to” because I can not been able to get that to work.

API

Even though you don’t have access to the Lighthouse database, you do have access to all of your data via the API. The good people at Lighthouse have created a small ruby library to use that implements ActiveResource Would you like to find all of the tickets for a given project? Try using Project.find(:first).tickets. Always good if you would like to make a CHANGELOG file or do any other reporting that Lighthouse does not offer.

User Interface

It’s nice looking, unlike Mantis which is very not. It feels quick and snappy and is very usable. Not much to say here except that it’s probably my favorite of the web issue trackers.

The Payment Plans

This is a pay service, but there is a free account. So feel free to tool around and get to know Lighthouse. But I do feel that the service is a little pricey. The _Personal_ plan offers more projects and more users, but no public projects. That would mean you would need to upgrade to the _Bronze_ package. Personally, I would like the features of _Bronze_, but would like the price tag of _Personal_.

The plans go all the way up to _Platinum_ at $120. I am curious as to how many people have signed up for that service. I don’t think Lighthouse is worth that considering that there is no fancy reporting and crazy customizations that often times larger groups would -require- want.

Conclusion

I think I may look into using this for a personal project. The integration and ease of use is terrific, plus it looks really good. Since I am a cheapskate, I may just continue to use Mantis or try using Trac or Collaboa

What makes this service interesting is that users can help support what gets put on the site. To contribute to their API(application programming interface) 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.

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.

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.

As a developer, the philosophies in this book are empowering. A lot of times, my projects experience some scope creep, where wouldn’t it be cool if it did this or while we are at it, let’s add that. This is fine, but as deadlines approach, you start having this juggling act you have to do where you give up one thing to make another happen, often times leading to everything being in half-assed. Getting Real’s point of view is to cut back some of the scope and make sure that the basics work. “Build half a product, not a half-ass product”. If those extras really needed to be in, they will make it in eventually, in a new iteration.

By doing this, it also allows you to focus on what is important. Adding some new sorting feature is definitely less important than making sure that the data it’s sorting is correct. And this is where a lot of the agile philosophy comes in. Start with the most basic functionality needed first, usually the HTML(hypertext markup language). The HTML is the interface for your application, and that’s everything that’s important to your users. For the first round of HTML, everything doesn’t have to be pixel perfect just yet. Once that is done, then building out the basic functionality to link everything together can be built, focusing on the main aspects of the backbone of the application. For instance, if you are doing a blog, the functionality to write the blog is more important that that of displaying the blog because you can’t display it if you can’t write it.

All in all, this was a good read and it is a fairly quick read. While there are many PDF pages, a lot of it is filled with quotes from all sorts of people. If you ignore the quotes, you could finish it in a night or two. You will do it a little injustice, as the quotes and little stories really bring home the points of the book. I am going to try to use the lesson of this book to apply this to my next software project.