Categorie: Geen categorie

In het verleden heb ik een aantal jaar gebankierd bij Knab. Een prima online bank, maar per januari 2022 ben ik daar van afgestapt. Toch had ik nog een reeks oude exportbestanden liggen met mijn transacties, in het CSV-formaat dat Knab aanbiedt.

Die bestanden hebben de volgende headers:

Rekeningnummer;Transactiedatum;Valutacode;CreditDebet;Bedrag;Tegenrekeningnummer;Tegenrekeninghouder;Valutadatum;Betaalwijze;Omschrijving;Type betaling;Machtigingsnummer;Incassant ID;Adres;Referentie;Boekdatum;

Een paar jaar geleden kwam ik al eens in aanraking met Firefly III, een open source project voor persoonlijke financiën dat me wel interessant leek. Ik ben er nu eindelijk eens aan toegekomen om Firefly III te testen via een Docker-container. Als proef wilde ik mijn oude Knab-transacties importeren via de Firefly III data importer.

• Rekeningnummer
• Transactiedatum
• Valutacode
• CreditDebet
• Bedrag
• Tegenrekeningnummer
• Tegenrekeninghouder
• Valutadatum
• Betaalwijze
• Omschrijving
• Type betaling
• Machtigingsnummer
• Incassant ID
• Adres
• Referentie
• Boekdatum

Geen bestaande importconfiguratie

Firefly III heeft een verzameling importconfiguraties per land: https://github.com/firefly-iii/import-configurations. Daar stond geen configuratie voor Knab tussen, dus ik heb zelf een configuratiebestand gemaakt dat goed werkt met de CSV-export van Knab.

Mijn Knab-importconfiguratie

Hieronder de configuratie die ik gebruik in de Firefly III CSV-importer (versie 1.8.2):

{
    "version": 3,
    "source": "ff3-importer-1.8.2",
    "created_at": "2025-10-10T14:05:19+02:00",
    "date": "d-m-Y",
    "default_account": 0,
    "delimiter": "semicolon",
    "headers": true,
    "rules": true,
    "skip_form": false,
    "add_import_tag": true,
    "roles": [
        "account-number",
        "date_transaction",
        "currency-code",
        "generic-debit-credit",
        "amount",
        "opposing-number",
        "opposing-name",
        "date_interest",
        "note",
        "description",
        "note",
        "sepa_db",
        "sepa_ci",
        "note",
        "external-id",
        "date_book"
    ],
    "do_mapping": [
        false,
        false,
        false,
        false,
        false,
        true,
        true,
        false,
        false,
        false,
        false,
        false,
        false,
        false,
        false,
        false
    ],
    "mapping": {},
    "duplicate_detection_method": "cell",
    "ignore_duplicate_lines": true,
    "unique_column_index": 14,
    "unique_column_type": "external-id",
    "flow": "file",
    "content_type": "csv",
    "custom_tag": "",
    "identifier": "0",
    "connection": "0",
    "ignore_spectre_categories": false,
    "grouped_transaction_handling": "",
    "use_entire_opposing_address": false,
    "map_all_data": false,
    "pending_transactions": false,
    "access_token": "",
    "accounts": {},
    "new_account": [],
    "date_range": "",
    "date_range_number": 30,
    "date_range_unit": "d",
    "date_range_not_after_unit": "",
    "date_range_not_after_number": 0,
    "date_not_before": "",
    "date_not_after": "",
    "nordigen_country": "",
    "nordigen_bank": "",
    "nordigen_requisitions": {},
    "nordigen_max_days": "90",
    "conversion": false,
    "ignore_duplicate_transactions": false
}

Belangrijke keuzes in deze configuratie

• Scheidingsteken: semicolon, omdat Knab puntkomma’s gebruikt in CSV-exporten.
• Datumformaat: d-m-Y, hetzelfde als in de Knab-bestanden.
• Referentie is gemapt als external-id, zodat Firefly dubbele transacties kan herkennen en voorkomen.
• Mapping is alleen aan bij tegenrekeningvelden (Tegenrekeningnummer en Tegenrekeninghouder), zodat vaste tegenpartijen automatisch worden herkend.

Dubbele transacties voorkomen

Toen ik een CSV van een Knab-spaarrekening importeerde, merkte ik dat Firefly overschrijvingen dubbel toevoegde. Door het veld Referentie te gebruiken als unieke external ID (unique_column_index: 14) worden zulke duplicaten netjes overgeslagen.

Conclusie

Met deze configuratie lukt het om oude Knab-exportbestanden goed in Firefly III te importeren. Misschien dat ik de configuratie nog toevoeg aan de officiële Firefly III import-configuraties op GitHub, zodat anderen er ook gebruik van kunnen maken. Voor nu was het vooral een leuke manier om Firefly III eens rustig te verkennen.

