by sebastian de deyne
A short intro on my second series: Unix things I always forget!
An attempt to document the Unix commands I know and care about. Consider this series a living document that will grow organically; I won’t be updating or adding new posts on a set schedule.
ls features.Every now and then I need to bump a dependency in a package, or require a higher PHP version.
{
"name": "my/package",
"require": {
- "php": ">=7.2.0",
+ "php": ">=7.4.0",
- "league/commonmark": "^0.19",
+ "league/commonmark": "^1.0",
}
}
When updating an underlying dependency, I don’t always tag a new major version. Some people consider this to be a breaking change, but it isn’t. Here’s how to deal with dependency and language updates from a package maintainer’s perspective.
Reviewing pull requests, I often see contributors sneakily adding editor configuration to the repository’s .gitignore file.
composer.lock
package.lock
+ .vscode
If everyone would commit their environment-specific .gitignore rules, we’d have a long list to maintain! My repository doesn’t care about your editor configuration.
There’s a better solution to this: a personal, global .gitignore file for all your repositories. Here’s how you can set one up.
12 Mar 2020 via pjrvs.com
I’ve always had a hard time finding a proper response to the classic “privacy isn’t important because I have nothing to hide” argument.
Paul Jarvis, cofounder of the privacy-first analytics tool Fathom Analytics, makes some strong points in But I have nothing to hide.
Whether it’s on reality TV or even just social media, we act and speak differently because we know we are being watched. We lose our ability to be authentic or explore our own identity and views because we’re stuck trying to put forward our “best selves” and ensure everyone else that we’re here “for the right reasons”.
Read the full article on pjrvs.com.
I came across this post by Jason Fried (from Basecamp) about giving ideas a few minutes before shooting them down.
I’ve caught myself blurting out unnecessary negative opinions when presented with an idea. More often than not, I have more empathy towards the idea a few minutes later, and feel bad about my initial reaction.
Next time you hear something, or someone, talk about an idea, pitch an idea, or suggest an idea, give it five minutes. Think about it a little bit before pushing back, before saying it’s too hard or it’s too much work. Those things may be true, but there may be another truth in there too: It may be worth it.
Read Give it five minutes on signalvnoise.com.
In Selecting elements (part 1) we learned how to select elements from the DOM, and how to find elements inside other elements, both with our own $ and $$ helpers.
In part 2, we’re going to review two DOM element instance methods: closest and matches.
$ and $$, which are wrappers around document.querySelector and document.querySelectorAll.JavaScript frameworks are great, but overused. Adding small bits of interactivity to an interface shouldn’t mean installing kilobytes of dependencies or introducing complex build tools.
It’s time for a diet. I’m challenging you to build something without a framework, or follow along and learn something along the way.
Yee-haw, we released Mailcoach! Mailcoach is a self-hosted newsletter solution. My contributions were on the JavaScript side of things: I helped decide which tech stack to use, and implemented it.
After building apps with almost exclusively Vue and React the past few years, we decided to go with vanilla JavaScript for Mailcoach. There’s no frontend framework involved, but we’re pulling in some npm packages where needed.
I’m not going to dive into implementation details. I’m going to talk about why we decided on this stack and go in-depth on the structure of the application code, bundle sizes, and choosing external dependencies.
Dan Abramov shared a short post on some key principles the React team sticks to. Some solid general advice here, it’s not explicitly related to React.
Absorb the Complexity
Making React internals simple is not a goal. We are willing to make React internals complex if that complexity lets product developers keep their code easier to understand and modify.
Hacks, Then Idioms
We need to allow hacks using escape hatches, and observe which hacks people put in practice. Our job is to eventually provide an idiomatic solution for hacks that exist in the name of better user experience. Sometimes, a solution might take years. We prefer a flexible hack to entrenching a poor idiom.
These two stood out because they’re the opposite of how I generally need to think when building applications (although they make perfect sense in the context of something like a lower level framework). Either way, lots of food for thought in here.
Read all principles on overreacted.io.