CrEv a écrit 4577 commentaires

Clojure/Ada/Ruby :-)

Ça fait peur!

Qu'est-ce qui fait peur dedans ? Vraiment hein.

L'un des gros projets que j'ai en tête est un jeu en ligne avec des clients desktop, web et mobiles.
Je me vois mal maintenir une base de code avec plusieurs langages…

Et pourtant, c'est probablement la meilleure chose à faire.
Java sur le desktop ? Niveau intégration multiplateforme c'est en général assez nul. Sur le mobile ? Heu, java sur iOS ça doit être assez marrant :-)
Sur le web à moins de faire du vaadin (ou équivalent, et encore) tu vas devoir prendre autre chose que du java (au moins partiellement)

Pourtant, tu pourrais très bien faire ton serveur en java (guice, jaxrs, etc) et avoir des clients différents. Et oui des langages différents. Mais c'est utiliser des langages (et sdk) différents qui va te permettre d'avoir des choses intégrées et adaptées à la cible.
M'enfin pour le serveur en fait je trouve clojure avec liberator (par exemple) plutôt bien foutu et agréable. korma si tu as besoin d'une bdd.
C'est rapide à coder, c'est expressif, say bien.

Ha oui, ou sinon jseverywhere ! un serveur en node.js, clients js partout et hop. Et à la rigueur une compile js -> asm.js pour gagner un peu en perf.

Ça dépend toujours de ce que tu veux faire. Le langage ne fait pas tout, l'intérêt de java étant bien évidemment les libs compatibles avec la jvm (en même temps vu que sans tu ne peux rien faire…)
Maintenant côté langage intéressant il y en a plein. Certains vont te sortir elixir par exemple, ou ruby. En ce moment par exemple je fais du clojure au taff, et c'est quand même plutôt bien, vraiment pas envie de retourner sur du java.
Et je fais aussi toujours beaucoup de js parce que j'aime bien.
Et je regarde de temps en temps Ada (entre autre parce que ma boite en fait) et c'est vraiment intéressant. Par exemple la gestion de la concurrence est vraiment pas mal, (très) loin devant java.
Dans tous les cas ce qui est mieux c'est surtout l'expressivité, java en manque cruellement. N'importe quel langage plus expressif sera plus intéressant.
Par exemple passe sur un autre langage que java tout en gardant la jvm, groovy/jruby si tu aimes le style, clojure parce que c'est bien et cool pour gérer des ensembles de données.
Ben voilà, remplace Java/C++/Python par Clojure/Ada/Ruby :-)

et tu utilise vraiment terminology ? vraiment ?
à chaque fois que je vois cette vidéo j'ai envie de vomir

et pourtant je la trouve caractéristique de ce que j'aime pas chez e17 : le style, les effets graphiques inutiles et bien kitsch (un peu comme une voiture avec des néons…)

Le isEmpty date de la 1.6 sorti en 2006. Beaucoup de développeurs ont été traumatisé par la merditude des débuts de Java, mais c'était il y a 7 ans quand même…

Cool, c'est pour ça que j'ai encore vu tourner du code en 1.5 il y a quelques mois.
Mais c'était juste un exemple de la lenteur avec laquelle Java évolue. Alors oui à partir de java 1.8 on commence à avoir des trucs intéressants, mais franchement comparé à d'autres langages c'est pathétique.

car Java est utilisé par la majorité des développeurs

Aucun rapport, ça n'en fait pas un bon langage pour autant.
Il suffit de voir combien de temps il a fallut pour avoir nombre de fonctionnalités de bases. Juste un exemple au pif, le fait par exemple de ne pas avoir de isEmpty sur les String.
Et franchement sans les libs apache (mouai) ou guava (mieux) java serait assez peu utilisable.
Dans beaucoup de cas Java est choisi sans prendre en compte les qualités (nope) et défauts du langage mais en regardant l'écosystème, les libs et parce que c'est bien corporate de faire du java donc say bien.

Par contre, C# est pour moi un bien meilleur langage et oui il est en avance sur Java depuis un bon moment…

Non.
La différence entre minifier est obfusquer est simpler. Obfusquer c'est volontairement rendre illisible. Minifier c'est volontairement dans un but de performance. Après aujourd'hui quasiment plus personne ne minifie (enfin je crois) mais la plupart du temps c'est de la compilation javascript vers javascript. Et l'un des meilleurs exemple est Google Closure compiler qui permet de faire des trucs vraiment bien genre inline de méthodes, suppression de code mort, etc.

parce que Symfony1 est à l’arrêt depuis maintenant 1 an

Le fait qu'un code n'évolue plus ne justifie pas un fork, il faut qu'il y ait une autre raison.

reprendre l’ensemble des fonctionnalités dépréciées dans PHP

ça ok, c'est plutôt une bonne raison.

Ça ok, mais ça n'en fait pas un besoin pour forker symfony 1.
Pour que ce soit intéressant il faut qu'il y ait des problèmes dans symfony 1, des manques, quelque chose quoi.

quel est le besoin ?
cool vous forkez symfony 1 mais pourquoi ? qu'est ce qui ne va pas actuellement, etc ?

La procrastination fera le reste: t'es pas près de le faire…

Sauf que ce n'est pas la procrastination qui fait que les gens sont chez Google (ou autre) mais en général plutôt l'absence d'une vrai alternative à fonctionnalité équivalente.
Les gens vont en général là où les fonctionnalités jugées nécessaires sont.
Si tu prend gmail par exemple, le jour où il y aura un équivalent (ce qui ne veut pas dire clone d'ailleurs) à leur webmail et la gestion des labels alors il pourra y avoir départ. En attendant c'est en partie pour cette raison que les gens sont chez GMail, pas la procrastination.
Le truc c'est que les produits google répondent en général aux besoins de utilisateurs. Et souvent il faut pas mal de temps pour que les autres s'en rendent compte et tentent ensuite de rattraper leur retard.

D'ailleurs c'est un des points que j'aime beaucoup avec Google. Les détracteurs disent que c'est une politique d'enfermement que d'aller chez eux, mais ils fournissent justement (et de manière non uniquement ponctuelle) les outils pour sortir de chez eux (ou rentrer).
Finalement c'est assez similaire (sans être à ce point) comme aller chez github en se disant que de toute façon si ça ne va pas on récupère le clone et le pose ailleurs.

ni une base de données sociales

Un peu quand même

ni centralisé

ha si
Si tu te limite au dépôt git en effet ça ne l'est pas. Si tu prend en compte la gestion des pull requests, le bug tracker, etc alors oui c'est centralisé.

Après moi je n'ai pas de problème avec eux, mais c'est pas libre, c'est centralisé et ça a écrasé toutes les solutions "libres" similaires.

Si tu veux être pris au sérieux quand tu quotes, soit gentil et laisse ma parenthèse complète

Je l'aurais fait si je souhaitais parler des deux autres points. Et franchement je ne vois pas le problème de parler d'un des points en particulier, sinon ça veut juste dire que le langage n'est pas un choix horrible.

il faut un environnement particulier pour héberger du RoR

heu… il faut un environnement particulier pour héberger quoi que ce soit. Les machines ne sont pas livrées en standard avec du PHP hein.
Et d'ailleurs aujourd'hui comment se fait une app PHP ? Avec composer en général. On arrive alors grossièrement à exactement la même situation qu'une appli ruby avec bundler (ce qui est quasi tout le temps le cas).

Ruby sans RoR ? Quel est les problème ? Des app sinatra par exemple ça existe.

Et ce n'est que le premier mot de ma parenthèse

Ha ok, donc comme c'est le premier mot il ne faut pas en parler ? Ridicule.

Les utilisateurs de Facebook et Google+ sont à mon sens irrécupérables

Voilà pourquoi de nombreux projets "libre" ne fonctionneront jamais à grand échelle.
Pour se marrer il suffit de voir le nombre de "libriste" ayant un compte facebook, google+, github, etc.
Et manque de pot ce sont justement les utilisateurs. Et en majorité ils ne sont pas irrécupérables, c'est juste que ce sont des utilisateurs qui s'attachent aux fonctionnalités et non à la philosophie sous-jascente (tu comprends, notre truc il fait moins de chose mais c'est libre et décentralisé. Oui mais je veux faire bla bla. Pas possible mais on est libre et décentralisé -_-)

ça me parait raisonnable d'observer tous les réseaux Libres populaires qui existent avant de se lancer. À ma connaissance XMPP est un bon choix.

Mais XMPP est un protocole et non un réseau libre. Et il est populaire essentiellement par les réseaux proprios l'utilisant.

En ce qui concerne le protocole, je prends ça pour de la mauvaise foi ou alors j'attends un peu d'argumentation.

Relis bien :

tout en étant extrêmement robuste puisqu'implémenté dans au moins 6 logiciels différents

Tu peux implémenter un protocole dans autant de logiciel que tu veux ça n'en fait absolument pas quelque chose de robuste.

Je persiste, le fait qu'un protocole soit implémenté dans plusieurs logiciel n'a aucune valeur sur le fait que le protocole soit robuste ou non. Il n'y a pas de lien. Je peux faire un protocole moisi et l'implémenter dans plusieurs logiciels, le protocole sera toujours moisi.

Il y a aussi le Data Liberation Front

The Data Liberation Front is an engineering team at Google whose singular goal is to make it easier for users to move their data in and out of Google products. We do this because we believe that you should be able to export any data that you create in (or import into) a product. We help and consult other engineering teams within Google on how to "liberate" their products. This is our mission statement:

Users should be able to control the data they store in any of Google's products. Our team's goal is to make it easier to move data in and out.

les gros projets tels que Diaspora font des choix techniques horribles (langage

Genre parce que c'est en ruby ?
Si tu veux être pris au sérieux comme pas par un troll en faveur du projet auquel tu contribues. Surtout lorsqu'ensuite on lit

Movim a tout misé sur le PHP

Côté choix technique horrible, c'est plutôt pas mal en effet.

Le langage reste souvent en réalité anecdotique. Et le meilleur est souvent celui que tu maitrise. Parce que bon installer des softs en nodejs, en ruby, en php, en java c'est aujourd'hui en gros équivalent.
A la rigueur je dirais qu'un truc qui ne peut pas s'exécuter sur heroku c'est triste aujourd'hui.

Les utilisateurs du réseau XMPP sont un public de choix

Sauf qu'ils n'existent pas vraiment. Il y a les utilisateurs de gtalk, les utilisateurs de facebook, les utilisateurs de hipchat, les utilisateurs de …. Mais les utilisateurs de XMPP en soit non. Et d'ailleurs les utilisateurs s'en foutent mais alors vraiment bien de XMPP. Ce qu'ils veulent c'est des fonctionnalité, de l'ergonomie, de l'utilisabilité, du fun (ce que personne n'a vraiment compris quand il y avait msn vs jabber), etc. Mais XMPP on s'en fout en soit. Ce n'est qu'une techno.

tout en étant extrêmement robuste puisqu'implémenté dans au moins 6 logiciels différents

Tu peux implémenter un protocole dans autant de logiciel que tu veux ça n'en fait absolument pas quelque chose de robuste.

Y'a pas un problème de méthode quand même ?

je convainque le vendeur d'utiliser paylib et je cours m'inscrire de ce pas !

Si je comprend bien, tu as convaincu le vendeur d'utiliser un truc que tu n'as jamais utilisé, ni même testé, ni même créé un compte ? Sérieux ?

$ time git branch
* bla
  master
hub branch  0,09s user 0,02s system 96% cpu 0,118 total

$ time cat .git/HEAD
ref: refs/heads/bla
cat .git/HEAD  0,00s user 0,00s system 77% cpu 0,003 total

Sachant que dans les deux cas il va falloir parser la sortie pour extraire réellement la bonne présentation.

Comment ça c'est pas une belle démonstration ?
Je dis pas qu'on peut tout faire avec. Mais une partie oui. Les commandes git sont faites pour l'utilisateur, pour le reste il est souvent plus intéressant de descendre dans les commandes bas niveau de git ou même .git.

l'appel git donc cela ne change rien ou si peu.

ça doit dépendre aussi comment ça fonctionne (je n'ai pas regardé pour liquidprompt)
Car avec git il y a deux moyens d'avoir les infos :

1. lancer des commandes git et parser le résultat -> lent et mauvaise solution la plupart du temps
2. aller lire le .git ce qui se fait avec du grep, sed, awk, … et qui est tout de suite moins lent

il faut avouer que la syntaxe résultante manque un tout petit peu de légèreté, non ?

Dans ce cas, un alias suffit, non ?

OK, donc leur campagne contre les chromebooks n'est pas visible par ceux qui utilisent des logiciels libres…

hum, pas grand chose d'étonnant là dedans, c'est pas tellement le public visé…

mais surtout parce que c'est un minitel en couleur où c'est un serveur central qui gère et contrôle tout ce que fait l'utilisateur

tu peux aussi utiliser tes propres services que tu héberges non ?
c'est un peu comme android, c'est pas parce que tout est fait pour bénéficier des comptes google (le contraire serait pour le moins ridicule) que ça t'empêche d'utiliser autre chose comme outil/logiciel/service

vu que je n'avais pas fait le rapprochement entre OSEF et OSEF oui

hop putain j'ai été mauvais sur celle là… -_-'

mais encore ?

(désolé je fais une allergie aux "merci de")

J'aime beaucoup le passage

Besoin de connaissances et de compétences techniques

Suivi dans le descriptif de leur solution idéale :

• système de templating HTML / CSS basé sur Smarty
• système évolué de cache, CDN, compression JPEGmini
• URL-rewriting, Robot.txt, SiteMap

Tout de suite, vachement moins besoin de connaissance techniques…

Exactement. Surtout que ce qui compte est beaucoup plus la manière de réfléchir, la capacité à apprendre que juste les connaissances à un instant donné car elles évoluent.
Et je dis ça justement pour avoir changé de langage assez souvent. Genre je suis dans une boite où je suis allé parce qu'ils font de l'Ada, finalement je fais du clojure, sachant que je n'avais fait ni l'un ni l'autre avant. Autant dire qu'on aurait pu me poser des questions sur l'un ou l'autre en entretien c'était mort. Enfin tout dépend ce qu'on teste pendant l'entretien.

Et pour en revenir au sujet du post, quelqu'un pourrait être bon pour détecter des comportements idiots dans un code sans pour autant "savoir" le coder immédiatement. Parce qu'il pourrait voir des structures incohérentes, des mauvaises pratiques, etc, quelque soit le langage d'ailleurs.