UberConf 2010

Attending UberConf

This week I had the great opportunity to attend UberConf 2010 in Denver Colorado. This is primarily a JVM platform focused conference, but still has a variety of topics outside of the JVM such as iPad development, Agile, and Design Patterns. Also the conference has a good focus on alternative languages on the JVM such as Scala, Clojure, JRuby, and Jython.

The keynote speaker at the conference was Cliff Click, the chief JVM architect. He gave a great opening speech on concurrency in the JVM. I also really enjoyed attending several other talks presented by Cliff at UberConf.

I was very excited this week to have the opportunity to attend a Scala Workshop put on by Venkat Subramaniam whole wrote the book “Scala Programming“. I also had the opportunity to attend his “How to Approach Refactoring” talk which was also excellent.

I finished off the week by attending a talk put on by Stuart Halloway on the programming language Clojure. Stuart also authored the book “Programming Clojure“. It was a fun three hour introduction to a very interesting programming language. Stuart left us with a number of exercises and examples to work from to continue learning the language on our own. The language is a strange mental shift to make which is a good thing.

Working with XML in Scala: A Simple Example

While at UberConf I had the great opportunity to attend a talk titled “Scala for Java Programmers” put on by Venkat Subramaniam, the author of the book “Scala Programming” . During the talk we went into a number of examples of where Scala excels over Java, in that it makes life for the developer significantly easier. One of those areas is in working with XML. In Scala, XML is a first class citizen (Woohoo!).

So for those of you who have never used Scala before, here are a few simple examples of working with XML:

Create XML
In this example all we do here is take some xml and assign it to a val. Okay, so does not seem like anything special, but wait, notice the lack of quotes around the XML tags.

val xml = <car make="Ford">Galaxy</car>
println(xml)

prints the XML:

<car make="Ford">Galaxy</car>

Generate XML
In this example we take a Map and generate XML based on the values in that Map.

val cars = Map("Galaxy" -> "Ford", "Chevelle" -> "Chevrolet")

def createCar() = {
cars.map { entry =>
val (key, value) = entry
<car make={key}>{value}</car>
}
}

val xml = <cars>{createCar()}</cars>
println(xml)

prints the XML:

<cars>
<car make="Ford">Galaxy</car>
<car make="Chevrolet">Chevelle</car>
</cars>

Parse XML with Xpath

val xml = <car make="Ford">Galaxy</car>
val make = xml \\ "@make"
println(make)

prints out the Result: Ford

Parsing XML From A Service
Alright, now let’s actually do something useful. The following is a simple example used by Venkat during his scala session. In this example we access Yahoo’s weather feed and return the City, State, and current temperature for Denver, CO.

import scala.xml._
import java.net._
import scala.io.Source

val theUrl = "http://weather.yahooapis.com/forecastrss?w=2391279&u=f"

val xmlString = Source.fromURL(new URL(theUrl)).mkString
val xml = XML.loadString(xmlString)

val city = xml \\ "location" \\ "@city"
val state = xml \\ "location" \\ "@region"
val temperature = xml \\ "condition" \\ "@temp"

println(city + " " + state + " " + temperature)

Now, for fun, try writing this example in Java (Hmm, okay, that won’t be much fun at all).

To Run the examples

• Download Scala: http://www.scala-lang.org/downloads
• Add the Scala bin folder to your path
• Save the example to a file: example.scala
• Run the example: scala example.scala

Common AntiPatterns

While at UberConf 2010 I had the opportunity to attend a talk on AntiPatterns put on by Mark Richards. There are many AntiPatterns that exist in the software world, but Mark decided for this talk to focus on seven that he considers to be the most common. The following is a quick summary of Mark’s talk.

What are Patterns?

A pattern is a repeatable process that produces positive results each time. The main reason patterns were developed were to help improve communication between developers. Design patterns allow developers to use a common language to convey complex design ideas in just a few words.

What are AntiPatterns?

AntiPatterns are things we repeatedly do that produce negative results. The example Mark used was Gambling. Even though repeating this process produces negative results, we still do it again and again.

Factors that cause Anti-Patterns

1. Haste – When project deadlines are tight, budgets are cut, team sizes are reduced, in these pressure situations we tend to ignore good practices.
2. Apathy – Developers who really don’t care about the problem or the solution will almost always produce a poor design.
3. Ignorance – When a developer either lacks knowledge of the domain or of the technology being used, that ignorance will result in antipatterns being introduced.

Seven Common AntiPatterns

There are many, many antipatterns in software design, but these are some of the most common.

1. Cargo Cult Programming

Using design patterns, techniques, or new technologies before really understanding them. Often as developers we jump into new technologies because they are interesting and we want to use them so we try to fit it in somehow, whether or not it is necessary for our project. This can lead to introducing a new technology or pattern when it is not needed and add unnecessary complexity.
Avoid it:

• Don’t introduce a new technology unless it is absolutely necessary.
• When you see some code you aren’t sure of, take the time to read and understand it.
• Take the time to read and understand a technology you are currently using or considering using.

2. Lava Flow

An old area of the code is never updated or touched because everyone on the project is scared to touch it. Often this occurs because none of the original developers who wrote the code still work at the company. Some signs of lava flow are when you have large blocks of code commented out (“Why was this commented out, was it needed?”) and also when there is dead code still hanging around in the code base.
Avoid it:

• Remove the commented out code.
• TDD with meaningful regression tests.
• Use tools to find dead code.
• Use interfaces to isolate the mess and also help locate dead code. If no path through the interface uses it, then it is safe to remove the code.

3. Parallel Protectionism

Code becomes so complicated and fragile that developers start copying the code and making changes to the copy rather than extending the original code out of a fear of breaking some existing functionality. Problems with this antipattern are that not only does it introduce duplicate code to the product, but now if a bug is found we now have two places to apply the fix instead of just one.
Avoid it:

• Look for duplicate code at all levels.
• Split up complicated areas of the code into smaller chunks.
• Avoid creating complicated tricky code that developers will be afraid of. Focus on readability over clever tricky code.

4. Accidental Complexity

Introducing unnecessary complexity to a project out of ego by trying to out do other developers by accomplishing the same task in less lines of code (“Wow, look at this amazing piece of code I wrote!”). This can also happen by accident when a system is built one method at a time without any real overall plan.
Avoid it:

• Focus on simple designs.
• Write readable code instead of “tricky code”.
• Frequent code reviews, or better yet, pair programming!

5. Object Orgy

An objects private values should never be exposed for modification unnecessarily. This is usually caused by poor encapsulation. For example: generating setters for every property in an object is NOT encapsulation. By always generating setters you are creating an object where it’s state can be invalidated at any time. The state of an object should be initialized by a constructor. Object Oriented programming is about object state, not getters and setters.
Avoid it:

• Use proper encapsulation.

6. The Blob

A class or package in your system that does far too much. The catch all for any code where the developer is not sure where to put it, or is just too lazy to create a new class or package. Also what can happen is developers will put code somewhere else simply because it is smaller and easier to work with, even if it is not the correct location. This antipattern is usually caused by a lack of proper object oriented design skills on a team.
Avoid it:

• Code reviews or pair programming.
• If you can’t describe a classes functionality with a single sentence, then it has too much responsibility.

7. Golden Hammer (Most Common)

Using the same technology or technique to solve every problem. For example: “I like Perl, Perl is the best language ever, it is perfect for any problem”.
Avoid it:

• Be familiar with many programming languages, technologies, tools, and know each of their strengths and weaknesses.
• Set your personal preferences aside and always pick the best tool/technique for each problem you are trying to solve.

Prairie Dev Con 2010!

Chris from P2 Presenting at PRDC10

This last week I had the great opportunity to attend Prairie Dev Con 2010 in Regina. This is the first time a good sized software conference has been organized here in the prairies. I travelled to Regina with some co-workers and really enjoyed the experience. I was extremely impressed at how well organized the conference was, as well as the number of talks lined up (50 talks over 2 days).

