It is again winter holiday time here in Finland, and as our land is mostly flat, you need to travel a long way to reach any hills suitable for real downhill skiing. For me that means ~12 hour drive from my home town Lohja to Finnish Lapland, more specifically Ylläs ski resort. You can get there by train or with an airplane, but as some of our friends live half way there we usually end up driving the whole way.

My kids are now 4 and 6 years old, and even though they enjoy skiing and being on holiday, they do not enjoy sitting inside a car for such a long time… so technology to the rescue. Here is a list of gadgets we carry with us; this is not to say you should have these, this is just the way we roll. Of course we also have traditional content (books etc.), but as this is a technology blog I’ll only introduce the techie side.

Seating & loudspeakers

While the car of course has loudspeakers all over the place, most of the time parents do not want to listen the same stuff kids do (or vice versa). Therefore a dedicated sound system for kids is a good idea. We have Recaro Monza booster seats that have loudspeakers built in:

A booster seat with integrated loudspeakers.
A booster seat with integrated loudspeakers.

This is a great idea, but unfortunately the quality of speakers in these chairs is really bad, and the wiring has some connectivity issues. Therefore we also carry some headphones with us for backup.

Amplification

Many times we only have one audio source and we need to divide that to both kids. A headphone amplifier with two outputs satisfies this need. I carry a Fiio E7 amplifier/DAC. This thing is highly recommended, I would happily buy the same again if I lost this one:

A headphone amp with dual outputs.
A headphone amp with dual outputs.

Gaming, video & audio source

As you are not supposed to carry your work laptops to holidays (to ensure holiday stays holiday), we carry tablets with us. Kids have a Nexus 7 as their personal gaming device, and then we have a Windows 8 tablet for bigger screen movie watching and parent’s surfing needs.

Small tablet for kids.
Small tablet for kids.

At home we have strict tablet usage rules (hours per week), but while travelling kids are allowed to spend much more time playing and watching videos. For our 6 year old Minecraft is currently a big hit and keeps him occupied for hours.

Many families have dedicated DVD players and such in their cars, but for us just attaching a tablet to back of the car seat (or between seats) has worked really well.

Content

Every child has their favorite music & movies: my daughter would watch Pippi Longstocking animations over and over again (if I let her). For long car trips I tend to copy all the favorite stuff to the devices, and then something new that they have not previously seen/heart. Audio books are always a good choice: they are long, and one must concentrate while listening to them, which is to say kids stay silent for a long time.

Network

Internet access for all the devices is not a must, but makes life much easier. For car trips I carry a mobile Wi-Fi hotspot with an unlimited data plan. Currently I have a ZTE MF60 which does the job:

Portable Wi-Fi hotspot.
Portable Wi-Fi hotspot.

Power

All the devices need power. Most of the stuff we carry last for a long time without charging. Also, most of the devices can be charged with standard car USB chargers. Unfortunately this is not true for all devices (e.g. the Win 8 tablet), so we also need a regular power outlet. For this purpose I always have a (cheap) 300W car power inverter in the car:

Car inverter.
Car inverter.

I hope this helps your family life. Happy travelling!

A week ago we had Microsoft TechDays 2013 at Finlandia Hall, Helsinki. For me this was fifth year in a row talking at Finnish Techdays; once I have talked about Azure, all the other talks have been about web technologies and trends. This time was no exception: I talked about real time web need and patterns, and about SignalR as one implementation tool. I enjoyed talking, and I hope I provoked at least some of the 200 listeners to think beyond the traditional HTTP Request/Response pattern we use to build web apps.

Talk was recorded, the video is available at Youtube. My slides (in Finnish) are here.

Demos

I showed four demonstrations about different SignalR and general real time web concepts. All demo sources are available online, links below.

Demo 1: Broadcasted HTML canvas drawing

First demo’s objective was to demonstrate what it takes to transform a simple drawing canvas to be collaborative: everyone can draw on the same canvas as all actions are broadcasted to all participants. More detailed explanation and sources are at GitHub. The fun part (for me) in this demo was, that I spent hours on “good enough” canvas drawing and broadcasting implementation, and only after I was done I noticed that SignalR samples project has a near identical DrawingPad sample.

Demo 2: Server side event visualization

In this demo I showed a specific use case of visualizing frequently changing server side data at browser. This could be amount of any business events, state of the runtime platform, amount of messages flowing in message bus, etc… My demo had “CPU” and “Network” graphs, although the data was random. This demo also included connecting other clients than browsers to the same data source: I created a command prompt visualizer that displayed exact same data than the web site graph. Full demo source and detailed explanation available at GitHub.

Web UI showing realtime graph.
Web UI showing realtime graph.
Command line UI showing the same realtime data.
Command line UI showing the same realtime data.

Demo 3: Store & forward + pub/sub between browser and server

