Oui je dis « les » filtre, mais je n’en ai essayé qu’un seul !
Vous pourrez lire un peu partout (y compris dans l’aide même de google !) que pour faire un filtre de recherche du genre :
mail envoyé par e@gmail.com ou mail envoyé par f@gmail.com ou mail envoyé par g@gmail.com
…il vous suffit de taper simplemement
from:e@gmail.com or from:f@gmail.com or from:g@yahoo.fr
Cela ne fonctionne pas… en tous les cas pour moi.
Mais j’ai trouvé la solution : faites des pipes !
Je vous parle pas du moyen classique de monter en grade dans le cinéma, mais du vrai « pipe », ALTGR et « 6 » de votre clavier.
Pour mettre plusieurs mails, c’est entre parenthèses, pas comme précisé dans la documentation de google :
Filtre « envoyé par e ou f ou g ou reçu de e ou f ou g »
C’est le genre de problème qui arrive très souvent lorsqu’on touche à une base de données, en ajoutant un champ.
Pourquoi ? Parce que par défaut, les champs crées sans paramètres ne doivent pas être vides.
Exemple concret : je veux rajouter pour un modèle, un champ « exemple » :
class Groupe(models.Model):
description = models.CharField(max_length=150)
exemple = models.CharField()
Je fais « makemigration / migrate » et là, horreur : « django.db.utils.IntegrityError: main_groupe__new.exemple may not be NULL »
La solution
Supprimer le dossier « migrations » de l’application concernée
Lancer un migrate --fake-initial qui va « simuler » un migrate, sans essayer de créer les tables
Lancer makemigration nomappli (!! c’est ici que si on oublie le nom de l’appli rien ne se passe !!)
Seconde astuce : supprimer le champ fautif
Lancer migrate : là il va supprimer de la base le champ fautif
Remettre le champ avec blank=True, default=None
Refaire makemigration puis migrate sans préciser le nom de l’appli, comme d’habitude.
Et votre nouveau code sera pris en compte : class Groupe(models.Model):
description = models.CharField(max_length=150)
exemple = models.CharField(max_length=150,
blank=True, default=None)
Oui je sais ça a l’air long, mais en pratique ça prend deux-trois minutes seulement !
Après avoir passé plusieurs heures sans aucune réponse satisfaisante, j’ai enfin trouvé la solution du redirect.
Varnish n’a pas la possibilité de faire un redirect « simplement », il faut normalement laisser cela au « backend », c’est à dire au serveur derrière (Apache ou autre).
Mais moi je ne voulais pas. C’est mon droit non ?
Voici comment faire un redirect qui fonctionne :
sub vcl_recv {
# Rediriger tous les ".fr" vers ".com"
if (
(req.http.host ~ "(.*)monsite\.fr$")
) {
# ! error = envoyer vers la sous-routine "vcl_error"
set req.http.x-redir = "http://www.bb.com" + req.url;
return(synth(850, "Moved permanently"));
}
}
L’astuce principale était : utiliser vcl_synth
D’après le code, je vous résume ce que j’ai compris : si jamais on a un status 850 qui semble être un ordre particulier, alors automatiquement changer les headers en y appliquant la redirection, et les renvoyer directement le résultat.
Donc, après la routine vcl_recv il vous suffit d’ajouter vcl_synth comme ceci :
sub vcl_synth {
if (resp.status == 850) {
set resp.http.Location = req.http.x-redir;
set resp.status = 302;
return (deliver);
}
}
Voici un mémo de mon expérience très rapide de github, qui n’est destiné à l’origine qu’à moi, mais que je partage pour ceux qui voudraient aller vite :
Forker un repo : c’est à dire, faire « sa » propre branche d’un source pour pouvoir travailler dessus. Sur github : en haut à droite du « repo » principal, vous avec le menu « fork ». Cliquez dessus et c’est fini !
Details »» ici ««
Copier en local
De l’étape précédente, vous aurez une adresse genre https://github.com/VOTRE-USERNAME/repo-qui-vous-plait
Faites : git clone https://github.com/VOTRE-USERNAME/repo-qui-vous-plait
et git fera un copier coller en local des sources github
Ajouter le repo d’origine pour les futures synchronisations :
Copier coller l’URL du repo d’origine qui est sur github : git remote add upstream https://github.com/repo-qui-vous-plait
Assurez-vous que tout est ok :
Avec ce code : git remote -v
Vous devriez avoir : origin https://github.com/VOTRE-USERNAME/repo-qui-vous-plait.git (fetch)
origin https://github.com/VOTRE-USERNAME/repo-qui-vous-plait.git (push)
upstream https://github.com/POSSESSEUR-DU-REPO/repo-qui-vous-plait.git (fetch)
upstream https://github.com/POSSESSEUR-DU-REPO/repo-qui-vous-plait.git (push)
Ensuite ces étapes en boucle :
Repo origine distant vers local :
Ce qui a été fait par les autres sur le repo général (s’il y en a) vers local. git fetch upstream
Repo perso distant vers local :
Ce qui a été fait par les autres sur votre repo (s’il y en a) vers local. git checkout master
puis git merge upstream/master
Details »» ici ««
Noter vos modifications en local :
Préciser à git de chercher (1) toutes vos modifications, option « a » (2) le commentaire, option « m ». git commit -am "Mon commentaire"
Appliquer vos modifications à distance : git push
Details pas de github, mais en français et très bien faits :
»» ici ««
J’ai eu une discussion avec des fans de Symfony il y a quelques temps. Ils me soutenaient (avec une prétention qui m’a surpris) que Php était de très loin le langage le plus recherché actuellement. Ils se trompaient lourdement. Dire que Php est le langage le plus utilisé, oui. Dire qu’il est le plus demandé, et qu’il le restera, non.
Python est l’avenir
Aucune discussion possible.
Python c’est tout. End of story
Voici le mail que j’ai envoyé récemment à plusieurs de mes clients, et, qui explique la tendance python :
En tapant « most popular development languages » sur google, on voit que :
Enfin je l’ai appris ce matin de la part d’un professeur : deux universités de France retirent Php pour le remplacer par Python cette année (si vous êtes intéressé je vous dirais lesquelles, je n’ai plus en tête les villes de ces universités).
J’imagine les gens de mauvaise foi qui vont aller chercher sur le Web et sortir les deux ou trois sites qui mettent Php devant Python… oui vous allez en trouver, mais en proportion, la plupart des sites expliquent que la tendance d’aujourd’hui c’est Python et JavaScript. Quant à ce dernier, moi qui ai fait quelques sites en NodeJS, je confirme que c’est l’âge de pierre aussi bien côté serveur Web que côté langage JavaScript lui-même… peut être qu’enfin à sa version 6, il fera du scoping normal (lisez ici) déjà rien que ça c’est moisi, sans parler des principes des closures qui empêchent carrément de faire de grosses applications qu’on peut facilement maintenir… là aussi, je ne pourrai jamais convaincre des gens qui ont principalement fait du JavaScript sans avoir essayé aussi intensivement d’autres langages (on ne peut pas comparer dans ce cadre, et toute discussion devient alors impossible)…
Si, comme moi, vous voulez faire des requêtes directement et voir toutes les tables, pour les modifier manuellement, rien de plus simple, il faut juste chercher sur le Web pendant pas mal de temps. Voici la solution pour économiser de précieuses minutes :
Lancer la console python (Tools » Python console)
Taper :
from django.db import connection
cursor = connection.cursor()
cursor.execute("PRAGMA table_info(langue)")
for c in cursor.fetchall():
print(c)
Si vous voulez plus de détail, et que la console a des problèmes avec les accents, voici un code qui remplace les accents par un point d’interrogation :
Taper :
from django.db import connection
cursor = connection.cursor()
cursor.execute("SELECT * FROM langue")
for c in cursor.fetchall():
for d in c:
if type(d) is str:
print(d.encode(
sys.stdout.encoding,
errors='replace'))
else:
print(d)
Et vous obtiendrez un résultat qui pourrait ressembler à : None
b'Russian'
b'ru'
False
b'???????'
False
Dans Facebook il faudra aller dans le coin des développeurs, et créer une application jusqu’à arriver à un écran comme celui-ci :
Même chose pour gmail :
Et enfin la relation dans le code :
Pour terminer : Facebook ne renvoyait pas les emails, lorsqu’on s’authentifiait.
C’est un bogue connu depuis que Facebook a modifié son API très récemment.
La solution est ici : editez votre fichier \authomatic\providers\oauth2.py.
Allez à la classe Facebook.
Copiez-collez ce code, qui ne change presque rien (je vous laisse chercher) sauf l’URL user_info_url qui a été modifiée pour la v2.4 : et voilà, il ne vous reste plus qu’à suivre le tutoriel de authomatic avec Django, qui est assez bien fait, et tout devrait fonctionner !
class Facebook(OAuth2):
"""
Facebook |oauth2| provider.
* Dashboard: https://developers.facebook.com/apps
* Docs: http://developers.facebook.com/docs/howtos/login/server-side-login/
* API reference: http://developers.facebook.com/docs/reference/api/
* API explorer: http://developers.facebook.com/tools/explorer
Supported :class:`.User` properties:
* city
* country
* email
* first_name
* gender
* id
* last_name
* link
* locale
* location
* name
* picture
* timezone
* username
Unsupported :class:`.User` properties:
* birth_date
* nickname
* phone
* postal_code
"""
user_authorization_url = 'https://www.facebook.com/dialog/oauth'
access_token_url = 'https://graph.facebook.com/oauth/access_token'
# Correction merci à miohtama :
# https://github.com/peterhudec/authomatic/issues/112
user_info_url = 'https://graph.facebook.com/me?fields=' \
'id,email,name,first_name,last_name,address,gender,' \
'hometown,link,timezone,verified,website,locale,languages'
user_info_scope = ['email', 'user_about_me', 'user_birthday',
'user_location']
