Semaine 43-2015

Quelles sont les tâches les plus difficiles pour un développeur ?

Une petit sondage très intéressant a été publié cette semaine, sur le thème ci-dessus. Si des réponses auxqueles on pouvait s’attendre ressortent (comme « travailler sur le code d’un autre »), des choses plus étonnantes sont mises en avant : « Concevoir une solution » ne reçoit que 0.83% des votes, soit, en passant, ce qui pourrait passer pour la chose la plus difficile à faire, est bonne dernière. J’ai bien rigolé en voyant « Nommer correctement les choses » recevoir pratiquement 8% de votes, au final, nous développeurs on est tous les mêmes. Les $tmp, $bidon et autres $a ont une belle vie devant eux 😉

Source : http://www.developpez.com/actu/91436/Quelles-sont-les-taches-les-plus-difficiles-pour-un-developpeur/

Quelques ressources sur Code Igniter

Un développeur a eu la gentillesse de rencenser des ressources récentes sur Code Igniter (attention à la boucle infinie, certaines se trouvent sur ce blog 😉 )

Source : http://www.developpez.net/forums/d1548180/php/bibliotheques-frameworks/code-igniter-ressources-code-igniter-developpeurs-php-experimentes/#post8413005

La veille techno

J’ai déjà relayé un article sur la veille techno sans fin , c’était du même auteur, il a un peu mûri sa réflexion et propose un article plus abouti, plus complet, avec d’autres solutions.

Source : http://www.miximum.fr/veille-techno-vieux-croutons-paris-web-2015.html

Code Igniter, un framework encore d’actualité

Pour développer mes applications web, j’utilise depuis 2009 Code Igniter. A l’époque, ayant signé un gros projet, bien plus gros que ce à quoi j’étais habituée, genre fois 10, j’ai réalisé que je ne pouvais plus bricoler des petites librairies dans mon coin et qu’il me fallait un framework.

Je me suis donc lancée dans cette douloureuse aventure qu’est le benchmark de frameworks, et j’ai retenu Code Igniter, pour des raisons que j’ai relaté dans cet article.

Au fil des années, Code Igniter a un peu perdu de sa notoriété, supplanté par Symfony qui a pris toute la place (aucun reproche, c’est un excellent framework). A un point qu’il y a deux ans, je me suis demandée si je n’allais pas devoir changer, CI étant à peine connu par les développeurs que je connaissais, ce qui entraînait des difficultés pour demander de l’aide en cas de surcharge de travail.

Cette semaine est sorti un classement de frameworks, réalisé par WebhostFace, un hébergeur, et j’ai eu la surprise d’y retrouver Code Igniter en très bonne place !

Point de vue communauté, il est à la traîne, mais pour le reste, waow ! Rapide et sécurisé, facile à prendre en main, bref, il reste toujours un très bon choix de développement. Bien sûr il a des lacunes, la plus grosse étant à mon avis l’absence de scaffolding, mais une librairie existait pour CI 2.2, on peut espérer qu’elle sera portée sur la version 3.0.

De mon côté, j’ai repris ma librairie préférée de templeting, celle de Colin Williams dont le site n’est plus en ligne, je l’ai mise sur github avec la documentation et j’ai apporté quelques modifications pour qu’elle fonctionne sur CI 3.0. J’encourage les développeurs à faire de même pour les libs qu’ils utilisaient et qui ne sont plus maintenues ou pas encore mises à jour pour CI 3.0

Sources : http://www.developpez.com/actu/88142/Quels-sont-les-frameworks-PHP-les-plus-populaires-de-2015-Un-specialiste-de-l-hebergement-propose-un-classement-des-cinq-les-plus-sollicites/

http://www.blog.webhostface.com/popular-php-frameworks-2015/

La librairie de template de Colin Williams : https://github.com/lezardrouge/williamsconcepts-template

Nouveautés de CodeIgniter 3

Après la sortie en mars de Code Igniter 3, mon framework préféré depuis 2009, j’avais promis ici de faire un compte-rendu plus en détail des nouveautés. N’ayant pas démarré de projet sous CI depuis, ça a un peu traîné mais ça y est.

L’inventaire ci-dessous n’a pas l’intention d’être exhaustif sur les points présentés, seulement sur les points qui m’ont semblé marquants.

Nommage

Le nommage a changé : désormais les classes doivent commencer par une majuscules, et les noms de fichiers aussi. Ainsi le controleur News s’appelle News.php, le modèle, News_model et son fichier News_model.php.

CI recommande d’écrire les méthodes et les variables en minuscules avec des underscopes comme séparateur, mais voilà une recommandation sur laquelle je vais m’asseoir.

Les sessions

Les sessions ont peu changé. Désormais les sessions sont lockées quand on accède aux données, deux requêtes HTTP ne peuvent plus accéder à la même session en même temps. D’après la doc, cela peut entraîner des problèmes de performance. Pour éviter cela, il suffit d’utiliser une nouvelle méthode : session_write_close()

Le reste n’a pas changé, on accède aux données de la même manière :

$this->session->userdata('item');

plus un getter :

$this->session->item

Pour ajouter ou modifier des données, $this->session->set_userdata($array); et $this->session->set_userdata('some_name', 'some_value'); sont toujours disponibles.

Les informations temporaires (flashdata) sont toujours disponibles et utilisées de la même manière qu’avant. Désormais il est possible de transformer une donnée existante en session en donnée flash avec mark_as_flash :

$this->session->mark_as_flash('item');

Cette méthode permettant également d’ajouter une donnée, fonctionnant comme l’ancienne :

$this->session->set_flashdata('item', 'value');

Une autre nouveauté se situe au niveau des Tempdata : il s’agit de noter une donnée de session avec une date d’expiration. Passé cette date d’expiration l’info est automatiquement supprimée.

$this->session->mark_as_temp('item', 300);
$this->session->set_tempdata('item', 'value', 300);

Et pour retrouver l’info :

$this->session->tempdata('item');

Le stockage des sessions utilise désormais 4 « drivers » : files, database, redis et memcached. Leur utilisation est détaillée dans la doc.

La structure de la table ci_sessions (si le « driver » database est utilisé) a changé : on « perd » le user-agent.

Plus d’infos sur les sessions :

http://www.codeigniter.com/user_guide/libraries/sessions.html

Utilisation de la base de données

Le Query Grouping

Si la syntaxe n’a pas changé, il y a maintenant le Query Grouping, qui permet de faire des sous-requêtes ou de grouper des clauses.

Très utile pour faire des OR WHERE par exemple. Là où avant, on devait utiliser du SQL :

$this->db->where('champ1 = 0 OR (champ2 = 'titi' AND champ3 = 'toto')') ;

On a :

$this->db->where('champ1', '0')
->or_group_start()
->where('champ2', 'titi')
->where('champ3', 'toto')
->group_end() ;

Plus d’infos sur le Query Grouping :

http://www.codeigniter.com/user_guide/database/query_builder.html#query-grouping

Le Query Caching

Je ne me souviens pas si le Query Caching existait sur les versions précédentes, en tout cas je ne l’utilisais pas. Ayant décidé de rendre mon code portable et donc de laisser tomber la précieuse instruction SQL_CALC_FOUND_ROWS, je me suis tournée vers le Query Caching :

$this->db->start_cache();
$this->db->select()
->from('news')
->where('display', '1')
->order_by('orderby asc');
$this->db->stop_cache();
$this->db->get();
$total = $this->db->count_all_results(); // compte l'ensemble des entrées
$this->db->limit($num, $from); // on ajoute le limit pour la pagination
$query = $this->db->get(); // et l'on ne récupère que les entrées que l'on souhaite

Plus d’infos sur le Query Caching :

http://www.codeigniter.com/user_guide/database/query_builder.html?highlight=count_all_results#query-builder-caching

Voilà déjà un début, la suite arrivera dès que j’aurai balayé le reste.

 

Sortie de CodeIgniter 3

CodeIgniter est un framework PHP, celui que j’utilise depuis 2007. À l’époque de mon choix, il me semblait être abouti, la communauté était active et il semblait très facile à apprendre, ce qui était mon critère prioritaire (la courbe d’apprentissage a effectivement été courte).

