A bottle of DB reliever

I don’t know about you, but trying to decide what technologies to use is beginning to feel like trying to choose a pain reliever: countless choices and a ton of small print. But when you think about it, it’s actually worse. Unlike pain reliever brands that tend to stick around year after year, many technologies don’t.

So in a new world liberated from the tyranny of expensive database technologies but buried in choices that will live or die depending on where the tech fashion winds blow, which do you choose?

I found this site particularly helpful for getting the big picture because it not only provides a survey of what’s out there but categorizes and ranks them based on popularity. This way I can survey the different categories of database engines, learn more about the players, and see how they’re popularity is trending.

Then I only have to dig into the small print on a few bottles before heading over to toothpaste...

Posting files with AngularJS

While AngularJS's built-in $http service posts data as JSON by default, what do you do if you need to include an image or other binary data file in the post?

Seems pretty straightforward. Just bind HTML <input type="file"> to a controller variable via ng-model and $http.post() a FormData object containing the file object as data with Content-Type set to multipart/form-data. Right?

Not so fast. It turns out that 

•  <input type="file"> doesn't work with ng-model, and 
• Setting Content-Type to multipart/form-data resulted in rejected posts (a bug?).

Thankfully Angular is thoughtfully extensible. The first issue can be resolved with a custom Angular directive that tells $compile to hook <input type="file"> change events and set a controller scope variable with the selected file object when fired as so:

 .directive('inputfileModel', ['$parse', function ($parse) {  
   return {  
     link: function(scope, element, attrs) {  
       var model = $parse(attrs.inputfileModel);  
       var modelAssigner = model.assign;  
       element.bind('change', function(){  
         scope.$apply(function(){  
           modelAssigner(scope, element[0].files[0]);  
         });  
       });  
     }  
   };  
 }]);  

This directive is then set on the element as a custom element attribute:

  <input type="file" inputfile-model="fileVar">  

The second issue is a little trickier to work around. After doing some digging, it turns out that setting Content-Type to undefined results in browsers both setting  Content-Type to multipart/form-data and filling in the correct boundaries. O-Kay, not sure why that is, but hey, it works. Note that $http.post()'s default behavior of transforming data to JSON also needs to be turned off, which can be done by setting it to Angular identity function if you're into functional style programming.

 .factory('Messages', ['$http', function ($http) {  
      return {  
           put: function(url, file, dataObj, success, error) {  
                var fd = new FormData();  
                fd.append('json', JSON.stringify(dataObj));  
                fd.append('file', file);  
                $http.post(url, fd, {  
                     transformRequest: angular.identity,  
                     headers: {'Content-Type': undefined}  
                })  
                .success(success)  
                .error(error);  
           }  
      }  
 }]);  

A few problems initially, but it wasn't too hard to modify and using frameworks like Angular to add some structure to JavaScript in all its expressive glory can only help ease the pain of the poor dude down the road who will have to maintain it.

Get the Gist: UML

So you have a picture in your head. You can see it. From a variety of angles. What it looks like laying flat, how it stands, how it will work when it becomes real.

Of course, things we build start out as pictures in our minds and in many cases just sketching out some lines and words is enough to work out the dimensions, the layout, how it will look. Enough to show someone else what it will look like.

Software can get pretty complex, though. Will the developer across the world understand what your squiggle means? Will the guy who has to maintain the software three years from now? Luckily, engineers and others have studied how humans model things and the techniques they developed can be useful for both thinking through ideas thoroughly and communicating them in an unambiguous way to others.  Universal Modelling Language is such a technique, a standard way to model and communicate software ideas.

UML defines standard ways of diagramming, which is probably its most used -- and useful -- contribution. The problem is there seems to be a pretty wide gulf between a simple napkin sketch and UML and it's 13 (!) types of diagrams (and thick instructional books).

It doesn't have to be that way, though. In my opinion the most useful aspects of UML boil down to some fairly simple bare essentials readily gleaned from examples which I attempt to provide in the following presentation.

It's true that refactoring is all the rage with the programming fashionistas. But really, is it ever advantageous to not take a little time to think things through? With a few basics UML can be a pretty useful napkin.

Get the Gist: Universal Modelling Language (UML) from russellgmorley

Communication reliability

One of the most important things to consider when designing communication between two systems in an enterprise is reliability: Does the sender need to know if messages were delivered to the receiver? If an error occurs on the receiver, does the sender need to know? Does the sender need to know what type of error occurred?  Do messages need to be received in the order they were sent? What about receivers that may go offline or networks that go down? Does communication need to participate in a transaction so state consistency is maintained across multiple systems?

Before designing interfaces and selecting network protocols, it's necessary to understand the reliability requirements of the communication and how requirements align with the capabilities of protocol standards and industry techniques. Because the matrix of communications protocol capability and techniques as related to reliability is rather complex, it's useful to categorize communication reliability requirements based the following:

1. Unordered: Unordered is useful for providing information to one or more interested receivers quickly. Communication is one way and does not block. Receivers cannot return information back to the sender and senders don't know if communication with receivers was successful.
2. Receive-reply: For communication to a single receiver, Receive-reply requires a sender wait for a reply or timeout. Both information and errors can be returned in the reply and senders know if communication was successful. 
3. Ordered: Provides ordered communication with one or more receivers. Information cannot be returned from receivers to senders but errors can. When configured to return errors, Ordered communication blocks but otherwise can be configured to be non-blocking.
4. Guaranteed: A form of Ordered communication, Guaranteed cannot return information or errors but guarantees delivery even if the receiver isn't running when sent.
5. Transactional: Either configured as Receive-reply or Ordered, Transactional can return information to the sender if configured as Receive-reply, can always return errors, and can further participate in a transaction as a durable resource.

In communication design, reliability requirements informs everything from the design of the interface operations to protocol selection and is a crucial part of creating a robust enterprise system. Capturing reliability requirements in the form of a few simple categories is a practical way to express business needs in terms real-world protocols and industry techniques can address.

The usefulness of adapters: a pictorial

Get the Gist: C++/CLI (or how to do native and managed code at the same time)

Get the Gist: C++/CLI from russellgmorley

C# for C++ Programmers

C++ isn't known as being the easiest programming language, so if you have it under your belt "getting" C# shouldn't be a problem. Here's a hint: if you know anything about Java think "Microsoft's Java".

Anyway, here's an overview to get you started:

C# for C++ Programmers from russellgmorley