Windows 8 in Virtual Box

Everybody has had  their opinions about the developer preview of Windows 8 so far.  It seems ok to me, though the new ‘Start Menu’ together with the desktop feels like trying to glue half a donkey onto half a Forumla One car.  It doesn’t seem right to me at the moment, as both are too different.  Apart from that, it’s Windows 7, as far as I am concerned, and works fine.

However, to run it in VirtualBox and get it working a little bit more like Microsoft intend, you have to tweak a couple of things.  Firstly, you’ll want to up your screen memory to maximum.  By default, this seems to be 256Mb.  In addition you want to run VirutalBox in full screen mode.  The reason for this is that the left hand edge of the screen, all one pixel of it, is a hot-spot for Windows 8, and you need to be able to push your mouse pointer flush with the left edge of your screen.

If you’re running a widescreen monitor, chances are that Virtual Box is pushing your maximum screen resolution into Windows 8, so you need to do a couple of things.  In Windows 7 64-bit:

  • Open a command prompt
  • cd “C:\Program Files\Oracle\VirtualBox”
  • then run:
  • VBoxManage setextradata global GUI/MaxGuestResolution any
  • and:
  • VBoxManage setextradata “Windows 8″ “CustomVideoMode1″ “1920x1200x32″

where “Windows 8″ is the image name I am using in Virtual Box, and “1920x1200x32″ is the resolution of my monitor.

Now restart Virtual Box and you’re good to go.

Random linux tricks, or RTFM

As usual, I’ve spent some time web-surfing, and despite my best efforts at RTFM’ing, I don’t always get to the end of *nix man pages.

 

 

 

The little trick I spotted today is to apply xargs in a more efficient manner:

 xargs  [-0prtx]	[-E  eof-str] [-e[eof-str]] [--eof[=eof-str]] [--null]
       [-d delimiter] [--delimiter delimiter]  [-I  replace-str]  [-i[replace-
       str]]	[--replace[=replace-str]]   [-l[max-lines]]   [-L   max-lines]
       [--max-lines[=max-lines]] [-n max-args] [--max-args=max-args] [-s  max-
       chars]  [--max-chars=max-chars]	[-P max-procs] [--max-procs=max-procs]
       [--interactive]	    [--verbose]	     [--exit]	   [--no-run-if-empty]
       [--arg-file=file] [--version] [--help] [command [initial-arguments]]

Yes, it supports the -P argument.

find . | xargs -P32 some_process.bash

That kind of thing.  RTFM as they say, especially as I usually work on Windows.

And whilst we’re at it, you can also chain workflows by abusing make:

step3.flag: 
  step2.flag	step_3.bash
step2.flag:
  step1.flag	step_2.bash
step1.flag: 
  step_1.bash
clean:
  rm -f step*.flag

Time to get back to reading manuals.

knockout.js


I like knockout.js, an MVVM framework for web development, and so do lots of other people.  At the company where I work, it is the framework I’ve chosen to build a shopping cart front-end for a site.   It seems to be quite a popular topic on StackOverflow, and also the cause of some problems.

The common problems that users seem to have with knockout.js (and is wholly demonstrated in the stackoverflow questions) seems to fall into several broad categories:

  • No familiarity of MVVM.
  • Lack of familiarity with Java(ECMA)script.
  • Application design.

Covering each point in turn:

The MVVM framework is just a variation on MVC, and comes from the XAML/WPF/Silverlight world.   Your data and your commands, become part of the View->View Model bindings.  Applying it to web development isn’t a great leap.

Javascript is just a mess in my opinion.  It has been recently described as ‘assembly code for the web’, and I don’t think this is too far from the truth, since projects such as Coffeescript compile to Javascript.  It suffers from the unfortunate problem that its syntax is similar to C-languages, yet its behaviour doesn’t always match (variable hoisting, nulls, triple equals etc.), and as such, new javascript developers trip over themselves, myself included.

And lastly, there is application design.   MVVM and MVC patterns gently prompt you, the developer, to think twice about your design.  Just because it is a web page, it doesn’t mean that it has to scroll 5 screens-worth of data.  You wouldn’t design a Windows, or MacOS native application like that, would you?   If you were designing a performant application that showed data in an 8×8 grid, i.e. 64 cells, would you ship over 64,000 pieces of data?

knockout.js is a great library for javascript and web development and makes some very complex tasks very easy, and with a bit of patience and thought can lead to simple, maintainable, and elegant web solutions.

Some Tech Predictions

In order to keep things interesting, I thought I’d make some predictions about what is happening in tech over the next year, especially given the imminent arrival of Windows 8, and the Metro UI everywhere.

Disclaimer:  I like to think I’m rather neutral in terms of technology, though anyone reading this will probably disagree.

