I has happened from time to time that some monks have expressed concern over the unexpected and prolonged absense of another monk.
In at least one case, a monk contacted the gods to see if a reachout could be done.
Unfortunately, we had to say no, because the contact information stored in the user profile consists only of an email address,
and our policies explicitly state this this email address "is used only to send you your password".
I believe that this creates — correctly — a strong expectation of privacy around this personal information.
Therefore, I would like to propose the addition of an "emergency contact" field, which would probably normally be an email address,
but with a different expectation as to its potential usage.
The use of this field would be strictly optional. That is, as a user, you wouldn't have to put anything in it unless you want to.
Alternatively, we could add a checkbox which, when checked, indicates that you are OK with site administrators using the
existing email for "emergency contact" purposes, in addition to its current purposes (i.e. password recovery).
As you might know, Tanktalus is retiring his CBStats/last hours of cb service. In agreement with gods and Tanktalus, i have taken over the duties of providing these services.
I've been working hard to get the new codebase for last hour of cb and cb stats to work reasonably well. Stats are still a bit bare, though. And i'm pretty sure there are plenty of bugs.
The new services (and the PM nodes) are run by the new chatterbot account. It's profile provides the official documentation, that is, it will provide it as soon as i get around to writing the damn thing. Technically, i'm running TWO of these services under the same account, one live, one for development/request-for-comment purposes. So, i might sometimes link to one of the dev pages and ask for feedback.
All bug reports and feature requests and questions, at least for now, should go into this discussion, directly as an answer to THIS post (that way, CB automatically notifies me of any new messages). For short things, send me a private message. (Don't send it to chatterbot, i seldomly log into this account, except by way of perl scripts).
Q: So this new CB stats is a downgrade?
A: Yes and no. The stats are not as feature rich as the old ones. I'm working on that. But on the bright side, chatterbot has the ability to understand commands. Currently, there is only 1 useful one:
This will generate a snapshot of the current "last hour of cb" and send you a link via private message. This may take about minute, and it currently doesn't always work. But when you see something in chatterbox that you like, give it a whirl.
Make chatterbot send a user a cookie. It's one of my test commands, so no guarantees that cookies will be, in fact, delivered.
When you are not sure what commands are available, you can type !help in chatterbox.
Command parsing and answering takes some time, because of the relatively long work cycles i've set in the software. (My software could run hundreds of calls to PM a seconds to make processing lightning fast, but running a denial-of-service attack on my favourite website would be counterproductive).
Recently (maybe 3 weeks ago now) something appears to have changed which means that frequently pages which would have loaded quickly now load much more slowly. My experience has always been that this site is fast by the standards of the modern web - almost everything downloads and finishes rendering in well under a second. But the last few weeks has seen this significantly alter where some requests are taking a great deal longer - up to 15 or 20 seconds in some instances and very often 5 seconds or more. This is a noticeable degradation.
Investigating via the in-browser tools shows that this is a delay in initial HTTP response. It's not DNS or the TLS setup, both of which happen very quickly, but after that the page response is the one which takes a long time to start. This can happen on any page and it doesn't seem to be some more than others.
Hopefully whatever is causing this is easy to find and simple to resolve. It would be great to have the old, snappy performance back again. :-)
This was discussed in the CB at the end of last week. Since that confirmed that it isn't just me affected, I'm raising it here for TPTB to be made aware.
It is with some regret that I've come to realise that my return to Perl is unlikely, let alone any time soon. Since I've not really been an active participant in this community in years, I think it's prudent to accept the truth and pass on the torch.
I will be shutting down the CB stats service I've been running for probably over a decade now by the end of the year. That service also provides last hour of cb, and so that will also disappear.
While I'm more than willing to pass on the codebase I have to any who ask for it (my nick at gmail.com), please be forewarned: it's not the cleanest code, and it was used to learn both Coro and DB2 (the latter of which for whom I worked at the time), and you'll probably want to re-seat it against a different database, the queries will be significantly less performant (sorry, but the joins are things that DB2 objectively does better than MySQL). I've gone on to do a lot of work against various databases, and what I learned writing this helped immensely, so I have zero regrets about doing it.
Why am I no longer doing Perl? Well, it's simple. After working from home for 13 years, I was told to return to Toronto. That wasn't going to happen, so I had to find another job. Took me 18 months, during which time I managed to hold on to the work-from-home position. What I found was something doing C# on Windows. That job was, let's just say, sub-optimal, and a bit over a year later I found another local job still with C#, leading a small team. I've been here for over four years at this point. By January, it'll have been about 5 years since I did any significant amounts of Perl.
Also, while working from home, I also helped out with an online game written in Perl, which got shut down shortly before I left the work-from-home position. I've come to realise that part of its cost in running came down to Perl - specifically, its lack of threading and co-routine support. (Yes, Coro works, but it's a serious hack to the point where I'm not confident in its future, but also its ability to support all the drivers and such that would be required for this.) I've wanted to re-start this game, but only recently embarked on this, and decided a better backend for this game would be .NET whose native support for threads and co-routines (async/await) is significantly stronger, but also because I'm already using that in my day job, so it becomes advantageous to stay ahead of the team that reports to me on technical matters this way. This serves to drop my chances at returning to Perl in any significant manner even further.
I cannot guarantee a timely return to view any responses here. You're better off with email if you feel the need to reach me. While I, personally, don't see any harm in multiple monks having their own CB scrapers and CB stats generators, you will definitely need the gods approval to take over the last hour of cb, as they will have to assign ownership to someone.
This node doesn't show the 'in reply to' and 'in thread' hyperlinks for me. I first suspected some user based setting based on depth, but this doesn't seem to be the case as this displays them as expected.
Update: I don't recall seeing this before. Does it render for everyone else the way it does for me?
PerlMonks already has a dark theme, but it is not automatically selected when not logged in. Literally every website, app, IDE etc. I use regularly nowadays supports a dark mode, and opening PerlMonks in the evenings, e.g. on mobile where I'm not logged in by default, is therefore much less enjoyable to my eyes, and I suspect it's similar for anyone who has selected the dark mode on their mobile, OS, or browser.
Supporting dark mode is easy nowadays with the corresponding CSS media selector. I propose a new color theme, "auto light/dark", and making this the default for non-logged-in users. This change would only affect users who are not logged in, and only those who have selected dark mode in their OS/browser - all other visistors will see no difference; logged in Monks could select the new theme in their display settings if they prefer. The other great thing is that supporting this and changing the theme doesn't require any server-side detection, JS, or even page reloads.
Is the restriction on image definition and size for our profile pics due to storage limitation?
I updated my own after numerous years and found that the limitations seemed to be possibly antiquated a little bit. I had to hack at my image in Preview on my Macbook and I'm not complaining, but it did get me to wonder why the restrictions seem so limited.
Does anybody else get this error? When I visit PerlMonks, I get a certificate expired message in my web browser. It doesn't matter which browser I use. Same thing happens when I visit PerlMonks on my phone. I get an error message. Apparently the expiration date is Sunday, September 17, 2023 which is today. Can somebody fix this? Btw I wouldn't mind if PerlMonks went back to use HTTP only. Saves you some money. I see no reason why PerlMonks should be using HTTPS. This is not a bank. What are you trying to protect?
Snippets of code should be wrapped in
<code> tags not<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor