Now with the MCP server, you can instruct the coding agent to use shadcn. I often do "I you need to add new UI elements, make sure to use shadcn and the shadcn component registry to find the best fitting component"
The genius move is that the shadcn components are all based on Tailwind and get COPIED to your project. 95% of the time, the created UI views are just pixel-perfect, spacing is right, everything looks good enough. You can take it from here to personalize it more using the coding agent.
I've had success here by simply telling Codex which components to use. I initially imported all the shadcn components into my project and then I just say things like "Create a card component that includes a scrollview component and in the scrollview add a table with a dropdown component in the third column"...and Codex just knows how to add the shadcn components. This is without internet access turned on by the way.
The plugin architecture here reminds me of what happened with VS Code - once you give users a proper JavaScript API and decent documentation, the community starts solving problems you never even knew existed. But there's something particularly clever about IINA's approach: they're essentially turning every media file into a potential canvas for interactive experiences.
I had a coworker introduce me to The Five Dysfunctions of a Team[0] as a useful tool for framing problems with team dynamics.
It's easy to draw parallels between what's described and those dysfunctions. In case you're not familiar, this framework by Patrick Lencioni outlines five obstacles that can mess up a team’s flow: absence of trust, fear of conflict, lack of commitment, avoidance of accountability, and inattention to results.
Particularly relevant to this situation:
> Fear of conflict: seeking artificial harmony over constructive passionate debate
Just to warn you though, there is a tradeoff. You can also just act like an asshole and cite a culture of toxic positivity if people take issue with your behavior. The key is collaborate, productive focus on the outcomes with the other human beings involved in the endeavor.
The videogames industry is completely paralyzed by fear of conflict. It's in a transition between the old guard who never had any training and revel in conflict (sometimes, but rarely, too toxic levels) and the new starters some of whom seem to have no idea that criticism is an intrinsic part of the creative act.
It's very sad and products are failing all over the place while the industry works it's way through this. It might not make it as the current solution is to homogonize all staff and remove their intrinsic value.
Oh well, I enjoyed the first 20 years in the industry, not so much the last 10 years.
Not only the games industry, we seem to be on a fluffy world where any kind of negativity has direct impact on job evaluation, and can even lead to losing the job.
A couple of years ago I worked on such good vibes project, uff.
This is a great reference, thank you. To me it was clear that Concord suffered from a deeply dysfunctional creative processes.
The character designs alone are so laughably bad that they border on caricature. They don't only violate the most basic of design fundamentals, they show a shocking amount of incompetence on all levels.
Lots of money, but not vision. It's not a coincident that Concord was a hero shooter. Of course big money doesn't understand what they invested in and everybody was just chasing trends without understanding a single dime of what made Overwatch a success.
>Of course big money doesn't understand what they invested in
Why "of course"? SIE did the due diligence, not just the executives (e.g. Hermen Hulst, the head of WWS, who signed off on the deal, is lauded as the genius of game design with such amazing titles as Killzone and Horizon under his direction during his tenure at Guerilla) but very senior people at the Playstation studios (Bungie, Naughty Dog, Insomniac etc.) checked this out and identified it as a sensible investment into a successful game. These are not some VCs investing into the most hyped thing this week, these are some acclaimed developers closing their eyes on the abomination of a game they purchased with money they don't really have.
There is nothing remotely normal in this process, this is something like Toyota buying Fisker for $10B and putting its badge on Karma.
Acclaimed developers make flops and garbage games all the time, I don’t think involving them is really any indicator of making a sound financial decision, which is further reinforced by TFA.
I've realized something funny. It should be the company's interest to encourage employees to have productive debates and spend effort figuring out the best course on action, while in reality, from the perspective of an employee, it's an uphill battle to have your voice heard, with no reward at the end. Therefore, what a smart employee does, is shutting the fuck up.
Case in point: in my current team there's one very vocal senior who needs to have things done his way, but other than that, the willingness to participate in discussions is inversely correlated with experience, and the most experienced devs simply ran out of fucks to give because they're not getting paid extra for the time they spent in fruitless discussions. The end result is that the knowledge ends up being unused and we implement stupid ideas.
The reward for those things is either more work for no increase in pay or you're in conflict with one or more people who are now bad mouthing you to the boss and you'll eventually be fired or be made so miserable that you'll voluntarily leave.
> Fear of conflict: seeking artificial harmony over constructive passionate debate
What do you do when you don't fear the "conflict" (passionate argumentation in search of better approaches) but having it leads nowhere, because people have different opinions?
For example, I responded to a comment where a person had a difficult situation with a coworker, though I didn't really have any solutions myself either: https://news.ycombinator.com/item?id=41601023
There's a lot of abstract stuff out there, without always having a clear cut "best" answer, but which will have different drawbacks long term, which will impact people differently (e.g. in regards to webdev, that could be using an ORM vs not using it from a type of workload where either could suffice, composition vs inheritance, DB views vs dynamically built queries in the app, using the DTO pattern vs not, using projections for returning DTO data directly from the DB to avoid needing arguably unnecessary mapping in the app code between an Entity and DTO object).
Probably there's dozens of things like that, that apply to game development as well, with people whose opinions have been shaped by differing experiences.
I think that you will probably need to compromise a lot and with outcomes that might feel sub-optimal, hopefully without souring the team dynamics in the process.
You need to have a way of resolving conflicts independent of arriving at a consensus (which is usually the best way to do things when it's possible). Usually in technical projects this is done by escalating up the chain of technical management. It could also be done by some kind of voting process, but this isn't very common except in some larger open-source projects. It also requires that the members of team will accept the decision, and not actively work against it. If you have a team member who will not accept things done any way but their way, then they're probably someone you don't want on your team.
A phrase I heard early in my career from a superior while reviewing code was "just reminding myself that while this isn't how I'd do it, that doesn't make it wrong"
I don’t disagree with the take, but it doesn’t seem sufficient either.
Even if you have developers that know better than to toss aside each other's linter rules and don’t rewrite each other's code in the name of “refactoring”, then if you still have people with differing views working on the codebase, its consistency over time will become less than more.
Whereas if developer A tries to be agreeable then more and more of the code will be written in the way of how developer B wants it to be written and that might make developer A’s life harder over time.
That's just standard erlang/elixir- because all values are immutable, when a new anonymous function is defined it copies the current value of the external variables into it.
You can do it right now even without Flame, just by opening two Elixir nodes, then it's as simple as
Note that while the string interpolation and `IO.puts` was run on `other_node@localhost`, it still did stdout from the first node- this is because it was the one that called `Node.spawn_link`, making it the 'group leader'. Outside of which stdout it went to, all the work was done in the other node.
Yeah, I think this was more inward focusing on things like `Oban` in elixir land.
He's made the distinction in the article that those tools are great when you need durability, but this gives you a lower ceremony way to make it Just Work™ when all you're after is passing off the work.
So, Chris, how do you envision the FLAME child understanding what OTP children it needs to start on boot, because this could be FLAME.call dependent if you have multiple types of calls as described above. Is there a way to pass along that data or for it to be pulled from the parent?
Acknowledging this is brand new; just curious what your thinking is.
EDIT: Would it go in the pool config, and a runner as a member of the pool has access to that?
Good question. The pools themselves in your app will be per usecase, and you can reference the named pool you are a part of inside the runner, ie by looking in system env passed as pool options. That said, we should probably just encode the pool name along with the other parent info in the `%FLAME.Parent{}` for easier lookup
Ah, that makes a lot of sense - I think the FLAME.Parent{} approach may enable backends that wouldn't be possible otherwise.
For example, if I used the heroku api to do the equivalent of ps:scale to boot up more nodes - those new nodes (dynos in heroku parlance) could see what kind of pool members they are. I don't think there is a way to do dyno specific env vars - they apply at the app level.
If anyone tries to do a Heroku backend before I do, an alternative might be to use distinct process types in the Procfile for each named pool and ps:scale those to 0 or more.
Also, might need something like Supabase's libcluster_postgres[1] to fully pull it off.
EDIT2: So the heroku backend would be a challenge. You'd maybe have to use something like the formation api[2] to spawn the pool, but even then you can't idle them down because Heroku will try to start them back. I.e. there's no `restart: false` from what I can tell from the docs or you could use the dyno api[3] with a timeout set up front (no idle awareness)
Well, that was 8 hours ago - you get anywhere noodling over this?
I'm trying to go through the same thought process - this is neat, how do i translate into more practical applications. It seems like such a powerful paradigm if one can figure out that mapping.
The interesting thing is that drag and drop interfaces are not typically purely directly mapping the drag operation to moving the object selected. There's a lot more going on -- there's hover and activation effects, limits, often animation.
This approach gets rid of the annoying leg work of mapping pointer movement to changes, but I'm not sure how to fit the rest of drag drop UI into it (I do see examples of limits in the doc).
I think it's going to have to be something in the back of my head for awhile, and when I see interesting dragdrop experiences I'll think about how it could be achieved with this approach.
I'm interested in hearing more about this - any resource you can point me at or do you mind elaborating a bit? TIA!