Tea vs. Coffee

I’ve recently switched from coffee to tea for dietary reasons. (I need to drastically cut down carbs.) Anyone who knows me knows that I’m a bit of a coffee addict — one of my favorite lines from a TV show was an exchange from Homicide: Life on the Streets, in which we discover the most intense character drinks “Two or three… pots” of coffee per day; that was me before I got obsessed with quality. Once you start caring about the quality of coffee, you either need to have a great local cafe, or you need to start making your coffee yourself. It’s a slippery slope — I grind my own coffee (and flirted with roasting, but I decided I’m not that dedicated) although for a while I did subscribe to coffee. Anyway, that reduced my consumption to 2-4 cups per day.

The problem is, I like milk in my coffee. I like lattés, although I can’t be bothered to make them at home very much. And I like to drink cold coffee (a double-shot in a cup of cold milk). And milk has carbs. (About 7% of my daily target in one cup.) I also drink espresso shots, but that’s not really a drink.

Now, before I got into really good coffee, I used to switch from mediocre coffee to tea for months at a time. I’m partial to Twinings, specifically English/Irish Breakfast, Earl Grey (which, I just discovered, recently had its very own New-Coke-style-debacle and aftermath), and Darjeeling. It’s hard to get good tea in the US (sure, it’s also tricky to get good coffee, if you’re a coffee snob, but it’s hard to get good tea if you’re only vaguely interested in tea — e.g. our local supermarkets have ample decent choices of whole bean coffee, but the only loose leaf tea is Liptons. That’s like only being able to buy Maxwell House coffee beans.

So, what are the advantages of tea over coffee (assuming you don’t drastically prefer coffee for its taste)?

  • Tea is cheaper than coffee.
  • It’s harder to screw up tea — e.g. by over-roasting or incompetent preparation.
  • You can make a lot of tea at a time and it will be Just Fine.
  • If a cup of tea gets cold, it’s still quite drinkable. A cold cup of coffee is a biohazard.
  • Tea has far less caffeine (or its equivalent) than coffee.
  • I find tea without milk (especially green or jasmine tea), or with only a little milk, much nicer than black coffee or “Americano” with milk.
  • Tea masks Splenda’s slightly unpleasant finish; coffee exacerbates it.

Obviously, if you simply prefer the taste of coffee, none of this matters. But for me, it gives me a harmless (possibly even beneficial) alternative to water (which is great too) I can have all day that won’t blow out my carbs, is easily made in quantity, and doesn’t become undrinkable when it gets cold.

Silicon Dust HD Homerun, CableCard, and Mac

One point twenty-one jiggawatts!

So, the good news is that Time Warner’s 50Mb/s internet access is really, truly 50Mb/s. I’m impressed. (Let’s assume no outages.) On the other hand there’s the whole digital cable situation. Now, as you may recall, I don’t care for broadcast TV but, hey, I wouldn’t mind being able to watch major sporting events live. Also, I’ve discovered that, at least where Comcast is concerned, if you don’t actually have a digital tuner in your house then you can’t access HBO GO even if you pay for HBO. So my goal was to (a) get access to TV when I wanted it (i.e. rarely), and (b) minimize the amount of cable TV bundling tax I pay on top of my true need which is high speed internet.

My plan was to get a stupidly fast internet connection with the cheapest TV package that included the station that Game of Thrones is on. I also wanted to pay as little as possible for set top boxes and other crap. The result is I bought a new modem from Amazon (based on recommendations from both Time Warner and The Wirecutter) to avoid paying $8/month for a crappy modem and trying to figure out which wall wart goes with my old Comcast modem (which probably doesn’t support DOCSYS 3 anyway) and I bought a mysterious device called the HD Homerun which purports to allow anyone on your LAN to watch Cable TV by using a CableCard. I picked this option after discovering that a CableCard is by far the cheapest “tuner” option I can rent from Time Warner if I want to be able to “watch” HBO.

The HD Homerun's software is minimalist and borderline useless

First off, the HD Homerun basically doesn’t support Macs. It has a godawful (and pretty useless) “application” that lets you discover your device on the network (which works quite well) and then point its tuners at different stations in a ludicrously primitive and unhelpful way. Some stations “work” (i.e. when you tune to one and click “view” you see something) while others don’t (i.e. if they’re encrypted or some other magic property is not in evidence). To get that far, however, is a bit of an epic journey.

The HD Homerun's embedded web app is truly awful.

To begin with, such documentation as you get (which is virtually nothing) assumes you’re using Windows 7 (or maybe 8). Although, judging by the forums, it’s not like everything “just works” in Windows. But in particular Windows will actually display the HOST ID and DATA strings you need to get the device working with your provider. On a Mac you need to go into terminal and type hdhomerun_config discover to find out the IP address of your gadget. (Getting this information involved extensive googling and then eventually realizing that Mac users are best off reading the MythTV documentation and trying to glean meaning from it.) You then type the resulting IP address into a web browser to get to a spectacularly bad web app (as in, worse than ten year old routers) which displays the information you need. And with that I was able to see perhaps one in ten stations (not even all the free to air stations I am supposed to get).

So, the one positive side of this is that despite the fact I can’t watch any HBO stations (they’re all encrypted and the device doesn’t support decrypting them — I’m not sure why) I have been able to log into HBO GO and I’m only paying $2.50 per month (plus taxes to pay for the Spanish-American War, etc.) for a useless CableCard instead of $8/month for a useless set-top box or $23/month for a useless DVR.

Verdict: I’m not positive that Time Warner Cable is as incompetent as Comcast, so it’s possible that I don’t need the CableCard at all, in which case the HD Homerun is a complete waste of money, On the assumption that TWC is exactly as incompetent as Comcast, and that without some kind of tuner that theoretically could receive HBO in my house I couldn’t use HBO GO, the HD Homerun is the cheapest device I could find that lets me use (and theoretically activate) a CableCard. As such, it pays for itself in about six months. Just don’t expect it to do anything useful.

Daikon Forge

Daikon Forge lets you edit your UI live in the scene editor and preview it in the game view.
Daikon Forge lets you edit your UI live in the scene editor and preview it in the game view.

Progress continues on Project Weasel, and last weekend I bought a license for Daikon Forge ($90 in the Unity Asset Store) after mulling over the Unity GUI situation for over two years (basically since Unity announced its new GUI system in San Francisco in 2011). Like many Unity developers, I’ve been waiting for Unity to fix its execrable GUI library for some time, and had avoided investing in nGUI, Daikon Forge, or Coherent because something better — and free — was coming out real soon now.

I reached the point where not having a functional UI library was blocking progress, so I decided I was going to buy a better UI library — the question was which one? nGUI has been the market leader, but from what I’ve seen the API is pretty terrible (and the fact that the nGUI dev is the guy building the new Unity GUI does not fill me with enthusiasm). Coherent — based on HTML5 — seems like a great idea, but according to reviews I’ve read it consumes quite a bit of CPU on mobile devices (and you’d expect it to, given that web browsers can tax mobile devices). From what I could see, Daikon Forge was the least expensive option and possibly the best (if not as widely supported as nGUI). It’s very well reviewed, including by quite a few nGUI refugees. It also struck me that the Unity GUI would probably be, in effect, an improved nGUI, so I’ll have the best of both worlds once it actually ships.

Anyway, so far I’ve found Daikon Forge is pretty nice but not without issues. But it’s worth noting that all of the weaknesses I’ve seen so far affect the developer and not the delivered product.

(Mostly) Good Stuff

I whipped up a 3d pinned information panel in less than an hour
I whipped up a 3d pinned information panel in less than an hour

To create a user interface with Daikon Forge you use a wizard to set up a “manager”. On the plus side, it works! On the minus side it’s a “wizard” — automatic fail. I’d prefer you to be able to drag a prefab into the scene, or drag a script onto a GameObject, or select a GameObject and pick a menu item. The sad thing is that there’s no reason it can’t work that way. Functionality A. Usability C.

Next, you need to assign a default skin and a default font to the UI gadget. In my opinion it should Just Work without this. (How? Easy — stick a default skin and a default font in a Resources folder and load them on the fly if needed.) This particular bit initially stymied me (the picker didn’t “see” the relevant assets), and I needed to find the relevant components manually and drag them into place. Functionality B. Usability F.

Daikon Forge makes creating and maintaining a UI atlas very easy
Daikon Forge makes creating and maintaining a UI atlas very easy
Using Sketch (this is the old version) you can whip up a UI skin in a matter of minutes
Using a tool like Sketch (this is the old version) you can whip up a UI skin in a matter of minutes

The tools for creating your own skins and fonts are almost brilliant. (Select the assets and pull a menu item — and you can easily add items to and remove items from your UI atlas any time you need to.) Functionality A. Usability B.

Next, you can right-click the UI “gizmo” in the scene editor and add controls to it directly. This also stymied me because the context menu does not work when your inspector panel is in debug mode, which mine happened to be in at the time. (Who knew?) Again, on the plus side it works, on the down side many controls come with idiotic defaults (e.g. huge or dimensionless). Functionality B. Usability C.

So I finally managed to get my Galaxy working so that I could click on a star and have a little information display pin itself to the star and show information like the name and spectral class of the star and how many planets it has orbiting it (and the display is not scaled, renders in a minimum of draw calls, and is pixel perfect, but is pinned to the projected 3d position of the star — very cool). On the downside, I found the documentation for binding values to controls to be incomprehensible, and did it all by brute force. Functionality C (so far). Usability F.

Bad Stuff

Every widget has a lot of properties, and they're not given sensible defaults
Every widget has a lot of properties, and they’re not given sensible defaults

First of all, there’s a big workflow problem. When I first imported Daikon Forge into my project it didn’t work properly (e.g. when I tried to assign a skin to one of Daikon Forge’s UI managers it wouldn’t find the relevant assets). This problem eventually “went away” (no idea why) but it was a sign of things to come.

Second, I keep my project in Dropbox and would work on it from my laptop and desktop at different times. When I switch machines, the other machine would load changed files and Just Work. But after I installed Daikon Forge this process became completely broken. Daikon Forge would become completely broken and need to be reimported whenever I switched machines. Worse, every script component assignment would become detached from its relevant script (only for Daikon Forge scripts) and have to be manually repaired. I don’t have a fix for this except to stop using DropBox, which might not be a Bad Thing.

Third, the documentation is good as a class reference, but bad as a guide/overview/cookbook. The tutorials are good but video only and somewhat lengthy. The examples are good but no substitute for actual documentation. Then there’s the website. To post on the website you need to register, and when I try to register it tells me my username or email address flags me as a spammer and that if I want to fix this I need to reply (how?) or use the contact form (where?). I tried my usual handle (podperson) and my usual email address, and my real name and my gmail address — all spammers apparently.

The WYSIWYG editing of your interface is great as far as it goes, but that’s not far. E.g. there are guides, but nothing snaps to them. There’s a grid but nothing snaps to it. There’s a tool to distribute multiple controls horizontally or vertically, but it doesn’t work properly. Worst of all, simply moving and editing things is very finicky. You can easily get into a state where the transform widget is overlapping some other control (e.g. a sizing handle) so that whenever you try to move a control you actually resize it. I ended up resorting to the keyboard for moving controls, and directly entering values for sizing them most of the time.

In a nut

Daikon Forge delivers on its promises in terms of functionality and performance. It renders user interfaces efficiently and attractively. It’s very easy to create and maintain texture atlases. And it supports scalable fonts. Furthermore, its design leverages idiomatic Unity development (e.g. you can make and reuse prefab controls in the obvious manner.) But it is far from perfect: ironically for a UI building tool, its own UI is spotty to put it charitably. Thus far I’ve found the website to be borderline useless and the documentation weak. I’m not sure if the video tutorials and examples really fill the gap (I haven’t had the time or inclination to watch all the tutorials).

C#’s Belt and Suspenders

In discussing my (fairly minor) annoyances with C# with a colleague, I finally figured out the nub of the problem. C# tries to protect you from certain bugs (overflowing bounds and buffers in particular) in so many different ways that the relevant warnings and fixes become irritations and noise, probably making code less reliable rather than more

E.g. why does assigning a double precision value to a float stop code from compiling? What’s the problem this solves?

Another example, why does moving values from unsigned to signed integer types stop compiles? The main reasons for worrying about integer overflows or getting a negative number when you expect a non-negative number is array bounds checking, but C# has array bounds checking, so why do this at all?

It seems to me that C# ought to treat all numbers with periods or exponents as double precision by default and allow assignment to float with implicit casting. This emphasizes correctness (precision) over performance by default, which is as it should be. Similarly, assigning an int to a uint should simply be allowed. (The compiler can insert code to throw an error if the value is negative if so desired.)

Now, I should say I’m using Unity’s (i.e. Mono’s) C# compiler here, so perhaps Microsoft deals with these annoyances at IDE level (e.g. by offering to automatically fix the relevant problems) in much the same way as Apple has leveraged compiler technology to provide automatic fixes, optimizations, and suggested improvements in XCode.

C# Part II

Galaxy Generated and Rendered in Unity 3D
Galaxy Generated and Rendered in Unity 3D

In the end, it took me four evenings to replicate the functionality in my Javascript prototype. I’d have to point out that I was able to do some really nice UI stuff (e.g. drag to rotate, mousewheel to zoom) in Unity that I hesitated to mess with in Javascript (the galaxy was rendered to a canvas in Javascript).

On the whole, I have some impressions.

First, C# is very strict about types, and while I can see some benefits, I think a lot of it is utterly wasted. E.g. having to constantly cast from one numeric type to another is simply a pain in the butt (I routinely expect to have to tease apart a bunch of cryptic type-related errors every time I compile a few lines of new code).

// given an array of weights, pick an index with corresponding weighted probability,
// e.g. [1,2,3] -> 1/6 chance of 0, 2/6 chance of 2, 3/6 chance of 3
public uint Pick( uint[] weights ){
    int s = 0;
    uint idx;
    foreach( uint w in weights ){
        s += (int)w;
    s = Range (1, s); // returns a random int from 1 to s, inclusive
    for( idx = 0; idx < weights.Length; idx++ ){
        s -= (int)weights[idx];
        if(s <= 0){
    return idx;

And all of this rigor didn’t actually prevent or even help debug an error I ran into with overflowing a uint (I have a utility that picks weighted random numbers, but I overflowed the weights leading to an out-of-bounds error. (A simple fix is to change idx < weights.Length to idx < weights.Length – 1.) On the whole it would be nice if you could simply live in a world of “numbers” (as in Javascript) and only convert explicitly to a specific representation when doing something low level.

Second, there’s this weird restriction on naming classes within a namespace such that the namespace and class sometimes may not match and the class you want is often not in the namespace you expect. (E.g. I wanted to create the namespace LNM.PRNG and define the class PRNG in it, but this confuses the compiler, so I ended up calling the namespace LNM.Random — so code referring to this is “using LNM.Random” which mysteriously causes a class called PRNG to become available.) I don’t see why namespaces and class names can’t be the same.

Oddly enough in some cases I am allowed to name the class the same as the namespace, and I don’t know why. So LNM.Astrophysics implements the Astrophysics class, but I had to rename Badwords to BadwordFilter at some point because the compiler started complaining.

I’ve been using Monodevelop, which is an editor produced by the Mono folk and lightly customized to work with Unity. It’s a bit of a slug (if it’s developed using Mono, then it’s not a terrific advertisement for Mono). In particular, its autocomplete is great when it works, but utterly frustrating far more often. It fails to match obvious words (e.g. local variable names) and often makes it impossible to type something short (which matches something longer) on the first attempt. The autocomplete is darn useful, or I’d simply switch back to Sublime.

Flying my untextured spaceship around an undecorated, partially implemented solar system
Flying my untextured spaceship around an undecorated, partially implemented solar system

So the current reckoning is that I ended up producing the following:

  • Astrophysics.cs — defines the LNM.Astrophysics namespace and implements the Astrophysics utility class, some useful enumerations, and the Galaxy, Star, and Planet classes.
  • PRNG.cs — defines the LNM.Random namespace and implements the PRNG class which provides convenience functions for the Meisui.Random Mersenne Twister implementation I’m using.
  • Badwords.cs — defines the LNM.Badwords namespace and implements the BadwordFilter class which checks to see if any of a pretty comprehensive list of nasty words is present in a given string. (Used to prevent obscene star names from being generated.)
  • Billboard.cs — a Monobehavior that keeps a sprite facing the camera. It’s a little cute in that it tries to save CPU time by only updating a given star every 10 physics updates. There’s probably a better way.
  • FixedCamera.cs — a Monobehavior that implements a mouse/touch controlled camera that keeps a fixed view of a specified target unless explicitly moved. I’m planning on using this as my main view control throughout the game.
  • NewtonianScoutship.cs — a Monobehavior implementing an Asteroids-style player ship. I’ve also experimented with a “Delta Vee” style abstracted Newtonian ship controller but good old rotate and accelerate just feels better, and makes movement a pleasant challenge in and of itself. (It also makes becoming “stationary” in space almost impossible, which I think is a Good Thing.)
  • GalaxyGenerator.cs — a Monobehavior that instantiates a galaxy and renders it with sprites. (Right now every single star is a Draw Call, so I’m going to need to do some optimization at some point.)
  • Starsystem.cs — a Monobehavior that instantiates a Star (and its planets) and renders them, a navigation grid (to provide a sense of movement when passing through empty space) and orbits using a bunch of Prefabs.

So, while I continue to find C# quite tedious to develop with, I am making significant progress for the first time in over a year, and while C# feels much less productive than real Javascript, I do think it’s very competitive with Unityscript, and it’s been quite easy to get over the hump.