Twister's blog

Aller au contenu | Aller au menu | Aller à la recherche

mercredi, octobre 8 2014

Log4j et SocketAppender

J'ai récemment (bon ok en juin...) pluggé nos applications J2EE sur un serveur LogStash/ElasticSearch afin de pouvoir facilement consulter tous les logs de toutes nos plateformes. Pour ca j'ai utilisé le SocketAppender de Log4j. C'était merveilleux, jusqu'au jour où...

Lire la suite


mardi, mai 6 2014

Alt-Grab

Je viens juste de découvrir ce petit outil pour Windows : Alt Grab. Il permet de pouvoir déplacer les fenêtre sous windows en utilisant Alt-Clic. Ca fait du bien un peu plus de Linux dans son Windows ;).

J'en profite pour conseiller d'autres petit outils que j'utilise au quotidien sous Windows pour avoir la vie plus facile :

Promis je vous partage bientôt ma conf autohotkey pour bien piloter son Spotify ;)


mercredi, mars 19 2014

Callbacks

Cela fait déjà une bonne dizaine de fois que je peste pour la même chose sur mon projet actuel : le chaînage des traitements dans tous les sens avec des fils de partout. Un schema très récurrent est "j'ai besoin de faire quelque chose après un traitement générique qui tourne dans un thread, mais cette chose dépend de paramètres qui ne sont jamais les mêmes suivant de où j'appelle mon traitement. Bon bah je vais rajouter pleins de paramètres à la méthode de mon traitement et me les traîner sur toute ma stack pour pouvoir faire ce qu'il faut à la fin". NOON ! Il faut arrêter les conneries. Si vous avez un traitement qui fonctionne gardez le comme ça, ATOMIQUE. Si les traitements qui suivent sont différents en fonction des appelants utilisez des Callbacks !

Un petit (mauvais) exemple :

public class Treatment {
    public static void doMyTreatment(int value1, int value2, int parameter1, int parameter2) {
        new Thread(new Runnable() {
            public void run() {
                /// DO a realy long treatment...
                /// very long...
                int res = value1 + value2;

                if (parameter1 == 0) {
                    doSomthg();
                } else if (parameter1 == 1) {
                    if (parameter2 == 0){
                        goSomewhere();
                } else {
                        cook();
                }
            }
        } 
    }
}

public class Caller1 {
    public void call() {
        Treatment.doMyTreatment(1, 2, 0, 0);
    }
}

public class Caller2 {
    public void call() {
        Treatment.doMyTreatment(1, 2, 1, 1);
    }
}

Ici vous avez les paramètres 1 et 2 qui vont influencer le "quoi" faire après le traitement des valeurs 1 et 2... C'est mal, ça va vite devenir une grosse pelote de laine au fil des ajouts de fonctionnalités. Alors que si vous aviez fait :

public class Treatment {
    public static void doMyTreatment(int value1, int value2, Runnable callback) {
        new Thread(new Runnable() {
            public void run() {
                /// DO a realy long treatment...
                /// very long...
                int res = value1 + value2;

                callback.run();
            }
        } 
    }
}

public class Caller1 {
    public void call() {
        Treatment.doMyTreatment(1, 2, new Runnable() {
            public void run() {
                StaticClass.doSomthg();
            }
        }
    }
}

public class Caller2 {
    public void call() {
        Treatment.doMyTreatment(1, 2, new Runnable() {
            public void run() {
                StaticClass.cook();
            }
        }
    }
}

C'est quand même plus propre. Bon là j'utilise de simples Runnable en callbacks, du coup je n'ai pas possibilité de passé des paramètres à ma méthode run mais ce n'est pas compliqué de définir votre interface perso à la place de Runnable.

Autre point, vous pouvez remplacer la callback par une List pour être capable de chaîner plusieurs traitements.

Et voilà...

dimanche, octobre 6 2013

Vera & Secure SSR-302

Je me suis récemment lancé dans la domotique. Pour commencé j'ai acquis une Vera Lite, un actionneur Secure SSR-302 et un switch Fibaro chez Delta Domotique (que je recommande au passage).

Mise à part de gros problèmes d'ergonomie sur la Vera, tout se passait plutôt pas mal jusqu'à ce que je réalise que la chaudière passe sa vie à s'éteindre. Au bout de quelques allumages je constate qu'elle s'éteint dans l'heure qui suit son allumage. Depuis son installation, le boitier SSR-302 a toujours clignoté en orange, ce qui veut dire qu'il est en fail-safe, j'avoue que comme ça avait l'air de marché je ne m'étais pas trop creusé (:p). Bref finalement, le froid arrivant et la chaudière ne marchant pas si bien que ça, j'ai creusé. Il se trouve que SSR-302 coupe tout une heure après le dernier signal reçu à cause du fameux mode fail-safe (comme quoi j'aurais du creuser tout de suite :p). Ainsi si le contrôleur tombe en rade, au lieu de laisser tout allumer sans contrôle, le SSR-302 coupe tout. Pas si bête à mon sens, mais galère à gérer... En effet lorsque l'on a le thermostat qui va bien c'est lui qui se charge d'envoyer le signal... Malheureusement je m'étais dis que ce serait pour plus tard (ça m'avait déjà couté assez cher :p).

Finalement ma mésaventure tombe plutôt bien puisque ça me démangeait depuis le début de regarder ce que l'on pouvait faire avec la Vera. Du coup ni une ni deux j'ai pris mon notepad et j'ai fais mon premier script LUUP qui se charge d'envoyer un signal au SSR-302 toutes les 45 minutes. Pour ce faire il faut commencer par créer une scène programmée pour s’exécuter toutes les 45 minutes. Cette scène ne fera rien d'autre que d'envoyer un signal d'allumage au SSR-302 s'il est déjà allumé. Pour cela quelques lignes suffisent :

local deviceNo = 13
local SSID = "urn:upnp-org:serviceId:HVAC_UserOperatingMode1"
local actualMode = luup.variable_get(SSID, "ModeTarget", deviceNo )

if (actualMode == "HeatOn") then
    luup.call_action(SSID,
                 "SetModeTarget", {NewModeTarget = "HeatOn"},
                 deviceNo )
end

return true
Et voilà, il vous suffit de remplacer le deviceNo par le numéro de device de votre SSR-302 et le tour est joué!

vendredi, août 2 2013

Lecteur RSS [suite]

Après la mort de Google Reader je pensais avoir trouvé plusieurs remplaçants dont un qui me convenait vraiment : The old reader. Malheureusement suite à un crash majeur de leurs serveurs ils ont décidé de jeter l'éponge et de passer à un mode de site privé pour quelques élus... Résultat je me re-retrouve au point de départ, plus rien pour lire mes flux. Sur les lecteurs existant qu'il me reste il y a donc :

  • Feedly buggant toujours pas mal et étant un poil lourd de temps en temps
  • Newsblur, payant à partir de 64 flux.

N'ayant que 50 flux, je partait donc sur Newsblur. Tout se passa bien pendant une semaine. Mais qu'elle ne fut pas ma surprise de découvrir ce matin une nouvelle limitation à Newsblur : on ne peut plus afficher que 8 articles non lus par flux en version gratuite ! Exit donc Newsblur.

J'ai donc décidé de redonner leur chance au petits lecteurs RSS installable sur un serveur. J'ai commencé par essayer d'installer Newsblur (oui c'est possible puisque le code est sur GitHub). Mais ce truc est une vrai usine à gaz ! Impossible de l'installer facilement... Poubelle!

Finalement après avoir réessayé tout ce qui trainait j'ai fini par installer Tiny-Tiny-RSS qui a en plus sa propre interface Android! Je vais donc voir ce que ça donne à terme, en espérant ne plus avoir à bouger de si tôt :p.

Pour ceux qui le voudrait mon install est ici : http://rss.perriot.fr/. Si vous voulez un compte n'hésitez pas à me faire signe.


- page 1 de 35