Archive for February, 2013

Military mobile app teaches you how to remain calm under fire

The mobile app Tactical Breather developed by the military to train soldiers to remain calm in life-or-death situations has a familiar mantra:

Tactical Breather“I will not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain.” — Frank Herbert, Dune

It turns out that you don’t need to be a eugenically engineered Bene Gesserit monk to learn amazing levels of self-control.  Through repetitive practice and training, anyone can learn to gain control of your heart rate, emotions, concentration, and other physiological and psychological responses to your body during stressful situations.

Although these techniques were developed primarily for the warfighter during intense combat situations, anyone can benefit from the ideas taught in this application to help with nearly any stressful situation in life.

The app teaches you the deceptively simple 4-4-4-4 breath technique.  Inhale for count of 4, hold count of 4, exhale count 4, hold count 4, repeat.  This will trigger a relaxation response within seconds, but more importantly as you practice this technique over days and weeks, it becomes an automatic reflex for stressful situations, like dealing with production outages or screaming toddlers…I mean screaming users.

Download the free app on Google Play to learn military-grade Bene Gesserit skillz.


Having recently migrated our database server, I’d like to acknowledge the staff that helped make this transition go as smoothly as possible.  There’s a great deal more to a database server migration than simply pointing the database migration tool to the new drive location.

In particular, I’d like to acknowledge the janitorial staff for vacuuming in the server room before the new server hardware was installed.  Ensuring a minimum of dust in the new environment is critical to the continued success of the performance of the hardware as well as the health and safety of the IT staff.  I can not overemphasize the amount of work that went into achieving this goal.  You can literally eat off the floor of the server room, good work Benny!

Going forward, we are endeavoring to automate this process, freeing the cleaning staff to focus on higher level janitorial tasks, so we have authorized the purchase of a Roomba 9000.  Made by iRobot, this state of the art robot uses military grade artificial intelligence to seek out and destroy dust bunnies wherever they may congregate.  Working 24/7 it will ensure an immaculate server room environment maximizing shareholder value for generations to come.  We named it “Skippy”.

I’ve learned a lot from this process.  You may never have migrated a database server before, but there’s more to it than just copying files.  The new server comes with a great deal of packing material that must be disposed of in a proper manner.  The amount of styrofoam blocks alone is truly staggering, reducing the efficiency and effectiveness of IT support staff by blocking movement about the workspace.  Even after the packing material has been laboriously removed, little bits of styrofoam often remain, flitting about the server room sowing chaos.  This is where the new Roomba really pays off, seeking out every last fleck of styrofoam and removing it from the environment completely.

Going forward, we are in the process of drafting  a policy that requires new server hardware to be opened outside of the server room.  This may reduce the efficiency of future server installs by requiring more steps to be taken to place the actual server hardware, so an offsite management workshop summit in Dubai is planned for next March to analyze the issue.  Benny will keep you informed of it’s progress.

Once again, good work team, you’ve all done very well.

Documentation best practices

Here are some thoughts about documentation, including guidelines and best practices on documentation of code, defects, and application usage.

Code Documentation

I’ve worked in a lot of different development teams at a lot of different companies and I can say that no one even tries to create hard rules around documentation of code for developers.  Mostly it’s because it’s so subjective, but also because it would be so hard to enforce.  However, a general guideline or “best practices” for code documentation would include:

1)  Use meaningful variable and property names (i.e. call a variable “agency”, not “a”;  call a property “DependentService” instead of “ds”, etc.)

2)  Use meaningful method or function names instead of code comments.

For example:

public void GetDependentServiceForXYZService()

instead of

// get dependent service for XYZ service
public void GetService()

3)  Don’t add pointless, redundant, or obvious code comments.

Example 1:  Don’t do this:

// get dependent service for XYZ service
public void GetDependentServiceForXYZService()

Example 2:  Don’t do this either:

// set agency to null
agency = null;

3) In general, only add code comments for anything that’s may seem out of the ordinary or that you yourself as the developer may cause you to get confused when you look at your own code 6 months from now.

Defect Documentation

Documentation for requirements and defects found in QA testing will need to be much more strictly enforced because there are certain things everyone (developers, testers, acceptance managers, etc) need to know to replicate, fix, and retest the issue.  Things that would need to be known for documenting a defect include:

1)  What screen was the error seen?

2)  Steps for reproducing the error

3)  What environment was the bug found?  (i.e. dev, qa, pre-prod, acceptance, production, etc)

4)  Date it was found

5)  Version of the code it was found in

6)  Who the bug is assigned to for fixing, who should it be assigned to for re-testing, etc.

7)  Screenshots of the error would be nice

All of these can be easily enforced with a bug tracking tool like Remedy, TFS, etc.

User Documentation

Documentation for using the application is a different ball game.  There are definitely no rules here, every company and every app had different requirements for user manuals.  Usually acceptance managers/testers, business analysts, and QA testers are (a lot) better than developers at documenting how the app is actually used by the business.  Usually help links/popups are best for documenting an app because no one reads the manual.  If you have a really complex app, you may need to hire a tech writer/trainer to document everything for you.  Short videos of how to use features or complete tasks with the app are awesome (they’re also much appreciated when learning linear algebra

Nano drones now on the battlefield

Black Hornet nano drone

Teeny tiny drones have been deployed to British troops on the front line in Afghanistan.   They are the first to use the state-of-the-art handheld tiny surveillance helicopters, just 10cm long and weighing 16 grams, which relay reliable full motion video and still images back to the devices’ handlers in the battlefield.

Soldiers use the Norwegian-designed Black Hornet Nano Unmanned Air Vehicle to peer around corners or over walls to identify any hidden threats and the images are relayed to a small screen on a handheld terminal. The mini drones can be piloted directly or programmed to follow co-ordinates using GPS.  Powered by battery, the Black Hornet is reported to have a range of about half a mile (800m), a top speed of 22mph (35kph) and can fly for up to 30 minutes.

Coolest RC helicopter EVAR!

© 2018 Robert Corvus