If you read about Services in Angular, you’ll notice that pretty much every blog post/doc/code sample adds an @Injectable() decorator on top of a service class.

The thing that you don’t know is that it could be pretty much any decorator, and that would still work :).

Let’s take an example:

@Component({
  selector: 'ponyracer-app',
  template: '<h1>PonyRacer</h1>'
})
export class PonyRacerAppComponent {
  constructor(private appService: AppService) {
    console.log(appService);
  }
}

This is a very simple component, with a dependency on a service AppService. The service looks like:

export class AppService {
  constructor() {
    console.log('new app service');
  }
}

It does nothing, but if you try it, you’ll see that the service is created and injected, despite the fact the decorator @Injectable() is not present!

Why does that work? Let’s check the JavaScript generated from these TypeScript classes:

var AppService = (function () {
    function AppService() {
      console.log('new app service');
    }
    return AppService;
}());
exports.AppService = AppService;

I skipped a bit of generated code to focus on the interesting part. The class AppService generates a pretty simple JavaScript. Let’s compare that to the PonyRacerAppComponent class:

var PonyRacerAppComponent = (function () {
    function PonyRacerAppComponent(appService) {
        this.appService = appService;
        console.log(appService);
    }
    PonyRacerAppComponent = __decorate([
        core_1.Component({
            selector: 'ponyracer-app',
            template: '<h1>PonyRacer</h1>'
        }),
        __metadata('design:paramtypes', [app_service_1.AppService])
    ], PonyRacerAppComponent);
    return PonyRacerAppComponent;
}());

Wow! That’s much more code! Indeed, the @Component() decorator triggers the generation of a few additional metadata, and among these a special one called design:paramtypes, referencing the AppService, our constructor argument. That’s how Angular knows what to inject in our Component, cool!

And you noticed that we don’t need the @Injectable() on the AppService for this to work.

But let’s say that now, our AppService has a dependency itself:

export class AppService {
  constructor(http: HttpService) {
    console.log(http);
  }
}

If we launch our app again, we’ll now have an error:

Error: Can't resolve all parameters for AppService: (?).

Hmm… Let’s check the generated JS:

var AppService = (function () {
    function AppService(http) {
        console.log(http);
    }
    return AppService;
}());
exports.AppService = AppService;

Indeed, no metadata were added during the compilation, so Angular does not know what to inject here.

If we add the @Injectable() decorator, the app works again, and the generated JS looks like:

var AppService = (function () {
    function AppService(http) {
        console.log(http);
    }
    AppService = __decorate([
        core_1.Injectable(),
        __metadata('design:paramtypes', [http_service_1.HttpService])
    ], AppService);
    return AppService;
}());
exports.AppService = AppService;

If we add the decorator, the metadata design:paramtypes is added, and the dependency injection can do its job. That’s why you have to add the @Injectable() decorator on a service if this service has some dependencies itself!

But the funny thing is that you could add any decorator. Let’s build our own (useless) decorator:

function Foo() {
  return (constructor: Function) => console.log(constructor);
}

@Foo()
export class AppService {
  constructor(http: HttpService) {
    console.log(http);
  }
}

The @Foo() decorator does not do much, but if we check the generated JS code:

var AppService = (function () {
    function AppService(http) {
        console.log(http);
    }
    AppService = __decorate([
        Foo(),
        __metadata('design:paramtypes', [http_service_1.HttpService])
    ], AppService);
    return AppService;
}());
exports.AppService = AppService;

Wow, the metadata were generated! And indeed, the app still work perfectly!

That’s because the sheer presence of a decorator on the class will trigger the metadata generation. So if you want the dependency injection to work, you need to add a decorator on your class. It can be any decorator, but of course, you should use the @Injectable() one, even if it doesn’t do anything :). The best practice is to add it on every service, even if it doesn’t have any dependencies on its own.

Check out our ebook and Pro Pack if you want to learn more about Angular!


Cédric Exbrayat


Ninja Squad books


Become a ninja with Angular 2
Cover of ebook Become a ninja with Angular 2

Pay what you want and support charity!


Devenez un Ninja avec AngularJS
Couverture du livre Devenez un Ninja avec AngularJS

Passez de débutant à ninja en AngularJS 1.4 avec un ebook à prix libre et pour une bonne cause !


Ninja Squad books



Formations

Angular 2

05-07 déc. à Paris
12-14 déc. à Lyon
23-25 jan. à Paris
06-08 mar. à Paris
03-05 avr. à Lyon


Suivez-nous


Le jeudi 24 novembre 2016, Agnès Crépet et Cyril Lacote assuraient la keynote d’ouverture de Codeurs en Seine 2016 : Codeurs du Monde.
L’équipe d’organisation leur avait demandé de raconter l’expérience de leur tour du monde.

En voici la retranscription.

Cette diapositive de titre devient extrèmement cocasse quand on réalise qu’elle montre des développeurs Java sur l’île de Java. Ha ha.

Que racontent Agnès Crépet et Cyril Lacote ?

Agnès Crépet est développeuse, Java Champion, membre active de Duchess France, ex-organistratice du LyonJUG, et co-fondatrice de la conférence Mix-IT à Lyon.

Cyril Lacote est dévelopeur Java. Après 10 ans de prestations en SSII, voulant travailler à l’étranger avec Agnès, il a cru trouver un job de rêve chez Google à Londres. Contre toute attente, il n’y resta qu’un mois, avant de s’enfuir (on en reparlera).

Il participe aussi à l’organisation de la conférence Mix-IT (dont il portait ce jour un t-shirt, en complète indécence et irrespect pour Codeurs en Seine qui les recevait).

Agnès et Cyril se lancent alors dans un jeu de question-réponses pour sortir le public de leur léthargie (et surtout se déstresser un peu en cachette). L’audience est-elle heureuse, dans leur vie personnelle (mais on s’en fout complètement) ou dans leur job ?

Il s’avéra que oui, l’audience était plutôt heureuse.

En 2011, Agnès et Cyril sortaient ainsi d’une dizaine d’années de développement. Même un job dans une boîte de rêve comme Google ne fut pas l’idéal. Alors libres de toute contrainte et attache, ils ont décidé de partir faire un Tour du Monde, pour voir comment c’était ailleurs.

Pourquoi attendre 5 ans pour en parler ? Parce qu’entre temps ils ont essayé de survivre à la naissance de deux enfants rapprochés (et ce n’est pas une mince affaire). Et maintenant, ils ont le recul pour constater combien cela les a marqué, quelles leçons ils en ont tirées, et lesquelles ont été fructueuses.

Est-ce que vous reconnaissez ce minuscule pays de l’Afrique de l’Ouest ? Non, ce n’est pas le Bénin, mais son voisin le Togo.

Togo, Malaisie, Indonésie, USA, Suède. Voici les pays que traversera cette présentation. Dans leur tour du monde, ils sont aussi passés en Thaïlande, à Bali, en Australie, et en Nouvelle-Zélande, mais comme ils n’ont fait que profiter du pays, ils n’en parleront pas (même si ça vaut le coup).

Ils n’avaient pas envie de voyager qu’en touristes. Ils voulaient rencontrer des gens, et notamment des dévelopeurs. Alors ils ont fait ce qu’ils savaient faire : enseigner du Java et partager leur expérience de développeur dans différents meetups. Ils étaient souvent nourris et logés en échange de leurs formations, ce qui leur convenait parfaitement.

Agnès, alors très impliquée dans la communauté Duchess France, n’a pas pu s’empêcher de faire aussi un peu de prosélytisme, en aidant au montage de deux antennes locales : Duchess Africa et Duchess Indonésia.

Quelques faits marquants glanés autour du monde

Nous voilà partis pour un Tour du Monde en 15 minutes (record battu), où l’audience sera emportée dans un maelström d’anecdotes exotiques, tout à la fois savoureuses et pertinentes (espérons-le).

