Audiofanzine a 25 ans !
Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
FR
EN
Notifications
  • Refonte graphique octobre 2025
    Refonte graphique octobre 2025
    Une refonte graphique vient d'être mise en ligne. Nous espérons qu'elle vous plaira. Merci de nous signaler tout bug ou perte de fonctionnalité ici →
  • Un cadeau d'UVI pour les 25 ans d'Audiofanzine
    Un cadeau d'UVI pour les 25 ans d'Audiofanzine
    Pour célébrer notre quart de siècle, UVI se joint à nous et vous offre le Digital Synsations Vol.1. Pour en profiter c'est par ici 👉
  • Nouveauté : Bookmark article, news ou tuto
    Nouveauté : Bookmark article, news ou tuto
    Bookmarkez un article, une news ou un tuto et retrouvez-le dans votre section "Mes signets" du menu membre.
  • 6 nouveaux annuaires
    6 nouveaux annuaires
    Luthiers, Réparateurs, Cours de musique, Studios d’enregistrement, de mastering et de répétition... Suggérez l’ajout d’une entreprise, inscrivez la vôtre ou déposez un avis.
  • Alertes disponibilité et baisse de prix
    Alertes disponibilité et baisse de prix
    Ces nouvelles fonctionnalités vous permettent d'être informé·e dès qu'un produit est disponible ou que son prix a baissé.
  • Tentatives d'arnaque dans les petites annonces
    Nous faisons face depuis quelques mois à une recrudescence de tentatives d'arnaques dans les petites annonces. Suivez nos recommandations >
Bidouille & Développement Informatique
News
Articles
Médias
Forums
Tutoriels

Le pub des programmeurs

  • 1 927 réponses
  • 117 participants
  • 131 668 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
1676
Citation :
J'avais pensé à utiliser une variable globale

Non. Ça c'est mal, et ce serait étonnant que tu ne finisses pas par le regretter.

Tu peux le faire via une programmation objet. Ou alors, ce qui revient à peu près au même, mais c'est moins élégant, passer sans arrêt en paramètre une structure qui contient les données dont tu as besoin.



Ceci n'est qu'un ´up' déguisé, car je pratique extrêmement peu Python. :oops2:

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

[ Dernière édition du message le 27/06/2017 à 20:25:48 ]

1677
+1 pour la programmation objet dans ce contexte.
En règle générale je ne suis pas fan de l'oo, mais là ca s'applique bien. Tu fais une classe par type d'instrument, avec dedans ta variable qui du coup est globale-mais-pas-trop, et des méthodes qui font ce que tu as à faire : initialiser, lire, changer de mode, etc.
Tu peux même factoriser les trucs communs dans une classe "instrument" dont hériteraient tes classes d'instruments particuliers.

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

1678
Une variable globale n'est pas forcément une mauvaise chose en soi.
C'est comme goto, ça peut faire le job et parfois c'est ce qui donnera la solution la plus simple et la plus lisible.
C'est généralement déconseillé mais si la portée de cette variable est limitée à ton fichier, si tu sais qu'il n'y aura jamais qu'une seule instance de cette variable et pas d'effets de bord, ça peut faire du code plus simple à lire (et ça c'est un des critères les plus importants).

Sinon, pour rebondir sur l'idée de Dr Pouet, cherche du côté de **kwargs pour passer un Dict en paramètre à une fonction.
C'est assez élégant et facile à lire une fois qu'on a compris le principe.

EDIT: et rien ne t'empêche de passer par une globale dans un premier temps pour vérifier que ton programme fonctionne, puis d'améliorer le design avec une classe dans le futur.

First make it work, then make it good, finally, make it awesome

EDIT 2: ou alors, ta fonction d'init retourne ta variable ou un tuple avec plusieurs variables, et c'est ça qui sera le paramètre de ta fonction.


def init():
    # initialize stuff
    if something_bad_happens():
        return None, None
    return x, y

def process(x, y):
    #do something awesome with x and y

if __name__ == "__main__":
    from sys import exit
    x, y = init()
    
    if x is None or y is None:
        exit("something bad happened")
    
    process(x, y)

Resistance is not futile... it's voltage divided by current

[ Dernière édition du message le 27/06/2017 à 20:56:05 ]

1679
Citation :
First make it work, then make it good, finally, make it awesome
Bof... On s'expose à rustiner encore et encore une archi qui aurait dû être pensée dès le début.

En fait, je ne vois pas trop ce que l'on gagne en lisibilité et en simplicité à ne pas partir directement sur une programmation objet.
1680
Ok, bon j'ai commencé à faire ça en poo du coup (première fois que j'en fait)

Voici ce que j'ai fait


Class monInstrument (object)
 Def __init__(self, ip_adress, visa)
 #blablablabla

 Def read_output_state 
 Return self._query('OUTP?')

Lorsque je crée mon instrument ça marche j'arrive à m'y connecter. Mais si par exemple je veux lire sa sortie j'ai un message d'erreur :

Moninstrument instance has nous attribuer 'query'

Ce que j'avais fait
Import visa
Import moninstrument_driver
test = moninstrument_driver.moninstrument("192.168.xx.xx")
test.read_output_state()

Quelqu'un voit ce que c'est ? En gros je pense qu'il ne comprends pas le 'query' dans la méthode read_output_state
1681
Si _query n'est pas une methode d'instance de monInstrument, tu ne peux pas appeler self._query

