De Devschuur Coffee Corner - Iteratie ➓

[Firesphere]

ZaZ schreef op maandag 18 april 2016 @ 12:40:
"We zullen nooit weten wat Turing in zijn leven nog had kunnen bereiken en wat hij als pionier van kunstmatige intelligentie nog had kunnen ontdekken", stelde Hannigan. "Zo'n fout mogen we als samenleving nooit meer maken."

Nee, bruikbare homo's moeten we accepteren.

Ik heb het idee dat de nieuws sites weer eens selectief aan het quoten zijn geweest en dat het in werkelijkheid niet zo context loos gezegd is.

[Voutloos]

Aangezien t.net uberhaupt niet t artikel over Turing plaatst, zou je bijna af kunnen vragen wat de devschuur hier nog doet.

[qless]

Over het wel/niet plaatsen van artikelen is t.net wel vaker of heel traag of heel inconsekwent... Zelfs voor de meuktracker ( nieuw mongoDB versie wordt de ene keer wel opgenomen, andere keer niet... )

[Mercatres]

In het rijtje "grappige vacatures":


(Yesh yes, hij stond eerst in een ander topic)

[Firesphere]

Mercatres schreef op dinsdag 19 april 2016 @ 09:47:
In het rijtje "grappige vacatures":
[afbeelding]

(Yesh yes, hij stond eerst in een ander topic)

Wut?

[incaz]

Aaaargh, git! Het zou zo leuk zijn als je gewoon ondoordacht makkelijk dingen in git kan gooien (niks stagen, adden en weet ik veel wat, gewoon 'doe alles, nu') en een net zo eenvoudige revert (fuck it, gooi alles weg en begin weer opnieuw.)

Waarom heb ik daar nog steeds een handleiding bij nodig? Het zal vast een leuke tool zijn als je heeeeel veel tijd hebt om het te leren, of als je om een of andere manier een aangeboren neiging hebt om net zo te denken als de bouwers, maar beide gaan voor mij niet op en ik kan er dus nog steeds niks behoorlijks mee.

[Alex)]

Mercatres schreef op dinsdag 19 april 2016 @ 09:47:
In het rijtje "grappige vacatures":
[afbeelding]

(Yesh yes, hij stond eerst in een ander topic)

Eerlijk is het wel

[Tjolk]

incaz schreef op dinsdag 19 april 2016 @ 13:12:
Aaaargh, git! Het zou zo leuk zijn als je gewoon ondoordacht makkelijk dingen in git kan gooien (niks stagen, adden en weet ik veel wat, gewoon 'doe alles, nu') en een net zo eenvoudige revert (fuck it, gooi alles weg en begin weer opnieuw.)

Waarom heb ik daar nog steeds een handleiding bij nodig? Het zal vast een leuke tool zijn als je heeeeel veel tijd hebt om het te leren, of als je om een of andere manier een aangeboren neiging hebt om net zo te denken als de bouwers, maar beide gaan voor mij niet op en ik kan er dus nog steeds niks behoorlijks mee.

Ik ken het gevoel. Normaliter werk ik met SVN en zo heel nu en dan wil ik eens bijdragen aan een Git project. Maar die drempel is om de een of andere reden zo verrektes hoog...

[OkkE]

incaz schreef op dinsdag 19 april 2016 @ 13:12:
Aaaargh, git! Het zou zo leuk zijn als je gewoon ondoordacht makkelijk dingen in git kan gooien (niks stagen, adden en weet ik veel wat, gewoon 'doe alles, nu') en een net zo eenvoudige revert (fuck it, gooi alles weg en begin weer opnieuw.)

