jeffcom a écrit 1114 commentaires

- je vous aime
> vous êtes sérieux ?
- oui
> Cela me fait vraiment très plaisir mais il ne vaut mieux pas s'étendre sur le sujet je crois..;
- vous êtes fidèle ?
> Je suis très fidèle ! [ air déterminé de la demoiselle ]
- même pour de l'argent ?
> Vous voulez dire "comment faire du change" ?
- non, juste te mordiller les têtons
> Navrée, je ne suis pas là pour parler du corps humain
- je pourrais vous revoir ?
> Vous pouvez me voir quand vous voulez, mais sur ce site.
- ça vous dit un résto ?
> Navrée mais je ne suis pas là pour vous aider à préparer vos sorties.
- vous ne m'aimez pas n'est-ce pas ?
> si je vous aime bien. Mais ça n'ira pas plus loin !
- un petit bisou alors ?
> ... SMACK ! Voila votre bisou.

énorme....

(non j'ai rien d'autre à foutre là)

Bof j'ai pas l'impression que ça interprète beaucoup.

Comment ?? tu veux dire que ça n'est pas vraiment sophie qui répond en vrai ???

T_T

beau boulot \o/

L'idéal c'est le wifi mais ça peut se passer en mode data (gprs,3g....) ou bluetooth

Pour le menu, je ne me souviens plus vraiment ce que ça donne pour les Nokia, mais ça doit pas vraiemnt différer des SE : menu / outils / Sync puis 'plus/afficher profil/nouveau profil'

c'est là que tu vas entrer les paramètres de ta connexion au serveur de synchro, en suite, il te faudra cocher/décocher les éléments à synchroniser


si non via usb, cette page parle spécifiquement du 6210 : http://cookerspot.tuxfamily.org/wikka.php?wakka=NokiaPCSuite(...)

c'est ce que je disais : désespérant...

toi aussi... reprenons...

Concernant : .Net, c'est de l'asp (voir Active_server_pages) qui est utilisé et qui peut, entre autres, encapsuler du .Net, du VBScript ou Jscript et autres joyeusetés made by MS

Concernant java, c'est du jsp(/JavaServer_Pages), donc oui, le langage est le même, mais, pour le coup, est interprété...

Évidement on peut, aussi, créer son site web en C... il suffirait de prendre lighttpd et lui inclure les pages (voire le cms) directement dedans. le gain de rapidité serait pour le coup plus que fulgurant... m'enfin on conviendra facilement que c'est un peu tuer une mouche à coup de blaster laser

Après, de là à en conclure que t'as loupé un épisode...

tous les symbian normalement

moi il me parrait débile de vouloir comparer 2 types de langages dont les buts et usages sont diamétralement opposés... mais bon je dis ça, je dis rien...

Il y a aussi ScheduleWorld¹ qui et en oeuvre un serveur funambol² et permet de synchroniser son tel avec son ordi, google, et leur propre service d'agenda/répertoire en ligne. C'est pratique si on veut vraiment avoir des sauvegardes à plusieurs endroits.

Si on est (un peu) parano et qu'on veut synchroniser son téléphone sur son propre serveur, on peut tout a fait installer un serveur funambol² sur son propre serveur voire l'interfacer avec un zimbra³.

à noter par ailleurs que funambol est aussi compatible avec les téléphones non compatible SyncML (sous Win mobile, iphones, blackberry et autres) via un petit plugin et permet par ailleurs de se synchroniser avec thunder/sun-bird.


Liens [en] :
¹ http://scheduleworld.com
² http://funambol.com
³ http://zimbra.com

je vois pas qui m'as dit d'être méthodique et faire gaffe à ce qu'on fait..., j'ai beau relire, tout le monde m'a dit qu'il fallait faire des tests unitaires et compiler car le compilateur te permet d'être certain de ton code à 100%

Mon discours était simplement de dire que pour l'interprété c'était pareil, mais comme le compilo est moins strict, la méthode et la rigueur dans le code permettait de palier à ça et que c'était en amont du compilo/interpréteur que le problème se situait réellement.

Comme quoi chacun comprends ce qu'il veut...

Oui, on se doute bien qu'un code syntaxiquement/semantiquement invalide ne va pas s'executer...
Tout comme du code machine inexecutable ne s'executera pas, t'auras ton erreur, et paf.

On se doute mais Timaniac (et quelques autres) ne semblent pas l'avoir compris...

Ca nous avance pas tellement ton histoire la.

ben si, je reformulais quelquechose qui ne semblait pas logique pour certains...

Maintenant, la difference, c'est que ton erreur/warning, en interprete, tu n'as aucun moyen de la detecter avant d'executer le bout de code en question.

et ? c'est quoi le problème ? c'est pour ça que les environnements de dev existent !

Et des tests de couverture de code ecrit manuellement, c'est lourd et difficile a ecrire.

"Suffit" de pas coder avec les pieds, et de commenter ton code (avoir un codex à coté peut être un plus) et adopter des conventions de codage te permet de coder plus vite, mieux, de manière plus lisible, et de ne pas vraiment avoir besoin de tests de couverture de code écrits manuellement... bref faut avoir un minimum de méthodologie

on a pas toujours le choix des delais de developpement/test

là encore, la méthode permet d'avoir moins de cheveux blancs, car en cas de soucis, on arrive plus facilement à voir d'où ça viens, si tant est qu'un soucis arrive puisqu'on a utilisé une méthode de travail qui permet de réduire ce genre de risque.

Si en plus tu dois te rajouter des tests a la con du genre "verifier le type de retour de la fonction", tu t'en sort plus.

bah d'une part t'as pas vraiment à le vérifier (pour php du moins) puisque c'est dynamique et que les fonctions font avec. et, là encore, faut être cohérent dans son processus de dev... avant de donner une variable à une fonction attendant un tableau, il convient de vérifier qu'on lui donne bien un tableau... bref un seul mot d'ordre : méthode

En l'interprétant ! C'est la 2ème façon d'exécuter du code dis donc :)

et l'interpréteur, il produit quoi ? un code à interpréter par un autre interpréteur ? ou un code (plus ou moins) compilé ? (ces questions n'appellent pas de réponse de ta part, si non tu vas re-poster un lien vers Wikipedia)

Oué bah je préfères avoir l'erreur sur un poste de développeur ou un serveur de build.

justement, c'est là qu'elles doivent apparaître les erreurs,.. (cf autres posts où je dis qu'il faut être un peu boulet pour balancer n'importe quoi sur un serveur de prod)

Ceux qui font du Java utilise Eclipse, ceux qui font du C# utilisent Visual, dans tous les cas le temps de compilation est anecdotique, donc le temps de compilation n'est PAS un problème.

Il n'y a pas que Java et C# dans la vie... perso quand je compile ffmpeg, ça prends souvent plus d'une heure... (petite machine) la compilation est un problème dans ce cas... et tout le monde n'utilise pas java/Eclipse et C#/Visual... enlève tes œillères

Ce qu'il faudrait [...] dire : les langages dynamiques à la sémantique laxistes saimal.

C'est pas parce que ça permet certaines choses qu'il ne faut faire que ça. Sur la route, parfois il n'y a ni ligne continue au sol, ni flèches indiquant le sens de circulation, ni gendarme : c'est pas pour autant qu'il faut rouler à gauche à tombeau ouvert avec 3g.

Après le fait est que ces langages sont généralement non compilés car non compilable.

non compilables ? intéressent...

en PHP t'as toujours le choix de pas faire suffisament de tests

Tu as aussi le choix d'ignorer les warnings du compilateur et même de ne pas faire de tests unitaires sur ton code compilé... et de balancer en prod...

Sérieusement t'as déjà fait des stats de couverture de code de tests U ?

ça appelait une réponse ?

le boulot pour arriver à une telle couverture de code est énorme

[[Méthodologie]] tu connais ?
développer, ça s'improvise pas... (même si on peut improviser) c'est clair que si tu pisses du code, tu va avoir pas mal de travail pour l'auditer alors que si, dès le départ, tu réfléchis à ce que tu fais, que tu découpes ton code en modules fonctionnels, que tu le commentes, etc... il devient plutôt facile de faire quelque chose de très (plus) facilement auditable.

quelque part tu avoues qu'une partie du code n'est pas testé

si je pisse du code oui, c'est certain, mais c'est pareil avec un langage compilé...
d'un autre coté même avec un langage compilé tu ne pourras pas vraiment être certain de 100% de ton code.

Enfin, encore une fois, je ne m'amuse pas à faire de la compression vidéo en php, et je ne m'amuse pas à faire un forum en C#... ça n'est pas vraiment comparable

Un langage interprété n'est pas compilé.