donc il faut soit que tu déclares (et implémente) une méthode d'instance _query dans la classe monInstrument, soit que tu fasse hériter monInstrument d'une classe qui a déjà cette méthode, soit que tu apelles _query pour une instance d'une classe qui l'a (et pas self, qui est la référence à l'instance courante) ;)

DubSide

[ Dernière édition du message le 28/06/2017 à 20:37:38 ]

1682
Tout d'abord, le dernier import visa n'est pas utile, il est fait dans l'import suiavnt, et tu n'as pas besoind e visa.
Ensuite, effectivement, tu as un problème avec _query, et je suppose que tu as un _query qui est défini, mais le '_' rend la fonction cachée. Si tu fais un dir(objet), tu devrait voir qu'il y a un moninstrucmentdriver_query et non un _query.

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

1683
x
Hors sujet :

Citation de EraTom :
Citation :
First make it work, then make it good, finally, make it awesome
Bof... On s'expose à rustiner encore et encore une archi qui aurait dû être pensée dès le début.


Dans un contexte industriel dans lequel tu développes un produit potentiellement complexe, qu'il va falloir maintenir, faire évoluer, etc.. je suis entièrement d'accord.

Ici on est manifestement dans un contexte de hobby, et vu la question posée, face à un dev ayant peu d'expérience (no disrespect @Patrick Truelle), et une des premières réponses parlait de classes et d'héritage.

Un design OO va demander une certaine expérience en architecture logicielle et un investissement en temps pour faire bien. Et si au final, il n'y a jamais qu'une seule instance de l'objet et seulement une poignée de méthodes, ce temps pourrait être employé de manière plus optimale en restant dans un simple programme procédural et en convergeant plus vite vers la fonctionnalité souhaitée.
Ce n'est bien sûr que mon avis.


Au sujet de _query, j'utilise très peu le système de classe de python.
Il me semble que rien n'est privé et que donc si _query est définie, tu devrais pouvoir l'appeler.

@Patrick Truelle: dans ce genre de cas, c'est plus facile d'aider si tu postes la trace que python imprime lorsque l'erreur arrive.

Resistance is not futile... it's voltage divided by current

1684
Il y a un mécanisme privé qui fonctionne quand la méthode commence par _.

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

1685
Citation de aaB :
x
Hors sujet :

Citation de EraTom :
Citation :
First make it work, then make it good, finally, make it awesome
Bof... On s'expose à rustiner encore et encore une archi qui aurait dû être pensée dès le début.


Dans un contexte industriel dans lequel tu développes un produit potentiellement complexe, qu'il va falloir maintenir, faire évoluer, etc.. je suis entièrement d'accord.

Ici on est manifestement dans un contexte de hobby, et vu la question posée, face à un dev ayant peu d'expérience (no disrespect @Patrick Truelle), et une des premières réponses parlait de classes et d'héritage.

Un design OO va demander une certaine expérience en architecture logicielle et un investissement en temps pour faire bien. Et si au final, il n'y a jamais qu'une seule instance de l'objet et seulement une poignée de méthodes, ce temps pourrait être employé de manière plus optimale en restant dans un simple programme procédural et en convergeant plus vite vers la fonctionnalité souhaitée.
Ce n'est bien sûr que mon avis.


Au sujet de _query, j'utilise très peu le système de classe de python.
Il me semble que rien n'est privé et que donc si _query est définie, tu devrais pouvoir l'appeler.

@Patrick Truelle: dans ce genre de cas, c'est plus facile d'aider si tu postes la trace que python imprime lorsque l'erreur arrive.
Oui c'est vrai ; je suis un peu trop formaté industrie et même pour mes bidouilles chez moi je griffonne des spec icon_facepalm.gif
1686
x
Hors sujet :

Citation de miles1981 :
Il y a un mécanisme privé qui fonctionne quand la méthode commence par _.


Je viens de faire un simple test.
Une méthode préfixée par _ peut tout à fait être appelée depuis une instance de la classe.
Par contre, si une seconde classe hérite de la première, elle n'hérite pas des méthodes "privées", du moins en python 3.
C'est probablement plus subtil dans un vrai design (par opposition à une dizaine de lignes pour voir si ça marche), mais je ne suis pas un spécialiste de l'OO.

Ce qui m'amène à:


@Patrick Truelle: ta methode _query ne serait-elle pas une méthode "privée" d'une classe dont ta classe hérite?
J'imagine que tu dois pouvoir faire un truc du genre (pas testé, il faudra certainement lire la doc pour savoir comment faire ça bien de manière pythonique):

class p:
    def __init__(self):
        # init code
    
    def _query(self):
        # do something

class c(p):
    def __init__(self):
        self.query = p._query

Resistance is not futile... it's voltage divided by current

[ Dernière édition du message le 29/06/2017 à 19:37:14 ]

1687
Citation de aaB :
x
Hors sujet :

Citation de miles1981 :
Il y a un mécanisme privé qui fonctionne quand la méthode commence par _.


Je viens de faire un simple test.
Une méthode préfixée par _ peut tout à fait être appelée depuis une instance de la classe.
Par contre, si une seconde classe hérite de la première, elle n'hérite pas des méthodes "privées", du moins en python 3.
C'est probablement plus subtil dans un vrai design (par opposition à une dizaine de lignes pour voir si ça marche), mais je ne suis pas un spécialiste de l'OO.

Ce qui m'amène à:


Ah, ça doit être ça. C'est accessible en mettant le nom de la classe héritée devant le nom de la méthode.

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

1688
Je serai à nouveau à Londres en Novembre à l'Audio Developer Conference 2017, en partenariat avec JUCE / ROLI, pour faire une présentation en anglais qui s'appellera "Fifty Shades of Distortion" (Cinquante nuances de distorsion), et elle sera probablement enregistrée pour être mise sur Youtube comme les autres années ! :bravo:

(je repars bosser mon accent anglais) :mdr:

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

1689
:bravo:

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

1690
Citation de Wolfen :
Je serai à nouveau à Londres en Novembre à l'Audio Developer Conference 2017, en partenariat avec JUCE / ROLI, pour faire une présentation en anglais qui s'appellera "Fifty Shades of Distortion" (Cinquante nuances de distorsion), et elle sera probablement enregistrée pour être mise sur Youtube comme les autres années ! :bravo:

(je repars bosser mon accent anglais) :mdr:

Cool ! On se verra sur le thème de la dispo, je ferai un talk sur l'optimisation de la modélisation d'un circuit de distortion (j'hésite entre SD1/TS9 et un circuit plus classique).

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

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 ]