De Devschuur Coffee Corner - Iteratie ⓫

[Jan_V]

Neko Koneko schreef op donderdag 1 juni 2017 @ 22:49:
Kleine applicatie die gebruik maakt van mongo Db omzetten naar sql... Wat een pokkeklus snap ook niet dat mijn voorganger dat ooit een goed idee heeft gevonden.

Waarschijnlijk omdat het enkele jaren geleden (nog steeds trouwens...) hip was om alles in een NoSQL database te stoppen.
Een paar projecten geleden had iemand dat ook gedaan in een project waar ik ook aan mee moest helpen. Dat was dan RavenDB, maar sloeg helemaal nergens op om een dergelijke database te gebruiken. We werkten namelijk alleen met relationele data

[Neko Koneko]

Jan_V schreef op vrijdag 2 juni 2017 @ 07:21:
[...]

Waarschijnlijk omdat het enkele jaren geleden (nog steeds trouwens...) hip was om alles in een NoSQL database te stoppen.
Een paar projecten geleden had iemand dat ook gedaan in een project waar ik ook aan mee moest helpen. Dat was dan RavenDB, maar sloeg helemaal nergens op om een dergelijke database te gebruiken. We werkten namelijk alleen met relationele data

Ik denk dat mijn voorganger gewoon wat wilde experimenteren met een NoSQL database inderdaad maar het ding is zo onlogisch opgebouwd dat wanneer er wat mis gaat, ik een dag kwijt ben om uit te zoeken waar het mis is gegaan. In een SQL database zou ik het in een paar minuten kunnen vinden.

Vervelende is gewoon dat het wel een belangrijke tool in ons productie proces is dus als ik dit niet goed doe, kunnen we mogelijk een tijdje geen nieuwe software aan onze klanten leveren No pressure, no pressure Ik denk sowieso dat dit een lange-termijn dingetje wordt, terwijl ik oorspronkelijk hoopte het in een week om te kunnen zetten. De data migreren naar SQL dat heb ik inmiddels voor elkaar, maar die hele applicatie is qua werking zo verweven met die Mongo meuk dat het helaas niet een kwestie is van even de database verwijzing omgooien

Nu heeft mijn voorganger toen ik zijn functie overnam wel aangegeven dat het niet de beste applicatie is die hij ooit geschreven heeft maar dit had ik niet verwacht

Ik kan aan de andere applicatie die ik van hem heb overgenomen wel zien wanneer hij iets nieuws had ontdekt dat hij wilde proberen. Hij is begonnen met ASP WebForms maar wel met MVC, Prototype JS (naast jQuery/Bootstrap), opeens kom ik Knockout tegen, eigen Javascript om modals te maken (niet de standaard Bootstrap modals, dat zou te makkelijk zijn), dan weer dit, dan weer dat... Ik heb veel geleerd in de pak hem beet anderhalf jaar dat ik aan dit pakket werk ben straks van alle markten thuis

[cracking cloud]

Neko Koneko schreef op vrijdag 2 juni 2017 @ 08:59:
[...]

Hij is begonnen met ASP WebForms maar wel met MVC, Prototype JS (naast jQuery/Bootstrap), opeens kom ik Knockout tegen, eigen Javascript om modals te maken (niet de standaard Bootstrap modals, dat zou te makkelijk zijn), dan weer dit, dan weer dat...

"Aahh dat kan mij ook gebeuren" YouTube: The White Cowboy: De Kerkgangers

[ Voor 3% gewijzigd door cracking cloud op 02-06-2017 09:13 ]

[ElkeBxl]

Neko Koneko schreef op vrijdag 2 juni 2017 @ 08:59:
[...]

Nu heeft mijn voorganger toen ik zijn functie overnam wel aangegeven dat het niet de beste applicatie is die hij ooit geschreven heeft maar dit had ik niet verwacht

Ah disclaimers Het zijn de previews van het "oh shit wat is dit..." moment dat onvermijdelijk zal plaatsvinden.

[gekkie]

Neko Koneko schreef op vrijdag 2 juni 2017 @ 08:59:
[...]
De data migreren naar SQL dat heb ik inmiddels voor elkaar, maar die hele applicatie is qua werking zo verweven met die Mongo meuk dat het helaas niet een kwestie is van even de database verwijzing omgooien

Is dat niet de essentie van het hele noSQL gebeuren ?
Schema niet in de DB maar in de applicatie "forceren".
Constraints idem ditto.
Dus ipv van een single point, alles lekker uitgespreid in je applicatie code.
Omdat er in de DB minder kan, lekker bakken data overvissen naar de applicatie en denken dat jij efficientere algoritmen kan verzinnen dan dedicated database guru's.

Ik heb het noSQL verhaal eenmalig eens geprobeerd bij een eerste project opzetje .. in het begin leek het allemaal wel wat.
Op zich allemaal vrij gauw opgezet, eerste eenvoudige queries met eenvoudige data zitten er lekker gauw in.
Maar dan heb je er de nodige uren al inzitten .. en dan begint het drama, je wilt wat complexere queries doen .. ow wat een hell, en terug naar SQL wil je in eerste instantie ook niet wat je hebt nu al geinvesteerd in dit .. dus je gaat door en de gedrochten worden steeds groter .. en groter en groter ...
(en toen zat ik met een deuntje in het hoofd)

[Neko Koneko]

gekkie schreef op vrijdag 2 juni 2017 @ 09:20:
[...]

Is dat niet de essentie van het hele noSQL gebeuren ?
Schema niet in de DB maar in de applicatie "forceren".
Constraints idem ditto.
Dus ipv van een single point, alles lekker uitgespreid in je applicatie code.
Omdat er in de DB minder kan, lekker bakken data overvissen naar de applicatie en denken dat jij efficientere algoritmen kan verzinnen dan dedicated database guru's.

Ik heb het noSQL verhaal eenmalig eens geprobeerd bij een eerste project opzetje .. in het begin leek het allemaal wel wat.
Op zich allemaal vrij gauw opgezet, eerste eenvoudige queries met eenvoudige data zitten er lekker gauw in.
Maar dan heb je er de nodige uren al inzitten .. en dan begint het drama, je wilt wat complexere queries doen .. ow wat een hell, en terug naar SQL wil je in eerste instantie ook niet wat je hebt nu al geinvesteerd in dit .. dus je gaat door en de gedrochten worden steeds groter .. en groter en groter ...
(en toen zat ik met een deuntje in het hoofd)

Dat is voor mij dus de reden om het maar om te zetten naar SQL, het andere alternatief is om met Mongo te leren werken en daar voel ik gewoon weinig voor. Ik heb het voor mijn werkzaamheden niet nodig en dit is een applicatie die in productie stabiel moet kunnen draaien en dan moet ik als er een probleem is dat probleem wel op kunnen lossen. Het bekende "kost nu veel tijd maar die win ik op termijn veelvoudig terug" verhaaltje

[ZaZ]

gekkie schreef op vrijdag 2 juni 2017 @ 09:20:
[...]

Is dat niet de essentie van het hele noSQL gebeuren ?
Schema niet in de DB maar in de applicatie "forceren".
Constraints idem ditto.
Dus ipv van een single point, alles lekker uitgespreid in je applicatie code.
Omdat er in de DB minder kan, lekker bakken data overvissen naar de applicatie en denken dat jij efficientere algoritmen kan verzinnen dan dedicated database guru's.

Ik heb het noSQL verhaal eenmalig eens geprobeerd bij een eerste project opzetje .. in het begin leek het allemaal wel wat.
Op zich allemaal vrij gauw opgezet, eerste eenvoudige queries met eenvoudige data zitten er lekker gauw in.
Maar dan heb je er de nodige uren al inzitten .. en dan begint het drama, je wilt wat complexere queries doen .. ow wat een hell, en terug naar SQL wil je in eerste instantie ook niet wat je hebt nu al geinvesteerd in dit .. dus je gaat door en de gedrochten worden steeds groter .. en groter en groter ...
(en toen zat ik met een deuntje in het hoofd)

