Nokia Lumia 900

Those of you who have been following my blog and my tweets know that I’m something of a polyglot and polyphone - I program in many different languages and I’ve used many different phones. I used the Palm Pre and it’s unified contacts and messaging systems years ago, before such a feature was even a twinkle in the eye of either Apple or Microsoft. I’ve owned and developed for the original iPhone, the 3, the 3G, the 4, and the 4S. I’ve owned an iPad 1, an iPad 2, and “the new iPad formerly called the iPad 3″. I’ve owned the Samsung Windows Phone and now own the Nokia Lumia 900.

The first thing to notice about the Lumia 900 is that it is big. It’s not just that it looks big, but it feels big. It’s heavier than the iPhone and takes up substantially more palm space. Back when I first held one of the Lumias in my hands, I was originally turned off by this – the last thing I wanted was a bigger phone. Now that I’ve had a chance to use the phone for more than just a quick in-store demo, I have completely changed my mind on that. The size, weight, and overall feel of this device is absolutely perfect.

The next thing I noticed about this phone is that it’s fast. Not just kinda fast or faster than my iPhone but it is blazingly fast. No matter what I do I can’t get any of the UI to skip, jitter, pause, or have any of the other weird issues that my Samsung used to have. Couple that with the brilliant, giant display and this phone is a freaking joy to use.

Even with all of iOS’ recent advances, I still hate the walled-off silo feeling you get from each application where even the ones that have been modified to work together still feel like a hack. This is in stark contrast to the smooth, effortless way I can sift through Facebook, LinkedIn, and Twitter updates from all of my contacts in a single place. As mentioned in previous blog posts, Windows Phone is designed specifically to get out of my way and give me what I want, when I want it, in an elegantly minimalist way.

Specific to the Nokia is the “Nokia Blue” color scheme, which is by far my favorite of any of the stock color options. Other things specific to the Nokia are a pile of awesome ring tones and notification sounds that are far better than the stock Microsoft options. Finally, the other thing that Nokia did that they deserve huge credit for is the “App Highlights” app.

I mentioned in a previous blog post that the state of the Windows Phone marketplace is disgusting at the moment. It is littered with crap, more crap, porn, some more crap, first party games, and a few gems struggling to shine in a sea of even more crap. Nokia has human curators who troll the marketplace and find the best of the best, the stuff we’re all looking for but don’t know we’re looking for it how to find it. Until the Marketplace gets better, I’ll be using the App Highlights app to find new stuff, not the Marketplace. I trust Nokia’s curators more than I do the automated ranking/relevance algorithm currently screwing the marketplace.

Something that Windows Phones have been doing for a while now that no iOS device does is bluetooth audio text-to-speech reading aloud of your incoming text messages. In addition, you can dictate outbound text messages, which makes for an awesome experience in a car that has bluetooth. I can make and receive calls and texts smoothly using nothing but audio and speech controls. The Lumia has this feature the same as other Windows Phone 7+ devices.

If you are an “app addict” like so many iOS users, where your smart phone experience has nothing to do with the phone and everything to do with the apps, then you may still find Windows Phone lacking. However, if you actually want to use the “smart” in your “smart phone”, then you’ll not find a better device than the Nokia Lumia 900.

One thing that I did with Akka 1.x was I exposed public state properties on various actors. While this fixed my problem, it was a bad smell that I didn’t notice at the time. In my ScalaMUD sample, I switched and used an implicit that wraps an external hash map to maintain state of actors. I now even think this is a bad idea and in a new project (yet to be disclosed) I am currently trying to avoid exposing -any- public state on any actors.

The current challenge that I seem to be running into is in figuring out the level of granularity of my actor system. In other words, how do I decide when to create more actors or when to do the work necessary within a def  as a plain Scala function?

I’ve come up with the following set of questions that I ask myself now:

