GitHub begint certificeringsprogramma met vier disciplines

GitHub heeft een eigen certificaatprogramma opgezet. Het platform heeft momenteel vier verschillende certificeringen waarmee gebruikers na een examen kunnen bewijzen expert te zijn in meerdere disciplines.

GitHub had dat certificeringsprogramma al voor eigen werknemers en voor bepaalde 'partners', maar het platform zegt nu dat het dat programma algemeen beschikbaar maakt. Met het programma kunnen ontwikkelaars bewijzen expert te zijn in bepaalde disciplines binnen het platform. GitHub heeft, via Microsofts Learn-platform, leermiddelen beschikbaar gesteld voor geïnteresseerden.

Het platform biedt vier certificeringen aan. GitHub Foundations is een certificering waarin deelnemers algemene kennis over GitHub en git leren. Daarnaast is er GitHub Actions, dat gaat over programmeerworkflows en pipelines. De Advanced Security-certificering gaat over het beveiligen van code en leert ontwikkelaars dependencymanagement en om te scannen op secrets. Dat certificaat is er vooral voor ontwikkelaars in zakelijke omgevingen, zegt GitHub. Tot slot is er nog het Administration-certificaat, waarmee gebruikers leren een eigen GitHub-omgeving op te zetten en te beheren.

Het kost 200 dollar om een examen af te leggen. Herexamens kosten telkens weer 200 dollar. Gebruikers moeten 48 uur tussen twee examens laten zitten en mogen die maximaal vijf keer maken. GitHub werkt samen met PSI om de examens af te leggen en voor de proctoring.

GitHub certificering

Door Tijs Hofmans

Nieuwscoördinator

09-01-2024 • 20:59

64

Submitter: wildhagen

Reacties (64)

64
64
27
0
0
32
Wijzig sortering
Oh eh. Ik zat er aan te denken om onze pipeline redelijk op het github platform in te richten. Daar ga ik nog maar eens over nadenken of ik dat wel wil. Het is ook wel de trend om iedereen je platform binnen te trekken en zoveel mogelijk te te binden met gespecialiseerde platform kennis.

Krijgen we straks weer allemaal github experts die alleen op github hun trucje uit kunnen voeren?

Nee dank je.
Wat maakt dat deze certificeringen je laten twijfelen? Ik zie het verband nog niet zo...

Veel CI/CD platforms gebruiken YML voor de configuratie en ze kennen allemaal iets als stages, jobs, tasks en steps. Maar allemaal hebben ze hun eigen "slang". Je zal altijd iets platform specifieks moeten configureren en kan het zelden 1-op-1 uitwisselen.
Met twijfelen doel ik sterker dat ik mijzelf niet de hoek in zal gaan schilderen en teveel ga leunen op github specifieke features en implementaties. In het geval van github actions is dat toch al snel het geval. Al is dat met gitlab niet echt heel anders I guess.

Ik ben bekend met CI/CD oplossingen. Werk er al aardig wat jaartjes mee. Maar ik zie deze certificeringen niet echt zitten, maar dat heb ik altijd al gehad met IT certificeringen.
In mijn ~ 25 jaar ervaring in de IT weinig correlatie gezien tussen certificeringen en kunde.
Dat hangt er natuurlijk vanaf of je leert om de certificering te behalen, of omdat je de certificering haalt met de kennis die je al hebt. Dat laatste zou eigenlijk het geval moeten zijn.

Voor wat betreft je zorgen over Github specifieke technologie, die begrijp ik niet echt. Dat heb je nagenoeg altijd. En het is natuurlijk niet zo dat als je GitHub door en door kent, je niks begrijpt van GitLab om maar wat te noemen. In de basis zijn die concepten hetzelfde.
Helemaal gelijk, het is net de monteur die specifiek alleen een Mercedes of Toyota maakt , maar kan eigenlijk elke auto maken, je leert altijd de grondbeginselen, zo is Github er 1 van (noem het Mercedes) en is een andere tool nr 2 of tig (noem het Toyota/BMW of welk merk ook). Altijd handig om er een beetje kaas van te hebben gegeten. zo kom je sneller verder met andere tools en vice versa.
Dat hangt er natuurlijk vanaf of je leert om de certificering te behalen, of omdat je de certificering haalt met de kennis die je al hebt. Dat laatste zou eigenlijk het geval moeten zijn.
In mijn ervaring werkt het juist andersom. Als je de kennis en ervaring al hebt voegt zo'n certificaat weinig toe, dus waarom die mallemolen in? Het zijn juist de mindere helden die graag een certificaat halen als extra 'bewijs' dat ze het kunnen.
Kan zelfs averechts werken. Dat je voor het certificaat volgens de methode moet doen terwijl er meerdere wegen naar Rome zijn en iemand die al jaren de kennis heeft een andere route bewandeld. En je niet op je resultaat word beoordeeld, maar of je wel de juiste methode//route bewandeld.
Zo'n certificaat wordt dan een bevestiging dat je die kennis en kunde ook daadwerkelijk hebt. Dat is vooral voor een toekomstige werkgever prettig. Natuurlijk zijn certificaten niet heilig en in lang niet alle gevallen echt nuttig, maar zo zou het moeten zijn.
Ik snap nog steeds je reactie niet in de context van een simpel certificering programma dat wordt besproken in bovenstaand artikel? :?

