De Devschuur Coffee Corner - Iteratie ⓬

[alienfruit]

Vorige week bezig geweest met Hangfire moet zeggen dat het aardig werkt! Nu is de roddel van HoE dat een ander team een licentie heeft voor Hangfire en dat we meer leuks kunnen gebruiken. Alleen de Engineering Teams-groep is doodstil als je er over begint lol.

Leuk yoh, die silo's op het werk... Kwam er ook achter dat ons team nagenoeg hetzelfde aan het bouwen zijn dat een andere tak ook aan het bouwen is. En zij zijn er al een jaar mee bezig terwijl wij MVP af moeten hebben half februari (begonnen in Oktober).

[ Voor 27% gewijzigd door alienfruit op 24-12-2019 00:03 ]

[Koenvh]

alienfruit schreef op dinsdag 24 december 2019 @ 00:01:
[...]

Leuk yoh, die silo's op het werk... Kwam er ook achter dat ons team nagenoeg hetzelfde aan het bouwen zijn dat een andere tak ook aan het bouwen is. En zij zijn er al een jaar mee bezig terwijl wij MVP af moeten hebben half februari (begonnen in Oktober).

Hoe kom je daar nu achter, en hoe is niemand anders daar eerder achter gekomen? Of wordt één van de twee takken in de toekomst uitgefaseerd, en is dit een soort gladiatorenduel?

[alienfruit]

Wij zitten in de Corporate Banking en zij zitten in Private Banking tak. Onze Product Manager kwam er achter maar onze bazen wisten er blijkbaar niet vanaf. Handig is het wel want zij hebben al over de verschillende edge cases nagedacht

[armageddon_2k1]

Zojuist het meest bizarre gesprek van de afgelopen jaren aan de telefoon. M'n persoonlijke telefoon (dus niet zakelijke) ging af met een nummer dat ik niet ken.

Ik werk bij bedrijf X, de beller bij Y.

• Y: Hi @armageddon_2k1 (mijn naam dus), we hadden om 10 uur een meeting. Waarom ben je er niet? We zitten allemaal op je te wachten.
• Ik: Wat? Wie ben jij? Waarover?
• Y: Wat!? De koppeling met Bedrijf X
• Ik: Welke koppeling?
• Y: Met ons!? Je reageerde ook al niet op de uitnodiging. Dit kan echt niet hoor.
• Ik: Wie zijn jullie!?
• Y: Jij bent toch @armageddon_2k1?
• Ik: Ja, wie ben jij dan?
• Y: Pietje. Maar jij werkt hier toch?
• Ik: Nee vriend, ik werk bij Bedrijf X.
• Y: Oh... vaag. Kan je langskomen?
• Ik: Nee.
• Y: Jammer, want je bent wel nodig.
• Ik: Vriend. Ik weet niet wie je bent en je hebt mijn prive-nummer en je denkt dat ik bij je werk. Ik ben even aan het verwerken wat er aan de hand is.
• Y: Ja het is wel vaag ja.
• Ik: Ik ga nu ophangen....
• Y: Okee

Wat?

[Giesber]

armageddon_2k1 schreef op dinsdag 24 december 2019 @ 10:35:
Zojuist het meest bizarre gesprek van de afgelopen jaren aan de telefoon. M'n persoonlijke telefoon (dus niet zakelijke) ging af met een nummer dat ik niet ken.

Ik werk bij bedrijf X, de beller bij Y.

[...]


Wat?

Dat wordt helaas geen aflevering van Banana Split volgende week .

[armageddon_2k1]

Ben erachter wat er gebeurd is.

- Het is een klant van ons welke SSO hebben naar ons pakket.
- In de toekomst willen ze uitgebreider met ons koppelen middels onze API
- Ze verwachtten dat wij daar support voor moeten leveren
- Hun projectleider heeft zeer proactief mij opgezocht op LinkedIn en heeft alvast doorgegeven aan hun IT dat ik een account binnen hun SSO moet hebben om het debuggen makkelijk te maken.
- Die projectleider kan blijkbaar via LinkedIn mijn telefoonnr ophalen en heeft dat aan IT doorgegeven
- IT heeft doorgegeven aan de projecleider dat ik toegevoegd ben aan hun AD en een emailadres heb
- Projectleider had het te druk en heeft project overgedragen. Bij overdracht was ik 'onderdeel van het team'.
- Mailtjes worden naar mijn nieuwe adres gestuurd.
- En nu zijn we hier aanbeland.

Intrigerend. Wel fokking irritant.

[.oisyn]

Sowieso apart dat ze verwachten dat je er bent terwijl je nooit op de uitnodiging hebt gereageerd

[armageddon_2k1]

.oisyn schreef op dinsdag 24 december 2019 @ 11:57:
Sowieso apart dat ze verwachten dat je er bent terwijl je nooit op de uitnodiging hebt gereageerd

Ach, zo ging het bij mijn vorige werkgever ook. Gewoon een Outlook meeting de deur uitgooien en de projectleider had z'n werk weer gedaan.

[Matis]

armageddon_2k1 schreef op dinsdag 24 december 2019 @ 13:50:
Ach, zo ging het bij mijn vorige werkgever ook. Gewoon een Outlook meeting de deur uitgooien en de projectleider had z'n werk weer gedaan.

Herkenbaar. Bij mijn vorige werkgever hadden we ook zo'n projectmanager. Die plande altijd meetings in wanneer het hém uitkwam. Zonder te kijken of de rest van de genodigden wel kon. Ik wees altijd netjes de meetings af als ik al wat had staan.
Kreeg ik regelmatig een pissige reactie terug dat ik de andere meeting maar moest verzetten

[Lethalis]

Bizar verhaal idd @armageddon_2k1

Ik hoor al een paar dagen niks van mijn werk *fingers crossed* dat het zo blijft

Nu nog zelf een beetje afkicken ervan. Gisterochtend zat ik toch mijn mail te lezen in de vakantie en nog wat dingen uit te zoeken... maar daarna niet meer. Nu ben ik vooral aan het hobby-en.

En met de kerst heb ik het zometeen zo druk met familiebezoeken e.d. dat ik even helemaal afkick van de computer Is ook wel hard nodig.

Gewoon even bij mijn gezin zijn. Misschien moet ik voor volgend jaar mezelf wat meer een 9 tot 5 mentaliteit aanmeten en de boel gewoon de boel laten (als het tijdens werktijd niet lukt, jammer dan). En als ik het niet kan laten om 's avonds achter die computer te kruipen, dat dan vooral voor mezelf doen om te pielen met iets dat ik leuk vind, en niet om te werken.

Ach ja. Ik begin alweer met goede voornemens haha. Nu nog gaan sporten lol.

Fijne kerst alvast allemaal

[mcDavid]

armageddon_2k1 schreef op dinsdag 24 december 2019 @ 10:35:
Zojuist het meest bizarre gesprek van de afgelopen jaren aan de telefoon. M'n persoonlijke telefoon (dus niet zakelijke) ging af met een nummer dat ik niet ken.

Ik werk bij bedrijf X, de beller bij Y.

[...]


Wat?

Https://reddit.com/r/idontworkherelady

[Koenvh]

Lethalis schreef op dinsdag 24 december 2019 @ 16:15:
[...]

Fijne kerst alvast allemaal

Fijne kerst

Hoeveel printers hebben jullie al mogen repareren deze kerst?

[P-Storm]

Geen. Mijn ouders hebben het wel gevraagd, maar draadloze printers waag ik mij niet aan. Wel het KPN kastje van 720p naar 1080p gezet.

[Hydra]

Koenvh schreef op dinsdag 24 december 2019 @ 23:19:
Hoeveel printers hebben jullie al mogen repareren deze kerst?

Ik doe geen techsupport. Het is gewoon mijn werk niet, en ik gebruik zelf geen Windows en weet er dus ook niks van. Daarbij heeft de familie geld zat om de lokale computerboer te ondersteunen en ik gun die man natuurlijk ook een fijne kerst

[Matis]

Pfff, uitgerekend vandaag bricked mijn RPi met daarop Kodi/OSMC

[R4gnax]

Koenvh schreef op dinsdag 24 december 2019 @ 23:19:
[...]


Fijne kerst

Hoeveel printers hebben jullie al mogen repareren deze kerst?

Geen. Maar ik heb wel op de valreep nog de power-button op mijn thuis-PC kunnen laten vervangen.
Kast was eind afgelopen week om ca. 6:45u in de ochtend beland in een oneindige startup->shutdown->startup->shutdown cycle, om de 2 à 3 minuten.

Echt heh.

