TL;DR MVC frameworks provide infrastructure to solve make believe problems. They complicate what should be simple.
Update (Feb 4, 2016): While writing this post focused on server-side MVC, I came across a somewhat related post, Why I No Longer Use MVC Frameworks, discussing problems with MVC on the client-side. It follows a slightly different direction and is well worth your time.
Continue readingI recently listened to David Nolen‘s talk from QCon London conference from back in July called Demand Driven Architecture. Before continuing, you should have a listen.
Ready?
I really like a lot of things Mr. Nolen has done and really enjoy most of his talks and posts. I was less enthused with this one. I think my main hang up was his mis-representation of REST and resources. I get the feeling he equates resources with data stores. If you watched the video and then skimmed that Wikipedia page, you will quickly see that the notion of “joining” two resources is nonsensical. I think Mr. Nolen is really referring to that “pragmatic” definition that means POX + HTTP methods, which really would correlate well to data stores.
Continue readingMy consistency with running the Community for F# over the last year or so has been lacking, to say the least. I’ve spread myself too thin working on various open source projects, mostly relating to pushing OWIN. Now that work is (mostly) done, I plan on re-focusing on driving the Community for F# early next year. I’ve already started trying to line up speakers for the first six months. Unfortunately, we’ll miss December and possibly even January, as Google changed their +Pages to My Business and dropped Hangouts support, so far as I can tell. I need to sort that out.
Continue readingI find tragic that we have only the ever-growing monolith of HTML5 on which to build web applications. Sure, it includes some good stuff like canvas and svg, but overall I find it a monstrosity. Whatever happened to XML namespaces? I know, “XML! Run for the hills!” However, the use of namespaces allowed simpler markup formats to be intermixed, and it worked rather well though a bit tedious to write by hand. Ultimately, I think the need to write these things by hand, due to bad tooling, led to the death of XML as a beloved format. Unfortunately, XML namespaces were replaced with a hack the size of Facebook. And the world cheered.
I keep finding a lot of developers who like to model and build web apps using HTTP as a transport for RPC. I don’t understand this but I thought I would do my best to provide a framework for understanding why one might choose to use the HTTP protocol rather than ignoring it and layering RPC on top.
Continue readingI recently stumbled across Peter Michaux‘s article MVC Architecture for JavaScript Applications. I’ve followed Peter’s writing in the past and was surprised I’d missed that and several others you can find on his site, including the more recent Smalltalk MVC Translated to JavaScript. (While you don’t have to go read them now, I recommend you do so.) Peter focuses his attention on JavaScript applications. I’m going to extend this a bit and tie in a bunch of other things I’ve been reading to show that 1) the current trend appears to be heading back in this direction (albeit under different names) and 2) that MVC need not focus entirely on the client side.
Continue readingThe hot topic in JavaScript right now typically involves which SPA framework one should use. These discussions tend to focus on one of the following:
Microsoft.Owin, a.k.a. Katana, provides a number of very useful abstractions for working with OWIN. These types are optional but greatly ease the construction of applications and middleware, especially security middleware. The Katana team did a great job of ensuring their implementations work well with Microsoft.Owin as well as the standard OWIN MidFunc described below. However, not all third-party middleware implementations followed the conventions set forth in the Katana team’s implementations. To be fair, OWIN only standardized the middleware signature earlier this year, and the spec is still a work in progress.
At some point in the last year, I discovered the HttpMessageHandlerAdapter was not, in fact, OWIN compliant. I learned from the Web API team they would not be able to fix the problem without introducing breaking changes, so I came up with an adapter that should work with most implementations based on OwinMiddleware that didn’t expose the OWIN MidFunc.
The solution is rather simple, and the Katana source code provides one of the necessary pieces in its AppFuncTransition class. The adapter wraps the OwinMiddleware-based implementation and exposes the OWIN MidFunc signature. After creating the adapter specifically for HttpMessageHandlerAdapter, I created a generic version I think should work for any OwinMiddleware. (Examples in both C# and F#.)
| using System; | |
| using System.Collections.Generic; | |
| using System.Threading.Tasks; | |
| using AppFunc = Func<IDictionary<string, obj>, Task>; | |
| using MidFunc = Func<AppFunc, AppFunc>; | |
| public class MidFuncType | |
| { | |
| private readonly AppFunc next; | |
| public MidFuncType(AppFunc next) | |
| { | |
| this.next = next; | |
| } | |
| public Task Invoke(IDictionary<string, obj> environment) | |
| { | |
| // invoke the middleware, call `next`, etc. | |
| // return the `Task` | |
| return Task.FromResult<obj>(null) :> Task | |
| } | |
| } |
| open System | |
| open System.Collections.Generic | |
| open System.Threading.Tasks | |
| type AppFunc = Func<IDictionary<string, obj>, Task> | |
| type MidFunc = Func<AppFunc, AppFunc> | |
| type MidFuncType(next: AppFunc) = | |
| // set up the middleware | |
| member this.Invoke(environment: IDictionary<string, obj>) : Task = | |
| // invoke the middleware, call `next`, etc. | |
| // return the `Task` | |
| Task.FromResult<obj>(null) :> Task |
| using System; | |
| using System.Collections.Generic; | |
| using System.Threading.Tasks; | |
| using Microsoft.Owin; | |
| using System.Web.Http.Owin; | |
| using AppFunc = Func<IDictionary<string, obj>, Task> | |
| /// See https://katanaproject.codeplex.com/SourceControl/latest#src/Microsoft.Owin/Infrastructure/AppFuncTransition.cs | |
| internal sealed class AppFuncTransition : OwinMiddleware | |
| : base(null) | |
| { | |
| private readonly AppFunc next; | |
| public AppFuncTransition(next: AppFunc) | |
| { | |
| this.next = next; | |
| } | |
| public Task Invoke(IOwinContext context) | |
| { | |
| // TODO: check for null | |
| return this.next(context.Environment) | |
| } | |
| } | |
| /// Explicit wrapper for HttpMessageHandlerAdapter | |
| public class OwinMessageHandlerMiddleware | |
| { | |
| private readonly OwinMiddleware next; | |
| OwinMessageHandlerMiddleware(AppFunc next, HttpMessageHandlerAdapterOptions /* I think this is the right name */ options) | |
| { | |
| var nextKatana = new AppFuncTransition(next); | |
| this.next = new HttpMessageHandlerAdapter(nextKatana, options); | |
| } | |
| public Task Invoke(IDictionary<string, obj> environment) | |
| { | |
| // TODO: check for null | |
| var context = new OwinContext(environment); | |
| return next(context); | |
| } | |
| } | |
| // This can be made generic: | |
| /// Generic OwinMiddleware adapter | |
| public abstract class OwinMiddlewareAdapter | |
| { | |
| private readonly OwinMiddleware next; | |
| protected OwinMiddlewareAdapter(AppFunc next, Func<OwinMiddleware, OwinMiddleware> factory) | |
| { | |
| var nextKatana = new AppFuncTransition(next); | |
| this.next = factory(nextKatana); | |
| } | |
| public Task Invoke(IDictionary<string, obj> environment) | |
| { | |
| // TODO: check for null | |
| var context = new OwinContext(environment) | |
| return next(context) | |
| } | |
| } | |
| /// HttpMessageHandlerAdapter using the Generic OwinMiddleware adapter | |
| public class OwinMessageHandlerMiddlewareAdapter : OwinMiddlewareAdapter | |
| { | |
| public OwinMessageHandlerMiddlewareAdapter(AppFunc next, HttpMessageHandlerAdapterOptions /* I think this is the right name */ options) | |
| : base(next, m => new HttpMessageHandlerAdapter(m, options)) | |
| { | |
| } | |
| } |
| open System | |
| open System.Collections.Generic | |
| open System.Threading.Tasks | |
| open Microsoft.Owin | |
| open System.Web.Http.Owin | |
| type AppFunc = Func<IDictionary<string, obj>, Task> | |
| /// See https://katanaproject.codeplex.com/SourceControl/latest#src/Microsoft.Owin/Infrastructure/AppFuncTransition.cs | |
| [<Sealed>] | |
| type AppFuncTransition(next: AppFunc) = | |
| inherit OwinMiddleware(null) | |
| default x.Invoke(context: IOwinContext) = | |
| // TODO: check for null | |
| next.Invoke(context.Environment) | |
| /// Explicit wrapper for HttpMessageHandlerAdapter | |
| type OwinMessageHandlerMiddleware(next: AppFunc, options) = | |
| let nextKatana = AppFuncTransition(next) :> OwinMiddleware | |
| let webApiKatana = new HttpMessageHandlerAdapter(nextKatana, options) | |
| member x.Invoke(environment: IDictionary<string, obj>) = | |
| // TODO: check for null | |
| let context = new OwinContext(environment) | |
| webApiKatana.Invoke(context) | |
| // This can be made generic: | |
| /// Generic OwinMiddleware adapter | |
| type OwinMiddlewareAdapter(next: AppFunc, factory: Func<OwinMiddleware, OwinMiddleware>) = | |
| let nextKatana = AppFuncTransition(next) :> OwinMiddleware | |
| let middlewareKatana = factory.Invoke(nextKatana) | |
| member x.Invoke(environment: IDictionary<string, obj>) = | |
| // TODO: check for null | |
| let context = new OwinContext(environment) | |
| middlewareKatana.Invoke(context) | |
| /// HttpMessageHandlerAdapter using the Generic OwinMiddleware adapter | |
| type OwinMessageHandlerMiddlewareAdapter(next: AppFunc, options) = | |
| inherit OwinMiddlewareAdapter(next, (fun m -> new HttpMessageHandlerAdapter(m, options) :> _)) | |
I hope that helps someone else. If there’s interest, I can package this up and place it on NuGet, though it seems a lot of effort for something so small. The source code above is released under the Apache 2 license, in keeping with the use of AppFuncTransition used above from the Katana source.
As a former competitor in Texas’ UIL Computer Science competition, I thought I would check in and see how it had evolved. I have a desire to, at some point, try to spend some volunteer time at a local high school working with Computer Science students, and I thought this might give me a view into what I might expect to find.
I admit I was quite disappointed to find Java the introductory language of choice. This is, after all, the state where Dijkstra presided, in Austin no less. How could Texas have gone so wrong? I knew Texas adopted C++ right after I graduated (from Pascal). I had no idea it had switched to Java.
What’s wrong with Java? Well, let’s start with complexity. Java is supposedly an OOP language. Alan Kay’s message passing and atoms definition of OOP makes sense. It’s the same argument Joe Armstrong uses to describe the Actor model used in Erlang and based on physics. Java, and its kind that includes C++ and C#, follows a very different form I tend to call “Class-Oriented.” Class-oriented programming uses things like inheritance and design patterns to solve problems that are created by using class-oriented programming. An outside observer should be able to see this clearly in the number of books published on the topic, especially when one takes the time to investigate the contents and learn that most contradict others.
For years, Rice and MIT taught their first-year computer science students LISP. They’ve now, sadly, departed from that tradition. However, I strongly believe teaching at such a raw, powerful level would both provide immediate job candidacy and a firmer grip on the actual mechanics of computing, rather than an understanding of OOP, which is much less useful than advertised. Those who understand LISP tend to understand algorithms and abstractions better and have a much closer appreciation for what languages do once they’ve been parsed. Isn’t this what our education system should be encouraging?
Okay, let’s say LISP is out. What about Python? It’s pretty popular and has supplanted LISP in both Rice and MIT (I think). I would actually suggest JavaScript, myself. Sure, it has warts, but 1) it’s the most ubiquitous language in the world, 2) can be written and run in any browser, 3) provides immediate feedback, and 4) would offer every student the possibility of getting a part- or even full-time job during summer months or upon graduation.
If the selection of Java is related to industry use, which I can only suppose is the case, then JavaScript should be the top choice. It has so many interesting facets and can be used to teach most if not all styles of programming. It even has roots in Scheme and Self, one the LISP and the other the OOP.
Please, at least consider it.
P.S. If a dynamic language, or JavaScript specifically, doesn’t satisfy, what about a typed, multi-paradigm language like F# or OCaml?
Pta.Build.WebEssentialsBundleTask A few months ago, the Tachyus web application used a C# + F# web application approach to separate the front-end HTML, CSS, and JavaScript from the back-end F# ASP.NET Web API application. With this configuration, we introduced Web Essentials to bundle and minify our CSS and JavaScript at build time within Visual Studio. To simplify deployments and better group related and shared code, we decided to merge the back-end with another Web API application, which used the F# MVC 5 project template. We originally tried using CORS, which worked great in almost every environment. Unfortunately, the one environment in which we ran into trouble was our staging/production environment. Since we are building an internal-only API, we haven’t spent the extra effort to make our APIs evolvable; therefore, we decided to just merge all three projects together into the F# web project. This worked rather well, except for Web Essentials. We abandoned Web Essentials, as well as any form of bundling or minification at that time.
Fast forward to last week: we again split the front-end application out into a separate, C# project. We did this for several reasons:
I was able to add Web Essentials back into the solution since we were again using a C# project. However, this had its own challenges, specifically in the form of communication to the rest of the team that they would need to install Web Essentials in order for their updates to take effect.
Fortunately, my colleague Anton Tayanovskyy recently found and pointed me toward the WebEssentialsBundleTask, which is a MSBuild task that will run the Web Essentials transformations at runtime depending on the build configuration, i.e. Debug or Release. This tool provides explicit script references for Debug builds and a bundled (and minified, if desired) version for Release builds. It seems to only require the presence of a Web Essentials-style .bundle file to work, so I would expect this to work equally well with a F#-only solution, though I have yet to try that. The WebEssentialsBundleTask has its own issues, though. It will modify your index.html file whenever it runs, so you must make sure to revert changes you don’t want to keep. We rarely change our index.html file since nearly everything is built in the form of Angular directives or templates. Nevertheless, you should consider the cost to your own project.
You may wonder why we didn’t just build a simple FAKE task. After all, whitespace in JavaScript is relatively meaningless, so a very simple concat + remove could probably get the job done, especially since we use ; where applicable. I definitely considered this option, as well as creating new FAKE tasks built around a node.exe using tools like grunt.js or gulp.js. In the end, these all seemed like overkill with the availability of Web Essentials, at least until we had evaluated whether WE would work for our purposes. We are still evaluating. What are you using? Did you find this helpful?
Wizards of Smart 
You must be logged in to post a comment.