Eclipse naar Netbeans

Ooit gestart in DreamWeaver om daarna, omdat het cooler en handiger was, door te gaan naar Notepad2.  Tijdens de groei van PHP/HTML scripting naar Zend Framework development groeide echter de behoefte aan betere ondersteuning voor diverse zaken. Zo begonnen we met versie controle en wilden we ook meer overzicht over de verschillende bestanden en projecten. Onze behoefte een goede Integrated Development Enviroment (IDE) te gebruiken werd groter en groter.

Eclipse PDT
De afgelopen jaren werkten we met ons hele team in Eclipse. Een geweldig programma. Solide en prettig in gebruik. Oke, we zullen niet ontkennen dat we zo nu en dan flinke ruzie hadden met subclipse (voor de versiecontrole) maar meestal was dit onze eigen fout. Het had nou eenmaal een gebruiksaanwijzing als het ging om bestanden hernoemen etc. Verder niets dan lof. Iedere keer keken we vol spanning uit naar de nieuwe versie van Eclipse. Wat voor moois zou er toch weer in zitten, zou de interface sexier zijn geworden etc?

Eclipse naar Netbeans
Het leven was zo eenvoudig, iedereen was gelukkig met Eclipse en er was geen behoefte aan een nieuwe IDE. Tot één van onze collega’s Netbeans installeerden op zijn thuisomgeving om mee te werken. Al snel was hij enthousiast genoeg om het op kantoor te durven opnemen tegen de Eclipse-fans. Niet zonder succes. Inmiddels is er nog maar één iemand bij ons op kantoor die Eclipse gebruikt. De rest is over naar Netbeans.

Waarom Netbeans?
Netbeans heeft dezelfde roots als Eclipse dus de overstap voelt niet erg zwaar aan en vanaf dat moment is het al snel genieten van alle leuke dingen die Netbeans wel goed kan / doet (of in iedere geval doet lijken alsof het goed is) zoals;

  • Instant renaming van PHP namen, classes etc
  • Nagenoeg naadloze SVN integratie
  • Frisse stijl qua schermen en icoontjes
  • Prettige bestuurbaarheid van kleurschema’s
  • Slimme code completion en controle (in zowel PHP als o.a. JS, CSS, HTML)
  • Fijne kleurcodering voor gewijzigde code tov. actuele SVN etc

Samenwerken met Eclipse en Netbeans
Dit werkt prachtig samen. Bij projecten waar we met meerdere mensen aan werken merk je er niets van. Beide zit je gewoon te werken in je gewenste editor en alle data wordt via de SVN prima op lijn gehouden zonder problemen.

Het inladen van oude Eclipse projecten (altijd mijn grootste motivatie om niet over te stappen naar een andere editor) ging eigenlijk te eenvoudig. Gewoon “new project” -> “PHP application with existing sources” en dan even paar kleine configuratiezaken en klaar. Alles inclusief de SVN configuratie. Sterker nog; beide omgevingen werken eigenlijk best goed naast elkaar (als je echt gek wilt doen)

Netbeans grootste gemis?
Wij werken redelijk veel met externe tools om bijvoorbeeld Docblocks te genereren, PHPdocumentor aan te sturen en Doctrine models te genereren. Helaas is dit alles niet mogelijk in Netbeans. Vanuit Eclipse kunnen we deze externe tools aansturen met parameters die betrekking hebben op het actuele project zodat hij automatisch de juiste mappen en namen pakt. Zo lang we hiervoor geen oplossing hebben blijft dit een beetje spijtig. (werk nu met een .bat file die wat dingen doet maar is natuurlijk lapwerk)

Heb al wel zitten kijken naar de mogelijkheden om zelf een Plugin te maken voor Netbeans maar gezien de drukte zal dat er nog even niet van komen.

Versiebeheer met Subversion

Sinds de dag dat ik kennis maakte met versiebeheer was ik verkocht. Eerder hoorde ik hier en daar wel eens developers die het gebruikten maar omdat ik zelf niet wist hoe geweldig het was miste ik niets. Tegenwoordig gebruiken we in principe voor alles versiebeheer middels Subversion (SVN). Ongeacht het formaat van het project.

Wat is versiebeheer?
In basis is dit software waarmee wijzigingen in software of documenten kunnen worden bewaard. Alle wijzigingen worden als het waren gelogd in een soort geschiedenis. Wijzigingen krijgen een uniek nummer zodat snel te zien welke mutaties bij welke versie horen. Zeker in omgevingen waar je met meerdere gebruikers aan één project werkt is versiebeheer een uitkomst. Zo kun je eenvoudig de laatste mutaties van je collega’s binnenhalen als je met een project begint en kun je de door jou gemaakte mutaties snel verspreiden onder de rest van het team. Daarnaast biedt versiebeheer je de mogelijkheid om terug te kijken in de geschiedenis. Op welk moment is iets aangepast en door wie.

Subversion
Wij gebruiken op kantoor subversion voor ons versiebeheer. Subversion is eenvoudig te koppelen vanuit Eclipse of Netbeans en werkt redelijk eenvoudig. In het kort;

  1. We maken een nieuwe SVN repository (zeg maar een plaats waar de historie van bestanden bewaard wordt) aan op onze eigen SVN server
  2. We bepalen op de server welke gebruikers er zijn en welke rechten ze hebben op dit project
  3. Daarna gaan we naar onze IDE en koppelen het project aan de aangemaakte SVN
  4. Hierna kun je lokaal bepalen welke zaken je wel niet (settings van je IDE bijvoorbeeld) in de SVN repository wilt opslaan
  5. De laatste stap is de initiële import, hierbij importeer je als het ware het project in zijn huidige staat in de repository

Vanaf dit moment heb je een werkend project met SVN koppeling. Vanaf nu zal je IDE bij alle wijzigingen in bestanden en mappen met een icoontje of kleurtje aangeven dat deze gewijzigd is ten opzichte van de laatste SVN situatie. Je kunt dan je wijzigingen toevoegen aan de repository (commit), vernieuwen volgens de actuele repository (update) of terugdraaien naar de repository status (revert).

Samen werken
Bij iedere commit kun je opmerkingen meegeven. Zo zien je collega’s gelijk wat de reden was van de update mochten ze hem binnenhalen middels een update of later terugzien in de geschiedenis van het bestand. Als je toevallig tegelijk één bestand gewijzigd hebt dan heb je een conflict. Dit is vaak eenvoudig op te lossen door beide versies met elkaar samen te voegen. Je IDE is vaak zelf perfect in staat om te kijken of de wijzigingen elkaar overlappen of dat het twee verschillende delen van de code betreft.

Nog een voordeel van versiebeheer
Wij doen ook regelmatig projecten voor grotere organisaties waarbij het belangrijk is dat mutaties aan de code genoteerd worden. Zo kun je later eenvoudig terugzoeken op welk moment een bepaalde bug bijvoorbeeld is opgelost, door wie en welke bestanden daarmee gewijzigd zijn. Bij wijzigingen kan het handig zijn omdat je bijvoorbeeld een wijziging in een tabelstructuur die meerdere bestanden omvat in één keer terug kunt draaien alsof hij nooit heeft plaatstgevonden.

Branches en tags
Het is ook mogelijk verschillende versies van een project naast elkaar te hebben. Dit doe je met branches. Als je bijvoorbeeld een nieuwe functionaliteit gaat ontwikkelen die voorlopig nog los moet staan van het hoofdproject (wat ondertussen wel doorontwikkeld wordt) maar op termijn wel samengevoegd gaat worden dan maak je een branche aan. Dit is eigenlijk gewoon een virtuele kopie van de trunk (hoofdmap van het project) waarin afwijkingen ten opzichte van de core worden bijgehouden. Op een later moment kan dan beslist worden een branche te integreren in de trunk zodat dit dus de productieversie wordt. Als een branche voorlopig niet meer actief ontwikkeld wordt noemt men deze een tag. Er is namelijk verder geen verschil tussen een branche en een tag.