Update 12 oktober 2025

Inmiddels de Knab import configuratie toegevoegd aan het Firefly III imort configuraties project:

https://github.com/firefly-iii/import-configurations/blob/b6b60fcc6b05d53a5c6608fff51f5e54247de57f/nl/knab/knab.json

Soms staat een videobestand ondersteboven en moet het gedraaid worden. Natuurlijk is dit in een videobewerkingsprogramma op te lossen, maar als programmeur kan ik een snel terminalcommando ook wel waarderen. Met FFmpeg, een veelzijdige tool voor video en audio, kan dit eenvoudig worden gedaan:

ffmpeg -i video.mp4 -c copy -metadata:s:v:0 rotate=180 video-rotated.mp4

Toelichting:

• -i video.mp4 geeft het bronbestand aan.
• -c copy kopieert video en audio zonder opnieuw te coderen, waardoor de kwaliteit behouden blijft en de verwerking snel gaat.
• -metadata:s:v:0 rotate=180 draait de video 180 graden.
• video-rotated.mp4 is het resultaatbestand.

Op deze manier kan een videobestand eenvoudig en efficiënt worden gedraaid, zonder dat er grafische videobewerkingssoftware nodig is.

Als trouwe gebruiker van Google Authenticator heb ik gemerkt dat de app, naarmate ik meer codes toevoeg voor verschillende diensten, steeds minder handig wordt. Het vinden van de juiste code wordt een steeds grotere uitdaging. Daarom ben ik gaan onderzoeken of er alternatieve apps zijn die misschien handiger zijn in gebruik.

Een vraag die bij me opkwam was: hoe kan ik mijn bestaande codes uit Google Authenticator halen? Gelukkig heeft Google in mei 2020 een functie geïntroduceerd waarmee het overzetten van codes naar een ander apparaat mogelijk is. Voor deze overdracht genereert de Google Authenticator app een QR-code (of meerdere) waarin meerdere authenticator-codes zijn gecodeerd. Met een andere Google Authenticator app is het mogelijk om deze QR-code te scannen en zo de codes over te zetten.

Na een korte zoektocht stuitte ik op de volgende bibliotheek op GitHub: dim13/otpauth. Deze bibliotheek is in staat om de gegevens van de QR-code voor het overzetten van Google Authenticator uit te lezen. Met behulp van de volgende stappen kunnen de authenticator-codes van Google Authenticator geëxporteerd worden:

1. Maak een schermafbeelding van de Google Authenticator overzetten QR-code.
2. Scan de schermafbeelding met de QR-code scanner functionaliteit van je telefoon.
   • Dit kan eventueel ook via CLI op je computer met bijvoorbeeld de mchehab/zbar-bibliotheek: zbarimg qrcode.jpeg.
3. Kopieer de volledig tekst uit de QR-code.
   • Deze tekst begint met otpauth-migration://offline?data=….
4. Gebruik de https://github.com/dim13/otpauth tool via het volgende commando:
   ~/go/bin/otpauth -link "~/go/bin/otpauth -link "otpauth-migration://offline?data=…"

De bibliotheek is ook in staat om nieuwe authenticator-QR-codes te genereren via de -qr-parameter. Deze zijn vervolgens weer te scannen met een andere authenticator app.

Inmiddels ben ik al ruim 20 jaar bezig met het ontwikkelen van websites en webapplicaties. Daarmee heb ik ook wel wat ervaring opgedaan in het maken van ureninschattingen. Toch blijkt het nog wel eens lastig om een juiste ureninschatting te maken. Zo maakte een collega recent de inschatting dat iets 5 à 6 uren aan tijd zou kosten om te ontwikkelen. Uiteindelijk bleken er heel wat meer uren nodig te zijn om het gewenste resultaat te ontwikkelen. De opdrachtgever vroeg zich natuurlijk af hoe dit kwam. Bepaalde onderdelen bleken aanzienlijk lastiger dan vooraf voorzien. Kort hierna kwam ik ook het volgende bericht tegen op X:

The work is never just “the work”. The actual “work” you have to do, is just a very small part of a whole invisible set of a project. There’s the world around the work, to get the work, before the work, between the work, beyond the work, outside the work, etc. pic.twitter.com/LTr4WLmpLW

— Stef Walter (@WalterStephanie) March 12, 2024

Webontwikkelaar Dave Stewart heeft hier een interessant artikel over geschreven: “The work is never just “the work”“. De volgende afbeelding geeft aan hoe het in de praktijk kan gaan:

Afgelopen maandag schreef ik in het bericht “Kunstmatige intelligentie (AI) inzetten voor generen foto’s” nog over ‘character consistency’ bij het generen van van afbeeldingen met AI. Gisteren ging het op X los over de nieuwe ‘karakterconsistentie’ functionaliteit binnen Midjourney. Via de parameter --cref gevolgd door een link (URL) naar een afbeelding van een karakter/persoon kan Midjourney deze karakter/persoon verwerken in de te genereren afbeeldingen. De --cref staat in dit geval voor ‘Character Reference’. Vergelijkbaar met de --sref parameter die staat voor ‘Style Reference’.

🚨 Breaking!

Midjourney just dropped the 'Character Consistency'.

First look and more 👇 pic.twitter.com/Moa3PfSG9H

— Dogan Ural (@doganuraldesign) March 11, 2024

🚨#BreakingNews🚨
And there we have it, Character Reference is finally available on #Midjourney!

Here's a first video of my initial tests.

The UX on the alpha version site is really cool. Check it out and share your thoughts!

How it works on Discords
• Type –cref URL after… pic.twitter.com/k4fj8yKrF7

— Pierrick Chevallier | IA (@CharaspowerAI) March 12, 2024

Midjourney just dropped a new "Character Consistency" feature!

And people are already creating insane images.

Here are 12 mind blowing examples (and how to get started): 👇 pic.twitter.com/jmTeO9whzW

— Sai Rahul (@sairahul1) March 12, 2024

Midjourney's new character consistency feature changed the whole game.

I mean, look at this 😮‍💨🤌

Testing some very interesting prompts and workflows, that I'll share later today pic.twitter.com/U0J9Fc16tF

— Halim Alrasihi (@HalimAlrasihi) March 12, 2024

🎉Midjourney just dropped Character Reference!!🎉

This feature is like the "Style Reference" tool but focuses on matching a character to an image instead of a style.

Here's how it works:

1⃣ Type –cref followed by a URL to a character image after your prompt.
2⃣ Use –cw to… pic.twitter.com/zTavif5pR3

— Everett World (@WorldEverett) March 11, 2024

Begin dit jaar kreeg ik de vraag van een klant of kunstmatig intelligentie (AI) ook ingezet kan worden voor het genereren van foto’s van een persoon in een bepaalde situatie in de branch waarin deze klant actief is. Voor marketingdoeleinden kan dat wel handig zijn om bepaalde situaties voor je (potentiële) klanten duidelijker te maken.

Nou volg ik via X wel een beetje de ontwikkelingen op het gebied van kunstmatige intelligentie en zie zo regelmatig leuke voorbeelden DALL·E (van de makers van ChatGPT → OpenAI), Midjourney en Adobe Firefly voorbij komen op mijn tijdlijn.

Zo ben ik zelf ook wat aan testen gegaan met deze tool, maar de resultaten vielen mijn persoonlijk nog een beetje tegen. Het was vaak wel duidelijk te zijn dat de foto’s gegenereerd waren en er zaten vaak wel wat onjuistheden in deze foto’s. Daarnaast bleek het lastig om telkens dezelfde persoon in de foto’s te krijgen. Een paar weken later zag ik een bericht van Chase Lean op X waarin hij dit ook aankaart:

Character consistency is a big problem when making AI images.

I’ve been testing a new way to solve character consistency, and it’s by far the best method I’ve tried so far.

Let me show you how: pic.twitter.com/r5gR46HtFN

— Chase Lean (@chaseleantj) January 27, 2024

Hij geeft aan dat hij met Scenario wel goede resultaten heeft kunnen bereiken. De tool richt zich voornamelijk op het generen van afbeeldingen voor games, daardoor is de style misschien niet altijd heel realistisch. Maar voor bepaalde doeleinden kan Scenario zeker wel leuke afbeeldingen generen in een consistente stijl. Voor marketing en het opvullen van een webpagina kan dit zeker van pas komen.

Craft unique and style-consistent game assets with custom-trained AI models.

Scenario

Nog weer later kwam ik het volgende bericht tegen:

👩‍🚒 With this new workflow, you'll nail character consistency and pose control super quickly and efficiently with Rendernet AI!

🔥 Wanna give it a shot?

I'll break it down for you in 5⃣ easy steps (prompts included) 👇#QuickGuide #AIArtCommunity pic.twitter.com/GWQbnS01m0

— TechHalla (@techhalla) February 14, 2024

Hier noemen ze de diensten van https://rendernet.ai/ en https://remix.ai/. Op de website van RenderNet noemen ze een techniek genaamd FaceLock:

Consistent characters… always!

Upload a photo of a person and create realistic AI characters with the same face.

RenderNet

Spelenderwijs zijn er zo heel veel tools beschikbaar en ontwikkelingen op dit gebied lijken razendsnel te gaan. Voor situaties waarbij het belangrijk is dat dezelfde persoon op de foto’s komt te staan is het handig om tools te zoeken die zich ook richten ‘character consistency’.

