Catégorie : développement – divers

cygwin : problème des espaces avec updatedb : la solution via mount

J’ai eu l’information ici : http://cygwin.com/cygwin-ug-net/using-utils.html#mount

Faire un mount permanent :
Editer le fichier /etc/fstab

Y ajouter le lien vers le répertoire qui a des espaces :
"C:/mon projet/mon sous projet" /monprojetmonsousprojet ntfs binary,posix=0,user,noumount,auto

Lancer un nouveau shell pour que le "mount" soit fait automatiquement

RaspberryPi : comment changer la vitesse du clavier

Comment changer la vitesse du clavier, et cela pour toujours (c’est à dire même après un reboot, ça fonctionne toujours) :

Pour rendre la configuration clavier permanente sur le terminal, éditer /etc/kbd/config et y mettre cette vitesse (enfin, c’est ma vitesse de clavier) :

xset r rate 170 120

Pour que cela fonctionne aussi partout et pas que dans les terminaux, editez ce fichier /etc/xdg/lxsession/LXDE/autostart et ajoutez y le même code :

xset r rate 170 120

Merci pour le lien ici.

google code prettify – prettyprint : les codes possibles

Pour rappel rapide, l’utilisation est extrêmement simple : un simple include JavaScript de google code prettifier (je vous laisse le chercher et le faire), puis l’utilisation : au lieu d’écrire de simples balises <code></code> ou <pre></pre>, ajoutez-y la classe prettyprint comme ceci :
<code class="prettyprint">Mon code</code>

Et vous passerez d’un code tel que :
alert("Bonjour");
…à :
alert("Bonjour");

Mais le seul hic c’est que le JavaScript de google « essaie » de deviner ce qu’il y a entre dans le code pour le mettre en couleur. Parfois il ne trouve pas et donc ne colore pas la syntaxe, ou pire, il se trompe (sur de très courts morceaux de code c’est normal). Il vous suffit de préciser de quel type de code il s’agit.

  • Exemple avec du JavaScript :
    <pre class="prettyprint lang-js">var t=12;</pre>
    Ce qui donnne 

    var t=12;
  • Exemple avec du Shell :
    <pre class="prettyprint lang-sh">echo "$MAVAR ok"</pre>
    Ce qui donnne 

    echo "$MAVAR ok"

Voici tous les codes qu’il est possible d’utiliser si jamais vous utilisez le google code prettifier

  • lang-c
  • lang-cc
  • lang-coffee
  • lang-cs
  • lang-css
  • lang-el
  • lang-erlang
  • lang-go
  • lang-hs
  • lang-html
  • lang-java
  • lang-js
  • lang-lua
  • lang-ml
  • lang-proto
  • lang-py
  • lang-scala
  • lang-sh
  • lang-sql
  • lang-vb
  • lang-vhdl
  • lang-wiki
  • lang-yaml

Une bonne interface utilisateur

Voici un site qui donne plein de bonnes idées pour faire une bonne interface utilisateur :

Try a one column layout instead of multicolumns:

Try a one column layout instead of multicolumns.

Try giving a gift instead of closing a sale right away:

Try giving a gift instead of closing a sale right away.

Try merging similar functions instead of fragmenting the ui:

Try merging similar functions instead of fragmenting the ui.

Try social proof instead of talking about yourself:

Try social proof instead of talking about yourself.

Try repeating your primary action instead of showing it just once:

Try repeating your primary action instead of showing it just once.

Try distinct styles between clickable and selected items instead of blurring them:

Try distinct styles between clickable and selected items instead of blurring them.

Try recommending instead of showing equal choices:

Try recommending instead of showing equal choices.

Try undos instead of prompting for confirmation:

Try undos instead of prompting for confirmation.

Try Telling who it’s for instead of targeting everyone:

Try Telling who it's for instead of targeting everyone.

Try being direct instead of indecisive:

Try being direct instead of indecisive.

Try more contrast instead of similarity:

Try more contrast instead of similarity.

Try showing where it’s made instead of being generic:

Try showing where it's made instead of being generic.

Try fewer form fields instead of asking for too many:

Try fewer form fields instead of asking for too many.

Try exposing options instead of hiding them:

Try exposing options instead of hiding them.

Try suggesting continuity instead of false bottoms:

Try suggesting continuity instead of false bottoms.

Try keeping focus instead of drowning with links:

Try keeping focus instead of drowning with links.

Try showing state instead of being state agnostic:

Try showing state instead of being state agnostic.

Try benefit buttons instead of just task based ones:

Try benefit buttons instead of just task based ones.

Try direct manipulation instead of contextless menus:

Try direct manipulation instead of contextless menus.

Try exposing fields instead of creating extra pages:

Try exposing fields instead of creating extra pages.

Try transitions instead of showing changes instantly:

Try transitions instead of showing changes instantly.

Try gradual engagement instead of a hasty sign up:

Try gradual engagement instead of a hasty sign up.

Try fewer borders instead of wasting attention:

Try fewer borders instead of wasting attention.

Try selling benefits instead of features:

Try selling benefits instead of features.

Try designing for zero data instead of just data heavy cases:

Try designing for zero data instead of just data heavy cases.

Try opt-out instead of opt-in:

Try opt-out instead of opt-in.

Try consistency instead of making people relearn:

Try consistency instead of making people relearn.

Try smart defaults instead of asking to do extra work:

Try smart defaults instead of asking to do extra work.

Try conventions instead of reinventing the wheel:

Try conventions instead of reinventing the wheel.

Try loss aversion instead of emphasizing gains:

Try loss aversion instead of emphasizing gains.

Try visual hierarchy instead of dullness:

Try visual hierarchy instead of dullness.

Try grouping related items instead of disordering:

Try grouping related items instead of disordering.

Try inline validation instead of delaying errors:

Try inline validation instead of delaying errors.

Try forgiving inputs instead of being strict with data:

Try forgiving inputs instead of being strict with data.

Try urgency instead of timelessness:

Try urgency instead of timelessness.

Try scarcity instead of abundance:

Try scarcity instead of abundance.

Try recognition instead of recall:

Try recognition instead of recall.

Try bigger click areas instead of tiny ones:

Try bigger click areas instead of tiny ones.

ExtJs autoLoad et store : howto / comment faire

Si vous ne connaissez pas ExtJs, c’est « à peine » du JavaScript, « à peine » utilisé par IBM, et plein d’autres « petites » entreprises 😉 .

Très puissant mais il manque parfois d’exemple.

En voici un pratique que j’ai eu du mal à mettre en place : pourtant c’est du classique de chez classique.

Je veux ouvrir un onglet qui charge automatiquement des informations de base de données : un onglet dans lequel il y a les informations d’un dossier : nom, prénom, date de naissance, etc.

Assez classique.

Mais disons… que je veux en faire le moins possible. Avec ExtJs, c’est très simple. Enfin simple… après avoir bien cherché !

En fait, l’astuce est qu’il faut appeler la fonction autoLoad, pour que le chargement soit automatique, et avant même d’afficher l’onglet.

Dans mon cas, je voulais afficher Homme ou Femme dans un combo. Donc il fallait avant même d’afficher l’onglet, qu’il précharge le truc dans un magasin de données = store.

WordPress et JavaScript : mettre du code en dur dans vos articles

Si jamais un jour, comme moi, vous essayez de mettre du code JavaScript directement à l’intérieur de votre article – ou de votre page – alors irez dans l’onglet à droite ainsi :

Wordpress edition d'un article - onglet texte.jpg

Et vous taperez sûrement quelques lignes basiques comme celles-ci :

<script>
alert('bonjour');
</script>

Cela ne fonctionnera pas !

J’ai posé la question ici, et la réponse était : le code généré dans la page n’est pas correct, il faut le corriger… ce qui est vrai ! La seule solution que j’aie trouvé : écrire un fichier JavaScript externe, et l’embarquer dans la page. Malheureusement, j’ai codé la chose en dur, et je cherche actuellement parmi ces possibilités :

  • Soit pouvoir écrire du code qui ne sera pas retravaillé dans les articles / et / ou / pages ;
  • Soit pouvoir inclure des fichiers uniquement en fonction des pages.

