Kyle Cordes – Page 6

Angular 2 alpha 38-or-so error finding Subject.js

Here’s a tip for the intrepid out there who are following the Angular 2 alphas. It has been somewhat harrowing, as alpha software tends to be. Here’s a problem I encountered today, and could not find an obvious answer anywhere on the Internet, therefore this post.

Here’s a critical piece of background, I have been using JSPM to manage dependencies in my Angular 2 work. I am using an alpha package manager with an alpha module loader to load an alpha framework and it’s mostly-alpha dependencies. Realistically it is surprising that it sometimes works at all.

I made the mistake(?) of falling behind a couple of weeks in the alphas – rather than updating one at a time I leapt directly from 37 to 40. With a bit of experimentation I found that breakage occurs starting with Alpha 38, and elaborate error failing to load a file Subject.js.

After reading numerous websites, Angular alpha diffs, and so on, it appears that this is related to the transition recently to “RxNext”, the upcoming next version of reactive extensions. The new dependency is visible in the top level package.json, for reasons unknown to me JSPM did not notice this and bring it in. Fortunately all of the sulfa software coordinated enough to fix the problem with a single command:

jspm install npm:@reactivex/rxjs

All of the Alpha stuff, that’s just life in your working with software on the edge. The one piece of this thing that I am a bit unhappy with is the name of the package mentioned above. This is the first NPM package I’ve encountered that begins with or otherwise includes a special character. I didn’t even know that was allowable, and I hope it does not become common practice.

Martin Fowler defines Software Architecture

Yesterday I saw the following video of a brief talk by Martin Fowler, in which he defines software architecture. I have grumbled about that term myself, in that firstly it is often ill-defined, and secondly it can be pretentious. I have sometimes defined software architecture as “high level design”, or as the design of systems complex enough to warrant substantial input from someone who is been around the block many times.

Fowler’s definition is crisp: Software architecture is those decisions which are both important and hard to change. This means it includes things like the choice of programming language, something architects sometimes gloss over or dismiss. Both aspects land squarely on the economics of software development. Said another way, software architecture is those decisions which, if made poorly, will make a project either succeed or fail, in a needlessly expensive way.

This connection resonates deeply with me. I have often talked about the economics of software development, the economic impacts of tool choices, the economic impacts of process selection, platform selection, etc. But Fowler’s talk made a connection I had never set out loud at least: the economic concerns, not only the technical ones, are software architecture.

Record Development Meetings with Hangouts On Air

At Oasis Digital, our project teams coordinate in numerous ways, sometimes by meeting “live”. At these meetings we discuss, we plan, we model, we code, we review. For teams/projects where everyone is physically present at headquarters, this is readily done by plugging in to a large TV re-purposed as a computer monitor. (Proposed bumper sticker: “My other monitor is a 60 inch Samsung”.)

For some teams and projects, though, not everyone is at our St. Louis office. Some of our developers are around the US, and occasionally projects include developers around the world. Therefore, some of our development meetings take place online, using a variety of meeting tools. Mostly these meetings are useful only at the moment they occur, but it is useful to record them for developers who are unable to attend “live”.

There are countless tools to choose from. We have had particularly good results with Google Hangouts. Unfortunately normal Hangouts has no recording feature – the recording capability is available only in the form of “Hangsout On Air”, which is more typically used to “broadcast” an online meeting. Google Apps customers, though, can use Hangouts on Air, decline to broadcast to anyone at all, then share the recording privately.

The process is not obvious. Here is how to use Hangouts On Air to privately record and share online meetings:

Consider performing all of these steps in a dedicated browser. For example, use Chrome for Hangouts, while using Firefox for other browsing. This reduces the opportunity for Hangouts (which is irritatingly bound to the browser) to interfere with other use of your computer.
Log in to YouTube. Use the Google account selector in the upper right to select your company Google Apps account, if you are logged in an more than one account.
If you don’t already have a YouTube “Channel”, which you probably don’t, click to create one. It is harmless, since for this Hangouts On Air purpose you don’t need to every actually publish anything to your “channel”.
Click “Video Manager”. The button for this is not in the most obvious place (the left navigation), rather it is along the top, and small.
Click Live Events.
Click to create a new live event.
Give your meeting event a name.
The description, keywords, etc. do not matter, since you won’t be publishing.
Adjust the setting to make it Private. This is a vital step, don’t miss it.
Don’t share it with anyone yet. That comes later.
Choose the default Quick settings, there is nothing important to adjust in the Custom settings.
Click to start the Hangout On Air. This will launch the same Hangouts app as any other Hangout – almost. As of December 2014, the features for Hangouts on Air are somewhat behind the normals Hangouts app in features and screen layout.
Click the invitation/add button in the Hangouts controls at the top of the Hangouts window.
Copy the link. Paste it in group chat so that other developers (meeting attendees) can join.
Wait for everyone to get in the meeting. Adjust microphones, webcams, speakere, etc.
Remind everyone to turn on their webcam and keep it on if possible. This provides a much better experience for anyone watching the video later – they get more of a sense of having “been there” for the meeting.
Discuss anything that isn’t part of the project in question, etc. while waiting for everyone to be ready.
Click Start Broadcast. This will start the “broadcast” to noone (because this HoA is private and not shared with anyone), and more importantly, start the recording.
During the meeting, remember that whatever is visible in the Hangouts app window, will be recorded. Adjust this regularly to keep it relevant to the discussion. Often the default behavior of switching to whoever is speaking, works well.
Remember that Hangouts On Air recordings are limited to pseudo-high-def, “720p”. Keep screen share window sizes moderate, so that text can be easily read by others in the meeting and on the recording. Sharing a full-screen at 1920×1080 or higher resolution will yield unreadable results.
When the meeting is done, Click Stop Broadcast.
Back in the Youtube Video manager, paste in the email addresses of those with whom the recording should be shared.
Don’t trust Google/YouTube to maintain privacy settings over the long term – leave the recording there until it has outlived its usefulness (a week or so in a typical project, maybe longer in a slow-paced project) then delete it.

Ouch, a 22-step process. That is the price of using Hangouts On Air in for an atypical purpose. The payoffs:

HoA works well across all major platforms, including Windows, Mac, Linux, Android, Chromebook, and more. This is the hardest thing to replace, many other meeting tools don’t come close.
The recording is immediately available privately on YouTube, all transcoding and hosting is seamless and effortless.
Google / YouTube is infinitely scalable, for all practical purposes.
No cost, for either the tools or the hosting.
Part of software (Chrome) that most developers have already installed.

More CSS in JavaScript, this time with React

In September I mentioned a talk at Strange Loop 2014 where the speaker described a technique for writing CSS in the form of JavaScript which then executes to produce the actual CSS. This avoids a server-side build process, it knows more about the browser while operating, it avoids a HTTP round-trip, and has various other advantages. However, the tooling the speaker was talking about was closed source inside of the conference speaker’s product.

Today I encountered a presentation online by a React expert at Facebook, who uses React’s mapping from JavaScript to HTML+CSS, to accomplish many of the same things and more – using tools openly available.

If anyone knows of a audio or video recording of the talk, I would appreciate a link very much.

My own experiments with programmatic CSS also react, but behind ClojureScript, so I’m writing Clojure code which turns into CSS. It is not as mature as what is described in the slides above, but it adds yet another layer of abstraction in the form of a higher-level language.

Rubber Duck Debugging ++

You may have heard of “rubber duck debugging“. Here is my superior debugging partner.

rubber-duck-debugging

Task Based User Interfaces

Here at Oasis Digital, the bulk of our work is on complex business data systems. These projects sometimes involve a so-called task-based user interface. Briefly, this is an interface where the operations available to the user are presented in terms of the problem domain, rather than in terms of editing data. Other names for this idea include “task-focused user interface” and “inductive user interface”.

