De Devschuur Coffee Corner - Iteratie ➓

[gekkie]

incaz schreef op donderdag 30 juni 2016 @ 12:04:
Ik vond Laura Dekker in Expeditie Poolcirkel eigenlijk wel cool, en in tweede instantie vraag ik me ook af waarom we zo tegen haar zeiltocht waren. (Oh nee! Niet iets doen wat gaaf en avontuurlijk is, als je je ook te pletter kunt vervelen op school!) Had toch een beetje een 'boven het maaiveld'-gevoel, zelfs al dacht ik er op dat moment anders over.

En gekkie: vraag het je klanten Op een vriendelijke respectvolle manier. Beetje feedback daarover helpt vaak een boel.

Had ik gevraagd, zet de getallen op een rij (of geef me de id's van een serie dingen die niet kloppen dan kijk ik ze wel na). Maar nee allemaal vage en relatieve verwijzingen, naja retour afzender met de mededeling wat de headers zijn van de gegevens die die bij elkaar mag plukken en in excel mag mikken.

En laura, tsja wat was er minder gaaf aan geweest als ze het een jaar later had gedaan ?
Vooral een geld dingetje, want niet de eerste van die leeftijd, dus geen guiness book, dus minder publiciteit, dus minder geld. Achja gelukkig gaat iedereen tegenwoordig voor avontuur op het dak van een trein, alleen nog wachten tot de eerste net iets te ver met z'n hoofd boven het letterlijke maaiveld uitsteekt.

Yippie ruzie met de klant, fijn dat mijn voorganger semi-random numbers (ruis) een interpretatie heeft gegeven als zou het wat zijn, maar dat is niks ... dus wat eruit komt is onzin, maar de bug dat de onzin er niet goed bij opgeteld werd is wel verholpen, so shut up en hou de problemen bloody hell eens uit elkaar.
*grmbll*

[ Voor 11% gewijzigd door gekkie op 30-06-2016 12:58 ]

[OkkE]

Herkenbaar, van die meldingen als “Het werkt niet”.

Die schuif ik altijd weer direct terug met een notitie als “Meer info nodig” of soms gewoon “Cannot reproduce”.

Skyaero schreef op donderdag 30 juni 2016 @ 13:24:
Wat zijn we weer lekker klantvriendelijk....

In mijn geval nooit naar de klant, ik ontvang bug-reports altijd van een collega. :-) Maar als ik ze wel direct van een klant zou ontvangen, zou ik nog steeds om meer info vragen — wel op een vriendelijkere manier.

(Ik ben developer, ik vind dat mijn taak is het oplossen van bugs, niet het uitvinden wat de klant bedoelt.)

[ Voor 58% gewijzigd door OkkE op 30-06-2016 13:32 ]

[Skyaero]

Wat zijn we weer lekker klantvriendelijk....

[Swedish Clown]

ElkeBxl schreef op woensdag 29 juni 2016 @ 09:50:
[...]

Sweet! Maar: pics or it didn't happen!

Enigzins aan de late kant maar ook vandaag een lekker dagje op dak werken

Alex) schreef op woensdag 29 juni 2016 @ 10:13:
Stockholm

Hoe is jouw Zweeds inmiddels, Brakkie41?

Gaat aardig alleen helpt het niet dat mijn team multinationaal is en ik een Duitse vriendin heb en thuis dus ook Engels spreek. Maar ik kom een aardig eind wanneer het moet

[incaz]

OkkE schreef op donderdag 30 juni 2016 @ 13:18:
(Ik ben developer, ik vind dat mijn taak is het oplossen van bugs, niet het uitvinden wat de klant bedoelt.)

Reactie van klant: 'het is jullie taak om gewoon te zorgen dat het werkt.'
Zo'n houding faalt bijna altijd.

[Tjolk]

Mja, maar ik kan er wel inkomen hoor. Zeker als je in je bedrijfsproces hebt ingeregeld dat er iemand is de de contacten met de klant heeft en jij dat niet bent. Zo iemand moet dan filteren wat zinnig is en niet, en zonodig vragen om aanvullende informatie. Alles doorschuiven naar de developer is gewoon kansloos.

Heb het ook wel eens gehad hoor. Importtool gemaakt die alles tot in detail vailideert en controleert. Indien 1 veld ergens niet goed ingevuld: error, gooi terug en leg uit waarom.
Gebruiker: Die import werkt niet, ik krijg allemaal foutmeldingen
- Euh, ja, wat voor foutmeldingen dan?
Ja, heel het scherm vol. Error dit, error dat
- Ok, maar wat voor errors dan? Wat is de melding die je krijgt?
Ja dat weet ik niet hoor, dat heb ik niet gelezen
-

Die errors beschrijven dus exact de fout en welke input er wel verwacht wordt. Als ze dus gewoon hadden gelezen had er ook geen contact met mij gezocht hoeven te worden. Maar zelfs dan wordt het gewoon over de schutting gegooid. Kun je wel zeggen: "Het is jullie taak om te zorgen dat het werkt", maar een schroevendraaier werkt ook pas als je hem goed gebruikt. "Gewoon" werkt niets. Alles heeft een handleiding.

In alle jaren dat ik dit werk nu doe, kom ik minstens net zoveel pebcaks als echte bug tegen. En dan heb ik zo goed als geen contact met de klant.

[gekkie]

incaz schreef op donderdag 30 juni 2016 @ 14:03:
[...]


Reactie van klant: 'het is jullie taak om gewoon te zorgen dat het werkt.'
Zo'n houding faalt bijna altijd.

Neh in dit specifieke geval heb ik al een keertje of 10 uitgelegd dat het getal waar hij naar refereert dat dat net zo goed uit een random number generator zou kunnen komen.
Ik heb die interpretatie er niet aan gekoppeld en het juiste getal wel vinden is bepaald niet triviaal, sterker nog het is überhaupt de vraag of dat ooit gaat lukken.
Maar goed als je na 10x uitleg nog steeds langskomst met je eigen interpretatie dat het totale getal niet klopt omdat hij verkeerd op zou tellen terwijl ik dus al 10x heb verteld dat het optellen prima gaat, maar dat 1 van de onderliggende getallen random is, dan wordt de bijl inderdaad betrekkelijk bot. Dat je zelf in de utopie leeft dat het onderliggende getal wel wat zou zeggen en hoe je tot die utopie gekomen of gebracht bent dat weet ik niet, maar als je ooit een oplossing wil zal je toch eerst uit die utopie moeten.

Maar goed kwartjes vallen soms langzaam. En daarbij worden mensen die voor een dubbeltje geboren zijn überhaupt nooit een kwartje.

[incaz]

Ger schreef op donderdag 30 juni 2016 @ 14:22:
In alle jaren dat ik dit werk nu doe, kom ik minstens net zoveel pebcaks als echte bug tegen. En dan heb ik zo goed als geen contact met de klant.

