De Devschuur Coffee Corner - Iteratie ⓬

[RayNbow]

RobIII schreef op donderdag 4 oktober 2018 @ 10:28:
[...]

Dat doet 'tzelfde, niet

Correct.

[Lethalis]

Wat vinden jullie van railway oriented programming?

https://fsharpforfunandprofit.com/rop/

Het is met wat extension methods in C# redelijk na te bootsen:

C#:

using LanguageExt; // Functional library voor C#

ValidateRequest(request)
  .Bind(UpdateDb)
  .Bind(SendEmail)
  .Match(LogSuccess, LogError);

Waarbij elke functie een Either<L, R> teruggeeft. Met implicit cast operators kun je dan vrij eenvoudig een type van L of R teruggeven. Dus als een functiesignatuur Request -> Either<Error, Request> is, kun je zowel een Error als een Request instantie returnen vanuit deze functie. Higher order functions zoals Bind voeren dan alleen de meegegeven functie uit als je geen Error hebt. Bij een error geven ze deze alleen door, zodat je die op het eind met Match kunt afhandelen.

Dus je hebt een "happy path" en een secundair pad voor als er iets fout gegaan is.

Anyways, ik ben dus benieuwd of hier meer mensen ervaring mee hebben en het ook toepassen

[bwerg]

Lethalis schreef op donderdag 4 oktober 2018 @ 14:40:
Anyways, ik ben dus benieuwd of hier meer mensen ervaring mee hebben en het ook toepassen

Specifiek voor C#, of in het algemeen? In FP komt dit paradigma vrij veel voor. In feite is het gewoon exception-handling, behalve dat de semantiek van exception-handling in veel talen hard-coded in de taal is ingebakken (try-catch, waarbij de catch het secundaire pad is), terwijl de semantiek op deze manier vrij te programmeren is (in dit geval either-match). In functionele talen zijn "try" en "catch" op precies deze manier vaak functies in plaats van keywords, en kunnen exceptions door verschillende datatypen gerepresenteerd worden (exception, either, maybe, ...), afhankelijk van wat je nodig hebt.

Je hebt minder hard-coded semantiek, en de semantiek die er is, maak je expliciet. Dat is doorgaans wel prettig, maar als je het in den treure doorvoert heb je het soms weer liever impliciet. Mits goed gedaan wordt ik er wel blij van.

Ook een dingetje: hoe combineert dit met ingebakken exception handling? Wordt dan het secundaire pad nog afgedraaid of ga je dan naar de ingebakken catch? Meerdere manieren om exception handling te doen kan ook verwarren. Zie haskell en zijn 100 manieren van exception handling, en elke library gebruikt weer zijn eigen variant...

[Lethalis]

bwerg schreef op donderdag 4 oktober 2018 @ 15:41:
[...]
Specifiek voor C#, of in het algemeen?

Ook een dingetje: hoe combineert dit met ingebakken exception handling? Wordt dan het secundaire pad nog afgedraaid of ga je dan naar de ingebakken catch? Meerdere manieren om exception handling te doen kan ook verwarren. Zie haskell en zijn 100 manieren van exception handling, en elke library gebruikt weer zijn eigen variant...

Specifiek dit paradigma toepassen in C#

De richtlijn voor exceptions is in principe dat exceptions "exceptions" moeten zijn. Het liefste heb je helemaal geen exceptions, omdat dit eigenlijk als een "go to" statement wordt gezien die een onverwachte sprong op de call stack maakt. Exceptions zijn dan dus puur voor de situaties die je als ontwikkelaar zelf niet voorzien hebt.

Je gooit dus zelf helemaal geen exceptions meer, maar geeft specifieke errors terug die overerven van Error (ValidationError, CustomerNotFoundError, enzovoorts).

Bijvoorbeeld: Either<Error, Customer> FindCustomerById(int customerId)

Omdat een functie bij voorkeur "eerlijk" is, zou de signatuur alle mogelijke uitkomsten moeten beschrijven. In dit geval krijg je dus altijd een Customer of een Error terug. Een Exception hoort daar niet bij.

Wel kun je framework exceptions opvangen met een Try<T> functie in de LanguageExt library:

https://github.com/louthy...ures#signatures-that-talk

[Mercatres]

RayNbow schreef op woensdag 3 oktober 2018 @ 02:29:
[...]

Naast het Prinsenhof.

Haha, dan denk ik dat ik dat heul toevallig gespot heb, toen we twee weken geleden een dagje Delft hebben gedaan

Also forenzen: Twintig minuten met de auto, 30 minuten met de fiets hier in 't Belgische Hasselt. Vroeger reed ik zo goed als dagelijks met de fiets, nu is het eerder nooit - nu ik een auto heb.

[ThomasG]

Lethalis schreef op donderdag 4 oktober 2018 @ 16:04:
[...]

Specifiek dit paradigma toepassen in C#

De richtlijn voor exceptions is in principe dat exceptions "exceptions" moeten zijn. Het liefste heb je helemaal geen exceptions, omdat dit eigenlijk als een "go to" statement wordt gezien die een onverwachte sprong op de call stack maakt. Exceptions zijn dan dus puur voor de situaties die je als ontwikkelaar zelf niet voorzien hebt.

Je gooit dus zelf helemaal geen exceptions meer, maar geeft specifieke errors terug die overerven van Error (ValidationError, CustomerNotFoundError, enzovoorts).

Bijvoorbeeld: Either<Error, Customer> FindCustomerById(int customerId)

Omdat een functie bij voorkeur "eerlijk" is, zou de signatuur alle mogelijke uitkomsten moeten beschrijven. In dit geval krijg je dus altijd een Customer of een Error terug. Een Exception hoort daar niet bij.

Wel kun je framework exceptions opvangen met een Try<T> functie in de LanguageExt library:

https://github.com/louthy...ures#signatures-that-talk

Dit klinkt mij meer als een gevalletje: je gebruikt de verkeerde programmeertaal.

[Lethalis]

ThomasG schreef op donderdag 4 oktober 2018 @ 16:28:
[...]
Dit klinkt mij meer als een gevalletje: je gebruikt de verkeerde programmeertaal.

De auteur van LanguageExt krijgt die opmerking ook vaak:

https://github.com/louthy...t-you-just-use-F%23%3F%22

En ik kan mij helemaal vinden in zijn reactie. Ook ik zit in een groot .NET project en kan niet zomaar delen gaan herschrijven naar een andere taal.

[RayNbow]

Mercatres schreef op donderdag 4 oktober 2018 @ 16:14:
[...]

Haha, dan denk ik dat ik dat heul toevallig gespot heb, toen we twee weken geleden een dagje Delft hebben gedaan

In een bepaald pand bevinden zich meer dan 1 bedrijf. Het kan zijn dat je misschien een vacature van een ander bedrijf gespot hebt?

[ThomasG]

Lethalis schreef op donderdag 4 oktober 2018 @ 16:50:
[...]

De auteur van LanguageExt krijgt die opmerking ook vaak:

https://github.com/louthy...t-you-just-use-F%23%3F%22

En ik kan mij helemaal vinden in zijn reactie. Ook ik zit in een groot .NET project en kan niet zomaar delen gaan herschrijven naar een andere taal.

Het argument is dus eigelijk: ik wil taal X gebruiken, maar ik kan niet over. Dus ik ga rare truukjes uithalen in taal Y, zodat het op taal X lijkt. En dat vind ik dus totaal niet ok.

[Lethalis]

ThomasG schreef op donderdag 4 oktober 2018 @ 16:53:
[...]
Het argument is dus eigelijk: ik wil taal X gebruiken, maar ik kan niet over. Dus ik ga rare truukjes uithalen in taal Y, zodat het op taal X lijkt. En dat vind ik dus totaal niet ok.

Zulke rare trucjes zijn het niet. Je past gewoon bepaalde principes uit het functionele programmeren in een taal als C# toe.

Naar mijn mening is het een mixed bag. Gebruik wat handig is, laat staan wat minder handig is. Tegen de Option<T> kijk ik bijvoorbeeld iets voorzichtiger aan, omdat die via een omweg beperkingen van het C# type system probeert te omzeilen (je zou dit ook met code contracts kunnen oplossen).

Het toepassen van generieke higher order functions zoals Bind en Match in combinatie met een Either<T> class, doet echter weinig qua trucjes. Het zijn simpelweg generic extension methods waar je weer andere functies aan doorgeeft.

In zekere zin is het principe van HOF's toepassen al "normaal" in de .NET ontwikkeling geworden. Kijk maar naar frameworks als NancyFX (alle handlers en middleware functies) en zelfs ASP.NET Core (configuration functies).

C# wordt dan ook als een hybride taal gezien die in de toekomst nog meer functionele aspecten zal krijgen (immutable data records, non-nullable reference types, etc).

[ Voor 7% gewijzigd door Lethalis op 04-10-2018 17:06 ]

[kenneth]

Als je het zo bekijkt zijn de developers van C# continu rare trucjes aan het uithalen want een flink deel van de features in C# 7 en 8 zijn gewoon F#-features

[Mercatres]

RayNbow schreef op donderdag 4 oktober 2018 @ 16:51:
[...]

In een bepaald pand bevinden zich meer dan 1 bedrijf. Het kan zijn dat je misschien een vacature van een ander bedrijf gespot hebt?

Kan hoor, 't was iets met 'geo'

[bwerg]

ThomasG schreef op donderdag 4 oktober 2018 @ 16:53:
[...]
Het argument is dus eigelijk: ik wil taal X gebruiken, maar ik kan niet over. Dus ik ga rare truukjes uithalen in taal Y, zodat het op taal X lijkt. En dat vind ik dus totaal niet ok.

Dus als je wél een request wil valideren, een database wil updaten, een mail wil sturen en afhankelijk van of het lukt of niet op een bepaalde manier loggen, dan moet je dat per sé met verbose if-else-statements afhandelen, omdat als je die if-else-statements wegstopt in een functioneel geinspireerde library, je het paradigma van je oorspronkelijke taal niet meer ziet?

De functionele aanpak (of 'railway oriented programming' - ik had die term nog niet gehoord) abstraheert zaken weg waar je niet over wil nadenken. Of je nou wegabstraheert met een taalkeuze of met een library, ik zie het probleem niet zo, zolang je geen concrete nadelen kan opnoemen.

[ThomasG]

bwerg schreef op donderdag 4 oktober 2018 @ 17:43:
[...]


Dus als je wél een request wil valideren, een database wil updaten, een mail wil sturen en afhankelijk van of het lukt of niet op een bepaalde manier loggen, dan moet je dat per sé met verbose if-else-statements afhandelen, omdat als je die if-else-statements wegstopt in een functioneel geinspireerde library, je het paradigma van je oorspronkelijke taal niet meer ziet?

De functionele aanpak (of 'railway oriented programming' - ik had die term nog niet gehoord) abstraheert zaken weg waar je niet over wil nadenken. Of je nou wegabstraheert met een taalkeuze of met een library, ik zie het probleem niet zo, zolang je geen concrete nadelen kan opnoemen.

Nee, niks if-statements, want daar heb je juist exceptions voor! Je hebt een try statement, en daarin validateer je input, update je de database, en stuur je een email. Mislukt het updaten? Dan throwt die methode een exception, zodat het stukje van email versturen niet wordt uitgevoerd.

Ik kan wel een concreet nadeel bedenken: in real-world kom je situaties tegen die niet (goed) werken met een Either - bijvoorbeeld third-party libraries, waardoor je ze moet gaan wrappen, en je het jezelf alleen maar moeilijker maakt.

[ Voor 10% gewijzigd door ThomasG op 04-10-2018 18:15 ]

[Hydra]

ThomasG schreef op donderdag 4 oktober 2018 @ 18:12:
[...]
Nee, niks if-statements, want daar heb je juist exceptions voor! Je hebt een try statement, en daarin validateer je input, update je de database, en stuur je een email. Mislukt het updaten? Dan throwt die methode een exception, zodat het stukje van email versturen niet wordt uitgevoerd.

Dat zijn twee compleet verschillende zaken die je hier op 1 hoop gooit. Het accessen van een database zou altijd moeten werken. Als dat niet kan, is er iets stuk. Dat is een uitzondering, een exception dus. Input valideren van een gebruiker daarentegen is gewoon je normale flow. En dat een gebruiker daarin een fout maakt, is iets wat ook te verwachten is.

Nu kom je hiermee snel in een grijs gebied; als je een service hebt die aangeroepen wordt door een client die zelf input valideert, valideer je het aan de server kant omdat je de client niet vertrouwt. Maar verkeerde input is daar wel weer een uitzondering; dan loopt iemand te klooien.

