Vim, RubyTest, & RSpec

Posted on January 29, 2011 by Michael Koby

If you use the Vim editor (or one of it’s counterparts like gVim), use the RubyTest Vim Plugin, and you use RSpec for some of your testing then you might run into a problem that I was experiencing where it gives you the error:

:!echo 'spec -f specdoc spec/greeter_spec.rb -l 8' && spec -f specdoc spec/greeter_spec.rb -l 8
spec -f specdoc spec/greeter_spec.rb -l 8
/bin/bash: spec: command not found

shell returned 127

Well, since I use RSpec 2.x (since I’m just now starting to use RSpec), the above error is quite annoying because the ‘spec’ command isn’t really used anymore (at least from what I can find on the internet).  So to get the RubyTest plugin to work with RSpec (and the ‘rspec’ command) you have to make a small change the plugin as marked below via a diff.

--- rubytest.vim.old	2011-01-29 14:29:19.897897990 -0600
+++ rubytest.vim	2011-01-29 14:30:16.487584334 -0600
@@ -21,10 +21,10 @@
   let g:rubytest_cmd_testcase = "ruby %p -n '/%c/'"
 endif
 if !exists("g:rubytest_cmd_spec")
-  let g:rubytest_cmd_spec = "spec -f specdoc %p"
+  let g:rubytest_cmd_spec = "rspec -f d %p"
 endif
 if !exists("g:rubytest_cmd_example")
-  let g:rubytest_cmd_example = "spec -f specdoc %p -l %c"
+  let g:rubytest_cmd_example = "rspec -f d %p -l %c"
 endif
 if !exists("g:rubytest_cmd_feature")
   let g:rubytest_cmd_feature = "cucumber %p"
Posted in programming | Tagged , , , , | Comments Off

Testing in Rails, It’s Important

Posted on January 28, 2011 by Michael Koby

Over the course of 2010 I spent most of my off time working on my side project, Just for Bands.  Specifically the first application to come from Just for Bands known as LiveShow.  The LiveShow application was written in Ruby on Rails with the plan to deploy it to Heroku (a successful plan I might add).  But the main point of this post is the idea of doing Test Driven Development (or TDD) in Ruby on Rails and how it allowed my partner and I to build an app quickly.

Testing is Built In

Something to know about testing frameworks and Ruby on Rails, there’s one built in.  The built in testing framework in Ruby on Rails is Test::Unit.  There are other frameworks that you can substitute in place of Test::Unit, but as far as “out of the box” frameworks go, you could do worse.  Having a framework built in allowed me to teach Erick (my partner, who had never worked in Rails before) how to follow the TDD workflow: Write test, run test (seeing it fail), write minimal code to make test pass, see test pass, refactor (bold because people tend to forget this step).  Erick had never done test driven development before, and I had never used Test::Unit (or written a Ruby on Rails app) before, so sticking with the built in framework allowed us to minimize the number of things we needed to learn from the get go.

Delegation of Responsibilities

Erick and I had a pretty strict division of responsibilities with regards to the work needed on the application.  Since I’ve been developing code professionally for almost a decade, I was the developer.  Erick was the sweeper, going between design and development duties where ever needed.  And we hired a graphic designer, John to handle the more complex design work.  Having such divisions allowed us to separate out the work.  But it left me in a position where I felt I couldn’t develop a ton of code because I didn’t have any screens to wire up.  This came from a lack of deep understanding of the MVC (Model View Controller) pattern that Rails is based on.  To keep it quick, this pattern means there’s separation between the UI, data, and processing layers.

Testing Allows Coding Without The User Interface

Because the MVC pattern is designed with separation of various application elements in mind, I was able to develop the backend code without any screens.  The idea of testing functionality as you develop using the built in test framework allowed most of the major functionality to be written and built while the design was worked out else where.  This was crucial to our ability to get the product built and launched in one year’s time, while learning new languages and tools.  Once the functionality was done, it was just a matter of tying it together with the user interface once we had a design we were happy with.  Of course there were things that didn’t work quite like expected when we got the interface wired up, but it was less work than doing it from scratch, and having to wait would have meant delaying the product.

Also, with the tests we were able to see if it was the UI not working correctly or if it was really our functionality.  In a couple of places we were testing for the wrong thing, or had an error in our test that caused a false positive.  But those were much quicker to iron out with the tests in place.  Having unit tested as we developed, we were able to save tons of time on the backend of the project fixing bugs.

Posted in Just for Bands, programming | Tagged , | Comments Off

Ship It

Posted on January 10, 2011 by Michael Koby

LiveShowWith the launch of LiveShow by Just for Bands last week, the stress of getting something done and pushed for public consumption is only half done.  Having actually “shipped” a working product, I understand that it is the larger (and harder) half.

LiveShow took about 2 hours a night 4-5 nights a week for an entire year to get ready.  The idea was always to get a basic product that did just what was needed to accomplish the goal done and pushed out for people to use.  Yes, we occasionally got burned out.  Yes, some things didn’t go quite as planned.  Yes, we got behind sometimes.  But we met our goal and launched within a year’s timeframe.  What was the secret?  We didn’t stop.  If we got burned out we worked on other aspects, brainstormed, and generally found busy work that needed to be done.

But the real secret comes from the time boxing.  Saying to ourselves nightly “I have 2 hours, I want to have [Feature X] working by then” and then working towards that.  The feature being worked on could have just been one piece of a larger feature.  But time boxing allowed us to really focus on what we were working on.  When you have a seriously limited amount of time, it helps decide what needs to be worked on.  On several occasions I scrapped my work and started fresh the next night because something took me longer than 2 hours during the first go.  Most of the time, I was doing it wrong to begin with, but I had to do it wrong to find the right way and those couple of hours that might have seemed like a waste were actual pivotal in finding a solution that worked (and in many places more elegant).

Time boxing also allowed us to maintain family and social obligations.  We started this project with our own time, our own money, and had to learn a few things on the way.  We didn’t quit our day jobs and we certainly couldn’t deprive our families of our time.  Time boxing allowed us to maintain a normal life.  Sure we worked a little more than usual after hours, but the focus that time boxing allows and the fact that we limited our time allowed us to not get carried away.

If you’re looking to do your own side project, I recommend time boxing yourself to a couple of hours a night 3-5 nights a week.  This will allow you to be moving constantly towards your goal without taking over your life.  It certainly worked for Erick and I when working on LiveShow, and it’s one of the tent pole points of 37Signals’ book “Getting Real”.  Give it shot, you have nothing to lose.

Posted in Just for Bands | Comments Off

LiveShow Ships

Posted on January 3, 2011 by Michael Koby

Ship it SquirrelYep,  today my partner Erick and I announced that LiveShow, the first Just for Bands app was ready for the world’s viewing.  It took a year’s worth of programming time at home after work and on weekends, learning a new programming language, learning a new web framework for writing web applications, designing a data model, and figuring out where the app should live.  But, it’s officially shipped as of today around 1:30pm.

What is LiveShow?  Simply, it’s a communication manager for bands that lets them track what band members are talking to what venues with regards to booking live shows (concerts, gigs, etc).  The idea was simplicity.  Get people in and out quickly so they can move on to other tasks.  No one wants to sit and organize communications, add things to a calendar, set reminders, and so on.  LiveShow does it automatically.  As the user logs a communication with a potential venue, LiveShow will automatically set a reminder and the user will be emailed about the follow up when it’s time.

This was my first time doing a project from the ground up and as the main technical person who was in charge of backend design, coding practices, and development tools used so I’ll be spending some time over the next few blog posts going talking about some of the decisions we made from a technical standpoint, so keep an eye out for those if you’re interested.  With this post, I officially enter the “start up” world, and become an entrepreneur.  Hopefully good times are ahead.

Posted in Just for Bands | Tagged , | Comments Off

Discount Calculator Released!

Posted on October 21, 2010 by Michael Koby

This past weekend I released a new Android app to the Android Marketplace.  This one is a simple discount calculator.  No frills, just simple enter price, enter discount, hit “calculate” button to see actual price.  If you’re looking for a QR code, look below.

Posted in Discount Calculator | Tagged , , | Comments Off

Learning a Programming Language a Year: A Plan

Posted on October 4, 2010 by Michael Koby

If you’re ever had the privilege of reading “The Pragmatic Programmer” then you know that they recommend that programmers learn at least one new language a year.   Around this time last year, I made the decision to begin following that practice and chose Ruby/Ruby on Rails as my programming language for 2010.  While not directly related to my day job, I wanted to build something in the language.  With the help of my friend we were able to build our first Just for Bands web application in Ruby on Rails (LiveShow), both learning the language as we went along.  While I’m still by no means a Ruby/Rails expert, I do feel some what comfortable enough with the framework.  I still have to look up how to do things in Ruby, but this is just the side effect of learning a language.  You’ll almost never know everything about a language.

Observation

I believe that part of the problem is that I’m not surrounded by other Ruby/Rails programmers and doing that kind of work on day to day basis.  I spent 5 years in a C# office and thus was able to learn C# pretty well, and when I left that shop to better pursue programming, I was surround by “better” C# programmers that taught me even more.  I believe that I would be better at Ruby today (not having to look as many things up) if I was in an environment that was utilizing the language (and/or Rails framework) on a daily basis.

The Plan

I plan to continue in my attempt to learn a new language every year.  Upon further reading of several blog posts, I came across one that suggested that not only learning a new language but to also rotate the paradigms behind the language you learn (object oriented, dynamic, functional, etc).  This not only allows you to learn a new language but also new concepts and new ways of thinking about problems because a functional language requires a very different thought process than dynamic one.

So with that in mind, here’s what my language plan looks like over the next few years:

  • Oct – Dec 2010: Ruby
  • 2011: Clojure
  • 2012: C

I went with Clojure for a couple of reasons.  The first being that it’s a functional language.  Secondly, it’s not tied to the Microsoft .NET platform (like F#).  While I’ve heard and seen good things about F#, I wanted to keep the Microsoft stack strictly a day-job thing.  Plus Clojure runs on the Java Virtual Machine, so it can really run on any machine that runs Java.  Finally, going with Clojure will bring some experience with Lisp, since Clojure is very Lisp like.  This will bring me at least a smidging of experience with using Lisp, without actually having to learn Lisp.

As for C, some would argue that the C programming language is a “functional” language.  And while there is truth in that point of view, I personally view C as “systems language” (something used to write drivers, operating systems, etc).  Learning C is also a personal mission of mine, and one that I’ve had since  was 15 and never just banged it out.  Something else always came up.

Posted in programming | Tagged , , , , | 4 Comments