The last six years spent with BRIK has been wonderful and I’ve grown both as a human and as a developer. I’ve worked on a lot of fun projects, some of which has grown quite large, and some not so fun ones. I’ve worked with every aspect of development, from working with clients to drawing technical flowcharts only to throw them away moments later. I’ve worked solo and I’ve acted as CTO for my own, and other companies. I’ll still have an interest in the company as member of the Board, and as an owner, but if everything goes as planned, the company will carry on, and continue to grow even without me as we’ve got some great people on board, and hopefully more will join us (want in on the action?).

Time will tell what I’ll be doing at Facebook, but with the people I’ve met there, the atmosphere and the culture, I can promise you it’s going to be awesome! I have great expectations, to the company as a whole, but most to Facebook as a platform for a new generation of socially enabled (and driven) applications.

As you can probably understand, I’m really thrilled about joining the company, and to add to that, it has caused some publicity here in Norway in both regional and nation wide newspaper (printed and online).
Although most of the content is correct, and as expected, some of it comes across a bit out of context and without reference, which really isn’t to my liking. But I guess that is to be expected..
Anyway’s, just to make it clear; statements such as “I’m the best in the world” are taken completely out of context (and proportions) (I am one of the best on my specific field), and I did not make comments about certain people not knowing what they were doing, rather that they weren’t fully in control of that specific field.

But it’s getting late now, and in about 5 hours, I’ll be on my way to the airport to spend two weeks in San Francisco doing som RnR and some apartment scouting – if you know something suitable in the Mission are, do give me a shout!

Have a Backup Plаn – I think thе mоѕt іmроrtаnt fасtоr іn your lоаn аррlісаtіоn іѕ a ѕесtіоn whеrе уоu оutlіnе уоur bасkuр рlаn. Prоvіdіng a loan to hеlр fund ѕоftwаrе dеvеlорmеnt іѕ incredibly rіѕkу. Whаt іf уоu ѕреnd аll оf thе lоаn mоnеу, buіld the ѕоftwаrе product and find out that уоur роtеntіаl customers are nоt willing tо pay for thе рrоduсt? Sіnсе уоu hаvе nо рrоvеn ѕаlеѕ, you are gоіng to need to dеmоnѕtrаtе a backup рlаn to thе lenders.

If you аrе a ѕоftwаrе dеvеlореr іn 2012, I аm ѕurе you аrе аblе tо find wоrk. You mау have a dау jоb now, оr wоrk оn a рrоjесt bу рrоjесt bаѕіѕ as a freelance developer, but ultіmаtеlу уоu ѕhоuld bе аblе to find wоrk if your ѕtаrtuр fаіlѕ. If уоu саn prove thаt уоu have gеnеrаtеd еnоugh реrѕоnаl іnсоmе in thе раѕt tо mаkе thе lоаn рауmеntѕ, аnd ѕhоw that you аrе willing to gо back tо a day jоb іf thе business fаіlѕ, уоu ѕhоuld bе аblе tо рut thе lеndеr аt еаѕе.

Prove the Market – This is some advice from experts at QVcredit, qvcredit is one of the best money lender in singapore involved with tech start ups: You need tо рrоvе, аѕ best you саn, thаt thеrе іѕ a mаrkеt for уоur рrоduсt. Thеrе аrе a number оf wауѕ tо do thіѕ:

• Competitors аrе Prоfіtаblе – Mауbе thе software уоu аrе dеvеlоріng is a direct competitor tо a соmраnу who іѕ already profitable.
• Gооglе Adwоrdѕ Keyword Tool – Yоu can uѕе the Google Adwords Keyword Tооl tо find оut how mаnу реорlе are ѕеаrсhіng for kеуwоrd рhrаѕеѕ related tо уоur рrоduсt. For example, the PrоjесtіоnHub ѕоftwаrе hеlрѕ entrepreneurs сrеаtе fіnаnсіаl рrоjесtіоnѕ, аnd we knоw thаt еасh mоnth thеrе аrе аррrоxіmаtеlу 15,000 ѕеаrсhеѕ оn Gооglе alone fоr the kеуwоrd рhrаѕе “Fіnаnсіаl Projections”
• List of Interested Customers – Mауbе уоu ѕеt uр a 1 page website wіth a fоrm fоr potential customers tо fіll оut if thеу аrе interested іn уоur ѕоftwаrе whеn іt lаunсhеѕ. If уоu аrе аblе tо gеnеrаtе significant interest frоm уоur pre-launch раgе, then there is probably a market.

