De Devschuur Coffee Corner - Iteratie ⓫

[Firesphere]

Skyaero schreef op donderdag 12 januari 2017 @ 08:39:
[...]


zoiets als "Hier staat het koffieapparaat. Firesphere drinkt zwart, de baas extra sterk met melk en twee klontjes suiker en voor Frans rooibosthee"

Meer als in "Dit is hoe je je commits squashed. En zo rebase je. En zo fix je conflicts. En dit is de coding standard. En zo zet je commit-hooks. En dit is wat een goede PR is. En wees niet bang om keihard te zijn in je PR comments. En zo zet je een Vagrant of Docker klaar. En er zijn ergere dingen dan tijdens een PR iets missen" etc.

Also, Sam maakt zijn eigen koffie, dus die redt zich wel

[ Voor 4% gewijzigd door Firesphere op 12-01-2017 08:57 ]

[Jan_V]

Firesphere schreef op donderdag 12 januari 2017 @ 08:56:
[...]

Meer als in "Dit is hoe je je commits squashed. En zo rebase je. En zo fix je conflicts. En dit is de coding standard. En zo zet je commit-hooks. En dit is wat een goede PR is. En wees niet bang om keihard te zijn in je PR comments. En zo zet je een Vagrant of Docker klaar. En er zijn ergere dingen dan tijdens een PR iets missen" etc.

Also, Sam maakt zijn eigen koffie, dus die redt zich wel

Wordt er veel gesquashed en rebased in de Git teams hier?
Heb er zelf een paar keer naar gekeken binnen teams waar we net met Git begonnen. Het lijkt alsof je door het squashen en rebasen heel veel commit informatie verliest en ook de reden waarom bepaalde acties zijn doorgevoerd.

Wellicht dat het gebruikt zou moeten worden om van 400 kleine commits van je eigen feature branches nu 10 ietwat grotere commits te maken en daar een PR van te maken. Zo heb ik het squashen in ieder geval zelf toegepast. Rebasen heb ik (nog niet) een use-case voor gehad (denk ik).
Ben wel benieuwd hoe de andere teams dat hier doen.

[Firesphere]

Jan_V schreef op donderdag 12 januari 2017 @ 09:19:
[...]

Wordt er veel gesquashed en rebased in de Git teams hier?
Heb er zelf een paar keer naar gekeken binnen teams waar we net met Git begonnen. Het lijkt alsof je door het squashen en rebasen heel veel commit informatie verliest en ook de reden waarom bepaalde acties zijn doorgevoerd.

Dan squash je verkeerd. Een interactive squash, geeft je de optie om een nieuwe commit message te schrijven.

Wellicht dat het gebruikt zou moeten worden om van 400 kleine commits van je eigen feature branches nu 10 ietwat grotere commits te maken en daar een PR van te maken. Zo heb ik het squashen in ieder geval zelf toegepast. Rebasen heb ik (nog niet) een use-case voor gehad (denk ik).
Ben wel benieuwd hoe de andere teams dat hier doen.

Squashen naar 1 commit is absoluut de moeite waard, maar zoals hier boven, je moet er voor zorgen dat je CM wel de juiste informatie bevat.

Verder, als je commit meerdere regels aan informatie nodig heeft, is dat een indicatie dat de issue had moeten worden opgesplitst in meerdere aparte issues.

[Woy]

Jan_V schreef op donderdag 12 januari 2017 @ 09:19:
[...]
Wellicht dat het gebruikt zou moeten worden om van 400 kleine commits van je eigen feature branches nu 10 ietwat grotere commits te maken en daar een PR van te maken. Zo heb ik het squashen in ieder geval zelf toegepast. Rebasen heb ik (nog niet) een use-case voor gehad (denk ik).
Ben wel benieuwd hoe de andere teams dat hier doen.

Dat is nogal afhankelijk van of je een merge of rebase strategie hebt: https://www.atlassian.com/git/tutorials/merging-vs-rebasing/

Maar sowieso is squashen wel fijn, want zeker met git commit ik gewoon alles wat ik gedaan heb, en voordat ik het push naar public squash ik het even zodat de history lekker schoon blijft. ( Meestal 1 commit per issue/task )

[ Voor 16% gewijzigd door Woy op 12-01-2017 09:24 ]

[gekkie]

Skyaero schreef op donderdag 12 januari 2017 @ 08:39:
[...]
Je leert zo nog eens wat vlaams in de Devschuur

Zo leer ik ook nog weer eens wat (had geen idee dat het vlaams was )

[Jan_V]

Woy schreef op donderdag 12 januari 2017 @ 09:22:
[...]

Dat is nogal afhankelijk van of je een merge of rebase strategie hebt: https://www.atlassian.com/git/tutorials/merging-vs-rebasing/

Maar sowieso is squashen wel fijn, want zeker met git commit ik gewoon alles wat ik gedaan heb, en voordat ik het push naar public squash ik het even zodat de history lekker schoon blijft. ( Meestal 1 commit per issue/task )

Duidelijk artikel, maar daar schrijft men volgens mij ook dat `rebase` eigenlijk alleen bij je eigen branches toegepast kan/zou moeten worden. Zodra de branch wordt gedeeld met meerdere mensen is het verstandiger om geen `rebase` te doen (volgens de 'Golden rule' in het artikel).

[Sardaukar]

Jan_V schreef op donderdag 12 januari 2017 @ 09:19:
[...]

Wordt er veel gesquashed en rebased in de Git teams hier?

Ik werk veel met squashen en rebasen. Al was het maar voor een PR waarbij ik (al experimenterend) een aantal commits heb gemaakt die ik later wil squashen/interactief rebasen naar 1 commit.

En standaard rebase ik feature-branches ten opzichte van de branch waar ze naar toe moeten.

[Firesphere]

git rebase -i HEAD~{commit-count}
Zo ideaal. Je krijgt dan de optie om de commits te squashen, en daarna de commit message aan te passen.

Einde gedoe, je kan alles beschrijven in je CM, GPF er achteraan omdat je moet forcen (dat is wel een kleine downside, maar goed)

Rebase na een squash is ook simpel, omdat je maar 1 commit hebt, dus de replay levert niet eindeloos veel conflicts op.

Als je't goed doet, is squash-rebase-PR zo veel fijner voor iedereen in't team, dan dontgiveafuck-merge-successermee

[CodeCaster]

Ik snap dat je het kunt counteren met "dan is de rest van je proces gaar", maar ik ben faliekant tegen squashen en rebasen.

Bij het implementeren van een feature refactor je bestaande code en/of pas je publieke interfaces aan van services die de functionaliteit leveren voor jouw feature. Deze zaken moeten als losstaande commit kunnen worden bekeken en gemerged, en niet gesquasht en als één geheel gezien.

Ja, als je dat nodig hebt, is je proces gaar. Dat weet ik. Idealiter zou je dan je ticket opsplitsen in twee aparte tickets: deel één om de servicelaag uit te breiden, en deel twee om de nieuwe functionaliteit daarop te bouwen. Cultuur verander je echter maar langzaam.

Hetzelfde geldt voor rebasen. Als er na het finishen van een feature weer eens iets omvalt door een slecht geteste nieuwe feature, wil je niet dat de geschiedenis van je project lineair is. Je wil de commit óp die feature branch zien die de boel gesloopt heeft.

