Thursday, September 11, 2014

dietzler's law

There are a lot of UI-centric build systems out there. As an old-skool web guy, some of them seem like overkill; but then again, I'm skeptical about the need to load content from a CDN, compressed, and bungled into one giant file, about whether that pulls its weight when you're in an agile mode. (As a final step, it becomes less onerous, and has more potential for being useful, but if you do it rarely than the automation isn't as crucial.)

I google for "Maven vs Rake" (Rake being "Ruby Make") and found this article, Why Everyone (Eventually) Hates (or Leaves) Maven. It cited a "law" -- technically about Access, but applicable to Maven as well as framework selection in general, that rings very true to me:
Dietzler’s Law for Access: Every Access project will eventually fail because, while 80% of what the user wants is fast and easy to create, and the next 10% is possible with difficulty, ultimately the last 10% is impossible because you can’t get far enough underneath the built-in abstractions, and users always want 100% of what they want.
The article cites a brilliant example of "composable systems", how systems that contain of simple, "do one thing, do it well" subsystems chained together are better than monolithic constructs: More Shell Less Egg is where 6 piped together unix commands trumped 10+ pages of beautiful Knuth Pascal for a simple word frequency task.

I think Javascript in particular lends itself to "composition over inheritance"; yes, there is a prototype system that can make it object-oriented-ish, but really, I don't think it's the language's most natural paradigm. By making function definitions as easy to assign as an integer, you can really make composable systems work well - and the simple elegance of JSON acts as a pretty decent glue language, just like plain, line and tab delimited text via pipes did for Unix. And as an extension of that, I prefer libraries with take-what-you-need functionality over big monolithic "this is how we do this" frameworks.

Friday, September 5, 2014


I don't understand this enough to do much with it, but , where you can make sounds and tracks via math in real time, in the browser, is amazing.

Friday, August 29, 2014

frameworks are waterfall-ish

Geek time! Thinking about how I so strongly prefer libraries, where you call the code, to frameworks, where their code calls you. (More or less.)

Looking at the trouble I've had lately with frameworks, it seems like there's always some mismatch between the end result we're trying to produce, and what the framework does naturally - and the hacks to get from point A to B are UGLY. To that extent, I realize frameworks are inherently "Waterfall"-ish, because you have to have a good idea what you're coding from the very outset. Libraries tend to be more swappable, and you're less beholden to the clever Frameworks makers having pre-guessed your requirements.

Don't get me wrong; Agile always gets messy. But I think the messiness that results from keeping things simple is easier to cope with than the messiness of hacking around something complex.

coping skills: monitoring DOM changes

Debugging other people's code is tough, especially when there's heavy use of frameworks.

In this case some other code was changing the contents of a DataTable cell, and I didn't know how to track down what code was making the change.

Turns out Chrome and Firefox have pretty good facilities for adding breakpoints based on DOM changes! In Chrome's Elements tab, right click on an element, and there is a convenient "Break on..." menu, with a few convenient options for the type of change you're worried about.

I've worked with so many primitive environments that I'm sometimes a bit more adept with log-based / println style debugging, but my debugger mojo has grown reasonably strong as of late. (The nice thing about log-based debugging is it really forces you to think about the assumptions you're making, and you're less likely to get swamped by a flood of information.)

More Information at Stackoverflow (as usual).

Tuesday, August 26, 2014

wheel library

Gábor Berkesi sent me an interactive version of the hooptime information disply I posted the other day. It uses his wheelnavjs library, working to make it easier to make little dial and circle based navigation widgets -- good use of SVG!

Monday, August 18, 2014

piece on frameworks

I don't agree with all of it, but this Opinionated Rundown of JS Frameworks echoes many of my concerns about some of the popular systems out there, especially Angular.

Also, Why Libraries are better than Frameworks -- I guess a lot of what I think has been argued under the terms libraries vs frameworks, sometimes described as "if I call the code from my code, it's a library, if their code calls my code, it's a framework". I really think libraries lead to much easier to debug things!

Friday, August 15, 2014

the ux of time, the ui of p5.js!

Over the past few years I've realized that I use an idiosyncratic visualization for certain kinds of time; I see the cyclic nature of the twelve months of a year and the seven days of a week in the form of a circle, both going counter-clockwise. I spent some time today generating images reflecting this view. Here's a reflection of what a week is like for me:
I guess the specific rotation and counter-clockwise direction reflects a dash of synesthesia, and also how important physical layout is to my sense of recall -- if I'm trying to do a week-based day calculation, I'll often use my hand to as an arrow to mark my place in the week, in the same way I'll still unconsciously shape an "L" with my left hand to recall which direction is which. 

I'm less certain why I place the weekend down. My best guess is see that as the start and stop of a week, and is either "heavier" or "where the week meets the road" (to stretch the physical metaphor, since I view myself as moving in the fixed week-wheel rather than it moving to accommodate me.) The counter-clockwise motion then springs from that - I read left-to-right, so the Saturday-Sunday "start" to the week is in that "forward" direction, and thus drives the rest of the loop. 

Years are even more strongly laid out in my mind's eye: 

Here the calendar starts at the top, as one might expect, but I think that's because I view a year as progressing from school year to school year, with the loveliness of summer vacation anchoring as the base (though a separate desire to have the numeric transition be straight up tilts the thing a bit.) 

Neither visual is strongly color-coded for me, but week vs weekend and the various seasons have a different ephemeral feel, here color-coded for grins. 

As a side note, I used a new technology for this, p5.js -- the same processing.js I've used for years, but now as pure javascript, rather than going through some weird java-to-js convertor. Highly recommended! You can check out the working page and source code if so inclined.

(Incidentally, I looked into doing this with CSS trickery, but man, the CSS shapes page uses such crazy, inflexible hacks... relying on how if the div is tiny and the border is REALLY wide, then one side of the border looks like a triangle, and messing with border radius makes circles, and then you can get :before and :after going for extra stuff... bleh, it's a mess that breaks quickly when you try to adjust it.)