Since this was the first time a big software conference had been hosted in Saskatchewan, the organizer, who works primarily with Microsoft technologies, used many of his contacts from within that community to put together a good list of speakers. Now that the conference has been run once and had a good attendance, the hope is for next years conference that we can attract speakers on a more wide range of technologies such as as Python, Django, Scala, and document style databases such as MongoDB.

Since Point2 has been doing a lot of interesting work with new technologies, I hope for next year we will be able to put on a number of talks to offer a more well rounded list of topics for next year.

Overall, I was really impressed with PRDC10 and I am looking forward to seeing it happen again next year!

University of Saskatchewan Programming Contest

Marcos and I attended the University of Saskatchewan Programming Contest where local students were competing for prizes and the chance to attend the Regional Programming Contest at the U of S on Oct 30, 2009.

The contest had eight coding problems to solve. To win you just needed to correctly solve the most questions. However, in the event of a tie the team who solved the problems in the shortest amount of time wins. The questions ranged from very simple to extremmely difficult. If you are interested in seeing some sample questions (Or would like to test yourself!) you can check the U of S Programming Contest sample page.

Students competing in the contest ranged from novice to advanced, however there is also an opportunity for anyone who wants to, to form a team and compete for fun! (count us in for next year). The contest is not just about writing code, but more about focusing on problem solving where you prove your solution with a small program. Of course the competitors who are able to solve each problem with small simple applications definitely have an advantage.

While at the programming contest we had the chance to meet the co-ordinator of the programming contest, professor Christopher Dutchyn. He gave us an overview of the contest, how scoring was handled, and walked us through some of the problems teams were attempting to solve. During our discussion, Marcos chanllenged the winners of the U of S contest to a programming contest with Point2 employees.

During our weekly professional development time we plan to put together a team to practice similar problems to the ones solved in the programming contest. We hope to prepare ourselves for a fun challenge. We know the competition will be tough, but we hope to give students a fun practice session before they go on to another competition. We hope to set something up some time over the next few months.

At the end of the contest Point2 presented some prizes to winners and also we told the students a little bit about Point2. We hope to see many of those students applying for positions offered through the U of S Internship Program for next spring.

After having a chance to spend a day on campus it sure makes me miss my time their as a student. The faculty and staff were great hosts.

First Day at SD WEST 08 – Overview

It is impressive the number of people from big name companies that are not just giving talks but that make up the list of attendees. From reading attendees’ conference tags the company names I saw most often were Google, Yahoo, Boeing, IBM, Microsoft, Nortel Networks, and Sun Microsystems just to name a few. It was unusual to see a company name I didn’t recognize.

Each talk we attended today provided a wealth of excellent information. The following is a very brief overview of the talks.

To Catch a Bug You Have to Think Like a Bug

This talk was given by a developer from Google who previously worked for years on the JBuilder IDE tool. He gave a talk on how to trap bugs in code and surround them with targeted meaningful tests. This was more a tutorial than a lecture so he had us all fire up Eclipse and write test cases in JUnit to test methods in his example application. Much of the session was on not just writing tests, but figuring out what tests need to be in place to cover a method, but the catch was to do it in the least amount of tests possible. It was interesting, at the start of the session we were all coming up with much higher numbers of test cases, such as 8 to test a method, when he was able to show us how to get basically the same coverage in just 2 tests. It was a very helpful exercise. The end of the talk focused on refactoring existing code for testability.

Several books that came highly recommended were:

Code Quality – Diomidis Spinellis

Code Complete – by Steve McConnell

Is Agile Working for You

The lunch time keynote address was by Scott Ambler who is the Agile Practice Leader for IBM. His talk focused on issues with putting into place Agile development practices. The part of his talk I really enjoyed was about database testing. He mentioned how it is so common for the focus in unit testing to focus so heavily on application code, that the development of test cases that test the database without the application present are often ignored such as tests to test stored procedures, triggers, etc. He also stressed the value of writing a suite of database data integrity tests that can be run on a regular basis to check existing production data for problems.

