Nous avons déjà beaucoup parlé ici et dans Open Silicium de la technologie Bluetooth et de l'utilisation de RFCOMM. Je vous rassure, vous n'aurez pas droit à une nouvelle édition des techniques de base. Ce que nous allons voir brièvement ici et de manière résolument pratique, c'est la façon de, sans la moindre programmation de microcontrôleur, assembler quelques modules pour obtenir des sondes capables d'être interrogées à distance afin de produire de jolis graphiques.

Dans la première partie, nous avons abordé deux aspects fondamentaux de Qemu, la recompilation dynamique du code émulé et la gestion du temps. Cependant, nous sommes restés sur le banc des spectateurs. Bien que Qemu 1.0 supporte 27 machines ARM différentes, aucune n’est basée sur les SoC Freescale™ de la famille i.MX. Dans ce second volet, nous passerons à la pratique en créant « from scratch » le support de l’émulation d’une nouvelle machine construite autour d’un i.MX27 : la carte Armadeus APF27.

Le Bluetooth, c'est un peu comme une créature étrange. Lorsqu'on ne l'a pas encore apprivoisée, elle nous semble farouche, changeante, sauvage et difficile à maîtriser. N'avez-vous jamais eu affaire à cette chose ? Sous la forme d'un casque sans fil ou d'un smartphone, par exemple ? Tantôt visible, puis absent sans raison ? Tantôt fonctionnant à merveille et subitement osant douter de votre identité et vous agresser d'une demande subite de code PIN ? Ce n'est qu'à l'usage qu'on finit par faire du Bluetooth un bon compagnon et qu'on apprend à le caresser dans le sens du poil et qu'il répond ainsi à vos savantes gratouilles. C'est généralement à ce moment que vous constatez qu'il n'est pas si farouche et que vous aurez bien du mal à le délaisser quelques instants...

C'est déjà presque la fin de ce hors-série spécial Django. Mais, avant de vous laisser chevaucher les poneys dans les roses prairies du développement web, nous ne pouvions pas vous laisser partir sans vous présenter un petit panel des lieux où vous trouverez aide, conseils et Djangonautes.

Dans deux articles précédents, nous avons utilisé Scilab pour afficher et animer des modèles 3D. Ce nouvel article va nous plonger dans la création d'un programme qui utilisera les fonctionnalités de Scilab à travers une interface graphique. Vous pourrez ainsi créer de véritables petites applications scientifiques ergonomiques en masquant la complexité du code.

L'une des grandes forces de Django, c'est sans conteste son interface d'administration auto-générée. La partie publique de notre application exemple étant bien avancée, nous allons nous atteler à construire son backoffice.

Un formulaire, lorsqu'on y pense rapidement, ça a l'air simple. Ce n'est après tout que quelques « inputs » et un bouton de « submit ». Mais dès que l'on veut commencer à « faire » des formulaires, on déchante rapidement. Heureusement pour nous, Django propose une gestion des formulaires qui, encore une fois, va prendre en charge une grosse partie du travail.

Imprimer ? Quelle drôle d'idée alors qu'on nous ressasse sans cesse que l'impression nuit à l'environnement, massacre les forêts, prive des petits chatons sans défense de leur maman et que sais-je encore. Mais imprimer des données présente de grands avantages, en particulier en termes de durée de rétention de l'information mais aussi en termes d'accessibilité de ces mêmes informations.

Créer une App, c'est bien, mais la rendre disponible et exploitable par d'autres, c'est mieux.