# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 7056
# self = https://watcher.sour.is?uri=https://lyse.isobeef.org/twtxt.txt&offset=6152
# next = https://watcher.sour.is?uri=https://lyse.isobeef.org/twtxt.txt&offset=6252
# prev = https://watcher.sour.is?uri=https://lyse.isobeef.org/twtxt.txt&offset=6052
@prologic We can't agree on this idea because that makes things even more complicated than it already is today. The beauty of twtxt is, you put one file on your server, done. One. Not five million. Granted, there might be archive feeds, so it might be already a bit more, but still faaaaaaar less than one file per message.
Also, you would need to host not your own hash files, but everybody else's as well you follow. Otherwise, what is that supposed to achieve? If people are already following my feed, they know what hashes I have, so this is to no use of them (unless they want to look up a message from an archive feed and don't process them). But the far more common scenario is that an unknown hash originates from a feed that they have not subscribed to.
Additionally, yarnd's URL schema would then also break, because https://twtxt.net/twt/<hash> now becomes https://twtxt.net/user/prologic/<hash>, https://twtxt.net/user/bender/<hash> and so on. To me, that looks like you would only get hashes if they belonged to this particular user. Of course, you could define rules that if there is a /user/ part in the path, then use a different URL, but this complicates things even more.
Sorry, I don't like that idea.
@prologic We can't agree on this idea because that makes things even more complicated than it already is today. The beauty of twtxt is, you put one file on your server, done. One. Not five million. Granted, there might be archive feeds, so it might be already a bit more, but still faaaaaaar less than one file per message.
Also, you would need to host not your own hash files, but everybody else's as well you follow. Otherwise, what is that supposed to achieve? If people are already following my feed, they know what hashes I have, so this is to no use of them (unless they want to look up a message from an archive feed and don't process them). But the far more common scenario is that an unknown hash originates from a feed that they have not subscribed to.
Additionally, yarnd's URL schema would then also break, because https://twtxt.net/twt/<hash> now becomes https://twtxt.net/user/prologic/<hash>, https://twtxt.net/user/bender/<hash> and so on. To me, that looks like you would only get hashes if they belonged to this particular user. Of course, you could define rules that if there is a /user/ part in the path, then use a different URL, but this complicates things even more.
Sorry, I don't like that idea.
We had a very sunny day, peaking at 19°C. This not only decoyed me out, but also plenty motorcycle terrorists. Eh fuckwits, nobody wants to listen to your bloody engine and exhaust noise, keep it quiet for fuck's sake! Many of your rider collegues can manage it, too, so should you.
I had some sore muscles after yesterday's waste paper collection with the scouts. So, I only went for a short trip to my closest backyard mountain. Watching two rock climbers was interesting. That's not something I see very often.
Rock climber going up the Spielburg
https://lyse.isobeef.org/waldspaziergang-2025-03-09/
We had a very sunny day, peaking at 19°C. This not only decoyed me out, but also plenty motorcycle terrorists. Eh fuckwits, nobody wants to listen to your bloody engine and exhaust noise, keep it quiet for fuck's sake! Many of your rider collegues can manage it, too, so should you.
I had some sore muscles after yesterday's waste paper collection with the scouts. So, I only went for a short trip to my closest backyard mountain. Watching two rock climbers was interesting. That's not something I see very often.
Rock climber going up the Spielburg
https://lyse.isobeef.org/waldspaziergang-2025-03-09/
@prologic Hahaha, I love that! :-D Something to laugh during these hard times. Hope you're doing alright.
@prologic Hahaha, I love that! :-D Something to laugh during these hard times. Hope you're doing alright.
@arne Glückwunsch, das ist in der Tat doch mal eine erfreuliche Abwechslung. :-)
@arne Glückwunsch, das ist in der Tat doch mal eine erfreuliche Abwechslung. :-)
Thanks, @xuu, great explanation. In another project I've structured it exactly like you wrote. The mock storage over there extends the SQLite storage and provides mechanism to return errors and such for testing purposes:
* storage/ defines the interface
* sqlite/ implements the storage interface
* mock/ extends the SQLite implementation by some mocking capabilities and assertions
Here, however, there are no storage subpackages. It's just storage, that's it. Everything is in there. The only implementation so far is an SQLite backend that resides in storage. My RAM storage is exactly that SQLite storage, but with :memory: instead a backing file on disk. I do not have a mock storage (yet).
I have to think about it a bit more, but I probably have to do exactly that in my tt rewrite, too. Sigh. I just have the feeling that in storage/sqlite/sqlite_test.go I cannot import storage/mock for the helper because storage/mock/mock.go imports and embeds the type from storage/sqlite. But I'm too tired right now to think clearly.*
Thanks, @xuu, great explanation. In another project I've structured it exactly like you wrote. The mock storage over there extends the SQLite storage and provides mechanism to return errors and such for testing purposes:
* storage/ defines the interface
* sqlite/ implements the storage interface
* mock/ extends the SQLite implementation by some mocking capabilities and assertions
Here, however, there are no storage subpackages. It's just storage, that's it. Everything is in there. The only implementation so far is an SQLite backend that resides in storage. My RAM storage is exactly that SQLite storage, but with :memory: instead a backing file on disk. I do not have a mock storage (yet).
I have to think about it a bit more, but I probably have to do exactly that in my tt rewrite, too. Sigh. I just have the feeling that in storage/sqlite/sqlite_test.go I cannot import storage/mock for the helper because storage/mock/mock.go imports and embeds the type from storage/sqlite. But I'm too tired right now to think clearly.*
@arne Hals- und Beinbruch! Die Bahn hat ja nur die vier Feinde: Frühling, Sommer, Herbst und Winter. Wurdest Du heute positiv überrascht?
@arne Hals- und Beinbruch! Die Bahn hat ja nur die vier Feinde: Frühling, Sommer, Herbst und Winter. Wurdest Du heute positiv überrascht?
@prologic You just have to stay in the center. It's supposed to be calm in there I heard. Just getting there is the tricky part. Good luck!
@prologic You just have to stay in the center. It's supposed to be calm in there I heard. Just getting there is the tricky part. Good luck!
@movq "Thermometer must not be installed near aircraft turbine exhaust."
@movq "Thermometer must not be installed near aircraft turbine exhaust."
@xuu My layout looks like this:
* storage/
* storage.go: defines a Storage interface
* sqlite.go: implements the Storage interface
* sqlite_test.go: originally had a function to set up a test storage to test the SQLite storage implementation itself: newRAMStorage(testing.T, $initialData) *Storage
* controller/
* feeds.go: uses a Storage
* feeds_test.go: here I wanted to reuse the newRAMStorage(…) function
I then tried to relocate the newRAMStorage(…) into a
* teststorage/
* storage.go: moved here as NewRAMStorage(…)
so that I could just reuse it from both
* storage/
* sqlite_test.go: uses testutils.NewRAMStorage(…)
* controller/
* feeds_test.go: uses testutils.NewRamStorage(…)
But that results into an import cycle, because the teststorage package imports storage for storage.Storage and the storage package imports testutils for testutils.NewRAMStorage(…) in its test. I'm just screwed. For now, I duplicated it as newRAMStorage(…) in controller/feeds_test.go.
I could put NewRAMStorage(…) in storage/testutils.go, which could be guarded with //go:build testutils. With go test -tags testutils …, in storage/sqlite_test.go could just use NewRAMStorage(…) directly and similarly in controller/feeds_test.go I could call storage.NewRamStorage(…). But I don't know if I would consider this really elegant.
The more I think about it, the more appealing it sounds. Because I could then also use other test-related stuff across packages without introducing other dedicated test packages. Build some assertions, converters, types etc. directly into the same package, maybe even make them methods of types.
If I went that route, I might do the opposite with the build tag and make it something like !prod instead of testing. Only when building the final binary, I would have to specify the tag to exclude all the non-prod stuff. Hmmm.*
@xuu My layout looks like this:
* storage/
* storage.go: defines a Storage interface
* sqlite.go: implements the Storage interface
* sqlite_test.go: originally had a function to set up a test storage to test the SQLite storage implementation itself: newRAMStorage(testing.T, $initialData) *Storage
* controller/
* feeds.go: uses a Storage
* feeds_test.go: here I wanted to reuse the newRAMStorage(…) function
I then tried to relocate the newRAMStorage(…) into a
* teststorage/
* storage.go: moved here as NewRAMStorage(…)
so that I could just reuse it from both
* storage/
* sqlite_test.go: uses testutils.NewRAMStorage(…)
* controller/
* feeds_test.go: uses testutils.NewRamStorage(…)
But that results into an import cycle, because the teststorage package imports storage for storage.Storage and the storage package imports testutils for testutils.NewRAMStorage(…) in its test. I'm just screwed. For now, I duplicated it as newRAMStorage(…) in controller/feeds_test.go.
I could put NewRAMStorage(…) in storage/testutils.go, which could be guarded with //go:build testutils. With go test -tags testutils …, in storage/sqlite_test.go could just use NewRAMStorage(…) directly and similarly in controller/feeds_test.go I could call storage.NewRamStorage(…). But I don't know if I would consider this really elegant.
The more I think about it, the more appealing it sounds. Because I could then also use other test-related stuff across packages without introducing other dedicated test packages. Build some assertions, converters, types etc. directly into the same package, maybe even make them methods of types.
If I went that route, I might do the opposite with the build tag and make it something like !prod*
@xuu My layout looks like this:
* storage/
* storage.go: defines a Storage interface
* sqlite.go: implements the Storage interface
* sqlite_test.go: originally had a function to set up a test storage to test the SQLite storage implementation itself: newRAMStorage(testing.T, $initialData) *Storage
* controller/
* feeds.go: uses a Storage
* feeds_test.go: here I wanted to reuse the newRAMStorage(…) function
I then tried to relocate the newRAMStorage(…) into a
* teststorage/
* storage.go: moved here as NewRAMStorage(…)
so that I could just reuse it from both
* storage/
* sqlite_test.go: uses testutils.NewRAMStorage(…)
* controller/
* feeds_test.go: uses testutils.NewRamStorage(…)
But that results into an import cycle, because the teststorage package imports storage for storage.Storage and the storage package imports testutils for testutils.NewRAMStorage(…) in its test. I'm just screwed. For now, I duplicated it as newRAMStorage(…) in controller/feeds_test.go.
I could put NewRAMStorage(…) in storage/testutils.go, which could be guarded with //go:build testutils. With go test -tags testutils …, in storage/sqlite_test.go could just use NewRAMStorage(…) directly and similarly in controller/feeds_test.go I could call storage.NewRamStorage(…). But I don't know if I would consider this really elegant.
The more I think about it, the more appealing it sounds. Because I could then also use other test-related stuff across packages without introducing other dedicated test packages. Build some assertions, converters, types etc. directly into the same package, maybe even make them methods of types.
If I went that route, I might do the opposite with the build tag and make it something like !prod instead of testing. Only when building the final binary, I would have to specify the tag to exclude all the non-prod stuff. Hmmm.*
Dang it! I ran into import cycles with shared test utilities again. :-( Either I have to copy this function to set up an in-memory test storage across packages or I have to put it in the storage package itself and guard it with a build tag that is only used in tests (otherwise I end up with this function in my production binary as well). I don't like any of the alternatives. :-(
Dang it! I ran into import cycles with shared test utilities again. :-( Either I have to copy this function to set up an in-memory test storage across packages or I have to put it in the storage package itself and guard it with a build tag that is only used in tests (otherwise I end up with this function in my production binary as well). I don't like any of the alternatives. :-(
Thank you, @eapl.me, this is awesome! I'm curious to see if we find some more advantages with the current approach. It seems there should be some more, but I can only think disadvantages right now. :-)
Thank you, @eapl.me, this is awesome! I'm curious to see if we find some more advantages with the current approach. It seems there should be some more, but I can only think disadvantages right now. :-)
@movq Did you place it in the sun? We only got 15°C today.
@movq Did you place it in the sun? We only got 15°C today.
@prologic Damn! :-( Yeah, I won't build that into my client. Not worth it for the many things that are still undetectable and the low frequency it happens.
@prologic Damn! :-( Yeah, I won't build that into my client. Not worth it for the many things that are still undetectable and the low frequency it happens.
@bmallred Oh, I hear you! It's always after carefully proofreading and publishing that a typo suddenly pops up. :-) Not sure if amending your edit implementation is really worth it, but happy hacking in case you do.
@bmallred Oh, I hear you! It's always after carefully proofreading and publishing that a typo suddenly pops up. :-) Not sure if amending your edit implementation is really worth it, but happy hacking in case you do.
@movq Luckily, they're not made of steel as I would not have made it home with such heavy weights. :-D
@movq Luckily, they're not made of steel as I would not have made it home with such heavy weights. :-D
@movq Fuck! So there aren't any non-criminal printer vendors out there anymore. Very sad. I really don't understand why this is not highly illegal in the entire world.
@movq Fuck! So there aren't any non-criminal printer vendors out there anymore. Very sad. I really don't understand why this is not highly illegal in the entire world.
And I just added a video clip of the woodpecker. As you can easily see from the shaking, it hammers so dang hard that the whole ground around the tree vibrates.
And I just added a video clip of the woodpecker. As you can easily see from the shaking, it hammers so dang hard that the whole ground around the tree vibrates.
I went on a 5:30 hours long hike to my second backyard mountain. About 12km to get there and roughly 9km on the way back. It was super nice, sunny all day long, 12°C and luckily just a little bit of wind. Great scenery. I managed to capture one great spotted woodpecker hammering along. There was also a kestrel hovering over a meadow and then landing on a sports field light pole. At the castle ruin I could watch 10-12 gliding red kites (with the V-shaped tail) and other raptors, maybe bussards, I don't know, for about five minutes. That was fascinating. Unfortunately, my camera doesn't too well with moving targets.
Great spotted woodpecker hammering on a branch in a tree
Ruined Hohenrechberg Castle, today's hiking destination
86 more photos: https://lyse.isobeef.org/wanderung-auf-den-hohenrechberg-2025-03-03/
I went on a 5:30 hours long hike to my second backyard mountain. About 12km to get there and roughly 9km on the way back. It was super nice, sunny all day long, 12°C and luckily just a little bit of wind. Great scenery. I managed to capture one great spotted woodpecker hammering along. There was also a kestrel hovering over a meadow and then landing on a sports field light pole. At the castle ruin I could watch 10-12 gliding red kites (with the V-shaped tail) and other raptors, maybe bussards, I don't know, for about five minutes. That was fascinating. Unfortunately, my camera doesn't too well with moving targets.
Great spotted woodpecker hammering on a branch in a tree
Ruined Hohenrechberg Castle, today's hiking destination
86 more photos: https://lyse.isobeef.org/wanderung-auf-den-hohenrechberg-2025-03-03/
@movq Hahaha, stimmt! :-D
@movq Hahaha, stimmt! :-D
@bmallred I forgot one more effect of edits. If clients remember the read status of massages by hash, an edit will mark the updated message as unread again. To some degree that is even the right behavior, because the message was updated, so the user might want to have a look at the updated version. On the other hand, if it's just a small typo fix, it's maybe not worth to tell the user about. But the client doesn't know, at least not with additional logic.
Having said that, it appears that this only affects me personally, noone else. I don't know of any other client that saves read statuses. But don't worry about me, all good. Just keep doing what you've done so far. I wanted to mention that only for the sake of completeness. :-)
@bmallred I forgot one more effect of edits. If clients remember the read status of massages by hash, an edit will mark the updated message as unread again. To some degree that is even the right behavior, because the message was updated, so the user might want to have a look at the updated version. On the other hand, if it's just a small typo fix, it's maybe not worth to tell the user about. But the client doesn't know, at least not with additional logic.
Having said that, it appears that this only affects me personally, noone else. I don't know of any other client that saves read statuses. But don't worry about me, all good. Just keep doing what you've done so far. I wanted to mention that only for the sake of completeness. :-)
@bmallred Not an issue if you're the doctor working there. :-)
@bmallred Not an issue if you're the doctor working there. :-)
@bmallred Any edit automatically changes the twt hash, because the hash is built over the hash URL, message timestamp and message text. https://twtxt.dev/exts/twt-hash.html So, it is only a problem, if somebody replied to your original message with the old hash. The original message suddenly doesn't exist anymore and the reply becomes detached, orphaned, whatever you wanna call it. Threading doesn't break, though, if nobody replied to your message.
@bmallred Any edit automatically changes the twt hash, because the hash is built over the hash URL, message timestamp and message text. https://twtxt.dev/exts/twt-hash.html So, it is only a problem, if somebody replied to your original message with the old hash. The original message suddenly doesn't exist anymore and the reply becomes detached, orphaned, whatever you wanna call it. Threading doesn't break, though, if nobody replied to your message.
We went up our backyard mountain again right after lunch. The sun peaked through the clouds sometimes. The 6°C felt much, much cooler with the northeast wind. We got lucky, though, it was dead calm at the summit. At least on the southwestern side, which is a few meters lower than the very top to the east. That was shielded absolutely perfectly from the wind (we were extremely surprised), so we sat down on a bench and could really enjoy the sun heating us up. Apart from the haze, the view was really nice.
There were even patches of snow left up top, that was unexpected. Also, somebody created a cool rock art piece on a tree stump. That one rock absolutely looked like a face. Crazy!
Rock figurine on a tree stump
Enjoy: https://lyse.isobeef.org/waldspaziergang-2025-03-01/
We went up our backyard mountain again right after lunch. The sun peaked through the clouds sometimes. The 6°C felt much, much cooler with the northeast wind. We got lucky, though, it was dead calm at the summit. At least on the southwestern side, which is a few meters lower than the very top to the east. That was shielded absolutely perfectly from the wind (we were extremely surprised), so we sat down on a bench and could really enjoy the sun heating us up. Apart from the haze, the view was really nice.
There were even patches of snow left up top, that was unexpected. Also, somebody created a cool rock art piece on a tree stump. That one rock absolutely looked like a face. Crazy!
Rock figurine on a tree stump
Enjoy: https://lyse.isobeef.org/waldspaziergang-2025-03-01/
@andros I don't see a burst of new twtxt clients popping up. Yeah, the most recent ones are TwtxtReader and twtxt-el. Did I miss one? I agree with @david, looks normal to me. :-)
I'm also working on my rewrite at the moment, but that started… *looking at the git history*… oh wow! O_o Over two years ago! I just implemented jumping to the next/previous unread message.
@andros I don't see a burst of new twtxt clients popping up. Yeah, the most recent ones are TwtxtReader and twtxt-el. Did I miss one? I agree with @david, looks normal to me. :-)
I'm also working on my rewrite at the moment, but that started… *looking at the git history*… oh wow! O_o Over two years ago! I just implemented jumping to the next/previous unread message.
@movq @david Where can I join you? Building a log cabin in the woods would be dang awesome!
@movq @david Where can I join you? Building a log cabin in the woods would be dang awesome!
@movq I don't know. It seems a bit like whatever we do or don't do, we're gonna lose. :-( Unless the ban is successful.
@movq I don't know. It seems a bit like whatever we do or don't do, we're gonna lose. :-( Unless the ban is successful.
Amd of course, TDD! I tried that, but it doesn't work all that great for me in its strict form. I have the feeling that coming up with a single new failing test, making it pass, maybe some refactoring, rinse and repeat wastes significantly more time than doing it in – what they call – the "bundle" approach. Coming up with several tests in advance and then writing the code or vise versa is usually much quicker. I do find that more enjoyable, it also helps me to reduce smaller context switches. I can focus on either the tests or the production code.
As for the potentially reduced code coverage with a non-TDD approach, I can easily see which parts are lacking tests and hand them in later. So, that's largely a specious argument. Granted, I can forget to check the coverage or simply ignore it.
I agree with John, TDD results in less elegant code or requires more refactoring to tidy it up. Sometimes, it's also not entirely clear at the beginning how the API should really look like. It doesn't happen often, but it does happen. Especially when experimenting or trying out different approaches. With TDD, I then also have to refactor the tests which is not only annoying, but also involves the danger of accidentally breaking them.
TDD only works really well, if you have super tiny functions. But we already established that I typically don't like tiny methods just for the purpose of them being extremely short.
When fixing a bug, I usually come up with a failing test case first to verify that my repaired code later actually resolves the problem. For new code, it depends, sometimes tests first, sometimes the productive code first. Starting off with the tests requires the API to be well defined beforehand.
Amd of course, TDD! I tried that, but it doesn't work all that great for me in its strict form. I have the feeling that coming up with a single new failing test, making it pass, maybe some refactoring, rinse and repeat wastes significantly more time than doing it in – what they call – the "bundle" approach. Coming up with several tests in advance and then writing the code or vise versa is usually much quicker. I do find that more enjoyable, it also helps me to reduce smaller context switches. I can focus on either the tests or the production code.
As for the potentially reduced code coverage with a non-TDD approach, I can easily see which parts are lacking tests and hand them in later. So, that's largely a specious argument. Granted, I can forget to check the coverage or simply ignore it.
I agree with John, TDD results in less elegant code or requires more refactoring to tidy it up. Sometimes, it's also not entirely clear at the beginning how the API should really look like. It doesn't happen often, but it does happen. Especially when experimenting or trying out different approaches. With TDD, I then also have to refactor the tests which is not only annoying, but also involves the danger of accidentally breaking them.
TDD only works really well, if you have super tiny functions. But we already established that I typically don't like tiny methods just for the purpose of them being extremely short.
When fixing a bug, I usually come up with a failing test case first to verify that my repaired code later actually resolves the problem. For new code, it depends, sometimes tests first, sometimes the productive code first. Starting off with the tests requires the API to be well defined beforehand.
@andros Just before the pandemic, we watched Uncle Bob videos once a week in the lunch break. While almost all of my old teammates agreed with his views, I partially found them to be very odd and even counterproductive.
I didn't come across John Ousterhout or any of his work before, at least not deliberately. So, this document is my first contact.
I only finished the chapter on comments and I totally agree with John so far. This document just manifests to me how weird Bob's view is on certain subjects.
I always disagreed with the concept of a maximum method length. Sure, generally, shorter functions are probably better, but it always depends. And I've certainly seen super short methods that just made the code flow even worse to follow. While "one function should only do one thing" is a nice general rule, I'm 100% in team John with the shown examples. There are cases, where this doesn't help readability at all. Not even close.
To me, a function always has to justify its existence. Either by reusing it at least at another place or by coming up with dedicated tests for it. But if it is just called once and there are no tests, I almost always decide against it. Personally, I don't mind longer methods. We just recently had a discussion about that and I lost against two other workmates who are more in Uncle Bob's camp, they refactored one medium sized method into three very short ones. Luckily, we agree on most other topics.
Lol, what!? The shorter the method, the longer the variables inside? I first thought I misread or the writeup mixed it up. I'll always do it the other way around.
I've been also bitten badly by outdated comments in the past, but Bob must have worked on really terrible projects to end up with such an attitude to dislike comments. Oh well. No doubt, I've come across by several orders of magnitude more useless comments, in my experience (autogenerated) JavaDocs fall in the category more frequently than not. So, I know that there are different types of comments. A comment doesn't automatically mean that it is good and justified.
But I also partially agree with Bob and John and think that a good name has a proper chance to save a comment. Though, when in doubt, I go John's route and use a shorter name with a comment rather than use a kilometer long identifier. Writing good comments typically takes some time, sometimes much longer than writing the code. It regularly takes me several minutes. It's a hard art.
I perhaps should read up on John's work. He seems to be more reasonable and likeminded. :-) Let me continue to complete this document.
@andros Just before the pandemic, we watched Uncle Bob videos once a week in the lunch break. While almost all of my old teammates agreed with his views, I partially found them to be very odd and even counterproductive.
I didn't come across John Ousterhout or any of his work before, at least not deliberately. So, this document is my first contact.
I only finished the chapter on comments and I totally agree with John so far. This document just manifests to me how weird Bob's view is on certain subjects.
I always disagreed with the concept of a maximum method length. Sure, generally, shorter functions are probably better, but it always depends. And I've certainly seen super short methods that just made the code flow even worse to follow. While "one function should only do one thing" is a nice general rule, I'm 100% in team John with the shown examples. There are cases, where this doesn't help readability at all. Not even close.
To me, a function always has to justify its existence. Either by reusing it at least at another place or by coming up with dedicated tests for it. But if it is just called once and there are no tests, I almost always decide against it. Personally, I don't mind longer methods. We just recently had a discussion about that and I lost against two other workmates who are more in Uncle Bob's camp, they refactored one medium sized method into three very short ones. Luckily, we agree on most other topics.
Lol, what!? The shorter the method, the longer the variables inside? I first thought I misread or the writeup mixed it up. I'll always do it the other way around.
I've been also bitten badly by outdated comments in the past, but Bob must have worked on really terrible projects to end up with such an attitude to dislike comments. Oh well. No doubt, I've come across by several orders of magnitude more useless comments, in my experience (autogenerated) JavaDocs fall in the category more frequently than not. So, I know that there are different types of comments. A comment doesn't automatically mean that it is good and justified.
But I also partially agree with Bob and John and think that a good name has a proper chance to save a comment. Though, when in doubt, I go John's route and use a shorter name with a comment rather than use a kilometer long identifier. Writing good comments typically takes some time, sometimes much longer than writing the code. It regularly takes me several minutes. It's a hard art.
I perhaps should read up on John's work. He seems to be more reasonable and likeminded. :-) Let me continue to complete this document.
@thecanine That's one of my favorite dogs. Very cute. I like its headband and bandana with the bones.
@thecanine That's one of my favorite dogs. Very cute. I like its headband and bandana with the bones.
@david Yeah. A horrendously wrong but *simple* solution often outpaces are bit more correct but complex one. Especially if the simple one suggests that oneself doesn't have to change at all and can just continue along. Wishful thinking.
@david Yeah. A horrendously wrong but *simple* solution often outpaces are bit more correct but complex one. Especially if the simple one suggests that oneself doesn't have to change at all and can just continue along. Wishful thinking.
@aelaraji Same. It actually goes for anything AI-related. It's best kept in /dev/null.
@aelaraji Same. It actually goes for anything AI-related. It's best kept in /dev/null.
@movq @arne Ach Herrjeh, was für ein Interview! O_o Unfassbar. Da kannste den Sender auch gleich dichtmachen, sowas braucht ja echt niemand. Der Moderator hört sich in der Tat arg versprengt an. :-(
@movq Oh right, I completely forgot about the media! Maybe a sign that they're losing their relevance? The third power appears to be gone or changed sides. Lots of them work on their own abolishment.
@movq Oh right, I completely forgot about the media! Maybe a sign that they're losing their relevance? The third power appears to be gone or changed sides. Lots of them work on their own abolishment.
@movq @arne Ach Herrjeh, was für ein Interview! O_o Unfassbar. Da kannste den Sender auch gleich dichtmachen, sowas braucht ja echt niemand. Der Moderator hört sich in der Tat arg versprengt an. :-(
@movq I didn't, so it's working fine. :-) I should rotate me as well.
@movq I didn't, so it's working fine. :-) I should rotate me as well.
Na, you're spot on, @movq! The result is an expected, terrible disaster. It just seems the absolute catastrophy is delayed for another four years.
Even though I'm the last one who wouldn't be glad about banning the nazis, I'm not a fan of banning parties in general. I believe that a healthy democracy has to withstand extremists. Whether it's still healthy is debatable. To me it appeared that the failed attempts to ban NPD in the past actually helped them gain more supporters.
The big established parties are all bad traitors. I blame them and their actions to help raise AfD. They just give a fuck about the ordinary people, they're only concerned about their private gain and power. I bet nothing will change, to the contrary, it will only get worse. The winners do have the chance to turn it for the better, but they just will not. No way, unfortunately.
But then, we must not forget that people are just dumb and stupid, too. Also, that won't change. AfD won't help these idiots either, but they still vote for them. I also don't understand how there is still so much support for the other big parties left. Education is important. Very important. But I have the impression that we're lacking it.
Na, you're spot on, @movq! The result is an expected, terrible disaster. It just seems the absolute catastrophy is delayed for another four years.
Even though I'm the last one who wouldn't be glad about banning the nazis, I'm not a fan of banning parties in general. I believe that a healthy democracy has to withstand extremists. Whether it's still healthy is debatable. To me it appeared that the failed attempts to ban NPD in the past actually helped them gain more supporters.
The big established parties are all bad traitors. I blame them and their actions to help raise AfD. They just give a fuck about the ordinary people, they're only concerned about their private gain and power. I bet nothing will change, to the contrary, it will only get worse. The winners do have the chance to turn it for the better, but they just will not. No way, unfortunately.
But then, we must not forget that people are just dumb and stupid, too. Also, that won't change. AfD won't help these idiots either, but they still vote for them. I also don't understand how there is still so much support for the other big parties left. Education is important. Very important. But I have the impression that we're lacking it.
It was mostly cloudy, but every now and then the sun peaked through. With very little wind, the 12°C felt quite nice. Especially for a hike. With the sun completely hidden and more wind, the lunch break at the summit was a bit chilly, though.
There's a bad looking crack in the climbing rock in 10. When you have eagle eyes, you might be able to see the hooks in the cliff for the climbing ropes. I haven't seen this one before. Also, it looked like several cubic meters of earth, grass and rock fell off the top.
On the way home, it got much more sunny. I found yet another skyrocket stick. That was pretty neat. And we saw the first field of snowdrops. With some bees checking them out. In total we walked a bit over 15km.
Bee slurping on snowdrops
More pics: https://lyse.isobeef.org/waldspaziergang-2025-02-23/
It was mostly cloudy, but every now and then the sun peaked through. With very little wind, the 12°C felt quite nice. Especially for a hike. With the sun completely hidden and more wind, the lunch break at the summit was a bit chilly, though.
There's a bad looking crack in the climbing rock in 10. When you have eagle eyes, you might be able to see the hooks in the cliff for the climbing ropes. I haven't seen this one before. Also, it looked like several cubic meters of earth, grass and rock fell off the top.
On the way home, it got much more sunny. I found yet another skyrocket stick. That was pretty neat. And we saw the first field of snowdrops. With some bees checking them out. In total we walked a bit over 15km.
Bee slurping on snowdrops
More pics: https://lyse.isobeef.org/waldspaziergang-2025-02-23/
Spring must be here. I just saw the first bee of the year. She paid me a visit when I was baking waffles outside as today's hiking tucker.
Spring must be here. I just saw the first bee of the year. She paid me a visit when I was baking waffles outside as today's hiking tucker.
@arne Nur gebrauchtes Lego ist gutes Lego!
@arne Nur gebrauchtes Lego ist gutes Lego!
@arne Right, they're great for upcycling. I knew you'd love that part. ;-)
@arne Right, they're great for upcycling. I knew you'd love that part. ;-)
@xuu Hahaha, this is great! :'-D