Wat in dit artikel maakt dat je nu ineens twijfelt? Dat anderen een certificaatje kunnen halen? Wat heeft dat voor invloed op je keuze om wel of niet GitHub te gebruiken, of delen van GitHub wel of niet te gebruiken?

Kan mij overigens goed vinden in je stelling dat er weinig correlatie tussen certificering en kunde zit, alhoewel ik met 10 jaar nog niet zo lang meega als jij ;)
Waarschijnlijk omdat zulk een programma meer bedoelt is als reclame en cash-grab dan om werkelijk iets te leren. Niet anders dan MS certificaten etc etc.

Er lopen nog al wat gecertificeerde "experts" rond die ik geen cent zou betalen. Ze hebben de slogans en het truucje geleerd, maar kunnen in de praktijk niets.

Wat wij nodig hebben in het bedrijf zijn mensen die zelfstandig kunnen nadenken en extrapoleren en meerdere producten kunnen bekijken en evalueren. Niet mensen die een cert hebben gehaald door stampen voor een paar dagen omdat het leuk staat op je cv.

Er zijn ook heel ervaren goede mensen met certificaten, maar zoals anderen al hebben gesteld, is de correlatie meestal omgekeerd. Hoe meer ervaring en hoe beter ze zijn, hoe minder interesse in certificaten ze hebben.
Certificeringen zijn bedoeld om als medewerker of bedrijf aan te tonen dat je in bezit kent van bepaalde competenties. Een certificaat is niet verplicht om met GitHub te kunnen worden.

Echter als jullie development doen voor andere bedrijven, kan het niet hebben van een dergelijke certificering ervoor zorgen dat de opdrachtgever kijkt naar de concurrentie. In deze is een GitHub certificering niet anders dan een Microsoft, Oracle Comptia of ISO certificering.
kan het niet hebben van een dergelijke certificering
correct en het is ook bij aanbestedingen van belang.

Maar gelukkig kan je ook scoren op de kwaliteit van je product in veel gevallen. En verder doen we het minimum aan certificering om de vinkjes te kunnen zetten. Dat ik het niets vind, wil niet zeggen dat ik de realiteit van de zakelijke wereld onderken of negeer.
Certificeringen zijn bedoeld om als medewerker of bedrijf aan te tonen dat je in bezit kent van bepaalde competenties.
In theorie, in de praktijk is niets minder waar dan dat. Het zegt alleen dat je mensen hebt die goed feitjes kunnen stampen.
In deze is een GitHub certificering niet anders dan een Microsoft, Oracle Comptia of ISO certificering.
absoluut, ik heb issues met al die certificaten. Ik vind de kwaliteit er van helemaal niets en ze tonen nog minder aan dan niets. ze focussen zich zeker bij MS niet op wat goed is, maar op wat microsoft op dat moment graag in de markt wil verkopen. Het is marketing.
Nadat je van regulier onderwijs vertrekt kijkt niemand meer naar je diploma of de cijfers daarop, het is alleen nog maar niveau (hbo, mbo etc) en zelfs dat kan genegeerd worden als je de ervaring hebt. Waarom deze certs anders behandeld worden, heb ik nog niet kunnen ontdekken. Je stampt feiten, haalt ze, volgende dag 90% vergeten en nog steeds geen praktijkervaring.

[Reactie gewijzigd door bzuidgeest op 22 juli 2024 23:21]

Vind GitHub actions wel echt een uitkomst voor kleine projectjes. Even snel een pipeline opzetten en dan deze kunnen runnen zonder eigen runner is heel fijn.

