再帰的に子プロセスをkillする

あるプロセスが長期間放置しているとOutOfMemoryで死ぬので、OutOfMemoryで死ぬ前にkillして起動しなおすと言う事をやりたい。

あるプロセスはそこそこな数の子・孫プロセスを作るので、子プロセスを全部辿ってkillしたい。

ただし、実行元の親プロセスは残す。

cronはなんとなく使わない。kill後の生死は問わない。

#!/bin/bash
色々やる &

# 時が来るまで待つ
sleep 86400

# 再帰的に子を辿る
function rpgrep(){
  local ppid=$1;
  for pid in $(pgrep -P $ppid); do
    echo $pid
    rpgrep $pid;
  done
}

# $$=自身のPID
kill $(rpgrep $$)

# 自分自身を起動するコマンドとか。 exec "$@" とか
exec bash test.sh

しばらく運用してみる。

はてなブログに移行した

はてなダイアリーが閉鎖すると聞いて。

記事を消しちゃうのはなんとなくもったいない気がしたので、とりあえず移行を済ませました。

元々Markdownが使えるはてなブログには移行したいと思っていて、色々やってたのだけど、idを気にし始めてしまった。 この id:ryousanngata は今のHNになる前に取ったヤツだし、古すぎるよなぁって思っていた。

そこで別アカウント id:ryozi_tn でblogを作っていたりしたけど、はてなブックマークは古いidのままにしておきたいし、色々面倒になっちゃってなーなーになってた。

しかし今回のはてなダイアリーがなくなると聞いて、消すのが嫌なら移行先としてはてなブログになるわけで、そうなると前のblog要らないな?となった。

ということでなので、id:ryozi_tn は無かったことにしてこのidでやっていこうかな、と。

でもid変えたいなぁ。あと広告の主張が強くなったなぁ。

Microsoft de:code 2017 1日目

仕事で「今日もつまんないな」と元気なさそうにしてたら「de:codeあるし参加費負担するから行ってきてもええんやで」と言われた。
朝早い電車は人が混んでて辛い。みんなこの生活をあと何十年もやるつもりなの?って思っちゃう。


というわけで行ってきました。一部セッションは動画に残り、この辺りに集まるようです。

https://channel9.msdn.com/

技術に理解があるのだけど活用出来ない現場なので辛い・・・導入していくためにどうすれば良いかなーとか説明できるための知恵を漬けたいなーと思っていたら、DevOps系のトークばかり聞きに行ってた。de:codeとは一体・・・

以下、参加した感想

続きを読む

父親がダメ

ここ2,3日で父親についていろいろうんざりしたので。

私から見た父親は、パチンコなどのギャンブルで生活費を使い込んだり、ギャンブル絡みで金銭トラブルによる夫婦喧嘩もしばしばやってたし、治る見込みがなく死ぬことが分かった母親の保険金のために離婚を辞めて死ぬのを待ったようにしか見えなかったり、8年以上ロクに働かずに過ごしたり、金とギャンブルのためにいきてるんだろうという認識。ダメな親だと思ってる。こんなダメな親だけど育ててもらった以上、その恩は感じてる。

しかし、ここ2か月で130万の使い込みをしていたことが分かり、その立て替えをすることになり、いよいよ早く死んでくれないな、という感じ。

続きを読む

プロジェクトを進める上での「要望・要求・要件」と愚痴

感情的になっちゃったので先に反省しておくと、自分がもっと要求分析をしたりして具体的に何をしたいかを聞き出したりしなかったのが悪いとは思っている。(客との距離間があって話しにくい。)

しかし、客はもっと自分がやること・自分が関わるプロジェクトに関心を持ってもらいたい。自分みたいなのと仕事するのは不安でしょう。


話は少し変わりますが、プロジェクトの進め方について勉強したわけではないけど、要望・要求・要件という言葉の使い分けをどこかできいて、プロジェクトでは必須では、と思ってる。

自分の頭の中ではこんな感じ。

  • (要望)これやりたい、何かをしたい
  • (要求)実現するにはこういうのが必要
  • (要件)こういうのを実現するには、こうしたらどうでしょうか

客側は「要望」と「要求」は固めるべき。要望は複数の要求からなりえるし、要求は要望にもなりえる。開発に伝わるまで小さくしていきましょう。
開発側は「要望」と「要求」を聞いて「要件」に落とし込む。場合によっては「要求」が足りなかったり、「要求」が見当違いなことになっているかもしれないから、こういう「要求」ではないですか?と提案する。(あと、客側に「フワフワさせてないで要求をはっきり言えや」と言える気概も必要かも。)

客は要求までをしっかり言えれば良くて、開発は要求から要件を固めればよい。
要望と要求について、客と開発の間で合意を取っていたら、巻き戻ることもない。

あとは、時間はかかっても焼きあがるはず。あとは正直に行きましょう。未知のソフトウェアについて知ったかぶってはいけない(戒め)

でも、この「要望・要求・要件」がちゃんと出来てないと、辛くなるのではないでしょうか。僕はそう思いました。

ポエム終了。

以下も頭の悪そうな愚痴。

続きを読む

Domain別にCookieを送る条件を調べた

Perl5のWWW::Mechanizeの挙動がなんか怪しかった。で、HTTP::Cookiesがどうも怪しそうだった。
送るべきCookieを送れてなかったりとか。

で、何が正しいのかわかんなくなってしまったので、Chromeと動作を比べた。
RFCとか見ればわかる事なんだろうけど、見てわかるような表がほしかった。文字読むの苦手なんだ。

確認方法

  1. Set-Cookieを受け取るためのアクセスを行う(「A」)
  2. Cookieを送るためのアクセスを行う(「B」)
  3. 「B」のときに送られたCookieの内容を確認する。(「A」でSet-Cookieした内容が送られたら○、そうでないなら×)

対象domain

  • ryozi.net
  • main.ryozi.net
  • sub.ryozi.net

Set-Cookie時のdomainの値

  • domain指定なし(none)
  • domain=ryozi.net
  • domain=.ryozi.net
  • domain=main.ryozi.net
Chrome
「A」のドメイン 「B」のドメイン (none) ryozi.net .ryozi.net main.ryozi.net
ryozi.net ryozi.net ×
main.ryozi.net × ×
sub.ryozi.net × ×
main.ryozi.net ryozi.net × ×
main.ryozi.net
sub.ryozi.net × ×
sub.ryozi.net ryozi.net × ×
main.ryozi.net × ×
sub.ryozi.net ×
WWW::Mechanize
「A」のドメイン 「B」のドメイン (none) ryozi.net .ryozi.net main.ryozi.net
ryozi.net ryozi.net ×
main.ryozi.net ×
sub.ryozi.net ×
main.ryozi.net ryozi.net × × × ×
main.ryozi.net
sub.ryozi.net × ×
sub.ryozi.net ryozi.net × × × ×
main.ryozi.net × ×
sub.ryozi.net ×

確認時に使ったコード

https://gist.github.com/ryozi-tn/f2be9b397cf9b2402c352b27a21a75bb


後はクッキーの上書きを登録時のdomainとは異なるdomainからでも出来るのか、domain値が似てるようで違う(「.ryozi.net」と「ryozi.net」)場合も上書きできるかなども調べたほうがよさそうだけど、面倒になったので諦めてPhantomJSでやることにしました。
PhantomJSもこれはこれで辛い・・・