How to Draw a Line

I became a bit intimidated and frustrated with my simulation framework so I set it aside for a while. I played a lot of video games and I practiced my piping. I’m bored with the video games, though, and last night I came back to the sim. I’ve got some ideas for making the problems tractable or even non-issues, and that’s the benefit of walking away for a bit. Before tackling the big structure, though, I thought I’d take a look at a small fix: how to tell what direction a link is going.

A link between two components is a directional line. It takes messages from the source end and sends them to the destination end. But if I’m drawing the link as just a blue line, how can you tell by looking which end is which? I thought I’d maybe color the line as a gradient. (First I thought maybe I’d draw little arrows on the line, but that seemed too fiddly for almost bedtime.) The documentation and tutorials around using LinearGradient are all about using gradients as fill for shapes, not about lines, so there was some experimentation along the lines of, “What happens when the source endpoint is to the right of the destination endpoint, or what if the source is below the destination?”

Anyway, this works:

Stop[] stops = new Stop[] {new Stop(source.getX() < dest.getX() ? 0 : 1, Color.BLUE),
                           new Stop(source.getX() < dest.getX() ? 1 : 0, Color.RED)};
LinearGradient linkStroke = new LinearGradient(0, 0, 1, 0, true, CycleMethod.NO_CYCLE, stops);
ctx.setStroke(linkStroke);

It’s Alive!

So, I’ve been fooling around with Java FX for the past month or so, poking at a toy project just to see how the system works. And now I’ve built a discrete event simulation environment that lets me drop graphical components down onto a workspace and let them pass messages to each other. I’m pretty jazzed about this! Maybe in another couple of months, I’ll have a trade network simulation that I can fool around with.

Followup

From the javadoc comments in Math.java: “If the argument is NaN or an infinity or positive zero or negative zero, then the result is the same as the argument.”

Let me just point out that Java thinks that NaN (Not a Number), positive zero, negative zero, or either positive or negative infinity are different values, and this is not a quirk of Java. The language thinks this because the standard for computer representation of real numbers thinks this; the language is just exposing the constructs so that programmers can handle these different values.

At least nowadays positive zero will test as equal to negative zero. (That wasn’t always true, you know.)

Order Matters

I’ve been playing Kerbal Space Program recently and using the MechJeb plugin. Some people criticise that plugin – “You can do anything that MechJeb does, and if you spend a little time, you can probably do it better” – and they’re right, for some values of right. And yet, “execute next node,” is blessedly useful. It keeps the game fun, for me.

Anyway, one of the problems with MechJeb is that some of its input fields that accept an angle want decimal degrees, and some want degrees – minutes – seconds, while the contracts seem uniformly to specify decimal degrees. I found an online tool that will convert between them, but have found that the author of the tool didn’t consider the way computers do floating point math. The algorithm would pass muster with a mathematician:

  1. Take the integer part of the decimal degrees. That is your degrees.
  2. Take everything to the right of the decimal point and multiply by 60. Take the integer portion of that product. That is your minutes.
  3. Take the decimal part of the product and multiply it by 60. That is your seconds.

The problem is that a computer might lose a few digits off the end when you start doing all that multiply, truncate, and subtract. For example, try using that online tool to convert 27.2 degrees. It’ll tell you that the answer is 27 degrees, 11 minutes, 60 seconds. And sure, that’s true, but what you really want is 27 degrees, 12 minutes.

The computer way to do this is to start out multiplying 27.2 by 3600. That gives you seconds, and you convert from there:

  1. Take the integer part of the decimal degrees. That is your degrees.
  2. Multiply the decimal degrees by 3600. That is the total number of seconds (still a floating point number).
  3. Multiply degrees by 3600. Subtract that product from the total number of seconds.
  4. Divide the new (smaller) total number of seconds by 60. Take the integer portion of that value. That is your minutes.
  5. Multiply minutes by 60 and subtract that product from the total number of seconds. Now the total number of seconds is really your seconds, and it will be smaller than 60.

I feel like this is the sort of thing that I learned from writing BASIC programs to do my math homework back in high school. Didn’t these guys ever get told off by their math teachers for being imprecise?