Daarnaast heeft natuurlijk elk cicd platform zijn eigen syntax
Met twijfelen doel ik sterker dat ik mijzelf niet de hoek in zal gaan schilderen en teveel ga leunen op github specifieke features en implementaties. In het geval van github actions is dat toch al snel het geval. Al is dat met gitlab niet echt heel anders I guess.
dat is met alle opllossingen zo. Er is er geen 1 die je in place kunt vervangen door een ander zonder daar iets van werk aan te doen. Enige wat je kunt doen is het dan weer gieten in iets als bash of python zodat je het ook lokaal zou kunnen doen op dezelfde manier, maar dan verlies je weer heel veel controle die de platformen je geven (zoals overzichten van stages en steps, archivering van artefacts en test result trends over de hele linie).

Ik ben tot op heden nog steeds het meest te spreken over Jenkins, Gitlab is echt onoverzichtelijk en github actions is nog een beetje kinderschoenen ofzo. Ik ben ook niet zo van het declarative. Condities en triggers zijn dan vaak echt lastig goed te krijgen en die missen dan volledig in je overzicht als ze worden geskipped bijvoorbeeld.
Je kunt ook de training doen zonder examen en certificering...
Ik heb de trainingen altijd gezien als snelle methode om gericht kennis op te doen.
Dat is nogal afhankelijk van de kennis van je trainer. Ik kom heel veel trainers tegen die nauwelijks meer kunnen dan het boekje voorlezen.

Ja het is een prima methode voor introductie in onderwerpen, maar als ik de kans krijg sta ik altijd op een trainer met relevante bedrijfservaring. Dan kan je tenminste een serieus gesprek voeren. Examinering kan je daarna inderdaad negeren.

[Reactie gewijzigd door bzuidgeest op 22 juli 2024 23:21]

Dit is een Microsoft Learning, dus in de basis zal het een digitale cursus zijn verwacht ik.
Met een 200 dollar examinering aan het einde, dat is makkelijk verdienen!
Ja, als je de certificering wil moet je betalen voor het examen, dat is meestal het geval bij certificeringen.
Ja, maar staat het bedrag in relatie tot wat je krijgt? Een paar videos, wat text en dan point en click examen.....
Laat een miljoen mensen dat examen doen * 200 dollar. 90% winstmarge schat ik zo. De prijs ligt alleen maar hoog omdat een goedkoop certificaat minder waarde heeft in mensen hun hoofd.
Doe eens een CISSP of CCNA of Exin examen, die zijn ook echt niet goedkoper. En of daar veel of weinig marge op zit, durf ik echt niet te zeggen, het lesgeven of examens ontwerpen en verkopen is niet mijn vakgebied.
Wel had ik dat de werkgever de trainingen en examens voor mij betaalde waar relevant, het was immers een training volgen en gelijk daarna ermee aan de slag, of veel langere doorlooptijd iets implementeren waarin ander werk niet gedaan kon worden, waardoor extra inhuur nodig was.
O zeker, het is niet uniek aan github, dat wil ik niet beweren. En ja de werkgever betaald alles, maar dan mag ik nog steeds wat van de prijs vinden. :+
Maar doe je dat niet aan de lopende band in de IT-wereld? Je leert een specifieke programeertaal, je gebruikt een specifiek framework, je zit al snel in een 'hoek'.
Ja je gebruikt platform specifieke features maar de principes die je leert, ook met bv Github Actions, zijn toepasbaar op andere vergelijkbare platforms.

Voor wat betreft certificeringen geef ik je helemaal gelijk, ik heb er ooit een aantal behaald, maar uiteindelijk heb je het meest aan hands on ervaring. Zoveel ontwikkelaars meegemaakt die stapels certificaten hadden maar veel te weinig praktische kennis. Zelfs managers die al die certificeringen hadden maar uiteindelijk nog niet begrepen waar het nu precies omdraait.
Ik ben altijd verbaasd over hoe verschillend de platformen zijn. Met Jenkins zelf niet gewerkt, maar wel TeamCity, Gitlab en Github. Teamcity had weer runners die je scriptte met ANT/ANTler, Gitlab en Github zijn weer YAML files. Ik vind met deze laatste twee platformen dat je weer beetje de oude issues krijgt met extending. Toch is het wel nuttig om te doen. Ik blijf wel fan van het github ecosysteem. Gitlab vind ik op een andere manier weer prettig. Ik denk dat ik mij er wel aan ga wagen. Ook een leuk certificaatje voor de verandering.
Mwoah, doe de built in een Makefile/Maven/Ant whatever tool en gebruik de CI/CD als scheduler. Ben je behoorlijk ontkoppelt van de fancy-smancy tool du jour.
Jij gaat net als ik al weer veel te lang mee in het wereldje... dat zijn drie dinosaurier build/project configuratie tools voor de oude garde (prima gereedschap, daar niet van, gebruik zelf maven ook nog altijd tot volle tevredenheid)
Jeez dat is lang geleden ;). Wat maakt het uit welke technologie er onder zit, uiteindelijk gaat het erom dat je in wisselende ci/cd omgevingen je doel bereikt. Gebruik maken van de funtionaliteit van een dergelijke omgeving is voor mij een stuk eenvoudiger en efficiënter. Als ik iets niet voor elkaar krijg kan ik maven, ant enz ook wel gebruiken in een van mijn stappen van het CI/CD proces.

