Calms blog

CALMSブログ

他人の幸運に嫉妬するのはフェアじゃない

「なんであいつだけあんなに運が良いんだ!」

 あなたはそんな風に嫉妬した経験があるだろうか? 僕はある。きっと、あなたにもある。

 明らかに努力の差があれば悔しいながらも納得できたかもしれない。けれど、まったく同じ条件でもより恵まれた結果を得る人、得られない人が存在する。どうしようもない結果。ただただ与えられるだけの結果で差が出てくる。

 くじ引きの類は完全にそれで、学校での席替え、宝くじ、パチンコに麻雀に最近ではゲームでのガチャなんかは顕著だ。

「同じだけお金を払ったのにあいつはレアキャラが出た!」

「俺なんてあいつの10倍払っているのに出てこない!」

 そんな不幸を叫ぶ声が聞こえてくる。

 そう、不幸だ。

 恵まれなかったあなた。今その瞬間、恵まれなかったあなた。

 悔しい。心がもやもやグツグツ煮えたぎる。その瞬間のあなた。

 冷静になって欲しい。それはアンフェアだ。

 あなたが比較しているものはなんだろう。

 幸運に恵まれた人。あなたが欲しかった境遇を運良く手に入れた人だ。

 そう、幸運だ。

 そこを比較すべきじゃない。

 幸運な境遇と不幸な境遇を比較するのはフェアじゃない。

 そんなの幸運が勝つに決まっている。勝者と敗者が試合を始めるようなものだ。始める前から敗者なのに試合の後に「悔しい!」だなんて、よく考えればバカみたいじゃないか。

 相手の幸運と比較すべきは幸運で、あなたの不幸とぶつけるべきは相手の不幸だ。

「あいつは今あんなについてるけど、そういえば1か月前は私にも同じくらいの運がきていた」

「俺はこんなにひどい不運に見舞われてあいつは今高笑いしているけど、思い出してみればあいつも1年前はひどい目に遭っていたな……」

「相手のことよく知らないけど、こんなついてばかりの人生なわけないよな」

 結局そんなものだ。そして、こんな状況、また時間がたてばひっくり返る。あなたが幸運を目にしていた相手は、1週間後にはあなたの幸運に嫉妬しているかもしれない。

 他人の幸運に嫉妬するのはフェアじゃない。

 幸運には幸運で立ち向かおう。幸運の差で打ち負けた時は「やるじゃないか。でも次はわからないぞ」と捨て台詞でも吐いてやろう。

 そうだ。次はわからないぞ。

薬物中毒の原因は薬物の中にない

 まだ確定的な研究結果ではないようですが、面白い記事がありました。

gigazine.net

 この記事によると、これまでの実験などから薬物中毒になるのは薬物に含まれる成分よりも「ストレス」が直接的な原因だというのです。

 孤独なマウスはストレスを解消する手段として薬物中毒になりますが、他の仲間がいれば薬物中毒にならないのだとか。

 これが正しい推測かどうかはまだわかりませんが、「苦痛が続く限り、苦痛から逃れる手段に依存する」というのは人として自然な行動原理だと思います。

 僕としては一つ、最近気になっていたことがあります。なぜ、人はお酒に依存するのでしょうか?

calms.hatenablog.com

 上記のエントリーのように、人体に致命的な影響を与えるまでに酒に依存する人がいます。

 しかし、よく考えてみてください。たばこや麻薬はそれ自体に依存性のある物質(と呼ばれるもの)が含まれていますが、アルコールも同様のものでしたっけ。

 一般的に依存性のある物質は幸福感といったプラスの影響を与えますが、酒に酔うというのは、脳の働きを阻害されているマイナスの影響ではないでしょうか?

 ん? ううん?

 そんなことを考えていたのですが、今回の記事を読んで少し納得できました。

 思考の混濁によりストレス源を一時的にでも忘れ、それによりある種の逃避が出来ていると仮定すれば。それは「苦痛から逃れる手段に依存する」という事象に合致しています。

 そういう風に考えると、何かに依存するというのは、それ以外に苦痛から逃れる手段を持っていないということでしょうか・・・・・・

 もしかすると、依存症に苦しんでいる人を救うのに一番効果的な治療方法は、その人と友達になることかもしれませんね。

