L’iPhone 6 / 6 Plus : la roll’s des smartphones ?

iPhone-6-Plus

A moins de vivre dans une caverne, mais vous ne seriez pas sur ce blog, vous avez forcément entendu parler de la nouvelle gamme d’iPhone présentée par Apple il y a un mois. Encore une nouvelle gamme, ca change tous les ans, alors en quoi celle-ci se démarque des précédentes ?

Pour le savoir, il faut commencer par une petite rétrospective des modèles et comparer les points les plus importants, la taille bien sûr, qui est LA grande évolution de cette année, mais aussi l’évolution des performances, naturelle au fur et à mesure de l’avancée des recherches technologiques en matière de miniaturisation et de gain constant de puissance à consommation énergétique égale.

Je vais m’atteler à cette rétrospective avec l’expérience que j’en ai eu, ayant attrapé le virus Apple à partir du modèle 3G, et je suis encore bien “atteint” !

Alors, qu’est-ce qui rend cette gamme si remarquable ?

Lire la suite »

Fever RSS Reader est publié !

Et voilà après encore quelques jours d’âpres heures de travail depuis le dernier post, mon petit logiciel est sur la toile, du côté de chez Codeplex !

Pourquoi d’âpres heures alors que tout semblait en voie de finition lors du dernier post publié 4 jours auparavant ? 2 raisons essentielles à cela :

  • Premièrement, le composant de liste que j’avais utilisé pour remplacer le composant d’origine payant, s’est avéré assez instable dans son comportement, faisant planter trop régulièrement l’application. Je suis donc passé au composant standard fourni par Visual Studio, non sans craintes quant à ses capacités par rapport à mes besoins… mais finalement, celui-ci s’est avéré suffisant, et bien plus stable ! Mais l’adaptation du code existant au fonctionnement de ce nouveau composant ne s’est bien sûr pas fait d’un claquement de doigt !
  • Deuxièmement, j’ai bien anglicisé complètement l’application comme prévu, à savoir tous les éléments textuels et messages affichés par celle-ci (en dehors bien sûr du contenu externe des flux RSS affichés), mais aussi tous les commentaires que j’ai apporté dans le code source pour expliquer la logique de raisonnement des différentes portions de code. Mais je ne me suis pas arrêté là, après tout il aurait été dommage de perdre notre belle langue au profit de l’anglais, j’ai donc cherché comment faire pour avoir les 2 langues au niveau des éléments d’interface et des messages affichés, ce qui m’a pris une bonne journée de tâtonnement… les joies de l’auto-apprentissage ! Mais je suis finalement parvenu à mes fins, l’application est donc à présent officiellement en langue anglaise avec une traduction complète en français.

Le résultat est à voir sur ce site : https://feverrssreader.codeplex.com en langue anglaise encore une fois – la rédaction du texte de la page d’accueil fut un exercice linguistique intéressant du reste-, toujours dans le but de maximiser la petite audience potentielle du produit… Le code source est téléchargeable tout comme une première version fonctionnelle de l’application. Je rappelle toutefois que l’application nécessite de posséder un compte associé à un serveur sur lequel est installé le script Fever, qui est téléchargeable ici : http://www.feedafever.com

Lire la suite »

Fever RSS Reader : finalisation et publication en open source en vue !

Depuis le dernier billet, j’ai passé pas mal de temps à améliorer Fever RSS Reader, en vue d’une publication sur un site spécialisé, un annuaire de projets open source.

Qui dit publication dit distribution, j’ai donc du procéder au remplacement de deux composants essentiels de mon programme, ceux qui gèrent l’arborescence sur la partie gauche et la liste des éléments sur la partie centrale. Il s’agissait de deux composants commerciaux, certes pas bien chers, mais qui ne m’autorisaient pas à publier mon projet gratuitement. Je les ai donc remplacé, l’un par un composant de base fourni par l’environnement de développement, l’autre par un autre composant, libre celui-ci. Ce remplacement m’a demandé pas mal d’heures de travail, à comprendre leur programmation et à résoudre les bugs imputables au temps nécessaire à la bonne compréhension de leur fonctionnement.

