Divers

Divers

UITableView + API GitHub + CocoaPods = Keep it Simple, keep it Stupid!

UITableView + API GitHub + CocoaPods = Keep it Simple, keep it Stupid!

Nous avons vu dans un article précédent comment utiliser RestKit pour se faciliter la vie lorsque nous travaillons avec des services web exploitant le format JSON. Toutefois, l’utilisation d’un framework fullstack peut se révéler contraignant dès lors que l’on sort du cadre pour lequel il a été destiné. Malheureusement, cela arrive souvent assez rapidement.

Nous verrons dans cet article comment reproduire une application similaire à celle construite grâce à RestKit, sans pour autant abandonner l’idée de gagner du temps grâce à l’utilisation de quelques librairies bien choisies :

Le monde iOS, comme tout environnement mature, dispose de nombreuses librairies Open Source intégrables dans vos projets via l’utilisation d’un Dependency Manager. Dans notre cas, nous utiliserons CocoaPods déjà présenté dans un article précédent.

La création de ce tutoriel fait suite à une présentation en XKE d’une session d’1h30 d’introduction aux développements iOS. Ce tutoriel est donc réalisable en un temps raisonnable en suivant les instructions ci-dessous.

Création du projet

Avant d’utiliser CocoaPods, vous devrez créer un projet de type Empty Application pour iOS via XCode:

Vous aurez ensuite à créer un fichier Podfile à la racine de votre projet XCode avec les dépendances suivantes:

platform :ios, '5.0'
pod 'JSONKit', '1.5pre'
pod 'Underscore.m', '0.2.0'
pod 'AFNetworking', '1.1'
pod 'MBProgressHUD', '0.6'
pod 'SVPullToRefresh', '0.4'
pod 'SDURLCache', '1.2'
pod 'AFHTTPRequestOperationLogger', '0.10.0'
pod 'DCKeyValueObjectMapping', '1.3'

Puis, vous devrez exécuter la commande suivante pour générer le workspace et intégrer le code des dépendances:

pod install

Il faudra alors relancer votre projet en ouvrant le fichier *.XCodeWorkspace, plutôt que le fichier *.XCodeProject. Vous serez alors prêt à développer votre application.

(suite…)

Programmation fonctionnelle en Objective-C

Programmation fonctionnelle en Objective-C

underscoremDans un article précédent, nous avons entrevu les possibilités offertes par l’utilisation des Blocks en Objective-C. Leur similarité avec les expressions lambda de la programmation fonctionnelle que vous pouvez retrouver dans Java 8, Scala ou bien encore JavaScript est évidente. Cependant, nous ne sommes pas habitué avec Objective-C à penser ou bien écrire dans un style fonctionnel. Cependant, il existe des libraries qui permettent de faciliter l’usage de l’approche fonctionnelle. Plusieurs projets ont même fleuri depuis la mise à disposition des blocks avec la sortie d’iOS4.
En JavaScript, la librairie underscore.js est très appréciée par les développeurs web pour sa simplicité et son efficacité. Cette librairie a d’ailleurs tellement de succès qu’elle a traversé la frontière des langages pour être implémentée en Objective-C! Il en existe à ce jour au moins deux implémentations, toutes les deux sous license MIT.

Le projet Underscore.m semble fournir un support plus abouti des fonctionnalités proposées par la librairie JavaScript originale, et surtout propose un site documentaire complet qui permet de démarrer rapidement et de trouver un grand nombre d’exemples.

Installation

Pour démarrer un projet avec Underscore.m, rien de plus simple, il suffit d’utiliser CocoaPods que nous avons découvert dans un article précédent.

Pour rappel, si vous n’avez pas encore installé CocoaPods, il suffit de lancer les commandes suivantes pour installer l’outil (A condition d’utiliser une version 1.9 de Ruby):

$ gem install cocoapods
$ pod setup

(suite…)

