(Disclosure: this may work for me but not for others, see the bottom of this piece for why.)

Vue is one of the larger and more popular Javascript frameworks.

It is very versatile and has great documentation. It can be used in different ways, either using Single File Components or as a library. It supports different API styles (options or composition) and offers a range of build tools. If you want to learn Vue, there is the Guide, the Quick Start and the Tutorial.

In other words, there are a ton of resources for beginners and quite frankly, when I tried to start learning Vue a couple of weeks ago, it was too much. I could not see the forest for the trees.

And by that I mean: I failed to start making even the simplest of applications in Vue.

So here is what I ended up doing:

(The underlying assumption being that you, like I, already know the 3 web technologies of HTML, CSS and Javascript.)

• Follow the exercises in the Tutorial.
• Create a minimal app in the Playground.
  • Hello World suffices, but if you want to see if you can make something more complex, you can do that too.
• Download your prototype from the Playground (button: Download Project Files).
• Download and install node.js.
• CD to your project files.
• npm install
• npm run dev

This is more or less the same procedure as the one outlined in the Quick Start section of vue.js. That section, however, tripped me up, because it produced a more than minimal app, and as such it didn’t give me a very good idea of what a minimal Vue app looks like. (The Quick Start app might help to provide some contrast though, I am certainly not saying that it is useless.)

I ended up scooping out the parts I did not need from the Quick Start app, but this left me with a broken app. I needed a gentler start, something that would let me put “Hello World” on the screen without having to worry about a ton of other things.

The tutorial let me do exactly that, but it would not let me save the results as an app.

The Playground would.

I fact I still use the Playground even when I am now working on my own app, just to quickly try out things that don’t work in my (currently) 550-line (and counting) app.

Note that if you use Vue as a library you end up with none of these problems and quite frankly, to each their own. I personally liked the workflow from the Tutorial (Single File Components and Composition API), so I tried to recreate that.

Pet peeve: people asking Vue questions on Stack Overflow without reducing their code to the minimum required to produce their problem.

Discussion: note that the Vue Playground only uses the Composition API at the time of writing. This is a fairly recent API: if I am not mistaken, it was introduced a little under 3 years ago. If you had tried Vue before or already have some Vue experience, this might not be the way for you.

My 2008 article about digital deterioration of e-books has, in a fit of irony, become unfindable through Google. The reason may be that no-one links to it any more, including the platform on which it was published.

So let me link to it myself:

The printed book as a preservation device

In the article I discuss three dangers that beset digital works:

1. Format deterioration
2. Digital Rights Management (DRM)
3. An adversive position of archivists

I offer no achievable solutions to these problems, but point out that, ironically, because of these dangers a print version of a book offers a greater chance of said book surviving the ages than the digital version does.

Every four years since 2010 I have been writing the ‘state of the CMS’ in which I compare how the major Free and Open Source (FOSS) content-management systems (CMSes) call themselves.

Today’s version will likely be the last of the series.

This is because in the past 12 years the main contenders for the title ‘popular CMS’ were all basically offering the same thing, namely an open source, LAMP-based generic CMS. That made them a natural category. Now that other types of CMS have started to compete in the top ten, it has become much harder to define a category to which these systems belong.

Wordpress is still by far the biggest fish in the pond, but in the past 4 years hosted CMS-es have grown in importance and have grown bigger than what were for a good 10 years Wordpress’ only rivals, Drupal and Joomla. In fact, according to W3Techs (which I won’t link to, because their chart changes weekly or so), the three most popular CMS-es after Wordpress are now Shopify, Wix and Squarespace. And where four years ago Drupal and Joomla were the only CMS-es after Wordpress that had a better than 1% market share — my personal measure of significance here — now between 6 to 10 do, depending on who you ask and how you calculate market share.

It seems, in other words, that the very definition of what a CMS is, is shifting, and that makes it less meaningful to continue this series.

How have these systems called themselves over time and can we glean anything useful from any changes?

Wordpress
2010: Semantic personal publishing platform
2014: Web software you can use to create a beautiful website or blog
2018: Open source software you can use to create a beautiful website, blog, or app
2022: Open source software you can use to create a beautiful website, blog, or app

Drupal
2010: Open source content management system
2014: Open source content management platform
2018: Open source content management system
2022: Digital experience platform (DXP)

Joomla
2010: Dynamic portal engine and content management system
2014: Content management system
2018: Content management system
2022: Content management system

