Catapult Systems, my employer, is hosting several of the upcoming Windows Azure Dev Camps.
I’ll be helping out with two in Denver (April 25)
and Houston (April 29).
The Dev Camps will provide you with an overview of Windows Azure and an opportunity to complete several
Hands-on Labs, including topics such as IaaS
and Azure Mobile Services.
If you plan to attend one of these events, or if you are just curious to see what Azure can offer, sign up for a free 90-day Azure trial.
If you are a student, you should also sign up for Dreamspark, which includes a
free Windows Store developer license.
(You need the Windows Store developer license to send push notifications to a Windows 8 client.)
In .NET Rocksepisode 855,
Jeff Fritz commented on ASP.NET Web API
being somewhat confusing in terms of its intended use. I don’t tend to agree,
but I thought I would address one point he made in particular: that Web API
is perhaps just another form of repository.
Web API is much more than a repository. And yes, it is indeed a protocol
mapping layer. As Uncle Bob once noted, a web or api front end is just a mapping
layer and is not really your application.
In many cases, however, one could argue that a web-api-as-repository is a
fairly solid use case. OData is a great example. However, I was thinking of
yet another argument I’ve heard for dynamic languages:
when you are just going from web to database and back, you are not really
working with types.
In that spirit, I set out to write a simple Web API using SQL and JSON with
no explicit class definitions. You can see the results in this gist:
I used Dapper to simplify the data
access, though I just as well could have used
Mostly I wanted to use SQL, so I went with Dapper.
I also model bind to a JObject, which I immediately cast to dynamic. I use an anonymous object to supply the values for the parameters in the SQL statements, casting the fields from the dynamic object to satisfy Dapper.
All in all, I kinda like this. Everything is tiny, and I can work directly
with SQL, which doesn’t bother me one bit. I have a single class to manage my
data access and API translation, but the ultimate goal of each method is still
small: retrieve data and present it over HTTP. That violates SRP, but I don’t
mind in this case. The code above is not very testable, but with an API
like this I’d be more inclined to do top level testing anyway.
It’s just not deep enough to require a lot of very specific, low-level testing,
Also, note again that this is just retrieving data and pushing it up through an API. This is not rocket science. An F# type provider over SQL would give a good enough sanity check. Why bother generating a bunch of types?
Which brings up another point for another post: what would I do if I needed to
add some logic to process or transform the data I retrieved?
As a future exercise, I want to see what it would take to cap this with the Web API OData extensions. That could be fun.
I recently ran into a problem with accessing a WCF web service over https.
I used the WSDL Type Provider
to generate the service client for me. I referenced System and System.ServiceModel
like a good boy, yet I couldn’t find any way to set the credentials for the service.
I began by trying to use the generated client: MyService.GetWSHttpBinding_IDataService.
Unfortunately, that didn’t have a the ClientCredentials property I expected. So I then
tried creating a new client:
let endpoint = "WSHttpBinding_Test"
let username = ""
let password = ""
let client = new MyService.DataServiceClient(endpoint)
client.ClientCredentials.Windows.ClientCredential <- new NetworkCredential(username, password)
Unfortunately, the issue persisted. I then noticed a little message noting that I was missing an assembly reference.
Turns out you must also open System.IdentityModel. Problem solved.
NOTE: If anyone knows of an https hosted WCF service in the wild, I’d be happy to share the full code.
I would like to propose an alternative compilation structure for building
F# projects. I’m currently calling it an F# manifest, though the actual
idea is less focused on the creation of a single file and rather on a different,
language-first approach to building projects. My idea stems from a technique
I’ve started using more regularly and that I’ve seen from Tomas Petricek.
This technique uses compiler directives for toggling #r and #load commands
for F# Interactive. Using these, you can typically run a script or compile and
run an executable. The overall process would roughly appear as follows:
Look for a Main.fs or Manifest.fsx file.
If a Manifest.fsx file doesn’t exist, generate the Manifest.fsx from #if INTERACTIVE, #r and #load references
Do this for all referenced files so that the Manifest.fsx lists the dependencies for the primary script
Search for references without a path in the local directory, then the GAC, and finally NuGet
Why an alternate build system?
Today I saw a question about docs for F#x
on the F#x mailing list. The first reply, from Art, referenced Tomas’
I hadn’t seen Tomas’ project in some time, so I went to check it out.
The last I looked at it, FSharp.Formatting provided a Markdown parser.
Tomas has extended it to cover a much larger feature set, including a
version of literate programming. Literate programming was the ultimate goal
of my halted focco project.
As I had always intended of pulling in several of Tomas’ other projects
to finish focco, and FSharp.Formatting now provides many of those features,
I will now be moving what I can from focco over to FSharp.Formatting.
That was what I had originally planned to write about. Instead, worn out
from the holidays, I lost focus and instead started thinking too much
about true literate programming.
(Disclaimer: I have not investigated Tomas’ implementation in any detail, so some of what follows may be inaccurate.)
Knuth’s idea of “literate” programming allow programmers to write for people
and use a tool to strip out the code and re-organize it for the computer.
This sort of thing is more necessary in languages such as F# and Pascal
you must first declare a procedure or function before you can use it.
Neither focco nor FSharp.Formatting currently addresses this.
Before literate programming in F# is really possible, we need a build system
that can work more directly from raw files. Well, that’s not entirely true,
but I’ve long wished to see less XML and more F# in my F# builds.
Is this really a necessity to literate programming in F#?
No, of course not. I just found myself thinking through all this and thought
I would write it down for posterity. If I really thought it necessary, I would
have instead started writing some code to feel this out. Instead, I’m planning to
get some sleep and try to focus and get F# project support added to FSharp.Formatting.
Once that is done, we’ll see about allowing a mechanism to allow authors to
list their code in an arbitrary manner and then reassemble it. And after that,
maybe a look at a new build system is in order.
And no, I haven’t forgotten about FAKE. If nothing else, I would probably make this
an optional extension via FAKE. Then again, you can already do some of this
with a single .fsx script several loose .fs files, and some assemblies.
I just happened to drop over to the ASP.NET Web Stack and noticed that
nested controllers are now allowed in Web API!
This is terrific news for you F# developers who, like me, think that grouping related functionality,
including controllers, within modules is a convenient practice. Note, that this is only in the source.
You won’t be able to update your NuGet packages to get this functionality, though it is easy to replace
the offending DefaultHttpControllerTypeResolver with this updated copy:
For at least the past year, I have repeatedly found my appreciation for the literal offended by the term “RESTful URLs.”
I recently spent a bit of time trying to explain how this term is oxymoronic on the Web API Forums.
While URIs are important as a means of identifying unique resources, REST doesn’t specify any other requirements for URIs.
I often note that a RESTful URI could be a GUID. While this is certainly not very meaningful to humans, it satisfies the
While pondering nested resources in Web API yet again, I realized where I think this term originates.
Ruby on Rails used the term “RESTful routing”
to describe their approach to building Controllers along the line of resources and using a convention to route controllers in a hierarchy based on the controller name.
The goal, I think, was to correctly model and mount resources at unique URIs. However, you get what I would call “pretty URLs” for free.
If you use the term “RESTful URLs,” please stop. While RESTful Routing makes sense, RESTful URLs are just nonsense. Do use “RESTful Routing.” Do use “Pretty URLs.” Just don’t confuse your terms. Thanks!
I finally published the first in a series of short, video tutorials describing web programming in the functional paradigm.
The first video briefly introduces the tools I’ll be using: F# and ASP.NET Web API.
I’ve been using a big of knockout.js of late, and while I don’t mind the ko namespace stuff,
I do wish that this had used RxJS instead. I know Steve tried that early on
and all; it would just be nice to be able to leverage something with which I’m more familiar. Perhaps
Matt Podwysocki or Christopher Bennage will come up
[This is the third in a series
started long ago on the use of MVC for building web “applications”.]
I’m glad I’m only getting back to this series now. I’ve had an opportunity
to build many more web applications and have a much better appreciation
for the poor terminology used to define web applications. For starters, this
MV? business silly. We’ll get to that.
I know I’m a bit of an extremist in some things. Specifically, I like things
to mean what they mean. When we abuse terms, we don’t communicate well. REST.
There, I said it. I feel better. Stop using the term. Most people have a wrong
idea of what it means b/c of all the silliness that has been done in its name.
I don’t claim to know exactly myself. I don’t think it’s possible to rescue
the term from the abuses heaped upon it. There, you see? I’m an extremist.
Now that we’ve covered that, on to MVC. I’m not sure who decided this was an
accurate description for what happens on the server-side of the web, but it’s
just flat wrong. As noted previously, HTTP uses a
It’s an IO-bound Request -> Response function. Can you use patterns on either side
to help maintainability? Certainly! Just don’t confuse things. Let’s start with Views.
What is a view?
The [view or viewport] is responsible for mapping graphics onto a device. A viewport typically has a one to one correspondence with a display surface and knows how to render to it. A viewport attaches to a model and renders its contents to the display surface. In addition, when the model changes, the viewport automatically redraws the affected part of the image to reflect those changes. […] there can be multiple viewports onto the same model and each of these viewports can render the contents of the model to a different display surface.
If a view was merely a serialization of a model, this would make sense for building
web applications. Unfortunately, there’s a problem. The definition suggests that
the view automatically updates whenever the model changes. How do you do that with
HTTP? HTTP doesn’t define any mechanism for hooking up observation of a server model.
People commonly mean HTML. HTML is not a UI. HTML is a serialization format. The
client (normally a browser) must interpret that HTML. Many of you will remember when
that wasn’t so standard.
Can we achieve MVC today? Possibly. You might be able to leverage web sockets to reach
across a client/server architecture such as that presented by HTTP. However, you are more
likely to find that “MVC” on the server is just limiting. You are typically better
off building a sort of restricted data access service, a.k.a
Web API (subtle hint). There’s really no point in trying
to enrich a serialization format to make it work more like true MVC across the
client and server.
This is no different than routing. Instead of calling your Router a Controller, you
split them up. However, most frameworks really just use the router as a top level
dispatcher and the controller as a lower-level dispatcher. Otherwise, I’d say web
frameworks stay a lot closer to the original meaning than a lot of the other MV?
patterns. (Hence the ?, of course.)
This really is the crux. HTML is a model. I noted this last time. It’s just a
serialization of data you want displayed. It happens to be a lot richer, but it’s
still just a data model. HTML is a great way to bootstrap an application that
ask why HTML5 removes the presentation elements. Why has layout and style moved to
CSS? CSS and the browser define the actual rendering. In a no-script web application,
you don’t have to build a view. You get it for free.
So what? Am I just ranting that I don’t like how people abuse terms? Possibly. However,
I think this goes deeper. When you allow the slippery slope, you get caught on it, as well.
It’s inevitable. The bigger, lurking danger is that we start to confuse useful patterns
and use them in the wrong places. Many people use MVC frameworks today to build
web APIs. However, that’s not MVC. So if you then switch to a desktop app to write MVC
applications, you are either confused or delighted to find that it’s so much richer.
I don’t know what I would call what we build for the web; I know I wouldn’t call it MVC.
In my experiments with Frank, I’ve found that writing
simple functions and nesting them with rules makes a very easy mechanism for building
web APIs. I think that would essentially just be a Command pattern. Simple, elegant, and
very easy to understand. YMMV.
If you have been trying out ASP.NET Web API, you will be happy to know that the RC is finally available.
No more struggling with building the sources yourself or fumbling with installing the nightlies to the GAC.
Henrik has posted a fewarticleson thechanges, as well as a follow up to
using the nightlies with the RC release, if you must.
One final note: the assembly names have changed, I assume to allow you to install the MVC4 for VS2010 alongside a VS11 installation, which was previously not possible.