Nodevember 2014 - Sunday

@bejonbee talking about React.

He works for an interesting group of people – not the usual consultancy, but a wealth-management and self-sufficiency group, doing education. Interesting premise.

Mostly a 101 to react, but nice to see someone more familiar tie some things together.

The implications of the DOM-diffing behavior are really interesting, in that modifications made outside of React are preserved, not overwritten – React really does play nice with others.

JSX is interestingly implemented; solid work by people who really understand parsers, but they’re somewhat simplistic about the lexing, so that class is a reserved word, meaning HTML class= had to be renamed className=.

@funkatron is giving a talk on “Open Sourcing Mental Illness”.

His talk’s been recorded 14 times(!) and he has copies up at funkatron.com.

Comparing eye disease – needing corrective lenses – to mental illness. Awesome! “How many people here have just been told you need to ‘squint harder’” .. no hands.

“how many of you would feel comfortable talking about a coworker you knew pretty well about having cancer?” Most hands.

“How many would feel comfortable with talking about your mental health?” Maybe 1 in 5.

Moderate depression`has a similar level of disability to MS or severe asthma.

Severe depression has a similar level of disability to quadrapeligia.

“You are so brave and quiet; I forgot that you were suffering” –Ernest Hemmingway

Watching @derickbailey‘s talk on development environments and getting out of IDEs, looking for advice to give to developers at PayPal.

I just realized that Grunt looks a lot more amazing if you’re coming from a heavy IDE with lots of features but no flexibility. It’s amazing what perspective looks like!

And now to @hunterloftis “We are all game developers”

He built a game for a major music artist in the UK in three weeks, using software rendering. Great art and integrating the music.

Now 1.7 billion WebGL devices were shipped last year. It’s available on IOS 8!

“We avoided a lot of work by avoiding state” – since most rendering is built with pure functions from a tiny, immutable state, lots of things like animation speed came out naturally. Then add websockets and the state from one user’s view controls a renderer on the server. Super clever.

requestAnimationFrame can drop frames, so time has to be calculated and perhaps multiple simulation ticks (to assign position and state) to keep time constant and not dependent on the computer’s speed. He points out that this affects testability, and rendering and simulation have to be decoupled.

Simulate faster than rendering: otherwise, tearing and sync problems.

Made the audience laugh with an awesome bug, trying to simulate rigid body physics, a simple box, which in trying to make it behave right flaps around the screen like a bird, squishing and flopping before it pops into final shape. The take=away though is that if physics is written deterministically and not depending on the render loop, the bug is repeatable – and it’s possible to know the bug was fixed since the simulation is deterministic.

And techniques for controlling state and using immutable objects apply greatly to DOM rendering and apps too. React uses determinism to great effect.

talks I missed

I’m bummed that I’m missing @thlorenz‘ talk on heap dumps for mere mortals, but I’m making a note to have good conversations with him after the fact. (He’s already got his slides up!)

I heard that @cdlorenz’ “Runtime Funtimes”

@nicholaswyoung‘s (Original Machine) talk on microservices.

“We learn more from things going wrong than things going right”

Divorced the CMS domain from the podcast feed domain, and separated out the web player software.

“When we release a new show, we get 10,000 requests to download the show in the first few seconds. Ruby wasn’t the utopia we thought it was.”

“I build a monolith because that’s what Rails conditions you to do. The admin dashboard, the analytics, the feed generation all in one app. You put your controllers in your controllers directory and your views in the views directory, and you end up with a monolith.”

“Our media services would hold requests and it would take users 4 seconds to load our application”.

“I didn’t initially know how to made node work. First thing I did was write a monolith. I thought the runtime would save me. I’m _smart_”

Seeing the core broken up into such isolated modules, you get the idea that breaking things up is a good idea.

“It’s an application. I guess you could call that a _service_”