Depuis quelques temps je cherchais a lier toutes les données d'un même projet dans le dossier eclipse du projet en question.
Entre autre pouvoir gérer la base de données du projet directement depuis eclipse sans avoir à passer par phpMyAdmin.
Malheureusement entre les plugins non-compatibles avec les dernières versions d'eclipse, ceux qui sont devenus payants et ceux pour lesquels il est nécessaire d'avoir la version commerciale ça devenait compliqué. Après plusieurs installations et désinstallation je pense enfin avoir trouvé ma solution : Clay Database Modelling
Et en plus un tuto assez simple pour installer le tout : jmdoudoux
Ce petit outil permet de gérer ses bases de données, de les créer mais aussi de faire de la rétro-conception d'un modèle. On peut alors modifier la base, y ajouter des données et ensuite de créer un fichier contenant les ordres de création des éléments de la base de données grâce à un assistant. Ceci produisant un fichier sql on garde ainsi un historique de toutes les modification apportée à une base de donnée. Le tout relié à un serveur SVN et au commit des fichier on retrouve les modification apporté par d'autres utilisateur ainsi que le modèle de BD à jour.
Il serait donc possible d'avoir un serveur de DB accessible à tous les programmeurs. On aurait ainsi plus besoin d'avoir les Bases de données installées sur chacun des postes mais une seule version toujours à jour.
J'attends le test des programmeurs pour savoir si ça fonctionne correctement sous linux aussi.
PS : notez que c'est l'intégratrice qui vous parle de prog !
CSSTidyest un parser et un optimiseur css open source. Il est possible de l'utiliser comme un executable ou en lignes de commande ou encore en php.
Le but : Optimiser le code. Pour ce faire votre CSS doit être valide. Ensuite CSSTidy passera au travers du fichier afin d'meliorer la syntaxe. Par exemple :
- color:black; ou color:rgb(0,0,0) deviendra color:#000;
- margin:1px 1px 1px 1px; deviendra margin:1px;
- les unités oubliées seront corrigées
- les erreurs syntaxiques seront aussi corrigées
- les espaces indesirables seront supprimés de même que les commentaires.
Résultat : CSSTidy permet de générer un css plus léger et optimiser ce qui permettra un téléchargement plus rapide. Il est possible de gagner en moyenne 30% de compression par rapport au fichier original.
Plusieurs options sont disponibles lors de l'optimisation :
- Le type de compression : du plus compacte au sur mesure (il est aussi possible de definir un gabarit de telle maniere que votre code puisse apparaitre comme indenté)
- Trier les selecteurs ou les propriétés
- Fusionner les sélecteurs
- Compresser les couleurs
- Case de propriétés
- Supprimer les propriétés non valide (CSS1 à CSS2.1)
Bref de quoi rendre optimal le code.
Cependant il est toujours bon de faire une sauvegarde du fichier original. Perso, je vais faire le test de cette technique en ligne en loadant le fichier optimisé. Mais je garderai une version de mon bon vieux fichier css de xxxx lignes plein de commentaires et indenté histoire de m'y retrouver rapidement lors de modifications.
Michael Ogawa et son groupe Vidi (de l'Université California-Davis) ont fait une représentation graphique du développement de plusieurs projets open source. Pour chaque projet, ils ont fait un petit film.
Chaque projet travaille avec un système nommé CVS qui permet de suivre le développement du projet et permettre à des centaines de personnes au niveau mondial de faire des changements et de les mettre à jour. Lorsque des changements sont effectués, on "commit" nos changements pour que les autres développeurs à travers le monde puissent mettre à jour leur version.
Michael Ogawa s'est servi de l'historique du système CVS de chaque projet et en a fait une représentation graphique. Chaque point rouge du film représente un fichier qui contient du code, un fichier blue pâle représente un image et un fichier bleu foncé représente un document (généralement texte).
Le site web original : Michael Ogawa
Le video pour Eclipse (un éditeur de fichier de code source gratuit) : Eclipse-HD
Félicitation à Michael et à toute son équipe pour un travail si impressionnant et de si grande ampleur.
Google a récemment mis en ligne une wiki pour webmaster regroupant les bonnes pratiques du web, les langages CSS, HTML, JAVASCRIPT, et bien d'autres.
Bien sur il y a beaucoup d'autres ressource sur le net sur le même sujet. Pas besoin de nommer Wikipedia et devGuru. Google a un petit plus : Il est possible de trouver les renseignements mais également des codes source déjà programmés via googleCode.
On trouvera également pour chaque propriété ou balise sa compatibilité IE (6, 7, 8) ainsi que Firfeox (2 et 3). Une petite avance par rapport aux autres du fait que IE8 et Firefox 3 ne sont pas encore totalement disponible ou en version beta.
Deplus étant un wiki, chacun pourra y mettre du sien pour améliorer la chose.
Les colonnes autoincrémentées dans une base de données (je fais référence au type de donnée serial en PostgreSQL, ou encore au modificateur de type auto_increment en MySQL) sont très utiles pour obtenir un numéro unique lorsqu'on ajoute une rangée dans une table. Cependant, j'ai appris récemment qu'annuler une transaction SQL (abort ou rollback) ne remet pas le compteur à ce qu'il était avant de débuter la transaction.
Imaginez que vous utilisez une colonne autoincrémentée pour assigner un numéro de facture. La dernière facture que vous avez créée porte le numéro 42. Vous débutez votre transaction SQL avec begin puis vous ajoutez une nouvelle facture: le numéro 43 lui est automatiquement attribué. Disons qu'au moment d'ajuster les tables d'inventaire, un problème survient et vous annulez la transaction SQL avec rollback. Le SGBD effacera toute trace de votre facture comme vous le souhaitez, mais le compteur demeurera à 43. La prochaine facture portera donc le numéro 44 et vous aurez un trou entre la facture 42 et 44, ce qui est guère apprécié des comptables!
Cela se produit avec la plupart des SGBD. Comment se fait-il alors que personne n'ait corrigé ce bogue? Parce que ce n'en est pas un! Pour reprendre l'exemple ci-haut, si un deuxième processus ajoutait une facture (numéro 44) entre le moment où la facture 43 est créée et le moment où la transaction SQL de la facture 43 est annulée, ce serait impensable de défaire aussi la facture 44 sous prétexte que son numéro devrait maintenant être 43...
Alors que faire? Ne pas utiliser de colonne autoincrémentée, malheureusement. Avant de créer une facture, il faut verrouiller la table des factures pour empêcher qu'un autre processus ne la lise (ouch!), faire un "select max(facture_id) + 1" pour obtenir le prochain numéro de facture et ajouter une facture en spécifiant ce numéro. Et bien sûr, ne pas oublier de libérer le verrou sur la table le plus tôt possible!
À quoi peut bien servir l'entité HTML ­? À indiquer à votre fureteur où il peut couper un mot trop long à la fin d'une ligne! Le nom de l'entité provient du nom donné au trait d'union qui n'apparaît que lorsqu'un mot est coupé: soft hyphen. Si par exemple vous tapez "triste­ment", vous obtiendrez "tristement" en début ou milieu de ligne, mais si le mot est en fin de ligne, vous verrez "triste-" et "ment" sur la ligne suivante.
Évidemment, il y a des incompatibilités entre fureteurs. Cette fois-ci, c'est Firefox 2.0 le coupable car ce dernier ignore simplement l'entité (http://www.quirksmode.org/oddsandends/wbr.html).
Et ce n'est pas tout. Tapez "Îles-de-la-Madeleine" en fin de ligne et vous aurez deux comportements différents: Internet Explorer insèrera un saut de ligne à l'un des traits d'union, alors que Firefox laissera le mot entier. La logique derrière ce choix serait qu'il n'est pas justifié de prendre pour acquis qu'un mot peut être coupé là où il y a un trait d'union. En effet, dans des cas comme dans "A-1", on ne veut pas que le mot soit coupé. Peut-être aussi que dans certaines langues, d'autres règles de césure s'appliquent.
Mais de tels cas sont à mon avis rarissimes, et à ma connaissance, le trait d'union peut provoquer un saut de ligne au moins dans toutes les langues indo-européennes. Ne serait-il pas plus efficace d'avoir un caractère ou une entité pour indiquer que l'on ne veut PAS permettre un saut de ligne, comme l'espace insécable ?
L'autre soir, en parlant avec mon père qui est gérant/chef mécanicien d'un garage, j'essayais de le convaincre qu'une erreur de programmation, qui peut paraître stupide à première vue, peut engendrer des répercutions qui pourrait mettre la vie de certaines personnes en danger.
Vous devinez probablement son scepticisme. Il était en effet convaincu qu'une erreur majeure pourrait entrainer des problèmes majeurs, comme par exemple un mauvais calcul sur un système bancaire, mais jamais qu'une petite erreur de tous les jours pourrait causer la perte de vies ou les mettre en danger.
Bien franchement, je n'en étais pas complètement convaincu moi-même, mais hier après-midi, j'ai trouvé des preuves très concrètes.
La plupart des langages de programmation sont faits, à la base, pour servir une population anglaise. Ce n'est donc pas du tout surprenant pour nous de rencontrer des problèmes où un accent a été mal interprété, mal affiché ou simplement tronqué. C'est une erreur que la majorité des personnes considèreraient comme mineure et simplement agaçante.
L'histoire que je viens vous présenter est celle de Emmine et Ramazan Çalçoban qui habite Hurriyet en Turquie. Je vais vous faire un court résumé mais pour plus de détails, je vais vous laisser le plaisir de lire l'article.
Ramazan avait envoyé un message texte, par cellulaire, à son ex-femme. Ils étaient en instance de divorce. Dans son message, il avait utiliser la lettre "ì" qui est finalement arrivée en simple "i" chez la destinataire. Au départ le message n'était pas offensant, à la réception, simplement en interchangeant les deux "i", le message s'est transformé en une insulte. Le message reçu a engendré des évènements un peu farfelus mais quand même réels qui ont finalement résulté en 2 morts et 3 emprisonnements.
Il serait maintenant difficile de contredire qu'une simple petite erreur de programmation ne peut pas engendrer la mort...
Lors des dernières semaines, j'ai travaillé avec un collègue à refaire la calculatrice hypothécaire sur le site La Capitale Vendu.com.
Cet outil utilise beaucoup de Javascript et Ajax et j'en suis venu à la situation dans laquelle je voulais mettre une espace insécable (non breaking space nbsp) dans la fonction createTextNode ce qui ne fonctionne pas aussi simplement qu'on oserait le croire!
La solution?
Mettre \u00a0 pour représenter le caractère de l'espace insécable! C'est la représentation UTF-8 du caractère.
Ensuite, la page de la calculatrice présente plusieurs scénarios et chacun de ceux-ci a son propre bouton pour sa version pour impression. Voulant à tout prix éviter le pop-up avec seulement l'information par rapport au scénario choisi, voulant profiter au maximum de ma feuille de styles print.css, j'ai fait en sorte que l'icône d'imprimante change la classe css d'un élément div parent et le print.css devait se charger du reste. Cela étant dit, puisque j'utilise des effets scriptaculous et autres certains éléments se voyaient attribuer un attribut style avec des display: none display: block ou height: 0px ou height: auto ce qui m'empêchait de bien contrôler tout ce que je voulais imprimer.
La solution?
CSS permet l'ajout d'une directive !important permettant de passer par dessus l'attribut style tout puissant spécifier inline.
display: none !important;
C'est génial ce qu'on peut faire avec ce truc!
En terminant cette chronique du développeur Web, quelques mots sur Maxthon, un navigateur qui semble être basé sur Internet Explorer mais en mieux selon ce que je comprends. J'en déduis qu'il s'adresse principalement aux gens désespérés devant l'agissement d'Internet Explorer, n'étant pas au courant de la présence et même de l'existence de Firefox! Maxthon présente une liste de fonctionnalités intéressantes, mais rien qui n'est pas disponible avec Firefox et ses extensions. Après quelques tests Acid, je reste avec Firefox! Si vous désirez un autre navigateur que Firefox ou Internet Explorer, pensez donc à Opéra!
PHP 6 s'en vient et voici un apperçu de ce à quoi nous pouvons nous attendre :
Un suppport Unicode
Yé! Cela facilitera sans doute les échanges entre php et mysql/postgresql. Avec cette fonctionalité, PHP pourra automatiquement encoder et décoder les entrées et sorties du script assurant la base de données et le client de recevoir le bon encodage sans l'aide de fonctions supplémentaires pour faire la conversion.
Une bonne chose ? Je ne sais pas trop... J'espère que cela emmènera pas le même genre d'ambiguïté que magic_quotes().
Un remu ménage
Parlant de magic_quotes, ceci disparaitra dans la prochaine version de PHP. Register_globals et safe_mode sont rayés de la carte aussi. Une bonne nouvelle ça!
Une cache alternative
Je vous laisse lire l'info ici.
Modèle OO amélioré
De nouvelles fonctionnalités orientées objet sont à prévoir. La notion de namespace (à la C++) va faire son apparition. Heureuse nouvelle pour ceux qui ont la mauvaise habitude de nommer leurs variables globales avec des noms trop génériques et sans préfixe...
Aucune date officielle de lancée pour PHP6 à l'heure actuelle.
Google doit beaucoup à JavaScript, et vice-versa. JavaScript a d'abord permis à Google d'offrir quelques unes des interfaces les plus abouties disponibles sur le Web (Je pense entre autres à Google Map, Gmail, Google Video, Google Documents, ...). Il faut toutefois mentionner que si ce n'était de Google, probablement que JavaScript n'aurait pas autant la cote que maintenant. La compagnie basée à Mountain View (en Californie) a été l'une des premières à faire usage intensif de l'objet JavaScript XMLHttpRequest (communément appelé Ajax), symbole phare du très-en-vogue Web 2.0. Avant que Google ne prouve aux développeurs Web que JavaScript permettait de construire des interfaces riches et fluides, ce dernier était quelque peu snobbé par la communauté. Le langage n'était pas élégant, les librairies étaient peu nombreuses et les pages qui en faisaient usage étaient parmi les moins ergonomiques du Web. Maintenant que JavaScript a retrouvé sa place dans nos coeurs, il est normal de s'attendre à une évolution de sa part. C'est pourquoi vous pourrez bientôt apprécier JavaScript 4 sur un écran près de chez vous. Et qui de mieux placé que Google pour faire une démonstration de ses nouvelles fonctionnalités? (Attention, la vidéo est d'une durée approximative d'une heure... Prévoyez du temps !)
QuiboWeb est à la recherche d'un(e) programmeur(e) Java et/ou PHP afin de se greffer à son équipe jeune et dynamique. Si vous êtes intéressé à contribuer à un projet d'envergure internationale ainsi qu'à rejoindre une compagnie en rapide expansion, faites nous parvenir votre CV et vos réalisations aux coordonnées suivantes :
QuiboWeb inc.
C.P. 85043
Mont-Saint-Hilaire
Québec, Canada
J3H 5W1
J'ai dû faire face à un petit bug avec la librairie GD sur PHP pour la conversion d'une photo en JPG avec la fonction imagecreatefromjpeg.
Lorsque je soumettais une image JPG, celle-ci s'uploadait sur le serveur et ensuite une page blanche s'affichait...
La démarche pour trouver le problème était bien entendu de faire un phpinfo() pour m'assurer que la librairie GD était belle et bien installé ainsi que le support pour le format JPG, ce qui était le cas...
À force d'essayer avec une photo de mes vacances, j'ai tenté ma chance avec une image provenant d'un site Web. La conversion fonctionnait pour l'image provenant d'Internet mais ne fonctionnait pas pour ma photo de vacances... Pourquoi?
Finalement j'ai réfléchi et la seul différence entre les 2 JPG c'était la taille... PHP utilise beaucoup de mémoire pour manipuler les images... et plus l'image est lourde, plus on a besoin de mémoire... C'était le problème, pas assez de mémoire allouée dans le php.ini .
Pour remédier à ce problème, vous pouvez tenter de faire ceci :
ini_set('memory_limit', '50M');
Les images provenant de caméras numériques récentes sont souvent très lourdes et demandent beaucoup de mémoire...
J'espère que cette courte chronique vous permettra de sauvez du temps si vous avez un jour un problème similaire!
J'ai récemment découvert cet outil qui s'annonce fort pratique afin de tester mes expressions régulières. Il utilise simplement du javascript afin d'évaluer les expressions en cours de frappe.
Vous êtes-vous déjà buté à une erreur étrange en programmant du PHP à l'aide du logiciel libre Eclipse et PHPEclipse?
Moi si, et je tiens à partager mes observations et les décrire afin de faire un peu de lumière sur ce bug obscure :
Vous commencez un projet de site Web en PHP sous Windows à l'aide d'Eclipse et PHPEclipse. Comme tout bon programmeur se souciant de la compatibilité multi plate-forme, vous prenez soin de tout régler vos paramètres d'encodage par défaut à UTF-8 avant d'entamer la production. Au moment de tester vos pages dans vos navigateurs, vous vous buter à une impasse se décrivant comme deux caractères hétéroclites apparaissant à l'écran "ÿþ" aka "FFFE". Et plus étrange encore, votre fidèle outil de travail se met à dérailler en vous affichant votre précieux code dépourvu de toute cohérence au niveau de la coloration syntaxique (syntax highlighting).
Qu'est-ce que sa signifie? Pourquoi rien ne s'affiche dans le navigateur à l'exception de ce malin duo de lettres exotiques? Et pour quelle diable raison la coloration syntaxique semble brisée?
Il est maintenant temps de vous partager l'explication rationnel que moi et mes confrères avons trouvée. Tout d'abord, une investigation approfondie du fichier PHP produisant l'erreur s'est imposée. Le fichier problématique, examiné en mode hexadécimal, révèle une suite de caractères en début de fichier: 0xFF 0xFE. Une vu en mode ASCII ne révèle pas leur présence, car ces deux caractères sont en fait un code UTF-8 indiquant le début d'un fichier UTF-8. Ceux-ci ne correspondent à aucun caractère lisible, d'où leur invisibilité consternante dans tout éditeur texte.
Il est important de noter que ces caractères n'apparraissent pas toujours, car Eclipse n'encode les fichiers en UTF-8 seulement et seulement si un caractère étendu (ex: "é", "à", etc) se trouve à l'intérieur du fichier. Donc si votre fichier ne contient de des caractères simples, vous évitez en principe le problème.
Il semblerait que la configuration Windows, Eclipse 3.2.x et PHP Eclipse n'apprécie guère ces caractères et provoque une incisitance dans la coloration syntaxique. Il se peut aussi que votre serveur Web favori (Apache muni de mod_PHP) traite maladroitement les fichiers contenant le jeux de caractères, provoquant un affichage inattendu dans votre navigateur.
Solution? Munissez-vous d'un éditeur hexadicimal (Je recommande UltraEdit-32) pour filtrer les fichiers problématiques, supprimer les deux premiers caractères de chacun.
Il y a 1 an presque jour pour jour, le site 24ways était lancé. Il s'agit en fait d'une collection d'astuces destinées aux développeurs web afin d'épater la gallerie. Le concept est calqué sur celui du calendrier de l'avent : du 1er au 24 décembre, une nouvelle astuce par jour est publiée sur le site. Chaque astuce est écrite par un auteur différent et tous les auteurs sont des blogeurs-"vedettes".
Cette année, il semble que l'expérience se répète, à notre grand bonheur! Jusqu'à maintenant, les trucs semblent légèrement moins impressionnants que l'année dernière... ou peut-être est-ce mes attentes qui sont un peu trop élevées ? Dans tous les cas, il est certain que je suivrai avec intérêt les publications jusqu'à Noël !
Voici le blog de QuiboWeb destiné à vous faire part de nos récentes
découvertes, prix citrons et derniers coups de coeur. Réactions et
suggestions sont les bienvenues, cette section est conçue pour vous. Pour certain
contenu, vous aurez besoin du
plug-in Flash
dont la taille varie de 1300K à 2500K selon votre système d'exploitation.