Its Build time again and I just finished watching Mads Torgesens keynote on day 3, where he has been talking about Roslyn and new C# features that are comming. I am really getting excited about Roslyn, with demos comming out that show how to write tooling extentions. Its one of those things that have always seemed out of reach for most things in every day development, simply because it was too much work and pain to do. With Roslyn being open sourced yesterday (by Anders Hejlsberg live on stage), it will provide options never seen before. So it is really a good time to be a C# developer.

On top of that todays demo got into some language features that the team at Microsoft are putting into C# and VB. As Mads said these are all relatively small features, but small as they might be they solve some real pains with todays C#. More...

Since the amount of javascript in an average website has exploded, the need to unittest that code has become apparent. I think we are still a bit behind in this respect, as I often hear from people don’t know what “the right way” is to create such as setup. Sadly this seems to mean that they never got off the ground and skip testing clientside. Without starting any kind of war on this, I think most of us like at least some number of tests and the option to do TDD.

Well I may already have painted myself into a corner, as I don’t claim to know the one and only “right way”, but I have found a way of going about it that I really like and have fun with. Shortly put, I have been playing around with Mocha.js and Should.js – supported by the Chutzpah test-runner and testem that allows a light weight way of running tests while doing TDD.

Lately I have been working quite a bit with displaying data in realtime on the web. I was even lucky enough to get the chance to talk about it at the Warm Crocodile Developer Conference – showing off how this can be done from your favorite SPA frameworks AngularJS and EmberJS.

One of the things I really like about these kinds of solutions is that all of a sudden it has become easy to do something that hardly was possible just a short while ago. All thanks to websockets, and technologies that utilize it. Firebase is just one such tool, and in many cases you may want to go low-level and build your own backend with eg. SignalR. It is still not too much work, and probably the route to take for most larger applications. However when Firebase is sufficient, life cannot be much simpler for getting things done.

More...

IMHO an overlooked part of the otherwise thoroughly hyped Cloud technologies is the so called baskend-as-a-service or BaaS technologies. Most presentations revolve around scalability and hosting, which are of course central and important, but non the less not the entire cloud story. This is something I have been looking a bit into, because I feel there is so much value in the cloud that we are not picking up on just yet.

More...

Azure is growing at an incredible pace and provides a good balance between lots of great services and easy ways to get started. I recently took a look at Azure mobile services, which seems to be an offering that has an interesting future with the rise of mobile development. So building a platform around features that you need to build these kinds of applications make all kinds of sense. Wanting to look more at Azure and with my recent focus on mobile it seems like a perfect fit for me.

Naming is hard

Diving into it you quickly become aware that the words "mobile services" are somewhat misleading, because although the service can be used for mobile it is just as much for building any other kind of small application. Only directly targeted mobile feature is push notifications. The featuers for working with data, scheduling and identity are very general purpose, but as a package this seems like a good idea - even though it name could be limiting to who will end up using it.

More...

While looking at how you can do your common scenarios in F# an obvious thing to look at is data access. I already covered type providers which are fantastic for consuming data. However type providers won't help you when you need to create data or in other ways interact with your SQL database, MongoDB, RavenDB or any other NoSQL solution you might be using. For this you will most likely want to use some of the libraries you already know and love - there is no reason to reinvent everything.

Working with existing libraries is mostly trivial, but F# likes types that are immutable which straight out of the box doesn't play well with serialization and mapping. This means that ORM's and libraries for MongoDB and RavenDB will throw exceptions when they try to construct your F# types. This basically boils down to the fact that code like the sample below won’t work, because the serializer can not instantiate the type and fill in the values.

More...

With my latest dive into F# I recently came across Canopy, which is a really nice and simple web testing framework. It really is as simple as installing a package and writing a few lines in a console application.

More...

I shortly wrote about Type Providers for SQL databases and services in a blog post last year, and since then a range of new providers have been written by the community. Just a quick search and you can find providers for WMI, CSV, XML, Regular expressions, REST services, world bank and pretty much every other thing you can imagine. Especially FSharpX and some of the excellent work done by people like Tomas Petricek.

After looking around I was surprised to see some of the use-cases. I was thinking in the lines of what LINQ provides until I saw samples like the provider for regular expressions.

I have started this year spending some spare time with two of my favourite languages, besides C# that I primarily use to earn a living. The two languages in question are F# and Python. The represent two other paradigms from the statically typed and object oriented ones that are by far the most main stream, with languages like Java, VB and all the C-family languages. Playing with other paradigms is a great way to learn how some problems may be solved more elegantly either by going polyglot or simply by implementing some of the basic ideas of another paradigm in the language that you work with on a daily basis.

More...

For some time I have grown weary by the ever increasing number of consoles and one-feature-applications I end up using during a work day. The good thing about being a developer is that it is my own fault, because I can just choose to do something about it - and so I did.

First step was based on two blogposts from Scott Hanselman that I remembered reading; "Console2 - A Better Windows Command Prompt" and "Awesome Visual Studio Command Prompt and PowerShell icons with Overlays". Those two posts gave me a place to start so I could get rid of seperate icons on my desktop for cmd, Visual Studio cmd, Powershell, MongoDb, Ryby, Python, Node, Clojure etc. Basically I can now use Powershell with the capabilities of the Visual Studio Command prompt, and have the rest open in other tabs in Console2.

Of course I made a few tweaks of my own, but all credit goes to Scott for a great blogpost. Only thing I was disliking was choosing the kermit green foreground color, because it overrides coloring of eg. error messages.

Second step was reducing the number of one-feature-applications and long cryptic commands that I had to remember or keep in Evernote, .txt files, .bat files and so on. This turned out to be easy by using my profile in Powershell to store functions.

New-Item -ItemType File -Path $profile -Force
notepad $profile

In my profile I can make naming conventions that make sence and I can wrap more complex operations in easilly discoverable functions utilizing Powershells tab-completion. I can replace small tools and scripts for doing xslt transforms, builds, migrations, remote iis resets, deployment to my development machine and so on. What these tools do often turns out to be the equivalent of a few lines of powershell. Mostly something along the lines of this sample, which runs a nant script that does database migrations.

function Invoke-MyProjectMigrate([string]$version)
{
    Set-Location $path
    if ($version -eq "") {
        .\nant.bat /f:nant.DbMigrations.build db.resources.migrate
    }
    else {
        &{.\nant.bat /f:nant.DbMigrations.build db.resources.migrate /D:migration.version=$version }
    }   
}

After a while I wanted to put my functions into modules, so I could package them up, and have a set of functions for each project I work on. To do this I simply moved my functions into separate files, that I put in my d:\Scripts folder. Then my profile simply imports all modules from that folder.

Get-ChildItem D:\Scripts | Foreach-Object {
    Import-Module D:\Scripts/$_
}

With this in place a have a very simple, lightweight and extensible way of improving my tooling as I go. I can also use Posh-Git/Posh-Hg for version control, and if I need to get more structure at some point I will turn to PSake. In case you don't already know PSake is the Powershell version of make, rake, bake or cake. Simply put it provides a way to do build scripts with interdependent steps. So by now I am starting to feel pretty good about my tooling, and I have been able to remove a lot of clutter from my daily life.

For now my setup is very self-centered, because I use full paths to where I put stuff, but going forward it will probably be generalized and checked into version control for everyone to enjoy.