Technique - J'ai participé au hackathon "MakeSense" (2/2)

[Suite de l'article précédent]

Pour ma part, j'ai rejoins le projet Adoptajerry car c'était le projet le plus intéressant  et parce qu'ils avaient un jerrycan ! Bon, évidement, ce n'était pas le projet le plus technique (Twitter et Google doc marquent un point là), surtout qu'en se lançant dans le projet, on avait pas plus de détail que ce que j'ai écrit dans le premier article...

Nous voila partis à 6-7 personnes pour réaliser notre challenge.

L'ordre du jour

1. Brainstorming (30 minutes)
2. Premier sprint (90 minutes)
3. Démonstration intermédiaire (10 minutes  par projets)
4. Second sprint (90 minutes)
5. Finalisation du projet et rapport final.

Brainstorming

Nous proposons, chacun notre tour, nos idées et quelles fonctionnalités sont nécessaires, pour réaliser le projet. Toutes sont notées sur un Post-It. Au bout de 20 minutes où nombres d'idées ont foisonnées, l'organisateur passe nous voir pour nous demander si nous avions choisi la technologie sur laquelle nous souhaitions travailler. Parmi les 3/4 propositions qui arrivent, ce ne sont que des Framework JavaScript et un SGBD NoSQL : CoutchDB. Youpi.

CouchDB : un SGBD NoSQL

Réflexion après coup, pour la prochaine fois, il y a pas mal de chose que l'on peut améliorer :

• parler de la technologie avant de se réunir par groupe. Peut-être aurais-je pu servir à un autre.
• faire un premier brainstorming en amont du hackathon afin de déterminer un ou deux parties galères, où il faut être un petite dizaine de cerveau pour que l'idée sorte.
• le brainstorming du début de projet porte alors sur ces contraintes.
• Le fait d'écrire les idées sur des Post-It était bien pour pouvoir les réutiliser ensuite, mais cela n'a pas été exploité. Chacun s'est fait une représentation du projet, il n'y a pas réellement eu de récapitulatif , et de priorisation des idées.

Premier Sprint

Pour ceux qui me connaissent un peu, vous savez à quel point j'ai du mal avec le JavaScript. Ce langage, où l'on peut TRÈS rapidement faire n'importe quoi, permet de faire à peut près tout ce que l'on a besoin, café inclus !
Étant très peu compétant avec cette technologie, je précise que je ne servirais pas à grand chose. Je me propose donc de travailler sur le web service et le dialogue avec la base de données. Et bien non !
Encore une fois, les technos ont été très bien choisie pour faire un prototype : le SGBD permet d'être attaqué très simplement avec un requête REST en JavaScript. On y place directement les objets complets. C'est le principe du NoSQL. Ok, je n'ai donc plus grand chose à faire là ?

C'est là où Romain recherche des personnes pour l'aider à faire des mockups des formulaires. Parfait, je sais faire ! Le binôme se passe bien, nous réfléchissons à simplifier au maximum le formulaire de création d'un Jerry et nous choisissons chaque mot pour qu'un publique non-technique puisse s'y retrouver.
Ce travail nous permet de définir informations obligatoires et optionnel pour l'objet "Jerry".

Fin du premier sprint, on se rend compte que l'on ne fait pas grand chose en 90 minutes !

Démonstration intermédiaire 

Chaque groupe présente son travail aux deux autres. 

AdoptAJerry, nous avons une première ébauche de design, qui se base sur le bootstrap de twitter. Nous avons grosso-modo la page d’accueil Une première ébauche de notre moteur applicatif est prête, les Jerry sont en base de données, et peuvent être récupérés et affichés. Le mockup de formulaire d'ajout de Jerry (3 pages, 10 champs maxi par page) est créer, et nous avons débuté "l'adoption" d'un Jerry par un utilisateur.

Unishared, ils ont réussi à "hacker" le menu contextuel de Google Docs, pour y ajouter une nouvelle entrée et son capable de récupérer l'action de clic sur cet item. Il ne leur reste plus qu'à twitter :) Encore une fois, bravo à deux, leur petit hack tiens sur 2 lignes !!

SenseSchool, je ne crois pas que l'on ait eu de présentation de leur part, ou sinon elle ne m'a pas marquée...

Second sprint

Bootstrap, from twitter

Romain nous quitte, je me retrouve seul pour faire les mockups, et je ne sais pas exactement ce qu'ils souhaitent pour leur produit : il n'y a rien d'écrit. Je vais donc vagabonder auprès des autres groupes, pour comprendre comment fonctionne ce qu'ils ont fait. C'est à ce moment là que je découvre la facilité d'utilisation de CouchDB. Je découvre aussi ce que l'autre binôme a réussi à faire avec le BootStrap Twitter C'est vraiment réussi : avec juste quelques balise, des bons attributs et ça fonctionne nickel ! J'espère que cela sera très bientôt enseigné dans les écoles d'informatique (orienté web)  !

Bref, c'est ici que l'aventure s'achève pour moi, je dois partir un peu plus tôt que l'heure finale, mais en résumé : 

• une équipe organisatrice qui a su mener à bien l'évènement, qui a su porter un groupe de personne pour réaliser les projets, maintenir le rythme... bref de l’excellent boulot !
• des projets qui ont du sens, généralement bien présentés, même si certains avaient de petits soucis à l'oral ;)
• des périmètres projets pour le hackathon seront à mieux définir pour la prochaine fois.
• réalisation d'un site jetable pour adoptajerry.cc, je ne sais pas s'il sera réutilisé par la suite...
• pour ma part, pour être un peu plus utile lors du prochain évènement, soit j'en choisi un qui tombe exactement dans mes cordes, soit j'ajoute le javascript aux cordes de mon arc !

En gros, les hackathon c'est génial, allez y tous !

Présentation - J'ai participé au hackathon "MakeSense" (1/2)

Alors que j'étais en train d'essayer de me faire entendre pour créer une série d'évènement pour que des développeurs puissent s'entraider et se motiver mutuellement, j'ai été approché par Arnaud BRETON. Ce dernier est un porteur d'idée, un entrepreneur social selon les termes de MakeSense.
Il travaille sur un outil collaboratif pour la formation, et en particulier sur la prise de note. Bref, j'étais motivé pour bosser, et on m'a proposé de bosser pour une vrai cause : j'ai sauté sur l'occaz !

Petit récap de l'évènement :

Pour une demi-journée le Samedi 29 Septembre, nous appelons tous les hackers (développeurs), designers, et utilisateurs a venir créer des prototypes de solution venant résoudre des défis technologiques auxquels font fasse des entrepreneurs sociaux.

Donc, avec mon humble bagage de développeur, j'espère donc pouvoir résoudre des blocages techniques pour une cause humanitaire !

Le hackaton se déroule dans les locaux d'Epita, au Kremlin-Bicêtre. Le lieu est très accueillant, il pullule d'étudiant qui bossent (ou pas! ) dans les couloirs, et dans les autres salles. C'est assez déroutant de se dire que l'on est dans une école, et que même sans professeurs, et qui plus est un samedi, on a des gents assez motivé pour continuer à bosser. Je pense que le prix de l'école joue un peu aussi ;)

Présentation des projets :

Jerry, 'cauz Jerry can ! Ceci est un PC :)

3 projets nous ont été présentés :

1. Adopt a Jerry, présenté par Romain. L'idée, c'est de recycler les composants de nos pc dans des nouveaux conteneur : des jerrycan ! Ca permet de rendre le pc mois cher, plus accessible et sexy. Ces pc sont ensuite utilisé comme des serveurs ou des pc pour une utilisation bureautique basique.
   Leur défi ? Réaliser un site web pour recenser les Jerry, leurs contributeurs...
2. Unishared, un outil de prise de note collaborative, amené par Arnaud BRETON.
   Leur défi ? Arriver à lier Twitter et Google doc : sélectionner du texte pour le twitter, et récupérer des valeurs de twit pour les ajouter à des Google doc.
3. SenseSchool. Ils proposaient de changer le programme des étudiants d'école de commerce. Aujourd'hui, ils bossent sur des projets fictif, des "cas d'école". SenseSchool propose qu'ils aident des entrepreneurs à réaliser leurs projets, afin d'apprendre leur métier. La réussite de cette matière dépendrait de la réussite du projet de l'entrepreneur.
   Leur défi ? Mettre en place un WordPress pour présenter le projet (projet à destination d'un publique non développeur).

Mis à part Unishared, ce n'est pas un réel Hackaton, il n'y a pas de réel chalenge technique pour créer un système web dédié à la gestion de personne (ou de Jerry) ou remplir un WordPress. Nous nous sommes donc retrouvé dans l'urgence d'un hackaton à réaliser des projets jetable. Je pense qu'il aurait mieux fallu définir à l'avance les objectifs, et déterminer la partie la plus "tricky" pour qu'on se mette a plusieurs cerveau pour la réaliser.

J'ai tout de même trouvé l’expérience intéressante et j'espère que les projets entamé ce w.e pourront être achevés. C'est pour une bonne cause, et parce que les organisateurs sont sympa !

La suite ici : J'ai participé au Hackathon (2/2)

Mener un projet personnel à terme

Beaucoup de personnes, et particulièrement dans l'informatique, souhaitent créer leur propre produit. Le but de cette démarche est souvent de vouloir répondre à un besoin, mais surtout que cette création soit utile et utilisée.

Il faut impérativement garder une chose en tête : le seul objectif à avoir est de finir le projet.

Il se pose dès lors la question du besoin : comment déterminer ce que l'on souhaite développer ?
Premier choix, nous en avons le besoin. L'application développée, nous n'utiliserons ! A ce moment là, nous nous poserons un peu moins de question.
Second choix, d'autres personnes ont remonté ce besoin. Question évidente : peut-on facilement prendre contact avec eux ? Sera-t-il possible de spécifier le besoin avec eux?

Que se soit nous ou d'autre, il est important de définir un cadre au projet, des limites qui serviront de garde fou. En définissant cette limite, nous avons un objectif ainsi qu'un moyen de quantifier notre avancement. La réponse à la question "Tu en es où ?" avec "Ca avance" est quasiment la pire. Oui, le "je reprend depuis le début" est  à la fois néfaste pour l'image que vous renvoyez du projet, mais surtout pour votre motivation personnel.
Savoir où on va, en ayant des objectif défini et quantifiable : objectif numéro uno !

Que développer ? Que de soit notre idée ou celle d'un autre, je conseillerais une démarche efficace, permettant de ne pas faire tout et n'importe quoi.

1. Rédiger l'idée. Cela dois de limiter à une unique page. Si vous n'y arrivez pas, l'idée n'est alors pas assez définie. Si vous en écrivez plus, alors il y a fort à parier que ce projet est complexe. Posez vous alors la question de savoir si vous maitriser toutes les compétences nécessaire pour mener le mener à bien.
   Tant que vous n'arrivez par à rédiger au moins une page, je vous conseil d'en parler autour de vous. De nombreuses personnes ayant des idées ont peur qu'on leur "vol" et ne souhaitent pas en parler. Dites vous 2 choses : soit quelqu'un a déjà eu cette idée, et elle a été concrétisée, alors il n'y a pas de crainte à avoir ! Soit personne n'y a pensé, ça n'existe nul part, vous créez alors le besoin. Il vous est donc nécessaire de savoir ce que les gents veulent, comment ils souhaitent l'utiliser. De plus, si quelqu'un récupère cette idée pour la développer, alors vous aurez un concurrent. Vous serez donc plusieurs à créer ce marché, ce qui va grandement aider la chose. Il vous suffira alors d'être meilleur, n'est-ce pas motivant ?
2. Faites de simples tests de faisabilité : développer un projet "brouillon" qui vous permettra d'assurer que le développement est possible. Par exemple, si vous souhaitez développer un projet qui a besoin de lire des codes barres (cc POME) testez le fonctionnement des douchettes, et des solutions alternatives (photo et analyse des codes barres via des smartphones).
   Cela permettra alors de définir les choix techniques.
3.  Arrivez à ce point là, contemplez le travail réalisé, ça fait du bien à la motivation ;) Vous en êtes à 30% de l'avancement de votre projet !
4. En fonction de la taille du projet et en fonction de la taille de votre équipe, il peut être intéressant de découper le travail en projet indépendant, en ne définissant que les interfaces de communication entre les différentes parties. Ces découpes pourront être assigné à un membre de l'équipe. Si vous travaillez seul, cela définira vos étapes, et vous pourrez répondre à la question "Tu en es où ?" assez facilement.
5. Après ça, y'a plus qu'à ! Je ne vais pas vous apprendre à développer, j'en ai pas la prétention ! Je conseillerais juste d'en faire le minimum, mais de toujours penser à l'évolutivité de votre projet. Par exemple, pourquoi traduire votre application en 7 langues dès le début? Ne laissez que votre langue maternelle, mais mettez tout de même en place des fichiers de ressources afin de pouvoir évoluer facilement. N'oubliez pas que le but final est d'au moins finir ce projet. Ce seront les retours de vos utilisateurs qui détermineront quelle partie de votre application est à améliorer.
6. Dernier conseil : en tant que développeur, nous apportons une volonté toute particulière au fonctionnement de notre application. On souhaite évidement que la fonctionnalité soit la plus complète possible, évidement dépourvue de zone non validée (les fameux bugs!). Mais il y a une chose qui est au moins aussi importante que le fonctionnel, si ce n'est plus à l'heure où nous consommons des applications aussi rapidement que télécharger/installer/quitter. Pour convaincre l'utilisateur d'utiliser notre application, il est indispensable de définir un bon design et une identité visuelle forte (un logo qui défonce!!). Pour ma part, je n'ai absolument aucun gout esthétique, je fais appel aux services d'une graphiste confirmée : Ibealia. Ok, ça fait un investissement supplémentaire, cependant ça ne coute pas non plus un bras, et vous saurez directement si vous souhaitez vous investir, un peu plus que par du temps, dans le projet :)

Un projet perso, c'est surtout un bon moyen de découvrir beaucoup de chose, et apprendre à devenir polyvalent. Un projet mené à terme est TOUJOURS valorisant, même pour une application téléchargée 4 fois ...

Ressources et WP7

Suite à l'article Gestion des ressources, voyons comment cela fonctionne avec un projet WindowsPhone 7.

Avec WP7, le code utilisé en ASP.Net
                <% $Resources : ResourceFile, ResourceKey %> 
ne fonctionne pas. Cependant, nous avons généralement l'habitude d'utiliser la notion de Binding, surtout avec le MVVM. L'utilisation des ressources dans un projet WP¨7 est quasiment identique !

Dans cet exemple, nous appelons la ressource dont la clé est AppName. Cette ressource est défini par la classe statique "Strings" qui expose une propriété "Localizerresources".

Le type de la propriété "Localizerresources" est du type du fichier de ressource que l'on souhaite utiliser. J'ai été original avec mon fichier de type "Resource" ;) 

Ce fichier doit définir un "Outil personnalisé" (voir ici !) tel que "PublicResXFileCodeGenerator". Cet outil va  créer un designer avec des propriétés publiques qui vont pouvoir être utilisées par notre classe "Strings".

Il ne reste qu'un petit détail, il faut référencer notre StaticResource. Pour cela, dans l'App.xaml : 

Et voila, c'est censé fonctionner ;)


Référence  : http://msdn.microsoft.com/en-us/library/ff637520%28VS.92%29.aspx

Gestion des thèmes dans un projet .net

Suite à l'article de gestion des ressources, nous verrons aujourd'hui la gestion des thèmes dans un projet .Net.

Un thème ?

Un thème est un ensemble de ressources (images, style, ...). Cet ensemble d'information se trouve dans un sous-répertoire du répertoire "App_Themes" de notre solution. Le nom de ce sous-répertoire définit le nom de notre thème.
Une fois cette architecture respectée, le thème peut contenir autant de répertoire et fichier souhaité, sans contrainte particulière.

Appliquer un thème

Pour cela, il existe plusieurs solutions.

Nous pouvons définir un thème global pour l'application. Pour cela, il suffit de définir dans le fichier de configuration (le web.config pour un site asp.net) le nom du thème à appliquer, au niveau de l'entrée "pages".

Le thème peut aussi être défini pour chaque page. Pour cela, il faut le définir dans l'en-tête de notre template aspx ou ascx. Cette définition surcharge celle faite dans le "web.config".

La dernière solution est de l'appliquer au runtime. Encore une fois, cette solution surcharge les deux précédente :

Attention : contrairement à ce que j'ai écrit dans le screen, l'affectation du thème doit se faire lors du PreInit de la page (plus d'info ici).

Utilisation du thème

Lorsque l'on applique un thème, chaque fichier ".css" inclus dans le dossier est automatiquement appliqué à la page. C'est cool : pas besoin de penser aux références :)

Cependant pour les images, c'est une autre paire de manche...

On ne peut pas utiliser les images avec les chemins relatifs habituels (~/Images/trug.png), ou sinon on inclut le nom du thème dans le chemin. Et à ce moment là, quel intérêt d'utiliser un thème ?

On a alors deux solutions :

• Référencer chaque appel d'une image en code-behind, en utilisant le thème en cours (Page.Theme)
• Utiliser un fichier ".skin"

Met un skin dans ton thème !

Cette idée a été trouvée ici : http://stackoverflow.com/questions/200488/asp-net-theme-images. 

Dans notre fichier ".skin", on définit les images utilisables : 

Le SkinID n'est pas nécessairement unique dans un fichier, mais il est unique par contrôle (dans notre cas Image et ImageButton).

Et les images utilisées sont évidement dans notre répertoire de thème, on peut alors avoir des images différentes par thème, tant que les SkinID sont identique.

On peut aussi référencer des images qui ne sont pas dépendantes de skin ! Bref, la vie est belle :)

On utilise ensuite notre Skin dans les templates aspx, ascx  tel que : 

Et voila.

Gestion des ressources dans un projet .NET

Gestion des ressources dans une application

Une ressource ?

Les ressources sont l'ensemble des textes, images, élément affichable qui peuvent être affiché dans une application. Cette dernière peut être un site web, une application WPF, WindowsPhone... les fichiers de ressources peuvent être partagés entre ces divers projets.

.resx

Un fichier de ressource est un fichier ".resx", un fichier XML qui défini pour chaque ressource, une balise "data" avec deux attributs et au moins un élément fils :

• un attribut "name" qui définit la clé pour appeler la ressource.
• un attribut "xml:space" qui prend la valeur "preserve" lorsque la ressource est créée par l'éditeur. Les espaces présents dans la donnée en rapport avec cette ressource seront concervés. En la définissant à "default", ou en ne la définissant pas, les espaces seront ignorés. 
• un élément fils "value" qui définit la valeur à afficher lorsque la clé sera appliquée dans le code
• un élément optionnel "comment" pour y placer un commentaire à destination du développeur.

Exemple :

<data name="AppName" xml:space="preserve">
    <value>POME</value>
    <comment>Application name</comment>
  </data>

Attention cependant : en utilisant le lecteur de ressource par défaut de Visual Studio, les ressources du fichier XML sont triés. Cette modification du fichier .resx, à chacune des ouvertures, va rendre complexe le merge de branche, lorsque l'on travaille avec des outils (indispensables!) de versionning tel que TFS ou SVN.
Pour ma part, je les ouvre donc avec l'éditeur XML :

Clic droit -> Ouvrir avec -> Editeur XML (Texte) avec encodage. Sélectionner "Par défaut", puis valider.

Modifier le lecteur de ressource par défaut

Ce fichier ".resx" peut être créé en plusieurs endroits :

• Dans un répertoire placé à la racine, nommé "App_GlobalResources". Les fichiers de ressources définis dans ce répertoire seront accessibles partout dans l'application. Cela peut être le bon endroit pour y définir les valeurs de "Oui", "Non", "Valider", ... Tous ces mots courants qui se retrouveront dans toute l'application.
• Dans un répertoire "App_LocalResources" placé au niveau d'un template : une page ".aspx" ou un composant ".ascx" pour un site ASP.NET, une page ou un composant ".xaml" pour un projet Silverlight ou WP7. Les ressources ne seront définies que localement au template.
• Ou bien n'importe où ! Et oui, un fichier de ressource peut être défini et utilisé depuis un projet différent. Cela casse cependant le processus de binding, automatiquement mis en place par les répertoires prévus à cet effet. 

Mécanismes

Le premier mécanisme est la possibilité d'appliquer un outil personnalisé ("CustomTool") à un fichier de ressource. Cet outil est une classe qui permettra de générer automatiquement un Designer associé à un fichier de ressource. Ce designer est en fait une classe C# qui reprend automatiquement l'ensemble des ressources du fichier afin de les exposer sous forme de propriété statique. Elles seront alors facilement utilisables via notre code C#.

Pour appliquer cet outil à un fichier de ressources : cliquer droit sur le fichier, propriété, puis y ajouter le nom de l'outil dans le champs correspondant (exemple d'outil : "GlobalResourceProxyGenerator" ou "ResXFileCodeGenerator"). Il est possible de créer son propre outils, mais cela demande de créer une COM classe et de l'enregistrer dans le registre du poste du développeur... pas très pratique !

Pour reprendre notre exemple de tout à l'heure, où notre fichier de ressources dans App_GlobalResources, nommé "Global" définit une ressource "AppName" et notre fichier dans App_LocalResources définit une ressource "Example" :  

Utilisation des ressources en code-behind

Attention : il est important de tester l’existence de la ressource dans un fichier qui n'a pas de Designer associé. Il n'y a pas de ressource par défaut renvoyée, une exception serait alors déclenchée.

L'équivalent pour afficher ces ressources dans des templates d'un site ASP.NET : 

Utilisation des ressources dans les templates

Ici, une ressource inexistante n’empêchera pas non plus la compilation, mais il y aura une erreur à l'exécution.

Quel utilité?

Si vous êtes arrivé jusqu'ici sans vous demander pourquoi mettre en place tout ce processus pour afficher juste des chaînes de caractères, il y a un souci ! En effet, c'est plutôt contraignant, donc pourquoi se donner cette peine ?

Réponse : pour se simplifier la localisation de votre application,  pouvoir changer les textes et les images affichés en fonction de la langue.

Pour cela, il suffit de définir des fichiers de ressources pour chaque langue que l'on souhaite supporter. Les nom des fichiers ont une importance particulière : ils définissent à quel langue correspond tel fichier.

Ex : 

Exemple de fichiers de ressources

En définissant ces 4 fichiers, nous supportons à présent plusieurs langues : 

• L'anglais (en)
• Le français (fr)
• Le français, spécifiquement pour la Belgique (fr-BE)

Chaque fichier re-définit tout ou partie des clés définies dans le fichier initial "Global.resx". Si une clé n'est pas définie dans le langage spécifique, alors le fichier de ressources du langage parent (ex : fr, pour le fr-BE) est interrogé. Encore une fois, si la clé n'est pas définie pour un langage, le fichier de défaut sera interrogé. Une exception sera déclenchée si la clé est appelée mais n'est pas définie.

La langue utilisée par votre application est définie par :

Thread.CurrentThread.CurrentUICulture

Cette valeur est assignable tel que : 

Thread.CurrentThread.CurrentUICulture = new CultureInfo(1033);

Le paramètre passé à CultureInfo est le LCID de la langue. La liste des LCID pour chaque langage est disponible ici :  http://msdn.microsoft.com/en-us/goglobal/bb964664

Pour plus d'informations, msdn regorge de fiches à ce propos : http://msdn.microsoft.com/fr-fr/library/ms247246(v=vs.80).aspx