fero14041 a écrit 192 commentaires

Est-ce que ça ne vaudrait pas le coup de mettre en place un système, ponctuel, spécifiquement pour les frais occasionnés par cette affaire? Avec une jauge des montants versés VS engagés/potentiels… Ca pourrait peut-être inciter d'avantage de dons, non?

Je rajouterais notamment comme référence l'ouvrage "Pro Linux System Administration" (Apress, 2nd éd.) (https://www.apress.com/us/book/9781484220078), qui est assez complet et très orienté débutant. Il couvre CentOS et Ubuntu.

A commencer par celui de Gérard Swinnen "Apprendre à programmer avec Python 3": http://inforef.be/swi/download/apprendre_python3.pdf
Les livres, on n'a pas fait mieux depuis l'invention d'Internet…

Merci!

Tous les liens externes de l'article sont cassés: ils pointent tous vers des sous-parties de LinuxFR! Si un modo passant par là pouvait corriger ?-)

Utilisateur de Mercurial, je constate qu'il y a des avantages à Git (VS Mercurial). J'aime beaucoup l'argumentaire de Michael Bayer, le papa de SQLAlchemy expliquant pourquoi ce projet a migré de Mercurial vers Git: http://www.sqlalchemy.org/blog/2013/05/25/sqlalchemy-migrated-to-git/, qui rejoint partiellement le commentaire ci-dessous de Seb.
Au delà des aspects techniques – et Git semble avoir de très solides arguments –, à mes yeux son principal avantage est sa base d'utilisateurs, propulsée par GitHub. Ce n'est pas pour rien que Bitbucket a introduit Git comme système de gestion de version alternatif à Mercurial, et ce depuis 2011 ;-|

Apparemment, la version 2 de la "norme" est sortie assez récemment. Mais où peut-on trouver un changelog lisible, ailleurs que celui du dépôt git? (parce que bon, indiquer "on a changé de versionl'API", c'est que la moitié du boulot…)

Flattr, non?

Merci!

Les diapos de la présentation effectuée par Michael Bright au Grenoble Python User Group le 27 mars sont également disponibles: http://mjbright.github.io/Pygre/2014/2014-Mar-27-LightWeightVirtualizationWithDocker/presentation.html

Et avec (presque) 8 ans déjà: Django (21 juillet 2005, dixit Wikipédia)

Ah, merci pour la référence :-)

Une autre différence, à mes yeux importante, entre Sass et LESS tient dans l'existence de bouquin(s) pour le premier et pas pour le second. Il en existe un chez The Pragmatic Bookshelf: "Pragmatic guide to Sass", et un autre devrait être publié sous peu chez Manning: "Sass and Compass in Action".

Tarek Ziadé a publié il y a peu à propos de son expérience pour faire du Raspberry Pi un juke-box (1ère partie, 2nde). L'article est en anglais, mais l'auteur français: est-ce que ça compte, ou seulement pour moitié ?-)

Je dirais même plus: Sphinx!

• Permet de générer du HTML, PDF (via LaTeX), ePub & plus;
• autorise la coloration syntaxique des langages reconnus par Pygments;
• il est facile de créer un hook sur le dépôt pour appeler le Makefile générant les formats de sortie (voir la doc du système de gestion de version).

Hello, guys.

Je trouve super de montrer comment utiliser les ressources d'un jeu pour permettre à d'autres d'en faire un nouveau. Il y a peu, un des auteurs de Frogatto a commencé une série d'articles et de vidéos autour de la création d'un jeu de plateforme (baptisé Elisa’s Quest) réutilisant son moteur, que je m'empresse donc de partager ici:

1. developing with the Frogatto engine,
2. developing games using the Frogatto engine: part 1,
3. developing games using the Frogatto engine: part 2,
4. how event handling in Frogatto works,
5. developing games using the Frogatto engine: part 3,
6. a gentle introduction to Frogatto formula language.

C'est malheureusement en anglais, mais se suit assez bien.

Il ne manquerait pas une mention explicite du sujet du GNU/LinuxMag HS, à savoir: Android, dans le début du paragraphe y afférant? (NB: Android est mentionné explicitement dans la première liste du chapô, dans le second lien, et en fin des paragraphes concernés. Ceux qui lisent trop rapidement pourraient l'avoir loupé.) Un admin pour corriger?

Pour les ceusses et celles qui souhaiteraient un complément à la présente dépêche, en français, il est à noter que Smile a publié un "livre blanc" traitant du NoSQL.

Merci!

Je suppose qu'il y a une erreur de typo pour Sphinx?

On pourrait même aller plus loin: visualiser de manière systématique le sommaire, qu'il soit ou non affiché à la publication. Cela permettrait aux rédacteurs utilisant des titres de vérifier la structure du contenu, leur arborescence.

Oui, entièrement d'accord pour garder le sommaire automatiquement généré pour les entrées longues. Pardon si la proposition prêtait à confusion sur ce point; elle portait sur la possibilité de l'inclure pour les courtes.

Donc: nouvelle entrée dans le suivi, demandant la possibilité d'inclure, à la discrétion des auteurs, le sommaire généré automatiquement.

Ah bah nan: ça ne permet pas pour le rédacteur de choisir d'insérer le sommaire automatique. Je pensais à quelque chose comme en reStructuredText:
.. contents::
Crotte, faire une entrée de suivi pour pouvoir rédiger sereinement une entrée de suivi, c'est décourageant…

Ok, merci pour ces précisions. Je cherchais en vain une commande à effectuer côté rédacteur: il n'y en a pas.

Pardon, c'était voulu: une référence au Petit Prince de Saint-Exupéry ("S'il vous plaît, dessine-moi un troll!").