> 3. Solve the generic problem not the specific one.
It's good that you provided the example...
> i could write a program that reads a csv row by row, converts it to my internal model, then emits those data into a ndjson file. Or I could just write a program that converts csv to ndjson , agnostic of the data. The former costs you every time the model changes. The latter is useful for a variety of system architectures again in the future.
...because in this case I can agree (although I'd need to drill into the details a bit more). Anyway, far more commonly (in my experience) unnecessary effort is spent on making generic code when a solution only targeting the specific problem in hand would suffice. Then later the requirements change or your original assumptions turned out to be wrong, and you need to spend time changing the generic solution to fit the new problem. This can require 10x the effort vs. just continuing from the specific and simple solution.
I guess the difficult art is to be able to recognize those exceptions where it is in fact reasonable to do the extra work for the generic solution. There was a recent submission [1] here about "YAGNI exceptions" which included a few common cases.
I think most podcasts post the exact same episodes to all popular platforms. Some may have an ad-free version on Patreon.
With Spotify, it's sort of similar to when the paid YouTube (Red/Premium) became a thing. Yea, you'd get rid of the Google-picked ads, but the in-video sponsored ads added by the video creator would still obviously remain.
Well, Spotify does some of that as far as I know. But I'd never switch to playing my podcasts there just out of principle (even though I pay the subscription too) because I don't like how they are trying to build a walled garden for podcasts and kill RSS as a thing.
That's how Git submodules [1] show up on GitHub. I didn't actually know the project was using them. Interesting. As far as I know, this is an ideal use case for submodules, yet at least I've rarely encountered them in the web dev scene for some reason (well, IIRC there are some gotchas).
The components look really good but I don't quite get why the instructions make you create a new Next.js app? I understood this would work in any React app/framework and doesn't have any opinions on server-side rendering etc.
Bad timing on the New page, I guess. Also, after posting, a couple of days later I realized there was already another PWA for this [1]. I'm glad I didn't find it earlier though so I wasn't discouraged to build my own. I'm glad my implementation handles a certain edge case better I realized: sharing from Spotify doesn't result in a `"null"` title but `""` instead.
I don't fully understand how this is supposed to be an alternative to Tailwind while not providing utility classes out of the box? Did I miss something in the docs?
To me the biggest benefit of Tailwind, apart from the great base design system, is not needing to come up with class names for 99% of the things in the app. This is of course only possible when you have some way to abstract components out of the reused parts of your markup – e.g. you're using React.
Edit: The title was "Open Props: Tailwind Alternative from Chrome Dev Team" when I posted this comment.
The same. Although, you would think GitHub had the resources to keep maintaining this page even for just public image purposes among the power users / enthusiast who maybe care more. Seems like they are tuning town the social media aspect in their marketing too.
My assumption was always that, from the get-go, iPhone just had that much of a bigger market share in the US compared to e.g. Europe. I remember in Finland in the early 2010s most of the people in my age group (~20-25 years old) had Android phones while I've understood in the US I'd been in the majority. Not suprising that that situation lead to different networking effects in the US vs elsewhere.
Nope, sorry mate. It was a long time ago. I did find [1] which seems similar-ish (I have no idea what "w3resource" is) but I think our schema back then had a lot more tables and the questions were a bit more diverse.
Learning SQL early on in uni. I attended a course where you passed the course if you completed a certain percentage of the home exercises on a web platform. They were just tons and tons of different kinds of SQL pickles against a fake corporation Postgres database, probably more complex than you'd ever need in an average CRUD app project. This was very useful in my first job were I had to make sense of a weird legacy data platform built on top of MSSQL but also later on in basically any project ever involving a relational DB.
Git somes to mind too, where it changed the way I think about how to do the day-to-day writing of my code and that the knowledge is very transferable across all kinds of projects.
I wish it was 60 fps though. At some point the footage was probably deinterlaced by discarding every other field. (Also, YouTube would not show it as 60 fps anyways as the resolution must be upscaled to at least 720p for the 60 fps option to be available.)
I understand this is very typical with online video. I wish it wasn't though.