Cacher des fichiers sur un matériel Android – Les Infos de Ballajack

#17836

En réalité, les dossiers dont le nom commence par un point sont des dossiers cachés. Le point en début de nom de fichier (ou dossier) le marque comme caché.

Android hérite cette fonctionnalité de Linux, sur lequel il est construit.

Pour aller plus loin, deux astuces :

— si vous avez un dossier de fichiers audio que vous ne souhaitez pas voir apparaître dans votre bibliothèque (par exemple des fichiers audio de sonneries, des enregistrements, ou autre…), placez un simple fichier « .nomedia » dans ce dossier.
Le fichier peut être vide : c’est juste le nom qui est important (notez qu’il débute, là encore, par un point).

– Sous Linux (et je pense aussi sous Android) : si vous avez un dossier que vous souhaitez cacher ou masquer, mais que vous ne pouvez pas renommer (pour quelconque raison), il suffit de créer un fichier « .hidden » à la racine du dossier parent, et dans lequel on va mettre le nom de fichier ou dossier que l’on veut cacher (un nom par ligne)

Par exemple, sur mes disques durs qui sont encore en NTFS, je mets bien souvent :

lost+found
System Volume Information

Dans un fichier .hidden à la racine du disque.

Le fichier « .hidden » débute par un point, donc il est lui-même caché.

Les deux dossiers, alors cachés, sont toujours là et sont toujours accessibles (si on dispose du chemin d’accès) et Windows les détectera toujours (si c’est un disque Windows).

http://www.ballajack.com/cacher-fichiers-android

Note : petite astuce pour les paranos…

#17802

… comme moi.

Si vous avez l’habitude de déchirer les enveloppes en 234058 morceaux avant de les jeter à la poubelle, histoire de bien rendre l’adresse invisible, etc., voici une autre méthode, plus pratique pour les colis.

La plupart des étiquettes autocollantes avec les adresses et les codes barres sont sensibles à la chaleur : passez simplement un coup de briquet dessus (sans y mettre le feu) et le papier devient tout noir, effaçant l’adresse.

Les tickets de caisse ont également cette propriété (c’est pour ça qu’il faut toujours faire des copies des tickets de caisse qui servent de preuve d’achat ; sans compter que la lumière du soleil efface très rapidement le texte imprimé).

ÉDIT : AKD me signale que le scotch (ruban adhésif) affecte également l’encre des tickets de caisse et l’efface.

https://lehollandaisvolant.net/?mode=links&id=20180926135752

Note : optimiser les boucles en programmation

#17705

J’ai décidé d’implémenter ça : https://sciencetonnante.wordpress.com/2015/11/06/la-machine-a-inventer-des-mots-version-ikea/ en javascript (pour un faire un petit générateur de mots dans une page web).

Y a une chose sur laquelle je reviens, et c’est pas la première fois, et ça semble trivial, mais ça change tout.

Dans ce script, en gros, j’ai 80 000 mots et je chercher les occurrences de triplets de lettres là-dedans. Donc en fait, j’ai 3 boucles imbriquées (de A à Z) sur chacun des 80 000 mots.

Question tout con : quel est le plus rapide,
– boucler sur les mots, puis sur les lettres ?
Comme ça :

for (w in words) {
    for (i in alphabet) {
        for (j in alphabet) {
            for (k in alphabet) {
                check(ijk, w)
            }
        }
    }
}

– boucler sur les lettres puis les mots ?
Comme ceci :

for (i in alphabet) {
    for (j in alphabet) {
        for (k in alphabet) {
            for (w in words) {
                check(ijk, w)
            }
        }
    }
}

Mathématiquement, dans les deux cas, on fait 80 000 × 26³ = 1,4 milliards de boucles.

Pourtant, avec une toute petite astuce, on peut rendre le premier code beaucoup plus rapide.
L’idée est qu’il y a 26 lettres dans l’alphabet. Mais les mots font rarement 26 lettres, et quand ils le font, c’est rarement avec toutes les lettres.

On va donc, à chaque boucle, commencer par vérifier si la lettre sur laquelle on est est contenue dans le mot.
Si il n’y est pas, c’est inutile de faire les deux autre boucles internes : la suite contenant la première lettre n’y sera pas non plus. Dans ce cas, on économise 26² boucles pour ce mot :

for (w in words) {
    for (i in alphabet) {
        if (check(i, w)) {
            for (j in alphabet) {
                if (check(ij, w)) {
                    for (k in alphabet) {
                        check(ijk, w)
                    }
                }
            }
        }
    }
}

Sachant que les mots font autour de ~8 lettres, ça représente (26-8)×26² = 12 168 boucles par mot !

Du coup, au lieu de 1,4 milliards de boucles, on réduit ça directement à 432 millions.
Ensuite, on économise encore sur le test de la chaîne "ij" (si la seconde lettre "j" ne se trouve pas dans le mot, alors on économise 26 boucles par mot : on passe en dessous des 400 millions.

La différence est grande : on a divisé le temps par 3~4 juste avec ça.
Et ça c’est juste une estimation grossière : en français, les mots — surtout les longs — ont plutôt des lettres en doubles que seulement des lettres différentes.

En pratique, je passe d’un temps d’éxécution de ~2 minutes à seulement 3 secondes… J’ai divisé le temps par 40.

Tout ceci est tout bête, tout con, mais pensez-y : parfois une ligne de code en plus, un simple "if" juste avant une fonction lourde peut tout changer.
Ok, fait un test « if » c’est une condition en plus et donc un calcul en plus. Mais si ça permet d’économiser sur une fonction qui prend 40 fois plus de temps… Alors ça en vaut la même. En l’occurrence, si ma fonction prend vraiment 40 fois plus de temps qu’un "if", alors je serait gagnant dès qu’on mot fait moins de 25 lettres différentes, ce qui est toujours le cas en français.

%%

Autre exemple dans mon code : pour faire le teste de présence d’un triple de lettres consécutifs dans un mot, j’utilisais les regex. C’est lourd et lent.
À la place, j’ai opté pour une fonction avec un simple "str.indexOf()", qui regarde si une souschaîne est contenue dans une chaîne. C’est bien plus rapide qu’un regex. Là, le temps a été divisé par un facteur 100 environ.

Sur une page normale, j’imagine qu’on n’aurait gagné que des micro-secondes. Mais quand on boucle 26³ fois sur chacun de 80 000 mots, le gain de temps est monstre.

cursor - CSS : Feuilles de style en cascade | MDN

#17671

Un truc tout bête qui aide beaucoup dans l’UI et l’UX : les curseurs en CSS.

Plutôt que d’ajouter un spinner en JS ou un GIF qui prend lui-même pas mal de ressources, pour dire « attendez ça charge », mettez plutôt un "cursor: progress" sur la page.

Plutôt que mettre un popup « déplacez le curseur de gauche à droite », ajoutez un simple "cursor: col-resize" ou "cursor: ew-resize".

https://developer.mozilla.org/fr/docs/Web/CSS/cursor