One of the best ways for making sense of a space is to have a lens for looking at it.  The productivity and results space are well-traversed and the body of knowledge is enormous.  That’s part of the problem.  Without an effective lens, it can be difficult to find, organize, and share the productivity strategies, tactics, etc.

Knowledge Areas
You can think of a “frame” or a “lens” as a set of knowledge areas that make it easier to learn a space.  Together, the knowledge areas form a constellation of knowledge.  For example, the PMBOK (Project Management Body of Knowledge) and SWEBOK (Software Engineering Body of Knowledge) use knowledge areas to cluster related topics, concepts, tasks, and terms to help share the information more effectively.  It’s a way to frame out the space.

Productivity Body of Knowledge
While working on Getting Results the Agile Way, one of the first things I needed to do was carve out the space into meaningful buckets.   By “framing out” the results and productivity space, I created a more effective lens to look at productivity.   This is how I created a “Productivity Body of Knowledge".   I named the collection of knowledge areas for productivity and results, the Results Frame.  Giving it a name and putting it into a simple table, made it easier to refer to and to share as a mental model with others.

The Results Frame (Productivity Knowledge Areas) 
Here is the Results Frame:

Hot Spot Description Action How you take action and manage your activities towards results. Efficiency and Effectiveness How you manage the cost and speed of your results, as well as how you manage the quality of your results. Energy Management How you manage your energy in terms of thinking, feeling, and doing, as well as how you take care of your eating, sleeping, and working out. Expectations How you set and reset expectations with yourself and others. Focus How you focus your time, energy, and attention. Goals and Objectives How you set meaningful goals and objectives for your results. Information Management How you organize and manage information, as well as avoid information overload. Learning How you find the lessons, improve, and correct course. Mindsets and Motivation How you get your head in the game. Planning How you map out the work to be done. Pioritizing How you choose what’s more important. Self-Awareness How to improve your knowledge about yourself in terms of achieving results. Self-Discipline How you correct your behavior. Task Management How you manage your tasks and action items. Time Management How you manage and schedule your time.

The key with these knowledge areas is that they are can contain insight and action.  They are great containers or buckets for productivity principles, patterns, and practices.  To create the buckets, I first gathered up all the “rocks” (the individual principles, patterns, practices, terms, concepts, etc.) , then I group the collections, and then I labeled the buckets.  This is the opposite of making up buckets and then looking to fill them.  I was more interested in creating buckets for proven practices and applied knowledge, rather than treating productivity as an abstract or academic exercise.

Not only did the Results Frame help with organizing my own body of knowledge for results and productivity, but it made it incredibly simple for me to very quickly parse just about any body of knowledge or significant work in the productivity space.  This frame also helped me quickly pressure test productivity systems against a more holistic view, as well as to find their more specific strengths and weaknesses.  Interestingly, you can also use the categories to help evaluate project management approaches and software development approaches.  The frame is useful whether you use it to organize your own knowledge base on productivity, or you use it for teams, or organization.  Don’t just take my word for it though … test drive it and you decide what works for you … you’re the ultimate expert on your context and scenario.

My former colleague Greg Gigon has written an interesting blog post where he talks about the pain that we cause ourselves by multi-tasking, a point which Kevin Fox also makes on the Theory of Constraints blog.

I think the overall point that he makes is very true:

We can switch our attention quickly from one task to another. But … is it good for our brain? Is it good for the work we are doing? Are we really more productive?

I've often found that when I try and switch between multiple different tasks I end up finishing none of them and it's certainly true that twitter, facebook and emails can be amazingly distracting.

Hopefully those types of distractions are less of an issue when working on a software development team, particularly if the team are pair programming.

Project influenced context switching

While I agree with Greg that it's good to try and make sure that we're only working on one task at a time, I think that to an extent there is always going to be some context switching involved if we have a group of people working together.

Greg touches on this briefly in his post:

When we are in a despair and need answers we are not worrying about anyone else. The goal is to ask or tell to achieve whatever we are after. We are not taking into consideration that we might be disturbing someone else Flow.

To me it seems that focusing on the flow of an individual individual/pair is a bit of a local optimisation when we're talking about software teams.

For example if a pair are working on a piece of functionality orthogonal to what another pair are working on then should they interrupt that pair if they need to talk about something?

Interrupting them possible would break their 'flow' but it might give one or both pairs an insight into the problem which they wouldn't have otherwise had.

From my experience pairs interrupting each other often helps reduce the amount of time that we spend building the wrong thing.

An alternative way to still gain this knowledge without interrupting people straight away would be to delay the conversation until a later time but perhaps the best moment for gaining that knowledge has now gone?

Counter productive context switching

The only time when interrupting a pair does seem counter productive is if you're doing so to ask a question whose answer could easily be found out with a quick bit of Googling.

In that case I completely agree with Greg that we should first think about the impact our interruption will have on our colleagues.

Overall

The topic of flow/context switching is an interesting one but I think we need to be careful about having it as our main goal on software delivery teams.

I wrote about pair flow a while ago where I described some ways to achieve more 'flow' within a pair but my current line of thinking is that we'll still have some interruption between pairs and that's not necessarily a bad thing.

An approach to ponder…

Mike Wagg once suggested that pairs should work in 25 minute pomodoros and only be interruptible when they're on a break from one.

This seems like an interesting idea but communication would end up being much more structured/time boxed/weird?!

One of the most common discussions that I have with my colleagues is around designing bits of code in the simplest way possible.

I've never quite been able to put my finger on exactly what makes a design simple and there is frequently disagreement about what is even considered simple.

On the last project I worked on we had an interesting problem where we wanted to partially update different parts of an object from different pages of the application.

We had access to the id of the object from the URL so my initial thought was that when we submitted each page we could load the full object from the database and update it with the values that had just been submitted from that page.

The problem with that solution was that it meant we needed to make another database call without any real benefit from doing so.

We had already created objects representing the data submitted from these pages so Christian suggested that an alternative approach would be to create NHibernate mappings for those objects instead so that we could just map the updated values straight to the database.

We had bit of duplication in our objects as we had one object representing every bit of data the user had provided so far and then two smaller objects just representing the data provided for each of the pages.

public class TheObject
{
	public string Page1Property { get; set; }
	public string Page2Property { get; set; }
}

public class PartialObject1
{
	public string Page1Property { get; set; }
}

public class PartialObject2
{
	public string Page2Property { get; set; }
}

We then created NHibernate mappings for each of those objects:

public class TheObjectMapping : ClassMap<TheObject>
{
	Map(x => x.Page1Property);
	Map(x => x.Page2Property);
}

