PSA – Assembly.GetEntryAssembly() is tricky.

So something I learned when I was getting Exor ready for publication and was reminded of when I hit a bug with TiledSharp last night was that Assembly.GetEntryAssembly() has a trap door in it. Something a lot of people, myself included, seem to forget is that you can load managed assemblies from unmanaged code in .NET. When you do this, GetEntryAssembly() returns null.

This is documented, but in the regular case you won’t see this–your app runs, you get the entry assembly you expect, life is good. The unit test runner in Visual Studio (at least as of 2013), though, calls through unmanaged code. So does the XNA content pipeline, which I’m otherwise using happily with MonoGame.

Exor: an extensible add-in framework for .NET

As with my other projects over the last couple weeks, I’ve been on a kick where I pull useful stuff out of old projects and polish them up for an open-source release. Exor is a (somewhat) polished iteration on Anaeax’s mod system. It couples an attribute-based type mapping add-in system with a neat wrapper around CSharpCodeCompiler that allows an add-in (like, say, for a game) to compile and dynamically load .cs files that can provide those types.

Originally I only planned for this project, my MonoGame-based content management gizmo and SheetParser, but Versioner ended up being a useful side effect–it didn’t really make a lot of sense to put all of the versioning and dependency resolution into Exor just to lock it away from other projects that could use it.

Exor is on Github and NuGet (Core, Compiler) and is licensed under the MIT license.

More Github stuff: Versioner

While on vacation at my folks’ in Maine, I’ve been plugging away on extracting more common patterns from various old projects. One common issue I regularly run into is the need for maintaining versions of stuff and a dependency graph. There are no easy libraries for this stuff as in Ruby, so I’ve repeatedly reimplemented solutions in multiple projects. Decided to clean up the best of them, write a solid test suite, and open-source it as Versioner.

The source is available on Github and a compiled PCL is available on NuGet.

GitHub braggadocio: SheetParser

So I spent a little time pulling useful code out of old projects and threw SheetParser up on Github and NuGet. SheetParser is my simple parsing/deserialization tool for ripping spreadsheets and building C# objects out of them. It’s a niche library, borne out of doing game development; I use this to avoid writing a bunch of really dumb tools and instead using Excel to do my dirty work.

Mostly tested, too, though coverage isn’t complete. MIT licensed – have at it.

A Healthy Platform Checklist

This post is up on Hacker News. I’d appreciate your upvote and your comments.

Oh yeah. Reddit too.

I’ve been doing a lot of thinking and talking with a lot of folks lately about what I’ve been calling “devops” and now mostly call platform engineering: the care and feeding of the underlying systems that power scalability, fault tolerance, and developer productivity. There’s a great deal of value to be mined from treating your infrastructure as a product, with strongly guaranteed interfaces and APIs for other product teams to use. Starting early on the kind of infrastructural work that can empower early developers and enable more effective early development, while building towards the long-term scalability needs of startups heading towards the “elbow” of exponential growth, where you Get Noticed and your lives get interesting.

Much of this doc is cadged from everybody else’s notebooks about platform engineering, pick-and-choosing best practices from others and from my own experience, to put together what I’m calling a Healthy Platform Checklist. Unlike the Joel Test, however, I don’t intend this to apply to everybody everywhere; this is a set of characteristics that expect the need for scalability and value developer agility and productivity, and not all businesses need that. I emphatically don’t view this as being a purely prescriptive “you suck if you aren’t doing this right now”, but instead something to pin on the wall, a set of guiding principles to keep in mind and ideal states to work towards.
read more

When all your tools are hammers…

…your thumbs are on notice.

Wait, that’s not right at all.

Anyway. Anaeax update—chewing through that final rewrite I mentioned a bit ago, a little more than halfway through. I hear tell it’s giving Peter a bunch of ideas, though he’s currently caught up in some other stuff and hasn’t had much time to progress on his side of things. (Neither of us need this game to eat, and we’re currently not considering a Kickstarter, so if it takes another eight years to come out—well, I’m not too worried.)

I’m in a blogging mood today, though, so I figured I’d talk briefly about the scripting layer. Readers of the old blog might remember that the scripting layer was a Rhino-based JavaScript interpreter that used Rhino’s general coolness to talk to the Java APIs inside the game. And that was rad. But we’ve switched tech to Mono for a number of reasons around tooling and platform-friendliness. While .NET has a couple different JavaScript libraries, none proved suitable for what I wanted. I wanted fast script execution but an option for no runtime code generation (which is disallowed on iOS, consoles, and so on).

This is harder than it sounds. JScript.NET requires runtime code generation and just doesn’t run on platforms without Reflection.Emit. Jint is cool and nobody knows about it, but I ran into a lot of trouble trying to make it play nicely with what I wanted—it was also pretty slow.

So I was complaining most vociferously about this to my buddy Sean, who has this habit of being good at things. Sean is a compilers guy, which scares me roughly on the level of “an axe-murdering guy” but in completely different parts of my psyche, and he’d done a bunch of Roslyn reading. (He doesn’t do much .NET, but, y’know. It’s an interest.) “What about using Roslyn to compile your scripts?”

“That’s fucking horrib—wait, that’s fucking brilliant.”

