It turns out, JavaScript provides a method of "trapping" nearly any operation on an object - property access, assignment, enumeration, and even property deletion. How? Via a Proxy. Think of a Proxy as a "hook" or "middleware" that can be used to gaslight the caller into seeing the proxied object any way you want them to see it. When you wrap an object in a Proxy, you can do almost anything you imagine - hide properties like I did with goodbye above, invent new "virtual" properties, or even make operations on properties "cursed":

 

Screen reader testing is notoriously difficult, and can be slow. It’s usually because it needs to be done manually, and although developers and testers often know how to write automated acceptance tests, like the tests I wrote in the TetraLogical Accessible Components Library, this type of automation is not usually easy to apply to assistive technologies.

But, what many people don’t know, is that VoiceOver on macOS has an AppleScript dictionary, and we can drive it from the terminal. This means we can boot up VoiceOver, move the virtual focus around, and capture what VoiceOver says, all fully automated. The functionality has been there for years, but hardly anyone uses it. Because, presumably, writing AppleScript isn’t most people’s idea of a fun afternoon!

[–] [S] 4 points 8 months ago

There are some really good tips on delivery and best practice, in summary:

Speed comes from making the safe thing easy, not from being brave about doing dangerous things.

Fast teams have:

  • Feature flags so they can turn things off instantly
  • Monitoring that actually tells them when something’s wrong
  • Rollback procedures they’ve practiced
  • Small changes that are easy to understand when they break

Slow teams are stuck because every deploy feels risky. And it is risky, because they don’t have the safety nets.

  • source
  • [–] 2 points 8 months ago (2 children)

    I try to stay well read on AI, and I regularly use Claude, but I'm not so convinced by this article. It makes no mention of the bubble that could burst. As for the models improving aren't the improvements slowing down?

    More importantly, the long term effects of using AI are still unknown, so that for reason the adoption trajectory could be subject to change.

    The other factor to consider is that the author of this article is a big investor in AI. It's in his interest to generate more hyperbole around it. I have no doubt that generative AI will forever change coding, but but I have my skepticism about other areas, especially considering the expensive controversy of Deloitte using AI to write reports for the Australian government.

  • source
  • [–] [S] 6 points 9 months ago (1 child)

    What I'm saying is the post is broadly about programming, and how that has changed over the decades, so I posted it in the community I thought was most appropriate.

    If you're arguing that articles posted in this community can't discuss AI and its impact on programming, then that's something you'll need to take up with the moderators.

  • source
  • parent
  • context
  • [–] [S] 14 points 9 months ago (5 children)

    In fact, this garbage blogspam should go on the AI coding community that was made specifically because the subscribers of the programming community didn't want it here.

    This article may mention AI coding but I made a very considered decision to post it in here because the primary focus is the author's relationship to programming, and hence worth sharing with the wider programming community.

    Considering how many people have voted this up, I would take that as a sign I posted it in the appropriate community. If you don't feel this post is appropriate in this community, I'm happy to discuss that.

  • source
  • parent
  • context
  • [–] [S] 5 points 9 months ago (4 children)

    Regardless of what the author says about AI, they are bang on with this point:

    You have the truth (your code), and then you have a human-written description of that truth (your docs). Every time you update the code, someone has to remember to update the description. They won't. Not because they're lazy, but because they're shipping features, fixing bugs, responding to incidents. Documentation updates don't page anyone at 3am.

    A previous project I worked on we had a manually maintained Swagger document, which was the source of truth for the API, and kept in sync with the code. However no one kept it in sync, except for when I reminded them to do so.

    Based on that and other past experiences, I think it's easier for the code to be the source of truth, and use that to generate your API documentation.

  • source
  • view more: ‹ prev next ›