NodeJS deelt dan ook geen dependencies; tenzij je alles global installeert, maar dan heb je weer DLL Hell. Ieder NodeJS project download dus alle dependencies, en de dependencies van de dependencies, e.d. en dat loopt inderdaad al gouw in de honderde MBs.Gropah schreef op maandag 14 oktober 2019 @ 13:00:
[...]
Niet mee eens. Ik heb 256GB linux partitie voor devven. Als ik daar wat met Node op moet doen (helaas moet dat af en toe) dan is 600mb aan node dependancies niet zo raar. En met docker kan het ook snel uit de klauwen lopen als iemand zijn versies niet goed pinned/hergebruikt.
/u/243953/crop56f55a7bcf291.png?f=community)
/u/12668/hydra.png?f=community)
:strip_exif()/u/52746/eric-cartman_small.gif?f=community)
:strip_icc():strip_exif()/u/439769/crop5a510243ea2e3_cropped.jpeg?f=community)
Ik zei ook dat het nadelen had. Maar in principe is Docker een regelrecht resultaat van dit.
Less alienation, more cooperation.
/u/3813/100_8985_ICON2.JPG?f=community)
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.
:strip_icc():strip_exif()/u/206968/325134.jpg?f=community)
Ik las DeepSpace. Waarom weet ik niet, misschien heeft het met het bezoek aan Space Expo van vandaag te maken
If money talks then I'm a mime
If time is money then I'm out of time
:strip_icc():strip_exif()/u/437778/crop684040f89be83_cropped.jpg?f=community)
:strip_icc():strip_exif()/u/69431/crop5d6d1438b1ba6_cropped.jpeg?f=community)
Ik heb toevallig wel iets leuks wat je kunt proberen op jouw Linux machines:
https://thehackernews.com...udo-run-as-root-flaw.html
(niet dat dit überhaupt iets met de discussie te maken heeft, maar ik vind het gewoon grappig... al moet je hiervoor wel een regel in de /etc/sudoers hebben met !root er in, dus als je een user hebt die andere users mag impersonaten behalve root, dan kan diegene toch root worden door sudo -u#-1 te doen).
[ Voor 29% gewijzigd door Lethalis op 15-10-2019 11:16 ]
Ask yourself if you are happy and then you cease to be.
/u/262310/ava.png?f=community)
Aan de slag als in "beetje spelen"?
Als je nog niets aan services bij Azure hebt zou ik meer bij GKE kijken (Google dus) en preemtible nodes gebruiken. Dan heb je voor een paar euro in de maand een cluster.
Anders dan dat mist het te veel context en is wellicht een nieuw topic zelfs beter
:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
Kijk eens aan, Disney+ voldoet niet aan hun plicht om een unsubscribe-link op te nemen in hun emails met kijksuggesties. De klantenservice ging er een melding van maken 
. Ondertussen heb ik er ook maar een melding van gemaakt, bij de ACM 
. Ondertussen heb ik er ook maar een melding van gemaakt, bij de ACM
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 heb nog een stuk code liggen wat gebruikt maakt van de Kinect SDK voor spraakherkenning. Ik was benieuwd of dit een beetje te doen is met DeepSpeech.:
[...]
Wat ben je van plan als ik 't vragen mag?
Die van de Kinect moet je namelijk helemaal voorkauwen met grammars en ik hoop dat deze wat meer freeflow is.
Edit: wow, het was wat gepruts met de juiste instellingen op de Kinect en Freenect op het Communisten OS (
) maar DeepSpeech is echt wel indrukwekkend.Oh man, nu nog iets vinden hoe ik dus de stream van de Kinect op Linux .Net Core in krijg en dat dan DeepSpeech in kan jagen, die inference laten doen en het er dan weer uit krijgen,
Edit2: Hij kent mijn hotword ook nog!
Waarom zou je je willen unsubscriben?:
Kijk eens aan, Disney+ voldoet niet aan hun plicht om een unsubscribe-link op te nemen in hun emails met kijksuggesties. De klantenservice ging er een melding van maken
Edit3:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| // Learn more about F# at http://fsharp.org
open System
open OpenTK.Audio
let getCaptureDevices () =
AudioCapture.AvailableDevices
|> Seq.cast
|> Seq.iter(printfn "%s")
[<EntryPoint>]
let main argv =
getCaptureDevices()
Console.ReadLine() |> ignore
printfn "Hello World from F#!"
0 // return an integer exit code |
Output:
code:
1
2
3
4
| Family 17h (Models 00h-0fh) HD Audio Controller Analog Stereo Kinect Audio 4 Channels Input Monitor of Family 17h (Models 00h-0fh) HD Audio Controller Digital Stereo (IEC958) Monitor of GP102 HDMI Audio Controller Digital Stereo (HDMI) |
Het begin is er.
[ Voor 70% gewijzigd door Sandor_Clegane op 15-10-2019 20:46 ]
Less alienation, more cooperation.
:strip_icc():strip_exif()/u/36003/crop584e9e5c223bd.jpeg?f=community)
Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.
:strip_exif()/u/396800/D-_3427da0a9c293b63f2a66dea2e642102.gif?f=community)
Ik dacht meer aan alles, en niet aan GUI vs CLI
Python vind ik qua "looks" maar een rare taal. En ik weet wel dat het door de dynamischere opzet wat features heeft die de strictere talen niet hebben. Maar daarvan ken ik de exacte ins en outs ook niet en ik heb ook niet het idee dat ik in PHP (shoot me) iets mis of in C# iets miste wat potentieel met Python stukken makkelijker zou kunnen.
Toch gebeurt het volop
Zeker waar, maar dat verplicht je niet je nieuwe dingen ook in Java te schrijven.
Of het nu Python, C# of zelfs PHP is, punt blijft hetzelfde. Er zijn voldoende alternatieven.
Zie hierboven.
Sinds de 2 dagen regel reageer ik hier niet meer
Veel nieuwe ontwikkelingen bij bedrijven en overheden bouwen op bestaande software of sluiten daar tenminste op aan.:
[...]
Toch gebeurt het volop
Zeker waar, maar dat verplicht je niet je nieuwe dingen ook in Java te schrijven.
Of het nu Python, C# of zelfs PHP is, punt blijft hetzelfde. Er zijn voldoende alternatieven.
Een andere taal gebruiken is dan vaak onhandig, omdat je bijvoorbeeld bestaande libraries wil hergebruiken.
Op mijn werk is .NET Core gebruiken in veel situaties al lastig t.o.v. het .NET Framework
Laat staan dat je ineens iets heel anders wil. Dan kun je hele domein specifieke libraries gaan herschrijven in die taal.Ik probeer die libraries naar .NET Standard te krijgen met veel moeite en heb het in een paar gevallen zelfs al opgegeven en mij er maar bij neergelegd omdat het de tijd en energie simpelweg niet waard is.
Ask yourself if you are happy and then you cease to be.
Tja als je enorme codebases in Python beheersbaar wilt houden, dan ga je dus zoals bij Dropbox weer terugvallen op static typing.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Het ligt eraan wat je ermee doet.
Voor betere performance gebruik je externe libraries, zoals numpy.
Die 2/3 split is mijn ogen echt verleden tijd, ik ken geen project wat nog niet over is naar 3.
Over static typing begin ik het inmiddels wel eens te worden. Python met static typing zou ik misschien zelfs wel prettig vinden
https://medium.com/@ageit...n-10-minutes-12c86d72677b:
Python met static typing zou ik misschien zelfs wel prettig vinden
Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.
:strip_icc():strip_exif()/u/36083/crop5dca9e34ce091_cropped.jpeg?f=community)
Toevallig zitten wij in deze situatie. We hebben meerdere applicaties waarbij dit het geval is. Bij eentje zijn we aan het overwegen het te herschrijven van een custom PHP framework dat ooit door een programmeur (die weg is) bedacht is naar een modernere manier. De reden dat we het doen is dat we, voor ons gevoel, onevenredig veel tijd/geld kwijt zijn met bugfixing en nieuwe features bijna ondoenlijk zijn. Het kost gewoon heel veel tijd/geld een triviale bug op te lossen. Daarnaast is de performance om te huilen vanwege een paar hele matige design keuzes.
Wat we eerst doen is kijken of we met een PoC de performance kunnen halen die we willen. Vanuit daar kijken we of we verder gaan. Ik denk dat je in zulke gevallen een paar harde criteria moet stellen wanneer je door besluit te gaan of niet en in den beginne klein moet beginnen met de vervanger zodat de investeringen in tijd en geld niet enorm zijn voordat je go/nogo beslissingen neemt. Voor management is het altijd lastig verlies te nemen als de kosten al enorm opgelopen zijn en men diep geinvesteerd is in het volgende legacy project
Engineering is like Tetris. Succes disappears and errors accumulate.
De winkel blijft open sowieso, en we gaan eerst haalbaarheidsstudie doen om onze aannames te staven. Vanuit daar komt een go/nogo.
Helaas kunnen we niet stapsgewijs vervangen. Dus op gegeven moment moeten we gewoon er vol voor gaan (of niet).Het is wel zo dat de JVM backend wel heel stabiel is, dus de REST-api waar de PHP-app mee praat gewoon hetzelfde blijft. Dus heel veel business-logica is onaangetast.
Het artikel van Joel is al vrij oud, en z'n referentie naar Netscape nog wel ouder. Het probleem bij Netscape was natuurlijk ook dat ze zich verkeken op de impact en het niet releasen van een nieuwe versie, terwijl er stiekem best veel concurrentie op de loer lag.
Engineering is like Tetris. Succes disappears and errors accumulate.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Yup. Dat is hem op z'n meest basaal, inderdaad.
Ondertussen heb ik vandaag er weer fijn een nieuw hoofdpijngeval bij gekregen.
Mijn werkgever schakelt voor een nieuwe schare projecten eindelijk vol over op een moderne toolchain gebruik makende van Webpack voor de front-end naast bestaande .NET Core voor de backend, en juist nu trekt Microsoft keihard de stekker uit de integratie tussen ASP.NET Core en de Webpack dev middleware: https://github.com/aspnet/AspNetCore/issues/12890
Enige migratie die ze bieden is het direct aanroepen van de CLI tooling voor Angular of React. Gebruik je iets met Webpack buiten die 2 frameworks of buiten de standaard opzet van bijv. create-react-app?
Geen ondersteuning meer.
Gebruik je hot-module reloading of server-side rendering?
Geen ondersteuning meer.
Had je graag de bestaande oplossing onder .NET Core 3 willen blijven gebruiken?
Verschillende aspecten er van zijn op het moment al stuk. En reken niet op een patch voor die problemen, want - aldus MS developers: "dat valt niet meer in lijn met onze lange termijn visie voor dit product"
Lekker dan...
[ Voor 50% gewijzigd door R4gnax op 16-10-2019 19:21 ]
Potverdikkie het werkt:
Wilde ik even delen.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| Loading wav....done
Creating deepspeech.....
TensorFlow: v1.13.1-10-g3e0cc53
DeepSpeech: v0.5.1-0-g4b29b78
2019-10-16 21:36:04.817615: I tensorflow/core/platform/cpu_feature_guard.cc:141] Your CPU supports instructions that this TensorFlow binary was not compiled to use: AVX2 FMA
2019-10-16 21:36:04.827163: E tensorflow/core/framework/op_kernel.cc:1325] OpKernel ('op: "UnwrapDatasetVariant" device_type: "CPU"') for unknown op: UnwrapDatasetVariant
2019-10-16 21:36:04.827205: E tensorflow/core/framework/op_kernel.cc:1325] OpKernel ('op: "WrapDatasetVariant" device_type: "GPU" host_memory_arg: "input_handle" host_memory_arg: "output_handle"') for unknown op: WrapDatasetVariant
2019-10-16 21:36:04.827216: E tensorflow/core/framework/op_kernel.cc:1325] OpKernel ('op: "WrapDatasetVariant" device_type: "CPU"') for unknown op: WrapDatasetVariant
2019-10-16 21:36:04.827297: E tensorflow/core/framework/op_kernel.cc:1325] OpKernel ('op: "UnwrapDatasetVariant" device_type: "GPU" host_memory_arg: "input_handle" host_memory_arg: "output_handle"') for unknown op: UnwrapDatasetVariant
done
Running inference.... Result: it was my reports from the north which
Hello World from F#!
Press any key to continue... |
Wilde ik even delen.
Less alienation, more cooperation.
@Sandor_Clegane Hoera 
Ook leuk om de aloude Python-discussie weer eens te zien. Dat was alweer even geleden
Ook leuk om de aloude Python-discussie weer eens te zien. Dat was alweer even geleden
🠕 This side up
Zelf aan het trainen, of alleen inference aan het toen op basis van engels model ?:
Potverdikkie het werkt:
Running inference.... Result: it was my reports from the north which
Hello World from F#!
Press any key to continue...
[/code]
Wilde ik even delen.
Ik heb hem nu zo::
[...]
Yup. Dat is hem op z'n meest basaal, inderdaad.
code:
1
2
3
4
5
6
| services.AddScoped<IDbConnection>(db =>
{
var dbConn = new SqlConnection(connectionString);
dbConn.Open();
return dbConn;
}); |
Ik open de SqlConnection om te voorkomen dat Dapper zelf de verbinding gaat managen.
Ah de zoveelste gekke beslissing van Microsoft.
Fijn inderdaad
Ik hoop maar dat het niet echt is vanwege Blazor, want dan zijn ze echt heel fout bezig.
Ask yourself if you are happy and then you cease to be.
Oh, het was geen enterprise-y stuk code nee. En het had een nogal beperkte scope. Dus een paar honderd, tot duizend misschien?
Kwa change management viel het wel mee. Die werden vooral door projecten gedreven, dus wellicht 5 tot 10x per jaar.
Maar LOC en hoe onderhevig het was aan verandering heeft vrij weinig te maken met het punt dat ik wilde maken
Namelijk dat Python wel z'n plek heeft en prima hi-perf kan zijn. Tegen een bepaalde prijs natuurlijk.
Engineering is like Tetris. Succes disappears and errors accumulate.
:strip_exif()/u/627282/charmander-kerst.gif?f=community)
Collega zegt hier plots achter mij:
Nog iemand koffie?
Waarna hij keihard facepalmed... Someone's having a rough morning
Nog iemand koffie?
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
Zo zit ik er ook wel eens bij. Dan kom ik dingen tegen in de codebase waarbij ik mij echt afvraag hoe het ooit heeft kunnen werken (als het dat al deed).:
Collega zegt hier plots achter mij:
[...]
Waarna hij keihard facepalmed... Someone's having a rough morning
Nog iemand koffie?
[Afbeelding]
Ah kijk eens aan .. doe maar gewoon een zwart bakkie :-):
Collega zegt hier plots achter mij:
Waarna hij keihard facepalmed... Someone's having a rough morning
Nog iemand koffie?
[Afbeelding]
Urghh pgloader nog niet compatible met postgres 12
Ik krijg nog wel eens het verzoek om werk van collega's te reviewen op architecturele hoofdlijnen en dan heb ik toch ook wel regelmatig van die WTF momentjes.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Ik voel een Navigator komen....... En dan is het cirkeltje weer rond.
Less alienation, more cooperation.
Ik hoor nu al die namen van de nieuwe tools, en ik moet gelijk weer aan dit denken: https://pixelastic.github.io/pokemonorbigdata/
🠕 This side up
Geweldig:
Ik hoor nu al die namen van de nieuwe tools, en ik moet gelijk weer aan dit denken: https://pixelastic.github.io/pokemonorbigdata/
Ach, ik zat daarnet te Googlen wat een SRE is
Ik kruip wel weer terug onder mijn steen.
Ask yourself if you are happy and then you cease to be.
/u/48320/kenshin60.png?f=community)
*zucht*
Wij zijn een nieuwe applicatie aan het ontwikkelen en praten daarbij tegen een API aan die iets voor ons moet regelen.
Nou hebben ze van die API een v2 ontwikkelt, die ook gewoon andere paden heeft en andere responses. Deze is alleen op Test en Acceptatie beschikbaar.
Dus willen wij nog met v1 praten, want wij willen naar Productie (zijn zelfs al naar productie).
Zeggen ze van die API, nee op Test en Acceptatie moet je V2 gebruiken en dan op Prod V1.
En hoe moet ik dan mijn code testen?? Op Prod??
Nee Gitflow is volgens hem het magische woord.
Wij zijn een nieuwe applicatie aan het ontwikkelen en praten daarbij tegen een API aan die iets voor ons moet regelen.
Nou hebben ze van die API een v2 ontwikkelt, die ook gewoon andere paden heeft en andere responses. Deze is alleen op Test en Acceptatie beschikbaar.
Dus willen wij nog met v1 praten, want wij willen naar Productie (zijn zelfs al naar productie).
Zeggen ze van die API, nee op Test en Acceptatie moet je V2 gebruiken en dan op Prod V1.
En hoe moet ik dan mijn code testen?? Op Prod??
Nee Gitflow is volgens hem het magische woord.
Mja daarnaast is het een typische three letter acronym
Mijn vriendin heeft dat op haar werk in de zorg ook met van alles. Dan hebben ze een MDO met de VSO, VPK en AIO.
En dan heb ik zoiets van "kun je ook gewoon Nederlands praten?"
Tsja, mijn idee is dat ik 1 IDbConnection gebruik gedurende 1 request en dat het niet uitmaakt in hoeveel verschillende classes ik hem nodig heb.
Op zich heb je daar natuurlijk ook connection pooling voor. Het spannende is alleen hoe je met transacties omgaat. Dus ga je bij alles wat je doet rekening houden met transacties, of ga je de situaties waarin je transacties nodig hebt simpelweg anders afhandelen?
Om even terug te komen op jouw Func<IDbConnection>. Wat ik wel een keer gedaan heb, is een class maken die een IDbConnection als property heeft. Bij de eerste keer dat een getter wordt aangeroepen op de property, dan maak ik de verbinding pas aan en vanaf dat moment wordt hij hergebruikt.
De class implementeert uiteraard ook IDisposable en sluit de IDbConnection ook.
Zou je dit dan beter vinden dan direct een IDbConnection injecten? Het komt principieel op hetzelfde neer.
Ik noem zoiets bijvoorbeeld een IDbContext die dus een IDbConnection als property heeft.
Ask yourself if you are happy and then you cease to be.
Komt dat ook niet gewoon omdat je 3 nieuwe dingen tegelijkertijd aan 't doen bent? Je hebt voor Kubernetes niet perse Helm nodig bijvoorbeeld, en Helm an sich is best wel een vreemd ding waarbij je je afvraagt of niet gewoon zelf simpelweg die resources templaten met Jinja ofzo niet beter is. Da's in ieder geval de route waar we in een vorig project (een hoop microservices met allemaal identieke deployments) voor gegaan zijn. Helm is leuk in theorie, in de praktijk is de use-case; een heel kubernetes cluster van hele diverse applicaties neerzetten, niet erg common in mijn ervaring.
Wat je meestal juist hebt is dat het K8s cluster specifiek voor een zooi microservices gebruikt wordt die eigenlijk allemaal precies op dezelfde manier gedeployed worden. Geen databases enzo (waar K8s sowieso niet zo geschikt voor is). Met per deployment een paar dingen die gecustomized worden (geheugen e.d.). Dan is gewoon een templating sausje over die K8s YAML files leggen veruit het simpelste. Helm is eigenlijk hetzelfde, maar dan op een nogal complexe 'eigen' manier.
Dit soort shit escaleer ik vrij snel naar een manager. Ik heb echt geen geduld meer voor dit soort dingen. Als je als developer niet inziet dat dit gewoon niet kan, vind ik dat je beter aardappels kunt gaan schillen in een gaarkeuken ofzo. Laat software engineering dan maar over aan mensen die het wel kunnen.:
Dus willen wij nog met v1 praten, want wij willen naar Productie (zijn zelfs al naar productie).
Zeggen ze van die API, nee op Test en Acceptatie moet je V2 gebruiken en dan op Prod V1.
En hoe moet ik dan mijn code testen?? Op Prod??
[ Voor 18% gewijzigd door Hydra op 18-10-2019 08:56 ]
https://niels.nu
2 nieuwe dingen; k8s en Helm. Azure DevOps kende ik al, alleen de yaml variant nog niet. Maar dat is allemaal niet zo bijzonder.
Loop er alleen tegen aan dat ik niet echt een boilerplate template kan gebruiken die alle microservices gebruiken met eigen parameters. Dat had ik in Jenkins wel voor mekaar via een template plug-in.
Wat mij erg aansprak van Helm is dat het volgens mij eenvoudiger wordt om een complete release van je applicatie met veel microservices wat centraler aan te kunnen pakken middels een umbrella chart.
En op zich vind ik Helm niet heel complex, ik vlieg het gewoon one step at a time aan. Eerst maar eens DevOps inrichten zodat de ACR gevuld wordt.
Daarna k8s descriptions maken. En dan kan ik altijd nog kijken of we daar Helm bij gaan gebruiken of niet.
Ik zit in een MKB omgeving
[ Voor 10% gewijzigd door plofkip op 18-10-2019 09:01 ]
Er is een reden waarom "wij" (waar ik werk) veel werk hebben. O.a. dat dit dus gebeurd en wij de clusters mogen fixen
Kubernetes is gewoon complex. Dit is volgens mij een definitie.
Ja, het is simpel om een yaml copy/paste op je cluster te flikkeren maar dan hebben we het niet meer zo zeer over k8s complexiteit. Die complexiteit zit hem uiteindelijk in observability en alle tools/software die je daarbij benodigd hebt, security, tenzij je gewoon yolo rbac'd (wat 99% van de mensen doen..). Het stukje CI/CD, vaults, en de automation & audits hiervan.
Want ja, ik zet ook in 5 min een cluster op GKE op met een ingress en een web app en done. Maar dat is 1% van wat k8s is en hoort te zijn in een gedegen prod omgeving.
Net zoals ik vaak zie dat men maar handmatig een soort vercrackte helm chart gebruiken om iets te deployen, public images gebruiken en whatnot.
Nog niet te spreken om k8s netjes op baremetal te zetten waar dat soms vereist is natuurlijk
---------
Vergeet alleen ook je eigen kennis niet. Voor sommige is niet eens 3 jaar geleden dat ze met FTP dingen online zetten. Niet om dat goed te praten maar af en toe is het niveau in de algemene zin erg laag. Voor k8s heb je eigenlijk wel een andere mindset benodigd, afhankelijk waar je vandaan komt. "12 factor app" is vaak nog zeer onbekend.
Heeft iemand een enige basis, dan kan je zeker binnen korte tijd iets met k8s doen, maar als we het echt hebben over production en dat alles "goed" is - dat is soms maanden werk.
Wel mooi dat je hier weer een mooi voorbeeld ziet van "who gets called at 2 am" als het omgevallen is.
Als je het zelf niet snapt moet je er ook geen software op draaien denk ik. Gewoon om je beheerders te vriend te houden.
Om een Microfoon in Linux te gebruiken is geen sinecure onder .Net zeg, jemig. Heb nu maar gewoon Unity 3d gepakt en in 5 min heb ik WAV files die ik DeepSpeech in kan lazeren.
Soms wil je gewoon dat het werkt.
Als je het zelf niet snapt moet je er ook geen software op draaien denk ik. Gewoon om je beheerders te vriend te houden.
Om een Microfoon in Linux te gebruiken is geen sinecure onder .Net zeg, jemig. Heb nu maar gewoon Unity 3d gepakt en in 5 min heb ik WAV files die ik DeepSpeech in kan lazeren.
Soms wil je gewoon dat het werkt.
[ Voor 32% gewijzigd door Sandor_Clegane op 18-10-2019 13:06 ]
Less alienation, more cooperation.
Wat ik dus aangaf is een cluster zelf opbouwen en onderhouden een heel ander verhaal dan er dingen in deployen. Als het bouwen / onderhouden van een cluster complex is, waarom het dan zelf doen? Ik snap dat nooit zo; dan ben je beter af met een cluster van een cloud provider. Dan zijn er echt wel zaken om rekening mee te houden, maar ook zaken als security zijn gewoon ingebouwd. In ieder geval wel toen ik vorig jaar nog zelf met Google Cloud een kubernetes pilot gestart ben.:
Er is een reden waarom "wij" (waar ik werk) veel werk hebben. O.a. dat dit dus gebeurd en wij de clusters mogen fixen
Kubernetes is gewoon complex. Dit is volgens mij een definitie.
Maar dat heeft toch weinig met K8s te maken? Hoe je services bij je secrets komen, is iets waar je met je eigen hardware volledig bare-metal werken net zo goed over na moet denken. CI/CD net zo goed; heeft wederom geen fluit met K8s zelf te maken. Het zal zo'n cluster een worst wezen als je alles met de hand deployed.
Ik denk dat daar de crux zit: mensen die vanuit hele oude outdated gebruiken opeens naar het nieuwste van het nieuwste gaan. Als je 10 jaar achterloopt en dan ineens een enorme inhaalslag gaat maken, dus EN CI/CD, EN docker, EN k8s, dan heb je dus een jaar of 10 in te halen. Maar dat heeft niks met k8s te maken. In ieder geval, naar mijn mening.
Kubernetes zelf is weinig meer dan een orchestration en security laagje bovenop docker. En natuurlijk is zelf een cluster bouwen aardig wat werk, maar dat moet je m.i. gewoon lekker aan Google/AWS overlaten.
https://niels.nu
/u/224026/crop5a1c1a6fcf1b1.png?f=community)
Hmmm... Op zoek naar een collega voor mij.
Onze recruitment afdeling is niet thuis in IT, dus hebben het uitbesteed aan.... starapple
Ik ken ze met name vanwege hun slechte naam. Nu een CV doorgestuurd gekregen waar ik niet op voorhand om sta te juichen. Recruitment afdeling heeft al een afspraak ingepland dus ik ga het maar met open vizier tegemoet. Nog iemand tips?
Onze recruitment afdeling is niet thuis in IT, dus hebben het uitbesteed aan.... starapple
Ik ken ze met name vanwege hun slechte naam. Nu een CV doorgestuurd gekregen waar ik niet op voorhand om sta te juichen. Recruitment afdeling heeft al een afspraak ingepland dus ik ga het maar met open vizier tegemoet. Nog iemand tips?
Tjolk is lekker. overal en altijd.
:strip_icc():strip_exif()/u/148671/skyaero_small_tweakers.jpg?f=community)
Als de CV in StarApple formaat is, is deze mogelijk aangepast. Check of de kandidaat daadwerkelijk de competenties heeft zoals op de CV staan.:
Hmmm... Op zoek naar een collega voor mij.
Onze recruitment afdeling is niet thuis in IT, dus hebben het uitbesteed aan.... starapple
Ik ken ze met name vanwege hun slechte naam. Nu een CV doorgestuurd gekregen waar ik niet op voorhand om sta te juichen. Recruitment afdeling heeft al een afspraak ingepland dus ik ga het maar met open vizier tegemoet. Nog iemand tips?
Stel je hebt een CustomerRepository waarmee je klantgegevens kunt ophalen en updaten, die gebruikt wordt vanuit een OrderController. Op zo'n moment wil je de verwerking van de order volledig transactioneel hebben, en toch ook graag klantgegevens ophalen / updaten binnen deze transactie bijvoorbeeld.
Dit is even een hypothetisch voorbeeld, maar je wil sommige classes / functies vaak wel vanuit meerdere plekken kunnen gebruiken.
Met een IDbContext kun je dit soort dingen afvangen, omdat deze naast de IDbConnection ook een IDbTransaction vast zou kunnen houden. Aan de andere kant kun je dit ook allemaal overboord gooien en de IDbConnection en IDbTransaction als parameters aan een UpdateCustomer functie meegeven.
Het is simpel en to the point. En nog maar de vraag of ik het ooit door iets anders ga vervangen. Ik krijg nu namelijk ook allemaal nietszeggende interfaces zoals ICustomerRepository die maar 1 implementatie heeft.
In een functionele programmeertaal zou je zeggen dat het IDbConnection, IDbTransaction -> Customer wordt en dat dit deel van de interface is. Dat impliceert wellicht ook dat het niet logisch is om deze waarden te injecten, maar dat het parameters moeten zijn.
Ik wil dingen "netjes" doen nu ik met .NET Core features zoals DI heb, maar ik moet tegelijkertijd wel zeggen dat het er niet per se beter van wordt (beter leesbaar, onderhoudbaar, etc).
Heb ik nog wel iets aan het Repository pattern? (ik gebruik wel Dapper en geen ORM als EF, die an sich al een abstractie is en waarbij het Repository pattern vaak afgeraden wordt)
Of doe ik er gewoon goed aan om mijn data access functies zaken als de IDbConnection en IDbTransaction simpelweg als parameter mee te geven?
Overengineering is ook slecht natuurlijk. Want ik kan natuurlijk wel een IDbContext maken die naast een IDbConnection ook een IDbTransaction vasthoudt etc, maar het gevoel bekruipt me dat ik nu iets betrekkelijk simpels alleen maar ingewikkelder aan het maken ben
En niet per se flexibeler, want zodra je met meerdere nested transacties aan de slag moet, werkt het niet meer.Maybe I should keep it simple. Too much indirection is also bad.
Waarom moet de recruitment afdeling per se thuis zijn in IT? Omdat ze niet genoeg communiceren met jullie?:
Hmmm... Op zoek naar een collega voor mij.
Onze recruitment afdeling is niet thuis in IT, dus hebben het uitbesteed aan.... starapple
Ik ken ze met name vanwege hun slechte naam. Nu een CV doorgestuurd gekregen waar ik niet op voorhand om sta te juichen. Recruitment afdeling heeft al een afspraak ingepland dus ik ga het maar met open vizier tegemoet. Nog iemand tips?
Ik neem aan dat jij wel een net lijstje kan maken met wat een kandidaat moet kunnen. Vervolgens kunnen zij het gewoon op diverse kanalen plaatsen (website, job boards, LinkedIn, Facebook, etc).
Wat denken ze dat een StarApple gaat doen dat zij niet kunnen?
[ Voor 15% gewijzigd door Lethalis op 18-10-2019 15:22 ]
Ask yourself if you are happy and then you cease to be.
:strip_exif()/u/19853/Goku1.gif?f=community)
Klein reclameblokje. Maar voor Devschuur wel relevant. We zijn een tijdje geleden begonnen met een Nederlandstalige podcast voor developers. Er staan inmiddels twee afleveringen online. Aflevering 3 hebben we net opgenomen, en zal begin volgende week online komen. Die aflevering gaat over AR/VR development. Oh en we verloten dan ook een licentie voor een Jetbrains IDE naar keus. Dus sowieso de moeite waard
We richten ons op alle developers, dus niet alleen een specifiek platform of type. We willen juist allerlei soorten developers de revue laten passeren. Inhoudelijk en luchtig.
Url staat in mijn signature. Maar voor de zekerheid : CodeKlets Podcast
P.S. Aflevering 1 hebben we audio issues gehad. Helaas. Kishen (host) valt vaak weg qua audio. We beloven dat we niet meer doen. Ondanks de audio was het wel een leuke aflevering.
We richten ons op alle developers, dus niet alleen een specifiek platform of type. We willen juist allerlei soorten developers de revue laten passeren. Inhoudelijk en luchtig.
Url staat in mijn signature. Maar voor de zekerheid : CodeKlets Podcast
P.S. Aflevering 1 hebben we audio issues gehad. Helaas. Kishen (host) valt vaak weg qua audio. We beloven dat we niet meer doen. Ondanks de audio was het wel een leuke aflevering.
Dè developers podcast in je moerstaal : CodeKlets Podcast
/u/454206/crop562d2ccb2479a.png?f=community)
Nice. Misschien ook leuk om ze op Spotify te zetten?:
Klein reclameblokje. Maar voor Devschuur wel relevant. We zijn een tijdje geleden begonnen met een Nederlandstalige podcast voor developers. Er staan inmiddels twee afleveringen online. Aflevering 3 hebben we net opgenomen, en zal begin volgende week online komen. Die aflevering gaat over AR/VR development. Oh en we verloten dan ook een licentie voor een Jetbrains IDE naar keus. Dus sowieso de moeite waard
We richten ons op alle developers, dus niet alleen een specifiek platform of type. We willen juist allerlei soorten developers de revue laten passeren. Inhoudelijk en luchtig.
Url staat in mijn signature. Maar voor de zekerheid : CodeKlets Podcast
P.S. Aflevering 1 hebben we audio issues gehad. Helaas. Kishen (host) valt vaak weg qua audio. We beloven dat we niet meer doen. Ondanks de audio was het wel een leuke aflevering.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Daar staan we al
Als het goed is zijn we vindbaar in alle populaire players.https://open.spotify.com/show/0Sf8c3aGZmtGiNUEwgDTSu
[ Voor 8% gewijzigd door OMX2000 op 18-10-2019 15:38 ]
Dè developers podcast in je moerstaal : CodeKlets Podcast
Recruitment is thuis in het hoofdstuk waar ik zo'n 180 collega's in heb (and counting). Da's de grote geldmachine hier en hun focus waarvoor ze al lastig de vraag kunnen bijbenen. Ik ben alleen en lever niet zoveel op in verhouding
Oftewel: kost teveel tijd.
Tjolk is lekker. overal en altijd.
Als je een micro-ORM zoals Dapper gebruikt, kan een repository pattern wel zijn voordelen hebben.:
[...]
Heb ik nog wel iets aan het Repository pattern? (ik gebruik wel Dapper en geen ORM als EF, die an sich al een abstractie is en waarbij het Repository pattern vaak afgeraden wordt)
Of doe ik er gewoon goed aan om mijn data access functies zaken als de IDbConnection en IDbTransaction simpelweg als parameter mee te geven?
Overengineering is ook slecht natuurlijk. Want ik kan natuurlijk wel een IDbContext maken die naast een IDbConnection ook een IDbTransaction vasthoudt etc, maar het gevoel bekruipt me dat ik nu iets betrekkelijk simpels alleen maar ingewikkelder aan het maken ben
Maybe I should keep it simple. Too much indirection is also bad.
Echter, ik kijk de laatste tijd meer en meer naar een sliced architectuur.
Bij EF of NH zit je idd al met een DbContext of ISession die een UnitOfWork voorstelt, en zeker bij EF heb je met LINQ al een mooie abstractie over je DB. Ik vind het dan beter om Command and Query classes te hebben ipv een repository pattern. (Da's zo 2005
)
https://fgheysels.github.io/
Je krijgt dan echter weer een explosie van het aantal Command and Query classes.:
[...]
Als je een micro-ORM zoals Dapper gebruikt, kan een repository pattern wel zijn voordelen hebben.
Echter, ik kijk de laatste tijd meer en meer naar een sliced architectuur.
Bij EF of NH zit je idd al met een DbContext of ISession die een UnitOfWork voorstelt, en zeker bij EF heb je met LINQ al een mooie abstractie over je DB. Ik vind het dan beter om Command and Query classes te hebben ipv een repository pattern. (Da's zo 2005
Voor zaken die in essentie gewoon functies zijn.
Maar goed, ik zou dus zelf een UnitOfWork pattern kunnen implementeren, of Repositories helemaal niet gebruiken. Maar in dat laatste geval wil ik alsnog mijn queries e.d. kunnen hergebruiken en kun je als simpel alternatief een CustomerFunctions class kunnen maken met bijvoorbeeld GetCustomer(int customerId, IDbConnection dbConnection, IDbTransaction dbTransaction = null).
Dan zijn we wel terug in 2002 ofzo
Ask yourself if you are happy and then you cease to be.
Als je maar ver genoeg abstraheert wordt het mouseclick -> moneyInTheBank:
[...]
Stel je hebt een CustomerRepository waarmee je klantgegevens kunt ophalen en updaten, die gebruikt wordt vanuit een OrderController. Op zo'n moment wil je de verwerking van de order volledig transactioneel hebben, en toch ook graag klantgegevens ophalen / updaten binnen deze transactie bijvoorbeeld.
Dit is even een hypothetisch voorbeeld, maar je wil sommige classes / functies vaak wel vanuit meerdere plekken kunnen gebruiken.
Met een IDbContext kun je dit soort dingen afvangen, omdat deze naast de IDbConnection ook een IDbTransaction vast zou kunnen houden. Aan de andere kant kun je dit ook allemaal overboord gooien en de IDbConnection en IDbTransaction als parameters aan een UpdateCustomer functie meegeven.
Het is simpel en to the point. En nog maar de vraag of ik het ooit door iets anders ga vervangen. IIs dat dat object.Methode().Methode().Methode()?
Je geeft na elke methode aanroep gewoon this terug en dan kun je volgende methode op het object weer aanroepen. k krijg nu namelijk ook allemaal nietszeggende interfaces zoals ICustomerRepository die maar 1 implementatie heeft.
In een functionele programmeertaal zou je zeggen dat het IDbConnection, IDbTransaction -> Customer wordt en dat dit deel van de interface is. Dat impliceert wellicht ook dat het niet logisch is om deze waarden te injecten, maar dat het parameters moeten zijn.
Ik wil dingen "netjes" doen nu ik met .NET Core features zoals DI heb, maar ik moet tegelijkertijd wel zeggen dat het er niet per se beter van wordt (beter leesbaar, onderhoudbaar, etc).
Heb ik nog wel iets aan het Repository pattern? (ik gebruik wel Dapper en geen ORM als EF, die an sich al een abstractie is en waarbij het Repository pattern vaak afgeraden wordt)
Of doe ik er gewoon goed aan om mijn data access functies zaken als de IDbConnection en IDbTransaction simpelweg als parameter mee te geven?
Overengineering is ook slecht natuurlijk. Want ik kan natuurlijk wel een IDbContext maken die naast een IDbConnection ook een IDbTransaction vasthoudt etc, maar het gevoel bekruipt me dat ik nu iets betrekkelijk simpels alleen maar ingewikkelder aan het maken ben
Maybe I should keep it simple. Too much indirection is also bad.
[...]
Waarom moet de recruitment afdeling per se thuis zijn in IT? Omdat ze niet genoeg communiceren met jullie?
Ik neem aan dat jij wel een net lijstje kan maken met wat een kandidaat moet kunnen. Vervolgens kunnen zij het gewoon op diverse kanalen plaatsen (website, job boards, LinkedIn, Facebook, etc).
Wat denken ze dat een StarApple gaat doen dat zij niet kunnen?
Volgens mij heb je een beetje last van analysis paralysis.
[ Voor 3% gewijzigd door Sandor_Clegane op 18-10-2019 17:37 ]
Less alienation, more cooperation.
Jij houdt van die term, meestal gevolgd door "als je nou F# gebruikt, dan...":
[...]
Als je maar ver genoeg abstraheert wordt het mouseclick -> moneyInTheBank
Volgens mij heb je een beetje last van analysis paralysis.
Al neig ik soms wel naar ouderwets rechttoe rechtaan programmeren met functies. Want dan ben ik veel productiever.
Zolang die functies puur zijn en gestructureerd, is daar ook weinig mis mee. Want dan zijn ze nog steeds goed te testen, vinden, hergebruiken etc.
Ik kan mijn collega's geen F# aandoen, dus het moet wel in C#
Ik kan daar wel met static utility classes werken om functies iig bij elkaar te houden.
[ Voor 6% gewijzigd door Lethalis op 18-10-2019 21:02 ]
Ask yourself if you are happy and then you cease to be.
Dat bedoelde ik er niet mee, ik wil niemand wat opdringen.:
[...]
Jij houdt van die term, meestal gevolgd door "als je nou F# gebruikt, dan..."
Al neig ik soms wel naar ouderwets rechttoe rechtaan programmeren met functies. Want dan ben ik veel productiever.
Zolang die functies puur zijn en gestructureerd, is daar ook weinig mis mee. Want dan zijn ze nog steeds goed te testen, vinden, hergebruiken etc.
Ik kan mijn collega's geen F# aandoen, dus het moet wel in C#
Less alienation, more cooperation.
:strip_icc():strip_exif()/u/10274/crop67712295188a6_cropped.jpg?f=community)
:strip_icc():strip_exif()/u/116726/crop5e3ee297a8a03_cropped.jpeg?f=community)
De enige reden die ik kan bedenken is als je vaak tussen meerdere implementaties wil switchen, of simpelweg meerdere wil ondersteunen en dat configureerbaar in het product is.
Functioneel gezien dus dat je klantgegevens uit meerdere bronnen kunt gebruiken.
Komen ze echter altijd uit dezelfde database en gaat dat praktisch nooit veranderen... tsja.
En natuurlijk zal je als OOP fanboy dan zeggen dat er diverse design patterns zijn waardoor je transparant een object kunt wrappen en bijvoorbeeld logging / caching / whatever kunt toevoegen, maar is dat wel handig?
Want in feite verstop je code dan ook. Mensen zoeken zich jaren later de rambam om dat dan te vinden.
Ik heb aardig wat design patterns versleten de afgelopen jaren en bijna altijd dacht ik later "waarom heb ik dit in vredesnaam zo ingewikkeld gemaakt?"
Plus dat mijn collega's veel minder thuis zijn er in, dus die nemen het mij ook niet in dank af.
Indirection maakt code moeilijker te begrijpen. Hoe mooi het in theorie ook is.
Ask yourself if you are happy and then you cease to be.
Het is natuurlijk ook zo dat velen van ons hier gewoon in de business software zitten en niet in de fundamentele frameworks. Wij hebben vaak niet te maken met vele duizenden andere ontwikkelaars die onze interfaces gebruiken, met vele dynamische wensen. Zaken als een uiterst stabiele API / interface, uitbreidbaarheid op alle vlakken, ondersteuning van vele platformen en ga zo maar door leggen veel meer druk op goed geschreven software met de juiste design patterns.:
[...]
De enige reden die ik kan bedenken is als je vaak tussen meerdere implementaties wil switchen, of simpelweg meerdere wil ondersteunen en dat configureerbaar in het product is.
Functioneel gezien dus dat je klantgegevens uit meerdere bronnen kunt gebruiken.
Komen ze echter altijd uit dezelfde database en gaat dat praktisch nooit veranderen... tsja.
En natuurlijk zal je als OOP fanboy dan zeggen dat er diverse design patterns zijn waardoor je transparant een object kunt wrappen en bijvoorbeeld logging / caching / whatever kunt toevoegen, maar is dat wel handig?
Want in feite verstop je code dan ook. Mensen zoeken zich jaren later de rambam om dat dan te vinden.
Ik heb aardig wat design patterns versleten de afgelopen jaren en bijna altijd dacht ik later "waarom heb ik dit in vredesnaam zo ingewikkeld gemaakt?"
Plus dat mijn collega's veel minder thuis zijn er in, dus die nemen het mij ook niet in dank af.
Indirection maakt code moeilijker te begrijpen. Hoe mooi het in theorie ook is.
Niets zo frustrerend als een library of framework dat bij een major version upgrade haar interfaces volledig op de kop gooit.
Refactoren, interfaces herzien en meer van dat soort zaken zijn een stuk eenvoudiger als hoofdzakelijk of zelfs alleen je eigen team gebruikt maakt van interfaces. Het is handig als je kunt anticiperen op toekomstige uitbreidbaarheid en de grote architecturale hoofdlijnen zorgen dat je niet heel hard tegen schaalbaarheidsissues aanloopt, maar al te puristisch zijn is vaak om meerdere redenen niet handig.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Nou, waar ik werkte hadden we alle starapple telefoonnummers geblokkeerd en een email block gemaakt.:
Hmmm... Op zoek naar een collega voor mij.
Onze recruitment afdeling is niet thuis in IT, dus hebben het uitbesteed aan.... starapple
Ik ken ze met name vanwege hun slechte naam. Nu een CV doorgestuurd gekregen waar ik niet op voorhand om sta te juichen. Recruitment afdeling heeft al een afspraak ingepland dus ik ga het maar met open vizier tegemoet. Nog iemand tips?
Als er 1 pauper partij is, is het starapple wel.
Dus qua tip, lol. Ik zou er nog even neutraal in gaan omwille van de sollicitant maar misschien daarna toch eens met HR praten vanwege hun keuzes.
Dit topic is gesloten.