AngeZanetti.com

Internet et ses usages, développement Web et humeurs diverses

Tag: Jobs (page 1 of 4)

Fuite mémoire avec curl et NSS sous RedHat

Depuis plusieurs mois je travaille pour une startup qui fait de la lutte contre la fraude. En deux mots, les clients nous envoient des flux XML et nous leur renvoyons note correspondant à l’indice de confiance de la transaction.

Et, début Janvier nous avons intégré un GROS client. Du genre à faire pâlir les sysadmin. Cela nous à forcer à reconstruire une partie du code, à revoir l’architecture de l’application (qui est au passage devenue une application symfony2).

Le problème à été de faire communiquer la nouvelle partie avec l’ancienne, et comme nous sommes en PHP, ben nous avons opté pour Curl.

Pour chaque score demandé nous avons donc un appel CURL du nouveau code vers l’ancien. Rien d’inquiétant, cela fait partie de l’habituel en PHP.

Sauf que là :

 

Une belle grosse fuite mémoire, entre chaque restart Apache pas moyen de savoir où partait la mémoire. Nous avons d’abord accusé Symfony, l’ORM à assez mauvaise réputation avec des dæmons et Doctrine avoue ne pas être taillée pour absorber de la charge.

J’ai donc mis en place les fix nécessaires: forcer le garbage collector, désallouer la mémoire des objets inutilisés mais rien n’y faisait.

J’ai ensuite testé de lancer mes commandes en –no-debug, de virer les logs mais pas mieux, ma mémoire disparaissait toujours dans les méandres de mon système…

Toute ma RAM foutait le camp, de manière pernicieuse, petit à petit, Mo par Mo jusqu’à arriver à la limite du système, aux alentours du Go de libre – NB: le serveur n’avait pas l’air de souffrir par ailleurs, l’application ne ralentissait pas outre mesure…  

NSS Softoken

Finalement c’est le sysadmin qui à trouvé l’origine, en farfouillant sur le web. Je lui avais parlé peu de temps avant d’une histoire de fuites mémoire dans le CURL, vaguement, j’avais rien pigé à l’article. Il est retombé dessus quelques jours plus tard, et BIM, révélation! Notre fuite mémoire était en fait dû à une faille système, une sombre histoire de NSS (Network Security Services), qui est utilisée par libcurl et qui faisait du cache là où elle ne devrait pas.  C’est assez bas niveau, mais c’est un bug connu sur la version 3.16.0. C’est la version actuelle sur RedHat… Si vous voulez plus de détail je vous invite à lire cet article qui est la source de nos modifications : https://www.splyt.com/blog/2014-05-16-optimizing-aws-nss-softoken

Le fix est assez simple, il suffit d’ajouter une ligne dans la conf’ Apache:

# execute these commands as ‘root’ echo “export NSS_SDB_USE_CACHE=YES” >> /etc/sysconfig/httpd service httpd restart

Et voilà, comment retrouver le sourire et plusieurs Go de RAM ! 

Comment savoir que son code est de bonne qualité?

C’est une question qui m’a été posée en entretien d’embauche il y a peu de temps:

“Comment un autodidacte comme vous peut-il être sur que son code est de bonne qualité?”

Ça peut paraître une question naïve, surtout venant d’un RH, mais ça me fait pas mal cogiter depuis, au delà de la technique.

Pendant l’entretien j’ai répondu un truc bâteau, qui a d’ailleurs eu l’air de lui plaire, mais il me semble que cette question de comment je produit du code et pourquoi il est bon ou mauvais mérite bien un petit article.

Au passage, si tu passes par là Mme la RH et bien tu trouveras ci dessous une réponse un peu plus complète à ta question :)

DISCLAIMER: Je vais parler ici de méthodes et pas de techniques pure. Si tu cherches à savoir comment indenter ton code ou si tu dois ou non commenter tu ne trouveras pas ton bonheur :)

Comment produire du code de qulité

1 – Mon code marche

Réponse simpliste. Mon code fonctionne, ça tourne en prod depuis des jours/mois/années, mon code est de qualité.

C’est pas faux, mais ce n’est pas suffisant. On a tous en tête des codes qui tournent mais qui ne seront jamais mis à jour tellement l’effort de maintenance est important.

Un code qui tourne n’est pas un bon code, c’est nécessaire mais loin d’être suffisant.

2 – Mon code est le fruit d’une méthode de travail

Produire du code de qualité c’est, pour moi, avant tout la mise en place d’une méthode. Toute l’équipe de développeurs doit être impliquée et faire en sorte que la base de code de tous les projets soit de qualité ou en constante évolution vers une qualité optimale.

Pour ça j’essaie d’appliquer ces trois méthodes :

Merge Request

