Alors oui, je dois vous l'avouer, je me suis délecté de la vidéo du "campfire : Introducing Google App Engine" (recherchez dans youtube si vous voulez la voir). J'avais l'impression de regarder un Monthy Python, tous les ingrédients y étaient. J'ai même sans succès essayé d'imiter la voix des intervenants, ça pourrait faire rire mon entourage, avec un peu d'entraînement, et quelques verres de vin, personne n'y résistera.
Le contenu est du même esprit que la forme. Lorsque l'on utilise S3 et autres EC2, le "cloud" de Google ressemble à une farce, c'est plus d'un métro de retard un jour de grève qu'ils ont, ils marchent encore à quatre pattes, ou nagent encore dans les rivières. Pas de Java : ejb3 + annotations ou Seam, plus tous les autres framework Ajax dont on parle (Seam, echo2, GWT) que peut-on faire de mieux sincèrement, pas de jointure dans les tables, pas d'accès disque, pas d'accès aux librairies natives pour faire du traitement de l'image, que du python …
Puis, il y a quelque jours, j'ai sur ma feuille de route le besoin de faire un petit projet, qui utilisera GWT, avec quelques graphs que je générerai avec gchart. Pour ce que je veux faire, c'est l'idéale. Rien de plus simple, je download le plugin eclipse et me voilà parti. L'intégration de GWT avec un serveur d'application java n'est pas idéale, du fait que l'on programme une application répartie avec GWT, mais l'intérêt est que l'on peut choisir un serveur d'application non java. Notamment, pourquoi pas, en Python. On trouve facilement comment faire sans passer par JSON. Comme ce que j'ai à faire est assez simple, les limitations du Google App Engine ne me semblaient pas être un problème. Malgré mon scepticisme je décide donc de passer 5 minutes à lire le "getting started" qui est proposé. Ça casse pas trois pattes à un canard, puis me remettre à Python que je n'ai jamais abordé sérieusement ne me ferais pas de mal. Malgré les petits défauts qu'on lui prête, c'est un langage simple, et à mon sens, bien maintenable pour des projets pas trop gros.
Et alors là, j'ai eu un putain de choc. Pour en comprendre l'ampleur, le seul choc qui s'en rapproche dans mon existence de Geek à 2 balles, c'est lorsque j'ai découvert Qt, après avoir passé 6 mois à essayer de comprendre la MFC. D'ailleurs le choc "Qt" m'a fait utiliser Linux, et louer Mandrake (pour avoir participé à la "libération" de Qt) c'est vous dire que ça m'a marqué.
C'est TROP simple. Il y a des limitations, comme authentifier les utilisateurs de seulement Google, mais Django … Y a t-il quelque chose de plus simple que ça?
J'ai toujours respecté Python, après avoir vu OpenERP, je me disais que certains arrivaient à faire des merveilles avec, mais je ne suis jamais rentré dedans sérieusement. En fait, c'est, LE meilleur truc pour pas ce prendre la tête, et faire quelque chose de propre. Et vous, qu'en pensez-vous de Django + Google App Engine?
Journal Google App Engine ma tuer
13
déc.
2008
# Et vous qu'en pensez vous de ce journal ?
Posté par dkremer . Évalué à 10.
je ne veux pas être rabat-joie, mais ton journal est farci de sigle, trademark, nom de framework peu familier, etc.
Ça sous entend que tout le monde sait exactement de quoi tu parles et, in fine, rrempe dans le même bain culturel que toi (Qt, EC2, MFC, ejb3, ...).
Si tu pouvais faire un effort pour construire ta pensée afin qu'elle soit accessible aux autres, je suis sûr que plus de monde comprendrait ton journal et pourrait donner un avis (pertinent ou pas, mais on aurait au moins le mérite de savoir de quoi on parle au départ).
[^] # Re: Et vous qu'en pensez vous de ce journal ?
Posté par Benjamin Poulain (site web personnel) . Évalué à -7.
Enfin, je dis ça je dis rien...
[^] # Re: Et vous qu'en pensez vous de ce journal ?
Posté par Thomas Douillard . Évalué à 7.
Au passage, il n'a rien jugé à part l'obscurité du journal si t'es pas "à fond dedans" ... et je ne peux que le rejoindre.
[^] # Re: Et vous qu'en pensez vous de ce journal ?
Posté par dkremer . Évalué à 3.
http://code.google.com/intl/fr/webtoolkit/
http://fr.wikipedia.org/wiki/JavaScript_Object_Notation
http://en.wikipedia.org/wiki/Microsoft_Foundation_Class_Libr(...)
http://www.google.fr/search?q=ejb3&ie=UTF-8&oe=UTF-8
http://code.google.com/appengine/
http://www.framasoft.net/article4724.html
D'accord, maintenant je comprends bien mieux l'auteur, mon commentaire étant en partie de mauvaise foi. J'ai juste été trop paresseux pour essayer de comprendre ce que tu disais.
À présent, je ressens mieux l'intérêt de l'auteur vis à vis de son travail, et je comprends ce qu'il veur dire.
Personnellement, je suis d'accord que Django c'est un bon framework de ce que j'en ai vu. Maintenant je sais que l'on peut l'héberger pour un site perso avec Google App Engine, grace à toi, thedidouille.
Au revoir, cordialement.
[^] # Re: Et vous qu'en pensez vous de ce journal ?
Posté par dkremer . Évalué à 2.
[^] # Re: Et vous qu'en pensez vous de ce journal ?
Posté par Benjamin Poulain (site web personnel) . Évalué à 3.
Je voulais dire que des "Python est bien pour des projets pas trop gros" et "pas de jointure dans les tables", etc, montrent une grande compréhension des concepts en questions pas l'auteur, et une grande ouverture d'esprit...
[^] # Re: Et vous qu'en pensez vous de ce journal ?
Posté par dkremer . Évalué à 2.
[^] # Re: Et vous qu'en pensez vous de ce journal ?
Posté par thedidouille . Évalué à 3.
Je suis tellement fermé d'esprit que finallement je l'ai testé et vraiment approuvé. Ce que je dis concernant Python (i.e. qu'il peut-être un peu délicat à maintenir, par rapport au java) mérite un vrai débat dont il n'est pas question ici, et ce n'était que des appriories.
Pour moi Python est un langage adapté aussi aux grands projets, mais, à priori, les langages dynamique et faiblement typé sont plus délicats à maintenir. Ce n'est pas de la fermeture d'esprit.
[^] # Re: Et vous qu'en pensez vous de ce journal ?
Posté par Benjamin Poulain (site web personnel) . Évalué à 1.
De même sur S3 et EC2, c'est n'est pas la panaché non plus, quoi qu'en dise Amazon, et le modèle de Big Table est séduisant. Enfin, je dis ça mais App Engine ne m'a pas complètement séduit non plus: http://www.openyourcode.org/historique-actualite/2008/octobr(...)
Maintenant c'est vrai que j'y ai été un peu fort, et tu es manifestement ouvert d'esprit.
[^] # Re: Et vous qu'en pensez vous de ce journal ?
Posté par djibb (site web personnel) . Évalué à 3.
python ???????
On doit pas parler du même langage
>>> 1+"2"
Traceback (most recent call last):
File "", line 1, in
TypeError: unsupported operand type(s) for +: 'int' and 'str'
Python est fortement typé. Par contre la déclaration n'est pas obligatoire c'est tout.
[^] # Re: Et vous qu'en pensez vous de ce journal ?
Posté par yellowiscool . Évalué à -1.
>>> a = 1
>>> a = "salut"
Et donc, python est faiblement typé.
Envoyé depuis mon lapin.
[^] # Re: Et vous qu'en pensez vous de ce journal ?
Posté par MsieurHappy . Évalué à 4.
[^] # Re: Et vous qu'en pensez vous de ce journal ?
Posté par lasher . Évalué à 7.
Typage dynamique :
var = 1
var = "toto"
On se fiche de savoir si la variable a été déclarée avant (par exemple on peut forcer la déclaration des variables en Perl, pourtant le langage est dynamique et faiblement typé...).
Dans ce cas, à la même variable var, j'ai affecté 2 valeurs qui avaient des types différents.
Pour ce qui est du typage faible/fort :
Le langage C est faiblement typé. Ça veut dire qu'il est possible de faire ce genre de choses :
int i = 3;
i = i + 'a';
Si tu essaies avec Python de faire le même genre de choses (mélanger des int et des chaînes de caractères, des flottants et des int, ou même des objets de type différents avec d'autres objets de types différents), tu vas juste réussir à obtenir une erreur.
Donc pour résumer :
Typage dynamique : une variable peut prendre différentes valeurs, de type différent.
Typage fort : on ne peut pas additionner des choux et des carottes.
Typage faible : on peut additionner des choux et des carottes, et parfois - parfois seulement - ça a du sens ...
[^] # Re: Et vous qu'en pensez vous de ce journal ?
Posté par Charles-Hubert MOINDRON . Évalué à 1.
Mais ensuite, typage dynamique... Non ça veut juste dire qu'on connaît pas le type de la variable avant qu'une première valeur lui soit affectée. C'est à opposer à un typage statique (C...). Une fois qu'elle aura sa valeur, tu ne changeras plus son type.
Il faut donc voir deux paires de typage :
- fort/faible (est-ce qu'on va pouvoir additionner des choux et des carottes) ;
- statique/dynamique (est-ce qu'on doit, au moment de l'écriture du code, dire si on parle de choux ou de carottes, ou est-ce qu'on pourra le dire plus tard.
Python est un langage à typage fort et dynamique.
C est un langage à typage faible et statique.
Après, on pourrait aussi parler de langages comme PHP, qui est dynamique, mais qui en plus va savoir transtyper à la volée.
[^] # Re: Et vous qu'en pensez vous de ce journal ?
Posté par Quikeg . Évalué à 6.
[^] # Re: Et vous qu'en pensez vous de ce journal ?
Posté par thedidouille . Évalué à 7.
- EC2 == Amazon Elastic Compute Cloud ( http://aws.amazon.com/ec2/ )
ce sont des serveurs sur lesquels on déploie des images (AMI : Amazon Machine Image). La différence avec une machine dédiée, c'est qu'il n'y a pas de stockage, et que l'on peut déployer un grand nombre d'images à travers le monde pour que ça puisse suivre la charge. On ne paye que ce dont on a besoin, à l'heure d'utilisation, dynamiquement.
- S3 == Simple Storage Service ( http://aws.amazon.com/s3/ )
c'est le service de stockage qui est monté dans les instances des images AMI (centralisé entre plusieurs machines). Ça peut aussi servir de cache web, pour les images ou les vidéos. Les Buckets peuvent donc être montée sur des serveurs ou bien accédé via HTTP.
=>Ces 2 technos peuvent permettre de suivre la charge TRÈS simplement par rapport à une batterie de serveurs dédiées. Les AMI sont des images de distributions Linux en général.
- ejb3 == Entreprise Java Bean 3 ( http://fr.wikipedia.org/wiki/Enterprise_JavaBeans )
Les sites web n'utilise pour la plupart que ce qu'on appelle des "beans entités". Ce sont des objets java stocké dans une base de données. On peut annoté leurs champs pour dire par exemple "cette chaine de caractère doit respecter cette regexp" et "le message d'erreur est (si ça respecte pas la regexp) : votre adresse email doit contenir un @". voir le lien wikipédia. Je dis bien 3, car les EJB 3 sont beaucoup plus simple que les EJB 2 à utiliser, grâce aux annotations.
- Annotations == voir wikipedia ( http://fr.wikipedia.org/wiki/Annotation_(Java) )
En gros ça permet d'ajouter des infos aux membres d'une classe. Ça évite énormément de configuration XML
- GWT, Echo2 ==
ça permet de faire de l'Ajax, sans tapper de HTML et de javascript, comme si on fabriquait une application java normale en utilisant les toolkits Swing ou SWT. Dans le cas de GWT, il y a un compilateur qui traduit le java en HTML/Javascript, dans le cas de Echo2, le serveur génère à la volé le code de la page. (voir http://demo.nextapp.com/echo3csjs/ pour une demo)
- Seam == En gros, ça permet de faire des page template java (jsp) en plus simple et plus puissant (je sais pas quoi dire d'autre, mais c'est pas mal).
- MFC Microsoft Fondation Classe (une horreur).
Toutes ces technos sont libres (à part la MFC, EC2 et S3) et développées de manière très dynamique.
Ce qu'il faut retenir de mon poste c'est que Django c'est bien (si on connait un peu Python), et que tu peux oublier le reste si ce n'est pas ton metier.
[^] # Impressionnant
Posté par dkremer . Évalué à 4.
Je dirai que c'est impressionnant. J'étais juste désolé de ne pas avoir les connaissances nécessaires pour bien saisir ton propos, mais j'en apprends beaucoup grâce à tes explications.
Merci beaucoup pour cet éclaircissement.
[^] # Re: Impressionnant
Posté par thedidouille . Évalué à 2.
Si tu veux voir des petits trucs interessants, et que tu programmes des GUI, tu peux commencer par voir la demo d'echo2, mais je te cache pas que ce qui est très chiant avec ces technos c'est la mise en place de l'environnement.
Enfin, le tuto de Google App Engine est pas mal et est accessible ( http://code.google.com/intl/fr/appengine/docs/gettingstarted(...) ), car Python simplifie grandement les choses et la configuration. Pour développer sous eclipse il est possible d'installer Pydev ( http://code.google.com/intl/fr/appengine/articles/eclipse.ht(...) ), une fois que c'est configuré c'est difficile de s'arrêter.
[^] # Re: Et vous qu'en pensez vous de ce journal ?
Posté par Benjamin Poulain (site web personnel) . Évalué à 3.
[^] # Re: Et vous qu'en pensez vous de ce journal ?
Posté par Gniarf . Évalué à -1.
[^] # Re: Et vous qu'en pensez vous de ce journal ?
Posté par claudex . Évalué à 4.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et vous qu'en pensez vous de ce journal ?
Posté par eastwind☯ . Évalué à 4.
[^] # Re: Et vous qu'en pensez vous de ce journal ?
Posté par IsNotGood . Évalué à 2.
> ce sont des serveurs sur lesquels on déploie des images (AMI : Amazon Machine Image).
Mouaif.
Tu peux faire ta propre AMI.
Les AMI ne sont que des archives (on y met ce qu'on veut). Ça devient un OS utilisable par une instance EC2 lorsque c'est remonté sur S3 et renseigné comme tel.
D'ailleurs mon AMI a "bêtement" été faite à partir d'une de mes machines virtuelles qui tourne sur ma bécane.
Actuellement le seul problème est qu'on doit choisir un noyau/raminitrd dans une liste (mais assez étoffée). C'est le service EC2 qui lance/charge le noyau et raminitrd. Tout ce qui a après, c'est toi qui décide.
On ne peut pas actuellement faire le noyau qu'on veut utiliser (mais on peut toujours compiler et charger des modules).
> La différence avec une machine dédiée, c'est qu'il n'y a pas de stockage
En fait il y a stockage. Il y a une machine virtuelle (ce qui inclus CPU, mémoire, disque, etc). Le problème est que si tu arrêtes ta machine virtuelle, tu perds le CPU, la mémoire, et aussi évidemment le disque. NB: on paye l'utilisation à la minute de EC2. Si tu arrêtes de payer, tu perds tout. C'est bien normal.
Maintenant on peut acheter séparément la machine virtuelle (avec un disque pour au moins booter) et d'autres disques. Donc si tu arrêtes ta bécane sous EC2, tu peux garder les disques que tu as acheté séparément (mais il te faudra une machine EC2 pour y accéder).
En passant, l'ancienne autre limitation d'EC2 était l'adresse IP. Avant il n'y avait que des adresses dynamiques. Maintenant tu peux aussi acheter une adresse ip static.
> - S3 == Simple Storage Service ( http://aws.amazon.com/s3/ )
> c'est le service de stockage qui est monté dans les instances des images AMI
Pas vraiment. Les AMI sont stockées sur S3 (faut bien les stocker quelque part).
S3 est un service de stockage qui n'est pas lié à EC2. On peut utiliser l'un sans l'autre à l'exception que l'AMI doit être sur S3. Lorsque tu demandes une machine EC2, l'AMI sur S3 est copiée sur ta machine EC2 (tu peux à partir de ce moment supprimer l'AMI sur S3 si ça te chante). Tu peux utiliser S3 avec un navigateur web, avec une API Java, faire de ton espace de stockage S3 un système de fichier (sous Linux ou Windows ou quasi n'importe quoi), etc.
C'est utilisable depuis EC2 et depuis n'importe où (du moment qu'il y a un accès internet).
Il y a un cas particulier, la bande passante et les "transactions" entre une machine virtuelle EC2 et S3 sont gratuites. S'il n'y a que des machines EC2 qui utilisent S3, on ne paye que le volume stocké (très peu cher et avec garanti de service (comme pour EC2 depuis peu de temps)). La communication entre machines virtuelles EC2 est aussi gratuite (avec une belle bande passante en prime).
> =>Ces 2 technos peuvent permettre de suivre la charge TRÈS simplement par rapport à une batterie de serveurs dédiées.
EC2 et S3 sont des services finalement assez basiques. Après on en fait ce qu'on veut. C'est aussi idéal pour faire des tests (puisqu'on paye à la minute).
Mais ça n'a rien à voir avec Google App Engine.
EC2 : machine virtuelle
S3 : stockage
C'est tout.
Des services basiques mais particuliairement bien foutus.
AWS a des services plus ou moins concurrent de Google App Engine. Mais pas EC2 et S3.
> Les AMI sont des images de distributions Linux en général.
EC2 supporte Solaris et Windows depuis peu de temps (et probablement *BSD).
[^] # Re: Et vous qu'en pensez vous de ce journal ?
Posté par thedidouille . Évalué à 2.
je crois que c'est EBS pour le stockage monté dans les instances d'AMI, pour le reste, je suis d'accord avec toi. Nous (pas moi qui gère ça) on utilise des images basée sur Fedora pour EC2 et S3 pour cacher les vidéos et gérer les AMI. Je crois qu'EC2 est aussi utilisé pour faire du calcul en parallèle, mais rien interdit d'en faire ce qu'on veut.
AWS ce sont les services qu'Amazon propose par dessus EC2. Google ne propose que la partie service et aucun accès aux machines. Mais finalement si on veut faire une application qui tienne la charge, pour le développeur, il doit quelque part se retrouver avec les mêmes contraintes que ce soit avec AWS ou avec GAE (au niveau architecture), simplement avec GAE, toutes les contraintes sont intégrées d'office, alors qu'avec AWS on te laisse faire ce que tu veux avec tes EC2.
# choc culturel
Posté par bidule . Évalué à 4.
Il y a dans cette communauté un recherche paisible et aboutie du bon équilibre simplicité/propreté/puissance. Ils disent "pythonic" et ils ont des textes sacrés:
http://www.python.org/dev/peps/pep-0020/ (The Zen of Python)
Bref j'adore ...
Google (employeur entre autre de Guido Von Rossum, le BDFL python) est apparemment l'un de leur sanctuaires.
Si tu veux amplifier le choc (d'aprés ce que j'ai entendu dire) tu devrais t'interresser à Zope.
# Typo
Posté par gUI (Mastodon) . Évalué à 10.
Il faut (quand meme) une apostrophe : m'a tuer (-;
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -9.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Typo
Posté par RB . Évalué à 6.
[^] # Re: Typo
Posté par Frédéric Heulin . Évalué à 3.
# Google App Engine != AWS
Posté par Erwan . Évalué à 2.
Avec AWS tu as des machines Linux sur lesquelles tu fais tout ce que tu veux. C'est beaucoup plus puissant, mais tu dois décider d'un langage ou framework, t'assurer que ton code passe à l'échelle, répartir la charge entre tes machines (avec un load balancer par exemple)... Et c'est à toi de décider de louer des machines quand tu en a besoin (ajouter des instances), et les supprimer quand ce n'est plus nécessaire.
Google App Engine se charge de la répartition de la charge, d'allouer le temps CPU nécessaire... Au final c'est beaucoup plus simple mais aussi plus limité parce que c'est Python seulement. Donc, pas du tout la même chose que AWS.
[^] # Re: Google App Engine != AWS
Posté par RB . Évalué à 2.
[^] # Re: Google App Engine != AWS
Posté par Erwan . Évalué à 2.
Pour le déploiement c'est une fois que tes machines sont là, donc tu te débrouilles comme tu veux (genre avoir tes machines qui vont chercher le code le plus récent sur ton repo SVN de production automatiquement).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.