Stage IUT & soutenance, conseils aux étudiants

Ce billet s'adresse plus spécifiquement aux étudiants GEII de l'IUT, mais peut éventuellement être utile à des étudiants dans d'autres situations. Je couvre ici l'aspect "valorisation" du stage, qui passe par une soutenance orale.

La soutenance est souvent déterminante dans la note finale. Qu'on le veuille ou non, nous vivons dans un monde de communication, et une prestation brillante peut parfois "sauver" un stage qui s'est mal déroulé. Attention, selon les grilles d'évaluation utilisées, ça ne fera pas des miracles, mais ca donnera au moins une image favorable au jury.

Objectifs généraux

La soutenance sert d'une part à montrer votre aptitude à rendre compte devant un auditoire du travail réalisé, d'autre part, à montrer au jury ce travail en en faisant une synthèse. L'objectif n'est pas d'expliquer au jury comment fonctionne telle ou telle technologie, mais de mettre en évidence la plus-value de votre stage. Il faut donc insister sur:

• A - la situation de départ (introduction, présentation du sujet, objectifs initiaux, contexte, ...),
• B - la situation à l'arrivée (en conclusion),
• comment vous êtes passé de A à B.

Ceci tout en prenant en compte le fait que votre auditoire ne connaît ni l'entreprise, ni éventuellement le domaine précis sur lequel vous avez travaillé. Il est très important de prendre du recul par rapport au sujet: montrer le contexte général, l'entreprise / le service, son domaine d'activité, le rôle de ce service par rapport à ses "clients" au sens large, quel était le besoin initial ou le sujet proposé par rapport à tout ca. Vous pourrez ensuite présenter quelques éléments de votre stage (missions réalisées, outils utilisés, difficultés rencontrées et comment vous les avez résolues, ...). Vous ne pourrez pas détailler toutes vos activités, et même si vous jugez que toutes vos missions méritent d'être exposées, vous devrez choisir un angle principal. Prenez l'avis de votre encadrant IUT ou industriel en cas de doute.

Vous pourrez vous attarder sur un point technique, mais sans chercher a être exhaustif: le jury ne s'intéresse pas tant au travail réalisé en lui-même que à la façon dont vous avez traité une situation donnée.

Outre le bilan sur le travail réalisé, la conclusion doit mettre en évidence l'intérêt pour l'entreprise: en quoi votre travail lui a été bénéfique ? Vous pourrez aussi y exposer votre appréciation personnelle sur ce stage, en restant positif. Vous pouvez par exemple expliquer que ce stage vous a permis de découvrir telle ou telle technologie, ou qu'il vous a permis de developper vos capacités relationnelles, ou autre.
Si votre stage s'est mal passé quelqu'en soit la raison, la présentation n'est pas le moment de régler des comptes ni même d'expliquer une situation confictuelle. Ceci pourra se faire lors de l'entretien ultérieur, si besoin.

Si votre stage n'a pas eu de sujet central, comme cela arrive parfois, vous devez alors trouver une autre articulation: montrer que vous vous êtes intéressé plus en détail à l'un des thèmes techniques abordés par l'entreprise et/ou le service dans lequel vous avez été accueilli. En dehors de la présentation de votre travail, vous devrez alors developper une partie qui fera une synthèse autour de ce thème. Parlez-en avec votre encadrant de l'IUT.

Durée de la présentation

Dans notre département, il est demandé une présentation de 15 min maximum. En réalité, il s'agit d'une barrière haute, et à titre personnel je demande plutôt aux étudiants de préparer une présentation de 11, 12, voire 13 mn, mais pas au delà. En pratique, et ayant pas mal l'habitude de ce genre d'exercice, il vaut mieux une présentation courte mais (très) bien préparée, plutôt que quelque chose de soporifique. De toute façon, le jury reviendra lors de la phase des questions sur les points clés.

L'oral est également important. Une articulation claire et fluide, des phrases bien construites qui sortent sans peine, et vous avez gagné un point. Les étudiants sont inégalement doués sur ce terrain, et certains devront particulièrement travailler ce point, par de multiples répétitions.

Pour les diapos: quelques règles

Sur la forme, et encore plus que pour le rapport, la sobriété est payante. Les effets multicolores et autres animations de transition sont souvent du plus mauvais goût. Ils peuvent donner l'impression que vous essayer d'impressionner le jury par votre maîtrise des dernières fonctionnalités de Powerpoint version 12345, alors qu'en réalité, celui-ci pensera que vous cherchez à compenser la légèreté du fond. Mais ceci n'interdit pas d'illustrer ses diapos par des figures, au contraire. Des pages associant texte et illustrations permettent souvent de mieux faire comprendre un concept, et montrent souvent que le candidat a réflechi au message à faire passer. Je vois trop souvent des diapos avec un titre, une liste à puce de 3 items, et c'est tout. Une, ça va, mais s'il y en a 10 comme ça, on a vite compris que l'étudiant a préparé ça assez rapidement...

Ne pas trop (sur)charger quand même, l'équilibre est difficile à trouver, dans le doute demander des conseils à des proches (non-techniciens de préférence).

Faire attention au contraste aussi: les conditions d'éclairement ne sont pas toujours optimales, et un texte jaune sur fond marron se lira alors difficilement. La taille des polices utilisées doit être choisie avec soin. Quand au choix des polices, de la sobriété toujours...

Le nombre de diapos: c'est assez variable, et fonction du contenu en fait. Il faut que le jury ait le temps de lire le contenu, en association avec vos commentaires. Disons qu'on compte en général 1 à 2 mn par diapo.

Un point que beaucoup d'étudiants oublient: la numérotation des pages, très importantes pour que jury et candidat puissent se repérer lors de la séance de questions.

Two scripts for packaging a source tree from a local repository

I'm currently maintaining a double build of some software projects, on both Windows and Linux. Svn is of course a great help, because it allows me to easily switch from one machine to another and finding my whole tree unchanged (with a network-hosted repository, of course). I could also use some virtual machine, but I happen to have enough machines available: my main laptop recently switched (more on this later!), and I still have Windows at work and at home. So it is kind of easier to work on separate machines, not to mention that virtual machines can have some specific trouble that you need to deal with, instead of focusing on your project.

Part of the job is letting the users try your code, users that don't necessarily have access to the svn repository, nor have/use the same dev tools you do. So the classical way is to upload somewhere the whole tree as a single archive, and let them fool around with the app.

A well-known post from Joel Spolsky (here in french) covers a list of what is required in dev teams to achieve a high quality level. And point n°2 is "Can you make a build in one step?". Besides the build process, this implies an efficient source tree release step, and that's what I'll talk about here. But what exactly does "release" mean ?

"Releasing" means here going from a source tree, with all binaries compiled and unit-tests done, to a single file uploaded somewhere, so users can download it the next morning. We do not cover here producing the more complex "self-installing" files, (linux .deb or .rpm, or windows .msi or .exe), only a regular archive, containing the whole source tree along with the needed binaries.

You can find below the two scripts, one for windows (.bat), and one for Linux (.sh). The Linux version only needs regular tools that should be available on every distribution, while the Windows versions needs 2 additional tools, the archiver and the svn command-line client. Yes, I know what you think: if you are using svn, then you have the command-line svn client ! Well, no, not necessarily. On windows, I use TortoiseSvn,  really nice and with a perfect shell integration. This gui software is not just a wrapper around the svn command-line client, it has its own binaries. So you need to install some other svn client if you're a TortoiseSvn user (they are available here).
For the archiver, I highly recommend 7-zip: has both GUI and CLI, high performance, good documentation, shell integration... and LGPL'ed ! Can't wait to have it on Linux.

The interesting point is that the two scripts here are project-independent: you just drop them in your root folder... and there you go! A simple double-clic will generate an archive (.zip or .tar.gz), containing a copy of the local repository, with the name like:

XXXXX_YYYYMMDD-HHMM_win32.zip for the windows version
XXXXX_YYYYMMDD-HHMM_linux.tar.gz for the linux version
with XXXXX being the project name, simply extracted from the root folder name. You can also run them from the command-line.

The only tweaking you need to do is edit the additional "upload" scripts, where the ftp command is issued: this is the only part that can not be automatic, as there is no way to automatically determine what the host is.

Inside the scripts, nothing really complicated, but I'm quite happy to achieve some bash scripting as well as I am used to do with windows scripting. I miss the 'goto' command, but I must say that bash is more efficient, even though I am more used to cmd.exe. The scripts mainly do an svn export, add the binaries (that shoudn't be versioned), and compress the whole thing, renaming it with the current date/time. Has been tested on XP-SP3 and Ubuntu 10.10, let me know if you experience some trouble.

Download link

Linux/bash version:

#!/bin/bash
echo Packaging linux archive

curpath=$(pwd)
name=$(basename $curpath)
#echo name=$name

now=$(date +%Y%m%d-%H%M)
fn=${name}_${now}_linux

echo "step 1 : export tree to temp path"
svn export . $HOME/tmp/$name

echo "step 2 : add binaries (not versioned)"
cp bin/* /tmp/$name/bin
cp lib/* /tmp/$name/lib

echo "step 3 : archive and compress"
cd /tmp
tar cfz $curpath/$fn.tar.gz $name
cd $curpath

echo "step 4 : cleanup"
rm -r $HOME/tmp/$name

echo "step 5 : upload"
./upload.sh

echo "done, file $fn.tar.gz available !"
read -p "press a key"

Windows version

@echo off
title Packaging windows archive

:: here, little trick to get the folder's name
set curr_path=%cd%
call :sp %curr_path%
::echo name=%name%

set archiver=C:\Program Files\7-Zip\7z.exe
set svnclient=C:\Program Files\Subversion\bin\svn.exe

:: step 0 : make sure all the tools are available
if not exist "%archiver%" goto err1
if not exist "%svnclient%" goto err2

echo step 1 : export tree to temp path
svn export . %temp%\%name% --native-eol CRLF

echo step 2 : add binaries (not versioned)
copy bin %temp%\%name%\bin > nul
copy lib %temp%\%name%\lib > nul

echo step 3 : compress
set year=%date:~6,4%
set month=%date:~3,2%
set day=%date:~0,2%
set hour=%time:~0,2%
if /I %hour% LSS 10 set hour=0%hour:~1,1%
set mn=%time:~3,2%
set now=%year%%month%%day%-%hour%%mn%
echo now=%now%
pause
"%archiver%" a "%name%_%now%_win32.zip" %temp%\%name% > nul

echo step 4 : cleanup
del /Q /S %temp%\%name%\* >nul
rd /S /Q %temp%\%name%

echo step 5 : upload
call upload.bat

echo done, file %name%_%now%_win32.zip available !
pause
goto :eof
============================================================
:err1
echo FAIL: archiver %archiver% not present !
pause
goto :eof
============================================================
:err2
echo FAIL: svnclient %svnclient% not present !
pause
goto :eof
============================================================
:sp
::echo sp, arg1=%1
set name=%~n1
goto :eof
============================================================

La fin des processeurs 8 bits ?

Un point de vue intéressant sur l'état du marché des microcontroleurs. Alors que les industriels poussent en avant les 32 bits et que nombre de gens prédisent depuis des lustres la disparition des 8 bits, le marché démontre au contraire que les processeurs 8 bits se portent mieux que jamais. Pour preuve l'excellente santé de Microchip, dont les ventes restent majoritairement centrées sur le 8/16 bits.

www.eetimes.com/discussion/break-points/4210504/8-bits-is-dead

Cet article est issu de embedded.com, site d'actu sur l'embarqué (qui a été racheté récemment par eetimes.com, l'url est maintenant www.eetimes.com/design/embedded). Je recommande vivement l'abonnement à ce site pour tous ceux qui s'intéressent à l'embarqué.

Voir aussi mes liens sur ce thème ici: www.delicious.com/skramm/embedded.

Edit 20120316: Suis tombé sur un autre billet au point de vue
radicalement différent.

Demo video

Just posted a short video I made that demontrates some stuff I have worked on during my PhD. It's about building sparse 3d maps using stereo images produced with unaligned cameras. Watch it directly on youtube for a higher image quality.

Utilisation carte K8055 de Velleman avec Code::Blocks

Nous utilisons dans le département la carte K8055 de Velleman pour initier nos étudiants au pilotage de hardware via de petits programmes en C. Voir le site pour une présentation de cette carte.




Le distributeur fournit des fichiers de projet pour MS Visual Studio, mais l'utilisation avec des IDE et compilateurs libres n'est pas indiquée, et peut être délicate pour des débutants. Nous présentons ici les étapes pour utiliser cette carte en C via Code::Blocks 10.05 sur Windows.

Pour plus de facilité, et pour ceux qui veulent se passer des détails, les fichiers modifiés sont accessibles ci-dessous. Pour les détails, voir le pdf en lien ci-dessous.

• article complet en pdf (65 ko)
• Archive zip des 3 fichiers (dll, .h et .lib) (12ko)

Running Doxygen

Doxygen is a nice tool, but using it comfortably is not very well explained in its documentation as this is supposed to be a tool used by people who have a little idea of what a console is. So the manual briefly says:
To generate the documentation you can now enter:

doxygen <config-file>

This assumes you have a console opened, in the right path. On a modern OS, it is much simpler to add an extension to the doxygen configuration file type (.dox seems of course appropriate, but its your choice), and to associate this extension to the considered program, so that a simple double click on the file will run doxygen, using this file as input.

With Windows, this association can be done easilly by selecting the .dox file, and selecting the "open with..." entry in the contextual menu. You can then navigate up to the doxygen/bin folder, and select doxygen.exe. I'm sure it is as simple on other OSes. However, this has some disadvantages, particularly on Windows. The default console behaviour that gets opened using the method described here gets closed when the program ends. So ?

Well, some times, things can go wrong. Either your code documentation is not correct, either there is a problem with your configuration file. In these cases, Doxygen outputs on standard error stream (stderr) a list of error messages that are very valuable. As the console closes, you lose all these error messages, not to mention that you can even not notice them. Moreover, even if you launch it from a previously opened console, doxygen is quite verbose on standard output (stdout), so important error messages get drowned under the flood of lines on stdout.

Redirecting is the way to go. Manually, sure, but as you probably need this functionnality through out your projects life, it is better to put this in a script. So the first idea is to add to the root of your project a small script file (say, run_doxygen.bat for Windows), that will look like this: (Nix users will adapt this without any problem)

@echo off
title Running Doxygen...

:: erasing previous files
del /Q html\*.*

:: running doxygen on file 'doxyfile.dox'
doxyfile.dox 1>doxygen_stdout.txt 2>doxygen_stderr.txt

:: showing doc (html) in default browser
html\index.html

:: opening error file in default text editor
doxygen_stderr.txt

This way, you log in two separate files the streams stdout and stderr, the latter being automatically opened when done, so the user can check for errors.

However, this method has two disadvantages:

• First, doxyfile name is hardcoded. For medium to large size projects, we will often have several configuration files, depending of the current documentation needs. Sure, whe could also duplicate the script, but that's not very practical.
• Second, this has to be done for every project we handle.

So a better idea is to have a unique script file somewhere, (on windows, c:\program files\_script for instance), and to associate the doxyfile type to this script, and not to the doxygen binary!

This only difference with the previous version is that it needs to explicitly call the doxygen binary, and pass it the script argument (%1) (doxygen configuration file).

@echo off
title Running Doxygen...

:: erasing previous files
del /Q html\*.*

:: running doxygen
"c:\program files\doxygen\bin\doxygen.exe" "%1" 1>doxygen_stdout.txt 2>doxygen_stderr.txt

:: showing doc (html) in default browser
html\index.html

:: opening error file in default text editor
doxygen_stderr.txt

Don't forget the quotes around the doxygen binary path !

Edit: this is for "html" doxygen output, but you can adapt it easily for other output types (tex, man, rtf, ...)

Edit-2 (2010-11-12): Actually, you must not put quotes around the %1 argument. Windows automatically adds quotes to the argument when called through the explorer, and this causes problem if the doxyfile is located from a path that has spaces.
(yes, I know, nobody puts spaces in the path of his personal folders...)

Aligned stereovision short note

If anybody is interested, I have written a short note on how to select the parameters of an aligned stereovision system (baseline and focal/field of view).

Nothing too complicated, only some basic geometry and some "gnuplotting".
It is hosted on my labs web site, the link is here.

It will probably be updated in some time, 'cause the plots don't look too nice, specifically when printed on a mochrome printer ;-), I'll let you know