IMHO the most interesting feature of OpenJ9 is the compile server. One node decides to optimize, sends over the traces, and the compile server sends optimized native code to all nodes. Or a new node joins and could be brought up to speed within a very short time.
I played around with codegraph. I did a quick experiment where I gave claude code a feature to implement, and I had it perform the same task with and without codegraph. This wasn't scientific, so take it all with a grain of salt.
The codegraph implementation used fewer tokens. However, I performed an automated code review on each implementation, and there were more issues with the codegraph version. These weren't major issues, more like it re-implemented a function that already existed, or used styling that wasn't consistent with the rest of the codebase. My theory is that there's useful information an LLM gleans while grepping through code that is missed when it uses codegraph instead.
Often in software development I encounter code that seems overly complex. It's not always obvious at first glance whether that complexity is because it's solving a really difficult problem, or because the developers made it more complex than it needed to be.
Having no domain knowledge of the problems of detecting cracks in blades, this sounds like either a genius solution to a super hard problem, or unnecessary complexity.
Given the forces involved, the need to avoid wireless communication, the complexity of any bearing with associated electrical contact, and so on this seems like the least complicated solution. You can rely on radioactive elements to emit radioactivity above background, you can build a pretty reliable pressure indicator, and you can fill a cavity in the blades with gas pretty reliably. You sidestep all of the complicated mechanical linkages in favor of a solution that's not in the rotor hub at all.
I though it sounded pretty clever. Now, that can be good or bad depending on context. I mean it in a good way. It seems simple conceptually (I have no idea if it adds a lot of complexity to the manufacturing) and rather foolproof. I guess the radiation shield could jam and not move when it should.
I don't use MCPs much for personal use, but I've come to see the benefits of having a standardized mechanism for distributing tools across non-dev teams, especially when they're using a hodgepodge of agents.
I'm also excited about the upcoming SEP-2640 extension to MCP, which will be allow skills to be delivered via MCP. While the skill format has been standardized, skill distribution hasn't. I know there are tools like Vercel skills CLI, but that's not a good option for non-devs.
My experience with Cognito matches the author's experience exactly. I mostly used Auth0 in the past, but we switched to Cognito for a new project because it would be cheaper.
Don't like that email addresses are case sensitive, and now you want to change that? Sorry, you gotta create a new user pool from scratch--no way to migrate.
That’s really the worst feature of it. When you first set it up you’re asked at least a dozen questions that you probably have no idea what they mean. But you have to pick something. And whatever you pick on that first day setup you are stuck with FOREVER. Unless you do a complex data migration task.
Also, want to migrate to a different provider? Sorry. You can’t get the hashed passwords out. So if you do a migration it will be painful to users since they’ll have to do a password reset.
Ory Kratos has a password migration hook that lets you migrate password credentials out of anything (including Cognito) without password resets.
I believe most other (modern) auth vendors have an equivalent.
I really don't see any reason to be using Cognito in $currentyear.
Auth0 will run an export for you, but you have to file a support ticket for them to do it, and it may take them a bit of time, so you may end up with some users who get reset to a slightly old password (if they change it between the export and your import) or if you get a new registration.
Given all the pain I've suffered working with both cognito and auth0, I can't imagine a reason for using either in $currentyear.
Yea I went through this as well - when I tested it, they also required you be on a paid plan to even be able to get the export, which is kinda crazy. I work at an auth company now (Clerk) and this experience drove our current approach, which is that you can instantly export all your user data through a button in the dashboard. Maybe it's not as "sticky", but I think respecting your users when they want to get their data or migrate off is way more important.
I've heard that the prevailing theory now is that it wasn't the lack of fungus that made coal. Instead, the earth was covered in tropical wetlands, and trees couldn't decay in the anoxic water.
Nice perspective. So even if all these data centers were built in the desert, it's entirely within the realm of possibility to transport 17B gallons of water, unlike the 43 trillion used for irrigation. Some back-of-the-napkin math:
- A truck holds 5000 gallons
- It would take 3.5 million trips to transport that much
- If each trip was 500 miles roundtrip, that's about 2 billion miles
- Trucks travel 140 billion miles each year in the US. That would add less than 2% to the total miles
- The trucking industry is about $1 trillion in revenue per year. So 2% of that is $20 billion total to transport 17 billion gallons. Or around $1 per gallon.
I built an ecommerce site long ago, and even though the UI was fairly modern for the time, they insisted we use antiquated styling on the billing forms of the checkout page to help exude trust. As a developer it bugged me because I knew it was just styling, but they probably weren't wrong.
reply