Direction Lomé, la capitale du Togo en Afrique de l’Ouest.

À Lomé, ils ont fait la rencontre d’Horacio, alors leader du TogoJUG, et depuis devenu un ami. Il leur proposait de faire un talk un samedi matin, dans un campus universitaire éloigné de la capitale. C’était à deux heures de taxi, et cela coûtait une journée de salaire local pour venir. Ils pensaient n’y trouver que quelques personnes : une soixantaine firent le déplacement ! On leur racontait alors que ce n’était pas étonnant : JCertif, la grosse conférence Java d’Afrique Centrale (leur Devoxx), accueillait des centaines de personnes faisant jusqu’à 3 jour de voyage pour y assister. Et traversaient parfois à pied l’imposant fleuve baignant le palais des congrès pour ne pas rater de conférence ! Une motivation qu’on aurait bien du mal à retrouver en France.

En France, Agnès et Cyril s’occupaient alors du LyonJUG. S’ils avaient organisé une session un samedi matin à Villeurbanne (la ville d’à-côté), ils n’y auraient probablement vu que 5 personnes maximum.

Sur Lyon, les communautés techniques sont fédérées par LyonTechHub, qui publie un calendrier de tous les meetups. Il y a un meetup chaque jour de la semaine, voir plusieurs. S’il est formidable de constater ce foisonnement des communautés, certaines peinent parfois à trouver leur public. Alors réjouissons-nous de cette richesse, là où d’autres n’ont droit qu’à très peu d’animations.

Agnès et Cyril étaient accueillis par une entreprise au Togo, où ils devaient former au Java de nouveaux embauchés. Ni l’entreprise, ni les élèves, n’étaient togolais : ils étaient tous de la Côte d’Ivoire. Mais l’entreprise les avait exfiltrés pour fuir la guerre civile sanglante qui ravageait le pays après la dernière élection présidentielle (pro-Gbagbo vs pro-Ouattara). Et une vraie guerre civile, avec des individus tués juste parce qu’ils étaient un peu enveloppés, comme le président sortant, qu’ils devaient donc nécessairement soutenir.

Ces élèves se retrouvaient ainsi dans un pays étranger, certes en sécurité, mais avec leur famille restée au pays. Autant dire qu’ils n’étaient pas pleinement sereins et concentrés pour suivre leur formation, jetant régulièrement un œil sur l’actualité de leur pays d’origine et prenant régulièrement des nouvelles de leurs proches.

En France, la plus violente des dernières guerres civiles en date a vu l’affrontement des partisans de l’appellation chocolatine, opposés à l’appellation pain au chocolat (qui est évidemment la bonne).

Encore une fois, réjouissons-nous des conditions de paix et de sérénité dans lesquelles nous avons la chance de pouvoir apprendre et travailler.

Leur copain Horacio leur expliquait aussi que les entreprises IT togolaises et africaines en général ne faisaient confiance qu’aux consultants blancs, et n’écoutaient pas les suggestions de leurs employés locaux. Elles préfèrent ainsi payer 2000€ par jour l’intervention d’un européen, alors que le SMIC mensuel n’est que de 50€ au Togo.

Certains occidentaux n’hésitent donc pas à s’expatrier, jouissant d’un pouvoir d’achat absolument considérable, avec une immense résidence, et 12 domestiques, de la cuisinière au chauffeur. Voilà un bel exemple de néo-colonialisme.

Même les startups africaines recrutent des blancs comme faire-valoir pour que leur proposition commerciale soit simplement écoutée. Leur copain Horacio, qui cherchait alors à créer son entreprise, leur a même demandé de jouer ce rôle pour lui. Malgré l’inconfortable culpabilité de ne pas aider leur ami, ils ont préféré refuser de participer à ce système.

En France, nous ne pouvons pas trop faire les malins : dans de nombreuses grosses entreprises, seuls certains consultants référencés ont leur mot à dire sur la stratégie ou l’architecture applicative, et les équipes de développeurs internes sont ignorées sur ces sujets importants. Plus le costume est cher, plus la voix est importante.

Après Lomé au Togo, nous nous envolons pour Kuala Lumpur en Malaisie (c’est rigolo c’est apparemment à la même latitude, traçant une ligne parfaitement parallèle à l’équateur). Bon, en vrai, ce n’est pas commme ça que le voyage s’est déroulé : entre ces deux destinations, Agnès et Cyril ont profité d’un long moment de détente en Thaïlande. Mais faute d’anecdote liée au développeur, ils n’en parleront pas.

Donc, Kuala Lumpur. À l’époque, ils ne connaissaient absolument rien de cette ville (Mission Impossible III n’était pas encore sorti), et n’avaient aucune image en tête. Et ce nom de Kuala Lumpur leur évoquait un exotisme absolu, genre temple d’Indiana Jones avec des singes dans la jungle.

Il s’est avéré que ce n’était pas tout à fait le cas.

Kuala Lumpur s’est révélée être une copie asiatique (et musulmane) de Londres, où les temples sont des tours de verre au service des dieux de la finance et du commerce.

Donnant une session au MalaysiaJUG, ils ont pu observé la richesse de l’université, et les conditions exceptionnelles auxquelles avaient droit les étudiants.

Bien loin de celles qu’ils avaient connues en France…

Voici l’INSA de Lyon, école d’ingénieur au top de leur région. Comme toute université française : murs décrépis, bancs cassés et moyens dérisoires.

Autre anecdote plus personnelle : Agnès et Cyril viennent de faire entrer leur plus grand fils Marius, 3 ans, à l’école maternelle. Alors qu’ils pensaient que Marius faisait ses premiers pas sur le long chemin serein de la vie, ils découvrent qu’ils seront plus de trente enfants entassés par classe, avec des peintures écaillées, des morceaux de plafond qui tombent, et un sol amianté (conseil de la mairie : “s’il ne frottent pas trop leurs pieds c’est sans danger”). Voici les moyens assignés à l’éducation publique en France. C’est assez pathétique, et peu rassurant sur l’avenir de la République.

Plus petit trajet de notre histoire : direction Jakarta, en Indonésie. Un véritable enfer urbain (plus de 25 millions de personnes en 2012), pollué par un trafic routier cauchemardesque.

Dans cet enfer, Agnès et Cyril ont rencontré deux jeunes femmes, Nety et Mila. Elles n’avaient pas 20 ans et menaient de front leurs études universitaires, une création d’entreprise, et quatre heures de transport quotidiennes. Régulièrement, elles prenaient leur scooter pour sillonner l’île de Java, dans des road trips pédagogiques où elles initiaient des jeunes au code.

Impressionnantes de motivation et d’énergie.

En France, les étudiants de 20 ans semblent moins préoccupés par leur avenir. Et consacrent en général leur temps libre à d’autres loisirs moins constructifs. N’est-ce pas Agnès ? (elle écumait alors les bars et les concerts).

Voici les élèves à qui ils donnaient des cours à l’Université de Jakarta. Et si vous regardez bien cette photo, vous y observerez une autre surprenante caractéristique de l’IT en Indonésie : une parité homme/femme exemplaire. Sans connaître les statistiques exactes, c’est bien ce qu’Agnès et Cyril ont constaté partout où ils sont allés.

Alors qu’en France, vous avez dû faire le même constat : c’est plutôt la bromance.

Cyril fait de la prestation informatique depuis 15 ans, et a dû travailler avec 150 personnes. Et probablement que 139 étaient des mâles trentenaires, blancs et hétéro. En gros, la seule développeuse qu’il a rencontrée, il lui a fait deux enfants…
C’est un peu exagéré, mais les développeuses qu’il a croisées doivent se compter sur les doigts d’une main (coucou Pierrette, coucou Daphné).

On a donc dans l’IT français un sacré problème de diversité. Et encore, le terme de diversité est mal choisi. “Diversité” sonne comme un luxe facultatif qui apporterait une petite touche d’exotisme charmant à l’équipe. Non, c’est juste un put*in de problème de représentativité : l’IT n’est pas à l’image de la France.

