De Devschuur Coffee Corner - Iteratie ➒

[F.West98]

Jegorex schreef op vrijdag 10 juli 2015 @ 15:15:
[...]

Je weet dat je vanuit Canada betere fotos kunt maken van de Niagara Falls?

Ja, we gaan dus ook via Toronto

[Mercatres]

Alex) schreef op vrijdag 10 juli 2015 @ 15:16:
[...]

Ik stond op een Djurgårdenferry

Een paar jaar geleden heb ik ook enkele uurtjes moeten wachten (op de nachttrein naar Narvik) heb ik aan het hoekpunt van Galarparken gezeten, gezellig in de zon, boekje, uitzicht op het water... heerlijk. Stockholm heeft een positieve indruk achtergelaten

[Siebsel]

Wij twijfelen nog om in de vakantie een stedentrip Stockholm te doen, maar dat is dus wel aan te raden als ik dat hier zo lees?

[OkkE]

Stockholm is vind ik zeker een toffe stad; eigenlijk is vind ik heel Zweden een prima (vakantie) land.

[ Voor 17% gewijzigd door OkkE op 10-07-2015 16:41 ]

[ZaZ]

OkkE schreef op vrijdag 10 juli 2015 @ 15:46:
Dat is inderdaad ergernis nummer één: “het is kapot” of “het werkt niet (meer)” ...

Daar is maar één antwoord op: “Niet reproduceerbaar.”

Al zo vaak meegemaakt:
"Het is kapot"
-"Ok, wat is er dan kapot?"
"Het programma"
-"Ja ok, maar geeft ie nog een foutmelding of iets dergelijks?"
"Ja"
-"En wat staat er dan in die foutmelding?"
"Dat ie het niet doet."

And so on

[F.West98]

Argh EF.
Database backup maken en op andere computer terugzetten in de hoop dat hij automagisch herkent dat de migrations al gedaan zijn.
Natuurlijk werkt dat niet... Nu heb ik dus pending changes, veranderingen in het model, en gaat het allemaal fijn mis

* F.West98 checkt in, doet de migrations op de andere computer en zo werkt het ook

edit:
Nvm.
Argh EF. Als je je namechange wijzigt gaan alle migrations ook de soep in...

[ Voor 12% gewijzigd door F.West98 op 10-07-2015 17:01 ]

[CodeCaster]

Wat wordt er toch een hoop geprutst in onze branche. Vannacht kreeg ik een mail van een club waar ik ooit lid van was:

Wij hebben je bestelling goed ontvangen. Hierbij bevestigen wij de verzending van je bestelling.

[Lege lijst]

Het Track & Trace-zendingsnummer van deze bestelling is 3SDMG [sic].

Zojuist kreeg ik daar een excuusmail overheen:

Door een fout in de processen rondom database en server is deze e-mail automatisch verzonden

(Er is ook een topic over deze mails).

Oftewel slecht getest, of er heeft iemand met z'n fikken aan de verkeerde knop gezeten. Hoe kan dit nu gebeuren? Het vak van programmeren houdt niet op bij een stuk code succesvol kunnen laten parsen. De meeste opleidingen richten zich op het stuk vóór het daadwerkelijke intikken van deze code. Wat erna met die code gebeurt daarentegen...

Testen is een vak. Build-automatisering is een vak. Packaging is een vak. Releasen is een vak. Ik zie en hoor echter zo vaak dat men gewoon vanuit de IDE een release voorbereidt (F6...) en via het filesystem op een server dumpt, of dat er vanaf workstations op de live-omgeving wordt gewerkt. Dit. Mag. Niet.

Zijdelings gerelateerde, nutteloze poll: hoe gaat dat er bij jullie aan toe? Heb jij een SQL Server Management Studio op je workstation waarmee je bij productie kan? Heb je dan ook schrijfrechten? Voer jij een update op live uit vanaf je eigen machine? Dump jij je executables via een netwerkshare op de server?

Poll: Kun jij vanaf je workstation bij een productieomgeving?
• Ja
• Nee
<sup>Tussenstand:

Ook een poll maken? Klik hier</sup>

Ach, het houdt ons aan het werk.

[Korben]

CodeCaster schreef op vrijdag 10 juli 2015 @ 17:28:
Wat wordt er toch een hoop geprutst in onze branche. Vannacht kreeg ik een mail van een club waar ik ooit lid van was:


[...]


Zojuist kreeg ik daar een excuusmail overheen:

[...]


(Er is ook een topic over deze mails).

Oftewel slecht getest, of er heeft iemand met z'n fikken aan de verkeerde knop gezeten. Hoe kan dit nu gebeuren? Het vak van programmeren houdt niet op bij een stuk code succesvol kunnen laten parsen. De meeste opleidingen richten zich op het stuk vóór het daadwerkelijke intikken van deze code. Wat erna met die code gebeurt daarentegen...

Testen is een vak. Build-automatisering is een vak. Packaging is een vak. Releasen is een vak. Ik zie en hoor echter zo vaak dat men gewoon vanuit de IDE een release voorbereidt (F6...) en via het filesystem op een server dumpt, of dat er vanaf workstations op de live-omgeving wordt gewerkt. Dit. Mag. Niet.

Zijdelings gerelateerde, nutteloze poll: hoe gaat dat er bij jullie aan toe? Heb jij een SQL Server Management Studio op je workstation waarmee je bij productie kan? Heb je dan ook schrijfrechten? Voer jij een update op live uit vanaf je eigen machine? Dump jij je executables via een SMB-share op de server?

Poll: Kun jij vanaf je workstation bij een productieomgeving?
• Ja
• Nee
^Tussenstand:
[afbeelding]
^{Ook een poll maken? Klik hier}

Ach, het houdt ons aan het werk.

Je kunt wel heel zwart-wit zeggen dat je niet vanaf je workstation bij de productie-omgeving mag, maar soms moet dat toch om zaken te kunnen reproduceren.

[Mercatres]

Op je vraag: nu nog wel, maar zeer binnenkort niet meer. Acceptatie-omgeving, testomgevingen enz...

[CodeCaster]

Korben schreef op vrijdag 10 juli 2015 @ 17:29:
[...]

Je kunt wel heel zwart-wit zeggen dat je niet vanaf je workstation bij de productie-omgeving mag, maar soms moet dat toch om zaken te kunnen reproduceren.

Ik ben echt niet Roomser dan de paus (freelance, dus voor mij stopt de verantwoordelijkheid zo ongeveer bij de schriftelijke suggestie om het anders te doen), maar als alles netjes is geregeld, vraag je de beheerders dan om een dump van productie naar een andere omgeving te maken en te anonimiseren. Of dat praktisch is, is een tweede. Als het móet, heb ik dan bij voorkeur read-onlyrechten.

