I'll be upfront, I have slacked and should have sent this report about 2
months ago.

*TL;DR - If you don't have time/inclination to read this, go to the bottom,
open link 7, register, and watch.*
In mid-July, I went to the FullStack conference here in London [1]. It's a
3-day affair that focuses on JavaScript, Node and IoT. Most schedule blocks
have 5 tracks. It was exhausting. Reading this might be nearly as

The sessions were a mixture of talks and workshops, a surprising amount of
of nitty-gritty "let's build something." The hot technical topics were
Progressive Web Apps (PWAs) and Redux. My favorite technical session was
about numeric computing with Node and JavaScript. My favorite overall
sessions were less technical and instead focused on process, knowing
yourself, and staying sane as a developer.

All the sessions were recorded and can be accessed from the site.

Here's a rundown of my personal highlights.

*Day 1*

*Opening - Progressing JavaScript and Apps the Web way (Chris Heilmann)*
Chris has a way of being controversial, sometimes I feel like he's
controversial just to be controversial, sometimes he's trying to start a
conversation. From the title, I wasn't sure which this would be, luckily he
was trying to start a conversation. Chris used the recent Brexit events as
a background to make the case on how the Web can and should win over Native
for the majority of apps.

For years, we as web devs have rushed headlong to emulate native apps.
Chris believes we should stop trying to emulate native, and instead play to
the web's strengths and co-opt only the best of native. The explosion of
DOM APIs and JavaScript libraries hasn't actually served anybody very well,
has made developers tired of churn ("developing for the web feels like a
burden"), and has made user's lives less private and secure. Native apps
can be worse because there isn't even any transparency into what the app is
doing. His point is good progress = transparency + technology + ethics +
accessibility. With PWAs, the web has a chance to break the native app
distribution model, with native-like performance and features, but with
transparency and accessibility.

*JSON Schema: More than just data validation (Jason Ian Green)*

JSON schema [2] is a platform and language independent data validation
standard [3]. I wanted to see if JSON Schema provided any advantages over
our two core validators JOI and VAT.

Speakers cases for JSON schema:

   - It's declarative
   - Covers most schenarios
   - It's mature
   - You write JSON and it validates itself.
   - Transportable (it's text, so not tied to any language)
   - Easy to manage in the build phase.

Beyond validation - since the schema is text, can be parsed and used for
all kinds of purposes

   - Generate test data
   - Generate realistic test cases
   - Accurate load testing
   - Populating dev or integration environments with pre-populated data.

My takeaway was that VAT and JOI work well and do a lot of what is possible
with JSON-schema, but our solutions lack the portability and generation
capabilities of JSON schema. We cannot easily take our VAT or JOI schemas,
extract those, and create fake data. I suppose we could extract the schemas
and write our own parser/generator. I have often wanted automatic data
generation capabilities so we can create robust fuzz tests that push the
front end using selenium and ensure invalid input is handles as we expect.

*Ember is an SDK for the web (Yehuda Katz)*

I've never used Ember so I don't have any opinion on it. To me the talk had
a mood that I also heard from an Angular dev - "Yes, react took the world
by storm, but we are still innovating and still relevant."
The big takeaway was that ember has a 3 phase load to minimize load time:

1) HTML/critical CSS only
2) Critical JS
3) Other JS/CSS

Step one puts something in front of the user ASAP. All rendering is done
server side. Only necessary CSS is needed. If JS on the client is needed
for rendering, that breaks the model and hurts performance.

Step two adds behaviors to the HTML. Step 3 pulls in JS/CSS/templates
necessary to create an SPA.

You'll see parts of this model applied to the content server soon.

*Surviving Web Security (Gergely Nemeth)*

Luckily, mostly stuff we are already doing, but there were a few things I
was surprised about, like how careful you have to be with using RegExp in
node when running the regexp against untrusted input.

The new information for me was how to model attack vectors using attack
trees [4]. Attack trees remind me of a quote I read last year "attackers
think in graphs, defenders think in lists." If we can model most possible
attacks using graphs/trees, we can then turn the knowledge into a robust
set of defenses.

*Developing for the Unknown (Ashley Nolan)*
Ashley works for Let's Eat, he came on a couple of years ago into a huge,
messy code-base. As our project matures, I found myself nodding in
agreement with most of the argument Ashley made. "We view legacy code as
bad, but it doesn't have to be. Legacy is something that that we are
creating right now." Ashley spent the remainder of the talk about
attempting to develop for the future, and what that means.

