Due to NDA limitations I had to remove links to the final product Latest Project Virtual Design Tool. [ url removed due to nda issues ) -: ]Some points that were fun, new, and challenging.

  1. Model, View, Controller mindet.
  2. Building the RESTful service/API first
  3. Trying to follow a feature driven development plan.
  4. Having smaller tasks and more points of QA
  5. Having smaller points to check in with the client to review the finished tasks and not wait till the “end”.
  6. Make it modular so it would work just as well outside of the site as in.
  7. Verbally breaking up the Classes, functions and overall code used to make the App. 
  8. NaturalDocs documentation tool and syntax
  9. JetBrain IDE
I have been trying to learn the Model View Controller structure to code in. Since we are working with drupal it seems to be a tough fit. Basically drupal becomes possible via some custom code with a RESTful API. It’s menu router offering one point of access for anonymous level data (right now just read only).

From there the work was making the Models to deliver back to the Controller the data requested. The App calls to this end point with requests. The App then has a View that receives the Model’s data and outputs it on the page. MVC is still quite new to me. Mix this with OOP and you get a lot of new ways of thinking in one project. So it was a good start but not perfect.

We learned from our last project and 100 projects before that the endless issues with “Big Up Front Design” [“Because any big design created in advance of working software cannot be correct” Practical Object-Oriented Design in Ruby: An Agile Primer (Addison-Wesley Professional Ruby Series) by Sandi Metz] also not having enough small measurable pieces to review with the client, ie Agile.
“Because any big design created in advance of working software cannot be correct” Practical Object-Oriented Design in Ruby: An Agile Primer (Addison-Wesley Professional Ruby Series) by Sandi Metz

This smaller project we took time to break up the scope into numerous tasks grouped in a Feature. That feature/interaction was then placed inside a Burn Down chart to help track progress. [Great info here http://joel.inpointform.net/software-development/b rn-down-charts-tutorial-simple-agile-project-tracking/]
Each task was smaller than 2 days. We initially played quoting poker as an office to guesstimate the tasks lengths. Many of the tasks ended up being small modular functional parts of the whole we that could QA internally or show to the client. For example the full product looks like this. [photo removed per NDA] But the work was broken up into smaller pieces as such Shapes BarOrientation Bar [photo removed per NDA] Texture and Colors bar window where images wrap out. etc.  Small chunks that we could make focused css and javascript around. 

Then we took a full day, 2 coders, to outline on paper, white board etc how to build the App. This was tough since it seems anti-productive. But mix this with writing tests, documentation and it was easier to be more precise about what was being built. The other goal here was to make it very modular. Ideally it could work outside of the website css and all. Scalable and Modular Architecture for CSS [photo removed per NDA] 

On a side note one of the cool things about the App is how the effect is made. There is really only one large swatch image and then a set of transparent orientations per Shape.  The initial load of the page only pulls down the default Shape’s set eg 4 orientations.  When you click a Shape the new set is pulled from a stored result in the jQuery.data object which was stashed there via the initial delivery of the JSON data. There is no new pull from the server till you click a new Texture. This was one possible way to reduce the image lag and download that can happen with a large set of image..[photo removed per NDA] was a good way to document the code but I am starting to agree with some of the books I am reading that good code should read like a book and not need comments and docs [Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin http://www.amazon.com/dp/B001GSTOAM/ref=r_soa_w_d ]. Opening notes or a readme to get help the coder know the purpose of the file but the rest should be found in the names of the Classes and Methods and just well broken out code.

Finally I used an IDE other than Coda. I am running Ubuntu now and just wanted to try and IDE that could do a ton more than Coda. Simple tools like Textmate or Sublime peak my interest as well but so far the IDE from these people was really good http://www.jetbrains.com/. I like how it had jshint built in, integration to git that was “better” than Coda. Sure the command line is great for git but there gui was not bad at times to have as well. It was not slow at all, my Core 2 Duo on an SSD never seemed slow.