public class PartialObject1Mapping : ClassMap<PartialObject1>
{
	Map(x => x.Page1Property);

public class PartialObject2Mapping : ClassMap<PartialObject2>
{
	Map(x => x.Page2Property);

When loading the object from the database onto the page we used 'TheObject' and its associated mappings and when updating the object from the individual pages we could use the partial object mappings.

I think this was quite a neat approach as it allowed us to reduce the complexity of our controller code when updating an object as well as removing the need for one trip to the database.

The trade off was that we ended up writing more mapping code but that seemed to be a reasonable trade off to make.

Don’t worry, this post isn’t about the ongoing political problems that Belgium has been suffering from for the past 3 years. It’s about something far more interesting (ahem): the way they read my blog. I was going over the blog’s stats for last month:

As you can see, the numbers for the Belgians are far different than they are for each other country in that list. The number of pages they read each visit is way above the average. The average time they spend on this site is also much higher than most countries. And the percentage of new visitors and the bounce rate is a lot lower than what we see from other countries. That means that almost 4 out of 5 Belgians that visit this site have been here before, and keeping the total number of visits in mind and the fact that it has a much smaller population than the other countries in the top 7, they seem to keep coming back as well. And this isn’t just an anomaly because the all-time stats for this blog show pretty much the same picture:

So that makes me wonder: what’s up with these Belgians? And yes, i know that some of you are probably thinking: “well duh, it’s because you’re Belgian too!”. But there are a couple of reasons why i don’t think that me being from Belgium explains it:

• The Google Analytics plugin that i’m using does not count my own visits
• I do very, very little networking so it’s not like i’m often in contact with a lot of Belgian developers to plug my blog
• I don’t go to developer events to evangelize my ideas, in fact, i generally don’t go to developer events
• I don’t give talks or presentations, except for one that i did on NHibernate a year ago. And i don’t see myself doing a lot of talks in the future either since i have no idea what i’d talk about.

So, it can’t be because i’ve been pushing this blog among the Belgian developers. So what is it then? Is it because we Belgians are generally quite thorough when it comes to learning about stuff we like? Or are we just lazy and do we love to waste a lot of time online? Both are true to some degree . Either way, it’s nice to see Belgium among the top of a list (even if it doesn’t mean shit) that isn’t related to female tennis, chocolate, beer, organized crime or fraud.

Seriously though, i do find this kind of stuff interesting so if you are Belgian (or are familiar with how Belgians are) and have some ideas on why those numbers are so different from other countries, please do share

These are some of the best ways I’ve found to master time management, get great results, improve your productivity, and amplify your impact:

1. Monthly Improvement Sprints. Use Monthly improvement sprints to cycle through things that you want to focus on. For example, focus on getting in shape in January; use February to learn a new skill. By using a month’s chunk of time, you give yourself enough of a timebox to achieve meaningful results. By using monthly themes, you give yourself a chance to cycle through a variety of your key interests and goals.
2. Balance your time across your Hot Spots. Balance your results across your meaningful buckets. For me, I use a life frame: mind, body, emotion, career, financial, relationships and fun. Each Hot Spot can be broken down into more Hot Spots. For example, my career bucket includes execution, thinking, administration, improvement and relationships.
3. Build a library of reference examples. Collect working examples to learn and model from. Actively looking for the positive examples of successful people around you helps keep your mind focused on success patterns. If you want to manage your time better, model from somebody who is effective. If you want to mange projects better, find somebody with a proven track record and learn from them. Keep in mind that what works for them, may not work for you, but there is no need to start from scratch.
4. Diversify your results. Think in terms of a portfolio of results. This means both producing results in different categories (such as relationships, career, and fun) as well as having some results you count on and some that are risks. Balance this with quitting when you aren’t going to get good at something, or you aren’t getting the return on investment. Diversify your results to avoid having all your eggs in one basket. For example, at work, you might have your flagship project that you can count on, but then add a couple of experimental projects to test the waters.
5. Establish a rhythm of results. Don't let the tail wag the dog. Factor when you create from when you release. This frees you up to focus on creation, without the immediate burden of production or release. Your release rate should match absorption rate and demand. Your production and release can occur at different times and at varying rates. For instance, you could write your eight blog posts on Sunday, then trickle them out over the week.
6. Find a way to flow value. Chunk your results down. Deliver incremental value to yourself or to others. Focus on value-delivered, not backlog burndown. Don't settle for being productive but ineffective. Focus on delivering value keeps you asking the right questions and making the right calls on priorities. Remember that backlogs tend to suffer from rot over time. If you focus on value delivered you won't miss windows of opportunity when they do appear. The other secret here is that focusing on value can be more energizing than tackling an overwhelming backlog, even if all you really changed is perspective.
7. Improve your network. Who you spend time with probably has the largest impact on getting results, personal growth, your quality of life, your career, etc. Here’s a tip: build a mind map of your personal and professional networks and see where you need to tune, prune, or grow. Your purpose is your guide, whether it’s seeing others’ perspectives to keep creative juices flowing, connecting with others you can model and learn from, or simply providing you with the support you need.
8. Make it a project. If you want to get something significant done, make it a project. This includes anything that takes several stages to complete or something that you know probably won’t get done otherwise. List the work to be done and estimate how long it will take.Allocate enough time, energy, and resources to accomplish the work and establish a timeline. Dedicate time to your project and see it through. It’s a simple but proven practice for achieving results. By giving something a start and an end, and by getting your head around the work, you dramatically improve your chances for success. By packaging up the work as a project, you can also look at it in terms of investment and ROI (return on investment). If you don’t think it will be worth the investment, you can make that call. Making it a project provides a lens you can both evaluate the opportunity and manage the work more effectively.
9. Stay flexible in your approach. Be flexible in the "how." If you have a compelling "what" and "why," you'll find the strategies. If something's not working, change your approach. A good sanity check is to ask yourself, "Is it effective?”
10. Sweeping. Periodically sweep up the mess you’ve left behind. Sometimes it’s easier to go back and clean things up than to try and get things right up front. It can be more efficient to batch and focus your time at a later point, than to try and keep things in order the whole time through. Consider sweeping as a deliberate strategy to maximize your energy by batching the work at a specific point in time. Sweeping as a practice gives you a chance to go back and improve things as well as integrate new learnings.

For more patterns and practices for improving results, see my book, Getting Results the Agile Way.

Creating a DSL seems like a hard thing to do, right? While there are various interesting challenges that you’ll need to deal with if you want to build and use a real DSL, the initial step of getting it working is actually a lot easier than you might think it is. I’m gonna walk you through the creation of a simple DSL, suitable for a domain that all of us have experience with. The domain is quite simple: describing entities, their properties and their relationships. Forget for a second that you could obviously get the exact same information from a set of class definitions. It’s merely a technical exercise using a domain that we all know

One of the key questions that we need to ask ourselves is: what kind of concepts do we want to be able to describe with our DSL? In our case, we want to describe a model consisting of entities. Disregarding behavior for now, we can say that each entity will consist of properties. Properties could be regular properties, references to other Entities, or collections of other entities. Here’s one way (of many, obviously) to model that in Ruby (since that language makes it very easy to define a DSL):

require 'forwardable'

class Model
  extend Forwardable