Het kan (soort van, met een paar simpele commando's) maar imho is daar Git niet voor bedoelt en is dat geen gewenste werkwijze.

[EagleTitan]

incaz schreef op dinsdag 19 april 2016 @ 13:12:
Aaaargh, git! Het zou zo leuk zijn als je gewoon ondoordacht makkelijk dingen in git kan gooien (niks stagen, adden en weet ik veel wat, gewoon 'doe alles, nu') en een net zo eenvoudige revert (fuck it, gooi alles weg en begin weer opnieuw.)

Waarom heb ik daar nog steeds een handleiding bij nodig? Het zal vast een leuke tool zijn als je heeeeel veel tijd hebt om het te leren, of als je om een of andere manier een aangeboren neiging hebt om net zo te denken als de bouwers, maar beide gaan voor mij niet op en ik kan er dus nog steeds niks behoorlijks mee.

Dus

code:

git commit -a

en

code:

git reset --hard HEAD^

is niet genoeg?

[incaz]

Vreemd idee, dat je niet gewoon een simpel begin zou kunnen maken omdat het daar 'niet voor bedoeld' is... Da's toch gewoon slecht design dan?

Of het de gewenste werkwijze is maak ik zelf wel uit, denk ik dan. Juist als je zo verschrikkelijk veel vergezochte mogelijkheden biedt, zouden die paar basisdingen er ook wel bij kunnen.

Iemand die Version Control by Example kent? http://ericsink.com/vcbe/
De stappen zijn logisch beschreven, en dan wordt het ook direct duidelijk dat Git de basisoperaties gewoon complexer heeft gemaakt dan de overige version control systemen. Zonder een goede reden, mi. Het is volstrekt niet duidelijk waarom ze dat op die manier hebben gedaan.

[Sardaukar]

incaz schreef op dinsdag 19 april 2016 @ 14:27:
Iemand die Version Control by Example kent? http://ericsink.com/vcbe/

Mijn naam staat zelfs in de acknowledgements

Iets met 15 minutes of fame en zo

[OkkE]

incaz schreef op dinsdag 19 april 2016 @ 14:27:
Vreemd idee, dat je niet gewoon een simpel begin zou kunnen maken omdat het daar 'niet voor bedoeld' is... Da's toch gewoon slecht design dan?

Of het de gewenste werkwijze is maak ik zelf wel uit, denk ik dan. Juist als je zo verschrikkelijk veel vergezochte mogelijkheden biedt, zouden die paar basisdingen er ook wel bij kunnen.

Je kunt vrij simpel en snel alles in Git zetten:

git add .; git commit -m "Adding all my changes at once."

Maar het in één keer toevoegen en weer reverten van alle wijzigingen is imho niet iets dat vaak voorkomt. Anyway, ik vind de Git workflow fijn en mis geen features, voor mij werkt het prima zo.

[incaz]

EagleTitan schreef op dinsdag 19 april 2016 @ 14:27:
Dus

code:

git commit -a

en

code:

git reset --hard HEAD^

is niet genoeg?

Git commit -a is blijkbaar niet genoeg, want ondanks dat ben ik nu toch echt code kwijt (en ook niet voor de eerste keer)....
De theorie is leuk, maar zodra er ergens iets scheef zit, krijg je het met commit -a niet recht.

(Nou was svn ook niet ideaal, want een mergeconflict loste ik meestal ook op door de code eerst maar eens voor noodgevallen te backuppen naar een dir buiten de working dir...)

@Sardaukar: yeah Handig boek.

@OkkE: meerdere commando's op 1 regel zetten met ; ertussen maakt het nog niet een 'eenvoudig commando'

[Sardaukar]

incaz schreef op dinsdag 19 april 2016 @ 14:43:
[...]
Git commit -a is blijkbaar niet genoeg, want ondanks dat ben ik nu toch echt code kwijt (en ook niet voor de eerste keer)....

Je probleem is waarschijnlijk dat je untracked files had. Git commit -a neemt deze standaard niet mee.

Zie ook de help voor git commit:

-a
--all
Tell the command to automatically stage files that have been modified and deleted, but new files you have not told Git about are not affected.

[incaz]

Sardaukar schreef op dinsdag 19 april 2016 @ 14:51:
[...]
Je probleem is waarschijnlijk dat je untracked files had. Git commit -a neemt deze standaard niet mee.

Deels. Er speelden nog wat dingen. Maar mijn probleem is dat ik dat een buitengewoon vervelende, foutgevoelige slechtgekozen default vind, die elke keer opnieuw irritant is.
(Omgekeerd vind ik het ook irritant bv dat je geen files kunt ignoren met git ignore file maar dat je een ignore-file moet editen, en dat is gewoon nodeloos complex voor simpele toevoegingen.)

[Grijze Vos]

Ik gebruik zelf TFS op het werk en heb hetzelfde probleem met git. Moet altijd weer nadenken hoe het ook alweer zit. De github windows client maakt wel e.e.a. makkelijker, als je github gebruikt. Dat scheelt wat.

Git is gemaakt door Torvalds, en dat is er gewoon aan af te lezen.

[TheNephilim]

incaz schreef op dinsdag 19 april 2016 @ 14:58:
[...]


Deels. Er speelden nog wat dingen. Maar mijn probleem is dat ik dat een buitengewoon vervelende, foutgevoelige slechtgekozen default vind, die elke keer opnieuw irritant is.
(Omgekeerd vind ik het ook irritant bv dat je geen files kunt ignoren met git ignore file maar dat je een ignore-file moet editen, en dat is gewoon nodeloos complex voor simpele toevoegingen.)

Mja, hoe vaak ignore je nou files?

Dat valt over het algemeen ook wel weer mee. Veel standaard dingen zitten al in mij global ignore file en bijv. Laravel heeft al een standaard ignore file waar het meeste al wel in zit. Als je net begint met een project en sporadisch tussendoor, dan heb je die gitignore file nog wel eens nodig, maar verder bijna niet toch?

[OkkE]

incaz schreef op dinsdag 19 april 2016 @ 14:43:
[...]
@OkkE: meerdere commando's op 1 regel zetten met ; ertussen maakt het nog niet een 'eenvoudig commando'

Ik vind het twee eenvoudige commando's, maar misschien werk ik ook al te lang met Git. Overigens heb ik ook voor vrijwel alle veelgebruikte command's een alias ingesteld, waar door het allemaal wel zo simpel is. Sowieso, elk versie systeem heeft denk ik wel voor- en nadelen, het is vooral waar je aan gewend bent.

Ik reageerde vooral omdat jouw eerste reactie omdat het mij deed denken aan een oud-collega die na een hele dag werken al zijn wijzigingen in één commit in de develop branch pleurde. Aangezien jij het ook had over alles in één keer toevoegen en als het toch niet goed is weer terugdraaien, kreeg ik daar flashbacks naar.

[ Voor 7% gewijzigd door OkkE op 19-04-2016 15:07 ]

[Sardaukar]

incaz schreef op dinsdag 19 april 2016 @ 14:58:
[...]
(Omgekeerd vind ik het ook irritant bv dat je geen files kunt ignoren met git ignore file maar dat je een ignore-file moet editen, en dat is gewoon nodeloos complex voor simpele toevoegingen.)

Dat komt onder andere omdat de ignore file geen lijstje is met files die je negeert maar een lijst met regular expressions. Daardoor kun je dit soort dingen vrolijk doen:

# User-specific files
*.suo
*.user
*.sln.docstates

# ReSharper is a .NET coding add-in
_ReSharper*/
*.[Rr]e[Ss]harper
*.DotSettings.user

Daarnaast is het wel fijn om ook versiebeheer op je ignorefile te hebben.

[incaz]

Nee, je ignoret niet heel vaak (hoewel, het gebeurt me af en toe wel), maar het punt is dat het gewoon allemaal nogal niet-intuitief voelt voor mij. Komt er eigenlijk op neer dat Linus een totaal andere manier van denken heeft dan ik, en ik daardoor voortdurend bezig ben met uitvogelen waarom simpel dingetje x niet gewoon simpel kan.

Dat conflict en die frustratie bestaat al heel lang - steevast vertelt de linuxcommunity dat IK het verkeerde wil, en ik blijf volhouden dat als ik de gebruiker ben, mijn wensen mijn wensen zijn en dus voor mij logisch, en het het systeem is dat niet deugt.
Er wordt veel te veel vanuit het systeem gedacht, niet vanuit de mens, de gebruiker. Als het argument is 'het heeft nou eenmaal een steile leercurve' dan zie IK daarin aanwijzingen voor een slechte opbouw, want de meeste dingen moeten niet zo moeilijk zijn. Helaas is het zeker in de technische tools toch ook vaak wat onwil om dingen gebruiksvriendelijker te maken, omdat het een beetje als een morele test beschouwd wordt of je er wel genoeg voor over hebt om die steile curve te beklimmen.
(En het antwoord is nee, dat heb ik niet )

[HMS]

Dan gebruik je toch geen Git, maar iets anders?

[alienfruit]

Zucht, wanneer je zegt dat ze vandaag niet mogen deven in een bepaalde omgeving wegens demo's. Collega's vonden het een goed idee om vooral vandaag wat aanpassingen te doen in de MARA tabel en zodoende alle demo's falen.

[Sardaukar]

incaz schreef op dinsdag 19 april 2016 @ 15:16:
Als het argument is 'het heeft nou eenmaal een steile leercurve' dan zie IK daarin aanwijzingen voor een slechte opbouw, want de meeste dingen moeten niet zo moeilijk zijn.

Ik geef regelmatig cursussen over Git zowel aan ontwikkelaars voor het dagelijkse gebruik als meer in een release management-achtige setting (hoe gebruik je het om je releaseproces te verbeteren).

Ik herken de frustatie wel. Ja, de commandline syntax is onduidelijk en inconsistent. Aan de andere kant is het een hele krachtige tool. Dingen als interactive rebase of git bisect hoef ik van iets als TFS of Subversion niet te verwachten.

Git is wat mij betreft een voorbeeld van de quote van Fred Brooks: "Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious".

Zodra je doorhebt hoe de interne structuur (de DAG) van Git werkt worden de operaties ook een stuk duidelijker. Een branch is in Git niets anders als een pointer in de DAG. Git reset is dan niets anders als een manier om die pointer te verzetten (wel of niet gecombineerd met het leeghalen van je index en/of working directory).

[EddoH]

Sardaukar schreef op dinsdag 19 april 2016 @ 15:25:
[...]


Zodra je doorhebt hoe de interne structuur (de DAG) van Git werkt worden de operaties ook een stuk duidelijker. Een branch is in Git niets anders als een pointer in de DAG. Git reset is dan niets anders als een manier om die pointer te verzetten (wel of niet gecombineerd met het leeghalen van je index en/of working directory).

Ik vind dat altijd een beetje een argument in de trant van 'als je weet hoe de versnellingsbak van deze auto in elkaar zit, snap je zelf wel dat je hem in de 3e versnellling in plaats van de eerste moet zetten om weg te rijden'

Als de user interface ruk is, dan is dat ruk. Het kan mij geen biet schelen wat er onder de motorkap gebeurd. Je zou dat argument eens bij consumentenproducten moeten proberen, en kijken hoe lang het stand houdt. Waarom zouden developers dat wel moeten doen/slikken?

(Overigens niet persoonlijk bedoeld en daarnaast gebruik ik Git al jaren naar tevredenheid.)

[Sardaukar]

EddoH schreef op dinsdag 19 april 2016 @ 15:38:
[...]
Ik vind dat altijd een beetje een argument in de trant van 'als je weet hoe de versnellingsbak van deze auto in elkaar zit, snap je zelf wel dat je hem in de 3e versnellling in plaats van de eerste moet zetten om weg te rijden'

Als de user interface ruk is, dan is dat ruk. Het kan mij geen biet schelen wat er onder de motorkap gebeurd. Je zou dat argument eens bij consumentenproducten moeten proberen, en kijken hoe lang het stand houdt. Waarom zouden developers dat wel moeten doen/slikken?

(Overigens niet persoonlijk bedoeld en daarnaast gebruik ik Git al jaren naar tevredenheid.)

Niet persoonlijk opgepakt hoor

Maar ik kan het argument ook weer omgooien. Sommige tools hebben nu eenmaal een bepaalde mate van complexiteit omdat ze complexe dingen doen. Ik verwacht ook niet dat ik iemand zonder kennis van databases achter SQL Enterprise Manager zet en dat ze dankzij de fijne UI een prima performante database neerzetten.

Ik ben het met iedereen eens die zegt dat de commandline syntax ruk is. Gelukkig zijn er tools zoals SmartGit en SourceTree die de pijn een beetje wegnemen. Maar zelfs in die tools is het handig dat je weet hoe de DAG in elkaar steekt voordat je klakkeloos operaties gaat uitvoeren.

(Overigens verwachten wij ook dat mensen rijles hebben gehad voordat we ze achter een versnellingsbak zetten )

[EddoH]

Sardaukar schreef op dinsdag 19 april 2016 @ 15:48:
[...]


Niet persoonlijk opgepakt hoor

Maar ik kan het argument ook weer omgooien. Sommige tools hebben nu eenmaal een bepaalde mate van complexiteit omdat ze complexe dingen doen. Ik verwacht ook niet dat ik iemand zonder kennis van databases achter SQL Enterprise Manager zet en dat ze dankzij de fijne UI een prima performante database neerzetten.

Ik ben het met iedereen eens die zegt dat de commandline syntax ruk is. Gelukkig zijn er tools zoals SmartGit en SourceTree die de pijn een beetje wegnemen. Maar zelfs in die tools is het handig dat je weet hoe de DAG in elkaar steekt voordat je klakkeloos operaties gaat uitvoeren.

(Overigens verwachten wij ook dat mensen rijles hebben gehad voordat we ze achter een versnellingsbak zetten )

Hmm. Deels wel mee eens, maar ik verwacht de abstractie voor de gebruiker op een iets hoger niveau dan git nu doet. Om de analogie met rijlessen te nemen; iemand leert gas geven, schakelen, remmen, koppelen, etc. Niet de interne tandwielverhoudingen en hoe de aandrijflijn in elkaar steekt.

Zo wil ik bij een versiebeheer systeem iets nieuws comitten, iets 'terug zetten', iets ongedaan maken,een nieuwe versie maken, etc. Niet de pointer van een node naar een andere plek verzetten.

[Sardaukar]

EddoH schreef op dinsdag 19 april 2016 @ 15:56:
[...]
Zo wil ik bij een versiebeheer systeem iets nieuws comitten, iets 'terug zetten', iets ongedaan maken,een nieuwe versie maken, etc. Niet de pointer van een node naar een andere plek verzetten.

Helemaal mee eens. Mercurial is daarin veel gebruikersvriendelijker. Alleen Git heeft de populariteits contest gewonnen (mede dankzij Github). Als je enigzins met open source werkt ontkom je al niet aan Git.

Dus ben je enigzins gedwongen om een commando als git reset --hard --soft --mixed te kennen. Maar nogmaals, tools als SmartGit/Sourcetree maken dat wel eenvoudiger.

[ZaZ]

Gewoon een paar local repos starten met git init en die elkaar als remote toevoegen (gewoon op filesys niveau)
En dan een paar avondjes spelen en expres conflicten en andere vervelende situaties proberen te veroorzaken en voor je het weet heb je het door.
Dan gaat het 'enge' er een beetje vanaf, wanneer je bijv. doorhebt dat alles wat je commit (en nog niet hebt gepushed) al voorlopig veilig is. Met reflog i.c.m reset kan je altijd weer terug naar je experimenteerpunt en kan je naar hartelust gaan klooien met de iets meer advanced features zoals interactive rebasing e.d

[incaz]

(Trouwens, als ik later groot ben wil ik best een automaat. Ik vond het heerlijk rijden. Ik heb het schakelen onder de knie hoor, maar ik heb nou niet het idee dat het echt iets zinvols aan mijn leven toevoegt - ik doe het omdat het moet.)

[Sardaukar]

incaz schreef op dinsdag 19 april 2016 @ 16:53:
(Trouwens, als ik later groot ben wil ik best een automaat. Ik vond het heerlijk rijden. Ik heb het schakelen onder de knie hoor, maar ik heb nou niet het idee dat het echt iets zinvols aan mijn leven toevoegt - ik doe het omdat het moet.)

Ik rij zelf in een Toyota Auris hybride met automaat. Heerlijk! Nooit meer anders.

[Voutloos]

alienfruit schreef op dinsdag 19 april 2016 @ 15:23:
Zucht, wanneer je zegt dat ze vandaag niet mogen deven in een bepaalde omgeving wegens demo's. Collega's vonden het een goed idee om vooral vandaag wat aanpassingen te doen in de MARA tabel en zodoende alle demo's falen.

Het echte probleem is natuurlijk dat je een omgeving te weinig hebt en/of het voor zowel jou als hunnie te veel werk is om op te zetten.

[Verwijderd]

Demo'en op ontwikkelomgeving... What could possibly go wrong!?

[Skyaero]

incaz schreef op dinsdag 19 april 2016 @ 13:12:
Aaaargh, git! Het zou zo leuk zijn als je gewoon ondoordacht makkelijk dingen in git kan gooien (niks stagen, adden en weet ik veel wat, gewoon 'doe alles, nu') en een net zo eenvoudige revert (fuck it, gooi alles weg en begin weer opnieuw.)

Waarom heb ik daar nog steeds een handleiding bij nodig?

Toevallig ook aan het kloten met git. Wat een gedoe om met twee SSH keys aan de slag te kunnen gaan.

[Alex)]