Wat veel developers afdoen als gebruikersfouten zijn volgens mij zijn voorbeelden van slecht design, omdat de verwachting is dat de mens zich aan de technologie aanpast in plaats van andersom. Maar de gebruiker heeft een ander perspectief. Die wil iets wat werkt, niet iets wat gedoe op zich is.

Bijvoorbeeld: het is meestal niet bepaald gebruiksvriendelijk om een gebruiker een hele lijst met foutmeldingen te laten lezen. Gebruikers voelen zich gestoord in hun werk maar ook overweldigd doordat ze in een situatie zitten waar ze niet willen zijn - en het leven zou echt fijner worden als tech zich daar wat meer op in zou stellen. Dat geldt voor de programma's, maar zeker ook voor de devs die ermee werken. Zoveel projecten die de mist in gaan, gewoon omdat de technische ontwikkelaars niet echt willen leren van gebruikers.

Als tech meer zou uitstralen dat ze echt wel respect hebben voor gebruikers, zouden gebruikers namelijk ook echt minder gefrustreerd raken als het niet werkt - en juist dan nemen ze de tijd om goede bugreports te schrijven, of rustig de foutmeldingen door te lopen en te ontdekken dat ze het wel kunnen oplossen.

[Skyaero]

Slecht design, of slechte overdracht. Je kunt van de meeste klanten niet verwachten dat als je een tool (conform specs.) samen met een handleiding over de muur gooit, dat het allemaal wel goed komt.



Zoiets is een ideale kans om een stukje training aan te bieden aan de klant. Heb je direct een paar extra billable hours, minder tickets/support requests een tevreden klant die zich gewaardeerd en geholpen voelt en jou eerder zal aanbevelen.

[gekkie]

incaz schreef op donderdag 30 juni 2016 @ 14:35:
[...]


Wat veel developers afdoen als gebruikersfouten zijn volgens mij zijn voorbeelden van slecht design, omdat de verwachting is dat de mens zich aan de technologie aanpast in plaats van andersom. Maar de gebruiker heeft een ander perspectief. Die wil iets wat werkt, niet iets wat gedoe op zich is.

Bijvoorbeeld: het is meestal niet bepaald gebruiksvriendelijk om een gebruiker een hele lijst met foutmeldingen te laten lezen. Gebruikers voelen zich gestoord in hun werk maar ook overweldigd doordat ze in een situatie zitten waar ze niet willen zijn - en het leven zou echt fijner worden als tech zich daar wat meer op in zou stellen. Dat geldt voor de programma's, maar zeker ook voor de devs die ermee werken. Zoveel projecten die de mist in gaan, gewoon omdat de technische ontwikkelaars niet echt willen leren van gebruikers.

Als tech meer zou uitstralen dat ze echt wel respect hebben voor gebruikers, zouden gebruikers namelijk ook echt minder gefrustreerd raken als het niet werkt - en juist dan nemen ze de tijd om goede bugreports te schrijven, of rustig de foutmeldingen door te lopen en te ontdekken dat ze het wel kunnen oplossen.

Waarbij gebruikers dan weer vaak willen dat alles tailormade is voor hun ene specifieke gevalletje. Tsja that ain't gonna fly. Kortom wil de klant gedoe doordat er 1000 buttons zijn waar zijn dingetje ook tussen zit, of 1 button met een set generieke opties waarmee je naar believen jouw wens kunt samen stellen.

Maar goed in het bovenstaande importeren we gewoon de data en een paar maanden later wordt van mevrouw het verkeerde been geamputeerd .. hoe is dat nou toch zo gekomen .. ja we mochten geen foutmelding laten zien als de data ambigu was ... dus lang leve de randomizer.

Achja meeste van m'n klanten zijn op een gegeven moment wel geconditioneerd. Aangezien ik toch meestal wel een paar stappen verder denk dan ze zelf denken en daarmee gelijk al een berg keuzes rond de implementatie oplepel waar wel een keuze voor gemaakt moet worden, meestal zien ze het zelf altijd allemaal vrij simpel in en gaan ze alleen maar uit van de case waarin alles goed is, alles beschikbaar is etc.
Ik wil graag ook altijd een antwoord op de vraag wat men wil dat het doet als de shit de fan gaat hitten.

[ Voor 12% gewijzigd door gekkie op 30-06-2016 14:57 ]

[incaz]

Gekkie, als je gaat praten met mensen blijken ze meestal best voor rede vatbaar. Ik heb dat soort discussies echt wel gehad, over ronduit tegenstrijdige wensen die neerkwamen op dat wij magischerwijs moesten weten wat ze in gedachten hadden. Maar mijn ervaring is echt dat als je maar rustig door de stappen heenwerkt, mensen in verreweg de meeste gevallen echt wel kunnen begrijpen wat de afwegingen zijn.
Maar goed, dat begint met de bereidheid om de algehele minachting voor gebruikers los te laten.

[Tjolk]

incaz schreef op donderdag 30 juni 2016 @ 14:35:
[...]


Wat veel developers afdoen als gebruikersfouten zijn volgens mij zijn voorbeelden van slecht design, omdat de verwachting is dat de mens zich aan de technologie aanpast in plaats van andersom. Maar de gebruiker heeft een ander perspectief. Die wil iets wat werkt, niet iets wat gedoe op zich is.

Bijvoorbeeld: het is meestal niet bepaald gebruiksvriendelijk om een gebruiker een hele lijst met foutmeldingen te laten lezen. Gebruikers voelen zich gestoord in hun werk maar ook overweldigd doordat ze in een situatie zitten waar ze niet willen zijn - en het leven zou echt fijner worden als tech zich daar wat meer op in zou stellen. Dat geldt voor de programma's, maar zeker ook voor de devs die ermee werken. Zoveel projecten die de mist in gaan, gewoon omdat de technische ontwikkelaars niet echt willen leren van gebruikers.

Als tech meer zou uitstralen dat ze echt wel respect hebben voor gebruikers, zouden gebruikers namelijk ook echt minder gefrustreerd raken als het niet werkt - en juist dan nemen ze de tijd om goede bugreports te schrijven, of rustig de foutmeldingen door te lopen en te ontdekken dat ze het wel kunnen oplossen.

Ik snap an sich je punt, maar het gaat gewoon niet altijd op.

Om de import tool die ik eerder noemde als voorbeeld te nemen: die valideert op dingen als valide emailadres, een integer voor een prijs (in centen), integers met een min-/maxlength voor barcodes, etc. Die dingen worden niet voor niets heel strikt gevalideerd: shit in het systeem is shit voor de rest van het jaar in de rest van het proces. Een emailadres wat niet voldoet aan de validatie toch doorlaten is gewoon het probleem over de schutting naar zowel klant als klantenservice gooien. Barcode die niet klopt is probleem over de schutting naar het magazijn gooien. Prijzen proberen te interpreteren (oh, haal die punt maar weg, klopt vast wel) is vragen om foute prijzen. Et cetera.

Natuurlijk kun je van alles proberen te interpreteren. piet.snot.email.example.com zal waarschijnlijk wel bedoeld zijn als [e-mail]. Maar ja; [e-mail] kan natuurlijk ook. Een barcode voorzien van wat voorloopnullen is ook geen rocket science, maar wie zegt mij dat dit klopt? Men kan ook gewoon vergeten zijn één van de cijfers in te voeren.

