January 23, 2009

Ultimate Warm

Friday January 23, 2009
12PM Pick-up game
Mitre Fields, Burlington, MA
Weather: 36 F, Sunny
Field: deep snow
Perfect conditions for Ultimate.

Warmest day of the year!

Ultimate Statistics (since January 2008):
Total Games Played: 147
Total Hours Played: 172

Ultimate Deep

Wednesday January 21, 2009
12PM Pick-up game
Mitre Fields, Burlington, MA
Weather: 25 F, Sunny
Field: deep snow
Perfect conditions for Ultimate.

After the back to back snow storms over the weekend, the fields at Mitre had over a foot of soft fresh snow. Great layout conditions but also makes for a good high knees and quad workout!

Ultimate Statistics (since January 2008):
Total Games Played: 146
Total Hours Played: 171

January 16, 2009

Ultimate Game

Friday January 16, 2009
12PM Pick-up game
TRW Field, Burlington, MA
Weather: 8 F, Sunny
Field: powdery snow
Perfect conditions for Ultimate.

Surprisingly it didn't feel too cold out there today. With basically no wind, bright sun, and soft powdery snow, we had a great 5v5 game.

Ultimate Statistics (since January 2008):
Total Games Played: 145
Total Hours Played: 170

January 14, 2009

Ultimate Cold

Wednesday January 14, 2009
12PM Pick-up game
Mitre Fields, Burlington, MA
Weather: 15 F, Sunny, Windy
Field: powdery snow
Perfect conditions for Ultimate.

Today's game featured sub zero degree wind chills, twelve total players, and tons of fun. I did land a little funny on my wrist on one layout attempt, though. It feels ok but I'm hoping it doesn't stiffen up (since it is my throwing hand!). I wouldn't want to miss Friday's Arctic Adventure with even colder temperatures forecast!

Ultimate Statistics (since January 2008):
Total Games Played: 144
Total Hours Played: 169

January 13, 2009

Ultimate Year

Monday January 12, 2009
12PM Pick-up game
Mitre Fields, Burlington, MA
Weather: 23 F, Sunny
Field: powdery snow
Perfect conditions for Ultimate.

For those who have been keeping track, this is my third, and longest running attempt at maintaining a blog. Today marks one year since starting this blog last January! Even though some of my posts tend to be repetitive, I hope you've enjoyed it so far. As you can see from the stats below, I've been averaging about one game of ultimate every two and half days or so.

Ultimate Statistics (since January 2008):
Total Games Played: 143
Total Hours Played: 168

January 11, 2009

Did You Know?

So I was watching the NFL playoff game between the Eagles and the Giants earlier today. At one point in the game, Donovan Mcnabb was called for intentional grounding in his own endzone, which translates of course, to a safety and two points for the Giants. On the ensuing play, the Eagles lined up at the 20 yard line for a "free kick" punt to the Giants. One thing I always wondered, though, was why teams always punted after a safety? I was almost certain that "free kick" meant that teams had the option to line up and kick a normal kickoff from the 20 yard line, just like after scoring a touchdown or field goal.

Out of curiosity I did a little research to find out. It turns out that I was right. Teams do have the option to kickoff, punt, or drop-kick after a safety. However, they are not allowed to use a tee, like for a regular kickoff, and must have a player hold it like for a field goal. Also, the rationale for almost always choosing a punt appears to be a combination of typical kickoff vs. punt distance in comparison to typical kickoff return vs. punt return yardage. Even though a typical kickoff would be slightly longer than a punt, because a punt travels so high, it's much easier to cover, which amounts to much shorter returns. This makes the punt the preferred option, coverage of a punt is easier and more reliable.

What I found most interesting out of my little research effort, though, was not the specifics of the kickoff after a safety rule, but was another obscure rule that I stumbled across called a fair catch kick. A fair catch kick is a rarely used option that teams have after signalling for, and receiving a fair catch after a punt or a kickoff. From Wikipedia:
Fair catch kicks can only occur when a member of the receiving team signals for, and successfully makes, a fair catch (or is awarded a fair catch after a kick-catch interference penalty.) That team then has the option of restarting play either by snap or fair catch kick. If the team elects the fair catch kick option, the kicking team lines up at the spot where the fair catch was made, and the opposing team must line up at least ten yards downfield. The kicker then may either place kick the ball from a teammate's hold (a kickoff tee may be used in high school) or drop kick the ball. Three points are awarded for kicking the ball through the uprights.
It's something that would only happen in rare situations when a fair catch is made in field goal range within the final seconds of the half or game. Apparently the last successful fair catch kick for a field goal was made in 1968, but quite a few have been attempted since then, including one a few weeks ago on the last game of the season between the Packers and the Lions! I had never heard of this rule, and never seen it in action, have you?

Ultimate Ice

Friday January 9, 2009
12PM Pick-up game
TRW Field, Burlington, MA
Weather: 25 F, Partly Sunny
Field: icy snow
Perfect conditions for Ultimate.

Friday was about as close to unplayable conditions as you could get. The field was covered in a crusty layer of ice that only sometimes broke through when you ran on it. Of course, we still played.

Ultimate Statistics (since January 2008):
Total Games Played: 142
Total Hours Played: 167

January 8, 2009

Ultimate Sleet