Wist eigenlijk wel meteen dat het die knop moest zijn, maar zelf helaas niet het gereedschap of de reserve-onderdelen. Gelukkig is er hier nog zo'n computer-shop van de oude stempel in de buurt; zo'n echt goede waar ze custom werk doen. Halverwege de dag af laten gooien en 20 EUR later op dezelfde dag nog een nieuwe schakelaar erin; helemaal netjes. Goeie service voor zo'n kleine prijs.

[NMe]

Koenvh schreef op dinsdag 24 december 2019 @ 23:19:
[...]

Hoeveel printers hebben jullie al mogen repareren deze kerst?

Ik ga morgen naar mijn ouders. Is altijd een beetje 50-50 of ik hun printer weer op een van hun twee WiFi-netwerken moet aansluiten of niet. Waarom ze er twee hebben? Geen idee, maar blijkbaar wil mijn moeder dat.

Ik ga wanneer deze een beetje lekker leverbaar is en wanneer er daar wat reviews van te vinden zijn wel uit eigen beweging met een printer spelen, maar dat is vast niet wat je bedoelde.

[Sebazzz]

Ik drop dit hier gewoon even

https://www.brunel.nl/nl-...n-telecom/c-net-developer

[Voutloos]

Je zou het een klein beetje geforceerd kunnen noemen.

Maar de vacature valt blijkbaar wel op, dus gezien de huidige markt is het dan misschien wel perfect geschreven.

[kenneth]

Die Hello, world was grappig, daarna ging het bergafwaarts. Maar, wat @Voutloos zegt.

[bwerg]

armageddon_2k1 schreef op dinsdag 24 december 2019 @ 13:50:
[...]


Ach, zo ging het bij mijn vorige werkgever ook. Gewoon een Outlook meeting de deur uitgooien en de projectleider had z'n werk weer gedaan.

Ah ja, die uitnodigingen. Leuk, maar ik heb geen outlook-meeting-compatibele client. Je kunt ze nog wel in plaintext openen en dan staat ergens in een niet al te leesbare encoding wel verstopt waar en wanneer het is, maar als ze verwachten dat ik allemaal dingen ga invullen stuur ik doorgaans gewoon een mailtje terug. Zie maar hoe je het in je agenda krijgt.

Niet heel gek dat ik ze krijg, trouwens. Als je vanuit de universiteit wat dingen bij een bedrijf doet hoor je er bij maar toch ook weer niet, dus ik snap wel dat mensen geen tijd hebben om na te gaan denken over hoe dingen dan precies het beste gecommuniceerd kunnen worden. Of over dat er überhaupt mensen zijn die wel een account binnen het bedrijf hebben, maar die alles lekker helemaal anders doen dan in datzelfde bedrijf.

Al is .ics nou ook weer niet zo heel exotisch, geloof ik, maar mijn client heeft er nou eenmaal geen support voor en voor die twee invitations per jaar ga ik er geen moeite voor doen.

[ Voor 33% gewijzigd door bwerg op 29-12-2019 22:02 ]

[RayNbow]

bwerg schreef op zondag 29 december 2019 @ 21:54:
Al is .ics nou ook weer niet zo heel exotisch

Ach, een formaatje uit '98 dat tien jaar geleden eens is bijgewerkt...

[Koenvh]

RayNbow schreef op maandag 30 december 2019 @ 06:18:
[...]

Ach, een formaatje uit '98 dat tien jaar geleden eens is bijgewerkt...

In vergelijking met e-mail nog zeer nieuwerwets

[armageddon_2k1]

Nu in de rustige daagjes rond kerst en oud- en nieuw lekker met wat uitgestelde dingetjes bezig. Ook lekker aan het rondneuzen naar nieuwe technieken.

Ben nu even in GatsbyJS gedoken, maar godnondeju, dat is toch wel erg leuk hoor. Statische site generator on steroids.

[ Voor 7% gewijzigd door armageddon_2k1 op 30-12-2019 14:24 ]

[CurlyMo]

Ik ben hier aan het kijken naar Reactive Programming. Mooie samensmelting van wat bekende design patterns en functioneel programmeren. Als imperatief C programmeur niet perse makkelijke kost

[armageddon_2k1]

@CurlyMo Nee, dat kan ik me voorstellen. Is een hele andere manier van denken. Welke taal gebruik je nu daarvoor?

Als hobbyprojectje ben ik nu in Kotlin een multiplatform ding aan het bouwen die ik zo reactive mogelijk wil maken. Oftewel:
- Kotlin JVM op backend
- Kotlin JS frontend en webworkers
- Eventstore / CQRS mechanisme
- Coroutines en websockets voor reactiviteit en doorsturen events

Vooralsnog werkt het redelijk. Maar Kotlin/JS was pijnlijk. Moeilijk om up en running te geraken en documentatie is erg matig. Uiteindelijk heb ik het goed aan de praat. Het helpt wel dat Jetbrains Kotlin/JS aardig aan het dogfooden is met hun nieuwe applicatie Space.

Daarnaast zijn coroutines voor Kotlin/JS totale overkill omdat JS in browser sowieso single-threaded is en je daar al allemaal promise en async/await constructies hebt.

[ Voor 11% gewijzigd door armageddon_2k1 op 30-12-2019 14:46 ]

[CurlyMo]

armageddon_2k1 schreef op maandag 30 december 2019 @ 14:45:
@CurlyMo Nee, dat kan ik me voorstellen. Is een hele andere manier van denken. Welke taal gebruik je nu daarvoor?

Ik was vrij begaafd met imperatief Javascript, maar sinds ES6 met zijn functionele aspecten minder. Het is wel een mooie manier om de functionele gedachtegang te leren begrijpen in een taal die ik imperatief al ken.

Daarnaast wordt er op het werk R-shiny gebruikt.

Voor mezelf zoek ik naar een effectieve manier om voor mijn C applicatie een web frontend te maken die super modulair is. De modules zelf zijn grotendeels in Lua waarbij mijn applicatie een API biedt in de vorm van Lua functies. Nu zoek ik dus een manier om het GUI gedeelte beter te krijgen.

Volledig reactive gaat het niet worden, maar de lessen eruit kan ik wel meenemen naar mijn C opgave.

[F.West98]

Ik heb ook eindelijk weer eens tijd om wat te hobbyen, verder gaan met een projectje dat ik deze zomer gestart was. Lekker modern: .NET Core met EF Core, alles in Docker en cross-platform. Nu wil ik iets van model normalization/formatting doen vóór de validation, dus ik Googlen, kom ik op SO precies tegen wat ik zoek: https://stackoverflow.com...ation-in-asp-net-core-2-0
Blijkt het een vraag (zonder overtuigend antwoord) te zijn van onze eigen @RobIII What are the odds

[Matis]

F.West98 schreef op maandag 30 december 2019 @ 15:04:
What are the odds

100%

[R4gnax]

F.West98 schreef op maandag 30 december 2019 @ 15:04:
Ik heb ook eindelijk weer eens tijd om wat te hobbyen, verder gaan met een projectje dat ik deze zomer gestart was. Lekker modern: .NET Core met EF Core, alles in Docker en cross-platform. Nu wil ik iets van model normalization/formatting doen vóór de validation, dus ik Googlen, kom ik op SO precies tegen wat ik zoek: https://stackoverflow.com...ation-in-asp-net-core-2-0
Blijkt het een vraag (zonder overtuigend antwoord) te zijn van onze eigen @RobIII What are the odds

Mocht je dat overtuigende antwoord nog nodig hebben; dat gaat moeilijk worden.
Is er gewoon niet.

Wel kan ik je het volgende meegeven:

ModelBinderAttribute heeft in ASP.NET Core schijnbaar ook AttributeTargets.Property, dus je kunt de te gebruiken model binder nu per individuele property instellen.

Vanaf daar moet het redelijk te doen zijn om een custom binder te schrijven die voor de te normaliseren properties op je model, delegeert naar de 'normale' binder voor de bulk van het werk en dan voordat de waarde daadwerkelijk gefinaliseerd op je model gezet wordt, nog een laatste conversie/normalisatie-slag doet.

MS zelf geeft als advies wel om voor conversie-doeleinden niet de ModelBinder te gebruiken, maar een TypeConverter. Maar dat is nogal limiterend: het vereist dat je ook daadwerkelijk van type wisselt. Vaak is dat niet het geval. Bijv. als je enkel wat strings wilt sanitizen.

Beter wellicht om iets te implementeren zoals een ProjectionBinder<T> where T: IBinderProjection en dan de normalisatie-slag consistent te implementeren middels die interface. De ProjectionBinder zelf kan bij het delegeren naar de onderliggende binder een verse ModelState dictionary meegeven, zodat validation state niet meteen door propageert naar het hele model.

Kun je mooi zoiets doen:

C#:

[ModelBinder(typeof(ProjectionBinder<PhoneNumberSanitization>))]
public string PhoneNumber { get; set; }

En maak daarnaast bijv. nog een versie met twee generic parameters als je de binder waarnaar gedelegeerd moet worden ook expliciet moet meegeven.


Een heel andere mogelijkheid is wellicht om iets met een eigen ValueProvider te gaan doen.
Maar dat is nog een paar tandjes verder naar beneden in het binding framework, en zeker niet makkelijker goed in elkaar gezet te krijgen.

[ Voor 17% gewijzigd door R4gnax op 30-12-2019 16:32 ]

[F.West98]

R4gnax schreef op maandag 30 december 2019 @ 16:22:
[...]


Mocht je dat overtuigende antwoord nog nodig hebben; dat gaat moeilijk worden.
Is er gewoon niet.

Wel kan ik je het volgende meegeven:

ModelBinderAttribute heeft in ASP.NET Core schijnbaar ook AttributeTargets.Property, dus je kunt de te gebruiken model binder nu per individuele property instellen.

Vanaf daar moet het redelijk te doen zijn om een custom binder te schrijven die voor de te normaliseren properties op je model, delegeert naar de 'normale' binder voor de bulk van het werk en dan voordat de waarde daadwerkelijk gefinaliseerd op je model gezet wordt, nog een laatste conversie/normalisatie-slag doet.

MS zelf geeft als advies wel om voor conversie-doeleinden niet de ModelBinder te gebruiken, maar een TypeConverter. Maar dat is nogal limiterend: het vereist dat je ook daadwerkelijk van type wisselt. Vaak is dat niet het geval. Bijv. als je enkel wat strings wilt sanitizen.

Beter wellicht om iets te implementeren zoals een ProjectionBinder<T> where T: IBinderProjection en dan de normalisatie-slag consistent te implementeren middels die interface. De ProjectionBinder zelf kan bij het delegeren naar de onderliggende binder een verse ModelState dictionary meegeven, zodat validation state niet meteen door propageert naar het hele model.

Kun je mooi zoiets doen:

C#:

[ModelBinder(typeof(ProjectionBinder<PhoneNumberSanitization>))]
public string PhoneNumber { get; set; }

En maak daarnaast bijv. nog een versie met twee generic parameters als je de binder waarnaar gedelegeerd moet worden ook expliciet moet meegeven.


Een heel andere mogelijkheid is wellicht om iets met een eigen ValueProvider te gaan doen.
Maar dat is nog een paar tandjes verder naar beneden in het binding framework, en zeker niet makkelijker goed in elkaar gezet te krijgen.

Wauw, bedankt voor het uitgebreide antwoord! Ik wou het sowieso wat generieker gaan opzetten zodat ik het eventueel als lib kan uitbrengen uiteindelijk. Ik heb het nu ook al gekoppeld aan de jQuery unobstrusive validation, waar ik een laag heb gemaakt die uiteindelijk delegeert naar de jQuery Validator normalizers. Dus dan zou het netjes in de front-end en back-end geregeld zijn.
Dan nog iets verzinnen voor de output formatting.

[armageddon_2k1]

Ben ik nou gek als ik zie dat voor de sanitation van een telefoonnr, zoals bij Rob, er hele threads opgespind worden (bij SO) of er allemaal annotations bij moeten komen ik dat een beetje overkill vind? Of mis ik een complete use case?

[BladeSlayer1000]

Ik heb deze vakantie besteed om mijn PC opnieuw te installeren, en tevens daarbij mijn development omgeving aan te vernieuwen en een orde te scheppen in de chaos die er was.

[R4gnax]

armageddon_2k1 schreef op maandag 30 december 2019 @ 16:49:
Ben ik nou gek als ik zie dat voor de sanitation van een telefoonnr, zoals bij Rob, er hele threads opgespind worden (bij SO) of er allemaal annotations bij moeten komen ik dat een beetje overkill vind? Of mis ik een complete use case?

Je mist een complete use-case; de case waar je in je input flow data normalisatie een specifieke plek wilt geven voordaat validators draaien, zodat je validators generiek zijn en niet als leaky abstractions zich bewust moeten zijn van evt. aanwezige sanitizations die per scenario verschillend kunnen zijn en die wel/niet door de validator toegelaten moeten zijn omdat aangenomen wordt dat ze later nog rechtgetrokken worden. (Gruwel...)

Telefoonnummers zijn wat dat betreft een goed voorbeeld; want er zijn veel verschillende manieren om die dingen te representeren, waarvan je er liefst één als canon neemt om een validator tegen te schrijven.

Echter, in een knap staaltje domheid heeft Microsoft in ASP.NET MVC al sinds de allereerste releases het draaien van model validators direct gekoppeld zitten aan het data-binden van de ruwe data aan een input model instance. Je moet bij wijze van met een breekijzer aan de gang omdat los te krijgen en er iets tussen te zetten wat dit af kan handelen, door zelf model binders - of erger: value providers - te gaan implementeren.

Enige andere werkbare manier is om voor bijv. telefoonnummers een toegespitste PhoneNumber class te maken met een eigen ModelBinder die simpelweg een PhoneNumber.Parse( ... ) doet; bij falen ook een instance retourneert met een failure state er op gezet, en die zijn eigen validator implementeert middels de IValidatibleObject interface om adhv die failure state alarm te slaan met het correcte type validatie-fout.

Dat is een heleboel concerns op één hoop gooien en je input model, wat idealiter een simpele POCO is, business-aware maken. En het is ook nog eens een heel, heel lelijk geval van failure state encoderen in success state. Bah!

[ Voor 28% gewijzigd door R4gnax op 30-12-2019 20:25 ]

[armageddon_2k1]

Allemachtig. Geeft de nadelen van een monolithisch allesomvattend framework weer mooi aan.

[cracking cloud]

Gelukkig is er fluentvalidation.net

[Mercatres]

F.West98 schreef op maandag 30 december 2019 @ 15:04:
Ik heb ook eindelijk weer eens tijd om wat te hobbyen, verder gaan met een projectje dat ik deze zomer gestart was. Lekker modern: .NET Core met EF Core, alles in Docker en cross-platform. Nu wil ik iets van model normalization/formatting doen vóór de validation, dus ik Googlen, kom ik op SO precies tegen wat ik zoek: https://stackoverflow.com...ation-in-asp-net-core-2-0
Blijkt het een vraag (zonder overtuigend antwoord) te zijn van onze eigen @RobIII What are the odds

Haha, ik kwam die vraag ook enkele weken geleden tegen. Zelfde setting, zelfde issue. Meestal let ik niet zo op de naam van de poster, maar nu viel er me ook iets op.

[kenneth]

Het is 2020 en het gebeurt nog steeds dat ik een melding van God mag weten welke applicatie heb weggeklikt omdat ik aan het typen was terwijl die opeens in mijn gezicht verscheen. Nu nog een ouderwetse focus steal en ik ben er weer van overtuigd dat de triviaalste problemen in software onoplosbaar zijn.

[Sebazzz]

cracking cloud schreef op dinsdag 31 december 2019 @ 11:59:
Gelukkig is er fluentvalidation.net

Die gestopt zijn .NET Framework ("old ASP.NET") te ondersteunen.

[Koenvh]

kenneth schreef op zaterdag 4 januari 2020 @ 09:51:
Het is 2020 en het gebeurt nog steeds dat ik een melding van God mag weten welke applicatie heb weggeklikt omdat ik aan het typen was terwijl die opeens in mijn gezicht verscheen. Nu nog een ouderwetse focus steal en ik ben er weer van overtuigd dat de triviaalste problemen in software onoplosbaar zijn.

Maar heb je nou interesse in onze nieuwsbrief of niet?

[kenneth]

Koenvh schreef op zondag 5 januari 2020 @ 14:06:
[...]

Maar heb je nou interesse in onze nieuwsbrief of niet?

Nee maar ik heb wel mijn AdBlocker uitgezet om je website te steunen. Heus!

[armageddon_2k1]

@Sebazzz Zit even je Return repo te bekijken op GitHub. Leuk projectje! Gebruik het aardig als inspiratie, maar dan voor Clean Architecture, CQRS, Event Sourcing in Kotlin Multiplatform.

[Sebazzz]

armageddon_2k1 schreef op zondag 5 januari 2020 @ 17:29:
@Sebazzz Zit even je Return repo te bekijken op GitHub. Leuk projectje! Gebruik het aardig als inspiratie, maar dan voor Clean Architecture, CQRS, Event Sourcing in Kotlin Multiplatform.

Dank! Ja, ik vond het wel leuk om een project op te zetten met CQRS, een volledig andere architectuur dan ik tot nu toe gewend was. Het voelt soms als overengineering, maar terwijl je tests schrijft blijkt toch dat het de boel eenvoudiger maakt.

[ThomasG]

