Comme sur des rails

Depuis décembre dernier, je suis assidûment les cours de CodeSchool, en particulier la section JavaScript. Une connaissance très pointue de JavaScript me semble nécessaire avant de me lancer dans l’utilisation de Node.js ou d’un des frameworks MVC existants.

J’ai été assez étonné d’une chose en particulier sur CodeSchool : la taille de la section Ruby On Rails. J’ai été d’autant plus étonné de voir que les tout premiers cours créés sur CodeSchool ont pour thème Ruby On Rails.

Alors certes, cela fait maintenant très longtemps que j’entends parler de Ruby on Rails et de la façon dont Rails (le « père » des frameworks MVC à l’intention du développement web) et de sa couche d’abstraction ActiveRecord pour les données.
En revanche, si Python est un autre langage de script qui m’a longtemps intéressé, et auquel je me déjà initié, Ruby et sa syntaxe héritée de Perl m’ont toujours fait peur.

It’s all about APIs, man

Retour au temps présent : la séparation MVC va bien plus loin que de simplement séparer certains types de contenus au niveau du code. Les sources de données sont aujourd’hui également mises à part de façon massive.

Avez-vous déjà entendu parler d’APIs? Pour schématiser, une API permet de questionner un programme et de recevoir une réponse sous forme de flux de données en retour.

Une API est propre au programme qui l’héberge et les réponses formulées dépendent bien entendu de la spécificité métier de ce programme.

La quasi-totalité des sites internet les plus fréquentés au monde possède une API pour chacun de leurs services. Google Search, Facebook, Google Map, Foursquare, Twitter. Et si les APIs étaient originalement créées pour les programmeurs barbus souhaitant « jouer » avec ces sites Web et incorporer des données de ces APIs sur leurs sites internet par exemple, aujourd’hui ces API servent aux concepteurs de ces sites / services dans le but de construire les clients de leurs sites / Services / Applications.

Ne l’oubliez pas, comme je le dis en Introduction à ce Blog, le web devient mobile et dynamique : cela signifie qu’une même source de données peut se retrouver sur de nombreuses déclinaisons logicielles : téléphone mobile, site internet, application télévisuelle, widget… et il y a bien une chose que les développeurs détestent : c’est la duplication de code et de données.

Sainte API priez pour nous

Avec les techniques modernes de programmation et de développement Web, il n’est aujourd’hui plus nécessaire de bâtir un FrontEnd avec une liaison directe en base de données. De multiples requêtes http se chargent de récupérer les différents contenus d’une page au format XML ou mieux, JSON et votre framework JavaScript favori vous permet de mettre tout ça en page dynamiquement.
Sans le savoir, vous venez d’utiliser un webservice pour construire votre page web. Félicitations !

T’aurais pas oublié Ruby dans ton monologue, là ? hein ?

J’y reviens : mon cheminement faiblard au niveau des APIs et de leur importance dans la conception de sites web modernes permet de toucher un point très important : la performance.

Votre nouveau site internet est relié aux données via une ou plusieurs API. Il vous arrivera très souvent de concevoir cette API pour « nourrir » votre FrontEnd. Une API lente vous garantira une expérience utilisateur minable.
Vous savez le nombre effarant de technologies qui permettent de créer une API RESTFull de nos jours ? (pour ne citer que ce protocole). Des milliers.
Mais il y en certaines qui sont reviennent souvent dernièrement: Ruby on Rail et Node.js.

On me dit dans l’oreillette que Java, .NET, Python ou même PHP font très bien le travail. C’est vrai. Mais j’omets volontairement ces technologies, car elles ne rentrent pas dans le cadre de ce blog, qui je vous le rappelle est mon « journal de bord » concernant les nouvelles technologies, et dans une mesure moindre les technologies très intéressantes que j’aurais laissé en chemin (RoR, levez la main !).

C’est donc décidé : je vais m’initier à Ruby On Rails. Je sais pertinemment que ce n’est pas un langage / framework que je vais réellement utiliser dans ma vie professionnelle. En revanche, je sais par expérience que se plonger dans un autre contexte de programmation, avec un environnement différent et un langage différent va nécessairement me donner des points de vues nouveaux sur des techniques que je maîtrise parfaitement aujourd’hui.

RoR : en selle ! (et Gretel)

keep-calm-and-learn-ruby-on-rails-8

Première étape de cette initiation : les cours de CodeSchool. Je vous les recommande, ils sont très bien faits et les exercices interactifs sont plutôt bien pensés. Ils sont parfois un peu rébarbatifs, mais ils donnent un bon point de départ !

Deuxième étape : commencer un projet fondamental (je ne sais pas encore lequel) et pourquoi pas le publier sur Github.

Je vais très certainement trouver des choses intéressantes, de ma perspective de développeur PHP. Je ne manquerais pas de vous en faire part.
Petite note aux lecteurs qui serait déjà de fins connaisseurs de RoR : ne vous moquez pas trop de ce que je pourrais remonter comme découverte, il est très probable que vous les connaissiez depuis plusieurs années et que ça vous fasse sourire de constater que j’ai pu m’en passer depuis tout ce temps 😉

A bientôt 😉

Où il est bon de se placer dans le bon contexte

Bonjour.

Un premier billet sur un blog est toujours une tâche fastidieuse car il est difficile de savoir par quel bout commencer. Pour une fois, je dois avouer que c’est assez simple, puisqu’il va être question de technologies liées au développement web.
Mais pas n’importe quelles technologies : les « nouvelles » technologies.

Nouvelles, vraiment ?

Pas vraiment. Aujourd’hui le web est de plus en plus mobile. Il est également de plus en plus dynamique et il est plus que probable que les notions de « Cloud Computing » ou de « Big Data » soient déjà arrivées à vos oreilles.

Derrière ces notions se cachent toute une batterie de technologies qui n’existaient pas il y a 10 ans. En tout cas pas sous la forme actuelle, ni avec la maturité actuelle.

De mon point de vue de développeur Web, ces technologies ont émergé très rapidement suite à la publication de Node.js, une plateforme permettant d’utiliser JavaScript comme langage côté serveur (c’est bien plus que ça en réalité, Wikipedia vous en dira plus).

Avant Node.js, Javascript était surtout utilisé pour rendre plus dynamique visuellement les pages Web et utiliser Ajax, généralement à l’aide de frameworks comme jQuery. Encore une fois je caricature, d’autres technologies comme Google Web Toolkit  permet de faire des applications en javascript très impressionnantes depuis de nombreuses années (Gmail en est l’exemple le plus parlant).

L’arrivée de Node.js et surtout son adoption massive au fil des années a mené à l’élaboration de très nombreux framework JavaScript MVC, parmi lesquels , ReactMeteorEmber.js, Angularjs (ça fait un paquet de « js »).

Ces frameworks ne sont pas forcément équivalents, ne font pas forcément tous la même chose mais ils ont tous un point commun : ils cherchent à faciliter la vie des développeurs web en inventant de nouveaux paradigmes et en encourageant l’adoption de best practices.

Mais c’est carrément la jungle ?!

Un peu oui ! Ce blog va vous mettre dans la même position que moi : s’initier à l’ensemble de ces technologies, se poser des questions, essayer d’y apporter des réponses. N’attendez pas de tutoriels de ma part, de nombreux blogs le font déjà très bien et la documentation des projets qui seront évoqués ici sont généralement très complets.

Voyez ce blog comme mon journal de bord concernant l’apprentissage de ces technologies. Mon opinion, mes coups de cœur / coups de gueule vous aideront peut-être à vous dépatouiller d’une situation de crise qui sait !