Interview de gorgull, créateur de Protein Der Klang
Bonjour,
beaucoup d'entre nous développent des projets personnels, mais il est rare qu'ils arrivent à maturité, et encore plus que ces petits projets atteignent le stade le logiciel commercialisable. Alors j'ai pensé que beaucoup d'entre nous seraient intéressés par l'interview de quelqu'un qui est parvenu à développer avec succès un logiciel sur son temps libre. C'est un peu long, mais très intéressant:
Bonjour, peux-tu te présenter rapidement, ton parcours scolaire et professionnel, tes projets antérieurs, ton activité actuelle ?
Bonjour. J’ai suivi un cursus universitaire scientifique partant des sciences de la matière et terminant par un Master en Informatique Multimédia.
Je travaille depuis 2003 comme ingénieur en informatique au sein de la société ArKaos en Belgique où nous créons des solutions logicielles et matérielles pour mixer de la vidéo et du son en temps-réel.
De 2003 à 2006 j’ai travaillé sur X-Foot avec des amis sur le concept original de l’un d’entre eux.
En 2006 j’ai commencé à m’intéresser à la programmation audio et j’ai développé Protein DScratch de 2007 à 2009 pour la plate-forme Nintendo DS, qui avait la particularité à l’époque d’avoir un écran tactile.
Je me suis lancé dans le développement de Protein Der Klang en 2009. A cette époque je n’imaginais pas qu’il se passerait plus de trois ans avant la sortie officielle! L’application est toujours en développement actif et la version 1.1 vient d’ailleurs de sortir.
En travaillant sur la mise à jour 1.1 de Protein Der Klang je viens de terminer une nouvelle application musicale pour iOS qui va être disponible gratuitement sur l’App Store. Cette application destinée aux beatboxers permet d’enregistrer des boucles et de les rejouer ensemble avec des effets.
Protein Der Klang permet de jouer et manipuler jusqu’à 12 samples en temps réel. Les échantillons peuvent être enregistrés à partir du micro ou du son de l’application elle-même, ou importés à partir d’un ordinateur ou d’autres applications.
J’ai pensé l’application comme un instrument à la fois simple et ludique, tout en ayant une profondeur qui lui permette d’être utilisé sur scène.
Au final, les utilisateurs vont du curieux qui s’enregistre et s’amuse avec des sons, au producteur qui joue ses propres morceaux sur scène.
Le travail sur Protein a commencé de manière expérimentale. Je m'amusais beaucoup à programmer du son et j'ai décidé de mettre une vidéo de ces expérimentations sur internet. Contre toute attente j’ai reçu un très bon retour, ce qui m'a poussé à créer une véritable application et à diffuser des versions. Des musiciens ont alors commencé à l’utiliser comme un instrument à part entière. J’ai reçu quelques dons, des demandes pour des fonctionnalités spécifiques et des encouragements qui m’ont motivé à continuer.
Apple a sorti le kit de développement pour iOS au moment où je commençais à ressentir les limites de la Nintendo DS, et j’ai décidé de sauter le pas et de créer une nouvelle application avec une qualité plus professionnelle, tout en gardant le côté ludique du concept Protein original.
J'ai travaillé environ 3 ans et demi sur Protein Der Klang, à raison de 10 à 12 heures par semaine.
Le projet Protein est un projet personnel, et j’ai rapidement pris goût à la liberté que procure le fait de travailler seul, en comparaison avec les projets sur lesquels je travaille en équipe.
Avec Protein Der Klang, j’ai voulu me prouver que j’étais capable de réaliser seul une application commercialisable.
Un ami designer m’a proposé son aide pour la partie graphique, et nous avons passé pas mal de temps à réfléchir à la manière d’épurer mon interface et l'ergonomie qui en découle.
Travailler seul a un côté très plaisant quand on n’a pas d’impératif financier: je travaille à mon rythme et ma liberté de décision est totale.
Je me sens aussi vite seul quand je butte sur un problème et il m’arrive ainsi régulièrement de me sentir découragé.
J’ai dû finir par m’imposer une date de sortie définitive car je la repoussais depuis des mois, considérant que l’application n’était pas assez mature, et parce que je devais commencer à travailler sur une autre application qui devait sortir dans un laps de temps très court.
J’utilise plus ou moins les même règles et les même outils que ceux que j’utilise lorsque je travaille en équipe.
J’utilise Subversion pour la gestion des versions et une sauvegarde en ligne.
Je profite du nouveau projet sur lequel je travaille pour tester Git qui semble offrir plus de souplesse que Subversion, notamment en ce qui concerne la création et le merge des branches.
Pour ce qui est des règles de codage, j’écris toujours dans l’optique que mon code soit utilisable par d'autres personnes, comme quand je travaille en équipe. Et comme je n’aime en général pas trop lire la documentation j’utilise des noms très explicites et je mets beaucoup de commentaires dans mon code.
Développant pour iOS, j’ai utilisé l’IDE XCode, qui intègre un compilateur, un debugger, un static analyzer, un outil de profiling assez complet appelé “Instruments” et permet de signer les binaires, de les exporter et les envoyer sur l’App Store.
Ma méthode est itérative et s’apparente à la méthode Scrum par certains aspects.
Je note toutes mes idées sous forme de tâches plus ou moins détaillées dans un outil de “Get Things Done” appelé Wunderlist.
Chaque semaine je décide les tickets sur lesquels je vais travailler. L’utilisation d’un tel outil permet de se concentrer uniquement sur ce qu’on a décidé de faire sans penser au reste, et ainsi de voir qu’on avance petit à petit.
Quand une fonctionnalité me pose un problème, j’en prends note dans la tâche en question et je passe à une autre, pour finalement y revenir un peu plus tard.
Je m’impose régulièrement de sortir des versions que je distribue à des testeurs.
Quand il m’arrive de douter de la pertinence de mon travail et de perdre ma motivation, je fais une pause d’une semaine, ce qui me permet de prendre le recul nécessaire pour aborder les choses sous un angle différent et avoir envie de m’y remettre.
Je pense que les deux éléments primordiaux pour la réussite d’un projet sont d’une part le plaisir intellectuel qu’on prend à y travailler, et d’autre part le retour des utilisateurs qui prennent plaisir à l’utiliser.
Comme je le disais précédemment, je note et détaille toutes mes idées au fur et à mesure dans Wunderlist synchronisé entre mes différents appareils, ce qui me permet de m’organiser et de ne rien oublier quelque soir le lieu et le moment.
Je ne fais pas d’UML à proprement parler. Pour chaque nouveau module ou fonctionnalité, je fais l’analyse, la conception, le design et je décris les grandes lignes de l'implémentation dans un cahier.
Au final, j’essaye de ne passer qu’un minimum de temps sur mon environnement de développement, ce qui réduit à mon sens énormément les risques de bugs.
J’utilise un maximum le langage C++ parce que c’est le langage que je maîtrise le mieux, mais surtout parce qu’il est portable sur énormément de plates-formes.
J’ai utilisé l’Objective C / Cocoa uniquement pour l’implémentation des modules qui sont spécifiques à la plateforme iOS, comme l’entrée et la sortie audio, l’accéléromètre, le multi-touch, les dialogues natifs, le chargement des ressources graphiques, et les opérations sur le système de fichiers.
L’idée est de définir une interface C++ unique pour chacun de ces modules, puis de les surcharger pour chaque plate-forme que je souhaite supporter.
De cette manière, il m’a par exemple été facile dans le passé de porter l’application Protein DScratch de la NDS sur Mac, Windows & Linux de manière à la débugger plus facilement.
J’utilise OpenGL ES pour la quasi-totalité de l’affichage, dans le même souci de portabilité.
En plus de Cocoa, j’ai utilisé Tinyxml pour la persistance des données, Sonoma AudioCopy/AudioPaste pour copier et coller des échantillons audio entre les applications et AudioBus pour partager la sortie audio avec d’autres applications.
La plateforme iOS est plébiscitée par les musiciens pour plusieurs raisons: elle a été la première à proposer un kit de développement et des applications à bas prix, elle proposait dès le début un accès bas niveau au matériel audio (ce qui est indispensable pour obtenir une faible latence), et des technologies comme Audiobus, Sonoma AudioCopy/AudioPaste et plus récemment Jack permettent aux musiciens d’utiliser plusieurs applications de manière complémentaire sur la même machine. Toutes ces raisons font qu’iOS et plus particulièrement l’iPad prennent une place grandissante dans la création musicale.
En comparaison, le système Android ne permet un accès audio bas niveau sur quelques appareils seulement depuis sa version 4.1, et la fragmentation de la plate-forme suppose de supporter plusieurs processeurs et un nombre important de formats d’écrans différents, là où iOS n’en propose qu’un petit nombre bien défini. Il semblerait néanmoins que les choses commencent à changer.
Toute l'application est construite autour du design-pattern MVC, qui permet de séparer complètement le moteur, les données et l’interface graphique.
A cette fin, j’ai beaucoup utilisé le pattern observable / observé, à la fois pour notifier l’interface des changements de données du modèle, mais aussi les contrôleurs des actions sur l’interface.
J’utilise également le pattern “Installable” pour abstraire les modules spécifiques à la plate-forme et facilement porter mon code: dans du code spécifique à la plate-forme, on “installe” l’instance d’une classe spécialisée dans la classe mère, qu’on utilise ensuite comme un Singleton dans tout le reste du code.
Pour pouvoir tester son code sur des appareils et soumettre des applications sur l’App Store il faut souscrire au “iOS developer program” qui coûte 99$ par an. Il est possible de développer et de tester son code dans un simulateur de iPhone / iPad sans cette licence, l’environnement de développement XCode étant gratuit.
Lors du développement, chaque appareil sur lequel on veut pouvoir tester l’application doit être enregistré dans un profil avec lequel on construit l’application. On peut alors distribuer un binaire qui ne pourra être exécuté que sur ces appareils.
Une fois le développement terminé, il faut construire l’application avec un profil spécial “App Store” qui permettra de soumettre l’application à Apple. Il faut alors patienter de une à deux semaines avant que le binaire soit testé, puis approuvé ou rejeté par Apple. Un rejet s’accompagne d’une explication détaillée, et il est possible de faire appel de cette décision; c’est ce qui m’est arrivé avec la version 1.1, qu’Apple a finalement accepté une fois que leur ai fourni quelques explications.
Il semblerait que les utilisateurs iOS soient plus enclins à acheter des applications que les utilisateurs d’Android, que le système plus ouvert de ce dernier permette plus facilement le piratage des applications. C’est pour ces raisons que certains développeurs proposent leurs applications sous forme gratuite avec des publicités sur Android, alors qu’ils la distribuent sous forme payante sur iOS.
Je distribuais mon application précédente Protein DS sous licence Creative Commons. J’avais installé un petit bouton pour les donations qui m’avait permis de récolter quelques dizaines de dollars. Je vais d’ailleurs prochainement d’en distribuer les sources en espérant faire plaisir à la communauté et certains utilisateurs qui continuent à me demander des mises à jour.
Pour Protein Der Klang, j’ai choisi une distribution payante car je me suis mis dans l’optique de réaliser une application de qualité professionnelle, en y consacrant beaucoup de temps et d’énergie, mais aussi car l’App Store permet de distribuer facilement et à moindre coût des applications à des prix très attractifs.
J’essayerais de plus utiliser des outils de design graphique pour m’éviter de passer des heures à programmer des éléments qui n’apparaissent pas dans la version finale.
J’ai utilisé pour ce projet une approche “key value observing” pour les notifications entre le modèle et les vues qui offre une bonne granularité et évite des rafraîchissements inutiles. Le désavantage est que l’on obtient énormément de notifications avec le nombre de propriétés qui augmente. Dans ma nouvelle application mon collègue et moi utilisons des notifications de plus haut niveau lancées par les objets possédants les propriétés, de manière à avoir une meilleure maîtrise des notifications.
Pour terminer je dirais qu’il ne faut pas sous-estimer le plaisir qu’on a à procéder par essai-erreur, et qu’il ne faut pas hésiter à laisser des problèmes de côté tant que l’on est pas satisfait de la solution, la meilleure étant souvent la plus simple.
Répondre avec citation
Partager