Aggressively popularized “best practices” often have a tendency of manifesting cargo cults around them, enticing developers to apply design patterns or use specific approaches without giving them a much needed second thought
Naming tests in accordance to specifications rather than classes has an additional advantage of removing that unnecessary coupling. Now, if we decide to rename SolarCalculator to something else or move it to a different directory, the test names won’t need to be updated to reflect that.
To summarize, we can conclude that it’s a good idea to partition tests based on threads of behavior, rather than the code’s internal structure.
The "write your code so it's easy to test" idea is silly. Write your code so it's easy to read. Test speed should barely be a consideration for your 200 line side project. Cypress tests are easy to read and actually test that stuff works. Test speed does become a factor eventyally, but worry about it then, rather than upfront.
Amazing write up, and clever outcome. Waist-level pockets are indeed stupid or poorly design most of the time, The reach/support diagram is a good illustration of the problem space
Great writeup, and fun to go through the questions and explanations. I really went off the rails with grep and parsing estimates, others were mostly solvable.
HN Discussion has people alternately arguing about whether modern programs are fast, or bloated and slow.
I don't think Moore's Law is an excuse to not worry about program performance, and the current slew of slow apps (web and otherwise) is not acceptable. Many electron apps really do feel slow. Waiting for my password manager to open (either electron app or chrome extension) is frustrating. It's minor, but it's friction to something that needs to be frictionless.
That isn't to say that can't be made fast. VSCode is a good example - that uses electron but has remainined very performant. They got boot up time down real low (actually relevant for me as I open/close sessions often). BUt on my older laptop (4gb RAM) I can't have it open alongside browser, so mostly use editors in the terminal. It does still mostly work, but they have focused on perf speed rather than footprint. Still some tradeoffs to be made there, and again another hard thing to think about.
There are definite costs to the abstractions, but also benefits. But none of this is free. Perf is hard, and computers being faster doesn't mean we don't have to think about it - time has been unchanged. Only our expectations have (of features and speed).
2 hours saving 10 seconds per file open twice a day is an egregious violation of the xkcd rule, but it was fun and I learned a lot about Vim automation in the process.
AND saved me 2 hours as I simply found this on google
I don’t foresee enough people paying for niche newsletters for this model to be feasible.
I don't know enough to have an opinion on this. People are quite cheap with written content, in particular for niche publications vs a newspaper/journal that publishes across a range. But there are also a lot of people on the internet, so who knows.
Instead, you should try to blend together the needed disciplines as best you can, consulting others when necessary, an offer the best plan you can, namely the best plan all things considered.
That might fill you with horror, but please recall from Tetlock that usually the generalists are the best predictors.
The high performance parts aren’t React. Mapbox GL, for example, is vanilla JavaScript and probably should be forever. The level of abstraction that React works on is too high, and the cost of using React - in payload, parse time, and so on - is too much for any company to include it as part of an SDK. Same with the Observable runtime, the juicy center of that product: it’s very performance-intensive and would barely benefit from a port.
The less interactive parts don’t benefit much from React. Listing pages, static pages, blogs - these things are increasingly built in React, but the benefits they accrue are extremely narrow. A lot of the optimizations we’re deploying to speed up these things, things like bundle splitting, server-side rendering, and prerendering, are triangulating what we had before the rise of React.
That squares with my experience of software development. It's like being a furniture maker but spending 80% of your time fixing your goddamn hammer because it keeps breaking and no better hammers exist, or consulting glue-drying tables because they keep changing your glue on you every hour or two and for no good reason every single glue performs differently while accomplishing the same thing.
Ive noticed some people use github almost like a social network. A rough analogy to Twitter would be that starring a repo is similar to liking a tweet, and forking it is almost like a retweet.
Love this term - this is exactly how I learn. Start by skipping over the details,
develop a coarse understanding, then refine your knowledge by learning about specific areas in more detail.
Interesting estimates and numbers - clientside savings really add up.
In fact, it is probably the most effective use of my time when it comes to reducing carbon dioxide emissions.
Just last week I reduced global emissions by an estimated 59.000 kg CO2 per month by removing a 20 kB JavaScript
dependency in Mailchimp for WordPress. There’s no way I can have that kind of effect in other areas of my life.
The problem with economic model of scarcity. More savings does not mean more spending - people eventually have enough cash and enough things; at this point they are taking more money out of the economy than putting back in.
Few other interesting ones in comments. I am terrified of the McCollough effect
However, Jones and Holding (1975) found that 15 minutes of induction, when time-elapse testing is employed, can lead to an effect lasting up to 2.8 months
A look at the music industry. You can't make money from album sales, or from touring. Either have to do it as a hobby or get into the merchandice game.
A walk through how fast different types of train can go, and why. Great balance of history and physics, detailed but without too much assumed knowledge.
I was hoping for a way to minimize margin left/right overrides, but sadly not. Bunch of other issues that come up with Arabic text - underlines, letter-spacing, opacity, font-weight, and others
watching/waiting for node deps to install almost causes me physical pain
You don’t have to be a genius to write fast programs. There’s no magic trick. The only thing required is not building on top of a huge pile of crap that modern toolchain is
We need solutions that are less terrible for the environment, but 'living in harmony with nature' is basically a fallacy; seeking that is longing for an age that never existed.
I had this exact same paper day schedule! Not exactly a groundbreaking discovery, but the half-hour blocks and height of the page are both great limitations
Honestly, skip all of the courses. Pick a problem to solve, start googling for common models that are used to solve the problem, then go on github, find code that solves that problem or a similar one
There is mixed consensus on this. But copy-pasting snippets to solve my problems is how I've learned to program so far; why should ML be any different.
Paper from 1989(!) looking at different methods people use to find information. There are six main categories, most online search continues to only use one or two
Very clever approach to estimating impact of self-driving cars. Interesting that budget limited a lot of the scope. Since this should be pretty important, but also that saving money is going to be a benefit of this!
Small sample size + novelty surely impacted the effect of a driver. Also that they can get out of the car and do stuff, whereas doing groceries or drycleaning you'd still need human intervention
Jot down snippets of observations/ideas in a single Google Docs document (available on almost any platform). Don't try to organize it. Keep it really simple. The key is to keep it low effort and frictionless.
Look over the Google Docs document from time to time. When you have enough ideas coalescing in a cluster/theme, feel them out. When the cluster feels like it's ready i.e. you feel an emotional connection to it, start writing. Important tip: don't feel you have to finish writing in one sitting -- you can stop, let your writing sit, and keep re-clustering until you have something that is worth putting out there.
Not everyone’s going to be my people, or each other’s people. No one in any group large enough is going to like everyone, or even be neutral to everyone— there’s gonna be some “get away from me” and strong dislike floating around, there are going to be divides. Pleasing every single person means being close to no one.
Insert more ads. Signal to noise goes down. Value to user shrinks. Value of user to advertisers decreases. Insert more ads. A vicious cycle that de-prioritizes the user experience.
Good strategy to minimize hindsight bias and try to improve quality of decisions. Interesting point from some interview: good decisions that have bad outcomes (due to chance) are better than bad decisions with good outcomes, as the latter reinforces bad decisions.
Accessibility won't work as an afterthought, it needs to be part of the process.
Making sites accessible makes them better for all users. Real-life example of this is curb-ramps.
Possible counterpoint: if the text doesn't render due to slow perf then readability is also affected.
Though only comparisons of text-rendering: optimizeSpeed; vs optimizeLegibility are from a while ago, unsure
if this is still a legit perf issue anyway.
Personal triggers are more persuasive that any other arguments or data. Future and far away people are harder to imagine than seeing change in a place you know. Image from ShowYourStripes is striking.
Soon after Adblock Radio gained some traction in 2016, I have received lawyer threats from French radio networks (more details below). I had to partially shut the website down, change its architecture, better understand the legal ramifications, etc
Tips from and case studies of using a few websites with a screenreader. TLDR make your markup valid and lightweight, keep headings in correct order, and add assistive tags.
