Expanding horizons

Wednesday, 22 June 2016

I’ve been running a Code Club at Fleetville Junior School in St Albans for the past four years and we have a whole load of fun programming and making things with computers.

About a year and a half ago, I introduced some Minecraft challenges to the club and soon discovered that it was the genie that can’t be put back into the bottle…

But what a genie! The students have been programming virtual turtles to build and dig their way through challenges, culminating in designing and building huge bridges across an endless ocean (seetheirvideos). They can’t get enough of being in Minecraft — even if they’re not allowed to kill each other or blow things up!

For the follow-on project from the bridge building, I wanted to give the students the chance to create something without programming — so I asked them to build a model of their school in Minecraft. They loved the idea!

I wanted the students to build the model themselves, but they needed a guide to help them get things to scale. I figured that a flat map of the school buildings sitting in the Minecraft world would be a good place to start.

Google Maps has a good detailed view of the outside of the school, but this wouldn’t help with the interior rooms. Luckily the school had a PDF architectural plan of the school that they were happy to contribute.

I took a screenshot of the Google Earth aerial imagery of the school and its grounds and then combined the image with the architectural plan in a drawing program.

The next step was to convert the image into a Minecraft “schematic” file — this is a file that can be imported into a world using the WorldEdit mod.
There’s a great little program called Spritecraft that does exactly this job. You’ll need the (paid for) Full version of Spritecraft to export as a schematic, but all the money goes to a children’s charity.

It took me a little while to adjust the image to give a good output in Spritecraft. First of all, I had to adjust the architectural plan to make it a bit more chunky — those fine lines just didn’t make it into the block-based world of Minecraft. Filling in the walls and removing the door symbols helped a lot, as did setting the windows to a contrasting colour (don’t forget that some students might be colour blind).

Secondly I had to choose a scale… I measured the outside of the school using Google Maps (right-click on a starting point and choose “Measure Distance” then left-click on the end point) and compared this to the number of pixels across the school in the image. Although Minecraft is all set up to use one block to one metre, using this default scale made the school corridors too narrow at just one block wide!

For my build, a scale of 1.5 blocks to 1 metre seemed to work better — the corridors were a couple of blocks wide and the building didn’t seem too large. This might be different for your build — so play around and see what works for you. Here's the result:

Finally, I exported the schematic file from Spritecraft and copied it into the correct server directory (for MinecraftEdu that’s server/schematics but it may be different for your server). Then in a flat Minecraft world, I used the WorldEdit //schematic load <filename> and //paste commands to make the plan appear on the ground.

For our school there was an extra complication — the whole school is built on a slope, with steps and ramps along the corridors. To ensure the floor level ended up in the right place, I asked the students to start building at the lowest point of the school and then create the corridors (with their slopes and steps) before creating the classrooms.

This has been a really successful project so far. The students have made some really detailed rooms, complete with furniture, automated lighting systems(!) and non-player characters acting as teachers.

Here’s some pictures of their build so far — I hope to make another video before the end of term of the students giving a guided tour…

If this has helped you and you’ve created something from the real world in Minecraft (especially another school), please comment below — I’d love to hear from you!

Thursday, 17 March 2016

Last month Facebook invited mobile developers into their London offices for a collaborative discussion on scaling mobile development.

The focus was mainly on native development — and the attendees were mostly iOS and Android developers — but the scope expanded to include scaling development processes as well as how to scale apps for lots of users.

Jim Purbrick @JimPurbrick, Engineering Manager in Facebook London’s office, introduced the talks by saying that on mobile, the bug stakes are higher — once a bug is released, the app is on people’s phones and is much harder to fix. You can’t just update the code and see people get the fix in the next page refresh.

And for all the focus on ending up with a native app in the platform-specific app store, two of the big themes were sharing code across platforms and being able to make quick changes to apps that were already deployed.

I was impressed by the inclusivity of the conference — not only were the speakers from a variety of companies (not just Facebook or Facebook partners) but the audience were encouraged and given time to ask questions and discuss with the speakers.

The talks and discussions were all videoed and I’ve linked to them below together with my notes highlighting the points that made an impression on me.

Scaling iOS @ Google

Michele Aiello@micheleaiello, Tech Lead Manager on the Calendar app, Google

Michele gave a really detailed talk about how the iOS teams at Google deal with handling large amounts of code shared amongst many geographically spread developers. There’s lots of useful nuggets in here — and it’s interesting to see where Google have invested time and effort in order to make cross-platform and large team development easier.

When mobile IDEs need to scale

Al talked about how Facebook builds Android apps, and how they feed back improvements to their build process into the open source community (e.g. IntelliJ community edition and the Buck build tool). By using Buck, they allow their developers to choose whatever IDE they want.

Nuclide

James continued from Al’s Android introduction to talk about Facebook’s new Nuclide IDE for building iOS apps… It’s exciting to see some competition in the iOS IDE world — whilst Xcode is great at some things, it often leaves a lot to be desired. JetBrains’ AppCode is a useful challenger but to have an extensible open-source IDE for iOS could be a game changer. The only downside for me is that Nuclide relies on Buck, so you have to change your project to buy in to the Facebook toolchain. Perhaps if someone could create a Fastlane plug-in…?

6 lessons learned scaling mobile at SoundCloud

Next up were a couple of sessions from smaller companies (though still not small!) showing how they built and adapted their apps faster to keep up with demand. SoundCloud spoke about using ReactNative (more on that later) and how they structured their dev teams to include mobile developers.

Backend-driven native UIs

Spotify have an almost completely content-based app and are constantly tweaking to change the presentation and priority of different music. John and his team came up with a way of handling that change by controlling the whole app UI from the backend API.

can set up fallback components — if this not available, fallback to previous

enables playing around with new features & UI but still supporting older builds

Infer: Moving fast with static analysis

Dulma Churchill, Software Engineer, Facebook

Taking up Jim Purbrick’s challenge of dealing with the higher stakes of bugs in mobile, Dulma gave us an introduction to Infer — Facebook’s static analyzer that can check for memory and resource leaks and null pointer issues each time you compile.

Don’t forget the web

After all that talk of native development, Jeremy brought us back to thinking about the web and how it will always be the largest, widest target. It isn’t a “platform” and it will never be the leading edge of mobile, but it is for everybody.