[ Voor 14% gewijzigd door CodeCaster op 10-07-2015 17:37 ]

[Ryur]

CodeCaster schreef op vrijdag 10 juli 2015 @ 17:28:
Poll: Kun jij vanaf je workstation bij een productieomgeving?

Ach, het houdt ons aan het werk.

Ik mis de optie: Ja ik kan erbij, maar zonder schrijfrechten!
Alleen voor een backup te maken (die automatisch wordt geannonimiseerd) en die lokaal te importeren en te reproduceren

En ik kan ook niet bij alle klanten, alleen de klanten waar ik ook verantwoordelijk voor ben (oke, in mijn geval zijn dat de meeste )

[ Voor 19% gewijzigd door Ryur op 10-07-2015 17:36 ]

[CodeCaster]

Ryur schreef op vrijdag 10 juli 2015 @ 17:34:
zonder schrijfrechten! automatisch geanonimiseerd

Goed bezig. Ik ga de poll nu niet meer aanpassen.

[Ryur]

Note: ik kan wel bekijken in werkelijke info; praat wat makkelijk als je het hebt over Resource/Employee Henk Westers.
Maar zodra ik een backup maak is het anonieme data, dus dan pak ik het op ID's.

[Megamind]

CodeCaster schreef op vrijdag 10 juli 2015 @ 17:28:
Wat wordt er toch een hoop geprutst in onze branche. Vannacht kreeg ik een mail van een club waar ik ooit lid van was:

Poll: Kun jij vanaf je workstation bij een productieomgeving?

Hoe bedoel je dit? Ja ik kan RDP'en naar alle prod servers, hoe zou ik er anders bij moeten komen

Maar er gaan echt geen SQL, FTP of web publish shit poorten open naar de servers, alles netjes via TeamCity en Octopus.

Alleen zou het wel leuk zijn dat Octopus een optie heeft om bv 2 factor auth te geven als iemand (per ongeluk) naar live deployed

[CodeCaster]

Megamind schreef op vrijdag 10 juli 2015 @ 17:43:
Ja ik kan RDP'en naar alle prod servers, hoe zou ik er anders bij moeten komen

Waaróm zou je erbij moeten kunnen? Package de boel en lever het af aan het systeem / de persoon die de deployments doet. Deze zet de package vervolgens op de test- / acceptatieomgeving, waarna hetzelfde package na goedkeuring van wie dan ook automagisch naar productie wordt uitgerold.

Ideale wereld, I know...

Uiteraard kun je deze persoon als developer ook zelf zijn, maar dan zou ik inderdaad op z'n minst een ander account verwachten dat alleen via iets als RDP bij die systemen kan.

TeamCity en Octopus klinken ook goed. Ik wil wel meer leren over deployment (met name automatisch), want ik kom maar zelden tegen dat het "goed" (volgens míjn huidige opvattingen ) is ingericht en wil daar meer mee gaan doen.

[ Voor 34% gewijzigd door CodeCaster op 10-07-2015 17:54 ]

[Megamind]

CodeCaster schreef op vrijdag 10 juli 2015 @ 17:45:
[...]

Waaróm zou je erbij moeten kunnen? Package de boel en lever het af aan het systeem / de persoon die de deployments doet. Deze zet de package vervolgens op de test- / acceptatieomgeving, waarna hetzelfde package na goedkeuring van wie dan ook automagisch naar productie wordt uitgerold.

Ideale wereld, I know...

Uiteraard kun je deze persoon als developer ook zelf zijn, maar dan zou ik inderdaad op z'n minst een ander account verwachten dat alleen via iets als RDP bij die systemen kan.

TeamCity en Octopus klinken ook goed. Ik wil wel meer leren over deployment, ik kom maar zelden tegen dat het "goed" (volgens míjn huidige opvattingen ) is ingericht.

Die persoon ben ik, maarja in een bedrijf met 4 devvers moet je wel wat flexibel zijn.

Overigens heb alleen ik en de andere senior toegang tot prod, de rest alleen test en acceptatie.

Bij ons is TC + Octopus best goed ingericht (denk ik dan). Bij een commit naar develop wordt er automatisch een build gemaakt en naar de test sites gepushed. Als je een merge of commit maakt naar de release branch dan wordt er een build gemaakt en de package klaargezet, die moet je dan handmatig deployen naar UAT. Na goedkeuring wordt de UAT package gedeployed naar live. Werkt tot nu toe perfect, zeker omdat je met meerdere mensen gewoon kan comitten en het vanzelf op de test server terecht komt.

[ Voor 20% gewijzigd door Megamind op 10-07-2015 17:52 ]

[.oisyn]

CodeCaster schreef op vrijdag 10 juli 2015 @ 17:28:
Poll: Kun jij vanaf je workstation bij een productieomgeving?
• Ja
• Nee
^Tussenstand:
[afbeelding]
^{Ook een poll maken? Klik hier}

Ach, het houdt ons aan het werk.

Je vergeet click bait erin te verwerken voor hen voor wie de vraag (of de antwoorden) niet van toepassing is

[Firesphere]

CodeCaster schreef op vrijdag 10 juli 2015 @ 17:36:
[...]

Goed bezig. Ik ga de poll nu niet meer aanpassen.

Ik ben kan rooten op elke test/acceptatie/productieserver als ik dat wil. Geen probleem. Gezeik met read-only enzo.

[CodeCaster]

.oisyn schreef op vrijdag 10 juli 2015 @ 18:33:
[...]


Je vergeet click bait erin te verwerken voor hen voor wie de vraag (of de antwoorden) niet van toepassing is

Kun jij op de laatste dag code committen die ongecontroleerd meegaat met de final build (of hoe werkt dat bij jullie)?

Firesphere schreef op vrijdag 10 juli 2015 @ 18:50:
[...]

Ik ben kan rooten op elke test/acceptatie/productieserver als ik dat wil. Geen probleem. Gezeik met read-only enzo.

Jij bent dan ook een cowboy.

[ Voor 26% gewijzigd door CodeCaster op 10-07-2015 19:09 ]

[Douweegbertje]

CodeCaster schreef op vrijdag 10 juli 2015 @ 17:45:
[...]

Waaróm zou je erbij moeten kunnen? Package de boel en lever het af aan het systeem / de persoon die de deployments doet. Deze zet de package vervolgens op de test- / acceptatieomgeving, waarna hetzelfde package na goedkeuring van wie dan ook automagisch naar productie wordt uitgerold.

Ideale wereld, I know...

Uiteraard kun je deze persoon als developer ook zelf zijn, maar dan zou ik inderdaad op z'n minst een ander account verwachten dat alleen via iets als RDP bij die systemen kan.

TeamCity en Octopus klinken ook goed. Ik wil wel meer leren over deployment (met name automatisch), want ik kom maar zelden tegen dat het "goed" (volgens míjn huidige opvattingen ) is ingericht en wil daar meer mee gaan doen.

Omdat het een kosten en baten verhaal is die overal anders kan zijn?..

[.oisyn]

CodeCaster schreef op vrijdag 10 juli 2015 @ 19:09:
[...]

Kun jij op de laatste dag code committen die ongecontroleerd meegaat met de final build (of hoe werkt dat bij jullie)?

Ja
Al zou ik wel wat mensen moeten overtuigen dat hij erin moet.

[ Voor 11% gewijzigd door .oisyn op 10-07-2015 19:12 ]

[Firesphere]

CodeCaster schreef op vrijdag 10 juli 2015 @ 19:09:
[...]

Jij bent dan ook een cowboy.

Hoezo is root toegang hebben gevaarlijk dan?

[CodeCaster]

Douweegbertje schreef op vrijdag 10 juli 2015 @ 19:10:
Omdat het een kosten en baten verhaal is die overal anders kan zijn?..

Firesphere schreef op vrijdag 10 juli 2015 @ 19:13:
[...]

Hoezo is root toegang hebben gevaarlijk dan?

Ik doelde op je avatar. Zeker bij kleinere groepen ontwikkelaars (laat staan eenmanszaken waarbij alles door één persoon wordt gedaan) is het beheer en de controle natuurlijk een stuk eenvoudiger.

[ Voor 30% gewijzigd door CodeCaster op 10-07-2015 19:21 ]

[Firesphere]

CodeCaster schreef op vrijdag 10 juli 2015 @ 19:17:
[...]

Ik doelde op je avatar. Zeker bij kleinere bedrijven (laat staan eenmanszaken waarbij álles door één persoon wordt gedaan) is het beheer en de controle een stuk eenvoudiger.

Die zag ik niet aankomen

[Douweegbertje]

Ik werk in de dev omgeving met de live database. We hebben svn, en in de dev meerdere 'test' omgevingen oftewel clean checkouts. Meuk word gewoon met filezilla online gezet en klaar.

[Firesphere]

Douweegbertje schreef op vrijdag 10 juli 2015 @ 19:21:
Ik werk in de dev omgeving met de live database. We hebben svn, en in de dev meerdere 'test' omgevingen oftewel clean checkouts. Meuk word gewoon met filezilla online gezet en klaar.

Filezilla
https://trac.filezilla-project.org/ticket/5530

[Douweegbertje]

Boeiend. Kan je toch niet bij.

[Firesphere]

Douweegbertje schreef op vrijdag 10 juli 2015 @ 19:24:
Boeiend. Kan je toch niet bij.

Maar een fijn stukje software, zeg angler, wel

Maargoed, voor die discussie is een ander topic, hier.
https://gathering.tweakers.net/forum/list_messages/1580769

[ Voor 23% gewijzigd door Firesphere op 10-07-2015 19:28 ]

[Alex)]

Siebsel schreef op vrijdag 10 juli 2015 @ 16:37:
Wij twijfelen nog om in de vakantie een stedentrip Stockholm te doen, maar dat is dus wel aan te raden als ik dat hier zo lees?

Ja, Zweden is aan te raden.

Zorg wel voor een enigszins gevulde portemonnee, het is wat duurder dan je gewend bent.

[Alex)]

CodeCaster schreef op vrijdag 10 juli 2015 @ 17:28:

Zijdelings gerelateerde, nutteloze poll: hoe gaat dat er bij jullie aan toe? Heb jij een SQL Server Management Studio op je workstation waarmee je bij productie kan? Heb je dan ook schrijfrechten? Voer jij een update op live uit vanaf je eigen machine? Dump jij je executables via een netwerkshare op de server?

Test/Acc/Prod staan in een aparte omgeving waar ik vanaf m'n workstation niet bij kan, enkel via een Citrixportal. Ik kan dus niet rechtstreeks vanuit Visual Studio een deployment doen.

Ik heb een buildscriptje dat alles bouwt, wat bestanden kopieert, en uiteindelijk een zipfile genereert met daarin het hele pakket. In dat pakket zitten ook deploymentscripts voor o.a. website en database.

Ik heb toegang tot de productieomgeving, maar daar probeer ik niet te komen. Als ik er al kom gaat het hoogstens om het uitlezen van wat logs, en daarna zo snel mogelijk wegwezen. Naar Test en Acc deploy ik zelf, als er iets naar Productie moet is het een gevalletje "Hoi beheerdersteam, ik heb een pakketje gebouwd dat op <server X> in de deploymentsfolder staat."

[BikkelZ]

Megamind schreef op vrijdag 10 juli 2015 @ 17:50:
[...]

Als je een merge of commit maakt naar de release branch dan wordt er een build gemaakt en de package klaargezet, die moet je dan handmatig deployen naar UAT. Na goedkeuring wordt de UAT package gedeployed naar live. Werkt tot nu toe perfect, zeker omdat je met meerdere mensen gewoon kan comitten en het vanzelf op de test server terecht komt.

Ik wil binnenkort zelf ook aan de slag met develop -> test, master -> staging en dan met een handmatige goedkeuring de farm flippen. Wat bedoel je precies met UAT? Werk jij ook met database scripts? Rollback scenarios?

[Damic]

*shit verkeerd topiek*

[ Voor 76% gewijzigd door Damic op 10-07-2015 20:18 ]

[Ryur]

Misschien slim om de discussie van het deployen af te splitsen?
Wel een topic wat ik beter wil volgen

[Firesphere]

Ryur schreef op vrijdag 10 juli 2015 @ 20:46:
Misschien slim om de discussie van het deployen af te splitsen?
Wel een topic wat ik beter wil volgen

Maak een TR aan

[Megamind]

BikkelZ schreef op vrijdag 10 juli 2015 @ 19:42:
[...]


Ik wil binnenkort zelf ook aan de slag met develop -> test, master -> staging en dan met een handmatige goedkeuring de farm flippen. Wat bedoel je precies met UAT? Werk jij ook met database scripts? Rollback scenarios?

User Acceptance Test.

Test (privé intern) -> UAT (klant testen) -> Live (Klant blij).

Wij gebruiken DB migrations van Entity Framework. Als er een deployment wordt gedaan worden die automatisch gedraaid.

