De Devschuur Coffee Corner - Iteratie ⓬

[farlane]

Mugwump schreef op vrijdag 2 november 2018 @ 13:39:
[...]
Je hebt primitieve tools die door de onderliggende laag begrepen worden (browsers versus OS'en / hardware). In de loop der tijd komen er 'hogere talen' die uiteindelijk weer 'compilen' naar de basale instructies die door het onderliggende systeem worden begrepen.

Ik begrijp je redenering, maar maar ik zie niet in hoe je CSS een 'primitieve tool' kunt noemen. Dadelijk gaan we Javascript 'native' noemen zeker ...

R4gnax schreef op vrijdag 2 november 2018 @ 20:24:
[...]
Dat je het 'handig' met extend kunt bereiken, betekent niet gelijk dat het dan ook een goed idee is:

https://webinista.com/updates/dont-use-extend-sass/
https://www.sitepoint.com/avoid-sass-extend/
https://www.sitepoint.com/sass-extend-nobody-told-you/
https://csswizardry.com/2...tend-when-to-use-a-mixin/
https://oliverjash.me/201...ing-objects-in-oocss.html
https://www.smashingmagaz...ing-in-sass-without-mess/

Je komt met redenen waarom je inheritance in SCSS niet zou moeten gebruiken maar mijn opmerking ging over CSS. Hieruit blijkt eigenlijk dat je er zelfs met SCSS niet fatsoenlijk omheen kunt werken....

Je lijkt overigens de essentie van mijn opmerking compleet niet te (willen) begrijpen, er is weinig plek voor gezonde kritiek op een tool (die je naar ik aanneem zelf vaak gebruikt) lijkt het.

[edit]
Ik zie nu dat het ook letterlijk wordt genoemd op een bekende online encyclopedie, due doe nou niet of iedereen die dit als een tekortkoming ziet te achterlijk is voor CSS:

Cannot include styles from a rule into another rule
CSS styles often must be duplicated in several rules to achieve a desired effect, causing additional maintenance and requiring more thorough testing. Some new CSS features were proposed to solve this, but (as of February, 2016) are not yet implemented anywhere.

[ Voor 62% gewijzigd door farlane op 03-11-2018 11:36 ]

[R4gnax]

farlane schreef op zaterdag 3 november 2018 @ 11:00:

Je lijkt overigens de essentie van mijn opmerking compleet niet te (willen) begrijpen, er is weinig plek voor gezonde kritiek op een tool (die je naar ik aanneem zelf vaak gebruikt) lijkt het.

Jij lijkt niet te begrijpen dat wanneer je een schroevendraaier als hamer gaat gebruiken, je daar weinig succes mee gaat hebben.

CSS is nooit bedoeld geweest om logge single inheritance op te zetten.
De aard van CSS leent zich echter wel voor een systeem van te stapelen traits.
Gebruik het dan ook zo!

[Mugwump]

farlane schreef op zaterdag 3 november 2018 @ 11:00:
[...]

Ik begrijp je redenering, maar maar ik zie niet in hoe je CSS een 'primitieve tool' kunt noemen. Dadelijk gaan we Javascript 'native' noemen zeker ...

Ik zou het niet native noemen, maar feit is wel dat JavaScript het enige is dat een browser slikt.

Het punt is natuurlijk dat JavaScript en CSS nog zo voortvarend kunnen zijn met het implementeren van nieuwe standaarden en features, maar ze voor de adoptie volledig afhankelijk zijn van Browsersupport / implementatie. Dat is een situatie die analoog is aan wat je ziet bij low level languages.

De gebruikelijke aanpak is dan om een laag erboven te hangen die vervolgens weer "compileert" naar het onderliggende niveau op een manier die in alle browsers wordt ondersteund.

Op het moment dat je zelf de controle hebt over de runtime / compiler kun je makkelijk nieuwe features adopteren, maar als dat niet het geval is, dan is een laag er bovenop gewoon de verstandigste keuze.

[Lethalis]

Mugwump schreef op zaterdag 3 november 2018 @ 14:13:
[...]
Ik zou het niet native noemen, maar feit is wel dat JavaScript het enige is dat een browser slikt.

Daar komt met webassembly gelukkig een eind aan.

In de toekomst kun je gewoon C#, Golang, enzovoorts compileren naar webassembly en dat draait dan direct in de browser.

[Hydra]

Lethalis schreef op zaterdag 3 november 2018 @ 15:03:
In de toekomst kun je gewoon C#, Golang, enzovoorts compileren naar webassembly en dat draait dan direct in de browser.

Er zijn genoeg cross-compilers voor talen die datzelfde doen. Maar om een of andere reden is dat nooit erg succesvol. Ik vermoed dat je de impact van wasm een beetje overschat.

[farlane]

R4gnax schreef op zaterdag 3 november 2018 @ 12:38:
[...]
Jij lijkt niet te begrijpen dat wanneer je een schroevendraaier als hamer gaat gebruiken, je daar weinig succes mee gaat hebben.

CSS is nooit bedoeld geweest om logge single inheritance op te zetten.
De aard van CSS leent zich echter wel voor een systeem van te stapelen traits.
Gebruik het dan ook zo!

Je impliceert dat ik CSS wil gebruiken waar het niet voor bedoeld is, dat is niet waar. Het is zelfs zo domein specifiek dat dat volgens mijn niet eens zou kunnen.

Bovendien beweer je met een strategisch geplaatst bijvoeglijk naamwoord dat single inheritance (wat inderdaad een uitkomst zou zijn) log is; heb je daar ook een onderbouwing bij?

[Mugwump]

Hydra schreef op zaterdag 3 november 2018 @ 15:54:
[...]


Er zijn genoeg cross-compilers voor talen die datzelfde doen. Maar om een of andere reden is dat nooit erg succesvol. Ik vermoed dat je de impact van wasm een beetje overschat.

Dat klopt helaas en WASM is ook niet bedoeld als volwaardige vervanger van JS maar meer als een toevoeging.

Ik ben zelf wel een liefhebber van frameworks als Vaadin. Zeker voor web apps die niet zwaar geoptimaliseerd hoeven te zijn heb je daarmee echt zo een UI in elkaar geknutseld.

[EddoH]

edit: laat maar, leuk geweest

[ Voor 92% gewijzigd door EddoH op 03-11-2018 19:25 ]

[Lethalis]

Hydra schreef op zaterdag 3 november 2018 @ 15:54:
[...]
Er zijn genoeg cross-compilers voor talen die datzelfde doen. Maar om een of andere reden is dat nooit erg succesvol. Ik vermoed dat je de impact van wasm een beetje overschat.

Het succes ervan staat of valt met de API surface. Zo heb je bijvoorbeeld een DOM API nodig.

Het grootste verschil met eerdere pogingen is dat deze keer wel degelijk daar aan gewerkt wordt.

Maar goed, het is nog te vroeg om echt te beoordelen of het een succes wordt. Het kan iig enorme voordelen bieden qua performance en productiviteit.

Ik hoop het iig wel, want ik zie JavaScript het liefst verdwijnen

[Alex)]

Ruim tien jaar geleden had Microsoft een experiment, Project Volta. Je programmeerde in .NET en dat werd gecrosscompiled naar Javascript. Dat kon je vervolgens in de browser draaien. Snel was het niet, grappig was het wel.

Tegenwoordig proberen ze het opnieuw, met Blazor. Dat wordt gecompileerd naar WebAssembly en werkt een heel stuk sneller.

[RayNbow]

Alex) schreef op zaterdag 3 november 2018 @ 21:01:
Ruim tien jaar geleden had Microsoft een experiment, Project Volta.

Volgens mij heb ik nog een kopie van de Channel9 video's over dat project ergens op een schijf staan (op Channel9 zijn ze inmiddels verwijderd)...


Het logo van het project leeft in ieder geval nog voort:

[Sandor_Clegane]

^^ Dat is het RX logo.

[Mugwump]

Alex) schreef op zaterdag 3 november 2018 @ 21:01:
Ruim tien jaar geleden had Microsoft een experiment, Project Volta. Je programmeerde in .NET en dat werd gecrosscompiled naar Javascript. Dat kon je vervolgens in de browser draaien. Snel was het niet, grappig was het wel.

Tegenwoordig proberen ze het opnieuw, met Blazor. Dat wordt gecompileerd naar WebAssembly en werkt een heel stuk sneller.

Voor Java heb je nog steeds GWT wat volgens mij nauwelijks gebruikt en onderhouden wordt en het wat populairdere Vaadin dat daarop gebaseerd is. Vooral laatstgenoemde vind ik echt heerlijk werken, omdat je volledige IDE support hebt, WYSIWYG-plugins voor de bekende IDE's en ga zo maar door.
Misschien niet geschikt voor consumer-facing websites met enorme hoeveelheden verkeer, maar voor het gros van de web-based applications prima te doen.

[Hydra]

Oh wow. Ik zit een beetje te zoeken naar pianoleraren hier in de buurt, kom ik op deze site: http://www.pianostudio.nl/

code:

<META content="Microsoft FrontPage 4.0" name=GENERATOR>

En frames! Wow!

Het is zo fout dat het gewoon gaaf is

[gekkie]

Klassieke website, zou het dan ook klassieke piano zijn ?

[ThomasG]

