diff options
| -rw-r--r-- | TODOs.adoc | 122 | ||||
| -rw-r--r-- | TODOs.md | 137 |
2 files changed, 122 insertions, 137 deletions
diff --git a/TODOs.adoc b/TODOs.adoc new file mode 100644 index 0000000..973a3f4 --- /dev/null +++ b/TODOs.adoc @@ -0,0 +1,122 @@ += papod's TODOs +:toc: + + +[[tasks]] +== Tasks + + +[[bugs]] +== Bugs + + +[[improvements]] +== Improvements + + +[[td-5p8wTOr8AbU]] +=== [.TODO]#TODO# Link against system SQLite +* [.TODO]#TODO# in 2024-05-23 + +''' +:over-200k-lines: https://github.com/mattn/go-sqlite3/blob/4702d9b5d640f42488752f5cf70a195b748ffe96/sqlite3-binding.c[over 200k lines of code] + + + +So we don't recompile {over-200k-lines} of code on every build of the application. +Not only that, but also for properly separating projects into their own artifacts. + + +[[td-x9yOtxlTfUQ]] +=== TODO Reuse prepared statements +* TODO in 2024-05-23 + +''' + +The documentation of `"database/sql"` suggests that a prepared statement can be +built once and reused across difference queries and goroutines. + + +[[questions]] +== Questions + + +[[td-fuTg3iCALR8]] +=== TODO wxWidgets nativeness + +* TODO in 2023-11-10 + +''''' + +With enough care, can a wxWidgets application become polished enough to +make dedicated GTK and Qt applications unnecessary? + +poedit(1) is the only app I can think from memory that is written in +wxWidgets. I should look for more apps and benchmark them on different +platforms. + + +[[decisions]] +== Decisions + + +[[resources]] +== Resources + + +=== Relevant links + +____ +(...) Checking code into a directory managed by npm is simply asinine, and +putting symlinks in there is just as "coupled to the runtime environment +configuration" as the NODE_PATH solution. What is really needed is a +reasonable (and supported) method of programmatically managing the node search +path. + +Why the node community is so stubborn about this point is a mystery to me and +it makes me wary of node in general, because who wants to be locked into an +environment where such an obvious pain point is ignored due to stubbornness? + +-- HN comment, https://news.ycombinator.com/item?id=7790847[May 23, 2014] +____ + +____ +I’ve often said that you can make money in FOSS, but not usually by accident. +Don’t just build your project and wait for the big bucks to start rolling in. +You need to take the business-building seriously from the start. What is the +organization of your company? Who will you work with? What kind of clients +or customers will you court? Do you know how to reach them? How much they’re +willing to pay? What you will sell? Do you have a budget? If you want to +make money from your project, sit down and answer these questions seriously. + +Different kinds of software projects make money in different ways. Some +projects with enterprise-oriented software may be able to sell support +contracts. Some can sell consultants to work on integration and feature +development. Maybe you can write books about your software, or teach courses +on it. Perhaps your software, like the kind my company builds, is well-suited +to being sold as a service. Some projects simply solicit donations, but this +is the most difficult approach. + +-- Drew DeVault, https://drewdevault.com/2021/03/03/To-make-money-in-FOSS-build-a-business.html[March 3, 2021] +____ + +____ +That's not an argument for sticking with the old programming language that +apparently is impossible to use safely (if you think that you can use it +safely, what makes you think that you are better than the all-star cast of C +programmers that have contributed CVEs over the years?). There were better +alternatives to C in the 80s, there most certainly are better alternatives to +C these days. I'm so sick of the Uncle Bob school of thought that all that is +needed for better software engineering is discipline. If we haven't managed to +impose that discipline yet after five decades, why would we believe that it +will magically appear in the future? My guess is that a programmer that had +the requisite mythical discipline would gravitate to programming languages +like Rust or Ada anyway, because that developer wouldn't mind tooling that +helped with it. + +-- HN comment, https://news.ycombinator.com/item?id=30842507[March 29, 2022] +____ + + +[[scratch]] +== Scratch diff --git a/TODOs.md b/TODOs.md deleted file mode 100644 index 368c6cf..0000000 --- a/TODOs.md +++ /dev/null @@ -1,137 +0,0 @@ -# Tasks - - -# Bugs - - -# Improvements - - -# Questions - -## TODO wxWidgets nativeness {#td-d27aca11-9449-bb0e-08cb-2a8ef9778a11} -- TODO in 2023-11-10 - ---- - -With enough care, can a wxWidgets application become polished enough to make -dedicated GTK and Qt applications unnecessary? - -poedit(1) is the only app I can think from memory that is written in wxWidgets. -I should look for more apps and benchmark them on different platforms. - - -# Decisions - -## TODO Accepted dependencies {#td-faf15e3f-4a57-a99e-55c6-53ffd7448962} -- TODO in 2023-11-09 - ---- - -- Node.js: for running the application; -- SQLite: for storing data for history, queues and auth; -- maybe some library with Node.js binding to SQLite. - -Since the fancy chat is going to be done first (see -[#td-ed5d15f4-ec30-7411-fa74-552a06569c91](#td-ed5d15f4-ec30-7411-fa74-552a06569c91)), -it may be possible to postpone the SASL authentication and rely only on the -`NickServ` authentication for now. - -## TODO IRCv3+ first, RFC 1459 after {#td-ed5d15f4-ec30-7411-fa74-552a06569c91} -- TODO in 2023-11-09 - ---- - -Do the fancy chat first, and the basic one after. - -## TODO Encubate dependencies than move them out {#td-1045dbb9-fd89-e254-3e9d-642cb112c6ad} -- DONE in 2023-11-09 - ---- - -In order to achieve the reliability and robustness targets I have, and to build -something that I'd want to personally use deploy, I'll need as few dependencies -as possible. So as papo gets built, I'll need miniscule libraries for web -routing, WebSockets, etc., and as I write those inside papo itself, I'll -eventually pull them out as standalone dependencies. - -So the apparent number of dependencies may seem to grow, but only because -they're being separated from papo itself, so that this repository contains code -relating to chat things, and infrastructure things go to their own repository. -Also despite the apparent dependency count growth, these dependencies are being -bu8ild alongisde papo and with its robustness, reliability and correctness -standard from the beginning, so the mismatch in quality is not a concern. - -## DONE Assume Node.js {#td-faae1d8e-4015-cb78-0fe9-d003428266c9} -- DONE in 2023-11-09 - ---- - -Despite existing multiple available JavaScript runtimes these days besides -Node.js, like Deno (also V8), QuickJS, Bun, Hermes, etc., I'll stick to Node.js, -for a few reasons: - -- it allows me to focus on getting things out there by leveraging - Node.js-specific functionalities; -- it prevents me from wasting time writing compat layers for the multiple - implementations. - -If a compatibility API across runtimes ever emerges I'll adopt that, but untill -then I'm better off getting things done rather than supporting as many platforms -as possible when I need not to. Its better for me to use this time and energy -improving papo itself. - - -# Resources - -## Relevant links - -On May 23, 2014, from https://news.ycombinator.com/item?id=7790847: - -> (...) Checking code into a directory managed by npm is simply asinine, and -> putting symlinks in there is just as "coupled to the runtime environment -> configuration" as the NODE_PATH solution. What is really needed is a -> reasonable (and supported) method of programmatically managing the node search -> path. -> -> Why the node community is so stubborn about this point is a mystery to me and -> it makes me wary of node in general, because who wants to be locked into an -> environment where such an obvious pain point is ignored due to stubbornness? - - -On March 3, 2021, from -https://drewdevault.com/2021/03/03/To-make-money-in-FOSS-build-a-business.html: - -> I’ve often said that you can make money in FOSS, but not usually by accident. -> Don’t just build your project and wait for the big bucks to start rolling in. -> You need to take the business-building seriously from the start. What is the -> organization of your company? Who will you work with? What kind of clients -> or customers will you court? Do you know how to reach them? How much they’re -> willing to pay? What you will sell? Do you have a budget? If you want to -> make money from your project, sit down and answer these questions seriously. -> -> Different kinds of software projects make money in different ways. Some -> projects with enterprise-oriented software may be able to sell support -> contracts. Some can sell consultants to work on integration and feature -> development. Maybe you can write books about your software, or teach courses -> on it. Perhaps your software, like the kind my company builds, is well-suited -> to being sold as a service. Some projects simply solicit donations, but this -> is the most difficult approach. - -on March 29, 2022, from https://news.ycombinator.com/item?id=30842507: - -> That's not an argument for sticking with the old programming language that -> apparently is impossible to use safely (if you think that you can use it -> safely, what makes you think that you are better than the all-star cast of C -> programmers that have contributed CVEs over the years?). There were better -> alternatives to C in the 80s, there most certainly are better alternatives to -> C these days. I'm so sick of the Uncle Bob school of thought that all that is -> needed for better software engineering is discipline. If we haven't managed to -> impose that discipline yet after five decades, why would we believe that it -> will magically appear in the future? My guess is that a programmer that had -> the requisite mythical discipline would gravitate to programming languages -> like Rust or Ada anyway, because that developer wouldn't mind tooling that -> helped with it. - - -# Scratch |