= 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