Origins

I was unable to determine the specific research/practice origins of task-based UI, but it is most commonly seen as arriving from three main directions. First, the inductive user interface guidelines published by Microsoft around 2001 lay out a detailed description and motivation. Second, the domain driven design (DDD) and command query responsibility separation (CQRS) communities often described task-based UI as suitable for use in front of the system built with those principles. Third, simply looking at mass-market software there are numerous examples.

CRUD

Task-based UI is the opposite of CRUD UI, a convenient foil. Many software systems have numerous features which are readily described as CRUD: create, read, update, delete. Some developers describe their work as primarily creating CRUD systems, with either pride or disdain. When analyzing a proposed feature or proposed software project, we sometimes evaluate the extent to which the project is “just CRUD” versus behavioral functionality. Brought to the user interface, CRUD typically means screen after screen in which users can make an entity of some kind, find an existing one, update one, or remove one. In other words, a minimal veneer over basic database operations.

Simple CRUD user interfaces have the advantage that they are generally easy to create, and amenable to common tooling. Many development environments offer wizards or libraries to ease such creation, and this dates back to at least early 1990s, and probably much farther than that.

Therefore, CRUD has a lot of appeal when first creating a new application. Unfortunately, a system built primarily around CRUD tends to make behavior beyond minor validation unduly difficult to implement. If you find yourself squeezing business logic into an “on change” or “on click” event handler somewhere, you are probably experiencing this difficulty. As systems grow in complexity this bad fit can consume vast amounts of time and money.

There is a way out, and that is a task-based user interface, one which presents the user with options and actions which fit the problem domain of the software, rather than those which appear to manipulate data in trivial ways.

Change of Address Example

A common example to explain task-based UI is a change of address operation in a system which has subscribers, members, or some other class of people to whom things might be mailed etc. The CRUD approach to change of address is simple: the user searches for the appropriate user record, views that record, moves the cursor to the address fields, types over those values, and clicks “save”. Very convenient, very easy to program.

Unfortunately, down the line if there is nontrivial behavior in the system, it can be extremely difficult to determine what such an edit means. Was the address corrected because it had been mis-entered in the past? Was the ZIP Code changed because the post office changed the ZIP code assigned to that physical location? Or does this edit represent the person moving to a different place of residence? If the latter, how might that affect them in terms of the problem domain?

To avoid this, a task-based user interface would not only present address fields which can be edited. Rather, the user would see information about a person (including their address) then have options (buttons or whatever else is suitable in the visual UI guidelines at hand) with names like “correct mis-entered address”, “subscriber moved to another residence”, etc. Such explicit actions make it possible to capture the underlying domain-level meaning, rather than just edits to data fields. A downstream system receiving this information could then respond appropriately.

Choose Your Words Wisely

Task-based user interface is therefore to a considerable extent about words: the words which describe actions the user can take. If a system merely uses a task-based user interface on top of a CRUD-centric back-end implementation, then the words can at least be chosen well in the user interface. If the system uses a domain driven approach internally, then some of the well-chosen words in the user interface may become part of the ubiquitous language used throughout the implementation.

I encourage developers to consider a task-based approach even if the underlying system is not particularly domain driven.

Add, Edit, Delete, +, –

Speaking of words, having built numerous user interfaces, I very often still “default” to wire framing with button labels like “add” and “delete”. Such things are fine for an early initial wireframe, but task-based design principles suggest reconsidering whether a more specific set of operations is suitable.

An example came up at work today with a list of employees, and the initial proposal was a “delete” button next to each one. But one does not merely delete an employee: at even the most heartless of companies there will be quite a lot more process involved in removing an employee from a list of employees. A system which manages the employees then, should probably have some sort of process flow around that removal, and it should use words other than “delete”.

A Final Quip

If the user wanted Excel, they would use Excel. If they are using an application which is instead specific to a problem domain, then it should have features, both internally and at the user interface level, relevant to that problem domain.