DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Microsoft.EntityFrameworkCore / SQLite downgraden naar 3.1.11 verhelpt het probleem trouwens ook niet.
Edit: ook het project rebuilden doet niks
Een warm welkom in de wereld van .NET
Edit: ook het project rebuilden doet niks
Een warm welkom in de wereld van .NET
Al gezocht op stack overflow en github? Heb nooit met de .net omgeving gewerkt.quote:Op zondag 24 januari 2021 12:51 schreef Scooteraar het volgende:
Ik probeer mezelf te verdiepen in ASP.NET. Ik heb een nieuw project gemaakt op basis van .NET 5.0 en heb Entity Framework + SQLite geïnstalleerd.
Ik heb nu dotnet-ef nodig voor het maken van o.a. de migrations. Ik krijg alleen deze error:
Error NU1202 Package dotnet-ef 3.1.11 is not compatible with netcoreapp3.1 (.NETCoreApp,Version=v3.1). Package dotnet-ef 3.1.11 supports: netcoreapp3.1 (.NETCoreApp,Version=v3.1) / any API C:\Users\Scooteraar\source\repos\DatingApp\API\API.csproj
Ehh wat?
- Ik heb het target framework voor DatingApp.API verlaagd naar .NET 3.1
- Ik heb geprobeerd oudere (3.x) versies te installeren.
Wie is bekend met deze ellende?
I think that it’s extraordinarily important that we in computer science keep fun in computing
For all who deny the struggle, the triumphant overcome
Met zwijgen kruist men de duivel
For all who deny the struggle, the triumphant overcome
Met zwijgen kruist men de duivel
Ik heb wel een beetje rond zitten kijken, maar nog geen oplossing gevonden. Het is ook niet heel belangrijk ofzo hoor, ik wilde gewoon wat experimenteren. Maar frustrerend wel.quote:Op zondag 24 januari 2021 13:12 schreef FlippingCoin het volgende:
[..]
Al gezocht op stack overflow en github? Heb nooit met de .net omgeving gewerkt.
[ Bericht 1% gewijzigd door Scooteraar op 24-01-2021 13:27:35 ]
Als ik dit zo lees lijkt het volgende een mogelijke oplossing te zijn:quote:
Error NU1202 Package dotnet-ef 3.1.11 is not compatible with netcoreapp3.1
dotnet tool install --global dotnet-ef --version 3.0.0
https://github.com/dotnet(...)suecomment-556092925
Ik weet niet of je met je 3.x probeersels ook 3.0.0 hebt geprobeerd
[ Bericht 4% gewijzigd door #ANONIEM op 24-01-2021 14:08:18 ]
dot net framework en dot net core zijn twee verschillende dingen. framework is zeg maar de windows extensie, core is zeg maar de multi-platform versie ervan. asp.net is net framework, aspnetcore is core framework. je dotnet-ef is zo te zien een net core library, maar je bent begonnen met een net framework applicatie. libraries voor net core werken vaak niet voor framework en vice versa. Praktisch alle libraries hebben wel versies compatibel met beide, maar je moet dus goed opletten welke je installeert. Soms zijn de libraries hernoemd waardoor het niet altijd even makkelijk is de compatibel evenknie te vinden, maar met google lukt dat altijd wel.quote:
Ik probeer mezelf te verdiepen in ASP.NET. Ik heb een nieuw project gemaakt op basis van .NET 5.0 en heb Entity Framework + SQLite geïnstalleerd.
Ik heb nu dotnet-ef nodig voor het maken van o.a. de migrations. Ik krijg alleen deze error:
Error NU1202 Package dotnet-ef 3.1.11 is not compatible with netcoreapp3.1 (.NETCoreApp,Version=v3.1). Package dotnet-ef 3.1.11 supports: netcoreapp3.1 (.NETCoreApp,Version=v3.1) / any API C:\Users\Scooteraar\source\repos\DatingApp\API\API.csproj
Ehh wat?
- Ik heb het target framework voor DatingApp.API verlaagd naar .NET 3.1
- Ik heb geprobeerd oudere (3.x) versies te installeren.
Wie is bekend met deze ellende?
https://medium.com/@prita(...)tandard-66fdeb308bf7
Hier iemand veel ervaring met git workflows Ik loop tegen wat issues aan die steeds meer tijd kosten.
I think that it’s extraordinarily important that we in computer science keep fun in computing
For all who deny the struggle, the triumphant overcome
Met zwijgen kruist men de duivel
For all who deny the struggle, the triumphant overcome
Met zwijgen kruist men de duivel
Sowieso zou ik heel erg uitkijken met externe repositories, er word soms veel te makkelijk vanuit gegaan dat het altijd maar beschikbaar en veilig is, letterlijk 1 regeltje in je nuget includes kunnen desastreuze gevolgen hebben.quote:
Sommige bedrijven hebben zelfs een aantal dagen de documentatie offline gehaald voor een BLM statement.
Heb wel flink wat mensen uit o.a. Hong Kong flink pissed gezien daarover.
Maar goed dat zeg ik al veel langer, we zijn véél te afhankelijk van de amerikaanse nukken w.b. software.
🕰️₿🕰️₿🕰️₿🕰️₿🕰️₿🕰️ TikTok next Block
Als je dit soort dingen leuk vind, kijk dan eens naar www.phaser.io zit ook heel veel in qua framework, echt heel tof hoe je bijvoorbeeld met 40 regels een compleet 3d spel kunt makenquote:
[..]
Vandaag rond 11u begonnen en om 16u een korte presentatie over gegeven.
Ja voor chat dingen is het super handig, de tutorial is ook een chat maken.
En ik zag ook dat ze p2p ondersteunen nu maar daar geen tijd voor gehad om naar te kijken.
🕰️₿🕰️₿🕰️₿🕰️₿🕰️₿🕰️ TikTok next Block
Wij gebruiken nu de volgende branch flow:quote:
master -> feature -> test -> acceptance -> release
waarbij een feature van en naar master gaat, en vervolgens de features die goed bevonden zijn naar test dan wel acceptance of release cherry picked worden. Alleen dit geeft super veel merge conflicts omdat we een app van scratch maken en dus niet uit elkaars vaarwater kunnen blijven. Per sprint van 2 weken meerdere uren die aan merge conflicts + controleren of er niks mis is gegaan besteed worden.
Nu ben ik wat aan het kijken naar alternatieven maar ik vroeg mij af of hier iemand nog suggesties heeft.
I think that it’s extraordinarily important that we in computer science keep fun in computing
For all who deny the struggle, the triumphant overcome
Met zwijgen kruist men de duivel
For all who deny the struggle, the triumphant overcome
Met zwijgen kruist men de duivel
Ja ik vond het ook echt bizar eigenlijk, een statement maken is een, maar er zijn wel gewoon bedrijven afhankelijk van die software... Maar goed, ken je afhankelijkheden inderdaad.quote:Op zondag 24 januari 2021 20:21 schreef raptorix het volgende:
[..]
Sowieso zou ik heel erg uitkijken met externe repositories, er word soms veel te makkelijk vanuit gegaan dat het altijd maar beschikbaar en veilig is, letterlijk 1 regeltje in je nuget includes kunnen desastreuze gevolgen hebben.
I think that it’s extraordinarily important that we in computer science keep fun in computing
For all who deny the struggle, the triumphant overcome
Met zwijgen kruist men de duivel
For all who deny the struggle, the triumphant overcome
Met zwijgen kruist men de duivel
Het meest handige is al je gebruik maakt van GitFlow, is over het algemeen erg handig voor sprints van 2 weken, in het kort:quote:
[..]
Wij gebruiken nu de volgende branch flow:
master -> feature -> test -> acceptance -> release
waarbij een feature van en naar master gaat, en vervolgens de features die goed bevonden zijn naar test dan wel acceptance of release cherry picked worden. Alleen dit geeft super veel merge conflicts omdat we een app van scratch maken en dus niet uit elkaars vaarwater kunnen blijven. Per sprint van 2 weken meerdere uren die aan merge conflicts + controleren of er niks mis is gegaan besteed worden.
Nu ben ik wat aan het kijken naar alternatieven maar ik vroeg mij af of hier iemand nog suggesties heeft.
-Iedereen werkt op Development
-Een uitzondering zijn feature branches, mag altijd, maar pull requests gaan altijd naar terug naar de development branch
-Wanneer je sprint ten einde loopt, dan word er een release branch gemaaakt van development
-Als uit testen bijvoorbeeld een bug word gevonden, dan word deze op de release branch gefixed (eventueel via een feature branch)
-Wanneer je klaar bent met testen en fixen, dan word de release branch terug gemerged naar Master en Dev, de release branch kun je sluiten, en een final build maak je van Master (dit zou in principe gelijk moeten zijn als je laatste release Branch!!!!
-Blijkt er na de release een probleem, dan maak je van de Master weer een Hotfix branch, en voer je het zelfde trucje uit, de fix merge je uiteraard ook terug naar development, dat wil je niet kwijt raken!
Kortom:
-Het grote voordeel is dat je team altijd op development kan blijven werken zonder dat er per ongeluk iets mee gereleased kan worden
-De release branch die je getest hebt, gaat naar productie, dus in principe is je laatste test versie altijd gelijk aan wat je naar productie release
-Je kunt ten alle tijden een hotfix maken op de Master branch zonder dat je bang hoeft te zijn zaken mee te releasen!!!!!
Belangrijk is om dus er voor te zorgen dat er branch policies op Master zitten, deze mogen alleen gepulled worden van een release of een hotfix branch!
https://nvie.com/posts/a-successful-git-branching-model/
Als tip, creeer met je team gewoon eens een sample projectje en ga het oefenen, je zult zien dat het erg overzichtelijk werkt
Nog een kleine tip, en dat is meer GIT algemeen, hou je pull requests klein, bij voorkeur gerelateerd aan 1 isssue, dat houd het overzichelijk en maakt de kans op merge problemen een stuk kleiner.
🕰️₿🕰️₿🕰️₿🕰️₿🕰️₿🕰️ TikTok next Block
en (hopelijk overbodig) werk zoveel mogelijk via interfaces , abstracts of header files of whatever je taal en je project ondersteunt, dat minimaliseert merge problemen als er iets aan de implementatiekant veranderd.quote:
[..]
Het meest handige is al je gebruik maakt van GitFlow, is over het algemeen erg handig voor sprints van 2 weken, in het kort:
-Iedereen werkt op Development
-Een uitzondering zijn feature branches, mag altijd, maar pull requests gaan altijd naar terug naar de development branch
-Wanneer je sprint ten einde loopt, dan word er een release branch gemaaakt van development
-Als uit testen bijvoorbeeld een bug word gevonden, dan word deze op de release branch gefixed (eventueel via een feature branch)
-Wanneer je klaar bent met testen en fixen, dan word de release branch terug gemerged naar Master en Dev, de release branch kun je sluiten, en een final build maak je van Master (dit zou in principe gelijk moeten zijn als je laatste release Branch!!!!
-Blijkt er na de release een probleem, dan maak je van de Master weer een Hotfix branch, en voer je het zelfde trucje uit, de fix merge je uiteraard ook terug naar development, dat wil je niet kwijt raken!
Kortom:
-Het grote voordeel is dat je team altijd op development kan blijven werken zonder dat er per ongeluk iets mee gereleased kan worden
-De release branch die je getest hebt, gaat naar productie, dus in principe is je laatste test versie altijd gelijk aan wat je naar productie release
-Je kunt ten alle tijden een hotfix maken op de Master branch zonder dat je bang hoeft te zijn zaken mee te releasen!!!!!
Belangrijk is om dus er voor te zorgen dat er branch policies op Master zitten, deze mogen alleen gepulled worden van een release of een hotfix branch!
https://nvie.com/posts/a-successful-git-branching-model/
Als tip, creeer met je team gewoon eens een sample projectje en ga het oefenen, je zult zien dat het erg overzichtelijk werkt
Nog een kleine tip, en dat is meer GIT algemeen, hou je pull requests klein, bij voorkeur gerelateerd aan 1 isssue, dat houd het overzichelijk en maakt de kans op merge problemen een stuk kleiner.
quote:
[..]
Het meest handige is al je gebruik maakt van GitFlow, is over het algemeen erg handig voor sprints van 2 weken, in het kort:
-Iedereen werkt op Development
-Een uitzondering zijn feature branches, mag altijd, maar pull requests gaan altijd naar terug naar de development branch
-Wanneer je sprint ten einde loopt, dan word er een release branch gemaaakt van development
-Als uit testen bijvoorbeeld een bug word gevonden, dan word deze op de release branch gefixed (eventueel via een feature branch)
-Wanneer je klaar bent met testen en fixen, dan word de release branch terug gemerged naar Master en Dev, de release branch kun je sluiten, en een final build maak je van Master (dit zou in principe gelijk moeten zijn als je laatste release Branch!!!!
-Blijkt er na de release een probleem, dan maak je van de Master weer een Hotfix branch, en voer je het zelfde trucje uit, de fix merge je uiteraard ook terug naar development, dat wil je niet kwijt raken!
Kortom:
-Het grote voordeel is dat je team altijd op development kan blijven werken zonder dat er per ongeluk iets mee gereleased kan worden
-De release branch die je getest hebt, gaat naar productie, dus in principe is je laatste test versie altijd gelijk aan wat je naar productie release
-Je kunt ten alle tijden een hotfix maken op de Master branch zonder dat je bang hoeft te zijn zaken mee te releasen!!!!!
Belangrijk is om dus er voor te zorgen dat er branch policies op Master zitten, deze mogen alleen gepulled worden van een release of een hotfix branch!
https://nvie.com/posts/a-successful-git-branching-model/
Als tip, creeer met je team gewoon eens een sample projectje en ga het oefenen, je zult zien dat het erg overzichtelijk werkt
Nog een kleine tip, en dat is meer GIT algemeen, hou je pull requests klein, bij voorkeur gerelateerd aan 1 isssue, dat houd het overzichelijk en maakt de kans op merge problemen een stuk kleiner.
Ik was nog vergeten te reageren sorry, ik ga van het weekend weer verder kijken; ik heb het er op mijn werk over gehad en ik ga een klein onderzoekje doen. Wij gebruiken nu gitflow maar ik stoor mij toch aan de vele conflicts, vooral omdat dit mergen te vaak bugs (her)introduceert.quote:
[..]
en (hopelijk overbodig) werk zoveel mogelijk via interfaces , abstracts of header files of whatever je taal en je project ondersteunt, dat minimaliseert merge problemen als er iets aan de implementatiekant veranderd.
I think that it’s extraordinarily important that we in computer science keep fun in computing
For all who deny the struggle, the triumphant overcome
Met zwijgen kruist men de duivel
For all who deny the struggle, the triumphant overcome
Met zwijgen kruist men de duivel
Geen probleem, kan je wel zeggen dat een andere GIT strategie je merge problemen niet gaat oplossen, ik zou daarvoor eerder kijken of de commits kleiner kunnen en of je eventueel gebruik kunt maken van meer atomaire bestanden (bijvoorbeeld via includes of subclasses in losse files).quote:
[..]
[..]
Ik was nog vergeten te reageren sorry, ik ga van het weekend weer verder kijken; ik heb het er op mijn werk over gehad en ik ga een klein onderzoekje doen. Wij gebruiken nu gitflow maar ik stoor mij toch aan de vele conflicts, vooral omdat dit mergen te vaak bugs (her)introduceert.
Ik weet niet hoe groot je merge problemen zijn, maar ik had altijd tyfus hekel aan die editors waar je dat moet oplossen, meestal stelde ik gewoon mijn werk even veilig en deed even al mijn changes opnieuw op de laatste versie
🕰️₿🕰️₿🕰️₿🕰️₿🕰️₿🕰️ TikTok next Block
Ik kwam in een talk wel de volgende quote tegen:quote:
[..]
Geen probleem, kan je wel zeggen dat een andere GIT strategie je merge problemen niet gaat oplossen, ik zou daarvoor eerder kijken of de commits kleiner kunnen en of je eventueel gebruik kunt maken van meer atomaire bestanden (bijvoorbeeld via includes of subclasses in losse files).
Ik weet niet hoe groot je merge problemen zijn, maar ik had altijd tyfus hekel aan die editors waar je dat moet oplossen, meestal stelde ik gewoon mijn werk even veilig en deed even al mijn changes opnieuw op de laatste versie
En dat herken ik wel erg terug bij ons.quote:branching is an integration credit-card, you to pay that debt of sometime
En omdat we 3 verschillende testomgevingen hebben (met drie verschillende checks om weer een omgeving verder te geraken), hebben we ook drie keer het probleem met cherry picken ten zij alle tickets goedgekeurd worden wat natuurlijk bijna nooit zo is. Waardoor we effectief het probleem met een factor drie vergroten misschien moet daar gewoon kritisch naar gekeken worden.
Ik ga er nog even over nadenken iig.
I think that it’s extraordinarily important that we in computer science keep fun in computing
For all who deny the struggle, the triumphant overcome
Met zwijgen kruist men de duivel
For all who deny the struggle, the triumphant overcome
Met zwijgen kruist men de duivel
Het hele concept van Gitflow is dat je juist niet aan Cherrypicking doet, dan ga je inderdaad de problemen op je nek halen, Cherrypicking doe je binnen GitFlow hoogstens om bijvoorbeeld een hotfix te doen, of wellicht een fix op een release branch.
Tenzij ik jullie Git model niet helemaal goed begrijp waarbij je dus sprake hebt van een model waarbij je bepaalde delen van je repo's shared met andere projecten, dit laatste maakt het wel complexer, ik heb een aantal keren met dat soort systemen gewerkt en het vergt een behoorlijk goede architectuur, bij een grote reisorganisatie deded we dat door nuget packages te maken die als dependencies op andere projecten werden geladen, in de praktijk klinkt dat erg mooi, maar als je abstractie laag niet goed geregeld is, is het een recept voor hoofdpijn (zeker op projecten die niet elke spring worden geupdate
)
Tenzij ik jullie Git model niet helemaal goed begrijp waarbij je dus sprake hebt van een model waarbij je bepaalde delen van je repo's shared met andere projecten, dit laatste maakt het wel complexer, ik heb een aantal keren met dat soort systemen gewerkt en het vergt een behoorlijk goede architectuur, bij een grote reisorganisatie deded we dat door nuget packages te maken die als dependencies op andere projecten werden geladen, in de praktijk klinkt dat erg mooi, maar als je abstractie laag niet goed geregeld is, is het een recept voor hoofdpijn (zeker op projecten die niet elke spring worden geupdate
)
🕰️₿🕰️₿🕰️₿🕰️₿🕰️₿🕰️ TikTok next Block
Hm ja maar dat sluit niet aan bij het agile idee, iig niet bij ons, we kunnen niet zeggen oke deze tickets zijn niet af we wachten met een deploy tot de laatste feedback of wijzigingen ook verwerkt zijn; en daar wringt de schoen ook denk ik.quote:
Het hele concept van Gitflow is dat je juist niet aan Cherrypicking doet, dan ga je inderdaad de problemen op je nek halen, Cherrypicking doe je binnen GitFlow hoogstens om bijvoorbeeld een hotfix te doen, of wellicht een fix op een release branch.
Tenzij ik jullie Git model niet helemaal goed begrijp waarbij je dus sprake hebt van een model waarbij je bepaalde delen van je repo's shared met andere projecten, dit laatste maakt het wel complexer, ik heb een aantal keren met dat soort systemen gewerkt en het vergt een behoorlijk goede architectuur, bij een grote reisorganisatie deded we dat door nuget packages te maken die als dependencies op andere projecten werden geladen, in de praktijk klinkt dat erg mooi, maar als je abstractie laag niet goed geregeld is, is het een recept voor hoofdpijn (zeker op projecten die niet elke spring worden geupdate
I think that it’s extraordinarily important that we in computer science keep fun in computing
For all who deny the struggle, the triumphant overcome
Met zwijgen kruist men de duivel
For all who deny the struggle, the triumphant overcome
Met zwijgen kruist men de duivel
Ja het hele idee van CI/CD is dat je ten alle tijden kunt deployen, alleen komt dat natuurlijk wel met een prijsquote:
[..]
Hm ja maar dat sluit niet aan bij het agile idee, iig niet bij ons, we kunnen niet zeggen oke deze tickets zijn niet af we wachten met een deploy tot de laatste feedback of wijzigingen ook verwerkt zijn; en daar wringt de schoen ook denk ik.
Kijk ik kan prima een CI/CD deployment maken die vrolijk alles doorzet, maar daar zit de pijn natuurlijk niet.
Mijn ervaring is dat als je dit wel wilt, en je software dit eigenlijk niet toelaat je het beste kunt investeren in goede integratie checks (dus geen unit tests), het voordeel van integratie tests is namelijk dat ze relatief snel te bouwen zijn en ook waarde blijven houden voor toekomstige refactoring. Uiteraard is het wel sterk afhankelijk van je software of dit mogelijk is.
🕰️₿🕰️₿🕰️₿🕰️₿🕰️₿🕰️ TikTok next Block
Ik ben de laatste 1,5 week 's avonds en in het weekend vooral bezig geweest met het 3e 'blokje', het informationcentre. Werkt grotendeels, CRUD en extra instellingen daarvoor ook. Nu tot het weekend bezig om alle code weer te optimaliseren, uniformeren.
Verder ook bezig mijn hele server opnieuw in te richten/beveiligen en daarvan een handleiding te maken.
Verder ook bezig mijn hele server opnieuw in te richten/beveiligen en daarvan een handleiding te maken.
8 dagen later, server redelijk beveiligd naar mijn maatstaven
@investeerdertje, dank je nog (je PM van maanden geleden), wat je meldde was nuttig en heb ik gebruik van gemaakt. Nu pas echt iets mee gedaan omdat ik eerst vooral bezig was met de website zelf.
Nou ja in het kort:
Server: SSH met keys werkt, ufw firewall, iptables, fail2ban, root login disabled. Ik ga fail2ban nog extra testen maar voor nu sowieso wel veilig genoeg (kon niet inloggen zonder de gebruikersnaam te weten en die is nogal ingewikkeld)
Informationcentre blokje is af, search heb ik uitgebreid, heel veel codes extra in functies geplaatst, dashboard mee begonnen. Komend weekend ga ik denk ik weer een youtube clipje maken over de vorderingen.
Tussentijds een programmeursgrapje
@investeerdertje, dank je nog (je PM van maanden geleden), wat je meldde was nuttig en heb ik gebruik van gemaakt. Nu pas echt iets mee gedaan omdat ik eerst vooral bezig was met de website zelf.
Nou ja in het kort:
Server: SSH met keys werkt, ufw firewall, iptables, fail2ban, root login disabled. Ik ga fail2ban nog extra testen maar voor nu sowieso wel veilig genoeg (kon niet inloggen zonder de gebruikersnaam te weten en die is nogal ingewikkeld)
Informationcentre blokje is af, search heb ik uitgebreid, heel veel codes extra in functies geplaatst, dashboard mee begonnen. Komend weekend ga ik denk ik weer een youtube clipje maken over de vorderingen.
Tussentijds een programmeursgrapje
Lekker bezig weer @phoenyx , wanneer ben je van plan om je applicatie te latent testen door anderen?
I think that it’s extraordinarily important that we in computer science keep fun in computing
For all who deny the struggle, the triumphant overcome
Met zwijgen kruist men de duivel
For all who deny the struggle, the triumphant overcome
Met zwijgen kruist men de duivel
Ik ben bezig geweest met drie dingen buiten de normale werkzaamheden:
Voor de merge conflicts heb ik nu wat dingen besproken, en besloten het breder te trekken dan de branchin strategy en dat te onderzoeken: iig hier is de branching strategy zoals die nu is:
Voor de merge conflicts heb ik nu wat dingen besproken, en besloten het breder te trekken dan de branchin strategy en dat te onderzoeken: iig hier is de branching strategy zoals die nu is:
SPOILEROm spoilers te kunnen lezen moet je zijn ingelogd. Je moet je daarvoor eerst gratis Registreren. Ook kun je spoilers niet lezen als je een ban hebt.Daarnaast bezig met de course over algoritmes en datastructuren maar niet heel veel tijd voor gehad, en ik ben bezig met een kleine tool in Java om meerdere dingen te copy pasten; en deze maak ik met RxJava, tijd niet meer met Java gewerkt dus het gaat niet heel soepel maar het is wel leuk om er weer eens mee bezig te zijnl.
I think that it’s extraordinarily important that we in computer science keep fun in computing
For all who deny the struggle, the triumphant overcome
Met zwijgen kruist men de duivel
P.s. Gaan er hier mensen wel eens naar meetups? Iemand vroeg mij laatst eens naar een RxJava meetup te komen (vandaar dat ik daar even mee aan het oefenen ben) maar dit klinkt wel leuk al is het nu digitaal door corona.
I think that it’s extraordinarily important that we in computer science keep fun in computing
For all who deny the struggle, the triumphant overcome
Met zwijgen kruist men de duivel
For all who deny the struggle, the triumphant overcome
Met zwijgen kruist men de duivel
quote:
Ik ben bezig geweest met drie dingen buiten de normale werkzaamheden:
Voor de merge conflicts heb ik nu wat dingen besproken, en besloten het breder te trekken dan de branchin strategy en dat te onderzoeken: iig hier is de branching strategy zoals die nu is:SPOILEROm spoilers te kunnen lezen moet je zijn ingelogd. Je moet je daarvoor eerst gratis Registreren. Ook kun je spoilers niet lezen als je een ban hebt.Daarnaast bezig met de course over algoritmes en datastructuren maar niet heel veel tijd voor gehad, en ik ben bezig met een kleine tool in Java om meerdere dingen te copy pasten; en deze maak ik met RxJava, tijd niet meer met Java gewerkt dus het gaat niet heel soepel maar het is wel leuk om er weer eens mee bezig te zijnl.
| Forum Opties | |
|---|---|
| Forumhop: | |
| Hop naar: | |