Je travaille le plus possible avec le workflow de github. Tout mon code est crée sur de nouvelles branches avec Git et quand j’ai fini une fonctionnalité ou un fix je fais relire le tout par un collègue. Tout le code produit est relu, commenté, et n’est mergé que quand celui à qui est affecté la merge request n’est satisfait.

Ce système permet de produire du code bien meilleur, on sait que l’on va être relu, du coup on fait gaffe et on essaye de commenter un peu plus, de mettre des variables explicites etc…

Si jamais des erreurs se sont glissées, il y a de grandes chances que le mainteneur nous le fasse remarquer (autant sur le fond que sur la forme d’ailleurs)

Autre point positif de cette méthode, le mainteneur du code changeant tout le temps, toute l’équipe “voit passer” le nouveau code sur le projet. Cela réduit considérablement l’effort de maintenance.

Extreme Programming

Depuis plusieurs mois j’essaye de mettre en place les règles de l’extreme programming. Au programme, pair programming, ne pas sur optimiser, garder le code le plus simple possible et impliquer toute l’équipe à ces problématiques.

La mise en place des tests automatisés est au programme, mais pour le moment ils ne sont pas encore écrit.

Les retombées sont impressionnantes, l’équipe est plus motivée, le code produit est de meilleure qualité car revu de manière régulière et le pair programming permet d’abattre plus rapidement les situations de blocages – sans avoir à faire des hacks tout moches que l’on aurait tendance à faire seul dans son coin!

Code Sniffer

Enfin, dernier point plus technique, j’ai mis un code sniffer sur mon éditeur de texte préféré. Il râle si mon code n’est pas formaté comme il faut, et, du coup, je râle si le code que je récupère d’un collègue ne respecte pas les règles du standard.

Cela peut paraître anecdotique mais c’est primordial. Cela donne une base de code uniforme sur les milliers de lignes de code de nos applicatifs et cela facilite la maintenance.

3 – Je suis un être social

Autre point qui me tient particulièrement à cœur: l’échange.

Un développeur isolé est un développeur qui travaille mal.

Moi qui n’ai jamais étudié la programmation à l’école (ou très peu) j’ai toujours codé en restant en contact avec des groupes de dev qui pouvait répondre à mes question et vide versa. C’est ce que je fais avec StackOverflow, sur IRC, Twitter etc…

C’est primordial pour moi, cela permet aussi de confronter les idées, d’aller chercher les best-pratices et “d’aspirer” une quantité d’expérience bien plus importante et de manière beaucoup plus interactive qu’en lisant des bouquins!

Par exemple, il y a peu j’ai du concevoir et coder une API RESTFull avec Symfony2. Au final j’ai du passer plus de 70% de mon temps à lire des posts de blogs sur le sujet, à échanger avec des pointures sur IRC et à chercher les meilleurs design pattern et les meilleurs bundle AVANT de commencer à coder.

Seul je n’aurai pas fait un dixième du résultat final et la qualité aurait été réellement en deçà de ce que j’ai finalement produit.

Voilà en substance comment je fais pour savoir si mon code est de bonne qualité, et vous quels sont vos #proTips pour produire du code de qualité ?

 

 

Silex un framework minimaliste PHP que vous devriez tester

Silex est un micro framework édité par SensioLabs, la société qui édite le fameux framework Symfony.

Un micro Framework

Silex est micro, vraiment micro. Même l’installation tiens en deux lignes:

$ curl -sS https://getcomposer.org/installer | php
$ composer.phar install

Une fois ces deux lignes exécutées vous vous trouvez avec:

  • un répertoire vendor qui embarque Pimple, une librairie pour l’injection de dépendances et les modules de gestion HTTP de Symfony ( pour gérer les routes, les requêtes etc..)
  • un répertoire web dans lequel se trouve un fichier index contenant toute voter application (rien pour le moment)
  • et un Composer pour installer en deux coups de cuillère à pot n’importe quelle librairie super utile.
  • et… c’est tout.

Ça ne fait pas lourd, surtout quand on vient de Symfony. Mais quand on y réfléchi deux minutes avec juste ces trois éléments on peut faire beaucoup de choses.

With great power, comes great responsibility

L’architecture de base, celle que je viens de décrire est suffisante pour des petits prototypes, pour tester SIlex ou pour monter votre blog. Mais rapidement, mettre toute vote application dans index.php, voire dans le répertoire web ça devient gênant. C’est pourtant ce que vous trouverez en majorité dans les tutos sur le web.

Si votre projet est fait pour prendre de l’ampleur, pour être maintenu dans le temps par plusieurs personnes il va falloir rendre les choses un peu plus structurées.

Comme Silex n’impose rien, le développeur à le choix. Pour partir sur de bonnes bases je vous propose de partir sur le Skeleton proposé sur Github par SensioLabs: https://github.com/silexphp/Silex-Skeleton

Ça permet de découpler le cœur de l’application du modèle MVC, de séparer les parties publiques et privées. Vous noterez au passage que le composer.json de cet exemple c’est pas mal étoffé et que l’on retrouve des outils Symfony comme Twig ou la console.

L’idée n’est peut être pas pour vous de prendre tout le skeleton, mais en tout cas de s’en inspirer et monter une vraie structure compréhensible et maintenable dans le temps.

Pourquoi pas Symfony ?

J’utilise actuellement Silex parce que le projet que j’ai repris était en Silex, je n’ai pas eu le choix. Cependant je me rends à l’utilisation que Silex peut être une bonne option dans plusieurs cas :

  • Vous voulez monter en compétences sur du PHP objet, savoir vraiment fonctionne des gros framework comme Symfony. Silex est beaucoup plus bas niveau que son cousin, il vous permet de vraiment mettre les mains dans le cambouis, de comprendre comment les choses fonctionnent.
  • Vous avez du code legacy dégueu et vous voulez migrer petit à petit vers quelque chose de plus propre. C’est le cas pour mon projet. 30% du code est horrible en legacy, 30% est sur du Silex mais en mode “Tout dans le index.php” et les derniers 30% ont été codés dans les derniers mois avec plus ou moins le skeleton ci dessus. Silex fonctionne très bien dans cette configuration et nous permet de migrer controlleur par controlleur notre code.
  • Vous êtes un ayatollah de la philosophie KISS, vous ne voulez installer que ce dont vous avez besoin et ne pas avoir un prjet qui finit par embarquer des milliers de lignes de codes qui ne vous serviront jamais.

Pour être honnête, pour des gros projets, des projets à longue durée de vie je vous conseille plutôt de partir sur du Symfony, la doc est mille fois plus abondante,  la structure est fixe et donc l’effort de maintenance et d’évolution sera beaucoup moins important.

Pour le cas d’une migration lente par contre je trouve que Silex est adapté si on part sur de bonnes bases.

Dans tous les cas, Silex vaut le coup d’oeil, au moins pour un side-project. On apprends beaucoup de choses et le chan IRC dédié est d’une grande qualité !

 

Migrer SPIP vers WordPress

Il y a quelques jour on m’a confié une super mission: migrer un blog SPIP vers un WordPress!
J’ai cherché un peu partout une solution simple et clé en main. Visiblement cela n’existe pas vraiment… Il y a bien Korben qui à fait un article la dessus, mais son code n’est plus dispo.

J’ai été cherché du côté de la communauté SPIP – ils sont super sympas d’ailleurs n’hésitez pas à aller leur faire un coucou sur IRC !
J’ai trouvé un tuto pas trop mal fait qui permet d’importer le contenu brut d’un SPIP vers un blog WordPress, tout ne fonctionne pas mais ça dégrossi vraiment le travail.

 

EDIT: Apparement il y a un plugin qui fait ça maintenant  (merci kerfred)

Ensuite il faut traiter toute la syntaxe bizarre du CMS pour en faire du beau HTML. Et là j’ai pas trouvé mieux que du sql, pénible mais efficace…

Le code des requetes est dans un gist ci dessous, n’hésitez pas à le forker !

 

Pour sortir du lot mettez vous dans une niche !

Depuis que les mondes virtuels sont en baisse, que je ne peux plus vivre avec cette activité il m’a fallu changer de cap, me recycler.

Et je me suis perdu.

DSC_6698

Devant la palette de technologies, d’outils qui sont disponibles j’ai testé pas mal de trucs: NodeJS, WebGL, Ruby on Rails, WordPress, Jekyll, Symfony, Zend et à chaque fois il faut apprendre de nouveau les bases du framework, recommencer à comprendre les grands concepts etc… Si j’ai testé autant de technos c’est que j’aime ça, découvrir de nouveaux outils m’a toujours plu et, au delà du défi “geek“, ça permet aussi d’améliorer sa compréhension de l’univers du web. Mais, et c’est là que le bat blesse, ça n’a jamais fait gonfler mon portefeuille client, au contraire.

Vu de l’extérieur être un “touche à tout” est souvent pris pour du papillonnage, cela brouille les pistes pour vos futurs prospects et même si c’est excitant professionnellement c’est souvent synonyme de perte de temps – il faut réapprendre tout le temps – et de mauvaise estimation de temps passé.

Du coup, personne ne comprends vraiment ce que vous faites, et les contrats que vous remportez sont souvent mal vendus. Au final on fini par se fondre dans la masse des freelances qui “font du web”, sans réelle plus value la concurrence est rude surtout si on met dans la balance les développeurs indiens !

Bref c’est un mauvais calcul !

