What's the difference between a cat and VB6?

Answer: A cat only has 9 lives.

The “It Just Works” compatibility for Visual Basic 6 applications will guarantee VB6 lives at least through the full lifetime of Windows 8, 10/01/2023. Visual Basic 6 first shipped in 1998, so that will make it's applications at least 25 years old before they see the end of supported lifetime.  Compare that to applications written for the early version of iOS or the Microsoft .NET Framework 1.0 release in 2002, which is incompatible with Windows 7 release in 2009.    

This seems strange when you consider that all versions of the Visual Basic development environment from 1.0 to 6.0 have been retired and are now unsupported by Microsoft. In fact, it's difficult to find a copy to install in the event you need one.  The required runtime environments are unsupported too, with the exception of the Visual Basic 6 core runtime environment which as stated above is supported through the lifetime of Windows 8.  What's even stranger is that many third party components that developers used to make their applications richer and easier to use are no longer available or supported. 

The main reason Microsoft won't kill the unkillable is that there are too many business applications out in the market that have yet to be upgraded to a modern language and technology.  If they release an OS, like Windows 8, and didn't support the VB6 runtime, many businesses wouldn't and couldn't buy it, because their applications would break. 

Microsoft is shackled by the incredible success of VB6, having to make concessions in how far they can go in technology shifts for a particular OS update.  See the Windows 8 Desktop where all legacy applications run outside the new modern looking Metro Suite.  Microsoft has also made many missteps in handling the VB6.  Rather than bring the VB6 code base along with incremental changes and upgrades to support new versions of the operating system, like Apple does with both iOS and OSX, Microsoft waited and tried to force a complete rewrite with the introduction of .NET, in a different language to boot (VB.NET).  This just doesn't work for an obviously change resistant customer base.  

VB6 is going to be around for a while but it won't be around for ever, 25 years might just might be enough.  Any reasonable business or ISV should consider moving their business applications from VB6 to some other language and technology.  

Forget the VB6 cult perspective I would venture to bet that any application currently in VB6 is running into issues on several fronts.  First it is probably getting harder to find software engineers to work on the application.  Look at this graph roughly representing the popularity of VB6, it looks like the heart monitor of a dying patient.

Click here to visit page...

Second it is probably becoming more difficult to add meaningful features/ui to the application because of the lack of support 3rd party world, practically no one develops or maintains, much less creates new VB6 widgets or components.  Third, your application is not enjoying a favored nation status anymore in the current desktop OS Windows 8.  Sure you kind of blended in through Windows 7, even though the application looked different when it launched, now you launch in a separate  area provided specifically for the legacy applications like you.  Finally the gap between your application and current application technology is starting to look like the Grand Canyon, ie what is your mobile strategy with VB6?

If you are looking for an innovative way to transpose your VB6 applications check out GizMox, I am looking into them now will let you know what I find out.

Look Mom No Coding

Creating Websites without Coding 

There are several sites on the market that enable anyone to create a web site, yes even users that have no idea what HTML is and think java script is a dialog over coffee.  Here's a Clipset on Meaki of some of the most popular vendors.  Recently I put one of these sites to work on a volunteer project.  The goal of the project was to update and expand the usefulness of McLean Youth Athletics Association web site. I am a on the Board of MYA which has the simple but important goal of enabling any youth that wants to play a sport in the McLean Community to be able to play that sport by providing the foundation and support for sports leagues to form and thrive.


The vendor I chose is named Moonfruit . Moonfruit is a UK-based web hosting company. They employ a website construction tool called SiteMaker, which is designed to make website development simple without sacrificing on design or functionality.

The tools is polished and has a rich feature set.  You can start with a wide range of clean, modern predesigned templates and use the drag and drop tools to build your site.

 There are some really nice social features in the tool set and if you know a little about embedding and HTML you can add HTML Snippets which opens up another world of possibilities.

 
A benefit of using a tool like this rather than hand coding it yourself or outsourcing the work is that the tool implements the latest best practices and technology when it publishes your website. You design your site the way you want it and the very qualified engineers at MoonFruit make sure it is published correctly for web, mobile and social targets. That's right, mobile and other form factors.  MoonFruit automatically creates a mobile optimized version of your site,   and can even push your site into Facebook with just a few clicks.

The MYA site isn't finished yet, there may be broken/incorrect links etc., we're still testing and the url is still at MoonFruit,  but it provides an example of what a tools like MoonFruit can help you do in a few hours of work.   Here is the old site and here is the new site built using MoonFruit.

Health Care and Mobile Devices

When wealth is lost, nothing is lost; when health is lost, something is lost; when character is lost, all is lost.

- Billy Graham

Regardless of where you come down on the Health Care Debate, there is no debating that the advancement in mobile networks and devices will have a significant impact on the Health Care Industry.