Logique, si non ça s'appellerait "langage compilé"...
Mais il l'est dans une certaine mesure. Certes cette compilation est moins complète que celle d'un langage compilé (c'est logique, ça prendrais un temps fou une compilation complète et stricte à chaque appel...) mais dans la mesure où la gestion de la mémoire est gérée par l'interpréteur, de même que les accès disque et système, et que, dans le cas de php, on a pas de typage strict ni de déclaration des variables : ça n'est pas "grave"
Après le débat est tout autre (strict mieux que pas strict toussa...)
Le fait est que, même si le processus n'aboutit pas au même résultat, il y a compilation, en tout cas un mécanisme qui s'y apparente.

en gros :
→ je pond mon appli en C : je tente de compiler, j'ai des erreurs, des warnings... en cas d'erreur, ça compile pas, en cas de warning, ça compile.
→ je pond mon appli en php : je lance le script, j'ai des erreurs, des warnings... en cas d'erreur, ça se lancera pas, en cas de warning ça se lance...
\o/

Donc si tu prends 2 programmes écrits dans 2 langages "proches" (voir identique) dont l'un est interprété et l'autre compilé, avec le même niveau de couverture de code niveau tests U, celui qui est compilé reste plus "sûr"

ça aussi, c'est logique, mais on va pas faire la même appli en c et en php... il y a une notion de contraintes qu'il faut prendre en compte

Se passer de l'un des 2 va forcement avoir des implications.

C'est certain m'enfin tu ne m'as pas compris je pense... et je ne t'expliquerai pas : j'abandonne, ta rigidité d'esprit a eu raison de moi...

Ps : rassures-moi, tu n'a pas généré ton cv sur ton site web en C j'espère...

Quand je lit des trucs pareils, je me dit que tu connais pas grand choses au langages... Ou alors que tu es un integriste de l'interprete.

Bah apparemment ya des gens qui n'y connaissent vraiment rien donc je survole de très haut pour expliquer et que tout le monde comprenne... j'ai sûrement été trop rapide... et je ne suis pas intégriste non plus, simplement je ne comprends pas pourquoi ce haro totalement infondé sur le langage interprété...

En somme, quand ca pete, [...], on s'en fout un peu que ca affiche des warnings ou que ca se bourre lamentablement.

perso je m'en fout pas... au moins je sais que les autres services hébergés du serveur sont ok et que toute les ressources de la machine ne seront pas consumées par un pov script... (puisque les accès mémoire etc sont gérés par autre chose que mon script, et que le temps maxi d'exécution peut être fixé, de même que la taille max de mémoire (entre autes choses).
Donc non, on s'en fout pas : en cas de soucis, ça permet de pas mettre en péril toute la machine.
Après c'est sûr que si tu fais tomber toutes ces barrières ou que tu exécutes directement ton script php par php en root... je peux rien pour toi...

Non, le test du code doit etre bien plus exhaustif, car tu dois toi meme tester ce que le compilo teste.

waw tester ce que le compilo teste... joli :)

Bref, oui, on peut avoir la meme qualite de code avec de l'interprete, mais c'est plus dur.
Et encore, faut etre super confiant dans ses tests.

Je vois pas bien en quoi c'est plus dur... si tu as de la méthode et que tu sais ce que tu fais... ça devrait pas être plus dur.. après c'est certain que si tu as l'habitude de faire du goret et que seuls les tests te permettent de faire du code de qualité...
De plus, comme je le disais plus haut (ou ailleurs je sais plus) : c'est compilé, si non comment l'exécuter ? alors, certes, selon le langage, certaines erreurs passent la compilation, et le script peut être exécuté même s'il comporte des erreurs sémantiques ou de typage mais rien de dramatique : pour php, par exemple, au pire t'auras un warning, dans python t'auras un beau message d'erreur de compilation... ah... comme avec un "vrai" compilateur dis donc ! c'est fou quand même !

Ouch. Java, .Net, ca te parle?[...](ok, on parlait de code serveur la, donc je sort du sujet un peu).

sauf qu'il n'y a *jamais* besoin de toucher au code pour prendre en charge telle ou telle archi. Il faut simplement prendre en compte les spécificités ponctuelles de certains OS lors de l'utilisation de certaines fonctions (exemple : penser au flag "b" pour que les fichiers soient ouverts en binaire au lieu de ascii sous Win si on utilise "fopen") on est simplement conditionné à l'existence d'un portage de l'interpréteur sur l'archi cible...
En C par exemple, selon le compilateur utilisé, on va obtenir ou non une compilation, on va pas avoir les mêmes messages d'erreur, pas les mêmes warnings, pas les mêmes comportements, en plus de devoir prendre parfois en compte l'archi et la plateforme cible...
par exemple, j'ai toujours eu du mal à compiler ffmpeg... le problème ne viens pas de mon archi ou des dépendances, mais du compilo et de son paramétrage... aucun souci avec un langage interprété : si l'interpréteur et les deps sont présentes : ça se lance à tous les coups.

