Merci à M. pierre Groleau et M. Stéphane Pinel pour les réponses.
Il faut laisser le temps à REAL Software US et Europe de travailler
et proposer les améliorations (documentations, Compatibilité Leopard,
amplification des améliorations, etc.). La société du "tout, tout de
suite et toujours" est hors de la réalité humaine, je le reconnais
bien volontiers. Les forums abscons où les utilisateurs s'imaginent
"réclamer de suite" et "obtenir sur le champ" tout et n'importe quoi
ne sont pas très pertinents au final. Il faut de la méthode. Notre
esprit cartésien devrait nous y aider sans complexe.
Tenez nous au courant de votre réflexion sur un feedback francophone,
si cela vous paraît jouable. Mais ne nous précipitons pas car une
fois en place, il faut pouvoir assumer le service dans la durée. Peut
être faudrait il que celui-ci soit payant car alors les gens seront
alors responsabilisés. J'ai une tendance naturelle à me méfier du
service gratuit qui dure un temps mais ne tient pas dans la fameuse
durée.
la formule Standard ( 12 incidents/an pour 400 Euros) est une bonne
formule.
pouvez vous me confirmer que le traitement a lieu en français avec
REAL Software Europe ? je suppose que oui.
S'agissant des incidents, je suis cependant pour ma part heureux
d'affirmer que je n'ai pratiquement pas d'incidents. Le produit
RealBasic a désormais une très bonne fiabilité selon moi. Peut être
est ce du au fait que j'ai un emploi de RB qui ne pousse pas
l'environnement dans ses limites mais mon but est de développer
proprement une application et je ne cherche pas la sophistication
"codale" (du code). Néanmoins il m'arrive d'avoir quelques agacements
quant aux limites actuelles de RB.
J'ai naturellement de réels besoins quant à l'amélioration des
fonctionnalités du produit RealBasic. Chacun a les siennes, ce qui
est normal et les ingénieurs de REAL Software sont très loin d'être
des idiots et ont bien conscience des améliorations qui devront être
fournies à l'avenir pour mieux satisfaire le client. Pour ma part je
crois à 100% dans l'avenir d'un produit comme RealBasic car il est
cross plateform et je me refuse aux environnements propriétaires qui
ne fonctionnent que sur un seul OS (cf. XCODE et MAC OSX ou VB.NET et
Microsoft)
Ainsi, par exemple, un outil d'optimisation (un profiler) doit voir
le jour dans les années à venir. J'ai bien d'autres idées plus
originales à partager mais rien ne sert à émettre moults idées,
fussent elles géniales, si elles sont inatteignables, non prises en
compte méthodiquement et hors du scope (la réalité de la société REAL
Software en l'état).
Ce qui est trivial pour REAL Software, c'est de prendre appui sur ce
qui existe ailleurs (galaxie VB.NET et outils XCODE d'Apple) pour
orienter les développements tout en consolidant le produit actuel
pour lui permettre l'extensibilité et la maintenabilité. Ceci est
évident. Cela évite de réinventer la roue mais de se conformer aux
autres. VB.NET offre à ce sujet bien des mécanismes dont devrait
hériter RealBasic. Aaron Balmann de chez REAL Software, très orienté
Windows, doit être le fer de lance de ce ralliement aux manière de
faire de VB.NET
Les clients veulent avoir leur mot à dire sur les orientations à
venir du produit. Ceci est normal. Il existe d'ailleurs un système de
votation (comme disent les suisses) sur le feedback RB US permettant
de comptabiliser les "accords" des clients sur tel ou tel nouveau
besoin (feature request). Voilà une bonne piste. L'intérêt bien
compris de tout le monde (la société REAL Software et ses clients)
est l'amélioration du produit tenant compte du fait que cette
sympathique société n'a pas les moyens d'un groupe comme APPLE inc.
D'où la nécessité de faire les bons choix et de ne pas se tromper sur
les besoins avérés et justifiés des clients. A moins que REAL
Software soit racheté par un plus gros et que cela booste les
développement par un plus grand nombre d'ingénieurs et une plus
grande agressivité commerciale.
Tout ce qui est dit ici est trivial, et je m'en excuse, et s'applique
à tout type de produit commercial. Organiser la remontée de
l'information des clients est bien sûr le B A - BA du marketing.
Cordialement.
M. Patrick Santoni
------------------------------------------------------------------------
----------------------------------------------------------------
108, rue de villiers
78300 POISSY
courriel : patricksantoni1 at mac dot com
------------------------------------------------------------------------
--------------------------------------
------------------------------------------------------------------------
----------------------------------------------------------------
Le 23 juil. 07 à 10:53, Stéphane Pinel a écrit :
Le 23 juil. 07 à 10:18, Sébastien Debiève a écrit :
Pour des gros projets, ce serait bien de pouvoir compiler avant
que Lepard arrive, il nous faudra au moins 2 mois pour tester les
applications et corrigés les problèmes. Donc si Real Software
pouvais mettre une bêta de RB pour pouvoir compilé avant le
lancement de leopard ce serais cool, surtout aussi pour ceux qui
ont un compte ADC (comme moi) pour pouvoir tester c'est
applications avec les builds en téléchargement, parce là je ne
vois pas l'investissement que j'ai fait si RB n'est pas capable de
fonctionner sur Leopard Beta :-(
Chaque version majeure de REALbasic est précédée d'un stage beta
durant lequel il vous est possible de faire vos tests. C'est à
cette occasion que vous pourrez voir comment se comportent vos
applications au fur et à mesure des builds. Toutefois,
l'investissement auquel vous faites référence concerne ADC (donc
Apple), et non REAL Software. Et c'est, du reste, le même
"investissement" auprès d'Apple qui permet aux ingénieurs de REAL
Software de travailler sur Leopard beta ;-)
Cordialement.
---
Stéphane Pinel
Support Technique en Français
stephane at realsoftware dot fr - http://www.realsoftware.fr
43, Rue Marius Aufan 92300 Levallois-Perret (FR)
Rejoignez la communauté francophone des développeurs REALbasic :
http://www.realsoftware.com/fr/support/listmanager/
|