maboiteaspam a écrit 476 commentaires

OK!

Au fait, pour répondre à ton journal,

JQuery incontournable pour le multi plateforme
jmobile éventuellement pour aller vite et faire standard
Ko pour la data et sa syntaxe bien fichue (le coup des balises Js mélangés à aux HTML me rappels vaguement un certain PHP, ou bien n'était ce ASP ?)
Pour l'heure je part sur Jasmine pour le testing
Le reste c'est maison en version 0.-1.

angularJS j'ai testé fût un temps, mais j'ai trouvé que c'était beaucoup trop compliqué.
YUI j'ai l'expérience d'une lib truffé de leak (le comble quand on sait que l'un des dévs de JS travail sur ce projet), mais c'est ptet ma faute…. On ne le saura jamais!

a+

ah faut que je regarde ce truc de gzip. C'est le genre de mod que je fais installé par défaut, mais j'avoue ne pas connaitre sont efficacité sur des fichiers minifiés par apport aux coûts cpu de compression.

Au sujet de xml, oui c'est lisible, mais c'est aussi verbeux. Alors autant pour templater de bloc à bloc ça me parait censer, autant pour faire du string replace c'est moi qui bloque.
Mais ce n'est ptet pas le genre de problèmes que tu as eu à résoudre.
Je vais aller voir cela dans les sources à l'occasion.

Pour ce qui est de la génération des commentaires, ok c'est clair.
Je me posais cette question car je me demandais combien de temps était pris pour générer les commentaires et les impacts sur l’hébergement d'une solution de ce type là.

Au sujet de la redondance, je pense que pour faire simple, moi ça m'ennuie profondément de devoir passer le bac (at least) pour dessiner programmatiquement un carré à l'écran.

HTML ce n'est pas seulement la sémantique, c'est aussi la simplicité et l'allocation aux erreurs. Ce que C ne sait, et ne saura jamais faire par nature (il est beaucoup trop proche du flux d'opérations pour en merder ne serait ce qu'une).

Au sujet de mvvm, oui c'est un pattern, ce que je voulais dire c'est que ce pattern plus ces technos, je trouve que c'est mortel. Hors il à fais défaut extrêmement longtemps dans cet environnement, le DP.

Par contre c'est tout à fait différent de mvc. Dans l'idée c'est très similaire, médiation de la vue et du modèle, mais l'implémentation et l'usage en sont tellement différents qu'ils ont leurs raisons d'être à chacun.

Ah le coups des deux colonnes est tellement véridique. Mais on s'en affranchit tellement bien, avec un bon designer, un background ou une table.
A l'inverse si il me vient à l'esprit de faire un deux colonnes qui fadeIn au chargement, je doute de ne jamais y arriver avec Qt ou dotnet.

Finalement, et c'est déjà ce que je me disais l'autre jour après avoir posté, on mélange un peu le choux et les carottes dans notre échange ( c'est ma faute…).
Car oui gnome kde lxde et tellement d'autres ont réfléchit à leurs affaires de bureaux virtuels tout intégrés.
Mais tout ce savoir semble ne pas s'appliquer à ces nouveaux besoins qui pointent le bout de leurs nez chaque jour sur la toile :-/
Et par ailleurs, je n'ai toujours pas envie de faire des années d'études pour faire un carnet de contact un peu sexy et multi plateforme.

Et puis reste que rien n'empêche de conceptualiser le bureau comme une application à part entière…. en html. Au lieu de ces devs tellement compliqué que les variantes sont finalement bien peu nombreuse.

Mais bon le plus important reste le passage sur les légumes ; )

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.

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

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.

Nanoko est orienté développement client et non serveur

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 :°)

Et en plus tu pourras faire un truc vachement plus sexy que sur une appli desktop.

Sinon, au sujet de knockoutjs, pourquoi dis tu qu'il créé une dépendance forte ?

N'est ce pas toi qui introduit (hmm) la dépendance lorsque tu décides de spécifier ton service de données pour coller pile poil à l'UI ?

Bah je suis un peu choqué par vos réponses.

L'UE est l'institution au dessus de l’institution dans mon pays, et pourtant elle n'est pas choisie par le peuple.
godwin… alors que nombreux sont ceux qui sont mort pour la souveraineté de ce pays, la France.

Bref, devant l'unanimité dont elle fait preuve, l'ue, et sa qualité démocratique, je ne peux m'empêcher de penser que toutes les manières, ça foire grave lorsque de surcroît je suis imposé de payer pour me faire penser différemment.

En fait je me dis même que le seul genre de système qui utilise cette méthode est la dictature.

