You may be familiar with Google’s policy that each employee is granted 20% free time to pursue their own interests. Some projects become real Google products like GMail, Google News, Google Talk, and AdSense.
Google has nearly infinite resources, and with thousands of talented developers trying so many things, once in a while one of them is going to be a winner and create a major new revenue stream.
Obviously, TrackAbout does not have infinite resources. But we admire the spirit of Google’s free time policy and would like to emulate it to the degree we can.
This came through a Google News Alert I have set up. It might be of particular interest to our customer base. TrackAbout’s tracking system is what I like to call “tag agnostic”. Be it 1D or 2D barcodes, RFID tags, QR-Codes, you name it, we’ll scan it.
We are in the process of migrating our disk from one SAN to another. We are in the enviable position of having both SANs available to our Microsoft SQL Server 2008 R2 SP1 cluster at the same time. Our SQL Server instance is not virtualized.
I began working on a process to migrate all our databases with as little downtime as possible. I imposed the “as little downtime as possible” requirement on myself to see if it was possible to migrate this data with no downtime whatsoever. I time-boxed my efforts to about 3 days of intermittent work (when I could steal the time). Technically, our customers would be fine with a little bit of downtime outside of business hours, but I wanted to challenge myself and see what I could come up with. Continue reading →
TrackAbout will be performing quarterly scheduled maintenance starting at 12:00 AM Eastern Daylight Time (04:00 UTC) on Saturday, July 7th, 2012.
We are installing operating system and database patches and updates.
Due to the redundancies built into our services, we don’t expect much in the way of service interruption. There may be very brief periods of temporary unavailability.
Chief Technology Officer
This press release just came over the wire from Motorola Solutions. It should be of general interest to our customer community. I don’t have any details other than what the press release says, so hop on over there and get the skinny.
I recently contributed an editorial to the industry print and online periodical gasworld. They asked if I could compress my recent 3-part blog series on rugged enterprise devices down to a single article.
Here’s the article. Enjoy!
In a previous post, I mentioned a rugged Android device called the Trimble Nomad, introduced in 2009.
One of the manufacturers, SDG Systems, in partnership with Juniper Systems, just announced a new device, the Rampage 6. Here’s the press release from Juniper’s web site. The device should be available in Q3 2012.
The Rampage 6 will run Android (AOSP) 2.3. It’s not the latest version of Android (4.0.4 as of this writing), but rugged hardware rarely runs the latest version of any OS.
The Rampage 6 sports a 5.7-inch display, IP67 ratings for ingress protection, an 806MHz processor, 256MB of RAM and 4GB Flash memory. An optional 1D/2D barcode scanner is mentioned. See the site or press release for the rest of the specs.
A bit of research reveals that the Rampage is probably the same exact hardware as the Juniper Mesa Rugged Notepad, released last year, except the case color is gray and the OS is Android.
Flowgistics GmbH Flowtouch Compadion and Speedmaker
Last week, I was contacted by a representative of Flowgistics GmbH from Berlin, Germany, who had read my previous blog posts regarding rugged enterprise hardware.
Flowgistics has created two unique and innovative shells, one of which encases an iPod Touch, and another which encases an iPad. Both provide ruggedness and bar code scanning capabilities. I am told the bar code scan engines are made by Motorola Solutions.
The Flowtouch Speedmaker encases the latest iPod Touch model. It is shown on their web site as being worn on the arm, attached to a neoprene sleeve using Velcro. An innovative feature is the ability to fire the bar code scanner by tilting one’s wrist.
The Flowtouch Compadion encases an iPad 2.
The Flowgistics web site and marketing materials claim that the Speedmaker is rated IP65 and the Compadion is rated IP67. When I requested evidence of testing, I was told the testing had not yet been completed but was scheduled for July 2012. The company told me that in their own testing, the Compadion survived being immersed in water beyond 50 cm (19.69 in.) and was dropped from a height of more than 120 cm (around 4 feet) to concrete 100 times. No claims were made for the Speedmaker. They had no plans to investigate MIL-STD testing until I mentioned it, but said they would investigate the cost.
I found the specifications sections on Flowgistics’ site a little confusing. They have mixed the specs of the underlying iOS devices with the specs for their custom shells, as though they are sold together as a packaged unit.
Overall, Flowgistics was very open and I thank them for answering my questions.
Flowgistics has let me know they are looking for customers and partners in the US.
We’ve been having a rough couple of days here in IT land. We experienced two unexpected outages of our service in as many days. Every failure is a chance to learn something, so I’m going to talk about what happened and what we can do better going forward.
But first, the non-technical executive summary:
Non-Technical Executive Summary
Tuesday: Between 11:13 AM and 11:22 AM Eastern US Time, we experienced a system slowdown and then a brief service outage. Our database server had a hardware failure, in which half the available memory was missing. We switched to our redundant database (we operate a database cluster), and after that everything was fine. The failover took just a couple of minutes.
Wednesday: Between 4:53 PM and 6:45 PM Eastern US Time, we experienced a system slowdown, then a brief outage for some customers and an extended outage for other customers. The root cause was completely different from Tuesday’s issue. On Wednesday, the Storage Area Network (SAN) on which our services rely experienced a degradation of service which slowed everything down. We mistook this for a database failure, and opted to fail over to our newly rebuilt database server. The failover did not solve the problem. The SAN’s slow disk issues meant that many of our largest customer databases took a very long time to pass the necessary automatic consistency checks which follow a failover before they came online. By 6:45 PM, our hosting provider had resolved the issue with the SAN and performance returned to normal.
Now, on to the details and the lessons learned.