Database access waarbij een record niet aanwezig is, kan zowel een foutsituatie zijn (door een programmeurfout is een record niet aangemaakt) of gewoon een normale situatie (je doet een GET op een resource die niet bestaat). Dit zijn andere situaties en hiervoor heb je dus verschillende mechanismen.

Libraries gebruiken om op een meer functionele manier die tweede manier (dus niet exceptions) is de normaalste zaak van de wereld. Ik vind het volslagen onzin om dan te stellen dat je maar een andere taal had moeten gebruiken; zo werkt de wereld niet. En dat weet je volgens mij best

[Sandor_Clegane]

Ik vind ROP wel een mooie manier om te programmeren, voordat F# de Result type had gebruikte ik altijd de Result<Success,Failure> type van Scott Wlaschin ( F# for fun and profit).

Als je een DB aanvraag doet dan plemp ik dat standaard in een try catch voor de exception en het resultaat is dan een OK of Error, Ok kan dan weer een Option bevatten. Dus dan kan de aanvraag goed gaan met Some record als resultaat, hij gaat goed met None. Of je krijgt een Error met een message of exception. Dat werkt wel mooi.

De volgende stap is dan een patternmatch op het resultaat | Ok(Some record) | Ok None etc. etc.

C# neemt veel over alleen ben ik bang dat veel van de aspecten van F# lastig zijn in C# omdat het gewoon een ander paradigma qua programmeren is. Zo heb je pattern matching, maar toch niet helemaal. En hou je de verbose syntax. Async in F# is ook net even anders.

Ik ben alleen altijd een beetje huivering voor die switch functions, dat maakt het een stuk meer diffuus.

Libraries als NancyFX komen ook een beetje over als net iets te slim, Suave heeft daar ook wel een beetje last van. Het is best lastig om te doorgronden wat er allemaal al geregeld wordt.

Ik ben ook geen fan van die Fluent syntax om eerlijk te zijn.

[ Voor 39% gewijzigd door Sandor_Clegane op 04-10-2018 18:50 ]

[Mugwump]

Ik stoorde me altijd mateloos aan het feit dat hibernate geen fatsoenlijke "get by Id if exists" had. Geen idee of die er inmiddels wel is.

[Hydra]

Mugwump schreef op donderdag 4 oktober 2018 @ 18:46:
Ik stoorde me altijd mateloos aan het feit dat hibernate geen fatsoenlijke "get by Id if exists" had. Geen idee of die er inmiddels wel is.

Spring Data JPA heeft dat wel, gebruikt (o.a.) hibernate onderwater. Hibernate is m.i. wel volkomen kut overigens.

[Lethalis]

Hydra schreef op donderdag 4 oktober 2018 @ 19:11:
[...]
Spring Data JPA heeft dat wel, gebruikt (o.a.) hibernate onderwater. Hibernate is m.i. wel volkomen kut overigens.

Wat vind je precies kut aan Hibernate?

In de .NET wereld is NHibernate namelijk een verademing als je het vergelijkt met een ORM als Entity Framework, zeker in "Database First" scenario's.

[Hydra]

Lethalis schreef op donderdag 4 oktober 2018 @ 19:18:
Wat vind je precies kut aan Hibernate?

9 van de 10 keer doet 't wel wat 't moet doen, maar die 1 van de 10 keer krijg je vaak rare queries. En vooral met complexe joins op composite keys moet je zoveel (dmv annotations e.d.) aan het framework vertellen dat je er, samen met het debuggen van rare queries, eigenlijk alleen maar meer tijd mee kwijt bent.

Daarnaast; dergelijke ORMs zijn gebaseerd op het inmiddels verouderde idee dat je een applicatie hebt met een in-memory object-boom, een enkele waarheid, die naar een zooi tabellen gemapt wordt. Vooral heden ten dage waarbij je vaak met REST API's werkt, werk je vooral met projecties op die data. Dus je bent al snel veel complexe entity modellen aan het optuigen.

Gewoon zelf de SQL queries schrijven (er is niks meer expressief dan een declarative taal IMHO) en met een simpele objectmapper deze resultsets naar objecten mappen werkt m.i. vele malen efficienter.

Last but not least; er zijn gewoon te veel slechte developers en die checken uberhaupt niet wat Hibernate e.d. uitvoeren. In een pull request zie ik tenminste in hun SQL queries dat ze rare shit uitspoken

TLDR: SQL: > hibernate

In de .NET wereld is NHibernate namelijk een verademing als je het vergelijkt met een ORM als Entity Framework, zeker in "Database First" scenario's.

Nooit met EF gewerkt (ik doe niet aan windows/microsoft als 't even te vermijden is ) maar als het nog slechter is dan Hibernate; damn

[ Voor 11% gewijzigd door Hydra op 04-10-2018 19:31 ]

[Lethalis]

Hydra schreef op donderdag 4 oktober 2018 @ 19:29:
[...]
En vooral met complexe joins op composite keys moet je zoveel (dmv annotations e.d.) aan het framework vertellen dat je er, samen met het debuggen van rare queries, eigenlijk alleen maar meer tijd mee kwijt bent.

Ondanks dat ik het eens ben met jou dat een simpele object mapper en directe SQL queries vaak eenvoudiger te maken en managen is, wil ik toch 1 ding opmerken...

Als je veel composite keys hebt in een database model, kan het een idee zijn om met surrogate keys te werken.

Op mijn werk kom ik het vaak tegen dat programmeurs niet altijd doorhebben wat er gebeurt in hun relationele database. Ze maken tabellen aan met composite keys, die ook meteen de clustered index vormen, met als gevolg dat de composite key ook de volgorde van de records in het fysieke model bepaalt.

Dit leidt vrijwel altijd tot een hoge fragmentatie, wat weer tot performance problemen leidt. Daarom is het vaak verstandig om tenminste de clustered index op een chronologische surrogate key te baseren. De non clustered indexes kun je immers relatief goedkoop rebuilden in een scheduled maintenance task.

Afgezien daarvan kunnen surrogate keys ook voor andere zaken handig zijn (als je een onderhoudfunctie schrijft, is het veel handiger om simpelweg een unieke id te gebruiken ipv meerdere velden).

Elke keer als ik een legacy database tegenkom met een hoop composite keys krijg ik jeuk Als ik dan vervolgens de bijbehorende code zie met WHERE clausules over 4 velden dan krijg ik rillingen.

En als ik dan de bug heb gevonden waar ik naar moest zoeken en het komt omdat iemand in 1 van die SQL statements 1 veldje is vergeten in een WHERE clausule dan begin ik te vloeken

Hydra schreef op donderdag 4 oktober 2018 @ 19:29:
[...]
Nooit met EF gewerkt (ik doe niet aan windows/microsoft als 't even te vermijden is ) maar als het nog slechter is dan Hibernate; damn

Het is zo erg dat ze opnieuw begonnen zijn voor EF Core

[ Voor 8% gewijzigd door Lethalis op 04-10-2018 22:10 ]

[Sandor_Clegane]

Ze hadden beter die energie kunnen steken in het helpen van de nHibernate jongens. Denk een gevalletje van NIH syndroom.

[Lethalis]

Sandor_Clegane schreef op donderdag 4 oktober 2018 @ 18:41:
C# neemt veel over alleen ben ik bang dat veel van de aspecten van F# lastig zijn in C# omdat het gewoon een ander paradigma qua programmeren is. Zo heb je pattern matching, maar toch niet helemaal. En hou je de verbose syntax. Async in F# is ook net even anders.

Ik ben alleen altijd een beetje huivering voor die switch functions, dat maakt het een stuk meer diffuus.

Libraries als NancyFX komen ook een beetje over als net iets te slim, Suave heeft daar ook wel een beetje last van. Het is best lastig om te doorgronden wat er allemaal al geregeld wordt.

Ik ben ook geen fan van die Fluent syntax om eerlijk te zijn.

Mja, ik vind de Fluent syntax clean en toegankelijk in C#. In F# zou je dit inderdaad niet zo snel doen, omdat de taal ingebouwde operators heeft (|> etc).

De keren dat ik met F# speel, moet ik trouwens erg wennen aan de type inference van de taal Deze is zo flexibel dat ik er eng van word. Een type bepalen op basis van zijn gebruik vind ik scary en dan ga ik de functie specifieker maken door type annotations toe te voegen:

code:

open System
open System.Data.SqlClient

type ConnectionStringParams = { DataSource: string; Catalog: string; UserName: string; Password: string; }

let getConnectionString connectionStringParams =
    let b = new SqlConnectionStringBuilder()
    b.DataSource <- connectionStringParams.DataSource
    b.InitialCatalog <- connectionStringParams.Catalog
    b.UserID <- connectionStringParams.UserName
    b.Password <- connectionStringParams.Password
    b.ToString()

[<EntryPoint>]
let main argv =

    let connectionStringParams = { DataSource = "server"; Catalog = "development"; UserName = "pietje"; Password = "1234" }
    let connectionString = getConnectionString connectionStringParams
    printfn "Connecting to: %s" connectionString

    use connection = new SqlConnection(connectionString)
    try connection.Open()
    with ex -> printfn "%s" ex.Message

    0 // return an integer exit code

Het voelt best gek dat de getConnectionString functie automatisch gematcht wordt aan een ConnectionStringParams record type. Dus dan pas ik hem daarna aan:

code:

let getConnectionString (connectionStringParams: ConnectionStringParams) :string =
    let b = new SqlConnectionStringBuilder()
    b.DataSource <- connectionStringParams.DataSource
    b.InitialCatalog <- connectionStringParams.Catalog
    b.UserID <- connectionStringParams.UserName
    b.Password <- connectionStringParams.Password
    b.ToString()

Maar goed, ik ben F# nog steeds aan het leren. In de praktijk blijft het afwachten of ik het kan gebruiken in greenfield projecten, en in bestaande projecten past het gebruiken van een oplossing als LanguageExt in C# beter.

[Alex)]

Één van de nadelen aan Entity Framework vind ik dat het van Microsoft zelf is, en dat het in vrijwel alle voorbeelden en templates gebruikt wordt. Er is amper aandacht voor alternatieven, terwijl er ook niet wordt ingegaan op wat er 'under the hood' gebeurt.

EF wordt dermate veel door Microsoft gepushed dat het als best practice wordt gezien, er is inmiddels een hele schare developers die niet eens beter weet dan dat je EF gebruikt voor data access. Of die van mening zijn dat "alles wat niet EF is, ouderwets is" en dat je "maar eens met je tijd moet meegaan" als je nog zelf SQL schrijft, of kiest voor iets wat geen EF is.

Sla er maar eens een willekeurige "getting started with ASP.NET MVC"-guide op na: er wordt meteen EF code first gebruikt, er wordt terloops genoemd dat de data in 'een SQL-database belandt' (wat dat is moet je zelf maar uitzoeken) en er is ook geen aandacht voor alternatieven (zoals SQL statements, of NHibernate/Dapper/...).

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[RayNbow]

Mercatres schreef op donderdag 4 oktober 2018 @ 17:11:
[...]

Kan hoor, 't was iets met 'geo'

Er zitten twee bedrijven daar met "Geo" in de naam (eentje waarmee de naam begint, een ander die er mee eindigt).

[Sandor_Clegane]

Lethalis schreef op donderdag 4 oktober 2018 @ 23:10:
[...]

Mja, ik vind de Fluent syntax clean en toegankelijk in C#. In F# zou je dit inderdaad niet zo snel doen, omdat de taal ingebouwde operators heeft (|> etc).

De keren dat ik met F# speel, moet ik trouwens erg wennen aan de type inference van de taal Deze is zo flexibel dat ik er eng van word. Een type bepalen op basis van zijn gebruik vind ik scary en dan ga ik de functie specifieker maken door type annotations toe te voegen:

code:

open System
open System.Data.SqlClient

type ConnectionStringParams = { DataSource: string; Catalog: string; UserName: string; Password: string; }

let getConnectionString connectionStringParams =
    let b = new SqlConnectionStringBuilder()
    b.DataSource <- connectionStringParams.DataSource
    b.InitialCatalog <- connectionStringParams.Catalog
    b.UserID <- connectionStringParams.UserName
    b.Password <- connectionStringParams.Password
    b.ToString()

[<EntryPoint>]
let main argv =

    let connectionStringParams = { DataSource = "server"; Catalog = "development"; UserName = "pietje"; Password = "1234" }
    let connectionString = getConnectionString connectionStringParams
    printfn "Connecting to: %s" connectionString

    use connection = new SqlConnection(connectionString)
    try connection.Open()
    with ex -> printfn "%s" ex.Message

    0 // return an integer exit code

Het voelt best gek dat de getConnectionString functie automatisch gematcht wordt aan een ConnectionStringParams record type. Dus dan pas ik hem daarna aan:

code:

let getConnectionString (connectionStringParams: ConnectionStringParams) :string =
    let b = new SqlConnectionStringBuilder()
    b.DataSource <- connectionStringParams.DataSource
    b.InitialCatalog <- connectionStringParams.Catalog
    b.UserID <- connectionStringParams.UserName
    b.Password <- connectionStringParams.Password
    b.ToString()

Maar goed, ik ben F# nog steeds aan het leren. In de praktijk blijft het afwachten of ik het kan gebruiken in greenfield projecten, en in bestaande projecten past het gebruiken van een oplossing als LanguageExt in C# beter.

Het is niet onfeilbaar, maar return type specificatie gebruik ik bijna nooit. Implicit operators zijn ook een draak omdat de compiler dan niet weet wat er gedaan moet worden. ( hallo redis client! ). Maar daar zijn wel custom operators voor te maken.

[ Voor 3% gewijzigd door Sandor_Clegane op 05-10-2018 06:40 ]

[Lethalis]

Alex) schreef op vrijdag 5 oktober 2018 @ 00:53:
EF wordt dermate veel door Microsoft gepushed dat het als best practice wordt gezien, er is inmiddels een hele schare developers die niet eens beter weet dan dat je EF gebruikt voor data access. Of die van mening zijn dat "alles wat niet EF is, ouderwets is" en dat je "maar eens met je tijd moet meegaan" als je nog zelf SQL schrijft, of kiest voor iets wat geen EF is.

