Friday, April 18, 2014

more improvements to object like encapsulation in js

An improvement to what I wrote about here-- I was still thinking in terms of a singleton pattern, but I think it can be easily extended to be reusable:

With a setup
function someObject(init){
    var somePrivateVariable = init;
    var somePrivateFunction = function(){
    this.somePublicVariable = null;
    this.somePublicFunction = function(){
//still has access because of function level scoping

You can make multiple instances

        var m = new someObject(1);
        var n = new someObject(2);

Wednesday, April 16, 2014

simple pixel programs for OSX

There were two things I started missing when I switched from Windows to OSX: one is the program IrfanView for folder based image viewing and basic manipulation (resizing, cropping, rotation). Those functions are handled pretty well though with a combination of Finder's builtin viewer (hit space when a file is selected, then use arrow keys to navigate through the folder itself) and OSX Preview.

The other was an editor more advanced pixel work, without running smack into the cost and/or usability hurdles of Photoshop or GIMP. On Windows I enjoyed Paint.NET (after a decade of getting by with an ancient copy of Paint Shop Pro). It was tougher on OSX -- Pixelmator was somewhat ok, but did a lot of things oddly, and fell into the mistake of assuming its native format was preferable for everything. (Sometimes you just want to open a PNG, edit some pixels, and save it again, but that wasn't trivial in Pixelmator.)

Now, however, I think I might have found my new favorite: "Acorn". I didn't experiment with it before, but it (temporarily?) knocked down its price from $50 to $15, and it seems well worth it.

So: "Acorn" for OSX. Recommended, and well-priced. (For the time being at least.)

Monday, April 14, 2014

ye olde joins

Just a summary of some stuff I used to know pretty well, but it has been a while: (and also a little exercise in differences in how people visualize stuff...)

Roughly, there are for kinds. Lets say you have a table A and a table B, joined via some ID.

  • INNER JOIN - gets you rows that appear in both A and B
  • LEFT JOIN - would return rows that appeared in A, whether or not they showed up in B
  • RIGHT JOIN - same as left, but swapping A + B
  • OUTER JOIN - would return all rows from A and B, whether or not they had entries in other table
To keep track of that, I found it useful to draw it out, the chart on the left. The syntax is a little wonky, of course. Scott, who was going over this stuff with me, thought Venn diagrams made more sense- his stickie is there on the right. I find it harder to wrap my brain around it, but I'm including it here as a nice display of different learning/visualization styles. 

(this reminds me of how odd it kind of is, how much of my SQL background was Oracle's flavor. Its old PL-SQL used a kind of wonky "(+)" symbol to indicate an outer (or optional, as they thought of it) join.)

Friday, April 11, 2014

a more joyous phone ui

I admit I kind of want a phone that looks like

with a UI that moves like
I was pointed to this interesting work from the site Minimally Minimal. I'm not sure if such happy bouncing and what not is within minimalism principles or not, but I dig it.

Wednesday, April 9, 2014


So, a recent popular idea in Javascript land is that it's always better to compare values using "triple equals", ===, which won't do type conversion, over good ol' "double equals", ==.

So quick example:
  var foo = 123;  //foo is an integer
 foo == "123"; //true, foo "double equals" the string 123
 foo === "123"; //false, because they are different types

I find myself disagreeing strongly with the preference for "===", for 3 iffy reasons, and I think one good one.

1. What I'm used to

I can sound like a cranky old hack sometimes, and remembering to type === and !== seems like a pain, and just kind of looks ugly.  Moreover, I cut my teeth on loosely-typed "Duck languages" like Perl. So if I read in a string and wanted to compare it to a numeric value such as 123, I wouldn't want to fail just because they were "different things", or came from a different source.

2. How I think about Java

Java's String primitive/object has a parallel situation that is deceptively similar, with .equals() vs ==, and I think I draw a false analogy.  To whit: for Java objects, == is only true when you have two references to the same object in memory, while equals() should be true if two different objects are equivalent. So for instance,
 String foo = "bar";
 foo.equals("bar"); //of course true!
 foo == "bar"; //don't count on it, buddy

So I learned to be careful, and use the "less strict" equals() for most stuff I was interested in. This makes me nervous about ===. Like, I'm almost skeptical that Javascript
 "foobar" === "foo" + "bar";  //true (amazingly ;-)
Yeah it works, but because I think of it in terms of what it looks like in Java, I don't want to trust it.

3. === is used to show off

It feels like an elitist shibboleth to me. (And yes, I love that knowing what "shibboleth" means is in itself a shibboleth.) To be fair, these people probably point to funkiness in the truthiness tables, and just odd asymmetries there, but in my heart of heart I think it's just a way for the with-it hipster coders to show they are with-it hipsters.

4. if(arg == undefined) //true for argument not passed, and null, but not for zero

Finally, this might be my most serious argument.

Say I have a function funk(arg), and returns its argument or a default of -1, if no argument is passed. (And of course it should work with 0 as a value) So:

function funk(arg){
  if(arg == undefined) arg = -1;
  return arg;

That works pretty well... (if I used the conditional if(!arg), that would accidentally catch 0 and return -1, and so in general I shun simple boolean expressions, preferring to check for undefined.)

So what I like about == is that is that funk(null) would be caught, and replaced with -1, but if I used === funk(null)would return null, because undefined === null is false.  (Of course, "null" and undefined are kind of odd beasts in Javascript land; some people think the "undefined" value is just an accident of history anyway.) (PS don't do stuff like using undefined as a real value, like calling funk(undefined) - that's just R,O,N,G, wrong.)

So basically, I prefer the behavior of double equals, and prefer its made up "this would fail!" arguments to the ones made in favor of trouble equals.

(Quick tip: if you don't know it already, the "console" you can get to in Chrome inspector or Firefox Firebug is great for doing this kind of little functional definition, tooling around with making and calling functions, just ignoring the page it's on. And of course it's an invaluable tool for poking around your Javascript in general.)

FOLLOWUP: A friend of mine points out "NaN" kind of messes up my simple != undefined filter, since it is defined, but probably not what we were expecting to work with what I described.

Monday, April 7, 2014

gender difference in 3d perception

Fascinating article on the gender difference in 3D perception systems by gender, and how women might be more prone to feeling sick using systems based on parallax (which is what most binocular-based systems are based on) at the cost of "shape-from-shading".

It's one of those cases where all-dude teams, even "well meaning ones", may be making gender assumptions they don't even realize.

Monday, March 31, 2014

200th post!


Yes, I am that old. To celebrate rolling in my 40s, I made a simple tool to generate this kind of fixed-width text. The one caveat is I decreased the line-height so that the text was more compressed, but that means it invisibly overlaps page content above and below, and so sometimes makes neighboring objects unclickable... ah well! No one said aging was easy,