Ga door naar de hoofdinhoud

Working around a Pop!_OS networking issue

Update (2021-11-26):

The solution I describe in the original post, did work for a while, and then stopped working. Then I got it working again by removing the kernel modules iwlmvm and iwlwifi, and modprobing iwlwifi again. Worked for a day, and stopped working again. So I guess it just sometimes worked, and sometimes, it didn't.

the TP-Link TL-WR1043ND v2

I think it was just the router. It's a TP-LINK TL-WR1043ND v2, and I installed OpenWrt on it (v19.something), a couple of years ago. Now I upgraded it to v 20.02.1, and I think - hope - that that will finally have solved the problem. I was a little reluctant to flash a firmware update, but it turned out to be very easy. The page for my device on the openWRT wiki had a direct link to the 'upgrade firmware', which I could easily flash using the openWRT web interface (using another device than my laptop, of course).

Lees verder…

Migrating a web app from VueJS to Symfony UX: retrospective

The last couple of weeks, I have been refactoring the frontend of dikdikdik, one of my pet projects, that we use to track the scores when we play the card game 'wiezen'.

twig and class for DelaerSelectComponent

The release of version 3.0, in which I threw out VueJS in favour of Symfony Turbo and Symfony Live Components was announced yesterday, and in this blog post I look back on the refactoring, making some kind of roundup on what I like and dislike about the new frontend I created with those new symfony-ux tools.

Lees verder…

Trying out Symfony Twig Components

Last summer, I attended SymfonyWorld Online 2021 Summer Edition, and I was fascinated by Ryan Weavers talk about Symfony Twig Components.

As the README says on the github project page

Twig components give you the power to bind an object to a template, making it easier to render and re-use small template "units" - like an "alert", markup for a modal, or a category sidebar.

I found the presentation very promising, and I wanted to try using twig components in combination with stimulus for the frontend of dikdikdik, a hobby webapp I maintain, to keep track of the score for the wiezen card game.

Lees verder…

Updating your Symfony app from Mercure 0.10 to Mercure 0.11

Last wednesday I updated dikdikdik, a score sheet app for solo whist, so that it now uses Mercure v0.11, instead of v0.10. I use docker-compose for the development environment of dikdikdik, and GitLab CI/CD to run the end-to-end tests with codeception and selenium.

Mercure v0.11

This was not a trivial update, because v0.11 was a major milestone for the Mercure project. In retrospect, I didn't have to change much, but it took me some time to find out what exactly I had to change, especially to make the end-to-end tests running again.

Lees verder…

Iemand zin om mijn code te reviewen?

Laat ons het hebben over code review. Waarschijnlijk bestaan er verschillende definities van 'code review', ik zal eerst even verduidelijken wat ik met code review bedoel.

In grote lijnen: alvorens er aanpassingen gebeuren aan de broncode van je software, is het de bedoeling dat één van je collega's er eens naar gekeken heeft. Zodat die collega vragen kan stellen, of opmerkingen kan maken.

speelkaart en broncode

Lees verder…

PHP event sourcing aan de kaarttafel

Vandaag ga ik eens wat dieper in op de inner workings van WDEBELEK, de webtoepassing die ik schreef om online te kaarten (wiezen en gelijkaardige spelletjes).

Want het is niet alleen erg fijn dat we in tijden van quarantaine en avondklok nog kunnen kaarten, het is ook bijzonder cool dat de achterliggende software gebruik maakt van event sourcing; dat is toch alleszins wat ik probeer.

Mijn bedoeling is om jullie in al dit moois in te leiden aan de hand van de wijzigingen in de code die nodig waren voor een nieuwe feature die ik onlangs inbouwde: het opnieuw open leggen van een slag die eigenlijk al opgeraapt was.

playing cards

Lees verder…

Wiezen in quarantaine met WDEBELEK

Nu het aantal dagelijkse nieuwe COVID-19-besmettingen een aantal dagen op rij toeneemt, en er in de media al gesproken wordt over mogelijke plaatselijke lockdowns, vergroot ook de kans op kaartavonden die geannuleerd worden wegens coronagevaar.

Maar in tegenstelling tot de vorige lockdown, is er nu wel een makkelijke oplossing om te wiezen vanuit uw kot (en hiermee bedoel ik dan traditioneel wiezen, want voor kleurenwiezen bestonden er al langer oplossingen). Want ik werk aan een webtoepassing om online te kaarten: WDEBELEK, in de volksmond ook wel eens ‘de wiezen-app’. (En als ik dat zo vermeld, wordt ze misschien makkelijker gevonden door Google en consoorten ;-))