Mja, dat zijn dezelfde mensen die je een stored procedure kunt laten zien van 25 regels die hetzelfde doet als hun programma van 100+ regels, maar dan zonder kostbare round trips.

Ik heb op mijn vorige baan met precies die actie iemand kwaad laten weglopen. Hij kon het niet handelen. Want ja, hij was 45 ofzo en wist alles beter.

[Hydra]

Alex) schreef op vrijdag 5 oktober 2018 @ 00:53:
EF wordt dermate veel door Microsoft gepushed dat het als best practice wordt gezien

Dit raakt m.i. ook een van de wat mij betreft grootste issues van het .Net ecosysteem; de community. Als voorbeeld; ik heb nog steeds van vroeger een oud studiegenoot die self proclaimed microsoft fan is en Linux maar te veel gedoe vindt met lastige command line commando's (heeft 'ie onlangs op LinkedIn gepost, dapper ). En zulke types zie je wel meer. Hij is ook eigenlijk altijd van mening dat als het van Microsoft komt goed is, en de rest kut is.

Als we die mentaliteit hadden gehad in Java land, hadden we nog steeds met z'n allen Java EE zitten doen op grote application servers. Juist die concurrentie tussen op source libraries en de 'officiele' libraries zorgen voor innovatie.

Ik weet wel dat veel C# devs niet zo zijn, maar dat gekwijl naar Microsoft toe zie je daar wel enorm veel meer. Als je de gemiddelde Java dev naar z'n mening over Oracle vraagt is die waarschijnlijk niet echt positief

[Matis]

Lethalis schreef op vrijdag 5 oktober 2018 @ 07:41:
Ik heb op mijn vorige baan met precies die actie iemand kwaad laten weglopen. Hij kon het niet handelen. Want ja, hij was 45 ofzo en wist alles beter.

Herkenbaar. Bij mijn vorige werkgever hadden we ook een collega van een "respectabele" leeftijd (ikzelf ben 29 ) die, als hij het met een beslissing niet eens was, minimaal drie keer zijn complete functietitel moest noemen om zijn eigen argumenten kracht bij te zetten.

[Sandor_Clegane]

Hydra schreef op vrijdag 5 oktober 2018 @ 07:50:
[...]


Dit raakt m.i. ook een van de wat mij betreft grootste issues van het .Net ecosysteem; de community. Als voorbeeld; ik heb nog steeds van vroeger een oud studiegenoot die self proclaimed microsoft fan is en Linux maar te veel gedoe vindt met lastige command line commando's (heeft 'ie onlangs op LinkedIn gepost, dapper ). En zulke types zie je wel meer. Hij is ook eigenlijk altijd van mening dat als het van Microsoft komt goed is, en de rest kut is.

Als we die mentaliteit hadden gehad in Java land, hadden we nog steeds met z'n allen Java EE zitten doen op grote application servers. Juist die concurrentie tussen op source libraries en de 'officiele' libraries zorgen voor innovatie.

Ik weet wel dat veel C# devs niet zo zijn, maar dat gekwijl naar Microsoft toe zie je daar wel enorm veel meer. Als je de gemiddelde Java dev naar z'n mening over Oracle vraagt is die waarschijnlijk niet echt positief

Ligt eraan in welk deel je zit. In F# land zijn ze lekker tegendraads. Type providers, Fake, Paket, Fable etc. etc.

[Hydra]

Matis schreef op vrijdag 5 oktober 2018 @ 07:51:
Herkenbaar. Bij mijn vorige werkgever hadden we ook een collega van een "respectabele" leeftijd (ikzelf ben 29 ) die, als hij het met een beslissing niet eens was, minimaal drie keer zijn complete functietitel moest noemen om zijn eigen argumenten kracht bij te zetten.

In m'n vorige project hebben we op een gegeven moment een ZZPer in het team gekregen die iets ouder was dan ik (hij's in de 40). Die kreeg het voor elkaar om binnen een paar weken 3 senior developers (een van begin dertig, een van eind dertig (ik) en een van eind 40) compleet tegen zich in het harnas te jagen. Die had een gezonde combinatie van denken dat je het beter weet omdat je ouder bent, geen social skills, geen fluit snappen van complexe software en koste wat 't kost voet bij stuk houden.

Als in; IntellIJ meldt dat als je een collection.contains doet je waarschijnlijk een Set wil gebruiken i.p.v. een List blijven argumenteren waarom je keuze voor List toch correct was (was het niet). Of in je aller eerste meeting waar je uitgenodigd bent om vooral te luisteren en te leren je teamgenoot (mij) op inhoud aanvallen door te melden dat het allemaal verkeerd was en we toch vooral ElasticSearch moesten gebruiken (want daar had hij in z'n vorige project mee gewerkt en dat was helemaal geweldig).

Gelukkig was het management wel gevoelig voor 3 senior devs die hem eruit wouden hebben, maar al met al toch bijna 3 maanden met 'em samen moeten werken.

</rant>

[Lethalis]

Sandor_Clegane schreef op vrijdag 5 oktober 2018 @ 07:52:
[...]


Ligt eraan in welk deel je zit. In F# land zijn ze lekker tegendraads. Type providers, Fake, Paket, Fable etc. etc.

Helaas is de F# community erg klein tov de rest.

Er zijn hele hordes .NET ontwikkelaars die nog zweren bij Visual Basic omdat ze de C# syntax te ingewikkeld vinden of omdat de designers niet alles voor ze uit handen nemen.

In mijn 15 jaar als .NET ontwikkelaar bij meerdere bedrijven vecht ik eigenlijk continu een uphill battle om nieuwe dingen te introduceren bij collega's en leidinggevenden.

Het is dat ik mijn baan voor de rest echt prima vind qua voorwaarden en reistijd, maar ik heb (te) vaak een switch overwogen naar de Java community.

Thuis draait daarnaast alles op Linux bij mij en elke keer dat er weer gezeur met een Windows installatie is op mijn werk, heb ik niet eens meer zin om ernaar te kijken.

Best lastig soms... Maar goed.

Gelukkig heeft Windows 10 zoveel irritatie veroorzaakt op mijn werk dat het niet meer heilig is. Bedankt Microsoft

Zodra ik meer kansen zie om .Net Core te gebruiken op mijn werk, gaan er wat migraties naar Linux VM's plaatsvinden

Het mooie daarvan is dat ik het als kostenbesparende maatregel kan aandragen. Zowel in licenties als in benodigde hardware resources.

[DeluxZ]

Lethalis schreef op vrijdag 5 oktober 2018 @ 08:43:
[...]

Helaas is de F# community erg klein tov de rest.

Er zijn hele hordes .NET ontwikkelaars die nog zweren bij Visual Basic omdat ze de C# syntax te ingewikkeld vinden of omdat de designers niet alles voor ze uit handen nemen.

In mijn 15 jaar als .NET ontwikkelaar bij meerdere bedrijven vecht ik eigenlijk continu een uphill battle om nieuwe dingen te introduceren bij collega's en leidinggevenden.

Het is dat ik mijn baan voor de rest echt prima vind qua voorwaarden en reistijd, maar ik heb (te) vaak een switch overwogen naar de Java community.

Thuis draait daarnaast alles op Linux bij mij en elke keer dat er weer gezeur met een Windows installatie is op mijn werk, heb ik niet eens meer zin om ernaar te kijken.

Best lastig soms... Maar goed.

Gelukkig heeft Windows 10 zoveel irritatie veroorzaakt op mijn werk dat het niet meer heilig is. Bedankt Microsoft

Zodra ik meer kansen zie om .Net Core te gebruiken op mijn werk, gaan er wat migraties naar Linux VM's plaatsvinden

Het mooie daarvan is dat ik het als kostenbesparende maatregel kan aandragen. Zowel in licenties als in benodigde hardware resources.

Waarvoor gebruik je de VM's? Is er geen PaaS waar je het op kunt hosten? Geen gezeik met licenties

Wij hebben heel ons IoT platform omgebouwd naar .NET Core het afgelopen jaar. Werkt heerlijk!

[ Voor 3% gewijzigd door DeluxZ op 05-10-2018 08:47 ]

[Lethalis]

DeluxZ schreef op vrijdag 5 oktober 2018 @ 08:46:
[...]


Waarvoor gebruik je de VM's? Is er geen PaaS waar je het op kunt hosten? Geen gezeik met licenties

Tsja, vanuit management bestaat de sterke wil om volledige controle te hebben over de hardware en software.

[DeluxZ]

Lethalis schreef op vrijdag 5 oktober 2018 @ 08:55:
[...]

Tsja, vanuit management bestaat de sterke wil om volledige controle te hebben over de hardware en software.

Dus een eventuele kostenbesparing maakt voor het management niet uit? Altijd interessante discussies over dit soort dingen

[Hydra]

Lethalis schreef op vrijdag 5 oktober 2018 @ 08:55:
Tsja, vanuit management bestaat de sterke wil om volledige controle te hebben over de hardware en software.

Hardware is duur en mensen zijn goedkoop.

Je managers zijn idioten maar dat wist je vast al.

[Sandor_Clegane]

Dat is wel heel kort door de bocht, het kan ook gewoon een standaard oplossing zijn en dan wil je geen variabelen doordat je niet precies weet wat de hardware doet.

[Mercatres]

RayNbow schreef op vrijdag 5 oktober 2018 @ 02:52:
[...]

Er zitten twee bedrijven daar met "Geo" in de naam (eentje waarmee de naam begint, een ander die er mee eindigt).

Dan weet ik het niet meer

[EddoH]

Hydra schreef op vrijdag 5 oktober 2018 @ 10:37:
[...]


Hardware is duur en mensen zijn goedkoop.

Je managers zijn idioten maar dat wist je vast al.

Doe nou toch eens een beetje verder kijken dan alleen jouw wereldje. Er zijn wellicht 100 reden te verzinnen, exotisch of niet, waarom een bedrijf controle wil hebben over de hardware waar de software op draait.

Nee, voor een simpele generieke webservice ga je niet zelf je hardware beheren, en ook voor de kosten hoef je het niet te doen, maar er kunnen zoveel meer aspecten aan een beslissing zitten.

Om gelijk mensen (helemaal als je ze niet kent) als idioot te bestempelen is gewoon respectloos en komt heel betweterig over to be honest. Ook al heb je veel kennis van zaken, je kunt niet alles weten.

[Lethalis]

DeluxZ schreef op vrijdag 5 oktober 2018 @ 10:32:
[...]
Dus een eventuele kostenbesparing maakt voor het management niet uit? Altijd interessante discussies over dit soort dingen

Hydra schreef op vrijdag 5 oktober 2018 @ 10:37:
[...]
Hardware is duur en mensen zijn goedkoop.

Je managers zijn idioten maar dat wist je vast al.

We hebben het nu over 2 verschillende dingen, namelijk:
1. Is iets duur en kan het goedkoper?
2. Hoeveel controle wil je zelf over de gekozen oplossing hebben?

Vanuit management is bij ons besloten dat punt 2 belangrijker is dan punt 1.

Voor wat context: het gaat om een bedrijfskritische portal die er absoluut niet uit mag liggen. Hij wordt letterlijk door duizenden mensen gebruikt elke dag en elke minuut dat hij offline is, kost dat onze klanten direct geld.

Onze ESXi servers staan in een colocatie direct naast de Amsterdam Internet Exchange. Als wij niet bereikbaar zijn, heeft half Nederland ook geen internet meer

[Gropah]

Lethalis schreef op vrijdag 5 oktober 2018 @ 11:22:
[...]


[...]

We hebben het nu over 2 verschillende dingen, namelijk:
1. Is iets duur en kan het goedkoper?
2. Hoeveel controle wil je zelf over de gekozen oplossing hebben?

Vanuit management is bij ons besloten dat punt 2 belangrijker is dan punt 1.

[...]

Niet om te zeggen dat uitbesteden altijd de beste optie is (sterker nog, bedrijf waar ik werk heeft het ook in eigen beheer) maar je moet ook weten wanneer je iets niet (goed) zelf (meer) kan doen. Als je op 1 locatie staan kan je locatie uitvallen en ben je ook niet meer bereikbaar (zelfs als het naast een IEX ligt). Je kunt er dan voor kiezen om zelf een 2e locatie in te richten, of om een groot deel uit te besteden aan bedrijven die hier hun werk van hebben gemaakt.

[Hydra]

EddoH schreef op vrijdag 5 oktober 2018 @ 11:18:
Om gelijk mensen (helemaal als je ze niet kent) als idioot te bestempelen is gewoon respectloos en komt heel betweterig over to be honest. Ook al heb je veel kennis van zaken, je kunt niet alles weten.

Joh, stel je niet aan. Het is gewoon een gechargeerde opmerking omdat ik nogal veel ervaring heb met bedrijven die vinden dat ze het in eigen beheer moeten doen en het eigenlijk gewoon altijd misgaat. Ik heb hier vaak discussies met managers over juist om ze richting PaaS te bewegen en dan ga ik heus niet in zo'n meeting verkondigen dat het idioten zijn.

Op m'n huidige project hebben ze nog een AS/400. Dat je die niet ff afneemt bij Google snap ik heus wel.

Lethalis schreef op vrijdag 5 oktober 2018 @ 11:22:
Vanuit management is bij ons besloten dat punt 2 belangrijker is dan punt 1.

Voor wat context: het gaat om een bedrijfskritische portal die er absoluut niet uit mag liggen. Hij wordt letterlijk door duizenden mensen gebruikt elke dag en elke minuut dat hij offline is, kost dat onze klanten direct geld.

De kans dat er bij Google of AWS een hele region uitflikkert is extreem veel kleiner dan dat je lokaal gemanagde serverparkje er een keer helemaal uitligt. Alleen het verschil in kwaliteit van mensen dat een Google weet aan te trekken versus dat de gemiddelde hostingclub hier in Nederland heeft lopen is al immens.

Dit is dus precies wat ik (nogal gechargeerd) bedoel; je managers maken, op basis van wat ik hier lees (kijk @EddoH , ik kan het heus wel!) volslagen verkeerde keuzes.

Ik zie het bij meerdere klanten van ons. Zelf maar Kubernetes clustertjes op gaan tuigen op eigen hardware omdat ze 'controle' willen. Okay. Je hebt dus eigen hardware, eigen netwerken, en dan ook nog een eigen platform infra daarboven op. Je hebt een zooi Ops mensen lopen die dit in elkaar gehobbied hebben. Als nu twee services in je kubernetes clustertje hoge latency hebben af en toe, waar in die hele stack zit het probleem dan?

Dat is letterlijk waar ik bij een vorige klant (ING, eigen datacenter gebouwd in Polen dat bestierd wordt door mensen die niet echt de top waren kwa skills, maar wel lekker goedkoop) tegenaan gelopen ben. En dat is een van de vele problemen die we daar hadden. Je wil een database? Sure; data pleuren we op een SAN. Geen probleem toch? Ugh.

Als datacenters bouwen niet je core business is; doe het gewoon niet.

[DeluxZ]

Lethalis schreef op vrijdag 5 oktober 2018 @ 11:22:
[...]


[...]

We hebben het nu over 2 verschillende dingen, namelijk:
1. Is iets duur en kan het goedkoper?
2. Hoeveel controle wil je zelf over de gekozen oplossing hebben?

Vanuit management is bij ons besloten dat punt 2 belangrijker is dan punt 1.

Voor wat context: het gaat om een bedrijfskritische portal die er absoluut niet uit mag liggen. Hij wordt letterlijk door duizenden mensen gebruikt elke dag en elke minuut dat hij offline is, kost dat onze klanten direct geld.

Onze ESXi servers staan in een colocatie direct naast de Amsterdam Internet Exchange. Als wij niet bereikbaar zijn, heeft half Nederland ook geen internet meer

Ok, dan kan ik het begrijpen Zo lang er goede redenen zijn om het zelf te doen is het toch prima

[dev10]

Matis schreef op vrijdag 5 oktober 2018 @ 07:51:
[...]

Herkenbaar. Bij mijn vorige werkgever hadden we ook een collega van een "respectabele" leeftijd (ikzelf ben 29 ) die, als hij het met een beslissing niet eens was, minimaal drie keer zijn complete functietitel moest noemen om zijn eigen argumenten kracht bij te zetten.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[Giesber]

Hydra schreef op vrijdag 5 oktober 2018 @ 11:34:
Dit is dus precies wat ik (nogal gechargeerd) bedoel; je managers maken, op basis van wat ik hier lees (kijk @EddoH , ik kan het heus wel!) volslagen verkeerde keuzes.

Als je op basis van wat je hier leest die managers idioten noemt, ben je volgens mij inderdaad betweterig en respectoos ja. Je neigt zelf al naar de conclusie dat je dat eigenlijk helemaal niet kan concluderen met de beterkte informatie die je hebt.

Ik heb er geen problemen mee dat je wat chargeert in een topic als de Devschuur (moest dat wel zijn, had ik waarschijnlijk al RSI gehad van op de rapporteer knop te klikken ), maar als je dan vervolgens iemand die daarop reageert een aansteller noemt komt dat wel nogal kinderachtig over naar mij.

Maar ja, nu ben ik mij aan het aanstellen .

[Matis]

dev10 schreef op vrijdag 5 oktober 2018 @ 12:11:

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Ja, oke dat is natuurlijk een ander verhaal. Dan scherm je niet met je eigen functie, maar attendeer je de tegenpartij dat jij het aanspreekpunt bent waar ze naar refereren. M.i. een hele andere situatie.

[EddoH]

Hydra schreef op vrijdag 5 oktober 2018 @ 11:34:
[...]
Joh, stel je niet aan.

....

je managers maken, op basis van wat ik hier lees (kijk @EddoH , ik kan het heus wel!) volslagen verkeerde keuzes.

Serieus? Je laat je zelf zo wel heel erg kennen hoor..

[Hydra]

EddoH schreef op vrijdag 5 oktober 2018 @ 12:33:
Serieus? Je laat je zelf zo wel heel erg kennen hoor..

Ik neem tenminste nog de moeite inhoudelijk te reageren en het uit te leggen Maarja, dat knip je voor 't gemak maar ff weg

dev10 schreef op vrijdag 5 oktober 2018 @ 12:11:
Ik heb een probleem met het systeem van een leverancier waar ik iedere keer dat ik daar op probeer in te loggen een melding krijg mijn wachtwoord niet klopt. Als ik vervolgens het wachtwoord aanpas door middel van de 'Wachtwoord vergeten' functionaliteit en voor de gein probeer het wachtwoord in te voeren dat in m'n wachtwoordenmanager staat, krijg ik de melding dat het nieuwe wachtwoord niet gelijk mag zijn aan het oude wachtwoord.

Niet direct relevant maar in de trant van de vorige discussie: In mijn ervaring is er vaak, om een of andere reden, een enorme overlap in bedrijven die dit soort IT allemaal zelf willen doen en waar je dit soort geneuzel hebt. Project waar ik nu op zit hebben ze 't gelukkig goed begrepen; de software waar ze het verschil mee maken doen ze zelf in-house. Al het andere is SaaS/ PaaS/IaaS.

[EddoH]

Hydra schreef op vrijdag 5 oktober 2018 @ 12:53:
[...]


Ik neem tenminste nog de moeite inhoudelijk te reageren en het uit te leggen Maarja, dat knip je voor 't gemak maar ff weg

Nee, dat knip ik niet voor t gemak even weg, dat knip ik bewust weg omdat ik je manier van reageren op mijn post behoorlijk ondermaats vind en daar op reageer. Dat je lange tenen hebt weten we hier wel, maar dat bevestig je wel door mijn reactie als aanstellerij te bestempelen en nog een kinderachtige toespeling te maken in je 'uitleg'.

Je inhoudelijk reactie bestaat overigens uit niet meer dan een hele stapel aannames(zoals altijd) en je zoveelste ervaring bij ING.

Je had ook gewoon kunnen zeggen dat je eerdere uithaal wat idd voorbarig en ongefundeerd was. In plaats daarvan open je een persoonlijke aanval en ga je in tal van bochten wringen om maar per se je gelijk te kunnen halen.

[Sandor_Clegane]

Can't we all just get along?

[Hydra]

EddoH schreef op vrijdag 5 oktober 2018 @ 13:00:
Je had ook gewoon kunnen zeggen dat je eerdere uithaal wat idd voorbarig en ongefundeerd was. In plaats daarvan open je een persoonlijke aanval

Je leest 't zoals je het wil lezen. Het is hoe dan ook niet bedoeld als persoonlijke aanval.

Over het algemeen, dus generaliserend, zijn IT managers die zelf zooi willen hosten als dat niet nodig is gewoon debielen. Hun agenda is gewoon hoe meer IT hoe beter, want dan hebben ze meer mensen onder hun. Vaak zijn verhalen over controle vooral een combinatie van angst, onkunde en de wens een grote club mensen aan te sturen. Zelf-hosten gaat ook vaak omdat het gewoon eigenlijk wel een beetje geil is om een eigen datacenter met mooie knipperende lampjes en mooi weggewerkte snoertjes te hebben, dat jij als IT manager dan "gebouwd hebt". Dit is het soort 'manager' waar ik graag tegen ageer, omdat ze niet in 'the best interest' van het bedrijf handelen. Dit zijn verkeerde mensen op de verkeerde plaats. Debielen. Idioten.

Natuurlijk is m'n reactie naar Lethalis gechargeerd, dat was met opzet. Niet in de laatste plaats omdat ik weet dat hij het prima kan hebben. Ik heb hier een sterke mening over die ik graag onderbouw. Het is m'n werk ook om daar een sterke mening over te hebben, helaas moet ik die in het dagelijks leven wat subtieler uitdragen.

Wat ik verder niet goed snap is waarom jij er nu een persoonlijk ding tussen jou en mij van maakt. Nota bene zou ik op m'n teentjes getrapt zijn. Nou nee, alles behalve. In je reactie noem je me betweterig en respectloos. De eerste persoon die het persoonlijk maakt ben toch echt jij hoor.

Als @Lethalis m'n reactie te ver vindt gaan; prima. Dan bied ik met alle plezier daar m'n verontschuldiging voor aan en ik nuanceer het ook met alle plezier (wat ik overigens ook al gedaan heb in m'n uitleg op zijn reactie).

Dus het enige wat overblijft is dat ik een paar anonieme managers idioten hebt genoemd. Tja. Ik vind dat niet zo'n dingetje. Jij kennelijk wel. Sorry daarvoor.

Sandor_Clegane schreef op vrijdag 5 oktober 2018 @ 13:32:
Can't we all just get along?

Ligt eraan. Emacs of VIM?

[ Voor 4% gewijzigd door Hydra op 05-10-2018 14:09 ]

[NMe]

Laten we het verder inderdaad maar even vriendelijk houden. Bovenstaande post lijkt me een prima afsluiting daarvoor.

Hydra schreef op vrijdag 5 oktober 2018 @ 14:08:
Ligt eraan. Emacs of VIM?

Joe!

[Sandor_Clegane]

Hydra schreef op vrijdag 5 oktober 2018 @ 14:08:
[...]


Je leest 't zoals je het wil lezen. Het is hoe dan ook niet bedoeld als persoonlijke aanval.

Over het algemeen, dus generaliserend, zijn IT managers die zelf zooi willen hosten als dat niet nodig is gewoon debielen. Hun agenda is gewoon hoe meer IT hoe beter, want dan hebben ze meer mensen onder hun. Vaak zijn verhalen over controle vooral een combinatie van angst, onkunde en de wens een grote club mensen aan te sturen. Zelf-hosten gaat ook vaak omdat het gewoon eigenlijk wel een beetje geil is om een eigen datacenter met mooie knipperende lampjes en mooi weggewerkte snoertjes te hebben, dat jij als IT manager dan "gebouwd hebt". Dit is het soort 'manager' waar ik graag tegen ageer, omdat ze niet in 'the best interest' van het bedrijf handelen. Dit zijn verkeerde mensen op de verkeerde plaats. Debielen. Idioten.

Natuurlijk is m'n reactie naar Lethalis gechargeerd, dat was met opzet. Niet in de laatste plaats omdat ik weet dat hij het prima kan hebben. Ik heb hier een sterke mening over die ik graag onderbouw. Het is m'n werk ook om daar een sterke mening over te hebben, helaas moet ik die in het dagelijks leven wat subtieler uitdragen.

Wat ik verder niet goed snap is waarom jij er nu een persoonlijk ding tussen jou en mij van maakt. Nota bene zou ik op m'n teentjes getrapt zijn. Nou nee, alles behalve. In je reactie noem je me betweterig en respectloos. De eerste persoon die het persoonlijk maakt ben toch echt jij hoor.

Als @Lethalis m'n reactie te ver vindt gaan; prima. Dan bied ik met alle plezier daar m'n verontschuldiging voor aan en ik nuanceer het ook met alle plezier (wat ik overigens ook al gedaan heb in m'n uitleg op zijn reactie).

Dus het enige wat overblijft is dat ik een paar anonieme managers idioten hebt genoemd. Tja. Ik vind dat niet zo'n dingetje. Jij kennelijk wel. Sorry daarvoor.


[...]


Ligt eraan. Emacs of VIM?

Je hebt het ook wel mooi gebracht: "als dat niet nodig is" Dat is ook zo lekker rekbaar, laat dat nou net voor iedereen anders zijn. Je zou kunnen zeggen dat het voor die IT managers dus wel nodig is, of heb jij dan het laatste woord over wat "nodig" is?

[Lethalis]

Hydra schreef op vrijdag 5 oktober 2018 @ 11:34:
[...]
De kans dat er bij Google of AWS een hele region uitflikkert is extreem veel kleiner dan dat je lokaal gemanagde serverparkje er een keer helemaal uitligt. Alleen het verschil in kwaliteit van mensen dat een Google weet aan te trekken versus dat de gemiddelde hostingclub hier in Nederland heeft lopen is al immens.

Dat de uptime van een Google, AWS of Azure beter is, geloof ik zomaar.

Maar het van tevoren berekenen van de prijzen is een vak apart. En zonder hele duidelijke prijsopgaven ga je echt nergens komen bij het management.

Daarom eindigde de discussie bij ons uiteindelijk in een keuze tussen VPS-en huren bij een Nederlandse hosting provider voor een X bedrag per maand (met automatische backups en snapshots), of zelf ESXi servers in een co-locatie plaatsen en deze beheren.

Qua kosten leken de VPS-en goedkoper te zijn, maar qua betrouwbaarheid (of vertrouwdheid if you will) is dus voor een eigen oplossing gekozen.

Zodra wij naar een oplossing kijken, moeten we altijd met een fixed prijs voor iets komen. De simpele vraag "Wat kost dat?" moet een simpel antwoord hebben.

Het is ons destijds niet gelukt om die vraag goed te beantwoorden (voor Amazon en ook Azure) eerlijk gezegd. Ik wil daar persoonlijk best nog weleens induiken en eventueel een balletje opgooien op de zaak, maar ik moet dan uiteindelijk wel met een heel duidelijk verhaal komen.

Hydra schreef op vrijdag 5 oktober 2018 @ 14:08:
[...]
Als @Lethalis m'n reactie te ver vindt gaan; prima. Dan bied ik met alle plezier daar m'n verontschuldiging voor aan en ik nuanceer het ook met alle plezier (wat ik overigens ook al gedaan heb in m'n uitleg op zijn reactie).

Tsja, ik hou mij niet echt bezig met wie wel of geen idioot is.

Mijn doelstelling is meestal om te leren van anderen. Ik ben ook in de eerste plaats een programmeur en geen systeembeheerder. Sterker nog, ik beschouw mezelf als een lousy systeembeheerder En ik vind het dan ook jammer dat ik beheertaken op mijn werk heb, waar ik eigenlijk helemaal niet de verantwoording voor wil dragen.

Laat mij maar lekker programmeren.

Dus vanuit dat oogpunt ben ik juist voor een kant en klare oplossing die we gewoon ergens inhuren. De reden dat dit (nog) niet gebeurt, is natuurlijk deels ook een onervarenheid met de geopperde diensten (Amazon, Google, maar ook Azure).

Het is dan ook niet helemaal terecht om de manager daar volledig op af te branden, want hij vraagt ook aan ons wat de opties zijn. Hij neemt daarna - op basis van onze informatie - een beslissing.

Kunnen wij voor bepaalde diensten niet heel duidelijk aangeven hoe het zit... tsja, dan worden die van de lijst geschrapt. Ook als ik nu kijk, vind ik al die pricing calculators behoorlijk ingewikkeld.

Als dat mij ook een idioot of debiel maakt, omdat ik niet in staat lijk te zijn die informatie hapklaar naar het management te leveren, tsja Ik kan niet overal even goed in zijn.

Maar goed, ik weet wie het zegt. Ik kom jou al sinds pakweg 2002 op het internet tegen

[EddoH]

NMe schreef op vrijdag 5 oktober 2018 @ 14:12:
Bovenstaande post lijkt me een prima afsluiting daarvoor.

Dat vind ik niet , maar point taken.

[Hydra]

Lethalis schreef op vrijdag 5 oktober 2018 @ 14:39:
Dat de uptime van een Google, AWS of Azure beter is, geloof ik zomaar.

Maar het van tevoren berekenen van de prijzen is een vak apart. En zonder hele duidelijke prijsopgaven ga je echt nergens komen bij het management.

Die snap ik niet zo goed. Je hebt bij AWS ook gewoon prijzen, alleen betaal je over het algemeen niet per maand maar per minuut. Als je een paar VPSen hebt (heten EC2 instances bij AWS) die altijd 'aan' staan, dan ga je voor reserved instances in plaats van on-demand prijzen. Al deze zaken kun je met online calculators uitrekenen. Sterker nog; je hebt tools die voor je uitrekenen of je voor bepaalde instances niet liever reserved wil gebruiken omdat ze meer dan X% van de tijd aanstaan.

En dan heb je nog preemptible instances (Spot instances bij AWS). Die zijn extreem goedkoop maar hebben als nadeel dat ze uitgezet kunnen worden. Die zijn weer ideaal voor niet kritieke zaken. Ook hiervan kun je de prijzen inzien.

Is een AWS reserved instance duurder dan een Hetzner (om maar ff een goedkope te noemen) VPS van dezelfde grootte? Sure. Een beetje. Maar kwa garanties zit een Hetzner VPS ongeveer op 't niveau van een spot-instance van AWS.

En dan heb je het alleen over VPSjes. Als je het 'goed' doet en dus gewoon cloud native docker containers gaat draaien, heb je uberhaupt niks meer te maken met VPSen. Als je AWS lambda's gebruikt zijn per maand de eerste miljoen invocations gratis.

Dat zijn kosten, maar dan heb je nog garanties. Google en AWS bieden bijvoorbeeld op DNS (CloudDNS en Route53 IIRC) bizar hoge uptime garanties, 99.999% geloof ik ofzo. Idem voor zaken als S3. Zaken als een CDN heb je in no time geregeld.

Het is ons destijds niet gelukt om die vraag goed te beantwoorden (voor Amazon en ook Azure) eerlijk gezegd. Ik wil daar persoonlijk best nog weleens induiken en eventueel een balletje opgooien op de zaak, maar ik moet dan uiteindelijk wel met een heel duidelijk verhaal komen.

Dat hoef jij nieteens. Nodig gewoon knakkers van Amazon en Google uit (die hebben offices met Nederlandse mensen in Amsterdam) en die rekenen 't zo voor voor je.

M'n frustratie komt er vooral vandaan dat er verkeerde keuzes gemaakt worden door managers maar dit nooit de mensen zijn die dan ook de rotzooi op moeten ruimen. Als je mooie co-located roestbak gaat stuiteren midden in de nacht, dan is het meestal niet zelf die manager die het gaat fixen. Als je je spullen bij een goedkope Nederlandse host neerzet en midden in de nacht de packetloss naar 50% gaat (heb ik meegemaakt), is het niet die manager die dat gaat fixen. Ik doe zelf hoe dan ook geen standby support op spullen die ik niet zelf gebouwd heb.

Maar goed, ik weet wie het zegt. Ik kom jou al sinds pakweg 2002 op het internet tegen

Sterker nog, volgens mij hebben we zelfs nog dezelfde rare vrouw aangeduwd

[Matis]

Hydra schreef op vrijdag 5 oktober 2018 @ 15:11:
Sterker nog, volgens mij hebben we zelfs nog dezelfde rare vrouw aangeduwd

[Stoelpoot]

Hydra schreef op vrijdag 5 oktober 2018 @ 14:08:
[...]


Ligt eraan. Emacs of VIM?

Als jullie dat lekker uitvechten, gebruik ik VSCode wel...

[Lethalis]

Hydra schreef op vrijdag 5 oktober 2018 @ 15:11:
[...]
M'n frustratie komt er vooral vandaan dat er verkeerde keuzes gemaakt worden door managers maar dit nooit de mensen zijn die dan ook de rotzooi op moeten ruimen. Als je mooie co-located roestbak gaat stuiteren midden in de nacht, dan is het meestal niet zelf die manager die het gaat fixen. Als je je spullen bij een goedkope Nederlandse host neerzet en midden in de nacht de packetloss naar 50% gaat (heb ik meegemaakt), is het niet die manager die dat gaat fixen. Ik doe zelf hoe dan ook geen standby support op spullen die ik niet zelf gebouwd heb.

Die frustratie snap ik op zich prima, want ik ben samen met mijn collega's ook altijd de pineut als het misgaat natuurlijk. Onze hele afdeling had ook graag liever die VPS-en gehuurd

Ik ga zelf iig nog eens goed kijken ernaar. Sowieso moet ik ook eens met Azure spelen (als .NET ontwikkelaar zijnde).

Sterker nog, volgens mij hebben we zelfs nog dezelfde rare vrouw aangeduwd

Ik weet wel dat je iets met de ex vriendin van een vriend van mij hebt gehad, dus misschien bedoel je die? Dat eindigde niet zo best volgens mij.

[Matis]

AARGgh, zojuist twee uur verkloot met een stomme typo in de console:

mv /a/long/path/name/to/a/file ,

En ik maar niet begrijpen waarom ik de file niet meer kon vinden. Als je de directory listing doet (wat mij bij ls -halF is) valt het niet op dat er boven de . en .. nog een , staat

[Hydra]

Lethalis schreef op vrijdag 5 oktober 2018 @ 15:23:
Ik weet wel dat je iets met de ex vriendin van een vriend van mij hebt gehad, dus misschien bedoel je die? Dat eindigde niet zo best volgens mij.

Zou kunnen dat ze niet de waarheid heeft verteld, maar dat kwam wel vaker voor

[Lethalis]

Hydra schreef op vrijdag 5 oktober 2018 @ 16:10:
[...]
Zou kunnen dat ze niet de waarheid heeft verteld, maar dat kwam wel vaker voor

Nu we weten wie je bedoelt, ik was degene die op een regenachtige avond een vriend verdrietig aantrof in zijn appartement. Ik kwam daar gewoon niets vermoedend om Visual Studio te kopieren van hem.

Misschien was het wel een teken van het universum dat ik geen .NET had moeten leren

[Firesphere]

* Firesphere in huidige discussie

[Verwijderd]

Hydra schreef op vrijdag 5 oktober 2018 @ 14:08:
Ligt eraan. Emacs of VIM?

NeoVim

[Antrax]

* Antrax vraagt zich af of een egpu voldoet voor zijn Macbook voor o.a. gaming (yes, i know, bla bla) of gewoon een nieuwe game bak bouwen

[Lethalis]

Firesphere schreef op zondag 7 oktober 2018 @ 03:01:
* Firesphere in huidige discussie

Ik had ook ff zoiets van "waar gaat dit over" Maar dat is dus ruim 15 jaar geleden.

Inmiddels is iedereen verder gegaan met zijn leven en heeft kinderen etc (de mannen iig wel, hoe het met haar is afgelopen weet ik niet).

Ik vind de discussie over wel of geen cloud hosting een stuk interessanter. Ben ook benieuwd wie er hier met Azure werkt en wat de bevindingen daarvan zijn.

Lees namelijk meerdere ervaringen van mensen waar het behoorlijk duur is uitgepakt en die uiteindelijk weer ermee zijn gestopt.

Op zich begrijp ik wel dat je ook de kosten van het personeel moet meenemen. Twee keer zelfs, 1 keer voor het werk dat je aan het beheer kwijt bent, en 1 keer voor de inkomsten die je misloopt als diezelfde mensen ander nuttig werk zouden doen.

De vraag blijft natuurlijk ook of die garanties die je krijgt wel voor alle projecten nodig zijn.

Ik heb ook een narrowcasting project waarbij alle clients content cachen. Als daar de server er eens een dag uitligt, merken mensen het niet eens. Ondanks dat er ruim 300 clients zijn.

[ Voor 44% gewijzigd door Lethalis op 07-10-2018 16:20 ]

[Alex)]

Op een vorig project heb ik Azure gebruikt, maar eigenlijk alleen als hostingplatform (web apps, blob storage, SQL). Ik ben er eigenlijk wel tevreden mee: het gemak van shared hosting ("gooi je files in een folder en het werkt") met de wetenschap dat er een ervaren partij achter zit die alles beheert en onderhoudt (Microsoft), in combinatie met flinke schaalbaarheid in zowel de hoogte als de breedte.

Het is misschien wat duurder dan een VPS of een dedicated machine, maar je wordt flink ontzorgd. Bij ijzer in eigen beheer moet je ook alles zelf updaten, patchen en testen wat a) niet leuk is en b) tijdrovend. Bij Azure heb je daar gewoon geen omkijken meer naar.

[ Voor 29% gewijzigd door Alex) op 07-10-2018 17:34 ]

