It’s Memorial Day weekend here in the US, which also marks the unofficial start of summer (at least in my book). And summer means sweltering heat from which there is but one relief: it’s the cool, refreshing breeze from an air conditioner. And while there’s nothing exactly wrong with my current, window-mounted AC unit (which I got in college in exchange for a six-pack of beer in what might be the best trade I’ve ever made), after making the switch over to smart lights in my room, I can’t help but want a smart air conditioner.
Most of this just stems from pure laziness. I’ll admit that I was, for years, skeptical about the value of smart lightbulbs, right up until I bought a set on a deal and discovered the unparalleled joy in being able to turn off the lights in my room without getting out of bed. There are added benefits, too, like being able to automatically set lights on a timer.
And now that summer’s here, I want the same thing for my air conditioner, with all of its many additional features and modes. Imagine being able to switch from fan to actively cooling by just asking Alexa or Siri instead of getting up or finding the remote. Or being able to remotely turn on the AC when you’re walking up the block from the subway, so that your room is perfectly cool when you walk through the door. Or how about being able to turn off the AC when you realize that you’ve forgotten to turn it off on your way out?
Now, there are already a few ways to do something like this. One is smart plugs — some even with thermostats — that brute force the solution by turning on and off the entire outlet, but those don’t have the full feature set I’m looking for. There are glorified IR blaster solutions, but that seems like a step in the wrong direction and even clunkier than the outlet option (even if it means not having to replace my window unit). The best answer seems to be the current wave of new smart AC units that feature Alexa, HomeKit, and Google Assistant support, but earlier smart AC units haven’t gotten the best reviews, plus the new ones are kind of pricey.
There’s also the fact that most of what I want to do is already possible with a standard remote control and timer, making this more of a “nice to have” rather than an actual need. But still, technology — and specifically smart home technology — is supported to make our lives easier and better, and for me, that would be a smart AC unit.
I agree with you, smart air conditioning is not a ‘want’ anymore, it is a ‘need’. Thanks for this article!
Considering it's Doppelgänger week on Facebook, I thought I'd mention that I have my very own Doppelgänger at work and his name is, well, Chris!
See, I share an office with another Chris. Yes, the jokes abound. Let's see, there's Chris 1 and Chris 1, Chris P and Chris T and Chris Squared.
It's actually kind of wierd because we implement practically all the same interfaces. People will come into our office and just say "Chris?" and then settle for whoever happens to answer first. Sometimes we just sit there silently the other Chris will be explicitly requested.
Sure, there are differences between us. He's been with the same company for 8 years while in the last 8 years I've been with, well, 8 companies! We take turns being the installer team lead. He usually has the helm when I leave to work elsewhere gladly giving it back to me when I return. What a friend... I think. :-)
Did I mention that he really gets it when it comes to setup and that he's joined the DeploymentEngineering.com blog team?
While he hasn't actually posted yet, I do know that he has an interesting story to write regarding his trip out to PDC last fall and a deployment focus group he attended.
As I posted last summer, I'm still looking for experienced software engineers in the area of Install, Build and/or Internal Tools development.
There are several available roles with different emphasis on the above skills. In general, the engineer will be part of a Build/Install/Internal Tools team that currently consists of 11 members with additional on the way to meet our ever growing needs.
Please note, due to customer requirements, all applicants must be a US citizen. Ability to obtain and maintain a US Security Clearance is required; an active clearance is highly desirable.
Components are the basic unit of installation in a Windows Installer product. They are installed by one or more features, and can contain any number of resources including files, assemblies, registry values, and are recommended for custom resources as well. Examples of custom resources are web sites, virtual directories, SQL tables, and stored procedures.
While it's an interesting read, albeit covering 10 year old concepts, I have a problem with the last little bit about "custom resources". Well, two problems:
1) Windows Installer doesn't expose the concept of "custom resources". This is entirely made up. Don't believe me? Then tell me how to mark a custom resource as the key-file for self repair checks? How do you involve the custom resource for costing purposes? Sure, you can write data driven custom actions that associate themselves conditionally to a component, but your out of process custom action will never really implement resources.
2) Why doesn't MSI already handle all these examples that are presented as "custom resources". Seriously, what (enterprise) application these days doesn't store data in XML or relational databases and/or present application layers as web apps or web ui? Wasn't Windows Installer intended to solve enterprise TCO issues?
It's an interesting perspective and I invite Neil to tell more ( as an aside, I'm always interested in guest bloggers on the Deployment Engineering team. Diversity in Opinion is always a good thing ). Until then, I wanted to give a few of my thoughts.
Merge modules provide a standard method for delivering Windows Installer components and setup logic just like any redistributable software. For all practical purposes any MSI package can consume a merge module and start using the functionality exposed by the merge module. However, the servicing story of such an MSI package has a huge flaw. Since the setup author who owns the MSI doesn’t own the merge module, they have no way to deliver fixes to issues that are found in the merge module, unless the merge module owner makes them available. On the other hand, the owner of the merge module has no way of delivering the fixes directly to the clients who installed the MSI built after consuming his/her merge module. The bottom-line of the story here is:
•Be prepared to handle the heat when bugs are found in your merge module causing issues for others’ products that have consumed your merge module and you get to put out the flame
Merge modules are great to use for distributing authoring and building of your setup. However, if you intend to redistribute an MSM externally, you should review the servicing implications. If you can tightly control the MSM consumers and identify the relevant products, then it’s possible to service them with a single MSP (multi-product targeting). Otherwise the recommendation is to provide your technology as an MSI that must be chained into the setup
Let's begin with a little history lesson. Microsoft used to use Concurrent / Nested Installs and Merge Modules as a deployment option for Microsoft SQL Server Desktop Engine. Then along came some really nasty security vulnerabilities that exposed a glaring problem in servicing these products that were embedded in other products. Network / Systems Administrators simply couldn't patch there production systems easily to eliminate these worms. Then Microsoft started telling developers to not use these technologies and instead use Micro-Packages to deliver them. After awhile, the message mutated into something along the lines of "merge modules are evil". Then there was the little problem that MSI doesn't actually provide a decent bootstrapper / chainer to put all these packages together and the proliferation of packages has made Add/Remove Programs look like total chaos.
OK, so what am I getting at? Yes, it's true that when I put merge modules in my installs from third parties ( typically Microsoft .. how ironic ) that the quality of my installs go down. And it's true that Microsoft doesn't promise to provide fixes and updates to these modules and in many instances they don't provide MicroPackages to redistribute either. So what's my alternative? Break the component rules and author my own components for another companies resources? Yup, this is an ugly problem that's never solved except by not taking dependencies on those components and moving to newer technologies that get more love from third party vendors. Still, I'm writing the install not the application so I don't typically get to make that call.
However, I am certain that using merge modules internally to distribute setup development is a good thing. Comparable and even better in some situations then using WiX Fragments / Libraries / Binary Libraries or InstallShield Developer Installation Manifests.
Second, merge modules are atomic collections of components and setup logic. This is actually fairly similar to WiX Fragments which according to their own documentation are also atomic and immutable. WiX Binary Libraries and MSI Merge Modules both aim to solve similar problems.
Sure, using Fragments can speed up your build and give you a bit more flexibility ( like including two components in a fragment but Referencing them into two different features ). However, you can do the same thing with merge modules by creating multiple merge modules with module dependencies to describe component / feature relationships. With a little bit of creativity, Merge Modules can even be used to encapsulate AppSearches, CustomActions, Dialogs and more.
Over the last five years I've developed an architecture where I use an InstallShield Basic MSI project to describe a feature tree and product configurations to describe which features to consume. This serves as a fishbone that I then flesh out with dozens to hundreds of merge modules and create dozens of product installers with. I use Major Upgrades as my servicing strategy and the result is I've never had any problems that were caused by the use of Merge Modules.
In summary, you don't have to have a monolithic InstallShield project for each of the installs you own. You can split it out and reuse components and logic through merge modules and not increase the fragility of your install. In fact, you can realize considerable savings by eliminating wasted effort and decreasing the frequency of bugs in your baseline.
Yes, I will admit it: I use Merge Modules and I'm OK with that. Still, I will be working on Fragment support for IsWiX.
I author merge modules for use internally only. My biggest complaint is with using InstallShield to author merge modules. If you have a multi-language MSI installation, using InstallShield to author the modules is next to useless. IS doesn't support creating standard multi-language merge modules (with multiple langage CABs embedded in the module). The first thing I tried was separating language-specific components into their own IS generated merge modules (IOW, a separate merge module source file for language A, language B, etc.). However, that only works if you're going to create separate MSI databases for each language (you can then use InstallShield's build options to only pull in language-specific data at build time). If you need to include the language-specific components in the same MSI database then you're pretty much screwed with InstallShield generated merge modules if any of the components target localized folders (such as a localized program menu) or have any other localized strings (service names, target directories, shortcuts, etc.). In my [very large] product MSI database, I've pretty much had to have any localized component included in the main IS source file rather than in IS generated merge modules.
My other warning would be in using the Microsoft Visual Studio C++ Runtime merge modules. My product currently has a dependency on the VS 2005 SP1 run time and there are several known issues with these modules that MS has not fixed (Google "SxsUninstallCA" to find them). I've finally gotten rid of these modules by distributing the Win32 assemblies as private side-by-side assemblies in my application's program files location according to the instructions in the Visual Studio "redist.txt". When I was using the MS modules, I had to re-condition the "SxsUninstallCA" CA so it didn't run.
To be honest I've only briefly dove into localization. My investigations lead me to believe that WiX and InstallShield are both lacking in terms of what the MSI SDK says should be possible.
I'd love to be able to make multilanguage MSM's and then aggregate them up into a single multilanguage MSI.
Even if you are using Fragments, WiX currently has no built-in way to do this. You'd have to build the different MSI's and then use a bunch of custom build automation to generate your transforms and stream them back into a signle MSI.