How to ensure a terrible User Experience

Mobify your web with JQuery Mobile

Let's face it, we all use our (smart) phones most of the time to browse the web. Then you get sites that aren't formatted for mobiles and you end up zooming and panning away, confusing yourself with the "all over the show" navigation, not to mention the teeny tiny links that makes it difficult to click - if you have toes for fingers (like me).

It's no doubt about it, we as web developers need to cater for mobile devices when we do web apps & -sites. Usually we achieve this by duplicating pages & logic in a sub-web that is formatted specifically for mobile devices, having our site www.example.com for PCs and m.example.com for mobile. This can become quite cumbersome - especially when doing site maintenance.
 
Have no fear, JQuery Mobile is here!
For those that doesn't know what JQuery is, go here before moving on.

JQuery Mobile is a unified user interface system that works seamlessly across all popular mobile device platforms, built on the rock-solid JQuery and JQuery UI foundation. Focused on a lightweight code base built on progressive enhancement with a flexible, easily themeable design.


Built with HTML5 in mind, we can now leverage the super sexy UI on touch devices right on our web apps!

The JQuery Mobile "page" structure is optimized to support either single pages, or local internal linked "pages" within a page.

The goal of this model is to allow developers to create websites using best practices — where ordinary links will "just work" without any special configuration — while creating a rich, native-like experience that can't be achieved with standard HTTP requests.

You can read more on JQuery Mobile on www.jquerymobile.com
or get it with NuGet - jquery.mobile

If you're not sure what NuGet is, I blogged about it a while back

Mobile View Engines to the rescue!
From the origin of the Razor view engine, things just got better. While working on an app (built with MVC & Razor), I came across a nifty Nuget package called MobileViewEngines

This adds all the plumbing for making your web app mobile viewable. In MVC this works great: If you have a view called "Index.chtml" for instance, just create another one called "Index.Mobile.chtml".

Everything else, will work seamlessly together - your controller will still return the "Index" view, but it will be dependant on the device if it will use the desktop or mobile version.

This can also be implemented on old school web forms.

Now, implement JQuery Mobile on top of this; and you have a truly winning solution.

Here is some information on this

I hope this can help anyone out there that wants to go mobile with their apps. The mobile world is bound to happen, it's not a question of if, it's a question of when. So best start now.

May you have a blessed 2012 and become the best in what you do - code! :) and remember: "Don't over do it, rather do it over"


Follow me on Twitter @FanieReynders

I do this, so you don’t have to…Corrupt Database

Every now and then, we are in the fortunate position to walk into the office, only to be confronted by this glaring screen.

At this point, we normally start muttering to ourselves, all sorts of obscenities…
After all the fun has been taken out of the morning, we realise, that right now, it is up to you to save the day.

You start checking your backups, and going through the normal procedure of restoring, when an
angry man starts screaming about all the work that will be lost if you restore to the last backup.

Sigh… Ok. What now?
Well, not to fret, there is some light at the end of the tunnel. First things first. Before going any further, I recommend you stop SQL Server, and make copies of the offending DB’s files so that you can always come back to this point, if all else fails. You want to see what is actually wrong with this DB. So you do the logical thing.

DBCC CHECKDB, only to be confronted with the very obvious answer of… The DB is SUSPECT!!!

No, really? I couldn’t tell that from the object explorer, and then I decided to do a check DB, just for you to confirm my suspicion all along. Thanks SQL. Then something in the back of your mind
comes creeping up. A little voice telling you, to change the DB status to something a little more friendly...

So you start by doing the following:
Change the suspect status by sp_resetstatus , which turns off the suspect flag on a database, but leaves all other database options intact.

If you were to run a SELECT DATABASEPROPERTYEX('YourDbName','STATUS') you would now get an ONLINE status.

Now you want to declare an emergency situation, and go and get some coffee, because whatever comes up after this, is what you will need to fix. This is also the point where you start to consider that maybe the current backup strategy is not really sufficient for this specific DB.

So you use ALTER DATABASE (YourDbName) SET EMERGENCY

Ok, coffee down, now you can start digging around. You do your DBCC CHECKDB again, and look for any obvious errors. In my case, I know that the log file was corrupt (As I actually broke it myself) and work through the rest of this result set just to confirm that nothing else was damaged.

