“Ce qui est sûr, c’est que si vous êtiez vraiment un gros barge avec des tas de problèmes psychologiques et sociologiques soutenus par une agressivité et une angoisse profonde, vous réfugiant dans le mensonge lorsque vous êtes confrontés à une nécésssité de vous adapter, alors vous seriez blogueur… Bah ouaip :-) (je pars d’un constat personnel réalisé scientifiquement bien sûr)” — Korben
“I wanted to use “Ruby Manager” instead of “Ruby Version Manager” however the CLI use would have scared people :)” — wayneeseguin
“emacsは\C-で左小指がつりそうだけど、vimは:で右手小指の感覚が無くなってくる” — yugui
Un monde idéal où on sait s’amuser
Je viens de perdre pas mal de documents, pour une manip bête…
J’ai voulu virer toutes les images présente dans mes dossiers, donc :
find . -type f | grep ‘*.jpg’ | xargs rm
Ça marche pas, les espaces plantent
find . -type f -print0 | grep ‘*.jpg’ | xargs -0 rm
Ça marche pas non plus…. et c’est ce compliquer la vie pour rien…
Ok on change de méthode :
find . -type f -exec rm {} \;
Voilà ça marche !
Hey mais….
Merde !!!
Et oui, j’ai réécris vite, et j’ai oublié le test sur le nom… la commande aurait du être :
find . -type f -name ‘*.jpg’ -exec rm {} \;
Mais bon… trop tard… j’ai perdu tous les fichiers présents…
Donc nouvelles résolutions, pour ne plus avoir ça
Ce dernier point est beaucoup plus complexe.
En effet l’idéal serait de faire comme quand on met un fichier à la corbeille : on le déplace mais il reste sur la même partition.
Donc un simple mv ne suffit pas…
Heureusement :
sudo apt-get install trash-cli
alias rm=”trash”
À partir de maintenant quand je tape rm, ça envoie le fichier à la corbeille !
Ce n’est pas ça qui va me rendre mes fichiers, mais j’ai beaucoup moins de chance d’en reperdre de la même mainère…
ps: on pourait croire que je n’ai perdu aucun fichier et que cette histoire ne sert que de pretexte à la présentation de trash-cli, mais non, j’ai réellement perdu plusieurs Go de données à cause de la commande stupide présentée plus haut….
We are defending against a denial-of-service attack, and will update status again shortly.
Update: the site is back up, but we are continuing to defend against and recover from this attack.
Update (9:46a): As we recover, users will experience some longer load times and slowness. This includes timeouts to API clients. We’re working to get back to 100% as quickly as we can.
Update (4:14p): Site latency has continued to improve, however some web requests continue to fail. This means that some people may be unable to post or follow from the website.
On en sait enfin un peu plus sur l’attaque contre Twitter, Facebook et LiveJournal qui a eu lieu hier. L’objectif de cette attaque était si l’on en croit Max Kelly, le chef de la sécurité chez Facebook, de faire taire un blogueur Georgien répondant au doux pseudo de Cyxymu. Ce dernier utilise LiveJournal, Facebook, Youtube et Twitter pour raconter ce qui se passe en Georgie.
J’avais 2 gros problèmes, je viens d’en régler un : mes objets se désenregistraient du serveur JMX lors de leur sérialization pour se réenregistrer durant leur désérialization.
C’est pratique quand on veut faire migrer l’object d’une JVM à l’autre.
Le soucis c’est que j’utilise la tolérance aux pannes, qui sérialize de temps en temps les objets et les stocke dans un coin. Donc ils se désenregistraient du serveur JMX, mais ne s’y réenregistraient jamais.
Un bonne chose de réglée.
Bon, voilà LE truc qui m’ennuie en Ruby.
Ce n’est pas un gros problème, juste un non-raccourci qui pourrait être génial !
Un programme ruby est lu par l’interpréteur (et le plus souvent « compilé »).
Donc à partir de là on a accès à plein d’informations, mais pas au code des méthodes.
À quoi ça servirait ?
Je vois 2 choses :
Donc question : pourquoi les classes/méthodes/blocs ne sont-elles pas encore sérialisable ?
La réponse que j’imagine est que les Proc ne le sont pas, que les méthodes sont des formes de Proc et que les classes sont des Proc.
Donc pourquoi les Proc ne sont-elle pas sérialisables ?
Là je ne sais pas :/
En réfléchissant, on voit que les Proc sont des fermetures, donc qu’ils peuvent modifier des variables d’autres environnements.
Exemples:
def toto
var1 = 2
Proc.new { var1 += 1 }
end
ma_proc = toto # => toto est un générateur
ma_proc.call # => 3
ma_proc.call # => 4
On voit qu’il y a un problème ici : ma_proc est liée à la méthode toto.
On ne peut pas pas la sérialiser, car lors de la désérialisation, l’appel à var1 n’aura plus aucun sens.
La méthode employée par DRb pour le passage de bloc est de n’envoyer qu’un stub. Réponse logique : on ne peut pas envoyer l’objet, alors on le laisse sur place et les appels à ce bloc traverseront le réseau.
Moi j’aimerais ajouter quelque chose : un méthode de la classe Proc qui permet de savoir si un environnement autre est utilisé.
À partir de là c’est simple :
Ainsi on peut faire remote_enum.find {|el| … } sans que chaque exécution de notre bloc traverse le réseau.
Voilà, j’espère avoir été assez clair.
Cependant, peut-être qu’il existe déjà un moyen de résoudre ce problème et que je ne l’ai pas vu.
Des suggestions ?