Please continue to blog about the obvious stuff. It happens all of the time that I want to explain to someone what I think is an obvious concept and then I am sometimes surprised to find out that there are no good blogs where I could link to for an explanation...
On Github, there is a way to leave individual comments in the code and in addition give a review a summary.
In addition to hitting the "approve" button, I typically spell it out explicitly in this summary: "Please check my comments and see if anything makes sense to implement."
Often, I also take this opportunity to point out the "one" most valuable change in my opinion.
If the developer of the code doesn't find any of the comments to be applicable/usefuly, they can always go ahead and merge it right away.
Where I work I can and am still allowed to push to mainline directly, as are all other developers on the team.
Some new colleagues started with PRs and since then it has been a slow move towards using PRs more and more (but still not mandatory).
As of now some colleagues don't typically do PRs and push directly (minority), some decide on a case-by-case basis (I am among those, among a small majority in our team) and some have been using PRs for each and every change from day one (also a minority).
The criticisms by the opponents of PRs are as follows:
1. People relying on PRs too much causes them to propose code which is not production quality as of the PR whereas before (i.e. "no PRs") if your code was not correct, you or someone else either noticed shortly after (checking the tests on CI etc.) or it would make it into the release. I don't believe this to be generally true but sometimes thought similar when reading some PRs. The frequency of large bugs being found by code review in the PR has gone down in recent times which leads me to believe that the colleagues have adjusted their development style to come up with good quality solutions in the first attempt already in most cases.
2. Code review is hard to do in many cases. In our team this is typically resolved by going over a PR together for the “hard cases” (e.g. in a videoconference).
I think PRs are mostly worth the effort because any bug that can be avoided before the release saves a lot of downstream effort (e.g. support) and the effect of building a shared knowledge about the code page is valuable (although hard to quantify).
Another way to make XML awesome (especially for config files and the like) is to completely avoid CDATA i.e. no <config><key>value</key><key2>value2</key2></config> but rather: <config key="value" key2="value2"/> -- simple constructions can then do with just a root element. Of course this pattern only pays off if you need the XML parser for other parts of the application, too...
I liked the content of the article enough to read it to the end, but I did have a hard time due to inflation with LLM-isms. Then again I am not a native so how would I know if this is good English? I can only tell that to me, it is hard to read despite interesting content.
After some search for programming languages which promise to reduce the number of bugs, I decided to give Ada (2012) a try.
I like it better than C and C++ and the compiler is included in Debian in a reasonably recent version that it can compile the code that I need.
Ada is particularly nice for programming RPI 2040 microcontrollers because for my needs I didn't need additional libraries. For both of my RPI 2040 projects (one of which is online here: https://masysma.net/37/dcf77_vfd_raspi_clock.xhtml), my code had fewer bugs than I had anticipated.
For general purpose systems programming the lack of free software libraries is still a concern e.g. while working on a custom backup restore program I had to write my own LZ4 extractor and Blake3 hash function implementation because there wasn't any existing libraries that I could find for the purpose.
> - Since maintainers do owe basic human politeness, and they know people will be interacting with them, maintainers do owe this culture some form of communication of their intentions. If they don't want to take any changes, put that in CONTRIBUTING and turn off GH PRs. If they want to take changes, but no AI changes, put that in CONTRIBUTING. If they don't want to do support, turn off GH Issues. If they require a specific 10-point series of steps before they look at a PR or Issue, put that in CONTRIBUTING. It's on the user to read this document and follow it - but it's on you to create it, so they know how to interface with you.
In general it is already in the license. Even permissive licenses like Expat have (in ALL CAPS no less)
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO [...]
There is zero need to indicate anything about CONTRIBUTING whatsoever because already it is clear that the developer already indicates that nothing can be taken for granted.
Of course it helps to be open about expectations.
I for instance don't put CONTRIBUTING instructions online but so far all of my stuff gets so little attention that I have received almost no feedback about my free software at all.
To me, this is perfectly OK and in line with the expectation that I for instance put my code online mostly for my own benefit. If it helps anyone else, all the better. But don't derive any more expectations from it because it's free...?
My exposure and usage of “AI” has been very limited so far. Hence that is what I am and have been doing all the time: Read the text mostly irrespective of origin.
I do note that recently, I wonder what was the point the author wanted to make more often only to then note that there are a lot of what seems to be the agreed on standard telltale signs of excessive AI usage.
Effectively there was a lot of spam before already hence in general I don't mind so much. It is interesting to see, though, that the “new spam” often gets some traction and interesting comments on HN which used to not be the case.
It also means that behind the spam layer there is possibly some interesting info the writer wanted to share and for that purpose, I imagine I'd prefer to read the unpolished/prompt input variant over the outcome. So far, I haven't seen any posts where both versions were shared to test whether this would indeed be any better, though.
This is a powerful technique that has helped me a lot in the past as well, especially for those projects where I rarely progressed on (mostly private stuff, the work topics are more streamlined).
Nowdays in my private projects I often use a combination of the git commit messages and comments left in the code to indicate where to continue. Of course, this is not useful for work, either.
For work I like to use the ticket system and a separate text file and a paper notebook each to a slightly different effect.
The text file is the log what was done and is done per day grouped by ticket, typically ~10 lines for a day. The notebook contains meeting notes, design thoughts, general notes etc. and is very verbose (often six or mor pages per day, A4 paper) but sometimes helps to identify how/why/when a given decision was taken. The ticket contains what might also benefit others such as technical insights, meeting summaries (derived and summarized after the meeting from the paper notebook), summaries of important (design or product) decisions etc.
UNIX provides the Makefile as go-to tool if a simple pipeline is not enough. GNUmake makes this even more powerful by being able to generate rules on-the-fly.
If the tool of interest works with files (like the UNIX tools do) it fits very well.
If the tool doesn't work with single files I have had some success in using Makefiles for generic processing tasks by creating a marker file that a given task was complete as part of the target.
I wonder if this is due to Linux being harder to work on or because it is possible to fix some errors which would be catastrophic on other OSes?
Back when I used Windows a lot (Windwos XP times...) I also had the "long, scarring evening of frustation" rather often. It was usually solved by a reinstall.
In recent times, the “standard” seems to be smartphones (I use Android). The logic of smartphones it: It works or it dosen't and if it doesn't there is nothing you can do about it. Like ... not supporting some docking station because its network interface is called usb0 rather than eth0 ... no bypass, no solution, buy another docking station.
Of course this is faster than debugging the issue and maybe fixing it for good or maybe waste the evening on it.
Effectively Linux giving you the option to do something about errors doesn't mean the workarounds from other OSes like “reinstall”, “buy a new one”, “use a friend's system because it doesn't work here” are still readily available?
I don't think anybody needs all of the features at once but people have different preferences. E.g. I typically do well without bold formatting (I only need one level of emphasis which is served well by italic) but I want tables, links and lists very often.
Also I like the WYSIWYG feature of Markdown where it has an advantage over the traditional Markup languages like HTML, LaTeX, groff etc. of being easier to read in the text file. Dedicated syntax highlighting can go a long way to make markup easier to read, though.
I don't think that is sufficient for the general case because I would like to be able to use the markdown like _emphasis_ or [hyperlinks](https://www.example.com) even inside the table rows and this doesn't render properly when using fixed pitch “tables as source code blocks”
The original Markdown has fewer features than listed for the more advanced formats in the table. Hence if someone uses reStructuredText it is more precise than just saying “Markdown” because Markown could refer to anything from the original minimalist featureset to the vastly extended format supported by pandoc if given the appropriate CLI arguments.
Some text-based formats have more options for tables e.g. alignment of columns (it may help with numbers to right-align them) or multirow/multicolumn options.
Some formats support definition lists (corresponds to <dl> in HTML) - a feature which I often find valuable but was not included in the original Markdown IIRC.
One advantage of using a text-based format is that it can be exported to either LaTeX or HTML and Markdown seems to prefer the HTML output by explicitly supporting inline HTML as an escape hatch for more complex constructs (e.g. tables with rowspan/colspan). In addition to often not being supported for a non-HTML export-type it also hurts the WYSIWYG experience when reading the file like plain text.
<https://pubs.opengroup.org/onlinepubs/9799919799/utilities/t...>
The most important differences seem to be:
* `:` is a builtin vs. `true` is an utility * passing arguments to `:` is safe but for `true` its not hence `:` is the right thing to use here.