Conférence dotScale

Salut les Poires!

Bon alors un petit post sur la conférence à laquelle j'ai assisté vendredi 7 juin à Paris.

Les dotConferences sont des conférences du style TEDTalks mais très orientées développement avec à chaque fois un thème particulier et dont le prix reste raisonable. Il y en a par exemple sur le JavaScript ou encore le Ruby. Cette fois cela portait sur les architectures distribuées et les applications dans les nuages °o° !!

Il y avait des intervenants assez incroyables comme par exemple le créateur de Apache Hadoop (il existe réellement sous forme humaine si si, mais il avait la voix cassée....), l'un des fondateurs du projet OpenStack (qui était nommé "Pinet" au départ, mais bon ça ne sera pas la première ni la dernière fois qu'un papa un peu saoul se trompera de nom en allant déclarer son bébé à la préfecture, car oui selon lui la culture des gens d'OpenStack repose sur l'alcool...), le CEO d'Heroku et plein d'autres...

La conférence s'est déroulée au Théâtre des Variétés dans le 1er arrondissement, autant dire que c'était un cadre parfait, mais sans plus attendre voici un petit résumé de ce qui a été dit au cours de cette conférence :

Intervention 1 : Quentin Adam (Clever Cloud) → une startup nantaise ^^

Lignes de conduite pour le développement d'applications distribuées et réparties

→ Scale out vs scale in (ou comment augmenter la qualité de service en répartissant son application sur une architecture distribuée comportant de nombreux serveurs de performances correctes, plutôt que de la faire fonctionner sur un faible nombre de nœuds ayant de hautes performances)

• Stateless is the key
• Split data and processes : il faut séparer en des couches bien distinctes le code qui accède au données de celui qui réalise des traitements et des calculs sur ces données.
  
• The choice of database requirements is linked to the type of data : chaque système de gestion de base de données présente des caractéristiques qui lui sont propres et qui font qu'il sera plus à même de gérer un type de données bien précis. Pourquoi utiliser un système de gestion base de données relationnel si l'on ne souhaite stocker qu'un ensemble de clés-valeurs? Il faut choisir un système de gestion de bases de données correspondant bien au type de données que l'on souhaite stocker.
  
• The choice of technology must be related to needs and requirements : il faut choisir la technologie que l'on utilisera en fonction de ce que l'on veut réaliser et pas l'inverse. Pourquoi utiliser tel langage de programmation si un autre permet de réaliser la même chose plus simplement ou plus rapidement?
  
• Avoid data storage in RAM : la mémoire vive n'a jamais été faite pour pérenniser des données, on peut lire ou écrire rapidement des données en mémoire RAM certes, mais il s'agit d'une mauvaise pratique. A la rigueur, il vaut mieux utiliser la RAM comme cache pour les accès rapides.
  
• Code will fail : lorsque l'on code, toujours penser que des erreurs apparaîtront, aucun code n'est sûr, il faut donc être certain de pouvoir réparer les éventuels bugs et de pouvoir rétablir le système le plus rapidement possible.
  
• Never store data in the file system
• Be careful with frameworks (only use them when you know exactly what they do) : il faut faire attention à l'utilisation de frameworks, il est possible de les utiliser seulement si l'on sait ce qu'il exactement, sinon il vaut mieux coder les choses soi-même.
  
• Split code in modules : autrement dit diviser pour mieux régner. Un programme dont le code est réparti en différents modules et bien structuré sera plus agréable à lire, plus simple à réparer et plus facile à modifier.
  
• Choose a good Event Broker (avoid Cron)
• Don't make hard and complex asynchronous code : le code asynchrone trop complexe est très difficile à comprendre pour l'homme, il est donc difficile à maintenir et présente une forte probabilité d'échouer.
  
• Put a proxy in front of the Application : en ajoutant un proxy devant l'application web il sera plus simple de gérer les accès au site.
  
  

Intervention 2 : Thomas Stocking (Gandi.net)

Challenge of large scale multi-tenancy, une problématique rencontrée au sein des infrastructures de Gandi.net.

VNT : Virtual Network over TRILL

TRILL : offers the best of Layer 2 and 3

The VNT solves the problem of VLAN exhaustion (limited to 4096 hosts).

Le projet deviendra Open Source d'ici peu.

Intervention 3 : Noah Zoschke (Heroku)

Architecture of Heroku PaaS (Platform as a Service)

6. Heroku LXC Container

5. Ubuntu and cgroups (pour fournir des espaces de ressources aux utilisateurs)

4. Xen hypervisor

3. Amazon Linux – paravirtual API

2. Intel CPU (instruction set)

1. Physics (matter, time, space)

Pourquoi cette architecture :

• Complexité
• Performances
• Possibilités de configuration
• Visibilité

Mais en contre partie des problématiques de :

• Efficacité de mise en œuvre
• Sécurité
• Expressivité
  
  

Intervention 4 : Jonathan Weiss (Scalarium, Amazon Web Services OpsWork)

Things will break → embrace and plan for failure : en développement rien n'est sûr à 100%, il faut toujours s'attendre à ce que les choses plantent et tout mettre en œuvre pour limiter les dégats.

Divide and Conquer : en séparant les choses, il est plus simple de les maîtriser.

Limit the blast radius → Isolate and compartmentalize : en isolant les composants, les dégâts sont souvent limités en cas de problème.

Automate and practice hard things : en automatisant et mettant en pratique régulièrement les tâches complexes, il est plus simple de mettre ces mécanisme en action en cas de crise.

Replace your fleet all the time : en changeant régulièrement l'ensemble des VM sur lesquelles est hébergée l'application, il sera plus simple de déployer l'application de manière efficace au fur et à mesure.

Backup and restore all the time : le processus de restauration du système sera efficace

→ Until tough things are easy : à terme, les choses difficiles deviendront simples et faciles à mettre en place.

→ Think about the crazy monkey : l'image du singe fou détruisant tout parce qu'il fait n'importe quoi est à garder à l'esprit pour envisager le pire des cas et donc mettre en place des barrières et solutions de secours.

→ Monitoring and measuring as a basis : la supervision est à la base de cette démarche, elle permet de savoir comment l'application fonctionne, comment elle est utilisée, quelles sont ses faiblesses et quels sont les choses à améliorer.

→ Auto Scaling : l'objectif final étant de disposer d'une application auto-scalable, où il suffit d'ajouter des noeuds pour que l'application supporte une plus grosse charge de travail.

Intervention 5 : Mandy Waite (Google)

Ça c'est pour Aurélien!

Device Cloud (ensemble d'appareils de mesure et de sondes distribué)

Exposé sur la mise en place de très nombreux systèmes munis de capteurs (température, son, qualité de l'air...) dans les bâtiments accueillant le Google I/O lors des jours de l'évènement. Les cellules de mesure sont réalisé grâce à des systèmes Arduino munis de capteurs et connectés grâce à un protocole de communication sans fil spécifique permettant d'utiliser une très large gamme de fréquences pour éviter les interférences.

L'acquisition des données et les opérations et traitements qu'elles ont subit ont été réalisées en utilisant les technologies de Google :

• App Engine pour l'hébergement de l'application
• Data storage : pour le stockage des données
• BigQuery pour effectuer les requêtes vers ces données
• Compute engine pour effectuer les calculs complexes

En cadeau le lien vers le code source et les résultats de l'expérience : data-sensing-lab.appspot.com

Ouvrage utilisé pour faire l'expérience : Building Wireless Sensor Networks

Intervention 6 : Salomon Hykes (dotCloud, Docker)

Docker : the portable container engine → très (trop?) prometteur, en tout cas mon coup de coeur de la conférence

What is it?

La problématique à laquelle veut répondre Docker est de transférer une application d'une machine A vers une machine B automatiquement et de manière fiable.

Conteneurs existants :

• jar, rvm, virtualenv → pas toujours compatible avec tous les systèmes
• machines virtuelles → trop lourdes, trop de composants, trop lent

Docker → the best of both worlds :

• complete sandbox
• works with all languages and dev tools

Docker a pour ambition de s'imposer comme un format standard de conteneur et le projet est open source.

Les développeurs construiront des conteneurs et ces conteneurs seront ensuite déployés sur l'infrastructure directement. 

 

Flash Talk : Tugdual (CouchBase) → il vient de Nantes

Explication et analyse de la chute de OMGPOP.

Intervention 7 : Shay Benman (ElasticSearch)

Valorisation des données (Data Zen) -> là je digérais mon repas, donc je n'ai pas noté grand chose...

Intervention 8 : Brad Fitzpatrick (memcached, OpenId, LiveJournal)

Travaille aujourd'hui pour Google.

Développement en Go! (langage de Google).

A présenté :

Chubby lock service (Distributed Lock Manager) : est utilisé pour gérer les accès concurrents à des ressources partagées. Le système sert également comme serveur de nommage chez Google, devant DNS.

Doozer : système de stockage de haute accessibilité pour les données de haute importance.

Bitcoin : nouveau système de monnaie électronique internationale

Camlistore.org : un projet de système permettant de stocker, synchroniser et partager du contenu. 

 

Intervention 9 : Barry Abrahamson (WordPress)

Présentation des mauvaises expériences techniques de WordPress face à l'augmentation rapide du nombre d'utilisateurs.

Par exemple trop d'utilisateurs, trop de tables relationnelles de données, trop de fichiers → changement du moteur de gestion (MyIsam → InnoDB).

Introduction de HyperDB, Static Asking, Dynamic Assignment...

Conclusion : Lors du lancement d'un projet ambitieux, il est impossible de définir parfaitement l'architecture d'une application et de faire les bons choix technologiques. Il faut certes, créer une base cohérente et qui répond aux besoins mais il y a aura toujours des imprévus qui apparaîtront et ce n'est que lorsqu'on les rencontre qu'il faut prendre les bonnes décisions.

Intervention 10 : Doug Cutting (Hadoop, Apache foundation)

Présentation des projets open source de la fondation Apache réalisés en partant des résultats de recherche ou des projets propriétaires de Google.

Hadoop MapReduce et Hbase après Google MapReduce et BigTable par exemple.

Nutch : moteur de recherche open source

Hive et Pig.

Intervention 11 : Joshua McKentie (OpenStack)

Conway's law : "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations". Pour que deux modules d'un programme implémentés par deux programmeurs ou groupes de programmeurs distincts s'interfacent correctement, il faut que les deux programmeurs ou groupes de programmeurs communiquent correctement. Autrement dit, l'interfaçage entre deux module d'un code reflète la qualité de la communication entre les personnes ayant produit ce code.

Présentation d'une théorie sur la qualité des logiciels open source.

La qualité d'un code open source repose sur la communauté et la qualité de la communauté repose sur la culture commune au groupe.

L'authenticité d'un projet lui permet de se développer et de réunir une communauté.

Les noms des projets ont un impact sur le développement d'un projet. OpenStack était nommé Pinet au départ pour Python Network... les créateurs ont commencé à discuter du projet dans un bar.

Le plus important est de pouvoir déployer et mettre en place le produit à terme.

Ensuite, le mec a terminé la présentation par un petit spectacle de jonglage...

Bonne nouvelle! les photos et vidéos de la conférence seront bientôt accessibles depuis le site web de l'événement.

Les diaporamas des présentations seront normalement disponibles sous peu sur ce site.

Voili Voilou, bonne nuit les petites poires...

Ne pas perdre l'adresse IP de sa maison

Un truc que j'adore faire avec mon raspberry pi, c'est pouvoir me connecter en ssh depuis l'extérieur. Avoir un petit serveur comme ça chez soi, c'est très pratique pour héberger ses données, avoir son petit dépot git à soi, monter son propre serveur... Il suffit de connaitre son adresse IP (et d'avoir une redirection de port sur son routeur) et c'est parti. Le soucis, c'est si vous avez une adresse IP dynamique. En pratique, bien sûr l'adresse change très rarement, mais il suffit d'une coupure de courant pendant que vous êtes à l'autre bout de la France et vous perdez contact avec votre chez vous. Alors si vous êtes un peu parano comme moi, vous aimeriez bien que votre maison vous dise quand l'ip a changé.

Je partage donc un petit script que j'ai réalisé en python 3. Il vérifie que l'adresse IP n'a pas changé depuis sa dernière exécution en comparant avec un fichier contenant l'adresse. Si l'adresse a été modifiée, il enregistre la nouvelle adresse et envoie un mail. Le script nécessite d'avoir accès à un serveur smtp (ici par défaut celui de google). Les explications sont plus bas.

Paramétrage

Les paramètres sont à changer dans la fonction main. On a notamment l'adresse qui va envoyer le mail, l'adresse qui va recevoir le mail, le serveur smtp et enfin le mot de passe. Personnellement je n'aime pas mettre mon mot de passe en clair dans un script donc le script utilise un mot de passe chiffré avec la méthode de Vigenère. Le script nécessite donc également la clé (une chaine de caractère) qui a été utilisée pour chiffrer le mot de passe.

Pour générer le mot de passe chiffré il faut utiliser la fonction vigenere fournie dans le script. En console dans le dossier contenant le script (et en supposant qu'il s'appelle ipcheck.py) :

$python3
>>>import ipcheck
>>>ipcheck.vigenere(maclef, monpassword)

Ce qui vous donne le mot de passe chiffré correspondant à mettre dans la variable password du script.

Attention : Étant donné que le script contient à la fois la clé et le mot de passe, le chiffrement de la clé n'est absolument pas sécurisé. Le chiffrement permet ici uniquement à ce que quelqu'un qui voit votre fichier vite fait dans votre dos ne connaisse pas votre mot de passe. A titre personnel, j'ai une adresse mail séparée spécialement pour mon Raspberry pi. Comme ça, même si quelqu'un récupère le mot de passe pour cette adresse, il ne pourra pas en faire grand chose.

Un coup de cron et en avant

Une fois le script configuré, il nous reste juste à demander l'exécution régulière du script. Pour ça, dans la ligne de commande (les éventuelles personnes sous windows pourront jouer avec les tâches planifiées)  :

$crontab -e
Votre éditeur préféré s'ouvre et vous pouvez ajouter la ligne :
0 * * * * /chemin/vers/le/script

En clair, cela veut dire : exécuter le script à chaque fois qu'il est x h 0 min, soit toutes les heures. Vous pouvez adapter en fonction de vos besoins pour le faire tourner plus ou moins souvent. On sauvegarde et c'est fini.

Voilà, j'espère que ce script trouvera son utilité auprès de certains. Au pire, il est toujours là pour moi si jamais je venais à perdre mon ordinateur. N'hésitez pas à demander des précisions ou faire des remarques (constructives, cela va sans dire :-) ).

 crédits photo : Keith Weller, United State Department of Agriculture

mongodb sur raspberry pi

Ça y est ! J'ai réussi. Il m'aura fallu une semaine d'essais divers mais j'y suis arrivé. Faire tourner habitrpg sur mon raspberry pi, petit défi que je m'était lancé en découvrant cette todolist plutôt originale. Dans les faits, ça ne semble pas si compliqué puisque d'après le dépôt github, il suffit de mongodb et node.js pour faire tourner l'application. C'est là que les choses se compliquent...

J'ai utilisé pour mon expérience un Raspberry Pi 256 Mo avec un archlinux ARM (histoire de changer de debian). Le principal soucis a été de réussir à faire tourner mongodb, d'où ce billet. Vous trouverez probablement d'autres billets parlant du sujet (voir les références plus bas) mais aucun n'ayant fonctionné pour moi.

MongoDB

ou comment compiler pendant 3 jours

J'imaginais au début que je pouvais me contenter d'aller sur le site de mongodb et télécharger les binaires tranquilou. Idée plutôt naïve de ma part, digne d'une poire en fait. Ne comptez pas trouver de version compatible avec votre framboise préférée de cette manière, et ce pour une raison simple et logique. MongoDB est avant toute chose fait pour tourner sur une machine, puissante d'une part et multi-coeurs d'autre part. Autant dire que le processeur ARM monocoeur à 700 MHz ne remplit pas exactement la description.

Les petits malins auront remarqué que sur Archlinux ARM, un version de mongodb est présente dans les dépots. Sauf que cette version plante au démarrage chez moi (et chez un certain nombre de gens). Reste une solution... compiler soi même mongodb dans une version compatible ARM.

Avant toute chose, sachez que la maigre mémoire d'un raspberry 256Mo ne lui permettra pas de compiler sans swap. J'ai donc créé un fichier de swap de 500 Mo en suivant le wiki d'archlinux. Je conseille fortement d'avoir une carte SD d'au moins 16 Go (j'ai une 32 pour ma part en ce moment).

J'ai pas mal trainé sur la toile avant de trouver une méthode qui marche. Il y a plusieurs recettes avec notamment 2 dépots github qui ressortent ( https://github.com/RickP/mongopi et https://github.com/skrabban/mongo-nonx86). C'est au final un mélange de différentes méthodes que je vais décrire ici vues sur certains blogs qui a fonctionné pour moi.

compilons !

J'ai pris comme base le dépot mongo-nonx86 :

git clone git://github.com/skrabban/mongo-nonx86.git
cd mongo-nonx86

Ensuite une bidouille pour régler un problème dû à la bibliothèque boost. Pour résumer (et d'après ce que j'en ai compris) cette (excellente) bibliothèque C++, dans la version utilisée dans le dépot, déclare une macro qui entre en collision avec une autre macro définie dans la version actuelle de la bibliothèque standard. Du coup, on va juste en changer le nom ainsi que toutes ses références.

Bref, un coup de script pour changer renommer les occurences de cette macro et le tour est joué.

for i in `grep -lr TIME_UTC`; do
sed -i s/TIME_UTC/TIME_UTC_/ $i;
done

La compilation nécessite le programme scons présent dans les dépots (pacman -S scons ou apt-get install scons selon votre gestionnaire de paquet). Comptez plusieurs heures (je dirais 4 heures pour la première compil et 3 pour la seconde) avant d'installer tout ça. Personnellement je m'envoyais un mail à la fin des compilations pour savoir que c'était terminé.

scons all
sudo scons --prefix=/opt/mongo install

Remplacez /opt/mongo par l'endroit où vous voulez installer mongodb. Ensuite histoire d'avoir un truc propre, on peut ajouter quelques lignes à la fin du fichier /etc/profile histoire d'avoir mongodb dans le path :

PATH=$PATH:/opt/mongo/bin
export PATH 

Comme ça il sera possible de lancer mongodb juste en tapant mongod dans la console.

références :

Un long billet parlant de l'installation d'une base mongodb sur plusieurs raspberry pi, de l'installation du système à la mise en réseau des raspis. : 

http://mongopi.wordpress.com/2012/11/25/installation/

Deux billets parlant du sujet et expliquant les différents obstacles à la compilation :

http://www.timandpaige.com/technology/installing-mongodb-on-the-raspberry-pi-part-1-introduction

http://www.timandpaige.com/technology/installing-mongodb-on-the-raspberry-pi-part-2

Pour finir

Pour ceux qui serait intéressés par installer habitrpg, il vous reste à installer Node.js. Pas de problème particuliers dans la mesure où il est présent dans les dépots. Pour la petite histoire, ça me donnait une 404 quand j'essayais de le télécharger, en conséquence de quoi j'ai également recompilé node.js sans trop de problèmes. Normalement nous avons tout ce dont nous avons besoin pour faire tourner habitrpg. J'ai suivi les instructions de cette page. Pensez bien à mettre l'option --recursive lorsque vous clonez le dépot git car ce dernier référence lui même d'autres dépots github.

Cependant, ne vous attendez pas à des miracles : la génération de page est extrêmement lente (je suppose que l'application revérifie tous les fichiers de l'arborescence à la requête, d'où la lenteur). Par contre, une fois la page affichée, la communication entre le navigateur et le serveur se fait par des websockets donc pas de soucis de lenteur (je crois qu'on aime bien les websockets chez pear programming).

Configurer mspgcc pour code::blocks

J'imagine qu'un titre pareil vous met l'eau à la bouche. Le but de ce billet est à la base de partager comment j'ai tenté d'intégrer au mieux le compilateur mspgcc dans Code::Blocks pour utiliser mon TI launchpad (j'en ai perdu la moitié là non ?). L'objectif est double : d'une part, faire découvrir une plate-forme d'initiation à l'embarqué (monde dans lequel je mets récemment les pieds), et d'autre part montrer comment on peut paramétrer l'IDE Code::Blocks afin d'intégrer au mieux différents outils. En fait, je pense que la partie Code::Blocks peut être intéressante pour les personnes cherchant à prendre en main cet IDE, même sans travailler sur des technos embarquées. Avant toute chose, je précise que je n'ai rien d'un expert dans le domaine, je suis même plutôt l'inverse. L'idée est simplement de partager mes récentes découvertes conformément à la philosophie du blog.

