Webd

La semaine dernière, Google annonçait officiellement l’ouverture au public de son nouveau service: Google Public DNS. Il s’agit de proposer à tout internaute un service DNS qui se veut offrir une bien meilleure expérience du net à tout les utilisateurs…

DNS, c’est quoi ?

DNS (pour Domain Name System). Il s’agit du système qui traduit les noms de domaines (webd.fr par exemple) en adresses IP (94.23.202.54 pour webd). En effet, les machines ne communiquent que par des adresses IP.

A moins d’être autiste, il est beaucoup plus simple de retenir des adresses textuelles. En fait, il faut voir DNS comme un annuaire du net. Il met en correspondance des noms de site avec des adresses IP. Là où un annuaire téléphonique met en relation des noms de personnes avec des numéros de téléphone.

Ce service DNS est totalement transparent pour les internautes car cela fait partie des services de base lors de la connexion à tout réseau (que ce soit le réseau de son FAI ou un réseau d’entreprise). Et voilà maintenant que Google lance son propre DNS publique et voudrait faire passer tout le Web par ce service.

La suite du billet, c’est par là »

Il est rare (en fait c’est la première fois) que je parle de SUPINFO (école où je m’apprête a faire ma seconde année de Master) sur ces pages. Pourquoi commencer aujourd’hui ? Tout simplement parce qu’une rumeur enfle en ce moment au sujet de l’école. Le principal canal de diffusion: Twitter.

L’idée de la rumeur est assez simple (simpliste ?): SUPINFO serait «macqué» avec Microsoft et obligerait tout ses étudiants à utiliser Windows sur leurs ordinateurs personnels. De là, on imagine rapidement le processus d’embrigadement visant à éloigner les étudiants du monde du logiciel libre (les élèves ingénieur d’aujourd’hui sont les décideurs de demain).
La suite du billet, c’est par là »

L’utilisation d’Interface Builder s’avère très pratique pour les développeurs Cocoa Touch. C’est vrais que c’est génial de pouvoir créer ses interfaces en mode WYSIWYG. Oui mais voilà, cela peut poser quelques problèmes. Outre les cas où l’utilisation du code est nécessaire (pour atteindre la granularité voulue), on peut vouloir renoncer à l’utilisation des nibs pour des raisons de performance.

En effet, dans certains cas l’utilisation des nibs pose de sérieux problèmes de performance. On se retrouve ainsi avec un dur choix: soit on choisit la simplicité (et on utilise Interface Builder), soit on écrit ses interfaces directement dans le code et on gagne en performance. Dans certains cas, l’impact de l’utilisation des nibs sur la performance est quasi nul. La question ne se pose donc pas. Mais parfois, ce n’est pas le cas.
La suite du billet, c’est par là »

Il est souvent utile de comparer deux NSDate dans le temps. Il s’agit de savoir si une date est antérieure ou postérieure à une autre. Le mécanisme offert par Apple pour les comparaisons de NSDate n’est pas des plus pratiques. Il faut utiliser la méthode compare:(NSDate*)date qui retourne un objet de type NSComparisonResult.

Cette méthode est une méthode standard de Foundation. Elle permet, grâce à des résultats de comparaison standardisés d’effectuer un tri sur des objets de façon générique. Oui, mais Apple ne prévoit pas de méthodes un peu plus haut niveau pour les simples comparaisons de dates. Voilà pourquoi j’ai écrit rapidement une addition de la classe NSDate permettant de comparer deux dates intuitivement. Les voici:
La suite du billet, c’est par là »

Je vois assez souvent, dans les fichiers de code qui passent entre mes mains, des en-têtes comme ceci:

//  Created by Julien on 17/01/09.
//  Copyright 2009 __MyCompanyName__. All rights reserved.

Le problème porte sur __MyCompanyName__. Il serait bien plus propre de le remplacer par une valeur personnalisée (et automatique de préférence). Pour ceci, Apple a tout prévu …
La suite du billet, c’est par là »

Il y a peu, je vous présentais ici même comment redimensionner une UIImage. Je vous replace dans le contexte: Dans certains cas, il peut être utile de redimensionner une UIImage. En effet, même si UIImageView gère très bien le redimensionnement, on peut vouloir exporter une image dans une certaine taille. De même, il n’est pas forcement utile de stocker (en mémoire ou bien en dur) une image de grande taille si c’est pour l’afficher réduite par la suite.

Le code qui était présenté est fonctionnel … Oui, mais un collègue m’a fait remarquer que ce n’était pas le cas en multi-threads. Pourquoi ? Tout simplement parce que quand on fait UIGraphicsBeginImageContext(), on travaille dans un contexte unique. Ainsi, quand on voudra redimensionner deux images en même temps, elles partageront le même contexte. Clairement, ça ne peut pas marcher. D’ailleurs: ça ne marche pas !

La suite du billet, c’est par là »