Moving to github pages

Migrated all content to wrschneider.github.io

KnockoutJS implicit subscriber via ko.computed: Elegant, yes. Readable, maybe?

I have seen code that looks like this with KnockoutJS a few times, using a ko.computed as a substitute for ko.subscribe on multiple observables:

this.x = ko.observable();
this.y = ko.observable();
this.updated = ko.observable(false);
this.tracker = ko.computed(function() {
  this.x();
  this.y();
  this.updated(true);
}, this);

The tracker function is equivalent to

var callback = function() {
  this.updated(true);
});

this.x.subscribe(callback, this);
this.y.subscribe(callback, this);

The pattern with ko.computed is compact and elegant. A single function tracks multiple observables, and fires an event when one of the tracked observables changes.

My challenge with this pattern is the readability, though.  A non-expert KnockoutJS user may have a hard time figuring out what's going on because the intent is not obvious from the code.  The pattern is exactly the opposite of basic ko.observable usage.  Simple cases like "fullName = firstName + lastName" use the tracked observables to calculate and return an output, and have no other side effect.  In this case, the tracked observables' values aren't used, there is no output, and there are side effects.

On the other hand, a KO expert who understands how ko.computed tracks observables might find this pattern is more readable than the alternative.

So I'm thinking, it's ok to use this pattern, but with some conventions to help prevent beginners from getting too confused.  Some thoughts:

• Use a naming convention to distinguish this ko.computed pattern from others.  For example, onSomethingChanged or trackSomething.  This way the name sounds like an event listener. 
• Don't mix the ko.computed patterns - either return a value or have a side effect, but not both
• Within the ko.computed body, make a clear separation between setting up observable tracking and the action to fire when something changes.  
• Consider separating the code comments - this is one of those times when code comments are helpful to explain something that might not be obvious from the code itself.

For example:

this.onInputChanged = ko.computed(function() {
  var trackedObservables = [this.x(), this.y()];
  // action when one of trackedObservables changes
  this.updated(true);
}, this);

KO documentation on computeds: http://knockoutjs.com/documentation/computedObservables.html

knockout/pager - possible solution for DOM teardown

Possible solution to DOM leakage issue with PagerJS as I observed previously (Knockout is great, not sure about pager):

Add an afterHide event handler to tear down DOM after you leave for another page.  This handler can wipe the DOM from the template, triggering any cleanup registered with ko.utils.domNodeDisposal (see this post on StackOverflow).

Also, by clearing the reference to the view model within the Page object, the view model may be garbage-collected.   This should work for both lazy and non-lazy bindings: for lazy bindings, only the Page object would have a reference to the view model.  For non-lazy, someone else passed a reference to an existing view model so the view model will hang around.

You could attach this callback globally or within individual page bindings.

var afterHideCallback = function afterHideCallback(event) {
  var elementToDestroy = event.page.element;
                     
  // clear out reference from the node with page binding so it can be garbage collected
  event.page.ctx = {};
                                  
  // shut down and wipe DOM from page to be hidden                     
  $(elementToDestroy).children().each(function destroyChildElement() {
    ko.removeNode(this);
  });
};

// attach this event globally or in individual "page: {afterHide: ...}" bindings
pager.afterHide.add(afterHideCallback);

Time intervals and other ranges should be half-open

It is a good practice to treat time intervals as half-open inequalities: start <= x < end. Note the asymmetry.  This is how the Joda-Time API implements time intervals, and also how the SQL "overlaps" keyword works.  Also note that SQL "between" does not behave the same way.

The main reason this is important is to allow adjacent time intervals like 10:00-11:00 and 11:00-12:00, such that the instant of 11:00:00 falls in the second interval, but not the first.

It is a mistake to try turning the intervals into 10:00-10:59, etc. An instant like 10:59:01 would fall through the cracks between intervals, and end minus start would be 59 minutes rather than an hour.

With date or timestamp ranges, the same logic applies.  But there's a key difference: while end-users tend to think of time ranges intuitively as half-open, they often tend to think of date ranges as closed.  That is, users expect 10:00-11:00 and 11:00-12:00 to be adjacent and non-overlapping even though 11:00 is the end of one range and the start of another.  For dates, though, users tend to think of ranges like Jan 1-Dec 31 inclusive of the last day of the month/year.

So what to do?  There are two workable solutions.  One is to apply the same half-open inequality as before, adding a day to the user-specified end date.  So you would have something like 1/1/2013 <= x < 1/1/2014. Another is to truncate the input under test: 1/1/2013 <= trunc(x) <= 12/31/2013.  This gives the same results, because any instant up to and excluding 1/1/2014 will be included in the range.  The first approach is better because you don't have to remember to strip the time portion off of x before testing.

