His first two novels are a two-part story: Daemon, and Freedom™. I have totally dug them, especially the 7 layers of metaphor and earnest mods to plausibility.

game-theory techno-thriller cyber-punk IT rouge-developer near-sourcing commando near-dystopia AI assassin spy epic cyborg spies viruses the-good–clichés game-design mad-scientist long-running-workflow anti-consumerism

The most interesting thing is Daniel Suarez himself. According to his website he’s a specialist consultant-developer slinging for bounty living in southern California. His bio reads as many of ours do at some point at some point. In short this dude seems to just be one of us geeks who also writes a bang-up novel.

I have no doubt I am late to the game on this writer, but I’m old. I’ve only just gotten around to a lot of things. If you haven’t read it yet, I recommend starting with Daemon. It’s fun and enjoyably thoughtful.

Note: Don’t have a drink in hand or mouth when reading these.

Enjoy:

• http://martinvalasek.com/blog/pictures-from-a-developers-life
• http://martinvalasek.com/blog/pictures-from-a-developers-life-part-2
• http://martinvalasek.com/blog/pictures-from-a-developers-life-part-3

If you’re a git user.

• http://wheningit.tumblr.com/

I am going to send email in hopes of encouraging some new feature development .

Jetty

Jetty, among other great things, contains a WebSocketClient implementation.  Getting this up and running is very simple: you’ll need a WebSocketClientFactory, where you can configure various settings, and a WebSocketClient which also has a bunch of settings to flip around to meet your needs.  Once you have those, you’ll need a class that implements WebSocket.OnTextMessage …and you’re pretty much done at this point. 

The code for sending and receiving messages becomes equally simple:

@Override

public void send(Message message) {

    // a message is going out!

    String data = null;

    try {

        data = messageToString(message);

        connection.sendMessage(data);

    } catch (Exception e) {

        logger.error("Failed to send message! " + data, e);

    }

}

@Override

public void onMessage(String data) {

    // a message is coming in!

    logger.debug("message received: {}", data);

    try {

        Message message = stringToMessage(data);

        handleMessage(message);

    } catch (IOException e) {

        logger.error("Failed to parse incoming message! " + data, e);

    }

}

The complete code for this example can be found at

https://github.com/trasa/WebSocketClientServer/tree/jettyclient

Installing node-validation can be done using the canonical package manager:

$ npm install node-validation

Validation rules must be defined in a custom validator by deriving from the base Validator.

var MyObjectValidator = function() {
    Validator.call(this);

    this.ruleFor('stringProperty').isNotEmpty();
    this.ruleFor('otherStringProperty').hasMaximumLength(10);

    this.ruleFor('numericStringProperty').isNumber()
        .withMessage('Oops, something is wrong ...');
    this.ruleFor('dateStringProperty')
        .matches(/^(19|20)\d\d[-](0[1-9]|1[012])[-](0[1-9]|[12][0-9]|3[01])$/);

    this.ruleFor('numberProperty').isInteger();
    this.ruleFor('otherNumberProperty').isMaximum(5);

    this.ruleFor('exoticProperty').is(function(value) {
        return 3 === value.propertyA + value.propertyB;
    }).withMessage('Either propertyA or propertyB has an incorrect value.');
};

util.inherits(MyObjectValidator, Validator);

After creating a validator object, an object that needs to be validated (the subject) can be passed to the validate method. The validate method returns an array of validation errors specifying a message and the name of the violating property.

//
// Validation subject
//
var subject = {
    stringProperty: '',
    otherStringProperty: 'Some string value that is too long ...',

    numericStringProperty: '65.85 invalid',
    dateStringProperty: '2013-04-30 invalid',

    numberProperty: 'Some invalid number',
    otherNumberProperty: 48,

    exoticProperty: {
        propertyA: 1,
        propertyB: 1
    }
};

//
// Now it's time to validate
//
var validator = new MyObjectValidator();
var validationErrors = validator.validate(subject);

