Ce n'est pas parce que c'est atypique que c'est imbitable
Imbitable n'était pas le bon mot, disons qu'elle n'est pas pour l'instant réutilisable par quelqu'un d'autre que toi : quel que soit le besoin, il sera moins coûteux de créer une nouvelle appli basée sur des technologies connues que d'investir dans la tienne.
interface web fonctionne avec tous les navigateurs web graphiques modernes
Je ne sais pas quels sont tes clients, mais pour les miens « moderne » signifie plutôt « moins de 3 ans » que « moins de 3 semaines ». Et une incompatibilité avec firefox et internet explorer pour windows < 10 est invendable.
Je n'ai jamais développé d'application web pour mes clients, et je n'ai pas l'intention d'en développer. L'interface de l’application présentée ici montre clairement que je n'ai pas les compétences en HTML, CSS et consorts pour cela (c'est pour cela que la facilité de modification de l'interface est un point clef de la technologie que j'emploie). D'ailleurs, si un prospect me contacte pour me demander de développer une application web, je lui dit sans équivoque qu'il lui sera facile de trouver développeur bien plus compétent et concurrentiel que moi pour cela.
Le fait est que les interfaces desktop que je développe s'appuient sur des technos web, pour les raisons expliquées dans ce journal. Du fait de l'utilisation de ces technos web, il me semblait juste logique que le même code puisse servir pour développer une version web de l'interface. Et c'est cette hypothèse qui fait l'objet d'une des POC présentés ici. L'interface web, c'est juste un bonus ; cela ne fait pas officiellement partie de mes prestations...
Tu as visiblement la chance d'avoir des clients qui ne s'intéressent pas à la technique et qui deviennent captifs puisque tu es le seul à pouvoir maintenir ton code, mais c'est de moins en moins la réalité du marché.
Au contraire, c'est parce que mes clients s'intéressent à la technique qu'ils me contactent. Ils sont bien conscients que c'est parce que les développeurs classiques n'ont pas la maîtrise des technologies qu'ils utilisent qu'ils ne sont pas capables de leur fournir une application qui réponde à leurs besoins. Avec mon framework, parce que j'en ai la totale maîtrise, je ne suis pas soumis au bon vouloir d'un éditeur pour en dépasser les limites.
Il vaut mieux une application développée dans une technologie soi-disant captive (mon framework, c'est quand même que du C++), mais qui réponde parfaitement aux besoins du client, qu'une application certes basée sur des technologies répandues, mais inutilisable à cause des limitations de ces technologies. Des clients dont les exigences sont telles que les technologies classiques ne peuvent y répondre sont peu nombreux, mais, d'un autre coté, comme on est peu de développeurs sur ce marché...
Du coup je ne comprends pas l'objectif de ton POC, parce que je n'ai aucun doute que ça va fonctionner et que tu vas pouvoir l'utiliser pour tes clients, mais pourquoi le rends-tu public ?
- tu as déjà expliqué dans les commentaires des journaux précédents que tu ne visais pas un usage pour les projets communautaires
- maintenant tu sembles indiquer que même pour des projets de commande tu t'adresses à un marché très restreint
Je n'ai pas trop compris ce que tu entends par viser un usage pour les projets communautaires.
Concernant mon framework, du fait qu'il soit atypique et que la documentation est inexistante, il y a peu de chances que quelqu'un s'y intéresse ; je ne communique donc pas directement dessus. Par contre, une application telle que celle présentée ici, naturellement pas en l'état, est plus à même de susciter l'intérêt, voire de fédérer une communauté. Certes, il reste bien du travail pour que cette application soit utilisable, et c'est pour cela que j'insiste plus sur l'aspect POC que sur ses fonctionnalités. Mais, à terme, peut-être deviendra-t-elle un projet communautaire ? En tout cas, je n'y aurais rien à y redire...
Je pense que tu as raison de continuer, visiblement ça peut te permettre d'avoir un avantage concurrentiel dans ton marché, mais je ne comprends pas quel est ton but en communiquant à ce sujet dans des journaux sur linuxfr.org.
Suite à ces journaux, j'observe quand même quelques téléchargements de mes logiciels. Sans préjuger de l'intention des téléchargeurs, on peut quand même supposer que mes logiciels, et donc leur évolution, les intéressent, d'où ces journaux pour communiquer à leur sujet...
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
[^] # Re: chromium, but not only
Posté par Claude SIMON (site web personnel) . En réponse au journal 'Epeios organizer' : nouveaux types de champs (widgets jQuery) et onglets. Évalué à 3.
Je n'ai jamais développé d'application web pour mes clients, et je n'ai pas l'intention d'en développer. L'interface de l’application présentée ici montre clairement que je n'ai pas les compétences en HTML, CSS et consorts pour cela (c'est pour cela que la facilité de modification de l'interface est un point clef de la technologie que j'emploie). D'ailleurs, si un prospect me contacte pour me demander de développer une application web, je lui dit sans équivoque qu'il lui sera facile de trouver développeur bien plus compétent et concurrentiel que moi pour cela.
Le fait est que les interfaces desktop que je développe s'appuient sur des technos web, pour les raisons expliquées dans ce journal. Du fait de l'utilisation de ces technos web, il me semblait juste logique que le même code puisse servir pour développer une version web de l'interface. Et c'est cette hypothèse qui fait l'objet d'une des POC présentés ici. L'interface web, c'est juste un bonus ; cela ne fait pas officiellement partie de mes prestations...
Au contraire, c'est parce que mes clients s'intéressent à la technique qu'ils me contactent. Ils sont bien conscients que c'est parce que les développeurs classiques n'ont pas la maîtrise des technologies qu'ils utilisent qu'ils ne sont pas capables de leur fournir une application qui réponde à leurs besoins. Avec mon framework, parce que j'en ai la totale maîtrise, je ne suis pas soumis au bon vouloir d'un éditeur pour en dépasser les limites.
Il vaut mieux une application développée dans une technologie soi-disant captive (mon framework, c'est quand même que du C++), mais qui réponde parfaitement aux besoins du client, qu'une application certes basée sur des technologies répandues, mais inutilisable à cause des limitations de ces technologies. Des clients dont les exigences sont telles que les technologies classiques ne peuvent y répondre sont peu nombreux, mais, d'un autre coté, comme on est peu de développeurs sur ce marché...
Je n'ai pas trop compris ce que tu entends par viser un usage pour les projets communautaires.
Concernant mon framework, du fait qu'il soit atypique et que la documentation est inexistante, il y a peu de chances que quelqu'un s'y intéresse ; je ne communique donc pas directement dessus. Par contre, une application telle que celle présentée ici, naturellement pas en l'état, est plus à même de susciter l'intérêt, voire de fédérer une communauté. Certes, il reste bien du travail pour que cette application soit utilisable, et c'est pour cela que j'insiste plus sur l'aspect POC que sur ses fonctionnalités. Mais, à terme, peut-être deviendra-t-elle un projet communautaire ? En tout cas, je n'y aurais rien à y redire...
Suite à ces journaux, j'observe quand même quelques téléchargements de mes logiciels. Sans préjuger de l'intention des téléchargeurs, on peut quand même supposer que mes logiciels, et donc leur évolution, les intéressent, d'où ces journaux pour communiquer à leur sujet...
Zelbinium: pour la génération qui crée, pas celle qui scrolle...