In no particular order:

  • Windows 8 and the UI refresh across Microsoft’s products will be successful.
    • The general public are generally accepting of doing things with a consistent UI from a well known brand.
    • XAML becomes the de-facto way of defining GUIs for all languages, including C++.
  • Windows Phone 7 (8!) will gain market share, starting in the US.
    • Android, and iPhone lose market share.
    • Microsoft, even though late to the market, drive down hardware costs and standardisation of phone hardware, in a similar way to the PC market.
  • ARM chips become even more prevalent as a result of Windows 8 running on ARM hardware.
    • Expect to see lots of Windows 8-ARM tablets with long battery life.
    • WinARM tablets easily take second position in the tablet market.
    • Expect major mobile announcements from Intel and AMD within 12 months.
  • Linux gains server market share
    • Loses desktop market share due to bizarre UI decisions by Ubuntu, Gnome, and KDE.
  • Apple:
    • Market value tops out, if not already:  nothing new to innovate and apart from continual hardware refreshes;  moves into middle-aged company territory.
    • OSes do not get consolidated:  desktop OS needs to be richer than mobile OS.
    • Potential for bottom-end (small business) growth as ‘teenagers’ that have grown up with Apple devices start working.
  • Google:
    • Continues to dominate searches.
    • Attacked by more litigation.
    • Consolidates businesses into key areas:  Android, and search (e.g. Wave killed off).
    • Expands to ‘enterprise’ level hardware projects market (e.g. cabling US cities).  Requires own infrastructure, so more moves in a ‘telco’ direction?
  • Facebook and Twitter:  expect acquisitions, or even a merger.  Core business idea is fragile:  see how quickly MySpace died.
  • Nothing major in the semiconductor industry, though possible:
    • Commercial fabrication of graphene in touch screens and lcds, bringing price down.
    • Memristor technology still another 2 years away for cheaper faster flash drives.
    • Prices, in general, rise due to world economy and China’s ‘rare-earths’ monopoly.

That should be enough controversy for 12 months.

Typography and Design

I’m quite interested in web sites that look nice and easy on the eye.  This is usually due to clean fonts, a decent grid layout, and simple informative graphics.  There are countless examples of this on the web now, from blogs, to dashboards, to magazine-style sites.   Smashing Magazine, for example, frequently lists whole collections of attractive web sites.

A good overview of web design and typography topics are covered in these two excellent and watchable (in my opinion) 50 minute presentations from the Mix 11 conference:

Fonts, Form and Function: A Primer on Digital Typography

Designing Infographics for Web Applications

If you’re not familiar with (modern) web design, some of the key points covered in these videos:

  • Design site layouts using a grid.
  • Sans-serif for web sites.
  • Understand what a colour wheel is.
  • Create your font-sizes using the golden ratio.
  • If you want it clever and simple, go for simple first.

Both videos are worth watching (especially if you’re sat on a train for 50 minutes).  Enjoy!

To Code or Not to Code

Working in a corporate environment often throws up many obstacles in the form of bureaucracy, corporate IT policy, and people. All of this has been well documented over the last few years by authors such as Steve McConnell, Frederick Brooks, Robert Martin, and so on.

“Those who cannot remember the past are condemned to repeat it”
George Santayana

Almost without fail, every system in a corporate environment has to interact with another in some fashion.  And yet, despite the onwards march of the rest of the word towards decoupled systems using a variety of network  technologies such as SOAP, REST, ajax, and so on, many companies are still mired with interoperability issues.  In some cases these issues are valid and real cases that have extreme performance requirements, such as sales and trading systems.

“It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”
Abraham Maslow

However in many cases, many developers still think in terms of the traditional ‘compile and link’ build cycle.  This seems to have the unfortunate side effect of enforcing (or just forcing) a mindset on many corporate developers that they must use the same language for every single task.  This thinking is utterly flawed, especially in a big company.  This policy might suit management, but it has the side effects of tying developers to old and often unweildy technology that isn’t fit or appropriate for the task in hand.

Measure twice, cut once.

Today, with such a rich technology environment of multiple languages and protocols such as C++, Java, C#, Python, Ruby, http, ajax, and so on, developers should be spending more time considering what language is most appropriate for a particular problem.  Does that directory look up need to be in C++, or can we do it in a small C# service?  Does that GUI need to be in C# or can we do it with HTML5?  Similarly, to decouple parts of the system, network apis need to be developed, something many developers traditionally shy away from.  With the advent of XML, JSON, SOAP, REST, ajax, etc.  the creation of  a (versioned!) network interface is considerably easier than it was a decade ago, with huge vendor and toolset support in just about every conceivable language.