Ik heb me altijd verzet tegen alle gasten die de hele tijd maar riepen dat alles in NoSQL gestopt zou moeten worden. De applicaties waar ik mee te maken heb zijn 99% apps met relationele data en door naar NoSQL te switchen verschuif je het probleem wat ze denken op te lossen en dan ook nog met minder constraint mogelijkheden.
Normaal word je soort van geforceerd je data weer op te schonen d.m.v database-updatescripts met modelwijzigingen en blijft de code ook lekker schoon. Met NoSQL heb je in mum van tijd je code allemaal checks op properties die soms wel en soms niet aanwezig zijn met vervolgens de logische afhandeling daarvan die als je niet uitkijkt ook nog eens af kan drijven. Voor je het weet is het een grote teringzooi omdat er ook niets wordt afgedwongen.
Tuurlijk zou iemand kunnen beweren dat het met goede programmeurs en doordachte code dat ook netjes zou moeten kunnen, maar wat ik heb gezien in de praktijk gaat die vlieger gewoon niet op.
NoSQL heeft natuurlijk wel een doel, maar de meeste developers krijgen daar zelden iets mee te maken.
Vaak is het argument dat het veel sneller is en als je dan kijkt naar de data zie je dat het gewoon relationele data is en het een database betreft met slechts enkele miljoenen records.
Als het dan niet performt kloppen er andere dingen niet en als je dat al niet fatsoenlijk aan de praat krijgt kan je beter maar niet aan NoSQL beginnen. Dan weet je namelijk zeker dat je daar een grote bende van gaat maken.

[gekkie]

ZaZ schreef op vrijdag 2 juni 2017 @ 09:59:
[...]

Ik heb me altijd verzet tegen alle gasten die de hele tijd maar riepen dat alles in NoSQL gestopt zou moeten worden. De applicaties waar ik mee te maken heb zijn 99% apps met relationele data en door naar NoSQL te switchen verschuif je het probleem wat ze denken op te lossen en dan ook nog met minder constraint mogelijkheden.
Normaal word je soort van geforceerd je data weer op te schonen d.m.v database-updatescripts met modelwijzigingen en blijft de code ook lekker schoon. Met NoSQL heb je in mum van tijd je code allemaal checks op properties die soms wel en soms niet aanwezig zijn met vervolgens de logische afhandeling daarvan die als je niet uitkijkt ook nog eens af kan drijven. Voor je het weet is het een grote teringzooi omdat er ook niets wordt afgedwongen.
Tuurlijk zou iemand kunnen beweren dat het met goede programmeurs en doordachte code dat ook netjes zou moeten kunnen, maar wat ik heb gezien in de praktijk gaat die vlieger gewoon niet op.
NoSQL heeft natuurlijk wel een doel, maar de meeste developers krijgen daar zelden iets mee te maken.
Vaak is het argument dat het veel sneller is en als je dan kijkt naar de data zie je dat het gewoon relationele data is en het een database betreft met slechts enkele miljoenen records.
Als het dan niet performt kloppen er andere dingen niet en als je dat al niet fatsoenlijk aan de praat krijgt kan je beter maar niet aan NoSQL beginnen. Dan weet je namelijk zeker dat je daar een grote bende van gaat maken.

Separation of concerns.

Het zou allemaal ook in je applicatie kunnen, alleen ga je dan uiteindelijk min of meer toch weer zelf een relationele database bouwen rondom je documentstore. Een centraal dingetje wat je constraints doet .. want verspreid is niks .. een centraal dingetje wat ontbrekende functionaliteit oplost .. en dat het liefste in je interpreted taaltje.

Mjah het verneukeradingste is dat je in het begin nog wel eens kan denken dat je niet echt queries gaat doen op relaties. En data erin stoppen is zo eenvoudig !
Maar uiteindelijk blijken er dan toch altijd weer relaties te zijn .. anders had je het wel in fscking text bestandjes in een filesystem gedumpt, who needs a DB ?
Vaak is een jointje (weer dat deuntje ) op je user table wel handig .. en daar gaan we al ..

Al zie ik als ik stackoverflow mag geloven dat ze nu ook iets wat lijkt op joins ingebouwd.
Achja denk dat ze uiteindelijk toch wel weer een eind naar relational toe moeten groeien omdat men dus basis functionaliteit mist.