kenneth schreef op zaterdag 4 januari 2020 @ 09:51:
Het is 2020 en het gebeurt nog steeds dat ik een melding van God mag weten welke applicatie heb weggeklikt omdat ik aan het typen was terwijl die opeens in mijn gezicht verscheen. Nu nog een ouderwetse focus steal en ik ben er weer van overtuigd dat de triviaalste problemen in software onoplosbaar zijn.

Het meest vervelende is dan nog als het dialoogje standaard de Ok button geselecteerd heeft. Dat was (in de Windows XP tijd) altijd zo met Windows Update. Dan kwam ineens het het schermpje in beeld of je nu de updates wilde installeren, maar omdat je zat te typen en daardoor spatie indrukte (wat werkt als een enter/muisklik) sloot de computer af om te updaten

[DeluxZ]

Sebazzz schreef op zondag 5 januari 2020 @ 11:57:
[...]

Die gestopt zijn .NET Framework ("old ASP.NET") te ondersteunen.

Uh...?

Hun FluentValidation.csproj heeft o.a. netstandard1.1 als targetframework.
Hun FluentValidation.Mvc5 heeft net45 als targetframework.
Hun FluentValidation.AspNetCore heeft o.a. netstandard2.0 als targetframework.

NetStandard2.0 heeft ondersteuning voor .NET Framework 4.6.1
NetStandard1.1 heeft ondersteuning voor .NET Framework 4.5

Je kunt dus gewoon Mvc5 package gebruiken voor "(old) ASP.NET"?

[Sebazzz]

DeluxZ schreef op maandag 6 januari 2020 @ 10:39:
[...]
Je kunt dus gewoon Mvc5 package gebruiken voor "(old) ASP.NET"?

Nu nog wel, maar niet voor lang (tenzij je op een unsupported library wilt zitten).

quote: https://fluentvalidation.net/mvc5

Deprecation Notice

Integration with ASP.NET MVC 5 is considered legacy and will not be supported beyond FluentValidation 8.x. For an optimal experience, we suggest using FluentValidtation with ASP.NET Core.

[yinx84]

Zijn er toevallig nog meer mensen bezig met OCP II voor Java 11? Ik ben de Sybex study guide voor Java 8 aan het crunchen, in afwachting van hun Java 11 versie. Die komt pas eind april uit: https://www.amazon.com/gp/product/1119617626

Ben benieuwd hoever ik kan komen met het Java 8 boek i.c.m. Enthuware proefexamens die al wel voor OCP II beschikbaar zijn. De hoeveelheid stampwerk vergeleken met OCA 8 is niet mals in ieder geval...

[ByteMe_]

* ByteMe_ zucht. Een website met een oude Code Igniter versie van 2.0.2 is compleet over de zeik nadat de webhost een upgrade naar PHP 7.1 heeft doorgevoerd. Nu was het al behoorlijk achterhaald en nodig om de code up te daten, maar ik heb zelf weinig kaas gegeten van dit systeem. Nu heb ik 3.1 erop gezet, maar continu blijf ik hangen in 404 pagina's (software kant) Ik dacht dat even de controllers/modules/autoloaden libraries en nog andere zaken instellen voldoende was. Nope. Steeds missende classes en andere dingen.

[Tjolk]

Waarom 3.0 ipv 3.1?

[wackmaniac]

ByteMe_ schreef op woensdag 8 januari 2020 @ 20:03:
* ByteMe_ zucht. Een website met een oude Code Igniter versie van 2.0.2 is compleet over de zeik nadat de webhost een upgrade naar PHP 7.0 heeft doorgevoerd. Nu was het al behoorlijk achterhaald en nodig om de code up te daten, maar ik heb zelf weinig kaas gegeten van dit systeem. Nu heb ik 3.0 erop gezet, maar continu blijf ik hangen in 404 pagina's (software kant) Ik dacht dat even de controllers/modules/autoloaden libraries en nog andere zaken instellen voldoende was. Nope. Steeds missende classes en andere dingen.

Ze zullen die upgrade toch wel gecommuniceerd hebben? Niet in de laatste plaats omdat 7.0 al een jaar end of life is.

[ByteMe_]

Tjolk schreef op woensdag 8 januari 2020 @ 22:07:
Waarom 3.0 ipv 3.1?

Oeps fixed

wackmaniac schreef op donderdag 9 januari 2020 @ 09:08:
[...]


Ze zullen die upgrade toch wel gecommuniceerd hebben? Niet in de laatste plaats omdat 7.0 al een jaar end of life is.

Jup, wel jammer dat dat dan weer pas een poos later naar mij wordt gecommuniceerd (ik help iemand). Goed, ook ik had dan eerder moeten beginnen, het was al veels te oud. Ik heb ook al vaak gezegd dat het nodig kan zijn om de boel te verbouwen en dat we er eens over moeten zitten.

En nu vind ik niet wat er mis is en heb ik ook niet de tijd om heel wat anders op te zetten Tijd voor een externe denk ik.

[ Voor 69% gewijzigd door ByteMe_ op 09-01-2020 09:52 ]

[mcDavid]

wackmaniac schreef op donderdag 9 januari 2020 @ 09:08:
[...]


Ze zullen die upgrade toch wel gecommuniceerd hebben? Niet in de laatste plaats omdat 7.0 al een jaar end of life is.

dat is idd de grooste wtf, hoezo wordt je ge"up"grade naar een verouderde versie?

[ByteMe_]

code:

PHP Version 7.1.33

Niet 7.0, maar nog steeds oud.

Ik moet wel zeggen dat ik hopeloos achterloop met die versies. Mijn eigen projecten zijn nog lang niet up to date, zelfs op het werk lopen we flink achter de feiten aan.

[ Voor 55% gewijzigd door ByteMe_ op 09-01-2020 10:01 ]

[Matis]

mcDavid schreef op donderdag 9 januari 2020 @ 09:48:
dat is idd de grooste wtf, hoezo wordt je ge"up"grade naar een verouderde versie?

Mogelijk heeft het te maken met de onderliggende software van de server welke alleen verouderde versie van PHP (en/of Apache / NGINX) kan draaien.

[ Voor 4% gewijzigd door Matis op 09-01-2020 09:58 ]

[mcDavid]

ByteMe_ schreef op donderdag 9 januari 2020 @ 09:56:

code:

PHP Version 7.1.33

Niet 7.0, maar nog steeds oud.

Ik moet wel zeggen dat ik hopeloos achterloop met die versies. Mijn eigen projecten zijn nog lang niet up to date, zelfs op het werk lopen we flink achter de feiten aan.

7.1 is ook alweer een goeie maand geleden met pensioen gegaan.

Als je toch aan de slag moet om compatibilities te fixen, zou ik je toch echt aanraden gewoon naar een courante versie te updaten. Heel veel verschil zit er niet tussen de 7.* releases, maar het zou toch zonde zijn als je eigenlijk gelijk weer aan de bak moet.

Matis schreef op donderdag 9 januari 2020 @ 09:57:
[...]

Mogelijk heeft het te maken met de onderliggende software van de server welke alleen verouderde versie van PHP (en/of Apache / NGINX) kan draaien.

klinkt als een hostingpartij waar je liever helemaal niet wilt draaien dus

[ZaZ]

Ik zit in de enterprise-wereld en heb nu een klant waar het na jaren er eindelijk 'door' is.
Er is groen licht om te upgraden van Oracle 9 naar Oracle 11 (release date 2009)

[gekkie]

ZaZ schreef op donderdag 9 januari 2020 @ 11:57:
Ik zit in de enterprise-wereld en heb nu een klant waar het na jaren er eindelijk 'door' is.
Er is groen licht om te upgraden van Oracle 9 naar Oracle 11 (release date 2009)

"legal" is er ook eindelijk uit ?

[Olaf van der Spek]

mcDavid schreef op donderdag 9 januari 2020 @ 10:13:
klinkt als een hostingpartij waar je liever helemaal niet wilt draaien dus

De nieuwste versie van Ubuntu LTS (18.04) heeft PHP 7.0 met ondersteuning, dus het lijkt mij niet per definitie slecht.
Hetzelfde geldt voor de vorige versie van Debian.

[ Voor 7% gewijzigd door Olaf van der Spek op 09-01-2020 12:16 ]

[gekkie]

Al is het altijd wel de vraag hoeveel support, support werkelijk is als upstream het niet meer support.
Op z'n minst zal het traag zijn, voornamelijk security issues die ook in hogere versies voorkomen, etc.

[mcDavid]

Olaf van der Spek schreef op donderdag 9 januari 2020 @ 12:16:
[...]

De nieuwste versie van Ubuntu LTS (18.04) heeft PHP 7.0 met ondersteuning, dus het lijkt mij niet per definitie slecht.
Hetzelfde geldt voor de vorige versie van Debian.

Het ging me er meer om dat je niet bij een partij wilt zitten die (om wat voor reden dan ook) 3 jaar achter loopt met hun software updates...

