They completely redesigned the code navigation to load it dynamically using React. One of the regressions introduced caused the entries to be duplicated when searching for a word using Ctrl+F. Their solution to address this issue? Decompose the source character by character, assigning each individual character its own distinct HTML node...
Needless to say, in addition to abysmal performance (it took seconds to display on my laptop), this also caused new problems (such as the inability to search for certain composite emojis). The worst part is that they seemed proud of their hack, since they wrote a blog post about it.
Trying to find a string in github actions logs is just impossible. Not to mention that even opening large logs takes many seconds of animated scrolling to get to the end.
There is the "view raw logs" button which just opens a plaintext file that my browser loads and searches instantly (imagine that), but doesn't work for still-running jobs.
Wow, that post is amazing. They observed that their page worked poorly because it had a lot of DOM nodes, and they don’t even discuss the idea of trying to make a usable page with fewer DOM nodes. Instead they add all manner of complexity and more nodes (!) to make it sort of work.
A web browser can render and search a boring pure-HTML syntax-highlighted source file just fine.
It's hand-written by me although I'm sure the writing style could be improved a lot. My process for the tutorial posts is to come up with the simplest functional code I can (admittedly using ChatGPT to double-check it), and then write the text around the code examples. I try to keep the text relatively simple so that a) the code does the talking, and b) non-native English speakers can still understand.
Although there is no specific implementation for Battleship, but I believe that some users sometimes have the possibility to create and submit their own games.
One month ago, I spent hours testing dozens of apps for "gamified todo list". I could not find any that would perfectly suits my needs (Habitica is too gamified for example).
Your app looks very promising. Polished UI. Intuitive. Unlimited habits. Simple "task -> award" principle without added complexity layers.
Something I'm having trouble finding in the apps I've tried is the distinction between "habit" and "task". An habit is something I want to do multiple time in a week. While a task is a one-shot TODO that I would like to execute at some point when I'm not procrastinating. Once done, I don't need to repeat it, but I like to be rewarded.
Your application seems to be more habit oriented. Is the notion of a one-time task something you could eventually incorporate?
I have been in the same boat of trying to gamify my to-do list. So far I have been working with progress bars and goals to try and find a way to motivate me to get things done.
I realized that the hardest thing is getting the long term goals to feel like a simple activity for today, bringing the 3+ month goal into a simple “read a few pages today” type of habit.
I also created a simple spreadsheet app that focuses specifically on the progress you made today in relation to your goal. The progress you make today is a different color. Instead of estimating how long it will take to complete the goal with your average, I use the amount done today. So after every addition page read you can see the amount of days left to finish the book go down.
I also added a little bit of motivation text that says “if you read X more pages you will be done Y days faster.
If you use the “MIT”(Most Important Task) type of system , then you could make it a daily habit to complete your top 2-3 MITs for the day.
Breaking one time tasks into small chunks that could become a habit to start on at specific times might be worth looking into. Similar to writers who write for an hour every day even when not motivated.
GPs example is perfectly valid as well - this is just a restatement of the same logic in a way that keeps the logic contained within the loop at the cost of using a conditional plus a break inside of an unconditional loop. See [0]:
Another motivating code pattern is the "loop and a half".
It was once common for processing a file by line, but that
has been solved by making file objects iterable; however
other non-iterable interfaces still suffer from patterns
like:
line = f.readline()
while line:
... # process line
line = f.readline()
or like this:
while True:
line = f.readline()
if not line:
break
... # process line
Either of those could be replaced with a much more clear
and concise version using an assignment expression:
while line := f.readline():
... # process line
Not static AOT, not creating tiny binaries that fit on a microcontroller.
There is a lot of stuff out there that goes in this direction. There is nukita (again no small binaries), there is even an abandoned GCC frontend that can compile some minimal examples, but has been abandoned long ago.
Seriously, the time I spent researching this topic - if a proper compiler engineer would spend that on the actual compiler, it'd be done by now.
They completely redesigned the code navigation to load it dynamically using React. One of the regressions introduced caused the entries to be duplicated when searching for a word using Ctrl+F. Their solution to address this issue? Decompose the source character by character, assigning each individual character its own distinct HTML node...
Needless to say, in addition to abysmal performance (it took seconds to display on my laptop), this also caused new problems (such as the inability to search for certain composite emojis). The worst part is that they seemed proud of their hack, since they wrote a blog post about it.