Sociaal programmeren

[Verwijderd]

Ik zit sinds kort met een nieuwe collega op kantoor, ik heb tot heden toe altijd in mijn ééntje hier aan HTML, CSS, PHP, JS, etc.. bestanden gezeten. Mijn andere collega's werken niet in de webdevelopment. Nu we met z'n tweeën in de webdev zitten, vraag ik mij af of er mensen hier zijn die tips hebben wat betreft het samen werken? Dus op de volgende vragen zou ik graag jullie mening willen:

Werken aan een zelfde project, hoe ga je het verstandigste om met bestanden die je wellicht samen aanpast op een webserver?
Is er nog een bepaalde editor die het prettigst werkt in een twee-mans verband? (zelf werk ik nu al een tijdje rechtstreeks op onze test server via SSH in een VIM editor, maar mijn nieuwe collega werkt momenteel met Netbeans)
Nog bepaalde tips in deze "social coding" situatie?

Voor twee personen lijkt een compleet SVN of GIT een beetje overbodig. Daarnaast heb ik geen ervaring met GIT / SVN / Mercurial op Windows systemen (onze werkstations) en werk met GIT alleen over SSH op onze Unix servers. Daarom werken we nu in de vorm van "Heb jij nog wat aangepast op dat bestandje op de server? Anders haal ik hem even binnen".

Enige feedback zou perfect zijn, alvast vriendelijk bedankt!

[Arjan]

SVN is inderdaad overbodig, GIT daarentegen zeker niet!

Ik gebruik git ook voor al mijn éénpersoons projectjes, zowel op osx, linux en windows.
Het gemak van wijzigingen mergen en branchen zonder 'kosten'.. ik zou niet meer zonder willen

[PiepPiep]

Ik vind zelf SVN erg handig, zelfs in mijn eentje.
Als je regelmatig netjes commit en een keer iets verprutst of wilt weten hoelang een bug er al in zit kan je altijd makkelijk weer terug naar oudere versies.

/edit
Ik heb nog geen ervaringen met GIT moet ik toegeven.
Ik heb wel een keer gelezen dat je het eigenlijk niet met SVN mag vergelijken, alleen de reden is me nog niet helemaal duidelijk.

[ Voor 31% gewijzigd door PiepPiep op 18-01-2011 13:49 ]

[Woy]

Verwijderd schreef op dinsdag 18 januari 2011 @ 13:45:
Voor twee personen lijkt een compleet SVN of GIT een beetje overbodig. Daarnaast heb ik geen ervaring met GIT / SVN / Mercurial op Windows systemen (onze werkstations) en werk met GIT alleen over SSH op onze Unix servers. Daarom werken we nu in de vorm van "Heb jij nog wat aangepast op dat bestandje op de server? Anders haal ik hem even binnen".

Source control is zelfs niet overbodig als je in je eentje aan een project werkt! Dus gewoon lekker SVN/GIT/TFS/Mercurial/Whatever gaan gebruiken!

Zeker als je meerdere versies van je site/applicatie naast elkaar gaat draaien word source control onmisbaar. Hoe wil je anders snel terug kunnen rollen naar een bepaalde versie?

Verwijderd schreef op dinsdag 18 januari 2011 @ 13:45:
(zelf werk ik nu al een tijdje rechtstreeks op onze test server via SSH in een VIM editor, maar mijn nieuwe collega werkt momenteel met Netbeans)

Ook dat lijkt me niet bijzonder handig op het moment dat je samen wilt werken. Het is IMHO een stuk makkelijker om gewoon lokaal te ontwikkelen, je wijzigingen in te checken, en dan bijvoorbeeld elke dag de laatste versie deployen op de test-server. Op die manier heeft je collega er ook geen last van als jij tijdens het ontwikkelen per ongeluk wat sloopt. Zolang je het niet ingechecked hebt kun je gewoon lekker doorontwikkelen totdat het klaar is, en dan check je het in. Je zult natuurlijk nog steeds wel afspraken moeten maken zodat je niet tegelijk op het zelfde stuk code gaat werken, want dan ga je geheid in de problemen komen.

[ Voor 49% gewijzigd door Woy op 18-01-2011 13:58 ]

[Verwijderd]

We werken hier alleen wel met een beetje vreemde websites... Althans... Laat ik het even uitleggen:

Op onze test- zowel live server staat onder een systeem map de kern van Drupal, hier draaien vrijwel al onze websites uit. Wat betekend dat de meeste websites van ons allemaal uit grotendeels symlinks bestaat naar de kern. Alleen de configuratie bestanden, themes en site specifieke modules staan in een non-symlink map (voor de Drupal bekenden: /sites/domein.ext/...). Hierdoor is een site al bijna niet lokaal te testen geloof ik... Ik kan even niets verzinnen in ieder geval. Als iemand daar een slimme oplossing voor heeft, graag!

Edit: En daarnaast bestaat een Drupal website hoofdzakelijk in zijn MySQL-db... Hoe je deze makkelijk met je GIT repo kan bijhouden... lijkt me ook vrij lastig?

[ Voor 11% gewijzigd door Verwijderd op 18-01-2011 14:10 ]

[Woy]

Je kan de hele drupal omgeving toch ook gewoon lokaal installeren?

[Remus]

Verwijderd schreef op dinsdag 18 januari 2011 @ 13:45:
zelf werk ik nu al een tijdje rechtstreeks op onze test server via SSH in een VIM editor

Ik vind dat dus totaal not done en onprofessioneel zelfs al ben je alleen: dat betekent dat je nooit een geschiedenis hebt van de code, dat je test server de enige bron van de huidige stand van zaken is, en dat je je in allerlei bochten moet wringen om problemen in productie-versies op te lossen.

Gebruik altijd version control software (of dat nou Subversion, GIT of welke andere version control du jour), en gebruik een duidelijk omlijnde manier van releasen naar bijvoorbeeld een testomgeving (de testers of gebruikers die acceptatietests uitvoeren op de testomgeving zullen je ook dankbaar zijn).

[Nick_S]

Over SCM is er al genoeg gezegd, gebruik het!

Als jij je software niet lokaal kan testen, is er dan wel genoeg kennis/documentatie om een nieuwe testserver in te richten mocht dat nodig zijn? Of zijn jullie testserver/productieserver de enige platformen waar het zou kunnen draaien?

Lokaal draaien is wat mij betreft echt een must have, niet elke wijziging verantwoord een commit, je zit vaak genoeg wat dingen uit te testen.

Verder over "sociaal programmeren", hoe gaan jullie de taken verdelen? Werken jullie in projecten? Dan zou ik eens kijken naar Scrum of een dergelijke Agile methodiek. Zijn het meer losse taken, kijk dan eens naar Kanban.

In ieder geval prioriseren, weten van elkaar waar je mee bezig bent, en waar je elkaar kan helpen en inzichtelijk houden wat er allemaal nog gedaan moet worden.

[Nick_S]

Verwijderd schreef op dinsdag 18 januari 2011 @ 14:09:
...
Edit: En daarnaast bestaat een Drupal website hoofdzakelijk in zijn MySQL-db... Hoe je deze makkelijk met je GIT repo kan bijhouden... lijkt me ook vrij lastig?

Hoe migreer je deze van je testomgeving naar je liveomgeving? Ik neem aan dat je niet heel je liveomgeving overschrijft met je testomgeving. Dit migratietraject zal waarschijnlijk bestaan uit update database scripts en update/insert/remove data scripts. Deze kunnen prima in je SCM.

[Verwijderd]

Oké, SCM gebruiken is nu duidelijk, een must have. Momenteel gebruikte ik het alleen voor onze Drupal-Kern en deze draait op GitHub. Ik zou dus ook graag GIT willen gebruiken voor de SCM, aangezien ik hierin al branches, commits etc.. kan doen.

Maar nu zit ik nog met de volgende dingen (klink wellicht echt als een beginneling, maar daar kan ik even niets aan helpen. ):
1. Momenteel gebruiken we de Migration manager van Plesk om van de test omgeving naar de live omgeving te gaan. Ik zie even niet hoe dit in een SCM zou kunnen verwerkt worden?

2. Alle Symlinks gaan naar een dieper liggende map, als we de sites lokaal zouden testen in een windows omgeving dan zou de Unix bestandssysteem-link niet meer overéén komen en daarnaast bestaan de symlinksook niet in Windows-bestandsysteem geloof ik? Zouden we dan op onze test server twee verschillende accounts aan moeten maken om daar dan allebei in te kunnen werken en van daaruit de commits te doen naar de SCM?

[Verwijderd]

Hoe kunnen we het beste werken in de volgende opstelling:

1 x Plesk test-server
2 x Windows work stations.

We zouden graag als volgt willen werken:

- Beide een aparte test omgeving, deze test omgeving moet op een Unix omgeving staan (omdat anders de file permissions niet kloppen). Waar we naar kunnen FTP'en naar meerdere websites.
- Onze eigen repositories van die omgevingen maken die we kunnen pushen, pullen etc...
- Identieke databases per website, dat we dus geen settings.php aan hoeven te passen na een pull.
- Databases pushen en pullen bij de zelfde repo.
- De website kunnen benaderen via eigen subdomain, in mijn geval: "http://niels.domein.ext/".

We zijn hier een beetje het spoor bijster over hoe we dit het beste kunnen realiseren. Zouden we allebei een Unix systeem met daarop een webservice geïnstalleerd moeten hebben? Of is het mogelijk om van onze bestaande Unix systeem te werken? Dit laatste lijkt ons niet omdat je dan conflicterende database namen hebt.

Alvast weer bedankt!

[ Voor 4% gewijzigd door Verwijderd op 18-01-2011 15:51 ]

[Kalentum]

Verwijderd schreef op dinsdag 18 januari 2011 @ 15:50:
Hoe kunnen we het beste werken in de volgende opstelling:

1 x Plesk test-server
2 x Windows work stations.

We zouden graag als volgt willen werken:

- Beide een aparte test omgeving, deze test omgeving moet op een Unix omgeving staan (omdat anders de file permissions niet kloppen). Waar we naar kunnen FTP'en naar meerdere websites.
- Onze eigen repositories van die omgevingen maken die we kunnen pushen, pullen etc...
- Identieke databases per website, dat we dus geen settings.php aan hoeven te passen na een pull.
- Databases pushen en pullen bij de zelfde repo.
- De website kunnen benaderen via eigen subdomain, in mijn geval: "http://niels.domein.ext/".

We zijn hier een beetje het spoor bijster over hoe we dit het beste kunnen realiseren. Zouden we allebei een Unix systeem met daarop een webservice geïnstalleerd moeten hebben? Of is het mogelijk om van onze bestaande Unix systeem te werken? Dit laatste lijkt ons niet omdat je dan conflicterende database namen hebt.

Alvast weer bedankt!

Op die twee workstations kun je met VirtualBox of VMware een Linuxserver plaatsen. Ik heb dat zelf ook, met 256Mb geheugen, en dat werkt prima. Je hebt dan ook je eigen databaseserver zodat je je productie-instellingen gewoon kunt gebruiken. Je kan ook een hostnaam eraan koppelen die je op het lokale netwerk kan benaderen.

[Janoz]

Eigenlijk zou je niet op test moeten ontwikkelen en dit naar productie brengen. IMHO zou je op test je ((gebruikers)acceptatie)tests moeten doen. Ontwikkelen doe je op een ontwikkelomgeving. Wat jullie eigenlijk zouden moeten doen is dus 2 ontwikkelomgevingen erbij. Voor elke ontwikkelaar 1. Daarop kunnen jullie in principe doen wat jullie willen. Jullie aanpassingen gaan weer in je SCM en van daaruit gaat het naar test om te zien of de gebruiker er mee accoord is. Vervolgens gaat het naar productie.

[Standeman]

Wat ook erg handig is om indien je een SCM systeem hebt, om dagelijks elkaars commit's te bekijken. Zo zie je duidelijk waar de ander mee bezig is geweest, welke oplossingen er gekozen zijn en als je het niet begrijpt kan je direct vragen waarom er voor een bepaalde oplossing / fix is gekozen. Een soort van code-review zeg maar.

imo ideaal om op de hoogte te blijven en kost je 10 tot maximaal 30 minuten van je tijd.

[Zoijar]

Arjan schreef op dinsdag 18 januari 2011 @ 13:48:
SVN is inderdaad overbodig, GIT daarentegen zeker niet!

Wat is het voordeel van git boven svn? Ik gebruik altijd al svn, uit gewoonte eigenlijk. Is git beter?

[ZaZ]

Zoijar schreef op dinsdag 18 januari 2011 @ 16:16:
[...]

Wat is het voordeel van git boven svn? Ik gebruik altijd al svn, uit gewoonte eigenlijk. Is git beter?

Don't go there.
Ga maar eens zoeken op dit forum.

[Andre-85]

Zoijar schreef op dinsdag 18 januari 2011 @ 16:16:
[...]

Wat is het voordeel van git boven svn? Ik gebruik altijd al svn, uit gewoonte eigenlijk. Is git beter?

In een dergelijk klein team is er IMHO weinig tot geen verschil tussen SVN of Git (of een ander distributed version control systeem). Zolang er maar version control gebruikt wordt.

Een tool als ReviewBoard is erg plezierig om de eerder genoemde code reviews vorm te geven.

Standeman schreef op dinsdag 18 januari 2011 @ 16:10:
Wat ook erg handig is om indien je een SCM systeem hebt, om dagelijks elkaars commit's te bekijken. Zo zie je duidelijk waar de ander mee bezig is geweest, welke oplossingen er gekozen zijn en als je het niet begrijpt kan je direct vragen waarom er voor een bepaalde oplossing / fix is gekozen. Een soort van code-review zeg maar.

imo ideaal om op de hoogte te blijven en kost je 10 tot maximaal 30 minuten van je tijd.

Niet alleen om op de hoogte te blijven, maar vooral om een manier te hebben om een bepaald niveau van code qualiteit te borgen.

[Arjan]

ZaZ schreef op dinsdag 18 januari 2011 @ 16:23:
[...]

Don't go there.
Ga maar eens zoeken op dit forum.

Wat hij zegt

Mijn ervaring: als je van svn naar git gaat, is git raar en lastig te gebruiken, als je van git naar svn gaat dan moet je ineens weer allerlei dingen handmatig doen die eerst 'gewoon werkten'. Daarnaast heb je met git ook offline versiebeheer. Of iets van dit boeit hangt helemaal af van je persoonlijk wensen.

[Janoz]

@Zoijar:

Git is distributed en SVN niet. Distributed is nu de buzzbomshizzle dus SVN is nu het nieuwe kwaad.

[Hydra]

Verwijderd schreef op dinsdag 18 januari 2011 @ 13:45:
zelf werk ik nu al een tijdje rechtstreeks op onze test server via SSH in een VIM editor

En wat nu als je door een fuckup van jezelf een bestand verwijderd?

SVN gebruik ik ongeacht hoeveel mensen er aan een project werken. Ik commit dagelijks, dus ben nooit meer dan een dag kwijt.

[Verwijderd]

Arjan schreef op dinsdag 18 januari 2011 @ 13:48:
SVN is inderdaad overbodig, GIT daarentegen zeker niet!

I LOL'ed

[Herko_ter_Horst]

Altijd doen: SCM, build automation, continuous integration, pair programming.

Alleen die laatste is optioneel en dan nog alleen als je in je eentje bent

Nooit doen: rechtstreeks op de server/live omgeving werken.

[Woy]

Herko_ter_Horst schreef op dinsdag 18 januari 2011 @ 20:35:
pair programming.

Pair programming vind ik dan weer niet zo'n goed idee, want het is volgens mij nooit cost-effective. Het is natuurlijk wel een goed idee om regelmatig code reviews te doen.

[frickY]

Naast source control worden coding standards ook relevanter. Het is wel zo prettig als je beide conform dezelfde stijl werkt, zodat de code in zijn geheel leesbaar blijft.

[Herko_ter_Horst]

In mijn ervaring is pair programming (ook als je verder niets met Agile o.i.d. doet) wel cost-effective:

• je deelt automatisch kennis
• door 2 stel hersens kom je vaak tot betere oplossingen
• door 2 paar ogen komen er minder bugs in de code waardoor je sneller door test-fix cycles en code reviews heen loopt
• je bent naadloos elkaars vervanging bij afwezigheid/vakantie/ziekte

Al deze zaken besparen tijd en/of leiden tot betere kwaliteit code.

[aaajeetee]

Toen ik aangenomen werd bij het bedrijf waar ik nog steeds werk, was ik de 3e programmeur. We ontwikkelden toen direct op de server, met Zend Studio oid (ctrl+s = opgeslagen en direct geupload).

Inmiddels is het team uitgebreid naar 9 programmeurs en maken we gebruik van SVN (ong 3 kwart jaar nu). Ik wou dat we dat in het begin hadden gedaan (4 jaar geleden).

Mijn tip (zoals eigenlijk veel mensen hier zeggen): gebruik version control. Ik heb alleen ervaring met SVN, werkt goed (voor ons).

[Hydra]

aaajeetee schreef op dinsdag 18 januari 2011 @ 20:58:
Toen ik aangenomen werd bij het bedrijf waar ik nog steeds werk, was ik de 3e programmeur. We ontwikkelden toen direct op de server, met Zend Studio oid (ctrl+s = opgeslagen en direct geupload).

Naar productie?

[Woy]

Herko_ter_Horst schreef op dinsdag 18 januari 2011 @ 20:55:
In mijn ervaring is pair programming (ook als je verder niets met Agile o.i.d. doet) wel cost-effective:

• je deelt automatisch kennis
• door 2 stel hersens kom je vaak tot betere oplossingen
• door 2 paar ogen komen er minder bugs in de code waardoor je sneller door test-fix cycles en code reviews heen loopt
• je bent naadloos elkaars vervanging bij afwezigheid/vakantie/ziekte

Al deze zaken besparen tijd en/of leiden tot betere kwaliteit code.

Maar om cost-effective te zijn moet je productiviteit dus wel verdubbelen. Ik vraag me af of je dat daadwerkelijk haalt.

Af en toe is het wel fijn om even met z'n 2en naar een stukje code te kijken, maar volgens mij zou ik stapel gek worden als ik de hele dag met z'n tweeën naar hetzelfde scherm moet kijken.

[Verwijderd]

