Today and tomorrow I’ll be at the Keeping it Realtime conference in Portland, learning about all the cool new interfaces available for a real-time web. Unfortunately, I wasn’t able to finish my liveblogging plugin before today … so you’ll be stuck hitting F5 repeatedly to get update from me in this space. On the other hand, this will serve as a real-world demonstration of why the non-real-time web is so ineffective for real-time communications.
Maybe we’ll both learn something! 🙂
—
6:00 pmWell that just about does it for the day. Time to go home and recharge the batteries for tomorrow’s sessions. Have a great night!
5:55 pmIronically, it’s usually consumption that outpaces production … but that seems to have reversed in the Internet age at least.
5:54 pmIf the web is growing faster than the leading search indexer (Google) can index it, what does that mean for the future of data? The real-time web will only make the content on the web grow faster. Can consumption keep up?
5:49 pmHow contextual should push notifications be? The guy asking the question makes a good point. I don’t care about every new follower I get on Twitter, but there are some followers I do care about – like when a celebrity or someone with a larger network influence starts paying attention. I don’t need push notifications every time a dollar or two comes in or out of my bank account, but if there’s a huge, atypical withdrawal (or deposit?) I want to know pretty quickly. Context is what frames the value of the immediate notification.
5:46 pmIf you want people to find your app using Google, then (right now, at least) you almost need to build two versions of your app – one for the user, one in HTML for the crawlers. I thought that was the point of the hash-bang API Google and Twitter have been experimenting with. It at least warrants some further research.
5:42 pmIf I need to go to your app to get value out of it, there’s a problem. I’m busy enough, the content and value should come to me. The real-time web isn’t so much about making the web faster, it’s about making it more convenient. Updates and info come to me as I need them, they don’t sit on some static site and wait for me to come looking for the update.
5:40 pmPanel discussions work best with 3 experts. Maybe 2, but no more than 4. The moderator just summed up the 8-person panel perfectly: “We’ve had 8 people talk about themselves and the future now for 20 minutes …” Makes it hard to get into real content and discussions with a 40-minute time limit.
5:34 pm“Some apps are going to be real-time and it’s going to freak people out.” I definitely agree with that.
5:31 pm“Communicating with super-low latencies will give us some really cool apps.” I agree, but a lot of that still depends on technology. A lot of people still don’t have high-speed Internet, smart phones, or computers capable of doing even half of what we’re doing …
5:28 pm“We go to a conference to meet people.” I like the idea … but really, this conference has had such a tight schedule I haven’t had the time to meet many people. And the few I’ve had the chance to meet were kind of floating around in a clique … I got first names, quick handshakes, then they started talking about events from the previous weeks and started catching up on “in” things from their group. Not so much “meet people” there … so sorry, I disagree.
5:24 pmBankSimple will eventually be exposing a developer API? Awesome!
5:23 pmThe real time web, in the banking world at least, has been around for a long time on the side of the banks. But the future of the real time web is putting it into the hands of the consumer. Thanks for the innovations, Alex Payne!
5:19 pmEight panelists … I definitely do want to know what they all do … but with only 40 minutes for the panel I think these introductions will take way too long. Be brief people, please.
5:18 pmAnd now, the panel begins.
5:01 pmToday’s final panel will feature Mikeal Rogers, Alex Payne, Leah Culver, Julien Genestoux, Nathan Fritz, Jack Moffitt, Jeff Lindsay, and Chris Blizzard. Should be informative, useful, and educational!
4:56 pm10-15 minute break, then the panel I’ve been waiting for all day! Time to stretch …
4:55 pm… and if anyone builds something based on that idea, I want a copy. And a short “inspired by” attribution buried somewhere in a readme … nothing big, just something I can show off while waiting for the race to start …
4:54 pmI definitely think a geolocation feature for a marathon would be a good seller. ”Track me as I run this race.” I’d love to post an interactive map of a race, let people see where I am at any point in time, link together with a few web cams so they can watch me as I pass through check points. That’d be very cool.
4:52 pmA geolocation game played with cars … hmm …
4:51 pmSo what’s the difference between a geolocation game and an augmented reality game? I think it’s all in the UI, and that’s why it’s effective. With a geo game, you use the real world as the UI and the phone/device is just an added input. With AR, you use the phone/device as the UI and the real world is an added input. It’s all about affecting common behavior. If AR really wants to take off, I think it needs to start in geolocation and evolve with the technology.
4:46 pmA physical drive with 6 GB/s read and 4.4 GB/s write speeds? Holy crap. Even at 0k for a drive, that’s really incredible. I don’t think I’ve even touched something that needs that kind of speed.
4:44 pmI like the slide title: “Examples of doing it wrong.” Ironically, just about everything on this list came up last week when I had a performance problem with my app. I’m glad I was able to solve it without falling into any of these traps.
4:42 pmThe most relevant data should stay outside of the slowest point of the application. If MySQL (or the persistent store) is the slowest point, then cache data in memory rather than reading/writing from the database frequently.
4:41 pmWow … that was just the overview? Intense …
4:40 pmThe “Reactor pattern” is a way to resolve the blocking IO (scalability) issue, and most programming languages have one.
4:39 pm“Ruby doesn’t scale well” is a myth. The scalability issue is actually common to many programming languages, not just Ruby.
4:38 pmThe trick to async with MySQL is message queues … put that on my to-do list for research, since I’m not 100% sure how to accomplish that.
4:37 pmThe basic stack includes Redis, Node.JS, Socket.IO, and the web application itself. He’s going to give us more details … and now I understand Redis a bit more. I think a Pub/Sub feature for a key/value store is really powerful and will probably use it to power the subscription engine of SwiftStream as I continue to build it out …
4:33 pmThey originally built the system using Apache and discovered the hard way that it wasn’t asynchronous when 7,000 score updates were queued on the server and ate a lot of RAM. I’m so glad people warned me about that before I started doing async work … yay for Nginx!
4:32 pmThe video of the graphics and pings on the map was pretty cool.
4:31 pmGeoLoqi sounds like a fun team to work with. Having your job be making a game as an experiment just to see if it works? Awesome!
4:28 pmKyle Drake and Building MapAttack. I know web-based games are pretty cool, but a web-based game using real-world geolocation … it’s very similar to the augmented reality stuff my friends were trying to get me into last year. Should be exciting!
4:26 pmIronically, I just saw a presentation on Thoonk and when I tried to load their website, it crashed because the servers are over capacity. Maybe it wouldn’t be the best choice for a scalable web app? Just kidding, I’ll still give it a look …
4:24 pmSome of the resources Henrik exposed us to: &! (his app), Thoonk.js, Backbone.js, and Capsule.js. I still have no idea what Thoonk and Capsule do, but I’ll be looking into them. And into Redis. They could all be hugely useful.
4:20 pmThose last pieces of advice were courtesy of Nathan Fritz, who will be speaking tomorrow.
4:19 pm“If your app fits Redis, use it. If it only kind of fits, don’t touch it.” – Great advice and reminds you to always choose the right tool for the job.
4:18 pmRedis can keep the entire app in RAM for 10s of thousands of users. That alone is impressive.
4:17 pmWhy Redis? Basically because it’s “fast as hell” … or because it’s a “honey badger” … um … sure …
4:14 pmWow … this session is very much like drinking from a firehose. Capsule.JS is the latest framework we’ve been told about, and I still barely understand what any of these systems do. Kind of like a here-are-50-tools-pick-one presentation. I’m not knocking it at all, it’s just a lot of information to absorb and retain. I’m sure I’m forgetting far more than I’m retaining right now.
4:10 pmRedis, an open source key/value store, is a great way to share memory between processes and languages. It’s pretty scalable, too.
4:09 pmSharing data models between the client and the server is great for quick prototyping, but sharing that memory state isn’t very secure or scalable.
4:08 pmCase Study #3: andbang (&!), which just launched today!
4:05 pmCase study 2: Recon Dynamics.
4:04 pmParsing XMPP in the browser is a pain. In my experience, parsing just about anything in the browser is a pain, so you want to be sure the data is ready before you send it. Particularly if you’re concerned about cross-browser performance (I’m looking at you IE) …
4:01 pmIck. It’s built in Django. I’m not really a fan of using Python and Python-related frameworks for web apps … don’t ask me for a solid argument why, just a lot of bad experiences …
4:00 pmFirst case study: Frontdesk.im
3:59 pmReal-time, real-life Pac-man after the conference? Cool!
3:51 pmThe next session, presented by Henrik Joreteg, is about building 3 single-page apps 6 different ways. When I first read that description, it sounded very much like reinventing the wheel … but I’m intrigued nonetheless.
3:45 pmA lot of systems are turning things off by default now … is that the right plan of action? I don’t necessarily think so. A lot of users don’t understand how to turn things back on, so disabling features by default in favor of security is crippling users in my opinion.
3:41 pmSo where are websockets today in terms of security? Adam feels comfortable with them, but doesn’t consider himself a websocket expert.
3:32 pmWho’s responsibility is it to do secure code? Is it a requirement of the framework/language? Or of the developer using the tools?
3:28 pm“If you happened to fall asleep …” Sorry, guilty. But that was a really technical discussion of the issues in the community with a very limited introduction and not much room to breathe.
3:21 pmAdam’s goals for the community:
- Secure by default
- Better examples – documentation that doesn’t suck
3:17 pmThe challenge is that we have a lot of developers who don’t really understand a lot of the security concerns that come along with development on the client. They’re typically server-side developers who are now writing libraries for use on the client side … but they haven’t been coming from the client perspective.
3:15 pm“I might make a few people upset by this talk” … Now I really want to know why.
3:14 pm“Old Problems, New Tools” – Adam Baldwin
3:08 pmNext up, a presentation from Adam Baldwin, the co-founder of nGenuity.
3:07 pmIs there binary support for websockets yet? It used to be stream based, now it’s packet based … but the best answer is “I think so?”
2:56 pmDebugging long-lived applications in the browser? Mozilla is building out a pretty advanced memory management tool. They’re breaking out DOM, content, layout, style, etc.
2:52 pmApplications don’t need to live in the cloud, they can live in the browser and interact with other browsers, the cloud, or other applications.
2:51 pmIt also allows for direct peer-to-peer data transfer. That’s a lot better than routing data through a 3rd party server. A peer-to-peer connection would be faster and, from a privacy standpoint, a bit more secure than a peer-to-server-to-peer connection.
2:51 pmWebRTC is a direct audio/video connection between browsers. It’s not run through a 3rd party server to reduce latency. I think it’s a fantastic idea, and what I referred to at one point as “Skype in the browser.” Apparently Mozilla and Google are collaborating on it. Awesome!
2:49 pmExposing device APIs and providing access to lower-level functionality of the machine to the browser and the browser’s applications are important.
2:47 pmApplications and web pages are different things. You install an application … and the mental associations that come along with that instill a sense of ownership. When you use a web page, you merely visit the web page. It’s easier to offer subscriptions and have a pricing model for an installable application than a website, even if they run on the same platform and present the same experience.
2:46 pmYou can build web-based applications that run in the browser but which aren’t server-based applications. This is a hugely powerful concept.
2:44 pmGoogle as an alien face-sucking monster … interesting analogy …
2:44 pm“Data in the cloud is the new proprietary source code.” Data is being locked in because it’s stored on a proprietary system.
2:42 pmWebsockets are nice because there’s not much overhead added to the request.
2:42 pmHTTP has been evolving from long, static requests, to asynchronous requests for chunks of HTML via XHR (XMLHttpRequest), to AJAX long polling, to websockets.
2:39 pmThere are technologies that we’re going to be building into browsers that will change the way the world builds web applications.
2:37 pmConsidering the cool stuff Mozilla has been doing with Firefox lately, this should be a pretty powerful presentation.
2:37 pmNext up, Christopher Blizzard from Mozilla … talking about “Real Time in the Browser”
2:35 pmNo idea what the next presentations are about … but I’ll be sticking in Track A for the next few speakers as well. Their resumes are compelling enough to promise something interesting, so I thought I’d gamble and stick it out here.
2:25 pmAnd now I hear about JSON-RPC … I need to see how that’s different from dNode, since that itself seemed very much like a JSON-powered RPC system.
2:24 pm“Futon” is the event service bus for hook.io and CouchDB. I think this particular community needs some help naming their projects …
2:22 pm“That totally should’ve worked.” No joy … here, though. Sad. 1 more demo to hopefully finish things up.
2:21 pmAm I the only one seeing the freaking awesome implications of a system like this? Twitter, IRC, a browser chat … all talking to one another and broadcasting messages. One point of entry, one API, over 40 different application hooks to broadcast and transport messages. Incredible!
2:20 pmWe’ve now established bi-directional communication between the browser and IRC … next we’re adding Twitter.
2:19 pmOK, the browser just piped a message through hook.io into the IRC chat room … awesome stuff!
2:18 pmNow we’re listening to IRC messages, too.
2:17 pmAll of hook.io is in active development, and hookJS was just introduced a couple of months ago.
2:16 pmCrap … I tweeted and get to be the “first victim” in the presentation.
2:15 pmAwesome captcha … that looks like nothing you can possibly type.
2:15 pmSetting up hooks to listen to Twitter and IRC at the same time. That’s freaking cool.
2:13 pmNext demo – setting up a quick RSS feed server …
2:11 pm“Sorry, bear with me for just one moment … ” Methinks we failed with the third goal of the presentation …
2:10 pmOK, I definitely will need to build something with hook.io. This is nifty stuff.
2:08 pm(My host might reboot my server in a few minutes … so if I disappear, I’ll be right back …)
2:04 pmGoal for the live coding demos – build an application, process multiple data streams, don’t fail.
2:01 pmIPO – Input, Process, Output. Building on this model, you can have a lot of actors that make up an application that is greater than the sum of all its parts.
2:00 pmSadly, I’m surrounded by Mac users. Seriously, I can see 16 different laptops from my seat and every single one is a Mac!!!
1:59 pmApparently I’m not geeky enough … he instructed us to curl an address and I immediately went to my browser because I don’t know a better way to do it on Windows 
1:55 pmComing up next, Marak Squires and hook.io in Track A …
1:54 pmI have about 50 different ideas in my head right now … and not enough time to do more than 2 or 3 of them. Maybe I should just spec out some rough details and sell the concepts to the highest bidder …
1:46 pmdNode is the same API for client-server and server-server. And the protocol is entirely abstracted away so you can use the protocol without using the dNode library at all. That’s the biggest difference between dNode and nowJS.
1:45 pm“How do I handle getting and setting closure variables? I don’t …”
1:45 pmTestling – really simple JavaScript unit tests that will run in all browsers.
1:44 pmBouncy queries dNode using Socket.IO to route requests from one server to another and act as an on-demand load balancer … that was actually a pretty cool demo. Simple, easy to use, but I think it’s insanely powerful.
1:41 pmIt definitely feels like “shared memory through communication” from that earlier presentation. You don’t have to duplicate functionality in different locations so long as you communicate enough to expose and support that functionality in those different locations.
1:41 pmWhere dNode shines is in its functionality and its ability to expose functionality you’ve already written somewhere else.
1:40 pm“Most of you are from the Bay area.” I feel special … I’m not 
1:39 pmCalling a remote process lists a bunch of data and a method name … I think an improvement would be to also list out parameters for the method. Kind of like a WSDL for a SOAP call. Knowing that the bart system exposes a departures() method doesn’t help me if I don’t know what parameters the method requires/accepts.
1:36 pmThere are PHP, Java, Ruby, and Node.JS adapters for dNode. I wonder how hard it would be to write a .Net adapter. JS-based RPC would be huge for my .Net MVC projects.
1:35 pmSo long as you use callbacks, it’s pretty much all going to work.
1:34 pmdNode calls functions using an RPC pattern. This is quite different from most of the REST-based web communications I’ve done so far. Particularly since it’s an RPC call written in JavaScript that uses JSON as a transport rather than XML.
1:33 pmdNode is like a newline-delimited JSON.
1:32 pmdNode isn’t just for Node.js and client side JavaScript. There are some adapters for other languages as well.
1:31 pmWatching someone live code during a presentation makes me feel like a crappy developer …
1:29 pmYou have to be really comfortable with callbacks … but if you’ve been doing any JavaScript, you already are.
1:28 pmOoh … live coding demo. Using vi. And Node.JS. Awesome.
1:27 pmYou don’t have to build a routing table or marshal around this stream just to use the callback.
1:26 pmThe cartoon crocodile can zig() …
1:25 pmdNode makes it easy to sychronize a flow in realtime.
1:25 pmOne of my coworkers wants to learn to be a “hacker” … I don’t think he knows what that means, but it’s entertaining. I should have brought him with me!
1:17 pmI’ll be sitting in Track A after this – first up in 10 minutes is James Halliday discussing dNode.
1:15 pmThere’s a lot of test coverage with Derby’s examples and a “pretty cool test suite around what Racer does.”
1:15 pmThey Derby framework will be used to build a lot of apps, will have changes to support ACL and authentication, and will provide long-term support.
1:09 pmDerby isn’t trying to answer the “how do you scale to a million user” question. Their first focus is on “how can anyone build a realtime app quickly and easily.” It’s all about getting the API defined first, then they’ll focus on scalability.
1:07 pmDerby can drop in realtime interaction to any web app. Check out a pre-beta demo athttp://derbyjs.com.
1:06 pmDemoing a realtime chat app in a room full of geeks with laptops … that was interesting.
1:05 pmThe goal of Derby is to provide a way for every developer to build applications that are fully realtime and fully multi-user.
1:03 pmBut application schema and data schema aren’t quite the same thing. That’s actually a great innovation and one I’ve already used in a couple of projects.
1:02 pmData will automatically sync to your database, not just between your client models and your server models.
12:59 pmIn the error handler, you can re-try the same action that just failed. I can see how this will help circumvent race conditions by just reapplying changes … but it seems a bit inefficient to just retry upon failure.
12:57 pmRace conditions and conflict resolution. Once you have a lot of concurrent connections, you can run into a lot of them. Makes synchronicity difficult.
12:54 pmI like how the underscore-signifies-privacy convention has now found its way into HTML rendering …
12:52 pmOoh … “slightly more complicated example”
12:51 pmNo, I get it. The client side MVC framework is in JS … so writing the code once for the client means you can re-use the code for a server-side Node.JS setup. Not bad, but it would mean migrating a lot of my existing .Net work if I want to take advantage of the write one, use anywhere paradigm.
12:50 pm“Write your routes once and they work on both the client and the server.” … so write them in which MVC framework? The PHP frameworks and .Net frameworks are different enough that I’m concerned here …
12:47 pmI like the way the Derby markup looks … but now I’m wondering which IDEs support it. I must say, Visual Studio Intellisense has me a bit spoiled when I start looking at web markup and IDEs.
12:46 pmIf any of your users don’t have Internet access but have your page loaded, they can still interact with the application because it shares a lot of the server code with the client already.
12:43 pm
A to-do application demo in Derby.
A to-do application demo in Derby.12:42 pmViews, models, and routing. Nothing new. Except it’s entirely asynchronous and can connect an input field on one machine in one browser to a display field in another for another user entirely.
12:41 pmDerby is all JavaScript … I’m quite excited about that. It means I can use it in my existing .Net projects as well as my open source PHP projects!
12:39 pmDerby is built around realtime and has a component called Racer that works as a realtime data synchronization engine with Node.js.
12:38 pmHe’s describing the disconnect between MVC on the server and “really complicated” jQuery on the client side. Sadly, he’s describing the exact problem I was fighting through all of last week …
12:37 pmThe after lunch talk is starting. Introducing Derby. It’s a new MVC framework that makes building realtime apps “easy.” I’m every excited about this one!
12:19 pmI think I need to migrate over to the Track A room for the next several sessions … anyone near an open power plug?
11:48 amAnd now it’s time for lunch … yay for food! Feel free to track me down at some point and say hi!
11:48 amI tried using Growl on my iPod when it first came out. Haven’t touched it again since. I really thought it had disappeared entirely until Adam mentioned it just now in his chat.
11:44 amAnd now that I’ve compared realtime communication and push notifications to Flash … please don’t shoot me.
11:43 amUse push to enhance your application. Give your users options and don’t let the technology get in the way of the experience. Reminds me of the advice we’ve been giving developers regarding Flash for years.
11:39 amUrban Airship has their own push transport … called Helium. This warrants some looking in to …
11:37 amBy the way, I’m working with my VPS host at the moment to correct the 8-minute timestamp issue on these posts. Should be resolved within the next hour or so. In other news, AtumIT rocks!
11:31 amReminds me of the disconnect between a sandbox PayPal account and a production one … don’t know things will fail until they do
11:31 am“99% of the problems using push come from a disconnect between development and production.”
11:30 amFrom the looks of things, Apple is a great way to learn sockets and push communication. Too bad so much of the code examples are written in Objective-C.
11:26 amYou can request all three of those permissions or just a smaller subset of them. Honestly, even all three isn’t that much … unless Apple expects to extend more permissions to push-enabled applications, I don’t understand why they’d make it that granular in the first place.
11:23 amOn iOS, applications can’t run in the background, so there are just a handful of things you can do: display an alert, add a badge (like an unread count in mail), and play a sound.
11:21 amPush using iOS and Apple for history and background…
11:17 amNow it’s time for Adam Lowry and “Connecting the Disconnected” …
11:10 amAn attendee was just asked for his opinion on an issue … “I blogged about it, so you can go read about it.” Um … we don’t know who you are, buddy.
11:09 amIf storing state in a distributed system is a mess … why do we bother making a stateful system in the first place?
11:05 amFor those of you paying attention … the time tags on my updates are actually 8 minutes behind. Not because I’m a slow typer, but because my VPS’ internal clock is off.
11:04 amEven though ZeroMQ can abstract a lot for you, it’s still too low-level most of the time.
11:02 amZeroMQ is a socket abstraction layer for messages rather than bytes.
10:58 am“Don’t communicate by sharing memory; share memory by communicating.”
10:57 amThe trick is being able to answer, “what’s happening now” not answering “what happened 5 minutes ago?”
10:55 amIt seems to me that there’s a disconnect at the data level. On the one hand, we need to record data quickly to capture all of the real time events that occur in a system. But the discrete events aren’t what’s interesting … its the aggregation of that data that’s interesting. So at the DB level we’re running into a speed issue – speed of recording events and speed of processing complex queries over those events.
10:52 amIn a realtime system, you have very simple bits of state, but the simple systems are more about answering questions regarding multiple users. What are the trends across the system?
10:50 amThe tricky part with building a distributed system is controlling the multiple points of failure.
10:44 amAnd now a quick test post to check that polling refreshes are working …
10:42 amTesting the AJAX polling system to make sure it’s working properly …
10:49am – Installing a quicky AJAX polling system so you don’t have to refresh any more …
10:42am – 10 minute break until the next session … Time to breathe for a minute …
10:39am – Having multiple sharing/interaction features on a site is ineffective. The user is one person, so breaking apart Facebook and Twitter and Tumbler and … sucks. There are ways to communicate between the two – Khris is recommending we all take a look at Backplane.
10:37am – Realtime is about different aspects of the web. Creating data, delivering data, storing data. But another great focus is processing the data to extract meaningful, marketable information.
10:31am – Great live example of a realtime interaction that isn’t a status update stream is the “Trend Watch” on reuters.com.
10:29am – Realtime is somehow associated to a list of updates presented in reverse chronological order. But that’s not all that it is. We need to break out of that stereotype. I agree 100%; there’s far more data that can be presented in realtime than just status updates. It’s just a matter of providing value so that you’re not just collecting data for data’s sake.
10:28am – “Once you lock in to one of these units, you can just rip through the rest of the industry.”
10:26am – Realtime on NBCs website makes keeping your phone nearby while watching TV essential to the experience. If you’re not watching the show and engaged with the site … you’re missing something. Fantastic use of technology!
10:24am – A concept called “push to air” allowed publishers to quickly push content and comments from a live Twitter/Facebook/Forum feed directly to an on-air TV show. This definitely makes it compelling for people to go to the site and interact with the feed. “Hey, I might get on TV!”
10:20am – Print publishers and magazines can do interesting things, but they’re all going out of business and disappearing …
10:16am – Hearing about a simple product “anyone in this room could build in an afternoon,” realizing that I could build it in an afternoon, and hearing how much money it was sold for … I’m frustrated I wasn’t there first, but excited that I’m still there in the first handful of people in this industry. Definitely a lot of financial potential here.
10:14am – To stay relevant, old time publishers like the Washington Post are going to need to transition away from a static, “crap” experience and towards a realtime one. The new experience these days is Facebook and Twitter. It’s live and realtime. Who wants to go back to an old, static experience after that? I can definitely relate … I get more news from Twitter than I do CNN …
10:13am – “The transition from the static web to the real time web isn’t just cool and exciting. There’s a lot of money there!”
10:11am – “Twitter is doing 230 million checkins a day … and we’ll look back at that later and laugh and think it was a toy.”
10:09am – Look for the products and innovations that should be built a year from now or 5 years from now. If you focus on what needs to be built now, you’ve already missed the boat.
10:08am – Society tells you that you can’t predict the future. We think that’s crap.
10:05am – “The transition from the static web to the realtime web is as important as the transition from the quill to the printing press.”
10:02am – A “nontechnical” presentation at a tech-centered conference? Hmm …
9:54am – In the mean time, I’m wondering why so many “real time” applications (like the aforementioned Google Reader demo) are only realtime on the server side and not on the client side. It would be huge if my feed could update in realtime. Speaking as a publisher, it would be awesome if I could update my readers in realtime as well. I think there might be a definite use of adding a meta tag to the headers of my documents to link to a realtime hub.
It’s just a question of convincing more people to update content for the client in realtime once I start pushing content to aggregators in realtime.
9:53am – Awesome presentation with some live demos. Next up is Khris Loux talking about realtime and revenue. I’ll be taking a copious amount of notes.
9:50am – The Google Reader demo was a server-to-server interaction … not a server-to-client interaction. So while your feed would be updated on Google’s system, you wouldn’t see an update until you click the Reload button …
9:45am – Greetings to all of you reading this site in real-time. Google Analytics tells me there are 6 of you at the moment. Realtime web in action! 🙂
9:43am – Apparently Tumblr uses a hub to push feed content out to subscribers in real time. I’m now wondering why WordPress doesn’t use a similar setup … and just finally discovered a potential business use for SwiftStream at the same time …
9:40am – We use there parties: the publisher who has the data, the subscriber who wants the data, and the hub that routes data between the other two.
9:39am – The only widely-used protocol on the web is HTTP, even though there are better protocols out there. So to make a realtime web on a large scale, we’ll need to use what’s already available and ubiquitous.
9:33am – A clock is a real-time realtime example. You could poll it … wake up every minute and see if it’s time to get up, or just wait for the alarm to go off instead. I’d rather wait for the alarm.
9:32am – Realtime doesn’t mean it has to be now … realtime can be really slow.
9:30am – “The key to real time is to be like the kid in the backseat asking ‘are we there yet are we there yet are we there yet …'” I’m impressed, Julien must read my blog.
9:27am – Making the web real-time versus making a specific website real-time involves making services and web servers push content back and forth in real time.
9:25am – First session is a little late, but looks to be pretty good regardless. I heard Julien talking up his presentation during breakfast, so I’m looking forward to it. Now that they’ve gotten the microphone working, that is …
9:15am – The conference is now open and there are a lot of people here.