De toepassing staat nog in zijn kinderschoenen, en er zijn nog heel wat losse eindjes, maar ze is wel al uitgebreid getest, en bruikbaar gebleken. Hoe gaat het in z'n werk:

  1. Vind 3 tot 5 vrienden die samen met jou willen wiezen.
  2. Start een video-conference met die vrienden; gebruik je favoriete video-conferencing tool. (Bijv. praatbox.be, maar uiteraard is eender welke tool geschikt.)
  3. Maak een kaarttafel aan op kaart.rijkvanafdronk.be.
  4. Maak uitnodigingen voor je vrienden, en bezorg hen de links.
  5. Kaarten maar!

Het is aangewezen om er de handleiding een keertje op na te slaan, maar in principe zou het allemaal vrij intuitief moeten zijn.

De broncode van de toepassing is vrij beschikbaar onder de voorwaarden van de AGPL v3 of later. En je kunt ze gratis gebruiken. Dat is: zo lang mijn server dat kan trekken, uiteraard.

Veel kaartplezier!

kaarten in quarantaine

Selenium web tests on gitlab-ci for an app using Mercure

I recently learned how to use Mercure so that the php/Symfony back-end of my application can send out events that can be picked up by the javascript on my front end. This is really cool technology, you should definitely try this out if you haven't already done so.

Now if you write this kind of software, of course you also want to write some web tests, so that you can automatically check if existing features of your program keep working after you add new things.

gitlab-ci, codeception and mercure

For these kind of tests, I use gitlab-ci and codeception, as I wrote in previous posts. Today I got these test working with a Mercure hub.

You need to use a mercure service in the job running your web tests, which you can configure in .gitlab-ci.yml:

Update 2020-12-03: I use the 0.10 version of the mercure container, because the acceptance test job started failing with 0.11, with these error messages:

Message: "Couldn't connect to server for "http://mercure:3000/.well-known/mercure"." In HandleMessageMiddleware.php line 80:

Couldn't connect to server for "http://mercure:3000/.well-known/mercure".)

So here's the adapted .gitlab-ci.yml-file:

variables:
  JWT_KEY: YourSecretKey
  DEMO: 1
  ALLOW_ANONYMOUS: 1
  HEARTBEAT_INTERVAL: 30s
  ADDR: ':3000'
  CORS_ALLOWED_ORIGINS: '*'
  PUBLISH_ALLOWED_ORIGINS: '*'

# ...

acceptance tests:
  # I would prefer to use a public php-7.3 image with mysqli, but
  # I don't think such a thing exists.
  # So let's reuse the image I created for the dikdikdik web tests.
  image: registry.gitlab.com/rva-vzw/dikdikdik.php
  services:
    - name: mariadb:10.4
      alias: db
    - name: selenium/standalone-chrome
      alias: chrome
    - name: dunglas/mercure
      alias: mercure:v0.10
  # (the rest of the job follows here)

The JWT_KEY should work with the JWT your backend uses to publish events. The port number in ADDR as well. If you use Symfony, as I do, the corresponding configuration of your backend should be in the .env file, e.g.

MERCURE_PUBLISH_URL=http://mercure:3000/.well-known/mercure
MERCURE_JWT_TOKEN=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJtZXJjdXJlIjp7InB1Ymxpc2giOltdfX0.FFSjymJCGRDWrmAmPJDoVGuYwnx5FRTjRFkkYfvLkUg

(Needless to say: don't use the production JWT and token in the source code that is used by gitlab! If you're unsure how to create a JWT, see the section ‘Creating your JWT’ of this excellent blog post.)

Update 2020-12-03: That blog post doesn't exist anymore, but I found another page that covers mercure and the JWT token.

Now the problem I ran into, is similar to the general problem I had with web tests: the chrome container doesn't know where the mercure hub is; the host name ‘mercure’ is not resolved to an ip address.

To fix this, I figure out the IP address of the Mercure hub when I start the job, and I replace the host name of the MERCURE_PUBLISH_URL in the .env file by this IP-address. This works, since my frontend retrieves the publish url from the backend by a rest-call.

This is how that looks like:

  script:
    - MERCURE_IP=$(getent hosts mercure | awk '{ print $1 }')
    - echo Mercure IP $MERCURE_IP
    - sed -i "s/mercure:3000/$MERCURE_IP:3000/" .env

You can review the complete job definition in the .gitlab-ci.yml file in the wdebelek repository. The file acceptance/TrickCest.php contains an example test involving server sent events. And hopefully you can see in the pipelines that all tests passed without problems 🤓.