OWIN - Am I missing something?
Time for some opinion. In the last few days I have taken my first serious look at OWIN and I can't help but feel the whole idea is being polluted by the Katana project.
Time for some opinion. In the last few days I have taken my first serious look at OWIN and I can't help but feel the whole idea is being polluted by the Katana project.
I've been looking out for ways to use ScriptCS in my day-to-day work lately. Each time I do, I am impressed by how much time it saves me.
So today I found myself needing to write some code with a named Mutex in C#. ScriptCS to the rescue!
Imagine you have an interface.
public interface IAsyncCommand
{
Task ExecuteAsync();
}
In my recent post about interfaces I showed one approach to breaking up and consuming your interfaces that I am finding interesting at the moment. The idea was born out placing restrictions on myself and trying to be explicit about my dependencies. I wanted to structure the code in a way where I couldn’t get lazy and just start firing off database code from anywhere in the codebase.
I’ve picked up a new coding technique recently.
I’ve always been a bit uncomfortable with the 1:1 relationship between class and interface. I’ve also been uncomfortable with large service classes like a repository.
When you take a dependency on a large service interface you are hiding all the details about what you are actually dependent on, which can cause you problems down the line with your tests and refactorings.
Repositories in particular quickly escalate to large numbers of functions. If I am working on tests for a piece of code that takes a dependency on that repository I have no option other than to read the code to see what methods it is calling. Tedious.
As you may know, AppHarbify is built with Nancy. One of the reasons I decided to build it in Nancy, other than the fact that Nancy is awesome, was that I wanted to put together a real project that can be used as an example of Nancy in action. All the code for AppHarbify is available on GitHub.
To go with that I am planning to put together some blog posts talking about various aspects of the code. To start with I am looking at sessions.
An important goal of AppHarbify is to make as much open source software as possible be AppHarbor-friendly. To speed this process along I will be creating and/or finding many libraries to solve common problems.
Since finishing up my day job last week, I have had some time to dedicate to a project idea I had a few months ago. It is now time to formally announce it.
Say hello to AppHarbify!
AppHarbify aims to make deploying common software to AppHarbor even easier. So easy that it can be done by non-technical people or from mobile devices.
Today AppHarbor announced beta support for Background Workers, I have been eagerly awaiting this announcement as it is something I need all the time when hosting sites.
It’s about 8 months since my first contribution to an open source project. It was followed up minutes later by one to reverse all the accidental formatting changes I made. Damn you Visual Studio!
Time for a quick tutorial on how to get a site up and running on AppHarbor using Nancy and MongoDb.
Today my toolset of choice for a quick learning session is Nancy.
Reading straight from the box
Nancy is a lightweight, low-ceremony, framework for building HTTP based services on .Net and Mono. The goal of the framework is to stay out of the way as much as possible and provide a super-duper-happy-path to all interactions.
Got that? Think of it as a replacement for WebForms or ASP.NET MVC.
I recently decided to switch gReadie away from JSON.Net to ServiceStack.Text for it’s heavy JSON processing of the Google Reader API.
While there was no WP7 dll available in the NuGet package the source was all on GitHub, so using my recently learned Git skills, I forked the project and added my own project file targeted at WP7.
I thought I would share two quick lessons today. Learnt while submitting the latest gReadie update to the marketplace.
Late last year when I implemented the unread count Live Tile in gReadie I found myself stunned at just how complicated it was. It seemed to me that it would make a lot more sense if I could just whack a [LiveTileUpdater] attribute on a static method in a class and the phone would run that method occasionally.
I was therefore delighted when details about Mango were released as this is basically what Microsoft implemented.
Over the last few weeks I have been doing a complete rewrite of gReadie, my Google Reader client for Windows Phone 7.
The original codebase for gReadie was really quite cluttered, and I wasn’t going to be able to take advantage of the new features Mango enables without pulling it all out and starting again.
With most of the rewrite behind me now, It is time to start putting together a few blog posts discussing the new features I am using and lessons learnt along the way.
I answered a question on StackOverflow yesterday which I am pretty happy with, so I thought I would share the link on here.
The question asks for general advice on how to write and test an ASP.NET MVC 3 website that correctly uses Inversion-of-Control, Unit Testing and Mocking.
Today my post is to announce the release of a small plugin I have been working on over the last few days. It is a plugin for the Glimpse client side debug tool that integrates profiling information from RavenDb.
I have recently been using (and occasionally contributing to) RavenDB, a NoSQL (or Document) database for .NET written by Oren Eini, aka ayende.
My biggest contribution yet has been to help with the basic "glue" to drive the new UI for profiling RavenDB requests in an ASP.NET MVC web application.
This post is going to offer a few tips about changing your Windows Phone 7 push notification service from unauthenticated to authenticated.
Specifically it will focus on the challenges I ran into hosting a WCF service, in IIS7 on a cheap shared hosting account.
Now about that Image Control. I mentioned in my last post that it seems to download on the UI thread, or at least block the UI thread while downloading.
Personally I think this is going to be a major issue with v1 apps in the marketplace when used on 3G connections.
It is actually a difficult thing to test, so here is the methodology I have been using and the code I am using to get around the issue.
I am going to start putting together some posts on my experience writing our first Windows Phone 7 application, gReadie.
I came across the MultiBinding markup extension and IMultiValueConveter today when looking for a solution to a problem. Not sure how I missed it previously. If you didn’t I probably don’t have a lot to add, but if you have not heard of them then read on.
I’ve read a lot of blog posts about the Repository pattern. Whenever I have looked at implementing it, I always come away underwhelmed. It’s one of those things that displays nicely in a small example but in practice you end up with a huge number of methods that each query the data in a similar but slightly different manner, and for me it’s fault is with querying.
I have been working with WPF recently, and one of the things that annoys me most is the usage of strings to reference object properties. This mainly affects Bindings, but also pops up in other places such as the IDataErrorInfo interface.
In my last post I made mention that it was easier not to use the Enumerators on HTTP context objects when you want to unit test with mocking. This is due to some annoyances with casting (as they predate generics) that can be avoided with simple for() loops instead of foreach().
Today however, I am going to look at mocking GetEnumerator() in a more general sense should you ever need it.
Microsoft released the ASP.NET MVC Release Candidate yesterday (Link). One thing that pricked my ears in the release notes was a change to the ControllerContext that would apparently make it easier to use a mocking tool to unit test actions that needed to interact with the standard HTTP objects.
I have recently been brushing up on my Computer Science training, implementing various data structures and algorithms, O(log n) searching, that sort of thing. While traversing a binary tree returning it's contents in sorted order, I really wanted to put the yield keyword to use.
An issue I have seen blogged about a number of times with LINQ-to-SQL is that by strong typing queries, you lose the ability to create generic functions for processes such as fetching records by their Primary Key.
One thing I have always needed to do in my web sites is break sections of pages out into a re-usable component. If you look at http://www.ht.com.au the "Featured Product Of The Month" panel displays three product "patches". This exact same patch is used on the Cart page and the Hub pages. It is a nice little class/template that you pass a product number to and it spits back the HTML for that patch, which you write out like any other expression in your template.
I have been further exploring the concepts of Test Driven Development of late, in particular around the ASP.NET MVC framework.
One concept that is very new to me is mocking. I have been using Rhino Mocks. This is not going to be a post about mocking, I am far much of a novice to offer any useful advice on this front just yet. However, it is pretty cool stuff and worth a read.
I have recently started work on what will become our first production application using LINQ-to-SQL and had hoped to use the CreateDatabase() function that is found on the generated DataContext to simplify the process of setting up the database on the client machine.
Ideally I wanted a nice simple piece of code like this
In this article I am going to look at Extension Methods. Although this is not a specific to LINQ post, Extension Methods are the compiler concept that LINQ was built on.
The basic premise is to allow the developer to add functionality to any class they like without the need to subclass it or wrap it in a wrapper class. This is a great new technique because it allows you to continue using a class like String or DateTime and not need to remember to use MyString and MyDateTime or fall back on static helper classes.