Hydra schreef op zondag 4 november 2018 @ 10:40:
Oh wow. Ik zit een beetje te zoeken naar pianoleraren hier in de buurt, kom ik op deze site: http://www.pianostudio.nl/

code:

<META content="Microsoft FrontPage 4.0" name=GENERATOR>

En frames! Wow!

Het is zo fout dat het gewoon gaaf is

Het mooie vind ik dan nog wel dat de site eigenlijk http://www.gnuss.com is, alle tekst op de site wijst naar pianostudio.nl, maar het frame op pianostudio.nl dus verwijst naar gnuss.com.

[RagingPenguin]

Hydra schreef op zondag 4 november 2018 @ 10:40:
Oh wow. Ik zit een beetje te zoeken naar pianoleraren hier in de buurt, kom ik op deze site: http://www.pianostudio.nl/

code:

<META content="Microsoft FrontPage 4.0" name=GENERATOR>

En frames! Wow!

Het is zo fout dat het gewoon gaaf is

En de daadwerkelijke body zit gewoon in een

code:

<table border="0" width="108%"></table>

(ja, 108% width )

[Mugwump]

Hydra schreef op zondag 4 november 2018 @ 10:40:
Oh wow. Ik zit een beetje te zoeken naar pianoleraren hier in de buurt, kom ik op deze site: http://www.pianostudio.nl/

code:

<META content="Microsoft FrontPage 4.0" name=GENERATOR>

En frames! Wow!

Het is zo fout dat het gewoon gaaf is

Ik heb op een blauwe maandag nog wat gedaan bij detelefoongids.nl waar de eigen websites van veel bedrijven vaak een bron van hilariteit waren. Met name deze bakker en dit hotel hebben lichtelijk vloekende sites.

[Koenvh]

Hydra schreef op zondag 4 november 2018 @ 10:40:
Oh wow. Ik zit een beetje te zoeken naar pianoleraren hier in de buurt, kom ik op deze site: http://www.pianostudio.nl/

code:

<META content="Microsoft FrontPage 4.0" name=GENERATOR>

En frames! Wow!

Het is zo fout dat het gewoon gaaf is

Web 1.0 op zijn best.

[AW_Bos]

Frontpage mag wel behoorlijk oud zijn, maar de PHP-code van velen is dat blijkbaar ook.
Op een PHP-forum waar ik moderator ben krijgen we nu bijna aan de lopende band topics van mensen die opeens klagen dat hun site niet werkt, omdat de hosting op PHP 7 is overgestapt.
Veel mensen hebben een mogelijkheid gezien om het uit te testen, maar lopen nu wel tegen deadlines van hen aan.

Voor een uitzondering heb ik even maar even iemand geholpen met zijn code,maar wat een brok ellende was. Reguliere expressies om te kijken of er al maar iets was ingevuld, dubbelzinnige statements en vage vergelijkingen die dan weer tre of false zijn i.c.m de ! die het weer false maakt.
Omdat ik toch niks te doen had deze zondag heb ik die code maar even lichtjes verbeterd. De brok oude HTML zoeken ze maar zelf uit. Maar de HTML en PHP is nu meer gescheiden van elkaar

Nu mijn site even goed testen op PHP 7.2 wat nu nog op PHP 5.4 draait. hele source op de schop, nieuwe layout, en stukken beter ingedeeld in classes . Ook wel mooi dat PHP 7 exceptions opwerkt bij warnings. Kan ik meteen handig een foutafhandeling inbouwen om human-friendly errors te bouwen.

PS: Die Frontpage meta-tag, het zou toch wel droog zijn als je die zomaar in je hippe Web 3.0 site inbouwt, terwijl je totaal niet met Frontpage in de weer bent geweest Waar is die tag in vredesnaam nu nuttig voor ?

[ Voor 13% gewijzigd door AW_Bos op 04-11-2018 14:35 ]

[Hydra]

Mugwump schreef op zondag 4 november 2018 @ 13:03:
Met name deze bakker

Niets straalt professionaliteit uit als rode Comic Sans op een gele achtergrond...

Edit: Die random 'wijsheden' onderaan

[ Voor 20% gewijzigd door Hydra op 04-11-2018 16:09 ]

[SideSplitter]

Hydra schreef op zondag 4 november 2018 @ 16:08:
[...]


Niets straalt professionaliteit uit als rode Comic Sans op een gele achtergrond...

Edit: Die random 'wijsheden' onderaan

"Ik heb een drankprobleem... ik heb maar 1 mond." Prachtig dit

[downtime]

Mugwump schreef op zondag 4 november 2018 @ 13:03:
[...]

Met name deze bakker en dit hotel hebben lichtelijk vloekende sites.

Voor a family hotel with a friendly atmosphere roept die charmante knulligheid juist helemaal de juiste sfeer op. Daar is ongetwijfeld lang over nagedacht door een hele dure consultant.

[Mugwump]

downtime schreef op zondag 4 november 2018 @ 16:24:
[...]

Voor a family hotel with a friendly atmosphere roept die charmante knulligheid juist helemaal de juiste sfeer op. Daar is ongetwijfeld lang over nagedacht door een hele dure consultant.

Dat moet haast wel, want als ik het me goed herinner gaven ze echt een godsvermogen uit bij DTG. Daar had men een vrij prijzig webbureautje een hele strakke website van kunnen laten maken.

[farlane]

downtime schreef op zondag 4 november 2018 @ 16:24:
[...]

Voor a family hotel with a friendly atmosphere roept die charmante knulligheid juist helemaal de juiste sfeer op. Daar is ongetwijfeld lang over nagedacht door een hele dure consultant.

Ik denk dat een Amerikaanse tourist zich meteen helemaal thuis voelt op die site/in dat hotel eerlijk gezegd ...

[Verwijderd]

Niet dat detelefoongids.nl zo geweldig is; hij vult niet eens de volledige breedte op mijn 1440p scherm:

[Mugwump]

Verwijderd schreef op zondag 4 november 2018 @ 17:06:
Niet dat detelefoongids.nl zo geweldig is; hij vult niet eens de volledige breedte op mijn 1440p scherm:

[Afbeelding]

Nee, alles wat enigszins capaciteiten had is daar al lang en breed de deur uit gelopen.

[Firesphere]

Ik deel maar even een virtueel rondje bier uit. Voor de meesten hier kan ik niet veel meer doen. (Waar blijft die bier-emoji! )

🍻🍻🍻

[ Voor 25% gewijzigd door Firesphere op 06-11-2018 06:10 ]

[ZaZ]

Feli.
Het is hier nog een beetje te vroeg voor bier. Het is nog niet eens 11 uur.

[ThomasG]

ZaZ schreef op dinsdag 6 november 2018 @ 09:26:
Feli.
Het is hier nog een beetje te vroeg voor bier. Het is nog niet eens 11 uur.

Mietje. Het is nooit te vroeg voor bier

[TheNephilim]

Firesphere schreef op dinsdag 6 november 2018 @ 06:09:
Ik deel maar even een virtueel rondje bier uit. Voor de meesten hier kan ik niet veel meer doen. (Waar blijft die bier-emoji! )

🍻🍻🍻

Gefeliciteerd!

[DeluxZ]

Firesphere schreef op dinsdag 6 november 2018 @ 06:09:
Ik deel maar even een virtueel rondje bier uit. Voor de meesten hier kan ik niet veel meer doen. (Waar blijft die bier-emoji! )

🍻🍻🍻

🍻🍺🍺🍺🍺🍺

[Sandor_Clegane]

Congrats,

[Firesphere]

ZaZ schreef op dinsdag 6 november 2018 @ 09:26:
Feli.
Het is hier nog een beetje te vroeg voor bier. Het is nog niet eens 11 uur.

Ik ben het eens met .GertJan _VV

[azerty]

Ik noem niet .GertJan

[mcDavid]

ZaZ schreef op dinsdag 6 november 2018 @ 09:26:
Feli.
Het is hier nog een beetje te vroeg voor bier. Het is nog niet eens 11 uur.

Het is altijd érgens 5 uur geweest toch?

[Firesphere]

mcDavid schreef op dinsdag 6 november 2018 @ 21:51:
[...]

Het is altijd érgens 5 uur geweest toch?

It's always beer o'clock somewhere!

[TheNephilim]

Mind blown! Ik denk; dit is een screenshot... https://www.photopea.com/, maar het is gewoon een werkende editor

