Songbird 1.10 est sortie

Synchronisation bidirectionnelle au menu, on peut choisir le sens de la synchro et le contenu : un titre une playlist ou tout

La refonte de la structure de la bibliothèque a permis une amélioration des performances et ça c’est tout bon moins lourd, moins lent

Bonne musique avec Songbird

concernant fabric, quand tu parles d’habitudes, tu parles de la syntaxe , de python, ou de son utilisation dans un autre environnement que les vôtres (lol bis) ?
En effet, l’un des aspects non abordés dans cet article concerne justement les mise a jours de base. Actuellement, notre équipe génère des sql que l’on doit jouer, quand bon nous semble, en local, en preprod, ou prod. Mais rien n’est exclu concernant la possibilité de les jouer un a un une fois le déploiement terminé. Nous ne nous sommes pas encore penchés sérieusement sur la question pour des raisons de temps, et parce que les habitudes ont parfois la vie dure.

Content en tout cas que cet article t’aie donné envie d’aller encore plus loin que ce que l’excellent Symfony offre déjà.

A bientôt ma petite

Pour notre part (lol), nous utilisons la fonction de déploiement intégrée à symfony qui fait un simple rsync du svn (trunk, branch, tag, peu importe) et le déploie sur l’environnement voulu :
(à la racine de symfony)
./symfony project:deploy appname environment –go
L’argument go permet de lancer le déploiement, sans cela, c’est une « répétition » du déploiement.

Cela a quelques contraintes bien sûr :
- la compression des assets doit être faites en amont sur la pre-prod
- les scripts sql à jouer se font directement en prod via des migrations doctrine (déjà répétées en pre-prod) mais lancées à la main, ce qui peut induire des erreurs humaines

Cet article m’a donné envie d’automatiser tout cela.
Mais je pencherai peut-être plus pour fabric (l’habitude).

Merci beaucoup madame.

- Pour le CSS, j’utilise SASS qui est un pré-processeur CSS qui peut, entre autres choses, minifier le code à la volée. Il permet également de travailler sur plusieurs fichiers mais de n’avoir qu’un seul fichier CSS en sortie (à la manière d’un @import mais pas via le browser) http://sass-lang.com/ et http://compass-style.org/

- JS : Pour les petits projets un cat fichier1.js fichier2.js | uglifyjs -o build.js suffit amplement.

- JS : Pour les plus gros projets, j’utilise RequireJS pour la gestion de dépendances, il est livré avec un outil de déploiement qui concatène toutes les dépendances et utilise UglifyJS au besoin pour minifier. http://requirejs.org/

Pour ma part j’utilise actuellement JSMin et CSSTidy (tous les deux ayant une version PHP) pour automatiser la minification/concaténation de mes fichiers.
Je n’ai pas benchmarké JSMin, et je pense qu’il compresse bien moins bien qu’Uglify. Pour CSSTidy, les résultats par contre sont assez bons. Il a quelques soucis parfois avec certaines syntaxes spéciales, mais rien qui ne puisse pas se patcher directement dans le code.

Cela va dépendre de multilples contraintes :
- tâches courantes/quotidiennes pour assurer un maintient d’une application en production
- contraintes business
- la volonté de l’équipe à se soumettre à la méthode

Mais je pense que l’on peut quand même structurer sa manière de travailler. Ce que propose le monsieur qui prenait ses pieds en photos est une bonne approche je pense.

Mais dans l’utilisation de toute méthode il y aura du temps de gestion consacrer au bon déroulement de la méthode.
Je pense aussi que l’utilisation de certains outils peuvent aider à structurer : redmine, pivotaltracker, thescrum (là on es clairement dans la méthode).

Sur ce, aurevouaîre !

Des société existent pour accompagner la mise en place de tels méthodos. Dis à ton boss que ça pourrait être opportun de faire un consulting. La seule que j’connaisse : http://www.efidev.com/ (les mecs sur la photo sont les vrais gars ).

Voilà bon courage à vous !

Il faut identifier clairement les problèmes actuels, dont tu parles :

- Régressions de l’application
- Respect des délais
- Manque de communication

Et trouver une solution à chacun :

- Régressions de l’application = prévoir l’écriture de tests fonctionnels pour renforcer la stabilité + intégration continue pour s’assurer *automatiquement* que le projet est OK
- Respect des délais = Faire des lots suffisamment petits pour être mesurables en heures (5 heures, 10 heures, 15 maximum) + Tracking précis du temps de chacun sur chaque tâche
- Manque de communication = Mettre en place un process simple : fonctionnement par tâche, la tâche n’est pas « commencée » tant que le développeur n’a pas certifié avoir toutes les infos + ne pas rester bloqué sur une inconnu/incertitude : dans ce cas, suspendre la tâche, demander les infos.

Je pense qu’il est possible de faire une transition douce vers Scrum. Tu peux le faire par étape :

0. Definition of Done : dire qu’une tâche est « terminée » veut dire : réponse correcte à la demande + documentation + tests + ce qui est propre à ton projet –> A DÉFINIR AVEC TOUTE L’ÉQUIPE
1. Toute demande doit être splittée en tâches traitables (15h maximum, privilégier les 2h/3h) + vérification des requis avant de les commencer : avoir compris le besoin + avoir tous les élements pour y répondre.
2. Intégration continue
3. Désigner un scrum master, qui sera responsable de la mise en oeuvre global d’un process

Des sociétés

merci de me recontacter pour que nous nous présentions les projets.

@thomas merci pour la précision, je vais clarifier ce point dans l’article directement

jQuery n’en est pas une et peut être substitué