Voilà maintenant qu’on s’envole pour San Francisco, Californie, USA, capitale de l’informatique mondiale, siège des Google, Twitter, Facebook, Uber et AirBnb.

Agnès et Cyril y ont rencontré quelques stars qu’ils interviewaient pour un podcast (depuis abandonné) :

  • Romain Guy, un googler d’origine lyonnaise, qui a codé l’essentiel de l’UI de vos téléphones Android 
  • Pamela Fox, ancienne developer advocate de Google, alors chez Coursera, qu’ils ont fait venir à Mix-IT 
  • Malte Ubl, depuis devenu le tech lead de AMP, la technologie de Google pour rendre instantané le rendu des pages web sur mobile.

Ces gens travaillent dans un cadre merveilleux, pour des sociétés financièrement généreuses, et impactent des milliards de personnes. Pourtant, tout n’est pas idéal. C’était l’époque où les navettes Google (qui transportent leurs employés de San Francisco au siège de Mountain View à une heure de route) commençaient à se faire caillasser par la population qui leur reprochait la terrible gentrification de la ville.

Même avec une très bonne rémunération, Romain Guy a eu du mal à trouver une maison dans la Silicon Valley pour loger sa famille agrandie, il lui a fallu trois ans : quand une annonce paraît, des chinois débarquent dans l’heure qui suit avec des valises de liquide, contenant 500.000$ de plus que l’exorbitant prix demandé, et achètent sans visiter…

À Saint-Etienne, il n’y a peut-être pas Twitter ni Google, mais ça ne saurait tarder grâce à la French Tech. Non j’déconne. On n’est pas là pour troller sur la French Tech.

A Saint-Etienne, il n’y a peut-être pas Twitter ni Google, mais au moins l’immobilier n’est pas aussi tendu : moins de 1000€ le mètre carré. Quand Agnès et Cyril sont revenus de leur voyage sans aucune possession, et qu’ils prévoyaient la création de leur entreprise sans garantie de succès, et la procréation d’enfants dont ils ignoraient tout du coût de gestion, ils se sont alors installés à Saint-Etienne pour éviter d’ajouter la pression immobilière à leurs projets. L’aventure était alors financièrement plus sereine.

Direction Stockholm, en Suède. Ce n’était pas vraiment dans le cadre de leur tour du Monde, mais ils y sont allés récemment (en repérage pour peut-être s’y installer avec leurs enfants).

À Stockholm, Agnès et Cyril ont croisé un expatrié français depuis 8 ans (il travaille depuis chez Spotify, la boîte cool du coin). Il avait débarqué en Suède avec un enfant en très bas âge. Lors de son premier jour de travail, son manager passe près de son bureau à 17H, et lui demande ce qu’il est en train de faire.

— Et bien je travaille.
— Je croyais que tu avais un bébé à la maison.
— Heu oui, c’est ça.
— Et bien tu ne devrais pas être là. Rentre vite t’en occuper.

En Suède, on ne rigole pas avec la parité. Le partage des tâches domestiques et familiales n’est pas seulement conseillé, c’est surtout très mal vu que le père ne s’occupe pas suffisamment de ses enfants. Au point de se faire engueuler par son manager si un jeune papa reste après 17H au travail.

En France, et dans la plupart des pays occidentaux semble-t-il, ce n’est pas vraiment cet esprit.

Ce dessin (qui a été piqué à un inconnu sur Internet) représente assez bien l’état d’esprit traditionnel :

  • Tu peux avoir de l’argent et du temps libre, mais il ne faut pas avoir d’enfant, ou ne pas s’en occuper.
  • Tu peux avoir de l’argent et des enfants, mais tu n’auras alors pas de temps libre.
  • Tu peux avoir du temps et des enfants, mais tu n’auras probablement pas trop d’argent, avec un temps partiel.

OK, et après ?

Montrons combien les présentateurs ont fait preuve d’une clairvoyance éclairée pour forger leur destin.

S’ils avaient flippé de partir en long voyage sans salaire, Agnès et Cyril ont finalement réalisé que c’était très facile sans enfants. Alors, profitez-en tant qu’il est encore temps pour vous !

Le tour du Monde terminé, la question était maintenant de savoir quelles leçons ils allaient en tirer pour leur retour à la réalité professionnelle.

Agnès et Cyril ne voulaient plus être salariés, et encore moins en SSII, où on leur expliquait que le développement était une tâche à faible valeur ajoutée, et qu’il fallait penser à faire un vrai métier rentable : remplir des chiffres dans des cases Excel. :’(

Une des premières phrases du droit du travail indique qu’il s’applique uniquement s’il y a un rapport de subordination entre l’employé et l’employeur. Ainsi, le travail, après lequel court toute la société depuis des décennies (pour réduire le chômage et retrouver le plein-emploi), est fondamentalement une relation de subordination. Un employeur fera du chantage à l’employé : tu n’auras ton salaire que si tu fais cette tâche ingrate. Agnès et Cyril ne voulaient plus de cette subordination, et voulaient rester libres de choisir leur travail, et pour qui ils travaillaient.

Les entreprises libérées sont d’ailleurs à la mode. Mais aussi libérée que soit une entreprise, la relation de subordination fait qu’aucun salarié non actionnaire n’a un droit de regard sur le destin de l’entreprise. Un exemple récent est celui d’Octo. Si Agnès et Cyril ne connaissaient pas vraiment Octo, elle semblait une SSII plutôt cool, avec des employés pointus et reconnus. Mais du jour au lendemain, elle fut rachetée par Accenture. Reste à voir comment cela évoluera, mais il est fortement probabable que l’ambiance change du tout au tout, et que la stratégie d’Octo ne soit plus vraiment la même. Ainsi, ce n’est pas parce que tu adhères aux valeurs de ton entreprise que tu seras maître de son destin.

Agnès et Cyril ne veulent pas non plus dire que travailler dans une grosse société est forcément un échec. Mais eux-mêmes avaient du mal à imaginer des alternatives satisfaisantes. Alors ils veulent aussi présenter celle à laquelle ils sont arrivés.

Ils cherchaient donc une alternative au salariat. L’évidence est de se lancer en freelance. Mais cela ne leur convenait pas vraiment. Ils voulaient construire un projet collectif. Tout en sachant qu’ils n’étaient que des développeurs sans aucune autre compétence, perdus vers Saint-Etienne, et qu’ils ne voulaient ni locaux, ni managers, ni commerciaux.

Avec deux autres développeurs (bisous Cédric, bisous JB), ils se sont alors lancés dans une société coopérative : un homme = une voix, tous égaux, tous actionnaires. La transparence était aussi une valeur qui leur tenait à cœur. Malgré des écarts d’âge prononcés, ils ont décidé d’adopté un modèle de salaire encore plus simple que la fameuse grille de Buffer : tous le même salaire (2500€ net, et ils se partagent le reste à la fin de l’année, ce qui représenta quand même un bonus de 18 000€ nets pour chaque ninja l’année dernière). La grille de salaire de Ninja Squad est d’ailleurs aussi publique :)

Avec le recul, quatre ans après, est-ce que cela a fonctionné ?

Déjà, ils cherchaient une alternative au salariat. Le problème n’était pas tant le salariat que la relation de subordination induite. Ainsi, dans Ninja Squad, ils ont volontairement choisis d’être salariés, car leur statut de SAS le permettait, et ils voulaient par conviction participer au système social par répartition.

Au début, les commerciaux de leurs précédentes SSIIs ricanaient : “vous allez vous planter en beauté”.
Et certains leur prophétisaient une déconvenue : “avec un nom comme Ninja Squad, vous allez vraiment passer pour des guignols”. Avec le recul, bien qu’ils étaient loin de l’avoir calculé, le nom et l’esprit débridé assurent un excellent filtre. Si les grosses entreprises scélérosées (banque, assurance, grande distribution) ne veulent pas travailler avec ces guignols, c’est finalement tant mieux : ils ne veulent pas non plus travailler pour eux. Les quelques clients qui font la démarche de venir les voir sont déjà probablement des gens avec qui ils auront des affinités.

Le plus grand luxe d’avoir sa propre société c’est aussi de choisir ses clients, et refuser de travailler pour ceux dont on ne partage pas l’éthique. Après avoir éprouvé de l’empathie pour certains parcours de vie autour du monde, et après avoir fait des enfants, il y a certaines activités qu’on a encore moins envie d’encourager.

Quand on travaille en SSII, la SSII d’à côté est une concurrente, à qui il faut plutôt faire des croche-pieds que des bisous. Sans avoir d’explication formelle, il s’avère que dans leur petit monde des sociétés coopératives, l’entre-aide est plutôt de mise. En 2013, avec leurs amis de Scopyleft et de Lateral Thoughts, ils avaient animé un BoF à Devoxx sur les NoSSII (NoSSII : Not Only SSII). Depuis, ils se retrouvent sur un Slack. Et l’échange de tuyaux, de bons plans, et de missions, est toujours d’actualité.

Être libre dans sa société, c’est aussi maîtriser complètement son temps de travail, et définir l’équilibre avec la vie personnelle qui convient à chacun. Google est célèbre pour ses 20% de temps libre, et Ninja Squad fait vraiment pareil : ils ne facturent que 4 jours par semaine, et se gardent le vendredi pour travailler sur ce qu’ils veulent. Ce n’est pas toujours très sexy (il y a parfois de l’administratif, notamment la gestion des formations avec nos chers dinosaures du FAFIEC), mais au moins ont-ils du temps réservé pour cela.

Un autre avantage peut-être anecdotique d’avoir sa propre société est que cela résout un bête problème d’image. Quand vous avez votre entreprise, unipersonnelle ou non, il faut en assurer la promotion. Si les clients ne savent pas que vous existez, ils ne viendront pas vers vous. Ainsi, si vous êtes freelance, c’est en votre nom propre qu’il vous faut faire du marketing : “Oh la la qu’est-ce que je suis fort, j’ai encore fait ce projet, je parle encore à cette conférence”. Si vous avez une vraie société, avec son image, il suffit alors d’en dire tout le bien que vous voulez : votre humilité est sauve, vous ne parlez pas de vous. Vous avez transformé le personal branling en corporate branding !

Comment faire alors pour se lancer ? Est-ce compliqué ?

Et bien non ! Agnès, Cyril, et leurs collègues ninja Cédric et JB n’y connaissaient rien. Il leur a suffit de payer 1500€ un cabinet prestataire pour se faire interviewer sur la teneur des statuts qui leur convenaient, et assurer la création de la société.

La vraie difficulté, la plus importante, est de trouver les bonnes personnes qui feront les bons associés. Les gens qui resteront vos copains quand le sujet de l’argent arrivera sur la table. Il faut donc trouver les gens avec qui vous partagez vraiment les bonnes valeurs, et qui sont aussi vos complémentaires. Facile à dire, bien plus difficile à trouver.

Dans Ninja Squad, ils ont eu beaucoup de chance. Agnès et Cyril avaient rencontré Cédric dans l’associatif, et avaient travaillé avec lui dans ce cadre (LyonJUG, Mix-IT). Comme quoi, participer à la vie des communautés techniques est important ;). Ils avaient travaillé avec JB dans le cadre professionnel. Mais JB et Cédric ne se connaissaient pas. Ce dernier dit d’ailleurs : “ça n’avait aucun sens de monter une boîte avec un mec avec qui j’avais juste bu une bière en 5 minutes”. Mais ils ont finalement eu la chance incroyable d’être à la fois complémentaires et compatibles.

Un dernier point important avant de se lancer : trouver un bon comptable, parce vous allez passer beaucoup de temps avec lui. Alors mieux vaut trouver quelqu’un avec qui vous vous entendez bien, et qui vous mâchera le travail si la comptabilité n’est pas votre passion… Mais vous pourrez toujours changer par la suite.

Avec tout ça, dans le monde du développement où il y a tellement de travail insatisfait, il n’y a aucune raison que cela ne fonctionne pas, si vous travaillez correctement. Et avec peu de charges (pas de locaux, pas de commerciaux, pas de managers à payer), il est probable que vous viviez très bien.

Une conclusion subtile et inspirante

Voici, enfin, la conclusion, où apparaît soudainement, après un moment de flou, combien cette présentation est finalement bien construite et inspirante (normalement).

Donc, pour reboucler avec l’introduction, pourquoi est-on heureux ?

Agnès et Cyril sont tombés sur un TEDx de Jérome Bonaldi sur le bonheur. Il présentait différentes études statistiques qui ont permis de discriminer les facteurs influants sur le bonheur. Et le facteur le plus influent n’est pas celui qu’on pourrait croire.

Est-ce que les enfants et la famille contribuent au bonheur comme on le croit instinctivement ? Pas du tout !

On peut être parfaitement heureux ou malheureux avec ou sans enfant.

Est-ce que la religion aide ? Non plus !

Après, il y a les facteurs évidents, comme la santé. On sera évidemment plus heureux si on est en bonne santé.

Le cadre de vie joue aussi. On sera plus heureux dans un joli endroit qu’en vivant au bord d’une décharge.

Le niveau de vie contribue aussi : on sera évidemment plus heureux si on a les moyens de manger ce qui nous plaît, et de s’offrir quelques loisirs.

Mais enfin, le facteur le plus universel qui contribue le plus au bonheur est le sentiment d’avoir le contrôle de sa vie (empowerment, comme disent les américains).

Quelqu’un qui pense que sa vie est la faute du gouvernement ou de ce salaud de patron sera fondamentalement moins heureux que celui qui pense qu’il est maître de son destin. Il n’est même pas question de pouvoir vraiment, factuellement, changer sa vie, il est juste question de le penser !

Alors, vous qui êtes développeurs, dans ce monde où vous êtes tant recherchés, il est temps de prendre en main votre destin pour construire votre bonheur.

Les feedbacks

Un article suite à une interview paru dans le journal régional Paris-Normandie : Codeurs en Seine à Rouen : le métier de développeur web a de beaux jours devant lui.

Les tweets :


Cyril Lacôte


Ninja Squad books


Become a ninja with Angular 2
Cover of ebook Become a ninja with Angular 2

Pay what you want and support charity!


Devenez un Ninja avec AngularJS
Couverture du livre Devenez un Ninja avec AngularJS

Passez de débutant à ninja en AngularJS 1.4 avec un ebook à prix libre et pour une bonne cause !


Ninja Squad books



Formations

Angular 2

05-07 déc. à Paris
12-14 déc. à Lyon
23-25 jan. à Paris
06-08 mar. à Paris
03-05 avr. à Lyon


Suivez-nous


Angular is moving fast, and we already have a minor release: 2.2! This contains the changes from Angular 2.1.x releases and Angular 2.2.0 various betas and RCs.

Upgrade

The most significant work has been done on the Ahead of Time compilation, and especially on the ngUpgrade support. That means you’ll be able to optimize your application going under migration. The router has received some love for those who want to migrate their ng1 apps to ng2: it’s now possible to use the Angular Router with the ngUpgrade!

Forms

One of the new features of this release is a modest contribution from me :) When you were using a template-driven form, the syntax was a bit painful to access some methods like hasError or getError:

<label>Username</label>
<input name="username" ngModel required #username="ngModel">
<div *ngIf="username.control.hasError('required')">Username is required</div>

Now with Angular 2.2+ we can directly access these methods on the local variable, without the need of accessing the control property:

<label>Username</label>
<input name="username" ngModel required #username="ngModel">
<div *ngIf="username.hasError('required')">Username is required</div>

