my recent reads..

Atomic Accidents: A History of Nuclear Meltdowns and Disasters; From the Ozark Mountains to Fukushima
Power Sources and Supplies: World Class Designs
Red Storm Rising
Locked On
Analog Circuits Cookbook
The Teeth Of The Tiger
Sharpe's Gold
Without Remorse
Practical Oscillator Handbook
Red Rabbit

Saturday, April 11, 2009

Why would you open source a framework?

Interesting to listen to Scott Hanselman and Richard Campbell talking over the rationale for open sourcing Microsoft's MVC framework on Hanselminutes show #175.

Part of the answer was a general desire to nudge Microsoft further towards embracing open source: "Why wouldn't you?". Which is admirable.

Partly it is a desire to open up the innovation envelope: Scott talked about his experience releasing TweetSandwich, and then seeing the unexpected derivative applications developed using the source as the base. Designing a framework is a daunting task. By definition, most of the framework's possible uses are not known ahead of time.

Take a listen to The Java Posse #241 which also came out this week, where they discuss the challenges of design as it applies to frameworks. One of the great concepts they talk about is how the best frameworks invariably have well designed escape hatches, to make sure you can overcome that typical problem of '..but the demo worked so well!'

Personally, I think having access to the source code of the framework is one of the most effective 'escape hatches' you can have.

Even if you never plan to fork or modify the framework, the ability to dive in and examine the source when things are not quite working as expected is really the difference between a framework you can work with, and a framework that will be discarded after a couple of projects. It is one of the great things about rails: often the documentation comes up short, but when you look at the api, the source code is but a click away!

Tweeting from your database with short urls

There's something cheekily enjoyable about getting all manner of 'non-human' things to tweet. I've heard of plants tweeting, but until I saw Lewis Cunningham's post announcing ORA_Tweet, I hadn't even thought of getting Oracle Database onto twitter.

Saturdays are good for little projects, so I thought I would add URL shortening service today;-)

Since twitter famously limits you to 140 characters, it is conventional to use a url-shortening service to include hyperlinks in your tweet. So my little play for today was to pair that idea up with ORA_Tweet.

There are a range of URL shortening services available including snipurl and tinyurl (here's a survey of services). I've been using for a while though, since it sports the simplest GET request 'api' you could imagine, making it great for ad-hoc programmatic use.

So I add an extra package called SHORT_URL which has just two functions:
  FUNCTION encode_url(
p_url IN VARCHAR2 )

FUNCTION encode_text(
p_text IN VARCHAR2 )
encode_url the main wrapper around the call to get a short url for the one you provide.

encode_text is a more convenient function that takes a block of text, and will replace all the urls it contains with the appropriate shortened versions.

Then there's just one change to the ORA_TWEET package body:
< url => 'status=' || SUBSTR( short_url.encode_text(p_string) ,1,140));
> url => 'status=' || SUBSTR(p_string,1,140));
Now you can go wild with URLs in your database tweets:
IF ora_tweet.tweet
p_user => 'twitter_username',
p_pwd => 'twitter_password',
p_string => 'ora_tweet v1.1 is complete! Now with url shortening ... see' )
Building on Lewis' original justification for building ORA_Tweet, you could for example include links to a report page or admin screen when your long-running process sends you its "I'm done" tweet.

That's if you need justification;-)

If you are interested, the source is up on my github account now:

Friday, April 10, 2009

Idea #105: what name babby? (Dugg already pwned)

I just saw mentioned on programmable web.

It's a first step towards addressing one of humankind's biggest challenges: forget about running out of IP addresses, we're going to run out of usernames first!

What kind of handle do you think your children be able to get on Friendfeed? Under what name will your grandchildren be able to tweet? And do you think they stand a chance of getting the same nick across all their services?

There's a mad stampede for names going on, and any self-respecting parent (or prospective parent) who wants to bring up their children right ought to be out there buying up their progeny's place in cyberspace. Along with the tuition fund you need: website domain name, email account, twitter handle, skype, tumblr ... who knows which will survive, so get them all.

You never know: what if you kid gets famous, or even goes into politics? It wouldn't be very presidential if they tweeted as @spaceycasey123456.

Parents need something more than namemasher. In addition to the parents' names, it needs to munge in family and cultural background, existing baby name references like (that's the one with the helpful definition of Espn), cross-check against existing accounts with something like, and then go out and pre-register all the services for your unborn child. What an 18th birthday present that would make!

In short, the world needs

Thursday, April 09, 2009

Learning not to love Java

Back in 99, I spent about six months procrastinating over a MAJOR decision (or so it seemed at the time).

To stick with the Microsoft camp - where I'd built up substantial experience through ActiveX to DCOM to COM, IIS and Commerce Server 3.0 - or jump onto the Java bandwagon?

Ultimately, Java won out, and along with millions of others, we've made Java the enterprise platform of choice (arguably).

The interesting point upon reflection, is that there was never any doubt in my mind that Java was somehow 'better' and more 'pure', in an academic sense.

Almost ten years later, I shocked myself recently when returning to Java after spending a good part of the past two years infatuated with ruby and rails and other scripting languages.

Where before I saw classical elegance, now my first thoughts were this sux and the language is just getting in my way.

First the verbosity kills me:

WeLikeLongDescriptiveClassNames myReallyDescriptivelyNamedObject = WeLikeLongDescriptiveClassNamesFactory.getInstance(duh);

How many times do I have to tell the compiler what kind of object I am dealing with? Sure, I understand the benefits of the Factory pattern and the subtleties you can construct by virtue of the inheritance hierarchy. But most of the time, I just want the compiler to do what is most obvious, and don't make me write a novel for the most straight-forward tasks!

Then there's the language-promoted cultural phenomenon of class explosion. Need half a dozen value objects to represent the various information to be passed around in your domain? Sure! With unit tests all, I am sure. Most of the time, I'd now prefer to scream YAGNI!

But the true ephiphany was my run-in with primitives (again ... every year or so). Using JSP sessions as a perfect place to test this out. Take an int and stick it in the session:

int startingInt = 3;
session.setAttribute( "startingInt" , startingInt);

What type is in the session? An Integer object of course. Java has cleverly done a type conversion for you, from a primitive to an object. But woe betide the simple developer who assumes this must be a commutative operation:

int newInt = session.getAttribute( "startingInt" );
// Error!!

That's what I call a language actively getting in your way. Kind of like if you deposited $10 cash in your bank, but when you went to withdraw the money, the teller threw the shutters down and said you could only get your money back in government bonds.

So do I have a point or is this just a rant (and certainly one that is not as erudite as many have written)?

I guess I must be pretty slow to catch on to what others knew long ago. The true test comes down to being able to realise one's goals. For personal projects, I find I'm able to knock out complete (and impressive) applications in Rails, while I still have ten java-based ideas on the drawing board.

It comes down to whatever works. And it should.

Does that mean I hate Java? Not at all. I still get a bit of a thrill out of its clean lines and voluminous open source library support. Much like seeing an aging and long-since outclassed 512BB. 'Classic' is timeless.

No. I don't hate Java, but neither do I love it the way it used to demand. I look back on my naïve 1999-self in wonder. Building experience is key, but it is a mistake to tie this to a language. Computer languages are the tools of our trade, and the more you know, the better you will be. When people mention Haskell, Scala, Eiffel ... do you know what they are on about, or do you just nod intelligently and pray not to get caught out?

With more tools at our disposal, we are better able to tackle new challenges in the most appropriate way.

To get the job done (which is generally the point, right?).

Thursday, April 02, 2009

Crazy Stupid Security Policies #1

So we've all been there .. a super-secure data centre where they ban wireless access while in the server room.

I recently had an acquaintance pulled up for using wireless while in one such place. Twice. I won't name where, because this issue knows no bounds.

It is a nice and reasonable rule from the security policy astronauts' perspective, because usually those responsible for the policy are not also accountable for operations. I presume the main concern is bridging networks and (intentionally or not) providing backdoor access.

They conduct audits and spot-checks, and on the surface everything looks great. If all you are concerned about is the paperwork, your job is done.

But in practice, and from what I have observed over the years, reality is a very different thing.

Unless all you are doing is bolting a server into a rack or plugging the fibre cables in, it is hard to get the job done these days without external network access.

  • Maybe that is for research: consulting vendor guides or searching the knowledge bases (because no-one provides all the doc on disk anymore - it's on the web!)

  • Or often you need to test the system you are configuring or diagnosing, and that can only be done from "outside" (SSL termination at an external-facing load-balancer for instance).

  • Or, in this Web 2.0 world, you need to collaborate with colleagues to get the job done. Skype or IM to get hold of the expertise needed for the task at hand.

  • Worse still, you have an "escort" policy, but a simple request to get in or out of the data centre is meet with abuse, recalcitrance or outright hostility from the people who are meant to escort you (like it's not their job!)

All these factors increase the frustration of SEs the world over, in the face of data centre policies that treat IT as if it were like installing an air-conditioner.

Now what happens when the threshold of pain is pushed up and up like this? At some point, the immediate pain (can't get to metalink) exceeds the potential future pain (maybe I'll get caught using wifi).

And, dear data center security experts, happens next?

Human nature takes over. Before you know it, you have a feral group of wifi/bluetooth/3G connected people running around your DC.

The worst part is that you have pushed the behaviour underground, where it is truly uncontrolled. In being secretive, people are breaking the most significant security prohibitions of all: bridging networks. Sorry, you don't know how much it goes on. (personal aside: yes, I admit I have, in the past, used wifi in a non-wifi DC. But being the conscientious and security aware guy that I am, I was always quite anal about disconnecting from the DC network before getting on wifi. Not that anyone knew. And if they did, my reward would have been ... a punishment!!)

So what approach would an enlightened, modern data center manage take? I would sleep much better at night if I:

  • Had an open wifi usage policy to bring the practive into the light of day. Maybe tables running between your racks for wifi-connected laptops (bolt them to the desk if you like, with a CCTV overhead), while direct network/server access had to be done rack-side.

  • Educate on responsible wifi use. Make sure people understand the risks of bridging nets and make it clear its OK to be on wifi, but not ok to bridge.

  • And have a clear understanding with my internal staff that "escorting" is not an interruption to the work they are doing, it is a vital task that will be rewarded.

Fundamentally, this means I would need to reconsider how I defined my job as a data centre manager: I'm not a slave to a policy handed down from upon high, my job is to implement and enforce the best procedures possible that both enforce the policy goals, while providing excellent customer service. Achieving this may mean I need to think a little out of the box, even be a little creative and pragmatic.

Now I should be clear that in writing this I am not condoning anyone who breaks a clearly published policy not to use wifi in a data center. On the contrary, if you have to work in such a place, I'd say stick to the policy, and drive the escorts nuts as you go in, out, in, out and in again to get the job done. Demand a full time escort if you need it.

My real message is to anyone with authority over security policies and their application: recognise that a policy on paper is worth exactly the cost of the paper unless you have taken into consideration the human factors involved and done your best to ensure that your procedures and environment are optimally designed to encourage the very best behaviours, and not the ones you most want to avoid.

Anyone have data centre security horror stories to share? I would love to hear about them! Better yet, how you manage to get around the stupidity, yet stay "legal".