Blog

Toen we Monica begonnen te herbouwen, wist ik dat relaties een van de onderdelen zouden zijn die we opnieuw moesten doordenken. Wat ik niet had verwacht, was hoe moeilijk het zou zijn om überhaupt te definiëren wat een relatie is.

Een persoonlijke CRM moet weten hoe mensen met elkaar verbonden zijn. Iemand is je moeder, je broer, je vriend, je collega of je partner. Monica ondersteunt dat al jaren, en vanuit het perspectief van de gebruiker is het een vrij eenvoudige functie: je kiest een persoon, je kiest een relatie en je bent klaar.

Helaas is het ontwerpen van wat er achter dat kleine keuzemenu gebeurt helemaal niet eenvoudig.

Zelfs eenvoudige relaties zijn niet zo eenvoudig

Stel dat Monica de zus van Ross is. Vanuit het perspectief van Monica is Ross haar broer. Beide uitspraken beschrijven dezelfde relatie, maar de woorden die we gebruiken hangen af van naar welke persoon we kijken.

Datzelfde gebeurt overal in een familie. Rachel is de moeder van Emma, terwijl Emma de dochter van Rachel is. Iemands tante heeft een nicht of een neef. Een grootmoeder heeft een kleindochter of een kleinzoon.

Andere relaties werken niet zo. Chandler en Joey zijn vrienden. Het woord is hetzelfde, van welke kant je ook kijkt. Bij neven, nichten en collega's kan het net zo werken.

We hebben dus al verschillend gedrag. Soms verandert een relatie van naam afhankelijk van de kant waarvan we kijken, soms niet, en soms hangt het woord dat we gebruiken af van het geslacht van een van de twee mensen.

En dit is het makkelijke deel.

Families zijn rommelig

Stel je voor dat twee mensen trouwen en twee kinderen krijgen. Ze scheiden. Een van hen hertrouwt met iemand die al kinderen heeft uit een andere relatie, en misschien krijgen ze samen nog een kind.

Dat is geen bijzonder ongewone familie, maar we hebben nu ouders, kinderen, broers en zussen, halfbroers en halfzussen, stiefkinderen, stiefouders, partners en ex-partners.

Het roept ook vragen op waar volgens mij niet altijd een universeel antwoord op bestaat. Als je scheidt, houdt je schoonmoeder dan op je schoonmoeder te zijn? Formeel misschien. Maar wat als je haar al twintig jaar kent en haar nog altijd als familie beschouwt? Ze houdt in elk geval niet op de grootmoeder van je kinderen te zijn omdat jouw huwelijk voorbij is.

Dan zijn er nog biologische ouders, adoptieouders, pleegouders en voogden. Iemand kan meerdere mensen hebben die hij als ouders beschouwt, en die relaties betekenen niet noodzakelijk hetzelfde. Er zijn familieleden met wie het contact verbroken is, mensen die iemand als broer of zus zien zonder enige biologische band, ex-partners die heel dicht bij elkaar blijven, en ouders die samen kinderen opvoeden zonder nog een koppel te zijn.

De nette stamboom die we ons bij dit probleem graag voorstellen, overleeft het contact met veel echte families niet.

En zelfs wanneer de familiestructuur zelf eenvoudig is, veranderen relaties. Wie vandaag je partner is, kan over vijf jaar je ex-partner zijn. Dat betekent niet dat de oude relatie eenvoudigweg moet verdwijnen. Dat twee mensen vijftien jaar getrouwd waren, blijft deel van hun geschiedenis, ook als ze dat niet langer zijn.

Relaties hebben een verleden, waardoor alleen hun huidige toestand weergeven ook problematisch is.

Twee mensen zijn het niet altijd eens over hun relatie

Familierelaties geven ons tenminste een paar feiten om mee te werken. Vriendschap is nog minder precies.

Als Monica Rachel als een goede vriendin beschouwt, beschouwt Rachel Monica dan noodzakelijk als een goede vriendin? We hebben geen idee.

Hetzelfde probleem bestaat bij mentoren, kennissen en tal van andere relaties. Iemand kan een ander als zijn mentor zien, ook als die persoon dat woord zelf nooit zou gebruiken. Iemand kan een oude vriend praktisch als familie zien, terwijl de ander in hem iemand ziet die hij jaren geleden kende.

Dat is heel belangrijk in Monica, omdat de informatie niet bedoeld is om een objectieve sociale graaf te beschrijven. Het is jouw informatie over de mensen in jouw leven.

Wanneer je opschrijft dat iemand je vriend is, beschrijf je de relatie zoals jij die begrijpt. Monica heeft de versie van de andere persoon niet, en in veel gevallen is er waarschijnlijk toch geen enkel juist antwoord.

Het wordt bijzonder vreemd wanneer software relaties in iets meetbaars probeert te veranderen. Is iemand een betere vriend omdat je hem elke week ziet? Is een vriendin die je vijf jaar niet hebt gezien minder belangrijk dan een collega met wie je elke dag praat? Natuurlijk zegt frequentie ons iets over een relatie, maar het zegt ons niet wat die relatie voor iemand betekent.

De tijd past er ook niet netjes in

Een collega kan een vriend worden. Een vriend kan een partner worden. Een partner kan een ex-partner worden, en jaren later kan diezelfde persoon opnieuw een vriend worden.

Als Monica vastlegt dat twee mensen getrouwd zijn en ze later scheiden, wat moet er dan met het huwelijk gebeuren? Het verwijderen zou de huidige informatie correct maken, maar zou ook iets vrij belangrijks uit hun geschiedenis wissen.

We zouden datums kunnen bewaren, behalve dat mensen die vaak niet kennen. Ik kan weten dat twee vrienden vroeger samen waren zonder enig idee te hebben wanneer ze zijn begonnen of wanneer ze precies uit elkaar zijn gegaan. Exacte datums verplichten zou het model netter maken en het product aanzienlijk irritanter.

Er is ook geen garantie dat relaties netjes van de ene toestand in de andere overgaan. Mensen worden niet noodzakelijk op een ochtend wakker en gaan van "vriend" naar "partner". Sommige relaties hebben een duidelijk begin, zoals een huwelijk. Veel andere niet.

De database zou heel graag willen dat we weten wanneer alles begon en eindigde. Meestal weten we dat niet.

Het Engels is niet het model voor de hele wereld

Een ander probleem is dat de meeste voorbeelden die als eerste in je opkomen op het Engels gebaseerd zijn.

Het Engels gebruikt "cousin" voor een groot aantal familierelaties, terwijl andere talen veel preciezer kunnen zijn. Het Mandarijn heeft bijvoorbeeld verschillende woorden voor neven en nichten, afhankelijk van welke kant van de familie ze komen, hun geslacht en soms hun leeftijd. Het Zweeds onderscheidt alle vier de grootouders: mormor is de moeder van je moeder, morfar de vader van je moeder, farmor de moeder van je vader en farfar de vader van je vader. Het Engels geeft ons simpelweg "grandmother" en "grandfather".

Het Koreaans levert nog een voorbeeld. Zelfs iets zo eenvoudigs als "oudere broer" verandert afhankelijk van wie er spreekt. Een man noemt zijn oudere broer hyeong, terwijl een vrouw hem oppa noemt. Het relatievocabulaire bevat informatie die niet in het Engelse woord "brother" zit.

Dat is belangrijk voor Monica, want Monica is in veel talen vertaald en wordt over de hele wereld gebruikt. We kunnen het hele relatiesysteem niet ontwerpen op de aanname dat het Engels de canonieke lijst van relaties bevat en dat elke andere taal die woorden alleen hoeft te vertalen.

Dat is een probleem dat we in Monica al zijn tegengekomen, en het herbouwen laat het niet als bij toverslag verdwijnen.

Familie is niet eens het moeilijkste deel

Familierelaties hebben tenminste meestal een naam. De rest van onze relaties is veel minder gestructureerd.

"Vriend" kan iemand beschrijven die je dertig jaar kent en met wie je elke week praat, maar ook iemand die je twee keer per jaar ziet en die je heel veel doet. Een collega kan de persoon zijn die elke dag naast je zit, of iemand met wie je vijftien jaar geleden werkte.

En mensen passen niet in één categorie tegelijk. Iemand kan je collega, je vriend en je vroegere huisgenoot zijn. Je zakenpartner kan ook je broer zijn. Je buurvrouw kan de ouder zijn van de beste vriendin van je dochter.

Soms is de context zelf wat telt. Je kent iemand omdat je samen naar school ging, in hetzelfde team speelde, in hetzelfde gebouw woonde of aan hetzelfde project werkte. "Vriend" is misschien formeel juist, maar het verliest de informatie die verklaart waarom die persoon deel uitmaakt van je leven.

Hier wordt een eenvoudige vraag als "hoe ken je deze persoon?" verrassend moeilijk om met één veld te beantwoorden.

Eén relatie kan er veel andere impliceren

Stel dat Ross de broer van Monica is en dat Ross een zoon heeft die Ben heet. We begrijpen onmiddellijk dat Monica de tante van Ben is.

Software kan tot dezelfde conclusie komen. En zodra ze daarmee begint, kan ze doorgaan.

Ouders impliceren kinderen. Kinderen met dezelfde ouders zijn misschien broers en zussen. Broers en zussen met kinderen leveren tantes, ooms, nichten en neven op. Voeg nog een generatie toe en je hebt grootouders en kleinkinderen. Vrij snel kan een klein aantal relaties een veel grotere familiegraaf opleveren.

Maar het feit dat software iets kan afleiden, betekent niet noodzakelijk dat ze het moet doen.

De nieuwe partner van een ouder is niet automatisch een ouder van het kind. Twee mensen die een ouder delen zijn formeel misschien halfbroers of halfzussen, maar kennen elkaar mogelijk niet. De informatie die Monica heeft kan ook simpelweg onvolledig zijn. En zelfs als de familierelatie formeel juist is, is het misschien niet de relatie die de betrokkenen zelf zouden gebruiken om elkaar te beschrijven.

Elke keer dat de software nog een relatie afleidt, krijgt ze ook nog een kans om het mis te hebben.

Er zijn meer vragen dan antwoorden

Hoe langer we hieraan werken, hoe meer randgevallen we vinden.

Moet Monica de geschiedenis van een relatie onthouden of alleen de huidige toestand? Kunnen twee mensen meerdere relaties tegelijk hebben? Is "beste vriend" een andere relatie dan "vriend", of is dat iets anders? Wat gebeurt er als we de moeder van iemand kennen maar die moeder geen contact in Monica is? Hoe beschrijven we relaties die belangrijk voor ons zijn maar geen handige naam hebben?

Sommige daarvan zijn databaseproblemen. De meeste niet.

Het moeilijke deel is beslissen wat we bedoelen wanneer we zeggen dat twee mensen een relatie hebben, want mensen gebruiken dat woord niet met iets dat in de buurt komt van de precisie die een database zou verkiezen.

In de interface komt dit alles uiteindelijk misschien neer op een paar woorden op iemands profiel: moeder, broer, vriend, collega.

Die paar woorden juist krijgen is een van de moeilijkste problemen waar we bij het herbouwen van Monica mee bezig zijn.

Dit is een volgend artikel in de reeks Building Monica, waarin ik schrijf over het proces van Monica helemaal opnieuw opbouwen. De meeste artikelen in deze reeks zullen waarschijnlijk over het product zelf gaan: relaties, herinneringen, aanpasbaarheid, activiteiten, privacy, en alle vragen die opduiken wanneer je het leven van mensen in software probeert weer te geven. Maar het herbouwen van een grote applicatie levert onderweg ook kleinere dingen op. LaraDB is er daar een van.

Terwijl ik aan Monica v3 werkte, merkte ik dat ik veel tijd besteedde aan het rechtstreeks bekijken van de database. Dat is niet bijzonder ongewoon bij het bouwen van een Laravel-applicatie. Je maakt een contact aan en controleert wat er weggeschreven is. Je maakt een relatie aan en bekijkt de bijbehorende rijen. Je wijzigt een herinnering en controleert de datums. Je voert een actie uit, ververst de gegevens, volgt een foreign key, en herhaalt dat vele keren per dag.

Er bestaan al veel goede manieren om dit te doen. Tinker is nuttig, maar niet eenvoudig en snel in gebruik. Applicaties als TablePlus, DBeaver, phpMyAdmin of Adminer kunnen erg handig zijn, maar niet om even snel iets op te zoeken. Ik gebruik TablePlus regelmatig, vooral wanneer ik queries moet schrijven, gegevens moet bewerken of het schema in detail wil bekijken. Maar het grootste deel van de tijd had ik tijdens het ontwikkelen van Monica geen databasebeheertool nodig. Ik wilde alleen snel kunnen zien wat er in de database stond, zonder de applicatie te verlaten waarin ik toch al aan het werk was.

Dat was het oorspronkelijke idee achter LaraDB. Een ontwikkelafhankelijkheid installeren, naar /db gaan en de database zien.

composer require --dev monicahq/laradb

Wat je krijgt is heel eenvoudig. Links staan de tabellen, rechts de rijen, en de pagina draait binnen de Laravel-applicatie zelf. LaraDB ondersteunt SQLite, MySQL en MariaDB, en PostgreSQL.

Een browser in plaats van een databasebeheerder

