Tag Archives: DevWeek

An algorithm for choosing your conference courses

Posted on by • Tagged • Leave a comment

So it seems I might have had better luck choosing courses than my colleague. Both of us are experienced programmers looking for info on new technologies. Here’s what seems to work when choosing a course:

Go for specific over general. Dejan Sarka’s talk on temporal data in SQL server, and Dominick Baier’s talk in WebAPI authentication patterns were very targeted — in Sarka’s case, to just one C# class and the way it could be used. Both were excellent, and full of ‘real’ information on exactly the type of code you might want to write tomorrow. My colleague has been going to more general talks, with names matching the regex /design pattern|unit testing|principles/, and those seem to be targeted to more of a beginner audience, or to someone who hasn’t been so actively following the industry.

DAC deployment and Windows Azure.

Posted on by • Tagged , , • 1 Comment

So here’s a nifty little feature. Visual Studio has a project type for SQL Server database projects. You write some scripts to create your database;

CREATE TABLE [dbo].[Customers]
(
 [Id] INT NOT NULL PRIMARY KEY, 
 [Name] NCHAR(255) NOT NULL 
)

Now that’s fine and dandy. You design your database and label it version 1.0.0. You build the project and it creates a ‘.dacbac’ file — a package which can be installed to Windows Azure to create your database. All is good, and your cloud app works happily on top of your database.

But let’s say the next version of your software requires some datbase changes. You update your creation script in SQL Server and label the version 1.1.0, a .1 incremental release.

CREATE TABLE [dbo].[Customers]
(
 [Id] INT NOT NULL PRIMARY KEY, 
 [Name] NCHAR(255) NOT NULL, 
 [Expired] BIT NOT NULL DEFAULT FALSE
)

Now you go ahead and build again. You get a new .dacbac file. When you try to upload the new definition, The Windows Azure service scans the SQL script, notices the columns, compares it to the existing database, and generates a change script which will upgrade from 1.0 to 1.1.

Now that’s really snazzy. Previously, developers would exect to write ‘patching’ scripts; something starting

-- 1.0 to 1.1 upgrade script
 ALTER TABLE [dbo].[Customers]
 ...

but notice that no such ALTER statements are being made. It’s just two CREATE statements, being intelligently compared. I asked Nino Filipe, and he confirmed that the service itself is actually parsing the file, figuring out the effect, comparing it to the current state, and generating a new script with the ALTER statements itself, so you don’t have to.

Creating a SQL Server database on Windows Azure

Posted on by • Tagged , , , • Leave a comment

(Just to address a point of confusion. In the old days, Microsoft called their cloud-based SQL Server cloud service ‘Windows Azure’. Then they made their cloud service do virtual machines and apps and whatnot, and they renamed the SQL Server bit ‘Windows Azure Sql Database’ or something. This post is about the SQL Server thing, whatever it’s called. On with the show, anyway.)

“Just give me a connection to a SQL instance”. That’s the promise of Windows Azure Sql Database. Out there somewhere in the cloud, Microsoft will give you a SQL server instance, into which you can create databases, and it’s supposed to function exactly like a SQL Server instance you’ve installed on a local machine. Or you can use it as the back-end store for an app running on Azure, of course, but for now, let’s just consider the use of it as a raw SQL Server instance.

The story is pretty complete. You create your instance through the Azure control panel, tell it some admin credentials, and then you’ve got an instance. You can open up Management Studio now if you want, and connect to your instance by typing in something like

w2490825.database.windows.net

and you now have Management Studio; you can now CREATE DATABASE or whatever you want to do. (Technically, you get a thing called a `TDS endpoint`. Google it.)

So databases created on Azure are replicated twice — you have a master copy and two slaves, and writes have to hit the master and at least one slave. That adds a little bit of latency, so the suggestion is that you write chunky, unchatty commands. Seems reasonable, I guess. But you get replication for free.

