(First thoughts, still a little rough. But every time I do this, I find that getting something out there motivates me to make it better. But if I wait till I think it’s done, it just sits there.)
- The cookout last night really was just like a family reunion.
- I want to bring my kids next year.
- Spent time by pool today, even there people on laptops.
- Offday in between is brilliant. This is what (to me) made it a family fun event. I can see bringing my kids next year.
- Nice mix of fun stuff, process, and tech
- Snacks/food/organization great.
Remy Sharp & WebRTC
In a nutshell, you don’t need to fully understand something to use it. Just try it and see if it works. Slides
- Web RTC is pure peer to peer
- can stream video or do sockets over peer to peer
- can do UDP across this?
- Bleeding edge changes under your feet, so expect to spend longer getting it working.
You are not special, but in a good way. No one is born an expert, we all have to learn. Slides
When you are not a beginner
- can you use the fundamentals in any language, you aren’t a beginner
- do you write from scratch
- you look inside the libraries you use
When you are not an expert
- you can’t explain what you know in a clear way
- you are not confident debugging
- rely on references too much
How to be an expert?
- ask why all the time
- teach or speak
- experiment (code doesn’t care)
- have opinions
- seek mentorship
- program a lot
- stop programming and do something else for a while
- write js
- write another language
- fall in love with your process
Angus Croll & Literature/JS
Brandon Dimcheff & Title: Down The Rabbit Hole: Chasing bugs from the browser to the backend
A nice presentation on debugging a particular problem, with some good humor. No slides.
- graph everything
- logs in JSON format
- jsontool for npm
- do the stupidest easy thing that works to recreate the issue (he pulled his ethernet cable out to simulate network flakiness vs using iptables).
Peter Flynn && Performance Tuning Secrets
Adobe guy with some nice Chrome debugging tips. I just captured some things to look for in the docs vs explaining them.
- remote debugging api
- telemerty framework lets you automate ui actions
- topcoat uses this for their testing and does d3 visualizations
- close all tabs but the one you want, find which process ID you want
- can see memory leaks and # of dom objects
- acn see gcs that block execution
- can diff memory snapshots
- can overlap these
Brian Cavalier && Connecting your shiz.js with AOP
A very interesting talk about how to construct apps w/o the intervweaving of dependencies. The really nice part is that every variation is coded and on Github. This is probably one my my top takeaways to dive into deeper. Didn’t take good notes because I was caught up in the actual code he was showing, and how things worked. But worth a deep look.
- Aspect Oriented Programming
- Aspect - encapsulated unit of behavior
- AOP lets you use methods as events
Dan Webb & Flight.js
New UI framework for events from Twitter.
- We want to decouple views, models, etc
- What do we have in the browser? We have the DOM.
- So we use events since those are there.
- Flight only worries about the events
Raquel Vèlez & AI.js: Robots with Brains!
This was a fun talk, just to see someone who’s so passionate about what she does. In the end, sort of a call to arms to say that we can build robots without needs thousands of dollars, government backing, or hugely complex environments. “Get a PhD vs Get Started”. Her robot project is here and here are the slides.
Rebecca Murphey & Optimizing for Developer Happiness
Developer delight - the sooner devs want to switch to using your project and/or your ‘better’ internal code, the more money you can make as a company. So how do you make those devs want to switch? Slides
- Provide a path to get up to speed
- Provide points of entry for junior and senior dev
- Have few surprises
- Have isolated complexity
- Easy development and debugging
- Nothing more difficult that it should be
Use asssertions - we expect that X is Y at this point. in prod, these are no-ops
log the lifecycle - should not have to console.log to know what happened
- console.group and console.group.end
you learn the flow and know where something broke
- Eliminate tempation - don’t give people a place to make mistakes. ex - don’t give them a global var to shove stuff into
- Have code for every concept
- Automate everything. make an internal tool to get data in one click.
- Document the things code can’t tell you (how to make new feature, how to fix things, where to find things)
- Document the things you don’t want to (ex, things you agreed on when a small team)
- Put docs in the repo - if it talks about code, it goes with code.
- Measure progress
New framework tool from Facebook. Link. Note to self, I need to separate my dislike of Facebook from their tech.
- how do you structure things
- MVC, MVVM, MVW
- Model View Whatever
- Models are the common thing
- Observable models encourage mutation
- Anytime data changes, best thing to do is nuke the view and recreate
- When you models change, react figures out the smallest dom mutation and make it happen for you.
Erich Gamma & TypeScript