Verwijderd schreef op dinsdag 19 april 2016 @ 19:55:
Demo'en op ontwikkelomgeving... What could possibly go wrong!?

Beter dan ontwikkelen op acceptatie

[Verwijderd]

Alex) schreef op dinsdag 19 april 2016 @ 20:02:
[...]

Beter dan ontwikkelen op acceptatie

Klopt. Echte devs ontwikkelen op productie!

[Skyaero]

Verwijderd schreef op dinsdag 19 april 2016 @ 20:07:
[...]

Klopt. Echte devs ontwikkelen op productie!

Bug driven development!

[Damic]

Sardaukar schreef op dinsdag 19 april 2016 @ 16:55:
[...]


Ik rij zelf in een Toyota Auris hybride met automaat CVT. Heerlijk! Nooit meer anders.

FTFY

[ Voor 31% gewijzigd door Damic op 19-04-2016 20:23 ]

[SPee]

De echte enterprise heeft gewoon een volledige OTAP omgeving, die allemaal anders geconfigureerd zijn in een complexe omgeving waar de configuratie belangrijk is. En natuurlijk is de installatie volledig handmatig en de handleiding compleet.

[ajakkes]

Mijn users werken tegenwoordig op acceptatie, zodat ik fijn kan devven op productie. Ze hebben het maar te accepteren.

[Xenophon16]

Moet binnenkort met Scheme aan de slag om aerodynamica-simulaties te automatiseren. Nog nooit van de taal gehoord

[Edwin88]

Niemand hier werkt met sourcetree? Ik type nooit handmatig git commands; gewoon een overzichtelijke UI!

[Megamind]

SourceTree hier ja, met HG Om te janken. Gelukkig zijn we bezig HG in te ruilen voor Git.

[azerty]

Goedemorgen iedereen!

* azerty zet een thermos met koffie, een thermos met chocolademelk en een thermos met thee klaar voor de gegadigden. Ook Firesphere wordt niet vergeten: een goed gekoeld Belgisch biertje staat voor hem klaar.

[Ryur]

Edwin88 schreef op dinsdag 19 april 2016 @ 23:01:
Niemand hier werkt met sourcetree? Ik type nooit handmatig git commands; gewoon een overzichtelijke UI!

Ik gebruik (helaas) Sourcetree op mijn Windows-omgeving (samen met Powershell gewoon commands).
Ben niet echt een fan van Sourcetree.

Op Mac gebruik ik Tower (en ook mijn terminal)

[ElkeBxl]

Xenophon16 schreef op dinsdag 19 april 2016 @ 22:52:
Moet binnenkort met Scheme aan de slag om aerodynamica-simulaties te automatiseren. Nog nooit van de taal gehoord

Tof taaltje hoor Maar hou je maar klaar voor een overload aan haakjes (je gaat geen haakjes meer kunnen zien (ja echt waar (overal haakjes! (in scheme kan je nooit genoeg haakjes hebben (het blijft maar komen (er komt geen einde aan! (tot je ineens te ver aan het nesten bent (en dan is het tijd voor eens proberen te refactoren (in de hoop dat je nog de weg vindt (anders ben je verloren))))))))))

azerty schreef op woensdag 20 april 2016 @ 05:19:
Goedemorgen iedereen!

* azerty zet een thermos met koffie, een thermos met chocolademelk en een thermos met thee klaar voor de gegadigden. Ook Firesphere wordt niet vergeten: een goed gekoeld Belgisch biertje staat voor hem klaar.

Hmmmm, chocomelk!

[OkkE]

Edwin88 schreef op dinsdag 19 april 2016 @ 23:01:
Niemand hier werkt met sourcetree? Ik type nooit handmatig git commands; gewoon een overzichtelijke UI!

Ik heb een tijdje SourceTree gebruikt maar vond het te buggy en er gebeurde te vaak dingen die ik niet wilde. Toen overgestapt naar Git op command line en dat bevalt prima, nooit problemen meer gehad. Voordeel van CLI vind ik dat het overal (het zelfde) werkt, ook op servers.

[wackmaniac]

Ben zelfs voor (My|postgre)SQL overgestapt naar cli. Heerlijk man! Doet precies wat je wilt

[farlane]

Sinds kort een beetje aan het pielen met GitKraken, basic op het moment maar vind het wel een aardig tooltje worden.

[Mercatres]

Edwin88 schreef op dinsdag 19 april 2016 @ 23:01:
Niemand hier werkt met sourcetree? Ik type nooit handmatig git commands; gewoon een overzichtelijke UI!

Hier ook een best tevreden gebruiker van SourceTree in combinatie met git. Echter gebeurt het helaas iets te vaak dat git toch nog ergens iets aan het doen is en dat SourceTree dat niet in de gaten heeft.

[DevWouter]

SourceTree is inderdaad prachtig om mee te beginnen, maar het mooiste is dat je met een druk op de knop de git-bash start. In het begin leer je voornamelijk via de GUI te werken en op het moment dat je dingen gaat scripten kan je zo de console openen.

Als je nieuw bent met GIT is dit echt een super fijne tool om het te leren.

Overigens is het wel aan te raden om ook git-bash te leren, zeker als je GIt dagelijks gebruikt is het de moeite waard.

[HuHu]

Ik gebruik zeer sporadisch git, maar ik gebruik daarvoor wel SourceTree. Werkt prima naar mijn mening. Ik doe alleen simpele projecten voor mezelf en de geavanceerde functies gebruik ik daarbij niet.

[alienfruit]

Skyaero schreef op dinsdag 19 april 2016 @ 20:16:
Bug driven development!

Demo's op ontwikkelomgeving. Voornamelijk omdat het aanvragen van een transport twee weken duurt en doorvoeren van de transport een week... Code freeze van drie weken is wel wat veel

[EddoH]

alienfruit schreef op woensdag 20 april 2016 @ 10:19:
[...]


Demo's op ontwikkelomgeving. Voornamelijk omdat het aanvragen van een transport twee weken duurt en doorvoeren van de transport een week... Code freeze van drie weken is wel wat veel

Transport?
Gaan er kleine minions met de code naar een datacentrum om ze daar in de servers te laden ofzo?

[alienfruit]

Bureaucratie! Ja, om data te verplaatsen van installatie A naar B noemen ze in SAP een transport. En dan heb je te maken met de SAP Basis team, approval en governance etc. etc. Document schrijven met al je wijzigen, waarom je de transport wil etc.

[ Voor 45% gewijzigd door alienfruit op 20-04-2016 10:42 ]

[Aherin]

alienfruit schreef op woensdag 20 april 2016 @ 10:41:
Bureaucratie! Ja, om data te verplaatsen van installatie A naar B noemen ze in SAP een transport. En dan heb je te maken met de SAP Basis team, approval en governance etc. etc. Document schrijven met al je wijzigen, waarom je de transport wil etc.

ahh ja.. de lagen managers die overal overheen willen plassen, het zijn net honden die hun territorium af willen bakenen

Dat vind ik soms wel eens lastig aan werken binnen een groot bedrijf.. als ZZPer is het altijd "see it, do it, report it"
Hier is het altijd "see it, discuss it, discuss it with others, discuss it some more, probably do it, then discuss it again"

[EddoH]

alienfruit schreef op woensdag 20 april 2016 @ 10:41:
Bureaucratie! Ja, om data te verplaatsen van installatie A naar B noemen ze in SAP een transport. En dan heb je te maken met de SAP Basis team, approval en governance etc. etc. Document schrijven met al je wijzigen, waarom je de transport wil etc.

Wauw. Volgens mij had men om de bureaucratie efficienter te laten verlopen veel zaken juist geautomatiseerd

[Jegorex]

alienfruit schreef op woensdag 20 april 2016 @ 10:41:
Bureaucratie! Ja, om data te verplaatsen van installatie A naar B noemen ze in SAP een transport. En dan heb je te maken met de SAP Basis team, approval en governance etc. etc. Document schrijven met al je wijzigen, waarom je de transport wil etc.

Bij ons zijn transporten binnen de OTA geen probleem, even een email naar transportbeheer waarin je aangeeft welke transportnummers naar welke omgeving verplaatst moeten worden.
Alleen als iets naar P moet dan heb je een boekwerk aan papieren die ingevuld moeten worden.

[Edwin88]

DevWouter schreef op woensdag 20 april 2016 @ 10:03:
SourceTree is inderdaad prachtig om mee te beginnen, maar het mooiste is dat je met een druk op de knop de git-bash start. In het begin leer je voornamelijk via de GUI te werken en op het moment dat je dingen gaat scripten kan je zo de console openen.

Als je nieuw bent met GIT is dit echt een super fijne tool om het te leren.

Overigens is het wel aan te raden om ook git-bash te leren, zeker als je GIt dagelijks gebruikt is het de moeite waard.

Ik werk voornamelijk alleen of met 1 ander persoon aan code, en dan is SourceTree voldoende. Nog niet echt met scripting gewerkt, dus zal binnenkort (wil het wel gaan doen) dan toch de command line in moeten duiken.
Maar voor de simpele pushes en features branches en overzicht houden werkt het prima. En gratis

[DevWouter]

In een groter team is het hebben van script een stuk handiger. Om je een idee te geven is het volgende script heel handig om heel snel alle issues die een bepaalde omschrijving hadden te cherry-picken van develop branch naar de huidige branch. In dit geval zocht ik naar alle commits die het issue-nummer 7394 en 7393 hadden.

git log --reverse --oneline develop |\
egrep "\b((7394)|(7393))\b" | cut -d' ' -f1 |\
xargs git cherry-pick -x --stdin

En als je een mergeconflict had gebruikte je het volgende om het snel handmatig op te lossen en door te gaan.

git mergetool && git cherry-pick --continue

Ging je toch ergens de mist in dan was het volgende commando om weer helemaal overnieuw te beginnen.

git cherry-pick --abort

De meeste mensen hadden een ochtend nodig om hun eigen tickets in de release branch te krijgen terwijl het mij letterlijk 5 minuten kosten om alles van het hele team te doen. Soms zelfs korter als er helemaal geen merge conflicten waren.

Gevolg was dan ook dat de meeste commits in release branch van mij waren. Voelde echt aan als pronken met andermans veren

[ Voor 4% gewijzigd door DevWouter op 20-04-2016 12:05 . Reden: Spelling en leesbaarheid ]

[joram.agten]

Struikrover schreef op vrijdag 15 april 2016 @ 18:13:
[...]


Moment.JS gebruiken met de timezone plugin? Neemt een hoop hoofdpijn weg...

dat ziet er perfect uit (we gebruiken nu XDate, maar Moment.JS met timezone plugin kan toch net iets meer) Thanks

[gekkie]

DevWouter schreef op woensdag 20 april 2016 @ 12:01:
Gevolg was dan ook dat de meeste commits in release branch van mij waren. Voelde echt aan als pronken met andermans veren

Mjah daarom ook nooit naar de merge commits kijken daarvoor

[EddoH]

DevWouter schreef op woensdag 20 april 2016 @ 12:01:
In een groter team is het hebben van script een stuk handiger. Om je een idee te geven is het volgende script heel handig om heel snel alle issues die een bepaalde omschrijving hadden te cherry-picken van develop branch naar de huidige branch. In dit geval zocht ik naar alle commits die het issue-nummer 7394 en 7393 hadden.

git log --reverse --oneline develop |\
egrep "\b((7394)|(7393))\b" | cut -d' ' -f1 |\
xargs git cherry-pick -x --stdin

En als je een mergeconflict had gebruikte je het volgende om het snel handmatig op te lossen en door te gaan.

git mergetool && git cherry-pick --continue

Ging je toch ergens de mist in dan was het volgende commando om weer helemaal overnieuw te beginnen.

git cherry-pick --abort

De meeste mensen hadden een ochtend nodig om hun eigen tickets in de release branch te krijgen terwijl het mij letterlijk 5 minuten kosten om alles van het hele team te doen. Soms zelfs korter als er helemaal geen merge conflicten waren.

Gevolg was dan ook dat de meeste commits in release branch van mij waren. Voelde echt aan als pronken met andermans veren

Alle tickets los cherry-picken naar release branch ?
Daar hebben ze iets heel moois voor uitgevonden, branching!

[DevWouter]

EddoH schreef op woensdag 20 april 2016 @ 12:17:
[...]


Alle tickets los cherry-picken naar release branch ?
Daar hebben ze iets heel moois voor uitgevonden, branching!

We gebruikte het ook als een methode om "vervuiling van de code" en "vervuiling van de historie" tegen te gaan.

Het was niet ongebruikelijk dat we op de dev-branch een paar features hadden die al bijna klaar waren en vervolgens terug naar de ontwerpfase gingen bij de stakeholders. En gezien de industrie waar de software gebruikt werd was dit niet altijd de schuld van de stakeholders (eerder regelgeving van overkoepelende organisatie of wetgeving die verandert).

Het heeft mij ook veel tijd (en frustratie) gekost voordat ik begreep waarom dat branching niet altijd mogelijk was en dat deze methode beter geschikt was.

[armageddon_2k1]

Xenophon16 schreef op dinsdag 19 april 2016 @ 22:52:
Moet binnenkort met Scheme aan de slag om aerodynamica-simulaties te automatiseren. Nog nooit van de taal gehoord

Toevallig L&R? Dueca?

EDIT: Oh nee, Werktuigbouw zie ik. Maar die hebben een mini-Simona simulator staan in Delft volgens mij.

[ Voor 17% gewijzigd door armageddon_2k1 op 20-04-2016 12:58 ]

[SPee]

Orii schreef op woensdag 20 april 2016 @ 10:50:
[...]

ahh ja.. de lagen managers die overal overheen willen plassen, het zijn net honden die hun territorium af willen bakenen

Dat vind ik soms wel eens lastig aan werken binnen een groot bedrijf.. als ZZPer is het altijd "see it, do it, report it"
Hier is het altijd "see it, discuss it, discuss it with others, discuss it some more, probably do it, then discuss it again"

Vandaar de vacature eisen:

Requirements for developers in large enterprises:
A bonus is any political experience, whether as a candidate or as an elected official.

[Verwijderd]

DevWouter schreef op woensdag 20 april 2016 @ 12:32:
[...]


We gebruikte het ook als een methode om "vervuiling van de code" en "vervuiling van de historie" tegen te gaan.

Het was niet ongebruikelijk dat we op de dev-branch een paar features hadden die al bijna klaar waren en vervolgens terug naar de ontwerpfase gingen bij de stakeholders. En gezien de industrie waar de software gebruikt werd was dit niet altijd de schuld van de stakeholders (eerder regelgeving van overkoepelende organisatie of wetgeving die verandert).

Het heeft mij ook veel tijd (en frustratie) gekost voordat ik begreep waarom dat branching niet altijd mogelijk was en dat deze methode beter geschikt was.

Zoals ik het nu begrijp, heeft het je veel tijd en frustratie gekost om iets aan te leren dat nogal onzinnig is...

[DevWouter]

Verwijderd schreef op woensdag 20 april 2016 @ 13:45:Zoals ik het nu begrijp, heeft het je veel tijd en frustratie gekost om iets aan te leren dat nogal onzinnig is...

Heb ook voorgesteld om iedereen in de DevSchuur te huren, maar het bedrijf vond het geen goed idee om een monopoly te krijgen op de beste mensen

[zezke]

Onzin, welk bedrijf wil dat nu niet? Of hadden ze schrik voor de koffierekening? (En chocomelk en bier en...)

[ZaZ]

rm -rf koppijn werkt niet

[gekkie]

ZaZ schreef op woensdag 20 april 2016 @ 14:45:
rm -rf koppijn werkt niet

Zou je je met een sterretje wel flink genomen voelen denk je ?
(kun je wel door voor een artikel op /. )

[ Voor 12% gewijzigd door gekkie op 20-04-2016 14:47 ]

[kenneth]

ZaZ schreef op woensdag 20 april 2016 @ 14:45:
rm -rf koppijn werkt niet

Is koppijn een directory dan?

[ZaZ]

Nou, het trekt van mijn slapen naar mijn schouders, dus recursief leek me wel wat

[Xenophon16]

ElkeBxl schreef op woensdag 20 april 2016 @ 08:38:
Tof taaltje hoor Maar hou je maar klaar voor een overload aan haakjes (je gaat geen haakjes meer kunnen zien (ja echt waar (overal haakjes! (in scheme kan je nooit genoeg haakjes hebben (het blijft maar komen (er komt geen einde aan! (tot je ineens te ver aan het nesten bent (en dan is het tijd voor eens proberen te refactoren (in de hoop dat je nog de weg vindt (anders ben je verloren))))))))))

*snip*

Haha nou ik haak al af

[ElkeBxl]

Xenophon16 schreef op woensdag 20 april 2016 @ 14:55:
[...]


Haha nou ik haak al af

Ja er zitten nogal wat haken en ogen aan als je niet goed oplet.

[BikkelZ]

Grumble iemand een idee voor een goede dedicated WordPress in Nederland? De hoster van mijn neef's site blijft maar zeuren, ik moet gewoon iemand hebben die die boel automatisch update en niet te allergisch loopt te doen van WordPress.

[wackmaniac]

Er is waarschijnlijk een reden dat ze er allergisch over doen

Je kan de website zelf automatisch laten updaten in Wordpress toch?

[Ryur]

ElkeBxl schreef op woensdag 20 april 2016 @ 14:57:
[...]


Ja er zitten nogal wat haken en ogen aan als je niet goed oplet.

Een van mijn lievelingstalen is LISP
En Clojure

[ Voor 3% gewijzigd door Ryur op 20-04-2016 15:08 ]

[TheNephilim]

BikkelZ schreef op woensdag 20 april 2016 @ 15:01:
Grumble iemand een idee voor een goede dedicated WordPress in Nederland? De hoster van mijn neef's site blijft maar zeuren, ik moet gewoon iemand hebben die die boel automatisch update en niet te allergisch loopt te doen van WordPress.

In Nederland heb je https://www.savvii.nl/. Zelf nog niet gebruikt, maar het ziet er allemaal wel goed uit en ook lees ik iets over 'automatische updates'.

Helaas bezigen ze vrij agressieve verkooptechnieken, waardoor ik dan weer snel een 'meh' gevoel krijg .

[hellum]

ZaZ schreef op woensdag 20 april 2016 @ 14:45:
rm -rf koppijn werkt niet

mv koppijn /dev/null al geprobeerd?

[Alex)]

umount /dev/koppijn

[ZaZ]

hellum schreef op woensdag 20 april 2016 @ 15:34:
[...]


mv koppijn /dev/null al geprobeerd?

Krijg ik een stack overflow

[zezke]

