The documentation complaint is true of many, maybe all, AWS services: they discuss multiple generations, address multiple target audiences, and range wildly in currency and relevance, from marketing material to technical deep dives, all intermixed.
Cognito itself is a very AWS tradeoff. It's delightfully inexpensive. It quite effectively protects one of the most relentlessly attacked parts of any web service. It supports workflows essential as you scale, like SAML federation ("single sign on/SSO"). It basically works, day in and day out.
But OMG, the sharp edges! It has sharp edges to spare, even compared to other AWS services, for which sharp edges and exposed corners are just par for the course.
Then you try to go the next step, e.g. add multi-region disaster recovery and failover. That seemingly straightforward requirement to scale up is "left as an exercise for the reader."
Cognito has all the virtues of a utility service, including the developer experience.
I'm surprised CGI is still used when there's alternatives like FastCGI which are a little smoother. I'm not a Perl guy, only Perl I ever did is try out Mojolicious which is a sleek web framework (looked to me like it at the time anyway) I have this habit of judging programming languages by what their web frameworks look like, and so I build small sample web apps, APIs and what not just to see what coding in said language is like. I didn't hate Mojolicious, but I don't see a future in Perl for myself, my whole career has been C# and Python (and a half dozen others).
Prosody is hard. No AI voice I've heard really nails voice generation with fully smooth and human-like cadence and quality, but they're gradually getting better. Airy voices sound a bit tinny and childish, but even so, they're better than many I've heard, including for the elusive "humanness" quality.
The curse of dimensionality times the reality that good metrics are elusive or themselves a bit cursed. Many outcomes you're engineering or product-managing toward are quite squishy, hard to define, and hard to evaluate. "Easy to use" or "can be used within 10 minutes" or "cleans up this current order form" are easy to state but hard to rate and/or hard to actionably implement as metrics.
I've built large, deep product evaluation frameworks, and it is 100% of the time a running argument with stakeholders, inside and out, "well you should have measured it this way" or "I think we should be targeting X not Y" or "why didn't you consider Z in the metric??"
The Pareto Front in practice is squishy, fuzzy, and often quite moist and moldy.
That may be your preference, but it's quite contrary to mine.
I have successfully used AI to generate generates "concept art" and logos for projects, presentations, and publications. It seems to make the outcomes more approachable, more understandable, and certainly more aesthetically pleasing.
It is not a matter of replacing human effort or skill, and certainly not a matter of adding cheap ornamentation. If AI weren't available, I usually wouldn't have the time, money, energy, or will to pursue those illustrations. I say this as someone who has historically spent what seems like a vast amount of time, energy, and money sourcing art. In a former life as as publisher I even hired full-time artists and insisted on custom artwork. But my current work no longer has that luxury. I still want the best possible looks, and the best possible outcomes.
See other top HN article rn about "expertise is essential for using LLMs". Nobody is debating whether illustrators, graphic designers or marketers are going to use AI. In addition to being a thoroughly sailed ship, the sheer demand for constant content and image generation makes it a job skill at this point.
TFA is about blogs written by people with non-graphic expertise, who think it's great to, e.g., punctuate every other point with a way-too-detailed picture of a panda bear coder orchestrating fleets of squirrel agents. (Yes I'm looking at you Steve Yegge.) Nobody needs to be abused with this crap, and it all has the same overpolished overdetailed look, the "it's too good to be drawn by the author but is obviously NOT drawn by anybody with any visual sense".
It's not just blogs -- bands are now making these ridiculous "pro" fliers, food carts have stupid pictures of their owners on them -- but in blogs that ostensibly are written by humans for humans, AI images are worse than distracting and a very negative signal.
I complied Kermit for IBM's AIX in ~1989 as a study in "how compatible is AIX to other Unixes?" Kermit source code remains the high-water mark in my memory for how many different, incompatible, non-standard platforms one piece of software can support. More than even Unix itself, as it could also run on VMS and non-Unixes of the time. I have never in my life seen so many `#ifdef`s and such complicated "Am I running on this platform or that one? Does it have this feature or that feature? No, what about this other one? Is it HP-UX maybe? HP-UX 6? No, 7? No, 8? No, what about VMS? No, how about SunOS? No, how about Unix System III?" ...on and on, seemingly endlessly.
Kermit was an extraordinary monument to portability in an era when "portable" often meant "we have individually accommodated every incompatible system anyone has ever built or might possibly still be using, however improbably."
Which is interesting because most autoconf programs I've seen do the opposite. They have all these defines and then don't use them. Just seems like a waste of time. Cmake has been better but still sometimes cmake will pass and the code still doesn't build
There was for a brief period a Middle Path, called libiberty (now mostly subsumed into gnulib). It generated GNU-compatible shim functions for whatever system you happened to be on that translated those calls into the native calls. So you wrote one clean GNU-esque codebase and gnulib patched together essentially a translation layer for it when you built.
That was one ethos that was taught at the UC Davis CS program in the 90's-00's. They had clusters of IRIX, Linux, Sun, HP-UX, and (sometimes) MINIX boxes. Homework and lab projects would be nondeterministically graded on any except MINIX. It was also beneficial to add portability for Windows with MS and/or Borland toolchains for some projects. BSD sockets was pretty cross-platform with some idiosyncratic gotchas per platform.
It saddens me whenever someone or a group religiously tie their opinions or assumptions to a particular platform and irrationally scoff at others or refuse to consider that other things exist, are used, and function.
The office-document format wars played out _at least_ twenty years ago.
The path dependence and "everyone uses it" (installed base) inertia of Microsoft's formats continue to benefit Microsoft (and its OOXML formats), despite ODF being more open and, in many ways, superior--not least because it's easier to implement, manipulate programmatically, and reason about.
But refighting that battle seems pointless. Users and the market have moved on, not least toward cloud-based tools; file formats no longer seem the primary barrier to competition.
reply