パパフラクス a écrit 187 commentaires

Pareil pour moi!
Je ne serais pas un cas isolé alors.

Systématiquement renvoyé à l'expéditeur et:
- je n'ai pas d'avis de passage
- le colis ne semble même pas arrivé a la poste: au bout d'un moment je vais voir quand même en comptant arriver dans la période des 15 jours.

S'ils arrivent à retrouver l'expéditeur, pourquoi ils arrivent pas a me trouver, le reste de mon courrier (factures, impôts, etc.) arrive bien.

Ou alors ils on trouvé un système super rentable, ou on fait payer le client pour que le colis reste ou il est.

Bref après avoir renoncé au contenu de qq colis, j'ai renoncé à me faire livré, mais c'est chi*** quand même.

T'as oublié colleur d'affiche !

D'ailleur le document pointé par svenfoo utilise la même modélisation,
et d'après ce que j'ai vu rapidement, utilise une méthode géométrique pour résoudre les contraintes

http://www.geometrictools.com/Documentation/MaximumAreaAspec(...)

En représentant le rectangle par (x, y, w), ou (x, y) est le point de base du rectangle, et w la largeur du rectangle, on obtient un ensemble de contraintes et une valeur à maximiser: w*w

Comme maximiser w*w (fonction strictement croissante) revient a maximiser w, le problèmes est un problème de programmation linéaire.

On doit donc pouvoir le résoudre avec l'algorithme du simplex.
Ca doit se trouver une lib qui implémente cet algo, non?

Bon, ça fait pas mal de temps que j'ai pas fait ce genre de choses, donc il y a peut-être des erreurs dans mon raisonnement...

J'aime le libre et j'aime Java et je suis cher ;)

Java n'est sûrement pas la panacée, mais ça reste satisfaisant, et je suis raisonnablement productif avec.

Par contre je ne comprends pas la course au "tout en C", qui pour moi est un des pires langage (non en fait le pire c'est C++ ;)
Avant de partir sur du C, j'envisagerai déjà Python, Ocaml, Ruby, et même Smalltalk, Haskell, ou ObjectiveC.

Pour arrêter de troller, j'en reviens au post:
ton point de vue est intéressant, mais je trouve que développer des interfaces graphique, ou ne pas maîtriser les flux extérieurs ça peut être intéressant aussi, si on a la liberté de proposer des solution adéquates.

En fait j'aime bien les contraintes du monde réel qui font sortir le développeur de son petit monde idéal. Par exemple développer une appli web de qualité est tout sauf facile.

Satisfaire des critères de qualité dans un temps limité, au seins d'une équipe, est aussi qqchose d'interessant (et enrichissant) pour un développeur, quelque soit l'appli en fait.

Déjà avec au minimum le nom de la boîte, un éventuel lecteur intéressé pourrait postuler.

Tu as essayé http://fr.lolix.org/ par exemple?

Sinon il faut peut-être aller les chercher à la sortie des écoles/université,
quand il sont encore frais.

Le développeur Java est très prisé des SSII, et une fois rentré dans ce monde, il doit perdre toutes ses illusions je suppose ;)

Excact.
Si j'en crois l'idée du poste, l'exmple avec matrice de flottant et matrice d'entier serait plus parlant.

Au passage:
http://en.wikibooks.org/wiki/Haskell/Class_declarations

Le +. c'est vrai que c'est pas terrible, mais on s'y fait vite, une fois le typage compris.

Par contre de ce coté, je préfère nettement les classes de types à la Haskell. C'est plus joli (subjectif !), mais surtour ça permet un polymorphisme plus large: je vois ça un peu comme une définition d'interface, qu'on peut utiliser après comme type.

J'avais déjà regardé wash, les autres je ne connaissait pas.

En fait j'ai pas de réel besoin dans ce domaine, c'est plus pour le fun ;)
Mais j'aime de plus en plus Haskell, je trouve que ça combine plutôt bien l'expressivité et le typage statique.

De plus comme je lisais récemment, les langages fonctionnels purs sont des bons candidats pour tirer partie des multi-coeurs/processeurs.

Mais on s'éloigne des framework web.

Effectivement RoR, Django et Turbogears sont sexy, personnellement, j'ai un peu peur de ce que certains dev pourraient écrire avec Ruby, et l'enfer de la maintenance qui pourrait en découler. J'ai une tendance naturelle vers la simplicité, et Ruby est tout sauf un langage simple, il n'y a qu'a regarder sa grammaire pour s'en convaincre.

Je suppose que tu voulais parler de Django http://www.djangoproject.com/

Sinon mon avis rapide:
- JEE c'est effectivement lourd, mais une fois qu'on maîtrise, on peut coder quasiment sans réfléchir (ce qui n'est pas drôle en fait...) :
Le problème c'est que les API sont souvent "over engineered", c'est concu pour résoudre tous les problèmes, y compris ceux dont la chance de rencontre est quasi nulle.
Une petite parenthèse, Spring simplifie plutôt les chose dans ce domaine, au contraire de ce que tu semble penser en employant le terme "joyeuseté"

- Zope: j'ai essayé très brièvement, et ça ne m'a pas vraiment séduit,
mais je regarderai la video dès que je serai de retour chez moi ;)

- Django, RoR, et Turbogears sont tous les trois de très bons frameworks. J'ai une préférence pour Turbogears et Django, principalement pour des raison de lisibilité du code (AMA pour un développement en équipe Python est un meilleur choix que Ruby au niveau lisibilité), mais surtout pour la documentation.

Fieew! Impressionant ;)

J'adore Smalltalk, et Seaside est effectivement très impressionant.
Par contre, et ce sont de vrai questions:
- Qu'est-ce que tu utilises pour la persistance (l'image c'est bof non ?)
- Une image, c'est pas évident pour le déploiement?
- Comment ça se passe le travail en équipe et la gestion de configuration avec Squeak.
- C'est quoi gemstone ?

Sinon, moi j'aimerai bien un framework web en Haskell.

Un autre truc qui me parait interessant, comme tu le souligne, c'est de pouvoir modifier les objets à la volée.
Un peu a la manière de pata pata http://patapata.sourceforge.net/

Pour ça, je suis persuadé que les langages à base de prototypes sont intéressants (par exemple Io http://www.iolanguage.com/ )

En tant qu'ex slacker maintenant sous arch, je cherche une distribution un peu moins geek que arch, mais restant simple et légère,
pour éventuellement l'installer chez des amis tout en gardant mes repères, car on ne manquera sans doute pas de me consulter en cas de problème.

Bof.
Depuis que j'habite Paris j'ai l'impression que le nombre
d'étoile a été divisé par au moins 10.

Alors voire une comète, je crois que j'ai aucune chance.

Est-ce que quelqu'un a déjà essayé zenwalk?
Je suis intéressé par un retour.

Qu'est-ce que ça apporte par rapport à une Slack?

http://www.zenwalk.org/

Ou en Géorgien (http://fr.wikipedia.org/wiki/G%C3%A9orgien)
J'avais essayé dans Eclipse il y a un certain temps et ça marche,
pas mal pour rendre son code illisible ;)

Je suis d'accord, ça apporte pas grand chose, pour le code,
c'est d'ailleurs pour ça que je ne le fais pas.

Par contre pour les chaînes de caractères c'est indispensable.

pas de catch d'exception vide
Ca me parait évident, mais c'est bon de le rappeler.

un seul return par fonction,
Ca par contre je trouve ça débile: ca augmente inutilement la complexité cyclomatique du code, et donc diminue la lisibilité

J'aime bien avoir des tests de gardes au début de mes méthodes pour éliminer les cas spéciaux ou triviaux, et retourner au plus vite, et ensuitre avoir le code du cas général.

Le même code écrit avec un seul return contient plus de niveau d'intentation, et est plus long: pour moi c'est moins bon.

Au fait, une source inépuisable pour les développeurs

http://c2.com/cgi/wiki

Et aussi comme cité plus haut, Martin Fowler distille de sages conseille et n'est pas avare de son expérience

http://www.martinfowler.com/

Mieux vaut toujours garder l'anglais comme langue pour nommer les variables, les fonctions...

Oui sauf qu'en France les spec sont souvent écrites en Français, et les gens parlent entre eux en Français.
Traduire en anglais introduit une ambiguïté, et en plus en France on est pas très fort en anglais, et je t'assure que ça pose problème, entre ceux qui comprenne rien, et ceux qui introduise des traduction toute pourrie.


- Quand on fait du code libre, c'est bien de pouvoir le diffuser au monde et pas seulement aux francophones.

Tout à fait d'accord, et là je trouve que ça se justifie pleinement d'investir dans une conception en anglais. AMA il faut a tout pris éviter de concevoir en français pour traduire ensuite, il faut tout faire en anglais, dès la conception fonctionnelle.

- En anglais, y'a pas d'accents, et les accents dans les noms de variable, ça suxxx.
Les langages qui ne gère pas les accents, ça suxxx.
Bon, dans la réalité je n'utilise pas les accents dans le code, mais avec un langage moderne (Python, Java) ça ne pose aucun problème. D'ailleurs c'est un indice pour la gestion de l'internationalisation. Par exemple Ruby suxxx, à ce niveau là.



- Ca fait réviser l'anglais.
C'est bien ce que je dis, beaucoup de gens ne maîtrisent pas l'anglais, et sur un projet, ça peut faire mal.

Et puis pas mélanger les langues. Je me souviens d'un projet de fac où j'ai fait tout une partie en angliche, et les autres tous en franchiche. Et bah c'était pas joli joli.

Je suis d'accord, c'est moche, mais parfois c'est un moindre mal.
Dans le cas de spec en français, je garde le vocabulaire métier en français, et le reste en anglais et je les compose à l'anglaise.

Par exemple pour une méthode qui crée une facture, je l'appelle
createFacture, car tout le monde parle de "facture" quand on discute, et pas de "invoice"
Et de toute façon, il y a un certain nombre de dev qui ne connaissent pas le mot "invoice" et mettront "facture" dans leur code

A mon avis, le build automatique après le commit est plus intéressant.
Ca permet d'avoir un retour rapide pour le développeur sur ce qu'il vient de commiter (oui encore cet anglicisme ;) et ces eventuels oublis.

Par exemple sur un projet on utilisait CruiseControl, qui compilait et executait les test unitaire après chaque commit, et envoyait un rapport aux developpeurs, c'est super utile, mais ça demande un peu d'éducation: j'ai vu des développeur filtrer les mail de rapports directement à la poubelle...

Et aussi, faire passer les test unitaire doit être une priorité

Les test unitaire, ça me parait indispensable, mais c'est étonnamment peu répandu. Ils y en a même pour prétendre que c'est une perte de temps

Par contre ce qui est un vrai problème c'est d'écrire des test unitaires pour de l'existant qui n'en comporte pas: c'est quasi impossible, car le code n'est en général pas écrit de manière à être testable, et il est impossible de le modifier sans casser ce qui marche (car en fait on ne sait pas ce qui marche ou pas!!)

Je suis bien d'accord.
En ce moment je suis contraint à utiliser wasd, qui n'est autre qu'un Eclipse customisé.

Tout a été francisé, ça m'a fait perdre pas mal de temps à chercher dans les menus et les préférences. Ah oui, parce qu'il ont modifié les raccourcis clavier aussi...

Sans parler de la débilité de certaines traductions:
par exemple le "go into" traduit par "suivant", qui ne veut rien dire,
ou bien "propager les modification" pour "refactor"...

Commettre?

D'accord je sors!
Quoique parfois on peux se demander ;)

Cela dit, l'"outils linguistique" de google donne cette traduction, mais bon c'est pas forcément une référence

A mon avis le sens est plutôt confier (au système de gestion de versions)

s/voix/voie

Ne pas oublier non plus que les compilateurs sont des générateurs de code !!!
+1

Alors, on les génère ou pas ?
J'ai dis "éviter", pas interdire ;)

En fait je me pose pas mal de question la dessus.

A mon avis, si le langage permet de réutiliser le code, ou d'écrire du code générique pour le problème rencontré, il faut privilégier cette voix

En tout cas la génération de code pose problème pour les fichier qu'on doit retoucher ensuite:
- écrasement des modifs par la génération suivante
- les dév on peur de toucher le code généré
- générateur pas à jour -> procédure manuelle pour palier le problème.
Car bien souvent un générateur est complexe, et personne ne veux/peux le maintenir si la personne qui l'a mis en place n'est plus là.

Plus généralement je me pose aussi la question de l'utilisation des outils de "programmation visuelle".
J'ai plutôt tendance à avoir confiance dans une approche entièrement textuelle: le code fais foi,
mais j'arrive pas trop à me justifier la dessus.

En fait l'important est surtout que tout le monde utilise un éditeur reglé de la même façon pour utiliser soit les tabs, soit les espaces, afin d'éviter les faux conflits.

Il me semble que je m'était fait pincé aussi par un collègue pour une autre raison, mais je ne me souviens plus...
En tout cas c'est sûr, il ne faut pas! ;)