  def initialize
    @entities = []
  end

  def add_entity(entity)
    @entities << entity
  end

  def entity_for(name)
    @entities.detect { |entity| entity.name == name }
  end

  def_delegator :@entities, :each, :each_entity
end

class Entity
  extend Forwardable

  attr_reader :name

  def initialize(name)
    @name = name
    @collections = []
    @properties = []
    @references = []
  end

  def add_collection(collection)
    @collections << collection
  end

  def add_property(property)
    @properties << property
  end

  def add_reference(reference)
    @references << reference
  end

  def identifier
    @properties.detect { |property| property.is_identifier? }
  end

  def_delegator :@collections, :each, :each_collection
  def_delegator :@properties, :each, :each_property
  def_delegator :@references, :each, :each_reference
end

class Property
  attr_reader :name
  attr_reader :required
  attr_reader :type

  def self.new_identifier(name, type)
    self.new(name, type, false, true)
  end

  def initialize(name, type, required=false, is_identifier=false)
    @name = name
    @type = type
    @required = required
    @is_identifier = is_identifier
  end

  def is_identifier?
    @is_identifier
  end
end

class Reference
  attr_reader :name
  attr_reader :entity
  attr_reader :is_required

  def initialize(name, entity, is_required)
    @name = name
    @entity = entity
    @is_required = is_required
  end
end

class Reference
  attr_reader :name
  attr_reader :entity
  attr_reader :is_required

  def initialize(name, entity, is_required)
    @name = name
    @entity = entity
    @is_required = is_required
  end
end

class Collection
  attr_reader :name
  attr_reader :entity

