Welcome

Christopher Grant is a Technology Leader in Columbus OH with and MBA and nearly 15 years experience focusing in the Internet and Architecture fields. Christopher is currently employed as a Sr. Architect for Gap Inc Direct. His work with businesses in a wide variety of industries and varying sizes demonstrates his adaptability and versatility. He is classified as INJT on the Myers-Briggs topology. Christopher combines his business background, leadership qualities and comprehensive knowledge of technology to provide organizations with successful long-term strategies and exacting tactical execution.

This blog provides a venue for discussing various topics from business, technology, and whatever else may arise. Please feel free to contact with any questions or comments.

The Profession of IT Architecture

The following presentation was given at the Columbus Architecture Group. It discusses some of the challenges we face understnading the role of architect and how architects fit into the IT organization.

Object Oriented Thinking for the Procedural Programmer

Moving from Procedural to Object Oriented thinking

In procedural programming we typically tell the system what to do in a line by line sequence of events. The data being used was globally available to enable various functions to act on it. Many developers today are using a mix of procedural and object oriented techniques. While they may be using an object oriented language and object oriented libraries or tools, the actual code tends to be rather procedural.

Many tutorials use "Hello World" as a sample application to teach. Interestingly most of these examples also use this mixed mode.

Look at a simple Java example

public static void main(){
   String Name = "Bob";
   System.out.println("Hello ");
   System.out.println(name);
}

In this demonstrates we happen to be using the "System" Object but this is really a simple top down procedural approach. So what is Object Oriented programming then. First let’s find out what an object is

What is an Object

You deal with objects every day in the real world. Your coffee mug is an object, your mouse is an object, heck you’re even an object. What does this have to do with programming? When we think in OO for our development we need to think in the same way we do in the real world, about objects. Lets take a few items from the real world and use them in OO programming. First look at your coffee mug. It has some data points or attributes about it such as color, capacity, temperature, available space etc. Some of those elements are fixed and shouldn’t be changed such as color and capacity. There are other attributes that can change such as available space.

Let look at a procedural example

public static void main(String args[]) {    String mugColor = "White";
   String mugCapacity = "14oz";
   String mugContents = "";
   String mugTempurature = "";
   String mugAvailableSpace = "";

   //Fill mug with coffee
   mugContents = "12oz Coffee";
   mugTemperature = "Hot";
   mugAvailableSpace = "0";

   // Check out our mug
   System.out.println("Mug Status: ");
   System.out.println("Mug Color: " + mugColor);
   System.out.println("Mug Capacity: " + mugCapacity);
   System.out.println("Mug Color: " + mugContents);
   System.out.println("Mug Color: " + mugTempurature);
   System.out.println("Mug Available Space: " + mugAvailableSpace);
}
 

 

Pretty straight forward. There are a few challenges though. How do you ensure I can’t put in more than the capacity. What’s to keep line of code from changing the temperature, color, or capacity. And finally  how do you deal with more than one mug. Yes you can code for a lot of these issues procedurally but the code gets complex and really you can’t enforce the rules you put in place since the objects are global.  Object Oriented programming allows you to do this.

In an OO model we would have a mug, or multiple mugs, each with its own current status. Once we got our mug, nothing would be able to change the color or capacity. While the temperature may change over time, this should be determined by the mug not some other code. For example I have a thermal mug which keeps my coffee hot for 2 hours. But I also have a regular ceramic mug that only keeps it warm for 20 minutes. The mug really determines how the temperature changes.

So lets make a mug

This mug and all objects really is just an isolated bit of code that can be reused. There are some rules for Objects but we won’t worry about them now.

public class Mug {

		// define the various attributes but don't set them
		   // Mark them private so they can't be updated by anyone but this mug
		   private String Color = "";
		   private String Capacity = "";
		   private String Contents = "";
		   private String Tempurature = "";
		   private String AvailableSpace = "";

		  // create an initialization function or constructor
		  // that will be used to setup some attribute data
		   public Mug(String _color, String _capacity) {
			   // take the input and store it in our attributes
			   Color = _color;
			   Capacity = _capacity;
			}

		  //enable the contents to be set
		  public void setContents(String _content){
		     Contents = _content;
		  }

		  // enable everyone to see what our attributes are
		   public String getColor(){
		     return Color;
		   }
		   public String getCapacity(){
		     return Capacity;
		   }
		   public String getContents(){
		     return Contents;
		   }
		   public String getTemperature(){
		     return Tempurature;
		   }

		   public String getAvailableSpace(){
		     return AvailableSpace;
		   }

		}

