One thing to bear in mind when using Mockito matchers with Scala is that Mockito, being a Java library knows nothing of a Scala method’s default arguments.  So if you have a method like:

def myMethod(param: String, defaultStr: String = "defaultToThis")

and you try to mock it thusly:

when(mocked.myMethod(anyString))

you’ll probably be met with the following complaint from Mockito:

[info]   org.mockito.exceptions.misusing.InvalidUseOfMatchersException: Invalid use of argument matchers!
[info] 0 matchers expected, 2 recorded.
[info] This exception may occur if matchers are combined with raw values:
[info]     //incorrect:
[info]     someMethod(anyObject(), "raw String");
[info] When using matchers, all arguments have to be provided by matchers.
[info] For example:
[info]     //correct:
[info]     someMethod(anyObject(), eq("String by matcher"));

You can’t mix regular values with Mockito matchers when mocking a method’s behavior and the default values will be supplied as plain old values to the mockito object.  The only option is to call all the default parameters with matchers:

when(mocked.myMethod(anyString, anyString))

or if you want to be more specific (and generally you should):

when(mocked.myMethod(anyString, Matchers.eq("defaultToThis")))

(This highlights another gotcha.  eq is a method on AnyRef so it hides any static import of Matchers.eq).

I won’t go into my reasons for leaving other than to say that I’m super excited to be starting work at Top10 tomorrow! The name of the site speaks for itself as does the subtitle on the front page “The Top 10 of Everything, Created by Everyone”.

I love the concept of the site and where the guys are taking it. Top10 will be the first startup I’ve joined and I can’t wait to start working on the site with some new technologies and another great team.

Here are my Top 10s.

The script searches for the episode title in quotes plus the word Columbo (as episodes like “Undercover” and “Dead Weight” were returning a lot of false positives).  I’ll stick the script on github later, first I have to get to the supermarket before it closes.

Update: Script is on github.  It’s dead simple, probably could have just been a gist.  I got the list of episodes from here.  There are some sample results in the git project.

So you’ve been warned. If you’re building an app the uses twitter on app engine always OAuth authenticate, even when this seems unnecessary or a pain otherwise you’ll always be at the whim of twitter’s IP limiting. Obviously markovator always authenticates as @markovator now. If you usually authenticate on behalf of your users then you should use the twitter account you used to register your twitter app just for making those public, read only requests you might have thought could go unauthenticated.  You can avoid the OAuth flow by getting a single access token for that account from your twitter app page on dev.twitter.com

On a side note the account/rate_limit_status endpoint seems a little capricious. I have an admin endpoint that reports the status of the markovator app, including it’s authenticated rate limit status. When run locally it returns 350 per hour whilst when run on app engine it returns 20000 per hour.  Perhaps the whitelisted status of App Engine overrides the fact that the status request is authenticated.  Despite this the authenticated rate limiting does seem to apply when making authenticated requests from App Engine to Twitter.

Links:

• markovator on github
• Markovator – Python + Google App Engine + Markov chains + Twitter
• Relevant Stack Overflow question

I created a Tumblr blog for recording our minecraft adventures rather than filling this site up.

I’ve cross posted the original minecraft post from here and added a couple more.

• New Floor and a Better Farm
• Valentines Day

More to come soon. Enjoy

Singleplayer was great but what has been even more fun is setting up a server and convincing Caragh to join me in a multiplayer world.  Here are some screenshots of the action we’ve encountered so far.

This is the spawn location in our world, every time you die you’re yanked back here and all your stuff stays where you were so you have to run back and collect it before it disappears.

Caragh’s cutting down logs while I head off to find coal.  It’s important to gather coal and wood on your first day so you can craft torches to get through that long first night.

The sun’s going down which means the monsters will be coming out.  Time to start to build a shelter so we can hide away.

We’ve got a little hole to hide away in now, with a door, a furnace, crafting bench, a chest and most importantly, torch light.

At first the only thing to do at night is to start digging a mineshaft so you can mine out some raw materials like coal, iron and maybe even diamond.

Whilst mining you’ll often breakthrough into huge natural caverns or tight twisting passages with zombies and skeletons hiding around every corner.  It’s up to you whether to hastily brick them up or to grab a torch and a sword and venture in.

Caragh standing in a creeper crater.  Creepers will sneak up on you soundlessly before making a hissing noise and exploding.  Creeper death was our number two cause of death starting out, after falling down our mineshaft.

Eventually we get a nice set of castle walls up outside our shelter so we can come out at night in relative safety.  The plants down there are the start of a wheat farm and a sugar cane crop.

We built a porch out the front because we kept opening our front door to find a creeper or a spider waiting for us.  The elevated porch is harder for the creepers to get as near to and the glass allows us to look out and see where they are.

We expanded the inside around our mine a little bit and made cake.  The cake replenishes health and is made from the crops we farmed outside (and some eggs and milk).  We found the pumpkin outside and put a torch inside to make a Jack-O-Lantern.

I climbed a tall tree on the hillside to get a better view of our castle/shelter.  You can see the skylight that lights our mineshaft from here.

Venturing even further from home.

In the other direction is a huge island.  I can’t wait to take a boat over there and explore.

I attended the History Hackday at the Guardian and helped Gareth implement his cunning plan to scrape Wikipedia for all historical events with associated geo coordinates and present them chronologically.  The video above is the result.  Unfortunately I couldn’t be there on Sunday but whilst Gareth set about doing the hard bit, using Python and Mongo to extract the events from his dump of Wikipedia, I managed to code up a framework in Java for Gareth to produce the visualisation video from.  The dataset is pretty fuzzy, we went through each Wikipedia year page and kept all pages that were linked to for that year that also had coords.  I’m pretty pleased with the results, we won a prize for “best visualisation”, although I’d like to spend a little more time tweaking the graphics if I find the time.  The code is available on github.

The hackday itself was pretty cool, well stocked with beer, pizza and cool people. Props for a well organised event go to @fidothe, I’m sorry I couldn’t have been there for the whole thing.

The algorithm for the trails is relatively simple, each moves forward one unit and then chooses a random direction to travel in before moving forward another unit and picking another direction.  Each trail won’t pick a direction that will cause it to overlap with itself or another and will stop moving as soon as is it gets trapped.

The rendering was done using the 2D API that Android provides via the Canvas class.  The little lights at the end of active trails were achieved by faking a bloom effect by repeatedly rendering a circle with a number of BlurMaskFilters, each with a smaller radius than the last.

Most of the work was spent optimising various things.  A more optimised wallpaper will scroll better as the user drags between virtual home screens and will use less battery.  Memory allocation and garbage collection are generally quite expensive on the Dalvik VM so avoiding using the new keyword where ever possible, except on start up, is generally a good idea when optimising for Android (there is still some work to do here as both the Trail and Grid class frequently allocate new Point instances).  The DDMS eclipse tool that you get with Android is excellent for tracking these things.

The technique that seemed to give the greatest benefit in terms of performance was generating an offscreen buffer (an instance of Bitmap) to render the “terminated” trails to (active trails are moving too much so would invalidate the buffer on every frame).  Referencing the buffer with a SoftReference meant that the system could always garbage collect the image if it couldn’t spare the memory required.  This is generally good practice for all non-essential offscreen buffers when working on optimised UIs in Java where memory might be tight.

The wallpaper is fairly customisable in terms of appearance, you can alter the color scheme and appearance of the trails and can even set a lower frame rate if you’re worried about the wallpapers effect on battery life.  The wallpaper is available for free on the Android Market and you can find the code on Github.

QR Code for Neon Trails Live Wallpaper for Android

Can good TV shows have a dog eating cat poop.

October 16, 2010 6:48 pm via markovator_devReplyRetweetFavorite

@markovator_dev

Markovator Dev

As a child a chat bot program called NIALL made quite an impression on me.  It came on one of those demo floppy disks from some PC magazine I forget the name of now.  NIALL stands for Non Intelligent Acquired Language Learner and what it (he?) would do is remember each word you “said” to it and the frequency that any following word appeared after it.  So for example when given the sentence “the cat sat on the mat” NIALL would remember that “cat” always precedes “sat” but that “the” only precedes “cat” half the time, the other half of the time it precedes “mat”.  Whilst slowly building up this dataset of word frequencies with each message you would type in it would use them to generate its own nonsensical, sometimes amusing replies.  You can find a better description of the process on the how it works page of this GNOME implementation.