  def initialize(name, entity)
    @name = name
    @entity = entity
  end
end

That gives us a simple, yet complete object model to describe entities, their properties and their relationships. The next question is: how do we define the DSL? Considering an Invoice entity, suppose we’d like to describe it in our DSL like this:

entity "Invoice"
identified_by "Id", :guid
must_reference "Customer"
must_have "Date", :date
can_have "Discount", :double
contains "Lines", "InvoiceLine"

This really tells us anything we need to know about this entity, and we could use this data for pretty much everything we want. There is no explicit or implicit link to any specific kind of technology, like say, a relational database, a document database, or some kind of databinding technology. We could transform or extend this data to suit whichever purpose we deem fit.

So now that we know how we want to describe our entities and their relationships, we can implement the language. As mentioned in the title of this post, this is the implementation of a simple DSL. It’s just to illustrate an idea, and not an approach that is guaranteed to stand up to the real-world requirements that a DSL could face (and that depends on a case by case basis). So in this case, we’re going to go with an implementation where each entity is described in its own file, and its filename must end with ‘_def.rb’. With that limitation in mind, we can do this:

require_relative 'application.rb'
require_relative 'entity.rb'
require_relative 'collection.rb'
require_relative 'property.rb'
require_relative 'reference.rb'

@model = Model.new

def entity(name)
  entity = Entity.new(name)
  @model.add_entity entity
  @current_entity = entity
end

def identified_by(name, type)
  @current_entity.add_property Property.new_identifier(name, type)
end

def must_have(name, type)
  has name, type, true
end

def can_have(name, type)
  has name, type, false
end

def must_reference(entity_name, name=nil)
  references entity_name, true, name
end

def can_reference(entity_name, name=nil)
  references entity_name, false, name
end

def contains(name, entity_name)
  referred_entity = @model.entity_for entity_name
  @current_entity.add_collection Collection.new(name, referred_entity)
end

def has(name, type, required=false)
  @current_entity.add_property Property.new(name, type, required)
end

def references(entity_name, is_required=false, name=nil)
  referred_entity = @model.entity_for entity_name
  name = entity_name if name.nil?
  @current_entity.add_reference Reference.new(name, entity_name, is_required)
end

Dir.glob('*_def.rb').each do |file|
  @current_entity = nil
  load file
end

@model.each_entity do |entity|
  puts entity.name
  print_name = Proc.new { |item| puts "\t\t#{item.name}"}
  puts "\t has the following properties:"
  entity.each_property &print_name
  puts "\t has the following references:"
  entity.each_reference &print_name
  puts "\t has the following collections:"
  entity.each_collection &print_name
end

As you can see, we have ‘global’ method definitions (they’re actually implicitly added to the Object class) which correspond with our language ‘keywords’. Those method implementations use the model that we defined earlier to build a nice object graph based on what we describe through our DSL.

You’ll notice that after the method definitions, you can see the following code:

Dir.glob('*_def.rb').each do |file|
  @current_entity = nil
  load file
end

And that’s the clue to this simple DSL: it loops through each file that matches the ‘*_def.rb’ pattern, sets an instance variable named @current_entity (implicitly added to the current Object instance in this case) to nil, and then loads the current file in the loop. The load method (it might look like a keyword, but it’s a method) executes the ruby code in the given file in place, meaning that it shares the same scope. In other words, the methods that we’ve defined here are accessible to our DSL declarations since those are executed within the same scope. And since those method implementations manipulate our domain model, we just built a simple ‘language’ to describe our entities, their properties and their relations.

Suppose we’ve got the following entity definitions (each would be in a separate file, but they are just listed all at once here):

entity "Customer"
identified_by "Id", :guid
must_have "Name", :string
can_have "Email", :string

entity "Product"
identified_by "Id", :guid
must_have "Name", :string
must_have "Price", :integer

entity "InvoiceLine"
identified_by "Id", :guid
must_reference "Product"
must_have "Count", :integer

entity "Invoice"
identified_by "Id", :guid
must_reference "Customer"
must_have "Date", :date
can_have "Discount", :double
contains "Lines", "InvoiceLine"

This describes a very small domain model consisting of 4 entities. In the code listed above, you may have noticed the following piece at the end:

@model.each_entity do |entity|
  puts entity.name
  print_name = Proc.new { |item| puts "\t\t#{item.name}"}
  puts "\t has the following properties:"
  entity.each_property &print_name
  puts "\t has the following references:"
  entity.each_reference &print_name
  puts "\t has the following collections:"
  entity.each_collection &print_name
end

Given the 4 described entities, running the code above results in the following output:

Customer
	 has the following properties:
		Id
		Name
		Email
	 has the following references:
	 has the following collections:
Invoice
	 has the following properties:
		Id
		Date
		Discount
	 has the following references:
		Customer
	 has the following collections:
		Lines
InvoiceLine
	 has the following properties:
		Id
		Count
	 has the following references:
		Product
	 has the following collections:
Product
	 has the following properties:
		Id
		Name
		Price
	 has the following references:
	 has the following collections:

So there you have it, we described our entities, their properties and their relationships in a very simple manner and those descriptions were interpreted and the data has been put into an object model that we can use for a variety of purposes if we wanted to. And there really are a lot of interesting things we can do with this, especially when keeping IronRuby in mind

var sidebarElement = new google.elements.sidewiki.SidebarElement(window.location.href,true);sidebarElement.bindToElement("sidewiki-open-ui-button");

We are very pleased to announce a new Sidewiki “sidebar” web element. Google Sidewiki allows visitors to your website to contribute helpful information and read other visitors’ insights alongside the pages of the website. The new web element is a Sidewiki button, which, when clicked, displays a fully functional Sidewiki sidebar to the left of the page content. This means that your visitors can see the Sidewiki content for your page even if they don’t have Google Toolbar or the Sidewiki Chrome extension installed.

You can choose from several different look and feels created by Google or even create a new custom one. Use our wizard to choose the desired look and behavior, embed the generated code in your page, and you’re done. Here's a sketch of what it looks like when a visitor is looking at the Sidewiki content.

Go to http://www.google.com/webelements/sidewiki/ to get started. If you'll be using the element on your site, we’d love to hear about it via @googlesidewiki on Twitter.

By Roman Shuvaev, Sidewiki Team

(Cross-posted from Google Analytics Blog)

On the Google Analytics API Team, we’re fascinated with what people create using the Data Export API. You guys come up with some really amazing stuff! Lately, we’ve also been paying a lot of attention to how people use it. We looked at whether the API has stumbling points (and where they are), what common features every developer wants in their GA applications, and what tricky areas need deeper explanations than we can give by replying to posts in our discussion group.

As a result of identifying these areas, we’ve written a few in-depth articles. Each article is meant as a “Deep Dive” into a specific topic, and is paired with open-source, sample reference code.

In no particular order, the articles are as follows:

Visualizing Google Analytics Data with Google Chart Tools
This article describes how you can use JavaScript to pull data from the Export API to dynamically create and embed chart images in a web page. To do this, it shows you how to use the Data Export API and Google Chart Tools to create visualizations of your Google Analytics Data.

Outputting Data from the Data Export API to CSV Format
If you use Google Analytics, chances are that your data eventually makes its way into a spreadsheet. This article shows you how to automate all the manual work by printing data from the Data Export API in CSV, the most ubiquitous file format for table data.

Filling in Missing Values In Date Requests
If you want to request data displayed over a time series, you will find that there might be missing dates in your series requests. When requesting multiple dimensions, the Data Export API only returns entries for dates that have collected data. This can lead to missing dates in a time series, but this article describes how to fill in these missing dates.

We think this article format makes for a perfect jumping off point. Download the code, follow along in the article, and when you’re done absorbing the material, treat the code as a starting point and hack away to see what you can come up with!

And if you’ve got some more ideas for areas you’d like us to expound upon, let us know!

By Alexander Lucas, Google Analytics API Team

I spent a good time last night troubleshooting a “works on my machine” problem.

It takes pain to learn something, this pain perhaps was good.  It reminded me of a concept that is really important in your software development infrastructure.

I have three golden rules of development environments and deployment:

1. I should be able to run a build locally that is the exact same build that will be run on the continuous integration server.
2. Only bits that were built by the continuous integration server are deployed and the same bits are deployed to each environment.
3. Differences in configuration in environments only exist in one place and on that machine.

You don’t have to follow these rules, but if you don’t, most likely you will experience some pain at some point.

If you are building a new deployment system, or you are revamping an old one, keeping these 3 rules in mind can save you a large amount of headache down the road.

I think it is worth talking about each rule and why I think it is important.

Rule 1: Local Build = Build Server Build

If you want your continuous integration environment to be successful, it needs to appropriately report failures and successes.

If your build server reports failures that are false, no one will believe the build server and you will be troubleshooting problems that are build configuration related instead of actual software problems.  Troubleshooting these kinds of problems provides absolutely no business value.  It is just a time sink.

If you report false successes, when you deploy the code to another environment, you will discover the issue, and will be wasting time deploying broken code, and you will have a long feedback loop for fixing it.

As a developer, I should be able to run the exact same command the build server will run when I check in my code.  I would even recommend setting up a local version of the continuous integration server your company is using.

By being able to be confident that a build will not fail on the build server or during deployment if it doesn’t fail when running it locally, you will prevent yourself from ever troubleshooting a false build failure.  (The deployment still could fail, and the application could still exhibit different behavior on different environments, but at least you will know that you are building the exact same bits using the exact same process.)

Rule 2: Build Server Bits = Only Deployed Bits

Build it once, and deploy those bits everywhere.  Why?

Because it is a waste of time to build what should be the exact same bits more than once.

Because the only way to be sure the exact same code gets deployed to each environment (dev, test, staging, production, etc.), is to make sure that the exact same bits are deployed in each environment.

The exact same SVN number is not good enough, because an application is more than source code.  You can build the exact same source code on two different machines and get a totally different application.  No, I’m not loony.  This is a true statement.  Different libraries on a machine could produce different binaries.  A different compiler could produce different binaries.

Don’t take a risk.  If you want to be sure that code you tested in QA will work in production exactly the same way, make sure it is the exact same code.

This means you can’t package your configuration with the deployment package.  Yes, I know you always have done it that way.  Yes, I know it is painful to figure out another way, but the time it will save you by never having to question the bits of a deployment ever again will be worth it.

Rule 3: Environment Configuration Resides in Environment

Obeying this rule will save you a huge amount of grief. 

Think about it.

If the only thing different in each environment is in one place, in one file in that environment, how easy will it be to tell what is different?

I know there are a lot of fancy schemes for adding configuration to the deployment package based on what environment the deployment is going to.  I have written at least 3 of those systems myself.

But, they always fail somewhere down the line and you spend hours tracing through them to figure out what went wrong and ask yourself “how the heck did this work again?”

By making the configuration for an environment live in the environment and in one place, you take the responsibility of managing the configuration away from the build process and put it in one known place.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

We are now ready to share the Google Developer Day agendas for Tokyo, Sao Paulo, Munich, Moscow and Prague. We have so much technical content to share but alas, Developer Day is a one-day event. There may still be changes to the agenda, but here is a sneak peek at where we are.

Globally, we will feature three major tracks:

• Android - With the continued momentum and growth of the platform, we would like to continue the conversation with you at Developer Day. We will feature sessions on Android performance, mobile user experience and best practices on building apps, and we will also deep dive on a new feature, Cloud to Device Messaging (C2DM).


• Chrome & HTML5 - We will discuss how to build an app for the Chrome Web Store and how to improve its development and performance. We’ll show which aspects of HTML5, Chrome Developer Tools and Native Client can be most useful to you. Finally, we will cover everything auth-related to show you when and where to use various authentication tools and how they integrate with our APIs and products.


• Cloud Platform - Building off of our series of announcements at Google I/O, we will feature sessions on App Engine, App Engine for Business, Spring integration, Google Web Toolkit, Google Storage for Developers, BigQuery and Prediction API. Be prepared for code samples, how to optimize performance and a glimpse into what else is on our roadmap.

We are happy to announce that Eric Tholome, Product Management Director for Developer Products, will be a keynote speaker in Sao Paulo, Munich, Moscow and Prague. In addition, we are happy to invite as our second keynote speaker:

• Sao Paulo, Brazil - Mario Queiroz, VP Product Management


• Munich, Germany - Dr. Wieland Holfelder, Engineering Director


• Moscow, Russia - Dr. Gene Sokolov, Head of Moscow Engineering

Due to the success of the Venture Capital sessions at Google I/O and the growing VC activity in our global markets, a new addition this year is Venture Capital panels at most of our Developer Days. Come hear from your local VCs on what they look for in startups.

The Sao Paulo and Moscow keynote presentations will have live translation, and for sessions, check the FAQ section of your Developer Day site. We will have savvy gurus available to answer your questions during Office Hours, and you will have a chance to meet Googlers and each other over Happy Hour.

Registration will open on September 15th for Sao Paulo and on September 22nd for Munich, Moscow and Prague. Tokyo’s registration is now closed.
In the meanwhile, please follow us on this blog and on Twitter to keep up-to-date with the latest news on Google Developer Day and other development topics: @googledevjp (Japan), @googledevbr (Brazil) and @gddru (Russia).
Hashtags: #gdd2010jp, #gddbr, #gddde, #gddru, #gddcz

By Susan Taing, Google Developer Team

This is a guest post by Owen Barton, partner and director of engineering at CivicActions. Owen has been working with Google's “Make the Web Faster” project team and the Drupal community to make improvements in Drupal 7 front-end performance. This is a condensed version of a more in-depth post over at the CivicActions blog.

Drupal is a popular free and open source publishing platform, powering high profile sites such as The White House, The New York Observer and Amnesty International. The Drupal community has long understood the importance of good front-end performance to successful web sites, being ahead of the game in many ways. This post highlights some of the improvements developed for the upcoming Drupal 7 release, several of which can save an additional second or more of page load times.

Drupal 7 has made its caching system more easily pluggable - to allow for easier memcache integration, for example. It has also enabled caching HTTP headers to be set so that logged out users can cache entire pages locally as well as improve compatibility with reverse proxies and content distribution networks (CDNs). There is also a patch waiting which reduces both the response size and the time taken to generate 404 responses for inlined page assets. Depending on the type of 404 (CSS have a larger effect than images, for example) the slower 404s were adding 0.5 to 1 second to the calling page load times.

Drupal currently has the ability to aggregate multiple CSS and JavaScript files by concatenating them into a smaller number of files to reduce the number of HTTP requests. There is a patch in the queue for Drupal 7 that could allow aggregation to be enabled by default, which is great because the large number of individual files can add anything from 0-1.5 seconds to page loads.

One issue that has become apparent with the Drupal 6 aggregation system is that users can end up downloading aggregate files that include a large amount of duplicate code. On one page the aggregate may contain files a, b and c, whilst on a second page the aggregate may contain files a, b and d - the “c” and “d” files being added conditionally on specific pages. This breaks the benefits of browser caching and slows down subsequent page loads. Benchmarking on core alone shows that avoiding duplicate aggregates can save over a second across 5 page loads. A patch has already been committed that means files need to be explicitly added to the aggregate, and fix Drupal core to add appropriate files to the aggregate unconditionally.

Drupal has supported gzip compression of HTML output for a long time, however for CSS and JavaScript, the files are delivered directly by the webserver, so Drupal has less control. There are webserver based compressors such as Apache’s mod_deflate, but these are not always available. A patch is in the queue that stores compressed versions of aggregated files on write and uses rewrite and header directives in .htaccess that allow these files to be served correctly. Benchmarks show that this patch can make initial page views 20-60% faster, saving anything from 0.3 to 3 seconds total.

The Drupal 7 release promises some real improvements from a front-end performance point of view. Other performance optimizations will no doubt continue to appear and be refined in contributed modules and themes, as well as in site building best practices and documentation. In Drupal 8 we will hopefully see further improvements in the CSS/JS file aggregation system, increased high-level caching effectiveness and hopefully more tools to help site builders reduce file sizes. If you have yet to try Drupal, download it now and give it a try and tell us in the comments if your site performance improves!

By Owen Barton of CivicActions

Just a heads up that it should now be easier for users to find SVG files when searching on Google. That’s right, we’ve expanded our indexing capabilities to include SVG. Feel free to check out our Webmaster Help Center for the complete list of file types we support, and our Webmaster Blog for more information on our SVG announcement.

By Maile Ohye, Google Developer Relations

[This post is by Dan Morrill, Open Source & Compatibility Program Manager. — Tim Bray]

Way back in November 2007 when Google announced Android, Andy Rubin said “We hope thousands of different phones will be powered by Android.” But now, Android’s growing beyond phones to new kinds of devices. (For instance, you might have read about the new 7” Galaxy Tab that our partners at Samsung just announced.) So, I wanted to point out a few interesting new gadgets that are coming soon running the latest versions of Android, 2.1 and 2.2.

For starters, the first Android-based non-phone handheld devices will be shipping over the next few months. Some people call these Mobile Internet Devices or Personal Media Players — MIDs or PMPs. Except for the phone part, PMP/MID devices look and work just like smartphones, but if your app really does require phone hardware to work correctly, you can follow some simple steps to make sure your app only appears on phones.

Next up are tablets. Besides the Samsung Galaxy Tab I mentioned, the Dell Streak is now on sale, which has a 5” screen and blurs the line between a phone and a tablet. Of course, Android has supported screens of any size since version 1.6, but these are the first large-screen devices to actually ship with Android Market. A tablet’s biggest quirk, of course, is its larger screen.

It’s pretty rare that we see problems with existing apps running on large-screen devices, but at the same time many apps would benefit from making better use of the additional screen space. For instance, an email app might be improved by changing its UI from a list-oriented layout to a two-pane view. Fortunately, Android and the SDK make it easy to support multiple screen sizes in your app, so you can read up on our documentation and make sure your app makes the best use of the extra space on large screens.

Speaking of screen quirks, we’re also seeing the first devices whose natural screen orientation is landscape. For instance, Motorola’s CHARM and FLIPOUT phones have screens which are wider than they are tall, when used in the natural orientation. The majority of apps won’t even notice the difference, but if your app uses sensors like accelerometer or compass, you might need to double-check your code.

Now, the devices I’ve mentioned so far still have the same hardware that Android phones have, like compass and accelerometer sensors, cameras, and so on. However, there are also devices coming that will omit some of this hardware. For instance, you’ve probably heard of Google TV, which will get Android Market in 2011. Since Google TV is, you know, a stationary object, it won’t have a compass and accelerometer. It also won’t have a standard camera, since we decided there wasn’t a big audience for pictures of the dust bunnies behind your TV.

Fortunately, you can use our built-in tools to handle these cases and control which devices your app appears to in Android Market. Android lets you provide versions of your UI optimized for various screen configurations, and each device will pick the one that runs best. Meanwhile, Android Market will make sure your apps only appear to devices that can run them, by matching those features you list as required (via tags) only with devices that have those features.

Android started on phones, but we’re growing to fit new kinds of devices. Now your Android app can run on almost anything, and the potential size of your audience is growing fast. But to fully unlock this additional reach, you should double-check your app and tweak it if you need to, so that it puts its best foot forward. Watch this blog over the next few weeks, as we post a series of detailed “tips and tricks” articles on how to get the most out of the new gadgets.

It’s official folks: we’re living in the future! Happy coding.

In Agile, everyone agrees on the concept that continuous improvement is a good thing. In Scrum and also in most Kanban practices we even have a ceremony to support this, namely The Retrospective. This periodically occurring meeting (often every other week) with the entire team plays a vital part in the process and in team [...]

One of the most common anti-patterns I've seen in waterfall projects is the "90% done syndrome". It goes like this: the project will get quite quickly to 90% readiness and will look to be on time until that point. However, after the 90% readiness point is achieved we start to see more and more delays and blast through deadlines like there was no tomorrow.

Why is that? I've spent some time thinking about this question. With Agile projects we avoid this syndrome quite effectively by managing the scope. In practice we avoid the "90% syndrome" by declining to work on the content that would delay the project but not add enough value to justify that delay. But, then some time ago the question came back to me. Why is it that in waterfall projects we have the "90% syndrome"?

The answer to that question just hit me today (a real "d'oh" moment): the reason is that we don't really know about all of the requirements until we are well into the implementation (say 70-90% into it). Therefore we will only really understand the full content of the project when we are close to the end. This, coupled with the fact that waterfall projects tend to be organized architecturally/horizontally (instead of feature/vertical sliced) leads to knowing about critical requirements too late(90% ready for a long time) and not being able to remove content (because we release the lower layers before the upper layers) to meet the schedule.

This anti-pattern is quite simple, but apparently it takes time to understand the forces at play, and most managers (including project managers) constantly miss this point...

Photo credit: striatic @ flickr

Over the years I have seen many configuration files. Most of them were unusable. There are many reasons for unusable configuration files. What I’ve learned from looking at large configurations are those main points: 1. Values Often configuration files use the wrong values. Developers tend to use true/false for switching options on and off. track-users = true The [...]

[This post is by Trevor Johns, who's a Developer Programs Engineer working on Android. — Tim Bray]

The Android Market licensing service is a powerful tool for protecting your applications against unauthorized use. The License Verification Library (LVL) is a key component. A determined attacker who’s willing to disassemble and reassemble code can eventually hack around the service; but application developers can make the hackers’ task immensely more difficult, to the point where it may simply not be worth their time.

Out of the box, the LVL protects against casual piracy; users who try to copy APKs directly from one device to another without purchasing the application. Here are some techniques to make things hard, even for technically skilled attackers who attempt to decompile your application and remove or disable LVL-related code.

• You can obfuscate your application to make it difficult to reverse-engineer.

• You can modify the licensing library itself to make it difficult to apply common cracking techniques.

• You can make your application tamper-resistant.

• You can offload license validation to a trusted server.

This can and should be done differently by each app developer. A guiding principle in the design of the licensing service is that attackers must be forced to crack each application individually, and unfortunately no client-side code can be made 100% secure. As a result, we depend on developers introducing additional complexity and heterogeneity into the license check code — something which requires human ingenuity and and a detailed knowledge of the application the license library is being integrated into.

Technique: Code Obfuscation

The first line of defense in your application should be code obfuscation. Code obfuscation will not protect against automated attacks, and it doesn’t alter the flow of your program. However, it does make it more difficult for attackers to write the initial attack for an application, by removing symbols that would quickly reveal the original structure of a compiled application. As such, we strongly recommend using code obfuscation in all LVL installations.

To understand what an obfuscator does, consider the build process for your application: Your application is compiled and converted into .dex files and packaged in an APK for distribution on devices. The bytecode contains references to the original code — packages, classes, methods, and fields all retain their original (human readable) names in the compiled code. Attackers use this information to help reverse-engineer your program, and ultimately disable the license check.

Obfuscators replace these names with short, machine generated alternatives. Rather than seeing a call to dontAllow(), an attacker would see a call to a(). This makes it more difficult to intuit the purpose of these functions without access to the original source code.

There are a number of commercial and open-source obfuscators available for Java that will work with Android. We have had good experience with ProGuard, but we encourage you to explore a range of obfuscators to find the solution that works best for you.

We will be publishing a separate article soon that provides detailed advice on working with ProGuard. Until then, please refer to the ProGuard documentation.

Technique: Modifying the license library

The second line of defense against attack from crackers is to modify the license verification library in such a way that it’s difficult for an attacker to modify the disassembled code and get a positive license check as result.

This actually provides protection against two different types of attack: it protects against attackers trying to crack your application, but it also prevents attacks designed to target other applications (or even the stock LVL distribution itself) from being easily ported over to your application. The goal should be to both increase the complexity of your application’s bytecode and make your application’s LVL implementation unique.

When modifying the license library, there are three areas that you will want to focus on:

• The core licensing library logic.

• The entry/exit points of the licensing library.

• How your application invokes the licensing library and handles the license response.

In the case of the core licensing library, you’ll primarily want to focus on two classes which comprise the core of the LVL logic: LicenseChecker and LicenseValidator.

Quite simply, your goal is to modify these two classes as much as possible, in any way possible, while still retaining the original function of the application. Here are some ideas to get you started, but you’re encouraged to be creative:

• Replace switch statements with if statements.

• Use XOR or hash functions to derive new values for any constants used and check for those instead.

• Remove unused code. For instance, if you’re sure you won’t need swappable policies, remove the Policy interface and implement the policy verification inline with the rest of LicenseValidator.

• Move the entirety of the LVL into your own application’s package.

• Spawn additional threads to handle different parts of license validation.

• Replace functions with inline code where possible.

For example, consider the following function from LicenseValidator:

public void verify(PublicKey publicKey, int responseCode, String signedData, String signature) {
    // ... Response validation code omitted for brevity ...
    switch (responseCode) {
        // In Java bytecode, LICENSED will be converted to the constant 0x0
        case LICENSED:
        case LICENSED_OLD_KEY:
            LicenseResponse limiterResponse = mDeviceLimiter.isDeviceAllowed(userId);
            handleResponse(limiterResponse, data);
            break;
        // NOT_LICENSED will be converted to the constant 0x1
        case NOT_LICENSED:
            handleResponse(LicenseResponse.NOT_LICENSED, data);
            break;
        // ... Extra response codes also removed for brevity ...
    }

In this example, an attacker might try to swap the code belonging to the LICENSED and NOT_LICENSED cases, so that an unlicensed user will be treated as licensed. The integer values for LICENSED (0x0) and NOT_LICENSED (0x1) will be known to an attacker by studying the LVL source, so even obfuscation makes it very easy to locate where this check is performed in your application’s bytecode.

To make this more difficult, consider the following modification:

public void verify(PublicKey publicKey, int responseCode, String signedData, String signature) {
       // ... Response validation code omitted for brevity …
        
        // Compute a derivative version of the response code
        // Ideally, this should be placed as far from the responseCode switch as possible,
        // to prevent attackers from noticing the call to the CRC32 library, which would be
        // a strong hint as to what we're done here. If you can add additional transformations
        // elsewhere in before this value is used, that's even better.
        java.util.zip.CRC32 crc32 = new java.util.zip.CRC32();
        crc32.update(responseCode);
        int transformedResponseCode = crc32.getValue();

        // ... put unrelated application code here ...
        // crc32(LICENSED) == 3523407757
        if (transformedResponse == 3523407757) {
            LicenseResponse limiterResponse = mDeviceLimiter.isDeviceAllowed(userId);
            handleResponse(limiterResponse, data);
        }
        // ... put unrelated application code here ...
        // crc32(LICENSED_OLD_KEY) == 1007455905
        if (transformedResponseCode == 1007455905) {
            LicenseResponse limiterResponse = mDeviceLimiter.isDeviceAllowed(userId);
            handleResponse(limiterResponse, data);
        }
        // ... put unrelated application code here ...
        // crc32(NOT_LICENSED) == 2768625435
        if (transformedResponseCode == 2768625435):
            userIsntLicensed();
        }
    }

In this example, we’ve added additional code to transform the license response code into a different value. We’ve also removed the switch block, allowing us to inject unrelated application code between the three license response checks. (Remember: The goal is to make your application’s LVL implementation unique. Do not copy the code above verbatim — come up with your own approach.)

For the entry/exit points, be aware that attackers may try to write a counterfeit version of the LVL that implements the same public interface, then try to swap out the relevant classes in your application. To prevent this, consider adding additional arguments to the LicenseChecker constructor, as well as allow() and dontAllow() in the LicenseCheckerCallback. For example, you could pass in a nonce (a unique value) to LicenseChecker that must also be present when calling allow().

Note: Renaming allow() and dontAllow() won’t make a difference, assuming that you’re using an obfuscator. The obfuscator will automatically rename these functions for you.

Be aware that attackers might try and attack the calls in your application to the LVL. For example, if you display a dialogue on license failure with an “Exit” button, consider what would happen if an attacker were to comment out the line of code that displayed that window. If the user never pushes the “Exit” button in the dialog (which is no not being displayed) will your application still terminate? To prevent this, consider invoking a different Activity to handle informing a user that their license is invalid, and immediately terminating the original Activity; add additional finish() statements to other parts of your code that get will get executed in case the original one gets disabled; or set a timer that will cause your application to be terminated after a timeout. It’s also a good idea to defer the license check until your application has been running a few minutes, since attackers will be expecting the license check to occur during your application’s launch.

Finally, be aware that certain methods cannot be obfuscated, even when using a tool such as ProGuard. As a key example, onCreate() cannot be renamed, since it needs to remain callable by the Android system. Avoid putting license check code in these methods, since attackers will be looking for the LVL there.

Technique: Make your application tamper-resistant

In order for an attacker to remove the LVL from your code, they have to modify your code. Unless done precisely, this can be detected by your code. There are a few approaches you can use here.

The most obvious mechanism is to use a lightweight hash function, such as CRC32, and build a hash of your application’s code. You can then compare this checksum with a known good value. You can find the path of your application’s files by calling context.GetApplicationInfo() — just be sure not to compute a checksum of the file that contains your checksum! (Consider storing this information on a third-party server.)

A simpler, and perhaps less obvious approach, is to simply check how your application was installed. If you know that your application will only be distributed through Android Market, you can verify that Android Market is listed as the installer for the application:

PackageManager pm = context.getPackageManager();
String installer = pm.GetInstallerPackageName(getApplicationInfo().packageName);

if (!"com.google.android.feedback".equals(installer)) {
    // Application was installed via other means than Android Market.
    // Assuming there are no other distribution channels, this APK has probably been
    // tampered with.
}

Consider using obfuscation techniques so that the installer package name never actually appears in your compiled source. For example, you can use the crc32() trick mentioned earlier, compute a md5(), or even use ROT13.

-->

[In a late edit, we removed a suggestion that you use a check that relies on GetInstallerPackageName when our of our senior engineers pointed out that this is undocumented, unsupported, and only happens to work by accident. –Tim]

Also, you can check to see if your application is debuggable. If your application tries to keep itself from performing normally if the debug flag is set, it may be harder for an attacker to compromise:

boolean isDebuggable =  ( 0 != ( getApplcationInfo().flags &= ApplicationInfo.FLAG_DEBUGGABLE ) );

Technique: Offload license validation to a trusted server

If your application has an online component, a very powerful technique to prevent piracy is to send a copy of the license server response, contained inside the ResponseData class, along with its signature, to your online server. Your server can then verify that the user is licensed, and if not refuse to serve any online content.

Since the license response is cryptographically signed, your server can check to make sure that the license response hasn’t been tampered with by using the public RSA key stored in the Android Market publisher console.

When performing the server-side validation, you will want to check all of the following:

• That the response signature is valid.

• That the license service returned a LICENSED response.

• That the package name and version code match the correct application.

• That the license response has not expired (check the VT license response extra).

• You should also log the userId field to ensure that a cracked application isn’t replaying a license response from another licensed user. (This would be visible by an abnormally high number of license checks coming from a single userId.)

To see how to properly verify a license response, look at LicenseValidator.verify().

As long as the license check is entirely handled within server-code (and your server itself is secure), it’s worth nothing that even an expert cracker cannot circumvent this mechanism. This is because your server is a trusted computing environment.

Remember that any code running on a computer under the user’s control (including their Android device) is untrusted. If you choose to inform the user that the server-side license validation has failed, this must only be done in an advisory capacity. You must still make sure that your server refuses to serve any content to an unlicensed user.

Conclusion

In summary, remember that your goal as an application developer is to make your application’s LVL implementation unique, difficult to trace when decompiled, and resistant to any changes that might be introduced. Realize that this might involve modifying your code in ways that seem counter-intuitive from a traditional software engineering viewpoint, such as removing functions and hiding license check routines inside unrelated code.

For added protection, consider moving the license check to a trusted server, where attackers will be unable to modify the license check code. While it’s impossible to write 100% secure validation code on client devices, this is attainable on a machine under your control.

And above all else, be creative. You have the advantage in that you have access to a fully annotated copy of your source code — attackers will be working with uncommented bytecode. Use this to your advantage.

Remember that, assuming you’ve followed the guidelines here, attackers will need to crack each new version of your application. Add new features and release often, and consider modifying your LVL implementation with each release to create additional work for attackers.

And above all else, listen to your users and keep them happy. The best defense against piracy isn’t technical, it’s emotional.

patterns & practices Parallel Programming with Microsoft .NET is now available.  The book shows design patterns to help developers use the .NET 4 Task Parallel Library (TPL) to write parallel applications successfully.

Contents at a Glance

• Authors and Disclaimers
• Foreword
• Preface
• Acknowledgments
• Introduction
• Parallel Loops
• Parallel Tasks
• Parallel Aggregation
• Futures
• Dynamic Task Parallelism
• Pipelines
• Appendix A: Adapting Object-Oriented Patterns
• Appendix B: Debugging and Profiling Parallel Applications
• Appendix C: Technology Overview
• Glossary
• References

The Patterns
The book describes six key parallel patterns for data and task parallelism and how to implement them using the TPL.

The Book

• Free in HTML -  Parallel Programming with .NET (MSDN)
• Print / EBook -  Parallel Programming with .NET (O’Reilly)

The Code Samples

• Parallel Programming Code Samples (CodePlex)

The Talk

• Patterns of Parallel Programming (TechEd)

The Community

• Parallel Programming with .NET Community KB (CodePlex)

One thing that i see a lot, and that i have largely started to avoid, is that people fetch entities with NHibernate, only to transform them to DTO’s so you can send them back to the client so they can be displayed in a a grid or some kind of list or whatever. This is usually pretty easy to do, especially if you already have a DTO mapper or are using something like Automapper. But this comes with a bit of overhead (both performance and memory) that you can often avoid quite easily.

Suppose i have a screen where i need to display entries based on the following DTO class:

    public class AuthorizationDto
    {
        public long Id { get; set; }
        public Guid ApplicationId { get; set; }
        public string ApplicationName { get; set; }
        public Guid? UserGroupId { get; set; }
        public string UserGroupName { get; set; }
        public Guid? UserId { get; set; }
        public string Username { get; set; }
        public Guid PermissionId { get; set; }
        public string PermissionName { get; set; }
        public string PermissionDescription { get; set; }
    }

This DTO basically contains data from 4 entities: Application, UserGroup, User and Permission. I could easily do something like this with NHibernate:

        	var items = Session.CreateCriteria<Authorization>()
        		.CreateAlias("Application", "a", JoinType.InnerJoin)
        		.CreateAlias("User", "u", JoinType.LeftOuterJoin)
        		.CreateAlias("UserGroup", "g", JoinType.LeftOuterJoin)
        		.CreateAlias("Permission", "p", JoinType.InnerJoin)
        		.Future<Authorization>();

        	var dtos = new AuthorizationDtoMapper().ToDtos(items);

As you can see, that’s very easy to do. Unfortunately, this code really does a lot of stuff that you might not realize. For starters, it retrieves all of the Authorization instances with its related Application, User, UserGroup and Permission instances. It also fetches those entities in their entirety, which means it’s retrieving all of their properties while i only need their Id and Name properties really. And finally, NHibernate will set up all of the things that enable its magic for all of these entity instances. That takes a few more CPU cycles and uses more memory than you truly need for the scenario of fetching entities merely to return DTO’s. This extra cost obviously becomes worse depending on the size of the resultset that you’re fetching.

A better way to do this, is to simply let NHibernate fetch only the data (columns) that you need, and to let it populate the DTO’s itself. You can easily do this using projections and the AliasToBeanResultTransformer class. The code would look like this:

			var dtos = Session.CreateCriteria<Authorization>()
				.CreateAlias("Application", "a", JoinType.InnerJoin)
				.CreateAlias("User", "u", JoinType.LeftOuterJoin)
				.CreateAlias("UserGroup", "g", JoinType.LeftOuterJoin)
				.CreateAlias("Permission", "p", JoinType.InnerJoin)
				.SetProjection(Projections.ProjectionList()
					.Add(Projections.Id(), "Id")
					.Add(Projections.Property("a.Id"), "ApplicationId")
					.Add(Projections.Property("a.Name"), "ApplicationName")
					.Add(Projections.Property("u.Id"), "UserId")
					.Add(Projections.Property("u.UserName"), "Username")
					.Add(Projections.Property("g.Id"), "UserGroupId")
					.Add(Projections.Property("g.Name"), "UserGroupName")
					.Add(Projections.Property("p.Id"), "PermissionId")
					.Add(Projections.Property("p.Name"), "PermissionName")
					.Add(Projections.Property("p.Description"), "PermissionDescription"))
				.SetResultTransformer(new AliasToBeanResultTransformer(typeof(AuthorizationDto)))
				.Future<AuthorizationDto>();

Granted, you need to write a bit more code. But that code will do far less than the first version.

It’s been about 3 weeks since i’ve started my Ruby journey. Obviously, i still have a lot to learn. And in order to keep learning, i’m subscribing to more Ruby-related blogs and i’m starting to follow more Ruby-related folks on Twitter. At the same time, i’m gradually unsubscribing from a lot of .NET blogs and have even un-followed some people on Twitter that i only followed for .NET related stuff.

The biggest difference that i’ve noticed so far is that the Ruby community is pretty much a lot like what the ALT.NET community always wanted to be. As far as i can tell so far, knowledge is being shared all the time. And this is generally done in good spirits without negativity or flamewars (save a few exceptions obviously). People genuinely seem to care about helping other people out and making sure that everyone improves. I privately contacted a few Ruby people out of the blue. They don’t know me, and i didn’t know them. I just happened to stumble upon their blogs or twitter profiles and i figured “what the hell… i’ll just bother them with some questions”. And you know what? Every single one of them has responded in a remarkably friendly way.

When i asked them about interesting resources to follow as a newbie Rubyist, they all gladly shared their suggestions. When i thanked them for it, they all replied stating that i should feel free to contact them if i had any more questions about whatever Ruby related. Seriously, can you imagine the few .NET heroes that we have responding to questions through email from people they don’t even know like that? I can’t. Hell, i know most of them don’t respond like that. The few that do are still trying to earn their MVP award or are too worried about renewing their MVP status.

Now, i’m not saying that all is well in the Ruby/Rails world and that there are no arguments or that there isn’t any negativity or anything like that. Because the negativity and the arguments are definitely there. The thing is, it just seems to happen at a much lower frequency than it does in the .NET world. Granted, the .NET world is probably one of the most unfriendliest of all but still, the difference is striking IMO.

A part of me hopes that i’m wrong about this and that in the end, there isn’t really a substantial difference between the ruby community and the (previously ALT).NET community. Then again, another part of me hopes that what i’m seeing so far is indeed true and real. If only because that would mean that what i consider to be the ideal developer community indeed exists somewhere.

To summarize the difference: i’m sure some of you remember the infamous “Rails Is A Ghetto”-rant. Well, from what i can tell so far… if Ruby/Rails is a ghetto, then .NET is the trailer park.