This is the tool I have been looking for quite some time. I don't know why my searches returned only the simplest screenshot tools that are available on Linux. I have been using ShareX on Windows and was surprised to not find a similarly powerful tool on Linux. Now, I know that it was because of my rusty duck-duck-fu (or search is basically useless nowadays).
For a moment I perceived that as "Flutter" and immediately thought, "Of course, Google is shutting down another project." Perhaps that's enough screen time for today.
Working with a 300 line method is not fun, believe me. Everything is in one place and you don't have to change many files, yes, but due to the cognitive load, it's so much more effort to maintain it.
There are some things that should be in one long function (or method).
Consider dealing with the output of a (lexical) tokeniser. It is much easier to maintain a massive switch statement (or a bunch of ifs/elseifs) to handle each token, with calls to other functions to do the actual processing, such that each case is just a token and a function call. Grouping them in some way not required by the code is an illusory "gain": it hides the complexity of the actual function in a bunch of files you don't look at, when this is not a natural abstraction of the problem at all and when those files introduce extra layers of flow control where tricky bugs can hide. Or see the "PLEASE DO NOT ATTEMPT TO SIMPLIFY THIS CODE" comment from the Kubernetes source[0]. A 300 line function that does one thing and which cannot be usefully divided into smaller units is more maintainable than any alternative. Attempting to break it up will make it worse.
That being said, I agree that nearly all 300 line functions in the wild are not like this.
There's a happy middle path here I think. Long functions are hard to grok. Spreading the logic across 20 files also increases cognitive load. There's a balance to strike.
Long functions are not hard to grok, if they have a logical flow and stay reasonably close to a common level of abstraction (which can be high or low, doesn't matter). You just read top to bottom and follow the story.
20 files with 20 functions each does not cause high cognitive load, if the scope of each file and each function makes sense. You easily find the file+function you need, whenever you need to look something up and the rest of the time it is as if the rest didn't exist.
Good code can come in any shape. It is not shape itself that is important, it is the "goodness" that is important.
My heuristic is that if logic is repeated at least 3 times, it's good to pull out into its own function, and even then you still need to consider liskov substitution principle.
Right, but the article seems to imply that all code should be in a single file.
It seems the author indeed is not a SW Engineer and thus does not really grok the benefit of "modules".
This of course depends on the size of the program. Small program "fits" into a single module.
And I think that scientific programs are basically small and simple because they don't typically need to deal with user-interaction at all, they just need to calculate a result.
Further I think scientific programs rely heavily on existing libraries, and writing a program that relies heavily on calls to external libraries produces simple, short programs.
Scientists produce science, engineers produce code-libraries.
"It seems the author indeed is not a SW Engineer".
This is a pretty ridiculous notion if you just cursorily glance over the page. It is quite clear that this guy is more of a software engineer than most with that title will ever be. Hint: a blog that contains a post with a title like 'Coroutines in one page of C' is a software engineer.
I always thought, the "correct" way of doing this was the other way around: the RSS reader would implement ActivityPub so you could "toot" from within you RSS client. It would perhaps attempt to collect other "toot"s about the same link, facilitating a discussion (and keeping everything at one place). But I think this is the next best thing, especially for those feeds you tend to share on the social networks (I don't think it's feasible to reproduce the RSS reader following with this).
> It would perhaps attempt to collect other "toot"s about the same link, facilitating a discussion (and keeping everything at one place).
If you go to Explore → News on Mastodon, there's like a list of 10 trending articles within your network. It also includes "discussed by X people in the past Y days", but annoyingly there's no way to reach those discussions and read what people thought about the article.
So I feel like Mastodon's moving in the right path to serve that purpose, it's just unfinished.
That's kinda how we've approached it with some of the IndieWeb tools (https://indieweb.org/reader) where you can subscribe to the various feeds you want to, and can directly like/reply/etc
I am an active user of Monocle (https://monocle.p3k.io), a social reader UI (which is connected to a feed polling service, in my case Aperture). I can click "like" or "reply" and the reaction is published on my personal website. A notification is sent to the recipient via Webmention that I liked/commented on their content (if their site supports webmention).
Isn't that effectively Micropub/Microsub? RSS was only ever meant for passive consumption, but similar IndieWeb specs have been layered on to support more social features and two-way engagement.
Yes, there is a slight difference in that, I would like the RSS reader to find other social accounts (Mastodon, Lemmy, etc.) that shared the same link and bring them in context so that the user can directly interact with those as well. I know it's not trivial to do, but one gets to dream, right?
> "More than 40% of Azure are running Linux and OSS workloads, and most of its infrastructure doesn’t have anything to do with Microsoft software at all."
It's fun to play. Thanks for sharing. One suggestion: I thought I had 4 attempts to get it right, but I was actually just tweaking the original 30 character prompt. It was too late when I saw the small text over the text box describing the process. Maybe instead of "attempt" you could call them "tweak"s or "adjustment"s. Something like: "You start with an initial prompt and 3 adjustments."
I had the same issue - didn't realize that the prompt was an add-on to the original. Definitely agree that Attempts could be reframed, especially since they're appended. Fun game though and a good exercise in prompt engineering.
I would love to have an e-ink Android tablet with reasonable refresh rates. The article mentions Onyx BOOX Tab, but if I remember correctly, that one had some problems related to licensing [1]. Not sure if those issues has been resolved by now.
Thank you for sharing.