Se connecter
Se connecter

ou
Créer un compte

ou
FR
EN

Le pub des programmeurs

  • 1 927 réponses
  • 117 participants
  • 131 770 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
1751
Citation :
injection SQL, qui peuvent être dévastatrices

Voilà. :oops2:
1752
Tout ça, plus le fait d'être fortement dépendant du PHP au niveau de la base => pratique à bannir.
1753
Ouais, merci de me confirmer que ça a été fait à la crade. Pas une grosse surprise en fait.
1754
Ouais le gros danger c'est que ça expose aux attaques par injection. Ça vaut le coup de vérifier si les requêtes sont faites avec le minimum de précaution comme parser pour virer les caractères spéciaux de contrôle...
1755
Automatiquement :

exploits_of_a_mom.png

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

1756
Quelqu’un a-t-il des suggestions de vidéos YouTube pour :

1- programmer des PICS

2- (et pour un ami) débuter en programmation ; plutôt en Python. Je lui ai déjà indiqué les vidéos (très claires) de Yvan Monka sur Scratch.

?
1757
Citation :
1- programmer des PICS


Alors qu'est ce que tu entends par programmer ? Les PICs c'est presque exclusivement du langage C. Il existe quelques vidéos mais qui parlent plus des spécificités des composants ou des IDEs. Tu peux regarder sur la chaine d'electrobidouilleur, il a quelques vidéos ou il utilise des pics

Jipihorn a fait une grosse vidéo sur l'outil de dev actuel de microchip (et il râle bien évidemment :bave: :-D )https://www.youtube.com/watch?v=yNWyhjcl8Bs
Voila en contenu français à part ces deux la je connais rien d'autre (mais il y a déjà pas mal de contenu la) sinon, tu peux regarder sur la chaine youtube de microchip

Edit : Quelqu'un a vraisemblablement fait une sorte de gros tuto séparé en différentes vidéos sur la programmation des pics. Par contre je sais pas du tout ce que ca vaut, à première vue ca a l'air pas mal vu les titres des vidéos il semble parler de l'essentiel https://www.youtube.com/watch?v=PefxW2s4Vlk&list=PLR7y_-qHrkNC2M_eCd64un5ut27Z2pZge
1758
Citation de EraTom :
Ouais le gros danger c'est que ça expose aux attaques par injection. Ça vaut le coup de vérifier si les requêtes sont faites avec le minimum de précaution comme parser pour virer les caractères spéciaux de contrôle...

En plus de ça, on peut aussi utiliser des requêtes préparées. Il suffit ensuite de lier les paramètres réels. Comme ça la requête n'est pas construite en concaténant des chaînes.

nothing is certain but death and taxes