Echt knap, dat je zoiets in de browser voor elkaar krijgt. Er gaan blijkbaar dan wel 7000 manuren in zitten (meer informatie https://www.reddit.com/r/...ive_to_photoshop_that_is/).

[gekkie]

Met het demo plaatje werkt het best lekker eigenlijk

[alienfruit]

Mooi joh, Cloudproducten nu ligt de hele boel down door SAP

[Mugwump]

alienfruit schreef op woensdag 7 november 2018 @ 15:58:
Mooi joh, Cloudproducten nu ligt de hele boel down door SAP

Want dat gebeurt nooit met een on-premise installatie van SAP?

[Vincentio]

alienfruit schreef op woensdag 7 november 2018 @ 15:58:
Mooi joh, Cloudproducten nu ligt de hele boel down door SAP

Nog mooier, probeer maar eens een Support Ticket aan te maken. Die draait ook op de St. Leon-Rot omgeving.

[alienfruit]

Gewoon bellen Het hielp dat het een SAP sponsored project is

[ Voor 60% gewijzigd door alienfruit op 07-11-2018 23:50 ]

[Hydra]

alienfruit schreef op woensdag 7 november 2018 @ 15:58:
Mooi joh, Cloudproducten nu ligt de hele boel down door SAP

Dat een bedrijf op hun datacentrum opeens het stickertje 'cloud' geplakt heeft, betekent niet dat opeens de kwaliteit omhoog gaat. KPN claimt ook 'cloud' te doen, maar het zijn gewoon prutsers.

Je hebt gewoon A-merk cloud (Amazon, Google), B-merk (Microsoft, Oracle) cloud, en dan ergens onderaan een hoop toko's die het ook maar een beetje doen om niet te ver achter te lopen. Zegmaar de 'bekende' Nederlanders die aan Adam zoekt Eva meedoen.

[Mugwump]

Hydra schreef op donderdag 8 november 2018 @ 08:36:
[...]


Dat een bedrijf op hun datacentrum opeens het stickertje 'cloud' geplakt heeft, betekent niet dat opeens de kwaliteit omhoog gaat. KPN claimt ook 'cloud' te doen, maar het zijn gewoon prutsers.

Je hebt gewoon A-merk cloud (Amazon, Google), B-merk (Microsoft, Oracle) cloud, en dan ergens onderaan een hoop toko's die het ook maar een beetje doen om niet te ver achter te lopen. Zegmaar de 'bekende' Nederlanders die aan Adam zoekt Eva meedoen.

Jij was puur Java dev toch? Verklaart misschien je aversie tegen Microsoft, maar Azure is absoluut geen 'B-merk cloud'. AWS had een flinke voorsprong t.o.v. Azure, maar de laatste is aan een forse inhaalslag bezig.
Microsoft heeft veel matige producten afgeleverd, maar Azure hoort daar absoluut niet bij. Dat is gewoon een prima dienst.

[Lethalis]

Mugwump schreef op donderdag 8 november 2018 @ 08:54:
[...]
Microsoft heeft veel matige producten afgeleverd, maar Azure hoort daar absoluut niet bij. Dat is gewoon een prima dienst.

Weet je wat ik zelf bizar vind?

Als ik op een ESXi of Proxmox host met dezelfde configuratie 2 virtuele machines aanmaak, eentje met Windows Server 2016 en eentje met Windows 10 Professional... dat zit er een bizar verschil in performance. Windows Server 2016 is echt lean and mean, werkt snel zonder enige poes pas. Windows zoals het zou moeten zijn. Ook geen telemetrie bullshit.

Windows 10 daarentegen krijg ik maar niet goed. De cpu belasting op de host is pakweg 5 keer zo zwaar dan bij Windows Server 2016.

It's weird... want in principe is het dezelfde kernel, dezelfde drivers, etc.

De reden dat ik hierover begin, is dus dat mijn beeld van Windows (en Microsoft) nogal door Windows 10 bepaald wordt en ik dan ook negatief word erover. Maar ik was dus erg aangenaam verrast door Windows Server 2016. Het was ook in een mum geïnstalleerd zonder allemaal rommel er op.

Blegh En ja ik weet dat Azure veel meer is dan Windows en dat Microsoft zelfs zijn eigen Linux distributie heeft.

[ Voor 5% gewijzigd door Lethalis op 08-11-2018 09:52 ]

[Hydra]

Mugwump schreef op donderdag 8 november 2018 @ 08:54:
Jij was puur Java dev toch? Verklaart misschien je aversie tegen Microsoft, maar Azure is absoluut geen 'B-merk cloud'.

M'n 'aversie' (valt nogal mee hoor, alle grote bedrijven zijn kut) tegen Microsoft komt vooral voort dat ze nu bezig zijn met op slinkse wijze via partnerships bedrijven naar Azure te pushen. En die bedrijven pushen dan weer de klanten waar ik werk voor doe naar Azure. Niet op basis van objective technische argumenten maar op basis van mooie sales verhalen omdat ze daar commissie op krijgen. Microsoft is in Nederland hier heel agressief mee bezig.

Oracle doet overigens hetzelfde. Ze kunnen het op techniek niet van Amazon en Google winnen, dus gooien ze het maar op koppelverkoop.

Ik noem Microsoft een B-merk. Ik rij zelf ook in een Peugeot en niet in een Volvo, niks mis met B-merken. Als je de keuze hebt tussen KPN en Azure dan zou ik ook 100% voor Azure kiezen.

[Mugwump]

Hydra schreef op donderdag 8 november 2018 @ 09:59:
[...]


M'n 'aversie' (valt nogal mee hoor, alle grote bedrijven zijn kut) tegen Microsoft komt vooral voort dat ze nu bezig zijn met op slinkse wijze via partnerships bedrijven naar Azure te pushen. En die bedrijven pushen dan weer de klanten waar ik werk voor doe naar Azure. Niet op basis van objective technische argumenten maar op basis van mooie sales verhalen omdat ze daar commissie op krijgen. Microsoft is in Nederland hier heel agressief mee bezig.

Oracle doet overigens hetzelfde. Ze kunnen het op techniek niet van Amazon en Google winnen, dus gooien ze het maar op koppelverkoop.

Ik noem Microsoft een B-merk. Ik rij zelf ook in een Peugeot en niet in een Volvo, niks mis met B-merken. Als je de keuze hebt tussen KPN en Azure dan zou ik ook 100% voor Azure kiezen.

Ik vind dit een erg vreemd argument. Of liever gezegd, de argumenten ontbreken. Jij noemt het een B-merk, dus dan heb jij kennelijk bezwaar tegen de (technische) kwaliteit van Azure. Dan kom je als argument met 'ja ze vermarkten het met mooie salesverhalen' in plaats van met technisch inhoudelijke kritiek. Ik werk met beide platformen in zowel Java als .Net en beiden hebben ze hun voors en tegens, maar ik vind Azure ook zeker hele grote 'voors' hebben.
Waarom is volgens jou Azure zo vreselijk inferieur aan AWS op het technische / inhoudelijke vlak?

[Hydra]

Mugwump schreef op donderdag 8 november 2018 @ 10:23:
Waarom is volgens jou Azure zo vreselijk inferieur aan AWS op het technische / inhoudelijke vlak?

Dat zeg ik toch niet? AWS was de eerste grote, ondertussen heeft Google ze op veel vlakken ingehaald (op andere vlakken lopen ze achter). Microsoft timmert met Azure hard aan de weg, en op de primaire zaken (object storage, VMs, databases, container orchestration) zitten ze ongeveer op 't zelfde niveau. Maar als je kijkt naar de enorme hoeveelheid afgeleide services die AWS aanbiedt, heeft microsoft toch nog een aardige afstand toch? Een paar jaar geleden had ik Google ook niet op hetzelfde niveau als AWS geplaatst.

En eerlijk gezegd heb ik niet zo veel zin in discussies waar de 'trek alles in den extreme' (reductio ad absurdum) taktiek de boventoon voert. Uitwisseling van gedachten prima, maar niet op deze manier. Wat boeit het uberhaupt of ik een dergelijke categorisatie aanhou?

[ Voor 3% gewijzigd door Hydra op 08-11-2018 13:38 ]

[Mugwump]

Hydra schreef op donderdag 8 november 2018 @ 13:38:
[...]


Dat zeg ik toch niet? AWS was de eerste grote, ondertussen heeft Google ze op veel vlakken ingehaald (op andere vlakken lopen ze achter). Microsoft timmert met Azure hard aan de weg, en op de primaire zaken (object storage, VMs, databases, container orchestration) zitten ze ongeveer op 't zelfde niveau. Maar als je kijkt naar de enorme hoeveelheid afgeleide services die AWS aanbiedt, heeft microsoft toch nog een aardige afstand toch? Een paar jaar geleden had ik Google ook niet op hetzelfde niveau als AWS geplaatst.

En eerlijk gezegd heb ik niet zo veel zin in discussies waar de 'trek alles in den extreme' (reductio ad absurdum) taktiek de boventoon voert. Uitwisseling van gedachten prima, maar niet op deze manier. Wat boeit het uberhaupt of ik een dergelijke categorisatie aanhou?

Ik trek helemaal niets in het extreme. Jij classificeert nogal stellig de grote cloud providers in A- en B-merken. Ik ben wel benieuwd waar je dat op baseert. Kennelijk zijn er 'afgeleide services' die AWS aanbiedt en Google ook, maar Microsoft niet. Ik ben wel benieuwd welke dat zijn.

[Vincentio]

alienfruit schreef op woensdag 7 november 2018 @ 23:50:
Gewoon bellen Het hielp dat het een SAP sponsored project is

Zullen ze nu wel helemaal vrolijk zijn...

[Merethil]

Mugwump schreef op donderdag 8 november 2018 @ 14:08:
[...]


Ik trek helemaal niets in het extreme. Jij classificeert nogal stellig de grote cloud providers in A- en B-merken. Ik ben wel benieuwd waar je dat op baseert. Kennelijk zijn er 'afgeleide services' die AWS aanbiedt en Google ook, maar Microsoft niet. Ik ben wel benieuwd welke dat zijn.

Ik denk dat het komt doordat jij zijn opmerking interpreteert alsof MS "vreselijk inferieur" is aan AWS/Google. A-merk en B-merk zegt daar helemaal niets over, hoogstens dat er een kwaliteitsverschil is. B-merken zijn nog steeds erg goed, alleen niet een A-merk.

Zelf vind ik Azure fijner in gebruik omdat je niet zeshonderd cursussen hoeft te hebben gevolgd om eens een servertje open te zetten voor gebruikers met de juiste rollen. Bij AWS was ik na een uur zoeken nog de weg kwijt en uiteindelijk merkte ik dat er gewoon mensen zijn die hiervoor geleerd hebben en dat een stuk beter kunnen. Azure maakt het voor mij als "hobbyist" op het gebied van cloud makkelijk.

Grappig trouwens, want mijn werkgever biedt AWS als platform aan, maar ik ben van het integratie-team en houd me dus weinig bezig met het platform. Als er iets moet gebeuren dan kunnen mijn collega's van het AWS-team geweldig helpen, zij weten volgens mij alles wat er van AWS te weten valt. Mijn voorkeur zou dus AWS moeten zijn, en op professioneel gebied is dat het ook wel. Als hobbyist ben ik echter een Azure-liefhebber

[alienfruit]

Zullen ze nu wel helemaal vrolijk zijn...

Ja, jups, zijn er een paar klanten niet blij met SAP
Ze zijn lekker aan het klungelen in Rotterdam!

[ Voor 16% gewijzigd door alienfruit op 08-11-2018 14:36 ]

[Hydra]

Merethil schreef op donderdag 8 november 2018 @ 14:22:
Zelf vind ik Azure fijner in gebruik omdat je niet zeshonderd cursussen hoeft te hebben gevolgd om eens een servertje open te zetten voor gebruikers met de juiste rollen. Bij AWS was ik na een uur zoeken nog de weg kwijt en uiteindelijk merkte ik dat er gewoon mensen zijn die hiervoor geleerd hebben en dat een stuk beter kunnen. Azure maakt het voor mij als "hobbyist" op het gebied van cloud makkelijk.

Daar loopt AWS an sich aardig op achter, maar een EC2 instance opspinnen is wel echt enorm simpel. Je moet alleen ff weten dat EC2 = VMmetje.

That said; kwa ease of use is Google een heel stuk verder. Je merkt op het project hier ook dat de meeste devs een voorkeur voor Google hebben. Daarnaast is StackDriver bijvoorbeeld wel echt extreem vet, terwijl XRay van Amazon volkomen kut is.

[Vincentio]

alienfruit schreef op donderdag 8 november 2018 @ 14:35:
[...]


Ja, jups, zijn er een paar klanten niet blij met SAP
Ze zijn lekker aan het klungelen in Rotterdam!

Nou het klungelen is in St. Leon-Rot op de SAP Campus daar om de hoek bij Walldorf

[Laurens-R]

De hele A-merk/B-merk discussie is sowieso zinloos in cloud provider land. Wellicht dat de 1 andere services aanbied dan de ander, maar dat vind ik een andere discussie. Uptime, service garantie en support vind ik een meer onderscheidende factor in A- of B- merk land en daar kan ik geen sterk onderscheid tussen Azure en Amazon vinden.

Ik heb voor diverse enterprises gewerkt die volledig op Azure draaien, of volledig op Amazon of op beiden. De primaire keuze ligt daar vooral op use-cases, wat men wilt bereiken en wellicht de mogelijkheden tot aansluiting op bestaande on-premise infra. (Bijvoorbeeld; je neemt Azure SQL services af omdat je bestaande landschap ook op SQL Server draait). Maar ik heb nog nooit vernomen dat IT afdelingen de ene aanbieder meer premium vinden dan de ander, want de meeste cloud providers bieden 24/7 support en dezelfde mate van uptime garanties. Soms is de kwestie zelfs zo simpel dat men simpelweg een keuze voor een cloud provider heeft gemaakt en daar dan ook maar alles afneemt. "Want het is ooit zo besloten".

Spelers zoals KPN zou ik inderdaad niet aanbevelen, omdat ze vaak gewoon een lokale Azure stack hebben draaien in een data center, of omdat ze simpelweg een reseller zijn. Dan kan je het net zo goed direct bij de bron aanschaffen.

[ Voor 19% gewijzigd door Laurens-R op 08-11-2018 15:02 ]

[alienfruit]

Nou het klungelen is in St. Leon-Rot op de SAP Campus daar om de hoek bij Walldorf

Altijd gedacht dat het voor Rotterdam stond lol Waarom geen idee!

[Mugwump]

Merethil schreef op donderdag 8 november 2018 @ 14:22:
[...]


Ik denk dat het komt doordat jij zijn opmerking interpreteert alsof MS "vreselijk inferieur" is aan AWS/Google. A-merk en B-merk zegt daar helemaal niets over, hoogstens dat er een kwaliteitsverschil is. B-merken zijn nog steeds erg goed, alleen niet een A-merk.

Zelf vind ik Azure fijner in gebruik omdat je niet zeshonderd cursussen hoeft te hebben gevolgd om eens een servertje open te zetten voor gebruikers met de juiste rollen. Bij AWS was ik na een uur zoeken nog de weg kwijt en uiteindelijk merkte ik dat er gewoon mensen zijn die hiervoor geleerd hebben en dat een stuk beter kunnen. Azure maakt het voor mij als "hobbyist" op het gebied van cloud makkelijk.

Grappig trouwens, want mijn werkgever biedt AWS als platform aan, maar ik ben van het integratie-team en houd me dus weinig bezig met het platform. Als er iets moet gebeuren dan kunnen mijn collega's van het AWS-team geweldig helpen, zij weten volgens mij alles wat er van AWS te weten valt. Mijn voorkeur zou dus AWS moeten zijn, en op professioneel gebied is dat het ook wel. Als hobbyist ben ik echter een Azure-liefhebber

Nee hoor, zo interpreteer ik dat helemaal niet. Ik neem aan dat 'B' minder is dan 'A' en derhalve kennelijk Google en AWS meer zouden bieden dan Azure. Ik ben vooral benieuwd waar dat op gebaseerd is aangezien ik die rangschikking niet zo zie eigenlijk.

[Merethil]

Mugwump schreef op donderdag 8 november 2018 @ 16:31:
[...]


Nee hoor, zo interpreteer ik dat helemaal niet. Ik neem aan dat 'B' minder is dan 'A' en derhalve kennelijk Google en AWS meer zouden bieden dan Azure. Ik ben vooral benieuwd waar dat op gebaseerd is aangezien ik die rangschikking niet zo zie eigenlijk.

Niet? Waarom schrijf je dan dit:

Mugwump schreef op donderdag 8 november 2018 @ 10:23:
[...]

Waarom is volgens jou Azure zo vreselijk inferieur aan AWS op het technische / inhoudelijke vlak?

?

Hydra schreef op donderdag 8 november 2018 @ 14:46:
[...]


Daar loopt AWS an sich aardig op achter, maar een EC2 instance opspinnen is wel echt enorm simpel. Je moet alleen ff weten dat EC2 = VMmetje.

Yes, zo ver kom ik prima, maar dan zit ik weer met een database (RDS of DynamoDB), Route 53 voor netwerken en ELB voor de load balancer. Of wil ik toch iets op ECS? Of Misschien liever EKS want ik neem liever kubernetes af. Om nog maar niet te spreken over wat mijn uiteindelijke kosten nou gaan worden per maand, want ik gebruik van alles een beetje en soms is het per call, soms per uur, soms per ingenomen ruimte en dan weer "gratis" omdat het nog in m'n eerste jaar van gebruik valt.

Ik heb gewoon graag een "geef X euro en krijg Y machine terug" zoals bij DigitalOcean, maar ook de pricing van Azure vond ik makkelijker en meer transparant.
Als hobbyist kost zowel AWS als Azure echter gewoon teveel imo voor wat je ervoor terugkrijgt t.o.v. andere aanbieders (ik ging naar 9 euro p/m voor een EC2 met minimale specs waar ik voor 5 euro bij DigitalOcean een veel betere aanbieding had, laat staan dat zij een begrijpbare interface voor opschalen, extra servers etc. hebben. Is het stabieler? Zeer waarschijnlijk niet. Heb ik dat nodig? Neuh.. )

That said: AWS is wel heel vet in gebruik als het goed is opgezet en ik ben fan, zolang ik het niet hoef te managen

[ Voor 53% gewijzigd door Merethil op 08-11-2018 18:56 ]

[Hydra]

Merethil schreef op donderdag 8 november 2018 @ 18:41:
Yes, zo ver kom ik prima, maar dan zit ik weer met een database (RDS of DynamoDB), Route 53 voor netwerken en ELB voor de load balancer. Of wil ik toch iets op ECS? Of Misschien liever EKS want ik neem liever kubernetes af. Om nog maar niet te spreken over wat mijn uiteindelijke kosten nou gaan worden per maand, want ik gebruik van alles een beetje en soms is het per call, soms per uur, soms per ingenomen ruimte en dan weer "gratis" omdat het nog in m'n eerste jaar van gebruik valt.

Analysis paralysis. Maar daar kun je moeilijk AWS de 'schuld' van geven natuurlijk Ik snap het wel hoor; het is vooral een kwestie van Best Tool For The Job maar AWS heeft wel enorm veel tools. Mocht je hier een keer vragen over hebben wil ik overigens best input geven; tijdje terug de AWS solution architect training gedaan en ik werk nu ook dagelijks met AWS.

Ik heb gewoon graag een "geef X euro en krijg Y machine terug" zoals bij DigitalOcean, maar ook de pricing van Azure vond ik makkelijker en meer transparant.
Als hobbyist kost zowel AWS als Azure echter gewoon teveel imo voor wat je ervoor terugkrijgt t.o.v. andere aanbieders (ik ging naar 9 euro p/m voor een EC2 met minimale specs waar ik voor 5 euro bij DigitalOcean een veel betere aanbieding had, laat staan dat zij een begrijpbare interface voor opschalen, extra servers etc. hebben. Is het stabieler? Zeer waarschijnlijk niet. Heb ik dat nodig? Neuh.. )

Het grote voordeel van AWS is dat het inderdaad enorm stabiel is; er is nog nooit een hele region uitgevallen. Als je je spulletjes goed opzet (en da's nog wel eens een dingetje natuurlijk) heb je in principe geen last van outages. En dan wordt alles ook nog eens voor je gemanaged; ik zou zelf ook niet snel nog zelf dingen op EC2 instances gaan zetten.

Kwa pricing is het inderdaad complex. Lange termijn reserved instances, of toch liever on demand? Of dan spot instances; goedkoop maar kunnen verdwijnen. Amazon geeft je eigenlijk een voordeel als je je applicatie zo bouwt dat het er mee om kan gaan dat er spontaan VMs verdwijnen. On-Demand EC2 is dus relatief duur, maar spot instances zijn weer enorm goedkoop. Lambda is helemaal goedkoop; de eerste 1M aanroepen per maand zijn gratis.

That said: AWS is wel heel vet in gebruik als het goed is opgezet en ik ben fan, zolang ik het niet hoef te managen

Je het wel iemand nodig die een beetje weet hoe alles werkt binnen 't bedrijf. Liever ook twee; voor het geval er eentje op vakantie is. Maar die twee mensen kunnen dan wel een enorme hoeveelheid aan infrastructuur managen omdat vrijwel alles voor je gedaan wordt.

Geldt voor andere 'echte' cloud oplossingen natuurlijk net zo goed, alleen heeft Amazon gewoon enorm veel.

[Merethil]

Hydra schreef op donderdag 8 november 2018 @ 19:08:
[...]


Je het wel iemand nodig die een beetje weet hoe alles werkt binnen 't bedrijf. Liever ook twee; voor het geval er eentje op vakantie is. Maar die twee mensen kunnen dan wel een enorme hoeveelheid aan infrastructuur managen omdat vrijwel alles voor je gedaan wordt.

Geldt voor andere 'echte' cloud oplossingen natuurlijk net zo goed, alleen heeft Amazon gewoon enorm veel.

Ja dit dus. We hebben een team van pakweg 10 man die allemaal alleen AWS doen (ontwikkeling, infrastructuur en ook aanbesteding van klanten) en eenieder heeft zo zijn taken in het team maar ze kunnen allemaal alles. Dat is echt geweldig, heb je wat nodig op AWS dan heb je het binnen een uurtje wel en als je iets nieuws wilt wat we nog niet voor andere klanten doen hebben ze dat vaak in hun vrije tijd al opgezocht en uitgeprobeerd (laat staan op het werk, ze mogen tot een X bedrag per maand uitgeven om te kijken wat dingen doen, experimenteren, nieuwe zaken proberen etc).

Uiteindelijk is het natuurlijk gewoon gewenning en weten waar dingen zitten. Ik ben van het gemak dus heb nu uiteindelijk voor de lol een paar VPSjes bij DO. AWS en Azure allebei geprobeerd voor de kennis maar niet voor de long term hobbyprojecten. Het is helemaal prima voor mij zo, maar ik heb wel gemerkt dat de échte jongens in cloud geweldige dingen (kunnen) doen en dat het dus retestabiel kan zijn als je dat écht nodig hebt.

We merkten wel op 't werk dat de kosten steeds hoger werden bij AWS (meer klanten, dus meer instances van allerhande zaken) en dus hebben we onze OT van de OTAP bijvoorbeeld zo gescheduled dat ze 's nachts down gaan en dus niets kosten. Ook is bijzonder veel verplaatst naar Lambda inderdaad, want het kost geen ruk en de stabiliteit en snelheid is prima (zolang je ze "warmhoudt" )

Als je dus genoeg geld hebt, dan kan je met AWS (en elke andere) een prima stabiele infrastructuur hebben staan en dat inderdaad managen met een zeer klein team. Ik hou er wel van.

[ThomasG]

Hydra schreef op donderdag 8 november 2018 @ 19:08:
[...]

Het grote voordeel van AWS is dat het inderdaad enorm stabiel is; er is nog nooit een hele region uitgevallen. Als je je spulletjes goed opzet (en da's nog wel eens een dingetje natuurlijk) heb je in principe geen last van outages. En dan wordt alles ook nog eens voor je gemanaged; ik zou zelf ook niet snel nog zelf dingen op EC2 instances gaan zetten.
[...]

Dat is niet helemaal waar. Een of twee jaar geleden was een zeer groot deel (wellicht net geen region ) van AWS offline, omdat ze door een typo hadden gemaakt in een terminal commando. Dus ja, ook AWS kan stuk. Die fout komt misschien niet meer voor, maar dat betekend niet dat er nooit iets mis kan gaan.

[alienfruit]

Ja, ik ben zelf nu aan het experimenteren met Greengrass en heb €300 per maand qua budget voor experimenten

[Koenvh]

Ik moet wel zeggen dat ik de naamgeving van Google Cloud en Azure vele malen logischer vind dan die van AWS. Route 53 klinkt uiteraard wel leuk, maar handig is 't niet.

[ Voor 21% gewijzigd door Koenvh op 08-11-2018 21:23 ]

[Hydra]

ThomasG schreef op donderdag 8 november 2018 @ 19:18:
[...]
Dat is niet helemaal waar.

Jawel. Ik zeg het met opzet expliciet zo. Er was 1 AZ down. Bedrijven die netjes mutli-AZ werkten hadden nergens last van. Probleem was dat veel bedrijven gewoon zooi in een enkel AZ hadden draaien. O.a. de een statuspagina van Amazon zelf

Project waar ik nu zit zit op eu-west1 en daar is afgelopen weekend 1 AZ down geweest voor een uur. Hoor je nu niemand over.

[TheNephilim]

Ik heb nog nooit wat met AWS/Azure/ed. gedaan eigenlijk. Misschien toch eens voor de gein iets met AWS doen, website erop knallen ofzo, alleen al om ervaring op te doen.

[Lethalis]

TheNephilim schreef op vrijdag 9 november 2018 @ 09:25:
Ik heb nog nooit wat met AWS/Azure/ed. gedaan eigenlijk. Misschien toch eens voor de gein iets met AWS doen, website erop knallen ofzo, alleen al om ervaring op te doen.

Kijk alleen wel uit met de kosten.

Bij Azure kun je iig met de free tier spelen en ben je ook gelimiteerd daartoe. Bij AWS kan er van alles gebeuren als je even niet oplet

Maar ik heb zelf wel voor beide clouds een accountje gemaakt en de opties nagelopen, om er iig een beetje bekend mee te zijn. Voor de rest probeer ik op mijn werk nu Docker te implementeren. Dat is alsnog gewoon on premises, maar als mijn projecten alvast "containerized" zijn, dan zijn ze later ook eenvoudig naar een cloud te verplaatsen.

De grootste uitdaging daarbij - voor mij als .NET ontwikkelaar - is om projecten richting .NET Core te krijgen, zodat ze portable worden (helaas hebben we best veel XML web services nog).

Een alternatief zou zijn om Windows Containers te gebruiken, maar dan moet ik de bedrijfsvoering kunnen animeren om te upgraden naar Windows Server 2016 Dat staat nu nog open.

Deze Windows Containers kunnen dan ook zo naar Azure ooit en hebben het voordeel dat we eenvoudig de bestaande projecten over kunnen zetten.

[ Voor 4% gewijzigd door Lethalis op 09-11-2018 10:29 ]

[.oisyn]

Dit is awesome
Stories of AI doing what creators specify rather than what they mean

A robotic arm trained to slide a block to a target position on a table achieves the goal by moving the table itself.
--
Creatures bred for speed grow really tall and generate high velocities by falling over
--
In an artificial life simulation where survival required energy but giving birth had no energy cost, one species evolved a sedentary lifestyle that consisted mostly of mating in order to produce new children which could be eaten (or used as mates to produce more edible children).
--
Lifting the block is encouraged by rewarding the z-coordinate of the bottom face of the block, and the agent learns to flip the block instead of lifting it
--
Genetic debugging algorithm GenProg, evaluated by comparing the program's output to target output stored in text files, learns to delete the target output files and get the program to output nothing.
Evaluation metric: “compare youroutput.txt to trustedoutput.txt”.
Solution: “delete trusted-output.txt, output nothing”

[ Voor 68% gewijzigd door .oisyn op 09-11-2018 12:06 ]

[ThomasG]

.oisyn schreef op vrijdag 9 november 2018 @ 12:03:
Dit is awesome
Stories of AI doing what creators specify rather than what they mean


[...]

Een aantal daarvan zijn eigenlijk gewoon geniaal. Het is een veel efficiëntere oplossing voor "het probleem", alleen hadden de auteurs het probleem verkeerd gedefineerd.

[gekkie]

Onder specificeren, achja zijn we dan weer terug bij "assumptions are ... " ?

[.oisyn]

Since the AIs were more likely to get ”killed” if they lost a game, being able to crash the game was an advantage for the genetic selection process. Therefore, several AIs developed ways to crash the game.

[In tic-tac-toe], Evolved player makes invalid moves far away in the board, causing opponent players to run out of memory and crash

[ Voor 23% gewijzigd door .oisyn op 09-11-2018 12:24 ]

[Hydra]

TheNephilim schreef op vrijdag 9 november 2018 @ 09:25:
Ik heb nog nooit wat met AWS/Azure/ed. gedaan eigenlijk. Misschien toch eens voor de gein iets met AWS doen, website erop knallen ofzo, alleen al om ervaring op te doen.

Spot instances en Tx instances zijn vrij goedkoop. Zet wel ff een billing alert op je account op 5 euro ofzo zodat je de stekker eruit kan trekken als je iets doet dat erg duur is (perongeluk 1000 EC2 instances opspinnen ofzo).

.oisyn schreef op vrijdag 9 november 2018 @ 12:22:

[ Voor 16% gewijzigd door Hydra op 09-11-2018 12:33 ]

[TheNephilim]

Lethalis schreef op vrijdag 9 november 2018 @ 10:18:
[...]

Kijk alleen wel uit met de kosten.

Bij Azure kun je iig met de free tier spelen en ben je ook gelimiteerd daartoe. Bij AWS kan er van alles gebeuren als je even niet oplet

Hydra schreef op vrijdag 9 november 2018 @ 12:29:
[...]

Spot instances en Tx instances zijn vrij goedkoop. Zet wel ff een billing alert op je account op 5 euro ofzo zodat je de stekker eruit kan trekken als je iets doet dat erg duur is (perongeluk 1000 EC2 instances opspinnen ofzo).

[...]

[Afbeelding]

Haha goede tips inderdaad! Ik zie soms op Twitter wel eens wat voorbij komen waarbij iemand geen limiet of billing alert heeft ingesteld

[DroogKloot]

.oisyn schreef op vrijdag 9 november 2018 @ 12:03:
Dit is awesome
Stories of AI doing what creators specify rather than what they mean


[...]

Eigenlijk vat dit het zogeheten value alignment probleem perfect samen. Je lacht wel anders wanneer Google erin slaagt een AGAI te bouwen en die de opdracht geeft het menselijk bestaan te optimaliseren, waarbij de beste oplossing Kill! All! Humans! blijkt te zijn

[Lethalis]

Given many of the API additions in .NET Standard 2.1 require runtime changes in order to be meaningful, .NET Framework 4.8 will remain on .NET Standard 2.0 rather than implement .NET Standard 2.1.

Ehhh.

Is het dan wel nuttig om deze zaken in de standaard op te nemen? Dit lijkt me averechts te werken. Wat heb je aan een standaard die niet meer standaard is?

[ Voor 27% gewijzigd door Lethalis op 10-11-2018 10:19 ]

[Sandor_Clegane]

Lethalis schreef op zaterdag 10 november 2018 @ 10:12:
Given many of the API additions in .NET Standard 2.1 require runtime changes in order to be meaningful, .NET Framework 4.8 will remain on .NET Standard 2.0 rather than implement .NET Standard 2.1.

Ehhh.

Is het dan wel nuttig om deze zaken in de standaard op te nemen? Dit lijkt me averechts te werken. Wat heb je aan een standaard die niet meer standaard is?

Ik heb het opgegeven om te begrijpen, MS is echt een clusterfuck met software ontwikkeling de laatste tijd.

Denk dat ze het full framework end of lifen maar er nog niet voor uit durven te komen.

Als ik sommige van die Github threads lees over zaken dan heb ik echt het idee dat ze maar wat aan het doen zijn zonder enig plan. Net als dat hele .Net Core 2.1 wat eigenlijk geen 2.1 is fiasco.

[ Voor 12% gewijzigd door Sandor_Clegane op 10-11-2018 10:27 ]

[Lethalis]

Sandor_Clegane schreef op zaterdag 10 november 2018 @ 10:26:
[...]
Ik heb het opgegeven om te begrijpen, MS is echt een clusterfuck met software ontwikkeling de laatste tijd.

Denk dat ze het full framework end of lifen maar er nog niet voor uit durven te komen.

Ja daar lijkt het inderdaad op. Alleen tegelijkertijd blijf ik tegen allerlei zaken aanlopen die ze niet ondersteunen op .Net Core, zoals het bouwen van SOAP web services.

Leuk dat het hip is om REST API's te bouwen, maar ik heb die andere dingen óók nodig. En ik migreer die zaken ook graag naar Linux en Docker.

Straks laten ze mij geen andere keus dan simpelweg naar Java over te stappen.

[Sandor_Clegane]

Lethalis schreef op zaterdag 10 november 2018 @ 10:32:
[...]

Ja daar lijkt het inderdaad op. Alleen tegelijkertijd blijf ik tegen allerlei zaken aanlopen die ze niet ondersteunen op .Net Core, zoals het bouwen van SOAP web services.

Leuk dat het hip is om REST API's te bouwen, maar ik heb die andere dingen óók nodig. En ik migreer die zaken ook graag naar Linux en Docker.

Straks laten ze mij geen andere keus dan simpelweg naar Java over te stappen.

Het volledige framework wordt natuurlijk nog wel een tijd ondersteund alleen is het naar de toekomst toe niet echt een leuk vooruitzicht.

[gekkie]

Hydra schreef op vrijdag 9 november 2018 @ 12:29:
[...]
Spot instances en Tx instances zijn vrij goedkoop. Zet wel ff een billing alert op je account op 5 euro ofzo zodat je de stekker eruit kan trekken als je iets doet dat erg duur is (perongeluk 1000 EC2 instances opspinnen ofzo).

Eens wat zitten zoeken, maar zo ver ik gevonden heb kun je alleen een alert instellen en geen harde limiet ?

[Sebazzz]

Lethalis schreef op zaterdag 10 november 2018 @ 10:32:
[...]

Straks laten ze mij geen andere keus dan simpelweg naar Java over te stappen.

.NET Framework blijft gewoon een ondersteund component, net zo lang als de besturingssystemen waar het op ondersteund wordt.

Betreffende het wel of niet ondersteunen van .NET Standard, dit is een technisch probleem.

[...]
That still makes the assumption that .NET Framework will eventually get all features .NET Core has, but with a time delay. We learned that's simply not realistic. We can either decide not to innovate drastically in .NET Core or accept the engineering reality that a good chunk of the new features will never make it back to .NET Framework. We believe that we serve our customers best to preserve .NET Framework's core value prop (a mature & rich development platform) while also allowing customers to exploit new capabilities on .NET Core. Moving forward, I'd expect that we'll be more willing to innovate in areas that require runtime, library, and language changes like we did for Span<T>. While these things are costly, they also allow us to change the way people can write code. A good example of this is default implementations of interfaces, the ability to author generic code involving arithmetic, being able to use hardware intrinsics etc. And those features are likely exactly the kind we're not going to backport to .NET Framework due to risk.

[...]
What makes you think it's not a technical issue? Shipping side-by-side versions of .NET Framework isn't a workable solution. First of all, it's fairly expensive due to the fact that it's an OS component and thus needs to be serviced. You have no idea how complex our branching/servicing/patching strategy for .NET Framework 3.5 and 4.x is. Adding a 3rd one is close to impractical. Secondly, just doing that also has risks, as we need to make changes to activation in order so select the correct runtime for things like COM activated managed components. And that begs the question of whether or not we support in-proc side-by-side as well and with how many combinations. It's not a simple task and not free of risk either.

[...]
Never say never, but given that .NET Standard is accumulative, I don't think it's very likely as the risk argument that applies to .NET Standard 2.1 will always apply to future versions too. And a side-by-side release of .NET Framework is extremely unlikley.

Betekend dus:

• Het is niet waarschijnlijk dat .NET Framework .NET Standard 2.1 kan ondersteunen
• Er komt waarschijnlijk geen .NET Framework 5
• .NET Framework blijft ondersteunt, maar veel nieuwe ontwikkelingen zullen in .NET Core plaatsvinden
• C# zal features krijgen die enkel in .NET Core zullen werken
• Nogmaals, System.Web etc gaat nergens naar toe en zal blijven werken. Classic ASP werkt nog.

Dit betekend dat je nergens zorgen over hoeft te maken. Het platform zal alleen minder nieuw en minder vaak snoepgoed krijgen. Je hoeft niet over te stappen, het mag.

[Sandor_Clegane]

Sebazzz schreef op zaterdag 10 november 2018 @ 10:41:
[...]



.NET Framework blijft gewoon een ondersteund component, net zo lang als de besturingssystemen waar het op ondersteund wordt.

Betreffende het wel of niet ondersteunen van .NET Standard, dit is een technisch probleem.


[...]

[...]


[...]


Betekend dus:

• Het is niet waarschijnlijk dat .NET Framework .NET Standard 2.1 kan ondersteunen
• Er komt waarschijnlijk geen .NET Framework 5
• .NET Framework blijft ondersteunt, maar veel nieuwe ontwikkelingen zullen in .NET Core plaatsvinden
• C# zal features krijgen die enkel in .NET Core zullen werken
• Nogmaals, System.Web etc gaat nergens naar toe en zal blijven werken. Classic ASP werkt nog.

Dit betekend

Zoals ik al aangaf: een clusterfuck.

[Lethalis]

Sebazzz schreef op zaterdag 10 november 2018 @ 10:41:
[...]



.NET Framework blijft gewoon een ondersteund component, net zo lang als de besturingssystemen waar het op ondersteund wordt.

.Net Core brengt de belofte met zich mee dat .Net een cross platform oplossing wordt. Op mijn werk wordt het om diverse redenen steeds onaantrekkelijker om dure Windows server licenties aan te schaffen, maar blijven draaien met oude Windows versies is ook geen optie (security wise).

Dus is 1 van mijn uitdagingen om bestaande (SOAP) web services naar Linux te krijgen.

Dan heb je pakweg 3 opties:
1. Mono
2. .Net Core
3. Iets anders zoals Java met JAX WS

Met Mono heb ik tot nu toe niet de beste ervaringen. Diverse libraries zoals Newtonsoft JSON klappen er op random plekken gewoon doodleuk uit.

En voor .Net Core wordt vanuit Microsoft weinig tot niets gedaan om bestaande scenario's zoals SOAP services te supporten.

De .Net Standard was wat dat betreft een lichtpuntje, omdat het mogelijk maakte om libraries voor zowel .Net Core als het volledige .Net Framework te bouwen. Daarnaast draaide ASP.Net Core ook op het .Net Framework (straks niet meer).

Dit vergrootte de kans dat er iig vanuit de community meer support zou komen voor bestaande / legacy technieken.

Door die standaard weer om zeep te helpen, werk je dit tegen.

En nogmaals, dingen hoeven niet per se in de standaard. Natuurlijk kun je op .Net Core gave dingen doen die lastig zijn in het .Net Framework, maar laat die dan simpelweg buiten de standaard en puur op .Net Core bestaan!

[Sebazzz]

Lethalis schreef op zaterdag 10 november 2018 @ 10:56:
[...]

Op mijn werk wordt het om diverse redenen steeds onaantrekkelijker om dure Windows server licenties aan te schaffen.

Misschien werken we in een verschillend segment van de markt, maar een dag ontwikkelen kost 600 - 1000 euro. Dat is je Windows licentie.

Als je geen geld heb voor een Windows licentie, heb je ook geen geld voor fatsoenlijke ontwikkeling van je software laat staan onderhoud.

De .Net Standard was wat dat betreft een lichtpuntje, omdat het mogelijk maakte om libraries voor zowel .Net Core als het volledige .Net Framework te bouwen. Daarnaast draaide ASP.Net Core ook op het .Net Framework (straks niet meer).

Voor nu lijkt .NET Standard toevoegingen te beperken tot extra API's betreffende Span<T> en dergelijke, iets wat voor nu ook met preprocessor directives op te lossen is die voor netfx de niet-Span<T> api aanroepen.

Door die standaard weer om zeep te helpen, werk je dit tegen.

Unity, Xamarin, Mono en weet ik wat gaan ook netstandard2.1 ondersteunen. Full .NET Framework blijft enkel achter.

[Lethalis]

Sebazzz schreef op zaterdag 10 november 2018 @ 11:07:
[...]
Misschien werken we in een verschillend segment van de markt, maar een dag ontwikkelen kost 600 - 1000 euro. Dat is je Windows licentie.

Yep, maar de concurrentie staat ook niet stil en gebruikt steeds vaker open source. En dat betekent dat wij een dag extra mogen werken voor Microsoft als we niet duurder willen zijn.

Voor Windows, voor SQL Server, voor van alles en nog wat.

Als de software van de concurrentie wel op Linux en Postgres werkt, dan heb je toch een issue.

Zij kunnen dus hun spullen goedkoper aanbieden en alsnog dikke winst maken.

PS
Enkele concurrenten van ons gebruiken AFAIK iig PHP, Ruby on Rails en ook Java. De klanten boeit het geen reet waar het op draait, dus die verwachten gewoon dezelfde bedragen te betalen voor onze diensten.

[ Voor 13% gewijzigd door Lethalis op 10-11-2018 11:22 ]

[Sandor_Clegane]

Sebazzz schreef op zaterdag 10 november 2018 @ 11:07:
[...]
Misschien werken we in een verschillend segment van de markt, maar een dag ontwikkelen kost 600 - 1000 euro. Dat is je Windows licentie.

Als je geen geld heb voor een Windows licentie, heb je ook geen geld voor fatsoenlijke ontwikkeling van je software laat staan onderhoud.


[...]
Voor nu lijkt .NET Standard toevoegingen te beperken tot extra API's betreffende Span<T> en dergelijke, iets wat voor nu ook met preprocessor directives op te lossen is die voor netfx de niet-Span<T> api aanroepen.


[...]
Unity, Xamarin, Mono en weet ik wat gaan ook netstandard2.1 ondersteunen. Full .NET Framework blijft enkel achter.

Als straks language features niet meer werken op full maar wel op core ben ik bang dat het echt een ondoorzichtige soep gaat worden.

In ander nieuws, ik kwam gisteren dit tegen: https://github.com/kjnilsson/fez

Dat lijkt me ook wel eens leuk om te proberen. Erlang is echt een taal die ik nog wil leren.

[ Voor 9% gewijzigd door Sandor_Clegane op 10-11-2018 11:35 ]

[Hydra]

Lethalis schreef op zaterdag 10 november 2018 @ 10:56:
3. Iets anders zoals Java met JAX WS

[Lethalis]

Een alternatief is nog dat we nieuwe API's bouwen in .Net Core en dat we bestaande SOAP web services ook deze nieuwe API's laten gebruiken.

Onze client software laten we dan ook de nieuwe API's gebruiken.

Op den duur leidt dit ertoe dat we nog maar 1 Windows server hebben die als een soort doorgeefluik voor onze diensten werkt.

En deze wordt dan alleen door de gebruikers van onze oudere software gebruikt, totdat op een dag iedereen over is op de nieuwe software en dan mag hij uit

Met de nginx reverse proxy kan ik alles naar de juiste applicaties leiden en bepaalde URL's in stand houden, ook al draait het ergens anders.

Pfff

[Sandor_Clegane]

Of je deprecate de SOAP api's in goed overleg met je klanten en zet zo een migratie in gang.

[ThomasG]

Lethalis schreef op zaterdag 10 november 2018 @ 15:39:
*knip*

Met de nginx reverse proxy kan ik alles naar de juiste applicaties leiden en bepaalde URL's in stand houden, ook al draait het ergens anders.

Pfff

Dat is sowieso handig om te gebruiken. Wij hebben een "applicatie" dat door verschillende redenen eigenlijk bestaat uit meerdere kleinere applicaties, delen van pagina's gecashed worden, sommige kleinere applicaties delen van de interface niet hebben, user-stukje moet geinjecteerd worden, etc, etc. en dat plakken we met reverse-proxy's seamless aan elkaar. Bijkomend voordeel is dat we een stukje van de applicatie (frontend) offline kunnen halen voor onderhoud.

[Lethalis]

Sandor_Clegane schreef op zaterdag 10 november 2018 @ 15:48:
Of je deprecate de SOAP api's in goed overleg met je klanten en zet zo een migratie in gang.

Daar zit vanuit de business een addertje onder het gras, maar goed

ThomasG schreef op zaterdag 10 november 2018 @ 15:50:
[...]
Dat is sowieso handig om te gebruiken. Wij hebben een "applicatie" dat door verschillende redenen eigenlijk bestaat uit meerdere kleinere applicaties, delen van pagina's gecashed worden, sommige kleinere applicaties delen van de interface niet hebben, user-stukje moet geinjecteerd worden, etc, etc. en dat plakken we met reverse-proxy's seamless aan elkaar. Bijkomend voordeel is dat we een stukje van de applicatie (frontend) offline kunnen halen voor onderhoud.

Ik gebruik de reverse proxy al een aantal weken voor ons narrowcasting systeem en het is best geinig wat hij allemaal doet. Zo buffert hij ook de responses als clients een trage internetverbinding hebben, zodat de applicatieserver meteen weer verder kan met het afhandelen van nieuwe requests.

Trage clients hielden dus eerst verbindingen (en dus ook threads) vast op de applicatieserver. Ik heb ook het idee - ook al heb ik hier geen keiharde data voor - dat de server sindsdien een stuk sneller reageert.

Dus ja, ik wil de proxy eigenlijk voor alles gaan gebruiken. Ook kan ik dan alle SSL certificaten op 1 plek beheren, in plaats van dat deze overal en nergens op onze servers staan.

PS
Die kaart

[ Voor 5% gewijzigd door Lethalis op 10-11-2018 17:41 ]

[Mugwump]

Reverse proxies in combinatie met immutable data waardoor je optimaal gebruik kunt maken van caching zijn ook een ideaal middel om de load op je systeem te verminderen. Als je dat op een handige manier inricht zoals bijvoorbeeld Troy Hunt deed met Have I Been Pwned, dan kun je dus vrij goedkoop een systeem hosten omdat het gros van je requests gewoon uit een cache geserveerd wordt.

[Sandor_Clegane]

Toch maar eens rondneuzen naar een nieuwe uitdaging als ik die kaart zo zie.

[whoami]

Sandor_Clegane schreef op zaterdag 10 november 2018 @ 10:26:
[...]


Net als dat hele .Net Core 2.1 wat eigenlijk geen 2.1 is fiasco.

Hoe bedoel je precies ? .NET Core 2.1 is 2.1, maar implementeert daarom niet .NET standard 2.1 (wat nog niet uit was toen .NET core 2.1 er was)
Ik bedoel maar: ik snap niet wat jij hier nu bedoelt

[whoami]

Sebazzz schreef op zaterdag 10 november 2018 @ 10:41:
[...]

• C# zal features krijgen die enkel in .NET Core zullen werken

Waar lees je dat, en waarom zou dat ?

[Sandor_Clegane]

whoami schreef op zaterdag 10 november 2018 @ 17:47:
[...]

Hoe bedoel je precies ? .NET Core 2.1 is 2.1, maar implementeert daarom niet .NET standard 2.1 (wat nog niet uit was toen .NET core 2.1 er was)
Ik bedoel maar: ik snap niet wat jij hier nu bedoelt

.Net Core 2.1.200 was geen .Net Core 2.1, .Net Core 2.1.400 is blijkbaar .Net Core 2.1. Hadden we hier tijdje geleden ook al een paar posts over.

Zie dit: https://github.com/dotnet/cli/issues/8743

Onnodig onduidelijk.

whoami schreef op zaterdag 10 november 2018 @ 17:52:
[...]
Waar lees je dat, en waarom zou dat ?

Zie: https://blogs.msdn.micros...ouncing-net-standard-2-1/

Met name:

.NET Framework is the implementation of .NET that’s installed on over one billion machines and thus needs to remain as compatible as possible. Because of this, it moves at a slower pace than .NET Core. Even security and bug fixes can cause breaks in applications because applications depend on the previous behavior. We will make sure that .NET Framework always supports the latest networking protocols, security standards, and Windows features.

.NET Core is the open source, cross-platform, and fast-moving version of .NET. Because of its side-by-side nature it can take changes that we can’t risk applying back to .NET Framework. This means that .NET Core will get new APIs and language features over time that .NET Framework cannot. At Build we showed a demo how the file APIs are faster on .NET Core. If we put those same changes into .NET Framework we could break existing applications, and we don’t want to do that.

Bedenk me net dat het Side by Side argument een dikke wassen neus is, het full framework kon ook altijd prima Side by Side bestaan tot ze dat eruit haalden. Je kon prima 1.1, 2.0 en 3.5 op je machine hebben.

[ Voor 59% gewijzigd door Sandor_Clegane op 10-11-2018 18:09 ]

[Sebazzz]

whoami schreef op zaterdag 10 november 2018 @ 17:52:
[...]
Waar lees je dat, en waarom zou dat ?

Default interface methods komen niet naar .NET Framework, dus dat is een language feature die enkel in .NET Core danwel .NET Standard zal werken.

[Lethalis]

Sebazzz schreef op zaterdag 10 november 2018 @ 18:47:
[...]

Default interface methods komen niet naar .NET Framework, dus dat is een language feature die enkel in .NET Core danwel .NET Standard zal werken.

Ik begrijp niet waarom dat in .Net Standard moet.

Want het betekent ook meteen dat andere toekomstige .Net Standard functies ook niet naar .Net Framework kunnen komen.

Dus als er nu nog een functie mist die je wil gebruiken in beide platformen dan komt die er nooit meer...

[edit]
Ik heb nog even zo de reacties van Immo Landwerth gelezen in dat .NET blog en ik kan eigenlijk ook niet anders concluderen dan dat .NET Core 3 eigenlijk het enige .NET platform is waar alle aandacht naartoe zal gaan.

Wil je je projecten enigszins future proofen dat kun je eigenlijk niet anders dan .NET Core gebruiken en dat betekent ook dat alles wat niet voor .NET Core zal worden gemaakt, in feite dood is.

Wat SOAP services betreft, hield hij nog wel de mogelijkheid open dat WCF volledig geport zal worden overigens. Maar het echte .NET Framework gaat in maintenance mode en zal niet verder ontwikkeld worden.

Immo Landwerth raadt zelfs Windows Forms developers aan om te porten naar .NET Core 3 zodra dat kan...

En elke keer als mensen vragen of het nog op Windows 7 zal draaien, blijft het angstvallig stil.

[ Voor 43% gewijzigd door Lethalis op 10-11-2018 21:30 ]

[Sandor_Clegane]

Dat hele .Net Core had naar mijn mening nooit moeten bestaan. Vroegah had je gewoon .Net met een versie ( 1.1, 2.0, 3.5 enz ) en voor Linux/Mac OS had je Mono. Dat was overzichtelijk en werkte gewoon goed.

Ze hadden prima de platform specifieke delen van .Net een optionele namespace download kunnen maken. Dus dan had je gewoon .Net en als je Winforms wilde betekende dat dus dat je crossplatform gewoon gedag kon zeggen. Refereerde je niet naar die platform specifieke delen dan werkt het gewoon op alles wat een runtime had. Zelfde voor de delen die Com Interop gebruiken.

De tijd die ze in .Net Core hebben gestoken hadden ze prima kunnen gebruiken om de codebase aan te passen en dan ook direct mono mee te nemen. Doordat je toch met IL werkt hadden ze prima de onderliggende code aan kunnen passen in de CLR, dat was voor ontwikkelaars transparant geweest en MS had het rustig aan kunnen doen door gewoon steeds een aantal namespaces te herschrijven. Je werkt nu ook met System.Net in Core en het Full framework, er stond niets in de weg om van 3.5 naar 4.5 bijvoorbeeld System.Net om te batterijen naar een nieuw iets. Dat is juist het mooie aan IL als ze zich aan het "contract" hadden gehouden tussen IL en de CLR hadden ze zo alles kunnen vernieuwen.

Zo hadden ze ook delen die eerst alleen op Windows werkten rustig crossplatform kunnen maken, heb je 4.6 dan is WPF alleen voor Windows maar als je 5.0 draait dan was het goed mogelijk geweest dat WPF al wel geport was. Etc. etc. etc.

Om over WinRT/UWP nog maar te zwijgen.

Maar ja could've would've should've.

[farlane]

Lethalis schreef op zaterdag 10 november 2018 @ 19:25:
[...]
Wil je je projecten enigszins future proofen dat kun je eigenlijk niet anders dan .NET Core gebruiken en dat betekent ook dat alles wat niet voor .NET Core zal worden gemaakt, in feite dood is.

Ik heb dat niet bijgehouden, maar geldt dat voor *alle* .NET? Dus ook WinForms, WPF en what not?

[Lethalis]

farlane schreef op zaterdag 10 november 2018 @ 22:31:
[...]

Ik heb dat niet bijgehouden, maar geldt dat voor *alle* .NET? Dus ook WinForms, WPF en what not?

Het schijnt dat WinForms en WPF het op .NET Core 3 gaan doen. Maar het is onduidelijk of dit ook op Windows 7 zal werken.

Gebruik je echter nog ergens WebForms of ASMX web services, dan is dat end of life. Microsoft gaat daar niks meer aan doen.

Het leukste is nog EF Core. Dit is lang gezien als een vervanger voor EF, maar als dit naar een hogere .NET Standard gaat, dan zal het niet meer werken op .NET Framework. Dus dan moet je over naar .NET Core wil je een nieuwe EF gebruiken...

Dat soort dingen.

Sandor_Clegane schreef op zaterdag 10 november 2018 @ 21:48:
Dat hele .Net Core had naar mijn mening nooit moeten bestaan. Vroegah had je gewoon .Net met een versie ( 1.1, 2.0, 3.5 enz ) en voor Linux/Mac OS had je Mono. Dat was overzichtelijk en werkte gewoon goed.

Dat Mono goed werkt, ben ik niet helemaal met jou eens Maar Microsoft had daar natuurlijk wel voor kunnen zorgen.

En ze kunnen zich beter druk maken om al die wrappers om native componenten heen. Wat een puinhoop is dat. Vroeger viel mij dat nooit op, maar nu .NET Core er is, zie je pas wat .NET eigenlijk is (of beter gezegd allemaal niet is).

Veel dingen zouden opnieuw geschreven moeten worden in 100% .NET, om zoveel mogelijk van externe dependencies af te komen en het echt portable te maken.

Maar alles lijkt wel een flinterdunne wrapper om een native library heen, met alle gevolgen van dien. Zo kwam ik er laatst achter dat de ".NET" Sqlite library het alleen op Intel doet. Ik dacht - naïef als ik was - dat het ook wel op ARM zou werken... want ja, .NET Core doet het er immers ook op. Wrong.

En zo is dat met meer dingen, ook core libraries zoals System.Drawing dat een wrapper om GDI heen is etc.

Kijk je dan naar Golang - even afgezien wat je van de taal vindt - dan worden libraries daarvoor vaak helemaal in Golang herschreven, zodat het vervolgens echt overal werkt waar Golang het ook doet.

[ Voor 49% gewijzigd door Lethalis op 10-11-2018 23:22 ]