- Using Logs to Build Solid Data Infrastructure — (Martin Kleppmann) — For lack of a better term, I’m going to call this the problem of ‘data integration.’ With that, I really just mean ‘making sure that the data ends up in all the right places.’ Whenever a piece of data changes in one place, it needs to change correspondingly in all the other places where there is a copy or derivative of that data.
- TremulaJS — sweet carousel, with PHYSICS.
- Project Advice (Daniel Bachhuber) — for leaders of distributed teams. Focus on clearing blockers above all else. Because you’re working on an open source project with contributors across many timezones, average time to feedback will optimistically be six hours. More likely, it will be 24-48 hours. This slow feedback cycle can kill progress on pull requests. As a project maintainer, prioritize giving feedback, clearing blockers, and making decisions.
- YAGNI (Martin Fowler) — cost of build, cost of delay, cost of carry, cost of repair. Every product manager has felt these costs.
WebAssembly – wasm – skips that final step, producing a binary format, technically a compressed AST encoding. Unless you’re going to be building compilers, you can compare wasm to a bytecode system. There is a text format for debugging, but the binary emphasis yields substantial extra speed as it skips parsing and minimizes decompression.
Learning from the Fluent Conference.
At Fluent 2015, we brought together a variety of stories about front-end engineering – some technical, some social, some more intricately intertwined.
From the very first day, it was clear that React was the big technical story of the conference, taking the place that Angular (which is still clearly important!) had had the previous year. Tutorials and sessions were busy, and I kept hearing conversation about React. Sometimes it was “what is React supposed to do?” but other times people were talking about exciting corners of React Native or techniques for integrating React with a variety of frameworks.
React makes me happy because it solves the problem a lot of people didn’t quite realize they had. Suddenly they are very enthusiastic about stuff that used to be really annoying. The Document Object Model (DOM) has been the foundation of most of the interactive work on the web since 1998, but it wasn’t very much fun then. As developers really get deeper into these things, the DOM has not exactly been a crowd-pleaser. In some ways React is a wrapper for the DOM, and in many ways it’s a just a better way to interact with the document tree.
How much do you need to know?
I expected that CSSDevConf would be primarily a show about front-end work, focused on work in clients and specifically in browsers. I kept running into conversations, though, about the challenges of moving between the front and back end, the client and the server side. Some were from developers suddenly told that they had to become “full-stack developers” covering the whole spectrum, while others were from front-end engineers suddenly finding a flood of back-end developers tinkering with the client side of their applications. “Full-stack” isn’t always a cheerful story.
In the early days of the Web, “full-stack” was normal. While there were certainly people who focused on running web servers or designing sites as beautiful as the technology would allow, there were lots of webmasters who knew how to design a site, write HTML, manage a server, and maybe write some CGI code for early applications.
Even as the bust set in, specialization remained the trend because Web projects — especially on the server side — had grown far more complicated. They weren’t just a server and a few scripts, but a complete stack, including templates, logic, and usually a database. Whether you preferred the LAMP stack, a Microsoft ASP stack, or perhaps Java servlets and JSP, the server side rapidly became its own complex arena. Intranet development in particular exploded as a way to build server-based applications that could (cheaply) connect data sources to users on multiple platforms. Writing web apps was faster and cheaper than writing desktop apps, with more tolerance for platform variation.
An experiment in containing stylesheet complexity.
This post is part of my personal notes about the benefits currently specified in Shadow DOM, but contentious and held up in committee. We’ll work it out in standards, I’m sure — but given the number of things Shadow DOM was addressing, it may still be several years until we have solutions widely implemented and deployed that solve all of them. This has me doing a lot of thought exercises about what can be done in the meantime. The following reflects one such exercise: specifically, what would it mean to solve just the styling end of this on its own. Warning: it may be mildly crazy.
The Pandora Box
CSS works really well if you can follow good patterns and have nice rich markup. It lets you define broad rules and inherit and override selectively, and if used well it cleanly decouples a separation of concerns — it’s pretty elegant actually.
On the other hand, in the real world, things are often not that simple: until pretty recently, HTML wasn’t especially expressive natively, so we worked around it — many times on our own by adding classes like “article.” But, there wasn’t a standard. Likewise, our ideas about the patterns we should follow or best practices continues to change as we gain new powers or spend more time with the technology. Of course, there are a vast number of cases where you’ll just go and upgrade your philosophy and be the better for it, but there are a number of times when this just isn’t an option. This is sometimes referred to in standards circles, less colorfully, as “the composition problem.”
When it comes to these sorts of cases, quality and philosophy are inevitably mixed and not entirely in the control of any one team. In these sorts of cases, CSS selectors are kind of like live hand grenades, it’s just way too easy to do damage you didn’t intend to do because it requires a level of coordination of approach which is, for business reasons, highly impractical. And so you try really hard to analyze the problem, get the right select/cascade/descend/inherit/specificity, pull the pin, lob it into the pages and… hope. Frequently, all hell breaks loose. The more you mix it up, the harder it gets to reason about and the more our stylesheets explode in complexity. You’ve opened the proverbial Pandora’s Box.
Khan Academy explores how far learners can get at different ages.
I picked up a brief guide to programming in 6th grade. There, on page 1, was A = A + 1. I knew that wasn’t possible, so I put it down, and came back to programming in 7th grade.
Khan Academy is having better luck with young students, but learning to program is kind of like learning to drive: the prerequisites aren’t obvious, but they’re helpful and often come later. At Fluent 2014, Pamela Fox explored the data Khan Academy has collected on learner age, and what it might mean for curricula going forward.
In her keynote, Fox explored:
- Developing a sense of how kids respond to fairly easy challenges with Khan Academy’s participant data. (3:24)
- What in the first programming challenge might keep people from succeeding? (4:37)
- How different is the data for a logic challenge? At what age does completion level off? (6:16)