Een rollback zal waarschijnlijk deel handmatig moeten gaan, al zou het theoretisch wel kunnen met EF migrations.

[Douweegbertje]

Firesphere schreef op vrijdag 10 juli 2015 @ 19:28:
[...]

Maar een fijn stukje software, zeg angler, wel

Maargoed, voor die discussie is een ander topic, hier.
https://gathering.tweakers.net/forum/list_messages/1580769

Ja ok, maar het is irrelevant voor mij. Ik ben mij bewust van de 'gevolgen', zij het niet dat ik in een afgeschermde omgeving zit en in feite 'ftp binnen de cloud' Hence maakt het niet uit.
In elke andere omgeving zal ik er inderdaad anders mee omgaan


Maar ook deels mijn punt.. elk bedrijf / applicatie of wat dan ook is anders (om weer terug te gaan naar het deployen en dev'en). Er bestaat geen standaard van "Het moet zo", of "Dit is de best-practice".

[F.West98]

Ik kan op m'n werk niet bij de productie-omgeving (denk ik tenminste, nooit geprobeerd, ken het IP niet ) maar ik kan wel inloggen als admin in het beheerpaneel van de applicatie en met één druk op de knop alle live-data weggooien

Met eigen projectjes doe ik gewoon heel simpel:
Webapplicatie: Code kloppen, testen, inchecken, deployen en fingers crossed
Androidapp: Merge naar master, apk genereren, commit taggen, uploaden op GH en in de Play Store en klaar.
Maar ik denk dat met eigen projectjes niemand hele stagingdingen gaat opzetten enzo

[Douweegbertje]

F.West98 schreef op vrijdag 10 juli 2015 @ 22:40:
Maar ik denk dat met eigen projectjes niemand hele stagingdingen gaat opzetten enzo

Niet denken
Als het handig is voor het project, why not.
Gewoon precies het zelfde wat ik dus al eerder zei.. je pakt wat eventueel nodig is, en soms doe je dingen ook weer anders omdat reden x, y of z. Nogal project afhankelijk IMO.

Ik heb ooit voor nodejs wel een staging gebruikt omdat het deployen voor mij met een factor 10 makkelijker werd ivm verschillende servers en meuk. En ja, dat was gewoon een eigen projectje.

[F.West98]

Douweegbertje schreef op vrijdag 10 juli 2015 @ 22:43:
[...]


Niet denken
Als het handig is voor het project, why not.
Gewoon precies het zelfde wat ik dus al eerder zei.. je pakt wat eventueel nodig is, en soms doe je dingen ook weer anders omdat reden x, y of z. Nogal project afhankelijk IMO.

Ik heb ooit voor nodejs wel een staging gebruikt omdat het deployen voor mij met een factor 10 makkelijker werd ivm verschillende servers en meuk. En ja, dat was gewoon een eigen projectje.

Ik zit ook wel te overwegen iets in te richten voor automatisch testen en bij commit naar master deployen, maar het werkt allemaal nog niet helemaal goed.

[Alex)]

Ik heb ooit wel eens een check-in+build-dingetje gebouwd tijdens een projectje. Ik devde lokaal, op het moment dat ik incheckte ging TFS het bouwen. En IIS gebruikte de outputdirectory weer als webroot, dus bij iedere check-in ging er een nieuwe versie live.

[Caelorum]

Ik zit dagelijks op de productieomgeving. Komt ook omdat er geen testomgeving is ^^ Alles gaat direct met de (live) database.
Veroorzaakt wel eens problemen (eens in de paar jaar) en hartverzakkingen hoor. Laatste hartverzakking was toen ik een deel van de where clause was vergeten in een update query
Gelukkig wordt er hard aan gewerkt om alles in orde te brengen


Dit alles heeft overigens wel mijn beeld versterkt. Al die aparte omgevingen zijn erg handig, maar niet direct noodzakelijk. Zonder al die dingen kan je nog steeds een fatsoenlijk product opleveren alleen iedereen die er aan werkt moet wel verdomde goed nadenken voordat ze iets doen. Als je daar niet vanuit kan gaan, moet je als een gek een aparte testomgeving maken.

[ Voor 33% gewijzigd door Caelorum op 10-07-2015 23:25 ]

[Alex)]

Het hebben van 4 (of zelfs 5) omgevingen is lang niet altijd nodig, maar om nou te gaan zitten cowboycoden op prod? Je zegt het zelf al, een foutje (zoals een ontbrekende where) is zo gemaakt...

[dcm360]

Op zijn minst 2 omgevingen hebben vind ik wel noodzakelijk, zeker als het om een serieuzere productie-omgeving gaat (oftewel: het kost geld als die plat gaat). Nu ik het zo bedenk kom ik eigenlijk meestal ook maar net aan die 2, met Play! is dat best eenvoudig, en bij mijn grootste klant is er een live-omgeving en een dev-omgeving sinds er te vaak dingen op de live site stuk gingen. En dan ook nog een experimentele omgeving erbij waarop ik zelf ontwikkel, maar die op een compleet andere software-stack draait. Die laatste is eens ontstaan toen een provider een domein kwijtgemaakt had en de dev-omgeving het niet meer deed, en is blijven hangen omdat de eigenlijke dev-omgeving niet vooruit te branden is... (nginx+hhvm wint heel erg hard op performance van Apache2+PHP5.3)

[Douweegbertje]

We hebben gewoon een dev code base maar live db. DB wijziging die niet zo boeiend is voer je op de live uit met gewoon een select als eerst om vervolgens de output te bekijken voordat je een update/delete doet. Moeilijkere dingen doe je dan op de dev omgeving eerst, desnoods wordt er een kopie nog van de live data set gemaakt van die specifieke table.
Dev database is gewoon niet echt mogelijk omdat je de daadwerkelijke verse data wilt hebben.. kosten plaatje is erg groot om dat te updaten.

In de ~3 jaar dat ik er nu werk is er werkelijkwaar nooit iets fout gegaan vanwege bovenstaande werkwijze.

Stel dat; eens in het jaar is er een fuck up.. dan soit.. voor het "gemak" en weinig kosten waar je dan mee werkt is daar mee te leven.

[ Voor 10% gewijzigd door Douweegbertje op 11-07-2015 00:26 ]

[Alex)]

Douweegbertje schreef op zaterdag 11 juli 2015 @ 00:25:

Dev database is gewoon niet echt mogelijk omdat je de daadwerkelijke verse data wilt hebben.. kosten plaatje is erg groot om dat te updaten.

Een scriptje dat periodiek een backup van prod restoret naar dev is toch niet zo veel werk?

[Caelorum]

