Je découvre apiary.io. Il y a de quoi documenter, tester et déboguer une API REST, avec des mocks et des proxy de déboguage.
Je ne sais pas si la valeur ajoutée est suffisante pour imaginer utiliser un service de ce type mais c’est bien foutu, simple, et assez clair. Je n’ai simplement pas compris quel est le modèle business (et ça c’est un gros point noir).
Bref, à surveiller, le compte de test peut être créé en quelques secondes à partir d’un compte github.
Les webapps sont pour moi définitivement la direction vers laquelle aller. Mozilla pousse beaucoup via Firefox OS. Pour jouer avec eux, jetez un oeil à Mortar, qui permet d’initialiser tout le nécessaire. Il y a un joli billet de hacks.mozilla.org qui peut vous permettre de démarrer.
Pendant quelques années nous avons cherché le saint Graal pour remplacer du texte par des images dans les pages HTML. Il y a eu sIFR qui nécessitait le plugin Flash, des bidouilles à base d’indentation et marges CSS négatives qui risquaient de casser pour ceux qui n’affichaient pas les images, des trucs horribles à base de display:none qui empêchaient le copier/coller, etc.
J’avais pas mal laissé tombé quand j’ai vu que certains jouaient avec des polices de caractères à la wingdings. Ça ne faisait pas de remplacement et ça nécessitait d’ajouter des caractères arbitraires qui risquaient de mal passer en cas d’absence de la police choisie.
Sauf que visiblement ils ont trouvé le saint Graal il y a un bon moment et personne ne m’a prévenu. Alors si vous aussi on ne vous a pas prévenu, regardez Symbolset et Ligature Symbols.
L’idée c’est d’utiliser les ligatures. Les ligatures ce sont ces artefacts qui permettent de remplacer certaines suites de caractères par un visuel spécifique afin d’en simplifier la lecture. On cite souvent « fl » et fi » comme exemple de ligature mais Wikipedia a une superbe illustration.
L’astuce est de déclarer une police personnalisée où « se connecter » est remplacé par une ligature qui contient l’icône correspondante. C’est vectoriel, ça s’adapte en taille comme en couleur, ça se dégrade parfaitement pour ceux qui ne savent pas relire la ligature ou la police de caractères, et pour le système ça reste encore le mot « se connecter » donc c’est totalement transparent. Bref, comme en plus c’est léger en poids, on a presque trouvé le saint Graal. Pourquoi personne ne m’avais rien dit ? Comment ai-je pu passer à côté ?
Vous avez même un outil en ligne qui fait tout ça : Icomoon
Partagé sans commentaires, mais vous pouvez faire les vôtres :
J’avais relayé quelques offres de recrutement ici par le passé. Je vous propose de regarder quelques possibilités de stages. L’idée c’est de travailler sur des sujets sympa, dans une équipe qui l’est tout autant.
Il y a un peu de tout, mais l’essentiel est bien sûr de l’innovation et des sujets que vous n’aurez pas forcément ailleurs. Par contre s’il y a pas mal de sujets, nous n’ouvrirons que deux postes, afin de gérer correctement le volet encadrement et formation.
L’environnement c’est une startup sympa, avec un vrai projet, de l’innovation, et une vision « ouverte » au coeur de son ADN. Pour ne rien gâcher c’est à Lyon et pas dans la grisaille parisienne.
Parce que ça m’a servi récemment, ça peut servir à d’autres.
Du vert clair sur du blanc c’est illisible. Du marron sur du noir, c’est illisible. Quelle est la limite, le blanc sur orange est-il lisible ? Se fier à sa propre vision c’est oublier que tous n’ont pas les mêmes difficultés, et oublier le contexte différent entre le visiteur et le créateur de l’illustration.
Donc pour avoir une mesure objective, je vous recommande la lecture du billet Openweb (une ressource excellente qui n’est jamais assez recommandée), et l’outil Contrast-A. Par la même occasion faites attention aux différents daltoniens : Ça représente tout de même presque 10% de la population masculine.
J’en profite : même si c’est probablement ce que je fais ici, vous avez en général intérêt à ne pas faire du noir sur blanc et encore moins du blanc sur noir. Atténuer le noir, voire le blanc, est souvent une bonne idée même si c’est moins épatant lors des présentations à la direction.
Parcourir les fichiers c’est simple avec PHP 5 et la SPL. Ou pas.
<?php
class bigFileFilterIterator extends FilterIterator {
public function accept() {
$oFileInfo = $this->getInnerIterator()->current();
return ($oFileInfo->getSize() > 10000);
}
}
$themedir = __DIR__.'/theme';
$iterator = new RecursiveDirectoryIterator($themedir, FilesystemIterator::SKIP_DOTS);
$iterator->setFlags(FilesystemIterator::CURRENT_AS_FILEINFO);
$recursiveIterator = new RecursiveIteratorIterator($iterator);
foreach(new bigFileFilterIterator($recursiveIterator) as $file) {
echo $file->getfilename()."n";
}
Sérieusement ? Mais pourquoi ne puis-je pas utiliser directement le RecursiveDirectoryIterator et dois-je instancier un RecursiveIteratorIterator ? Celui qui a conçu cette dernière classe souffre-t-il de bégayement ? Rien que l’instanciation du premier itérateur ne tient pas sur une seule ligne. Un ->getInnerIterator()->current() et pas un paramètre directement dans la méthode ->accept() ? Sérieusement ?
Montrer les nouvelles possibilités c’est appréciable, les qualifier de simple est une insulte à l’intelligence.
De mon temps on faisait quelque chose comme ce qui suit :
<?php
function recursive_filter($path) {
$dir = dir($path) ;
while (false !== ($name = $dir->read())) {
if ($name[0] === '.') return ;
$new_path = $path.DIRECTORY_SEPARATOR.$name ;
if (is_dir($new_path)) {
recursive_filter($new_path) ;
} elsif (file_size($new_path) > 10000) {
echo $new_path ;
}
}
}
$themedir = __DIR__.'/theme';
recursive_filter( $themedir ) ;
Ce n’était pas plus court, mais pas plus long. On peut entrer dans de longs discours pour savoir si c’était plus simple ou plus complexe, mieux structuré ou non, mais la valeur ajoutée du nouveau code ne saute pas aux yeux côté simplicité je trouve.
À titre d’exemple, en ruby (« find » est dans la lib standard) :
require 'find' theme_dir = File.dirname(__FILE__)."/theme" Find.find(theme_dir) do |path| next if FileTest.directory?(path) puts path if FileTest.size(path) > 10000 end
Ou sur Python :
import os
themedir = os.path.join(os.path.dirname(__file__), "theme")
def find_files(directory):
for root, dirs, files in os.walk(directory):
for basename in files:
if not file.startswith("."):
filename = os.path.join(root, basename)
yield filenames
for filename in find_file(themedir)
if os.path.getsize(filename) > 10000 :
print filename
Il peut y avoir des fautes et il peut y avoir mieux dans les différents langages, et peu importe le nombre de lignes, mais dans les quatre codes précédents c’est bien le premier qui me semble complexe.
Il y a bien d’autres occasions de trouver PHP « simple », mais pas les itérateurs de la SPL.
Je rage devant tous ces afficionados qui veulent être à la pointe et qui tout en crachant sur les mode de compatibilité et doctype switching, forcent les futurs navigateurs à reproduire les mêmes problèmes.
N’utilisez pas « X-UA-Compatible : IE=Edge ». C’est inutile et contre-productif.
Avec cette entête, on déclare explicitement une compatibilité avec tout moteur Internet Explorer futur. Celui de dans deux ans ou celui de dans cinq ans.
Avec le passé des navigateurs, l’histoire du doctype switching, les modes de compatibilité et les ruptures de compatibilité diverses, c’est quand même un pari qui semble perdu d’avance.
La question n’est pas tellement de savoir si vous codez « standard », mais que le standard peut évoluer ou se préciser, que certaines fonctionnalités peuvent être abandonnées, ou que certains bugs peuvent être corrigés en introduisant des effets de bords sur vos pages. Même ceux qui codent « standard » jusqu’au bout des ongles choisissent en général tel ou tel montage pour contourner les manques ou différences des navigateurs et que ces manques et différences évoluent avec le temps.
Le problème n’est pas vos pages ou votre code, c’est l’environnement autour.
Et encore, je laisse de côté ceux qui s’attachent tellement fort aux standards qu’ils finissent pas n’utiliser que des fonctionnalités avant leur stabilisation voire avec préfixées dans des versions de test. Eux *vont* des problèmes, mais ils le méritent.
Le système est fait pour trois cas :
Si vous n’êtes pas dans un de ces trois cas, il est très probable que vous n’ayez pas besoin d’une entête X-UA-Compatible. Pour utiliser la dernière version respectueuse des normes du moteur d’Internet Explorer, il vous suffit de coder des pages valides avec un doctype correct et sans prologue XML.
Sauf à être dans un des cas précédents, le X-UA-Compatible n’apportera rien de plus à part les effets négatifs qui seront décrits plus haut.
Même si vous vous retrouvez dans un des trois cas décrits plus haut, ou si vous souhaitez quand même être explicite, se déclarer explicitement compatible avec de futures versions qui n’ont même pas commencé à voir le jour est toujours aussi risqué.
Vous avez testé avec IE10 ? alors déclarez IE=10. Vous n’aurez rien de moins que prévu, même si un IE11 ou un IE12 sortent. Si ces prochains n’introduisent pas de problème de compatibilité, il est probable que vous bénéficierez de toutes façons du nouveau moteur. À l’inverse, s’il y a rupture de compatibilité majeure, vous aurez probablement moins de problèmes avec un mode de compatibilité « IE=10 » qu’avec un nouveau moteur incompatible « IE=Edge ».
Vous avez tout à gagner à être honnête et à déclarer la compatibilité réelle de vos pages. Au pire le site développé pour IE10 continuera d’être vu avec un moteur compatible avec ce que proposait IE10. Est-ce vraiment si peu souhaitable ?
Si ces pages sont toujours en maintenance active lors d’une nouvelle version du moteur IE *et* que ce moteur est compatible avec la version précédente *et* pourtant qu’il décide de passer en compatibilité quand vous précisez IE=[la_version_précedente] (vous remarquerez que les deux dernières conditions sont assez incohérentes entre elles), alors il vous sera facile de mettre à jour la déclaration. L’avantage c’est que si une de ces hypothèses devient invalide à l’insu de votre plein gré, au moins ça continuera à fonctionner comme avant et comme prévu.
Le mode IE=Edge est utile à condition que vous testiez toutes les pages différentes à chaque nouvelle beta d’Internet Explorer, et ce tant qu’au moins une de vos pages est en ligne (chez vous ou chez un tiers).
Ça peut être votre cas si vous avez un petit site et que vous avez du temps à y passer. C’est toutefois un pari sur le fait que vous restiez en maintenance active et que vous aurez du temps à perdre à l’avenir. Je ne compte pas le nombre d’applications ou de sites abandonnés qui sont en théorie en maintenance ou dont on pensait qu’ils seraient encore en maintenance.
Le plus souvent IE=Edge c’est surtout pour les sites en développement, et ça devrait y rester cantonné.
Mon problème n’est pas tant que vous choisissiez d’utiliser une déclaration IE=Edge, à vrai dire vous faites ce que bon vous semble et comme je n’utilise pas IE je n’aurai pas à en souffrir. Mon problème c’est quand ça arrive en recommandation ou en bonne pratique à destination des développeurs. Là désolé de vous le dire, mais vous avez fauté. Vous engagez fortement un tiers à quelque chose dont je doute qu’il ait saisi toutes les implications, et ce pour un bénéfice qui reste franchement à démontrer.
Si trop de gens utilisent IE=Edge, et qu’Internet Explorer se sent obligé d’introduire une rupture de compatibilité significative, quelle(s) solution(s) leur restera-t-il ?
Même du point de vue du web, en trichant à ce niveau vous n’aidez pas le web à rester à jour, vous risquez surtout de le casser ou de le complexifier. À bon entendeur…
La fainéantise est une superbe qualité pour un informaticien. C’est ce qui fait que l’informaticien est capable de coder 20 minutes un script pour lui automatiser une tâche qui prend 5 minutes de boulot tous les mois.
Maintenant parfois c’est abusé, et c’est trop souvent le cas sur les formulaires.
![[saisir le ] nom utilisé lors de votre commande en majuscule et sans accent [et] le téléphone fixe actuel](http://n.survol.fr/wp-content/uploads/2012/08/sfr.png "Formulaire d'inscription SFR")
Sans rire, préciser « en majuscules et sans accents » en gras c’est que le problème a été repéré lors de la conception du formulaire, ou que les retours clients en assistance téléphonique ont été assez importants pour justifier la modification du texte.
Dans ce cas, vous ne croyez pas que la saisie devrait être libre ? À votre application de mettre en majuscules et de retirer les accents si ça lui chante, mais ne faites pas faire votre boulot à l’utilisateur.
Le pire c’est pour le numéro de téléphone parce que je l’ai vu dans *tous* les formulaires d’opérateurs téléphonie et internet. Le champ est bloqué à dix caractères, donc un numéro de téléphone sans espaces.
Bon, c’est juste agaçant à la saisie, mais c’est surtout inutilisable au copier-coller car quasiment tout le reste de la France utilise des espaces comme séparateur. C’est donc à l’utilisateur d’aller copier-coller le numéro dans un éditeur de texte pour retirer les espace et le copier-coller à nouveau dans le formulaire.
Franchement, le développeur n’avait pas la capacité de retirer lui même espaces et ponctuation côté serveur ? Ça coutait vraiment trop cher ?
Développeurs : Soyez fainéants, mais ne faites pas faire votre boulot par vos utilisateurs !
J’ai beaucoup aimé le site de Bayrou, et j’ai découvert il y a quelques temps celui de Troll d’idées. Je vous encourage à explorer au moins le second.
Il y a un petit mouvement vers les sites à page unique avec des ancres et des séparateurs visuels pour naviguer. Je dois avouer que c’est génialissime quand c’est bien pensé et bien travaillé, mais ça demande à priori un investissement en conception largement supérieur au site habituel. Sans cet investissement, le résultat est rarement au niveau.
Mon problème c’est que sur ces deux sites, il manque une version mobile. Est-ce une bonne pratique sur mobile ? Ce genre de design résistera-t-il au temps ou restera-t-il un effet de mode comme furent en leur temps les effets de paralaxe (dont Troll d’idées abuse d’ailleurs un peu) ?
Connaissez-vous un site qui fait de même avec en plus du responsive design ?