flan a écrit 1805 commentaires

À la base, Django était un framework fait maison pour le site web d'un journal, ce qui explique certains couplages.
Mais, au cours du temps, ces modules de base (authentification, admin, …) sont passés dans le dossier contrib, qui regroupe les modules non essentiels, mais utiles quand même dans 99% des cas.

C'est aussi ça l'intérêt de Django, quasiment à chaque fois que j'ai besoin de faire quelque chose, c'est soit fourni de base dans le cœur du framework, soit dans les contrib.

Je ne suis pas sûr de bien avoir saisi ce que tu veux dire, mais dans le doute, je vais tout de même répondre.

Avec Django, tu n'es pas censé voir du SQL. Tu écris tes classes Python (*) qui servent de modèle, et tu peux utiliser des « views » génériques (qui correspondraient plutôt au contrôleur dans MVC). Il ne te reste plus qu'à écrire un template avec un peu de HTML (la vue du MVC).

Quand tu pars d'un projet existant, tu n'as aucune raison de partir de la base de données… car elle n'existe pas.

En tout cas, Django utilise beaucoup les conventions, si ça peut te rassurer.

(*) exemple :
class Book(models.Model):
title = models.CharField("titre", max_length=255, primary_key=True)
author = models.CharField("auteur", max_length=255)

Ça génèrera une table SQL avec deux colonnes de VARCHAR, mais tu pourras manipuler uniquement des objets Python.

Et au lieu de te contenter de dire ça, pourquoi ne pas expliquer en quoi RoR est-il supérieur à Django ?

On peut en effet modifier le modèle User. C'est plutôt pas mal, car le modèle d'origine est tout de même assez basique. Maintenant, on peut rajouter tous les attributs dont on a besoin. De façon générale, il y avaient un certain nombre de choses qui étaient spécifiques aux modules d'authentification et d'admin.
Maintenant, ce n'est plus le cas, et ils deviennent des modules comme les autres.

Django commence à devenir vraiment bon avec cette version 1.5 !

Par principe, je trouve curieux de critiquer l'absence de choix et de ne pas cite Adobe Reader ou Apple Preview quand on donne une liste de lecteurs PDF pour OS X. « On est gentil, on tient à vous informer, mais on ne vous dira que ce qui nous arrange ». Voilà tout l'effet que ça me fait.

Ensuite, ils me conseillent gentiment Vindaloo, qui, je cite «  is currently under active development.  » Comprendre : il existe une version 0.2 datant de 2005.
Après avoir vu ça, je ne vais même pas chercher à prendre autre chose qu'Apple Preview (qui me convient tout à fait, soit dit en passant), si le meilleur équivalent libre est de ce niveau…

Peut-être PHP 5.4.8 ? (au hasard)

Mais bon, ça me semble curieux qu'en PHP on puisse faire plus rapide qu'en C/C++.
Enfin, plus exactement, il serait plus intéressant de comparer son serveur web à un serveur classique + n'importe quel système de cache habituel avec PHP, pour voir quel est le gain apporté par l'absence de parsing (et autres) à chaque page.

Et je me demande quelle sera la différence de perf (même sans cache PHP) quand il voudra prendre en compte des configurations HTTP consommant du CPU, comme du HTTPS (avec authentification TLS mutuelle) avec Kerberos…

Bin 2% de beaucoup, ça ne reste que 2%… Autant dire que ce n'est pas ça qui va changer la face du monde. Si le trafic aérien augmente de 4% par an, que tu améliores de 2% une partie des avions, tu auras juste décalé ton augmentation de 2 ou 3mois.

Tu peux compiler et installer une application sans qu'elle passe par Apple (heureusement pour les développeurs !)

Ce que tu ne peux pas faire sans validation par Apple, c'est distribuer ton code via l'AppStore. De plus, il y a un système pour que les entreprises puissent déployer leurs applications internes sans passer par l'AppStore d'Apple. J'ose espérer qu'il n'y a pas besoin de validation d'Apple pour ce genre d'applis, mais on peut s'attendre au pire.

J'imagine que le coût du benchmark doit être pris en charge, au moins en partie, par le constructeur. Ça fait toujours une bonne pub de pouvoir annoncer avoir construit le n° X du Top 500.

Accessoirement, il doit y avoir plusieurs essais, à cause des pannes. Sur ce genre de machines, les pannes sont fréquentes et normales.

En quoi serait-ce la mort des freeware ? Il suffit de regarder ce qui se passez sur l'iPhone ou les Android pour se rendre compte qu'il y a environ 50% d'applications gratuites.