Alex) schreef op vrijdag 10 juli 2015 @ 23:27:
Het hebben van 4 (of zelfs 5) omgevingen is lang niet altijd nodig, maar om nou te gaan zitten cowboycoden op prod? Je zegt het zelf al, een foutje (zoals een ontbrekende where) is zo gemaakt...

Mja, de oorzaak heb ik hier al eens eerder (vaag) uitgelegd. Laten we zeggen dat de reden hiervoor voor mij erg duidelijk en redelijk is. Ideaal is het absoluut niet, maar verder wat Douweegbertje zegt. Er is niet een strikte scheiding tussen live en dev data, maar lokaal testen doen we uiteraard wel.

[...]
Stel dat; eens in het jaar is er een fuck up.. dan soit.. voor het "gemak" en weinig kosten waar je dan mee werkt is daar mee te leven.[...]

Een hele dag aan werk van je klanten dat weg is, doordat een backup (deelS) terug moet worden gezet is wel nogal pijnlijk. Persoonlijk vind ik een gescheiden test, dev en productieomgeving wel een must, maar niet altijd haalbaar. Elk bedrijf moet er echter wel naar streven om in die situatie te eindigen.

Alex) schreef op zaterdag 11 juli 2015 @ 00:31:
[...] Een scriptje dat periodiek een backup van prod restoret naar dev is toch niet zo veel werk?

Moet je wel een tweede server hebben en die kosten zijn soms gewoon te hoog.

[ Voor 11% gewijzigd door Caelorum op 11-07-2015 00:33 ]

[Douweegbertje]

Alex) schreef op zaterdag 11 juli 2015 @ 00:31:
[...]

Een scriptje dat periodiek een backup van prod restoret naar dev is toch niet zo veel werk?

Klopt.
En?

(mssql trouwens)
Je zou eventueel een daadwerkelijke copy kunnen doen met bijv. echt fysieke verplaatsing wat al aardig scheelt qua tijd en performance. Hier zitten ook nadelen aan, bijv dat de dev omgeving dan tijdelijk z'n table mist.
Of je doet een import, maar dan moet je truncaten op de dev, en je belast de live ook nog eens.
Of je doet echt een sql uitvoeren, maar dan belast je alsnog live en dev en wil je dit relatief snel doen dan zul je de indexes eraf moeten halen en daarna weer rebuilden.
Bij de laatste 2 opties moet je sowieso weer werken aan je indexes etc.

Kijk, zo'n scriptje is misschien leuk voor een dataset van een paar duizend records, maar ik heb het over miljoenen records en dan zit je al totaal anders qua performance.

Ik zit al zwaar vast qua performance op de live, die zit namelijk 24/7 op 80-90% CPU en dik geheugen, echter qua kosten valt alles mee. Indien je echt iets wilt met repliceren c.q. mirroring of wat dan ook.. dan gaat je kostenplaatje een heel stuk omhoog.


Wellicht als je hier komt en er nog geen !(@* van snapt denk je dat het allemaal enorm crap en amateuristisch is. Na een half jaar weet je meer en zul je dat gevoel nog sterker hebben. Echter als je vervolgens alle ins en outs weet en rekening houdt met de bedrijfsvoering en daadwerkelijk kijkt naar wat er allemaal staat met de huidige resources (servers/personeel etc) begin je op zich te beseffen dat het ondanks vele zogenaamde flaws, het allemaal redelijk in elkaar zit. Bijvoorbeeld Tweakers heeft meerdere malen fuckups online gezet terwijl ze naar mijn weten wel meerdere omgevingen hebben en qua 'flow' redelijk professioneel zijn. Dus welke garanties heb je nu eigenlijk daadwerkelijk?
Zoals ik zei heb ik in 3 jaar tijd geen enkele fuckup gehad vanwege de manier van werken.

Ik heb alleen ooit eens de live db set verneukt omdat ik injections zat te testen en per ongeluk dat op de live omgeving zat te doen.. Dat is meer een kwestie van even wakker worden

[BikkelZ]

Megamind schreef op vrijdag 10 juli 2015 @ 21:09:
[...]

User Acceptance Test.

Test (privé intern) -> UAT (klant testen) -> Live (Klant blij).

Wij gebruiken DB migrations van Entity Framework. Als er een deployment wordt gedaan worden die automatisch gedraaid.

Een rollback zal waarschijnlijk deel handmatig moeten gaan, al zou het theoretisch wel kunnen met EF migrations.

Het zou op zich wel fijn zijn dat de klant zelf met één druk op de knop live kan gaan. "Weet u zeker dat u voldoende getest heeft? Ja / Nee".

Ik heb een code first EF project van iemand over genomen, natuurlijk geen compound key ingesteld of dat soort fratsen. Ben toch zelf meer dan de DB first. Ik schrijf forward / backward scripts zodat ik ook makkelijker tussen branches kan switchen.

[BikkelZ]

Megamind schreef op vrijdag 10 juli 2015 @ 21:09:
[...]

User Acceptance Test.

Test (privé intern) -> UAT (klant testen) -> Live (Klant blij).

Wij gebruiken DB migrations van Entity Framework. Als er een deployment wordt gedaan worden die automatisch gedraaid.

Een rollback zal waarschijnlijk deel handmatig moeten gaan, al zou het theoretisch wel kunnen met EF migrations.

Het zou op zich wel fijn zijn dat de klant zelf met één druk op de knop live kan gaan. "Weet u zeker dat u voldoende getest heeft? Ja / Nee".

Ik heb een code first EF project van iemand over genomen, natuurlijk geen compound key ingesteld of dat soort fratsen. Ben toch zelf meer dan de DB first. Ik schrijf forward / backward scripts zodat ik ook makkelijker tussen branches kan switchen.

Douweegbertje schreef op zaterdag 11 juli 2015 @ 01:23:
[...]

Ik zit al zwaar vast qua performance op de live, die zit namelijk 24/7 op 80-90% CPU en dik geheugen, echter qua kosten valt alles mee. Indien je echt iets wilt met repliceren c.q. mirroring of wat dan ook.. dan gaat je kostenplaatje een heel stuk omhoog.

[blah blah blah]

Ik heb alleen ooit eens de live db set verneukt omdat ik injections zat te testen en per ongeluk dat op de live omgeving zat te doen.. Dat is meer een kwestie van even wakker worden

Oh ja dat soort omgevingen zijn altijd wel interessant. Ooit een keer op die manier bij de grootste ticketboer van Nederland de live database weggeflikkerd en het enige wat me redde was een time-out op de transaction omdat de server permanent op >90% stond.

Weet je dat je angst echt kunt proeven in je eigen mond? Soort rare ijzersmaak is het.

[Douweegbertje]

Ja ik lig meestal niet zo wakker van dingen die fout gaan. Niet dat ik er niet om geef (al word dat vaak gesuggereerd..) maar ik vind het altijd handig om gewoon chill te blijven zoals altijd om iets op te lossen. Wellicht word ik angstig als er data weg is en de provider zegt dat de backups corrupt zijn of iets dergelijks
Technisch gezien zou dat ook gewoon betekenen dat meerdere bedrijven failliet gaan en 100den op straat komen te staan als alle data verloren is. In feite wel bizar als je er zo over nadenkt.

[SPee]

En dan wil je niet als bedrijf die zekerheid bieden door 1000 euro per jaar aan een ontwikkel omgeving te betalen?
Leuk dat ze daar geld op willen besparen. Maar wel dure tools aanschaffen, waar je amper wat van gebruikt

[Douweegbertje]

Je trekt echt kromme conclusies.

[DamadmOO]

Bij ons restoren we (waar mogelijk) elke week automatisch de productie database (ook mssql) naar de test servers. De dev servers doen we elke keer als we een nieuwe sprint beginnen. Op zowel de dev als test servers gebruiken we developer edition en dat kost dan 40 euro per ontwikkelaar per jaar. Na de restore draaien we per applicatie een script om de productie config om te zetten naar hetgeen wat nodig is op dev of test.

De backup die we gebruiken voor het restoren is altijd een point-in-time restore van de productie backups (en meestal is het een combinatie van full, diff en log backups), dit heeft als voordeel dat we elke testen dat we onze productie backups kunnen restoren en dat we precies weten hoeveel tijd dat in beslag neemt. Hiermee hebben we ook kijk op de RTO van onze database servers die we maandelijks afstemmen met onze SLA's.

[JohnHeroHD]

Is het niet tricky om productie db's te restoren naar dev/test db's? Ik kan me voorstellen dat dev/test servers qua beveiliging iets minder strak staan, je moet er als developer toch goed bijkunnen. Hoe zit het dan met eventuele user tabellen in die db's die gestored worden? Worden die leeggemaakt en vervangen door dev accounts? Of denk aan andere tabellen die gevoelige informatie kunnen bevatten.

[Douweegbertje]

JohnHeroHD schreef op zaterdag 11 juli 2015 @ 21:24:
Is het niet tricky om productie db's te restoren naar dev/test db's? Ik kan me voorstellen dat dev/test servers qua beveiliging iets minder strak staan, je moet er als developer toch goed bijkunnen. Hoe zit het dan met eventuele user tabellen in die db's die gestored worden? Worden die leeggemaakt en vervangen door dev accounts? Of denk aan andere tabellen die gevoelige informatie kunnen bevatten.

Waarom zou dat minder strak moeten staan? Bij ons is het juist 'strakker' omdat je er niet eens remote bij kan (port 80 of beter gezegd 443). Ik doe gewoon een RDP naar de dev bak, en vanuit daar kan ik ook bij de live db.

[orf]

Wij draaien op productie master-master-slave. De slave is alleen voor backups en daardoor draait de normale database lekker door terwijl er een backup getrokken wordt.

Developers hebben wel toegang tot de productieomgeving, maar deployen doen we met deployHQ. Database aanpassingen gaan met migrations. Voor oude projecten waar geen migrations gebruikt worden hebben we een diff tooltje die de verschillen tussen acceptatie en productie laat zien. Aanpassingen doen we dan met de SQL-output van dat tooltje.

Binnenkort gaat de database van ons platform af (private cloud). Databases gaan dan bare metal draaien op flinke machines. Met 256GB ram kan de dataset helemaal in ram gaan draaien. IO is nu het zwaarst belast en zou als eerste de bottleneck worden. Daarom krijgen die machines ook mooie SSD's. Best mooi hoe we van een paar machines komen en nu een platform draaien met load balancers, Master-slave oplossingen, cachers, webservers, etc. Heeft onze provider mooi voor ons ingericht.

[Douweegbertje]

Tja, zoiets zou ik ook nog wel willen, maar ik denk dat er voor ons nog veel winst te behalen valt met caching en gewoon database optimalisaties en wat meer normalisaties.
Voor nu is dat voornamelijk de bottleneck en niet zo zeer de server zelf. Nu kun je dat heus wel oplossing met meer hardware, maar dat is dan vrij zinloos eigenlijk.

Waar ik ook nog binnenkort voor ga opten is om eens iemand in te huren die gewoon heel de meuk goed gaat inregelen voor versiebeheer van zowel code als db en het deployen daarvan. De reden puur voor extern is omdat ik wel meer dingen te doen heb

[orf]

Wij doen helemaal geen onderhoud of management van ons hostingplatform. Dat is niet onze core business en besteden we dus helemaal uit. Zij doen waar zij goed in zijn, wij doen waar wij goed in zijn. Dat kost best wat, maar dat is het me waard.

Edit: Wij zijn ook bezig om meer te cachen. Geen datasets, maar al eerder met Varnish. Dat gebruiken we nu alleen nog voor statische files, maar de bedoeling is om met ESI delen van pagina's te cachen. Uiteindelijk zorgt dat ook voor minder belasting van webservers en database. En het is een stuk sneller.

[ Voor 42% gewijzigd door orf op 11-07-2015 23:01 ]

[Firesphere]

orf schreef op zaterdag 11 juli 2015 @ 22:58:
Wij doen helemaal geen onderhoud of management van ons hostingplatform. Dat is niet onze core business en besteden we dus helemaal uit. Zij doen waar zij goed in zijn, wij doen waar wij goed in zijn. Dat kost best wat, maar dat is het me waard.

Niet helemaal ontopic, en kun je beter beantwoorden per DM, maar ik ben wel benieuwd wie "zij" zijn

[orf]

Ik kan een makkelijke hint geven: Rechtsboven op deze pagina staat hun logo.

[Firesphere]

orf schreef op zaterdag 11 juli 2015 @ 23:02:
Ik kan een makkelijke hint geven: Rechtsboven op deze pagina staat hun logo.

Dat had je niet gezegd!

* Firesphere zit bij een andere partij

[F.West98]

DB renamen. Altijd leuk
Ik had mijn hele DB in een mix van lowerCamelCasing, underscore_namen en NL-EN mix. Nu is alles gewoon Engels UpperCamelCasing volgens C#/.NET guidelines (code first met EF)

[Avalaxy]

Niet eens een rant over hoe kut EF is?

[ZaZ]

yay camping wifi gehackt! gratis internet. blijf hollander eh.

[Douweegbertje]

orf schreef op zaterdag 11 juli 2015 @ 22:58:
Wij doen helemaal geen onderhoud of management van ons hostingplatform. Dat is niet onze core business en besteden we dus helemaal uit. Zij doen waar zij goed in zijn, wij doen waar wij goed in zijn. Dat kost best wat, maar dat is het me waard.

Edit: Wij zijn ook bezig om meer te cachen. Geen datasets, maar al eerder met Varnish. Dat gebruiken we nu alleen nog voor statische files, maar de bedoeling is om met ESI delen van pagina's te cachen. Uiteindelijk zorgt dat ook voor minder belasting van webservers en database. En het is een stuk sneller.

Wij besteden het ook uit, maar wij bepalen soort van de specs.
Uiteraard kan ik ook vragen om een complete oplossing voor iets specifieks, maar 9 van de 10x is het meer van gooi er nog even wat geheugen/opslag w/e bij.

[F.West98]

Avalaxy schreef op zaterdag 11 juli 2015 @ 23:28:
Niet eens een rant over hoe kut EF is?

Geen zin in
Ik weet niet of het ligt aan dat ik een case insensitive collation gebruik, maar puur casing-veranderingen pikt EF niet op, behalve op indexes (en dan dropt en recreate hij de index). Dus uiteindelijk veel handwerk nog, ook in de migrations.

[Lethalis]

F.West98 schreef op zaterdag 11 juli 2015 @ 23:13:
DB renamen. Altijd leuk
Ik had mijn hele DB in een mix van lowerCamelCasing, underscore_namen en NL-EN mix. Nu is alles gewoon Engels UpperCamelCasing volgens C#/.NET guidelines (code first met EF)

Eigenlijk wil je helemaal geen mixed case in een database. Je zou maar moeten migreren naar een ander platform zoals Postgres of Oracle

Ik vind SQL server wel het fijnste werken, maar de licentiekosten lopen erg op wanneer je geen Express meer kunt gebruiken.

Genoeg .Net developers die nHibernate + Postgres gebruiken om die reden.

[ Voor 12% gewijzigd door Lethalis op 12-07-2015 07:42 ]

[Tjolk]

ZaZ schreef op zaterdag 11 juli 2015 @ 23:54:
yay camping wifi gehackt! gratis internet. blijf hollander eh.

Welkom01 ?

[Firesphere]

SQL:

UPDATE `table` SET `URL` = REPLACE('URL', 'Prefix', '');

Tijd om een backup terug te zetten.

[Mercatres]

Avalaxy schreef op zaterdag 11 juli 2015 @ 23:28:
Niet eens een rant over hoe kut EF is?

Ieder om de beurt he

[GateKeaper]

ObiTewodros schreef op vrijdag 10 juli 2015 @ 15:52:
Oh mijn god github werkt niet goed.

Blijft ook irritant dat hun code-search zo beperkt werkt.

Ben je opzoek naar waar een bepaalde functie wordt aangeroepen, neemt hij een punt niet mee in zijn query. Zoeken naar "App.db.find" resulteert dan dus in een query als "App db find". Ook wordt code alleen in de main branch (master) gezocht, en laten de resultaten niet alle matches zien, maar laat hij alle files zien waarin hij een match gevonden heeft, met de eerste beste match gehighlight en de rest niet. Moet je zelf maar verder kijken of het bestand toevallig de code bevat die jij zocht.

Juist van GitHub, zou je toch een fatsoenlijke code-search verwachten.

quote: https://help.github.com/a...derations-for-code-search

Considerations for code search

• At most, search results can show two fragments from the same file, but there may be more results within the file.
• You can't use the following wildcard characters as part of your search query: . , : ; / \ ` ' " = * ! ? # $ & + ^ | ~ < > ( ) { } [ ]. The search will simply ignore these symbols.

Die laatste voorwaarde, alles wat je dus gebruikt bij het onderscheiden van een normale search of een code-search, wordt er dus uitgefilterd. GitHub zou toch moeten weten dat dat geen 'wildcard characters' zijn, maar dat je dan code zoekt.

[Firesphere]

Morgen Atlassian maar eens bellen, die zijn natuurlijk niet open in't weekend.

Waarom zijn zoveel bedrijven die ik alleen maar buiten "office hours" kan bellen, open tijdens office hours?

[dcm360]

orf schreef op zaterdag 11 juli 2015 @ 23:02:
Ik kan een makkelijke hint geven: Rechtsboven op deze pagina staat hun logo.

Jullie hebben hosting geregeld bij Twitter?

Maar zonder dollen, ik ben nu (nouja, afgelopen en komende week) bezig met een klant verhuizen naar een managed virtual server bij hun. Misschien een beetje overkill, maar het zou mij minder tijd moeten gaan kosten dan de huidige budget-vps

[F.West98]

Lethalis schreef op zondag 12 juli 2015 @ 07:38:
[...]

Eigenlijk wil je helemaal geen mixed case in een database. Je zou maar moeten migreren naar een ander platform zoals Postgres of Oracle

Ik vind SQL server wel het fijnste werken, maar de licentiekosten lopen erg op wanneer je geen Express meer kunt gebruiken.

Genoeg .Net developers die nHibernate + Postgres gebruiken om die reden.

De licentie zit gratis bij mijn gratis VPS, dus daar heb ik geen last van

[SPee]

GateKeaper schreef op zondag 12 juli 2015 @ 14:42:
[...]
Die laatste voorwaarde, alles wat je dus gebruikt bij het onderscheiden van een normale search of een code-search, wordt er dus uitgefilterd. GitHub zou toch moeten weten dat dat geen 'wildcard characters' zijn, maar dat je dan code zoekt.

Je kunt dat stuk code ook tussen quotjes zetten, dan is het geen wildcard pattern?

[GateKeaper]

SPee schreef op zondag 12 juli 2015 @ 16:54:
[...]

Je kunt dat stuk code ook tussen quotjes zetten, dan is het geen wildcard pattern?

Dat doet nog niet wat ik wil. Het enige dat hij dan doet is dat alle woorden in het bestand moeten voorkomen (en volgens mij ook op volgorde). De "leestekens" worden dan nog steeds genegeerd.

Het is wel zo dat als je dus zoekt op iets als "process.argv.slice", dat een regel met die exacte code waarschijnlijk wel een van de eerste resultaten is, omdat die woorden alle 3 op volgorde worden gematched, maar het is niet dat hij die exacte query zoekt. Een query als "process.argv.slice(2)" negeert de (2) volledig, waardoor ook alle regels met "process.argv.slice(3)" een match zijn, immers zoekt hij enkel naar "process argv slice".


Ik bedoel..

[Firesphere]

What are you waiting for

https://lhartikk.github.io/ArnoldC/

[Douweegbertje]

mogguh dan maar?

[Alex)]