De wereld waarin we werken veranderd continu, en daar heb je weer allerlei nieuw tools die je leven en stuk makkelijker maken. Gebruik blijven maken van "het bekende" werkt op den duur niet meer.
en daar heb je weer allerlei nieuw tools die je leven en stuk makkelijker maken
Als ze dat dan ook daadwerkelijk deden zou de adoptie ook wat sneller gaan denk ik zo ;)

Iedere tool heeft zo zijn voor en nadelen. Als Javaan ben ik heel tevreden met Maven en Jenkins scripted DSL. Dan kun je namelijk je pipeline en configuratie ook in Java beschrijven.

Maar YML declaratie valt ook wel weer wat voor te zeggen, maakt het makkelijker om het door mensen die met andere talen werken te laten onderhouden.
Tenzij je het zelf in elkaar gaat kitten (wat flink werk is en net zoveel tool specifieke kennis vergt), zal je altijd aan een pipeline platform gebonden zijn met elk z’n eigen kennis.
Pak Gitea en Jenkins en je hebt Github voor een groot deel niet meer nodig. Hosting blijft over, dat is tricky.
Dan ben je een Gitea/Jenkins expert, wat is daar het voordeel van ten opzichte van een GitHub Actions expert zijn?
Het leven is te kort om te verspillen aan Jenkins.
hehe, ik herken je gevoel wel enigzins ;) bij het doen van migraties naar GitHub. (Ja ik ben biased, we geven ook die GitHub trainingen)
Jenkins gebruiken als klok/log verzamelen. Geen diepere Jenkins kennis nodig. Die tools zijn zo vluchtig als water, dus tegen de tijd dat je expert bent is er een nieuwe tool hip.
De algemene concepten zijn overal dezelfde, maar op een gegeven moment kies je gewoon wat best bij je past. na verloop van tijd komt er een platform bij en valt er eentje af... zie ook (OO) programmeertalen..
Het model van Github is dat private repositories, enterprise pakketten en vooral Github Action runners geld kosten (en die laatste per minuut)
Ik gebruik zelf een selfhosted instance van Gitea voor actions, die zijn actions heeft gebouwd zodat ze zo veel mogelijk GitHub compatible zijn. Maar je hebt eerlijk well gelijk dat het hier een gevoel dat GitHub(Microsoft) will dat je de GitHub manier gebruikt en je dus locked in dat platform komt.
Hoezo zou het dat worden? Niet dat ik pro ben, maar ik heb er wat code op staan. Dat zijn alleen maar tekstbestanden. Ik heb nog niet gemerkt dat er bepaalde 'verplichte trends' zijn, of hoe je het wil noemen. Lijkt me best lastig om iets te verzinnen wat uitsluitend werkt met Github. Of je moet iets maken wat automatisch code ophaalt. Dan zit je aan de url's vast die je programma geeft.
Het woord "expert" wordt tegenwoordig zoveel, te pas en te onpas, gebruikt dat het zijn betekenis begint te verliezen.
Vroeguh, kreeg je dat soort stempels pas na een 10.000 uur werken. Dan had je voldoende ellende meegemaakt en genoeg shit mogen opruimen, om je expert of senior te mogen noemen.

In Japan duurt het wat langer, tegen het einde van je carrière _/-\o_
Dat is omdat vroeger de vendors nog niet alle vendors hadden ingezien dat trainings/certificeringen makkelijk verdienen is.
Helaas is het niet anders, "expert" en "heeft certificaat" zijn verschillende dingen.
Maar hier wordt toch juist mee bewezen dat iemand de kennis daadwerkelijk heeft? Dan is dit toch goed nieuws in dat opzicht?
Dat die persoon de theorie kent, toepassen in de praktijk is een ander verhaal.