[dcm360]

mcDavid schreef op donderdag 9 januari 2020 @ 12:51:
[...]


Het ging me er meer om dat je niet bij een partij wilt zitten die (om wat voor reden dan ook) 3 jaar achter loopt met hun software updates...

Dat kan je dus niet concluderen uit het feit dat PHP 7.0 gebruikt wordt. Als ik in theorie nu een nieuwe server met de laatste Ubuntu LTS installeer, volledig gepatcht dan kom ik blijkbaar ook niet verder.

In de praktijk had ik echter op de release-datum van PHP 7.4 bijna een server daarmee opgeleverd. Leek me ook weer net niet handig vlak voor Black Friday.

[mcDavid]

Jawel. Als je core-business is om php-servers te leveren, dan draai je niet whatever er toevallig in de standaard repo van je distro zit.

[RobertMe]

mcDavid schreef op donderdag 9 januari 2020 @ 13:04:
Jawel. Als je core-business is om php-servers te leveren, dan draai je niet whatever er toevallig in de standaard repo van je distro zit.

Op het werken hebben wij managed VPS bij True. Die gaan dus echt voor "Je krijgt wat in de repo zit" (dus Ubuntu 16.04 voor PHP 7.0 en Ubuntu 18.04 voor PHP 7.2)

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[mcDavid]

ja, daarom moet je ook nóóit een "managed" server afnemen. Of je besteed je IT uit, of je doet het zelf, maar een beetje half-half werkt gewoon niet.

[RobertMe]

mcDavid schreef op donderdag 9 januari 2020 @ 13:58:
ja, daarom moet je ook nóóit een "managed" server afnemen. Of je besteed je IT uit, of je doet het zelf, maar een beetje half-half werkt gewoon niet.

In ons geval is het in die zin inderdaad beetje half half. Bedrijf dat is opgericht om "probleem X op te lossen" en daardoor dus een paar programmeurs maar ook mensen met kennis in "X". Ooit is toen besloten om voor een managed server te gaan (van ene kant ook begrijpelijk, want toen waren het nog maar één of twee man aan programmeurs en geen kennis van servers etc). En nu zit ik er als programmeur die qua Linux & server flink wat doet hobbyen en heb ik nu zoiets van "dit kan echt niet". Note: niet dat ik perse verantwoordelijk wil zijn voor server gebeuren, want ook maar hobbyist. Maar nu hebben we niet eens de mogelijkheid om het issue uit te zoeken op wat effectief onze test server is. Terwijl True er dus ook geen haast mee lijkt te maken.

[Olaf van der Spek]

RobertMe schreef op donderdag 9 januari 2020 @ 14:31:
Maar nu hebben we niet eens de mogelijkheid om het issue uit te zoeken op wat effectief onze test server is.

Als ze root toegang toestaan en iemand sloopt iets.. en klopt vervolgens aan bij True, is True niet blij. Dus dat is op zich logisch. Root en managed zijn soort van mutually exclusief.

[Koenvh]

mcDavid schreef op donderdag 9 januari 2020 @ 13:58:
ja, daarom moet je ook nóóit een "managed" server afnemen. Of je besteed je IT uit, of je doet het zelf, maar een beetje half-half werkt gewoon niet.

Valt Google App Engine en consorten daar (volgens jou) ook onder?

[RobertMe]

Olaf van der Spek schreef op donderdag 9 januari 2020 @ 14:43:
[...]

Als ze root toegang toestaan en iemand sloopt iets.. en klopt vervolgens aan bij True, is True niet blij. Dus dat is op zich logisch. Root en managed zijn soort van mutually exclusief.

Dat het niet de voorkeur heeft spreekt voor zich. Maar je kunt nog altijd gaan voor een "als het kapot gaat is het jullie verantwoording". Daarnaast kunnen ze natuurlijk altijd vooraf even een snapshot maken zodat je altijd weer terug kunt.
Voor mijn gevoel zou managed VPS meer mogen neerkomen op "mijn server, maar iemand anders doet het beheer". Dus als ik de boel zelf wil slopen moet ook dat kunnen, want "is van mij" en "wie betaalt bepaald".

En uiteraard was het überhaupt geen issue als het intussen niet al een maand of 2 duurde om het probleem wat nu speelt op te lossen. Nu moet True voor ons een probleem met Apache uitzoeken wat volgens hun in eerste instantie überhaupt geen issue was "want maar een warning in de logging" en nu ze wel duidelijk is dat het toch echt gefixt moet worden schiet het ook nog steeds niet op. Dat het allemaal zo lang moet duren draagt gewoon bij aan "als ikzelf toegang had dan..."

[Olaf van der Spek]

RobertMe schreef op donderdag 9 januari 2020 @ 15:06:
Maar je kunt nog altijd gaan voor een "als het kapot gaat is het jullie verantwoording".

Wat als True updates uitvoert, het daarna niet meer werkt maar het werkelijke probleem veroorzaakt wordt door een update van jullie?

Of andersom?
Dan moet je eigenlijk afspreken dat jullie *alle* problemen zelf oppakken.

Bij 'ons' waren een keer bijna alle foto's van de productieserver verdwenen. De eindklant was niet blij, ik had recent root toegang gekregen voor wat kleine werkzaamheden.. de developer / beheerder beweerde dat het niet hun schuld was..

[ Voor 21% gewijzigd door Olaf van der Spek op 09-01-2020 15:14 ]

[RobertMe]

Olaf van der Spek schreef op donderdag 9 januari 2020 @ 15:12:
[...]

Wat als True updates uitvoert, het daarna niet meer werkt maar het werkelijke probleem veroorzaakt wordt door een update van jullie?

Weet je he, ook dat updaten gaat nu niet goed. Draaien PHP 7.0 dus op Ubuntu 16.04. Gevraagd om de acceptatie server te updaten naar Ubuntu 18.04 / PHP 7.2. En * plop * de custom PHP ini settings waren weer weg. Terwijl True die altijd op ons verzoek heeft doorgevoerd en al in een custom ini file staan die ze maar hoefden over te zetten van de ene naar de andere config dir.
En de "we kunnen de server updaten en dan ben je na paar minuten live met nieuwe versie" was hun voorstel. Zelf hadden we gevraagd voor de update en of dat via een nieuwe server kon, maar zij stelden voor om een in-place upgrade te doen want geeft maar paar minuten downtime. Met als gevolg dus dat acceptatie en productie nu al een maand of twee niet in sync zijn terwijl dat "volgens planning" maar bv een week of twee zo zou zijn (bijgewerkte acceptatie testen en dan week of twee later ook op productie de in-place upgrade doen).

Dat is ook wat de hele situatie zo ergerlijk maakt. Niet het feit dat het niet werkt, niet het feit dat we geen root toegang hebben. Maar wel dat na een maand of twee het issue nog steeds niet is opgelost en ik persoonlijk toch wel eens heel graag naar PHP 7.2 wil gaan. En dat acceptatie en productie nu niet gelijk zijn helpt natuurlijk ook niet mee. En we tickets lokaal nog steeds op wisselende PHP versies moeten testen om compatibiliteit met beide versies te garanderen etc. etc.. De hele situatie is gewoon niet wenselijk, en dat we True dan ook nog "achter de veren moeten zitten" om het opgelost te krijgen helpt dan niet mee.

Edit:
Overigens kun je je intussen ook afvragen hoe betrouwbaar een update van productie nog gaat zijn. Verschillende personen binnen True schijnen er al naar gekeken te hebben en dingen geprobeerd te hebben. Weten ze t.z.t. zelf nog wat ze moeten doen om te voorkomen dat het niet ook op productie mis gaat als die geüpdate is.

[ Voor 8% gewijzigd door RobertMe op 09-01-2020 15:42 ]

[Olaf van der Spek]

Productie zou ik in ieder geval niet in-place doen.

[RobertMe]

Olaf van der Spek schreef op donderdag 9 januari 2020 @ 15:46:
Productie zou ik in ieder geval niet in-place doen.

Guess what, bij mijn weten was dat wel wat True wou doen ("want stelt toch niks voor"). Maar gezien dit debacle is het inderdaad een stuk handiger om True een nieuwe, werkende, server op te laten zetten en dan na controle te switchen.

[Koenvh]

Olaf van der Spek schreef op donderdag 9 januari 2020 @ 15:46:
Productie zou ik in ieder geval niet in-place doen.

Veel betere oplossing, gaat er ook niet zo veel stuk

[Kobus Post]

Wat dat betreft zijn containers een uitkomst, update is kwestie van nieuwe image pakken en testen -> publish en alles is bij.

Heerlijk SEPA XML genereren hierzo, wie die namen verzonnen heeft weet ik niet, maar waarom?? "CstmrDrctDbtInitn"

