getting xwindows to run nicely on mac osx

I was having some problems running X-windows commands across an ssh connection.. http://www.mit.edu/people/lucylim/MacX11.html gave me some hints -- I'm not sure if that was needed or not because what really helped was downloading and running XQuartz, http://xquartz.macosforge.org .

FUN FACT: X -Windows kind of reverses the usual meaning  of "client" and server". The computer in front of you with the screen is "providing X windows services", and the individual programs you are running on the remote machine (or, technically, the local one) are X-Windows clients.

imagemagic notes

A while back I wrote about ImageMagick and editor macros. For a personal project, a comic book, I'm back to using it for some bulk image processing. And speaking of processing, this time I wrote a Processing program to let me select regions from a 1000x1000 image and then figure out the corresponding ImageMagick command to clip out that area from the 7008x7008 original, resizing the clipping to 1000 pixels wide by whatever the correct height was.

I didn't spend much time making the program "good" from a UI sense, in fact I had to edit one line it and rerun for each image- but Processing is so quick that wasn't much of a burden. I would select each area in turn and tap the space bar when I was happy with the clipping region I had drawn.

The Processing code was:
PImage img;
String file = "45"; //change this for each image
void setup(){
   size(1000,1000); 
   img = loadImage("orig/"+file+"_1000x1000.png");
}

float startX, startY;
void draw(){
   image(img,0,0);
   noFill();
   rect(startX,startY,mouseX-startX,mouseY-startY); 
}

void mousePressed(){
   startX = mouseX;
   startY = mouseY; 
}

void keyPressed(){
   float w = mouseX - startX;
  if(w < 0) {
     startX = mouseX;
     w = abs(w);
  }
  float h = mouseY - startY;
  if(h < 0) {
     startY = mouseY;
     h = abs(h);
  } 

  int realX = round(startX * 7.008);
  int realY = round(startY * 7.008);
  int realW = round(w * 7.008);
  int realH = round(h * 7.008);
  int finalW = 1000;
  if(realW == 0) realW = 1; //catch case if area not really drawn
  float ratio = (float)finalW /(float) realW;
  int finalH = round(ratio * realH);
  

   println("convert orig/"+file+".png -crop "+realW+"x"+realH+"+"+realX+"+"+realY+
           " -resize "+finalW+"x"+finalH+" out/"+file+"-"+".png");
  flush();
}

The flush(); at the end didn't do what I wanted, which was to ensure Processing's output buffer showed the line immediately, but it worked well enough and wasn't worth fixing.

The ImageMagick command it output was:
convert origfile.png -crop WIDTHxHEIGHTxTOPxLEFT -resize WIDTHxHEIGHT outputfile.png

Another ImageMagick I had to lookup today is

convert file1.png file2.png file3.png +append outputfile.png

"+append" is pretty handy for making an "image sequence". I haven't experimented with what happens if the images are different heights, but it met my goal of making a simple "filmstrip" from the pages. (I'm going to use that as a simple thumbnail view.)

on frameworkless javascript

An article that appeals to my personal stances about Javascript toolkits; I'm always a little hesitant to go too much into my views, because I don't want a potential future employer to think I can't be a team player in terms of adopting a toolkit they're using, or that I'm mired in a "Not Invented Here" (NIH) outlook. Also, my outlook isn't entirely well-researched at this point, I haven't used every one of the major toolkits.

Whenever you add a technology that increases the distance between what you are looking at in the debugger window and what code you wrote yourself, you might be making life more difficult even as it seems "easier" to do other tasks. It's one thing for a toolkit to offer lots of power and save you lots of coding, but if you can't model how it's doing what it's doing, you're not being a good programmer. (Down to a certain level, of course, it's not like I think in assembly language and circuit gates-- but it has to be down to a point of solidity and robustness) The nadir of this style of coding was with Microsoft in the aughts; legions of coders who were writing lots of powerful stuff but had no idea what to do when it went wrong.

For me the way to best leverage what other coders have done is to prefer "do one thing well" tools over frameworks, keeping the core code in as "pure" a language as possible, like raw JavaScript, but then farming out annoying things (like templating or animation/transitions) to a self-contained tool, like jQuery or handlebars.

on smartwatches and doing a few things well

For Christmas I received a Pebble smart watch. I think it works well because it doesn't try and do to much: it's pretty happy just being a watch (with options for different watchfaces, and even an ability to roll your own (and I'm very tempted to try and port Timish, a "watch for literate time" I prototyped in Javascript a while back)) and showing you notifications.

Of course, the makers of the watch would be mad at this description: it can do more than that! There's a whole app store! It can control music! There's an accelerometer! It can... well, I dunno. The physical interface is a bit limited. I'm sure there's a bunch of stuff it could do, but it raises the question: why?

But I find the notifications feature worth the price of admission. It's great not to have to dig out my phone to see if a message is important, and the watch's vibration on my wrist is much easier to notice than one from an iPhone that's jammed in a pocket. It's also reduced the amount of "phantom vibrations" and I check my pocket for imagined alerts less often.

This is in contrast to what the Galaxy Gear offers in this creepy, creepy ad:


That's a lot of features! But the ad has to bundle up its people in ski gear or load them down with wine glasses to make their point... otherwise all of those functions are going to be easier to do on the companion phone itself, with its fullsize screen. (One exception might be the camera... but then that gets into the whole realm of surreptitious photography aka creepshots.)

I was trying to quantify the boundary of "useful" to "just nice to have, maybe" and realize the Pebble's sweetspot maps 1:1 with the information on my phone's lockscreen: the time, and notifications that may have occurred. Everything else I'd have to swipe to get to anyway. The watch saves me from having to dig out the phone, and makes glancing at at least the sender if not the subject or some of the content of a message very discrete.

(So, reviews of the Galaxy tend to be pretty mixed: the camera feature is solid, and the "talk like Dick Tracy" seems kind of fun. There are still some fundamental issues, mostly concerning battery life.)

It's an exciting space. The Pebble is meeting my needs well right now, though I might jump on the bandwagon once Apple gets its act together. I think the Gear might be a little underrated, but who knows.

For at least the medium term if not longer, I think connected watches will be much more useful and fun than, say, Google Glass. I got to play with one during the holidays, and man, it was so not ready for prime time... an ugly little screen floating in my vision, looking like an Atari 2600 screenshot from ten feet away, having to reach up and stroke the side of the ugly frames, feeling like I was looking like a freak to people who didn't know what I had on, and a potential creepshot taking perv to those who do... decades from now, it might be useful to have information bounced off some lenses, but right now I'm pretty skeptical about this flavor of ubiquitous computing. (Or maybe I'm just turning into an old codger.)

js quick hits

A nice little list of javascript snippets. Good stuff.

improving encapsulation with a singleton pattern in js

A while back I blogged about a simple javascript singleton pattern. Recently at work I got called on the fact that it was doing a bad job at encapsulation, specifically there was nothing like public/private functions in it, even though I was implementing an API with functions that might as well have been private, for clarity purposes.

The core pattern was something like
var someObject = new function(){
    this.someVariable = undefined;

    this.init = function(){
        alert("started up");
        someObject.someVariable = true;
    };
}
The slight variant goes like this
var someObject = new function(){
    var somePrivateVariable = null;
    var somePrivateFunction = function(){
        alert('shh');
    }
    this.somePublicVariable = null;
    this.somePublicFunction = function(){
        alert(somePrivateVariable); //still has access because of function level scoping
        somePrivateFunction();
    }
}

Now the outside world has access to the public things but not the private ones.