[Mugwump]

Lethalis schreef op zondag 7 oktober 2018 @ 15:59:
[...]

Ik had ook ff zoiets van "waar gaat dit over" Maar dat is dus ruim 15 jaar geleden.

Inmiddels is iedereen verder gegaan met zijn leven en heeft kinderen etc (de mannen iig wel, hoe het met haar is afgelopen weet ik niet).

Ik vind de discussie over wel of geen cloud hosting een stuk interessanter. Ben ook benieuwd wie er hier met Azure werkt en wat de bevindingen daarvan zijn.

Lees namelijk meerdere ervaringen van mensen waar het behoorlijk duur is uitgepakt en die uiteindelijk weer ermee zijn gestopt.

Op zich begrijp ik wel dat je ook de kosten van het personeel moet meenemen. Twee keer zelfs, 1 keer voor het werk dat je aan het beheer kwijt bent, en 1 keer voor de inkomsten die je misloopt als diezelfde mensen ander nuttig werk zouden doen.

De vraag blijft natuurlijk ook of die garanties die je krijgt wel voor alle projecten nodig zijn.

Ik heb ook een narrowcasting project waarbij alle clients content cachen. Als daar de server er eens een dag uitligt, merken mensen het niet eens. Ondanks dat er ruim 300 clients zijn.