De belangrijkste beslissing die we namen, was LaraDB alleen-lezen houden. Het heeft geen bewerkknop, geen verwijderknop, geen invoerformulier en geen SQL-console. Beide routes die het pakket blootstelt zijn GET-routes, en het pakket voert uitsluitend SELECT-statements uit.

Dat is deels een veiligheidsbeslissing, maar het gaat vooral over reikwijdte. Er bestaan al volwassen tools om databases te beheren, en een deel van hun functies binnen Laravel nabouwen zou LaraDB niet nuttiger maken voor het probleem dat we probeerden op te lossen.

Het pakket vermijdt ook het accepteren van willekeurige identifiers of queries vanuit de browser. Een opgevraagde tabel moet eerst bestaan in het schema dat de driver heeft gevonden. Identifiers worden gequote volgens de database-engine. Waarden die gebruikt worden bij het volgen van foreign keys worden als parameters gebonden. Er is geen interface om willekeurige SQL in te dienen, omdat willekeurige SQL niet tot het doel van het pakket behoort.

Een klein hulpmiddel blijft begrijpelijk als het een heel nauwkeurige taak heeft. LaraDB is bedoeld om te beantwoorden wat er op dit moment in de database staat en hoe die rijen zich tot elkaar verhouden. Het is niet bedoeld om een vervanging te worden voor een volwaardige databaseclient.

Wat we uiteindelijk nodig hadden

De interface weerspiegelt die beperkte reikwijdte. LaraDB somt de tabellen in het huidige schema op en toont hun rijen in een dichte tabel. Kolomtypes worden getoond, primaire en foreign keys worden aangeduid, NULL-waarden zijn visueel te onderscheiden van lege strings, en lange waarden worden afgekapt zodat grote tekst- of JSON-kolommen de pagina niet onbruikbaar maken.

Foreign keys bleken een van de nuttigere functies voor Monica. Als een kolom naar een andere tabel verwijst, kun je de waarde ervan direct volgen. Erop klikken opent de verwezen tabel, gefilterd op de bijbehorende rij. Dat is vooral handig in Monica v3, omdat een groeiend aantal domeinen wordt weergegeven via expliciete relaties tussen meerdere tabellen in plaats van via grote, op zichzelf staande records.

De pagina toont ook wat context over de huidige database en query. Afhankelijk van wat de database-engine beschikbaar stelt, kan LaraDB de engine en versie, de databasenaam, de omvang, het aantal indexen en andere engine-specifieke metadata weergeven. Voor de huidige pagina toont het bovendien het SQL-statement dat het resultaat opleverde en hoe lang de query duurde.

Er is ook een JSON-weergave van een tabel. Die was goedkoop toe te voegen zodra de databaselaag gescheiden was van het renderen van de HTML, en is nuttig gebleken om gegevens buiten de pagina zelf te bekijken.

De frontend is bewust op zichzelf staand. Het pakket levert zijn eigen CSS en JavaScript mee en leunt niet op de asset-pipeline van de host-applicatie. LaraDB installeren zou niet mogen betekenen dat je een Tailwind-configuratie, een Alpine-afhankelijkheid of nog een buildstap aan een bestaand project moet toevoegen.

De database-abstractie werd het echte werk

Rijen in een browser tonen is rechttoe rechtaan. SQLite, MySQL en PostgreSQL consistent ondersteunen, daar belandde het meeste interessante werk.

De engines verschillen aanzienlijk in de manier waarop ze schema- en databasemetadata blootstellen. Tabellen opsommen, kolommen beschrijven, primaire keys vinden, foreign keys oplossen, rijen tellen en informatie op databaseniveau ophalen vragen allemaal andere queries, afhankelijk van de engine. Zelfs details als het quoten van identifiers moeten correct worden afgehandeld in plaats van als een generieke SQL-operatie.

LaraDB verbergt die verschillen achter een kleine driver-interface. De Laravel-laag vraagt om tabellen, kolommen, rijen en metadata zonder te hoeven weten of de onderliggende verbinding SQLite, MySQL of PostgreSQL is.

Een vereenvoudigd deel van het contract ziet er zo uit:

public function listTables(): array;

public function getColumns(string $table): array;

public function getRowCount(
    string $table,
    ?RowFilter $filter = null,
): int;

public function getRows(
    string $table,
    int $page,
    int $perPage,
    ?RowFilter $filter = null,
): TablePage;

public function getForeignKeys(string $table): array;

Elke databasedriver implementeert die operaties anders, terwijl de rest van LaraDB werkt met de gemeenschappelijke resultaatobjecten die de interface teruggeeft.

Een interessant gevolg van dit ontwerp is dat de kern van de databaselezende code helemaal niet van Laravel afhangt. Die werkt rechtstreeks met PDO. Laravel zorgt voor package discovery, configuratie, routing en rendering, maar de eigenlijke database-inspectie kun je los gebruiken.

use LaraDb\DriverFactory;

$pdo = new PDO('sqlite:database.sqlite');
$driver = DriverFactory::fromPdo($pdo);

foreach ($driver->listTables() as $table) {
    echo $table->name;
}

Alleen-lezen is niet hetzelfde als ongevaarlijk

Dat het pakket alleen leest, voorkomt dat het de database beschadigt, maar het maakt het blootstellen van de database niet ongevaarlijk. Een databasebrowser kan elke rij in elke tabel tonen aan iedereen die erbij kan, wat voor een applicatie als Monica uiteraard een ernstig probleem is.

Daarom is LaraDB bedoeld om als ontwikkelafhankelijkheid geïnstalleerd te worden.

composer require --dev monicahq/laradb

Een normale productie-deploy met composer install --no-dev bevat het pakket niet. LaraDB is bovendien standaard uitgeschakeld buiten de local-omgeving, en de routes gebruiken standaard de web- en auth-middleware wanneer ze wel aanstaan.

Kleine dingen die uit een grote herbouw voortkomen

Toen ik met de reeks Building Monica begon, verwachtte ik dat het meeste schrijfwerk over de grote architectuur- en productbeslissingen achter Monica v3 zou gaan. Dat blijft ook zo. Maar ik wil ook een aantal van de kleinere hulpmiddelen en ideeën vastleggen die uit de herbouw voortkomen, want ook die horen bij het werk.

LaraDB is geen belangrijk onderdeel van Monica v3, en het probeert op zichzelf geen groot product te worden. Het is gewoon een klein ontwikkelhulpmiddel dat een terugkerende ergernis voor ons wegnam. Het pakket is nuttig juist omdat de reikwijdte beperkt is, en dat zou ik graag zo houden.

Als je aan Laravel-applicaties werkt en vaak een databaseclient opent alleen om te bekijken wat je code net heeft weggeschreven, is LaraDB misschien ook voor jou nuttig.

composer require --dev monicahq/laradb

Ga daarna naar /db.

De broncode is beschikbaar op github.com/monicahq/laradb.

Dit is het eerste artikel in een reeks die Building Monica heet. Ik wil deze reeks gebruiken om te documenteren hoe we Monica, de open source persoonlijke CRM, helemaal opnieuw opbouwen. Ik ga schrijven over de problemen die we proberen op te lossen, de beslissingen die we onderweg nemen en waarschijnlijk ook over een aantal dingen die niet lopen zoals verwacht.

Bijna tien jaar geleden begon ik Monica te bouwen omdat ik verschrikkelijk slecht was in het onthouden van dingen over mensen. Ik vergat de naam van iemands kind, waar we het over hadden gehad toen we elkaar voor het laatst zagen, of iets belangrijks dat iemand me een paar maanden eerder had verteld. Ik wilde een plek om dat allemaal op te schrijven, vooral om mijn slechte geheugen te compenseren, dus begon ik een professionele CRM te gebruiken.

Dat was geen goede oplossing. De software was gemaakt voor verkopers, en dat was ik niet, en ik had niet veel zin om te betalen voor een tool die me moest helpen geld te verdienen terwijl ik alleen dingen over mijn vrienden en familie wilde onthouden. Ik zocht iets dat beter paste, vond niets, en besloot het zelf te bouwen.

Dat kleine project werd uiteindelijk Monica. Ik zette de code op GitHub, plaatste hem op Hacker News, en vanaf daar ging het er een beetje wild aan toe. Ik was blijkbaar niet de enige die naar zoiets op zoek was. Alexis kwam er later als medeoprichter bij, en in de loop der jaren hebben duizenden mensen Monica gebruikt, code bijgedragen, het project vertaald, fouten gemeld en de applicatie op hun eigen server gezet. Het project heeft nu meer dan 25.000 sterren op GitHub en is een van de bekendste open source persoonlijke CRM's geworden.

Ik ben heel trots op wat Monica is geworden. Maar na er zo lang aan gewerkt te hebben, ben ik op een punt gekomen waarop de huidige versie niet meer de persoonlijke CRM is die ik vandaag zou bouwen.

Bijna tien jaar aan beslissingen

Toen ik met Monica begon, had ik natuurlijk geen tien jaar ervaring in het nadenken over hoe je persoonlijke relaties in software weergeeft. De meeste beslissingen werden genomen op het moment dat er een probleem opdook. We hadden contacten nodig, dus bouwde ik contacten. We hadden relaties nodig, dus voegde ik relaties toe. Daarna kwamen herinneringen, activiteiten, cadeaus, notities, huisdieren, adressen en veel andere functies.

Er is niets bijzonder verkeerd aan software zo bouwen. Zo is Monica gegroeid, en veel van die beslissingen waren op dat moment logisch. Maar na bijna tien jaar tellen ze op. Nieuwe ideeën moeten om beslissingen heen werken die jaren eerder zijn genomen, en wat eruitzag als een implementatiedetail wordt langzaam een grens aan wat je met het product kunt doen.

In de loop van de tijd zijn sommige delen van Monica daardoor moeilijker te veranderen dan ze zouden moeten zijn. En belangrijker nog: ik ben van gedachten veranderd over een aantal van de oorspronkelijke beslissingen.

Wat zou ik vandaag bouwen?

Op een bepaald moment begon ik me een eenvoudige vraag te stellen: als Monica niet bestond en ik vandaag een persoonlijke CRM moest bouwen, met alles wat ik het afgelopen decennium heb geleerd, hoe zou die er dan uitzien?

Dat leidde snel tot vragen die veel fundamenteler waren dan welke functies Monica zou moeten hebben. Wat is een persoon eigenlijk in Monica? Hoe zouden relaties tussen mensen moeten werken? Hoe zou Monica de gebruiker zelf moeten weergeven? Wat gebeurt er als het belangrijke in iemands leven geen andere persoon is, maar een dier, een organisatie of iets heel anders? Hoe zouden herinneringen moeten werken als menselijke relaties van zichzelf geen schema volgen? Wat zou een activiteit moeten voorstellen? En hoeveel hiervan zou Monica eigenlijk voor je moeten bepalen?

Relaties zijn een goed voorbeeld. Opslaan dat Monica de zus van Ross is, lijkt niet bijzonder ingewikkeld. Maar als Monica de zus van Ross is, is Ross ook de broer van Monica. Een ouderrelatie veronderstelt een kindrelatie. Sommige relaties hebben een richting, andere niet. Echte families hebben scheidingen, nieuwe huwelijken, stiefkinderen, halfbroers en halfzussen, adoptie en allerlei structuren die niet netjes in een vaste lijst passen. Verschillende culturen beschrijven familiebanden ook anders.

Ik heb hier voor de nieuwe versie veel over nagedacht, en ik zie relaties nu als een eigen domein in plaats van als een eigenschap die aan een contact hangt. Dat lijkt me nu volkomen logisch. Dat was het niet toen we de eerste versies van Monica ontwierpen.

Aanpasbaarheid is nog een gebied waarover ik van gedachten ben veranderd. Historisch heeft vooral Monica bepaald wat een contact is en welke informatie je erover kunt bewaren, en hebben we rond die structuur aanpasbaarheid toegevoegd. Voor v3 willen we dat omdraaien. Monica blijft goede standaardinstellingen bieden, want niemand wil vijftig dingen instellen voordat hij zijn eerste contact toevoegt, maar jouw leven zou niet in het databaseschema hoeven passen dat wij voor iedereen goed vonden.

Zodra je dingen op dat niveau verandert, is een paar schermen opnieuw ontwerpen niet genoeg. De fundering moet ook veranderen.

Wat ik wil dat v3 wordt

Monica v3 is niet bedoeld als het huidige product met een mooiere interface. De interface gaat flink veranderen, en ik wil dat die veel speelser en persoonlijker aanvoelt dan de meeste software die we vandaag gebruiken, maar dat is maar een deel van het werk.

Ik wil een heel krachtig systeem bouwen om de mensen en relaties in iemands leven te documenteren. Alles optimaliseren voor eenvoud interesseert me niet zo als het resultaat een product is dat alleen eenvoudige levens kan weergeven. Ik heb liever goede standaardinstellingen voor mensen die niets willen instellen, en geef mensen die dat wel willen enorm veel controle over hoe hun Monica werkt.

Dat betekent relaties als volwaardige concepten behandelen en mensen zelf laten bepalen welke informatie voor hen belangrijk is. Monica moet veel meer aankunnen dan een vaste lijst velden die aan een contact hangt. Het moeilijke wordt om dat allemaal te doen zonder te eindigen met bedrijfssoftware voor het beheren van je vrienden en familie, want dat zou behoorlijk vreselijk zijn.

