De Devschuur Coffee Corner - Iteratie ⓬

[Wilf]

Hello dev!

Omdat ik de afgelopen 4 jaar per ongeluk een simpel Pythonscriptje heb laten uitgroeien tot 7k regels multitool bij een bedrijf dat nu failliet is EN NIET DOORSTART, plus de meeste uren in het script privé waren, zit ik te denken aan een versie bouwen die ik veilig kan distribueren.

Het gaat mij dan vooral om bescherming van de broncode.

Nou is deze tool vooral Windows-gericht maar ik gebruik ongeveer 70% van de code ook voor Linux en Mac (hier en daar met aanpassingen).

Ik heb 22 jaar geleden met C++ gewerkt maar dat heb ik, stom stom, al tig jaar ook laten verslonzen ten faveure van de webhype (full on op PHP en Flash gedoken).

Is C++ ook nog steeds de ‘way to go’ om een multiplatform tool te schrijven of zijn er in de afgelopen 20 jaar wellicht andere talen bijgekomen die nu écht de edge hebben en waar ik niks van weet (dat laatste weten jullie natuurlijk niet maar zeg dat m’n taalgebruik op dit moment (naast wat niche) = PHP, JS, Python).

- Oh, en ik gebruik nog altijd notepad of Atom en geen echte tools dus daar moet ik denk ik ook eens aan geloven

[ Voor 5% gewijzigd door Wilf op 19-06-2020 08:32 ]

[Ryur]

RobertMe schreef op donderdag 18 juni 2020 @ 17:24:
[...]
IDE is een afgeleide van Intellij, waarvan ik de naam niet durf te noemen . Waarvan ik ook bergen handige features wel gebruik, maar autocomplete echt een stuk minder.

Toch nieuwsgierig welke je dan bedoeld? Ik denk gezien de autocomplete of PHPStorm of RubyMine?

Beide merk ik zijn nog niet zo goed qua autocomplete als de andere producten van ze.
Ik gebruik veel RubyMine, en nu ik de EAP versie gebruik vind ik wel autocompleet stukken beter trouwens!

[Mugwump]

Wilf schreef op vrijdag 19 juni 2020 @ 08:30:
Hello dev!

Omdat ik de afgelopen 4 jaar per ongeluk een simpel Pythonscriptje heb laten uitgroeien tot 7k regels multitool bij een bedrijf dat nu failliet is EN NIET DOORSTART, plus de meeste uren in het script privé waren, zit ik te denken aan een versie bouwen die ik veilig kan distribueren.

Het gaat mij dan vooral om bescherming van de broncode.

Nou is deze tool vooral Windows-gericht maar ik gebruik ongeveer 70% van de code ook voor Linux en Mac (hier en daar met aanpassingen).

Ik heb 22 jaar geleden met C++ gewerkt maar dat heb ik, stom stom, al tig jaar ook laten verslonzen ten faveure van de webhype (full on op PHP en Flash gedoken).

Is C++ ook nog steeds de ‘way to go’ om een multiplatform tool te schrijven of zijn er in de afgelopen 20 jaar wellicht andere talen bijgekomen die nu écht de edge hebben en waar ik niks van weet (dat laatste weten jullie natuurlijk niet maar zeg dat m’n taalgebruik op dit moment (naast wat niche) = PHP, JS, Python).

- Oh, en ik gebruik nog altijd notepad of Atom en geen echte tools dus daar moet ik denk ik ook eens aan geloven

Ik heb geen idee wat precies je requirements zijn en zit zelf niet echt in de hoek van de desktopapplicaties, maar als je toch volop in de 'webontwikkeling' zit / zat, is Electron dan geen optie?
Verder is met .Net core C# ook crossplatform, heb je natuurlijk Java en nog wel wat andere opties.

[RobertMe]

Ryur schreef op vrijdag 19 juni 2020 @ 08:57:
[...]

Toch nieuwsgierig welke je dan bedoeld? Ik denk gezien de autocomplete of PHPStorm of RubyMine?

Beide merk ik zijn nog niet zo goed qua autocomplete als de andere producten van ze.
Ik gebruik veel RubyMine, en nu ik de EAP versie gebruik vind ik wel autocompleet stukken beter trouwens!

De eerste, de taal die hier niet genoemd mag worden omdat die altijd wat discussie losmaakt

En an zich is de autocomplete volgens mij niet slecht. Ik neem me alleen niet de moeite om erop te letten. Als ik iets van zeg eens wat, minder dan 10 letters moet typen, doe ik dat gevoelsmatig sneller zelf / volledig uittypen dan kijken of de juiste optie al in de autocomplete (gemarkeerd) staat en ik nog maar op enter hoef te duwen.

[reputatio]

Wilf schreef op vrijdag 19 juni 2020 @ 08:30:
Hello dev!

Omdat ik de afgelopen 4 jaar per ongeluk een simpel Pythonscriptje heb laten uitgroeien tot 7k regels multitool bij een bedrijf dat nu failliet is EN NIET DOORSTART, plus de meeste uren in het script privé waren, zit ik te denken aan een versie bouwen die ik veilig kan distribueren.

Het gaat mij dan vooral om bescherming van de broncode.

Nou is deze tool vooral Windows-gericht maar ik gebruik ongeveer 70% van de code ook voor Linux en Mac (hier en daar met aanpassingen).

Ik heb 22 jaar geleden met C++ gewerkt maar dat heb ik, stom stom, al tig jaar ook laten verslonzen ten faveure van de webhype (full on op PHP en Flash gedoken).

Is C++ ook nog steeds de ‘way to go’ om een multiplatform tool te schrijven of zijn er in de afgelopen 20 jaar wellicht andere talen bijgekomen die nu écht de edge hebben en waar ik niks van weet (dat laatste weten jullie natuurlijk niet maar zeg dat m’n taalgebruik op dit moment (naast wat niche) = PHP, JS, Python).

- Oh, en ik gebruik nog altijd notepad of Atom en geen echte tools dus daar moet ik denk ik ook eens aan geloven

Ik zou eventueel Golang ook nog overwegen, als het niet om een applicatie met UI gaat. Is ook te cross compilen voor ieder platform.

[Wilf]

Mugwump schreef op vrijdag 19 juni 2020 @ 09:05:
[...]


Ik heb geen idee wat precies je requirements zijn en zit zelf niet echt in de hoek van de desktopapplicaties, maar als je toch volop in de 'webontwikkeling' zit / zat, is Electron dan geen optie?
Verder is met .Net core C# ook crossplatform, heb je natuurlijk Java en nog wel wat andere opties.

Excuses, ik ben echt véél te karig geweest met details (om eerst te checken of dit wel hier thuishoort) maar de app is géén desktop app maar background met web interface. In windows draait het nu NIET als service omdat ik het OS ook aanstuur en verander (en ook diverse andere apps aanstuur).

Het is dus de bedoeling dat het een background service app blijft (en als ik de sandbox kan omzeilen liefst ook een echte service) met alleen server interface. De app zelf stuur je aan via HTML en UDP/TCP en de app zelf genereert ook netwerkverkeer om diverse andere apparaten aan te sturen.

De software is bedoeld voor aansturing van LAN-devices en computers die één specifieke taak vervullen.

[Mugwump]

reputatio schreef op vrijdag 19 juni 2020 @ 09:11:
[...]


Ik zou eventueel Golang ook nog overwegen, als het niet om een applicatie met UI gaat. Is ook te cross compilen voor ieder platform.

En misschien dat ik nu iets heel geks zeg, maar zou Rust geen optie zijn?

[Woy]

Wilf schreef op vrijdag 19 juni 2020 @ 09:16:
[...]
Excuses, ik ben echt véél te karig geweest met details (om eerst te checken of dit wel hier thuishoort) maar de app is géén desktop app maar background met web interface. In windows draait het nu NIET als service omdat ik het OS ook aanstuur en verander (en ook diverse andere apps aanstuur).

Het is dus de bedoeling dat het een background service app blijft (en als ik de sandbox kan omzeilen liefst ook een echte service) met alleen server interface. De app zelf stuur je aan via HTML en UDP/TCP en de app zelf genereert ook netwerkverkeer om diverse andere apparaten aan te sturen.

De software is bedoeld voor aansturing van LAN-devices en computers die één specifieke taak vervullen.

Je zit wel in het juiste gedeelte van GoT, maar niet in het juiste topic. Dit is namelijk gewoon een algemeen topic. Je kunt beter zelf een topic openen. Let daarbij wel even op het beleid, en dan ook met name: Welke programmeertaal moet ik leren?

In dit topic horen dit soort vragen ieder geval niet.

[Mugwump]

Wilf schreef op vrijdag 19 juni 2020 @ 09:16:
[...]
Excuses, ik ben echt véél te karig geweest met details (om eerst te checken of dit wel hier thuishoort) maar de app is géén desktop app maar background met web interface. In windows draait het nu NIET als service omdat ik het OS ook aanstuur en verander (en ook diverse andere apps aanstuur).

Het is dus de bedoeling dat het een background service app blijft (en als ik de sandbox kan omzeilen liefst ook een echte service) met alleen server interface. De app zelf stuur je aan via HTML en UDP/TCP en de app zelf genereert ook netwerkverkeer om diverse andere apparaten aan te sturen.

De software is bedoeld voor aansturing van LAN-devices en computers die één specifieke taak vervullen.

Heel formeel gezien is het hier geen helpdesk volgens de topicpointer, maar dit is in mijn ogen ook weer niet echt een 'help mijn compiler geeft een fout'-vraag of iets dergelijks.

Ik zit zelf niet zo heel erg in de LAN-devices en dergelijke, maar volgens mij kan C++ nog steeds prima hoor. Wil je liever wat nieuws proberen dan is Rust wellicht nog wel optie. Rust is een beetje een 'running gag' als oplossing voor alles, maar volgens mij een prima opvolger van C(++).

Edit: Oh toch niet hier, nou de boel maar even verplaatsen dan?

[Wilf]

Bedankt, ook @Woy, vandaar idd mijn terughoudendheid. Ik had eerst RTFM van deze afdeling maar die las ik te binair (zag geen passende vorm), ik heb inmiddels een open vorm topic geplaatst. M’n reacties hier kunnen verwijderd worden.

[ Voor 22% gewijzigd door Wilf op 19-06-2020 10:07 ]

[hackerhater]

Wilf schreef op vrijdag 19 juni 2020 @ 08:30:
Is C++ ook nog steeds de ‘way to go’ om een multiplatform tool te schrijven of zijn er in de afgelopen 20 jaar wellicht andere talen bijgekomen die nu écht de edge hebben en waar ik niks van weet (dat laatste weten jullie natuurlijk niet maar zeg dat m’n taalgebruik op dit moment (naast wat niche) = PHP, JS, Python).

Wellicht Rust als je erin geintereseerd bent?

Edit, dit is al geopperd

[ Voor 3% gewijzigd door hackerhater op 19-06-2020 09:49 ]

[Skyaero]

Wilf schreef op vrijdag 19 juni 2020 @ 08:30:
Hello dev!

Omdat ik de afgelopen 4 jaar per ongeluk een simpel Pythonscriptje heb laten uitgroeien tot 7k regels multitool bij een bedrijf dat nu failliet is EN NIET DOORSTART, plus de meeste uren in het script privé waren, zit ik te denken aan een versie bouwen die ik veilig kan distribueren.

Dat jij er veel priveuren erin hebt gestopt betekent niet automatisch dat je ook het ip bezit. Als het nog kan zou ik bij de curator vastlsggen dat deze software jouw eigendom wordt. Eventueel "koop" je het ip voir een klein bedrag (bijv 100 euro).

Kan je in de toekomst een hoop gezeik schelen.

[alienfruit]

[b]armageddon_2k1 schreef op vrijdag 19 juni 2020 @ 07:23
@alienfruit Een bearer token voor alle request is toch niet zo’n gekke gedachte?

Klopt, maar ik krijg het tot nu niet voor elkaar om deze token als een header toe te voegen alle uitgaande requests voor https://staging.domein.nl. Ik heb het alleen nog om Cypress te kunnen gebruiken in de Gitlab CI runner die in onze GCP GKE draait. Ik heb al een http proxy geprobeerd voor Cypress alleen dan kan ik geen https requests herschrijven dus moet ik met MITM aan de gang denk ik.

Liefst zou ik gewoon Elastic IPS willen hebben in GCP in een bepaalde reeks voor de automatische scale de Gitlab runners en vervolgens die IP adressen whitelisten. Dus ja, weet nog niet hoe ik dit ga oplossen zonder Google Identity Proxy uit te zetten

[Wilf]

Skyaero schreef op vrijdag 19 juni 2020 @ 10:24:
[...]


Dat jij er veel priveuren erin hebt gestopt betekent niet automatisch dat je ook het ip bezit. Als het nog kan zou ik bij de curator vastlsggen dat deze software jouw eigendom wordt. Eventueel "koop" je het ip voir een klein bedrag (bijv 100 euro).

Er is geen koper voor de boedel en de inboedel (servers, computers et cetera worden gewist); devices komen allemaal leeg op Troostwijk te staan, daarmee effectief verplaatst naar /dev/null.

Was overigens heel veel interesse in boedel, ook voor doorstart, maar curator wilde niet.

[ Voor 54% gewijzigd door Wilf op 19-06-2020 10:30 ]

[hackerhater]

Wilf schreef op vrijdag 19 juni 2020 @ 10:28:
[...]


Er is geen koper voor de boedel en de inboedel (servers, computers et cetera worden gewist); devices komen allemaal leeg op Troostwijk te staan, daarmee effectief verplaatst naar /dev/null.

Was overigens heel veel interesse in boedel, ook voor doorstart, maar curator wilde niet.

Evengoed is het handig het op papier te hebben
Van een van de ex-eigenaars of de curator.
Better have it and not need it, then need it and not have it.

[Jory]

armageddon_2k1 schreef op vrijdag 19 juni 2020 @ 07:23:
[...]


Ik zit al kneedeep in Jetbrains

In dit geval was het bij documentatie van onze API in Markdown. Kan je je afvragen of Markdown code is natuurlijk.....eerlijk gezegd niet.

Ik had eigenlijk verwacht dat hun IDE's daarin ook wel enige mate van autocomplete hebben,maar dat valt vies tegen. Zelfs een class naam aanvullen in een code blokje werkt niet.

Maar goed, ik ging inderdaad uit van echte code, daar werkt de autocomplete voor mij toch wel goed genoeg dat ik zelden een volledige naam uittyp tenzij het een korte variable naam is (Golang, dus r is gewoon een geldige naam ).

[Voutloos]

Wilf schreef op vrijdag 19 juni 2020 @ 10:28:Was overigens heel veel interesse in boedel, ook voor doorstart, maar curator wilde niet.

De enige objectieve interessepeiling is via geld, dus sorry, maar er was blijkbaar onvoldoende interesse.

Misschien pijnlijk nu en/of niet van toepassing: Maar als het idee dat er interesse was door de directeur is gecommuniceerd, moet je dat soort uitspraken met de kennis van nu bijstellen. Alles gaat goed, soms met wat bluf, totdat t te laat is.

En ook:
Ga eens heel gauw wél aan een IDE, maak je eerder druk over IP of incomplete afspraken, en let op privé-uren in het kader van die afspraken.

[Hydra]

Wilf schreef op vrijdag 19 juni 2020 @ 08:30:
Is C++ ook nog steeds de ‘way to go’ om een multiplatform tool te schrijven of zijn er in de afgelopen 20 jaar wellicht andere talen bijgekomen die nu écht de edge hebben en waar ik niks van weet (dat laatste weten jullie natuurlijk niet maar zeg dat m’n taalgebruik op dit moment (naast wat niche) = PHP, JS, Python).