Ceci fait, une ultime phase de développement s’en est suivie, à savoir l’implémentation des fonctions spécifiques à Fever. Car quitte à distribuer le logiciel et à le “vendre” comme un client Fever, autant faire en sorte qu’il soit complet. Et les 2 fonctionnalités ne furent pas simple à implémenter, l’une consistant à masquer des éléments qui ne sont pas destinés à être visualisés, l’autre à faire une liste d’éléments bien différente dans sa forme, et donc dans sa programmation, aux autres présentant la liste des articles de la sélection en cours. Mais finalement, tout est en place et fonctionne pas trop mal !

La prochaine, et ultime, étape de cette phase initiale de développement dont je suis jusqu’à présent le seul contributeur, va consister à publier mon projet sur un site spécialisé, à savoir Codeplex. Pour cela, et pour augmenter la lisibilité de celui-ci et l’intérêt des développeurs tiers, je vais angliciser l’interface, les noms des variables du code et les commentaires de celui-ci. En effet, Fever étant un script encore assez peu utilisé, je pense avoir un potentiel d’audience bien plus important si mon projet est en langue anglaise que française.

Le but de cette publication est de permettre à des développeurs venus de tout pays, qui voudront bien s’y intéresser, de travailler de manière collaborative sur mon projet, de façon à améliorer le logiciel (et il y a du boulot en terme d’interface et d’ergonomie !). Mais il est également envisagé que la source de mon programme puisse servir de modèle ou de compréhension au fonctionnement de l’API de Fever, pour que d’autres projets de clients Fever sous Windows voient le jour, ou pour que le support de Fever soit implémenté dans des projets d’agrégateur RSS existants.

Ce serait là un bel aboutissement pour mon petit projet tout personnel !

GRD Reader est mort, vive Fever RSS Reader !

Bonjour,

Comme annoncé précédemment dans le blog, Google a décidé un peu plus tôt cette année d’arrêter son service d’agrégation de flux RSS nommé Reader, ceci à compter du 1er juillet de cette année.

Conséquence, tous les logiciels ou scripts conçus pour s’interfacer avec le service Google Reader cesseront de fonctionner en l’état passé cette date. Pour continuer d’utiliser un agrégateur de flux RSS en ligne, offrant la possibilité très utile de synchroniser la liste de lecture des articles dans n’importe quel logiciel ou script supporté, les développeurs des applications concernées doivent donc obligatoirement adapter leur application en prenant en charge un autre service d’agrégation en ligne, proposant de préférence un niveau de fonctionnalités aussi proche que possible du service de Google qui était très complet. Le service choisi doit également disposer d’une API dédiée qui permet d’interfacer le logiciel ou le script avec la base de données de l’agrégateur contenant les articles récupérés afin de les consulter depuis celui-ci.

