geek!daily

Setting Up A Minecraft Server For Kids, Part 1: Preparation

I've got a little more time on my hands than usual at the moment, so I decided to set up a Minecraft server for my son and his friends. I figured it would force me to play around with cloud APIs, some linux configuration that I haven't done for a long while, and other various bits of geekery that would just make me happy.

As I started to do some research on how to go about it, I found about a gajillion posts on how to set up a server (including this slightly outdated gem), including a few from smart friends of mine. After a bit of reading, it became clear that this could be a much larger undertaking so I decided to chunk out the project into four steps:

1. Preparation: research and learning
2. Installation: set up the instance and server
3. Configuration: tweak the server config and add plugins to get what you're looking for
4. Productionization: make the installation reproducible and automatable; set up backups; etc. And yeah, that's not a real word. I'm okay with that.

This post will focus on the preparation required to get as many bits sorted out as you can before installing. I'll write about the rest in the next few posts.

So, Minecraft ...

If, like me, you came to this with little practical Minecraft experience, the first thing you should do is try playing a bit. There are a few free ways to do this — such as Minecraft Classic in your browser or Minecraft Pocket Edition Lite on an iOS device — or you can just spend the ~$30 and jump in. I figured that to be an op I'd want my own account, so I went for the full experience.

I died a lot. I crafted a bit. I created a bunch in single player. I joined a few multiplayer servers. I died some more. Through all of it, I got a sense of the game and what my son and his friends would be in for. This helped a lot as I started to figure out what it would take to start up and run a server, as it identified some key questions, like, "How can we have a creative world as well as a survival world?" and "What's the difference between 'easy' and 'peaceful'?"

These led me to the Minecraft Wiki. Frankly, had I read much of it before playing I would have died less and crafted more. However, it helped me get clear on a few things that matter when you're considering running a server for others.

Game Mode

The default is survival mode, which means that, in order to survive and craft things, you have to walk around and collect block types required by recipes while avoiding being killed by monsters ("mobs" in the old MUD parlance). There's also creative mode, where you gain the power of flight, you have access to every block type instantly, and you can make anything your heart desires. My son is currently constructing a flush toilet in the hotel he's making. His heart desires strange things.

Difficulty

This ranges from Peaceful, where any aggressive mobs are removed or don't spawn, through Easy and Normal, right into Hard. The wiki does an excellent job explaining.

World Types

There are a few settings in there that weren't obvious on the face of it, such as what Large Biomes is or why Superflat would be interesting. It turns out that Superflat is a great canvas for Creative worlds, and Large Biomes is pretty much just like the default biome-based terrain generator but each biome takes up more real estate.

It was clear to me that we'd want a Superflat Creative world and an Easy Default Survival world.

Servers, Servers Everywhere

There are a lot of available servers out there. I could tell you that I did an exhaustive search and evaluation, but the truth is that I trusted my smart friend, Sarah, and chose Craftbukkit (CB) for many of the same reasons she did: we both know and trust Tom Enebo's opinion, it's easy to extend using JRuby, and it seems to be the leading server beyond vanilla Minecraft.

Another bit of validation comes from cheracc, who runs Sandlot Minecraft server for kids and families, and who also uses CB with many plugins. More on that later, though you can read his excellent Reddit post on setting up a Minecraft server for kids now.

One other minor note: since CB is a third-party server, it takes them a bit of time to catch up when Mojang releases a new client version. This means you'll want to wait on client updates until there's a beta version of CB that handles the new client version. As of this writing, the current client requires a 1.5.x server which means craftbukkit-beta.jar

Does Size Matter?

Finally, I wanted to figure out how big an instance I'd need to host a decent server. I flailed my way through several posts trying to figure this out until I discovered Can I Host A Minecraft Server, which makes it easy to take your bandwidth (both up and down) and the available RAM and figure out about how many people you can host. Remember to use the bandwidth figures for the cloud provider you're planning to use. For me, it turns out I can handle ~12 players in a 1GB instance with the usual cloud host network speeds of >5Mbps, which is what I was hoping to cover.

So that's it for prep. Now it's time to instantiate and install.

Bashing tcsh

After 15 years of non-stop tcsh action, I've finally made the jump to bash. It was painful and I miss all my lovely variable expansion (^X $), wildcard expansion (^X*) and term completion (ESC-/), but there are so many tools like rbenv that expect that you're using bash with no tcsh-friendly alternatives.

On the upside, I've got functions now. I guess that's something.

Oh, and hi again.

