ATOUTFOX
COMMUNAUTÉ FRANCOPHONE DES PROFESSIONNELS FOXPRO
Visual FoxPro : le développement durable

SEDNA : traduction de l'interview de Alan Griver et Ken Levy au DevCon 2005   



L'auteur

Groupe Localisation
France France
Membre Simple
# 0000000333
enregistré le 28/05/2005

http://www.atoutfox.org
Groupe Localisation VFP
Fiche personnelle


Note des membres
pas de note

Contributions > 60 - AtoutFox > 50 - VFP9 Francophone > 5.1 - Traductions

SEDNA : traduction de l'interview de Alan Griver et Ken Levy au DevCon 2005
# 0000000235
ajouté le 31/08/2005 12:03:23 et modifié le 31/08/2005
consulté 17166 fois
Niveau débutant

Description
Visual FoxPro DevCon 2005 Interview d’Alan Griver et Ken Levy
 par David Stevenson
 David Stevenson, le rédacteur en chef de FoxTalk, a interviewé Ken Levy (VS Data Product Manager chez Microsoft) et Alan Griver (VS Data Group Manager chez Microsoft) sur l’orientation avenir de FoxPro et le prochain projet d’évolution de VFP Sedna. Cette interview s’est déroulée le 14 juin 2005, lors du DevCon VFP Advisor à Las Vegas.
 
Interview : 14 juin 2005
Publication : 2 août 2005

