Skip to: Site menu | Main content

Australia 7th in Google government removal requests per capita

Feeding some numbers from Google’s new Government Requests page into a simple spreadsheet reveals that Australia is 7th world-wide in Google government removal requests of search results and other materials. South Korea, Germany and Brazil lead the sad pack.

Note that only countries with over 10 requests have been included and that the population data is circa 2008/2009.

Maven voice notifications on Mac OS X

A quick hack to get the ‘mvn’ Maven script to vocally notify ‘Success’ or ‘Failed’ when the build completes. I find it useful as it grabs my attention when I’m undertaking other tasks while the build is churning.

Naturally the real solution is getting the build to run in seconds… Technical debt, thou art a harsh mistress.

Replace the last couple of lines (starting with ‘exec’) in your mvn script with:

"$JAVACMD"
  $MAVEN_OPTS
  -classpath "${M2_HOME}"/boot/classworlds-*.jar
  "-Dclassworlds.conf=${M2_HOME}/bin/m2.conf"
  "-Dmaven.home=${M2_HOME}"
  ${CLASSWORLDS_LAUNCHER} $QUOTED_ARGS && say "Success!" || (say "Failed!" && false)

Updated: Changed to avoid incorrectly returning a successful exit code on failure.

Affordable php mysql hosting with cpanel

DDD = ?

Mark Needham has a very interesting post regarding Domain Driven Design. One paragraph that caught my eye especially is:

As Luis Abreu points out, I don’t think there is a precise definition of what DDD actually is but for me the essence of DDD is still the same as when I compared it with OO i.e. Domain Driven Design = Object Oriented Programming + Ubiquitous Language.

I think that Mark is on to a very useful and succinct definition of DDD, yet I feel he overlooked the Law of Demeter. Building on Mark’s definition I’d define DDD as Domain Driven Design = Object Oriented Programming + Ubiquitous Language + The Law of Demeter. While some would argue that the Law of Demeter is implicit in Object Oriented Programming (or at least of OOP of the good kind…) I believe that it is important enough for successful Domain Driven Design that it should be explicitly mentioned.

Looking forward to your comments!

Google Maps Street View April Fools

The ‘you are here’ person in Google Maps’ Street View is now a Panda, as this screenshot illustrates. I’m assuming this is an April Fools joke.

Google Maps' Street View indicator is now a Panda bear

Google Maps' Street View indicator is now a Panda bear

I’m wondering if this is happening in the US version of Street View or only here in Australia.

‘IT pays’ doesn’t pay

Picture this rather common scenario–

You are in charge of a project for developing an internal application at a large brick-and-mortar company. Your target audience for the application are the employees of a critical business department (here on, Department X). The customer representative is the head of that department and is glad to be involved in the planning process and domain knowledge sharing as well as story analysis, hand over and sign-off; Seemingly, an ideal ‘customer’, here on- Mr. X.

Yet at scope planning meetings for the project, Mr X. is insisting that all the feature requirements are ‘Must Haves’ and while he agrees that the order of development should be based on ‘higher business value first’, he refuses to de-scope any features, insisting that due to external circumstances their delivery must occur by the project’s go-live date.

You would accept Mr X’s proposal if he would be willing to increase the budget for project to allow resourcing to meet these requirements. Great! He is willing! But wait — he can’t. Why? Because the project is funded out of the IT budget and not out of department X’s. This is a lose-lose situation, as the project is now set to fail in the eyes of the customer and in turn, harming the IT department’s reputation – Department X is not getting what it wants, even though it is willing to pay for it. 

The root cause here is the divergence between the beneficiary of the application and the entity that pays for it. The two may have differing goals, priorities, political considerations and machinations and whilst they both work towards the same organisational goals, these two entities operate under different business units with sometimes divergent operating considerations.

Budgeting models for IT departments seem to be based around IT as infrastructure — which makes sense for, wait for it… infrastructure: network, VOIP, hardware and the like — but repeatedly fails for business applications.

While it makes sense for IT departments to harbour the core capabilities and knowledge for software development (….development infrastructure…) it should only act as a cost-effective contractor to the business when developing business applications. Business applications projects should only be undertaken as part of a business case, they should have clear ownership by the benefiting entity and not the IT department.

When analysing teams and projects that clearly ‘smell’ and have a hard time changing, my personal experience indicates that in the majority of cases, following the smell to its source leads to this root cause. This is more pronounced in bigger organisations and seems to be proportional to the level of organisational separation between the project beneficiaries and the IT department. More so — this is almost always the underlying organisational issue that makes it difficult to implement agile methodologies.

This lesson was learned by many organisations, but unfortunately not all — and it should–

 The ‘IT department pays’ model of application development should die.

Movember Rain

Movember - Sponsor Me

A Good Ride

Work mates of mine just released A Good Ride, it is a Rails 2.0-based motorbike riding site with some killer features. Check out the ride video feature.

Cute method_missing hack

I love abusing method_missing in Ruby, it is great fun.

 module IsDoesIsntDoesnt

  def method_missing(method, *args)
    m = method.to_s
    if (m =~ /^is_(\w*?\?)$/) || (m =~ /^does_(\w*?\?)$/)
      real_method = $1.to_sym
      return send(real_method, *args) if respond_to?(real_method)
    elsif (m =~ /^isnt_(\w*?\?)$/) || (m =~ /^doesnt_(\w*?\?)$/)
      real_method = $1.to_sym
      return !send(real_method, *args) if respond_to?(real_method)
    elsif (m =~ /^(\w*?)s\?$/)
      real_method = "#{$1}?".to_sym
      return send(real_method, *args) if respond_to?(real_method)
    end     
    super.method_missing(method, *args)
  end

end

Object.class_eval() do 
  include IsDoesIsntDoesnt
end

Which lends itself to these types of natural statements:

?> "team".includes?("i")
=> false
>> "team".isnt_empty?
=> true

and:

>> [].is_empty?
=> true
>> [ :stuff ].does_include?(:stuff)
=> true

While I’m sure Ruby mavens will think of much nicer ways to implement this type of functionality, I had fun doing it.

An exercise for the reader would be to dynamically add the appropriate method, so the next call doesn’t rely on method_missing.

Back in Melbourne

Home sweet home! ;-)

I might be arriving tonight!

Just spoke to El-Al’s Bangkok office and they said that there is a good chance that I’ll be able to board the flight, so I’m going to grab brunch and head off to the airport. I’ll be in stand-by, but hopefully I’ll get on the flight.

Hope to see some of you tonight ;p