Er zijn ook dingen die ik niet wil veranderen. Privacy en eigenaarschap over je gegevens blijven enorm belangrijk voor Monica. Het project blijft open source en je kunt het zelf blijven hosten. Als je jarenlang een deel van de meest persoonlijke informatie in je leven aan software toevertrouwt, vind ik dat je zoveel mogelijk controle over die informatie moet hebben.

Ik wil ook niet dat Monica bepaalt hoe belangrijk iemand voor je is. Ze kan je helpen dingen te onthouden, informatie te organiseren en je vertellen dat je iemand al een tijd niet hebt gesproken. De relatie zelf blijf je zelf onderhouden.

Opnieuw beginnen, met tien jaar ervaring

"Opnieuw beginnen" is natuurlijk niet helemaal juist. Toen ik Monica in 2017 maakte, had ik een idee en een probleem dat ik wilde oplossen. Deze keer hebben we bijna tien jaar ervaring met dat probleem, duizenden gesprekken met gebruikers, bijdragen van mensen over de hele wereld, twee generaties van het product en een behoorlijk lange lijst met dingen die we niet nog eens zo zouden doen.

Terwijl we aan v3 werken, wil ik hier meer van in het openbaar documenteren. Achter iets dat van buiten redelijk eenvoudig lijkt, zitten verrassend veel moeilijke problemen, vooral als je serieus gaat nadenken over relaties, herinneringen, aanpasbaarheid en hoe je iets zo rommelig als een mensenleven in een database weergeeft. Ik ga over die problemen schrijven, maar ook over de technische keuzes en ontwerpkeuzes die we maken en over de dingen die we proberen en die niet blijken te werken.

Daar gaat Building Monica over. Ik weet niet hoe vaak ik een artikel zal publiceren, en ik wil geen publicatieschema bedenken alleen maar om er een te hebben. Ik schrijf wanneer we iets interessants te vertellen hebben.

In 2017 bouwde ik Monica op basis van wat ik toen van het probleem begreep. Bijna tien jaar later begrijp ik dat probleem heel anders. Daarom bouwen we het opnieuw.

Het is alweer een tijd geleden dat we echt iets over Monica hebben verteld.

Alexis en ik denken al heel lang na over een nieuwe versie. Duidelijk langer dan we aanvankelijk hadden gedacht. Een applicatie helemaal opnieuw opbouwen terwijl je een fulltimebaan, een gezin en een leven buiten Monica hebt, blijkt nogal wat tijd te kosten. Wie had dat gedacht.

Maar vandaag kunnen we eindelijk dit zeggen: we brengen de nieuwe versie van Monica uit voor het eind van 2026.

Deze nieuwe versie is de Monica die we al jaren willen bouwen. Hij wordt sneller, flexibeler, makkelijker in gebruik en gebouwd op een veel steviger fundament.

Monica blijft je helpen de mensen te onthouden die je dierbaar zijn. Het blijft privé. Het blijft open source. En je kunt het nog steeds gratis op je eigen server installeren.

We hebben er ongelooflijk veel zin in. Monica maakt nu al bijna tien jaar deel uit van ons leven, en dit voelt als het begin van een compleet nieuw hoofdstuk voor het project.

Er is nog veel werk te doen.

Maar het komt eraan. Deze keer echt.

Bedankt voor je geduld, je berichten en je steun al die jaren. We kunnen niet wachten je te laten zien wat we hebben gebouwd.

Met veel plezier kondigen we aan dat onze nieuwe versie, met de codenaam Chandler, na 18 maanden hard werken beschikbaar is in bèta: https://beta.monicahq.com

Monica is 7 jaar geleden ontstaan met het doel een persoonlijke CRM te zijn. Deze nieuwe versie gaat over het vastleggen van je leven, inclusief wat je contacten doen, maar niet alleen dat.

Wat betekent bèta? Het is alsof er een stel ondeugende kleine bugs in onze software verstopt zit die verstoppertje met ons spelen. We weten vrij zeker dat ze er zijn, maar we hebben geen idee welke of waar ze zich schuilhouden. We hebben dus alle dappere zielen nodig om bij ons bugjachtteam te komen en ze eruit te jagen voordat we het aan het publiek uitbrengen.

Chandler is Monica volledig opnieuw gedacht, vanaf de grond opgebouwd. We hebben de flinke technische schuld die we door de jaren heen hadden opgebouwd weggewerkt en veel nieuwe functies toegevoegd of verbeterd. Hoewel we geen reclame voor Chandler hebben gemaakt, hebben veel gebruikers het al getest en fouten gevonden die we hebben opgelost, maar we hebben deze software nog niet op schaal getest. Dus maak alsjeblieft een account aan en veel plezier.

De versie op de bètaserver mag als stabiel worden beschouwd. We zetten de database niet terug. We maken dagelijks een back-up van je gegevens, en die gegevens blijven bewaard zodra we de definitieve versie officieel uitbrengen.

Chandler heeft een paar beperkingen:

• Je kunt je huidige inloggegevens van Monica niet gebruiken,
• Je kunt je gegevens niet importeren,
• Er is geen massa-import van contacten,
• We hebben nog geen API.

We hebben volop nieuwe functies, een nieuwe indeling en de veelgevraagde donkere modus.

Persoonlijk ben ik het meest trots op de mogelijkheid om vrijwel alles in Chandler aan te passen: van de indeling tot de modules die je aanzet tot de gegevens die je over je leven kunt invoeren.

Chandler is nog steeds open source en kan gratis op je eigen server worden geïnstalleerd, als je met Docker of de opdrachtregel overweg kunt. Je kunt de code nog altijd aanpassen als je dat wilt. Monica is en blijft open source. Zo hoort het.

