informatique et high-tech (les meilleures news) %) - Page 823

(./24652> Mais kekispasse avec ton post ? Ton spoiler vient sur 2 lignes et ce que tu as écrit sur 1
)

GT Turbo (./24651) :
http://www.frandroid.com/0-android/le-monde-de-la-mobilite/263413_du-sperme-de-saumon-pour-mieux-recycler-les-batteries-de-smartphones

Ça donne un nouveau sens à "la batterie de mon smartphone est niquée".

Plus sérieusement, on voit qu'il y a du progrès dans le recyclage des terres rares, donc un argument de moins contre les éoliennes.

GoldenCrystal (./24659) :
Oui bien sûr, mais si le but est d'avoir un site stable, tu ne va pas mettre à jour Angular JS tous les 4 matins. Même si y'a un certain nombre de trucs dont je suis pas méga fan (qu'ils ont prévu de dégager pour la v2, je crois), le framework est mature et te fournit globalement tout ce dont tu as besoin pour développer une appli. (le data binding !)

Le but, c'est aussi de rentabiliser au maximum les technos que j'apprend. Le web n'est pas mon métier, je n'aime pas ça, du coup j'essaie de miser sur des choses pérennes ^^

flanker (./24664) :
j'essaie de miser sur des choses pérennes ^^

Donc des technologies comme ça?

Non, je préfère des trucs utilisables ^^

flanker > Sur la pérénnité je pense que c'est pas trop mal. Ok peut-être que AngularJS aura une nouvelle version incompatible (sous réserve qu'elle arrive à terme un jour). Ok peut-être que AngularJS aura été remplacé par le framework MVVM dernier-cri à la mode dans 5-10 ans. Mais même si les API spécifiques changent, les principes que tu auras appris resteront, car c'est le modèle vers lequel se tournent beaucoup d'applications de nos jours.
Sinon en faisant la supposition que dans 10 ans AngularJS sera devenu une technologie non viable: Dans ce cas cela impliquerait que l'un des trois parmi HTML, CSS, JS, sera devenu une techno obsolète. Dans ce cas, n'importe quelle autre techno que tu aurais pu choisir aujourd'hui le sera également, du coup je ne vois pas trop le souci actuel

Plus sérieusement, aujourd'hui, tu as trois modèles d'application:
1 - Le modèle traditionnel, basée sur des pages HTML multiples parfois générées à la volée, lesquelles font ou pas appel à du JavaScript pour ajouter quelques effets dynamiques.
2 - Le modèle "à la mode", les applications "Single Page", qui se basent sur un framework JavaScript pour implémenter un pattern MVC (beurk), MVP ou MVVM à leur sauce. Où l'on se sépare du modèle traditionnel parce que le HTML autrefois généré à la volée, revient du HTML (ou HTML-like) codé en dur, et le code de génération côté serveur est remplacé par du JavaScript côté client. De leur côté, les données son exposées par des services REST. (De préférence, mais pas obligatoirement) Oui, je suppose que tu sais tout ça, c'est juste histoire d'être complet.
3 - Le modèle "du futur", basé sur les Web Components. C'est encore vachement du domaine de l'expérimental, et personnellement je vais attendre un peu de voir ce que ça donne chez les autres avant de m'y intéresser sérieusement. Pour l'instant je suis doucement l'évolution, et je nage un peu dans le mystère. Un bon point de départ, c'est Polymer, de Google. (Hé oui ! )

Bref, 2 et 3 mettent plus ou moins directement jQuery à la rue (en gros: AngularJS utilise quand même jQuery/jqLite en interne mais bon), bien que ce fut auparavant une solution de choix. C'est typiquement le genre de trucs qui deviennent inévitables avec le temps.
De son côté, 1 reste une solution viable pour un certain nombre de projets, bien que la majorité puissent être réalisés suivant le modèle 2.
Et le 3, lui, on verra dans 1 ou 2 ans. Si ça fonctionne, alors oui, ça mettra peut-être tes connaissances à la rue, mais quoi que tu fasses, tu n'y pourras rien

Kevin > Un truc supporté par aucun navigateur moderne, c'est pas ce qu'on appelle une technologie pérenne. C'est ce qu'on appelle une technologie obsolète.

Si AngularJS v.2 est incompatible avec la v.1, la v.1 risque d'être remplacée bien avant les 5 ou 10 ans ^^

Je vais rester encore un peu avec mon modèle d'application n°1, il me suffit pour l'instant

Tiens sinon hier soir je suis tombé là dessus:

probably the saddest graph ever shown in a CS conference. #Linux #tshirtsize pic.twitter.com/RWBnTSJ2ip

— AlexandrosKapravelos (@kapravel) September 5, 2013

J'ai trouvé ça rigolo au début, mais en fait c'est quand même assez triste…

flanker (./24666) :
Non, je préfère des trucs utilisables ^^

PyGopherd marche très bien pour la page principale et les téléchargements de CalcForge. Partout où on a besoin d'une interface à base de menus, le Gopher est la manière la plus efficace de la créer, et PyGopherd génère aussi une version HTML (cf. le lien exemple).

GoldenCrystal (./24667) :
Kevin > Un truc supporté par aucun navigateur moderne, c'est pas ce qu'on appelle une technologie pérenne. C'est ce qu'on appelle une technologie obsolète.

http://www.calcforge.org:70/ marche avec n'importe quel navigateur (à moins que ton "navigateur moderne" ne soit incompatible avec le HTTP… ).

Et sinon, pour le protocole Gopher natif (par exemple gopher://www.calcforge.org/1/):

• OverbiteFF pour Firefox,
• kio_gopher pour Konqueror et Rekonq.

C'est vrai que c'est pertinent de faire du Gopher pour le consulter en HTTP
(et mes interfaces ne se limitent pas à des menus…)

Kevin Kofler, si tu veux faire de l'administration de site web, tu devrais commencer par mettre à jour le certificat RapidSSL de votre serveur.

C'est Tyler le responsable normalement, c'est lui le contact admin officiel du serveur. Je lui avais déjà écrit un mail avant noël, je viens d'en envoyer encore un.

T'as même pas pensé à lui en envoyer un pour lui souhaiter la bonne année ?

Brunni (./24661) :'
(./24652> Mais kekispasse avec ton post ? Ton spoiler vient sur 2 lignes et ce que tu as écrit sur 1

(y'a un retour chariot en trop qui traîne dans le texte du spoiler, c'est pas fait exprès - ceci dit, l'effet est surprenant en effet)

flanker (./24671) :
C'est vrai que c'est pertinent de faire du Gopher pour le consulter en HTTP

Trouve-moi une autre technologie qui me formatte une page comme ça à partir de ça. Pas de <P>, de <A>, de <UL> et de <LI> etc. à se trimballer, pas d'entête, juste un simple fichier texte.

J'avais regardé à l'époque tout ce qu'il y avait comme download manager web-based, je n'ai trouvé rien d'aussi simple et fonctionnel que PyGopherd. (La seule alternative raisonnable niveau maintenance aurait été un index de dossier autogénéré par Apache httpd, mais avec PyGopherd, je peux mettre les fichiers dans l'ordre que je veux et rajouter des descriptions, donc c'est beaucoup plus flexible.)

Le support (natif) de Gopher n'est qu'un bonus. Et d'ailleurs, PyGopherd gère aussi le WAP (mais l'utilité de cette feature est limitée pour un site de téléchargements, il faut l'admettre – mais ça ne m'a coûté rien du tout de le mettre en place).

Ouais enfin n'oublie pas que tu peux faire la même chose avec une page HTML générique (i.e. non spécifique à ton site) avec un petit script JavaScript, sachant que le fichier texte complémentaire peut aisément être remplacé par un petit fichier JSON.

Là, tu ne fais que déplacer le problème en utilisant:
a) Une technologie obsolète (Donc un truc à installer)
b) Une passerelle entre la technologie obsolète vers une technologie plus moderne (Donc un autre truc à installer)
c) Une version obsolète de la technologie moderne qui a un rendu mochissime (Pas configurable, ou alors ça va te demander du boulot donc de faire du HTML…)

Dans le genre compliqué je sais pas trop ce qui te manque encore…

Kevin Kofler (./24677) :

flanker (./24671) :
C'est vrai que c'est pertinent de faire du Gopher pour le consulter en HTTP

Trouve-moi une autre technologie qui me formatte une page comme ça à partir de ça. Pas de <P>, de <A>, de <UL> et de <LI> etc. à se trimballer, pas d'entête, juste un simple fichier texte.

J'avais regardé à l'époque tout ce qu'il y avait comme download manager web-based, je n'ai trouvé rien d'aussi simple et fonctionnel que PyGopherd. (La seule alternative raisonnable niveau maintenance aurait été un index de dossier autogénéré par Apache httpd, mais avec PyGopherd, je peux mettre les fichiers dans l'ordre que je veux et rajouter des descriptions, donc c'est beaucoup plus flexible.)

Le support (natif) de Gopher n'est qu'un bonus. Et d'ailleurs, PyGopherd gère aussi le WAP (mais l'utilité de cette feature est limitée pour un site de téléchargements, il faut l'admettre – mais ça ne m'a coûté rien du tout de le mettre en place).

* c'est moche
* c'est super limité
* il y a des milliards de façons de générer des pages statiques bien plus jolies à partir de fichiers similaires (restructuredtext, markdown, …)
* c'est (très) moche

GoldenCrystal (./24678) :
Ouais enfin n'oublie pas que tu peux faire la même chose avec une page HTML générique (i.e. non spécifique à ton site) avec un petit script JavaScript, sachant que le fichier texte complémentaire peut aisément être remplacé par un petit fichier JSON.

J'aurais dû préciser que je veux une solution entièrement côté serveur, je suis absolument contre les sites où du code côté client est obligatoire pour la visualisation. Il y a 2 solutions raisonnables: soit une génération de pages HTML côté serveur, soit un protocole standard (= implémenté en du code qui ne dépend pas de mon site et dont la distribution n'est pas le problème de mon site) plus adapté à la situation (ici le Gopher). PyGopherd gère les deux, et laisse le choix à l'utilisateur, c'est excellent.

Là, tu ne fais que déplacer le problème en utilisant:
a) Une technologie obsolète (Donc un truc à installer)
b) Une passerelle entre la technologie obsolète vers une technologie plus moderne (Donc un autre truc à installer)c) Une version obsolète de la technologie moderne qui a un rendu mochissime (Pas configurable, ou alors ça va te demander du boulot donc de faire du HTML…)

J'ai eu un seul truc à installer: PyGopherd. Il fait serveur Gopher, serveur HTTP et passerelle tout en même temps (et sur le même port: il détecte automatiquement si la requête du client est une requête HTTP ou Gopher et répond en conséquence).

Quant à la personnalisation du rendu HTML, je n'ai fait que 2 modifications, triviales: J'ai changé le titre qui apparaît partout de "Gopher" en "CalcForge" et j'ai supprimé le paragraphe d'entête ("Welcome to Gopherspace! You are browsing Gopher through a Web interface right now. You can use most browsers to browse Gopher natively. If your browser supports it, click here to see this page in Gopher directly. To find Gopher browsers, click here.") (pour passer en Gopher natif, le lien "view with Gopher" à la fin suffit).

Dans le genre compliqué je sais pas trop ce qui te manque encore…

C'est au contraire tout simple. Il n'y a pratiquement pas de configuration à faire, le support multiprotocole est automatique.

Ben alors avec node.js, par exemple… (C'est à mon avis plus simple que d'utiliser du PHP ou autre, par contre peut être moins performant)

Tu me proposes sérieusement de coder mon propre générateur de pages parce que ce serait "plus simple" que d'installer PyGopherd qui fait tout pour moi?

.. la vache qu'est-ce que c'est moche

et sinon, il y a 6 fautes dans ton texte:
"Window$"
"Window$"
"Window$"
"Window$"
"WINDOW$"
et
"Window$"

en vrai ca s'appelle "Windows"

Tout comme "Fedora" s'appelle "Fedora" et pas "F3d0R4 lolololh4X0r5"

C'est pas F€dora? Ou bien c'est R€d Hat?

Kevin > Ah ... Jekyll ? Ca supporte ce genre de formatage de fichiers (genre en markdown) et ça permet de faire des pages qui n'aient pas l'air de sortir d'un premier TP d'informatique d'un étudiant en école d'info.

Ah mais tu veux la génération côté serveur ? hum... Tu sais quoi, je t'offre même l'hébergement pour la peine ! https://pages.github.com

Par contre je suis désolé mais ça ne supporte ni le WAP, ni le minitel. Je comprends bien que ça soit un dealbreaker pour toi cependant...

C'est tres bien le minitel

On est dans un topic sérieux ici…

• PyGopherd gère Gopher, HTTP et WAP, et c'est tout.
• Le minitel ne m'intéresse pas, et le réseau a été éteint de toute façon. Le WAP existe encore. (J'ai toujours un vieux téléphone WAP, par exemple. Mais bon, je ne me sers jamais du WAP.)
• Comme déjà dit, le mode WAP n'est pas vraiment utile pour CalcForge parce que le site (la partie qui utilise PyGopherd) ne propose que des téléchargements qui ne servent à rien sur un tel téléphone.
• Le Markdown est plus compliqué que le gophermap.

Kevin Kofler (./24687) :
On est dans un topic sérieux ici…

On est surtout sur un topic de news, si tu veux parler de la techno obsolète que tu préfères aux technos modernes, fais le ailleurs, ouvres un topic pour ça ou fais toi un post de blog.

Un jour j'avais pensé implémenter un browser wap sur ti92. mais j'avais des problèmes avec le link port. et txtrider aurait pu être utilisé à la place, donc j'ai pas poursuivi.

Pourtant il y aurais moyen de faire des trucs droles