Pour ma part, j’ai choisi d’utiliser l’agrégateur Fever (http://www.feedafever.com) qui, s’il n’est pas entièrement gratuit, étant donné qu’il faut payer une licence à l’installation, a le mérite de le devenir une fois la licence acquise, là où de nombreux autres services d’agrégation ne manqueront pas de faire payer leur service via un abonnement mensuel (certains le font déjà au moment d’écrire cet article). D’autre part, il s’agit d’une solution auto-hébergée, qui tourne très bien sur le serveur de mon hébergement mutualisé. Evidemment cela requiert des connaissances pour la mise en place, mais une fois installé l’agrégateur fonctionne parfaitement de façon autonome. Enfin l’API proposée par cet agrégateur, un cran moins complète que celle de Google Reader, est néanmoins suffisamment fonctionnelle pour l’usage que je fais de ce service, qui peut être qualifié de classique.

Lire la suite »

Retour sur près de 3 semaines de galère dans les transports en commun

Entre le 23 février et le 14 mars de cette année, une ligne de transports du réseau Transilien a été victime de toute une série d’incidents d’exploitation qui ont aboutit sur cette période de 20 jours, à une rupture complète du service pendant 14 jours, à un service dégradé durant 4 jours, et à un service normal durant 2 jours qui étaient sur un WE. Comment en est-on arrivé là ? Explications.

Bien évidemment la ligne en question est celle que je prends tous les jours ouvrés pour aller à mon travail, en l’occurrence la ligne U qui relie les gares de La Verrière à La Défense. Voici un plan pour situer cette ligne, elle est tracée de couleur rose :

plan_ligneU

Cette carte montre au passage les autres lignes utilisables pour compenser l’arrêt de la U, à savoir :

  • RER C (en vert clair) de Saint Quentin en Yvelines à Issy Val de Seine puis tramway (en pointillés) de Issy Val de Seine à La Défense
  • Transilien ligne N (vert foncé) de Saint Quentin en Yvelines à Paris Montparnasse puis métro lignes 6, 12 ou 13 puis 1 jusqu’à La Défense
  • Transilien ligne N (vert foncé) de Saint Quentin en Yvelines à Viroflay rive gauche puis correspondance à pieds (800 m) pour Viroflay rive droite, de là ligne L du Transilien jusqu’à La Défense

Ces différents itinéraires de substitution représentent un allongement du temps de trajet de 20 à 30 minutes sur un trajet ferroviaire de 30 minutes avec la ligne U. Allongement non négligeable donc.

La ligne U a une spécificité qui n’arrange pas son exploitation, elle n’a aucune gare qui lui est propre, elle utilise exclusivement deux réseaux (Montparnasse – ligne N – et Saint Lazare – ligne L) reliés par un viaduc au niveau de Viroflay. Ce qui fait qu’il suffit qu’il y ait un problème sur l’un des 2 réseaux pour que l’ensemble de la ligne U soit perturbée. Ce qui fait aussi que cette ligne qui ne dessert donc aucune gare spécifiquement est souvent sacrifiée (mise à l’arrêt) lors d’importantes perturbations sur les 2 réseaux la constituant, ce qui on le verra plus tard a contribué à la galère des jours passés.
Pour plus d’information sur cette ligne : http://fr.wikipedia.org/wiki/Ligne_U_du_Transilien

Lire la suite »

Abandon définitif du projet GReader

Bonjour,

GReader était un projet de client Windows pour le service Google Reader, réalisé par mes seuls moyens, forcément limités notamment au niveau de l’interface graphique qui n’est pas le domaine informatique dans lequel j’ai le plus de compétences. Après avoir donc élaboré un prototype à peu près fonctionnel, mais très basique graphiquement, j’ai laissé le projet en stand-by, utilisant d’autres solutions bien plus abouties, réalisées par des développeurs professionnels, sur d’autres plate-formes (iOS, Mac).

Ce jour, une triste nouvelle vient enterrer définitivement ce projet : Google arrêtera le service Reader le 1er juillet prochain (source). Il ne fait guère de doute que d’autres éditeurs de service proposeront à terme un service équivalent, mais le prototype actuel cessera de fonctionner à l’arrêt de Google Reader.

Je maintiendrai les articles de ce blog relatifs au programme en ligne, pour conserver une petite trace de cette petite aventure dans l’univers du développement d’applications.

Mise à jour du statut des articles dans Google Reader

Nous arrivons à la dernière étape de la gestion des fonctionnalités de Google Reader du programme, après avoir passé en revue les requêtes de récupération des catégories d’articles et des articles associés ainsi que des compteurs d’articles non lus.

Cette dernière sera rapide car en fait, qu’il s’agisse de marquer un article lu, non lu, suivi ou non suivi, la requête aura la même base avec simplement des paramètres différents. Voici la requête en question :

 https://www.google.com/reader/api/0/edit-tag?client=scroll",
"POST", "i=[id_article]&a=[list]&r=[list]&async=true&T=[Token]"

Quelques explications sur les paramètres de cette requête :

  • i : identifiant unique de l’article, récupéré dans le flux XML des listes de lecture, permet d’identifier de manière unique un article quelque soit sa catégorie de rattachement
  • a : action d’ajout à une liste interne de Reader
  • r : action de suppression d’une liste interne de Reader
  • T : token, qui est une variable nécessaire pour faire des actions de modification du statut des articles. Cette variable change régulièrement de valeur, il faut donc périodiquement la renouveler.

Lire la suite »

Réception et traitement des données de Google Reader (2è partie)

Dans la première partie de ce thème nous avons vu comment récupérer les différentes listes de lectures et les abonnements de l’utilisateur. Si les requêtes étaient assez nombreuses, elles étaient plutôt simples à mettre en œuvre, notamment de par le format des résultats, en XML.

Dans cette deuxième partie il y aura beaucoup moins de requêtes mais le traitement sera rendu plus complexe par l’utilisation par Google du format ATOM pour fournir les articles correspondant à chaque liste de lecture. Il est possible d’exploiter directement de format dans VB.Net par l’utilisation de classes créées spécialement pour çà, mais par soucis de cohérence j’ai utilisé une fonction de conversion de format de l’ATOM vers le XML. Il faudra par la suite gérer l’affichage des articles dans une liste dédiée dans la fenêtre de l’application.

Mais avant d’aller plus loin, il est intéressant de préciser que le format ATOM a été créé pour palier certaines lacunes du XML en terme de flexibilité dans le contenu du document généré. Google a donc très probablement considéré que pour les listes des articles le XML devait s’avérer trop strict pour répondre à ses besoins. Cependant le programme que je conçois s’en accommodera sans problème.

Après cette petite phase introductive, passons maintenant au vif du sujet ! Lire la suite »

Réception et traitement des données de Google Reader (1ère partie)

Il est maintenant temps de rentrer le vif du sujet avec les requêtes de récupération des données en provenance du service Google Reader.

Ces requêtes se font dans VB.Net avec la classe intégrée au framework .Net nommée Net.WebRequest, qui revient sur le principe de fonctionnement à entrer une URL dans un navigateur web (avec quelques options avancées tout de même).

Dans la suite de ce billet est détaillée une première liste des requêtes avec leurs principales fonctions. Pour ce billet, seules les requêtes de récupération d’informations sont indiquées, celles, moins nombreuses, qui permettent de modifier une information relative aux flux RSS consultés (article marqué lu/non lu et mis ou retiré de la liste de suivis) feront l’objet d’un billet spécifique. D’autre part, une seconde liste suivra celle-ci pour alléger ce billet bien fourni.

Lire la suite »

Le XML, un format de données au coeur du programme

Après la technique de programmation évoquée au précédent billet, un dernier point est indispensable à maitriser avant de pouvoir se lancer dans l’écriture d’un programme correspondant à mon projet. En effet, le programme requête chez Google toute une série d’informations relatives aux abonnements de l’utilisateur connecté (qu’il faut d’abord authentifier), les choses étant plus complexes qu’un simple affichage brut (sans traitement) des données reçues.

Celles-ci peuvent être organisées ou stockées de plusieurs manières, il peut s’agir d’une base de données si le volume concerné est important, ou de fichiers textes pour des volumes plus faibles, et dans le cadre du programme, c’est ce dernier format qui est utilisée. Mais encore faut-il pour qu’il soit exploitable que ce fichier soit structuré d’une manière précise qui permette de retrouver l’information voulue. Concrètement, toutes les données stockées chez Google pour le service Reader peuvent être récupérées ou adaptées au format XML.

Mais qu’est-ce que le XML ?
Lire la suite »