Ook leuk: .NET core spuugt netjes xml met formatting uit als je kijkt in de browser, met het download attribute in de link krijg je een xml bestand met 1 hele lange string...

[RobertMe]

Kobus Post schreef op donderdag 9 januari 2020 @ 18:53:
Wat dat betreft zijn containers een uitkomst, update is kwestie van nieuwe image pakken en testen -> publish en alles is bij.

Maak dat mijn Windows minded baas maar eens duidelijk

Maar ben daar laatst wel fanatiek mee bezig geweest. Intern draait nog een servertje met vanalles en nog wat. Van Active Directory tot wat interne PHP based tooltjes/webapps. Maar die server moet eruit. Deel "naar de cloud" en de tooltjes op een VPS. Die tooltjes heb ik nu allemaal mooi in Docker zitten. Dat gecombineerd met Bitbucket Pipelines en commit op de master branch build mooi een nieuw image en deployed die op de VPS onder een test.tool.... Wordt vervolgens een tag gepusht wordt ook daarvoor een image gebuild en op de VPS gedeployed, onder stage.tool..... Vervolgens met een manual stap in de build pipeline wordt daarna het docker image getagged als latest en die ook op VPS gedeployed onder tool..... En ik had zelf/prive wel al vanalles met Docker gedaan, maar toen ik dit allemaal had opgezet voelde ik mij toch een beetje in 2016, 2017 i.p.v. in 2000.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[martijncalker]

RobertMe schreef op donderdag 9 januari 2020 @ 15:38:
[...]

Weet je he, ook dat updaten gaat nu niet goed. Draaien PHP 7.0 dus op Ubuntu 16.04. Gevraagd om de acceptatie server te updaten naar Ubuntu 18.04 / PHP 7.2. En * plop * de custom PHP ini settings waren weer weg. Terwijl True die altijd op ons verzoek heeft doorgevoerd en al in een custom ini file staan die ze maar hoefden over te zetten van de ene naar de andere config dir.
En de "we kunnen de server updaten en dan ben je na paar minuten live met nieuwe versie" was hun voorstel. Zelf hadden we gevraagd voor de update en of dat via een nieuwe server kon, maar zij stelden voor om een in-place upgrade te doen want geeft maar paar minuten downtime. Met als gevolg dus dat acceptatie en productie nu al een maand of twee niet in sync zijn terwijl dat "volgens planning" maar bv een week of twee zo zou zijn (bijgewerkte acceptatie testen en dan week of twee later ook op productie de in-place upgrade doen).

Dat is ook wat de hele situatie zo ergerlijk maakt. Niet het feit dat het niet werkt, niet het feit dat we geen root toegang hebben. Maar wel dat na een maand of twee het issue nog steeds niet is opgelost en ik persoonlijk toch wel eens heel graag naar PHP 7.2 wil gaan. En dat acceptatie en productie nu niet gelijk zijn helpt natuurlijk ook niet mee. En we tickets lokaal nog steeds op wisselende PHP versies moeten testen om compatibiliteit met beide versies te garanderen etc. etc.. De hele situatie is gewoon niet wenselijk, en dat we True dan ook nog "achter de veren moeten zitten" om het opgelost te krijgen helpt dan niet mee.

Edit:
Overigens kun je je intussen ook afvragen hoe betrouwbaar een update van productie nog gaat zijn. Verschillende personen binnen True schijnen er al naar gekeken te hebben en dingen geprobeerd te hebben. Weten ze t.z.t. zelf nog wat ze moeten doen om te voorkomen dat het niet ook op productie mis gaat als die geüpdate is.

Members only: title

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[ Voor 15% gewijzigd door martijncalker op 20-01-2021 10:32 . Reden: personal ]

[RobertMe]

martijncalker schreef op donderdag 9 januari 2020 @ 23:09:
Waar ik wel benieuwd naar ben is (vrij bot) waarom jullie dan nog klant bij zo'n partij zijn. Is het voor jullie makkelijk om je spul op te pakken en over te zetten of zitten jullie helemaal vendor locked in True?

Ik heb eerlijk gezegd geen idee. Ten eerste was het al zo toen ik 5 jaar terug binnen rolde, ten tweede is het boven mijn pay grade, en als ik een gok moet doen "iets met NEN/ISO certificering" (die voor ons product verplicht is en dus op z'n minst zeeer wenselijk bij de hostingpartij, als ook niet daar verplicht).

En m.b.t. je opmerking m.b.t. Kubernetes. Is het niet zo dat True op dat moment voor alle klanten juist dezelfde configuratie draait (een basis Kubernetes cluster met niks erop) en de klant vervolgens zelf de deployments doet / pods configurereerd? Wat je als klant draait maakt voor True dan niet meer uit en voor hun wordt de configuratie dan makkelijker.

En m.b.t. configuration management. 100% mee eens. Ja, het lijkt erop dat True niet bijhoud welke aanpassingen zijn gedaan / nodig zijn, en ja, waarom doen ze dat niet via een tool (Ansible, Puppet, Chef, ...). Bij mijn vorige werkgever is in die tijd de boel verplaatst naar Exonet, en die gebruikte bv wel Ansible. Alhoewel die de playbooks niet wouden vrijgeven zodat we deze intern konden gebruiken in combinatie met Vagrant

[dev10]

Kobus Post schreef op donderdag 9 januari 2020 @ 18:53:
Heerlijk SEPA XML genereren hierzo, wie die namen verzonnen heeft weet ik niet, maar waarom?? "CstmrDrctDbtInitn"

Oh man, ik voel je. Er is ook gewoon echt geen logische verklaring voor de veldnamen:

- BatchBooking -> BtchBookg
- NumberOfTransactions -> NbOfTxs
- RequestedCollectionDate -> ReqdColltnDt
- Mandate Identification -> MndtId

Er zijn maar twee mogelijke verklaringen voor die achterlijke veldnamen: de persoon die dit heeft uitgeschreven was stomdronken of hij was toe aan een nieuw toetsenbord.

[RayNbow]

dev10 schreef op vrijdag 10 januari 2020 @ 09:15:
Er zijn maar twee mogelijke verklaringen voor die achterlijke veldnamen: de persoon die dit heeft uitgeschreven was stomdronken of hij was toe aan een nieuw toetsenbord.

Of een oude gewoonte om dingen af te korten omdat sommige oude formaten een beperking hadden op veldnamen.

(Shapefiles hebben bijv. nog steeds een beperking van 10 tekens per veldnaam... )

[dev10]

Dat kan ook nog, maar waarom je RequestedCollectionDate dan afkort met ReqdColltnDt? Kort dat dan af met ReqCollDate. Zijn nog minder karakters ook. De naam van die SEPA standaard is ook pain.008. Die naam dekt de lading wel aardig.

Die SEPA standaard is gelukkig nog niet zo erg als EDIFACT. Dat is me toch een crime om mee te werken.

[Mugwump]

dev10 schreef op vrijdag 10 januari 2020 @ 09:15:
[...]


Oh man, ik voel je. Er is ook gewoon echt geen logische verklaring voor de veldnamen:

- BatchBooking -> BtchBookg
- NumberOfTransactions -> NbOfTxs
- RequestedCollectionDate -> ReqdColltnDt
- Mandate Identification -> MndtId

Er zijn maar twee mogelijke verklaringen voor die achterlijke veldnamen: de persoon die dit heeft uitgeschreven was stomdronken of hij was toe aan een nieuw toetsenbord.

Waardeloos formaat inderdaad, maar het is altijd hetzelfde gezeik met XML.
"Laten we XML gebruiken, dat is lekker zelf beschrijvend!"
"Oh nu krijgen we wel heel veel data vanwege alle overhead. "
"Weet je wat, we korten de tagnamen wel in door gewoon willekeurige letters weg te laten zodat het we minder overhead hebben en het geheel volkomen onleesbaar wordt"
"Goed plan!"

In m'n huidige project hebben we ook weer te maken met gedrochten van XML specs met enorme namespaces, allerlei loze niveaus en ga zo maar door. We besparen echt letterlijk iets van 30-50% in de operationele kosten door die dingen te converteren naar een compacter JSON formaat zonder dat er enige informatie verloren gaat.

[CodeCaster]

Echt, WTF is er aan de hand met dat Atlassian SourceTree? Ik heb al jaren ruzie met dat gare product, maar heb nog steeds geen fatsoenlijkere Git-GUI gevonden, dus ik moet het er maar mee doen.

Op de ene ontwikkelmachine heb ik om de zoveel tijd een wachtwoord-popup van om het even welke repository. Azure DevOps, GitHub, BitBucket, whatever. Dan kan ik m'n Git Credential Manager for Windows updaten tot ik een ons weeg, en de opgeslagen credentials in Windows wissen wat ik wil, het probleem keert telkens terug.

En op een andere machine heb ik nu dat ik na iedere wijziging handmatig op F5 moet drukken, anders blijft het scherm de oude informatie tonen. Dus ik fetch, en zie geen nieuwe commits die er wel moeten zijn. Ik kan alles doen wat ik wil in de GUI, dus branches maken, commits samenstellen, alles, maar na iedere actie moet ik dus op F5 drukken. Een volledige wipe van alle mappen die Atlassian heten en een schone installatie verder, blijft hetzelfde probleem aanwezig.

[ Voor 3% gewijzigd door CodeCaster op 10-01-2020 10:33 ]

[Merethil]

CodeCaster schreef op vrijdag 10 januari 2020 @ 10:32:
Echt, WTF is er aan de hand met dat Atlassian SourceTree? Ik heb al jaren ruzie met dat gare product, maar heb nog steeds geen fatsoenlijkere Git-GUI gevonden, dus ik moet het er maar mee doen.

Op de ene ontwikkelmachine heb ik om de zoveel tijd een wachtwoord-popup van om het even welke repository. Azure DevOps, GitHub, BitBucket, whatever. Dan kan ik m'n Git Credential Manager for Windows updaten tot ik een ons weeg, en de opgeslagen credentials in Windows wissen wat ik wil, het probleem keert telkens terug.

En op een andere machine heb ik nu dat ik na iedere wijziging handmatig op F5 moet drukken, anders blijft het scherm de oude informatie tonen. Dus ik fetch, en zie geen nieuwe commits die er wel moeten zijn. Ik kan alles doen wat ik wil in de GUI, dus branches maken, commits samenstellen, alles, maar na iedere actie moet ik dus op F5 drukken. Een volledige wipe van alle mappen die Atlassian heten en een schone installatie verder, blijft hetzelfde probleem aanwezig.

Ik gebruik nu Fork. Veel fatsoenlijker en toevallig meegepikt van iemand die hier ook Fork gebruikt
Was wel verbaasd dat 'ie toevallig alleen voor mijn 2 "werkplatformen" (Windows en MacOS) beschikbaar is. Kwam weer handig uit.

[ Voor 4% gewijzigd door Merethil op 10-01-2020 11:23 ]

[CodeCaster]

Merethil schreef op vrijdag 10 januari 2020 @ 11:21:
[...]


Ik gebruik nu Fork. Veel fatsoenlijker en toevallig meegepikt van iemand die hier ook Fork gebruikt
Was wel verbaasd dat 'ie toevallig alleen voor mijn 2 "werkplatformen" (Windows en MacOS) beschikbaar is. Kwam weer handig uit.

Volgens mij kwam een collega daar deze week ook mee. Ik ga hem eens proberen, bedankt!

En volgens mij heb ik die al vaker aangeraden gekregen, maar ben ik altijd eigenwijs geweest en wilde ik SourceTree blijven gebruiken omdat ik dat gewend was. Maar nu ben ik er echt klaar mee.

[ Voor 17% gewijzigd door CodeCaster op 10-01-2020 11:37 ]

[azerty]

CodeCaster schreef op vrijdag 10 januari 2020 @ 10:32:
Echt, WTF is er aan de hand met dat Atlassian SourceTree? Ik heb al jaren ruzie met dat gare product, maar heb nog steeds geen fatsoenlijkere Git-GUI gevonden, dus ik moet het er maar mee doen.

Op de ene ontwikkelmachine heb ik om de zoveel tijd een wachtwoord-popup van om het even welke repository. Azure DevOps, GitHub, BitBucket, whatever. Dan kan ik m'n Git Credential Manager for Windows updaten tot ik een ons weeg, en de opgeslagen credentials in Windows wissen wat ik wil, het probleem keert telkens terug.

En op een andere machine heb ik nu dat ik na iedere wijziging handmatig op F5 moet drukken, anders blijft het scherm de oude informatie tonen. Dus ik fetch, en zie geen nieuwe commits die er wel moeten zijn. Ik kan alles doen wat ik wil in de GUI, dus branches maken, commits samenstellen, alles, maar na iedere actie moet ik dus op F5 drukken. Een volledige wipe van alle mappen die Atlassian heten en een schone installatie verder, blijft hetzelfde probleem aanwezig.

GitHub for Windows is dan al niet veel beter

Heb dit weekend een clean install mogen doen na een WSOD van de applicatie.

Alle repositories weer een per een toevoegen

[CodeCaster]

azerty schreef op vrijdag 10 januari 2020 @ 11:37:
[...]


GitHub for Windows is dan al niet veel beter

Die heb ik net geïnstalleerd en weer verwijderd. Te veel verschillende tabs/schermen/panels. Enorm chaotisch.

Het enige wat ik wil is een tree, waarin alle branches te zien zijn, en een commit aanklikken om in hetzelfde scherm de wijzigingen van die commit te zien. En dan het liefst vanuit dat wijzigingen-scherm kunnen klikken op een file om de geschiedenis van die file te bekijken. Dat lijkt me toch niet te veel gevraagd, maar blijkbaar wel...

En Fork doet dat goed, lijkt goed afgekeken van SourceTree.

[ Voor 5% gewijzigd door CodeCaster op 10-01-2020 11:40 ]

[Matis]

Daar is de altijd gezellig git (GUI) client discussie weer

Ik raad SmartGit aan!!11!1one

[Sandor_Clegane]

GitExtensions? Werkt wel ok moet ik zeggen.

[F.West98]

CodeCaster schreef op vrijdag 10 januari 2020 @ 11:39:
[...]

Die heb ik net geïnstalleerd en weer verwijderd. Te veel verschillende tabs/schermen/panels. Enorm chaotisch.

Het enige wat ik wil is een tree, waarin alle branches te zien zijn, en een commit aanklikken om in hetzelfde scherm de wijzigingen van die commit te zien. En dan het liefst vanuit dat wijzigingen-scherm kunnen klikken op een file om de geschiedenis van die file te bekijken. Dat lijkt me toch niet te veel gevraagd, maar blijkbaar wel...

En Fork doet dat goed, lijkt goed afgekeken van SourceTree.

GitKraken doet dat ook erg goed in mijn ervaring. Vind ik er net iets rustiger qua UI maar mis nog geen features.

[CodeCaster]

F.West98 schreef op vrijdag 10 januari 2020 @ 12:36:
[...]

GitKraken doet dat ook erg goed in mijn ervaring. Vind ik er net iets rustiger qua UI maar mis nog geen features.

Ik heb sinds dag één dat het bestaat ruzie met GitKraken.

Z'n AutoStash-feature heeft menig commit en bestand geb0rked, de panels die over elkaar heen klappen maken het onoverzichtelijk, ik vind de diff-view niks, m'n bugreports zijn altijd genegeerd en je moet betalen om met private repos te werken, waardoor ik niet kan controleren of de destijds meegemaakte kinderziektes er inmiddels uitgepoetst zijn.

Oh, en dan vergeet ik nog integratie met Beyond Compare. Dat is gewoon een must, zeker voor conflict resolution.

En dat je moet kiezen of dezelfde knop een Fetch, Pull of Pull (Rebase) doet? Serieus?

Sandor_Clegane schreef op vrijdag 10 januari 2020 @ 12:35:
GitExtensions? Werkt wel ok moet ik zeggen.

Ziet er ook clean uit!

Ik ben verder niet veeleisend, maar gewoon een professioneel zeikerd.

[ Voor 26% gewijzigd door CodeCaster op 10-01-2020 12:48 ]

[Giesber]

dev10 schreef op vrijdag 10 januari 2020 @ 09:28:
Dat kan ook nog, maar waarom je RequestedCollectionDate dan afkort met ReqdColltnDt? Kort dat dan af met ReqCollDate. Zijn nog minder karakters ook. De naam van die SEPA standaard is ook pain.008. Die naam dekt de lading wel aardig.

Die SEPA standaard is gelukkig nog niet zo erg als EDIFACT. Dat is me toch een crime om mee te werken.

Die ReqCollDate zal wel dubbelzinnigheden bevatten: dat kan een RequiredCollatedDate zijn.

Ik ben in de bank die afkortingen ook tegengekomen, en na een tijd leest dat zoals normaal Nederlands/Engels. Er waren ook applicaties en lijsten om een afkorting op te zoeken moest je ze niet kennen, maar die waren eigenlijk alleen nodig als je eentje moest verzinnen voor een nieuwe term: dan kon je kijken of iemand anders daar ooit een afkorting voor bedacht had, of dat er misschien al een andere exotische term is met dezelfde afkorting.

[Mercatres]

CodeCaster schreef op vrijdag 10 januari 2020 @ 11:39:
[...]

Die heb ik net geïnstalleerd en weer verwijderd. Te veel verschillende tabs/schermen/panels. Enorm chaotisch.

Het enige wat ik wil is een tree, waarin alle branches te zien zijn, en een commit aanklikken om in hetzelfde scherm de wijzigingen van die commit te zien. En dan het liefst vanuit dat wijzigingen-scherm kunnen klikken op een file om de geschiedenis van die file te bekijken. Dat lijkt me toch niet te veel gevraagd, maar blijkbaar wel...

En Fork doet dat goed, lijkt goed afgekeken van SourceTree.

Ik had een issue met Fork dat ie bij het mergen van grotere files (met name package.json) af en toe gewoon helft van de file dropte. Met als gevolg dat (als je even niet oplet), je hele build pipeline begint te huilen. Sindsdien naar GitExtenstions. Wel jammer, want van UI is Fork wel een verademing.
SourceTree gebruik ik professioneel, maar ook maar alleen voor visuele branch management. Pushen enz. doe ik met Windows Terminal, want 't hele remote repo gebeuren in SourceTree is bagger (en kapot).

[Koenvh]

Mugwump schreef op vrijdag 10 januari 2020 @ 10:09:
[...]


Waardeloos formaat inderdaad, maar het is altijd hetzelfde gezeik met XML.
"Laten we XML gebruiken, dat is lekker zelf beschrijvend!"
"Oh nu krijgen we wel heel veel data vanwege alle overhead. "
"Weet je wat, we korten de tagnamen wel in door gewoon willekeurige letters weg te laten zodat het we minder overhead hebben en het geheel volkomen onleesbaar wordt"
"Goed plan!"

In m'n huidige project hebben we ook weer te maken met gedrochten van XML specs met enorme namespaces, allerlei loze niveaus en ga zo maar door. We besparen echt letterlijk iets van 30-50% in de operationele kosten door die dingen te converteren naar een compacter JSON formaat zonder dat er enige informatie verloren gaat.

Je kunt ook alles in YAML doen
Of kun je tegenwoordig YAML wel redelijk minifyen?

[ Voor 3% gewijzigd door Koenvh op 10-01-2020 20:43 ]

[Olaf van der Spek]

Mugwump schreef op vrijdag 10 januari 2020 @ 10:09:
We besparen echt letterlijk iets van 30-50% in de operationele kosten door die dingen te converteren naar een compacter JSON formaat zonder dat er enige informatie verloren gaat.

Waar zit die kostenbesparing in? Bandbreedte / dataverkeer? CPU-tijd voor compressie?
Minder typisten nodig om alle XML te typen?
Minder papier om alle XML te printen?

[ Voor 9% gewijzigd door Olaf van der Spek op 10-01-2020 21:18 ]

[Mugwump]

Olaf van der Spek schreef op vrijdag 10 januari 2020 @ 21:12:
[...]

Waar zit die kostenbesparing in? Bandbreedte / dataverkeer? CPU-tijd voor compressie?
Minder typisten nodig om alle XML te typen?
Minder papier om alle XML te printen?

Het is een project waarin we alles op AWS doen en dan redelijk "cloud native", dus S3, Lambda's, SQS / SNS, DynamoDB en ga zo maar door. Alles dus feitelijk 'pay per use'. Omdat we 80-90% van het volume kwijtraken als we het naar JSON converteren (waarbij we ook null values weglaten e.d. voor verdere reductie in omvang) scheelt dat in opslag en 'tikken' aan alle kanten. Het betreft een systeem dat een kleine 100M van dit soort berichtjes per dag verwerkt en ook nog een redelijke historie moet bijhouden waarbij de data ook nog min of meer door een pipeline heen vloeit met losse lambda's en SQS queues.
Daar zitten weer optimalisatieslagen in zoals gebruik maken van de mogelijkheid om een lambda 10 SQS berichten tegelijk uit te laten lezen. Echter, het afrekenmodel is dan ook weer dat je een 'tik' betaalt per 64kb payload. Met die XML formaten kom je dan vaak net aan 2 tikken, terwijl het er voor JSON altijd slechts één is.
DynamoDB kent ook al zo'n mooi verdienmodel waarbij je voor lezen en schrijven een read of write unit betaalt per KB omvang. Als je formaat dus zorg dat het bericht 8KB is in plaats van 1-2KB dan scheelt dat weer een factor 4-8 in de kosten.

[CodeCaster]

Mercatres schreef op vrijdag 10 januari 2020 @ 20:04:
[...]
want 't hele remote repo gebeuren in SourceTree is bagger (en kapot).

Oh, dat ook nog eens ja. Altijd een rood uitroepteken bij remotes, en dus inlogproblemen.

Een nieuwe bug, waar ik onlangs tegenaan liep, is dat 'ie bij het pushen van een nieuwe branch de remote-naam de eerste keer niet meegeeft aan libgit.

Dus:

• Maak lokaal een nieuwe branch
• Open het Push-scherm met je branchoverzicht, om die nieuwe branch naar remote te pushen
• Vink hem aan, de lokale naam wordt nu ook bij remote ingevuld
• Klik op OK
• Krijg de foutmelding: "The Remote branch '<lege string>' (Local branch = 'feature/foo-bar') is invalid. Ref names must follow git ref-format rules"
• Klik nogmaals op OK
• Nu werkt het wel

En dit op meerdere machines en meerdere repo's.

[Kobus Post]

RobertMe schreef op donderdag 9 januari 2020 @ 19:12:
[...]

Maak dat mijn Windows minded baas maar eens duidelijk

Tegenwoordig heb je ook docker containers die windows draaien

Maar ben daar laatst wel fanatiek mee bezig geweest. Intern draait nog een servertje met vanalles en nog wat. Van Active Directory tot wat interne PHP based tooltjes/webapps. Maar die server moet eruit. Deel "naar de cloud" en de tooltjes op een VPS. Die tooltjes heb ik nu allemaal mooi in Docker zitten. Dat gecombineerd met Bitbucket Pipelines en commit op de master branch build mooi een nieuw image en deployed die op de VPS onder een test.tool.... Wordt vervolgens een tag gepusht wordt ook daarvoor een image gebuild en op de VPS gedeployed, onder stage.tool..... Vervolgens met een manual stap in de build pipeline wordt daarna het docker image getagged als latest en die ook op VPS gedeployed onder tool..... En ik had zelf/prive wel al vanalles met Docker gedaan, maar toen ik dit allemaal had opgezet voelde ik mij toch een beetje in 2016, 2017 i.p.v. in 2000.

***members only***

Dat is toch wel hoe het moet. Vind het zelf een verademing dat je gewoon code kan schrijven en je niet elke keer bezig hoeft te houden met de infra. Zeker als je van die aanpassingen op een vm zelf doet,die nergens genoteerd worden en je bíj een update weer aan het kloten zit van hoe zat het ook alweer.

Wel eens het network thuis plat getrokken door een Magento installatie te verwijderen via FTP...

[Firesphere]

CodeCaster schreef op vrijdag 10 januari 2020 @ 10:32:
Echt, WTF is er aan de hand met dat Atlassian SourceTree? Ik heb al jaren ruzie met dat gare product, maar heb nog steeds geen fatsoenlijkere Git-GUI gevonden, dus ik moet het er maar mee doen.

Op de ene ontwikkelmachine heb ik om de zoveel tijd een wachtwoord-popup van om het even welke repository. Azure DevOps, GitHub, BitBucket, whatever. Dan kan ik m'n Git Credential Manager for Windows updaten tot ik een ons weeg, en de opgeslagen credentials in Windows wissen wat ik wil, het probleem keert telkens terug.

En op een andere machine heb ik nu dat ik na iedere wijziging handmatig op F5 moet drukken, anders blijft het scherm de oude informatie tonen. Dus ik fetch, en zie geen nieuwe commits die er wel moeten zijn. Ik kan alles doen wat ik wil in de GUI, dus branches maken, commits samenstellen, alles, maar na iedere actie moet ik dus op F5 drukken. Een volledige wipe van alle mappen die Atlassian heten en een schone installatie verder, blijft hetzelfde probleem aanwezig.

Git Fork is imo de beste client die er is. Het doet what SourceTree origineel probeerde te doen, lightweight zijn. En de interface is een stuk plezieriger than die van ST.

[alienfruit]

@RobertMe Docker werkt prima onder Windows 10 hoor. Op mijn werk gebruiken we het om een beetje rap te kunnen programmeren. We draaien er VSCode, Rider, Cypress etc in om te werken aan een CRA, en ASP.NET Core app. Werkt prima en het is zo veel sneller dan 'native' Windows. Van 2-3 minuten om je Jest unit tests draaien duurt het nu een minuutje. Ik weet niet wat er allemaal draait qua scanners maar het is zonder devcontainer een onwerkbare bedoeling zo traag.

[GrooV]

Gewoon CMD git gebruiken, als je het eenmaal onder de knie hebt dan wil je niet anders