'Fin che pas, mais quand il y à eu le scandale de la vache folle on avait bien supprimé les farines animales, pourquoi est ce qu'en 2013 (ou bientôt je n'ai pas la date exacte en tête..) on autorise à nouveau ce genre de pratique.
Je sais qu'ils ont dit que désormais la poule ne mangera pas de poule, le boeuf pas de boeuf ect.
Mais vous l'avez bien vu le scandale de la viande de cheval maquillé en viande bovine ?
Scandale qui touche la nourriture de nos assiettes dont nous sommes très soucieux en France (où soit disant), pas celle de nos animaux dont on se fou royalement pour la majeure partie.
Pensez vous vraiment que ce scandale ne peut pas se répéter pour les farines animales avec des proportions beaucoup plus importante sachant que bien peu de personnes ne se pré occuperont de procéder à des tests indépendants et de qualité…… ?

Vous l'avez vu l'état de la grèce ? de l'espagne ?
On a libéraliser le marché, laisser des pouilleux leurs faire prendre de mauvaises décisions et maintenant nous les punissons jusqu'au sang (oui je peux le dire au regard des immolations récentes et répétées, même si c'est mecs là sont morts et qu'il n'y répondront pas, il semble bien qu'ils n'aient pas fais cela pour le fun, mais bien par désespoir bancaire et financier).

