Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Automatisch, of hengel je de boel handmatig binnen?Brakkie41 schreef op woensdag 23 augustus 2017 @ 21:33:
[...]
Dát is dus precies de reden waarom wij in beginsel alles intern mirroren. Als je gebruik maakt van een library, mirror deze (incl. deps) intern.
Je zou maar net 's nachts uit je nest gebeld worden en geen release kunnen doen omdat Github op ze nek ligt.
Des te hoger de SLA, des te strikter het wordt
Maar inderdaad, als releases er vanaf hangen dan moet je daar wel een oplossing voor hebben. Hier is het nog niet zo'n probleem tot zover, maar wel iets om eens naar te kijken.
Heeft dat niet ook gewoon met performance te maken? Ik kan mij zo voorstellen dat ze het geoptimaliseerd hebben om hetzelfde te kunnen doen, met minder cycles..oisyn schreef op woensdag 23 augustus 2017 @ 22:40:
Meer omdat je natuurlijk met honderdduizenden resourcedescriptors te maken hebt. Een paar bytes gesaved per descriptor tikt dan behoorlijk aan
Even gechecked bij een courante en capabele MCU die we gebruiken: van de 4GB adresruimte wordt +/- 1,5GB gereserveerd voor peripheral registers, das best veel dus..oisyn schreef op woensdag 23 augustus 2017 @ 22:26:
Bij de moderne CPU's waarmee ik in aanmerking kom (GPU's) wordt er nog immer gigantisch gepacked, nog steeds om geheugen uit te sparen. En dan krijg je dus ook rare alignment requirements zoals 32kB voor een texture
Het mooie daar van is dat men niet maar van alles samenvoegt om plaats te sparen, maar het meeste netjes gegroepeerd zit
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
Natuurlijk, in de zin dat compactere data minder gebruikte cachelines betekent.ThomasG schreef op donderdag 24 augustus 2017 @ 10:10:
[...]
Heeft dat niet ook gewoon met performance te maken? Ik kan mij zo voorstellen dat ze het geoptimaliseerd hebben om hetzelfde te kunnen doen, met minder cycles.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Ik ben eigenlijk wel benieuwd wat het verschil in prestaties is met aligned memory ten opzichte van unaligned memory. De meeste CPU's ([bepaalde] ARM tegenwoordig ook) ondersteunen unaligned memory access, maar dat was pak en beet 5 jaar geleden relatief duur en langzaam om te doen. Volgens mij is dat bij de huidige x86-64 CPU's enigszins te verwaarlozen..oisyn schreef op donderdag 24 augustus 2017 @ 11:58:
[...]
Natuurlijk, in de zin dat compactere data minder gebruikte cachelines betekent.
Zie http://infocenter.arm.com...arm.doc.faqs/ka15414.htmlThomasG schreef op donderdag 24 augustus 2017 @ 12:11:
[...]
Ik ben eigenlijk wel benieuwd wat het verschil in prestaties is met aligned memory ten opzichte van unaligned memory. De meeste CPU's ([bepaalde] ARM tegenwoordig ook) ondersteunen unaligned memory access, maar dat was pak en beet 5 jaar geleden relatief duur en langzaam om te doen. Volgens mij is dat bij de huidige x86-64 CPU's enigszins te verwaarlozen.
Geldt niet voor Cortex-M, die ondersteunt geen unaligned access.If code frequently accesses unaligned data, there may be a performance advantage in enabling unaligned accesses. However, the extent of this advantage will be dependent on many factors.
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
Op zich zijn unaligned loads/stores niet langzamer binnen een cacheline. Alleen bestaat de kans dat je met een unaligned load of store een cache line boundary crosst, en dat levert een penalty op.ThomasG schreef op donderdag 24 augustus 2017 @ 12:11:
Volgens mij is dat bij de huidige x86-64 CPU's enigszins te verwaarlozen.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

https://jsfiddle.net/w5ek1z5c/
Zet de cursor aan het begin van de regel, en probeer spaties te tikken.
Na de twee spaties wordt automatisch een linebreak geplaatst, omdat de regel de textarea-breedte vult.
Fan-tas-tisch. Dat is nieuw.
[ Voor 22% gewijzigd door CodeCaster op 24-08-2017 14:05 ]
https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...
.edit: oh wacht het wordt ook echt een linebreak