BikkelZ schreef op woensdag 20 april 2016 @ 15:01:
Grumble iemand een idee voor een goede dedicated WordPress in Nederland? De hoster van mijn neef's site blijft maar zeuren, ik moet gewoon iemand hebben die die boel automatisch update en niet te allergisch loopt te doen van WordPress.

Azure heeft ook een WordPress App Service tegenwoordig.

[.oisyn]

BikkelZ schreef op woensdag 20 april 2016 @ 15:01:
Grumble iemand een idee voor een goede dedicated WordPress in Nederland? De hoster van mijn neef's site blijft maar zeuren, ik moet gewoon iemand hebben die die boel automatisch update en niet te allergisch loopt te doen van WordPress.

Redenen genoeg om daar allergisch over te doen.

[Woy]

BikkelZ schreef op woensdag 20 april 2016 @ 15:01:
Grumble iemand een idee voor een goede dedicated WordPress in Nederland? De hoster van mijn neef's site blijft maar zeuren, ik moet gewoon iemand hebben die die boel automatisch update en niet te allergisch loopt te doen van WordPress.

Bij de meeste hosters heb je toch gewoon DirectAdmin/CPanel/Iets vergelijkbaars, en bij de application manager daarvan kan je toch gewoon aangeven dat hij automatisch updates uit moet rollen ( en eventueel eerst een backup maakt ).

[Tjolk]

BikkelZ schreef op woensdag 20 april 2016 @ 15:01:
Grumble iemand een idee voor een goede dedicated WordPress in Nederland? De hoster van mijn neef's site blijft maar zeuren, ik moet gewoon iemand hebben die die boel automatisch update en niet te allergisch loopt te doen van WordPress.

Wordpress bezorgt veel mensen rode bultjes hoor.
Maar als je een redelijk standaard installatie hebt, kun je toch gewoon de auto-updater van Wordpress zelf gebruiken? Die zit er al 2 jaar in ofzo meen ik.

[BikkelZ]

wackmaniac schreef op woensdag 20 april 2016 @ 15:02:
Er is waarschijnlijk een reden dat ze er allergisch over doen

Je kan de website zelf automatisch laten updaten in Wordpress toch?

Ja al een paar keer aan gezet maar er gebeurt steeds niks.

Bedankt voor de tips!

[ Voor 4% gewijzigd door BikkelZ op 20-04-2016 16:08 ]

[TheNephilim]

Ger schreef op woensdag 20 april 2016 @ 16:02:
[...]

Wordpress bezorgt veel mensen rode bultjes hoor.
Maar als je een redelijk standaard installatie hebt, kun je toch gewoon de auto-updater van Wordpress zelf gebruiken? Die zit er al 2 jaar in ofzo meen ik.

Dat is alleen voor de WordPress core, niet voor plugins. Het updaten van plugins is normaal gesproken niet meer moeite dan één keer klikken, maar je moet het wel bijhouden natuurlijk.

[wackmaniac]

Stukje kwaliteit dat Wordpress

[TheNephilim]

wackmaniac schreef op woensdag 20 april 2016 @ 16:10:
[afbeelding]

Stukje kwaliteit dat Wordpress

Hmmm, hier geen last van

[gekkie]

ElkeBxl schreef op woensdag 20 april 2016 @ 14:57:
[...]


Ja er zitten nogal wat haken en ogen aan als je niet goed oplet.

Zou van Rossum ooit met scheme geprutst hebben en er een haakjesallergie aan over gehouden hebben ?

[Geerrrt]

Playing cards for developers

[wackmaniac]

TheNephilim schreef op woensdag 20 april 2016 @ 16:18:
[...]


Hmmm, hier geen last van

[afbeelding]

Wat apart ja. Is een installatie met alleen Akismet en één theme als plugins...

[farlane]

GeertJam schreef op woensdag 20 april 2016 @ 16:23:
Playing cards for developers

Hihi er zit HTML bij.

[Hatsieflatsie]

gekkie schreef op woensdag 20 april 2016 @ 16:21:
[...]

Zou van Rossum ooit met scheme geprutst hebben en er een haakjesallergie aan over gehouden hebben ?

Rossum werkt in Emacs, de King of haakjes (Lisp). Dus dat zal wel meevallen. .

[Douweegbertje]

wackmaniac schreef op woensdag 20 april 2016 @ 16:10:
[afbeelding]

Stukje kwaliteit dat Wordpress

Stukje kwaliteit, jouw server instellingen.

[Hatsieflatsie]

Douweegbertje schreef op woensdag 20 april 2016 @ 20:20:
[...]


Stukje kwaliteit, jouw server instellingen.

Denk niet dat aan de server ligt. Die heeft namelijk niks met encodering te doen. Denk dat z'n tekst in de database opgeslagen is, en vanuit de database naar website verkeerde encodering (UTF-8) toegepast is, waardoor sommige karakters HTML entities krijgen.

[Voutloos]

Of t nou een .htaccess is, een default charset in PHP of een van de opties in structuur van of verbinding naar database, je zou t met beetje goede wil allemaal een server instelling kunnen noemen.

[wackmaniac]

Douweegbertje schreef op woensdag 20 april 2016 @ 20:20:
[...]


Stukje kwaliteit, jouw server instellingen.

Ongeacht of dat zo is, daar zou een pakket als Wordpress natuurlijk wel mee om moeten kunnen gaan

[Douweegbertje]

wackmaniac schreef op donderdag 21 april 2016 @ 08:51:
[...]


Ongeacht of dat zo is, daar zou een pakket als Wordpress natuurlijk wel mee om moeten kunnen gaan

Nja het is gewoon maar net wat je de schuld wilt geven. Ergens heb je iets met je encoding gedaan. Hoogstwaarschijnlijk zit je ergens met een db charset define die je eerst niet had, of gewoon niet erin moet staan.