Note for future self :) (and yesterday's self)

On a GWT ListBox widget, it is natural to write 

listbox.addChangeHandler(new ChangeHandler() {

@Override
    public void onChange(ChangeEvent event) {...}

}

But do not forget to 

listbox.addKeyUpHandler(new KeyUpHandler() {
 @Override
 public void onKeyUp(KeyUpEvent event) {...}
}

for else, the event "the listbox has been selected and value is modified with the keyboard arrows"
 will not be handled even though the value "changes".


Now, shouldn't the ChangeHandler be called ChangeByMouseHandler ? No ?

• use TLS props.put("mail.smtp.starttls.enable","true");
• use port 587  (not 25, not 685)
• use a javax.mail.Authenticator
• add the necessary certificates to the keystore used by your VM
  
  On a *nix system, try   find / -name cacerts |more
and find / -name .keystore |more

• You will find the certificates from your browser settings

As I was installing an Alfresco on a Linux machine, I learned AGAIN.
Damn Alfresco, I know it since the "not yet 1.0" version (was 0.6??) and everytime I use it, I learn new stuff.

Problem:
It all started with my test user seeing mixed languages, English and French in the web interface despite the choice of English at login time. 


OK, problem is solved but it was a pita as I had to "DROP DATABASE alfresco;". Was empty, fortunately.

Short version :
As the "system spaces" like "data dictionnary" are created upon first boot of the webapp, you must not leave YOUR language packs (.properties files) in the .war file. Main culprit was bootstrap-spaces_fr.properties in alfresco.war\WEB-INF\classes\alfresco\messages\

Long version :
I installed on a Linux machine, not using the 1-click installer provided by Alfresco but it would not have changed a thing considering it's the .war file the guilty.

I am not a US resident, nor EN.
I use a Linux VM that I have not set up, physically located in fr_FR, which I tend to forget as I mostly write/code in english (sometimes frenglish).

On first start, the .war file deployed in Tomcat is unpacked and its content is used by the initial process -- including the deadly bootstrap-spaces_fr.properties. 

This process creates what I'll call the "system spaces" (like "data dictionnary") and they are created accordingly to the locale whenever the files are available. If not, the default are used and they are plain English, which is better for a system to be used by people around the world.

The culprit file can be found at alfresco.war\WEB-INF\classes\alfresco\messages\bootstrap-spaces_fr.properties. I moved all _fr.properties files to a subfolder -- just in case.

My advice is to remove all I18N files from the .war before to use it.
Or, you'll have to drop the database and empty the alf_data folder and of course, bear with another looong first start. 

Hint: Setting the JVM's locale to "en_US" could be an option (not verified) at install time.

This post is not about teaching a phone to eat all your waste :)

What to do of "old" phones

As time goes by, one (developper) gets more and more smartphones and specs evolve, leaving older phones behind in terms of daily use.

Thus the question that arises is what to do of "old" phone ?

Of course, the quick and easy answers are :

• let it rest in a drawer for ... hum ... future use.
• give/sell it to someone

What else ... ???

HACKING !

There is a computer in the phone ! Remember ?
Depending on the phone model and the work done for it by the wonderful community, you can :

• install another system, like Ubuntu on a Nexus One
  
• install uncommon services
  
• use as a remote home-monitoring system (camera to take pics periodically and upload to web if delta)
  
• Experiment (roms, ...) : nice way to learn
  

To give an example to that second point, it would be to install a web server with a few pages, tie it to a dynamic dns (you'll need to configure your box/modem of course)

There is web servers for Android, you are not forced to install Ubuntu + Apache :) or even to cook your own.

It all depends all your available time

That is how innovation happens.

Maybe one day, we'll see Tomcat running on a mobile phone without slowing it to death.

Entre autres choses, j'apprécie les traits d'esprit et les jeux de mots.
Il y a quelques années, je me suis intéressé aux contrepeteries et j'ai constaté que le web n'en manquait pas, mais qu'il y avait souvent les mêmes, dupliquées de sites en sites.
J'ai initié le site http://contrepeteries.free.fr pour qu'il soit collaboratif : que les visiteurs l'enrichissent et puissent récupérer les contrep's pour les utiliser sur d'autres supports.
Il y a eu des échanges fructueux avec le créateur d'une appli pour mac, des visiteurs qui ont beaucoup participé (Merci encore à Maud du fond du champ).
Mais le site vivote à 50 visites par jour.

Comme dirait le chien parlant que je n'ai pas : ça c'est de la niche !

A partir des données de mon site, j'ai créé une appli pour smartphones Android.

Elle s'enrichira au fil des versions. Aujourd'hui (v1.1), elle permet de

• consulter +500 contrepeteries au hasard
• partager la contrepeterie affichée (par mail, facebook, twitter, etc ...)
• voir la liste des évolutions à venir (affichage des solutions est l'évolution la plus demandée)

Voici le lien vers le market web https://market.android.com/details?id=org.wadael.contrepeteries

Et le QR code correspondant

Amusez-vous bien et donnez-moi votre avis.
Merci

Today's new concept is

AD-jacking a word based on "AD" (for advertisement) for prefix and "-jacking" (same idea is hijacking, carjacking etc...).

Means : benefiting from another advertisement.

That is, your ad reuse a word, concept or element of language introduced to the audience by a previous advertisement, thus benefiting from it in terms of time. Anything known by your audience does not have to be explained by your own ad, making it shorter than in the opposite case.

Alternate syntax : adjacking, ADjacking, ADJacking

First references I get from googling it refer to hacking with online ads using XSS techniques.
So I might have invented this term.

I have read a post from Eric Vetillard (javacard expert amongst all and a colleague), about smudge attack against android terminals.

To quote his post :

this attack targets the authentication pattern that is used to unlock an Android phone. .... owners also know that smudge really is dangerous for this authentication technique. I have tried it with a colleague: after picking up my phone, it took him 3 tries to get my combination

Why that ? Because :

• fingers are sweaty or greasy or both (weather is good in the south of France, isn't it Eric ?) so they leave traces on our shining screens
• there is only one path to unlock the phone
  
• this path 'looks' always the same on the phone
  

So, that post triggered some thinking. I think I've found possible solutions :)

First proposal
The pattern has to not be static. To reach that, my proposal is to have the dots or equivalents to be in a circle that will rotate.
Not randomly but more like a compass.
Just like a compass has an arrow, an arrow is used so that the user has a landmark and not get lost
Then either link the dots to unlock. (5 tries are allowed instead of 3)
With that, you will never not touch the screen at the same place (unless you unlock only at the very same place, with the same position of the body)
Derivated proposal :
A keyboard which keys are never at the same place, used to enter PIN code.
Most of us already know that, as this is used by online banks. The proposal is to integrate it as a proposed unlocking system.

Third proposal, I call it the psycho-camembert :)
It looks like a camembert (or pie chart) with equal parts coloured differently and having patterns (stripes, dots, etc ..).
This camembert is centered on the screen. Those parts are displayed in a random order.
To unlock, parts have to be dragged toward the exterior. Therefore, the traces on the screen are all lines from the center to the outside.
Of course, its a memory thing and one will have to memorize a colour order. Sorry for those who cannot distinguish colors, thats why patterns can be added.

I hope this contribution will find its way to the good ears.
Let's be frank, all the better if it brings me an all-inclusive invitation to IO 2011 !
I really liked San Francisco and have no idea on how to deserve an invite for next year.

Feel free to indicate me the classes of the API to look at in order to implement it.


Cheers,

Jérôme


Eric's post is here http://javacard.vetilles.com/2010/10/18/smudge-attacks-on-android
You can follow Eric on Twitter : @evetillard http://twitter.com/evetillard

Last May, I visited San Francisco.

One of my preferred shots is :

It is a firemen truck. Red, huge, shiny : a boy's dream !!
Actually, my boy dreamed of it :)

21or22 May 2010, San Francisco, near North Beach