Wednesday, August 6, 2008
Il y a quelques années j’ai acheté un livre sur le fameux framework Ruby on Rails. J’avais beaucoup lu là dessus et je pensais que c’était vraiment formidable de pouvoir développer des application web super rapidement.
J’ai maturé et appris le PHP, parce que beaucoup plus accessible. Et j’avais mon cours de développement web dans lequel je l’apprenais.
Ces jours cis j’utilise une application web (Backpack) toute faire en Ruby on Rails, par 37 signals, ceux qui ont inventé le fameux framework. J’ai remarqué qu’il y a souvent des avertissements pour dire que tel jour il y aura une maintenance dans l’application, donc elle ne sera pas accessible pendant ce temps. Ils font ça à des heures de faible achalandage, mais quand même… C’est EUX qui ont inventé le framework Ruby on Rail et ils doivent mettre leur serveurs down pour faire de la maintenance. Je ne trouve pas ça très sérieux. Surtout quand je vois certaines autres applications qui n’ont pas besoin de faire ça aussi souvent.
Et puis il y a Twitter, une autre application fleuron du Ruby on Rails. Très populaire, et très souvent offline (http://www.istwitterdown.com/ pour voir si c’est le cas en ce moment).
Il y a ces exemples de la vie réelle, et d’autres comme ceci : http://www.networkworld.com/news/2008/062408-ruby-creators-warn-of-serious.html qui indique qu’il y a dans certaines versions de Ruby on Rails des failles exploitables qui pourraient compromettre la sécurité du serveur. Inquiet? Un peu. :-S
Donc si vous voulez mon avis, je dirais qu’il est encore un peu tôt pour s’aventurer là dedans sans être certain de ses habilités à gérer des serveurs qui hébergent une application web qui a beaucoup d’utilisateurs. Tout dépend de votre capacité à supporter le risque je dirais.
De mon côté je m’intéresse plutôt à Django comme voie de l’avenir en matière de framework d’application Web. Et aussi CakePHP, mais ça… Ça reste de la syntaxe PHP pas très élégante.
Je vais commencer mon emploi à temps plein à partir de mardi prochain (le 3 juin) chez CloudRaker. Je travaillerai à titre de Développeur Web dans cette agence qui compte environ 35 employés. Je ferai du PHP, du Python, du XHTML-CSS, du Javascript et du Ajax entre autre.
Je suis très honoré de faire partie de cette équipe de talentueux perfectionnistes et visionnaires.
Je vous en reparlerai prochainement!
@+
Dernièrement j’ai essayé d’installer la toute dernière version de CakePHP sur mon mac (en localhost). J’ai donc fait un
svn co https://svn.cakephp.org/repo/trunk/cake/1.2.x.x/ caketest
pour prendre la toute dernière version de CakePHP 1.2 beta dans une nouveau répertoire nommé caketest, et ce dans le document root de xampp.
Lorsque je tapais l’adresse du répertoire dans Firefox j’avais une erreur 500. Alors j’ai décidé d’aller voir dans mon log d’erreurs de apache (de xampp) qui est le fichier nommé “error_log”. J’y ai découvert qu’il y avait une erreur à propos du fichier .htaccess qui vient avec Cake. Il y avait une erreur de ce genre : [alert] [client 127.0.0.1] /Applications/xampp/xamppfiles/htdocs/tests/caketest/.htaccess: RewriteEngine not allowed here.
J’ai donc Googlé cette erreur et j’ai trouvé qu’il suffisait de modifier une ligne dans le fichier httpd.conf de xampp : AllowOverride All au lieu de AllowOverride AuthConfig dans <Directory "/Applications/xampp/xamppfiles/htdocs">.
Un refresh dans Firefox et tout est correct : CakePHP s’affiche dans toute sa gloire maintenant.
Comme vous savez je suis actuellement en stage chez CloudRaker. Je travaille sur la version mobile du site web et on vise particulièrement le iPhone. J’ai fait une petite découverte récemment que je crois intéressant à vous partager.
En css, on applique une background-image à une Div et l’image n’apparait pas dans le iPhone Simulator (qui vient avec le iPhone SDK). L’image ne load tout simplement pas…
Alors j’ai pensé à réduire la hauteur de l’image (qui faisais au départ environ 800×4990 px) en réduisant sa hauteur à coups de 1000. Donc une version en 4000, 3000 2000 et 1000 de haut.
Conclusion? celle de 3000 de haut ne load tout simplement pas, mais cette de 2000 oui.
Donc il y a une limitation de hauteur dans le user-agent du iPhone. Je ne sais pas si il y a la même limitation avec certaines versions de Safari, mais celle que j’ai testé sur Leopard (3.1) n’avait pas ce problème.
À noter que je n’ai pas pu tester avec un vrai iPhone, parce que le iPhone est cher et qu’ici au Canada, avoir l’internet sur son mobile est hors de prix, donc si de l’autre côté de l’océan quelqu’un pourrait tester ceci et me le dire ce serait intéressant.
Ces jours ci j’expérimente avec Django (framework Python pour faire des applications Web) et j’ai eu toutes les misères du monde à tenter de le faire fonctionner sur un Mac (Tiger ou Leopard).
Lorsque j’essayais de faire la commande python manage.py syncdb, j’avais toujours l’erreur suivante :
_mysql_exceptions.OperationalError: (2002, "Can't connect to local MySQL server through socket '/opt/local/var/run/mysql5/mysqld.sock' (2)")
Alors je n’avais aucune idée quoi faire, jusqu’à ce que je trouve ce thread sur un Google Group : http://groups.google.com/group/django-users/browse_thread/thread/9204db1ac289a623/1ee1a2951347126b
En gros, le problème est dû à un bug de MySQL qui fait que dans le fichier settings.py de Django, il faut que la ligne DATABASE_HOST au lieu d’avoir ‘localhost’ comme nom d’hôte, il faut “forcer” l’adresse ip à être 127.0.0.1, ce qui revient au même, mais c’est la petite différence qui fait que tout marche et que Django peut effectivement syncroniser la DB. Donc, en un mot, il faut que cette ligne ressemble à ceci :
DATABASE_HOST = '127.0.0.1'
Je suis content de vous accueillir sur mon blog. Sur ce blog je vous partagerai mes connaissances et découvertes dans la sphère du Web (Programmation, Design, etc).