Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
Notifications
< Retour vers Bidouille & Développement Informatique
Agrandir
Bidouille & Développement Informatique
Les Mains dans le Cambouis
Bidouille & Développement Informatique
Actu 1 1
Articles
Médias 33 33
Tutoriels
Forums 326 326

Le pub des programmeurs

  • 1 927 réponses
  • 117 participants
  • 123 988 vues
  • 130 followers
Sujet de la discussion Le pub des programmeurs
Salut :coucou: y a des programeurs sur AF si oui vous bossez sous quoi ?
Afficher le sujet de la discussion
1691
La nouvelle version 5.1 de JUCE contient maintenant un module DSP, et c'est bibi qui en a codé une grosse partie :bravo:

https://www.juce.com/releases/juce-5-1

(bon tout a été réécrit par l'équipe de JUCE aussi pour être C++14 compliant, et pour suivre leurs standards de codage, donc il doit pas rester grand chose de mon code original :mdr: )

Développeur de Musical Entropy | Nouveau plug-in freeware, The Great Escape | Soundcloud

1692
Bah bravo tout de même ! :bravo:

Formateur en techniques sonores ; électronicien ; auteur @ sonelec-musique.com

1693
Pendant qu'on écrit des conneries sur Audiofanzine, il y en a quand même qui font des choses utiles. La France n'est pas aussi déconfite que Gattaz veut bien le dire ! :bravo:

C'est bien l'homme qui cause le dérèglement climatique - AudioFanzine sans PUBlicité

1694
Tout ça pour pas un balle. Juste pour la gloire du lol et les crypto-communistes qui croient encore à l'open source. Ca ne fait pas partie du monde de Gattaz, ça.

We're born naked, wet and hungry. Then things get worse.
http://soundcloud.com/jay-f-2

1695
C'est open source mais y a des licences commerciales quand même :-D

Les gars :bravo:

Développeur de Musical Entropy | Nouveau plug-in freeware, The Great Escape | Soundcloud

[ Dernière édition du message le 29/07/2017 à 16:21:10 ]

1696
Y a toutes les vidéos de la conférence Audio Developer organisée par l'équipe de JUCE sur Youtube :bravo:

https://www.youtube.com/channel/UCaF6fKdDrSmPDmiZcl9KLnQ

Développeur de Musical Entropy | Nouveau plug-in freeware, The Great Escape | Soundcloud

1697
Chouette article du Monde.fr adapté de The Atlantic :
http://internetactu.blog.lemonde.fr/2017/11/25/reinventer-la-programmation/
https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/

Notamment les citations de Bret Victor.

Citation :
“When I want to make a thing, especially when I want to create something in software, there’s this initial layer of disgust that I have to push through, where I’m not manipulating the thing that I want to make, I’m writing a bunch of text into a text editor.”

“There’s a pretty strong conviction that that’s the wrong way of doing things.”


http://worrydream.com/cv/ -> il a travaillé chez Alesis, sur les Micron, Ion et Fusion. Plutôt ironique et dépouillé, le Ion, pour un spécialiste des interfaces homme-machine.

:-D

« What is full of redundancy or formula is predictably boring. What is free of all structure or discipline is randomly boring. In between lies art. » (Wendy Carlos)

1698
En parlan d'IHM, dites moi que vous n'avez pas raté cette pépite :

https://www.pushturnmove.com/

https://fr.audiofanzine.com/methode/kim-bjorn/push-turn-move/medias/photos/

kim-bj-rn-push-turn-move-1762519.jpg

Ca fait un mois que je l'ai :bravo:

Développeur de Musical Entropy | Nouveau plug-in freeware, The Great Escape | Soundcloud

1699
Wolfen : il a l’air super ce livre !


Citation :
Chouette article du Monde.fr adapté de The Atlantic :
http://internetactu.blog.lemonde.fr/2017/11/25/reinventer-la-programmation/

Mouais, je suis assez mitigé sur cet article, du moins pour des gens qui s’intéressent depuis longtemps à la programmation :

- il passe beaucoup de temps à enfoncer des portes ouvertes (les très gros logiciels sont devenus courants, et sont très difficiles à rendre parfaitement fiables)

- il présente comme nouveaux des trucs connus depuis longtemps (les méthodes formelles), au moins 20 ans (1974 et 1980 pour Z et B)

- il pose des « fausses questions », dont on connaît déjà les réponses.


Pour ce dernier point, je parle de :
Citation :
En fait, comme le montre l’exemple de l’aéronautique, nous savons déjà comment rendre des logiciels complexes fiables, via des normes réglementaires rigoureuses, des procédures de conception et de documentation très rigoureuses elles aussi. « Alors pourquoi ne le faisons-nous pas partout ? », interroge James Somers.

Tant et si bien, souligne Somers, qu’il faudrait surtout étudier pourquoi les développeurs sont encore si réfractaires à ces nouvelles méthodes.

Ce qui fait que ces méthodes (pas nouvelles) ne sont pas plus utilisées, c’est qu’elles coûtent beaucoup plus cher. Plus exactement : leur productivité est beaucoup plus faible, donc le coût beaucoup plus élevé pour réaliser les mêmes fonctions.

Typiquement, les systémiers (Airbus, Thalès, ADS ex Astrium/Matra...) estiment à une multiplication par 5 l’augmentation du coût entre chacun des niveaux suivants :

- industriel (le plus courant dans tout ce qui est censé être sérieux ; donc avec déjà beaucoup de tests, de la documentation etc...) ; estimation globale pour un projet (y compris docs, tests...) = un jour pour un bonhomme pour produire 25 lignes de code.

- critique (typiquement une salle de contrôle de satellites : ce dernier coûte tellement cher qu’on ne peut pas le perdre, néanmoins la salle étant au sol, les corrections sont plus faciles que ci-après)

- embarqué (forte probabilité de mort d’hommes, perte financière colossale ; commandes de vol d’un avion de ligne, matériel médical sensible, code de pilotage d’un satellite...)

Dans le dernier cas, les méthodes formelles sont assez souvent utilisées. Notamment le Z.100 / SDL (1988).
Mais ça coûte 25 fois plus cher que du code industriel, qui coûte déjà beaucoup plus cher que tout ce qui est un peu bâclé (pour du code industriel, la charge de travail totale est généralement considérée comme six fois la charge de codage).

Je pense que la faiblesse de l’article vient du fait qu’il a été rédigé essentiellement en interviewant des gens qui ont des trucs à vendre, et présentent donc les faits d’une manière qui les arrange un peu.

Ces questions de criticité du logiciel se sont imposées de manière brutale avec la triste histoire du Therac-25, donc ça ne date pas d’hier (1987). Aussi le vol inaugural d’Ariane 5 en 1996.


Après si on ne connaît pas ces sujets, cet article reste une introduction assez intéressante.
Je pense qu’il a aussi raison de souligner qu’en automobile la criticité semble un peu sous-évaluée.

C'est bien l'homme qui cause le dérèglement climatique - AudioFanzine sans PUBlicité

[ Dernière édition du message le 26/11/2017 à 16:31:43 ]

1700
100% d'accord avec Pouet !

J'ajoute que la productivité avec les langages graphiques ou WYSIWYG est désastreuse, même si c'est utilisé pour certains systèmes critiques (je pense notamment à SCADE : http://www.esterel-technologies.com/products/scade-suite/) [edit : je n'avais pas fini de lire l'article, en fait il en est question. En passant, le langage Esterel a été abandonné par la société du même nom ... pour se concentrer sur Lustre/SCADE et se faire racheter par ANSYS.]

Il y a en ce moment de gros enjeux sur la sûreté (au sens résilience aux erreurs, aux pannes et aux facteurs environnementaux) et de sécurité (au sens résilience aux attaques malveillantes) du logiciel. En effet, de plus en plus de systèmes critiques et/ou embarqués deviennent connectés. Et de plus en plus de produits contiennent de l'informatique embarquée. L'automobile, de plus en plus assistée voire autonome, est symptomatique (avec sa particularité d'être à la fois critique et grand public). Mais il y en a plein d'autres, le sujet très à la mode étant l'Internet des Objets (IoT).

Dans la course à la productivité sur des systèmes informatiques de plus en plus complexes, on a poussé l'abstraction. On code sous forme de strate, et on forme les ingénieurs à ne raisonner que dans l'abstraction d'une strate. Ca rend le code inoptimisable, et planque les bugs au plus profond des interactions entre strates. Il faut réussir à re-concrétiser tout ca pour maîtriser le fonctionnement.

Par ailleurs, l'esprit humain est super mal équipé pour penser des flux d'information parallèles intriqués (préemption de threads, déterminer les bonnes priorités dans un modèle CSP, partage de ressources entre plusieurs processeurs, etc.). À mon avis c'est plus là-dessus qu'il faudrait plancher en terme de révolution des langages informatiques : expression directe du temps (deadlines) et des dépendances de données, éviter les communications implicites (variables partagées), etc.

Le formalisme synchrone, sur lequel la recherche française était en pointe il y a 30 ans (et qui a débouché sur Esterel) a été une tentative dans ce sens. Il en faudrait d'autres ...

Mais bon, déjà une prise de conscience que le logiciel n'est pas magique, ce serait bien.

Musikmesser 2013 - Bullshit Gourous - Tocxic Instruments - festivals Foud'Rock, Metal Sphère et la Tour met les Watts

[ Dernière édition du message le 26/11/2017 à 16:50:18 ]