Fork WP, and cut Mullenweg out of the loop.
93 karma · joined February 25, 2011
Engineering manager with 20+ years in Software/DevOps/Security. Created SimplePie and AWS SDK for PHP. Patented MFA-as-a-service. The godfather of Serverless. Ambivert. Curious. Not a coffee drinker.
Fork WP, and cut Mullenweg out of the loop.
Like Apple offers this for email for iCloud users. I think Firefox Relay offered it too. There was another company in the late 00s that offered a P2P version.
I mean _cool_, but I’ve not seen a company with this as its primary product last more than 18 months before. With that, _good luck_.
Buying a list of email addresses off the internet that has mine in it is top-tier shady.
2. Never spend money on multiplayer-only video games. Never buy a robot that is 100% cloud connected — ESPECIALLY from a startup. This is the same concept stated twice.
3. You buy things for what they are today; NEVER for what they might be tomorrow.
I feel no remorse. Stupidity should be painful.
Everyone gets to make their own decisions, I suppose, but let’s all tell the truth about what’s happening here.
During the transition, the new development lead said "I'm not going to read the documentation. If the code isn't self-documenting, we're going to rewrite it." Note that he said that not knowing anything about the service they were taking over. Also, it was in a language that had never established strong patterns for itself, so self-documenting when there are no strong patterns is generally meaningless.
Over the next 6 months, he proceeded to ruin the service to the point where it was impacting customers, and got fired for it. In any project of large enough size, self-documenting code falls apart unless you are remarkably good at it. IMO, Go's standard library is an exception to my experience.
Although you _can_ use separate accounts, the idea that you MUST is nonsense.
But yes, I encountered the same thing once I was added to my full-time employer’s GHE Cloud account. So far, not a problem.
It reminded me of the old magazine clipping of a guy holding a camcorder over his shoulder and pointing to a table full of technology. "All of this fits in your pocket now."
Same thing. Chill out. You're free to not like something and have it continue to exist despite your dislike of it.
FFS
…aaaaaand I've tuned-out.
Instead of looking to disable 2FA, look to speed-up providing 2FA codes.
Most passwords managers support auto-filling 2FA codes. Yes, some are still super-old school and only support SMS and email. But Safari on macOS (for example) can pre-fill the texted/emailed codes (as long as Mail.app is open, and/or your phone is paired with your computer).
Even better/faster? Passkeys. GitHub supports them, and they’re the fastest (and most secure?) login solution.
There are all sorts of solutions for this problem outside of making security worse.
It’s not just payment processing.
Fair fees for the exchange of value they provide is perfectly valid and fair in capitalistic societies. The percentage number is up for discussion, but “charging for value” by the platform vendors who built the thing and provide the platform itself is a valid point.
I worked at AWS from 2010 to 2014 after also getting acqui-hired (AWS SDK for PHP, fka CloudFusion).
About 13 years in, I pivoted in two interesting ways.
1. I started looking far more at the backend, infrastructure, and how to design efficient end-to-end systems (from UX, through the stack, to the infrastructure).
2. I realized that I have a passion for building products that take complex things, and simplify them for the masses.
So, I was doing more "building", but I was also creating new "products". And that flipped a switch inside me.
I would agree for a web dev. But if you start getting more into backend, infrastructure, building distributed systems and APIs (which was the path I took), data structures and algorithms definitely start to come into play.
I started out self-taught on the web. Got a degree in design. Then learned web dev, then moved to backend, then to infrastructure, then devops, and now platform and cloud engineering. For me, I wanted to understand "the whole widget". And there are things I learned about UX that when applied to DevOps/SRE work, have elevated me as someone to listen to.
(As a fan of Avatar: The Last Airbender, I want to point to when Iroh was explaining how the 4 nations achieve balance. Same concept here. UX, engineering, infrastructure, and product need to work collaboratively together with mutual respect for the other disciplines to achieve the balance that leads to something great happening.)
I've picked up some data structures and algorithms along the way over the years, but I don't have college definitions of them. This hurt me when interviewing at Google, but I also have the ability to search the web and learn new things. So I do.
Just last week, I was working on tokenizing and building an AST for NRQL (New Relic's Query Language). As I was working through the tokenizer, I realized that this is what a linked list is.
I'm thinking about taking a single college course this upcoming semester about data structures and algorithms, just to fill in the blanks. But I've been building things for the web since 1997. For the most part, using anything beyond lists, maps, sets, queues, etc., is (relatively) rare, but again, it depends where you want to go next. Sorting large datasets efficiently, parsing things into trees, binary search, and making sure I iterate over things as few times as humanly possible will give you FAR more bang for your buck.
Perfection is impossible when human beings are involved.
Please stop manufacturing rage.
A better example would be having the confederate flag. Except that the confederacy being dissolved is already a decided issue at the national level. (Also most Americans are only familiar with the confederate army flag, and not the confederate national flag.)
China and Taiwan have no such agreement. Taiwan says one thing, mainland China says the opposite. There is no resolution.
I’m not saying it isn’t true, but rather there is no evidence to support it. Ars Technica is also reporting on this topic this morning, and they are also missing evidence-backed sources. It’s all Wall Street analyst speculation.
Read with several large, coarse, grains of salt.
Serverless is great for event handling and bursty workloads. It is not efficient for a long running or constantly running processes. That was never what it was designed for.
There is a time and a place for serverless.
The robots are ALWAYS coming to get you.
As a principal engineer who left the Bay Area in 2010, this post obviously excludes me. If I have my choice, I’ll never go back to the office.
Support does not mean “it works“. Support refers to who is on the hook when something goes wrong.
If the company is not prepared to support Linux, there is your problem.