1. Should this work take place concurrently?  If the work in question is something that I think should be fired off in the background, then this is a huge argument leaning toward the use of an Actor.
2. Do multiple other actors need this service performed? If the code I’m about to put into a function is something that other actors in the system also need done, then I should really consider using an Actor that performs the work on demand by receiving a message rather than a function. That said, keep in mind that multiple Actors can all make use of shared Scala objects/classes – so re-evaluate the problem against other criteria in this list as well.
3. Is this operation purely synchronous or request/response? If so, then you might not need or want to use an actor for it. Sure, there is plenty of syntactical support for request-and-await-reply blocking calls in Akka but the more of those you do, the uglier and harder to read your code gets. If you really need to perform a synchronous, blocking functional call then it might be better as a function and not an Actor.
4. Is this really a data storage/retrieval operation? If the work you’re considering offloading to an Actor is actually data storage like putting and getting from hash tables or something similar then you might not need an Actor for it. That said, if the act of storing or retrieving might take a while and you don’t want to block during this, sending a message to a “data actor” and going about your business might actually be the best thing for it.
5. Does my current Actor respond to too many messages? One thing I’ve noticed during my work with ScalaMUD is that I’ve created Actors that do too much. Actors, in my experience, seem to be work better the smaller and more purpose-built they are. The actor system has a robust supervisory system that makes actors that control other actors not only possible, but a best practice. I’ve gotten tremendous value from refactoring one big Actor into multiple smaller actors.
6. Do I need supervisory control over a service that is being performed? As mentioned above, if there is some service that needs to be performed but you want control over how your application reacts to failures like exceptions, then using a supervisor and wrapping that service as an Actor and setting a control policy can do you a world of good. For example, you can set it so the supervisor receives messages when the child throws an exception, or you can have Akka automatically restart dead child actors. The possibilities are as powerful as they are varied.
7. Does this operation need to be thread-safe? If the answer is yes, then you might want to use an actor. The reason for this is that actors pull their messages out of queues in a single thread, which means no work you do in response to receiving a message is ever re-entrant, so you don’t need locks or critical sections. This alone is quite possibly one of the single biggest advantages of actor-based programming and design.

Obviously your mileage may vary and I am still an Akka/Scala newbie but what I have found, especially with my newest project, is that my application almost designs itself automatically when I think in terms of autonomous, supervisory-linked actors rather than thinking in terms of traditional OOP.

I recently tweeted the following statement and I still believe it is true: Actors are to OOP what OOP was to procedural programming.

When the “shiny new” iPad was announced my first reaction was “meh”. I really wasn’t all that impressed. Sure, it had a shiny new retina display but the difficulty Apple has to overcome isn’t convincing people that an iPad is awesome, it’s convincing owners of an iPad 2 that an iPad 3 is awesome enough to warrant forking over what I believe is a flaming truckload of cash. While these things are awesome, the only reason I can even condone purchasing one for myself is that they are tax deductions for my freelance development business and technical writing.

Case in point – I wouldn’t buy it for myself, it had to be given to me as an early birthday present. So, is the hype on the iPad 3 worth it?

The first thing I noticed when I unboxed the new iPad is that it’s heavy. Typically you have to put new devices on a scale to notice the different in weight but, even just holding one iPad in either hand, it’s very obvious that the new iPad weighs a bit more. It’s not enough so that it’s going to stop me from using it but it does have a more noticeable heft to it.

The next thing I noticed was that when setting up the new iPad, it asked me if I wanted to enable dictation. Dictation? I’d never seen this option on the iPad 2 and I didn’t remember hearing about it in the rumor mill. As a writer, the idea of getting dictation services on my iPad is pretty appealing. While dictation is there, iPad 3 has no “Siri” on it, which is fine by me. In another blog post, I will post a review of the dictation ability from an author’s point of view rather than just someone wanting to dictate an e-mail message.