"We don't really know what will happen in the future, that means we have to
make reasonable, sensible, *documented* decisions, and make code easy to
delete." He spent a lot of time talking about the importance of sharing
workflows, processes, and tooling across different parts of the project.
Our team is good with the workflow and process aspects, but we need
improvement with tooling. Hapi vs Express, mocha vs tap are just two
examples. Mozilla-wide, we have an even bigger problem, it seems no two
teams use the same technologies, making code-sharing almost impossible and
jumping between teams more difficult than it needs to be.

Finally, like Chris, Ashley warned us to beware of the hype. Lots of hype
doesn't mean the project will stand the test of time. Whatever we build
should be built to last.

*Day 2*

*Dev interviews - You're doing it wrong (Guy Nesher)*
This was one of my favorite talks, I think because I find giving technical
interviews nearly as frustrating as being interviewed. Guy went through a
lot of the techniques commonly used in technical interviewed and made a
case for why many of them are little more than BS and interviewer ego

His gripes on various techniques used to determine whether a candidate is
technically competent:

   - On the spot CS knowledge.
   - It's good to have a foundation, but really, once we have the
      foundation, do we have to have the minutia memorized? That's
what a large,
      always-available repository of global knowledge is good for.
   - The slightly insulting/simple questions
   - bubble sort, linked list in JS
   - The ridiculously hard algorithms questions
   - The 8 queens problem
   - Anything from "cracking the coding interview"
   - The obscure
      - Library specific edge cases
   - Anything with a whiteboard
      - There's a reason we don't code on whiteboards to begin with. It's
      not natural. Programs don't run.

His suggestion is to let users do take home problems. Hooray, we do that.
Another approach he has seen work is to play 30 minutes of a board game, in
a neutral place.

He also suggested structured interviews, where each person plays a role,
and if interviewing multiple candidates, each interviewer uses the same set
of questions to avoid bias.

*Workshop: Interactive numeric computing with Node.js and JavaScript (Athan
This was my favorite technical session of the entire conference. It was a 3
hour workshop on statistics and machine learning in JavaScript. I took very
few notes because I was too busy hacking away. Athan's claim is that by
being smart and knowing the limitations of the language, it is possible to
do hefty math and achieve near native performance in JS. A lot of examples
in [5].

*Day 3*

*7 Habits of Highly Ineffective Developers  (Kitson P. Kelly)*
This was my favorite session overall. Kitson played on the popular book
title to talk about some of the anti-patterns that are common amongst the
developer community.

   1. Fear of missing out (FOMO)
      - Fear of regret, not using the latest toolkit, best project, of
      being left behind.
      - Solution: CALM DOWN! If you have problem solving skills, you'llb e
      better off than knowing the newest framework. Don't fear change.
   2. "Ergo a blog legere" (I read a blog, so...)
      - "lots of people are using X"
      - "Hooli built Y..."
      - "Exciting news! XXX is now one of the top ten most-starred projects
      on GitHub!"
      - Solution: Ask, "What problem are we really trying to solve?" and
      "What's the long term cost of this new thing?"
   3. "Because management says..."
      - Absolving responsibility because "someone made me do it."
      - There are right and wrong ways to land a message.
      - (Most) people don't get up in the morning to do a crappy job.
      - Solution: Take responsibility for yourself. You always have a
      4. Fallacy of Composition
      - Bad inductive reasoning - sometimes things don't generalize.
      - "I'm going to stand up at the concert to get a better view" says
      *everyone* at the concert and we all end up back at the start.
   5. The expert beginner
      - Someone who makes a career out of being semi-competent and never
      mastering anything.
      - See the Dryfus model of skill acquisition [6]
      - Experts often say "it depends."
      - Advanced beginners overestimate their abilities and cause big
      - Solution: Recognize it in yourself and others. Try to help others
      out of it.
   6. Un-self-aware
      - Constantly defensive
      - Must micromanage
      - Make excuses
      - "You have been called a bully more than once"
      - "You're in denial."
   7. Actively disengaged
      - Not only unhappy, they have a halo of melancholy that affect others.
      - May be prone to actively undermining others.
      - Solution: *Do you and everyone around you a favor and go do
      something else!*
      - Sometimes just need a kick in the butt.

*Closing: The things that I like are superior to the things that you like
(Mark Rendle)*

If there is only one talk you can watch, watch this [7]. It's a very
humorous standup-like routine about cognitive biases of all sorts. It was

[1] - https://skillsmatter.com/conferences/7278-fullstack-
[2] - http://json-schema.org/
[3] - https://tools.ietf.org/html/draft-zyp-json-schema-04
[4] - https://en.wikipedia.org/wiki/Attack_tree
[5] - https://github.com/stdlib-js/stdlib/tree/develop
[6] - https://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition
[7] -
Dev-fxacct mailing list

Reply via email to