https://roadmap.sh/

Bij Pronamic hebben we als richtlijn dat we alles strict in het Engels programmeren. Stagiairs leren we daarom ook altijd om in het Engels te programmeren. Toch zijn er op internet ook vele voorbeelden te vinden waarin Nederlandse naamgeving wordt gebruikt in de code. Waarom heeft Engels dan bij ons de voorkeur? Ik ben voor de aardigheid eens op zoek gegaan naar goede argumenten. Al snel kwam ik een artikel tegen uit het boek “Het beste van PHP en MySQL“.

Engels of Nederlands

Amerikaans Engels is de voertaal onder programmeurs. Ook de meeste PHP-ontwikkelaars gebruiken Engels. Als je echter PHP-script alleen voor jezelf schrijft of als je in een team met alleen Hollanders en Vlamingen werkt, zijn er goede redenen om Nederlands te gebruiken.

Wanneer je Nederlands gebruikt voor alle namen die je zelf kunt kiezen, wordt broncode beter leesbaar. Het verschillen tussen Engelstalige termen uit PHP en zelfgekozen namen in dan direct zichtbaar. Dat is de reden waarom ik in dit boek vaker Nederlands gebruik dan Engels: het maakt de voorbeelden veel duidelijker als PHP nieuw voor je is.

De kans op naamconflicten neemt drastisch af als je Nederlands gebruikt. Als je Engels gebruikt voor bijvoorbeeld een functie die je zelf definieert, bestaat altijd het risico dat je per ongeluk een bestaande PHP-functie gebruikt. Naamconflicten kunnen ook voorkomen met andere talen die je in PHP gebruikt: HTML, CSS, SQL, HTPT, MIME, XML enzovoort gebruiken allemaal Engels.

Natuurlijk moet je niet overdreven vasthouden aan het Nederlands. Hoewel databank en gegevensbank foutloos Nederlands zijn, zeggen en schrijven ontwikkelaars altijd database. Het Nederlands kent al helemaal geen bruikbaar synoniem van query. In zulke gevallen kun je naamconflicten voorkomen door verschillende woorden of een samenstelling met Nederlands te gebruiken. Maak dan van $database en $query bijvoorbeeld $database_met_producten en $selectiequery.

Ward van der Put

In een boek zoals deze is het denk ik ook prima om Nederlandse code voorbeelden te gebruiken. Lezers kunnen op die manier waarschijnlijk sneller zaken herkennen. Het argument om Nederlands te gebruiken om naamconflicten te voorkomen vind ik wat minder sterk. Voor dat probleem zijn er in PHP denk ik namespaces geïntroduceerd.

Al met al nog niet hele sterke argumenten om wel of niet in het Engels of Nederlands te programmeren. Ik ben daarom verder gaan zoeken en kwam o.a. de volgende vragen / topics tegen:

• Software Engineering Stack Exchange: “Do people in non-English-speaking countries code in English?”
• Quora: “Is it better learning programming in English or in my native language (Portuguese)?”
• DEV Community: “Do you feel comfortable learning in your own language or do you prefer English? (For non English-native speakers)”

Velen geven aan dat Engels de voorkeur heeft, maar om programmeren te leren je moedertaal wel fijn kan zijn.

DomQ (een Fransman) noemde nog wel de volgende aandachtspunten:

• I speak the language that the target audience will most likely understand. When coding open-source software with a global ambition, I use English. For less widely useful stuff (for instance, my Emacs configuration file), I might use French.

• I acknowledge the fact that not everyone will master English. In that perspective, using my mother tongue might actually make my code more accessible instead of less (in the example above, nobody cares about an umpteenth .emacs, except if it happens to be written in a language that they understand).

• Better to write good French than bad English. I actively discourage my subordinates from writing half-assed English especially where concision matters, eg in docstrings and version control commit messages.

https://softwareengineering.stackexchange.com/a/1764

Mattias Kihlström (een Zweed) noemde volgende argumenten om Engels te gebruiken:

• Allmost all programming languages I have ever used have been written in English (mixing languages would make the code harder to read for me)

• Most popular frameworks and third party extension are written in English (again, mixing languages would only be a distraction)

• Swedish characters (åäö) are usually not allowed when naming variables and functions

• If the other team members are from different countries we can still collaborate

• If I need support from a platform vendor it is is much easier for them to help me if they can understand my code

• It is easier to outsource support

https://softwareengineering.stackexchange.com/a/1687

Ik sluit me persoonlijk aan bij de argumenten van Mattias, dat zijn denk ik ook de redenen waarom we bij Pronamic in het Engels programmeren.

Mocht je zelf ook nog goede redenen hebben om in het Engels of juist in het Nederlands te programmeren dan hoor ik ze graag. Laat daarom gerust een reactie achter.