Waarom geen moderne JVM taal als Kotlin? Alle voordelen van Java, geen van de nadelen.

[Hydra]

armageddon_2k1 schreef op vrijdag 19 juni 2020 @ 07:23:
@alienfruit Een bearer token voor alle request is toch niet zo’n gekke gedachte?

Nee, da's heel gangbaar juist. Beetje 'de' manier waarop je met per-client tokens (JWT of session tokens) werkt. De API die ik ontwikkel voor m'n Fintech startup werkt met Firebase Auth (want; waarom zelf bouwen) en daar stuur je ook gewoon na login de token naar m'n API als Auth: Bearer <token> header.

[Woy]

Ik wil de discussie toch even afkappen, een inhoudelijke discussie is prima, maar dan moet @Wilf even een los topic maken met meer informatie over wat hij al overwogen heeft, zodat het niet een standaard Deze taal zou ik nemen topic wordt.

[Hydra]

Sowieso wel een leuk onderwerp voor een topic. Niet zozeer specifiek voor @Wilf maar een "welke technologie zou je gebruiken als je volledig de vrije hand hebt" topic. Dus ook met de argumenten waarom. Denk dat dat wel interessante en leerzame discussies op kan leveren.

[Woy]

Hydra schreef op vrijdag 19 juni 2020 @ 12:47:
[...]


Nee, da's heel gangbaar juist. Beetje 'de' manier waarop je met per-client tokens (JWT of session tokens) werkt. De API die ik ontwikkel voor m'n Fintech startup werkt met Firebase Auth (want; waarom zelf bouwen) en daar stuur je ook gewoon na login de token naar m'n API als Auth: Bearer <token> header.

Yup inderdaad, voor de API's die ik maak maak ik gebruik van Azure AD icm OpenID connect. Zonde om daar zelf veel voor te gaan ontwikkelen, als het al goed in elkaar is gezet door anderen.

[Mugwump]

Hydra schreef op vrijdag 19 juni 2020 @ 12:47:
[...]


Nee, da's heel gangbaar juist. Beetje 'de' manier waarop je met per-client tokens (JWT of session tokens) werkt. De API die ik ontwikkel voor m'n Fintech startup werkt met Firebase Auth (want; waarom zelf bouwen) en daar stuur je ook gewoon na login de token naar m'n API als Auth: Bearer <token> header.

Dat is toch ook gewoon het idee achter de access token in de Oauth spec?
De access token bevat gewoon credentials om een beschermde resource te benaderen. HTTP is een stateless protocol, dus elke call naar een protected resource (vaak een API dus) staat los van de ander en is er dan ook gewoon een die de credentials vereist middels bijvoorbeeld een header. Zie ook niet direct in waarom het meesturen van een extra header moeilijk zou moeten zijn.

[armageddon_2k1]

Hydra schreef op vrijdag 19 juni 2020 @ 12:47:
[...]


Nee, da's heel gangbaar juist. Beetje 'de' manier waarop je met per-client tokens (JWT of session tokens) werkt. De API die ik ontwikkel voor m'n Fintech startup werkt met Firebase Auth (want; waarom zelf bouwen) en daar stuur je ook gewoon na login de token naar m'n API als Auth: Bearer <token> header.

Ja daarom, dat dacht ik dus ook. Dat is ook hoe wij onze API's beveiligen.

[Wilf]

Woy schreef op vrijdag 19 juni 2020 @ 12:47:
[mbr]
Ik wil de discussie toch even afkappen, een inhoudelijke discussie is prima, maar dan moet @Wilf even een los topic maken met meer informatie over wat hij al overwogen heeft, zodat het niet een standaard Deze taal zou ik nemen topic wordt.
[/]

Had ik reeds gemaakt, discussie kan dus naar deze topic.

[Alex)]

.NET Core

Jetbrains

Hierover gesproken.. ik gebruikte eerst Visual Studio Community for Mac als ik .NET-dingen wilde doen op m'n Macbook, maar dat vond ik toch een beetje tegenvallen in vergelijking met de Windows-versie.

Afgelopen weekend heb ik eens een trial van JetBrains' Rider geïnstalleerd op m'n Macbook Air en ben ik daarmee aan het spelen gegaan. Wat een fijne tool is dat. Het werkt grotendeels zoals ik verwacht en wat ik gewend ben van Visual Studio + ReSharper.

[alienfruit]

@Hydra Ja, voor APIs snap ik het wel, maar dit is voor als je een pagina wil bezoeken, moet je dus voor index.html, index.js, logo.png een Authorization header meesturen wat lastig is. Een beetje als het volgende maar dan niet voor API requests maar webserver requests: https://github.com/Q42/IAP-prog-auth en dat is lastig dan is het nog makkelijker gewoon in cypress met Puppeteer de login pagina van Google in te vullen vervolgens de cookies over te kopiëren in je Cypress browser-sessie maar dat kost weer een extra mail account voor GSuite...

[ Voor 28% gewijzigd door alienfruit op 19-06-2020 15:57 ]

[Swedgin]

Swedgin schreef op donderdag 18 juni 2020 @ 12:14:
Ugh. Debuggen in Atmel Studio met code die vooral uit macro's bestaat in geen pretje.

'Step into'
-> springt 10 regels verder

En de optimalisatie stond nog aan
Maar nog klaar geraakt voor de sprint demo vandaag: een interface tussen een touchpanel en een PIC32 door middel van een atmega328p.

[Sebazzz]

Na lange tijd vandaag weer eens gespeeld met Azure. Ik moest even wennen omdat veel dingen die ik kende hernoemd zijn

Als je echter tegen problemen aanloopt, man man man Een application gateway aangemaakt en die naar mijn app service gewezen, en constant een HTTP 502 error en in de health niets anders dan "Ja, je instance is unhealthy" terwijl ik het toch echt direct kan benaderen en de diagnostics goed lopen. Aan de artikelen op de Microsoft Docs heb je ook niets aan.

/rant

[WernerL]

Vandaag eerste versie van mijn eigen website online gezet. Statische react-site die geserveerd wordt door nodes. Mijn hele backend is 15 regels code.

Heroku werkt ook erg nice trouwens. Ik kan nu deployen door simpelweg naar master te pushen. Configuratie ging vrij eenvoudig. Met Azure in het verleden meer tijd kwijt geweest aan build en release pipelines.

[scosec]

WernerL schreef op zaterdag 20 juni 2020 @ 14:18:
Vandaag eerste versie van mijn eigen website online gezet. Statische react-site die geserveerd wordt door nodes. Mijn hele backend is 15 regels code.

Heroku werkt ook erg nice trouwens. Ik kan nu deployen door simpelweg naar master te pushen. Configuratie ging vrij eenvoudig. Met Azure in het verleden meer tijd kwijt geweest aan build en release pipelines.

En toch werkt azure devops subliem kan ik je vertellen. Wij gebruiken het voor alle projecten. We hosten dan ook alle spulletjes in azure. Dat maakt het misschien wel eenvoudiger.

[Immutable]

Hebben jullie wel eens bij een bedrijf gewerkt waar het Not Invented Here syndroom heerst? Waarbij managers totaal geen verstand hebben van software en waarbij de product owner dus last hiervan heeft en de meeste andere developers van school komen en of niet bij veel andere bedrijven gewerkt hebben?

Ik zelf zit op een andere afdeling, maar het product heeft wel invloed op mijn werk. Ik zelf ben altijd een persoon van dat ik libraries en systemen gebruik die al ontwikkeld zijn en zich bewezen hebben.
Voor die product owner is het product echt zijn kindje, en ik zie steeds requirements komen die heel normaal zijn in moderne systemen. Tevens is de performance heel laag, en hikken we tegen de limieten. Bestaande systemen kunnen 100.000x zoveel zaken aan als nu de limiet is op dezelfde CPU.

Eigenlijk kan je zelfs een paar bestaande libraries/frameworks samenvoegen met een configurator en tada heb je hetzelfde product, maar dan wel bij de tijd en modern. En aankomende requirements zijn peanuts!

Product owner wil en zal zijn kindje beschermen, en gaat een plan schrijven om desbetreffende requirement te implementeren en de daarbij behorende uren. Ik weet dat dat een gigantische sunk cost gaat worden in de toekomst. Want het systeem waar het op gebouwd is, is heel ouderwets en niet bedoelt voor waar we het voor gebruiken. Die extra requirement is doodnormaal in nieuwere systemen. Product owner wil en zal dit implementeren in zijn kindje, en vaak lukt het uiteindelijk ook wel na HEEL VEEL uren. Maar het resultaat is echt belabberd en niet bij de tijd. Product owner is heel erg charismatisch en kan goed managers overtuigen en enthousiast maken. Maar ik weet dat de uiteindelijke klanten en mensen die het systeem gebruiken niet erg tevreden zijn en vinden het gebruiksonvriendelijk, traag en lastig. etc. Maar daar kijken deze managers niet naar.

Ik ben zelf een allemans-vriend en hou graag iedereen te vriend. Echter zie ik dit gebeuren en denk van... kan ik daar überhaupt iets aan doen zonder dat ik een slechte relatie krijg met deze product owner?
Daarnaast, met de managers praten helpt niet want die snappen niks van Software, laat staat psychologie of als ik zeg "sunk cost" zegt ze ook niks.

Ooit wel eens in zo'n situatie gezeten? Of bedrijf?

[Alex)]

Ja hoor, ik heb ook al eens in zo'n situatie gezeten.

De klant wilde een systeem waarmee monteurs in het veld bepaalde checklists konden afwerken. Dit hadden ze bij ons neergelegd, "kunnen jullie dit regelen?" Natuurlijk kan dat. De lead developer/architect was al meteen een technisch ontwerp voor een maatwerk .NET-applicatie gaan uitdenken, inclusief het optuigen van een supportorganisatie offshore. Ik hoefde er alleen nog maar even een verwacht aantal developmenturen op te plakken, en het zou ter accordering naar de klant gaan.

Toevallig zag ik een keer op internet een advertentie voor een applicatie die het op mobiele apparaten afwerken van checklists aanbood. Gewoon als commercial off-the-shelf software als mobiele app. Met offline functionaliteit, camera, SSO, et cetera. Alles wat de klant wilde, en meer. Tegen een zeer schappelijke prijs van een paar euro per user per maand, met eventueel opties voor staffelkorting.

Toen ik dat tegen de architect vertelde werd ik vrijwel genegeerd. Hij vulde zelf het verwachte aantal uren in en stuurde het op naar de klant. Die ging akkoord, maar door omstandigheden werd het project uitgesteld. De architect verliet uiteindelijk het bedrijf en werd vervangen door iemand anders.

Een tijd later kwam dit project weer bij mij en m'n collega's op het bord te liggen. De nieuwe architect wilde van de hoed en de rand weten, en vroeg aan mij wat ik wist. Dus ik legde uit wat ik wist, en vertelde ook over de app die ik toevallig was tegengekomen. De nieuwe architect was hierin heel erg geïnteresseerd en heeft het uitgeprobeerd. Hij was overtuigd en heeft de klant overgehaald om uiteindelijk hiervoor te kiezen i.p.v. maatwerk.

[alienfruit]

Na veel geklungel heb ik Cypress, een MITM SSL proxy met generated root certificate voor IAP requests werkend in Docker tbv. Gitlab runner. Toch altijd weer gaaf als iets begint te werken na uren bezig te zijn.

[armageddon_2k1]

WernerL schreef op zaterdag 20 juni 2020 @ 14:18:
Vandaag eerste versie van mijn eigen website online gezet. Statische react-site die geserveerd wordt door nodes. Mijn hele backend is 15 regels code.

Heroku werkt ook erg nice trouwens. Ik kan nu deployen door simpelweg naar master te pushen. Configuratie ging vrij eenvoudig. Met Azure in het verleden meer tijd kwijt geweest aan build en release pipelines.

Oeh, dat klinkt leuk. Heb je een link naar wat meer info misschien? Of is het Gatsby?

[WernerL]

Meer info over het automatisch deployen? Ik heb daarvoor deze stappen gevolgd: https://devcenter.heroku.com/articles/deploying-nodejs

Heroku verwacht dus een package.json of een Procfile met een start en build commando. build om je applicatie te builden, en start voor het starten van de applicatie die http requests kan serveren.

Ziet er in mijn geval zo uit:

code:

{
  "name": "WernerL-website",
  "version": "1.0.0",
  "description": "",
  "main": "",
  "scripts": {
    "build": "cd client && yarn && yarn build",
    "start": "node server.js",
  },
 
[...]

  "dependencies": {
    "express.js": "^1.0.0"
  }
}

Vervolgens binnen Heroku een release-pipeline aanmaken die een deploy triggert bij wijzigingen in master.

[ Voor 7% gewijzigd door WernerL op 21-06-2020 08:46 ]

[alienfruit]

Ja, er is ook een open-source kloon hiervan:https://github.com/gliderlabs/herokuish
Wordt ook gebruikt door Gitlab zonder veel upstream PRs

[dev10]

Taart voor iedereen uit de Devschuur!

[.oisyn]

Feli @dev10

[hackerhater]

Gefeliciteerd @dev10

[Creepy]

Tijd voor koffie en taart blijkbaar Gefeliciteerd!

[alienfruit]

Ik kan niet wachten om weer naar Nederland te gaan en een lekkere Limburgse vlaai te eten

[Mugwump]

Ik sla over, veel te veel suiker.
Maar toch gefeliciteerd!

[Koenvh]

Mugwump schreef op dinsdag 23 juni 2020 @ 11:13:
Ik sla over, veel te veel suiker.
Maar toch gefeliciteerd!

Geen probleem, meer voor mij

Gefeliciteerd @dev10

[Hydra]

Die ziet er goed uit. Gefeliciteerd!

[Hydra]

Immutable schreef op zaterdag 20 juni 2020 @ 19:17:
Hebben jullie wel eens bij een bedrijf gewerkt waar het Not Invented Here syndroom heerst?

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[downtime]

Alex) schreef op zondag 21 juni 2020 @ 00:19:

De nieuwe architect was hierin heel erg geïnteresseerd en heeft het uitgeprobeerd. Hij was overtuigd en heeft de klant overgehaald om uiteindelijk hiervoor te kiezen i.p.v. maatwerk.

En wat zei het management toen ze erachter kwamen dat hun architect de klant belangrijker vindt dan de eigen omzet?

[Alex)]

downtime schreef op dinsdag 23 juni 2020 @ 16:28:
[...]

En wat zei het management toen ze erachter kwamen dat hun architect de klant belangrijker vindt dan de eigen omzet?

Ik denk dat het niet zo veel zou hebben uitgemaakt, het was een erg grote klant en dit project zou 'pocket money' zijn qua omvang.

[kwaakvaak_v2]

downtime schreef op dinsdag 23 juni 2020 @ 16:28:
[...]

En wat zei het management toen ze erachter kwamen dat hun architect de klant belangrijker vindt dan de eigen omzet?

Eerlijkheid naar je klant is meestal meer waard dan die omzet. Zeker als het een klant is die meerdere diensten afneemt bij je.

Plus op de lange duur is het outsourcen van dit soort complexe producten vaak goedkoper dan het kost wat kost in huis te willen maken. Onderhoud of bug fixing kan aardig in de papieren lopen en afhankelijk van de SLA niet altijd worden door belast aan de klant.

[Alex)]

Als consultant moet je, naar mijn mening, ook kijken naar wat in het belang is van je klant en niet alleen naar je eigen bottom line. De doorlooptijd die bij zo'n maatwerkapplicatie komt kijken is lang, hosting en onderhoud zijn doorlopende kosten, en als er een keer een change request komt kan de doorlooptijd daarvan wederom erg lang zijn.

Als er een kant-en-klaar product te koop is dat precies doet wat je wilt (en meer kan), waarom zou je dan een klant adviseren om fors te investeren om een maatwerkapplicatie te maken?

In mijn geval was er nog een factor: de applicatie die ons gevraagd werd te ontwikkelen zou vanaf mobiele apparaten gebruikt moeten worden, zowel Apple als Android. Niemand in het team waar ik destijds in zat had daar enige ervaring mee.

De oorspronkelijke architect had bedacht dat het een progressive web app zou moeten worden (inclusief offline support), wederom technologie waar niemand in mijn team mee bekend was. Dat zie ik als een risico: wat als het niet werkt zoals verwacht? Of veel langer duurt dan gepland?

Dan is een paar euro per gebruiker per maand voor een off-the-shelf product + support echt zo gek nog niet. Het neemt ook een hoop risico's weg.

[ Voor 30% gewijzigd door Alex) op 23-06-2020 18:17 ]

[esv77]

Alex) schreef op dinsdag 23 juni 2020 @ 18:15:
Als consultant moet je, naar mijn mening, ook kijken naar wat in het belang is van je klant en niet alleen naar je eigen bottom line. De doorlooptijd die bij zo'n maatwerkapplicatie komt kijken is lang, hosting en onderhoud zijn doorlopende kosten, en als er een keer een change request komt kan de doorlooptijd daarvan wederom erg lang zijn.

Als er een kant-en-klaar product te koop is dat precies doet wat je wilt (en meer kan), waarom zou je dan een klant adviseren om fors te investeren om een maatwerkapplicatie te maken?

In mijn geval was er nog een factor: de applicatie die ons gevraagd werd te ontwikkelen zou vanaf mobiele apparaten gebruikt moeten worden, zowel Apple als Android. Niemand in het team waar ik destijds in zat had daar enige ervaring mee.

De oorspronkelijke architect had bedacht dat het een progressive web app zou moeten worden (inclusief offline support), wederom technologie waar niemand in mijn team mee bekend was. Dat zie ik als een risico: wat als het niet werkt zoals verwacht? Of veel langer duurt dan gepland?

Dan is een paar euro per gebruiker per maand voor een off-the-shelf product + support echt zo gek nog niet. Het neemt ook een hoop risico's weg.

Hoe pakken jullie dat normaal gesproken aan dan met technologie waar nog niemand bekend mee is? Blijven jullie daarbij weg of experimenteren jullie daar zelf mee of zo?

[Alex)]

Meestal is er wel wat ruimte voor experimenteren en het bouwen van een Proof of Concept te vinden.

Dat was hier eigenlijk niet het geval, er werd een werkend product verwacht (logisch) maar de estimates die waren bedacht waren gebaseerd op helemaal niets.

[ZaZ]

Ik kom er nu pas achter dat Groenland ongeveer even groot is als Mexico. Ik wist dat de kaart zoals we 'm altijd zien een beetje vertekend is maar dat het zo extreem is schrik ik eigenlijk wel van.
Brazilie (8.516.000 km²) is zelfs 4 keer zo groot als Groenland (2.166.000 km²) terwijl laatstgenoemde op de kaart duidelijk groter is!
Dit zullen een heel aantal van jullie vast al weten maar ik heb effe een WTF moment.

[.oisyn]

Mercator for the lose

[ZaZ]

Ja, ik ben inmiddels op de hoogte

[RayNbow]

Maar ja, wie projecteert er nou op een cilinder? Je moet gewoon op een vlak projecteren...

[xFeverr]

Aan de dev'ers die, net als ik (helaas), veel in Xcode moeten zitten: het wordt echt een feest, de komende release!

Want, Xcode 12 heeft ze dan toch eindelijk: Tabbladen die wél werken!
Dus niet meer op bases van vensters, maar op basis van documenten. Zoals eigenlijk elke IDE doet! FINALY!

Ik wou dit vreugdedansje even met jullie delen. Het gebrek van goed werkende tabbladen is namelijk echt een van de (vele) grote ergernissen die ik heb met Xcode. Nu wachten tot de uiteindelijke release...

Nu ik erover nadenk: toch eigenlijk best gek dat ze op WWDC niet eens even de nieuwe features van Xcode laten zien in de keynote. Het is toch voor developers?

[ Voor 14% gewijzigd door xFeverr op 24-06-2020 09:24 ]

[kwaakvaak_v2]

xFeverr schreef op woensdag 24 juni 2020 @ 09:21:

Nu ik erover nadenk: toch eigenlijk best gek dat ze op WWDC niet eens even de nieuwe features van Xcode laten zien in de keynote. Het is toch voor developers?

De publieke keynote is vooral voor de investeerders,media mensen en de Apple fans. Vandaar dat er meestal heel vluchtig over nieuwe API dingen etc heen gesprongen wordt.

[Sharkware]

ZaZ schreef op woensdag 24 juni 2020 @ 01:18:
Ik kom er nu pas achter dat Groenland ongeveer even groot is als Mexico. Ik wist dat de kaart zoals we 'm altijd zien een beetje vertekend is maar dat het zo extreem is schrik ik eigenlijk wel van.
Brazilie (8.516.000 km²) is zelfs 4 keer zo groot als Groenland (2.166.000 km²) terwijl laatstgenoemde op de kaart duidelijk groter is!
Dit zullen een heel aantal van jullie vast al weten maar ik heb effe een WTF moment.

Deze site tegengekomen? https://thetruesize.com/

[RayNbow]

Sharkware schreef op woensdag 24 juni 2020 @ 09:39:
[...]


Deze site tegengekomen? https://thetruesize.com/

En dan iets richting de polen slepen...

[gekkie]

RayNbow schreef op woensdag 24 juni 2020 @ 10:22:
[...]
En dan iets richting de polen slepen...

Werkt wel goed. Nederland los hakken en naar de pool slepen.

Misschien wat voor meneer B i audet: "Make the Netherlands great again ut etiam magna Belgio" (of iets dergelijks) .

edit: Ohh opa vertel toch nog eens over vroeger, toen kwetsen nog zure droge pruimen waren ...

[ Voor 21% gewijzigd door gekkie op 24-06-2020 12:14 ]

[Matis]

gekkie schreef op woensdag 24 juni 2020 @ 10:52:
Werkt wel goed. Nederland los hakken en naar de pool slepen.

En als je dan het land verwijderd (rechter muisknop) dan blijft ie oneindig scrollen

Misschien wat voor meneer Bidet: "Make the Netherlands great again" .

Ik ben (ook) geen fan van de standpunten van de beste man of hoe hij ze presenteert, maar behandel hem wel respectvol door hem te noemen zoals hij heet.

Door zijn naam op zo'n kinderachtige (spottende) manier te gebruiken verlaag je je bij mij tot een niveau / persoon waarmee niet serieus te praten en/of te discussiëren valt.

Zelfde als van die voetbal"fans" die de clubnaam van de tegenstander niet uit durven spreken of een geuzennaam gebruiken: Ajakkes zus, Feyenooit zo, Pisvee dit...

[ Voor 6% gewijzigd door Matis op 24-06-2020 11:26 ]

[Hydra]

Alex) schreef op dinsdag 23 juni 2020 @ 18:15:
Als consultant moet je, naar mijn mening, ook kijken naar wat in het belang is van je klant en niet alleen naar je eigen bottom line.

Precies. Dat maakt vind ik ook het verschil tussen een "consultant" en een developer die bij een klant gezet woordt. Consulting is primair advies geven en als het goed is, is dat het advies dat het beste is voor die klant.

Komt nog eens bij dat echt goed zijn in je werk, ook als dat op korte termijn betekent dat je een project niet hoeft te doen, waarschijnlijk op de lange termijn veel meer business op gaat leveren. Als 'bedrijf' is je reputatie alles.

[Hydra]

esv77 schreef op dinsdag 23 juni 2020 @ 20:24:
Hoe pakken jullie dat normaal gesproken aan dan met technologie waar nog niemand bekend mee is? Blijven jullie daarbij weg of experimenteren jullie daar zelf mee of zo?

