The Internet of Things (IoT) Conversation
Accelerate Mobile Development with Cross-Platform Tools
Cross-platform tools allow developers to repurpose existing skills to accelerate native, multi-platform #mobile development.
While many of your mobile, cross-platform goals can be accomplished with HTML5, you might be wondering if there’s a solution for pure native code. There are a growing number of options out there using popular programming languages and even no code at all.
Appcelerator provides an IDE and the Titanium SDK allowing developers to create cross-platform apps using JavaScript. Unlike Hybrid apps, the JavaScript is compiled to native code for better performance. APIs are included to ensure apps can take advantage of all platform features as well as native UI elements.
If you’re a .NET shop with developers comfortable with Visual Studio and skilled in the C# programming language, Xamarin is right for you. This development tool runs on its own or plugs into Visual Studio allowing you to build native iOS, Android and OSX apps. It also implements the native UI of each platform so users will never know the apps weren’t built in Objective-C, Swift or Java. Xamarin is a great way to leverage .NET investments across devices.
Zero-code or low-code solutions like AppArchitect, Alpha Anywhere, SkyGiraffe, Force.com, PowWow, WorkSimple, PowerApps, Reddo, MobileSmith, StarMobile and others are worth your due diligence to speed up development efforts as long as they don’t create a risk to your business platforms.
Reduce expenses by building apps for all mobile platforms with a single codebase and a smaller development team to get your product to market more quickly and pervasively. Has your company pivoted to cross-platform development tools?
Learn how to digitally transform your company in my newest book, “Mobile Strategies for Business: 50 Actionable Insights to Digitally Transform your Business.”
Click here to purchase a copy of my book today and start transforming your business!
Reduce Business Risk by Migrating your Legacy Software to Modern, Secure Platforms and Programming Languages
Businesses drag their feet when mobilizing line of business #apps via legacy #software migration thinking it’s cheaper to maintain a codebase than to rewrite for #mobile.
I get it. Migrating all those apps to mobile seems like eating the proverbial elephant. They cost a lot of money to build, the highly-skilled developers needed to rewrite the code are harder to find than ever, the code isn’t commented and there aren’t any docs. This often leads to IT decision makers putting off these projects, perhaps until it’s not their problem anymore. So why do it?
For starters, your employees will be significantly more productive running your apps on the mobile devices they actually use. Since work is not a place to go but a thing to do, employees can get their jobs done from anywhere. Millennials won’t be chained to a desk and they’re going to use the devices they like best. Face it, those Win32 apps are never going to run on someone’s iPhone and your new generation of employees haven’t ever heard of Windows 95. Not changing is a non-starter as you’ll just miss out on younger talent entirely.
Another good reason migrate all these apps and systems is because they’re running on outdated hardware and software. It goes without saying that this infrastructure has far surpassed its end of life (EOL) and there is absolutely no support coming from the original vendors of the computers, operating systems, software and development tools. I’m actually not 100% correct on this point. There are some giant technology vendors that charge tens of millions of dollars per year to support old systems that reached EOL without migrating. In the end, migrating is significantly cheaper and it rescues your valuable intellectual property from fragile, unsupported, failing systems.
There’s a more ominous reason to migrate your apps. Most data breaches are due to running unpatched, out-of-date, and therefore unprotected software. This includes:
- Software written before PCs were pervasively open to Internet attacks.
- Apps that don’t require authentication.
- Apps that don’t encrypt data at-rest or data in-transit.
- Apps written before established secure development lifecycle procedures.
- Un-patched software.
- Software oblivious to buffer overflows or SQL injection attacks.
- Software and services built with the assumption that they would always be “inside the firewall” and therefore protected.
- Apps that don’t follow “least privilege” principles.
- Apps that don’t work with modern sandboxed operating systems.
This older and often unattended software is putting your company at risk. Individual and state-sponsored hackers are attacking the software of companies all over the world. Valuable intellectual property and sensitive customer data is being stolen daily. Company executives are getting fired. You absolutely don’t want this to be your priceless intellectual property or your customer data. This is a fast ticket to losing your competitive advantage as well as the trust of your customers. Oh, and you might be looking for a new CEO and CIO.
So what’s the game plan?
- Catalog all your Win32 and Web 1.0 apps and assemble a v-team to take ownership of them.
- Send out surveys to all your employees to find out who’s still using which apps.
- Utilize asset management discovery software that scans the company network searching for apps running on Windows, Macs and servers.
- Pull the plug on apps that don’t show up in a survey or via asset management scanning.
- Listen carefully for screaming employees and turn those apps back on. I expect you’ll find a good percentage of those apps aren’t used anymore.
- Eliminate the next chunk of apps by seeing if employees can use a new or different process to accomplish certain tasks. Your business and processes may have changed so much over the years that some of these apps aren’t relevant.
When rewriting the remaining apps, focus less on the code and more on data sources, workflows, user interfaces, performance and latency. I’ll talk later about new ways to connect to data and build new apps. It’s more important to reverse-engineer the way employees perceive these apps to work than how the existing code actually makes them work. This provides a good opportunity to stealthily update business cases.
Reduce risk to your company by migrating unsafe, unsupported, end of life software to modern, secure platforms and programming languages. How rapidly is your company de-risking its exposure to legacy business applications?
Learn how to digitally transform your company in my newest book, “Mobile Strategies for Business: 50 Actionable Insights to Digitally Transform your Business.”
Click here to purchase a copy of my book today and start transforming your business!
Improve Employee Productivity by Moving your Win32 and Web 1.0 Apps to Mobile
It’s time to migrate the millions of Win32 and #Web 1.0 apps that currently run global business to #mobile.
Global businesses are run primarily by Windows applications built in the 90s. While apps were created for DOS, the Apple II, OS/2, Sun Workstations, Win16, NeXT, SGI and the Mac in the 80s and early 90s, most were migrated after Windows NT/95 arrived. Y2K taught us COBOL on mainframes are still around. The larger mega-trend stemmed from low-cost PCs coupled to a graphical operating system working with minimal RAM and slow processors. Combined with drag and drop GUI development tools, a perfect storm took over the world of business. The resulting Win32 apps drove a tidal wave of productivity and innovation. Companies still have thousands of them in use today.
Something else happened in the 1990s. A giant network of networks called the Internet, combined with Tim Berners-Lee’s World Wide Web, to create the next technology revolution. Web servers arrived and businesses created static web pages to establish a presence on the web and start marketing to customers. The Intranet was born with internal-facing web pages used to disseminate information to employees. Server-side data processing gave rise to Web 1.0 apps that didn’t have to be deployed to employee desktops the way Windows apps did.
The Win32 and Web 1.0 apps are still with us and must urgently evolve to fit in a world where untethered people expect to flexibly work anytime, from anywhere with mobile devices instead of desktops.
Improve user productivity by migrating legacy apps and websites to the mobile devices employees and customers actually use. What is your organization doing to unchain its employees from desktop apps?
Learn how to digitally transform your company in my newest book, “Mobile Strategies for Business: 50 Actionable Insights to Digitally Transform your Business.”
Click here to purchase a copy of my book today and start transforming your business!
Get Connected to Windows 10 IoT Core on Your Raspberry Pi
Connect to Windows 10 #IoT Core on Your Raspberry Pi with Secure Shell, the Web and Visual Studio.
In my last article, I showed you how to get Windows 10 IoT Core installed on your Raspberry Pi 2. In order to remotely configure, monitor and push Universal Windows Platform apps to your Pi, your Windows 10 PC must be able to connect. A critical element in making all this work is to ensure your PC is on the same network and subnet as the Raspberry Pi 2. Lets get to work.
A quick glance at your Raspberry Pi’s home screen will show you its name and IP address.
From the command prompt of your Windows 10 PC, run ipconfig to verify that it is on the same network and subnet. Sending a ping to your Raspberry Pi to ensure you can reach it is a good idea as well. If your connectivity is good, then it’s time to remotely connect via Secure Shell (SSH) so you can run commands on your Raspberry Pi.
In order to connect with Secure Shell, you’ll need need a remote shell client for Windows. PuTTY is a commonly used, open source terminal emulator that can be downloaded here. Once it’s downloaded, launch the app, type in the IP address of your Raspberry Pi, select the SSH radio button and click the Open button.
The first time you connect, you may experience a slight delay and a Security Alert dialog below might popup. Just click the Yes button to proceed.
Once you connect, type the default value of Administrator at the login as: screen and hit enter. Next, type the default password of p@ssw0rd and hit enter.
Welcome back to DOS! No Edlin jokes…
Let’s try a few commands. If you don’t like the default device name of minwinpc, you can change it by typing setcomputername <new name>. I changed mine to houseofpi in honor of the Houston restaurant where Rod Canion and the other founders of Compaq hatched their plan for a new computer company on a paper placemat. Type hostname to make sure you got it right.
One thing I absolutely want you to change is the Administrator password since your new IoT device is currently in a vulnerable state. Type net user Administrator <new password>to make this happen. Please take IoT security seriously so you don’t contribute to creating the largest attack surface in the history of computing. A good list of Windows 10 IoT Core command line utilities can be found here.
Now lets move on to see how you can connect to your Raspberry Pi via the web.
Looking back to the installation of Windows 10 IoT Core for Raspberry Pi 2 from the previous article, it installed an app called Windows IoT Core Watcher which can be found from the Windows Start menu at All apps | Microsoft IoT. When you launch this app, it should display your Raspberry Pi in a list as shown below:
Right-click on your device and select Web Browser Here from the context menu. Since you just changed your password, the browser will prompt you for it before displaying the page. As you can see below, the Home page just shows you some minimal information about your Raspberry Pi.
The App page shows you a dropdown list of installed apps that you can run, uninstall or set as the default app at the top. Remember, only one app can run in the foreground at a time on Windows IoT Core. The Install app section is interesting in that it lets you remotely install your app (.appx), associated certificate (.cer) and any other dependencies your app may have.
The Process page works similarly to the Task Manager on your PC and displays a list of running processes along with associated CPU and memory usage. Clicking the X next to any of the processes will kill it.
Also like the Task Manager on your PC, the Performance page displays real-time CPU and file I/O utilization and memory usage.
There are a lot of other pages to explore that deliver helpful information and diagnostics to help you be successful with Windows 10 IoT Core on the Raspberry Pi 2. Definitely check them out.
As you might imagine, the whole point of having Windows 10 IoT Core is to run apps. This is where Visual Studio 2015 and the Universal Windows Platform comes in.
RTM versions of Visual Studio 2015 Community, Professional or Enterprise are required to get started. Make sure Universal Windows App Development Tools -> Tools and Windows SDK are installed during the setup procedure. After installation, download the Windows IoT Core Project Templates from the Visual Studio Gallery to make your File | New Project experience more productive. Last but not least, make sure developer mode is enabled by following these instructions.
If the Raspberry Pi devices you’re targeting are deployed with a connected monitor that a person can interact with, create a Windows Universal Blank App project in Visual Studio to deliver a user interface. On the other hand, if you’re targeting headless Raspberry Pi devices, create a Windows IoT Core Background Application in Visual Studio.
Once your headless or GUI IoT app project is loaded, you’ll have to make some adjustments to Visual Studio in order to deploy and debug against your Raspberry Pi. You’ll need to select ARM to support the Broadcom CPU and Remote Machine to debug over Ethernet.
It’s possible that a Remote Connections dialog will popup when you select Remote Machine for the first time. If Visual Studio cannot find your Raspberry Pi automatically, type in its IP address in the Address text box. Select none instead of Windows for Authentication Mode and click the Select button.
Next, I want you to go to the Solution Explorer and double-click on the Properties icon of your IoT project. Click Debug on the left side of the screen and ensure that Target device is set to Remote Machine and the IP address of your Raspberry Pi is displayed in the Remote machine text box. Click the Find button to verify that Visual Studio can connect. If your Pi cannot be found, it’s possible that Visual Studio’s remote debugger on the Pi has shut down after a long time of inactivity. Try restarting your Raspberry Pi and give it another shot.
If all goes well, the Remote Connections dialog should popup and the name of your Pi should be displayed beneath the Auto Detected section. Click the Select button.
After the dialog closes, make sure that the Use authentication check box is unchecked and then click the Save icon. At this point, you should be able to hit F5 and remotely debug against your Raspberry Pi.
As you can see, there’s no shortage of ways to connect, configure, control and debug against your Raspberry Pi running Windows 10 IoT Core. Now start building those IoT apps using the development tools and programming languages you’re comfortable with.
Happy 20th Birthday Visual Basic :: VB Under the Sea
Back in 2001, Apress asked me to write an article about my experiences with Visual Basic during its first ten years of life. Now that we’ve hit VB’s twentieth birthday, I thought I’d share this ten year old article with you:
Back in the early ’90s, I used to drive submarines for the U.S. Navy. During the Gulf War, I helped the Navy Seals get to where they needed to go on a special ops sub that came complete with every kind of James Bond gadget and weapon you can imagine. Back then I carried a 386-16MHz black and white laptop powered by DOS 4. The manufacturer of the laptop was a company called Altima, just like the car, go figure. I had done a little GWBASIC and dBASE III programming here and there, but my primary computing focus was to run WordPerfect 5.0 and a financial package called WealthBuilder.
After the Gulf War ended, I was lucky enough to get orders to a Trident submarine called the Alaska. I arrived in the Seattle area just in the nick of time to witness the Grunge Rock phenomenon that was transforming the city. It was clear to me though, that one particular software company on the “Eastside” of Lake Washington was having an equally profound impact on the Puget Sound region. Meanwhile, life on the Alaska was much less eventful. It was an ordinary job. We would just drive around the ocean waiting for the message from the President to launch our nuclear missiles.
Onboard the submarine we had all kinds of 386 PCs running Windows 3.x. As a Yeoman, I was either driving the sub or handling personnel issues. My boss Joe and I were really “into” computers and thought it would be a move in the right direction to shift our personnel recordkeeping from the file cabinets to the computer. Borland had just come out with a Windows version of Paradox, so we bought it and started teaching ourselves how to build databases and work with SQL. We wanted to build our own standalone application but were intimidated by the Object PAL language provided by Paradox.
On one fateful day in 1993, I was kicking the tires at a computer store in Kirkland when I came upon a big white box labeled “Microsoft Visual Basic Professional Edition 3.0.” It claimed to work seamlessly with Microsoft Access 1.1 and would allow me to create my own standalone executables. In what turned out to be the most important decision I’ve ever made in my computing career, I bought that copy of VB and proceeded to teach myself how to use it. Lucky for me, software still came with books back then. Creating Windows applications in VB was a creative outlet for me because I found it to be similar to painting. I still get kidded for admitting this by my Computer Science and Mathematics colleagues.
Life on a submarine revolves around an 18-hour day. You’re “on watch” for six hours and then off for twelve. This makes for some unusual sleep patterns. While most of my shipmates watched movies, played video games, or slept after getting off watch, I spent my time finishing my college degree and reading every VB book I could get my hands on. I was on a steady diet of books from Karen Watterson, Roger Jennings, and Dan Appleman. Parking my sub at Pearl Harbor meant I could take a bus over to Ala Moana Center and buy more programming books on VB, Access and SQL. At the same time, a lieutenant on board the sub got me hooked on OS/2. Writing 32-bit REXX programs was cool, but getting
VB3 to run in a crash-protected DOS/Windows virtual machine was something to write home about. Before I got out of the Navy, I moved on to Windows NT 3.1 to build my VB3 apps using the WOW (Windows on Windows) subsystem.
When I got out of the Navy, I returned to Houston and landed my first job as a consultant. I can’t say that I was much of a programming heavyweight at the time. I’m ashamed to say that the “data control” was my best friend. Luckily, I had plenty of time to get my coding skills up to par while sitting on the bench. It seems that the Powersoft guys had sold all the large energy companies on the virtues of PowerBuilder. Apparently, VB arrived late to the RAD Windows development party and was having trouble getting a foothold in many of the large companies due to its lack of “enterprise” features compared to competitors like Gupta SQLWindows. (Sound familiar?) After four months with no billable VB hours under my belt, I bought a copy of the Seattle Times to see if the market for VB developers was any better there. Boy, was it ever! The classified section had pages and pages of jobs for VB developers. Being the impulsive guy that I am, my wife and I packed our bags and moved to Seattle where we settled in a neighborhood called Ballard (http://web.archive.org/web/20031108133537/http://www.ballardchamber.com/) that seemed to be comprised completely of Scandinavian AARP members. The local comedy show, “Almost Live,” got lots of laughs at the expense of these poor people from Ballard who drove their cars around with their turn signals perpetually on.
I took a job with a pioneering wireless company in Bellevue called Real Time Data. We built a system in VB3 that remotely monitored vending machines over primitive wireless networks. We did more than our fair share to push along the state of the art in wireless packet data networks. It was here that I learned humility and was transformed into a true software engineer by a group of guys much older and wiser than myself. Lauren Vanderhoof, Steve Horste, Phil Silvia, and Ray Angeledes taught me about state machines, user-defined types, bit twiddling, custom wire protocols, and serial programming. Thanks, guys. Together, we pushed VB3, Windows 3.1, and Access 2.0 to their limits as a round-the-clock telemetry system.
A few years later I spent some time at Microsoft as an Orange badge. It was there that I converted my VB skills to the Web; first with OLEISAPI and then with Denali (Active Server Pages). Over the winter of ’96-’97, I had the pleasure of building one of the first internal ASP/SQL Server applications for Microsoft. OK, it was just a reporting tool, but it seemed pretty cool at the time. I was living proof that Microsoft would succeed in turning millions of VB developers into Web developers with ASP, VBScript, and ADO. Active Server Pages has been a big win for Microsoft and VB developers everywhere. Its success has even brought about the rise of copycat technologies like Java Server Pages and PHP.
Four years and several dot-coms later, we stand poised to usher in the next phase of the Internet thanks to the .Net Framework and Web Services. VB developers have finally been given everything they’ve asked for over the last ten years. Many of these developers are balking at moving to VB.Net, perhaps out of the fear of the unknown. My advice to them is to suck it up and get on board. The recent economic downturn has sparked a shakeout in the computer industry. Single language developers who made a lot of money in the ’90s due to an “out of whack” supply and demand situation may not survive. Developers who strive to learn all they can about all technologies will be the ones left standing.
Remember, Bill Gates and Andy Grove have been successful due to a paranoia that tells them that they have to work twice as hard as the other guy or risk being a relic of history.
Will VB.Net do the same thing for Internet development that “Thunder” did for Windows development? Only time will tell. But I’ve got my fingers crossed.
Rob Tiffany
July 23, 2001
Houston, Texas
Update: Fast forward to 2011 and VB is a first-class citizen on the .NET 4.0 platform. I won’t lie and tell you that all the VB6 developers eventually made the jump to VB.NET. Many didn’t. I am hopeful that a new product we’re launching called Visual Studio LightSwitch can bring back the magic that we all experienced with VB in the 90’s. It’s super-simple to use and is designed to reduce complexity by taking care of all the plumbing for you.
Sharing my knowledge and helping others never stops, so connect with me on my blog at https://robtiffany.com , follow me on Twitter at https://twitter.com/RobTiffany and on LinkedIn at https://www.linkedin.com/in/robtiffany