for(var i=0; i < validationErrors.length; i++) {
    console.log('Property name: ' + validationErrors[i].propertyName 
                + ', Message: ' + validationErrors[i].message);
}

There you go. Head over to the GitHub repository and give it a try. I’m definitely looking forward to hear your feedback.

Rather than build a custom protocol on top of TCP to go between the custom game server and the rest of the system, we decided to use Web Sockets for the wire protocol and objects serialized via JSON.  There are plenty of client and server implementations for all of the major languages we’re intending to support – making the job of supporting the other dev teams much easier.  Plus, it’s trivial to create various test harness Web Socket powered clients and servers – useful for developing your custom game without having to be tied to the larger system’s environment.  Particularly since that larger system was still actively under development..

As I was writing the game server, I found many examples of writing a Java server which would listen for incoming clients.  I found plenty of examples for writing Web Socket clients in JavaScript, or clients in Java that did everything in “public static void main()”.  But I didn’t find much in the way of writing a Java Server that kept a persistent Web Socket client around for the life of the server.  So, attached is an example Web Socket “client” server (a server application) which can send and receive messages using netty.

https://github.com/trasa/WebSocketClientServer

This particular example connects to a public “echo” server — which is great for testing out such ideas.

Netty

Netty is a client server framework for building network applications.  Netty’s power comes from being able to construct a high performance Channel Pipeline which describes the steps that network traffic goes through on its way to and from the application.  For this example, we define a pipeline that is built on HTTP and includes a Serializer/Deserializer for translating objects into json (and back), and also the WebSocketClientHandler itself for doing something with those WebSocket messages.

When sending a Message, we send the Message through the pipeline we’ve established. The Serializer/Deserializer (SerDe) translates the message into a byte array, wraps the bytes into a TextWebSocketFrame, and sends the WebSocketFrame on it’s way.

Coming back the other way, the SerDe recognizes an incoming stream of bytes as a Message and reconstitutes the java object.  The Message object is sent up the pipeline, handled by WebSocketClientHandler, which then executes that message, finding the correct handler to call, and otherwise “doing stuff” with the message received.

The advantage of this pipeline approach is that the actual game logic is easy to separate from the underlying communication, making the game code easier to write and much easier to test in isolation.  For example, a message handler might be defined as:

@MessageHandler

public void handleConstructArmyRequest(ConstructArmyRequest request) {

    // do whatever you're supposed to do here

    sendResponse(new ConstructArmyResponse(SUCCESS));

}

Netty met the needs of this particular game server, performance-wise and through it’s flexibility.  Since we’re using web sockets, such a system would be easy to put together using a library or different language completely.

The next step for this system is to look at replacing Netty with Jetty – which provides a servlet container and web server with web sockets support.  Typically a custom game server will need some http-based parts for monitoring (connecting to nagios, viewing and graphing statistics) and for allowing some administrative access to the inner workings of the game server.  Jetty doesn’t provide the same sort of pipeline for serializing and deserializing but the process is pretty much the same.

The ideas expressed here are around the pragmatism of using estimation as a technique, but not getting lost in the weeds. In other words, admit that we need some process and understanding of what we will be doing, but don’t value process over software.

I share some techniques my team and use at Microsoft to keep things understood and on track. Hope you enjoy it.

From the Abstract

Software development is often fundamentally different than the analogies used to describe it. Accordingly, estimating what software will be done and by when can be an exercise in frustration. Yet, some teams seem to just "get it", making accurate predictions of cost or effort. Other teams struggle with excruciatingly detailed planning meetings or with the results of not estimating at all. Explore estimation for software development from several angles including: empirical planning, time-based estimation, relative comparison, and others. Several effective and proven estimation techniques will be explored, expanding your team’s capabilities beyond hoping for the best.

The My Work feature focuses a developer’s immediate work in a single, actionable view. My Work presents TFS Work Items assigned to me in a view that allows quick and easy integration with checking in code. This aims to reduce the friction of associating Work Items with check-ins, a process which has an annoyingly high number of clicks without My Work.