Voorlopig is Monica gratis op onze gehoste installatie (https://beta.monicahq.com), maar we hanteren dezelfde prijzen als de huidige versie zodra we het product stabiel vinden.

Ik ben ongelooflijk trots op wat we de afgelopen acht jaar hebben bereikt. Destijds was ik bang mijn code openbaar te maken omdat ik wist dat de kwaliteit slecht was. Verrassend genoeg leek het niemand iets te kunnen schelen. Inmiddels staat onze code nog altijd open voor iedereen en maken we ons geen zorgen meer over een oordeel. De app is nog steeds een Laravel-applicatie, met VueJS aan de voorkant en InertiaJS tussen voor- en achterkant. Het is een heel eenvoudige opzet. We streven ernaar onze code zo eenvoudig mogelijk te houden, om het onderhoud, de doorontwikkeling en het vinden van ontwikkelaars die ons helpen makkelijker te maken.

We stappen binnenkort over op Chandler voor onze officiële Docker-image. Die image is meer dan 25 miljoen keer gedownload, wat ons nederig stemt.

Namens het hele team van Monica: bedankt dat jullie al die tijd bij ons zijn gebleven. Het "hele team van Monica" is eigenlijk twee vrienden, Alexis en ik, die er oprecht gepassioneerd over zijn mooie gereedschappen te maken waarmee mensen hun leven kunnen verbeteren. Monica is voor ons nog steeds een project naast ons werk; we hebben allebei "ernaast" een fulltimebaan. Waar sommige mensen computerspelletjes spelen of naar Netflix kijken, "spelen" wij in de code van Monica. En dat vinden we heerlijk.

Alexis en ik (Regis) werken nu een paar maanden (nou ja, sinds januari 2022) aan een gloednieuwe versie van Monica. De eerste echt nieuwe hoofdversie sinds we een paar jaar geleden lanceerden.

Ik word erg verleid om het een "snellere, nieuwere, betere versie" te noemen, want dat is het, maar ik ben slecht in marketing, dus ik zeg gewoon dat het een nieuwe versie is en beantwoord hieronder de vragen die je misschien hebt.

Wat bedoelen we met een nieuwe versie?

Een volledige herschrijving van Monica, vanaf nul.

Zijn jullie gek geworden?

Ja, maar ook: de code van Monica is inmiddels oud. Oud in de zin dat het 7 jaar oud is en dat honderden bijdragers eraan hebben gezeten. Er zitten dingen in de code die we destijds hebben doorgelaten, omdat we het toen niet beter wisten of omdat we bijdragers niet voor het hoofd wilden stoten, die we niet meer willen. Het project heeft veel te veel afhankelijkheden en het onderhouden van de code is lastiger geworden dan het was. Iets veranderen is riskanter en kost meer tijd. We hebben ook gezien hoe mensen Monica gebruiken en wat ze ermee willen, en de huidige code beperkt ons veel te veel als we willen ondersteunen waar mensen Monica voor willen inzetten. En tot slot is Monica voor ons nog steeds een project naast ons werk. We zijn er enorm gepassioneerd over en we willen er ook plezier in hebben om het te bouwen. En dat was de huidige versie niet meer.

Wat bedoelen jullie met herschrijven?

Dat we met een lege code zijn begonnen en het daarvandaan hebben opgebouwd. Eerder was het een Laravel-app (dus PHP), met Blade-views en hier en daar wat Vue. Nu is het nog steeds een Laravel-app (dus nog steeds PHP), maar volledig met Vue 3. We hebben veel vereenvoudigd, sommige dingen flexibeler en daardoor iets ingewikkelder gemaakt, maar we denken dat we de toekomst van Monica ermee aankunnen.

Het betekent ook dat we een gloednieuwe gegevensstructuur hebben, gedragen door een nieuw databaseschema.

Gaat de nieuwe versie Monica heten?

Op dit moment is de codenaam van de nieuwe Monica Chandler. Die naam houden we niet: de officiële naam van de nieuwe Monica wordt Monica. Voor de duidelijkheid noemen we de nieuwe versie in de rest van dit artikel Chandler.

Kozen jullie PHP ondanks \?

PHP is een prima taal. We leven niet meer in het tijdperk van PHP 4 of 5. Het is bovendien een heel eenvoudige taal, wat betekent dat veel mensen ter wereld PHP kunnen lezen en begrijpen. PHP kiezen betekent dat het makkelijker is aan het project bij te dragen, makkelijker te debuggen, makkelijker te onderhouden en makkelijker voor ons om mensen te vinden die ons helpen als dat later nodig is. En het ecosysteem van PHP is gewoon prachtig, met Laravel als wegbereider van een van de beste ontwikkelaarservaringen die ik ken.

Welke functies krijgt Chandler?

Bij de lancering willen we 100% (of bijna) de functies van Monica v1 evenaren. Ook als we ze evenaren, wilden we ze ofwel vereenvoudigen (taken bijvoorbeeld) ofwel robuuster maken (herinneringen bijvoorbeeld).

Zodra dat gedaan is hebben we zoveel ideeën over wat Monica zou moeten worden dat het overweldigend is. Monica is ontstaan als de eerste persoonlijke CRM (of PRM, personal relationship manager) die er was. Zo hebben we het ook in de markt gezet. Maar na jaren eraan werken, met mensen praten en de duizenden e-mails lezen die jullie ons hebben gestuurd, beseften we dat Monica eigenlijk een manier is om je leven vast te leggen, wat dat voor jou ook betekent. Monica gaat dus over je leven vastleggen, en je gereedschap geven om dat te doen zoals jij dat wilt.

Overal lees je dat producten een uitgesproken mening en een sterke persoonlijkheid moeten hebben, zodat mensen je gereedschap gebruiken zoals jij dat wilt. Dat was de richting van v1. Die uitspraak willen we nu veranderen. We willen dat mensen Monica gebruiken en instellen zoals zij dat willen. Wie zijn wij om te zeggen dat je maar 3 voornaamwoorden voor je contacten mag gebruiken, of welke soorten relaties je zou moeten hebben? Chandler wordt volledig aanpasbaar, van wat je in de interface ziet tot het soort gegevens dat je kunt invoeren. Marketingmensen zouden zeggen "Chandler draait helemaal om jou", en dat is in zekere zin waar. Het nadeel: technisch gezien is dat lastiger te beheren, maar dat is onze zorg.

Wanneer is het klaar? Kan ik het proberen?

Het is klaar als het klaar is. Bedenk dat we hier absoluut niet fulltime aan werken. Alexis en ik hebben allebei veeleisende banen, en we hebben gezinnen, vrienden en Monica (en OfficeLife).

MAAR.

We hebben al veel gedaan. Een paar grote functies die je kent en waar je van houdt ontbreken nog in de nieuwe versie: levensgebeurtenissen, activiteiten, cadeaus en CalDAV/CardDAV, om er een paar te noemen. Levensgebeurtenissen zijn extra groot omdat we het hele idee opnieuw willen doordenken en echt nuttig willen maken. En, dat is een enorme "en", we hebben nu nog geen API. Omdat dit een nieuwe code is, kunnen we je bestaande v1-contacten niet zomaar kopiëren en verwachten dat ze in v2 verschijnen. Zouden we nu iets uitbrengen, dan kon je je gegevens dus niet importeren. En dat vinden we een probleem.

DAT GEZEGD HEBBENDE.

We hebben nog steeds testers nodig die ons helpen fouten te vinden, ook al maken wij hier geen fouten (lol). We hebben mensen nodig die spelfouten in de documentatie helpen oplossen. Wat we dus zouden kunnen doen is Chandler in een zeer vroege alfastaat uitbrengen, gratis voor iedereen tot het geen alfa meer is.

Is het nog steeds open source? Kan ik het gratis gebruiken?

Ja, het is nog steeds open source, met dezelfde licentie als eerst. Dat betekent dat Monica uiteraard gratis is, tenzij je de versie gebruikt die wij hosten, die uiteindelijk iets gaat kosten, net als de huidige versie. Ja, je kunt het installeren waar je wilt, op je eigen server. Omdat Chandler niet dezelfde code is, hebben we nog niet het rijke ecosysteem dat we eerder hadden met al die verschillende manieren om het overal te installeren, maar dat komt goed. En ja, je kunt nog steeds aan de code bijdragen, fouten oplossen en functies toevoegen, al behouden we ons het recht voor je pull request te weigeren als we vinden dat we niet willen ondersteunen wat jij wilt.

Wat is de toekomst van Monica v1?

We ondersteunen v1 tot Chandler uit alfa en bèta is. Daarna komt het te vervallen, maar wie het zelf host kan het blijven gebruiken als hij dat wil. De v1 die wij zelf hosten wordt daarna niet meer ondersteund.

Kun je nu al aan de code bijdragen?

De repository staat al op GitHub, maar we zijn nog lang niet zo volwassen als de huidige hoofdrepository. Dat betekent dat we nog niet klaar zijn om bijdragen van iedereen te ondersteunen, omdat er bijna elke dag dingen veranderen, maar als je dat accepteert: ga je gang.

Wat komt er hierna?

Allereerst: heel erg bedankt dat je dit hele bericht hebt gelezen. We zijn enorm dankbaar voor onze gemeenschap en voor het feit dat jullie nog steeds gepassioneerd zijn over dit kleine hulpmiddel dat wij met plezier bouwen. Alexis en ik zijn nog altijd erg gemotiveerd, en we danken jullie dat jullie er met ons om geven. We houden contact.

Op dit moment gebruiken we Stripe om onze abonnementen te beheren. We zijn dol op Stripe als ontwikkelaar, maar het is een complete puinhoop om er wereldwijd de belastingen mee af te handelen, zeker aan het eind van het boekjaar. Onze boekhouder haat ons. We moeten over naar een andere betaaldienst die alle belastingen op de juiste manier afhandelt. Die betaaldienst heet Paddle.

Er is nog een reden waarom we onze huidige aanpak willen veranderen. Monica is in de eerste plaats een open source product. We hebben een enorme gemeenschap. Velen van jullie draaien Monica op hun eigen server. Omdat we het product ook zelf hosten om er geld mee te verdienen, zit op dit moment alle code voor het beheren van abonnementen in de hoofdcode. Dat is veel code. We regelen het afsluiten, wijzigen en opzeggen van een abonnement, met alle rechten die daarbij horen, enzovoort. Dat is niet ideaal.

We hebben besloten alle code rond facturatie uit de hoofdcode te halen en een nieuw portaal te maken, het abonnementsportaal, om je abonnementen op Monica te beheren. Je maakt op die website een account aan en koopt een licentiesleutel die je in je Monica-account plakt. Meer is er niet nodig.

Heb je nu een abonnement, dan kun je je account eenvoudig laten overzetten. Iedereen krijgt daarover per e-mail nadere instructies.

We willen de komende weken naar dit nieuwe klantenportaal overstappen.

Zoals alles wat we bij Monica doen is ons klantenportaal volledig open source en staat de code op GitHub. En zodra het klantenportaal live is, is de hoofdcode van Monica volledig vrij van het begrip facturatie.

Het is lang geleden. Een jaar zelfs, sinds het laatste bericht op deze blog. In dit bericht hebben we het over de nieuwe release 2.16 die we net hebben gemaakt, over wat er in 2019 is gebeurd en over wat er hierna met Monica gebeurt.

Versie 2.16 bevat 226 wijzigingen, waarvan de meeste opgeloste fouten of verbeteringen in de code zijn. Maar er zitten ook een aantal nieuwe functies in, die we hieronder toelichten.

Nieuwe manier om activiteiten toe te voegen

Je kunt activiteiten nu ter plekke toevoegen, in plaats van daarvoor naar een nieuwe pagina te gaan. Net als bij telefoongesprekken kun je nu aangeven welke emoties je tijdens een activiteit voelde.

Betere instellingenpagina voor de API

Het meeste wat je met Monica kunt doen, kan ook via de API. Het is voor ons enorm belangrijk dat mensen naar believen met hun gegevens kunnen werken. Daarom werd het tijd de instellingenpagina voor de API wat aandacht te geven.

We hebben ook veel nieuwe API-methodes toegevoegd om ons verder open te stellen voor andere systemen.

Veel veranderingen onder de motorkap

We hebben ook volledig veranderd hoe gegevens worden opgeslagen, door aan elke tabel in de database externe sleutels toe te voegen. Voor de gebruiker verandert er niets, maar voor ons als ontwikkelaars is het behoorlijk ingrijpend, omdat het ons meer controle en flexibiliteit geeft. Dit was een enorme verandering en het duurde bijna 11 maanden voordat de pull requests waren samengevoegd.

We hebben ook het exporteren van gegevens volledig omgebouwd en dat zou nu vlekkeloos moeten werken (of, zoals ze zeggen: 60% van de tijd werkt het altijd).

Wat is er in 2019 gebeurd?

In 2019 zijn we qua releases per jaar wat langzamer gaan lopen. Ook lag de activiteit op deze blog stil. Dat had geen invloed op het aantal aanmeldingen, het aantal downloads of de liefde van mensen op internet voor dit project.

Monica heeft er eigenlijk nog nooit zo sterk voor gestaan. Onze officiële docker-image is bijna 5 miljoen keer gedownload. We hebben tienduizenden gebruikers op onze gehoste versie. Monica duikt steeds weer op Hacker News op en onze issuetracker op GitHub is drukker dan ooit. We hebben in 2019 875 pull requests samengevoegd.

Waarom dan die stilte? Dat lag vooral aan mij (Regis). Ik ben bijna vier jaar geleden met Monica begonnen. Een populair project hebben is heel leuk, maar het kost ook veel energie en motivatie. Zeker omdat Monica voor zowel mij als Alexis nog steeds een project naast ons werk is. Dit jaar werd Monica me te veel, en ik ben meestal degene die op deze blog of op sociale media schrijft. Een burn-out van een project naast je werk, zou je kunnen zeggen. Alexis heeft veel werk op zich genomen om het product te onderhouden en verder te brengen, maar ik kon er niet zoveel aan werken als eerst en ik kon geen nieuws over het project plaatsen. Ik moest iets anders doen, mijn hoofd leegmaken en pas terugkomen als ik er klaar voor was. Dat ben ik nu, en ik ben meer dan gemotiveerd om weer aan de slag te gaan en er weer plezier in te hebben.

Monica in 2020

Vier jaar geleden was Monica een van de eerste populaire persoonlijke CRM's. Vandaag is de concurrentie groter dan ooit (een stuk of twaalf, toen ik voor het laatst keek). Maar ik geloof dat we een voordeel hebben dat onze concurrenten ons niet kunnen afnemen: we zijn open source, we hebben nauwelijks kosten en we zijn niet hebberig. Alles wat we doen, doen we in de eerste plaats voor de gemeenschap. Hoe meer installaties van Monica er in het wild draaien, hoe blijer we zijn: dat betekent namelijk dat we geen enkele controle hebben over de gegevens van onze gebruikers.

In 2020:

• Willen we ons werk aan openheid en transparantie voortzetten. Dat betekent meer manieren om gegevens te exporteren of importeren in een standaardformaat.
• Willen we webhooks bieden, zodat externe systemen kunnen weten wanneer er gegevens in je account veranderen (als jij dat wilt, uiteraard).
• Denk ik dat Monica op dit moment het beste hulpmiddel is om je persoonlijke contacten vast te leggen. Je kunt echt alles noteren. Nu we een heel stevig fundament hebben, vind ik het tijd om daarop voort te bouwen. Het wordt tijd dat je meer met je contacten kunt doen, door groepen (of families), gebeurtenissen, kansen enzovoort te maken. We richten ons op eenvoudige begrippen die geleidelijk aan het platform worden toegevoegd en je zoveel mogelijk vrijheid geven.

Monica is een hulpmiddel voor jou. Blijf alsjeblieft ideeën delen en blijf me mailen over wat we hierna zouden moeten doen. We zijn er voor jou.

En verder: gelukkig nieuwjaar 😀

Na ruim een maand werk kondig ik met plezier de nieuwe versie van Monica aan, met foto's uploaden, betere beveiliging, beter beheer van telefoongesprekken, weerbericht, de introductie van emoties en nog veel meer verbeteringen.

Foto's uploaden

Je kunt nu foto's uploaden op de profielpagina van een contact. Hoeveel foto's je kunt bewaren hangt af van de opslaglimiet van je account, die op https://monicahq.com 512 MB is (en per installatie instelbaar). Foto's kunnen uploaden opent in de toekomst veel mogelijkheden.

Herstelcodes

Beveiliging is enorm belangrijk, zeker in een hulpmiddel als Monica dat veel intieme details bewaart. Monica ondersteunt al tweefactorauthenticatie (ook bekend als 2FA) en U2F om je account te beveiligen. Vanaf Monica 2.11 kun je herstelcodes genereren om je account te openen als je niet meer met 2FA kunt inloggen. Pas wel op: met die codes kun je bij je account, dus bewaar ze op een heel veilige plek.

Telefoongesprekken

Telefoongesprekken hebben in deze release veel aandacht gekregen. Om te beginnen hebben we de manier waarop je ze noteert opnieuw ontworpen. Daarna hebben we (eindelijk) de mogelijkheid toegevoegd een eerder gevoerd gesprek te bewerken. En als extraatje kun je nu aangeven wie het gesprek begon.

Emoties

Zou het niet mooi zijn om heel precies te kunnen vastleggen hoe je je voelde toen er iets gebeurde? Monica 2.11 introduceert het idee van emoties, gebaseerd op het werk van dr. Phillip Shaver. In zijn werk worden emoties in 3 hoofdcategorieën ingedeeld:

• Primaire emoties (liefde, vreugde, verrassing, boosheid, verdriet en angst),
• Secundaire emoties (liefde -> genegenheid, verlangen, gemis),
• Tertiaire emoties (liefde -> genegenheid -> aanbidding, liefde, tederheid, aantrekking).

Die begrippen hebben we in Monica opgenomen, om te beginnen bij telefoongesprekken. Er is een nieuw keuzemenu waarin je zoveel emoties kunt kiezen als je wilt, zodat je heel precies kunt weergeven wat je tijdens een gesprek voelde. We zijn van plan emoties ook aan andere belangrijke onderdelen toe te voegen, zoals activiteiten.

Weer

Als je praat met een vriend die ergens anders woont dan jij, is de kans groot dat het uiteindelijk over het weer gaat. Monica helpt je daarbij door het huidige weer te tonen op de plek waar je vriend woont. Die informatie komt van het eerste adres op de profielpagina van het contact. Dat betekent ook dat er geen weerbericht verschijnt als er geen adres is ingevuld.

De weergegevens komen van Darksky en worden elke 6 uur ververst. Het enige wat we met Darksky delen is de breedte- en lengtegraad, verder niets. Voor wie een eigen installatie beheert: Darksky heeft een gratis abonnement waarmee je 1.000 aanroepen per dag mag doen, wat ruim voldoende zou moeten zijn.

GPS-coördinaten

Over breedte- en lengtegraad gesproken: om het weer te kunnen tonen moesten we een manier vinden om die twee gegevens te achterhalen bij elk adres in Monica. Monica 2.11 kan nu elk adres automatisch geocoderen om de coördinaten te vinden.

Voer je een adres in, en is de dienst op je installatie ingesteld, dan proberen we het automatisch te geocoderen, tenzij je de coördinaten voor een plek zelf opgeeft.

Het geocoderen gebeurt door LocationIQ, een mooi en onafhankelijk bedrijf dat een royaal gratis abonnement van 10.000 aanroepen per dag biedt. We delen met LocationIQ niets anders dan het adres, om de coördinaten op te halen.

Taken

Op je dashboard kun je nu taken toevoegen die aan geen enkel contact gekoppeld zijn.

Verbeteringen

We hebben veel van de interne opzet herschreven. Dat past bij onze zoektocht naar een zo stabiel mogelijk platform. Ook hebben we de testdekking verder verhoogd (oftewel de mate waarin onze code echt automatisch getest wordt). We zitten nu op 66% dekking voor de hele code.

We hopen dat je 2.11 net zo mooi vindt als wij.

Ik heb de mobiele applicaties zojuist uit zowel de Apple Store als de Play Store gehaald. De enige manier om ze nog te krijgen is ze zelf bouwen vanuit de repository op GitHub.

Theo heeft geweldig werk geleverd aan de eerste versie van die apps, maar de ontwikkeling is aan het begin van deze zomer stil komen te liggen terwijl de ontwikkeling van Monica, het platform, doorging. We zitten nu in een situatie waarin de mobiele app niet meer gelijk loopt met het platform, en erger nog: we gaan dingen in de API veranderen die de mobiele app niet ondersteunt.

Ik blijf ervan overtuigd dat de groei en het gebruik van Monica via een mobiele app zullen lopen.

Ik zou graag prachtige dingen beloven en aankondigen dat er over 2 maanden een nieuwe app is, maar eerlijk gezegd weet ik niet hoeveel tijd het gaat kosten. Omdat Monica nog steeds een project naast mijn werk is, kan het 6 maanden duren, of 2 jaar. Maar op een dag hebben we een mooie mobiele applicatie, net zo goed als de webversie (zo niet beter).

Bedankt voor je geduld.