Ik werk zelf wel redelijk wat met Azure, veelal bij wat grotere klanten die niet echt om geld verlegen zitten.
Daarbij heb ik als developer wel behoorlijke vrijheid om zelf aan te maken wat ik nodig heb. Dat is echt wel ideaal werken. Gewoon infra as code en je tuigt zonder enige moeite nieuwe omgevingen op.

In sommige gevallen kun je zo optimaliseren dat het erg kosteneffectief kan zijn, maar als je gewoon componenten "always on" hebt staan voor een maandelijkse fee, dan zal het niet goedkoper zijn dan de boel zelf regelen.

Ik denk dat je het ook niet puur voor het kostenplaatje doet, maar ook voor zaken als time-to-market, gebruikersgemak en alle zaken als scaling, monitoring, integratie met VSTS en ga zo maar door.

[whoami]

Lethalis schreef op zondag 7 oktober 2018 @ 15:59:
[...]

Ik vind de discussie over wel of geen cloud hosting een stuk interessanter. Ben ook benieuwd wie er hier met Azure werkt en wat de bevindingen daarvan zijn.

Alle projecten die wij doen (of toch die waar ik aan werk), hebben ergens wel iets met Azure te maken. (Op een project werk ik met Service Fabric, ServiceBus, een ander project maakt gebruik van AKS, ServiceBus, IoT-hub, .... ).
Ik maak dus eerder gebruik van de Paas offerings, en niet zozeer IaaS.
Allemaal heel leuk en interessant, je hebt iets nodigs, provisioned dat en het werkt gewoon. Met PaaS heb je dan nog eens het voordeel dat je je niet hoeft bezig te houden met de infrastructuur. De servers waar je applicatie op runt hoef je niet te onderhouden, dat doet iemand anders voor je. Je kan je gewoon meer concentreren en bezig houden met wat er voor jou van belang is: ontwikkelen.

Lees namelijk meerdere ervaringen van mensen waar het behoorlijk duur is uitgepakt en die uiteindelijk weer ermee zijn gestopt.

De kosten kunnen snel oplopen; ik denk niet dat je de KMO van om de hoek op Azure moet zetten. Volgens mij is het vooral interessant voor grote projecten.

[Lethalis]

whoami schreef op zondag 7 oktober 2018 @ 18:33:
[...]
Volgens mij is het vooral interessant voor grote projecten.

Deze indruk krijg ik dus ook.

Als mensen zelf hele clusters gaan bouwen, kan ik mij voorstellen dat een cloud oplossing uiteindelijk veel effectiever is.

Doe je dat echter niet, omdat je voor de projecten die je doet ook met een eenvoudigere oplossing af kunt - die dus veel minder tijd kost om te beheren - dan haal je minder uit de mogelijkheden die de cloud je kan bieden.

Desalniettemin wil ik wel wat testen gaan doen. Ik denk dat de enige manier is om vooral geen VM's te gebruiken, maar alleen containers te laten hosten.

Daarmee zou ik wellicht - door alleen te betalen voor wat je gebruikt - wat efficiency kunnen bereiken.

[Alex)]

Helemaal mee eens.

Het is van belang om van tevoren te bepalen wat je wilt doen en wat je daarvoor nodig hebt, en daar je infrastructuur op af te stemmen. Als je al toe kunt met shared hosting, waarom zou je dan Azure nemen?

[Sandor_Clegane]

Meh, dat hele cloud gebeuren is redelijk tweestrijdig in mijn optiek.

Regel 1: Het bijft andermans computer, hoe gemakkelijk je je daarbij voelt is voor iedereen anders, maar ik vind het wel een ding. Hoe gemakkelijk sommigen daar overheen stappen vind ik ook wel frappant. Maar ja, het is wat het is zeg maar. Ikzelf hou er wel van om dingen in eigen beheer te hebben, maar ja dat ben ik. Gaan ze TITSUP staat je data daar en moet je maar zien hoe je het weer krijgt. De manier om uit te leggen dat we stroom ook niet meer zelf opwekken dus waarom zou je nog wel je eigen servers willen hosten en het OS bijwerken enzo gaat mank op het feit dat stroom een een-weg straat is. Mijn bedrijf verrijkt het stroom niet als het uit de wandcontactdoos komt, maar de data die ik heb heeft wel degelijk een waarvermeerdering gehad doordat het in mijn bedrijf is terechtgekomen en kan dus dermate belangrijk zijn dat ik een ander er niet mee vertrouw. Appels en peren enzo.

Ervaring leert dat als shit hits the fan, en dat gebeurt, we werken met computers, dan is het fijn om van A tot Z alles onder controle te hebben.

Wat me vooral opvalt is dat mensen geen idee lijken te hebben hoe krachtig een huidige server is. Als je een beetje een server optuigt dan heb je toch een rekenkracht tot je beschikking, dat is echt fenomenaal. Daar komt bij dat ik weinig server software echt de hardware zie gebruiken, het is allemaal redelijk bedroevend als je kijkt naar wat er allemaal mogelijk is.

Met alle mooie verhaaltjes over redundancy, geloof ik niet dat alles zo mooi werkt als ze je doen geloven. De laatste outage van Azure was daar een mooi voorbeeld van. En voor iedereen die zegt dat het de core business van de cloud provider is om je spul in de lucht te houden is, ik geloof er weinig van. Het is vooral een bedrijf en de bottom line is dat ze voor zo weinig mogelijk kosten zoveel mogelijk klanten willen bedienen. Dus al dat geschoolde personeel in een datacenter is gewoon laag betaald personeel dat als alles goed gaat prima weten wat ze moeten doen maar als het een keer mis gaat, en dat gaat het, het blijven computers, met de handen in hun haar zitten.

Moet je alles zelf willen doen? Geen idee, dat is voor iedereen anders. Maar het gemak waarmee sommige dingen aan de kant worden gezet omdat het gemakkelijk is baart me wel zorgen. Komt bij dat ik denk dat AWS, Azure en Google Compute allang een keer gehacked zijn. Waarom denk ik dat? De exploits die ik de laatste tijd voorbij heb zien komen zijn dermate venijnig dat ze de kansberekening tegen zich hebben.

Heb je stateless servers en je wilt schaalbaarheid op piekmomenten? Neem vooral een cloud oplossing. Voor andere dingen zou ik me zeker nog eens achter mijn oor krabben.

[gold_dust]

Lethalis schreef op zondag 7 oktober 2018 @ 15:59:
...

Ik vind de discussie over wel of geen cloud hosting een stuk interessanter. Ben ook benieuwd wie er hier met Azure werkt en wat de bevindingen daarvan zijn.

Lees namelijk meerdere ervaringen van mensen waar het behoorlijk duur is uitgepakt en die uiteindelijk weer ermee zijn gestopt.

...

Cloud is niet een beetje te duur maar extreem veel te duur. Ik zit al langere tijd te kijken naar gpu servers voor machine learning bij verschillende aanbieders. Voor de prijs van één maand een gpu server huren kan ik lokaal een eigen workstation met gpu neerzetten. Ubuntu en gpu installeren stelt niks voor en kost zo goed als niets aan tijd. Daarnaast hebben cloud servers vaak veel te weinig en te trage storage en is de up/download altijd te traag. Stroomkosten wegen ook niet echt op tegen het enorme prijsverschil.

De cloud is echt iets voor managers die met de laatste hype mee willen gaan. Behalve de basis cloud vps'en voor een paar euro per maand ben je met een cloud server altijd te duur uit. Daar komen Microsoft's miljarden winsten tegenwoordig ook vandaan.

De enige optie waar ik een cloud server als realistische optie zie is als je werkelijk nu meteen direct een server nodig hebt en niet kan wachten tot de eigen hardware binnen is.

[Skyaero]

whoami schreef op zondag 7 oktober 2018 @ 18:33:
De kosten kunnen snel oplopen; ik denk niet dat je de KMO van om de hoek op Azure moet zetten. Volgens mij is het vooral interessant voor grote projecten.

Kleine onderneming (< 10 mensen) hier. Wij doen alles in Azure. In het verleden wel eigen servers gehad, maar menselijke capaciteit (en expertise) om deze te beheren is een behoorlijke kostenpost. Daarnaast remt het de schaalbaarheid enorm.

Daar komt bij dat je als je met .Net en/of Azure werkt, je ook als ISV (Independent Software Vendor) partner van Microsoft kunt worden. Levert (zeker voor een klein bedrijf) toch best wat financiële en in-kind voordelen op. De ISV meetings zijn erg interessant.

[ThomasG]

gold_dust schreef op zondag 7 oktober 2018 @ 22:56:
[...]

Cloud is niet een beetje te duur maar extreem veel te duur. Ik zit al langere tijd te kijken naar gpu servers voor machine learning bij verschillende aanbieders. Voor de prijs van één maand een gpu server huren kan ik lokaal een eigen workstation met gpu neerzetten. Ubuntu en gpu installeren stelt niks voor en kost zo goed als niets aan tijd. Daarnaast hebben cloud servers vaak veel te weinig en te trage storage en is de up/download altijd te traag. Stroomkosten wegen ook niet echt op tegen het enorme prijsverschil.