Echter ga ik dan liever van de andere kant uit, relational DB met een json columntype en indexen, wat er nu al is bij bijvb. Postgres (Maria is er geloof ik mee bezig). Kun je eventueel een deel van de meuk in een json type kwijt en belangrijke (meta)data voor performance in gewone kolommen.
(aardige is ook dat er daarmee een berg functies zijn gekomen om je resultaten naar json te laten ombouwen en vise-versa, waarmee je in combinatie met CTE's de handel op het laatst gewoon door je DB in json kunt laten uitpoepen en in je applicatie er weinig meer mee hoeft te doen dan doorsturen).
En uiteindelijk wordt sharding-like/cluster functionaliteit ook wel beter en meer gemeen goed.

Belangrijkste daarbij is dat ik die lui vertrouw dat ze geen gekke dingen doen met mijn data en eerst nadenken en dan eventueel doen in tegenstelling tot sommige noSQL cowboys.

Kortom het belangrijkste achievment van die noSQL/document store dingen is ... dat ze er bij RDBMS'en voor hebben gezorgd dat er een json column type met alle functionaliteit er omheen is gekomen, waarvoor dank .

[ Voor 17% gewijzigd door gekkie op 02-06-2017 10:22 ]

[DevWouter]

Jantje2000 schreef op vrijdag 2 juni 2017 @ 06:56:
Dat zou moeten kunnen bij SpreadShirt denk ik.

Super bedankt! Ik had er wel een paar gevonden, maar deze is echt een stuk beter!

Mijn eerste poging: https://www.spreadshirt.n...?product=155764166&view=1

Als iemand suggesties heeft, laat maar horen.

[Jan_V]

gekkie schreef op vrijdag 2 juni 2017 @ 10:21:
[...]

...
Echter ga ik dan liever van de andere kant uit, relational DB met een json columntype en indexen, wat er nu al is bij bijvb. Postgres (Maria is er geloof ik mee bezig). Kun je eventueel een deel van de meuk in een json type kwijt en belangrijke (meta)data voor performance in gewone kolommen.
...

Dit!

Ik heb dit in een vorig project ook gebruikt, aangezien we ongestructureerde informatie binnen kregen en daarvan maar een deel wilden gaan gebruiken als relationele data. De rest van de data moest gewoon in een 'model' worden opgeslagen.
Dus in plaats van het hele model normaliseren en in verschillende tabellen op te slaan met allerlei FK's, gewoon het SQL Server XML veld gebruikt en de data daar in plaatsen.
Zo kunnen er ook nog queries op worden uitgevoerd, als men dat zou willen. Verder hoeft alleen een applicatie er bij en die kan prima met een XmlSerializer hier een mooi model van toveren.
Best of both worlds!

* Jan_V houdt sowieso meer van XML dan JSON

[mindcrash]

ZaZ schreef op vrijdag 2 juni 2017 @ 09:59:
Ik heb me altijd verzet tegen alle gasten die de hele tijd maar riepen dat alles in NoSQL gestopt zou moeten worden. De applicaties waar ik mee te maken heb zijn 99% apps met relationele data en door naar NoSQL te switchen verschuif je het probleem wat ze denken op te lossen en dan ook nog met minder constraint mogelijkheden.

De mensen die dat roepen hebben het zowiezo niet begrepen.

NoSQL (Mongo, RavenDB, maar feitelijk ook Elasticsearch) gebruik je in principe alleen als je zaken in structurele documentvorm wil opslaan en doorzoeken, en correctheid in je servicelaag is verwerkt. Feitelijk dus ook alleen toepasbaar als de informatie wordt aangeleverd als structureel document (denk aan facturen, orders, whatever)

Daarnaast is de keus in data opslag zeker niet binair (als in SQL en NoSQL), er is keus tussen columnaire data storage (Postgres, MariaDb, MySQL), "brede" columnaire data storage (Cassandra, Accumulo), File c.q. Blob storage (Op lokale of gedistribueerde file systems of services zoals Azure BS of Amazon S3), Graph storage (Neo4J, Cayley, DGraph), en Times Series storage (Influx, Druid). Daarnaast heb je ook multi model databases waar een aantal van deze opslagmodellen zit verwerkt (bijvoorbeeld een Arango waarin zo uit m'n hoofd document, KV en graph storage in is verwerkt).

Al naargelang van het data gerelateerde probleem wat je oplost kun je dus 1 van deze systemen toepassen, en kun je je ook erg hard in de vingers snijden als je een bepaald probleem met het verkeerde systeem probeert op te lossen. Zo zou ik iets als "toon de spellen waarin mijn netwerk de laatste 4 weken interesse in hebben getoond" echt nooit proberen op te lossen met een document database.

[DevWouter]

Ik denk ook dat een groot probleem is dat we dusdanig getraind zijn op relationele database dat we ons ontwerp niet geschikt makenvoor andere storage types.

Echter er is ook niks dat zegt dat we maar één type database mogen gebruiken. Zo zou een lijst van producten (met allerlei afwijkende eigenschappen) in een document storage beter tot zijn recht komen terwijl je de transacties van aankopen weer in een relationele database doet.

Het enige vervelende is dat je geen relationele integriteit heb en soms meerdere databases moet benaderen voor een simpele resultaat (bijvoorbeeld: laatste aankoop)

[qless]

Ik heb al een aantal projecten met mongo gedaan, maar idd, als je data zuiver relationeel is, gebruik lekker sql...

[hellum]

Wij gebruiken hier Mongo voor caching van zoekresultaten, daar is het wel erg geschikt voor. Je kunt stomweg het hele object met de resultaten van een search query er in pleuren.

Alle andere data staat dan weer gewoon in SQL Server.

[ Voor 14% gewijzigd door hellum op 02-06-2017 15:18 ]

[F.West98]

Wij gebruiken Elastic vooral om snel te kunnen aggregaten. Beetje het probleem van 1001 kolommen/attributen die soms wel/niet aanwezig zijn en atm in een key/value tabel met 800M+ rijen zijn opgeslagen. Ja dat is traag
Dus we slaan alles nog wel op in SQL, maar exporteren daarna alle wijzigingen/nieuwe entries naar elastic. Zo heb je wel consistency, maar ook de snelheid als het nodig is (en dubbele opslag maargoed dat is niet zo'n probleem meer tegenwoordig).
Beetje half-half dus.

[gekkie]

DevWouter schreef op vrijdag 2 juni 2017 @ 13:32:
Ik denk ook dat een groot probleem is dat we dusdanig getraind zijn op relationele database dat we ons ontwerp niet geschikt makenvoor andere storage types.

Echter er is ook niks dat zegt dat we maar één type database mogen gebruiken. Zo zou een lijst van producten (met allerlei afwijkende eigenschappen) in een document storage beter tot zijn recht komen terwijl je de transacties van aankopen weer in een relationele database doet.

Dat is toch ook zo ongeveer de use-case geweest waarop de ontwikkelaars van SQL databases overtuigd zijn geraakt om een json type te implementeren ?
De oplossing met koppel tabellen was namelijk ook niet bepaald ideaal, maar kwam wel veelvuldig voor.

Het enige vervelende is dat je geen relationele integriteit heb en soms meerdere databases moet benaderen voor een simpele resultaat (bijvoorbeeld: laatste aankoop)

Heb het sowieso liever in 1 DB als het kan, transactiewise, backupwise etc.
Een documentstore heeft wat dat betreft niet dusdanig eigenschappen die een RDBMS niet kan hebben dat ik er veel brood meer in zie. Voor de andere noSQL databases is best wat te zeggen in hun eigen niche.

Tsjinkiedinkie ... dat was pittige post op de deurmat .. schlagertv gaat uit het zenderpakket
(toch netjes dat ze het melden met een brief)

[ Voor 6% gewijzigd door gekkie op 02-06-2017 17:11 ]

[Verwijderd]

Wat zouden jullie dan gebruiken voor categorieën met producten, die niet altijd dezelfde eigenschappen hebben en doorzocht kunnen worden, en bestellingen die die producten bevatten door een bepaalde gebruikers? Op dit moment gebruiken we een document store (CouchDB 2).

[RagingPenguin]

Verwijderd schreef op vrijdag 2 juni 2017 @ 18:30:
Wat zouden jullie dan gebruiken voor categorieën met producten, die niet altijd dezelfde eigenschappen hebben en doorzocht kunnen worden, en bestellingen die die producten bevatten door een bepaalde gebruikers? Op dit moment gebruiken we een document store (CouchDB 2).

Voor mij klinkt dat heel erg als SQl. Categorieën heeft een een-op-veel of een veel-op-veel relatie met producten. Categorieën heeft ook een veel-op-veel relatie met (de niet verplichte) eigenschappen (ik ga er even vanuit dat er eigenschappen zijn die iedere categorie heeft zoals bv naam). Gebruikers hebben een een-op-veel relatie met bestellingen. Bestellingen hebben weer een veel-op-veel relatie met producten.

Edit: het eigenschappen ding kan mischien beter in een JSON field, beetje afhankelijk van hoe verschillend ze zijn per categorie.

Hoe hebben jullie nu de relatie tussen gebruiker, bestelling en producten afgehandeld? Want ik kan dat niet echt voor me zien zonder toch maar wel foreignkeys te gaan opslaan in je tabellen en er stiekem toch een relationele database op na te houden.

[ Voor 19% gewijzigd door RagingPenguin op 02-06-2017 19:00 ]

[Caelorum]

Moet je alleen wel opletten, want je wilt de bestellingen niet zomaar koppelen aan de huidige toestand van de producten, maar voor een deel aan hoe het was ten tijde van verkoop/in behandeling nemen.
Door het over te hevelen van je RDBMS, naar een andere data-store kan je mooi forceren dat die koppelingen niet alsnog worden geïntroduceerd.

[gekkie]

RagingPenguin schreef op vrijdag 2 juni 2017 @ 18:51:
[...]


Voor mij klinkt dat heel erg als SQl. Categorieën heeft een een-op-veel of een veel-op-veel relatie met producten. Categorieën heeft ook een veel-op-veel relatie met (de niet verplichte) eigenschappen (ik ga er even vanuit dat er eigenschappen zijn die iedere categorie heeft zoals bv naam). Gebruikers hebben een een-op-veel relatie met bestellingen. Bestellingen hebben weer een veel-op-veel relatie met producten.

Edit: het eigenschappen ding kan mischien beter in een JSON field, beetje afhankelijk van hoe verschillend ze zijn per categorie.

Zolang je enige restricties handhaaft zoals dat producten non-mutable zijn kan dat.
Anders kun je bij je bestellingen geen referenties toepassen, aangezien je dan ook al afgehandelde bestellingen veranderd met je wijzigingen van producten. Dat is denk ik de voornaamste gotcha (dezelfde als waar menig beginnende pythonista zijn schedel iets kaler maakt).

Hoe hebben jullie nu de relatie tussen gebruiker, bestelling en producten afgehandeld? Want ik kan dat niet echt voor me zien zonder toch maar wel foreignkeys te gaan opslaan in je tabellen en er stiekem toch een relationele database op na te houden.

In iedergeval tussen users en bestellingen zul je een relatie moeten hebben en houden.
Tussen bestellingen en producten hoeft dus niet als je je bestellingen volledig met alle product info opslaat als document, waarbij dan ook de bovenstaande restrictie vervalt. Maar goed dat kun je in SQL net zo goed doen door de bestelling als "document" te behandelen zonder referenties.

[Verwijderd]

RagingPenguin schreef op vrijdag 2 juni 2017 @ 18:51:
[...]


Voor mij klinkt dat heel erg als SQl. Categorieën heeft een een-op-veel of een veel-op-veel relatie met producten. Categorieën heeft ook een veel-op-veel relatie met (de niet verplichte) eigenschappen (ik ga er even vanuit dat er eigenschappen zijn die iedere categorie heeft zoals bv naam). Gebruikers hebben een een-op-veel relatie met bestellingen. Bestellingen hebben weer een veel-op-veel relatie met producten.

Hmm… dat dacht ik al, ookal vind ik de relevante code niet zo slordig ofzo. Overigens heb ik niet bepaald om CouchDB te gebruiken.

Hoe hebben jullie nu de relatie tussen gebruiker, bestelling en producten afgehandeld? Want ik kan dat niet echt voor me zien zonder toch maar wel foreignkeys te gaan opslaan in je tabellen en er stiekem toch een relationele database op na te houden.

In het document van een bestelling is er onder andere een eigenschap die de gebruiker aangeeft (we doen dan een Mango query om alleen bestellingen van een bepaalde gebruiker te krijgen) en een lijst met objecten waarin de ID, de revisie en de hoeveelheid van een product staan.

[ Voor 37% gewijzigd door Verwijderd op 02-06-2017 19:20 ]

[Jantje2000]

Wat ik op het moment doe is eigenlijk gewoon een gestringde (array waar een string van is gemaakt ) array in json formaat in een varchar veld dumpen op mn werk. Ik weet niet of daar nadelen aan zitten?

[Mercatres]

Jantje2000 schreef op vrijdag 2 juni 2017 @ 20:17:
Wat ik op het moment doe is eigenlijk gewoon een gestringde (array waar een string van is gemaakt ) array in json formaat in een varchar veld dumpen op mn werk. Ik weet niet of daar nadelen aan zitten?

Zolang je er niet al te veel operaties mee doet, zie ik niet meteen nadelen. Gebruik wel de juiste tool je JSON de (de)serializen.

[Alex)]

JSON schrijven, dat doe je toch gewoon zo?

C#:

var json = $"{{'items': [ {{ 'flerp': {someObject.Value} }} ] }}";

[RagingPenguin]

Alex) schreef op zaterdag 3 juni 2017 @ 18:13:
JSON schrijven, dat doe je toch gewoon zo?

C#:

var json = $"{{'items': [ {{ 'flerp': {someObject.Value} }} ] }}";

Nee, dat is geen geldige JSON. Je moet dubbele quotes gebruiken. En alsjeblieft, gebruik gewoon een goede tool voor json. Newton of json.net bv. als we het over C# hebben.

[mcDavid]

Alex) schreef op zaterdag 3 juni 2017 @ 18:13:
JSON schrijven, dat doe je toch gewoon zo?

