Friday, October 17, 2014

growing up

I am accepting that (most?) interesting jobs are using frameworks.

I still think that framework use can bring on 80/20 rule Dietzler's Law hells, and almost by definition makes debugging tougher (since what you're looking at in the browser is more and more removed from the code you as a developer actually wrote - a coder is forced to the techniques of holism without the fallback of reductionism) but there are some pluses, and a lot of smart people really embrace these advantages.

But I mean it's so humbling, going from knowing near-everything relevant (DOM and CSS and Javascript) to knowing near-nothing (trusting the framework to do the right stuff but having it provide whole new worlds to learn) and I need to muscle through.



Even though Plain Old JQuery (along with some clunky Server Side Include for rough reusable modules) proved its value for a rich and complex application at Alleyoop, I have to accept that not everyone believes this is a sustainable, scalable pattern - and also I might not have really rich experience with "one page applications", we got much better mileage when we switched to logical functional breaks tied into various html pages.

I have to remind myself of the learning curve I had to master, to get talented at bending jQuery and CSS to my will.  Sometimes I think the big frameworks fanbase has a lot of folks who actually don't dig HTML5/JS/CSS basics as much, so they don't mind the gap between browser and written code. But this is an unfair assumption.

Meanwhile:
What's Wrong With Angular, a retort Defending Angular, and then the original author assembled a piecemeal list of Angular.js alternatives; getting the functionality that people long for "À la Carte", not buying whole houses when you just want the hightech kitchen.


Tuesday, October 7, 2014

angularjs mistakes

The Top 10 Mistakes AngularJS Developers Make. At work, we agree that Batarang looks pretty awesome, and maybe the author is a bit too harsh on jQuery.

Sunday, September 28, 2014

the processing/processing.js gap

Trying to learn about making some prettier graphs I decided to resurrect an old "drag the anchor and control points of bezier curve" toy I made a while back.

You can play with the toy here. I had a harsh lesson making the web/processing.js version once the processing (Java) version was working fine: I had overloaded the processing functions line() and bezier() to take a new Point class, but in the Javascript translation, that had overshadowed the native functions full stop -- without Java's object typing, it couldn't tell which version I wanted to call.

The fix was simply renaming the functions to something that didn't collide with the built-in functions. I often say processing.js is a "good 90-95% solution" for translating Java to js, but that remaining 5-10% is pretty confusing to debug!

Saturday, September 27, 2014

p5.js boilerplate

I haven't checked but I'm pretty certain that the most used Google search for this site is "site:kirkdev.blogspot.com boilerplate". Which is what I use when I want to find my basic html5 template in a hurry.

Similarly, while I've messed messed around in p5.js before, leveraging my years of Processing mojo in a more purely javascript-y way, I don't have the usual "ceremonial" stuff down pat, and so to reduce the friction of starting a new project, I gift my future self with the following:

<!doctype html>
<html>
<head>
<meta charset="utf-8">
<title>p5.js boilerplate</title>
<script src="p5.js"></script>
<style>
    #appCanvas {
        width:500px;
        height:500px;
        border: solid 1px black;
    }
</style>

<script>
var app = function(p) {
    p.setup = function() {
        p.createCanvas(500, 500);
  };
    p.draw = function(){
        p.stroke(p.random(255),128);
        p.line(p.random(500),p.random(500),p.mouseX,p.mouseY);
    }
}

var myApp = new p5(app,'appCanvas');
</script>
</head>
<body>
<div id="appCanvas"></div>
</body>
</html>

It contains some arbitrary bits that I find useful (I like to work at 500x500 because of my blog, for instance) but is pretty minimal, easy to reset once copy and pasted. And I added just a touch of fun to the draw() routine, so I can see it working. (You can see it in action on my website, where I have a random copy of p5.js)

