Je suis également indep, (depuis 10 ans, programmeur de spécifs), et après avoir essayé diverses formes de collaborations (ssii et asso), je constate que le plus simple et surtout le plus réaliste est la collaboration client-fournisseur, entre indeps, entre indep et ssii etc...
C'est l'anarchie au sens noble du terme (pas de pouvoir issue de la hierarchie). Chacun est responsable, chacun travaille en fonction de ces compétences, au rythme qui lui convient...
Ensuite rien n'empêche de mutualiser certaines choses, c'est ce qu'on fait déjà indirectement en travaillant avec les logiciels libres.
Pour la partie administrative, en indep c'est déjà extrèmement simple, aucun intérêt de centraliser ça.
Commercialement, c'est difficile de centraliser car c'est très lié aux domaines de chacun. Pour ma part je ne fonctionne qu'avec le bouche à oreille.
Financièrement, c'est difficile aussi, personne n'a ni les mêmes envies ni les mêmes moyens.
Ce que je trouverai intéressant de mutualiser (en plus des logiciels, mais c'est évident ici), c'est le dépannage (lorsque je part en vaccance, je croise les 10 doigts des pieds avec les 10 doigts des mains et ça devient difficile de pédaler) et un système d'aide aux collègues dans la panade (financière ou manque de compétence), quelqu'un qui a un surplus de boulot va le donner en priorité à celui qui en manque par ex, prêt de machine, de serveur... Bref, un petit havre de sécurité pour dormir tranquille et rassurer clients et familles.
En fait ce que tu cherches c'est un IDE sous forme de web-application on dirait. Il serait peut-être plus simple que tu te dirige vers un IDE qui permette le travail en réseau et qui comprenne des outils de gestion de version, <gag>windev par ex</gag>... J'ai du mal à croire que des développeurs puissent utliser un formulaire web pour gerer des sources ! Ou alors avec XUL ?
Oui, il y a énormément d'applications professionnelles en Windev. Pour la petite histoire, Windev jusqu'à la version 4 (j'ai abandonné à la version 5) permettait de faire de petits miracles, on peut le dire... Une interface, un langage et une bdd simple, rapide et très fiable en production. Ca a permis à bon nombre de développeurs de passer le cap fenêtre.
Ensuite ils ont eu du mal à suivre, dongle, odbc accessible qu'en lecture, pas de sql, embryon d'objet, ide plein de bugs etc... Alors que la concurence arrivait avec delphi, java et les langages libres pointaient leur nez dans toutes les directions.
De la on a été nombreux à aller voir ailleur, aujourd'hui je ne sais pas où ils en sont, mais c'est sûr qu'il reste un tas d'applications en circulation.
Le problème vient du fait que dès que quelqu'un a une idée il croit avoir inventé la poudre...
D'une part il y a pleins de gens qui ont eu la même idée avant, mais qui ne l'ont pas forcément clamée sur tous les toits.
D'autre part, une idée est toujours issue de l'expérience, et des connaissances acquises avant, ne serait-ce que le langage et l'écriture. C'est pour ça qu'une idée n'apartient à personne, elle n'est que le fruit de la culture et la connaissance de la communauté qui précède.
Il n'y a pas non plus de séparation à faire entre auteurs du libre et propriétaires. Tous les développeurs sont issuent des mêmes écoles, discuttent sur les mêmes forums etc... Les idées vont et viennent, se construisent à partir de tout ça. La seule différence est que si elle tombent dans des mains commerciales, elles sont mises en avant, apropriées, et enfin brevetées...
C'est vrai que la comparaison python/j2ee a plus de sens. Il manque une unité dans les frameworks web en python. Espérons que le pep333 permette de régler ce problème progressivement... http://www.python.org/peps/pep-0333.html(...)
« This document specifies a proposed standard interface between web servers and Python web applications or frameworks, to promote web application portability across a variety of web servers. »
Avec j2ee il doit y avoir des mécanismes hypers sophistiqués, style les sessions sur une machine séparée, en base de donnée etc...
Mais sinon, plus simplement, le noyau (linux) sait très bien gérer ce genre de choses. (l'inverse aussi : ne pas aller chercher sur disque chaque script php).
La différence sur un serveur c'est que c'est toi qui peut choisir ce qui doit rester en mémoire et ce qui ne doit pas...
Ensuite, en java je sais pas, mais on peut faire un serveur asynchrone, dans ce cas il n'y a qu'un seul process et 1 ou 2 threads (voir twistedmatrix)
Ca dépend si tu compare à mod-php ou php-cgi.
Avec php-cgi c'est incomparable, avec mod-php je sais pas, j'imagine que les sessions peuvent être stockées en ram aussi non (mais là c'est des histoires d'implémentations) ?
Oui, mais ton application tu devra l'écrire dans un autre langage et assurer la communication entre ces deux langages, ce qui va t'obliger à rajouter une couche/passerelle supplémentaire.
Par exemple, comment accèdes-tu à ton application php à partir de telnet, jabber, irc etc... ?
Elle n'aura pas la même interface au contraire, l'intérêt c'est d'avoir des interfaces différentes justement...
Par ex une interface client en html, une interface d'administration en telnet, en jabber, une interface gestion en gtk, en swing... Ou même, pas d'interface du tout, c'est un autre serveur qui communique avec le tien...
Il y a plein de "juste milieu" : n'importe quel langage avec lequel tu peux faire un serveur autonome (cad lancé en permanence). Après c'est un problème de confort, les librairies plus où moins pratiques etc...
Jette un coup d'oeuil à http://twistedmatrix.com(...)
Tu ne peux pas réutiliser du code php pour autre chose que du web. Alors qu'avec j2ee, demain tu peux développer une interface native sans rien changer au code métier qui est derrière. Et en prime les deux interfaces marcherons en même temps.
Tu n'as pas pigé que la différence est qu'une appli web en j2ee ou autre, est lancée en permanence, ce qui facilite la persistance et qui permet de faire des choses sans intervention du client qui visite une page.
Un autre exemple plus frappant que l'email : tu peux réagir à d'autres actions qu'un timer, par ex pour mon jeu de scrabble, je peux réagir à des messages jabber, je peux controler mon programme par telnet etc...
Mis à part le petit troll qui s'est glissé, voilà pourquoi j'utilise python à la place de php, et pour les mêmes raisons j'aurai pu utiliser java...
D'abord une raison suplémentaire qui a été décrite maintes fois, j2ee n'est pas un langage mais une norme qui défini des comportements standards. On pourrait très bien imaginer un php compatible j2ee, mais pour l'instant ce n'est pas le cas.
Mais revenons aux choses plus terre à terre.
Au début j'ai utilisé php par obligation car c'était le seul langage disponible chez mon hébergeur. J'utilisais windev pour faire des applications windows, bash pour faire des scripts d'admin, C pour faire des jeux, C++ pour faire des GUI etc... C'était très pénible d'avoir à changer mes habitudes à chaque programme.
Aujourd'hui j'utilise python, je me suis fait des bibliothèques que je peux aussi bien utiliser pour du web (j'ai un dédié) que pour de la gestion, des jeux etc... Et je ne change quasiment plus jamais de langage. Voilà ce qui ne serait pas possible en PHP. Cela est d'autant plus important pour des applications complexes où la partie interface web n'est qu'une toute petite partie. Java aurait très bien pu faire l'affaire, mais je l'ai laissé tomber pour des raisons de confort on va dire (et de phylosophie).
Ensuite il y a tout un tas de petits avantages purement techniques (code plus propre, possibilité de se passer d'un serveur apache etc...) mais ça rentre dans le domaine du troll.
A vérifier, mais à mon avis quand il dit qu'il a besoin d'un serveur, c'est pas forcément un serveur local, c'est juste pour dire que le bot étant un client, il lui faut un serveur. Mais ça doit pouvoir être n'importe lequel.
On pourrait même imaginer, si ça a vraiment un intérêt, de créer un site exprès avec un bot qui recense tous les utilisateurs de plusieurs forums... Et chaque forum irait s'inscrire et piocher dedans. Ca éviterait aux webmaster de forum d'avoir leur propre bot. bof...
# bench des disques
Posté par wilk . En réponse au journal Itanium 2 - Performances sur le SGBD ???. Évalué à 2.
Faudrait que tu teste avec exactement le même disque et la même installation de l'os.
# Arch ou darcs
Posté par wilk . En réponse au message Télétravail et CVS. Évalué à 2.
[^] # Re: ...
Posté par wilk . En réponse au journal Idée d'entreprise mutualisée à visage plus "humain". Évalué à 3.
C'est l'anarchie au sens noble du terme (pas de pouvoir issue de la hierarchie). Chacun est responsable, chacun travaille en fonction de ces compétences, au rythme qui lui convient...
Ensuite rien n'empêche de mutualiser certaines choses, c'est ce qu'on fait déjà indirectement en travaillant avec les logiciels libres.
Pour la partie administrative, en indep c'est déjà extrèmement simple, aucun intérêt de centraliser ça.
Commercialement, c'est difficile de centraliser car c'est très lié aux domaines de chacun. Pour ma part je ne fonctionne qu'avec le bouche à oreille.
Financièrement, c'est difficile aussi, personne n'a ni les mêmes envies ni les mêmes moyens.
Ce que je trouverai intéressant de mutualiser (en plus des logiciels, mais c'est évident ici), c'est le dépannage (lorsque je part en vaccance, je croise les 10 doigts des pieds avec les 10 doigts des mains et ça devient difficile de pédaler) et un système d'aide aux collègues dans la panade (financière ou manque de compétence), quelqu'un qui a un surplus de boulot va le donner en priorité à celui qui en manque par ex, prêt de machine, de serveur... Bref, un petit havre de sécurité pour dormir tranquille et rassurer clients et familles.
D'autres indeps intéressés ?
[^] # Re: Bof, pas convaincu par l'article
Posté par wilk . En réponse à la dépêche Il n'y a pas que le traitement de texte pour manipuler du texte !. Évalué à 1.
# autoreload
Posté par wilk . En réponse au journal Ode à cherrypy. Évalué à 1.
C'est un petit script qui permet de recharger les modules automatiquement, sans arrêter le programme(serveur).
# Tu ne chercherais pas un ide plutôt ?
Posté par wilk . En réponse au journal Gestion de version suite. Évalué à 2.
[^] # Re: windev ou seulement hyperfile ?
Posté par wilk . En réponse à la dépêche Une ouverture pour les logiciels "métier" avec Windev 9. Évalué à 3.
Pour la gestion des versions j'utilise http://wiki.gnuarch.org(...) et enfin http://roundup.sf.net(...) pour le suivi. Comme ide emacs, pour les états http://reportlab.org(...) Voilà mon windev libre et multiplateforme :-)
[^] # Re: Des cas réels
Posté par wilk . En réponse à la dépêche Une ouverture pour les logiciels "métier" avec Windev 9. Évalué à 6.
Ensuite ils ont eu du mal à suivre, dongle, odbc accessible qu'en lecture, pas de sql, embryon d'objet, ide plein de bugs etc... Alors que la concurence arrivait avec delphi, java et les langages libres pointaient leur nez dans toutes les directions.
De la on a été nombreux à aller voir ailleur, aujourd'hui je ne sais pas où ils en sont, mais c'est sûr qu'il reste un tas d'applications en circulation.
[^] # Re: windev ou seulement hyperfile ?
Posté par wilk . En réponse à la dépêche Une ouverture pour les logiciels "métier" avec Windev 9. Évalué à 2.
# windev ou seulement hyperfile ?
Posté par wilk . En réponse à la dépêche Une ouverture pour les logiciels "métier" avec Windev 9. Évalué à 5.
Si c'est bien ça, ça n'a pas tellement d'intérêt...
Personnellement je n'ai pas attendu la version 9 pour migrer toutes mes applications windev en python !
# Passerelles ouvertes ?
Posté par wilk . En réponse au journal Nouveau serveur Jabber public cherche testeurs... Évalué à 2.
# on n'invente pas la poudre
Posté par wilk . En réponse au journal Je lisais la news de Kimdaba2 quand.... Évalué à 9.
D'une part il y a pleins de gens qui ont eu la même idée avant, mais qui ne l'ont pas forcément clamée sur tous les toits.
D'autre part, une idée est toujours issue de l'expérience, et des connaissances acquises avant, ne serait-ce que le langage et l'écriture. C'est pour ça qu'une idée n'apartient à personne, elle n'est que le fruit de la culture et la connaissance de la communauté qui précède.
Il n'y a pas non plus de séparation à faire entre auteurs du libre et propriétaires. Tous les développeurs sont issuent des mêmes écoles, discuttent sur les mêmes forums etc... Les idées vont et viennent, se construisent à partir de tout ça. La seule différence est que si elle tombent dans des mains commerciales, elles sont mises en avant, apropriées, et enfin brevetées...
[^] # Re: Entre php et java mon coeur balance du côté de python
Posté par wilk . En réponse au journal Apache/PHP et J2EE. Évalué à 1.
C'est vrai que la comparaison python/j2ee a plus de sens. Il manque une unité dans les frameworks web en python. Espérons que le pep333 permette de régler ce problème progressivement...
http://www.python.org/peps/pep-0333.html(...)
« This document specifies a proposed standard interface between web servers and Python web applications or frameworks, to promote web application portability across a variety of web servers. »
Quelqu'un travaille déjà sur une implémentation wsgi en servlet j2ee.
http://www.xhaus.com/modjy/(...)
[^] # Re: PS
Posté par wilk . En réponse au journal Apache/PHP et J2EE. Évalué à 1.
Mais sinon, plus simplement, le noyau (linux) sait très bien gérer ce genre de choses. (l'inverse aussi : ne pas aller chercher sur disque chaque script php).
La différence sur un serveur c'est que c'est toi qui peut choisir ce qui doit rester en mémoire et ce qui ne doit pas...
Ensuite, en java je sais pas, mais on peut faire un serveur asynchrone, dans ce cas il n'y a qu'un seul process et 1 ou 2 threads (voir twistedmatrix)
[^] # Re: Marrant, ça...
Posté par wilk . En réponse au journal Apache/PHP et J2EE. Évalué à 1.
[^] # Re: Marrant, ça...
Posté par wilk . En réponse au journal Apache/PHP et J2EE. Évalué à 1.
[^] # Re: Marrant, ça...
Posté par wilk . En réponse au journal Apache/PHP et J2EE. Évalué à 1.
[^] # Re: Marrant, ça...
Posté par wilk . En réponse au journal Apache/PHP et J2EE. Évalué à 1.
Avec php-cgi c'est incomparable, avec mod-php je sais pas, j'imagine que les sessions peuvent être stockées en ram aussi non (mais là c'est des histoires d'implémentations) ?
[^] # Re: Marrant, ça...
Posté par wilk . En réponse au journal Apache/PHP et J2EE. Évalué à 2.
Par exemple, comment accèdes-tu à ton application php à partir de telnet, jabber, irc etc... ?
[^] # Re: Marrant, ça...
Posté par wilk . En réponse au journal Apache/PHP et J2EE. Évalué à 1.
Par ex une interface client en html, une interface d'administration en telnet, en jabber, une interface gestion en gtk, en swing... Ou même, pas d'interface du tout, c'est un autre serveur qui communique avec le tien...
[^] # Re: Marrant, ça...
Posté par wilk . En réponse au journal Apache/PHP et J2EE. Évalué à 2.
Jette un coup d'oeuil à http://twistedmatrix.com(...)
[^] # Re: Marrant, ça...
Posté par wilk . En réponse au journal Apache/PHP et J2EE. Évalué à 2.
[^] # Re: Avec j2ee j'ai un serveur
Posté par wilk . En réponse au journal Apache/PHP et J2EE. Évalué à 2.
Un autre exemple plus frappant que l'email : tu peux réagir à d'autres actions qu'un timer, par ex pour mon jeu de scrabble, je peux réagir à des messages jabber, je peux controler mon programme par telnet etc...
# Entre php et java mon coeur balance du côté de python
Posté par wilk . En réponse au journal Apache/PHP et J2EE. Évalué à 6.
D'abord une raison suplémentaire qui a été décrite maintes fois, j2ee n'est pas un langage mais une norme qui défini des comportements standards. On pourrait très bien imaginer un php compatible j2ee, mais pour l'instant ce n'est pas le cas.
Mais revenons aux choses plus terre à terre.
Au début j'ai utilisé php par obligation car c'était le seul langage disponible chez mon hébergeur. J'utilisais windev pour faire des applications windows, bash pour faire des scripts d'admin, C pour faire des jeux, C++ pour faire des GUI etc... C'était très pénible d'avoir à changer mes habitudes à chaque programme.
Aujourd'hui j'utilise python, je me suis fait des bibliothèques que je peux aussi bien utiliser pour du web (j'ai un dédié) que pour de la gestion, des jeux etc... Et je ne change quasiment plus jamais de langage. Voilà ce qui ne serait pas possible en PHP. Cela est d'autant plus important pour des applications complexes où la partie interface web n'est qu'une toute petite partie. Java aurait très bien pu faire l'affaire, mais je l'ai laissé tomber pour des raisons de confort on va dire (et de phylosophie).
Ensuite il y a tout un tas de petits avantages purement techniques (code plus propre, possibilité de se passer d'un serveur apache etc...) mais ça rentre dans le domaine du troll.
[^] # Re: au sujet des forums
Posté par wilk . En réponse à la dépêche L'IETF publie les RFC de XMPP (pour Jabber, notamment). Évalué à 2.
On pourrait même imaginer, si ça a vraiment un intérêt, de créer un site exprès avec un bot qui recense tous les utilisateurs de plusieurs forums... Et chaque forum irait s'inscrire et piocher dedans. Ca éviterait aux webmaster de forum d'avoir leur propre bot. bof...