Chris’ Musings

Musings - Tiny Usability Improvements

2013-03-09T00:00:00-05:00

I've been wrapped up in a datacenter move for the past two weeks - migrating old UNIX and ESX hosts from one old company to a fresh, vibrant new company. At home, I'm also busy setting up a new VPN-enabled network and reconfiguring the various routers and switches I have scattered throughout the house. In the process I've had to configure numerous networks. My Mac is a great tool, and the IP interface is many fewer mouse clicks away than on Windows (not to bash Windows, but to single out usability issues). On Windows 7 (Start -> Network Connections -> Right Click -> Properties -> Select Adapter -> Right Click -> Properties -> TCP/IP) - Mac ( Apple Icon -> Settings -> Network -> Adapter ).

So yes, the Mac is a smidge faster to get to and change. But you know what would be better? If it let me specify IP profiles with preconfigured info so I can save myself the trouble of re-entering data for this switch so I can test that Cisco ASA, but now I have to switch to that switch and test that other Cisco ASA. Or at home, switch to Inside Network (static or DHCP), or the Outside Network (Static IP). Because let's face it, in only one of those cases was DHCP actually available to me (Home router - inside network). And while link-local DHCP is useful after a fashion (169.254.0.0/16), it turns out it's not very useful in actual practice. But considering that I have had to switch between 4 or 5 different network configurations many dozens of times over the past two weeks debugging networking issues, a small change in usability would mean a huge change in savings for me.

And this circles back to my previous thoughts of having "competency levels" in our OSes that alter the features available to people, depending on their competency level (duh). If you're a total newb, you get an iPad-like interface (pretty hard to screw up). If you're a moderately experienced individual, you get an interface such as the default today. If you want to kick on the secret "super-user mode" you have to A) find it, B) pass a test (like compute binary numbers or subnet masks - same difference, right - LOL), and you get a richer feature set that's less likely to get in your way, or help you be faster at tasks.

I know that the time invested is possibly not worth it for the fringe of folks who truly are "super-users" and can benefit from features such as this, but there are plenty of us out there - how much time could Apple or Microsoft save by making things just a smidge easy and more powerful for us?

Beginning UNIX - n+1 Steps to Becoming a Programmer/Admin

2013-03-09T00:00:00-05:00

When I began my career, the only hope and help I had was primarily from folks all over the country via dialup BBSes, FiDO Net, and a few strategically located senseis. As I joined the working world, my experience was broadened by having access to think I did not as a high-school student in 1994 - AIX on giant IBM mainframes, WindowsNT, SGIs, etc. Oh, and "Unix Power Tools" and about a 100 more top-notch mentors. But I've longed to write my own roadmap to help folks learn the things I have - to give them the modern tools and tricks that I've spent nearly 20 years honing (sometimes badly and inefficiently). It's also a tool I wish to use to broaden and enrich my own deep understanding of the field I work in. My experience is so broad, that at times I feel as if I am missing significant depth in understanding - someone once said if you cannot explain something to a 6 year old, you truly do not understand that something. My hope with this project is that I will be able to address that shortcoming.

Datacenter Migration Checklist

2013-02-22T00:00:00-05:00

I'm in the midst of yet another great datacenter move, and this one feels like it's been cobbled together from the scraps of chaos with a boatload of confusion and poor planning thrown in. In the midst of all this chaos, so far no one has been injured, but I've been slowed down by not having the proper tools. Since it's been a while since my last DC move, maybe I can be forgiven for some of the following oversights, but below are my observations about how to prepare for these events for those unlucky enough to be doing this for the first time, or are just really rusty!

Tools