Dans la famille des XaaS, je voudrais le BaaS

Dans la famille des XaaS, je voudrais le BaaS

En ce début de week-end, je suis tombé sur un terme que je n’avais pas encore vu, mais qui m’a tout de suite fait tilt et qui prend tout son sens dans le business de la mobilité.

BaaS est l’acronyme pour Backend as a Service.

Quand on code une application mobile on aime pas trop se prendre la tête sur d’autres sujets que le développement de l’application en elle-même qui demande déjà beaucoup de temps à concevoir et qui devient assez rapidement complexe (Problématiques multi-plateforme, multi-version d’os, …).

C’est pour ça que de nombreuses startup et sociétés spécialisées dans la mobilité délèguent le développement de la partie serveur à un ensemble de services webs tel que: Parse ou bien Deployd …

Ces services de nouvelles génération viennent compléter l’écosystème habituel de services sociaux (Twitter, Facebook, …) avec par exemple: Flurry pour les stats ou bien encore Urban Airship pour les notifications push.

La particularité des services comme Parse et Deployd réside dans le fait qu’elles proposent sur le fait de construire non pas un backend, mais directement les données utiles aux applications mobiles. Ainsi on ne pert plus de temps à construire le backend serveur, on ne construit que les structures de données, et on s’intègre avec le framework du services web qui fournit également les librairies côté client.

Ces startups proposent des Backend as a Service qui permettent donc de créer les services web dans le cloud dont on a besoin sans perdre de temps avec la technique. Ils intègrent en général des mécanismes d’authentification, ce qui permet de ne pas uniquement pouvoir stocker les habituels highscores d’un jeu, mais également de pouvoir stocker des données relatives à un utilisateur dans le contexte d’une application mobile.

Différents services de ce nouveau type:

Une vidéo de démonstration du service deployd :

Enfin, voici une map très intéressante tirée de l’article suivant: http://www.kinvey.com/index.php?option=com_k2&view=item&id=217&Itemid=322

Ajoutez vos flux Twitter et Delicious sans plugin dans WordPress

Ajoutez vos flux Twitter et Delicious sans plugin dans WordPress

J’ai toujours trouvé laborieux la recherche de plugins pour WordPress. On ne sait pas ce qu’on installe et le résultat est souvent loin de ce qu’on attend. Autant dire qu’il est parfois plus efficace de faire le job soi-même. Le résultat obtenu est parfois meilleurs et ce en peu de temps.

En cherchant un plugin pour afficher dans la sidebar du blog la user timeline de mes tweets ou bien mon feed Delicious, j’ai souvent eu de mauvaises surprises liées au performances: Page qui bloque au chargement plus ou moins longtemps dans le meilleurs des cas, voir page qui plante lorsque le chargement côté serveur n’aboutit pas ou bien lorsque le javascript est mal codé.

1. Intégrer un widget Twitter

Pour cela rien de plus simple, il suffit d’ajouter un widget de type texte et d’y coller le contenu suivant:

<div id="twitter_div">
  <ul id="twitter_update_list"></ul>
  <a href="http://twitter.com/alexiskinsella" id="twitter-link" style="display:block;text-align:right;">follow me on Twitter</a>
  <script type="text/javascript" src="http://twitter.com/javascripts/blogger.js"></script>
  <script type="text/javascript" src="https://twitter.com/statuses/user_timeline/alexiskinsella.json?callback=twitterCallback2&include_rts=1&include_entities=0&contributor_details=0&exclude_replies=1&trim_user=1&count=8">
  </script>
</div>

N’oubliez pas de personnaliser au mieux les options afin d’éviter de récupérer du contenu qui ne sera de toute façon pas affiché!

2. Intégrer un widget Delicious

<script type="text/javascript" src="http://feeds.delicious.com/v2/js/akinsella?title=&count=12&sort=date&name&showadd"></script>