David Stevenson :
VFP9 est maintenant fonctionnel, et semble jusqu’à maintenant être bien accueilli par les développeurs VFP qui l’ont essayé. Quelles informations la communauté vous renvoie-t-elle jusqu’à présent ?
 Alan Griver : Nous entendons en gros la même chose. Environ un tiers de la communauté est passé à VFP9, ce qui est parfaitement conforme à nos attentes. Les gens disent que c’est la version la plus stable de VFP. Les gens sont secoués – vous savez, si vous parlez à 4 ou 5 personnes, vous obtenez 4 ou 5 réponses différentes sur la fonctionnalité qu’ils préfèrent, ça peut être l’amélioration des reports, les nouveaux types de données, les améliorations du SQL, etc. je pense que nous avons marqué un point avec cette version. Je ne pensais pas qu’on pourrait faire mieux que la 8, mais c’est ce qu’on fait aujourd’hui.
 Ken Levy : De plus, les gens ne sont pas vraiment entré dans toutes les extensions. En même temps, vous avez des choses comme GDI+, et nous avons inclus d’autres fonctionnalités qui ne sont pas nécessairement mises en avant. Je pense qu’il y aura beaucoup de découvertes dans les 6 ou 12 prochains mois, à partir des exemples, des articles, et ainsi de suite, qui révéleront encore plus de fonctionnalités dans VFP9 ; plus que ce que les gens auront lu, des choses dont ils ne savent pas qu’elles existent. Le BindEvent (amélioré) a une puissance inimaginable. Il y a plein de choses qu’on peut faire avec la 9, et qu’on n’avait jamais fait avant.
 David Stevenson : Parmi les commentaires faits l’autre soir à la réunion, on a parlé de la surprise causé par le temps que vous avez mis entre le début et la finalisation de VFP9. Je sais que la communauté a été surprise, mais vous avez dit qu’on avait été surpris aussi chez Microsoft. Comment pensez-vous que ça puisse compter, pour vos projets sur Sedna ? Vous avez avancé quelques paramètres sur ce que Sedna devrait inclure, mais 2 ans semblent être lointains, et les gens pourraient proposer des beaucoup de choses nouvelles.
 Alan Griver : Bon, si vous regardez bien, VFP9 a aussi nécessité 2 ans environ, ce qui correspond au schéma classique. Ce qui se passe, c’est que vous avancez, en posant les piliers des fondations d’une mise à jour, puis vous faites un compte-rendu général, où vous dites « voilà le genre de choses que nous recherchons ». Ça essaie d’être des concepts architecturaux, et la façon dont vous les assemblez, parce que vous les développez, fait apparaître d’un coup des nouvelles choses qui sont en plan.
 J’avais l’habitude de voir ça tout le temps, quand je développais avec Fox et VB6. C’est la même chose. On a avancé, et on a dit « bon, on sait qu’on veut améliorer les reports », par exemple. Là, on a une idée architecturale de la façon dont on veut y arriver, et tout d’un coup, les bandes de détail multiples en sont sorties, le reporting en multi-passage également, tout ça est arrivé parce que nous avions correctement conçu l’architecture.
 Nous pensons que c’est ce qui va arriver aussi avec Sedna. Nous mettons en place les approches structurelles, et nous disons que nous concevons le produit pour l’extensibilité. Je crois que Doug Hennig dit que nous allons au-delà de l’extensibilité. Mais nous allons l’utiliser, pour continuer d’ajouter des choses dont on peut seulement rêver aujourd'hui.
 Ken Levy : je pense qu’avec toutes les nouvelles technologies qui arrivent, et avec l’extensibilité qui nous donne la possibilité de coller toutes ces choses ensemble, j’ai bon espoir que nous allons faire sortir quelque chose qui sera assez passionnant. Rien qu’ici, lors de la présentation, j’étais excité dans certaines démos, et je pouvais le sentir dans la réaction du public. Par exemple, le potentiel – où en serons-nous dans 2 ou 5 ans ? Là, on est juste en train de gratter à la surface, et il y a un potentiel très grand – comme l’extensibilité de FoxPro et la programmation orientée données.
 David Stevenson : On ne sait pas vraiment comment interpréter le nouveau genre de mise à jour que semble être Sedna. Vous l’avez décrit comme un SP2 avec des additifs, en disant que c’était plus qu’un service pack. Mais alors, si c’est le cas, pourquoi ne pas l’avoir appelé 9.1 ou 9.5, ou même VFP10 ?
 Alan Griver : Tout d’abord, on ne lui a pas donné de nom définitif. Actuellement c’est Sedna, mais nous n’avons pas dit si ça deviendrait 9.1 ou 9.5 ou autre chose.
 David Stevenson : D’accord, mais vous l’avez décrit comme un service pack plus des additifs.
 Alan Griver : Pensez par exemple à la façon dont le SP2 de Windows XP l’a enrichi de nombreuses fonctionnalités ; c’est semblable à ce que Sedna fera pour Fox. Nous avons estimé que nous ne devions pas toucher au noyau – que des DLL additionnelles pour l’extensibilité de Fox pouvaient nous offrir un large éventail de possibilités, comme n’importe quelle application que vous écrivez qui comporte un EXE comme noyau et un groupe de différentes DLL. Ça nous maintient sur base vraiment stable, ce qui aide aussi les gens à migrer. Ce qui marche avec VFP9 continuera de fonctionner, parce que c’est le même code. Comme ça, on et les améliorations, et la stabilité.
 Ken Levy : une des choses que nous avons faites quand nous avons commence la version 9 a été de prendre du recul, et de nous dire que plutôt que de suivre un chemin traditionnel, nous recherchions le long terme. Je ne parle pas d’une année à compter d’aujourd'hui, mais bien de trois à dix ans. C’est ça notre voie. Dans la direction où les développeurs Fox doivent aller, vers le genre de choses qu’ils demandent, vers ce que leurs utilisateurs demandent. Notre équipe a des moyens limités, comme pour la 9.0, et nous devons être très prudents quand nous choisissons nos priorités. On ne peut pas tout faire ! si nous consacrions beaucoup de temps, par exemple, sur le contrôle grid, ça engendrerait un temps énorme en planification, en développement, en tests. Ce n’est pas si simple, d’ouvrir quelque chose et d’y faire des modifications.
 Si on prend toute cette énergie pour la mettre dans quelque chose qui, par exemple, se raccroche à Longhorn (Windows Vista), ça peut être beaucoup plus bénéfique pour les utilisateurs, et leurs applications. C’est un peu comme ce que dit Spock dans Star Trek, « les besoins de la majorité comptent plus que ceux de la minorité, ou d’un individu ». C’est un peu comme ça qu’on a réfléchi, quand on a pensé à ces fonctionnalités. Il nous fallait prendre du recul, essayer de faire nos choix, et lever le nez du guidon. Quelles sont les options pour le faire, comment le conditionner, comment le distribuer. Nous gardons tous nos choix ouverts, et nous pensons qu’avec des versions beta régulières, ça permettra à chacun de voir ce que nous faisons et de savoir à l’avance avec précision ce que nous pensons. Comme ça, ce n’est pas la grande surprise dans six mois – comme on l’a annoncée. C’est comme ce grand courrier qui décrit toutes les nouvelles fonctionnalités, et en gros, tout le monde sait ce qui va arriver et attend six mois jusqu’à ce que le produit soit distribué – quelque chose de ce genre. Ici, avec Sedna, on voit l’évolution sur une base mensuelle, et la communauté Fox devient comme une extension de l’équipe de développement Fox elle-même.
 Alan Griver : c’est quelque chose qui a très bien marché pour Visual Studio, avec le centre de feedback et aussi les CTP (Community Technology Previews). On a fourni pour Visual Studio une mise à jour qui n’avait peut-être pas la qualité d’une beta, mais tout le monde peut voir ce que nous faisons mois après mois. SQL Server fonctionne aussi comme ça, et nous envisageons de faire pareil pour Fox. Je pense que ça va se généraliser dans plusieurs groupes.
 Ken Levy : Ce n’est pas un coup de marketing, mais réellement un appui technique aux développeurs. Pensez à Virtual PC, un programme pas cher. C’est un bon moyen de tester des betas, de faire des essais, comme ça vous vous tenez à jour, vous y consacrez peu de temps et vous nous renvoyez des informations. Je cois que ça sera une grosse part de nos efforts de construction de Sedna.
 Alan Griver : Je voudrais préciser un point, pour tous ceux qui s’inquiètent sur la façon dont ils vont gérer ces mises à jour mensuelles – c’est quelque chose que la communauté Visual Studio a vécu – et la réponse est qu’il ne sera pas nécessaire de le faire mensuellement. Quand vous aurez un peu de temps, vous téléchargez la dernière version, vous l’utilisez, vous faîtes tourner votre appli dessus, et vous nous communiquez les bugs.
 David Stevenson : Vous prévoyez des mises à jour aussi fréquentes – mensuelles ?
 Alan Griver : C’est un des points que nous regardons. Vu la taille de l’équipe, ça ne sera peut-être pas aussi fréquent, mais on verra. Nous aimerions être beaucoup plus transparents et beaucoup plus ouverts sur ce que nous faisons, parce que nous faisons partie de la communauté et que la communauté fait partie de l’équipe, nous montrons le chemin, et nous y veillons attentivement dans ce cas, sur la façon dont nous allons intégrer la communauté au produit. Nous avons toujours eu des listes d’améliorations – nous avons fait comme ça – et là nous voudrions voir si nous pouvons faire plus qu’une beta publique, et c’est ce que nous allons faire.
 Ken Levy : les deux questions les plus courantes sont : « Qu’est-ce qu’on fait avec FoxPro ?», et « Qu’est-ce qu’on ne fait pas avec FoxPro ? ». Les gens veulent vraiment pouvoir prendre des décisions, et faire des projets basés sur une bonne information. Nous devons améliorer ça considérablement, sur une base plus rapide.
 David Stevenson : Bien, sur ce point, j’ai remarqué en direct pendant la discussion que les gens essayent de comprendre le sens réel de la Feuille de route de VFP. On a une série de mots, une entrée de FAQ qui renvoie en arrière – chacun pointe sur un autre. Les gens réagissent souvent au fait que la Feuille de route contient l’expression « tous nos projets » pour le développement de Visual FoxPro.
 Ken Levy : Tous nos projets actuels.
 Alan Griver : Tous nos projets actuels.
 David Stevenson : C’est vraiment « Tous nos projets actuels » ?
 Ken Levy : Sur la page de la FAQ, on dit que tous nos projets actuels concernant l’évolution de Visual FoxPro sont dans la Feuille de route. Cela peut changer à tout moment.
 David Stevenson : La question récurrente est « quelles sont les probabilités qu’il y ait encore des améliorations après Sedna ? »
 Alan Griver : C’est quelque chose que nous regarderons à la fin de Sedna, exactement comme nous avons commencé à envisager Sedna vers la fin de VFP 9, et la 9 vers la fin de VFP 8, et la 7 vers la fin de la 6. Dans l’équipe, nous avons en gros une version d’avance. En ce moment, Sedna est probablement un de nos plus gros paris, un des plus gros efforts que nous ayons eu à faire. Quand on y pense, la dernière fois que nous avons eu un décalage structurel dans l’environnement sous-jacent, c’était quand nous sommes passés de DOS à Windows, ou peut-être du 16 au 32 bits.
 Ce qui arrive maintenant, c’est pour l’essentiel une nouvelle plateforme Windows, et il nous faut tourner proprement sur cette plateforme. Nous savons que c’est ça qui va être important dans les 2 prochaines années, et Sedna est la mise à jour que nous devons commencer pour prendre ça en compte. Tous nos efforts sont centrés là-dessus. Juste en guise d’exemple simple, mais simple, Longhorn (Windows Vista), ça fait combien de nouvelles API, Ken ?
 Ken Levy : plus de 3500, à ce jour.
 Alan Griver : Ce qui veut dire que nous devons toutes les regarder, et comprendre sur lesquelles nous voulons nous interfacer pour les utiliser dans Fox, comment nous voulons les étendre, et c’est simplement… notre travail ! Donc, pour le moment, nous sommes centrés sur Sedna, et pas sur la suite. On ne peut rien dire sur la suite, mais il n’y a aucune différence avec ce qui s’est passé à chaque mise à jour.
 David Stevenson : Je pense que le souci de la plupart des gens est de savoir si la porte est fermée en ce qui concerne d’autres évolutions.
 Ken Levy : Une bonne réponse à cette question serait de dire qu’il y a une possibilité qu’il n’y ait aucun perfectionnement après Sedna, et qu’il y a une possibilité qu’il y en ait. Nous aurions répondu de la même façon, lors de la disponibilité de VFP8, et que les gens nous questionnaient sur l’après VFP9. Nous sommes totalement honnêtes, et nous ne cherchons pas d’échappatoires. Personne ne s’est réuni ou n’a pris de décision chez Microsoft, et nous attendons deux années de plus pour envisager cela.
 Alan Griver : Une réponse courte est de dire que la porte n’est pas fermée à des évolutions après Sedna. L’autre aspect de la réponse est que nous ne savons pas ce qu’il y a derrière la porte.
 Ken Levy : Nous avons deux objectifs parmi d’autres, dans Sedna, qui sont évidemment que nous aimerions que les développeurs Visual FoxPro et leurs utilisateurs utilisent le plus possible de technologies .NET, et éventuellement passent à Longhorn (Windows Vista). C’est quelque chose d’évident. D’un autre côté, si les développeurs FoxPro et leurs solutions étendent .NET et qu’ils ont des besoins sur ce terrain, et s’ils passent à Longhorn (Windows Vista), nous devons nous assurer de leur réussite autant que possible, et qu’ils ne soient pas bloqués par des barrages. C’est complexe. Nous essayons d’encourager les gens à utiliser d’autres produits et technologies pour faire de meilleures applications, et en même temps nous les aidons tout le long du chemin et nous ne les laissons pas tomber.
 David Stevenson : Comment êtes-vous arrivés à imaginer ce genre d’évolution ? C’est vraiment différent de ce qu’on a vu dans le passé, pour le développement normal d’un produit.
 Ken Levy : Pour répondre honnêtement, ça a été discuté avec le haut management, y compris Eric Rudder. C’est dans une collaboration d’idées et de choix, où nous avons disséqué tout ce que nous pouvions faire, et il a semblé que tout le monde était d’accord pour dire que c’était la meilleure option pour le long terme. Nous avons clairement établi que notre objectif n’est pas d’intégrer FoxPro directement à la plateforme .NET, mais que nous allons développer FoxPro comme une base d’évolution, et que nous ajouterions plus de fonctionnalités comme celles de Visual FoxPro dans Visual Studio (.NET). Nous devons conserver ces deux points de vue à l’esprit.
 Alan Griver : J’ai une réponse légèrement différente. Tout dépend de ce que comporte une mise à jour. On peut prendre un produit – et ça change suivant les endroits – prenons un exemple. Si vous regardez le monde Linux ou celui de l’open source, vous allez trouver différentes mises à jour en même temps, et vous allez en prendre une ici, deux là, etc, etc…et ça embrouille tout le monde, et c’est difficile de suivre.
 Nous, nous disons que nous avons un pilier pour Sedna. Ce pilier, c’est l’interopérabilité. A l’instant où vous dites ça, ça signifie que vous n’allez pas changer le contrôle grid. Vous n’allez pas toucher au textbox. Nous n’allons pas en faire plus avec le moteur SQL – nous en avons fait une tonne dans VFP 9. Nous pouvons faire des choses dans deux directions. On pourrait dire qu’on va tout mettre dans l’exe, qui grossirait alors de plusieurs centaines de bytes ou de megabytes, et il y aurait le risque d’introduire une nouvelle instabilité dans le code existant.
 Ou bien, on peut se dire, vous savez, architecturalement, on a fait un bon travail avec la 9, et il serait préférable de fabriquer des DLL périphériques qui n’affecteraient pas la stabilité du noyau du produit, dont nous connaissons la solidité incroyable. Continuons dans ce sens, et voyons jusqu’où on peut aller en rajoutant des fonctionnalités sans toucher au noyau. Est-ce que ça veut dire qu’on n’y touchera pas ? Non, et c’est pour ça qu’on a parlé d’un SP (Service Pack) – ou quelque chose de ce genre. Il peut y avoir des choses qui fonctionneraient mieux sur le plan de l’architecture, avec une gestion différente, alors ajoutons cette approche différente dans le noyau du produit et rendons le disponible à l’ensemble de la communauté Fox, et utilisons-le, nous aussi.
 Les gens parlent toujours des langages de programmation qui ont été écrits avec le langage lui-même. Le framework .NET a été écrit en C# et en VB. De plus en plus de parties de Visual Studio sont maintenant écrites en langage managés (.NET). C’est pour cette même raison que ce que nous ajoutons pour nous bénéficie à nos clients. Ça veut dire que si nous ajoutons des nouvelles possibilités d’extensibilité dans Sedna, et que nous démontrons comment on va le faire – alors vous savez, si on fait la moitié de ce qu’on a prévu pour Sedna sans toucher le noyau de Fox, alors Fox, c’est un produit d’enfer !
 Oui, je pense que c’est vraiment le noyau, et qu’en ne touchant pas à l’EXE, ça rend les choses plus faciles, et aussi, franchement, cela réduit nos coûts également. Ça veut dire que nos tests n’ont pas besoin d’être augmentés, et qu’on peut exécuter les tests de VFP 9 en étant surs que tout continue de fonctionner. Ça se répercute sur les coûts de formation et d’après-vente. Ça veut dire que les études de cas restent d’actualité – il y en a cinq nouvelles pour VFP 9 en ce moment sur le web. Dès que vous mettez une nouvelle version basée sur un nouvel EXE, vous mettez toutes les études de cas aux archives et vous recommencez à nouveau. Pour ceux qui ont travaillé avec nous sur ces études de cas, ça leur donne plus de temps pour faire la publicité de ces études. Voilà, je pense que c’est une grande victoire pour beaucoup de monde.
 Ken Levy : Je voudrais approfondir deux points abordés par YAG. Sur un plan technique, nous pouvons faire beaucoup de choses avec des DLL écrites en C++, de la même façon qu’on ferait le code d’un composant natif pour aller dans VFP. Par exemple, nous pourrions exposer beaucoup d’API pour Longhorn (Windows Vista) et essayer de les traiter comme des extensions du langage naturel. On pourrait facilement mettre tout ça dans une espèce de DLL, et dire SET LIBRARY TO, et juste avec cette ligne de code, vous auriez un langage étendu. Et on a tous ces autres composants qui font toutes ces autres choses, et vous êtes alors en train de construire sur la plateforme VFP 9.0, pour ainsi dire. Un autre avantage est que quand Sedna sortira, il y aura plein de choses dedans, et ceux qui auront besoin de 30 ou 70% de ses capacités prendront et choisiront les composants dont ils ont besoin, sans toucher à l’application existante parce qu’elle sera toujours sur la même base. Le processus de mise à jour et la flexibilité des tests devraient être encore meilleurs pour eux. Ça facilite la gestion des solutions et le déploiement.
 Alan Griver : L’autre chose, c’est que ce n’est pas quelque chose que nous n’avons jamais fait auparavant. Je reviens vraiment loin en arrière, non ?
 David Stevenson : Vraiment loin !
 Alan Griver : Vraiment, vraiment trop loin. Pour ceux qui ne me connaissent pas, ma première version de Fox était FoxBase 1.21. Ce dont bon nombre de gens ne peuvent pas se souvenir, c’est que la première fois que vous vouliez accéder à un serveur SQL depuis Fox, il vous fallait vous procurer le kit de connectivité, qui pour l’essentiel faisait un SET LIBRARY TO, et soudain vous aviez accès au serveur SQL. Ça n’a pas été inclus dans le produit avant deux ou trois mises à jour, si bien qu’au début, c’est comme ça qu’on faisait. Vous avez eu COMUTIL (VFPCOM.DLL), pour avoir accès à de nombreux événements COM, vous utilisez aujourd'hui une librairie – un fichier à part. Nous allons continuer cette glorieuse tradition.
 Ken Levy : Et quand nous devons mettre à jour ces composants avec l’évolution technologique, nous mettons à jour juste ces petits composants, pas le produit entier. Plutôt qu’un service pack 1, 2, 3, et 4, juste avec les fonctionnalités du noyau en rapport avec des technologies externes, maintenant nous pouvons avoir des composants sur lesquels on se raccorde, que ce soit des FFC, des DLL, des wrappers .Net, et ainsi de suite.
 David Stevenson : On a parlé de la façon dont on aurait les betas progressivement pendant ces deux années pour que les gens puissent les utiliser, mais que la version finale de Sedna, quel que soit son nom définitif, sera probablement payante.
 Ken Levy : En règle générale, je dirais que c’est environ six à huit mois avant la livraison de la mise à jour que nous commençons à travailler sur l’emballage, la distribution, la tarification, et le nom. Tout ça arrive en même temps. Dans le cas de Sedna, ça sera vers la fin de 2006. D’autre part, il nous faut à peu près un an et demi pour concevoir Sedna. Nous prendrons des décisions rapides, mais l’évolution continuera, et on peut très bien avoir une illumination en Avril de l’année suivante, et faire quelque chose à laquelle on n’avait jamais songé jusque là.
 Alan Griver : Autre chose, au sujet du prix et de la beta – rien de différent. Je pense que parfois les gens divaguent parce que nous avons annoncé ça dans la Feuille de route. Pour Vfp 8, il y avait une beta publique qui était gratuite pour tout le monde, mais une fois le produit mis en vente, si vous vouliez continuer d’utiliser la 8, il fallait payer. VFP 9, beta publique, libre pour tous. A la mise en vente, vous payez. Tout ce que nous disons pour Sedna, c’est beta publique. Que va-t-il se passer quand on va le vendre ? On le verra, mais, vous savez, je crois qu’on va trouver le moyen de gagner de l’argent avec.
 David Stevenson : Il a été dit publiquement, je crois que c’est Ken, en réponse à une question posée, que l’avenir de VFP n’était pas lié aux ventes de VFP ? Sur quelles décisions repose l’avenir de VFP ?
 Ken Levy : Pour être clair à ce sujet, si pour une raison quelconque la courbe des ventes se modifie, ça ne signifie pas que nous allons nous arrêter et dire « je crois que nous n’allons pas faire Sedna ». Nous ne voulons pas que les gens ressentent de l’insécurité vis à vis de nos plans et de nos engagements définis dans la Feuille de route de Visual FoxPro, comme ça a été le cas pour VFP 9. Il peut y avoir des gens qui attendent quelques mois pour changer de version, peut-être parce qu’ils développent en VFP 8 ou en VFP 6, ou pour toute autre raison, et nous sommes très engagés pour aider les développeurs FoxPro et les utilisateurs de leurs applications à avancer sur les nouveaux produits et les technologies Microsoft. C’est une publication très stratégique pour la fonctionnalité additionnelle de FoxPro.
 Alan Griver : Nous recherchons toujours le bénéfice, d’accord ? Mais une fois que nous avons le budget pour une nouvelle version, le bénéfice n’est plus la question. Avant qu’on ait le budget pour Sedna, avant qu’on se soit engagé sur Sedna, une partie du problème était, bien entendu, la façon dont nous pouvions faire de l’argent avec ça. Est-ce qu’on pourrait faire mieux en utilisant ces ressources ailleurs ? Vous savez, c’est la même discussion à chaque fois, pour n’importe quel produit. Est-ce qu’on va amener assez de personnes à l’adopter pour compenser l’effort massif nécessaire à la fabrication de la prochaine version de X ?
 David Stevenson : Ça nous amène à la question de l’équipe VFP. Je crois que beaucoup de gens voudraient savoir ce qui se passe dans l’équipe VFP. Nous savons qu’une partie d’entre eux travaille sur d’autres projets, pour une partie de leur temps. À quoi ressemble l’équipe, à quoi va-t-elle ressembler dans les prochaines années en termes de taille, et du pourcentage de ce temps qui sera consacré à Fox ?
 Alan Griver : J’ai écrit un texte de blog il y a quelques mois – pas dans le détail – qui parlait en gros de l’équipe que je dirige, le Visual Studio Data. C’est une équipe qui est constituée de plusieurs groupes, si vous voulez. Fox est l’un d’entre eux, et le Data Tools de Visual Studio en est un autre. Je ne crois pas qu’il doive y avoir un mur entre les deux équipes. A cet effet, certaines personnes de Fox apportent quelques unes des grandes possibilités de Fox à .NET. Mais en même temps, il y a des personnes de l’équipe du Visual Data Tools qui travaillent maintenant sur Fox. Ce n’est pas une question de ressources qui iraient à sens unique de Fox vers Visual Studio.
 J’ai pris un directeur de programmes qui s’appelle Milind Lele, et en principe, à notre retour, nous devrions commencer à présenter certains d’entre eux dans des endroits comme Universal Thread. Milind travaille maintenant avec Randy Brown sur le SP1 de VFP 9. On a un bon groupe de test dans mon équipe, qui travaille maintenant aussi sur Fox, et qui apporte des outils qu’on utilise dans les tests de Visual Studio – qui a de toute évidence une beaucoup plus grande zone de tests à couvrir – il apporte ça à Fox, de sorte qu’on peut faire encore plus d’automation, de contrôle de code, et ainsi de suite.
 Pour moi, c’est vraiment important qu’il n’y ait aucune frontière entre les deux. C’est pour ça que, si vous regardez mon équipe d’encadrement, certains de mes cadres, comme mon responsable des tests, un dénommé Cameron Slide, qui était responsable test sur Fox, maintenant il est responsable test de VS Data. Ken, qui est responsable Produit de Fox, est maintenant responsable produit de VS Data. J’ai pris des cadres du VFT (visual data tools), et maintenant ils sont cadres du VS Data. C’est mon boulot de dire que j’ai deux produits à fournir, dont les cycles commerciaux sont différents, et j’ai besoin de ressources sur l’un ou sur l’autre à des moments différents. Au lieu d’avoir ici deux personnes qui sont les seules à tout savoir sur Fox, et là deux autres qui sont les seules à tout savoir sur VS Data, j’ai quatre personnes qui connaissent l’ensemble. Je peux dire, aujourd'hui, il me faut trois et un, et demain ça sera deux et deux. Ça me donne une flexibilité supplémentaire, et ça nous aide à fournir des produits plus rapidement.
 Ken Levy : Les gens doivent se rappeler que nous faisons toujours partie d’une seule équipe, et que c’est l’équipe Microsoft.
 David Stevenson : Ça ressemble à une réponse marketing typique.
 Ken Levy : Par exemple, notre équipe a aide à piloter et à soutenir les outils XML qui ont été introduits dans Visual Studio 2005. C’était un petit effort à temps partiel pendant le développement de VFP 9. Mais il y a beaucoup d’autres tâches avec la documentation, et tous ces autres facteurs qui sont transversaux à différentes équipes. Ainsi, oui, il y a une équipe noyau qui travaille la plupart du temps sur Visual FoxPro, mais c’est une des dimensions dans l’ensemble du développement et du déploiement de FoxPro et de ce qui s’y rattache. C’est pourquoi je dis qu’il y a une grande équipe Microsoft – pas de groupes complètement isolés.
 David Stevenson : Vous avez évoqué le SP1 pour VFP 9, pour les environs de la fin de cette année. On peut s’attendre à quoi, dans ce Service Pack ?
 Alan Griver : Ça sera un Service Pack habituel comme on en a déjà vu, qui corrigera les bugs critiques que nous avons vus.
 Ken Levy : Ça sera comme le SP1 pour FoxPro 8 – il y en aura juste un pour la version 9.
 Alan Griver : Nous attendons la fin de l’année simplement parce qu’on ne nous a pas signalé suffisamment de bugs critiques pour que ça vaille la peine de le faire. C’est un peu comme un jeu de balancier intéressant. Un service pack nécessite beaucoup de tests, d’accord ? Nous devons le tester sur des systèmes d’exploitation différents, installé avec de nombreuses autres applications. On doit être certains que le SP1 ne va pas casser Excel ou Visual Basic ou je ne sais quoi. Il y a une grosse part de test qui en fait partie. Si on le fournit trop tôt, et que de ce fait on a encore des retours sur d’autres bugs critiques, alors il faut faire un second service pack qui épuiserait mes ressources, et ça affecterait Sedna. Donc on aimerait que ça aille en diminuant, et avoir donné un bon nombre de réponses aux problèmes critiques. Nous en avons tellement moins que pour la 8 que nous préférons attendre pour être surs de viser juste.
 David Stevenson : Vous avez dit que vous vouliez l’avis de la communauté sur ce qu’elle souhaitait voir dans Sedna. Certains ont dit lors de la présentation « donnez-nous des scénarios, et nous vous ferons des propositions techniques ». Qu’est-ce que vous attendez vraiment des gens, et quelle est la meilleure façon pour qu’ils vous le disent ?
 Ken Levy : Aujourd’hui, ce que nous mettons en ligne pour la communauté, les pensées, les idées, les paramètres, autour de ce que nous projetons de faire pour développer Visual FoxPro, tout ça est beaucoup plus détaillé que tout ce que nous avons fait pour les versions précédentes. Aussi, de façon régulière, nous montrons nos limites, nos objectifs globaux, ainsi que les points et les zones qui seront nos priorités. Au cours des six prochains mois, nous allons les approfondir pour définir des caractéristiques plus spécifiques – quel sera leur impact, quel est leur fil conducteur. Nous devons justifier tout ce que nous faisons et dire ce que ça aura comme effet.
 Nous voulons que la communauté nous accompagne pendant ces publications d’information quasi-mensuelles sur ce que nous avons projeté – de nouvelles idées – et nous fasse des retours réguliers. Ça ne veut pas dire qu’il y aura des idées au hasard, sans rapport avec nos buts et objectifs – nous voulons que la communauté nous accompagne et là, OK, c’est ce que nous essayons de faire, en interaction. Comme pour le grid, si quelqu'un demandait une nouvelle spécificité du genre colonne, nous répondrions probablement que ce n’est pas dans notre liste de priorités – pouvez-vous nous proposer des dispositifs et des scénarios en rapport avec les buts que nous avons dégagés ?
 Nous voulons beaucoup plus d’interaction avec ce que nous exposons de façon régulière, comme dans la section Sedna du forum VFP sur Universal Thread.
 David Stevenson : Comment les gens devraient-ils faire ? En vous envoyant en mail, à vous ou à Randy, ou en postant sur Universal Thread ou sur le wiki ?
 Ken Levy : Le mail direct est compliqué parce qu’il ne peut pas facilement être discuté par tout le monde. Pour le moment, pendant encore quelque temps, utilisez la section Sedna dans Universal Thread, mais nous recherchons d’autres voies pour avoir des entrées, des discussions et des retours en ligne. Nous allons essayer un centre de retour à la fin de l’année.
 Alan Griver : Pour que ça soit vraiment clair pour tout le monde – nous avons rendu publics les piliers de Sedna. Ce sont l’interopérabilité avec .NET, l’interopérabilité avec Longhorn (Windows vista), l’interopérabilité avec SQL Serveur 2005, et l’interopérabilité avec Office 12. Alors, ce que les gens peuvent faire de mieux, c’est de nous donner des scénarios. Comment comptez-vous l’utiliser ? Vous pourriez dire, j’ai une grosse appli VFP sur laquelle je travaille depuis des années, ma compagnie fusionne avec une autre qui utilise une appli .NET, et nous devons faire communiquer les deux. Voilà les solutions que nous avons trouvées avec VFP 9 – ce serait beaucoup plus facile si on pouvait le faire automatiquement. Ou bien, j’ai entendu dire que Office 12 enregistrait tout au format XML, est-ce que ça ne serait pas merveilleux d’avoir un nouveau type d’export qui s’appellerait Word 12 ou Excel 12 ? Ce sont des choses de ce genre – des scénarios de haut niveau pour des choses qui apporteraient une aide réelle si nous les rendons disponibles.
 Ken Levy : Un des piliers vraiment importants à ajouter à tous ceux-là, est la zone d’extensibilité dans FoxPro – ce que nous appelons en interne les « composants Xbase » qui sont écrits en FoxPro. Dans la présentation, une des deux des démos passionnantes portait sur une nouvelle architecture « My-dot » basée sur Visual Basic 2005, un genre de communication rapide entre les fonctions communes ou inhabituelles pour découvrir les choses. L’autre était une démo sur une fonctionnalité du report, qui en gros étend le système de report de VFP 9, dans lequel vous entrez et vous déclarez des choses facilement, sans code, et qui déclenche et exécute automatiquement le ReportListener. Tout ça est écrit en Visual FoxPro, et nous pensons qu’il y a beaucoup, beaucoup de façons de développer le noyau de VFP sans toucher à rien d’extérieur, que nous pouvons intégrer dans Sedna. C’est un peu comme si on prenait le meilleur dans les deux mondes : l’interopérabilité et les caractéristiques nouvelles de FoxPro.
 Alan Griver : Mais je voudrais que les gens soient précis. Quand nous parlons de scénarios, nous voulons comprendre ce qu’ils essayent de faire. Nous pourrons y arriver en utilisant Xbase, ou une DLL, ou en faisant des changements méticuleux dans l’exécutable. On peut le comprendre, mais si on a beaucoup de bons scénarios et que nous faisons un bon travail structurel, on peut découvrir que la moitié des scénarios trouveraient leur solution dans un changement architectural dans Fox – voilà ce qu’est vraiment notre travail.
 David Stevenson : YAG, vous avez dit tout à l’heure qu’il était important que ces retours soient mis en place rapidement, au début du processus de fabrication dans la mesure où il peut toujours y avoir des effets de bord sur d’autres technologies, et vous avez mentionné des changements qui avaient été faits dans Visual Studio 2005 en rapport avec un problème concernant Fox. Vous pouvez être plus précis à ce sujet ?
 Alan Griver : Un des aspects agréables, dans le fait de diriger VS Data et d’être responsable de l’histoire des données à la fois pour Fox et pour VS, c’est de pouvoir faire des choses comme l’Explorateur de Serveurs et la plupart des données – je ne peux pas dire toutes – accèdent elles-mêmes dans un Visual Studio 2005 orienté données. Il se trouve que les données sont des fichiers XML, mais ça veut dire par exemple, que si vous ajoutez une base de données d’un serveur SQL 2005 à l’explorateur de serveurs, que vous créez une connexion à celle-ci, vous pouvez voir maintenant beaucoup plus que les Procédures, les Tables et les Diagrammes, qui est ce qu’on voyait auparavant. Maintenant, vous pouvez voir des choses comme les Types Définis par l’Utilisateur, les Assemblies, etc, etc… nous avons ajouté cette caractéristique à travers les extensibilités que nous avons créées.
 Ça veut dire par exemple, que nous pouvons dialoguer avec IBM ou Oracle, et quand vous cliquez dans l’explorateur de serveurs, vous ne voyez pas seulement les procédures et les tables, mais avec Oracle vous voyez les packages. On permet à IBM ou Oracle de définir eux-mêmes quels genre de vues ils veulent rendre disponibles pour les développeurs, celles qui conviennent à leur socle.
 On peut avoir le même système quand nous sortirons Visual Studio 2005, et proposer ce genre de possibilité pour les DBC FoxPro, et on peut aussi utiliser beaucoup de cette information contenue, pour permettre des choses comme la création de forms par drag and drop, et ainsi de suite. Quiconque a essayé de créer un Adaptateur sur un DBC VFP dans Visual Studio 2002 ou 2003 sait que ça nécessite beaucoup de code manuscrit, parce que beaucoup d’assistants ne fonctionnent pas. Nous avons commencé à regarder tout ça de très près – je ne veux pas dire qu’on fait ça à 100%, parce qu’on doit aussi livrer Visual Studio 2005 – mais nous nous efforçons d’utiliser ce type d’extensibilité à travers tout le secteur des données dans 2005, et dans ce qui suivra, Orcas.
 Vous verrez que les DBC de Fox vont mieux interopérer dans Visual Studio 2005 à cause de choses comme ça. Comme je l’ai dit précédemment, quand j’ai pris la direction de l’équipe, on n’a pas simplement dit OK, on va aussi s’occuper de Fox dans Visual Studio. Non, nous avons dit ce que nous pouvions faire structurellement pour résoudre ce problème de soutenir N bases de données, et c’est ce que nous avons fait. Avec l’arrière-plan Fox qui est commun à beaucoup d’entre nous, nous pensons plus à ce niveau en termes de possibilités orientées données.
 David Stevenson : Peut-on s’attendre à plus de possibilités orientés données, dans les prochaines versions de Visual Studio?
 Alan Griver : J’aimerais voir beaucoup de choses que vous avez l’habitude d’utiliser dans Fox arriver dans Visual Studio au fur et à mesure. Un autre exemple, quand je parlais de création de formulaire par drag and drop. Vous avez la fenêtre de la source de données où vous précisez sur quelle parie de la base de données vous voulez travailler dans votre application WinForm. Pour chacun de ces éléments, vous pouvez spécifier quel contrôle doit être utilisé quand vous faîtes un drag and drop sur un formulaire, y compris des controles personnalisés, tout à fait comme dans Fox. Vous faîtes un drag and drop, et ça fonctionne, et vous pouvez utiliser exactement la même source de données pour créer vos rapports, tout à fait comme dans Fox. Beaucoup de ces idées sont disponibles – Fox est présent sur l’ordinateur de nombreux Directeurs de Programmes qui sont responsables des données.
 David Stevenson : Le blog Sedna qui a été montré pendant la présentation, est-ce que ça sera un support de communication important pour l’équipe ?
 Ken Levy : Non, c’était juste un prototype de démo pour l’amusement. C’est plutôt un blog de démo test, et nous allons nous recentrer sur les blogs des membres de l’équipe déjà existants, et sur la lettre mensuelle d’informations en ligne, pour présenter des choses plus formalisées à l’extérieur. Nous n’allons probablement pas utiliser de blog nommé Sedna, mais nous allons conserver ce que nous avons aujourd'hui – les blogs des membres de l’équipe et la page d’accueil de FoxPro.
 David Stevenson : Vous avez fait précédemment un commentaire que je voudrais reprendre. Vous avez dit, bien entendu nous voudrions voir plus de monde commencer à utiliser Visual Studio .NET. Pourquoi ?
 Alan Griver : Parce que c’est le noyau de la future plateforme de travail pour Microsoft. C’est pur la même raison que, quand les entreprises avaient beaucoup investi sur le DOS, nous avions dit que nous aimerions voir plus de monde utiliser Windows. .NET est la plateforme sous-jacente à tout ce que nous allons faire dans les 10 prochaines années au moins.
 David Stevenson : Alors, des clients qui ont des ressources existantes après avoir investi des années et des années dans du code bien débogué, dont ils dépendent pour des applications sur des missions critiques, vous allez leur dire qu’ils doivent se préparer à réécrire tout ça.
 Alan Griver : Non, nous disons que tout continuera à fonctionner, tout comme dans Windows aujourdhui vous pouvez faire fonctionner un VisiCalc des années CPM, comme fonctionnent les applis DOS, comme fonctionnent les applis Windows 16-bits – tout ça fonctionne sous Windows aujourd'hui, et tout ça fonctionnera sous Longhorn (Windows Vista). Nous disons que nous avons en ensemble de code bien débogué que nous allons continuer à étendre avec .NET – nous faisons la même chose que ce que nous recommandons aux autres. Nous avons une grande base de code, alors étendons le en utilisant .NET – voilà ce que nous disons.
 Ken Levy : Particulièrement pour Sedna, nous projetons d’ajouter beaucoup de fonctionnalités et de possibilités, dans des endroits qui toucheront le framework .NET, et qui nécessiteront de consacrer du temps à l’environnement de développement de Visual Studio, pour construire une application dont les fonctionnalités iront bien au-delà de tout ce que FoxPro seul peut faire aujourd'hui. Nous pensons que l’utilisation de ces outils apportera beaucoup d’autres possibilités aux développeurs Fox – tout comme un peu plus de la moitié des développeurs Fox utilisent SQL Serveur avec FoxPro. Nous prévoyons qu’une grosse moitié des développeurs Fox utilisera la programmation .NET parallèlement à la programmation Fox, comme outil complémentaire pour fabriquer le produit final.
 Alan Griver : Rien que nous n’ayons déjà vu. Je me rappelle le passage de Fox DOS à Windows, et les cris lors de la première livraison de VFP. Beaucoup de développeurs ont utilisé VFP dans les 10 dernières années – peut-être ne se souviennent-ils pas du groupe énorme qui disait « je ne vais pas migrer à VFP parce que Fox DOS et Fox Windows 2.6 font tout ce dont j’ai besoin ». Par la suite, les gens ont vu les possibilités, et je pense que ça sera la même chose.
 Ken Levy : Pour conclure, l’équipe de Visual FoxPro est au moins aussi enthousiaste sur le potentiel de Sedna que ce qu’elle était quand nous avons démarré Europa (Visual FoxPro 9).
 
Commentaires
Aucun commentaire enregistré ...

Publicité

Les pubs en cours :


www.atoutfox.org - Site de la Communauté Francophone des Professionnels FoxPro - v3.4.0 - © 2004-2024.
Cette page est générée par un composant COM+ développé en Visual FoxPro 9.0-SP2-HF3