Ce que je n’ai pas fait. Mais ma solution fonctionne, même si elle n’est pas la meilleure.

Solution 1

Je suis allé dans mon thème, et j’ai fait un include « générique » dans et j’y ai rajouté l’inclusion de mon script :

wp_enqueue_script( 'olivierpons', get_template_directory_uri() . '/js/op.js' );

C’était ici :
Wordpress description de l'inclusion de javascript dans un theme

Et là, j’ai pu écrire mon script, entièrement en JavaScript, qui n’est pas modifié par WordPress.

Pour information, ce script crée un formulaire complet afin de générer une requête SQL pour créer une base de données SQL avec un utilisateur et un mot de passe afin de copier coller le code pour créer la totale. Cela est si souvent fait que ça m’a lassé un peu et j’ai écrit ce code.

Vous pouvez retrouver ce formulaire dans cet article et dans cette page.

Solution 2

Les shortcode. Vous écrivez une function Php qui renvoie une chaine qui ne sera pas modifiée. Donc cette chaine peut tout à fait être du code dans une balise Javascript : <script>alert('bonjour');</script>. Seul problème : elle doit être codée en dur.

J’ai essayé de le contourner pour rendre le code entièrement dynamique.
Essayez ce code dans le fichier functions.php de votre thème :

if (!function_exists( 'foobar_func' )):
function foobar_func( $atts, $content, $tag ){
  echo $atts['script'];
  return (isset($content) ? $content : '');
}
add_shortcode( 'foobar', 'foobar_func' );
endif;

Puis essayez d’appeler la fonction ainsi dans un article :

[f oobar script="<script>
  jQuery(document).ready(function() {
    var j=jQuery('<div />');
  });
</script>"]

Et vous verrez que malgré tout, les paramètres sont retravaillés par WordPress et malmenés !

Au final, deux solutions

  • Ecrire un fichier JS externe, et l’inclure soit de manière générique dans toutes les pages, soit de manière dynamique (à vous de le paramétrer) :
  • La seconde qui consiste à écrire un shortcode et que ce shortcode renvoie le code Javascript au complet, sachant que le gros inconvénient, c’est que le code que vous renverrez sera difficilement lisible : en effet, ce sera une chaine de caractères « simple » dans votre fichier Php, il n’y aura aucune coloration syntaxique.

Coding game : les résultats : olivier pons

Je suis content, je suis 92ème sur 1167 :

Coding Game résultat pour Olivier Pons 92ème sur 1167

Dans les faits, si on enlève ceux qui sont à 0% (on ne sait pas s’ils ont participé ou pas), je suis 92ème sur 871. Ce qui n’est pas trop mal.
Si j’avais réussi à résoudre le second challenge en entier, j’aurais été dans les 40 premiers…

Vous pouvez avoir accès à mes codes sources ainsi qu’aux résultats ici.

J’étais content pour le premier, réalisé assez rapidement (32 minutes) :
Coding Game 2013 11 22 analyse 1

Alors que pour le second, j’ai galéré comme un fou (sachant que je suis allé chercher une pizzas et que je l’ai mangé en famille pendant le concours) :

Coding Game 2013 11 22 analyse 2

Ce qu’il y a de marrant, c’est qu’en travaillant en local, je me suis ressorti le fichier décompressé au format texte et c’était amusant à voir :

Coding Game 2013 11 22 notes de musiques fichier décompressé au format texte

Développement : Coding contest !

Nouveau challenge de codeurs !

C’est pour le fun, essayez vous aussi 

Le principe est simple

Vous aurez deux puzzles de programmation à résoudre.

Pour ce faire, vous pourrez choisir votre langage favori parmi ceux-ci : Java, C, C++, C#, Javascript, PHP, Python, Ruby, Objective-C, Haskell and Go.
La durée moyenne d’un challenge est de 2 heures et 30 minutes.

J’y serai, le 23 novembre !

Inscrivez vous !
Si jamais plus de trois personnes se sont inscrites via le lien précédent, et ont dépassé un score de 0% (= y sont allées), j’aurais un t-shirt codingame 😉