case42 a écrit 610 commentaires

Pareil, il a fallut que je lise jusqu'à "Smarty" pour comprendre que "moteur de gabarit" signifie ici "template engine". Cas typique ou l'emploi du Français dans un contexte technique n'ajoute que de la confusion...

On est peut-être pas beaucoup, mais on fait plus de bruit que les autres, et certains commencent a s'en rendre compte, surtout dans certaines niches.

Je pense en particulier au développeurs indépendants de jeux vidéo, qui voient de plus en plus Linux comme un marcher qui se tiens.

Quelques exemples:

- Sur l'opération "Humble Indie Bundle", presque un quart des revenus sont venu de Linux, presque autant que Mac ( http://www.wolfire.com/humble )

- Wolfire (a l'origine de l'Indie bundle d'ailleurs), a plusieurs articles très engagés pour expliquer en quoi développer pour Linux (et OSX) est bénéfique pour un jeu indie , au delà des seules ventes ( http://blog.wolfire.com/2008/12/why-you-should-support-mac-o(...) )

- Hemisphere, qui a sorti le (super) jeu Osmos entre autre sur Linux, a plusieurs articles très intéressants sur leur expérience de portage ( parfois dur pour la plateforme, mais juste), et leur conclusion est que ca valait le coup : http://www.hemispheregames.com/2010/06/23/linux-the-numbers/

- De plus en plus de jeux indie sortent sous Linux ( cf Amnesia cette semaine : http://linuxfr.org/~neoshad/30148.html )

C'est pas très français mais c'est du Perceval tout a fait valide.

J'espère que tu as garde un dump du système d'origine quelque part, dans quelques années on se rappellera même plus a quoi ca ressemblait un système proprio de la fin du XXieme siècle...

Complètement d'accord.

J'ai l'habitude de résumer ca comme ca: avec la GPL, le code est libre, avec la BSD, le consommateur du code est libre... En tant que producteur de code, il faut savoir ce que l'on veut...

j'ai envie de répondre "rule 34"

COÏNCIDENCE???

(explication rationnelle 1 : toutes les moules^W geeks , en voyant FB down, se sont précipités pour le troller^W dire sur ./ , et boom )

Ca c'est de la recurtion ou je ne m'y connais pas...

et on saignera aussi tous les grammar nazis, ca leur fera pas de mal...

Quand on aura prit le pouvoir, on vous enverra tous dans des camps ou les portes ne s'ouvrent que de la main gauche!

C'est vrai que c'est pas vraiment que ce n'est pas possible de lui expliquer, c'est que même en ayant pris le temps de t'écouter et ayant compris ton argumentaire, a la fin de la journée, 95% de ce quidam voudra quand même voir ces vidéos Flash...

Dans le domaine du jeu vidéo, on dit "production" pour designer la période ou on produit le jeu, pas la période ou le jeu est fini...

Merci pour les feedbacks.

C'est marrant j'ai eu des feedbacks contradictoires sur les graphismes, qui sont de toute facon provisoirs. J'ai pas mal d'idees de gameplays autour de cette mecanique de jeu, mais j'ai vraiment pas envie d'introduire des obstacles sur la trajectoire...

Merci pour ton soutiens :)

Le jeu est effectivement limité, mais je compte bien itérer et en augmenter l'intérêt, raison pour laquelle j'ai release soon (et je compte bien releaser often aussi :) ).

Pour les collisions, j'ai essayé et ca ne fonctionne pas (ou du moins ca ne donne pas le gameplay que je cherche). Les trajectoires des satellites sont telles qu'il est impossible d'éviter les collisions, c'est un élément purement random et le jeu n'a vraiment pas besoin de ca en plus.

Les idées pour l'étendre ne manquent pas, mais demandent des efforts de productions, et il y a manifestement a travailler sur d'autres points avant (en particulier les contrôles :) ).

La dernière fois que j'ai fait un jeu avec Document02, ca n'a pas pose tellement de problème:

http://corpsmoderne.net/reons/reons/LICENSES.txt

(ha merde, j'ai déjà fait du libre, oups!)

La dernière fois (cf mon dernier journal) , la seule chose qui a intéressé les gens c'est la licence et la saleté du code. Je m'en fou d'avoir des feedbacks sur les licences et le code, je suis intéresse par des feedbacks sur le jeu. C'est aussi pourquoi la description est laconique. Si le jeu a besoin d'un pavé explicatif, il y a un problème (et manifestement il y a un problème ;p ) . Maintenant je reconnais que c'est un journal bookmark, c'était plus ou moins annoncée dans le titre.

Ceci dit, je vais probablement ouvrir rapidement le code, parce que contrairement a hier j'ai une vrai raison de le faire: il plante sur certains téléphones, et je ne peux pas reproduire moi même.

(ce sera probablement GPLv3) (je ne suis pas intéressé par une forge)

Quel mot tu comprends pas dans "non" ? :)

Blague a part, j'ai dit que je ne trouvais pas opportun de montrer le code pour le moment, si tu veux qu'on troll de la pertinence de l'open-source pour le cas particulier du jeu video, je suis ton homme :)

Ils devraient pas répondre. Quand t'utilise perl tu la fermes bien comme il faut et pis c'est tout.

A zut on est pas dredi? -> []

C’est quoi cette idée stupide d’imposer législativement une technologie spécifique ?

Je sais bien que les rôles fondamentaux de l'État sont en voie d'extinction de nos jours dans nos sociétés, mais tout de même, l'un de ceux-ci est de protéger ces citoyens de l'agression et de la prédation.

C'est le rôle de l'État de s'assurer qu'il n'y a pas (trop) d'énergumènes a rouler sans permis, parce que c'est dangereux pour moi.

Des l'or, il ne me semble pas délirant que l'État s'assure que les organismes qui opèrent des transactions bancaires le fasse avec une sécurité minimale garantie, dans l'intérêt de tous les citoyens qui vont utiliser ce système.

Ensuite, on sait très bien qu'en crypto, on ne peut pas se contenter de caractéristiques générales pour garantir un niveau de sécurité (comme la taille des clefs). Si tu dis "clefs de 128 bits minimum", tu vas avoir des boulets pour chiffrer en 256bits, mais en RSA (ce qui doit tomber en quelques secondes avec la puissance d'un téléphone portable). Et même si tu donnes des tailles de clefs précises pour le chiffrement symétrique et asymétrique, tu auras toujours des malins pour t'inventer le chiffrement du siècle: le double XOR en 4096 bits!!!! incassable ma p'tite dame!

Et et et et même si tu impose un algo particulier et sérieux, genre Blowfish, t'es pas sorti d'affaire, parce que le Blowfish implémenté par le petit Kevin en turbo pascal, je suis certain que même ma petite sœur elle peut le casser ( ouai elle déchire en timing attack ma petite sœur... ).

Tout ca pour dire que ca a du sens pour un etat de valider quels sont les moyens legaux pour procéder a des échanges bancaire, après c'est certain que de choisir CET algo, c'etait un gros epic fail...

Sans vouloir te décourager, je cherchais quelque chose de similaire et je n'ai jamais trouvé (mon problème s'est résolu autrement) :

http://linuxfr.org/~case42/29166.html

Ben, c'est a dire que quand on vient faire l'éloge de Gmail face a Thunderbird dans les commentaires d'un article sur Thunderbird, alors qu'on a dit dans une tout premier commentaire, je cite : "Ça fait des années que je n'ai plus utilisé Thunderbird", forcement on perd un peu en crédibilité, et donc oui on des chances de se faire moinser, ca me semble relativement logique.

Les tests ont été beaucoup évoqués, mais pas le TDD. Je ne te conseillerais pas un langage en particulier, mais je pense qu'essayer le test-driven development pourrais t'aider fortement.

Écris tes tests avant d'écrire ton code! Écrire les tests équivaut a écrire une spec de ton code, mais une spec qui vérifie ton code!

Tu veux une nouvelle fonctionnalité dans ton programme? Tu écris un ou des tests. Puis tu code jusqu'a ce que tous les tests passent. Tu ne peux pas oublier un bout par inattention, car tu as les tests pour te le rappeler. Si tu as oublier d'écrire des tests pour certaines parties, tu les écris, puis tu ecris le code pour que les tests passent. Si tu trouve un bug, tu ecris un test qui le verifie, puis tu ecris le code qui corrige le bug. Le bug ne peut jamais revenir, ou tu le sauras grace au test. C'est une super méthode anti-étourderie, et ca produit un code super robuste.

http://en.wikipedia.org/wiki/Test-driven_development

my 2 cents.

Moi je pense que l'incompréhension vient de ce que tu ne considère pas les contraintes d'utilisations de ces projets: la plupart de ces projs sont prévus pour être hébergés sur des sites web mutualisés, ou le processus Apache (et donc PHP) n'a pas le droit d'écrire sur le disque dur, mais a par contre le droit d'accéder a une base de donnée. Dans ce genre de situation, sqlite (ou un fichier plat, ou xml, ou json, ou quoi que ce soit) n'est juste pas une option. Et donc même si tu n'as besoin que d'écrire un minimum de choses, si le seul endroit ou on te laisse écrire c'est en base, et bien tu es bien obligé d'utiliser ce moyen la et pas un autre.

Mon eeepc 701 a 3 ans, il est has-been sous tous rapport et je ne l'utilise plus, ce n'est donc pas du tout contradictoire.

J'allais dire: recycle ton vieux portable en serveur. Inutile d'acheter une machine: quand tu change ton vieux portable obsolète pour un tout neuf, tu recycle ton vieux portable en serveur et basta. Cout 0.