Accueil > Citations > Citations sur le sérialiser

Citations sur le sérialiser

Il y a 21 citations sur le sérialiser.

• Depuis le 9 février, les fabricants de médicaments ont l'obligation de sérialiser les boîtes. Un système anticontrefaçon coûteux pour les petits laboratoires, qui n'est pas encore opérationnel dans les pharmacies.

• Pour sérialiser et agréger sa production, Skyepharma s’est tourné vers les machines du groupe Marchesini et la solution logicielle de Sea Vision. Ces deux entités italiennes se sont rapprochées en janvier[…]

• Le numérique facilite également l’intervention des pouvoirs publics dans le domaine médical et pharmaceutique. Par exemple, afin de renforcer les mesures de sécurité concernant le trafic de médicaments au sein de l’Union Européenne, une directive oblige les laboratoires pharmaceutiques, à partir de cette année 2019, à sérialiser chaque boîte de médicament. Un moyen efficace d’allier numérique et lutte contre la fraude.

• Astreignons-nous donc à créer une méthode permettant de sérialiser un objet de type Personne qui va nous servir à nouveau pour la suite. C'est curieusement un peu plus difficile qu'on ne pourrait le croire de prime abord (il faut notamment tenir compte du fait que certains attributs ne sont peut-être pas définis).

• Pour assurer la communication entre modules, la Bytecode Alliance développe diverses interfaces. Objectif : permettre la copie de données sans les sérialiser et les désérialiser. Y compris pour deux modules compilés dans différents langages.

• Pour partager des données entre machines ou pour sauvegarder et charger les parties de Squadron 42; les développeurs ont dû réfléchir à la manière de sérialiser les données. Ceci a des conséquences importantes sur le server meshing (voir plus bas)

• Les systèmes préemptifs demandent l'utilisation de lock afin d'éviter les problèmes posés par un accès concurrent à une même ressource partagée. On peut distinguer deux méthodes équivalentes, mais ayant des sémantiques différentes, permettant de sérialiser les accès à une ressource. La première déjà évoquée est le lock qui permet (en l'associant à une donnée) de s'assurer qu'il n'y aura pas d'accès concurrent à cette donnée partagée. La procédure est assez simple :

• JMSSerializer est un composant qui permet de sérialiser un objet en différents formats au moyen d'annotations. Un usage fréquent est la transformation de vos entités en JSON pour la réalisation d'API REST.

• Le logement étudiant est une des pistes pour sérialiser les constructions et attirer les investisseurs. D’ailleurs au mois de mai Eloa a livré quatre appartements étudiants à Vendôme dans le Loir-et-Cher et des discussions sont en cours avec des institutionnels pour une dizaine supplémentaire. La commande de deux maisons individuelles est aussi en bonne voie. Eloa démarche également les communes pour leur proposer des logements sociaux sur ce modèle. Les patrons de la société pornichétine espèrent développer leur activité, pour d’ici trois ans construire jusqu’à une quarantaine d’habitations par an.

• "Navarro a été la première série récurrente de TF1, qui faisait jusque-là des téléfilms unitaires de 90 minutes. Ils ont décidé de "sérialiser", en s'inspirant de la série américaine Kojak, et Navarro est né. Mais ils ont gardé leur format habituel de 90 minutes, ce qui est long pour un épisode. ll a donc fallu créer des histoires parallèles, d'où les mulets" (les acolytes), a raconté Takis Candilis mercredi devant l'AJM (Association des journalistes médias).

• Il faudra lire et comprendre chaque fichier des entités, en extraire l’attribut qui intéresse (l’idéal étant de n’en avoir qu’un par index secondaire). Ce n’est pas encore l’heure du tri s’il y a lieu : il suffit de faire notre index secondaire avec la valeur sélectionnée, ici un attribut de l’entité (sous format « texte », c’est-à-dire sérialiser si besoin), et l’ID. Le nom de cet index secondaire sera composé du nom de l’attribut, du type de l’entité ainsi que de l’extension « entites ». Par exemple : valeurNumerique.test.entites.

• Une première idée (naïve) consisterait à sérialiser en JSON le contenu des fichiers en question et de les stocker dans le Local Storage. Cependant, outre la complexité d'une telle technique, l'espace du Local Storage est limité à cinq Mo et est déjà utilisé par la base de données.

• Certes, mais en même temps, exposer dans ta sérialisation le nom du membre (côté programme) est vraisemblablement une mauvaise idée. Outre que suivant le type de sérialisation voulue, celui ci peut nécessiter une transformation (par exemple, pour sérialiser vers xml, on aura tendance à transformer les « _ » en « - » ). Donc devoir le définir deux fois mais pas à proprement parler un soucis, en tout cas pas majeur.

• Pas vraiment ça qu'il voulait dire je pense Du S4 au S5 en passant par les Note ou ces nouveaux là, ils ont tous la même gueule de face, et presque la même de dos J'veux bien qu'il faut faire des économies et sérialiser les pièces nanana, mais à ce point quand même

• Un des cas d'utilisation classiques de cette class Storage est de stocker les données au format JSON, ce qui nous permettra de sérialiser et désérialiser celles-ci de façon très performante (si les navigateurs savent faire très rapidement quelque chose, c'est bien la lecture/écriture en JSON…). Vous pouvez à cette fin vous reporter aux bibliothèques JSON intégrées à GWT.

• Je suis curieux de savoir ce que tu appelles « bien crade ». À comparer avec sérialiser automatiquement une classe « s$ » qui est un nom de classe tout à fait valide (au moins en c++ et java) mais un nom de nœud xml tout à fait invalide… Et de la nécessité des [CDATA] suivant le contenu, ce qui peut te péter pas mal d’outils qui n’en tiendront pas compte parce que ça te rajoute un nœud supplémentaire dans ton arbre dom…

• En tirant profit de la granularité de CouchDB, nous épargnons d'innombrables cycles CPU qui auraient été nécessaires pour sérialiser les graphes d'objets provenant de SQL, pour les convertir en objets du domaine et en exploitant ces objets pour effectuer une validation au niveau applicatif.

• S’il est très profond, mais pas très large, l’accès aux données ne semble pas optimal ; mieux vaudrait peut-être utiliser une autre structure (table de hachage ?). S’il est très profond et très large, donc très volumineux, est-ce que les capacités mémoires actuelles permettent de l’avoir entièrement en mémoire (la taille augmente exponentiellement avec la profondeur quand même), ou faut-il le manipuler directement sur disque/SSD ? Dans le deuxième cas, la question n’est pas de le sérialiser, mais d’avoir un format permettant un accès efficace sur disque/SSD.

• De mon ressentis, c'est que tu n'es pas au bon niveau. Pour toi, faire de l'overengineering, c'est utiliser des concepts de base d'un langage (héritage, interface). Non, c'est pas ça. L'overengineering, c'est de te dire : tiens, j'ai besoin d'une classe qui va gérer mes objets, en me permettant de les sérialiser/désérialiser vers/depuis un fichier, et comme j'en aurais sans doute besoin dans le futur, que je puisse lire/écrire directement depuis/vers un fichier compressé (un zip, un 7z, un rar, un bz2, un gz, un xz, pardon à ceux que j'ai oublié) tout en gérant un historique comme git pourrait le faire pour pouvoir revenir en arrière.

• lightning permet de sérialiser les protocoles vidéos. En gros à adapter toutes sortes de sorties vidéo présentes ou futures via un adapteur du connecteur. A ma connaissance, ce n'est pas une flexibilité qu'offre usb 3.1