AoC 2018 – Day 10 Retro

Today is day 10 of Advent of Code 2018, the fun daily coding challenge I mentioned I was taking part in this year, and I thought it a good time to take a quick look back at my story so far.

I’ve still not managed to rank globally for any of the challenges (the closest I came was on day 5 when I completed part two 696th) but things are going reasonably well on our private BJSS leaderboard, and the challenges have mostly been fun. So far I’ve stuck with Ruby as my language of choice, although I almost broke out Unity 2D for today’s graphical challenge (Early-morning me obviously had grand ideas which were quickly set aside when I realised I could zoom out my terminal and stick with Ruby).

Here’s a quick rundown (with possible mild spoilers) of the challenges to date. The links take you to my solutions on GitLab, which obviously do contain spoilers, so don’t click them if you haven’t already done the puzzle for that day.

  • Day 1 was a very simple problem involving summing a list of numbers, and finding the first duplicated number. Nothing much to say here, nice and quick.
  • Day 2 involved finding characters duplicated two- and three-times in a string, with part two focusing on finding strings that differed by one character. I went with hash-based solutions for this one.
  • Day 3 was about finding overlapping rectangles. I made a simulation for this as the maths escaped me. This was the first solution that was properly object-oriented Ruby, and I got stuck for a while because I accidentally transposed my X and Y coordinates in one of the methods!
  • Day 4 involved finding the guard who slept the most, and (in part two) the minute in which they were most often asleep. Another simulation (I quite enjoyed this one).
  • Day 5 was about reducing a string by removing pairs until none remained. Regex and recursion to the rescue here – a really quick solution.
  • Day 6 was, frankly, a nightmare. I couldn’t really visualise the problem at first, and it took me a lot longer than it should have to really get to grips with it. Solved in the end, but after many hours on-and-off. I did learn something new though 🙂
  • Day 7 involved a dependency graph and another simulation. I had a lot of fun with this, and even made an ANSI-based visual mode so you could watch the simulation unfold in the terminal. Great fun.
  • Day 8 was a simple tree problem involving both breadth-first and depth-first traversal. The depth-first part had a little twist that meant it took a little thinking about.
  • Day 9 caused me a few problems – partly due to some vague wording in the puzzle, and partly due to my not understanding the problem properly for a while. It was made worse by the fact that I initially decided to write it with the wrong data-structure because I felt it would be quicker. After a few false starts I gave up on that and finally made it work using circular linked lists.
  • Day 10 was another fun one involving points and velocities to work out when the points (stars) align to display a message. Initially I planned to switch to something with proper graphical support (in a fit of complete overkill, I fired up Unity) but settled in the end on a Ruby solution after I realised I could make the output fit in a terminal.

And that’s it so far! The most fun I’ve had so far was probably on day 7, while my least favourite has been day 6.

Taking part? Let me know in the comments what your favourite puzzle has been thus far.

Advertisements

Advent of Code 2018

This year I’m taking part in the awesome Advent of Code, and because I haven’t done a lot of Ruby over the past couple of years I thought this would be an excellent opportunity to refresh my skills.  In case you’re unfamiliar, AoC is a series of twenty-five coding challenges. Each day leading up to Christmas a new challenge is posted on the site, and there’s a global leaderboard. You can also have local leaderboards (We have one at BJSS for example).

I did originally consider using the opportunity to learn a new language, but the desire to get back to Ruby proved too strong. In truth, I’m glad it did – every time I come back to Ruby after a break, I’m pleasantly surprised by both the bits I’d forgotten and the bits that have been added.

Advent of Code 2018 is at https://adventofcode.com/2018 . In case you’re interested, I’m posting my solutions day-by-day on GitLab here: https://gitlab.com/rosco.peco/aoc-2018 (they’re only spoilers if you decide to look!)

There’s also a subreddit where you can follow the discussion and see some very cool solutions.

In short, if you haven’t already, you should check it out.

Generate less bytecode with default methods

Java’s default methods (introduced back in Java 8) are one of those features that solve the intended problem reasonably well, while at the same time allowing all kinds of nasty code and weird inheritance stuff when used in a general-purpose kind of way. Indeed, they’ve been the subject of a ton of posts and the way they (fail to) work still surprises people. They’ve been around for a while now, and there’s a lot of good advice out there on how they should and shouldn’t be used, so that’s not what I’m going to talk about in this post.

What I am going to talk about, however, is the way I’m using them in Moxy, as a way to do a lot less work in runtime-generated bytecode.

A bit of background

Moxy is a mock framework, and it does it’s job by generating mock classes at runtime. These mock classes naturally use a fair bit of bytecode generation, replacing real method implementations with new methods that implement the mock behaviour.

These mock methods do the standard mock thing of recording their invocation, and then they implement behaviour that has been set-up on the mock beforehand.

The problem

In order to implement this behaviour, mock objects need access to all kinds of state that’s specific to the instance – stubbed return values, exceptions they should throw, and more. They also need to have easy access to the mock engine that created them (so they can record invocations, for example).

This is often implemented via static methods on some class somewhere whose job it is to store state. The generated code will typically be peppered with a ton of invokestatic instructions that calls out to methods on those classes in order to get things done.

This works, but it has a few problems:

  • Some kind of mapping between instances and their state must be maintained.
  • It can make it difficult to swap out mock strategies in a clean fashion.
  • It can make testing (of the framework) difficult.

The Moxy approach

Instead of storing state statically, Moxy stores it right there in the mock, and all interaction with the state is done with instance methods. These methods can’t be inherited from a superclass (since mocks usually subclass the mocked class), and I really don’t want to generate them (I like to keep generated code to a minimum, as it’s harder to maintain and test that regular Java), so instead Moxy abuses default methods.

It works like this:

  • All mocks implement an interface, ASMMockSupport.
  • This interface defines one abstract method, __moxy_asm_ivars(). This method is implemented in generated code (since interfaces don’t have instance variables, the mocks hold the variables and expose them via this method)*.
  • The support interfaces defines a ton of default methods that do various kinds of work based on those instance variables.
  • The actual generated code for mocked methods uses invokeinterface calls on this to get stuff done as needed.
  • Other parts of the framework that interact with the mocks (e.g. stubbers) simple cast the mock instance to ASMMockSupport and call the methods they need.

* Yes, that’s a strange name for a method. Moxy does this to lessen the chances of its built-in methods clashing with methods being mocked.

 

The default methods on the support interface handle things like finding the engine that created the mock, adding stubbing, finding appropriate stubbing for a given invocation, running delegate methods and actions, and determining whether the current thread is currently in what Moxy calls a monitored invocation (used for recording purposes only, when mock behaviour is disabled).

This has the benefit that a whole lot of fairly-complex code that would otherwise be either generated, or stuffed into static methods, is now implemented, in Java, as instance methods. They’re easy to unit-test, and they’re easy to maintain. The added bonus is the generated bytecode is also easier to maintain, since it’s as short as possible.

Is this the intended use of default methods? Not at all. Is it correct, or appropriate? I’ll leave that to you to decide. I firmly believe, however, that in this very limited use-case it’s a good solution to a tricky problem, all things considered.

If you’re interested in looking at the code, you’ll find it here.

Just checking in…

Wow, so my last post was September? That’s just not good blogging, and for that I apologise… There’s been a lot going on, but this is no time for excuses – I’m just posting this to let you all know that I’m still here, still writing code (lately, not as much as I’d like, but there you go) and I’m soon going to be making a start on the huge list of Open Source stuff that’s been building up over the past few months. Here are a few highlights of what’s in store:

  • Some awesome new stuff will be going into ORMDroid very soon, with some great contributions from Jacob Ferrero including one-to-many support. I can only apologise to Jacob for the time it’s taking to get these reviewed and merged!
  • Speaking or ORMDroid, it must be about time for that 1.0 release…
  • I’m planning to finally finish up Deelang. It still needs the new parser architecture sorting out, and some bug-fixes, plus some decent documentation. It’s been sitting there for too long, it needs to be pushed out the door!
  • I have some new code to put into Mink, including some rudimentary user-mode bootstrap code, along with a basic round-robin scheduler and other basic bits that will allow development to continue. A lot of this code is written, but still shockingly untested and even-more-shockingly out of version control!

Outside of Open Source, I still have to do something with retroify.me, a fact I was reminded of the other day when the domain name came up for renewal. The annoying thing there is that it’s done – I just need a reasonably-priced swag supplier who can print up cool T-shirts and the like for people to buy (any suggestions much appreciated!). We’ve also got an exciting new venture on the verge of private beta, which we hope to be launching as a commercial product later in the year.

So, all in all, exciting times. Now I just have to actually get on and do all this stuff.

Watch this space.

 

And for your next project…

We’ve all been there – you’re at a bit of a loose end, you want to write some cool software, but try as you might you just can’t get inspired. There’s that vague idea you’ve been toying with for months, you know – the one that involves dependency injection, HTML Canvas and/or Haxe – but you’re not ready to make a start on that yet. You want something new.

If this sounds familiar, check this out (Warning: Maybe NSFW, depending on your employers). Boom – all the inspiration you could ever possibly want!

That’s all for now, I’m off to start work on my new Pascal wrapper for lightweight Lingo Blackberry applications that utilises the Singleton Pattern.

Git on Dropbox

People have been doing this for ages, but I’m a bit late to the Dropbox (if you don’t have it yet, here’s my referral link) party and have only been using it for a little while (only since I got a One X which had a tie-in deal going with HTC Sense and Dropbox) so it was nice to stumble across this blog article today while looking around for a free way to host private git repositories off-site.

The long and the short of it is that you create a remote repo in your dropbox directory, and then it just follows you everywhere you go. I have to say, I love how easy git makes all this. We’re still using Subversion for “the work stuff” but the day can’t be far off when we migrate over to git…