Durant la primera guerra mundial i un cop superada la primera fase de la gran ofensiva alemanya, els estrategues del Kaiser i més concretament, el tinent-coronel Richard Hentsch va veure evident que el gran pla de derrotar França per la via ràpida, el pla Schlieffen, havia fracassat.

A principis de setembre del 1914, els soldats alemanys participants en l’ofensiva nord, sota les ordres de Hentsch, van situar-se en posicions favorables i es van posar a cavar trinxeres. Unes fortificacions que definiren els anys següents de la guerra i que no es mourien, -almenys les del front nord de París- fins el 1917.

En el bàndol alemany, Hentsch seria rellevat pel general Erich von Falkenhayn, pero les defences ja estaven apunt. Així va començar una guerra sagnant de trinxeres, on quedava clar cap a on s’havia de disparar i qui era l’enemic, fos quin fos el bàndol.

Els temps canvien i els conflictes també. La segona guerra mundial, amb la Blitzkrieg, la modernització dels carros blindats i l’aviació deixarien l’atrinxerament estàtic en el passat.

La competència en els mitjans de comunicació en el passat

En temps més moderns, el conflicte entre els mitjans de comunicació ha estat de ‘trinxeres’. Primerament, la competència es limitava a les empreses d’un mateix país, regió, àrea d’influència lingüística o cultural.

Els continguts internacionals, com la CNN o la MTV tenien un impacte limitat tot i emetre’s bàsicament en obert. Entre altres raons com poden ser la òbvia barrera idiomàtica trobem la dificultat tecnològica d’instal·lar i operar un receptor de satèl·lit.

Eren dies més feliços, els mitjans nacionals o regionals coneixien molt bé als seus rivals de l’altre costat de la trinxera. En el cas de la televisió i la ràdio, per exemple, l’accés a una llicència d’emissió el regula l’administració, creant unes barreres d’accés immenses. A més, el cost de les infraestructures d’emissió, sobretot en el cas de la TV, eren i són molt grans, o si no que li ho preguntin a la xarxa de televisions locals. Les despeses de distribució de la premsa escrita tampoc són

Aquests temps es marcaven per uns canvis de quota de mercat relativament petits i uns canvis en els hàbits de consum gairebé inexistents. No costa gaire d’imaginar en el temps de la ‘primera cadena’ en l’estat Espanyol com en moltes llars no es canviava mai de canal.

D’aquestes barreres d’entrada, la relativa escassetat d’alternatives i en alguns casos també la qualitat dels continguts va fonamentar el model de negoci basat en la publicitat encara en ús avui en dia (sí, sí, sumat a altres d’auxiliars).
Sense cap mena de dubte, l’exemple més clar és quan costa el fet que surti el logo de la teva empresa per pantalla durant 20 segons.

Segons Oblicua, un espot en prime time a Telecinco pot arribar a costar 20.000€. Això sense comptar agències i intermediaris, la realització de l’espot en sí, etc.

Desde els temps del naixement de la premsa escrita els grans grups i empreses de comunicació es van fonamentar, crèixer i consolidar en aquesta situació. Molts cops aprofitant la tecnologia anterior com a plataforma de llançament, com en el cas de la BBC passant de fer ràdio a fer també tele.

L’arribada de les noves tecnologies i sobretot la Web va suposar evidentment una gran revolució a moltíssims nivells. Al principi, però els canvis tecnològics feien endevinar grans coses a uns pocs gurús però tampoc semblava que arribessin a tenir tant impacte.

Tal com va passar amb els primers carros blindats, inventats i desplegats a la Gran Guerra. Eren lents, relativament poc efectius i amb molta tendència a deixar els soldats ‘tirats’. Pocs anys més tard els tancs serien claus pels Nazis, ajudant a conquerir mitja Europa amb atacs llampec.

L’atac del contingut generat per l’usuari

Tornant al passat recent. L’advent de la Web en sí i sobretot del UGC (Contingut Generat per l’Usuari) amb la popularització de YouTube (creat al 2005) van fer presagiar a uns quants d’aquests gurus la “desaparició” o si més no la decadència dels mitjans tradicionals. Va ser una moda divertida i de fet, encara hi ha gurús que ho prediquen.

Qualsevol persona que hagi provat de fer un curt de cinema o tele sabrà que fer continguts de qualitat no és gens fàcil, ni normalment tampoc barat. Per molt accessible que sigui la tecnologia de blogs, WordPress, etc. escriure un bon article o tutorial comporta feina i fer una recerca com toca. Tampoc ens emocionem i ens ajuntem amb els ‘gurús’. Com a mínim es necessita una bona història i no surten de totes les pedres, per moltes Red One que es comprin.

En el moment de començar a escriure aquest post, fent una mirada als vídeos més vistos a tot el món a YouTube ens dóna

1.- ‘My Tram Experience‘
En aquest cas UGC i del bo.

2.- We Found Love – Rihanna feat. Calvin Harris (Boyce Avenue piano acoustic cover) on iTunes
Vídeo professional, links al iTunes inclosos. Per cert el Calvin Harris sona molt retocat i tampoc us perdeu la caixa flamenca. Pot semblar més o menys fluixet però la iluminació no està feta amb unes bombetes de baix consum.

3.- Beyoncé – Dance For You

Professional.

4.- Exclusive: Miley says ‘Weed my lips!’
Vídeo capturat amb un mòbil però publicat pel ‘The Daily‘, un diari per iPad digital. Low-cost, però un mitjà professional. A no ser que us agradi el ‘gossip’ groguenc UK no cal que cliqueu a l’enllaç.

5.- Aaron Dobson “The Catch”

Professional. No us perdeu la recepció del Dobson, espectacular.

6.- Fail Compilation November 2011 || TNL

UGC, amb alguna part extreta de contingut pro. Veient-ne alguns fragments hom es pregunta com pot ser que la raça humana hagi sobreviscut fins ara. Excepte el trosset amb uns castellers fent llenya, que al personatge creador de la compilació deu ser l’únic a qui li fa gràcia. Pels colors semblen els Minyons de Terrassa.

No és un estudi científic però tampoc es podria dir que pel contingut en sí els mitjans i productores es vegin molt amenaçats directament pel que fa a la qualitat. A més, últimament es veuen molts anuncis al YouTube, amb part dels ingressos que van a parar als creadors del contingut. No és preocupant, de moment, però val la pena tenir-hi un ull posat per veure com evoluciona.

Avui en dia, i tal com reflexa aquesta prova informal, es podria dir que la ‘moda’ del UGC ha minvat i s’ha acabat assemblat una mica al contingut més ‘mainstream’.

La següent era: la vinguda de les xarxes socials

Les coses han canviat i la natura de la xarxa evoluciona molt ràpidament, el conflicte, muta. Com si res, passem d’una gran guerra a una altra.
Amb l’explosió de l’ús de les xarxes socials, com pot ser Facebook, amb un creixement espectacular en els últims anys.

I quin impacte té, l’ofensiva de les xarxes socials en els mitjans de comunicació?

El primer impacte: les URLs

Es pot començar per molts llocs, però començem per una de les eines d’accés als continguts online més importants: les adreçes URL.

Bé, agafem per exemple l’excel·lent programa de RAC1 ‘La Competència’ i les següents URLs:

http://www.facebook.com/lacompetencia
http://twitter.com/lacompetencia

O en les del conegut programa de debats esportius Punto Pelota de Josep Pedrerol:

https://www.facebook.com/puntopelota
https://twitter.com/puntopelota

En aquestes URLs i en les de molts productes audiovisuals i de comunicació no surt enlloc la marca mare, el diari, cadena de ràdio o televisió que creen aquest contingut.

Resultat: la marca mare es dilueix cada vegada que es publiquen, esmenten, visualitzen o comuniquen aquestes adreçes. I a més, la marca contenidora de la xarxa social en qüestió va sempre primer.

En el cas del Twitter, si s’utilitzen hash tags per promocionar continguts com es fa per exemple en algunes sèries americanes posant el tag com una mosca discreta llavors es l’impacte és menor (com passa per exemple amb la promo de Twitter que es fa a la sèrie Fringe).

Tot i que l’accés a la Web avui en dia es fa en un percentatge significatiu amb el cercador Google, no podem descartar l’impacte debilitant en les marques ‘mare’ pel fet que brillin per la seva absència en les URLs publicitades.

En defensa de les xarxes: el tràfic d’entrada

Dins del tema de l’accés i els sitemes d’entrada als continguts interactius dels mitjans, si es miren les dades de seguida podem comprovar que un percentatge molt gran ens ve de les pròpies xarxes socials, apart del que pugui venir directament o del cercador de Google.

Clar, amb la immensa promoció que s’en fa…

Escoltem el programa d’avui de La Competència:

Mencions de RAC1: 12 (inclou les auto promos i la careta del programa)
Mencions de ‘La Competència’: 14
Mencions de FaceBook: 2
Mencions de Twitter: 2

Proporcionalment, no són moltes mencions, però es produeixen a cada programa, tot l’any. Els anunciants també surten, però no a cada programa i ni molt menys tota la temporada, si no és pagant, és clar.
Quantes setmanes té la temporada? 42? Això són 42x5x4=840.

“Hola, RAC1?!? Voldria que l’Òscar Dalmau digués el nom de la meva marca mil cops per temporada. Quan val?”

