De Devschuur Coffee Corner - Iteratie ⓬

[Mugwump]

gold_dust schreef op woensdag 3 juli 2019 @ 08:41:
[...]

Als ik vragen zou moeten stellen zou ik het bij algemene CS/software engineering concepten houden, makkelijk beginnen zoals 'wat is polymorfisme', 'wat is encapsulation' en 'waarom zou je dit willen toepassen'? Dan zal je zien dat een groot deel van de kandidaten, inclusief vrijwel alle die geen formele Informatica achtergrond hebben al door de mand vallen.

Dan het iets moeilijker maken zoals bijvoorbeeld bubblesort vs quicksort, wat is het nut van een virtuele destructor in C++ etc. En vervolgens weer moeilijker maken tot het gewenste niveau bereikt is. Als conceptueel alles in orde is, dan vragen om een stukje code te laten zien of dat netjes is.

Het blijft altijd een gok, ik zou ook niet snel een onbekende die solliciteert aannemen. Liever iemand waar ik van weet dat hij/zij goed is. Maar met Silly Con Valley achtige raadsels/ongepaste vragen zou ik niet beginnen. Zelf pas ik daar inmiddels ook voor.

Ik zie trouwens mijn hele carrière lang de omgekeerde situatie, dat bedrijven/teams niet aan mijn eisen voldoen. En doe alleen nog freelance opdrachten waar ik mijn deel in principe alleen kan doen.

Ik mag toch hopen dat iemand met enige ervaring heeft met software-ontwikkeling ook zonder formele Informatica achtergrond wel weet wat encapsulation of polymorphism is, zeker als die persoon in een OO-taal werkt. In bijvoorbeeld de basiscertificeringen voor Java komt dat gewoon aan bod. Concrete opdrachten om iets te implementeren zijn wel afhankelijk van het soort developmentwerk dat iemand doet. Ik zou ook weer diep hard moeten graven om een bubblesort of quicksort te implementeren, want dat is echt alweer 15 jaar geleden.
Meestal start ik bij een gesprek gewoon vanuit de CV / werkervaring. Pak er een klus / project uit en vraag eens door naar wat die persoon in het project precies heeft gedaan. Als je ziet dat mensen over een bepaald aspect heel enthousiast zijn, vraag daar dan op door om wat meer inzicht te krijgen in diens niveau. Probeer waar mogelijk ook wat vragen te stellen over gekozen technologieën / oplossingen, waarom die gekozen zijn, wat de alternatieven en de afwegingen zijn en ga zo maar door. Dat geeft je een aardig beeld van de persoon en zijn of haar globale kennisniveau.
Het echt proberen in te schatten van iemands functioneren nadat de persoon is aangenomen is toch heel lastig en als het echt dramatisch blijkt heb je altijd nog een proeftijd.

[gold_dust]

Mugwump schreef op woensdag 3 juli 2019 @ 09:37:
Ik mag toch hopen dat iemand met enige ervaring heeft met software-ontwikkeling ook zonder formele Informatica achtergrond wel weet wat encapsulation of polymorphism is, zeker als die persoon in een OO-taal werkt. In bijvoorbeeld de basiscertificeringen voor Java komt dat gewoon aan bod. Concrete opdrachten om iets te implementeren zijn wel afhankelijk van het soort developmentwerk dat iemand doet. Ik zou ook weer diep hard moeten graven om een bubblesort of quicksort te implementeren, want dat is echt alweer 15 jaar geleden.
...

Ik zou zelf ook niemand vragen iets te implementeren, maar zou willen zien dat iemand conceptueel begrijpt dat en vooral waarom quicksort efficiënter is. Juist die whiteboard programmeeropgaven vind ik onzin, zorg dan tenminste voor een IDE en voldoende tijd, wat er tijdens een interview toch niet is. En ga niet iemand onder druk zetten met code uitschrijven op een whiteboard. Dat zou voor mij een red flag zijn.

En vooral zo veel mogelijk remote afhandelen, CS/software engineering concepten zijn prima via telefoon/voip af te handelen. Ga niet iemands tijd verspillen met reizen voor een vanuit perspectief van de kandidaat potentieel onmogelijke interview stijl met onzinnige vragen.

[RayNbow]

Mugwump schreef op woensdag 3 juli 2019 @ 09:37:
Ik zou ook weer diep hard moeten graven om [...] quicksort te implementeren, want dat is echt alweer 15 jaar geleden.

Haskell:

qsort [] = []
qsort (x:xs) = qsort le ++ [x] ++ qsort gt
               where (le, gt) =  partition (<=x) xs

[F.West98]

Ik zou geen fan zijn van vragen als "wat is polymorphism" of "wat is encapsulation". Ik heb praktisch een BSc Informatica, ben al jaren aan het programmeren en ik zou wel durven zeggen dat ik het programmeren in het algemeen wel onder de knie heb. Ook polymorphism/encapsulation ben ik mee bekend, op concept-niveau. Ik weet de namen van dat soort concepten nooit, die mapping past niet in mijn hoofd ofzo Dat terwijl ik al die concepten wel dagelijks toepas tijdens programmeren, dus in dat opzicht kan ik het prima uitleggen, als ik maar weet wat wat is. Ligt dat nou aan mij, of hebben anderen dat ook? Die namen zeggen mij gewoon vaak niets...

[Jantje2000]

Tja, ik gebruik encapsulation vrijwel altijd, maar de term was ik vergeten. Er zou worden geconcludeerd dat ik dus een slechte programmeur zou zijn, als je dat niet weet, maar toen ik het opzocht dat ik: o is dat encapsulation.

[Koenvh]

@F.West98 Ik heb dat ook wel eens, al ligt het er een beetje aan waar ik mee bezig ben. Dingen als encapsulatie zijn zo vanzelfsprekend dat ik ook even de term kwijt was, maar na het even op te zoeken wist ik 't weer.

[F.West98]

Jantje2000 schreef op woensdag 3 juli 2019 @ 14:49:
Tja, ik gebruik encapsulation vrijwel altijd, maar de term was ik vergeten. Er zou worden geconcludeerd dat ik dus een slechte programmeur zou zijn, als je dat niet weet, maar toen ik het opzocht dat ik: o is dat encapsulation.

Precies
Zelfde heb ik met al die duizenden design patterns enzo, leuk allemaal om het theoretisch te beschrijven, maar het gaat erom dat je in de praktijk de goede kiest. En of je nou weet dat dat het decorator pattern ofzo is, who cares (imho).

[Jantje2000]

F.West98 schreef op woensdag 3 juli 2019 @ 17:15:
[...]

Precies
Zelfde heb ik met al die duizenden design patterns enzo, leuk allemaal om het theoretisch te beschrijven, maar het gaat erom dat je in de praktijk de goede kiest. En of je nou weet dat dat het decorator pattern ofzo is, who cares (imho).

Ben ik het helemaal mee eens. Persoonlijk lijkt me het logischer om gewoon een onderwerp te pakken en daarover te gaan sparren. Dus hoe zou jij dat aanpakken (architectureel) e.d. Waar let je op, en waarom dan? Dan hoor je snel genoeg of de persoon er verstand van heeft of niet

[R4gnax]

Jantje2000 schreef op woensdag 3 juli 2019 @ 17:16:
Persoonlijk lijkt me het logischer om gewoon een onderwerp te pakken en daarover te gaan sparren. Dus hoe zou jij dat aanpakken (architectureel) e.d. Waar let je op, en waarom dan? Dan hoor je snel genoeg of de persoon er verstand van heeft of niet

100% Eens. Dat is waar ik ook eigenlijk altijd naar toe ga als we door het verplichte fizz-buzz testje heen zijn wat HR graag gedaan ziet worden. "Goh, nou was ik van de week met probleem <xyz> bezig en <blah, blah blah>. Hoe zou jij zoiets nou aanvliegen?"

F.West98 schreef op woensdag 3 juli 2019 @ 14:38:
Ik zou geen fan zijn van vragen als "wat is polymorphism" of "wat is encapsulation"

Ik ook niet, want je hebt een te grote kans dat iemand net dat begrip onder die ene terminologie niet kent, buiten context verkeerd interpreteert, etc.

Als je van dat soort kennisvragen wilt gaan stellen, dan kun je veel beter twee begrippen tegen elkaar uit zetten en dan aan een kandidaat vragen: "Kun je eens beargumenteren waarom/wanneer A een betere keuze dan B zou zijn?" Daarmee toets je niet alleen hun kennis van een begrip, methode, patroon, etc. zelf - maar ook of ze het inzicht hebben om zaken correct toe te passen.

Een mooie is bijv. om zelf de begrippen compositie en overerving uit te leggen en daarna te vragen wat de redenering achter het credo composition over inheritance (als in: verkies compositie boven overerving) is. En of er situaties zijn waarin ze zelf strikt voor het één of ander zouden kiezen. En waarom dan.

