Skip to main content

Posts

Showing posts from February, 2016

Blood-e-mail

We all hate e-mail. We all love e-mail... E-mail is like writing  a letter. There was a time when sitting down to write a letter (with pen) was an almost pleasant task which you expected to take a good hour on a rainy day... including moments of displaced thought spent staring out of the window (at this points anyone under the age of 30 is probably wondering what the hell I'm on about!). I still can (and do) waste a good hour or two writing an e-mail. E-mail is not : A replacement for conversation. The best tech solutions we have for this are  Google Hangouts , Facetime or Skype etc. or even; god forbid, the telephone (psst, don't tell the kids they can talk into those things). Ping-pong emails are just an ineffective and tedious form of conversation - even worse when they're to a cc list who mostly couldn't care less about the topic. It's morse-code compared to the telephone. If you can, get off your back-side, walk across the office and talk to them! A repla

Traceability

We can have a small server... ...a big server (aka vertical scaling)... .. a cluster of servers (aka horizontal scaling)... .. or even a compute grid (horizontal scaling on steroids). For resiliency we can have active-passive... ... or active-active... ... or replication in a cluster or grid... ...each with their own connectivity, load-balancing and routing concerns. From a logical perspective we could have a simple client-server setup... ...a two tier architecture... ...an n-tier architecture... ...a service oriented (micro- or ESB) architecture... ...and so on. And in each environment we can have different physical topologies depending on the environmental needs with logical nodes mapped to each environments servers... With our functional components deployed on our logical infrastructure using a myriad of other deployment topologies.. ... or ... ... and on and on and on... And this functional perspective can be implemented using dozens of design patterns and a plethora of integration

JBOSS Openshift Queue Deployment

Deploying to Openshift is, in theory, as simple as git push . But if you've made any changes to the app-server environment you'll find it gets blitzed on deployment (this is actually a good thing since it'll force you to get into the habits of automating deployments). To deal with this Openshift gives you the ability to define a set of action-hooks that get called during the various stages of the applications lifecycle. These are just shell scripts and are pretty easy to define - just create a file in the .openshift/action_hooks directory in the project root matching the name of the hook you want. In the case of queue deployment we need a post_start script which uses the JBOSS CLI to create queues. The script .openshift/action_hooks/post_start looks like this: echo "Starting JBOSS Queue Configuration..." ${OPENSHIFT_JBOSSAS_DIR}/bin/tools/jboss-cli.sh --connect controller=${OPENSHIFT_JBOSSAS_IP}:${OPENSHIFT_JBOSSAS_MANAGEMENT_NATIVE_PORT} --file=${OPENSHIFT_R