Reprise du message précédent :
Pleins d'annonces et d'avancement chez la concurrence.
 
Ember.js 2.0 annoncé pour le 12 juin. Et c'est code en JS et il n'y a pas besoin de réécrire entièrement son application.
 
La rumeur voudrait en SV que les gens se posent des questions sur la non adoption en interne chez Google, qui serait déjà plus investi dans Polymer.

 
contribuer non, mais un fork transcompilé c'est pas difficile. donc pas genant.
lire le code source oui, typescript ne me gene absolument pas dans la lecture.

La moitié des exemples seront en type script , ça compliquera encore un peu la prise en main, un peu comme les tutos en coffee.
C'est pas très compliqué, mais ça s'ajoute a un ticket d'entrée déjà élevé.

Type Script a encore un intérêt face à ES6

Le typechecking?

il y a quelques jours on a du debugger des appels a methode qui prenait en argument soit un number, soit une string (documenté evidemment)
 
les mecs en face nous on assuré qu'ils envoyaient les bons params et que notre methode chiait. Sauf que bon, "12345" c'est pas un number les enfants c'est une string...
Le plus marrant c'est que justement on a une facade qui fait un parseInt() pour ces cas la mais ils ont décidé que non, ils allaient pas suivre la doc et tout melanger.
 
donc ouais le typage ca a un interet.

J'ai du mal à voir en quoi le typechecking aurait changé quoi que ce soit, si la méthode prend Number|String et qu'ils donnaient un String, ça serait passé comme une lettre à la poste dans tous les cas.

le typecheck de leur coté ca aurait remonté le problème lors de leurs TU et on se serait evité avoir a debogguer leur code.
Bon apres on part du principe qu'il s savent mettre en oeuvre des TU.
edit > parce que justement de notre coté le typecheck il est présent.

 
"12345" c'est pas un number

Ben quand c'est entre "guillemets" ben c'est une string aux dernières nouvelles

Je comprends pas non plus le problème, si t'acceptes une String c'est que tu sais la gérer derrière  

Si y'a des gens qui touchent aussi au design, y'a un topic blabla@webdesign    
 
C'est moins actif qu'ici

Normal, on est sur Hardware.fr, pas coloriages.com

 
function doSomething(<Number> generatedId | <String> userDefinedAlias){}
 
edit > en vrai c'est plus :
 
function doSomething(<Object> | <Number> | <String> )
 
d'ou le test sur typeof car la syntaxe clean c'est notation object
 
truc.doSomething({generatedId ,  userDefinedAlias, ... });

Interface merdique. Soit pas surpris que tes users aient du mal.

Bah OK mais t'as toujours pas expliqué en quoi ça aurait fixé quoi que ce soit, "12345" pourrait parfaitement être un string UserDefinedAlias. Avec une ontologie aussi peu précise, je vois toujours pas comment un typage explicite aurait évité le bug. J'veux dire si c'est comme ça de ton côté c'est aussi comme ça du leur, ils ont passé un string dans une fonction qui prend un string, ça match.

 
toutafé, c'est pour ca qu'on a pas eu d'erreur, le typage de leur coté ca aurait fait que leur test se serait fait explicitement sur une string pour un alias. la ils nous on envoyé une string, qu'on a traité comme un alias alors qu'ils voulaient envoyer un id.
et je suis d'accord l'interface est pourrave ca sent le patch legacy degueu.

Je suis content de te voir l'écrire

Plus sérieusement, blâme pas les utilisateurs pour ça. C'est quand même tordu de différencier un paramètre en fonction de son type sur un langage faiblement typé comme JS.

Tu n'as pas possibilité d'ajouter deux alias à cette méthode, une pour les ID, une pour les alias, et ainsi de déprécier la méthode originale ?
Ou quelque chose comme ça !?

Comme ça, si on t'embête encore avec cette méthode, tu dis qu'elle est dépréciée, qu'il faut utiliser l'une des deux autres, et donc moins de source d'erreur de la part des utilisateurs, et en plus tu peux même transtyper si besoin puisque de toute façon.

huhuhu, comment te dire...
cette methode est deja dépréciée et a deja des alternatives en fait je sais meme pas ou ils l'ont trouvé vu qu'elle est plus dans la doc qui leur a été fournie.
Ellle ne sert normalement que pour la userbase legacy en cours de migration.
 
(Je pensais que c'etait encore dans la doc en deprecated et ca y est meme plus. haha, ils sont encore plus forts que ce que je pensais.)

 
Voilà
Single responsibility principle epicétou.

Ca sent le code dégueux surtout, déjà pour tester ce qu'on a en entrée en JS le typeof n'est pas suffisant surtout si tu veux distinguer une string d'un number
isNaN() c'est pas fait pour les chiens

isNaN ça a uniquement un intérêt si l'alias doit être non numérique et que tu fais automagiquement des coercions de chaînes numériques en generatedId (bonjour le beau caca). Il a pas été défini comme tel ici.

parseInt()
 
problem solved.

Ça résout rien de plus que isNaN. C'est même pire, tout alias avec un préfixe numérique va être considéré comme un id à la place.

 
... mouais, je pense surtout que le dev d'origine il vient d'un language fortement typé et qu'il a l'habitude de surcharger. Par contre c'est sur que la signature elle est pas tip top
 

 
pour distinguer une primitive string d'une number je vois pas beaucoup mieux et explicite que typeof. mais je peux comprendre qu'en JS ca choque.
dans les deux solutions proposées (parseInt et isNaN) leur interet se situe bien coté utilisateur ou il maitrise et teste ses valeurs avant de les envoyer. ce qui revient a typer ses variables correctement au final.

Je n'ai pas trouvé la cause, et ça c'est reproduit.
Syslog est bourré de lignes de ce genre :

Je ne serait pas en train de me faire ddos ?

transform: scale(0.5) sur une table-row, ça réduit la taille de son contenu mais pas la hauteur effective de la row (donc le bas de la table remonte pas, t'as juste un tout petit bout de contenu perdu au milieu d'un grand rien)

c'est pas ça ton problème ? http://stackoverflow.com/questions [...] css3-scale

 
En ce qui concerne le deuxième quote, le problème est sûrement de ton côté : http://serverfault.com/questions/6 [...] w-to-debug
 
Quant au premier paragraphe, ca fait penser à un service de cloud monté ou non sur ta machine. Mais ca peut être plein de choses... Ca ressemble pas trop à du ddos.
 
Sinon, tu devrais augmenter suhosin memory limit: suhosin.memory_limit = 256M  (dans /etc/php5/conf.d/suhosin.ini)
 
le plantage d'apache *pourrait* être lié à ce dernier point, mais j'y crois pas trop. Fixe quand même ce problème avec suhosin.

Ce qui m'intrigue surtout c'est pourquoi et comment des ips différentes essayent d'exécuter ce script.

 
Pourquoi ? Quelle différence avec n'importe quelle "page/script" en PHP ? C'est tout à fait normal. A moins que tu n'aies qu'un seul visiteur.

Il me semblait que ce n'était accessible que via l'admin  

 
ben ca dépend des plugins, des pages etc...

Euh 2015 ? Déjà ? T1 2015 quoi
 
Ce qui serait intéressant c'est l'évolution.

Et puis populaire dans quel sens ? Dans celui qu'on aimerait ? Ou est-ce que ca reflète une quelconque présence de ces langages en entreprise ?

En général ils se basent sur les repos Github par exemple

Ou pas
http://blog.codeeval.com/codeevalblog/2015

j'avais mis le lien sur l'image

Bien vu, mais sur HFR+ impossible d'ouvrir la page, au tap ça ouvre l'image