Pour ceux qui connaissent déjà le compilateur mspgcc, vous pouvez aller directement à la fin pour voir ma configuration. Pour les autres, je vais profiter de ce billet pour présenter vite fait le TI launchpad et peut être vous donner envie de vous mettre à l'embarqué.

Le TI launchpad pour les poires

Pour faire simple, le TI launchpad est une petite plate-forme d'expérimentation sur les circuits intégrés de Texas Instrument (de la gamme M430G2xx pour dire des gros mots). J'ai découvert cette petite bête dans un linux magazine hors série dédié à l'embarqué. Si vous êtes intéressé par le sujet et que vous êtes néophyte, jetez y un coup d'oeil. La mise en route de l'engin y est plutôt bien décrite.

L'intérêt de ce genre de produit c'est qu'il permet de s'initier pour peu de frais à la programmation sur des micro-contrôleurs. La plate-forme ne coûte que 5 euros (prévoyez tout de même d'avoir également un fer sous la main pour souder le quartz fourni avec le Launchpad). Les circuits inclus dans le Launchpad sont relativement peu puissants mais ils contiennent ce qu'il faut pour aborder un certain nombre de concepts inhérents à l'embarqué comme les watchdogs, les timers et autres réjouissances.

Ça change quoi de coder là dessus ?

Le TI Launchpad

Déjà, désolé pour les javateux, mais il va falloir se mettre au C pour ce genre de machine. Et pour cause, la programmation sur systèmes embarqués a pour caractéristique de cibler des circuits peu consommateurs en énergie et disposant de ressources limitées. En l'occurence, le circuit intégré le plus puissant inclus dans le TI launchpad (le MSP430G2553, Maurice de son prénom) dispose de  512 octets (!) de RAM. Il s'agit au passage de la version 1.5 du launchpad, la version 1.4 est fournie avec un autre circuit moins puissant. Le code C est compilé grâce à un compilateur propre à la plate forme. En l'occurence, je vais parler ici de mspgcc.

Les outils

le dernier logo de C::B envoie du lourd

Je vais ici parler de Code::Blocks, mais rapidement vu que ce n'est pas vraiment l'objet de ce billet. Pour ceux qui ne connaissent pas, il s'agit d'un IDE libre pour coder en C/C++. Je le trouve relativement simple, peut être un peu trop diront certains, mais il se révèle plutôt souple dans sa configuration en fouillant un minimum. On peut notamment bien paramétrer ses compilateurs et en plus, il en supporte un certain nombre de base, dont notamment celui qui nous intéresse, mspgcc ! Cependant, ça ne compile pas pour autant sans erreur en un clin d'oeil, d'où l'idée de ce billet. Je vous conseille fortement si vous souhaitez l'utiliser de prendre les nightly builds (les dernières versions même pas encore release). Pourquoi ? Parce que les releases de Code::Blocks ont lieu... quand elles ont lieu, au bon vouloir des développeurs, ce qui fait qu'avant la dernière release (toute récente d'ailleurs), C::B était relativement limité.

