Wikimedia Enterprise: A first look

Wikimedia Enterprise is a new (now 1-year-old) service and offered by the Wikimedia Foundation, via Wikimedia, LLC.

This is a wholly-owned LLC that provides opt-in services for third-party content reuse, delivered via API services.

In essence, this means that Wikimedia Enterprise is an optional product that third parties can choose to use that repackages data from within Wikimedia projects in a more useful, more reliable, and stable format presenting them primarily via data downloads and APIs, with profits going into the Wikimedia Foundation.

Want to find out more? Read the FAQ.

The project and APIs are well documented, and access can be requested for free, but I wanted to spend a little bit of time hands-on with the APIs to get a full understanding of what is offered, the formats, and how it differs from things I know are exposed elsewhere in Wikimedia projects.

Account Creation

Wikimedia Enterprise accounts are separate from any other Wikimedia related accounts, so you’ll need a new one.

In order to get an account you need to fill out a pretty straightforward form (username, password, email, and accept terms). You then need to verify your email address. Tada, you are in!

Read more

Jetbrains Fleet & WSL: First impressions

It’s no secret that I develop using Windows and WSL. For the past few years, I have also primarily used VSCode as my go-to development environment.

Between 2012 and 2018 I mainly used Jetbrains IntellijJ IDEA, but I found the speed of VSCode (launched in 2015), along with the modern design and vibrate plugin ecosystem, to win me over.

Every now and again I have found myself dipping back into the suite of Jetbrains IDEs, primarily for their high-quality code refactoring tools, nothing that I have seen in the VSCode ecosystem has quite lived up to this functionality.

Jetbrains Fleet was announced in 2021, and was behind a waitlist until this past week. It’s now in public preview!

This is exciting, as it’s advertised as “lightweight” with code processing engines running separately, similar to what is done in VSCode. But also contains their “20 years of experience developing IDEs”, which I hope will maintain the high-quality refactoring tools. Not to mention built-in “distributed” working modes for remote development, thus built-in WSL project integration.

So here is a very first look at using Fleet with a project in WSL2 land.

Read more

Global “unlimited” data options: Wraptel, Keepgo & Solis

Ahead of this year of sailing, I wanted to ensure I had as many high quality connectivity options as possible. As already mentioned I bought a Digital yacht WL510 and 4G Connect, the latter of which needs sim cards in order to connect.

Sim card slot inside the 4G Connect

The world seems to be half way between using physical sim cards, and ESIMS, and the digital yachting world hasn’t quite caught up with this trend just yet. So I wanted to find the best, hopfully mostly unlimited, mostly worldwide, sim card options to put in the 4G Connect.

All options that I managed to find had some sort capping system before data would slow down. Some even had an actual data cap despite advertising themselves as “unlimited”.

Below you can find a comparison of the options I tried.

Read more

A first Wikidata query service JNL file for public use

This entry is part 2 of 3 in the series Your own Wikidata Query Service

Back in 2019 I wrote a blog post called Your own Wikidata Query Service, with no limits which documented loading a Wikidata TTL dump into your own Blazegraph instance running within Google cloud, a near 2 week process.

I ended that post speculating that part 2 might be using a “pre-generated Blazegraph journal file to deploy a fully loaded Wikidata query service in a matter of minutes”. This post should take us a step close to that eventuality.

Wikidata Production

There are many production Wikidata query service instances all up to date with Wikidata and all of which are powered using open source code that anyone can use, making use of Blazegraph.

Per wikitech documentation there are currently at least 17 Wikidata query service backends:

  • public cluster, eqiad: wdqs1004, wdqs1005, wdqs1006, wdqs1007, wdqs1012, wdqs1013
  • public cluster, codfw: wdqs2001, wdqs2002, wdqs2003, wdqs2004, wdqs2007
  • internal cluster, eqiad: wdqs1003, wdqs1008, wdqs1011
  • internal cluster, codfw: wdqs2005, wdqs2006, wdqs2008

These servers all have hardware specs that look something like Dual Intel(R) Xeon(R) CPU E5-2620 v3 CPUs, 1.6TB raw raided space SSD, 128GB RAM.

When you run a query it may end up in any one of the backends powering the public clusters.

All of these servers also then have an up-to-date JNL file full of Wikidata data that anyone wanting to set up their own blazegraph instance with Wikidata data could use. This is currently 1.1TB.

So let’s try and get that out of the cluster for folks to use, rather than having people rebuild their own JNL files.

Read more