Some notes to myself on a recent adventure trying to get Minecraft running in a Windows Server Core virtual machine inside of Hyper-V. I'll refine this post later.
- You can download JRE Server to avoid installation headaches.
- You have to disable TCP offloading, otherwise connections will drop all the time. Set
This was much harder than it should've been.
Visual Studio offers an excellent Android emulator. It runs at native x86 on Microsoft's Hyper-V platform, so it's speedy and plays nice with other Hyper-V VMs and Windows Phone emulators.
Getting it to work was a bit tricky, though.
Lollipop VMs Won't Boot
First off, after installing I noticed that Lollipop VMs (API versions 21 and 22) just plain didn't boot. They would just hang at the "OS Starting..." screen until the emulator would finally timeout with an error. Looking at the VM through the Hyper-V console itself would reveal the error
failed to read from /dev/hw_random which was fairly cryptic.
It was only after searching the web a little bit that I came across the solution:
My guess is that the problem is the new generation of processor you are using. Apparently the Hyper-V emulator fails while trying to load Android Api 21 or 22 virtual images.
- Open Hyper-V Manager
- Select the Lollipop Emulator Virtual Machine
- Click Settings
- Expand "Processor", select "Compatibility"
- Enable "Migrate to a physical computer with a different processor version"
After toggling this option, the emulator started very quickly.
VMs Don't Show Up in ADB
After successfully booting the VMs, I had trouble getting them to show up in ADB so that I could deploy to them. Turns out that the VS Android Emulator looks to a registry key to determine where your Android SDK is installed, as mentioned in the troubleshooting document.
Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Android SDK Tools
Modify the Path registry variable to match the path to your Android SDK.
This key didn't exist on my machine (perhaps it was removed from whatever SDK ships with Android Studio 2 Preview). After adding it and restarting my VM, it showed up in ADB and I was able to deploy to it. Joy!
My web apps tend to be a mess.
Over the past few years, I've written a number of "single-page apps". Purdue.io, Tunr, Roomie, etc. As I never bothered to learn any of the hip new client-side SPA frameworks (Angular, Ember, etc), my first step was always to come up with a good way to manage the UI. In my haste to build an awesome app, I never put too much thought into crafting a nice way to manage how I was displaying information, or even architecting the app in the first place.
The result was nightmarish spaghetti code. Extremely short-sighted hunks of code to apply this animation here, update this element here, insert these elements there, etc. Despite this, however, I'd receive praise for how beautiful and smooth the UI was. The code, despite being poorly conceived from a perspective of re-use and modularity, was very efficient at what it did: move elements of the DOM around to display what it needed to the user.
Once others started diving into my code, though, this became a problem. It hit me harder when I dove back into old code of mine and couldn't easily come to understand where I'd need to make changes to add new features. I was lost in my own labyrinth of terrible UI code.
Tunr promotion video, showcasing some of the cool UI
You should use a framework, you idiot.
So how do I solve this problem? Use a framework, of course! I immediately dove into Google's Polymer project, which seeks to provide a framework that includes support for web components, data binding, common controls that implement "material design," and all sorts of other stuff.
It was a nightmare - nothing was easy. Tons of components and conventions that weren't very well documented. There was no support for TypeScript. Helpers were provided in places I didn't feel I needed help (a huge amount of "let me get that for you" CSS styles). In addition, a lot of it only worked well with Chrome. Worst of all, whenever something went horribly wrong, I didn't understand how the framework worked behind the scenes, so I had nowhere to go. It drove me crazy. Worth noting is that this was over a year ago, things may be much better now.
After wrestling with Polymer for days, I went back to spaghetti-UI, and productivity shot through the roof. I could bang out simple apps in no-time (the Purdue.io front-end was the result of one or two night's work), even if the code behind them was hideous.
Do it yourself.
I started thinking... what exactly do I need to do to beautify my apps? A way to declaratively write UI. A library that will interpret declared UI, and manage keeping it in sync with data, animating it, etc. I would write my own UI framework, and I'd call it Boink.
Instead of being a giant mess of spaghetti code, what if my app could look like something like this?
Pretty straightforward. Define some templates, define where the data belongs, and Boink does the rest.
So far Boink already supports templating and data binding, and comes with some common components like
Repeater. As I continue to write more apps with Boink, the framework will expand to support everything I need to do. Navigation model and animations are up next. Maybe when I get to a point where I'm confident Boink is fairly feature complete, I can go back and re-write some of my old projects to utilize it.