2022-02-15
So the latest craze in web games is currently Wordle. It's unsurprisingly pretty fun, and the stats and social sharing aspect make it instantly worth discussing with friends. However, only about two days into playing Wordle, I realized Josh Wardle had made what I consider a tragic mistake: Using LocalStorage to store content in the browser.
You see, the first time I tried Wordle was on my tablet. But suddenly, I wanted to give Wordle a shot on my phone... and I realized those treasured statistics wouldn't be there. And if I ever tried to play from my desktop, I'd be up a creek again. As I use three different devices, I'd have three different sets of statistics, all incomplete.
LocalStorage is popular for web apps because it is lazy: You don't need a server-side component and you don't need to manage users in any way. However, it's a fragile crutch, as browser privacy strategies are likely to blow away the assumed-to-be-non-critical data websites cache on browsers, and you lose any matter of cross-device, or even cross-browser access. It also isn't secure and often misused.
Browser-based storage is also a missed opportunity for sharing: Since arcade cabinets became popular decades ago, the simple high score list was a way for players to brag and share. With all data contained in an individual's own browser, this isn't possible. For all the benefits of social-media sharing Wordle, a whole potential experience is lost: The Wordle site doesn't let you see anything about how your various friends are doing in the game.
Recently, the New York Times purchased Wordle and has begun migrating it over to their site. However, this introduced a wrinkle, and exposed yet another flaw of LocalStorage: It's tied to a specific domain, and scattered on everyone's various web browsers. So the solution it appears they went with involved a customized redirect which grabs your Wordle data on the original site, and then passes it along to the New York Times site when it redirects. And of course, that introduced problems.
Ultimately, people should have control of their data, and they should have access to their data from all of their devices. Whether that is running their own or renting someone else's, that ultimately means the correct place to store web app data is on a server.
I'm a user of Sandstorm.io as my app server of choice, and LocalStorage has always presented an issue for packaging Sandstorm apps: Apps are loaded on random hostnames each time for security reasons, hence losing access to any LocalStorage data from the previous load. Depending on the complexity of a given web app, sometimes it's possible to patch in decent server-side storage to an app built solely for LocalStorage.
Unfortunately in Wordle's case, while downloading a copy of it is easy, fixing it is not: It's not open source, and with the acquisition by the New York Times, probably never will be.
2018-06-13
It seems like all of the cool apps today are written in either Node or Python. While I could spend some time learning to write in these, and learning how to debug these, I learned Visual Basic almost two decades ago, and have gravitated back to it repeatedly over the years.
Sometimes people seem to suggest Visual Basic is "dead" or "abandoned", but it's still well-supported on one of the most capable modern IDEs today: Visual Studio 2017. And unlike the VB6 days of yore, Visual Studio 2017 Community provides a free environment that is more than adequate for developing, packaging, and releasing software. The march forward of the .NET Framework and now .NET Core is adding new uses and capabilities to Visual Basic on a regular basis, and Microsoft's new Docs site continues to impress.
I wanted to write a blog post to share some of my recent Visual Basic projects, and what made them interesting to me. While HAController has been a multi-year project, I often use Visual Basic the way others often use a quick Python script: Assembling quick one-day projects that meet simple needs.
First up is my main project, HAController. It's a home automation controller with a personal assistant spin on it. I haven't added a voice recognition capability to it yet, but it's designed with one in mind. Currently I primarily use it to control my Insteon-based home automation devices and log GPS in my car, but it's fairly versatile, and I often consider first whether a given piece of code I want to run would be easiest or most convenient as part of this project.
My newest one was a bit of an experiment, as I'd never written a Windows Service before or made an HTTP Basic Authentication-based web request. SSCaaS, or Sandstorm Cron as a (Windows) Service, is a quick little tool to ping a Sandstorm grain's API on a mostly-regular interval. It adds a little randomness to the request timing, and makes a few requests in short succession, mostly to keep the Sandstorm grain it's checking open enough long enough to perform the operations I expect of it.
I was pretty uncomfortable when I first heard of the Pwned Passwords API, and the idea that hashed passwords were being sent to HaveIBeenPwned. When I learned that the V2 version of the API used k-anonymity, I was much comforted, but wanted to be sure if I checked the API I could be sure the application I used was honest: So I wrote my own. PwnPsswords is a quick console app using .NET Core which checks the API. This is the first one I've assembled that should be cross-platform capable, so this was a pretty neat project too, albeit a short one.
And the final one I am pretty proud of was a way to "fight back" against the retirement of one of my favorite GitHub Insights graphs. GitHub Punch Card Viewer is a quick desktop app which accesses the still-available API for the Punch Card and lets you see what times of day and days of the week your project's commits were made. Rather than trying to emulate GitHub's original varyingly-sized circles, I went for a shading approach here that was quick and effective.
2017-08-25
This part is mostly backstory, how I got to the design and goals I have now.
So, a few years ago it struck me that I wanted to automate my home. I got a Nest thermostat, eventually decided to give X10 a shot, before settling on Insteon. For a while, HouseLinc, their proprietary Windows software, did the job. Then I tried Mayhem, an open source 'if-this-then-that'-type application from Microsoft which had an Insteon module. I looked high and low for other solutions, got rid of my Nest around the time Google bought them (switching to an Insteon thermostat), but still really lacked a piece of software that did what I wanted.
HouseLinc went largely unsupported and is now basically abandoned. It wouldn't handle doors or alarms, despite Insteon having modules for them, because it 'wasn't a security system'. A third party home automation software I looked at refused to support my Insteon Smoke Bridge because they didn't want to be responsible for any safety-related system. A lot of new home automation products and offerings were showing up by this point, but it was of that nasty IoT variety: Cloud-connected, wireless, and based on individual phone apps, rather than a central, intelligent controller.
Eventually I came across Jonathan Dale's excellent site on how to control Insteon devices with Visual Basic. Good old VB was the first language I learned, and despite having long since moved into a lot of PHP and learning C++ and C# in school, falling back into Visual Basic felt like going home. Learning the .NET version took a little more work, of course, but having learned more mature languages in the interim, it wasn't hard to pick up.
The biggest thing I realized early on was that the light switch was still my favorite way to enter a room. Controlling a device on command wasn't the key use here. I wanted to schedule things, and I wanted things to react to other things. And of course, being able to control my house remotely if I needed to was important. But not worrying about turning on a light in my room from my phone while sitting in my room changed my priorities a lot. UI became the least important thing.
So, long story shorter, I ended up with a command line-ish interface. Some commands looking like natural English, but some being quite utilitarian. But the key part about this transition is it put all my disaparate components into one very simple command interface: Text. It was easy for me to make a way to control from my phone by providing a way to let me phone send a text string to the app; I avoided building out a whole mobile app and UI entirely... for now. I could easily prototype new features by making a hidden text command to trigger them.
If my computers or devices didn't do something I wanted them to do... all I needed to do was make a command for them to do it... The ultimate personal assistant is one you write yourself.
2015-06-24
I sometimes spend an unhealthy amount of time on Hacker News. I also communicate with a lot of people who work in Silicon Valley, or in a startup atmosphere. I've heavily noticed a trend towards talking about "DevOps" and "full stack developers", along with the not infrequent suggestion that IT professionals are no longer needed in the cloud era. (I've been told my profession is obsolete a few times.) Further than that, today I heard of the term "NoOps", suggesting that you really don't need anyone managing your company's technology assets at all.
To me, this is not only questionable from a factual standpoint, but this line of thinking causes people a poorer understanding of their business' needs, and how IT staff can fulfill those needs. Developers, I think, feel they can automate or abstract away IT with cloud services. On the other hand, one can also abstract away developers by purchasing software rather than developing it in-house. (Although, I wouldn't question the positive merits of having software perfectly-tailored to your business needs.)
First and foremost, for any business beyond a mom-and-pop shop, you require, and are paying for, IT. The question is how, and how far abstracted you are from it. For some, IT is just calling Geek Squad at Best Buy when a computer breaks. For others, they use cloud services, which means they're paying a subscription fee that includes IT staff they never talk to. In some cases, that subscription fee may actually pay for that service to pay a different service for IT. In fact, there's likely a profit layer there for each company involved, so you're paying quite a bit of overhead over the cost of that IT.
Now, there's no question that smaller companies may not need a full-time IT employee. That's why managed IT companies exist in the first place. Either by contract for part or full-time service, or on an as-needed basis with an incident fee. But I would contend that whether your IT is an in-house employee or a contractor, you should definitely know your SysAdmin.
The problem with the DevOps/NoOps concept, is that while looking for "full stack" developers, they miss the importance of "full stack" SysAdmins. By relying on the support of various service providers, you have no way of ensuring you are making the right decisions for your business, rather than the right decisions for your service providers.
Your Google Cloud support people cannot tell you if your business would benefit from using an Amazon Web Services product, or vCloud Air. They're there to support you using their products, rather than being their to support you.
IT personnel can not only support a particular component of your infrastructure, but understand your needs as a whole. For instance, on any given day I may be working with user desktops, repairing hardware on the plant floor, configuring virtual machines, running backups, managing accounts, pricing out and benchmarking competing technologies to our current choices, and responding to alert conditions on our web servers. If it's electronic, at bare minimum I can provide an informed opinion on it. I know my employer's workflow, and I can suggest better ways to do things, and implement the best options for the company. That's hardware, software, and networking alike.
So the question I have is, why would you trust your IT to someone who you'll never speak to directly? Who doesn't understand your priorities and the service levels you require? Who won't suggest solutions you didn't think of, or question why you're doing something in a less efficient, or less profitable, manner?
2015-03-03
I think we're about at the point that I can comfortably talk about my experience with Google Glass as a whole from a holistic standpoint. Namely because as far as I am concerned, Glass is now dead.
Early Experience
In 2012, I was at Google I/O during the most public unveiling of Glass, and the first opportunity to get on the waitlist to buy one. Sergey Brin parachuted into the Moscone Center streaming video from the device, with a landing that felt like it was taken right out of Iron Man 2. I got GRID brick, number 663, and in May of 2013, I received the first of what ended up being three Shale Glass units.
I was also part of the Glass Foundry event the preceding January. I'll admit, one of the most exciting moments of my tech career was having a New York Times reporter beg me to break the non-disclosure agreement surrounding information we were told at the Foundry. (And there was a significant thrill in refusing to provide information to the New York Times. When newspapers want to know what you know... it's exciting.)
From my first experience with the device, I was absolutely thrilled with the hardware. It's elegant, simple, and blends right in, if you wear prescription frames and a muted color. The screen was perfectly designed; out of your way during daily life and easy to forget was there, but incredibly convenient to glance at when you needed it. Battery life was particularly short, but that is to be expected with a 560 mAh battery.
The first day I got Google Glass, I wore it to a restaurant and received, to my knowledge, the most amazing compliment a woman has ever given me. The girl at the register told me I was "the coolest guy she'd ever met" because I had Glass. I enjoyed the personal attention having one of the rare devices got me. One of my jokes was that "I paid $1,600 to buy popularity for a year." No longer having to seek people to converse with, people regularly approached me to ask about it.
The biggest initial concerns I had with the product was the design that all apps were simply messaging back and forth to the cloud via a Google API protocol (later to be supplemented by a native app option), and the fact that "Instant Upload" or Auto-Backup, was a non-configurable 'feature' of the device. If you took pictures with Glass, Google would upload those pictures next time the device had both power and Wi-Fi. I requested an option to disable this feature at the earliest possible opportunity.
Watching the Hype
As a moderator on the most popular Glass Explorer community on Google+, I had front row seats to the growth of the community and public perception of the Glass program. Invites were initially hotly-traded commodities, and people clamored for the chance to buy into the program. In time, Google granted their wish, first by giving Glass Explorers the chance to invite others to the program, and eventually by opening Glass up for public purchase.
Meanwhile, several people shifted their career focuses specifically to Glass-related products and services. Things like the SoGE (Society of Glass Enthusiasts) groups arose, along with companies making apps, skins, and hardware accessories for Glass. Decorative caps for the Glass earbuds were a particular favorite of mine. However, as someone not generally prone to the startup lifestyle, I questionned those who abandoned their other jobs to work an ecosystem surrounding a product that wasn't even released for consumers, as it seemed like an act of fanaticism. (Notably, some of these people have been hired by Google itself.)
Public Perception Sours
However, as excitement in the Glass community was ramping up, things turned sour for Glass in the public image. A few notable incidents in the San Francisco Bay Area were likely caused in part by the anti-tech movement that has arisen there. While Glass is far from a covert recording device, many people expressed believe that without a more overt recording indicator, Glass users were assumed to be violating their privacy. (Personally, I rarely if ever experienced negative perceptions while wearing Glass, most people I encountered were intrigued and curious about them.)
Furthermore, both businesses and the government turned against them. While I found the ability to subtly check notifications without disrupting moviegoers to be a primary perk of the device, movie theaters began to publicly announce bans on Glass for fear that people would use them to bootleg movies (despite obvious head-bobbing issues). The ability to navigate, text, and call hands-free on Glass is far superior to any hands-free system sold in any car today. However, states began to propose laws banning their use while driving, despite again, that being a key use case for the device.
While surely not more than a minor footnote, an affair between Sergey Brin and a Glass employee made a fair bit of a fuss when it went public, and shortly after even Sergey, our real-life Tony Stark, stopped wearing the device.
Glass Development Stalls
Another huge hit seemed to be the apparently slowing and eventual cessation of updates to Google Glass. While initially updated monthly, Glass eventually stopped receiving frequent updates. In particular the baseline upgrade to KitKat held back feature updates for months. One of the most publicly-marketed features, the ability to stream video live over Hangouts, was actually removed from the device, which was not a decision that was received well.
Very few Google apps were updated with more than the most basic functionality, even after a significant period of time. Settings were non-existant. For example, you could only receive emails Google decided were "important" and there was no way to change that behavior.
My longstanding privacy concern with Instant Upload was never addressed. For a while, it was arguable that Glass simply didn't have the depth of settings necessary to allow it, however Glass eventually introduced a settings bundle to configure auto-backup settings, allowing you to choose to allow sync regardless of power and network state, or to wait for wall power and Wi-Fi. However, Google refused to include an option to shut that synchronization feature off, showing disregard for users' ownership over their own photos.
In part due to the lack of consumer release, third party apps never left the range of around fifty apps, and the slow, Apple-esque app approval process meant many of the most useful apps never made it to the app list. Eventually, some companies dropped support for their Glass apps entirely. While the Android build on Glass was open source, and the bootloader was unlocked, the decision to keep the entire UI of the device in a closed source package killed the chance of any significant ROM development in it's cradle.
For many basic functions, no app was ever available. For instance, Glass never had an email client that could work with non-Gmail addresses. Without even this level of baseline capability, it was hard to justify wearing the device day in and day out, other than the attention it sometimes got me.
The End, Effectively
On a recent earnings call, Google confirmed that they asked the Glass team to step back and refocus. This was coupled with the closure of the Explorer Edition and the end of public sales. While Google still provides the devices for 'Glass for Work' customers, the consumer side of Glass has come to a close.
The official rhetoric is that they are working on what's next, I believe the end of Glass has been reached. Many of the known employees of Glass have now moved on, either by leaving the company or moving to other products at Google. I know of a few employees on the original Glass team which haven't, at least publicly, changed their status, but without so many of their developers, I question even the viability of the project continuing.
My Glass is now shelved, and I anticipate a matter of time for Google doing the same with the program.
2014-08-01
It's recently been revealed that the EU is preparing an antitrust case against Google. A lot of people have already started to come out and claim that it's crazy for whatever reasons. But it's truly one of the most important coming pieces of litigation. Android is a massive monopoly, and it was created by an agreement between a wide variety of competitors to work together.
The first thing to bear in mind, is Google is smart. Ridiculously smart. These are the people who social engineer the placement of food in employee cafeterias to trick their employees into eating healthier. Google knows what it's doing, and it knew what it was doing when it created the Open Handset Alliance (OHA).
When Android came out, most of the OEMs have no idea what to do about the iPhone. They didn't even have smartphone models yet in most cases. I refer to Android as the "open source trojan horse", because it appeared to be a gift at the time.
Google offered up an open source platform with the means to compete with Apple. OEMs were basically given free reign to do whatever they wanted with it, as long as they agreed to some basic provisions: To not break application compatibility. And, you know, Google was willing to help them and such if they installed the Android Market on it. At it's best point, Android was like Linux: A completely open source project that you could do what you wanted with.
But the problem is, the app ecosystem, whether people realized it at the time or not, is the most powerful component of the platform. Windows Phone is, in many ways, better than Android. But it doesn't have the app ecosystem, and without that, nobody wants one. (BlackBerry and Palm also learned this the hard way.) And as the Android Market, now the Play Store, of course, gained traction, it became less and less possible to sell a device without it. (Note that back then, a lot of OEMs did produce devices without the market. That practice has almost entirely died off now.)
With each Android version, the OHA agreements have been tweaked. Gradually bringing each OEM in line with Google's vision. OEMs don't want it, but they have no choice: They either fall in line, or lose the Play Store, and hence, their product won't sell. OEMs have fundamentally no control over the devices they produce at this point. There's strict limits on customization, strict limits on timelines OEMs must provide updates, strict limits on preinstalled apps. These are not Samsung, HTC, or LG phones. These are all Google phones.
One of the worst provisions is the all or nothing requirement with Google Apps. If OEMs want the Play Store, which they need, they also must include all of Google's other apps, like Google Search and Google+. Preinstalling Google apps makes it harder for other companies to compete on the platform. As Google no longer has to innovate to maintain hold over the market, and newcomers are disadvantaged, innovation languishes.
Technically speaking, no, OEMs aren't prevented from developing an alternative OS. But market forces have ensured that isn't a problem: They can't run the Play Store. The no forking provision coupled with the mandate to preinstall Google apps prevents OEMs from developing competitors to Google's apps and services without abandoning Google entirely. (There's a huge potential profit cliff to forking Android. Google knows it.) The few things OEMs are allowed to do by Google, are the things Google knows can't threaten them. Anything that can threaten Google's monopoly is regulated.
It's a combination of market forces and the agreements that they've made to fill in the gaps, that ensure Google maintains control over every Android OEM. Google is smart enough to have engineered these rules in a way that looks good on the outside, but is just as locked in nonetheless. Most of the companies making Androids have no control over their own products anymore, and are too afraid of the reprisals to break out from it. Samsung is probably the only company that has the brand power to break from Google successfully, but Google's been tossing them a bone here and there to keep buying them off.
A dissolution of the OHA would allow OEMs to differentiate their devices again, providing their own custom experiences and competitive products. Yes, more fragmentation would occur, but that's a good thing. Fragmentation is just another word for "consumer choice". And without the OHA, competing services would be able to compete with Google's built in services, encouraging new innovation in a market that has started to become stale.