Everyone raves about the new horsepower of the device – it has a better processor in it with more cores blah blah… For most applications that I tried I couldn’t tell the difference between how they ran on the iPad 2 and how they ran on the new device. The only ones that showed noticeable differences were the higher-end apps like 3d games and video streaming apps. A large portion of what I use my iPad for is watching video so this is a good thing for me. I’ve actually seen some videos of people doing speed tests where the iPad 2 comes out ahead in most situations. My experience is that the 3 has a much better display and is no slower, and visibly faster in video rendering, so that’s a plus.

All in all I’m really happy with the device and can’t wait to try out the dictation feature – of course you can’t use dictation on a train or a plane without annoying your neighbors so I wonder about where I might be able to use it. Is the new iPad 3 worth all the hype? Maybe, it’s an upgrade but a minor one. Is it worth the money? I don’t think so, but that hasn’t stopped me from owning it

I still firmly believe this. From an overall experience point of view, Windows Phone allows me smoother, faster, more efficient access to everything I need than iOS. My common everyday workflows on a Windows Phone are faster and less intrusive than they are on an iOS device (I won’t even talk about Android… I can barely stomach 30 seconds of interaction with most droids).

So, if I still think that the core of Windows Phone 7 is so awesome, why is the word disappoint in the title of this blog post? The answer is simple: the marketplace or the “app store”. Today, long after the “it’s just a v1 product” excuse has expired, I can go to the Windows Phone marketplace and I become nauseous with what I see there.

Firstly, if you look at the list of top games in the Marketplace, they are either first-party (Microsoft made them or paid someone else to make them under their iron fist) or they are made by giant third-parties like Electronic Arts or any of it’s 80 bajilion subsidiaries. You still see a few good examples of non-MS games but, the point remains – Microsoft and the other gaming giants pretty much own that segment of the Marketplace. This is completely explainable – making a game for a mobile platform is a pure and simple ROI (Return on Investment) calculation. How many potential buyers are there * price per game – production cost total / potential buyers = potential profit. The reason we don’t see as many ports of ridiculously popular iOS games is simple: the ports would probably cost more to make than they would earn. Note probably there, because that notion is very subjective and easily influenced by the paranoia of any given decision maker. Bottom line? Developers are still skeptical.

Secondly is the experience of the marketplace. When I flip through Apple’s App Store, I see a wide variety of great stuff – so much stuff, in fact, that I can’t possibly sift through it all. However, I feel somewhat confident that Apple’s “featured”, “popular”, and other filtering and sorting systems will allow me to find relatively good examples of the type of application I am looking for.

Today, when I go sifting through the Windows Phone marketplace, I feel like I’m walking through the “old times square”. You know, the one that used to be peppered on all sides by strip clubs, peep shows, adult video stores, with a drug dealer on every corner. I’m not exaggerating – In the “most popular” filter for most of the apps in the marketplace I regularly skim past 4 or 5 apps with half-naked women on their icon. I understand that Microsoft may not have full control over this because, after all, if boobs are popular, then boobs are popular and what can they do about it??

The problem is that I can’t see the forest for the trees in their marketplace. I cannot find anything with ease and often some of the most amazing Windows Phone apps don’t show up anywhere – I have to search for them by obtuse keywords that friends have given me who told me about these great applications. Not only is the marketplace diluted with immature fart apps, “boobs” apps, and other garbage for which I have no use, but the worst offense of all is that the marketplace is sinking under a deluge of irrelevant stuff that they could easily filter out. It would literally take them a few hours. But they don’t do it.

Every single time I go to the marketplace to check out what’s new, I see countless apps written entirely in foreign languages that are obviously designed for foreign audiences. If I have to scroll past 150 apps (this is also not an exaggeration, this happened to me recently) just to see something that actually pertains to my search, I am going to give up looking.

And that’s exactly what I have done. I no longer use my Windows Phone for apps. It is a sad, sad commentary because I love Metro, I love Windows Phone, and I absolutely adore the integration, the “hub” concept, and everything else that operating system does so well. But even for a “low app” consumer like me who only regularly uses 3 or 4 apps, the current state of the marketplace turned me off.