Sowieso haat ik commits die meer dan een handvol bestanden en/of regels raken, maar aan de andere kant heb ik ook een hekel aan opvolgende commits die hetzelfde stuk code raken door voortschrijdend inzicht tijdens het implementeren. Dát soort commits mogen gesquashed worden.

---

En ik snap HATEOAS/HAL nog steeds niet (https://github.com/mikeke...ster/hal_specification.md, https://tools.ietf.org/html/draft-kelly-json-hal-08, https://spring.io/understanding/HATEOAS, https://martinfowler.com/...hardsonMaturityModel.html).

Of althans, niet voor wie het bedoeld is. Het lijkt vooralsnog geadverteerd te worden als een alternatief voor documentatie: "kijk maar naar de output van de service, er staan links in de response die je kunt volgen".

Leuk voor een mens die een applicatie moet gaan bouwen tegen een service, maar niet voor een machine. Je SPA gaat niet in de JSON een "order"-relatie zien in een "product"-entiteit en vervolgens bedenken dat 'ie een webshop moet gaan genereren.

[ Voor 16% gewijzigd door CodeCaster op 12-01-2017 10:54 ]

[Mercatres]

gekkie schreef op woensdag 11 januari 2017 @ 22:19:
[...]

A-ha .. met al dat geren begin ik me toch af te vragen of jij de doos met chocolaatjes hebt getjoept uit de coffe cornert ..

Whoot .. kom ik toch nog een .NET gerelateerde talk tegen op FOSDEM:

Oh, die is zelfs voor mij relevant. IdentityServer is inderdaad een heel leuk project, min of meer volledig geadopteerd door Microsoft. Die webtalen boeien me iets minder, maar toch. Wie weet ga ik dan toch, al was het maar voor 1 dag.

[alienfruit]

Ik snap niet waarom je keihard zou moeten zijn bij PR. Betere de vriendelijke aanpak dan zoals een collega bij ons: 'This is not how we doing things around here', 'Worthless', 'Clearly you didn't think about X' etc. Daar worden ik en andere collega's niet vrolijk van hoor!

[CodeCaster]

alienfruit schreef op donderdag 12 januari 2017 @ 11:14:
Ik snap niet waarom je keihard zou moeten zijn bij PR. Betere de vriendelijke aanpak dan zoals een collega bij ons: 'This is not how we doing things around here', 'Worthless', 'Clearly you didn't think about X' etc. Daar worden ik en andere collega's niet vrolijk van hoor!

Precies, één Linus is wel genoeg.

[Firesphere]

CodeCaster schreef op donderdag 12 januari 2017 @ 10:47:
Ik snap dat je het kunt counteren met "dan is de rest van je proces gaar", maar ik ben faliekant tegen squashen en rebasen.

Bij het implementeren van een feature refactor je bestaande code en/of pas je publieke interfaces aan van services die de functionaliteit leveren voor jouw feature. Deze zaken moeten als losstaande commit kunnen worden bekeken en gemerged, en niet gesquasht en als één geheel gezien.

Ja, als je dat nodig hebt, is je proces gaar. Dat weet ik. Idealiter zou je dan je ticket opsplitsen in twee aparte tickets: deel één om de servicelaag uit te breiden, en deel twee om de nieuwe functionaliteit daarop te bouwen. Cultuur verander je echter maar langzaam.

Hetzelfde geldt voor rebasen. Als er na het finishen van een feature weer eens iets omvalt door een slecht geteste nieuwe feature, wil je niet dat de geschiedenis van je project lineair is. Je wil de commit óp die feature branch zien die de boel gesloopt heeft.

Sowieso haat ik commits die meer dan een handvol bestanden en/of regels raken, maar aan de andere kant heb ik ook een hekel aan opvolgende commits die hetzelfde stuk code raken door voortschrijdend inzicht tijdens het implementeren. Dát soort commits mogen gesquashed worden.

---

En ik snap HATEOAS/HAL nog steeds niet (https://github.com/mikeke...ster/hal_specification.md, https://tools.ietf.org/html/draft-kelly-json-hal-08, https://spring.io/understanding/HATEOAS, https://martinfowler.com/...hardsonMaturityModel.html).

Of althans, niet voor wie het bedoeld is. Het lijkt vooralsnog geadverteerd te worden als een alternatief voor documentatie: "kijk maar naar de output van de service, er staan links in de response die je kunt volgen".

Leuk voor een mens die een applicatie moet gaan bouwen tegen een service, maar niet voor een machine. Je SPA gaat niet in de JSON een "order"-relatie zien in een "product"-entiteit en vervolgens bedenken dat 'ie een webshop moet gaan genereren.

Er zijn meerdere redenen om te squashen. Jouw reden is inderdaad niet een reden om te squashen.

Je "niet rebasen" argument daarentegen, is nogal ongefundeerd. Rebasing doe je als de origin diverted is van jouw werk.

En dat is niet omdat het toevallig jouw werk kan beinvouden. En mocht dat het geval zijn, zoek je een oplossing.

Zeggen dat je nooit hoeft te rebasen, betekend dat er nooit iets gebeurd on je aster of develop. E dat is domweg niet waar.

[ Voor 7% gewijzigd door Firesphere op 12-01-2017 11:44 ]

[gekkie]

grmbl .. vergeten m'n wifi-kaart te duct-tapen .. laptop weer open halen.

[CodeCaster]

Firesphere schreef op donderdag 12 januari 2017 @ 11:40:
Je "niet rebasen" argument daarentegen, is nogal ongefundeerd. Rebasing doe je als de origin diverted is van jouw werk.

En dat is niet omdat het toevallig jouw werk kan beinvouden. En mocht dat het geval zijn, zoek je een oplossing.

Zeggen dat je nooit hoeft te rebasen, betekend dat er nooit iets gebeurd on je aster of develop. E dat is domweg niet waar.

Je doet niet echt je best om me te overtuigen door je punt te verduidelijken,maar in plaats daarvan ga je me met de botte bijl aanvallen op opmerkingen die ik niet heb gemaakt. En dat vind ik jammer, want op de meetings leek je IRL best een toffe peer.

Ik zeg niet dat je nooit hoeft te rebasen. Ik zeg dat rebasen de geschiedenis lineair maakt, waardoor je niet meer kunt zien wat er op een bepaalde feature branch is gebeurd. En dat ik dat laatste nogal eens nodig heb gehad.

Als ik dat mis heb, leg me dat dan uit.

[ Voor 7% gewijzigd door CodeCaster op 12-01-2017 12:05 ]

[HMS]

CodeCaster, ik vermoed dat FS bedoelt dat je rebased op je feature branch om de feature boven op je master (of hoe je main branch ook heet ) te plaatsen en dan eventuele merge problemen oplossen.

Vervolgens zou je dan een merge kunnen doen van de feature branch met de '--no-ff' optie, afhankelijk van of je een lineaire historie wil of niet.

[Jan_V]

HMS schreef op donderdag 12 januari 2017 @ 13:30:
CodeCaster, ik vermoed dat FS bedoelt dat je rebased op je feature branch om de feature boven op je master (of hoe je main branch ook heet ) te plaatsen en dan eventuele merge problemen oplossen.

Vervolgens zou je dan een merge kunnen doen van de feature branch met de '--no-ff' optie, afhankelijk van of je een lineaire historie wil of niet.

Zo begreep ik het ook, zoals in dit plaatje.

Bron: https://www.atlassian.com...verview#the-rebase-option

Dan 'breek' je dus niet de historie, maar schuif je de start van je feature-branch gewoon op. Dit lijkt me een viable toepassing van een rebase, aangezien je niet zo'n 'lelijke' merge commit krijgt van master -> feature.

[Sardaukar]

CodeCaster schreef op donderdag 12 januari 2017 @ 10:47:
Hetzelfde geldt voor rebasen. Als er na het finishen van een feature weer eens iets omvalt door een slecht geteste nieuwe feature, wil je niet dat de geschiedenis van je project lineair is. Je wil de commit óp die feature branch zien die de boel gesloopt heeft.

Rebasen is echter ideaal om een feature-branch up-to-date te houden met master zonder de feature-branch zelf te moeten vervuilen met merge-commits vanuit master. Die merge-commits zijn in mijn ogen niet te reviewen.

En als je bij het mergen de --no-ff switch gebruikt kun je ook nog keurig blijven zien in je historie hoe je branch in elkaar zat.

[CodeCaster]

Sardaukar schreef op donderdag 12 januari 2017 @ 14:50:
[...]


Rebasen is echter ideaal om een feature-branch up-to-date te houden met master zonder de feature-branch zelf te moeten vervuilen met merge-commits vanuit master.

Ik wil door mij getikte code niet alleen op mijn machine hebben staan. Als ik in een feature-branch aan het werk ben, push ik die dan ook regelmatig.

Op dat moment zou je toch niet meer moeten rebasen?

Begrijp me niet verkeerd, ik snap dat er mensen lyrisch zijn over rebasen, ik kan alleen geen enkele leesbare, duidelijke uitleg vinden waarom ik het ook zou moeten doen en in welk scenario. Ik kan geen tree-schets met bolletjes zoals hierboven van Atlassian meer zien. Er wordt bij die voorbeelden ook nooit uitgelegd hóe er met Git gewerkt wordt, of dat alleen of in een team is, met Git Flow of welke branching-strategie dan ook.

[ Voor 30% gewijzigd door CodeCaster op 12-01-2017 16:44 ]

[HMS]

Dat ligt er aan, werk je alleen op de feature branch of met meer mensen tegelijk? Als de aanname is dat je alleen op je feature branch aan het werk bent dan kan je prima rebasen en force pushen naar de server.

Mocht je met meer mensen op 1 feature branch werken, dan is het wel een stuk lastiger. Ik ben zelf wel voorstander van 1 persoon op een feature branch waar je in principe mee mag doen wat je wil (qua rebasen / force push / squash / etc.).

[Gamebuster]

Ik werk altijd alleen op een feature branch, rebase vrijwel dagelijks tegen de branch waar ik vanaf haakte binnen, en force-push daarna. Als meerdere aan dezelfde feature werken, hebben we 1 feature branch met daarin persoonlijke "forks" van die branches, waarbij de feature branch gerebased wordt met master en daarna je eigen branch met de gedeelde feature branch. Dit doen we echter niet heel veel; men werkt voornamelijk alleen aan features

Het vereist wat oefenen en communicatie, maar je hebt hele schone git historie en duidelijke pull requests

[ Voor 7% gewijzigd door Gamebuster op 12-01-2017 17:05 ]

[Sardaukar]

CodeCaster schreef op donderdag 12 januari 2017 @ 16:39:
[...]

Ik wil door mij getikte code niet alleen op mijn machine hebben staan. Als ik in een feature-branch aan het werk ben, push ik die dan ook regelmatig.

Op dat moment zou je toch niet meer moeten rebasen?

Begrijp me niet verkeerd, ik snap dat er mensen lyrisch zijn over rebasen, ik kan alleen geen enkele leesbare, duidelijke uitleg vinden waarom ik het ook zou moeten doen en in welk scenario. Ik kan geen tree-schets met bolletjes zoals hierboven van Atlassian meer zien. Er wordt bij die voorbeelden ook nooit uitgelegd hóe er met Git gewerkt wordt, of dat alleen of in een team is, met Git Flow of welke branching-strategie dan ook.

Ik ben er niet lyrisch over - het is gewoon een handig hulpmiddel om tot je beschikking te hebben.

Vaak genoeg dat ik zelf met meerdere branches bezig ben in mijn eentje (bijvoorbeeld PR'en). Dan is het geen enkel probleem om zo'n branch te pushen, te rebasen en daarna opnieuw te force-pushen.

En ik geef regelmatig Git cursussen op mijn werk voor collega's: ik zou zeggen, kom een keertje langs. We zitten door het hele land

(En Git flow zou ik nooit aanraden voor een team wat net met Git bezig is).

[ZaZ]

Het rebasen van de feature branch is ook niet zaligmakend. Ik heb vaak genoeg bakken met conflicten die bij een lang levende branch verschrikkelijk irritant worden omdat je ze elke keer weer opnieuw per rebase om je oren krijgt. Soms zelfs wel meerdere malen.
De optie rerere helpt wel, maar daar kleven ook weer nadelen aan vast.
Het is persoonlijk in dat geval toch nog wel altijd mooier dan een merge.

Maar goed, een feature branch up to date houden met bijv. master probeer ik te voorkomen.
Helemaal in teamverband (wat dan altijd met gewone merges gaat)
Daar had ik nog niet zo lang geleden een onwijs groot issue mee waar niet echt een goede oplossing voor is als iemand onopgemerkt een merge heeft verkloot in de feature branch zelf.
Enige oplossing was commits van een heel team gaan cherry picken van een week lang waar ik dus weer alle conflicten kon gaan oplossen.

[Sardaukar]

ZaZ schreef op vrijdag 13 januari 2017 @ 01:10:
Het rebasen van de feature branch is ook niet zaligmakend. Ik heb vaak genoeg bakken met conflicten die bij een lang levende branch verschrikkelijk irritant worden omdat je ze elke keer weer opnieuw per rebase om je oren krijgt. Soms zelfs wel meerdere malen.
De optie rerere helpt wel, maar daar kleven ook weer nadelen aan vast.
Het is persoonlijk in dat geval toch nog wel altijd mooier dan een merge.

Uiteraard zul je altijd tegen merge problemen aanlopen (of dat nu via een rebase of via een merge is) als beide branches substantieel uit elkaar gaan lopen. Het oude gezegde 'merge early, merge often' blijft daarom ook altijd geldig.

Ik heb echter altijd met Git het idee dat ik er meer mee kan in vergelijking met systemen als TFS of Subversion.

[PrisonerOfPain]

Sardaukar schreef op vrijdag 13 januari 2017 @ 11:19:
[...]
Het oude gezegde 'merge early, merge often' blijft daarom ook altijd geldig.

Ik dacht dat bij git 't gezegde was "merge early, merge the same shit all the time"

[ZaZ]

Sardaukar schreef op vrijdag 13 januari 2017 @ 11:19:
[...]


Uiteraard zul je altijd tegen merge problemen aanlopen (of dat nu via een rebase of via een merge is) als beide branches substantieel uit elkaar gaan lopen. Het oude gezegde 'merge early, merge often' blijft daarom ook altijd geldig.

Ik heb echter altijd met Git het idee dat ik er meer mee kan in vergelijking met systemen als TFS of Subversion.

Maar bij een merge krijg je een keer een conflict en je lost 'm op en klaar.
De volgende keer wanneer je een merge doet heb je er geen last meer van.
Wanneer je gaat rebasen krijg je echter elke volgende rebase al je oude conlficten nogmaals voor je kiezen en wanneer de branches meer en meer uit elkaar gaan lopen wordt dat probleem steeds erger omdat je de 'eerste' commit steeds weer opnieuw gaat toepassen op een meer en meer vervreemde basis. En hetzelfde geldt natuurlijk ook voor alle volgende commits.

[EagleTitan]

ZaZ schreef op vrijdag 13 januari 2017 @ 11:44:
[...]

Maar bij een merge krijg je een keer een conflict en je lost 'm op en klaar.
De volgende keer wanneer je een merge doet heb je er geen last meer van.
Wanneer je gaat rebasen krijg je echter elke volgende rebase al je oude conlficten nogmaals voor je kiezen en wanneer de branches meer en meer uit elkaar gaan lopen wordt dat probleem steeds erger omdat je de 'eerste' commit steeds weer opnieuw gaat toepassen op een meer en meer vervreemde basis. En hetzelfde geldt natuurlijk ook voor alle volgende commits.

Dat is toch gewoon een indicatie dat je te veel probeert te doen binnen een branch?

[ZaZ]

Soms heb je nou eenmaal wat grotere features of wordt het een en ander gerefactored.
Dan kan je niet tegen de rest van het team zeggen "en nou niets meer doen de komende week!"

[EagleTitan]

Bij ingrijpende refactors zou ik alleen wanneer je klaar bent voor PR/merge een rebase doen, exact hierom. Het inmergen van de base houdt ook in dat je steeds de wijzigingen van het team moet aanpassen, dus dan doe je in principe hetzelfde.

[Rutix]

whoami schreef op woensdag 11 januari 2017 @ 20:27:
[...]

Beetje foute zinstructuur.
Het gaat erom dat we de signature van een XML bericht dat door een Java systeem gegenereerd werd, moeten verifiëren in onze .NET backend.
Ons systeem meldt altijd dat de signature niet valid is, terwijl ze dat wel is. Wellicht een probleem met de canonicalization.

Ik weet niet of je hebt gevonden waarom dit gebeurt maar ik ben hier ookal in het verleden tegenaan gelopen. Ik heb dit toen helemaal uitgezocht met debugging van .NET aan enzo. Volgens mij had het te maken met de manier hoe Java de signatures maakt (en include in de XML). Volgens de standaard mocht die manier gewoon maar .NET rekende daar niet op. Als je wilt dan kan ik even vragen hoe wij dat opgelost hadden

[Firesphere]

Als de feature te groot is, moet je je feature herinrichten. Indien nodig met subtasks die je kan gebruiken om nieuwe branches te maken die je snel kan mergen.

[Tarkin]

ZaZ schreef op vrijdag 13 januari 2017 @ 11:48:
Soms heb je nou eenmaal wat grotere features of wordt het een en ander gerefactored.
Dan kan je niet tegen de rest van het team zeggen "en nou niets meer doen de komende week!"

Dat hebben we wel nog gedaan. nu niet in die bewoordingen maar de boodschap was toch zo weinig mogelijk kleine commits. Het was wel nog SVN toen.

Ging ook over een grote refactoring en ze waren het wat beu dat ze iedere keer merge conflicts moesten oplossen (waren al een paar maand zo bezig) en ze waren nog maar een paar dagen van merge met de master toen.

Zolang het voor een dag of 2-3 is, gaat dat nog. Maar maanden iets gijzelen wordt al heel wat lastiger

[Sardaukar]

Firesphere schreef op vrijdag 13 januari 2017 @ 12:31:
Als de feature te groot is, moet je je feature herinrichten. Indien nodig met subtasks die je kan gebruiken om nieuwe branches te maken die je snel kan mergen.

En een optie als feature flags of feature toggles zijn natuurlijk ook altijd te gebruiken.

[Rutix]

Sardaukar schreef op vrijdag 13 januari 2017 @ 13:04:
[...]


En een optie als feature flags of feature toggles zijn natuurlijk ook altijd te gebruiken.

Als ze goed gedaan worden wel ja ik ken teams die dat toepastte maar uiteindelijk als de feature klaar was dan niet de toggle enzo eruit sloopte. Maar als ze goed worden gebruikt dan is Feature Toggle een hele goede. Vooral ook omdat er al snel de integratie met de rest van de features getest word.

[whoami]

Rutix schreef op vrijdag 13 januari 2017 @ 12:29:
[...]

Ik weet niet of je hebt gevonden waarom dit gebeurt maar ik ben hier ookal in het verleden tegenaan gelopen. Ik heb dit toen helemaal uitgezocht met debugging van .NET aan enzo. Volgens mij had het te maken met de manier hoe Java de signatures maakt (en include in de XML). Volgens de standaard mocht die manier gewoon maar .NET rekende daar niet op. Als je wilt dan kan ik even vragen hoe wij dat opgelost hadden

Nee, nog niet gevonden. Momenteel laat ik dat even liggen, en met een andere issue bezig, maar alle informatie is welkom natuurlijk

[Sardaukar]

Rutix schreef op vrijdag 13 januari 2017 @ 18:12:
[...]

Als ze goed gedaan worden wel ja ik ken teams die dat toepastte maar uiteindelijk als de feature klaar was dan niet de toggle enzo eruit sloopte. Maar als ze goed worden gebruikt dan is Feature Toggle een hele goede. Vooral ook omdat er al snel de integratie met de rest van de features getest word.

Ja, als je met incompetente mensen werkt zal alles een probleem worden

Ik heb ooit een discussie met een manager gehad die vond dat alles gedocumenteerd moest worden zodat iedereen (ook mensen zonder programmeer ervaring) er mee uit de voeten moest kunnen. Het ging hier om technische documentatie die alleen bedoeld was voor programmeurs

[Rutix]

whoami schreef op vrijdag 13 januari 2017 @ 18:56:
[...]

Nee, nog niet gevonden. Momenteel laat ik dat even liggen, en met een andere issue bezig, maar alle informatie is welkom natuurlijk

Ik zal maandag even kijken of ik het nog kan vinden .

[Verwijderd]

Gebruik altijd de "readonly" user op productie-database... Zodat er niks mis kan gaan als ik in verkeerde tabblad zit. Dan is het wel handig als die user daadwerkelijk read-only is en niet gewoon alle rechten heeft.

[wackmaniac]

Dat je geen toegang hebt tot de API waar je mee moet koppelen en alles op basis van een documentatieset moet doen. Waar foutieve url's en responses in staan ...

[hackerhater]

Sterkte wackmaniac
Zucht ik mag ik mijn werkgever (voor de zoveelste keer) uitleggen waarom er zoveel kapot gegaan is op de nieuwe site (dev) -_-'

Ik had namelijk een groot veiligheidslek moeten repareren (je kon je voordoen als een ander!) waardoor de oude aanroepen niet meer werken.

[Mercatres]

wackmaniac schreef op maandag 16 januari 2017 @ 11:25:
Dat je geen toegang hebt tot de API waar je mee moet koppelen en alles op basis van een documentatieset moet doen. Waar foutieve url's en responses in staan ...

Jij hebt tenminste nog documentatie

[Rem]

Mercatres schreef op maandag 16 januari 2017 @ 14:02:
[...]

Jij hebt tenminste nog documentatie

Wat moet je dan als je geen toegang tot de API hebt?

Nouja, wellicht als ik iets post naar /:users/:id krijg ik wel wat data, en misschien ziet die er dan wel zo uit:

code:

{
 id: 1,
 name: 'Thomas'
}

Nou dan gaan we daar maar vanuit!

[wackmaniac]

Rem schreef op maandag 16 januari 2017 @ 14:07:
[...]


Wat moet je dan als je geen toegang tot de API hebt?

Nouja, wellicht als ik iets post naar /:users/:id krijg ik wel wat data, en misschien ziet die er dan wel zo uit:

code:

{
 id: 1,
 name: 'Thomas'
}

Nou dan gaan we daar maar vanuit!

Nou de response mocken op basis van de documentatie. Alleen nu ik wel toegang heb tot de API blijkt de documentatie op een aantal punten niet te kloppen. Dat maakt het geheel niet makkelijker. Gelukkig lijk ik nu een issue in de API te hebben gevonden, kan het mooi weer even naar de andere kant

[hackerhater]

Mercatres schreef op maandag 16 januari 2017 @ 14:02:
[...]

Jij hebt tenminste nog documentatie

Documentatie wat is dat?
De docu wat er is van de interne systemen heb ik gemaakt
En dan nog durft de wg te beweren dat ie het systeem beter kent dan ik

[ Voor 14% gewijzigd door hackerhater op 16-01-2017 15:14 ]

[Rem]

wackmaniac schreef op maandag 16 januari 2017 @ 14:18:
[...]


Nou de response mocken op basis van de documentatie. Alleen nu ik wel toegang heb tot de API blijkt de documentatie op een aantal punten niet te kloppen. Dat maakt het geheel niet makkelijker. Gelukkig lijk ik nu een issue in de API te hebben gevonden, kan het mooi weer even naar de andere kant

Dat is het punt, Mercatres zegt dat je geluk hebt dat je in ieder geval nog documentatie hebt. Dus wat als je die niet zou hebben?

[Mercatres]

hackerhater schreef op maandag 16 januari 2017 @ 15:08:
[...]


Documentatie wat is dat?
De docu wat er is van de interne systemen heb ik gemaakt
En dan nog durft de wg te beweren dat ie het systeem beter kent dan ik

[afbeelding]

Wij moeten ook documentatie schrijven, en al bij al valt dat nog wel mee. Zolang je het bijhoudt. Echter ondersteunen wij ook externe systemen, en die hebben niet altijd de nodige documentatie.

[Rutix]

Mercatres schreef op maandag 16 januari 2017 @ 15:49:
[...]

Wij moeten ook documentatie schrijven, en al bij al valt dat nog wel mee. Zolang je het bijhoudt. Echter ondersteunen wij ook externe systemen, en die hebben niet altijd de nodige documentatie.

Precies als je het gewoon routine maakt en je interne documentatie bij houd dan valt het werk wat je erin moet steken reuze mee . Ik vind het nooit leuk werk maar het moet toch gebeuren

[hackerhater]

Rutix schreef op maandag 16 januari 2017 @ 18:36:
[...]

Precies als je het gewoon routine maakt en je interne documentatie bij houd dan valt het werk wat je erin moet steken reuze mee . Ik vind het nooit leuk werk maar het moet toch gebeuren

Ja maar reverse engineren een oud systeem is dat niet

[Mercatres]

hackerhater schreef op maandag 16 januari 2017 @ 20:15:
[...]


Ja maar reverse engineren een oud systeem is dat niet

Als je er de tijd voor krijgt wel

[hackerhater]

Mercatres schreef op dinsdag 17 januari 2017 @ 09:06:
[...]

Als je er de tijd voor krijgt wel

Als. Daar zit ook direct het probleem.

[Mercatres]

hackerhater schreef op dinsdag 17 januari 2017 @ 09:41:
[...]


Als. Daar zit ook direct het probleem.

Tja, dan zal het ook niet al te belangrijk zijn

[hackerhater]

Laat ik het zo zeggen : er is een reden waarom ik om me heen het kijken ben

[whoami]

Ik ben voor de eerste keer bezig met een project dat gebruik maakt van EF Core. Ik wil een transactie starten met een bepaald isolation-level, maar het lijkt me niet mogelijk om dit te doen in EFCore, daar waar dit in EF6 blijkbaar wel kan (overload op BeginTransaction met IsolationLevel parameter).

[HMS]

whoami schreef op dinsdag 17 januari 2017 @ 11:13:
Ik ben voor de eerste keer bezig met een project dat gebruik maakt van EF Core. Ik wil een transactie starten met een bepaald isolation-level, maar het lijkt me niet mogelijk om dit te doen in EFCore, daar waar dit in EF6 blijkbaar wel kan (overload op BeginTransaction met IsolationLevel parameter).

Lijkt voor 1.2 of 2.0 op de rol te staan inderdaad: https://github.com/aspnet/EntityFramework/issues/5595

[Jan_V]

Onlangs wilde ik ook een project in Core gaan maken, maar ben wel blij dat ik eerst een klein tooltje heb gemaakt om er enige ervaring mee op te doen.
Tijdens de ontwikkeling van het tooltje kwam ik er al vrij snel achter dat ik voor een groter project liever even wacht tot ze een hoger .NET Standard versie gaan ondersteunen. Er missen, voor mij, nu nog enkele features die ik liever niet zelf ga ontwikkelen. Plus het feit dat de tooling enkele maanden geleden nog niet heel geschikt was voor productie doeleinden. Is dat inmiddels verbeterd?

[Rutix]

Jan_V schreef op dinsdag 17 januari 2017 @ 13:54:
Onlangs wilde ik ook een project in Core gaan maken, maar ben wel blij dat ik eerst een klein tooltje heb gemaakt om er enige ervaring mee op te doen.
Tijdens de ontwikkeling van het tooltje kwam ik er al vrij snel achter dat ik voor een groter project liever even wacht tot ze een hoger .NET Standard versie gaan ondersteunen. Er missen, voor mij, nu nog enkele features die ik liever niet zelf ga ontwikkelen. Plus het feit dat de tooling enkele maanden geleden nog niet heel geschikt was voor productie doeleinden. Is dat inmiddels verbeterd?

Het is wel beter geworden maar nog niet zo goed dat ik het voor commercieel zou gebruiken. Ze lopen nu ook te kloten met toch weer project.json weg te doen enzo en dat schijnt met Visual Studio 2017 RTM klaar te zijn. Ik zou dus nog een paar maandjes wachten . Mijn hobby tooltjes doe ik al wel in Core vooral om ervaring te krijgen.

[ThaStealth]

Iemand een idee hoelang het nog gaat duren voordat de Final van 2017 uitkomt? Heb net mijn PC geherinstalleerd en ben aan het twijfelen om RC2017 erop te knallen. Nadeel van VS is dat hij bijna nooit te deinstalleren is, deinstalleren betekend complete reinstall doen.

als het nog een paar maanden duurt doe ik wel een reinstall, als het overmorgen is doe ik wel een paar dagen zonder VS

[beany]

Ik kan zo snel niks vinden over een RTM datum. Meestal komen die dingen als een soort van verrassing (voor mij dan ).

Snelle zoektocht op 'visual studio 2017 road map' woorden levert ook weinig op.

Wat mis je als je in VS2015 aan de slag gaat? En is een VM een optie tot de RTM uit is?

[Alex)]

VM'metje aanmaken in Azure met een VS2015-template, en die gebruiken tot VS2017 uitkomt?

[DeluxZ]

ThaStealth schreef op woensdag 18 januari 2017 @ 11:19:
Iemand een idee hoelang het nog gaat duren voordat de Final van 2017 uitkomt? Heb net mijn PC geherinstalleerd en ben aan het twijfelen om RC2017 erop te knallen. Nadeel van VS is dat hij bijna nooit te deinstalleren is, deinstalleren betekend complete reinstall doen.

als het nog een paar maanden duurt doe ik wel een reinstall, als het overmorgen is doe ik wel een paar dagen zonder VS

Ergens in de zomer volgens mij. De installatie van 2017 is sowieso helemaal anders als van 2015 (een stuk sneller). Ik verwacht dat de deinstallatie ook makkelijker is als bij 2015

[Sardaukar]

ThaStealth schreef op woensdag 18 januari 2017 @ 11:19:
Iemand een idee hoelang het nog gaat duren voordat de Final van 2017 uitkomt? Heb net mijn PC geherinstalleerd en ben aan het twijfelen om RC2017 erop te knallen. Nadeel van VS is dat hij bijna nooit te deinstalleren is, deinstalleren betekend complete reinstall doen.

Mijn educated guess is dat de final uitkomt op de Microsoft Build conference op 10 mei.

Source: my ass

[HMS]

ThaStealth schreef op woensdag 18 januari 2017 @ 11:19:
Iemand een idee hoelang het nog gaat duren voordat de Final van 2017 uitkomt? Heb net mijn PC geherinstalleerd en ben aan het twijfelen om RC2017 erop te knallen. Nadeel van VS is dat hij bijna nooit te deinstalleren is, deinstalleren betekend complete reinstall doen.

als het nog een paar maanden duurt doe ik wel een reinstall, als het overmorgen is doe ik wel een paar dagen zonder VS

Het hele uninstall feest zouden ze aangepakt moeten hebben met VS2017, sterker nog de hele installer hebben ze aangepakt. Dus misschien is het de moeite waard om te testen

[Rutix]

ThaStealth schreef op woensdag 18 januari 2017 @ 11:19:
Iemand een idee hoelang het nog gaat duren voordat de Final van 2017 uitkomt? Heb net mijn PC geherinstalleerd en ben aan het twijfelen om RC2017 erop te knallen. Nadeel van VS is dat hij bijna nooit te deinstalleren is, deinstalleren betekend complete reinstall doen.

als het nog een paar maanden duurt doe ik wel een reinstall, als het overmorgen is doe ik wel een paar dagen zonder VS

Wacht nog maar even. Veel mensen hebben last van Expired licenses bij VS2017...

[Ryur]

ThaStealth schreef op woensdag 18 januari 2017 @ 11:19:
Iemand een idee hoelang het nog gaat duren voordat de Final van 2017 uitkomt? Heb net mijn PC geherinstalleerd en ben aan het twijfelen om RC2017 erop te knallen. Nadeel van VS is dat hij bijna nooit te deinstalleren is, deinstalleren betekend complete reinstall doen.

als het nog een paar maanden duurt doe ik wel een reinstall, als het overmorgen is doe ik wel een paar dagen zonder VS

Toevallig zit/zat ik met hetzelfde idee. Mijn Windows VM (werk op een Mac met Parallels) is beetje kapot, en wilde hem opnieuw installeren wanneer VS2017 uitkomt.
Maar gaat nu blijkbaar lang duren, dus ga hem binnenkort opnieuw installeren en dan voordat ik VS erop gooi even een backup maken.
Kan ik als VS2017 uit is mijn backup terugzetten en dan gewoon installeren.

Ben benieuwd hoelang het duurt voordat de extensions die ik nu gebruik in 2015 weer overgezet zijn naar 2017

[Hipska]

Nu we toch aan bijna hetzelfde onderwerp zitten..

Wat vinden jullie van VS Code? Gebruik je het voor kleine projectjes en/of editor voor losse files? Heeft het al een ander programma (Notepad++, TextWrangler, BBEdit, Atom?, ...) vervangen bij jou?

[ZaZ]

Is zie voor mijzelf echt het nut van VS Code niet in.
Waarom zou ik in hemelsnaam die beperkte tool opstarten als ik ook Visual Studio heb?
Notepad++/Notepad2/Sublime heeft ie ook niet vervangen, want die gebruik ik niet om te devven.
Ik heb 'm een tijdje geleden geinstalleerd om uit te proberen, maar goed dat je erover begint, ik was vergeten 'm eraf te mikken.
Ga ik nu doen.

[RagingPenguin]

VS code is ideaal voor web front-end werk. Alleen de ondersteuning van .vue bestanden kan imo beter. Maar verder heeft VS Code sublime en Webstorm bij mij compleet verdrongen. Sublime is bij mij altijd een drama met plugins voor dingen die standaard al in VS Code zitten en Webstorm is leuk, maar voor front-end vind ik een full-blown-IDE alleen maar lastig. Helemaal als het zo'n traag gedrocht is als Webstorm. Voor back-end is het echter wel veels te kaal.

[hackerhater]

Ik snap ook niet waarom ze niet de full-blown VS voor Linux uitbrengen.
Wat moet je nu met dat code-ding?

[RagingPenguin]

Ik denk dat de full-blown VS iets te veel afhankelijk is van Windows om zo maar geport te worden. VS code is ook een compleet ander project dat op de naam na weinig te maken heeft met de grote VS

[scosec]

Hipska schreef op donderdag 19 januari 2017 @ 12:43:
Nu we toch aan bijna hetzelfde onderwerp zitten..

Wat vinden jullie van VS Code? Gebruik je het voor kleine projectjes en/of editor voor losse files? Heeft het al een ander programma (Notepad++, TextWrangler, BBEdit, Atom?, ...) vervangen bij jou?

Normaal gesproken maak ik gebruik van PHPStorm maar die heb ik op mijn werk helaas niet. Notepad++ en Textwranger zijn voor mijn gevoel niet geschikt als IDE.

VS Code werkt best aardig en heeft behoorlijk wat mogelijkheden om deze aan te passen naar persoonlijke smaak. Voor bij de werkgever voldoet het bij mij prima.

[wackmaniac]

Waarom heb je op werk geen PHPStorm? Is een minimale investering voor een bedrijf.

[Jan_V]

Ook je persoonlijke licentie mag je gebruiken bij je werkgever. Bij ReSharper in ieder geval wel, denk niet dat het licentie model veel verschilt.

[F.West98]

Ik gebruik VS Code vooral af en toe als vervanger van Notepad++ bij kleine C dingetjes voor mn studie. Dan heeft het geen zin om voor 1/2 bestanden een hele VS te openen maar dan heeft NP weer een beperkte autocomplete en highlighting. Maar ook VS Code is niet echt geweldig voor autocomplete, zeker niet in dingen als flex/bison/yacc. Dat gaat eigenlijk nergens goed.

[armageddon_2k1]

Vraagje, hoe doen "jullie IT-ers" eigenlijk requirements management, if at all? Hoe vertalen jullie klanten/regulatory/quality requirements door naar software? Gewoon puur uit interesse vanuit mijn eigen rol als System Engineer in product development (consumentenelectronica).

[Gropah]

F.West98 schreef op donderdag 19 januari 2017 @ 15:44:
Ik gebruik VS Code vooral af en toe als vervanger van Notepad++ bij kleine C dingetjes voor mn studie. Dan heeft het geen zin om voor 1/2 bestanden een hele VS te openen maar dan heeft NP weer een beperkte autocomplete en highlighting. Maar ook VS Code is niet echt geweldig voor autocomplete, zeker niet in dingen als flex/bison/yacc. Dat gaat eigenlijk nergens goed.

Is ook niet zo raar. Linters etc gaan er stuk op als je meerdere talen door elkaar gebruikte, wat je basically doet wanneer je flex/bison/yacc gebruikt. Also, ik ben slightly confuus; ik had verwacht dat je daar pas later mee te maken zou krijgen?

[F.West98]

Gropah schreef op donderdag 19 januari 2017 @ 18:00:
[...]


Is ook niet zo raar. Linters etc gaan er stuk op als je meerdere talen door elkaar gebruikte, wat je basically doet wanneer je flex/bison/yacc gebruikt. Also, ik ben slightly confuus; ik had verwacht dat je daar pas later mee te maken zou krijgen?

Ja ik doe alvast wat derdejaarsvakken omdat niet alle 2ejaars dingen in het rooster passen zegmaar.

[SPee]

armageddon_2k1 schreef op donderdag 19 januari 2017 @ 17:28:
Vraagje, hoe doen "jullie IT-ers" eigenlijk requirements management, if at all? Hoe vertalen jullie klanten/regulatory/quality requirements door naar software? Gewoon puur uit interesse vanuit mijn eigen rol als System Engineer in product development (consumentenelectronica).

Lijkt mij een cruciaal iets. Zonder requirements geen software.
Hoe goed dat "management" plaats vindt, hangt sterk van de omgeving af. Bij mijn werkgever (IT dienstverlener) moet dat gewoon goed zijn. Maar dat gebeurd zeker niet overal: vooral bij klanten is deze drive minder.
Aan de ene kant zeer belangrijk, maar aan de andere vindt er weinig aandacht voor plaatst.
Ook een supergoede reden om naar Scrum/agile methode over te stappen: "je hoeft dan niet meer te documenteren! :)"

[Alex)]

Dat lijkt wel te gelden voor het project waar ik nu op zit. De enige documentatie die ik (tot nu toe) heb gevonden gaat over integratie met derde partijen.

[Megamind]

Deden wij ook tot 6 maanden geleden, toen hebben we een tester gehuurd die blijkbaar weinig te doen heeft als er geen requirements zijn...

We doen het nu in Target Process, dat werkt best goed.

[Alex)]

Hoe streng zijn jullie eigenlijk in de scrum-leer? Ik snap de principes erachter en ik vind het ook wel fijn werken, maar sommige dingen storen me toch wel.

Het meest vervelende vind ik eigenlijk nog wel de dagelijkse standup, de toegevoegde waarde daarvan vind ik nihil. En daarnaast krijg ik jeuk wanneer mensen het hebben over "scrum-rituelen".

[denyos]

De daily scrum (als we het dan toch over Scrum hebben dan ook maar gelijk de juiste termen er in ) is mits goed uitgevoerd enorm nuttig.
Een korte planning sessie voor de komende 24 uur. Wie gaat wat doen.
Helaas wordt hij vaak gehouden als een update over de vorige dag waarbij de komende dag niet wordt toegelicht. Wanneer je de vorige dag je geplande werk niet hebt kunnen afmaken kan het interessant zijn om even toe te lichten waar dat door kwam, zodat eventueel iemand anders je kan helpen.

[Megamind]

Wij hebben ook elke dag 7 uur de standup meeting, is wel erg handig want het is het enige moment om een beeld te schetsen wat er gaande is, open support etc.

[Rutix]

Alex) schreef op donderdag 19 januari 2017 @ 21:12:
Hoe streng zijn jullie eigenlijk in de scrum-leer? Ik snap de principes erachter en ik vind het ook wel fijn werken, maar sommige dingen storen me toch wel.

Het meest vervelende vind ik eigenlijk nog wel de dagelijkse standup, de toegevoegde waarde daarvan vind ik nihil. En daarnaast krijg ik jeuk wanneer mensen het hebben over "scrum-rituelen".

Ik ben misschien niet heel objectief omdat ik ook Scrum Master ben maar als je de daily scrum goed uitvoert dan is het een van de meest nuttige meetings die je kan hebben. In principe is het heel kort wat heb je gedaan, wat ga je vandaag oppakken en van wie heb je hulp nodig. Sommige mensen beginnen hele discussie in die meetings en dat is niet handig.

Megamind schreef op donderdag 19 januari 2017 @ 21:56:
Wij hebben ook elke dag 7 uur de standup meeting, is wel erg handig want het is het enige moment om een beeld te schetsen wat er gaande is, open support etc.

Just curious 7 uur 's ochtends of 7 uur 's avonds?

[Megamind]

's Ochtends. We beginnen om 7 uur, 5 uur kappen en dan 1x in de 2 weken vrijdag vrij. Maar scrum hebben we helemaal geschrapt, dus we noemen het gewoon de standup meeting, we hebben een eigen agenda gemaakt e.d.

[q-enf0rcer.1]

Net even wat uurtjes besteed aan Vue.js, wat een lekker framework is dat zeg. Ik werk nu al een aantal jaren met AngularJS, sinds kort overgestapt naar Angular 2. Dat was nogal een schok om al die nieuwe patronen te leren. Bij Vue.js is de instapdrempel toch een stuk lager, maar heb je wel de mogelijkheden om de diepte in te gaan zoals bij Angular 2. Geen wonder dat Vue.js het zo goed doet!

Het resultaat is (natuurlijk ) een kleine todo app:

https://vue-todo-4c12e.firebaseapp.com

[Ryur]

armageddon_2k1 schreef op donderdag 19 januari 2017 @ 17:28:
Vraagje, hoe doen "jullie IT-ers" eigenlijk requirements management, if at all? Hoe vertalen jullie klanten/regulatory/quality requirements door naar software? Gewoon puur uit interesse vanuit mijn eigen rol als System Engineer in product development (consumentenelectronica).

Denk dat dit een leuke discussie is in een nieuw topic. Verwacht dat er nog veel commentaar op komt

[Swedish Clown]

Alex) schreef op donderdag 19 januari 2017 @ 21:12:
Hoe streng zijn jullie eigenlijk in de scrum-leer? Ik snap de principes erachter en ik vind het ook wel fijn werken, maar sommige dingen storen me toch wel.

Het meest vervelende vind ik eigenlijk nog wel de dagelijkse standup, de toegevoegde waarde daarvan vind ik nihil. En daarnaast krijg ik jeuk wanneer mensen het hebben over "scrum-rituelen".

Wij doen hier een soort van ScrumBan. Mijn huidige team is redelijk recent afgesplitst van een ander team en op dat moment hebben wij besloten om alle processen die we hadden uit het raam te gooien. Terug naar de basis Rn langzaam processen toe te staan waar nodig. Wij zijn nu enorm flexibel, hebben een fantastische throughput en weinig overhead.