Cerise sur le gâteau, l’intégration des 2 scripts précédents n’ajoute aucun style au HTML généré, et si votre thème est correctement développé, le résultat sera naturellement intégré avec celui-ci.

Ces deux scripts sont plutôt performants et votre blog ne souffrira que peu de leur ajout dans le rendu de votre page. Delicious a souffert pendant longtemps de problème de performances, ceci semble ne plus être le cas, et le script se comporte très bien. Cependant à toutes fins utiles, placez plutôt ces scripts dans la sidebar de droite, afin de privilégier l’affichage du contenu de votre billet avant tout.

Fork du plugin WordPress WP-JSON-API disponible sur GitHub

Fork du plugin WordPress WP-JSON-API disponible sur GitHub

Le plugin WP-JSON-API fournit une API REST permettant d’exposer les données d’un blog WordPress (Tags, Categories, Auteurs, Posts, …). Ce plugin est plutôt assez complet et vraiment utile. Malheureusement, le plugin ne semble pas vraiment maintenu et souffre de quelques lacunes (Plantages, manque d’options de filtrage, …).

Ayant utilisé ce plugin à divers occasions, j’en ai profité pour corriger quelques défauts, et j’en ai profité pour forker le repo GitHub original pour mettre à disposition les modifications effectuées.

Vous pouvez retrouver ce fork sur mon compte GitHub à l’adresse suivante: https://github.com/akinsella/wp-json-api.

N’hésitez pas à faire vivre ce plugin WordPress en le forkant ou bien même en y contribuant du code!

Installer les outils dos2unix, mac2unix et compagnie sur un Mac

Installer les outils dos2unix, mac2unix et compagnie sur un Mac

L’outil dos2unix n’est pas disponible par défaut sous Mac. Il existe bien entendu des alternatives, notamment avec l’outil ‘tr’, mais il est agréable également d’avoir à disposition dans sa boîte à outils ce petit utilitaire.

Pour l’installer, créez un script « makeDos2Unix.sh » et copiez-y le code ci-dessous. Une fois le fichier créé, il faut chmoder le fichier avec la commande suivante:

chmod 755 makeDos2Unix.sh

et lancez le script en tapant:

./makeDos2Unix.sh

Lors de son exécution, le script va ouvrir la page web de l’outil, puis installer les différentes commandes sur votre Mac.

#!/bin/bash
open -a Safari http://slagheap.net/darwin/

curl -L -O http://slagheap.net/darwin/dos2unix-051230.tar.gz

tar -xzf dos2unix-051230.tar.gz

cd dos2unix

export MAKEOBJDIR=.

sed -i "" -e 's/NOMANCOMPRESS/NO_MANCOMPRESS/' -e 's|/man/man|/share/man/man|' Makefile

bsdmake all

# perform a dry run to show install locations
# take the output of bsdmake's dry run, insert some newline characters and "echo" commands, then run it

bsdmake -n install |
sed \
-e 's/\([^;]\);\([^;]\)/\1'$'\\\n''\2/g' \
-e $'s/;;/&amp;\\\n/g' \
-e $'s/do *case *\\$# *in/&amp;\\\n/g' |
sed \
-e 's/^\( *install -.*\)/echo \1/' \
-e 's/^\( *\)\(rm \)/\1echo \2/' \
-e 's/^\( *\)\(ln \)/\1echo \2/' |
bash -s | uniq | grep -E '^(install|/)'

sudo bsdmake install

man dos2unix

La commande suivante, ci-dessous, permet d’arriver au même résultat sans avoir à installer l’exécutable dos2unix:

tr '\r' '\n' < input.txt > output.txt

Source originale du script: http://codesnippets.joyent.com/posts/show/10939

Publication du code source de l’application Devoxx Mobile et retour d’expérience

Publication du code source de l’application Devoxx Mobile et retour d’expérience

