Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

14 janvier 2013

Créer un odomètre d’entrainement RPi

Création d'un odomètre avec un Raspberry Pi

Brûler l'image de Debian avec Win32Imager en mode « administrateur »

Configurer le raspberry pi

Étendre la partition

Changer le pwd pi/pi

Configurer la langue du clavier et le locale

Configurer split mémoire 256/256 (au cas ou on voudrait avoir environnement graphique)

Et autre options que j'aurais oublié ici

Faire l'update

Se logger in et faire ifconfig pour connaitre l'adresse IP (192.168.1.108)

Quitter le RPi via exit


 

A partir d'ici on fonctionne en mode SSH avec putty sur windows

Se logger in en SSH avec l'utilisateur pi

login as: pi

pi@192.168.1.108's password:

Linux raspberrypi 3.2.27+ #250 PREEMPT Thu Oct 18 19:03:02 BST 2012 armv6l


 

The programs included with the Debian GNU/Linux system are free software;

the exact distribution terms for each program are described in the

individual files in /usr/share/doc/*/copyright.


 

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent

permitted by applicable law.

Last login: Fri Jan 4 11:28:09 2013

pi@raspberrypi ~ $


 

On va avoir besoin des librairies python pour accéder au GPIO. On download avec wget comme suit (ou apt-get)

Allez d'abord sur la page http://pypi.python.org/pypi/RPi.GPIO et copier l'adresse du fichier a downloader (le tar file)

pi@raspberrypi ~ $ wget http://pypi.python.org/packages/source/R/RPi.GPIO/RPi.GPIO-0.4.1a.tar.gz

--2013-01-04 11:57:34-- http://pypi.python.org/packages/source/R/RPi.GPIO/RPi.GPIO-0.4.1a.tar.gz

Résolution de pypi.python.org (pypi.python.org)... 140.211.10.73

Connexion vers pypi.python.org (pypi.python.org)|140.211.10.73|:80...connecté.

requête HTTP transmise, en attente de la réponse...200 OK

Longueur: 15287 (15K) [application/octet-stream]

Sauvegarde en : «RPi.GPIO-0.4.1a.tar.gz»


 

100%[======================================>] 15287 --.-K/s ds 0,09s


 

2013-01-04 11:57:34 (162 KB/s) - «RPi.GPIO-0.4.1a.tar.gz» sauvegardé [15287/15287]


 

pi@raspberrypi ~ $ ls

Desktop python_games RPi.GPIO-0.4.1a.tar.gz

pi@raspberrypi ~ $


 

unzip et untar le fichier

pi@raspberrypi ~ $ ls

] Desktop python_games RPi.GPIO-0.4.1a.tar.gz

pi@raspberrypi ~ $ gunzip RPi.GPIO-0.4.1a.tar.gz

pi@raspberrypi ~ $ tar -xvf RPi.GPIO-0.4.1a.tar

RPi.GPIO-0.4.1a/

RPi.GPIO-0.4.1a/distribute_setup.py

RPi.GPIO-0.4.1a/INSTALL.txt

RPi.GPIO-0.4.1a/setup.cfg

RPi.GPIO-0.4.1a/setup.py

RPi.GPIO-0.4.1a/PKG-INFO

RPi.GPIO-0.4.1a/README.txt

RPi.GPIO-0.4.1a/RPi.GPIO.egg-info/

RPi.GPIO-0.4.1a/RPi.GPIO.egg-info/top_level.txt

RPi.GPIO-0.4.1a/RPi.GPIO.egg-info/PKG-INFO

RPi.GPIO-0.4.1a/RPi.GPIO.egg-info/SOURCES.txt

RPi.GPIO-0.4.1a/RPi.GPIO.egg-info/dependency_links.txt

RPi.GPIO-0.4.1a/RPi/

RPi.GPIO-0.4.1a/RPi/__init__.py

RPi.GPIO-0.4.1a/LICENCE.txt

RPi.GPIO-0.4.1a/.hg/

RPi.GPIO-0.4.1a/.hg/last-message.txt

RPi.GPIO-0.4.1a/MANIFEST.in

RPi.GPIO-0.4.1a/source/

RPi.GPIO-0.4.1a/source/cpuinfo.h

RPi.GPIO-0.4.1a/source/cpuinfo.c

RPi.GPIO-0.4.1a/source/c_gpio.c

RPi.GPIO-0.4.1a/source/c_gpio.h

RPi.GPIO-0.4.1a/source/py_gpio.c

RPi.GPIO-0.4.1a/test/

RPi.GPIO-0.4.1a/test/test.py

RPi.GPIO-0.4.1a/CHANGELOG.txt

pi@raspberrypi ~ $


 

On un nouveau répertoire RPi.GPIO-0.4.1a

pi@raspberrypi ~ $ ls

] Desktop python_games RPi.GPIO-0.4.1a RPi.GPIO-0.4.1a.tar


 

Il faut aller dans ce répertoire et exécuter le script d'installation

pi@raspberrypi ~ $ cd RPi.GPIO-0.4.1a/

pi@raspberrypi ~/RPi.GPIO-0.4.1a $ sudo python setup.py install

Downloading http://pypi.python.org/packages/source/d/distribute/distribute-0.6.27.tar.gz

Extracting in /tmp/tmp0LCim0

Now working in /tmp/tmp0LCim0/distribute-0.6.27

Building a Distribute egg in /home/pi/RPi.GPIO-0.4.1a

/home/pi/RPi.GPIO-0.4.1a/distribute-0.6.27-py2.7.egg

running install

Checking .pth file support in /usr/local/lib/python2.7/dist-packages/

/usr/bin/python -E -c pass

TEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files

running bdist_egg

running egg_info

writing RPi.GPIO.egg-info/PKG-INFO

writing top-level names to RPi.GPIO.egg-info/top_level.txt

writing dependency_links to RPi.GPIO.egg-info/dependency_links.txt

reading manifest file 'RPi.GPIO.egg-info/SOURCES.txt'

reading manifest template 'MANIFEST.in'

writing manifest file 'RPi.GPIO.egg-info/SOURCES.txt'

installing library code to build/bdist.linux-armv6l/egg

running install_lib

running build_py

creating build

creating build/lib.linux-armv6l-2.7

creating build/lib.linux-armv6l-2.7/RPi

copying RPi/__init__.py -> build/lib.linux-armv6l-2.7/RPi

running build_ext

building 'RPi.GPIO' extension

creating build/temp.linux-armv6l-2.7

creating build/temp.linux-armv6l-2.7/source

gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.7 -c source/py_gpio.c -o build/temp.linux-armv6l-2.7/source/py_gpio.o

source/py_gpio.c:23:20: fatal error: Python.h: Aucun fichier ou dossier de ce type

compilation terminated.

error: command 'gcc' failed with exit status 1

pi@raspberrypi ~/RPi.GPIO-0.4.1a $


 

On remonte dans notre répertoire /home/pi

pi@raspberrypi ~/RPi.GPIO-0.4.1a $ cd ..

pi@raspberrypi ~ $


 

Créons le programme pour le speedometer en créant le fichier speed.py

nano speed.py


 

Écrire le programme suivant :

#!/usr/bin/python

import time

import RPi.GPIO as GPIO


 

GPIO.setmode(GPIO.BOARD)


 

lastState = False

lastTime = time.time()

currTime = lastTime

cumulDist = 0


 

GPIO.setup(11,GPIO.IN)

GPIO.setup(12,GPIO.OUT)


 

while True:

currState = GPIO.input(11)

#print currState

if currState and not lastState :

#if we pass from low to high

currTime = time.time()

dt = currTime-lastTime

currSpeed = 7.6104/dt

#2.114m de circonference * 3600s/h / 1000 m/km

cumulDist += 2.114

print "Distance,", cumulDist/1000, ",km, Current speed ," ,currSpeed, ",Time,", time.time()

# print dt

GPIO.output(12,False)

time.sleep(0.001)

GPIO.output(12,True)

else :

# print "."

GPIO.output(12,True)

lastState = currState

lastTime = currTime

time.sleep(0.001)


 

Rendre le programme directement exécutable en faisant :

chmod +x speed.py

Rouler directement avec

sudo ./speed.py    


 

Ou, pour créer un fichier

sudo ./speed.py > out.dat


 

Montage électronique (diagramme avec http://www.digikey.com/schemeit )



 

Montage électro mécanique


Avec Filezilla en mode ssh sur le port 22, télécharger le fichier sur Windows et importer dans Excel pour faire le graphique de la vitesse par exemple.



 


 

04 septembre 2012

Capsules sur les essais unitaires

Je viens de publier une série de capsules vidéos sur les essais unitaires. On total les sept capsules durent environ 45 minutes. Bonne écoute...
 
Voici une description de chaque capsule avec un hyperlien pour y accéder.
 

Que sont les essais unitaires? La première capsule "Les niveaux d'essais" (5 minutes) situe les essais unitaires par rapport aux deux autres grands niveaux d'essais que sont les essais d'intégration et d'acceptation.

 

Comment aborder les essais unitaires? La seconde capsule "Stratégie d'essais unitaires" (2 min) insiste sur l'importance de la réflexion préalable sur ce que seront les essais unitaires dans un projet donné.

 

Quoi tester en essais unitaires? Ensuite, on aborde dans "La nature des essais unitaires" (7 min)les diverses catégories de vérification (domaine, comportement, cinématique, connexion, normes), le domaine de valeur CORECT (conforme, ordre, "range", existence, cardinalité, temps) et on donne des exemples d'éléments à considérer.

 

Exemple d'essais unitaires. La quatrième capsule "Exemple d'essais unitaires" (8 min) montre comment tester unitairement un écran dans un contexte progiciel en appliquant les leçons de la capsule précédente.

 

Comment automatiser les essais unitaires? "Essais unitaires automatisés" (11 min) explique comment automatiser une partie des essais unitaires présentés dans la capsule précédente. On montre l'utilisation de xUnit. Comment découper et nommer les tests. On présente l'organisation "Arrange, Act, Assert" pour construire une test. Finalement, on aborde la mesure de la couverture des essais à l'aide de Cobertura.

 

Quels sont les caractéristiques de bons essais unitaires automatisés? La capsule suivante, "Caractéristiques des essais automatisés" (5 min) présente l'importance de la rapidité, de l'indépendance, du déterminisme, de la non-ambigüité des tests  et du meilleur moment pour les rédiger.

 

Comment partir de spécifications claires? La dernière capsule, intitulée "Spécifications exécutables" (5 min), montre un exemple de spécifications exécutable, de dossier fonctionnel, dans le contexte de l'écran utilisé dans les capsules précédentes. On utilise le framework "Concordion".

10:19 Publié dans Agile, Grails, Scrum | Lien permanent | Commentaires (0)

Roo ou Grails, Roo et Grails

2012-08-31 La semaine dernière, je me suis lancé dans l'exploration de SpringSource Roo afin de le comparer à Grails, aussi de SpringSource, afin de mieux pouvoir conseiller notre organisation.

Divulgation d'intérêt : j'utilise Grails depuis plus de trois ans et mon exploration de Roo se limite à seulement quelques jours. J'ai une préoccupation constante pour livrer des solutions et optimiser la productivité de l'ensemble des équipes impliquées tout au long du cycle de vie de l'application. J'ai fait la promotion de Grails au sein de l'entreprise avec un résultat d'adoption quasi nul (on va voir pourquoi).

Contexte. Depuis deux ans nous utilisons le framework Spring/Hibernate dans nos développements Java avec un certain succès et nous avons débuté l'adoption du TDD. Comme la plupart des développeurs Java, nous constatons que la productivité par rapport à d'autres technologies, notamment .NET, pourrait bénéficier d'un coup de pouce. Attention, la productivité est influencée par de nombreux facteurs. L'objectif ici, est de voir comment nos développeurs, notamment nos développeurs Java, peuvent devenir plus productif. Implicitement, la solution doit rouler dans un environnement Java. Actuellement, nous considérons deux voies : Roo et Grails.

Similarités

Principes. Après exploration, je constate que Roo et Grails partagent plusieurs similarités. Les deux visent l'augmentation de la productivité des développeurs Java, autour de Spring et Hibernate. Les deux sont bien intégrés dans Eclipse (Spring Tool Suite). Il faut souligner l'excellent shell de Roo qui facilite l'utilisation des commandes et qui est supérieur à celui de Grails (un avantage pour l'apprentissage). Grails et Roo misent aussi sur le même concept de "convention over configuration" introduit par Ruby on Rails et qui permet de réduire le travail.

Approche technique. Roo génère du code java (donc, compile time) alors que Grails injecte du code Groovy au run time. Dans ce contexte, Roo à l'avantage de donner au développeur du code statique qu'il peut examiner et compiler. Dans le cas de Grails, comme la magie se passe au run time, il faut plus faire confiance au code. Le code générique qui est injecté par Grails peut aussi être consulté (dans les sources de Grails) mais j'en au rarement vu l'intérêt. Du point de vue du développeur, Grails apparaît plus "magique", mais il faut le voir plutôt comme un niveau plus élevé d'abstraction.

L'approche de Roo génère un war plus petit et requiert moins de dépendances que Grails. Il procure aussi un avantage du côté des performances, bien que pour des applications de gestion normales, je ne pense pas que ce soit un avantage significatif. Si la performance est un enjeu, les deux approches devront faire l'objet d'une attention particulière de toute façon.

Il est important de mentionner qu’autant Grails que Roo capitalisent sur Spring et Hibernate.

Architecture logicielle. J'ai été agréablement surpris de constater que Roo misait sur la même base que Grails. Les "entity" Roo sont presque identiques aux objets "domain" de Grails. Les annotations de Roo pour les "fields" correspondent directement aux "constraints" de Grails. Il en va de même pour le traitement des relations entre les entités où on a simplement à déclarer un "field" du type d'une entité pour établir la relation, comme dans Grails. Même support pour les relations n:m. Comme Grails, Roo génère le squelette des tests unitaires. Les deux génèrent les contrôleurs et les vues. On retrouve dans Roo l'utilisation du "scaffolding", comme dans Grails.

Note: L'apprentissage de Roo se limite essentiellement à quelques concepts dans la façon de réaliser une application Spring/Hibernate. Grails requiert l'apprentissage de ces mêmes concepts, mais aussi une variante du langage Java (Groovy) et de nombreux plugins (ce qui explique le niveau d'adoption).

Donc, comme j'aime Grails et que Roo va dans la même direction, j'aime Roo. Au point où, si je ne pouvais utiliser Grails et que je devais réaliser une application Java, ce serait mon approche de développement privilégiée.

Expérience "out of the box".Construire une application hypersimple, pour une démonstration par exemple, montre que Grails requiert moins de travail et de lignes de code que Roo. L'application Grails est aussi plus riche fonctionnellement que celle produite par Roo. Par exemple, les listes peuvent être triées dans les écrans Grails, mais pas dans ceux de Roo. Le cycle de modification-compilation-exécution est aussi plus rapide dans Grails.

Le nombre de commandes Roo, et donc, dans l'excellent Roo shell est plus limité que celui de Grails.

Plugins. Là où la différence se fait sentir, c'est sur le nombre de "plugins". Actuellement, pour Roo, il n'y en a que quatre (4). Pour Grails, ce nombre est de 830… c'est 200 fois plus!

Cette différence fait que Grails apporte l'intégration de beaucoup de fonctionnalités à peu de frais. Ces plugins, de qualité inégale, il faut le dire, apportent autant des fonctionnalités à l'application qu'au développeur (par exemple pour faire du BDD Behavior Driven Development).

Maturité et apprentissage. Le nombre de commandes, l'envergure des fonctionnalités out-of-the-box et le nombre de plugins découlent directement de la maturité de Grails par rapport à Roo. Grails existe depuis plus longtemps que Roo et est inspiré (et similaire) à Ruby on Rails, lui-même encore plus mature. Il va sans dire que le nombre de ressources (articles, livres, revues, conférences, sites web, communautés…) est largement plus grand autour de Grails que de Roo. Cependant, Roo n'est pas un framework au même titre que Grails. Il faut le voir comme une couche structurante au dessus de Spring/Hibernate. Une couche nécessairement plus mince. Ceci permet de profiter du grand nombre de développeurs Java disponible sur le marché, qui connaissent déjà Spring et Hibernate.

Comparatif

Productivité à maturité :           Grails             >>>            Roo            >             dév. "à la main"

Courbe d'apprentissage :         Grails             >>>            Roo            >             dév. "à la main"

Conclusion. Plusieurs articles sur internet spéculent sur le fait que SpringSource aurait introduit Roo comme "stepping stone", comme une étape intermédiaire, vers l'adoption de Grails. Mon exploration me pousse dans la même direction. Roo est une excellente façon de migrer vers plus de productivité pour un développeur Java d'expérience puisque Roo mécanise une partie de son travail et introduit une architecture logicielle plus moderne.

En se sens Roo me semble une avenue d'amélioration importante pour les équipes Java (spring/hibernate) mature. Grails offre pour le moment, une bien plus grande productivité, mais aux coûts d'un apprentissage beaucoup plus important. Grails représente une cible long terme pour les équipes matures et une cible court terme pour des personnes ayant moins d'expérience en développement et donc moins d'acquis, dans la mesure où on supporte ces développeurs adéquatement.

Donc , selon moi , il ne faut pas parler de Grails ou Roo, mais de Grails et Roo.

 

08:21 Publié dans Grails | Lien permanent | Commentaires (1)

06 août 2012

Capsules vidéos sur les essais unitaires

Je viens de terminer une série de courtes capsules d'information sur les essais unitaires dont l'objectif est d'expliquer ce qu'il sont, comment les faires et aborder leur automatisation. Au total, l'écoute des sept capsules prend environ 45 minutes.

 

Que sont les essais unitaires? La première capsule "Les niveaux d'essais" (5 minutes) situe les essais unitaires par rapport aux deux autres grands niveaux d'essais que sont les essais d'intégration et d'acceptation.

 

Comment aborder les essais unitaires? La seconde capsule "Stratégie d'essais unitaires" (2 min) insiste sur l'importance de la réflexion préalable sur ce que seront les essais unitaires dans un projet donné.

 

Quoi tester en essais unitaires? Ensuite, on aborde dans "La nature des essais unitaires" (7 min)les diverses catégories de vérification (domaine, comportement, cinématique, connexion, normes), le domaine de valeur CORECT (conforme, ordre, "range", existence, cardinalité, temps) et on donne des exemples d'éléments à considérer.

 

Exemple d'essais unitaires. La quatrième capsule "Exemple d'essais unitaires" (8 min) montre comment tester unitairement un écran dans un contexte progiciel en appliquant les leçons de la capsule précédente.

 

Comment automatiser les essais unitaires? "Essais unitaires automatisés" (11 min) explique comment automatiser une partie des essais unitaires présentés dans la capsule précédente. On montre l'utilisation de xUnit. Comment découper et nommer les tests. On présente l'organisation "Arrange, Act, Assert" pour construire une test. Finalement, on aborde la mesure de la couverture des essais à l'aide de Cobertura.

 

Quels sont les caractéristiques de bons essais unitaires automatisés? La capsule suivante, "Caractéristiques des essais automatisés" (5 min) présente l'importance de la rapidité, de l'indépendance, du déterminisme, de la non-ambigüité des tests  et du meilleur moment pour les rédiger.

 

Comment partir de spécifications claires? La dernière capsule, intitulée "Spécifications exécutables" (5 min), montre un exemple de spécifications exécutable, de dossier fonctionnel, dans le contexte de l'écran utilisé dans les capsules précédentes. On utilise le framework "Concordion".