Just track the actual number of frames an animation has taken so far and the number of frames it needs to take to complete in the time taken. For bonus points re-average your framerate each time an animation ends by keeping track of the number of frames an animation actually was able to take.

And as far as easing goes...

http://www.robertpenner.com/easing/

Ext has a nice DataStore object for accessing remote data. And Ext has all those great "rich" components. But I found it wasn't much more work to do my own components in jQuery. (Tree is very simple to implement in jQuery from scratch)

The sense of control I have with jQuery is nice.

The main code to handle my own trees:

  _.fn.toggleTreeNode = function(animate) {
    var node = this.filter('button');
    if(animate) {
      node.siblings('ol').slideToggle(animate)
    }
    else { 
      node.siblings('ol').toggle();
    }
    node.parent().toggleClass('closed');
  };

My favorite thing about jQuery is it makes doing things the right way very easy.

What happens when a Master node dies? (Or, say it's EC2 instance kicks the bucket, rare but possible. Or in the case of a non-EC2 deployment the hardware just fails.)

My limited understanding of Erlang leads me to think the unhandled death of a Master node is the death of all the nodes in the cluster.

Further, I understand this does not have to be. I remember there being some way for another node to respond to the death of another node, handle that death, and let things continue along.

Is anything like this set up in Fuzed? Would this be handled by having multiple master nodes for a cluster, and they watch each other?

Would there be any difference in setting up Fuzed to handle the death of the Master node process and the disappearance of the Master node instance?

When a master node dies, all the worker nodes go into a hibernation state, pinging the master's previous hostname until they can reconnect to that host, and then they reregister their resources with the master's resource_fountain.

One of the next major features for fuzed is handling the master as a single point of failure. We're exploring two options currently:

1. When a master dies the cluster can re-elect a new master on one of the machines in the cloud and everyone re-registers their assets. This process assumes that master death is relatively rare, and so minimizes the resources necessary for redundant operation at the cost of a slight time gap in service while the master is re-elected and resources are re-registered to it.

2. Clusters can create numerous masters which all maintain identical state. When one dies, another master will move forward and become the primary master. This approach requires more hardware in the cloud, but even if the master faults are common they don't allow for a gap of service.

As for the difference between process death and machine death, yes there are differences. If you're interested in how we handle it, please check out master_beater.erl (great name, huh?), which is a gen_fsm that worker nodes use to eagerly reconnect to the master. Also check out the fuzed.ap and fuzed_supervisor.erl. Erlang provides very good resources for handling this.

Let us set the scene: A small television ad-agency of around 100 employees. Creative, Production, Replication, Sales, Media Purchasing, Finances, Management, Shipping, IT and Marketing all work in concert.

This company does it all. Finding products, producing spots, buying time on the air, duplicating and distributing video tapes and tracking sales.

They have an elaborate database keeping track of everything in motion. There is a minor breakdown in this system(well, there are many, but I'm focusing on this one). Replication needs work orders to copy a tape and ship it to a station.

These work orders are sheets of paper, in triplicate. They contain hand-copied information from the database, such as station name and address, the code of the tape, the required date of arrival and the preferred shipping method.

On some days, hundreds of requests come to the replication department and prioritization begins. But before triage begins the forms must be sorted.

Management knows about the problem. And they know it's expensive. Sorting and prioritizing takes up precious hours. With a five o'clock shipping deadline and limited VCRs, every minute you don't have a tape in a deck is a potentially large commission lost.

In comes IT. And requirements gathering begins. They're a hip, 'with it' bunch of guys and know how to ask the right questions. "What are you doing?" vs "How do you think a computer should do it?"

But even that isn't enough. Pressure is on to mechanize and automate the entire department. Every other department is in the system. Why isn't replication?

The solution is fraught with bar codes, complex color-coded prioritization schemes and a host of other features to let replicators know in an instant: "What tape do I make next?"

That system is ten years behind schedule. Has no hope of completion and most of what they really need could be implemented for a fraction of the cost.

What went wrong?

They thought of something other than the user experience. They focused on requirements. But those requirements are already met. Requests come in. Requests are prioritized. Tapes go out.

In their zeal to improve the efficiency of it all everybody had no sight of what they should have been doing.

Improving the user experience.

This is what they should have done. And had they been willing to listen it would have happened.

Simple no-brainer: stick the requests into a database. Only a minor fraction of the data on those forms was new information and a ridiculous amount of time was being wasted hand-copying it for each form.

Then give video technicians access to a simple column sorting view of this data.

Let the computer sort. Computers are good for sorting.

Let the humans prioritize. Humans are good for prioritizing. And the team in replication knows the infinitely complex prioritization system they use better than anybody in the world could. They know what attributes matter when, and when to escalate a time-crunch up the chain of command. What was really slowing them up was sorting hundreds of sheets of paper.

And there you have the vast majority of the time wasted in this process knocked out with the features more-or-less already implemented by the database in use.

Let other features get added on people see opportunities and say: "Hey, wouldn't it be cool if it did ..."

I worked in that replication facility before I got into programming. And it has shown me changing the way think about how to use a computer is a far more daunting task than any design I'll ever come up against.

This is a nice one.

I just read http://thebackofthenapkin.com/ on a train ride last week.

It's a good read about how to solve problems and sell ideas with simple pictures like the one in that post.

Not sure what I can add to the discussion about the topic in the image, but I was inspired to share the book.

And Seth Godin(Oh really? I hear he's on Internet.) says it makes you smarter, so maybe we can use it to fight the anti-intellectuals :D

I just finished up my submission today and subtext is relevant to the idea.

I'm big on visual tools. From everything I've read and experienced I believe we should be expressing our instructions to computers in a more visual manner.

I can get non-programmers to "just get" the tree-view/node highlighting in firebug. Those same people see one hacking at html and wonder aloud how you can have any idea what it all means.

I can explain REST to my mother and it just makes sense, but her "programming" experience stops at a spreadsheet.

I make the point about the spreadsheet intentionally. A spreadsheet to manage what furniture goes on a shipping container, and in what order based on the distance to deliver is quite a complex set of requirements for an application.

But my mother, partner in a small furniture company, does just that sort of thing regularly. I do think there is something to be said for the amazing feats one can undertake when it is required. But I'd really like to make a point about the importance of spacial thinking.

When I program I only get one dimension for my instruction set. It goes from the start of the file to the end of the file. I may have some tricky control flow structures, but I still have to represent them in a wholly linear fashion.

Whereas my mother, with her spreadsheet gets two spatial dimensions to think in. She can even put multiple planes right next to each other.

Our minds are wired to interpret spatial(visual) information. Thats why my mother can easily solve complex, unique problems with a spreadsheet and wouldn't even want to read a "real" program. And yet, if we can allow oureselves some perspective, they are really the same thing. A human's instructions to get a machine to solve problems.

I would never expect my mother to create space-shuttle software or anything like that. But she, and I'm sure untold millions like her are better equipped than some programmer to understand the requirements of their business' problems.

The spreadsheet was great when computers were for crunching numbers. But in this wild world of the web, I think it's time my mother had a better tool.

Really? Instant communication over Internet? Chat! IM?

I want more focus on the innovations in Google Docs etc.

Multi user interfaces stretch my perception of what to use my computer for. Multi user apps have yet to really break into the mainstream outside of games and IM. Should be interesting to see the explosion as "comet" is starting to become easier to do than not.

Just wait till it in something trendy like rails :)

I think it behooves hacker news to stay as ujderground as possible.

You know, there was a time when Digg was a good source for programming news and discussion. Digg. Reddit too.

This site is now where I huddle to get that programmers social news fix.

It's important for those of us interested in making the social web to have our own little unadulterated social webs. This site also needs to stay lean so hackers will be drawn to it. ycombinator watches this thing to see what potential founders say. I think this should be a place for those thinking of, or filling out an application. At least, that's what I hope to find in reading it.