If the marketplace’s current state can turn me off, someone with an absolutely insane tolerance for shitty experiences, then I can’t even imagine how quickly standard consumers are being turned off by that same marketplace.

The talk I will be giving is about my experience learning Scala and Akka 2.0 through my ScalaMUD project. Here is the description of my talk from the ScalaDays 2012 website:

When learning a new language, one of the first things I do is try and build a game in that language because games are a lot more fun than progressively complicated “hello world” samples. In this experience report, I discuss my learning process and experience, that of a developer who has spent the last 11 years in the Microsoft world. I am exploring Scala by building a simple network text adventure game that uses many language features and Akka 2.0 and encounters surprisingly real-world problems from many other industries, including finance. My focus in learning languages is on creating clean, simple, elegant code and, as always, justifying to others why this language is worth the learning curve.
The code I’ve been writing as part of this experiment is open-sourced and available on GitHub.

Looking forward to meeting a bunch of fellow Scala enthusiasts and being able to present on this compelling language.

Here’s the code I originally produced, which scans through a list of NLP-tagged words and retrieves the first verb. If the list is empty then we need to return an empty string and if the list has no verbs then we assume that the first (or only) word in the list is a verb. For example, if I type “who” or “uptime” into the game then these should be considered verbs for command dispatching, even though NLP says they’re not verbs per se.

Ugly as Sin Code:

def firstVerb = {
if (words.size == 1)
words.head.value
else {
val outWords = words.filter( word => word.pos == Verb)
if (outWords == Set.empty)
words.head.value
else
outWords.head.value
}
}

And thanks to the geniuses over at Stack Overflow, they were able to guide me to this incredibly simple, elegant refactoring:

Refactored Code:

words find(_.pos == Verb) orElse words.headOption map(_.value) getOrElse ""

My hope is that someday I will think in terms of the second, more clean and refactored version and not instinctively reach for my imperative crutches.

In this blog post, I’ve come one step closer to that goal by enabling the dispatching of commands. As players enter input, that input is sent off to a Commander actor which tags up the input with parts of speech. Once the Comander is finished with it, it wraps the tagged words in an EnrichedCommand message and sends that to the player, which now has the trait Commandable, allowing the player to respond to enriched commands. This has an added benefit of allowing NPCs to be scripted in the future by allowing them to pretend to ‘type’ things like “kill player”, etc.

Eventually rooms will add commands to players when they enter the room to allow them to type the name of the exit (e.g. north, south, up, window) as a verb. Mortals and Wizards alike each have a unique set of commands they need to be able to type and these commands are grouped into “command libraries” (my old alma mater MUD, Genesis, an LPMUD, called them command souls). For example, here’s the first version of the Mortal command lib:

package com.kotancode.scalamud.core.cmd

import com.kotancode.scalamud.core.ServerStats
import com.kotancode.scalamud.core.TextMessage
import com.kotancode.scalamud.Game
import com.kotancode.scalamud.core.Implicits._
import akka.actor._
import akka.routing._

abstract class CommandLibMessage
case class AttachCommandLib extends CommandLibMessage

class MortalCommandLib extends Actor {
	def receive = handleMortalCommands

	def handleMortalCommands: Receive = {
		case cmd:EnrichedCommand if cmd.firstVerb == "who" => {
			handleWho(cmd.issuer)
		}
		case AttachCommandLib => {
			attachToSender(sender)
		}
	}

	def handleWho(issuer: ActorRef) = {
		println("player "+ issuer.name + " typed who.")
		var stringOut = "Players logged in:\n"
		for (p: ActorRef <- Game.server.inventory) {
			stringOut += p.name + "\n"
		}
		issuer ! TextMessage(stringOut)
	}

	def attachToSender(sender:ActorRef) = {
		sender ! AddCommand(Set("who"), self)
	}

}