A wrong answer is to do something like 1/1/2013@midnight <= x <= 12/31/2013@23:59:59.  This assumes you know the exact precision of x, and there's a risk of a moment of time falling through the cracks again.  It's also just icky.

Integer ranges where the input under test is a decimal behave like dates and times, with the same options. Currency is a good example: you can use half-open ranges such that $100-200 and $200-300 are adjacent and non-overlapping and $200.00 falls in only the second range.  You could also have the user specify closed ranges like $100-199 and $200-299 and do the same thing with floor(x) or start <= x <= end + 1.  What you can't do is let $199.01 fall between the two adjacent intervals or let $200.00 match both ranges.

Incidentally, it seems like even when we're dealing with pure integer ranges, the common practice in Java is to use half-open intervals for things like substrings, and Python does the same for array slicing.  This seems to be the best practice for programming in general, for readability and minimizing chance of mistakes (see http://stackoverflow.com/questions/8441749/representing-intervals-or-ranges).

MicroStrategy Web SDK - WTFs

MicroStrategy's Web SDK did something I totally didn't expect: calling WebReportInstance.getPrompts() actually runs the report if the report has no prompts. WTF??

This is a big deal if the report takes a long time to run.  I would expect a method called getPrompts to, you know, get the list of prompts.

After a few rounds with support, I got the answer:

reportSource.setExecutionFlags(EnumDSSXMLExecutionFlags.DssXmlExecutionResolve);

Note that call is on the ReportSource before getting the ReportInstance.

Same goes for Documents.

Speaking of WTF's with MicroStrategy's Web SDK - even though all subclasses of WebResultSetInstance (documents and reports) implement a getMessage() method that returns a subclass of WebMessage, the method is implemented only on the individual subclasses.

In other words, instead of this:

class WebResultSetInstance { public WebMessage getMessage() }

you get this

class WebDocumentInstance { public WebDocumentMessage getMessage() }
class WebReportInstance { public WebReportMessage getMessage() }

This is annoying, because it prevents you from doing something like this

resultSetInstance.getMessage().removeFromInbox()

interchangeably with a report or document.  You need to treat both report and document cases separately.

KnockoutJS is great, not so sure about PagerJS

I've been using KnockoutJS for a while and I like it.  Knockout solves a clear need for me, in that without it or something similar, I'd have a mess of jQuery event handlers that breaks every time my HTML markup changes.  And because Knockout only solves for data binding, it is simple and easy to learn. It was easy to learn after using JSF on the server, with a similar two-way binding model.  I imagine .NET developers would have a similar transition from XAML, WPF, etc.

The one thing I am not as happy with was extending Knockout with PagerJS for client-side routing.  Although it's easy to get started with Pager, it doesn't seem to work well with the use case where only one page is active at a time and each page has its own isolated view model.  Pager does have mechanisms to lazy fetch templates and bind view models when a page becomes active, but the DOM and the view model don't go away when you move to another page.

This might be ok for some use cases like master/detail, or tabbed navigation on a single page.  But it seems like the growing memory footprint will cause problems when the DOM and view models for multiple independent pages are all in scope when they don't need to be.

Ideally there would be some way to dispose view models and DOM whenever we leave one page for another.

Web stacks that support change - but what kind?

I've recently made a transition from using dependency-injection heavy Java frameworks (Spring, Java EE) to full-stack dynamic language frameworks like Grails, Django, Ruby on Rails etc.

With these full-stack frameworks, you need much less code to get something done, between the magic of dynamic languages, and the elimination of dependency injection .  As a result it's easier to iterate rapidly as business requirements change, because there's fewer places to touch and fewer layers of indirection to sort through.

It made me wonder whether dependency injection in Spring and Java EE was intended to address a different kind of flexibility - flexibility to change out pieces of the tech stack.  I feel like this kind of flexibility is still a hangover from EJB 2.x.  The legacy use case was something like this: maybe EJB won't always suck so you put your business logic in a service that gets injected, and you could replace your POJO implementation with an EJB without changing the dependencies.

I feel like the flexibility from dependency injection was overrated - think about how often during the typical lifecycle you make a significant tech stack change, and think about how much time you spend wading through all those extra layers of indirection and configuration to make a functional change.  Also, these days with the proliferation of viable technologies, you are almost as likely to try something totally different (node.js, perhaps?) than to change out your ORM in isolation.

Yes, things are better today with annotations and better dynamic bytecode generation (e.g., no gratuitous interface with single implementation).  Still it feels like dynamic proxies are a clumsy mechanism for providing services like transactions, when compared with frameworks that provide these capabilities through dynamic language features or closures.  Given the choice, I think I'd rather go with a tech stack that makes it simpler and more efficient to address business requirement changes, even if it makes it harder to switch between EclipseLink and Hibernate.