I most enjoyed the experience of “talking” to a computer and having it reply.  Whilst NIALL wouldn’t get within a million miles of passing the Turing test it was my first experience of any kind of a “chatbot”.  Additionally the accompanying explanation of how it worked (very similar to the gNiall explanation linked above) was simple concise and illustrated the technique quite clearly.  I’ve since always wanted to hack together a clone of NIALL as an exercise.  I’m sure I initiated a number of failed attempts in QBASIC but the required string manipulation would doubtless have been beyond my 10 year old programming brain.

With the recent realisation that the 2010 analog of a chatbot is a twitterbot and the need for a simple project to get to grips with Python on Google App Engine I needed no further excuse.  markovator is the result.  If you @mention him he will send you a reply generated NIALL-style from some of your recent tweets.  He will also follow you (feel free to block him if you don’t like this!) and occasionally send out a tweet made up of all the tweets of the people he is following.  markovator won’t use @mentions you’ve sent to other people so you won’t be the cause of him spamming your friends.

Here are a few of my favourite markovator tweets that were generated whilst developing him:

@HeyChinaski markovated: Criticker says it really needs to have randomly spammed BBC White City Tesco.

October 18, 2010 2:59 pm via markovator_devReplyRetweetFavorite

@markovator_dev

Markovator Dev

Lovely pub lunch with my favorite movies of his nose?

October 17, 2010 2:41 pm via markovator_devReplyRetweetFavorite

@markovator_dev

Markovator Dev

@HeyChinaski markovated: So Ben Affleck is way more grey hairs in my Ubuntu install. Bedtime.

October 18, 2010 2:58 pm via markovator_devReplyRetweetFavorite

@markovator_dev

Markovator Dev

markovator is so named because (as far as I understand the concept) the process of generating his tweets is a kind of Markov chain in that it “is a random process with the property that the next state depends only on the current state.”  The source can be found on github (sans twitter auth details of course).

To learn a bit about the HTML 5 canvas I’ve been writing a simple graphing visualization tool in Javascript.  Graphing in the sense of vertices connected by edges in a network, not in the pie chart and bar chart sense.  There is already a fairly decent charting library for  HTML 5; RGraph.

The canvas API itself is quite straightforward, it even makes things like drop shadows disappointingly simple.  In fact most of the time spent on this project was on implementing a force-directed graph layout algorithm in Javascript.  This was made easier by the fact that I’d already implemented it once in Java.  You can see a demo of the project here.

The canvas element is only available on “real” web browsers such as Firefox, Chrome, Opera and Safari.  Also performance of the layout algorithm is notably better in Chrome, particularly in comparison to Firefox 3.5.7 (on Ubuntu).  The demo can even render in Internet Explorer now thanks to Google’s ExplorerCanvas library although performance is so low that it is not recommended.  The time that the layout algorithm will take to complete is impossible to predict and so the layout will time out after a set time (around 15 seconds).  For this reason you are likely to get a substandard layout on particularly slow machines or when using browsers with poor Javascript performance.  The graph that is represented in the demo is generated at random so be sure to refresh the page a few times to see the tool handle a number of graph structures.

The tool is currently quite limited.  There is only one layout algorithm available* which could be better optimised.  There are no ways to navigate the graph by zooming or panning and the appearance of the graph is currently limited to the white on blue default presented in the demo.  The graph can visualise any data as long as it is expressed in a certain format, easily described in JSON.  However it does add properties to that data when it lays out and renders the graph.  This would ideally be avoided.  I hope to address these issues in the future, particularly in regard to navigating the graph and customising the appearance, specifically so as to be able to visually distinguish and label the vertices.

The project along with it’s source is available under the MIT license from github.

HeyGraph Demo

*(although in my opinion force directed layout’s are appropriate for most small to medium size graphs) <