NL/Interview/Kerst2011

From The Document Foundation Wiki
Jump to: navigation, search

LibreOffice mega Kerst interview

December 2011: In vele landen in de wereld wordt Kerst gevierd als een tijd van vrede. In vroegere dagen werd op het noordelijk halfrond de mid-winter viering gehouden – uitkijkend naar het nieuwe licht. Tegenwoordig is het gebruikelijk om tijdens Kerstcadeautjes uit te wisselen.
Laten we snel eens kijken wat voor cadeautjes LibreOffice onder de Kerstboom heeft gelegd… Ah, dit is duidelijk het ontwerp van een nieuwe grote versie: 3.5  :-) Ik zal proberen dit cadeau een beetje uit te pakken, een kijkje nemen onder het glanzende pakpapier.
Wat zie ik hier: honderden en honderden nieuwe code regels, die spreken over 'opschonen', 'vernieuwen', 'verwijderen', 'eenvoudige hack'. Klinkt nogal technisch in mijn oren. Maar wat voor groot cadeau is dit dan voor de gebruikers?
Ik besloot eens met wat ontwikkelaars te gaan praten, in een poging om uitleg te krijgen van wat al dit werk betekent – om voor sterfelijke gebruikers als (waarschijnlijk) u en ik te ontrafelen, simpelweg: wat voor verbeteringen, in welke gebieden, kunnen we verwachten, nu en in de toekomst, als resultaat van al dit harde werken?
Onderstaand kunt u het resultaat van mij 'research' vinden. Sommige delen zijn technisch, sommige delen beschrijven werkelijk de functies voor gebruikers. Ik moet bekennen dat ik slechts een klein deel van alle mensen en al het werk heb kunnen omvatten..... Desondanks hoop ik dat u het (grotere) cadeau mooi vindt!

Snel bouwen

Een belangrijk deel van het proces van software ontwikkeling is het bouwen: de broncode die door ontwikkelaars is geschreven omzetten in iets dat wij kunnen downloaden en installeren. Maar dit bouwen is ook belangrijk voor ontwikkelaars, als bewijs dat het werk goed is gedaan, dat het werkt als was verwacht, of de foutjes zijn hersteld, en dat er nu niets anders fout gaat.
Dus ontwikkelaars hebben de 'bouw' nodig. Meermaals. Snel. Dit is waar Norbert Thiebaud een verhaal over te vertellen heeft: “Ja, mijn inspanningen zijn gericht om het bouwproces snel en betrouwbaar te maken, om goede betrouwbare tinderboxes te hebben: snel, en met bruikbare terugkoppeling, zodat andere ontwikkelaars op hun beurt terugkoppeling op hun werk kunnen krijgen voor platformen (besturingssystemen) waar ze normaal geen toegang toe hebben. Voor de kwaliteitsborging hebben ze dan regelmatiger en frequenter testversies, zodat zij vroegtijdig kunnen testen…” Het sleutelwoord daarvoor is ‘voortdurende integratie’. Code wordt geïnspecteerd en snel uitgebracht: bij voorkeur zo snel als mogelijk. Daarom heb je ook snelle terugkoppeling nodig.
De tinderboxes waar Norbert over vertelt, zijn machines die automatisch installeerbare versies bouwen, voor alle soorten platformen. Dan is er ook nog de tinderbox-server', waar op dagelijkse basis gerapporteerd wordt over de status en de versies. Norbert opnieuw: “Dit betekent dat ik punctueel verbeteringen maak, om te proberen mijn tinderboxen groen te houden. . Ontwikkelaars zullen zorgvuldig willen werken om te zorgen dat de server een groen “OK” signaal geeft. We boeken grote voortgang met deze tinderboxen. In deze decembermaand, hebben we meer dan 100 testversies per dag gemaakt. Vorige april was dit slechts zo'n 30!”

Lionel Elie Mamane, die later over Base zal vertellen, werk ook mee aan het bouw-proces: “In het begin, toen ik startte met bouwen van LibreOffice, stuitte ik op een paar dingen die me irriteerden in het configuratie/bouw-systeem, dus corrigeerde ik deze. “Eén irritatie was dat er een 'mysql-connector' bestand gedownload zou worden nádat de configuratie klaar was, maar de configuratie liep fout omdat het bestand er nog niet was. Een catch-22 situatie :-) en nu dat ik dat verholpen heb is er een soepeler ‘eerste bouw’ ervaring voor nieuwkomers.” “Andere kleine dingen betreffende het stoppen van het onnodige creëren van vele 'symlinks' (met als gevolg een snelheidsverbetering), en het aanpassen van de kleureninstelling van de bouw uitvoer van de oude 16 kleuren standaard naar 256 kleuren. Dit maakt ontwikkeling gemakkelijker, omdat compilatiefouten in kleur op het scherm te zien zijn.”

Fatsoenlijke versie opbouw

Versies die vrijgegeven worden, moeten natuurlijk goede versies zijn. Petr Mladek vertelt ons hoe dit gaat: “Het meeste van mijn werk is gerelateerd aan het vervaardigen van alle officiële versies, dit houdt in dat ik de versie samenvoeg-fouten (merge conflicts)repareer. En natuurlijk meer versie samenvoeg gerelateerde zaken. Omdat en bijna elke week een versie werd samengesteld, had ik er veel werk aan. Daarnaast help ik bruikbare scripts uit de oude versie databank in te voegen. Deze helpen pakket ondersteuners met het maken van LibreOffice voor verschillende Linux distributies. Er waren vele anderen die daar ook aan meehielpen.” Omdat versies ook gebruikt worden door vrijwilligers van kwaliteitsborging voor het testen, werd daar ook speciaal werk voor gedaan. “Eén van de taken was het maken van Linux pakketten op zo'n manier dat de verschillende 3.x versies naast elkaar konden worden geïnstalleerd. Dit is handig, vooral voor testers, maar ook voor normale gebruikers. Ik voegde ook specifieke versie informatie aan het 'info over' venster toe, zoals beta2. Dit helpt de testers en gebruikers de geïnstalleerde versie beter te beschrijven en betere foutrapporten te maken.”

Easy-hacks als een goede start

Nu wat woorden van Olivier Hallot, één van de oprichters van The Document Foundation: “LibreOffice code was een uitdaging voor me sinds de OOo dagen. Ik slaagde erin het te compileren en de volgende stap was natuurlijk om één van de 'easy-hacks' te proberen die door de ontwikkelaars worden gesuggereerd. Ik vond deze easy-hacks de beste manier om vertrouwd te geraken met C++ programmeren en ik begon sommige gebruikersinterface problemen, die ik in mijn taal vond, te repareren. Van een simpele hobby naar een meer serieuze taak. Ik ben nu betrokken bij de ontwikkeling van LibreOffice. Genoeg plezier!”

Opschoning: Voor verbeteringen en gemakkelijker ontwikkelen

Gemakkelijk ontwikkelen .. nou ja, zo gemakkelijk als mogelijk! Tor Lillqvist is één van de ontwikkelaars die daar aan werken: “Ik ruimde veel ongebruikte stukjes en beetjes op. Dit maakt het gemakkelijker om met ontwikkelen te starten, omdat er minder ongebruikte of niet relevante onderdelen zijn waaraan je tijd kunt verspillen door ernaar te moeten kijken.”
Een deel van het werk dat Tor doet is gerelateerd aan cross-compilatie: “Cross-compilatie maakt het mogelijk een een snelle machine voor langzamere machines te ontwikkelen, of voor machines die helemaal niet op een desktop besturingssysteem draaien. Je kunt nu dus op een Linux machine een uitvoerbaar bestand voor Windows produceren, maar nog geen installatie bestand. De 'Lanedo' mensen werken daar nu aan.”
Hoewel niet direct gerelateerd aan dit schonings/verbeterings interview, wilde Tor ook nog iets anders toevoegen: “Ja, voor de webversie en voor Android is het compilatie gedeelte ook klaar, net een paar dagen geleden. Maar wees voorzichtig: dat betekent niet dat er al een versie beschikbaar is die op die systemen draait. Alleen dat mensen die geïnteresseerd zijn in het werken met gebruikers interfaces nu een solide basis hebben om mee te werken.”
Lionel Elie Mamane werkte ook aan algemene code opschoning: “Ik verwijderde onnodige const casts, ongebruikte variabelen, … Dit maakt de code beter onderhoudbaar, gemakkelijker te begrijpen, enz. Const casts zijn gaten geboord door een veiligheidsmarkering van C++! Dus ze verwijderen als ze toch geen doel hebben, helpt toekomstige programmeerfouten te voorkomen.” Een speciale opschoning was de oude OpenOffice <-> PostgreSQL driver. “Dat was ‘bitrotten’ zoals wij dat noemen. Het werkte alleen tot aan versie 3.2 .. Dus ik bewerkte het: integreerde de oorspronkelijke LibreOffice <-> PostgreSQL driver in LibreOffice, verbeterde het, porte het in de laatste LibreOffice versie. Dit had vanzelfsprekend vele voordelen voor PostgreSQL toegang.”

Code leesbaarheid

Als je het gemakkelijk wilt maken voor part-time ontwikkelaars, studenten, beginners en dergelijke om aan de code te werken, dan is goede leesbaarheid van de code erg belangrijk. Er zijn veel voorbeelden. Olivier vertelt over een 'easy hack' dat is bedoelt om de test voor code matrices te vervangen: “Als je voorheen een code matrixmoest testen die leeg was, moest je de lengte van de matrix weten. Als dit nul was, dan was de matrix leeg. Kortgeleden is er een nieuwe methode 'isEmpty()' geschreven voor dit doel. Het is dan de bedoeling om, in alle code, 'getLength()' te vervangen door 'isEmpty()': een erg bewerkelijke klus. Maar het resultaat is een veel betrouwbaarder code.”

Wat merken gebruikers hiervan?

Het werken met RTF (Rich Text Format) documenten gaat beter

Terwijl anderen werken aan het opschonen van de algemene code, is het werk van Miklos Vanja, met waardering voor het schoning en vervangingswerk, sterk gefocust op één gebied. Miklos: “Gedurende de laatste twee zomers heb ik gewerkt aan de Writer RTF filters. Zowel de export als de import filters waren in oude code, met bekende ontwerpfouten. Het was dus tijd om deze te vervangen en nieuwe te creëren. Exporteren was nieuw in 3.3, importeren zal nieuw zijn in 3.5. Dat maakt het mogelijk om in de toekomst nieuwe functies toe te voegen aan onze RTF die al lang gemist werden, zoals geneste tabellen, die al in Word 2000 geïntroduceerd werd in RTF.” Miklos verwelkomt altijd voorbeeld-documenten die nog niet volledig bewerkt worden door de nieuwe filters, zodat de importfunctie verder verbeterd kan worden.

Calc

Verbeterde testen, speciaal voor Calc, is ook noemenswaardig. Markus Mohrhard werkt hier aan: “Eén van de gebieden waar ik mee bezig ben geweest is het automatiseren van testwerk. Dit maakt het werk van ontwikkelaars werkelijk eenvoudiger, en verkleint het risico van het introduceren van nieuwe fouten in nieuwe en gewijzigde functies. Onze Calc filter-testen in het bijzonder, zijn een goede manier om fouten vroegtijdig te ontdekken. Deze toonden ongeveer 15 erg vervelende Calc fouten, en minstens twee oudere fouten in de LibreOffice kern. Aan het foutnummer zien we dat het meestal nieuwere fouten zijn die waarschijnlijk nog niet ontdekt zijn in OOo en sommige zijn onze eigen fouten.”
Markus wijst er op dat dit nieuwe testen zijn, die snel en betrouwbaar zijn, en meedraaien tijdens de meeste compilatie processen van de ontwikkelaars – zodat we er zeker van kunnen zijn dat: als het gecompileerd is, het op geen van deze punten regressies zal hebben. Hij benadrukt dat het niet alleen belangrijk is, maar ook erg gemakkelijk om het testen uit te spreiden! “Wat ik deed was, alle ods, xls and xlsx van verschillende bug-databases downloaden en dit filter-test concept gebruiken om te testen of één van deze bestanden Calc laat crashen bij het importeren, of gedurende de eerste berekeningen van de inhoud. Dit toonde een andere serie van fouten aan die Kohei, Eike en ik herstelden voor de code van 3.5 .
“Meer dan 4000 documenten werden gecontroleerd met deze aanpak, waarbij 3.5.0 al significant verbeterd is.” Een andere ontwikkelaar: “Ik verwijderde ongebruikte code en verbeterde fouten, hoofdzakelijk enkele die al in 3.4 waren ontstaan, en sommige die nog niet waren opgevallen of wel al waren gerapporteerd.”. Hier is Eike Rathke aan het woord.

Snelheid verbetering

Eike Rathke is één van de lang erkende ontwikkelaars, die we nog kennen van Sun/OpenOffice.org. Hij begint met te vertellen over zijn vakantie: “De zomer was zo slecht in juli/augustus dat ik maar aan het werk ging met LibreOffice :-) Ik sloot me aan bij RedHat in oktober, de maandag gelijk na de LibreOffice conferentie. Eén van de dingen die ik toen aanpakte, was het aanpassen van het formaat ‘Datum, Tijd en DatumTijd’. In de oude code werd de systeemtijd iedere keer opgehaald tijdens de werkzaamheden. Dit is onnodig als je alleen een variabele wilt definiëren. Tezamen met gerelateerde controles en bewerkingen veroorzaakte dit vele onnodige systeem acties, die nu niet meer gebeuren en in 130 van ongeveer 350 gebeurtenissen. “Ik verwacht een triljoen onnodige systeemactiviteiten om tijd op te vragen te zijn kwijtgeraakt met deze aanpassing :-) Sorry, geen echte cijfers hiervan beschikbaar.
“Natuurlijk verbeterde ik veel meer code, gerapporteerde en niet gerapporteerde fouten, het werk waar “Moggi” Markus Mohrhard over sprak. En ik voegde een aantal foutenverbeteringen toe die vanuit CWSs van (A)OO(o) en nog steeds onder LGPL in de wacht stonden, en ik verzorgde/duwde wat patches. Ook hielp ik Moggi de in Calc benoemde bereiken/expressie afhandeling te verbeteren, speciaal met werkblad namen en kopieer en plakken gedrag.“

Base

Verdergaand met Base, Lionel heeft hier veel over te vertellen: “In zijn geheel, zou ik zeggen dat het mijn focus was om Base (met scripting) weer bruikbaar te maken, omdat ik het wilde gebruiken in mij dagelijkse werkzaamheden. Om de Microsoft Access-gebaseerde bedsrijfs-specifieke programma's die ik in het verleden had ontwikkeld te vervangen. En het werkte erg slecht in de eerste 3.4. Verder herstelde ik een aantal fouten die voor de gebruiker zichtbaar waren, o.a.: marges in rapporten; betere, meer breed ondersteunde, zinsbouw voor rapporten gebaseerd op een query + sorteren; repareerde meerdere 'crashes', verbeterde PDF-export. “En misschien wel het meest belangrijke dat ik ADO (ActiveX Data Objects) voor Windows opnieuw integreerde; nog een andere gebruikelijke API voor access naar SQL databases.”
Lionel maakte ook verbeteringen voor wachtwoorden, metadata, queries, koppelingen: “Mijn werk aan LibreOffice was hoofdzakelijk omdat ‘mijn handen jeukten’, en ik pak fouten en functies aan waar ik in geïnteresseerd ben en ik me bekwaam voor voel: database dingen!”
Lionel benadrukt dat de LibreOfficegemeenschap zijn inspanningen uitzonderlijk hebben verwelkomd en snel zijn met het erkennen van zijn werk. [Laat mij (verslaggever) opmerken dat het me een leuk idee lijkt om ergens een bericht te plaatsen met meer details over Lionel's werk.]

Verschillende easy hack-gebruikersinterface verbeteringen

Olivier Hallot was blij wat tijd te besteden aan verschillende easy hacks, resulterend in een betere bruikbaarheid, interface enz.: “Eén hack gaat over het verbeteren van het extensie-beheer scherm. Het staat de gebruiker nu toe om de geïnstalleerde extensies te filteren, de dialoog opschonen en het zoeken naar geïnstalleerde extensies vereenvoudigen. Een ander eenvoudige aanpassing is het commando ‘Beveilig werkblad’ toevoegen aan het context menu van het werkblad. Ik voegde ook 8 nieuwe symbolen toe aan LibreOffice Math, die worden gebruikt in theorie vergelijkingen bij spellen. Dat verzoek kwam van een collega professor wiskunde.”
Eén van de interessante onderdelen van of LibreOffice is natuurlijk de lokalisatie. Soms levert dat tekenreeksen op die veel langer zijn dan de Engelstaligen en past de tekst niet .... Olivier: “Daarvoor maakte in verschillende aanpassingen aan de dialoog schermen, om de niet Engelstalige tekenreeksen, die veel langer waren en werden afgebroken in de gebruikersinterface, te laten passen.” Een ander voorbeeld van een verbetering van de leesbaarheid van de gebruikersinterface Dus, wat een Kerstcadeau! En dit is alleen en klein kiekje van een paar van de 'hackers' die we even van het fout-oplossen van 3.5.0 betá konden losweken. – Er zijn er veel meer geweest, meer zichtbare verbeteringen – u kunt er een aantal zien in de 3.5 wiki pagina.

originele interview hier - vertaling Kees Kriek, redactie Cor Nouws