In dergelijke processen is interpreteren gewoon vragen om problemen. Mijn voorganger had dat veel gedaan en er waren toen ook continu problemen in het magazijn en de klantenservice stond roodgloeiend. Toen ik de zaken wat meer structuur had gegeven waren er met enige regelmaat mopperende inkopers en accountmanagers, maar dat kwam doordat men dus bot gezegd lui was. Toen ik ze eenmaal opgevoed had en kon laten zien dat we minder manco's in het magazijn hadden en met een hogere omzet toch minder uitzendkrachten nodig hadden in zowel magazijn als klantenservice in de kerstperiode begonnen ze toch in te zien dat er een kern van waarheid in mijn strikte validatie zat.

Overigens werk ik er al anderhalf jaar niet meer hoor, maar dat terzijde. Kern van het verhaal: shit in = shit out.

[.oisyn]

incaz schreef op donderdag 30 juni 2016 @ 15:09:
Gekkie, als je gaat praten met mensen blijken ze meestal best voor rede vatbaar. Ik heb dat soort discussies echt wel gehad, over ronduit tegenstrijdige wensen die neerkwamen op dat wij magischerwijs moesten weten wat ze in gedachten hadden. Maar mijn ervaring is echt dat als je maar rustig door de stappen heenwerkt, mensen in verreweg de meeste gevallen echt wel kunnen begrijpen wat de afwegingen zijn.

Dat jij zoiets als vrouw überhaupt durft te posten

[ Voor 17% gewijzigd door .oisyn op 30-06-2016 15:34 ]

[incaz]

Ger schreef op donderdag 30 juni 2016 @ 15:28:
[...]
Prijzen proberen te interpreteren (oh, haal die punt maar weg, klopt vast wel) is vragen om foute prijzen. Et cetera.

Ik heb het niet over interpreteren gehad hoor?

Je kunt bv ook kiezen voor andere manieren van foutweergave, of het eerst analyseren van een preview, of een beter gui-design (een lijst met errorcodes is bv minder vriendelijk dan een visuele weergave die foute inputvelden precies subtiel genoeg weergeeft om wel snel inzichtelijk te zijn maar niet intimiderend over te komen.)
En ook een belangrijke stap: kijken naar het proces hoe de data uberhaupt bij die import komt. Meestal zit daar bv een stap waar je eigenlijk uberhaupt geen menselijke input wilt hebben en waar je het liefst zo rechtstreeks mogelijk aan je bron wilt zitten.

Etc.

Praten met mensen is ook dat je je niet blindstaart op 1 oplossing om te zeggen dat die oplossing niet kan... er zijn vaak meer wegen. En zelfs als je die wegen niet bewandelt, dan nog is het goed om te bedenken dat dat een afweging is tussen alternatieven, geen 'de gebruiker is gewoon te dom/lui'-situatie. Nee, je programma is niet vriendelijk genoeg. Soms is meer dan dat niet haalbaar/betaalbaar, maar verschuil je dan niet achter de gebruiker - dat is toch nog steeds een tekortschieten van de tech die niet aansluit bij de gebruiker, en niet andersom.

[gekkie]

incaz schreef op donderdag 30 juni 2016 @ 15:09:
Gekkie, als je gaat praten met mensen blijken ze meestal best voor rede vatbaar. Ik heb dat soort discussies echt wel gehad, over ronduit tegenstrijdige wensen die neerkwamen op dat wij magischerwijs moesten weten wat ze in gedachten hadden. Maar mijn ervaring is echt dat als je maar rustig door de stappen heenwerkt, mensen in verreweg de meeste gevallen echt wel kunnen begrijpen wat de afwegingen zijn.
Maar goed, dat begint met de bereidheid om de algehele minachting voor gebruikers los te laten.

Klopt en dat doe ik dan ook .. liefst face to face velletje papier erbij en klaar zo het probleem geschetst met een paar mogelijke oplossingsrichtingen en dan ben je er vrij snel uit idd.

Maar goed dat is in mijn onderhavige geval allemaal niet aan de hand, als dat zo was dan was het al opgelost.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[gekkie]

incaz schreef op donderdag 30 juni 2016 @ 15:56:
[...]
Nee, je programma is niet vriendelijk genoeg. Soms is meer dan dat niet haalbaar/betaalbaar, maar verschuil je dan niet achter de gebruiker - dat is toch nog steeds een tekortschieten van de tech die niet aansluit bij de gebruiker, en niet andersom.

Waarom niet, er is toch een keuze gemaakt van niet haalbaar/betaalbaar en daarmee zijn alle daaruit voortvloeiende consequenties toch geaccepteerd tot het moment dat je het over de haalbaar en betaalbaar (en bij behorende tijdsspanne) hebt gehad ?

* gekkie vraagt zich plosteling af of incaz in een dikke amerikaan met automagiër rijdt ?

[Tjolk]

incaz schreef op donderdag 30 juni 2016 @ 15:56:
[...]


Ik heb het niet over interpreteren gehad hoor?

Je kunt bv ook kiezen voor andere manieren van foutweergave, of het eerst analyseren van een preview, of een beter gui-design (een lijst met errorcodes is bv minder vriendelijk dan een visuele weergave die foute inputvelden precies subtiel genoeg weergeeft om wel snel inzichtelijk te zijn maar niet intimiderend over te komen.)
En ook een belangrijke stap: kijken naar het proces hoe de data uberhaupt bij die import komt. Meestal zit daar bv een stap waar je eigenlijk uberhaupt geen menselijke input wilt hebben en waar je het liefst zo rechtstreeks mogelijk aan je bron wilt zitten.

Etc.

Praten met mensen is ook dat je je niet blindstaart op 1 oplossing om te zeggen dat die oplossing niet kan... er zijn vaak meer wegen. En zelfs als je die wegen niet bewandelt, dan nog is het goed om te bedenken dat dat een afweging is tussen alternatieven, geen 'de gebruiker is gewoon te dom/lui'-situatie. Nee, je programma is niet vriendelijk genoeg. Soms is meer dan dat niet haalbaar/betaalbaar, maar verschuil je dan niet achter de gebruiker - dat is toch nog steeds een tekortschieten van de tech die niet aansluit bij de gebruiker, en niet andersom.

Nogmaals: ik begrijp je punt, maar het gaat gewoon niet altijd op.

Als je een tool schrijft waar ± 5 collega's mee moet werken (gemiddeld 1-2x per maand) dan kun je daar leuk úúren in gaan steken om het heel fancypancy weer te geven, maar dan vind ik zo'n melding duidelijk genoeg:

De volgende fouten zijn opgetreden:

- Error in rij 4: kolom email bevat onjuiste waarde "piet.snot.email.example.com"; geldig emailadres vereist
- Error in rij 5: kolom prijs bevat onjuiste waarde "24.950"; numerieke waarde in hele centen vereist
- etc.

