Here in the US, NIST has deprecated the use of SMS as 2-factor auth[1] on the grounds that "there’s a risk that SMS messages can be intercepted or redirected".
There was an easter egg in Windows 95 for clouds.mid.[1] You had to create a folder and rename it a few times, and then it would play the song[2]. Even hearing it now takes me back to a simpler time...
My dad worked for a rather large insurance company. One of the hacks printed the user's name, marched it around the border of the terminal (thin client to the mainframe) and then deleted itself before giving the user their prompt back.
Yep worked for a pretty large company and they had a (capable), high ranking dev guy who was prone to add easter eggs in the UI. Konami code would cause something to fly across the screen etc. The live product was taken down twice due to these easter eggs.
The amount of complexity, bugs, and security vulnerabilities in modern software is already at a staggering level purely due to non-easter-eggs. Not only will allowing the developers to occasionally have some fun help them to be more engaged (and produce higher-quality software as a result), but a well-implemented easter egg touches a highly localized portion of the system and won't introduce any of the above in the first place.
The vowel shift is one of the major reasons why Shakespeare's poetry doesn't rhyme when spoken with modern English. There was a rather fascinating video that went around awhile back of a father and son demonstrating the changes.[1]
Shakespeare's plays post-date the bulk of the Great Vowel Shift. The reason they don’t rhyme is only partly because of the very last phases of the Great Vowel Shift, and partly due to the changing English dialectal landscape.
The classic English author for whom the Great Vowel Shift is most relevant, in terms of audiences today not pronouncing the text anywhere near as society then would have, is Chaucer.
It's funny, for at least the first example, original pronunciation just sounds like Hagrid from the Harry Potter movies, which is especially interesting considering that's intended to be a less formal/"lower class" accent. Reminds me of something I heard once that the modern american accent is actually closer to the british accent at the time of the revolutionary war, and it's the british accent that's changed more since then. No idea if that's actually true, but it was really interesting when I heard it.
Hagrid has a West Country accent. The character is supposed to come from the Forest of Dean, in Gloucestershire, and the accent is approximately from that area. The most obvious difference from RP English is that it has the rhotic "R", which is how it's closer to standard American and to historical English accents. The non-rhotic R is also found in the Boston accect ("hahvahd yahd").
I seem to remember that the closest thing to an old school English is a costal Maryland/Virginia accent. Which sorta makes sense historically speaking.
It's fascinating how much of this holds out in various accents across the UK, most particularly outside of London and going up north. My mother and grandparents on her side have similar-ish pronunciation of some words with their thick Lancs accents. Not quite farmers accents but still quite archaic in sound sometimes.
(Imagine other examples, like pronouncing 'couch' a bit more like 'cooch')
I run Snapcast across my house connected to MPD running on a local Linux box, and have been pretty happy with it. I've had to do very little maintenance to keep things running.
The main thing I haven't been able to figure out is how to have multiple Snapcast streams and control which room listens to what. I don't actually think it's possible to do.. (though I could be wrong?)
Input streams are configured once on the server. You can group clients together and assign a stream to a group.
This can be done either with Snapdroid https://github.com/badaix/snapdroid or with Snapweb (is shipped with the Snapcast server since version 0.21) https://github.com/badaix/snapweb or with any other control client from the community
I'm in the same boat about RoR. I just find its size to be overkill for most uses. Hanami is considerably smaller and lightweight, but not to the point where it's more of a micro-framework (like Roda). I've been happy with it for a number of microservices and some larger websites.
There's also the Edo-Tokyo Open Air Architectural Museum outside of Tokyo[1] (in Koganei, not the one in Ryogoku) that has some three dozen buildings that have been moved there. They go back as far as the Edo period. Well worth the time if you're in the area (though admittedly, kinda hard to get to).
I'm on a team that started doing Scrum a few months ago, and we're still figuring it out.
To be clear: are you saying that the one team that did Scrum well did so because they spent more time on the process? Reading what you wrote, spending two full days every two weeks to plan sounds, well, terribly dragged out. Does it feel like the time was well spent, or was it a slog?
It did not seem dragged out, it was just thorough, and reasonably un-rushed. It was somewhat tiring, but definitely worth it.
By the end of the planning meeting, we had a clear idea of what we were going to accomplish, and a reasonable amount of confidence that we considered all the tasks that went into our plan.
Because when a story was, e.g. "add addresses to the clients page", it was broken down, discussed, thought out, and agreed upon. The moments when I discovered, oh shit, this story will actually take 10 hours longer than I had allocated, and now I have to stay until 10PM two days this week to meet my committment. Because our story points were approximately an hour each, and almost every story was broken down until there were no tasks more than 3 points each, 1 or 2 preferred.
It was all thanks to our scrum-master/project manager, who had actually spent a lot of time learning about scrum/agile/kanban/etc, read many books on it, and most of all, was committed to doing it right.
I think our sprints were a bit longer than 2 weeks.
I had a similar experience, where we would spend at a full day every sprint planning the sprint (team of 5).
During the project, it felt like a bit of a waste. We were spending a full 10% of our time on project management. However, looking back, I see that a) it seems to match up with other's experience, and b) it's pretty much the same amount of overhead for project management that the project would have had using any methodology.
At least with the 1-2 days every 2 weeks everyone sees it and it's something you can get better at. I'll take that over magical GANTT charts any day.
> are you saying that the one team that did Scrum well did so because they spent more time on the process?
Creating fine-grained, detailed user stories and making sure that everyone understand them and agrees on the prioritization is not time spent on "the process", it's requirements engineering.
I just read your comment again, and I want to add this to my other reply:
I would say the top, most useful, make-or-break practice that I would say is most essential to Scrum succeeding is a combination of:
* 1 point ≈ 1 hour of work
and
* no task above 3 points, try to only have 1-point tasks
Coincidentally, this process is what took the longest in our planning meetings, because the coders sat down and planned out the tasks, kind of the way you would in an algorithms course.
The payoff is that our estimates, after the first couple of sprints, were dead on, and there was very little "discovered work" mid-sprint. No midnight oil. And no corner-cutting.
[1] https://www.zdnet.com/article/nist-blog-clarifies-sms-deprec...