Moving On, Leaving Sogeti

Posted on April 29, 2011 by Michael Koby

Almost four years ago, I left working for Prudential Real Estate Services to go work as a consultant Sogeti. The intent was to surround myself with programmers in hopes that I could learn to become a better programmer myself. I’d like to say that the experiment was a success. I met some really great people, who taught me a great many things. It wasn’t all about the programming all the time, but I did get to work on tons of different projects, doing many different kinds of work.

But good things always have to come to an end at some point and a new beginning must be made. There are always new lessons to learn, new challenges to overcome, and cool new projects to get involved with. So as of today, I’m not longer employed by Sogeti, and will be moving on to a stealth-startup here in Houston.

Before you ask, no, this is not my startup, it’s someone elses. I’ll still be working on Just for Bands and a couple of other projects I have in the works (more on these soon, I hope). But this is a company that hired me to work with them on getting their product launched. Since I have a little bit of experience in that area, here’s hoping I can help them with theirs.

What will I be doing? At first it will mainly be Ruby on Rails work. But long term there is some mobile application development that will need to be done and I’m hoping I can get my feet wet in that area too. I’m the second developer on the ground, so there’s some room for growth as well. It promises to be an interesting project where I will get to apply some of the things I have recently learned about Ruby, Ruby on Rails, and getting an app from idea to launch. Hopefully I can learn a few things along the way as well.

Posted in General | Tagged , , | 2 Comments

Google, Android, and Open Source

Posted on April 1, 2011 by Michael Koby

Google announced that they would be holding back with regards to releasing the latest version of the Android operating system. The release in question, Android 3.0 aka Honeycomb aka the version for tablets. The reasoning for this they say is two fold: 1) the code isn’t ready to be released to the public, and 2) they don’t want manufacturers attempting to put Honeycomb on smaller form factor devices (read “mobile phones”).

Then Google announced yesterday that they were going to tighten the requirements on releasing Android based products. More specifically they were going to enforce the clause in their licensing agreement (the one that allows companies to use the “with Google” tag on their devices like the recently released Motorola Xoom) that the devices must meet certain standards and certain objectives must be met.

I want to look at both of these things in this article, because they kind of go hand in hand. Continue reading →

Posted in Commentary, Technology | Tagged , , | Comments Off

Build Only What’s Necessary

Posted on February 1, 2011 by Michael Koby

When Erick and I set out to build LiveShow, we wrote down literally every idea that came to mind. No matter how outrageous, complex, forward thinking, backwards thinking, or idiotic, if it was an idea related to booking shows we wrote it down. When it came time to actually build the application, it became my job to keep us on the straight and narrow. Because as we worked on the application, more ideas came to mind.

Is it Absolutely Necessary

Eventually it all came down to one simple question: Is that feature/idea absolutely essential to booking a show for your band?

If the answer to that question was a “No” then we shelved the idea for possible later inclusion.  It might seem like a really weird idea to not build as many features as possible, but doing so keeps you on the path to actually launching your product.  If we hadn’t followed that one simple rule when deciding where to focus our work, Erick and I would still be working on LiveShow and wouldn’t have gotten it out the door.  If you don’t ever release your product/application then you can never make money off of it.

Release Early, Release Often

Creating an an application that runs and works on the internet means that you can release a product early and gradually add to its feature set as time passes.  The phrase is often heard in what is known as the “agile development method” and it’s called “Release early, release often” and it means to release the product at the earliest possible point and then gradually improve it over time (have many successive releases).

If you want an example of a company that does this frequently, look no further than Google.  A good example of Google doing this would be Gmail, their online email product.  When Gmail was first released it allowed you to do 2 things with the emails you got: read them or archive them.  There was no “delete” button because Gmail gave users one gigabyte of space, compared to Yahoo and Hotmail which gave around 250 megabytes of storage, that was a lot of space.  They believed you’d never need to delete an email again.  Over time they found that customers really wanted to be able to delete so they added a delete button, and then they add a “Trash” folder so you could recover accidentally deleted emails.  They also over time added Google Talk to Gmail.  And more recently they added the ability to make phone calls from within Gmail.  Gmail is just one example of Google doing this.  Android is another example, so is Google Calendar.

The idea is to get your product out in front of the public.  Even if it doesn’t have all the features you’d want it to have, if it at least accomplishes the basic goal of the application then it’s good enough to launch with.  Just because you launch it doesn’t mean it’s done.  You can still make changes, add features, and fix bugs.  Getting the product out in front of people allows you to figure out how people will use your application.  You might find that they use it in a way that you hadn’t foreseen and that might give you a whole new direction to go in (read about Flickr’s early beginnings for a good example of this).

