nicholasjarnold

The article seemed to highlight the inconsistencies or errors in the plugin review process which puts undue burden on developers trying to add value to the ecosystem. It was not about the differences in Manifest v2/3 and the issues with Chrome, though this was mentioned and is the reason why the 'Lite' version of uBlock Origin exists in the first place.

tl;dr - continue using Firefox and installing uBlock Origin. If you develop Firefox plugins for distribution through their official channel beware the review process I guess.

While I agree with your sentiment regarding implementing complex bespoke logic, I think there are likely measurable gains when an experienced engineer is operating outside of their current comfort zone.

Allow me an anecdote - I was recently doing some HTML/CSS to update the public website for a client. This is not where I typically operate, though I obviously have some exposure over the years. Using Supermaven I was able to very quickly perform website surgery that would have ultimately taken me much more time reading Tailwind documentation and loading my RAM with details that would be mostly superfluous to 99% of my professional workload. It's in contexts like this where I think these tools shine.

'Game changer' is clickbait phrasing for these tools in their current incarnations, but they can certainly save time while producing acceptable results when used appropriately.

> ...how much of modern cloud architecture is over engineered.

I would wager a good majority of it is. The Stack Overflow architecture[0] sticks out to me in this regard as an example on the other end of the spectrum.

[0] https://news.ycombinator.com/item?id=34950843

> the rental locations were all on air bnb but cheaper and with none of the extra fees that they would have charged forever

Exactly! Came here to echo this. I have family that got roped into this arrangement and the annual maintenance fees (and other misc fees at every turn) coupled with the up-front cost is absolutely ridiculous when compared to just booking an AirBnB/VRBO/etc for a couple weeks.

Also agree on sitting through one with zero intention to sign, once. It's a unique experience, and I feel like most people not already doing sales/marketing professionally might learn something from it.

Link to paper: https://proceedings.mlr.press/v235/crispino24a.html

Since I don't see it mentioned here and it's complimentary information allow me to mention the OpenAPI Tools website[0]. It lists and categorizes a ton of different tooling options from SDK generators, to automatic testing frameworks, etc. From some personal experience they vary in spec support and quality widely, but the listing itself is a good starting point if you're in a position to start evaluating tooling for a team you're on or company you're working with.

[0] https://openapi.tools/

Yep. It sucks. Zero consequences of any import for those companies as far as I'm aware too. Tiny fines end up being "cost of doing business". Then they get to externalize their failures onto us by using terms like "Identity Theft", which indicates something was stolen from ME and is now MY problem.

In actuality some not-well-maintained systems owned by <corp> were hacked or exposed or someone perpetrated fraud on a financial institution and happened to use information that identifies me. It's really backwards.

PSA: If you haven't already, go freeze your credit at Experian, TransUnion, Equifax and Innovis. It will make the perpetration of this type of fraud much more difficult for adversaries.

As I recall (this was about 6 months ago now) the Spring project's support for these libraries was somewhat in flux and was evolving, so arriving at the correct set of dependencies for a modern Boot stack was somewhat fraught with reading now-out-of-date information and having to find the newly-correct way. Once that was out of the way I needed to add like 3 or so dependencies to a parent POM all the teams used as a base and then add a small handful of config (which was well documented) to get it working. That config was like the jaeger sink endpoint, etc.

If you have the ability to use or upgrade to the newest version of Spring Boot, you will not have to go through what I did finding the "correct way" because iirc there was a lot of shifting happening in those deps between v3.1 and 3.2.

I can confirm that this is a pretty good way. Building out a basic distributed tracing solution with OTEL, jaeger and the relevant Spring Boot configuration and dependencies was quite a pleasant experience once you figure out the relevant-for-your-use-cases set of dependencies. It's one of those nice things that Just Works™, at least for Java 17 and 21 and Spring Boot 3.2 (iirc) or greater.

There appeared to be wide array of library and framework support across various stacks, but I can only attest personally to the quality of the above setup (Java, Boot, etc).

While it seems that I may have triggered some extremely negative sentiment here with my honest question, I appreciate the responses that didn't assume I think Greek people are aliens or serfs. I'm quite ignorant of the on-the-ground realities of Greek life (having not visited yet), but I've read enough to understand that the economic conditions haven't been great there for some time now. Therefore, I think it appropriate to question how outsiders might be received under the current conditions. I apologize if this wasn't clear from my original question. Another commenter was correct in identifying the news regarding local hostilities in some regions towards tourists whom are viewed to be part of the problem and therefore met with hostility.

