On 21/09/2016 06:29, Shane Tomlinson wrote:
> Heyo!
> I'll be upfront, I have slacked and should have sent this report about 2
> months ago.

It was worth waiting for ;-)

Thanks for such a detailed report Shane!  Sounds like I've got a lot of
video-watching in my near future.



> *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
> exhausting.
> 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 stroking.
> His gripes on various techniques used to determine whether a candidate
> is technically competent:
>   * On the spot CS knowledge.
>       o 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
>       o bubble sort, linked list in JS
>   * The ridiculously hard algorithms questions
>       o The 8 queens problem
>   * Anything from "cracking the coding interview"
>   * The obscure
>       o Library specific edge cases
>   * Anything with a whiteboard
>       o 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 Reines)
> *
> 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
>         choice.
>  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
>         problems.
>       * 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 awesome.
> Shane*
> *
> [1] -
> https://skillsmatter.com/conferences/7278-fullstack-2016-the-conference-on-javascript-node-and-internet-of-things
> <https://skillsmatter.com/conferences/7278-fullstack-2016-the-conference-on-javascript-node-and-internet-of-things>
> [2] - http://json-schema.org/
> [3] - https://tools.ietf.org/html/draft-zyp-json-schema-04
> <https://tools.ietf.org/html/draft-zyp-json-schema-04>
> [4] - https://en.wikipedia.org/wiki/Attack_tree
> <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] -
> https://skillsmatter.com/skillscasts/7363-the-things-that-i-like-are-superior-to-the-things-that-you-like
> _______________________________________________
> Dev-fxacct mailing list
> Dev-fxacct@mozilla.org
> https://mail.mozilla.org/listinfo/dev-fxacct
Dev-fxacct mailing list

Reply via email to