De cloud is echt iets voor managers die met de laatste hype mee willen gaan. Behalve de basis cloud vps'en voor een paar euro per maand ben je met een cloud server altijd te duur uit. Daar komen Microsoft's miljarden winsten tegenwoordig ook vandaan.

De enige optie waar ik een cloud server als realistische optie zie is als je werkelijk nu meteen direct een server nodig hebt en niet kan wachten tot de eigen hardware binnen is.

Het voordeel van Cloud zit hem vooral in het feit dat je gemakkelijk kunt opschalen wanneer dat nodig is. Als je de benodige capaciteit van te voren weet, dit voor lange tijd nodig hebt, en dat niet of nauwelijks gaat veranderen is Cloud eigenlijk atlijd te duur. Heb je een systeem die in piekgevallen veel capaciteit nodig heeft, maar in de meeste gevallen relatief weinig doet dat is Cloud een goedkopere oplossing. Het is dus niet zo dat Cloud altijd een betere oplossing is, dat ligt aan je eisen. Voor veel toepassingen kan Cloud echter wel een goede, en zelfs betere, oplossing zijn.

[Lethalis]

Sandor_Clegane schreef op zondag 7 oktober 2018 @ 22:49:
Wat me vooral opvalt is dat mensen geen idee lijken te hebben hoe krachtig een huidige server is. Als je een beetje een server optuigt dan heb je toch een rekenkracht tot je beschikking, dat is echt fenomenaal. Daar komt bij dat ik weinig server software echt de hardware zie gebruiken, het is allemaal redelijk bedroevend als je kijkt naar wat er allemaal mogelijk is.

Ik ben daar weleens mee bezig en ik vind het heel lastig om eerlijk te zijn.

Draai voor de lol maar eens een REST API die je met Golang geprogrammeerd hebt. En kijk dan naar het geheugen en de cpu cycles die het verbruikt.

Dan ga je toch bijna janken als je daarna diezelfde API met .NET bouwt.

Het is dat Golang qua programmeertaal wat basic is, maar ze hebben wel een strong selling point in dat opzicht. Juist als je software "voor de cloud" schrijft en betaalt naar het gebruik.

PS
Geen idee hoe OCAML het in dat opzicht doet overigens.

[ Voor 3% gewijzigd door Lethalis op 08-10-2018 10:48 ]

[TheNephilim]

ThomasG schreef op maandag 8 oktober 2018 @ 09:49:
[...]
Het voordeel van Cloud zit hem vooral in het feit dat je gemakkelijk kunt opschalen wanneer dat nodig is. Als je de benodige capaciteit van te voren weet, dit voor lange tijd nodig hebt, en dat niet of nauwelijks gaat veranderen is Cloud eigenlijk atlijd te duur. Heb je een systeem die in piekgevallen veel capaciteit nodig heeft, maar in de meeste gevallen relatief weinig doet dat is Cloud een goedkopere oplossing. Het is dus niet zo dat Cloud altijd een betere oplossing is, dat ligt aan je eisen. Voor veel toepassingen kan Cloud echter wel een goede, en zelfs betere, oplossing zijn.

Nou wij hadden vroegah een bult servers in eigen beheer, een eigen rack in een datacenter. Dat was voor ons een stuk duurder dan de cloud nu (gewoon een aantal VPSjes). De kosten zaten sowieso in de extra ampères die we nodig hadden en ook uitvallende hardware was een probleem. Alles dubbel uitvoeren is duur, niet alleen in aanschaf, maar ook maandelijks en na verloop van tijd als er wat vervangen moet worden.

[Koetjeboe]

Wij zitten sinds een paar jaar bij AWS, en voor ons zit de meerwaarde juist in de schaalbaarheid en randzaken. We hebben nu loadbalancers die automatisch meeschalen met de drukte, webservers die automatisch meeschalen en zichzelf vervangen als ze stuk zijn, databaseservers die automatisch opschalen. Daarnaast bied AWS ook veel extra diensten wat allemaal heel makkelijk integreert. Bijvoorbeeld als iemand een video upload in ons systeem wordt deze via een AWS dienst in 3 formaten getranscode. Je betaald daar puur voor wat je gebruikt, dus die feature kost ons een paar dollar per maand en dan werkt het gewoon altijd goed, ongeacht het formaat van het bronbestand. AWS heeft een email verzend dienst die we gebruiken die automatisch alles signed en bounces e.d. opvangt en naar ons doorstuurt. CDN, certificaten, deployen van code, cacheservers, elastic search, etc. Kun je allemaal zelf regelen, is vast kwa hosting en hardware goedkoper, maar nu is het gewoon geregeld en werkt het altijd. En, mocht er een keer iets mis gaan of als we hulp nodig hebben, de support (ja, waar je ook weer voor betaald) is van een heel hoog niveau. Goede, inhoudelijke antwoorden, snel, meedenkend, etc.

We komen van een paar grote nederlandse hosters af (zeker geen budget hosters), en dat was echt een heel ander verhaal. De fuckups die we daar elk jaar meemaakten...

[Sandor_Clegane]

Lethalis schreef op maandag 8 oktober 2018 @ 09:51:
[...]

Ik ben daar weleens mee bezig en ik vind het heel lastig om eerlijk te zijn.

Draai voor de lol maar eens een REST API die je met Golang geprogrammeerd hebt. En kijk dan naar het geheugen en de cpu cycles die het verbruikt.

Dan ga je toch bijna janken als je daarna diezelfde API met .NET bouwt.

Het is dat Golang qua programmeertaal wat basic is, maar ze hebben wel een strong selling point in dat opzicht. Juist als je software "voor de cloud" schrijft en betaalt naar het gebruik.

PS
Geen idee hoe OCAML het in dat opzicht doet overigens.

Ik snap je punt niet echt, Is .Net lomp vergeleken met Go? Of andersom? Ik heb nog nooit wat met Go gedaan.

[Lethalis]

TheNephilim schreef op maandag 8 oktober 2018 @ 09:59:
[...]
Nou wij hadden vroegah een bult servers in eigen beheer, een eigen rack in een datacenter. Dat was voor ons een stuk duurder dan de cloud nu (gewoon een aantal VPSjes). De kosten zaten sowieso in de extra ampères die we nodig hadden en ook uitvallende hardware was een probleem. Alles dubbel uitvoeren is duur, niet alleen in aanschaf, maar ook maandelijks en na verloop van tijd als er wat vervangen moet worden.

Het inhuren van VPS-en hadden wij ook bijna gedaan. Het grootste voordeel daarvan zijn de automatische snapshots en backups, en geen omkijken meer naar de hardware.

Ik zie ook zeker voor bepaalde klanten van ons voordelen als we die naar VPS-en zouden krijgen. Zeker op een dag als vandaag, als ik weer hoor dat een klant van ons een virus op zijn server heeft Dan zou je nu een snapshot terugzetten en klaar.

Maar ja, veel klanten van ons kiezen de locatie van hun pand op basis van commerciële doeleinden en kijken niet of nauwelijks naar de voorzieningen.

Gevolg daarvan is dat ze vaak niet veel meer kunnen krijgen dan ADSL ofzo. Tsja, maar wel duizenden orders per dag doen en 500GB aan data hebben.

Uploaden naar de cloud wordt hem dan niet...

Sandor_Clegane schreef op maandag 8 oktober 2018 @ 10:53:
[...]
Ik snap je punt niet echt, Is .Net lomp vergeleken met Go? Of andersom? Ik heb nog nooit wat met Go gedaan.

Je kunt Golang zien als een moderne variant van C met een ingebouwde garbage collector.

Ik heb er een paar programma's mee gemaakt voor de leuk en die gebruiken gemiddeld 6MB RAM.

Je leest het goed. 6. Niet 60. Niet 600.

6.

[ Voor 15% gewijzigd door Lethalis op 08-10-2018 10:56 ]

[Sandor_Clegane]

Lethalis schreef op maandag 8 oktober 2018 @ 10:53:
[...]

Het inhuren van VPS-en hadden wij ook bijna gedaan. Het grootste voordeel daarvan zijn de automatische snapshots en backups, en geen omkijken meer naar de hardware.

Ik zie ook zeker voor bepaalde klanten van ons voordelen als we die naar VPS-en zouden krijgen. Zeker op een dag als vandaag, als ik weer hoor dat een klant van ons een virus op zijn server heeft Dan zou je nu een snapshot terugzetten en klaar.

Maar ja, veel klanten van ons kiezen de locatie van hun pand op basis van commerciële doeleinden en kijken niet of nauwelijks naar de voorzieningen.

Gevolg daarvan is dat ze vaak niet veel meer kunnen krijgen dan ADSL ofzo. Tsja, maar wel duizenden orders per dag doen en 500GB aan data hebben.

Uploaden naar de cloud wordt hem dan niet...


[...]

Je kunt Golang zien als een moderne variant van C met een ingebouwde garbage collector.

Ik heb er een paar programma's mee gemaakt voor de leuk en die gebruiken gemiddeld 6MB RAM.

Je leest het goed. 6. Niet 60. Niet 600.

6.

Maar kunnen ze dan ook wat? Ik weet niet of ik .Net nu een memoryhog vind, ASP.net misschien.

[Gropah]

Wij hebben recentelijk bij de startup waar ik werk de belangrijkste REST API vervangen. We zijn van .NET/Mono naar Go gegaan. De API is qua architectuur ongeveer 1 op 1 overgenomen (en dus bijna zeer zeker geen idiomatic Go) en het heeft er zijn denk ik in het totaal 6 manweken in gestopt waarbij het het eerste project van de developers was wat ze in Go deden. Bij initiele tests was de Go API 5x zo snel als de mono API, was de gemiddelde replytijd lager en werden alle requests goed afgehandeld, waarde Mono API dat niet had.

Naast dat het sneller is, was de vorige Mono API ook in een framework geschreven wat intern geschreven was en eigenlijk maar door 1 persoon gesnapt werd. Al met al genoeg reden om compleet over te gaan naar Go voor ons.

En ja, Go is redelijk basaal in language features, maar dat zorgt er juist voor dat het makkelijk is voor iemand om op te pakken. En standaard word er wel veel meegeleverd in de standaard library. Enige wat mistte was de mogelijkheid om variabelen of regex'en in paden van de API te gooien, maar daar zijn genoeg libraries voor. Sommige maken het nog sneller dan het al is.

edit: nog even om te verduidelijken, het is niet de silver bullet, maar voor onze usecase is het een goede fit.

[ Voor 4% gewijzigd door Gropah op 08-10-2018 11:19 ]

[Mugwump]

gold_dust schreef op zondag 7 oktober 2018 @ 22:56:
[...]

Cloud is niet een beetje te duur maar extreem veel te duur. Ik zit al langere tijd te kijken naar gpu servers voor machine learning bij verschillende aanbieders. Voor de prijs van één maand een gpu server huren kan ik lokaal een eigen workstation met gpu neerzetten. Ubuntu en gpu installeren stelt niks voor en kost zo goed als niets aan tijd. Daarnaast hebben cloud servers vaak veel te weinig en te trage storage en is de up/download altijd te traag. Stroomkosten wegen ook niet echt op tegen het enorme prijsverschil.

De cloud is echt iets voor managers die met de laatste hype mee willen gaan. Behalve de basis cloud vps'en voor een paar euro per maand ben je met een cloud server altijd te duur uit. Daar komen Microsoft's miljarden winsten tegenwoordig ook vandaan.

De enige optie waar ik een cloud server als realistische optie zie is als je werkelijk nu meteen direct een server nodig hebt en niet kan wachten tot de eigen hardware binnen is.

Enkel kijken naar je eigen use case en constateren dat cloud 'iets is voor managers' is wel erg kortzichtig. Je kijkt hier specifiek naar 'even wat rekenkracht' aanschaffen. Ja een GPU machine fulltime aanzetten is al snel duurder dan de pure aanschaf van een machine en ja voor de prijzen die Azure vraagt kun je ook nog wel een paar uurtjes installatie doen. Maar je moet bij een beetje serieuze toepassing ook rekening houden met backups, monitoring en ga zo maar door. Vaak

Cloud wordt natuurlijk al interessanter als je een GPU-machine even twee dagen kan aanzetten, een neuraal netwerk kunt trainen en weer weg kunt gooien. Als jij handig gebruik kunt maken van de 'on-demand' variant van Cloud, dan kan dat best voordelig zijn. Dat artikel over die password lookup database van laatst is een mooi voorbeeld hoe je dat tot in het extreme kunt doorvoeren.