Sprint Nextel CEO Dan Hesse made the case at the annual conference of the Healthcare Information and Management Systems Society on March 1.

Today, on a planet of 6.8 billion people, there are more than 4 billion active cell phones—more mobile phones in the world than TVs, PCs and cars combined. The cell phone is the most rapidly adopted technology in the history of this planet... High mobile phone penetration provides an incredible opportunity for us to work together to improve health care and health care access, regardless of location, age, gender or disability.

Mobile devices may be on their way to replacing the characteristic stethscope hanging from every doctors neck or pocket. Today 64% of U.S Physicians use smartphones and is expected to reach 81% by 2012 according to the health care consulting firm Manhattan Research. With the introduction of iPhone 3.0 OS just over a year ago Apple set the stage for increased penetration of the iPhone into the Healthcare industry. Features included in that release made this possible, such as the External Accessories API, allowing external accessories to interface to the iPhone via the dock connector or wirelessly over Bluetooth. Apple used a blood pressure cuff as an example so I guess the stethoscope analogy isn't that far off.

In fact, Apple seems to have always had it's eye on the Healthcare market, partnering with Dr. Geoffrey Rutledge, chief medical officer for Epocrates Inc., to reformat a huge medical database into a downloadable app known as Epocrates RX, before the iPhone was even launched. Today, Rutledge claims Epocrates RX is used by one in five U.S. doctors as a drug reference and to prevent interaction problems between a patient’s multiple medications.

In India, the iPhone is being used to cure a disease called Retinopathy of Prematurity (RoP), an eye disease that affects thousands of prematurely born infants and can cause blindness if not swiftly treated. This type of disease is especially a problem in countries where there is a lack of adequate facilities, long distances to travel, illiteracy and low accessibility to quality healthcare. Laboratory assistants take pictures of the retinas of prematurely born babies and transmit them via broadband to pediatric eye surgeons, many times hundreds or thousands of miles away. The surgeons, use the iPhones high resolution graphics and pinch-and-drag capabilities combined with special software to diagnose and then determine treatment.

Currently there are hundreds of mobile applications in the AppStore's "Healthcare and Fitness" category available to businesses and consumers. Many more applications will be needed by the growing Healthcare Industry. Device manufacturers are improving their operating systems and SDKs to appeal to application developers designing tomorrows Healthcare Solutions.

A few application areas that apply to Healthcare include:

• Medical Spanish or Medical translation capabilities so doctors can communicate with Foreign language-speaking patients
• Fast medication facts, alternative medications, multiple drug interaction data, health plan insurance guidelines on medications.
• Remote diagnostic and treatment recommendations, bringing Healthcare to the patient.
• Receive and analyze laboratory test results.

The iPad, where I thought it might fit...

The Matryoshka Doll

Sometimes products aren't as good as you might imagine they will be from the pre-release hype and rumores that precede their official launch. I was thinking this the other day about the iPad and the difference between what I thought it might be, and what it turned out to be.  And thinking more about it, it would have been more appealing to me, if it had been what I thought it might be.  Don't get me wrong the iPad is a phenomenal product and it's launch a runaway success but I thought it was going to be something much more. 

I thought...it might be a device that had a more appealing fit between the iPhone and the Mac notebook, both of which I owned at the time of the iPad's announcement.  More specifically it would follow the "nested doll" or  "matryoshka" design principle. 

This design pattern describes an "object-within-similar-object" and appears in the design of many natural and man-made objects. For something like the iPad sitting between the iPhone and the Mac notebook this would be extended to be an "object-within-similar-object" with added inheritance/leverage of the embedded object. 

So what if the iPad was a middle doll in a matryoshka doll set. What if the iPad served as the 15/17 inch screen of a Mac Air, Mac Book or Mac Book Pro notebook when it was embedded. It would have all the features it has today in it's standalone state but it could also embed into  the Mac notebook and serve as the screen. When it was docked the combined object would use the Mac OSX and all the applications and you could use the Mac keyboard.  All all the resources (folders, documents, contacts etc.) on the iPad would be available to the Mac notebook and potentially applications written for the iPad would be available also.  When it was undocked the iPad would run on the iPad OS and function as a standalone iPad. 

This would allow you to select the form factor that made sense for the task as hand.  If you wanted  to goto a meeting or you were on the run or you were sitting around the house and wanted to surf the internet or check your email you might just grab the ipad (the screen) from the notebook and leave the rest behind.  For more serious work requiring a keyboard and a more powerful operating system and applications (OSX versus iPad OS) you would plug the screen back in and use the Mac Book as a notebook. 
Taking this a step further to the smallest doll, the iPhone, what if the iPad had a docking station or slot where the iPhone could be inserted completely.


