Cette année, pas de ForumPHP à Paris faute de travaux à la Villette. Cependant, l'AFUP a mis en place une nouvelle formule : le PHPTour, un événement itinérant qui se déroulera dans une ville différente à chaque fois. Cette année, c'est à Lille et j'y serias. A ce sujet, je vous fais part de mon programme des sessions que je suivrais.
Le jeudi, je commencerais par la présentation de PHP 5.4 par David Sora Parra en session plénière. Ensuite, pour la première matinée de sessions:
Traitement XML de pointe avec PHP et XQuery
Tenue en charge d'un site média
Optimiser la performance business de votre site avec l'A/B testing.
Après un bon repas, je suivrais la conférence de Zeev Suraski qui présentera le nouveau produit phpcloud.com. J'aimerais en savoir plus sur ce sujet. L'après midi se poursuivra avec:
- La conférence sur les tests Mock, Stubs et Tests m'intéresse particulièrement car mon projet actuel me pose quelques soucis concernant la mise en place des tests
- la présentation d'Atoum, le framework de test unitaire, mis en place par Frédéric Hardy
- je terminerais la première journée par la présentation : Pourquoi on a abandonné Magento au profit d'un dévéloppement spécifique. Très intéressé de connaître les différents éléments qui les ont poussés à ce choix
Pour la deuxième journée :
- êtes-vous prêt pour le succès ?
- Comment développer et déployer une application PHP maintenable ? J'espère pouvoir glâner des bonnes pratiques, cela peut notamment aider dans le cadre de déploiement d'applicatif PHP (non web)
- Profiling PHP Applications par Derick Rethans. Je rappelle que Derick est le créateur de Xdebug entre autres...
- Sécurité des applications PHP, j'attends de voir sous quel angle sera réalisé cette session
Pour la dernière demi-journée, encore une fois, j'aimerais me divisé pour aller à toutes les sessions. Mais il faut faire un choix :
- Caching and Tuning fun for high scalability
- dev et admin sys : une cohabitation simplifiée... pour éviter de se taper dessus entre les deux équipes ;)
Ca fait un bon programme et je préparerais un compte-rendu des sessions que j'aurais suivi dans ce blog.
Ce petit bijou de robotique est suisse. En plus d'être rapide, il est également extrêmement précis, ce qui lui laisse un large champ d'application.
Les moteurs sont en rotation mais en sortie le mouvement est toujours une translation. Inventé par Reymond Clavel, ce robot est inspiré de l'industrie du chocolat. Le robot avec du matériel standard atteint les 15G d'accélérations. On entend d'ailleurs parler d'un robot qui atteint les 100G.
C'est juste hallucinant. La vidéo parle d'elle-même.
Un ami m'a fait découvrir récemment un outil que j'appellerais outil pour ultra geek disponible uniquement sous Mac. Cet outil permet d'afficher sur le bureau tout un ensemble d'informations diverses et varié. C'est à vous de faire votre propre configuration.
Cet outil s'appelle Geektool. Trois modes de fonctionnement sont disponibles :
le mode Fichier qui vous permettra de surveiller l'activité sur votre MacOS X
le mode Image qui vous permet d'afficher des graphiques, /images (assez intéressant pour avoir des graphs d'utilisation réseau ou CPU par exemple)
le mode Shell qui vous permet de lancer une commande shell
Voici par exemple, ce que j'ai mis sur mon bureau :
Ca y est, la Release d'Arduino en 1.0 arrive bientôt. Elle est en effet annoncé sur le blog Arduino. Beaucoup de choses vont évolués entre la dernière version 0 et la 1.0. Un premier résumé en attendant la traduction compléte du Changelog.
Côté IDE, le point le plus important est sans doute le changement des extensions de fichier notammement pour eviter les conflits avec le logiciel Processing. On peut également noté des évolutions au niveau de l'interface (icônes, barres de progression…).
Côté SDK, les évolutions sont bien plus importantes :
transmission série en asynchrone (via Serial) : ça laisse présager de belle mise en application
support des écritures de chaines de caractères sur mémoire Flash au lieu de la mémoire RAM
support DNS et DHCP au sein de la library Ethernet : auparavant il fallait faire appel à une lib externe ou directement passer par les adresses IP
support de plusieurs fichiers dans la librairie SD
Le boulot apporté est donc très conséquent et va permettre de réaliser des mises en application beaucoup plus complexes :)
Je viens de terminer la lecture du dernier livre de Jan Ozer : Video Compression for Flash, Apple Devices and Html5. Ce livre est un petit bijou. Que vous travaillez directement sur la vidéo, si vous en êtes proche ou même si vous souhaitez approfondir vos connaissances techniques, ce livre est fait pour vous.
Le livre aborde les points suivants :
une première partie aborde le H264 (le codec vidéo) en partant de la théorie pour arriver progressivement aux paramétrages et aux outils qui permettent les transcodages
une petite partie aborde WebM, VP6 et WMV
ensuite, comment préparer les contenus pour les différentes cibles : Flash, iOS, HTML5
enfin l'auteur aborde enfin des outils plus industriels, les méthodes de diffusion
Au final, ce livre est réellement à avoir dans une bibliothèque de livre technique/technologique lié au Web.
Disponible sur [Amazon](http://www.amazon.fr/Video-Compression-Flash-Apple-Devices/dp/0976259508/) (en anglais)
Une discussion sur Twitter très intéressante s'est entamé hier soir avec @skywood. En effet, ce dernier me posa la question suivante : comment récupérer les coordonnées d'un relais téléphonique (je décrivais ces relais dans un précédent billet).
un code pour la zone géographique : LAC Local Area Code
un code pour l'opérateur télécom MNC Mobile Network Code
un code pour réseau national : MMC Mobile Country Code
A partir de ces informations, le téléphone est capable de se localiser via une API chez Google (à vérifier pour l'utilisation). La précision est plutôt intéressante (jusqu'à 60-90 mètres).
A propos de relais téléphonique, vous pouvez retrouver deux bases de données permettant de retrouver les positions des relais :
- OpenCellID : une base open source contenant les coordonnées GPS mais également les informations cités plus haut dans cet article
- ANFR (Agence Nationale des Fréquences) : cette base regroupe l'ensemble des relais téléphoniques, des antennes de radiodiffusion et également des points de mesures
On peut également observer sur cette image la couverture des opérateurs téléphoniques :
Je crois que @skywodd souhaite en faire un projet, j'attends de voir ce que cela va donner. On verra également si l'API Google est disponible sans limite d'utilisation (ou des limites cohérentes).
Linky est le nouveau compteur EDF dit "intelligent". Actuellement en test sur deux régions de France, le gouvernement prendra normalement la décision finale de déploiement durant l'été. A la base, cette décision devait être prise durant l'hiver 2011. Mais cela va nous coûter et pas uniquement sur notre porte-monnaie.
Pour la petite histoire, ce nouveau compteur fait parti d'un projet plus global de réseaux électriques intelligents au niveau européen : le Smart Grid. En France, le projet s'appelle "Linky" tout comme le nouveau compteur. Il serait mis en place dans 35 millions de foyers. Les objectifs principaux sont les réductions des coûts tout particulièrement côté EDF. En effet, ce compteur sera pilotable à distance :
oublions donc le passage d'un technicien EDF pour l'ouverture, relevé / fermeture des compteurs
en cas de non-paiement, le distributeur pourra couper l'arrivée électrique
les informations à propos de la consommation seront en temps réel.
Côté technique, la technologie utilisée sera le CPL pour relier le compteur Linky au concentrateur. Le protocole utilisé est côté réseau PLAN (norme IEC_61334) et pour la partie applicative la message COSEM (norme IEC_62056). J'ai trouvé une présentation (PDF) plus précise du protocole de COSEM. Je n'ai rien trouvé au sujet du cryptage des données lors du transport des données. A cet effet, je me pose la question de l'accès aux autres Linky depuis un point du réseau. Quelle est la sécurité associée : les informations transiteront via le CPL, mais quel sera la sécurité utilisée lors de la communication ? Une personne sera-t-elle capable via un peu de bricolage et un peu de développement d'accéder à mon compteur et y effectuer des actions ? En tant que technicien, je sais que le 100% sécurité n'existe pas, mais je souhaite tout de même connaître le risque associé...
Le compteur sera finalement payant : 120 à 240 €, étalé sur 10ans soit 1 à 2 € en plus par mois, à la base cela n'était pas prévu. Pourquoi une telle différence de prix d'ailleurs, on va tout de même du simple au double. La pose sera effectué non pas par EDF, mais par des prestataires tierces. Encore un point complètement ahurissant. De plus, et c'est un comble total là, ils ont trouvé le moyen de nous faire payer l'accès aux informations (à nos informations privées) via internet. Inadmissible !!
Des questions se posent : pourquoi devons-nous payer 3,5€ par mois pour avoir accès aux informations ? C'est comme si nous achetions un téléphone portable mais que nous devrions payer l'opérateur pour accéder aux informations de consommations (tels des appels entrants / sortants etc...). Où et comment sont stockés les données et quel est le traitement associé (en plus de celui pour EDF) ? En temps réel, le distributeur saura ce que chaque habitant fait : "Les informations de consommation d'énergie transmises par les compteurs sont très détaillées et permettent de savoir beaucoup de choses sur les occupants d'une habitation, comme leur horaire de réveil, le moment où ils prennent une douche ou bien quand ils utilisent certains appareils (four, bouilloire, toaster…)", comme l'a signalé la CNIL. Cet article d'energie2007.fr montre également qu'en fait, il serait possible de faire "sauter" ce déploiement dans le cas où l'abonné n'en tire pas d'avantages... et on peut le voir c'est le cas.
L'objectif annoncé du projet était de permettre la réduction des factures, or lors de la phase d'expérimentation, ils ont observé une réduction de 50€ environ sur l'année. Si l'utilisateur veut accéder aux données, il devra payer 3,5€ x 12 = 42 €... quel intérêt alors mis à part engraisser EDF et ses prestataires !
Pour résumé, je me pose énormément pour mon habitat et ma vie privée et actuellement, aucune réelle assurance n'est disponible sur la toile. Je suis ouvert à tout retour d'expérience ou précision plus technique sur le système.
En quelques jours, je suis tombé sur deux vidéos assez bluffantes des possibilités offertes par Kinect. Rappelons que le SDK du Kinect est disponible sur le site de Microsoft.
Le premier exemple montre Rajarshi Roy qui a développé un outil permettant d'utiliser le Kinect pour jouer à différents jeux sur PC (ex : NeedForSpeed, Portal, etc...). On voit sur la vidéo qu'un calibrage est nécessaire afin de jouer. Le code source est également disponible, du nettoyage sera fait prochainement.
La seconde démo est elle totalement hallucinante. On y voit un homme pilotant via son Kinect un quadcopter (une sorte de ARDrone de chez Parrot). Plutôt qu'un long discours, je vous laisse lire la vidéo.
L'objectif de cet article est d'obtenir un aperçu d'une partie des différents protocoles utilisables pour le transport de données dans le cadre d'une installation de domotique. Je vais aborder uniquement les 4 plus importants qui sont portés soient par des alliances, soit par des regroupements de sociétés.
Zigbee
C'est un standard de communication récent (début des années 2000) permettant l'échange d'informations via onde radio avec une consommation réduite. Il est porté par une alliance du même nom dont le but est de promouvoir la technologie. Les fréquences sont 868Mhz, 915Mhz et 2,4GHz à utiliser selon la zone géographique (Europe, Amérique, Monde...). Le standard s'appuie également sur la norme IEEE 202.15.4.
Le module Xbee se repose sur ce standard de communication et permet l'utilisation de ce protocole.
X10
Si vous avez une Freebox avec les prises CPL, vous connaissez déjà dans les grandes lignes le principe. En effet, tout comme le Homeplug de la Freebox, le protocole X10 est un protocole de communication par courant porteur développé dans les années 70. Il passe par le circuit électrique de l'habitation. Le protocole se base sur la sinosoïde du courant électrique alternatif pour transmettre les informations. Sa fréquence est de 120Hz.
On peut distinguer plusieurs avantages : il se base sur le circuit électrique (donc pas besoin de faire passer des câbles en plus), il n'y a pas d'ondes en plus, son coût est peu cher. En revanche, il a différents inconvénients : pas de compatibilité USA / France par exemple dû à la fréquence du courant, sensibilité aux ondes (par exemple une télévision trop proche)
EIB/KNX
C'est un standard pour le contrôle des maisons et des bâtiments. EIB (European Industrial Bus) est un standard créé à la fin des années 80, ayant pour but d'améliorer la communication entre les équipements des bâtiments et de permettre l'interopérabilité entre les équipements EIB. Le résultat donna la norme EIB/KNX. La spécification KNX fut publié en 2002. Le très bon article de l'académie d'Aix-Marseille rentre plus en détails dans cette norme.
1-Wire
C'est un protocole de communication basé sur un bus (série ou parallèle) via 2 fils : un fil pour les données et un fil pour la masse. Il est utilisé principalement pour des capteurs : températures, taux de gaz ou autres systèmes de météorologie. Il peut être également utilisé pour la gestion de l'énergie (onduleur, batteries, ...).
Naturellement, d'autres protocoles existent, cependant ils sont beaucoup moins utilisés notamment car utilisés par des sociétés moins populaires.
Cette année, pas de ForumPHP à Paris faute de travaux à la Villette. Cependant, l'AFUP a mis en place une nouvelle formule : le PHPTour, un événement itinérant qui se déroulera dans une ville différente à chaque fois. Cette année, c'est à Lille et j'y serias. A ce sujet, je vous fais part de mon programme des sessions que je suivrais.
](/images/2011/11/geektool.png)
C'est un standard de communication récent (début des années 2000) permettant l'échange d'informations via onde radio avec une consommation réduite. Il est porté par une 