lyse

lyse.isobeef.org

No description provided.

Recent twts from lyse
In-reply-to » For a real feed format I would like to have a clear separation between titles and content. And more options for the content. Plaintext and HTML at least.

@darch@neotxt.dk Titles and subjects are two different things in my opinion. A title is a caption, brief summary or some description of a longer content that follows. A subject is a – in this case human readable – reference in a reply to some topic in order to group several twts to a conversation. Forks aside, the first twt starting a discussion typically doesn’t have a subject. But some article would have a title in most cases. You are right in that the subject mechanism could be abused for a crude title implementation. I wouldn’t do it, though.

⤋ Read More
In-reply-to » For a real feed format I would like to have a clear separation between titles and content. And more options for the content. Plaintext and HTML at least.

@mckinley Even though I miss a title for general purposes, I’m not sold of cramming it into twtxt. It’s just not made for it. To only announce new articles, that format would work, though. It’s basically what some people already do, except a space rather than a tab is used between the title and link.

⤋ Read More
In-reply-to » Related with my current conversation, what do you think of using twtxt.txt as a format for feeds?

Not sure which conversation you mean, @eaplmx@twtxt.net (it’s already quite late here), but here’s my take: I think twtxt it’s not heavy enough. For a real feed format I would like to have a clear separation between titles and content. And more options for the content. Plaintext and HTML at least. Twtxt is plaintext, but lots of folks (me included) actually use markdown in their yarns. However, the actual format being used is not advertised anywhere. To make things worse, I actually prefer reStructuredText over markdown. For podcasts some enclosure-like thing would be nice as well. Twtxt being line based also really limits structuring of longer content by hand. Just can’t produce a nice source file.

On the other hand, RSS and Atom being XML are way too heavy for my taste. And then there’s JSON feed. It’s been a while since I skimmed over it, can’t remember the details, but I wasn’t sold on this one either. I also never encountered any JSON feed in the wild. So I’m still on my quest to find an optimal feed format.

⤋ Read More
In-reply-to » Guys, I have a bad news, I went through the twtxt-osphere : - I found 1289 twtxt account - among those 721 are accessible ( 712 http / 9 gemini / 0 gopher) - but only 111 account are still active in 2022 :S (107 http / 4 gemini / 0 gopher).

@tkanos So basically it counts the mentions? We definitely need some feed normalization database, too many broken mentions out there. :-)

⤋ Read More
In-reply-to » Writing and running full e2e integration tests using Go and for Go CLI applications. Lookingo into one of:

@prologic@twtxt.net Whoops, I must have missed the error return value! That sounds good to me. When there are just fatal errors that abort the program execution, a main function returning an error is definitely enough.

Hmm, if you don’t want to report errors to stderr, where do you write them to? Hopefully not stdout. A log file? It obviously depends on the program and such, but generally I do not want to dig up errors from a log file. Usually, I find it much more convenient to see them directly. Properly dealing with stdout and stderr basically provides the capabilities for free to be pipeline-ready. And of course, -q or something along those lines is also a good choice. When talking about more serious programs, that is. Not just some quickly cobbled together helper.

⤋ Read More
In-reply-to » 💡 TIL: Today I learned that there is nothing special about pkg/ inside of Go projects. It is just like any other sub-package structure you might otherwise define in your project. It just adds an extra part to your imports. I think it's actually confusing at best and just unnecessary typing and an unnecessary sub-structure. Just keep your packages in the top-level and be done with it 👌

@prologic@twtxt.net I’m bad with terminology, sorry. But I think, we’re basically on the same page. The only thing I wanted to say is, that I fully agree with @brasshopper@twtxt.net’s theory here and tried to elaborate a bit.

Even if you have a very deep knowledge of one language, you typically won’t know about all the styles, patterns, spirits, etc. when starting to pick up a new one. Some ideomatics are just different. So when tackling something, you naturally do it like you’ve been doing it before in other language(s). In the beginning it just doesn’t occur to you, that something might be done (entirely) differently in this new language. It takes time to pick up and sometimes even more to wrap your head around it. Open-mindedness certainly also helps, I found. The more you’ve really worked with different languages, the more your little knowledge base grows. Hence, you know that things can be solved in lots of different ways. And that will basically bring you awareness, that you might want to look out for the specific procedures of doing something in that other language you’re using.

