Vous conaissiez Jamendo ?
Vous savez, ce site ou on trouve des milliers d'heures de musique libre !
dimanche, août 5 2007
My Jamendo Favorites albums :-)
Par knoodrake le dimanche, août 5 2007, 11:11 - Web
mercredi, mai 30 2007
Quelques photos
Par knoodrake le mercredi, mai 30 2007, 19:05 - Photographie
J'ai publié quelques nouvelles photographies faites ces derniers temps et que je n'avait pas trouvé le temps de mettre jusqu'a présent sur ma gallerie.
lundi, mai 21 2007
USB (Universal Serial Bus)
Par compuls le lundi, mai 21 2007, 22:47
Né
d'une collaboration entre divers grosses boites informatiques: compac,
microsoft, IBM, Intel,...en 1995: USB1(de 1,5 à 12 Mb/s),
USB1.1(vitesse idem) & USB2( 480 Mb/s).
La norme USB, constituée de plusieurs couches de protocoles ayant pour but de définir un mode de tansfére de données entre un ordinateur (hote) et un périphérique , en particulier de normaliser une connectique.Elle posséde une architecture série synchrone (ce qui permet une candence d'horloge beaucoup plus rapide qu'en parallèle à cause des érreures dues aux décalages des signaux électrics répartis sur les deux fils du port paralléle et un côut moindre, puisque moins de cuivre utilisé; mais en pratique,nécessité de hubs) mais autorise jusqu'à 126 connections simultanées sur le même port d'un hote, sachant que la bande passante est partagé par nombre de côntoleurs USB Une ramification est possible à l'aide d'hubs.
L'architecture USB a la particulatarité d'alimenter les périphériques qu'elle connecte (max: 15w, 500mA, 5v)=>donc une alimentation controlée, une indépendance de ceux-ci vis a vis de l'hote: chaque périphérique peut être coupé indépendament.
L'utilisation d'une signalisation différentielle symétrique pour la transmission des données: les fils + & - de données transmettent le même signal mais avec une polarisation électrique inverse (ex: si le codage de 1 et transmis en 2v sur D+, il sera transmis en -2v sur D-). Ainsi, c'est la différence des 2 signaux qui vont permetre de reconstituer les données, évitant les érreures (notament le bruit)
Elle autorise les topologie réseau en bus ou en étoile (comme ethernet base 10).
Le protocole de communication utilisé est basé sur le "Token Ring": l'hote envoit un signal (jeton) , comportant entre autre l'adresse du périphérique avec qui il veut communiquer, sur le réseau (anneau). Le premier client , s'il ne reconnait pas son adresse, renvoit ce signal au client suivant. Le périphérique qui reconnaitra son adresse renvera à l'hote un signal (son adresse) . L'hote lui envéra alors un paquet de données, suivit d'un paquet d'état(précisant l'état de la transaction).
L'USB utilise le codage NRZI (ou seul les changements de valeurs sont marquées) (synchronisation des horloges de l'hote et des périphériques)
L'infrastructure de liaison type USB comporte 4 fils: 1 d'alimentaion(rouge), 1 pour la masse(noir) et 2 pour les données(vert=D+ & blanc=D-). Les 2 fils de données, l'un positif, l'autre négatif, permetent le "plug and play": Au branchement, l'hote détecte sur le réseau un dipole provenant de ces fils de données, il attribu donc une adresse provisoire (0, qui est une adresse réservée à cette usage), le temps de consulter les autres périphérique (procédure d'énumération), puis il va charger les pilotes (PID, VID) et lui attribut une adresse.
L'USB peut utiliser la spécification OTG protocole de négociation d'hote permetant de connecter un périphérique directement sur un autre (utilisation des connecteurs type mini)pour les connexions "point par point" (comme pour les teléphones, organiseurs,...
Il existe aussi une norme WUSB (480Mb/3m & 110Mb/10m) établie par le groupe "wireless USB" (depuis 2004) étant similaire à la norme USB, mais utilisant une liaison radio(UWB) et non filliare.
La norme USB, constituée de plusieurs couches de protocoles ayant pour but de définir un mode de tansfére de données entre un ordinateur (hote) et un périphérique , en particulier de normaliser une connectique.Elle posséde une architecture série synchrone (ce qui permet une candence d'horloge beaucoup plus rapide qu'en parallèle à cause des érreures dues aux décalages des signaux électrics répartis sur les deux fils du port paralléle et un côut moindre, puisque moins de cuivre utilisé; mais en pratique,nécessité de hubs) mais autorise jusqu'à 126 connections simultanées sur le même port d'un hote, sachant que la bande passante est partagé par nombre de côntoleurs USB Une ramification est possible à l'aide d'hubs.
L'architecture USB a la particulatarité d'alimenter les périphériques qu'elle connecte (max: 15w, 500mA, 5v)=>donc une alimentation controlée, une indépendance de ceux-ci vis a vis de l'hote: chaque périphérique peut être coupé indépendament.
L'utilisation d'une signalisation différentielle symétrique pour la transmission des données: les fils + & - de données transmettent le même signal mais avec une polarisation électrique inverse (ex: si le codage de 1 et transmis en 2v sur D+, il sera transmis en -2v sur D-). Ainsi, c'est la différence des 2 signaux qui vont permetre de reconstituer les données, évitant les érreures (notament le bruit)
Elle autorise les topologie réseau en bus ou en étoile (comme ethernet base 10).
Le protocole de communication utilisé est basé sur le "Token Ring": l'hote envoit un signal (jeton) , comportant entre autre l'adresse du périphérique avec qui il veut communiquer, sur le réseau (anneau). Le premier client , s'il ne reconnait pas son adresse, renvoit ce signal au client suivant. Le périphérique qui reconnaitra son adresse renvera à l'hote un signal (son adresse) . L'hote lui envéra alors un paquet de données, suivit d'un paquet d'état(précisant l'état de la transaction).
L'USB utilise le codage NRZI (ou seul les changements de valeurs sont marquées) (synchronisation des horloges de l'hote et des périphériques)
L'infrastructure de liaison type USB comporte 4 fils: 1 d'alimentaion(rouge), 1 pour la masse(noir) et 2 pour les données(vert=D+ & blanc=D-). Les 2 fils de données, l'un positif, l'autre négatif, permetent le "plug and play": Au branchement, l'hote détecte sur le réseau un dipole provenant de ces fils de données, il attribu donc une adresse provisoire (0, qui est une adresse réservée à cette usage), le temps de consulter les autres périphérique (procédure d'énumération), puis il va charger les pilotes (PID, VID) et lui attribut une adresse.
L'USB peut utiliser la spécification OTG protocole de négociation d'hote permetant de connecter un périphérique directement sur un autre (utilisation des connecteurs type mini)pour les connexions "point par point" (comme pour les teléphones, organiseurs,...
Il existe aussi une norme WUSB (480Mb/3m & 110Mb/10m) établie par le groupe "wireless USB" (depuis 2004) étant similaire à la norme USB, mais utilisant une liaison radio(UWB) et non filliare.
WIFI or not WIFI ?
Par compuls le lundi, mai 21 2007, 22:39
Il me semble que le terme "wi-fi" est un abus de langage. En fait, "wi-fi" ne veut rien dire: c'est un logo !!! A la base, le materiel répondant à la norme ISO/IEC 802.11b (802.11a et 802.11g) de l'IEEE (Institute of Electrical and Electronics Engineers) est (éventuellement)certifié "Wireless Fidelity" par la WECA (Westchester Emergency Communications Association) qui applique un logo ou figure écrit "wi-fi"(contraction de Wireless Fidelity). Maintenant, on pourra observer que la plupart du materiel que l'on nomme "wi-fi", n'est même pas certifier par la WECA... Il vaudrait donc peut-être mieux éviter d'utiliser ce terme, à moins que l'on tienne à acquérir une nouvelle entrée dans la langue Francaise.
Pour plus de détail, se référer à:
http://fr.wikipedia.org
www.commentcamarche.net
www.ieee.org
www.iec.ch
www.weca.org
www.iso.org
samedi, avril 21 2007
PHP: Introduction au design patterns, partie 1: Singleton
Par knoodrake le samedi, avril 21 2007, 13:18 - Informatique
Commence ici une petite serie de billets sur les "design patterns", les motifs de conception en français. Les motifs de conception ne sont rien d'autre que des solutions toutes prêtes à des problèmes couramment rencontrés, il s'agit de morceaux de code, des "squelettes" prêts à remplir leur fonction (variable) et à être adaptés a votre situation.
La quasi-totalité des design patterns ne dépendent pas d'un langage et peuvent être adaptés à n'importe quel langage moyennant l'adaptation de la syntaxe. Bien évidemment, un design pattern proposant une solution orientée objet ne sera valable que pour un language orienté objet, etc..
Le motif de conception nommé "singleton" est sans conteste un des plus simples à mettre en oeuvre et à comprendre, c'est aussi un des plus utilisés et les exemples de singleton pullulent sur le web, d'ailleurs, j'y mets là mon grain de sel
Destiné a la programmation orientée objet, il permet de n'avoir toujours qu'une seule et unique instance d'un objet quel que soit le nombre de fois où l'on en a besoin.
Une situation typique et courante est la connection a une BDD (Base De Données): en général, vous ne voulez avoir pour toute l'exécution du script qu'une unique connection a la BDD même si vous faites appel à votre classe de gestion de BDD a maintes reprises et dans différents contextes.
Un autre cas pourrait être le suivant: Vous utilisez un ensemble de classes par le biais d'une autre classe, par exemple, votre classe de gestion de BDD ainsi que votre classe de gestion d'utilisateur sont accessibles toutes deux au travers de la classe "moteur":
Afin d'utiliser toujours la même instance d'une classe "BaseSql" par exemple, une solution pourrait être de l'instantiser une première fois lors de l'initialisation de votre script puis de faire passer la référence de l'objet de classe en classe de la sorte
Mais cette solution n'est vraiment pas pratique ! car elle vous oblige à appeler votre classe en fournissant en argument l'instance de $BaseSql:
Là c'était juste pour une classe qui se sert d'une autre classe, mais imaginez si cette même autre classe se sert elle-même d'une autre classe, puis que cette autre classe se serve de 4 autres classes, et ces 4 autres de 2 autres, etc.. Il faudra veiller à chaque fois que l'on a besoin de BASESQL à prendre la référence de son instance, bien veiller à toujours passer l'instance à d'autres classes, etc.. en d'autres mots, croyez-moi: ca devient le bordel !
LA solution qui serait élégante serait, de tout simplement, et à chaque fois que l'on a besoin d'utiliser la classe BASESQL, faire:
le motif Singleton le permet en 2 ou 3 lignes.
La classe qui ne devra être instantisée qu'une seule fois devra être comme ceci:
Elle finit par retourner $Instance qui dans tous les cas contiendra donc une instance de BASESQL.
Ainsi, si BASESQL est déja instantisée on en transmet l'instance, sinon on instantise (et le prochain appel de la method getInstance transmettra cette instance qui vient d'être faite ) et on transmet.
La méthode getInstance() et la propriété $Instance sont publiques et statiques dans le but d'être accessibles par tout le monde et ce sans avoir besoin que la classe ait été déjà instantisée (logique, c'est le but ! )
Des questions ? des suggestions ? des conseils ? n'hésitez pas a vous servir des commentaires, ils sont là pour ça, ou de la page contact (cf. menu a droite) pour un mail.
Le prochain billet traitera du motif Registry ou du motif Factory.
La quasi-totalité des design patterns ne dépendent pas d'un langage et peuvent être adaptés à n'importe quel langage moyennant l'adaptation de la syntaxe. Bien évidemment, un design pattern proposant une solution orientée objet ne sera valable que pour un language orienté objet, etc..
Singleton: Utilité
Le motif de conception nommé "singleton" est sans conteste un des plus simples à mettre en oeuvre et à comprendre, c'est aussi un des plus utilisés et les exemples de singleton pullulent sur le web, d'ailleurs, j'y mets là mon grain de sel
Destiné a la programmation orientée objet, il permet de n'avoir toujours qu'une seule et unique instance d'un objet quel que soit le nombre de fois où l'on en a besoin.
Une situation typique et courante est la connection a une BDD (Base De Données): en général, vous ne voulez avoir pour toute l'exécution du script qu'une unique connection a la BDD même si vous faites appel à votre classe de gestion de BDD a maintes reprises et dans différents contextes.
Un autre cas pourrait être le suivant: Vous utilisez un ensemble de classes par le biais d'une autre classe, par exemple, votre classe de gestion de BDD ainsi que votre classe de gestion d'utilisateur sont accessibles toutes deux au travers de la classe "moteur":
$moteur->bdd->query_sql()
$moteur->users->is_online();
Dans un tel contexte, vous voudriez sans doute là aussi n'avoir qu'une unique instance de la classe "moteur".resultat recherché
Afin d'utiliser toujours la même instance d'une classe "BaseSql" par exemple, une solution pourrait être de l'instantiser une première fois lors de l'initialisation de votre script puis de faire passer la référence de l'objet de classe en classe de la sorte
class MaClasse_A
{
private $BaseSql;
__construct (&InstanceBDD) {
$this->BaseSql =& $InstanceBDD;
}
uneFonction () {
$requete = "SELECT * FROM `MaTable` WHERE 1";
$this->BaseSql->query_sql($requete);
}
}Mais cette solution n'est vraiment pas pratique ! car elle vous oblige à appeler votre classe en fournissant en argument l'instance de $BaseSql:
$classA = new MaClasse_A ($BaseSql);
Mais surtout, cela devient vraiment vraiment pénible dès qu'il est question d'héritage et de collaboration entre les classes ! voyez l'exemple ci-dessous:class MaClasse_A {
__construct (&instanceBDD) {
$this->BaseSql =& $InstanceBDD;
}
/*
... plein de methodes
*/
getUserInscriptionDate () {
$classeDate = new DATE ($this->BaseSql);
return $classeDate->userInstription();
}
}
class DATE {
__construct (&$instanceBDD) {
$this->bdd =& $instanceBDD;
}
userInscription() {
/* ... */
}
}Là c'était juste pour une classe qui se sert d'une autre classe, mais imaginez si cette même autre classe se sert elle-même d'une autre classe, puis que cette autre classe se serve de 4 autres classes, et ces 4 autres de 2 autres, etc.. Il faudra veiller à chaque fois que l'on a besoin de BASESQL à prendre la référence de son instance, bien veiller à toujours passer l'instance à d'autres classes, etc.. en d'autres mots, croyez-moi: ca devient le bordel !
LA solution qui serait élégante serait, de tout simplement, et à chaque fois que l'on a besoin d'utiliser la classe BASESQL, faire:
/* quelque part dans le code.. dans une classe ou n'importe ou */
$basesql = BASESQL::getInstance(); // et mainteant on fait ce qu'on veut
$basesql->methodeXYZ(); // et si on fait a nouveau
$Autre = BASESQL::getInstance();
/*
et ben on se retrouve avec toujours la même instance,
$basesql et $Autre contiendront la même instance de BASESQL
*/le motif Singleton le permet en 2 ou 3 lignes.
Mise en Oeuvre
La classe qui ne devra être instantisée qu'une seule fois devra être comme ceci:
class BASESQL {
private static $instance;
/* ...some code */
public static getInstance () {
if (is_null(self::instance)) {
self::instance = new BASESQL (/* ..some args */ ); }
return self::instance;
}
/* ...some code */
}Explication:
Lorsque vous faites un appel à la methode getInstance() comme ceci:
$BaseSql = BASESQL::getInstance();
Elle finit par retourner $Instance qui dans tous les cas contiendra donc une instance de BASESQL.
Ainsi, si BASESQL est déja instantisée on en transmet l'instance, sinon on instantise (et le prochain appel de la method getInstance transmettra cette instance qui vient d'être faite ) et on transmet.
La méthode getInstance() et la propriété $Instance sont publiques et statiques dans le but d'être accessibles par tout le monde et ce sans avoir besoin que la classe ait été déjà instantisée (logique, c'est le but ! )
Des questions ? des suggestions ? des conseils ? n'hésitez pas a vous servir des commentaires, ils sont là pour ça, ou de la page contact (cf. menu a droite) pour un mail.
Le prochain billet traitera du motif Registry ou du motif Factory.
« billets précédents - page 2 de 9 - billets suivants »