Wel elke dag een standup maar ook daar zijn we flexibel in. Als het niet uitkomt of er valt niks te delen dan skippen we deze gewoon

Retrospectives hebben we ná de afronding van een groter project. Sinds Juni dan ook oas 2 retrospectives gehad. Zolang het team goed blijft communiceren vinden wij het niet nodig om regelmatig retros te houden.

Megamind schreef op donderdag 19 januari 2017 @ 21:56:
Wij hebben ook elke dag 7 uur de standup meeting, is wel erg handig want het is het enige moment om een beeld te schetsen wat er gaande is, open support etc.

Man om 7 uur lig ok nog te maffen. De rest van mijn team ook trouwens Onze werktijden zijn gemiddeld van 09-18 maar ook daar zijn we flexibel. Wil je eerder starten, prima. Wil je later starten, tot op zekere hoogte prima zolang je er maar bent om 09.30 voor de standup.

[armageddon_2k1]

Ryur schreef op vrijdag 20 januari 2017 @ 07:54:
[...]

Denk dat dit een leuke discussie is in een nieuw topic. Verwacht dat er nog veel commentaar op komt

Goed idee, ik ga er een nieuw topic op openen :-)

[DynaSpan]

Net op werk de vraag gekregen of ik eens kan kijken naar een legacy VB project van minstens 10 jaar oud, wat in Windows 10 niet fatsoenlijk werkt (grafieken blijven zwart/hebben zwarte achtergrond ipv wit e.d.). Wordt een leuke dag dit....