⤋ Read More
In-reply-to » Guys, I have a bad news, I went through the twtxt-osphere : - I found 1289 twtxt account - among those 721 are accessible ( 712 http / 9 gemini / 0 gopher) - but only 111 account are still active in 2022 :S (107 http / 4 gemini / 0 gopher).

@tkanos I have the same question as @mckinley. What is influence? If I’m third place, I should probably slow down. :-D

⤋ Read More
In-reply-to » Writing and running full e2e integration tests using Go and for Go CLI applications. Lookingo into one of:

@prologic@twtxt.net Logging is different, I meant regular errors messages. E.g. you invoke the program with an invalid argument or something else goes wrong. That should then be reported on stderr and not stdout. When striving for a good coverage rate, error cases should not be forgotten in my opinion. Ideally, error messages are tested, too. I’ve seen a bunch of cases in the past, where something was broken, because there weren’t any tests. But to be fair, I neglect them most of time, too. :-( Just checked, go-cmdtest merges both stdout and -err, that’s a no-go in my books.

⤋ Read More
In-reply-to » 💡 TIL: Today I learned that there is nothing special about pkg/ inside of Go projects. It is just like any other sub-package structure you might otherwise define in your project. It just adds an extra part to your imports. I think it's actually confusing at best and just unnecessary typing and an unnecessary sub-structure. Just keep your packages in the top-level and be done with it 👌

@prologic@twtxt.net @brasshopper@twtxt.net @tkanos@twtxt.net Exactly, you just know what you know. You simply can’t follow a pattern which you haven’t heard of, so you just stick to what you’ve been doing in the past. From my own experience and what I’ve seen from others, it’s getting much better with more experience.

⤋ Read More

Autumn is here, 17°C tops, in the night even 4°C. In fact, 0°C this morning. It chilling. Went up our backyard mountain again and had a great view. The rain in the beginning of the week helped to clear the air. We had a bloody awesome sunset today. Incredibly red light everywhere, unbelievable. Photos don’t do justice.

40km away Stuttgart TV Tower after sunset

⤋ Read More
In-reply-to » Writing and running full e2e integration tests using Go and for Go CLI applications. Lookingo into one of:

That’s quite a complicated hello world, @prologic :-D

My main()s often also just do os.Exit(run()). Passing the command line arguments run run(…) seems like another obvious thing to do. Even though, I should have done this more consistently, I reckon. I feel very stupid now, because for whatever reason, it never occurred to me to simply pass an io.Writer for stdout. I really like that. Although, I’m wondering why there’s nothing for stderr. Errors should definitely not mix with other output in my opinion. Anyways. When testing, I always captured stdout with a much more complicated code segment so far. Store the original output and error streams, set the new ones, execute the test, convert things to strings and finally reset to the original streams. I will definitely adopt these io.Writer arguments. Thanks, mate! :-)

This cmdtest test execution also captures the coverage? It looks kinda more complicated than it should be, otherwise. Just a program with the test definition file would be enough in my opinion.

I don’t know if I like the concept of providing a single test definition file or not. It’s a bit intriguing, but I fear that’s not flexible enough. Just a gut feeling, might be wrong.

⤋ Read More
In-reply-to » I have a new Atom feed at https://mckinley.cc/blog/atom.xml. Open it in a Web browser for a surprise. :)

@mckinley@mckinley.cc Crazy! My feed preview extension kicked in and rendered the feed as it is supposed to do. Hence, I had to open it in porn mode to enjoy your black magic. I’m very surprised that the XSLT is this short. And that I could easily understand it. It’s been at least six years since my former employer forced me to use XSLT. Just the $ prefixes surprised me, didn’t remember them at all.

⤋ Read More