Gescheiden ouders met (tijdelijke) psychische klachten

In Nederland is het zo dat wanneer je als ouders uit elkaar gaat (en samen kinderen hebt) en een van de ouders last heeft van tijdelijke psychische klachten dat er in de scheidingsprocedure een onderzoek wordt ingesteld door de Raad voor de Kinderbescherming. In dat onderzoek worden twee onderwerpen behandeld: omgang met de kinderen en ouderlijk gezag. De Raad voor de Kinderbescherming brengt dan een advies uit aan de Rechtbank. Deze werkwijze wordt nu een kleine 2 jaar zo gehanteerd. Wanneer een van de ouders (tijdelijk) last heeft van psychische klachten kan het zo zijn dat goede omgang met de kinderen een korte of wat langere periode moeilijker te realiseren is. Maar dat wil nog niets zeggen over beslissingen kunnen nemen die de opvoeding van het kind aangaan. Wanneer een ouder last heeft van psychische klachten wil dat niet zeggen dat de ouder niet kan nadenken of meedenken over opvoedkundige beslissingen die voor de kinderen genomen moeten worden. Om die reden zou gezamenlijk ouderlijk gezag dan ook altijd gehandhaafd moeten blijven. Het handhaven van gezamenlijk ouderlijk gezag zorgt er ook voor dat de ouders met elkaar blijven praten en legt daarnaast druk op instanties om daarin te begeleiden en dit is in het belang van de kinderen.

Ouderlijk gezag op de schop

In Nederland is het zo dat wanneer je niet getrouwd bent dat je als vader niet automatisch het gezag hebt over je kinderen. Dit zorgt in de praktijk voor een hoop onenigheid tussen ouders als het gaat om beslissingen nemen over het kind.

Wat is het voor onzin dat je als vader het kind eerst moet erkennen en dat je daarna pas gezag kunt aanvragen over je kind?

Dit geeft de moeder een bevoorrechte positie en dit is niet correct, want de vader zou een bevoorrechte positie moeten hebben. In het scheppingsverhaal uit de Bijbel werd de vrouw namelijk geschapen uit een rib van de man. De reden dat dit zo is opgeschreven heeft alles te maken met energetische verbondenheid tussen mensen. Op de 4puppies pagina over zielengroepen kun je meer lezen over deze energetische verbondenheid.

Ieder kind wordt toch ingeschreven in het geboorteregister van de gemeente? En wanneer een kind wordt ingeschreven in het geboorteregister wordt daarbij toch een vader en een moeder geregistreerd?

Wanneer de vader van het kind niet goed kan worden vastgesteld betekent dit dat de moeder tijdens het zwanger worden meerdere affaires heeft gehad.

Er gaan in Nederland heel veel stellen uit elkaar. 40% van alle relaties eindigt in een scheiding. Het is in het belang van het kind dat ouders na een scheiding met elkaar blijven samenwerken. Regelgeving en wetgeving kan hieraan positief bijdragen.

Door te zorgen dat beide ouders gezag hebben en ook na een scheiding houden worden ouders gedwongen om met elkaar te blijven samenwerken en overleggen.

Over ouderlijk gezag zou helemaal geen discussie moeten zijn. Wanneer je een kind hebt samen betekent dit dat je ook samen beslissingen zult moeten nemen over dat kind. Of je dat nu leuk vindt of niet.

Maak Nederland weer een “Maakland”

Bekijk hier een uitzending van Buitenhof met als gast Roland Plasterk (PvdA) over de “eurocrisis” (een erg wijze politicus die het door de media af en toe goed moeilijk gemaakt wordt, maar dit lukt maar niet…)

https://www.npo.nl/buitenhof/27-05-2012/VPWON_1165548

Let op het zinnetje “het onvermogen van de politiek versus we moeten weer een maakindustrie gaan creëren”. Ik geloof niet dat deze journalistiek verslaggeefster Clairy Polak (als dochter van twee cabaretiers) zelf ooit iets aan handenarbeid heeft gedaan…

Roland Plasterk kan af en toe goed tegendraads zijn. Hij doet dit op basis van ontzettend veel wijsheid, kennis, inzicht en vooruit kunnen zien. Hij mist alleen net een stukje overtuigingskracht en overredingskracht en dus is zijn stem net niet sterk genoeg voor de hervormingen die op een bepaald moment in tijd wel nodig zijn.

Dat komt omdat zijn krachtdier De Vis is. De Vis streeft ook steeds weer naar harmonie en breekt dus niet door barrières heen.

Mp3’s met speciale tekens in de bestandsnaam spelen niet af op iPhone en iPad

Wanneer je Mp3’s gaat streamen naar je iPhone of iPad en er zit een speciaal (Unicode) teken in de URL die vertaald wordt naar een ASCII code (HTML special character) dan speelt het Mp3 bestand niet af op de iPhone en iPad. Je krijgt op de device een 404 – Not found HTML response terug. De oplossing is heel eenvoudig. Hernoem je Mp3 bestand.

European e-Competence Framework

Ik moest denken aan het goede ouderwetse functiegebouw dat we vroeger in de ICT hadden. Met functies als helpdeskmedewerker, tester, systeembeheerder, junior / medior / senior programmeur, functioneel en technisch ontwerper, informatieanalist, software architect en projectmanager. Vroeger groeide je van laag naar hoog. Maar tegenwoordig loopt alles door elkaar en hebben we allerlei creatieve nieuwe functies bedacht. En zijn we soms het spoor een beetje bijster in het vormgeven van een goed en professioneel softwareontwikkelingstraject. Maar er is goed nieuws. Want er is een Europese standaard opgesteld die voor iedereen toegankelijk is en die met competenties werkt. Het is een CEN norm geworden. Werken met competenties is wel slim, want dan heb je geen gezeur over functiehuizen en gebouwen en kun je heel goed werken met een systeem dat gebaseerd is op doorgroeien en doorontwikkelen. Die standaard heet het European-e-Competence-Framework.

Documenteren, wat is dat?

Ik weet niet wat het is, maar in welk projectteam ik ook terecht kom: er wordt of beroerd of helemaal niet gedocumenteerd. Ik heb het mezelf juist met de paplepel ingegoten dat je functies die je schrijft fatsoenlijk hoort te documenteren. Of ik nu in een VB, een .NET, een Java of een Python project bezig was: ik documenteerde mijn functies en classes goed en uitgebreid en had veel aandacht voor het genereren van nette en overzichtelijke documentatie. Want daar zijn hele mooie tools voor beschikbaar. Maar het lijkt erop dat de programmeurs in Nederland het niet zo nauw nemen met documenteren. Of zeg maar gerust totaal geen aandacht hebben voor het documenteren van hun code. En ik snap dat niet. Want alle goede programmeurs zijn gek van open source software. En raadplegen heel erg veel de documentatie van libraries die ze gebruiken. Want goede open source software is “goed” gedocumenteerd. Maar zelf documenteren ho maar. En er is ook altijd die verdraaide druk van een project (want er is geen poen voor) dat als excuus wordt gebruikt: er is geen tijd om te documenteren. Maar dat beïnvloed echt de duurzaamheid van een stuk software heel erg nadelig. En ook de overdraagbaarheid (naar andere ontwikkelaars) heel erg nadelig. Bij een goed stuk software hoort gewoon een goed stuk documentatie. En dat zou in geen enkel project mogen ontbreken. Het bijzondere is dat wanneer je aangeeft dat je een “aparte programmeur” bent, omdat je graag documenteert, dat men daar dan altijd oren naar heeft. “Wat fijn zeg” zegt men dan. Maar om de een of andere reden is er “nooit” aandacht (en tijd) voor in een project…

Ik heb een eigen Business Intelligence tool ontwikkeld, genaamd “Vique”, waarvoor ik destijds ook aardig goede documentatie heb opgesteld. Deze documentatie kun je hier bekijken. Ik was ook bezig met de ontwikkeling van een eigen backup oplossing. Ook hiervoor had ik nette documentatie opgesteld, deze kun je hier bekijken.

Stop using buildout

Ik heb de afgelopen jaren meerdere projecten gedaan waarbij buildout wordt ingezet voor het packagen van een project. Maar dat is niet slim. Want in die projecten werd ook steeds gebruik gemaakt van een CI (Continuous Integration) tool zoals Jenkins of Atlassian Bamboo. En die tools verlangen altijd shell scripts om installatie taken uit te voeren op servers. En die tools verzorgen echt op een hele mooie manier een deployment. En bovendien is pip heel erg goed in staat om Python packages te installeren en versies mee te beheren. En hiervoor heb je maar een paar eenvoudige commando’s nodig. En niet allerlei buildout scripts. Buildout maakt een project onnodig complex. En complexiteit moet je zoveel mogelijk proberen te vermijden. Dit lijkt echt een developer dingetje: leuk om complexiteit te introduceren.

Links:

Git workflow: merge policy versus rebase policy

Ik heb de afgelopen paar jaar in verschillende projecten meegewerkt waar Git als versiebeheer systeem wordt gebruikt. En in ieder project was er gezeur over de Git workflow. Over de manier van werken met branches, tags en releases wordt men het steeds wel eens. Maar over de manier van werken met commits niet. Dat is altijd gezeur. Er zijn op hoofdlijnen twee stromingen: merge policy en rebase policy. En de discussie kwam steeds uit op: laten we rebasen. En commits squashen. En dat is dom. Want de tooling die beschikbaar is (Github, Gitlab, Atlassian BitBucket enzovoorts) geeft ons een “merge” knop. Dus je kunt het allemaal op de commandline gaan doen als je wilt gaan rebasen. En bovendien is het “rebase policy” ook nog eens veel gevaarlijker, omdat je je versie geschiedenis van je broncode in je repository aan het tweaken bent. En als je het rebasen fout doet ben je je code gewoon kwijt. En Git is juist bedoeld om “dat” te voorkomen. De argumenten om voor rebasen te kiezen zijn steeds: dan zijn de pull requests beter te lezen, dan is de commit history veel schoner enzovoorts. Maar het heeft gewoon met een manier van werken te maken. Zorg dat je pull request niet teveel code bevat. En niet teveel commits bevat. En als dat wel zo is heb je dus aan een flink stuk code zitten werken, dat kan ook. Een stuk nieuwe functionaliteit dus. En als je dat alleen hebt gedaan dan kon je dat blijkbaar ook in je eentje, dus approve en merge zelf dan ook maar gewoon je pull request… En een extra “merge commit” in de commit history: so big deal…

Links: