I've always been very much in favour of UX and a11y over DX but, if you don't provide good DX, developers can produce some truly horrible UX and a11y. Can't win.
Just turned the radio on. See two pileups on 30m CW. Look them up on dxsummit.fi. See that CB0ZA (Juan Fernandez Island), off the coast of Chile (see below) is calling CQ on 10115 kHz. I listen for a bit to see who he's calling, set my transmit frequency, and work them on the first call! That's my kind of DX. :) #hamradio#DX
"Our research and evaluation shows that there are currently few design-specific AI tools that meaningfully enhance UX design workflows." -- #CalebSponheim#MeganBrown
feature request for PhpStorm: when the break points are muted, please change the background color of the dubug console, and display a message “break points are muted” above the debug console.
I just lost 30 minutes because i couldn’t figure out why Step Debugging wasn’t working. I’m certain that’ll happen again. Please JevBrains - you’re my only hope
Just made my first international DX a few minutes ago on 10m. JG1HQA was on the air from Tokyo Bay calling CQ when I was scanning the band, and to my great pleasure he was able to receive my signal! #amateurradio#DX#ham_radio
I am new to #amateurradio and on the way to my license. I am here for the #hamradio content to learn and to connect with other people. I am from #germany and also a fan of #draussenfunker.
I am interessed in #pota and #dx and can‘t wait to have my first #qso.
#APIs#APIDocumentation#DX#TechnicalWriting#SoftwareDocumentation: "Finding the right balance between being too simple and too sophisticated isn't easy. You might get away with a generic onboarding how-to guide if your API focuses on one single feature (as OpenCage does). Otherwise, you need to craft different onboarding experiences for each one of the consumer use cases you want to support.
One thing that works for me is learning as much as I can from consumers before writing any API documentation. Then, I focus on the top use cases potential consumers are interested in. Since those will be the top entry points for most new API users, I prepare a tutorial for each. Each tutorial offers a safe environment where developers can easily sign up to use the API. Then, by following the steps in the tutorial they will end up implementing the integration that fulfills their use case."
It all comes down to helping your API consumers integrate faster. When people decide to integrate with your API, they have a job they want to get done. They think your API could be the fastest path to solving it. But too often, building an integration with the API is as painful (or even more painful) as the original job. That’s counterproductive, to put it mildly. There are a hundred things your users would rather be doing than reading your API docs and writing basic integration code. The less you require of them, the happier they’ll be. And SDKs are the best tool for making sure your API remains unobtrusive.
The definition of an SDK is straightforward: It’s a library that surrounds your API and handles the boring parts of the integrating process, such as:
Constructing an HTTP request
Managing an authentication token
Handling retries
Parsing paginated responses
More powerful SDKs will go beyond request and response-handling basics and provide type safety and hinting in the integrated development environment (IDE). This means users don’t have to open a docs page; they’ll get all the information and feedback they need directly in their coding environment. It doesn’t get more efficient than that."