It really depends on the code. To find a CSS bug, yes easy peasy. To find a logic hole in a payment integration of what someone has missed or should have implemented but didn't (eg webhooks), then this requires a lot more time and the developer basically has to sit down properly to work out exactly what should have been implemented / how they would have developed it, and then cross-check it against what has been done, otherwise you won't be able to easily find those logical holes which effectively are bugs, just not simple code bugs like a missing semicolon.
I'm not sure code reviews hold much merit. I've been a web developer for around 12 years and I've worked in companies big and small.
I think there should be a manual QA process to test the functionality of what the developer is pushing out.
The issue with code reviews is always that they take so much time for another developer and many devs are super busy so they just have a quick review of the PR and approve or feel they have to add some comments. Context switching between what the dev is already doing and having to come to the PR to review properly means they should switch to that Git branch, pull down the code, test it all and check for logical bugs that a static code review won't pick up.
For juniors, code reviews are still useful as you will be able to spot poor quality code, but for seniors, not as much for the reasons above, better off having a QA process to find and logic holes rather than expecting devs to invest so much time in context switching.
The problem here is not that developers are too busy, but that code reviews are considered second class citizens to churning out new code. It's like saying "many devs are super busy working on feature A so they just write quick and dirty code for feature B". If reviews are integral part of feature production pipeline, there should be no issue to sit down and spend a day reviewing code. For bigger, more complex things it could be a few rounds of reviews.
There is an approximate non linear relationship between time it takes to produce the first PR and time it takes to go through all rounds of review. This time can be pretty reliably calculated and taken into account.
Nah, automated testing cover basic functionality. For most PRs, a senior familiar with the code wouldn’t need to check it out and manually test anything, that’s not what “code review” is most of the time. If you need them to look at the code in a running state, that should be part of the CI process, not a manual task for the developer.
A good reviewer can call out bad strategic coding decisions or misinterpretations of the requirements. QA is another layer of review entirely.
Honestly sounds like correlation vs causation. I doubt doubt Elixir is amazing - it is. But maybe the old code was just written poorly from a performance perspective, and then they rewrote it, and now it's performant.
Interesting to see what the Government will focus their time on. Obama outrightly said recently that it's clear that a significant portion of the US (and outside of - namely Australia and the UK) is essentially mind-controlled by Murdoch Press through fear mongering and extreme sensationalism - whether that is Fox in the US, Sky in the UK, and a variety of news papers & channels in Australia.
At no point has anyone actually done anything about this, even though it significantly affects peoples views in a negative way through false truths, voting etc.
What about kids with social media and how bad it is for them? Evident through the fact that most people who work at social media companies ban or severely limit their kids from having phones and/or social media. Nope, let it slide.
But the China war with Tiktok? Of course this gets focus. How about they care about the country they actually live in by looking after the people that live in it rather than only focusing on external country threats.
It's sad living outside of the US and watching it fall apart by their own doing. If they cared, they'd focus on their employment rate, homelessness, free quality healthcare, gun control (yes), clean streets, and better education. If they can't solve it with their Military, they don't care.
> Everyone deserves peace of mind, so we made security easy and free for everyone.
which lets me know that it's not a useful source of accurate information. A quick look at the App Store page shows that there are many IAPs, including fairly expensive subscriptions. If I have a choice of paying $30/yr to enable my iPad to be a security camera, or $30 one time to buy a Wyze (which has IR sensors/lights), then I'm going to go with the latter every time.
Correct, but I prefer to understand the actual downtime experienced by people over the years (eg data centre issues, network issues, unplanned server maintenance) as that data seems hard to find centrally.
This comment is the overplayed take that because a lot are heavy frameworks, that this should be acceptable. As soon as something is classified as a framework, it seems ok to be >200kb.
If you take Tailwind CSS for example, when correctly using their CLI tool, it only includes the size of the css classes actually used, keeping it to a minimum, when compared to people just doing a standard import of the entire library. I like this mentality because it's offering the ability to be very lightweight, or as large as the 'framework' it offers. NextJS offers this as part of their build process, but not sure how big their assets are with it for a simple usecase.
The word framework doesn't really actually mean anything. People have a feel for it, but there is no concrete "this is a framework, not a library." However, I think that for most people, the criteria isn't actually related to how large the software is, but rather the feeling of using it. When you use a non-framework library, it feels like using a wrench or a drill; it's a tool. When you use a framework, it feels like you're writing code inside it, not using it. Frameworks can be small. The term "microframework" exists for this exact reason.
Semantics aside, the existence of things with different philosophies doesn't immediately invalidate everything that doesn't give you the same tradeoffs. For one thing, Tailwind deals with declarative CSS output, not imperative modular code. I'm not saying that makes it stupid or anything, but it's very apples and oranges. There are very few JS libraries or frameworks that can offer starting-from-zero KiB JS; maybe Svelte comes close? Ironically, if we're talking about client side bundles, it seems as though Fresh actually does start with 0 KiB, as it does not default to shipping JS code to the client at all.
This doesn't feel like a rational discussion at all. It feels like it's just necessary to come up with a cynical take because there's a new JavaScript thing. In a few weeks there could be some Rust FRP webassembly UI thing that has a 1.2 MiB hello world and hardly anyone will care.