...slowly backing away... :)

Some years ago I was mildly invested in the idea of finding 'strong dollar destinations' (locations where due to exchange rates and other economic factors the US Dollar was very performant), and using this research to weight vacation decisions that my wife and I made.

I recall that Greece was one of these locations. (Unfortunately we haven't been there yet.)

Can anyone here shed some more light on the friendliness of the locals in Greece towards (relatively) monied western vacationers? In other words, are people generally happy to welcome visitors, or are the visitors viewed as part of the problem (via, e.g. AirBnB driving up local housing costs, etc)? I know that a lot of how you're received anywhere depends on how you act, so assume that the visitor is a well-behaved westerner whom is interested in embracing the local culture and customs.

Yep, fully agree here. Some companies seem to consider the word 'refactor' to be profane language, and I think that's a real shame. In my experience it's those companies that end up with mountains of technical debt and regressions each cycle.

Allowing your engineers the freedom to truly own and maintain the code they're responsible for will necessarily result in refactors that sometimes even include rewrites and data migrations. On the surface and in the short term this seems risky. In the medium-to-longer term I think it results in happier employees, more confidence in the solutions and faster longer-term velocity.

> Smartphones are a tragedy itself. Security theatre destroyed it.

If you're willing to buy a new device, then I recommend getting a Pixel on sale and flashing it with GrapheneOS[0]. No rooting required. Read up on it when you have a chance. Also, if you install the sandboxed Google Play Services layer (which doesn't require any Google account logins and has very limited access to the device) you will be able to run your bank app.

[0] https://grapheneos.org/

I was once bitten by not understanding that there is a difference between "regular" clocks and high performance clocks/timers that a developer can take advantage of. At the time I needed a sampling routine to run at precisely once per second. My inexperience led me to go with something like thread.sleep(1000), and I learned quickly that I was mistaken in thinking it'd run with little jitter. As others are pointing out, there are also similar lessons and solutions when dealing with audio processing pipelines.

There is some new evidence that changes occur at various stages in our lives, specifically one in the early-to-mid forties, that can affect things like alcohol metabolism[0][1]. I find this type of thing and the "epigenetic clock" research to be pretty fascinating to read about now that I'm approaching mid-life myself.

[0] https://www.scientificamerican.com/article/drastic-molecular...

[1] https://www.nature.com/articles/s43587-024-00692-2

> the originals remain dominant for enterprise and free users anyways.

I'm a former pfSense user that reluctantly moved to OPNsense a handful of years ago after a lot of bad press around Netgate started circulating widely causing me to believe that support for the community offering might wane over time. I was under the impression that many people had moved off of pfSense for home use. I'm surprised by your assertion that it "remains dominant" for free users, and I wonder how you might know this?

OPNsense has been rock solid for me, btw. I was reluctant to switch only because of the time sink and perceived risk. Nobody wants to spend a weekend debugging VLAN tagging on their WAN port or some such. Luckily for me, there were no such issues when switching over.

Yes, and we should be investing heavily into technologies and techniques that maximize the efficiency of the water that is consumed by agriculture. The government should probably subsidize the expense of the conversion. We should also get rid of any "use it or lose next year's ration" rules that are in place which cause some farmers to literally just run water out of their pipes to ensure they're recorded as having "used their allocation" and therefore "still require that much next year".

Very true, but the agency does benefit from the current state of affairs: You can load up an engagement with more people...whom are there to help facilitate the process. These people add to the bottom line engagement revenue. When all your competitors are doing the same then the buyers of your services have no choice but to pony up. As someone who builds and enjoys building, it saddens me. We can do better, but how do we convince the deciders of this?

We're busy building when others are busy convincing the deciders they need Agile Scrum or Lean Agile or whatever flavor is cool in <year>. It's like Baskin Robbins - 31 flavors and each will make you fat and sick with enough exposure!

Hear hear!

I think it was Franklin who is quoted to have said "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."

While I've always resonated personally with this quote and how it relates to what I consider a fundamental principle we should strive to achieve/maintain, I recall there being some debate about the 'etymology' of the quote itself.

> That's what makes Bank REST APIs so tricky - processing doesn't ever actually occur at request time.

