HTML 5 and audio tag - browser support

Having to do some unplanned development which involves audio in support of accessibility for the vision impaired.  I was pleasantly surprised when some initial prototyping (aka figure it out and get it into production yesterday) ended up working correctly early on when testing with Firefox.  When I moved onto Chrome the excitement started to fade when Chrome refused to allow replaying an audio clip.  And then the mood went further south when trying IE and finding that the HTML 5 audio tag (at least in IE 9) doesn't work with wav files.  And of course, other documentation indicated that Firefox didn't support MP3 with the audio tag - which doesn't matter much since the only format available to me is dynamically generated WAV data from a third-party servlet.


Fortunately, the 3rd party stuff is open source.  It hasn't been updated since 2009 but the good news is the underlying framework, Java Sound, now supports MP3 which it didn't in 2009 it seems.

I think I am heading down the road of reworking the 3rd party good to support MP3 at this point.  I had looked into a multitude of other possibilities and none were panning out.

• audio.js
• The fallback to Flash isn't working and appears to be related to some specific data aspects of the WAV data we are using.
• Found some thread talking about code which needed native libs which I don't really want to deal with.  Been there and done that and in our environment it would be a disaster waiting to happen.
• Found a thread talking about NestedVM which allowed conversion of native code to Java bytecode.  My quick review of this found some pretty negative items.  
• Other weird or impractical ideas which I may include/update here at some point but it is getting late.

Anyways, it looks like the Java sound api has improved and includes much more functionality now and appears to be the best option which I hope won't turn into a blackhole for my time.

Struts 2 issue

A dire emergency drove me to work on some substantial changes in in session handling and implementation of some security mechanisms.  While working on this, it became apparent that struts was not calling the execute method on some actions.  There was a good amount of logging added and not a single line was getting output.

For a brief moment, I thought I would have to immediately upgrade - it must have been a struts 2 bug. This may be the case but it was worked around.  Unfortunately, I did not have time to fully debug into struts to determine the true root cause.  The items that in some combination got things working again included:

1. Implement Action interface - we had implementations of the execute method with the correct signature but not as part of the Action interface.
2. Replace use of the old/deprecated filter with the use of the newer filter org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter
3. Wrap some code in try/catch and do some defensive coding to prevent null reference access
4. Use some API calls in a more consistent fashion so that sessions are created under more controlled circumstances.

I would love to go back and debug into the roof issue here but there is never time - part of the organizational culture.  As much as I am annoyed by the person/people responsible for instigating our issue, it has put security back into the light again (for now).  Security is not a static item and the cost of treating it otherwise is high in many ways ($, time, respect, etc). 

Beginner welding experience - Thermal Arc 211i

I have wanted to learn to weld for sometime - I have never handled one before this.  I finally broke down and purchased a Thermal Arc 211i which is a 3 process (DC) welder - TIG, Stick and MIG (gas and flux-core).  I researched welders for over a year and was finding many positive references to Thermal Arc machines.  I was originally going to get the 181i but decided that the lack of 110v support in it was enough of a differentiator to drive me to the 211i which can work with 110 or 208/220v.

Not to spoil the rest of the post but I REALLY like the welder.

I purchased the machine from CyberWeld - they had a good price- not the absolute lowest but close and I found no indications of problems with their support which was not true of a place with a slightly lower price at the time.  I received the unit pretty quickly and without any issues.  I put in the paperwork to get a free auto darkening helmet (while supplies last..) and received it in around a week which was pretty nice.  I had already picked up some cheap tools/helmet/smock/gloves from Harbor Freight as well but this is working out well - I am going to try and teach my kids a little as I learn as well.

Best features of the Thermal Arc for me:

• 110v and 220v support. 
• Wonderful value - amount of functionality versus price is great.
• Can get MIG spoolgun, TIG torch and foot control when ready
• Not outrageously heavy and has decent handholds on front & back
• Documentation is pretty good
• components feel pretty solid and of good quality
• setup chart seems close in my limited use

 Lows for me:

• The supplied SMAW rods were marked for type (6013) but not diameter.  My lack of actually checking the size wasted several hours of my time, caused some heartburn and almost resulted in an unnecessary support call.  I was trying to verify things were working by welding a small piece of scrap but was using too low of an amperage for the rod and couldn't get a spark.
• Maybe a minor low that the MIG gun trigger is pretty sensitive.  I may have to just find some less bulky gloves.

My first actual project was to create a second lower wood loft for my spare wood, piping, etc in the garage.  I was making this out of angle iron, 1/8" flat stock and 1" square tubing using .035" flux core MIG wire.  Setting up the 4" spool was somewhat challenging to me - don't try it when you are tired already.  There is a fairly strong spring you must work against to attach the spool - a bit of an Abbott and Costello type comedy action going on for a little while.  I'll spare everyone the details for now.  I do wonder whether it would have been easier getting the large 12" spool on - maybe try someday.  As a side note, I picked up some Bosch  metal cutting bits for my jig saw and that worked really well for this project.  My welds so far are quite ugly - lack of skill/experience and the flux core combined make that unavoidable. 

I think getting the spool tension and such just right is a bit of an art form.  One of my first weld attempts resulted in the wire punching into a piece of flat stock hard enough to pop it loose from the welding magnets I had holding it in place.  This was after I got the helmet settings to the point that all light wasn't blotted out completely when the arc was going.  I'm starting to get more comfortable with the helmet and feel I can get down to what some of the books/manuals state as a recommended shade value for the helmet.  I was able to see the weld pool to some extent on my last welds but couldn't see far enough ahead to tell when I was about to run off of the object.  Nothing like going along fine and then having 4+ inches of wire hanging out in space.  At which point you bump the target object and make a mess.. not that I know anything about that.

This loft was a success and I have some new steel studs I am going to use for my overhead loft which is currently attached to the garage ceiling at the outside corner (no pole to floor).  I am going to switch from ceiling attachment to a pole (steel stud)  - I am getting a bit concerned about the weight I have up there possibly causing issues with the ceiling/wall.

Planning on looking for some steel later this week to try and build a welding cart.  Seems like a good way to practice.

All in all, the Thermal Arc 211i is a really nice machine and much more capable than I am for now.  Looking forward to practicing and learning TIG as well.  I may try the SMAW process a bit as well but my first successful attempt at that was not nearly gratifying as using the MIG gun.

[Edit 2014/02/25] Welding cart/table 3/4 "complete".. a bit of a joke since just like computer software, there is always "one more thing" you can add or change.

Summary of cart/table:

• 18" x 30" main cart top with ~ 18" x 36" base
• height adjustable folding side extension 18" x 36" - folding extending legs with pins to lock extension
• 1 drawer [side]
• 3 extendable/removable hanger poles - general hanging needs but also thinking about using with welding blanket for special needs

construction