Screwdrivers (Philips, Flat, Torx, Hex - various sizes, two good assortments and drivers)
Ka-bar folding knife <- Do NOT underestimate how much you will be using this
Socket set (Metric/SAE - 1/8-1/2", 3-18mm)
Zip-ties - 4-5", lots and lots.
Side-cutters
wifi hotspot/dumb switch (Linksys router) + cables.
extention core + household power switch
DB9 F/F serial console cable
Cisco console cable
Vice-grips.
Flashlight + fresh batteries
A few magnets for holding paper to cages.
pens/pencils
first aid kit

Strange bits

C14 to NEMA 5-15R adapters ( or your local household equivalent - most PDUs s don't have standard 120/250 wiring any more)

Serial Console

Cisco:
HP:
Sparc:
AIX:

WIP.

HP LAN fixes:

IP Interfaces: lanscan

/etc/rc.config.d/netconf

/etc/rc.config.d/namesvrs

NIS_CLIENT=0/1 (off/on)

Source Control Facepalm!

2012-08-15T00:00:00-04:00

So there I was, leaving work on a Friday for a week-long respite from the rat race (haha!) and I was faced with cleaning up and saving work I had just slaved over. I finally had my app doing what I wanted, and I was working on making it look pretty, and I was also faced with rushing out to meet up with someone for a few pints. Well, the one thing I DIDN'T do was a git push - even though I looked at it for a while before I left and thought about it. Well, for some reason the git plugin in Eclipse didn't remember my remotes, and so I would have to enter all the remote data by hand. I gave it a pass, hit Hibernate, and ran off for fun in the sun.

Go figure, when I returned to work this past Monday, my hard drive was dead. I had all of my email saved on either the Exchange server or the network home drive, some of my data on Dropbox (safe) - but my project was toast - no backup of the machine itself. For a simple little operation, I could have saved myself a weeks worth of rework. Working git-remotes and a simple git-push - all that would have saved me.

I'm not a newbie to data loss prevention - in a previous job I mastered it as the network backup admin. We never lost data under my reign as master of NetBackup (Shudder). But yet as a user I still fall prey to assuming that my technology is 100% reliable. While this isn't a travesty, this was only a hobby project mind you, it's a good reminder that one can never be too vigilant about their data, and that with a tool like git, where backup is almost TOO easy, it behooves one to make sure one uses those features as often as possible.

Lesson learned.

More Unit Testing Cassandra with Maven

2012-07-17T00:00:00-04:00

Nearly two years ago (wow) I wrote about unit testing with Maven/Cassandra in Unit testing Cassandra with Maven. Well, the project I was working on got a little sidetracked, but I came back to it with a vengeance this month to try and bring it to completion. I moved development hosts, and ran into a few small issues with how I set up the build environment (great for getting ready for a continuous integration setup). At the same time, I thought I'd bring myself up to date from Cassandra 0.7 to 1.1.2. That's where all the trouble began!

First things first - version control. I'm an avid git user - github is my second home for all my code. Suffice it to say that I neglected to branch my trunk for this. Not only was I hoping the upgrade would be painless, I was looking to implement some features this past weekend as well, not just upgrade my Cassandra versions. Well, that went south really quick, and I wasn't allowed to work on other things until I fixed this upgrade issue. All because I failed to issue:

"git checkout -b cassie-1.1-upgrade"

I could make all my destructive changes in that branch, and continue working on other features/bugs in my project in other branches. But because I broke my branch - not only wouldn't my unit tests pass, but mostly it wouldn't compile at all - I couldn't work productively on anything else. So note folks - for major destructive work like this, ALWAYS branch.

The next phase of this project was updating the dependencies.

org.apache.cassandra:cassandra-all:1.1.2

org.apache.cassandra:cassandra-thrift:1.1.2

org.apache.thrift:libthrift:0.8.0

me.prettyprint:hector-core:1.0-5

That took care of the Cassandra dependencies for my project. But an interesting thing happened - EmbeddedServerHelper no longer obeyed the KeySpace definitions in cassandra.yaml - in order to load my schema I had to come up with another option. Thanks to the maven-failsafe-plugin, and the cassandra-maven-plugin, I can fork each of my unit tests and get a newly scrubbed/loaded/initialized schema to run my testcases against. This clearing is important, by running this way, so far I've yet to lose any data in my two-tier test-cases (Integration tests, not so much at the moment). So having an easy to use, easily document schema that could be loaded upon first server startup - that was huge - and now it was missing.

[ more to come ]

The Wonders of Github

2012-04-02T00:00:00-04:00

I'm currently working on a java project with a number of friends - my first real group project with Java. Part of the problem with what we're doing is that a number of the open-source libraries we're using do not have local maven repositories. I'm a firm believer in what maven brings to the table in terms of dependency management - so I've created a number of my own. I could put them on my own website, but I'm looking to migrate away from managing my own forge, which is currrently based on indefero. Github is one of the two major elephants in the room (the other being gitorious), so I've put them there. I think a lot of people trust github (a lot more than darthcoder.com) - so I think I've made a good choice. Ideally, these files would make it into maven central somehow, but until then I can offer my repos.

Eclipse SWT - https://github.com/ckaminski/swt-maven-repo

JGraphT - https://github.com/ckaminski/jgrapht-maven-repo

Today’s computer pet peeves…

2012-02-17T00:00:00-05:00

I know I've probably complained about this at some point in time, but I'm continually amazed at how poorly Outlook does email. I can't save embedded attachments (images, for example) unless I first cut and paste them into an external program.

Also, I HATE splash screens. Especially ones that stack themselves on top of the z-order and won't go away. Eclipse does this right - it starts and will let you float it to the background, but even that isn't optimal. What if I have an active desktop, with widgets, or I need documents and folders behind the unmovable splash screen? This new program I'm trying today, Spicebird, is the exact type of bad offender I hate. It puts itself on top of all other active windows, and wont' let you move it around. Splash screens need to be relegated to the dustbin of history, just like Windows 95, that abortion of an OS that spawned them.

Rebooting the Cloud??

2011-07-18T00:00:00-04:00

I'm chewing through my email here at work, and I see a notice that our Cloud platform (built on ESX/Surgient) is going down for upgrades this weekend, a nearly 24 hour outage of the platform. It got me to thinking - when does Amazon Web Services or Google App Engine ever shut down their cloud?

People who know me well know that I really hate technology. Not that I'm a luddite, but that most technology is actually crap - poorly engineered, prone to failure, difficult to fix. I'm in the midst of building a webapp with a Lua plugin for Adobe Lightroom, and I will have to deal with the fact that a user may install my plugin, and never update it. I may have to service version 1 of my plugin forever. My web service is the type that needs to be robust - taking the whole cloud of servers down to upgrade just isn't in the cards. I have to build my data model to be resilient - I can't change it midstream, and I can't do massive database upgrades that allow me to take the system offline for a day at a time. I must plan for cases where I can only upgrade components of my infrastructure at a time.

Things I must be able to tell about my infrastructure:

1. what I'm running and it's versions.

2. health of what I'm running

3. status of any dependencies.

Because truth be told, I must write my software and my app as if the Cloud can't be rebooted. And the fact that my day job requires this on a constant basis is borderline criminal - we should hold our software vendors to higher standards. I shouldn't put 100% of my cloud users out of commission, when I might be able to limit it to a fraction - or none at all.

Java in the Cloud - A rebuttal to TheRegister

2011-06-30T00:00:00-04:00

In an article written on the Register entitled "Oracle's Java plan trapped in last century", Matt Stephens makes the comment:

"The one feature that genuinely is vital for Java to succeed in the cloud has been pushed back yet again. Lambda functions (essentially closures) are now set to appear in Java 8 (yes, 8) - though I'll believe it when I see it."

I whole heartedly disagree. I believe enterprise Java in the cloud is here (witness Google App Engine). I feel that there is a key feature that needs to become available to make Java better in the cloud. JSR 121 - Application Isolation API.

Lazy Ways - Using Aspectj with Restlet Resources

2011-06-17T00:00:00-04:00

I'll say it - I'm Lazy. I'll say it again, just in case you missed it the first time - I'M LAZY!!! Not in the sense you might mean, but in the DRY fashion. DRY, for the uninitiated is Don't Repeat Yourself - a coders mantra that you never write imperfectly twice (even if it's quicker to do) what you can spend a smidge more time on and write perfectly once! In that vein, when working with Restlet, there are instances where you write code like:

getRequest().getAttributes().get("valuename")

While not an issue in and of themselves, this gets tedious, and I might have to do it multiple times in a RESTlet (supporting 4 methods). So I decided to use a little runtime annotation on instance fields with a parameter name mapping. My annotation looks like so:

package org.example.webresources;

import java.lang.annotation.*;

@Retention(RetentionPolicy.RUNTIME)
@Target ({ElementType.FIELD, ElementType.METHOD })
@Inherited
public @interface RestletResourceVariable {
String name();
}

Then the parameters my resource supports are codified at the top of the class definition, and are ensured to be the same across all the REST methods. Wait, wait. Just using annotations doesn't confer this capability to my class, WTF?

Well, to perform a little magic, I call in the powerful AspectJ and wield it's mighty capabilities to do compile-time weaving to intercept calls and modify my instance variables in my ServerResources from the Requests passed in. My aspect creates targets called pointcuts that are the descriptions of where my "before" interceptor functions are going to be attached - in this case the methods in my ServerResources that are annotation with @Delete, @Get, @Post and @Put method annotations.

package org.example.webresources;

import java.lang.annotation.Annotation;
import java.lang.reflect.Field;
import org.aspectj.lang.Signature;
import org.restlet.*;
import org.restlet.resource.ServerResource;
import org.slf4j.*;

public aspect RestletResourceVariableAspect {
static Logger logger = LoggerFactory.getLogger(RestletResourceVariableAspect.class);

pointcut RESTMethods() :
execution( @org.restlet.resource.Delete * org.example.webresources..*(..) ) ||
execution( @org.restlet.resource.Get * org.example.webresources..*(..) ) ||
execution( @org.restlet.resource.Post * org.example.webresources..*(..) ) ||
execution( @org.restlet.resource.Put * org.example.webresources..*(..) ) ;

before(): RESTMethods() {
Signature sig = thisJoinPoint.getSignature();
Object target = thisJoinPoint.getTarget();

Class<?> c = target.getClass();

Field[] fields = c.getDeclaredFields() ;

for ( Field field : fields ) {
Annotation[] annotations = field.getDeclaredAnnotations();
for(Annotation annotation : annotations){
if(annotation instanceof RestletResourceVariable){
  RestletResourceVariable myAnnotation = (RestletResourceVariable) annotation;
  // get matching name from request variables.
  String reqVarName = myAnnotation.name();
  // set request instance var to request var.
  ServerResource sres = (ServerResource)target;
  Request req = sres.getRequest();
  String reqVarVal = (String)req.getAttributes().get(reqVarName);

  try {
logger.info("On Class " + c.getName() + " Field " +  reqVarName + " value : " + reqVarVal );
field.set(target, reqVarVal);
} catch ( IllegalAccessException ex ) {
logger.info( ex.toString() );
  }
}
}
}
}
}

This aspect iterates through the fields on ServerResource, finds any that are annotated with my custom @RequestResourceVariable annotation. It then finds the request input attribute that matches the annotation name() property and stored that value in the ServerResource's instance variable. Then my @Get, @Post methods get the same variable - I don't have to take a chance that multiple methods are going to get difference variable/parameter names due to typos or failure to use a class Constant to document. Mistakes are eliminated, simple coding errors. And my code becomes self-documenting. The parameter names are typed to the annotation. The annotation is tied to the instance variable and the instance variable is pinned to the actual value passed in the Request object.

public class QuestionResource extends ServerResource {
static Logger logger = LoggerFactory.getLogger(QuestionResource.class);

@RestletResourceVariable(name="questionId")
public String questionId;

@Get("json")
public JsonRepresentation doGet() {
  logger.info("QuestionResource::doGet() {}.", questionId);
  QuestionRepository qr = new QuestionRepository();
  Question question = qr.getById("en", questionId);

}
}

Transparently.

Granted, there was effort involved in setting this up and making work properly (though as I think about it, I know there's a bug to fix - what if the @RequestResourceVariable annotation doesn't have a name property, it should default to the instance variable name). But if there hadn't have been the niggling runtime @Retention I forgot to add (4 hours) and the familiarity with AspectJ that I needed to re-acquaint myself with (4 hours) - what would have been a day-long job would have been a half-hours work, and saved me countless bugs. I only have to debug this Aspect once. I have to debug all my request variable access code in every method I write. Now I let the computer write correct code for me.

That's being Lazy the Hard Way.