J’ai l’impression que la solution est de faire carrément l’inverse, choisir une techno qui nous plait, qui paraît robuste et s’y tenir. Au passage avant de foncer tête baissé, allez faire une  tour sur la timeline Twitter de l’outil, regardez les annonces de jobs, bref vérifiez qu’il y a de la demande. Dans le cas de Symfony par exemple c’est très clair : la moitié des tweets français sont des recherche de compétences !

Une fois la techno choisie, communiquez de façon hyper ciblée, spécialisée, faites vous identifiez comme un “expert” de la solution. Mettez en avant vos compétences techniques, votre expérience sur le sujet, faites du réseau en local et sur Twitter. Je vous parie qu’en quelques mois pour une techno demandée vous avez des clients.

Au passage, en l’écrivant je me dis que rien n’empêche d’avoir deux trois activités distinctes sur plusieurs technos différentes, le tout étant de garder une ligne et un discours hyper centré sur chaque projet. Le tout est d’avoir assez d’énergie pour animer 3 blogs, 3 twitters et faire de la veille sur toutes ces technos !

Voilà, cela fait longtemps que cette problématique me trotte dans la tête, j’ai d’ailleurs expérimenté l’inverse avec une “agence” montée au sein de CoworkingLille qui finalement n’a jamais marché justement parce notre discours était beaucoup trop large et que l’on avait pas de ressources commerciales suffisante pour assurer ce grand écart.

Et vous comment faites vous ? Quelle est voter solution pour sortir du lot ?

Installer un environnement de développement avec VirtualBox

Travailller avec un LAMP, ou un MAMP, installé en local c’est bien pour des petits projets, type création de thème/plugins WordPress, mais pour les projets plus conséquents avec des technos plus exotique que PHP il peut être nécessaire de virtualiser un système d’exploitation pour travailler. Je vous conseillle d’ailleurs de mettre en local le même système que votre machine de production, ça limite grandement les surprises de mise en prod !

Etape 1 : Installation de VirtualBox et de l’OS

Vous trouverez des milliers de tutos sur le web pour installer votre distribution préférée et sur la procédure d’installation de virtualbox, rien de bien compliqué. Petites remarques toutefois, préférez bien sur des OS stables genre debian, ubuntu LTS , CentOS etc… Les distributions à la mode ne sont pas forcement un choix judicieux pour une machine de production.

Limitez les ressources que vous allouez à votre machine, un OS serveur n’a pas besoin de beaucoup de ressources (256Mo de RAM et un petit de processeur devrait suffire) sinon vous allez vraiment avoir du mal à bosser dans de bonnes conditions.

Etape 2 : Configuration de l’OS

Une fois que tous vos paquets sont installés et que votre serveur virtuel tourne bien il va falloir le mettre en relation avec votre machine afin de travailler dans de bonnes conditions.

Pour l’accès je recommande un bon vieil SSH, c’est simple et efficace :

sudo apt-get install open-ssh

Pour le serveur web et le langage je vous laisse choix, nginx, apache2 ou autres, idem PHP, Ruby, Python, faites votre marché !
NB: Faites attention à bien installer la version identique à celle du serveur de production, toujours dans un soucis de compatibilité.

Etape 3 : Configuration du réseau

Ensuite, il faut pouvoir accéder à son serveur depuis son navigateur pour afficher les pages web, pour ça c’est un peu plus complexe, mais pas sorcier non plus.

D’abord rendez vous dans configuration/Réseau de votre machine virtuelle et configurer la carte 1 en NAT, et ajouter une deuxième carte en Réseau privé comme ci dessous  :

Reseau Virtualbox

Ensuite, on va configurer les interfaces réseau dans l’OS directement  – ici une debian. On édite donc  /etc/network/interfaces dans lequel on trouvera lo et eth0 nous allons ajouter eth1 à la fin du fichier :

# The host-only network interface
auto eth1
iface eth1 inet static
address 192.168.56.101
netmask 255.255.255.0
network 192.168.56.0
broadcast 192.168.56.255

Ensuite, pour des raisons pratiques nous allons donner des noms à ces serveurs virtuels pour éviter de retenir des adresses IP obscures, en éditant le /etc/hosts/ de votre machine hôte et en ajoutant :

192.168.56.101    myserver1
192.168.56.102    myserver2

Et voilà vous avez une machine de développement fonctionnelle, reste plus qu’a mettre votre framework préféfé et à installer git pour travailler en équipe !

Freelances contribuez au libre pendant vos temps morts

Dans la vie professionnelle de tout indépendant il y a des temps morts. Entre deux contrats, avant ou après avoir fait de la prospection commerciale, les moments où l’on est pas forcement débordé sont assez fréquents. Hors ce sont bien souvent ces temps là qui nous permettent de nous former, d’apprendre, de faire de la veille.