et, oui : java, .Net (beurk), etc. ça me parle...

Eclipse fait de la compile a la volee.

Tout le monde n'utilise/ne peut pas utiliser Eclipse...

Ca s'appelle un test unitaire

Moi je le sais, mais c'est pas certain que les autres lecteurs le sachent...

et pour qq1 qui donne des lecons sur la qualite du code

Je ne voulais pas donner des leçons mais contrer le troll qui dit que "PHP saimal parce que c'est permissif et que l'interprété saipareil parce que c'est pas compilé"

tu devrais savoir que c'est qq chose de tres tres fortement recomande pour tous les projets de toutes facons (et une condition necessaire mais non suffisante pour s'assurer de la qualite du produit).

oui, c'est pour ça que j'en ai parlé... pour quelqu'un qui réponds avec virulence tu devrais *tout* lire avant de répondre...

Conclusion :
on est tous les deux d'accord... le problème c'est que toi (et d'autres) ne semblent pas connaître suffisamment php et les autres langages interprétés pour avoir un avis vraiment impartial ou simplement prendre du recul : tout n'est pas tout rose et parfait, mais il y a tout ce qu'il faut pour faire un code très clean et avec un minimum de rigueur on s'en sort très bien

Il ne faut pas oublier, au passage, qu'on ne va pas faire la même chose en C ou en php...
Les comparaisons sont donc un peu capillo-tractées....

J'ajoute simplement qu'apparemment, pour celui qui a parlé de cette différence entre compilé et interprété, lorsqu'on dev en un langage interprété, on met forcément n'importe quoi en prod, et, qu'en plus, le fait qu'il y ait pas de compilation (qui est évidement faux) devait générer des problèmes (et des sueurs froides aux dev)

Je rectifiait simplement ces postulats, tous évidement faux... soit :
- un langage interprété va être, de toute manières, compilé avant exécution
- on ne balance pas n'imp sur un serveur de prod, de la même manière qu'on n'envoie pas un soft qui a seulement été compilé (et pas testé, et dont les retours du compilo n'ont pas été analysés) au client
- qu'on dispose de pas mal d'outils d'audit de code qui sont plus efficaces qu'une sortie de compilo combinée à des heures d'arrachage de tifs pour comprendre où optimiser le code et comment.

Je n'ai *pas* dit que :
- ça protégeait d'une quelconque faille : c'est logique
- ça permettait d'avoir *forcément* un meilleur code : là encore, c'est logique

Après, c'est certain, tout dépend du gus qui code : on peut tout faire, tout voir....

ah, bah dans ce cas si ça pète sur le serveur, c'est que le dev a mal fait son taf, et puis quand ça pète, soit ça "plante" (fatal error : ie ça s'exécute même pas), soit ça affiche des warnings (là ça s'exécute mais pas forcément bien) soit ça affiche rien (par défaut, l'utilisateur peut créer ses propres exceptions) et là charge au dev de voir si le soft fait bien ce qui était prévu...

Dans tous les cas, le dev qui sort une appli et qui la met en prod direct sans tests, un gros boulet incompétent. Le dev un tant soit peu cérébré, lui, va s'installer un environnement de dev, soit sur sa propre machine, soit sur un autre serveur (de dev) et testera son appli à fond avant de mettre en prod... bref il va tester avant de mettre en prod...