El ‘preu’ de la publicitat

Fem uns càlculs ràpids.

Segons Radioes.net, a la província de Barcelona hi ha 124 emissores, a Lleida 51, a Girona 54 i a Tarragona 43. Si considerem un solapament de les ràdios a nivell català d’un 40% ens queden unes 160 amb números rodons. Per tant, si cada emissora té 10 programes que fan 1000 esments per temporada i tenim 160x10x1000 = 1.6 milions d’esments per temporada a la ràdio catalana. Multipliquem per 50 a Espanya i fent números rodons ens quedem diguem amb 70 milions d’esments per temporada.

Estem parlant de mini promocions fetes per locutors amb molta credibilitat i de personatges famosos, de forma contínua, uniforme i en totes les emissores

Si afegim els mitjans televisius quants centenars de milers o milions de ‘promos’ més per temporada llavors tenim?

Si recordem, un espot de tele pot arribar a costar 20.000€ en prime-time, quan la gent desconnecta o va al lavabo. Però integrats en el propi programa tal com passen aquestes mini promos és força més efectiu i impactant. Si es quantifica el cost en euros d’aquesta publicitat quan valdria? Milions d’euros? Una campanya per tot el país, en tots els mitjans de comunicació, en boca de conductors, presentadors, locutors i personatges famosos, en mitjans grans i petits.

I tot això a cost zero per Facebook i Twitter.

Clar que ve tràfic de les xarxes socials, només faltaria, amb la publicitat que se’ls està regalant. És una promesa feta realitat, les accions d’un profeta que fan que es compleixin els seus auguris.

La segona línia de defensa: l’efectivitat tècnica de les xarxes socials

Només cal ser usuari actiu de Facebook o Twitter per comprovar que són productes interactius excel·lents. Són funcionalment molt bons, amb un disseny espartà però funcional i distintiu, una estabilitat a prova de bomba i un temps de resposta rapidíssim. A més, constantment van evolucionant i afegint millores, sobretot en el cas de Facebook, que té una política més expansiva.

Els equips de producte i desenvolupament tècnic d’aquestes empreses són modèlics, amb plantilles motivades, joves, dinàmiques, molt ben preparades i a sobre ben pagades. La seva orientació a producte és total i absoluta, per alguna cosa Mark Zuckerberg va ser tutelat per Steve Jobs (un dels millors si no el millor cap de producte de la història).

Comparat amb aquesta efectivitat, els productes d’interacció fets a casa dels mitjans de comunicació acostumen a ser molt dignes però molt sovint no arriben a assolir el mateix nivell d’excel·lència. Ja siguin fets a mida, comprats o adaptats de codi lliure, els equips de producte i desenvolupament que els despleguen estan molts cops infradimensionats i amb una orientació diferent. A vegades també comparteixen responsabilitats amb els aspectes tècnics i de concepte de l’activitat pròpia d’un mitjà de comunicació. El dimensionament i l’encaix de la interactivitat en un mitjà tradicional encara no està del tot resolt. L’outsourcing o la compra de productes claus en mà tampoc sembla ser la solució perquè no deixa de ser una porta fàcil de sortida que rebaixa la capacitat de diferenciació de producte, homologant el servei d’un mitjà a la resta.

Amb aquesta situació els mitjans competeixen amb els equips estrella de les xarxes socials amb totes les de perdre. Els productes de Facebook i Twitter funcionen millor, són més estables i a sobre, són “gratis”. Cada cop més, els mitjans aposten més fort per deixar de banda els productes d’interacció propis i centrar-se en els productes enllaunats que ens ofereixen les xarxes socials.

Per veure el que ens ha portat fins aquí hem d’entrar en l’àmbit de l’economia a gran escala. A Superfreakonomics, de l’economista Steven D. Levitt i el periodista Stephen J. Dubner, es donen detalls de l’impacte dels incentius en els processos globals. Concretament parlen del concepte en economia de l’externalitat. L’externalitat és el que passa quan una persona emprèn una acció però totes o part de les conseqüències les paga algú altre i sense tenir cap acord.

Un bon exemple d’externalitat són els gasos que desprenem en la nostra activitat diària que es sumen a l’efecte hivernacle i possiblement a l’escalfament global. La tecnologia actual és tant potent que emmascara les conseqüències de les nostres accions, com passa quan posem l’aire acondicionat a tope i no veiem pas el fum de la central tèrmica que ens dóna l’energia necessària, com tampoc les deixalleries situades en països del tercer món.

En aquesta línia, desenvolupar o integrar productes interactius de qualitat requereix molt temps i esforç, essent els guanys més substancials molt a llarg termini. Aquests incentius contrastats amb la facilitat d’implantació dels productes de sindicació de Facebook i Twitter fan que els mitjans es vagin decantant per la via de les xarxes socials. L’impacte que cada acció és una externalitat que té unes conseqüencies per la indústria reals però llunyanes i impercebtibles. I sentim frases com: “ja se n’encarregarà algú altre, de competir amb ells”, “això és cosa de la privada”, “de la pública”, “nosaltres som massa petits, això els grans mitjans”, etc.

Cada petita acció, cada tuit i cada post, són externalitats que alimenten els gegants.

La tercera defensa: “som un mitjà”

Potser la frase més repetida per alguns escèptics seria: “nosaltres som un mitjà de comunicació, no pas una empresa tecnològica, per tant ens quedem amb Facebook”. Una afirmació ben certa i potser definint una estratègia ‘guanyadora’. Guanyadora si no fos pel fet que Facebook i Twitter també són mitjans de comunicació. Mitjans que en plantilla només tenen equips de producte i desenvolupament i que externalitzen tots els seus continguts (i gratis).

Twitter i Facebook, mitjans de comunicació?

Examinem, per exemple el model de negoci de Facebook. Facebook ven publicitat als seus clients que són els anunciants per obtenir impressions publicitàries generades pels seus usuaris. Degut a les dades extenses sobre els mateixos i la seva activitat, pot oferir anuncis als seus clients dirigits a públics molt concrets. A més, els continguts són tots externs, regalats a cost zero pels propis usuaris i els diferents mitjans de comunicació.

Un mitjà de comunicació televisiu ven publicitat als seus clients que són els anunciants per obtenir impressions publicitàries vistes per la seva audiència. Degut als diferents canals, programes i franges horàries, pot oferir anuncis als seus clients dirigits a públic més o menys concrets. Ah, els continguts són tant interns com externs i costen molts diners.

No hi ha gaires diferències. Sí, que els continguts no hi són en la seva totalitat a Facebook, però en són com a mínim els aparadors i sovint els contenidors. L’altra diferència és que a Facebook només hi ha equips de desenvolupament (i comercials!).

L’última línia de defensa: l’autopreservació de la xarxa social

Apart dels formidables arguments presentats, resta el potent efecte ‘xarxa’ i d’autopreservació de les xarxes socials amb suficient massa crítica. Richard Dawkins en parla d’efectes similars a ‘The Extended Phenotype‘, ‘The Selfish Gene‘ i a ‘The God Delusion‘, encunyant els termes ‘replicador’ (replicator) i ‘meme’.

Segons Dawkins, un replicador és un “qualsevol cosa en l’univers de la que s’en fan còpies”, amb els gens i l’ADN com a exemples paradigmàtics. En canvi, un ‘meme’ és un replicador cultural, una idea que s’autoreplica i viu en les persones. O tal com diu el mateix Cobb en la fantàstica película de Christopher Nolan, Inception

“What is the most resilient parasite? Bacteria? A virus? An intestinal worm?
An idea. Resilient… highly contagious. Once an idea has taken hold of the brain it’s almost impossible to eradicate. An idea that is fully formed – fully understood – that sticks; right in there somewhere. “

L’essència d’una xarxa social és una idea brillant que es replica de cervell a cervell, de persona a persona, de follower a follower. Per exemple, Facebook només és útil si també ho utilitzen les coneixençes dels propis usuaris, que treballen activament perque sigui així. La pròpia idea d’una xarxa social en sí treballa perque el meme es repliqui de forma molt activa. Si no s’escampa la idea no val la pena ser usuari d’una xarxa social. Aquesta capacitat de replicació fa que un cop s’agafa suficient massa crítica l’estabilitat de la xarxa és molt gran, i d’alguna manera, es sustenta a sí mateixa.

Els memes dels mitjans tradicionals no requereixen ni tampoc busquen de forma tant agressiva la replicació activa i a més, la creixent aparició del contingut sota-demanda fa la replicació en tals mitjans no sigui tant necessària com abans. Abans de l’aparició de la Web i el vídeo IP amb la seva multitud de formes, els televidents veien els continguts prime-time al vespre i els comentaven l’endemà a la feina, a l’escola, etc. Una forma efectiva de replicació però que ja no s’estila tant, en pro de la Web i les xarxes socials.

El nou conflicte global

A diferència de molts mitjans, Google ha sabut reconèixer la naturalesa de l’adversari, ha establert els fronts, cavat les trinxeres i passat a l’ofensiva amb Google+.

El model de negoci del cercador de Google també es basa en la publicitat, en un 96% l’any 2011 i en aquesta línia, Google aconsegueix tants diners a canvi de presentar anuncis rellevants als seus usuaris en base al seu comportament i a les cerques. Certament es tracta d’un model molt similar al de Facebook i Twitter. Google ha sabut veure l’existència del conflicte i preveure que en vindran de més madures conforme es vagi enforting la relació directa entre anunciants, marques i els usuaris a traves de les xarxes socials.

D’aquí el llançament de Google+ i seva la potserior vinculació amb el producte estrella, el cercador. Sense cap dubte, Google ha sabut reconèixer els fronts principals que té oberts tot i que potser en són masses, tal com li va passar als imperis alemany i austrohongarès.

Potser, tal com fa Google, els mitjans de comunicació tradicionals han de reconèixer l’existència del conflicte. Aquest seria el primer pas i que donaria pas a l’acció més important, la definició d’una estratègia unificada i coherent. Com qualsevol estratègia, hi han riscos i avantatges en qualsevol de les accions, alguns exemples:

• Aliança completa amb Facebook i Twitter: establir una política d’immersió completa, esperant que la resta de mitjans de la competència no ho facin tant bé i viure en comfort a l’ombra d’aquests gegants de la comunicació global. Els avantatges principals d’aquesta estratègia oportunista són el baix cost, el guany de tràfic a curt termini i la simplicitat. El desavantatge és la pèrdua de la relació directa amb els usuaris i la supeditació a l’estratègia de tercers.
• Crear-se la xarxa social pròpia, només viable realment en mitjans amb moltíssima massa crítica i una capacitat de crear producte de primer nivell. Amb un cost i riscs elevats, es manté el coneixement a la casa i es fidelitza directament als usuaris.
• Unificar la comunicació i vehicular-la a través de productes propis: en comptes de publicitar les URLs de la competència, comunicar estrictament només URLs del propi mitjà, on es poden trobar llavors els diferents accessos a les xarxes socials més les eines de participació pròpies i alienes. La comunicació de la participació s’unifica i simplifica mentres s’espera cap a on bufa el vent.

Sigui quina sigui l’estratègia, no es pot deixar res a l’atzar i els controls interns sobre les marques, els canals de participació i fidelització han de ser més grans que mai, a risc d’acabar com els perdedors d’aquest gran conflicte. En la Gran Guerra, Europa es va redibuixar, imperis sencers que semblaven inamovibles van caure i les coses van canviar per sempre, almenys fins al següent conflicte.

Introducing Maven and testing

It is well known and accepted that the Maven build system from Apache is very powerful and capable. It is also easy to use and hard to master.

Countless plugins to extend its functionality can be found.

One of the main functionalities offered by Maven is assisting in various levels of testing, made possible by some powerful plugins.

In building and testing software, individual software components and classes should be unit tested using mockup objects and at a level of granularity that is independent of any services being available, both internal and external.

In this case Maven offers very good solutions, such as the ubiquitous Surefire plugin. Using this plugin unit testing with a variety of testing frameworks is quite straightforward and easy.

On the other hand, Integration Testing is done at a higher level, verifying that the integration between components, both internal and external is done correctly and to help identify problematic areas. Once a faulty integration is discovered, its unit test results can be examined in detail or if it is an external system, further diagnostics on it can be run.

Good judgement on the programmer is key to apply testing at the most convenient levels though on large enterprise systems usually a combination of unit testing and integration testing is most appropriate.

Though less well known than Surefire, Maven offers the Failsafe plugin, designed specifically for integration testing.

It is interesting to note that the name has been chosen to emphasize that failures don’t stop the Maven lifecycle allowing for gracefully cleaning up any resources used during the testing. As resources can be external it i risky -and rather inelegant- not to clean them up correctly.

According to the Failsafe documentation, it needs to be attached to the integration-test and verify phases (though it seems to work if attached only to the integration-phase). In any case, once invoked it runs through the relevant goals and relevant tests are run.

Testing FTP and SFTP functionality under Maven

We have discussed instances of problems where powerful, established plugins are available to do what we want (in this case, testing). However, we need to do something in Maven for where there are no plugins or they are not easy to find. Look it up twice as it is quite likely someone else has solved the problem before though it may be the case no solution exists.

One of such problems is testing systems that depend on external services such as FTP or SFTP. Say we have a client that downloads some data off such a server, such as XML files or large binaries and no other interface is available.

A good non-legacy example of such a service is YouTube’s API.

Even though YouTube offers programmatic APIs in Java for instance, to use more advanced functionality and for efficient bulk uploading an SFTP interface needs to be used. There are many other examples of such services, using both FTP and SFTP.

Unit tests on the system can be done with mockup objects as usual. However, to do integration testing things get more interesting.

We could, of course, use our YouTube production service to do some integration tests using dummy files, etc. Using production for testing is usually not a very good idea, with potential for disaster. Therefore, using the YouTube production service is not advisable.

Ideally, we should be able to create a mock but fully functional FTP environment, containing exactly the files we need where we can upload and download whatever is necessary and if needed, a small script (say, groovy or something) that simulates whatever it is that YouTube does with your files behind the scenes.

The basic workflow would look like this:

Therefore, we need a plugin that fires up a FTP server and points users to specific areas of the target folder. Ideally, it fires up during the pre-integration-test phase and shuts down on the post-integration-test. Easy as a cake.
A google search of ‘maven ftp server plugin‘ yields no significant results and looking up on the official list of plugins here. Also doing a google code search is of no use, either. Lots of stuff to perform FTPs and file transfers but no starting up servers.

Instead of giving up or firing up some server using Ant or even worse, manually(!), we go on and do it the Maven way.

Namely, we develop a plugin that fires up an (S)FTP server on the desired integration test phases.

Firstly, we need a FTP backbone written in Java so it can be integrated easily and of a suitable license. The Apache FtpServer is perfect for that purpose. It is a high-performance server based on Apache MINA for I/O and it is ridiculously easy to embed from any Java app.

Creating the Maven plugin basics

Firstly, we create a plugin skeleton project using the Maven Archetype plugin:

mvn org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7:create -DgroupId=cat.calidos.maven.ftpserver -DartifactId=ftpserver-maven-plugin -DarchetypeArtifactId=maven-archetype-plugin -DarchetypeGroupId=org.apache.maven.archetypes

This creates an empty Maven plugin project ready to start adding stuff such as code and tests. We also need to run

mvn eclipse:eclipse

to create Eclipse settings for the project. We also need to run it whenever we add new dependencies to the POM file so they are also included in the Eclipse world.

Firstly, we add the dependencies for the Apache Ftp server (*):

	
		org.apache.ftpserver
		ftpserver-core
		1.0.6
	
	
		org.apache.ftpserver
		ftplet-api
		1.0.6
	
	
		org.slf4j
		slf4j-api
		1.6.1
	
	
		org.slf4j
		slf4j-log4j12
		1.6.1
	

We can find the details on dependencies and versions on a Maven repo such as MVNrepository.

In this case, we also add the Simple Logging Facade for Java ‘Log4j’ implementation< so the ftp server can output logs.

This means that whenever we use the maven plugin we should provide a log4j configuration file through the usual methods. Plugin will still work but will complain about the missing configuration. In any case, should we desire to use another logging framework we only need to change the dependency to our chosen implementation artifact.

Adding our first mojo

Next, we need to start adding some ‘mojos‘, or ‘Maven plain Old Java Object’, which are the fine-grained goals we need to run (or what is the same, tasks that we want Maven to execute). For more information, read the Introduction to the Build Lifecycle article on the official documentation which is very clarifying and chock full of valuable information.

Examining the source of other Maven plugins, we observe a common enough pattern which is to have an abstract superclass with some of the attributes needed by our mojos.