※実際は依存性のある物質を含んでいなくとも、ドーパミンの分泌による快感で依存症になるようです。なので、その人の嗜好によってはどんな行為でも依存してしまう可能性がありそうです。

 アルコール依存症については次の記事もわかりやすかったです。

business.nikkeibp.co.jp

※追記:冒頭のネズミの実験、再現実験に失敗したようで、研究結果としての信頼性はなくなりました。参考程度にしてください(だからストレスが完全に中毒に関係していないと言い切れるわけでもありませんが)。

Kotlinいいじゃん!

ことりん可愛いよことりん。

KotlinはJava互換のあるJVM言語で、ScalaやGroovyの親戚みたいなもの。それぞれからいいところ取りをしていてAndroid開発にまで対応しているとか。

Qiitaで下の記事に詳しくまとまっていました。

qiita.com

ほとんどのことは上の記事でわかるのでそちらを読んでいただきたい。Scala同様、Javaを書くよりは楽だし合理的だし楽しそう。

僕としては、Scalaは少し使ったきりめっきりやらなくなってしまったのだけど、理由の一つとしてRuntimeのサイズが重いのが気になっていた。(今時の悩みじゃないのかもしれないけど、僕はjarをやり取りすることが多いので軽ければ軽いほど嬉しい)

試しにKotlinのコンパイラで以下のようにランタイム込みでjarを作ってみた。

kotlinc example\Test.kt -include-runtime -d Test.jar

すると出来上がったファイルサイズは1.12MBと非常に軽量。もちろん java -jar でそのまま実行できる。これはいい。

kotlinc-jvmというREPLもあるし、上述の通りEclipseでも使える。(インポート編成が使えないけどJavaクラスもそのままインポートできる。QuickFixによるインポートは使える)

対応JREは7以上。これはScala以上に手軽なNextJavaとしていいと思う。

とりあえず、手近なものからKotlinはじめてみます。

※関数型へ移行していきたいと思っているけどScalaから折り返している自分・・・・・

議員の実力行使を正当化してはいけない

安保関係でいろいろ騒動が起こっていますが、いかなる理由であっても暴力を手段として使ってはいけません。

昔から牛歩戦術なんて進行の妨害はありましたが、バリケードを作る、相手議員に飛び掛って妨害する、というのは『実力行使』であり、暴力です。

『自らの意見が通らないとき実力を持って対処する』というテロリストのような方法を、国会議員が取ることを断じて許してはいけません。

そのような議員たちが政権を握った場合、外交の失敗をいかなる手段で取り戻そうとするか――それこそ戦争の火種になりかねないのです。

私は法案の中身よりも、議会で暴力を利用できたという前例を作ってしまうことのほうが問題だと感じます。

法案は極端な話、修正が可能です。しかし、国会議員が品位を失い、『時には実力行使も問わない』なんてことになると、『遵法意識のない裁判官』のようになりかねません。

端的な話、議会で腕力が通じる要素があってはいけないのです。力の強い人も、体の弱い人も、対等でなければ議会として機能しません。議員は、議論してください。

以前から何度か言っていますが、子供に見せても大丈夫な大人として振舞いましょう、本当に。

(書き出す前は憤りがあったのですが、書いているうちになんか悲しくなってきました……)

【小技】libフォルダのjarのクラスパスを自動的に追加

 Javaで開発していて動的にClassPathを追加したくなったのでメモ。

 日本語で検索するとリフレクションを使ったものばかり出てくるので、リフレクションを使わないで(普通に)libフォルダのjarファイルを登録するサンプルです。

public static void main(String[] args) {
    File libDirectory = new File("lib");
    
    File[] libs = libDirectory.listFiles(new FileFilter() {
        @Override
        public boolean accept(File f) {
            // jarファイルのみ
            return f.getName().endsWith(".jar");
        }
    });
    addClassPath(libs);
}

private static void addClassPath(File[] files) {
    
    if (files == null || files.length <= 0) return;
    
    ClassLoader classLoader = 
            Thread.currentThread().getContextClassLoader();
    // URLに変換
    URL[] urls = new URL[files.length];
    for (int i = 0; i < urls.length; i++) {
        try {
            urls[i] = files[i].toURI().toURL();
        } catch (MalformedURLException e) {
            // 適宜例外処理
            throw new IllegalArgumentException(e);
        }
    }
    URLClassLoader newClassLoader = 
            URLClassLoader.newInstance(urls, classLoader);
    Thread.currentThread().setContextClassLoader(newClassLoader);
}

参考は下記ページです。

stackoverflow.com

「がんばれ」と言ってもいい境界線

「がんばれ」と言うのは無責任か

 最近はうつについての理解が進んだおかげもあるのか、「がんばれ」と言うのは無責任で、相手に無用なプレッシャーを掛けてしまうということをたびたび耳にするようになりました。

 確かに、どうしようもならない病気で苦しんでいる人にがんばれと声を掛けるのは無遠慮な行為かもしれません。

 しかし、ちょっとだけ違和感を感じている人もいると思います。それは、「がんばれ」と言われて嬉しかった、助かった経験がある人です。

応援することは悪ではない

 そもそも、「がんばれ」というのは応援の言葉です。その人のためになるように、気持ちの大小あれど幸せを願う言葉です。言葉として、悪い類では決してありません。

 その言葉が人にプレッシャーを与えてしまうのはとても残念な結果ですが、現実として「勝手なこと言いやがって」と思う人がいるのも事実。

「不快に思う人がいるならやめた方が……」

「でも、自分は言われて救われたことがある。誰かの救いになるのであれば……」

 どうせなら、うまく使いこなせるのが一番です。

 では、何か使用するのに良い判断基準はあるでしょうか。

ゴールを目指しているか、スタートを目指しているか

 一つの判断基準として提案するのは、その人がどのステージを目指しているか、です。

  • 「がんばれ」と言っていい

 →ゴールを目指している人

  • 「がんばれ」を言うべきではない

 →スタートを目指している人

 スタート、ゴールと言って語弊がある場合もあります。「通常を目指している人」、「上を目指している人」と言い換えてもいいでしょう。

 その人が、その人にとってどの位置にいるか――それが重要なポイントとなります。

 ランナーに例えると、大会で新記録を出すためにハードなトレーニングをしている人。この人は自分なりのゴールを目指しているといえるでしょう。「がんばれ」と応援されて、嫌な気はしないのではないでしょうか。

 しかし、スランプに陥って、思ったようにタイムが伸びない人、そもそもいつも通りのタイムが出ない人……これはスタートラインに立つことを目指している状態といえます。このような段階の人に「がんばれ」というのは少し酷でしょう。

 病気や怪我の場合は、「治癒を目指す」ところがスタートラインです。

 健康になってあんなことをしよう、こんなことをしよう……そう考えて言動に表れている状態がゴールを目指している状態です。

 対して、このまま治らなかったらどうしよう。つらい。何とかして欲しい……これは、スタートラインを目指している状態です。自分がこんな時に「がんばれ」と言われたら――少し、つらいかもしれません。

その人の気持ちになって考える

 こう言ってしまうと途端に当たり前の話しになってしまうのですが、重要なのは相手の気持ちになって考えることです。そして、相手の気持ちになって考えるために、相手の状況をよく知ることが必要です。

 詳細は忘れてしまい正確ではありませんが、こんな話を本で読んだことがあります。