Donne donc des chiffres plus fiables. Personnellement, ça ne me choque pas plus que ça. Jailbreaker un téléphone demande tout de même quelques connaissances informatiques, même basiques (je ne vois pas ma mère le faire, par exemple), et ce n'est pas parce que tu possèdes ces connaissances que tu vas forcément jailbreaker ton téléphone. Pour reprendre une méthode de statistique fiable, au doigt mouillé, je connais pas mal de gens qui bossent dans l'informatique (avec largement le niveau pour le jailbreak), et qui pourtant ne l'ont pas fait. Mais à nouveau, si tu as de meilleurs chiffres, je suis preneur.

Apple a tout de même intégré un certain nombre de choses qui n'étaient possibles qu'avec le jailbreak dans les premières versions, ce qui le rend moins utile quand on ne veut pas d'applis piratées.

En 2011, il y aurait eu en gros 7-8% d'iPhone jailbreakés en France (loin des 75% que tu annonces), et il y aurait des applications piratées sur 38% de ceux-ci (d'après PinchMedia, je n'ai pas vu d'autres sources). Le taux de jailbreak monte à 40% en Chine, mais est entre 5 et 10% dans les pays occidentaux.

Supporter OS X, ok, mais comment ?
Avoir une « vraie » appli OS X, c'est avoir une appli qui utilise les composants du système, du genre :
- le proxy
- le correcteur orthographique et grammatical
- les raccourcis clavier (modifiables par le système)
- le trousseau de mots de passe et de certificats
- les API pour les contacts et les mails
- l'API système pour faire du plein écran

Alors, oui, ça commence à arriver, mais que ce soit avec Qt ou avec un autre toolkit, il est nécessaire d'avoir du code spécifique à OS X (comme il en faut sûrement pour Linux ou Windows). Faire du code identique quelque soit l'OS et être bien intégré au système me semble vraiment impossible, quelque soit le toolkit utilisé.

Sauf que reprendre le look & feel natif, ce n'est pas seulement changer la couleur des boutons. Par exemple, tu peux avoir un widget (composant élémentaire de l'interface graphique : bouton, liste déroulante, élément de menu, …) qui existe sur un OS et pas sur un autre, comme c'est le cas avec Vista par rapport aux autres OS. Autre exemple, avec OS X, tu as une seule icône pour toutes les fenêtres de l'application, icône que tu peux animer (faire rebondir, ou la modifier).

C'est assez loin du modèle Windows XP et Gnome 2 où tu as une icône par fenêtre, icône qui est figée. Dur d'avoir un toolkit qui adopte vraiment le style natif de chaque plate-forme.

Je fais bien la différence, mais tu peux avoir plusieurs solutions de SSO en parallèle : Kerberos qui va te logguer sur les différents sites de l'intranet de ton entreprise, Facebook qui va te logguer sur tous les sites qui utilisent Facebook pour t'authentifier (je ne connais que Clubic qui permette d'utiliser Facebook pour se logguer, mais j'imagine bien qu'il y a pas mal d'autres sites), …