1759
Pourquoi du PIC ? Ce sera bien plus simple de débuter avec un environnement Arduino.
(et perso je trouve l'archi AVR bien plus propre que celle des PIC)

Je ne suis pas convaincu par un support vidéo pour apprendre un langage de programmation : c'est toujours trop lent ou trop rapide. On trouve plein de tutos "Apprendre Python en 10 minutes" sous forme de blog ou d'ebook :
https://www.stavros.io/tutorials/python/
https://www.pyscoop.com/learn-python-in-10-minutes/
https://learnxinyminutes.com/docs/python/
1760
En effet, une vidéo pour apprendre la programmation, ce n'est pas très adapté comme support.

Mes enfants ont le livre Python pour les kids. Même s'il est à destination des enfants, je le trouve plutôt bien fait.
1761
Citation de Jimbass :
Pourquoi du PIC ? Ce sera bien plus simple de débuter avec un environnement Arduino.
(et perso je trouve l'archi AVR bien plus propre que celle des PIC)

+1 pour AVR, c'est très fonctionnel et les data sheet sont bien mieux écrites que chez Microchip.
Et puis, rien n'oblige a programmer un Arduino en arduino, on peut tout a fait écrire du bon vieux C, compiler avec avr-gcc et n'utiliser de l'Arduino que le bootloader pour flasher.

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

1762
Citation :
Alors qu'est ce que tu entends par programmer ? Les PICs c'est presque exclusivement du langage C. Il existe quelques vidéos mais qui parlent plus des spécificités des composants ou des IDEs.

Oui la question n’était pas très bien formulée, mais ta réponse est bonne. Merci pour les liens, idem pour JimBass et les autres.

Étant sur Mac, au niveau IDE et interconnexion avec le PIC ou Arduino, il y a des solutions bien adaptées ?


Citation :
Je ne suis pas convaincu par un support vidéo pour apprendre un langage de programmation : c'est toujours trop lent ou trop rapide.

Je suis d’accord. Et je trouve que les cours en ligne de CodeCademy sont très bien (merci Trumanche ! ).
C’est plus pour convaincre le pote que ce n’est pas compliqué. Bon à la limite les vidéos pour Scratch le font assez.


x
Hors sujet :
Par ailleurs, je verrais bien une version de Scratch orientée statechart + multitâche. :volatil: (à moins qu’il sache déjà le faire ? !! )
D’ailleurs la première version des Lego Mindstorms était orientée statechart. :bave:
1763
Citation :
Étant sur Mac, au niveau IDE et interconnexion avec le PIC ou Arduino, il y a des solutions bien adaptées ?


MplabX est dispo sur mac, les compilateurs pour les familles 8,16 et 32 bits aussi (et ils existent en version gratuite ou le code généré ne sera par contre pas optimisé) pour arduino aucune idée mais je pense que c'est pareil
1764
Citation de Dr :

Étant sur Mac, au niveau IDE et interconnexion avec le PIC ou Arduino, il y a des solutions bien adaptées ?

L'avantage est a l'Arduino dans ce cas: c'est un device USB série qui parle a un bootloader embarqué sur la carte elle-même, pas besoin d'acheter un programmateur.
Si tu prends cette route, le programme avrdude te permet de flasher l'arduino depuis un terminal ou un Makefile (tu peux aussi t'en servir pour les bits d'option), et apparemment il y a moyen de le faire tourner sur OSX.

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

1765
1766
L'environnement Arduino de base est libre et multi-plateforme : https://www.arduino.cc/en/Main/Software

mais rien n'empêche d'utiliser ton éditeur préféré, gcc et avrdude qui en sont le principe actif. Le chargement du binaire dans la carte se fait par série-via-USB, ultra standard et sans driver sur Mac ou Linux.
https://www.arduino.cc/en/Guide/MacOSX

Idem pour la programmation : je ne comprends pas trop ceux qui distinguent le C et le "language" Arduino, en plus du bootloader il s'agit juste de quelques librairies bien pratiques pour accéder aux IO, et d'un scheduleur ultra basique (mais qui devrait te rappeler certains systèmes critiques) avec une fonction d'init et une boucle infinie.

[ Dernière édition du message le 15/11/2018 à 21:06:05 ]

1767
x
Hors sujet :
Citation de Jimbass :
je ne comprends pas trop ceux qui distinguent le C et le "language" Arduino, en plus du bootloader il s'agit juste de quelques librairies bien pratiques pour accéder aux IO, et d'un scheduleur ultra basique (mais qui devrait te rappeler certains systèmes critiques) avec une fonction d'init et une boucle infinie.

Tu conviendras tout de même que le but (largement atteint) d'Arduino est d'abstraire une bonne partie de ce qu'on doit faire lorsqu'on démarre un projet embarqué en C.
Ça n’était pas un jugement de valeur, du tout, la forme n’était peut-être pas la meilleure, et ça n'est effectivement pas un langage a part.
De mon point de vue, si on veut faire un projet pour avoir un résultat rapide (et évidemment parfaitement fonctionnel), Arduino est la bonne solution.
Si on veut apprendre a programmer un MCU, la datasheet et un compilateur C sont un chemin assurément plus long (lourd même), mais plus riche en apprentissages.

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

1768
x
Hors sujet :
Ah, mais nous sommes entièrement d'accord. Et je ne faisais pas spécialement référence à ton post précédent, ca m'a juste fait penser à des discours plus "tranchés" que j'ai rencontré par ailleurs.

C'est vraiment une super plate-forme pour débuter et/ou pour obtenir un résultat fonctionnel rapidement et simplement. Je gros avantage que j'y vois, outre l’apprentissage initial, c'est de réconcilier des programmeurs "pur software" qui ont pris l'habitude de se complaire dans l'abstraction totale (et considérer la mémoire comme infinie) avec le monde physique et les ressources limitées de l'embarqué.

Dans un second temps, on peut s'attaquer à des mécanismes plus évolués : interruptions, périphériques divers, bootloader, voire RTOS ...
1769
x
Hors sujet :

J'aime bien FreeRTOS, et c'est effectivement un bon next step une fois qu'on s'est fait la main.
Ces derniers temps, j'utilise beaucoup ChibiOS qui est tres complet, avec plus d'abstractions et un tres bon support pour les Cortex-M* de chez STMicro.

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

1770
Je reviens juste du Audio Developer Conference de ROLI/JUCE à Londres, j'y ai animé une journée de formation : https://juce.com/adc

Comme d'hab toutes les vidéos sont disponibles sur Youtube (y en a d'autres à venir d'ailleurs, Youtube a striké une vidéo à cause d'un fond musical :violent: )

https://www.youtube.com/channel/UCaF6fKdDrSmPDmiZcl9KLnQ/videos?disable_polymer=1

Mais surtout cette année il y a une vidéo qui m'a bien retourné le cerveau, c'est la vidéo de Julian Storer (le fondateur de JUCE et le créateur de Tracktion) :



En gros il est en train de bosser sur un équivalent des shaders sur les GPUs mais pour l'audio, qui peut récupérer les ressources automatiquement là où elles sont pour faire du live coding en audio, pour alléger la charge CPU dans le cadre d'un plug-in. C'est super intéressant, ça me fait penser un peu à des trucs que j'ai vus récemment qui permettent de bidouiller les GPUs pour faire de l'audio dans un navigateur :

https://www.shadertoy.com/view/ldfSW2

Sauf que là y a en plus eu le développement d'un nouveau langage, de futurs drivers pour rendre plein de choses compatibles avec, un compilateur JIT et tout un tas de bordel :aime: J'ai bien aimé sa démo aussi où il passe juste d'un fichier à l'autre dans son éditeur texte, fait "save", et ça compile le contenu du fichier à la volée pour lui donner presque instantanément accès à un nouveau synthé qui est utilisé sans latence perceptible.

Plus d'infos à venir là : https://soul-lang.org

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

[ Dernière édition du message le 22/11/2018 à 19:47:13 ]

1771
Les traitements sur GPGPU ça marche bien... mais les latences ne sont pas compatibles avec ce qu'un musicien / ingé son attend en live.

A moins que j'ai loupé un truc, ce qui est prometteur ce n'est pas le langage en lui même mais la délocalisation des traitements vers un DSP qui orientera directement son flux de sortie vers le CNA pour réduire la latence, plutôt que de le renvoyer vers le CPU/RAM de l'ordinateur pour être ré-aiguillé vers la carte son.

Une telle architecture matérielle ne demande pas une rupture technologique dingue (les DSP pour faire de l'audio sont matures, mettre des DSP à côté d'un CNA dans une carte fille ou au bout d'une liaison USB... bon) ; il y a déjà eu des tentatives et pourtant ça n'a jamais vraiment percé.
Peut-être que les promesses du langage enclenchera la démocratisation de telle archi matérielle...
1772
En passant, savez-vous qu'une des toutes premières applications du concept de GPGPU a été pour l'audio ? Il s'agissait d'une réverb à convolution, laborieusement codée en OpenGL, et le signal audio était encodé dans une image pour être traité. À l'époque il était impensable de faire sur un CPU une convolution en temps réel avec une fréquence d'échantillonnage acceptable.

L'utilisation de tels coprocesseurs est un domaine qui progresse bien depuis quelques années, avec des standards logiciels comme OpenCL. Les DSP eux-mêmes ne sont plus trop à la mode, mais le couplage plus fort d'un GPGPU ou d'un FPGA avec le processeur est une tendance drivée par le Big Data et l'IA. On voit d'ailleurs arriver des "processeurs neuronaux", qui sont essentiellement des réseaux de DSP.
Tout ca manque encore cruellement d'IO directes.
1773
Peu importe le processeur / DSP / GPU déporté ; le problème de la latence et l'occupation du bus de donnée ne pourra pas être réglé tant que les données audio devront transiter d'une carte de calcul/traitement vers une carte son.

Enfin, les bus HDMI proposent un canal pour l'audio ; la dernière fois que j'ai regardé (fin 2016) il n'était pas possible de mapper les ports HDMI dans le contexte CUDA, par exemple.
C'est con, quand-même.


Peut être qu'il existe actuellement des solutions mais je n'en ai pas eu vent.
Je n'ai pas creusé avec OpenGL... vous savez ce qu'il est possible de faire ?
(Genre GPGPU avec Cuda, puis détourner le flux vers la sortie audio du HDMI avec OpenGL).
1774
Sur une carte FPGA rien n'empêche de faire des I/O dédiées : la puce a tout ce qu'il faut, mais il faut la configurer pour ca.

Côté GPGPU, ils sont bien trop occupés à faire du Big Data, de la prédiction financière ou de l'IA pour se préoccuper d'I/O directes faible latence. :((
1775
Du coup ça me donne presque envie d'essayer de coller un FPGA derrière un bus DVI pour détourner son usage et passer des samples sur 24bits dans une image.

A 60Hz ça fait une frame toutes les 17ms. Pour passer un signal stéréo à 48kHz il faudrait 2x48000/60 = 1600 pixels.