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!

2. Crida la url REST amb curl, parseja el xml, i transforma el resultat en un array:

	$ch=curl_init();
	$curl_post_data = array(
		"method" => "flickr.photos.search",
		"api_key" => $api_key,
		"lat" => $lat,
		"lon" => $lon,
		"radius_units" => "km",
		"has_geo" => "1",
		"radius" => $radius,
		"accuracy" => $accuracy,
		"min_taken_date" => $min_taken_date,
		"max_taken_date" => $max_taken_date,
	);
	curl_setopt($ch, CURLOPT_URL, 'http://api.flickr.com/services/rest/');
	curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
	curl_setopt($ch, CURLOPT_POST, true);
	curl_setopt($ch, CURLOPT_POSTFIELDS, $curl_post_data);
	$xmlstr=curl_exec($ch);
	curl_close($ch);
	$xml = new SimpleXMLElement($xmlstr);
	$totalresults=$xml->photos['total'];
	$photoresults = array();
	if ($totalresults!=0){
		foreach ($xml->photos->photo as $photo) {
			$photoinfotmp=array();
			$photoinfotmp['id']=$photo['id'];
			$photoinfotmp['owner']=$photo['owner'];
			$photoinfotmp['secret']=$photo['secret'];
			$photoinfotmp['server']=$photo['server'];
			$photoinfotmp['farm']=$photo['farm'];
			$photoinfotmp['title']=$photo['title'];
			$photoinfotmp['ispublic']=$photo['ispublic'];
			$photoinfotmp['isfriend']=$photo['isfriend'];
			$photoinfotmp['isfamily']=$photo['isfamily'];
			$photoinfotmp['url']="http://farm".$photoinfotmp['farm'];
                        $photoinfotmp['url']=$photoinfotmp['url'].$photoinfotmp['server'];
                        $photoinfotmp['url']=$photoinfotmp['url']."/".$photoinfotmp['id'];
                        $photoinfotmp['url']=$photoinfotmp['url']."_".$photo['secret'].".jpg";
			$photoresults[]=$photoinfotmp;
		}
	}

NOTA: Per algún motiu, la crida a la url REST amb file_get_contents o curl amb GET en lloc de POST no retorna els resultats correctes…

Independentment de les raons per les quals un vol saber el grau de la seva presència en Internet, com ego o curiositat, la idea ha esdevingut una pràctica comuna, i fins i tot han aparegut termes per identificar aquest fenòmen.

Noves maneres de consultar la web es fan possibles en gairebé la mateixa freqüència en què noves maneres de compartir informació apareixen, i amb l’avenç de la Web Semàntica, és increïblement fàcil d’explorar la web de diferents maneres.

Mentres pensava en aquesta idea, em preguntava si seria possible la auto recerca de mi mateix en Flickr.

Per exemple, gràcies a l’API de flickr, és possible consultar la base de fotos de flickr de manera innovadora, com per exemple integrant Flickr amb la versió semàntica de Wikipedia.

En el moment d’escriure aquest text, flickr té més de 80 milions fotografies etiquetades geogràficament.

Jo també tinc una base de fotos amb informació goegràfica.

Podria ser possible trobar-me a mi mateix a la foto d’algú, en algun lloc en segon pla?

Per a cadascuna de les meves fotos, he creat un enllaç que permet consultar flickr per a les fotos que es van prendre en més o menys el mateix moment i en més o menys, el mateix lloc.

Informació sobre la data i hora, i localització geogràfica s’extreuen de cada foto, i s’utilitzen com a criteris de recerca per a la crida a l’API de Flickr.

De moment, no he aconseguit trobar-me a mi mateix a la foto d’algú, encara que els resultats són sorprenents: algunes fotos van ser fetes gairebé al mateix temps i gairebé al mateix lloc.

En teoria, la possibilitat de trobar-me a mi mateix hauria d’augmentar dia a dia, a mesura que els usuaris segueixen adoptant les tecnologies d’etiquetatge geogràfic de fotos.

Pensant en el futur, hauria de ser possible incloure en la recerca a altres llocs per compartir fotos que ofereixen crides per API, i pensant en una escala major, es podria fins i tot considerar executanr consultes de forma permanent, i analitzar els resultats amb aplicacions de detecció de cares per exemple…

La pregunta que queda per contestar és si tot això és només una forma de diversió egocéntrica a la On és Wally?, o si aquesta i altres idees similars són alguna a comentar per la pròxima trobada amb un VC…