I was going to make a snarky quip that it would cost a lot more to buy the parts from Radio Shack since you would need also have to either already own or build a time machine. But, then I checked the internet and someone is still operating Radio Shack stores in other countries. But, depending on where you live you might hvae to add airfare to that $10 in parts to get them from Radio Shack.

I'm fairly certain the "willing to be treated poorly" is not just in relation to the in-office 3 days a week policy. Amazon has a poor reputation for corporate culture with a high burnout rate. I have chosen to politely rebuff all their recruiters so far because I have no desire to work in a burnout culture.

Actually when you put it in those terms of $3k/month it probably is cheaper than the rent many people pay in the area. I wonder what sort of limitations they would have on length of stay? The up side is that if you leave the company and need to relocate just pack up and go. The downside is if you leave the company and want to stay in the area you still have to go.

Have you read the memorandum that went with the injunction? https://storage.courtlistener.com/recap/gov.uscourts.lawd.189520/gov.uscourts.lawd.189520.293.0.pdf

I assume there is a lot more not cited in the memorandum. But, when you put together everything it certainly sounds like the government was dictating actions by the social media companies and at several points threatened unspecified actions they would take if their requests were not acted upon. And, this is only the communcations that were recorded. I imagine there were also unrecorded phone calls and meetings.

If you just want excerpts there are plenty of sites that are taking excerpts and summarizing things so you can search for those if you want. Or you can read the whole thing which is what I've been doing, and I do think it is worth reading regardless of what your opinion of the injunction is. I do believe that it shows an increasing trend of demands from the government to the various companies involved, and a progressive trend towards submitting to those demands. I believe that when taken in totality it can be read as government coercion, and there are multiple instances where there were direct requests to remove content or block individuals. But, I encourage you to read it for yourself and make your own judgement.

The principal problem addressed here was that individuals in the government were explicitly telling the social media companies what and what not to allow on their platforms. They were actively threatening and coercing the social media companies into doing what they wanted them to do. That is explicitly what the first amendment is supposed to prevent.

Arguing for or against the ability of the social media companies to censor speech they disagree with on their own platform is a separate argument. And, from what I can tell this injunction does not stop the various social media companies from doing these things on their own.

My big question however is what happens to the polcies that these companies are currently enforcing that were directed intiially by the government? My assumption (not a lawyer) is that all those polciies would be open to litigation by the parties they impacted. By acting at the behest of the government I presume they can be considered government actors and thus subject to lawsuits brought on a first amendment basis.

The Achilles Heel here would be if the app uses a semi-predictable algorithm for generating the twelve words. If there is any predictability to the algorithm and the dictionary used then someone could've cranked through a list of inputs and generated a list of keys and validated them against the blockchain. Then they just had to queue up their attack and crank through the wallets they wanted to drain.

Some random number generators are not very random when the system in question has low entropy (low up-time). And, grabbing a random entry from a dictionary to build that twelve word phrase would become predictable if using a weak random number generator algorthim with low entropy.

Sure they may not sell them anymore but the average consumer is going to keep these things as long as they keep working. And, since most of the time smart plugs just get set up once, a schedule added, and then are left in place they're going to keep working in most homes for years. So Belkin just admitted they are going to leave a known security vulnerability running in peoples homes forever. Sorry Belkin but people are not going to replace a plug that costs > $20 a pop just because you say its end of life, instead someone is going to phone up a lawyer and initiate a class action lawsuit which is going to cost you more than patching the code and initiating an update.

I use it almost every day actually and it works pretty well. Sure it gets confused if I'm in Audible and decide to ask for a song, or if I'm in Music and ask for an audiobook. But, I've learned to just ask Siri to open the audible app before asking Siri to play my audiobook. When it comes to the nav apps I always set up my destination when parked because that's too easy to mess up if you're not giving it your full attention and it's thus too distracting to try and do while driving.

The biggest bonus in my opinion, and this goes for both CarPlay and Android Auto is that you have the same interface in any vehicle you drive. Just plug in and you have your nav, your music, etc... Before these hit the market I had to pay Jeep for their nav product and Toyota for their nav product, and then if you sold your car and bought a new one you had to start all over again. Now I just take my phone with me.

Honestly it's a bit of a sticking point for me that if a car doesn't have CarPlay in it I'm not going to look at it. There are too many options that do have it right now for me to waste my time and money on something that doesn't have it. And, no I won't let BMW nickel and dime me to death to keep CarPlay going when I know for a fact that it's a one time licensing fee on their end to get it enabled for the whole product line.

I know people don't always read the article but did you even read the summary?

Yes, there is a licensing fee, but it's a one time deal that they can then amoritize across all the vehicles they produce. From my understanding the fee is not per vehicle but rather a one time up front licensing fee.

Refactor costs are exponentially larger when the underlying code is slapdash and uses dynamic structures/types. When an engineer learns how to write their code with the understanding of how it can be refactored and supported later they can make much more readable code that is still performant and will save hundreds of hours of support and maintenance time later on. I have seen too many people claim that time is money and then rush something out without thinking of the implications on maintenance and support. And, I've had to come in and clean up someone's dynamically typed mess too many times when something has broken to buy into the belief that dynamic typing helps. IMHO the only thing it helps is sloppy coding and increasing break points and support costs.

Personally I cannot and would not trust IBM as an employer. Their actions a few years ago laying off older (higher paid) employees so they could hire younger workers made it specifically clear to me that their management culture is toxic and not worth trusting. It's a rather sad state of affairs as they once had the reputation of a place you could work your entire career at and be treated well.

