juin
2009
dans un précédent article nous avons vu comment convertir un texte en utf8.
aujourd’hui on va voir comment faire la même chose mais avec un tableau, sans passer par un foreach, ni aucune autre boucle.
pour cela nous allons utiliser une seule fonction qui convertira ce qu’on lui donne en entrée en utf8.
pour l’instant elle va savoir gérer, les chaînes de caractères et les tableaux.
function toUTF8($param) { if(is_array($param)) { array_walk_recursive($param, create_function('&$item, $index', '$item = toUTF8($item);')); return $param; } mb_detect_order('UTF-8, ISO-8859-15, ISO-8859-1, Windows-1252'); //parfois si le dernier caractère de la chaine est accentué, la conversion peut foirer, //donc on force avec un caractère qui ne l'est pas. //(astuce trouvée sur les commentaires de la doc sur php.net) $param .= '_'; $currentCharset = mb_detect_encoding($param); if ($currentCharset != 'UTF-8') { $param = mb_convert_encoding($param, 'UTF-8', $currentCharset); $param = substr($param, 0, strlen($param)-1); return $param; } return $param; } |
et voilà, cette fonction convertira array ou string en utf8 sans brancher…
en bonus voici une fonction somme que j’ai trouvé dans les commentaire de la doc sur php.net (une sorte de coup de coeur pour moi :-D)
function sum(){ $s=0; foreach(func_get_args() as $a) $s+= is_numeric($a)?$a:0; return $s; }; print sum(1,2,3,4,5,6); // will return 21 print sum(3,2,1); // will return 6 print sum(false,array(),5,5); // will return 10 |
trop fort non ?
(2 votes, note : 4,50 sur 5) Catégories : PHP / MySQL, Programmation | Pas de commentaires
mai
2009
Nous avons vu dans précédent article comment protéger un répertoire avec htaccess, c’est l’utilisation la plus courante de cette technique, mais ici nous allons nous intéresser a comment faire la même chose mais pour protéger uniquement un ou quelques fichiers d’un répertoire, c’est à dire, dans le même répertoire, certains fichiers seront protégés mais pas d’autres.
pour protéger un seul fichier voici ce qu’il faut mettre dans le .htaccess :
<Files fichier.ext> require valid-user </Files> |
pour en protéger plusieurs :
<Files fichier1.ext fichier2.ext fichier3.ext> require valid-user </Files> |
cette syntaxe est a utiliser en complément de celle expliquée dans l’autre article bien sûr.
bonne protection de fichiers…
(1 votes, note : 3,00 sur 5) Catégories : Divers, Programmation | Pas de commentaires
avr
2009
Il fut un temps où on ne se posait pas de question quant au serveur web, on prend Apache et on en parle plus, aujourd’hui les choses ont changé, Apache reste quand même le plus utilisé avec plus de 66% des parts de marché, suivi par IIS, puis tous les autres “petits” derrière, néanmoins en fonction des besoins, certains de ces petits peuvent s’avérer bien plus performants qu’Apache, aujourd’hui on va tester 3 configurations possibles avec Apache et Lighttpd.
d’après ce qu’on peut lire un peu partout sur le net, Lighttpd (lighty pour les intimes) est beaucoup plus performant quand il s’agit de servir des pages statiques, mais qu’en est-il vraiment ? et comment s’en sort-il avec le contenu dynamique ? (des sites statiques ça n’existe plus de nos jours ^^).
pour notre test, on va prendre un site très léger, basé sur Zend framework (donc loin d’être statique), contenant une page qui affiche 9 images au hasard a partir d’une tables mysql contenant environ 1000 enregistrements (seulement les emplacement des images sont stockés dans la base). Le serveur de test est un kimsufi L (petit processeur et 1Go de RAM).
versions utilisées :
Apache 2.2.9
Lighttpd 1.4.19
PHP 5.2.6
pour les tests on utilise siege, on lance donc un siege avec 100 concurrency sur 10 minutes, voici la commande :
siege -c100 -t10M URL_DU_SITE
on note également le Load average de la machine a la fin de l’opération.
1ère configuration : Lighttpd tout seul
voici le resultat :
Load average : 4.87 Lifting the server siege... done. Transactions: 23859 hits Availability: 100.00 % Elapsed time: 600.37 secs Data transferred: 83.25 MB Response time: 2.02 secs Transaction rate: 39.74 trans/sec Throughput: 0.14 MB/sec Concurrency: 80.21 Successful transactions: 23859 Failed transactions: 0 Longest transaction: 5.20 Shortest transaction: 0.10
2ème configuration : Apache2 tout seul
le résultat :
Load average : 77.51 Lifting the server siege... done. Transactions: 23543 hits Availability: 100.00 % Elapsed time: 599.66 secs Data transferred: 82.16 MB Response time: 2.04 secs Transaction rate: 39.26 trans/sec Throughput: 0.14 MB/sec Concurrency: 80.22 Successful transactions: 23543 Failed transactions: 0 Longest transaction: 10.51 Shortest transaction: 0.05
3ème configuration : Lighttpd + Apache
maintenant faisons le test en couplant les 2, dans cette configuration tout ce qui est statique (images, css, js, etc.) sera servi par lighty alors que les scripts php eux, seront traités par apache, pour cela on active le mod_proxy dans lighty, et on ajoute le code suivant dans le vhost de notre site :
$HTTP["url"] !~ "\.(js|css|gif|jpg|png|ico|txt|swf|html|htm)$" {
proxy.server = ( "" => (
( "host" => "127.0.0.1", "port" => 8080 )
)
)
}
vous l’aurez compris, Apache écoute sur le port 8080 (c’est fait en changeant le fichier /etc/apache2/ports.conf).
voici le résultat :
Load average : 14.79 Lifting the server siege... done. Transactions: 22684 hits Availability: 100.00 % Elapsed time: 600.25 secs Data transferred: 79.10 MB Response time: 2.13 secs Transaction rate: 37.79 trans/sec Throughput: 0.13 MB/sec Concurrency: 80.53 Successful transactions: 22684 Failed transactions: 0 Longest transaction: 8.61 Shortest transaction: 0.07
plutôt surprenant !
Conclusion :
Lighty s’en sort très bien au vu des transactions/s (ou le nombre total de transactions traitées), contrairement a ce qu’on pouvait attendre, coupler les 2 nous fait perdre en performances (on enregistre quand même un load average nettement inférieur a la config d’apache tout seul).
personnellement ce que je retiens, c’est que lighty n’est pas si mauvais que ça pour le contenu dynamique, les performances restent quand très proches dans les 3 cas, donc autant utiliser la solution qui nous plait :-)
(aucun vote) Catégories : Divers, Linux - Logiciels | Commentaires (2)
mar
2009
Ou comment permettre à un utilisateur se saisir plus facilement dans un formulaire des données a longueur fixe, ou de format spécifique (dates, numéros de téléphone, etc.) sans se préoccuper du formatage.
C’est un plugin pour jQuery, il a été testé sur Internet Explorer 6 / 7, Firefox 1.5/2/3, Safari, Opera et Chrome.
Son fonctionnement :
on va prendre un champ date au format dd/mm/YYYY pour l’exemple :
quand le champ du formulaire reçoit le focus, le plugin va automatiquement pré-remplir le champ avec “__/__/____” et votre saisie va automatiquement remplacer la chaine par défaut, ainsi pour une date vous n’aurez pas a saisir les / juste les information de la date, ce qui est quand même par mal pour l’utilisateur final.
vous trouverez plus d’exemples sur cette page : Masked Input Plugin
l’onglet “usage” vous sera de grande utilité pour la partie implémentation et utilisation.
voici une vidéo pour illustrer quelques exemples :
(2 votes, note : 5,00 sur 5) Catégories : Divers | Pas de commentaires
mar
2009
IE 8 a été annoncé en version finale lors du MIX09 de Microsoft qui s’est déroulé du 19 au 20 mars à Las vegas. Tout le monde peut le télécharger depuis le 19 mars.
Du coté des développeurs cette version est très attendue, surtout après une version 7 un peu décevante… Donc qu’en est-il avec cette nouvelle version ?
Chez nous les développeurs, la règle d’or est : “on ne réinvente pas la roue !”, du coup au lieux de vous faire un article en 30 pages, je vais juste relayer un super article fait par Alsacréations avec toutes les nouveautés d’IE8, tout ce qu’il supporte, ne supporte pas, etc. en résumé : un article complet sur IE8, bonne lecture…
(aucun vote) Catégories : Divers, Windows - Logiciels | Pas de commentaires