def things_n_stuff

Adventures in Code

Sampling Code Organization

Fairly soon I’ll hopefully begin cleaning up and open-sourcing a few projects I’ve been working on. To get a better idea of how programmers organize their codebase I’m going to look at a super-simple app.

For simplicity and clarity (and fun) I’m checking out the Bubs App on github by the just stupidly awesome Zach Hollman.

Bubs

The Bubs functionality is straightforward enough: “ⒷⓊⒷⓈ helps you write really obnoxious text from your command line. Try it in your commit messages- your coworkers will love you.” Love it. Need more pointless fun in my life. (Also love The Wire.)

Install and run. I get some odd formatting because of over-personalized .bashprofile etc., but otherwise all good.

Smaller icon

So What’ve We got:

  • bubs Holds everything
  • bubs/bin/
    • contains a file labeled bubs
    • is an executable file, tells bash to use ruby and requires the gem
    • grabs the arguments following “bubs”, assigns to a variable and sends that variable object to the Bubs class as an argument to the class method “copy”
    • prints the result to the console
  • bubs/lib/
    • contains one file with one small (clear and well-commented) ruby class
    • runs the image conversion and returns it to the executable file in /bubs/bin
  • bubs/.gitignore/
    • the file you all know and love
  • bubs/LISCENSE.md
    • the ‘please play nice and don’t sue me’ file.
  • bubs/README.md
    • the ‘how to use and install’ file
  • bubs/Rakefile
    • not super clear on this one, but I think it’s kind of similar to a task compiler for your app written in ruby. A ruby Makefile.
  • bubs/bubs.gemspec
    • again not super clear here. Spec sheets are usually tests, but Holman says that this is the “rakegem gemspec template”. Seems to simply list out settings and tasks for the rakefile, and pull all of the files together.

That’s all for now. Next up, dissecting a program with a few more layers, Evoke, by thumblemonks.