Written on 7:30:00 AM by S. Potter

While I usually do not express views about current affairs and political figures on this blog (except to highlight a point as applied to software), I couldn't let this beautiful day go by without a mention of the sheer delight I am experiencing being freed from the shackles and chains that was Tony Blair's premiership. My only regret is this has come ten years too late.
For those that do not know what our "fabulous" Tony has done domestically in UK, you should watch the British documentary Taking Liberties released earlier this summer. You can view the trailer below:
If you still want to know more about the police state in UK created by Blair (all in the convenient name of "terrorism"), just ask Jean Charles de Menezes...oh wait, you can't. This Brazilian man was shot dead by Blair's police state at the Stockwell Tube station on the London underground. He was NOT affiliated to the London bombings in 2005 or any other terrorist plot or organization.

Written on 12:36:00 PM by S. Potter

Twitter4R, the open source Ruby project for the Twitter REST API, version 0.1.1 has been released this afternoon as a Ruby Gem. It may take a little time for the new Gem to appear on the Rubyforge gem servers, but once replicated to all mirrors you should be able to do the following:
require 'rubygems'
gem 'twitter4r', '0.1.1'
require 'twitter'
client = Twitter::Client.new(:login => 'mylogin', :password => 'mypassword')
timeline = client.public_timeline
timeline.each do |status|
puts "#{status.user.screen_name}: #{status.message}"
end
This will get you started. Changes from 0.1.0 to 0.1.1 include:

Addition of proxy support

Addition of SSL support

Migration from RSpec 0.8.2 to 1.0.x specifications

For proxy support you can do the following:
require 'rubygems'
gem 'twitter4r', '0.1.1'
require 'twitter'
Twitter::Client.config(:proxy_host => 'myproxy.host', :proxy_port => 8080)
# continue using Twitter4R API as above.
Or if you have a proxy server that requires authentication, you can do the following:
Twitter::Client.config(:proxy_host => 'myproxy.host', :proxy_port => 8080, :proxy_user => 'myproxyuser', :proxy_pass => 'myproxypass')
# continue using Twitter4R API as above.
To force Twitter4R to use SSL, we would write the following configuration code before using the client API:
Twitter::Client.config(:ssl => true, :port => 443)
Enjoy!

Written on 9:14:00 AM by S. Potter

While nothing has yet to be release for Twitter4R since version 0.1.0, it has not be standing still. A number of changes will be released within the next few business days.
Firstly, I will be releasing Twitter4R 0.1.1 with just two public API changes (and one internal change):

[PUBLIC] SSL support

[PUBLIC] Proxy support

[INTERNAL] Migration from RSpec 0.8.2 to 1.0.x

Secondly, I will also be releasing Twitter4R 0.2.0 very soon after 0.1.1, which will contain a number of API changes. These changes are mostly documented in the comments of ticket #6 in Twitter4R's Retrospectiva project. I plan writing much more RDoc documentation for 0.2.0 and subsequent 0.2.x releases. Lack of documentation was a problem with the 0.1.0 release.
The reasoning for the quick succession of releases of Twitter4R is so that 0.1.x versions can have the same public API, whereas 0.2.x signifies a change in API to allow us to cover more of the Twitter REST API without cluttering the Ruby API too much.
A major reason for the API revamp was to hide some of the very unRESTful and asymmetric things the Twitter team have exposed in their public API. If any of the Twitter team are reading this, I recommend RESTful Web Services.
I admit to dropping the ball on the next release of Twitter4R gladly, because it is true. I violated the first rule of agile development: Do not bite off more than you can chew!
I apologize and will learn from it. Thanks for your patience.

Written on 9:40:00 AM by S. Potter

Despite applying his talents towards a despicable cause, Joseph Goebbels (Hitler's propaganda minister from 1933) had amazing insights into public behavior and described his most famous observations:

If you tell a lie big enough and keep repeating it, people will eventually come to believe it. The lie can be maintained only for such time as the State can shield the people from the political, economic and/or military consequences of the lie. It thus becomes vitally important for the State to use all of its powers to repress dissent, for the truth is the mortal enemy of the lie, and thus by extension, the truth is the greatest enemy of the State.

Using Goebbels' wisdom Java™ successfully launched their propaganda campaign initially against C/C++ with the rhetoric that Java guards against programming errors unlike its predecessor. Yes, Java does lean very heavily toward a dictatorship style of governing. This is without doubt. But does this translate to guarding against developers' own stupidity?
When moving from C++ and Perl to Java back in 1997 I appreciated this dictatorship-style of governing very much. It removed *many* cycles of thought from development and I became lazy. Earlier in this new millennium I moved to a more democratic language called Python, where I enjoyed this new found freedom. Soon after the Python doctrine embedded deep-rooted values in me, I discovered the [almost] Libertarian utopia that is Ruby (though not perfect, thus the [almost]).
Where am I going with this? Excellent question. Where was I? Ah yes, Java™, propaganda, Goebbels, etc....
Now that Java™ has new mortal enemies - Ruby, Python and other non-static languages that provide significant productivity gains as compared with large bloated development in Java - the Java™ machine is using the same rhetoric. Is it working? In short, for the software Lemmings that don't think, it is working well. Due in large part to the Java Dogma.
In truth I find the liberty offered by these non-static languages (yes, Python that still includes you, weird *strongly*-typed cousin) provide a much greater guard against programmer stupidity than the forced dictatorship style of Java™. This is because the developer and development team must take full ownership of the responsibility for their work and thus disciplined, smart and agile developers tend to flock to these languages, leaving the lazy developers only looking for a nice pay check for using the right buzzwords at the right time in the Java world.
Java now faces a big problem: how to not let this lazy and uninspiring critical mass not weigh it's reputation down too much? This is an excellent question and one I fear Ruby will need to find an answer to soon, if PHP hackers with no real software development understanding keep flocking to Ruby through Ruby on Rails.
The growing popularity of Ruby due to Rails will bring the current community (you and I) problems that we will need to start thinking about now if we are to survive the consequences. Or we will suffer a very similar fate to Java, which would be very sad indeed.

Written on 8:08:00 AM by S. Potter

Everyone of us has probably met one. You may have worked for one as a subordinate. You may even be one. Though many people do not know what a Cowboy Monkey is.
In a nutshell a Cowboy Monkey is that person on your team that jumps in to save the day with a hack. They are the ones that repeatedly put out the same fires instead of making sure they don't start them again. A Cowboy Monkey can't be bothered to take 5 minutes a day to commit code changes into a SCM and resync their working copy, but spends half the day in meetings not achieving anything. They are generally horrible dates because they spend all dinner talking about "quick and dirty" solutions.
Generally a Cowboy Monkey:

does not believe in any type of SCM system.

does not think about the longer-term consequences of their actions only the immediate effects.

does not believe in unit, functional, integration, performance or system testing or specifications of any kind.

prefers to test in production rather than create a whole new staging environment.

has not heard of best practices.

has a tendency to build silo systems.

has a total disregard for the software architecture of a project.

usually has no real understanding of design patterns of any kind.

thinks PHP is so good that it can solve the war in Iraq.

gives smiles and nods but delivers very few of the promises they make and almost nothing on time.

If you nodded at least 5 times in agreement with any of the statements above, you might be a full-fledged Cowboy Monkey. Do not fear, you are amongst friends and we will help you overcome this disorder.
If you are not one, how many Cowboy Monkey's have you worked with thus far?
Please feel free to share your (anonymous please) stories of the Cowboy Monkey's you've met on the job in comments.