[ Voor 45% gewijzigd door .oisyn op 24-08-2017 14:00 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Dat heeft nooit zo gewerkt, in geen enkele browser.
Voorheen werd de lange regel wel op een nieuwe regel geprint, maar bleven de spaties behouden. Bijvoorbeeld belangrijk voor Markdown-formatting.
Maar nu wordt elke tweede spatie automatisch opgevolgd door een newline, wat je tekst inhoudelijk verandert.
Ja, dat dus..edit: oh wacht het wordt ook echt een linebreakWTF

[ Voor 9% gewijzigd door CodeCaster op 24-08-2017 14:05 ]
https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...
Without nipples, boobs are pointless - 365 project - In mijn hoofd is het alle dagen Kerstmis - What type of bees make milk? Boobies! - What type of bees are scary? BoooOOOOOooobeees! - Cactusliefhebster
Dacht even 'wtf lul hij nou weer', maar console.log laat idd linebreaks zien lolCodeCaster schreef op donderdag 24 augustus 2017 @ 13:50:
Oh wow, Chrome. Wow.
https://jsfiddle.net/w5ek1z5c/
Zet de cursor aan het begin van de regel, en probeer spaties te tikken.
Na de twee spaties wordt automatisch een linebreak geplaatst, omdat de regel de textarea-breedte vult.
Fan-tas-tisch. Dat is nieuw.
Afhankelijk van processor.. sommige geven je een bus error..oisyn schreef op donderdag 24 augustus 2017 @ 12:44:
Op zich zijn unaligned loads/stores niet langzamer binnen een cacheline. Alleen bestaat de kans dat je met een unaligned load of store een cache line boundary crosst, en dat levert een penalty op.
Welke x86-64 cpu doet dat dan?Olaf van der Spek schreef op donderdag 24 augustus 2017 @ 14:44:
[...]
Afhankelijk van processor.. sommige geven je een bus error.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Wist niet dat het alleen over x86-64 ging..
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Door wie werd er niks mee gedaan dan? Scrum leunt ook erg op self organizing teams. Als je iets constateert als team moet je er ook als team wat aan doen. Bij ons hebben we de regel ingevoerd dat mensen buiten het team maar zoveel uur per week meetings mogen inplannen met mensen van het team. Dat word bijgehouden en als ze op zijn dan heb je pech en moet je wachten. Maar dit werkt bijvoorbeeld pas als iedere team member zich eraan houd.Defector schreef op woensdag 23 augustus 2017 @ 14:09:
[...]
Klopt dat was het ook en dat werd ook vaak genoeg aangegeven. Maarja daar werd niks meegedaan want. Scrum is hot en dus dat gaan we doen.
Nothing to see here!
We heben daar scripts voorTheNephilim schreef op donderdag 24 augustus 2017 @ 09:38:
[...]
Automatisch, of hengel je de boel handmatig binnen?
Maar inderdaad, als releases er vanaf hangen dan moet je daar wel een oplossing voor hebben. Hier is het nog niet zo'n probleem tot zover, maar wel iets om eens naar te kijken.
Het is bij ons meer dan eens voorgekomen dat er een emergency release de deur uit moest maar ergens een of andere externe depenedency niet beschikbaar was. Met tussen de 99.9999% en 99.99999% availability kunnen wij ons (nagenoeg) geen downtime veroorloven.
[ Voor 3% gewijzigd door Swedish Clown op 25-08-2017 07:48 ]
Always looking for developers wanting to work with Erlang.
Wanneer de scrum master en/of product owner die refinement of retrospective van zes uur in je agenda zetten. Dan kun je die moeilijk weigeren.Rutix schreef op donderdag 24 augustus 2017 @ 20:03:
[...]
Door wie werd er niks mee gedaan dan? Scrum leunt ook erg op self organizing teams. Als je iets constateert als team moet je er ook als team wat aan doen. Bij ons hebben we de regel ingevoerd dat mensen buiten het team maar zoveel uur per week meetings mogen inplannen met mensen van het team. Dat word bijgehouden en als ze op zijn dan heb je pech en moet je wachten. Maar dit werkt bijvoorbeeld pas als iedere team member zich eraan houd.
Nu heel snel even gekeken wat hip en happening is en het is toch allemaal wel makkelijker geworden. Met CSS Grid (dus zonder al die vieze rotframeworks) in een mum van tijd een mooie layout gemaakt en met SCSS gaat het stylen ook als een tierelier. Ik begon het zowaar leuk te vinden.
Engineering is like Tetris. Succes disappears and errors accumulate.
Hoezo kun je dan moeilijk weigeren? Ik weiger zo vaak meetings, ook gewoon van mijn baas ofzo als het niet uit komt. Daarnaast ben je samen een team en heeft de PO mandaat op de prio maar kan die echt niet verplichten dat je 6 uur in een hok gaat zitten.Defector schreef op vrijdag 25 augustus 2017 @ 09:30:
[...]
Wanneer de scrum master en/of product owner die refinement of retrospective van zes uur in je agenda zetten. Dan kun je die moeilijk weigeren.
Nothing to see here!
Zou er een performance verschil zijn tussen:
1
2
3
4
5
| var f = obj as Foo; if( f != null ) { f.Bar(); } |
en
1
2
3
4
| if( obj is Foo f ) { f.Bar(); } |
https://fgheysels.github.io/
Verwijderd
Ervan uitgaande dat dat C# is, compileer je beide (met deterministic builds aan) en kijk je of er een verschil in de CIL. Als er geen verschil in de CIL zit, dan is het exact hetzelfde en kan er dus ook geen performance verschil inzitten. Als er wel een verschil in de CIL zit, dan kan je het eventueel nog benchmarken. Sowieso denk ik dat dat verschil, als er al een verschil is, te verwaarlozen is.whoami schreef op vrijdag 25 augustus 2017 @ 10:46:
Wat een mens zich zoal afvraagt:
Zou er een performance verschil zijn tussen:
code:
1 2 3 4 5 var f = obj as Foo; if( f != null ) { f.Bar(); }
en
code:
1 2 3 4 if( obj is Foo f ) { f.Bar(); }
[ Voor 26% gewijzigd door Verwijderd op 25-08-2017 11:08 ]
Wat ík me dan zoal afvraag is wat je in hemelsnaam aan het maken bent dat, mocht dit idd een paar cycles verschillen (want meer zal het niet zijn), je dat ook echt gaat zien in het eindresultaat?whoami schreef op vrijdag 25 augustus 2017 @ 10:46:
Wat een mens zich zoal afvraagt:
Zou er een performance verschil zijn tussen:
code:
1 2 3 4 5 var f = obj as Foo; if( f != null ) { f.Bar(); }
en
code:
1 2 3 4 if( obj is Foo f ) { f.Bar(); }
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
RavenDB.oisyn schreef op vrijdag 25 augustus 2017 @ 11:07:
[...]
Wat ík me dan zoal afvraag is wat je in hemelsnaam aan het maken bent dat, mocht dit idd een paar cycles verschillen (want meer zal het niet zijn), je dat ook echt gaat zien in het eindresultaat?
[Te koop: 3D printers] [Website] Agile tools: [Return: retrospectives] [Pokertime: planning poker]
Blijkbaar is er tijdens een context switch wat data verloren gegaan..oisyn schreef op donderdag 24 augustus 2017 @ 14:49:
@Olaf van der Spek Dat staat letterlijk in de quote in mijn post waar jij op reageerde
We werken aan een AS4 message handler. Het is echter niet zo dat ik hier probeer te micro-optimizen, 't is gewoon eerder uit nieuwsgierigheid..oisyn schreef op vrijdag 25 augustus 2017 @ 11:07:
[...]
Wat ík me dan zoal afvraag is wat je in hemelsnaam aan het maken bent dat, mocht dit idd een paar cycles verschillen (want meer zal het niet zijn), je dat ook echt gaat zien in het eindresultaat?
IL inspecteren geeft natuurlijk een antwoord; dat ik daar op deze vrijdag nog niet aan gedacht heb
https://fgheysels.github.io/
En wat is het antwoordwhoami schreef op vrijdag 25 augustus 2017 @ 11:13:
[...]
We werken aan een AS4 message handler. Het is echter niet zo dat ik hier probeer te micro-optimizen, 't is gewoon eerder uit nieuwsgierigheid.
IL inspecteren geeft natuurlijk een antwoord; dat ik daar op deze vrijdag nog niet aan gedacht heb
Nothing to see here!
Het is misschien makkelijker geworden, maar: 1) ik vind het nog steeds een kriem om mee te werken omdat het ook op 10 duizende verschillende resoluties, DPI's en verhoudingen moet werken 2) ik totaal niets van design kanarmageddon_2k1 schreef op vrijdag 25 augustus 2017 @ 09:33:
Voor een simpel eigen web-appje wilde ik even een front-endje in elkaar steken. De laatste keer dat ik met CSS en HTML gewerkt heb is 6 jaar geleden dus ik zag er aardig tegenop omdat het gewoon kut is. Toen was het 960 Grid System nog hip.
Nu heel snel even gekeken wat hip en happening is en het is toch allemaal wel makkelijker geworden. Met CSS Grid (dus zonder al die vieze rotframeworks) in een mum van tijd een mooie layout gemaakt en met SCSS gaat het stylen ook als een tierelier. Ik begon het zowaar leuk te vinden.
Is het nieuwe syntax? dotnetfiddle.com snapt het niet (.Net 4.5)
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Het is C# 7.oisyn schreef op vrijdag 25 augustus 2017 @ 11:25:
[...]
Is het nieuwe syntax? dotnetfiddle.com snapt het niet (.Net 4.5)
https://dotnetfiddle.net/rzQXfx
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
| .method private hidebysig static void Test1(class A a) cil managed { // .maxstack 2 .locals init ([0] class B b, [1] bool V_1) .line 7,7 : 2,3 '' IL_0000: nop .line 8,8 : 3,18 '' IL_0001: ldarg.0 IL_0002: isinst B IL_0007: stloc.0 .line 9,9 : 3,17 '' IL_0008: ldloc.0 IL_0009: ldnull IL_000a: cgt.un IL_000c: stloc.1 .line 16707566,16707566 : 0,0 '' IL_000d: ldloc.1 IL_000e: brfalse.s IL_0019 .line 10,10 : 3,4 '' IL_0010: nop .line 11,11 : 4,12 '' IL_0011: ldloc.0 IL_0012: callvirt instance void B::Bar() IL_0017: nop .line 12,12 : 3,4 '' IL_0018: nop .line 13,13 : 2,3 '' IL_0019: ret } // end of method Test::Test1 .method private hidebysig static void Test2(class A a) cil managed { // .maxstack 2 .locals init ([0] class B b, [1] bool V_1) .line 16,16 : 2,3 '' IL_0000: nop .line 17,17 : 3,16 '' IL_0001: ldarg.0 IL_0002: isinst B IL_0007: dup IL_0008: stloc.0 IL_0009: ldnull IL_000a: cgt.un IL_000c: stloc.1 .line 16707566,16707566 : 0,0 '' IL_000d: ldloc.1 IL_000e: brfalse.s IL_0019 .line 18,18 : 3,4 '' IL_0010: nop .line 19,19 : 4,12 '' IL_0011: ldloc.0 IL_0012: callvirt instance void B::Bar() IL_0017: nop .line 20,20 : 3,4 '' IL_0018: nop .line 21,21 : 2,3 '' IL_0019: ret } // end of method Test::Test2 |
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Er is een klein verschil in de IL:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| .method private hidebysig static void UseAs(object o) cil managed { // Code size 30 (0x1e) .maxstack 2 .locals init ([0] class PatternMatch.Child m, [1] bool V_1) IL_0000: nop IL_0001: ldarg.0 IL_0002: isinst PatternMatch.Child IL_0007: stloc.0 IL_0008: ldloc.0 IL_0009: ldnull IL_000a: cgt.un IL_000c: stloc.1 IL_000d: ldloc.1 IL_000e: brfalse.s IL_001d IL_0010: nop IL_0011: ldstr "allright" IL_0016: call void [mscorlib]System.Console::WriteLine(string) IL_001b: nop IL_001c: nop IL_001d: ret } // end of method Program::UseAs |
en
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| .method private hidebysig static void UsePatternMatch(object o) cil managed { // Code size 30 (0x1e) .maxstack 2 .locals init ([0] class PatternMatch.Child p, [1] bool V_1) IL_0000: nop IL_0001: ldarg.0 IL_0002: isinst PatternMatch.Child IL_0007: dup IL_0008: stloc.0 IL_0009: ldnull IL_000a: cgt.un IL_000c: stloc.1 IL_000d: ldloc.1 IL_000e: brfalse.s IL_001d IL_0010: nop IL_0011: ldstr "allright" IL_0016: call void [mscorlib]System.Console::WriteLine(string) IL_001b: nop IL_001c: nop IL_001d: ret } // end of method Program::UsePatternMatch |
Het verschil zit in line 7 & 8
https://fgheysels.github.io/
Afgezien van dit minimale verschil doet hij in beide gevallen gewoon een compare met null. Ik vraag me af of er überhaupt een IL constructie bestaat voor 'is', die dus een boolean returnt.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
[Te koop: 3D printers] [Website] Agile tools: [Return: retrospectives] [Pokertime: planning poker]
Als de IL gelijk zou zijn, waarom zou de JIT er dan wat anders van maken?Sebazzz schreef op vrijdag 25 augustus 2017 @ 11:43:
IL is toch eigenlijk niet eens zo interessant? Uiteindelijk is interessant wat de JIT compiler ervan maakt.
Ik reageerde op dat er een kleine verschil in de IL zou zitten.Dido schreef op vrijdag 25 augustus 2017 @ 11:44:
[...]
Als de IL gelijk zou zijn, waarom zou de JIT er dan wat anders van maken?
[Te koop: 3D printers] [Website] Agile tools: [Return: retrospectives] [Pokertime: planning poker]
Ik snap niet waarom line 8 (ldloc.0) van de eerste en line 7 (dup) van de 2de uberhaupt aangeroepen worden. Iemand die dit uit kan leggen?whoami schreef op vrijdag 25 augustus 2017 @ 11:32:
[...]
Er is een klein verschil in de IL:
code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 .method private hidebysig static void UseAs(object o) cil managed { // Code size 30 (0x1e) .maxstack 2 .locals init ([0] class PatternMatch.Child m, [1] bool V_1) IL_0000: nop IL_0001: ldarg.0 IL_0002: isinst PatternMatch.Child IL_0007: stloc.0 IL_0008: ldloc.0 IL_0009: ldnull IL_000a: cgt.un IL_000c: stloc.1 IL_000d: ldloc.1 IL_000e: brfalse.s IL_001d IL_0010: nop IL_0011: ldstr "allright" IL_0016: call void [mscorlib]System.Console::WriteLine(string) IL_001b: nop IL_001c: nop IL_001d: ret } // end of method Program::UseAs
en
code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 .method private hidebysig static void UsePatternMatch(object o) cil managed { // Code size 30 (0x1e) .maxstack 2 .locals init (\[0] class PatternMatch.Child p, \[1] bool V_1) IL_0000: nop IL_0001: ldarg.0 IL_0002: isinst PatternMatch.Child IL_0007: dup IL_0008: stloc.0 IL_0009: ldnull IL_000a: cgt.un IL_000c: stloc.1 IL_000d: ldloc.1 IL_000e: brfalse.s IL_001d IL_0010: nop IL_0011: ldstr "allright" IL_0016: call void \[mscorlib]System.Console::WriteLine(string) IL_001b: nop IL_001c: nop IL_001d: ret } // end of method Program::UsePatternMatch
Het verschil zit in line 7 & 8
Edit: formatting
De IL is wel interessant, wat er niet interessant is is dat kleine verschilSebazzz schreef op vrijdag 25 augustus 2017 @ 11:46:
[...]
Ik reageerde op dat er een kleine verschil in de IL zou zitten.
Om terug te komen op mijn eerdere opmerking, er bestaat idd niet iets voor 'is'. Als je dat gebruikt dan compileert dat ook gewoon naar een 'isinst' en een null check.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Een store popt van de stack. Hij wil het resultaat van isinst opslaan in local #0, en vervolgens ook comparen tegen null. Hij moet dus ofwel een store doen gevolgd door een load, ofwel een dup gevolgd door een store.Soundless schreef op vrijdag 25 augustus 2017 @ 11:48:
[...]
Ik snap niet waarom line 8 (ldloc.0) van de eerste en line 7 (dup) van de 2de uberhaupt aangeroepen worden. Iemand die dit uit kan leggen?
Edit: formatting
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Dat begrijp ik nog maar:.oisyn schreef op vrijdag 25 augustus 2017 @ 11:51:
[...]
Een store popt van de stack. Hij wil het resultaat van isinst opslaan in local #0, en vervolgens ook comparen tegen null. Hij moet dus ofwel een store doen gevolgd door een load, ofwel een dup gevolgd door een store.
- na een stloc hoef je toch geen ldloc te doen? Dus waarom ldloc aanroepen?
- waarom dup aanroepen als je het origineel gewoon op kan slaan? Dus waarom uberhaupt dup aanroepen?
[ Voor 16% gewijzigd door Soundless op 25-08-2017 11:59 ]
PreciesSoundless schreef op vrijdag 25 augustus 2017 @ 11:55:
Edit: oww wacht. 'een store popt' dus punt 1 klopt dan niet? Je moet ldloc aanroepen omdat er niks meer in de stack staat?
ldarg.0 -> Push argument op stack. Stack is { obj }
isinst Bar -> Vervangt top stack met null als top stack geen instance is van Bar. Stack is { obj2 }
dup -> Duplicate top van stack. Stack is { obj2, obj2 }
stloc.0 -> Store top van stack in local #0. Stack is { obj2 }
ldnull -> Pusht null op stack. Stack is { obj2, null }
cgt.un -> Popt 2 waarden van stack, pusht 1 als eerste waarde groter is dan tweede waarde. Stack is { 0/1 }
[ Voor 56% gewijzigd door .oisyn op 25-08-2017 12:28 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Tevens de boel maar naar PHP 7 overgezet en SSL op het gehele geheel gegooid.
Nu vroeg ik me af: Wordt Mantis BT nog actief gebruikt, of is dit al weer behoorlijk achterhaald?
☎ Telecommunicatie van vroeger
🚅Alles over spoor en treintjes
whoami schreef op vrijdag 25 augustus 2017 @ 10:46:
Wat een mens zich zoal afvraagt:
Zou er een performance verschil zijn tussen:
code:
1 2 3 4 5 var f = obj as Foo; if( f != null ) { f.Bar(); }
en
code:
1 2 3 4 if( obj is Foo f ) { f.Bar(); }
1
| (obj as Foo)?.Bar(); |
Nog kortere IL ook:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| .method private hidebysig static void Whatisit(object obj) cil managed { // .maxstack 8 .line 40,40 : 2,3 '' IL_0000: nop .line 41,41 : 3,23 '' IL_0001: ldarg.0 IL_0002: isinst Foo IL_0007: dup IL_0008: brtrue.s IL_000d IL_000a: pop IL_000b: br.s IL_0013 IL_000d: call instance void Foo::Bar() IL_0012: nop .line 42,42 : 2,3 '' IL_0013: ret } // end of method Program::Whatisit |
https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...
Wat wel een branch oplevert wanneer het niet null is, terwijl de andere code branched wanneer het wel null is. Het hangt dus af van de JIT en de kans dat het null is, welke code uiteindelijk beter is.CodeCaster schreef op vrijdag 25 augustus 2017 @ 13:15:
[...]
C#:
1 (obj as Foo)?.Bar();
Nog kortere IL ook:
code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 .method private hidebysig static void Whatisit(object obj) cil managed { // .maxstack 8 .line 40,40 : 2,3 '' IL_0000: nop .line 41,41 : 3,23 '' IL_0001: ldarg.0 IL_0002: isinst Foo IL_0007: dup IL_0008: brtrue.s IL_000d IL_000a: pop IL_000b: br.s IL_0013 IL_000d: call instance void Foo::Bar() IL_0012: nop .line 42,42 : 2,3 '' IL_0013: ret } // end of method Program::Whatisit
Tsja, dan moet whoami er maar een [un]likely() omheen zetten, ik weet ook niet welke branch vaker voorkomt.ThomasG schreef op vrijdag 25 augustus 2017 @ 13:26:
[...]
Wat wel een branch oplevert wanneer het niet null is, terwijl de andere code branched wanneer het wel null is. Het hangt dus af van de JIT en de kans dat het null is, welke code uiteindelijk beter is.
[ Voor 12% gewijzigd door CodeCaster op 25-08-2017 13:29 ]
https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Hmm, ja. Want deze code.oisyn schreef op vrijdag 25 augustus 2017 @ 13:31:
Ik vind het enigszins apart dat de compiler nu wel ineens een compare direct op een reference kan doen, en eerder expliciet een check tegen null doet.
1
2
3
4
5
| var f = obj as Foo; if (f != null) { f.Bar(); } |
Compileert dus naar dit:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| .locals init ([0] class Foo f, [1] bool V_1) IL_0000: nop IL_0001: ldarg.0 // push arg0 on stack IL_0002: isinst Foo // push null (when not Foo) or instance (when Foo) on stack IL_0007: stloc.0 // pop the null or instance, store in local0 IL_0008: ldloc.0 // push the null or instance from local0 IL_0009: ldnull // push null IL_000a: cgt.un // pop, pop, push 1 if obj was Foo, otherwise 0 IL_000c: stloc.1 // pop the 1 or 0, store in local1 IL_000d: ldloc.1 // push the 1 or 0 from local1 IL_000e: brfalse.s IL_0019 // pop, goto IL_0019 when obj was not a Foo IL_0010: nop IL_0011: ldloc.0 // push local0 IL_0012: callvirt instance void Foo::Bar() // pop local0 and call Bar() IL_0017: nop IL_0018: nop IL_0019: ret |
Terwijl dit volgens mij functioneel equivalent is, maar dan zonder locals:
1
2
3
4
5
6
7
8
9
10
11
| IL_0000: nop IL_0001: ldarg.0 // push arg0 on stack IL_0002: isinst Foo // push null (when not Foo) or instance (when Foo) on stack dup // duplicate the null or instance IL_000e: brfalse.s IL_0019 // pop, goto IL_0019 when obj was not a Foo IL_0010: nop IL_0012: callvirt instance void Foo::Bar() // pop isinst result and call Bar() IL_0017: nop IL_0018: nop IL_0019: ret |
Toch?
Maar ik heb wat minder ervaring met assembly, dus ben niet zo goed in "stack-denken".
Maar misschien is dit allemaal moot en compileert het in Release allemaal naar dezelfde CIL.
Edit, release:
1
2
3
4
5
6
7
8
9
10
11
12
13
| private static void As(object obj) { var f = obj as Foo; if (f != null) { f.Bar(); } } private static void Elvas(object obj) { (obj as Foo)?.Bar(); } |
Wordt:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
| .method private hidebysig static void As ( object obj ) cil managed { .locals init ( [0] class TypeChecking.Foo f ) IL_0000: ldarg.0 IL_0001: isinst TypeChecking.Foo IL_0006: stloc.0 IL_0007: ldloc.0 IL_0008: brfalse.s IL_0010 IL_000a: ldloc.0 IL_000b: callvirt instance void TypeChecking.Foo::Bar() IL_0010: ret } .method private hidebysig static void Elvas ( object obj ) cil managed { IL_0000: ldarg.0 IL_0001: isinst TypeChecking.Foo IL_0006: dup IL_0007: brtrue.s IL_000b IL_0009: pop IL_000a: ret IL_000b: call instance void TypeChecking.Foo::Bar() IL_0010: ret } |
De compiler blijft hardnekkig vasthouden aan z'n local, maar dat is misschien toch voor breakpoints?
[ Voor 27% gewijzigd door CodeCaster op 25-08-2017 14:26 ]
https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...
1
2
3
4
| try { (a as B).Bar(); } catch (InvalidCastException ex) { } |
Wat de IL-code oplevert:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
| .method private hidebysig static void Test4(class A a) cil managed { // .maxstack 1 .locals init ([0] class [mscorlib]System.InvalidCastException ex) .line 29,29 : 25,26 '' IL_0000: nop .line 30,30 : 7,8 '' .try { IL_0001: nop .line 31,31 : 4,19 '' IL_0002: ldarg.0 IL_0003: isinst B IL_0008: callvirt instance void B::Bar() IL_000d: nop .line 32,32 : 3,4 '' IL_000e: nop IL_000f: leave.s IL_0016 .line 32,32 : 5,36 '' } // end .try catch [mscorlib]System.InvalidCastException { IL_0011: stloc.0 .line 32,32 : 37,38 '' IL_0012: nop .line 33,33 : 3,4 '' IL_0013: nop IL_0014: leave.s IL_0016 .line 34,34 : 2,3 '' } // end handler IL_0016: ret } // end of method Test::Test4 |
Het heeft een kleine overhead door de try/catch (het initialiseert de exception altijd, en een jump), maar verder minder instructies oplevert wanneer er geen exception is.
Nu wordt ik toch wel benieuwd naar een benchmark
Ja, maar deze code kan een NullReferenceException opleveren, want de as operator throwed geen exception, maar returned null indien a niet van het type B is.ThomasG schreef op vrijdag 25 augustus 2017 @ 14:09:
Er is natuurlijk ook nog:
C#:
1 2 3 4 try { (a as B).Bar(); } catch (InvalidCastException ex) { }
Dan ben je beter met dit:
1
2
3
4
| try { ((B)a).Bar(); } catch (InvalidCastException ex) { } |
Maar dergelijke constructies zijn imho gewoon bad practice.
Indien a niet van het gewenste type is, wordt er een exception gethrowed, wat zowiezo duurder is dan een branch.
[ Voor 26% gewijzigd door whoami op 25-08-2017 14:14 ]
https://fgheysels.github.io/
Wat dus alleen het geval is wanneer er een exception optreed. Als er geen exception optreed is het niet of nauwelijks duurder. Het hangt dan af van hoevaak het niet van het gewenste type is. Het is natuurlijk niet hoe je de code het liefst wilt hebben, maar ik ben toch wel benieuwd naar welke manier nu uiteindelijk het snelste is.whoami schreef op vrijdag 25 augustus 2017 @ 14:11:
[...]
Ja, maar deze code kan een NullReferenceException opleveren, want de as operator throwed geen exception, maar returned null indien a niet van het type B is.
Dan ben je beter met dit:
C#:
1 2 3 4 try { ((B)a).Bar(); } catch (InvalidCastException ex) { }
Maar dergelijke constructies zijn imho gewoon bad practice.
Indien a niet van het gewenste type is, wordt er een exception gethrowed, wat zowiezo duurder is dan een branch.
Dat maakt meer sense idd. Die local is niet raar, je hebt immers in je code ook daadwerkelijk een local in het ene voorbeeld, en in het andere niet. Je wilt die kunnen uitlezen als je aan het debuggen bent. De JIT'er zal het verder wel optimizen.CodeCaster schreef op vrijdag 25 augustus 2017 @ 14:04:
Edit, release:
C#:
1 2 3 4 5 6 7 8 9 10 11 12 13 private static void As(object obj) { var f = obj as Foo; if (f != null) { f.Bar(); } } private static void Elvas(object obj) { (obj as Foo)?.Bar(); }
Wordt:
code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 .method private hidebysig static void As ( object obj ) cil managed { .locals init ( \[0] class TypeChecking.Foo f ) IL_0000: ldarg.0 IL_0001: isinst TypeChecking.Foo IL_0006: stloc.0 IL_0007: ldloc.0 IL_0008: brfalse.s IL_0010 IL_000a: ldloc.0 IL_000b: callvirt instance void TypeChecking.Foo::Bar() IL_0010: ret } .method private hidebysig static void Elvas ( object obj ) cil managed { IL_0000: ldarg.0 IL_0001: isinst TypeChecking.Foo IL_0006: dup IL_0007: brtrue.s IL_000b IL_0009: pop IL_000a: ret IL_000b: call instance void TypeChecking.Foo::Bar() IL_0010: ret }
De compiler blijft hardnekkig vasthouden aan z'n local, maar dat is misschien toch voor breakpoints?
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Nu is .NET Core 2.0 uitgekomen, dus wil ik m'n packages updaten. De ene na de andere error ("Detected package downgrade", "Package [...] was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework"), de projecten compileren niet meer en ReSharper is al helemaal de kwijtweg.
Dan toch maar weer met Notepad++ de projectfiles bijwerken, zoals eigenlijk altijd al moest.
Bepaalde versies van ReSharper hebben bij .NET Framework-projecten namelijk nog steeds de bug dat ze wel de reference toevoegen uit de packages-folder, maar niet de packages.config aanpassen... Terwijl die functionaliteit al in 2012 is toegevoegd. Het werkt dus op jouw machine, maar niet op die van een collega. Gelukkig hoeft dat bij CSProj2017 (of hoe het nieuwe formaat ook heet) enkel nog in de projectfile...
Ik háát die "move fast and break things"-mentaliteit. "Microsoft" stond voor mij ooit te boek voor "pijnloos upgraden", voor alle soorten upgrades worden tools en wizards geleverd. Niet bij Core: zoek het allemaal maar lekker zelf uit. Hun "works on my machine"-gehalte is geluchtraket sinds ze opensource zijn gegaan.
Edit: OK, het was dus wéér ReSharper:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>netstandard2.0</TargetFramework> </PropertyGroup> <ItemGroup> <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.0.0" /> </ItemGroup> <ItemGroup> <Reference Include="Microsoft.AspNetCore.Identity.EntityFrameworkCore"> <HintPath>[...]\.nuget\packages\microsoft.aspnetcore.identity.entityframeworkcore\2.0.0-preview2-final\lib\netstandard2.0\Microsoft.AspNetCore.Identity.EntityFrameworkCore.dll</HintPath> </Reference> <Reference Include="Microsoft.Extensions.Identity.Stores"> <HintPath>[...]\.nuget\packages\microsoft.extensions.identity.stores\2.0.0-preview2-final\lib\netstandard2.0\Microsoft.Extensions.Identity.Stores.dll</HintPath> </Reference> </ItemGroup> </Project> |
Geen packagereferences, maar references naar assemblies in package-directories.
[ Voor 51% gewijzigd door CodeCaster op 27-08-2017 09:49 ]
https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...
[Te koop: 3D printers] [Website] Agile tools: [Return: retrospectives] [Pokertime: planning poker]
Lijkt een beetje op mensen die over de NS klagen als ProRail weer wat fout doetSebazzz schreef op zondag 27 augustus 2017 @ 10:30:
Dus je zit te kankeren op Microsoft maar stiekem is het JetBrains?
Tsja, in dat geval weten mensen natuurlijk niet beter. Ze nemen de dienst af van NS, ProRail is een toeleverancier en hebben ze niets mee te maken. Als bij een restaurant iets niet besteld kan worden omdat ingrediënten niet op voorraad zijn, gaat de klant ook niet bij de DeliXL klagenDido schreef op zondag 27 augustus 2017 @ 10:46:
[...]
Lijkt een beetje op mensen die over de NS klagen als ProRail weer wat fout doet
[Te koop: 3D printers] [Website] Agile tools: [Return: retrospectives] [Pokertime: planning poker]
Je hebt wel de laatste versie van ReSharper? Want anders word .net Core 2 helemaal niet ondersteund. En zoals mensen hierboven al zeggen: ReSharper is niet van MSCodeCaster schreef op zondag 27 augustus 2017 @ 09:35:
Wat blijft dat .NET Core toch een hel. Ik heb een demoproject waarmee ik thuis hobby, met Entity Framework, ASP.NET Core, .NET Core en wat van m'n eigen libraries, geport naar .NET Standard. Gewoon om van te leren.
Nee, het is allebei ruk.Sebazzz schreef op zondag 27 augustus 2017 @ 10:30:
Dus je zit te kankeren op Microsoft maar stiekem is het JetBrains?
Laat ik het anders zeggen: is er iemand tevreden met hoe .NET Core tot nu toe gaat? Het is eerder .NETniet zeg maar.
Sinds 2.0 heb je redelijke functionaliteit, maar verder nog bijzonder onbruikbaar, en het upgraden is en blijft een hel.
[ Voor 38% gewijzigd door CodeCaster op 27-08-2017 13:22 ]
https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...
Heb er ook problemen mee. Ook .NETStandard durf ik bijna onder dezelfde noemer gooien. Het idee is goed, maar de uitwerking voelt nog erg beta achtig aan.CodeCaster schreef op zondag 27 augustus 2017 @ 11:53:
[...]
Nee, het is allebei ruk.
Laat ik het anders zeggen: is er iemand tevreden met hoe .NET Core tot nu toe gaat? Het is eerder .NETniet zeg maar.
Sinds 2.0 heb je redelijke functionaliteit, maar verder nog bijzonder onbruikbaar, en het upgraden is en blijft een hel.
Tevens, in een enterprise / corporate omgeving waar heel wat regels gelden, is het een miserie om ermee te werken.
Ik vind het ook vervelend om nu te kiezen welk "framework" te nemen voor web ontwikkeling. ASP.NET MVC en Web API lijken duidelijk aan de kant geschovem te zijn; maar het onvolwassen karakter van .NET Core vind ik ook niet aansprekend.
Wij gebruiken het met alle tevredenheid voor 'gewone' REST API's met een postgres database. Maar dan concurreerd het meer met NodeJs en co. dan met ASP.NET.CodeCaster schreef op zondag 27 augustus 2017 @ 11:53:
Laat ik het anders zeggen: is er iemand tevreden met hoe .NET Core tot nu toe gaat? Het is eerder .NETniet zeg maar.
Sinds 2.0 heb je redelijke functionaliteit, maar verder nog bijzonder onbruikbaar, en het upgraden is en blijft een hel.
cracking cloud schreef op zondag 27 augustus 2017 @ 13:44:
En zolang mssql voor linux nog niet uit is kan ik er ook nog niet zoveel mee.
Wat heeft .NET Core met SQL Server op Linux te maken ?
Je hoeft helemaal niet beperkt te zijn tot SQL Server; je kan prima een ander DBMS gebruiken.
https://fgheysels.github.io/
Goh. Wij (bedrijfje dat in de medische sector met ISO 13485 zit) gaan nu toch .NET Core 2.0 gebruiken voor een nieuwe tool/product. Inderdaad, dat het nog z'n kinderziektes heeft, is te verwachten. Al moet ik wel eerlijk zijn, het zijn voorlopig alleen de externe tools zoals ReSharper die het af lieten weten - inmiddels is er een update van ReSharper met .NET Core 2.0 support.Styxxy schreef op zondag 27 augustus 2017 @ 15:00:
[...]
Heb er ook problemen mee. Ook .NETStandard durf ik bijna onder dezelfde noemer gooien. Het idee is goed, maar de uitwerking voelt nog erg beta achtig aan.
Tevens, in een enterprise / corporate omgeving waar heel wat regels gelden, is het een miserie om ermee te werken.
Ik vind het ook vervelend om nu te kiezen welk "framework" te nemen voor web ontwikkeling. ASP.NET MVC en Web API lijken duidelijk aan de kant geschovem te zijn; maar het onvolwassen karakter van .NET Core vind ik ook niet aansprekend.
Aangezien EF het type RDBMS weg-abstraheert, vind ik dat een rare redeneringcracking cloud schreef op zondag 27 augustus 2017 @ 18:02:
Als ik .net core gebruik zou ik ook het liefst EF core gebruiken en als ik EF core gebruik doe ik dat het liefste met MSSQL. Gewoon persoonlijke voorkeur.
https://fgheysels.github.io/
Klopt, tot zover de theorie. In de praktijk blijken er af en toe nog wat rare zaken in te zitten waar je dan omheen moet werken.whoami schreef op zondag 27 augustus 2017 @ 18:38:
[...]
Aangezien EF het type RDBMS weg-abstraheert, vind ik dat een rare redenering
-- edit (paar voorbeeldjes).
* de mysql provider is nog pre-release
* SqlLite ondersteunt (nog) geen AddPrimaryKey
* vage scaffolding dingen in mysql pomelo
[ Voor 19% gewijzigd door cracking cloud op 27-08-2017 20:14 ]
Zoals ?cracking cloud schreef op zondag 27 augustus 2017 @ 20:09:
[...]
Klopt, tot zover de theorie. In de praktijk blijken er af en toe nog wat rare zaken in te zitten waar je dan omheen moet werken.
https://fgheysels.github.io/
Bij ons werkt .NET Standard echt uitstekend. Wij gebruiken nu nog bij veel projecten ASP.NET Core boven op full framework maar we wilde wel voorbereid zijn op de toekomst van .NET Core. We hebben nu dus een paar .NET Core projecten en die kunnen ook gewoon onze .NET Standard libraries zonder problemen gebruiken.Styxxy schreef op zondag 27 augustus 2017 @ 15:00:
[...]
Heb er ook problemen mee. Ook .NETStandard durf ik bijna onder dezelfde noemer gooien. Het idee is goed, maar de uitwerking voelt nog erg beta achtig aan.
Tevens, in een enterprise / corporate omgeving waar heel wat regels gelden, is het een miserie om ermee te werken.
Ik vind het ook vervelend om nu te kiezen welk "framework" te nemen voor web ontwikkeling. ASP.NET MVC en Web API lijken duidelijk aan de kant geschovem te zijn; maar het onvolwassen karakter van .NET Core vind ik ook niet aansprekend.
Ik heb inderdaad wel meer problemen gezien bij 3rd party tools zoals Resharper maar verder rest nog niet echt iets te klagen.
Op je laatste opmerking je hoeft geen .NET Core te gebruiken als je ASP.NET Core wilt gebruiken. ASP.NET Core werkt echt prima op full framework. Ik zou persoonlijk geen nieuwe dingen meer bouwen in ASP.NET MVC en WebApi.
[ Voor 9% gewijzigd door Rutix op 28-08-2017 07:56 ]
Nothing to see here!
We are shaping the future
Het .NET (full) framework zit (helaas) vol met Windows/Microsoft specifieke dingen, dat is historisch zo ontstaan maar geeft problemen bij multi-platform; wat Microsoft nu graag wilt bereiken met hun nieuwe bedrijfsvoering. .NET Core richt zich op platform onafhankelijkheid, waarbij het dus niet uitmaakt of je op Windows, Linux of OS X deployed.Alex) schreef op maandag 28 augustus 2017 @ 09:12:
Ik moet eerlijk bekennen dat ik de weg een beetje kwijt ben als het aankomt op .NET. Wat is nou het verschil tussen .NET Core, Standard, full framework, enzovoorts?
.NET Framework heeft dus zeg maar een grote vendor-lockin met Microsoft/Windows.
.NET Core kun je zien als een directe concurrent van Java.
Wat ik mij nu dus afvraag is; ik weet dat er (volgens mij) niet echt UX/UI classes in .Net Core zitten. Zijn er al mogelijkheden als ik client apps op basis van .Net Core wil ontwikkelen (wat lastig is want dan krijg je weer platform/API specifiek geneuzel), of moet ik dan naar andere oplossingen zoeken?ThomasG schreef op maandag 28 augustus 2017 @ 09:35:
[...]
Het .NET (full) framework zit (helaas) vol met Windows/Microsoft specifieke dingen, dat is historisch zo ontstaan maar geeft problemen bij multi-platform; wat Microsoft nu graag wilt bereiken met hun nieuwe bedrijfsvoering. .NET Core richt zich op platform onafhankelijkheid, waarbij het dus niet uitmaakt of je op Windows, Linux of OS X deployed.
.NET Framework heeft dus zeg maar een grote vendor-lockin met Microsoft/Windows.
.NET Core kun je zien als een directe concurrent van Java.
edit: of moet ik .net core bijvoorbeeld voor business logic gebruiken, die ik dan weer reference in platform specifieke projects? (wat sowieso qua architectuur hout snijd)
[ Voor 8% gewijzigd door Laurens-R op 28-08-2017 11:18 ]
.Net core is niet bedoeld voor client apps. Je hebt wel je Razor .cshtml templates voor webapps. Maar het liefst bouw je met core (REST) API's die je kan gebruiken in een cliënt naar keuze.Laurens-R schreef op maandag 28 augustus 2017 @ 11:16:
[...]
Wat ik mij nu dus afvraag is; ik weet dat er (volgens mij) niet echt UX/UI classes in .Net Core zitten. Zijn er al mogelijkheden als ik client apps op basis van .Net Core wil ontwikkelen (wat lastig is want dan krijg je weer platform/API specifiek geneuzel), of moet ik dan naar andere oplossingen zoeken?
edit: of moet ik .net core bijvoorbeeld voor business logic gebruiken, die ik dan weer reference in platform specifieke projects? (wat sowieso qua architectuur hout snijd)
Beetje zoals dat je een fiets kunt zien als directe concurrent voor een autoThomasG schreef op maandag 28 augustus 2017 @ 09:35:
.NET Core kun je zien als een directe concurrent van Java.
Nee, en de kans dat dat gaat komen is nihil. Die GUI spullen van .Net zijn hard gekoppeld aan Windows zelf. Het zou een enorme hoeveelheid tijd kosten en dan zou je met iets als JavaFX komen.Laurens-R schreef op maandag 28 augustus 2017 @ 11:16:
Wat ik mij nu dus afvraag is; ik weet dat er (volgens mij) niet echt UX/UI classes in .Net Core zitten. Zijn er al mogelijkheden als ik client apps op basis van .Net Core wil ontwikkelen (wat lastig is want dan krijg je weer platform/API specifiek geneuzel), of moet ik dan naar andere oplossingen zoeken?
[ Voor 54% gewijzigd door Hydra op 28-08-2017 11:58 ]
https://niels.nu
Je zult je verbazen over hoeveel sneller de fiets is dan de auto (of het OV) in grote stedenHydra schreef op maandag 28 augustus 2017 @ 11:55:
[...]
Beetje zoals dat je een fiets kunt zien als directe concurrent voor een auto
Met een auto kom je nog wel de stad door, met de fiets op vakantie naar zuid-frankrijk of een Ikea kast ophalen is een grotere uitdaging.ThomasG schreef op maandag 28 augustus 2017 @ 11:57:
Je zult je verbazen over hoeveel sneller de fiets is dan de auto (of het OV) in grote steden
Het was overigens een 100% bewuste steek-onder-water naar alle .Net core fans hier
[ Voor 6% gewijzigd door Hydra op 28-08-2017 12:00 ]
https://niels.nu
Het is zoals met alles, je moet zoeken naar the best tool for the job. Dat hangt af van wat je er mee wilt bereiken, maar ook welke kennis er al in huis is, wat je wilt investeren, etc. Dat is voor iedere situatie anders.Hydra schreef op maandag 28 augustus 2017 @ 11:59:
[...]
Met een auto kom je nog wel de stad door, met de fiets op vakantie naar zuid-frankrijk of een Ikea kast ophalen is een grotere uitdaging.
Het was overigens een 100% bewuste steek-onder-water naar alle .Net core fans hierMaar goed; C# is en blijft een mooie taal. Het is geen PHP ofzo.
Nu staat .NET Core nog in de kinderschoenen, maar het heeft veel potentie. Vooral als je er "taalkundig" naar kijkt, dan vind ik C# beter dan Java; omdat het bijvoorbeeld een aantal irritante ontwerpfouten (of zoals ze het zelf noemen, design keuzes) van Java niet heeft.
Mijn ervaring is dat de switch even doorbijten maar het wel waard is, je bent ongeveer een 1 a 2 werk-weken bezig met de port van een MVC project. Het enige nadeel is is dat je vaak en veel te snel nog "oude troep" (4.5 framework) importeert waardoor je oud en nieuw door elkaar gebruikt. Het gebeurd iets te gemakkelijk dat ik ergens per ongeluk System.Web gebruik in plaats van een AspNet (core) library. Het enige wat je echt merkt is de ASP.NET functionaliteit die qua API grondig is aangepakt. Echter steekt die wel naar mijn mening veel beter in elkaar, zo heb je bijvoorbeeld nu degelijke DI en zit je niet meer in de knoop met je unit tests als je ergens de HttpContext aanroept en de startup is veel overzichtelijker (als je het netjes opsplitst) met alle fluent add's die je doet.
Zeker met de Release van 2.0 is Core simpelweg de way to go voor web, alleen de documentatie moet nog vooral voor 3de partij projecten aangepast worden en/of moet er simpelweg ondersteuning komen (denk aan IdentityServer 4) waardoor ik niet alles nu meteen ga upgraden.
Privé met de micro-services in containers is er eigenlijk geen andere optie dan Core (als je .Net wilt), de full framework containers zijn ontzettend groot (10 gig per container
Ik zou verder nog niemand aanraden om nu naar 2.0 te gaan totdat er een LTS variant van is. ik zou nu nog even bij 1.1 blijven, ik denk ook dat je als .NET developer je mindset anders moet hebben dan in de voorgaande jaren, je zit met Core simpelweg in de "bleeding-edge" te werken en niet meer in het oude vertrouwde 4.x tijdperk. Resharper is bijvoorbeeld ook vrij traag telkens met updates (ook met typescript bijvoorbeeld) daarom gebruik ik het niet meer (naast dat het ook mij eerder vertraagd dan helpt

En voor de mensen die .NET standard verder niet snappen:
https://docs.microsoft.co...net/standard/net-standard
Ik denk niet dat .Net Core van de grond gaat komen. Deze move naar open source is minimaal 10 jaar te laat. MS heeft te lang het "open source is kut" verhaal volgehouden en nu ze echt inzien dat ze dat stuk verloren hebben gaan ze alsnog maar stukjes en beetjes open sourcen. Ik ga MS op OS vlak pas serieus nemen als ze echt de stap maken Windows te open sourcen.ThomasG schreef op maandag 28 augustus 2017 @ 12:06:
Nu staat .NET Core nog in de kinderschoenen, maar het heeft veel potentie. Vooral als je er "taalkundig" naar kijkt, dan vind ik C# beter dan Java; omdat het bijvoorbeeld een aantal irritante ontwerpfouten (of zoals ze het zelf noemen, design keuzes) van Java niet heeft.
Wat betreft de taal geef ik je niet perse ongelijk: C# heeft een hoop geleerd van de fouten die Java gemaakt heeft. Met Java 7 en daarvoor had C# als taal ook mijn voorkeur. Met Java 8, helemaal samen met Lombok, heb ik die voorkeur niet meer. En wat belangrijker is, is dat het ecosysteem van Java een enorm eind voorligt.
Maarja, misschien zit ik er wel helemaal naast. We gaan 't wel zien. Concurrentie is hoe dan ook gezond.
https://niels.nu
Zoals gezegd had je het (oude) .Net full. Daarnaast was er mono. Nu is er een eigen nieuwe MS platform genaamd .NET Core, welke multiplatform is en opensource. Eigenlijk wordt mono voor webdevelopment compleet buitenspel gezet en voor desktop komt dat ook vanzelf wel een keer.Alex) schreef op maandag 28 augustus 2017 @ 09:12:
Ik moet eerlijk bekennen dat ik de weg een beetje kwijt ben als het aankomt op .NET. Wat is nou het verschil tussen .NET Core, Standard, full framework, enzovoorts?
.Net standard is een standaard waar alle verscijllende runtime/platformen zoals .NET core, .NET (full) framework, xamarin, mono en windows phone en nog wat anderen aan voldoen. Als je targer tegen de standaard dan zou, in theorie, de applicatie moeten werken (na opnieuw compilen) op al deze platformen. Een tabelletje kan je hier vinden: https://docs.microsoft.co...net/standard/net-standard
Dat bedoel ik dus niet. Dat versie 'nieuw' aandeel overneemt van versie 'oud' is niet meer dan logisch.Caelorum schreef op maandag 28 augustus 2017 @ 13:11:
.Net core komt zeker wel van de grond. Al is het alleen maar omdat anders alle bedrijven die in .net full hebben geinvesteerd naar iets compleet anders zouden moeten overstappen.
https://niels.nu
Dat zou je zeggen, maar is zeker lang niet altijd het geval. Je kan het ook moeilijk een nieuwe versie noemen met de wijzigingen die zijn doorgevoerd.Hydra schreef op maandag 28 augustus 2017 @ 13:39:
[...]
Dat bedoel ik dus niet. Dat versie 'nieuw' aandeel overneemt van versie 'oud' is niet meer dan logisch.
Maar volgens mij is van de grond komen nog steeds dat er een zeker marktaandeel wordt behaald waarbij de community zichzelf in stand kan houden en het blijft groeien en volgens mij voldoen ze daar zeker aan.
Maar wat is jouw definitie van 'van de grond afkomen' dan?
Met andere woorden, gaan er nu mensen overstappen van Java naar .Net Core?
[ Voor 11% gewijzigd door .oisyn op 28-08-2017 13:45 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Overigens is er sowieso weinig overstap tussen Java en talen als c# en vb.net lijkt me. Daarvoor zijn de mogelijkheden gewoon te vergelijkbaar en niemand heeft zin om tijd te investeren om vervolgens er niets mee op te schieten.
Maar van andere platformen is inderdaad de vraag, maar interessanter lijkt het me om te kijken naar het aandeel in overstappen die wisselen van framework
Nou wat Oisyn zei dusCaelorum schreef op maandag 28 augustus 2017 @ 13:51:
Ah dat was niet de bedoeling. Ik vroeg me gewoon af wat hij nou bedoelde.
Want .Net Core is heel leuk voor de .Net wereld (het is natuurlijk ook spannend eindelijk eens met Docker aan de slag te kunnen
https://niels.nu
Er was en is natuurlijk nog steeds wel een goede reden om naar Java te gaan. Als je cross-platform desktop applicaties wil maken en een highlevel taal wilt gebruiken, dan zal je wel moeten, want anders moet je met een draak van een mono gaan lopen klooien (met de redelijk ruk-tooling daaromheen).Hydra schreef op maandag 28 augustus 2017 @ 13:54:
[...]Want .Net Core is heel leuk voor de .Net wereld (het is natuurlijk ook spannend eindelijk eens met Docker aan de slag te kunnen) maar het doel van MS is natuurlijk om niet vooruit gestreefd te worden door de rest van de wereld. Ik ken (ik geef toe; selection bias) meer projecten waarbij ze van .Net naar Java gegaan zijn dan andersom.
Voor webapplicaties was dit ook het geval tot .Net Core 1.1, bij die release heb ik iig gemerkt dat het echt aan het oppakken was. Of het echt blijft aanhouden is natuurlijk de vraag, maar dat ligt denk ik 100% aan de inzet/houding van Microsoft, want het platform is best interessant en je merkt gewoon dat de houding van ontwikkelaars van andere platformen ook wat meer open is geworden. Maar het blijft een jong platform wat redelijk in ontwikkeling is en dus niet zo stabiel in landschap is als bijv. java, het oude .net framework of php en alles daaromheen.
Mijn ervaring is juist dat de laatste tijd de overstap word gemaakt van Java naar .Net (ook selection bias natuurlijk bij mij). .NET Core is voor veel bedrijven wel interessant omdat Oracle support vergeleken met Microsoft support echt belachelijk duur is. En als het dan ook nog cross platform word dan is dat helemaal aantrekkelijk natuurlijk. Maar het is allemaal nog vrij vroeg om te zeggen imo. We gaan het zien over een paar jaar.Hydra schreef op maandag 28 augustus 2017 @ 13:54:
[...]
Nou wat Oisyn zei dus
Want .Net Core is heel leuk voor de .Net wereld (het is natuurlijk ook spannend eindelijk eens met Docker aan de slag te kunnen) maar het doel van MS is natuurlijk om niet vooruit gestreefd te worden door de rest van de wereld. Ik ken (ik geef toe; selection bias) meer projecten waarbij ze van .Net naar Java gegaan zijn dan andersom.
Nothing to see here!
Soms vind ik wel dat hij een punt heeft, maar heel vaak bekruipt me het gevoel dat het niet onderbouwd is en iemand is met "an axe to grind"
Al eens gelezen. Veel van zijn punten komen helemaal niet uit scrum of agile maar zijn gewoon slechte keuzes die je ook zou hebben bij elke andere methode.Tarkin schreef op maandag 28 augustus 2017 @ 15:03:
iemand https://michaelochurch.wo...ially-scrum-are-terrible/ al eens gelezen?
Soms vind ik wel dat hij een punt heeft, maar heel vaak bekruipt me het gevoel dat het niet onderbouwd is en iemand is met "an axe to grind"
Nothing to see here!
Support waarop?Rutix schreef op maandag 28 augustus 2017 @ 14:56:
Mijn ervaring is juist dat de laatste tijd de overstap word gemaakt van Java naar .Net (ook selection bias natuurlijk bij mij). .NET Core is voor veel bedrijven wel interessant omdat Oracle support vergeleken met Microsoft support echt belachelijk duur is.
Die knakker is 'beroemd' in de US omdat hij het voor elkaar heeft gekregen dat vrijwel alle grote software bedrijven hem niet meer moeten. Het is nogal een moeilijke persoon. En daar zit 'ie dan hele tirades over te schrijven; dat hij op een SV 'blacklist' staat.Tarkin schreef op maandag 28 augustus 2017 @ 15:03:
iemand https://michaelochurch.wo...ially-scrum-are-terrible/ al eens gelezen?
Niks van wat die kerel schrijft sla ik ook maar ene acht op. Een kapotte klok staat altijd nog twee keer per dag op de goeie tijd.
Je moet voor de gein eens een discussie met 'em aangaan op Reddit. Hij spoort niet.
Er zijn hordes 'developers' die op Scrum zitten te zeiken zonder in te zien dat de problemen die Scrum aan 't licht brengt vooral veroorzaakt worden door slecht management. Scrum is hier niet de oorzaak maar de 'messenger'. Oftewel sterk staaltje "shooting the messenger".Rutix schreef op maandag 28 augustus 2017 @ 15:06:
Al eens gelezen. Veel van zijn punten komen helemaal niet uit scrum of agile maar zijn gewoon slechte keuzes die je ook zou hebben bij elke andere methode.
[ Voor 62% gewijzigd door Hydra op 28-08-2017 15:15 ]
https://niels.nu
Tarkin schreef op maandag 28 augustus 2017 @ 15:03:
iemand https://michaelochurch.wo...ially-scrum-are-terrible/ al eens gelezen?
Soms vind ik wel dat hij een punt heeft, maar heel vaak bekruipt me het gevoel dat het niet onderbouwd is en iemand is met "an axe to grind"
Dit liet mij wel even gniffelen...Atomized user stories aren’t good for engineers’ careers. By age 30, you’re expected to be able to show that you can work at the whole-project level, and that you’re at least ready to go beyond such a level into infrastructure, architecture, research, or leadership.
En door zijn rant over 'business-driven engineering' komt hij op mij vooral over als iemand die denkt dat devs (en vooral hijzelf) ver verheven zijn boven dingen als multidisciplinair samenwerken. Dat gecombineerd met zijn rant over het te kleine verschil tussen junior en senior laat hem op mij overkomen als een bijzonder arrogant persoon die denkt dat zijn werkgever en zijn collega's enkel bestaan zodat hij plezier kan hebben met programmeren.
De comments zijn soms ook bedenkelijk
Tuurlijk ben je het met hem eens. Een combinatie van scrum en niet met je tijd meegaan betekent dat je als 'middle management' gewoon thuis komt te zitten. En da's natuurlijk niet je eigen schuld.
Wat ik mooi vindt aan goed geimplementeerde Scrum is dat het heel duidelijk maakt wie er in je team geen fuck doet.
https://niels.nu
Mensen die geen manager in hun functietitel hebben staan kunnen toch ook helemaal niet zelfstandig nadenkenHydra schreef op maandag 28 augustus 2017 @ 19:10:
En daar zie je ook massa's oude uitgerangeerde projectmanagers het heel stellig met 'em eens zijn.
Tuurlijk ben je het met hem eens. Een combinatie van scrum en niet met je tijd meegaan betekent dat je als 'middle management' gewoon thuis komt te zitten. En da's natuurlijk niet je eigen schuld.
Grappig genoeg word dat in de genoemde rant (en bijna elke andere scrum rant) als groot nadeel genoemd. Want men zou maar inzien dat jij niet de onmisbare codegod bent...Wat ik mooi vindt aan goed geimplementeerde Scrum is dat het heel duidelijk maakt wie er in je team geen fuck doet.
hmm, dat is wel een interessante. Zou bewijsdrang iets developer specifiek zijn? Hebben 'wij' developers daar meer last van dan anderen? Interessante vraag.RagingPenguin schreef op maandag 28 augustus 2017 @ 19:29:
[...]
Grappig genoeg word dat in de genoemde rant (en bijna elke andere scrum rant) als groot nadeel genoemd. Want men zou maar inzien dat jij niet de onmisbare codegod bent...
Dit topic is gesloten.
Dit topic is niet de plaats om te lopen helpdesken. De Coffee Corner is primair bedoeld als uitlaatklep voor iedereen in de Devschuur® en niet als vraagbaak.