The Six Goals of Every Programming Project

The list:

  1. The end user got what they needed, or what they wanted.
  2. The end user was able to easily make use of what you made.
  3. The quality, performance, security or other attributes of what you made were acceptable to the end user.
  4. You utilized a reasonable amount of resources in building it.
  5. You completed the work in a reasonable amount of time.
  6. The work was built to be maintained or updated or expanded.

The little-known iPhone feature that lets blind people see with their fingers.

A few years ago, backstage at a conference, I spotted a blind woman using her phone. The phone was speaking everything her finger touched on the screen, allowing her to tear through her apps. My jaw hit the floor. After years of practice, she had cranked the voice’s speed so high, I couldn’t understand a word it was saying.

And here’s the kicker: She could do all of this with the screen turned off. Her phone’s battery lasted forever.

The little-known iPhone feature that lets blind people see with their fingers

Apple Accessibility

RFC1925 – The 12 Truths.

(1) It Has To Work.

(2) No matter how hard you push and no matter what the priority,
you can’t increase the speed of light.

(2a) (corollary). No matter how hard you try, you can’t make a
baby in much less than 9 months. Trying to speed this up
*might* make it slower, but it won’t make it happen any

(3) With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead.

(4) Some things in life can never be fully appreciated nor
understood unless experienced firsthand. Some things in
networking can never be fully understood by someone who neither
builds commercial networking equipment nor runs an operational

(5) It is always possible to aglutenate multiple separate problems
into a single complex interdependent solution. In most cases
this is a bad idea.

(6) It is easier to move a problem around (for example, by moving
the problem to a different part of the overall network
architecture) than it is to solve it.

(6a) (corollary). It is always possible to add another level of

(7) It is always something

(7a) (corollary). Good, Fast, Cheap: Pick any two (you can’t
have all three).

(8) It is more complicated than you think.

(9) For all resources, whatever it is, you need more.

(9a) (corollary) Every networking problem always takes longer to
solve than it seems like it should.

(10) One size never fits all.

(11) Every old idea will be proposed again with a different name and
a different presentation, regardless of whether it works.

(11a) (corollary). See rule 6a.

(12) In protocol design, perfection has been reached not when there
is nothing left to add, but when there is nothing left to take

Javascript: Debugging Bitwise Operators

Most people are never going to even use bitwise ops, especially in JavaScript. But if you really must, beware all is not what it seems!

Problem 1’s Complement
1’s complement seems slightly off?!
console.log(~0xFF); //gives -256

You might then automatically assume that JavaScript implementation of 1’s complement is fundamental borked, a cursory Google might even back up that. Obviously its hard to believe that handling of bitwise ops are so broken in a language that is so widely used, but given that few if any web developers’ would actually need bitwise ops maybe its the case. (There are plenty of stack overflow posts that recommend the abuse of the ~ operator)

Taking a closer look at the ECMA script definition you see the definition of NOT as the following[1]:

      Let expr be the result of evaluating UnaryExpression.
      Let oldValue be ToInt32(GetValue(expr)).
      Return the result of applying bitwise complement to oldValue. The result is a signed 32-bit integer.

Now this is where things get interesting. You would naturally assume if you give the NOT operator a 8-bit value you’d get an 8-bit field back, but this is clearly not the case. If you want to dig even further the real concrete instance of the value is a 64-bit IEEE 754 representation see [2].

So that neatly explains why ~0xff transforms to -256

1111 1111
0000 0000 0000 0000 0000 0000 1111 1111
apply ~ (NOT)
1111 1111 1111 1111 1111 1111 0000 0000
aka -256

But that still leaves a problem, how can you easily debug a value that isn’t a Number but is represented as one…

If you’ve got this far there is probably a very good reason you’re using bitwise ops, otherwise you might have given up on them altogether. So it would be somewhat handy to look at the real value, and not the Int32 representation, which console.log and friends are going to give a misleading value for.

Getting at the full representation
A nice simple function to show all the bits for the input value.

>>> Operator coerce the value input a 32-bit representation by right shifting and filling in with zeros, depending on your usage you can also slice the value, to only show the 8-bits that are needed to debug, like so:

General Rule
If dealing with bits, clamp the field to the proper bit length before assignment. Using an 8-Bit clamped array is no guarantee that the value will be assigned properly, there are cases where the value can be assigned to zero instead of the proper bit value. For an 8-bit you would use array[i] = bits&0xFF this will make sure the value is appropriately truncated and does not get evaluated as a Number.


Factory of the Future

The factory of the future will have only two employees, a man and a dog. The man will be there to feed the dog. The dog will be there to keep the man from touching the equipment. Warren G. Bennis