4:56 pmNext on the schedule is Jack Moffitt on “Imagining the Future of Realtime” at 5:20 …

4:55 pmIs it true?  Do we really have a 25-minute break before the next session?  Time to stretch!

4:53 pmThe various frameworks are being built out of very different use cases.  So “real time” is more a family of ideas than it is a singular concept.

4:52 pmAre there any efforts at collaboration between the various frameworks?  Collaboration would help create standardization, but I agree that it might be a mistake.  Don’t start standardizing while you’re still experimenting with new approaches.  Get it all on the table first.

4:49 pmNode inspector lets you step through code running on the server inside a browser using Chrome’s JS debugger.  Awesome tool.

4:48 pmWhat are you using for debugging? “I’m using Visual Studio” … “I’m using console.log()” … yeah, I can vouch for VS being a far easier way to debug than printing to the log …

4:46 pmHaving a context and a stack trace is nice, I agree, but some times they don’t make much sense, either.  I have yet to see a stack trace for a multi-process/asynchronous system that makes sense …

4:43 pmSignalR is all about making “this kind” of programming available to a .Net stack.  It’s too important to not have anything.  I agree 100% and hope to see some options come out in the future.  I like the idea of SignalR so far, but I’d like to see other approaches at addressing the same problem, too.

4:42 pmMore realtime frameworks should interface in a polyglot kind of way.  And should add distributed/realtime debugging.

4:39 pmWhat is the biggest problem that your framework does not solve?  This is a very good question when people like me are trying to choose a framework to start with.

4:38 pmWhat technologies inspired your frameworks? Ruby programming … Jarvis from Iron Man …

4:36 pmUsing middleware to cancel DDoS attacks … like someone running an RPC command from the browser console a million times …

4:33 pmWhat is your framework’s security model?  ”None.”  That’s been the question no one’s asked yet this conference.  I know everyone’s focused on building the API right now, but “security’s not a big deal” isnot a good answer.  Security should be one of the first concerns, not an after-the-fact addition.

4:29 pmWe should be benchmarking the user experience.  That’s all that matters.  +1

4:27 pmOne thing that unites all of the guys using this realtime “stuff” right now is the use of Redis.  That’s true based on what I’ve seen so far … and I’ll be learning Redis over the next few days and weeks to make sure I’m ready for it!

4:26 pmA lot of the realtime standards/frameworks are still in their infancy.  This tells me far more about the industry as a whole than most of the other conversations.  Really, if you use any one of these frameworks you’ll need to be somewhat risk tolerant, because the API and standard will probably change tomorrow.  So use it, but be ready and willing to change and evolve your code and implementation as the system grows and matures.

4:24 pmWe might see more of an organic standards practice with regards to realtime.  This is similar to the way jQuery’s DOM selector pattern has influenced the modern web …

4:22 pmShould there be a standard way of “doing realtime?”  I can’t speak for the panelists, but I don’t think there should be.  The potential use cases are still being developed, so creating and sticking to a standard now would be a bit limiting.

4:17 pmOut of all of them, I’m the most excited about SignalR … if you haven’t heard of it, it’s freaking awesome!

4:17 pmWe’re discussing: SocketStream, Flowtype/NowJS, SignalR, dNode, hook.io, and Derby/Racer.

4:15 pmI once again have Internet access … but it may or may not last.  In any case, we’re now starting the panel comparing various realtime frameworks.

1:47 pmWatching so many command line demos has me really wanting a Mac or a Linux box … I’m installing Cygwin for now …

1:39 pmMessage queues can be implemented in MongoDB, but you have to poll … so it’s not a good solution.  Redis has Pub/Sub, PostgreSQL has listen/notify.  RabbitMQ and ZeroMQ are MQ’s … right?

1:33 pmMaking scalability more fun, less painful …

1:32 pmNext we get a “turbocharged toolkit for realtime in the Cloud” … yay for practical takeaways!

1:30 pmSorry, I missed the last half of that chat.  My office website crashed and I’ve spent the last few minutes debugging in terminal server …

1:07 pmThe browser doesn’t care which Node instance is handling things on the back end.  It gets all of its data through one pipe.  So don’t use one Node instance to handle two different data sources – like a chat feed and a Twitter feed.

1:05 pmDoes anyone here think that JavaScript is not fun?  Yeah … rhetorical question, but really … not fair to single out someone who dislikes your favorite system just because you have a microphone.

1:04 pmYou can exploit Node as a message service on the back end with a bunch of different workers.

12:59 pmDon’t re-invent the wheel.  Leverage the frameworks and systems that have already been built.

12:53 pmYou can’t just push TCP traffic out to the Internet, you need a gateway to transport it.  This is where Node and similar systems come in – they act as the gateway.

12:49 pmHTTP is wasteful.  Large headers for overhead, high latency with polling and new connections.  These aren’t issues with websockets.

12:46 pmWe’re all in agreement, websockets are the way to go!  The original system was designed for document pages … i.e. Mosaic.

12:45 pmNext presentation by Axel Kratel.

11:53 amTime for lunch! Let’s hope it’s a tastier fare than the carb-fest that was our breakfast … bread + french toast + oatmeal + cold cereal … we need some protein!

11:50 amWhy sticky sessions over pluggable persistence?  Because it’s meant to work with different development frameworks and languages.  You might do one thing if you’re using Redis and Node, you might do something else with a different system.  Specific decisions have been made in order to keep SockJS “polyglot.”

11:46 amSome of the complexity in this system is rooted in the fact that the browser is untrusted.  That’s an issue that comes up time and time again … and I have yet to see a reliable solution that doesn’t include just forcing more of the processing to the server side.

11:41 amGoogle App Engine, PubNub, and Pusher are all trying to do the same thing … providing a messaging API that’s simple to use.  But they’re all very complex under the hood.

11:39 amSockJS is only a transport layer.  If you want higher-level message abstractions, you should build them yourself.

11:37 amIf your server can handle sockets, but doesn’t have a SockJS library for it, you can deploy SockJS as a proxy … that’s interesting, but I don’t see the need.  Sounds like adding complexity for complexity’s sake …

11:34 amSockJS requires an asynchronous stack to work properly.  This makes perfect sense and speaks to a lot of the problems I had implementing websockets with Apache a few months ago.

11:33 amMost importantly, there is no Flash fallback … just native JavaScript.  This is the best part of SockJS, in my opinion.

11:32 amSockJS gives you abstractions that look like websockets but can use different underlying transports if needed.  It makes it easy to begin using websockets without needing to worry about the different implementations of the spec.

11:30 amChrome treats websockets as a binary thing and tries to push a lot of data through.  Firefox treats them like HTTP because they look like HTTP.  This makes using proxies difficult.

11:28 amIf you want to sum up SockJS in one sentence, you could call it a Socket.IO clone.  I guess that answers my question about the differences between the libraries …

11:27 amOoh, he’s giving away t-shirts for audience participation.  You can never have enough dev-related t-shirts.

11:27 am“WebSocket emulation kept simple, stupid.”

11:25 amNext up is Marek Majkowski talking about SockJS.  Hopefully this will explain how SockJS is different than Socket.IO (aside from some obvious differences in implementation that we discussed over breakfast).

11:25 amWhy didn’t they use websockets for the messages?  Because they needed to support multiple browsers and devices that don’t support websockets.  So instead they used a standard HTTP POST to send the data and long polling to update the vote tallies.

11:21 amAnd that’s the third person who’s alleged that this is a Node-centered conference.  Maybe we just need more asynchronous, event-driven, open-source servers …

11:20 amIs the underlying technology Node.JS since this is the Node.JS conference?  No … they’re using C.

11:17 amHow does data replication occur for multiple servers? As long as they’re all connected, they’ll all receive the message.  They’re basically all talking to one another all the time and sharing updates.

11:13 am10-15 languages and 10-15 frameworks … definitely a rich system.

11:12 amSpike allowed people to vote once every 5 seconds.  So apparently there is a bit of state information transferred in that massively distributed system.  They managed to handle 10s of thousands of concurrent users, too!

11:09 amDrumo is a realtime app on the web that’s similar to Quora.

11:07 amPubNub is “one step closer to the Singularity …”  This is an idea that came up yesterday and, oddly enough, the exact topic of the story I’m writing for NaNoWriMo.

11:05 amDoing this kind of project required a new type of architecture.  You can’t just take an existing LAMP stack application and add some realtime functionality to it.

11:02 amOnce again, Redis comes up as an efficient, quick data store … I will be adding Redis to my stack within the next few weeks …

11:01 amVotes came out at a rate of 350 votes/second and updated aggregate totals across all devices at a rate of 10 times/second.

11:01 amAfter 80k votes, there was only a 100-vote difference between zombies and vampires.  I’m less impressed with that stat as I am with the fact that they collected all of those votes in real time in less than a 5 minute period …

10:59 amTen times per second every device connected to the site updated the voting results.  Everyone saw realtime data in real time.  Awesome!

10:58 am(The Internet is a bit spotty today, so if I lose you, I apologize in advance.)

10:57 amReal-time voting with SpikeTV using The Deadliest Warrier as an example.  I love that show!

10:28 amHad to step out for a minute, what’d I miss?

10:22 amOK, that was cool.  Sending a message from ZeroMQ on the server side with python over a socket to NullMQ in the browser.  Great to have the demo pay off.

10:21 amOne of the slower live code demonstration sessions of the conference … the ones using prepared code seemed to go a bit smoother.

10:16 amCreating a request socket in one browser session and a listener in the other.  Nifty.

10:15 amAnother real-time demo of realtime.  Awesome!

10:14 amHmm … apparently our table just lost power.  Could be a bad sign …

10:11 amSTOMP is a simple protocol for PubSub connections. It looks a lot like HTTP, there are verbs, a header, and a body.  It’s simple and human-readable.

10:09 amNullMQ is meant to be an implementation of ZeroMQ for the browser.  It’s designed to extend features and the ZeroMQ API to the client-server nature of the web.

10:08 amZeroMQ isn’t in the browser … so there are some limitations to what you can do.  You’d have to write a plugin/extension to get it into the browser.

10:07 amI think I could integrate a Twilio-style realtime phone call support feature into my company’s client portal … add another idea to the never-ending to-do list I’ve created this week …

10:05 amTwilio has a product for making and receiving calls through the Internet using JavaScript.  Now that’s just cool!

10:04 amThe Paranoid Pirate Pattern?  Interesting development nomenclature …

9:59 amZeroMQ isn’t a server or a protocol, it’s a library that presents a socket-like messaging API over a variety of transports.

9:58 amThe context for this involves ZeroMQ, which is a transport layer I’ve never really heard of.  But from the docs, it acts as a concurrency framework.  Maybe this answers one of my earlier questions …

9:56 amNullMQ is so new, it started 3 weeks ago.  I love new tech!

9:55 amAnd now Jeff Lindsay will talk about NullMQ.

9:53 amNode is at version 0.6 but is getting pretty stable.  If you want to build a business on it, you might want to wait for 1.0.

9:47 amA one-line HTTP server in Node can proxy a request.  Awesome.  I need to start using Node.  Looking forward to the Node/IIS discussion later today!

9:45 am“clientRespsonse” … someone didn’t proofread their slides.  This is why I don’t use code in my presentations …

9:40 amI’ve never heard anyone pronounce “url” as a word before.  We all usually just spell it out.  Took me a second to figure out what he was talking about.

9:36 am“We need to steal the right ideas, not the popular ideas.”

9:33 amIf anyone in the world who wants to edit a specific Yammer page goes to the same Node process, itdoes make the application code easier.  But that kind of centralized computing comes with its own problems.  There’s a reason AWS and Google’s cloud are so popular …

9:31 amOne of the reasons dNode is great is because you don’t have to send all of your state arguments with the RPC request, you just leave them in the closure.

9:29 amPHP, Python, and Ruby all suck at concurrency.  So this makes me wonder if there’s a language/framework that excels at it …

9:28 am“Node.JS is starting to dominate this space.”  That’s seemed very obvious from this conference.  One of the guys I talked to today even suggested changing the conference to ‘Keeping Node Realtime’ based on the number of speakers referencing the project …

9:25 am“You might want to talk to Facebook if you want to talk to somebody’s mom …”

9:23 amAnother Rails presentation … I really need to learn Ruby …

9:22 am“The consumer is never the content creator.”  At least not until Web 2.0 changed the way the web worked …

9:22 amSo far I’m seeing a lot of logical progressions in how the server side of things changed – static pages to static pages served by Apache to database parsed by PHP and served by Apache.  But we never really changed the browser and are still stuck in the stone age when it comes to consuming the information stored in the DB.

9:20 amThe problem in the old days was getting really old browsers to use these static web pages … and in many circles, that’s still the problem.

9:16 amGetting started with the introduction talk by Mikeal Rogers.

8:41 amEveryone here seems to use Rails for just about everything.  Methinks it’s time to learn Ruby …

8:21 amGood morning from the breakfast table!