Je pensais donc à un système qui stocke tous tes mots de passe (comme un trousseau d'accès), mais qui en plus gère l'aspect SSO de ces comptes (renouveler le ticket, par exemple).
Par exemple, un trousseau simple utiliserait le mot de passe associé à Clubic pour te connecter sur Clubic, alors qu'un système conscient du SSO te connecterait à Facebook si tu ne l'es pas déjà, puis utiliserait cette connexion pour te connecter sur Facebook.
Mais bon, attendons d'en savoir plus :D

Idem !
Est-ce une sorte de panneau de contrôle dans lequel on rentre tous ses identifiants (son mot de passe Kerberos, son compte Facebook, son compte Google, son certificat PKCS12, son mot de passe LDAP, …), et quand on doit s'identifier, le framework trouve tout seul le bon identifiant à utiliser ?

Ou est-ce un remplacement de PAM ?

Just par curiosité, quels sont les problèmes de distutils ? Je m'en sers régulièrement (pour faire des .deb et des .tar.gz de mes modules Python), et je trouve que cela fonctionne plutôt bien :)

Personnellement, je trouve que les extensions sont complètement archaïques. Le type MIME est pas mal, mais trop empirique (si je ne me trompe pas, il se base sur l'extension et le début du fichier, donc bien trop peu pour distinguer un .m d'un .c ou d'un .h si les extensions sont absentes).
À mes yeux, le nom du fichier (qui est choisi par l'utilisateur) ne devrait pas déterminer le type du contenu (qui est choisi par l'application).

Sur les anciens Mac OS et Mac OS X, un fichier est un triplet (nom de fichier, données, ressources), alors que sur Windows et Linux, c'est simplement un couple (nom de fichier, données).
Les ressources stockaient toutes sortes de métadonnées : type complet, mais aussi application ayant créé le fichier, application ayant ouvert le fichier (très pratique pour les images, par exemple), icône représentant le fichier (aperçu pour un PDF, par exemple).

Ça permet d'avoir deux fichiers avec la même extensions et un début de fichier similaire (donc impossible à distinguer au niveau MIME), mais modifiés par des applications différentes.

Et comme ces ressources font partie du fichier au même titre que les données, elles étaient recopiées en même temps sur les disques externes (c'est l'origine des fichiers ._.toto quand on copie un fichier toto sur un système de fichiers qui ne connaît pas les ressources, comme FAT32). Vous imaginez bien que cela a posé quelques soucis à l'heure d'internet :D

Je trouve ce système bien mieux pensé que la version windowsienne et linuxienne, même si elle n'est pas parfaite et qu'elle pourrait être améliorée.

Cette solution offre l'avantage de ne pas avoir à modifier le fichier sur le serveur distant ;)

Au passage, il n'y aura pas de Python 2.8, et il n'y aura plus de nouvelles fonctionnalités sur la branche 2.7.

Il n'y a plus qu'à attendre que les grandes bibliothèques passent toutes à Python 3 pour vraiment lancer le mouvement (PyQt est déjà compatible, Django 1.5 le sera, SQLAlchemy fonctionne, Matplotlib est bien avancé, il semble rester encore du boulot pour Twisted, PiL n'est pas être prête).

Je pense que le lien plus haut ( http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ ) donne un certain nombre de bonnes raisons :)

Je traduis l'introduction :
> * un langage doit être prédictible. […]
> * un langage doit être cohérent. […]
> * un langage doit être concis. […]
> * un langage doit être fiable. […]
> * un langage doit être débuggable. […]
> Ma position est celle-ci :
> PHP est plein de surprises : mysql_real_escape_string, E_ALL
> PHP est incohérent : strpos, str_rot13
> PHP demande de l'emballage (boilerplate), comme la gestion d'erreurs autour des appels C
> PHP n'est pas fiable (== qui n'a pas le sens habituel et qui ne sert à rien, foreach ($foo as &$bar))
> PHP est opaque (pas de stracktrace par défaut, rapports d'erreurs complexes)
>
> Ne me dites pas que « de bons développeurs peuvent écrire du bon code dans n'importe quel langage », ou de mauvais développeurs blah, blah, blah. Ça ne veut rien dire. Un bon charpentier peut enfoncer un clou avec une pierre ou un marteau, mais combien en avez-vous vus taper quelque chose avec des pierres ? […]
> Ne me dites pas que c'est la responsabilité du développeur de se souvenir des centaines d'exceptions étranges et de comportements surprenant. Oui, c'est nécessaire dans tous les systèmes. […] PHP n'est rien qu'un paquet d'exceptions […]
> Ne me dites pas que « c'est comme ça que l'API C fonctionne ». Quel intérêt d'utiliser un langage haut-niveau s'il ne fournit que quelques aides et wrappers C ? Autant écrire du C !

Le reste du texte est bien intéressant :)

Je ne fais du dev web qu'à titre perso, mais j'ai pris la peine d'apprendre Python + Django. Ça demande un investissement initial certain, mais qui est très largement rentabilisé par rapport à du PHP basique (et je trouve Django bien plus simple à utiliser que Symfony, même si je n'ai pas eu beaucoup d'expérience avec ce dernier).
Au final, avec Django, on se retrouve à écrire quelques classes Python pour le modèle de données, quelques fonctions pour les pages appelées (une page == une fonction en gros), avec quelques templates HTML, et hop, c'est fini :) J'exagère, mais à peine ^{^}

Es-tu sûr ? Même pas le «  et adressées à des tiers », qui change tout ?
Le premier paragraphe concerne les correspondances papier, le second les correspondances électroniques, mais dans les deux cas, le problème ne s'applique que quand tu n'es ni l'auteur, ni le destinataire de la correspondance.
D'ailleurs, petite citation de Me Eolas :

Eolas:
Oui, on peut les publier. Ce n'est pas une atteinte au secret de la correspondance puisque cette atteinte suppose que celui qui la commet soit de mauvaise foi, en sachant que le courrier ne lui est pas destiné. »

Diffuser le contenu d'une correspondance peut-être puni par la loi, même si on est le destinataire de la correpondance en question (ici un sexto).

Depuis quand ?
À partir du moment où l'on est destinataire du message, et qu'il n'y a pas de contraintes extérieures (genre un gros tampon SECRET DÉFENSE au-dessus :D), tu peux faire tout ce que tu veux.

Dans l'autre cas, tu n'es pas censé lire les messages qui ne te sont pas destinés (et rien qu'intercepter les correspondances est puni par la loi).

En effet, c'est peut-être le seul avantage de PHP.
Mais :
* ce n'est pas une bonne idée de faire ça,
* tu peux faire sensiblement la même chose avec Python en CGI.