As is well know and well documented if you separate your system into sufficiently small pieces with well defined APIs, bad platform or language choices can be easily replaced as required.   You don’t need an architecture astronaut, just the confidence to start coding with the aim of decoupling things.

This leads to the chaos monkey.  This post by Jeff Atwood, I think, may become a minor classic, for graphically illustrating why decoupled network systems are the way forwards.  The chaos monkey is, simply put, a process that randomly kills your processes to test the robustness of your system.  Return to the mindset I described earlier, with a monolithic system, the chaos monkey is going to kill it, and you will end up with egg on your face.

For many systems now, there is no excuse not to decouple them via the network, and gain all the benefits that come with it.

LLVM

LLVM

I recently had the opportunity to get up to speed on LLVM as part of project to replace the interpreter of an in-house functional language.

What is it?

As you’ll read elsewhere on the web, the acronym stands for ‘low level virtual machine’, but it is really a collection of compilation tools.

You, the developer, would take your parser, generated by Coco/R for example, and then use the LLVM libraries to generate byte code for your instruction set. The byte code is LLVM’s IR that can then be run by LLVM’s JIT, or the LLVM framework provides tools that compile the IR to a native executable.

It is used by the latest version of gcc, and is also in the Mono framework.

LLVM is built on top of C++ and uses STL extensively.

Getting started

Firstly, you need to download the latest version of the framework, and build it on your platform via cmake.

Once complete, you will have the entire toolset, including the llvm linker, debugger, static libraries, C++ headers, and examples, plus much more.

How does it work?

Once you have your parser front-end complete, you start to plug in LLVM by including the headers.

Probably the most important class is the IRBuilder. As its name suggests, it builds the intermediate representation. The Kaleidoscope example demonstrates it usage.

Lessons

Whilst coding this, assert becomes your friend. As with all compilers and parsers, you will be walking a abstract syntax tree, and much of the work you do will be on the stack, so liberally asserting the stack size will save you a lot of time.

Also, once you get past adding the basic types, you find the syntax tree gets walked in slightly unexpected ways than you might think, hence making a plan for which part of the parser you are implementing for might not necessarily get followed.

For our language, at least, you need to implement a main function that returns a set type, e.g. int main in C/C++. In the Kaleidoscope, you’ll notice that it adopts float as the only type it supports, and generates a nameless float main. Once the main function is implemented you can start inserting instructions.

Implementing llvm for a language takes the following steps

  • Implement basic types and operators
  • Implement basic casting
  • Implement function prototype and function body code
  • Generate an int main
  • Implement blocks and scopes
  • Implement conditionals, and loops
  • String handling

At this point our project was cancelled, but I expect the following steps would have been taken:

  • Implement multi-file ‘module’ linking
  • Implement classes and structs
  • Add optimization stages
  • Move from running code under JIT to full LLVM compilation to native binaries for performance.

At this point I would add ‘goto start’, whereby the experience gained from implementing llvm is reapplied to the whole problem: you might choose to make variables immutable once set; add new language keywords; or more significantly, add implicit threading to the library (e.g. erlang).

At some point I hope to revisit this and complete an implementation of a non-trivial language.

Microsoft

 

Reg:
All right… all right… but apart from better sanitation and medicine and education and irrigation and public health and roads and a freshwater system and baths and public order… what have the Romans done for us?

What have Microsoft ever done for us? Apart from standardising PC hardware (remember all the different kind of ports?), and pushing down the cost of hardware, and providing a ubiquitous operating system, and widely available development tools, and simplifying access to the internet.

They may not have done it first, and they may not have done it in the friendliest ways, but the modern computer (handhelds, phones, and not just PCs) owe a lot to Microsoft.

Starting with F#

I spent a few days last week working through F# tutorials for an algo trading project at work. First thoughts are that the language is quite nice, if somewhat confusing at first. This isn’t too surprising given that it is a functional, rather than procedural, language. One of the most compelling features is that it is a .Net language, and therefore leverages all of the existing class libraries available from C#, VB.Net and so on.

The other obvious functional language choice is Scala, which compiles to java byte code and runs on the JVM. There are lots of discussions on which is best, and how tail-end optimization works.

How does a functional language differ from a procedural language?

For example:

let f = 5

in C# would be:

int f()
{
  return 5;
}

Recursive functions require the rec key word, and you must use tail-recursion, rather than stack-based recursion:

let rec fib n =
    match n with
    | 1 | 2 -> 1
    | n -> fib(n-1) + fib(n-2)

Partial functions are nice, and tasks can be made to run in parallel/asynchronously quite easily.

The only other point that struck me was that Visual Studio support beyond very basic Intellisense, was completely lacking, i.e. no refactoring and no automatic code formating. I would like to see F# refactoring in Visual Studio ‘vNext’ (as seems to be the current trend for just saying ‘the next version’).