Reprise du message précédent :

Aimerais tu que quelqu'un étrangé à ta boite puisse changer l'ensemble des tarifs que tu proposes comme ça le chante?
 

pour ça, il y a des solutions alternatives : une dynamo dans un moulin à vent ou à eau, des paneaux solaires, des générateurs ... En plus, si tu produis plus que ce que tu consomes, tu peux revendre le surplus à EDF. Mais attention, si on produit plus qu'un certain seuil, c'est EDF qui récupére tout et alors tu te retrouves à payer EDF pour l'électricité que tu consomes même si elle fait partie de ta propre production. Les boules, non? Du moins, à ma conaissance, ce réglement là est encore en vigueur et le restera jusqu'à la libéralisation du marché.
Bon, évidement, on reste encore dépendant des cables électriques.

 
Pourquoi ? ca m'intéresse...
 
 

mouais a ma avis y'a plus de risque que ca arrive sur le pc du client ...

4 clients qui mangent à la même table. Chacun prend un appéro, une entrée, un plat principal et un dessert.
Deux d'entre eux prennent un café.
Aucun ne prend la même chôse que les autres.
4 appéro + 4 entrée + 4 plat principal + 4 dessert + 2 desserts = 34 saisies.
10 seconde de latence par saisie on va dire : 360 secondes.
5 minutes pour saisir une comande, tu trouves que c'est une vitesse suportable pour le client ou pour le professionel?
Peut être que pour un petit resto qui sert 100 personnes par services de 2 heures c'est utilisable, mais pour un resto qui en fait beaucoup plus, ca devient du n'importe quoi. Et je te dis pas ce que ca donnerait pour de la restoration rapide.
 
Voilà pourquoi on est plusieurs à penser qu'il faut que l'applis soit hébergeable en local et pas juste aux USA.

Ha bon? Pourquoi ça? Tu penses que le client du restorateur va avoir accés à ce PC là? Moi pas.

 
Je plussoie.    Tu m'as évité d'écrire 20 lignes.    

 
Et pour complêter le tout :
 
Pour moi, non seulement il faut que le serveur soit sur place, mais en plus, le formulaire de saisie devrait obligatoirement être en JS ou autre techno client et permettre l'impression de la facture (comme dans l'exemple que j'ai montré), car alors, même en cas de panne du serveur, tu peux facturer et rêgler le problème du serveur plus tard.    

Vous me faite délirer. Vous restez bloquer sur le coté technique et code. Il propose les deux solution apres c'est à l'utilisateur de décider de la solution qu'il souhaite. Arrêté de vous tortiller les fesses pour chier droit.

Au fait sonikbuzz. Est ce que ton client t'as parlé du probléme de vérification des commandes passé pendant une période donnée?
Il me semble que ca peut être exigé en cas de controle financié.
J'espéres que ton programme sauvegarde l'ensemble des commandes enregistrés et ce avec le détail de la commande.

 
La sécurité et le fait que son applie fonctionne quelque soit la situation, c'est de la responsabilité de celui qui conçoit l'applie.
 
En rêgle générale, les applies des restaus ne reposent pas uniquement sur une techno serveur comme PHP ou JSP. C'est juste le traitement des données qui devrait reposer dessus. Ajouter ou retirer un article d'une facture au moment ou l'on crée la facture ne devrait pas être fait en PHP. C'est mon avis. (et je le partage )

Ben lui, il a l'air de refuser catégoriquement la solution de l'hébergement sur site. On essaye de lui expliquer pourquoi, en pratique, ca peut être nécessaire.

Il faudra lui demander mais son appli n'est pas contractuel c'est à dire que si un restaurateur quelconque télécharge et il y a un bug qui fait qu'il perd toute ces données il peut pas ce retourner contre l'auteur.
Comme il le dit au début il ne connait que le Php.  
Php commence a prendre place sur des applications local. Il y a pas de problème à cela c'est juste qu'il faut s'y habituer. Il y a bien eu un magnetoscope dont la programmation des horaire d'enregistrement ce faiait en PHP  

Je parlais du pc du restaurateur et des utilisateur de ce pc (les serveurs entre autre).
 
omega2> "10 seconde de latence par saisie on va dire : 360 secondes." Consernant la rapidité: c'est quand meme plus rapide que ca (chez moi).
1)le serveur actuel est lents -> ca peu changer.
2)le code n'est pas optimisé: ca peu etre plus rapide et en JS
 
omega2> oui bien sur que toutes les commandes sont sauvegardés
 
 
bon je voulez juste avoir votre avis sur l'utilisation par internet -> c'est plutot négatif.
mais je suis tetu  
Distribuer une appli en php ca me plait pas trop...

 
te prend pas la tête tu proposes les deux solution et voila

 
Mais en php, ca implique l'install d'un serveur en local.
Et puis les sources...

