Jean B a écrit 740 commentaires

Malheureusement c'est une mauvaise idée, car il suffit d'un rien pour que ces clauses ne respectent pas le droit de tel ou tel pays et deviennent automatiquement nulles.

De plus c'est un gros frein à l'adoption en milieu professionnel, car beaucoup de sociétés ont une liste blanche de licenses autorisées et ne prendrons pas le risque d'utiliser un logiciel sous une licence inconnue.

Si 3 heures de code est effectivement le premier contact c'est un peu rude.

Par contre pour un poste ou il y a beaucoup de candidats, je n'ai absolument aucun scrupule à leur faire passer un entretien de 30 minutes via skype (ou autre) où je veux les voir coder un FizzBuzz.

Sur des positions type PHP, ça filtre généralement plus de la moitié des candidats.

Peux être as-tu un commentaire constructif à opposer ?

Je sais que mon commentaire va sonner comme un troll, mais je suis très sérieux.

J'ai moi même été amené à recruter pour des positions PHP dans un lieu tout autre (Montréal) et en suis arrivé au même constat que toi.

La façon dont je le rationalise, c'est que les gens qui aiment le métier de développeur, qui aime le code bien écrit (quelque soit la définition de bien écrit), ne font pas ou plus de PHP. Et les rares qui le font encore c'est car ils ont réussit à trouver un bon poste.

Je ne saurait que trop te conseiller de te former à d'autres languages qui attirent plus les passionnés.

Et comme je l'ai dit plus haut, recherche des éditeurs ou autre sociétés qui maintiennent leurs projets sur le long terme. La vision de la qualité du code, de la gestion de la dette technique, etc y est totalement différente (ou alors ils se foutent dans le mur après quelques années)

Je dirais même plus, c'est du code qu'on aura pas besoin de jeter intégralement quand les gens du produit aurons changé d'idée pour la ennieème fois.

Oui les entreprises recherchent avant tout la valeur, mais la valeur à court terme ne fait pas tout.

Pour l'auteur: Je te conseille de chercher un emploi chez un éditeur, ou un poste R&D, tu verra que les notions de maintenabilité sont beaucoup moins souvent poussées sous le tapis que dans les sociétés de service.

à priori je ne vois aucun soucis pour faire une bête injection sql avec python-sql.

Ah ? Je ne suis pas allé voir le code, mais de base je supposait qu'il profitait de cette abstraction pour échapper les entrées de données ou forcer l'utilisation de "bindings" …

Quand tu dois construire des requêtes de manière dynamique des "formulaire de recherche avancée" etc, c'est plus pratique et sécuritaire d'utiliser un ORM ou une bibliothèque de ce genre que de container des bouts de SQL sous forme de chaines.

Cela t'offre aussi une certaine abstraction par rapport au SGBD, par exemple si tu veux utiliser Postgres en production mais SQLite en développement et en test.

Disons que c'est un compromis intéressant entre ORM et plain SQL.

Pour rajouter à ça il semblerait que Facebook considère l'idée de designer ses propres serveurs à base d'ARM: https://www.facebook.com/careers/department?dept=infrastructure&req=a0IA0000006cPWvMAM

J'ai peut être raté l'information mais je ne voit aucune mention de la possibilité de déploiement simultané sur plusieurs serveurs, chose indispensable dans un environnement avec répartiteur de charge (load balancing).

Aussi, je me pose honnêtement la question des avantages d'une intégration à Git par rapport à un outil spécifique tel que capistrano.

Spotify sur Mac

La majeure partie de Spotify est une WebKit View. Tout comme le client Steam.

Oui oui tout le monde sait que python/JS sont aussi rapide que du C++, bien sûr.

Pas sûr, par contre un développeur compétent sait que la performance brute d'un langage à toujours moins d'impact sur les performances en condition réelles que l'algorithme implémenté.

Il y a un léger gain: http://jsperf.com/jquery-1-7-2-vs-jquery-1-8/29

Rien de suffisant pour motiver seul le passage en 2.0 mais c'est tout de même une bonne nouvelle.

De plus il est possible d'inclure la uniquement pour les IE 6/7/8: http://blog.jquery.com/2013/03/01/jquery-2-0-beta-2-released/

Tu compte la bibliothèque complète, hors, il y a aussi moyen de n'avoir que certains modules.

Oui c'est d'ailleurs ça la grande nouveauté, pouvoir faire des builds personnalisés:
https://github.com/jquery/jquery#modules

avoir un langage fortement typé, ça a de gros avantages.
Ça tombe bien Python à un typage fort. Dynamique (on ne déclare pas le typage d'une variable et il peut changer) mais fort (aucune coercion implicite).

Le principal étant de détecter beaucoup d'erreurs dès la compil, et pas uniquement quand le programme passe dans le bout de code qui pose problème.

Justement, ça ce discute, mais je pense comme d'autre qu'executer le programme jusqu'à tomber sur une erreur est parfois mieux pour des débutants, étant donné que ça accélère la boucle d'essai-erreur.

À tout hasard personne n'a entendu parlé d'une étude sur les langages d'initiation ?

à part Dalvik, je n'en connais pas mais c'est faisable

C'est un petit peu au point mort suite à la libération de Java mais: GCJ

puisque c’est le Javascript qui fait tout laguer en général

Oui et non. En général le Javascript modifie le DOM, ce qui entraine un rafraichissement du moteur de rendu (reflow + repaint) et c'est ça qui est lent.

Mettre le process Javascript dans un processus externe ne changera rien. Et surtout bon courage pour avoir des perfs décentes si pour accéder au DOM ton Javascript doit faire de l'IPC.

On sort tout juste de 15 ans de "Java c'est lent ça bouffe de la RAM", vous voulez vraiment faire pareil avec JS ?

est-ce que l'accès aux webcams est faisable en l'état en JS/HTML 5 ?

Oui, c'est encore assez expérimental, mais même IE à prévu de l'implémenter, donc ça se profile pas mal.

[0] http://www.html5rocks.com/en/tutorials/getusermedia/intro/?redirect_from_locale=fr
[1] https://developer.mozilla.org/en-US/docs/WebRTC/navigator.getUserMedia
[2]http://blogs.msdn.com/b/ie/archive/2011/12/09/media-capture-api-helping-web-developers-directly-import-image-video-and-sound-data-into-web-apps.aspx

Si j'en croit cet échange[0] entre un dèv de chrome et un dèv d'apple, les deux partie se sentent rejetée par l'autre.
Webkit car Google n'a pas développé son model de multiprocess directement dans Webkit.
Et Google car plutôt qu'intégrer le multiprocess de Chromium dans Webkit ils ont implémentée une autre solution incompatible ce qui cause de la misère à Chrome pour intégrer Webkit.

[0][EN] https://news.ycombinator.com/item?id=5490242

Vous en pensez quoi ?

J'ai envie de dire pourquoi pas. Ce qui m'inquiète le plus c'est l'indépendance du programme.

Un exemple:
- Frameworks haut niveau et CMS: Prestashop, Wordpress.

Ce qui bien sûr n'a rien à voir avec le fait que Prestashop finance l'école …

On peut donc imaginer que si les investisseurs changent au cours du cursus le programme aussi, c'est pas très rassurant.

Il suffit de dire à l'élève que tu mets un & devant le nom de la variable et c'est tout, il aura des explications dans le supérieur.

C'est loin d'être le seul piège dans lequel l'étudiant peut tomber.

En physique et en maths durant le lycée, de nombreuses notions sont cachées, mises sous le tapis voire volontairement contredites jusqu'à un stade où tu peux comprendre les notions plus.

Oui cachées ou abstraites, ces notions sont totalement invisible dans le modèle qu'on présente à l'étudiant, il n'y voit que du feu. On lui dit pas "met bêtement un & à cet endroit là, ferme les yeux et ouvre la bouche".

Python permet justement de cacher des notion sous le tapis pour rendre la tache plus simple à appréhender pour l'étudiant. Ainsi tu peux leur apprendre tranquillement l'algorithmique, ce qui leur servira toujours même s'ils ne poursuivent pas l'informatique après le lycée, qui à mon avis est plus important que "reprendre le contrôle sur l'ordinateur" ce qui n'à aucune chance d'arriver vu le volume horaire.

Et une fois que tes étudiant maitrisent les bases de l'algorithmique, tu puex introduire des notions plus avancées petit à petit, et même pourquoi pas passer à des langages plus bas niveau comme C.

Mais faire apprendre l'algorithmique avec C à des lycéens qui pour la plus-part sont là par ce que "je kif call of duty" ou bien "je suis un geek je passe mes week end sur Facebook", pour moi c'est un peu comme apprendre le collage à des CP avec une tronçonneuse et de la super glue.

voire même pas de langage du tout.

Si tu fait que de l'algorithmique avec du pseudo code sur papier je te garanti que tu pert toute ta classe en deux heures.

C'est là ou je pense que Python est un bon choix comme tout premier langage.
C'est grosso modo du pseudo code executable et le shell intéractif permet aux étudiant d'apprendre par essai/erreur avec des cycles très courts.

De plus sa bibliothèque standard très fournie permet aux étudiants de réaliser rapidement quelque chose d'utile et concret, ce qui est très important pour leur motivation.

Avec C rien que recueillir une entrée utilisateur demande d'expliquer beaucoup de concepts, et la moitié de ta classe aura des segfault.

Mais je suis près à admettre qu'un Python statiquement typé serait peut être plus adapté.

Ce qu'il faut comprendre c'est que les deux licenciements sont pour des raisons de relations publiques.

D'abord le développeur qui porte le T-Shirt de son entreprise (sponsor de l'événement) qui est dépeint publiquement comme un immonde sexiste. L'entreprise prend peur et le vire sur le champ pour montrer que non monsieur PlayHaven n'est pas un repaire de machos.

Deuxième temps, suite à l'annonce du licenciement, du fait qu'il est père de 3 enfants et surtout des circonstances de l'incident, c'est Adria qui passe pour une grosse truffe et les interwebs se déchainent sur SendGrid (lui aussi sponsor), ils auraient même subi un DDOS paraît-il.

Là, pareil, même réaction, ils la virent.
Cependant dans son cas, étant donné que son boulot c'est justement de convaincre les développeurs d'utiliser SendGrid en se rendant à de multiples conférences et que son image ne vaut plus un clou et qu'il y a fort à parier qu'elle se ferait lyncher si elle mettait les pieds dans une conférence, c'est plus compréhensible de la part de l'entreprise.

Surtout que SendGrid est sur un marché très tendu (fournisseur SMTP) où passer à la concurrence ne prend pas plus de quelques minutes.

Effectivement 3Mo de JSON => 80 à 160ms sous chrome.

Attention je dit pas que chaque onglet devrait être dans un processus séparé comme dans Chrome. Juste l'interface. Je me fiche si un de mes onglets n'est pas réactif car il est en train de charger une page lourde. Mais si je ne peux pas continuer à naviguer sur els autres onglets pendant ce temps là c'est franchement pénible.

Une partie de la réponse a été donnée : passer les attentes IO en arière plan.

Beh non, les IO sont déjà pas en problème puisque toutes les opérations IO permisses par le navigateur sont "evented".

Par contre ce qu'il faut comprendre c'est que lorsque du Javascript est en cours d'execution dans une page le navigateur doit attendre qu'il finisse pour pouvoir repeindre la page et accepter de nouvelles entrées utilisateur.

Du coup si en réaction à une entrée utilisateur tu lance une opération de calcul qui prend une seconde, tu fige la page 1 seconde(ou le navigateur entier dans le cas de Firefox à moins que ça n'ai été réglé depuis).

Démonstration: http://jsfiddle.net/nDf7r/9/

une des utilités que je vois, c'est les jeux : calcul d'une partie d'image ou de coordonnées pendant que le navigateur traite l'affichage du calcul précédent.

Effectivement c'est tout à fait le genre d'opération longue mais synchrone qu'on ne peut pas se permettre de faire dans le thread principal.

En résumé les WebWorkers permettent d'exporter des fonction synchrone dans un ou plusieurs autre threads et de les utiliser de manière asynchrone.