Now, don’t go confusing that with backups. If you `TRUNCATE TABLE PROJECTS` on your master you can’t switch to a slave to restore to an earlier state — you just truncated all three copies. This is just for redundancy in case a meteor strike hits the rack with your master DB on it. You still need to do regular backups.

And I say backups, but you don’t get those the same way. Actually, technically, you can’t do backup or restore. Not with `.bak` files. Instead, there is an import/export service that you can use. The .bak files contain transaction logs, and those would contain sensitive data from other users of the datacentre, so you can’t get ’em.

DevWeek Day 2 summary

Posted on by • Tagged , , , , , • Leave a comment

So, four sessions today;

Modern JavaScript — Scott Allen. A nice overview of JavaScript and the right sort of patterns to use to build larger, more maintainable systems. Covered basics like function scope and closures, and then delved into more advanced topics like IIFEs (immediately invoking function expressions) and the revealing module pattern.

So the nice outcome here for me is that I can go back to work and say that, yes, these things are good and worth doing — an expert at DevWeek told us. And I know that sounds kinda funny, but it means that it becomes easier to build a consensus amongst a team. Instead of saying ‘Steve’s an opinionated developer and has his way of doing things, but I’ve got my way,’ members of a team can feel more like they are following an independent best practice.

Temporal data in SQL Server — Dejan Sarka. This was a really interesting one. Dejan Sarka is a man who knows his stuff. Check out the book list. He wrote the Microsoft books on the internals of SQL Server 2005 and 2008.

Dejan Sarka’s presentation was about how to deal with timed data in SQL Server — a server which doesn’t include a timespan-like datatype. What he outlined was a system for building systems with really solid time-based support. The tl:dr; is this; identify a ‘time quantum’ like one day, and give each day an integer value. Then define a CLR datatype with a start-day and an end-day, forming a scalar value that can be used to represent a time range and which can be joined, unioned, etc — all the operations you need for querying. Now you can include ‘Interval’ columns in your database and use the interval as part of your key, for joins, etc.

Patterns and techniques for securing REST/HTTP-based services and (ASP.NET) Web APIs — Dominick Baier. The surprise big hit of the conference for me. This one was held in one of the big cinemas, and it got a lot of interest. It seems that the ASP.NET stack doesn’t have that strong a security story, and Dominick gave a nice presentation of how you might successfully secure a web service using OAuth2 and claims-based authentication. One to use, I think.

RESTful architectures on the Microsoft stack — Hadi Hariri. This one was interesting. Before I went, I thought that there was a danger that this would be a repeat of material from Christian Weyer’s talk yesterday and Dominick Baier’s talk today, but it took a different tack and I’m glad it did. The first half of the talk helped explain the difference between REST, which is a very particular design pattern for designing HTTP-based APIs, and non-REST HTTP APIs. The short thing here is that if you’re not sure if you’re doing REST, you aren’t. REST is very particular, has a fixed number of principles that need to be followed, and if you haven’t studied them and made sure you’re doing them, then you aren’t doing them.

The second half of the talk went into how you might go about implementing true REST on the parallel Microsoft stacks of ASP.NET MVC, and ASP.NET Web API — two products that are remarkably similar superficially, but which need their own different handling to become RESTful.

Now, the question is, do you want to be RESTful? Is it worth the effort, if you’re already doing an HTTP API? That question you can only answer for yourself, but it’s worth noting that it’s not free — it’s a re-write you need to do to your existing HTTP API.

Interlude

Posted on by • Tagged • Leave a comment

Standing in the conference area, I overheard someone talking about session cookies, and I honestly didn’t know whether they meant the free biscuits nearby or the HTTP headers.

Just listened to Scott Allen’s “modern JavaScript” talk. Good stuff! More later.

Separation between Data Transfer Objects and Entities, and Automapper to the rescue

Posted on by • Tagged , , • Leave a comment

One question we had a little while ago. When you return objects from a controller, should they be the same objects you get out of your data layer?

That is, if your data layer has an object like this;


