No. Just Stop. The prior monthly post is still the #1 on the "ask" page, and even monthly it is a high noise ratio. We don't need it faster, we certainly don't need people posting their own thread just to pimp their personal project.
Putting the version number in the domain is a fairly strong "I'm just going for quick cash grab from a wrapper app" signal, if I've ever seen one. As is the blog link with no entries. The utter lack of any information on who is behind this, what they are actually running, or anything at all about what this really is that is different than using any existing platform.
> But what if we've been wrong about what matters?
Still wrong, though. Does the final product solve the problem it set out to solve? Because that is what matters. Specs and code are both tools to achieve that. So while this article is a good start... if you think that AI has changed what matters, not only were you wrong about it before, but you still are.
The idea of just re-building a whole app via LLMs when changes are needed is cute. But then you are also going to have a whole new set of bugs and UX changes. For anything non-trivial, documentation will be wrong, training will be wrong, people's experience will shift and complaints will ensue. Sure-fire way to increase churn, which is a bad thing.
I'm working on hand-building mugs. Throwing clay around in a studio, etc.
But I'm also thinking about it as a product manager based on my tech experience. Looking at what people like in mugs, creating templates to exactly size the mugs to people's preferences, creating re-usable molds to put repeatable components together, and taking detailed notes on exactly what I am doing in-studio to create a repeatable, reliable process to create a product that will sell.
It is going poorly so far, but each iteration gets better, so hopefully I have everything down before I end up with 100+ unsellable mugs in my kitchen.
That is just how being a PM goes. You need to take all those inputs and synthesize a vision that meets as many needs as possible, without delegating control to the stakeholders.
The most important thing to learn is how to say "No", and that saying "No" should be the default answer.
You add features when multiple stakeholders agree they are needed, not when one new guy shows up in a meeting. You listen deeply to them all and understand why they are asking for things, and devise a solutions that solves their underlying problem - do not just take their requests at face value and implement them. Then you get to surprise them in UAT, when instead of them telling you that you failed to solve their problems, they tell you: "Wow, not what we asked for, but this is even better than what we had thought of."
It is your job to be the expert in what the customers and stakeholders need, so take all those pain points and embrace them as opportunities to learn more deeply what the correct product to build actually is.
It is also your job to set the priority, so there is no situation where everything is priority #1. People can tell you their own opinions on what is most important to them, but the actual priority is set by you.
When building up something small and new, sure, checking security in each route is quick and easy. But a time will come where your security, roles, and whatnot have evolved to the point that new features and roles would mean you need to go update every route. Aside from the tedium to do so, it introduces more changes which means more potential for mistakes. That is when middleware is better.
When you do get to that point, don't hard-code checks on whether the current user has the exact roles for that specific route. Instead, get more creative. Every app will have different needs, but I like to do all the setup for the auth checks when they first login, cache an array of their allowed routes on the server, and then you just check whether the cache has the current route on each request. (Yes, and clear that cache if their access changes mid-session.)
Doing so is not much code, performs well at scale, and you never have to touch the routes themselves when refactoring security, you just need to tweak that setup function.
My experience is that different people have different roles. Those focused on the tech are probably focusing in their own space. Those focused on marketing are probably trying to kickstart discussions online. So when you are looking at what discussions you see, which group do you think you are really looking at?
I agree. i have seen marketing and sales ( mostly just talking about competition). But I think if we care talking more about our product with just a sense of where competition is that should be better.Idk
I'm dubious. The fact that there are valuable minerals in the Utah desert is not news. This feels less like a surprise discovery and more like someone trying to milk the current administration for support, as the bottom of the article points out that the USA is currently trying to get more mining going.
That point on the map is also a bit south of where suburban development ends, which would make it fairly valuable real estate as the metro area expands. So I got online to confirm whether it really was owned by the mining company. I know from my prior days doing my own prospecting in that area that most of the land there is public, owned either by the feds or the state. Funny thing - that specific parcel doesn't show the owner on the Utah county parcel map. It is just a blank spot in the data. But it does have historical photos and shows that the dig site at that point has been there since at least 2015, so this could be new finds, but the dig site is definitely not new.
It could be true - it could be a new find on land owned by a private company. I cannot prove otherwise, but something smells a little fishy here.
That touches on why I never pursued server-side React in any form. It seemed to twist what was a clean break between layers into spaghetti. I totally get that it solves other problems, but it always felt to me more like trying to force React to be something it was not. The better strategy seemed to me to use React on sites where users can handle the bulk of a front-end React app, and don't use it elsewhere.
Specific to security, keeping React 100% client-side keeps things simple: Don't trust the front-end.
reply