"Parlant de llenguatges, molts dels problemes a què ens enfrontem avui no poden resoldre amb un sol llenguatge o
aplicació. Avui en dia, no es pot explicar adequadament ni raonar sobre el comportament d'un lloc web només
examinant el codi de l'aplicació. Un lloc recull atributs de comportament d'una multitud de fonts: el codi de l'aplicació,
 la configuració de servidors web i servidors cache, servidors grid, processament asíncron, elements d'aprenentatge
automàtic, dispositius actius de xarxa (com firewalls aplicatius), i magatzems de dades. "Programació", com el descriuríem
 avui - programació de comportament aplicatiu com a tractament de peticions - defineix una porció cada vegada menor
del comportament. No tenim eines o llenguatges per expressar i raonar sobre aquests sistemes distribuïts, estesos i
fragmentats. A conseqüència, és difícil predir la funcionalitat, rendiment, capacitat, escalabilitat i disponibilitat d'aquests
sistemes. "

No podria estar més d’acord…

La quantitat de coneixement i expertise que de vegades es necessita per implementar, entendre i mantenir el que pot semblar ser “un lloc web senzill” sol ser subestimada.

És realment increïble el que es pot trobar sota la caputxa d’una pàgina “web”, i la quantitat de coneixements necessaris per controlar i comprendre plenament les conseqüències i els resultats que es donen per l’execució del teu codi:

Transaccions distribuïdes, dominis profunds dinàmics, entorns “caixa negra” clusterizados i balancejats de càrrega, biblioteques de tercers que limiten, protocols http sense estat, nivells d’aïllament proclius a deadlock, colls d’ampolla dels recursos, navegadors client insuportables, inferns de classloader…

Quan sorgeix un problema, en general en forma d’un comportament inesperat, la recerca de qualsevol informació que pugui ajudar a entendre exactament el que està passant comença.

Com diu Michael, “la programació de comportament aplicatiu com a tractament de peticions - defineix una porció cada vegada menor del comportament”.

A vegades és bastant sorprenent la quantitat de coses que han d’anar bé només perquè una petició http simple pugui ser processada com volem:

En primer lloc, un segment de JavaScript ha de ser correctament interpretat per qualsevol de molts navegadors iguals-però-totalment diferents. Si aquest primer pas ja de per si complex surt bé, llavors, d’alguna manera, la sol.licitud ha de ser enrutada i gairebé miraculosament guiada a través d’una xarxa gairebé infinita de nodes trencats i carrerons sense sortida a un socket. Suposant que la sol.licitud ha estat realment capaç de desencadenar la creació d’un fil en un membre vàlid d’un entorn clusterizado, el rellotge comença a comptar per vèncer tot tipus de timeouts de petició, sessió i transacció, per obrir, utilitzar i tancar tots els recursos, i generar la resposta esperada, que per descomptat han de ser d’alguna manera guiat de tornada al punt inicial original.

Si es multiplica aquesta seqüència d’esdeveniments per cent, no és difícil imaginar la bogeria que es produeix en un entorn multiprocés de memòria compartida com una JVM…

Tampoc és sorprenent que el nombre d’elements que han d’estar perfectament sincronitzats i configurats per treballar junts perquè el sistema global funcioni, pugui ser aterridor…

Pel que he vist fins ara, només l’especialització, més la recopilació d’informació, a través d’una àmplia gamma d’eines, pot ajudar.

Els registres de transaccions i deadlocks per DBAs, bolcats de fils pels enginyers de Java, logs de sistemes per a operacions …

No sempre és possible aplicar solucions simples: de vegades implementacions de sistemes complexos són inevitables.

I quan aquest sigui el cas, reptes interessants sempre apareixen abans de ser capaç d’oferir un lloc web “simple” que “simplement funcioni”.

(En el cas dels T-800, esperem que per a nosaltres, no a curt termini)

Recordo haver fet un curs de robòtica durant els meus estudis a principis del 2000, i l’autònom de 4 rodes, de propòsit específic, seguidor-de-línies i avantpassat de Número 5, que va resultar a ajuntar un PCB, un servo, soldadures d’amateur, una mica de micro-programació i molt entusiasme, va quedar bastant lluny de David.

No obstant això, la força de voluntat dels sheldons del món segueix tancant la bretxa entre la ciència ficció i la realitat i, de tant en tant, alguns resultats apareixen que sens dubte em fan aixecar les celles.

