RMF est plus proche d'un DOORS dans l'esprit que d'un Reqtify (qui effectivement ne fait que de la tracabilité et qui part des documents qui contiennent les "choses" à tracer alors qu'un DOORS et RMF sont la source des "choses" à tracer), mais les liens de traça peuvent être directement exprimés dans RMF.
Comme derrière c'est de l'Eclipse EMF y a tous les outils dispo ensuite pour générer de la doc, modifier programmatiquement la base d'exigences, l'intégrer avec des outils tiers pour faire de la vérif, de la trace…
Vu le volume d'opérations nécessaires pour une assistance gravitationnelle et que le fait de la rater met fin à la mission, je pense qu'ils y ont pensé et qu'une partie des 5% qui restent seront dans le centre de controle de Juno ;-)
Pour le moment c'est une synchro seulement serveur vers android, mais on travaille sur la synchro dans l'autre sens
(on prend des gants car c'est plus dangereux, je suis pas sûr qu'effacer toutes les entrées sur le serveur suite à un bug soit bien vu ;-) )
Et bien entendu si vous avez 5min pour nous aider, rendez-vous sur GitHub !
J'ai pas bien compris la relation entre les "moteurs" et le fait qu'il n'y a plus de gravité... pour pallier au problème que tu évoques (un fluide n'a aucune envie de sortir des réservoirs car les forces de capilarité sont prépondérentes dans l'espace) on pressurise les réservoirs avec un gaz inerte, tout le monde fait ça. C'est surement pas le problème ici...
Visiblement ils n'ont pas reçu de télémétrie lors de son dernier passage sur Baikonour, ça sent pas super bon, le problème dans l'espace et que pour pouvoir patcher le soft il faut déjà qu'un grand nombre de conditions complexes soient réunies (qu'on ai de la puissance soit par les batteries soit par les panneaux, qu'on ai pas trop froid ou trop chaud, qu'on soit en position pour communiquer avec le sol, que le soft boot correctement et plante pas immédiatement...), pas de télémetrie, surement pas de télécommandes, une seule visibilité par jour, cette fois c'est vraiment mal barré...
Mais comme je le dis plus bas, les russes n'ont pas cet expérience...
Tout le monde qui "s'amuse" à envoyer des engins dans l'espace a l'expérience de modification en vol des logiciels, les Russes autant que les autres... si la modification du logiciel de vol ou un changement dans les procédures peuvent sauver la mission je n'ai aucun doute sur leur capacité à mettre en oeuvre ces modifications...
Il semble que "l'espèce de jet-pack" à base d'étage fregat qui est attaché à la sonde pour lui fournir la poussée nécessaire n'a pas été déclenché par le logiciel de vol, c'est pas forcément un problème logiciel, mais peut-être un "glitch" matériel (par exemple sur le senseur stellaire) qui a conduit à ne pas remplir les conditions de déclenchement de la poussée. Si c'est le cas, ils pourront peut-être pousser par des commandes sol même si leurs fenetres de visibilité sont très réduites en raison d'un réseau d'antennes visiblement très réduit... peut-être que la NASA ou l'ESA pourront leur donner un coup de main pour améliorer cette couverture...
Wait and see, le spatial n'est pas toujours une science exacte...
Si je ne peux qu'être d'accord sur l'état actuel de stabilité de Papyrus ( ceux qui ont déjà perdu des modèles d'un jour sur l'autre comprennent ce que je veux dire ;-) ), je suis pas sûr que l'objectif final de Papyrus soit de rester un modeleur "experimental" (qqn de l'équipe de dev peut peut-être confirmer). Il faut quand même se souvenir qu'ils sont encore en incubation dans le projet modeling donc il faut leur laisser le temps pour stabiliser le produit.
En tout cas il y a pas mal de fonctionnalités super-sympa (genre les éditeurs textuels pour le typage par exemple), c'est un projet Eclipse, c'est d'ailleurs le seul projet eclipse de modeleur UML (à moins que Modelio soit un jour un projet Eclipse), des industriels le regarde de près (Y a qu'a voir Topcased qui est à l'origine issu d'un consortium de gros industriels qui a décidé de faire de Papyrus son modeleur UML)...
Enfin, on peut quand même se demander si Modelio n'est pas passé open-source à cause de Papyrus justement (en mettant d'ailleurs en open source que la partie qui correspond à Papyrus), de même pour la réorganisation de l'offre UML d'IBM (il parrait d'ailleurs que la partie modeleur est visiblement à un prix "agressif").
Je me demande aussi l'impact de la mise en veille en RAM. Dans ce mode la batterie se décharge très lentement jusqu'à épuisement ce qui n'est peut-être pas très bon.
Le comportement de Windows est de redémarrer le PC tout seul au bout d'un moment pour le mettre en veille sur disque qui ne consomme plus... à ma connaissance c'est pas fait sous Linux (du moins je sais pas l'activer) mais ça pourrait peut-être avoir un impact sur la durée de vie...
Tu peux utiliser un modeleur Eclipse/UML2 comme Topcased ou Papyrus avec un générateur de code basé sur Acceleo. Selon ton application et le temps que tu souhaites passer sur ton atelier de dev, tu pourras générer bien plus que de simple squelettes de code (par exemple du PHP/Smarty, du JEE, ...).
C'est idiot de n'utiliser UML que pour faire de jolis dessins (autant utiliser Inkscape ou OpenOffice Draw ça sera plus beau), si le modèle est (un peu) formalisé et propre, tu peux générer une grande partie du code de ton appli automatiquement...
Justement, en quoi cela va poser des problèmes au serveur d'application de changer le client puisque le serveur, lui, continuera à travailler de la même manière ?
Quand on se penche sur le fonctionnement de librairies comme Google Web Toolkit (utilisé par les appli google), on s'aperçoit qu'il n'y a aucune séparation entre la partie client qui tourne sur le serveur et celle qui tourne sur le client (tout est généré à partir d'une description unique et est complètement spécifique à une interface client particulière). Quand on parle de déployer une nouvelle version de l'appli, on déploie la partie serveur et client web en même temps sans se préoccuper d'une quelconque préservation du protocole et des interfaces client/serveur.
Dans ce style d'architecture (d'un autre coté je trouve ça super pratique et élégant), il n'est pas possible de redévelopper son client dans son coin (enfin de façon simple, maintenable, ...). Je souhaite bien du courage à celui qui voudrait pondre une nouvelle IHM à gmail...
Le problème doit être abordé dans sa globalité, une application libre c'est la partie client + la partie serveur.
Sinon, ils ont les sources, quand a l'independance technologique, vu qu'ils n'ont tout simplement pas les moyens de maintenir un OS eux-meme, c'est un faux probleme(eh oui, c'est tres complexe et cher a faire, la SSII du coin, meme une grosse n'en a pas les moyens).
Comment dire... des entreprises comme Thales n'ont pas vraiment que les moyens des grosses SSII... ;-)
Beaucoup de systèmes critiques utilisent des OS propriétaires (j'imagine que Thales en a plusieurs en interne, y en a un qui tourne sur l'avionique A380 par exemple) ou même pas d'OS du tout (est-ce qu'un séquenceur est encore un OS ?)
C'est un problème de qualif et surtout de maitrise du comportement de l'OS (pour une illustration de ceci voir le bug de Pathfinder le rover martien, la NASA a utilisé VxWorks sans vraiment maitriser le comportement sur les sémaphores ce qui a conduit au bug...)
Du coup quand je l'ouvre la page principale je tombe sur des photos de femmes à poil (même si c'est des oeuvres d'art) et sur mein kampf... ça partait pourtant d'une bonne idée, mais c'était sans compter sur les internautes ;-)
Tu crois vraiment que beaucoup d'entreprises (d'une taille supérieure à une start-up) laissent les ports sortants de leur réseau ouverts (tu travailles peut-être sur Chrome chez Google avec l'install qui prenait pas en compte les proxy ;-) )?
C'est pas pour cela qu'on a pas les moyens d'accéder aux outils de développement "normaux"...
Peut-être que cette personne est dans une entreprise avec un proxy http/https comme seule porte de sortie et que oui dans ce cas utiliser CVS pour récupérer un snapshot des sources c'est simplement pas possible (vive SVN pour ça au passage)
Je suis pas sur que la manœuvre soit si ordinaire que cela. D'après quelques articles, l'architecture de Hubble (comme toute celle des satellites anciens) est partagée quasi physiquement en deux, une partie nominale (voie A) qui était en fonctionnement jusqu'à aujourd'hui et une partie redondante (voie B) en sommeil depuis 18ans. Passer sur le formateur de donnée scientifique redondant semble impliquer de passer tout un ensemble de composants sur les redondants (dont le logiciel central et son CPU qui gère la survie de la plateforme et la communication avec le centre de controle).
Donc ce qu'ils ont fait c'est de basculer toute l'avionique de la partie nominale à la partie redondante et ça c'est pas anodin (imaginons qu'un des composants soit défaillant, ça pourrait transformer le satellite en vulgaire caillou de l'espace). D'où le temps passé a imaginer tous les scénarii catastrophe et les parades associées et la petite goutte de sueur du contrôleur qui a enclenché la procédure ;-)
La plus part des satellites actuels ont une architecture qui permet de reconfigurer une boite sans reconfigurer tout le satellite (tout les chemins sont croisés, un calculateur nominal peut parler avec un équipement redondant).
Je ne connais que ce qu'on veut bien nous dire sur Hubble ;-) donc tout ça est à prendre avec des pincettes et au conditionnel....
Attention à la différence entre la version normale et la version 8Gb, si ils ont viré le slot SD et le cache de l'appareil photo c'était pour loger une batterie plus grosse car le N95 initial avait une autonomie assez limitée. C'est un critère à prendre en compte pour choisir une version normale ou 8Gb...
Le code généré est relativement simple, et donc ne présente pas réellement d'intérêt. Il ne gérait pas très bien les modifs de schémas.
C'est là qu'intervient Acceleo et les autres (JET, openArchitectureWare, MOFscript, ...), comme les outils fournis en standard avec les modeleurs UML visent la généricité, ils ne peuvent pas générer grand chose (au mieux les squelettes du code) et en plus il y a de fortes chance que ça ne colle pas à tes règles métier. Pour aller plus loin, il te faut définir un profil UML ou un DSL (Domain specific language) qui est propre à ton métier (comme ceux proposés dans la news) et développer/adapter un générateur de code maison. Aujourd'hui avec des solutions comme Acceleo ça devient un jeu d'enfant et on peut faire des générations de large parties du code (celles pénibles à codé ou source d'erreur fréquentes) simplement. Par exemple refaire un générateur du style de celui de RSM est l'affaire de qq jours (et non j'ai pas d'action chez eux ;-) )
Il faut s'enlever de l'idée (pour le moment ?) qu'un modeleur UML aussi bon soit-il va te permettre de faire du MDD sorti de la boite. Mettre en place un process orienté modèle demande des développement proprio et de l'investissement (générateur de code, transformateurs de modèles, vérif sur ces modèles, ...). Sur des projets un peu gros, ça peu être très rapidement super rentable.
Je suis assez étonné que l'approche a base de modèle n'ai pas plus de succès que ça dans les grands projets libres, pourtant c'est ceux qui ont la plus grande flexibilité pour mettre en place ces solutions et pour en tirer avantage (productivité plus forte, meilleure homogénéité du code, meilleure intégration des nouveaux, ...). De même avec des frameworks comme RoR, on pourrait faire des trucs super puissants en modélisant l'appli et ensuite en générant une grande partie du code (genre le modèle de données, une partie des contrôleurs, ...)
En fin de compte, c'est assez difficile de
modéliser un cas assez technique, pas sûr que ca ait apporté une lisibilité supplémentaire.
Les graphes obtenus par des clics de souris sont longs à faire et à modifier.
Je vais être caricatural... RSM n'a pas que des qualités, loin de là, mais le problème est que RSM n'est pas un outil de dessin... Le but à la fin est d'avoir un modèle à partir duquel tu peux faire qqch générer du code, faire des analyses, produire d'autres modèle, ...). Pour faire des "dessins UML" vaut mieux prendre PowerPoint ou Dia pour faire libre tu auras un meilleur rendu plus simplement...
Finalement, en ce qui me concerne en tout cas, je pense qu'il vaut mieux que je commence le code assez tôt, même si la modélisation n'est pas encore terminée, quitte à la faire évoluer au fur et à mesure.
Dans une approche MDE c'est la transformation du modèle vers le code qui te permet de commencer à coder (même si plusieurs itérations sont possibles). Je suis d'accord que pour le moment
les outils sont assez lourds et mal foutus, mais ça s'améliore de plus en plus et le jeu en vaut carrément la chandelle !
Pour le modeleur UML libre, il y a aussi Papyrus du CEA (http://www.papyrusuml.org/) qui est à mon avis plus utilisable intensivement et operationellement que celui de Topcased. Ils seraient amenés à fusionner dans un futur plus ou moins proche, je croyait que c'était pour la 2.0, ça sera pour plus tard...
Tous les téléphones et autres périphériques Bluetooth permettent de ne pas répondre au protocole de découverte. Cette option devrait être toujours activée par les utilisateurs et désactivé seulement les 30s qui permettent de "pairer" deux périphériques une fois pour toutes ! Il n'y a alors plus de moyen (simple) de découvrir le périphérique donc de recevoir de la pub...
Je suis assez partagé, d'une part il y a quelques ajouts qui vont permettre de renforcer le fait qu'une page HTML devrait ne contenir que le contenu "sémantique" et le CSS devrait s'occuper que de la forme et de l'adaptation au média d'affichage, par exemple :
* la balise figure qui permet d'associer une légende à un élément graphique
* ou les balises sections, aside, nav qui permettent de mieux structurer le document et de signaler ce qui est le contenu et ce qui est de l'aide à la navigation ou de la décoration)
D'autre part on rajoute des balises qui elle ne pourront être rendues correctement que sur le média pour lequel la page a été conçue (qu'est qu'un moteur de recherche peut faire du contenu de canvas ? comment afficher une vidéo sur un écran de 3x3 cm ?)
Est-ce que le HTML5 est toujours dans la philo de séparer le contenu de la présentation ?
Ca montre bien que pour le moment dans le domaine du logiciel temps-réel critique la question n'est pas encore d'avoir un RTOS commercial ou un RTLinux, car souvent c'est des OS maison. Faut dire qu'on parle souvent de simples schedulers qui n'ont rien avoir avec la richesse fonctionnelle d'un Linux.
En plus connaître parfaitement son OS dans des domaines aussi critiques permet d'éviter les bêtises (cf. les bugs des rovers martiens américains... http://research.microsoft.com/~mbj/Mars_Pathfinder/Authorita(...) ;-) ), et c'est pas forcément parce qu'on a accès au code source (WindRiver diffuse son code) qu'on comprend toutes les subtilités d'un OS...
[^] # Re: excellente nouvelle
Posté par gege (site web personnel) . En réponse au journal Reqflow. Évalué à 1.
Je vais juste rajouter RMF un outil open source sous Eclipse : http://www.eclipse.org/rmf/
RMF est plus proche d'un DOORS dans l'esprit que d'un Reqtify (qui effectivement ne fait que de la tracabilité et qui part des documents qui contiennent les "choses" à tracer alors qu'un DOORS et RMF sont la source des "choses" à tracer), mais les liens de traça peuvent être directement exprimés dans RMF.
Comme derrière c'est de l'Eclipse EMF y a tous les outils dispo ensuite pour générer de la doc, modifier programmatiquement la base d'exigences, l'intégrer avec des outils tiers pour faire de la vérif, de la trace…
[^] # Re: Sonde Juno
Posté par gege (site web personnel) . En réponse au journal La NASA au ralenti :(. Évalué à 4.
Vu le volume d'opérations nécessaires pour une assistance gravitationnelle et que le fait de la rater met fin à la mission, je pense qu'ils y ont pensé et qu'une partie des 5% qui restent seront dans le centre de controle de Juno ;-)
[^] # Re: comparaison owncolud
Posté par gege (site web personnel) . En réponse à la dépêche Cozy, un cloud personnel que l'on peut héberger, bidouiller et supprimer. Évalué à 1.
Un peu de pub : CaldavSync Free Beta
Aussi dispo sur f-droid et github
Pour le moment c'est une synchro seulement serveur vers android, mais on travaille sur la synchro dans l'autre sens
(on prend des gants car c'est plus dangereux, je suis pas sûr qu'effacer toutes les entrées sur le serveur suite à un bug soit bien vu ;-) )
Et bien entendu si vous avez 5min pour nous aider, rendez-vous sur GitHub !
[^] # Re: Pour fêter ça...
Posté par gege (site web personnel) . En réponse au journal Happy birthday lady Ada. Évalué à 3.
Tant que c'est pas la RATP qui décide de crasher une rame de métro ou EDF qui décide de faire exploser une centrale ça va ;-)
[^] # Re: ingress
Posté par gege (site web personnel) . En réponse au journal Happy birthday lady Ada. Évalué à 6.
Ada et pas ADA… ADA c'est les loueurs de voiture, Ada c'est son prénom et le langage ;-)
[^] # Re: Loi de Murphy
Posté par gege (site web personnel) . En réponse au journal La sonde russe Phobos-Grunt en perdition. Évalué à 2.
J'ai pas bien compris la relation entre les "moteurs" et le fait qu'il n'y a plus de gravité... pour pallier au problème que tu évoques (un fluide n'a aucune envie de sortir des réservoirs car les forces de capilarité sont prépondérentes dans l'espace) on pressurise les réservoirs avec un gaz inerte, tout le monde fait ça. C'est surement pas le problème ici...
Visiblement ils n'ont pas reçu de télémétrie lors de son dernier passage sur Baikonour, ça sent pas super bon, le problème dans l'espace et que pour pouvoir patcher le soft il faut déjà qu'un grand nombre de conditions complexes soient réunies (qu'on ai de la puissance soit par les batteries soit par les panneaux, qu'on ai pas trop froid ou trop chaud, qu'on soit en position pour communiquer avec le sol, que le soft boot correctement et plante pas immédiatement...), pas de télémetrie, surement pas de télécommandes, une seule visibilité par jour, cette fois c'est vraiment mal barré...
[^] # Re: Loi de Murphy
Posté par gege (site web personnel) . En réponse au journal La sonde russe Phobos-Grunt en perdition. Évalué à 3.
Tout le monde qui "s'amuse" à envoyer des engins dans l'espace a l'expérience de modification en vol des logiciels, les Russes autant que les autres... si la modification du logiciel de vol ou un changement dans les procédures peuvent sauver la mission je n'ai aucun doute sur leur capacité à mettre en oeuvre ces modifications...
Il semble que "l'espèce de jet-pack" à base d'étage fregat qui est attaché à la sonde pour lui fournir la poussée nécessaire n'a pas été déclenché par le logiciel de vol, c'est pas forcément un problème logiciel, mais peut-être un "glitch" matériel (par exemple sur le senseur stellaire) qui a conduit à ne pas remplir les conditions de déclenchement de la poussée. Si c'est le cas, ils pourront peut-être pousser par des commandes sol même si leurs fenetres de visibilité sont très réduites en raison d'un réseau d'antennes visiblement très réduit... peut-être que la NASA ou l'ESA pourront leur donner un coup de main pour améliorer cette couverture...
Wait and see, le spatial n'est pas toujours une science exacte...
[^] # Re: Comparaison avec PapyrusUML?
Posté par gege (site web personnel) . En réponse à la dépêche Modelio, un AGL UML propriétaire passe en GPL. Évalué à 3.
Si je ne peux qu'être d'accord sur l'état actuel de stabilité de Papyrus ( ceux qui ont déjà perdu des modèles d'un jour sur l'autre comprennent ce que je veux dire ;-) ), je suis pas sûr que l'objectif final de Papyrus soit de rester un modeleur "experimental" (qqn de l'équipe de dev peut peut-être confirmer). Il faut quand même se souvenir qu'ils sont encore en incubation dans le projet modeling donc il faut leur laisser le temps pour stabiliser le produit.
En tout cas il y a pas mal de fonctionnalités super-sympa (genre les éditeurs textuels pour le typage par exemple), c'est un projet Eclipse, c'est d'ailleurs le seul projet eclipse de modeleur UML (à moins que Modelio soit un jour un projet Eclipse), des industriels le regarde de près (Y a qu'a voir Topcased qui est à l'origine issu d'un consortium de gros industriels qui a décidé de faire de Papyrus son modeleur UML)...
Enfin, on peut quand même se demander si Modelio n'est pas passé open-source à cause de Papyrus justement (en mettant d'ailleurs en open source que la partie qui correspond à Papyrus), de même pour la réorganisation de l'offre UML d'IBM (il parrait d'ailleurs que la partie modeleur est visiblement à un prix "agressif").
[^] # Re: Dassault Systeme
Posté par gege (site web personnel) . En réponse au journal DraftSight (TM), un logiciel de DAO sous Linux.. Évalué à 4.
Dassault Data Systems et Dassault Aviation ne partagent plus que le nom depuis pas mal de temps à ma connaissance, c'est des sociétés différentes.
# Influence du suspend to RAM sur la durée de vie de la batterie
Posté par gege (site web personnel) . En réponse au journal Préserver sa batterie de portable. Évalué à 2.
Le comportement de Windows est de redémarrer le PC tout seul au bout d'un moment pour le mettre en veille sur disque qui ne consomme plus... à ma connaissance c'est pas fait sous Linux (du moins je sais pas l'activer) mais ça pourrait peut-être avoir un impact sur la durée de vie...
# Solution basée sur Eclipse + générateur de code ?
Posté par gege (site web personnel) . En réponse au message Générateur de squelette à partir d'UML. Évalué à 1.
C'est idiot de n'utiliser UML que pour faire de jolis dessins (autant utiliser Inkscape ou OpenOffice Draw ça sera plus beau), si le modèle est (un peu) formalisé et propre, tu peux générer une grande partie du code de ton appli automatiquement...
[^] # Re: En même temps...
Posté par gege (site web personnel) . En réponse au journal RMS et le piège du Javascript. Évalué à 7.
Quand on se penche sur le fonctionnement de librairies comme Google Web Toolkit (utilisé par les appli google), on s'aperçoit qu'il n'y a aucune séparation entre la partie client qui tourne sur le serveur et celle qui tourne sur le client (tout est généré à partir d'une description unique et est complètement spécifique à une interface client particulière). Quand on parle de déployer une nouvelle version de l'appli, on déploie la partie serveur et client web en même temps sans se préoccuper d'une quelconque préservation du protocole et des interfaces client/serveur.
Dans ce style d'architecture (d'un autre coté je trouve ça super pratique et élégant), il n'est pas possible de redévelopper son client dans son coin (enfin de façon simple, maintenable, ...). Je souhaite bien du courage à celui qui voudrait pondre une nouvelle IHM à gmail...
Le problème doit être abordé dans sa globalité, une application libre c'est la partie client + la partie serveur.
[^] # Re: Critique = faut que ça marche sans bug et tout le temps
Posté par gege (site web personnel) . En réponse à la dépêche Thales met à disposition un framework à composants logiciels visant les systèmes critiques. Évalué à 5.
Sinon, ils ont les sources, quand a l'independance technologique, vu qu'ils n'ont tout simplement pas les moyens de maintenir un OS eux-meme, c'est un faux probleme(eh oui, c'est tres complexe et cher a faire, la SSII du coin, meme une grosse n'en a pas les moyens).
Comment dire... des entreprises comme Thales n'ont pas vraiment que les moyens des grosses SSII... ;-)
Beaucoup de systèmes critiques utilisent des OS propriétaires (j'imagine que Thales en a plusieurs en interne, y en a un qui tourne sur l'avionique A380 par exemple) ou même pas d'OS du tout (est-ce qu'un séquenceur est encore un OS ?)
C'est un problème de qualif et surtout de maitrise du comportement de l'OS (pour une illustration de ceci voir le bug de Pathfinder le rover martien, la NASA a utilisé VxWorks sans vraiment maitriser le comportement sur les sémaphores ce qui a conduit au bug...)
# Chef, chef, j'ai fait une bétise...
Posté par gege (site web personnel) . En réponse au journal [HS] Attention, internet peut endomager votre ordinateur. Évalué à 10.
[^] # Re: L'O.S. et le navigateur utilisé pour visiter linuxfr sont-ils connu
Posté par gege (site web personnel) . En réponse au journal Quelque statistiques sur linuxfr. Évalué à 4.
en particulier le web analyser :
http://www.linuxfr.org/stats/web.html/usage_200901.html
# Belle idée le bandeau avec les photos des recherches les plus fréquent
Posté par gege (site web personnel) . En réponse au journal Europeana.eu. Évalué à 7.
[^] # Re: Releases are available by CVS branch checkout only.
Posté par gege (site web personnel) . En réponse au journal glibc m'a tuer. Évalué à 3.
Tu crois vraiment que beaucoup d'entreprises (d'une taille supérieure à une start-up) laissent les ports sortants de leur réseau ouverts (tu travailles peut-être sur Chrome chez Google avec l'install qui prenait pas en compte les proxy ;-) )?
C'est pas pour cela qu'on a pas les moyens d'accéder aux outils de développement "normaux"...
[^] # Re: Releases are available by CVS branch checkout only.
Posté par gege (site web personnel) . En réponse au journal glibc m'a tuer. Évalué à 4.
[^] # Re: Manoeuvre ordinaire,
Posté par gege (site web personnel) . En réponse au journal Le téléscope spacial Hubble est sous windows. Évalué à 7.
Donc ce qu'ils ont fait c'est de basculer toute l'avionique de la partie nominale à la partie redondante et ça c'est pas anodin (imaginons qu'un des composants soit défaillant, ça pourrait transformer le satellite en vulgaire caillou de l'espace). D'où le temps passé a imaginer tous les scénarii catastrophe et les parades associées et la petite goutte de sueur du contrôleur qui a enclenché la procédure ;-)
La plus part des satellites actuels ont une architecture qui permet de reconfigurer une boite sans reconfigurer tout le satellite (tout les chemins sont croisés, un calculateur nominal peut parler avec un équipement redondant).
Je ne connais que ce qu'on veut bien nous dire sur Hubble ;-) donc tout ça est à prendre avec des pincettes et au conditionnel....
[^] # Re: Essaye donc....
Posté par gege (site web personnel) . En réponse au journal Linux et les telephones mobiles. Évalué à 1.
[^] # Re: Modelisation vs Code
Posté par gege (site web personnel) . En réponse à la dépêche Acceleo 2.3 compatible Eclipse Ganymede. Évalué à 6.
C'est là qu'intervient Acceleo et les autres (JET, openArchitectureWare, MOFscript, ...), comme les outils fournis en standard avec les modeleurs UML visent la généricité, ils ne peuvent pas générer grand chose (au mieux les squelettes du code) et en plus il y a de fortes chance que ça ne colle pas à tes règles métier. Pour aller plus loin, il te faut définir un profil UML ou un DSL (Domain specific language) qui est propre à ton métier (comme ceux proposés dans la news) et développer/adapter un générateur de code maison. Aujourd'hui avec des solutions comme Acceleo ça devient un jeu d'enfant et on peut faire des générations de large parties du code (celles pénibles à codé ou source d'erreur fréquentes) simplement. Par exemple refaire un générateur du style de celui de RSM est l'affaire de qq jours (et non j'ai pas d'action chez eux ;-) )
Il faut s'enlever de l'idée (pour le moment ?) qu'un modeleur UML aussi bon soit-il va te permettre de faire du MDD sorti de la boite. Mettre en place un process orienté modèle demande des développement proprio et de l'investissement (générateur de code, transformateurs de modèles, vérif sur ces modèles, ...). Sur des projets un peu gros, ça peu être très rapidement super rentable.
Je suis assez étonné que l'approche a base de modèle n'ai pas plus de succès que ça dans les grands projets libres, pourtant c'est ceux qui ont la plus grande flexibilité pour mettre en place ces solutions et pour en tirer avantage (productivité plus forte, meilleure homogénéité du code, meilleure intégration des nouveaux, ...). De même avec des frameworks comme RoR, on pourrait faire des trucs super puissants en modélisant l'appli et ensuite en générant une grande partie du code (genre le modèle de données, une partie des contrôleurs, ...)
En fin de compte, c'est assez difficile de
modéliser un cas assez technique, pas sûr que ca ait apporté une lisibilité supplémentaire.
Les graphes obtenus par des clics de souris sont longs à faire et à modifier.
Je vais être caricatural... RSM n'a pas que des qualités, loin de là, mais le problème est que RSM n'est pas un outil de dessin... Le but à la fin est d'avoir un modèle à partir duquel tu peux faire qqch générer du code, faire des analyses, produire d'autres modèle, ...). Pour faire des "dessins UML" vaut mieux prendre PowerPoint ou Dia pour faire libre tu auras un meilleur rendu plus simplement...
Finalement, en ce qui me concerne en tout cas, je pense qu'il vaut mieux que je commence le code assez tôt, même si la modélisation n'est pas encore terminée, quitte à la faire évoluer au fur et à mesure.
Dans une approche MDE c'est la transformation du modèle vers le code qui te permet de commencer à coder (même si plusieurs itérations sont possibles). Je suis d'accord que pour le moment
les outils sont assez lourds et mal foutus, mais ça s'améliore de plus en plus et le jeu en vaut carrément la chandelle !
[^] # Re: UML dans les avions ?
Posté par gege (site web personnel) . En réponse à la dépêche Topcased 2.0 est sorti. Évalué à 4.
[^] # Re: Fermer son Bluetooth
Posté par gege (site web personnel) . En réponse au journal Le bluespam. Évalué à 3.
# Et la sémantique dans tout ça ?
Posté par gege (site web personnel) . En réponse à la dépêche Le W3C met en route le premier brouillon de HTML 5. Évalué à 3.
* la balise figure qui permet d'associer une légende à un élément graphique
* ou les balises sections, aside, nav qui permettent de mieux structurer le document et de signaler ce qui est le contenu et ce qui est de l'aide à la navigation ou de la décoration)
D'autre part on rajoute des balises qui elle ne pourront être rendues correctement que sur le média pour lequel la page a été conçue (qu'est qu'un moteur de recherche peut faire du contenu de canvas ? comment afficher une vidéo sur un écran de 3x3 cm ?)
Est-ce que le HTML5 est toujours dans la philo de séparer le contenu de la présentation ?
[^] # Re: Adeos, RTAI, Xenomai
Posté par gege (site web personnel) . En réponse à la dépêche La guerre du temps réel. Évalué à 4.
En plus connaître parfaitement son OS dans des domaines aussi critiques permet d'éviter les bêtises (cf. les bugs des rovers martiens américains... http://research.microsoft.com/~mbj/Mars_Pathfinder/Authorita(...) ;-) ), et c'est pas forcément parce qu'on a accès au code source (WindRiver diffuse son code) qu'on comprend toutes les subtilités d'un OS...