Archives taggées avec ‘php’

Installer Composer sur un synology sous DSM 6

Si vous disposez d’un NAS Synology sous DSM6 et que vous souhaitez utiliser Composer pour créer des projets PHP, cet article peut vous aider !

Prérequis

En prérequis, je considère comme acquis les points suivants :

  • Votre accès SSH est opérationnel,
  • Web Station est activée,
  • Vous avez installé PHP 5.6 et/ou PHP 7 sur votre NAS,
  • L’extension « phar » est active au moins dans la configuration PHP de la version avec laquelle vous souhaitez utiliser Composer.

Installation de Composer

La première chose à savoir – je suis tombé dans le panneau et c’est la raison de ce billet – c’est que votre NAS est équipé d’une version de PHP dédiée à l’exécution du DSM. Cette version n’est pas utilisée par Web Station. C’est-à-dire qu’en tapant php en ligne de commande, c’est le PHP interne qui se lance et qui est limité au niveau de ses extensions (je me suis retrouvé confronté à l’absence de « tokenizer » en souhaitant installer un logiciel). Les autres versions de PHP sont accessibles depuis les commandes php56 et/ou php70 ; qui sont installées dans /usr/local/bin.

Je vous propose donc d’installer Composer globalement au serveur dans le même répertoire que les différentes versions PHP installées ; parce que taper du php56 composer.phar, ça va deux secondes…

Commençez donc par ouvrir votre accès SSH :

$ ssh yourname@ip

Accédez au compte root :

$ sudo -i

Déplacez-vous dans le répertoire où nous installerons Composer :

$ cd /usr/local/bin

Installez Composer :

$ curl -s http://getcomposer.org/installer | php56
 All settings correct for using Composer
 Downloading...

Composer (version 1.3.1) successfully installed to: /usr/local/bin/composer.phar
 Use it: php composer.phar

Comme composer.phar utilise par défaut la commande php nous devons créer une commande qui permet d’outrepasser ce comportement. Créons donc ce script :

$ vi composer

Enregistrez le contenu suivant (tapez « i » pour passer en modification de contenu) :

!/bin/bash
php56 /usr/local/bin/composer.phar $*

Tapez Echap pour quitter le mode modification puis :wq pour enregistrer et fermer le fichier.

Rendez le script exécutable :

$ chmod +X composer

Quittez le mode root :

$ exit

Testez pour finir que la commande fonctionne correctement :

$ composer --version
Composer version 1.3.1 2017-01-07 18:08:51

Si la version s’affiche correctement, c’est tout bon !

Qu’est-ce que REST ?

Apache, Lighty, LiteSpeed, Nginx, que choisir ?

Depuis peu, je dispose d’un hébergement d’une part chez Gandi.net. J’ai craqué dernièrement pour un serveur dédié virtualisé ; j’en ai marre de mon hébergement mutualisé (besoin de plus de flexibilité et d’espace disque). Une part d’hébergement chez Gandi correspond à 256Mo de RAM. C’est très correct pour héberger des petits sites à faible trafic (ce qui est mon cas 😀 ) mais cela peut vite devenir faible : avoir son propre serveur ouvre des possibilités et donc une consommation potientielle plus grande des ressources.

Initialement installé avec Apache + PHP5 + MySQL, la consommation du serveur est montée en flèche : quasiment 200 Mo pour un seul site hébergé…Je n’ai cependant pas qu’un serveur web mais aussi un serveur Teeworlds pour jouer de temps à autre (~ 15 Mo en RAM). Je suis donc en train de reconsidérer l’installation du serveur web.

Après quelques recherches, trois alternatives à Apache sont possibles (Apache c’est bien mais c’est « mémoirophage ») :

  • Lighttpd (Lighty), utilisé par YouTube, un seul process pour 10000 connexions simultannées, une consommation mémoire moindre, mais apparamment quelques problèmes de fuites mémoire.
  • LiteSpeed, plus commercial, une version standard gratuite est disponible.
  • Nginx (prononcez EngineX), un petit serveur ultra léger, optimisé et sécurisé qui a le vent en poupe.

L’ennui dans tout ça, c’est que je ne sais pas quel serveur choisir…Lequel prendre pour avoir le meilleur compromis performances / fonctionnalités sachant que je souhaite disposer d’un serveur pour pouvoir exécuter des scripts PHP et Ruby On Rails ?

Je fais donc appel à vous, chers lecteurs de ce blog, pour me retourner vos expériences et ainsi me guider dans mon choix ! (pour l’instant ma préférence va à Nginx…)

echo VS printf

Voilà le genre de test que j’aurais bien fait si j’avais le temps. Mais nous sommes nombreux sur la toile et il n’est pas toujours nécessaire de tout faire soi-même 😉

Si vous êtes développeur, vous connaissez certainement le sempiternel débat qui oppose les fonctions PHP echo et printf ? Et bien voilà de quoi vous mettre sous la dent : un test complet sur les performances des différentes possibilités de concaténations de chaînes et de leur affichage.

Au final, echo s’avère plus rapide que printf mais la différence n’est pas énorme. En revanche, le test met en exergue l’impact de l’utilisation des guillemets (doubles quotes dans le jargon) sur la rapidité de traitement face aux chaînes contenues entres apostrophes (simples quotes…). Et là, les différences sont bien plus importantes : que vous utilisiez l’une ou l’autre des fonctions, l’utilisation des guillemets plombe le traitement d’une seconde (sur un échantillonnage de 500 000 concaténations) ! Une seule chose à retenir (on ne le dira jamais assez), utilisez dans la mesure du possible des chaînes à apostrophes dans vos scripts PHP !

Pour la petite histoire, sachez que lorsque vous utilisez une chaîne entre guillemets, PHP lance son moteur d’analyse de chaînes pour remplacer les éventuels caractères spéciaux (\n, \t, \r…) ou remplacer les variables que vous auriez pu placer directement au sein de la chaîne. Dans une chaîne entre apostrophes, PHP n’effectue pas d’analyse de chaîne et la traite « brute de fonderie » ; d’où le gain temporel.

Bref que du bon pour un article qui vient relancer un site qui manquait d’activité ces derniers temps et qui vient de subir un relooking plutôt sympa 😉 . Affaire à suivre !

L’article chez EXinsidePHP »

Albulle 1.0 finale !

Logo AlbulleCe n’est pas sans une certaine émotion que je suis fier et heureux de vous annoncer la sortie de la première version stable d’Albulle !

Commencé en 2005, il aura fallu 3 années pour arriver à ce résultat. C’est effectivement énorme ! Mais ce sont 3 années à essayer de trouver du temps pour faire avancer le projet, corriger les erreurs, améliorer le script, ajouter des fonctionnalités pour que le plus grand nombre d’entre vous puisse disposer d’une solution simple, souple et fonctionnelle.

Pour promouvoir Albulle, j’ai lui ai créé un petit site que je vous invite à découvrir de ce pas !

http://albulle.jebulle.net

Pour conclure, je tiens à remercier tous ceux qui ont de près ou de loin participé à l’avancement du projet : nouvelles idées, aides, remontées de bogues, suggestions, critiques, corrections, … !

Du fond du coeur : merci à tous !