So off I went, code code code, and had something cranked out in a few hours. Scripts are just C#. On the first startup, Tracksuit (which is open-source, btw, use it in good health and send me pull requests) walks your mods/assets directories for .cs files and compiles them, caching the results for future runs, and loads them as their own assemblies. There’s some mod-level metadata to define mod dependencies used by the mod compiler to compile dependencies in the proper order and expose them as dependent assemblies to code further down the dependency tree. Attributes declare entry points and object unique IDs for use in other content; I kind of reinvented Mono.Addins in the process but couldn’t quite come up with a good way to reuse that instead of bolting in my own simple assembly-walker stuff (and I didn’t really want to be its new maintainer, either).

This whole approach doesn’t work on iOS, obviously. But that’s not a big deal, because what does work is precompiling the mod projects (all my content .cs files live in a .csproj) and embedding them. Already tested it. Works like a champ. My biggest concern thus far is security, because while .NET supports AppDomain and some security stuff, Mono (Mac and Linux) sure don’t. Then again, Minecraft mods are Java and can do anything they want on the system. There might just have to be some caveat modtor in there.

Stupid Java Stuff: static initializers and singletons

So, to get it out of the way: there is a fairly large segment of the Java community whose reaction to a Java-style singleton object is to hold their nose and go fleeing in the opposite direction, pausing only to git blame to know who to come back for and settle accounts with later. I know this because we all have Singleton Haters Club cards and the meeting is at the corner bar every Tuesday evening. But this post is largely in spite of that.

The topic of singleton initialization came up today. There are a lot of bad ways to initialize a singleton and I got to see a couple of them up close and personal today; that there are ostensibly principal-level Java developers who haven’t internalized Effective Java is a surprise but nobody’s perfect. Anyway, without further ado, lemme give you the wrongest (vaguely working) way to do it that I can think of.

read more

Anaeax – an overdue update

So it’s been awhile and I figure I owe the twos of y’all actually interested in this game an update.


Long version:

For now, the plans for a Kickstarter are scuttled–the project’s still trundling along but the going has been slow due to scheduling issues. Peter’s got a gig, I just switched jobs, and Tida had to duck out for a little while in order to take care of some stuff. Even with a Kickstarter it’d be hard for us to take off to work on this full-time, so the day jobs come first.

As far as actual dev goes, my new job’s been taking a lot out of me lately and I haven’t been able to make the progress I’d have liked to this summer. (The job and that “outside” thing. Maybe I should move somewhere where it isn’t gorgeous all summer.) That said, things are progressing okay and I’ve got a handle on that end of things. Over the last week I’ve started in on the final draft of the script and overall game design doc; I wasn’t satisfied with the last draft and am tying up all my loose ends as I go. I expect to have that done by the end of September, which probably means mid-October because The Job Is Eating My Entire Life, and we’ll see where we can go from there.

In the next couple of weeks I’m going to write something up soon about the final-final iteration of the tech stack (no seriously, this works and it’s cool), the open-source release of the core tools that we’re using (very much related), and maybe a little thing about some games I’ve been studying and how they’ve influenced the design of Anaeax.

Oh, and forwards here for now because updating two blogs is beyond my superhuman powers of typery. Blogs, man.

Docker Web Proxy with SSL support

So Mesos is pretty cool, but it isn’t a universal solution. Not much reason to run it as a singleton cluster, for example, so this blog is running on a Linode running all its apps in Docker containers. This is new to me, but the upside is that it’s new to everybody else too—Docker’s still pretty new and there’s a lot of green field to play with in the containerization space. While there’s that sense of openness there’s also very little to suggest what the Right Course Of Action really is. Sometimes you gotta get inventive

Speaking of inventivity, I found myself needing a way to route HTTP requests to Docker containers based on vhosts. This isn’t a new problem to have, and Jason Wilder has a neat proxy container written in Go. I needed something that could handle HTTPS as well, though. I tried extending that container to do what I wanted, but I learned two things along the way.

  • Go’s templating options are Not Ready For Prime Time. Compared to ERB, it’s straight-up miserable.
  • The list of things I would rather do than use Go is not small and includes scenarios that involve nailing pieces of myself to other pieces of myself.

Enter docker-web-proxy, which I put together while I was on vacation in Maine this week. It’s a simple Ruby-based app that polls Docker for connections and splats out the appropriate nginx config before SIGHUP’ing the service; arguments are passed via the env vars given to the containers that need to be made visible. It supports HTTP, HTTPS, or HTTPS with HTTP forwarding, and optionally supports forwarding to if that there’s your thing.

After doing some nontrivial work with Docker, I’ve come around to the opinion that Docker would really benefit from a way to tag containers dynamically at runtime—think AWS—without bringing in something like etcd or Consul (my own personal favorite in this space, HashiCorp is cool people). I get the argument for separation of concerns, but, ehh.

So, part one of this little getting-acquainted with Mesos left me with one (1) Mesos server, running apps in an app-ish sort of way via the Marathon framework. Which is cool. But there’s a lot of places to go from here.

I could install additional frameworks onto the box, if I wanted–I could bolt in Chronos to give me a cron replacement or I could wire up Spark to map and reduce things on HDFS. But those aren’t really interesting to me, not least because I don’t have any jobs that have a burning need to run at 3AM, nor do I have a few terabytes of interesting data lying around to gnaw on. So instead I’m going to stick with Mesos and see what I can do about expanding my little cluster past a singleton server.
read more