So when you inserted the iPhone into the iPad you could make phone calls/use telephony from your iPad or your Mac Book. Using Internet Tethering would be seamless as well. Of course each device would sync data and portable applications when nested.
In this model there is a clear fit for the iPad in the form factors, and it would have been much more appealing to me, as an iPhone and Mac Book Pro owner.
Anyway that's what I thought.

Waiting for Moore's Law Work

Reading the "Mobile Web Application Best Practices" a W3C Recommendation from 14 December 2010, I was struck by the similarity of the resource management challenges faced by early Personal Computer developers and those faced by mobile device developers today.


Here are some of the best practices for early PC Development that are arguably non-existent today.

Keep programs small (especially true for the Basic Interpreter, and then compiled programs that had to be shipped and installed on Floppy Diskettes. Smaller programs loaded and ran faster. Later with overlay managers it was important to optimize overlay segments for application start-up time.

Use memory very, very efficiently. First there wasn't much of it, and later when there was more, memory management and disk swapping caused performance issues, especially when multiple applications were running.

Keep your code footprint small. Early on this even meant keeping your variable names very terse (x,y,z were good candidates), there were even utilities that would convert your code before compile and reduce your nice long readable variables to terse variants.

Optimize the User Interface to be responsive or at least appear to be responsive to the user. This meant coming up with strategies to improve performance or at least hide slow running tasks, and when all else fails put up the hour glass and appear responsive.

Here are some of the best practices for mobile development from the W3C, "Mobile Web Application Best Practices".

Use Cookies Sparingly - information stored in cookies is sent to the server for every request and so using them for excessive amounts of data can negatively impact performance on a mobile network.

Use Transfer Compression - compression like HTTP 1.1 compression, which uses the gzip and DEFLATE algorithms which are widely supported, reduces bandwidth of each payload and increases transport efficiency. But...decompressing and compressing use up time and battery so this is a balancing act/ Alternative compression formats (such as EXI [EXI]) may be worth looking into.

Minimize Application Data and Size - obviously the smaller the better, faster downloads and execution time.

Minimize Perceived Latency - device limitations can lead to latency in page views, page reloads can frustrate even the most patient user.

As you can see we seem to be faced with similar resource management challenges as those faced by developers of the early PC. But why is this? Are we waiting for Moore's Law to raise all ships in Mobile Bay. Remember Moore’s Law?, named for Intel co-founder Gordon Moore, states that the number of transistors incorporated in a chip will approximately double every 24 months. That rate of progress means that the semiconductor industry will far surpass that of nearly all other industries over time, or from the flip side, other industries can't keep up. So the mobile device as a system, with components from several industries, batteries, network towers, displays, is going have resource management challenges and limits to growth directly related to the slowest advancing component.

We saw this with the PC, the integrated circuit was only one component of the overall system. And until recently we had some really, really fast computers with some really, really big monitors, that took up most of a normal size desk, now we have smaller, flatter monitors, we even have entire PC's the size of the old monitors.

The mobile device is more than the integrated circuit and it is experiencing the same disproportionate growth of it's individual components. Although if you look at the first "smartphones" you would have to agree that the iPhone in totality shows an amazing evolution in a short period of time. But you would also have to agree that certain components and sub systems are not as impressive in their rate of advancement and this can be seen in the familiar resource management issues mobile programmers are faced with today.

Looking Back...BP Oil Spill and Mobile Devices

The BP Oil Spill is a disaster of epic proportions. Responding to the disaster has required innovative minds to use all available technology to craft quick and effective solutions. It's interesting to note some of the solutions that have been crafted using mobile technology.


Oil Spill Crisis Map

The Oil Spill Crisis Map was created using the Ushahidi, a free open-source software created specifically to enable people with cell phones to contribute during a crisis. Ushahidi, which means "testimony" in Swahili, was initially developed to map reports of violence in Kenya after the post-election fallout in 2008. Students at Tulane University in conjunction with the Louisiana Bucket Brigade have used Ushahidi to give the citizens of the Gulf Coast a voice to give testimony on the how the Gulf oil spill is impacting their lives and environment.

Reports can be made in four ways:
1. Send a text message or call (504) 27 27 OIL (7645),
2. Send an email to bpoilspill@gmail.com
3. Via Twitter with the hashtag #BPspillmap
4. Filling out this form (http://oilspill.labucketbrigade.org/reports/submit/ )

iPhone Applications


These applications were built taking advantage of the iPhone SDK features enabling the creation of forms, back end web data storage, GPS and RSS feeds. As I write this there are over 20 apps in the app store about the oil spill. There are apps in several categories, heres a sample:

News - keeping users up to date on all the news available across the many internet resources including community sites like Twitter and RSS Feeds
Utilities - enabling users to report location, size and severity of oil contamination
Travel - tracking all world oil spills so you know if there is oil where you plan to vacation
Games - of course there are games like "Fight the Pipe" where you compete with others around the globe to plug the hole with your finger for the highest score.

QR Codes

QR Codes or Quick Response Codes are 2d bar codes designed to be decoded at high speed. A QR Code can handle many times the amount of information of a conventional bar code, 7,089 characters can be encoded in one symbol containing, URL's, web service calls with parameters, text etc.

QR Codes are most commonly used in "mobile tagging" sometimes referred to as physical world connections or "object hyperlinking", basically connecting the internet and it's resources to the physical world.
QR Codes, popular in Asia, have are becoming more popular here and have made their way into Sports Illustrated magazines, Pepsi Bottles and Times Square to name a few.

ScanLife the world wide leader in barcode scanning applications, has partnered with the celebrity backed "Be The One" campaign to get signatures for their petition, which states: “I demand that a plan to restore America’s Gulf be fully funded and implemented for me and future generations." Using QR Codes, the campaign enables mobile users to scan the code which automatically takes the users to restorethegulf.com where they can watch the Be the One video and sign the petition. The "Be The One" QR Codes have shown up in Times Square and availble on T-Shirts.

Text Messaging

Several organizations have launched campaigns to make it easy for mobile users to donate money to aid in the cleanup of the Gulf.
Examples include Mad Mobile, a mobile marketing company, has launched the “Oil Spill Relief” campaign, users can text the keyword GULF to the short code 50555 to donate $10 and the National Wildlife Federation has established a "Gulf Oil Spill Restoration Fund" which users can donate $10 to by texting "WILDLIFE" to 20222.

Text messaging is also used to sign up for alerts from the Deepwater Horizon Unified Command

Legacy Applications and Technology Change

It is not necessary to change. Survival is not mandatory. ~W. Edwards Deming

Independent Software Vendors (ISV's) inevitably, and then repeatedly, grapple with application technology changes. Sometimes these changes are modest, new compiler or component upgrades that need to be fit into the product road map. Sometimes these changes are better described as paradigm shifts, mandating significant changes in products and practices and in most cases absconding the product road map. Examples of such changes include the introduction of .NET and the move to Software as a Service model, or cloud computing.

Although in each case, as with paradigm shifts in other industries, the impact to the those products lagging behind is not immediately fatal, users of these applications demand that the laggers be provided a lifeline, to continue operating at least until the vendor has enough time to adapt the product to the new paradigm or the customer has enough time to find a replacement. Eventually, if the ISV does not adapt to the new technology the product begins to suffer, the user interface may begin to look outdated, performance may suffer, integrations with other applications that have adapted may become impossible, opportunities for the product to expand in it's market or enter attractive adjacent markets.

The business case to adapt the product becomes the focal point and sometimes the paralysis point of the action plan. This is development cost hoisted onto the unfortunate unsuspecting ISV by forces outside of its control, but it is the price of doing business in the commercial software industry.

For product lines where there is a critical revenue stream based on a renewal rate associated with periodic or annual updates, tax preparation products tied to state or federal legislation are an example, the paralysis can be severe and the stakes very high. For these products absconding the roadmap is not feasible, since the majority of the roadmap has nothing to do with features or technology, but everything to do with updating business rules and calculations with legislative changes. As an example of the effort involved, the IRS recently blamed congress for delaying the filing season by passing the recent tax law changes so late in the year, claiming they will need time to reprogram computers forcing refund processing to be delayed until mid-to-late February. So for these ISV's the strategy is to reduce the legacy roadmap to the minimal legislative changes to secure the renewal revenue, jettison all features, and stand up a new development team to work on the next generation application, merging the tax law changes back in before shipment. This of course is an expensive and risky proposition, but a necessary one.
For those ISV's that aren't bound by update timing the strategy if much more straight forward.

In either case the resource issues are similar, new technology, new skills, new designs, new metaphors, new environment new opportunity. It's time to retool and think outside of the box again, the process can be rejuvenating for an organization but it can also lead to some internal tension and critical market mistakes.

Internal tension can occur between the legacy group and the next generation group for obvious reasons. Keeping cross communication channels open and communication events frequent and meaningful can remedy this situation. Also providing a clear skills development path for the legacy developers to join the next generation team is key.

The most common market mistake is to overshoot the current market. Even though the application technology paradigm shift has occurred, rocking the foundation of the product line, doesn't necessarily mean the same thing has happened to your customers, they may be perfectly happy with what they have. And because the next generation product may take some time to build, there is a danger of undershooting where the market will be when the product if finally shipped. A mentor of mine, Jim Petersen - founder and CEO of Best Software (later purchased by Sage Software),used to say, "shoot the puck to where you customer is going, not where they are now". This is critical for the current customer base, but even more important for the prospect customers and markets.

After you've done a thing the same way for two years, look it over carefully. After five years, look at it with suspicion. And after ten years, throw it away and start all over. ~Alfred Edward Perlman, New York Times, 3 July 1958