Le reste des  outils se compose d'un compilateur pour pouvoir cross compiler et d'un debugger, ainsi que diverses librairies concernant notre modèle de circuit intégré. Pour les distributions linux type debian, les outils de compilation sont déjà dans les dépôts. Un petit apt-get devrait suffire pour avoir tout ce qu'il faut pour compiler :

sudo apt-get install gcc-msp430 binutils-msp430 msp430-libc msp430mcu mspdebug gdb-msp430 build-essential 

Bref, revenons à nos moutons.

Et mon Code::Blocks dans tout ça

La configuration que je vais montrer n'a rien de bien compliquée. Il s'agit plus de quelques astuces toutes bêtes mais qui permettent de mieux intégrer notre environnement de développement dans l'IDE (ce qui est le principe d'un IDE après tout :) ).

Configurer le compilateur

Dans le menu Settings -> Compiler :

1. Sélectionner le compilateur GNU GCC for MSP430.
2. Sélectionner l'onglet Toolchain executables.
3. Modifier le répertoire d'installation du compilateur : pour moi /usr (par défaut il est à /usr/local/msp430). Le bouton auto-detect est votre ami.
4. Pour le linker, mettre msp430-gcc à la place du compilateur C++.
5. Vous pouvez en profiter pour modifier les compilers flags dans l'onglet Compiler settings : personnellement je coche warning (-Wall) et optimisation (-Os).

Configurer son projet

Je propose ici de créer un projet type. Pour cela, on part d'un bête projet console avec le compilateur msp430 ne contenant quasiment rien, éventuellement un fichier .c avec un code minimum (personnellement j'ai juste mis un programme qui fait clignoter les LEDs du launchpad).

Tout se passe dans les propriétés du projet. Je présente ici comment configurer tout ça sans faire de makefile personnalisé.

1. Dans  C/C++ parser option, rajouter le dossier d'include : dans mon cas /usr/msp430/include
2. Dans build target, mettre Type a Native 

Ensuite dans les Project build options (accessibles depuis les paramètres du projet ou directement avec clic droit sur le projet). On paramètre ici le compilateur avec des caractéristiques propres à notre projet qui va se rajouter à la configuration générale faite précédemment.

1. Dans Compiler settings -> Other option, rajouter le modèle de la puce avec l'option mmcu. Dans mon cas ça donne -mmcu=msp430g2553.



une belle compilation sans douleur avec mspgcc

2. De même dans Linker settings, rajouter l'option mmcu dans Other linker options.

Et pour terminer en beauté, cliquer sur File -> save project as template. Comme ça pas besoin de refaire toutes les manip à chaque fois ! Vous pouvez créer un projet identique depuis ce template quand vous voulez.

Le petit bonus de la fin

Tout ça c'est bien beau mais on peut toujours pas flasher notre puce pour envoyer notre programme dessus. La fonctionnalité que je vais présenter peut être utilisée de plein d'autres manières, et n'a rien à voir avec mspgcc finalement mais j'ai trouvé ça bien utile.

Aller dans le menu Tools -> Configure tools. En cliquant sur add, on arrive sur un menu tout bête qui permet de créer des commandes appelées directement depuis Code::Blocks.

Je vous laisse regarder ma configuration :

Grâce à ces quelques lignes, je peux aller dans Tools, et lancer l'upload du code directement depuis code blocks. Pas grand chose au final mais c'est le genre de détail qui permet d'intégrer au mieux les outils mspgcc dans C::B. 

Conclusion

J'ai bien conscience que ma configuration est probablement loin d'être optimale. Elle a cependant le mérite de marcher pour le (très) peu de fois où je l'ai utilisé. Si jamais un ami lecteur a une meilleure façon de faire je suis preneur. Dans tous les cas, n'hésitez pas à regarder un peu du côté du TI Launchpad ou autre plate-forme pour l'embarqué. Ça change du java habituel et ça permet de revenir aux sources du développement (notez le jeu de mot sur source :) ). Les commentaires sont bien entendus les bienvenus pour toute question qui vous viendrait à l'esprit (sur le billet ou sur les poires).

Mangez des poires

Il fallait bien commencer quelque part. Alors commençons.

Nous sommes 13, comme les doigts de la main. Quand nous étions petits, nous rêvions d'ordinateurs, de Java, de Spring, d'Android, de développement agile... et de poires. Nous songions à ce jour prochain où nous serions des experts reconnus et écoutés, des maîtres en informatique (un peu comme les maîtres jedi, mais en remplaçant la force par des bits et le sabre laser par un clavier). Mus par une même passion et un même élan, nous nous retrouvâmes tous dans notre chère école d'ingénieur, l'EMN. Cette époque bénie nous offrit moult cours sur des technologies diverses et variées. À force d'arpenter les salles de classe, le web et des disques durs, nos rêves commencèrent à prendre forme sous nos yeux. 

Hélas, rien ne dure éternellement et le destin allait cruellement nous séparer. L'école était finie, et cette fois pour de bon. Après un adieu plein d'émotion à notre vie étudiante, nous mîmes nos portables dans nos baluchons et partîmes aux quatre vents accomplir notre dernière quête d'étudiant, le stage de fin d'études. Nous n'étions plus des petits, nous pouvions entrer dans le monde, le vrai. Enfin, ça c'est ce que nous avait dit.

Pourtant, malgré tout le labeur fourni durant nos études, nous n'avons guère l'impression d'en savoir plus. Pire, à la lumière de notre enseignement, nous ne pouvons que constater à quel point l'informatique est un vaste domaine que nous avons à peine exploré (de même que pour les poires. Vous saviez qu'il y a une trentaine de variété de poire ? (source) ). Le chemin parcouru depuis nos rêves d'enfant avait beau être long, nous étions encore loin de pouvoir prétendre maîtriser quoi que ce soit : loin de monter sur nos grands chevaux, nous nous hissions laborieusement sur nos poneys.

Alors on nous aurait menti ? Nous ne sommes pas des grands finalement ?

Peut être pas... En fait, je ne sais pas si nous serons jamais grands. En attendant, nous continuons d'apprendre un peu plus tous les jours. Et c'est là qu'intervient pear programming. Ce blog nous permettra de partager nos trouvailles, nos difficultés, nos problèmes et solutions... un carnet de bord des explorateurs de l'informatique en quelque sorte. Une vraie aventure en perspective. Alors à bientôt pour de nouvelles péripéties !