Net zoals met cursussen zijn er vaak uitgestippelde paden, de kunst is de theorie omzetten naar praktijk oplossingen en ik vind dat daar goede documentatie vaak veel belangrijker is.
Het voelt als een MS-Word expert.... geef zo iemand LibreOffice en die is compleet de weg kwijt en gaat lopen roepen dat alles slecht is omdat het geen wordt is. Ik heb liever iemand die snapt wat een tool conceptueel doet en me dat uit kan leggen. De rest google/chatgpt je bij elkaar want dat zijn niet essentiele skills. De YAML syntax van Github kan me gestolen worden als je me niet kunt vertellen wat de impact van een parallele build is op de ordening van je targets in je build systeem.
Iemand die net een master diploma heeft behaald is ook geen expert.
De originele connotatie is iemand die het spelletje heeft uitgespeeld.

Het gebruik van incorrecte terminologie geeft mensen een onjuiste emotionele connotatie en daarmee een verkeerd beeld van de werkelijkheid.
Vind de waarde van die multiple choice examens bedenkelijk. Vind echte lab examens zoals die van RedHat en Linux Foundation (cka,ckad,cks) echt meerwaarde hebben, laat maar zien dat je het kan.
Linkedin doet het ook. Het is een leuke gimmick. Er zullen vast mensen zijn die er waarde aan hechten straks. En natuurlijk is dit nog maar het begin.
Helemaal mee eens. Maar het hangt er ook wel echt vanaf hoe je studeert. Je kunt multiple choice vragen uit je hoofd gaan leren of daadwerkelijk aan de slag met de materie en er zo veel mogelijk uit proberen te halen. Ik doe het laatste.
Het resultaat voor diegene die je certificaat uiteindelijk ziet is hetzelfde: ja, die heeft een multiple-gok examen gehaald ;-)
Een ccna examen is ook multiple choice, ik wil je dat wel eens op de gok zien doen 😉
Tegenwoordig heb je experts in alles ... Maar veel van die "expert" certificate zijn oftewel ridicuul oftewel krijg je het "zomaar". Ridicuul in de zin van ... om ergens mee te kunnen werken moet je nu niet echt functie x kennen die je in 5 jaar 1x gebruikt om het zo te zeggen. En "zomaar" omdat sommige echt gewoon met common sense te doen zijn.

Maar uit de praktijk weet ik dat velen met zo een hele hoop certificaten met moeite iets gedaan krijgen. Ze hebben dat gehaald ja ... maar in de praktijk bakken ze er niks van. En dat is het spijtige van de zaak

Net effe de dingen bekeken van "foundations", dat is nou ook niet bepaald wat ik noem ik kan werken met gihub ... Markdown ? Sorry maar dat hoort niet thuis in een certificaat van Github. Github administratie ? Zo moeilijk is dat nu toch echt niet hoor.

Dat ze nu eerst eens een deftige factuur voorzien, zonder dat je daar een organisatie moet aanhangen. Er zijn genoeg eenmanszaken. En nee gewoon die extra optie BTW nummer toevoegen is niet genoeg.

[Reactie gewijzigd door cricque op 22 juli 2024 23:21]

Soms loop je tegen git hell aan, bijv multiple ppl op 1 story, zelfde methods screens. Momenteel creeeren wij een branch off develop/main en idereen werkt uit die branch, het werkt beter dan iedereen creating branch off develop en dan merge back maar het is nog steeds een royal pain. Lijkt me handig om een expert te hebben die de beste strategie voorsteld want nu zijn we een beetje aan het expirementeren wat het best werk.
waarschijnlijk is je branching niet je probleem maar de modulairteit van je app.

Wij werken prima met main + (short lived) feature branches, met 30+ developers & meer dan 25pr's gemerged per dag, zonder echt merge hell te krijgen.

Ik zou eerder kijken: wat zijn je hotspots, en hebben die uberhaubt iets met elkaar te maken, hoort alles in die file / module thuis?


Deze certs gaan overigens niet echt over git gebruik zo te zien, maar meer over github specifieke rand tooling: ci/cd (actions) + security scans (advanced sec) + github enterprise (admin).

[Reactie gewijzigd door Squixx op 22 juli 2024 23:21]

