Je vais vous décrire ici mon installation "parfaite" d'une ubuntu Interpid Ibex.
Au programme, LVM chiffré et ubuntu avec Gnome minimale
mercredi, novembre 5 2008
Intrepid Ibex - Installation "nécessaire mais suffisante" - sur Aspire One
Par Wam mania le mercredi, novembre 5 2008, 10:45 - Ubuntu
mercredi, septembre 10 2008
Aedituus 2.0.0
Par Wam mania le mercredi, septembre 10 2008, 12:48 - Aedituus
Pour ceux qui ne savant pas, (c'est à dire tous ceux qui ne m'ont pas contacté par mail), la version 2 de l'Aedituus est en cours d'écriture. Je voulais ici éclaircir les fonctionnalités futures, ainsi que le direction que prendra le projet. Une version béta est déjà en train de se faire sévèrement corrigée. J'espère pouvoir sortir une version finale assez vite.
vendredi, août 29 2008
Be a javascript rock star !
Par Wam mania le vendredi, août 29 2008, 16:45 - Jquery
Jquery a pété un câble, mais j'adore.
Petit post qui sert à rien, mais je voulais montrer la nouvelle bannière du nouveau style du site de jquery
lundi, août 25 2008
Framy - Partie 4 - Url-rewritons !!
Par Wam mania le lundi, août 25 2008, 20:24 - Framy
Cet article fait suite à la partie 3
Nous voici donc arrivé à cette grosse partie.
Je vais commencer par expliquer ce qu'on cherche à faire.
Une application est constituée de un ou plusieurs contrôleurs, contenant des actions étroitement liées au contrôleur.
Nous allons créer un contrôleur application, contenant 1 action : helloworld qui prendra en paramètre la langue (en ou fr), ainsi que la période de la journée (matin, aprem, soir, nuit)
Nous devons maintenant appeler ce couple contrôleur/action.
Pour les pressés, voici le code complet de notre Url Rewriting :
Télécharger le code complet
C'est nul, il veut même pas lire mon .doc
Par Wam mania le lundi, août 25 2008, 15:19 - Ubuntu
Le prochain qui me sort ça, je le sors à coup de pied dans c**
Retournons le problème !
Il y a d'un coté le monde, ses lois, ses normes, ses utilisateurs, l'harmonie entre toute chose et d'un autre coté Microsoft.
Faut-il changer tout pour le rendre compatible microsoft ou faut-il changer microsoft pour être compatible avec le reste ?
De nombreux utilisateurs ne comprennent pas pourquoi les "autres" -comme ma tendre ubuntu- n'ont pas essayé d'être compatible avec Windows notamment niveau ergonomie utilisateur. Je leur répond en général que les développeurs d'ubuntu n'ont pas réussis à être aussi mauvais.
Mais la vraie réponse est que l'utilisateur est un boulet (pour être poli). On préfére accepter la vente liée (pourtant interdite), les virus, la licence qui coûte la peau du c**, l'installation des drivers/programmes de tierces parties inconnues desfois difficiles à trouver, les changements imposés de version avec des soucix de compatiblité entre elle, etc....
plutôt que de changer des habitudes et éventuellement de devoir réfléchir qqs mins.
Vous savez quoi, ce p..... de word ne lit pas mon .odt
Gros bisous à ma copine qui vient enfin de passer à ubuntu ce week-end, après que son pc, désirant continuer à travailler même sans elle, ait envoyé des messages de pubs à tous ses contacts yahoo et ai changé son message d'absence. Elle a maintenant un beau bureau tout rose ;)
Pour elle, comme pour toi, futur ubuntien
http://www.framabook.org/ubuntu.html
http://www.ecrans.fr/Linux-Le-journal-d-un-novice,4666.html
mardi, août 19 2008
Nouveau thème - spécial daltonien
Par Wam mania le mardi, août 19 2008, 17:33 - Osef ta life
Etant moi même daltonien, je ne suis pas vraiment sûr de l'harmonie générale du site.
En tout cas, chez wam, y a de la couleur maintenant, et à l'époque de la télé, c'était vraiment un progrès !!
N'hésitez pas, daltonien ou non, à me signaler par commentaire ceux qui ont perdus leurs yeux ou -au contraire- ceux qui ont l'impression de voir une toile de Van Gogh dans ce thème.
PS : Un daltonien est qq'un ayant des problèmes de vison des couleurs (vert et/ou bleu et/ou rouge). Personnellement, j'ai une protanomalie : "présence d'une mutation du pigment de la vision du rouge ; la sensibilité à cette couleur est diminuée."
lundi, août 18 2008
Knol - Ou comment troquer le savoir contre du fric
Par Wam mania le lundi, août 18 2008, 15:17 - The web
Voila un bon post copier/coller, mais je devais relayer l'info !
http://www.oric-ak.fr/post/2008/07/30/Knol-soupe-de-Wikipedia
Knol est un nouveau service de google, actif depuis le 23 juillet 2008 et permettant à des auteurs non anonymes de publier des articles sur lesquels sera affichée de la pub google que l'auteur et google se partageront.
En gros, pour troller sec, google va racheter les auteurs de wikipedia, car wikipedia a toujours refusé la pub de google.
J'invite donc mes 100 000 visiteurs par jours à ne pas knoler !!
Framy - Partie 3 - (Episode -51, Là ou tout a vraiment commencé)
Par Wam mania le lundi, août 18 2008, 12:29 - Framy
Cet article fait suite à la Partie 2
Avant de commencer à compliquer le bouzin, et surtout, avant de commencer l'url-rewriting, je me suis dit que présenter tout de suite l'objectif final permettrait sûrement de gagner beaucoup de temps. Pour cela, je me suis replongé dans l'UML2, mais j'avoue que je galère, c'est pas trop mon truc les blocks (je préférais les patates).
Alors, étudions un peu ça. Tout d'abord, il ne faut surtout pas avoir peur !
Le commencement, c'est la méthode yBoot::launch() qui sera appelée par exemple dans l'index.php Cette méthode static crée 2 objets :
- $resquest (yRequest)
- $response (yResponse)
La classe yRequest contient les attributs et méthodes nécessaires à l'analyse de la requête de l'utilisateur. C'est elle qui va déterminer le couple contrôleur/action à utiliser à travers les différents classes de traitement de l'URL disponibles.
La classe yResponse contient simplement la réponse que Framy enverra au navigateur, ce qui comprend entête HTTP et contenu.
On crée ces classes dans le boot pour
- Déterminer le couple contrôleur/action ainsi que les paramètres.
- Valider la requête et si besoin, envoyer une erreur 404
- Charger la configuration globale de Framy (que nous ne verrons pas du tout ici)
- Lancer l'application (ie : Instancier le contrôleur et lancer l'action)
Ensuite, l'ensemble des pouvoirs est transmis au contrôleur (applicationController est un contrôleur arbitraire pour servir d'exemple). N'oublions pas que le contrôleur hérite de la classe abstraite yController, qui possède tout ce dont on a besoin, et qui va récupérer au passage l'objet $request et l'objet $response (regardez donc le constructeur de yController).
Voila, maintenant que les choses sont claires, nous pouvons commencer à travailler sur chacune des parties. A commencer bientôt par l'url-rewriting.
jeudi, août 14 2008
Compiz-fusion sur Ubuntu (Hardy Heron 8.04 LTS)
Par Wam mania le jeudi, août 14 2008, 19:59 - Ubuntu
Certes, ce n'est pas un scoop, mais j'aime, alors je montre.
Ubuntu gagne de plus en plus de terrain, et quand on voit la progression à chaque nouvelle version, on comprend pourquoi !
Toi, avec ton vista, regarde ce qu'on fait en quelques minutes, et pleure !
Url rewriting sur dotclear
Par Wam mania le jeudi, août 14 2008, 16:55 - The web
mmmm
Je viens de me rendre compte que dotclear ne propose que 2 choix pour la réécriture d'URL.
- Le QUERY_STRING, c'est à dire par l'utilisation de $_SERVER['QUERY_STRING'] qui consiste globalement à parser tout ce qui suis le ? dans l'adresse. Ainsi on aurait http://www.wamania.com/index.php?/url-rewriting-sur-dotclear.
Pourquoi c'est mal?
Déjà parce que c'est moche ! Ensuite parce que google n'aime pas. Dès qu'il y a un ?, il zappe.
- Le PATH_INFO, utilisé avec une option d'apache (souvent dans le virtualhost) : le MultiViews
<Directory /var/www/wamania.com>
Options MultiViews
....
</Directory>
Pour expliquer, voici un exemple :
Nous prenons l'URL
http://www.wamania.com/index/url-rewriting-sur-dotclear
En gros, on a tout écrit sous forme de répertoire. En effet, si apache ne trouve pas de répertoire avec le bon nom (ici index) alors il cherche les fichiers possibles, et trouve donc index.php, ce qui suis étant transformé ensuite en QUERY_STRING. Ceci permet d'avoir des URL sans .php? mais laisse quand même un /index/ pas cool, et surtout beaucoup de contraintes (si un répertoire existe, il est prioritaire sur le fichier !)
Bref, tout ça, c'est de l'URL-bidouilling.
Pour un vrai URL-rewriting, il faut absolument avoir le mod_rewrite d'apache activé sur son hébergement !
Le plus simple à mon avis, c'est de configurer dotclear pour le QUERY_STRING (le PATH_INFO necessite l'option MultiViews d'apache, et est plus contraignant), en mettant en url http://toto.com/
Il nous reste maintenant à rediriger vers notre ancien index.php?
Nous utilisons pour cela un fichier .htaccess à placer à la racine du blog
<IfModule mod_rewrite.c>
RewriteEngine On
## Si le blog n'est pas à la racine du site !
#RewriteBase /blog
## Si le fichier/dossier existe, on passe son chemin
## Ca evite de réécrire les adresses des images par exemple
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
## et enfin, on réécrit
RewriteRule ^(.*)$ index.php?$1 [L,QSA]
</IfModule>fonction addslashes
Par Wam mania le jeudi, août 14 2008, 15:49 - PHP5
La méthode addslashes est mondialement connue pour échaper les ' ou les " dans les chaînes de caractères à destination de requète SQL. Ca, c'est ce que tout le monde croit.
Suite à un entretien dernièrement ou j'ai passé un test de PHP dans lequel on me demandait - encore - de choisir entre 4 choix pour empêcher les injections SQL.
ET BAH C'EST PAS ADDSLASHES !!!
J'avais envie de le crier haut et fort.
Quelques explications :
Les véritables méthodes d'échappement d'une requète liée à une base sont les méthodes propres à ces bases !
Par exemple, la fonction PHP mysql_real_escape_string n'est utilisable QUE si la connexion à MySQL est ouverte. Cela car c'est belle et bien MySQL qui échappe la chaîne et non PHP.
Ainsi, toutes les bases de données ont leurs méthodes d'échappement, et les fonctions PHP qui les appellent :
- mysql_real_escape_string
- pg_escape_string
- db2_escape_string
- dbx_escape_string
- maxdb_escape_string
- mysqli_escape_string
- sqlite_escape_string
L'arrivée de composant comme PDO permet de s'abstraire de tous ces problèmes (à condition de ne pas faire n'imp). Je conseille personnellement de ne plus utiliser que ça. Ca évite d'avoir à réfléchir sur des problèmatiques de sécurité seul dans son coin alors qu'une communauté bien plus forte que toi le fait à ta place !
Bon, sinon, pourquoi addslashes c'est pas bon ? Simplement à cause d'une 'confusion' entre single-byte et multi-byte string.
En single-byte string, 0xbf27 devient 0xbf (¿) suivi de 0x27 ('), c'est à dire (¿'). Ceci car 0xbf27 n'est pas un multi-byte valide. Si on passe ceci dans addslashes, on obtient 0xbf5c27, c'est à dire ¿\' en single-byte string. Seulement voila 0xbf5c est un multi-byte string valide, du coup, la chaîne devient 縗 ' Et voila notre ( ' ) qui n'est plus échappé.
Framy - Partie 2 - Le contrôleur
Par Wam mania le jeudi, août 14 2008, 13:59 - Framy
Cet article fait suite à celui-ci : Partie 1 - Pourquoi utiliser un framework MVC
Je vais vous présenter ici la base du début du commencement d'un bon contrôleur dans une optique MVC. Tout d'abord, un peu de théorie. Selon wikipedia "Le contrôleur prend en charge la gestion des évènements de synchronisation pour mettre à jour la vue ou le modèle et les synchroniser.". Ce qui signifie que le contrôleur est appelé à chaque évènement lié à l'utilisateur (en tout cas dans le web). Il va ensuite synchroniser la vue et le modèle en fonction de la requète. Attention cependant, si le contrôleur est le "système nerveux" du programme, il n'est pas le cerveau. En effet, l'ensemble des classes "métiers" nécessaires au traitement des informations seront à l'extérieur du MVC, et seront appelées si besoin par le contrôleur. Au final, le contrôleur est le coordinateur de notre programme. Ce qui signifie que tout commence par lui et tout fini par lui (en tout cas, d'un point de vue extérieur au framework). Chronologiquement, le framework va analyser la requète, puis va déterminer :
- Le contrôleur à utiliser
- L'action à appelée
- Les paramètres supplémentaires.
Le couple contrôleur/action se cherchera de coordonner les différents acteurs pour finir (en général) par l'envoi de la vue.
Par exemple, voici un contrôleur et quelques actions typiques pour gérer les utilisateurs d'un espace membre.
class userController {
// On va détailler un peu cette action
function register() {
// On attend ici dans les paramètres le pseudo et le pass du user
if (empty($this->params['pseudo'] || empty($this->params['pass'])) {
$this->render_view('formulaire_incomplet.tpl');
} else {
// on insere
$user = new User($this->params['pseudo'], $this->params['pass'] );
if ($user) {
$this->render_view('inser_user_success.tpl');
} else {
$this->render_view('inser_user_failed.tpl');
}
}
}
function update() {
// On attend ici en paramètre l'id du user à modifier et le pseudo et/ou pass à modifier
}
function delete() {
// On attend ici l'id du user à supprimer
}
function login() {
// On attend ici l'id du user à connecter
}
function logout() {
// On attend ici l'id du user à déconnecter
}
}
La jonction formulaire <-> base de donnée est la partie la plus redondante, la plus pénible et la plus grande source d'erreur de tout programme web. Le but du contrôleur est de simplifier et centraliser tout ça.
Parlons justement de centralisation. Jusqu'ici, hormis ressembler les fonctions, on a pas encore grand chose. On a déjà vaguement aperçu le modèle User, ainsi que la méthode $this->render_view encore inconnue. Concentrons nous sur ce qu'il y a à rassembler pour que notre classe contienne TOUT ce dont elle a besoin:
- Le modèle
- La vue
- La session
- Les paramètres d'entrées
class userController {
private $db;
private $view;
private $session;
private $params;
// Lié au fonctionnement
private $data;
public __construct() {}
public register() {}
public update() {}
public delete() {}
public login() {}
public logout() {}
// Nouvelle méthode, vu au paragraphe avant, qui serivra à afficher une vue
private render_view() {}
}
Dans ces quelques lignes, il y a toute l'architecture de notre espace membre. Toutes les variables extérieures sont accessibles à chaque action. Reste maintenant à alimenter ces variables, et à rendre nos actions appelables par un visiteur.
Mais avant tout, regardons de plus prêt notre classe. Nous l'avons créée pour gérer un espace membre, or un site n'est jamais constitué de si peu. Il va nous falloir utiliser d'autres contrôleurs pour les autres contextes, par exemple sur une galerie d'images, il nous faudra gérer les images.
Pour cela nous allons créer un contrôleur imageController qui devra lui aussi utiliser les sessions, les paramètres, les vues, etc. Grâce à l'héritage, nous allons pouvoir créer une classe Controller mère dont chaque controller héritera. Cette classe mère se chargera des variables et méthodes communes. Ainsi, nous aurons :
abstract class Controller {
/**
* Notre modèle
*/
protected $db;
/**
* Notre vue
*/
protected $view;
/**
* La session
*/
protected $session;
/**
* Les paramètres POST et GET
*/
protected $params;
/**
* Un tableau qui contiendra se qu'on enverra à la vue.
* La vue ne disposera que de ces données et aucune autre
*/
protected $data;
/**
* Constructeur
*/
public function __construct() {}
/**
* Méthode privée appelée par chaque action et qui se chargera de la vue.
*/
protected function render_view() {}
}
Ce qui permet de simplifier notre contrôleur :
class userController extends Controller{
public register() {}
public update() {}
public delete() {}
public login() {
// Notre vue n'étant pas encore écrite, nous utiliserons un simple echo
echo 'Hello World';
}
public logout() {}
}
Testons maintenant notre contrôleur. Il faut pour cela avoir un moyen pour se diriger vers le bon couple contrôleur/action en fonction de la requète. Nous ferons très simple pour commencer :
Placer ceci dans un fichier index.php
// La classe abstraite
require_once 'controller.php';
// Notre controleur user
require_once 'userController.php';
if (isset($_GET['controller'])) {
$controller = $_GET['controller'];
} else {
// On peut mettre un contrôleur par défaut
}
if (isset($_GET['action'])) {
$action = $_GET['action'];
} else {
// On peut mettre une action par défaut
}
$oController = new $controller;
$oController->$action;
Il vous reste à appeler l'adresse correspondante, par exemple en local, si les fichiers sont dans le répertoire framework, nous appelerons http://localhost/framework/index.php?controller=user&action=login
Cette partie est maintenant finie. Nous verrons dans la prochaine partie la réécriture des urls car il est clair qu'une url comme celle du dessus n'est pas très sexy sur un site sérieux. Nous verrons aussi, dans les différents articles qui suivront, comment améliorer nettement la classe abstraite par l'ajout de nombreuses fonctionnalités, notamment la pagination, les filtres, le cache, etc...
Framy - Partie 1 - Pourquoi utiliser un framework MVC
Par Wam mania le jeudi, août 14 2008, 12:01 - Framy
Un framework se défini par "cadre d'application". Le MVC signie Modèle Vue Contrôleur. Il s'agit d'un design pattern consistant à séparer la vue (ce qu'on voit dans le navigateur), le modèle de données (le plus souvent l'accès à la base) et le contrôleur qui fait la jonction. Cette définition est en fait un peu simpliste, mais permet de bien voir le rôle de chacuns. D'une manière générale, l'utilisation de design pattern et notamment celui du MVC demande du temps pour étre assimilé. D'autant plus qu'on le retrouve souvent dans des frameworks beaucoup plus riches en général. Je ne m'intéresse ici à aucun framework en particulier, mais juste au pattern MVC. Le but final de tous ces articles sera d'avoir une vue d'ensemble bien construite de ce qu'un framework typique peut proposer.
PHP est longtemps resté un langage réputé "pour débutant" et donc peu prisé par les entreprises, notamment à cause de son coté "bordel". En effet, avec php, il n'y a pas séparation entre le coté serveur et le coté client, ce qui veut dire que le même fichier peu contenir
- du php
- du SQL
- du javascript
- du CSS
- du (X)HTML
Non seulement ces langages peuvent se retrouver tous ensembles dans la même page, mais en plus, depuis l'avènement d'AJAX, on peut réaliser des appels de la page sur elle-même en ajax ou en http traditionnel. On perd vite les pédales entre tous les appels, tous les langages, ajax pas ajax, et pour peu qu'on ajoute un formulaire, des redirections conditionnelles (qu'on peut réaliser en php avec header(), en html ou en javascript avec window.location et c'est fini la page seule est devenue un godzilla incontrôlable qu'il va falloir abattre.
D'un point de vue plus théorique, l'utilisation du MVC permet de revoir toute la structure d'un programme (j'utilise le terme "programme" et non "site"). En effet, la méthode courante stipule qu'une bonne séparation des différents acteurs implique leur écriture dans des fichiers séparés. Ce qui se résume en gros par : la structure du programme est la structure des fichiers ET la structure des fichiers est la structure du programme. C'est en fait une horreur de conception. Penser comme ça signifie qu'on ne fait pas ce qu'on doit faire, mais ce qu'on peut faire, il signifie que le fonctionnel n'est réfléchis qu'après l'opérationnel. En gros, ça signifie que le programme est mal ou pas pensé (Attention, je ne dis pas le prog est mauvais, je dis juste qu'il est pensé à l'envers).
Pour illustrer un peu, je vais prendre un espace membre tel qu'il est fait dans 90% des cas. On retrouve donc un fichier connection.php, un fichier inscription.php, un fichier passperdu.php et un fichier "protégé" index.php. Chacun d'eux utilise les fichiers fonctions.php, classes.php, db.php Lorsqu'on arrive sur index.php, la page est protégée, et redirige vers connection.php pour que le gars se loggue, elle inclue donc fonctions.php qui va probablement définir des fonctions bourrées de variable globales ou de avoir des paramètres excessivement élevés, classes.php qui définira sûrement les méthodes pour gérer l'espace membre et enfin db.php
Que peut-on faire pour simplifier ? Simplement rassembler les acteurs par intérêt et non par chronologie.
class user {
private isConnected = false;
private user_id = null;
function connection() {
}
function inscription() {
}
function passperdu() {
}
function isConnected() {
}
function isLoginAlreadyExists() {
}
function changePass() {
}
// ..........
}
Il est possible que l'interêt majeur du MVC vous échappe encore, et c'est normal sans exemple concret. Sachez cependant qu'avec ceci, il est déjà possible de voir les futures possibilités. Par exemple, en conservant le format class/méthode (qu'on nommera contrôleur/action), on pourra définir une norme pour la réécriture d'URL. Par exemple http://toto.com/user/connection appelera automatiquement le méthode connection de la classe user.
N'hésitez pas à fouillez dans la réécriture d'URL avec ou sans apache.