C#:

var json = $"{{'items': [ {{ 'flerp': {someObject.Value} }} ] }}";

Je vergeet nog de

PHP:

 '{"booleanVal": "' . ($booleanval ? 'Y' : 'N') . '"}';

Dat ben ik serieus een keer tegengekomen. Heb je zo'n mooie efficiënte object notation, ga je booleans casten naar strings en op de cliënt weer terug natuurlijk.

[Jantje2000]

php en javascript hebben uiteraard gewoon built-in functies. Python heeft dan weer een mooie library (simplejson, dacht ik)

[ Voor 4% gewijzigd door Jantje2000 op 03-06-2017 19:07 ]

[Ryur]

RagingPenguin schreef op zaterdag 3 juni 2017 @ 18:31:
[...]


Nee, dat is geen geldige JSON. Je moet dubbele quotes gebruiken. En alsjeblieft, gebruik gewoon een goede tool voor json. Newton of json.net bv. als we het over C# hebben.

Volgens mij begrijp jij sarcasme niet?

[RagingPenguin]

Ryur schreef op zaterdag 3 juni 2017 @ 19:21:
[...]

Volgens mij begrijp jij sarcasme niet?

bad me

Maar je zou niet de eerste zijn die zulke dingen zie doen...

[Ryur]

RagingPenguin schreef op zaterdag 3 juni 2017 @ 19:23:
[...]



bad me

Maar je zou niet de eerste zijn die zulke dingen zie doen...

Truetrue
Ik heb toevallig gister een collega een enorme trap hierom gegeven, en dat terwijl het kan 'afkijken' van mijn project

Maar ik weet zeker dat @Alex) het sarcastisch bedoeld, gezien zijn kennisniveau (wat ik kan zien aan zijn geschiedenis hier)

[ Voor 5% gewijzigd door Ryur op 03-06-2017 19:29 ]

[Creepy]

Blijft grappig om te zien dat dezelfde crap die met XML werd gedaan, weer vrolijk opnieuw wordt gedaan met JSON. Strings aan elkaar plakken ftw.. ofzo

[Adion]

Dat is toch net wat een JSON/XML library ook doet? (alleen vermoedelijk met een omweg via een interne object-representatie van de JSON, die vervolgens door strings aan elkaar te plakken JSON output)

[Creepy]

Dat er uiteindelijk een string uitkomt, betekent niet dat je zelf alvast maar strings aan elkaar moet gaan plakken. Gebruik er aub een fatsoenlijke library voor anders is de kant dat je het verkeerd doet nogal groot... Hoeveel support we op mijn werk al niet gezien hebben omdat mensen XML (SOAP in dit geval), maar ook JSON zelf maar aan elkaar gingen plakken om onze APIs te benaderen en dat dan verkeerd deden.....

Zelfs string aan elkaar plakken betekent dat je geen idee hebt waar je mee bezig bent, of dat je te eigenwijs bent en denkt het beter te kunnen dan de libs die er zijn zijn (en dat heb je dan mis )

[Alex)]

mcDavid schreef op zaterdag 3 juni 2017 @ 18:32:
[...]

Je vergeet nog de

PHP:

 '{"booleanVal": "' . ($booleanval ? 'Y' : 'N') . '"}';

Dat ben ik serieus een keer tegengekomen. Heb je zo'n mooie efficiënte object notation, ga je booleans casten naar strings en op de cliënt weer terug natuurlijk.

I see your Y/N and raise with...

C#:

 
public enum CustomBoolean : int
{
    Y = 1, 
    J = 1
    N = 0, 
    ✓ = 1, 
    Yes = 1, 
    No = 0, 
    FILE_NOT_FOUND = 2
} 

Die gekke HTML encoded meuk hierboven is dit teken: ✓

[ Voor 5% gewijzigd door Alex) op 03-06-2017 23:04 ]

[mcDavid]

@Alex) ...en dan nog een waarde 2 erbij zodat het ook niet meer in een Boolean past .

@Creepy an sich zou er niets mis mee zijn als je het zelf schrijft (behalve dat het zonde van je tijd is), maar dan schrijf je er iig een nette method voor. En niet inline met je business logic.

Anyway dit zou eigenlijk mooier staan in het slechte programmeervoorbeelden topic

[Creepy]

Het is zonde van de tijd om het te proberen, en het is zonde van je tijd omdat je gegarandeerd bugs schrijft die een veel gebruikte library niet heeft. Dus wat mij betreft is er zeker wat mis mee tenzij je het schrijft om er van te leren.

[ Voor 9% gewijzigd door Creepy op 04-06-2017 13:11 ]

[hellum]

@Creepy Hoezo? Alleen omdat jou code bugs heeft? Die van mij is altijd perfect.

[gekkie]

hellum schreef op zondag 4 juni 2017 @ 11:00:
@Creepy Hoezo? Alleen omdat jouW code bugs heeft? Die van mij is altijd perfect.

FTFY
(altijd lullig, zo'n syntax error in line 1)

[ Voor 19% gewijzigd door gekkie op 04-06-2017 13:07 ]

[RayNbow]

YouTube's recommender system werkt soms verbluffend goed...

...4 van je eigen video's aanbevelen.

[alienfruit]

Huh, wie gebruikt er nou Y/N voor boolean waarden? Lijkt mij duidelijk dat dit X, -, spatie' moet zijn

[Merethil]

alienfruit schreef op maandag 5 juni 2017 @ 11:10:
Huh, wie gebruikt er nou Y/N voor boolean waarden? Lijkt mij duidelijk dat dit X, -, spatie' moet zijn

Wij interfacen met Duitse en Italiaanse systemen, het SAP-systeem in Duitsland stuurt J/N of X/{leeg}, het Italiaanse (door overgekocht bedrijf zelf gebouwde) systeem stuurt S/N of X/F
Echt heel duidelijk allemaal

[alienfruit]

X,-,spatie is ook SAP hoor
X = Ja
- = Nee
spatie = Geen waarde/onbekend

[ Voor 45% gewijzigd door alienfruit op 05-06-2017 11:46 ]

[Alex)]

Ohja, SAP-booleans! Daar heb ik me nog over verbaasd toen ik het voor het eerst moest gebruiken.

Nog mooier vond ik het toen bleek dat ik ook echt 'X' in een SOAP-bericht moest stoppen

[DevWouter]

Then again... Deze XML valt voor mij in dezelfde categorie:

code:

<hasName>true</hasName>
<name>John</name>

En nee, je mocht de velden niet weglaten of laten een self-closing xml maken. En als je vergat om de has-argument in te vullen dan las het de waarde niet uit.

Volgens mij zijn die codes (net zoals de voorbeelden hierboven) geschreven door mensen die software-ontwikkelen niet als hun primaire vakgebied zien.

[RagingPenguin]

Oke, ik begrijp nu helemaal waarom SOAP niet zo populair meer is...

[Rutix]

RagingPenguin schreef op maandag 5 juni 2017 @ 16:40:
Oke, ik begrijp nu helemaal waarom SOAP niet zo populair meer is...

Dan is zeker niks meer populair. Elke techniek die ik ken heeft mensen die achtelijke dingen ermee doen . JSON zie ik ook de raarste dingen voorbij komen

[RagingPenguin]

Rutix schreef op maandag 5 juni 2017 @ 16:51:
[...]

Dan is zeker niks meer populair. Elke techniek die ik ken heeft mensen die achtelijke dingen ermee doen . JSON zie ik ook de raarste dingen voorbij komen

Het was dat ook niet 's werelds meest serieuze comment Maar zo iets simpels als een boolean op een zo complexe en zo voor niet-soapers onleesbare manier weergeven is natuurlijk wel stereotype SOAP.

[Alex)]

DevWouter schreef op maandag 5 juni 2017 @ 15:23:


En nee, je mocht de velden niet weglaten of laten een self-closing xml maken.

Dat klinkt als "we parsen XML met Regular Expressions."

En als je vergat om de has-argument in te vullen dan las het de waarde niet uit.

Da's een rare ontwerpkeuze, maar ik heb het wel vaker gezien. Waarom, geen idee

[Merethil]

DevWouter schreef op maandag 5 juni 2017 @ 15:23:
Then again... Deze XML valt voor mij in dezelfde categorie:

code:

<hasName>true</hasName>
<name>John</name>

En nee, je mocht de velden niet weglaten of laten een self-closing xml maken. En als je vergat om de has-argument in te vullen dan las het de waarde niet uit.

Volgens mij zijn die codes (net zoals de voorbeelden hierboven) geschreven door mensen die software-ontwikkelen niet als hun primaire vakgebied zien.

Zelfde soort idioterie:

Bij ons snapt ons SAP-systeem het niet als je een segment in XML niet "segment="1"" meegeeft als variabele op said XML-segment. Ik snap dat ook totaal niet, maar het is best irritant als je het per ongeluk vergeet en het hele segment dus niet wordt geparsed.
Grappig genoeg hebben we ook een aantal "IDocs" die dat dan weer niet expliciet nodig hebben, maar die dingen zijn allemaal custom...

[Alex)]

Wat ook leuk is met SAP-systemen: datums.

Ik heb het wel eens gezien dat een SAP-systeem i.p.v. een xs:date (ISO 8601) een custom datatype had gedefinieerd in de WSDL, en in precies dat formaat ook de datums wilde hebben. Zoiets dus:

XML:

<xs:simpleType name="CustomDate">
    <xs:restriction base="xs:date">
        <xs:pattern value="\d{2}\.\d{2}\.\d{4}"/>
    </xs:restriction>
</xs:simpleType>

In de door Visual Studio gegenereerde proxy classes stond wel netjes een DateTime, maar de XmlSerializer wist niet wat hij aanmoest met dat custom pattern. Die stuurde gewoon ISO 8601 over de lijn, wat het SAP-systeem dus niet accepteerde.

Uiteindelijk moest ik de XML-serialisatie zelf gaan schrijven

[Down]

Ik heb vandaag zitten spelen met een ASP.NET Core API hosted in AWS lambda. Serverless dus. Ik moet zeggen dat het erg goed werkt en zeker interessant is vanuit een maintenance perspectief . Nu nog even het kostenplaatje uitzoeken voor een applicatie met serieuze load.

[cracking cloud]

Waarom niet azure? Is die qua prijs niet interessant? Of doen jullie nu alles al bij Amazon?

[Down]

cracking cloud schreef op maandag 5 juni 2017 @ 21:49:
Waarom niet azure? Is die qua prijs niet interessant? Of doen jullie nu alles al bij Amazon?

Ons platform draait volledig in AWS en ik zag toevallig ergens een tutorial i.c.m. AWS voorbij komen. In Azure zal het ongetwijfeld ook kunnen.

[gekkie]

* gekkie verwacht nu eindelijk ook wel eens andere opleveringen van projecten, iedereen is onderhand toch wel opgevoed door Appel.
1.geen commentaar over m'n overhemden met kreuk uit de broek.
2. applaus en gejoel voordat ik een feature aankondig.
Oja en one last thing, dat geldt voor elke scheet apart.ook voor totale non-features waarvan je je afvraagt of het uberhaupt het benoemen waard is en/of waarvan je zou verwachten dat het er al lang in zat.

[Alex)]

"Oh, and one more thing...

We now use Application Insights for logging!"

*crowd goes wild*

[Merethil]

Alex) schreef op maandag 5 juni 2017 @ 17:57:
Wat ook leuk is met SAP-systemen: datums.

Ik heb het wel eens gezien dat een SAP-systeem i.p.v. een xs:date (ISO 8601) een custom datatype had gedefinieerd in de WSDL, en in precies dat formaat ook de datums wilde hebben. Zoiets dus:

XML:

<xs:simpleType name="CustomDate">
    <xs:restriction base="xs:date">
        <xs:pattern value="\d{2}\.\d{2}\.\d{4}"/>
    </xs:restriction>
</xs:simpleType>

In de door Visual Studio gegenereerde proxy classes stond wel netjes een DateTime, maar de XmlSerializer wist niet wat hij aanmoest met dat custom pattern. Die stuurde gewoon ISO 8601 over de lijn, wat het SAP-systeem dus niet accepteerde.

Uiteindelijk moest ik de XML-serialisatie zelf gaan schrijven

Oh bij ons is alles een string in die XSD's/XML's. Is dat beter of slechter?

[Hydra]

RagingPenguin schreef op maandag 5 juni 2017 @ 17:04:
Het was dat ook niet 's werelds meest serieuze comment Maar zo iets simpels als een boolean op een zo complexe en zo voor niet-soapers onleesbare manier weergeven is natuurlijk wel stereotype SOAP.

Oh, ik heb echt de meest bizarre shit meegemaakt in die "SOAP is hip" tijd waar we nu gelukkig doorheen zijn:

• Ik heb bij twee aparte vendors meegemaakt dat ze hun XML serialisatie met de hand met String concatenations deden. Werkte in hun tests prima. Werkt live, met accenten in namen e.d., natuurlijk voor geen fucking meter. En maar blijven volhouden dat de fout aan onze kant zit terwijl zelfs Internet Explorer meldt dat het invalid XML is.
• Binary data in XML berichten serialiseren als <array><byte>1</byte><byte>2</byte> ... ></array>. Een <byte> tag per byte dus. base64 is hard yo
• WSDL definities zo groot en complex dat de meeste parsers er op crashen. Gegenereerd uit hun model natuurlijk, WSDL met de hand maken is te moeilijk
• Hele simpele WSDL schema's met daaren een <xsd:any/> value. Oftewel; daar kan een willekeurige XML boom in zitten. En daar zit dan natuurlijk de complexiteit; een enorme structuur zonder schema of documentatie.
• XML commentaar blokken misbruiken voor meta informatie die je XML parser nodig heeft om de juiste interpretatie te doen. Wat niet werkt als je standaard tools gebruikt en liever niet je eigen XML parsers schrijft.

Ik ben blij dat die tijd voorbij is. Een van de grootste pluspunten van JSON is dat je er geen commentaar in kwijt kan. Dit is met opzet omdat te veel developers dat misbruiken voor 'slimme' truukjes.

Tenslotte wil ik deze link nog ff achterlaten voor de mensen die S stands for Simple niet kennen

Merethil schreef op maandag 5 juni 2017 @ 23:21:
Oh bij ons is alles een string in die XSD's/XML's. Is dat beter of slechter?

Ga je schamen

Maar serieus: als je het goed doet is er niks met SOAP. Maar je moet gewoon contract first werken en met de hand een WSDL maken. Dan werkt het super goed en kan je heel simpel zowel server als client stubs genereren. Maar 90% van de SOAP meuk doen het andersom en dan krijg je grote rotzooi. Daarnaast zijn het vaak deze 'simpele' taken die aan compleet onervaren stagairs overgelaten worden omdat de senior devs het te saai vinden.

[ Voor 14% gewijzigd door Hydra op 06-06-2017 08:59 ]

[Merethil]

Hydra schreef op dinsdag 6 juni 2017 @ 08:56:

[...]


Ga je schamen

Maar serieus: als je het goed doet is er niks met SOAP. Maar je moet gewoon contract first werken en met de hand een WSDL maken. Dan werkt het super goed en kan je heel simpel zowel server als client stubs genereren. Maar 90% van de SOAP meuk doen het andersom en dan krijg je grote rotzooi. Daarnaast zijn het vaak deze 'simpele' taken die aan compleet onervaren stagairs overgelaten worden omdat de senior devs het te saai vinden.

Oh sorry, ik had het hier over XSD's en XML's van SAP, niet van SOAP
SOAP doen we wel gewoon volgens het boekje

[alienfruit]

Altijd mooi wanneer een freelancer de rekening naar heel het bedrijf mailt. Kan je mooi zien hoeveel een freelancer verdient. Toch maar eens praten met de baas

[DevWouter]

Ik heb nog een leukere ervaring met SOAP, ik moest een standaard implementeren voor encryptie en signing dat de Java variant wel heeft, maar de .Net versie niet.

Het duurde even voordat ik accepteerde dat de gezochte variant niet ondersteund werd (en ik heb alle .net-varianten van encryptie en signing gedecompiled om zeker te zijn).

Good times, good times

[mindcrash]

DevWouter schreef op dinsdag 6 juni 2017 @ 09:58:
Ik heb nog een leukere ervaring met SOAP, ik moest een standaard implementeren voor encryptie en signing dat de Java variant wel heeft, maar de .Net versie niet.

Het duurde even voordat ik accepteerde dat de gezochte variant niet ondersteund werd (en ik heb alle .net-varianten van encryptie en signing gedecompiled om zeker te zijn).

Good times, good times

Komt waarschijnlijk omdat al het SOAP related spul bij Microsoft inmiddels deprecated is in favor of REST en JSON, en bij Oracle niet

[Rutix]

DevWouter schreef op dinsdag 6 juni 2017 @ 09:58:
Ik heb nog een leukere ervaring met SOAP, ik moest een standaard implementeren voor encryptie en signing dat de Java variant wel heeft, maar de .Net versie niet.

Het duurde even voordat ik accepteerde dat de gezochte variant niet ondersteund werd (en ik heb alle .net-varianten van encryptie en signing gedecompiled om zeker te zijn).

Good times, good times

XML encryptie en signing icm met java is echt een hel. Ik heb daar toen een keer ook heel wat tijd in gestoken zelfs door zelf handmatig de encryptie en signing na te spelen. Als ik me goed herinner was het uiteindelijk dat de signing op de verkeerde plek ofzo zat en de verwijzing wel volgens de standaard was maar dat de java kant niet met die variant om kon gaan.

[DevWouter]

mindcrash schreef op dinsdag 6 juni 2017 @ 10:10:
[...]


Komt waarschijnlijk omdat al het SOAP related spul bij Microsoft inmiddels deprecated is in favor of REST en JSON, en bij Oracle niet

Dat dacht ik ook een lange tijd, maar SOAP is een compleet messaging platform. Zo kan je het gebruiken via de e-mail of zelfs een usb-stick of postduif. Je kan het ook meer vergelijken met e-mail dan met http.

Het is dus niet te vergelijken met REST.

Echter... Het lijkt er inderdaad op dat Microsoft er inderdaad geen energie of weinig energie instopt.

[Damic]

alienfruit schreef op dinsdag 6 juni 2017 @ 09:42:
Altijd mooi wanneer een freelancer de rekening naar heel het bedrijf mailt. Kan je mooi zien hoeveel een freelancer verdient. Toch maar eens praten met de baas

Lol tja moet een freelancer niet zelf alles afdragen naar de belastingen terwijl als je voor een baas werkt de baas dat doet?

[TheNephilim]

Wat een verhaal

https://twitter.com/jxxf/status/871000661869154304

[RagingPenguin]

TheNephilim schreef op dinsdag 6 juni 2017 @ 12:33:
Wat een verhaal

https://twitter.com/jxxf/status/871000661869154304

Dat is meer de fout van het bedrijf dan van die stagiair. Die stagiair zou nooit de mogelijkheid moeten hebben om iets goed stuk te kunnen maken.

[Jantje2000]

Lijkt mij ook een fout van het bedrijf, aangezien zij de foute data aan die stagiair gaven. Maar eigenlijk hoort zoiets niet te kunnen.

[alienfruit]

Damic schreef op dinsdag 6 juni 2017 @ 12:31:
Lol tja moet een freelancer niet zelf alles afdragen naar de belastingen terwijl als je voor een baas werkt de baas dat doet?

Klopt, maar zelfs de freelancer bruto 'maand' is al €35.000 euro meer dan mijn bruto salaris

[Damic]

Zal wel iets zijn dat een freelancer voordelig is in de kwartaal afrekening dan iemand continu hebben. Maar euhm 35k

[ZaZ]

Ligt er natuurlijk aan hoe lang ie werk heeft gehad.
Het lijkt snel spectaculair, maar dat valt vies tegen hoor als je ziet wat je allemaal nog moet aftikken.
Toen ik een aantal jaar geleden begon zette ik ongeveer 100k om ofzo en dat ziet er allemaal leuk uit, maar toen kwamen de blauwe brieven. Los van BTW plicht (die redelijk voorspelbaar is) zit je ineens in een andere schijf en kan je 52% afdragen en allemaal teruggaves die je altijd kreeg heb je ineens geen recht meer op etc.
Geen reden tot klagen hoor, maar alles is veel minder zeker, je moet aan de kar blijven trekken, veel minder overzicht. Als je als normale werkslaaf een spaarrekening hebt van 10k dan kom je het jaar wel door als de wasmachine stukgaat, de auto wat problemen vertoont e.d.
Heb je jouw eigen toko, dan kan je ineens rekeningen krijgen die het veelvoudige zijn van dat omdat bijvoorbeeld de belastingdienst ineens zegt "we vinden dat u alvast voor volgend jaar moet betalen"

Zelf vind ik geld niet zo heel interessant, dus ik zit er niet zo heel erg bovenop. Ik heb een boekhouder die vertelt me wat ik moet doen en ik geloof 'm maar op zijn blauwe ogen.

[Skyaero]

alienfruit schreef op dinsdag 6 juni 2017 @ 12:52:
Klopt, maar zelfs de freelancer bruto 'maand' is al €35.000 euro meer dan mijn bruto salaris

Dan zou de freelancer bijna 250 euro per uur moeten vragen. Tenzij het C-level management is lijkt me dat erg veel.

[alienfruit]

Ik weet nu niet meer hoe ik aan die som kwam. Maar goed, stuk meer wat ik krijg nu terwijl ik zijn lead developer was een paar projecten terug

[Jan_V]

Skyaero schreef op dinsdag 6 juni 2017 @ 13:10:
[...]

Dan zou de freelancer bijna 250 euro per uur moeten vragen. Tenzij het C-level management is lijkt me dat erg veel.

Of geen uurtje-factuurtje opdracht, maar een fixed-fee opdracht.
Hoor daar de laatste tijd veel meer over.

"Oh, jullie willen X realiseren en dat gaat jullie Y per jaar opleveren. Dan wil ik graag 10% van de verwachte besparing/omzet Y."
Voor de freelancer een incentive om zo snel mogelijk iets op te leveren wat het X gaat behalen. Uiteraard geen garanties bieden op Y, aangezien dat te veel afhankelijk is van externe factoren.

[Rutix]

TheNephilim schreef op dinsdag 6 juni 2017 @ 12:33:
Wat een verhaal

https://twitter.com/jxxf/status/871000661869154304

Ik las het op reddit waar die stagiair om hulp vroeg. IMO heeft die een bullet gedodged dat hij daar weg is. Als je CTO zo reageert dan ben je geen goede CTO en probeer je gewoon je ass te saven.

https://np.reddit.com/r/c...d_production_database_on/

[TheNephilim]

Rutix schreef op dinsdag 6 juni 2017 @ 15:25:
[...]

Ik las het op reddit waar die stagiair om hulp vroeg. IMO heeft die een bullet gedodged dat hij daar weg is. Als je CTO zo reageert dan ben je geen goede CTO en probeer je gewoon je ass te saven.

https://np.reddit.com/r/c...d_production_database_on/

Ah, kon de reddit-thread zo gauw niet vinden. Geniale comments overigens:

Hi, guy here who accidentally nuked GitLab.com's database earlier this year. Fortunately we did have a backup, though it was 6 hours old at that point.

[Hydra]

mindcrash schreef op dinsdag 6 juni 2017 @ 10:10:
Komt waarschijnlijk omdat al het SOAP related spul bij Microsoft inmiddels deprecated is in favor of REST en JSON, en bij Oracle niet

In de tijd dat SOAP nog enigzins 'hip' was, deed MS erg z'n best een eigen draai aan een hoop zaken te geven. Het was vrijwel onmogelijk een Axis2 client met een in MS Visual Studio gemaakt de service te laten praten en vice versa.

Daarnaast is WS-Security ook nog eens een complete draak die in veel frameworks niet goed / compleet geïntegreerd is.

alienfruit schreef op dinsdag 6 juni 2017 @ 09:42:
Altijd mooi wanneer een freelancer de rekening naar heel het bedrijf mailt. Kan je mooi zien hoeveel een freelancer verdient. Toch maar eens praten met de baas

85E per uur is redelijk gangbaar hier met uitschieters naar de 100E. Als je dat online omrekent zie je ook wel waarom zoveel mensen richting ZZP-schap gaan.

[mindcrash]

TheNephilim schreef op dinsdag 6 juni 2017 @ 15:28:
[...]
Ah, kon de reddit-thread zo gauw niet vinden. Geniale comments overigens:
[...]

Ah ja, dat. Bij GitLab ging de blameless postmortem zelfs zover dat het devops team het hele restore traject van die actie live heeft gestreamed op YouTube.

[Antrax]

mindcrash schreef op dinsdag 6 juni 2017 @ 16:30:
[...]


Ah ja, dat. Bij GitLab ging de blameless postmortem zelfs zover dat het devops team het hele restore traject van die actie live heeft gestreamed op YouTube.

Klopt, ze hebben er zelfs een QA bij gedaan. Gaf wel een leuk kijkje aan de achterkant

[Rutix]

mindcrash schreef op dinsdag 6 juni 2017 @ 16:30:
[...]


Ah ja, dat. Bij GitLab ging de blameless postmortem zelfs zover dat het devops team het hele restore traject van die actie live heeft gestreamed op YouTube.

En zo hoort het . Fouten worden nu eenmaal gemaakt en die afstraffen heeft juist een verkeerd effect, mensen moeten er juist van leren.

[Rem]

Kan me ook wel een gouwe ouwe herinneren, volgens mijn sources de CEO van IBM toendertijd:

A young executive had made some bad decisions that cost the company several million dollars. He was summoned to Watson’s office, fully expecting to be dismissed. As he entered the office, the young executive said, “I suppose after that set of mistakes you will want to fire me.” Watson was said to have replied,

“Not at all, young man, we have just spent a couple of million dollars educating you.”

[Hydra]

Grappig: https://medium.com/@jjper...are-interview-ee673bc5ef6

Hoewel het niet echt overeenkomt met m'n eigen ervaringen (hier in NL proberen we nog niet en-masse Google na te doen) vond ik het wel een leuke parallel.

[Neko Koneko]

Hydra schreef op woensdag 7 juni 2017 @ 08:06:
Grappig: https://medium.com/@jjper...are-interview-ee673bc5ef6

Hoewel het niet echt overeenkomt met m'n eigen ervaringen (hier in NL proberen we nog niet en-masse Google na te doen) vond ik het wel een leuke parallel.

Als ik dat soort onzin tegen zou komen tijdens een sollicitatiegesprek denk ik dat ik het gesprek zelf beëindig, voor zo'n bedrijf wil ik niet eens werken.

[Alex)]

Ik vond het stukje over Agile nog wel het mooiste

[Hydra]

Alex) schreef op woensdag 7 juni 2017 @ 08:39:
Ik vond het stukje over Agile nog wel het mooiste

"Everything is in a flat structure, expect when it comes to salary and responsibilities."

[gekkie]

Dat noemt zich "data-analist" .. en zitten nu een minuutje of 5 te emmeren over een divide by zero .. en hebben geen idee waar het vandaan komt

[RagingPenguin]

Neko Koneko schreef op woensdag 7 juni 2017 @ 08:19:
[...]


Als ik dat soort onzin tegen zou komen tijdens een sollicitatiegesprek denk ik dat ik het gesprek zelf beëindig, voor zo'n bedrijf wil ik niet eens werken.

En dit

Well, here you will learn things you can’t learn in any other company, while still making a great impact in the world. You’ll do something meaningful, and you will never be bored. It’s an ultra high growth environment with multiple opportunities for rapid development in many areas.

– … you translate labels for pharmaceutical products.

Yes, we are changing the world, one label at a time.

Ieder hip 'agency' ooit

[ Voor 8% gewijzigd door RagingPenguin op 07-06-2017 11:34 ]

[whoami]

Het is precies niet mogelijk om een transaction isolation level te specifieren in EF Core

[gekkie]

Hrrrm grmblll .. is er dan echt geen linux image viewer met scrollwheel=zoom ?
Lijk ze onderhand wel allemaal geprobeerd te hebben , maar alles doet scrollen door de image list.

[farlane]

gekkie schreef op woensdag 7 juni 2017 @ 12:45:
Hrrrm grmblll .. is er dan echt geen linux image viewer met scrollwheel=zoom ?
Lijk ze onderhand wel allemaal geprobeerd te hebben , maar alles doet scrollen door de image list.

De Gnome image viewer doet precies dat.

[Olaf van der Spek]

gekkie schreef op woensdag 7 juni 2017 @ 12:45:
Hrrrm grmblll .. is er dan echt geen linux image viewer met scrollwheel=zoom ?
Lijk ze onderhand wel allemaal geprobeerd te hebben , maar alles doet scrollen door de image list.

Ook met Ctrl of Shift modifiers?

[gekkie]

farlane schreef op woensdag 7 juni 2017 @ 12:54:
[...]

De Gnome image viewer doet precies dat.

Die was ik ook net op het spoor , alleen bij debian hebben ze het afgekort naar eog (eye of gnome).

En nee ik wou het liefste geen keyboard modifiers erbij gebruiken (iets te veel gewend om alleen een zwengel aan m'n scrollwieltje te geven dus dan zit ik al tig images verder voordat ik een "ohnee ctrl moet erbij" ingeving krijg, ziet er niet naar uit dat ik die gewoonte nog eenvoudig af ga leren zonder het te rerouten naar een paar electroden ).

[ Voor 30% gewijzigd door gekkie op 07-06-2017 13:09 ]

[EddoH]

Ik kreeg net de volgende mail van een recruiter:

C++:

void CoolPosition(string lang; string loc; string co);

//We would like to present you an interesting C++ back-end position at [xxxxxxxx] in Amsterdam by using C++ code

#include <iostream>
#include <string>
using namespace std;

lang = "C++";
loc = "Amsterdam";
co = "[xxxxxxxx]";
static string InputInterested;

int main()
{
cout << "Dear EddoH,\n";
cout << "Cool position description:\n";
string Contract = "Fulltime";
string YearsOfXP = "&#8226; At least 3 years of back-end development XP";
string EduLevel = "&#8226; HBO degree or higher";
string ReqSkills = "&#8226; C++ / (Postgre)SQL / REST / APIs. Linux";
string PlusSkills = "&#8226; NoSQL, AWS. Experience with large systems (massive user-base, high data throughput)";
string Languages = "&#8226; Fluency in English";
cout << "This " << lang << " position is a " << Contract << " position. You will need:\n" << YearsOfXP << "\n" << EduLevel << "\n" << ReqSkills << "\n" << Languages << "\n\n";
cout << "If you possess the following skills, they are your advantage:\n" << PlusSkills << "\n\n";
cout << "We offer:\n";
cout << "&#8226; Flexible working hours and the possibility to work part-time\n";
cout << "&#8226; Market based salary and excellent working conditions\n";
cout << "&#8226; Informal atmosphere in a company where your input is highly valued\n\n";
cout << "More information can be found on our site:\n [xxxxxxxx] \n\n";

cout << "Are you interested in this C++ position in [xxxxxxxx]? Y/N";
cin >> InputInterested;

if (InputInterested == "Y")
cout << "We are glad you are interested. Please send your CV to [xxxxxxxx] or schedule a call with my colleague [xxxxxxxx] at[xxxxxxxx]" << "\n";

else 
cout << "Thank you for your reply. If you know someone who would fit the description, please forward them the message with the link.\n";

system("pause");
}

Man, man, man..
Ik weet niet zeker of het een verkapte test is om te zien of ik alle fouten/rariteiten er uit kan halen of dat het serieus bedoeld is. (Overigens de '[xxxxxxxx]' heb ik er in ge-edit vanwege privacy.)

[Damic]

Je kan terug sturen: "Will generate error's on compile"

[kenneth]

Damic schreef op woensdag 7 juni 2017 @ 15:11:
Je kan terug sturen: "Will generate error's on compile"

*errors

[orf]

EddoH schreef op woensdag 7 juni 2017 @ 15:00:
Ik kreeg net de volgende mail van een recruiter:

C++:

void CoolPosition(string lang; string loc; string co);

//We would like to present you an interesting C++ back-end position at [xxxxxxxx] in Amsterdam by using C++ code

#include <iostream>
#include <string>
using namespace std;

lang = "C++";
loc = "Amsterdam";
co = "[xxxxxxxx]";
static string InputInterested;

int main()
{
cout << "Dear EddoH,\n";
cout << "Cool position description:\n";
string Contract = "Fulltime";
string YearsOfXP = "&#8226; At least 3 years of back-end development XP";
string EduLevel = "&#8226; HBO degree or higher";
string ReqSkills = "&#8226; C++ / (Postgre)SQL / REST / APIs. Linux";
string PlusSkills = "&#8226; NoSQL, AWS. Experience with large systems (massive user-base, high data throughput)";
string Languages = "&#8226; Fluency in English";
cout << "This " << lang << " position is a " << Contract << " position. You will need:\n" << YearsOfXP << "\n" << EduLevel << "\n" << ReqSkills << "\n" << Languages << "\n\n";
cout << "If you possess the following skills, they are your advantage:\n" << PlusSkills << "\n\n";
cout << "We offer:\n";
cout << "&#8226; Flexible working hours and the possibility to work part-time\n";
cout << "&#8226; Market based salary and excellent working conditions\n";
cout << "&#8226; Informal atmosphere in a company where your input is highly valued\n\n";
cout << "More information can be found on our site:\n [xxxxxxxx] \n\n";

cout << "Are you interested in this C++ position in [xxxxxxxx]? Y/N";
cin >> InputInterested;

if (InputInterested == "Y")
cout << "We are glad you are interested. Please send your CV to [xxxxxxxx] or schedule a call with my colleague [xxxxxxxx] at[xxxxxxxx]" << "\n";

else 
cout << "Thank you for your reply. If you know someone who would fit the description, please forward them the message with the link.\n";

system("pause");
}

Man, man, man..
Ik weet niet zeker of het een verkapte test is om te zien of ik alle fouten/rariteiten er uit kan halen of dat het serieus bedoeld is. (Overigens de '[xxxxxxxx]' heb ik er in ge-edit vanwege privacy.)

Mooi! Die kun je ook hier delen: de shitpraktijken van recruiters

[Olaf van der Spek]

Damic schreef op woensdag 7 juni 2017 @ 15:11:
Je kan terug sturen: "Will generate error's on compile"

Niet zoveel als je misschien verwacht.

[Bosmonster]

Ipv ls -la ~/ typte ik in een brainfart ineens rm -rf ~/

Heel snel ctrl-C geramd, maar ben toch wel wat dingen kwijt....

[Damic]

Olaf van der Spek schreef op woensdag 7 juni 2017 @ 16:20:
[...]

Niet zoveel als je misschien verwacht.

Zou het niet weten ken geen Cpp

[whoami]

Bosmonster schreef op woensdag 7 juni 2017 @ 16:20:
Ipv ls -la ~/ typte ik in een brainfart ineens rm -rf ~/

Waarom

[EddoH]

Olaf van der Spek schreef op woensdag 7 juni 2017 @ 16:20:
[...]

Niet zoveel als je misschien verwacht.

Genoeg?

code:

main.cpp:1:19: error: variable or field 'CoolPosition' declared void
main.cpp:1:19: error: 'string' was not declared in this scope
main.cpp:1:32: error: 'string' does not name a type
main.cpp:1:44: error: 'string' does not name a type
main.cpp:9:1: error: 'lang' does not name a type
main.cpp:10:1: error: 'loc' does not name a type
main.cpp:11:1: error: 'co' does not name a type
main.cpp: In function 'int main()':
main.cpp:24:20: error: 'lang' was not declared in this scope
main.cpp:41:15: error: 'system' was not declared in this scope
make[2]: *** [main.o] Error 1

[ Voor 62% gewijzigd door EddoH op 07-06-2017 16:34 ]