Hope you didn’t eat too much at lunch. Stay awake for the first part of the CascadiaJS Server Day afternoon.
Rebecca Murphey: Deploying Client-Side Apps, 1,000 at a Time
A talk about how we’re rethinking the systems we build and deploy client-side web application at her work specifically (not a how-to talk).
Does ratings & reviews, single page app that runs inside other pages. Common code base, one build per site/locale combo.
Lots of sites, lots of locales.
Currently we have servers that just sit and wait to be told they need to do a build, and paying for that, and when they do, it’s a bunch of grunt tasks.
- no clear contract between steps
- primitive, blocking retries
- builds are lot for most failures
- no demand-based scaling of resources
- limited observability overall
The worst part is that have a team of people who feel like they cannot do anything with it or touch it at all.
Any build is basically a set of steps, units of work, ideally producing some output.
orchestration: the automated arrangement, coordination, and management of complex computer systems, middleware and services.
Amazon SWF listens to decider, activities listening for SWF.
pontiac: a tool for describing and performaing a workflow, using SWF, where a workflow consists of a set of steps, info about the input, info about ideal duraction and concurrency of steps, strategy for retrying failed steps.
Creates decider and activities for you.
chopper: receive build message, fetch locales, create new messages, which to delete.
Step authors don’t need to think about the system as a whole, just the one step, so easily testable.
Pros and Cons
- size of step output is limited and must be a string, so have to store large or binary data
- no guarantee that steps will run on the same machine, can’t rely on filesystem (on the other hand, much more flexibility)
- retries, concurrency are first class
- clear contract between steps
- framework abstracts known complexities
- adding a step is exactly as hard as writing the step itself, no harder; can be shared across builds
- tools are easy to abuse
- identify and abstract common complexity
- write all code as testable modules
- there is great power in convention
- smart people have already solved at least part of your problem, go talk to them
Potch: Scratch That Itch – Node on the command line for fun and profit
Get easily distracted from coding when looking something up online.
If it’s something you look up a lot, then consider creating a shell script to help you.
Do One Thing Well
Code something to replace a part of your brain. In particular, node has a ton of packages to do things. NPM makes it reall easy to build these things.
The process module gives you access for basic interactivity.
The goal isn’t to build a thing that works for everyone, but it’s just for yourself.
Example: checking flight status. Node has http.get or request module to grab page, cheerio for jQuery on server side. CHALK = colour module. Print to console.
Scraping is API 0.
Example: a9r on npm
Figure out a little contain piece of what you want to build and make it happen.
Donovan Buck: These Bots are Made for Walkin’
This talk is mostly about Johnny 5. It has moved way more than blinking LEDs. Actually pretty easy, and fun to do.
Walking is hard!
Has to maintain balance. Went with static gait. Many servo pieces. Tibia, Femur, Coxa. Not as simple has putting the end effector on the ground.
Must move all three joints in concert. It’s a lot of things that need to be coordinated.
Need to work about 30 FPS to look smooth, 6 legs, 18 servos, that’s 540 commands every second.
Used the Animation() function, a few lines of code in JS can create an animation, which can execute a short, repeatable movement.
But we don’t just want a fancy toy. We want it to be responsive to the environment and be aware. So it needs to be dealing with 3D points in space.
Use module called Tharp. Can move on all three axes. Actually incredibly responsive at 60 FPS.
Check out Johnny Five