Saving Windows RT

I consider the release of Windows RT to the consumer market to be one of the worst decisions Microsoft has made in recent years, and I have an $853MM writedown to back me up.  RT shipped primarily on a Surface RT, which isn’t an attractive personal device—it’s small, relatively costly, difficult to connect to the usual suite of peripherals and doesn’t sit well in your lap.  Additionally, here was a version of Windows which wouldn’t run any previous Windows program.  Consumers were used to getting a new computer with a new version of Windows and simply reinstalling their favorite old greeting card maker or photo editor.  Months later, when Windows 8 was released, confusion multiplied—now there were two versions of Windows—a “right one” and a “wrong one”, and your average consumer couldn’t tell the difference by looking.  Consumers literally needed someone with technical knowledge to tell the devices apart.  Add to that an a store which had few desirable apps and it’s no wonder interest was really low for RT.  The release of the Surface 3 running only Windows 8 puts the future of RT into greater doubt.

Having said that, RT could still be one of the greatest versions of Windows of all time.  How?  Improve the concept of enterprise application stores, and make RT the next Windows Embedded.  It’s not as crazy as it sounds.  I’ve helped manage installations of WinTerms for sales teams, and hundreds of handheld and lift mount devices in multiple warehouses, and this idea is a bit of a dream come true.

Windows 8 ships with a hard-coded attachment to the Microsoft store.  Make it simpler for enterprises to set up their own internal app store, and control the store setting via group policy.  Enterprises could easily distribute their in-house apps, or those supplied by ERP/WMS/etc vendors to the issued devices.  At a previous employer—a warehousing company—we had to manage hundreds of devices in multiple warehouses around the country.  We had to have someone onsite manually dock each one, and we had to go through a complicated set of steps to update the wimpy onboard apps.  If we could have posted an updated app on our internal store and have every device update itself automatically in seconds, that would have been a dream come true.  Intermec and Symbol should be all over this idea.

Take this one step further.  Remember the fires in Tesla Model S?  A software fix to correct how the car rides at freeway speed was downloaded to all the Model Ss.  Now imagine Ford replacing Sync with RT, and being able to do the same for control or entertainment systems.  Speaking of entertainment systems. keep the linkage to the movies and music stores so movies can be downloaded while parked at a McDonald’s.  The capabilities in RT would put Ford years ahead of its competitors in regards to onboard systems.  This could be extended into on-board systems for trucks as well.

Take this one more step.  Imagine battlefield updates to combat systems, downloaded via AWACs or properly equipped drones from a secure DOD app store.  It’s not too far-fetched.

Vehicles and warehouse equipment alone offers the potential of millions of devices running RT.  By looking at RT as a new Windows Embedded, Microsoft thinks big by thinking small.

Slides for “The Data Bath” at Pittsburgh Tech Fest

Thanks to everyone who attended! You can download the slides handout at The Data Bath Handout.

If you’re a SlideShare fan, you can find these same slides at http://www.slideshare.net/rjdudley/the-data-bath.

Additional references for the SimMetrics library are at the end, but the main reference for installing into SQL Server is Beyond SoundEx-Functions for Fuzzy Searching in MS SQL Server. All the algorithms have great entries in Wikipedia.

How we did EDI via AS2 with /n software’s AS2 Connector and BizTalk 2009

Two “lives’” ago, I led the team of enterprise developers.  We did everything from the data warehouse/BI to LOB apps to systems integration.  It was good times, we kept busy.  It is an amazing company, small with people but with big revenues and big needs.  As our trading partners and services grew, we needed to significantly upgrade our EDI capabilities, including AS2.  After several months of evaluating solutions, we settled on BizTalk, because it was very flexible with EDI mapping, could multicast documents (which we needed to do), and would handle other types of messaging as well (we had a requirement for XML between several systems).  We settled on BizTalk 2009, which as it turned out had its share of issues and limitations we found out later.

One of the limitations of BizTalk’s AS2 connector is that it had to run on the same machine as BizTalk (I don’t know if this has changed or not).  This meant either having a second license of BizTalk just for AS2 (cost prohibitive), putting a production server in the DMZ (stupid) or poking a hole into our internal network (over the network admin’s dead body).  Time to find a new, simple, cost-effective solution. 

This time the decision was significantly easier.  We looked at a number of options, from hosted solutions to AS2 apps, but /n software’s AS2 Connector was exactly what we needed (they moved the current version of the connector to their RSS Bus product line, so don’t panic since the company brands don’t match).  Just to clarify, /n software’s EDI integrator is a component for building your own AS2 solutions.  The AS2 Connector is a pre-built application with most or all of the functionality you need—this is what fit the bill for us.

In a nutshell, here’s what we did:

1. Installed the AS2 Connector on a web server in our DMZ.  Since we had several web servers already, and AS2 is pretty low bandwidth, nothing additional was required here besides the SSL certificate.  Setup and config was insanely easy on our IIS box.

2. The version we used dropped all the AS2 files into one folder. To make it easy for BizTalk’s processing rules, we needed to sort them by trading partner.  The connector did have the ability to call a batch file after a receive was complete.  We wrote a PowerShell script (called by a BAT file) to read the ISA line, and move the files to a folder named for the trading partner ID.  We also had T and P folders, based on the test indicator.  This was back in 2009—I think the current version does this now without needing a “sorting hat” script.

3. On that same web server, we had a TFTP server set up.  We secured it to only accept connections from a particular IP (corresponding to our BizTalk server), and had a specific firewall route exclusive for the BizTalk server into the DMZ.

4. We scheduled BizTalk to check the folders every few minutes.  One of the downsides to this approach is that you lose BizTalk’s file system watcher capabilities.  BizTalk picked up the files via FTP and processed them per the rules we had configured.

What we ended up with was a very flexible system that was easy to expand as we brought on new trading partners, and we could meet all kinds of crazy new requirements.  We actually started to become the go-to integration partner because of how fast we could adapt to changes and the processing we could do on the received information.

Of huge importance for a couple of our trading partners we brought on later was having a Drummond Certified solution.  Fortunately, the AS2 Connector was (and still is) Drummond certified.

Something to remember that AS2 is not EDI—AS2 is just a way of transferring files.  You can send nearly any file type via AS2.

Yahoo’s CAPTCHA Broken…Is a Spam Tsunami in the Offing?

Uh oh…

The CAPTCHA security system that Yahoo, and many other email service providers adopt to prevent spam, may not be secure, according to Russian security researchers. The researchers claim to have found a way in which the security system can be compromised. This would result in a huge increase in spam coming from yahoo and other email accounts.

Full story at http://internetcommunications.tmcnet.com/topics/broadband-mobile/articles/18772-yahoos-captcha-brokenis-spam-tsunami-the-offing.htm