Conclusion

When you start to build something, ask yourself what is the absolute essential things your product needs to allow users to achieve their goals.  If a feature or idea isn’t a part of that, then shelve it for later.  You want to get the product out to the public so they can use it, not keep it to yourself until it’s “perfect” because realistically it will never be perfect.  Get it out there.

Posted in General | Tagged , , | Comments Off

Thinking of Starting a Web Business, You Can Do It

Posted on January 31, 2011 by Michael Koby

Do you say something like “Man it would be great is someone would create a site that does [fill in the blank]” a lot?  Do you find yourself coming up with great ideas only to forget them a couple of hours later?  Have you ever told an idea to your friends, have them tell you it’s horrible, only to see the exact product a year later released by someone else?

Well, do something about it.

Write Your Ideas Down

Have a great idea?  Write it down.  In a notebook, in Evernote (or SpringPad), on a napkin that you put in your pocket, write the idea down.  Basically store it somewhere that you won’t lose it later.  If you write the idea down, you can come back to it later.  I can’t tell you the number of ideas I let slip away because I had this great idea while I was at work and didn’t write it down.  So I started carrying a notebook (Amazon affiliate link) around.  When I have an idea, I stop and write it in my notebook on one of the pages dedicated to business ideas.  This allows me to easily find it later.  If I don’t have the notebook with me for some reason, I open up Evernote (web page or application) and write it down in a note that is specific to my business ideas.  Sure it means I have to look in two places when I’m reviewing those ideas, but at least I don’t forget the idea.

Don’t just write down the idea.  Write down anything related to it.  For example, I once had an idea to give companies the ability to create their own secure chat server, so I wrote the idea down, but I also wrote down to look at cloud computing options that would allow me to start and stop servers as needed, chat server software, protocols, and so on.  That way I just didn’t write down the idea but also the surrounding ideas so I knew what direction I wanted to go.

Pick An Idea

After you’ve gotten a few ideas written down, spend a Saturday reviewing them.  Flesh them out a little.  What do you need to implement those ideas?  What things should you research more?  Which one really gets you fired up?  If you find that an idea sparks a million other thoughts about that idea, go with it.  If you aren’t passionate about it, you’re probably not going to get very far with it.  However, if you find that a specific idea really gets your brain going, focus on it.  It’s really about passion.  You’re going to have to really like that idea to be able to spend the next year or so working on it.

Keep it Simple

That idea that’s spawning a million thoughts a second, that’s good.  But don’t let yourself get carried away with all those secondary ideas.  Write them down so you don’t lose them to the ether.  Instead, after you’ve written them down go ahead and pick the absolute essentials.  For every sub-idea, ask “is this absolutely essential to accomplishing the initial idea” and if the answer is “no” then move onto the next sub-idea.  This will help you determine what’s really important to the idea.  The ideas that aren’t absolutely essential can be worked on/implemented after launch.

This is important: If it’s not absolutely essential to the achieve the goal of your product, you don’t need it to launch.

Build It

This is one of the most important thing to do.  Build it.  Get working on it as soon as you can.  You’ll hit road blocks, have burn out, and have to put some time in during your off hours.  But if you don’t build it, you can’t release it.  Set up a schedule to work on the project.  A couple of hours a day, no less than three days a week.  Having such a schedule really helps you to set aside time for the project but still allow you to have a life.  Having a life outside of work and your side project will delay any burn out experience you’re likely to have.

When you do hit a period of burn out, work on something else related to the project.  Don’t have the website design, work on that.  Formulate plans for after the launch of the product.  Organize the to-do list or write a blog post about what you’re working on or some of the lessons learned so far.  These things help you get through the burn outs but allow you to maintain momentum and your work schedule.

Release It

This is probably the most important part of the whole process.  Getting it out to the public.  Letting real users hack away and break things.  Hey, thinks are going to break, accept this truth early on and you will be less stressed about it.  But releasing your product means you completed the process.  You took an idea from inception all the way to release.  Sure you probably hit some snags along the way.  It probably took you a little longer than you initially thought (it always does).  But, it’s released, it’s out there.

Unfortunately, just releasing the product isn’t enough.  You’ll need to make enhancements.  Those ideas I said you need to put to the side because they’re not essential, start cherry picking those and working on them.  You’ll have bugs to fix.  There will be customers to support, they’re going to request things.  Getting here though is the just the start of the journey.  If you can get to this point, you’ve made it farther than most.

Posted in General | Tagged , | 1 Comment

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