Project 31-A

I mentioned in my last post how much I enjoyed Ruby and wanted to continue to use it in my project. That is easier said than done.   In order to leverage all the great Ruby ( RoR ) tools and methodologies I learned, I’m attempting to find .Net equivalents. This started with finding a Behavior Driven Development ( BDD ) tool. There are several that come up but they are a hybrid to a BDD (I picked SpecFlow ) tool siting on top of a TDD tool ( NUnit or MSTest).  I also needed a web driver to make calls to a browser and verify results. I looked at WatiN but went with Selenium .   The next two tools I need to add are a mocking tool ( Moq ) and an injection tool (probably NInject ).   Since the class used GitHub and Heroku , I’ll also stick with that. My GitHub account is DFBerry .  All my example code is posted up their in public repositories.

Introduction Several things happened in a short period of time to influence my decision to take a Ruby/SaaS class. I’m a lifer on .Net or more specifically Asp.Net and it’s precursor, Asp. First, the MVC .Net book I was reading at the time said programmers either use .Net or Ruby for MVC development but not both. Second, an online UC Berkeley class was free and gave me both a new language ( Ruby ) and backfilled any software-as-a-service (SaaS) holes in my knowledge. Third, the class used the Agile methodology which I had bits and pieces of. I wanted to see someone else’s interpretation put into practice.   Ruby on Rails (RoR)/MVC I knew MVC , web protocols, and web development so the learning curve was all Ruby. The class had a quick pace where I knew how to do it in .Net but not Ruby. Ruby, fortunately, is a very easy language to pick up. It feels very much like a script kiddie toy but  more powerful.   Interpreted versus Compiled Ruby is interpreted w...

On the way home from ProductCamp Vancouver, we got discussing the increasing division of product development into smaller and smaller cubicles – each with a hyper specialized individual in it. Back in 1979, I had my first professional employee - then consulting gig. Technically I reported to the head of IT. My customer was a department head managing a 30+ employee group. I meet directly with the department head, his reports and the clerks that would use the application (an interactive system using CICS running on a big IBM 4331 –2 megabytes of memory!!). I did UX mockups and reviewed them. Shadowed the clerks. Refine the requirements. Then I proceed to write the specifications. After that I proceed to design the database and implement (create a relational database using ISAM – not a trivial feat). Then coded up the application in COBOL and tested it (did QA too!). Then it was passed over to user acceptance. Finally, writing up documentation for users as well as design documentation...

This weekend I attend Product Camp Vancouver . Some talks were interesting (review of information that I already know), some were so-so (or worst), and others were good “reference card” session such as the one on UX (User Experience). One of the impressions that I had was that product development is becoming a tower of Babel with everyone using in-vogue phrases scattered in each language (or pidgin language). A common frustration was poor communications with others in the team (UX Product Manager – Architecture – Development).   One of the most interesting talks (with a small attendance) was a pragmatic talk about how far does Agile Development scales. The concept of agile development is well known, but we are seeing terms like ‘agile architecture’ and ‘agile product management’ being tossed around. Often they seem to be used as excuse for not doing their homework.  An agile product management means that the architect must be agile – agile to the point of being continuousl...