Et alors ? quand tu installes c'est pareille. En faite je comprend ou tu bloques comme beaucoup, harf et alors? il est ou le problème ? les sources, tu veux les protéger? si oui tu peux crypter le fichier ou bien faire en sorte qu'il puisse être converti en language machine.

Je peux le comprendre mais il existe plusieurs solutions.
 

Je penses que si on a un avis négatif sur l'utilisation d'une telle application par internet c'est surement par ce qu'on a conscience de tous les problémes qui peuvent survenir sur internet.
 
En tout cas, bonne chance pour la suite. C'est déjà bien que t'es tenté la création d'un tel programme.

 
Tu as certainement raison, mais je trouve ca lourd de devoir installer un serveur web chez le client.

En java, en delphi, en c, en perl .... dans tous les languages en fait. lol La différence, c'est que c'est pas forcément un serveur web mais une partie de l'applis qui contient une partie serveur. Enfin, du moins s'il y a plus d'un ordi permettant de saisir des commandes.

Je veux pas écarter les problèmes liés a internet mais je pense que c'est plutot une question d'habitude peut etre que dans quelques années ce sera plus courant.
 
 

PHP GTK ===>

ca a l'air pas mal tu l'as deja utilisé ?

Je l'ai déjà vu tourner mais j'ai pas mis mes mimines dans le code. Mais c'est une bonne alternative.

Il y a un autre probleme concernant une appli distribuee sur internet.
Les attaques DDoS.
 
Certains (grands) hebergeurs, lorsqu'ils sont en train de se faire attaquer par un DDoS decident de bloquer les ranges d'ips d'ou l'attaque provient, afin de stoper l'attaque.
C'est une bonne pratique, mais ... Cela peut avoir des effets de bord assez genants... Imaginez que le FAI du restorateur se fasse bloquer a cause de 2-3 ordis zombis qui utilisent cet FAI... Ben le pov restorateur n'aura plus acces au logiciel...
Vous vous dites que les probabilitées sont quasi nulles ? Ca m'est deja arrive ... Le blocage avait dure 2-3 jours, le temps pour le DDoS de se calmer...
 
Autre probleme : Vous n'avez generalement pas beaucoup de controle sur la config php chez un hebergeur. Alors que si vous utilisez un serveur chez le restorateur, la vous avez full control dessus.
Suffit d'installer un petit linux, le tweak un peu pour qu'il lance X, s'autolog avec un user, et lance un navigateur en plein ecran (dont la page de demarrage est votre appli) et c'est bon. Si de plus le restorateur a un acces au net, vous pourrez meme vous y connecter dessus pour faire des backups, mises a jour.
De plus, avec un serveur dedie, vous aurez acces aux taches planifiees (cron, at). Histoire de faire des backup reguliers de la base a des heures ou le resto est ferme (et envoyer le backup sur un mail ou sur un serveur de backup).
 
Pour ceux qui ne veulent pas distribuer les sources, il y a toujours moyen de les crypter (via Zend Optimizer il me semble), ou meme de les compiler (j'avais vu une foi une appli opengl programmee en php5 ...)

Si le retaurateur a deja un pc je doute fort qu'il accete un linux. pour ça linux n'est pas forcément necessaire. Mais bon ça , sa va commencer avec l'eternel question de win vs linux Moi je dis que c'est seulement le client qui décide.

 
+1 C'est ce que j'ai fait pour ma propre applie. (:spamafote]

 
Ben moi, le restaurateur avait déjà un PC sous windows connecté à internet et avec winsnack comme logiciel de restauration, et c'est lui qui m'a demandé d'installer Linux dessus pour plus avoir de problème
 
Comme il n'existait aucun logiciel satisfaisant pour son restaurant sous Linux, j'en ai écrit un.

Oui evidement, s'il a deja un pc, c'est une autre histoire.
Mais si tu installe toi un serveur, je prefere installer un linux pour la simple et bonne raison que ce dernier resistera mieux a la "maltraitance" des utilisateurs.
Un utilisateur sous windows fait partie des administrateurs, ce qui n'est pas forcement une bonne chose pour un serveur.
Il y aussi le probleme des virus et autre ammusements.
 
Enfin, ne commençons pas un debat sur linux vs windows.
 
Pour finir je dirais que je serais plutot d'avis d'un serveur dedie chez le client, au moins de cette facon on a le controle sur la version + config de php (ainsi que sur les libs installees).

[Hors sujet]

 
J'ai fait comme ca pour l'appli que je dev pour un cyber cafe.
 
Installation d'un serveur dedie sous debian, login automatique sous X et utilisation de Fluxbox, lancement automatique d'un xterm + Firefox (avec comme page d'accueil l'appli).
 
Si le browser est ferme ou plante, je me log en ssh dessus, puis soit je me connecte au "screen" qui est lance ds le xterm, soit je lance x11vnc puis me log en vnc dessus.
 
Sans oublier un shorewall qui tourne pour bloquer tous les ports sauf le ssh. (Avec ssh + tunnel ssh, pas besoin d'ouvrir les ports sur la machine )
 
Ah la la, ssh c'est le pied.
 
Et le tout tourne sur un ancien serveur recycle. Un bi p3-800 mhz avec 1go de ram. Si je l'avais recup, le pov serveur etait voue a un triste sort, en effet plus assez puissant pour les heberger les serveurs des jeux actuels... Mais largement suffisant pour servir de serveur a mon appli.
[/Hors sujet]

J'ai un root access sur le serveur que j'utilise.  

J'ai fait un truc dans le genre, mais uniquement pour la gestion de la carte

Ben voila les grands esprits se rencontre

 
Je ne dis pas le contraire. Ma propre applie est bien en PHP.
 
MAIS, le module de facturation, LUI ne peut pas reposer UNIQUEMENT sur une techno serveur, d'abord parce que c'est trop lent et ensuite parce qu'on doit pouvoir facturer quoi qu'il arrive.

Trop lent? c'est à dire?

 
Hmmm, c'est ton hebergeur qui propose un acces root ? Tu as serveur dedie ? Ou c'est une "combine" ?
 
Si le premier se suis interesse
Je reve de pouvoir installer subversion + mod_python + trac sur un petit serveur

 
C'est à dire que chaque fois que tu vas rajouter un article commandé par le client dans une seule et meme facture, tu vas pas faire un appel au serveur, il faut le faire au niveau du client et ENSUITE passer toute la facture sur le serveur...
 
Regarde mon exemple, c'est plus facile à comprendre.

Un Virtual Dedied Server, c'est comme un server dedie (tu choisi ta distro, acces ssh, installe ce que tu veux, reboot...) mais ya une dizaine de vps par server donc partage de la ram et cpu (avec un minimum garantie).  
 

Au début je voulais faire comme ca mais... JS n'est pas mon ami.
 
Le traitement ne doit pas être beaucoup plus rapide mais l'affichage oui.
Je suis entrain de réfléchir a un truc « hybride » en css et js (un peu ). (ca risque de pas être génial   )
 
Je retourne bosser sur mes stats (jpgraph)...

 
Il ne tient qu'à toi qu'il le devienne.
 
Regarde mon code, tu verras qu'il n'est pas très compliqué à comprendre et que le principe va être vite compris.
 
Ensuite, plusieurs rêgles :
 
1) Utiliser les id et jamais les names pour l'adéquation JS + CSS.
2) Utiliser innerHTML pour générer du HTML via JS (tu verras, c'est très très simple).
3) Toujours travailler avec mozilla/firefox et son debbuggeur de JS et corriger s'il y a lieu ensuite pour IE.
 
La seule chose complexe dans mon script que j'ai mis en exemple, c'est la génération de JS via JS pour pouvoir effacer les articles généré via innerHTML...    
 
Allez, un peu de courage. Au boulot, tu vas y arriver, et dans ton cas, tu n'as pas le choix en fait. Ce sera 10 000 fois plus confortable pour les restaurateurs. Et n'oublie pas de faire en sorte qu'ils puissent saisir l'id de chaque produit. C'est 1000 fois plus rapide pour une saisie que n'importe quel menu déroulant.
 
Surtout que dans ton cas, tu aimerais redistribuer ensuite ton applie pour d'autres restaurants.

ok merci pour tes conseils.
 
hum... je vois que personne n'a encore testé la creation de compte.

Et pour que JS devienne encore plus ton ami, quoi de mieux de pouvoir l'utiliser en "temps reel" sur ta page ?
 
Je te conseille un petit bookmarklet qui se trouve a cette adresse : http://www.squarefree.com/bookmarklets/webdevel.html
Tu prends le bookmarklet "Shell". Ensuite, une fois que tu l'a ajoute a tes favoris, suffit de le lancer quand tu es sur ta page.
Apres tu auras un shell javascript. Tout le javascript execute dans ce shell sera execute sur la page depuis ou il a ete lance. Cela te permet d'interargir avec la page en temps reel.  
Tres pratique pour le developpement des fonctions JS.

merci cerel je vais voir ca...
bon un petit s'impose