In previous versions of My Work, only two types of Work Items appeared in the My Work panel. It has been generally accepted good practice to associate only Tasks or Bugs with check-ins. In a Kanban world, Task level work is often represented as a state or column on the team’s board. Instead of using Tasks, more teams will not create Task Work Items and instead will orchestrate their work using simple PBI or User Story Work Item types and move those across the board to represent state.

To support Kanban through the My Work feature, developers can now see more Work Item types that might be assigned to them. Generally, any Work Item type that is a:

• Requirement (User Stories, PBIs, etc)
• Task
• Bug

Here is an example of how this might look using the Scrum 2.2 process template.

Any of these Work Items may be associated with pending changes so that future check-ins will associate with them.

There is also a difference in the workflow behavior of the feature. For Tasks associated in My Work:

Checking In Tasks

Given a Task is associated with In Progress Work
When a Check-in occurs
Then the Task’s state transitions to Resolved
And the Task is associated with the Changeset
And the Task will therefore no longer appear in the My Work pane

However, associated Work Items that are generally requirement types behave a bit differently.

Checking In Bugs and Requirement Work Item Types

Given a Work Item is associated with In Progress Work
When a Check-in occurs
Then the Work Item’s state does not transition
And the Work Item is associated with the Changeset
And the Work Item will still appear under "In Progress Work

This new behavior may seem a bit odd at first. When developers resolve Tasks with each check-in, the Task model makes sense. When developers make many check-ins over time associated to a given Product Backlog Item or Requirement, the latter model makes more sense.

Resolving Requirement Work Item Types in My Work

When clicking “Finish” under “In Progress Work”, note the language of “if possible” in the popup that appears:

It turns out that for Requirement Work Item types, we cannot determine or infer the next logical workflow state. The reason for this is a long-standing design decision in how TFS WI state transition models work, and it is what it is. Given this, removing the Requirement Work Items from scope for the current developer become a wee bit more manual.

After checking in, the Work Items in "In Progress Work" may be handled in several ways:

1. Open the Work Item and assign it to another person (WI disappears from My Work)
2. Open the Work Item and manually transition it to its “Done” or “completed” state. (WI disappears from My Work)
3. Click "Finish". The WI is still assigned to the current developer, and re-appears in the "Available Work Items" list.
4. Commit pending changes. Regardless of whether the WI is marked “associated” or “resolved”, it still appears in My Work.

The Bottom Line

To transition a Requirement Work Item Type from your My Work pane to its next logical owner or state, open it and make the changes to the Work Item as appropriate. All the features allowing associating to current and future code check-ins still work as before, but taking your name off a given Requirement Work Item must be a more deliberate choice as must moving it to a “Done” state.

As with many things in JavaScript, there is not a single straight answer. We can choose between a couple of options and many different variations of these solutions. But one thing’s for sure: we can’t have it all!

In this blog post I want to discuss two different styles of inheritance that I have a hard time choosing from when programming JavaScript. And as with everything in life, both styles have their own pros and cons. 

Prototypical inheritance

In ‘classical’ programming languages, one class can directly inherit from another class. JavaScript doesn’t have this notion of classes (yet). Instead, JavaScript has prototypes which you can augment to fit your own needs. This means that having a single augmented object as the prototype for other objects, which ‘inherit’ all members of the augmented prototype object, kind of simulates a pseudo-classical inheritance pattern. Let’s talk code in order to demystify this concept.

// validator.js
var Validator = exports.Validator = function() {
    this._rules = [];
};

Validator.prototype.addRule = function(rule) {
    this._rules.push(rule)
};

Validator.prototype.validate = function(instance) {
    ...
};

// specificValidator.js
var util = require('util');

var SpecificValidator = function() {
    Validator.call(this);
};

util.inherits(SpecificValidator, Validator);

