Bonjour à tous,
Ce journal est divisé en deux parties. La première concerne la formation "GÉNIE INFORMATIQUE" en cours de jour au CNAM à Toulouse.
La seconde un projet qui me tiens à coeur et qui serait la concrétisation d'un réflexion personnelle sur les Suites Office et les
Progiciels (deux mamelles de l'administration informatisé des entreprises).
Rappel :
http://linuxfr.org/~djojo/15579.html(...)
Après dix ans passée à travailler en hôtellerie restaurantion, j'ai décidé de vivre ma passion pour l'informatique et d'apprendre à programmer.
Excuses :
Je tiens à m'excuser pour certains propos que j'ai pu tenir et soutenir ici et qui étaient, je m'en rends compte aujourd'hui de belles
conneries (Non pas de lien).
Première partie :
Pour ceux que ça interesse, je vais détailler ici le contenu de la formation que je suie actuellement. L'objectif des formateurs est double :
- Nous donner des bases théoriques et conceptuelles en informatiques
- Nous donner des outils concrets pour qu'on puisse "trouver du travail"
D'un point de vu logistique, nous sommes un petit groupe (quatorze), nous avons une salle "à nous", avec du matos correct (en dualboot Win XP et Fedora),
une imprimante en réseau et un accès internet qui déchire.
Algorithmique/programmation
C'est la matière principale. On travaille les algorithmes de base (nombres premiers, Fibbonacci, tour de Hanoï, piles, listes...) et l'approche Objet. Les profs ont décidés que contrairement aux années précédentes où ils faisaient un peu d'ADA, un peu de C et un peu de C++, ils n'enseignerai plus qu'un seul langage : Java (Tramo Roxor). Donc, on fait tout en Java, ce qui est discutable, mais qui nous permettra de connaître un langage de façon approfondie (chaque fois que j'entends le prof dire que la "référence pointe vers...", je pense à DLFP :-)
Système
Le cours est divisé en deux parties, l'une théorique : ordonnancement, mémoire virtuelle, systèmes de fichier ... présente les principaux algorithmes mis en oeuvre pour résoudre ces problématiques. L'autre partie est un TP sur l'administration en ligne de commande de Linux.
Informatique industrielle
Un nuage zéro et de un, flotte au dessus de la tête du prof. Il nous enseigne la programmation en Assembleur sur ColdFire (avec la larme à l'oeil lorsqu'il parle du 68000). Bit de parité, Codage BCD et port série, et Adressage indirect Registre d'adresse avec déplacement et index sont au rendez-vous.
Math pour l'info
Après trois mois de remise en jambe axée sur les fonctions usuelles (l'inégalité de Cauchy ça fait mal quand t'as pas fait de Math depuis une douzaine d'années), on attaque enfin les maths pour l'info : algèbre de Boole, analyse combinatoire...
Le prof nous fait aussi le cours "Graphes et algorithmes"
Réseau
Après un première partie très théorique (Modèle OSI, X-25, ATM, RNIS, ADSL...), on a fait un gros travail sur Ethernet avant d'entamer TCP/IP. Le prof est sans concession. Ses cours sont très pointus (il a par exemple détaillé le calcul d'un CRC. Ce qui n'est pas au programme, mais qui ma fois est bien utile).
Au niveau TP, il ne néglige rien non plus. Il nous à par exemple appris à monter un câble réseau. Ce genre de petit détails, j'aime bien.
Base de donnée
Je cite le prof (a peu près) : "Oracle, c'est comme Windows, si tu développe un truc avec PostgreSQL et que ça marche pas, on te reprochera de ne pas avoir choisis Oracle,tandis que si ça ne marche pas avec Oracle, c'est la fatalité ".
Au programme : Modèle Entité Association, Modèle relationnel et SQL.
Structure de Données
Cours théorique. Complexité des algorithmes, tris et parcours en tout genre, arbres et pointeurs.
Moralité
Je ne sais pas quel sera mon avenir d'informaticien, et je m'en fout. Aujourd'hui, je m'éclate, chaque jour, en cours, le soir en bossant chez moi... Le projet de fin d'année (à faire à deux) est un logiciel d'acquisition (usb), stockage (base de donnée) et manipulation de photo. Je me suis fixé un défit, implémenter l'export sur DVD (bon, je sais que je n'aurais pas le temps...). Ça fait en tout cas bien longtemps, que vie familiale mis à part, je n'avais pas été aussi heureux.
Seconde Partie
Lorsqu'on doit administrer et gérer, un centre de profit, on se retrouve en général en face de Deux types de logiciels :
Les Progiciel et autres Applications maisons, qui enveloppent, les bases de données. Leur utilisation est directive, leurs possibilités sont limités
à ce qui a été prévu. On saisit et accède à des données via des interfaces rigides.
La suite bureautique. Logiciel passe partout, dont l'usage n'est que très faiblement déterminé. Pour faire un affichette Word ou Powerpoint. Pour faire
des étiquettes Word ou Excel ? Sans parler des mini bases de données sous Excel.
L'unité manipulable est le fichier, qu'il faut gérer, retrouver afin d'en extraire de préciseuses informations.
A l'usage, on se rends compte que l'alliances progiciels / suites bureautiques ne permet pas une efficacité maximale. Recopiage sans fin, recherches infinies, bidouillages innommables, sont souvent le lot quotidien des utilisateurs. Trop de rigidité, d'un côté, trop de souplesse de l'autre, peu de communication entre les deux ne permettent pas une gestion correcte des cas particuliers. Or si on regarde en détail, pour beaucoup d'entreprises, et surtout pour les TPE/PME tout est cas particulier. Combien de fois, ai-je édité une lettre de relance avec tel progiciel, pour que la base sache que la relance à été faite, puis retapé un courrier correspondant exactement à la situation et à l'importance du client. Combien de fois ai-je du gruger Sage ou Harmonie, pour faire passer un truc un peu original. Conbiens de fois ai-je du pour préparer un budget retaper des centaines de chiffres qui pour une raison obscur ne sortent qu'a l'impression, mais pas à l'écran. On se rends compte assez vite que tout cela vous éloigne rapidement de la gestion au centime et de la démarche zéro papier que votre PDG ne manque pas de vous chanter à chaque fin d'année.
Pour cet ensemble de raison, mais aussi parceque je crois qu'une des force du Libre c'est de pouvoir offrir à terme des solutions extrêmement souples et personnalisé, à des prix abordables. Je souhaite étudier la possibilité du développement de progiciels autour de OpenOffice, afin de pouvoir en exploiter la richesse et la souplesse d'utilisation, dans un contexte strict de validation et de gestion des données. Je pense que la version 2, avec une API qui s'affine et un vrai module de Gestion de données , a une maturité acceptable pour imaginer cela.
Je ne suis pas encore fixé sur les modalités d'un tel projet. Toutefois, je pense que la réalisation, d'un premier cas, devrais permettre de déterminer, un méthode, pour mener à bien ce type de projets. Je pense évidement à une application de gestion/administration dédiée à la restauration. Parceque je connais bien ce secteur, mais je ne suis pas figé.
Dans le cadre de ce projet. Afin de pouvoir le mettre en route, et même si je sais que c'est pas lolix ici, je recherche une entreprise de la région Toulousaine (je suis sur Albi) pouvant m'accueillir en stage du 15 mai à fin juin. Mon cv c'est là : http://perso.wanadoo.fr/d-jo/CV_de_Joris_Dedieu.pdf(...)
Conclusion
J'espère que la lecture de ce journal, si elle ne vous apporte calme et sérénité, vous fera passer un moment sympathique
Joris
Journal Ma vie, mon oeuvre ;-)
12
fév.
2005
# Merci
Posté par Maxime (site web personnel) . Évalué à 7.
Merci pour ta joie :)
Allez bonne chance à toi.
PS: tiens, je suis de Gaillac mais interne sur Albi (Rascol) :) Peut etre qu'on c'est déjà croisé ;)
# Mon expérience personnelle
Posté par Mr Kapouik (site web personnel) . Évalué à 3.
Après j'ai intégré une formation pour adulte tout comme toi au Greta.
Maintenant je prépare un bac pro MRIM ou j'y fais énormément de réseau plus les matière général. On bosse sur les communication, les réseau microsoft et unix ainsi que sur les différent protocol en usage.
Le niveau est assez élevé car on s'entraine sur des exercices de bts deuxième année ainsi que sur les questionnaire proposés par cisco pour le ccna.
Dans ma formation, il y a des anciens maçons, des gens venant de l'hôtelerie, etc...
Et on s'éclate tous la dedans.
Je connais le genre de problème que tu peux rencontrer dans ce genre de formation et je te souhaite bonne chance pour l'avenir.
ps : moi j'ai déjà trouver un stage où je bosse sur des serveurs red hat et je prépare une migration vers debian :-)
# Base de données ... relationnelles (soyons précis)
Posté par Narmer . Évalué à 6.
Tout d'abord je dirai qu'il y a plusieurs données !! ;) :p
Plus sérieusement, je trouve dommage qu'aujourd'hui on appelle un cours base de données et qu'on ne fasse que du relationnel !! A mon époque dans mon cours de base de données, en préambule on présentait les differents types de bases de données (Hierarchique, Fichiers, Relationnelles, Relationnelles étendu, et enfin Objets!) . Et par la suite, on a fait des focus sur le relationnel avec Oracle et sur l'objet avec O2 (oql).
Maintenant qu'on ne me dise pas qu'il n'y a pas d'implementation de SGBDOO :
- Ozone : http://www.ozone-db.org(...) open-source et libre.
- DB4O : http://www.db4o.com.(...) licence libre et commerciale
- EsiObjects : http://esiobjects.sourceforge.net(...) libre opensource. Il existe un gateway java (http://www.esitechnology.com/library/downloads/esiobjects/whatIsThe(...)) et depuis l'ouverture du code un projet d'IDE client sous linux en complément de celui qui existe déja sous windows (http://geode.sourceforge.net(...))
- Caché projet commerciale mais gratuit pour projets non commerciaux (donc universitaire) http://www.intersystems.com/cache/index.html(...) est une base de donnée orientée objet.
- etc ...
Donc ça existe !
Maintenant je fais cette critique parce que je trouve dommage qu'en entreprise comme ailleurs on s'encroute encore a faire du relationnel alors qu'on fait un langage objet : ajouter un nouveau paradigme SQL+PL/SQL(ou autres) juste pour gérer la persistence alors qu'on programme en java , je trouve ça vraiment dommage.
Dans ma boite, j'ai eu une requète de type récursive à faire : du type deux tables, Person (id , firstname, lastname) et PersonHierachy (parent_id , child_id). Et bien en SQL c'est pas possible en une requète d'avoir l'ensemble des ids des personnes hierachiquement en dessous d'une personne sans passer par un subterfuge. En objet avec le couplage donnée/traitement, le langage OQL intégrant les methodes des objets on traite l'ensemble des problematiques du relationnel plus d'autres comme le hierarchique ...
A mon avis nous perdons notre temps avec du relationnel, les outils comme hibernate et autres joyeusetés. Je sais y a l'existant toussa ... mais pour des projets qui parte from scratch pour un projet java je trouve ça débile de mettre dans l'architecture une base de données relationnelle ! que ce soit mysql, postgres ou bien oracle ...
les gens ne sont pas prêt pour le tout objet !
--
l'integriste objet :)
[^] # Re: Base de données ... relationnelles (soyons précis)
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
- Ça ne résoud pas toujours tous les problèmes quand même.
- Ce n'est pas toujours aussi performant que le relationnel (surtout d'un point de vue ensembliste)
- Le relationnel, ça suffit dans la majeure partie des cas.
Et surtout, si j'ai bien compris, (corrigez moi si je me trompe), c'est trés dépendant d'un langage précis en général (à cause du mapping). Et ça je pense que c'est ce qui rebute les entreprises à passer aux bases de données objets. Avec Ozone par exemple, on ne peut l'utiliser qu'avec du Java. Bon ok. Mais une entreprise n'a pas forcément QUE des applis en java. Quid du site en PHP ? de l'appli en VB du service truc ? ou en python du service machin ? Quand bien même elle accepte de tout passer en Java , il y a forcément une période de transition (plus ou moins longue, selon le nombre d'appli à réécrire), qui ne doit pas être du tout évidente à mettre en place.
Faut il une réplication des données entre le vieux SGBDR et le nouveau SGBDOO ? Y a t-il ce qu'il faut pour faire un "pont" entre les appels SGDBR vers le SGBDOO ? etc...
Le gros avantage des bases de données relationnelles, c'est que c'est accessible par la majeure partie des langages (objets et non objets). Et c'est pour cela que ça reste encore trés ancré dans les entreprises. Les coùt induits d'une migration vers un SGBDOO sont à mon avis beaucoup trop important pour qu'une entreprise face le pas. Ou alors cela sera adopté pour un type d'application précis. Et donc pour le reste, un SGBDR sera toujours nécéssaire.
Bref, à première vu, avec quelques essais, le SGBDOO est trés alléchant. Mais il semble y avoir tout un tas de problèmes derrière qui ne sont pas tout à fait négligeables.
Pendant longtemps, et sûrement encore aujourd'hui, les SGBDOOs ont été une techno réservées aux geeks. J'entend par là que sur le papier, c'est joli, c'est un sujet passionnant pour les chercheurs, ça fait des années qu'on nous loue les grands avantages des SGBDOOs, mais sans vraiment avoir résolu tout les gros problèmes.
Et donc pour les entreprises, j'imagine bien que cela n'apporte pas encore suffisement d'avancées spéctaculaires pour leur système d'information, rien qui ne vaille le cout de migrer.
Ce que je veux dire, est que, ok, pour le développeur, c'est jouissif, en 3 lignes il fait des choses merveilleuses, mais si elles prennent 3 fois plus de temps qu'avec un SGBDR (j'éxagère sûrement, mais l'idée est là), associé à un cout enorme de migration, où est l'avantage pour le système d'information de l'entreprise ? Où est son intérêt dans cette histoire ? (sans parler qu'actuellement, cela la rend prisonnière d'une techno comme Java par ex)
Les vraies réponses à ces dernières questions permettraient certainement de comprendre pourquoi les SGBDOOs sont encore des "niches" technologiques.
[^] # Re: Base de données ... relationnelles (soyons précis)
Posté par Narmer . Évalué à 3.
Exemples ?
Je dirais simplement : SQL est un sous-ensemble de OQL. Je rajoute aussi que SQL est non procédural, il n'a pas été conçu comme un langage applicatif. Tu es toujours dans le paradigme relationnel/procédural. Si tes objets sont bien conçus tu résouds toutes tes problématiques. Avec SQL et le modele entité relation, ta logique applicative est éclatée sur parfois 3 niveaux (serveur d'appli (java, C#, C++, Smaltalk), SGBDR (SQL), SGBDR (Proc stock PL/SQL) ). Ce qui multiplie par autant la complexité et le nombre d'experts qu'il faut pour un seul projet :-/ . OQL te permet d'appeler directement les méthodes de tes objets => la logique applicative est défini une fois pour toute et à un seul endroit ! A quoi ça te sert de prendre un Rational Rose, Together, Poseidon UML ou encore JUDE, si c'est pour développer par la suite du SQL et du trigger !
Dans le cas que j'enonçais dans mon post, le relationnel est largué !
Je ne suis pas convaincu par tes 3 premiers arguments.
Déja, je ne parlais que des langages objets (smalltalk, java,c++, C# ? ) pour chacun de ces langages il existe une base de données objets. Et si tu aimes le php des projets comme HessianPHP (http://hessianphp.sourceforge.net(...)) te permettent d'attaquer des serveurs d'applications C# et Java. D'ailleurs je te signale que PHP se met lui aussi au tout objet et le clame haut et fort. (troll à part je ne considère pas php comme un langage pour faire des projets lourds) .Pour python il existe un serveur d'application entièrement objet Plone ou Zope ?. Et puis pour VB ... j'avais dit de vrais langages ptdr! Sans blague, je connais pas bien ce monde là mais un projet comme db4o te permet d'attaquer leur SGBDOO avec du .net, alors après je sais pas les versions etc ...
Après pour ce qui est de l'implantation du relationnel en entreprise, je sais très bien, il est pas là le problème, à la base on parlait des cours dispensés en base de données, d'ailleurs j'ai évoqué l'existant dans mon post. Et puis j'ai pas parlé de migration, je sais que c'est complexe moi je parle des nouveaux projets dans les nouvelles archis.
Selon toi pourquoi des projets comme hibernate voient le jour, c'est pour traiter de l'existant justement et ne faire que de l'objet en utilisant un Oracle juste comme un service de persistence. Maintenant pour ce qui est "d'être prisonnier d'une techno comme java", soit pragmatique tu penses qu'un DSI va choisir 15 technos pour son SI à partir d'un moment tu dois choisir : je ne connais pas beaucoup de boites qui font tourner et du J2EE et du .NET et du php. De plus ton exemple d'emprisonnement technologique de Java est très mal choisi car avec Java je fait des applications sur toutes les plateformes et il existe des interface vers d'autres langages (JNI) sur toutes ces plateformes. Par contre si tu choisis microsoft là tu peux parler d'emprisonnement car tu es obligé et contraint de rester sur cette plateforme. À mon sens les SGBDOO ne sont plus une niche technologique.
Pour finir, je préfère que le consultant que je paie 600 euros la journée fasse ma fonctionnalité en 3 lignes plutot que : 1 - modifier le java , 2 - modifier le SQL (+index + types + contraintes), 3 - modifier les proc/stok en PL/SQL. Non seulement il coute plus chèr car il doit connaitre 3 technos et en plus à périmètre constant il va prendre plus de temps :-/ , je préfère le tout objet ...
Maintenant je ne me penche pas vers les migrations. Je m'oriente vers les nouveaux projets. Le relationnel j'en ai vraiment marre ...
[^] # Re: Base de données ... relationnelles (soyons précis)
Posté par applex . Évalué à 3.
Y a-til des benchs (et pas sur des tables de milliers d'enregistrements mais plutot sur des centaines de milliers voire millions ) ?
Cela m'interesserait pour un projet dans ma boîte mais je m'y suis jamais frotté à ses bases objets.
[^] # Get the facts !
Posté par Narmer . Évalué à 2.
Depuis http://www.objectivity.com/Products/ProductsDownload.shtml?source=b(...) il y a un document pdf RelationalWall.pdf retraçant les avantages de Objectivity/DB (SGBDOO) en particulier http://www.objectivity.com/Misc/docs/RelationalWall.pdf(...) avec pleins d'exemples de cas réels et de chiffres.
2 - Ensembles d'articles faisant le tour de la problématique SGBDOO
Sur cet autre site http://www.service-architecture.com/object-oriented-databases/artic(...) un ensemble d'articles liés aux SGBDO. Les sections qui t'interessent sont notemment
->When an object database should be used
--> Business need
--> High performance
--> Complex data
--> One model to reduce development and maintenance costs
Et aussi les mythes démystifiés, avec en prime des cas d'etudes dont Air France.
->ODBMS myths
-->Myth: ODBMSs have a steep learning curve
-->Myth: ODBMSs are slow
-->Myth: ODBMS do not support queries
---->Stonebraker's DBMS Matrix (bien tout lire et voir le lien "Errors in Stonebraker's DBMS Matrix")
-->Myth: ODBMS products do not scale
---->Air France
---->Stanford Linear Accelerator (SLAC)
----->Real-Time Event Engine
3 - Ma conclusion
Il existe en plus des SGBDO que j'ai mentionné d'autres SGBDO et ceux dans pratiquement tous les langages.
http://directory.google.com/Top/Computers/Software/Databases/Object(...)
http://directory.google.com/Top/Computers/Programming/Languages/Jav(...)
Encore une fois à périmètre constant, je trouve qu'une application objet (utilisant un langage objet java, C#, C++, etc ...) utilisant une base de données relationnelle se freien considérablement pour toutes les raisons évoquées plus haut.
PS : j'espère que tu comprends l'anglais !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.