Right. "Realtime" is a bit overloaded of a term, and you've identified the two main interpretations.
The realtime data concept has a bunch of buzz right now and is predicted by some to replace "web 2.0" as the most overused buzzword. The optimistic view of this trend is that always-on internet and smart phones are reaching a critical mass so that there's a demand to know what's happening right now.
In terms of web technologies, the standard implementation for "realtime" updates is to use timers to periodically make AJAX requests. Inefficient, sure, but you can minimize this. Look at sending JSON and using javascript in the browser to add the data to the page as HTML, optimizing database/datastore queries used to serve update requests, and using "lite" versions of your framework if possible (Rails, for example, provides "Rails Metal" for this type of thing).
If you're interested in alternatives to polling, look at ReverseHTTP or comet. Pubsubhubbub looks promising in the web resource space.
This reminds me of that YC funded recruiting company (forgot the name--help!) that closed up shop and had their postmortem featured on HN recently. The conclusion was that HR departments aren't a profit center, so there's no motivation to innovate.
Maybe there should be a RFS for a better way to measure HR performance; that way, at least the pointy-haired bosses could be yelled at by their pointy-haired bosses when they score below industry average, or worse than last year.
internet/_why
#=> SystemStackError: stack level too deep
I remember reading on his twitter something like, "a caller asks: should I use hpricot or nokogiri? If you're not me, use nokogiri. If you're me, then stop being me"
I liked the article, but agree that the suggestion that Cell networks can be run like Wi-Fi isn't feasible. The amount of signal loss through a barrier increases with frequency, so 2.4GHz signals die out more quickly than, say 700MHz. To be a bit anthropomorphic, radio waves don't see the thickness of an obstacle in terms of inches or meters, they see them in terms of wavelengths, which are inversely proportional to frequency. So opening up high power, low(er) frequency wireless equipment to everyone would most likely be a disaster.
On the other hand, the current practice of just handing over chunks of scarce resources to anti-competitive firms _is_ broken, so the author is correct that change would be beneficial.
Shorter: Based on one or two poorly coded web apps, which are also examples of the best web programming ever, I have concluded that web developers are stupid.
Shorter comment thread: I have decided that all of the hard CS problems in web programming, including, but not limited to, scaling, machine learning and recommendations, high availability and fault tolerant systems, and everything google does, are called "server programming," because I would otherwise have to admit that many web developers are smarter than me. Also, javascript was not designed from the ground up by Microsoft to draw graphics on a canvas, so everyone who uses it for that purpose is also stupid.
I would recommend that you switch to ruby or python, then start going to the local users groups for whichever one you switched to. Stick around for the chatting/beers/etc. afterwards and network. Bring up your ideas with hackers that you hit it off with. If one of them bites, then by working together they'll make you a better hacker and you'll make them a better businessperson.
If you're looking to do this relatively soon, then I'd recommend picking one area of development, such as HTML/CSS and focusing more effort on that so that you can contribute effectively to building the project when it's just the 2 or 3 of you.
The realtime data concept has a bunch of buzz right now and is predicted by some to replace "web 2.0" as the most overused buzzword. The optimistic view of this trend is that always-on internet and smart phones are reaching a critical mass so that there's a demand to know what's happening right now.
In terms of web technologies, the standard implementation for "realtime" updates is to use timers to periodically make AJAX requests. Inefficient, sure, but you can minimize this. Look at sending JSON and using javascript in the browser to add the data to the page as HTML, optimizing database/datastore queries used to serve update requests, and using "lite" versions of your framework if possible (Rails, for example, provides "Rails Metal" for this type of thing).
If you're interested in alternatives to polling, look at ReverseHTTP or comet. Pubsubhubbub looks promising in the web resource space.