Als iemand die nu aan de andere kant van de tafel zit: als wij een bedrijf inhuren voor werk is het 'leren' van dingen die ook voor andere klanten van toepassing kunnen zijn niet voor onze rekening. Trainen van je personeel doe je in je eigen tijd en niet op onze kosten. Dit stemmen we vooraf ook af; dus als het voor hen dan niet rendabel is, is dat het moment om het te zeggen.

[Hydra]

Matis schreef op woensdag 24 juni 2020 @ 11:26:
Ik ben (ook) geen fan van de standpunten van de beste man of hoe hij ze presenteert, maar behandel hem wel respectvol door hem te noemen zoals hij heet.

Respect verdien je en kun je verliezen. Je kunt niet op die manier over vrouwen en buitenlanders tekeer gaan, en dan de gebeten hond gaan spelen als mensen je een klojo vinden en zich zo naar je gaan gedragen. Daarbij is sjefke Thierry vast wel wat meer gewend dan "Bidet" genoemd te worden

[gekkie]

Matis schreef op woensdag 24 juni 2020 @ 11:26:
[...]
En als je dan het land verwijderd (rechter muisknop) dan blijft ie oneindig scrollen
[...]
Ik ben (ook) geen fan van de standpunten van de beste man of hoe hij ze presenteert, maar behandel hem wel respectvol door hem te noemen zoals hij heet.

Door zijn naam op zo'n kinderachtige (spottende) manier te gebruiken verlaag je je bij mij tot een niveau / persoon waarmee niet serieus te praten en/of te discussiëren valt.

Zelfde als van die voetbal"fans" die de clubnaam van de tegenstander niet uit durven spreken of een geuzennaam gebruiken: Ajakkes zus, Feyenooit zo, Pisvee dit...

De meneer die regelmatig een pleefiguur slaat is wel acceptabel voor je ?

[Crazy D]

Hydra schreef op woensdag 24 juni 2020 @ 12:05:
[...]


Precies. Dat maakt vind ik ook het verschil tussen een "consultant" en een developer die bij een klant gezet woordt. Consulting is primair advies geven en als het goed is, is dat het advies dat het beste is voor die klant.

Komt nog eens bij dat echt goed zijn in je werk, ook als dat op korte termijn betekent dat je een project niet hoeft te doen, waarschijnlijk op de lange termijn veel meer business op gaat leveren. Als 'bedrijf' is je reputatie alles.

Maar die grens is wel dun. Als zelfstandige wellicht iets eenvoudiger te maken (of wellicht wel niet, als je de komende 3 maanden nog niets anders op de agenda hebt staan) maar in loondienst gaan de meeste werkgevers je niet zo waarderen als je een opdracht van 50k misloopt omdat er ook een standaard tooltje van een paar euro is wat redelijk doet wat de klant wil. Dan zijn er toch echt wat minder werkgevers heel blij met je. Uiteraard, in werkelijkheid zijn dingen weer niet zwart-wit en dan hangt het van de klant af. Als je al tig uren per maand draait bij die klant zal de werkgever er minder moeite mee hebben dan wanneer dit de enige opdracht had kunnen zijn...

[Mugwump]

Crazy D schreef op woensdag 24 juni 2020 @ 12:48:
[...]

Maar die grens is wel dun. Als zelfstandige wellicht iets eenvoudiger te maken (of wellicht wel niet, als je de komende 3 maanden nog niets anders op de agenda hebt staan) maar in loondienst gaan de meeste werkgevers je niet zo waarderen als je een opdracht van 50k misloopt omdat er ook een standaard tooltje van een paar euro is wat redelijk doet wat de klant wil. Dan zijn er toch echt wat minder werkgevers heel blij met je. Uiteraard, in werkelijkheid zijn dingen weer niet zwart-wit en dan hangt het van de klant af. Als je al tig uren per maand draait bij die klant zal de werkgever er minder moeite mee hebben dan wanneer dit de enige opdracht had kunnen zijn...

Ligt heel erg aan de situatie. Wij hebben ook wel eens een klant heel duidelijk geadviseerd om absoluut niet te beginnen aan een stuk nieuwbouw voor iets waar echt legio prima off-the-shelf oplossingen voor zijn, maar ze eisten een offerte. Vervolgens sloegen ze stijl achterover van de kosten, want off-the-shelf oplossingen waren veel goedkoper. Goh, echt? Waarom dacht je dat we dat adviseerden?

Mensen lijken vaak nog wel eens te denken dat hun situatie volkomen uniek is en elk bedrijf heeft natuurlijk z'n eigen eigenaardigheden, maar meestal levert een maatwerkapplicatie voor iets als voorraadbeheer je meer ellende op dan een standaardoplossing en kun je 99% van je werk gewoon in die applicaties kwijt. Die obscure edge case kun je dan wel op een andere manier oplossen.

[Ghehe]

Mugwump schreef op woensdag 24 juni 2020 @ 13:06:
[...]
Mensen lijken vaak nog wel eens te denken dat hun situatie volkomen uniek is en elk bedrijf heeft natuurlijk z'n eigen eigenaardigheden, maar meestal levert een maatwerkapplicatie voor iets als voorraadbeheer je meer ellende op dan een standaardoplossing en kun je 99% van je werk gewoon in die applicaties kwijt. Die obscure edge case kun je dan wel op een andere manier oplossen.

SAP

[Mugwump]

Ghehe schreef op woensdag 24 juni 2020 @ 13:31:
[...]


SAP

Ik zei 'prima'.

[Pizzalucht]

Mugwump schreef op woensdag 24 juni 2020 @ 14:12:
[...]


Ik zei 'prima'.

AFAS?

[Matis]

Mugwump schreef op woensdag 24 juni 2020 @ 13:06:
Mensen lijken vaak nog wel eens te denken dat hun situatie volkomen uniek is en elk bedrijf heeft natuurlijk z'n eigen eigenaardigheden, maar meestal levert een maatwerkapplicatie voor iets als voorraadbeheer je meer ellende op dan een standaardoplossing en kun je 99% van je werk gewoon in die applicaties kwijt. Die obscure edge case kun je dan wel op een andere manier oplossen.

Bij ons gebeurt juist het tegenovergestelde. Hier proberen ze juist alles in SAP te frotten.

Dat heeft de afgelopen decennia geleid tot een draak van een monoliet waar niemand meer aan durft te komen en dat al lang niet meer te herkennen is als SAP.

Ik stel af en toe voor om gedeelten uit SAP naar microservices te verplaatsen, maar tot op heden tegen dovemansoren.

[Mugwump]

Matis schreef op woensdag 24 juni 2020 @ 14:28:
[...]

Bij ons gebeurt juist het tegenovergestelde. Hier proberen ze juist alles in SAP te frotten.

Dat heeft de afgelopen decennia geleid tot een draak van een monoliet waar niemand meer aan durft te komen en dat al lang niet meer te herkennen is als SAP.

Ik stel af en toe voor om gedeelten uit SAP naar microservices te verplaatsen, maar tot op heden tegen dovemansoren.

Zie post van 14:12.

Maar verder bedoel ik ook vooral "Kies een passend off-the-shelf-product", niet "Ram alles in SAP / Salesforce / Dynamics / whatever".

[Hydra]

Crazy D schreef op woensdag 24 juni 2020 @ 12:48:
Maar die grens is wel dun. Als zelfstandige wellicht iets eenvoudiger te maken (of wellicht wel niet, als je de komende 3 maanden nog niets anders op de agenda hebt staan) maar in loondienst gaan de meeste werkgevers je niet zo waarderen als je een opdracht van 50k misloopt omdat er ook een standaard tooltje van een paar euro is wat redelijk doet wat de klant wil. Dan zijn er toch echt wat minder werkgevers heel blij met je. Uiteraard, in werkelijkheid zijn dingen weer niet zwart-wit en dan hangt het van de klant af. Als je al tig uren per maand draait bij die klant zal de werkgever er minder moeite mee hebben dan wanneer dit de enige opdracht had kunnen zijn...