public class Project
{
public int ProjectId { get; set; }
public string Name { get; set; }
}

Should you return this direct from Controllers, like so;


public class ProjectController: ApiController
{
public Project Get(int id)
{
return this.db.GetProject(id);
}
}

And the answer Christian Weyer gave in his talk was no — use a Data Transfer Object instead. This is a pattern which has you translate from the database entity down into a very plain object designed exclusively for transferring across the wire. We’d started doing this and named them transmission objects — we would have a DB.Project class designed for inside the system, and a TX.Project class designed for transmitting over the wire, converting to JSON, etc. We had agonised a bit over the added complexity, but it’s good to see that it’s a recognised good pattern, and I’ll sleep better tonight knowing we’re doing the same as the thought-leaders.

Where his solution was much tighter than ours is that he’d used Automapper — a library which allows for very straightforward mappings between comparable types. So if DB.Project and TX.Project share similarly-named members, you end up being able to translate one to the other using calls like;


DB.Project dbProject = ...;
TX.Project txProject = dbProject.Map(); // auto-mapper kicks in here

As an adjunct to that — there is also a JsonValue class which is designed for converting to JSON. Might be worth investigating in more detail…

Enabling OData through WebAPI

Posted on by • Tagged , , • Leave a comment

Here’s a very quick bit of code which Christain Weyer’s talk leads me to believe gives you easy OData support. OData support is enabled by (1) calling .EnableQuerySupport() on the HttpConfiguration object you get in global.asax.cs, and (2) Returning IQueryable<T> from the .Get() method of your ApiController subclass, and (3) marking that method up as [Queryable]. Something like;


// in Global.asax.cs
config.EnableQuerySupport();

// in your Api Controller
class ToDoController: ApiController
{
[Queryable]
public IQueryable Get()
{
return this.repo.Todos;
}
}

Not sure about the details, or whether this is perfect code — it’s copied out of a desperate scribbling session during the talk — but this might be enough for someone to start searching down the right track.

Hosting options for WebAPI

Posted on by • Tagged , • Leave a comment

So you’ll probably be using IIS to run your WebAPI apps, but you really don’t need to. WebAPI ships with a class which starts a web server handling WebAPI requests, in System.Web.Http.SelfHost..dll — HttpSelfHostServer.

Now, this is really interesting, for two reasons.

1) You can spin up a new server, run some tests against it, and shut it down. That means you can test all your HTTP traffic without having to set up a development server. I struggled with this all last week — how do you write a test to prove all your HTTP code is working, but not require all your developers to set up a web server like http://localhost:3000/myapp just so that you’ve got somewhere to act as an endpoint for calls? This short-lived server becomes your endpoint for the lifecycle of the tests.

2) It allows you to create a host outside IIS, on a non-server machine. For instance, imagine you were writing a document search application. It has a front end written in Windows Forms, and the backend is written in WebAPI. When you start the app, it starts an HTTP server at http://localhost:1234/mydocumentsearch. The front end loads its data by making GET requests to that server, and saves changes by POSTS and PUTS and DELETES. Now let’s say you want to search the corporate network using the same app. It would be simple to change the URI to http://corporateserver/documentsearch and now the same app, with no code changes, has become a corporate intranet-based application. Change it again to http://www.internetdocuments.com/search and it’s now an internet-enabled cloud-whatsit buzzword-filled bundle of awesome. And you don’t need to recompile to switch between these seriously different modes.

This approach says — code for HTTP first, and in fact only code for HTTP. You don’t need any other kind of public API. You don’t need an API that you compile into your app, but instead you really code in separate tiers communicating through HTTP. You can now code everything as if it were cloud-enabled, and then just switch to the cloud when you’re ready.

For me, it’s the testing scenario that’ll be most useful in the short term, but the other one is making me think about API design. After all, there are now even database engines (like CouchDb) which only offer HTTP/JSON interfaces. HTTP has become a universal communication mechanism. Will this become the widespread pattern of the future?