Il n'est dit nulle part qu'il est interdit de préfixer les variables pour indiquer leur scope. Le caractère '_' n'est pas interdit (seulement en premier caractère). Je commence bien par une minuscule.
Je suis la règle suivante :
- variable statique : s_xxxYyy
- variable membre : m_xxxYyy
- paramètre de méthode : p_xxxYyy
- variable locale : xxxYyy
Après c'est comme toute convention, on aime ou pas. Ça l'avantage d'être clair et d'éviter tout masquage involontaire (et donc de ne pas nécessiter le this).
Tu as une classe Java, appelons-là Plop.
Bon.
Elle a une propriété private String m_toto; dans un coin.
Après tout pourquoi pas, hein ?
Elle a aussi deux méthodes :
- public String getToto() { return m_toto; }
- public void setToto(String p_toto) { m_toto = p_toto; }
Voilà, tu as un Bean. C'est tout bêtement une classe Java qui respecte la règle de nommage des getters/setters (et sont publics) :
- getProperty() pour obtenir la valeur ;
- setProperty() pour la renseigner.
Il n'est même pas nécessaire d'avoir les deux.
Après si tu parles d'EJB (Enterprise Java Bean) je passe le relai. J'y ai touché (EJB2) et plus jamais ça.
Par contre, pourquoi JoNaS ? Un bête Tomcat suffirait amplement à mon avis...
Sauf que c'est Open Source.
Dans le pire des cas tu payes quelqu'un pour faire les modifs dont tu as besoin.
Oui, en théorie.
En pratique, tu vas évaluer le coût de maintenance par rapport à un changement de techno. S'il existe d'autres bibliothèques assez proches, ce sera sans doute le choix retenu. Mais il faudra bien faire l'intégration. Sinon, tu vas garder la vieille version en ajustant pour que ça marche (bugfix only), jusqu'à atteindre le moment où il devient plus avantageux de tout réécrire voire de partir sur une techno différente que de continuer à boucher les trous.
Dans le premier cas, c'est une modif qui n'est pas prévue dans le planning initial. Dans le second cas, ça revient à faire du dev interne (sauf qu'il n'était pas prévu non plus).
Si c'est un développement interne, les modifications sont celles requises uniquement par le projet (pas de retard à cause d'un développement dont on n'a pas besoin) et sont prévues dans le planning.
Bref, tout recoder est stupide, mais utiliser toutes les bibliothèques disponibles parce que saybien est tout aussi suicidaire.
<mavie>
On utilise pas mal de bibliothèques Apache, et pour le moment ça va plutôt bien.
Mais pour l'interface d'admin, on était partis il y a 5 ans sur Luxor (traducteur XUL -> Swing) pour que des personnes ne connaissant pas Java puissent modifier facilement les formulaires. XUL semblait prometteur à l'époque, et ce choix aurait pu marcher.
Mais Luxor est mort et n'a aucun remplaçant. Le maintenir est hors de question (1. ce n'est pas notre domaine 2. on n'a pas assez de personnes 3. qui paye ?). On reste donc avec un truc qui marche mais est trop basique. Du coup, on va certainement tout refaire en changeant complètement de techno.
</mavie>
Pour moi, ça l'est car ça permet d'envisager les choses sous un autre angle. L'une des difficultés qu'on rencontre généralement en commençant la programmation fonctionnelle, c'est qu'on a l'habitude de penser en impératif.
Il me semble important d'être capable d'aborder un problème de différentes façons.
Ex: traitement de gros volumes de données à répartir sur un grand nombre de machines. Google a "inventé" le MapReduce qui décompose un algorithme en deux fonctions et est naturellement parallélisable. Leur implémentation est en C++, mais le concept est directement inspiré des fonctions map() et reduce() communes en programmation fonctionnelle.
un bon programmeur java fera appel à un maximum de bibliothèques existantes [...], mais bon je n'en vois pas tant que ça
Le problème de cette approche est que tu deviens dépendant d'un projet externe, et donc des décisions prises par ce projet. Que faire s'il est abandonné ? Si la nouvelle version (nécessaire pour supporter la nouvelle plateforme par ex.) prend une direction qui rend son utilisation difficile ?
Utiliser une bibliothèque externe, c'est prendre la responsabilité de suivre ses évolutions, tester les nouvelles versions et éventuellement devoir reporter la sortie d'un projet à cause d'incompatibilités.
Bref, il n'y a pas que des avantages et c'est un choix qu'il ne faut pas prendre à la légère.
Là, ils marquent un point : les ressources Java courent les rues, [...].
Malheureusement, les bonnes ressources Java ne courent pas les rues. N'importe qui ayant suivi 3 jours de formation est développeur Java. Sans avoir une culture de développement minimale :
- pointeurs,
- récursivité,
- programmation fonctionelle,
- programmation logique.
De plus en plus de formations au développement commencent directement avec le Java et ne font que ça. C'est une énorme erreur, dommageable pour les personnes formées, leur employeur et le langage lui-même.
Il est simplement regrettable qu'il n'y ait pas moyen de changer globalement le style d'entrées dans les menus car, pour l'utilisateur expérimenté, avoir le nom du logiciel donne plus d'information (au pire l'infobulle rappelle qu'il s'agit d'un traitement de texte ou autre).
Je ne sais pas sous d'autres environnements, mais sous KDE :
Centre de Configuration > Bureau > Tableau de bord > Menu.
On peut choisir Nom uniquement, Nom - Description, Description (Nom) ou Description uniquement.
On peut troller sur l'accessibilité du réglage, mais ça fait un moment que ça existe...
Quoique, rien n'interdit à OOo 3.0 d'utiliser XUL pour l'interface, ni à Sun de créer un moteur XUL digne de ce nom en Java (Luxor étant mort depuis plusieurs années).
C'est mon premier APN, donc je n'ai pas d'autre point de comparaison sur une utilisation longue. Mes parents ont un FZ8 que je trouve trop léger, il ne stabilise pas la main. Mais je n'ai pas pu l'utiliser beaucoup, donc...
J'aime bien la prise en main et l'ergonomie du S5. Les fonctions sont accessibles sans devoir passer par des menus interminables. Et après y avoir goûté, l'écran orientable est un must-have.
L'absence de grand-angle ne me dérange pas, mais ça dépend de ce que chacun veut faire. Il existe un convertisseur.
Après pour la qualité des photos, va voir sur le lien que j'ai donné plus haut. Je suis loin d'être un pro, mais tu pourra te faire une idée. Pour le bruit, je trouve que ça va jusqu'à 400 en conditions 'normales'. De nuit par contre, c'est 200 max. C'est déjà largement mieux que les S2/S3.
Un capteur plus gros (en taille, pas en nombre de pixels) aurait été mieux, mais ça lui permet de combiner compacité et gros zoom. Tu peux regarder le Panasonic FZ50 aussi, mais l'objectif est plus gros (à cause du capteur plus grand).
Le compromis me convient pour le moment. Je ne peux pas te dire 'vas-y coco', ça dépend trop de ce que tu cherches. En tout cas moi je ne regrette pas.
J'ai actuellement un Canon S5-IS. À part le RAW et le fait qu'il soit un peu plus volumineux qu'un compact, il correspond aux autres critères.
Il n'est pas ultra-léger, mais son poids améliore sa stabilité en main.
Les 3 samedis passés je me suis essayé à la photo de nuit au Parc Oriental de Maulévrier et on arrive à des résultats sympas[1] en manuel+trépied. Le mode manuel est très simple d'utilisation.
Je ne sais pas comment fonctionne le Digic III mais il prend autant de temps de post-traitement que le temps d'exposition. Pour 15s d'expo (le maximum), il lui en faut autant pour obtenir l'image finale.
Le développement n'est pas "complètement figé" dès qu'une version majeure sort. Des ajouts sont toujours possibles dans l'API (et il y en a eu de nombreux dans la branche 3.x). Seulement il n'est plus possible de supprimer ou modifier des fonctions de l'API de base.
C'est une contrainte forte, mais je trouve quand même intéressant qu'un logiciel développé pour la X.0 ait l'assurance de continuer à fonctionner jusqu'à la dernière évolution de la branche X ; même si le développement est abandonné. Ça lui donne plus de 'chances' d'être utilisé et repris.
je serais assez surpris qu'il en soit de même pour Qt5 ou KDE5.
J'ai l'impression en tout cas que la branche Qt4 va évoluer plus longtemps que Qt3. Pour preuve, on en est déjà à la 4.3 et la 4.4 se profile alors que la branche 3 s'est arrêté à la 3.3.8...
KDE est environnement de bureau qui vise la meilleure intégration possible. Si c'est pour se retrouver avec la moitié des applis qui ont été portées pour phonon et solid et l'autre moitié non, ça ne fait pas très propre...
D'autre part, la compatibilité binaire doit être assurée pour toute la durée de KDE4 (comme ça a été le cas pour les 2.x et 3.x). Une appli 3.0 fonctionne toujours avec le dernier 3.5.7... Donc passer à la 4.0 en gardant arts (par exemple) ne permet plus de le virer après...
KDE combine des évolutions 'douces' dans une branche (la 3.x aura duré plus de 5,5 ans quand même ; à peu près autant que Gnome 2.0) et des évolutions plus 'brutales' afin de permettre des sauts évolutifs plus importants.
[^] # Re: Saikoi un Bean ?
Posté par Olivier Serve (site web personnel) . En réponse au journal javabean != réseau ?. Évalué à 3.
Je suis la règle suivante :
- variable statique : s_xxxYyy
- variable membre : m_xxxYyy
- paramètre de méthode : p_xxxYyy
- variable locale : xxxYyy
Après c'est comme toute convention, on aime ou pas. Ça l'avantage d'être clair et d'éviter tout masquage involontaire (et donc de ne pas nécessiter le this).
# Saikoi un Bean ?
Posté par Olivier Serve (site web personnel) . En réponse au journal javabean != réseau ?. Évalué à 8.
Bon.
Elle a une propriété private String m_toto; dans un coin.
Après tout pourquoi pas, hein ?
Elle a aussi deux méthodes :
- public String getToto() { return m_toto; }
- public void setToto(String p_toto) { m_toto = p_toto; }
Voilà, tu as un Bean. C'est tout bêtement une classe Java qui respecte la règle de nommage des getters/setters (et sont publics) :
- getProperty() pour obtenir la valeur ;
- setProperty() pour la renseigner.
Il n'est même pas nécessaire d'avoir les deux.
Après si tu parles d'EJB (Enterprise Java Bean) je passe le relai. J'y ai touché (EJB2) et plus jamais ça.
Par contre, pourquoi JoNaS ? Un bête Tomcat suffirait amplement à mon avis...
[^] # Re: normes et bibliothèques dispos
Posté par Olivier Serve (site web personnel) . En réponse au journal Python et les décideurs. Évalué à 4.
Oui, en théorie.
En pratique, tu vas évaluer le coût de maintenance par rapport à un changement de techno. S'il existe d'autres bibliothèques assez proches, ce sera sans doute le choix retenu. Mais il faudra bien faire l'intégration. Sinon, tu vas garder la vieille version en ajustant pour que ça marche (bugfix only), jusqu'à atteindre le moment où il devient plus avantageux de tout réécrire voire de partir sur une techno différente que de continuer à boucher les trous.
Dans le premier cas, c'est une modif qui n'est pas prévue dans le planning initial. Dans le second cas, ça revient à faire du dev interne (sauf qu'il n'était pas prévu non plus).
Si c'est un développement interne, les modifications sont celles requises uniquement par le projet (pas de retard à cause d'un développement dont on n'a pas besoin) et sont prévues dans le planning.
Bref, tout recoder est stupide, mais utiliser toutes les bibliothèques disponibles parce que saybien est tout aussi suicidaire.
<mavie>
On utilise pas mal de bibliothèques Apache, et pour le moment ça va plutôt bien.
Mais pour l'interface d'admin, on était partis il y a 5 ans sur Luxor (traducteur XUL -> Swing) pour que des personnes ne connaissant pas Java puissent modifier facilement les formulaires. XUL semblait prometteur à l'époque, et ce choix aurait pu marcher.
Mais Luxor est mort et n'a aucun remplaçant. Le maintenir est hors de question (1. ce n'est pas notre domaine 2. on n'a pas assez de personnes 3. qui paye ?). On reste donc avec un truc qui marche mais est trop basique. Du coup, on va certainement tout refaire en changeant complètement de techno.
</mavie>
[^] # Re: normes et bibliothèques dispos
Posté par Olivier Serve (site web personnel) . En réponse au journal Python et les décideurs. Évalué à 1.
[^] # Re: Analysons les arguments
Posté par Olivier Serve (site web personnel) . En réponse au journal Python et les décideurs. Évalué à 3.
Il me semble important d'être capable d'aborder un problème de différentes façons.
Ex: traitement de gros volumes de données à répartir sur un grand nombre de machines. Google a "inventé" le MapReduce qui décompose un algorithme en deux fonctions et est naturellement parallélisable. Leur implémentation est en C++, mais le concept est directement inspiré des fonctions map() et reduce() communes en programmation fonctionnelle.
[^] # Re: normes et bibliothèques dispos
Posté par Olivier Serve (site web personnel) . En réponse au journal Python et les décideurs. Évalué à 2.
Le problème de cette approche est que tu deviens dépendant d'un projet externe, et donc des décisions prises par ce projet. Que faire s'il est abandonné ? Si la nouvelle version (nécessaire pour supporter la nouvelle plateforme par ex.) prend une direction qui rend son utilisation difficile ?
Utiliser une bibliothèque externe, c'est prendre la responsabilité de suivre ses évolutions, tester les nouvelles versions et éventuellement devoir reporter la sortie d'un projet à cause d'incompatibilités.
Bref, il n'y a pas que des avantages et c'est un choix qu'il ne faut pas prendre à la légère.
[^] # Re: Analysons les arguments
Posté par Olivier Serve (site web personnel) . En réponse au journal Python et les décideurs. Évalué à 5.
Malheureusement, les bonnes ressources Java ne courent pas les rues. N'importe qui ayant suivi 3 jours de formation est développeur Java. Sans avoir une culture de développement minimale :
- pointeurs,
- récursivité,
- programmation fonctionelle,
- programmation logique.
De plus en plus de formations au développement commencent directement avec le Java et ne font que ça. C'est une énorme erreur, dommageable pour les personnes formées, leur employeur et le langage lui-même.
[^] # Re: Splash
Posté par Olivier Serve (site web personnel) . En réponse au journal Le GNU Image Manipulation Program 2.4 is out.. Évalué à 7.
Je ne sais pas sous d'autres environnements, mais sous KDE :
Centre de Configuration > Bureau > Tableau de bord > Menu.
On peut choisir Nom uniquement, Nom - Description, Description (Nom) ou Description uniquement.
On peut troller sur l'accessibilité du réglage, mais ça fait un moment que ça existe...
[^] # Re: Faut pas exagérer
Posté par Olivier Serve (site web personnel) . En réponse à la dépêche Officiel : les Rencontres Mondiales du Logiciel Libre 2008 auront lieu à Mont-de-Marsan. Évalué à 1.
[^] # Re: T'étais effectivement naïf, je crois
Posté par Olivier Serve (site web personnel) . En réponse au journal OpenOffice 3.0 : Ce sera sans moi !. Évalué à 1.
Ça unifierait la bloatitude...
[^] # Aïe, ça pique les yeux !
Posté par Olivier Serve (site web personnel) . En réponse à la dépêche Présentation de Maarch LetterBox 2.0 lors d'une Install Party. Évalué à 1.
[^] # Re: de la bonne utilisation ...
Posté par Olivier Serve (site web personnel) . En réponse à la dépêche Présentation de Maarch LetterBox 2.0 lors d'une Install Party. Évalué à 1.
s/accès/axé/
[^] # Re: SVN vs CVS
Posté par Olivier Serve (site web personnel) . En réponse à la dépêche Projet NACA [2]: transcodage automatique vers Java de 4 millions de lignes Cobol. Évalué à 2.
Je l'utilise depuis plus de 2 ans et je ne vois vraiment pas ce qui lui manque...
[^] # Re: Python c'est bon
Posté par Olivier Serve (site web personnel) . En réponse au journal PyQt, QtJambi, et les autres. Évalué à 10.
[^] # Re: S5-IS
Posté par Olivier Serve (site web personnel) . En réponse au journal Quel appareil photo numérique compact me faut-il ?. Évalué à 1.
J'aime bien la prise en main et l'ergonomie du S5. Les fonctions sont accessibles sans devoir passer par des menus interminables. Et après y avoir goûté, l'écran orientable est un must-have.
L'absence de grand-angle ne me dérange pas, mais ça dépend de ce que chacun veut faire. Il existe un convertisseur.
Après pour la qualité des photos, va voir sur le lien que j'ai donné plus haut. Je suis loin d'être un pro, mais tu pourra te faire une idée. Pour le bruit, je trouve que ça va jusqu'à 400 en conditions 'normales'. De nuit par contre, c'est 200 max. C'est déjà largement mieux que les S2/S3.
Un capteur plus gros (en taille, pas en nombre de pixels) aurait été mieux, mais ça lui permet de combiner compacité et gros zoom. Tu peux regarder le Panasonic FZ50 aussi, mais l'objectif est plus gros (à cause du capteur plus grand).
Le compromis me convient pour le moment. Je ne peux pas te dire 'vas-y coco', ça dépend trop de ce que tu cherches. En tout cas moi je ne regrette pas.
# S5-IS
Posté par Olivier Serve (site web personnel) . En réponse au journal Quel appareil photo numérique compact me faut-il ?. Évalué à 3.
Il n'est pas ultra-léger, mais son poids améliore sa stabilité en main.
Les 3 samedis passés je me suis essayé à la photo de nuit au Parc Oriental de Maulévrier et on arrive à des résultats sympas[1] en manuel+trépied. Le mode manuel est très simple d'utilisation.
Je ne sais pas comment fonctionne le Digic III mais il prend autant de temps de post-traitement que le temps d'exposition. Pour 15s d'expo (le maximum), il lui en faut autant pour obtenir l'image finale.
Pour le moment, j'en suis content.
[1] http://tifauv.homeip.net/gallery/v/parc_oriental/nuit/
[^] # Re: Michu sur ohloh
Posté par Olivier Serve (site web personnel) . En réponse au journal Linus sur ohloh. Évalué à 2.
# Petites corrections
Posté par Olivier Serve (site web personnel) . En réponse au journal Aider les Birmans. Évalué à 6.
killing itself
doing this
[^] # Re: Gentoo
Posté par Olivier Serve (site web personnel) . En réponse au journal Grenelle de l'environnement et LL. Évalué à 2.
[^] # Re: compléments
Posté par Olivier Serve (site web personnel) . En réponse au journal IBM se joint à la communauté OOo. Évalué à 3.
IBM va libérer Lotus Notes ? Je me demande si c'est une bonne nouvelle...
[^] # Re: Autre possibilité:
Posté par Olivier Serve (site web personnel) . En réponse au journal Report de la sortie de KDE 4.0. Évalué à 3.
[^] # Re: Cycle de release
Posté par Olivier Serve (site web personnel) . En réponse à la dépêche GNOME fête ses dix ans de logiciel libre. Évalué à 3.
Oui, tout évolue, KDE aussi. Entre la 3.0.0 et la 3.5.7, il y en a eu du boulot... (KDE3 est à peine plus agé que Gnome2)
[^] # Re: Cycle de release
Posté par Olivier Serve (site web personnel) . En réponse à la dépêche GNOME fête ses dix ans de logiciel libre. Évalué à 3.
C'est une contrainte forte, mais je trouve quand même intéressant qu'un logiciel développé pour la X.0 ait l'assurance de continuer à fonctionner jusqu'à la dernière évolution de la branche X ; même si le développement est abandonné. Ça lui donne plus de 'chances' d'être utilisé et repris.
[^] # Re: Cycle de release
Posté par Olivier Serve (site web personnel) . En réponse à la dépêche GNOME fête ses dix ans de logiciel libre. Évalué à 3.
J'ai l'impression en tout cas que la branche Qt4 va évoluer plus longtemps que Qt3. Pour preuve, on en est déjà à la 4.3 et la 4.4 se profile alors que la branche 3 s'est arrêté à la 3.3.8...
[^] # Re: Cycle de release
Posté par Olivier Serve (site web personnel) . En réponse à la dépêche GNOME fête ses dix ans de logiciel libre. Évalué à 5.
D'autre part, la compatibilité binaire doit être assurée pour toute la durée de KDE4 (comme ça a été le cas pour les 2.x et 3.x). Une appli 3.0 fonctionne toujours avec le dernier 3.5.7... Donc passer à la 4.0 en gardant arts (par exemple) ne permet plus de le virer après...
KDE combine des évolutions 'douces' dans une branche (la 3.x aura duré plus de 5,5 ans quand même ; à peu près autant que Gnome 2.0) et des évolutions plus 'brutales' afin de permettre des sauts évolutifs plus importants.