This demo went farther into web sockets usage patterns. Main objective of this demo was to demonstrate what kind of infrastructure is needed to store commands at browser before pumping them into server in the background. This concept is very useful over slow networks. More information and source at GitHub. After TechDays I extracted the JavaScript bus code from the demo to a separate GitHub repository and a set of NuGet packages. A separate blog post about this library will follow.

Demo 4: Long running UI tasks concept

This demo finished the JavaScript bus (demo 3) concept by showing how it could be used in a very normal business application scenario: user selects multiple items from a list and sends them all at once to server for processing. I’ve seen many (failed) implementations, where developers spend lots of time honing last milliseconds off the operation to prevent timeouts or to match non-func requirements… and then someone selects even more items from the list and files another bug about the operation being too slow. The real solution is of course to do split list operation into a set of separate one item operations, and do everything in the background.

Long running UI operation two phase commit message pump.
Long running UI operation two phase commit message pump.

This is not trivial: there are UX issues to be taken care of, designing commands to (almost) always succeed takes lots of thought, and ensuring commands are never lost (idempotence, living without transactions) is challenging (and fun). My demo gives some building blocks how this can be done over the web. Full source available here.

Last year, when my kids got interested in learning to read and write, I decided to do what I tend to do: bring technology to the table. I created a simple web site that narrates input text, and shows navigable history of the given input on the page.

Simple narrating UI for kids.
Simple narrating UI for kids.

I created this on Finnish only, but changing the language is relatively easy (i.e. only a couple minutes work). If you wish to use this, I just put the []source code on GitHub](https://github.com/teelahti/ReadAloudWeb). If you wish to play with the Finnish version, I host it at http://lue.teelahti.fi. For my kids I put this full screen, and it kept them occupied for as long as half an hour (= eternity for kids).

Today Microsoft’s Anders Hejlsberg introduced TypeScript, which basically is a language that compiles into JavaScript, very similar to CoffeeScript. There are some differences, though: whereas CoffeeScript tries to make writing JavaScript very brief and removes lots of {}-stuff from the language, TypeScript tries to create an efficient type system on top of JavaScript.

I have tried to approach CoffeeScript a couple of times, but every time using it for real has had lots of doubts:

  • New syntax to learn, both myself and other team members
  • New tooling needed
  • Debugging story not that good (although getting better)
  • Will it fly? Do I need to roll back to JS in a year or two?

Overall I have not felt that the benefits would outnumber the drawbacks.

My first feelings with TypeScript are very similar to above; I still have great doubts about the future of this language, but some aspects are better: overall the syntax is very JavaScript-like, and as I have a C# background I could easily dive into TypeScript. Even more importantly: the tooling seems to be great from day #1 and I’m sure it will get even better. Other smart moves from Microsoft are: TypeScript is open sourced, it has Node.js support right out of the box, and it has the best sponsor there is for a new language, Anders Hejlsberg.

I do not see myself writing any apps in TypeScript, at least not in a while, but I will follow the project very closely and play with it every now and then. You never know, it might even fly – especially if the community gets over the fact that TypeScript is Microsoft-initiated.

I visited NDC 2012 and enjoyed the conference a lot. Again. Awesome speaker lineup without too much product group advertisements. Lots of thought provoking lessons. Lots of fun tongue-in-the-cheek style stuff in between. Like Damian Edwards and Rob Conery “fighting” each other with SignalR and Socket.io, respectively (video here). On that cage match Rob used a cool narrator from command line (they used narrators since Damian had lost his voice), and for some reason that fascinated me.

My first thought was that this must be possible in Windows (without all the nice effects and only an official sounding voice). And I was right: PowerShell does the trick since it can easily reference SpeechSynthesizer class. At the end of this post is the complete PowerShell script I used. To make usage easier I also added an alias creation into my Profile.ps1:

New-Alias Speak $HOME\Documents\WindowsPowershell\Speak.ps1

With this setup I can narrate text and optionally give any installed voice to the narrator. E.g.

C:\>Speak “Speak this”

Here is the PowerShell script Speak.ps1:

# Create the text to speak (with default)
$text = "Hello world";
if ($args.Length -ge 1) 
{
    $text = $args[0];
}
[System.Reflection.Assembly]::LoadWithPartialName("System.Speech") | out-null
$spk = New-Object System.Speech.Synthesis.SpeechSynthesizer
# Change voice if instructed
if ($args.Length -eq 2) 
{
    # Check that voice exists
    ForEach ($voice in $spk.GetInstalledVoices()) 
    {
        if ($voice.VoiceInfo.Name -eq $args[1]) 
        {
            $spk.SelectVoice($args[1]);
        }
        else 
        {
            # Try longer system name
            $fromShortName = "Microsoft " + $args[1] + " Desktop"
            if ($voice.VoiceInfo.Name -eq $fromShortName) 
            {
                $spk.SelectVoice($fromShortName);
            }
        }
    }
}
$spk.SpeakAsync($text)