Les années passant, il a été (largement) détrôné par Symfony, des plus petits ont commencé à se faire connaître (Laravel, YII), les équivalents de son époque (comme CakePHP) ont stagné, comme lui. Je lui suis toujours restée fidèle, pour des raisons pragmatiques : en démarrage de projet, je n’ai pas le temps d’apprendre un nouveau framework, surtout avec une courbe d’apprentissage complexe comme pour Symfony ; ou des raisons plus pratiques : passer de CI à un autre framework pas beaucoup plus développé (en terme de fonctionnalités ou de communauté) n’avait pas de sens.

Il a toujours évolué, surtout avec des corrections de bugs, rarement avec des fonctionnalités épatantes. De-ci, de-là, quelques nouveautés que je n’ai jamais utilisées, comme la classe Cart. En revanche au fil du temps j’ai utilisé de plus en plus de choses qu’il offrait, comme le routing, l’active record ; j’ai créé mes propres helpers, des librairies standards, j’ai étendu des classes, bref, je l’ai aménagé comme on aménage un bureau, et aujourd’hui il est confortable à utiliser. Bien sûr, il n’est pas parfait, loin de là. Mes principaux griefs portent sur la gestion des formulaires (j’avoue que je suis envieuse de celle de Symfony) et le scaffolding, qui a été abandonné avant que je commence à l’utiliser : quand j’ai commencé à manipuler YII, je me suis rendue compte du temps que je perdais à créer un CRUD et le MVC associé à une table, ça m’a rendue dingue.

Mais dans l’ensemble ça reste un bon framework. L’année dernière son éditeur a cherché à le vendre. J’ai commencé à regarder ailleurs (d’où mon immersion dans YII).

Et puis j’ai vu passer quelques nouvelles sur une version 3, je me suis dit (ma paresse m’a dit) qu’on pouvait bien attendre un peu.

Et la version 3 vient de sortir !

Bon, ça ne casse pas des briques, mais déjà, il y a une volonté d’améliorer le code du Core : on passe sur PHP5.4 et la convention de nommage a été revue.

La licence a également été revue : l’ancienne licence était un peu batarde, en fait ça ne ressemblait à rien, une espèce de FLOSS. Là c’est clair, c’est du MIT.

Les drivers DB ont été revus, les tests unitaires améliorés, de nouvelles librairies Session et Encryption viennent prendre le relais des anciennes, pas terribles.

L’ensemble du changelog est disponible ici : http://www.codeigniter.com/userguide3/changelog.html

Tout ça me motive à continuer à l’utiliser, je vais prendre le temps de le tester (surtout la nouvelle classe Session) avant de mettre à jour les projets existants. Je posterai mes impressions dès que j’en aurai fait le tour.

 

Les sessions dans Code Igniter

Je suis en train de développer une application SaaS avec le framework Code Igniter, et je rencontre pas mal de problème avec les sessions des utilisateurs.

Déconnexions intempestives, affichage du nom d’un autre utilisateur au sein de la même entreprise… J’ai changé de librairie pour Session Hybrid, qui remporte pas mal de suffrages, mais je continuais à avoir des déconnexions sauvages dans une entreprise où deux personnes utilisent l’outil.

Après avoir tout tenté, tout testé, j’ai eu un flash. Serait-il possible, même si improbable, que leur adresse IP change ? du coup, la vérification avec l’adresse IP (j’avais déjà viré la vérification avec le User Agent) serait la cause de ce désagrément.

Eh bien oui, il arrive que dans certaines entreprises, l’adresse IP d’un poste change en cours de route, sans déconnexion de routeur, de cable, et dieu sait quoi.

Bref, du coup je déconseille l’utilisation de la vérification par IP, et je déconseille également de la vérification par User Agent. Y’a plus qu’à espérer que les identifiants de sessions sont suffisamment aléatoires pour éviter un bon vieux mélange de compte comme décrit ici [lien HS]

Have fun !

[Edit 05/09/2016 : le lien vers le forum de CI est HS car la structure du site a changé. Je n’ai pas retrouvé le thread]