Generate the regex for a TLD hostname from Perl

This was a quick, fun exercise to remind me that I can still write Perl. It fetches the list of TLDs from IANA, does a quick bit of munging, then renders a regex which should match any valid FQDN:

#!/usr/bin/env perl
use strict;
use warnings;

use LWP::Simple;

my $fqdn_regex;

if (my $content = get('http://data.iana.org/TLD/tlds-alpha-by-domain.txt')) {
  $fqdn_regex = '(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+(?:';
  $fqdn_regex .= join('|', grep (!/^(#|xn)/i, (split /\n/, lc($content))));
  $fqdn_regex .= ')';
}

my $regex = $fqdn_regex . '(?:\s|\/|$)';
print "$regex\n";

Several caveats:

• It doesn't match IPv4 dotted quad nor IPv6 ::-notation
• It intentionally ignores Internationalized Domain Name in Applications (IDNA) domains
• It borrows from my favorite reference for this, regular-expressions.info's page on email address regexes.

Maybe I'll extend it for completeness and/or rewrite it in Ruby someday. Until then, it'll always be ~/bin/tld_regex for me.

Generating with Ruby OFF Rails

I'm spending a fair amount of my time working on non-Rails Ruby projects lately and I've been missing the fine code generation toys in Rails. So tonight, for the fun of it and because I was hankering to play with cucumber, I hacked up the minimal set of bits that gets you script/generate in your non-Rails project.

This is how we do it:

> mkdir my_non_rails_proj
> cd my_non_rails_proj
> mkdir script config
> touch config/environment.rb
> cat > config/boot.rb
RAILS_ROOT = "#{File.dirname(__FILE__)}/.." unless defined?(RAILS_ROOT)
RAILS_ENV = nil
require 'rubygems'
require 'initializer'

Rails.configuration = Rails::Configuration.new
^D
> cp -p /path/to/gems/rails-2.3.2/bin/generate script/.
> ./script/generate
Usage: ./script/generate generator [options] [args]
Rails Info:
 -v, --version     Show the Rails version number and quit.
 -h, --help      Show this help message and quit.
[...]
> ./script/generate cucumber
  create features/step_definitions
  create features/step_definitions/webrat_steps.rb
  create features/support
  create features/support/env.rb
  create features/support/paths.rb
  create lib/tasks
  create lib/tasks/cucumber.rake
  create script/cucumber
> touch Rakefile
> rake features
[... large lack of FAIL ...]
>

Voila! Not guaranteed to work for all Rails generators, but it bootstrapped rspec and cucumber just fine, which was the point of my exercise. Someday I'll make a generator:bootstrap rake task or gem something if I need to do it again.

Re-finding my rubyligion ...

Life's been busy. Good, but busy. My gig at LinkedIn, two hours of commuting each day, plus our four person plus dog family certainly keeps me awash in things I should be doing. Thing is, ever since I stepped away from managing LinkedIn's rubyists, I haven't had much to keep me practicing my Ruby skills or tied to the Ruby community. That's made me a bit sad.

So, for the last few months, I've been finding spare-time, non-urgent Ruby projects on github to play with, forking them when I'm ready to make contributions. The one I'm currently twiddling most is a fork of Jon Maddox's IMDB library. He got the very basics in to deal with movies; I'm expanding it to handle TV series and episodes as well. In the process, I've added testing and some heavy refactoring, mostly to arrange the libraries in a more idiomatic fashion but also to swap out Hpricot for Nokogiri (sorry, why, but Nokogiri has better support for complex XPath and XSLT fun that simplifies some of the code dramatically).

I'm also digging into the guts of the Confluence4R and Jira4R libraries (and I am gratefully indebted to Ben Walding for setting up a github mirror of the Jira4R main git repo at Codehaus); for them, I'm mostly adding spec code to demonstrate what I think is true as I'm learning. Jira4R is driving me a bit nuts -- I'm having a love/hate relationship with its wsdl2ruby underpinnings. Slowly I learn.

But, then, that's the point, isn't it?

Cuzillion: 'cuz there's a zillion pages to check

Once in a while I get lucky. Most recently, this means that I was asked to write a blog post for LinkedIn about the tech talk Steve Souders gave for us last week: Even Faster Web Sites. Unfortunately, in the interests of brevity, I couldn't dive on something incidental to the talk which fascinated me: Cuzillion.

Cuzillion is one of those headslappers Steve seems to produce on a regular basis; it's a tool to model web pages and experiment with load order and methodology in order to better understand performance bottlenecks and find your way to a solution. He uses it to illustrate examples in his talks of late (as he did in the slides for his talk at LinkedIn), which highlights another feature: the ability to share a precise example among the team seeking a solution. It fascinates me because it's so straightforward and so obviously useful, yet you can twiddle it to great depth, willfully violating all the well-known best practices, and see clearly why that's not a good idea. It's like checkers: you get the basics instantly, and yet there's so much more there.

After playing with it for a while, it occurred to me that I very much want to say, "Cuzillion, go model the way this web page loads so I can play with it." When Steve announced Cuzillion, he mentioned that he intends to set up a Google Code repo for Cuzillion; when he gets around to that, it might be fun to spend a little time adding that feature.

Check it.

Old & Rusty to Shiny & New, Part 1

I'm feeling particularly masochistic today, so I'm going to tackle a project I've been putting off for a while: moving a Rails 1.2.6 app in our subversion repository into github, then updating it to Rails 2.1.

The first part, getting from svn to github, should be relatively painless according to github's "Importing From SVN" guide. It is, as long as you have already created your github repo (I hadn't) and already have git-svn installed (I didn't). So here's the expanded tutorial

1. Create your github repo

2. Be sure you have git-svn installed. I didn't, so here's what I had to do:

sudo port uninstall git-core
sudo port install git-core +svn

I had a bit of trouble with the serf port breaking during build time:

--->  Building serf with target all
Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_www_serf/work/serf-0.2.0" && make all " returned error 2
Command output: /opt/local/share/apr-1/build/libtool --silent --mode=compile /usr/bin/gcc-4.0 -O2 -I/opt/local/include -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp -I. -I/opt/local/include/apr-1 -I/opt/local/include/apr-1  -c -o buckets/aggregate_buckets.lo buckets/aggregate_buckets.c && touch buckets/aggregate_buckets.lo
libtool: compile: unable to infer tagged configuration
libtool: compile: specify a tag with `--tag'
make: *** [buckets/aggregate_buckets.lo] Error 1

Error: The following dependencies failed to build: p5-svn-simple subversion-perlbindings serf p5-term-readkey
Error: Status 1 encountered during processing.

... so I got all medieval on it, building it manually, then finishing the port install:

> cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_www_serf/work/serf-0.2.0"
> head config.status
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure, which was
generated by GNU Autoconf 2.61.  Invocation command line was

  $ ./configure --prefix=/opt/local --with-apr=/opt/local --with-apr-util=/opt/local

## --------- ##
## Platform. ##
> sudo ./configure --prefix=/opt/local --with-apr=/opt/local --with-apr-util=/opt/local
[...generally successful configuration noises...]
> sudo make all
> [...generally successful build noises...]
> cd -
> sudo port install serf
[...generally successful install noises...]
> sudo port install git-core +svn
[...more generally successful install noises...]

3. Create an authors file

I made mine as authors.txt; it looks kinda like:

jim = Jim Meyer <jim@...>
joe = Joe DiMaggio<joe@...>

4. Run the commands from the github guide. My pseudo-values included below:

$ git-svn --authors-file authors.txt clone http://events-svn.example.com/ events_tmp
$ cd events_tmp
$ git remote add origin git@github.com:my_github_username/events.git
$ git push origin master

...é voila! It's done! It even (quite cleverly) recognized other authors and properly linked them. Very nice!

Using mysqldump with subqueries

I needed to dump some very specific portions of a large MySQL database; some of the data were second-degree relations (aka a Rails has-many-through). mysqldump won't allow a join in the --where clause, but it will allow a subquery, so I ended up with something that looked a bit like this:

mysqldump --lock-all-tables --where 'id in (select user_id from memberships where site_id = 123)' my_database users

Handy, that. Thanks to Austriaco who was doing this in a similar context.

OLPC: You Know, For Kids ... Theirs *and* Yours.

I just tripped over this video:

... which leads to the OLPC Laptop Giving website. The gist of it is that for $400 you can get an XO laptop for your kids ... and give one to kids who'll use it to change the world.

I think Sam's going to have a very happy holiday.

Live Blog: Graphing Social Patterns, Day 1, Geek Track, Late Afternoon

Despite being individually wonderful, fresh-popped popcorn and hot coffee don't go together at all. Bye bye, popcorn.

Jia Shen and Raymond (?) from RockYou! talking about launching and distributing your FB app. RockYou are the folks who brought Werewolves, Vampires, and SuperWall, as well as GlitterText.

Widgets for MySpace, Bebo, Friendster, are all like clothing -- self-expressive, no user interaction.

Facebook supports this, but also offers user engagement. It's like a MMORPG vs. the single-player games of the others.

Networks with engagement gives you ~7x more distribution.

(He showed quantcast rockyou.com web statistics)

RockYou is helping monetize now by offering an ad network on FB, both for use by developers to monetize their apps as well as seeking good matches between their apps and advertisers (e.g. Zombies & Resident Evil movie)

New application setup page walkthru:

Add FB Dev app, create a new app, *make sure it's checked on to allow folks to add it*. You can limit that to developers only further down the config.

Picking a good name: expressive, short, and catchy.

Callback URL is your server.

Interaction is: FB App page -> your callback URL -> returns text (FBML) -> FB puts it on the page

You can do iframe within FBML, so there's little advantage to doing iframe instead of FBML.

Developers of your app will be able to see debug messages (as comments in rendered HTML).

Post-Add URL: where you go when someone adds the app. Default is profile page; this is a great opportunity to move them into your app's design flow -- help them take the next step

Post-Remove URL: Isn't called in user space, but at backend.

Adding left vs. right: right side's wider, left will likely place you higher.

*BE SURE TO SET DEVELOPER MODE* They have a dev app with 300K users because they forgot. You don't want to deal with this.

Side Nav URL: set this! users like to nav to the app from there; if you leave it empty, you don't show up.

Private installation is good for dev mode -- don't announce you're adding your test/dev apps.

Make sure to have a banner/splash/screenshot for the app when you're ready to submit it. It shows on the profile page.

insert much configurational fun as we all make dirs on the rockyou dev server. If you want to see what my "app" is up to, it's here.

Each request sends the following pieces in the session:

• fb_sig_session_key: session key (hopefully infinite)
• fb_sig_user: uid
• fb_sig_added: boolean 1/0, is it added
• fb_sig_time: current time, float sec since epoch
• fb_sig_friends: comma sep'd list of uids

The wiki is a treasure trove. Keep it open all the time.

Tracking

You need to know you're tuning your app in the right direction. Here's some good stats to track:

• Infinite Sessions
• Page Views
• Installs/Uninstalls
• Invites Sent/Opened

If you have infinite session key, you can look at their info for as long as you're installed. Allows you to regen their profile regularly, etc.

Use Google Analytics, Quantcast to capture stats.

Not sure if FBJS allows Google Urchin yet.

Google Analytics doesn't manage to capture good stats (gets bad total uniques/page views) sometimes if you're doing "fancy things" where Quantcast is very straightforward, brute-force and rock-solid reliable.

Tracking via post-add URL: how are you getting installed? day-to-day growth is important for sensing how your user community is reacting. Set "next" parameter (&next=...) and send to something that reacts dynamically to that param.

Tracking via post-remove URL:  gets called at uninstall; just be sure you're being pinged by FB and catch the user id. You don't have to ditch their info, but note that they've uninstalled.

Debugging

You must have a dev app and a production app.

FB Dev blog explains how to make test accounts which won't be removed.

Use cases: They're looking at your app but haven't added; they've added; they're looking at someone's profile and have/don't have your app, .... Be sure you consider them all.

Look at HTML for debug info; it shows you everything FB set and sent in a comment.

Firebug: use the console to see the AJAX calls to be sure that the request went out right and got a good response.

Test on all browsers, including IE 6 & 7. Use Fiddler (Windows only HTTP debugging proxy) to see all the calls in IE.

Be sure your browser isn't caching content you expect to be updated.

MS Script Debugger for debugging JS. Allows you to break into JS and step thru.

File logging, email notifications in your app: you'll see invisible errors and track production issues.

Invites

FB gives multi-selector for picking your friends.

fb:request_form tag gives you an easy

After the user clicks the action in invites (either to do it or skip it) you can take care of them (preview, thank, etc). FB tells you who's been sent an invite (friend_ids)

Profile FBML is cached at FB, as are images. You can use API to invalidate cache data.

FB:Refs are also cached.

 

FB carries the bulk of the load. Usually scaling is a DB issue on your side.

Amazon EC2 and S3 are very useful for doing big FB apps.

And then we ran out of time. Jia and Raymond ran a tight session. It kept moving, they actively made sure everyone was moving along well, and I actually got an app running. They kept it really simple, from Hello World to some basic essential concepts, no DB, nothing unnecessary. An ideally structured hands-on workshop.