Patterns of Refactoring

This talk was given by Joshua Kerievsky who is the author of the book with the same name. It was a live coding demo where he took us step by step though each of his refactoring patterns. Also he showed us many simple tactics he uses for doing refactoring in small simple steps to reduce the risk of making refactoring changes. Some of his refactoring patterns such as Gradual Cutover, Parallel Change, Inline Refactoring, and Narrowed Change I have used in the past, however the valuable part of this task was really in seeing the steps to implementing each of these patterns in a safe way. As he stressed the number one mistake made in refactoring is in trying to change too much too fast. Spreading it out in a series of steps is much safer and also an easier sell as it allows new development to be done in parallel with refactoring work.

For all of the live coding demos the presenter used Eclipse with both Java and C++ code samples. However, he did talk briefly about C# and highly recommended ReSharper.

 

Beautiful Code

The keynote address in the evening was a Q & A session with 6 of the authors of the “Beautiful Code” book. They discussed the basics of what makes beautiful code (Readability, Consistency, Simplicity, etc.) Later on they got into a discussion about languages themselves that they considered beautiful. Python was the main topic of the conversation.

That’s just a very brief overview of the talks, barely scratches the surface. It was an interesting first day.

SD WEST – Monday Morning

We are all signed up and ready to go. Mark and I went through registration this morning and are now at our first talk “To Catch a Bug You Have to Think Like a Bug”. This afternoon Mark and I will be headed to separate talks, I am taking in “Patterns of Refactoring” while Mark will be attending “Fundamentals of Defensive Programming”. This evening I am really excited because the Keynote address “Beautiful Code” will include Michael Feathers (I just finished reading his book on refactoring book called “Working with Legacy Code”).

For Tuesday I decided at the last minute to change the talk I will be attending. The word on the street is that of all the talks this week, the talk to make sure you don’t miss is the “Better Software – No Matter What”>Better Software – No Matter What”. Other conference attendees and presenters all say it is THE talk to be at.

Yahoo

My SD West Schedule

I think one of the hardest parts about attending a conference such as this one, is trying to decide which talks to attend. There are some time slots where I was torn between two or even three talks, but I can’t attend them all, so here is my list:

Monday

To Catch a bug, You Have to Think Like a Bug – Robert Evans

Patterns of Refactoring – Joshua Kerievsky (or Test Driven Developement – Rob Meyers)

Beautiful Code -Keynote address – Michael Feathers, Elliotte Rusty Harold, Alberto Savoia, Chris Seiwald

Tuesday

Dealing with NonFunctional Requirements as the Hero, not the Witch – Andre Gous

Practical Advanced Threat Modeling – John Steven

Wednesday

Clean Code: Ruby – Robert C. Martin

Behaviour-Driven Database Design – Scott Ambler

Paradox of Choice: Design Principles for Goal-Oriented Data-Driven System – Todd Zaki Warfel

Prefactoring – Ken Pugh (Or What Makes a Design Seem Intuitive – Jared Spool)

Thursday

Pattern Connections -Kevlin Henney

Design Patterns in the Real World – Allen Holub

The Business Value of Pair Programming – Rob Meyers

The Science of a Great UI – Mark Miller

Friday

GUI Bloopers: Avoiding Common UI Design Mistakes – Jeff Johnson

Emergent Design: Design Patterns and Test Driven Development – Allen Shalloway (Or Scaling Habits of ASP.NET)

Dances with Robots – Keynote – James McLurkin of MIT

Polyglot and Poly-Paradigm Programming – Dean Wampler (This talk looks very interesting…)

Data Controls in ASP.NET 3.5 – Paul Sheriff

This will be a lot of fun!

SD WEST 2008

I will be heading to Santa Clara next week to attend the SD WEST 2008 conference. I am really excited about this trip. Just take a look at the list of presenters, the odds are you have  probably already read books by several of these presenters (I know I have!). The sessions I am primarily planning to attend are in the Design & Modeling, Refactoring, and TDD tracks. It should be a great week!