An algorithm for choosing your conference courses

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.

Advertisements

Brock Allen’s ASP.NET security: the tl:dr;

tl:dr;

– If it’s on an HTTP address, consider it public info — usernames, passwords, HTML, and JSON results are all interceptable.
– unless you’ve secured it, your database usernames, passwords, and data are ALSO being sent in plain text.

DAC deployment and Windows Azure.

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

(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

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

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.