Christine

Niet, dus. Ach ja. Vorige weel weer een kennis van straat geplukt omdat ik het 'zag'. Fijn gesprek gehad en hoop dat ze er iets aan heeft gehad. Verschil in definitie van "je", denk ik. Je kunt ook op de bank zitten met je zus en je vader en dan geheel tussen de wal en het schip vallen. Terwijl ze toch op aandringen van anderen op zondagavond in allerijl langs zijn gekomen.

Niet, dus.

Je zoon heeft niet gefaald. Ondernemen is per definitie risico nemen, en risico nemen betekent dat je een eindige kans op mislukking hebt. Zonder ondernemers zijn er geen banen in ons land, en loopt de economie vast. Het jammere is dat de meeste mensen zich dat niet realiseren. Zich niet realiseren dat zij een baan hebben omdat anderen hun nek hebben uitgestoken. De overheid profiteert van je ondernemerschap met het heffen van belasting en premies, maar zodra je bedrijf stopt, dan geven ze niet thuis. Dat is dom, want de feiten tonen aan dat ondernemers die opnieuw beginnen significant succeslvoller zijn dan ondernemers die voor het eerst ondernemen. Een vorm van kapitaalvernietiging dus, als je failliete ondernemers in de shit duwt. Je zoon moet niet bij de pakken neer zitten. Ik heb rare perioden meegemaakt, maar op het eind dacht ik altijd maar "het ergste wat er kan gebeuren is dat ik dakloos raak, en dan woon ik fijn buiten". Het is gelukkig (net) niet zo ver gekomen. Je zoon heeft jou, en z'n verdere familie, en z'n goede vrienden nu nodig. Spreek 'm moed in, vraag 'm te eten, stop 'm zo nu en dan wat toe. Het belangrijkste: communicatie met de buitenwereld is voor hem heel lastig. Bellen met een energiebedrijf over een openstaande rekening, dat is onmogelijk. Maar een goede vriend, of z'n vader, kan dat wel eenvoudig doen, die heeft er geen diepe emoties bij. Dat soort dingen is waar het mij indertijd het meest aan ontbrak: iemand die ff naar de belastingdienst belde. Ik wens je zoon veel sterkte, hoop dat z'n omgeving 'm overeind houdt, en als er praktische vragen zijn, weet dat de leden van HL altijd klaar staan om te helpen. En we zijn met heel veel.

Een van de zaken die TTIP wil regelen is dat als een product in de VS voor de markt is goedgekeurd, het dan automatisch ook in Europa verkocht mag worden. Als in de VS de crash eisen voor auto's lager zijn dan hier, krijgen we hier onveilige auto's op de weg. Als in de VS GMO is toegestaan en hier niet, krijgen we hier toch GMO producten op de markt. Als de Nederlandse overheid een product verbiedt omdat het onveilig is, kan de Amerikaanse fabrikant een zaak aanspannen tegen de NL overheid bij een soort geheime rechtbank die wordt gedomineerd door het bedrijfsleven. Daaruit gaan dan enorme schadeclaims volgen waartegen geen beroep mogelijk is. Voor een samenvatting van TTIP, kijk naar de laatste aflevering van "Zondag met Lubach" van vorig seizoen.

http://dilbert.com/strip/2015-09-11

Zoals Claudia de Breij net zei, "hij was een ontzettend leuke man". Wat ze bij Pauw ook allemaal zeiden was "nooit gemerkt dat 'ie depressief was, was altijd vrolijk". Ik denk dat dat geldt voor veel mensen die in perioden depressief zijn: je ziet het niet aan de buitenkant.

Dit stukje DWDD is vandaag actueel.

Een beetje uitleg in een video van Brenno de Winter.

Het heeft niks met "te goed" te maken. Meer met "als je over een paar tientjes al niet zelf een beslissing kan nemen, hoe kun je dan een bedrijf runnen, hoe kun je dan ondernemer zijn?" Maar goed, ieder zijn meug.

Ik denk dat een mededeling bij de oplevering "klant is zelf verantwoordelijk voor security updates" voldoende is. Een checklist is extra service van jouw kant (doen dus). En ik was serieus over het update-contract: klant betaalt jou per maand voor het up to date houden van de installatie. Voor CipherMail doen we dat ook: we testen alle externe security updates eerst zelf, en de klant krijgt de updates dan aangeboden. Als ze een maintenance contract hebben tenminste.

Enkele honderden euro's. En nu moet een heel forum zich buigen over de vraag of dat kan, om jou 100 euro al dan niet te laten besparen. Wat denk je dat de tijd kost van al die mensen die je vraag lezen, laat staan van de mensen die nadenken over een antwoord? Denk liever zelf nog even na, over sop en kool en zo.

Die ligt bij de beheerder van de site. Dat is meestal de organisatie van wie de site is. Die zal niet worden aangesproken op het bestaan van een zero day exploit in één van de tools of libraries die in de site worden gebruikt, maar wel op het niet onmiddellijk patchen ervan zodra een patch beschikbaar is. In het onderzoek dat we jaren geleden jaarlijks deden met WebWereld naar lekken in webmail systemen van providers vonden we bij iedere provider altijd een lek. Dat kon een nieuwe exploit zijn, een reeds bekende, of een programmeerfout van de beheerders. Een flink deel van de providers stuurde dan een bedankmail en patchte het onmiddellijk, maar de meer low end providers deden dat niet. Als na drie maanden het lek nog bestond (waarbij de mail van alle klanten gewoon op straat lag) dan kwam de provider met het slechte nieuws in Webwereld. Volgens de nieuwe wet zou die laatste groep providers de maximale boete krijgen (3 maanden is immers veel te lang). Het kan de beste gebeuren, zo'n lek. Microsoft en Google reageerden altijd sympathiek, en soms met het verzoek om het lek nog een paar dagen onder de pet te houden zodat ze snel een fix konden uitbrengen. Die zouden daar zeker geen boete voor krijgen, neem ik aan. Als jouw klant iets nalaat krijg jij geen boete. Mits je de klant verteld hebt dat ze updates voor de tools en libraries die je hebt gebruikt onmiddellijk aanbrengen. Voor jou zou het een dienstverlening kunnen zijn: voor een x bedrag per maand hou jij bij welke bugs en fixes er zijn in de tools die je gebruikt (dat moet je voor jezelf toch al bijhouden) en je mailt de klant als ze een update moeten doen. Dat is business, en daarmee dek je je in tegen aansprakelijkheid voor lekken en bugs. Dat is ook een tip aan TS: ga in zee met een partij die het patchen en fixen van je site als product aanbiedt.

Dat zegt ook niemand. Ik doelde meer op het zinnetje "komt zij eerst met duidelijke functionele omschrijving en schermen?" In Scrum gebruik je user stories die door de klant zijn gemaakt en op basis waarvan de functionaliteit wordt gebouwd, eerder in de zin van een mockup of prototype dan in de vorm van documenten. Niet dat ik voorstander ben van Scrum, overigens. Het maken van mockups en prototypen is wel wat TS zou helpen om snel te kunnen beoordelen wat er gebouwd wordt en of dat is wat gewenst is.

Dat is het probleem met data lekken. Niet dat ze er zijn, maar dat ze niet onmiddellijk verholpen worden.

Dat is het zelfde. Een datalek is een mogelijkheid voor een hacker om je systeem binnen te dringen. De verantwoordelijkheid voor het lek hoeft niet bij de eigenaar van het te hacken bedrijf te liggen. Het kan zijn dat je software gebruikt die als veilig te boek staat en door miljoenen servers wordt gebruikt, en die toch een lek bevat. Dat is wel 's gebeurd met openSSL. Iedereen heeft dat, of je het weet of niet, en toch was het lek.

Ik heb slechte ervaringen met het melden van ernstige datalekken bij bedrijven. Volgens het scenario - je vindt een ernstig lek in de webmail van een provider - je meldt dat keurig bij die provider - je krijgt een brief van de advocaat van de provider die je van hacking beschuldigt (gelukkig een minderheid van providers, de meeste sturen een bedankmailtje voor het melden)

Tegenwoordig wil iedereen met Scrum werken. Dan gaat wat je zegt niet op.

Ik wordt geen wijs uit de stukken (ligt aan mij, ik weet het) maar geldt de meldplicht voor de eigenaar van het lek, of ook voor anderen? Dus als ik een lek vind in de site van een bedrijf of overheidsinstantie die gevolgen heeft voor de privacy van personen, maar ik meld dat lek niet, kan ik daar dan last mee krijgen?

Precies. WP is veel beter dan het adhoc in elkaar geknutselde CMS van een developer. En als je een WP developer zoekt, probeer dan een check te doen of het iemand is die enige relevante kennis heeft, dat is het advies dat je uit de discussie hier kunt destilleren.

Ik hou wel van het overdonderende effect van vier verschillende. Maar ik begrijp je punt. Het was in dit geval een zich langzaam ontwikkelende emotie mijnerzijds.

Ach, joh! Dat meen je niet....

Ehm, tsja. Misschien het hele draadje nog 's lezen, en dan je eigen bijdrage nog 's heel precies lezen, en dan mijn reactie, en dan een kwartje, en dan misschien een "klonk!" ?

Het is moeilijk vrouwelijke programmeurs te vinden, ik heb er een keer eentje uit Kazakstan moeten halen omdat ik per se vrouwen in mijn team wilde. Dat komt omdat onze cultuur vindt dat meisjes niet moeten programmeren en niks met computers moeten willen. Dat lees je terug in bijdragen hier op HL.

"Snel" is een complex begrip in dezen. Ten eerste, zoals Joel Spolsky al 's heeft uigelegd in zijn blog, het verschil in productiviteit van programmeurs is hoger dan welk ander vak ook. De ene programmeur kan 10x sneller zijn dan de andere. Ik denk zelf dat Spolsky met dat getal aan de lage kant zit. Maar snelheid is wat anders dan productiviteit, gemeten aan goed product. Je kunt beter een developer hebben die iets in korte tijd bouwt en het blijft altijd goed werken, dan dat je een developer hebt die het nog sneller bouwt, maar die iedere week terug moet komen om fouten te verhelpen. Het leuke is, je hoeft meestal maar een snelle blik te werpen op source code van een project, en je weet of het hele project goed gebouwd is of niet.

Dat komt omdat alleen mannelijke programmeurs dat kunnen, vrouwelijke programmeurs kunnen niet inschatten. Of is dat niet wat je zegt?