public abstract class AbstractFtpServerMojo extends AbstractMojo {

On this class we can add common attributes to our mojos such as the Maven project instance

/** Encompassing maven project
*	@parameter default-value="${project}"
* 	@required
* 	@readonly
*/
protected MavenProject mavenProject;

To the attributes we add the revelant annotations which let the Maven runtime inject following the popular Inversion of Control pattern. More documentation on the annotations can be found on the Mojo API Specification.

Basically, we need one mojo to start the server at the ‘pre-integration-test’ phase and another to stop it at the ‘post-integration-test’ phase, which gives us this a class hierarchy like this:

Ok, so now we need to take a look at the Apache Ftp Server documentation to discover how to embed it.

Fortunately it is pretty straightforward. A server factory instance is created from which a server instance can be created and attached to a specific port. Any such configuration such as adding users, setting up SSL keystores or port and interface attachment are configured using ‘listeners‘, which are configuration classes. Multiple listener instances can be set onto the same instance, to allow for multiple interfaces, etc. In the case of this example plugin we aim to configure a subset of all setup possibilities as it is only for integration testing and shouldn’t be used to deploy production FTP servers. For proper deployment, it can be run and configured fully from the command line or as a Windows service very easily.

Ok, so we add a method to the ‘run’ mojo to create the relevant instances

/** Create a server instance with default values
*///////////////////////////////////////////////////////////////////////////////
private void initServer() {

	// add relevant system property variables
	if (systemPropertyVariables!=null) {
		Set propertyNames = systemPropertyVariables.keySet();
		for (Iterator iterator = propertyNames.iterator(); iterator.hasNext();) {
			String propertyName = (String) iterator.next();
			String propertyValue = (String) systemPropertyVariables.get(propertyName);
			getLog().debug("Setting system variable '"+propertyName+"'");
			System.setProperty(propertyName, propertyValue);
		}
	}

	serverFactory = new FtpServerFactory();
	factory = new ListenerFactory();

	// set the port of the listener
	getLog().debug("Using port "+port);
	factory.setPort(port);
	serverFactory.addListener("default", factory.createListener());
	server = serverFactory.createServer();

}	// initServer

Firstly, we add any system variables that our POM wants to have added to our environment. This is a common pattern on many plugins and allows plugin users to fine tune system properties on that particular plugin environment. A very important possibility is to be able to configure a custom location of the log4j configuration using the ‘log4j.configuration’ system variable. For another example of setting system properties you can look at the excellent Jetty Maven plugin.

As properties are just key-value pairs of strings, we allow for the Maven injection to inject them defining the appropriate attribute parameter.

/** Additional system property variables (to pass onto tests, etc.)
*	@parameter
*/
protected Map systemPropertyVariables;

Secondly, we create the factory, listener and server instance. To make use of the more sophisticated features of the Apache Ftp Server we would only need to modify this method a little bit, for instance to allow to bind to a different network interface, etc.

Adding user management

Another common enough configuration that is definitely needed is user setup, including password setup, write permissions, home location, simultaneous logins, etc.

Examining the documentation we see a simple yet very flexible API to manage users. An interface to an user manager class is provided, ‘org.apache.ftpserver.ftplet.UserManager’ and two ready made implementations are available: a properties-based manager and a database-based one. This is very convenient and we could easily have the mojo provide database connection details or a path to a property file. However, we would rather provide configuration details on the POM file itself so all settings are selfcontained in the Maven world.

This means we need a simple factory, user manager and a trivial user class, where all user details are created in Java code.

We start by creating a skeleton factory:

public class SimpleUserManagerFactory implements UserManagerFactory {

And fill the necessary methods, in this case, only the ‘createUserManager’ method.
We follow by creating a simple User class:

public class User implements org.apache.ftpserver.ftplet.User  {

We shouldn’t really use the Ftp Server User implementation ‘BaseUser’ for two reasons: a) it’s in a private implementation package ‘impl’ on ftpserver-core so it can’t really be used (the interface is public and resides in the ftplet-api library) and b) we want to populate its details through the POM file so we need to add appropriate Maven annotations to its attributes.

It is no big deal as it is an easy enough interface to implement, with several key-value pairs, related to the different settings users can have such as maximum number of logins, username, password, etc. We tag the attributes with the Maven annotations and implement all the interface methods.

/** @parameter
*	@required */
protected String name;

/** @parameter
*	@required */
protected String password;

Creating the user manager is also pretty straightforward, implementing the UserManager interface of the ftplet API:

public class SimpleUserManager implements UserManager {

As a ‘repository’ to hold the User data we employ a simple in-memory Map instance:

private HashMap	users;

The resulting class structure is clear in its intent and purpose:

Testing user management code

Both the manager and the manager factory classes are pretty much self-contained it is fairly easy to create tests for most of that functionality. For example. in the case of the user manager, on the setUp() jUnit method we create a sample environment which we use on each test.

/* (non-Javadoc)
* @see junit.framework.TestCase#setUp()
*///////////////////////////////////////////////////////////////////////////////
protected void setUp() throws Exception {

	super.setUp();

	String adminName = "admin";
	userManager = new SimpleUserManager(adminName,new ClearTextPasswordEncryptor(),false);
	saveUser("demo","demo");
	saveUser("demo2","demo");
	saveUser(adminName,"administrator");

}	// setUp

Note that we use the clear text password encryptor both on the test and on the functional code as the passwords are only stored in memory therefore they do not really need to be encrypted and they are in plain view in the POM file anyway.

Using the sample environment we test functionality of the user manager:

/**
* Test method for {@link cat.calidos.maven.ftpserver.users.SimpleUserManager#authenticate(org.apache.ftpserver.ftplet.Authentication)}.
*///////////////////////////////////////////////////////////////////////////////
public void testAuthenticate() {

	loginShouldWork("demo", "demo");
	loginShouldFail("demo", "FAIL");
	loginShouldFail("DOESNTEXIST", "whatever");
	loginShouldWork("admin", "administrator");
	loginShouldFail("admin", "FAIL");

}	// testAuthenticate

Methods ‘saveUser’, ‘loginShouldWork’ and ‘loginShouldFail’ are private convenience methods to aid in testing and make tests more readable, tests are still code and should be readable and well-structured like regular functional code.

Run server mojo

Next, we add some code to have our configured FTP server instance run:

/** Startup the server and store it on the project properties if possible
*	@throws MojoFailureException
*//////////////////////////////////////////////////////////////////////////////
private void runServer() throws MojoFailureException {

	getLog().debug("About to start FTP server...");

	try {

		server.start();
		getLog().info("FTP server started.");

	} catch (FtpException e) {

		getLog().error("Could not start FTP server...");
		throw new MojoFailureException("Could not start FTP server instance", e);

	}

	Properties properties = null;
	if (mavenProject!=null) {
		properties = mavenProject.getProperties();
		properties.put(FtpServerConstants.FTPSERVER_KEY, server);
	} else {
		throw new MojoFailureException("Can't add ftpserver instance as maven project is null");
	}

}	// runServer

The ‘start’ method does not block and creates a new thread, where the server code will run and listen for upcoming connections. We also add the instance to the project properties so the server can be stopped gracefully on the ‘post-integration-test’ phase.

Also, we do not forget to add the annotation to the ‘FtpServerRunMojo’ class that binds the run mojo to the ‘pre-integration-test’ phase:

/** Mojo to start the apache FTP server as an integration instance
*	@goal run
*	@phase pre-integration-test
*///////////////////////////////////////////////////////////////////////////////

Stopping the server mojo

Once our run mojo starts the server, integration tests can be run on the ‘integration-test’ phase. Please bear in mind that client POMs can still be configured to run the server on whatever phases they need through XML tweaking.

The stop mojo ‘execute’ method is quite straightforward as well:

public void execute() throws MojoFailureException {

	getLog().debug("Stopping FTP server...");
	Properties properties = null;
	if (mavenProject!=null) {
		properties = mavenProject.getProperties();
	} else {
		throw new MojoFailureException("Can't access maven project to stop FTP server (null)");
	}

	if (properties!=null) {

		FtpServer ftpServer;
		try {
			ftpServer = (FtpServer) properties.get(FtpServerConstants.FTPSERVER_KEY);
		} catch (ClassCastException e) {
			throw new MojoFailureException("Context doesn't contain a valid ftp server instance",e);
		}
		if (ftpServer==null) {
			throw new MojoFailureException("Context doesn't contain any ftp server instance");
		}
		if (!ftpServer.isStopped()) {
			ftpServer.stop();
			getLog().info("FTP server stopped.");
		} else {
			getLog().info("FTP server was stopped already");
		}

	} else {
		throw new MojoFailureException("Maven project has null properties",new NullPointerException());
	}

}	// execute

After error and sanity checks we retrieve the ftp server instance and stop it. Easy.
Bear in mind that, exceptions during the integration-test phase should be instances of ‘MojoFailureException’ which do not cause the build to die (please check the appropriate documentation on the Maven reference book).

So, if for instance a single test fails, the other tests can run and the server is gracefully stopped at the end. Using ‘MojoExecutionException’ would cause the whole build to stop and if done before the stop mojo has a chance to run the server is not stopped. All probable exceptions on the Maven ftp server plugin are of the type ‘MojoFailureException’ as we do not want to stop the whole build if integration tests fail, we report them and it will be up to the client developer to decide what to do.

Testing the mojos the right way

Unit testing mojo code is made easier thanks to the ‘AbstractMojoTestCase’

public class FtpServerMojoTest extends AbstractMojoTestCase {

This superclass contains some methods to help in testing mojos, mainly methods to read POM files and run mojos.

We also need an FTP client to connect to the running instance. The excellent Apache Commons Net library is ideal for that purpose.

To use it we add the relevant test dependencies to our project POM with a ‘test’ scope which means they will only be used on the ‘test’ phase and not when the plugin is ran:

	
		org.apache.maven.plugin-testing
		maven-plugin-testing-harness
		1.2
		test
	
	
	    commons-net
	    commons-net
   		 3.0.1
    	test
    

So what we want to do is run the FTP server startup method on each test setup and stop it on each test teardown.

/** Read pom and start FTP server
*	@throws java.lang.Exception
*///////////////////////////////////////////////////////////////////////////////
public void setUp() throws Exception {

	super.setUp() ;

	pom = getTestFile("src/test/resources/unit/test-project/pom.xml");
	assertNotNull("Test pom not found",pom);
	assertTrue("Test pom not found",pom.exists());

	port = getFreePort();

	FtpServerRunMojo runMojo = (FtpServerRunMojo) lookupMojo("run", pom);

	// all this will be set on a real project (it's not on the test environment)
	runMojo.serverRoot = new File(PlexusTestCase.getBasedir()+"/target");
	runMojo.port = port;
	runMojo.mavenProject = new MavenProject();
	runMojo.mavenProject.getModel().setProperties(new Properties());
	runMojo.execute();
	ftpServer = (FtpServer) runMojo.mavenProject.getProperties().get(FtpServerConstants.FTPSERVER_KEY);

    ftp = new FTPClient();
    ftp.connect("localhost",port);    

}	// setUp

First we call the superclass as it configures stuff we need to call the convenience methods, load up a test pom and find a free port to run the server. Next we lookup the ‘run’ mojo and add the relevant data that it needs to start such as the server root, port, container Maven project, etc. All that data is automatically set on a non-test environment but it is not on a test setup. Last on the setup is to connect to the FTP server.

Teardown needs to cleanup the ftp connection and run the stop mojo:

/** Run stop server mojo
* 	@throws java.lang.Exception
*///////////////////////////////////////////////////////////////////////////////
public void tearDown() throws Exception {

	if (ftp.isAvailable()) {
		if (ftp.isConnected()) {
			ftp.disconnect();
		}
	}

	FtpServerStopMojo stopMojo = (FtpServerStopMojo) lookupMojo("stop",pom);

	Properties properties = new Properties();
	properties.put(FtpServerConstants.FTPSERVER_KEY, ftpServer);
	stopMojo.mavenProject = new MavenProject();
	stopMojo.mavenProject.getModel().setProperties(properties);
	stopMojo.execute();

	super.tearDown();	// called last as it dismantles running mojo stuff

}	// tearDown

Note we create a Maven project instance to store the running FTP instance which will be stopped by the ‘stop’ mojo. We also call ‘super.tearDown()’ last to make sure any superclass resources are cleaned up when we are done cleaning up ourselves.

The test POM should contain appropriate test data so significant tests can be run, therefore we add different configuration settings to the XML

