844 karma · joined February 24, 2021
The issue for me is when commit who are about adding a new value in the env file become mixed with template and responsive handling, mixed potentially with a bug fix.
It's okay to have 'low information' commits one can easily ignore in your history, as long as the 'high information' ones stay readable and coherent.
EDIT: On top of that, there's usually a bit of 'related' work you need for a task, by example when you find an edge case related to your feature, and now you also needed to fix a bug, or you did a bit of refactoring on a related service, or needed to change the data on a badly formatted JSON file.
Unbeknownst to you, you added a bug when refactoring the related service, a bug that is spotted a few months after, only on a very specific edge case. If the cause is not obvious, you might want to reach for git bisect, but that won't be very useful now that everything I've talked about is squashed into a single commit.
If you need to do a workaround, or a complicated feature sometime it's nice to explain it as a comment in the code, but sometime it's better to put it as a comment inside the commit message. But if it's all merged i the end, along with lots of template changes, README changes, refactor irrelevant to the current changes, then you're losing an important way of navigating a codebase.
I'm a big proponent of rebase and squash if it helps to make a commit more coherent, but we use squash merges by default in the current project I'm working on, and I die a little bit each time I try to understand what changes were related to a line when tracking down a bug.
As a front-end dev who actually like the fundamental platform and the capacities it offers, I'm both happy to see so much nice things coming our way (nested CSS, container queries, and a generally nicer JS experience since ES6) and at the same time horrified by the amount of people using components for trivial things like buttons or bold text.
And I do like framework, but so much framework and library's marketing depend on making people believe that CSS and vanilla DOM manipulation is insanely hard (it's not once you know the fundamentals), and that pulling a random package on NPM is not just quick and easy, but also the professional thing to do.
To be fair, Troy was also mostly thought to be mystical before Heinrich Schliemann went on a quest to find it (and subsequently destroyed most of it as he used explosives to perform archeological digs).
I love etymology in general, but don't fall into the trap of thinking that the origin of a word or an expression is the only correct meaning.
Just like the article, his reasoning is that if you improve performance too much, it makes management/the team look bad for not doing it before, while a smaller improvement in performance make management looks good.
In an incredible act of chutzpah , he invented a whole country along a fictional city of St Joseph, serving as capital, he printed dollar notes from the "Bank of Poyais", forged geographical data, wrote book about it under a fake name.
His scam resulted in a stock market crash in 1825, and the death of at least 180 peoples out or 250 colonists who expected to settle in St Joseph, but instead arrived to Belize.
Yes, it's verbose, but its advantages over Typescript is that it work without any compilation step, while being standard enough to give helpful type-hint on any good enough IDE.
Of course, if your project uses Typescript already, you should use Typescript instead, but if you just want to do a simple web page without any compilation step/package.json shenanigan, it's sometime nice to reach for JSDoc.
EDIT: to answer your question, in JSDoc you can typedef your own custom objects[0], so you thankfully don't have to repeat your types everywhere.
It's about psychological studies of morality, and what tends to influence one sense of morality.
It had a huge impact on me because I feel that it helped me grow as a person, and being able to understand other culture/other principle, even if I don't necessarily agree with that.
Lots of stuff that seems plain evil from a western point of view (ergo, centered about the morals of individuality) would look more sensible once understood from a moral coming from a sense of community, and the necessarily conservative need to foster a stable societal structure.
It doesn't mean that I agree with things like opposing the rights of woman to drive/open bank account, but it help understanding the motivation better.
Another interesting point he brings is the differentiation between a moral judgement (X is good or bad), and the moral reasoning (X is bad because of Y and Z). Notably, the moral judgement come before the moral reasoning, the latter being used not as a way to reach a conclusion, but as a way to defend a moral judgement with our peers.
Jonathan Haidt is mostly known for his works on the political polarization of the USA.
Another book I found incredibly enriching (but unfortunately only in French) is "Au coeur des services spéciaux", which is an interview by Jean Guisnel (a french investigative journalist) of Alain Chouet, a former director of the DGSE (the french CIA basically).
Alain Chouet studied Arabic and the arab/muslim world even before joining the DGSE, and what I picked up at the bookstore as a way to understand the french intelligence services turned out to be an extremely interesting (and respectful) exposé of the muslim and arab world, with the prism of political Islam, the history of terrorism as seen by french intelligence service, his opinion on many nuclear programs, and of course a great deal about 9/11.
The writing of the book is very fresh thanks to the conversational/interview style used, and while the book show its age more and more (it's from 2013), I still believe it's a worthwhile lecture if one is curious about such subject, especially given the current context.
In the same spirit (but for another reason), the famous "Van Halen brown M&Ms clause" [1], which served as a proxy for how likely the venue also read & complied with the safety precautions for the concert.
[1] https://businessofsoftware.org/2013/08/the-truth-about-van-h...
And yeah, it was because of Snap.
I believe it's mostly due to the fact that CSS, just like SQL, is one of those technology approachable enough to fiddle with it and get somewhat far, while not really learning it, and thus overlooking the fundamentals.
> None of the frameworks I know of do that.
I would squarely put into this category all the CSS-in-JS frameworks, such as 'styled components'. Also everything that markets the 'cascading' part of CSS as being a mistake.
Also, all the frameworks that compiles CSS without generating the CSS sourcemaps, making the debugging experience way less efficient since all the applied CSS rules shows under '<style>' (eg: 'styled-components' again, who discarded it as being 'cosmetic' in the related Github issue).
Truth is I've been spoiled on that front because I had the luck to work for many year in a company where the CTO was a very talented dude who lived and breathed HTML/CSS since the mid-2000's, and who was quite thoughtful about that kind of stuff, so I had a first-hand experience of a good codebase, mostly by avoiding external dependencies, using the standard browser behavior, and frequently consulting the MDN.
This is why it's a bit disheartening to see so many front-end framework working against the plateform, even even marketing against it, while CSS and browser tooling his so much more enjoyable and powerful than before.
I think I understand tailwind, but like the parent poster I'm really not a fan, because while CSS can be a footgun, it can also be quite clean when you use a sane DOM structure, CSS variables, and well thought out CSS selectors.
I've been on a project like that, and the result was maddening: any page or component template would contain only references to other components and almost no plain HTML tag.
Each time you encountered something like a 'Title' or a 'Button' or a 'FooBarHeader' component, you didn't knew how much Javascript was executed behind each of those, or wether it had any side effects until you looked at the code (and sometime had nasty surprise on components used everywhere).
You also either had to look at its API or modify it to correctly use the web plateform (eg: how do I specify to my 'Button' is of type="button" or of type="submit" ? How do I add some aria attributes ? What if I want to add a 'data' attribute ?).
On top of that, the generated, runtime DOM would look nothing like the design-time template you are changing, which goes against the plateform, again.
And you also ended up with a huge 'components' surface, where this moderately complex (in term of essential complexity) had more than a hundred components, with some basic 'Button' component being monstruous 500+ lines of code under the hood (because of CSS-in-JS), all of it destroying the performance of the page.
On this particular project, I realized that the tag-to-component ratio was less than 1, even maybe closer to 0 than 1. In other words, behind each little <span> visible in the inspector, you had something like 3 to 5 component instances. I've called it "loosing your footing", as you couldn't touch any primitive, drowning in a sea of abstraction.
Somehow, I feel that it's more specific to the 'React' world which is a bit too trigger happy when it come to creating new component.