Freelances contribuez à l'opensource

Depuis quelques temps déjà j’essaye de consacrer ces temps morts à des projets opensource. Je ne le faisais pas forcement avant, mais clairement c’était une erreur pour plusieurs raisons :

Cela permet de faire de la veille active

Être développeur c’est être curieux, être capable de s’adapter aux nouvelles technologies et donc d’apprendre sans cesse. Alors, bien sur, on peut lire des tonnes de flux RSS mais la meilleure façon est encore de mettre les mains dans le code. “C’est en forgeant que l’on devient forgeron”.

Contribuer à des projets libre c’est donc se confronter à de nouveaux outils, à de nouvelles méthodes de travail mais dans une ambiance moins tendue que dans une relation client/prestataire classique. Cela peut être l’occasion de tester le framework de vos rêves de mettre les mains dans un nouveau langage etc… Le plus souvent vous êtes en plus épauler par les anciens de la communauté qui n’hésitent pas à vous donner un conseil, une astuce, une vraie aubaine quand on apprend une nouvelle techno !

Cela contribue à forger vos références et votre réputation

Mettre son temps libre à profit pour des projets opensource cela permet bien sur d’augmenter le nombre de ces compétences, de monter son expérience sur telle ou telle techno mais cela peut aussi faire une jolie référence à présenter à vos futurs clients. De plus, la réputation d’un développeur passant de plus en plus par son profil Github, contribuer à un projet Github libre, le forker, commiter faire des pull request fera monter votre activité sur le réseau social et permettra à vos clients, ou à d’éventuels recruteurs de vous trouver et de voir la qualité de votre code, vos compétences et votre implication.

Faire du libre c’est surtout aider des projets vraiment cools

Evidemment, et, à mon avis c’est le plus important contribuer au libre c’est aussi aider des projets qui en valent la peine. D’ailleurs à ce propos Github est un vrai vivier de petits projets super cools qui ont besoin d’un coup de main ! Je rappelle d’ailleurs que contribuer ce n’est pas forcement coder. En fait c’est bien souvent le reste qui fait défaut. Il y a souvent plus besoin de graphistes, d’ergonomes et de traducteurs que de développeurs. D’ailleurs contribuer ça peut tout simplement être de remonter les bugs.

Bref, la prochaine fois que vous avez un jour ou deux à tuer, sans activité réelle allez faire un tour sur Github, essayer de rencontrer les gens qui font les petits outils que vous utilisez ou tout simplement allez sur les trackeurs de bugs des géants de l’opensource – Mozilla par exemple facilite vraiment la tâche des ces futurs contributeurs – et traduisez, codez, designez, aidez vous verrez c’est beaucoup plus gratifiant, valorisant et plaisant que d’attendre les futurs clients !

 

Pourquoi vous devriez utiliser WebGL

Depuis que je travaille comme consultant et développeur dans le monde de la 3D je suis confronté à des débats sur les technos. Cela à commencé avec SecondLife, Opensim puis Unity3d, WebGL, Flash etc …
Avec des arguments plus ou moins bien choisi, mais il y a toujours cette problématique du choix de technos. Je vais essayer de vous convaincre, dans ce billet, de tester WebGL.
WebGL logo

WebG quoi ?

WebGL est une implementation d’OpenGL en javascript qui permet d’afficher de la 3d dans les navigateurs sans plugins.
C’est en fait une API qui permet au Web de “parler” à votre carte graphique et d’afficher de la 3D.
Les navigateurs qui supportent cette techno sont:
  • Chrome (desktop & mobile)
  • Firefox (desktop & mobile)
  • Safari ( sauf sur iOS)
  • Opéra (sauf iOS)
  • Blackberry browser

A noter qu’internet explorer 11 devrait supporter WebGL, c’est du moins les rumeurs qui courent sur Twitter. Autrement dit, à part iOS qui fait le blocus, vous pouvez afficher du WebGL à peu près partout pour peu que vous ayez un  ordinateur potable, avec un navigateur mis à jour ou une tablette Android.

Si on en crois le site webglstats, à l’heure actuelle près de 70% des internautes peuvent afficher du WebGL.

Comment ça marche ?

WebGL s’affiche à l’intérieur de la nouvelle balise HTML5 appelée canvas, une fois cette balise créée il suffit de lui attribuer du le contexte qui va bien

var gl = canvas.getContext('experimental-webgl');

Et, hop vous avez un carré de WebGL, le reste c’est du javascript et des shaders.

Il y a également de nombreux frameworks pour faciliter le travail, mon préféré étant Three.js.

 

Si c’est si facile pourquoi c’est aussi peu utilisé ?

Aah, la fameuse question ! Premièrement c’est utilisé un peu partout sans forcement le savoir, WebGL est utilisé par Google Street View par exemple. dans de plus en plus d’application de prévisualisation 3D, github vient d’annoncer un “STL file viewing” supporté par du WebGL, sans oublier CouldParty, clone de SecondLife entièrement en WebGL et intégré à Facebook.

Ensuite, il faut le dire, les dernières années ont été des années de développement. WebGL n’était pas forcement stable, à fait face à des soucis de sécurité assez important et les performances n’étaient pas non plus au rendez vous.

Mais les choses changent vite, l’API est passé en version 1.0 il y a quelques semaines et, pour ce qui est des performances, Mozilla à sorti la semaine dernière un portage du moteur de jeu unreal Tournament dans le navigateur en WebGl, qui contredit vraiment les critiques sur la performance de la techno !

Quels sont les concurents ?

Unity3D

C’est à mon avis le concurrent le plus sérieux, Unity est un logiciel propriétaire dédié à la création de jeux vidéos. Les jeux crées sont exportablent vers consoles, mobiles, ou vers le web via un plugin.

L’outil est vraiment efficace et permet de créer facilement des scènes 3D de jeu. Si le web n’est pas votre cible principale ou si vous voulez des jeux extrêmement complexes, foncez c’est la techno qu’il vous faut!

Flash Stage 3D

Si je voulais troller un peu je dirais que Flash n’est pas vraiment une techno d’avenir et que ça devrait suffire pour vous convaincre !

Pour être un peu plus objectif, Stage 3d n’a pas l’air vraiment documenté, demande l’installation de Flash – même si c’est standard sur la plupart des plateformes – et ne tourne pas sur mobile. Vous pouvez toujours compiler votre code en appli native, mais on sort du champs d’application de WebGL, tout comme les applis natives générées par Unity.

Silverlight 3D

C’était une idée de Microsoft, même si la firme n’a pas apporté beaucop de soutient à Silverlight et encore moins à Silverlight 3D. Honnêtement, je ne vois pas d’avenir pour cette techno, en tout cas rien qui justifie une investissement conséquent.

 Qui m’aime me suive !

Pour moi tout est réuni pour que l’on assiste dans les prochains mois à une effervescence de projets WebGL. Cette techno, encore confidentielle est entrain d’émerger, et l’implémentation sur IE11 devrait aider encore plus son essor.

Je vois de plus en plus de projets qui sortent, Sketchfab est un bon exemple de projet WebgL qui marche. Alors pas forcement sur des jeux complexes, sur des mondes virtuels mais dans un premier temps pour tout ce qui est data-visualisation, démos produits, visite virtuelle, je crois vraiment que le WebGL à sa carte à jouer.

C’est d’ailleurs pour cette raison que je me replonge, tête la première, et avec plaisir dans cette techno. Vous venez ?

Pourquoi les freelances sont aussi déprimés… ou pas

Je suis tombé hier, au fil de ma veille, sur un article de fastcompany qui a pour titre : “Why freelancers are so depressed”.

Un bon gros titre qui fait peur, qui fait buzzer et pleurer dans les chaumières, on se croirait sur TF1. Je vais me permettre dans ce billet de répondre à ce post, parce que je suis freelance depuis presque 5 ans maintenant et aussi parce les problématiques des nouvelles formes de travail m’intéressent beaucoup.

En gros l’article explique pourquoi être freelance c’est terrible en trois points, je vais les reprendre ici.

Photo depression freelance

Photo by ABC Archives – CC BY-NC 2.0

Une entreprise unipersonnelle

C’est pas vraiment un scoop mais quand on est freelance, on est … seul. A la fois “patron”, secretaire, comptable, commercial, ouvrier etc… Et il faut bien avouer que l’image de liberté que cela véhicule est un peu galvaudée.

Plus de patron, pas d’horaire, c’est vrai mais cela implique beaucoup plus que cela rapporte. Il faut se plier à une discipline, aller chercher des clients régulièrement, faire ses comptes, faire le boulot, le tout en même temps sous peine de voir son activité disparaître. On est bien libre de la faire comme on veut, mais il faut le faire.

Après des années de pratique, je pense qu’il vaut mieux payer pour externaliser des tâches – c’est le cas pour ma comptabilité par exemple. Je ne sais pas le faire, je le fais mal, pas assez souvent et en plus j’aime vraiment pas ça. Autant passer ce temps à aller chercher des nouveaux clients. Alors c’est sur ça se paye, mais je pense de plus en plus que ça vaut le coup. D’autant que le comptable donne des conseils, aiguille dans les situations délicates. Au final, avec de la pratique, on sait où aller chercher les infos et la solitude du début se fait moins sentir.

On est isolé, seul chez soi

Comme vous le savez probablement moi j’ai résolu le problème depuis 2 ans. Je vais bosser presque tous les jours au CoworkingLille j’y trouve des gens qui ont les mêmes problématiques professionelle que moi, du réseau local qui m’apporte du boulot, et un réseau social d’amis. Honnêtement, sans  vouloir la jouer guimauve, ça à changer ma vie. Je ne serait peut être même plus freelance si je n’allais bosser tous les jours au coworking.

J’ai structuré mes horaires, cadré mon activité et j’ai appris plus de choses en 6 mois que je n’en avais appris seul derrière mon pc à essayer de faire des tutos.

Travailler uniquement à la maison et malsain, je m’en rend compte maintenant. Et cela devient carrément impossible quand vous avez des enfants.

Regroupez vous ! Regroupons nous ! Pas besoin de beaucoup d’argent, pas besoin d’être dans une grande ville, juste aménagez vous un bureau avec 2-3 indépendants c’est déjà un comfort de vie et de travail incomparable ! Et vous verrez que naturellement les contacts s’organisent, que les contrats arrivent et que l’on monte des projets commun.

L’argent

C’est le nerf de la guerre, et c’est aussi le point noir de l’activité. Les problèmes d’argent sont récurrents  pour quasiment tous les indépendants. Il faut souvent “courir” après le paiement des clients. Il faut aussi accepter de vivre avec l’angoisse de la fin de mois. Être indépendant c’est accepter de vivre avec l’idée que vos revenus ne seront jamais fixe et jamais assurés. Il faut se battre tous les mois pour aller chercher des clients, faire des devis qui ne seront pas acceptés, et recommencer encore et toujours.

Le pire dans tout ça c’est que les revenus ne sont jamais, ou rarement à un niveau de salarié.

Oui, mais on est souple

Aucune mention de ça dans l’article de fastcompany, mais moi ça me paraît essentiel. C’est probablement même LE point positif de l’activité. Je pars en vacances quand je veux, je peut bosser ici ou là, peut importe. Si je veux bosser le dimanche plutôt que le vendredi rien ne m’en empêche. Et surtout, je travail sur des projets qui me plaisent, tout en consacrant du temps pour des projets persos, pour continuer à apprendre de nouvelles technos.

En conclusion, comme souvent, tout n’est pas noir ou blanc. Être freelance ça me plaît beaucoup mais il faut se battre pour exister. Cela ne rend pas depressif au contraire ce sentiment de contrôler vraiment son activité professionelle est assez plaisante. Et vous, vous vous sentez dépressifs ?

Les news de la rentrée

Mon blog est en sommeil depuis plusieurs mois. Je le sais, ce n’est pas une volonté de ma part mais plus un manque de temps. Dur de tenir le rythme d’article que je m’étais imposé depuis son lancement. J’ai été pas mal occupé durant l’été, pas mal de changement et des projets en cours !

3 mois de changements à rattraper en un post cela ne va pas être facile, je vais essayer de faire court :

 

Changement de statut juridique

C’est probablement le plus gros changement de la rentrée. Après presque 4 ans de bon et loyaux services j’ai décidé de mettre fin à mon auto-entreprise. Je n’ai jamais été vraiment à l’aise avec ce statut pour être franc. Si, au départ, à la signature. C’était simple et rapide. Ensuite on se rend compte que créer une entreprise même “auto” ça n’a rien de simple, que ça demande de l’implication et du temps… D’autant plus que j’étais un des premiers auto-entrepreneurs et que , du coup, j’ai un peu essuyé les plâtres de leur statut révolutionnaire !
De toute façon, depuis quelque mois je m’y sentais franchement à l’étroit. Que ce soit pour l’impossibilité de sous traiter ou la dispense de T.V.A. Le fait est que mon activité à beaucoup  évoluée depuis que je bosse depuis le @CoworkingLille. J’y ai tissé un réseau qui me demande souvent de travailler en équipe, de sous traiter justement. La plupart de mes projets web demande de collaborer avec une ou plusieurs personnes et à chaque fois je retombe sur le même problème : celui d’être chargé sur mon chiffre d’affaire…Et, on a beau dire, ce statut ne fais pas très sérieux. Encore moins quand on va vendre, et ce fut mon cas, des solutions à des très grosses entreprises !

Je réfléchissais à ce changement depuis au moins un an sans trop savoir quoi choisir, sans vraiment me décider.

Finalement j’ai opté pour le statut d’entrepreneur salarié proposé par Grands Ensemble. C’est un statut qui ressemble à celui du portage salarial, sauf que GE est une coopérative, donc il y a du social, de l’accompagnement et beaucoup de réseau local potentiel. Ce nouveau régime m’a séduit pour plusieurs raisons :

  • Le statut de salarié. Je n’ai jamais vraiment voulu être salarié, en CDI, ça ne me correspond pas vraiment. J’aime la liberté qu’apporte le statut de freelance mais il faut reconnaître que du coté prestations sociales et retraite ce n’est pas vraiment ça. A moins de payer des assurances/contrats prévoyance très chères la couverture médicale et les prestations retraites sont à des années lumières de celle d’un salarié. Quand on est jeune tout va bien, mais quand on chope un problème de santé ça fait un peu réfléchir…
  • Le suivi. Tout les mois j’ai rendez vous avec un comptable qui me fait le bilan de mon activité et me propose des directions pour améliorer la gestion de l’entreprise. Au sein de la coopérative je cotise aussi au droit à la formation (DIF), et ce n’est pas négligeable surtout dans un monde comme celui du Web qui bouge tout le temps. Où il faut bien souvent choisir entre faire de la veille, se former ou travailler pour facturer.
  • Enfin, dernier point, plus personnel, GE est dans une dynamique qui converge avec celle du coworking et celle d’un projet dont je vous parlerais plus bas. Cela m’a convaincu à franchir le pas.

Lancement de Maintenant Au Travail !

MAT!  est un projet qui tourne dans la tête de quelques coworkers depuis longtemps. C’est une idée qui part d’un constat simple : les coworkers, presque tous freelance, ont toujours des trous dans leurs emplois du temps. Ce temps disponible est inhérente à  leurs activités mais c’est plus une contrainte qu’un choix. Tous sont experts dans leur domaine, suffisamment pour en vivre par eux mêmes, mais ils sont confrontés aux mêmes problèmes que tous les freelances, ils ne sont pas forcement perçus comme fiable pour de gros jobs et son bien souvent trop “petit” pour assumer les gros projets. Du coup ils naviguent plus ou moins à vue de petits projets en petits projets.

L’idée est donc simple : monter une structure d’accompagnement de projet la plus légère possible pour pouvoir aller chercher des projets sur la durée et les faire réaliser par les freelances pendant les “trous” de leur emploi du temps.

Ainsi on garde un tarif équivalent à celui d’un free et on rajoute de la gestion de projet, une vraie prestation commerciale, une relation client suivie et toute l’assurance que peut amener une “vraie” entreprise. Du côté du coworker c’est tout bénef’, il comble son emploi du temps avec des tâches clés en main et payées suivant un tarif commun.

Le client, lui, est aussi gagnant car il gagne clairement en flexibilité. Il peut décider à tout moment de ne pas refaire son logo mais de plutôt traduire son site web en Japonais par exemple. Il suffit d’enlever @curlybushman du projet et de le remplacer par Makiko par exemple. M.A.T! se base sur de la gestion de projet agile donc ça ne pose pas de soucis, il suffit juste de changer deux trois post-it sur  le kanban! Et à plus de 70 coworkers inscrit à @CoworkingLille il y a un nombre presque infini de combinaisons !

Ce projet est porté par @Manuduv et me tiens vraiment à coeur. J’ai vraiment l’impression que cette forme d’organisation peut permettre de faire du business dans une VRAIE démarche gagnant-gagnant, sans bullshit.

Tout ça mériterait bien plus que ce simple paragraphe mais, ne vous inquiétez pas, je vous en reparlerai au fil des projets et, notamment, au moment de la mise en place du workflow.

Le site de MAT! devrait sortir sous peu, en attendant il y a un compte twitter : @NousSommesMAT

 

Deux projets qui devraient sortir bientôt

Le premier vous le connaissez déjà, il s’agit de Dentallife. J’avais mis en place avec @bill_walach la version 1 il y a quelques mois. Et bien la V2 est sur les rails avec un outil de création de scénario en langage naturel crée par l’ami @WoldenAvro. Moi je m’occupe de toute la partie code LSL et ce n’est pas de tout repos.Quand on a connu des langages plus évolués comme Javascript ou PHP  c’est vraiment dur de ce remettre à coder dans un carcan aussi petit que du LSL. Ceci dit je prends beaucoup de plaisir à bosser pour ce projet qui me plaît :)

Le deuxième, je ne crois pas vous en avoir parlé encore. Il s’agit d’un projet web, un outil métier par excellence avec de l’appli tablette en HTML5, un backoffice plein d’ajax et autres qui m’occupe depuis pas loin d’un an. C’est d’ailleurs ce projet qui m’a mis au PHP de manière sérieuse. Il devrait sortir sous peu – si tout va bien. Je ferais un article pour le présenter un peu plus en détail !

Donc grosse rentrée pour moi, pleine de projets de nouvelles technos à tester et toujours plus de collaboratif.

Onward !

 

Older posts

© 2016 AngeZanetti.com

Theme by Anders NorenUp ↑