Ars Gratia Artis

So, I came out of retirement to work on a neato project. I’m doing a lot of programming, architecture, release management, project management, and, um, reporting. So, that’s why I’m not doing a whole lot of bagpiping or anything. Because this is fun and important.

But nobody cares about that. The interesting thing here is that when I came on board there was git and not a whole lot else in the way of engineering support. I know how horribly messy a build and release system can get, let alone a development workspace, without some good process and support tools in place. So I started thinking about continuous integration, bug tracking, and an artifact repository.

I then mentioned this in a work context and was reminded that a “team” of only three people probably didn’t need a CI system and an artifact repository, but maybe a bug tracker wasn’t a bad idea. And that made sense. I have worked with enough QA people, though, and people who were serious and thoughtful about configuration management and build/release process, to still feel like having a dedicated build machine is probably a Good Idea. I just feel kind of itchy when I think about distributing software that was built on a programmer’s laptop.

So I checked out Jenkins and Artifactory and became befuddled within an hour of crawling through their documentation. I have associated with CM folks, but I’ve never really figured out their lingo.

Time passed. I wrote a lot of code. Other folks did. We threw some stuff away, we built some stuff, and now we’ve reached a major internal milestone. I’ve released some software internally, and it was built on my laptop. By me. By opening a terminal window and typing `mvn package`. I still kind of cringe to think about that, even though when I go to the trouble of articulating why, it turns out that in this particular case it is okay. I’m distributing an early beta/late alpha dev build.

Anyway, tonight I had a bit of spare time. Did I play video games? Did I veg out to some Netflix? Or did I install Nexus and TeamCity and try them out? Yeah, you guessed it. I still don’t think that we need an artifact repository. Not yet, anyway. We don’t have enough distinct modules to need it (unlike at Netflix, where we had a score or more internally developed libraries). But I found that setting up TeamCity was really easy (well, except for the part where it doesn’t grok my local MySQL installation) and it doesn’t confuse me with a lot of words that don’t mean what I think they mean. I might actually turn our cute itty bitty Mac Mini into our build server. Won’t that be a kick?

You know. For fun.

Building Everything from Scratch

You know what I love about programming? The part where I get to solve interesting problems. You know what isn’t interesting? solving the same problem over and over again. Even less interesting is having to solve a problem that I know someone else has solved but where I can’t copy the answer. That’s not only uninteresting, it’s frustrating.

So, I’m writing a tool in Java and I need for it to allow the user to input styled text (simple typeface stuff – italics, bold, strikethrough). We’re not changing font family and we’re not laying it out for print; we just need to be able to capture this style stuff. And then persist it. Ultimately, it’s going to be stored as XHTML. So I look around, and sure enough, JTextPane turns out to be the thing I need to be able to display the text. Pretty soon we’ll want to have inline images that the text can flow around, and that component can handle those things. So, that’s great.

Continue reading

Oh Right, That’s Why I Hated Libraries

I dunno, back in, like, 2010, I was working on software that had something like 1 zillion dependencies (or, you know, 50. Same thing) and keeping track of consistent versions of all the dependencies was a real pain in the neck. Our organization had a dedicated CM team who set up Artifactory and Ivy and we worked pretty hard at being flexible with which version of commons-lang we actually required.

But note, that was a full time job, just managing the artifact repo and the build system. So now here I am, managing a team and we’re developing a suite of programs. We’re building some custom code, but a lot of what we want to do is accomplished with off-the-shelf libraries, each of which is available from Maven central. Of course, each one pulls in a different version of slf4j or bcprov or whatever. With only a couple of dependencies, it’s okay, there are no collisions. But last night I pulled in jets3t and *poof*, the app would no longer start because jets3t’s version of bouncycastle collides with the version I was already using, so uh oh, we can’t do encryption because the class loader is confused.

Easy enough to solve (downgrade bouncycastle to the version jets3t plays with) but this is my reminder that configuration management is actually a full time job, and there are best practices and frameworks and all that good stuff.