Those of you who program in iOS or Cocoa might recognize some of the “Delegate Pattern” here… when the command lib attaches itself to something capable of issuing commands (anything that carries the Commandable trait, like a player or NPC), it just passes the implicit sender ActorRef so that actor can now dispatch commands to that lib.

Here’s the code in the Commander object that sends enriched commands to the actor that “typed” (virtually or for real) the command:

package com.kotancode.scalamud.core.cmd

import akka.actor._
import akka.routing._

import com.kotancode.scalamud.core.lang.EnrichedWord
import java.util.ArrayList
import edu.stanford.nlp.ling.Sentence
import edu.stanford.nlp.ling.TaggedWord
import edu.stanford.nlp.ling.HasWord
import edu.stanford.nlp.tagger.maxent.MaxentTagger
import scala.collection.JavaConverters._
import scala.collection.mutable.ListBuffer
import com.kotancode.scalamud.core.cmd._

class Commander extends Actor {
	def receive = {
		case s:String => {
			val words = s.split(" ");
			val wordList = new java.util.ArrayList[String]();
			for (elem <- words) wordList.add(elem)
		    val sentence = Sentence.toWordList(wordList);
		    val taggedSentence = Commander.tagger.tagSentence(sentence).asScala.toList

			var enrichedWords = new ListBuffer[EnrichedWord]
		    for (tw : TaggedWord <- taggedSentence) {
				val ew = EnrichedWord(tw)
				println(ew)
				enrichedWords += ew
			}

			sender ! HandleCommand(EnrichedCommand(enrichedWords, sender))
	}
}
}

object Commander {
	val tagger = new MaxentTagger("models/english-bidirectional-distsim.tagger")
}

The important bit is that the player gets the HandleCommand message, which then goes through a dispatch process in the Commandable trait, and eventually registered verb handlers (like those registered via attached command libraries) get invoked via messages. Here’s the Commandable trait:

package com.kotancode.scalamud.core.cmd

import akka.actor._
import akka.routing._
import scala.collection.mutable.HashMap
import scala.collection.mutable.HashSet

sealed abstract class CommandMessage
case class AddCommand(verbs:Set[String], handlerTarget:ActorRef) extends CommandMessage
case class Removecommand(verb:String) extends CommandMessage
case class HandleCommand(command:EnrichedCommand) extends CommandMessage

trait Commandable {

	private val verbHandlers: HashMap[Set[String], ActorRef] = new HashMap[Set[String], ActorRef]

	def handleCommandMessages:akka.actor.Actor.Receive = {
		case AddCommand(verbs, handlerTarget) => {
			verbHandlers.put(verbs, handlerTarget)
		}

		case HandleCommand(cmd) => {
			dispatch(cmd)
		}
	}

	def dispatch(cmd:EnrichedCommand) = {
		println("handled a command "+ cmd +".")
		println("command's first verb: " + cmd.firstVerb)
		val targetHandlers = verbHandlers.filterKeys(key => key.contains(cmd.firstVerb))
		targetHandlers foreach {case (key, value) => value ! cmd}
	}
}

The dispatching actually happens in the targetHandlers foreach … line where the command is sent to every command handler that declared interest in that verb. In our case, we have a mortal command verb who that displays the list of connected users and the wizard command verb uptime that displays the length of time the server app has been running.

The following is sample session output from telnetting to the game:

Welcome to ScalaMUD 1.0

Login: Kevin
Welcome to ScalaMUD, Kevin
who
Kevin: who
Players logged in:
Bob
Kevin
Kevin
uptime
Kevin: uptime
Server has been up for 6 mins 39 secs.

Now that I can log in with multiple players, see who is online, and dispatch commands to handlers as well as differentiate between mortal and wizard abilities, this game is finally starting to feel like the beginnings of a real MUD.

So what is Apple planning to do with Mac OS X Mountain Lion? According to the information I can find publicly, here are some of the highlights:

• Game Center – Apple’s game service that provides everything from matchmaking to leader boards, achievements, and even in-game multiplayer voice chat is coming to the Mac. This also means that developers writing games for the Mac will be able to participate in all that amazing goodness that iOS developers have been enjoying since iOS 4.1.
• iCloud – I don’t really know all the details here only that iCloud is even more integrated into the OS now and I’m assuming the developer experience around iCloud is getting better. I’m actually hoping that experience gets better because writing iCloud code on Lion is a pain in the ass.
• Sharing – More iOS goodness comes to the Mac with sharing “sheets”. Every application on Mountain Lion now gets a little sharing icon that uses sharing services, allowing you to share whatever you’re looking at in the application with your buddies via e-mail or whatever other services are registered on the Mac, including Twitter. I would imagine that it wouldn’t take much work, assuming the sharing APIs are good, to add other sharing targets like Facebook, Dropbox, LinkedIn, etc to your Mac – turning it into just as much of a social hub as your phone.
• Twitter - Twitter is a first-class citizen on the Mac just like it became first-class on iOS 5. This means that Mountain Lion users can tweet from pretty much anywhere and using the “sharing” services, they can share pretty much whatever they’re working on in any application (that supports it) via Twitter. Not only is twitter a first-class citizen, but applications can send Tweets on behalf of their users without any extra work. Twitter appears to be accessible in API form to developers without them having to figure out which of the 10 open-source Objective-C twitter libraries they want to shoehorn into their app. This is fantastic news for developers and I hope we get similar integration possibilities with Facebook, Dropbox, etc via Sharing “sheet” APIs.
• Notifications - In what looks to be very similar to the notification center on iOS 5, Apple now has a unified display of messages that are pertinent to the user, including IMs, iMessages (also now a fully integrated part of Mountain Lion), and application-level notifications. In classic Apple style, they are aiming to push popular 3rd parties out of this market with their 1st party offering. Applications like Growl may find it hard to compete with the unified interface, but time will tell how the 1st-vs-3rd party battles are settled.
• Gatekeeper - Again I don’t know all the details, but this feature aims to make your application more secure and, more importantly, provides developers with a secure way of distributing verified, signed applications outside the app store. For most developers, the App Store is absolutely the best way to go. But for some applications, it makes no sense to put in the app store and many people don’t need Apple’s distribution channel and so aren’t comfortable sharing 30% of their profit with the company. Gatekeeper and Developer IDs and signing give developers a way of distributing applications that users can feel comfortable downloading, installing, and using.
• 64-Bit – You simply cannot run Mountain Lion on a 32-bit machine. The kernel is 64-bit and an entire host of 32-bit “wrappers” are missing in Mountain Lion, further drawing a line in the sand against 32-bit apps. If only some other software giant whose name starts with M that makes an operating system would also draw a similar line. In words from one of my favorite movies of all time (Zombieland), “It’s time to nut up or shut up.”
• SSO – In order to support seamless sharing and such, there appears to be some kind of single sign-on facility in OS X much like Windows has been allowing you to link your “LiveID” to your user account for quite some time … only with the Twitter integration I would imagine Apple’s SSO allows for more than just Apple ID storage.

All in all Mountain Lion is looking pretty promising. Again, there’s absolutely nothing groundbreaking in here, but starting with Lion and continuing with Mountain Lion, it appears that Mac developers are finally getting access to the same amount of lovin’ that the iOS developers have been enjoying since iOS 4.

While I had the MUD code open I decided to start working on the problem of accepting player input. Sure, I have a socket reader that accepts text from players but what does one do with this text?

In the old days, I would’ve tokenized the string. By tokenized here I mean just splitting it blindly on spaces. Then I would have considered the first word in the array to be the verb and then dispatched the remaining parameters to some function in the MUD code that knows how to respond to that verb. For example, if I typed kill dragon then I would’ve tagged kill as the verb and dragon as the “rest”. This would have eventually found its way to some kill() method on a player that takes an array of strings as parameters.