Et tout cela pour rembourser des dettes. De l'argent dont on peut fixer le prix sur n'importe quelle volonté politique (vous l'avez vu la planche à billet japonaise ? Illimité hein .. )

A des créanciers qui ont déjà largement de quoi bouffer et polluer chaque jour (et la je me permet cette approximation au regard des chiffres US, sa manière de re distribué la richesse, et donc la propriété des actions de ws).

bref quoi, je n'ai pas encore assimilé l'état de ma condition.
Me faire dresser pour mieux me faire saigner.
… A l'occaz ça rentrera dans ma ptite tête, ou pas.

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+

?

http://www.pauljorion.com/blog/?p=50019

J'ai jeté un oeil à la vidéo, et je dois dire que j'ai été choqué de voir que le mec à pris plus d'une demi heure sur le même slide.
Celui où il doit expliquer, pourquoi / comment, il se permet de remplacer console kit, cron, atd et quelques autres (j'en oublie la moitié désolé).

L'audience était une bande de moule réfractaire au changement ?

Dans cette histoire, le politicien n'est qu'un homme faible comme tous les autres.
Je ne suis pas sûr qu'il faille le blâmer plus que cela, même si certes l'envie de lui démonter la gueule pourrait prendre. Celui qui faut blâmer c'est le citoyen qui n'en à rien à foutre, qui ignore, qui laisse faire. De temps en temps il te dira même "Je sais !! Mais que veux tu y faire ?"
bref à vos bayonnettes au lieu de piaier.

certains pensent que le tirage au sort (du premier ministre ou n'importe quel fonction) est la solution pour lutter contre la corruption.

Une idée comme ça.

bof. Si tu cliques sur le lien tu as un report minute assez complet et détaillé. Alors si c'est pour faire du copier-coller, je ne sais pas si c'est vraiment utile, suffit vraiment de cliquer.

Après, faut il ou non leur laisser le droit de parole, je ne sais pas,
bien évidemment : )

J'ai passé un moment agréable à écouter cette émission, même si des fois je comprends pas tout ce que dit avec précision, accent oblige.
Pour te donner une idée, le contenu est l'équivalent de plusieurs journaux au format audio compilé ensemble pour faire une émission.
Donc je suis plutôt pour les laisser poster.

Ils sont pas obligé de faire du display pour faire de l'argent.
Ils se contenteront très bien de faire de l'analyse de données.
C'est ça qui est bien avec google, tout est dedans l'analyse, le display, le reporting ect Mais ça ne fonctionne que si il y à du trafic. Alors si tu arrives à tuer le trafic, le display meurt, l'analyse devient inutile et ton reporting tu le fais ailleurs.

hello,

As tu intégré une passe d'optimisation purement HTML lors de la phase de compilation ?
minification, regroupement, chargement progressif d'image, des trucs que ferait google mod_pagespeed en somme.

Quid de la qualité de développement, des impressions, avec ce couple xslt + html ?

Sinon en l'état, il y a un point qui me chiffonne tout de même.
L'opération de post de commentaire, le click, est elle complètement chaînée de proche en proche à l'opération de régénération, ou bien le fais tu à intervalle régulier ?

a+

hello,

c'est intéressant, en tout cas, moi, cela me fait réfléchir.

C'est redondant, je ne sais pas bien. J'ai tendance à penser que ce trio est une abstraction du système de dessin sous jacent. Et qu'à ce titre ce n'est pas vraiment une redondance, ou en tout cas, pas plus redondant que d'avoir GTK et Qt pour faire des applications desktop.

Le cas du bureau himself et de son rôle d'interface avec le sous système et les composants physiques de la machine, est une question à laquelle je n'ai pas d'idée car cela sort complètement de mon scope d’intérêts.

Aujourd'hui ce que je veux c'est développer multi plate forme, simple et testable. Et il s'avère que j'ai trouvé le couplage html/js/css/webservices fort intéressant et fort simple à re déployer quelque soit le système cible.
Bref, j'ai découvert le pattern mvvm, j'ai adoré.

J'ai aussi d'autres considérations, comme, plus c'est bas niveau, plus il faut être qualifié, plus il faut payer. Plus les composants sont concentrés dans une seule entité, moins c'est simple à manipuler arriver à un certain degré de complexité.
Et puis je tentes d'arriver à un véritable develop once run everywhere, qui finalement me parait plus que faisable dans cet environnement de développement et d’exécution.

Il faut aussi prendre en considération un autre fait pas technique du tout pour le coup. Une technologie qui répond à ces besoins, devra nécessairement être portée par l'économie pour se voir injecter des fonds et donc développer des solutions et un haut niveau de qualité (Alors bon des fois sa foire, voir le cas d'IE… C'est la vie).
Hors l'e-commerce, le développement des tablettes, des smartphones, des tv, des lunettes me font penser qu'à termes, c'est ce trio qui restera car de tous les points de vue c'est le plus populaire, grand public.

GTK, je n'ai rien contre, mais voilà, à part quelques applications tels que GIMP, et malgré toute la bonne volonté des développeurs, aujourd'hui c'est une audience somme toute très relative.
Alors ils peuvent si ils le souhaitent continuer en vent d'ouest, c'est un choix qui n'est guère critiquable et je leur souhaites même de réussir.

Au sujet des layouts, widgets ect, comme tu le dis c'est bien développé dans ces environnements. Mais je pense cela concerne plus le bureau, que l'application.
L'application consomme ces widgets, et le bureau doit fournir un moyen à l'application de consommer le widget.

Ce qui effectivement est complètement différent des applications de type site internet avec charte graphique spécifique ect.
On se contentera parfaitement d'une vue webkit après tout ;) Ainsi que d'un moyen de consommer les widgets.

Ta dernière remarque me semble tendancieuse au plus haut point !
Justifiée par l'expérience, mais ce n'est pas la faute des spécifications (enfin pas à ma connaissance) que l'implémentation foire.
Tentons d'en rester aux spécifications, ce sont des rêves d'ingénieurs en cours d'implémentation qui ne demande qu'à être concrétisés.

Au plaisir de te lire.

Mais pour coder dans quel environnement ?

Genre QML ? Tu utilises javascript pour t'affranchir de certaines lourdeur, mais en contre partie tu te dois quand même d'apprendre la documentation, le framework de Qt ?

Ou plutôt quelque chose dans le genre de FF OS ?

Pour moi, il est clair, que si je dois apprendre gtk+, gocject ect pour faire une appli desktop en JS sous gnome, c'est juste no way.
C'est le même sac de noeud, avec un emballage différent certes.

bref, pour faire du desktop, je pense que les applications gtk gagnerait à utiliser un composant vue webkit pour gérer l'ui telle une pure page web, mais à améliorer le support type webservice par gnome pour opérer la liaison entre ui et système. Genre un serveur web démarré par défaut en local…
Une UI portable partout, compatible partout, qui ne demande qu'à se voir adjoindre quelques specs de service système pour fournir une disponibilité parfaite quelque soit le sous système.

Pour être plus précis,

chromium-browser --temp-profile --app=http://localhost:8080/  --window-position=250,250 --app-window-size=500,600

En mode app, il semble qu'ill faut utiliser --app-window-size
en mode classique --window-size
voir http://peter.sh/experiments/chromium-command-line-switches/

Cependant, la fonction semble buggée, cf http://code.google.com/p/chromium/issues/detail?id=27550
personnellement, je suis quelque peu limité, du moins sur ubuntu.
les valeurs x,y de position de la fenêtre doivent forcément être égales, par exemple x=y=120
Si ce n'est pas le cas, le positionnement sera incorrect.

Oui effectivement cet exemple de commentaire est un peu tendancieux en ta faveur.

Si je prenais plutôt un exemple sur une fonction qui utilise le temps, ou le statut de l'utilisateur pour modifier le contenu.
Cela impliquerait que tout une logique soit déplacé,
- ou dans la vue, cf ta problématique
- ou côté serveur, ma position

At least une bonne raison de le placer côté serveur est de contrôler les accès.
Car placé dans la vue c'est permettre à tout a chacun d'accéder ce contenu.
Hors il est des cas où ce comportement n'est pas désiré.

auquel il faut rajouter un moyen de persistance qui serait en doublon avec mon git

Effectivement une base de donnée, serait un doublon.
Mais si tu voulais garder uniquement une base de fichier, ta base de données pour les commentaires, serait donc un fichier compilable.
Genre une liste ul > li, je sais pas.

Dans ce cas là, la compilation générerait plusieurs versions des commentaires
- une version public avec tous les commentaires modérés
- une version privée, avec modération des commentaires

Après avec e-tag facile à générer pour le coup, c'est très agréable à hoster.

En tout cas, cette idée de prendre le fichier comme base de stockage, et de développement me semble forte intéressante à moi aussi.

Tu ne trouves pas que c'est un peu dommage de rajouter cette étape de compilation autour de ces langages de bases qui depuis toujours ont fais la part belle à l’exécution JIT ?

Les outils choisit sont probablement très bien, mais je ne peux m’empêcher de penser qu'il y à perte d'un acquis.

Il me semble que ce sont deux choses tout à faits distinct.

L'un c'est du contenu statique, que tu peux te permettre si ça te plait, de compiler.
L'autre, les commentaires, sont tout à fait dynamique, et ce serait assez ouf de re compiler le site, re déployer, a chaque nouveau commentaire.
Ou alors, il faut partir sur des système à wake up régulier, mais cela implique pour l'utilisateur que son post n'est pas instantané.
Sachant qu'en plus tout l’intérêt de la compilation et de balancer le site on the CDN, cela commence à faire beaucoup de latence pour des fonctions que l'on sait très bien faire aujourd'hui avec des langages cote serveur.

Bref, j'ai pris partit de ne pas mélanger ces deux choses. Elles ne sont liés que par l'ui, et l'ui m'offre pléthore de solution pour mixer le compiler et le JIT selon les besoins de la fonctionnalité.

désolé pour les fautes toousa.

Ouais, le man c'est sympa.

La solution est la suivante,

chromium-browser --temp-profile --app=http://localhost:8080/ --window-position=100,100 --window-size=500,600

Les avantages, ce sera probablement cross-platform, puisque c'est dépendant du software, ici chromium.

L'inconvénient, c'est probablement pas cross-browser, ou alors il faudra trouver les options de chacun d'eux.

Merci la doc/man/ect la ml et ses archives.

Uniquement pour donner la solution complète.

Si vous utilisez liteide, il faudra aussi injecter les variables suivante dans votre.profile, sinon plus de compilation depuis l'ui.
Par exemple,
export GOPATH=$HOME/Bureau/go/last-build/mygo
export GOROOT=$HOME/Bureau/go/last-build/go
export PATH=$PATH:$GOROOT/bin

Le pourquoi du comment, le 'man' vous le dira probablement, n'est ce pas.

La solution à base de gccgo, pour toutes les bonnes raisons qu'elle peut avoir, m'ennuie,
http://golang.org/doc/install/gccgo
http://gcc.gnu.org/onlinedocs/gccgo/Invoking-gccgo.html#Invoking-gccgo
http://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html#Option-Summary

Le script que j'ai trouvé me donne exactement ce que je veux, simplement, du coup je l'ai mise dans le .bashrc et c'est tout bon.

Merci encore

Merci !

Sauf que de l'eau a coulée sous les ponts :-/

#:/usr/share$ chromium-browser --temp-profile --app=http://localhost:8080/ --display geometry 800x600+0+0
(chromium-browser:22578): Gtk-WARNING **: cannot open display: geometry

#:/usr/share$ chromium-browser --temp-profile --app=http://localhost:8080/ --display --geometry 800x600+0+0
(chromium-browser:22622): Gtk-WARNING **: cannot open display: --geometry

#:/usr/share$

Bon, j'ai un début de solution.
Je vais envisager de digger gtk, d'autres browsers.
'Fin, je préférerais tout de même éviter d'avoir à pondre une ui avec un composant webkitView inside pour simplement pouvoir définir ce comportement. Si tant est que ce soit une solution.

Tout idée est la bienvenue.

Edit : Note, j'ai aussi testé la version 1 dash -geometry, juste que cela n'apparait pas dans ma sortie de tests manuels.

Clairement l'interface est moins puissante que la ligne de commande.
Mais la flemme des fois d'utiliser la ligne de commande, à chaque fois je dois faire un man ceci, man cela pour avoir les options.
Avec l'interface c'est moins pénible de trouver ce que l'on veut faire dans ce cas.

Reste que, comme dit plus haut, ce n'est pas aussi puissant.

Mais bon j'ai bon espoir que cela s'améliore :-)