Recentment em vaig trobar amb la lliçó Space & Robots donada a la universitat de la singularitat per l’astronauta de la NASA Dan Barry.

L’exposició fa un gran treball de discutir breument la capacitat d’adaptació, la robòtica i la intel.ligència artificial, però el que em va cridar l’atenció van ser els diversos exemples d’estat actual de la robòtica, i en especial aquests dos:

Kiva Systems

El que probablement sigui el fet més interessant d’aquesta legió d’agents intel.ligents taronges controlats per un cervell central, és que es tracta d’un sistema real que s’utilitza en entorns de producció reals.

Three Engineers, centenars of Robots, One Warehouse on spectrum.ieee.org explica en breu com funciona el sistema:

"The robots ... navigate the warehouse by pointing cameras at the floor that read two-dimensional bar-coded stickers laid out by hand 1
 meter from each other, in a grid. The robots relay the encoded information wirelessly to a computer cluster that functions both as a
 dispatcher and a traffic controller. It instructs, for instance, robot No. 1051 to bring rack No. 308 to worker No. 12--without colliding
 with robot No. 1433, which is crossing its path."

"Instead of relying on a single piece of software that centralizes all the decisions, they envisioned software agents that could run on the
 central computer, on the robots, and on PCs at the picking stations. The agents would exchange information but act independently, each
 trying to optimize its own tasks. They also adopted heuristic methods, like greedy algorithms that can make good--but not always the
 best--decisions to perform tasks such as assigning racks to stations."

“BigDog”

Només veure com camina aquesta “bèstia” sobre el gel és alhora impressionant i aterridor.

Com el Dr Barry, jo també penso que BigDog es desenvolupa millor sobre gel que jo …

Amb l’esperança que pugui ser útil per a tots els que es troben sovint en el rol de “amic / parent / XXX”, que “sap d’informàtica” , i al qual se li demana resoldre amb facilitat i rapidesa qualsevol tasca relacionada amb la informàtica, aquí va una possible solució ràpida i fàcil de crear el lloc esmentat.

La construcció d’un lloc web no és certament la més complexa de les tasques d’un informàtic avui en dia, però, les limitacions que envolten aquest cas particular la converteixen en complexa:

• Els meus coneixements sobre Disseny i construcció de llocs web no ha avançat des de començaments dels 00 (efectes CSS, Flash i HTML5 segueixen sent un misteri per a mi)
• El cost total de la construcció i allotjament del lloc web …. i qualsevol altra despesa, ha de ser 0
• No han d’haver efectes secundaris desagradables de hosting gratuït (com elements emergents)
• El lloc web portfoli ha de permetre la gestió fàcil d’àlbums: tot aspecte tècnic ha de ser transparent per a l’usuari final

Gestió d’àlbums Transparent

El requisit més difícil a resoldre per a mi va ser trobar una solució que oferís gestió de fàcil i trivial d’àlbums.

La transferència FTP, la creació de directoris remots o la programació HTML no eren una opció, ja que totes aquestes tasques requereixen de coneixements específics que no es poden imposar a l’usuari final.

Afortunadament, vaig topar amb JAlbum.

JAlbum ofereix allotjament gratis per a àlbums de fotos i, el més important, JAlbum també ofereix una aplicació client java que permet a l’usuari crear i administrar fàcilment els àlbums de fotos del lloc.

Seleccionar, arrossegar i deixar anar són les úniques tres operacions bàsiques necessàries per a utilitzar amb èxit JAlbum.

El client és de descàrrega gratuïta, i és possible obtenir un allotjament gratuït (sense popups) de 30 MB (més o menys 200 fotos, la qual cosa és suficient per al meu cas).

Disseny “bonic” i personalitzat

En el meu cas, necessitava una animació a la pàgina principal, i un menú superior per connectar els diferents àlbums.

Flash Catalyst va arribar al rescat quan la meva ignorància completa de Flash es va convertir en un problema per fer una simple animació a la primera pàgina.

Tot i certa inestabilitat (potser a causa del fet que encara estava en fase beta quan ho vaig provar), si estàs equipat amb un bon PSD a capes, és molt senzill crear animacions cridaneres.

( el Tutorial de Ryan sobre Flash Catalyst hauria de permetre d’avançar en cap al camí d’animacions simples en només un parell d’hores)

(Com a nota al marge, per desgràcia, vaig haver de trobar un PC amb Windows per utilitzar Flash Catalyst: els requisits previs deien que “no es pot instal lar en un volum que utilitzi un sistema de fitxers sensibles a majúscules / minúscules”, que lamentablement és la (dolenta?), elecció que vaig fer en instal lar Mac OS …. Potser alguna cosa a resoldre en futures versions)

Després d’una mica d’investigació sobre JAlbum, vaig aconseguir modificar el skin imago d’azarai, inserint els diferents menús superiors, permetent l’efecte desitjat de vincular els diferents àlbums del lloc.

Allotjament

L’allotjament ofert per JAlbum no està destinada a permetre la flexibilitat requerida per un lloc web personalitzat, sinó només per a l’allotjament de llocs JAlbum, el que significa que no va ser possible allotjar la primera pàgina juntament amb els àlbums de JAlbum.

L’última vegada que havia buscat una solució d’allotjament gratuït, crec que l’ara extint Geocities era la millor opció, el que pot donar una idea dels meus coneixements sobre l’estat actual de possibilitats d’allotjament gratuït.

Després de buscar una mica, vaig acabar creant un compte Google App Engine.

Aquesta opció ofereix més del necessari, i després de descarregar el SDK, de la creació del meu projecte i un simple “.. / AppEngine-java-SDK / bin / appcfg.sh update war”, el lloc web portfolio estava en funcionament en el núvol.

He de dir que considero que el resultat final no és del tot dolent per a un lloc-web-de-cost-0 construït un diumenge al matí …

Una possible font d’aquesta informació és, per exemple, un enregistrador de dades GPS.

El camí de GPX a Google Maps pot ser completat en 4 senzills passos:

1. Exporta les rutes enregistrades a GPX

En el meu cas, amb el Venture HC, resulta bastant senzill.

Connecta el Venture HC al Mac a través del port USB, inicia Road Trip i fes clic al botó “Receive”. Les rutes enregistrades han d’aparèixer a la carpeta “Recently Read”. Simplement copia les rutes necessàries en una carpeta i després exporta la carpeta.

2. Converteix l’arxiu GPX a KMZ

Arxius KMZ són versions comprimides d’arxius KML, que és un altre estàndard basat en XML per a la representació de dades GPS.

En qualsevol cas, el format KMZ és un format que Google Maps entén, de manera que el GPX ha de ser transformat a aquest format, amb GPS Visualizer, per exemple.

3. Escriu el codi del mapa

No podria ser més fàcil:

    if (GBrowserIsCompatible()) {
      var map = new GMap2(document.getElementById("map"));
      map.addControl(new GLargeMapControl());
      map.addControl(new GMapTypeControl());
      map.setCenter(new GLatLng(49.613824,6.127625), 12);
      var kml = new GGeoXml("http://dvrom.eu/bike/2.kmz");
      map.addOverlay(kml);
    }

El resultat final, per exemple, una ruta amb bicicleta al voltant de Luxemburg.

La part difícil de tot això és la producció de dades d’entrada rellevants …. mitjançant alguna forma d’activitat física, per descomptat …

Video

	1) Connect 360 Enviament d’àudio (iTunes) i vídeo (qualsevol format que sigui reproduïble al teu Mac ho serà en la teva Xbox 360) directament a la teva Xbox 360.
	2) VLC Aquest bon reproductor de vídeo funciona igual de bé en Mac OS X que en altres plataformes, i és capaç de reproduir gairebé qualsevol format existent.
	3) ffmpegX Un bon codificador / descodificador d’àudio i vídeo, genial per afegir subtítols a un vídeo per exemple.
	4) DivX for MAC La història del origen de DivX és força interessant, i el còdec és encara molt utilitzat avui en dia.
	5) MPEG Streamclip Una altra bona aplicació per a codificar, descodificar i produir vídeo.
	6) Flip4Mac Permet reproduir Windows Media Video i Àudio en Max OS X (i també WMV que formi part de contingut web).

Eines de Blogging

	7) Cyberduck Un bon client FTP lleuger i senzill.
	8) TextWrangler Un bon editor de text, amb syntax highlighting.
	9) GIMP Encara que no m’ha agrada l’entorn multi-finestra de la interfície, definitavemente el millor editor d’imatges gratuït, i funciona sobre X11 sobre Mac OS X.
	10) MAMP La manera més fàcil d’obtenir un entorn de test Apache - MySQL - PHP en Mac.

Geolocalització

	11) Exif Viewer Una petita i útil eina per a visualitzar la informació EXIF d’un arxiu imatge.
	12) Geotagger Funciona conjuntament amb Google Earth per oferir etiquetatge manual geolocalitzada d’arxius imatge.
	13) GPSPhotoLinker Una eina per etiquetatge geolocalitzats automàtic de fotos a través de la lectura d’informació geogràfica prèviament enregistrada.

Altres Utilitats

	14) XCode Les eines de desenvolupament d’Apple, i la manera més fàcil d’obtenir gcc a Mac.
	15) NeoOffice Basat en OpenOffice, però s’executa una mica més ràpid.
	16) Little Snitch Un excel.lent (i sobretot discret i no molest) monitor de xarxa. Genial per vigilar que entra i surt del teu PC.
	17) MenuMeters Un petit i valent monitor de sistema que s’allotja a la barra de menú, i ofereix informació sobre l’ús de xarxa, cpu i memòria.
	18) UnRarX Max OS X no suporta fitxers rar per defecte, així que UnRarX pot resultar molt útil.
	19) utorrent El millor client torrent lleuger.
	20) NTFS-3G Permet operacions d’escriptura sobre particions NTFS en Mac OS X. Especialment útil en cas de doble so.

1. Descarrega e Instal·la GIMP

2. Obra l’Imatge

3. Filtres -> Llums i Ombres -> Ombra

Simplement:

1. Instal·la ImageMagick

2.Configura les variables d’entorn:

export MAGICK_HOME="/opt/local/var/ImageMagick-6.5.3"
export PATH="/opt/local/var/ImageMagick-6.5.3/bin:$PATH"
export DYLD_LIBRARY_PATH="/opt/local/var/ImageMagick-6.5.3/lib"

3. Escala:

bash-3.2$ /opt/local/bin/mogrify -resize 525x700 image.jpg

(NOTA: Sobreescriu l’imatge (no crea una imatge nova))

Cada projecte de software és diferent, i té unes necessitats diferents i úniques, i com Edward Garson assenyala a El context és el rei:

“Crec que hi ha una certa ironia en l’intent de transmetre alguna cosa sobre els ideals de l’arquitectura, quan la premissa amb la què vull començar és que efectivament no hi ha ideals. Si això és així, llavors segurament no hi ha res a escriure, sóc una contradicció i en fer això, corro el risc de provocar la implosió de l’univers o alguna cosa així. “

No obstant això:

“Però, per desgràcia, Ceci n’est pas une pipe.”

Jo si crec que els projectes d’enginyeria de software comparteixen alguns problemes comuns (o almenys ho espero, qualsevol reforç moral és benvingut: l’enginyeria de software és una difícil disciplina on la desesperació és freqüent).

“97 Coses”, assenyala alguns dels temes i solucions que probablement haurien de ser aplicables a qualsevol projecte d’enginyeria de software.

Hi ha alguns noms grans i molts anys d’experiència darrere d’aquests aforismes de saviesa, i en la meva curta carrera fins al moment, he trobat molts dels problemes descrits en “97 Coses” en projectes passats i presents.

Atès que 97 coses són massa per la meva memòria a curt termini, aquestes són les 3 coses que m’esforçaré a recordar:

1. Tria la tecnologia més adequada

Molt sovint, la tecnologia escollida per a resoldre un determinat problema no és l’opció òptima.

Com s’indica en No posi el seu currículum per davant dels requisits, de vegades es trien tecnologies només perquè són “més recent que” o “més atractives que” altres tecnologies que serien més adequades.

En altres casos, la mateixa tecnologia s’utilitza una i altra vegada. No hi ha una talla única vàlida per a tots. En la majoria dels casos això és causat per un dels grans perills de l’enginyeria del programari: prevaler la idea de reutilitzar components / arquitectura / codi / disseny reutilització sobre qualsevol altre criteri. En molts casos, el problema s’adapta a utilitzar una solució existent, quan hauria de ser al revés. No he vist mal pitjor que els frameworks corporatius!

Probablement hauríem de “pensar fora de la solució” amb més freqüència, i triar la millor solució per a cada problema: L’heterogeneïtat guanya.

2. KISS i YAGNI

“Sempre Senzill, estúpid” i “No et farà faltal” són dos principis que apunten a resoldre un dels esculls més freqüents que em trobo: complexitat innecessària.

En Simplificar la complexitat essencial; disminuir la complexitat accidental Neal Ford explica aquest error (en un context de desenvolupador) a la perfecció:

“Els desenvolupadors es senten atrets per la complexitat com arnes a les flames, sovint amb el mateix resultat. La resolució de puzles és divertit, i els desenvolupadors són resol problemes. A qui no li agrada la satisfacció de resoldre un problema increïblement complex? No obstant això, en sistemes de software de gran escala, eliminar la complexitat accidental, mantenint la solució en un nivell de complexitat trivial, és el veritable repte “

També afegeix:

“Miri el percentatge de codi que té en una solució que aborda directament el problema de negoci davant del percentatge de codi que només serveix a alimentar la frontera entre l’aplicació i els usuaris”

Saber quan parar ( “perfecte” és el enemic de “el just”), No Siguis Llest, Assegura’t que les coses simples són simples i recorda que les solucions a prova de canvis no existeixen, l’arquitectura de l’aplicació determina el rendiment i l’ Àmbit de l’aplicació és l’enemic del seu èxit!

3. Coneix l’entorn

Si entens el domini i te n’adones que El context és el rei, hauries de ser capaç de desafiar les sol.licituds no necessitades del client que ofeguen el sistema, de Cercar el valor de la funcionalitat demanada i Quantificar demandes difuses.

Tot i que El Negoci Mana , si tenim coneixements suficients del domini, podem donar al client el que necessita, no el que vol, perquè el teu client no és el teu client.

I tota la resta …

Aquest només és el meu top 3 … però hi ha moltes altres coses que recordar.

En línia i gratuït … així que realment no hi ha excusa per no fer una ullada !

Després d’haver trobat aquest llibre en moltes llistes tipus “Llibres que un Enginyer de Programari ha de llegir”, vaig pensar a donar-li una oportunitat.

Això no serà un comentari a fons, ja que ja n’hi ha molts existents, sinó més aviat un resum de les idees que es quedaran amb mi després d’aquesta primera lectura.

El llibre de Michael tracta la problemàtica relacionada amb l’execució exitosa de sistemes de software en producció, i, encara que se centra en sistemes distribuïts d’alta disponibilitat i de gran escala, molts dels temes exposats poden ser aplicats a qualsevol sistema de software.

El llibre cobreix tots els possibles elements i capes de l’enginyeria de software que se m’ocorren: gestió, execució, proves, disseny, desenvolupament…, front-end, back-end, explotació, etc., i en lloc de tractar de respondre a totes les preguntes, més aviat intenta mostrar la bona direcció en la qual anar.

Aquest és, sens dubte, un llibre que segurament torni a llegir en el futur, ja que les idees i situacions que es quedaran amb mi després d’aquesta primera lectura són només aquelles que m’he trobat en projectes actuals i anteriors.

Estabilitat i Testeig

La primera part del llibre parla sobre estabilitat, i que s’ha de fer a fi d’aconseguir un sistema d’alta disponibilitat 24 / 7, i que sigui capaç de complir els estrictes requisits d’un SLA.

Un dels aspectes amb els quals m’he topat en la meva vida laboral, i que em va semblar de particular interès, va ser el tema de com i què exactament posar a prova quan s’intenta assegurar l’estabilitat del sistema.

Per exemple, el llibre esmenta l’ús d’un “sistema de proves malvat”: el sistema ha de ser maltractat i abusat de totes les possibles maneres que es puguin imaginar.

Això és una cosa que vaig trobar en el passat: la complexitat d’alguns projectes va fer impossible provar tots els casos funcionals.

En canvi, a l’estil reducció a l’absurd, es va assignar un cert període de temps en què el sistema va ser castigat a fi de trobar un estat inestable.

Si no és possible provar tot camí funcional per posar a prova l’estabilitat del sistema, llavors la recerca de la inestabilitat pot ajudar a trobar alguns punts febles.

Una altra idea amb què m’he topat, és que, en un escenari EAI / SOA / ESB, on el sistema es veu obligat a viure i a comunicar amb sistemes estranys i aliens, cada punt d’integració és un risc quant a l’estabilitat del sistema global.

Proves unitàries, proves funcionals, proves d’integració, assaigs punt a punt, proves de component… etc… totes posen a prova el comportament del sistema sota condicions normals, però saps com es comporta el sistema en condicions no esperades?

En efecte, per a cada punt d’integració, és important saber el que passa si el sistema rep respostes inesperades o inexistents.

El mateix pot dir-se en l’altre sentit: com reaccionen els altres sistemes si el nostre sistema envia respostes estranyes o inexistents?

Un altre tema que em va semblar interessant va ser que el de “Proves de Longevitat”.

La idea de proves de longevitat és executar proves similars a l’entorn de producció executant-se en un entorn similar al de producció, lliure d’arrencades i parades.

L’objectiu és detectar errors en el sistema que d’una altra manera serien difícilment detectats, tals com la temuda excepció OutOfMemory (i així evitar la vergonya de tenir rearrencades diàries de servidors en producció).

Monitoratge del Sistema i Ús de Recursos

Havent treballat en el passat en un rol Winston Wolf, és a dir, com a consultor tècnic, vaig aprendre l’important que és ser capaç de diagnosticar i vigilar fàcilment sistemes en entorns de producció.

Michael exposa això al seu llibre, i assenyala parts vitals del sistema que han de ser vigilats.

Un tema amb el que he torejat freqüentment, és probablement el mecanisme número un de seguiment de sistemes en producció: logging.

En la meva experiència, cada vegada que fa falta una sessió de depuració per corregir un error, i els logs no van ser suficients, sorgeix un risc: el sistema no va ser capaç de dir-nos una cosa important.

El simple fet de no registrar algunes informacions, podria fer de la correcció d’errors que apareixen en producció una tasca llarga i àrdua: de vegades les exportacions de dades, missatges i altres elements de producció no són possibles. La reproducció d’errors de producció en un entorn de desenvolupament per a l’anàlisi, pot ser difícil o fins i tot una tasca impossible.

Release it! també esmenta l’important que és comprendre exactament la forma en la qual el sistema usa recursos.

Aquests recursos varien dels “quatre grans” (CPU, memòria, emmagatzemament, ample de banda), a altres recursos com a pools de recursos, fils i qualsevol altre recurs.

Mètriques obtingudes en entorns de desenvolupament i producció poden ajudar a entendre per on el nostre sistema es pot trencar, i fins i tot evitar desastres futurs.

Després de llegir aquest llibre, segurament et converteixis en un recurs-paranoic, el que probablement sigui bo.

Cada vegada que treballis amb un pool de connexions, configuris un nivell d’aïllament, iniciïs una transacció, o fins i tot fins i tot quan estableixis una propietat de la JVM, és probable que et trobis preguntant-se què succeeix amb el teu sistema si no hi ha connexions disponibles, si la transacció fracassa o si el servidor d’aplicacions mor.

Arquitectura, Patrons i Antipatrons

Un altre tema important tractat al llibre és l’arquitectura del sistema, els patrons i antipatrons.

Una altra idea que comparteixo, i que em sembla bastant òbvia, però que mai no s’esmenta prou, és la idea que com més dependents siguin els sistemes entre ells, el més gran és el risc d’un error|fallada a nivell global.

I a això m’agradaria afegir, com més sistemes integrats, més risc.

La primera regla de la simplificació d’un escenari d’integració és l’eliminació de sistemes.

Si, per qualsevol raó (sent les causes més injustificables i freqüents, causes polítiques i contractuals) això no és possible, el llibre presenta diversos patrons per evitar dependències fortes entre els sistemes, així com exemples de com sol una forta dependència pot produir un error|fallada en tot el sistema.

Conclusió

Release it! és un llibre adequat per a persones que tenen alguna cosa d’experiència en portar un sistema de programari fins a producció.

El contingut exposat és prou ampli com per ser útil en gairebé qualsevol projecte de programari, encara que els lectors que treballin en sistemes distribuïts d’alta disponibilitat traguessin el major profit del llibre.

El llibre té un ritme meravellós, i Michael dóna exemples reals de com un sistema es pot trencar d’una manera espectacular i aterridora.

Fàcil de llegir i una font valuosa de coneixements, imprescindible!