Once you have your problem area identified, you can now decide whether it will be advisable to continue marching on through the process of recovery. You decide that there will be some data loss, but overall, your results should be quite good. And as this is one of the few options left for
you, you push on.

ALTER DATABASE (YourDbName) SET SINGLE_USER WITH ROLLBACK IMMEDIATE

You do this in order for SQL to be able to repair your corrupt DB without outside interference.

Then you attempt the repair:
DBCC CHECKDB (‘YourDbName’, REPAIR_ALLOW_DATA_LOSS)
From here on you hope that the angry man screaming at you hasn’t lost too much data, and allow SQL to fix the problem areas.

As you can see, in my scenario, it actually recreated the Log file.

Once all these steps are completed, all that’s left to do is to give the DB back to the users, too test, and look at any potential missing data records.

This might be inevitable, as there might be corruption on specific areas that they used, and as such, SQL will discard these changes, to get to a good state. Explaining this to the angry man, might be a bit more difficult…

You do this with the command ALTER DATBASE (YourDbName) SET MULTI_USER

You will now see this beautiful screen, where you can sit back and relax, and enjoy that second cup of coffee.

Obviously, this leads you back to that thought of the backup strategy. You have to be prepared for these sort of eventualities, and revisit DR situations as often as possible, to avoid these little problems as best you can.

PS: If all of these steps fail, remember that first recommendation of copying your files away first. You can always try to extract the data from a suspect DB manually. Again setting it into emergency mode, and single user, so that you can try and access the data, to export to a new DB. If you need more info on this, let me know, and I will be glad to help.

Scrum Basics

Introduction

Scrum is a management framework and, being one of many Agile 'flavours', is designed to add clarity, focus and transparency to project planning, development and implementation. Alistair Cockburn, from Agile Software Development: The Cooperative Game (2007), describes software development as 'a cooperative game of invention and communication'. Scrum provides a platform for people to work together effectively and to relentlessly make visible every problem that gets in the way of progress and, properly implemented, increases development speed, creates a culture of driven performance, and allows stable and consistent communication at all levels.

The information provided below serves to give an overview of the Scrum framework, the roles involved, and the various meetings that take place.

Role Breakdown

The Product Owner's responsibilities are:

• Working on a shared vision
• Gathering requirements

• Managing and prioritising the Product Backlog

• Accepting the software at the end of each iteration

• Managing the release plan

• The profitability of the project (Return on investment)

The Scrum Master's responsibilities are:

• Empowering and shepherding the team
• Removing impediments
• Keeping the process moving
• Socialising Scrum to the greater organisation

The Team's responsibilities are:

• Estimating size of backlog items
• Committing to increments of deliverable software, and delivering it
• Tracking own progress
• Is self-organising - but accountable to the Product Owner for delivering as promised

The Product Backlog

The Product Backlog is a living document that contains a list of work items that need to be completed over time. Items may be added to the backlog by anyone, but only the Product Owner, with input and negotiations with the stakeholders, has the right to determine the order in which they will be executed by the Team.

The Sprint Backlog

The Sprint Backlog represents the work that the team has committed themselves to complete during the course of the current sprint. This list is usually represented by a task board, but may take any form as long as it is able to 'radiate' this information to the whole team, or anyone else, and indicates progress.

The Sprint Meetings

The sprint is the heartbeat of the Scrum cycle. It is bookmarked by sprint planning at the start and by the sprint review and sprint retrospective at the end. The length of the sprint is fixed and is never extended. Each day during the sprint the team holds a daily Scrum meeting (daily stand-up). Each meeting in the Scrum cycle is strictly time-boxed. For a 30 day sprint (4 weeks) the time boxes for sprint planning 1 & 2, sprint review and sprint retrospective are set at four hours each. For shorter sprints the time-boxes should be adjusted proportionately with the length of the sprint, i.e. a sprint length of 2 weeks produces time-boxes of two hours for each meeting. The daily Scrum meeting is time-boxed to fifteen minutes in all cases.

The meetings in the Scrum cycle as summarised below:

• Sprint Planning - Part 1