Firesphere schreef op maandag 13 juli 2015 @ 00:46:
What are you waiting for

https://lhartikk.github.io/ArnoldC/

Je weet dat er nu vanzelf één of andere stagiair is die een nieuwe website (voor bijvoorbeeld de Belastingdienst) bouwt in ArnoldC, he?

[ Voor 6% gewijzigd door Alex) op 13-07-2015 09:26 ]

[Rutix]

Alex) schreef op maandag 13 juli 2015 @ 09:22:
[...]

Je weet dat er nu vanzelf één of andere stagiair is die een nieuwe website (voor bijvoorbeeld de Belastingdienst) bouwt in ArnoldC, he?

dat is altijd nog beter dan https://github.com/letsgetrandy/brototype

[Douweegbertje]

Niets mis met brototype hoor :x

[WernerL]

Brototype is inderdaad geniaal.

[RayNbow]

Waarom niet een fatsoenlijke taal met de maybe monad?

[WernerL]

RayNbow schreef op maandag 13 juli 2015 @ 09:50:
Waarom niet een fatsoenlijke taal met de maybe monad?

Je bedoeld Scala?
En ScalaJS als alternatief op JS.

Die heeft gewoon een Maybe. (Nouja, het heet in Scala een Option, maar het principe is hetzelfde).

[Korben]

RayNbow schreef op maandag 13 juli 2015 @ 09:50:
Waarom niet een fatsoenlijke taal met de maybe monad?

Zoals C# 6? Voor zover ik het snel heb gelezen is maybe hetzelfde als de Elvis operator in C# 6.

[WernerL]

De Elvis operator lijkt vooral syntatic sugar te zijn voor dit soort constructies:

code:

var x = bla == null ? false : true;

Een Maybe is iets meer dan dat. In plaats van een Int returnt een functie Maybe[Int], en op het resultaat kun je vervolgens gewoon higher order functies loslaten zonder dat je hoeft te controlleren of er echt een Int inzit.

[Ryur]

WernerL schreef op maandag 13 juli 2015 @ 10:01:
Een Maybe is iets meer dan dat. In plaats van een Int returnt een functie Maybe[Int], en op het resultaat kun je vervolgens gewoon higher order functies loslaten zonder dat je hoeft te controlleren of er echt een Int inzit.

Komt "straks" vergelijkbaar in C# 6.0

code:

var postcode = this.Person?.address?.postcode;

Als Person null is, dan wordt postcode ook null. Als Address null is (maar Persoon bestaat wel), dan wordt null teruggegeven.
Scheelt een hoop "IF" code

(Note: let niet op de mix van NL & EN)

[ Voor 9% gewijzigd door Ryur op 13-07-2015 10:04 ]

[Alex)]

Ryur schreef op maandag 13 juli 2015 @ 10:03:
[...]

(Note: let niet op de mix van NL & EN)

Postcode is gewoon Engels hoor

[basisdeman]

Alex) schreef op maandag 13 juli 2015 @ 10:04:
[...]

Postcode is gewoon Engels hoor

"Zip Code"?

[ Voor 8% gewijzigd door basisdeman op 13-07-2015 10:08 ]

[Rutix]

basisdeman schreef op maandag 13 juli 2015 @ 10:07:
[...]


Maar "address" niet

Wikipedia: Address (geography)
Wiki disagrees.

[basisdeman]

Rutix schreef op maandag 13 juli 2015 @ 10:08:
[...]

Wikipedia: Address (geography)
Wiki disagrees.

Was op dat moment net mijn comment aan het veranderen

[Rutix]

basisdeman schreef op maandag 13 juli 2015 @ 10:09:
[...]


Was op dat moment net mijn comment aan het veranderen

Dan nog steeds:
Wiki disagrees:

A postal code (known in various countries as a post code or postcode)

Wikipedia: Postal code

[Alex)]

basisdeman schreef op maandag 13 juli 2015 @ 10:07:
[...]


"Zip Code"?

Dat is Amerikaans, niet Engels.

[Avalaxy]

Korben schreef op maandag 13 juli 2015 @ 09:56:
[...]

Zoals C# 6? Voor zover ik het snel heb gelezen is maybe hetzelfde als de Elvis operator in C# 6.

Dat ding heet een monadic null check, niet een "elvis operator".

[alienfruit]

Klanten die willen dat de SVN bij hun wordt gehost. Prima, maar nu kan ik dus niet meer aan hun project werken zonder hun eigen notebook. En ik ben momenteel op pad en heb niet hun notebook meegesleept en nu zijn ze geïrriteerd dat ik het vandaag niet kan oplossen. Sigh.

Mompelt iets van een gewaarschuwd mens telt voor twee

[ Voor 9% gewijzigd door alienfruit op 13-07-2015 10:52 ]

[Korben]

Avalaxy schreef op maandag 13 juli 2015 @ 10:39:
[...]


Dat ding heet een monadic null check, niet een "elvis operator".

Zo'n ding heet een null-conditional operator, niet een monadic null check. Mads Torgersen noemt het een Elvis operator.

[Douweegbertje]

Jullie zijn allemaal super op feesten en partijen.

[RayNbow]

WernerL schreef op maandag 13 juli 2015 @ 09:54:
[...]


Je bedoeld Scala?
En ScalaJS als alternatief op JS.

Die heeft gewoon een Maybe. (Nouja, het heet in Scala een Option, maar het principe is hetzelfde).

Korben schreef op maandag 13 juli 2015 @ 09:56:
[...]

Zoals C# 6? Voor zover ik het snel heb gelezen is maybe hetzelfde als de Elvis operator in C# 6.

...of, nog beter, een taal waarin je je eigen operators kunt definieren.

[WernerL]

RayNbow schreef op maandag 13 juli 2015 @ 11:16:
[...]


[...]


...of, nog beter, een taal waarin je je eigen operators kunt definieren.

Dat kan Scala ook

Scala:

implicit class ListOps[A](list:List[A]) {

def &^%(that:List[A]) { ... do some cool stuff }

}

List(1,2,3) &^% List(4,5,6)

Ok code klopt niet 100%, en eigenlijk is het gewoon een functie. Maar je kunt hem zo gebruiken als infix operator.

[Firesphere]

Alex) schreef op maandag 13 juli 2015 @ 09:22:
[...]

Je weet dat er nu vanzelf één of andere stagiair is die een nieuwe website (voor bijvoorbeeld de Belastingdienst) bouwt in ArnoldC, he?

Dat is toch ook de bedoeling?