La semaine dernière Xebia annonçait la sortie de l’application mobile Xebia pour Devoxx France, ainsi que la publication prochaine du code source de l’application. C’est aujourd’hui chose faite puisque vous pouvez le consulter sur son espace GitHub à l’adresse suivante : https://github.com/xebia-france/devoxx-mobile.

Le code source est publié sous license MIT. Je vous encourage à aller le consulter, le forker ainsi qu’à partager vos retours d’expériences autour du développement d’applications mobiles basées sur des technologies web.

Génèse et objectifs

Le développement de l’application s’est focalisé autour des axes et objectifs suivants :

  • Explorer les technologies web pour développer une application mobile, que cela soit par l’utilisation d’HTML5 et CSS3 via le cadre de développement proposé par la librairie jQueryMobile ou bien par l’intégration de différentes librairies JavaScript telles que Require, Backbone, Underscore ou Lawnchair.
  • Mettre en oeuvre PhoneGap et son usine logicielle en ligne PhoneGap Build pour délivrer des applications web encapsulées dans des coquilles natives afin de pouvoir les publier sur les markets Android, Chrome ou bien encore iOS.
  • Fournir une application qui sera utilisable sur l’ensemble des matériels du marché et vérifier dans quelle mesure les applications mobiles web peuvent se comparer aujourd’hui face aux applications natives. 
  • Développer une application ayant une base de code unique afin d’éviter d’avoir à gérer la fragmentation des plateformes.
  • Etre en mesure de répondre à un cahier des charges complet en un temps réduit. Ce cahier des charges comprenant:
    • Le développement des différents écrans applicatifs : Liste des sessions par journée avec affichage complet des détails, ainsi que les listes et détails des speakers, des salles, et des tracks.
    • La gestion et le stockage des favoris (On parle ici des sessions)
    • La présentation du programme Xebia pendant les 3 jours de la conférence
    • Une application étant capable de fonctionner en mode offline avec synchronisation et stockage des données
    • Un affichage de la timeline twitter XebiaFr et DevoxxFr
    • Un fonctionnement effectif sur un ensemble étendu des matériels allant du téléphone au PC en passant par la tablette quelque soit l’OS

(suite…)

QCon London – Développement Web mobile, Javascript et HTML5

QCon London – Développement Web mobile, Javascript et HTML5

Avec l’émergence de la mobilité dans notre quotidien, ce sont également de nouveaux besoins informatiques qui sont apparus dans nos SI. Au début, la problématique était simple puisque la plateforme iOS était sans concurrence. L’arrivée de nouveaux challengers a multiplié les nouveaux développements, et la fragmentation des développements est rapidement devenue un problème sérieux à adresser, voire même un véritable enjeu budgétaire: la fragmentation coûte cher et de prime abord ne semble pas toujours rentable à traiter. Certaines entreprises font ainsi le choix de supporter de nombreuses plateformes, tandis que d’autres ne supportent que le strict minimum, c’est à dire iOS et Android, voire même des fois uniquement iOS.

Avec l’avènement d’HTML5 et le bouillonnement actuel du web, des solutions innovantes ont commencé à pointer le bout de leur nez. Sont apparus tout d’abord des toolkits mimiquant l’interface utilisateur d’iOS, puis sont arrivés progressivement des frameworks plus ambitieux ayant pour objectif d’adresser ce problème de fragmentation. Le champion en la matière s’appelle jQueryMobile, il supporte la quasi totalité des plateformes mobiles à ce jour, et ses principaux concurrents sont Sencha Touch et Titanium d’Appcelerator. Même si ces outils sont relativement récents, ils permettent d’ores et déjà de développer des solutions sérieuses basées sur des technos web, et des nouveaux outils innovants fleurissent cette année à un rythme effréné (Rhodes, Jo, Wink, Dojo Mobile, Kendo, M Projecttrigger.io), ce qui montre une furieuse tendance à vouloir trouver des solutions à cette fragmentation via des standards déjà maîtrisés.

