Nanoko est un tout nouveau framework JavaScript professionel supporté par le consortium open source européen OW2. Publié sous licence Apache 2.0, il permet de concevoir des applications web & hybrides (encapsulation via Phonegap par exemple) de manière unifiée.
Sommaire
- Quelles ont été les motivations ayant conduit à la création de Nanoko ?
- Quels sont les concepts phares de Nanoko pour répondre à ces attentes ?
- Quels sont les avantages de Nanoko ?
- Plus concrètement, comment cela s'architecture-t-il ?
- Les perspectives
Quelles ont été les motivations ayant conduit à la création de Nanoko ?
Nanoko a été implémenté pour :
- contourner l' hétérogénéité et la volatilité du marché du numérique, sachant il est de plus en plus complexe et coûteux de mettre à disposition son application sur tout ou partie des appareils pour maximiser son potentiel d'utilisateurs
- répondre aux nouvelles attentes du marché avec l'intégration de services (DropBox, PayPal, Foursquare…), de technologies (NFC, camera frontal et dorsale, Wifi-Direct, tactile…) et d' usages (réseaux sociaux, gamification/ludification, paiement mobile, geomarketing) de plus en plus variés afin d'offrir une expérience personnalisée et ubiquitaire à l'utilisateur
- tirer partie des fonctionnalités et des usages de chaque type d'appareils selon que l'application soit déployée sur un smartphone, une tablette, une TV connectée, ou sur le cloud ; et sur les montres, vêtements et lunettes connectés demain.
Quels sont les concepts phares de Nanoko pour répondre à ces attentes ?
L'approche du client unifié requiert de pouvoir adapter l'application à chaque appareil, pour éviter de devoir développer n applications pour cibler n appareils comme le font la plupart des éditeurs d'applications et autres SSII à l'heure actuelle.
Pour ce faire, Nanoko permet de concevoir des applications modulaires, chaque module représentant une fonctionnalité métier ou un fragment d'UI. Le framework intègre donc un modèle à composants de services à l'instar d'OSGi dans le monde J2EE. Chaque composant décrit ses dépendances et les services qu'il offre. Nanoko va alors résoudre à l'exécution, en fonction du contexte et selon le type de plateforme les dépendances de services pour activer les modules adéquats, en désactivant les autres.
Par exemple, votre application permet de prendre une photo et de gérer vos photos sur le Cloud, si vous êtes sur un smartphone vous activez la prise de photo, si vous êtes sur une TV connectée non équipée de caméra vous désactivez la prise de photo. De plus, dans chacun de ces deux cas on active le fragment d'UI qui correspond. En effet, l'interface et l'ergonomie d'une application smartphone ou d'une application pour TV connectée diffèrent diamétralement.
Quels sont les avantages de Nanoko ?
Le gros avantage de l'approche unifiée est de conserver un ensemble de composants JavaScript commun pour chaque plateforme et d' offrir des composants spécifiques pour tel ou tel autre type d'appareils et selon les fonctionnalités qu'ils prennent en charge.
L'approche modulaire permet d'offrir une solution logique à la diversification des devices et des usages. Mais Nanoko ne s'arrête pas là puisqu'il offre une chaîne de compilation de l'application construite autour de la technologie Maven ainsi qu'un watch mode.
Plus concrètement, comment cela s'architecture-t-il ?
La chaîne de compilation effectue un ensemble de traitements (compilation, test unitaires, minification, obfuscation, optimisation, packaging) permettant d'accélerer, de solidifier et de mutualiser le développement de l'application. La chaîne de compilation de Nanoko intègre une batterie de bibliothèques JavaScript adéquates telles que :
- CoffeeScript et Less : pour une syntaxe allégée et l'accès à des fonctionnalités additionnelles (par rapport à JS et CSS)
- Jasmine pour les tests unitaires : tout composant ne respectant pas ses jeux de tests ne sera pas agrégé dans l'application finale, et s'il est indispensable la chaîne de compilation renvoie gentiment le développeur à ses cahiers.
- JSLint, JSHint, Dust, etc.
Le watch-mode quant à lui compile à la volée vos sources dès que vous sauvegardez un fichier et fait tourner automatiquement la chaîne de compilation.
Nanoko a donc fait pour vous une sélection des toutes dernières bibliothèques JS et les a combinées pour vous offrir un environnement de développement permettant d' industrialiser vos développements web côté client tel que ce qui est fait côté serveur dans les langages professionnels (J2EE, Ruby, etc.).
Enfin Nanoko encapsule les meilleures bibliothèques multi-platformes du moment, dûment testées et sélectionnées par les auteurs du framework pour leur performance ou leurs fonctionnalités : jQuery, EnyoJS , Bootstrap, CoffeeScript, Mootools, Less, Dust, JSLint, JSHint, Jasmine, Node.js, etc.
Ces bibliothèques sont mises à disposition sur le dépôt Maven Central de Sonatype, afin de permettre une récupération automatique des bibliothèques requises par votre application par la chaîne de compilation de Nanoko.
D'ailleurs, c'est la toute première fois que Sonatype accepte des artefacts Maven implémentés en JS car n'acceptant jusqu'alors uniquement des artefacts Java, tout ça grâce à la publication de Nanoko en open source et un travail acharné de ses fondateurs.
Nanoko ne réinvente donc pas la roue, le framework tire partie des bibliothèques mondialement utilisées à l'heure actuelle et y ajoute des concepts éprouvés du développement logiciel professionnel.
Nanoko vous permet donc de développer à un niveau industriel tout en utilisant vos bibliothèques favorites ! Vous pouvez également mettre à niveau industriel vos applications existantes en les modifiant très légèrement.
Les perspectives
Avec Nanoko, une nouvelle ère s'ouvre donc aux développeurs JS, en résolvant le manque d'industrialisation des développements JavaScript actuels et en adoptant l'approche révolutionnaire du client unifié, pour le développement d'applications web nouvelle génération, adaptables partout ! À vos IDE, commencez à développer les applications multi-modales de demain !
D'ailleurs le projet a une feuille de route bien étoffée cette année qui devrait réserver quelques surprises à l'ensemble des communautés web & J2EE à l'échelle internationale. Comme quoi, l'innovation des TPE françaises peut sans problème rayonner mondialement, n'ayez pas peur de vous lancer vous aussi !
Develop once & professionally, deploy everywhere!
Testez au plus vite le tutoriel de Nanoko disponible sur le site web dans la section Developer>Docs. Le site a d'ailleurs été réalisé en Nanoko, ci-dessous l'égérie du framework !
Nanoko : La technologie sexy qui va faire mal !
Aller plus loin
- Nanoko : pro javascript framework (1446 clics)
- nanoko-project sur GitHub (361 clics)
- Ubidreams (292 clics)
- Dynamis-Technologies (177 clics)
# FOUTAISES!
Posté par Serge Julien . Évalué à 9.
Jamais ma grille de business-loto n'a été aussi vite remplie, faut dire que c'était facile: framework, hétérogénéité, volatilité, ubiquitaire, client unifié, applications modulaires, modèle à composants de services, native encapsulation, solidifer, industrialiser, multi-modale…
[^] # Re: FOUTAISES!
Posté par lrbabe . Évalué à 2.
Effectivement. J'ai arrêté de lire à partir de "CoffeeScript" mais ma grille était déjà bien remplie.
[^] # Re: FOUTAISES!
Posté par CrEv (site web personnel) . Évalué à 5.
Mouai, si tu classe ça dans ta grille de business loto say triste
# TL;DR
Posté par usbplug . Évalué à 2.
Blabla a part, c'est quoi au juste ? Un truc genre Yeoman ?
# Merci pour ces feedbacks
Posté par Rom1 . Évalué à 8.
@usbplug, par rapport à Yeoman quelques premiers éléments de différenciation:
- Yeoman est une solution basée sur Grunt, Nanoko lui repose sur Maven qui est plus avancé et surtout permet de chainer des développements avec des composants de services (grille loto) J2EE.
- Nanoko cible uniquement le développement côté client et non le serveur comme Yeoman
- Nanoko intègre un vrai modèle à composants de services dynamiques (grille loto), d'ailleurs créer par le fondateur d'iPOJO (Apache Felix)
- Nanoko intègre un watch mode
@Serge_Julien, Irbabe, je suis ravi de voir que Nanoko a touché quelque chose de très profond en vous. Mieux vaut générer de l'animosité que de l'indifférence. Seul le temps passé à essayer de vulgariser notre technologie dans cette dépêche en prend un coup.
Au lieu de fustiger (grille loto aussi?) , si vous voulez réellement vous faire une idée sur le framework le code est sur github (grille loto aussi?) et les concepts récapitulés dans cette dépêche sont expliqués de A à Z sur le site web. Prenez-donc le temps de consulter tout ça, de tester le tuto, et venez en discuter avec nous sur la communauté G+ du projet, ce sera avec grand plaisir :)
Je vais demandé à la rédaction de rédiger une autre dépêche avec un peu plus de code et moins de mots "à la mode" qui pourtant sont nos concepts de bases. Libre à vous d'ailleurs d'utiliser, de contribuer ou de lire les dépêches sur Nanoko, ou d'ailleurs de continuer à fustiger (grille concurrente ?).
[^] # Re: Merci pour ces feedbacks
Posté par Grunt . Évalué à 10.
Wait, what ?
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Merci pour ces feedbacks
Posté par Rom1 . Évalué à 1.
http://yeoman.io
[^] # Re: Merci pour ces feedbacks
Posté par Raoul Volfoni (site web personnel) . Évalué à 5.
Parfois il suffit juste de porter un peu d'attention à la personne à qui on s'adresse…
[^] # Re: Merci pour ces feedbacks
Posté par Serge Julien . Évalué à 5.
Nulle animosité, seulement un trait d'humour, je crois que ça fait partie des traditions de ce site, et le business loto n'était plus sorti depuis quelque temps.
Désolé si j'ai été mal compris, et surtout toutes mes excuses pour le discrédit que mon premier commentaire a pu jeter sur cet article et le temps que vous avez mis à le rédiger. Sincèrement désolé, et si les modos pouvaient le supprimer ou le forcer à -42 (mon commentaire, pas l'article), je les en remercierais.
En ce qui concerne le fond, je ne fais malheureusement pas partie du public cible, n'étant pas codeur web ou mobile. Mais pour ma pénitence, je promets d'y jeter un œil. Je ne suis pas inscrit sur Google+ et ce n'est pas dans mes intentions immédiates, mais si j'ai un feedback plus constructif à vous apporter, je trouverai bien un moyen de le faire.
Sans rancune, j'espère.
[^] # Re: Merci pour ces feedbacks
Posté par Rom1 . Évalué à 1.
Pas de problème, j'ai l'habitude, et c'était un bon troll ;) A bientôt j'espère et surtout essayez Nanoko! ^
[^] # Re: Merci pour ces feedbacks
Posté par Pierre . Évalué à 2.
Je suis assez d'accord avec Serge, j'ai eu la même réaction capillaire. Linuxfr est un site technique, pas besoin sortir les buzzwords de décideurs..
Du point de vue technique, on retrouve des concepts intéressants. Typiquement la modularization de maven est intéressante, c'est quelque chose qui commence a devenir très important en JS, notamment avec AMD, ou commonJS.
On a du mal a voir dans ta présentation en quoi Nanoko est plus qu'un build system.
Dans le style, AngularFun implémente en quelque lignes de grunt les fonctionnalités coffee script, less, minification, concatenation des templates, watch, browser auto-reload (bingo!):
https://github.com/CaryLandholt/AngularFun
Si je regarde un peu le site, je vois qu'il y a h-ubu, qui est un descripteur de service. Bon. C'est quoi l'avantage par rapport au système de services d'angular?
AMHA, vous devriez justement imposer un framework MVC. Je comprends que vous voulez permettre au gens de récupérer leur ancien code, mais je ne crois pas que ça soit au fond leur rendre service.
Si l'industrie frontend a besoin de structure, il faut qu'on se mette d'accord sur un framework MVC/TDD, et qu'on laisse tomber les anciennes technos intestables type JQueryUI, YUI, dojo, etc.
Sur ce point, j'ai l'impression que justement l'industrie francaise a 1 a 2 ans de retard sur l'industrie Silicon Valley.
[^] # Re: Merci pour ces feedbacks
Posté par Rom1 . Évalué à 2.
Oui Grunt est un outil intéressant mais jeune, de plus pour entrelacer les développements avec des composants J2EE ça s'annonce plus sioux.
Venant de ce monde là, on est parti tout logiquement sur maven qui possède beaucoup plus d'extensions. Des extensions qu'on utilise notamment en interne et qu'on a placé dans notre roadmap open source que je ne vous dévoilerais pas ici puisque big brother is watching you :)
De toute façon Grunt et Nanoko ne sont pas incompatibles croyez moi.
h-ubu est un modèle à composants de services dynamique tirant le meilleur de la norme OSGi et de nos expériences sur l'implémentation iPOJO sur Apache Felix, le positionnement et la logique de programmation diffère de celle d'Angular.js d'ailleurs nous allons bientôt poster un billet sur ce sujet.
Pour ce qui est MV*, notre positionnement est de ne pas réinventer la roue puisque d'autres libs le font déjà très bien, libre à vous donc de sélectionner ce qui vous convient. En interne, pour notre V on n'en utilise pas et on développe avec du modèle à composant en codant des contrôleurs graphiques maisons encapsulant Enyo ou Bootstrap. Pour le M on a l'orientation MIL. Pour le L, h-ubu. Ce choix est un positionnement voulu pour ne pas marcher sur d'autres plates bandes (parce que ça pique fort), parce que nous n'en avons jamais eu besoin et puisque le W3C nous prépare ShadowDOM. Sur ce point là, on va quand même open sourcé certaines choses dans l'année ;)
Sur la Silicon Valley, je pense que Nanoko est au coude à coude, voire un poil en avance. En tout cas, on est loin d'être à la rue, on va faire notre chemin, enfin tout dépendra de vous, la communauté open source, après nous fait du "forfait" sur Nanoko donc.
Merci pour ces commentaires, je crois qu'on est en train de construire ensemble la FAQ Nanoko !
# NodeJs...comprend pas
Posté par romu . Évalué à 3.
Bonjour,
Et merci pour la dépêche. Ca semble intéressant, mais vous parlez de développement côté client, quand tout à coup surgit le terme "nodejs" et là, tout de suite, on se dit qu'il y a un truc bizarre.
[^] # Re: NodeJs...comprend pas
Posté par Rom1 . Évalué à 3.
Effectivement je comprends que ça confusionne, mais en fait certaines briques de Nanoko notamment h-ubu peuvent être utilisées côté serveur pour utiliser l'approche à composants de services à la OSGi / iPojo. Ceci est décrit ici.
[^] # Re: NodeJs...comprend pas
Posté par Grunt . Évalué à 2. Dernière modification le 19 février 2013 à 03:57.
(Note : je ne suis pas du tout, du tout, un Web dev, et toutes ces technos sonnent comme un langage étranger pour moi)
Etherpad Lite (une interface Web d'édition collaborative) est écrit en Node.js côté serveur, non ?
Après tout ça parait logique de voir des langages côté clients être utilisés côté serveur : pour le dev' autant utiliser ce qu'il connaît.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
# lapin compris
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
C'est une sorte de Java EE en javascript?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: lapin compris
Posté par Rom1 . Évalué à 2.
Presque, c'est plutôt un framework JavaScript qui utilise les concepts éprouvés de développement J2EE pour ce qui est du modèle de programmation dynamique, de la chaîne de compilation et du watch-mode.
# Bof
Posté par ariasuni . Évalué à 3.
J'avoue que je suis un peu déçu par la dépêche…
Déjà le terme Wifi-direct n'est pas expliqué. Dommage que ne soit pas indiqué dans la dépêche. (au moins un lien vers Wikipedia)
Sinon même en cherchant sur la doc de Maven, rien qui explique ce qu'est un artefact, j'aurais aimé une explication. La définition du mot en français et en anglais ne m'aide pas beaucoup.
De plus la dépêche est remplie d'anglicismes (1 ou 2 ça va mais là…):
* «front/rear camera» = appareil photo frontal/dorsal
* «gamification» = ludification (rendre les choses ludique), dommage que ça ne sont pas expliqué dans la dépêche non plus
* «cross-platformes» = multiplateformes.
* «repo» = dépôt
* «next-gen» = nouvelle génération
* «roadmap» = feuile de route
Bref je reste un peu sur ma faim (pour la qualité de la dépêche).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Bof
Posté par Rom1 . Évalué à 1.
Oui effectivement trop d'anglicismes et de termes incongrus, c'est mon premier article sur Linuxfr soyez indulgent :)
Pour votre Samsung GS2 c'est étonnant, j'ai un Nexus One sur lequel ça fonctionne bien, EnyoJs et Bootstrap font peut être ramé votre smartphone. D'ailleurs à quel moment rame t'il (scroll, chargement de la page)?
Quand vous dites le menu ne marche pas, parlez vous du menu Bootstrap? Et que se passe t'il exactement?
Suite à vos retours, on optimisera tout ça asap (site réalisé en 1 semaine).
Nycö faudrait mettre à jour la dépêche rapidement, je peux m'y coller si tu veux.
[^] # Re: Bof
Posté par Nÿco (site web personnel) . Évalué à 3.
C'est corrigé, merci.
Note : c'est Nÿco, avec un tréma sur le « y ». :-p
[^] # Re: Bof
Posté par Rom1 . Évalué à 2.
Ouah le pointilleux quoi … ^
[^] # Re: Bof
Posté par ariasuni . Évalué à 2.
Ça rame au défilement, je viens de revérifier: légèrement avec le navigateur par défaut (sur lequel j'ai une bande blanche en bas de l'écran), pas mal avec Tint Browser.
Le menu fonctionne, mes excuses. Il prend presque tout l'écran une fois déroulé et comme il n'y a pas de rechargement de la page j'avais pas vu que le contenu de la page changeait).
Sinon techniquement ça a l'air très intéressant, je garde ça en tête pour le jour où j'aurais besoin de faire du Javascript.
Et merci pour la clarification de la dépêche — n'oublions pas que nous avons été débutant un jour…
Écrit en Bépo selon l’orthographe de 1990
# Positionnement ?
Posté par janac . Évalué à 4.
Quel est le positionnement de votre framework par rapport à AngularJs ou encore EmberJs? Sans parler de process de developpement…
[^] # Re: Positionnement ?
Posté par Rom1 . Évalué à 3. Dernière modification le 18 février 2013 à 11:01.
C'est une très bonne question, merci à vous de la poser!
Nanoko ne force pas de modèle MV* à l'instar de Backbone.js, Angular.js et cie.
Donc vous pouvez faire soit du modèle à composants de services + controller EnyoJs ou Bootstrap ou tout autre framework graphique, soit vous encapsulez Angular, Backbone et cie dans un(des) composant(s) Nanoko tout en tirant partie des services du framework plus bas niveau.
Des tutoriels d'intégration tels que celui de Node.js et Require.js vont être postés petit à petit sur le site Nanoko, la sortie du framework en open source requérant un max d'efforts. Nous intègrerons l'ensemble de vos feedbacks en continuous delivery sur le site Nanoko, passez régulièrement ou suivez nous sur les réseaux sociaux (principalement G+ pour les posts, et Twitter en plus pour les annonces).
# Intéressant
Posté par maboiteaspam . Évalué à 3.
Hello,
Le projet est très très intéressant.
Désolé de ne pas aller lire la doc moi même…, mais je voudrais quand même clarifier l'étape de compilation.
Cette étape produit elle des pages ouebs finies, ou bien "n'est ce qu'une" translation/minification/obsfucation de chacun des fragments ?
Et aussi comment résolvez vous la question des droits accès aux contenus ?
Faut il faire tourner les fichiers compilés dans une appli tierce qui s'occupe de jouer le rôle de contrôleur ?
J'ai vu que vous aviez ajouté tout un tas de librairies pour le contrôle et la qualité, quid de tout ce qui concerne le chargement des assets plus volumineuse type image ? Un système de progressive download automatique existe t'il ?
Enfin dernier point qui m'échappe présentement, nanoko est il une plateforme de développement à déployer comme serveur sur chacun des postes de développeur ou bien est il préférable de l'installer en tant que serveur central de développement ?
Encore une ou deux questions…,
comment vous envisagez l'overhead induit par l'utilisation de javascript ?
A quels types d'applications destinez vous ce projet ?
a+
[^] # Re: Intéressant
Posté par Rom1 . Évalué à 3.
Hello too,
merci pour votre feedback très positif et pour tout ce tas de questions très pertinentes auxquelles je vais essayer de répondre au mieux:
- la chaîne de compilation de Nanoko agrège l'ensemble des librairies et composants de votre application au sein de votre unique fichier HTML index.html, après avoir validé que toutes les dépendances sont résolus, que tous les tests unitaires sont passés, après avoir amélioré optimisé vote code, l'application est enfin intégralement retestée: tout ça est possible grâce à la châine de compilation Maven (fichier pom.xml de votre application)
- Nanoko est orienté développement client et non serveur, donc vous développez sur votre poste et déployez ensuite. Si vous ciblez le déploiement d'un(e) webapp ou siteweb vous déployez ce fichier sur votre serveur tel que nous l'avons fait pour le site web de Nanoko. Si vous ciblez le déploiement hybride sur smartphone ou tablette sous forme d'un application native vous encapsuler les fichiers résultant dans Phonegap par exemple.
- un système de progressive download est accessible mais uniquement dans un repo privé pour le moment accessible sur abonnement, et oui on a besoin d'avoir un modèle économique autour du framework, faut qu'on gagne notre vie ^ et nous adoptons un modèle à la phonegap, dès que ces composants de services sont amortis nous les relacherons en open source. De toute manière, rien ne vous empêche dans développer un vous même et l'agréger comme dépendance Maven. D'ailleurs vous pouvez fournir si vous désirer publier ces composants développés en open source, nous les lierons avec le repo Nanoko github après validation technique.
- je ne vois pas bien ce que vous appelez "overhead" javascript, peut être la charge mémoire ? Et bien sur ce point la il est possible de désactiver à la volée des composants Nanoko s'ils ne sont pas ou plus utilisés, après le garbage collector fait son travail ;) Pour l'instant, pas de système de déchargement automatique c'est à coder à la mano, mais ça sera dans notre roadmap :) D'ailleurs rejoignez nous sur G+ car vous fourmillez d'idées plus que pertinentes!
- nous avons utilisé Nanoko en interne à Ubidreams dans de nombreux projets dont certains sont cités sur le site nanoko dans la partie partners, nous avons fait des applis smartphone, tablettes et web. L'idée majeure de l'approche au coeur de Nanoko est le fait de pouvoir développer une seule fois son application et de la spécialiser pour chaque plateforme cible soit au packaging soit dynamiquement.
En espérant avoir répondu à vos interrogations.
[^] # Re: Intéressant
Posté par maboiteaspam . Évalué à 3. Dernière modification le 18 février 2013 à 13:22.
Merci pour ce retour hyper rapide : )
Par overhead j'entendais sur-consommation cpu, et donc latence côté device au lieu du traditionnel network.
C'est un peu litigieux comme remarque de ma part car cela concerne uniquement les dinosaures de cet environnement, aka * != webkit (trident et gecko inclut…). Mais bon c'est une réalité tout à fait présente aujourd'hui et pour encore quelques années at least car on ne passe pas à côté de 10% d'audience parce que le projet est beau techniquement.
OK. Si je me mets dans le cas où mon appli sert des contenus variés et nombreux, je ne m'imagines pas une seconde tout mettre dans le même fichier HTML. Donc, il faut passer par un système de transition de page à page ? En un sens il faut réinventer la roue de la balise < a >, de HTTP ?
Quid du SEO dans cette configuration ? Dans le fichier index j'aurais trop de donnée, dans les autres fragments, probablement pas assez.
Oui j'ai bien compris. Mais je croit qu'il faut que je teste par moi même car je n'envisage pas ce type de dév sans le déploiement d'un serveur web. Dès lors de deux choses l'une, soit c'est compliqué et ce sera fais par un spécialiste sur un serveur centrale partagé à l'ensemble des dév, soit ce sera fais par chacun des développeurs car le gap technique est faible ou acceptable.
Et par ailleurs à parler de serveur, quid de la couche business (tout le foutoir en json pour rapatrier de la donnée personnalisée à l'utilisateur) à rajouter dans ce genre d'architecture ?
Fournissez vous des clues ou des bonnes pratiques avec votre package ?
Bon sinon j'aimes bien, si j'avais rien d'autres à foutre je crois que j'aurais volontier mis la main à la pâte de votre projet car at least nos objectifs convergent en certains points. Sait on jamais..
Par contre je sais que je hais les réseau sociaux, donc il est peu probable que je suivent vos aventures en ces lieux de débauche :°)
[^] # Re: Intéressant
Posté par Rom1 . Évalué à 3.
En fait, il n'y aucun problème avec l'unicité du fichier web. Ce n'est plus du code statique dans des fichiers HTML, mais des balises ajoutées dynamiquement au runtime par la librairie JS, c'est d'ailleurs comme cela que fonctionne EnyoJS, backbone.js etc.
Le site Nanoko implémente cette approche, Nanoko permet de faire des applications web dynamiques autonomes et non des pages générées par un serveur web. C'est une approche donc différente du développement web, et c'est comme cela que fonctionne les web apps de nouvelles générations à l'instar de GoogleDocs par exemple. C'est d'ailleurs grâce à cette approche que nous pouvons faire du client unifié et encapsulé le code Nanoko dans des applications natives via phonegap par exemple.
Pour les développements, Nanoko permet la fédération de plusieurs développeurs mais via le repository Git ou SVN du projet que vous développez, la chaîne de compilation fait le reste en allant chercher les sources des composants requis développés par d'autres sur leur propre machine et centraliser au sein du repo.
Pour ce qui est de la couche business, nous conseillons une approche MIL (medium intermediate language) basée sur du JSON via webservices ou RESTFUL, vous interagissez donc depuis le client autonome avec les web services déployés sur le Cloud.
Pour les réseaux sociaux pas de problème mais n'hésitez pas à m'envoyer un mail directement via les références mails Ubidreams dans la partie contact du site Nanoko. En tout cas rejoignez nous sur Github, c'est essentiel pour le codéveloppement de Nanoko avec la communauté open source.
Bien à vous.
[^] # Re: Intéressant
Posté par Pierre . Évalué à 1.
En effet, l'implementation du site est interressante. Par contre, vous avez oublie de le minifier! C'est sans doute pour ca que ca rame. En attendant ca permet de voir un peu comment c'est gaulé. L'approche semble interressante, meme si je trouve qu'il y a un peu trop d'html dans des map JS, mais bon ca c'est plus enyo.
Du coup ca me fait penser que ca manque d'exemple. avoir le code source du site principal semble une bonne idee (c'est du coffeescript a la base, ou pur JS?)
un TodoMVC semble incontournable..
[^] # Re: Intéressant
Posté par Rom1 . Évalué à 1.
Effectivement, on a pas minifié le site histoire que vous ayez un exemple online de site fait en Nanoko. On minifiera les futures versions.
Pour répondre à votre question, le site a effectivement été développé en CoffeeScript et Less, donc les fichiers JS sont les fichiers générés par CoffeeScript. On va sûrement open sourcer le code du site web, mais c'était soumis à 100 retweet sur ma proposition de l'open sourcer :)
[^] # Re: Intéressant
Posté par Pierre . Évalué à 1.
Je suis pas sur que les 100 retweet soit une super idée. L'open-source n'est pas un ultimatum de buzz. :-)
Quant a la minification, ca fait un peu cordonnier mal chausse. Surtout si tu veux faire du buzz, et que ton site rame a cause des tonnes de requêtes générées par la non concaténation des sources (tous ces packages.js de 3 lignes, ça fait mal au coeur). Il y a bien concaténation?!
C'est un truc qui n'est pas très clair dans la doc (une fois qu'on la trouvée). Le index.html a l'air généré a la main, avec donc le tracking des modules JS + de l'ordre potentiellement a la main. Pour moi c'est rédhibitoire!
Je critique, je critique, mais bravo et bon courage quand même, ça fait plaisir d'avoir de l’innovation a la française dans ce domaine.
[^] # Re: Intéressant
Posté par Rom1 . Évalué à 1.
Open source et modèle économique sont forcément compatibles :)
Qui dit modèle économique, dit marketing de l'open source.
Open source n'est pas équivalent à se "mettre à poil", on a besoin de payer nos 10 salariés ;)
# retour arrière
Posté par blobmaster . Évalué à 1. Dernière modification le 18 février 2013 à 23:11.
Bon le site est incompréhensible.
Et un coup je clique sur une image pour naviguer, un coup je clique sur un lien pour revenir au menu.
Mais ça c'est pas la faute du framework.
Par contre :
Il casse l'historique de navigation : retour arrière impossible ! Le framework ne semble pas gérer cela.
En plus certains liens n'ont pas la bonne icône de souris.
Et parfois quand on clique ça ne marche pas et parfois si.
En plus, c'est lent (en ressentit dld+exe).
C'est peut-être un site pour IE6.
À ce stade, ça ne donne pas envie.
Alors, si ça se trouve le produit est bon et me plairait mais je n'ai pas trouvé d'exemple, de démo de tutorial…
Ou est le Hello World (le site ne me semble pas tout montrer) ?
Et le site ne donne pas envie d'aller plus loin.
Je dis ça car il m'arrive de vouloir pousser des technos innovante (la votre pourrait me plaire) et que quand on me demande de montrer patte blanche, ce genre de "détail" fait parfois tout capoter.
Le décideur pressé n'ira pas plus loin.
Bon courage pour les objectifs. Et à bientôt pour le "Hello World".
D'ailleurs oui c'était bien écrit qu'il y en avait un dans l'article alors ou est-il ?
""Here you will find all documentation to start your own Nanoko app!""
[^] # Re: retour arrière
Posté par Rom1 . Évalué à -1.
Bonsoir, merci pour vos retours.
La barre de navigation vous permet d'accéder à l'ensemble des ressources à tout moment.
Le retour dans l'historique, le pointeur, les liens, fonctionnent pourtant sur safari, chrome, sur Android, sur iOS; quel navigateur utilisez-vous?
Vous trouverez un tutoriel dans la section Developer>Docs>, et il se nomme classiquement "Getting Started".
J'espère que vous pourrez retrouver vos billes avec ces quelques retours, je suppose que vous êtes sur IE non ? Si oui, je vous conseille vivement un navigateur moderne supportant le CSS3, sinon vous aurez des problèmes avec beaucoup de librairies telles que Bootstrap.
Je viens de comprendre votre dernière phrase, vous n'avez rien dans la section Docs ?
C'est que le traitement du markdown ne fonctionne pas sur votre navigateur donc il n'affiche rien, il faudrait absoluement que vous me disiez sur quel navigateur vous êtes. Ca nous permettrait d'améliorer la compatibilité.
[^] # Re: retour arrière
Posté par blobmaster . Évalué à 3. Dernière modification le 19 février 2013 à 06:54.
J'utilise un navigateur de kéké ; Firefox 16.0.2.
J'utilise un OS de kéké : LinuxMint (là c'est vrai)
J'insiste : Non je ne trouve pas de tutoriel dans la section Doc.
Je trouve juste la phrase, la donzelle et un gros carré noir mal centré avec la pub pour Ubidream, c'est tout (quand je clique dessus je vais là :http://www.ubidreams.com/ ).
Ah ! oui, une info. Je désactive flash
Je note dans le journal comme dans votre réponse ici que vous ne faites pas d'hyperlien. C'est lascaux ce site !
Vous pourriez faire en sorte que le JavaScript réagisse aux changement de l'url et vos problèmes d'historique et d'hyperlien pourraient se régler.
[^] # Re: retour arrière
Posté par Pierre . Évalué à 1.
J'ai moi aussi rencontre des incohérences sur la gestion du routing.
De temps en temps, il y a reload de la page entiere e.g:
si on clique sur
developer -> docs -> Cross-device market & developing analysis
Et en effet, le back ne marche pas sur chrome. Ça change l'URL, mais ça charge pas la route, la page ne change pas.
Bref, pour un site qui ce dis l'ultime technologie de l’industrie française, ça fait tache :)
[^] # Re: retour arrière
Posté par claudex . Évalué à 4.
Je n'ai aucun contenu dans les éléments du menu. Si je clique sur developer -> docs, j'ai juste le titre de la page ("Nanoko documentation
Here you will find all documentation to start your own Nanoko app!"), même chose pour le code ("Nanoko source code
Adopt Nanoko framework and create unified apps by now! ").
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: retour arrière
Posté par Rom1 . Évalué à 2.
Bug fixed, vous pouvez retourner sur le site et avoir l'ensemble des contenus.
[^] # Re: retour arrière
Posté par Rom1 . Évalué à 1. Dernière modification le 19 février 2013 à 17:19.
J'ai aussi ajouté un tuto pour "la pub Ubidreams" qui lorsqu'on appuie sur les touches < > montrent que ce sont 44 slides sur notre vision du marché et non une pub ;)
Pour la "donzelle" je transmets à Tatiana votre avis sur son avatar, moi j'aurais plus dit "amazone qui rentre dans le lard des préjugés".
Quand à "Lascaux" je me retiendrais de répondre ;)
Le site est jeune et mérite du débug, ce que je viens de faire pour améliorer votre expérience utilisateur et la bonne visibilité du contenu.
Merci à vous.
[^] # Re: retour arrière
Posté par Rom1 . Évalué à 0.
Ah oui j'oubliais, il n'y a pas de Flash sur ce site.
[^] # Re: retour arrière
Posté par blobmaster . Évalué à 2.
Ah… C'était un slide.
Bon j'étais fatigué mais c'était pas non plus totalement évident.
Et si on veut tout faire à la souris pour moins déplacer la main, on peut cliquer sur les bordures. Il manque un petit logo dans les bordures, genre <[Diapo]>.
Et j'adore le :
""" Mobile market … simple ou complex? """
du troisième slide.
[^] # Re: retour arrière
Posté par saimn . Évalué à 4.
tiens ça rejoint un sujet d'actualité … vous n'avez testé que sur Webkit ?
Je me disait bien en testant hier sur Firefox que les pages paraissait bien vides, c'était bizarre, mais ça ne m'est pas venu à l'idée qu'on était sur un site "optimisé pour Webkit" ;-).
[^] # Re: retour arrière
Posté par Rom1 . Évalué à 0.
C'est de ma faute à moi tout seul, j'ai fait le site en une semaine un peu à l'arrache. Je vais optimiser tout ça et corriger les problèmes rapidement. Merci à vous tous pour vos retours.
[^] # Re: retour arrière
Posté par Rom1 . Évalué à 1. Dernière modification le 19 février 2013 à 17:14.
Site web debuggué sur Firefox, problème de loading des fichiers markdown par showdownjs.
[^] # Re: retour arrière
Posté par Rom1 . Évalué à 0.
Après debug le site Nanoko testé et approuvé sur Safari, Chrome, Opera, Firefox.
Plus qu'à blinder le site sur IE, arf …
# bon bah si tout le monde décortiques l'objet, pourquoi pas moi
Posté par maboiteaspam . Évalué à 2. Dernière modification le 19 février 2013 à 13:07.
http://www.nanoko.org/ui/Header.js
En quoi c'est plus simple d'utiliser un descripteur en json plutôt qu'un descripteur en html pour faire ce qui ressemble à un menu dropdown ?
Sinon je préférerais tourner sur une version compilée du site pour sentir mon coeur battre.
Là…. soso. Ça me donne le sentiment d'une usine à gaz qui s'assume pleinement.
Bon après c'est p'tet le cas.
[^] # Re: bon bah si tout le monde décortiques l'objet, pourquoi pas moi
Posté par maboiteaspam . Évalué à 2.
mouep par contre il me semble que sa leak à mort votre framework.
Je me suis fais quelques aller retours entre build et philosophy, j'en suis a 7000 nodes… pas terrible
[^] # Re: bon bah si tout le monde décortiques l'objet, pourquoi pas moi
Posté par Rom1 . Évalué à 1. Dernière modification le 19 février 2013 à 15:38.
Bonjour, le descripteur JSON n'est pas du Nanoko mais du EnyoJS que nous avons combiné à Bootstrap. On va vinifier la version du site web, nous voulions pouvoir vous laisser la possibilité de voir comment tout ça était fagoté. "Ca leak à mort", faut voir avec HP pour EnyoJS et leur demander d'optimiser tout ça, n'hésitez pas à pull request si vous avez des optimisations à leur proposer. Quant à lui Nanoko permet de faire des jeux très réactif en 2D sans aucun ralentissement sur des smartphones de plus de 3 ans ;) Voir notre mini-jeu FishDish dans l'app Ubidreams Android/iOS.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.