Thankfully this isn’t the old days.

Instead what I did was declare a Maven dependency on the Stanford NLP (Natural Language Processing) project. To be specific, I wanted to use the Stanford non-linear Parts of Speech tagger. Why should I deal with parsing strings in a dumb way when someone else has spent years creating a powerful, well-trained NLP engine that can tag every sentence my player types with parts of speech?

This way, instead of relying on forcing players to type in pidgin dialects (e.g. kill dragon or cast spell or move north) I can let them type complete English sentences (if they want). I will then tag those sentences with the appropriate parts of speech and infer what they wanted to do from that.

I want this parsing to take place in the background. Once the player’s sentence has been enriched with parts of speech, I want to send the enriched sentence back to whatever typed it so that the command can be dispatched. To do this, I created a new Actor called Commander:

package com.kotancode.scalamud.core

import akka.actor._
import akka.routing._

import com.kotancode.scalamud.core.lang.EnrichedWord
import java.util.ArrayList
import edu.stanford.nlp.ling.Sentence
import edu.stanford.nlp.ling.TaggedWord
import edu.stanford.nlp.ling.HasWord
import edu.stanford.nlp.tagger.maxent.MaxentTagger
import scala.collection.JavaConverters._

class Commander extends Actor {
	def receive = {
		case s:String => {
			val words = s.split(" ");
			val wordList = new java.util.ArrayList[String]();
			for (elem <- words) wordList.add(elem)
		    val sentence = Sentence.toWordList(wordList);
		    val taggedSentence = Commander.tagger.tagSentence(sentence).asScala.toList

			var enrichedWords = new ArrayList[EnrichedWord]
		    for (tw : TaggedWord <- taggedSentence) {
		//		println(tw.value + "/" + tw.tag)
				val ew = EnrichedWord(tw)
				println(ew)
				enrichedWords.add(ew)
			}
	}
  }
}

object Commander {
	val tagger = new MaxentTagger("models/english-bidirectional-distsim.tagger")
}

At this point I’m just building the array of enriched words and I’m not actually sending the command back to the player (I’ll do that tonight or tomorrow, time permitting .. as always, you can check out the GitHub repo for the latest changes to the MUD). One of the interesting bits here is how I’m using a Java library from Scala. This is usually a pretty painless task but sometimes there are issues. In this case, the Stanford NLP library class Sentence has a bunch of overloads for the toWordList method. Java knows how to pick which overload but Scala doesn’t if I just use type inference and default Scala types. To get it to pick the right toWordList method I had to manually construct an ArrayList[String] because passing an Array[String] doesn’t let Scala know which overload to pick. It’s a little annoying but if I can keep the Scala->Java bridge points like this minimal then it’s not bad.

The flip side of this is that I’m getting back a regular Java array list in response to toWordList, which doesn’t support pretty Scala-native iteration because it doesn’t contain a foreach method, which is the underpinning that supports all the syntactic sugar around iteration. To deal with that, I imported the Java converters package implicits so that I could get the asScala function, which lets me call toList, which gives me a nice Scala list that I can use for easy iteration.

Here’s some sample output when I connect to the MUD and enter a sample sentence, which is then tokenized and tagged with parts of speech:

[EnrichedWord: word=attack, tag=VB, pos=Verb]
[EnrichedWord: word=the, tag=DT, pos=DontCare]
[EnrichedWord: word=green, tag=JJ, pos=Adjective]
[EnrichedWord: word=dragon, tag=NN, pos=Noun]
[EnrichedWord: word=with, tag=IN, pos=DontCare]
[EnrichedWord: word=the, tag=DT, pos=DontCare]
[EnrichedWord: word=yellow, tag=JJ, pos=Adjective]
[EnrichedWord: word=sword, tag=NN, pos=Noun]

