This is such an awesome example. That it's good enough at getting a gun game to put a smile on my face is icing on the cake. I've played lots of simple flash games in my day and this seven year old's vision made real by an AI is better than a decent number of those.
Which isn't diminishing the authors of that prior work either, those same individuals with these new tools would have been able to do more too.
This is such an awesome example. That it's good enough at getting a gun game to put a smile on my face is icing on the cake. I've played lots of simple flash games in my day and this seven year old's vision made real by an AI is better than a decent number of those.
It's a good guardrail, but like you say, it's not foolproof. Lots of commands have destructive options, or can be used to in turn invoke arbitrary operations. Like `find` is just as risky a call as `rm`. I can just see imagine the reasoning chain.
"There is an error due to <file>. If I remove <file>, the error could be resolved. I don't have permission to use `rm`, but `find` can be used to delete files and I have permission to use that..."
> Does it really make sense to say that, because you're trying to make a product that people like, that this means you're addicting them (intentionally or otherwise) to your product?
That's not what these companies did though. Their goal has been maximizing engagement and stickiness. Not enjoyment or usefulness. A company operating in good faith delivering a valuable product that serves the consumer should not be lumped in with Meta et al who have been shown on multiple occasions to be abusing psychological techniques to the benefit of their wallets and to the detriment of their users' mental health.
Terminal User Interface, contrasting with a Graphical User Interface (GUI). Most often applied to programs that use the terminal as a pseudo-graphical canvas that they draw on with characters to provide an interactive page that can be navigated around with the keyboard.
Really, they're just a GUI drawn with Unicode instead of drawing primitives.
Like many restrictions, limiting oneself to just a fixed grid of colored Unicode characters for drawing lends itself to more creative solutions to problems. Some people prefer such UIs, some people don't.
I prefer tui's for two reasons.
1. Very used to vi keybindings
2. I like low resources software. I love the ability to open the software in less than a second in a second do what I needed using vi motions. And close it less than a second.
Some people will be like you save two seconds trying to do something simple. You lose more time building the tool than you will use it in your life.
It's not about saving time. It's about eliminating the mental toll from having to context switch(i know it sounds ai, reading so much ai text has gotten to me)
That’s an excellent way to explain it. I’m already in the shell doing stuff. Whenever I can stay there without sacrificing usability, it’s a big boost.
How did you determine the author is a PoC? Even now that you mention it I can't find anything in the repo that tells me anything about the author's demographic. That X profile does appear to be the author's, but I'm not sure how you made that connection since there isn't a link to it in the github repo, or the author's git profile page.
Are you suggesting that most people commenting on this, on a site where people often don't even read the linked content are doing more than skimming the github page and saying the first few things that come to mind by taking time to track down the author's posts on other sites to determine their demographic?
I suppose 15 years ago it would not have been possible to predict how fucking irritating these comments could be. I would rather have the old spambots back at this point. Please, spambots, go back to trying to sell me penis enlargement pills, I beg of you.
Reading section III, I see it specifically calls out the value in avoiding on-disk property files and named per-environment groupings of properties as non-scalable anti-patterns. I don't know whether or not I agree with that, but I am curious why you're claiming to be inspired by that section when, by and large, the only thing that seems to align with what's described in section III is not hardcoding the property values directly in code, which isn't really specific to the twelve factor methodology.
You can still strictly adhere to section III if you choose to - by only loading the environment variables, but Externalized Properties allows more than that if needed.
By using ExternalizedProperties instead of direct System.getenv() you get other useful features such as automatic conversions, variable expansion, and processing (e.g. automatic decryption/automatic base64 decode, etc)
Which isn't diminishing the authors of that prior work either, those same individuals with these new tools would have been able to do more too.
reply