Je kunt het ook gewoon eerst met je werkgever afstemmen natuurlijk Ik zou zelf overigens niet blijven werken voor een werkgever die er zo instaat.

[Hydra]

Matis schreef op woensdag 24 juni 2020 @ 14:28:
Ik stel af en toe voor om gedeelten uit SAP naar microservices te verplaatsen, maar tot op heden tegen dovemansoren.

Hoeveel mensen in die organisatie hebben al ruime ervaring met microservices?

[Matis]

Hydra schreef op woensdag 24 juni 2020 @ 15:29:
Hoeveel mensen in die organisatie hebben al ruime ervaring met microservices?

Twee, ik en een collega. Maar ik heb het gevoel dat een aantal collega's het systeem ook niet uit wíllen kleden, omdat dit hun pensioengarantie is.
Zij zijn de enige die min of meer snappen en kunnen doorgronden hoe het systeem werkt. Maar ook daar komen steeds meer scheuren in.

Het systeem blijkt pleister op pleister te zijn. En niemand weet exact wat de impact is als er een pleister wordt verwijderd.

[Hydra]

Matis schreef op woensdag 24 juni 2020 @ 15:40:
Twee, ik en een collega.

Dat vind ik nog best riskant. Niet dat ik geloof dat de huidige weg zo fantastisch is, maar microservices zijn complex en het gaat lastig zijn in zo'n organisatie de boel op de rails te houden. Mijn ervaring is dat je, als je niet een flink aantal goeie senior devs hebt die distrubuted programming snappen, het vrij snel een grote spaghetti wordt.

[Creepy]

Pizzalucht schreef op woensdag 24 juni 2020 @ 14:23:
[...]


AFAS?

Hij zei "prima" he

[Matis]

Hydra schreef op woensdag 24 juni 2020 @ 17:49:
Dat vind ik nog best riskant. Niet dat ik geloof dat de huidige weg zo fantastisch is, maar microservices zijn complex en het gaat lastig zijn in zo'n organisatie de boel op de rails te houden. Mijn ervaring is dat je, als je niet een flink aantal goeie senior devs hebt die distrubuted programming snappen, het vrij snel een grote spaghetti wordt.

Daarmee bedoel ik, dat ik zeker weet dat ze het weten. Volgens mij zijn er veel meer mensen binnen die afdeling die weten hoe het werkt, maar die houden wijselijk de kaken op elkaar.

SAP is een andere afdeling/business unit dan de dev afdeling. Bij "ons" is er wel veel meer ervaring met microservices. Wij zijn van het maatwerk, zij van SAP.

Daar zal ook wel een deel van de schrik van de transitie liggen. Dat is letterlijk tornen aan je eigen bestaansrecht binnen de organisatie.

[kwaakvaak_v2]

Mugwump schreef op woensdag 24 juni 2020 @ 13:06:
[...]


Mensen lijken vaak nog wel eens te denken dat hun situatie volkomen uniek is en elk bedrijf heeft natuurlijk z'n eigen eigenaardigheden, maar meestal levert een maatwerkapplicatie voor iets als voorraadbeheer je meer ellende op dan een standaardoplossing en kun je 99% van je werk gewoon in die applicaties kwijt. Die obscure edge case kun je dan wel op een andere manier oplossen.

100% van alle applicaties is data processing

er komt iets in ->super unieke magische toestanden -> er komt iets uit.

[Mugwump]

kwaakvaak_v2 schreef op woensdag 24 juni 2020 @ 19:18:
[...]


100% van alle applicaties is data processing

er komt iets in ->super unieke magische toestanden -> er komt iets uit.

Ja en alles is nullen en enen!

[RayNbow]

kwaakvaak_v2 schreef op woensdag 24 juni 2020 @ 19:18:
er komt iets in ->super unieke magische toestanden -> er komt iets uit.

Wat als er niets uit komt rollen?

[kwaakvaak_v2]

RayNbow schreef op woensdag 24 juni 2020 @ 19:47:
[...]

Wat als er niets uit komt rollen?

dan begint de lol pas echt

[WernerL]

Hydra schreef op woensdag 24 juni 2020 @ 17:49:
[...]


Dat vind ik nog best riskant. Niet dat ik geloof dat de huidige weg zo fantastisch is, maar microservices zijn complex en het gaat lastig zijn in zo'n organisatie de boel op de rails te houden. Mijn ervaring is dat je, als je niet een flink aantal goeie senior devs hebt die distrubuted programming snappen, het vrij snel een grote spaghetti wordt.

Dat probleem heb je met een monolith ook.

Ik begrijp sowieso niet waarom zoveel bedrijven ineens microservices willen hebben. In veel gevallen kun je prima wegkomen met een monolith waarin eventueel een klein aantal services losgekoppeld zijn waar dat zinvol is imho.

[Sebazzz]

HeT iS ScAlABlE eN ClOUd rEaddY!?



Microservices vereisen echt een stricte scheiding in je subdomeinen. Als je die niet hebt dan ben je gewoon een onhandige monolith aan het bouwen.

[bwerg]

WernerL schreef op woensdag 24 juni 2020 @ 20:14:
Dat probleem heb je met een monolith ook.

Je zou bijna gaan denken dat het gewoon inherent is aan een complex product maken.

[Koenvh]

Sebazzz schreef op woensdag 24 juni 2020 @ 22:13:
HeT iS ScAlABlE eN ClOUd rEaddY!?



Microservices vereisen echt een stricte scheiding in je subdomeinen. Als je die niet hebt dan ben je gewoon een onhandige monolith aan het bouwen.

Webscale! Overigens zijn microservices zo 2019, nu is ISPaaS helemaal in: Infrastructure Service Platform as a Service, oftewel, niks meer zelf in huis hebben, maar alles door anderen laten doen. Kun je al je personeel (behalve je management) eruit gooien

[Vincentio]

Matis schreef op woensdag 24 juni 2020 @ 18:17:
[...]

Daarmee bedoel ik, dat ik zeker weet dat ze het weten. Volgens mij zijn er veel meer mensen binnen die afdeling die weten hoe het werkt, maar die houden wijselijk de kaken op elkaar.

SAP is een andere afdeling/business unit dan de dev afdeling. Bij "ons" is er wel veel meer ervaring met microservices. Wij zijn van het maatwerk, zij van SAP.

Daar zal ook wel een deel van de schrik van de transitie liggen. Dat is letterlijk tornen aan je eigen bestaansrecht binnen de organisatie.

Dan wordt het wel tijd voor hun om dat te gaan leren. Zo min mogelijk maatwerk in je core SAP systeem. Maatwerk op SAP moet je buiten de core doen. Dit kan gemakkelijk met de Cloud. En SAP heeft daar ook allerlei oplossingen bij, including microservices.

[Matis]

Vincentio schreef op donderdag 25 juni 2020 @ 08:16:
Dan wordt het wel tijd voor hun om dat te gaan leren. Zo min mogelijk maatwerk in je core SAP systeem. Maatwerk op SAP moet je buiten de core doen. Dit kan gemakkelijk met de Cloud. En SAP heeft daar ook allerlei oplossingen bij, including microservices.

Klopt, we zijn nu langzaamaan processen aan het verplaatsen naar Del Boomi (een iPaaS) zoals @Koenvh al opmerkte

[Mugwump]

WernerL schreef op woensdag 24 juni 2020 @ 20:14:
[...]


Dat probleem heb je met een monolith ook.

Ik begrijp sowieso niet waarom zoveel bedrijven ineens microservices willen hebben. In veel gevallen kun je prima wegkomen met een monolith waarin eventueel een klein aantal services losgekoppeld zijn waar dat zinvol is imho.

