De tout, de rien, des bookmarks, du bla bla #10

Posté par  (site web personnel) . Édité par Nÿco et Benoît Sibaud. Modéré par Benoît Sibaud. Licence CC By‑SA.
Étiquettes :
33
10
mar.
2013
Technologie

Le dernier numéro date maintenant d'il y a un bon moment (l'an dernier). Pas mal de choses se sont passées qui m'ont beaucoup ralenti. Entre autre, mon moteur de blog statique Web Log Today a occupé pas mal de mon temps. Mais j'ai aussi changé d'emploi. Tout ça fait que j'ai pas raconté grand chose côté veille.

Je ne vais pas rattraper ce qui est arrivé durant ce temps, ce serait trop complexe et surtout inutile car vous avez du avoir ces informations par ailleurs. Mais voici tout de même quelques petites news, en espérant que j'arrive à reprendre le rythme :)

Comme toujours, les plus pressés trouveront à la fin de l'article la liste brute des liens présentés.

Bonne lecture !

Sommaire

Un peu de contenu

Développement

Si vous êtes intéressés par le développement iOS et/ou ruby, vous connaissez probablement Mattt Thompson. Si non, ben il parait que c'est un bon, entre autre développeur iOS et ruby. Il est par exemple "Mobile Lead" chez Heroku, papotte sur NSHipster, code sur plein de trucs.

Mattt a été invité par l'antenne lyonnaise des CocoaHeads pour parler de Ruby + iOS. Vous pouvez trouver plus d'informations ici sachant que la soirée, qui se déroulera le 3 avril, est sur inscription (mais gratuite évidemment).

La version 1.5.0 de CoffeeScript est sortie récemment. La grande nouveauté est la sortie du literate CoffeeScript. Vous pouvez retrouver quelques infos sur l'article que j'ai écris récemment : « Literate programming, pour un code toujours documenté ? » (qui comporte aussi quelques infos et présentations sur le literate programming).

Par contre, je ne vous conseille absolument pas cette version, elle pose un certain nombre de problèmes, entre autre liés aux parenthèses et accolades implicites. Vous pouvez voir un exemple de problème sur ce bug sur le teabook open reader. Heureusement, une version 1.6.1 (dont voici le changelog) est sortie est corrige ce problème. Elle inclus aussi, et ça c'est une très très bonne nouvelle, le support des Source Maps. Les source maps permettent au debugger javascript de faire le lien avec la source coffeescript et affichent donc le code coffeescript originel en lieu et place du javascript généré. Un grand pas en avant je trouve.

Twitter continue d'ouvrir un certain nombre de code. Cette fois ci (enfin c'était il y a un petit moment déjà) il s'agit de flight, (encore) un framework javascript. Il est orienté événementiel mais pour tout dire je ne l'ai pas testé. En fait je ne sais pas vraiment en quoi il serait plus intéressant qu'un autre, si quelqu'un a testé je suis preneur d'informations.

On continue dans les bibliothèques d'interface avec Topcoat d'Adobe. Il s'agit pour le coup uniquement de style (css) et c'est plutôt sympa, même si c'est surtout un de plus ;)

À noter que les Google API sont désormais officiellement supportées sous node.js.

Si vous développez sous android, vous serez probablement intéressés par Action Bar Scherlock. Il s'agit d'une lib au dessus des barres d'action d'Android, permettant de les gérer plus facilement quelque soit le matériel de destination (tablette ou smartphone).

jQuery est sorti en version 2 beta 2. Pour ma part je ne suis en général pas trop le développement de jQuery (c'est loin d'être la bib javascript que je préfère). Par contre, ce fut pour moi l'occasion de voir que la version 2 ne supportera plus les version 6, 7 et 8 d'Internet Explorer ! Ça c'est une vrai bonne nouvelle ! Par contre, la crainte que j'ai c'est que cela freine et morcelle encore plus le paysage javascript (avec les deux versions utilisées). Mais il serait temps que les IE < 9 disparaissent enfin (et quand j'entends certaines entreprises migrer sous IE7 et Vista, comment dire…)

Graphisme, design & co

On sort un peu (mais pas trop, ne vous inquiétez pas) du développement pour passer du côté de la typographie. Tout d'abord avec l'excellent Typelate. Il s'agit d'un framework css (disponible en sass, stylus, less ou css) s'occupant uniquement du rendu des textes. Et franchement c'est bien fait. Je pense d'ailleurs que je l'inclurai désormais dans mes développements. La typographie est loin d'être quelque chose d'anodin, souvent négligé (même si c'est un peu moins vrai ces derniers temps) et pourtant revêt d'une importance capitale étant donné que la majorité du contenu sur internet reste le texte.

Et pour continuer dans la typo, une question : vous n'en avez pas marre du lorem ipsum ? Si oui, vous apprécierez probablement Blokk. Il s'agit d'une police de caractère spécialement étudiée pour vos wireframes et mockups, surtout si vous ne comprenez pas le latin. Allez voir le site pour un aperçu, moi j'aime bien !

Misc

Dans le genre totalement inutile dont absolument indispensable, je vous présente coffitivity. Ça ne fait rien d'autre que… jouer du bruit comme si vous étiez au café ! Personnellement je n'arrive pas à me concentrer dans le silence. C'est juste horrible. Résultat le passe la majeur partie de mon temps avec de la musique dans les oreilles. Là par exemple, je bosse dans une boite silencieuse. J'avais jamais vu ça, je suis dans un grand open space et… rien. Pas de bruit. Finalement avec coffitivity et ma musique, ça ressemble enfin à une atmosphère pour bien bosser !

Liste des liens présentés

Développement

Graphisme, design & co

Misc

Aller plus loin

  • # Veille culturelle

    Posté par  (site web personnel) . Évalué à 3.

    Typelate m'a scotché. Les bonnes pratiques typographiques sont connues, et les moyens techniques de les pratiquer sur le web ne sont finalement pas très complexes, mais je reste impressionné par le soin du détail.

    Et en parcourant les autres liens, ainsi que tes autres dépêches et tutoriels, je m'aperçois que l'esthétique du web est en pleine révolution.

    Je ne te remercierai jamais assez de me (nous?) faire découvrir cette face du web que sans toi je (nous?) n'aurions découverte que trop tard.

    • [^] # Re: Veille culturelle

      Posté par  (site web personnel) . Évalué à 3.

      Merci :)

      Pendant pas mal de temps j'étais un développeur sans talent graphique. Aujourd'hui… ben j'ai pas beaucoup plus de talent mais j'essaie de me soigner :)

      La typo entre autre est quelque chose que j'apprécie pas mal. Je ne suis pas fan de lettres (littérature) mais j'ai toujours apprécié les lettres au sens graphique. Par exemple, sur la machine avec laquelle j'écris, j'ai presque 5000 polices.

      Il faut bien voir que la majorité des choses sur le web c'est du texte. Mais surtout, la majeur partie des informations sont textuelles, bien avant les images ou autre. La première chose à faire est de tenter de les afficher de manière agréable.

      Par contre, les bonnes pratiques ne sont pas si connues, surtout pas si simples. On les connait un peu mieux pour le papier, les supports physiques, mais pour le web ce n'est pas si évident. Et côté techno ce n'est pas si simple non plus.

      Si le sujet intéresse, il y a ce livre qui est plutôt sympa, agréable et rapide à lire : Webgrids - Structure et et typographie de la page web.

      Il y a aussi cette présentation côté techno : Get the look. Mais le support des navigateurs est variable et les fonctionnalités peuvent encore être améliorées. Entre autre le support de nouvelles manières d'afficher le texte mérite d'être poussé et continué, par exemple tout ce qui tourne autour des colonnes (j'avais un lien mais je ne le retrouve plus dans l'instant)

      Y'a aussi le "tuto" là : Technical Web Typography: Guidelines and Techniques.
      Et aussi cet article : Les ligatures dans les navigateurs

      • [^] # Typelate

        Posté par  . Évalué à 2.

        C'est effectivement impressionnant. Dommage que la licence soit confuse.

        Il y a un fichier dans l'arborescence (typelate.less) qui dit :
        | LICENSE: Creative Commmons |
        | http://creativecommons.org/licenses/by/3.0 |

        Il y a une bibliothèque incluse (normalise-css) qui est sous licence AS-IS

        En revanche le README.md et la documentation qui en résulte donne une licence proprio.

        ######©credits
        Typeplate &copy;2013 &bull; A [@grayghostvisuals](https://twitter.com/gryghostvisuals) and [@zakkain](https://twitter.com/zakkain) Joint™

        • [^] # Re: Typelate

          Posté par  . Évalué à 4.

          Les crédits/copyright c'est pas pareil que la licence je pense, ça dit juste que ce sont eux les auteurs, alors que la licence ça dit comment ça peut être redistribuer…

          non ?

          • [^] # Re: Typelate

            Posté par  (site web personnel) . Évalué à 3.

            Oui, c'est d'ailleurs le principe des licences copyleft : utiliser le copyright afin de donner plus de droits.

            C'est pourquoi les GPL commencent par un ligne définissant le copyright qui indique qui a écrit, qui a les droits initiaux. Le reste du texte définissant la cession de droits à des tiers.

          • [^] # Re: Typelate

            Posté par  . Évalué à 3. Dernière modification le 11 mars 2013 à 11:54.

            Tu as raison sur la différence, mais le mot « crédit » que je cite est une indication de style de texte prédéfini, pas un titre de section qui apparait au lecteur. La doc finale indique « Copyright ©2013. Typeplate is a @gryghostvisuals and @zakkain Joint™ Logo Crafting by @TommyCreenan. », ce qui n'incite pas à penser qu'on a affaire à du logiciel libre.

            Dans les sources, il n'y a pas de fichier COPYING ; le fichier README ne mentionne pas de licence ; les fichiers n'ont pas d'en-tête de licence sauf les deux que j'ai cités, dont un n'est pas d'eux ; la page d'accueil sur github n'indique pas de licence ; le site web typelate n'indique pas de licence, seulement le « copyright » que j'ai cité. Sachant que par défaut tout ce qui n'a pas de licence ouvrant des droits est proprio. En tous cas c'est confus.

        • [^] # Re: Typelate

          Posté par  (site web personnel) . Évalué à 3.

          La licence est bien une cc-by

          https://github.com/typeplate/typeplate.github.com/blob/master/scss/_typeplate.scss#L16 (réponse de typeplate)

      • [^] # Re: Veille culturelle

        Posté par  (site web personnel) . Évalué à 2.

        Par contre, les bonnes pratiques ne sont pas si connues, surtout pas si simples. On les connait un peu mieux pour le papier, les supports physiques, mais pour le web ce n'est pas si évident.

        Du peu de typographie que je connaisse, il me semble que Typeless (ainsi que les autres choses dont tu as parlé jusqu'ici) est une transposition des pratiques de la typographie du livre : la ligne comme base, les tailles proportionnelles, l'indentation, les lignes de 45 à 70 caractères, la correction des fausses petites capitales, l'usage de styles typographiques (citations, notes, listes, définitions) qui définissent un rapport entre le fond et la forme, et quelques astuces pour corriger l'alignement et les césures lorsque la technologie n'y prend pas grand soin.

        Le couple html/css impose certes une manière de faire spécifique, mais pour le livre aussi chaque logiciel impose sa manière de faire spécifique.

        • [^] # Re: Veille culturelle

          Posté par  (site web personnel) . Évalué à 2.

          Il y a tout de même certaines possibilités différentes. Rien que le fait qu'on ne soit pas limité en pages. Dans les livres, on passe de page en page. Dans le numérique on n'est pas limité, on peut très bien avoir des documents beaucoup plus long (plus comme des rouleaux de papyrus par exemple) et ça demande d'autres comportement (pour ne pas rendre le tout indigeste)

          Il y a quelques variations du genre sur papier on va plutôt utiliser du serif, sur écran du sans serif. On va aussi sur papier beaucoup (beaucoup) utiliser le principe de grille, sur du numérique on va souvent l'utiliser mais pas toujours de la même manière, et parfois on peut même s'en passer.

          Alors oui, beaucoup de choses sont quasi identiques, la complexité vient tout de même lorsqu'il faut les appliquer et surtout il faut arriver à s'affranchir des contraintes physiques du livre pour libérer au maximum les possibilités.

  • # Mattt

    Posté par  (site web personnel) . Évalué à 2.

    Au fait, y a-t-il des lyonnais qui pensent aller au cocoaheads voir mattt ?

    Et sinon, j'ai oublié de précisé mais il sera aussi le 2 avril à Paris.rb (on peut trouver l'ensemble de sa tourner européenne ici : https://gist.github.com/mattt/5024982

  • # Programmation lettrée, des retours d'expérience ?

    Posté par  . Évalué à 6.

    Depuis que j'ai découvert la programmation lettrée, j'ai beaucoup accroché avec le concept. J'ai même traduit l'article Wikipédia anglais en français, afin de pouvoir faire profiter mes amis anglophobes du concept.

    J'ai écrit quelques programmes en utilisant des outils comme noweb, mais mon expérience est que cela mène à un code assez rigide :

    Quand on écrit un programme assez conséquent, on écrit encore plus de documentation. La conception du programme ressemble dans mon cas à l'écriture d'un livre. On organise notre documentation (qui n'est pas comment utiliser le code, mais quel est le contexte du code, pourquoi il est là, quel est son but réel) comme un livre, en le découpant en chapitre, suivant les différentes tâches à accomplir et les différents modules.

    Lors de la refactorisation, on n'a plus juste un petit morceau de code à déplacer, mais aussi toute une documentation à mettre à jour.

    Dans le cas d'un code extrêmement factorisé, la documentation devient quasiment inutile (une fonction parle d'elle même), ou – pour un problème complexe – a une meilleure place dans un document annexe décrivant le problème. Au pire, cette documentation peut se trouver au début du code, comme préambule. Elle n'est pas destinée à changer (elle décrit le problème), et n'est plus mélangée au code (ce n'est donc pas de la programmation lettrée).

    L'article de blog lié dans la dépêche pose la question de la programmation objet mixée à la programmation lettrée. J'ai remarqué dans ma manière de faire (et pour un programme écrit dès le départ en programmation lettrée, par contraste avec des codes déjà écrit et documentés/réorganisés après coup) que ce n'était pas très différent du fonctionnement headers/code que l'on trouve en C++. J'aurais par exemple une partie décrivant mon objet, puis plus loin la définition des méthodes (dans leur propres chapitres).

    Malgré tout l'enthousiasme que j'éprouve envers cette pratique, j'ai la sensation qu'elle ne fonctionne que dans le cas de petits programmes. Mon expérience porte sur un environnement de développement plus « complet » que ceux proposés par Haskell, CoffeeScript et Docco, c'est à dire des environnements où l'on peut vraiment séparer et déplacer le code suivant notre propre logique (les possibilités de factorisation offertes par Haskell et Coffeescript diminuent le besoin de réorganisation, mais je ne factorisais pas autant à l'époque, et cette réorganisation me semble encore pertinente dans le cas de la programmation objet). Et je n'ai pas trouvé d'exemple de code vraiment conséquent et en perpétuelle évolution écrit en programmation lettrée.

    Je parle de petits/gros programmes, mais mon véritable questionnement porte sur les programmes « jamais finit » : si le programme a une tâche à effectuer, et le fait bien, il n'a plus de raison d'évoluer. Dans ce cas, la programmation lettrée permet d'avoir un travail définitif et bien documenté. Mais pour les programmes plus « vivants » (par exemple, le code de LinuxFR n'a jamais arrêté d'évoluer), quelqu'un a t'il déjà utilisé avec succès cette méthode ?

    • [^] # Re: Programmation lettrée, des retours d'expérience ?

      Posté par  (site web personnel) . Évalué à 2.

      Malgré tout le respect que j'ai pour Knuth, je pense qu'il fait fausse route avec la programmation lettrée. Le langage des ordinateurs, c'est celui des mathématiques, et non pas celui de la langue humaine naturelle.

      Je suis d'accord avec Knuth sur le fait que l'un des points essentiels de la conception d'un programme, c'est qu'il soit compréhensible par les autres humains, et donc que les commentaires et les noms de variables sont importants, mais un programme n'est pas la simple transcription dans le langage des ordinateurs de quelque chose de préexistant dans la langue humaine. C'est quelque chose de différent.

      Pour donner une analogie de ce que je veux dire, quand je vais voir un architecte pour qu'il conçoive une maison, je ne veux pas qu'il me rédige un pavé de 20 pages en langue naturelle du style "à droite, on va mettre un escalier, qui débouchera sur les deux chambres". C'est bien plus simple qu'il me dessine un plan de la maison. D'ailleurs, dans sa tête, un architecte pense directement avec le plan de la maison, pas en langue naturelle.

      Et ce n'est pas un hasard si on parle de "l'architecture" d'un programme. Ce que je fais le plus souvent dans mon activité de programmation - et j'imagine que je ne suis pas le seul - c'est l'inverse de la programmation lettrée, à savoir de la programmation "graphique". Je prends un bout de papier, et je dessine avec des blocs et des flèches la structure d'ensemble du programme. Si on pouvait laisser facilement ces petits schémas en commentaire dans le source, ce serait génial.

      • [^] # Re: Programmation lettrée, des retours d'expérience ?

        Posté par  (site web personnel) . Évalué à 4.

        Si on pouvait laisser facilement ces petits schémas en commentaire dans le source, ce serait génial

        Sinon, le problème est un poil plus complexe. Certes c'est l'ordinateur qui doit executer le programme, mais il s'adresse aussi, beaucoup, aux humains. C'est une façon de l'écrire pour les humains, pour les programmeurs écrivant, lisant, modifiant, corrigeant le code. Une façon de prendre en charge le côté maintenance par exemple.

        En général on voit surtout des commentaires inutiles, là c'est à contre pied, peut-être trop. Mais ça a le mérite d'être une solution sympa pour décrire l'intention (c'est ce qui est le plus important, beaucoup plus qu'expliquer ce que font des lignes de code)

      • [^] # Re: Programmation lettrée, des retours d'expérience ?

        Posté par  (Mastodon) . Évalué à 2.

        Moi je dirais plutôt qu'il y a une convergence entre la programmation lettrée et la programmation traditionnelle. Les commentaires, dans les vieux langages, c'était plutôt un gadget. Puis ça a commencé à se normaliser, genre avec la Javadoc. Maintenant, les commentaires sont en train d'intégrer directement le code (en Python par exemple), ils font partie du code, ils sont du code. On n'est plus très loin de la programmation lettrée, mais prise dans le bon sens.

        • [^] # Re: Programmation lettrée, des retours d'expérience ?

          Posté par  . Évalué à 4.

          J'aurais tendance à dire que ce sont deux choses différentes :

          Les commentaires en Python et dans la Javadoc ont tendance à décrire l'API. L'objectif est de pouvoir récupérer la documentation d'une bibliothèque à partir de son code source, d'une part, et d'avoir la documentation sous les yeux lors de la programmation de la bibliothèque, d'autre part, non pas pour comprendre le code qu'on écrit, mais pour faciliter la synchronisation entre le code et sa documentation. Mais l'objectif final est de décrire l'API (cette fonction fait ça, celle là fait ceci…).

          L'orientation des commentaires de la programmation lettrée est plus destinée à celui qui va lire le code, qu'à celui qui va l'utiliser : on ne se contente pas de dire ce que fait la fonction, mais on explique pourquoi, comment, tout ce qui n'est pas évident. Si j'écris un parser, la documentation « javadoc » va expliquer comment utiliser mon parser (appeler telle fonction pour tel résultat), et la documentation « lettrée » va expliquer le fonctionnement interne du parseur (quel algorithme, quelles exceptions…).

          Dans ce morceau de code :

              # Sys will be needed to acceed standard file descriptors (stderr, stdout, sdin).    
    import sys

    def error(message):
        """"Display a message on the stderr"""
        # Don't forget to put a newline, as write, unlike print, will not append it for us.
        sys.stderr.write(message+"\n")

          Le commentaire """ est l'équivalent de la javadoc, et les commentaires # sont l'équivalent de la programmation lettrée (quand à la pertinence des dit commentaires, essayez de trouver un meilleur exemple aussi court ;-)).

          Pour un exemple en français de ce à quoi peut ressembler un programme littéraire, j'ai écrit celui-ci il y a trois ans. (soyez gentils avec ma connexion, c'est auto-hébergé)

          Bon, mon style a beaucoup évolué depuis (c'est fou ce qu'on peut changer vite). Les morceaux de code sont conséquents, tout n'est pas dit (entre autre, une revue rapide du mode de fonctionnement du programme n'aurait pas été de trop), certains commentaires ont été écrits par captain obvious, il y a des passages pas très formels (lire : il y a des grossièretés), il n'y a pas de licence. Comme j'ai la flemme d'aller reprendre ce code dont je ne me sert plus du tout (puis bon, c'est un jouet, donc niveau motivation, si je l'utilise pas…), ces problèmes vont rester. À moins qu'un fou désire jouer avec. Dans ce cas, je ne dirais rien, mais il vaux mieux qu'il m'en informe, histoire que je fasse au moins l'effort de spécifier une licence, puis que je lui donne la source s'il ne l'a pas trouvé tout seul.

      • [^] # Re: Programmation lettrée, des retours d'expérience ?

        Posté par  . Évalué à 1.

        Justement, l'objectif de la programmation lettrée est de créer ce plan. Certes, de manière plus verbeuse qu'avec juste des schémas. Mais le programme se présentant comme un livre, il peut inclure des schémas.

        J'avais commencé à écrire un programme assez conséquent (pas terminé, même s'il est juste en pause). La majeure partie de l'effort s'est retrouvée à penser, puis décrire l'architecture. Il y avait des schémas inclut.

        Knuth est avant tout un mathématicien, et si le langage de l'ordinateur est celui des mathématiques, sa propositions est tout à fait pertinente : ce que j'ai lu qui ressemble le plus à de la programmation lettrée, c'est les travaux de mathématiciens décrivant des algorithmes (celui-ci par exemple).

        En fait, j'ai l'impression que la programmation lettrée se rapproche plus de la conception logicielle « à l'ancienne », où on réfléchit, spécifie, etc. énormément avant la moindre ligne de code, et où les spécifications ne vont pas changer. Dans ce cas, on obtient un livre, qui décrit de bout en bout l'implémentation du programme, de manière précise, avec schéma… Ce livre traite à la fois de l'architecture du programme, des détails d'implémentation, des pièges à éviter… C'est à la fois la description du programme et un traité sur comment résoudre le problème auquel le programme répond.

        La programmation lettrée me semble toutefois moins adaptée à des spécifications en continuelle évolution, comme on croise dans les méthodes agiles, programmation extrême, etc. (et quoi que vous pensiez des méthodes en question, le problème auquel elles veulent répondre existe et est inévitable dans certains domaines). Ces méthodologies étant très courantes de nos jours, et pertinentes dans les domaines pour lesquels je programme, j'aurais aimé savoir si quelqu'un avait réussit à les concilier à la programmation lettrée.

        Je me pose d'autant plus cette question que je croise de plus en plus de propositions quant à cette pratique (comme cette nouvelle implémentation par CoffeeScript). La programmation lettrée « des origines » date d'une époque où les besoins d'un programme étaient fixée avant l'écriture, et avec l'avènement de la programmation extrême est entrée en hibernation. L'éveil/évolution de cette pratique dans un nouveau contexte peut signifier qu'un début de réponse se met en place, visant à concilier ces deux mondes.

        Pour ma part, je suis passé à autre chose, influencé par Forth (dans ma recherche de la « méthode parfaite », l'approche de la programmation lettrée et l'approche de Forth sont les deux réponses qui m'ont le plus convaincues, bien que d'apparence totalement opposées). Je continuerais d'utiliser la programmation lettrée pour les problèmes « finit » (utilitaire shell, programme qui ne fait qu'une chose mais le fait bien), mais je n'essaye même plus pour les problèmes « créatifs » (site web, programme évolutif…).

        Et je suis donc intéressé par l'avis de ceux qui ont pratiqué, ou pratiquent encore, la programmation lettrée dans le cadre instable devenu courant de nos jours.

  • # Musique

    Posté par  . Évalué à 1.

    Je trouve aussi que bosser dans un environnement totalement silencieux ou, au contraire, trop (merci les écouteurs intra-auriculaires) m'empêche de travailler correctement.

    Personnellement c'est plutôt tout ce qui est électronique mais c'est généralement quelque chose de calme, juste pour « m'occuper » l'oreille sans avoir envie de changer toutes les 5 minutes ; je me permets de partager :
    - SubFM et DnBHeaven : « Drum And Bass Radio », mais je conseille à divers moments, vu que plusieurs DJs passent par jour, le style change grandement, des fois je n'aime pas du tout alors qu'un peu plus tard j'aime bien
    - « Above and Beyond - Trance Around The World » sur Youtube, 2h de mix de trance
    - les FG (surtout FG Clubbing et FG Remix) quand je veux quelque chose de plus « tonique »
    - FlaixFM : radio espagnole, par contre au bout d'une semaine on a entendu ce qu'ils vous passer pour un mois. Mais c'est marrant, parce que quelques mois plus tard les mêmes musiques vont arriver sur des radios du style Fun Radio avec un magnifique « la première fois que vous l'avez entendu, c'était sur Fun Radio »
    - Enfin, radio.fr qui permet de trouver pleins de webradios classées par thème.

    Voilà, c'est principalement ce que j'écoute, mais j'aimerais bien découvrir de nouveaux genres ou webradios qui s'y prêtent pour ça.

    • [^] # Re: Musique

      Posté par  . Évalué à 1.

      Les radios du monde : http://tunein.com

    • [^] # Re: Musique

      Posté par  (Mastodon) . Évalué à 2.

      Si tu aimes les musiques électroniques, il y a http://di.fm/ qui te propose tellement de trucs que tu es obligé de trouver ton bonheur. Et pour tous les autres styles, il y a la petite soeur, http://sky.fm/ !

    • [^] # Re: Musique

      Posté par  (Mastodon) . Évalué à 2.

      Voilà, c'est principalement ce que j'écoute, mais j'aimerais bien découvrir de nouveaux genres ou webradios qui s'y prêtent pour ça.

      Alors cette commande : mplayer http://relay1.slayradio.org:8100/ est faite pour toi. Avec un volume sonore raisonnable, l'accoutumance vient très vite, de la bonne chiptune qui maintient les neurones à la bonne cadence.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.