Better Carpools with Compossible Cars

Todays random thought is about how to make car pooling better.

The Trouble with Car Pools

This week I have to drive 60 miles to a client down in San Marcos. This is a long drive, I would appreciate both the gas advantages of a car pool, but also the time savings of being able to be productive while driving. However, to do this I need someone near by, who will drive to my house (or vice versa) then drive to my work, and then pick me up. This is a bunch of extra’s and lot’s of little things that if they go wrong will ruin my day. It’s just too much trouble.

 

but what if it didn’t have to be this way?

Image if our 2 cars could become 1, for a period, then split apart again. Then we could both drive to a common meet up, join up, ride together until we covered the common portion of our trip. spilt apart and not have to worry about getting stuck if one of us needs to stay late at work tonight.

Here’s a diagram of the idea:

The nice thing about this is not only do you get to share the burden of driving, but also gas mileage only goes up slightly with weight. From my short search, doubling your weight (2 cars) would only remove about 10% to your gas mileage. So a 34MPG Smart Car should get about 30 MPG combined with a second car.

Generic Type Information at Runtime in Java

I’ve been playing around with Hadoop lately, and it seems that this is a situation when the lack of runtime information about generics really hurts.

The bad news: java isn’t going to be changing that anytime soon.

The good news: you don’t need to wait for them to do it.

       Here’s how.

1. Define Useful Generic Base

The secret here is to add a method per generic type to expose it’s type. Here’s an example

public interface UsefulMap<In1, Out1>
{
  public Class<In1> getIn1Type();
  public Class<Out1> getOut1Type();
}

2. Implement

Now when you implement, you will have to provide the runtime information.

public class MyMap implements UsefulMap<Double, String>
{
  @Override
  public Class<Double> getIn1Type()
  {
    return Double.class;
  }
  @Override
  public Class<String> getOut1Type()
  {
    return String.class;
  }
}

The nice part is, if you forget or change it, it won’t compile.

  public Class<Double> getIn1Type()
  {
    return Integer.class; <- Type mismatch: cannot convert from 

                             Class<Integer> to Class<Double>
  }

Once you do this, there are a bunch of convenience functions you can write that will make your setup much easier & safer.

For example, you can now write

HadoopJob.Create()         

         .WithMapper(new MyMapper())

         .AndReducer(new MyReducer())

         .Start();

This (new) developers life

Today I discovered the podcast “This Developer’s Life”. It’s a very differently crafted podcast. Very true to the style of  "This American Life” that it’s name is borrowed from. It is more in a story telling venue, better production quality, not about API’s or even craftsmanship, but rather “common” themes to lives programmers.

I listened to Episode’s “Play” & “Problems”. They are nice, but it stirred in me an issue that first surfaced last year at Tech Ed South Africa, when I attended a presentation that presented this clip from the Movie “The social network” about being “wired in” and then stated this is the best way to be productive. I remembered nights or days with my headphones on, programming in the zone, but I could NOT remember the last time I actually programmed with headphones. I don’t work that way anymore.

“Play” also described this state, but mentioned that it was hard to get into with programming. They argued that racecars could instantly move you into it, but code was more haphazard about when you’d get into the zone.

“Problems” talked about what I consider to be the opposite effect;Bugs and the frustration and confusion they bring about. They also talked about the lack of satisfaction when the bug is finally found. Techniques to build up success, when to quit or undo.

The Old Me

I remember a time when this felt very familiar. In fact most of my younger years identified heavily with these anecdotes. I use to say “you have to love programming to be able to survive because bugs are so frustrating.” However, this whole thing was more of a nostalgic experience for me. In fact, I found myself shaking my head often, wanting to correct the process. For example, In the “Problems” episode, when they are talking about the bug introduced while programming in Sinatra, all I could think was “use Git Bisect”.

I’m not sure exactly when the changes started and I became proficient enough in my new skills and attained enough discipline that I stopped having these experiences. And I should note that they haven’t stopped completely, I still have relapses sometimes, but they are much much fewer and father apart.

But I do know why I have changed.

The New Me

Nowadays, I am almost constantly in the zone when I’m programming. I rarely fight with a bug for hours, and almost never if it’s an regression bug, in fact 10 minutes is a long time for a regression bug.

I am more disciplined than ever in my code, and part of that is focus, and part of that is small steps building up success.

I also am frequently in a state I would describe as “brain on fire” a state of hyper creativity that makes the old “in the zone” feel a bit stale.

The changes have come from from eXtreme programming. I started on this road almost a decade ago in 2002, and I have to search back to around that time to identify with the concepts and stories in the podcast.

There are many practices in eXtreme programming that contribute to the overall effect, and the combine upon each other to get the full result, but I want to highlight the most useful ones. I’ll do it in order of value for me personally.

Pair Programming

When they talk about the zone, pairing brings that almost instantly. I am amazed at how focused I can be when pairing with someone. Email, twitter, other people… it all fades into the background, and the code pops in front of you. Even if a interruption occurs it is quick & easy to regain that focus.

Learn more about pair programming, here & here.

Test Driven Development (TDD)

A clearly stated problem, constant feedback, and regression about twice every minute! TDD has removed the massive hell that bugs by breaking things into nice little steps, and catching you if you slip. Nowadays when something goes wrong I know about it 30 seconds later, and Ctrl+Z is usually the answer.

“The journey of a Million lines starts with a single Unit Test.”

Learn more about TDD here, here & watch a video demo here.

 

Incremental & Iterative Development

TDD sort of forces you to do small steps in a iterative fashion with constant feedback, but eXtreme programming doesn’t stop there. It uses this technique with user stories, refactoring, continuous integration, source control, retrospectives and many other practices. It’s extremely powerful. Do something small. No smaller. Now add some more.

How powerful is smaller? Let me show you an example from my own history

Books written – 0
Blog Posts – 25
Tweets - 2,621

Agile 2012 Development Practices & Craftsmanship stage

This is the original description we made as the producers for the Agile 2012 Development Practices Stage.


It didn't fit the needed format, so we couldn't use it, but it is what we have in our mind, and I thought it would be useful for speakers who are thinking of submitting to read.

You can submit here: http://submit2012.agilealliance.org/ 


Development Practices & Craftsmanship stage
"We have come to valueWorking Software"
This stage is about the code, and our goal is to have each attendee go away from each session having taken their game to a higher level.That's what real craftsmanship is all about - the desire to constantly improve.


We will accomplish this in 3 ways:

1. Core Practices: By having an explicit minimum set of "must have" topics  
2. Practice: we intend for Wednesday to be a code retreat day within the conference!  (more details to follow) 
3. Advanced: Agile2012 is also the premier place to share what we've learned as we've continued to improve over the last year

It should be stated that as our track is about code, we are looking for sessions with lots of code in them. Demo heavy rather than slide heavy.


Must-have
"You can't possibly have a stage for dev practices and craftsmanship and not cover ________ !" 
 That's what goes in this list for us.This stage must have an introductory session to these areas,
which we consider fundamental: TDD  - Refactoring  - Pairing  - CI  - BDD


Guidelines
Language: As these sessions are about code, one factor is which language will the demo's be given in. Please clearly state that in your submission.


No first-run sessions: Your session should be one that you've given at least once before. Even if that was just at an in-house event or for a small local group - that is ok.


Speaking skills: Help us to know what you are like as a speaker.Please include a link to a online video (preferably youtube) of you speaking at a user group or conference. This is extra helpful if you are linking to the talk you will be presenting at Agile2012, but any presentation will be helpful to us.


Training: The core goal for this stage is to transfer skill.Sessions should help people to improve their skills rather than just delivering a lecture.

Agile Open Northern California

What is Agile Open Northern California? 
[Register Here]
Agile Open NorCal is an annual, 2-day event hosted by the local agile community. Here managers, developers & students meet and discuss topics that they are interested in.
Past topics included

• Team self improvement
• Coding skills practice
• Kanban
• How to test
• Communication through drawings

Open spaces are optimized to help you learn what YOU need to, not what someone else wants you to hear.

Find out more about open spaces at here.

Who attends Agile Open Northern California?

Managers:
 There are many sessions about managing technical professionals. Agile helps to improve communication, prioritize work streams, and visibility into the team and unstick teams. Managers share their successes. Many times puzzles and games are used to help understand underlying behavioral issues.

Developers:
 There are usually hands on coding sessions to help developers practice and hone their craft. Agile development is strong on continual learning of best development practices. While Agile Open space is not language or API specific, many times the hands-on discussions are very specific to the problems you are having (For example: many times a dev will open up their legacy code challenge to solicit advice.)

Students:
 This is an excellent opportunity for students to find about ‘working in the real world.’  Also they can talk and code side-by-side with both technical managers and developers.  Agile Open is a great place to ‘try out’ ideas students have been learning in their classrooms.


Details:
Agile Open NorCal is hosted at Fort Mason Conference Center in San Francisco on

Monday, Oct. 3rd
Tuesday, Oct. 4rd

8:30 am to 5 pm.
It costs $250 to attend.  We hope to see you there.
Register Here

Open Agile SoCal 2011

What is Open Agile SoCal? 
[Register Here]
Open Agile SoCal is an annual, 2-day event hosted by the local agile community. Here managers, developers & students meet and discuss topics that they are interested in.
Past topics included

• Team self improvement
• Coding skills practice
• Kanban
• How to test
• Communication through drawings

Open spaces are optimized to help you learn what YOU need to, not what someone else wants you to hear.

Find out more about open spaces at here.

Who attends Open Agile SoCal?

Managers:
 There are many sessions about managing technical professionals. Agile helps to improve communication, prioritize work streams, and visibility into the team and unstick teams. Managers share their successes. Many times puzzles and games are used to help understand underlying behavioral issues.

Developers:
 There are usually hands on coding sessions to help developers practice and hone their craft. Agile development is strong on continual learning of best development practices. While Agile Open space is not language or API specific, many times the hands-on discussions are very specific to the problems you are having (For example: many times a dev will open up their legacy code challenge to solicit advice.)

Students:
 This is an excellent opportunity for students to find about ‘working in the real world.’  Also they can talk and code side-by-side with both technical managers and developers.  OpenAgile is a great place to ‘try out’ ideas students have been learning in their classrooms.
For students OpenAgile costs just $50 for the entire event.

Details:
OpenAgile SoCal is hosted at UCI at Donald Bren Hall (DBH) on

Thursday, Sept. 15th
Friday, Sept. 16th

8:30 am to 6 pm.
It costs $250 to attend.  We hope to see you there.
Register Here

Test-Driven Cameras

I am getting old.

The other day I was hanging around with my friend, Ike Ellis.  He told me a story about his kids.  His 3 young sons had been given disposable cameras as a gift.  These kids were actually confused by the idea of a camera that used film.  The first question they asked was

“Where is the picture?”
Ike explained that they had to look through the camera lens to see what the picture would look like.  They seemed ok with that, but the next question they asked was

“How do you know if you have taken a bad picture?”
Ike said “You won’t be able to know until after we get the film developed.” To which they replied,

“When will that be?” Still confused, they continued asking

“How do you delete the bad pictures?” 
 Ike said, “You can’t.”  At this point, the kids lost interest in the cameras.

However, because these cameras were gifts, the oldest decided to actually try out using the camera anyway.
The first thing he did was to take 6 pictures of the same thing.
Ike tried to explain that he shouldn’t do that, because the camera only had the ability to take a total of 32 (film) pictures.  After realizing that he could not experiment and would probably end up with a bad picture anyway, he set his camera next too the other two and walked away.

I wish people had this same reaction to the idea of writing code without first writing tests (TDD).

Tests give you the chance:

To see what you are going to write, BEFORE you write it.
To see if what you wrote actually worked.
To immediately get feedback.

To play (or experiment) with possible solutions.



If you haven’t already, here’s a great place to start learning to Test-Driven Development


If you are already writing tests, here’s a free library to make test even easier to write


Llewellyn Falco & Lynn Langit