Insérez ces alias dans votre .gitconfig :

[alias]
  ignore = update-index --assume-unchanged
  unignore = update-index --no-assume-unchanged

Maintenant, il suffit d’une commande git ignore monfichier.js et les modifications appliquées au fichier seront temporairement ignorées.

La commande git unignore monfichier.js le ramenera ( et conservera vos modifications effectuées pendant la période d’amnésie )

Via une astuce Git de PiouPioum & Stack Overflow

Après quelques recherches, voici la méthode (adaptable à tout snippet, évidemment)

Créer le snippet

Dans votre dossier Packages/User/ (Accessible depuis Preferences | Browse Packages…), créez un sous-dossier « Snippets ». Dans ce dossier, créez un fichier nommé wrapstrong.sublime-snippet.

Entrez le contenu suivant dans le fichier wrapstrong.sublime-snippet

<snippet>
    <!-- $SELECTION peut être appelé plusieurs fois -->
    <content><![CDATA[<strong>$SELECTION</strong>]]></content>
    <!-- Facultatif: Description affichée dans le menu -->
    <description>Wrap in strong</description>
</snippet>

Note :
Ce snippet n’a pas de portée (source.css, etc) car je l’utilise dans de nombreux types de fichiers. Je vous invite à lire la documentation sur les snippets [en] si vous souhaitez plus de détails.

Ajouter le raccourci clavier

Maintenant, éditez votre fichier de raccourcis claviers (Preferences | Key Bindings – User) en ajoutant le raccourci suivant au tableau :

{
    "keys": [
        "super+b"
    ],
    "command": "insert_snippet",
    "args": {
        "name": "Packages/User/Snippets/wrapstrong.sublime-snippet"
    }
}

Notes :

• La touche « Super » est l’autre nom de la touche « Pomme » ou « Cmd » sur Mac.
• Remplacez super+b par ctrl+b si vous êtes sous Win/Linux.

Redémarrer

Redémarrer votre éditeur permettra d’assurer que ce snippet a bien été enregistré. Maintenant, surlignez un mot dans votre éditeur, et utilisez le raccourci cmd+b (ou ctrl+b). Magique !

On ne le dira jamais assez, bien choisir un nom est une étape à ne pas sauter. En l’occurrence, j’avais pris un nom trop proche de l’excellent normalize.css, projet bien différent.

J’en ai profité également pour unifier un peu les noms de classes CSS, en les préfixant de manière plus logique : .cssc-*

Si vous aviez déjà cloné le projet, je vous invite à en refaire une copie :

git clone git://github.com/Darklg/CSSCommon.git

PS : J’essaie de faire le plus long streak possible sur Github, c’est tout sauf évident !

Le titre pourrait laisser penser que seuls SASS & Compass sont abordés, mais ce livre parle majoritairement d’organisation des CSS, ainsi que de bonnes pratiques pour produire des feuilles de styles maintenables, optimisées et réutilisables.

Il s’agit d’un sujet qui me tient à coeur, et c’est avec grand plaisir que j’ai lu ce livre qui aborde tous les pièges à éviter (et les bonnes pratiques à suivre) pour maintenir du CSS sur tout projet web. Ce livre est, selon moi, l’une des lectures indispensables pour tout intégrateur qui se respecte. Il contient une méthodologie solide de maintenance des CSS, ainsi qu’un tour d’horizon des outils améliorant la qualité de votre code.

Si vous n’êtes toujours pas convaincus, dites-vous que ce livre m’a même donné envie de passer à SASS. Et oui.

Sommaire

• De <font> à @font-face : une problématique nouvelle
• Première plongée dans CSS
• Bonnes pratiques pour un code CSS lisible et maintenable
• Pragmatisme : démystifier certaines bonnes pratiques
• Les frameworks CSS
• Travailler en équipe
• Préprocesseurs CSS : quand la machine écrit pour vous
• SASS et Compass
• Erreurs de conception : comment les débusquer
• Méthode : coder un design de zéro
• Méthode : faire le ménage dans les CSS

