Revisiting Microsoft Forms: InfoPath (and XForms)

In this third part of my series on Microsoft Forms solutions. You can find posts on WebForms here and WinForms here. In this post, I want to look back at InfoPath, and more specifically, the lost opportunity in forgoing the W3C‘s XForms recommendation.

Continue reading

The Real MVC in Web Apps

I 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 reading

Texas UIL Computer Science Competition Should Use JavaScript

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?

Bundling and Minification with Web Essentials

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:

  • We ran into trouble trying to remote debug the F# web project
  • The project had grown to the point that it was quite large, and it made sense to separate the two for maintenance
  • It’s common even in other languages to separate the front-end into a separate folder or project as different teams are often responsible for the different apps, which is not quite our case but close
  • We wanted to clean up our Angular code so that we had less Angular spread throughout and more standard JavaScript; for this we wanted to use bundling again

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?