writing a test for a bug before fixing it: a good idea most of the time

I’m not fully onboard with test-driven development, but I have started to like it a lot when I’m fixing bugs. First I reproduce the bug manually in the product, then I write a test for it that fails, then I fix it and makes sure that the test passes. Good stuff!

Friday I started working on a bug that I was surprised to see, because I had written a test that I thought should cover it. So I tried it manually in the product, and was easily able to reproduce it. I noticed some differences with the way the test was set up, so I started trying to tweak the test to get it to fail.

And I spent like 4 hours trying to do this, getting more and more frustrated. I could not for the life of me figure out what was going on!

Finally I said “whatever” and investigated the bug in the product. It took me like 10 minutes to find the cause of the bug, which also revealed why my test hadn’t caught it. Another 20 minutes later, and I was able to make a test that failed without the bug fix and passed with it.

So this is a reminder to myself: it’s OK to do things out of order sometimes!

Man, Javascript is still kind of dumb

I’m working on rewriting my floating point to hex converter with React. This time I thought I’d do it “right” and use all the nifty Javascript tools that everyone complains about instead of just putting a bunch of inline Javascript/JSX in an HTML file, even though that works well enough. Long term, I’d like to rewrite the marriage map with React and D3.js, so I thought this would be a good dry run.

But, maaaaan:
– I literally had to buy a React+d3.js ebook to figure out how to get all this crap set up. (the book is pretty good, by the by)
– The book recommends starting from a particular git repository. To clone that on my linux machine I had to set up some SSH key stuff, which seemed like overkill. (why do I need to do that for anonymous access?)
– To set it up, it downloads something on the order of 300 packages through npm. I wish I were exaggerating.
– Building it (even without minifying the source!) takes a solid 6 seconds on my desktop machine. This is for a ~100 line javascript file. The non-minified version is more than 2 MB of Javascript! Even the minified one is ~180K, which seems like way too much.
– React now recommends you use ES6 instead of calling React.createClass(), and there are some niceties there. But there also some stupid gotchas, like the fact that you have to call .bind(this) on every method for it to be able to access this, because Javascript is the worst.
– For some reason I’m not able to debug with Firefox’s debugging tools. (luckily Edge seems to work well)
– I wasted an hour because the new fancy fetch standard (not supported in some versions of IE so you need a polyfill) has a method called text() that returns the text of the response. Wait, no, it actually returns a promise that has the text of the response. I never realized how much I liked C#’s standard of ending asynchronous methods with “Async” before…

Anyway, I think I’m past all this crap, but I’m starting to remember why Javascript is terrible!

Using Let’s Encrypt to make gregstoll.com support HTTPS!

Since I have a few projects that require passwords (most notably LJBackup), I’ve wanted to set up HTTPS on my website. I had done this with my own self-signed certificate a while back, which works but gives you a pretty scary-looking warning in various browsers. I’ve blocked out the memory of what I had to do to get this to work, but it was very painful.

So when I read about Let’s Encrypt again, I thought I’d give it a shot. They recommend using certbot to automatically enable HTTPS, and I was pretty skeptical but thought it was worth a shot.

And – wow! It totally works! It made a certificate and updated my Apache config that worked correctly out of the box. Now gregstoll.com has a pretty green lock when you visit it 🙂

Using react.js for the first time – mostly good, some bad

My JavaScript coding has been pretty basic in the past – I’ve gotten good at using jquery.com to hack together things that work, which has been plenty good enough for my side projects. Now that JavaScript frameworks and libraries are all the rage (here’s a giant list of frameworks and libraries) I decided to learn React (or react.js), which I’ve heard some good things about.

Since I had just improved my baseball win expectancy finder and it was fresh in my mind, I decided to try to rewrite the whole thing in React. And I was able to do it in just two nights! If you’re interested in looking at the code, here’s the original jQuery-only version and here’s the version in React.

I read a bunch of the React docs and thought I knew what I was doing, so I started to write it, then got confused/uncertain about how to approach it very quickly. Finally I read Thinking in React which made everything click for me and I was off to the races! I highly recommend the article.

So what’s good and bad about React? Here’s what I’ve found:
Good: Changing the inputs (inning, number of outs, runners, etc.) to React was very natural. This is where React really shines – you just define how these things should render if they have a particular value. Here’s what the code looks like for the runners combobox:

var RunnersOnBaseList = React.createClass({
handleChange: function(e) {
render: function() {

Runners on base: 

/* etc. */

The key point here is that you’re just responsible for setting the properties and state of things and defining how those component should look. React will figure out if anything has actually changed and re-render if so, since updating the DOM is notoriously slow. It’s similar to data binding in XAML, although it’s not two-way (more on that later). In the jQuery version of the code I have statements like $('#runners').val(runners); all over the place to set values, and it’s just ugly.

Good: React specifically plays nicely with other frameworks. So even in the React version of the page I still use jQuery to do the AJAX request, which is handy. I also use it for the highlight effect.

OK: The way React handles events (like doing something when a button is clicked) is a little clunky – the parent components pass down callback functions to their children, and the children call them when appropriate. But that means if there are multiple levels of components you have to pass down callbacks to each of them.

Bad: Getting the highlight effect after the AJAX request was done was a big pain. I’m pretty sure I went down the wrong track somewhere, but I’m not sure where. I tried to use the builtin animation stuff, but couldn’t get that to work so I ended up checking in componentDidUpdate() whether any properties have changed, but only _certain_ properties…anyway, I struggled with it and the code is a mess. In jQuery this is extremely simple – just highlight the output after the AJAX request is done!

Good: React lets you write code in JSX (although it’s not required), which is basically JavaScript, but it lets you return HTML in each component’s render() function that really looks like HTML. This makes writing components really nice.

Bad: Debugging JSX isn’t possible, at least not that I saw. You can run a JSX transformer to generate JavaScript and debug that, but that’s an extra step between making a change and seeing if it works. At least if there’s an error, Firefox will tell you what line number of the JSX it happened on, so that’s something.

Windows Phone 7 App Hub – my complaints

In the wake of complaining about background tasks in Win 8 (that was later rescinded), here are my complaints about the Windows Phone 7 App Hub, where you submit new apps and look at download numbers, etc.

Before I begin: I rant because I care 🙂 I’m still very happy with Windows Phone 7 (and Windows 8!) development, and plan on sticking around it for a while, unless of course Microsoft pulls a webOS like HP did. (dear Microsoft: please don’t do this!) But there is some serious need for improvement here.

(Had I been writing this a few months ago, my number one complaint would be that the page itself was dog slow, but Microsoft seems to have fixed that. Yay!)

When I load the App Hub page, 95% of the time I have a simple question: How many copies did my app sell today? For webOS and Android, their consoles answer an equivalent question: how many copies has the app sold over its lifetime? Let’s count the number of clicks it takes to answer that question:

First I load the page (I won’t count this as a click), and I see something like this:

You might think the answer to my question is right by the word “FlightPredictor”: 101. Or at least you might think that’s the total number of sales. Sadly, it is the number of downloads in the last 30 days. This is interesting information (as is the graph at the bottom), but it doesn’t answer my question. So click 1 is to click on the “101” number, which by the way does not do the same thing as clicking “FlightPredictor”.

That takes us to this screen:

Here we can see a nice pretty graph, which is again interesting, but it only covers the last thirty days. So clicks 2-4 are setting the Start date to March 1, which is before FlightPredictor was released. (for bonus fun: this will take one more click every month!) Then click 5 is clicking Refresh Report, which shows me the full graph. But the numbers include trial downloads, which I am interested in, but I don’t get paid for. To see the paid numbers, click 6 is clicking on Details, which takes me to this screen:

and then click 7 is advancing to page 2, where I can see the paid downloads for the US. If other countries had any paid downloads, I guess I’d have to add those up.

So…yeah. In theory I could get by with not resetting the date range and use the “export details” button to look at an Excel spreadsheet and look at just the most recent daily numbers that way, but most of the time I’d much rather be able to see the numbers in a browser, rather than firing up Excel. It would be really nice if this information was more easily accessable!

Windows 8 Metro: everything is fine re background tasks, nothing to see here

After kvetching a bit about Windows 8 Metro background tasks, Jared Bienz set me straight.

The right way to do this is to either use push notifications to update the tile, or a TileUpdateManager to have it poll for tile updates. In both cases the difference is that you’re not actually scheduling a background task – you’re just providing a way to get a tile notification, which is a bit of XML that describes how to change the tile.

Now, this isn’t ideal for me the programmer, since I need to set up an extra server, but it does scale better with lots of different apps and preserves battery life, etc. So it’s all good, and hopefully lots of Win 8 apps will take advantage of one of these two ways to get power-efficient live tiles that update!