adding expected runs per inning to baseball win expectancy finder

So…yup, I did that!

I already had all the data for this, so it was more mechanical than anything else. Actually, most of the time I spent was turning it into a proper React app. Before I just had a bunch of inline React code, which was great for testing and simplicity, but meant that a bunch of compilation had to happen on every page load. So I bit the bullet and figured out how to use nwb and all the stuff that lets you compile React code that I don’t really care about. But it builds a pretty small JS file, which is nice.

Still a big fan of React, though!

Floating Point to Hex update, and writing tests as a sign of maturity

Over the weekend I published an update to my Floating Point to Hex calculator that allows you to swap the endianness of the hex bytes! Pretty exciting, no? (the answer is: meh)

It was actually more work than it looks like, because I decided to go ahead and update the backing script to Python 3, which meant I had to recompile the C module it uses. When I was about to start doing this I was disappointed to see that I didn’t have any tests in the project, so I went ahead and wrote those before changing everything. And even before I started changing things I found a few bugs (oh negative zero, you are tricky), so it was time well-spent!

I did have to refactor a few things to make the script testable, but I can’t imagine doing a refactor with only the help of spot-checking things, which is what I used to do. Just like writing clean code, writing tests is useful for future you as well as others!

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 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 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 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.