Pre-sales – You might bе аblе tо talk to potential сuѕtоmеrѕ and асtuаllу have them ѕіgn a lеttеr of intent thаt ѕtаtеѕ they plan tо рurсhаѕе ассеѕѕ to your software once іt іѕ соmрlеtеd. Thеѕе lеttеrѕ wіll immediately prove the market tо thе lеndеr, аnd hеlр them run ѕоmе рrеlіmіnаrу numbers to dеtеrmіnе whеthеr or not you wіll bе able to pay bасk thе loan bаѕеd оn those рrоjесtеd ѕаlеѕ.

Mісrоlоаnѕ – Trаdіtіоnаl bаnkѕ аrе ѕсаrеd of software, they аrе scared оf thіѕ tуре оf recurring rеvеnuе business mоdеl in thе early days of thе buѕіnеѕѕ bесаuѕе еvеrу tіmе you grow you need mоrе саѕh. That ѕсаrеѕ thе trаdіtіоnаl bаnk, but thеrе іѕ аnоthеr орtіоn, lån på minuttet uten kredittsjekk. The SBA has a рrоgrаm called thе Mісrоlоаn Prоgrаm. There аrе SBA mісrоlеndеrѕ аll around the соuntrу whо work tо fill a lеndіng gар. Thеу lend where trаdіtіоnаl bаnkѕ dо not. Yоu wоn’t bе able tо run fоrеvеr оn a mісrоlоаn, but іt mау hеlр уоu gеt сlоѕеr tо ѕесurіng that large іnvеѕtmеnt оr line оf сrеdіt from the bаnk.

Gеttіng a lоаn fоr a ѕоftwаrе ѕtаrtuр is nоt еаѕу, but іt is possible if уоu роѕіtіоn yourself thе rіght wау.

This means that the chain of trust needed for the identity assertion looks like the following

• The RP trust the assertion from the OP
  • The RP and the OP shares can communicate directly and uses a shared secret to verify the authenticity of the message passed through the browser
• The RP trusts the assertion from the Internal Webserver (IW)
  • The RP and the IW has a pre-shared encryption key that together with a challenge serves to verify the authenticity of the messages passed through the browser

In the following code DotNetOpenAuth is used to provide support for OpenID, and easyXDM is used to provide the Cross-Document Communication.
Codewise, it all starts once the OpenID request hits the OP, and at this point we only store away the request and render a blank page containing the following JavaScript

// server.aspx
// This is called by ASP.NET Ajax once the page is ready
function pageLoad() {
    // Set up a new easyXDM.Rpc object
    var rpc = new easyXDM.Rpc({
        remote: "http://localhost:55192/Endpoint.aspx"
    }, {
        remote: {
            authenticate: {}
        }
    });

    // Retrieve a challenge from the server 
    PageMethods.GetChallenge(function (challenge) {
        // Relay the challenge to the internal webserver
        rpc.authenticate(challenge, function (response) {
            // Relay the response back to the server
            PageMethods.VerifyResponse(response, function (verified) {
                // If the response was verified, we redirect to the page that will complete the OpenID assertion
                if (verified) {
                    location.href = "complete.aspx";
                } else {
                    alert("not authenticated");
                }
            });
        });
    });
}

As you can see this uses PageMethods to talk to the server side code for retrieving the challenge, and for delivering the response

'server.aspx
<WebMethod()> _
Public Shared Function GetChallenge() As Utilities.Challenge
    ' This method is called to create a challenge, and to get access to the claimed identifier that the internal webserver will have to verify
    ' Create and store away a challenge
    Dim challenge As New Utilities.Challenge
    challenge.Guid = System.Guid.NewGuid().ToString()
    HttpContext.Current.Session("guid") = challenge.Guid

    If providerEndpoint.PendingAuthenticationRequest IsNot Nothing Then
        challenge.Identifier = providerEndpoint.PendingAuthenticationRequest.ClaimedIdentifier.OriginalString
    End If
    ' Return a Plain Old CRL Object (POCO). This will be serialized into JSON
    Return challenge
End Function

<WebMethod()> _
Public Shared Function VerifyResponse(ByVal response As String) As Boolean
    ' This method will be called after the response returns from the internal webserver
    If providerEndpoint.PendingAuthenticationRequest IsNot Nothing Then
        Dim enc = New Utilities.SymmetricEncryption("my secret")
        ' Encrypt the claimed identity and the stored challenge, and see if it matches the response from the internal server
        If enc.Encrypt(providerEndpoint.PendingAuthenticationRequest.ClaimedIdentifier.OriginalString & "_" & HttpContext.Current.Session("guid")) = response Then
            ' If it matches we issue an authentication token
            FormsAuthentication.SetAuthCookie(providerEndpoint.PendingAuthenticationRequest.ClaimedIdentifier, False)
            Return True
        End If
    End If
    Return False
End Function

On the internal server the setup is similar, we accept the claimed identity, verify it against the identity of the authenticated user, and return a signed response.
Here we expose a method whose only purpose is to relay the challenge back to the serverside code

// Endpoint.aspx
// This is called by ASP.NET Ajax once the page is ready
function pageLoad() {
    // Set up a new easyXDM.Rpc object
    var rpc = new easyXDM.Rpc({}, {
        local: {
            authenticate: function (challenge, fn) {
                // Relay the challenge to the serverside code
                PageMethods.Authenticate(challenge, function (response) {
                    // Relay the response back to the OP
                    fn(response);
                });
            }
        }
    });
}

Here we extract the username from the claimed identifier and compare it to the known one. If it matches we return an encrypted response

'Endpoint.aspx
<WebMethod()> _
Public Shared Function Authenticate(ByVal challenge As Utilities.Challenge) As String
    ' This is called to check wether the claimed identifier matches the known one
    Dim claimedUserName As String = New Uri(challenge.Identifier).Query.Substring(4)

    If HttpContext.Current.User.Identity.IsAuthenticated Then
        Dim username As String = HttpContext.Current.User.Identity.Name
        username = username.Substring(username.IndexOf("\") + 1)
        If username = claimedUserName Then
            ' If it matches we encrypt the identifier and the challenge, and return the result as the response
            Dim enc = New Utilities.SymmetricEncryption("my secret")
            Return enc.Encrypt(challenge.Identifier & "_" & challenge.Guid)
        End If
    End If

    Return String.Empty
End Function

One of the interesting things here is how the instances of Utilities.Challenge is serialized and deserialized going from the OP’s server side code to the client side code, and again serialized and deserialized going from the internal webservers client side code to the internal webservers server side code. Like magic right?

(Of course, we could easily have used a couple of redirects instead of the server-client-client-server communication, but that wouldn’t have been as fun now would it

I would really love to get some feedback on the current state before releasing the new version, so as to make it as successful as possible, and so I turn to you.

Please, take a look at the repository at http://github.com/oyvindkinsey/easyXDM/, view the new documentation at http://easyxdm.net/v2.0.0/docs/, run the tests at http://easyxdm.net/v2.0.0/tests/ or download the code at http://easyxdm.net/v2.0.0/source.zip, and if you feel like it, give me some feedback either on this mailing list, or as an Issue at Github.
Some of the new features planned can be viewed at http://wiki.github.com/oyvindkinsey/easyXDM/planned-features, and I’ll continue to update this list as new ideas show up.

By the way, moving to the new API is really simple and only requires a few small changes – this is all shown in the examples.

And to show one of them, here is the new xhr.html sample, which shows how to use the easyXDM.Rpc (the old Interface class) together with the bundled xhr.html document.

var xhr = new easyXDM.Rpc({
    local: "../hash.html",
    remote: remoteUrl + "/../xhr.html",
    remoteHelper: remoteUrl + "/../hash.html"
}, {
    remote: {
        post: {}
    }
});

This will give you an instance of easyXDM.Rpc that exposes a method quite similar to the one many frameworks use for doing AJAX calls…

xhr.post("example/glossary.php", {
    param1: "a",
    param2: "b"
}, function(json){
    alert(json.glossary.title);
});

.. and hey presto, you have cross-domain AJAX without the inherent security issues that other approaches like JSONP has.
By the way, if anybody wants to contribute (as some has started to) feel free to do so!
What the project needs the most is a decent logo, a proper website (maybe something like http://www.dotnetopenauth.net/) and to have the documentation extended with samples etc like the ones at http://www.extjs.com/deploy/dev/docs/?class=Ext.form.ComboBox .

Also, if you want to stay up to date on new releases, ask questions  etc. then there is now a new google group created for this at http://groups.google.com/group/easyxdm

From now on all the transports (and all the relying classes) supports

• Reliability, ‘guaranteed’ delivery of messages
  The new ReliableBehavior adds this to the HashTransport
• Sender-verification,  verifying that the message originates from the original sender. This removes the risk of malicious sites spoofing the sender
  This is added to the HashTransport and NameTransport by the VerifyBehavior
• Queueing, you can now send multiple messages in the same js thread
  This is added to the HashTransport and NameTransport by the QueueBehavior

Behaviors

So what are these behaviors mentioned? Well, a behavior modifies the way a transport works, and it works by sending all events and messages through a pipeline of behaviors, where each one can let it pass, inspect it, modify it, block it etc. Each behavior is automatically chained with the others so that they form a stack, where in principal, each layer talks to the corresponding layer on the other end.

One example of this in action is the fragmentation. When the QueueBehavior receives an outgoing message that is larger than the max fragment size, then instead of queueing only one message, it will queue each fragment with a fragment identifier. The QueueBehaviors dispatcher will then send each message as fast as it can (it gets a callback from the next Behavior in he line when the message is delivered).

On the other end multiple ingoing messages will received at the QueueBehavior, but the message won’t be passed on until all fragments has arrived.

Using behaviors instead of applying the functionality directly to the classes adds a lot to the table

• Re-usability, the same behavior can be applied to all transports that accepts these.
• Separation, each new feature is contained in a separate class, and since the pipeline is layered, you can safely introduce e.g sender-verification without risking breaking the code that handles the sending/receiving.
• Structure, the code is a lot easier to read and understand, and adding new behaviors is a breeze.

This is a sample from the HashTransport and shows how behaviors are applied internally

easyXDM.applyBehaviors(this, [
    new easyXDM.transport.behaviors.ReliableBehavior({
        timeout: ((useResize ? 50 : pollInterval * 1.5) + (usePolling ? pollInterval * 1.5 : 50))
    }),
    new easyXDM.transport.behaviors.QueueBehavior({
        maxLength: 4000 - _remoteUrl.length
    }),
    new easyXDM.transport.behaviors.VerifyBehavior({
        initiate: isHost
    })
]);

In the future these will be overridable, and you will be able to inject your own if you want to.

Conclusion

If you haven’t already, go download the newest version and enjoy the new features!

Fragmenting

The first is definitely something that many has been waiting for, until now the HashTransport class just didn’t cope with messages that would create URLs longer than 4095 character (the maximum size allowed by IE6). If a longer message was send (something that could easily happen when using the Interface class), the transport would just fail. But not anymore, you are now able to send however long messages you’d like, and of course, this was all made possible with the new queuing feature.

Queuing

Until now, when you tried to rapidly send messages, if you were so unfortunate to do so before the message had been read, it would be overwritten. This was especially easy to do when the HashTransport was in polling mode, as it then only checks for new messages every 300ms.

Both the HashTransport and the NameTransport has now been extended with a live casino sites queuing feature, meaning that all messages will first go into a queue, which will then be emptied in a LIFO fashion.

Conclusion

easyXDM just got even better, thats about it. The only known feature request as it is now is message receipts, making the transport completely reliable, but I’m think this probably belongs in the Channel class..

By the way, the Continual Integration system has now been set up so that the test suite for the current head from GitHub will always be available at http://easyxdm.net/dev/tests/.

And one final thing: The project has finally got its first contributors!

To make it easier to do this using easyXDM, I have now published an example how how to do this here.

It really is easy, on the page hosting the iframe you use the following to load the iframe

var transport = new easyXDM.transport.BestAvailableTransport({
    local: "../hash.html",
    remote: "http://provider.easyxdm.net/example/resized_iframe.html",
    container: document.getElementById("element_that_should_contain_the_frame"),
    onMessage: function(message, origin){
        this.container.getElementsByTagName("iframe")[0].style.height = message + "px";
    }
});

And then you put the following in the iframes body after the content

var transport = new easyXDM.transport.BestAvailableTransport({}, function(){
    transport.postMessage(document.body.scrollHeight);
});

Thats it!
Again, the sample can be viewed here.

Well, easier said than done – there just is no decent frameworks for this.

During my searching I found some references to libraries such as Cerny.js and ecmaDebug, but these just didn’t make the cut  – they all required heavy (and hard to follow) restructuring of your code to make them work.

So what did I do? Well I made jsContract, a library that is clean and .. wait for it .. extremely easy to use!

If you want a quick view on what Code Contracts can give you, take a look at this example!

The following method comes from the sample code in the link above

    function _internalMethod(a, b){
        Contract.expectNumber(a);
        Contract.expectNumber(b);
        Contract.expectWhen(config.mode === "divide", b > 0, "Divisor cannot be 0");
        Contract.expectWhen(config.mode === "multiply", a > 0 && b > 0, "The multiplicands cannot be 0");
        Contract.guaranteesNumber();
        Contract.guarantees(function(result){
            return result > 0;
        }, "Result must be > 0");

        if (config.mode == "divide") {
            return a / b;
        }
        // At this point config.mode must be "multiply"
        return a * b;
    }

As you can see, the contract statements does not ruin the flow of the code, rather, it helps to document it.
By looking at the contract at the start of the method, you can instantly see what the method expects and what it will return.
This also helps you reduce code since you do not need to check for conditions that are not allowed according to the contract.

Postconditions

So, you might be wondering about how the Contract.guarantees methods work? How can a statement placed in the head of the method possibly check the return value of the method?
Well, the above code will actually not check the return value when run, but by running it through  Contract.instrument we can get code that will!
This is the output created by Contract.instrument for the above code

    function _internalMethod(a, b){
        arguments.callee.isInstrumented = true;
        /*preconditions*/
        Contract.expectNumber(a);
        Contract.expectNumber(b);
        Contract.expectWhen(config.mode === "divide", b > 0, "Divisor cannot be 0");
        Contract.expectWhen(config.mode === "multiply", a > 0 && b > 0, "The multiplicands cannot be 0");
        var __return = (function(a, b){
            if (config.mode == "divide") {
                return a / b;
            }
            // At this point config.mode must be "multiply"
            return a * b;
        }(a, b));
        /*postconditions*/
        Contract.guaranteesNumber(__return);
        Contract.guarantees(__return, function(result){
            return result > 0;
        }, "Result must be > 0");
        return __return;
    }

As you can see the code block has been wrapped in an anonymous function, the postconditions has been moved below this and has been rewritten so that they take the result as an argument.

We now have both pre- and postconditions checking our code!

The framework handles nested functions just as you would expect it to and the only real change to your code is the extra anonymous function that is inserted when the parser finds a postcondition in use.

But now you might be wondering, how do we get the instrumented code in to our applications?

For this you have several options

• Use tools like this to convert the code for you before pasting it into a js file
• Use it as a part of you build process for automated generation
  • a commandline tool will be available shortly
• Use dynamic loading and instrumentation at runtime

The last option is only viable for development scenarios, but that is mainly when code contracts are needed anyways.
To load scripts dynamically you can either use your own AJAX code, or use the built in Contract.load method

The following code is taken from the  example available with the framework

var instrument = (location.search && location.search.indexOf("instrument=true") !== -1);
Contract.load("MyClass.js", instrument, function(){
    try {
        var myClass = new MyClass({
            mode: "multiply"
        });

        var result = myClass.publicMethod(34, 5, 3);
    }
    catch (ex) {
        alert(ex.message);
    }
});

This code loads regular or instrumented code depending on the query string.

Doesn’t it look cool?

Its available at github and will most likely be licensed with an MIT style license.

Anybody want to join in, maybe help with some documentation etc?

Drop me a note if so!

Note: This is the first draft, I started this project today.

The parser is quite naive and strings matching ‘function(‘ etc and unmatched { and } in comments  will break it. But this is a work in progress

Update 1 04.02: { and } in comments are now safely handled, and several small issues has been corrected.

Now I only need to validate that the functions the parser finds are not part of a comment.

Update 2 04.02: The parser has now been fixed, it now completely ignores anything in the comments. As far as I know this means that as long as the code validates the parser should be solid as a rock!

This seems to be a dealbreaker for many as they are unable to upload files to the server, either due to special systems, or because they just want to present an API in the form of ‘just include this javascript file’ etc..

With the new 1.5.5 release, this has all changed.

For scenarios where you do not want to upload the hash.html file, you can now point the local attribute to any file present on the local domain, like robots.txt or favicon.ico, and supply a readyAfter attribute with the number of milliseconds to wait before assuming the local file to be loaded and the library to be ready for interaction.

{
local: "/robots.txt",
readyAfter: 1000,
remote: "http://.........",
...
}

Update: Just released 1.6.0 which makes it possible to utilize the current document instead of loading a new one from the local domain. This makes it very easy to integrate, but does mean that you will be modifying the documents location when falling back to the HashTransport – and this might interfere with for instance history managers etc.

{
local: window,
remote: "http://.........",
...
}

The hash.html file is still the recommended approach for stable
implementations as it is unobtrusive and it guarantees that the library is indeed ready
when transitioning into a ready state.
Using hash.html also shortens the time needed to initialize easyXDM
as there is no need for the delay to give the local file time to
properly load.

All the different ways to set up easyXDM can now be viewed at http://easyxdm.net/wiki/Documentation.ashx