• 1/4" plate for tops
• 1" tubing & 1/4" thick angle iron for the basic frame.
• spare pieces of "super strut", angle iron, a smidgen of flat bar for the folding/height adjustment aspect of the extension table. The super strut pieces form a guide for 1" tubing which slides up/down where the extension and main cart meet.  The tubing is too small for the super strut cavity so a small piece of flat stock was hand fitted and welded to the tube so that it doesn't rotate, etc when changing the height.  I might try to add a diagram showing this at a later date - a bit hard to describe.
• The drawer body is 20ga steel.  Using some slides from Lowes which are ok..  Some angle iron and 3-4" wide bar stock are welded to the bottom of the cart top.  I attached the slide to the flat stock with rivets.  I also attached the drawer body to the slide with rivets.  I almost hate to describe the drawer body because folks will probably fall down laughing.  Anyways, just think of it as Christmas present wrapping.
• Cart bottom is 20ga steel
• The poles are 3/8" stainless steel which slide in short pieces of 1/2" tubing with a piece of nail in a through-hole supporting them when raised. [NOTE: Practical example of knowledge - the stainless is not magnetic so the magnetic pickup was useless - not fun when you know you must cleanup WELL so the kids don't run through it with bare feet!]

This was really an experiment and nothing like a production design.  It won't win any awards (although my kids said maybe an "ugly weld" award might be possible).  I did learn a lot and the result is extremely useful even with a few warts here and there.

Todo:

• add 2 more drawers [on front] - still experimenting as I create these without any reliable tools for bending.
• add 1 more extendable/removable hanger pole
• Modify rear base area to support Argon/CO2, etc tanks [flat plate as bottom and add straps]
• Replace current rear casters with something larger and easier to roll over transitions between the driveway/garage/sidewalk.  This will be even more important once I have shielding gas tanks.
• Considering making the extension table a little more flexible in height adjustment by using cam levers [search 'cam lever' on Grainger] on the legs.  Trying to determine if they can handle a reasonable amount of load from hammering and such on the table top.

Here is the "final" cart; I don't think I am going to add argon/co2 storage to this since it has gotten extremely heavy.  The only other "someday" change is better height adjustability of the side folding/extension table.

I'll have to start dreaming up plans for handling argon/co2 tanks sometime.  I would love to try some TIG work  but I think I exceeded my hobby budget for "a while".  I only have DC TIG capability so while it is possible to work with aluminum per a bit of research; it looks like the results won't be as clean and it may take more effort to get even "reasonable" results.

Linux/Unix application configuration methodology

We are experiencing substantial application sprawl at my current employer while staffing either stays stable or decreases.  The combination of 9-5 normal development/operations/support combined with more after hours time for production operations is leading to increased human error and general difficulty in managing the movement of application & settings between dev/test/prod environments.  A contributing factor is the fact that each application has a slightly different method of handling configuration data.

This lack of a standard template and methodology for handling configuration was not sustainable.  This lead me to identify a number of core issues and work toward a process the mitigates them.  Some common problems include mismatches of configuration data between servers in a specific environment, changes not getting propagated between environments and incorrect configuration propagating between environments.

The mitigation methods include:

• Use of a source control system (Subversion) to contain all application configuration/settings data.
• Configuration files named based on server name/environment - typically for properties files
• Spring XML configuration files keyed by environment
•  Environment setup broken out into up to 3 distinct files - one for each of application, server and environment.  These files are named based on the type of data.  The general idea here is that application wide settings reside in a shared application wide (all server, all environments) file.  Any environment specific profile setup is in a file named based on the environment type.  Each server has a file based on the server name and is primarily responsible for setting the environment type.
• A shared profile processing driver that each server uses to "source" the appropriate configuration files.  There are some utility functions shared between all systems. The application wide environment setup profile plays the role of the driver and used the utility functions to process the server specific environment profile first, followed by the environment specific profile and finally completes its processing of the application wide environment settings.
• Utility functions include an item which displays the server name, application name and environment type.  This is called at login and is available to operators to quickly verify they are operating on the system they expect to be on.

This methodology is combined with the use of NFS in production and sometimes non-production environments.  There is an additional benefit of this combination in the production environment.  There is no direct network server to server communication between the production and disaster recovery (DR) environments but the production NFS storage is replicated to the DR site.  By including all DR environment settings/configuration on the production NFS storage, it automatically gets replicated out to warm DR servers.  Some additional shell scripting, a couple cron jobs and a standardized but special app deployment method result in the ability to have the DR application/web servers automatically deploy the production application versions in an unattended fashion.

I am still evaluating this mechanism in combination with Jenkins jobs and remote nodes for a more automated production deployment. 

Overall, there is a little learning curve for my team but this is already providing some benefits including traceability of change, identification of unapproved changes (run Jenkins jobs which check for correct versions of settings and local server modifications) and easier difference identification/handling via Subversion diff/merge functionality.

One other item of note is that the Subversion "externals" functionality is somewhat key in the sharing of some items which need to be available to all applications but would be awkward to manually synchronize or duplicate.