mardi 07 octobre

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : Développeur

Liens connexes

Seaside (1058 hits)
L'annonce de Seaside 2.8 (161 hits)
Quelques screenshots (1120 hits)
Le guide de migration (148 hits)
Wiki francophone (495 hits)
DLFP : annonce de la version 2.7 précédente (135 hits)

Dépêche modérée par

Ragnagna

Dépêche éditée par

Développeur : Seaside 2.8 est sorti

Posté par Damien Cassou (). Modéré le 29 octobre 2007.

La version 2.8 de Seaside vient de sortir après plus de sept mois de développement dont deux de release candidate. Seaside est un framework web libre (licence MIT) écrit en Smalltalk qui abstrait HTTP, HTML et JavaScript. Avec Seaside, il n'est plus question de pages web mais uniquement de composants réutilisables qui s'appellent les uns les autres et se composent. Un autre des avantages de Seaside consiste en sa faculté de modélisation des flots d'exécution.

La version 2.8 apporte un grand nombre d'améliorations et de corrections parmi lesquelles :

une bien plus grande vitesse de rendu des pages (deux fois plus rapide que la version précédente) ;
une consommation mémoire très fortement réduite (jusqu'à quatre fois moins de mémoire utilisée) ;
une compatibilité accrue avec les différentes implémentations de Smalltalk (Squeak, Visual Works et GemStone) ;
beaucoup plus de documentation, de tests unitaires et un site web refait à neuf.

Un guide de migration a aussi été réalisé pour aider les développeurs à passer d'une version à une autre.

Seaside (1058 hits)
L'annonce de Seaside 2.8 (161 hits)
Quelques screenshots (1120 hits)
Le guide de migration (148 hits)
Wiki francophone (495 hits)
DLFP : annonce de la version 2.7 précédente (135 hits)

> Lire la suite (38 commentaires, moyenne: 2,9). [dépêche : 2398 caractères]

Seaside inclut :

Une génération du code HTML à partir de code Smalltalk. Le codage HTML à la main est souvent rébarbatif : toujours les mêmes répétitions de listes, de liens, de formes et de tableaux qui apparaissent page après page. Seaside a une API complète pour générer du code HTML qui vous permet d'abstraire ces répétitions en méthodes correspondantes plutôt que de copier-coller toujours les mêmes séquences de balises. Ceci permet aussi de garantir que le code HTML qui va être généré est bien compatible XHTML 1.0 strict.
Une gestion des requêtes de type callback. Ceci permet de mettre la définition d'un lien ou d'un champ de formulaire juste à côté du code qui va être exécuté pour gérer ce lien ou ce champ. Plus besoin alors de penser en terme d'identifiant et de décodage d'URLs.
Une architecture de composants. Un composant est décrit par une classe. Chaque composant est capable de rendre du code HTML (grâce à une API Smalltalk), d'afficher d'autres composants ou d'appeler un second composant qui va alors remplacer le premier. Ceci vous permet de penser à votre application comme un ensemble de composants avec chacun un rôle bien défini. Comme chaque composant est indépendant, il est possible de les réutiliser dans plusieurs applications ; Seaside en fournit même quelques uns.
Une gestion des sessions. Seaside permet la modélisation du flux entier de l'application dans une même méthode. Ceci permet d'écrire une application web comme si vous écriviez une application non web.
Seaside possède aussi un bon support de CSS et de Javascript, des outils de développement accessibles depuis le navigateur, un vrai support du débogage, un système de configuration et de préférences et bien plus.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Smalltalk

Posté par yellowiscool (Jabber id, page perso, ) le 29/10/2007 à 18:29. (lien). Évalué à 3.

Dommage que smalltalk soit peux connu et utilisé dans le grand public. Pour ma part, je reste sur ruby on rails.

[^]Re: Smalltalk

Posté par Damien Cassou () le 29/10/2007 à 18:54. (lien). Évalué à 7.
C'est parce que les gens "restent sur ruby on rails" ou Java que Smalltalk n'a pas une grosse communauté. Je pense que l'apprentissage de Smalltalk et de Seaside peut apporter beaucoup même si l'on n'en fait pas au quotidien.

--
Damien Cassou
- [^]Re: Smalltalk
  
  Posté par reno () le 30/10/2007 à 09:00. (lien). Évalué à 1.
  L'apprentissage de Seaside je ne sais pas, mais de toute manière Ruby est inspiré de Smalltalk (entre autre) alors je ne suis pas sur que Smalltalk apporte beaucoup dans ce cas..
  - [^]Re: Smalltalk
    
    Posté par Thomas () le 30/10/2007 à 10:20. (lien). Évalué à 4.
    Ruby est inspiré de Smalltalk (entre autre) alors je ne suis pas sur que Smalltalk apporte beaucoup dans ce cas..
    
    Je trouve la syntaxe plus simple et plus flexible. Tu peux rajouter facilement des structures de contrôle comme tu le ferais en CL avec ses bonnes vieilles macros.
    
    Les implémentations sont généralement plus matures, notamment au niveau du garbage collector (généralement quand quelqu'un râle contre les GC c'est qu'il n'en a pas utilisé de bon.) Les implémentations compilent en bytecode, tu peux sauvegarder ta VM en l'état (càd avec toutes ses libs chargées, pour un démarrage plus rapide)... Bref, pas mal d'avantages.
    
    Essaie une fois et tu verras. Quand j'en faisais un peu (avant de retourner à CL) j'avais testé Squeak (c'est louche au début à cause de l'interface) et Cincom Smalltalk (pas libre mais gratuit et c'est un bon truc). Tu remarqueras vite aussi la différence entre le mode de développement en Ruby et celui en Smalltalk.
    
    En Smalltalk, tout comme en CL ou Erlang, tu développes ton code vraiment de manière incrémentale. En Smalltalk, tu développes en "bottom-up "et pas "top-down". Càd que tu commences par coder de petites fonctions de bas niveau, tu t'amuses un peu avec pour vérifier que tout marche, puis tu les combines dans des fonctions plus grandes, jusqu'à arriver à ce que tu veux (je dis fonctions mais en Smalltalk on parleras plus d'objets et de méthodes... mon habitude du CL qui ressort ;-) )
    
    PS: j'ai pas l'url pour Cincom Smalltalk, mais ça se trouve facilement.
    - [^]Re: Smalltalk
      
      Posté par Damien Cassou () le 30/10/2007 à 11:13. (lien). Évalué à 3.
      http://www.cincomsmalltalk.com
      
      --
      Damien Cassou
  - [^]Re: Smalltalk
    
    Posté par Larry Cow () le 30/10/2007 à 12:20. (lien). Évalué à 3.
    De toutes manières, Linux est inspiré d'Unix, alors je ne suis pas sur que Linux apporte beaucoup dans ce cas.
    - [^]Re: Smalltalk
      
      Posté par kaouete (page perso, ) le 30/10/2007 à 12:56. (lien). Évalué à 2.
      Tu voulais dire :
      
      De toutes manières, Linux est inspiré d'Unix, alors je ne suis pas sur que Unix apporte beaucoup dans ce cas.
      
      Ce qui est plutôt vrai ... :)
    - [^]Re: Smalltalk
      
      Posté par reno () le 30/10/2007 à 14:45. (lien). Évalué à 0.
      >De toutes manières, Linux est inspiré d'Unix, alors je ne suis pas sur que Linux apporte beaucoup dans ce cas.
      
      Bin si, il est moins cher.

[^]Re: Smalltalk

Posté par Florent Peyraud (Jabber id, page perso, ) le 30/10/2007 à 13:56. (lien). Évalué à 2.
Et justement pour faire mieux connaitre Smalltalk, Damien Cassou vient faire une conférence sur le sujet lors de JM2L 2007 (http://jm2l.linux-azur.org ). Pour les sudiste, c'est l'occasion de découvrir Smalltalk, et bien d'autres sujets...

[+] Question provoc

Posté par cdvddt () le 29/10/2007 à 19:08. (lien). Évalué à -2.

Est ce que le "marché" des frameworks Web n'est pas déjà ultra saturé ?
Franchement, à quoi ca sert toutes ces micros communautés qui réinventent la roue et proposent des frameworks pour leur petit langage préféré. C'est du fétichisme.

Entre les frameworks Java, PHP et ses milliers de frameworks et les Ruby On Rail et Cie, ça devient vraiment ridicule.
On dirait que chaque geek qui se lance dans la conception d'une appli Web développe son framework perso.

C'est comme pour les window manager sous linux. La foire aux geeks désoeuvrés. Et c'est contre productif. C'est autant d'énergie perdue à diviser les efforts plutôt que d'essayer d'améliorer l'existant.

C'est triste.

[^]Re: Question provoc

Posté par tulipemoutarde (page perso, ) le 29/10/2007 à 19:17. (lien). Évalué à 10.
C'est justement là que c'est différent.
Seaside n'offre pas du tout la même vision du web qu'un autre framework. Il abstrait vraiment HTTP, Javascript et consort. Même la notion d'URL est limite inutile.

De l'autre coté c'est de la diversité que vient l'innovation. Si on utilisait tous les même outils, le même environnement et OS, le monde serait bien triste...
- [^]Re: Question provoc
  
  Posté par Florian G (Jabber id, ) le 29/10/2007 à 20:04. (lien). Évalué à 4.
  
  le monde serait bien triste...
  Et monopolistique…
  
  --
  Comment marchent le « moinssage » et le « plussage » ?
- [^]Re: Question provoc
  
  Posté par Éric (Jabber id, page perso, ) le 30/10/2007 à 16:47. (lien). Évalué à 2.
  > Seaside n'offre pas du tout la même vision du web qu'un autre
  > framework. Il abstrait vraiment HTTP, Javascript et consort. Même la
  > notion d'URL est limite inutile.
  
  Ce n'est pas le premier et je trouve toujours ça très nul.
  
  On manipule du Web. Les liens et les URL sont la composante de base. La masquer c'est coder autre chose que du Web et la première chose à imaginer pour faire des erreurs basiques sur un site Web (genre des URL dégueu, des perf pourries, des pages non bookmarkables, etc.)
  
  Un framework c'est un cadre de travail, ça ne doit pas être là pour oublier ce qu'on manipule.
  
  A la limite je comprend quand le but c'est *réellement* de faire un code qui fonctionne directement sur plusieurs transports et pas que sur le Web, mais j'ai rarement vu quelque chose de vraiment fonctionnel de ce côté là (sans avoir à refaire toute la vue et plein de code en double)
  - [^]Re: Question provoc
    
    Posté par CrEv (page perso, ) le 30/10/2007 à 17:05. (lien). Évalué à 2.
    Si je ne me trompe pas (corrigez moi sinon) les pages générés par seaside sont bookmarkables par exemple.
    
    Pour ce qui est des url dégueu ou non, ben je dirais plutôt que ça dépend ce que l'on code. Si pour un site de "contenu" (blog pour prendre un exemple bateau) c'est intéressant d'avoir une belle url, dès qu'on s'oriente vers des applications web, la beauté de l'url on s'en fout un peu (entendre par là que jamais on mettera un bookmark, jamais on tappera une url). De plus, même si les urls sont parfois "belles" (y compris pour des sites des contenu) il est bien rare de s'en servir.
    
    Le truc à mon avis c'est que seaside est là pour faire un peu plus qu'un site Web. Et le fait d'avoir des urls 'illisibles' ou non je vois pas trop ce que ça change sur les perfs. Pour moi ce serait plutôt le contraire, pour avoir des belles urls on va plutôt faire des choses verbeuse, en utilisant des strings, là où un identifiant numérique serait plus efficace.
    
    J'avais lu un article il y a quelques temps sur seaside (dans un glmf) et le côté composant est assez attirant. (Ils expliquaient par ailleurs l'histoire des urls, mais je l'ai pas sous la main...)
    - [^]Re: Question provoc
      
      Posté par Serge Stinckwich (page perso, ) le 30/10/2007 à 17:13. (lien). Évalué à 2.
      Elles sont bookmarkables si tu le spécifie dans ton code, pas par défaut.
      Je crois que Seaside est adapté pour faire des applications web où il n'y a pas besoin d'avoir d'URLs à conserver. Pour un site web, Seaside est peut-être moins intéressant.
      
      Mais bon la question de savoir si les URLs sont importantes ou pas dans un framework web, cela peut veut devenir un troll ;-)
      
      L'intérêt de Seaside, c'est que tu code une application web comme tu coderais une application classique, tu te soucie pas des tracas liés au protocole HTTP.
  - [^]Re: Question provoc
    
    Posté par Damien Cassou () le 31/10/2007 à 07:28. (lien). Évalué à 2.
    En fait, si tu regardes les urls de la news, elles pointent presque toutes vers seaside.st qui est un site web écrit en Seaside (en fait, c'est fait avec le CMS Pier qui est implémenté au dessus de Seaside). Donc, les urls sont bien bookmarkables.
    
    --
    Damien Cassou

[^]Re: Question provoc

Posté par Jean-Philippe (page perso, ) le 29/10/2007 à 22:18. (lien). Évalué à 6.
C'est justement cette diversité qui donne envie aux gens d'expérimenter de nouvelles idées et d'innover; ce qui donne des références reprises par d'autres projets avant de repartir dans l'innovation et ainsi de suite... enfin, c'est le libre quoi.

[^]Re: Question provoc

Posté par Damien Cassou () le 30/10/2007 à 07:45. (lien). Évalué à 2.
Il faut voir aussi que Seaside (sauf erreur) existait avant Ruby on Rails (2002 environ pour Seaside, 2004 pour Rails) et avant beaucoup d'autres frameworks web.

Comme d'autres l'ont dit, l'approche est complètement différente et apprendre à utiliser Seaside permet de mieux se rendre compte des limitations des autres frameworks.

--
Damien Cassou
- [^]Re: Question provoc
  
  Posté par Serge Stinckwich (page perso, ) le 30/10/2007 à 17:16. (lien). Évalué à 1.
  Je crois que la première version de Seaside a été codé en Ruby par Avi Bryant son concepteur. Puis il l'a réécrit en Smalltalk, car il n'était pas satisfait ...

Doc en Français

Posté par Poulain Benjamin (page perso, ) le 29/10/2007 à 20:19. (lien). Évalué à 6.

Je citerais aussi la doc du Magellan: http://www.magellan.fpms.ac.be/articles/seaside/
La documentation est un peu vieille mais globalement toujours d'actualité. Ça peut servir à un débutant par exemple.

--
Visitez Linux Certif, le site qu'il est bien pour les Linuxiens. (Passez voir aussi OpenYourCode pour les développeurs)

[^]Re: Doc en Français

Posté par totof2000 () le 29/10/2007 à 20:56. (lien). Évalué à 6.
Bah moi j'ai tenté de m'y mettre a Seaside et a Smalltalk.

Reultat : trop peu de documentation sur le sujet. Aller voir le code source et l'implémntation des composants, contrairement à ce que prétndent certains, ne suffit absolument pas .... Faut pas s'étonner de ce fait si peu de monde s'y met.

Je n'abandonne pas complètement l'affaire, seulement, je n'ai pas en ce moment de soirées à passer pour décoder l'implémentation du bazar, je verrai ça plus tard.
- [^]Re: Doc en Français
  
  Posté par Serge Stinckwich (page perso, ) le 29/10/2007 à 21:54. (lien). Évalué à 5.
  Oui, c'est clair la documentation est encore un problème en Seaside. D'un autre côté, on progresse 144 classes dans la version 2.8 sont commentées au lieu de 99 pour la version précédente.
  Il commence a y avoir plusieurs tutoriels en anglais et en français (voir ici pour quelques liens : http://doesnotunderstand.free.fr/?cat=23 ) Nous avons également des pages dans le wiki Squeak-fr : http://community.ofset.org/index.php/Seaside
  Bon, c'est vrai ces pages sont un peu obsolètes, il faudrait les remettre à jour à partir à la dernière version de Seaside.
  - [^]Re: Doc en Français
    
    Posté par Damien Cassou () le 30/10/2007 à 07:50. (lien). Évalué à 1.
    En fait, je suis presque sûr qu'il y avait bien moins de classes commentées que 99 dans la version précédente. Le 99 auquel tu fais références est la base qui a servi à Roger Whitney pour écrire les 45 autres commentaires. Mais Lukas et Philippe en avait déjà commenté un bon paquet avant.
    
    --
    Damien Cassou
  - [^]Re: Doc en Français
    
    Posté par totof2000 () le 30/10/2007 à 13:03. (lien). Évalué à 4.
    Je trouve quand même un peu louche cette démarche de documenter les classes a l'interieur du code. C'est comme si tu devais démonter ton téléphone portable pour lire le mode d'emploi caché dedans, ou, pour un électronicien ou informaticien, démonter le microcontroleur qu'il utilise et examiner la façon dont il est gravé à la loupe pour savoir comment l'utiliser.
    - [^]Re: Doc en Français
      
      Posté par Damien Cassou () le 30/10/2007 à 13:16. (lien). Évalué à 3.
      En fait, si tu codais en Smalltalk comme en Java ou en PHP, ta remarque serait tout à fait valable. Sauf qu'en Smalltalk (avec les IDE comme Squeak ou Cincom Smalltalk), tu as accès au code des bibliothèques que tu utilises aussi facilement qu'à ton propre code. Ce qui fait que quand tu souhaites utiliser une classe, tu commences par ouvrir un navigateur de code sur cette classe et tu peux voir immédiatement son commentaire et ses méthodes. C'est un des gros avantages par rapport à une approche de type documentation séparée : on a la doc et le code juste sous la main pour bien voir ce qui se passe.
      
      --
      Damien Cassou
      - [^]Re: Doc en Français
        
        Posté par totof2000 () le 30/10/2007 à 17:57. (lien). Évalué à 4.
        En fait, si tu codais en Smalltalk comme en Java ou en PHP, ta remarque serait tout à fait valable. Sauf qu'en Smalltalk (avec les IDE comme Squeak ou Cincom Smalltalk), tu as accès au code des bibliothèques que tu utilises aussi facilement qu'à ton propre code.
        
        Je veux bien, c'est pratique quand tu sais quelle classe utiliser. Pour en revenir à ma comparaison avec l'elecronique, si tu as besoin d'un élément qui réalise une amplification de courant, tu sais que tu dois utiliser un transistor, et tu sais à partir de ton besoin, quel transistor tu vas choisir ( éventuellement tu fais un petit montage avec appareils de mesure pour vérifier ton choix, ou tu utilises un simulateur).
        
        Ce qui fait que quand tu souhaites utiliser une classe, tu commences par ouvrir un navigateur de code sur cette classe et tu peux voir immédiatement son commentaire et ses méthodes.
        
        Le problème se pose dans le cas inverse: tu veux effectuer une opération mais tu ne sais pas quelle classe utiliser: il est un peu fastidieux d'ouvrir les classes une à une pour s'y retrouver. Pour Seaside c'est encore pire, a l'époque ou j'ai tenté de l'utiliser (6 mois environs), même le code n'était pas documenté.
        C'est un des gros avantages par rapport à une approche de type documentation séparée : on a la doc et le code juste sous la main pour bien voir ce qui se passe.
        
        C'est pratique mais incomplet à mon avis, surtout pour débuter.
    - [^]Re: Doc en Français
      
      Posté par Ummon () le 30/10/2007 à 13:17. (lien). Évalué à 2.
      Petite remarque juste en passant (je ne connais pas seaside et son système de documentation).
      
      Personnellement je trouve bien d'avoir toute la documentation liée avec le code, ça la rend plus accessible pour le programmeur.
      Évidemment cela va de paire avec un outil comme Doxygen pour l'extraire et la présenter à l'utilisateur.
      - [^]Re: Doc en Français
        
        Posté par CrEv (page perso, ) le 30/10/2007 à 14:00. (lien). Évalué à 4.
        Un autre avantage est que dans ce cas la documentation est en générale plus mise à jour, en cohérence avec le code.
        Alors que lorsque la doc est réellement à côté, il arrive fréquement que celle-ci soit en décalage.
        
        [^]Re: Doc en Français
        
        Posté par Serge Stinckwich (page perso, ) le 30/10/2007 à 17:08. (lien). Évalué à 2.
        Tout fait, une documentation externe (même si elle parfois nécessaire) est très vite en décalage par rapport au code. Aujourd'hui, la documentation devient du code exécutable, c'est la notion de tests unitaires. Un test constitue un élément de documentation essentiel d'un programme. Le développeur voit rapidement lorsque son test passe au rouge que le test ne reflète plus le code correspondant.
        
        Si vous ne connaissez pas ce principe de développement par les tests, je vous invite à venir à la séance de Dojo XP (eXtreme Programming) que nous organisons à la prochaine SmalltalkParty le 1ier décembre à Paris :
        http://linuxfr.org/2007/10/25/23254.html
        
        [^]Re: Doc en Français
        
        Posté par totof2000 () le 30/10/2007 à 17:49. (lien). Évalué à 2.
        
        une documentation externe (même si elle parfois nécessaire) est très vite en décalage par rapport au code. Aujourd'hui, la documentation devient du code exécutable
        
        Ce serait bien alors un outil qui irait extraire la documentation du code source des classes .... parce que lorsque tu as besoin d'effectuer une action précise, c'est pas génial d'explorer les classes une à une pour savoir laquelle répond le mieux à tes besoins.

Autre documentation

Posté par weeber (page perso, ) le 29/10/2007 à 20:56. (lien). Évalué à 3.

Bonjour,
Je ne connais pas du tout seaside, quel est/sont le/les avantage/inconénients par rapport à du php + mysql, plus rapide à dévelloper?

J'espère que ma question n'est pas trop bête...

Sinon j'ai trouvé une autre doc francaise:
http://www.magellan.fpms.ac.be/articles/seaside/?searchterm=(...)

Bonne soirée

[^]Re: Autre documentation

Posté par Damien Cassou () le 30/10/2007 à 07:57. (lien). Évalué à 1.
La question n'est pas bête du tout, mais la réponse se trouve en partie dans la nouvelle :-). Ce que j'apprécie tout particulièrement dans Seaside :

- l'approche composant qui permet de vraiment découper son application web en petites parties réutilisables.
- la génération de code XHTML à partir de code Smalltalk.
- les outils de développement directement accessible dans le navigateur.
- sa simplicité une fois qu'on a lâché les ponts avec ce que l'on connaît déjà.
- le langage Smalltalk

--
Damien Cassou

"scalabilite"

Posté par Erwan (page perso, ) le 30/10/2007 à 07:19. (lien). Évalué à 3.

Et est-ce que ca tient bien la montee en charge ?

C'est-a-dire - est-ce facile d'avoir plusieurs serveurs web, plusieurs serveurs de bases de données ou est-ce que tout ca est tout melangé ?

[^]Re: "scalabilite"

Posté par Serge Stinckwich (page perso, ) le 30/10/2007 à 07:46. (lien). Évalué à 2.
En ce qui concerne la montée en charge, je crois qu'il n'y a pas encore bcp d'expériences, néanmoins il commence à y avoir de grosses applications en Seaside, notamment DabbleDB : http://dabbledb.com/

[^]Re: "scalabilite"

Posté par Damien Cassou () le 30/10/2007 à 07:53. (lien). Évalué à 2.
En fait, ton Seaside va tourner derrière un serveur web qui va faire le load balancing entre plusieurs serveurs et plusieurs machines. Par contre, il est vrai que Seaside reste gourmand en mémoire même si la situation a été grandement améliorée avec cette nouvelle version.

--
Damien Cassou
- [^]Re: "scalabilite"
  
  Posté par totof2000 () le 30/10/2007 à 13:05. (lien). Évalué à 2.
  T'as une doc ou un lien sur le sujet ? Ca m'interesse au plus haut point !!!

Rapidité

Posté par Pierre Tramonson () le 31/10/2007 à 10:06. (lien). Évalué à 1.

une bien plus grande vitesse de rendu des pages (deux fois plus rapide que la version précédente) ;

Est-ce qu'il sert les pages plus rapidement qu'Apache ?
Parce que bon, c'est quand même une des marques de distinction des framework web de qualité; toute ressemblance avec <![troll[ un ~langage() basé sur PHP étant bien évidemment involontaire. ]troll]>

[^]Re: Rapidité

Posté par CrEv (page perso, ) le 31/10/2007 à 10:24. (lien). Évalué à 2.
lapincompris...

Apache sert les pages qui on été rendu par le framework.
si on prend un framework en ruby, un en python et un en php, ils peuvent très bien être tous les trois servis par apache... (pour seaside j'en sais rien, j'ai pas regardé...)

Entre deux applis web (framework + serveur) les deux éléments peuvent jouer pour le temps jusqu'au client mais sont différents.

Revenir en haut de page

Articles précédents : Développeur

Liens connexes

Dépêche modérée par

Dépêche éditée par

Développeur : Seaside 2.8 est sorti

Smalltalk

[^]Re: Smalltalk

[^]Re: Smalltalk

[^]Re: Smalltalk

[^]Re: Smalltalk

[^]Re: Smalltalk

[^]Re: Smalltalk

[^]Re: Smalltalk

[^]Re: Smalltalk

[+] Question provoc

[^]Re: Question provoc

[^]Re: Question provoc

[^]Re: Question provoc

[^]Re: Question provoc

[^]Re: Question provoc

[^]Re: Question provoc

[^]Re: Question provoc

[^]Re: Question provoc

[^]Re: Question provoc

Doc en Français

[^]Re: Doc en Français

[^]Re: Doc en Français

[^]Re: Doc en Français

[^]Re: Doc en Français

[^]Re: Doc en Français

[^]Re: Doc en Français

[^]Re: Doc en Français

[^]Re: Doc en Français

[^]Re: Doc en Français

[^]Re: Doc en Français

Autre documentation

[^]Re: Autre documentation

"scalabilite"

[^]Re: "scalabilite"

[^]Re: "scalabilite"

[^]Re: "scalabilite"

Rapidité

[^]Re: Rapidité