Je vais répondre à toutes vos réponses par un seul mail. 1. Microsoft dans la boite : L'informatique dite "banalisée" (PC Bureautiques) a été outsourcée. C'est Windows sur les serveurs, Windows sur les desktops. Mais il reste un Solaris ou l'autre plus quelques Linux. Les desktops ont IE et MS Office. Nous n'avons pas la main sur ces machines. 2. Le service informatique de la boite : Il développe essentiellement le portal intranet/extranet et d'autres applis que je connais pas. Mais pour des raisons "humaines" que je devine, on a "oublié" de la consulter. C'est donc par hasard que j'ai pris connaissance de ses positions par rapport à Microsoft. 3. L'utilisation d'un document en .Doc, ben c'est le "standard" dans la boite. PDF est utilisé dans 2 cas. L'envois vers l'extérieur et les documents scannés. 4. Quand je dis que la boite n'est pas sensible à L'open-Source, je veux dire que des arguments comme la redistribution ses sources ne percute pas. Le coût des licenses ne l'est pas forcément. Exemple, le framework .NET est "gratuit" pour l'utilisation. Je ne parle pas de licenses VS.NET ou CR développeur. 5. Quand je dis qu'elle se méfie de MS, c'est le service informatique interne qui a eu de drôles d'expériences avec l'Extranet et Firefox. 6. Après 10 ans, passés à utiliser Linux dont 8 ans comme seule solution à la maison, je ne suis plus à convaincre à ce sujet. 7. Le pire dans cette affaire, c'est que les règles d'appel d'offres ont été un peu baffouée car l'une des socièté contactée (celle qui à remis le projet que je vous soumet) à partcipé à la rédaction du budget déjà remis au client :( Et oui à l'époque, elle fesait partie du même groupe. 8. Elle a remis une offre très près du budget prévu, elle le connaissait.
Je sentais bien l'arnaque. Le comportement agressif du commercial m'avait déjà mis la puce à l'oreille. Il a très mal pris mes questions sur la portabilité et l'interface Web. Puis j'avais le sentiment qu'il voulait nous mener en bateau et garder la main sur de futurs développements. Surtout que la chef de projet ne connais que FORTRAN. Maintenant, j'ai des arguments face à eux et je pourrais comparer aux autres solutions. Dont une .NET mais avec client Web. Je vais aussi regarder les différents liens proposé et voir ce qu'il en retourne. Pascal, pourrais-tu me donner une idée du surcoût pour une interface "Web" par rapport à un client riche ? La solution d'interfacage avec OOo2 ne me plait pas vraiment dans ce cas, même si je l'utiliserais avec plaisir dans d'autres. Pq ? Simplement que le "rapport" doit absolument être fait en .Doc, que le "modèle" a été réalisé avec MS-Office, que les modifications éventuelles (logo, .....) seront faites avec le même soft (à moins qu'ils ne deviennent intelligents et prennent OOo) et que je veux avoir le même résultat, tip top le même. Merci. Je sens que ça vas saigner. On Saturday 21 October 2006 15:00, Pascal Bleser wrote: > Thierry Leurent wrote: > ... > > > Une des solutions présentées. > > Serveur Oracle pour la base, .NET 2 (C#) + Crystal Report pour la couche > > application et la couche client, Word/VBA pour le rapport. > > Euh... je cite: > "Ma boite n'est pas sensible à l'Open-Source, mais devient sensible aux > standards et à la portabilité Elle a eu de mauvaises expériences avec du > tout Microsoft." > > Donc on prend .NET (MS), Crystal Reports (Windows), Word/VBA (MS). > Logique ;) > > > Nous avons rencontré la société qui propose cette solution. > > Quand, j'ai parlé de portabilité Ils ont parlé de Java et ont justifié > > le choix de .NET par rapport à Java en indiquant que Java était plus > > lourd, moins aisé pour un développement rapide et surtout moins stable > > dans le temps. > > Ils ont parlé que d'un JDK/JRE à un autre des fonctions disparaissaient > > ou que les appels changeaient. Donc une application développée avec le > > JDK 1.3 ne pourrait pas être utilisée avec le JDK 1.5. > > Quoi ? HAHAHAAHAAAAAAAHAHAHAHAA MDR > C'est une blague ? C'est quoi ces clowns ? > > Bon, alors: > 1) Java "plus lourd" que .NET > Ca veut dire quoi ça ? > - .NET et toute sa communauté n'a pour l'instant _aucune_ solution pour > tout un tas de problèmes qu'ils vont encore rencontrer dès qu'ils vont > développer des applications un chouya plus complexes (mappings ORM, > identité d'objets quand on fait du remoting, intégration de systèmes > "legacy", clustering HA, ...) > - je veux bien que Ruby ou Python soient "moins lourds" que Java > puisqu'ils ne proposent des solutions que pour des problèmes moins > complexes, mais .NET... euh... n'importe quoi > > Si c'est une question de performances, c'est ridicule: Java sur le > serveur est extrêmement performant, d'une part par la JVM elle-même > (hotspot compiler, garbage collection) qui a 8 ans d'avance sur celle de > .NET, d'autre part parce que des applications "enterprise" sont > développées depuis des années avec Java et qu'il y a des solutions, > produits et standards permettant des approches hautes performances. > > Certes, Swing est assez "lent" sur le client, mais pour ça c'est > portable, le modèle de développement est très bon (MVC) et solide. > Franchement, on fait beaucoup d'applications client Swing complexe > (entre 50 et 400 utilisateurs en même temps) + conteneur EJB et ça > fonctionne très bien, aucun client ne s'est jamais plaint (beaucoup de > clients banques, télécoms, ...). > Note qu'on fait aussi des applications web et j'en ai fait quelques-unes > d'assez complexes dans mon temps libre (http://packman.links2linux.org). > C'est bien aussi mais c'est plus compliqué et prends plus de temps à > développer (complètement stateless, portabilité au niveau des navigateurs). > > 2) Java moins aisé pour un développement rapide > En gros, ils te disent qu'ils développent comme des m..... > > Quand tu sais ce que tu fais et que tu écris quelque chose de solide, > peu importe Java, Ruby, .NET, Python, C++, ... (mais quand même pas > visual basic). > > 3) moins stable dans le temps > Alors là c'est le pompon. C'est exactement le contraire. > .NET 2.0 est totalement incompatible avec .NET 1.x > Java 6 est "upwards compatible" avec 1.1, càd que du code écrit pour 1.1 > fonctionne encore avec 6 (juste quelques petites différences avec Swing > à partir de 1.3 et 1.4 côté client). > > C'est justement un des grands avantages de Java, la compatibilité. > JEE 5 est compatible avec J2EE 1.3 et 1.4. > > Évidemment, si tu écris du code Java qui utilise les nouvelles > fonctionnalités de Java 5 (generics, annotations, autoboxing), ça ne > fonctionnera pas sur 1.4 ou 1.3. > C'est un choix à faire lors du développement (ou du cahier de charge). > > Par contre, écrit avec Java 5, ça fonctionnera avec Java 6 et 7 et ... > Et tu peux très bien écrire des applications Java en utilisant que les > fonctionnalités Java 1.4 (même si tu utilises une JVM 5). Dans ce cas, > ça fonctionne sur 1.4, 5, 6, ... > C'est pas si compliqué, juste une option de configuration dans Eclipse ;) > > Pareil avec JEE. > > "Ils ont parlé que d'un JDK/JRE à un autre des fonctions disparaissaient > ou que les appels changeaient. Donc une application développée avec le > JDK 1.3 ne pourrait pas être utilisée avec le JDK 1.5." > > Complètement faux, mensonge ou incompétence pure et simple. > > > Quand j'ai parlé de technologies "WEB", j'ai eu > > - Un "c'est trop compliqué il faut développer pour chaque browser". Pour > > les technologies web en général. IE occupant 90 % des parts du marché > > (C'est pas les derniers chiffres dont je me rappels mais bon) > > - Un "C'est du bête HTML", pas convivial. Pour les normes W3C. > > - Un "C'est volatile (ça change tous 12 à 18 mois). AJAX !!! Berrrrrk > > !!!! Vous voulez développer une application critique en AJAX ????? Mais > > vous êtes fou !!!" Quand j'ai parlé d'AJAX. > > Eh bein. > > > Voici mes conclusions qui demandent vos commentaires et retours > > d'expériences : > > - Vu la complexité des "calculs" et des contrôles (Calculs basics et > > intégrité référentielle), Je placerais tous cela au niveau DB. Donc la > > partie application/client fait des appels à la DB et des "impressions". > > Moui. Pour l'intégrité référentielle, oui, forcément dans la DB. > Mais des "stored procedures"... Pas une bonne idée à mon avis, parce que > tu te lies à une base de données bien spécifique (p.ex. PL/SQL Oracle, > si tu passes à une autre DB (p.ex. PostgreSQL ou DB2), oublie, faudra > ré-écrire beaucoup). > > Plutôt faire ça dans le code applicatif. > > Les stored procedures, c'est surtout intéressant pour optimiser (en > termes de performances). Dans ce cas, tu as sûrement ton architecture > bien propre, avec un DAO qui fait abstraction de la base de données et > de comment certaines données sont tirées de la DB (ou autre chose), donc > il suffit de modifier le DAO et tout le reste de l'application reste > pareil. (enfin, ça, c'est une architecture propre comme un le fait > classiquement avec Java, certainement pas le genre de choses que les > développeurs de cette boîte connaissent) > > > - .NET 2 n'est pas portable enfin pas encore son support dans Mono est > > prévu pour la fin de l'année. Puis, il faut voir les bibliothèques > > utilisées. > > .NET == portabilité 0 > > Le "standard" .NET est encore en mouvement, et l'est probablement encore > pour un bon moment. Comme déjà dit, .NET 2 est incompatible avec .NET > 1.x (et pas qu'un peu). > > Et puis que .NET soit un standard... ouais, sur papier ou dans la > propagande MS, mais dans la réalité... > > La CLI .NET (équivalent de la JVM Java) et C# sont effectivement dans le > standard ECMA, mais > - dans les faits, le "standard" .NET est contrôlé à 100% par MS > - d'autres composants nécessaires au développement d'une application ne > sont pas dans le standard ECMA, que ce soit ASP.NET, les librairies de > développement d'applications graphiques, etc... > > Java n'est pas uniquement contrôlé par Sun, il y a le JCP (Java > Community Process). > Certes, il n'y a pas beaucoup d'alternatives à la JVM de Sun (quoique, > IBM et BEA fonctionnent très bien, et Kaffee et autres JVM libres sont > en cours de développement), mais > - JDBC est un standard > - JEE est un standard (JEE 5 contient même un standard pour les ORMs: > JPA (Java Persistence API)) > - Servlet et JSP sont des standards > - Swing est un standard > etc... > > Avec .NET, tu n'as que la CLI et C# qui sont standardisés (et encore, ça > change tout le temps pour l'instant). > > > - .NET est plus stable au niveau version que Java. Cela m'étonne mais je > > ne connais pas les deux mondes donc je n'ai pas d'expérience concrète et > > vous ? > > Ridicule, c'est exactement le contraire. > C'est comme s'ils te disaient que Linux est plus propriétaire que Windows. > > > - .NET est plus souple que Java. Confirmation ? > > "souple"... là je dirais également que c'est le contraire, parce que > Java contient un très grand nombre de standards et différentes > implémentations (JBoss, Weblogic, Websphere, Glassfish, ......, > Hibernate, .....) > > Au niveau du langage, C# a quelques trucs pas mal au niveau du > "syntactic sugar" mais d'autres qui sont plutôt... bizarres (pas de > checked exceptions). > > > - Crystal Report est l'idéal pour générer des documents à partir de base > > de données et modèles. > > Oui. Mais dans ce cas, tu es lié à Crystal Reports. > http://jasperforge.org/sf/projects/jasperreports > > > - Le Web, c'est pas si pauvre que ça au niveau présentation. Même sans > > AJAX, au pire on adapte un peu le code généré en fonction du browser > > (Transparence des PNG par exemple). Connaissez-vous des sociétés qui > > fuient AJAX ? > > Moui. Là, faut voir. AJAX c'est beaucoup de hype, c'est surtout pour que > des consultants vendent beaucoup de livres et se fassent de l'argent > dans des projets (quoique, "SOA" est encore bien pire à ce niveau-là). > > Certes, AJAX ça peut donner des applications web très conviviales et > très intéressantes (Flickr, Basecamp, ...), mais c'est loin d'être une > technologie mature. Et le coût de développement d'une application web > est toujours plus élevé que pour une application "rich client" (p.ex. > Swing), que tu utilises AJAX ou pas. > On en a déjà fait aussi, c'est pas la panacée, mais dans certains cas de > figure c'est très intéressant. > > Ca dépend vraiment de l'environnement, des contraintes, de la complexité > de l'application. > > > - Un serveur applicatif engendrerait des coûts plus élevés au niveau > > licences (CR par exemple). > > Il y a plusieurs conteneurs libres et gratuits (et très très bons ;)) > pour Java: > - http://www.jboss.org/products/jbossas > - https://glassfish.dev.java.net/ > - http://jonas.objectweb.org/ > - http://tomcat.apache.org/ > - http://jetty.mortbay.org/ > > Pour Crystal Reports: > http://jasperforge.org/sf/projects/jasperreports > > > Questions subsidiaires ? > > - Quelqu'un connaît-il Microsoft Reporting Service ? > > Non merci. > > > - Existe-t-il un "Crystal Report Like" Open-Source ? Pas forcement > > compatible. > > http://jasperforge.org/sf/projects/jasperreports > > > Que pensez-vous de la proposition suivante pour la couche application? > > PHP 5 générant des pages xhtml et des css. > > - clients web > Ca dépend vraiment des fonctionnalités à implémenter. Si tu as une > couche de représentation assez complexe (p.ex. call center), j'irais > plutôt dans la direction des clients riches (p.ex. Swing). > Au niveau du "deployment" (qui est le grand avantage des applications > web), avec Java tu as Web Start > (http://java.sun.com/products/javawebstart/) > > Sinon, si la représentation web est suffisante, pourquoi pas. > > PHP est quand même un langage simple à utiliser mais extrêmement limité > pour le développement d'une application solide (et crois-moi, j'en ai > fait du PHP). > A mon avis, PHP c'est bon pour faire une dizaine des pages web au > maximum, mais pour quelque chose de plus complexe ou plus critique, je > prendrais Java. > > > PHP 5 Triturant du XML-MSOffice pour le rapport normalement en .doc. > > Cette solution pose au moins deux problèmes : > > Comment lancer Word depuis PHP. > > Comment construire facilement de nouveaux rapports. > > http://jakarta.apache.org/poi/index.html > http://radio.javaranch.com/val/2004/10/16/1097909528000.html > "Google is your friend" ;) > > Et puis, pour lancer word à partir d'une application web, il suffit de > mettre le MIME type correctement ("application/msword" ou un truc du > genre). On a des équipes de projet qui ont déjà fait ça pour Excel, pas > vraiment un problème. > > Evidemment, si Word supportait déjà le format ODF, ce serait bien plus > simple pour générer les documents ;) _______________________________________________________ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://lists.unixtech.be/cgi-bin/mailman/listinfo/linux Archives: http://www.mail-archive.com/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #unixtech NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech
