E' il mercato, baby

Ai millantatori che scrivono che sviluppare su Android rende meno... faccio umilmente notare che siete a corto di cose interessanti da dire che non siano già state dette da almeno 2 anni e, per vostra sfortuna, già estese a tutte le piattaforme Store-based.
In soldoni: o le vostre apps sono basate sull'in-app purchase o rischiano fortemente di finire nel gruppone di quelli che non rientrano nemmeno dalle spese di sviluppo e marketing.
Questo vale per tutti.

Si chiama Mercato, e non ti chiede se sei figo o nerd. Lui ti schiaccia, ti mastica e ti risputa. E dopo ti schiaccia di nuovo. Non ti rimastica perchè è schizzinoso.

Ah... e non lo dico solo io:
http://arstechnica.com/apple/2012/05/ios-app-success-is-a-lottery-and-60-of-developers-dont-break-even/

Youtube Remote

La "nuova" GoogleTV che in questi giorni in molti hanno atteso potrebbe essere stata anticipata, e purtroppo ignorata, già da un pò.
Esiste infatti qualcosa che già oggi può trasformare qualsiasi apparecchiatura dotata di browser e uscita video in una Internet TV.
Si tratta di Youtube Remote, un applicativo che promette di portare una GoogleTV o, meglio, una "YoutubeTV" dentro le nostre case.
Oggi.
E senza che sia necessario acquistare nuovo hardware.

Basta collegare il proprio pc/portatile alla TV, aprire un browser e andare alla seguente pagina: http://www.youtube.com/leanback



Usando il vostro tablet Android potete procedere a fare il pairing tra quest'ultimo e la pagina "leanback".
Sul mio tablet il pairing ha richiesto 1 minuto (grazie a Google Goggles).

Dopo questo, utilizzare il tablet per comandare a distanza la mia "nuova" TV è stato semplice:




Il messaggio che passa è piacere digitale allo stato puro:

1. Ho in casa un prodotto nuovo e innovativo, che non sapevo di avere
2. I contenuti disponibili sono... ehm, parecchi. E Youtube non ha certo problemi a proporne di nuovi ogni giorno/ora/minuto
3. Il tablet o lo smartphone Android permettono un controllo remoto completo ed evoluto

Dal punto di vista dello sviluppatore sono poi rimasto favorevolmente colpito dall'intelligente mix di tecnologie pre-esistenti e standard,
cosa che implica che un qualsiasi hardware (anche di basso profilo) potrebbe offrire la medesima esperienza, preconfezionata in un set-top box a basso prezzo e di facile realizzazione.

Riassumendo questa analisi possiamo porci la domanda "Perchè è una buona idea Youtube Remote?" e (marzullamente) risponderci:

• Di sicuro perchè non ha bisogno di nuovo hardware: nella maggior parte delle nostre case sono già presenti un PC e uno smartphone/tablet
• Qualora così non fosse i produttori di hardware non dovranno realizzare dispositivi costosi e complicati, nè implementare nuovi standard, ma solo un set-top box contenente un browser di buona qualità e poco altro
• Non dover installare niente sul PC (nemmeno un'estensione del browser!)... non ha prezzo.

Fatemi sapere cosa ne pensate.

Illustrazione per far riflettere

Causa poco tempo a disposizione vi lascio l'idea, se ci fossero illustratori disposti ad usarla:
Una serie di strati geologici mostra al suo interno alcuni scheletri umani sedimentati accanto a uno o più strumenti teconlogici odierni (pensavo a un tablet e a un'automobile).
Dall'alto, fuori campo, in contrasto con l'aridità e il grigio delle rocce sedimentate e degli scheletri al loro interno, scendono uno o più rampicanti con fiori dai colori sgargianti, ma "diversi" dai fiori odierni (avevo pensato di realizzare un fiore con dei denti bianchi al centro).
I rampicanti fanno ombra agli strati, ma li lasciano scoperti abbastanza da lasciar intravvedere sia le ossa che i manufatti tecnologici.

La scritta, al di sotto, è breve e in un font essenziale (stile Arial):

Our planet will last long. Will we?

In grassetto la frase "Will we?".

L'immagine deve avere caratteristiche di fotorealismo spinto tali che mi hanno fatto desistere dal proposito di realizzarla con software tipo Illustrator/Inkscape.

L'ideale sarebbe partire da foto vere, da ritoccare con Photoshop/Gimp.

Se qualcuno fosse in possesso di queste foto potrei anche trovare il tempo di realizzare l'illustrazione.

Altrimenti beccatevi l'idea e, se vi piace, sfruttatela e fatemi sapere :-)

Simple as it is:

The earth will survive pollution, global warming and so on.
We won't.

AI. At least.

Last night I had time to focus my thoughts on a topic somewhat forgotten nowadays: Artificial Intelligence.

I found myself more and more concerned about not being literally surrounded by AIs that help and assist us on doing all sort of everyday tasks.
If you ask I would have expected for the AIs to be a constant and common presence at least in technology-related areas of the society such as IT, energy companies, transportation and military, healthcare, banks and trading, education and... well, almost everywere an AI with just a grain of intelligence could automate, manage and help men perform complex and/or repetitive tasks.
At least.

What we got instead? Zero-intelligence systems that would be dead after 5 minutes without a man supervising and managing them.
Even worse: systems that put man as the main information-processing unit.
I.e. applications that beautifully display bars, pies and reports that will be read, judged (and finally forgotten) by a human that will then formulate one or more possible actions to take as a consequence of those data.
Let alone the possibility to completely erase the human from that process, why not at least let the AI analyze the data and formulate possible scenarios to be judged by a human?

And what about an AI that asks me which author I'd like to read these month and then begins fetching data, ordering the books, paying them using my credit card, waiting for them to be shipped (eventually triggering an alert to me and/or the shipping AI in case the delivery is taking too much time) and putting together a brief introduction to that author so I could then enjoy a more complete experience from reading his/her books?

I don't feel like fearing (much) more intelligent systems as dangerous nor I think pleople would lose their jobs to an AI.
Nor man will get any lazy than he actually is...
Simply there would be more people doing different jobs that need no automation but a great amount of creativity instead.
By the way I think mankind may actually benefit of such a shift from automation to creation.

But aside from that there is a fact that bothers me: the technology for these kind of intelligent systems was ready a long time ago (let's see months and years from the technology perspective). I mean, we have multi-core processing since the early 1990s and AIs are one of the most ancient and studied topics of the Computer Science. We now have cloud-computing for exploiting even more computational power and we sure as hell don't lack minds that can design these Everyday AIs.

Thus I'm utterly disappointed that we still lack them.
They would make life easier and let people focus their lives on more meaningful activities (living their life above all...).
But I'm disappointed that I can't comprehend why they are not here yet.
I also thought of giving my contribute but it would seem that people and market are simply "not interested" in it.
Did I missed something? Am I drawing a wrong scenario when reality is much more promising instead?
Are we already there and I didn't notice?

I'll send a link to the new Megaupload to the first ones who answer my questions.

Integrating HTML5 and UPnP

I posted a really good link I found about integrating HTML5 and UPnP:
https://plus.google.com/u/0/112160333465217123290/posts/EKYW1wh8Wwd

Altough it seems still a bit rough this is a good idea.
If interested leave comments here or on my Google+ account.
I'm definitely studying it and I hope it will evolve and be implemented.

Vala compile error: cannot infer generic type argument for type parameter `GLib.Thread.create.T'

Today I tried to work with Vala and threads.
Turned out that documentation, even the official sources, is still sketchy and young.
E.g. I tried to build the following, taken from here:

void* thread_func()
{
    stdout.printf("Thread running.\n");
    return null;
}

int main(string[] args)
{
    if (!Thread.supported())
    {
        stderr.printf("Cannot run without threads.\n");
        return 1;
    }

    try
    {
        Thread.create(thread_func, false);
    }
    catch (ThreadError exc)
    {
        return 1;
    }  

    return 0;
}

It will give up compiling with the following error:

$ valac --thread main.vala
 main.vala:19.9-19.21: error:
 cannot infer generic type argument
  for type parameter `GLib.Thread.create.T'
        Thread.create(thread_func, false);
        ^^^^^^^^^^^^^
 Compilation failed: 1 error(s), 0 warning(s) 

The compiler does complain about an actual lack in my code. Infact the declaration of "Thread.create()" is:

Thread<T> create<T>(ThreadFunc<T> func, bool joinable)

The culprit is the generic type "T" to be passed to the create method.

But the type of what I need to provide?

Thread.create<?>(thread_func, false)

It's the return type of the thread function "thread_func" passed as the first parameter to the create method.
Hence I need to call it this way instead:

Thread.create<void*>(thread_func, false)

In the case thread_func had returned bool:

Thread.create<bool>(thread_func, false)

And so on.

Here's the incomplete documentation for the create method that led me to the initial impasse.
Here is where I found the solution (thanks to Abderrahim Kitouni) instead.
Yeah, a bit of Googling helped me as well.

MAC to IP address resolution

Today I couldn't find a way to resolve an host's IP starting from its MAC address, without using RARP (which isn't supported by some kernels ("This kernel does not support RARP"...)).
The solution I came up with is the following: given that two hosts already "know" (i.e. pinged) each other at least once you can perform the command
ping `arp -n | grep -i 00:17:C8:3B:81:94 | grep -o -E "\b[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\b"`

The only issue here is that the two hosts MUST have already "met" at least once.
This is because of the kernel ARP cache used by the "arp" command.

Useful?

Suppress "unused parameter" warnings

Here's a way to suppress the annoying "unused parameter" warning given by the following code:
void aFunction(int unusedParameter)
{
    // Do something but ignore the 'unusedParameter'
}
I use this define:
#define CHECKED_UNUSED(x) (void)x

And then I surround unused parameter with it, right after the opening bracket of the function (so I can easy find and modify the parameter if I start using it):
#define CHECKED_UNUSED(x) (void)x

void aFunction(int unusedParameter)
{
    CHECKED_UNUSED(unusedParameter);
}


I looked at the generated assembly before and after and it didn't change:
                  aFunction(int):
00000000004007d4:   push %rbp
00000000004007d5:   mov %rsp,%rbp
00000000004007d8:   mov %edi,-0x4(%rbp)
15                }
00000000004007db:   pop %rbp
00000000004007dc:   retq
18                {

Disclaimer: use it only after you carefully checked that you really not need to use that parameter.
Unused parameters (and all the warnings in general) could really lead to a bug (or simple misunderstandings) in your code.

Gnome3 e GnomeShell. I miei due centesimi.

Uso Gnome3 e la Shell da quando è uscito dalla fase di testing in Arch Linux. Effettivamente l'inizio è stato un pò ostico perchè molte cose sono cambiate, ma successivamente ho apprezzato il design tutto sommato lineare e pulito: sembra fatto bene e, soprattutto, pensato bene.

Ok, la status-bar è stata pensata male e realizzata peggio, ma tutto il resto se la cava piuttosto bene, tranne che per l'aspetto "configurazione".
Su quel versante Gnome3 mostra molto il fianco; in particolare è davvero troppo poco configurabile (sembra un prodotto Apple) e le extensions sono ancora troppo poco diffuse e, spesso, realizzate male.
Ma ciò che mi spaventa di più è che la configurazione del sistema sembra essere stata realizzata in modo così spartano e semplice di proposito. Se così fosse allora Gnome avrebbe perso un'occasione di quelle d'oro. Diciamo solo che hanno tempo di recuperare e spero sinceramente che lo facciano. Per loro.

Vogliamo parlare poi di stabilità? Stabilissimo e anche molto reattivo. Anche qua traspare l'impressione di buona realizzazione e buon design iniziale e, come bonus, i crash e i difetti sono lontani da un ambiente pulito e funzionante giusto un "ALT+F2 r".

In definitiva sono molto soddisfatto e propenso a credere che successivi rilasci portino ulteriori miglioramenti anche sotto questo aspetto.

Vorrei infine porre l'accento ancora una volta sulle extensions, stavolta con una nota molto positiva: sono realizzabili in Javascript... cosa mai avrei potuto desiderare di più (se non un'Aston Martin la mattina di Natale).