DomesticMouse

The UI is built by geeks for geeks. Google's issues with keeping designers is well known.

The exciting thing about Wave for me is that it is a way of distributing update capability to a server hosted xml document. The spotlight that is being put on Operational Transforms is the game changer.

http://en.wikipedia.org/wiki/Operational_transformation

PG's post is interesting, as always. The bit that is worrying me is the linked Etherpad animation. Am I the only one that looks at the Etherpad DVCS using javascript functions as the delta data format, and think XSS sploit in waiting?

There is a rule of thumb in UI design wherein if someone blames operator error, that's shorthand for system failure. Obie's call that Alex's code base is bad is classic blame the operator behaviour.

I'm glad Tony has been found. His articles always make for interesting reading. His plight is of concern to me, even though I have not met him. I'm still hoping to get some time off at some point to get scala training from the WorkingMouse guys.

Dude, frack no. Having everything in a database means you are tied to the speed of disk, instead of the speed of ram. The biggest issue with being purely ram resident is handling multi-threaded updates across your ram resident dataset.

You could always use Erlang...

Think how different HN would be if the comment pages updated themselves in real time as people commented?

Or a bug tracking system. Or a newspaper. Or pretty much any site, really.

Maybe it makes some sense in server apis?

I don't know. I'm sold on using long polls in conjunction with actors...

Are you questioning the relative merit of reverse http, or of the ability of the server to update the page?

I'm failing to see the advantage of reverse http over long polls, even though I am completely sold on the difference that having server push would make...

IPv6 makes routing packets harder, not easier.

Where there is a price difference, there is an arbitrage opportunity. Sure it's a bunch of work, but it only has to be done once. With something like software radio it can even be invisible to the end user. It becomes a usb dongle that feeds them high def youtube et al.

Broadcast has bandwidth. Computers have brains. Why are these two competing? Broadcasting a signal that means something to computers, and having computers then marshal that for users is way more profitable.

Easy place to start - start hiring a small TV station for an hour in the morning, somewhere in amongst the informercials, and broadcast a signal that people with TV Tuners can decode. Using some variation of colour 3D barcodes, say. Have the TV Tuner decode software use this hour to pump content into squid or some other form of web cache.

Monetisation strategy: give people the ability to vote on what gets broadcast based on their cache logs.

Broadcast bandwidth is currently being wasted big time by the broadcasters. It is actually worth more as a backfill conduit to feed desktop caches than to broadcast TV repeatedly.

Where are the cost centers in production? I've watched some guys I know get together and make films using pro-am hd cameras, and then edit it down on a mac pro.

Would building an online service that allows people to mail in hd tapes, and then edit online via a flex app help? You could use AWS clusters to handle the rendering compute load.

Integrating servers that are being used as message conduits between the front end and the back end of an application seems like a nightmare, security wise. I much prefer integration points to be limited rather than everything out in the open.

As a ten year veteran of Java, currently learning C# (the world is full of irony), I can say that Java is a simpler language. There are a bunch of bones thrown to c++ and assembler focused guys in C# making it a more complex language to master. And I dispute that VisualStudio is a better IDE than IntelliJ. So, my honest opinion is start with Java.

Spend time writing code, and just as importantly, reading it. Read through Spring, Hibernate, et al. Understand the architectures, the trade offs, and the code tricks.