[Discussie] Ervaringen met buildtools

[zoepercavia]

Ik heb de laatste tijd een beetje lopen lezen in verschillende boeken (Applying UML and Patterns, Patterns of Enterprise Application Architecture, Extreme Programming Explained) en even de website van Extreme Programming (XP) (www.extremeprogramming.org) bekeken en heb daar behoorlijk wat nieuwe ideeen opgedaan. Hoewel ik zeker niet 'geloof' in Extreme Programming, denk ik wel dat 'agile' (lichte) methodes voor software ontwerp de toekomst zijn. Nou vroeg ik mij af, zijn er mensen die ervaring hebben met het toepassen van agile software methodologieen en wat zijn hun ervaringen daar mee?

Dan mijn tweede vraag. Een van de aspecten die mij wel aanspreekt van dit soort methodologieen is het aanbevelen van unit testing (JUnit/NUnit) en continuous integration, bv. CruiseControl (.Net) icm buildtools zoals (N)Ant. Het mooie is dat al deze tools freeware zijn, dus heb ik ze natuurlijk meteen gedownload. Echter bekroop mij snel het angstige gevoel dat dit alleen meer werk oplevert in de eerste projecten die je er mee doet. Wat zijn de ervaringen hier over dit soort tools? Wie gebruikt er bijvoorbeeld fanatiek Unit testing en wat is zijn mening daarover?

Nog wat links van de beschreven tools:
JUnit
NUnit (.Net)
Ant
NAnt (.Net)
CruiseControl
CruiseControl.NET

[ Voor 14% gewijzigd door zoepercavia op 17-06-2003 15:16 . Reden: linkjes toegevoegd ]

[Alarmnummer]

Ik zet al mijn java projecten tegenwoordig op mbv ANT (kan het dan ook zonder? ) En verder maak ik voor alle lastige code (lees neit alle code) junit-testen. Op dit moment ben ik bezig met een kleine taal in elkaar te zetten, en daar kan je perfect junit testen op uitvoeren. Ik heb de volgende dirs
semantic-valid
semantic-invalid
runtime-error
good-run

Bij iedere directory verwacht hij een foutmelding, een runtime exceptions, of een true. Verder bouw ik nu ook steeds meer unittests bij andere projecten.

[edit]
Ik zou verder niet meteen alles tegerlijkertijd proberen in te voeren. Probeer eerst ANT icm JUnit eens (ANT heb je echt zo onder de knie) en ga daarna verder uitbouwen. Dat doe ik ook en het bevalt goed, ik denk dat je anders te veel voor de kiezen gaat krijgen en de ware kracht van de tool niet zo snel zal ontdekken.

[ Voor 25% gewijzigd door Alarmnummer op 17-06-2003 15:23 ]

[Verwijderd]

Ik moet toegeven dat ik nooit JUnit tests schrijf, maar dat is ook vrij lastig omdat het niet makkelijk testbare classes zijn, er worden database aanroepen gedaan etc. Ik gebruik Ant persoonlijk eigenlijk alleen voor het backupen, eventueel rebuilden, maar met name deployment. Echt ideaal:

ant (voor builden, niet echt nodig icm met Eclipse)
ant deploy (alles wordt gejarred en geftp-ed naar de server waar de webapplicatie direct herladen wordt -> het werkt)
ant srcarch (backupped alles sources, jsps etc. en stopt ze in een zip met timestamp in de naam)
ant commitsrc (ftp-ed die backup naar de server)

Ik zou ook CVS kunnen overwegen, maar dit werkt vooralsnog perfect

[Alarmnummer]

Verwijderd schreef op 17 juni 2003 @ 15:27:
Ik moet toegeven dat ik nooit JUnit tests schrijf, maar dat is ook vrij lastig omdat het niet makkelijk testbare classes zijn, er worden database aanroepen gedaan etc.

Dat dacht ik in het begin ook. En aan bestaande enterprise code junit-code toe te gaan voegen is idd lastig, maar als je van het begin af aan er rekening mee houd dan zorg je er zelf wel voor dat je wel junit testen kan maken (eventueel met allerlei proxies ed.)

En voor db-junit testing zie : http://dbunit.sourceforge.net/

Ik zou ook CVS kunnen overwegen, maar dit werkt vooralsnog perfect

Bij mij gaat alles ook nog fijn naar een zipdrive of usbpendrive

[Verwijderd]

Alarmnummer schreef op 17 June 2003 @ 15:33:
Dat dacht ik in het begin ook. En aan bestaande enterprise code junit-code toe te gaan voegen is idd lastig, maar als je van het begin af aan er rekening mee houd dan zorg je er zelf wel voor dat je wel junit testen kan maken (eventueel met allerlei proxies ed.)

Daar gaat verschrikkelijk veel tijd in zitten vrees ik.

En voor db-junit testing zie : http://dbunit.sourceforge.net/

Hey, dat ziet er grappig uit, eens naar kijken.

Bij mij gaat alles ook nog fijn naar een zipdrive of usbpendrive

Idd, pendrives zijn inderdaad erg handig.

[oh,when?]

Hier gebruiken we idd CruiseControl icm met ANT, het grote voordeel is dat je altijd op een centrale plek een reliable build hebt. Je gevoel van 'meerwerk' kan ik begrijpen, daar zulke tools in het begin counter productief zullen zijn. Echter mijn ervaring is dat in projecten waar al gauw meerdere mensen opzitten en ook langere tijd duren, deze processen ( automated en continous builds, automated unit testing ) hun voordeel zullen bewijzen. Echter werk je maar in je eentje, dan betwijfel ik het grote nut van deze tools.

[Bobco]

zoepercavia schreef op 17 June 2003 @ 15:11:
Dan mijn tweede vraag. Een van de aspecten die mij wel aanspreekt van dit soort methodologieen is het aanbevelen van unit testing (JUnit/NUnit) en continuous integration, bv. CruiseControl (.Net) icm buildtools zoals (N)Ant. Het mooie is dat al deze tools freeware zijn, dus heb ik ze natuurlijk meteen gedownload. Echter bekroop mij snel het angstige gevoel dat dit alleen meer werk oplevert in de eerste projecten die je er mee doet. Wat zijn de ervaringen hier over dit soort tools? Wie gebruikt er bijvoorbeeld fanatiek Unit testing en wat is zijn mening daarover?

Hmm, in principe maak ik wel unit tests, maar dat gebruik ik voornamelijk om er zeker van te zijn dat ik niets stuk maak wat eerst wel werkte. Dit is natuurlijk niet helemaal zoals het hoort volgens XP, maar het werkt wel aardig. Je kunt in ieder geval nare verassingen voor een deel voorkomen. Bovendie zijn sommige opdrachtgevers erg gevoelig voor het idee dat de code constant getest wordt.

Voor wat betreft het gebruik van een build tool: een Java project zonder Ant kan eigenlijk niet meer. Ant heeft zoveel ingebouwde functionaliteit en werkt zo gemakkelijk dat je het jezelf erg moeilijk maakt als je het niet gebruikt.

Ant maakt het ook mogelijk om een ontwikkelaar zijn of haar favoriete IDE te laten gebruiken zonder de rest van het team meteen op te zadelen met de verplichting om dat ook te doen, puur omdat het hele build proces in de project definitie van die IDE zit ingebakken.

Ant is redelijk snel, uitermate flexibel en doet alles wat je van een build tool mag verwachten (en nog wel iets meer). Bovendien bieden de goede Java IDEs (ik noem IntelluiJ, mijn favoriet) goede integratiemogelijkheden met Ant.

Ik ben het met je eens dat de initiele opzet wat tijd kost, maar als je eenmaal een basis build file hebt kun je die heel erg snel hergebuiken voor andere projecten en dan begint het echte genieten.

[Bobco]

oh,when? schreef op 17 June 2003 @ 16:16:
Echter werk je maar in je eentje, dan betwijfel ik het grote nut van deze tools.

Ook als je alleen werkt heeft het zo zijn voordelen om bijvoorbeeld Ant te gebruiken. Ook kleine projecten hebben veel baat bij een gescheiden productie/test en ontwikkelomgeving en een goede build tool maakt het simpel om die omgevingen van elkaar te onderscheiden en software te maken die meteen werkt in elke omgeving.

Zelf gebruik ik dit bijvoorbeel om EAR files te maken die andere configuraties hebben voor de verschillende omgevingen. Erg makkelijk: de classes zijn hetzelfde, maar de configuratiefiles die meegaan zijn anders. Een keer opzetten en daarna loopt het als een zonnetje.

[oh,when?]

In de lijn van dit topic is dit trouwens een heel goed boek: Java Development with Ant

HTH

[Alarmnummer]

Ik heb hem zelf van het internet afgeplukt, maar het boek vind ik niet zo geweldig (eigelijk zoals alle boeken van Manning). Als je een boek wilt kopen over ANT, dan moet je denk ik even verder kijken.

[oh,when?]

offtopic:
is dat een persoonlijke aversie tegenover Manning of zijn er echt dingen waarvan je zegt: bullshit? Ik heb het een tijdje echt dagelijks gebruikt, en ook collega-devvers zijn er zeer over te spreken. Als ik de reviews zo even lees zijn er veel positieve geluiden te horen

gewoon nieuwsgierig trouwens

[tomato]

Alarmnummer schreef op 17 June 2003 @ 16:53:
Als je een boek wilt kopen over ANT, dan moet je denk ik even verder kijken.

Ik denk dat je er weinig zult vinden.

Ik heb het boek eigenlijk nooit goed bekeken (alleen de inhoudsopgave en daar leek absoluut niets mis mee), maar ik betwijfel een beetje of het het geld nou waard is. Je kunt veel met Ant, maar een heel boek erover gaat me wel wat ver. Veel mooie mogelijkheden zijn toch wel open deuren als je Ant een beetje kent.

[Alarmnummer]

oh,when? schreef op 17 juni 2003 @ 17:09:
[offtopic]is dat een persoonlijke aversie tegenover Manning of zijn er echt dingen waarvan je zegt: bullshit?

Ik heb een aantal boeken van hun bekeken en ik vind zo nogal rommelig. ANT is verder niet een waardeloos boek ofzo, maar ik vind zijn geld niet waard: Our price: $44.95 (dus 60 euro in nederland). Voor dat geld heb ik boeken staan die ik persoonlijk een stuk informatiever en waardevoller vind.

Verder hadden ze de font-size ook wel iets lagen kunnen zetten, en ze hadden die pagina`s met XML code ook wel achterwege kunnen laten (of goed moeten afdrukken) want ik vind dat ook weer zeer rommelig.

O`Reilly heeft trouwens ook een ANT boek: Ant The Definitive Guide

[ Voor 10% gewijzigd door Alarmnummer op 18-06-2003 14:36 ]

[oh,when?]

Alarmnummer schreef op 18 June 2003 @ 14:35:
[...]O`Reilly heeft trouwens ook een ANT boek: Ant The Definitive Guide

lees voor de grap de reviews maar eens op Amazon en op de Oreilly site zelf, lijkt niet zo heel erg positief...

[Alarmnummer]

*schaamt zich diep, heeft het boek eerlijk gezegd ook nog niet ingezien*

Maar ik red me goed met de zaken die ik daar op de site vind uitstekend. En om te verhinderen dat dit een ANT-boek topic gaat worden, zal ik er verder geen woorden meer aan vuil maken..

[zoepercavia]

Ant blijkt zijn meerwaarde dus wel te hebben. Maar misschien kan iemand wat meer vertellen over concreet gebruik in een omgeving waar meerdere personen aan 1 project werken? Is het bijvoorbeeld gebruikelijk om in de IDE dan Ant aan te roepen? En wie bepaalt wat er in de .build file staat?

Daarnaast vraag ik mij af in hoeverre NAnt (.Net versie) nuttig is icm Visual Studio. Ik heb al wat informatie gevonden om de project files van Visual Studio om te zetten naar .build files. Maar ik denk dat de meeste mensen in een team toch liever met de project explorer werken dan met .build files. Misschien is er iemand hier die werkt met NAnt en Visual Studio in een ontwikkelteam en zijn ervaringen kwijt wil?

Het klinkt namelijk allemaal veelbelovend, maar het blijft wel een beetje wazig.

BTW, zijn er ook mensen die continuous integration gebruiken?

[EfBe]

Je bent hippo.net vergeten, gebouwd door Jan Tielens uut Belgie! http://hipponet.sourceforge.net/

Ik vind zelf NAnt een verschrikkelijk stuk software. Het zal na 3 uur configgen best handig zijn, maar ik begrijp werkelijk niet dat men het gewoon klakkeloos als 'normaal' accepteert dat een tool als NAnt komt met nauwelijks docs en geen GUI editor, m.a.w. je moet dus met de hand die xml files gaan zitten bouwen of een voorbeeld gaan aanpassen, maar hoe je dat het beste opzet is een totale blur. Net als vroeger bij gnu make moet je zelf maar van alles uitvogelen. Dat is niet meer van deze tijd!

(ik had sneller een .cmd icm met nmake opgezet dan NAnt)

[ Voor 6% gewijzigd door EfBe op 18-06-2003 19:04 ]

[Verwijderd]

EfBe schreef op 18 June 2003 @ 19:01:
Ik vind zelf NAnt een verschrikkelijk stuk software. Het zal na 3 uur configgen best handig zijn, maar ik begrijp werkelijk niet dat men het gewoon klakkeloos als 'normaal' accepteert dat een tool als NAnt komt met nauwelijks docs en geen GUI editor, m.a.w. je moet dus met de hand die xml files gaan zitten bouwen of een voorbeeld gaan aanpassen, maar hoe je dat het beste opzet is een totale blur. Net als vroeger bij gnu make moet je zelf maar van alles uitvogelen. Dat is niet meer van deze tijd!

Ik vind het triest dat je alles wat je niet met je ogen dicht via een GUI kunt bedienen als verschrikkelijk stuk software bestempelt.

[ Voor 5% gewijzigd door Verwijderd op 18-06-2003 19:35 ]

[zoepercavia]

Ik vind zelf NAnt een verschrikkelijk stuk software

Ik vond zelf wel nuttig wat hier stond: http://samgentile.com/blog/posts/3145.aspx. Geeft wat tips om NAnt met Visual Studio te gebruiken. In de link naar Gordon's weblog staat een XSL stylesheet om VS project files om te zetten naar .build files, best handig.
Hippo.Net ziet er goed uit en heeft inderdaad wel een mooie GUI
Ik heb alleen nul ervaring met Visual Source Safe, dus ik moet maar even kijken hoe dat werkt. Het ondersteunt in ieder geval continuous integration, iets wat mij wel erg positief lijkt.

[mbravenboer]

EfBe: Net als vroeger bij gnu make moet je zelf maar van alles uitvogelen.

Hoezo vroeger? . Ik werk dagelijks met gnu make/autoconf/automak (niet dat ik daar altijd even blij van word ).

Overigens is Ant zeker niet magnifiek: er ontbreekt een duidelijk concept. Je wilt over het algemeen graag specificerende build files: het interesseert je niet hoe iets gemaakt, het interesseert je alleen wat er gemaakt wordt. Hoe iets gemaakt wordt, wil je daarvan het liefst scheiden.

Ant is hier gewoon slecht in: het is niet veel meer dan een wat duidelijkere script taal in een xml formaat. Shell scripting is verschrikkelijk (om even iemand te quoten: Unix shell scripting should die a slow and painful death), dus zo moeilijk is het niet om iets beters te maken. Veel van de kracht van Ant zit in de taken, die een soort standaard en abstractere interface bieden tot basis tools. Dat werkt op zich niet onaardig, maar zodra je tools wilt gebruiken waar geen Ant taken voor zijn, ben je aardig de pineut.

De Ant build files zijn ook absoluut niet specificerend: ze zijn eigenlijk volledig operationeel. Ze geven precies aan welke operaties er uitgevoerd moeten worden. Dit kan soms heel duidelijk zijn, maar zorgt ook voor enorme build files. Abstractie mogelijkheden in de taal zelf zijn er gewoon niet.

Ant (en klonen) zou je daarom misschien beter kunnen omschrijven als een zeer rigide script taal, voornamelijk qua syntax. Syntax is een groot probleem van shell scripting en door maar in een soort abstracte syntax (XML) te gaan werken los je dat op (min of meer).

[mbravenboer]

EfBe: geen GUI editor

GUIs zijn pas uit de tijd: applicaties die zich alleen richten op een eindgebruiker zijn passe . Applicaties die zich richten op andere applicaties, das het heden en de toekomst .

[EfBe]

Verwijderd schreef op 18 June 2003 @ 19:32:
Ik vind het triest dat je alles wat je niet met je ogen dicht via een GUI kunt bedienen als verschrikkelijk stuk software bestempelt.

Erm, je snapt geloof ik weinig van software development, is het wel? Wat moet software doen? Je helpen. Wat doet software die veel werk vereist? Je niet helpen. Wat is dat dus voor software? Slechte software.

Als je xml tags moet editen om van nant gebruik te kunnen maken, terwijl de helft van die tags niet is uitgelegd en dus ook het xml format niet, dan is het HARD WERKEN om dat goed te krijgen. Als je middels een gui dat wel in 100% van de gevallen correct kan in een fractie van de tijd, dan helpt de software je WEL, en is het dus WEL goede software.

Teveel mensen vinden het normaal dat een tool/applicatie nauwelijks te gebruiken is zonder veel tijd te investeren. "Dat is iets voor eindgebruikers". No offence, maar een developer is mbt buildtools OOK een eindgebruiker en elke seconde telt: iedere hindernis die een tool opwerpt, wat aangeeft dat de developer van die tool heeft er geen reet van begrepen heeft, is er 1 teveel.

Dus ja, ik bestempel ieder stukje software dat meer tijd kost dan het oplevert als prutswerk. Gelukkig heb ik een lang trackrecord dat me de basis geeft om dit soort uitspraken te doen.

[EfBe]

mbravenboer schreef op 18 June 2003 @ 23:50:
GUIs zijn pas uit de tijd: applicaties die zich alleen richten op een eindgebruiker zijn passe . Applicaties die zich richten op andere applicaties, das het heden en de toekomst .

Ik ben blij dat je het sarcastisch brengt

Ik vind een beetje tijd investeren niet erg. Ik ben een uur bezig geweest om nant te doorgronden, op zoek geweest naar die gui tools, maar die zitten in een library die GEEN files released maar waar je het direct uit de CVS moet trekken. No offence, maar ik heb geen cvs client, geen ssh of gerelateerde spullen op mn devbak. Erg veel moeite ook om dat even in een zip te distribueren.

Na een kwartier die example build gevallen te hebben bekeken en de nant build file maar te hebben omgehackt was ik het zo zat en heb een paar 5 regelige nmake files gemaakt die ik aanroep met nog kleinere .cmd files zodat ik mn .NET 1.0 en .NET 1.1 builds snel kan maken.

Waar ik me mateloos aan erger is de blinde steun die onbruikbare software nog altijd krijgt. Kennelijk is het 'prettig' oid om uberhaupt 2 seconden te moeten spenderen voor het formuleren van je build files terwijl je werkomgeving dat voor je hoort te doen (m.a.w.: build tools zouden volledig transparant moeten zijn).

Ik wil zelfs wel zover gaan dat ik een project file aan een compiler wil voeren en dat die compiler het verder maar uitzoekt. Waarom moet ik dat doen, is die compiler express dom gehouden oid? Hebben we niet computers uitgevonden om repeterend, geestdodend of bulkwerk ons uit handen te nemen? Jazekers. Echter menige developer is dat even vergeten.

Bravenboer, je zegt het in je andere posting mooi: 'het intereseert me niet hoe de build gedaan wordt'. Zo is dat. Je wilt als developer 1 ding: van je sources een programma maken. Dat je UBERHAUPT moet compileren is al een denkfout in het complete process, maar wellicht wordt daar iets aan gedaan in de komende jaren. Accepterende dat je moet compileren wil je in feite als developer na het intikken van de laatste regel op 'test' drukken of 'start' en dat de processen die de start van de code mogelijk maken op de achtergrond worden uitgevoerd.

_DAT_ is goede software, want dat helpt je. IEDERE andere software kost tijd en heeft het dus niet begrepen en de makers ervan al helemaal niet. Het concept van Hippo.net is dus een magistraal stukje denkwerk: de sourcebase wijzigt, ik bouw een nieuwe executable. Hoe je geen reet voor te doen!

Dus, developers:
Software moet makkelijk zijn en de mens helpen. Ook mij. Software die dat niet doet is prutsware en moet worden genegeerd..

Uitprinten, opplakken op je monitor en iedere dag 10 keer naar kijken.

[Verwijderd]

EfBe schreef op 19 juni 2003 @ 09:37:
[...]
Erm, je snapt geloof ik weinig van software development, is het wel? Wat moet software doen? Je helpen.

Ant helpt je niet?

Wat doet software die veel werk vereist? Je niet helpen.

Dat is wel heel kort door de bocht. Software die je meer tijd kost om aan de slag te kunnen dan dat het je oplevert, dat is software die je niet helpt.

Wat is dat dus voor software? Slechte software.

Dat heet software die nog verbeterd kan worden.

Als je xml tags moet editen om van nant gebruik te kunnen maken, terwijl de helft van die tags niet is uitgelegd en dus ook het xml format niet, dan is het HARD WERKEN om dat goed te krijgen.

Goed dat NAnt slecht gedocumenteerd is, ok dat is inderdaad slecht. Maar over het typen van een paar XML tags moet je niet gaan zeuren vind ik.

Als je middels een gui dat wel in 100% van de gevallen correct kan in een fractie van de tijd, dan helpt de software je WEL, en is het dus WEL goede software.

Nee, dan helpt de software je beter. Er is een verschil tussen niet ideale software en slechte software.

Teveel mensen vinden het normaal dat een tool/applicatie nauwelijks te gebruiken is zonder veel tijd te investeren. "Dat is iets voor eindgebruikers". No offence, maar een developer is mbt buildtools OOK een eindgebruiker en elke seconde telt: iedere hindernis die een tool opwerpt wat de developer van die tool heeft er geen reet van begrepen is er 1 teveel.

Het gaat mij er om dat jij alles wat je niet binnen die ene seconde aan de praat kunt krijgen bestempeld als slechte software. Zou jij NAnt nooit gebruiken omdat je misschien 1 keer een half uurtje nodig hebt om een buildfile in elkaar te zetten? Het gaat er toch om wat het oplevert uiteindelijk?

Dus ja, ik bestempel ieder stukje software dat meer tijd kost dan het oplevert als prutswerk. Gelukkig heb ik een lang trackrecord dat me de basis geeft om dit soort uitspraken te doen.

Oh, toch wel. Ik heb nieuws voor je, Ant (de java versie) heeft mij meer tijd opgeleverd dan dat ik er in gestoken heb en het is dus GEEN slechte software.

[Alarmnummer]

EfBe schreef op 19 June 2003 @ 09:37:
[...]

Erm, je snapt geloof ik weinig van software development, is het wel? Wat moet software doen? Je helpen. Wat doet software die veel werk vereist? Je niet helpen. Wat is dat dus voor software? Slechte software.

Als je xml tags moet editen om van nant gebruik te kunnen maken, terwijl de helft van die tags niet is uitgelegd en dus ook het xml format niet, dan is het HARD WERKEN om dat goed te krijgen. Als je middels een gui dat wel in 100% van de gevallen correct kan in een fractie van de tijd, dan helpt de software je WEL, en is het dus WEL goede software.

Teveel mensen vinden het normaal dat een tool/applicatie nauwelijks te gebruiken is zonder veel tijd te investeren. "Dat is iets voor eindgebruikers". No offence, maar een developer is mbt buildtools OOK een eindgebruiker en elke seconde telt: iedere hindernis die een tool opwerpt wat de developer van die tool heeft er geen reet van begrepen is er 1 teveel.

Dus ja, ik bestempel ieder stukje software dat meer tijd kost dan het oplevert als prutswerk. Gelukkig heb ik een lang trackrecord dat me de basis geeft om dit soort uitspraken te doen.

Ik moet eerlijk zijn en zeggen dat ik het toch erg fijn werken vind met ANT. Je bent misschien een tijdje bezig (werk er nu iets meer dan een jaar mee) en ik leer nog steeds nieuwe dingen erbij. Ik doe verder zaken met ANT die me echt handen vol met werk besparen.

-parsers genereren
-compileren
-files copieren
-junit testen
-jarren en signen
-ftp`en, backuppen en zippen.
en nog veel meer, en dat met maar 1 druk op de knop.

Een ander voordeel aan een non-gui based tool is dat je niet hoeft te wachten totdat de gui een keer een update krijgt als er nieuwe functionaliteit nodig is. Als ik een task nodig heb die niet standaard in ANT zit, dan haal ik even een anttask op en kan weer verder. Desnoods kan ik het zelf schrijven, dus je hebt volledige bewegingsvrijheid.

Als jij tevreden bent met een gui-aansturing van zo`n script dan kan ik je niet helemaal ongelijk geven, want in het begin is het makkelijker.

[ Voor 3% gewijzigd door Alarmnummer op 19-06-2003 09:56 ]

[mbravenboer]

EfBe: Ik ben blij dat je het sarcastisch brengt

Maar ik hoop dat de serieuze bedoeling wel over kwam . Wat ik met name bedoelde is dat er helaas ook teveel tools zijn die zich alleen op een eindgebruiker richten en daardoor vrijwel niet te gebruiken zijn vanuit andere applicatie. Ik denk dat je de stap naar de eindgebruiker moet scheiden van de kern van een tool. Dit zorgt ervoor dat de kern van het tooltje wellicht beter te gebruiken is in andere applicatie en dat er wellicht zelfs verschillende interfaces aangeboden kunnen worden voor een eindgebruiker.

No offence, maar ik heb geen cvs client, geen ssh of gerelateerde spullen op mn devbak.

Tje, dat noem je een devbak? .

[EfBe]

Verwijderd schreef op 19 juni 2003 @ 09:50:
Ant helpt je niet?

Laten we NAnt nemen, ik doe geen java.
Het zal ongetwijfeld je helpen, wanneer je er veel tijd in steekt. een gnu make file, wanneer eindelijk goed voor elkaar geprutst, zal je in the end ook helpen. Waar het om gaat is dat iedere seconde gespendeerd aan het in elkaar prutsen van die config files, verloren tijd is.

Dat is wel heel kort door de bocht. Software die je meer tijd kost om aan de slag te kunnen dan dat het je oplevert, dat is software die je niet helpt.

Nou, NAnt kostte mij erg veel tijd om een build file voor elkaar te krijgen want ik had geen docs en geen gui die me hielp. De vs.net tools die ik gebruiken kon waren niet bereikbaar. Na wat blogs te hebben gelezen waarbij ik middels xslt eventueel ook nog wat kon doen (yeah right) heb ik het fijn opgegeven met NAnt. Zo werkt het nu eenmaal. Ik heb wellicht bij elkaar opgeteld een jaar van mn leven verloren door met de meests verschrikkelijke software aller tijden moeten werken en daar pas ik voor. Het is 2003, vergeet dat niet, we zijn niet in 1990, toen een harddisk een schaars goed was. Software behoort je gewoon te helpen, zonder fouten. Software die je toestaat fouten te maken en dan na afloop gaat piepen "dat was niet zo slim he!", dat is prutsware. Weg ermee. Uberhaupt is het verschrikkelijk dat ik een ascii file moet hacken om een buildprocess goed te krijgen.

Waarom kan NAnt niet een vs.net sln file lezen? Of een sharpdevelop project file? DAT zou handig zijn, dan snap je waar het over gaat als NAnt developer. Als je from scratch een C# project begint in notepad of ultraedit, waarom kan NAnt dan niet een kale .build file genereren voor je, na het ingeven van wat parameters voor je project? Zodra je een file toevoegt aan je project dir, voegt nant hem toe aan de build file.

DAT is hoe het zou moeten gaan. Want in al die gevallen ben je klaar voor het build process wanneer je klaar bent met programmeren. Als je na het programmeren van je code nog een build file in elkaar moet programmeren heb je 1) kans op fouten in je build file (en dat wil je niet) en 2) kost het extra tijd om het te maken plus extra tijd om het format te leren.

Dat heet software die nog verbeterd kan worden.

Nee. Software die nog verbeterd kan worden maar nu belabberd is, is prutsware. Het had dan dus niet gereleased moeten worden.

Goed dat NAnt slecht gedocumenteerd is, ok dat is inderdaad slecht. Maar over het typen van een paar XML tags moet je niet gaan zeuren vind ik.

Ja dat doe ik wel. Het gaat nl. over het principe dat ik dat uberhaupt moet doen omdat de programmeur(s) van NAnt te lui zijn om die functionaliteit in te bouwen die ik hierboven heb geschetst. Er wordt NIET over nagedacht. Men denkt dat als je de rauwe functionaliteit zonder gebruikersinterface brengt, dat een developer het dan wel uitzoekt. *rrrt!* foute bingo. Developers zijn net zo goed mensen en hebben wel betere dingen te doen dan de dingen te doen die computers horen te doen.

Nee, dan helpt de software je beter. Er is een verschil tussen niet ideale software en slechte software.

Nee. Jouw gebrek aan besef wat slechte software is is gemeengoed in de IT en daarom is software ook zo bar slecht over het algemeen.

Het gaat mij er om dat jij alles wat je niet binnen die ene seconde aan de praat kunt krijgen bestempeld als slechte software. Zou jij NAnt nooit gebruiken omdat je misschien 1 keer een half uurtje nodig hebt om een buildfile in elkaar te zetten? Het gaat er toch om wat het oplevert uiteindelijk?

Ik gebruik NAnt van mn leven niet meer nee. Het gaat niet om die ene seconde, het gaat om het totale gebrek aan inzicht bij de makers van NAnt of bij vele andere build tools die we al jaren kennen, zoals gnu make en ander prutswerk. Je wilt niet weten hoeveel tijd ik kwijt ben geraakt eind jaren 80 begin 90 in gnu make omdat een afhankelijkheid niet goed stond, of de makefile uberhaupt niet werkte etc.

Sourcecode komt niet uit de lucht vallen. Men heeft niet ineens 30 files C# met weet ik hoeveel regels code.

Hier wat denkwerk dat de makers van NAnt volledig genegeerd hebben en daardoor is hun build tool dus belabberd. Het build proces zal wellicht goed gaan, maar het is om andere redenen dus niet te gebruiken:
1) Men heeft OF een project gebouwd in een IDE,
2) OF men heeft het project gestart met een andere build tool
3) OF men heeft het project gestart zonder build tool
4) OF men heeft het project gestart met NAnt.

Vanuit het POV van de nant GEBRUIKER, als NAnt wel goed was geweest:
1) is makkelijk. Je eet als NAnt de project file of solution file en kan meteen aan de slag met de build.
2) is ook makkelijk. Je eet de build file van de andere tool en kan meteen aan de slag.
3) is wat lastig, je kunt de developer leiden langs wat stappen zodat de developer makkelijk een build file kan aanmaken met zn huidige sourcecode.
4) men heeft al een build file.

Voor de developer(s) van NAnt is 1, 2 en 3 een ramp. Maar... en nu komt het... is dat het probleem van de developer die nant gebruikt? NEE! Omdat het lastig is, bouwen de developers van NAnt het maar niet in en is het mijn probleem. Ho! Ik gebruik juist een buildtool zodat ik niet zelf csc /t:library /out:bla.dll /o *.cs hoef ik te tikken en er zeker van ben dat ik de juiste references heb etc. 1, 2 en 3 bevatten alle info al, dus NAnt kan die info gebruiken voor zn eigen buildprocess.

DAN praat je over bruikbare tools. Nu is NAnt dat dus niet, want ik moet veel werk doen, meer dan met nmake, een file voor cs parameters en een .cmd file die het geheel aanroept met de juiste vsvars zodat ik de juiste compiler aanroep (wat nant niet eens kan).

Oh, toch wel. Ik heb nieuws voor je, Ant (de java versie) heeft mij meer tijd opgeleverd dan dat ik er in gestoken heb en het is dus GEEN slechte software.

Good for you. Ga dan nu eens nadenken over het feit dat Ant's buildfile al werd aangemaakt door je editor.

[EfBe]

mbravenboer schreef op 19 June 2003 @ 10:05:
Maar ik hoop dat de serieuze bedoeling wel over kwam . Wat ik met name bedoelde is dat er helaas ook teveel tools zijn die zich alleen op een eindgebruiker richten en daardoor vrijwel niet te gebruiken zijn vanuit andere applicatie. Ik denk dat je de stap naar de eindgebruiker moet scheiden van de kern van een tool. Dit zorgt ervoor dat de kern van het tooltje wellicht beter te gebruiken is in andere applicatie en dat er wellicht zelfs verschillende interfaces aangeboden kunnen worden voor een eindgebruiker.

Je doelt op het feit dat je de buildtools en andere tools, als een chain aan elkaar kunt rijgen zonder interface geneuzel? Tuurlijk is dat ok. Alleen dat groeit niet vanzelf aan elkaar! Iedere C++ programmeur zal het je kunnen vertellen dat de dag dat hij zn 1e compile deed in een echte C++ IDE dat hij niet een makefile hoefde aan te maken, want de IDE had dat al gedaan, en zonder fouten, hij een gevoel had van "heee. dit is handig!". Nee dat is niet handig, dat is normaal, althans dat zou normaal moeten zijn. Daarvoor gebruik je tools.

NAnt zal dus wat mij betreft best met die xml file mogen blijven werken, alleen hoe ik kom tot die xml file, daar wil ik geen gezeik over, immers dat kost MIJ tijd want die developers van NAnt hebben verzuimd mij dat werk uit handen te nemen terwijl ik JUIST daarom een buildtool gebruik! (anders kan ik net zogoed die parameters voor die compiler even op de commandline of in een .cmd file prutsen).

Tje, dat noem je een devbak? .

Een productieve devbak zelfs

[Verwijderd]

EfBe schreef op 19 June 2003 @ 10:15:
[...]
Laten we NAnt nemen, ik doe geen java.

Nee, laten we het over Ant hebben, ik heb NAnt slechts kort bekeken.

Het zal ongetwijfeld je helpen, wanneer je er veel tijd in steekt. een gnu make file, wanneer eindelijk goed voor elkaar geprutst, zal je in the end ook helpen. Waar het om gaat is dat iedere seconde gespendeerd aan het in elkaar prutsen van die config files, verloren tijd is.

Uiteraard.

Nou, NAnt kostte mij erg veel tijd om een build file voor elkaar te krijgen want ik had geen docs en geen gui die me hielp. De vs.net tools die ik gebruiken kon waren niet bereikbaar. Na wat blogs te hebben gelezen waarbij ik middels xslt eventueel ook nog wat kon doen (yeah right) heb ik het fijn opgegeven met NAnt.

Ok, ik ken NAnt niet echt en dat het niet zo goed gedocumenteerd is als het originele Ant, daar kan ik niet over meepraten.

Software behoort je gewoon te helpen, zonder fouten. Software die je toestaat fouten te maken en dan na afloop gaat piepen "dat was niet zo slim he!", dat is prutsware.

Ehm Ik zie niet wat dit met deze buildtools te maken heeft? Door het gewoon inkloppen van XML kun je fouten maken bedoel je? Ok, in dit geval is dat inderdaad onnodig, een GUI om die XML files te genereren zou handig zijn. Overigens laat iedere programmeer IDE toe code te schrijven die fout is en komt ook met meldingen als "dat is niet zo slim he" (alhoewel at compile time), dus die IDE's zijn ook prutsware?

[...]
Nee. Jouw gebrek aan besef wat slechte software is is gemeengoed in de IT en daarom is software ook zo bar slecht over het algemeen.

Denk jij überhaupt wel eens na voor je iets zegt? Of gooi je er alles gewoon maar uit? Met je elite gedrag, gatverdamme

Maar het zal me verder ook een rotzorg zijn, ik ben blij, jij bent blij. Laten we dat vooral zo houden.

[Bobco]

zoepercavia schreef op 18 June 2003 @ 18:09:
Ant blijkt zijn meerwaarde dus wel te hebben. Maar misschien kan iemand wat meer vertellen over concreet gebruik in een omgeving waar meerdere personen aan 1 project werken? Is het bijvoorbeeld gebruikelijk om in de IDE dan Ant aan te roepen? En wie bepaalt wat er in de .build file staat?

Wij gebruiken het in combinatie met IntelliJ, dat een heel behoorlijke integratie met Ant kent. De build file is gewoon een van de items in de project repository in CVS of VSS en in principe gelden daar dezelfde regels voor als alle andere source elementen.

Over het algemeen heeft elke organisatie die al wat langer met Ant werkt een soort van template voor een standaard build file, is mijn verwachting. Door dit te gebuiken is voor iedereen direct duidelijk hoe het project georganiseerd is en wat je in welke directory terug kunt vinden.

Je kunt natuurlijk op verschillende manieren werken. Zelf werk ik nog wel eens offline, dus ik wil gewoon lokaal mijn projecten kunnen builden. Je kunt ook kiezen voor een centrale build die wordt gedaan op vaste tijden, heb ik zelf geen ervaring mee.

[whoami]

Verwijderd schreef op 19 June 2003 @ 10:31:
[...]

Denk jij überhaupt wel eens na voor je iets zegt? Of gooi je er alles gewoon maar uit? Met je elite gedrag, gatverdamme

Maar het zal me verder ook een rotzorg zijn, ik ben blij, jij bent blij. Laten we dat vooral zo houden.

Ergens vind ik wel dat EfBe gelijk heeft hoor. Ik zou ook geen zin hebben om eerst in de config-files enzo te gaan prutsen vooraleer je iets werkends krijgt zoals je het wilt.

[Verwijderd]

whoami schreef op 19 juni 2003 @ 10:54:
[...]
Ergens vind ik wel dat EfBe gelijk heeft hoor. Ik zou ook geen zin hebben om eerst in de config-files enzo te gaan prutsen vooraleer je iets werkends krijgt zoals je het wilt.

Ik zeg ook helemaal niet dat we het niet eens kunnen worden, maar de manier van "discussiëren" die de heer Bouma hanteert is dusdanig dat ik, en er zijn meer, denk van zout toch even een heel eind op.

[whoami]

Verwijderd schreef op 19 June 2003 @ 10:57:
[...]

Ik zeg ook helemaal niet dat we het niet eens kunnen worden, maar de manier van "discussiëren" die de heer Bouma hanteert is dusdanig dat ik, en er zijn meer, denk van zout toch even een heel eind op.

Nouja, sommigen nemen het zo op, anderen kunnen het relativeren. So what.

ontopic nu maar weer

[EfBe]

Verwijderd schreef op 19 June 2003 @ 10:31:
Ehm Ik zie niet wat dit met deze buildtools te maken heeft? Door het gewoon inkloppen van XML kun je fouten maken bedoel je? Ok, in dit geval is dat inderdaad onnodig, een GUI om die XML files te genereren zou handig zijn. Overigens laat iedere programmeer IDE toe code te schrijven die fout is en komt ook met meldingen als "dat is niet zo slim he" (alhoewel at compile time), dus die IDE's zijn ook prutsware?

Het concept is vrij triest idd, als je op compile time er nog eens mee komt. Tegenwoordig zijn IDEs vrij slim dat ze at tiktime al met errormeldingen komen. Waar ik in het algemeen op doelde, en dat is ook van toepassing op nant o.a. is dat je met een ascii editor een file moet aanpassen waar je dus niet alleen syntactische fouten kunt maken, maar vooral semantische fouten, dus dat je files vergeet in je project, een reference vergeet, je build process niet goed schedult etc. Je maakt mij niet wijs dat je dat altijd in de 1e keer goed doet. Wat dus tijd kost en die tijd is t.a.t. weggegooide tijd.

Denk jij überhaupt wel eens na voor je iets zegt? Of gooi je er alles gewoon maar uit? Met je elite gedrag, gatverdamme
Maar het zal me verder ook een rotzorg zijn, ik ben blij, jij bent blij. Laten we dat vooral zo houden.

Waarom is het elitair gedrag als ik zeg dat het gebrek aan besef dat software t.a.t. zo veel mogelijk drempels moet weghalen en je tot in den treure moet helpen, vrij treurig is?

Ik vind het juist vrij 'elitair' dat er nog altijd vrij denigrerend over GUI's wordt gesproken in de development wereld, terwijl GUI's je juist de tijd kunnen besparen die je verprutst met het verbeteren van tik en config fouten.

Als je je voelt aangesproken dan is dat jammer, ik erger me gewoon aan de houding die ik bij veel mensen zie: "leuk tooltje, nuttig!", terwijl je er meer tijd aan kwijt bent dan nodig want de tool is rampzalig opgezet en mist essentiele interfaces, wizards en bruikbare functionaliteit.

Ooit bij nagedacht dat deze discussie over buildtools eigenlijk te bezopen voor woorden is? Waarom zijn die dingen uberhaupt nodig? En als ze al nodig zijn, waarom vermoeien ze mij met complexe configuraties waarbij ik als developer veelal de 1e paar keer de mist in ga en bij grotere projecten bekans een specialist moet inhuren om het goed te krijgen of zelf veel tijd moet gaan steken in het onderhouden van die files?

Exact hetzelfde met installers. (dit is niet off topic, de analogie is eender). Je hebt bv Wise. Er zijn dus 'wise scripters', dat zijn mensen die specialist zijn in het bouwen van intelligente wise scripts. Je moet dan niet denken: "goh, dat is handig, zo'n wise installer", maar je moet denken:"wat een crap installer, je hebt een specialist nodig voor de scripts". Een installer voer je een project file uit je IDE en er rolt een installer uit. (of je voert hem een build file en er rolt een installer uit). Dat moet met 1 druk op de knop kunnen en wel ZONDER de investering van tijd en dus geld aan het opzetten daarvan.

De enige juiste build tool is de buildtool die je niet ziet. Die is dus OF onderdeel van je compiler (of de compiler is onderdeel van de build tool) OF onderdeel vanje editor/IDE. Het bouwen van softwar is al complex genoeg. Door complexe config files te introduceren wordt dat proces er niet gemakkelijker op, in tegendeel. Het wordt alleen wel nog altijd in stand gehouden door een of andere vorm van fetisjisme dat vraagt om kreupele software, als je het mij vraagt om het gevoel te hebben met iets complex bezig te zijn.

Zodra een buildtool totaal onzichtbaar is en compilatie van sourcecode iets irrelevants is geworden in het bouw proces van software, dan zijn we op de goede weg. Het blijven hameren op het feit dat onnodig complexe software fout is is dus een must. Als dat 'elitair' wordt gevonden of een voorbeeld van 'ik weet het beter'-gedrag, c'est la vie. Feit is wel dat het onvermijdelijk is. Over 20 jaar zit jij geen textfiles meer te tikken voor de gemiddelde applicatie, maar klik je hem in elkaar. Dat heet vooruitgang.

[EfBe]

Verwijderd schreef op 19 June 2003 @ 10:57:
Ik zeg ook helemaal niet dat we het niet eens kunnen worden, maar de manier van "discussiëren" die de heer Bouma hanteert is dusdanig dat ik, en er zijn meer, denk van zout toch even een heel eind op.

Krijgen we dat weer.

"If you can't stand the heat, get out of the freakin' kitchen." - R. Dennis

M.a.w.: dit is een discussie over buildtools en men babbelt wat over het nut van die dingen. Mag ik dan aanvoeren dat buildtools eigenlijk overbodig zijn? Ik bedoel, link jij je javacode zelf? Je verwacht toch dat de compiler die handel linkt? Ik heb nog ld statements in mn make files zitten prutsen. Je kon daar veel tijd mee winnen. ALS je dat goed deed, tenminste.

Zolang men niet beseft dat build tools dingen zijn die transparant moeten worden geintegreerd in hetgeen je de software mee maakt, blijft men op een niveau steken waardoor we nooit verder komen. Geen hond (behalve wellicht de unix C programmeurs) linkt nog zelf zn sofware, dat doet de compiler. Zo vanzelfsprekend is het voor o.a. jou. Waarom is het dan niet zo vanzelfsprekend als iemand zegt dat hij het maar raar vindt dat je makefiles en andere crap met de hand moet gaan zitten maken?

Ik vind het ook een zeer triest punt dat vs.net bv niet een makefile kan genereren voor C# projects. Hij kan (kon iig in vc6) dat wel voor C++. Die dingen maak je niet met de hand, die dingen zijn het gevolg van iets.

[Verwijderd]

EfBe schreef op 19 June 2003 @ 11:03:
Waar ik in het algemeen op doelde, en dat is ook van toepassing op nant o.a. is dat je met een ascii editor een file moet aanpassen waar je dus niet alleen syntactische fouten kunt maken, maar vooral semantische fouten, dus dat je files vergeet in je project, een reference vergeet, je build process niet goed schedult etc. Je maakt mij niet wijs dat je dat altijd in de 1e keer goed doet. Wat dus tijd kost en die tijd is t.a.t. weggegooide tijd.

Kun je die semantische fouten niet maken in bijvoorbeeld Visual Studio? Daar is het toch net zo goed mogelijk een assembly vergeten te referen bijvoorbeeld? Je zult waarschijnlijk niet zo snel een bestand vergeten mee te compileren, want zal zal neem ik aan automatisch geregeld worden (1 dll/exe per project?)

[...]
Waarom is het elitair gedrag als ik zeg dat het gebrek aan besef dat software t.a.t. zo veel mogelijk drempels moet weghalen en je tot in den treure moet helpen, vrij treurig is?

Geloof je zelf dat dat is waar ik over viel? Mijn probleem is dat jij het persoonlijk maakt door iets te zeggen dat op mij over kwam als "jij bent de reden waarom software zo bar slecht is over het algemeen." Wat verwacht je dan, dat ik je in de armen vlieg en je vraag hoe ik net zo kan worden zoals jij, die in ieder geval weet hoe het wel moet? Ik krijg bij meerdere van je posts zo sterk het idee dat jij het idee hebt te denk dat je weet hoe het zit, en anderen dat, hoe ranzig hard dan ook, duidelijk te maken. Het is een kwestie van fatsoen, of je het nu tegen een tweedejaars student informatica hebt of tegen Bill Gates, er zijn dingen die je wel en niet zegt.

Ik vind het juist vrij 'elitair' dat er nog altijd vrij denigrerend over GUI's wordt gesproken in de development wereld, terwijl GUI's je juist de tijd kunnen besparen die je verprutst met het verbeteren van tik en config fouten.

Dat is vaak blindheid inderdaad. Een GUI mag niet altijd de oplossing zijn, maar vaak maakt het het leven een stuk makkelijker.

Als je je voelt aangesproken dan is dat jammer, ik erger me gewoon aan de houding die ik bij veel mensen zie: "leuk tooltje, nuttig!", terwijl je er meer tijd aan kwijt bent dan nodig want de tool is rampzalig opgezet en mist essentiele interfaces, wizards en bruikbare functionaliteit.

Dat zeg ik niet. Ik bekeen Ant, zag dat het mij tijd zou besparen en ben het dus gaan gebruiken. Het bespaart mij tijd. Ik gebruik het niet omdat "het een leuk tooltje is". Als er betere, eventuele GUI oplossingen zijn, dan zou ik die liever gebruiken. Je bent tevreden met wat je hebt, tot je iets beters hebt gevonden en dat is er voor mij, als java developer, bij mijn weten nog niet.

Ooit bij nagedacht dat deze discussie over buildtools eigenlijk te bezopen voor woorden is? Waarom zijn die dingen uberhaupt nodig? En als ze al nodig zijn, waarom vermoeien ze mij met complexe configuraties waarbij ik als developer veelal de 1e paar keer de mist in ga en bij grotere projecten bekans een specialist moet inhuren om het goed te krijgen of zelf veel tijd moet gaan steken in het onderhouden van die files?

Denk jij dat alle informatie die je in zo'n file stopt overbodig is? Hoe moet een compiler weten welke references nodig zijn? In ieder geval de java compiler maakt een groot deel van de oude buildtools al onnodig (de C# compiler ook?) door in "main class" te kijken of alle daar gebruikte classes te vinden zijn, zo niet dan zoekt hij de .java file erbij en compileert die ook. In principe zijn buildtools daarvoor niet echt meer nodig. Maar in ieder geval mijn gebruik van Ant is heel anders. Ik gebruik het voor het ftp naar de server, het archiveren van sourcecode etc. Dat zijn dingen die duidelijk buiten de taak van een compiler vallen en of je zo'n tool een buildtool wilt noemen of niet, ik vind ze handig.

[EfBe]

Verwijderd schreef op 19 juni 2003 @ 11:40:
Kun je die semantische fouten niet maken in bijvoorbeeld Visual Studio? Daar is het toch net zo goed mogelijk een assembly vergeten te referen bijvoorbeeld? Je zult waarschijnlijk niet zo snel een bestand vergeten mee te compileren, want zal zal neem ik aan automatisch geregeld worden (1 dll/exe per project?)

1) waaruit het project bestaat wordt gecompileerd. Is prima keuze. De volgorde wordt automatisch goed gedaan, files waar ik naar refereer in dezelfde solution worden bv eerst gecompileerd.
2) het is inderdaad triest dat wanneer je compileert dat hij gaat gillen dat er een reference mist. Ik zeg ook niet dat vs.net in dat opzicht goed is. bij 1) echter wint de IDE het van de handgemaakte files-etende buildtool. Vs.net zou automatisch een reference moeten toevoegen als ik een naar een known type refereer waar geen reference naar staat (maar bv wel een using / imports directive)

Geloof je zelf dat dat is waar ik over viel? Mijn probleem is dat jij het persoonlijk maakt door iets te zeggen dat op mij over kwam als "jij bent de reden waarom software zo bar slecht is over het algemeen."

Je leest er teveel in, of je projecteert het dan teveel op jezelf. Ik bedoelde dat de denkwijze die jij aan de dag legde in jouw posting een van de redenen is dat software nog altijd veelal erbarmelijk slecht is. Dat betekent niet automatisch dat jij slechte sofware maakt. Ik ageerde alleen tegen de manier van denken, die ik erg bekrompen vind. Dat mag dan weer als denigrerend worden opgevat, je kunt ook redeneren van: "wellicht is het idd bekrompen, ik ga anders denken".

Wat verwacht je dan, dat ik je in de armen vlieg en je vraag hoe ik net zo kan worden zoals jij, die in ieder geval weet hoe het wel moet? Ik krijg bij meerdere van je posts zo sterk het idee dat jij het idee hebt te denk dat je weet hoe het zit, en anderen dat, hoe ranzig hard dan ook, duidelijk te maken. Het is een kwestie van fatsoen, of je het nu tegen een tweedejaars student informatica hebt of tegen Bill Gates, er zijn dingen die je wel en niet zegt.

Sorry, maar ik heb op het gebied van software development nogal een scherpe mening. Dat sommigen die niet delen is tot daaraantoe, maar ik vind het wel bespottelijk worden als je je mening (beargumenteerd, want ik heb argumenten genoemd, alternatieven aangedragen etc.) niet mag ventileren want een of ander persoon neemt er aanstoot aan want die persoon denkt ANDERS. Jij vindt kennelijk dat wat ik zeg niet spoort. Het is een vrij land. Je zou ook andersom kunnen redeneren: waarom heeft die gekke FB die mening? Waarom zou hij na 16 jaar software bouwen tot de conclusie zijn gekomen dat in die 16 jaar er weinig is veranderd en dat dat best wel triest is? (sterker, de assembler die ik in 1989 gebruikte was gebruikersvriendelijker dan NAnt en andere buildtools bijelkaar.)

[...]
Denk jij dat alle informatie die je in zo'n file stopt overbodig is? Hoe moet een compiler weten welke references nodig zijn? In ieder geval de java compiler maakt een groot deel van de oude buildtools al onnodig (de C# compiler ook?) door in "main class" te kijken of alle daar gebruikte classes te vinden zijn, zo niet dan zoekt hij de .java file erbij en compileert die ook. In principe zijn buildtools daarvoor niet echt meer nodig.

De C# compiler heeft de handicap dat de filename niet een relatie hoeft te hebben met de class die erin zit. Maar references erbij zoeken is dus voor een compiler echt erg simpel. In de sourcefiles staan nl namespace includes. En als je full names gebruikt (dus namespaces uitschrijft) kun je ook als compiler daar de references vandaan halen. Blijft over wat compiler settings en welke sources, plus daarnaast de sequence hoe je meerdere projects tegelijk build in de juiste volgorde. Wie zoekt dat uit? Jij ? Dat kan een computer toch veel beter: sneller en zonder fouten.

Maar in ieder geval mijn gebruik van Ant is heel anders. Ik gebruik het voor het ftp naar de server, het archiveren van sourcecode etc. Dat zijn dingen die duidelijk buiten de taak van een compiler vallen en of je zo'n tool een buildtool wilt noemen of niet, ik vind ze handig.

Ik zeg ook niet dat die taken niet bestaan. Ik zeg alleen dat wanneer je zo'n tooltje wilt gaan gebruiken, dat gebruik niet een boek moet vereisen over die tool of een bak met tijd. Als jij tijdens een build automatisch ook deployment taken wilt uitvoeren, prima. Maar het opzetten van die taken moet makkelijk zijn en waar mogelijk worden opgezet mbv beschikbare informatie, iets wat nu totaal wordt genegeerd en dat is (IMHO) puur uit luiheid aan de kant van de toolbouwers, plus de gebruikers vinden het 'normaal'.

[Verwijderd]

Ik zal me ook maar eens met de discussie gaan bemoeien. We gebruiken op mijn werk namelijk ook ANT. Er wordt hier heel veel gesproken over het zelf linken van je eigen code. Dit is mijn inziens niet eens het belangrijkste punt van buildtools. Zoals Alarmnummer al in het begin aangaf, is het niet het compileren het belangrijkst wat je buildtool, maar wat er allemaal verder nog bij komt kijken.

In onze buildfiles, die overigens eerst gebruikt werden vanuit JBuilder en nu vanuit Eclipse, is het compileren maar een heel klein gedeelte. Om maar eens een aantal kleine zaken te noemen:

- XSl transformaties
- Code generaties
- XML validaties
- maken van jar's, war's en ear's
- deployen naar appserver
- uitvoeren JUnit testen
- uitvoeren Cactus testen

en ga zo maar door. Het voordeel van ANT gebruiken is dat dit alles continue gerunt kan worden vanaf onze build machine. We hebben een 'nightly' full build en een half uurlijkse icremental build. Allemaal vanaf dezelfde buildfiles die we ook nu in Eclipse gebruiken. Door Ant zijn we dus niet meer afhankelijk van een IDE om onze build te kunnen draaien.

Ik ben het er best mee eens dat een buildfile in elkaar kloppen niet het makkelijkste is, maar je hoeft ook niet in een keer heel je buildfile te hebben. Je begint met alleen compileren en het maken van een jar. Groeit je project, dan groeit je buildfile. Ik zie het probleem niet.

Integratie van IDE's met buildtools kan inderdaad verbeteren. Maar ik werk persoonlijk liever rechtstreeks in de xml (met codecompletion van Eclipse) dan dat ik een GUI tool gebruik waar ik niet weet wat er uit komt rollen.

Dus, ANT is makkelijk, Ant helpt mij, en is dus geen prutsware dat genegeerd moet worden.


Tja, of het feit dat we over 20 jaar applicaties in elkaar klikken en geen textfiles meer editten, zien we dan wel weer. Maar ik heb liever dat het buildprocess niet onzichtbaar is, zodat ik tenminste weet wat er gebeurd, en dat ik de problemen die ontstaat op kan lossen.

[Verwijderd]

EfBe schreef op 19 juni 2003 @ 11:56:
Sorry, maar ik heb op het gebied van software development nogal een scherpe mening. Dat sommigen die niet delen is tot daaraantoe, maar ik vind het wel bespottelijk worden als je je mening (beargumenteerd, want ik heb argumenten genoemd, alternatieven aangedragen etc.) niet mag ventileren want een of ander persoon neemt er aanstoot aan want die persoon denkt ANDERS. Jij vindt kennelijk dat wat ik zeg niet spoort. Het is een vrij land. Je zou ook andersom kunnen redeneren: waarom heeft die gekke FB die mening? Waarom zou hij na 16 jaar software bouwen tot de conclusie zijn gekomen dat in die 16 jaar er weinig is veranderd en dat dat best wel triest is? (sterker, de assembler die ik in 1989 gebruikte was gebruikersvriendelijker dan NAnt en andere buildtools bijelkaar.)

Ik denk niet dat we inhoudelijk er verschrikkelijk anders over denken, maar daar ging het mij niet om. Het probleem is helemaal niet inhoudelijk, of je nu beargumenteerd zegt dat "mijn slag informatici" zorgen voor slechte software, of zonder argumenten het komt nooit vrolijk aan, of je het nu zo bedoelde of niet, ik werd er niet blij van. Dat is de reden van mijn reactie.

De C# compiler heeft de handicap dat de filename niet een relatie hoeft te hebben met de class die erin zit. Maar references erbij zoeken is dus voor een compiler echt erg simpel. In de sourcefiles staan nl namespace includes. En als je full names gebruikt (dus namespaces uitschrijft) kun je ook als compiler daar de references vandaan halen.

.NET zou daar wat stricter in moeten zijn, idd, 1 class per file en classname overeen laten komen met de filename, net als in Java. Als je dan inderdaad ook de dll filenames vaststeld ben je al een heel eind.

[...]
Ik zeg ook niet dat die taken niet bestaan. Ik zeg alleen dat wanneer je zo'n tooltje wilt gaan gebruiken, dat gebruik niet een boek moet vereisen over die tool of een bak met tijd. Als jij tijdens een build automatisch ook deployment taken wilt uitvoeren, prima. Maar het opzetten van die taken moet makkelijk zijn en waar mogelijk worden opgezet mbv beschikbare informatie, iets wat nu totaal wordt genegeerd en dat is (IMHO) puur uit luiheid aan de kant van de toolbouwers, plus de gebruikers vinden het 'normaal'.

Maar jij stelt eigenlijk dat we de huidige tools moete boycotten, alleen maar omdat ze niet zo handig in het gebruik zijn als had gekunt. Ookal leveren ze wel wat op? Is dat niet wat extremistisch?

[EfBe]

Maar jij stelt eigenlijk dat we de huidige tools moete boycotten, alleen maar omdat ze niet zo handig in het gebruik zijn als had gekunt. Ookal leveren ze wel wat op? Is dat niet wat extremistisch?

Waarom? Iedereen moet maar gebruiken wat hij/zij denkt dat goed voor hem/haar is. Ik hou in dit geval mensen alleen een spiegel voor dat wat ze gebruiken niet optimaal is. Ik gebruik een IDE, ik tik code, en als ik klaar ben ram ik op cntrl-shift-B (jaja, kan ook andere toets zijn) en mijn solution build. daar heb ik dus 0.0 tijd in gestoken maar het gaat wel altijd goed, dat verwacht ik ook van die IDE.

Dat is gemak.

Nu, die buildtools doen meer dan alleen compileren. Prachtig, maar die power komt er alleen uit als je er veel tijd in steekt. Dat is erg jammer, men zou dat veel makkelijker moeten maken. Zolang men echter niet protesteert gebeurt dat ook niet. VS.NET schiet bv ook nog veel te kort: ik kan nu wel post-build steps aangeven, maar dat is maar weer erg brak gedaan, het kan veel beter en het MOET ook veel beter, anders zitten we over 16 jaar nog steeds op amateuristische wijze middels batch files onze software te bouwen, en dat lijkt me geen goed signaal aan kopers van die software: als je zelf al niet in staat bent om jezelf te automatiseren, waarom zou je dan wel in staat zijn om een andere te automatiseren?

[Verwijderd]

Ik gebruik een IDE, ik tik code, en als ik klaar ben ram ik op cntrl-shift-B (jaja, kan ook andere toets zijn) en mijn solution build. daar heb ik dus 0.0 tijd in gestoken maar het gaat wel altijd goed, dat verwacht ik ook van die IDE.

Ik doe zelfs dat niet. Eclipse compiled terwijl je typt. Maar dan nog heb ik iets nodig wat gegeneerd moet worden dan is CTRL-ALT-F10 (run last external tool). Dat is gemak en dat is ook Ant.

als je zelf al niet in staat bent om jezelf te automatiseren, waarom zou je dan wel in staat zijn om een andere te automatiseren?

Maar ant draait toch juist om te automatiseren? Heel ons build process is juist geautomatiseerd door middel van Ant.

[EfBe]

Verwijderd schreef op 19 June 2003 @ 13:09:
Ik doe zelfs dat niet. Eclipse compiled terwijl je typt. Maar dan nog heb ik iets nodig wat gegeneerd moet worden dan is CTRL-ALT-F10 (run last external tool). Dat is gemak en dat is ook Ant.

Als Eclipse een ant build file genereert, dan heeft eclipse het wel begrepen. Of als ant (ik ken de specs van ant niet) een eclipse project file kan begrijpen, dan is dat ook goed. Het gaat erom datje geen extra werk doet voor wat je eigenlijk 'for free' zou moeten krijgen, immers daarvoor heb je die ide tenslotte

Maar ant draait toch juist om te automatiseren? Heel ons build process is juist geautomatiseerd door middel van Ant.

Ja, maar hoe is dat gekomen? Groeide die ant file aan een boom of heb je die zelf gebouwd? Het gaat om het opzetten ervan, en dat kan stukken beter.

[Verwijderd]

Als Eclipse een ant build file genereert, dan heeft eclipse het wel begrepen. Of als ant (ik ken de specs van ant niet) een eclipse project file kan begrijpen, dan is dat ook goed

Er is wel een task voor ant die een eclipse project file inleest en daarvan het classpath en de sourcedirectories uit haalt. Maar het genereren van een complete Ant file zit er niet in. Ik denk niet dat je door het gebruik van Ant extra werk aan het doen bent (ok, mischien het opzetten van het classpath en de source directories, maar daar was die plugin voor:) ). Ik wil al die xml transformaties, code generaties, distributie, test etc zaken niet in mijn editor definieren. Dat doe ik direct in Ant en is dus ook geen dubbel werk.
Bij het overgaan naar een andere IDE neem je je ant build file mee, dus het extra werk wat je dan in die nieuwe IDE zou moeten doen krijg je nu dus 'for free', omdat je build IDE onafhankelijk is.

Ja, maar hoe is dat gekomen? Groeide die ant file aan een boom of heb je die zelf gebouwd? Het gaat om het opzetten ervan, en dat kan stukken beter.

Ik zie nog steeds niet precies de moeilijkheid in van het opzetten van een ant build. Ik heb meer moeite gehad om alles in Eclipse goed te krijgen dan het maken van de compile targets in ant.
Je kunt eigenlijk wel zeggen dat die ant file langzaam groeide. Als we een stuk nieuwe funcitonaliet of nieuwe testen (bijv. cactus) toevoegden, voegden we een stukje aan de buildfile toe. Of we dat nu in een IDE toevoegen (wat toen iig niet kon) of in de buildfile kost evenveel/weinig moeite.

[Bobco]

EfBe schreef op 19 June 2003 @ 13:26:
[...]
Als Eclipse een ant build file genereert, dan heeft eclipse het wel begrepen. Of als ant (ik ken de specs van ant niet) een eclipse project file kan begrijpen, dan is dat ook goed. Het gaat erom datje geen extra werk doet voor wat je eigenlijk 'for free' zou moeten krijgen, immers daarvoor heb je die ide tenslotte

[edit: gedeeltelijke echo van wat Sosume hierboven zegt]

Hmm, een ander voordeel van tools als Ant is juist dat je niet gebonden bent aan een bepaalde IDE. In principe kan elk teamlid zijn eigen favoriete omgeving gebruiken terwijl alle centrale zaken worden afgehandeld door Ant. Er zijn bedrijven die blijkbaar zo werken.

Volledige integratie tussen een IDE en een build/deply tool hooft om mij niet zo nodig. Ant heeft bijvoorbeeld de mogelijkheid om een log bij te houden van je build proces en dat automatisch te mailen naar 1 of meer mensen. Dit is typisch functionaliteit die je wel in een dergelijk tool verwacht, maar niet in een IDE die ergens op een workstation draait.

Als ik de discussie hierboven zo doorlees denk ik dat je wel een beetje scherp bent in het afkeuren van een tool omdat het met een configuratie-file werkt die je zelf in elkaar moet zetten. Ant is bijvoorbeeld redelijk gedocumenteerd en er zijn stapels voorbeelden van gebruik op het net te vinden. Als Nant minder gemakkelijk is, dan is dat jammer maar helaas. Persoonlijk zie ik niet zo heel erg veel verschil in het invullen van een XML file of het vullen van properties in een IDE. Voor Ant is overigens ook een DTD verkrijgbaar om je te helpen bij het valideren van de build file.

Jouw stelling dat het ideale proces om software te bouwen alleen maar gaat bestaan uit het in elkaar klikken van componenten is komt ook een beetje extreem over. Natuurlijk kun je op dit manier gemakkelijk en snel iets in elkaar zetten, maar specifieke details/aanpassingen zul je nog altijd op een of andere manier met de hand moeten aangeven, tenzij je software bijvoorbeeld automatisch weet welke database er gebruikt moet worden omdat 'ie dat ruikt op het netwerk.....

[Johannes]

EfBe,

denk je niet dat het een beetje te simpel is om te zegen dat elk programma zonder GUI meteen slecht is? Het is gewoon een andere insteek. Jij vindt het belangrijk dat er voor elke optie een GUI aanwezig is, maar raakt ook gefrusteerd door 'ik kan nu wel post-build steps aangeven, maar dat is maar weer erg brak gedaan'. De developers van ANT vonden het blijkbaar belangrijker om een krachtige tool te bouwen (waarbij dit bijv. wel zou kunnen) dan om daarbij meteen een GUI te geven.

Dit betekent niet dat ANT slechte software is, slechts dat de prioriteiten anders liggen. Dat jij er nogal van overtuigd ben waar die prioriteiten moeten liggen (GUI/IDE), betekent ook niet dat wij die moeten delen.

BTW, er is wel een GUI-editor voor ANT beschikbaar: http://antelope.sf.net.

[zoepercavia]

Ohja trouwens, ik vond deze pagina http://www.gotdotnet.com/team/csharp/tools/#Buildtools nog. Hier staan wat tools die worden aanbevolen door het team van .Net (LLBLGen staat er trouwens ook ). Ook NAnt wordt genoemd, maar daarnaast ook nog een aantal andere buildtools, die helaas niet opensource/freeware zijn maar wel allemaal een GUI hebben
Wat ik wel mis is een goeie integratie met Visual Studio en een duidelijke visie op gebruik in een team. Ik ben pas net begonnen in een team te werken met Visual Studio en werk nu gewoon allemaal tegelijk in dezelfde solution op de server. Dit gaat redelijk behalve dat:
- fouten van anderen zichtbaar worden tijdens het compilen (dit lijkt me niet goed?)
- als je een bestand toevoegt aan het project dan moeten de anderen ofwel hun project herladen of het compilen mislukt.
Ik heb het gevoel dat ik met deze methode nogal de plank missla, maar het alternatief - allemaal lokaal werken (en compilen), uppen naar de server en dan centraal compilen - lijkt me net zo bewerkelijk. Is CVS/VSS hier dan de enige oplossing voor?

Wat betreft de nut/noodzaak van buildtools. Ideaal zou VS een buildtool moeten hebben die allemaal nuttige dingen automatisch mogelijk maakt (centraal compilen, versioning, unit testing, opschonen, packaging, etc..). Desnoods biedt VS de mogelijkheid om externe programma's te 'hooken' in het build proces. Helaas is dit niet zo en wordt zo de noodzaak voor externe tools (zeker in teams) wel heel groot. Naar mijn mening moet zo'n externe tool liefst zo vloeiend mogelijk integreren met bestaande IDEs (VS, SharpDevelop) en een bepaalde basisfunctionaliteit zoals bovengenoemd bieden. Dit betekent dat zo'n tool sln/csproj files moet kunnen lezen, desnoods vertalen in een eigen batchformaat, maar dat moet allemaal transparant voor de gebruiker gebeuren. Wat dat betreft slaat NAnt de plank compleet mis, naar mijn smaak hebben ze domweg Ant proberen te vertalen zonder na te denken over het gebruik daarvan in een .Net omgeving. Ook opensource/freeware tools moeten aan een zeker aantal basisvoorwaarden voor gebruik voldoen (GUI/documentatie) en er moet vooral over nagedacht zijn. De gebruiker is immers koning!

Wat dat betreft is het inderdaad, zoals EfBe als noemde, triest gesteld met de bruikbaarheid van computers. Er is al enorm veel bekend over cognitieve ergonomie, testen van software, etc.. maar in te veel programma's lijkt dat alles te ontbreken. Ik werk veel met computers en gebruik ze voor van alles en nog wat, maar ik vind ze vaak genoeg gewoon ondingen omdat ze niet doen wat ik wil (en dat ligt echt niet aan mij).

Een zinnetje van Microsoft over CASE tools is hier wel mooi toepasselijk bij: "Eat your own dogfood".

Nou weer even on-topic, wat zijn voor jullie de basisvereisten waaraan een buildtool moet voldoen? Ik noem er al vast wat:
- integratie met bestaande IDEs (maar wel IDE onafhankelijk)
- centraal compilen
- backup
- unit testing
- integratie met andere tools (CVS/VSS bv.)
- versioning
- ondersteuning voor iteraties

[mbravenboer]

zoepercavia: Wat betreft de nut/noodzaak van buildtools. Ideaal zou VS een buildtool moeten hebben die allemaal nuttige dingen automatisch mogelijk maakt (centraal compilen, versioning, unit testing, opschonen, packaging, etc..). Desnoods biedt VS de mogelijkheid om externe programma's te 'hooken' in het build proces.

Dat laatste lijkt mij absoluut noodzakelijk. Wat je namelijk daar voor allemaal beschrijft (centraal compilen, versioning, unit testing, opschonen, packaging, etc.. ) is zo'n beetje alles wat met software engineering, deployment en logistiek te maken heeft. Als je dat allemaal in 1 tool wilt zien, krijgt het nogal wat te doen en de trieste realiteit is nu eenmaal dat je niet alles goed kan doen.

Daarom moeten er individuele tools zijn die de losse problemen van software engineering goed oplossen: versioning, geautomatiseerd build proces, compilatie op diverse systemen, unit-testing, packaging en deployment. Een IDE die dit allemaal zelf tracht te doen is gedoemd te mislukken. Een IDE moet het juist mogelijk maken al deze tools goed aan elkaar te lijmen in een visuele omgeving. Een IDE die dat niet mogelijk maakt is een slechte IDE. Een slechte IDE is dus bijvoorbeeld een IDE die maar 1 vaste compiler kan gebruiken, geen filosofie heeft voor een geautomiseerd build proces en niet open is zodat andere tools het zelf eventueel kunnen oplossen. Er ligt dus een verantwoordelijkheid bij zowel de IDE als de tool ontwikkelaars. Er bestaan dus ook slechte tools.

Nou weer even on-topic, wat zijn voor jullie de basisvereisten waaraan een buildtool moet voldoen? Ik noem er al vast wat:
- integratie met bestaande IDEs (maar wel IDE onafhankelijk)
- centraal compilen
- backup
- unit testing
- integratie met andere tools (CVS/VSS bv.)
- versioning
- ondersteuning voor iteraties

Een basisvereiste is dus imho dat hij helemaal niets van dit moet doen. Een complete omgeving voor software engineering moet dit uiteraard allemaal wel doen, maar laat elk tooltje een probleem echt goed oplossen. Een IDE is ervoor verantwoordelijk dat dit allemaal aan elkaar geplakt kan worden en de tools zijn ervoor verantwoordelijk dat ze geplakt kunnen worden.