j'aime bien la philosophie (pas de bdd...). jme demande s'il existe la meme chose en ruby ou python parce que bon, quand j'ouvre un .php mes yeux brûlent.
ouais. on pourra plus dire qu'il y a 3 ans Linux c'était pas desktop-ready et pas user-friendly.
Ah, merde ! On me dit dans l'oreillette que c'est toujours pas le cas aujourd'hui. Pardon aux familles, toussa...
Non ! Halte ! Qui c'est celui là qui trolle ? Y a que moi qui ait le droit de troller sur Apple et MacOS X ! C'est moi le fanboy Apple ici, mais euhhhhhh !!!!!!
Tu n'est pas le 1er à vouloir un CMS qui soit à la fois simple, flexible, bien écrit, avec une API clean, qui puisse permettre de créer des formulaires, se connecter à du Windows tant qu'on y est, faire le café, te tondre la pelouse le dimanche, etc.
C'est juste que cela ne s'appelle pas un CMS, mais.... <roulements de tambours> un framework Web ! <applaudissements du public ravi>
De plus,
tu utilises beaucoup le mot "stable" dans ton commentaire.
Chaque développeur a sa définition du mot "stable", certaines librairies sont très stables en master et leurs développeurs ne releasent pas souvent de nouvelles gems, et d'autres c'est l'inverse.
Lorsque tu développes une application Ruby avec des dizaines de gems, utiliser constamment les versions stables des gems n'est pas forcément la meilleure chose, tout comme utiliser toutes les gems en branche "master".
C'est pour cette raison que la philosophie de Bundler laissant le choix au développeur de setter ses dépendances sur une release officielle considérée "stable" ou un dépôt est selon moi bonne.
La seule chose qui compte c'est que les tests unitaires/fonctionnels pour TON application passent pour une version donnée de chaque librairie utilisée (que celle ci soit considérée stable ou instable par son auteur n'a aucune valeur).
dépendant d'un dépot git qui par définition est constamment mouvant.
Le dépôt Git peut bouger, voir théoriquement casser ton application, mais lorsque tu installes le bundle, Bundler génère un fichier Gemfile.lock. Ce fichier est locké sur des versions précises des gems et un numéro de révision pour les dépôts Git. Tant que tu n'utilises pas "bundle update" pour mettre à jour ton fichier Gemfile.lock, tu es sûr que ton application fetchera toujours les mêmes versions des gems et des dépôts Git.
D'ailleurs c'est pour cette raison que versionner Gemfile.lock est essentiel, c'est même obligatoire pour utiliser l'option "--deployment".
Grâce à cette fonctionnalité de Bundler, je ne vois aucun inconvénient à utiliser des dépôts Git, même pour un projet ou une librairie stable (si cela est nécessaire bien sûr).
Ma feature préférée dans Bundler, c'est qu'il est vraiment aisé de poser une dépendance d'une librairie sur un répo Git. Imaginons vous développez une appli avec une librairie X, un jour cette librairie X à un bug critique pour votre appli ou une nouvelle killer feature pas encore releasée.
Vous pouvez avec Bundler, indiquer que vous voulez utiliser cette librairie depuis son repo Git si la librairie a été patchée depuis. Et si vous écrivez vous même le patch, il est facile de forker le repo...
# Denver ?
Posté par Nicolas Blanco (site web personnel) . En réponse au journal Projet Denver de Nvidia. Évalué à 0.
[^] # Re: Doctrine2
Posté par Nicolas Blanco (site web personnel) . En réponse à la dépêche En vrac : Doctrine 2, MySQL 5.5 et VimGolf. Évalué à 6.
affirme la supériorité du langage PHP
http://bit.ly/eDScUc
# PyF ?
Posté par Nicolas Blanco (site web personnel) . En réponse à la dépêche La programmation en flux, c'est facile avec PyF 2.0. Évalué à -1.
[^] # Re: ça allait fuiter...
Posté par Nicolas Blanco (site web personnel) . En réponse au journal Backdoor dans OpenBSD ?. Évalué à 10.
[^] # Re: mouais
Posté par Nicolas Blanco (site web personnel) . En réponse au journal Sondage spécial filles : les jeux libres qu'elles préfèrent.. Évalué à 1.
http://en.wikipedia.org/wiki/The_Sims
# mouais
Posté par Nicolas Blanco (site web personnel) . En réponse au journal Sondage spécial filles : les jeux libres qu'elles préfèrent.. Évalué à 0.
:-D
(je ne sors pas, krkrkrkrkrkrkrkrk)
# Passage de Richard Stallman au Québec
Posté par Nicolas Blanco (site web personnel) . En réponse à la dépêche Passage de Richard Stallman au Québec. Évalué à -1.
[^] # Re: La connaissance de RoR n'est pas obligatoire
Posté par Nicolas Blanco (site web personnel) . En réponse à la dépêche Participez au concours LinuxFr.org !. Évalué à 1.
[^] # Re: La connaissance de RoR n'est pas obligatoire
Posté par Nicolas Blanco (site web personnel) . En réponse à la dépêche Participez au concours LinuxFr.org !. Évalué à 1.
[^] # Re: La connaissance de RoR n'est pas obligatoire
Posté par Nicolas Blanco (site web personnel) . En réponse à la dépêche Participez au concours LinuxFr.org !. Évalué à 1.
# interesting
Posté par Nicolas Blanco (site web personnel) . En réponse au journal Gallerie photo en php, simple, facile mais complete. Évalué à -3.
# clair
Posté par Nicolas Blanco (site web personnel) . En réponse à la dépêche Avancement du concours pour la future version de LinuxFr.org. Évalué à -1.
Ah, merde ! On me dit dans l'oreillette que c'est toujours pas le cas aujourd'hui. Pardon aux familles, toussa...
:D
# Facile !
Posté par Nicolas Blanco (site web personnel) . En réponse au journal Acheter sur iTunes - question envoyée à Apple. Évalué à 3.
Apple
1 Infinite Loop
Cupertino, CA 95014
Etats-Unis d'Amérique
Heureux ?
[^] # Re: Et vim?
Posté par Nicolas Blanco (site web personnel) . En réponse au journal Un Vendredi sans IDE.. Évalué à 3.
# <-- Hey, toi ! clique sur le [+] à gauche !
Posté par Nicolas Blanco (site web personnel) . En réponse au journal Python 3.1 devient la version de Python par défaut sur Archlinux. Évalué à 1.
Par contre, Ruby 1.9, lui, est déjà bien supporté par la communauté et par quasiment toutes les librairies :p. Je dis ça, je dis rien.
[^] # Re: merci
Posté par Nicolas Blanco (site web personnel) . En réponse au journal pourquoi j'ai resombré dans le mac. Évalué à -8.
# Le vieux rêve du CMS qui sait tout faire...
Posté par Nicolas Blanco (site web personnel) . En réponse au journal Un CMS pour tout faire ?. Évalué à 8.
Tu n'est pas le 1er à vouloir un CMS qui soit à la fois simple, flexible, bien écrit, avec une API clean, qui puisse permettre de créer des formulaires, se connecter à du Windows tant qu'on y est, faire le café, te tondre la pelouse le dimanche, etc.
C'est juste que cela ne s'appelle pas un CMS, mais.... <roulements de tambours> un framework Web ! <applaudissements du public ravi>
# Retour vers le futur !
Posté par Nicolas Blanco (site web personnel) . En réponse au journal Sortie de Movicon 0.3. Évalué à 2.
On est bien retourné au 20ème siècle Marty !
# je dirais...
Posté par Nicolas Blanco (site web personnel) . En réponse au journal Softs qui déchiraizent \o/. Évalué à 7.
* iwork
* ilife
# L'avenir...
Posté par Nicolas Blanco (site web personnel) . En réponse à la dépêche Revue de presse de l'April pour la semaine 36 de l'année 2010. Évalué à -4.
[^] # Re: .
Posté par Nicolas Blanco (site web personnel) . En réponse à la dépêche Sortie de Bundler 1.0.0. Évalué à 1.
tu utilises beaucoup le mot "stable" dans ton commentaire.
Chaque développeur a sa définition du mot "stable", certaines librairies sont très stables en master et leurs développeurs ne releasent pas souvent de nouvelles gems, et d'autres c'est l'inverse.
Lorsque tu développes une application Ruby avec des dizaines de gems, utiliser constamment les versions stables des gems n'est pas forcément la meilleure chose, tout comme utiliser toutes les gems en branche "master".
C'est pour cette raison que la philosophie de Bundler laissant le choix au développeur de setter ses dépendances sur une release officielle considérée "stable" ou un dépôt est selon moi bonne.
La seule chose qui compte c'est que les tests unitaires/fonctionnels pour TON application passent pour une version donnée de chaque librairie utilisée (que celle ci soit considérée stable ou instable par son auteur n'a aucune valeur).
[^] # Re: .
Posté par Nicolas Blanco (site web personnel) . En réponse à la dépêche Sortie de Bundler 1.0.0. Évalué à 2.
Le dépôt Git peut bouger, voir théoriquement casser ton application, mais lorsque tu installes le bundle, Bundler génère un fichier Gemfile.lock. Ce fichier est locké sur des versions précises des gems et un numéro de révision pour les dépôts Git. Tant que tu n'utilises pas "bundle update" pour mettre à jour ton fichier Gemfile.lock, tu es sûr que ton application fetchera toujours les mêmes versions des gems et des dépôts Git.
D'ailleurs c'est pour cette raison que versionner Gemfile.lock est essentiel, c'est même obligatoire pour utiliser l'option "--deployment".
Grâce à cette fonctionnalité de Bundler, je ne vois aucun inconvénient à utiliser des dépôts Git, même pour un projet ou une librairie stable (si cela est nécessaire bien sûr).
# .
Posté par Nicolas Blanco (site web personnel) . En réponse à la dépêche Sortie de Bundler 1.0.0. Évalué à 2.
Vous pouvez avec Bundler, indiquer que vous voulez utiliser cette librairie depuis son repo Git si la librairie a été patchée depuis. Et si vous écrivez vous même le patch, il est facile de forker le repo...
# mouais
Posté par Nicolas Blanco (site web personnel) . En réponse à la dépêche Firefox 4 bêta disponible pour tests (et plus si affinités). Évalué à -10.
--> [ . ]
# Sans troller
Posté par Nicolas Blanco (site web personnel) . En réponse au journal Linux de moins en moins utilisé chez les étudiants de l'université Information Technology & Communication. Évalué à 10.