[Jan_V]

DynaSpan schreef op vrijdag 20 januari 2017 @ 10:27:
Net op werk de vraag gekregen of ik eens kan kijken naar een legacy VB project van minstens 10 jaar oud, wat in Windows 10 niet fatsoenlijk werkt (grafieken blijven zwart/hebben zwarte achtergrond ipv wit e.d.). Wordt een leuke dag dit....

Klinkt als een mooie use-case voor Centennial!

[ZaZ]

DynaSpan schreef op vrijdag 20 januari 2017 @ 10:27:
Net op werk de vraag gekregen of ik eens kan kijken naar een legacy VB project van minstens 10 jaar oud, wat in Windows 10 niet fatsoenlijk werkt (grafieken blijven zwart/hebben zwarte achtergrond ipv wit e.d.). Wordt een leuke dag dit....

Ik zou als eerste eens kijken of ie misschien een manifest file heeft al dan niet embedded.
Zo ja, eens proberen zonder.

[markvt]

DynaSpan schreef op vrijdag 20 januari 2017 @ 10:27:
Net op werk de vraag gekregen of ik eens kan kijken naar een legacy VB project van minstens 10 jaar oud, wat in Windows 10 niet fatsoenlijk werkt (grafieken blijven zwart/hebben zwarte achtergrond ipv wit e.d.). Wordt een leuke dag dit....

Last van een thema kleur?

MSDN: App Compat Bug Explained: The Mysterious Black Background in Visual Bas...

[DynaSpan]

Jan_V schreef op vrijdag 20 januari 2017 @ 10:53:
[...]

Klinkt als een mooie use-case voor Centennial!

Thanks! Zal eens kijken, alleen het downloaden van die 3GB file wordt een beetje lastig op dit lijntje... thuis maar even proberen dan

ZaZ schreef op vrijdag 20 januari 2017 @ 11:22:
[...]

Ik zou als eerste eens kijken of ie misschien een manifest file heeft al dan niet embedded.
Zo ja, eens proberen zonder.

Kan de manifest file niet zo 1, 2, 3 vinden, dus waarschijnlijk is die niet aanwezig, toch bedankt!

markvt schreef op vrijdag 20 januari 2017 @ 11:26:
[...]


Last van een thema kleur?

MSDN: App Compat Bug Explained: The Mysterious Black Background in Visual Bas...

Heb al geprobeerd in Windows 10 zwart als kleur in te stellen (waardoor de letters wit zouden moeten worden en de grafiek ook, werkt helaas niet). Zal alsnog eens verder kijken. In W7 moet je in ieder geval het oude XP thema aanzetten.

[ZaZ]

Is het VB6? Een andere oude truc is dacht ik om de usercontrols in een picturebox te gooien.
Hoef je geen code voor te veranderen verder. Gewoon knippen en plakken.
Makkelijk om te testen.

[DynaSpan]

ZaZ schreef op vrijdag 20 januari 2017 @ 11:51:
Is het VB6? Een andere oude truc is dacht ik om de usercontrols in een picturebox te gooien.
Hoef je geen code voor te veranderen verder. Gewoon knippen en plakken.
Makkelijk om te testen.

Heb net heel even snel door de broncode kunnen kijken, volgens mij is het niet eens een VB applicatie maar een gescheven in BASIC.

[markvt]

DynaSpan schreef op vrijdag 20 januari 2017 @ 12:25:
[...]


Heb net heel even snel door de broncode kunnen kijken, volgens mij is het niet eens een VB applicatie maar een gescheven in BASIC.

heb je .frm en .bas bestanden?

[scosec]

wackmaniac schreef op donderdag 19 januari 2017 @ 15:06:
Waarom heb je op werk geen PHPStorm? Is een minimale investering voor een bedrijf.

We zijn Microsoft georiënteerd als ik begin over andere software als Microsoft beginnen er een paar te stressen hier op kantoor

[DynaSpan]

markvt schreef op vrijdag 20 januari 2017 @ 12:26:
[...]


heb je .frm en .bas bestanden?

Ja, maar ook een aantal .vbp zie ik nu. Ik ga het eens aanzien. Als het niet gaat dan is het jammer en kijken of 't gevirtualiseerd kan worden.

[ Voor 21% gewijzigd door DynaSpan op 20-01-2017 12:30 ]

[markvt]

DynaSpan schreef op vrijdag 20 januari 2017 @ 12:29:
[...]


Ja, maar ook een aantal .vbp zie ik nu.

Toch visual basic dan

[jip_86]

scosec schreef op vrijdag 20 januari 2017 @ 12:28:
[...]


We zijn Microsoft georiënteerd als ik begin over andere software als Microsoft beginnen er een paar te stressen hier op kantoor

Eh, moet je dan niet in ASP.NET programmeren?