Guillaume Camera a écrit 45 commentaires

Ploplop,

Bravo pour l'initiative, mais je ne serais que trop rejoindre les commentaires qui ont été faits plus haut. La notation choisie est bien sur plus facile à gérer , et tout de suite fonctionnel, mais proposer ça à des débutants, j'y crois moyen moins.

Lorsque j'ai été à l'EPITA, on nous a pris un langage algo maison, mais bien foutu. Alors , oui, nos premières lignes de codes on les a écrit sur une feuille de papier, mais la syntaxe du langage invite vraiment à comprendre les bases de manière claire. Un doctorant qui passait par là et merveilleux professeur à ses heures perdus, a eu la bonne initiative de vouloir implémenter un interpréteur du langage pour que les élèves aient d'avantage envie de le pratiquer et de s'exercer sur machine.

Je crois que très franchement, le projet a été plus ou moins abandonné, mais je pense plus par faute de temps et d'utilisation concrète. Cela dit, ce projet mériterait franchement une mise en avant

https://code.google.com/p/epi-algo/source/browse/?r=8 (peut-être y a t'il des sources plus récente)

C'est du CamL, l'outil est merveilleusement bien choisi (oui c'est vendredi \o/) :)

Portable, performant et surtout productif

Je sais qu'on est vendredi , mais quand même !

Vu ton profil et ton expérience, pourquoi ne changes-tu pas tout simplement d'entreprise ? Ou en créer une ?

Je suis bien d'accord. Si ton boulot te plaît, pourquoi ne pas changer de contexte ? Pourquoi ne pas demander à voir ton propre projet aussi ? Surtout si tu as l'expérience et le talent, c'est motivant de s'occuper de son propre bébé, et pourquoi pas de son équipe (Je sais pas où tu en es dans ta carrière…). Mais si c'est qu'une histoire de "Mon chef me pète les b****" ça vaut peut-être pas le coup de changer de domaine.

expliquer avec vos mots le nouveau paradigme de programmation Evenja

Une blague sans poneys !

Ah oui, y'a marqué "sold out" en effet. Autant pour moi.

c'est complètement encrypté

Hein ?

Tu voulais dire: "chiffré" ?

Sinon y'a le kimsufi à 3 balles H.T. , ça peut pas te satisfaire ? Depuis que j'ai la fibre chez moi(oui, je me la pète grave), je pense à ça pour faire mes backups et arrêter ma dediboite à 40balles/mois

je n'ai JAMAIS vu un manager/dirigeant prendre en compte des cout ou à la fin du mois il n'y a pas une facture avec TVA.

Il est vrai que c'est assez rare, mais une fois la situation vécue ( trois mois de formation pour un nouvel arrivant, des vagues de départs des "bons".), si le mec est pas débile, il arrive à remettre en question son management. Un projet sur lequel il est agréable de travailler, c'est bon pour le morale et la productivité.

Mais oui c'est regrettable que ça se passe souvent à la marge net de la facture de la fin du mois.

Oui, du "vite fait mal fait" c'est le quotidien de plus d'un développeur, mais n'oublions pas que limiter sa créativité et du coup la qualité de son travail, ça a des coûts câchés. Situation vécu, certains étaient étonnés que je passe plus d'un jour à documenter une fonctionnalité. Ouais sauf qu'une doc mal faite ça sert à que dalle, on comprend rien et c'est une perte de temps pour celui qui passe après.

Je ne pense pas qu'il faille (ça se dit ça ?) être fataliste à ce sujet et au contraire, se battre le plus possible pour qu'on nous oblige pas à bacler notre taf. Ca me revolte vraiment de passer sur du code dégueulasse et qu'on me dise: "Non mais tu comprends il fallait que ça sorte." Ouais, sauf que maintenant il me faut trois semaines pour comprendre trois fonctions imbriquées les une dans les autres , pouvoir décorèler unitairement les fonction pour enfin, soit fixer un bug soit rajouter une feature. Alors qu'à l'époque ça aurait prit deux jours. Je parle même pas de la fatigue que ça peut entraîner et de la démotivation, qui peuvent jouer sur le temps de sortie d'un produit.

Bon bref, je m'arrête là, mais tout ça pour vous dire, que quand on vous dit d'aller vite et qu'il faut que ça sorte, battez vous pour obtenir du rabe si vous êtes limite et au pire, un délai après la sortie pour bien ré-architecturer et bien documenter ce que vous avez dégueulé en une demi journée.

Cela dit, ça ne doit pas vous empêcher de contribuer activement au libre \o/ (ce que je ne fais pas parce que je suis pas trop créatif et et trop mauvais)

Ouais on va faire ça ! Le boulot de correction de la traduction, ça sera déjà une grande étape ! Est-ce que je passe directe de la version 0.4.1 à 1.0 ? Je mets quoi dans le changelog ? 1.0.0 => Final Release \o/

Querying all MyModel with a MyOtherObject has MyOtherOtherObject has a name attribute is ‘foo’.

Le V.O. : Demander tous les objets de la classe MyModel qui ont pour un attribut un MyOtherObject qui ont eu même pour attribut un myOtherOtherModel.

Alors, qu'est-ce que ça veut dire ?

class MyModel(DeclarativeBase):
      awesome_attr = MyOtherModel()

et

class MyOtherModel()
      other_attr = MyOtherOtherModel()

En gros j'essaye juste de dire qu'on peut faire des recherches par rapport aux attributs des attributs d'un objet.

The meaning of use a dictionary is to facilitate access to data

De ce que je me souviens la V.O. disait un truc comme ça : "L'intérêt d'utiliser des dictionnaires, c'est qu'ils sont utilisables pour les deux parties (client en JavaScript qui reçoit et envoie du Json, Le serveur en python qui peut du coup charge des objets depuis la base avec un dictionnaire)

Dès que j'ai le temps, je me remets sur tes corrections, merci encore, c'est très chouette de ta part. Pour te remercier, une nimage[Vue la source, je pense que cette image est libre de droit mais je n'ayant pas vu d'indication de licence, je m'autorise à la linker—Si je n'ai pas le droit n'hésitez pas à flinguer la dernière phrase, merci au modo !]

Me suis permis de mettre ton pseudo dans le commit de correction, mais si ça te gêne un petit commit --amend et un push -f résoudront rapidement le problème. Redis-moi.

Merci de ton aide encore :)

Ah Cool ! Merci pour tout ce retour, je corrige ça de suite.

pour des raisons de maintenance et/ou de performance.

Je trouve personnellement que SQLAlchemy fournit toutes les alternatives afin d'optimiser les requêtes (pré-chargement de certaines relations , rapatriement des scalaires seuls, etc) et de ne pas perdre en lisibilité en ayant des très bonnes performances.

Sûrement cette là: «Nous (les gens qui enseignent du python dans le secondaire)».

"Bon maintenant les enfants, dans ce cours sur l'apprentissage de ce merveilleux outils qu'est le tournevis, je vais vous apprendre à faire la cuisine avec !"

Je connaissais pas trop les méthodes d'accélération du code. C'est cool de pouvoir garder l'expressivité de Python et d'avoir un code qui trace ! En tout cas cas ça donne envie d'aller fouiller plus loin, ce que je ferai très certainement bientôt (oui c'est toujours ce qu'on dit quand on le fera surement jamais, mais sait-on ..jamais !).

Bravo pour le boulot et merci pour le journal , ça donne vraiment envie d'essayer ! Bon courage pour la suite.

python puisse devenir statiquement typé

Je comprend tout à fait le besoin d'enseigner le typage mais il ne faut pas négliger qu'il n y a pas que ça dans la vraie vie.

Dans ce cas, pourquoi ne pas enseigner un langage qui parait vraiment plus adapter à la pédagogie et qui répondra fondamentalement plus à votre (les gens qui enseignent du python dans le secondaire) besoin ? Je pense notamment à Caml, qui justement est fortement typé est convient parfaitement, à mon sens, à l'apprentissage. (Hummm récursivité !)

Python fait partie de ces langages dynamiques, alors s'il vous plaît, laissons le dynamique ! Encore une fois je comprend largement le besoin de la pédagogie, mais dans ce cas là, il vaudrait mieux faire rentrer Python dans l'apprentissage d'un langage dynamique. Surtout les notions qui peuvent aller avec (Duck typing etc).

Après il y a surement des contraintes qui m'échappent.

L'amour du travail bien fait, malheureusement ça marche pas dans toutes les boites. On ne nous laisse pas le temps de faire comme on voudrait, parce qu'"il faut que ça sorte". Et on en arrive à la situation que tu décris. "Embaucher pour la mission, et qu'est-ce qu'on fait après ?", "La qualité du code ? On s'en foo ça marche !"

On cherche un peu tous le job de nos rêves finalement… Est-ce qu'un poste dans une vraie R&D ne te conviendrait pas ? Il y a des boites qui sont à cheval entre la recherche et le développement de produit. Les défis techniques sont intéressants, et bien souvent, la notion de long terme est bien présente ce qui ne laisse aucune place "à la va vite". Peut-être que tu peux rechercher dans cette direction ?

As-tu pensé à contacter des cabinets de recrutement ? La piste peut semblé douteuse, mais si le cabinet est sérieux, il prendra le temps de noter tes critères et de te contacter lorsqu'ils trouveront quelque chose qui pourrait te convenir (C'est dans leur intérêt et le tiens de toute façon).