Je le veux !

CSS maintenables est disponible sur Amazon ainsi que sur le site d’Eyrolles.

Sur votre nouveau serveur

Cette commande vous permettra cloner en bare depuis olddomain, transformant une version « clonée » en version « serveur ».
Attention, il faut avoir l’autorisation de cloner (ssh, etc).

$ git clone --bare git@olddomain:~/projet.git

Sur votre poste de travail

Il suffit de spécifier une nouvelle origine à votre copie de travail.

$ git config remote.origin.url git@newdomain:~/projet.git

Il y a d’autres (meilleures) façons de faire, mais celle là m’a bien dépanné récemment.

• 24 Ways
  Le plus ancien du genre, avec des articles qui soulignent les tendances de l’année à venir.
• UXMas
  Axé sur les bonnes pratiques d’expérience utilisateur.
• HTML and CSS Advent
  Des astuces intéressantes sur des APIs HTML5 et autres.
• Performance Calendar
  à suivre absolument si vous êtes intéressé par la performance web.
• Christmas Experiments
  Des demos CSS bien fichues.
• Web Advent
  Un calendrier pour tous les développeurs web.
• 24 jours de web
  Un site auquel j’ai (un peu) contribué, dont je vous avais déjà parlé précédemment. Vous devriez déjà être en train de le parcourir

L’Abri gère un Atelier Chantier d’Insertion qui accompagne 42 personnes dans un parcours de reconstruction, de qualification et de retour à l’emploi à travers deux activités : l’entretien d’espaces verts et la peinture en bâtiment.

J’y ai participé en rédigeant l’article « Frameworks CSS, templates et thèmes de base. Comment bien démarrer vos projets web ? » dans lequel je parle de ma méthodologie concernant les « code starters ».

N’hésitez pas à y jeter un oeil, et à soutenir « L’Abri »

ça vous dépasse ? Voici une explication en vidéo (un peu lente, désolé).

(Désolé, c’est samedi / Image honteusement piquée chez Désencyclopédie. )

Inconvénients pour l’intégrateur :

• Des retours sur la DA sont fréquents.
• Les livraisons de code sont multiples, les retours arrivent non groupés.
• Pas d’estimation fiable de la durée du projet.
• Selon les aléas du planning, le projet peut être confié à une autre personne qui le continuera.
• Le projet dure plus longtemps, car des prévisions sur les comportements de blocks sont à faire en amont.
• Aucune idée de la portée et du niveau de réutilisation de code
  (Typiquement : Block « pas prévu pour cette taille » à refaire ou Block « prévu pour » mais non utilisé.)
• OOCSS ? « .objet-video {} ». non, mince « .objet-media {} ». non, mince. « .objet-media, .objet-video {} »

Avantages de cette solution :

• L’intégration est démarrée plus tôt.
• Le client voit que « le travail avance ».

L’enfer, quoi.

(Disclaimer : Aucun rapport avec mon employeur actuel, je relate une expérience vécue)

Pièces détachées à acheter chez IKEA :

• Face de tiroir Besta Vara 60x26cm (5€) (Attention, la 60×16 est vraiment trop fine pour la plupart des pieds d’écran). Forcément, une planche de bois moins cher, ou toute autre étagère restante, ça marche aussi bien.
• Pieds Capita 11cm (5€)

Outils :

• Une vrille, ou une perceuse à petit forêt.
• Un tournevis cruciforme ou une ♥ visseuse ♥.
• Un feutre.

Instructions :

• Mettez la planche face contre sol.
• Marquez les emplacements pour les trous au feutre (2 fixations aux coins opposés par pieds suffisent).
• Percez les trous à la vrille ou à la perceuse.
• Vissez les pieds.
• Retournez le support.
• Installez le sur votre bureau, enjoy :’)

Exemple avec une face de 16×60

Mise en situation avec la face de 26×60

Si cet article vous a plu, je vous invite à visiter l’excellent site anglophone IKEA Hackers !