Windows 8 – The end of an error?

So I hear there’s some news about a new Windows, and people are worried by the 5-minute Windows 8 press release because it mentions HTML5. Some people are really worried. I’m not in tears myself just yet, though I would be upset if the scare-mongers are proved right.

Personally I’m just (finally) starting out in WPF. I really like it and if I’m honest I’m not a great fan of HTML/CSS because of the inconsistencies between browsers. I’m aware I’m not alone in that respect. My worry isn’t about historical investment in WPF, but the fact that I’m just starting out. I hope I’m not writing the new Betamax for my new apps.

However, If one takes a deep breath, relaxes and looks at it again, one could surmise that it’s unlikely .NET will be dropped totally. MS do have a good history (often to their own detriment) of backwards-compatibility, and I reckon that in the fullness of time there will be "layers" of apps:

  1. HTML5/CSS3 for tiles and "widgets", though SL might be part of the "tile" story.
  2. LOB apps that want to talk to local databases and/or webservices etc but still solve the business problems in a RAD-fashion will be Silverlight and WPF (WinForms will surely be supported but possibly discouraged for new apps and relegated to the “legacy” UI that so closely resembles Win7 in the video).
  3. Device drivers and those apps that need to get down to nitty-gritty close-to-the-metal stuff or require super-duper high performance will be for C/C++ devs with brains far larger than mine.

It’s not much different from the decision that WP7 apps being totally SL-based. They’re trying to tidy-up a long-established line of inconsistent apps and UI tech to give "mom and pop" users a better experience. My Dad loves his iPhone but still struggles with the fact that Windows isn’t the Pit of Success when it comes to usability and stability.

Let’s face it, advanced users (application/IT support, testing teams, DBAs, developers) will not use this new HTML5 veneer all that much, because it’s not meant for them. This is MS taking a look at their customer base, comparing it with the iPhone customer base, and realising they need a simpler OS UI that allows people to watch videos, check emails, mess with their pictures etc. It’s simply moving to a "task-based UI" on a grander scale.

Of course, tooling goes a long way to calm .NET devs in these situations. At the moment many may be worried by the prospect of using Notepad to write their Windows apps and struggle with debugging and implementation inconsistencies. However I’m sure that companies like JetBrains and DevExpress will be there to help.

It will be fine, don’t worry. 🙂

Visual Studio Screen Real Estate

I have to say first that I am a total keyboard-freak. I use keyboard shortcuts for all Visual Studio and ReSharper commands. Over Christmas, my main dual-24”-screen development machine developed a fault, and I fell back to my (excellent and highly recommended) Lenovo ThinkPad X201. Of course screen real estate was suddenly an issue, and I decided to do something radical.

I got rid of all the toolbars.

Yep – all of them.

Literally, I right-clicked the toolbar, and un-checked every single one, in both design mode and debugging mode. I then found and installed the Hide Main Menu plugin for Visual Studio.

Now Visual Studio looks like this:

SingleScreenVS

This is good, I like this. Then I fixed my desktop PC, and didn’t want to lose the goodness, but also wanted to make use of VS2010’s improved multi-monitor support. I exported All Settings->General Settings->Window Layouts options to SingleMonitor.vssettings, put that file into my shared DropBox folder to sync it to the desktop, imported it, and customised VS to look like this:

MultiScreenVS2

I’ve exported those window layouts to MultiMonitor.vssettings, so I can easily switch between them. Sometimes I move to a single screen even on the desktop in order to read documents/websites on the secondary monitor, or when screen sharing with my colleagues.

If you want my window layout files, you can find them on my box.net page.

Additional Tips:

  1. Don’t forget when customising your window layouts to also customise them when debugging, as VS will switch between layouts as you start and finish debugging.
  2. Try closing toolwindows too. If you learn the shortcuts to get them back (or alternatives) it makes for a much cleaner feel.
  3. Try replacing the solution explorer with ReSharper’s “CTRL+T” command. It’s faster and doesn’t take up space.
  4. Try working in full-screen mode when actually coding (toggle using SHIFT+ALT+ENTER).

I appreciate I may have taken this as far as I could without using vi or something, but hopefully it serves as a little inspiration.

HTH.

Rabbit in the headlights (Windows Identity Foundation woes)

I’m working on a new project at work, and part of my role as architect is to decide how we’re going to build authentication and authorisation. This will be a desktop smart client application deployed via ClickOnce that will use web services (hosted by us at our datacentre) to operate, with a dash of local caching for offline operation where applicable. We already have an ASP.NET website that has auth/authz behind it, so ideally I’d like to build on that.

After much internetting, I re-discovered Windows Identity Foundation (WIF), having heard a little about it on a DotNetRocks episode some time back. I like the concepts – separating auth/authz from your applications and instead obtaining tokens containing the claims the user has.

Sounds great. In theory.

In practice, it’s appears WIF suffers from “Over-engineering Microsoft Giddyness” syndrome. I’ve watched various WCF Pluralsight videos (which are excellent, by the way) to try and get a basis of understanding for WIF, but when I really got into WIF itself, it’s too much for my small brain to cope with.

Essentially I’ve worked out that I want to have an “Identity Provider” that my desktop app can authenticate with, and that will return a security token in exchange for a valid username and password. I then want to be able to pop that token into subsequent calls to the other WCF services, which will then investigate the claims supplied in that token to establish whether the user can carry out those operations or not. However it seems writing my own Identity Provider that works off our user store is, ahem, “non-trivial”. There are a few choices of existing ones out there in the world., but it all seems like over-kill to me.

So I’m going to steal the idea and Build My Own. I’ll have a WCF service that is accessed via SSL that will return a token containing various information (“claims” in WIF parlance) about the user in exchange for a valid username and password. This token will then be made available in the SOAP headers of calls to our other web services (also accessed via SSL, so it’s okay Smile).

I know what some of my readers will be thinking – that there’s a reason for the engineering that’s gone into WIF. The truth is that this approach should work just as well. I’ll need to have a think about possibly signing the token and encrypting it so that the web services can be confident the data hasn’t been tampered with or otherwise intercepted, but I’m willing to be my small brain comes up with The Simplest Thing That Could Possibly Work. A key tenant of Domain Driven Design, and something else I’m going to strive for on this project.

The Big Rewrite

I know the big rewrite is almost never the right answer, but in the case of a stalled hobby project that started a year ago with Linq to SQL, ASP.NET MVC 1.0, then maybe it’s okay. 🙂

I’ve decided to start again totally from scratch. This is for a few reasons:

  • I want to start again using ASP.NET MVC 3 with Razor view engine, and make use of the many other improvements.
  • I want to use EF code first, rather than Linq to SQL.
  • I attended DDD9 today, and saw a session with a lot of useful information about CQRS that I want to try and apply here.
  • I want to remove the product name from the code. I think I’ll still be branding it as “Workflo”, but since I have this overall idea of a project called “Genrsis” that’ll include other products, the root namespace for this particular product will probably be something more abstract like “Genrsis.WorkItemTracking”.
  • I want to host this project on codeplex.
  • There is a lot of stuff I can reuse from the old code: my custom ASP.NET MembershipProvider, logo, CSS etc.

So I’m going to get started on this now. The sooner I can start dogfooding the better. 🙂

Yet Another Bug Tracking System

Other titles I thought of included “If you build it, they will come” and “Building a better mousetrap”.  What can I say, SEO isn’t a skill of mine.

I needed a hobby project that was a thought experiment (which is my caveat for all my bad architectural decisions) that could go somewhere.  That wasn’t just a name and a few lines of half-finished code.  Something that I could take on a laptop to job interviews in the future and say “No, I can’t actually work out an algorithm on the spot that calculates the distance in yards from London to Calais, but look at this neat thing I’ve done…”.  Not that I’m looking for work right now, but it’s good to have something to show for one’s skills that one owns the IPR to.

Amongst other things, I wanted to try ASP.NET MVC (which was v1 at the time), jQuery and Linq to SQL (I know it’s out of date now, but I have my reasons…).

I decided to be different, and write a bug-tracking system.  My motivation came in the form of difficulties using FogBugz at work.  FogBugz is very capable, but only if you use it the way the guys at Fog Creek expect you to – which means conforming to the way they think bug tracking should be done.  We’re trying to use it in a different process than it was designed for, and it’s caused friction.  Being the jumped-up know-it-all that I am, I thought I could do better (well, different) so, full of Great Ideas, I started planning.

This was many months ago.  I’ve put quite a few hours in here and there.  Probably a few weeks FTE.

Then yesterday I deleted much of the code I’ve written.  I’ve kept infrastructure stuff (like ASP.NET Membership providers – yuck!), but basically this is a re-write of what little I’d actually managed to create.

I’ve learnt much with my tinkering over the last year, but now I’m going to give it a proper go.  Hopefully this may even end up as something we can use at work.  It’s called “Workflo”.  Yes, I know that name exists but I have a project codename to put it under and “Buggr” just didn’t seem appropriate.  It has few key features:

  1. A fully-customisable workflow.  Not using MS Workflow Foundation, but something home-grown (it’s a thought-experiment, see).
  2. Estimates and time-tracking per status.  So developers estimate the development, testers estimate the testing, etc etc.  Then you see how long those things actually took and do amazing reports like how good people are at estimating, either for themselves or on behalf of others, and break down how much effort goes into testing vs. actual coding.

That’s kind of it, for now.  I have lots of wonderful ideas floating around, and the plan is to use this blog to chronicle the various design decisions and implementation tribulations as they happen.  Hopefully I will learn something, even better would be to teach something.  We’ll see.  I’ve got a little more re-jigging to do, and then I’ll be posting the code on Codeplex.

Wish me luck!

Poor man’s KVM

I have two PCs but one keyboard and monitor. Rather than shell out for a KVM, I plugged each PC into a different port on the monitor, and use the menu to switch between them.

For the keyboard I put a USB extension lying on the floor near the main PC, and I just get on my knees to swop the keyboard between it and the back of the main PC.

I don’t need to do this too often, so it works quite well enough for me. 🙂