村に住んでいる少年は家に帰る途中、普段は温厚な村人のおじさんに突然乱暴な言葉を投げられます。少年はその場はやり過ごしますが、家に帰ってから憤慨して先ほどのやりとりを父親に話しました。すると父親から、彼の身内が今日亡くなってしまったのだということを伝えられ、「それを最初から知っていれば、もっと違う感情で、違う言葉をかけられたのに」と後悔しました。

 その人の状況を良く知らずに発言すると思いがけず相手を傷つけてしまうこともあります。

 「がんばれ」と応援したい気持ちがちゃんと伝わるように、相手のことをよく知って、思いやることを心がけたいものです。

 ちなみに、僕はよく状況を知らないけどがんばっているなぁ、という人には「がんばって」ではなく「体に気をつけて」と言うようにしています。参考までに。

※上に挙げたお話、ネットや本棚をあさっても見つけられませんでした。それらしいものをご存じの方は教えていただけると助かります。

Chefでcron(crontab)

   

楽なのか面倒なのかなんだかよくわからないことで定評のあるChefを触ってみた。

とりあえず今回はChef(OpsWorks)でcronを設定する時のメモ。

といってもここをちゃんと読めば何も問題ない。

http://docs.opscode.com/resource_cron.html

英語問題ない人は上記サイトへ。ワタシ英語ヨミタクナイってお仲間は速やかにこちらへ避難してください。

Chef関係のインストールや動作確認方法は以下を参照

http://www.atmarkit.co.jp/ait/articles/1305/24/news003.html

Cookbookのインストール

Cookbookのディレクトリで以下を実行

knife cookbook site download cron

tar.gzが落ちてくるため解凍(バージョンは適宜修正)

tar zxvf cron-1.4.0.tar.gz

cronディレクトリが作成される。

登録

cron/recipies/yourtask.rb を作成(このレシピ名も適宜)

cron "yourtask" do # タスク名(大事)
    action :create
    minute "0"
    hour "7"
    weekday "1"
    user "myuser" # 実行ユーザ名
    mailto "myuser@calmsfill.com"
    home "/home/myuser/tasks" # 実行ディレクトリ
    command "python new_week_has_begun.py" # 実行コマンド
end

上記の登録で、毎週月曜日の朝に1週間の始まりをお知らせしてくれる悪魔のようなタスクが登録される。

minute, hour, day, weekday, mouthは設定しないと自動的に *(aster) になる。

英語のページを見るとコマンドは他の書き方も例がある。

command if [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ];
then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi
command %Q{
    cd /srv/opscode-community-site/current &&
    env RUBYLIB="/srv/opscode-community-site/current/lib"
    RAILS_ASSET_ID=`git rev-parse HEAD` RAILS_ENV="#{rails_env}"
   bundle exec rake cookbooks_report
}

タスク名がKeyになっているので大事。タスク名が同じなら実行するたびに上書きされ、新規タスク名なら既存の設定に追記設定される。

削除

cron/recipies/delete-yourtask.rb を作成

cron "yourtask" do
    action :delete
    user "myuser"
end

actionをdeleteに変えて、タスク名とユーザ名は登録時と同じものを使う。

ここでもタスク名をちゃんと見てくれていて、同じタスク名で登録したタスクのみ削除される。

逆にいえば、このcookbookで登録したタスク以外は消すことが出来ないからその辺りは統一しなきゃならない。


こんな感じで、既に公開されているレシピをダウンロードして使うだけだと簡単。

自分で1から書こうとすると大変なこと間違い無しだから、公開レシピを上手く使って料理するのが正しいのかもしれない。

cronのレシピでもっと細かい情報が必要な人は以下のページが詳しいです!

http://docs.opscode.com/resource_cron.html

ちなみに、cronじゃなくてcrontabという名前のCookbookも登録されている。(knifeもcrontabで落ちてくる)

http://community.opscode.com/cookbooks/crontab

こっちはtemplates配下に置いたcronスクリプトファイルをそのまま登録するタイプ。

既存のものがあるならこっちのほうが楽かも。