Wix
2022: [undefined]

Squarespace
2022: [undefined]

I have tried to figure out what Wix and Squarespace call themselves, but being commercial entities they are not really calling themselves anything. Instead they present themselves as a bunch of solutions to any number of problems you might have and leave it to the historians to provide them with a label. So Wix opens with “Create a website you’re proud of” and Squarespace with “Everything to sell anything”.

See also: State of the CMS in 2018.

This was a list I made of many of the problems I encountered using the Microsoft operating system Windows 10.

I cannot remember why I started making such a list, but it is a habit. Maybe because other voices have much greater platforms and maintaining these lists protects me a little from the gaslighting.

I built my current PC in 2016 and started maintaining this list shortly after. Since then, Windows 10 has changed a bunch and as a result, this is more of a hodgepodge historical overview than a completely up-to-date compendium of all Windows’ woes.

The main change since the release of Windows 10 was that Microsoft started thinking of it as a service, rather than a product.

There may be a (strategic) legal reason for this: consumer protection laws are typically a lot stronger with regards to products rather than services.

Anyway, Windows 10 sucked, and here is why:

* Tries to let you sign up to a huge number of gross privacy violations upon installation.

* You cannot block it from restarting whenever it damn feels like. (It will let you enter a period of 12 hours in which it will presumably not restart.)

* When you have speedy start turned on, it will forget it’s network settings after a while.

* It forgets application settings (this may have to do with the previous points).

* Apparently from time to time it will reset all file associations to crappy Microsoft software. (I haven’t come across this yet, but while searching for solutions to other crap Microsoft pulls, I came across this one to look forward to.)

* Like most Windowses before it, Windows 10 also hides file extensions by default to make it easier for distributors of viruses and backdoors to let you install their malware.

* Creates a Thumbs.db file whenever you store an image in a directory, regardless whether you want to see thumbs or not. This file cannot be deleted. Some archivers balk when you try and create a ZIP file of such a directory.

* Reinstalls unwanted bundled software.

There was probably a bunch more, but at some point you no longer notice them.

Lately I have been using my 2008 Asus EEE netbook quite a bit and when I noticed this, I decided to look for an upgrade.

I knew that netbooks had been largely supplanted, first by tablets and later by Chromebooks, but what I had not realised is that they have disappeared completely from the market together with their ultraportable brethern.

So what is a netbook? It is a small and lightweight and cheap generic laptop, that is all. They were introduced in the mid-noughties and were then pulled off the market almost as quickly when manufacturers realised how thin the margins on these machines exactly were.

Netbooks sold for as little as 200 euro. Before netbooks were introduced you could already get ultraportable laptops in the 2000 euro price range. There was apparently a market for a laptop of that form factor even at a price ten times that of a netbook.

And I have to say, if I look at how I used my netbook in the past and how I use it now, the size and the weight keep playing a role:

• Watching shows copied off my main PC, while in bed, with the netbook resting on my chest.
• Blogging (including editing photos) while on the road.
• Taking notes from meetings and brainstorms.
• Homework for a creative writing course.
• Doing post-processing for Distributed Proofreaders, i.e. creating e-books.
• Listening to online radio.

(Compare with how I use my tablet.)

I guess a lot of people use smartphones for these things now. I am one of the remaining 5 people on the planet who is not a smartphone person, I realise that makes our group too small to form a market.

Retrospectives on netbooks are typically a hoot-and-a-half, with the authors clickbaitely mocking the devices and claiming nobody ever used them, after which the comments sections come alive with people who loved their netbooks and used them for all kinds of cool things.

The form factor of the netbook was important. Unlike devices like tablets, where large-format devices have carved out their own niche among for example graphic artists, a medium- to large-format netbook makes no sense. That would be the same thing as a laptop but underpowered.

My netbook has a 10 inch screen diagonal which is already on the large side.

Illustration: book sizes to compare to laptop sizes: the left-most book is pocket-sized and fits in a coat pocket. The middle book is the size of my 10-inch Asus EEE netbook and fits in a small backpack or bag. The book on the right is about the size of an 11- or 12-inch laptop and already needs something more substantial to be carried around in.

After I figured out I won’t be able to buy a modern netbook, I have looked into the possibility of upgrading the current one but that is going to require a bunch more thought. Even if I could buy 2012 era tech to replace some of the 2008 era stuff, there is no guarantee everything will work together nicely, and, more importantly, I am not sure I even need the upgrade. More storage would be nice but that is all I currently ‘need’.

In the 2000s I was a volunteer for Distributed Proofreaders, an organisation that produces e-books for Project Gutenberg using a process that breaks up the work in manageable steps.

At the time I was looking into ways of creating a mobile scanning station that I could use to travel to libraries and rare book collections so that I could scan their books on location.

My idea was to create a so-called planetary scanner because in my experience it can be quite easy to damage books on a regular flatbed scanner – typically laying books open on a glass plate is bad for the spine, and when you turn over the book so that you can turn the page, you can easily rip a page.

Most of the parts of a planetary scanner can be bought off the shelf: tripods, cameras, glass plates, lights and so on. I could not find a book cradle however (little did I know that the ones for display purposes are called ‘book stands’) so I set out to make one myself.

Initially I made a cradle out of cardboard. That one functioned just fine, however after scanning a single book the cardboard walls had weakened to the point that they no longer could support a book.

So I made a second book cradle out of thin, soft plywood, and that is the one you can see here.

For the design, see this PDF.

I added a few components, namely a glass plate from a 3-euro picture frame and a printed reference sheet.

The glass plate is for keeping pages more or less flat.

If you keep the rest of the frame’s components, it will help you keep the glass plate undamaged during transport.

The reference sheet is just a print-out of a grid of squares and will help fix a few things beforehand or in post-processing: lens distortion (the lines should be straight), perspective (the squares should all be the same size), and white balance (the sheet should be white).

You might want to try and make the squares an exact size (for example 10 mm), but I never bothered with that, because getting it right is also a function of the printer you use. If you need to know the size of the book cover or the book’s pages, it is probably easier and faster to measure them by hand anyway.

I made the joints quite tight. Since I used fairly soft plywood this makes the cradle quite firm.

At this size, the cradle supports small and medium sized books. If you want to scan larger books, you have to get creative. (For example, you could make something that pushes the wooden sheets outwards.)

Once you are done scanning your book, everything combines into a strong and neat package that can easily be carried in for example a laptop bag.

I won’t go into the actual scanning process, because that could easily take up 3 or 4 more blogposts, but I have some notes from back in the day here.

As you can see (green dashed line added for emphasis), the glass plate can have quite a strong reflection. The angle of the light and the camera will play a role here.

Other people have made DIY book scanners with accompanying cradles, such as Daniel Reetz.

This is the propaganda I watch and listen to on Youtube.

Content warning: all of these channels discuss and often show extreme forms of violence. Not just because they discuss war, but also because almost all Russians are terrorists and criminals or supporters of terrorists and criminals, and because Russia wants to genocide Ukraine into the history books, and the results are particularly ugly.

Pro-Ukrainian propaganda

Tactics and strategy

Perun Gamer turned commentator. Clearly has some sort of academic past and some sort of public speaking past, but he doesn’t want to reveal too much about himself. You will have to judge him strictly on the content.

Anders Puck Nielsen Former officer aboard a Danish patrol boat, he returned to his old school to become a lecturer there. Posts every 10 days or so.

Österreiches bundesheer (in English: Austrian army) Every week or so, among their regular content, a lieutenant-colonel explains how the war is progressing. (Update 2-6-2022: ab heute auch auf englisch.)

Ukrainian voices

UATV English Daily war news, often quoting regional managers.

Operator Starsky A PR officer of a National Guard brigade attached to Kyiv presents all kinds of mostly background information, mostly about the hostilities around Kyiv. He is also popular on English-language Youtube-talkshows.

I stand with Ukraine – Nataliya’s channel Miscellaneous, but I mostly watch this channel for the translations of interviews with Russian prisoners of war by Volodymyr Zolkin. (Update 9 June 2022 – the translated interviews are no longer available, because the original interviewer started monetizing them.)

Insights from Ukraine and Russia Once per day, sometimes once per two days, this channel presents two short translations of intercepted phone calls of Russian soldiers.

Ukraine Leaks Battle videos from body cams and drone cams.

Olga Reznikova A Ukrainian vlogger who got overtaken by the war, fled the country (taking her kids and her parents along), and returned last week.

Armchair generals

The Enforcer Daily live show (long) and daily review of the clips you saw at UATV and Ukraine Leaks.

Animarchy Long-form essays, mostly about the weapons- and soldiers-side of war.

Pro-Russian propaganda

Niki Proshin How the war affects Russia.

1420 Russian vox pops. I am going to quote a little dialog I particularly liked:

Interviewer: “Which mythical creature do you like best?”

Young man: “Centaurs.”

Interviewer: “Don’t you like orcs?”

Young man: “No, I hate them.”

Interviewer: “Why?”

Young man: “They rape and kill and loot washing machines.”

(Explanation: Ukrainians call Russians ‘orcs’. Russian soldiers loot a lot. There have been cases where Ukrainians retrieved stolen washing machines from Russian trenches.)

Pro-American propaganda

Times Radio.

CNN.

BBC.

What is true?

Propaganda does not necessarily mean lying, it may simply mean choosing to highlight what one side finds important – and in fact that is how I have interpreted the term when categorising the Youtube channels above. This is why, for example, I added certain Russian vloggers to the pro-Russian side, even though they appear to be no great fans of the war.

Still, lying is a valid tactic in a war and therefore I assume that most of the time I do not really know what is going on.

I use some heuristics though to determine for myself what I believe is the truth (until proven otherwise):

– Time. I find that after weeks or months, belligerents find it easier to admit that something was the case.

– ‘Innocent’ sources. Russian newspapers for instance will publish biographies of fallen local soldiers. The sum of these biographies tend to be wildly at odds with official mortality figures.

– Comparison. If both sides say X, I tend to believe X is true. This is a tricky one, because each side may have their own reasons to spread the same falsehood. For that reason, I try not to use this heuristic.

– A history of speaking the truth.

In my experience Ukrainians hold back information (they tend to go: “we cannot really determine these things until after the war”), whereas Russians outright lie. I assume the Russians do not believe that we don’t realise they are lying – rather I assume they are trying to sow confusion.

As a result, I tend to believe the Ukrainians. I realise this is also a form of laziness, but so far it has not tripped me up.

I made the following comparison of Wordpress and Drupal terminology for a customer and figured others might find it useful too.

Important: undoubtedly the very existence of this table will create the impression that Wordpress and Drupal are much alike. This is obviously true in some aspects – both are open source CMS-es based on a XAMPP stack for instance – but the underlying philosophies of both systems can vary wildly.

I will try and give a few examples after the jargon comparison.

* Drupal’s templates are more powerful than Wordpress’. Drupal makes almost everything themable, meaning you can make a template for almost everything. This has advantages for child-themes (you only have to define template parts, which are just called templates; Drupal will figure out which one to load) and for modules, which can define templates for their own output, which in turn can be overwritten by themes. Instead of templates you can also use theming hooks.

** ‘Hook’ is programming terminology. Wordpress sub-divides its hooks into actions and filters. Drupal lets you define hooks by prefixing function names with the name of your custom theme or module. E.g. theming hooks are called THEME_preprocess_HOOK and THEME_process_HOOK, where THEME is the machine name of your theme and HOOK is the part of the page you want to alter, e.g. ‘page’, ‘block’, ‘section’ and so on.

*** Drupal’s filters are typically only used to change text before it is being output to the browser. In Drupal 7 and earlier filters were defined using hooks, in later versions using ‘plugins’ (not the Wordpress kind, obviously).

**** Tokens require a third-party module.

Discussion

Where Wordpress is a CMS, Drupal has historically been more of a CMS construction kit – simply installing Drupal was never enough to run a website. Wordpress on the other hand has its famous 5-minute install: you can literally be up-and-running in that litle time – assuming you do not want anything complicated.

Wordpress has a rich ecosystem of large, monolithic plug-ins (often with paid expansions typically called the Pro version) which give you everything but the kitchen sink for any given functionality.

Drupal on the other hand typically has leaner modules that tend to cooperate well with other modules – meaning you can build functionality from combining modules. Since Drupal sites are typically built by professional coders, this way of glueing together small modules works well for the system.

Drupal even has modules that were specifically made to provide an API – although I am not entirely comfortable with the comparison. Wordpress provides such a large ecosystem, that the combination of Wordpress and a popular plugin can be considered a CMS in its own right.

For example if you considered the Wordpress + Elementor combination to be a CMS of its own, it would be more popular than Drupal. The result is that these popular plugins become their own API’s, even if they are very ugly API’s that can be difficult to develop against.

The existence of the table above suggests that the jargon I have compared is closely related, but the different philosophies underlying both systems permeate through each concept. As a result, finding the right terminology tends to be little more than a starting point.