Now lets use it

public class Main {

	public static void main(String args[]) {
		Mug mug1 = new Mug("White", "140z");
		mug1.setContents("14oz Coffee");

		System.out.println(mug1.getColor());
		System.out.println(mug1.getCapacity());
		System.out.println(mug1.getTemperature());

	}
}

At first it appears we just added some structure to our code and split this into two files. If you look closer you’ll see that we can’t change the color or capacity after we get our mug.

Lets make this into a coffee shop and use lots of mugs.

public class Main {

	public static void main(String args[]) {
		Mug mug1 = new Mug("White", "14oz");
		mug1.setContents("14oz Coffee");

		Mug mug2 = new Mug("Silver", "8oz");
		mug1.setContents("8oz Tea")
		Mug mug3 = new Mug("Red", "6oz");
		mug1.setContents("6oz Chai")
		Mug mug4 = new Mug("Blue", "12oz");
		mug1.setContents("12oz Hot Chocolate")
		Mug mug5 = new Mug("Black", "10oz");
		mug1.setContents("10oz Milk")

		printMug(mug1);
		printMug(mug2);
		printMug(mug3);
		printMug(mug4);
		printMug(mug5);

	}

	private static void printMug(Mug mug) {
		System.out.println(mug.getColor());
		System.out.println(mug.getCapacity());
		System.out.println(mug.getTemperature());
	}
}

Not much extra code and lost of reuse. 

 

This has been a very brief intro to Object oriented programming. There is a lot more to OO, but taking these first steps will reduce the amount of code you need to write as well as increasing the quality of your application.

In future articles we’ll look at applying real OO techniques in in various languages.

Agile Code Reviews with Jupiter

Code reviews are a valuable part of any software development effort. Agile development processes provide the opportunity to integrate reviews closer to the actual development .

Jupiter

Jupiter is a plugin for the eclipse platform that enables developers to communicate over specific lines of code. The plugin comes with a suggested process for code reviews. The process suggests a three phase approach starting with inspecting the code and logging review items.  A quick demo of this process can be viewed here. When a section of code raises quality concerns, the reviewer notes the issue in Jupiter for later discussion. Once the initial review is completed, the process moves into the second phase which is to discuss the items that were identified. As each item is approved for rework it is updated and assigned to a developer. In the third phase, the developer works through the list of issues that were assigned to him. This process can be used in agile code reviews as well.

Agile

A quick review of the agile development cycle. Code is developed in time boxed chunks called sprints, or iterations. One or more iterations of code are sent to production at regular intervals. We’ll call this the release. For this discussion our release will contain two iterations. In each iteration a developer works multiple story cards to completion then hands it off for various sign-offs.

Agile Jupiter

To integrate code reviews into the process we need to add a step to the story card process. When a developer has completed work, he passes the code to a reviewer.

Individual Review

This reviewer picks up the standard code review process, discussed earlier, starting with the identification of quality concerns. When this individual review is complete the results are passed back to the developer for discussion.

Team Review

In this second phase, the developer walks through the list with the reviewer to understand what the concerns. The two discuss and agree on which items need to be corrected before the story can be signed off.

Rework

Once the list has been discussed and review items have been approved for rework, the developer moves into phase three, to rework the issues found.

Code Review Cleanup

Each code review will generate a series of files that are used by the Jupiter system. A file is created for each developer in each review. Given that a single iteration will contain multiple stories, the result is a handful of files that would need to be managed.

In each review there may be review concerns which will be deferred to a later point. To manage these concerns it is suggested that those issues be moved to a master list or logged as stories for future work.

It is suggested that these code review files be closed down and cleaned up before starting the next release. To close out the code reviews for a release, all outstanding review items should be moved to a consolidated location. What remains are Jupiter files with closed out review items. At this point all Jupiter files can be removed and the review process can be prepped for the next release.

This should be completed after cutting the release. This leaves all review files available to be included in version control system for use in future audits.

 

Adding a second set of eyes to a coding effort can not only improve code quality but also enhance knowledge transfer within a team. Integrating a code review process into your agile environment can enable those discussions and improve application quality.

Event: 12/8 – COJUG: SQL Tuning Tips for JAVA Developers

Topic 1 – What causes performance issues?
Topic 2 – Understanding Optimization
Topic 3 – What can a developer get from an Explain Tool?
Topic 4 – Top 25 performance tips for JAVA SQL developers
Topic 5 – Hibernate Performance Concerns

 

http://www.cojug.org/index.php?option=com_eventlist&Itemid=27&func=details&did=71