- Clear feature ownership
- Module usage predictibility (refactoring, maintainence, you know what's shared, what's not, prevents accidental regressions, avoids huge directories of not-actually-reusable modules, etc)
These are my unstructured notes from the workshop. Read with caution (they're biased to my own interpretation).
1,000,000 Julian.com visitors Part 1: What's your objective for your article? Part 2: pair it with an objective objective + motivation good nonfiction = 70% novelty + 25% story + 5% style
This document is a guide to writing agile contracts. Unlike traditional contracts, an agile contract does not specify individual tasks to be completed by the Contractor. Rather, an agile contract specifies how the Client and Contractor interact, and how the Contractor is paid. The Deliverable Work performed for the contract is determined through an ongoing collaboration between the Client and the Contractor.
Agile contracts require a great deal of trust from both the Client and the Contractor. This trust is fostered through tight feedback cycles and well-defined responsibilities that both parties can expect from each other. More so than traditional contracts, an agile contract requires active participation from the Client.
Questions to ask potential employers
- How long do you expect it would take me to deploy my first change? To become productive? To understand the codebase?
- What's the longest tenure of a developer at this company?
- How long has the top quarter of the developers been here?
- What fraction of the developers have been here less than 6 months?
- How long does it take to do a complete deployment?
- How large are PRs? For a "big" PR, how many lines of code? How long is it open?
- How often do you have major outages? What constitutes a major outage for you?
- Do you have a defined process for the aftermath of an outage?
NOTE: Sokra confirmed I had a misunderstanding, Webpack is still a static build tool and the below won't work. It's still a nice concept though...
With webpack 1, code splitting react-router routes is quite tedious. It requires us to repeat the getComponent
function over and over again. (See here for an explanation how it works with webpack 1)
Example:
<Router history={history}>
<Route
path="/"
With the addition of ES modules, there's now no fewer than 24 ways to load your JS code: (inline|not inline) x (defer|no defer) x (async|no async) x (type=text/javascript | type=module | nomodule) -- and each of them is subtly different.
This document is a comparison of various ways the <script>
tags in HTML are processed depending on the attributes set.
If you ever wondered when to use inline <script async type="module">
and when <script nomodule defer src="...">
, you're in the good place!
Note that this article is about <script>
s inserted in the HTML; the behavior of <script>
s inserted at runtime is slightly different - see Deep dive into the murky waters of script loading by Jake Archibald (2013)
- By Edmond Lau
- Highly Recommended 👍
- http://www.theeffectiveengineer.com/
- They are the people who get things done. Effective Engineers produce results.
https://twitter.com/snookca/status/1073299331262889984?s=21
“In what way is JS any more maintainable than CSS? How does writing CSS in JS make it any more maintainable?”
Happy to chat about this. There’s an obvious disclaimer that there’s a cost to css-in-js solutions, but that cost is paid specifically for the benefits it brings; as such it’s useful for some usecases, and not meant as a replacement for all workflows.
(These conversations always get heated on twitter, so please believe that I’m here to converse, not to convince. In return, I promise to listen to you too and change my opinions; I’ve had mad respect for you for years and would consider your feedback a gift. Also, some of the stuff I’m writing might seem obvious to you; I’m not trying to tell you if all people of some of the details, but it might be useful to someone else who bumps into this who doesn’t have context)
So the big deal about css-in-js (cij) is selectors.
Building reusable UI components is a non trivial task, as we need to anticipate a number of things when planing for reuseability. On the one end of the spectrum we want to enable customization and on the other side we want to avoid developers doing the wrong thing, like breaking the component or displaying invalid states.
To get a better understanding of what we need to think about and consider upfront, we will build a non-trivial UI component, that displays tags. Our Tags
component will take care of managing and displaying tags.
The following examples are all built with Tachyons and React, but these ideas apply to any UI component and any general styling approach.