Blog
-
Utiliser l’API des climatiseurs DAIKIN
Aujourd’hui, je vous partage ma dernière création. Une libraire destinée à contrôler les climatiseurs Daikin.
Voici les unités compatibles (2021)
BRP069A41
- dispositif de commande inclus avec l’unité
Vous pouvez l’installer avec composer https://packagist.org/packages/daikin/api
Enjoy 🙂
-
Il faut rendre à César ce qui est à César
blog de Korben, je les reprends essentiellement pour m’en servir comme pense-bête.
Les 3 lignes de commandes ci-dessous proviennent duMerci à lui pour ses nombreux posts très intéressants.
Sous Windows
Sous le système d’exploitation de Microsoft, d’abord, il vous faudra ouvrir une invite de commande et entrer la ligne suivante, en remplaçant NOM_DU_RESEAU_WIFI par le vrai nom du réseau wifi sur lequel vous êtes connecté :
netsh wlan show profile NOM_DU_RESEAU_WIFI key=clear
Sous macOS
Sous macOS c’est sensiblement la même chose. Ouvrez un terminal et entrez la commande suivante :
security find-generic-password -wa NOM_DU_RESEAU_WIFI
Sous Linux
Et sous Linux c’est pareil, ouvrez un terminal et entrez la commande suivante :
sudo cat /etc/NetworkManager/system-connections/NOM_DU_RESEAU_WIFI | grep psk=
-
Installer la solution domotique NextDom sous Debian9.5
Le projet NextDom avance bien. Il s’agit d’une refonte du core de Jeedom dans le but d’en améliorer la maintenabilité et les performances. Un gros travail a été fourni par des personnes formidables sur ces points. Nous en avons profité pour améliorer l’aspect visuel en utilisant le template basé sur bootstrap (pour la compatibilité) adminLte.
En exclusivité, voici la procédure d’installation.
J’attends des retours de votre part pour rechercher les bugs qui aurait pu rester.
Je vous conseille de vérifier que vous n’avez pas de dossier html dans /var/www/ dans ce cas, supprimez-le, avant de commencer.
Voici la procédure de test :
Installation
apt install -y software-properties-common gnupg wget unzip curl add-apt-repository non-free wget -qO - http://debian.nextdom.org/debian/nextdom.gpg.key | apt-key add - echo "deb http://debian.nextdom.org/debian nextdom main" > /etc/apt/sources.list.d/nextdom.list apt update
1/ Solution simple pour installer la version stable sur une machine
apt install nextdom
Installe Nextdom et la BDD (base de données) en local sur la machine.
Les paquets nextdom-common et nextdom-mysql sont automatiquement installés.Vous avez aussi la possibilité de faire tout cela automatiquement en rendant ce script exécutable : https://raw.githubusercontent.com/NextDom/NextDom-DebInstaller/master/deb-install.sh
Bon test 😉
-
NextDom fait sa conférence
Salut à tous !
Juste un petit message pour vous dire que NextDom sera présenté officiellement lors du Open Source Summit de Paris 2018.
A cette occasion, Vincent Fresnel aka byackee et Astral0 seront heureux de vous faire découvrir notre solution Domotique et Opensource. Venez nombreux leurs poser des questions !
-
Bonne pratiques des nommages en css
Dans le projet NextDom, nous sommes confrontés à la refonte du style. Beaucoup de style est directement présent dans le HTML. Il fallait repartir sur de bonnes bases si nous voulions assurer la pérennité de notre développement.
En premiers lieux, nous avons décidé d’utiliser SASS. On y gagne :- les variables,
- la vérification de syntaxe,
- une meilleure lisibilité,
- la possibilité d’utiliser la syntaxe CSS et de la transformer petit à petit en SCSS,
- la possibilité de découper facilement d’énormes feuilles de styles en de plus petits fichiers plus digestes
la sortie du style du HTML est un gros morceau que mes collègues ont commencé et ce n’est pas simple. Très vite est apparu le besoin de créer de nouvelles classes et surtout de les nommer correctement.
C’est un point très compliqué en informatique, savoir nommer les choses et ce n’est pas que moi qui le dit :
There are only two hard things in Computer Science: cache invalidation and naming things.
– Phil Karlton
Lorsque je fais une intégration, j’essaie de concilier deux choses vraiment pas évidentes. Je veux rendre le plus abstrait possible le nom de mes classes et en même temps, il faut ce même nom soit le plus compréhensible possible. Sachant que je ne suis pas un spécialiste du frontend et que j’en fais que quand je suis vraiment obligé…
Des exemples de ce qu’il ne faut pas faire
Mon expérience m’a fait rencontrer des choses étranges :
.h1, .h2, .h3 ... /pre> Vouloir créer des classes pour faire passer une balise pour ce qu'elle n'est pas n'est pas une bonne pratique. C'est comme si on mettait une étiquette girafe à un éléphant, un éléphant reste un éléphant. Pour l'accessibilité des personnes défaillantes visuelles ou autre, elles perdent la sémantique de l’information qui leur est présentée.
.span_colorblue, .pre_code-php ... /pre> Dans le cas vu ci-dessus, on mélange la sémantique de la balise et le style qu'on veut lui appliquer. Par ailleurs, "span_colorblue" ne donne pas d'information sur l'utilité réelle de cette classe si ce n'est que le texte est en bleu. Pourquoi n'aurait-on pas besoin d'une couleur bleu ailleurs qu'avec un span ?
.toto > div > p > img { width: 500px; }
Il faut aussi faire attention de ne pas trop lier l’imbrication des balises avec la feuille de style. Un seul sous niveau est un maximum. Au-delà, l’imbrication est trop forte et le moindre changement est trop long à répercuter. Si vous voulez atteindre les images, mettez une classe à « img » et le problème est réglé.
CammelCase ou snake-case ?
À la lecture de la norme sur le document de référence du W3C on se rend compte que les attributs id et classes sont « case-insensitive », les seuls séparateurs autorisés sont le « – « et le « _ ».
https://www.w3.org/TR/CSS21/syndata.html#characters
All CSS syntax is case-insensitive within the ASCII range (i.e., [a-z] and [A-Z] are equivalent), except for parts that are not under the control of CSS. For example, the case-sensitivity of values of the HTML attributes « id » and « class », of font names, and of URIs lies outside the scope of this specification. Note in particular that element names are case-insensitive in HTML, but case-sensitive in XML.
La symbolique
la première question à se poser est : « Qu’est-ce que je veux représenter et dans quel contexte« . Si on répond à ces deux questions, on a rapidement des noms qui nous viens à l’esprit.
Regardons le code HTML suivant :
<div class="background-blue"> <h1 class="strong">Un super titre</h1> <h2>Un super sous-titre</h2> </div> <div class="normal"> <p> Lorem ipsum dolor sit amet, consectetur adipisicing elit. Minima ratione vero ad repellat ea. Sint, est, eligendi expedita ducimus magnam quae voluptate! Amet possimus error sapiente consectetur dolore qui illo? </p> </div>
Les classes « background-blue », « strong » et « normal » sont instanciées. Le problème, vous l’aurez compris, est qu’elles n’indiquent pas pour quel usage réel, elles sont destinées. La classe « normal » n’a pas de signification. Qu’est-ce qui est normal ?
Selon moi, voici ce qu’il aurait fallu faire.
<div class="head"> <h1 class="head-title">Un super titre</h1> <h2>Un super sous-titre</h2> </div> <div class="content"> <p> Lorem ipsum dolor sit amet, consectetur adipisicing elit. Minima ratione vero ad repellat ea. Sint, est, eligendi expedita ducimus magnam quae voluptate! Amet possimus error sapiente consectetur dolore qui illo? </p> </div>
J’ai choisi l’anglais pour nommer mes classes, c’est un choix qui n’engage que moi. Regardons attentivement la première div, la classe « head » indique que nous sommes dans le contexte d’un entête qui contient des titres et sous-titre. On a le schéma suivant A contient A-B, etc.
Dans la div suivante, « normal » a été remplacé par « content » car c’est l’objet de cette div de contenir un texte.
J’attends vos retours pour agrémenter cet article… -
Une interview de Jérémie Zimmermann
Cette année, Jérémie a quitté la quadrature du net. Pas de rancune, mais une prise de recul très intéressante sur le fonctionnement du lobbying à Bruxelles.
-
La RGPD Expliqué par un DEV (Frédéric Hardy)
Encore une fois, Frédéric Hardy a réalisé une conférence de très bonne qualité sur la RGPD dans le cadre du PHP tour 2018 à Montpellier. Je vous incite fortement à regarder cette vidéo.
-
NextDom, l’avenir de la domotique !
Je vais vous parler de NextDom un projet domotique ambitieux. J’ai longtemps été un contributeur de l’application en PHP Jeedom. Avec le temps, j’ai voulu aider le projet en contribuant plus et en mettant en avant les bonnes pratiques du développement. J’ai donc fait de nombreux PR sur le Github du projet. Ce fut la douche froide !!
Le lead développeur est fermé à toutes évolutions qu’il considère comme une perte de temps.
Celles qui font perdre du temps sont :
L’ajout de documentation dans le code sous forme de PHPDoc
- La refactorisation de code faisant plus de 200 ligne pour une méthode/fonction
- La normalisation du coding style vers les PSR
- L’introduction de tests unitaires
- L’introduction de Namespaces
- L’utilisation cohérente de composer
- … /li>
On parle d’un projet sous Licence GPL, pas d’un projet dont le code source est privé.
Je n’étais pas le seul à vouloir faire évoluer Jeedom vers plus de qualité. Avec le temps, j’ai découvert un groupe de personnes partageant le même point de vue que moi. Un très bon groupe, ouvert et sympathique. Ce groupe a tenté une médiation avec Jeedom SAS, la maison mère de Jeedom. À l’issue de cette discutions, il a été convenu que la communication avec les développeurs serait revue et améliorée.
Malheureusement, rien n’est allé dans le bon sens. Les CGV/CGU de Jeedom ont été modifiés en rendant responsable le développeur de tous dommages physiques ou moraux. Inacceptable et contraire au principe de responsabilité de chaque un.
D’autant plus que Jeedom s’exonère de cette responsabilité. 2 poids, 2 mesures…
Comme cette situation n’est pas tenable, on a décidé de donner un nom à notre organisation : « NextDom« .
La situation s’est envenimée aujourd’hui. Sur le forum Jeedom, il est interdit d’utiliser le mot NextDom. Il est automatiquement remplacé par « NotAutorized », comme si on avait écrit des insultes…
Longue vie à NextDom un fork de Jeedom voir une solution complètement alternative.
-
Règlement général sur la protection des données personnelles (RGPD)
Bonjour,Le Règlement général sur la protection des données personnelles (RGPD) sera appliqué le 25/05/2018. C’est une notion qu’il faudra intégrer dans votre vie professionnelle.Je vous ai trouvé cet article en libre accès sur NextImpact expliquant ligne par ligne ce qu’il faut faire.Bonne lecture !
-
Soumettre un sitemap.xml à Google, et Bing
Bonjour,
Ce petit code va vous permettre de soumettre votre sitemap.xml aux 2 principaux moteurs de recherche, soit Google search et Bing.
<?php class searchEngineSubmitter{ private $urls; public function getUrls(){ return $this->urls ; } /** * @param array $urlsForSubmitting */ public function __construct(array $urlsForSubmitting){ $this->urls = $urlsForSubmitting; } /** * * @param string $url * @return type */ private function myCurl($url) { $ch = curl_init($url); curl_setopt($ch, CURLOPT_HEADER, 0); curl_exec($ch); $httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE); curl_close($ch); return $httpCode; } /* * @abstract Sitemap Submitter Use this script to submit your site maps automatically to Google, Bing.MSN and Ask Trigger this script on a schedule of your choosing or after your site map gets updated. * @param string */ public function submitSitemap($sitemapUrl) { foreach ( $this->getUrls() as $url) { $code = $this->myCurl($url . $sitemapUrl); if ($code == '200') { return 'success: ' . parse_url($url, PHP_URL_HOST) . ' has been pinged (return code: ' . $code . ' )'; } else { return 'warning' . parse_url($url, PHP_URL_HOST) . ' return error (return code: ' . $code . ' )'; } } } }
Pour l’utiliser on fait comme ceci :
<?php $submit = (new searchEngineSubmitter( ["http://www.google.com/webmasters/sitemaps/ping?sitemap=", "http://www.bing.com/webmaster/ping.aspx?siteMap="])) ->submitSitemap('http://www.mywebsite.com');
Et voilà 🙂
@ bientôt
-
Valider les champs d’un formulaire avec Silex et « Validator Constraints »
Je me suis associé à Baptiste Pesquet l’auteur du cours sur Openclassrooms « Évoluez vers une architecture PHP professionnelle ». La validation des champs est désormais compatible avec la version 2.1 de silex c’est l’itération 14.
Bonjour,
Aujourd’hui nous allons voir comment ajouter la validation des valeurs de retour d’un formulaire dans le framework Silex.
Après avoir suivi le cours sur Openclassrooms « Évoluez vers une architecture PHP professionnelle », il vous manquera cette partie avant de mettre votre site en ligne.
Pourquoi valider les champs ?
Pour s’assurer que les utilisateurs du site ne cherche pas à enter n’importe quelle donnée n’importe où. Par exemple un numéro de téléphone dans le champ email, tenter de faire passer des valeurs inapproprié et exploiter une faille xss…
Voici comment nous allons procéder :
Dans un premier temps nous allons ajouter un namespace qui sera utilisé par votre buildForm:: ce namespace c’est :
use Symfony\Component\Validator\Constraints as Assert;
Voici ce que j’ai fait pour l’enregistrement d’un email :
<?php namespace MicroCMS\Form\Type; use Symfony\Component\Form\AbstractType; use Symfony\Component\Form\FormBuilderInterface; class NewsletterType extends AbstractType { public function buildForm(FormBuilderInterface $builder, array $options) { $builder->add('email', 'email', [ 'label' => '', 'required' => true, ]); } public function getName() { return 'newsletter'; } }
On vois que j’ai mis plusieurs contraintes. En premier lieu j’ai décidé que le champ est de type « email »et qu’il est « requis » (required), c’est à dire que sur le html généré, on verra ceci :
<input id="newsletter_email" name="newsletter[email]" required="required" placeholder="Votre email pour vous inscrire à la Newsletter" type="email">
Si l’utilisateur a un navigateur récent, et qu’il soumet le formulaire directement, un message lui dira que ce n’est pas possible car le champ est vide. Si il remplit ce champ avec autre chose qu’un email le navigateur va là aussi l’informer que cette donnée n’est pas valide. C’est une première étape car si l’utilisateur est un petit malin, il peut modifier le type de champ dans le input, supprimer le required et le email. à ce moment là, il pourra soumettre le formulaire sans message d’erreur.
Il faut donc procéder à une deuxième vérification sur les données au niveau du framework et pas seulement dans le navigateur.
Pour cela on va rajouter cette ligne dans notre méthode buildForm, ‘constraints’ => new Assert\Email(),
<?php namespace MicroCMS\Form\Type; use Symfony\Component\Form\AbstractType; use Symfony\Component\Form\FormBuilderInterface; use Symfony\Component\Validator\Constraints as Assert; class NewsletterType extends AbstractType { public function buildForm(FormBuilderInterface $builder, array $options) { $builder->add('email', 'email', [ 'label' => '', 'required' => true, 'constraints' => new Assert\Email(), ]); } public function getName() { return 'newsletter'; } }
Là, on est certain que la valeur attendu sera un email et pas autre chose. Si l’utilisateur fait le malin au niveau de son navigateur, voici ce qui va s’afficher :
- This value is not a valid email address.
Grand maître L
-
Thomas pesquet
Hop Hop Hop ! je sors ce blog de son sommeil pour vous rappeler à tous que ce soir Thomas Pesquet prend son envol pour l’ISS. Je lui souhaite bon vol !