[Alg] Het gebruik van 3rd party libraries / gems

[Verwijderd]

Een goedenavond allen,

Ik ben de laatste weken / maanden bezig met het schrijven van een kleine webapp. Omdat ik nog maar pas begonnen ben met Ruby on Rails zoek ik regelmatig wat dingen op. Nu was ik op zoek naar een tutorial voor het schrijven van pagination. Daarvoor kwam ik terecht op Railscasts waar ik al een hele hoop andere goede screencasts heb gezien. Volgens de maker van het filmpje kan je best gebruik maken van een gem genaamd 'will_paginate'. Nu vroeg ik mij af: Waarom zou je dit niet gewoon zelf schrijven?

Ik heb even gekeken op de Github-pagina van 'will_paginate' en kwam daar tot de conclusie dat de gem bijvoorbeeld vatbaar is voor SQL-Injecties, iets wat me niet echt wenselijk lijkt. Stel dat ik er voor kies om deze gem te installeren, dan zal ik er toch voor moeten zorgen dat ik altijd de laatste nieuwe versie heb om toch telkens maar weer de "veiligste" versie te hebben. Maar wat dan als je applicatie breekt wanneer je een update doorvoert (vb. Van Rails 3 app naar Rails 4)

Met andere woorden: Ik vind dat je nogal snel afhankelijk wordt van andere partijen. Ik heb ook een screencast gekeken in verband met user authenticatie en ook daar raadden ze me aan om een gem te gebruiken. In de plaats daarvan heb ik geopteerd om zelf authenticatie te schrijven.

Tot nu toe heb ik het aantal gems dus proberen te beperken. Ik heb er nu 2 zelf geïnstalleerd, namelijk "paperclip" en "bcrypt-ruby".

Hoe staan jullie tegenover het gebruik van deze gems? Hoe zorgen jullie dat deze gems op tijde geupdated worden (hier bestaat ook een gem voor (http://rubygems.org/gems/bundler-auto-update) maar ik weet dus niet als dit wel de bedoeling is.

offtopic:
Ik neem aan dat dit ook geldt voor andere talen / platformen

[Verwijderd]

Schop

[AtleX]

Wil je nu een discussie over het gebruik van 3rd party libs/code of wil je antwoord op je vraag of je die specifieke gems moet gebruiken? Title en startpost zijn wat in conflict zeg maar.

[Verwijderd]

Het gaat mie niet over het gebruik van specifieke gems maar over het gebruik van gems in het algemeen. Ik vraag me af als jullie veel gebruik maken van dit soort gems of dat jullie er voor opteren om dit soort code zelf te schrijven.

Als jullie er voor opteren om gebruik te maken van deze gems, hoe onderhouden jullie deze dan?

[AtleX]

Ik ben geen RoR ontwikkelaar, maar heb er wel een idee over. Als ontwikkelaar ben ik toch een vrij groot voorstander van niet nogmaals het wiel uitvinden. Als ik een goede lib of tool in kan kopen die doet wat ik wil, die actief ontwikkelt wordt, al wat historie heeft en een aardige userbase dan zou dat mijn eerste keus zijn. Waarom? Omdat de ontwikkelaars daarvan al de fouten gemaakt hebben die ik ga maken bij het zelf schrijven van de library. En natuurlijk is het regelmatig veel goedkoper, als er voor 500 euro iets in te kopen is dat mij een week ontwikkeltijd zou kosten dan weet ik het wel.

Zomaar wat van internet aftrekken ben ik dan weer geen fan van. Iets wat iemand een jaar terug op zijn zolderkamertje heeft ontwikkeld en sindsdien niet meer geupdate heeft is gewoon een extra risico in de ontwikkeling van de applicatie. Vandaar mijn opmerking over historie, als iets al een tijdje (jaren?) ontwikkeld wordt is hopelijk de kwaliteit beter en vaak zit er dan ook meer dan één persoon achter wat beter is voor de continuiteit.

[Herko_ter_Horst]

In het algemeen is hergebruik van bestaande libraries, zeker op het gebied van security, veruit aan te bevelen boven zelf maken. Ik durf te wedden dat "zelf maken" verantwoordelijk is voor een aantal van de security breaches die de afgelopen tijd in het nieuws zijn geweest.

Natuurlijk is het dan wel verstandig om gangbare, liefst open source, libraries kiezen die al veel gebruikers hebben. Een library van een enkele developer is net zo goed/slecht als zelf maken.

Je hebt een aantal nadelen benoemd, maar de voordelen zijn veel groter:
- meerdere developers, dus meer kans op de juiste oplossing ("twee weten meer dan één")
- meer gebruikers, dus veel meer kans dat fouten worden ontdekt
- onderhoud hoef je niet zelf te doen, je hoeft alleen maar nieuwe versies in de gaten te houden
- je hoeft niet alle detailkennis zelf in huis te halen

Dus je hebt in principe minder werk en een grotere kans op hogere kwaliteit. Dit gaat zoals gezegd niet op voor een nieuw projectje dat een enkele developer net uit de grond heeft gestampt. Dus hoe langer een library bestaat, hoe meer developers er aan werken en hoe meer gebruikers deze heeft, des te meer zou ik aanraden deze te gebruiken.

[Verwijderd]

Ik zie uiteraard de voordelen hiervan in. Dat is een van de redenen waarom ik trouwens begonnen ben met een framework (Rails) en niet gewoon verder ben blijven prutsen met PHP.

Hoe onderhouden jullie dit soort software dan. Hoe zorg je ervoor dat je code niet breekt nadat je een update van je library hebt doorgevoerd?

[AtleX]

Daarvoor vertrouw ik voor een groot gedeelte op de ontwikkelaar van de lib, als die elke keer zijn API omgooit is de kwaliteit in mijn ogen niet zo heel goed. Ik krijg dan het idee dat er geen visie of ontwerp achter zit maar er maar gewoon een beetje aangeklooid wordt.

[ Voor 26% gewijzigd door AtleX op 19-06-2012 18:20 ]

[eamelink]

Verwijderd schreef op dinsdag 19 juni 2012 @ 18:06:
Hoe onderhouden jullie dit soort software dan. Hoe zorg je ervoor dat je code niet breekt nadat je een update van je library hebt doorgevoerd?

Ten eerste preventie; als je een goede library uitkiest van een ontwikkelaar die verstand van zaken heeft, verandert de public API niet zodanig dat je code regelmatig breekt bij updates.

Als extra maatregel zou je tests kunnen schrijven voor de contracts van de API waar jij op rekent, als die dan toch veranderen dan zie je dat aan falende tests.

En lees de release notes als er een nieuwe versie uitkomt

[StM]

En updaten is geen doel opzich. Wij updaten alleen als er security bugs gevonden zijn, een serieus probleem waar we tegen aan lopen opgelost is of als we een grote update van de applicatie doen. Wij updaten echt niet naar iedere willekeurige patch update.

[chime]

Geautomatiseerde testen.
Dat zorgt er voor dat ongeacht welke aanpassing je doet de bestaande functionaliteit behouden blijft of je het direct kunt zien wanneer dit niet het geval mocht zijn.

Dat gecombineerd met: we updaten 3rd party zaken pas als dat nodig is en niet wanneer er een nieuwe versie uitkomt.
Of het nodig is, moet je zelf bepalen. (veiligheidrisico opgelost, performantie-winst, zit jou product al in productie of nog in ontwikkeling, ... )