HTTP has provisions to enable async semantics between the client and the server. I would always advocate for teams to return 202 Accepted responses with a Location header containing the absolute or relative path to an endpoint that can be interrogated for status of the underlying async operation. This can work fine for lower-scale services (or even higher scale services with rate limits enforced at gateway). You POST'd a payment. You get 202 Accepted with some Location value like (simplified) `/payments/<identifier>` for which GET can be used to retrieve current status (e.g. pending, failed, committed, etc).

If a polling model is not desirable you can also use webhooks and inform the caller whenever a given task is finished.

Both of these strategies work fairly well in practice in my experience. However, I Must agree that simply dropping a big file off at an sFTP share and moving on with life is certainly "easier" from the client perspective. But...do you then roll your own mechanism for checking status? Why not just use HTTP semantics that exist already?

I've lived this life first-hand, and it is refreshing after experiencing the vast open sea of half-assed Confluence sprawl, huge PDF design documents that aren't kept up to date with changing requirements, etc.

The other sibling comment regarding rendering documentation source to Confluence or <required external system> to keep the corp overlords happy is a great middle ground IMO.

Yep, FedNow is a good step in the right direction, but the list of banks that participate needs to grow substantially. Many small and mid-sized banks/FIs aren't having a great 2023/2024, so I wouldn't expect to hear much about them integrating with new payment rails until their fundamental economics improve a bit allowing the decision makers to loosen up the purse strings again.

source: have worked in the industry consulting and doing technical design and implementation

Fair. My comment was more in the direction of saving others time, as I've personally looked into this previously (granted, some years ago) and found the Temurin packages to be of very high quality while avoiding the legal risk with the Oracle packages.

Perhaps this is also helpful for others - https://whichjdk.com/

If this might apply to you/your company and you don't have a lot of time to get into deep research on the topic just go see the Eclipse Temurin[0] project and grab a build or image from them.

[0] https://adoptium.net/temurin/releases/

Agree. I've always thought that PostgREST is an interesting project for some niche use-cases and teams. However, his argument about replacing GET request handling with a new tool that lives outside of/alongside your existing application architecture is not a particularly compelling argument. With properly-factored application code adding a GET (list) or GET-by-id is fairly trivial.

The only complexity I've ever run into there is implementing a pagination scheme that is not the typical "OOTB framework" limit/offset mechanism. I still don't think this makes the argument much stronger.

I can agree with that wholeheartedly and admit to the practice myself...particularly with libs with a large surface area or which are used in many other places in the company.

I appreciate that the engineers at Spotify wrote this post, but not because it's a novel solution or because most software engineers don't know this stuff (well, some don't I suppose). However, I find it and others like it helpful to engineering groups that exist outside of tech companies.

Why? It gives those groups and their technical leads something to point to when discussing trade-offs, timelines and investments in technology with product teams or more senior engineering leadership whom might not have had a background in software engineering and architecture. "Don't take my word for it, look at what the engineers at Spotify, et. al. wrote about this topic."

Public service notice: Employing these patterns in small companies that don't have any need for the complexity is an anti-pattern.

confirmed. and interesting/unexpected! this breaks:

datetime.strptime('Feb 29 13:37:06.942', '%b %d %H:%M:%S.%f')

edit: added code example. import datetime from datetime first obvi

It's literally out of control. We cannot have a healthy democracy in a systematically surveilled society. When people understand they're being actively and constantly surveilled they tend to self-censor their expression. When we do not have a healthy and honest exchange of expression (something that has arguably been being eroded for a long while now) it will fundamentally erode one of the pillars of our society. Kudos to CA and IL for attempting to do something about this legislatively.

As a citizen with some modicum of hope for the future I will vote for strong privacy protections. As an engineer I will not work on products that progress our state of surveillance capitalism (yep, realize the constraints here). I hope others agree and act accordingly.

Exactly, and this is why I always try to steer teams away from "one metric to rule them all" whether this be "always fail if coverage is less than X percent" or "random code metric like CC is beyond limit". Reality is simply more complicated than that, and it takes experienced engineers to actively manage and balance the tradeoffs appropriately over time. Putting arbitrary one-size-fits-all rules in place is almost never the answer.

Unfortunately, in some (many?) companies there simply aren't enough experienced engineers who have the time to do the active balancing...leading us back to "just stick this rule in pipeline so the teams are held to _some standard_".