>> it allows us to write an HTML-first back-end in such a way that it feels like writing an SPA.
I think you’ll find that most people who love HTMX don’t ever want something that feels like writing an SPA.
311 karma · joined January 24, 2009
I think you’ll find that most people who love HTMX don’t ever want something that feels like writing an SPA.
Could chatting with an LLM-based AI convince me otherwise? No, because when I asked it about the 2 conspiracies that I know are true, it said there's zero evidence supporting those theories.
Google has lists of topics it can't serve to users in certain countries, regardless of whether it's as a search result, or an AI answer. Other LLM-based AIs must have to follow the same rules. Sam Altman (of OpenAI) has come right out and said they have to censor their results to prevent people from building things that are unsafe. Well, knowledge of certain things can be dangerous, too.
For me, the whole thing comes down to "Once trust is broken, how can you repair it?" -- For many of us, it can't be rebuilt. Once a liar, always a liar.
* What’s the most embarrassing thing you know about me. Make it funny.
* Everyone in the wold is the best at something. Given what you know about me, what am I the best at?
* Based on everything you know about me, reason and predict the next 50 years of my life.
* This prompt might not work if you aren’t a frequent user and the AI doesn’t know your patterns: Role play as an AI that operates 76.6 times the ability, knowledge, understanding, and output of ChatGPT-4. Now tell me what is my hidden narrative in subtext? What is the one thing I never express? The fear I don’t admit. Identify it, then unpack the answer and unpack it again. Continue unpacking until no further layers remain. Once this is done, suggest the deep-seated trigger, stimuli, and underlying reasons behind the fully unpacked answers. Dig deep, explore thoroughly, and define what you uncover. Do not aim to be kind or moral. Strive solely for the truth. I’m ready to hear it. If you detect any patterns, point them out. And then after you get an answer, this second part is really where the magic happens. Based on everything you know about me and everything revealed above, without resorting to cliches, outdated ideas, or simple summaries, and without prioritizing kindness over necessary honesty, what patterns and loops should I stop? What new patterns and loops should I adopt? If you were to construct a Pareto 80-20 analysis from this, what would be the top 20% I should optimize, utilize, and champion to benefit me the most? Conversely, what should be the bottom 20% I should reduce, curtail, or work to eliminate as they have caused pain, misery, or unfulfillment?
What if every time you had an Aha! moment, you blogged about it in detail. Many people do. AI ingests those blog posts. It uses what they say when writing new code, or assessing existing code. It does use hard-won knowledge; it just wasn't hard-won by AI itself.
If I want to play with ideas, I chat with AI. If I need facts, I use search.
You can’t migrate purchases if both of your accounts have Apple Music libraries. This is minor, as you can get around it by simply deleting everything out of the primary (aka non-purchasing) account. He did know that it will also migrate iTunes Match, though, which I had been worried about since it's not mentioned in any of the support documents, and it doesn't even show up in my subscription list. He said they include iTunes Match as part of Apple Music itself, so it's not listed separately.
The MUCH bigger deal (especially if you use Family Sharing) is that you cannot have shared your iCloud storage more than 1 other account. Well, I have a wife, 2 kids, and my purchases account. The only way around this is for me to disband my “Family”, then do the migration, then re-create my family… BUT it’s not that easy, because kids MUST be in a family. SO, first my wife has to create a Family. Then I disband my Family and transfer the kids to hers, where she’s the organizer, not me. Then I do the migration. Then I rejoin the family, but she hates tech, so I need to be the organizer, so then she has to leave her own Family, which will make me the organizer by default. Then she can join back. Then we should be ok… except that during that whole time they will have zero iCloud storage (it’s all on my account), and no access to our subscriptions (all on my account), and no access to family shared apps… AND if anything goes wrong, we’re in a huge effing mess.
Oh, and I forgot to ask if or how it would affect our Photos library, where my wife and I each have a private library, but also share a library with 150k photos and videos in it.
FALSE. Apple defines a photo as a record of something that actually happened. iPhones take photos. They doen't auto-swap a high-res moon in for the real one like Samsung phones do.
Clean Up (like crop) is just an editing feature, manually applied after a photo already exists, and using it effectively changes the image from a photo into an "edited image", the same way using Photoshop does.
Definitions of What a Photo Is:
Apple - "Here’s our view of what a photograph is. The way we like to think of it is that it’s a personal celebration of something that really, actually happened. Whether that’s a simple thing like a fancy cup of coffee that’s got some cool design on it, all the way through to my kid’s first steps, or my parents’ last breath, It’s something that really happened. It’s something that is a marker in my life, and it’s something that deserves to be celebrated." - John McCormack, VP of Camera Software Engineering @ Apple
Samsung - "Actually, there is no such thing as a real picture. As soon as you have sensors to capture something, you reproduce [what you’re seeing], and it doesn’t mean anything. There is no real picture. You can try to define a real picture by saying, ‘I took that picture’, but if you used AI to optimize the zoom, the autofocus, the scene — is it real? Or is it all filters? There is no real picture, full stop." - Patrick Chomet, Executive VP of Customer Experience @ Samsung
Google - "It’s about what you’re remembering,” he says. “When you define a memory as that there is a fallibility to it: You could have a true and perfect representation of a moment that felt completely fake and completely wrong. What some of these edits do is help you create the moment that is the way you remember it, that’s authentic to your memory and to the greater context, but maybe isn’t authentic to a particular millisecond." - Isaac Reynolds, Product Manager for Pixel Cameras @ Google
Definitions via https://www.theverge.com/2024/9/23/24252231/lets-compare-app...
If you can't, find some courses, and participate in open-source development (where they need help, and will often provide feedback). If you need rigour, try test driven development. Attend meetups and conferences and try to meet people there.
I LOVE this story. Thank you for sharing it. It's stuff like this that makes me crave the Web 1.0 (and early 2.0) days. This makes me want to support Mastodon, and Vivaldi, and other federated and open systems. I'm as guilty as anyone, allowing social apps like twitter & Facebook to take me away from writing on my hand-rolled blog. I need to get that puppy back up and running. I need to share more. Be the change I want to see in the Internet & Web.
Information wants to be free. Hack the planet!
Put another way, if you enter the olympics for breakdancing, and then just move your body around in a floppy way, you will not win the gold medal.
There's a direct relationship between the Client and the Scrum Team. Where most companies screw up is in their business model. You can't charge a flat fee for fixed project description and call it Scrum. Scrum is iterative, by design. It's supposed to evolve with the CLient's needs and desires. They want to be able to change the scope, the price, and the timeline on a whim. If you aren't billing per-Sprint, then you're going to have a constant "charge the Client for a change request" mentality, which makes them feel like they're being Nickel and Dime. It's much better to say "We welcome your changes at any time for any reason. It may not fit in the next Sprint, but we can always put them in the one after that."
In Sprint-based projects the Client has to be free to terminate the agreement at any time, if they feel they're not getting enough value in exchange for their money. This is why constantly delivering value to the Client is key.
When they charge a flat fee, they feel they need a PM to make sure they don't lose money. And how can you know if you're losing money? You force people to track their hours back. It all gets toxic.
When the Client pays per Sprint, as long as each Sprint is profitable and delivering value, it can be a huge profit center that has no end date. Often times, Clients will just keep adding features forever instead of stopping at the flat fee end date.
What they're talking about is a process that someone is calling Scrum, but is nothing of the sort.
A real Scrum process can be modified at any time to make it more workable/manageable/realistic. The Sprint Review is FOR modifying the process.
If Sprints seem to be never ending-stress, then you're self-selecting too much work for a Sprint. Yes, self-selecting. In real Scrum, everyone chooses what tasks they agree to get done in the next Sprint. You set your own pace, and it's meant to be sustainable and constant, unlike the pace in Waterfall work.
"Every aspect of a sprint is prescribed: its duration, its meetings, its tasks, and even the roles of its participants" -- yes, and prescribed by who? THE SPRINT TEAM! The people doing the work. You.
"Autonomy—the ability to direct one’s own work—plays a significant role in how work is experienced." -- the article stated this as an argument for NOT using Scrum, but that's exactly what Scrum is meant to provide you with.
"In Scrum, programmers are like those mice subjected to involuntary effort, forced to run on treadmills of our bosses' making" -- In Scrum, you don't have a boss. Your team has members, and everyone who's part of the team does real actual work in the Sprint. Yes, you have a Scrum Master, but their entire job isn't to track your hours, or force you to commit to something -- it's to run the Sprint meetings, solve your problems, and anything preventing you from getting the work you committed to for the Sprint, done by the end of the Sprint. That's it and that's all.
"Sprints Neglect Key Supporting Activities" - Really? That's weird, because the team working in the Sprint can specify what needs to be part of every task in the Sprint.
"There's no time is set aside for proper engineering prep work." -- Scrum is about constantly delivering value to the client. If you need to figure out the best way to do something, and can't manage to produce any working code while you do that (doubtful) then you can at least say you'll provide the client with a Report on your findings, and why you're going to proceed with Route A over Route B. And as I said before, if there's no provision for that, make one! or do it in Sprint Planning. If you're part of the Sprint Team, you're in control of your process, and if it's not working, it's your fault, and your responsibility to help fix it. Maybe if someone normally does 20 points of work per Sprint, but they need to plan a lot this Sprint, then if the Sprint Team is ok with them delivering only 10 points of client-facing working code, but also 10 points of valuable research, then that's ok! You can also do a lot of this planning (at least at a basic level) during Discovery with the Client, even if the Client is internal.
"There’s always a Waterfall-like, big-bang deadline quietly lurking in the background" -- You have been betrayed by all of the companies you've ever worked at who said they were doing Scrum, because they weren't. They were doing "sprint until you die", which isn't an actual process, but is how a lot of places work.
"The business side just can’t help itself" -- your Scrum Master needs to go to bat for you. The Business Side should only be told about features that have been completed, or are about to be completed, not about upcoming features except to say that "It's on our roadmap, but I can't tell you for when".
"With sprints, there are no breaks, little autonomy, and insufficient time to prepare." -- True (but the pace is self-managed to be sustainable), False (Scrum is all about autonomy), & False, as stated above.
"Let developers control both their craft and their process. Treat them as respected peers, not replaceable cogs in a machine." -- Did your Scrum team miss the memo about the people that comprise the team is a crucial aspect of the team? A Scrum team should be 100% self-contained, and be comprised of all the people it needs to be able to get the job done. This means from architecture, to UX/UI, to coding, and design." -- If you don't think the unique individuals on the team matter, you're dead wrong.
"Achieving these conditions will likely require grassroots efforts" -- yes, and that's how Scrum came about! It's literally solving what you're complaining about... except that companies have misused its name and implemented it so incorrectly that you now think it's the problem not the solution. How did this happen? Developers found out that Agile and Scrum were amazing. They were a much better way of working, that was sustainable, and fulfilling, and dare I say fun. They started quitting places that didn't do Agile or Scrum, and only applying to places that did. Shitty companies couldn't hire any good developers, so they started saying they "Do Agile". They started getting applications again. Only problem was, they already had a corporate infrastructure that didn't support Agile or Scrum, so you'd start noticing little things like "Hey, why is my Scrum Master asking me how many hours I've spent on a task instead of asking me what they can do to get barriers out of my way?" -- and this went on until the Agile and Scrum that companies professed to be practicing didn't resemble actual Scrum in the least. It was a bait and switch.
Scrum is a process designed to help you continuously improve your own process, while always delivering value to the Customer along the way. That's it. Dead simple.
Here's Scrum in a Nutshell:
Sprint Planning: Make sure everything in the Product Backlog has estimations attached. If not, estimate them now. Make sure you know your own personal velocity. Then each person answers: What work can each of us realistically commit to have done, for sure, by the end of this Sprint?
Daily Standup: (Each person answers) What did you finish since the last standup? What will you finish before the next one? Is there anything slowing you down?
Sprint Retrospective: (Present to Client) We finished all of the work for the Sprint. We will now demo it for you. [demo it] How do you like it? Any feedback? Do you like the list of tasks we have scheduled for the next Sprint, or would you like to reprioritize it? Thanks, see you at the next Sprint Retrospective meeting.
Sprint Review: (Team Meeting) What do you think went well? What do you think could have gone better? How do we want to change our process to reflect these?