2012 Geeky Goals

My “Geeky Goals” for 2012 are…

1. Learn iOS Development. I’ve had a chance to dabble in the past, but am itching to go deeper and build an app or two this year.
2. Teach my 6-year-old son the basic of electronic circuits…or rather, learn the basics of electronic circuits together. We picked up some Snap Circuits last year, and got another kit this Christmas. My son is showing an interest, and I’m happy to learn with him. I also have a breadboard, a bunch of circuits and an Arduino that we will eventually explore together.
3. Play more Skylanders.
4. Develop and implement a RPG-based approach to parenting. I was fortunate enough to get a copy of Geek Dad: Awesomely Geeky Projects and Activities for Dads and Kids to Share for Christmas, and stumbled across a chapter that suggested that parents create a role-playing game. I’ve already taken a stab at it, and my son and my girlfriend’s daughter are totally into it.
5. Pick some of the problems at Project Euler and solve them using ColdFusion, Java and other languages.

Here’s to a productive and fun 2012!

A Colossal Chart of Selenium Selectors

This wall chart does a fine job of detailing the various XPath, CSS and DOM selectors available when working with Selenium.

Grails Quick Tip: One-Click Application Start

In the search for the perfect, lightweight Grails IDE I’ve temporarily abandoned the feature-rich and bloated Eclipse variant SpringSource. One of SpringSource’s features that I like is the ability to associate a specific version of Grails with each project. Since my requirement is to run a specific application with a specific version of grails, I created this simple batch file to run ‘ApplicationX’ with Grails 1.3.7.

@echo off
SET GRAILS_HOME=C:\grails-1.3.7
SET PATH=%GRAILS_HOME%\bin;%PATH%
CD C:\ApplicationX
grails -Dgrails.env=local -Dgrails.gsp.enable.reload=true run-app
pause

Windows batch files FTW!

Quick Grails Logging Tip

My fun with Grails continues. Today I was having a bit of difficulty wrapping my head around the concept of dumping and logging. Dumping variables to the screen or to a log file is easy in ColdFusion thanks to the CFDUMP and CFLOG tags.

One way to dump variables in Grails is to output them to the console. After reading through this and asking a co-worker for assistance I still had to tinker a bit before I could get log.trace() statements from displaying in the console.

So as it turns out, I had to modify the log output level for an entity in Grails modify the log4j code block in your application’s Config.groovy file.

trace 'grails.app.controller.chapter4.SongController'

In this example “grails.app.controller” refers to ‘one or more controllers’ and ‘chapter4.SongController’ is the classpath and controller name. The code basically says ‘display all log messages at or above the trace level in SongController’. You can read more about logging levels here.

Here is a slight modification to the above code. This code allowed me to change the log settings for multiple controllers.

trace 'grails.app.controller.chapter4.SongController', 
'grails.app.controller.chapter4.AlbumController'

Note that you can apply the same log settings to all controller files…

Example C: trace 'grails.app.controller'

And for reference here is SongController.groovy…

package chapter4
class SongController {
 
	def index = {
		log.trace("I can see log.trace")
		log.warn("I can see log.warn")
		log.error("I can see log.error")
	}
}

OK, back to the code. I’m deep into Chapter 4 of The Definitive Guide to Grails.

Holy Grails, Batman

I’m fortunate enough to be working on three projects at the moment (I perform best when multitasking). One of these projects is ColdFusion-based (CF for life!), the second is rooted in Java and Selenium (test-driven development FTW) and the third project is written in Grails.

I chose the popular Eclipse-based IDE, SpringSource Tool Suite (STS). EClipse/CFEclipse is my preferred IDE for ColdFusion development, and I found the interface to be almost idenfical.

At present I’m bouncing back-and-forth between the book The Definitive Guide to Grails and Grails STS Integration and am really impressed with the language. In particular I like how controllers and unit tests are created in tandem. When creating a controller via the “grails create-controller” command both a controller class and a unit test are created.

I’ll be posting more about Grails in the coming weeks/months. 

Big thanks to long-time friend and fellow ColdFusion (and Grails) developer Mike Copeland for helping me to get my development environment set up and for sending me a good list of Grails developers to follow (Mike, please don’t ever delete that list!).

ColdFusion 10

Welcome to what may quite possibly be my laziest blog post ever…in which I mention the new version of ColdFusion in the title and simply state that “I’m seeing some juicy details on the new version of ColdFusion…head over to Nathan Struz‘s twitter feed now for more”. Enjoy.

Netflix, Quikster and The Missing Piece

Today Netflix announced that they would be splitting their streaming and DVD services into two companies. The streaming service will retain the name “Netflix” and the DVD service will get the new name “Quikster”. It’s also worth noting that Quikster will also offer video games.

One victim of this change is the current user ratings feature. Moving forward Netflix and Quikster ratings will not be shared across the two services. This data is being overlooked and could be the basis of an area of growth for both companies. Ratings and reviews are a driving force behind the success of websites like Amazon. Here’s my idea for how to leverage that data into something not entirely unique, but possibly revenue generating and fun…

Create a separate website called “Reviewster” (terrible name added for reference purposes only). Reviewster will contain a database of all movies (ala IMDB) and videogames. This ad-supported component is free for both members and non-members to use. Unreleased games and movies that are in theaters or pending theatrical release should also be added. Game and movie studios can also add trailers and other promotional crap to the relevant Reviewster entry for their game and movie…possibly in exchange for their games and movies being offered on Reviewster and Netflix (which is having problems getting content at the moment).

The second piece of Reviewster is personalization. Reviewster will also store each Quikster and Netflix user’s reviews and ratings. This allows users to access their ratings across all three services, as well as share them with Reviewster/Netflix/Quikster friends (via a simple, one-click “Recommend” button), the general public (via a “share my ratings and reviews with the public” user account setting) and to Twitter, Facebook, etc.

Reviewster will also act as a supplemental method for adding movies to each queue, as well as requesting that movies be added to each service. For example, each movie and game that is on Quikster will have an “Add to Quikster Queue” button. Movies and games that are not on Quikster will have an “I Want This On Quikster” button. Same thing for Netflix…add “Add to queue and “I want this on” buttons for that service as well. This will allow both services to anticipate demand for movies and games on a per-movie/per-game basis.

Other features like purchasing tickets and buying movies and games could easily be added to Reviewster. They could also partner up with respected movie and game reviewers in the industry to generate exclusive content.

If Reed Hastings and the folks at Netflix and Quikster do happen to stumble across and hopefully use this idea I hope that they do me the courtesy of a free lifetime membership to both services

Let’s Learn How To Write Code! Free Class This Sunday

This Sunday from 2pm-4pm I’m offering a free class (at my house) called “Lets Learn How To Write Code! Ruby On Rails”. This class is for folks are new to software development and have an interest in learning how to develop software. If you are that person, live near Brunswick Maryland, are free this Sunday from 2-4 and have a working laptop (that can run Flash and has WiFi) email me to reserve your spot.

christopher@christophervigliotti.com

Software Quality Improvement Plan

I’m pondering an approach to cleaning up an older Fusebox-based system that I’m presently working on. The goals are to encapsulate the logic, organize the code, strengthen the code base with a both functional and unit tests. Here is my rough sketch of a plan…it’s incomplete to say the least. I’m sure that I missed a bunch of stuff, so please do me the favor of scrutinizing this in the comments

Step One: Build and Deployment

The Plan: First we document the existing build and deployment processes. At this point we should develop a plan for improving and automating both, integrating the appropriate functional test and unit test solution. Implement said plan. At this point functional tests should be created by the development and test teams independently of the remaining steps. Lastly, a system for performing code reviews should be implemented.

The Risks: We choose the wrong solution. This risk can be mitigated by testing the solutions suite together and analyzing the results.

The Outcome: At this point we have a formalized build process in place. We can move the code between environments easier and can run functional and unit tests as a part of the build process as they are added to the test suites. We also have cross-team cooperation between the test and development teams, and are working together to build stronger software.

Step Two: Code Together

The Plan: Create a ColdFusion style guide. This document should be limited to six pages and should offer guidance as to how to write cleaner and easier to understand code. Each developer should be a part of this document.

The Risks: The suggestions of the document will be ignored. This risk can be mitigated by ensuring that the document is concise and human-readable.

The Outcome: At this point we have a consensus among the development team as to how to style our code.

Step Three: A Testable Data Access Layer

The Plan: Now it’s time to dive into the code. Encapsulate the logic found in qry_ includes, replacing queries with calls to the appropriate AreaOfConcernDAO.getThingYouAreGetting() method call. AreaOfConcernDAO.cfc instance is created in a persistent scope only if it does not exist. Also create unit tests for each method as they are created.

Replace this…

<cfquery name="qryGetStuff" datasource="request.dsn_name">
lots of sql here that isn't indented and is kinda messy
</cfquery>

…with this…