Il faut cependant reconnaître que ces idées sont nouvelles, et de nombreux gaps viennent compliquer légèrement les choses. A commencer par le fait que le parc mobile actuel propose des navigateurs plus ou moins matures, dont le support d’HTML5 varie de façon non négligeable selon la version de l’OS et le type de plateforme. Bien que les moteurs de rendu et de JavaScript des navigateurs mobiles évoluent de manière incroyable, tout comme leur matériel d’ailleurs, on est loin des performances natives de ces combinés. Il suffit pour cela de regarder la fluidité d’iOS pour s’en convaincre. Cela est toutefois à mettre dans la balance avec un univers web qui évolue (très) rapidement et qui chaque jour abat des barrières.

(suite…)

QCon London – Zero to ten million daily users in four weeks

QCon London – Zero to ten million daily users in four weeks


Jodi Moran, co-fondatrice et CTO de la société Plumbee, spécialisée dans le développement de jeux sur le web (Jeux Facebook en particulier), a présenté lors de QCon Londres un retour d’expérience sur les pratiques de développement mises en oeuvre au sein de sa société, et qui ont permis de répondre à des contraintes de croissance fulgurante.

Jodi démarre la présentation avec la définition de la notion de « Une vitesse soutenable »:

  • La vitesse est mesurée par le temps séparant l’expression du besoin à son changement effectif.
  • La durabilité est mesurée par la capacité à garder cette vitesse dans le temps.

Maintenir un rythme soutenable permet d’avoir de la réactivité, ce qui est primordial pour garder son audience. Mais cela permet également d’avoir un meilleur rendement et des investissements plus faibles.

(suite…)

QCon London – The Guardian, Simplifying Development

QCon London – The Guardian, Simplifying Development


Lors de la dernière journée de QCon Londres, dans le cadre du track The rise of Scala & Functional Programming, les équipes du journal The Guardian nous proposaient un second retour d’expérience via leur architecte Graham Tackley. L’objectif de cette session était de présenter comment les équipes sont passées à Scala et comment ce choix a simplifié les développements.

Tout d’abord, il faut savoir qu’entre 2006 et 2008, l’architecture applicative du site web du journal reposait sur un socle composé des technos Spring, Hibernate et Velocity. Assez rapidement, ce socle commença à poser des problèmes de maintenabilité aux équipes. En premier lieu, la cause incombait à la verbosité des technologies utilisées. Pour se faire une idée, il suffit de jeter un œil aux métriques et en particulier au cumul des lignes de code:

  • les classes Java représentaientnt 185.000 lignes,
  • les fichiers XML : 35.000 lignes correspondant en grande partie au code Spring,
  • les fichiers de templating (Velocity) : 72.000 lignes.

Ces totaux peuvent vous sembler importants, mais il faut se rappeler que Java n’est pas un langage appliquant particulièrement les principes DRY. De plus, les configurations XML des applications basées sur Spring étaient particulièrement verbeuses ce qui est moins le cas aujourd’hui depuis la généralisation de l’usage des annotations. Il faut cependant relativiser s’il faut ramener ces chiffres à la verbosité des tests unitaires qui représentaient à l’époque, accrochez-vous, 248.000 lignes de code.

Graham nous explique qu’un cycle de développement de deux semaines pour une application web est bien trop long. De plus, cela ne répond pas aux exigences du monde du web. Cependant, cela est trop rapide pour les équipes qui ne peuvent répondre aux cadences exigées par le monde du web avec un applicatif aussi lourd à faire évoluer.

Un autre aspect des problématiques de maintenabilité et de charge semblait venir de la partie ORM de l’application. Non pas qu’Hibernate, utilisé à l’époque, soit remis en cause, mais plutôt les concepts associés.

Une des premières initiatives prises pour remédier aux problèmes de cycles de développement a été de scinder l’application monolithique en différentes micros applications indépendantes avec des  cycles de développement très courts et dont la maintenabilité est facilitée par leur faible taille et leur découplage.