L'interprété c'est comme le compilé, ça répond aux mêmes règles de développement ! (je vois pas bien pourquoi ça serait autrement d'ailleurs) la seule différence, c'est que l'interprété, on a pas à modifier le code en fonction de la plateforme (ou presque) ni à passer des heures de compilation pour s'apercevoir que l'appli merde : on peut tester les scripts un à un, ce qui améliore considérablement la qualité du travail.
En passant, il est tout à fait possible de créer un exécutable directement écrit en un langage interprété...

J'ai du mal a comprendre comment on peut ecrire un gros projet dans un langage interprete, se passe de la detection d'erreur de la compilation,

T'es sérieux là ? comment il va s'exécuter ton code s'il est pas compilé ? :)
D'ailleurs, PHP a plusieurs étapes¹ de compilation qu'on peut résumer très rapidement (et de tête) en
- précompilation (qui inclue les vérifications du code lui même comme la syntaxe, le type de données passées aux fonctions et commandes)
- analyse et optimisation du code précompilé
- compilation et création de l'opcode²

donc il y a de la détection d'erreurs, et php sait être très verbeux quand on le configure pour.

de plus il existe des choses comme PHPUnit qui permettent d'aller très loin coté audit de code.

Oui on peut faire du super-goret, de l'immonde, du grand n'importe quoi en PHP, mais on peut aussi avoir un code d'une très grande lisibilité, d'une grande modularité et d'une grande efficacité : tous les outils (sans parler des frameworks) et les méthodes existent pour se faire.

¹ le tout effectué par le Zend_Engine qui effectue ce travail depuis php3 (la première version du PHP que nous connaissons aujourd'hui) où il était en version 0.5 (php4 utilise la 1 et php5 la 2, qui est, de très loin, la plus rapide, complète et fiable)
² cet opcode peut, d'ailleurs, être mis en cache et réutilisé lors d'un appel ultérieur du script, ainsi on a un gain de temps considérable et des perfs vraiment boostées, sans sacrifier au coté dynamique que n'offre pas un cache statique qui, lui, oblige à avoir une version figée (pas dynamique) durant un certain temps.

Sauf que Windows, ya pas vraiment moyen de combler ses failles et défaillances en mettant une option ou 2 à "off"... ça serait bien

non ? -8 ? sérieux ?

non ? Ça t'étonnes ? sérieux ?

sur http://fr.php.net/magic_quotes site officiel de PHP :
Cette fonctionnalité est OBSOLETE et a été supprimée depuis PHP 6.0.0. Nous vous encourageons vivement à ne pas l'utiliser.

Sans déconner ?... je crois que cette annonce est là depuis que PHP 6 est en alpha soit... un petit moment déjà, et avant ça, (depuis PHP5 je crois, donc encore plus longtemps) une annonce du même type indiquait le coté bancale de cette fonctionnalité et, avant ça encore, de nombreux commentaires (qui se trouvent en bas de chaque page de doc sur php.net) informaient de tout cela... donc en gros, même si quelqu'un s'est "auto-formé", s'il est passé sur la page, (chose quasi certaine tant les avertissements concernant les magic_quotes sont omniprésents dans chaque projet un tant soit peu sérieux et ailleurs sur le net) il(elle) aura vu que ça n'était clairement pas une bonne chose.

L'histoire du magic_quote c'est un peu comme le register_globals, c'est du connu depuis belle lurette...
Il es clair aussi que PHP se traîne quelques boulets pour rétro-compatibilité... mais il faut comprendre d'où viens php et en combien de temps il a évolué, comment, et vers où il va.
PHP5 préparait à l'arrivée de PHP6 tout en permettant un maximum de rétro-compatibilité avec les versions précédentes (un peu comme avec les versions 2.5, 2.6 et 3 de python)
Donc, oui, on sait, ya des boulets, on est au courant... mais dire "php c'est de la merde parce que des devs pissent du code" désolé, mais ça mérite bien une telle note... on peut pisser du code, quel que soit le langage, et tout système a ses failles, ça veut pas forcément dire que c'est le mal absolu... ou que tout ce qu'on produira avec sera de la merde

eh bien tu as une mauvaise impression...

Qui ici a un site internationalisé à l'aide d'un jeu de caractères BIG5 ?

ah c'est certain, si on n'écrit qu'en anglais, pas besoin de big5... (ni de utf-8 d'ailleurs) néanmoins, il est probable que dans un petit pays appelé "Chine" ça soit utile, le big5... même chose pour celles et ceux qui veulent permettre le support du mandarin (par exemple, langue officielle de ce petit pays)... le lien pratique est là amha

C'est pas encore d'actualité pour les applis webs en python.

Combien de serveurs sont des "apache + mysql + php" ?
Combien de serveurs ont python (avec apache ou zope par exemple) ?

Autre chose :
Combien existe-t-il d'applis web en php ?
Combien en python ?

En cherchant à répondre à ces questions tu comprendras que, pour trouver une vulnérabilité, il sera plus rapide et fructueux de chercher du php que du python, qui est, en plus, souvent camouflé d'une manière ou d'une autre et ne permet donc pas de l'identifier en tant que tel (à moins de tomber sur une erreur python auquel cas, pour le coup, aucun doute n'est possible)

le code pissé est souvent merdique

Les commentaires aussi

Parce qu'une appli en jsp, asp, python ou ruby c'est plus "secure" et "maintainable" ? Il convient surtout ne ne pas installer n'importe quoi ni n'importe comment... lorsqu'on sait pas : on fait pas et on va apprendre... ou on se tait lorsque les problèmes arrives, ou, du moins, on accuse pas "l'appli web en php"....

Il s'agit d'un ordinateur intégré dans un écran sans ventilation à destination des débutants en informatique.

Un iMac ?


désolé ~~~>[]