<cfscript>
if(! StructKeyExists(persistentScope, 'AreaOfConcernDAO'){
   persistentScope.AreaOfConcernDAO = Application.SingletonManager.getSingleton('AreaOfConcernDAO');
}
qryGetStuff = persistentScope.AreaOfConcernDAO.getStuff();
</cfscript>

…and this…

<cfcomponent name="AreaOfConcernDAO">
<cffunction name="getStuff" returntype="query">
...args...
...query...
...return...
</cffunction>
</cfcomponent>

The Risks: Changes to the code will break existing system functionality. This risk can be mitigated by (1) covering the code with unit and functional tests and (2) performing code reviews.

The Outcome: At this point we have a data access layer that is fully covered by unit tests.

Step Four: Controller and View Layers

The Plan: Rewrite fusebox controller logic and views one at a time. First scope all variables in the view in the request scope. Consider using request.viewContext (it’s tidier but more verbose). Move calls to act_ and qry_ includes from the fuseaction to an include found in /controller/areaOfConcern/fuseactionName.cfm. Perform tests on each action. Scope variables every time. Formalize said tests into functional tests. Also move views to /view/areaOfConcern/fuseactionName.cfm

Each fuseaction should look like this after it’s been rewritten.

<cfcase value="subdirectory.fuseactionName">
<cfinclude template="/controller/subdirectory/fuseactionName.cfm" />
<cfinclude template="/view/subdirectory/fuseactionName.cfm" />
</cfcase>

The Risks: Changes to the code will break existing system functionality. This risk can be mitigated by (1) covering the code with unit and functional tests and (2) performing code reviews.

The Outcome: At this point we have scoped variables in the view and model and the beginnings of model-view-controller separation.

Step Five: The Service Layer

The Plan: Analyze act_ includes to determine where they are being used. Move this logic to Service objects and create unit tests for each object/method. Variables that were not scoped in step 2 should be scoped now.

The Risks: Changes to the code will break existing system functionality. This risk can be mitigated by (1) covering the code with unit and functional tests and (2) performing code reviews.

The Outcome: At this point we have model-view-controller separation with a service layer!

Step Six: Close The Gaps

The Plan: Identify gaps in unit and functional tests and close them

The Risks: none

The Outcome: At this point we are awesome. So awesome in fact that we periodically check our code to verify that we have good coverage in our test cases, and are revisiting our build and deployment processes now and then to see if we can make further improvements. Since we have amazing coverage with functional tests we can refactor the code to improve it’s speed and organization. As new requirements are formalized we can write the test cases before we write the code.

Entity Drive

Imagine if you could define the relationships between entities in your data-driven system once, and then have them automatically link to both the database and to the display pages of your ColdFusion-based system. I’m exploring this concept now and am calling it “Entity Drive”.

The Point
The high-level goal here is to speed up the process of developing software. Every system that I’ve coded shares similar features. Entity Drive automates the process of some of those features…in particular getting data from the database, displaying it (either in list or tree forms) and presenting users with system interactions. I should also point out that the code is easy read, implement and modify.

Concepts

Entity Drive is similar to existing Object-relational mapping (ORM) solutions in that it links the database to system objects. Unlike ORM the code uses a structure in place of objects. I chose a structure or structures in place of objects as I want this to work as fast as possible. This structure is called the Entity Definition.

Each Entity Definition includes four basic pieces:

1. it’s name
2. how it relates to the database
3. how it relates to child entities
4. which (if any) links to create

From the Entity Definition you simply pass in ancestor and descendent entity names and generate an Entity Chain. An Entity Chain is a slice of the Entity Definition that only contains relevant segments of the Entity Definition. It is limited to definitions of the ancestor entity, the descendent entity and each entity between.

The Entity Chain serves two purposes. The first is to generate queries. The second is to generate views. Both are dynamically generated, which is a fancy way of saying that they are created when and where you need them.

Where I’m At

It works and it’s fast. I have the following features working:

• Entity Definition created from an XML file
• Entity Chain created from Entity Definition
• queries are dynamically generated
• a basic Tree View feature that outputs the query

What’s Next

1. refine Tree View feature to restore the tree’s expand/collapse state when a user returns to the page
2. highlight relevant tree node when user returns
3. refactor Entity Drive, Entity Chain and Entity DAO objects, adding lots and lots of comments
4. create unit tests and functional tests for all features
5. perform testing with a mega-huge data set
6. create an awesome List View page
7. documentation, documentation, documentation

In the coming weeks/months I’ll be posting updates and code samples. When it’s done I’ll share it.