This smells to me like Unilever identified that they had problems managing IT. But, they have likely traded the problems they had for new ones instead. They might have some big wins in the short term from learning about their own infrastructure and applications. But, long term unless they fix the issues that led them to see this as a big win they will continue to have issues.

IT requires constant upkeep, maintenance, and iteration. It requires investing in your team that will keep things running. If you don't invest in the people you need then your IT will have problems. Unilever is chasing a magical solution that they think will fix all their problems. But, unless they invest in their people their cloud-only enterprise will soon suffer the same problems that led them to this in the first place.

It's easier to secure a Chromebook than a Windows machine or Mac. It's basically a glorified web browser and can be centrally managed with forced updates.

When I think of non-engineering roles I think of:
- managers
- scrum masters (yes our company managed to make scrum master a separate role)
- business analysts
- product owners
- etc...

In my experience most of those individuals do not need much in terms of hardware these days they can do almost everything in a web browser. Google has to be using their own suite of products for email, word processing, spreadsheets, etc... And, things like project boards tend to be all web based these days.

Plus I assume that if you need an actual desktop you can get a virtualized machine to remote into or justify the exception for the hardware. I rather assume that my own company will be heading this way soon too. We're already built the infrastructure to deploy chromeos machines to 2k+ locations so its likely only a matter of time before it comes to HQ too for non-engineering roles.

Had a coworker in the same boat as you. He had gone management, it got old, he was not confident in his employer anymore, and his skills were rusty. He interviewed around and we gave him a chance as a contractor for six months. That was three years ago. Rock solid engineer. It gave him the chance to try us out and us to try him out. Ultimately it worked out well for both parties. And, if you hop around a little as a contractor it doesnâ(TM)t look bad. Whereas hopping around as an FTE does.

Reading through the comments you'll find a very wide variety of opinions. And, I think much of that is reflected by individual's positive and negative experiences with the pattern. I've had both.

First the negative. If you divide up your services poorly, or define what is a service poorly you will absolutely have a negative experience. Also if you fail to take into account caching you'll have a negative experience. My first venture into micro service land was horrible. An architect decided to try and build a "platform" from the services that would supposedly allow us to build many different apps from the same few core services. He decided that the act of putting stuff away into an inventory location should be one service. The act of taking something out of an inventory service should be another service. And, yet another service would provide the list of work to be done. It kept going and it was bad.

The positive came when we tore that mess down and rewrote it without an architect providing an esoteric design. We decided that the lines between things had been drawn horribly. Getting data about an item should be one service. A Kafka consumer to get our list of work from upstream. Getting inventory locations should be another. We should have one that built a route through the locations to guide us. And, we should have one service that interacted with them and stored the information as a single document in a mongo repo.

You could in some ways argue that that pattern is a mixture of micro services and a monolith. And, I wouldn't say you're necessarily wrong. But, it has been the most effective pattern for us.

Each service works in isolation. When the data contract for getting information about items changes we go modify the item service and maintain our internal mapping. When we decided there was another team who had developed a better pattern for building efficient paths we were able to swap out our back end call quickly because it was proxied through our own service.

The confusion I see most often about what is a micro service comes from not being able to clearly delineate what should be a service on its own. And, in not having the correct tooling in place to make it effectively. We have a few data sources that are API based but can have rather slow response times. So we build a cache. In our local team we have a varnish server that is configured to route our traffic correctly but also add a buffer to each call. Some calls for data that doesn't change often can be cached for up to 24 hours. Some calls we just want to avoid an HTTP hiccup and will cache the result for 2-3 seconds. If you run four varnish nodes you're now talking that in the case of the 24 hour cache you will have four slow calls for that unique piece of data in 24 hours and the rest will be lightning fast. We use Micronaut, Kotlin, and async/suspend calls throughout to allow for the most efficient use of our compute resources. We are also highly aggressive with our TTL's in mongo to keep the total dataset down to a manageable level with heavy indexing on our most commonly queried fields.

As we rebuilt using the above stack there was a lot of learning along the way. It requires constantly evolving the system and you need to truly own your architecture. This is not something that you build it and walk away from it. This is something that you build and maintain. In the long term it reduced our total cost of ownership and support issues tremendously. When we had our abortive bad experience our issues were compounding and it was a nightmare.

The only way to truly evolve a micro service architecture correctly is to approach it in an iterative format. Start with something small, make it work, then add onto it. As it grows you will find where something should be peeled off and become its own service. Hopefully you figure that out before you get too far down the rabbit hole of wiring it in. Unit tests, code coverage analysis tools like jacoco, and functional specs are essential also.

The other big tool that helps maintain this pattern is the ability to make the same change to many projects in parallel. We have a home built tool that one of our principal engineers slapped together a few years ago that will cycle through every repo in our git org and run a processing rule against it. This could be something as simple as get the latest version of library X from artifactory and then update the project to use that library. It could be something more complex like update a library in gradle, add a block to override references to com.javax.singleton and replace it with com.jakarta.singleton throughout the entire project. Having this tool allows us to maintain many independent git repos concurrently with little effort. And, because our build pipelines are running the full unit and functional spec test suites every time you make a pull request we have a pretty good idea that our updates will work when we do that. Occasionally we still make mistakes, but we deploy services one by one with canaries and heavily automated monitoring. So if we've introduced a new error we typically know about it in minutes and can roll back and fix it.

Microservices as a concept by itself is nothing without a culture and the tooling to support it. If you don't have that then you might be better off with a monolith.