Wednesday January 7, 2009
12PM Pick-up game
Mitre Fields, Burlington, MA
Weather: 33 F, Sleet
Field: slushy snow cover
Perfect conditions for Ultimate.

Yesterday here in the northeast, we got hit with yet another snow and ice storm. In fact, most people from the office chose to work from home due to the weather conditions. Not I though! There was lunchtime ultimate to be played and we managed a 5v4 game in the slippery slushy snow.

Ultimate Statistics (since January 2008):
Total Games Played: 141
Total Hours Played: 166

January 6, 2009

Project Darkstar 0.9.8

Project Darkstar is, in the simplest description, an application server for games. What J2EE has done for business applications, we want Project Darkstar to do for MMOPGs, virtual worlds, and the like. If you've used a J2EE server such as Glassfish or JBoss, then you know that deployment and maintenance of applications into these containers is simple, and more importantly consistent. However, until just recently, this simplicity and consistency has been sorely lacking with Project Darkstar deployments.

Just before the holidays, we managed to roll a new release, version 0.9.8, of Project Darkstar. Officially announced today, this release features a major packaging improvement that greatly simplifies deployment, startup, and shutdown of Darkstar applications. Let's take a look at how this works.

At the heart of a deployment, is the Project Darkstar container itself. Unlike past releases, installing the server package is as simple as unzipping the distribution zip file. No additional steps are required. The extracted archive will leave a directory structure as follows:

- sgs-server-dist-0.9.8
  - API-CHANGES
  - CHANGELOG
  - NOTICE.txt
  - README
  - bin
  - conf
  - deploy
  - doc
  - lib
  - license
  - src
  - tutorial

The README file has a decent introductory explanation of this structure, but the main directories that you want to concentrate on are bin, conf, deploy, and lib:
  • bin - The bin directory contains two executable JAR files, sgs-boot.jar and sgs-stop.jar which are respectively used to startup and shutdown the container. Executing the command "java -jar /path/to/sgs-server-dist-0.9.8/bin/sgs-boot.jar" will startup the container and initialize the deployed application according to the configuration in the directories below.
  • conf - The conf directory contains three configuration files used for the runtime configuration of the system. The sgs-boot.properties file is used to configure the system environment and JVM configuration, the sgs-server.properties file represents the application configuration file which is fed to the Darkstar Kernel, and the sgs-logging.properties file is used as the java.util.logging.config.file during runtime.
  • deploy - The deploy directory contains all application-specific JAR files. When the container is booted up, these JAR files are automatically included in the JVM's classpath. Additionally, a single one of these JAR files can optionally include an embedded META-INF/app.properties file which is combined with the sgs-server.properties file from the conf directory to make up the set of properties used by the Darkstar Kernel. Out of the box, the deploy directory is empty and so booting up the container will immediately fail since there is no application to run.
  • lib - The lib directory suitably contains all of the JAR files required for any Project Darkstar application. These are automatically included in the JVM's classpath upon bootup of the container.
So we see above that the Project Darkstar container offers a rigid, well-defined structure, while at the same time being customizable and highly flexible. This brings us to the second component of a deployment, the Project Darkstar application. As stated previously, we want simplicity and consistency when developing and deploying an application into a container:
  • An additional feature of the 0.9.8 release of Project Darkstar is the explicit decoupling of the API interfaces from the implementation classes. The only compile-time dependency required when developing an app now is the sgs-server-api JAR file (found in the lib directory as well as the Maven repository). Simple.
  • Application specific Darkstar properties (e.g. com.sun.sgs.app.listener, etc.) can be bundled directly with the application by embedding a META-INF/app.properties Darkstar configuration file directly into your application JAR file. Simple. Consistent.
  • A Project Darkstar application is a JAR file or set of JAR files, one of which optionally contains a META-INF/app.properties Darkstar configuration file. Consistent.
  • A Project Darkstar application can be deployed into any Project Darkstar container by simply dropping the application JAR files into the deploy directory of the container and suitably tweaking the configuration files in the conf directory for your needs. Simple. Consistent.
There are other, subtle details about the flexibility and configuration of the container (including, among many things, how to use native libraries, how to use custom BDB libraries, how to use a different deploy directory, etc.) but I'll leave those for a separate discussion. In a future post, I'm hoping to case-study a real deployment using this new distribution.

Ultimate Status

Monday January 5, 2009
12PM Pick-up game
Mitre Fields, Burlington, MA
Weather: 34 F, Cloudy
Field: thin snow cover
Perfect conditions for Ultimate.

Back to work and back to regular numbers with the holidays over on Monday.

Ultimate Statistics (since January 2008):
Total Games Played: 140
Total Hours Played: 165

January 1, 2009

Ultimate Windchill

Thursday January 1, 2009
11AM Pick-up game
Danehy Park, Cambridge, MA
Weather: 13 F, Windy
Field: several inches of powder snow
Perfect conditions for Ultimate.

I don't usually attend the regular pickup game held in Arlington and/or Cambridge, but I'm on the mailing list and couldn't resist going to the annual New Year's day game. With a snow covered field, and wind chills below 0F, the game drew 17 people at its peak. Once again, a snow field game made for lots of fun, lots of layouts, and a great way to ring in the new year.

Ultimate Statistics (since January 2008):
Total Games Played: 139
Total Hours Played: 164