Tu te fous du monde, tu n'as même pas lu l'article que tu pointes toi-même

Bien sûr que si.

"le Système solaire devait se déplacer vers le centre de la collision, la vie sur Terre pourrait se terminer de façon catastrophique"

Euh, personne ne va essayer de dévier un astéroïde de 10m de diamètre.

L'astéroïde Apophis fait plutôt 325m. Certes, on a vu récemment qu'il nous tombera pas sur la poire d'ici 2036.

Ça risque d'éparpiller un peu les étoiles

http://fr.wikipedia.org/wiki/Collision_entre_Androm%C3%A8de_et_la_Voie_lact%C3%A9e

"Quand la collision se produira, les deux galaxies vont vraisemblablement :
* fusionner….
…
* se détruire
"

Et puis, écarte le soleil de la terre, on verra sur il va rester beaucoup de vie après.

Et d'après Wikipédia, c'est dans 4 milliards d'années

J'avais voulu mettre 2 milliards, my bad. Les dernières conférences que j'ai faite, il était plutôt évoqué 2 milliards que 4.

Sauf que…

Un astéroïde de 50m de diamètre est passé à 30000 km de la terre le soir même de la tombée des météorite. Comme ça, 30000 km ça peut paraitre loin, mais en vrai à l'échelle de l'univers proche (je parle même pas de l'univers lointain), c'est quand même juste.

Même si on détecte un astéroide un an à l'avance qui va nous tomber sur le pif , c'est même pas sur qu'on est les moyens de le faire dévier en étant à 100% sûr.

Cela dit je suis pas expert en astrophysique ni même en défense spatiale, c'est pour ça que je vais me rendre à cette merveilleuse conférence http://www.grandpublic.obspm.fr/Asteroides-Terre-en-danger. Cela me permettra d'en savoir plus et de venir troller sur linuxfr sur l'avenir de notre planète qui de toute façon sera complément foutu quand la galaxie d'andromède rentretra en collision avec la voie lactée (Paniquez pas, c'est dans 2,5millions d'année.)

Hello !

Je voulais juste t'encourager dans ta démarche et te dire qu'avant tout un logiciel est conçu pour une utilisation donc un utilisateur (y a le plaisir du code œuf corse mais ça …).

Comme ça l'a été dit de nombreuses fois, concentre toi sur les fonctionnalités que tu as déjà et corriges les bugs bloquants. Release une version alpha, et vois les premiers retours que tu as. Tu avanceras les fonctionnalités au fil de l'eau.

Là où ça peut-être intéressant aussi, c'est la doc utilisateur. Si ton logiciel, c'est le meilleur du monde, mais que y'a pas de doc pour s'en servir, personne l'utilisera et tu n'auras aucun retour.

Une fois qu'il n y a plus de bugs bloquants et des fonctionnalités minimum sont en places, diffuse ta doc et mets en place des moyens pour que les utilisateurs te remontent les problèmes (fichier AUTHORS dans le code, bug tracker etc…). Et pour ça, ça faudrait peut-être le coup de passer à git et d'héberger les sources sur Github. Ainsi tu auras tous les outils d'évolution de projet et tes contributeurs pourront te soumettre facilement des patchs.

Pour résumer et dans l'ordre : Résous les bugs bloquants, fais de la bonne doc pour tes utilisateurs, et bugs trackers ! Le reste viendra avec le temps :)

Bon courage en tout cas !

Mais y'a bug et bug.

Le premier c'est bien un bug. Le deuxième, ce n'est pas un bug, c'est une feature !

c'est étrange comme initiative tout de même

Je trouve plutôt que c'est l'occasion de pas oublier que la distro qui te sert au quotidien, y a des mecs qu'ont passé du temps dessus pour coder, empaqueter, documenter, maintenir etc.

Et c'est une occasion de se le rappeler et d'encourager ceux qui nous fournissent des outils dont on ne peut plus se passer aujourd'hui et tout ça sous licence libre.

Logiciel Libre, je t'aime !

Stoo.

Salut,

Ca à l'air cool ton petit moteur :)

Par contre une chose m'interpelle

les JS et les CSS sont pré compressés en gzip. nginx utilise directement les fichiers pré compressés.

Est-ce que ça veut dire que ton serveur oueb doit supporter le pré-compressage ? Si oui, Apache est-il capable de le faire (je devrait RTFM, mais c'est vendredi, la flemme.) ? Dans le cas opposé y'a t'il une configuration du moteur qui permette de s'en passer ?

tu perds en fonctionnalité : adieu les Threads.

Je suis pas encore extremement compétent avec SQLAlchemy, mais il me semble que si l'on décore le sessionmaker avec sqlalchem.orm.scoped_session on a quelque chose qui tient le route

"the ScopedSession provides a quick and relatively simple (if one is familiar with thread-local storage) way of providing a single, global object in an application that is safe to be called upon from multiple threads."

D'ailleurs je l'utilise dans une application threadée au boulot et ça marche très bien.

Après, je suis pas encore très au point avec SQLAlchemy, il y a encore des choses qui m'échappent, je suis pas contre quelques explications :)