I clicked the article thinking it was about GitLab. Much of the criticism held true for GitLab anyway, particularly the insanely slow feedback loops these CI/CD systems create.
You can though. GHA and Gitlab CI and all the others have a large feature set for orchestration (build matrices, triggers,etc.) that are hard to test on a local setup. Sometimes they interfere with the build because of flags, or the build fails because it got orchestrated on a different machine, or a package is missing, or the cache key was misconfigured, etc.
There are a bunch of failures of a build that have nothing to do with how your build itself works. Asking teams to rebuild all that orchestration logic into their builds is madness. We shouldn’t ask teams to have to replicate tests for features that are in the CI they use.
Indeed there are. But you iterate on local and care about CI once everything is working in local. It's not every tuesday I get CI errors because a package was missing. It's rare unless you're in those 1000-little-microservice shops.
It is rare for our run of the mill Java apps to however, we notice it with:
Integration of code quality gates, documentation checks, linting, cross architecture builds, etc.
Most of this can be solved by doing the builds in a docker image that we also maintain ourselves. Then what remains is the interaction between the ci config for matrices, the tasks/actions to report back quality metrics, the integration with keyvaults to obtain deploy time secrets, etc.
Then there are the soft failures, missing a cache key causing many packages to be downloaded over and over again, or the same for the docker base images, etc.
We fix this for our 1000+ microservices, across hundreds of teams by maintaining a template that all services are mandated to use. It removes whole classes of errors and introduces whatever shenanigans we introduce. But it works for us.
If GHA, Azure Pipelines, etc., would provide a way of running builds locally that would speed up our development greatly.
Until then we have created linting based on CUE to parse the various yamls, resolving references to keystores, key ids, templates, etc., and making sure they exist. I think this is generic enough to open source even.
> Authorities, citing a “foregone conclusion exception” to the Fifth Amendment, argued that Rawls could not invoke his right to self-incrimination because police already had evidence of a crime. The 3rd Circuit panel agreed, upholding a lower court decision.
I do not follow the logic here, what does that even mean? It seems very dubious. And what happens if one legitimately forgets? They just get to keep you there forever?
This is an area that seems to confuse a lot of people because of what the 5th amendment says and doesn't say.
The reason they can't force you to unlock your phone is not because your phone contains evidence of stuff. They have a warrant to get that evidence. You do not have a right to prevent them from getting it just because it's yours. Most evidence is self-incriminating in this way - if you have a murder weapon in your pocket with blood on it, and the police lawfully stop you and take it, you really are incriminating yourself in one sense by giving it to them, but not in the 5th amendment sense.
The right against self-incrimination is mostly about being forced to give testimonial evidence against yourself. That is, it's mostly about you being forced to testify against yourself under oath, or otherwise give evidence that is testimonial in nature against yourself. In the case of passwords, courts often view it now as you being forced to disclose the contents of your mind (IE live testify against yourself) and equally important, even if not live testimony against yourself, it testimonially proves that you have access to the phone (more on this in a second). Biometrics are a weird state, with some courts finding it like passwords/pins, and some finding it just a physical fact with no testimonial component at all other than proving your ability to access.
The foregone conclusion part comes into play because, excluding being forced to disclose the contents of your mind for a second, the testimonial evidence you are being forced to give when you unlock a phone is that you have access to the phone. If they can already prove it's your phone or that you have access to it, then unlocking it does not matter from a testimonial standpoint, and courts will often require you to do so in the jurisdictions that don't consider any other part of unlocking to be testimonial.
(Similarly, if they can't prove you have access to the phone, and whether you have access to the phone or not matters to the case in a material way, they generally will not be able to force you to unlock it or try to unlock it because it woudl be a 5th amendment violation).
> excluding being forced to disclose the contents of your mind for a second
This seems like a key point though. What's the legal distinction between compelling someone to unlock a phone using information in their mind, and compelling them to speak what's in their mind?
If I had incriminating info on my phone at one point, and I memorized it and then deleted it from the phone, now that information is legally protected from being accessed. So it just matters whether the information itself is in your mind, vs. the ability to access it?
There are practical differences - phones store a lot more information that you will keep in your mind at once.
You can actually eliminate phones entirely from your second example.
If you had incriminating info on paper at one point, and memorized it and deleted it, it would now be legally protected from being accessed.
One reason society is okay with this is because most people can't memorize vast troves of information.
Otherwise, the view here would probably change.
These rules exist to serve various goals as best they can. If they no longer serve those goals well, because of technology or whatever else, the rules will change. Being completely logical and self-consistent is not one of these goals, nor would it make sense as a primary goal for rules meant to try to balance societal vs personal rights.
This is, for various reasons, often frustrating to the average HN'er :)
> This is, for various reasons, often frustrating to the average HN'er :)
With that in mind...
> Being completely logical and self-consistent is not one of these goals, nor would it make sense as a primary goal for rules meant to try to balance societal vs personal rights.
Do we really know that it wouldn't make sense, or is that just an assumption because the existing system doesn't do it? (Alternatively, perhaps a consistent logical theory simply hasn't been identified and articulated.)
This reminds me of how "sovereign citizens" argue their position. Their logic isn't consistent, it’s built around rhetorical escape hatches. They'll claim that their vehicle is registered with the federal DOT, which is a commercial registration, but then they'll also claim to be a non-commercial "traveler". They're optimizing for coverage of objections, not global consistency.
What you seem to be telling me is that the prevailing legal system is the same, just perhaps with more of the obvious rough edges smoothed out over the centuries.
It means that if all the other evidence shows that the desired evidence is on the computer, then it is not a question of whether it exists, so youre not really searching for something. Youre retrieving it. That doesn't implicate the 4th amendment.
Unlocking/forced unlocking is not a 4th amendment issue, but a 5th amendment one.
The 4th amendment would protect you from them seizing your phone in the first place for no good reason, but would not protect you from them seizing your phone if they believe it has evidence of a crime.
Regardless, it is not the thing that protects you (or doesn't, depending) from having to give or otherwise type in your passcode/pin/fingerprint/etc.
Fair check! I use it to polish my phrasing (especially trying to keep up with this thread volume), but the 'scars' and the management experience behind the comment are 100% human. Point taken though—I'll try to keep it rawer
I don't like doing the leetcode grind, but all of the alternatives are strictly worse.
* Take home projects filter out people with busy lives. Wastes 100 people's time to hire 1 person. Can't be sure they didn't cheat. No incentives to stop company from giving you a 10 hour assignment and then not looking at it. The candidate with the most time to waste wins.
* Relying on academic credentials unfairly favors people from privileged backgrounds and doesn't necessarily correlate with skill as an engineer.
* Skipping the tech interview and just talking about the candidate's experience is prone to favoring bullshitters, plus you'll miss smart people who haven't had their lucky break yet.
* Asking "practical" questions tends to eliminate people without familiarity with your problem domain or tech stack.
* We all know how asking riddles and brainteasers worked out.
With leetcode, the curriculum is known up front and I have some assurance that the company has at least has some skin in the game when they schedule an engineer to evaluate me. It also tests your general knowledge and in some part intelligence as opposed to testing that you have some very narrow experience that happens to overlap with the job description.
I've spent a heck of a lot more time grinding leetcode than I have working on take-home projects. I always enjoyed doing take-home's because I could really spend time on it and make it something worth showing off - if anything it always felt like the perfect low-stress way to show what you can do. It's amazing how many candidates don't take the time to make it look good (or even meet the objectives in many cases).
Haven't done one since pre-LLM era though and that path seems like it might be completely infeasible for employers now.
That said, the most productive interviews I've been a part of as both employee and employer have always been with the technical people that you'll actually work with and conversational in nature. You can learn a lot about what someone knows by listening to their experiences and opinions (but this depends greatly on the quality of the interviewer)
The author is writing like Java was outlawed or something. There are tons of shitty enterprise Java jobs out there for those who want them. Personally, I worked one of those jobs a decade ago, and the article's description of the "golden age" didn't bring back good memories.
It's easy enough to avoid the NPM circus as well. Just don't put JavaScript on your resume and don't get anywhere near frontend development.
> The outgoing Element mobile app (‘classic Element’) will remain available in the app stores until at least the end of 2025, to ensure a smooth transition
I can't find any other communication from Element Creations other than that.
The renaming to Element Classic doesn't bode well considering that Element X still doesn't support a vast number of home servers and a number of Synapse authn/authz features.
If they remove it from the app store, my advice for my users is going to be to switch to fluffychat, and I'll eventually migrate away from Synapse to some flavor of Conduit.