Hip en hype natuurlijk. Lijkt goed te passen binnen de hippe Agile werkwijze met korte TTM, snelle iteratieve cycli en ga zo maar door. Er zitten ook best voordelen aan. Als je een monsterlijk stuk software op een gigantische geclusterde applicatieserver draait, dan wordt het nog wel eens lastig om te achterhalen waar je resourceproblemen nou precies vandaan komen. Als het allemaal losse, kleinere onderdelen zijn, dan kun je vaak al veel gerichter analyseren. Releasen van losse onderdelen wordt veel makkelijker. Je zit andere onderdelen ook niet in de weg.
Wat je alleen vaak ziet is dat men er compleet in doorslaat en de kleinst mogelijke deploybare stukjes code verpakt in een 'microservice' die dan ook nog vaak middels synchrone communicatie via HTTP werkt. Dan krijg je echt een deployment hell en bovendien maak je van voorheen zeer betrouwbare calls binnen een stuk software opeens calls over een netwerk met alle risico's en problemen van dien.

[Immutable]

Sebazzz schreef op woensdag 24 juni 2020 @ 22:13:
HeT iS ScAlABlE eN ClOUd rEaddY!?



Microservices vereisen echt een stricte scheiding in je subdomeinen. Als je die niet hebt dan ben je gewoon een onhandige monolith aan het bouwen.

YouTube: Episode 1 - Mongo DB Is Web Scale

It's webscale !!
Just pipe your data to /dev/null it will be very fast!

[ Voor 6% gewijzigd door Immutable op 25-06-2020 10:18 ]

[Hydra]

Microservices hebben niks met hype te maken. Het is een reflectie van je bedrijfsstructuur. Boven een bepaald aantal mensen/teams schaalt een monoliet gewoon niet. Dat is ook niks nieuws overigens; een 'bank' was ook in 2000 niet 1 enkele applicatie.

Microservices zijn alleen geen doel, ze zijn een gereedschap om een specifiek probleem op te lossen. Een gereedschap dat ook flinke nadelen heeft.

[Mugwump]

Hydra schreef op donderdag 25 juni 2020 @ 12:01:
Microservices hebben niks met hype te maken. Het is een reflectie van je bedrijfsstructuur. Boven een bepaald aantal mensen/teams schaalt een monoliet gewoon niet. Dat is ook niks nieuws overigens; een 'bank' was ook in 2000 niet 1 enkele applicatie.

Microservices zijn alleen geen doel, ze zijn een gereedschap om een specifiek probleem op te lossen. Een gereedschap dat ook flinke nadelen heeft.

Daar gaat het natuurlijk niet om. Het structureren en isoleren van functionaliteit is uiteraard van alle tijden. Niemand zal een "big ball of mud"-architectuur aanraden.
Het ging alleen een beetje mis toen we dat "microservices" gingen noemen. Toen werd de term an sich dus een doel op zich, derhalve hype.
Dan krijg je ook domme discussies als "hoeveel regels code mag mijn microservice bevatten?" of mensen gaan bij wijze van spreken een functie die twee getallen optelt in een microservice met een REST interface proppen. Hetzelfde voor de overige aritmetische operaties doen en er een GraphQL service voor gooien die alles integreert en je kunt rekensommetjes doen!

[gekkie]

Altijd leuk puzzelen waar de systeemgrenzen zouden moeten liggen, of het nou software is, bedrijfsprocessen of wat dan ook.

[Hydra]

Mugwump schreef op donderdag 25 juni 2020 @ 12:16:
Dan krijg je ook domme discussies als "hoeveel regels code mag mijn microservice bevatten?" of mensen gaan bij wijze van spreken een functie die twee getallen optelt in een microservice met een REST interface proppen. Hetzelfde voor de overige aritmetische operaties doen en er een GraphQL service voor gooien die alles integreert en je kunt rekensommetjes doen!

Nouja, stupid devs gonna stupid. Daar kun je sowieso niks aan doen. Je ziet dat er daar bij heel veel bedrijven gewoon een enorm gebrek is aan ervaren mensen. Maar als je diezelfde developers een monoliet laat bouwen, wordt dat ook een puinhoop.

Heb een voorbeeld gezien van een erg junior team dat 'microservices' deed waarbij alle microservices tegelijkertijd gedeployed moesten worden, en ze ook geen CI/CD hadden. En geen e2e tests. Tja. Die kan beter een monoliet bouwen, maar no way dat dat een monoliet zou worden die je later nog op kunt breken.

Maar ik vind microservices een 'hype' noemen net zoals als 'de cloud' een hype noemen.

[Hydra]

gekkie schreef op donderdag 25 juni 2020 @ 12:44:
Altijd leuk puzzelen waar de systeemgrenzen zouden moeten liggen, of het nou software is, bedrijfsprocessen of wat dan ook.

Microservices zijn een dependency tree. Het laagste niveau is zijn je domein root aggregates. Dat zijn relatief 'domme' data services. Daarboven heb je 'business' services die afhankelijk zijn van de data services daaronder. Data services mogen nooit afhankelijk zijn van business services en als het even kan ook niet van andere data services.

[gekkie]

Hydra schreef op donderdag 25 juni 2020 @ 12:53:
[...]
Microservices zijn een dependency tree. Het laagste niveau is zijn je domein root aggregates. Dat zijn relatief 'domme' data services. Daarboven heb je 'business' services die afhankelijk zijn van de data services daaronder. Data services mogen nooit afhankelijk zijn van business services en als het even kan ook niet van andere data services.

Maar binnen de business services zelf ?, of laat je die dan wel als monolith en splits je alleen data en business ?

Daarnaast hangt het ook af van het doel waarvoor je het allemaal doet en welke tradeoff's je daar in acceptabeler acht dan anderen.

(oja en was het altijd maar een eenvoudige nette "tree" qua afhankelijkheden )

[ Voor 5% gewijzigd door gekkie op 25-06-2020 13:06 ]

[HMS]

Ik kwam deze GitHub repo tegen van de Nederlanse COVID-19 notificatie app, en ik zit met stijgende verbazing door de code heen te bladeren.

Unit testen, niet aanwezig. Rechtstreeks zooi naar de HttpContext response schrijven vanuit een 'command'... wat?

Wel top dat het allemaal 'in the open' gebeurd, maar hoe ze het doen vind ik bedenkelijk

[WernerL]

Hydra schreef op donderdag 25 juni 2020 @ 12:01:
Microservices hebben niks met hype te maken. Het is een reflectie van je bedrijfsstructuur. Boven een bepaald aantal mensen/teams schaalt een monoliet gewoon niet. Dat is ook niks nieuws overigens; een 'bank' was ook in 2000 niet 1 enkele applicatie.

Microservices zijn alleen geen doel, ze zijn een gereedschap om een specifiek probleem op te lossen. Een gereedschap dat ook flinke nadelen heeft.

Ik ben het deels met je eens maar dit kan ook prima opgelost worden zonder 'microservices'. Ik heb 8 maanden bij een bigCorp gewerkt en daar hadden we ook losse services die door verschillende teams onderhouden werden. Dan kan iedere individuele applicatie nog steeds een monoliet zijn die externe services aanspreekt.

Het gaat fout als je van microservices het doel maakt en letterlijk alles op gaat splitsen. Zoals enkele posters hierboven ook al benoemde.

De infrastructuur moet gedicteerd worden door het probleem wat je probeert op te lossen, niet andersom.

[WernerL]

HMS schreef op donderdag 25 juni 2020 @ 14:26:
Ik kwam deze GitHub repo tegen van de Nederlanse COVID-19 notificatie app, en ik zit met stijgende verbazing door de code heen te bladeren.

Unit testen, niet aanwezig. Rechtstreeks zooi naar de HttpContext response schrijven vanuit een 'command'... wat?

Wel top dat het allemaal 'in the open' gebeurd, maar hoe ze het doen vind ik bedenkelijk

Ik zie hier wel wat unit tests staan.
https://github.com/minvws...e/master/Components.Tests

En het lijkt erop dat zij ook last hebben van het microservice virus. Verschillende APIs die allemaal 1 controller hebben. Lekker efficient.