Category Archives: Software Development

Installing Octave on OSX with MacPorts

Most of the time, installing things with MacPorts is pretty easy; however, I have found that GNU Octave can be a little tricky. That being said, it’s still pretty easy to get Octave up and running in both Snow Leopard and Lion.

At the time of this post, here’s two version of Octave to choose from: octave (version 3.2.4) and octave-devel (version 3.4.3). For my money, I like octave-devel. In my brief testing with the two, the biggest difference for me was that the graphs plotted in octave-devel looked more like their OS counterparts. With octave, I found the scaling of elements on the graph to be different sizes and that bugged me.

To install Octave, run the following from the terminal:

sudo port install octave-devel +gcc45

And then wait…as there are a lot of things that need being compiled.

I added the gcc45 variant because one of the dependencies, atlas, needs gcc45 to compile. This ensures that both of those are in sync.

Feel free to add other variants if you like, like X11 support or offline documentation. To get a full list, run:

port variants octave-devel

Continue reading

Snow Leopard and ZendServer CE 4.0.5

So I’m all upgraded onto the new Snow Leopard and I wanted to see what ZendServer CE was all about.  Well, unfortunately, when I try to run it, I see watchdog errors when I try to start the Java Bridge and Lighttpd.  Some have updated the lighttpd service script to not use watchdog (which still hoses the JavaBridge), while others tried to create a new zend user.  What worked for me was to replace the watchdog application.  After doing that, everything worked fine and I didn’t have to modify the lighttpd script or create a zend user.

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

Managing Vim Scripts with a Vimball

I am a vim user.  The thing I like about vim is it’s speed, how universal it is, and it’s customizations.  These customizations can come in the form of plugins, syntax files, compilers, and code completion utilities; all of which are scripts.  Scripts can be a single file like MiniBufExplorer or can encompass multple files like vjde.

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.
Continue reading

Code Reviews – Inherit in Git

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.

Continue reading

A Tip For People using Google Code and the Issue Tracker

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.

Playing with Lighthouse

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.

Continue reading

RMagick added to gotAPI

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(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.

Google Image Labeler

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.

Getting Real Review

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(eXtreme Programming) 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.

Continue reading