The real goal here is that I will be taking the tagged nouns in the sentence and scanning through the player’s inventory and the environment in which the player stands for objects which have names that match the nouns and then using adjectives to disambiguate them if collisions occur. That way, when I type “kick blue bottle” I will be able to scan the surroundings for objects called “bottle” and if I find more than one, I’ll only gather up the ones that are blue.

In case you’re wondering what the EnrichedWord class looks like, which has some helper code that identifies only the parts of speech I care about, here it is:

package com.kotancode.scalamud.core.lang

import edu.stanford.nlp.ling.TaggedWord

case class PartOfSpeech
case object Noun extends PartOfSpeech
case object Verb extends PartOfSpeech
case object Adjective extends PartOfSpeech
case object DontCare extends PartOfSpeech

class EnrichedWord(value:String, tag:String, val pos:PartOfSpeech) extends TaggedWord(value, tag) {

	override def toString = "[EnrichedWord: word=" + value +", tag=" + tag + ", pos=" + pos + "]"
}

object EnrichedWord {
	def apply(hw: TaggedWord) = {
		val ew = new EnrichedWord(hw.value, hw.tag, rootTypeOf(hw.tag))
		ew
	}

	def rootTypeOf(s:String) = {
		s match {
			case "VB" | "VBD" | "VBG" | "VBN" | "VBP" | "VBZ" => Verb
			case  "NN" | "NNS" | "NNP" | "NNPS" => Noun
			case "JJ" | "JJR" | "JJS" => Adjective
			case _ => DontCare
		}
	}
}

Note that the EnrichedWord Scala class inherits from the Stanford TaggedWord Java class.

I really, really, love the syntax of the string pattern matcher I use to obtain the POS root (adjective, verb, noun, don’t care) from the Penn Treebank Tags that are used by the Stanford NLP POS tagger.

The takeaway I got from this exercise is further reinforcement of my rule to never re-invent the wheel because there are wheel experts out there who have dedicated their lives and careers to building wheels more awesome than I could ever hope to build. Hence I declare a Maven dependency on the NLP library and in a single night, I’ve got a MUD that can intelligently POS-tag player sentences which I can then use to identify potential targets of player commands. In addition, I don’t have to create a pidgin dialect for interacting with the MUD. English works and the MUD should be able to deal with “I kill the dragon with the blue sword because I am the shizzle” with the same ease as “kill dragon with sword”.

No, my experience with regular expression support and parsing in other languages like C# and Java has left a terrible taste in my mouth. I hate it. When I want to parse stuff, I want to use pattern matching and rich syntax like I can get from languages like F# or Scala.

This made me wonder if Scala didn’t make regex parsing easier. Turns out, it makes it brain-dead simple with the clever use of the concept of an unapply. The same capability that makes Scala so good at constructing, zipping, and traversing list structures also makes it just as good at cracking apart structures into their component parts.

As a sample, I created a simple string in Scala and then put the “.r” postfix on it, turning it into a regular expression:

scala> val zombieLog = """(d\+) zombies spotted in (\w+).""".r

This created a regular expression with two groups. If you’re used to doing this kind of thing in Java or C# then you’re probably thinking that you now need to write 10 lines of code to set up the regex compiler, call some method to feed the string into the regex compiler, then access groups by numeric, 0-based indexes.

Fortunately, this is Scala and more often than not, things suck less in Scalaville.

First, I’ll create an input string that I want to crack apart with my regex:

scala> val inputText = "200 zombies spotted in Mexico."

Now I’ll use unapply and syntactic sugar and Scala goodness to pull out the right values:

scala> val zombieLog(zombieCount, location) = inputText // UNAPPLY magic
zombieCount: String = 200
location: String = Mexico

And that’s it, Bob’s your uncle. With the plethora of online regular expression builders available, it should only take you a few minutes to create the regex you need and slap it into your Scala code.