Kan dit topic niet naar een algemeen 'ontwikkel straat topic' getransformeerd worden? Hoewel de TS nu wel specifiek van aard is, denk ik dat het in abstracto voor heel veel mensen nuttig kan zijn... Een bespreking van source control, nightly builds et cetera. Zelfs als je alleen werkt zijn veel dingen goed toe te passen.

[Wilf]

Verwijderd schreef op dinsdag 18 januari 2011 @ 13:45:
Voor twee personen lijkt een compleet SVN of GIT een beetje overbodig.

Deze zin snap ik niet helemaal. Een compleet SVN..? Het is geen softwarepakket van 32 GB. SVN heb je binnen een kwartiertje up and running voor een MKB en kost nauwelijks resources. Je repository op de SBS knallen en draaien maar. Ik zie alleen maar voordelen aan SVN, zoals al eerder gezegd zelfs als je in je eentje werkt. GIT heb ik geen ervaring mee, SVN wel en als je je keurig aan de regels houdt tijdens het commiten (duidelijke logs schrijven van je werkzaamheden / veranderingen) is het een zegen als je met 2 of meer man werkt. Het eerste wat je leert als programmeur is documenteren zodat je na een half jaar stofhappen je eigen code nog begrijpt, SVN helpt daarbij op metaniveau.

[st0p]

Herko_ter_Horst schreef op dinsdag 18 januari 2011 @ 20:35:
pair programming

Even los van de vraag of het efficient is, ik zou knettergek worden als ik altijd met z'n tweeen moest programmeren. Zo af en toe samen naar een lastig probleem of een vage bug kijken? Prima. Maar niet 40 uur per week.

[Hydra]

st0p schreef op dinsdag 18 januari 2011 @ 22:34:
Even los van de vraag of het efficient is, ik zou knettergek worden als ik altijd met z'n tweeen moest programmeren. Zo af en toe samen naar een lastig probleem of een vage bug kijken? Prima. Maar niet 40 uur per week.

Ja, dat heb ik dus ook. Je zit enorm in elkaars personal space.

[PiepPiep]

Hoe het met andere svn clients zit weet ik niet, maar tortoisesvn kan zelfs zonder server, die maakt dan zelf op je eigen computer/netwerk schijf een map aan en gooit daar de zooi in.
Op die manier kan je helemaal simpel thuis in je eentje toch oudere versies van je code terug zien.

[aaajeetee]

Hydra schreef op dinsdag 18 januari 2011 @ 21:03:
[...]


Naar productie?

Ja dat was direct op de productieserver, iets anders was er niet. Inmiddels hebben we een lokale ontwikkelomgeving, een test, staging en build server. Voordat er nu iets in productie wordt gezet, gaat het door deze stadia/servers heen.

[Rmg]

Woy schreef op dinsdag 18 januari 2011 @ 21:29:
[...]

Maar om cost-effective te zijn moet je productiviteit dus wel verdubbelen. Ik vraag me af of je dat daadwerkelijk haalt.

Af en toe is het wel fijn om even met z'n 2en naar een stukje code te kijken, maar volgens mij zou ik stapel gek worden als ik de hele dag met z'n tweeën naar hetzelfde scherm moet kijken.

Naja cost-effective zijn hangt (soms wel) niet altijd af van de snelheid waarin code oplevert. Pair programming forceert wel meer om netjes en begrijpelijk te coden wat je kwaliteit weer verbetert. Wat dus je kwaliteit omhoog brengt en zo meer cost effective is

[Kettrick]

Hydra schreef op dinsdag 18 januari 2011 @ 23:10:
[...]


Ja, dat heb ik dus ook. Je zit enorm in elkaars personal space.

Dat maakt het ook effectief, ineens worden gmail.com, t.net en facebook.com een stuk minder bezocht .

Pair programming moet geen must zijn, maar er moet wel ruimte voor zijn. Ik kan gerust een paar uur naast een collega zitten met een lastig probleem. Ik ken bedrijven waar daar nogal moelijk over gedaan wordt, maar 40 uur per week, nee dank je

[Standeman]

Kettrick schreef op woensdag 19 januari 2011 @ 08:09:
[...]


Dat maakt het ook effectief, ineens worden gmail.com, t.net en facebook.com een stuk minder bezocht .

En je mag ook niet met twee personen op 1 account GoT-en

Pair programming moet geen must zijn, maar er moet wel ruimte voor zijn. Ik kan gerust een paar uur naast een collega zitten met een lastig probleem. Ik ken bedrijven waar daar nogal moelijk over gedaan wordt, maar 40 uur per week, nee dank je

^^ so true. Pair programming moet je doen wanneer het nodig is / toegevoegde waarde heeft. Als je bijv met een lastig en complex probleem bezig bent of een ad-hoc ontwerpje in code maakt.

[Verwijderd]

Okay, even terug naar mijn vraag.

Janoz schreef op dinsdag 18 januari 2011 @ 16:06:
Wat jullie eigenlijk zouden moeten doen is dus 2 ontwikkelomgevingen erbij. Voor elke ontwikkelaar 1.

Wat betreft twee fysieke ontwikkel servers per persoon word hier op kantoor een beetje een probleem. Ik verwacht dat ik dat hier bij mijn werkgevers er niet in ga krijgen. Een WAMP lokale server oid, is dat geen oplossing? Alleen krijg ik dan dus (geloof ik) problemen met mijn file modes? Daarnaast, heeft iemand er ervaring mee om GIT te draaien op een Windows bak? WAMP zou wel het probleem oplossen van twee of drie verschillende databases die conflictende namen gebruiken.

Ook vraag ik mij eigenlijk af of jullie ook allemaal (vooral in een 5+ ontwikkelaars kantoor omgeving) je eigen server hebben staan? Het lijkt mij zo overbodig... Wellicht dat de meeste van jullie op een Unix bak werken en daar lokaal op alle services draaien ofzo?

[Guldan]

Wat ook handig kan zijn is wanneer jullie samen werken aan hetzelfde product (of niet maakt eigenlijk niet uit) om 's ochtends een standup te houden waarin jullie bespreken wat er de vorige dag is gebeurd en wat je deze dag gaat doen. Het idee is een beetje gejat van Scrum dus dat betekent ook dat de standup niet heel lang mag duren.

Hierdoor weet de een precies wat de ander heeft gedaan/gaat doen en kan je ook bijvoorbeeld al vroeg aangegeven dat de een de ander kan helpen bij het oplossen van bepaalde problemen.

Nog even over de ontwikkelomgevingen. Je kan natuurlijk lokaal ontwikkelen maar zaken voor test/acceptatie op een andere omgeving zetten. Wanneer je ieder je eigen ontwikkel omgeving hebt is het natuurlijk wel zaak dat je sourcecontrol gebruikt zodat wanneer jullie beiden aan hetzelfde bestand werken deze gemakkelijk samengevoegd kan worden.

[ Voor 24% gewijzigd door Guldan op 19-01-2011 09:44 ]

[Gerco]

Verwijderd schreef op woensdag 19 januari 2011 @ 08:56:Wat betreft twee fysieke ontwikkel servers per persoon word hier op kantoor een beetje een probleem.

Niemand zei dat die servers fysiek moesten zijn, toch? Je kan prima virtueel een Linux servertje draaien met Apache en MySQL. Als je daar niet genoeg RAM voor hebt moet het niet zo moeilijk zijn om budget los te peuteren voor een reepje RAM van een paar tientjes.

Een WAMP lokale server oid, is dat geen oplossing? Alleen krijg ik dan dus (geloof ik) problemen met mijn file modes?

Dat hangt van je applicatie af. Windows heeft een heel ander permissiesysteem dan Linux standaard gebruikt, maar je kunt er minimaal hetzelfde mee (ik zou zeggen veel meer). Zo lang de applicatie zelf niet met de permissies gaat rommelen kun je alles precies zo instellen als je zelf wilt.

Daarnaast, heeft iemand er ervaring mee om GIT te draaien op een Windows bak?

Ik gebruik Git regelmatig op Windows, Linux en Mac OS X en naast wat issues met CRLF line endings is er weinig mis mee. Gewoon al je files met LF line endings opslaan en dat probleem is ook uit de wereld.

Ook vraag ik mij eigenlijk af of jullie ook allemaal (vooral in een 5+ ontwikkelaars kantoor omgeving) je eigen server hebben staan?

Dat varieert tussen lokaal een Linux VM draaien, Linux op de desktop draaien en mensen die liever een Mac gebruiken. In alle gevallen hebben ze een lokale omgeving waar ze op werken.

[Janoz]

Verwijderd schreef op woensdag 19 januari 2011 @ 08:56:
Wat betreft twee fysieke ontwikkel servers per persoon word hier op kantoor een beetje een probleem. Ik verwacht dat ik dat hier bij mijn werkgevers er niet in ga krijgen. Een WAMP lokale server oid, is dat geen oplossing? Alleen krijg ik dan dus (geloof ik) problemen met mijn file modes? Daarnaast, heeft iemand er ervaring mee om GIT te draaien op een Windows bak? WAMP zou wel het probleem oplossen van twee of drie verschillende databases die conflictende namen gebruiken.

Bij alle opdrachten waar ik de laatste tijd gezeten heb had ik lokaal een omgeving draaien. Eventueel een remote database waarop ik een eigen schema had. De applicaties waren dan wel zo te configureren dat ik ergens op mijn eigen pc een properties bestandje neer kon zetten met instellingen specifiek voor mijn omgeving.

Ook vraag ik mij eigenlijk af of jullie ook allemaal (vooral in een 5+ ontwikkelaars kantoor omgeving) je eigen server hebben staan? Het lijkt mij zo overbodig... Wellicht dat de meeste van jullie op een Unix bak werken en daar lokaal op alle services draaien ofzo?

Ik mocht hopen dat ik op linux werkte , maar een virtuele omgeving is zo neergezet mocht het nodig zijn.

[Woy]

Rmg schreef op woensdag 19 januari 2011 @ 07:58:
[...]
Naja cost-effective zijn hangt (soms wel) niet altijd af van de snelheid waarin code oplevert. Pair programming forceert wel meer om netjes en begrijpelijk te coden wat je kwaliteit weer verbetert. Wat dus je kwaliteit omhoog brengt en zo meer cost effective is

Zolang die extra netheid van code niet resulteert in extra productiviteit of een beter product heeft het voor het bedrijf geen waarde.

Ik geloof best wel dat je met z'n 2en iets betere code op kunt leveren en zo iets productiever kan zijn, maar nooit dat het genoeg oplevert om 2 maal zo veel mankracht te bekostigen.

Kettrick schreef op woensdag 19 januari 2011 @ 08:09:
[...]
Pair programming moet geen must zijn, maar er moet wel ruimte voor zijn. Ik kan gerust een paar uur naast een collega zitten met een lastig probleem. Ik ken bedrijven waar daar nogal moelijk over gedaan wordt, maar 40 uur per week, nee dank je

Daar ben ik het wel mee eens. Maar dat gebeurt bij de meeste bedrijven ook wel. Als ik een probleem heb, of niet weet wat de beste oplossing voor iets is, dan vraag ik er even een collega bij, en kijken we even een uurtje met z'n 2en naar de code. Zo gaat dat andersom ook. Maar ik zou niet structureel in een pair willen programmeren, daar zou ik ook gek van worden.

ontopic: Voor ontwikkelen is het wel noodzakelijk dat je je eigen omgeving hebt, maar inderdaad niet dat het een losse fysieke server/machine is. Je kan inderdaad lokaal gewoon een omgeving hebben draaien ( eventueel virtueel ), of op een server een omgeving per ontwikkelaar (kan eventueel ook virtueel). Zolang die omgevingen gewoon gescheiden zijn is dat geen enkel probleem.

[ Voor 11% gewijzigd door Woy op 19-01-2011 10:27 ]

[Janoz]

Pairprogramming is alleen nuttig wanneer je met een wat lastiger stukje bent. Denk aan het pinpointen van een nasty bug of wanneer er dingen voor het eerst gedaan moeten worden (en er dus eigenlijk een soort standaard oplossing gedestilleerd moet worden). Voor veel van het bulk werk vind ik het overbodig.

[Hydra]

aaajeetee schreef op woensdag 19 januari 2011 @ 07:35:
Ja dat was direct op de productieserver, iets anders was er niet. Inmiddels hebben we een lokale ontwikkelomgeving, een test, staging en build server. Voordat er nu iets in productie wordt gezet, gaat het door deze stadia/servers heen.

Holy crap, dat is toch bizar? Je maakt als developer continue typfouten. Ik vergeet regelmatig een ; of een = ofzo, en dat ging dan meteen live?

Ik heb ook bij zo'n prutswebdesign bedrijfje gewerkt waar men niet aan SC deed enzo, maar daar ontwikkelde ik tenminste nog op m'n eigen productie-like omgeving en maakte iedere keer een backup voordat ik iets uploadde, en ik vond hoe het daar ging al scary.

Kettrick schreef op woensdag 19 januari 2011 @ 08:09:
Dat maakt het ook effectief, ineens worden gmail.com, t.net en facebook.com een stuk minder bezocht .

Tja, soms moet je stoom af kunnen blazen. Ik denk dat iedereen wel eens gewerkt heeft binnen een keiharde deadline waarbij je 8 uur per dag of meer zat te coden. Dat hou je volgens mij niet vol als dat elke dag zo gaat. Vrijwel niemand is 8 uur per dag productief; ik heb een onderzoek gelezen dat een normaal mens ongeveer zo'n 3 uur per dag 'inspiratie' heeft en echt hard werkt en de rest van de tijd niet op 100% capaciteit werkt.

Pair programming moet geen must zijn, maar er moet wel ruimte voor zijn. Ik kan gerust een paar uur naast een collega zitten met een lastig probleem. Ik ken bedrijven waar daar nogal moelijk over gedaan wordt, maar 40 uur per week, nee dank je

Joh, dat is geen pair-programming maar elkaar gewoon helpen, dat doet iedereen lijkt me. Alleen al je code uit moeten leggen aan iemand anders (rubber duck debugging ) zorgt vaak al voor een doorbraak.

Verwijderd schreef op woensdag 19 januari 2011 @ 08:56:
Wat betreft twee fysieke ontwikkel servers per persoon word hier op kantoor een beetje een probleem. Ik verwacht dat ik dat hier bij mijn werkgevers er niet in ga krijgen. Een WAMP lokale server oid, is dat geen oplossing? Alleen krijg ik dan dus (geloof ik) problemen met mijn file modes? Daarnaast, heeft iemand er ervaring mee om GIT te draaien op een Windows bak? WAMP zou wel het probleem oplossen van twee of drie verschillende databases die conflictende namen gebruiken.

Waarom zou het perse een production-like server moeten zijn? Je kunt prima je eigen WAMP omgeving op je machine production-like inrichten lijkt me? Je ontwikkeld in PHP kennelijk dus dan is er van OS-specifieke code als 't goed is niet of nauwelijks sprake. Dus dan heb je je eigen Ontwikkel machine, een Test/Acceptatie machine, en Productie. En als het echt perse linux moet zijn kun je prima een VMware image op je eigen machine zetten.

[ Voor 21% gewijzigd door Hydra op 19-01-2011 11:06 ]

[Scr33x0r]

Ik wil hier wel even op inhaken.

Sinds een tijdje hebben we wat meer mensen op onze webdevelopment afdeling, nu hebben wij alleen een ander probleem. Wij doen voornamelijk SEM/SEO werkzaamheden en passen dus delen van de website van onze klanten aan.

Ook wij doen nu alles eerst lokaal waarna we het uploaden, maar daardoor kunnen we eigenlijk niet met z'n tweeen in 1 project.

Nu is SVN een leuke oplossing, maar op het moment dat onze klanten bestanden gaan aanpassen raakt het corrupt. De enige oplossing zou dan zijn om er nog een server tussen te hebben wat zeg maar de "nep"-productieserver is en die vervolgens alles laten uploaden naar de live-server..

Hoe zien jullie dit? Hebben jullie ervaring met dit soort dingen?

[Hydra]

Scr33x0r schreef op woensdag 19 januari 2011 @ 11:21:
Nu is SVN een leuke oplossing, maar op het moment dat onze klanten bestanden gaan aanpassen raakt het corrupt. De enige oplossing zou dan zijn om er nog een server tussen te hebben wat zeg maar de "nep"-productieserver is en die vervolgens alles laten uploaden naar de live-server..

Hoe zien jullie dit? Hebben jullie ervaring met dit soort dingen?

Ik snap niet waarom klanten zelf rechtstreeks bestanden aanpassen. Als je content != code. Klinkt alsof dat bij jullie niet / slecht gescheiden is. Content zit normaal in de database, niet in files.

[Voutloos]

@Scr33x0r Je moet gewoon *altijd* SVN (of whatever) gebruiken. Voordat je wilt releasen gooi je alle edits door derden er ook in, merge je dingen indien nodig en heb je alsnog alles onder controle.

(los van dat de scheiding dan wellicht inderdaad niet optimaal is)

[ Voor 14% gewijzigd door Voutloos op 19-01-2011 11:32 ]

[Scr33x0r]

Hydra schreef op woensdag 19 januari 2011 @ 11:29:
[...]


Ik snap niet waarom klanten zelf rechtstreeks bestanden aanpassen. Als je content != code. Klinkt alsof dat bij jullie niet / slecht gescheiden is. Content zit normaal in de database, niet in files.

Wij maken die websites niet zelf.. sommige zijn complete html sites, sommige mooie cms systemen en soms zelfs iets daartussen in.. Het probleem is dat wij niet een nieuwe website voor onze klanten maken, maar de website van onze klanten zoekmachinevriendelijker maken..

Vaak heeft de orginele webbouwer ook nog toegang en op het moment dat er bijvoorbeeld iets aangepast wordt, wordt hij weer ingeschakeld.. met alle gevolgen van dien, want dat wil wel eens zo'n 13 jarig buurjongetje zijn...

Voutloos schreef op woensdag 19 januari 2011 @ 11:31:
@Scr33x0r Je moet gewoon *altijd* SVN (of whatever) gebruiken. Voordat je wilt releasen gooi je alle edits door derden er ook in, merge je dingen indien nodig en heb je alsnog alles onder controle.

(los van dat de scheiding dan wellicht inderdaad niet optimaal is)

Het probleem is dat wij dus niet volledige tijd hebben om zo'n website met al zijn wijzigingen in de gaten te houden. Vaak hosten we het niet eens zelf. En dan met het wijzigen van code heb ik het niet alleen over echte webdevelopment zaken, maar ook over het aanpassen van title, meta, alt-tags, h1,h2 etc.. dus ook de content..

Onze pakketten zijn op uur-per-maand basis. Dus we doen enkele seo werkzaamheden elke maand. Dat begint bij 1,5 uur per maand en kan oplopen afhankelijk van wat de klant wil. Ik ben alleen al bezig om die wijzigingen te controleren en dan heb ik vervolgens nog een half uur van die maand om uberhaupt iets zinnigs te doen..

Waar een wordpress het mooi bijhoudt en je versie's terug kan gaan, heb je dat probleem dus wel met websites die volledig in HTML gebouwd zijn en waarbij de klant wel beter gevonden wil worden, maar geen geld hebben voor een nieuwe website (MKB'ers..)

[ Voor 45% gewijzigd door Scr33x0r op 19-01-2011 11:37 ]

[Hydra]

Scr33x0r schreef op woensdag 19 januari 2011 @ 11:33:
Het probleem is dat wij dus niet volledige tijd hebben om zo'n website met al zijn wijzigingen in de gaten te houden. Vaak hosten we het niet eens zelf. En dan met het wijzigen van code heb ik het niet alleen over echte webdevelopment zaken, maar ook over het aanpassen van title, meta, alt-tags, h1,h2 etc.. dus ook de content..

Onze pakketten zijn op uur-per-maand basis. Dus we doen enkele seo werkzaamheden elke maand. Dat begint bij 1,5 uur per maand en kan oplopen afhankelijk van wat de klant wil. Ik ben alleen al bezig om die wijzigingen te controleren en dan heb ik vervolgens nog een half uur van die maand om uberhaupt iets zinnigs te doen..

Waar een wordpress het mooi bijhoudt en je versie's terug kan gaan, heb je dat probleem dus wel met websites die volledig in HTML gebouwd zijn en waarbij de klant wel beter gevonden wil worden, maar geen geld hebben voor een nieuwe website (MKB'ers..)

Tja, je berekent die tijd die je kwijt bent door, of je dropt klanten die voor een dubbeltje op de eerste rang willen zitten. Ik zie het issue niet zo. Leg ze het probleem uit: of jullie mergen wijzigingen en berekenen dat door, of ze doen 't zelf en zijn dus zelf die tijd kwijt. Je moet gewoon duidelijke afspraken maken wie een site beheert en dus ook de verantwoordelijkheid heeft voor het mergen.

Ik weet verder niet wie er bij jullie voor sales verantwoordelijk is, maar met een mooi verhaal over hoe jullie "terug kunnen gaan in de tijd" en hoe de site "in de cloud opgeslagen is" (huhu) moet je toch hard kunnen maken dat het mergen en bijhouden van wijzigingen tijd en dus geld kost.

[Verwijderd]

[Sensuur]

[ Voor 92% gewijzigd door Verwijderd op 19-01-2011 12:03 ]

[Verwijderd]

Ik zie het probleem niet zo? Dit is exact gelijk alsof je zelf met 2 man op het project zou zitten, of die andere partij nou extern is of niet dan maakt dat niets uit. Het verschil is dat je 'zijn' commits handmatig zelf even moet doen, maar dat kan ook niet meer dan 5 minuten duren toch?

Stap 1: Syncen van jouw repo met de live omgeving
Stap 2: Uitvoeren werkzaamheden, met x man
Stap 3: Syncen van jouw repo met de live omgeving
Stap 4: Jouw wijzigingen in de live omgeving inbrengen (al dan niet via test/acceptatieomgeving)

[Hydra]

Verwijderd schreef op woensdag 19 januari 2011 @ 11:44:
Wat ik eigenlijk nog niet voorbij heb zien komen is een coding standaard!

Nou knul, vertel

Verwijderd schreef op woensdag 19 januari 2011 @ 11:44:
Ik zie het probleem niet zo? Dit is exact gelijk alsof je zelf met 2 man op het project zou zitten, of die andere partij nou extern is of niet dan maakt dat niets uit. Het verschil is dat je 'zijn' commits handmatig zelf even moet doen, maar dat kan ook niet meer dan 5 minuten duren toch?

Stap 1: Syncen van jouw repo met de live omgeving
Stap 2: Uitvoeren werkzaamheden, met x man
Stap 3: Syncen van jouw repo met de live omgeving
Stap 4: Jouw wijzigingen in de live omgeving inbrengen (al dan niet via test/acceptatieomgeving)

Inderdaad. Gewoon een kwestie van duidelijke afspraken maken. De huidige opzet is nog slechter, want als de 'gebruiker' wijzigingen doorvoert die je niet doorhebt overschrijf je die gewoon, en als het zo'n "we ontwikkelen op prod" type is, heeft 'ie misschien niet eens een lokale backup.

Nee, hop aan de SC, dat is juist uitermate geschikt voor dit soort 'projecten'.

[Scr33x0r]

Op zich zou dat inderdaad wel werken, maar wat nu als in die tussentijd de webhouwer van hun wat doet?

[Verwijderd]

[Sensuur]

[ Voor 115% gewijzigd door Verwijderd op 19-01-2011 12:03 ]

[Hydra]

Scr33x0r schreef op woensdag 19 januari 2011 @ 11:52:
Op zich zou dat inderdaad wel werken, maar wat nu als in die tussentijd de webhouwer van hun wat doet?

Die webbouwer moet geen meuk rechtstreeks naar productie uploaden maar dat OF zelf mergen, OF naar jullie sturen en door jullie laten mergen. Hij moet dus ook, al dan niet direct, SC gaan gebruiken.

Verwijderd schreef op woensdag 19 januari 2011 @ 11:54:
Serieus topic dit!

Jij komt er mee aanzetten, doe eens een voorzet?

Dat je met codingstandards werkt lijkt me verder een enorme nobrainer overigens, ook als je niet met meer mensen op 1 project werkt. Ieder serieus ontwikkelbedrijf heeft volgens mij wel een coding standard document waar je je aan hebt te conformeren.

Edit: Jouw manier van discussieren is dus maar een wikipedia definitie dumpen? Alsof mensen hier niet weten wat een coding style is?

[ Voor 7% gewijzigd door Hydra op 19-01-2011 11:58 ]

[Verwijderd]

Scr33x0r schreef op woensdag 19 januari 2011 @ 11:52:
Op zich zou dat inderdaad wel werken, maar wat nu als in die tussentijd de webhouwer van hun wat doet?

Daar is stap 3 dus voor

[Janoz]

Bijkomend voordeel is dat je zelf ook een timetrail heb van hoe de livesite er uit zag. Dat is erg handig als onderbouwing wanneer je meer tijd kwijt blijkt te zijn vanwege externe veranderingen. In je versiebeheer kun je dan keurig laten zien welke wijzigingen er live doorgevoerd waren en eventueel aangeven wat de impact van die wijziging was.

Het mooiste zou natuurlijk zijn wanneer je die synchronisatie automatisch dagelijks laat gebeuren en in een apparte branch bijhoudt. Deze branch kun je, bij wijzigingen, vervolgens naar je ontwikkelbranch mergen. Bij een release van jullie zijde zouden beide branches dan weer precies gelijk moeten zijn .

[aaajeetee]

Hydra schreef op woensdag 19 januari 2011 @ 11:03:
[...]


Holy crap, dat is toch bizar? Je maakt als developer continue typfouten. Ik vergeet regelmatig een ; of een = ofzo, en dat ging dan meteen live?

Ik heb ook bij zo'n prutswebdesign bedrijfje gewerkt waar men niet aan SC deed enzo, maar daar ontwikkelde ik tenminste nog op m'n eigen productie-like omgeving en maakte iedere keer een backup voordat ik iets uploadde, en ik vond hoe het daar ging al scary.

Toendertijd wist ik/wisten we niet veel beter. Ja zo nu en dan kwam er eens een fatal error op het scherm (door inderdaad een typfout oid). *oeps*
Achteraf gezien snap ik niet dat we ooit zo hebben kúnnen ontwikkelen, het gebruik van een (lokale) testserver en SC is vele malen makkelijker en levert minder fouten op. Inderdaad een "holy crap" moment

[Killemov]

Scr33x0r schreef op woensdag 19 januari 2011 @ 11:52:
Op zich zou dat inderdaad wel werken, maar wat nu als in die tussentijd de webhouwer van hun wat doet?

Blijkbaar werk je "samen" met een andere partij. Dan lijkt het me vrij logisch om de andere partij ook met je SVN, GIT of Bazaar systeem te laten werken.

[Verwijderd]

Oké, ik heb niet meer zo'n zin om het complete topic te gaan lezen aangezien het nogal is afgeweken van mijn eigenlijke vraag. Maar het is duidelijk wat jullie zeggen over het sociaal programmeren.

Nu heb ik nog een vraag naar aanleiding van heel dit topic, we zijn nu onderhand bezig met het opzetten van lokale virtual machines en ik heb zelf momenteel Ubuntu Server console draaiende. Ik heb ook Apache met wat virtual host tweaks, MySQL, PHPMyAdmin, vsftpd, PHP, etc. er op gezet. Nu werkt alles an sich wel, maar het toch gaat deze niet echt helemaal soepel. Ik loop telkens nog tegen dingen op zoals dat mijn FTP niet de juiste file permissies lekker wegzet, owner:group probleempjes, apache telkens moet aanpassen wat betreft virtual host config files, etc...

Nu vraag ik mij af of er geen totaal pakket beschikbaar is zoals een PLESK service? Ik zoek iets wat zelf meteen alles regelt wat betreft:
- MySQL databases aanmaken
- Virtual host optuigen
- Folder structuur aanmaken (het liefst met error/access logs in de folder van de virtual host)
- FTP users aanmaakt per website of gewoon lekker alles wegschrijft qua permissies en owner / group.

Iemand idee of er een gratis/opensource/iets is naast zo'n oplossing als PLESK en heeft daar ervaring mee?

[Lethalis]

Anders maak je een aparte user aan voor het live zetten van spul op webservers, etc?

Overigens heb ik wel vaker in kleine teams gewerkt (lees 2 personen ) en ook in die situaties bleek een source control system altijd onontbeerlijk.

[Gleighton]

Ik moet voor mijn opleiding af en toe wat programma'tjes uitpoepen met z'n tweeën, daarbij was een van de eerste dingen die we deden Git installeren op mijn server, want anders zit je de hele tijd aan de ander te zeuren of ie even de nieuwste versie naar je toe kan sturen. Zonder Git of een ander scm was het snel een zooitje geworden of waren er deadlines niet gehaald. Zelfs als ik in mijn eentje grotere opdrachten moet gaan maken is Git handig, zeker vanwege backups / revisions. Kan eigenlijk niet meer zonder dus.

[MacWolf]

Voor solo projectjes is overigens de combinatie Dropbox + Git super. Repository op Dropbox, kan je op ieder systeem (OS X, Windows, Linux) eenvoudig benaderen, want Dropbox wordt gemount alsof het een normale schijf is (althans in OS X). Tegelijkertijd heb je op die manier een remote backup.

[PiepPiep]

MacWolf schreef op dinsdag 25 januari 2011 @ 01:39:
Voor solo projectjes is overigens de combinatie Dropbox + Git super. Repository op Dropbox, kan je op ieder systeem (OS X, Windows, Linux) eenvoudig benaderen, want Dropbox wordt gemount alsof het een normale schijf is (althans in OS X). Tegelijkertijd heb je op die manier een remote backup.

Gaat dat goed met meerdere gebruikers? Of let je gewoon erg goed op dat je nooit met z'n 2en tegelijk commits doet en alles goed gesynchroniseerd is?
Het is in dit geval namelijk een andere schijf voor de verschillende mensen en werken locks op bestanden niet onderling.

[MacWolf]

PiepPiep schreef op dinsdag 25 januari 2011 @ 08:41:
[...]

Gaat dat goed met meerdere gebruikers? Of let je gewoon erg goed op dat je nooit met z'n 2en tegelijk commits doet en alles goed gesynchroniseerd is?
Het is in dit geval namelijk een andere schijf voor de verschillende mensen en werken locks op bestanden niet onderling.

Nee, met meerdere gebruikers is het niet ideaal, vanwege de problemen die je noemt. Je zou dan inderdaad de commits (of eigenlijk de pushes) moeten coördineren onder elkaar. Maar deze setup gebruik ik dan ook aleen voor solo projecten.