Feed was redirected: https://twtxt.andros.dev -> https://twtxt.andros.dev/
Each time my client fetches your feed. It just doesn't make any sense to me. Wouldn't be both, pretty much, be the same (I noticed the
/, yes)?
Each time my client fetches your feed. It just doesn't make any sense to me. Wouldn't be both, pretty much, be the same (I noticed the
Feed was redirected: https://twtxt.andros.dev -> https://twtxt.andros.dev/
Each time my client fetches your feed. It just doesn't make any sense to me. Wouldn't be both, pretty much, be the same (I noticed the
/, yes)?
brew applications. Want to keep it lean!
brew applications. Want to keep it lean!
DVAR - Bedrii Wedrii
https://dvar.bandcamp.com/track/bedrii-wedrii
foto do CD "fayah!" dos DVAR, de onde veio a música escolhida esta semana
DVAR - Bedrii Wedrii
https://dvar.bandcamp.com/track/bedrii-wedrii
foto do CD "fayah!" dos DVAR, de onde veio a música escolhida esta semana
https://connect.mozilla.org/t5/discussions/information-about-the-new-terms-of-use-and-updated-privacy/m-p/87735
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".
https://connect.mozilla.org/t5/discussions/information-about-the-new-terms-of-use-and-updated-privacy/m-p/87735
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".
"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.
"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.
But of course, everyone is welcome to take a look at https://github.com/upputter/TwtxtReaderMK1
> To me it appeared that the failed attempts to ban NPD in the past actually helped them gain more supporters.
What makes AfD stronger *for sure* is just going “lol nah we’re not even going to try”:
https://www.tagesschau.de/inland/innenpolitik/afd-verbot-antrag-100.html
If they don’t try, then it means that “it can’t be that bad, it’s just a normal party”, right? 😡
> To me it appeared that the failed attempts to ban NPD in the past actually helped them gain more supporters.
What makes AfD stronger *for sure* is just going “lol nah we’re not even going to try”:
https://www.tagesschau.de/inland/innenpolitik/afd-verbot-antrag-100.html
If they don’t try, then it means that “it can’t be that bad, it’s just a normal party”, right? 😡
> To me it appeared that the failed attempts to ban NPD in the past actually helped them gain more supporters.
What makes AfD stronger *for sure* is just going “lol nah we’re not even going to try”:
https://www.tagesschau.de/inland/innenpolitik/afd-verbot-antrag-100.html
If they don’t try, then it means that “it can’t be that bad, it’s just a normal party”, right? 😡
I have the books but they don't grow much more past interview level.
I have the books but they don't grow much more past interview level.
ugh, work pushing this late again. just got it done.
#running #treadmill
ugh, work pushing this late again. just got it done.
#running #treadmill
ugh, work pushing this late again. just got it done.
#running #treadmill
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.
@sarahjamielewis@sarahjamielewis https://mastodon.social/@sarahjamielewis/114072293410465140
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.
@sarahjamielewis@sarahjamielewis https://mastodon.social/@sarahjamielewis/114072293410465140
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.
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.
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.
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.
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 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, change is hard. But it is also needed.
@dangoodin@dangoodin https://infosec.exchange/@dangoodin/114034183325328927
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, change is hard. But it is also needed.
@dangoodin@dangoodin https://infosec.exchange/@dangoodin/114034183325328927
foto da trupe "Carreta Furacão' com o logo das cobrinhas do Python sobrepondo o personagem do meio.
https://github.com/johnousterhout/aposd-vs-clean-code/blob/main/README.md
This is something to read and reflect on for days.
https://github.com/johnousterhout/aposd-vs-clean-code/blob/main/README.md
This is something to read and reflect on for days.
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.
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.
- Markdown to Org mode (you need to install Pandoc).
- Centred column.
- Added new logo.
- Added text helper.
The new version I will try to finish the visual thread. You still can't see the thread yet.
https://activity.andros.dev/fileserver/01FQ7FH7RWJCEWS8FG7N1W26TX/attachment/original/01JN0PMNNCDCDC13TBQZMKTZYP.mp4
#emacs #twtxt #twtxtel
- Markdown to Org mode (you need to install Pandoc).
- Centred column.
- Added new logo.
- Added text helper.
The new version I will try to finish the visual thread. You still can't see the thread yet.
#emacs #twtxt #twtxtel
- Markdown to Org mode (you need to install Pandoc).
- Centred column.
- Added new logo.
- Added text helper.
The new version I will try to finish the visual thread. You still can't see the thread yet.
#emacs #twtxt #twtxtel
late in the evening (fucking work). definitely had the urge to drop a deuce for the majority of it. the pace was comfortable.
#running
late in the evening (fucking work). definitely had the urge to drop a deuce for the majority of it. the pace was comfortable.
#running
late in the evening (fucking work). definitely had the urge to drop a deuce for the majority of it. the pace was comfortable.
#running