Sprint Planning 1 is carried out at the start of the new sprint and is where the Product Owner presents the set of priority features that need to be executed. The Team discusses the items until such time that everyone understands the requirements in sufficient detail to be able to commit to their delivery at the end of the sprint. The Team alone decides what it can deliver in the sprint and takes into account the duration of the sprint, team size, team capabilities and the team's definition of done (DOD).

• Sprint Planning - Part 2

Sprint Planning 2 is held after Sprint Planning 1 and is a design workshop where the Team collaborates to create a high-level design of the features that they have committed to deliver in the sprint. Those features are broken down into a list of tasks that the Team collectively need to execute in order to turn the selected items into a deliverable product.

• Daily Scrum Meeting

The daily Scrum meeting is one of the three primary "inspect and adapt" aspects in Scrum. The Team meets to communicate and synchronise it's work to ensure continues progress and to avoid work impediments/blockages.

The daily Scrum meeting is not for reporting progress to the Scrum Master or Product Owner, but rather to keep each other informed by answering the three questions:

• What have I done since the last Scrum meeting?
• What will I be doing today?
• What is impeding or blocking my progress?

Further discussion may take place after the Scrum meeting if necessary.

• Sprint Review

While the sprint review does include a demonstration of the new features that the team has completed in the sprint, it's primary purpose is to 'inspect' what the team has delivered and gather feedback from the attendees to 'adapt' the plan for the next sprint. The focus of this meeting is a balanced combination of demonstration and conversation.

• Sprint Retrospective

This meeting is the final meeting of the sprint. Whereas the sprint review is focused on the Product, the retrospective is focused on the Process - the way in which the Team is working together, including their technical skills and the software development practices and tools they are using.

The sprint retrospective is restricted to the members of the Scrum Team - the Product Owner, development team members and the Scrum Master.

The focus of this meeting is to inspect, at a deep level, how the team is collaborating and performing, and to take actions to improve on processes, tools ,etc. This often requires deep introspection and sharing which should be done in a neutral environment.

• Estimation Meeting

During every sprint, the Product Owner convenes one or two meetings where the Scrum Team, and if required, other Stakeholders, meet to size the backlog items that have been added or to re-size large items that need to be split into smaller ones for tackling in the next sprint or two.

How to kill a Ninja

Implementing a different kind of Service Pattern

For the past few months I've investigated many different types of patterns I can implement in my projects; like Repository Patterns, Unit of Work Patterns, Service Patterns etc. After plenty of research, late nights and a gazillion units of black coffee; I finally came across a some sort of hybrid solution that works for me in many different scenarios.

Being aware that a specific pattern to follow is purely dependant on the particular solution, I wanted to be comfortable with a rock solid "generic" implementation that can be used across many types of applications like ASP.NET MVC, WPF, Silverlight & WindowsPhone.

The main reason for this was to make the code more unit testable using mock-ups, this can be implemented easier because everything is very loosely coupled and is utilising the beauty of dependency injection (DI).

I want to mention that the following "pattern", if you will; is only a suggestion to those who feel daring and in need for something fresh & different. Your comments are more than welcome.

What we'll build

Okay, don't get bored so soon! Let me walk you through the whole thing.

This is a typical ASP.NET MVC implementation, I haven't tried using this in other frameworks yet but I'm very confident that it should work just as well.

Scanning the diagram from the bottom, you'll first notice the database. This can be any source of data (SQL, XML files etc.)

Next, there's two IDataContext implementations: MockDataContext and DataContext. This serves as the data access layer to our store and can be anything from EntityFramework, NHibernate etc. Note that the MockDataContext does not have any connections to a data store as this will be fabricating mock data for our unit tests.

    public interface IDataContext

    {
        IQueryable<T> All<T>() where T : class;
        IQueryable<T> Find<T>(Expression<Func<T, bool>> predicate) where T : class;
        T GetOne<T>(Expression<Func<T, bool>> predicate) where T : class;
        T Add<T>(T entity) where T : class;
        T Update<T>(T entity) where T : class;
        T Remove<T>(T entity) where T : class;
        bool SaveChanges();
    }

By implementing the Factory Pattern, it allows us to create an disposable instance of different IDataContext implementations, in turn better managing database connections & utilising connection pooling.