en dan heb je met ci/cd en security gelijk te maken met externe partijen die een beetje kijken of je dat leuk doet. Dan kan een certificering geen kwaad.
Lijkt me een ouderwetse manier van trunk based development wat jullie aan het doen zijn.
je branching strategy hangt ook heel erg samen met je deployment en delivery strategy maar ook je ontwikkelsnelheid en story grootte. Werk je als team een story of drie per dag er door dan kan een github flow wel interessant zijn. Zit je nog met een sprint release waarin alle opgeleverde stories in 1 keer worden opgeleverd dan is een gitflow misschien handiger.

Hier heb je alleen niet echt een certificaat voor nodig want ik denk niet dat branching strategieën hierin worden behandeld. Iemand met 5+ jaar DevOps ervaring binnen verschillende organisaties en teams vinden is denk ik waardevoller voor je dan.
En dan krijg je een embleempje op je profiel erbij of zo?

Was op zich wel te verwachten dat ze er een verdienmodel aan gingen hangen. Denk dat dit beter is dan gewoon lukraak wat reclame of andere stuff. Ik denk dat als ze zelf merchandise zouden verkopen, het ook wel aardig zal lopen. Ik snap dit soort diensten ook nooit zo. Er zijn gewoon genoeg die-hards die de buidel trekken en ondertussen zijn je investeerders (of eigenaars) een stuk blijer met hun investering.
Is github actions al op het niveau van de gitlab ci/cd straat? Laatste keer dat ik mij erover in had gelezen liep het nog wat achter.
Dit is weer het zoveelste certificaat wat je kan halen. Wordt er een beetje moe van.
Waarschijnlijk met 10% inhoud en 60% informatie die je uit de handleiding kan halen en daarom nutteloos is omdat deze doorlopend wordt aangepast met updates tussen verschillende versies. De resterende 30% is informatie waar je uit kan komen door te gokken.

Klinkt zoals de bekende Azure-certificaten :Y

Waarom zou ik betalen om mijn hoofd te vullen met vluchtige informatie die ChatGPT ook kan oplepelen zodra ik het nodig heb?

Het is een mooi marketingmodel, maar dit is net zo nuttig als de webpagina die door Google Search als belangrijker wordt gezien omdat het mij een verhaal vertelt over het verleden van de schrijver die een oma in een ver land heeft en werd getriggerd om recepten te bedenken voor lekkere koekjes terwijl ik alleen maar wilde weten hoe je zandkoekjes kan maken met zo weinig mogelijk stappen en omwegen.

[Reactie gewijzigd door Stukfruit op 22 juli 2024 23:21]

Leuk, certificaatjes en trainingen is altijd een goed verdienmodel. Veel Consultancy clubs zweren bij die stikkers om hun mensen naar voren te schuiven…
Als je pas aan je carrière begint of je wisselt een beetje van pad zijn een aantal stikkers op je CV ook nooit verkeerd om door een begin ronde (de recruiterbot die LinkedIn uitleest) te komen of net een streepje extra te krijgen…
Iemand op z’n blauwe ogen aannemen? of 1 met een paar stikkers? Geeft je wel een voorsprong bij de 1e schifting.

(Jaarlijks) hercertificeren is redelijk bedenkelijk want dat voegt vrij weinig toe over het algemeen; praktijkervaring is dan vele malen waardevoller.

Deze zijn misschien zelfs wel leuk voor erbij, toch budget genoeg :)
idd, een leuk verdien model, om weer wat omzet te boeken op iets wat min of meer open source was. De certificaten worden bij deze een must have voor iedere code klopper op github. Lijkt mij geen brug te ver, en wellicht goed om een uniforme knowledge base te hebben. Jammere is dat het een potentieele filter kan zijn voor al die ervaring die geen github badges bij de scouts hebben gehaald, maar wel verdomd goed zijn. Met die realiteit moeten we allemaal wat langere leven dan vandaag. Onder het mom van hoe kan ik geld verdienen met die vervloekte ongrijpbare software mensen die mijn wereld continue veranderen?
GitHub heeft, via Microsofts Learn-platform, leermiddelen beschikbaar gesteld voor geïnteresseerden.
8)7

Ik snap dat GitHub van Microsoft is, maar Microsoft Learn (wat ook Microsoft's documentatie website is) is echt bagger. Er komt altijd een klein beetje kots naar boven als ik de website moet gebruiken en weer eens moet opzoeken wat ookalweer het verschil is tussen "Quickstart", "How-to guide", "Tutorial" en "Samples". En dan nog waarom er bij "Concepts" vaak niks nuttigs tussen staat... :?

Op dit item kan niet meer gereageerd worden.