May 2014

« April 2014 | Main Index | Archives | June 2014 »

22
May

Sorry, this blog entry is all images. I fail at accessibility. If it's any consolation, you've only missed a lame Star Wars joke.

(Transcript of IM conversation)

Charles: We need this!

Donna: No.

Charles: Awwww…

Donna: It's fugly.

Charles: Yes, but… but…

Donna: You can put it in your study?

Charles: I don't have room. It would have to go in the living room.

Charles: IT WAS HIS FAULT FOR NOT PAYING ON TIME.

Laura Hudson, writing in Wired:

Ultimately, online abuse isn’t a technological problem; it’s a social problem that just happens to be powered by technology. The best solutions are going to be those that not only defuse the Internet’s power to amplify abuse but also encourage crucial shifts in social norms, placing bad behavior beyond the pale. When people speak up about online harassment, one of the most common responses is “Well, what did you expect from the Internet?” If we truly want to change our online spaces, the answer from all of us has got to be: more.

I haven't seen the F8 session or used Flux. I've just vaguely skimmed some of the reddit comments. However…

Once upon a time, there was this thing called the Model View Controller architecture. It was a product of the Smalltalk community, but then so were Design Patterns and Extreme Programming. At its heart, it was the simple idea that Model classes should be responsible for representing the state of your application, View classes should be responsible for drawing your user interfaces and presenting that state to your users, and Controller classes should be for translating actions performed by your user into changes to your model, that were then reflected in your view.

In a typical screen for an MVC GUI you might have any number of widgets, each drawn by their own independent view objects, backed by different models, connected to multiple controllers. Almost forty years after the MVC pattern was formulated for GUI development it is still out there, albeit in obscure rarely-used frameworks like Cocoa Touch.

Then, twenty years after MVC was introduced to the Smalltalk world, along came the Model 2 Web Application. In an attempt to make Java web development fit into the growing J2EE spec, the Java community seized on MVC and mapped it almost arbitrarily to the web. Every HTTP request would be served by a single controller (servlet), which would collaborate with zero-to-many models (EJBs), and map the resulting data into a DTO (Pay no attention to the man behind the curtain!) that could be passed via RequestDispatcher to a single JSP view.

The sleight-of-hand was the assumption—baked into the servlet spec—that each HTTP request would map to a single controller which would delegate to a single view. A few frameworks like Tapestry tried to buck the trend, but a Java developer years later could literally replace servlets with actions, EJBs with dependency-injected beans and JSPs with the templating language du jour, and still deliver a not-unreasonable technology choice in most circles. This malaise even infected other undeserving languages like Ruby.

The problem is that even in a very simple web application, a single page contains elements that by rights should be the responsibility of different views, backed by different controllers and their own models. The single controller-per-request, or even the primary controller-per-request is a broken paradigm, and one that every developer has come up with some sub-optimal tower of contraptions to compensate for.

As a result, your average non-trivial Java web application ended up being a mess of controller implementation inheritence, servlet filters, interceptor stacks, view decorators and arbitrary objects placed in the template engine's context to allow the drawing of all the bits of the web page that don't belong to the increasingly impure controller.

Amusingly, the "Type 2" approach to web MVC isn't a bad fit for REST-based systems, (because a REST resource usually does have a single responsibility), but most pure REST systems figure it's overkill… because a REST resource just has a single responsibility.

A simple inversion fixes so much. Going back to the GUI paradigm and flipping the process around so the view comes first and then delegates to controllers and models as necessary is already the go-to strategy for single-page applications and frameworks like Backbone. This kind of "view first" is also a perfectly good strategy for server-side page generation, one that large distributed systems have been taking advantage of for years to delegate fragments of page generation to independent external services.

This blog post was brought to you by the Society for Sending Charles Back In Time Fourteen Years To Slap Himself.

mVOSg.gif

Help! Stuck in Turbolift!
Reporter: Williams, D. Lieutenant
Priority: Critical
Version: NCC-1701

Description:

The Turbolift is not moving, no matter how many times I state my destination to the computer.

Comment from Bandt, G. Ensign

I am reducing the priority of this issue from Critical to High. While we appreciate the urgency of your situation, Critical priority is reserved for issues that may impact the integrity or spaceworthiness of the vessel.

Old Enterprise versions do not have a reliable voice control in the Turbolift. Have you tried twisting the cylindrical handle clockwise or anticlockwise?

Comment from Williams, D. Lieutenant

I rotated the handle anticlockwise and I am now in Engineering. Please close the issue, I will find someone here to show me how to get to the Bridge.

mVOSg.gif

From: Cordova, M. Lieutenant Commander
To: enterprise-support@starfleet.gov
Subject: Auxiliary Power

It has come to my attention that many support engineers are reducing their “time to first response” by, on receiving a new case, immediately bouncing it back to the customer with the comment: “Have you tried diverting auxiliary power to the affected system?”

While diverting auxiliary power is often a good short-term fix, suggesting it in every case will only reduce the confidence our customers have in our service, and increase the perception that we are just making guesses instead of taking the time to understand the issue and provide informed advice.

As Starfleet officers, we should take pride in the service we provide, and not resort to cheap shortcuts to artificially boost our metrics.

LtC. Michelle Cordova
Team Lead, Enterprise Support

mVOSg.gif

Starship adrift! Please Escalate!
Reporter: Picard, J-L. Captain
Priority: Blocker
Version: NCC-1701-D

Description:

It has been seven days since I opened my previous ticket re: having completely lost control of my Starship. The Enterprise is currently adrift in space, main power is dead as are the warp and impulse engines. We are locked out of the computer and all diagnostics and overrides have so far been fruitless.

Despite this dire situation we have found ourselves being bounced back and forth by a junior engineer who does not seem to appreciate the gravity of the situation, or even be able to provide us with an idea of how much longer our situation will have gravity!

We have approximately four days of auxiliary power remaining (Thank you for that suggestion, it would SO OBVIOUSLY have not been the very first thing we tried ourselves!) and would appreciate the attention of a more senior engineer before then.

Comment from Garvin T. Snr Ensign

Hi, I was assigned to help you with your case. I have reviewed the previous tickets and will be working personally with you going forward until we have found a solution.

Have you checked Jeffries Tube 194a? The problem you are experiencing could be caused by a crystalline intelligence having taken refuge in your substructure, using that location as a beach-head to control the core engineering functions of your starship.

As a higher form of life you may not wish to kill it, but short bursts of gamma radiation triggered manually from the deflector dish can make it uncomfortable enough to leave on its own.

Comment from Picard, J-L. Captain

That was exactly right! How did you know? Please close the issue.

Comment from Garvin T. Snr Ensign

It happens more often than you think.

Comment from System

Thank you for contacting Enterprise Support. Now your case is closed, we would appreciate if you took a moment to fill out the following survey:

On a scale of 1 to 10 where 1 is “never” and 10 is “always”, how likely would you be to recommend Enterprise Support to a friend or colleague?

mVOSg.gif

From: Cordova, M. Lieutenant Commander
To: enterprise-support@starfleet.gov
Subject: First and last warning.

Everything in my previous email referring to diverting auxiliary power _also_ applies to reversing the polarity.

LtC. Michelle Cordova
Team Lead, Enterprise Support

Ideas shamelessly stolen from Chris and Conor. Also, Atlassian is hiring an Enterprise Senior Support Engineer, but I can’t guarantee you’d end up fixing warp core breaches if you applied.