Suche
Beiträge, die mit softwaredevelopment getaggt sind
i have released my second #blog post and it's about my main software project for my own little use case.
it hope that it can inspire people to write code to solve their own small problems!
#dev #softwaredevelopment #walkman #linux #foss #python #coding
https://blog.myiu.de/2025/03/how-i-made-playlists-work-on-my-sony-walkman-under-linux-and-then-improved-them/
it hope that it can inspire people to write code to solve their own small problems!
#dev #softwaredevelopment #walkman #linux #foss #python #coding
https://blog.myiu.de/2025/03/how-i-made-playlists-work-on-my-sony-walkman-under-linux-and-then-improved-them/
When I was working on my first Django project, I encountered a problem where modifications done inside pre_save signal were not stored in the database. Back then it took me a couple of hours to figure out what is wrong and how to fix it. I’m sharing what I’ve learned to save that time someone else.
https://mirekdlugosz.com/blog/2025/django-data-modified-in-pre-save-signal-is-not-saved/
#python #django #programming #bugs #blog #software #softwaredevelopment
https://mirekdlugosz.com/blog/2025/django-data-modified-in-pre-save-signal-is-not-saved/
#python #django #programming #bugs #blog #software #softwaredevelopment
"Getting to this point isn’t unusual. Clients clearly think they’re making the call correctly, or else they would fix the endpoint themselves. Some misspellings are difficult to catch. The enum USER_RETREIVE may not be noticed from USER_RETRIEVE, especially if picking it from a list. Misspellings happen and they’re not always caught before making it to the contract. As an aside, that’s why it’s important writers routinely check development’s changes. This applies, too, to our testing calls in Postman, where manually entering endpoints and values are more pervasive.
The reason this isn’t caught is simple: We’re not expecting it.
For our testing, the call is made and we get results. We may even spot check some of them. But generally, results aren’t examined that closely. For instance, how often do you so carefully examine a returned list of 50 or 100 items? You check may check that the objects are complete but not that the list conforms to the search criteria.
The reason this happens is because of an intentional behavior on the server. This behavior is called Lenient Handling or Strict Handling."
https://robertdelwood.medium.com/understanding-query-parameter-handling-in-rest-calls-1821e0c3fa8c
#APIs #RESTAPIs #Rest #APITesting #APIDesign #APIDocumentation #SoftwareDevelopment
The reason this isn’t caught is simple: We’re not expecting it.
For our testing, the call is made and we get results. We may even spot check some of them. But generally, results aren’t examined that closely. For instance, how often do you so carefully examine a returned list of 50 or 100 items? You check may check that the objects are complete but not that the list conforms to the search criteria.
The reason this happens is because of an intentional behavior on the server. This behavior is called Lenient Handling or Strict Handling."
https://robertdelwood.medium.com/understanding-query-parameter-handling-in-rest-calls-1821e0c3fa8c
#APIs #RESTAPIs #Rest #APITesting #APIDesign #APIDocumentation #SoftwareDevelopment
A fellow engineer was uncertain how they should spend their limited time - should they test the new thing and work on automation later, possibly after the release? Or should they start writing automation right away, but risk finding important issues close to the release date? My answer is on the blog:
https://mirekdlugosz.com/blog/2025/testing-a-new-feature-should-you-start-with-automation-or-by-inspecting-it-yourself/
#Testing #Automation #automatedtesting #blog #softwaredevelopment
https://mirekdlugosz.com/blog/2025/testing-a-new-feature-should-you-start-with-automation-or-by-inspecting-it-yourself/
#Testing #Automation #automatedtesting #blog #softwaredevelopment
Testing a new feature - should you start with automation or by inspecting it yourself?
A fellow engineer submitted a question to internal mailing list. The gist is: a new feature is supposed to be released in a few months and there is no automation coverage for it.Mirek Długosz personal website
"A quick start guide offers concise step-by-step instructions to help users quickly get started with a product, service, or tool. In the context of API documentation, a quick start guide covers the minimal steps required for developers to make their first API call successfully. It typically provides steps such as how to create an account, where to locate API keys or credentials, how to authenticate, example code to make a basic API call, a way to display the response, and troubleshooting tips. The goal is to deliver a quick win to developers and provide a foundation to integrate with your API."
https://www.apimatic.io/blog/how-to-design-a-quick-start-guide-for-your-api
#TechnicalWriting #APIs #APIDocumentation #SoftwareDocumentation #GettingStarted #Tutorials #SoftwareDevelopment #DE #DeveloperExperience
https://www.apimatic.io/blog/how-to-design-a-quick-start-guide-for-your-api
#TechnicalWriting #APIs #APIDocumentation #SoftwareDocumentation #GettingStarted #Tutorials #SoftwareDevelopment #DE #DeveloperExperience
How to Design a Quick Start Guide for Your API
Learn how Quick Start Guides help developers, what makes a good quick start guide and an example of a quick startSid Maestre (APIMatic Limited)
"4. You’re not just a writer, you’re an advocate for clarity
I thought being a technical writer meant simply explaining what someone else built. But it’s so much more than that. You’re there to simplify complexity, anticipate user needs, and advocate for clarity.
Why it’s key: A good writer doesn’t just document systems, they improve them. In most cases, you should be the first real user of a new feature. Your fresh perspective can highlight gaps and improve the overall experience."
https://bufferbuffer.com/10-things-i-learned-the-hard-way-about-technical-writing-in-tech/
#TechnicalWriting #SoftwareDocumentation #Documentation #Docs #SoftwareDevelopment
I thought being a technical writer meant simply explaining what someone else built. But it’s so much more than that. You’re there to simplify complexity, anticipate user needs, and advocate for clarity.
Why it’s key: A good writer doesn’t just document systems, they improve them. In most cases, you should be the first real user of a new feature. Your fresh perspective can highlight gaps and improve the overall experience."
https://bufferbuffer.com/10-things-i-learned-the-hard-way-about-technical-writing-in-tech/
#TechnicalWriting #SoftwareDocumentation #Documentation #Docs #SoftwareDevelopment
"Normally, you don't visit your own API documentation that often, right? I mean, if you already know how your API works, why would you want to consult its documentation? Conversely, there's a place you visit—or should visit—very often, with information you care about your API. I assume you have an API dashboard where you can review metrics such as the ones I described earlier. Usually, the dashboard lives close to the API gateway, or somewhere where other company-wide observability tools reside. What I'm proposing here, in short, is that the API documentation can be the best place to present those metrics to you, the producer.
Being able to see the metrics you care about right near the documentation for each part of your API feels refreshing. You could, for instance, be looking at the reference of one operation and immediately see its usage trend, the error rate, the number of active consumers in the last hour, and so on. What's more, some of the information visible only to you could also be actionable. You could, for instance, open the pending support requests to see what the top complaints are. Or, you could immediately check why there's such a percentage of errors on one single operation.
While most information would be restricted to you, the producer, I argue that some things could even be openly shared with your API consumers. Imagine being a consumer and seeing a list of "popular" API operations right on the documentation. Or understanding if a certain operation is producing a high error rate. All these things could be easily available in the API documentation."
https://apichangelog.substack.com/p/producer-oriented-api-documentation
#TechnicalWriting #APIs #APIDocumentation #SoftwareDocumentation #APIMetrics #APIAnalytics #SoftwareDevelopment
Being able to see the metrics you care about right near the documentation for each part of your API feels refreshing. You could, for instance, be looking at the reference of one operation and immediately see its usage trend, the error rate, the number of active consumers in the last hour, and so on. What's more, some of the information visible only to you could also be actionable. You could, for instance, open the pending support requests to see what the top complaints are. Or, you could immediately check why there's such a percentage of errors on one single operation.
While most information would be restricted to you, the producer, I argue that some things could even be openly shared with your API consumers. Imagine being a consumer and seeing a list of "popular" API operations right on the documentation. Or understanding if a certain operation is producing a high error rate. All these things could be easily available in the API documentation."
https://apichangelog.substack.com/p/producer-oriented-api-documentation
#TechnicalWriting #APIs #APIDocumentation #SoftwareDocumentation #APIMetrics #APIAnalytics #SoftwareDevelopment
Producer-Oriented API Documentation
If API documentation is so important to consumers, how can it also help producers succeed?Bruno Pedro (The API Changelog)
#Blog rewind, part 3!
My least viewed post. I thought this one would resonate more.
How could this one have been more valuable? Closer to what I normally write about? Not interesting? Not technical?
#SoftwareTesting #SoftwareDevelopment #Automation
https://responsibleautomation.wordpress.com/2024/09/10/why-so-many-clicks-and-how-can-testing-and-automation-help/
My least viewed post. I thought this one would resonate more.
How could this one have been more valuable? Closer to what I normally write about? Not interesting? Not technical?
#SoftwareTesting #SoftwareDevelopment #Automation
https://responsibleautomation.wordpress.com/2024/09/10/why-so-many-clicks-and-how-can-testing-and-automation-help/
Why So Many Clicks And How Can Testing And Automation Help?
Many years ago, back when I worked for a telecom company, we were building what we called a test automation platform. It was more than what we currently call a test tool; it was a system in which w…Responsible Automation
#Blog rewind, part 2!
This is the post that seemed to have the most views, possibly it's one of my most dev-centric and it solved an issue for, I suspect, many people
Enjoy!
#SoftwareTesting #Automation #Testing #SoftwareDevelopment
https://responsibleautomation.wordpress.com/2023/07/13/i-did-it-ui-automator-viewer-running-on-a-current-java-version/
This is the post that seemed to have the most views, possibly it's one of my most dev-centric and it solved an issue for, I suspect, many people
Enjoy!
#SoftwareTesting #Automation #Testing #SoftwareDevelopment
https://responsibleautomation.wordpress.com/2023/07/13/i-did-it-ui-automator-viewer-running-on-a-current-java-version/
I Did It! UI Automator Viewer Running On A Current Java Version
I did a thing! I made Android Studio’s UI Automator Viewer run on Java 20! Some of you might be saying, “Duh, doesn’t everyone already do that?”. I don’t know the answer to that question, but based…Responsible Automation
#Blog rewind!
As a surprise to me, my most-read blog post during 2024, was not the one I expected; that's probably due to this specific post being reposted evelopment website. Here's that post!
#SoftwareTesting #Automation #SoftwareDevelopment #Testing
https://responsibleautomation.wordpress.com/2018/02/01/heresy-ii-comments-are-code/
As a surprise to me, my most-read blog post during 2024, was not the one I expected; that's probably due to this specific post being reposted evelopment website. Here's that post!
#SoftwareTesting #Automation #SoftwareDevelopment #Testing
https://responsibleautomation.wordpress.com/2018/02/01/heresy-ii-comments-are-code/
Heresy II – Comments Are Code
I hold an unpopular stance: code comments are as important as the code itself. OK, maybe that’s a little overstated, but I maintain that code comments are critical to code readability and maintaina…Responsible Automation
#Blog rewind!
As a surprise to me, my most-read blog post during 2024, was not the one I expected; that's probably due to this specific post being reposted evelopment website. Here's that post!
#SoftwareTesting #Automation #SoftwareDevelopment #Testing
https://buff.ly/2EjR5lc
As a surprise to me, my most-read blog post during 2024, was not the one I expected; that's probably due to this specific post being reposted evelopment website. Here's that post!
#SoftwareTesting #Automation #SoftwareDevelopment #Testing
https://buff.ly/2EjR5lc
Heresy II – Comments Are Code
I hold an unpopular stance: code comments are as important as the code itself. OK, maybe that’s a little overstated, but I maintain that code comments are critical to code readability and maintaina…Responsible Automation
"The quality of job descriptions varies wildly. That means how the job is described, the components of the job, and expertise expected for each component. The descriptions are better for the common job types, such as project and product managers, developers, and sales. Companies know what those are and have experience hiring those.
All that falls apart when it comes to writing, of any type, and specifically API documentation writers. CEOs, who I love to vilify for this reason, generally don’t understand technical writing and technical writers. To them, and that attitude often trickles down the table of organization, see copy, marketing, content, and technical writing as the same and interchangeable. I believe this causes the low pay rates, because we’re seen as a commodity, going at market rate. A doctor with 15 years of experience is treated as an expert. A writer with 15 years of experience competes in the marketplace with junior writers. A shame for sure. I digress some but that needed to be pointed out.
There is information to be mined from bad job descriptions, if you know what to look for and know how to use that information."
https://robertdelwood.medium.com/reading-api-documentation-writers-job-descriptions-92124e5d9008
#TechnicalWriting #APIDocumentation #APIs #SoftwareDocumentation #SoftwareDevelopment
All that falls apart when it comes to writing, of any type, and specifically API documentation writers. CEOs, who I love to vilify for this reason, generally don’t understand technical writing and technical writers. To them, and that attitude often trickles down the table of organization, see copy, marketing, content, and technical writing as the same and interchangeable. I believe this causes the low pay rates, because we’re seen as a commodity, going at market rate. A doctor with 15 years of experience is treated as an expert. A writer with 15 years of experience competes in the marketplace with junior writers. A shame for sure. I digress some but that needed to be pointed out.
There is information to be mined from bad job descriptions, if you know what to look for and know how to use that information."
https://robertdelwood.medium.com/reading-api-documentation-writers-job-descriptions-92124e5d9008
#TechnicalWriting #APIDocumentation #APIs #SoftwareDocumentation #SoftwareDevelopment
⚡️ New #Blog Post
Selling Outside of the Mac App Store, Part III: Updates and Release Notes
https://blog.eternalstorms.at/2024/12/20/selling-outside-of-the-mac-app-store-part-iii-updates-and-release-notes/
#indiedev #softwaredevelopment
Selling Outside of the Mac App Store, Part III: Updates and Release Notes
https://blog.eternalstorms.at/2024/12/20/selling-outside-of-the-mac-app-store-part-iii-updates-and-release-notes/
#indiedev #softwaredevelopment
Was sind SBOMs?
Ein neuer Beitrag auf meinem Blog. Grundlagen zum Thema SBOMs.
https://blog.security-manufaktur.de/sbom/bom/cyclonedx/spdx/opensource/oss/2024/12/17/sbom-grundlagen.html
#bom #sbom #sboms #software #softwaredevelopment #softwarebillofmaterials #SoftwareBillsofMaterialSBOMs #dev #devops #development #developer #blog #cybersecurity #security #cyclonedx #spdx #vex
Ein neuer Beitrag auf meinem Blog. Grundlagen zum Thema SBOMs.
https://blog.security-manufaktur.de/sbom/bom/cyclonedx/spdx/opensource/oss/2024/12/17/sbom-grundlagen.html
#bom #sbom #sboms #software #softwaredevelopment #softwarebillofmaterials #SoftwareBillsofMaterialSBOMs #dev #devops #development #developer #blog #cybersecurity #security #cyclonedx #spdx #vex
SBOM: Die Zutatenliste für Software
SBOM – Die Zutatenliste für Softwareprodukted33pjs (Security Manufaktur Blog)
"Writing For Developers: Blogs That Get Read is a practical guide to writing more compelling engineering blog posts.
We discuss strategies for nailing all phases of the technical blogging process: planning, drafting, revision -- even promotion and extension. And we have quite a bit of fun exploring the core blog post patterns that are most common across engineering blogs today, like “The Bug Hunt,” “How We Built It,” “Lessons Learned,” “We Rewrote It in X,” “Thoughts on Trends,” etc. Each "pattern" chapter includes an analysis of real-world examples as well as specific dos/don’ts for that particular pattern. There's a section on moving from blogging into opportunities such as article writing, conference speaking, and book writing. Finally, we wrap with a critical (and often amusing) look at generative AI blogging uses and abuses."
https://github.com/scynthiadunlop/WritingForDevelopersBook/
#TechnicalWriting #SoftwareDocumentation #Blogs #Blogging #SoftwareDevelopment
We discuss strategies for nailing all phases of the technical blogging process: planning, drafting, revision -- even promotion and extension. And we have quite a bit of fun exploring the core blog post patterns that are most common across engineering blogs today, like “The Bug Hunt,” “How We Built It,” “Lessons Learned,” “We Rewrote It in X,” “Thoughts on Trends,” etc. Each "pattern" chapter includes an analysis of real-world examples as well as specific dos/don’ts for that particular pattern. There's a section on moving from blogging into opportunities such as article writing, conference speaking, and book writing. Finally, we wrap with a critical (and often amusing) look at generative AI blogging uses and abuses."
https://github.com/scynthiadunlop/WritingForDevelopersBook/
#TechnicalWriting #SoftwareDocumentation #Blogs #Blogging #SoftwareDevelopment
GitHub - scynthiadunlop/WritingForDevelopersBook: About the book "Writing for Developers: Blogs That Get Read," which is all about writing more compelling engineering blog posts. Available on Amazon as well as Manning. By Piotr Sarna & Cynthia Dunlop.
About the book "Writing for Developers: Blogs That Get Read," which is all about writing more compelling engineering blog posts. Available on Amazon as well as Manning. By Piotr Sarna &a...GitHub
"The Good Docs Project is excited to announce our latest release of documentation templates! This version 1.3 is codenamed Friendship. The Friendship release is inspired by the twenty-seven bridges throughout the world named Friendship, including the pictured Thai-Lao Friendship bridge which connects Thailand and Laos.
One of the other big highlights in the Friendship template release involved the efforts by the Tech Team to standardize our template suite. Led by Bryan Klein, Michael Park, and Alyssa Rock, the Tech Team made several changes to the templates to improve downstream consumption. They standardized the template file naming conventions to ensure consistency, repaired broken links, and ran all the templates through a Markdown linter to ensure it was well-formed."
https://www.thegooddocsproject.dev/blog/release-friendship
#TheGoodDocs #SoftwareDocumentation #TechnicalWriting #SoftwareDevelopment
One of the other big highlights in the Friendship template release involved the efforts by the Tech Team to standardize our template suite. Led by Bryan Klein, Michael Park, and Alyssa Rock, the Tech Team made several changes to the templates to improve downstream consumption. They standardized the template file naming conventions to ensure consistency, repaired broken links, and ran all the templates through a Markdown linter to ensure it was well-formed."
https://www.thegooddocsproject.dev/blog/release-friendship
#TheGoodDocs #SoftwareDocumentation #TechnicalWriting #SoftwareDevelopment
"Asking me what’s my favourite documentation is a bit like asking me what are the best doorways I’ve crossed in my life. We remember places, not open doors; we recall the things we did through software, not great docs. In my case, I seldom remember good or great documentation because its purpose is not to get in the way. On the other hand, I do remember lots of bad documentation when it failed to provide answers. The curse of technical writing is that the best expressions of our work are the ones people rarely notice, because they offer so little friction they never disturb the user’s flow.
There are exceptions to this, of course. The first is documentation that is presented in such a way that it generates a “Wow” moment. Perhaps it’s a code snippet you can run, an interactive demo, or similar gimmicks. While they’re not key to great documentation, they make for some memorable experiences, though that can backfire quickly if the docs aren’t good. The other exception are docs that teach us something new, either through conceptual explanations or examples. Some of the best docs I’ve read are aware that they’re also teaching new ideas and concepts. You can tell because they grin."
https://passo.uno/my-favorite-tech-docs/
#TechnicalWriting #SoftwareDocumentation #Docs #DocsAsCode #SoftwareDevelopment
There are exceptions to this, of course. The first is documentation that is presented in such a way that it generates a “Wow” moment. Perhaps it’s a code snippet you can run, an interactive demo, or similar gimmicks. While they’re not key to great documentation, they make for some memorable experiences, though that can backfire quickly if the docs aren’t good. The other exception are docs that teach us something new, either through conceptual explanations or examples. Some of the best docs I’ve read are aware that they’re also teaching new ideas and concepts. You can tell because they grin."
https://passo.uno/my-favorite-tech-docs/
#TechnicalWriting #SoftwareDocumentation #Docs #DocsAsCode #SoftwareDevelopment
What I say when someone asks me what are my favorite docs
I’m a terrible user of documentation. I tend to consume docs in a hurry, reading diagonally, Control+Fing my way to things. I generally mistreat the interface of docs until I obtain something resembling an answer.passo.uno
"So, if developers aren’t going to use Try Its, what harm is there for including them? They can just ignore them, right? Perhaps, but there’s more to it.
It takes up valuable screen real estate (the right corner above the fold). Writers need to optimize the developer experience, even to the point of minimizing eye movements. Make it easy to find details. That space could be used more productively.
We “should know” but we don’t. This segues into the real reason. It demonstrates that writers don’t know the developer experience. Let’s be blunt. We’re delivering documentation suites that have not been tested properly, calls that are unlikely to have been tested, and tools developers don’t use. Not understanding these issues is the fundamental reason writers also need developer experience. Writers simply can’t empathize with own audiences, which means we supplying developers with inadequate and incomplete tools and documentation. This is a real concern.
This is not a condemnation. Quite the opposite. API documentation writers need to empathize with developers. Writers do this by treating this as a craft, learn a little about development each day, and move slowly along the experience spectrum towards the developer’s end. Learn a language. It doesn’t matter which one. Java, JavaScript, to DOS batch commands, UNIX command line programming, Word macros, Python, or even AutoHotKey*. All of these have programming concepts and that’s what matters. Learn about them, which requires using an API guide, craft statements, and debug them is at the heart of the matter."
https://robertdelwood.medium.com/why-i-dont-like-try-it-f44112ed1b6d
#APIs #APIDocumentation #SoftwareDevelopment #TechnicalWriting
It takes up valuable screen real estate (the right corner above the fold). Writers need to optimize the developer experience, even to the point of minimizing eye movements. Make it easy to find details. That space could be used more productively.
We “should know” but we don’t. This segues into the real reason. It demonstrates that writers don’t know the developer experience. Let’s be blunt. We’re delivering documentation suites that have not been tested properly, calls that are unlikely to have been tested, and tools developers don’t use. Not understanding these issues is the fundamental reason writers also need developer experience. Writers simply can’t empathize with own audiences, which means we supplying developers with inadequate and incomplete tools and documentation. This is a real concern.
This is not a condemnation. Quite the opposite. API documentation writers need to empathize with developers. Writers do this by treating this as a craft, learn a little about development each day, and move slowly along the experience spectrum towards the developer’s end. Learn a language. It doesn’t matter which one. Java, JavaScript, to DOS batch commands, UNIX command line programming, Word macros, Python, or even AutoHotKey*. All of these have programming concepts and that’s what matters. Learn about them, which requires using an API guide, craft statements, and debug them is at the heart of the matter."
https://robertdelwood.medium.com/why-i-dont-like-try-it-f44112ed1b6d
#APIs #APIDocumentation #SoftwareDevelopment #TechnicalWriting
I've been using it for several years on one of my home laptops, and now (after the words of the arrogant Linus Torvalds) FreeBSD will be my primary system.
#blog
Feeling Code’s Consequences
https://stevengharms.com/posts/2024-11-13-live-visualization-of-data-state/
#javascript #lisp #medley #interlisp #lotus #spreadsheets #softwaredevelopment
Shoutout to @amoroso
Feeling Code’s Consequences
https://stevengharms.com/posts/2024-11-13-live-visualization-of-data-state/
#javascript #lisp #medley #interlisp #lotus #spreadsheets #softwaredevelopment
Shoutout to @amoroso
Feeling Code's Consequences
Live visual feedback based on analog controls could change how we programstevengharms.com
Software architecture plays a decisive role in the design of modern applications. Event-Driven Architecture (EDA) is a promising approach. This article highlights the advantages and functionality of EDA. You will also get a closer look at how it reacts to events in real time and why it is an attractive option for developing flexible, scalable and responsive systems.
https://atix.de/en/blog/the-future-of-software-architecture-focus-on-event-driven-architecture/
#devops #software #softwaredevelopment #eventdriven #blog #tech #technology
https://atix.de/en/blog/the-future-of-software-architecture-focus-on-event-driven-architecture/
#devops #software #softwaredevelopment #eventdriven #blog #tech #technology
The future of event-driven architecture | ATIX AG
The article explains the Event-Driven Architecture (EDA) and its advantages for flexible, scalable and responsive systems.Michael Morlock (ATIX AG)