De meldingen zijn duidelijk zat; ze wijzen naar de juiste locatie wáár de fout zit, geven aan welke waarde fout gerekend wordt en wat er verwacht wordt. Natuurlijk kan ik het ook in zachtroze op babyblauw weergeven, of door clippy vriendelijk laten vertellen wat er mis is, maar bottom line blijft gewoon: de invoer is onjuist, dit is het probleem, los het op.
En ja, als je dan een import doet met een paar honderd artikelen waarbij je consequent dezelfde fout maakt, dan krijg je een paar honderd foutmeldingen. Maar als je die foutmeldingen dan léést zijn ze eenvoudig op te lossen. Ga dan niet de boel wegklikken en melden dat het niet werkt.

[.oisyn]

Relevant filmpje:

.edit: deze

[ Voor 105% gewijzigd door .oisyn op 30-06-2016 16:40 ]

[incaz]

* incaz niet rijk genoeg is om d'r eigen auto te kiezen. Ding rijdt prima, me == happy. (En met airco en waarschuwingsdingetje als ik mijn lichten vergeet uit te zetten, me >= happy.)
Maar... als ik zou kunnen kiezen dan een kleine automagiër

@Ger / @gekkie, bottom line is dat je dan blijft denken vanuit hoe de technologie is en hoe gebruikers zouden moeten zijn, ipv andersom. Maar gebruikers zijn niet write-once progammeerbaar.

[dcm360]

incaz schreef op donderdag 30 juni 2016 @ 17:05:
@Ger / @gekkie, bottom line is dat je dan blijft denken vanuit hoe de technologie is en hoe gebruikers zouden moeten zijn, ipv andersom. Maar gebruikers zijn niet write-once progammeerbaar.

Als je echter het punt bereikt dat de applicatie netjes in een melding uitlegt wat er mis gaat, maar de gebruiker de melding negeert en meldt 'Het is stuk', ga je dat niet kunnen oplossen met de applicatie. Sterker nog, als een gebruiker door zijn baas betaald wordt voor het gebruiken van de applicatie, verwacht ik als ontwikkelaar er van dat hij of zij professioneel genoeg is om meldingen van het programma te lezen. Hieruit kan alsnog terugvloeien dat de applicatie aangepast moet worden, maar daar is meer voor nodig (en wordt er ook meer verwacht) dan slechts de melding 'het is stuk'.

[gekkie]

incaz schreef op donderdag 30 juni 2016 @ 17:05:
* incaz niet rijk genoeg is om d'r eigen auto te kiezen. Ding rijdt prima, me == happy. (En met airco en waarschuwingsdingetje als ik mijn lichten vergeet uit te zetten, me >= happy.)
Maar... als ik zou kunnen kiezen dan een kleine automagiër

Ah naja in iedergeval geen kans dat je geplet wordt door de usability van je eigen automagiër dan.
Want ik vraag me dan vervolgens weer af waar jij in die dicusssie staat

Is een waarschuwingslampje (sterker nog 2) en geluidje genoeg ... net als bij je verlichting ?

@Ger / @gekkie, bottom line is dat je dan blijft denken vanuit hoe de technologie is en hoe gebruikers zouden moeten zijn, ipv andersom. Maar gebruikers zijn niet write-once progammeerbaar.

Nope en beschikken juist daarom over de flexibiliteit om een hoop wat niet haalbaar en betaalbaar is te compenseren en zo tot een werkbaar totaal te komen ipv tot de constatering dat er helemaal niets mogelijk was. Het gaat echter fout als men inflexibel wil zijn EN ook niet wil betalen om meer haalbaar te maken (en de gewenste logica vervat in specs aan te leveren). En bij issues met interpretatie dan te accepteren wat het systeem (fuzzy of niet) heeft gedaan (goed danwel fout). Voorlopdig zijn fatsoenlijk lererende systemen nog no where near mensen met hun enorme hoeveelheid context waardoor een kleine beetje trial en error al vondoende is om bij te leren.

Maar goed moet je toch ook wel fan zijn van de PHP fuzzy logic, probeert toch ook vaak door te hobbelen terwijl een dikke vette error het probleem toch sneller duidelijker en beter zou definieren dan stilletjes aan doorhobbelen op basis van wazige interpretatie regeltjes die iemand ooit voor god mag weten wat voor reden heeft verzonnen (waarschijnlijk als shortcut).

[ Voor 17% gewijzigd door gekkie op 30-06-2016 17:51 ]

[Verwijderd]

Vaak zijn gebruikers gewoon te dom, en moet het ze maar 10x uitgelegd worden voordat ze het snappen. De domheid van sommige gebruikers kan je gewoon niet tegenop.

quote: Albert Einstein

Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.

[gekkie]

Verwijderd schreef op donderdag 30 juni 2016 @ 17:42:
Vaak zijn gebruikers gewoon te dom, en moet het ze maar 10x uitgelegd worden voordat ze het snappen. De domheid van sommige gebruikers kan je gewoon niet tegenop.
[...]

Mjah vaak kunnen of willen (ik heb vaak het idee willen, maar misschien ben ik bevooroordeeld met een technische achtergrond) een systeem (en achterliggende logica) niet eens oppervlakkig doorgronden. Tsja als je niet basaal snapt waarom bepaalde dingen zo zijn als ze zijn; en je ook weigert om een poging doet om je er enigzins in te verdiepen, dan wordt het ook nooit wat.
(bijvb door de notie te hebben dat een hoop van dat gezeik iedere dag met verkeerde emailadressen en verkeerde prijzen 1000x zou erg zou zijn als je het niet zou valideren. Dan zou je namelijk blij kunnen zijn met die melding ipv dat je je er tegen verzet, omdat over het geheel gezien die melding je helpt omdat mensen daar specifiek over nagedacht hebben die wel een systeem kunnen overzien).

[Swedish Clown]

gekkie schreef op donderdag 30 juni 2016 @ 18:01:
[...]

Mjah vaak kunnen of willen (ik heb vaak het idee willen, maar misschien ben ik bevooroordeeld met een technische achtergrond) een systeem (en achterliggende logica) niet eens oppervlakkig doorgronden. Tsja als je niet basaal snapt waarom bepaalde dingen zo zijn als ze zijn; en je ook weigert om een poging doet om je er enigzins in te verdiepen, dan wordt het ook nooit wat.
(bijvb door de notie te hebben dat een hoop van dat gezeik iedere dag met verkeerde emailadressen en verkeerde prijzen 1000x zou erg zou zijn als je het niet zou valideren. Dan zou je namelijk blij kunnen zijn met die melding ipv dat je je er tegen verzet, omdat over het geheel gezien die melding je helpt omdat mensen daar specifiek over nagedacht hebben die wel een systeem kunnen overzien).

Ik kan het een eindgebruiker die een typefout maakt niet kwalijk nemen dat hij/zij denkt "Hadden ze dat nou niet ff automatisch kunnen corrigeren voor me? Iedereen snapt toch wat ik hier bedoelde?"

