# 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 235306
# self = https://watcher.sour.is?offset=232384
# next = https://watcher.sour.is?offset=232484
# prev = https://watcher.sour.is?offset=232284
@andros I wouldn't call it regular, but cyclical. Since, with the exception of Yarn (maybe?), clients are everything when it comes to twtxt, every now and then we see an increase of interest on new development. I have seeing them come and go, only few "beside remains". :-)
@andros I wouldn't call it regular, but cyclical. Since, with the exception of Yarn (maybe?), clients are everything when it comes to twtxt, every now and then we see an increase of interest on new development. I have seeing them come and go, only few "beside remains". :-)
@movq ahh, living in a small house in the middle of nowhere, yes! That's my dream too. We live in the suburbs, in a relatively small community; it isn't enough, though. Take a sick day, and blast that amp! :-D
@movq ahh, living in a small house in the middle of nowhere, yes! That's my dream too. We live in the suburbs, in a relatively small community; it isn't enough, though. Take a sick day, and blast that amp! :-D
There they tell users that "You stay in control". Unfortunately, their new Terms of Use say that:
"Every once in a while, Mozilla may decide to update these Terms. We will post the updated Terms online. We will take your continued use of Firefox as acceptance of such changes."
No matter how common this has become over the past years, this is quite unacceptable, and Firefox users deserve better from Mozilla. The fact that they can unilaterally change the terms and users are automatically bound to them (as soon as they use the browser again - even if they're using it to open the document where they can see the date on the terms!) is not a fair agreement - and works against the claim that "You stay in control".
There they tell users that "You stay in control". Unfortunately, their new Terms of Use say that:
"Every once in a while, Mozilla may decide to update these Terms. We will post the updated Terms online. We will take your continued use of Firefox as acceptance of such changes."
No matter how common this has become over the past years, this is quite unacceptable, and Firefox users deserve better from Mozilla. The fact that they can unilaterally change the terms and users are automatically bound to them (as soon as they use the browser again - even if they're using it to open the document where they can see the date on the terms!) is not a fair agreement - and works against the claim that "You stay in control".
@mozillaofficial@mozillaofficial in the meantime updated their news item to add this "explanation" regarding one of the items within the terms that has been criticized:
"We need a license to allow us to make some of the basic functionality of Firefox possible. Without it, we couldn’t use information typed into Firefox, for example."
In the explanation, they don't tell us -what- is that "some basic functionality" they refer to, or why would Mozilla need to use information typed into Firefox, for example.
@mozillaofficial@mozillaofficial in the meantime updated their news item to add this "explanation" regarding one of the items within the terms that has been criticized:
"We need a license to allow us to make some of the basic functionality of Firefox possible. Without it, we couldn’t use information typed into Firefox, for example."
In the explanation, they don't tell us -what- is that "some basic functionality" they refer to, or why would Mozilla need to use information typed into Firefox, for example.
@andros I don't get the "layers" bit at all, but the composability ist just common sense to me. It requires a good language though with the right levels of abstractions. i.e: prefer interfaces over classes.
I have the feeling, that I have come to a dead end with my first version of the TwtxtReader. That's why I'm stopping the project and starting again. But of course, everyone is welcome to take a look at https://github.com/upputter/TwtxtReaderMK1
I agree. finding good writings on architecture is hard to find. I used to read architecture reviews over on the high scalability blog. i suspect the reason why is that the arch is how the big tech companies can build moats around their bases. I know in AWS world it only goes as far as how to nickle and dime you to death.
I have the books but they don't grow much more past interview level.
@mozillaofficial@mozillaofficial decided to add "Terms of Use" to #Firefox.
If you just asked "WTF?", welcome to the club.
Of course, this doesn't make sense, it couldn't be just like that... so I went on and read the terms. The trick is specifically on this bit:
"These Terms only apply to the Executable Code version of Firefox, not the Firefox source code."
So sure, Firefox is still the Free Software codebase you were used to, only now if you want to use not the code but Mozilla's distributed binaries, you'll do so while also agreeing to some Terms of Use and Privacy Policy.
The trick is, of course, to not use their binaries. In practice, things are a bit trickier. Ubuntu, for instance, was more than happy to ditch their self-compiled Firefox packages and use Mozilla-provided snaps instead.
But trickier or not... well, Mozilla has just made an unhappy user base unhappier - and I hope they reap what they are sowing.
@mozillaofficial@mozillaofficial decided to add "Terms of Use" to #Firefox.
If you just asked "WTF?", welcome to the club.
Of course, this doesn't make sense, it couldn't be just like that... so I went on and read the terms. The trick is specifically on this bit:
"These Terms only apply to the Executable Code version of Firefox, not the Firefox source code."
So sure, Firefox is still the Free Software codebase you were used to, only now if you want to use not the code but Mozilla's distributed binaries, you'll do so while also agreeing to some Terms of Use and Privacy Policy.
The trick is, of course, to not use their binaries. In practice, things are a bit trickier. Ubuntu, for instance, was more than happy to ditch their self-compiled Firefox packages and use Mozilla-provided snaps instead.
But trickier or not... well, Mozilla has just made an unhappy user base unhappier - and I hope they reap what they are sowing.
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.
"So old, but so old, that not even the Internet knows what it is!"
Dear Internet, can you prove them wrong and tell me what "Heller" from this tin box used to be? "Heller", a metal logo on a tin box' lid, both a bit rusty.
"So old, but so old, that not even the Internet knows what it is!"
Dear Internet, can you prove them wrong and tell me what "Heller" from this tin box used to be? "Heller", a metal logo on a tin box' lid, both a bit rusty.
@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.
I know, the great is enemy of the good, we all have Things To Do (TM), and that's not your core business.
I've heard it all, and I know: there is a million reasons not to do something, specially if it doesn't affect you particularly. That’s why we (still?) have buildings with stairs but no ramps, digital systems without backups... or infrastructure running on proprietary third-parties.
I know, I've heard it all. You'd love to, but you really don't have an alternative to google docs yet, zoom can't be that bad anyway since everyone seems to use it, and here's our form you have to fill in - hosted by Qualtrics. Between the "you don't care because it isn't a problem to you" and the "I get you, I really do, but I don’t have the means to switch", we both know that your parents group will either remain on WhatsApp or move away from it "soon".
The problem is, it is already too late. What if there's someone needing their union, but the conversation happens over slack?
I know, the great is enemy of the good, we all have Things To Do (TM), and that's not your core business.
I've heard it all, and I know: there is a million reasons not to do something, specially if it doesn't affect you particularly. That’s why we (still?) have buildings with stairs but no ramps, digital systems without backups... or infrastructure running on proprietary third-parties.
I know, I've heard it all. You'd love to, but you really don't have an alternative to google docs yet, zoom can't be that bad anyway since everyone seems to use it, and here's our form you have to fill in - hosted by Qualtrics. Between the "you don't care because it isn't a problem to you" and the "I get you, I really do, but I don’t have the means to switch", we both know that your parents group will either remain on WhatsApp or move away from it "soon".
The problem is, it is already too late. What if there's someone needing their union, but the conversation happens over slack?
@doesnmppsflt this one is the safest feed to follow. Quark's will cease to exist, as I am not renewing the domain. Bender's will eventually fade away too, I am afraid. "No show, however good, can last forever." :-)
@doesnmppsflt this one is the safest feed to follow. Quark's will cease to exist, as I am not renewing the domain. Bender's will eventually fade away too, I am afraid. "No show, however good, can last forever." :-)
Tem um livro aberto muito legal do VanderPlas que eu costumo indicar que chama "A Whirlwind Tour of #Python" (https://jakevdp.github.io/WhirlwindTourOfPython/) e eu sempre penso que é tipo uma "Turnê furacão pelo Python" 😂 foto da trupe "Carreta Furacão' com o logo das cobrinhas do Python sobrepondo o personagem do meio.
This document is the result of a series of discussions between Robert "Uncle Bob" Martin and John Ousterhout, held between September 2024 and February 2025. The text addresses three main topics: method length, comments, and Test Driven Development (TDD). https://github.com/johnousterhout/aposd-vs-clean-code/blob/main/README.md This is something to read and reflect on for days.
This document is the result of a series of discussions between Robert "Uncle Bob" Martin and John Ousterhout, held between September 2024 and February 2025. The text addresses three main topics: method length, comments, and Test Driven Development (TDD). https://github.com/johnousterhout/aposd-vs-clean-code/blob/main/README.md This is something to read and reflect on for days.
I read a lot about Clean Code, SOLID, TDD, DDD... now I'm discovering «A Philosophy of Software Design»... but nobody talks about the importance of the project architecture. Do we depend on the framework to do the work for us? You know I'm a big fan of Clean Architecture, but I feel alone when I share my thoughts on social media or at work. You have to think outside the framework.
I read a lot about Clean Code, SOLID, TDD, DDD... now I'm discovering «A Philosophy of Software Design»... but nobody talks about the importance of the project architecture. Do we depend on the framework to do the work for us? You know I'm a big fan of Clean Architecture, but I feel alone when I share my thoughts on social media or at work. You have to think outside the framework.
Pinellas County - 4 mile run: 4.06 miles, 00:08:50 average pace, 00:35:50 duration late in the evening (fucking work). definitely had the urge to drop a deuce for the majority of it. the pace was comfortable. #running
Pinellas County - 4 mile run: 4.06 miles, 00:08:50 average pace, 00:35:50 duration late in the evening (fucking work). definitely had the urge to drop a deuce for the majority of it. the pace was comfortable. #running
Pinellas County - 4 mile run: 4.06 miles, 00:08:50 average pace, 00:35:50 duration late in the evening (fucking work). definitely had the urge to drop a deuce for the majority of it. the pace was comfortable. #running
I like gopher so far. Probably gonna increment the amount of gopher servers by 1 soon. Could also make custom client and server software for it, since it's so simple.
Fiz uma pesquisa sobre o SNS, dei com uma coisa escrita pela DGS... no Facebook. Li, mas também vi as dezenas de comentários. Todos(!) eles eram comentários de desinformação (antivax), ainda que hovessem dois ou três "comentários de comentários" a tentar por algum juízo naquilo.
Fiz uma pesquisa sobre o SNS, dei com uma coisa escrita pela DGS... no Facebook. Li, mas também vi as dezenas de comentários. Todos(!) eles eram comentários de desinformação (antivax), ainda que hovessem dois ou três "comentários de comentários" a tentar por algum juízo naquilo.
@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.
@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. :-(