Maar nee, als je full-time up-and-running IaaS wil waarbij vele waarborgen en out of the box functionaliteit omtrent backups, monitoring en ga zo maar door niet relevant zijn, dan zou ik voor de kosten inderdaad niet naar de cloud gaan. Gebruik je allerlei PaaS en SaaS diensten en kun je handig gebruik maken van on-demand / pay-per-use, dan kan een cloudprovider ook kostentechnisch best interessant zijn.

[Styxxy]

Gropah schreef op maandag 8 oktober 2018 @ 11:19:
Wij hebben recentelijk bij de startup waar ik werk de belangrijkste REST API vervangen. We zijn van .NET/Mono naar Go gegaan.
[...]
edit: nog even om te verduidelijken, het is niet de silver bullet, maar voor onze usecase is het een goede fit.

Ik ben dan toch benieuwd naar de vergelijking .NET Core <-> Go. (ASP?).NET in Mono kan ik me wel inbeelden dat dit niet het performantste is (sowieso, ASP.NET Web Api <-> ASP.NET Core is al een groot verschil).

Is er een specifieke reden waarom jullie niet naar .NET Core hebben gekeken?

[ Voor 6% gewijzigd door Styxxy op 08-10-2018 13:05 ]

[Lethalis]

Sandor_Clegane schreef op maandag 8 oktober 2018 @ 10:59:
[...]


Maar kunnen ze dan ook wat? Ik weet niet of ik .Net nu een memoryhog vind, ASP.net misschien.

Wij draaien hier Gitea (een Gogs.io kloon) voor onze source control. Dat is een heel dashboard / portal geschreven in Golang.

Het gebruikt 30MB. Dat is net zoveel als mijn Hello World .NET Core web api

Kijk ik echter naar Full CLR web applicaties van ons, dan zitten de meeste ervan ruim boven de 100MB.

Gropah schreef op maandag 8 oktober 2018 @ 11:19:
En ja, Go is redelijk basaal in language features, maar dat zorgt er juist voor dat het makkelijk is voor iemand om op te pakken. En standaard word er wel veel meegeleverd in de standaard library. Enige wat mistte was de mogelijkheid om variabelen of regex'en in paden van de API te gooien, maar daar zijn genoeg libraries voor. Sommige maken het nog sneller dan het al is.

Mja ik vond het in sommige opzichten net iets te basaal (omslachtige error handling en geen generics, waardoor functioneel programmeren ook lastig wordt).

In .NET gebruik ik toch best veel LINQ de laatste tijd en ook eigen extension methods. Het maakt code een stuk voorspelbaarder en simpeler.

Dat gezegd hebbende, zijn verbeterde error handling en generics speerpunten voor Go 2.0.

[ Voor 54% gewijzigd door Lethalis op 08-10-2018 13:31 ]

[Sandor_Clegane]

Maar dan nog 100MB, dat is toch ook redelijk weinig? Helemaal voor een redelijke server.

[Hydra]

Oh lol, Go. Volkomen bizar dat je van een prima taal als C# naar dat gedrocht gaat. Geen exceptions, geen generics, geen inheritance, geen method overloads, tooling die dependencies managed door gewoon een github master over te hevelen. Dat Node.js hipsters overstappen van Node naar Go is nog te volgen omdat ze gewoon niet beter weten, maar als m'n bedrijf van C# naar Go over zou gaan, zou ik snel op zoek naar iets nieuws gaan.

Go is door Google ontwikkeld omdat Google een onethisch bedrijf is dat het niet belangrijk vindt mensen uit school te leren hoe je echt software ontwikkelt. Rob Pike is een arrogante bal die halverwege het bouwen van een grammar erachter kwam dat het allemaal best complex is en vond het een nuttigere tijdsbesteding om maar papers te gaan schrijven over hoe generics en exceptions evil zijn (Go 2 krijgt generics overigens, go figure).

Een deel van me vermoed gewoon dat Google Go pushed intern omdat ze problemen hebben mensen te houden (gemiddeld genomen vertrekken mensen na 1.8 jaar weer). Als je ze minder in-demand skills leert blijven ze langer.

Go bewijst dat we als industrie steeds dezelfde domme fouten blijven maken.

</rant>

[Gropah]

Sandor_Clegane schreef op maandag 8 oktober 2018 @ 13:50:
Maar dan nog 100MB, dat is toch ook redelijk weinig? Helemaal voor een redelijke server.

Het hangt er heel erg vanaf wat je doet en wat je architectuur is. Als je een monolith hebt is 100mb overhead geen probleem, maar bij microservices al wel (sneller).

Lethalis schreef op maandag 8 oktober 2018 @ 13:23:
[...]

Mja ik vond het in sommige opzichten net iets te basaal (omslachtige error handling en geen generics, waardoor functioneel programmeren ook lastig wordt).

In .NET gebruik ik toch best veel LINQ de laatste tijd en ook eigen extension methods. Het maakt code een stuk voorspelbaarder en simpeler.

Dat gezegd hebbende, zijn verbeterde error handling en generics speerpunten voor Go 2.0.

Error handling is inderdaad wat naar af en toe, maar het zorgt er wel voor dat je veel expliciter gaat nadenken over je error handling. En dat is (naar mijn ervaring) juist waar de meeste bugs zitten.

Hydra schreef op maandag 8 oktober 2018 @ 14:01:
Oh lol, Go. Volkomen bizar dat je van een prima taal als C# naar dat gedrocht gaat. Geen exceptions, geen generics, geen inheritance, geen method overloads, tooling die dependencies managed door gewoon een github master over te hevelen.

[Rant over Google als software developer]

Sinds een maand of 2 is er in de standaard toolchain een package manager ingebouwd die het mogelijk maakt om semver tags van een gitrepo te gebruiken voor dependency management, maar daarvoor was het voor mij ook een reden om Go links te laten liggen. Geen inheritence is gedeeltelijk waar, het is mogelijk mbv composition. En het is mogelijk om interfaces te beschrijven welke objecten kunnen implementeren waardoor er toch een soort van generics mogelijk is.

[Hydra]

Laat ik voorop stellen dan m'n 'enthusiasme' tegen Go niks met jou persoonlijk te maken heeft!

Gropah schreef op maandag 8 oktober 2018 @ 14:08:
Sinds een maand of 2 is er in de standaard toolchain een package manager ingebouwd die het mogelijk maakt om semver tags van een gitrepo te gebruiken voor dependency management, maar daarvoor was het voor mij ook een reden om Go links te laten liggen.

In het Node.js ecosysteem waren ze er een tijdje geleden al achter dat Bower een enorm slecht idee was. Zegmaar een jaar of 4 terug. Dus dat zegt nogal wat over de Go maintainers.

Geen inheritence is gedeeltelijk waar, het is mogelijk mbv composition.

Go's interface zijn een vorm van duck-typing en daarom enorm gevaarlijk. Als ik een interface implementeer met dezelfde vorm 'is' het opeens een interface die past. Dit is een domme workaround voor het gebrek aan bijvoorbeeld generics.

Go heeft geen inheritance. Een interface is een contract. Marker interfaces bijvoorbeeld zijn in Go niet mogelijk.

En het is mogelijk om interfaces te beschrijven welke objecten kunnen implementeren waardoor er toch een soort van generics mogelijk is.

Go heeft intern voor z'n eigen API generics omdat ze het teveel werk vonden voor alle verschillende types de collections opnieuw te bouwen. Alleen is dit nooit geexposed in de taal. En collections bouwen zoals je in C# kan voor een willekeurige <T> kan Go gewoon echt niet.

Ik heb zelf best veel met Go gedaan, command line tools en een paar REST services. En vooral bij die laatste valt op dat, t.o.v. de standaard Java frameworks, Go echt ronduit een kuttaal is. Ik programmeer liever een Node.js back-end service dan een Go service. Alle gebreken van Go hinderen code reuse enorm (kijk in de standaard API maar naar hoe je een string-split; geen overloads dus overal kopieen) en dat zie je terug in Go projecten; copy-paste based development.

En dat Go geen exceptions kent is te bizar voor woorden. Als je een standaard service maakt, met een controller, service en repository laag, dan zit je in elke laag in iedere functie te kijken of er een error optreedt en dit dan door te sturen.

Ik heb meerdere malen discussies gehad met mensen die me Go proberen te verkopen, en dit zijn altijd of Ops mensen, of developers die nog nooit een enigzins complexe service in Go gebouwd hebben. En vooral die eerste categorie heb ik ronduit een hekel aan gekregen; iets te veel discussies met Ops types gehad die gaan lopen verkondigen dat Exceptions evil zijn, Generics evil zijn, Java kut is, etc. Dat is het rotte aan het Go ecosysteem vooral; de mensen.

Ik kan het nogal fel op reageren omdat het precies zo goed weergeeft wat er mis is met veel hedentendaagse developers. De reden dat iets als Maven niet rechtstreeks van Github trekt is niet omdat ze het perse moeilijk willen doen, het is omdat het een fucking slecht idee is. De reden dat moderne talen neigen naar een combinatie van OO en functionele talen is niet omdat we graag stoffige oude zooi produceren, het is omdat abstracties bouwen noodzakelijk is om complexe shit begrijpelijk te houden. De volgende opser die me meldt dat exceptions en generics evil zijn gaat 't raam uit.

Zo.

[Falcon]

Azure-DevOps voor WEST-EUROPE ligt er uit

https://twitter.com/AzureSupport/with_replies

[Lethalis]

Sandor_Clegane schreef op maandag 8 oktober 2018 @ 13:50:
Maar dan nog 100MB, dat is toch ook redelijk weinig? Helemaal voor een redelijke server.

Maar het is wel ruim 3 keer zoveel. Heb je dus veel applicaties draaien, dan heb je 3 keer zoveel hardware (of cloud computing power ) nodig.

Wel is .NET Core in dit opzicht een stuk beter geworden ten opzichte van de Full CLR. En sinds ik met F# aan het spelen ben, denk ik niet dat ik zo snel weer naar zoiets als Golang terug zou gaan.

Ook denk ik dat .NET Core in de toekomst alleen maar efficiënter zal worden.

Je ziet toch dat het open sourcen ervan tot een hoop nieuwe ontwikkelingen leidt.

[Koenvh]

Falcon schreef op maandag 8 oktober 2018 @ 15:10:
Azure-DevOps voor WEST-EUROPE ligt er uit

https://twitter.com/AzureSupport/with_replies

Klinkt als koffietijd

[Sandor_Clegane]

Falcon schreef op maandag 8 oktober 2018 @ 15:10:
Azure-DevOps voor WEST-EUROPE ligt er uit

https://twitter.com/AzureSupport/with_replies

Lol, dat is wel timely.

[Falcon]

Sandor_Clegane schreef op maandag 8 oktober 2018 @ 15:39:
[...]


Lol, dat is wel timely.

* Falcon kijkt met een schuin oog naar@Sandor_Clegane

[Sandor_Clegane]

Falcon schreef op maandag 8 oktober 2018 @ 15:42:
[...]


* Falcon kijkt met een schuin oog naar@Sandor_Clegane

Tja, met die discussie over wel of geen cloud......

[Falcon]

Sandor_Clegane schreef op maandag 8 oktober 2018 @ 15:48:
[...]


Tja, met die discussie over wel of geen cloud......

Ach met het ijzer in je eigen datacentertje of hosted gaat het ook weleens wat mis. Prima moment voor nog wat te refinen of gewoon simpelweg teambuilding/nerfguns-op-collega's-legen.

[Sandor_Clegane]

Dat spreek ik ook niet tegen maar de timing was te mooi

[boe2]

*knip* verkeerd gelezen

[ Voor 95% gewijzigd door boe2 op 08-10-2018 16:38 ]

[Mugwump]

Hier nergens last van met DevOps overigens.

[Mercatres]

Falcon schreef op maandag 8 oktober 2018 @ 15:10:
Azure-DevOps voor WEST-EUROPE ligt er uit

https://twitter.com/AzureSupport/with_replies

Haha, hier was het ook even een lichte paniek.

Mugwump schreef op maandag 8 oktober 2018 @ 16:43:
Hier nergens last van met DevOps overigens.

Het is inmiddels ook opgelost bij ons. Geen idee wat ze aan 't uitspoken zijn daar.

Wel gerelateerd aan 't hele DevOps gebeuren: nog anderen aanwezig geweest op TechoramaNL vorige week?

[ Voor 40% gewijzigd door Mercatres op 08-10-2018 16:54 ]