Personal preference is valid only to an extent. At a certain point, with enough scale/team size/complexity TypeScript becomes invaluable. I've worked on projects that would have been intractable without TypeScript.
This is a huge problem with front-end. Too many people who don't know what they don't know, and think their use case is the only one.
Unsure if mentioned already, but I keep a repository of all my Linux configuration files. I have scripts that link them all out to the correct places. Then for almost any tweak I make, I script it into a massive install.sh script I maintain. Now I'm at a point where I can set up a 98% perfectly customized machine with a sequence of `./install.sh some_scripted_setting` calls. All this takes effort and care, but well worth it to me. And since it's all my scripting, I know exactly what's going on.
It's quite tough to do that for Windows (which I partially do). Ultimately I keep a list of the stuff I need to do and manually do a lot of it.
An alternative which I have dabbled with is basing your config in VMs. Keep stable backups of them. That way the host OS is not important, and just re-use the VMs if you switch hosts. QubesOS is what really opened my eyes to this. Of course this is really only useful for particular workflows probably more development oriented, and at some point you'll want to update them/start fresh.
I do the same thing, and I make sure that the install.sh file can be re-run without breaking things. Then if I want to make a permanent change, or add a new package that I will want to keep, I just updated install.sh and re-run it so I know it works and is up to date. Pretty fragile, but I would rather spend a few minutes fixing any errors whenever I run it on a updated OS then take the time to make it more robust.
I found Stripe usage quite complicated. It felt like they were handling very complex use cases at the expense of simpler ones (which are probably the majority).
It's one of those things where once you're already "in the know", the simple use cases are in fact simple to implement. But sifting through the massive and complex API set, with outdated and partial documentation/examples all over the internet, it's very difficult to get into. Every single example starts with "this is not production ready..." And the official docs are difficult to piece together into an "E2E best practices" setup.
Not saying there is a better solution, just that as a competent dev with a simple use case, I found Stripe overly complex.
We are currently working on a new version of our Checkout product[0] and would love feedback. We are working on making the simplest drop-in integration to get up and running on Stripe, and we support Stripe Billing! Send me any thoughts you have (matt at stripe).
There are so many smaller open source projects I would love to donate to but don't accept donations. I would even pay subscription to them if it ensures their continued development.
Agree with you fully. People take these blanket generalizations and make them rules and then use them to ignorantly judge someone's decisions. I've worked on projects where performance needed to be addressed up front or else it just wasn't viable.
On the flip side, after using CSS in large projects for years with many, many third party libraries, I've never once felt this urge... Rarely had any problems. At least none that the effort of styling everything in JS would merit!
He forges art, nets 100m+ euros, goes to prison for 3 years. I spend 40 years at a job I'd rather not be at, lucky to retire with 1m+ euros. Leaves a sour taste.
You can still pick up a brush. 3 years in prison is nothing to sneeze at. It's a matter of ethics, after all, if all you want to look at is the eventual outcome we could all be bank robbers but most people prefer another life.
Not trying to play word games, but what is the difference between answering a question and processing data? Aren't they effectively the same?
Using another tool for processing data often results in recreating SQL mechanics at application level. E.g. select this data, retrieve it, loop and if this, then set that, etc. SQL does it way better, guaranteed.
Of course that's often required for technical reasons (scalability etc.) or processing that's too complex to implement at data layer, or just for cleaner design.
«what is the difference between answering a question and processing data? Aren't they effectively the same?»
I think it influences the mindset of the developer. As you say, “retrieve ... if this, then ... loop”. If you're in a “data processing” mindset, then you'll think of a problem like “Get the total number of car widgets in the warehouse” as fetch a widget row; if it's of type car, add number to total; loop until you've processed every row; there you have your total. If, OTOH, you're in an “asking questions” mindset, you'll go: What was the question again, exactly? Oh yes, get the sum of the number for all the widgets which are of type car widgets. Which is almost exactly the same as SELECT SUM(NUMBER) FROM WIDGET WHERE TYPE = 'CAR';.
Processing data is when you do it (in code); answering questions is when the RDBMS (i.e, its code) does it for you. :-)
(At least that's what I think the difference is _in terms of vvkumar's original question._)
Agreed that SQL is amazing at processing data! I would argue that a lot of people are trying to both process their data _and_ ask a question of it in the same statement. Separating those out is really important to make analytics more scalable.
We do >95% of our transformations with pure SQL and the queries are primarily in Looker.
I used to think this too, and wondered what magical SQL perspective my brain was missing. I'd see these elegant but seemingly impenetrable queries and wonder why my brain wasn't in the "SQL dimension" yet.
But over time, and very heavy SQL reporting, I realized the procedural mindset still applies, it's just not expressed as such.
You need to think through the steps of how you want to retrieve, transform, aggregate etc. the data and build up the query to accomplish those steps. The resulting query doesn't look procedural, but the thought process was. Of course you need to know the sometimes opaque constructs/tricks/syntax to express the steps, which again, look like magic at face value or just reading docs.
I think this is why people struggle with understanding SQL. The thought process is still procedural, but the query isn't. You need to translate the query back into procedural terms for your own understanding, which is a PITA.
Yes, that's what I'm saying. The difficulty people have is that the thought process (solution) is still procedural but the query is expressed declaratively. Once you learn how to navigate that gap you get good at SQL.
This is a huge problem with front-end. Too many people who don't know what they don't know, and think their use case is the only one.