Off topic perhaps but entertaining and inspiring...
[ted id=2441 x=640 y=360]
2016/02/18
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:
We all hate e-mail. We all love e-mail... No, scratch that. E-mail is rubbish and should be relegated to the same historic status as letter writing. Occasionally nice to receive but quaint and you'd rather not spend your time writing them... It's time to abandon 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 replacement for instant-messaging. IM deserves more credit than it typically receives and in many organisations is a fundamental necessity to improve communication. You should be ashamed of yourself if you use e-mail this way! IM is quicker, simpler and crucially doesn't fill your day with a tonne of "in-box" items you'll never get round to. And if you're only experience of IM is Lync.. you need to get out more.
- A replacement for group conversation. Get a room for god-sake! Co-location is the #1 solution for group communication. But if you can't do that (and don't give in, fight for this as it will revolutionise your working life) then many tools are available to ease comms over a distance. Many of these; Slack notably in my experience, can be truly engaging for group conversations.
- And the cherry on the cake... a replacement for documentation. If you think that sending an email with detailed information counts as "documentation" then you deserve to be taken outside, strapped to the stocks, de-trousered, painted in pigs-blood and have your children forced to throw a variety or spoiled food products at your sorry carcass till their tears run dry. Put it in a wiki or a teamroom or in a document on a file-system - I care not which. But stuffed in the crevice of some email chain where it's neither obvious or available to those that need it only serves to deter the distribution of knowledge, increase confusion and encourage chaos and entropy to thrive. If your organisation works this way then your organisation is likely living off institutionalised knowledge which may walk out the door tomorrow.
We all hate e-mail. We all love e-mail... No, scratch that. E-mail is rubbish and should be relegated to the same historic status as letter writing. Occasionally nice to receive but quaint and you'd rather not spend your time writing them... It's time to abandon e-mail!
2016/02/13
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 patterns.
With each component implemented using whichever products and packages we choose to be responsible for supporting one or more requirements and capabilities...
So the infrastructure we rely on, the products we select, the components we build or buy; the patterns we adopt and use... all exist for nothing but the underlying requirement.
We should therefore be able to trace from requirement through the design all the way to the tin on the floor.
And if we can do that we can answer lots of interesting questions such as "what happens if I turn this box off?", "what's impacted if I change this requirement?" or even "which requirements are driving costs?". Which in turn can help improve supportability, maintainability and availability and reduce costs. You may even find your product sponsor questioning if they really need this or that feature...
...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 patterns.
With each component implemented using whichever products and packages we choose to be responsible for supporting one or more requirements and capabilities...
So the infrastructure we rely on, the products we select, the components we build or buy; the patterns we adopt and use... all exist for nothing but the underlying requirement.
We should therefore be able to trace from requirement through the design all the way to the tin on the floor.
And if we can do that we can answer lots of interesting questions such as "what happens if I turn this box off?", "what's impacted if I change this requirement?" or even "which requirements are driving costs?". Which in turn can help improve supportability, maintainability and availability and reduce costs. You may even find your product sponsor questioning if they really need this or that feature...
2016/02/01
JBOSS Openshift Queue Deployment
Deploying to Openshift is, in theory, as simple as
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
In the case of queue deployment we need a post_start script which uses the JBOSS CLI to create queues.
The script
Make sure the script is executable via
The use of various environment variables ensures the script will work regardless of the configuration the image fires-up with and the "echo" commands ensures some sort of output is dumped to stdout during push for confirmation.
This script references a cli script (cli/create-queues.cli) looking like this:
And hey presto! On deployment you'll see a couple of messages output showing:
And if you tail the logs (
Finally the JBOSS console will show your queues in all their glory...
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_REPO_DIR}/cli/create-queues.cli
echo "JBOSS configuration complete!"
Make sure the script is executable via
chmod +x .openshift/action_hooks/post_start.The use of various environment variables ensures the script will work regardless of the configuration the image fires-up with and the "echo" commands ensures some sort of output is dumped to stdout during push for confirmation.
This script references a cli script (cli/create-queues.cli) looking like this:
jms-queue add --queue-address=queueA --entries=queue/QueueA
jms-queue add --queue-address=queueB --entries=queue/QueueB
And hey presto! On deployment you'll see a couple of messages output showing:
remote: Starting JBOSS Queue Configuration...
remote: JBOSS configuration complete!
And if you tail the logs (
rhc tail -a ) you should see confirmation of the deployment as below:
2016/02/01 16:57:57,641 INFO [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-8) trying to deploy queue jms.queue.queueA
2016/02/01 16:57:57,644 INFO [org.jboss.as.messaging] (MSC service thread 1-8) JBAS011601: Bound messaging object to jndi name java:/queue/QueueA
2016/02/01 16:57:57,738 INFO [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-8) trying to deploy queue jms.queue.queueB
2016/02/01 16:57:57,740 INFO [org.jboss.as.messaging] (MSC service thread 1-8) JBAS011601: Bound messaging object to jndi name java:/queue/QueueB
Finally the JBOSS console will show your queues in all their glory...
Subscribe to:
Posts (Atom)