Rapidement, les équipes ont commencé à créer des micros applications dans différentes technologies telles que Python avec Django. Ces outils ont rapidement permis aux équipes de se focaliser sur des aspects métiers plutôt que sur des aspects techniques. Cependant, ces nouveaux environnements semblaient poser des problèmes d’exploitation puisque les environnements d’exécution associés impliquaient de nouvelles acquisitions de compétences. Cela avait pour effet de générer des problématiques d’exploitation qui jusqu’ici n’existaient pas. Comme Graham le rappelle, il vaut mieux privilégier les évolutions plutôt que les révolutions.

Afin de retrouver un environnement proche du monde Java, les équipes ont cherché de nouvelles solutions et se sont orientées vers le développement de composants basés sur Scala. L’objectif recherché étant d’avoir accès aux avantages que peuvent apporter la JVM et l’environnement Java : même infrastructures, même outils (Maven notamment), même bibliothèques, mêmes runtimes, etc. Le compilateur Scala génère du bytecode et un war, c’est à dire tout ce qu’il y a des plus standard dans le monde java. Scala étant opérable avec Java, il est possible de mixer les deux langages dans une même application et de pouvoir reprendre certaines parties de code de l’un ou de l’autre.

Scala est connu pour sa concision, ce qui est réellement important aux yeux de Graham vis-à-vis des problématiques engendrées par la taille de la base de code historique.

En novembre 2009, les équipes sont parties sur un socle technique basé sur Java + Guice + Guice Servlet + Apache Solr et 3 à 4 développeurs, pour switcher en février 2010 de Java à Scala. Graham explique qu’Il n’aura fallu que trois mois à l’équipe pour passer le projet en Scala et le porter en production. Par la suite, il insiste sur le fait que la mise en production s’est passée sans incident, et ce, même avec un changement aussi impactant.

Enfin en juillet 2010, les équipes sont passées à SBT afin de disposer d’un outils plus puissant et mieux adapté aux besoins des projets Scala. SBT permet en particulier d’outrepasser les problématiques de lenteur du compilateur Scala.

La stack actuellement exploitée par le site est composé de Scala + Lift + Apache Solr. On pourra s’interroger sur ces changements de technologies incessants. Mais comme le répète Graham, mieux vaut privilégier les évolutions que les révolutions.

Afin de faire taire certaines idées persistantes à propos de la supposée difficulté d’apprendre Scala, Graham prend les devants en expliquant que ce choix a été plus bénéfique que prévu pour les équipes. Les membres ont pris beaucoup de plaisir à apprendre ce langage, ce qui a favorisé une forte collaboration dans cet apprentissage. Cela a pris entre un et trois mois pour que chaque développeur devienne productif avec le langage. Graham insiste sur le fait que ses équipes n’ont pas rencontré tous ces problèmes énoncés dans différents articles qui ont enflammé la communauté Scala ces dernièrs mois.

Graham voit au final dans Scala plusieurs avantages pour ceux qui veulent l’utiliser ou bien encore l’apprendre :

  • Scala tend à favoriser l’immutabilité dans les développements,
  • La console Scala encourage la vision du code comme une entité vivante (qui évolue),
  • Les frameworks de tests sont d’une extrême simplicité,
  • Scala ne pousse pas à l’intégrer de frameworks complexes à tous les étages.

Parmi les inconvénients imputables au langage, Graham met en avant :

  • La relation de type « je t’aime, moi non plus » des développeurs (en général) avec SBT. On pourrait dire la même chose avec la communauté Java avec Maven…
  • Le support encore immature des outils,
  • Un compilateur lent,
  • Le rythme des évolutions du langage.

Enfin, Graham dit à demi-mot que le framework Play!2 semble très prometteur et qu’il faut garder un œil dessus dans les prochains mois.

Liens utiles: