Neko – A brief history and porting to Javascript – Evert Pot

In the early 90’s, being a frisian kid obsessed with computers there weren’t a
ton of ways to get access to new software or learn more about computers.

The two main ways were exchanging 3.5” diskettes with friends, or go to the
library. One book I remember more than others was “Windows for Kinderen”
(“Windows for Kids”) by Addo Stuur.

I must have been around 10 years old and was obsessed by this book. It covered
Windows 3.0, and when you got the book from the library, it came with a diskette
filled to the brim with shareware. Mostly games and
useless toys, but it still baffles me thinking they were able to cram it all on
a 1.44 megabyte disk. Using floppys from the libraries was even back then a
risky business given that they’re writable! Luckily this mostly went ok.

One that I remembered particularly well was ‘Neko’, an application that
renders a cat in a window that follows your mouse. This must have been a
popular thing to make at the time, because the diskette somehow had space
for 3(!) different ports of this same application.

I don’t know what reminded me of Neko last week, but I started doing some
more research, and found out that the first version was written all the
way back in the 1980’s by Naoshi Watanabe for the NEC PC 9801.

Neko for the NEC PC 9801
Neko for the NEC PC 9801 (1980’s)

After that, it was ported to the Macintosh in 1989 by Kenji Gotoh, and this
art style seems to be the basis of almost every future port:

Neko on Macintosh
Neko on Macintosh (1989)

In 1991, IBM included it in OS/2! Apparently they paid 300,000 YEN, which
is about $3000 CAD in todays money. At this point it also became public
domain.

Neko on OS/2
Neko on OS/2 (1991)

Since then there’s been countless ports for every platform. If you’re running
linux you might be able to install one by just running:

apt install oneko

I also decided to make a version. Neko is now close to 40, so my Neko is
no longer interested in following the mouse, and prefers to just sleep all day
unless you wake it.

Taking a look at Mastodon – Evert Pot

I’ve been a Twitter user and fan since 2007. With Twitter’s future
looking a bit grim, I started looking around if there’s another place to go.

Twitter can’t really be replaced with anything else, because everyone’s
Twitter experience is unique to them and their community. For me, it’s
the main way I stay in touch with my Open Source / HTTP / API / Hypermedia
bubble and some friends. Losing that would suck! Unfortunately, there’s no way
that group would all flock to another platform.

But for the ones that do try something else, the talk of the town seems
to be Mastodon.

Mastodon is interesting. On the surface it might just seem like a
Twitter clone, but it’s based on a federated protocol called ‘ActivityPub’.
What this means in practice is that there’s no central server. There’s
many instances. Each of these instances
is managed by different people, and many of them focus on specific interests.

With email, it doesn’t matter which provider you go with Thanks to universal
SMTP standards that every server uses, you can exchange messages with everyone
else. This is the same with Mastodon. You’re not siloed into a single instance,
and you can follow people from any other instance. Unlike email, it appears
that with Mastodon you can actually migrate to different instances if you don’t
like your current one.

This has some interesting side effects too. I joined the
IndieWeb instance, which is a community I already
loved. And even though I’m not siloed in, I get access to a local feed of
like-minded people from that community. Everything feels new and more
intimate.

Also, instead of one central authority that you have to trust to make the right
moderation decisions, you can join one of many that aligns with your values,
and you can block entire instances that don’t.

So should you join? If you use Twitter to stay on top of news and follow high
profile people then probably not. If you’re like me, you might be able to
find a community that fits your interest.

Will I stick to this? Who knows… but Twitter, like everything before,
will fall out of favor one day and I’m enjoying Mastodon’s ad-free, open source,
developer-friendly experience. Reminds me of early Twitter or mid-2000’s
blogging culture.

Lastly, one of the interesting results of Mastodon building on open protocols,
is that it allows alternative implementations.

The Microblog.pub project lets you self-host a
single-user instance. Instead of joining some large instance, you deploy
an instance on your own domain that’s just for you. Can’t get more control
than that, and this might be something I’ll consider in the future.

I don’t see why this blog couldn’t one day also be a ‘microblog’ and part of the
fediverse.

PHP 8.2.0 RC5 available for testing – PHP: Hypertext Preprocessor

The PHP team is pleased to announce the fifth release candidate of PHP 8.2.0, RC 5. This continues the PHP 8.2 release cycle, the rough outline of which is specified in the PHP Wiki.For source downloads of PHP 8.2.0 RC5 please visit the download page.Please carefully test this version and report any issues found in the bug reporting system.Please DO NOT use this version in production, it is an early test version.For more information on the new features and other changes, you can read the NEWS file, or the UPGRADING file for a complete list of upgrading notes. These files can also be found in the release archive.The next release will be the sixth release candidate (RC 6), planned for Nov 10th 2022.The signatures for the release can be found in the manifest or on the QA site.Thank you for helping us make PHP better.

PHP 8.2.0 RC 4 available for testing – PHP: Hypertext Preprocessor

The PHP team is pleased to announce the release of PHP 8.2.0, RC 4. This is the fourth release candidate, continuing the PHP 8.2 release cycle, the rough outline of which is specified in the PHP Wiki. For source downloads of PHP 8.2.0, RC 4 please visit the download page. Please carefully test this version and report any issues found in the bug reporting system. Please DO NOT use this version in production, it is an early test version. For more information on the new features and other changes, you can read the NEWS file or the UPGRADING file for a complete list of upgrading notes. These files can also be found in the release archive. The next release will be the fifth release candidate (RC 5), planned for 27 October 2022. The signatures for the release can be found in the manifest or on the QA site. Thank you for helping us make PHP better.

Refactoring without tests should be fine – Matthias Noback

Refactoring without tests should be fine. Why is it not? When could it be safe?

From the cover of “Refactoring” by Martin Fowler:

Refactoring is a controlled technique for improving the design of an existing code base. Its essence is applying a series of small behavior-preserving transformations, each of which “too small to be worth doing”. However the cumulative effect of each of these transformations is quite significant.

Although the word “refactoring” is used by programmers in many different ways (often it just means “changing” the code), in this case I’m thinking of those small behavior-preserving transformations. The essence of those transformations is:

  • The structure of the code changes (e.g. we add a method, a class, an argument, etc.), but
  • The behavior of the program stays the same.

We perform these refactorings to establish a better design, which in the end will look nothing like the current design. But we only take small, safe steps. Fowler mentions in the introduction of the book that tests are necessary to find out if a refactoring didn’t break anything. Then the book goes on to show a large number of small behavior-preserving transformations. Most of those transformations are quite safe, and we can’t think of a reason why they would go wrong. So they wouldn’t really need tests as a safety net after all. Except, in practice, we do need tests because we run into problems, like:

  1. We make a mistake at syntax-level (e.g. we forget a comma, a bracket, or we write the wrong function name etc.)
  2. We neglect to update all the clients (e.g. we rename a method, but one of the call sites still uses the old name)
  3. An existing test is tied to the old code structure (e.g. it refers to a class that no longer exists after the refactoring)
  4. We change not only the structure, but also the behavior

I find that a static analysis tool like PHPStan will cover you when it comes to the first category of issues. For instance, PHPStan will report errors for incorrect code, or calls to methods that don’t exist, etc.

The same goes for the second category, but there’s a caveat. In order to make no mistakes here, we have to be aware of all the call sites/clients. This can be hard in applications where a lot of dynamic programming is used: a method is not called explicitly but dynamically, e.g. $controller->{$method}(). In that case, PHPStan won’t be able to warn you if you changed the method name that used to be invoked in this way. It’s why I don’t like methods and classes being dynamically resolved: because it makes refactoring harder and more dangerous. In some cases we may install a PHPStan extension or write our own, so PHPStan can dynamically resolve types that it could never derive from the code itself. But still, dynamic programming endangers your capability to safely refactor.

The third group of failures, where tests become the problem that keeps us from making simple refactorings, can be overcome to a large extent by writing better tests. Many unit tests that I’ve seen would count as tests that are too close to the current structure of the code. If you want to extract a class, or merge two classes, the unit test for the original class really gets in the way, because it still relies on that old class. We’d have to rewrite, rename, move tests, in order to keep track of the modified structure of the code. This is wasteful, and unnecessary: there are good ways to write so-called higher-level tests that aren’t so susceptible to a modified code structure. When the structure changes, they don’t immediately become useless or break because of the modified structure.

From my own experiences with refactoring-without-tests, I bet the fourth category is the worst and hardest to tackle. It often happens that you don’t just make that structural change, but add some semi-related change to the same commit, one that turns out to change the behavior of the code. I’ve found that you really need to program in (at least) a pair to reduce the number of mistakes in this category. A navigator will check constantly: are we changing behavior here as well? Is this merely the structural changes we were here for? Examples of mistakes that I made that were more than the small behavior-preserving transformations that refactorings were intended to be:

  • I removed stuff that seemed unused (correctness of such a change may be really hard to prove)
  • I changed settings, tweaked stuff hoping for a better performance (this has to be proven with a benchmark)
  • I tried to replace the design of several classes at once, instead of in the step-by-step fashion that refactoring requires.

I think as developers we’ve deviated a lot from the original idea behind refactoring. We’ve been hoping to impr

Truncated by Planet PHP, read more at the original (another 564 bytes)