Thursday, 13 October 2011

Signs Don't Work! And a solution to one case... (by K)

Over the last 40yrs I've been relatively sentient, I have noticed a gradual but continual rise in the number of signs telling us not to do things.
You know what I mean:

  • "Smoking is addictive" - no sh*t - Ah damn. Too late.
  • "No user serviceable parts inside" - Hmm. Sounds like a challenge to me.
  • "Emergency access only" - with no alarm it'll just be ignored.

And I see very little evidence that they work.
After seeing them the first and second times, they just ignore them.

Example 1 - Emergency Doors
In the building where I work there is 1 single, slow, tiny elevator servicing 2 floors of businesses.
Most people going down to the car-park use the emergency stair well.
And almost all the smokers use it to get to the "Designated Smoking Area."
At the base of the set of stairs is a single door leading outside to the DSA.
And they 'chock' the door open while they have a smoke.
They could walk the extra 30 feet round through the main entrance, but it's easier to 'chock' the door.
And they forget to 'un-chock' it occasionally.
This means the door to the outside world stays 'open' all night - a violation of security and safety.
The safety dudes have installed cameras, placed GIGANTIC signs saying "NOT TO BE USED EXCEPT DURING EMERGENCIES" and repeatedly adjusted that auto-shut lever thingey to force the door to shut.
The problem is that humans are inventive little buggers.
With a new supposedly un-chock proof door in place, everybody figured out, within a day, how to fiddle with the latch thing to chock the door open.
So to avoid a 30' walk, they simply ignore the cameras, ignore the sign, open the door and click in that little thing next to the latch so the door can't shut.
The safety dudes then plastered the door with "THIS DOOR IS ALARMED".
But even the average person can easily see there is no reed switch, so they ignore it.
All to save a 30' walk.

Example 2 - The Coffee Machine
We have a rather expensive Swiss coffee machine in our lobby.
Every couple of hours it does a 'rinse'.
This involves spewing out hot water and milk into the drip tray.
That design choice may seem silly, but the machines aren't meant to spend their lives in an empty un-manned area and used all day.
They would normally be in an area which would have someone to watch over it and empty the drip tray.
Er. Got side tracked.
Anyway.
The point is that since the machine is un-manned most of the time, and the rinse cycle happens relatively frequently, the drip tray overflows and causes a massive mess.
To make matters worse, most of our staff are "young men".
By that I mean: "lazy grubs who are only just getting used to not having their mother to clean up after them."
So we have a plastic beaker that is supposed to be placed under the spout so that the rinse cycle spews into it, instead of all over the floor.
And over the last few months emails and chats and standup announcements have failed to get across the message "FOR PITIES SAKE, PUT THE BLOODY BEAKER BACK UNDER THE SPOUT WHEN YOU'VE GOT YOUR COFFEE."
Signs have been made.
And ignored.

A Proposed Solution:
We have Arduino.
We have Kinect.
We have Speakers.
We have Cattle Prods.
We have Tesla Coils.
We have Lasers.
Can't someone just make a project that detects if the beaker isn't back under the spout as the person starts to leave and give the little buggers a load "OI! PUT THE BLOODY BEAKER BACK" and give their ass a jolt?

Wednesday, 12 October 2011

Stumbled on this and it needs support (by K)

Like Task Focused Interfaces like Mylyn in Eclipse, but using NetBeans?
Check out this project which I noticed in issue 508 of NetBeans Weekly News.

Task Focused Interface for NetBeans IDE

May have issues with anything less than NB 7.1 beta, but I tend to go bleeding edge...
Love it.

Detecting if Mongo is running in your app (by K)

We use MongoDB for a load of stuff.
One thing that is a problem is that, in the dev environment, the mongo service needs to be restarted.
(In production we have different mechanisms of course)
So for a period of time while developing an app, Mongo may not be running.
And if you make any call to it in your app you get a shed load of exceptions that, for some reason, can't be caught.

This kind of thing:

[#|2011-10-11T17:44:58.420+1000|WARNING|glassfish3.1.1|com.mongodb.tcp|_ThreadID=27;_ThreadName=Thread-3;|Exception determining maxBSON size using0
java.io.IOException: couldn't connect to [your-app.com/your-ip:27017] bc:java.net.ConnectException: Connection refused
at com.mongodb.DBPort._open(DBPort.java:224)
at com.mongodb.DBPort.go(DBPort.java:101)
at com.mongodb.DBPort.go(DBPort.java:82)
at com.mongodb.DBPort.findOne(DBPort.java:142)
at com.mongodb.DBPort.runCommand(DBPort.java:151)
at com.mongodb.DBTCPConnector.fetchMaxBsonObjectSize(DBTCPConnector.java:429)
at com.mongodb.DBTCPConnector.checkMaster(DBTCPConnector.java:416)
at com.mongodb.DBTCPConnector.call(DBTCPConnector.java:193)
at com.mongodb.DBApiLayer$MyCollection.__find(DBApiLayer.java:303)
at com.mongodb.DBCollection.findOne(DBCollection.java:565)
at com.mongodb.DBCollection.findOne(DBCollection.java:554)

So I did some digging to find out what's going on and how to programmatically checking if the service is available.
I found this:

http://groups.google.com/group/mongodb-user/browse_thread/thread/2b3c1d4bdb1314e3

And made my own version which is called before any persistent action.
Here are the bones of it so you can modify it to suit your needs.

boolean mongoRunning = false;
ServerAddress serverAddress = new ServerAddress(dbHost);  // dbHost is the mongo host name
DBPortPool pool = mongo.getConnector().getDBPortPool(serverAddress); // mongo is the instance
DBPort port = pool.get();
try {
  port.ensureOpen();
  mongoRunning = true;
} catch (IOException e) {
  // Uh oh. Mongo not running. Do something meaningful...
  log.error("MongoDB isn't running on [" + dbHost + "][" + dbPort + "]"); // or just log it
} finally {
  port.close(); // should do try/catch here...
}

It's overkill of course, but it does help.
Just to help out.

Tuesday, 11 October 2011

I'm a dinosaur (by K)

I started in the IT industry in April '77.
I was completely broke and met a friend of mine who was doing a "Diploma in Computer Programming."
Sitting with him working at RPG and COBOL I thought "This is easy."
So I asked him how much he would make a year when he finished.
After picking myself up off the floor, I thought "I have to learn this!"
Problem was, I was broke, unemployed and definitely couldn't afford to take 2 years to get that piece of paper.
Worse, I had got woeful scores in High School, so I'd have to do a raft of courses before I could even start.
Hmm.
So I just walked around the various business districts asking to speak to the local IT person and tried to get a job.
It took 2 weeks but I got in.
An accountant who was building a computerised accounting system was mildly interested.
It was a tad embarrassing for both of us...
Him: "Do you know what RAM is?"
Me: "Male sheep?"
But he hired me.
For the princely sum of $75 a week.
I lived in an condemned, abandoned house which was falling down and crawling with cockroaches.
I made and ate Pea with Ham soup for a month.
But after 6 months I was in charge of a product.
I had learnt Assembler, de-compiled CP/M, located and fixed a dud memory chip on a SuperBrain and wrote a new screen driver.
I also rewrote the Report Writer component for the system.
I discovered a bug in the integer handling code for the MBasic compiler and sent a fix to Redmond.
So my career started.
Since then I've used just about every language invented - yes, I even used APL once.
I was instrumental in creating a new language and was a paper millionaire for a while.
1,000,000 lines of K&R C.
Even have the "executive" pins given to me by AT&T and others.
I was even in contact with ESR with fixes for Sendmail, Prof J Ousterhout, Al Stevens and so on.
I wrote a self-published manual for Systems Administration on SunOS.
I used VisualAge.
I have my name on a MAN page.
Now I'm 55.
And I did an ego-search.
Squat.
Now that's depressing.
And now I'm surrounded by kids.
Kids who don't understand stuff.
Kids who don't have a clue about DRY or YAGNI or were all this stuff they use comes from.
And they don't seem to care.
They assume Factories and Builders and Adapters are the way it's always been.
They've never heard of "Mel."
They get entranced with a specific technology and when all you have is a hammer...
So they lumber along crashing about like drunk Elks at a pool party missing the point at every turn.
Because they don't seem to care about why things are they way they are.
They just seem to twiddle knobs, mash buttons and pull levers until magically it works.
And if you try to explain, it seems like they're just waiting for you to finish so they can continue twiddling, mashing and pulling.
So much for the Scientific Approach.
Sure, they're passionate and committed and excited.
But you can't tell them squat.
They waste hours and build rubbish that will lurch along, become un-maintainable while they move onto the next exciting technology.
Now I know that the worlds changed.
I know that the old idea of a job that you went to each day and did what your boss said is fading.
I know that everyone with a laptop and inspiration is essentially the same as a factory of yesteryear.
I'm not talking about the "Death of the Job."
It's just the lack of care and responsibility.
Sigh.
I'm guess I've been EOL'd and become surplus to requirements.
Might as well go and eat worms.

Monday, 10 October 2011

Todays Interesting News

Science:
New telescope takes image of galaxies colliding
Lung cancer secret solved by scientists
Qu8k Rockets Above the Balloons
LHSee - Large Hadron Collider app - Big bang science in your pocket
Western fast food, waistlines surge in India
New theories emerge to disprove OPERA faster-than-light neutrinos claim

IT/Tech:
Chrome extension enables remote control
EU approves Microsoft's Skype takeover
Atlassian buys SourceTree, makes it free
Computer Virus Hits U.S. Drone Fleet & Predator Drone 'Virus' Could Be Military's Own Monitoring
Oracle's Ambitious Plan For Client-Side Java
Google puts MySQL in App Engine Cloud with Google Cloud SQL
Puppet vs Chef, Fight
A reboot of PHP: keep the philosophy, improve the syntax with the jvm

Nice/Cool:
Three women win Nobel Peace Prize
Scott McNealy's new venture
Flying Monsters' Pterosaurs Soar With Avatar-Style 3-D
Insert Coin: Romo, the smartphone robot (video)
CLASH is an adorable, cloth-climbing roach-bot (video)
Robo-Tea
Watch A Pilot Cooly, Calmly Ditch His Plane In The Pacific Ocean

Don't they ever learn?
Incomplete PDF Redaction Leaks Data From UK MoD

WTF?
Patients' lists exceed population
California pot crackdown
Homeland Security starts Pre-Crime
German government accused of spying on citizens with state-sponsored Trojan
UN Bigwig: The Web Should Have Been Patented and Licensed
Florida School District Begins Fingerprinting Students
FBI Plans Nationwide Face-Recognition Trials In 2012
Painful Neck? YOU May Be Suffering From Text Neck!
Women who violate headscarf law should be stripped of passports: Iranian lawmaker

Business/Finance:
UK banks hit by Moody's downgrade
Groupon steps back as LivingSocial issues $143 million in stock
Lack of cash claim 'hilarious': Groupon
Oil May Be Finite, But U.S. Production Is Ramping Up
Clamping Down on High-Speed Stock Trades: US, Canada, European regulators
eBay En Route To $4B In Gross Mobile Sales
9 Reasons Why Online Video Advertising Has Failed to Meet Previous Forecasts

You know what I like? Throwing code away.

I had a hard look today at some of the coding being done in one of the apps I'm involved with.
A maven project with dozens of sub-projects each having different versions of dependencies in their POMs.
Many of the sub-projects have dependencies on other sub-projects and the web is immense.
I did a "mvn dependency:tree" - HA! That should be "mvn dependency:omg".
Two minutes of tree screaming past (or was that me?).
Boy oh boy.
What a load of...
And there was more...
One class will package up a bunch of data into a DTO to pass it to another project which then picks it apart to make another DTO to pass it...
Wha?
This is silly.
I tried to do a plain old "mvn clean install" on one of the sub-projects and it looked like an explosion in a stack trace factory.
Pages and pages of gumpf roaring up the screen.
How would you ever know if anything was out of whack?
I'm not talking about unit tests.
You wouldn't know if the dto->data->dto->data->dto stuff is going on.
Wasteful.
Acres of jars in the .m2 folders.
Builds taking forever.
This is silly.
So I took one of the projects and tore it to pieces.
I broke it down into single units of work.
So I have a load of little dinky jars that don't change from build to build and do exactly one thing.
For example, one project has dozens and dozens of try/catch->log.error() stuff going on.
You know what I mean, methodA throws the Exception to caller methodB which throws the Exception all the way up to this:

    try {
      // call methodZ
    } catch (SomeException) {
      // Uh oh. What's the context? Oh well...
      log.error(ex.getMessage());
      log.error(StackDump.getTrace(ex));
      // Do we continue? Or die?
      // Oh well... Just keep on Truckin' Hope it works...
    }

So I created a jar project that makes a RESTful call asynchronously to a web site to report exceptions.
It looks for a config file of the same name as the jar which tells it what to do (including time outs, distributed whatever).
It doesn't care what the site(s) does with the exception, it just sends a bunch of basic information and the stack trace to where it's told to.
But this jar now has exactly one class.
And it's as dumb as a box of hammers.
So now, any project anywhere can do something like this:

    try {
      // something that might break
    } catch (SomeException ex) {
      // do anything that may be needed in the project context
      new ReportException("ServerName","Module","SubModule",ex).send();
      // crash, burn, rethrow, use a default, use a config option, continue - whatever
    }

And exception handling becomes easy enough that programmers won't do this:

    try {
      // something that might break
    } catch (SomeException ex) {}

Because it's now easy to report it.
And that exception is sent to a central (or distributed depending on the config file) site(s).
That site is another dinky project that does one thing.
It has one Resource which responds to PUT on one path.
It has a simple Config file which tells it whether to log to MongoDB, send email, post to an IssueTracker or whatever.
It depends on several small project jars that do one thing each: log to MongoDB, SendEmail, PostToBugZilla and so on.
So now we have several tiny jars and 1 tiny war that don't change.
And tons and tons of Exception handling in multiple sub-projects can be thrown away and better monitored.
Moreover, the store where the exceptions are saved (MongoDB, MySQL, Cassandra whatever) can now be monitored by Nagios.
And all those sub-projects have a load of dependencies reduced.
And the app-build is quicker.
I like(+1) throwing code away.

Friday, 7 October 2011

7th October randomness (By K)

IT:


Business/Finance:

Other:

6th of October randomness (by K)

Wednesday, 5 October 2011

5th of October Randomness


Tuesday, 4 October 2011

4th of October Randomness

Man rips out eyeballs during Mass