	cat.calidos.maven.ftpserver
	ftpserver-maven-plugin
	1.0
		
			
				admin
admin00
			
			
				
					demo
demo
				
				
					disabled
disabled
					false
				
				
					classes-root
classes-root
					./classes
				
				
					write-disabled
write-disabled
					false
				

			
		
	

This setup lets us test the administrator user, a regular user, a disabled one, home folders and write-disabled users. There are far more features exposed by the Apache FTP Server though it is not the aim of this test to test them all, just to make a general set of features work as expected. Obviously, to get higher code coverage more tests can be added as needed.

After the POM is ready, we add some unit tests such as the regular user test:

/** Demo user should be able to login
*	@throws SocketException
*	@throws IOException
*//////////////////////////////////////////////////////////////////////////////
public void testDemoUser() throws SocketException, IOException {

    ftp.login("demo", "demo");
	int reply = ftp.getReplyCode();
    assertTrue(FTPReply.isPositiveCompletion(reply));
    assertTrue("Can't login with demo user",ftp.isConnected());

	String filename = "test-file";
	putFile(filename);
	boolean found = findRemoteItem(filename);
	assertTrue(filename+" can't be uploaded",found);

    ftp.disconnect();

}	// testDemoUser

We connect, add a test file and ensure it has been uploaded successfully. Both ‘putFile’ and ‘findRemoteItem’ are convenience methods created on the test class.

Adding more test cases is pretty straightforward, like in the test for readonly users:

/**	User shouldn't have write permissions
*	@throws IOException
*//////////////////////////////////////////////////////////////////////////////
public void testCannotWrite() throws IOException {

	ftp.login("write-disabled", "write-disabled");
	int reply = ftp.getReplyCode();
	assertTrue(FTPReply.isPositiveCompletion(reply));
	assertTrue(ftp.isConnected());

	String filename = "test-file2";
	putFile(filename);
	boolean found = findRemoteItem(filename);
	assertFalse(filename+" can be put on nonwrite permissions user",found);

	ftp.disconnect();

}	// testCannotWrite

Using the plugin

Doing integration testing with our completed FTP Server Maven plugin is pretty straightforward using the ‘maven-failsafe-plugin’ to fire up the tests and the ‘ftpserver-maven-plugin’ itself to run the FTP server

	cat.calidos.maven.ftpserver
	ftpserver-maven-plugin
	1.0

		
			
				admin
admin00
			
		
			file:target/test-classes/log4j.properties
		
	

	
	
		
			start-ftpserver
			
				run
			
		
		
			stop-ftpserver
			
				stop
			
		
	

Not that, unlike in unit testing and the ‘maven-surefire-plugin’ the standard test location for the log4j configuration file does not work so we need to specify it on the POM. We also need to specify the goals for the FTP server to startup and shutdown, much along the lines of the Maven Failsafe plugin itself.

If any of the integration tests fails the stop goal is still ran and the server shuts down gracefully.

Additionally, if running the FTP server is needed on phases other than the integration testing ones the goals be attached to the relevant phases through our client POM.

Wrapping up: creation of an FTP server plugin

We have identified a need of using a fully functional FTP and SFTP server in integration testing using Maven. Looking up available plugins on the Web does not yield any already available plugins. We have gone ahead and built a plugin from scratch using the Apache FTP Server opensource library.

You can download the source code of version 1.0 of the maven-ftpserver-plugin as well as a sample client project. Enjoy and comments are welcome.

(*) Between completing the code and writing the article Apache FtpServer came out with a new release (1.0.6). Thanks to Maven and the fair amount testing it was ridiculously easy to upgrade the project, just changed the dependency numbers on the pom file and ran a maven build.

Per això m’encanta el programa de 100 push-ups en 7 setmanes de Steve Speirs.
La idea bàsica del programa és arribar a fer un centenar de push-ups a l’estil militar si es segueix el programa al peu de la lletra. D’entrada sembla un repte ‘impossible’ pels mortals més comuns (un servidor inclòs).

La premissa bàsica és que un push-up és un exercici en la línia de ‘full body movement‘, on es mou tot el cos i s’involucren el màxim de grups musculars i articulacions. Es creu que els exercicis d’aquest tipus són molt beneficiosos i presenten un rendiment superior que el de les típiques màquines de musculació o els exercicis ‘localitzats’ en una sola part del cos. Córrer n’és un dels exemples més clàssics.

Un push-up involucra els pectorals, els tríceps (els grans oblidats), deltoides, serratus anterior (músculs de l’esquena situats sota la part superior dels braços), els músculs abdominals, glutis i bíceps. En el cas d’aquests últims amb els push-ups tradicionals no es treballen gaire i cal fer alguna variant si es vol potenciar-los. La diferència en el nivell de treball dels bíceps i tríceps és significativa pel fet que els tríceps comformen el 60% de la massa muscular de la zona superior dels braços. Cal pensar que s’acostuma a abusar del treball amb els bíceps per raons estètiques, cosa que pot causar desequilibris de tota mena.

Per seguir el programa, primerament es fa un test de quantes flexions es poden fer seguides, sense parar. Depenent de la quantitat final -jo en vaig fer 20-, es comença amb un programa concret o un altre. En el meu cas em toca el ‘Intermediate 2′. Malgrat que amb un push-up més ja passaria al ‘Advanced 1′, millor no precipitar-se! Fins i tot hi ha un programa pels qui no són capaços de fer cap push-up o només uns quatre o cinc.

Un cop fet el test i seleccionat el programa només cal anar seguint els passos cada dia. L’estructura principal gira al voltant de la setmana o almenys de cicles iteratius incrementals de set dies. Quatre dies de descans alternats amb tres dies d’exercici.

L’exercici es basa en l’escalfament, uns quants sets de push-ups amb un descans d’un minut entre cadascun i els estiraments finals. En un quart d’hora o vint minuts es pot completar tranquil·lament, escalfament i estiraments inclosos.

Avui em toca descans i demà toca ‘warm up, 11, 14, 11, 11, 16+, stretch (Intermediate 2, week 3)’, que són com a mínim 63 push-ups, no està del tot malament.

Per fer el seguiment es pot fer servir qualsevol tècnica, un paper, el llibre de Steve Speirs, GTD, una agenda… Jo faig servir el Remember The Milk que és un servei de GTD boníssim.

Al durant la setmana final de cada programa es poden fer sèries impresionants de més de 22 o 24 push-ups i en el cas del Intermediate 2 hi ha una traca final de més de 60!

Un cop completat el programa la idea és descansar dos o tres dies i intentar fer 100 push-ups seguits. Sembla impossible, no?

Per més detalls sobre el programa hi ha diverses opcions, primerament hi ha el site One Hundred Push ups, on podem trobar el programa, diversos recursos, programes alternatius, merxandatge i molts testimonials, inclòs el d’algun linuxero, hehe.

També hi ha el llibre (el programa exacte que segueixo), escrit per l’ideòleg del programa. Els més moderns poden provar l’aplicació per iPhone.

A veure si us animeu!

For the sake of drama and structure I will go from the most obvious to the slightly less evident and finish with the most subtle of the three.

Firstly, there is Microsoft.

It is common knowledge that the old boys from Redmond are in deep trouble in the mobile arena (and still are). After being a major player in the mobile smartphone arena for quite a long time it has gradually become a so-so player, being met by some skepticism by users and critics alike.

Even though Windows Phone 7 received decent reviews it feels like too little and definitely too late.

The Windows Phone 7 rollout still feels too corporate to me and still part of a lukewarm strategy.

Yeah but Microsoft has conquered or at least made a good dent on other markets before, even if just by brute force, yes? (read XBOX).

So why would a juggernaut like Microsoft be constrained in its long-term strategy? Shouldn’t be.

Well, it’s the systems, stupid.
If anything, Apple has taught the industry one thing with the iPod, iPhone and lately with the iPad. Consumers love SYSTEMS.

Consumers don’t like loosely coupled devices. Consumers don’t like replacing or upgrading components. Consumers don’t like lengthy boot sequences. Consumers don’t like invasive firmware installations. Consumers don’t like the software provider plus OEM combination. Maybe they did in the beginning of the 90′s. We ain’t in the 90′s anymore. XBOX, though successful, has been targeted at hardcore gamers rather than casual ones up until the Kinect.

On top of that Microsoft has learned something on its own, it doesn’t know how to build consumer SYSTEMS at all.

Therefore, to get itself out of the hole, Microsoft considered its options.

Acquisition of a successful company just to go on and destroy it in the process was ruled out, lest it turn into another disaster.

Lesson learned and any acquisitions ruled out, Microsoft then took a look at the OEM market… Err, in the case of MS, it meant HTC, builder of the 80% of cell phones bearing Microsoft’s mobile OS (at least prior the 7th version). Out of 50 partners!

Well, a simple Google search for Android and HTC is quite revealing. HTC didn’t jump ship, not exactly. But it started to be really busy building handsets with that OS.

Well, considering Android had been in the market for a while, a mature product, consumers liking it, with a plethora of apps and -most importantly- being FREE, what do you expect? Considering that MS has been known to thoroughly screw its partners from time to time., who can blame HTC?

Surely, HTC has hedged its bets and is only too happy to license to MS and adopt a wait-and-see attitude to it to see if it sticks and to exploit slow IT corporate policies that still mandate Windows-Everywhere(™). The good old leverage from the fading age of Windows was gone though and Microsoft would feel like second best here.

Choice taken away: traditional OEMs were out.

To add icing on the cake, it would seem that Microsoft had little choice but to license the ARM architecture, surely watched closely by its mobile hardware OEMs who have perceived it as yet another sword hanging over their little necks. A sword that would materialise as Microsoft mobile hardware. Uh-oh. Again, Microsoft has had to take some eggs from the software-only basket and put them on the systems one though only as a last resort (see Kin fiasco).

No pure-OEM model then. No acquisitions. Definitely not Android. SONY? You gotta be kidding. No Microsoft hardware (yet). Samsung maybe? Nay.

Um…

It had to be Nokia then. It’s smartphone marketshare in decline, Microsoft couldn’t go anywhere else.

Which leads nicely to the next big boy, Nokia itself.

Nokia is a giant. Massive with customers, it has created remarkable legendary mobile designs. However, its fortunes -or at least its marketshare lead- got reversed and were showing a worrying trend.

The new CEO put it very well himself, the company is in dire straits indeed, at least in the long term.

Nokia also considered its options.

Nokia understands systems and consumers very well, probably much more than Microsoft does or has ever done. With that in mind, Elop and senior managers understood that Symbian is a thing of the past that. Meego wasn’t ready and perhaps would never be good enough.

But, wait? A company the size of Nokia has lots of engineering talent! Yes, but also lots of middle managers and lacklustre leadership, if one is to believe Nokia’s top brass.

Therefore, culling the company of useless meddlers and taking the time to isolate a dedicated, motivated and driven team to push Meego (much like what Palm managed to do with its WebOS) up to scratch would take time, too long. If I remember correctly, it took Palm the better part of two years or more to get WebOS near 1.0-status and that is an heroic feat. Time though, is not something Nokia had available. Option out.

Acquisition? Nokia doesn’t strike me as an acquisition-crazy company.

Firstly, a nimble startup would understandably have a hard time integrating into a company of 12.000+ employees.

Secondly, while the Trolltech acquisition had some technical merit, it was completed in 2008 and Nokia has’t really made Qt onto the big promised paradise it was intented to. And they have had plenty of time to do it.

And finally, who to buy? RIM? Are you kidding? Making the company bigger and having a huge corporate cultural clash to boot?!? And getting RIM’s loony CEO(s) onboard?

Nay, purchasing its way out of trouble, choice taken away.

Which lead Nokia to consider Android.

One can imagine Nokia seeing Android as the forbidden fruit of sin. Juicy, tempting, free for the taking… and ultimately damning.

Oh, there is the legal swamp. Before taking a bite out of the fruit, Nokia must have had it’s lawyer legions take a good look at it.

If that was not to scare the Nokia strategist what would?

Well, I would argue that the real reason is freedom. Freedom to differentiate. As the Symbian guys put it “[…] surrender too much of the value and differentiation ability, most obviously in services and advertising, to Google.” Exactly. Nokia would play on the same field as all the other OEM. Bummer, from leading systems developer down to mere squabbling OEM.

Surely Nokia had been following what happened to Motorola and the Skyhook guys.

Apparently, both Motorola and ‘Company X’ (believed to be Samsung) have been prevented by Google from shipping handsets bearing its location technology. Remeber Navteq? Ever heard of Nokia maps?

Jump onto the Android bandwagon and kiss goodbye to all that.

So Android being out what was left as an option? A company in desperate need?

Microsoft.

Which leads to the idea of Google having courted Nokia precisely for many of the reasons Microsoft ‘bought’ them in the first place.

Finally, Google is the third big one having run out of options on some of its most strategic options.

Consider the official gospel on why Google created Android and released it to the wild. Well, most of it, anyway.

According to Vic Gundotra from Google:

“If Google didn’t act, it faced a draconian future where one man, one phone, one carrier were our choice. That’s a future we don’t want.”

Sounds chivalrous and following the ‘Don’t be evil’ mantra. Google released Android to save us all from that bleak future.

Well, it’s not true.

Consider Google’s business model. It revolves around advertising and to do well in advertising you need eyeballs, lots of them. Furthermore, to do very well you need targeted eyeballs, that is, to show the right adverts to the right people, to maximise chances of these people hitting the ads.

Google’s business model elevator pitch: person would like to get a service or product on the Web. Cool, she fires up Google on her desktop or laptop and does a search for the terms she thinks will help her find that product or service. Maybe clicks on the ads, maybe finds what she is looking for, maybe not. Bonus points: does more searches through Google, refining the terms (translation: getting more targeted ads), finally finds what she is looking for. This happens millions of times. Google makes tons of money.

Whereas if that same person would like to get a service or product on her iPhone, the story is completely different. Cool, she fires up the App Store app, does a search or browses the categories. Looks at the top charts, reads the reviews and how many stars the candidate solutions have, ponders wether to pay or get a free app, etc. Person chooses app and installs it. Google gets zero money. Zaroo, zip, nada, nothing.

There are a few things that need to be considered:

• Not all services are available through the App Store and probably will never be a 100%, but there are zillions of apps (read, services) waiting to be downloaded.
• People trust Google to deliver good search results but how to compare one result from the other can basically only be done by the rank itself or by clicking on the link and spending sometime on the site. The App Store offers a simplified interface allegedly easier the average consumer (ranks, reviews, stars, etc.).
• People trust the App Store as well, it has never allowed malware on people’s devices.
• Apple is very careful and vocal about not having any influence on the ranking, like, erm, Google.
• To get iPhone apps, geeks will do research on Google and the Web. Will look for extended reviews, comparisons and specialised sites. Consumers just use the App Store.

Google knew that smartphones and later tablets would be the devices the mass market consumer will use to access the Internet. iOS was looking good and demolishing the competition at the time. It seems to be doing the same now.

The App Store is a ‘Google search’ replacement.

I would say that Apple wasn’t expecting it to become so successful. I would add that Apple didn’t set out to build a Google search replacement when the App Store was built. Apple engineers and product managers only wanted to create a better experience for consumers than googling vague terms, shuffling through specialised review sites, getting malware off dubious websites, etc. Google is collateral damage.

Google knew it had to act, very fast and with very decisive steps. Apple’s competition was in shambles and couldn’t get their stuff together for the life of them. Microsoft Windows Mobile 6.x was crap and any real future releases years into the future, RIM was -is- a shadow of its former self and Palm was on its last legs. Google couldn’t wait on them.

Android was born and released for free. Had to be. Google didn’t have any other choice. What they really imagined was a mobile future sans Android, where Apple would rule. Imagine if Android didn’t exist what the marketshare of Apple would be on smartphones today and Google wouldn’t be able to continue making money on it. That is the future Google didn’t want.

A corporate strategy is about having a vision and making it happen and the three giants have lost the initiative.

Localització genial totalment recomanable més enllà de les visites més típiques com pot ser Vienna, la zona del Danubi, Salzburg, etc.

La manera més fàcil d’arribar és via St. Gilgen i és recomanable agafar el ferri que et porta pel llac Wolfgangsee i va parant pels diversos poblets. Mentres degustes una cerveseta dins del ferri vas escoltant com t’expliquen curiositats de la zona primer en alemany i després en un anglès molt correcte. Bé, almenys fins que s’en cansen i es passen a l’alemany directament… així et pots imaginar què diuen i l’experiència es torna encara més estimulant. El ferri és molt còmode i diposa de taules on recuperar forçes i disfrutar del viatge.

De fet, això es repeteix força en les localitzacions Austríaques menys cèntriques -que no menys turístiques- on et trobes amb una gran quantitat de menús exclusivament en la llengua germànica i res de res en anglès. Una mica d’”aventura” no fa mal.

Pel que sembla, St. Wolfgang és famós per l’hotel del ‘Cavall Blanc’, regentat per la mateixa família desde el 1712 i escenari de la òpera ‘White Horse Inn’, de Ralph Benatzky. Segons diuen és una peça “mundialment famosa”… veurem quan arriba al Liceu.

En sí el poble és força petit tot i que té unes quantes perles amagades. Per exemple, hi ha una col·lecció de nines força gran muntada per un senyor força friki, on destaca la immensa quantitat i varietat de Barbies. Les Barbie islàmiques, orientals i indies destaquen especialment.

Tampoc us perdeu el típic pub de poble amb la típica disco al costat. Al pub es poden beure còctels d’allò més bons (recomanat el “Swimming Pool”) i observar com els locals consumeixen unes quantitats gens despreciables d’alcohol.

Pel que fa a l’allotjament, imprescindible el petit hotel ‘Hupfmuehle‘, al costat d’un rierol amb cascada inclosa que va a desembocar al llac. Hi ha una pujadeta important però quan s’arriba a dalt segurament us trobareu al patriarca de la família que el regenta que us estarà esperant… D’aquest pal, vaja. Moltes de les habitacions donen directament a la cascada i el so és tant relaxant que et quedes adormit en un plis plas. Mentres esperes l’hora de sopar et pots estar a la terrassa fent un vermutet.

El menú és força curiós pel fet que és molt curt: sopa o amanida de primer i de segon només hi ha peix, truita de riu o una varietat local. Quan has triat el pesquen i el preparen al moment. Com era d’esperar és deliciós.

L’endemà cal recuperar-se de la ressaca generada al pub del poble i deixar-se caure pel restaurant Joseph’s. No és precisament barat però tampoc és desproporcionat pel servei i la qualitat. El menú és exclusivament en alemany i està escrit en una pissara mòbil que et porta el cambrer cosa que dóna molta vidilla. Hi ha menú degustació o pots triar els plats que vols. Les làmines de vedella amb verdures són de lo millor que he tastat mai. La selecció de vins, xampany, caves i licors és molt extensa i també val com a vinoteca o sigui que si un vi t’ha agradat en pots comprar una ampolla per potser acabar-la a l’hotel amb més intimitat?

Resumint, cal fugir dels llocs més habituals i explorar aquests raconets genials que ens regala Europa… No ens en penedirem!

A common feature of Web applications is the need to output structured content, be it XML, XHTML markup, JSON or many others. A number of technologies is used to do that but few seem to be that dynamic, usually only reloading templates when they change or loading them from URLs. Surely we can leverage OSGi to make things more interesting…

Therefore we should be following the OSGi dynamic philosophy as much as possible, exploiting the features made available by the framework such as dynamic discovery, services, bundle headers and the lot.

In the case of our cache app we are violating quite a few basic design principles by having the format embedded in the java code. So we should as well use a template separate from the code and if possible reuse some existing well-known templating engine from somewhere.

Given these basic design principles let’s get started.

Firstly, we need a robust and flexible templating engine. We select the mature Freemarker engine which is reasonably speedy and has the power and flexibility we want. Make sure you check out the license, of course.

We could stop at putting the library JAR in a bundle and package it so it can be used by any other bundle and that is what we do to be able to use it in OSGi. That however doesn’t exploit many of the nicer OSGi capabilities so we will create another bundle called ‘com.calidos.dani.osgi.freemarker-loader’.

What we want is to allow bundles to carry templates inside them and have our freemarker-loader templating bundle discover them automagically. This is the same technique that the Spring dynamic modules use and you can find more info here. The mechanism is described in this diagram:

That is easy enough with a BundleTracker and a BundleTrackerCustomizer implementation. The BundleTracker class tracks bundles being added to the environment like this:

tracker = new BundleTracker(context, Bundle.RESOLVED, templateTracker);
tracker.open();

With this snippet the tracker instance will look for bundles in the RESOLVED state (which lets us track fragments). The ‘templateTracker’ object is an instance of BundleTrackerCustomizer and will receive callbacks whenever bundles are added to the environment.

For instance, when a bundle is added we check for a special header in the bundle which tells us what is the relative path of available templates in the bundle being resolved:

public Object addingBundle(Bundle bundle, BundleEvent event) {

// we look for the header and act accordingly
String templatesLocation = (String) bundle.getHeaders().get(TEMPLATE_HEADER);
if (templatesLocation!=null) {

	Enumeration bundleTemplates = bundle.findEntries(templatesLocation, "*.ftl", true);
	HashSet templatesFromAddedBundle = new HashSet();
	while (bundleTemplates.hasMoreElements()) {

		URL templateURL = bundleTemplates.nextElement();
		addTemplate(bundle, templateURL,templatesLocation);
		templatesFromAddedBundle.add(templateURL);

	}

	templatesOfEachBundle.put(bundle.getBundleId(), templatesFromAddedBundle);

}
return null;

}	// addingBundle

An interesting method being used here is ‘findEntries’ which loads all the entries in the provided templates folder and lets us add them to our holding structure. We also take care to implement the methods to remove the templates and update them accordingly whenever bundles are updated or unloaded from the environment.

Having TEMPLATE_HEADER with a value of ‘Freemarker-Templates’ means that bundles having a header such as Freemarker-Templates: /templates will have any templates within that folder (please note that the ‘/templates’ bit is not added to template URLs!).

The next thing we need to do is make the loaded templates available to the environment. To do that we make a freemarker Configuration object accessible as an OSGi service object. That Configuration instance is the main object Freemarker to load and use templates and has an interesting mechanism to override its template loading mechanism we use to make available our OSGi environment templates.

freemarkerConfig.setTemplateLoader( new URLTemplateLoader() {

@Override
protected URL getURL(String url) {
Stack templateStack = templates.get(url);
if (templateStack!=null) {
	TemplateEntry templateStackTop = templateStack.peek();
	if (templateStackTop!=null) {
		return templateStackTop.getTemplateURL();
	}
	return null;
}
return null;
}

});

The service Configuration object is set with a template loader inner class that uses our template holding objects to retrieve templates stored in our OSGi context. Cool.

This also allows us to effectively disable the template refreshing cycles that Freemarker does by default (allegedly making it slightly more efficient). Now we only need to refresh a bundle containing the templates to get the new version. This can be modified by using the appropriate methods on the Configuration service of course. (There is another method explained later).

An interesting feature we can add to exploit the dynamic nature of OSGi is to make templates available in a stack. This means different bundles can dynamically overwrite templates by the same name. Moreover, once a template is removed the previous version becomes available. This can be used to make temporary changes to templates to add or remove diagnostics information, test new templates temporarily, etc.

We do that using a Stack of TemplateEntry objects, TemplateEntry being a helper class to store template entries.

This is all very nice but we have a problem when having multiple versions of the same bundle that hold multiple copies of the same template, this means they will stack and we have no way to access a particular version of a template. To solve this problem we store each template in three different stacks by three different URLs:

• ‘path/file.ftl’
• ‘bundle://bundlename/path/file.ftl’
• ‘bundle://bundlename:version/path/file.ftl’

In this manner we can use the more generic URL in most cases but still can access specific versions when needed. It is important to think about the dynamic nature of OSGi as well as the possibility of several versions of the same bundle coexisting peacefully in the same environment.

From the perspective of any bundle using the service in the simplest case it only needs to look for a service named ‘freemarker.template.Configuration’. For convenience, the property ‘dynamicConfiguration’ is set to ‘true’ to coexist peacefully with other Configuration services (maybe coming from an official Freemarker bundle). For instance, if we know for sure our dynamic Configuration service is the only one present we can do:

context.getServiceReference(Configuration.class.getName());

That will give us the highest ranking Configuration service. If there are several such services we can use a call like this to get the one that has the dynamic OSGi loader:

context.getServiceReferences(Configuration.class.getName(), "dynamicConfiguration=true");

There is one last feature which lets bundle users feed an already configured template configuration object to the bundle by publishing a Configuration service with property ‘preparedConfiguration’ set to ‘true’. This will get picked up by the bundle and its template loader put in sequence with the dynamic OSGi template loader. This means that any original Configuration settings are maintained (For further information on service filtering based on properties please check the BundleContext javadoc.).

Best thing to do is to go and try it by downloading the bundles here. Source is also available.

Demos impresionants en la roda de premsa de presentació del ‘Little Big Planet 2′ durant l’E3.

Els resultats són ben bé espectaculars, com podeu veure.

PS: la web oficial de Media Molecule és un exemple molt bo d’una web corporativa genial que no es pren seriosament a sí mateixa.

In the case of integration testing, it is manly used in a pre-production environment, with a valid build that has all unit tests passed. It can even be used in production to just after a deployment is made, taking care not to have destructive checks or massive load tests in the integration test code. YMMV.

To achieve integration testing we need to check the various OSGi components deployed interact in the way that is expected of them. Therefore we need to test the components in a group and not in isolation. To do that in the OSGi world means we need to have access to the OSGi context from within the tests to access services, call them and check their responses, etc.

To allow for this kind of integration testing within the OSGi environment, we make a slight modification to the excellent test.extender we have already patched in the previous installment.

Basically, the basic test.extender seeks out any JUnit test classes within the fragment bundle, creates an instance using an empty constructor and then fires up the tests. This is activated either by default when the fragment is loaded or by using ‘test ‘ in the console. For further information please see the previous post about this subject.

For our integration testing, we add an extra command to test.extender:

public Object _integrationTest(CommandInterpreter intp) {
        String nextArgument = intp.nextArgument();
    	testExtender.integrationTest(Long.parseLong(nextArgument));
    	return null;
}

And we refactor the TestExtender to add the integrationTest method which reuses some of the code to instantiate test cases using a constructor that accepts the OSGi context as a parameter.

Constructor[] constructors = clazz.getConstructors();
boolean foundConstructor = false;
for (int i = 0; i < constructors.length && !foundConstructor; i++) {
	Constructor constructor = constructors[i];
	Class[] types = constructor.getParameterTypes();
	if (types.length==1 && types[0].isInstance(context)) {
		foundConstructor = true;
		EClassUtils.testClass(inspectClass, constructor.newInstance(context));
	}
} // for

The OSGi context is passed onto the constructor and then the test class is run. It is obviously up to the test class to use the context appropriately for its integration testing.

In our cache project setup, we can do some useful integration testing on the cache.controller component, basically checking if the interaction with the provider components is behaving as we expect it. The integration testing is also added to a fragment that can be deployed optionally, of course.

We start by creating the fragment and adding a testing class like this:

Next, we add the constructor that accepts an OSGi context, which is very simple:

public CacheIntegrationTest(BundleContext ctx) {
	super();
	this.context = ctx;
}

In the setup and teardown methods we get and unget the cache service to perform the testing:

public void setUp() throws Exception {
	serviceReference = context.getServiceReference(Cache.class.getName());
	controller = (CacheControllerCore) context.getService(serviceReference);

}

public void tearDown() throws Exception {
	context.ungetService(serviceReference);
	controller = null;
}

In this case we get the controller cache service and store it in an instance used to perform the tests. This is quite simple and fulfills our intended purpose but we still have the flexibility to make more complex integration testing if needed.

Next we create as many test cases as needed:

public void testGet() {
	try {
		controller.init();
		double v = Math.random();
		String k = "/k"+v;
		controller.set(k, v);
		assertEquals(v, controller.get(k));
	} catch (CacheProviderException e) {
		e.printStackTrace();
		fail(e.getMessage());
	}

}

It should be noted that while the code looks like regular testing code, it is actually using real services from the OSGi environment as opposed to mockups. This means we are testing the real integration between components as well as the individual controller component code. The disadvantage here is that if there is an error in the controller we might mistake the problem with an issue with the services used. In conclusion, having integration code doesn’t negate the need to have unit tests.

Once we load the fragment onto the environment, first we need to obtain the bundle id of the integration fragment and then launch the integration testing in this manner:


osgi> integrate 125
Bundle : [125] : com.calidos.dani.osgi.cache.controller.integration
_
CLASS : [com.calidos.dani.osgi.cache.controller.CacheIntegrationTest]
___________________________________________________________________________
Method : [ testInit ] PASS
Method : [ testInitInt ] PASS
Method : [ testSize ] PASS
14:21:43,077 WARN CacheControllerCore Couldn't clear some of the provider caches as operation is unsupported
14:21:43,077 WARN CacheControllerCore Couldn't clear some of the provider caches as operation is unsupported
Method : [ testClear ] PASS
Method : [ testSet ] PASS
Method : [ testGet ] PASS
Method : [ testGetStatus ] PASS
___________________________________________________________________________


The results tell us that all operations are OK but we need to bear in mind that the clear operation is not supported in some backend caches. If this is what is expected by the operator then all is fine.

We take advantage of the new integration testing functionality to make some extensive changes to logging and exception handling of the controller code. By running the integration tests we make sure all seems to work fine (even though we still need some proper unit testing of the controller). Modifications are made quite quickly thanks to the integration tests.

To recap, we’ve added integration testing support to the existing ‘test.extender’ bundle and created integration testing code for the cache controller component. This has allowed us to make code changes quickly with less risk of mistakes.

Here you can find a patch for the test extender project as well as the patched testing bundle already compiled. Enjoy!

La idea és anar amb molt de compte en enllaçar els posts i updates de microblogging entre els diferents serveis, no sempre és lo òptim. Com diu el mateix Roger:

Un clam al cel perquè la gent deixi de reaprofitar el mateix missatge per a totes les xarxes socials. Crea soroll innecesari, molts cops perd context (hashtags a facebook, etc…) i molesta. Ok a que em diguis “avui he dinat molt bé”, però no necessito rebre-ho per triplicat.

Both J.G. and L.G. have brought up many valid points: Adobe dragged their heels on Flash for mobile for a looooong time. There have been countless detabes and blog posts.

I’ll bring two further arguments, one logical and one historical, the latter being one that I believe hasn’t been brought up yet.

Logical argument: the fallacy of Flash being cross-platform

Moreover, why should we choose to lock ourselves onto Adobe’s propietary API instead of Apple’s propietary API? Why is Adobe’s API, specs and runtime superior to any others? Many would say the main reason (the only?) is that it’s crossplatform?

Wikipedia says that cross-platform means:

“an attribute conferred to computer software or computing methods and concepts that are implemented and inter-operate on multiple computer platforms”.

Oh, okay, so multiple means Windows, Mac and Linux desktops. Hello?!? Anyone there?!? This is 2010 and the 90′s called because they want their meaning of “platform” back. Nowadays, multiple means desktop and mobile. Therefore:

• Flash Lite is a joke. Where are the multiplicity of mobile devices supporting proper Flash 10.1 today?
• Where is the pervasive Android support today? HTC Hero buyers are screwed, a phone bought as little as less than a year ago won’t be supported.
• Where is the support for Windows Mobile devices? Not there until WinMo7. You mean it will be supported on a OS that it’s not even there yet?

Well, you could say that the Open Screen Project and the releasing of the FLV, SWF and the lot specs are true multiplatformness… Well, so far so good but where is the real market traction? Where are the tried-and-true implementations? Adobe has released this technology but until it gains traction it’s no more than a glorified press release. Apple can play this game too, with tech such as WebKit which is used in a zillion places including Adobe’s own Air platform. Press releases and freeing technologies are irrelevant until adopted. A good initiative which I applaud, but still not widely used.

No, Flash is not cross-platform anymore. What is the marketshare of the mobile devices capable of running Flash 10.1? Nowhere big enough for Adobe to be pulling muscle and demanding anything. It seems Adobe is using Flash devs and aficionados as cannon fodder or -as Gerbarg more aptly puts it-, “Adobe used its userbase and their livelihood as a bargaining chip”. Adobe dragged its feet for years in the mobile arena and now is paying for its mistakes.

Historical argument: Macromedia Adobe has screwed its own developers like this before

In the nineties Macromedia had a great product already. It was cross-platform (as per 90′s definition), had powerful scripting capabilities, an powerful extension architecture, a great browser plug-in runtime that was also cross-platform, video capabilities, awesome rapid development tools, stellar graphics integration, built-in debugger, great performance, etc. It was called Director and it was really cool.

Then Macromedia bought FutureSplash in 1996 which would be later renamed to Flash. It had far less capabilities that Director at the time (no real scripting at the beginning, etc.) and would remain technically inferior for sometime, having no debugging and many other features being missing for a long while. However, it had three distinct advantages. Strike one: having less features and being a newer codebase meant it could have a more lightweight runtime than the Director one. Strike two: it had support for vector graphics, which desktop CPUs at the time were just capable of displaying and animating adequately. Director came from a less CPU-intensive bitmap background, faster but consuming more space than vector definitions and looking less sleek in many cases.

One “advantage” remained. So what did Macromedia do? Take advantage of the FutureSplash technology acquisition and the Director established developer base? It could have easily added the vector drawing technology into Director (it supported many types of media already). Refactoring the code and runtime would be no trivial feat but doable. Any Director developer would have been OK with a new restriction being put into place that meant only vector-graphics resources being allowed any new Director web runtime, would have welcomed and embraced such a change.

Strike three: Macromedia realised that with the maturity and feature-complete of Director no long-winded upgrade path was in sight. Just adding vector graphics and a streamlined runtime would do for one or two Director upgrades, no more. They thoroughly screwed the existing loyal developer base royally and released a sleek new 1.0 Flash product. Then they spent years releasing upgrades that added features that had already been present in Director for some time. They created another cash cow, a cow that would ride the wave of the Web explosion of the .com era. Director out. And no, I’m not buying any of the “official” reasons for its languishing and Flash emergence. It was all about money.

I am not crying for Director’s demise -or rather, being put into life-support mode. It was a good platform and many (myself included) made good money using it. This doesn’t mean Adobe didn’t screw up many of its own developers and went in for the next cash cow.

I am not buying Flash developers and supporters taking offense and the moral high ground, the company (now Adobe) you support has done a much worse thing to its own developers. Why should Apple even care for developers of other platforms? Just because you learned a framework and are scared of it fading away doesn’t mean anything… Some of us have done this many times before and moved on…

Final word: put your code where your mouth is

Okay. Time to recap, folks. If Flash is such a great platform -it’s actually not bad but not that good either- go ahead and develop these killer apps on Android or WinMo7 whenever that comes out. With killer apps being available on competing platforms making a huge difference Apple will simply change the clause and allow you in. They’re not stupid.

Now stop crying and start coding. Myself, will try to put this out of my mind.