Another feature introduced adds a ng-pending class on fields under pending async validations. In Angular, you can add validators on every field or group of fields. Such validators can be synchronous or asynchronous (for example asking the server if the chosen username is available). When an asynchronous validation is pending (the HTTP request is not completed yet for example), the ng-pending class is added to the field. You can use it to add some style or a spinner for example.

Router

The Router Module offers a very handy directive called RouterLinkActive, allowing us to add a specific class if a link is active. This directive is now exported, and can be used in our templates via a local variable:

<a routerLink="/races/1" routerLinkActive #route="routerLinkActive">
 Race 1 
</a>

That’s all for this small release. Check out our ebook and Pro Pack if you want to learn more about Angular!


Cédric Exbrayat


Ninja Squad books


Become a ninja with Angular 2
Cover of ebook Become a ninja with Angular 2

Pay what you want and support charity!


Devenez un Ninja avec AngularJS
Couverture du livre Devenez un Ninja avec AngularJS

Passez de débutant à ninja en AngularJS 1.4 avec un ebook à prix libre et pour une bonne cause !


Ninja Squad books



Formations

Angular 2

05-07 déc. à Paris
12-14 déc. à Lyon
23-25 jan. à Paris
06-08 mar. à Paris
03-05 avr. à Lyon


Suivez-nous


Writing a technical book is a long, painful and difficult experience. I only took a small part in the writing of our two Angular books, Cédric being the main author, but even then, I know how hard it is.

It would be even harder if we had not chosen the good tools and processes to write it. And even more importantly, for you beloved readers (or future readers, hopefully), the book wouldn’t have such a good quality.

This post will give you an overview of the tools and processes we use. You’ll see that writing a book is very similar to writing software.

Team work

First of all, even if Cédric is, by large, the main developer of this book (I told you: a book is a software project), the book is actually the result of team work. The other ninjas, and even some friends external to Ninja Squad, helped translating and proof-reading the book. Or rather, the many iterations of the book.

You might think the book is written from the beginning to the end, chapter by chapter. That’s not how it works. The structure has changed several times. Some chapters have been rewritten almost completely, several times. Sometimes because we were not satisfied, sometimes because Angular itself made big changes to their architecture and APIs (the forms, router and testing modules come to mind).

It would have been a nightmare to achieve that with a giant shared Word document. So the main tools we used were a text editor, Github, Asciidoctor, and shell scripts.

Each chapter (in French and English), has its own asciidoc file in the project, which is hosted in a Github repo.

Each time someone makes a change, he/she creates a branch and a pull request, and the change is proof-read, commented and amended until we’re satisfied.

Using Asciidoctor makes that very easy: the document is pure readable text, which makes it simple to diff, comment and merge. Using the Asciidoctor toolchain, the asciidoc files are merged into a big document, and the HTML, PDF, epub and mobi versions of the book are generated.

Even the diagrams are generated from ascii-art, using asciidoctor-diagram. That makes it easy to produce and translate them.

We also use the comments from our Git commits, and a custom Java program, to generate a changelog.

Embedded code

Proof-reading the text is a human task. To proof-read the code snippets, however, we need more than that:

  • errors in the code are more difficult to spot;
  • we started working on the book when Angular was still in alpha, so each and every release introduced breaking changes in the code;
  • readers are forgiving when it comes to typos (and several ones were kind enough to provide feedback about them), but they would be frustrated if the provided code snippets were incorrect.

So what’s the solution here? Just as in any other software project: compilation, linting, and automated tests.

How can we compile and run automated tests for code snippets embedded in a document? Well, we can’t. So that’s not how we’re doing it.

Asciidoctor allows including sections of external files into an asciidoc document. Here’s how it looks like to extract a section of an external typescript.spec.ts in the asciidoc document:

:specs: ../tests/specs/typescript/typescript.spec.ts

[...]

[source, javascript, indent=0]
----
include::{specs}[tags=variable-with-types]
----

And here’s how it looks like in the typescript.spec.ts:

[...]
  
it('should introduce types', () => {
  // tag::variable-with-types[]
  let poneyNumber: number = 0;
  let poneyName: string = 'Rainbow Dash';
  // end::variable-with-types[]

  // asserts
  expect(poneyNumber).toBe(0);
  expect(poneyName).toBe('Rainbow Dash');
});

[...]

Many tests are much more complex than this one, obviously, but Angular is very much testable, including the HTML templates, so it really allows testing each and every code snippet in the book. Our big test suite even allowed finding and reporting bugs in Angular itself sometimes.

The pro pack

The pro pack is another similar story. We of course want to be able to evolve the exercises from one Angular version to the next, and to make sure our provided solution is correct. If you have tested our pro pack already (the first 6 exercises are free, in case you want to), you know that each exercise comes with

  • the project as it should be to start the exercise;
  • unit and end-to-end tests to check that your solution is correct;
  • tooling to check that all the code is covered by tests, and passes lint checks;
  • the solution of the exercise.

Once again, automation and tests are key things to make that correct and maintainable. So Cédric has created a build process using custom scripts. The process automatically executes all the checks for each exercise of the pro pack one by one, using the files of the provided solution. A bit as if a robot passed through all the exercises and wrote the solution.

The demo application, is simply the result of the final exercise of the pro pack, amended with some branding and additional goodies by a final step of this whole build process.

Regarding the backend API of ponyracer, it’s a Spring Boot application, written in Kotlin, and documented, once again using Asciidoctor and a set of automated tests using Spring REST Docs.

The training material

Of course, our training slides follow the same philosophy. Nothing is more frustrating than having a wrong snippet of code in your slides when you give a training. So we use an asciidoc file per training module to write our slides, thanks to asciidoctor-bespoke. This awesome project lets you write your slides in plain asciidoc and generates an HTML presentation (with Bespoke.js). A slide is really easy to write:

== Angular 2
[%build]
* announced in March 2014
* RC in May 2016
* stable in September 2016

As it is a pure HTML presentation, you can customize the CSS, and insert dynamic Angular demos right into it. Of course, all code samples are in external files and are unit-tested just as for the ebook.

So what?

This wasn’t meant to convince you to write a book by yourself. But even if you don’t, many of the tools and processes described in this post can be used in other contexts.

The next time your pointy haired boss asks you to write a big Word document to describe your architecture or your library, you might want to convince him that much better collaborative tools are available to software engineers.


JB Nizet


Ninja Squad books


Become a ninja with Angular 2
Cover of ebook Become a ninja with Angular 2

Pay what you want and support charity!


Devenez un Ninja avec AngularJS
Couverture du livre Devenez un Ninja avec AngularJS

Passez de débutant à ninja en AngularJS 1.4 avec un ebook à prix libre et pour une bonne cause !


Ninja Squad books



Formations

Angular 2

05-07 déc. à Paris
12-14 déc. à Lyon
23-25 jan. à Paris
06-08 mar. à Paris
03-05 avr. à Lyon


Suivez-nous


Angular is moving fast, and we already have a minor release: 2.1!

If you haven’t heard, Angular is planning to have patch updates every week, minor releases every month, and major releases every 6 months.

That means Angular 3 should be Q1 or Q2 of 2017!

We plan to blog a little about each new release, to introduce you to the newest changes. We’ll ignore the tons of bug fixes, perf improvements and changes to ngUpgrade, to only focus on the new features.

This blog post contains the changes from Angular 2.0.x releases and Angular 2.1.0 various betas and RCs.

Router, modules, lazy-loading and pre-loading

The router comes with a really amazing feature allowing to lazy-load parts of your application. Instead of shipping a big bundle containing your whole application when your user lands on your home page, you can instead use this feature to only deliver the module he/she needs for this page, and then fetch the other modules only when required. Instead of paying the price of the load time once, you pay a smaller price, several times. And your initial load is faster!

But we can now do slightly better, with the 2.1.0 release. We can now define a strategy for pre-fetching the modules, even before the user needs them. Angular comes with a built-in strategy PreloadAllModules that will preload all modules as soon as possible. But you can also define your own strategy, to load only a few modules depending on your business logic (if the user is not an Administrator, maybe you can safely ignore the AdminModule for example).

Animations

Angular also comes with a great support for animations, with a custom DSL to define them. Angular 2.1.0 comes with two handy aliases :enter and :leave, to define animations that should run when the component is created or deleted.

@Component({
  animations: [
    trigger('myAnimation', [
      transition(':enter', [
        style({'opacity': 0}),
        animate('500ms', style({opacity: 1}))
      ])
    ])
  ]
})
export class AnimatedComponent {

With this animation, the component will slowly “fade in” as you can see on that plunker:

That’s all for this small release. Check out our ebook and Pro Pack if you want to learn more about Angular!


Cédric Exbrayat


Ninja Squad books


Become a ninja with Angular 2
Cover of ebook Become a ninja with Angular 2

Pay what you want and support charity!


Devenez un Ninja avec AngularJS
Couverture du livre Devenez un Ninja avec AngularJS

Passez de débutant à ninja en AngularJS 1.4 avec un ebook à prix libre et pour une bonne cause !


Ninja Squad books



Formations

Angular 2

05-07 déc. à Paris
12-14 déc. à Lyon
23-25 jan. à Paris
06-08 mar. à Paris
03-05 avr. à Lyon


Suivez-nous


Vous cherchez la version en Français ? C’est par ici.

To discover Angular 2, several thousands of you have read our ebook Become a ninja with Angular 2 (thank you!). You may have noticed we spent a lot of time keeping it up to date with the tons of changes from the various betas and release candidates! All that for the price you decided, without DRM, in English and French, and with some ponies inside.

Thanks for all your feedbacks and amazing stories: it helps to know that this tremendous workload has been useful ;)

But we wanted to go further to share our experience in building modern JavaScript applications. An ebook is a great way to discover a topic, but it’s not enough to really master it. You have to experiment, test, read code and learn best practices. A great way is to follow a training, but we know that’s not always possible time-wise, location-wise, boss-wise or money-wise.

We came up with this idea to let you build a complete application step by step, an application that would be close to a real professional app (so… not a todo list…), but that would be fun enough (so… with ponies!). An application that would include components, services, routing, dependency injection, modules, http, websockets, lazy loading, authentication, forms, validations, performance tricks, production tricks, etc. And tests. Lots of tests. Because Angular 2 makes it easy to have a great code coverage and to build robust applications. This application is Ponyracer (take a look)!

Purple pony

The Pro Pack lets you build Ponyracer, step by step, with more than 30 exercises, each dedicated to a specific topic. For each step:

  • we provide all the unit tests to validate 100% of your code
  • we provide you all the necessary resources
  • we provide you the instructions (in English or in French)
  • you have to complete the exercises (with the help of our ebook and resources)
  • you can submit your score with a tool we wrote (it analyzes your code, checks the quality, measures the completeness and submit the result to our platform)
  • you can check the ‘state of the art’ solution we wrote for each exercise
  • you can go to the next step and continue, or skip to whatever exercise you want, as we provide the full project ready to use for each step.

See the Pro Pack in action:

Pro Pack demo

You can check the Pro Pack platform at angular2-exercises.ninja-squad.com and see the list of exercises by yourself.

We had nearly a hundred beta-testers over the past months, and they all have been ecstatic about it! As we regularly update the exercises (to keep up with the changes and new features in Angular 2) and add new ones, they often come back to see what changed, learn new tricks and how they can update their own projects.

The Pro Pack is really about gaining time and experience. It gives you an overview of everything you can do, how to test it and how to best implement it, in an always up-to-date fashion. If you complete the exercises, you will be able to tackle any project in Angular 2. I’m not saying that this will be an overnight process: you’ll have to spend several hours/days making your way through the Pro Pack. But we are really confident that what you’ll learn is way worth the money you’ll spend on the Pro Pack. The updates and new exercises will be free, of course.

Sounds interesting? It’s now available! Go buy it!

Oh and if you already bought the ebook, we have a nice discount for you! Just go to books.ninja-squad.com/discount to claim it! The offered discount will be slightly bigger than how much you gave, because we want to thank you for supporting us from the start.


Cédric Exbrayat


Ninja Squad books


Become a ninja with Angular 2
Cover of ebook Become a ninja with Angular 2

Pay what you want and support charity!


Devenez un Ninja avec AngularJS
Couverture du livre Devenez un Ninja avec AngularJS

Passez de débutant à ninja en AngularJS 1.4 avec un ebook à prix libre et pour une bonne cause !


Ninja Squad books



Formations

Angular 2

05-07 déc. à Paris
12-14 déc. à Lyon
23-25 jan. à Paris
06-08 mar. à Paris
03-05 avr. à Lyon


Suivez-nous


Looking for the English version? It’s there.

Pour découvrir Angular 2, plusieurs milliers d’entre-vous se sont jetés sur notre ebook Devenez un Ninja avec Angular 2 (merci !). Vous avez probablement remarqué qu’on a consacré beaucoup de temps à le maintenir à jour avec tous les changements des différentes versions beta et release candidate. Et tout ça pour un prix de votre choix, sans DRM, en anglais et français, et avec des poneys en bonus !

Merci à tous pour vos retours et vos histoires incroyables : ça met du baume au cœur de savoir que cette conséquente charge de travail a été utile ;)

Mais on voulait aller plus loin pour partager notre expérience des applications JavaScript modernes. Un ebook est un bon moyen de découvrir un sujet, mais cela ne suffit pas à le maîtriser réellement.

Il faut expérimenter, tester, lire et écrire du code encore et encore pour apprendre les bonnes pratiques. Un moyen efficace est de suivre une formation, mais on sait que ce n’est pas toujours possible, que ce soit à cause des disponibilités, des localisations géographiques, de votre patron, ou du coût.

Alors on a eu cette idée de vous faire construire une application complète pas à pas, proche d’une application professionelle (donc pas une simple TODO list…), mais qui ne serait pas complètement rébarbative (d’où les poneys !). Une application qui contiendrait des composants, des services, du routage, de l’injection de dépendances, des modules, de l’HTTP, des WebSockets, du lazy loading, de l’authentification, des formulaires, de la validation, des astuces de performance, des astuces de mise en production, etc… Et des tests, des tonnes de tests. Parce qu’Angular 2 permet d’avoir une excellente couverture, et de construire des applications vraiment solides. Cette application est Ponyracer (jetez-y un œil) !

Poney

Notre Pack Pro te permet de construire PonyRacer, pas à pas, avec plus de 30 exercices, chacun étant consacré à un sujet précis.

  • On fournit tous les tests unitaires couvrant 100% de ton code.
  • On fournit toutes les ressources nécessaires.
  • On fournit toutes les instructions (en anglais ou français).
  • Vous complétez les exercices (avec l’aide de l’ebook et des ressources fournies).
  • Vous pouvez soumettre votre score via un outil que l’on a écrit (il analyse votre code, vérifie la qualité, mesure la complétude et soumet le résultat à notre plateforme).
  • Vous pouvez consulter la solution “état de l’art” qu’on a codée pour chaque exercise.
  • Vous pouvez continuer à l’étape suivante, ou sauter à l’exercice qui vous intéresse tout particulièrement : on vous fournit un projet fonctionnel pour débuter chaque étape.

Voici le Pack Pro en action :

Démo du Pack Pro Pack

Vous pouvez jeter un œil à la plateforme du Pack Pro sur angular2-exercises.ninja-squad.com et visualiser la liste des exercices prévus.

Près d’une centaine de beta-testeurs l’ont essayé sur les derniers mois, et ils nous on fait des retours très enthousiastes ! Comme on met fréquemment à jour les exercices (pour intégrer les changements et nouvelles fonctionnalités d’Angular 2), et comme on en ajoute de temps en temps, ils reviennent souvent pour voir ce qui a changé, apprendre de nouvelles actuces, et identifier comment impacter leurs propres projets.

Le Pack Pro permet de vraiment gagner du temps et de l’expérience. Il donne un aperçu de tout ce qu’on peut faire, comment le tester, et comment l’implémenter, dans le respect de l’état de l’art. Si vous complétez les exercices, vous serez prêt à vous attaquer à n’importe quel projet en Angular 2. Ne me faite pas dire que ça va être facile : il vous faudra plusieurs jours pour venir à bout de ce Pack Pro. Mais on sait que tout ce que vous apprendrez en chemin vaudra largement l’argent investi. Les mises à jour et les nouveaux exercices seront gratuits, évidemment.

Alors, intéressé ? Il est disponible dès maintenant !

Oh, et si vous avez déjà acheté l’ebook, on vous propose une chouette ristourne. Il vous suffit d’aller sur books.ninja-squad.com/discount pour la réclamer ! La remise sera légèrement plus importante que la somme que vous avez décidé de nous donner, parce qu’on est très fier que vous nous souteniez depuis le début, et qu’on veut vous en remercier chaleureusement.


Cédric Exbrayat


Ninja Squad books


Become a ninja with Angular 2
Cover of ebook Become a ninja with Angular 2

Pay what you want and support charity!


Devenez un Ninja avec AngularJS
Couverture du livre Devenez un Ninja avec AngularJS

Passez de débutant à ninja en AngularJS 1.4 avec un ebook à prix libre et pour une bonne cause !


Ninja Squad books



Formations

Angular 2

05-07 déc. à Paris
12-14 déc. à Lyon
23-25 jan. à Paris
06-08 mar. à Paris
03-05 avr. à Lyon


Suivez-nous


Kotlin logo

I read about it, I saw several talks about it, I even played a little bit with it, but now I made one step further, and started using Kotlin on a small, but real project.

It’s only been one week, and it’s a brand new project, where the most experimented Kotlin programmer is… myself. So I’ve hit walls, learnt quite a few things, and will probably have more mature opinions about the language in the future. But I’d like to share my experience at this point anyway.

The good stuff

First of all, you shouldn’t be afraid. Learning a new language is always intimidating, but when you know Java already, Kotlin is easy to learn.

The documentation is top-notch; the tooling (IntelliJ, Gradle/Maven plugins) is almost as mature as for Java; the compatibility with Java is real, and you should thus be able to code real stuff in a few hours, even when starting from scratch.

The first thing that you enjoy is all the syntax candy that the language brings. No primitive types anymore, no semi-colons to separate statements (and it always works fine, unlike in some other languages), [] to access an element in a map, multi-line strings for your JSON or SQL, the elvis operator for null-safe access, foo.bar.baz instead of foo.getBar().getBaz(), etc. That doesn’t seem much, but it really makes the code more readable. Another cool stuff is the extensions methods, which allow to use plenty of utility methods that you would dream to have in Java: list.firstOrNull(), list.last(), string.toInt(), etc.

Something that bothers you for a few minutes, but then proves to be the greatest feature of Kotlin, is its null-safety. Every Kotlin type comes in two flavors: Foo and Foo?. A Foo cannot be null. If a method accepts a Foo, Kotlin won’t let you pass null to the method. If you receive a Foo as argument, you can be sure that it’s not null. With Java 8 came Optional, but Kotlin doesn’t really need it, since a method can return a Foo? to signal that it can return null. And Kotlin will force you to deal with the null case. That feature, alone, is a damn good reason to use Kotlin.

Another thing that I appreciate is the promotion of immutability and encapsulation. There are two ways to declare variables: var and val. val means final. Immutability is helped by making it the default, easy thing. Just use val. A List is immutable. If you want to mutate it, you need a MutableList. A MutableList is a List, so you can return a MutableList if your method has List as its returned type. And you don’t need to wrap it with Collections.unmodifiableList(): the caller won’t be able to add anything to the returned list, because it’s not mutable. The beauty of that mechanism is that it doesn’t work by reimplementing the whole Java collection framework. The actual implementations of those types are the standard collections that you already know and master.

Finally, the signal/noise ratio is much bigger in Kotlin than in Java. You can write a typical dumb DTO with 5 fields in a single line of code, using a data class. No fields, no getters, no setters, mutability of properties depending on the use of val or var. That is intimidating at first, because you can’t help but think that so much information and details are condensed in such a small piece of code: every character matters when you read it.

Another great thing that helps making your code clean, readable and immutable is the named parameters. Kotlin won’t force you to use them, but they are a good alternative to the builder pattern (or setters) that you typically use in Java when dealing with a large data structure. For example, instead of typing

val person = Person(1L, "Jean", "Lambert", 1975, 2000)

which is quite confusing (is Jean the first name or the last name? what are the two numbers at the end?)

you can type

val person = Person(id = 1L, firstName = "Jean", lastName = "Lambert", birthYear = 1975, score = 2000)

Now, suppose you want a copy of this person with an incremented score, you can do

val newPerson = person.copy(score = person.score + 1)

The copy method is generated for you by the compiler on data classes (but it’s quite easy to define it by yourself, too).

The pain points

Nothing is perfect in this world, and Kotlin is not either. The code that I have started writing is not a library. It’s a typical “enterprise” application using Spring. But the problem would be the same with a Java EE application.

Kotlin chose to apply one of Josh Bloch’s principles: Design and document for inheritance, or else prohibit it. What does that mean? It means that all classes and methods in Kotlin are final by default: inheritance is prohibited by default. To enable it, you must add the keyword open to your class, property or method. That is probably a good choice for libraries, but when it comes to “enterprise” applications, it becomes cumbersome. Spring and Java EE are both based on dynamic proxies, i.e. on dynamically generated classes that extend your classes. And unit-testing those classes with Mockito, for example, also relies on dynamically generated subclasses. The result is that Kotlin’s open is like Java’s public: it’s a modifier that you start adding everywhere because it is your default. (Note: this will probably be fixed)

Talking about Mockito, that’s another pain point. Let’s take an example:

when(mockUserDao.findByEmail(any())).thenReturn(null)

That code won’t work for two reasons:

  1. when is a keyword in Kotlin. That’s easy to circumvent though. You can use `when` instead. (that is cool by the way: my tests method all look like fun `should do this when that`() { ... })
  2. more problematic: Mockito.any() (and many other matchers) returns null, and findByEmail() takes a String as argument, not a String?. So that fails, too. Niek Haarman did a good job providing a mockito-kotlin project that helps avoiding these two problems, but unfortunately, it’s based on the latest Mockito beta version, which is not the one required by Spring Boot. It was easy enough to adapt, but still, it’s a pain point.

Finally, Kotlin chose to adopt the Pascal way of declaring variables and functions: instead of typing the type first and the name after (Foo foo, Foo makeFoo()) the name comes first and the type after, even if inferred most of the time (var foo: Foo, fun makeFoo(): Foo). Note for the young hipsters reading that blog: Pascal was a very popular language back in the days, that was used by many schools to teach programming. That is a minor thing, but when you are used to the Java/JavaScript/C way for 20 years, your brain has a hard time doing it the other way. And I haven’t found a way to make the IDE help me with code completion. For example, when I have to declare a field FooBarBaz fooBarBaz in Java, I can just type FBB TAB Space f TAB, and the IDE autocompletes for me. But I haven’t found the way to do the same in Kotlin where the property must be defined as val fooBarBaz: FooBarBaz.

Mixed feelings

There are other stuff in Kotlin that I find a little bit disturbing, but maybe just because I’m not used to it yet, or because the language will improve them later. Those include:

  • companion objects instead of static fields and methods (I haven’t seen the real gain yet)
  • hard to remember syntax for creating anonymous class instances;
  • the lack of method references on objects, but that will come in a future version;
  • top-level variables and functions (I haven’t seen the real gain over static variables and methods);
  • the lack of package-level visibility. It seems to be circumvented by declaring multiple classes in the same file, but I find it ugly: it’s hard to find your classes if you’re not using an IDE.
  • function types instead of named functional interfaces (I find them hard to read, especially when defining generic higher-order functions: Predicate<T> is clearer to me than (T) -> Boolean)
  • the fact that SAM Java interfaces can be written lambda-style, but not SAM Kotlin interfaces
  • arrays that are invariant (unlike Java, which is good), but which still don’t behave like lists when it comes to equality (you still can’t use == to compare arrays just like you would do for lists)
  • the short syntax for function (fun foo() = bar()) which looks like unnecessary additional syntax to me
  • some other stuff that I can’t remember :-).

Conclusion

After just one week, although the language is not perfect yet, I definitely like it a lot. I would use it over Java 8, and even more over Java 6 or 7. Kotlin runs on Java 6, so if you’re doing Android development, you should really consider Kotlin as a much better alternative. If you’re using Java 8, like I do, you should still really consider it, for all the good stuff this article started with.

Kotlin has also been announced as the future language of choice for Gradle, and I can’t wait to be able to use it for my Gradle builds, and benefit for Gradle and code completion in the IDE.

Are you already using Kotlin? I’d love to know what you think about it. Comments welcome!


JB Nizet


Ninja Squad books


Become a ninja with Angular 2
Cover of ebook Become a ninja with Angular 2

Pay what you want and support charity!


Devenez un Ninja avec AngularJS
Couverture du livre Devenez un Ninja avec AngularJS

Passez de débutant à ninja en AngularJS 1.4 avec un ebook à prix libre et pour une bonne cause !


Ninja Squad books



Formations

Angular 2

05-07 déc. à Paris
12-14 déc. à Lyon
23-25 jan. à Paris
06-08 mar. à Paris
03-05 avr. à Lyon


Suivez-nous


2016-05-11

Chez Ninja Squad, on aime beaucoup Laurent “@on_code” Victorino. Comme l’essentiel du reste du Monde d’ailleurs, car Laurent est un homme fondamentalement aimable.

Laurent est aussi développeur, comme nous. Pourtant, nous ne sommes pas du même monde : dans sa bouche, nous sommes du monde des “cravateux”, ces développeurs qui font des applications de gestion pour les entreprises. Et lui, il développe des jeux vidéo indie, au sein du studio qu’il a fondé, Monkey Moon, après avoir travaillé sur des AAA chez des grands éditeurs. Et dans son domaine, à défaut de devenir notablement riche, il s’est forgé une solide réputation.

Son outil de prédilection est Unity, un moteur de jeux 2D ou 3D, qui se veut très accessible. Et à chaque fois que nous nous retrouvions autour d’un burger pour refaire le monde, il ne cessait de nous inviter à venir s’essayer à la création de jeux. On lui répondait qu’on n’avait pas cette capacité, il nous rétorquait que c’était beaucoup plus facile qu’on ne l’imaginait. On a du mal à le croire, pourtant il enseigne largement la création de jeux, dans les écoles spécialisées comme pour un jeune public dans les musées : il doit avoir éprouvé ce qu’il raconte. Il était même venu présenter son travail et initier des débutants à Mix-IT, une conférence chère à notre cœur, car organisée par certains ninjas.

Alors pourquoi ne pas s’essayer au développement de jeu. Et plutôt que profiter égoïstement de notre proximité avec ce généreux grand homme, on s’est dit que cela pourrait vous intéresser aussi, soit parce que vous aimez le jeu vidéo depuis que vous jouiez à la NES les yeux collés à votre écran cathodique assis sur le tapis du salon, soit pour se confronter à un univers de développement très éloigné de nos petits problèmes de transaction en BDD et de formulaires web.

Videogames are for idiots - Monkey Moon

Une vingtaine de personnes sont donc cordialement invitées, aux frais de la princesse des ninjas, à un atelier d’initiation au développement de jeu vidéo avec Unity, le vendredi 20 mai 2016 après-midi. Cela se passera à La Cordée Liberté.

Quelques conditions :

  • savoir coder, quelque soit le langage. Nous utiliserons C# sous Unity, mais il comprend aussi le JS ;
  • être disponible le vendredi 20 mai après-midi sur Lyon ;
  • posséder un ordinateur portable sur lequel peut s’installer Unity : Mac ou Windows ;
  • venir avec son ordinateur portable et Unity ;
  • être sympathique.

Pour vous inscrire, il vous faut remplir ce formulaire.
On vous confirmera rapidement si vous faites partie des heureux premiers élus.

À très vite !


Cyril Lacôte


Ninja Squad books


Become a ninja with Angular 2
Cover of ebook Become a ninja with Angular 2

Pay what you want and support charity!


Devenez un Ninja avec AngularJS
Couverture du livre Devenez un Ninja avec AngularJS

Passez de débutant à ninja en AngularJS 1.4 avec un ebook à prix libre et pour une bonne cause !


Ninja Squad books



Formations

Angular 2

05-07 déc. à Paris
12-14 déc. à Lyon
23-25 jan. à Paris
06-08 mar. à Paris
03-05 avr. à Lyon


Suivez-nous


AngularJS 1.5.x has been out for a few weeks now but, despite tracking the changelog, I missed a change that this version introduces: one-way binding in directives.

When you need to pass an argument to a directive, there are 3 ways of doing it:

  • using @, to pass a string value. You can pass a dynamic string by using mustaches:

    <my-directive name="{{ thePony.name }}"></my-directive>
    
  • using =, to pass an expression of any type:

    <my-directive pony="thePony"></my-directive>
    
  • using &, to pass some code that the directive is free to execute when it needs to:

    <my-directive on-selection="setSelectedPony(thePony)"></my-directive>`
    

The second way does more than that, though: it establishes a two-way binding between the directive scope’s pony and the controller scope’s thePony:

  • assigning a new value to thePony in the controller scope will assign a new value to pony in the directive scope;
  • assigning a new value to pony in the directive scope will assign a new value to thePony in the controller scope;
  • changing an attribute (the color, for example) of thePony in the controller scope, will change the attribute in pony, in the directive scope;
  • changing an attribute (the color, for example) of pony in the directive scope, will change the attribute in thePony, in the controller scope.

Most of the time, the directive needs to get information from the controller, but doesn’t need to change that information. The second bullet point above is something we don’t really need. And this two-way binding has a certain cost.

Since AngularJS 1.5, it’s now possible to bind a value one-way, using <:

  • assigning a new value to thePony in the controller scope will assign a new value to pony in the directive scope;
  • assigning a new value to pony in the directive scope will not assign a new value to thePony in the controller scope. Don’t do that, it’s nasty;
  • changing an attribute (the color, for example) of thePony in the controller scope, will change the attribute in pony, in the directive scope: they both reference the same object;
  • changing an attribute (the color, for example) of pony in the directive scope, will change the attribute in thePony, in the controller scope: they both reference the same object.

As far as I know, this has been done for several reasons:

  • it aligns more closely with Angular2, where one-way binding is the norm;
  • it allows to avoid making a copy of the object passed as argument to the directive;
  • it allows creating a single watcher in the controller scope, that watches by identity instead of equality, making it faster.

More details are available in the documentation. You can also experiment with a little plunkr I wrote to show the difference of behavior between the two.

Enjoy!


JB Nizet


Ninja Squad books


Become a ninja with Angular 2
Cover of ebook Become a ninja with Angular 2

Pay what you want and support charity!


Devenez un Ninja avec AngularJS
Couverture du livre Devenez un Ninja avec AngularJS

Passez de débutant à ninja en AngularJS 1.4 avec un ebook à prix libre et pour une bonne cause !


Ninja Squad books



Formations

Angular 2

05-07 déc. à Paris
12-14 déc. à Lyon
23-25 jan. à Paris
06-08 mar. à Paris
03-05 avr. à Lyon


Suivez-nous


Posts plus anciens