The only responsibility of the IDataContextFactory implementation, is to create the applicable instance of the data contexts to be consumed.

    public interface IDataContextFactory
    {
        IDataContext Context { get; }   
    }

    [Export(typeof(IDataContextFactory))]

    public class DataContextFactory : IDataContextFactory
    {
        public IDataContext Context
        {
            get { return new DataContext(); }
        }

    }

We all may be familiar with the next item, the Service; that houses all the business logic of each unit of work. The InvoiceService implements IInvoiceService which forces an property of type

IDataContextFactory named "factory". 

    public interface IInvoiceService

    {

        IDataContextFactory factory { get; set; }

        Invoice GetInvoice(string invoiceNumber);

        bool SaveNewInvoice(Invoice newInvoice);

    }

    [Export(typeof(IInvoiceService))]

    public class InvoiceService:IInvoiceService

    {

        [Import]

        private IDataContextFactory _factory;

        public IDataContextFactory factory

        {

            get { return _factory; }

            set { _factory = value; }

        }

        public Invoice GetInvoice(string invoiceNumber)

        {

            using (var context = factory.Context)

            {

                var invoice = context.Find<Invoice>(i => i.InvoiceNumber.Equals(invoiceNumber,  StringComparison.OrdinalIgnoreCase));

                return invoice;

            }

        }

        public bool SaveNewInvoice(Invoice newInvoice)

        {

            using (var context = factory.Context)

            {

                var invoice = context.Add<Invoice>(newInvoice);

                context.SaveChanges();

                return invoice != null;

            }

        }

    }

All the classes mentioned above, lives in the Domain layer of the solution. The next few items is applicable for a ASP.NET MVC implementation:

I'm not going into detail of MVC, but the general rule of thumb is to keep your views skinny, have thin controllers and fat models (View Models). It's also best practise to have a ViewModel for every View so that unit testing is possible on your view logic.

Keep the behavior logic in the Controllers, view logic in the ViewModels & business logic in the Domain.

Moving on, The InvoiceController consumes a service of type IInvoiceService. (Not to be confused by an web & WCF service, the term "service" here merely acts as a host of business specific tasks exposed by the contract IInvoiceService) 

The Controller contains many Actions that is responsible for relaying commands, DomainModel-ViewModel mappings & showing certain Views depending on request. In this case, an Action in the

InvoiceController can decide to pass the ViewModel to either a Desktop or Mobile View.

The Controller's Action method may use the helper class InvoiceComposer to map from Domain Models to ViewModels and back. There are many Object Mappers available like AutoMapper.

    public class InvoiceController : Controller

    {

        private readonly IInvoiceService invoiceService;

        public InvoiceController(IInvoiceService invoiceService)

        {

            this.invoiceService = invoiceService;

        }

        public ActionResult Details(string invoiceNumber)

        {

            var domainModel = invoiceService.GetInvoice(invoiceNumber);

            var viewModel = domainModel.ToViewModel();

            if (Request.Browser.IsMobileDevice)

            {

                return View("Invoice.Mobile", viewModel);

            }

            return View(viewModel);

        }

        [HttpPost]

        public ActionResult Save(InvoiceViewModel viewModel)

        {

            var domainModel = viewModel.ToDomainModel();

            invoiceService.SaveNewInvoice(domainModel);

            return View(viewModel);

        }

    }

Wiring everything together

By utilising the beauty of dependency injection, we can create a container that houses the configuration mappings of contracts to the implementation classes. In return, we just expect the different types concerned to be magically instantiated for us by the Dependency Resolver. No ugly "Object reference not set to an instance of an object" exceptions (or at least if the DI is setup correctly).

In this example, I'll be using MEF (no not the drug) for the DI framework. MEF is obviously short for Managed Extensible Framework and is way more than just an Dependency Injection engine.

Note the [Import] & [Export] attributes on the code above. This tells MEF to Export the implementation class as type of the contract specified and imports the instance of the implementation class when required.

Here is some cool resources on MEF for anyone that's interested

I don't want to steal Steve Job's line here but... There is one more thing...

Unit Testing

Having our code so loosely coupled means better unit testing which means more rock solid systems which means happier clients which means more money :)

Okay but its not all about the money, it's about that air punch at the end of the day when you feel you just created the best and cleanest system in the world.

Going into no detail here is what a typical unit test may look like with mocking in place:

 

 [TestMethod()]

        public void GetInvoiceTest()

        {

            var invoiceService = new InvoiceService();

           //This MockDataContextFactory also implements IDataContextFactory

            invoiceService.factory = new MockDataContextFactory();

            string invoiceNumber = "INA001";

            var expected = new Invoice

                       { Id = 1, InvoiceNumber = "INA001", Amount = 100 };

            var actual = invoiceService.GetInvoice(invoiceNumber);

            Assert.IsInstanceOfType(actual, typeof(Invoice));

            Assert.AreEqual(expected, actual);

    

        }

 So there you go. Another mouth-full from me.

I hope that this may help everyone else interested. Like I said, I urge my fellow Ninjas to please feel free to comment, correct my possible wrongs or even elaborate on a possible other solution. This works perfectly for me.

Till next time...

Cheers.

 Follow and Tweet with me on Twitter: @FanieReynders

Jump Start your next project with Nuget

In between the company end-year functions, demanding clients and of course my fabulous life :) , I've deceided to do some blogging again. In fact, it's been a while since any Ninja laid a finger on a keyboard here, (or an iThing)...

A while ago I came across a cool little thing called "NuGet" (pronounced new-get). No, it's not the kind of things you get from Mc Donalds. According to the website, NuGet is a Visual Studio extension that makes it easy to install and update [open source] libraries and tools in Visual Studio. But, I believe they're being modest. It's way more cooler than what meets the eye.

Okay, so whats all the fuss about? Well, the main idea behind it is to allow you to install any files (libraries, media, code files etc) into your project / solution in a managed way with versioning & dependency detection. In the NuGet world, these files are bundles into things called "packages".

When you use NuGet to install a package, it copies the [library] files to your solution and automatically updates your project (add references, change config files, etc). If you remove a package, NuGet reverses whatever changes it made so that no clutter is left

There is a wide variety of libraries ready to be downloaded & used (3680 to be exact) from the offical NuGet Package Source. You can even create your own package source that can be hosted to be available externally or internally on your intranet - I will get to this later.

So, let's install NuGet...

Obviosly, first you need to open every Ninja's biggest asset: Visual Studio 2010.

1. Open up the 'Extension Manager' from the Tools menu

2. Under the Online Gallery section, search for "NuGet" and click "Download"

After downloading, "reading" the legal stuff & installing, you need to restart VS for the changes to take effect.

That's it, now we have NuGet installed & we can get "Nugetting" :)

For this example, I'm going to create a blank web forms project (yes I said web forms) and install "EntityFramework.Patterns" onto it. This is only to show the functionality of NuGet.

1. After you've created a blank project, right-click on 'References' there is an additional item "Manage NuGet Packages" - Click it. (or if you're using a touch screen, I rest my case)

2. Next you will be presented by the main NuGet Manager

3. From the 'Online' section (on the left), search for "EntityFramework.Patterns" and hit "Install"

Note that EntityFramework 4.1 is required for this library to work (under dependencies). But have no fear NuGet handles it for us:

That's it... So if we go back to our little sample project you will notice that a few references were added including a packages.config file. (Also note that some content has been added to the web.config file)

There is of coarse an alternative "Ninja" solution to do all this, by using the Library Package Manager Console (Tools > Library Package Manager > Package Manager Console). Just type:

Install-Package EntityFramework.Patterns

You can now use the installed library in your code. Im not going into how we use EntityFramework.Patterns, but hopefully you get the idea.

But, where is the actual packages? If you go to your solution folder, you will note a "packages" folder. When you open it up, you'll notice all the packages that is installed in the solution. So best checking this folder into TFS!

RIGTH!
Now, for the cool stuff... Creating your own package...

Creating your package is exactly like adding files to a ZIP file. But in this instance, the "zip" file is called a NuGet Package file (*.nupkg). There is also a specifications file called a NuSpec file (*.nuspec) that contains all the meta data of the package like version information & dependencies etc.

There are many ways of creating and publishing your packages:

The Ninja Way
The Easy Way

You can also host your own package feed

You can view a variety of videos available on this subject

So, Ninjas... Now you have no excuse to deliver the "best in the business" code. Get coding away... Get packaging away and make your life easier with NuGet.

Follow me on Twitter @FanieReynders

Until next time..... Cheers.