SpecificValidator.prototype.filter = function(instance) {
    ...
};

// client.js
var validator = new SpecificValidator();

// Calls function on derived object
validator.filter( { ... } );        

// Calls function on base object
validator.validate( { ... } );        

Here we have a constructor function named Validator which is the base object for other ‘derived’ objects. We augment the prototype with two functions (addRule and validate). Next we define another constructor function named SpecificValidator. We ‘derive’ this new  constructor function by calling the base constructor function and wiring the prototype by using the util.inherits() function from the Node.js core library.

We have to use the new keyword in order to instantiate a SpecificValidator object. Now we can use the functions that we added to the prototype.

Functional inheritance

This pattern is advocated by Douglas Crockford in his book JavaScript, The Good Parts. There he offers this particular style as the way to go for inheriting objects. Let’s look at an example.

// validator.js
module.exports = function() {
    var rules = [], my = {};

    my.addRule = function(rule) {
        rules.push(rule);
    };

    my.validate = function(instance) {
        ...
    };

    return my;
};

// specificValidator.js
var validator = require('...').validator;

var specificValidator = function() {
    var my = validator();

    my.filter = function(instance) {
        ...
    };
    
    return my;
};

// client.js
var validator = specificValidator();

// Calls function on derived object
validator.filter( { ... } );    

// Calls function on base object
validator.validate( { ... } );        

The base constructor function returns an object that is augmented with functions and is returned at the end. The derived constructor function simple calls the base constructor function and further augments the retrieved object before returning it to the calling code. Here we don’t have to use the new keyword to instantiate anything. Just calling the right constructor function gives us an object which we can use in our client code.

Conclusion

The most important benefit of prototypical inheritance, at least in my humble opinion, is performance. By augmenting the prototype with functions, we only create these functions once. Not matter how many times we instantiate a constructor function, the same functions get (re)used every single time. Functional inheritance on the other hand creates new functions every time a constructor function is called, which is several orders of magnitude slower compared to the prototypical inheritance pattern.

On the other hand, the prototypical approach doesn’t come with encapsulation. Looking at the example shown earlier, the ‘_rules’ property is publicly available to the client code and can be manipulated at will. By using a simple convention, like prefixing with an underscore, we can indicate that these private members should not be touched in order to guarantee a correct behavior. But again, nothing can be enforced. Using functional constructors, we can have private variables and functions that cannot be manipulated by the calling code.    

There are more pros and cons, but for me, these are the most important ones to be aware of. You can see that both styles have their strengths and weaknesses. I usually tend to go with prototypical inheritance as this is the ‘JavaScript way’, but I like using the functional approach as well for those cases were I know in advance that not too many objects are created or when I don’t care about performance.

I would love to hear other takes on this. What particular styles do you use? When do you use them and why?

Until next time

System.UnauthorizedAccessException was unhandled by user code
  HResult=-2147024891
  Message=Access is denied. (Exception from HRESULT: 0×80070005 (E_ACCESSDENIED))
  Source=Windows.UI
  StackTrace:
       at Windows.UI.Text.ITextDocument.SetText(TextSetOptions options, String value)

when all I was trying to do was programmatically set the text of a RichEditBox. EX:

theRichEditBox.Document.SetText(Windows.UI.Text.TextSetOptions.FormatRtf, textValue);

After searching and searching and eventually taking a walk to cool down, I decided that I would play with the IsReadOnly flag. I have it set to “True” in the XAML because I don’t want users to edit the text. I then wondered if this was causing the problem.

I tweaked the code as shown below and it magically started working. Notice how I’m turning off the IsReadOnly flag off, then setting the text, and returning the read only state after the text has changed.

theRichEditBox.IsReadOnly = false;
theRichEditBox.Document.SetText(Windows.UI.Text.TextSetOptions.FormatRtf, textValue);
theRichEditBox.IsReadOnly = true;

Dear Exception: you were not helpful. Sigh.