Dadou

En général chaque service gratuit à sa contrepartie (plus ou moins "visible" pour nous) Personnellement, en plus des stats serveur de mon hebergeur, j'utiliser, Google Analytics

Voila l'adresse : http://webmessenger.msn.com/

Le plus simple : prendre la version web de messenger

Ben c'est tout simple, les paiements seront en moyenne de * 100 € * 1 000 € * 10 000 € * ... suivant l'ordre de grandeur des paiements, les solutions seront différentes

Je ne suis pas franchement pour De plus sur les écrans plats actuel, un fond noir devient plutôt désagréable à utiliser : facilite les reflets sur l'écran.

Se méfier des idées simples : Oui, afficher une image noire nécessite moins d'électricité que pour une image blanche mais uniquement si vous utilisez un écran cathodique, les écrans plats quand à eux utilisent des pixels qui sont allumés en permanence, que l'image soit blanche ou noire, donc pour eux, pas d'économie. Bilan, aujourd'hui l'impact est franchement négligeable.

Les messageries gratuites comme Gmail, hotmail, yahoo mail... ont tendance à envoyer les mails envoyés automatiquement dans le filtre antispam (surtout si les entêtes ne sont pas complets), certains comme Hotmail necessite de travailler sur le spf (enfin je crois que c'est ça)

Il y a éventuellement la possibilité que l'entreprise qui a besoin de tes services puisse établir un contrat de travail à durée déterminée, le centre de formation pour lequel je bossais il y a quelques années procédait de cette manière pour rémunérer les vacataires

Bonjour à tous, Voila, actuellement je développe une application avec une utilisation de PDO (PHP Data Objects), sur mon ordinateur local avec WAMP (et les extentions pdo et mysql_pdo d'activées) cela fonctionne correctement. Mais déception lors de la publication chez mon hébergeur, rien, page blanche. J'ai vérifié le phpinfo, mais les extentions sont bien notés comme présentes et actives, bon soit. Je fais donc un test : <?php try { // Paramtres de connection $dsn = "mysql:host=####;dbname=####"; $username = "####"; $password = "####"; // Connection la base de donnes $bdd = new PDO($dsn, $username, $password); $result = $bdd->query("SELECT * FROM `pages`"); // Premier test => la table s'affiche foreach ($result as $row) { print $row['titre']."<br />"; } // Utilisation des fonctions PDO $nbresult = $result->rowCount(); print $nbresult."<br/>"; // Deuxèime test => la table ne s'affiche pas while ($lignes = $result->fetch(PDO::FETCH_ASSOC)) { print $lignes['titre']."<br />"; } // Fermer la connection $bdd = null; } catch(PDOException $e){ die('Connexion impossible :'.$e->getMessage()); } ?> Voir le résultat : http://www.normandie-creation.com/testpdo.php Le premier test fonctionne bien, et me liste bien les résultats, mais dès que je veux utiliser des fonctions propres à PDO me semble t'il, plus aucun résultat n'est retourné : en l'occurrence $result->rowCount(); me retourne 0 au lieu de 6 et $result->fetch(PDO::FETCH_ASSOC) qui ne retourne aucun enregistrement J'avoue que je suis perdu et commence à être sérieusement agacé par cette différence de fonctionnement. Si une bonne âme bien charitable pouvait me permettre de voir enfin la lumière d'une explication / solution, je lui en serait très reconnaissant

L'exemple de bigbaer.com/ est effectivement une idée à creuser, il est dommage de constater que cela ne fonctionne ni sous firefox, ni sous Internet explorer 6, par contre rien à redire sous Opéra et sous Internet Explorer 7. [MOD je pousse un peu ] L'argument est valable pour la largeur écran : il n'est pas nécessaire de travailler au-dessus d'une certaine largeur, du moment que cela reste consultable La pas tout a fait d'accord : le premier à contenter est "malheureusement" le client, il m'est arrivé de nombreuses fois devoir faire des concessions à l'accessibilité des sites que je développe car le client en avait décidé autrement. Non pas qu'en tant que technicien, je donne encore pas mal de formations, et je ne compte plus le nombre de clients pour lesquels leur poste de travail est encore en 800x600 Bien sûr la cible finale est déterminante pour le choix des largeurs à utiliser, l'idéal c'est d'arriver à faire en sorte que le site soit consultable dans une résolution inférieure à celle déterminé (mais c'est beaucoup plus difficile à réaliser dans ce sens) Bon au final on se rejoint. Why not, non sérieusement, en général, il ne serait pas nécessaire de refaire toute la feuille, mais seulement quelques critères spécifique je pense. Et au final, la liste ne serait pas si grande que cela screen : pour les écrans tv : télévisions, consoles, ... handled : pocket pc, smartphones, consoles portables, ... print : imprimantes ... J'en verrais pas beaucoup plus

La j'ai un gros doute, une entreprise qui à les moyens de générer plusieurs versions différentes pour essayer de s'adapter aux différentes largeurs écran (c'est surtout la largeur qui est un point ennuyeux) va vite s'apercevoir que la mise en forme de son rédactionnel est aussi à revoir pour chaque version, ce qui signifie à chaque mise à jour il faut une mise en page spécifique, donc si tu as quatre versions, tu as quatre mises à jours à faire. En général je prend une petite dizaine de minutes pour expliquer pourquoi le choix (bon, j'avoue, je suis aidé au bureau j'ai gardé un ordi avec un vieil écran 15 pouces en 800x600, et je leur montre ce que donne les site adapté pour de plus grande résolutions, et celui que je suis en train de leur faire, pour eux au final, y a pas photo, si tu leur explique convenablement (le mieux c'est par l'exemple) que grâce a ce choix tu touches plus de visiteurs, ils sont convaincus. Oui et non, même si un site est adapté pour du 800x600 il sera plus facilement consultable sur les GSM, PDA, WEBTV, consoles... qu'un site pour du 1024x768, il pénalisera un peu les utilisateurs, mais on limite la casse. Aujourd'hui le principal problème des GSM, PDA, WEBTV, consoles... c'est qu'ils n'ont aucune norme réellement définit (surtout les GSM & PDA qui sont rare à utiliser correctement le media handled des CSS), et c'est ce qui nous complique la tache, ce serait tellement plus facile si ils respectaient les normes : une feuille CSS par media bien ficelé, et cela résoudrait pas mal de problèmes (pas tous, mais pas mal) Tu le dis bien : c'est une question de compromis, et a mon avis le 800x600 reste encore un bon compromis. Il est relativement aisé d'imposer l'accessibilité d'un site à un client quand on sait lui parler (en gros, faut lui parler argent, client potentiels et positionnement dans les moteurs de recherche, je sais c'est pas le but, mais la plupart des clients finaux, n'ont pas grand chose à faire des handicaps, du moins tant que cela ne sera pas rendu obligatoire par la législation).

Je l'ai déjà fait sur un écran plat 19 pouces panoramique, ou la largeur doit être réglé aux alentour de 1920px, (j'ai même essayé avec mon double écran en élargissant la fenêtre sur les 2 écrans => largeur de 2*1280 = 2560 pixel) je n'ai éprouvé aucune gène à consulter les sites qui sont formatés pour une largeur écran de 800px, cela fait une très grande bande de chaque coté, mais rien de gênant. C'est parce que tu vois beaucoup de vide, et apparemment cela te gène tout ce vide, mais cela ne nuit pas à la consultation du site. C'est juste une question de gout de ta part, nullement de confort à mon avis. Non pas forcement réduire, si les constructeurs des smartphones arrivent à respecter les normes, il sera possible de leur affecter une feuille de style spécifique. Ce n'est pas le cas actuellement, mais sans aller à réduire, leur proposer au moins une solution qui diminue le scroll en largeur, et formater un site pour une largeur de 800 pixel, me semble un compromis acceptable Non surtout pas plusieurs version d'un site, elle ne sont en général pas mis correctement à jours, énormément de travail supplémentaire alors qu'il est bien plus simple de choisir un compromis. Je n'aime pas vraiment les extensibles, car sur les écrans larges, c'est souvent trop pénible à lire, car les lignes de rédactionnel sont trop large. Cf ma première intervention dans le post

Surfer sur un mobile "standard" c'est vrai que c'est pas spécialement confortable, mais les différents opérateurs de mobiles proposent des smartphones à prix très intéressants, les utilisateurs de ces appareils vont être de plus en plus nombreux, et, sur ces derniers, le surf est déjà plus facile. Il est je crois grand temps de penser à ces technologies

Alors optimise énormément tes scripts et accès a la base de données, car les performances de du kimsufi n'a rien a voir avec les offres céléonet, ni avec les Vrai serveur d'OVH (qui sont eux aussi plus cher)

Reste la page, est elle en UTF8?

Par défaut sur un dédié c'est toi qui doit se charger de la partie technique (réglages d'apache, mysql, php, webmail...), si tu n'as aucune connaissance en gestion de serveur, bonjour la galère et les failles de sécurité. Un serveur Infogéré, c'est la même chose que le dédié, sauf qu'il y a des techniciens qui vont s'en charger. Les offres Infogérées ont souvent des tarifs prohibitifs, c'est pour cela que je trouve l'offre de Céléonet très intéressante. Concernant l'optimisation, cela va être plus difficile à résoudre par simple forum, tu peux toutefois ouvrir un autre topic, tu trouveras probablement un début de réponse, et je te conseille de te renseigner sur les forums spécialisés en développement

Apparement, vu le message de Yann, le problème vient des requêtes SQL puisqu'il dit : L'Ajax ne résoudra pas le problème du trop grand nombre de requêtes, il doit être possible de mettre le résultat pour beaucoup de requêtes en cache. A la base, le nombre de joueurs est bien trop important pour du mutualisé, quoiqu'il en soit, je ne saurais te conseiller de passer d'ores et déjà sur une solution supérieures (serveur virtuel ou dédié), les offres proposées chez Céléonet sont intéressantes : tout est infogéré.

Personnellement, je suis chez céléonet, pour mon site perso et pour l'hébergement de mes clients. Ne voulant pas gérer plusieurs comptes, j'avais la plus grosse offre mutualisé pouvant heberger plusieurs domaines, mais les limites sont aussi apparues, je suis donc passé au serveur virtuel, c'est une solution que tu peux envisager avant de passer au dédier. Par contre, si tes requêtes 100% de la ressource processeur du serveur (Bixeon 3Ghz), c'est qu'il y a un gros problème d'optimisation de tes scripts, il est donc important de faire le nécessaire de les optimiser un maximum, sinon, tu seras vite obligé de passer sur un dédié.

La faute à qui ? au constructeur / le revendeur ou à Microsoft ? C'est comme les lecteurs CD, cartes son aux débuts : si on ne voulait pas du lecteur CD et ou de la carte son, il était courant de se retrouver avec un pc plus cher (facturation du démontage) Aujourd'hui l'utilisateur à le choix de linux ou windows, même si il reste très difficile de trouver une enseigne qui permette le choix (Dell est un peu hors course, le particulier va plutôt dans des magasins comme Carrefour, La Fnac, ...) Paradoxalement, Microsoft est entrainé dans un engrenage assez complexe : Il est accusé d'abus de position dominante, d'intégrer des fonctionnalités dans son OS qui sont normalement supporté par d'autres outils, mais, l'utilisateur final veux pouvoir tout faire (ou presque) avec son ordinateur : j'ai régulièrement ce type de questions : => Problème tout simple de codecs non installés et réponse de l'utilisateur : On a donc un monstre commercial, qui utilise le manque de connaissance informatique de l'utilisateur lambda et qui ajoute des fonctionnalités qui servent à l'utilisateur final, et qui font que windows se démarque petit à petit des autres Os. Pour la plus grande partie des utilisateurs, cela correspond tout a fait à leur besoins, par contre, pour les utilisateurs avertis, les fonctionnalités supplémentaires ne sont souvent pas utilisées : Pour ma part, je n'utilise jamais la fonctionnalité de compression / décompression de windows, je lui préfère un autre utilitaire, je n'utilise quasiment pas IE, outlook, la suite office, leur préférant d'autres outils aux même fonctionnalités. Emettre, une opinion sur la condamnation de Microsoft n'est pas chose facile, il y a énormément d'élément à prendre en compte : Oui Microsoft est en position dominante, mais les autres Os peuvent ils convenir aussi bien à l'utilisateur lambda

Nicolas, il n'y a aucune gène pour un utilisateur de consulter un site qui est réalisé pour une résolution inférieure à la sienne. La vrai gène est uniquement pour les "designer"/"concepteurs" qui voudraient mettre plus de contenu sur une plus grande largeur. Mais, je pense que plus le site est large, plus il est "chiant" à consulter. Par exemple, pourquoi les journaux se présentent en colonne? : Tous simplement pour qu'il y ait moins de texte sur une ligne, et ainsi facilité la lecture.

A ton animation Flash il te manque un paramètre : <param name="wmode" value="transparent">

Pour répondre au problème d'Occi : aujourd'hui il n'existe aucun moyen fiable de déterminer l'unicité d'un visiteur. Pour l'ip derrière un proxy, tous les proxy ne permettent pas d'avoir l'ip finale du visiteur (c'est il me semble souvent le cas dans les grosses entreprises).

Il y a éventuellement l'usage de script perl sur le serveur : http://encodable.com/filechucker

Je pense en effet que la syntaxe wiki correspond à la meilleure alternative pour les utilisateurs non-voyants

Malheureusement, le résultat n'est jamais certain, il est lié au bon vouloir du juge et à mon avis à sa connaissance du monde du net. J'ai une cliente qui à acheter un NDD en .com correspondant au nom exact de sa boutique, sa concurrente la plus proche : une cinquantaine de mètres ayant exactement la même activité, mais i, nom totalement différent à acheté le même NDD mais en .fr, au passage cette concurrente avait aussi acheté prenom-nom.com (le prenom et le nom correspondant à ceux de ma cliente). Il à été jugé que ma cliente récupérait le prenom-nom.com car il y avait usurpation d'identité flagrante, mais n'a pas pus récupéré le .com correspondant au nom de sa boutique.