Harde feiten-kennis is in IT vrij nutteloos. Dat is vooraf aan een interview allemaal stamp-baar. En achteraf doe je er tijdens het werk meestal goed aan om de moelijke dingen toch opnieuw op te zoeken en de correcte referenties er op na te slaan. (Ik zou trouwens iemand die er prat op gaat quicksort uit z'n hoofd te kunnen reproduceren, nooit direct vertrouwen om eigenhandig bepaalde complexere data-structures te gaan implementeren.)

Inzicht en vermogen tot redeneren en adapteren; dat is waar het om draait.

[EddoH]

Ik heb in mijn 12 jarige carrière nog nooit uit mijn hoofd het verschil tussen een quicksort of een bubblesort moeten weten. En als ik op zoek ben naar een goede sorting voor mijn probleem sla ik een boek open, of doe ik een uurtje research & profiling om tot een goede danwel beste oplossing te komen.

En hopelijk ben ik na een jaar wel weer vergeten wat de details daarvan waren. Ga me dat dus ook niet vragen op een sollicitatiegesprek. Ik ben een probleemoplosser, geen encyclopedie.

[.oisyn]

@EddoH Een goede basis van verschillende algoritmen en wanneer je ze moet toepassen lijkt me redelijk essentieel. Het zijn de tools in je gereedschapskist. Een timmerman gaat ook niet Googlen waarmee hij een spijker er het beste in kan slaan.

Toevallig kwam er vandaag een fix voor een memory corruption langs. Iemand die een random permutatie probeerde te verkrijgen door een sort te doen met een comparator die gewoon willekeurig true of false teruggeeft. Wat toevallig goed ging in Visual C++ maar niet in Clang, omdat de implementatie van std::sort in Clang bepaalde aannames maakt over de volgorde die niet nageleefd worden door een dergelijke comparator.

Het is precies die "ja maar het werkt toch" attitude die iemand anders enorm veel tijd heeft gekost om dat memory corruptie nou eenmaal heel lastig op te sporen is. Een fout die gewoon voorkomen had kunnen worden als de schrijver of zijn reviewer een beetje verstand hadden van dat soort dingen. Namelijk dat sort niet bedoeld is voor het maken van random permutaties.

[ Voor 21% gewijzigd door .oisyn op 03-07-2019 20:36 ]

[Mugwump]

.oisyn schreef op woensdag 3 juli 2019 @ 20:29:
@EddoH Een goede basis van verschillende algoritmen en wanneer je ze moet toepassen lijkt me redelijk essentieel. Het zijn de tools in je gereedschapskist. Een timmerman gaat ook niet Googlen waarmee hij een spijker er het beste in kan slaan.

Toevallig kwam er vandaag een fix voor een memory corruption langs. Iemand die een random permutatie probeerde te verkrijgen door een sort te doen met een comparator die gewoon willekeurig true of false teruggeeft. Wat toevallig goed ging in Visual C++ maar niet in Clang, omdat de implementatie van std::sort in Clang bepaalde aannames maakt over de volgorde die niet nageleefd worden door een dergelijke comparator.

Het is precies die "ja maar het werkt toch" attitude die iemand anders enorm veel tijd heeft gekost om dat memory corruptie nou eenmaal heel lastig op te sporen is. Een fout die gewoon voorkomen had kunnen worden als de schrijver of zijn reviewer een beetje verstand hadden van dat soort dingen. Namelijk dat sort niet bedoeld is voor het maken van random permutaties.

Maar welk percentage van developers denk je dat in hun dagelijks praktijk echt te maken heeft met het kiezen tussen een quicksort of een bubblesort algoritme?

[.oisyn]

@Mugwump Geen idee, ik trok zijn stelling breder dan alleen het specifieke voorbeeld van bubblesort en quicksort, want zo was het volgens mij ook bedoeld. Het was een enorm slecht voorbeeld, want voor het percentage gevallen waarbij bubblesort een betere keuze is dan quicksort is heb je waarschijnlijk een aantal digits achter de komma nodig. Meestal roep je gewoon de sorteerfunctie aan van de standaard library (die doorgaans geoptimaliseerd is voor het generieke geval) en ben je niet echt geinteresseerd in het daadwerkelijke algoritme.

[ Voor 22% gewijzigd door .oisyn op 03-07-2019 21:06 ]

[ThomasG]

De meeste datasets zijn al bijna op volgorde, of op een (bijna) omgekeerde volgorde. TimSort is in die gevallen vaker sneller dan quicksort, en het is dan ook steeds vaker de standaard implementatie als het om non-primitive types gaat.

[gekkie]

En dus gaat zo'n analogie met de timmerman toch al gauw weer mank.

[EddoH]

.oisyn schreef op woensdag 3 juli 2019 @ 21:01:
@Mugwump Geen idee, ik trok zijn stelling breder dan alleen het specifieke voorbeeld van bubblesort en quicksort, want zo was het volgens mij ook bedoeld. Het was een enorm slecht voorbeeld, want voor het percentage gevallen waarbij bubblesort een betere keuze is dan quicksort is heb je waarschijnlijk een aantal digits achter de komma nodig. Meestal roep je gewoon de sorteerfunctie aan van de standaard library (die doorgaans geoptimaliseerd is voor het generieke geval) en ben je niet echt geinteresseerd in het daadwerkelijke algoritme.

Maar mijn opmerking ging specifiek over het verschil tussen een quicksort en een bubblesort. Als je het breder trekt dan vervalt de context natuurlijk deels. Ik bedoel dat ik niet altijd aan het naampje (quicksort of bubblesort) exact weet hoe een implementatie in elkaar steekt. Dat neemt niet weg dat je die wel moet kunnen begrijpen als het van belang is en als je probleem die behoefte heeft. Ik bedoel dus expliciet niet dat het mij niet uitmaakt hoe sorting algoritmes in elkaar steken, zolang ze maar werken. Ik bedoel dat ik niet elke mogelijke sorting implementatie bij naam uit mijn hoofd weet.

[Mugwump]

.oisyn schreef op woensdag 3 juli 2019 @ 21:01:
@Mugwump Geen idee, ik trok zijn stelling breder dan alleen het specifieke voorbeeld van bubblesort en quicksort, want zo was het volgens mij ook bedoeld. Het was een enorm slecht voorbeeld, want voor het percentage gevallen waarbij bubblesort een betere keuze is dan quicksort is heb je waarschijnlijk een aantal digits achter de komma nodig. Meestal roep je gewoon de sorteerfunctie aan van de standaard library (die doorgaans geoptimaliseerd is voor het generieke geval) en ben je niet echt geinteresseerd in het daadwerkelijke algoritme.

Ik ben het met je eens hoor. Dit is een slecht voorbeeld maar ik vind fundamentele kennis van zaken altijd wel een behoorlijke pre. Werk je met databases, dan zijn concepten als optimistic en pessimistic locking, acid, eventual consistency en ga zo maar door wel belangrijk ongeacht hoe je die in een specifieke technologie hanteert of implementeert.

[gekkie]

Hangt er ook wel een beetje af hoe low of high-level je dagelijks werkt.
Als je er niet dagelijks mee werkt is kun je het wel als een pre dat je van het bestaan weet.
Alles waar je het bestaan van weet kun je indien nodig relatief makkelijk je tijdelijk in verdiepen als het nodig is. Van de hoed en de rand weten lijkt me niet van alles en voor elke rol strikt noodzakelijk.

[EddoH]

Uiteraard is benodigde kennis natuurlijk compleet afhankelijk van het bedrijf of de positie waar je op solliciteert. Als ik een embedded developer zoek dan verwacht ik ook specifieke kennis van realtime OS'en en moet hij met een oscilloscoop kunnen omgaan. Van iemand die verwacht wordt dat hij op dagelijkse basis snelle algoritmes op grote hoeveelheden data uit zijn mouw schudt mag
je verwachten dat hij de sorteeralgoritmes kent.
Als generieke sollicitatievraag om te kijken of iemand een goede developer is vind ik het gewoon minder relevant.

[Matis]

Ik heb een keer als Symfony ontwikkelaar gesolliciteerd. Na de eerste ronde werd me gevraagd een eenvoudige opdracht op basis van Symfony te maken. Om zo mijn niveau en bijbehorende vergoeding te bepalen. Ik vond het een prima manier.

[Douweegbertje]

.oisyn schreef op woensdag 3 juli 2019 @ 21:01:
@Mugwump Geen idee, ik trok zijn stelling breder dan alleen het specifieke voorbeeld van bubblesort en quicksort, want zo was het volgens mij ook bedoeld. Het was een enorm slecht voorbeeld, want voor het percentage gevallen waarbij bubblesort een betere keuze is dan quicksort is heb je waarschijnlijk een aantal digits achter de komma nodig. Meestal roep je gewoon de sorteerfunctie aan van de standaard library (die doorgaans geoptimaliseerd is voor het generieke geval) en ben je niet echt geinteresseerd in het daadwerkelijke algoritme.

Op jouw 'niveau' is het logisch dat er totaal andere vragen worden gesteld dan bij een ander bedrijf/persoon.

Het interview / de sollicitatie moet ook in lijn zijn met het niveau, branche, functie, etc, etc.

[.oisyn]

Douweegbertje schreef op woensdag 3 juli 2019 @ 23:42:
[...]


Op jouw 'niveau' is het logisch dat er totaal andere vragen worden gesteld dan bij een ander bedrijf/persoon.

Dat wat jij 'mijn niveau' noemt is anders wel gewoon onderdeel van het HBO informatica curriculum. Ik verwacht van een schoolverlater wel dat ie ongeveer weet wanneer je een array, linked list, (red-black) tree of een hashtable moet gebruiken, en dat je dat enigszins kan onderbouwen. En dat je dus ook iets snapt van algoritmische complexiteit.

[ Voor 26% gewijzigd door .oisyn op 04-07-2019 00:17 ]

[EddoH]

@.oisyn er is toch niemand die dat ontkent? Ik vind wel een verschil zitten tussen 2 specifieke sorting algoritmes en de meer algemene zaken die je nu noemt. Dat is in ieder geval wat ik probeerde aan te geven.

[Douweegbertje]

.oisyn schreef op donderdag 4 juli 2019 @ 00:01:
[...]

Dat wat jij 'mijn niveau' noemt is anders wel gewoon onderdeel van het HBO informatica curriculum. Ik verwacht van een schoolverlater wel dat ie ongeveer weet wanneer je een array, linked list, (red-black) tree of een hashtable moet gebruiken, en dat je dat enigszins kan onderbouwen. En dat je dus ook iets snapt van algoritmische complexiteit.

Ik weet het niet exact en heb daar ook vrij weinig tot niet mee te maken gehad. Je vergeet misschien dat er genoeg programmeurs zijn die niet vanuit een vrij technische informatica opleiding komen.

Naar mijn inziens zijn er zat gedegen developers die niet tot weinig wiskunde / algoritmen hoeven te gebruiken.

En wellicht ben je je eigen stof iets te lang gewend maar je mag iets meer credits toe kennen aan jouw kunde. Vele zitten niet op dat niveau, waaronder ik.

Overigens niet erg. Ik heb weer mijn andere expertises

[ThomasG]

Douweegbertje schreef op donderdag 4 juli 2019 @ 09:15:
[...]


Ik weet het niet exact en heb daar ook vrij weinig tot niet mee te maken gehad. Je vergeet misschien dat er genoeg programmeurs zijn die niet vanuit een vrij technische informatica opleiding komen.

Naar mijn inziens zijn er zat gedegen developers die niet tot weinig wiskunde / algoritmen hoeven te gebruiken.

En wellicht ben je je eigen stof iets te lang gewend maar je mag iets meer credits toe kennen aan jouw kunde. Vele zitten niet op dat niveau, waaronder ik.

Overigens niet erg. Ik heb weer mijn andere expertises

Dat komt omdat er tegenwoordig veel talen zijn waarbij het automagish gaat. In veel gevallen is het dan ook niet nodig om het te weten, tenzij je tegen een bottleneck aanloopt. Laten we wel wezen, de meeste programmeurs werken niet aan projecten waarbij er een merkbaar verschil is. In het geval van @.oisyn wil je in principe alles zo snel mogelijk met zo min mogelijk latency, dat vereist gewoon andere kennis dan wanneer je een boekhoud programma maakt. Duurt iets bij het factureren een fractie van een seconde langer? No big deal. Bij een spel kan dat zo een paar FPS, of erger: input dat een paar frames achterloopt, schelen.

[.oisyn]

ThomasG schreef op donderdag 4 juli 2019 @ 11:01:
[...]
In het geval van @.oisyn wil je in principe alles zo snel mogelijk met zo min mogelijk latency, dat vereist gewoon andere kennis dan wanneer je een boekhoud programma maakt.

Wij maken heus niet alleen performance-kritieke code, hoor. De codebase van de gehele toolchain is veel groter dan die van de game, en performance daarin is veel minder relevant. Maar ook als je een boekhoudprogramma maakt hoop ik wel dat je de juiste datastructuren kiest, in plaats van alles maar gewoon in arrays te vrotten omdat dat nou eenmaal de standaard is.

[RayNbow]

.oisyn schreef op donderdag 4 juli 2019 @ 11:30:
Maar ook als je een boekhoudprogramma maakt hoop ik wel dat je de juiste datastructuren kiest

Gewoon alles laden van/opslaan in simpele platte tekstbestanden.

[Mugwump]

.oisyn schreef op donderdag 4 juli 2019 @ 11:30:
[...]

Wij maken heus niet alleen performance-kritieke code, hoor. De codebase van de gehele toolchain is veel groter dan die van de game, en performance daarin is veel minder relevant. Maar ook als je een boekhoudprogramma maakt hoop ik wel dat je de juiste datastructuren kiest, in plaats van alles maar gewoon in arrays te vrotten omdat dat nou eenmaal de standaard is.

Ik merk toch best wel vaak dat datastructuren nog wel eens een ondergeschoven kindje zijn. Heb wel meer dan eens meegemaakt dat mensen met toch best de nodige werkervaring je vreemd aankijken als je bijvoorbeeld een set gebruikt omdat je een ongeordende verzameling unieke dingen wilt hebben en "Venn Diagram"-operaties nodig hebt. Wat ik dan weer bijzonder vind aangezien dat soort mensen vaak genoeg ervaring hebben met relationele databases en sets daarin toch een vrij centraal concept zijn.

[orf]

Iemand niks te doen en zin in fijne UX? https://userinyerface.com/
Grappig hoe frustrerend UX kan zijn en soms in het echt is.

[.oisyn]

orf schreef op donderdag 4 juli 2019 @ 16:06:
Iemand niks te doen en zin in fijne UX? https://userinyerface.com/
Grappig hoe frustrerend UX kan zijn en soms in het echt is.

Ik kom niet eens voorbij het eerste scherm.

[orf]

.oisyn schreef op donderdag 4 juli 2019 @ 16:21:
[...]


Ik kom niet eens voorbij het eerste scherm.

Gewoon op "HERE" klikken. Logisch toch?

[.oisyn]

Dan 2e scherm. Scherm 1 van 4 . Maar het is al gelukt, blijkbaar is "domain" geen goed domein.

[ Voor 15% gewijzigd door .oisyn op 04-07-2019 16:27 ]

[Mugwump]

Ik ben door alle schermpjes heengekomen, maar heel makkelijk was het niet.

[Skyaero]

In exact 4 minuten. Volgens mij doe ik er langer over om mijn wachtwoord bij de ING te wijzigen.

[gekkie]

Of het inloggen bij de ING .... uw cookie van de vorige keer was consument ... maar het account waarin u probeert in te loggen is zakelijk ... spring door het hoepeltje en probeer het nog een keer.
En uiteraard daarna vice versa.
Mafketels, je weet waarin ik in wil loggen, je weet kennelijk welk type account het is, just do it (zoals het tot een jaar geleden ook gewoon altijd werkte).

[Koenvh]

RayNbow schreef op donderdag 4 juli 2019 @ 11:49:
[...]

Gewoon alles laden van/opslaan in simpele platte tekstbestanden.

Screenshot opslaan en dan later inladen met OCR?

[gekkie]

Koenvh schreef op donderdag 4 juli 2019 @ 19:36:
[...]

Screenshot opslaan en dan later inladen met OCR?

Wat dan eigenlijk gewoon stiekum weer een mechanical turk is ?

[Koenvh]

gekkie schreef op donderdag 4 juli 2019 @ 19:39:
[...]

Wat dan eigenlijk gewoon stiekum weer een mechanical turk is ?

De "open"-knop start een TeamViewer-verbinding met iemand uit India die handmatig de waarden van een screenshot overtypt.

[Matis]

Ik ga volgende week op vakantie en overweeg een puzzelboek mee te nemen. Zijn er leuke (lees uitdagen, dus geen hersendodende woordzoekers) puzzelboeken?

Vroegah had ik puzzelboeken die gemixt waren. Tentje-boompje en andere toffe denkpuzzels, maar die kan ik niet meer vinden

[ Voor 29% gewijzigd door Matis op 04-07-2019 19:50 ]

[Koenvh]

De AIVD kerstpuzzel? ('t Is dan wel geen kerst, maar uitdagend is het zeker)

[ Voor 58% gewijzigd door Koenvh op 04-07-2019 19:54 ]

[Mugwump]

Nog iemand hier op zoek naar eens een keer iets anders dan een voetbaltafel of een leaseauto als secundaire voorwaarden?

https://www.parool.nl/ams...adellijke-titel~b9624a14/

[Kalentum]

Vandaag iteratie nummer 4 van onze development environment uitgeprobeerd. Ik werk er 4,5 jaar nu dus gemiddeld bijna ieder jaar gaat de boel overhoop.

Toen ik in dienst kwam draaide de ene applicatie die we hadden gewoon op de mac. Een drama om te installeren en fingers crossed bij OS upgrades. Niet handig.

Toen kwam er een Virtualbox image waar alles op draaide. In principe makkelijk te installeren maar voor devops lastig te onderhouden bij 10-tallen devs. Die oplossing evolueerde uiteindelijk in een met ansible beheerde development environment. Maar 20 microservices op 1 VM bleek niet echt lekker te gaan.

De volgende environment was een VM die bij Google staat. Centraal te managen maar ja, lokaal werken en dan syncen met een remote vm, ook niet alles.

En nu zijn alle microservers containers geworden en dus ook de development environment. Applicaties waar je aan werkt draaien lokaal en wat je nodig hebt maar niet aan werkt staat remote. Elke dag staat er een database klaar met data tot en met gisteren.

Ben benieuwd wanneer we development environment 5 krijgen

[Lethalis]

Merethil schreef op dinsdag 2 juli 2019 @ 09:24:
[...]
Tijdens je vakantie heb je nog een REST API zitten aanpassen om zodoende fouten eruit te halen? Terwijl je collega's gewoon konden werken? Dat lijkt me dus een flinke no-go. Vakantie = rusttijd = geen tijd van de baas. Hopelijk heb je die vakantie-uren teruggeclaimed nadien?

Als ik 2 uur eerder weg ga, omdat ik met mijn dochter naar de diëtist oid ga, hoef ik daar ook niks mee te doen.

Flexibiliteit werkt beide kanten op.

Het enige waarin ik jou gelijk geef, is dat het mijn vakantie was / is.

Al ben ik ook een beetje stupid geweest, omdat ik het werk niet had overgedragen. Dus collega's wisten niet hoe ze het konden fixen.

Uiteraard heb ik alsnog een overdracht geschreven via de mail en sindsdien heb ik ze ook niet meer gehoord (zit nu in week 2 vd 3).

Als jij zo op de uurtjes let, moet je toch ook een hoop gezeur krijgen als je zelf regelmatig afwezig bent?

Ik ben het afgelopen jaar misschien wel 15 keer bij de tandarts geweest, en tig keer met mijn dochter naar allerlei dingen toe. En dat boeit ook niemand.

Zou ergens ook wel krom zijn als ik dan ga miepen als ik eens 2 uur overwerk voor niks.

[ Voor 16% gewijzigd door Lethalis op 04-07-2019 21:11 ]

[Merethil]

Lethalis schreef op donderdag 4 juli 2019 @ 21:03:
[...]

Als ik 2 uur eerder weg ga, omdat ik met mijn dochter naar de diëtist oid ga, hoef ik daar ook niks mee te doen.

Flexibiliteit werkt beide kanten op.

Het enige waarin ik jou gelijk geef, is dat het mijn vakantie was / is.

Al ben ik ook een beetje stupid geweest, omdat ik het werk niet had overgedragen. Dus collega's wisten niet hoe ze het konden fixen.

Uiteraard heb ik alsnog een overdracht geschreven via de mail en sindsdien heb ik ze ook niet meer gehoord (zit nu in week 2 vd 3).

Als jij zo op de uurtjes let, moet je toch ook een hoop gezeur krijgen als je zelf regelmatig afwezig bent?

Ik ben het afgelopen jaar misschien wel 15 keer bij de tandarts geweest, en tig keer met mijn dochter naar allerlei dingen toe. En dat boeit ook niemand.

Zou ergens ook wel krom zijn als ik dan ga miepen als ik eens 2 uur overwerk voor niks.

Ik doe mijn werk goed en de klant is tevreden, daar staat tegenover dat ik wat coulance krijg. Maak ik weinig gebruik van, ik werk gewoon een half uurtje langer of kom een half uurtje eerder als ik een andere dag eerder weg moet/later moet komen i.v.m. afspraken.
Verder doe ik alles op basis van mijn vrije dagen, of regel ik (in geval van je voorbeeld, de tandarts) dat ik dingen 's avonds of heel vroeg in de morgen kan doen.

Je hoeft echt niet over te werken om coulance in dingen te krijgen. De bedrijven waar ik werk doen niet zo spastisch over uren schrijven, als ze dat wel zouden doen zou ik er ook niet lang blijven werken. Het bedrijf waar ik nu werk is er heel makkelijk in: zolang je de klant tevreden houdt vinden ze een hoop goed. En ook de klanten worden uitgezocht op een wat meer relaxte werkethiek, gewoon om te voorkomen dat mijn collega's en ik er al na een paar maanden helemaal klaar mee zijn.

Dus nee, ik word niet gek aangekeken en doe ook niet heel overdreven op de uurtjes letten. Onverwacht overwerken is alleen gewoon niet mijn probleem, dat regelen ze dan maar door betere planning.
Als er shit tegen de fan aan komt hebben we daar een standby-regeling voor en die rouleert over alle collega's heen, maar komt ook neer op "we herstarten het, als het dan nog niet werkt escaleren we het naar de manager en fixen we het de volgende dag".

Ik ben trouwens niet de enige, het hele bedrijf werkt zo. Dat maakt het misschien ook wel heel makkelijk praten voor me, maar ik heb het bedrijf daar ook wel specifiek op uitgekozen. Merk ook dat bedrijven die op deze manier opereren de meest loyale en fijne medewerkers hebben die ik tot nu toe heb meegemaakt.

[sig69]

Mugwump schreef op donderdag 4 juli 2019 @ 20:05:
Nog iemand hier op zoek naar eens een keer iets anders dan een voetbaltafel of een leaseauto als secundaire voorwaarden?

https://www.parool.nl/ams...adellijke-titel~b9624a14/

Dat kost 38 euro, doe mij die leaseauto maar. Wel leuk als kado, thanks!

[gekkie]

sig69 schreef op donderdag 4 juli 2019 @ 22:55:
[...]

Dat kost 38 euro, doe mij die leaseauto maar. Wel leuk als kado, thanks!

Oh lord .. would you buy me a Mercedes-Benz ?

(overigens is die kans klein, en zit je opgevouwen in een knal roze VW lease polo volgens google images)

[ Voor 20% gewijzigd door gekkie op 05-07-2019 10:05 ]

[Douweegbertje]

sig69 schreef op donderdag 4 juli 2019 @ 22:55:
[...]

Dat kost 38 euro, doe mij die leaseauto maar. Wel leuk als kado, thanks!

lol 38 euro, het is eigenlijk bijna te triest. Ik las ook dat bestaande medewerkers daar dus niets krijgen. M.a.w. het bedrijf is te gierig om 38 euro p/p te betalen voor hun medewerkers die al in dienst zijn. Ja, je mag het wel krijgen,als je een referal aanbrengt die in dienst komt. Dit zegt mij al genoeg.

Mijn vorige werkgever gaf 1000 euro voor een nieuwe medewerker die via jou binnen kwam.

Het hoeft echt niet allemaal duur of veel te zijn, maar holy shit. Je kan ook gewoon een beetje coulant zijn.

[Mugwump]

Douweegbertje schreef op vrijdag 5 juli 2019 @ 07:17:
[...]


lol 38 euro, het is eigenlijk bijna te triest. Ik las ook dat bestaande medewerkers daar dus niets krijgen. M.a.w. het bedrijf is te gierig om 38 euro p/p te betalen voor hun medewerkers die al in dienst zijn. Ja, je mag het wel krijgen,als je een referal aanbrengt die in dienst komt. Dit zegt mij al genoeg.

Mijn vorige werkgever gaf 1000 euro voor een nieuwe medewerker die via jou binnen kwam.

Het hoeft echt niet allemaal duur of veel te zijn, maar holy shit. Je kan ook gewoon een beetje coulant zijn.

Het is ook gewoon een marketingactie en wat dat betreft wel geslaagd aangezien ze er de media mee halen, maar er zal toch hopelijk geen developer serieus overwegen om vanwege die secundaire voorwaarde te gaan solliciteren.
Als ze dan kennelijk ook nog zo gierig zijn, dan slaan ze de plank wel behoorlijk mis als ze zich als een geweldig leuk bedrijf willen profileren.

[armageddon_2k1]

.oisyn schreef op donderdag 4 juli 2019 @ 11:30:
[...]Maar ook als je een boekhoudprogramma maakt hoop ik wel dat je de juiste datastructuren kiest, in plaats van alles maar gewoon in arrays te vrotten omdat dat nou eenmaal de standaard is.

Grappig dat je daar over begint. Ik ben zelf bezig m'n administratie in Rust (ja....waarom? Gewoon.) te maken, met WebAssembly.

Maar wat is nou eigenlijk een logische datastructuur? Dit is een persoonlijke administratie, dus je komt op maximaal een paar honderd transacties per jaar uit. Voor een bedrijf zijn het miljoenen transacties. In het eerste geval werkt voor mij een PriorityQueue (op datum) prima, maar met miljoenen transacties kom je toch 'gewoon' op een RDBMS uit?

[Immutable]

armageddon_2k1 schreef op zaterdag 6 juli 2019 @ 10:27:
[...]


Grappig dat je daar over begint. Ik ben zelf bezig m'n administratie in Rust (ja....waarom? Gewoon.) te maken, met WebAssembly.

Maar wat is nou eigenlijk een logische datastructuur? Dit is een persoonlijke administratie, dus je komt op maximaal een paar honderd transacties per jaar uit. Voor een bedrijf zijn het miljoenen transacties. In het eerste geval werkt voor mij een PriorityQueue (op datum) prima, maar met miljoenen transacties kom je toch 'gewoon' op een RDBMS uit?

Interessant wel. Hoe praat je via dat gegenereerde WebAssembly dan met de DOM Api, en andere WEB Api's welke volledig in Javascript zijn?

[Voutloos]

armageddon_2k1 schreef op zaterdag 6 juli 2019 @ 10:27:

Maar wat is nou eigenlijk een logische datastructuur? [...] maar met miljoenen transacties kom je toch 'gewoon' op een RDBMS uit?

Een RDBMS maakt nog geen datastructuur. Het is heel eenvoudig om een slecht model te maken.

[armageddon_2k1]

Fair enough

Je komt dan op een RDBMS uit waar je een juist model definieert met de juiste indices om de queries te ondersteunen die je nodig hebt, waar je een zo optimale afweging zal moeten maken tussen space en time complexity.

Zo dan?

Immutable schreef op zaterdag 6 juli 2019 @ 10:39:
[...]


Interessant wel. Hoe praat je via dat gegenereerde WebAssembly dan met de DOM Api, en andere WEB Api's welke volledig in Javascript zijn?

Oh, daar ben ik nog helemaal niet. Ik zie mijn Rust huishoudboekje lib meer als een standalone data model die wat functies exposed naar JS.

Ik heb vanuit m'n werk toegang tot Safari Books online, dus ben nu Progamming WebAssembly with Rust aan het lezen (https://www.amazon.com/Pr...pplications/dp/1680506366). Zodoende een hobbyprojectje.

Dat lijkt me ook de beste methode, vooralsnog. Rust mist nog bindings naar de DOM Api, maar ze zijn er wel mee bezig. Hoe gaaf is het als je straks gewoon React / Angular in Rust hebt.

[ Voor 62% gewijzigd door armageddon_2k1 op 06-07-2019 11:07 ]

[Immutable]

armageddon_2k1 schreef op zaterdag 6 juli 2019 @ 10:59:
Dat lijkt me ook de beste methode, vooralsnog. Rust mist nog bindings naar de DOM Api, maar ze zijn er wel mee bezig. Hoe gaaf is het als je straks gewoon React / Angular in Rust hebt.

Dit dus !! WebAssembly is in combinatie met Rust of C++ echt mooi.
Het was meer een retorische vraag om daar wat meer informatie uit te harken. Maar snap nu je bedoeling goed. Maar inderdaad. Wanneer al die api's beschikbaar zijn in Rust, C++ of andere talen denk ik dat het echt gaat doorbreken.

[bauke1994]

armageddon_2k1 schreef op zaterdag 6 juli 2019 @ 10:59:

Dat lijkt me ook de beste methode, vooralsnog. Rust mist nog bindings naar de DOM Api, maar ze zijn er wel mee bezig. Hoe gaaf is het als je straks gewoon React / Angular in Rust hebt.

Er zijn al wel wat bindings, ik geloof dat ze nog niet compleet zijn maar stdweb ondersteund er al wel wat.

En yew bestaat natuurlijk ook al ik heb er allemaal geen ervaring mee, daarvoor ontbreekt het nog een beetje aan tijd en ervaring met Rust.

[Douweegbertje]

armageddon_2k1 schreef op zaterdag 6 juli 2019 @ 10:59:
Fair enough

Je komt dan op een RDBMS uit waar je een juist model definieert met de juiste indices om de queries te ondersteunen die je nodig hebt, waar je een zo optimale afweging zal moeten maken tussen space en time complexity.

Zo dan?


[...]

Ben ik nou te simpel om gewoon te zeggen: je hebt relationele data, dus RDBMS? Ik snap je link nog niet zo goed. Je hebt het over datastructures en dan is er de vergelijking van RDBSMS vs PriorityQueue?

[armageddon_2k1]

Waar trek ik die vergelijking?

Als ik relationele data heb hoef ik er toch geen "database management systeem" tegenaan te gooien? Beetje afhankelijk van de grootte en de hoeveelheid relaties lijkt me.

[ Voor 74% gewijzigd door armageddon_2k1 op 07-07-2019 08:07 ]

[WernerL]

Je zult je data toch ergens op moeten slaan? Een PriorityQueue is een datastructuur die je binnen je applicatie gebruikt en in het geheugen leeft. Dat is weg zodra je applicatie stopt. Wil je zorgen dat je data blijft bestaan zul je toch een database nodig moeten hebben. Het alternatief is naar text-bestanden schrijven maar daar wordt je met relationele data ook niet blij van.

De grootte en hoeveelheid relaties kan wel van invloed zijn op het type RDBMS dat je kiest. Voor kleine applicaties voldoet SQLite, voor serieuzere applicaties iets als Postgresql.

[Merethil]

armageddon_2k1 schreef op zondag 7 juli 2019 @ 08:05:
Waar trek ik die vergelijking?

Nou, hier:

Maar wat is nou eigenlijk een logische datastructuur? Dit is een persoonlijke administratie, dus je komt op maximaal een paar honderd transacties per jaar uit. Voor een bedrijf zijn het miljoenen transacties. In het eerste geval werkt voor mij een PriorityQueue (op datum) prima, maar met miljoenen transacties kom je toch 'gewoon' op een RDBMS uit?

Maar een RDBMS lijkt mij niet zozeer een datastructuur zoals .oisyn die bedoelde; hij had het specifiek over arrays, lists, sets, hashtables etc. Dat zijn gewoon structuren zoals je ze in je applicatie gebruikt. Een database staat daar naar mijn mening volledig los van, die kan je ook aanspreken en daarna alles in een array vrotten. Of in losse variabelen die je allemaal "ID1", "ID2", "ID3" noemt en daardoor een belachelijke structuur bouwt.

[armageddon_2k1]

Okee, dan druk ik me wat onhandig uit denk ik Ik gooi inderdaad, foutief, database en datastructuur op een hoop.

Maar, wat zou nou een goede data-structuur zijn voor een boekhoudprogramma? Ligt natuurlijk aan de details en wat voor hierarchieen je toestaat, maar in de simpelste vorm is een boekhouding een simpele lijst met alleen maar entries a a [timestamp, amount, debtor, creditor]. Aangezien het altijd gesorteerd zal staan op timestamp kom je volgens mij al snel op een priority-queue uit of iets dergelijks.

[Mugwump]

armageddon_2k1 schreef op zondag 7 juli 2019 @ 11:04:
Okee, dan druk ik me wat onhandig uit denk ik Ik gooi inderdaad, foutief, database en datastructuur op een hoop.

Maar, wat zou nou een goede data-structuur zijn voor een boekhoudprogramma? Ligt natuurlijk aan de details en wat voor hierarchieen je toestaat, maar in de simpelste vorm is een boekhouding een simpele lijst met alleen maar entries a a [timestamp, amount, debtor, creditor]. Aangezien het altijd gesorteerd zal staan op timestamp kom je volgens mij al snel op een priority-queue uit of iets dergelijks.

Een "boekhoudprogramma" is qua data wel iets meer dan puur een kasboek.
Maar als je wilt bepalen wat een handige datastructuur zou zijn, mocht je het programma om de één of andere reden volledig in memory willen draaien, dan moet je kijken naar criteria. Is de data geordend? Kunnen er duplicaten voorkomen? Moeten lees- of juist schrijfoperaties geprioriteerd worden? Mogen er zaken verwijderd worden?

Efficiënte toegang hangt weer af van de vraag wat je met de data doet. Toon je alleen de hele lijst transacties als kasboek? Moet je ook informatievragen als "wat is het saldo van debiteur X" beantwoorden?

Er is niet zozeer een juist antwoord, maar vooral veel vragen met antwoorden die keuzes bepalen.

[EddoH]

Wat een gedoe over boekhouden en datastructuren. Als het over geld gaat is een dikke stack natuurlijk de enige optie.

[Matis]

EddoH schreef op zondag 7 juli 2019 @ 20:26:
Wat een gedoe over boekhouden en datastructuren. Als het over geld gaat is een dikke stack natuurlijk de enige optie.

I see what you did there

[Lethalis]

armageddon_2k1 schreef op zondag 7 juli 2019 @ 11:04:
Okee, dan druk ik me wat onhandig uit denk ik Ik gooi inderdaad, foutief, database en datastructuur op een hoop.

Maar, wat zou nou een goede data-structuur zijn voor een boekhoudprogramma? Ligt natuurlijk aan de details en wat voor hierarchieen je toestaat, maar in de simpelste vorm is een boekhouding een simpele lijst met alleen maar entries a a [timestamp, amount, debtor, creditor]. Aangezien het altijd gesorteerd zal staan op timestamp kom je volgens mij al snel op een priority-queue uit of iets dergelijks.

Een boekhoudprogramma bestaat al gauw uit dagboeken, grootboeken, crediteuren en debiteuren, en natuurlijk journaalposten.

Daarnaast krijg je ook subadministraties voor verkoop en inkoop, zodat je journaalposten kunt koppelen aan financiële transacties.

Ook zul je een BTW administratie hebben, zul je diverse overzichten moeten kunnen genereren, enzovoorts.

Daarnaast moet je aan bepaalde voorwaarden voldoen, factuurnummers moeten bijvoorbeeld chronologisch en sluitend zijn. Journaalposten mogen nooit gewijzigd kunnen worden (dan maak je maar lekker een credit, of je werkt met een boekingsbuffer), etc.

Niet iets dat je even zo bouwt

Wij hebben in onze ERP software een boekhoudprogramma. Al willen veel van onze klanten eigenlijk liever simpelweg met een bestaand programma koppelen dat de boekhouder al kent, zoals Exact of AccountView.

Maar goed, als je simpelweg normaliseert krijg je dus een tabel in een relationele database voor veel van de dingen die ik genoemd heb (dagboek, grootboek, journaalpost, etc).

Ik ben zelf niet zo'n fan van data hiërarchisch ordenen. Deels omdat ik het altijd op de relationele manier geleerd en gedaan heb, maar ook omdat ik het vaak onhandig vind.

[ Voor 9% gewijzigd door Lethalis op 07-07-2019 21:09 ]

[Loev]

First post in dit topic, go easy on me

//edit: Ow, ik lees nu de topic warning. Sorry! Vond het niet echt nodig om hier een special topic voor te openen. Waar mag ik dit wel kwijt? Of wel een apart topic openen?

* Loev is software tester

Ik ben aan het klooien met Selenium Webdriber, wat best aardig gaat alleen heb ik specifieke testdata nodig, dit kan ik inschieten d.m.v. een REST API. Ik zoek een Java lib waarmee ik een aanvraag (POST) kan inschieten en de response kan uitlezen. Hierin staat namelijk het dossiernummer die ik later nodig heb. Zelf al Rest assured gevonden maar die documentatie is niet best. Iemand ervaring met een library met gedegen documentatie voor de niet programmeerhelden? Dank!

[ Voor 36% gewijzigd door Loev op 08-07-2019 11:41 ]

[Mugwump]

Loev schreef op maandag 8 juli 2019 @ 11:37:
First post in dit topic, go easy on me

//edit: Ow, ik lees nu de topic warning. Sorry! Vond het niet echt nodig om hier een special topic voor te openen. Waar mag ik dit wel kwijt? Of wel een apart topic openen?

* Loev is software tester

Ik ben aan het klooien met Selenium Webdriber, wat best aardig gaat alleen heb ik specifieke testdata nodig, dit kan ik inschieten d.m.v. een REST API. Ik zoek een Java lib waarmee ik een aanvraag (POST) kan inschieten en de response kan uitlezen. Hierin staat namelijk het dossiernummer die ik later nodig heb. Zelf al Rest assured gevonden maar die documentatie is niet best. Iemand ervaring met een library met gedegen documentatie voor de niet programmeerhelden? Dank!

Dat zit gewoon standaard in Java. Zie bijvoorbeeld deze documentatie.

Vereist wel Java 11.

[ThomasG]

Mugwump schreef op maandag 8 juli 2019 @ 11:52:
[...]


Dat zit gewoon standaard in Java. Zie bijvoorbeeld deze documentatie.

Vereist wel Java 11.

Maar dan ben je er nog niet. Dan heeft hij nog steeds iets als Jackson nodig voor het parsen van de JSON die hij terug krijgt van de POST request.

[Mugwump]

ThomasG schreef op maandag 8 juli 2019 @ 11:56:
[...]
Maar dan ben je er nog niet. Dan heeft hij nog steeds iets als Jackson nodig voor het parsen van de JSON die hij terug krijgt van de POST request.

Klopt, zie b.v. deze informatie: https://openjdk.java.net/...ient/recipes.html#jsonGet

[Creepy]

Loev schreef op maandag 8 juli 2019 @ 11:37:
First post in dit topic, go easy on me

//edit: Ow, ik lees nu de topic warning. Sorry! Vond het niet echt nodig om hier een special topic voor te openen. Waar mag ik dit wel kwijt? Of wel een apart topic openen?

* Loev is software tester

Ik ben aan het klooien met Selenium Webdriber, wat best aardig gaat alleen heb ik specifieke testdata nodig, dit kan ik inschieten d.m.v. een REST API. Ik zoek een Java lib waarmee ik een aanvraag (POST) kan inschieten en de response kan uitlezen. Hierin staat namelijk het dossiernummer die ik later nodig heb. Zelf al Rest assured gevonden maar die documentatie is niet best. Iemand ervaring met een library met gedegen documentatie voor de niet programmeerhelden? Dank!

Als je maar eigen inzet toont dan kan dit prima in een eigen topic. De CC is hier inderdaad niet voor bedoeld zoals je zelf al zag... Maar even zoeken op "JSON JAVA" levert al een hoop resultaten op in google. Daar zit vast wel wat bruikbaars tussen Dus waarom heb je dat nog niet gedaan of waarom leverde dat bij jou geen bruikbare resultaten op?

[ Voor 4% gewijzigd door Creepy op 08-07-2019 12:03 ]

[Loev]

Creepy schreef op maandag 8 juli 2019 @ 12:03:
[...]

Als je maar eigen inzet toont dan kan dit prima in een eigen topic. De CC is hier inderdaad niet voor bedoeld zoals je zelf al zag... Maar even zoeken op "JSON JAVA" levert al een hoop resultaten op in google. Daar zit vast wel wat bruikbaars tussen Dus waarom heb je dat nog niet gedaan of waarom leverde dat bij jou geen bruikbare resultaten op?

Eerlijk gezegd had ik niet gedacht dat ik direct vanuit Java een REST API kan aanroepen. Ik ga verder klooien, en anders maak ik een topic aan. Dank voor de zoeksuggesties daar ben ik ook al meegeholpen.

[Mugwump]

Loev schreef op maandag 8 juli 2019 @ 12:28:
[...]

Eerlijk gezegd had ik niet gedacht dat ik direct vanuit Java een REST API kan aanroepen. Ik ga verder klooien, en anders maak ik een topic aan. Dank voor de zoeksuggesties daar ben ik ook al meegeholpen.

Een REST API aanroepen is in de basis niets anders dan een simpele HTTP request / response en wat conversie van je in- en output.
Dat kon altijd al wel in Java, maar sinds Java 11 hebben ze de interface daarvan flink verbeterd waardoor het nu een stuk eleganter kan.

[Hydra]

Loev schreef op maandag 8 juli 2019 @ 12:28:
Eerlijk gezegd had ik niet gedacht dat ik direct vanuit Java een REST API kan aanroepen.

Ik ga verder klooien, en anders maak ik een topic aan. Dank voor de zoeksuggesties daar ben ik ook al meegeholpen.

Een van de meest simpele manieren om REST API clients te bouwen is via Retrofit: https://square.github.io/retrofit/

Daarnaast zijn er vele wegen (libraries) die naar Rome leiden. Of je nu via Spring's Rest Template werkt, of via een HTTP client als OkHttp3. Ik doe dit soort werk heel erg veel dus stel me gerust vragen.

Tegenwoordig heeft Java ook wat meer API-interne spullen maar die halen het over het algemeen niet bij meer gespecialiseerde libraries.

[ Voor 14% gewijzigd door Hydra op 08-07-2019 15:35 ]

[rvankruistum]

Loev schreef op maandag 8 juli 2019 @ 11:37:
* Loev is software tester

Ik ben aan het klooien met Selenium Webdriber, wat best aardig gaat alleen heb ik specifieke testdata nodig, dit kan ik inschieten d.m.v. een REST API. Ik zoek een Java lib waarmee ik een aanvraag (POST) kan inschieten en de response kan uitlezen. Hierin staat namelijk het dossiernummer die ik later nodig heb. Zelf al Rest assured gevonden maar die documentatie is niet best. Iemand ervaring met een library met gedegen documentatie voor de niet programmeerhelden? Dank!

Hierboven al een hoop goede suggesties. Verder zou ik je aanraden om niet afhankelijk te zijn van API's om je testdata op te voeren. Je loop dan het risico dat je test faalt omdat de API niet werkt, in plaats van omdat het resultaat van je test niet klopt. Bovendien kan je beginsituatie veranderen zonder dat je het door hebt als de API aangepast wordt. Het is beter om de data direct te inserten zodat je zeker weet dat de beginsituatie altijd hetzelfde is.

[diabolofan]

Laatst even kort gespeeld met NativeScript en dat werkt toch wel echt geweldig zeg! Onze app is momenteel met Xamarin.Forms gebouwd (dus ook cross platform), maar die C# builds duren altijd vrij lang, dus zit je relatief lang te klooien om een mooie UI te krijgen (steeds opnieuw builden e.d., van die XAML previewer heeft ook diverse gebreken). Dat dan in vergelijking met NativeScript die real time reloads doet... En aangezien we in de frontend Angular gebruiken, ben je dat snelle laden ed (wat tijdens ontwikkelen erg fijn is) wel enigsinds gewend geraakt, waardoor elke keer dat je met Xamarin.Forms werkt je je toch te vaak zit te vervelen als tie weer aan het builden is. Xamarin doet gelukkig wel wat pogingen om het ook sneller te krijgen (XAML Hot Reload, https://devblogs.microsoft.com/xamarin/xaml-hot-reload/), maar heb het gevoel dat ze nooit zo snel/fijn als NativeScript gaan worden.

Ligt er uiteraard aan wat voor app je hebt, want je kan natuurlijk wel last krijgen van die relatief 'trage' JS bridge die NativeScript nodig heeft. Maar aangezien wij in onze apps veel CRUD werk e.d. hebben (en geen fancy game ui), lijkt NativeScript een goede richting...

Iemand soortgelijke/andere ervaringen met NativeScript voor business apps?

[qless]

Wel wat mee gespeeld, maar op moment vindt ik voor universal apps flutter de beste keuze. Hot reload werkt fantastisch, compiled naar native, goede perfomance. Nadeel: dart + weer iets van google.

[Gropah]

Van wat ik heb gehoord van binnen het bedrijf waar ik werk: het leek erg promising, maar er waren nogal wat problemen met startup times en android app links (en het equivalent op ios) waarmee je je app aan bepaalde links kunt haken. Uiteindelijk is er overgeschakeld naar native app development.

[Barryvdh]

diabolofan schreef op donderdag 11 juli 2019 @ 22:10:
Laatst even kort gespeeld met NativeScript en dat werkt toch wel echt geweldig zeg! Onze app is momenteel met Xamarin.Forms gebouwd (dus ook cross platform), maar die C# builds duren altijd vrij lang, dus zit je relatief lang te klooien om een mooie UI te krijgen (steeds opnieuw builden e.d., van die XAML previewer heeft ook diverse gebreken). Dat dan in vergelijking met NativeScript die real time reloads doet... En aangezien we in de frontend Angular gebruiken, ben je dat snelle laden ed (wat tijdens ontwikkelen erg fijn is) wel enigsinds gewend geraakt, waardoor elke keer dat je met Xamarin.Forms werkt je je toch te vaak zit te vervelen als tie weer aan het builden is. Xamarin doet gelukkig wel wat pogingen om het ook sneller te krijgen (XAML Hot Reload, https://devblogs.microsoft.com/xamarin/xaml-hot-reload/), maar heb het gevoel dat ze nooit zo snel/fijn als NativeScript gaan worden.

Ligt er uiteraard aan wat voor app je hebt, want je kan natuurlijk wel last krijgen van die relatief 'trage' JS bridge die NativeScript nodig heeft. Maar aangezien wij in onze apps veel CRUD werk e.d. hebben (en geen fancy game ui), lijkt NativeScript een goede richting...

Iemand soortgelijke/andere ervaringen met NativeScript voor business apps?

React Native is wat populairder/volwassener nog toch? https://github.com/facebook/react-native

[Gropah]

Barryvdh schreef op vrijdag 12 juli 2019 @ 11:09:
[...]


React Native is wat populairder/volwassener nog toch? https://github.com/facebook/react-native

populairder betekend niet meteen beter En ze zijn ongeveer even oud, tenminste hun source. react native vs native script

Maar ze hebben een andere insteek, react native probeert (afaik) op alle platformen hetzelfde weer te geven en je zit alsnog meer met HTML achtige componenten te werken, terwijl nativescript alles in native onderdelen probeert te doen, dus het ziet er platform compliant uit. Hierdoor zijn is het ook iets makkelijker om native calls te doen.

[diabolofan]

qless schreef op vrijdag 12 juli 2019 @ 09:53:
Wel wat mee gespeeld, maar op moment vindt ik voor universal apps flutter de beste keuze. Hot reload werkt fantastisch, compiled naar native, goede perfomance. Nadeel: dart + weer iets van google.

Flutter vind ik qua UI wel stuk minder handig ogen dan NativeScript. Bij Flutter heb je bijvoorbeeld diverse iOS-only UI compontenten (en andersom ook Android-only), wat niet erg crossplatform doet overkomen.

Barryvdh schreef op vrijdag 12 juli 2019 @ 11:09:
[...]


React Native is wat populairder/volwassener nog toch? https://github.com/facebook/react-native

Geen ervaring mee / Nog niet naar gekeken. Maar ziet er voor ons wat onhandiger uit, aangezien we al Angular gebruiken voor de frontend, waardoor NativeScript Angular logischer is dan React.

[Pizzalucht]

Wij hebben onze 2 native apps omgebouwd naar NativeScript icm Angular. De NativeScript app deelt een groot stuk code met onze Angular webapp. Op zich is doet goed bevallen, en de apps/webapp gelijk houden qua features is nu veel beter te doen, maar het is denk ik belangrijk om de volgende dingen te weten:

• De startup tijd kan een tegenvaller zijn, er zijn wel manieren om dit te verbeteren maar het is volgens mij nooit echt top
• Sommige dingen moet je nog wel native bouwen, dit is goed te doen in NativeScript, maar het is dus wel handig om iemand te hebben die verstand heeft van iOS en Android (of 2 losse developers), denk aan het aanroepen van de camera of het aanroepen van externe SDKs (Google Maps, Facebook login), voor veel van deze dingen zijn al plugins gemaakt, maar als je wat ingewikkeldere dingen gaat doen ga je al snel je eigen plugins bouwen of bestaande plugins aanpassen
• Alles draait op de UI thread in NativeScript, dit hebben ze gedaan zodat je direct vanuit JavaScript code native calls kan uitvoeren, maar dit zorgt er wel voor dat je vrij makkelijk de UI thread kan blocken, ze hebben wel WebWorkers support maar dat zorgt ervoor dat er een hele nieuwe JavaScript engine wordt geladen voor die Worker thread, en het werkt nog niet echt goed icm Angular
• Soms heb je te maken met bugs in de weergave waardoor de rendering net anders is tussen Android/iOS, dit vereist dan wat rare hacks om het gelijk te krijgen

[qless]

diabolofan schreef op vrijdag 12 juli 2019 @ 11:40:
[...]


Flutter vind ik qua UI wel stuk minder handig ogen dan NativeScript. Bij Flutter heb je bijvoorbeeld diverse iOS-only UI compontenten (en andersom ook Android-only), wat niet erg crossplatform doet overkomen.


[...]

Nee zowel material als cuppertino werken allebei op zowel android als ios, ze zijn echt platflormonafhanelijk. Ik kies zelf altijd 1 van beide als basis, en pas daarop nog wat styling toe.

[diabolofan]

qless schreef op vrijdag 12 juli 2019 @ 14:08:
[...]


Nee zowel material als cuppertino werken allebei op zowel android als ios, ze zijn echt platflormonafhanelijk. Ik kies zelf altijd 1 van beide als basis, en pas daarop nog wat styling toe.

Dus dat betekend bij Material dat je Android styling hebt op iOS en bij Cuppertino dat je iOS styling hebt op Android? Lijkt me toch niet wenselijk?

[qless]

Nou vindt ik persoonlijk material mooier dan cuppertino, maar inderdaad dat kan. Of je laat switchen aan de hand van welk platform er gebruikt wordt, kan ook. Of je maakt volledig je eigen styling....

[Matis]

Zo, weer thuis na een week Majorca. Wat ben ik toch blij met de kwaliteit van het leiding-/kraanwater hier in Nederland.

[Sebazzz]

@discussie over NativeScript: Hoe goed werkt het als je "custom zaken" wilt? Bij Kendo en ook de Web Forms gaan ze er redelijk vanuit dat je je hele applicatie ermee opbouwd en de standaard thema's gebruikt, anders heb je nogal een styling ... uitdaging. Ook lijken sommige features puur voor de demo gebouwd te lijken, en gaat het stuk zodra je het daadwerkelijk implementeert.

Matis schreef op vrijdag 12 juli 2019 @ 22:34:
Zo, weer thuis na een week Majorca. Wat ben ik toch blij met de kwaliteit van het leiding-/kraanwater hier in Nederland.

Mijn darmen wel ja

[Immutable]

qless schreef op vrijdag 12 juli 2019 @ 09:53:
Wel wat mee gespeeld, maar op moment vindt ik voor universal apps flutter de beste keuze. Hot reload werkt fantastisch, compiled naar native, goede perfomance. Nadeel: dart + weer iets van google.

Ik denk niet dat veel mensen inzien (technisch gezien) hoe goed flutter eigenlijk is. Onder de motorkap heeft het de mogelijkheid om een soort QT QML achtig systeem te worden, maar dan zonder de nadelen van QT en veel beter cross-platform. (Als ze eens een fatsoenlijke interface bouwen naar andere talen zoals C++)

Maar als ze dat doen. Zie ik voor 2D applicaties dat het echt true multiplatform kan worden.
Voor zowel:
- Android
- iOS
- Windows (Goede vervanger voor Electron)
- OSX (Ook goede vervanger voor Electron)
- Linux (Ook goede vervanger voor Electron)
- En in de browser ! (Hummingbird) zie hier een demo: https://flutter.github.io/samples/gallery/frame.html

(Ook veel potentie voor embedded systemen, net als QT. Of bijvoorbeeld Kiosk systemen, hier draait het op een raspberry pi: https://medium.com/flutte...from-scratch-2824c5e7dcb1)

Daarnaast inderdaad. Hot reload voor snelle develop iteretaties.
Plus je hebt hele grote vrijheid betreft custom widgets. Omdat eigenlijk alles een custom widget is. Ja daar zit ook wel een nadeel aan verbonden. De huidige Android & iOS widgets volgen nu de native widgets. Dus als er native iets wijzigd zal de custom widgets dus moeten worden bijgewerkt worden.

De keuze voor Dart is opzich best logisch als je nadenkt. De hybrid functie van JIT & AOT zorgt er juist voor dat je de voordelen van beide hebt. En het werkt in de browser omdat je Dart -> Javascript kan doen, en straks vast naar webassembly.
Dart is tevens een behoorlijk snelle script taal, en multiplatform.

Flutter voert de zware performance zaken uit in C++ met Skia 2D teken api naar de GPU, met daarboven een soort laag je waar de developer dus met Dart alles kan ontwikkelen.
QT met QTQuick hier het dichts bij in de buurt. (En als je wel eens in een Tesla S/X/3 hebt gezeten, weet je dus wat mogelijk is met QT Quick. Wat voor fancy en snelle UI je kan maken.. dat komt voornamelijk door de opbouw.) Dezelfde opbouw doet Flutter dus.

Ik weet echter dat de wereld niet altijd voor de technisch beste oplossing kiest. Maar dat community en ecosysteem ook vaak heel belangrijk is. Dus we zullen zien. Ik hoop op een goede C++ interfacen tussen dart en C++. Net zoals QT met QML een eigen QT signal/slot interface gebruiken om te communiceren tussen C++ en QML. Er gaan al wel geruchten om bijvoorbeeld sowieso gRPC werkend te maken. En dat is ook al een soort multiplatform interface tussen verschillende talen, alleen vraag ik me af of de performance ook daarvoor wel hoog is.

[ Voor 14% gewijzigd door Immutable op 14-07-2019 21:22 ]

[sig69]

Immutable schreef op zondag 14 juli 2019 @ 20:55:
[...]


Ik denk niet dat veel mensen inzien (technisch gezien) hoe goed flutter eigenlijk is. Onder de motorkap heeft het de mogelijkheid om een soort QT QML achtig systeem te worden, maar dan zonder de nadelen van QT en veel beter cross-platform. (Als ze eens een fatsoenlijke interface bouwen naar andere talen zoals C++)

Maar als ze dat doen. Zie ik voor 2D applicaties dat het echt true multiplatform kan worden.
Voor zowel:
- Android
- iOS
- Windows (Goede vervanger voor Electron)
- OSX (Ook goede vervanger voor Electron)
- Linux (Ook goede vervanger voor Electron)
- En in de browser ! (Hummingbird) zie hier een demo: https://flutter.github.io/samples/gallery/frame.html

Als dit hun demo is zijn ze mij kwijt want dit draait op mijn telefoon voor geen meter.

[F.West98]

Immutable schreef op zondag 14 juli 2019 @ 20:55:
[...]
Maar als ze dat doen. Zie ik voor 2D applicaties dat het echt true multiplatform kan worden.
Voor zowel:
- Android
- iOS
- Windows (Goede vervanger voor Electron)
- OSX (Ook goede vervanger voor Electron)
- Linux (Ook goede vervanger voor Electron)
- En in de browser ! (Hummingbird) zie hier een demo: https://flutter.github.io/samples/gallery/frame.html

Dit is dus exact waarom ik (vooralsnog) een hekel heb aan PWA en aanverwanten. Ze proberen native na te doen, maar het is het net niet en dat is echt enorm irritant. Laggy scrolling, random missende touchanimaties, vertragingen na een druk op de knop, menuteksten die niet de system text size settings volgen (in Android kan je de letters systemwide kleiner zetten, praktisch alle apps luisteren daar naar), animaties die net niet overeenkomen met native, etc. En op desktop zijn de lettertypes vreemd..?

Tuurlijk, de meer volledige demo's zijn best impressive, en sommige animaties zien er erg goed uit. Maar dan klik je een dropdown aan en dan heb je ineens enorme lag en vertraging. De fuck? Dus ja, zorg eerst dat die basis gefixt is voordat dit soort dingen als de oplossing voor alles gepresenteerd worden.

[qless]

Flutter voor web is nog wel in test, flutter apps voor Android en IOS zijn wel vloeiend en snel

[Pizzalucht]

Sebazzz schreef op zaterdag 13 juli 2019 @ 17:23:
@discussie over NativeScript: Hoe goed werkt het als je "custom zaken" wilt? Bij Kendo en ook de Web Forms gaan ze er redelijk vanuit dat je je hele applicatie ermee opbouwd en de standaard thema's gebruikt, anders heb je nogal een styling ... uitdaging. Ook lijken sommige features puur voor de demo gebouwd te lijken, en gaat het stuk zodra je het daadwerkelijk implementeert.

Wat bedoel je met custom zaken?
Voor styling importeren wij de "nativescript-theme-core" SCSS, en daar overheen onze eigen styling, dit werkt erg goed.
Custom zaken zoals native activities/widgets/views zijn goed te doen dmv gesplitste code, je maakt dan een interface/common methods in je {plugin}.ts file, en je native logica in {plugin}.{android/ios}.ts, waardoor je de logica per platform kan scheiden. Omdat je vanuit JavaScript de native methods kan aanroepen zit je niet met een native laag tussen je NativeScript app en native code. Je kan ook nieuwe elementen registreren waardoor je een gedeelte van de view kan vervangen door een native plugin die per platform een andere implementatie heeft (denk aan Google Maps, Lottie).

Welke zaken lijken alsof ze puur voor demo gebouwd zijn?

[CurlyMo]

Voor de C kenners onder ons zoals @farlane. Is het mogelijk om in C naar generic shared libraries te linken. Daarmee bedoel ik dat C geen link heeft naar een specifieke versie, maar naar generiek een library.

Concreet heb ik het probleem dat mijn software linkt aan libmbedtls10. Nu heeft Debian Buster alleen libmbedtls12 in zijn repositories. Mijn software werkt net zo goed met beide versie dus twee versies van mijn software aanbieden zou wat mij betreft niet nodig hoeven zijn, maar ik weet niet of het mogelijk is mijn applicatie te vertellen dat hij beide versies mag gebruiken.

[Creepy]

Eehhmm... die topic warning he.........

[CurlyMo]

Creepy schreef op maandag 15 juli 2019 @ 19:27:
Eehhmm... die topic warning he.........

Moet ik daar echt een eigen topic voor openen?

[Creepy]

Ja? Kom op zeg, nog ff toevoegen wat je zelf al hebt geprobeerd en gaan..... ik snap echt niet waarom men hier soms lijkt te weigeren om een topic te openen maar dan wel hier een concrete programeervraag stellen...

[CurlyMo]

Creepy schreef op maandag 15 juli 2019 @ 19:47:
Ja? Kom op zeg, nog ff toevoegen wat je zelf al hebt geprobeerd en gaan..... ik snap echt niet waarom men hier soms lijkt te weigeren om een topic te openen maar dan wel hier een concrete programeervraag stellen...

Tsja, als je zelf in ik weet niet hoeveel topics andere geholpen heb, dan is het soms wel prettig om ergens even een concrete vraag te stellen. Dan hoop ik ook dusdanige goodwill gekweekt te hebben om dat dan in zeldzame gevallen te mogen en men er vanuit gaat dat ik niet zomaar een vraag stel

Maar, je hebt gelijk. Ik geef toe dat ik de topic warning niet gezien had en irriteer er mezelf ook genoeg aan als anderen hem niet respecteren

[Creepy]

Het is juist omdat ik weet dat je (en ook sommige anderen) niet zomaar een vraag stelt ik me verbaas over het niet openen van een los topic.

[CurlyMo]

Creepy schreef op maandag 15 juli 2019 @ 20:10:
Het is juist omdat ik weet dat je (en ook sommige anderen) niet zomaar een vraag stelt ik me verbaas over het niet openen van een los topic.

Omdat ik het openen van een topic als iets speciaals zie dat je niet lichtvoetig doet (in tegenstelling tot genoeg anderen)

Maar goed, ik ga eerst zelf nog even verder stoeien.

[armageddon_2k1]

Je hebt nou al zoveel toetsaanslagen verspilt aan de discussie
Open dat topic nou gewoon, dan is het ook terug te vinden voor anderen in de toekomst.

[Woy]

@CurlyMo je post is al bijna genoeg voor een topic. Als je even vermeld met welke zoektermen/instellingen het niet wilde lukken is het al een prima topic

[farlane]

CurlyMo schreef op maandag 15 juli 2019 @ 19:22:
Voor de C kenners onder ons zoals @farlane. Is het mogelijk om in C naar generic shared libraries te linken. Daarmee bedoel ik dat C geen link heeft naar een specifieke versie, maar naar generiek een library.

Concreet heb ik het probleem dat mijn software linkt aan libmbedtls10. Nu heeft Debian Buster alleen libmbedtls12 in zijn repositories. Mijn software werkt net zo goed met beide versie dus twee versies van mijn software aanbieden zou wat mij betreft niet nodig hoeven zijn, maar ik weet niet of het mogelijk is mijn applicatie te vertellen dat hij beide versies mag gebruiken.

Link mbedtls10.so naar mbedtls12.so .....


Hmmm....wat?

[ Voor 3% gewijzigd door farlane op 15-07-2019 20:57 ]

[R4gnax]

Immutable schreef op zondag 14 juli 2019 @ 20:55:

Flutter voert de zware performance zaken uit in C++ met Skia 2D teken api naar de GPU, met daarboven een soort laag je waar de developer dus met Dart alles kan ontwikkelen.

Hmm.. ik vraag me eerlijk gezegd af of Microsoft deze weg ook in zal gaan met Blazor, hoewel zij in tegenstelling tot Flutter een web-first aanpak nemen. (Nou ja; de novieteit van .NET Core direct in je browser draaien is natuurlijk ook wel een fraai te misbruiken marketing voordeel.)