Monday, February 1, 2016

the office meets lord of the rings

Lord of the Rings as "every crappy enterprise IT project" ever:

Kind of brilliant! I like how there doesn't even have to be a bad guy, per se...

quick hack to center horizontally AND vertically on page...

I participated in my 8th Global Game Jam. I wasn't as delighted in my team's game (Dinner Party Faux Pas) as much as I have been previous years, but it was a fun exercise in making a game directly in the DOM (instead of the canvas) and I learned one decent trick: to center a div (or whatever) horizontally AND vertically, you can CSS something like the following:
  width:400px;  
  height:400px;
  background-color:red;
  margin:auto;
  position:absolute;
  top:0;
  bottom:0;
  left:0;
  right:0;
Pretty nifty.

Thursday, January 28, 2016

artsy css animations

A friend of a friend made a cyberPunkGenerator, sprouting slogans and doing it's best to look like an old crappy VHS playback. It's an intriguing use of some css animations such as blur, flick, and jump.

Wednesday, January 27, 2016

quotes from "Dreaming in Code"

"The realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs."
--Maurice Wilkes, in 1949, at the dawn of the age of debugging computer programs.

"The hard thing about building software is deciding what to say, not saying it."
--Frederick Brooks

"Is it possible to do great work without great pressure, or is pressure an indispensable part of genius?"
--Michael Toy

"Joy is an asset. It may well turn out that one of the most important effects of open source’s success will be to teach us that play is the most economically efficient mode of creative work."
--Eric Raymond

"All programmers are optimists. Perhaps the hundreds of nitty frustrations drive away all but those who habitually focus on the end goal. Perhaps it is merely that computers are young, programmers are younger, and the young are always optimists."
--Frederick Brooks

"Front ends are supposed to be elegant, intuitive, versatile; back ends are supposed to be invisible, efficient, rock-solid. The front end talks to people; the back end talks to bits. In Star Wars terms, the front end is the butlerish C3PO; the back end is the unintelligible R2D2."
--Scott Rosenberg

We are still building our software cottage-industry-style today.
--Brad Cox

"There's a difference between transparency aimed at giving visibility and transparency that is aimed at producing collaboration.”
--Ted Leung

"If it takes the typical programmer more than two minutes and twenty-seven seconds to find something, they will conclude it does not exist and therefore will reinvent it."
--Larry Constantine.

My thought on that last one... Yes, but: The price of learning and configuring and tweaking a large system that almost does the required job - and could be similarly battered into shape of handling lots of other tasks- is often larger than the cost of making an original, smaller bit of code that just handles the matter at hand. and, that is also more fun. Or as Rosenberg puts it later in the book: "There is almost always something you can pull off the shelf that will satisfy many of your needs. But usually the parts of what you need done that your off-the-shelf code won’t handle are the very parts that make your new project different, unique, innovative--and they’re why you’re building it in the first place."

Or as he even later refines it:

"Rosenberg’s Law: Software is easy to make, except when you want it to do something new. And then, of course, there is a corollary: The only software that’s worth making is software that does something new."
--Scott Rosenberg, "Dreaming in Code"

Tuesday, January 26, 2016

unit tests vs integration tests

I admit my understanding of unit tests is still a work in progress... I still don't get:

  • how they don't just test implementation
  • how you expect developers to hunt for something they really don't want to find (i.e. problems with their implementation... I mean if they could think of it, they would have solved it in the code, right?)
  • how they work in a world dependent on side effects: if it's a function, inputs in, output out, that's pretty straightforward. But so much of UI, say, is the evil of "side effects", changing something else in the environment that the user will see...
Anyway, a coworker said the following tweet made him think of me...

Thursday, January 21, 2016

the bees' ease

Bees & Bombs is Dave Whyte's site where he posts what has become a garden of beautiful hypnotic looping animations.

Once upon a time, he mentioned his secret was this equation:
3x2 - 2x3
This is an easing he frequently relied on.... as x varies from 0 to 1, it also varies from 0 to 1, but at various rates. (One of my first posts on this blog was about various easings, the equations you can add to transitions and animations in order to make less boring and linear and more organic.)

At one point he mentioned he had switched to Paolo Ceric's easing equation which goes like this:
float ease(float p, float g){
  if (p < 0.5) 
    return 0.5 * pow(2*p, g);
  else
    return 1 - 0.5 * pow(2*(1 - p), g);
}

It's pretty rad because you can change the value of g and get different results: 1 is linear, like you were doing no easing at all, while a value of 8 would be a long windup and slow down and a quick motion in between.

The link above has an animation that shows Paolo's equation in action for various values of g for linear motion... I decided to make a rotation based animation to see it work, and also to compare it to the Bees & Bombs original formula:

That's kind of a long transition, here it is with every other frame skipped:

Here's the Processing program I used to make the animation. I had some problems with the GifMaker library, so I ended up tweaking the final GIF by hand using EZGIF.com, a new-to-me useful site for making and manipulating Animated GIFs.

Tuesday, January 19, 2016

the dawn of debugging

"The realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs."
--Maurice Wilkes, in 1949, at the dawn of the age of debugging computer programs.