Email validatie is een ander topic en dient IMHO heel losjes te worden genomen tenzij je de mogelijkheid hebt om een activatiemail of iets dergelijks te versturen. Heb je dat niet ga dan geen gekke regex lopen bouwen want je gaat geheid op je bek. Bouw eerder je systeem zo op dat je bounced e-mails kan afhandelen en daar op een slimme manier op in kan spelen.

Kritieke delen van het systeem dienen uiteraard zuivere input te krijgen en je boekhouding dient altijd strak op orde te zijn maar i.p.v. talloze validatieregels laat dat proces maar lekker op ze bek gaan. (Of denk ik nou teveel vanuit m'n Erlang hoedje?)

[gekkie]

Brakkie41 schreef op donderdag 30 juni 2016 @ 20:21:
[...]


Ik kan het een eindgebruiker die een typefout maakt niet kwalijk nemen dat hij/zij denkt "Hadden ze dat nou niet ff automatisch kunnen corrigeren voor me? Iedereen snapt toch wat ik hier bedoelde?"

Email validatie is een ander topic en dient IMHO heel losjes te worden genomen tenzij je de mogelijkheid hebt om een activatiemail of iets dergelijks te versturen. Heb je dat niet ga dan geen gekke regex lopen bouwen want je gaat geheid op je bek. Bouw eerder je systeem zo op dat je bounced e-mails kan afhandelen en daar op een slimme manier op in kan spelen.

Kritieke delen van het systeem dienen uiteraard zuivere input te krijgen en je boekhouding dient altijd strak op orde te zijn maar i.p.v. talloze validatieregels laat dat proces maar lekker op ze bek gaan. (Of denk ik nou teveel vanuit m'n Erlang hoedje?)

Hangt er wat mij betreft nogal af van de afweging waar je meer aan hebt:
- systeem wat direct op z'n bek gaat waarbij de bron gelijk duidelijk is en de kans op moeilijk tot niet herstelbare en relateren doorwerkende fouten eventueel jaren later is daarmee verminderd.
- systeem wat door hobbelt omdat op dat moment stoppen zwaardere gevolgen heeft dan het bovenstaande.

Bij een import in de meeste administratie systemen zal de 1e variant waarschijnlijk winnen.
Bij variant 2 zul je wil je het kunnen testen dus extra asserts moeten toevoegen die alleen tijdens testen en debuggen triggeren zodat je test faalt en je bugs er desondanks toch uit kunt halen.

[ Voor 6% gewijzigd door gekkie op 30-06-2016 20:46 ]

[incaz]

Brakkie41 schreef op donderdag 30 juni 2016 @ 20:21:
[...]

Kritieke delen van het systeem dienen uiteraard zuivere input te krijgen en je boekhouding dient altijd strak op orde te zijn maar i.p.v. talloze validatieregels laat dat proces maar lekker op ze bek gaan. (Of denk ik nou teveel vanuit m'n Erlang hoedje?)

Als eindgebruiker is het krijgen van een blanco 'an error occured somewhere, go guess' in elk geval al net zomin behulpzaam als een lijst met 1500 foutmeldingen. (Vooral niet als het ding eerst een nacht heeft staan zwoegen en pas breekt op de EOF of zoiets lulligs, en dan alle werk dat al gedaan is weer weggooit.)

Maar mijn punt was niet eens om voor te schrijven hoe die foutmeldingen gegeven moeten worden, maar vooral dat je daar heel veel keuzes en afwegingen in hebt, en dat als je gewoon even de tijd neemt om de gebruiker open te woord te staan, het allemaal positieve kanten op kan gaan. Ofwel omdat de gebruiker gerustgesteld is dat de errormeldingen geen paniek zijn - en hoe hij/zij ze kan lezen en er nuttige info uit te halen, ofwel door budgetruimte te krijgen om het aan te passen, ofwel door het proces beter te automatiseren..
En al die oplossingen blokkeer je als je er op voorhand vanuit gaat dat je programma goed en de gebruiker dom is.

Het begon allemaal met gebruikers die geen screenshot/tabel of andere nuttige debuginformatie opstuurden. De simpele oplossing: vraag het ze vriendelijk. Dan zijn de problemen meestal zo de wereld uit, OF je hebt goede informatie om mee verder te werken.

[gekkie]

incaz schreef op donderdag 30 juni 2016 @ 20:56:
[...]
Het begon allemaal met gebruikers die geen screenshot/tabel of andere nuttige debuginformatie opstuurden. De simpele oplossing: vraag het ze vriendelijk. Dan zijn de problemen meestal zo de wereld uit, OF je hebt goede informatie om mee verder te werken.

Ik mis toch nog de optie dat de klant weigert te geloven dat de gerapporteerde bug gefixt is door het in zijn ogen verkeerde getal te tonen en klanten dus niet snappen dat er meerdere bugs rond hetzelfde kunnen spelen (en dat het tevens handig is om die zaken uit elkaar te houden).
Whack a mole ... mep er eentje de grond in en te krijgt er een x aantal nieuwe voor terug

Maar goed in dit geval dus een patient die op basis van een aantal heldere symptomen na gericht onderzoek tegen de dokter na diagnose gaat roepen dat dat het allemaal niet kan zijn, tis toch echt de stand van de maan de horrorscoop (ja dubbel rrrrrrrr) en nog wat esoterisch geneuzel.

Maar goed strubbelingen om van een demo-project te komen tot iets want klanten ook daadwerkelijk kunnen gaan gebruiken, waarbij er kennelijk in de demofase de nodige shortcuts zijn genomen uit de afdeling "een random getal is ook een getal", tsja daar kom je in productie niet helemaal mee weg zeg maar, maar is ook niet altijd even eenvoudig te verhelpen.

[ Voor 60% gewijzigd door gekkie op 30-06-2016 21:46 ]

[armageddon_2k1]

gekkie schreef op donderdag 30 juni 2016 @ 21:22:
[...]
Maar goed strubbelingen om van een demo-project te komen tot iets want klanten ook daadwerkelijk kunnen gaan gebruiken, waarbij er kennelijk in de demofase de nodige shortcuts zijn genomen uit de afdeling "een random getal is ook een getal", tsja daar kom je in productie niet helemaal mee weg zeg maar, maar is ook niet altijd even eenvoudig te verhelpen.

Okee, dus als ik het goed begrijp heeft het te maken met hoe jullie het project aangepakt hebben Als dat beter aangepakt was was het voor de klant dan wel te begrijpen, of was de bug dan wel begrijpelijker te fixen?

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[ Voor 4% gewijzigd door armageddon_2k1 op 30-06-2016 22:18 ]

[gekkie]

armageddon_2k1 schreef op donderdag 30 juni 2016 @ 22:17:
[...]
Okee, dus als ik het goed begrijp heeft het te maken met hoe jullie het project aangepakt hebben Als dat beter aangepakt was was het voor de klant dan wel te begrijpen, of was de bug dan wel begrijpelijker te fixen?

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Ahh eindelijk the plot thickens .. waarom de opensource mesa/clover opencl driver meuk niet wil werken met opencv lib en de fglrx radoen driver wel. Zou fijn zijn als ik van die fglrx driver af kan .. onmogelijke fragiele closed source meuk.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[ Voor 11% gewijzigd door gekkie op 30-06-2016 23:05 ]

[Ryur]

gekkie schreef op donderdag 30 juni 2016 @ 22:53:
[...]

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Laat maar

[ Voor 65% gewijzigd door Ryur op 01-07-2016 08:16 ]

[OkkE]

incaz schreef op donderdag 30 juni 2016 @ 20:56:
[...]

Het begon allemaal met gebruikers die geen screenshot/tabel of andere nuttige debuginformatie opstuurden. De simpele oplossing: vraag het ze vriendelijk. Dan zijn de problemen meestal zo de wereld uit, OF je hebt goede informatie om mee verder te werken.

Agree.

Mijn reactie ging voornamelijk over het feit dat soms collega's en/of projectmanagers nog wel eens de neiging hebben om zulke bug-reports zonder verdere info gewoon door te schuiven in plaats van meer info te geven / vragen bij de klant. In zo'n geval gooi ik het gewoon terug naar hun (dus niet naar de klant) met de melding “need more info”.

[Tjolk]

incaz schreef op donderdag 30 juni 2016 @ 17:05:
@Ger / @gekkie, bottom line is dat je dan blijft denken vanuit hoe de technologie is en hoe gebruikers zouden moeten zijn, ipv andersom. Maar gebruikers zijn niet write-once progammeerbaar.

Mja, prima, nogmaals: in theorie heb je gelijk, maar ik zie werkelijk niet hoe je een dergelijk probleem in de praktijk zou willen oplossen zonder foutmeldingen. Anders gesteld:

• Incaz geeft een foutmelding: Ger denkt vanuit de technologie in plaats vanuit de gebruiker
• Incaz stuurt Ger terug.
• Ger zit in een situatie waar hij niet wil zijn.
• Het zou fijner zijn als Incaz zich daar wat meer op zou instellen.

In plaats van mij een foutmelding te geven, geef me dan eens aan hoe jij het zou oplossen.

[wackmaniac]

Pfff, begint hier meer en meer de Project Managers Corner te worden

[Robicide]

Nieuw topic "de shitpraktijken van projectmanagers"?

[mbarie]

legacy frameworks.... (Zend 1). Geklier met joins en automagische quotes die toegevoegd worden op verkeerde plek en een database link reference in de query die getruncate wordt. Alles wat je zorgen zou moeten wegnemen wordt hier moeilijk gemaakt

[ Voor 14% gewijzigd door mbarie op 01-07-2016 10:28 ]

[OkkE]

We kregen de vraag van een klant of we een oud systeem (niet door ons gemaakt) eens konden bekijken, dit werd letterlijk zo geprint op de pagina na het verkeerd invullen van user/pass:

.

code:

SELECT * FROM gebruikers WHERE `user` = 'admin' AND `email` LIKE 'Password1' LIMIT 0,1

mbarie schreef op vrijdag 01 juli 2016 @ 10:44:
email like password?

Yes, wat je invult in het password veld wordt vergeleken met de `email` column in de database d.m.v LIKE. Verder wordt er ook NIETS geescaped. Dus een OR 1=1 en je bent binnen.

[ Voor 37% gewijzigd door OkkE op 01-07-2016 11:46 ]

[mbarie]

email like password?

[gekkie]

OkkE schreef op vrijdag 01 juli 2016 @ 10:33:
We kregen de vraag van een klant of we een oud systeem (niet door ons gemaakt) eens konden bekijken, dit werd letterlijk zo geprint op de pagina na het verkeerd invullen van user/pass:

.

code:

SELECT * FROM gebruikers WHERE `user` = 'admin' AND `email` LIKE 'password' LIMIT 0,1

Kijk dat is weer opbeurend nieuws .. het kan toch nog altijd erger dan waar ik me mee bezig mag houden

[Robicide]

OkkE schreef op vrijdag 01 juli 2016 @ 10:33:

code:

SELECT * FROM gebruikers WHERE `user` = 'admin' AND `email` LIKE 'Password1' LIMIT 0,1

Manmanman, alsof je de sleutel OP de mat hebt gelegd.

[Antrax]

Die LIKE is wel echt killer.

Robicide schreef op vrijdag 01 juli 2016 @ 11:30:
Manmanman, alsof je de sleutel OP de mat hebt gelegd.

Wat hij zegt

[Firesphere]

incaz schreef op donderdag 30 juni 2016 @ 17:05:
* incaz niet rijk genoeg is om d'r eigen auto te kiezen. Ding rijdt prima, me == happy. (En met airco en waarschuwingsdingetje als ik mijn lichten vergeet uit te zetten, me >= happy.)
Maar... als ik zou kunnen kiezen dan een kleine automagiër

@Ger / @gekkie, bottom line is dat je dan blijft denken vanuit hoe de technologie is en hoe gebruikers zouden moeten zijn, ipv andersom. Maar gebruikers zijn niet write-once progammeerbaar.

Ik realiseer me ineens dat jij vrouw bent... Wist het wel, alleen nooit bij stil gestaan tot ik dit las

[mbarie]

Als ik maandag heel de dag met staartjes in loop krijg ik 10E van een collega. Een vrouwelijke collega zal de m'n staartjes verzorgen.

Er is maandag alleen wel review en retro en loop ik door diverse gebouwen. Ach, is eigenlijk wel grappig.

[ElkeBxl]

mbarie schreef op vrijdag 01 juli 2016 @ 14:04:
Als ik maandag heel de dag met staartjes in loop krijg ik 10E van een collega. Een vrouwelijke collega zal de m'n staartjes verzorgen.

Pics or it didn't happen!

Wear it with pride!

[Firesphere]

mbarie schreef op vrijdag 01 juli 2016 @ 14:04:
Als ik maandag heel de dag met staartjes in loop krijg ik 10E van een collega. Een vrouwelijke collega zal de m'n staartjes verzorgen.

Er is maandag alleen wel review en retro en loop ik door diverse gebouwen. Ach, is eigenlijk wel grappig.

Just do it. Fuck the system.

[Alex)]

Robicide schreef op vrijdag 01 juli 2016 @ 09:44:
Nieuw topic "de shitpraktijken van projectmanagers"?

Met stip op 1...

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[Merethil]

Alex) schreef op vrijdag 01 juli 2016 @ 14:29:
[...]


Met stip op 1...

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[incaz]

Firesphere schreef op vrijdag 01 juli 2016 @ 12:56:
[...]

Ik realiseer me ineens dat jij vrouw bent... Wist het wel, alleen nooit bij stil gestaan tot ik dit las

Ach. Er zijn ook mensen die niet weten dat jij in Australie woont.

Toch waren er wel wat bedekte toespelingen op gegeven hoor, zoals van .oisyn:

Dat jij zoiets als vrouw überhaupt durft te posten

Ik geef toe, het is subtiel, maar het was een hint.

[Firesphere]

incaz schreef op vrijdag 01 juli 2016 @ 14:57:
[...]




Ach. Er zijn ook mensen die niet weten dat jij in Australie woont.

Toch waren er wel wat bedekte toespelingen op gegeven hoor, zoals van .oisyn:

[...]


Ik geef toe, het is subtiel, maar het was een hint.

Haha, zoals ik zei, ik wist het wel, maar nooit bij stil gestaan! Gewoon even gek om het toch zo hard te realiseren. Verandert voor mij niets.
(En ik woon niet in Australie Ik woon in New Zealand )

[gekkie]

Aan de toiletten hoeft ook niks te veranderen tegenswoordigs wel zo makkelijk

[Swedish Clown]

mbarie schreef op vrijdag 01 juli 2016 @ 14:04:
Als ik maandag heel de dag met staartjes in loop krijg ik 10E van een collega. Een vrouwelijke collega zal de m'n staartjes verzorgen.

Er is maandag alleen wel review en retro en loop ik door diverse gebouwen. Ach, is eigenlijk wel grappig.

Ga een stap verder en vraag wat ze over hebben voor Pippi Langkous vlechtjes!

[Merethil]

Brakkie41 schreef op vrijdag 01 juli 2016 @ 15:50:
[...]


Ga een stap verder en vraag wat ze over hebben voor Pippi Langkous vlechtjes!

200 euro en een jurk later....

[azerty]

Firesphere schreef op vrijdag 01 juli 2016 @ 15:01:
(En ik woon niet in Australie Ik woon in New Zealand )

TIL

spoiler:

[Mercatres]

azerty schreef op vrijdag 01 juli 2016 @ 15:59:
[...]


TIL

spoiler:

spoiler:

Ja, want hij heeft dat nog nóóit gezegd

[azerty]

Goedemorgen iedereen!

* azerty zet een thermos met koffie, een thermos met chocolademelk en een thermos met thee klaar voor de gegadigden (behalve voor gekkie). Ook Firesphere wordt niet vergeten: een goed gekoeld Belgisch biertje staat voor hem klaar.

[Ryur]

Mogge. Nu een dagje documenteren voor mij
Laatste documentatie voor school was nog niet goedgekeurd, dus hele weekendplannen weg.

Maar als het goed is, is dit mijn laatste vak!

[Laurens-R]

Zo en we gaan eens even vandaag flink verhuisdozen inpakken

[Matis]

Net via TransIP een wildcard SSL certificaat besteld.
Al voor het toplevel domein werkend. Straks voor alle virtualhosts de zut aanpassen

[Gamebuster]

Phoenix framework is echt wel super cool hoor.

[Matis]

Gamebuster schreef op zaterdag 02 juli 2016 @ 21:06:
Phoenix framework is echt wel super cool hoor.

Productive. Reliable. Fast.

A productive web framework that
does not compromise speed and maintainability.

Klinkt wederom als een dertien in een dozijn...

[Ryur]

Matis schreef op zaterdag 02 juli 2016 @ 22:19:
[...]


[...]

Klinkt wederom als een dertien in een dozijn...

Qua framework zelf is het weinig interessants (vind ikzelf).

Ik vind het vooral tof dat het met Elixir is! Vind Phoenix erg lijken op Ruby on Rails, maar dan met Elixir.
Zijn ook redelijk wat RoR programmeurs naar Phoenix overstapt.

[Gamebuster]

Het is gemaakt door mensen uit de Rails wereld dus de gelijkenis is te verklaren. Er zijn echter keuzes gemaakt die de magic weghalen en alles vrij expliciet maakt, zonder dat je te maken krijgt met boilerplate. Dit maakt het veel beter te onderhouden en te begrijpen.

Verder is het grotendeels stateless en functioneel; je kan ieder component als een functie in een one-liner aanroepen.

Tot slot is het ook nog eens heel modulair; je kan heel makkelijk code verschuiven omdat de dependencies allemaal dezelfde kant op wijzen en het stateless is.

[RayNbow]

Interessante reclame op de frontpage deze morgen...

[Gamebuster]

Altijd mooi.

[kenneth]

Morgen is vandaag
War is peace
utf-8 is 8859-1

[Douweegbertje]

kenneth schreef op zondag 03 juli 2016 @ 09:06:
Morgen is vandaag
War is peace
utf-8 is 8859-1

Haha, dit is gewoon geniaal

[Niekfct]

Meh, ik denk ik ga eens wat integration tests schrijven voor m'n Kotlin android app.
Krijg je dit:

code:

println(user)
println("login=${user.login}")

.. met als output:

code:

TestUser(login=login, id=0, avatarUrl=avatarUrl, organizationsUrl=organizationsUrl, ...)
login=organizationsUrl

[Rutix]

Aangezien Azerty nog niet wakker is blijkbaar

/me Rutix zet een thermos met koffie, een thermos met chocolademelk en een thermos met thee klaar voor de liefhebbers.

[Ealanrian]

Zo weer terug na twee weken in de bergen. Nu maar weer rustig opstarten en kijken wat er te doen is.

[mbarie]

ElkeBxl schreef op vrijdag 01 juli 2016 @ 14:08:
[...]

Pics or it didn't happen!

Wear it with pride!

Firesphere schreef op vrijdag 01 juli 2016 @ 14:29:
[...]

Just do it. Fuck the system.

Brakkie41 schreef op vrijdag 01 juli 2016 @ 15:50:
[...]


Ga een stap verder en vraag wat ze over hebben voor Pippi Langkous vlechtjes!

Het valt best mee. Vanmiddag nog even de sprint review presenteren

[farlane]

mbarie schreef op maandag 04 juli 2016 @ 09:09:
[...]
Het valt best mee.

Ja hoor, valt best mee.

[mbarie]

Een zekere mate van schaamteloosheid doet wonderen. Hebben collega's ook een pleziertje op werk, ik vind 't wel grappig voor een keer. Weddenschap afsluiten doen ze in ieder geval niet nog een keer

[Jegorex]

mbarie schreef op maandag 04 juli 2016 @ 09:18:
Weddenschap afsluiten doen ze in ieder geval niet nog een keer

Of juist wel, als ze het die paar euro waard vinden

[Oxidda]

mbarie schreef op maandag 04 juli 2016 @ 09:09:
[...]


[...]


[...]


Het valt best mee. Vanmiddag nog even de sprint review presenteren
[afbeelding]

Valt best wel mee

[Swedish Clown]

mbarie schreef op maandag 04 juli 2016 @ 09:09:
[...]


[...]


[...]


Het valt best mee. Vanmiddag nog even de sprint review presenteren
[afbeelding]

+mucho voor pic!

[azerty]

Rutix schreef op maandag 04 juli 2016 @ 06:43:
Aangezien Azerty nog niet wakker is blijkbaar

/me Rutix zet een thermos met koffie, een thermos met chocolademelk en een thermos met thee klaar voor de liefhebbers.

Is dat niet het bewijs dat het géén bot is?

[mbarie]

azerty schreef op maandag 04 juli 2016 @ 11:05:
[...]


Is dat niet het bewijs dat het géén bot is?

Of gewoon slecht geschreven . Of bewuste randomization om wel/niet te posten.

[ Voor 11% gewijzigd door mbarie op 04-07-2016 11:07 ]

[azerty]

mbarie schreef op maandag 04 juli 2016 @ 11:07:
[...]

Of gewoon slecht geschreven . Of bewuste randomization om wel/niet te posten.

Hmm, dat hou ik dan wel in het achterhoofd als ik hem daadwerkelijk maak

[farlane]

mbarie schreef op maandag 04 juli 2016 @ 09:18:
Een zekere mate van schaamteloosheid doet wonderen.

Was geintje natuurlijk

[Rutix]

mbarie schreef op maandag 04 juli 2016 @ 09:09:
[...]


[...]


[...]


Het valt best mee. Vanmiddag nog even de sprint review presenteren
[afbeelding]

Ik had het erger vewacht .

azerty schreef op maandag 04 juli 2016 @ 11:05:
[...]


Is dat niet het bewijs dat het géén bot is?

Of ik was gewoon eerder dan de bot en hij heeft herkend dat er al gepost is.

[incaz]

code:

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  [e-mail]
    host x.x.x.x [x.x.x.x]
    SMTP error from remote mail server after end of data:
    550 The content of this message looked like spam.

Mijn doorsturen van een phishing mail naar het adres daarvoor faalt omdat het op spam lijkt... Ehmm....

Heb nou nog niet helemaal duidelijk of het mijn smtp is die het blockt, of het ontvangstadres dat het weert, maar beide lijken me nogal problematisch
(Heb ook niet veel behoefte om aangemerkt te worden door automatische detection software omdat ik valse mails doorstuur naar meldpunten.)

[Rutix]

incaz schreef op maandag 04 juli 2016 @ 14:11:

code:

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  [e-mail]
    host x.x.x.x [x.x.x.x]
    SMTP error from remote mail server after end of data:
    550 The content of this message looked like spam.

Mijn doorsturen van een phishing mail naar het adres daarvoor faalt omdat het op spam lijkt... Ehmm....

Heb nou nog niet helemaal duidelijk of het mijn smtp is die het blockt, of het ontvangstadres dat het weert, maar beide lijken me nogal problematisch :=
(Heb ook niet veel behoefte om aangemerkt te worden door automatische detection software omdat ik valse mails doorstuur naar meldpunten.)

Ik stuur ze nooit door. Ik pak altijd de raw message (dus met de headers ect.) en plak die altijd in de email naar het meldpunt .

[azerty]

incaz schreef op maandag 04 juli 2016 @ 14:11:

code:

... from remote mail server ...

Mij lijkt het duidelijk welke server er voor verantwoordelijk is

[gekkie]

Hmm als ik al die mails door zou moeten gaan sturen, dan ben ik nog wel even bezig
Wel suf als ze dan een filter hebben zitten op hun meld-adres, kunnen ze natuurlijk wel in de media roepen dat ze als SNS-bank relatief weinig meldingen binnen krijgen

[ Voor 50% gewijzigd door gekkie op 04-07-2016 15:15 ]

[mbarie]

Makin' money while I'm making money dawg.

E10,92.

edit:
Iedereen heeft er even goed om gelachen, al met al was dat eigenlijk veel leuker

[ Voor 48% gewijzigd door mbarie op 04-07-2016 16:58 ]

[azerty]

Goedemorgen iedereen!

* azerty zet een thermos met koffie, een thermos met chocolademelk en een thermos met thee klaar voor de gegadigden (behalve voor gekkie). Ook Firesphere wordt niet vergeten: een goed gekoeld Belgisch biertje staat voor hem klaar.

[mbarie]

Tnx, ik pak zelfs nog even een tweede. Vandaag weer werken met mn eigen haar.

[Merethil]

mbarie schreef op dinsdag 05 juli 2016 @ 08:19:
Tnx, ik pak zelfs nog even een tweede. Vandaag weer werken met mn eigen haar.

Heb je gisteren dan iemand anders z'n haar op gehad? Gadver

[Firesphere]

Bijna de hele dag gespendeerd aan onze junior uitleggen/leren hoe dingen werken. Ik was vergeten hoe verschrikkelijk vermoeiend het is om niet op de autopilot dingen te kunnen doen.

[gekkie]

Berg impliciete kennis die je toch hebt die je nu ineens expliciet mag gaan overdragen omdat blijkt dat het zonder toch niet helemaal gesnapt wordt ?

[Firesphere]

gekkie schreef op dinsdag 05 juli 2016 @ 09:27:
Berg impliciete kennis die je toch hebt die je nu ineens expliciet mag gaan overdragen omdat blijkt dat het zonder toch niet helemaal gesnapt wordt ?

Jep, veel dingen doe je vaak op de autopilot. Het uitleggen aan iemand die het nog nooit eerder gedaan heeft is echt ook even een stap terug en naar je eigen methodes kijken.

Leuk om te doen, daar niet van, maar het is vrij vermoeiend

[Antrax]

Deze update is zeer welkom!

[Douweegbertje]

mbarie schreef op maandag 04 juli 2016 @ 11:07:
[...]

Of gewoon slecht geschreven . Of bewuste randomization om wel/niet te posten.

haha we hadden het laatst over een bot maken met iemand die weinig PR's reviewed. Dat we een bot maken die dan PR's doorneemt en dan op een random line iets neer zet als: "Do you really need to use this?". of op een andere reactie een "+1" neerzet

[azerty]

Goedemorgen iedereen!!

* azerty zet een thermos met koffie, een thermos met chocolademelk en een thermos met thee klaar voor de gegadigden (behalve voor gekkie). Ook Firesphere wordt niet vergeten: een goed gekoeld Belgisch biertje staat voor hem klaar.

[Geerrrt]

Iemand nog honger?

* Geerrrt flikkert een tree met worstenbroodjes naar binnen

[ Voor 5% gewijzigd door Geerrrt op 06-07-2016 09:55 ]

[EddoH]

GeertJam schreef op woensdag 06 juli 2016 @ 09:55:
Iemand nog honger?

* EddoH flikkert een tree met worstenbroodjes naar binnen

+



?

[TheNephilim]

https://textfac.es/ (ง'̀-'́)ง

[ Voor 49% gewijzigd door TheNephilim op 06-07-2016 10:11 ]

[jip_86]

EddoH schreef op woensdag 06 juli 2016 @ 10:08:
[...]


[afbeelding]

+

[afbeelding]

?

=

Logisch toch

[EddoH]

jip_86 schreef op woensdag 06 juli 2016 @ 10:45:
[...]

=
[afbeelding]
Logisch toch

[Ryur]

En ik ben nu ook geslaagd Happy me

[azerty]

Ryur schreef op woensdag 06 juli 2016 @ 11:10:
En ik ben nu ook geslaagd Happy me

Gratz. Ik heb het mijne gisteren ook met succes afgelegd