Afin de prendre en main concrètement votre tout nouveau shield ou module/carte à base de SIM900/SIM800, il est temps de passer à une utilisation pratique et réelle. Nous allons ici faire reposer notre projet Arduino, non pas directement sur le jeu de commandes Hayes à notre disposition, mais sur une bibliothèque mise à disposition par l'un des fabricants. Comme vous allez le constater, ceci peut être à la fois un avantage et une limitation dans nos travaux.

Cet article pratique a pour but d’introduire le sujet des conteneurs et plus particulièrement les conteneurs Docker. Je détaillerai d’abord l’histoire de Docker, puis je vous proposerai des petits exercices pratiques pour comprendre progressivement les forces et les contraintes de ce nouveau format.

Qu'il s'agisse de dépister des anomalies dans un code que l'on veut robuste ou de démontrer qu'un prestataire n'a pas respecté l'état de l'art, ou plus simplement pour améliorer la qualité de son projet, il arrive un moment où l'on souhaite faire le point sur la qualité technique globale de son projet. Ce genre de travail nécessite bien évidemment une bonne maîtrise de la technologie utilisée, mais aussi un outillage assez élaboré pour analyser et remonter les potentiels problèmes. S'il existe de nombreuses solutions open source – PMD, Cloc, Findbugs... – pour analyser un projet et remonter ses indicateurs, il reste fastidieux de mettre en place tous ces outils et surtout encore plus laborieux de faire la synthèse des différents résultats obtenus.

Après avoir étudié les différentes formes et transformations d'un programme depuis le code source jusqu'à l'exécutable chargé, il nous reste à nous intéresser aux mécanismes qui régissent son exécution. Celle-ci doit s'effectuer dans un cadre très strict, contrôlé à outrance par un autre programme qui joue le rôle d'autorité du système : le noyau.

Meilleurs scores, noms de joueurs, paramètres de configuration, ... autant de données qu'il faut conserver en mémoire : inutile de demander au joueur de saisir une cinquantaine de fois son nom !

Grâce à la miniaturisation des composants électroniques, nous avons au fond de nos poches des téléphones de plus en plus performants. De véritables ordinateurs dotés des dernières technologies... Et le Raspberry Pi dans tout cela, me direz-vous ? C'est simplement un ordinateur qui emprunte la technologie des téléphones mobiles modernes ! Résultat : un ordinateur ultra-compact fonctionnant sous Linux.

Parfois il faut réaliser plusieurs fois les mêmes actions sur une application ou sur des pages Web. Cela peut être pour réaliser des tests en cours de développement ou plus simplement pour les utiliser. Un robot permet d'automatiser les tâches. Dans le cas d'un jeu, il pourra même jouer à votre place...

Depuis quelques années, les imprimantes multifonctions (Multi Function Printer) ont beaucoup évolué en intégrant de nouvelles fonctionnalités : fax, stockage des données sur disque dur, serveurs FTP, serveur mail, serveur web, partages réseau, etc.La plupart des entreprises considèrent encore ces MFP comme un simple périphérique d’impression ou de reprographie, parfois dotés d’un media de stockage pouvant exposer des informations sensibles. Mais beaucoup ignorent qu’en réalité ils connectent un serveur, une boîte noire, souvent laissée dans sa configuration par défaut, à leurs réseaux et par lesquels transitent des informations souvent très sensibles.L’audit de MFP est, de par la nature de ces périphériques, un sujet à la fois abondamment traité et à la fois mal connu. Toute la difficulté d’auditer et de sécuriser ce type de système vient de la dualité entre un système standard - un périphérique IP muni d’un disque dur interagissant via des protocoles standards - et l’aspect boîte noire, chaque modèle étant très spécifique.Cet article est articulé en deux parties, la première traitant de l'audit et la deuxième partie de la sécurisation des MFP ; en gardant une approche duale, présentant à la fois les grands principes et des exemples précis.