I love the idea of p5, though I admit having to remember to prefix every command with "p." (or whatever variable I've assigned) is annoying.

In other dev blogging... on FB I posted this:
I really feel like a better person, empowered and creative and capable, when I take time to sit and hack in an environment I'm fluent in, especially sitting in front of a big monitor rather than just grabbing time on the subway. Between a techie conference, helping friends in need, a band gig, and various social fun stuff, I haven't had a solid morning or afternoon for that for weeks.
I wonder if this feeling is anything like what people who get nurtured by being out in nature feel when they go camping. I mean, different, obviously, but deeply resonate and restorative nonetheless.

Oh. The other thing: I just realized that for YEARS a gmail filter I set up has been shunting all mail notifications of comments added here away and out of my inbox. I was getting too much material from the "OpenOffice.org" list, so I created a filter for "[dev]'. Turns out that filter wasn't as literal as I had assumed, so something like "[Kirk's UI Dev Blog]", or anything with the word "dev" in it, was shoved away as well. Ah, technology.

Wednesday, September 24, 2014

upcoming browser coolness - destructuring and web components

This past weekend my employer was kind of enough to foot the bill (and I was kind enough to sacrifice a weekend) for the No Fluff Just Stuff conference, 2 1/2 days of lectures on various topics. The emphasis is a bit more Java and fullstack than I try to be these days, but there was still a track for the front end, especially Angular.js and other js toolkits.

Two of my favorite takeaways were technologies that are not quite ready for prime time (Or to quote William Gibson: "The future is already here — it's just not very evenly distributed.") One is a tidbit from ECMAScript Next, the flavor of Javascript that should be running in your browser in a year or two.

10 years ago, I was blogging about a weird asymmetry in Java and most other C-derived languages (I know C didn't originate all of these things, but it certainly popularized it) - the unit of subroutine is a "function" which (probably because of its mathematic roots, or possibly because of what it's easy to make a compiler do) can take multiple parameters in, but can only return one thing. Perl, for one, didn't have that problem. A subroutine could have a return statement like
    return ($result1, $result2);
and a bit of calling code could easily grab each argument in a named variable:
    ($thing1,$thing2) = mySubroutine("foo","bar");

In fact, Perl uses this kind of in-array-variable-naming in lieu of traditional named parameters, so while C/Java/Javascript has something like
    function myFunction(String arg1, String arg2) {
Perl relies on a special variable "@_" to be the array of arguments, so a similar subroutine might start
    sub mySubroutine {
      ($arg1,$arg2) = @_;

It turns out that "in-array-variable-naming" has a formal name, and that is"destructuring", and it's going to be part of the next generation of Javascript!  In short, a function could return an array (as it can now) something like
    return [result1,result2];
but in the future the calling function could be doing something like
    let [thing1, thing2] = myFunction("foo","bar");
("let" is another bit of the new hotness, with easier to understand behavior in terms of scoping relative to "var". There are some neat syntax for packing up arrays, destructuring objects (vs lists) and what not as well.)

So that's pretty hip.

The final seminar I attended was on Web Components and Polymer. These are a kind of awesome way of writing your own tags to extend HTML5 - for example, you might include a Google Map as a single set of tags, or a chessboard display, or one of a bajillion bits of functionality. Each component gets its little shadow DOM, so conflicts in CSS and the like are avoided. (Polymer is just one implementation of the emerging WebComponents spec, but it seems good at using a "polyfill" technique to bring legacy browsers into the fold.)

I'm not quite sure why Web Components feel like the obvious future to me, and the Right Thing, when Angular.js feels like a weird, gratuitously complex set of kludges. I thought "making up our own HTML5-ish syntax" was one of things I hated about Angular, but I guess if you get the syntax and scoping cleaner, it's a pretty cool thing.

(https://www.polymer-project.org/apps/topeka/ is a nice demo of some of this flexible future.)

Still, I don't feel 100% at ease with Angular's "monitoring mapped memory to drive DOM changes" paradigm, its sometimes arcane syntax (oh, inject your dependency by an array consisting of a bunch of strings and ending with the function that does the work!-- though the conference pointed out how this is a pattern of protecting against "uglify" scripts that might try to rename globally shared variables), infamous learning curves, pushing of its own flavors of paradigms (ala factory vs service vs provider), extensive folder structures, etc etc -- or the way that Angular 2.0 promises to bust through some of the unfortunate syntax issues by making all your old code obsolete.

All that said, Angular might be the best bet in this direction that's here now, and I'm glad Web Components has shown me some of the light about getting into named components, not just an infinite future of <div> decorated in jQuery...

PS Another cool site is http://todomvc.com/, that walks you through the same basic example in a host of Javascript MV* frameworks...

Tuesday, September 16, 2014

the 7-minute no-look workout page

People at my company have been doing the The Scientific 7-Minute Workout. There are a ton of apps and pages and videos for this, but we were using http://www.7-min.com/. It's a decent site, but I realized there were some UX improvements that could be made. I noticed that I, and others using the side, would often:
  • announce the upcoming exercise (reading it from the page)
  • glance at the screen (some times difficult when on the floor!) near the end, and then count down the final "3...2...1" to alert peers
  • wonder what the "halfway point" was for exercises that didn't have a "switch sides" prompt midway through.
So I took these ideas, remade the illustrations, and ended up with kirk's no-look 7-minute workout page. (I also parlayed it into an open-source github project.)

The code is a bit inefficient, relying on setting up a big hoard of javascript timers, one for each page event. I'm toying with redoing it so it uses a single interval timer, but so far the current version seems to function ok. 

For sounds I used my own lowLag.js library. To make the voices, I used OSX's "say" command, using the India English voice "Veena" (some of the voices sound really off), dumping the result to an aiff file, and then using LAME to encode as MP3. (Happy to see firefox seems to be supporting MP3s now.)

The commands for that were:
say -v "Veena" "good job" -o goodjob.aiff
and
lame goodjob.aiff --preset medium goodjob.mp3

I didn't have permission to reproduce the NY Times illustrations, so I traced over and made some of my own. (I used ArtStudio on the iPad to trace over an existing set on a different layer.)

The only other clever bit was the old "python webserver" trick. 

It was nice iterating on this with "real users", i.e. my coworkers and myself. At first the "tick" was a bassdrum sound, but then didn't translate well over video chat. (Similarly, I may have to increase the contrast of the progress bar at the bottom.)

Anyway, the 7 Minute Workout is kind of fun. I'm skeptical about it, in some ways, and suspect we don't push ourselves enough while doing it, but still, it's better than nothing, and feels good to get through!

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.