Hatena::ブログ(Diary)

n3104の日記 このページをアンテナに追加 RSSフィード

2014-07-13

はてなブログに引っ越しました

いまさらなんですが、はてなブログに引っ越しました。

http://n3104.hatenablog.com/

何回か書いてみてからどうするか決めれば良いと思っていたので、実際には3月末からはてなブログ側で書いています(といっても、この日記を書く時点で3エントリーしかありませんが)。とりあえず暫くははてなブログで書いてみる予定です。

2013-07-24

Fork/Join Framework についてちょろっと調べてみた

同僚と Fork/Join Framework について話す機会があり、ちょっと気になったので調べてみました。ちなみに、ソースは jdk1.7.0_25 です。

native なのか Java なのか?

native とかは使わないで普通に Java の Thred クラスを利用して実装しているようでした。そのように判断した理由は以下の通りです。

  • ForkJoinWorkerThread 自体は Thread クラスを継承している
  • ForkJoinPool#invoke から RecursiveTask#compute までのソースを見た感じ、普通に Java のコードだった
ForkJoinWorkerThread の生成タイミング

ForkJoinPool#invoke の中で ForkJoinWorkerThread を生成しているみたいでした。

registerWorker(ForkJoinWorkerThread) : int - java.util.concurrent.ForkJoinPool (3 matches)
	ForkJoinWorkerThread(ForkJoinPool) - java.util.concurrent.ForkJoinWorkerThread
		newThread(ForkJoinPool) : ForkJoinWorkerThread - java.util.concurrent.ForkJoinPool.DefaultForkJoinWorkerThreadFactory
			addWorker() : void - java.util.concurrent.ForkJoinPool
				signalWork() : void - java.util.concurrent.ForkJoinPool
					addSubmission(ForkJoinTask) : void - java.util.concurrent.ForkJoinPool
						invoke(ForkJoinTask<T>) <T> : T - java.util.concurrent.ForkJoinPool

ちなみに、 ForkJoinPool#registerWorker まで書いているのはこの中で ForkJoinPoolクラス の workers フィールドに新しく生成した ForkJoinWorkerThread のインスタンスを代入しているように見えたためです。なお、 workers フィールドの初期化は ForkJoinPool のコンストラクタの中で行なっているようで、引数なしのコンストラクタを利用した場合はプロセッサ数の 2 倍の数を生成するようでした。

    public ForkJoinPool(int parallelism,
                        ForkJoinWorkerThreadFactory factory,
                        Thread.UncaughtExceptionHandler handler,
                        boolean asyncMode) {

// ... 中略 ...

        // initialize workers array with room for 2*parallelism if possible
        int n = parallelism << 1;
        if (n >= MAX_ID)
            n = MAX_ID;
        else { // See Hackers Delight, sec 3.2, where n < (1 << 16)
            n |= n >>> 1; n |= n >>> 2; n |= n >>> 4; n |= n >>> 8;
        }
        workers = new ForkJoinWorkerThread[n + 1];

引数なしのコンストラクタ

    public ForkJoinPool() {
        this(Runtime.getRuntime().availableProcessors(),
             defaultForkJoinWorkerThreadFactory, null, false);
    }
ForkJoinPool#invoke から RecursiveTask#compute の呼び出し階層

以下の様な感じで RecursiveTask が呼ばれてました。 work-stealing の実装部分は読んでいませんw

compute() : V - java.util.concurrent.RecursiveTask
     exec() : boolean - java.util.concurrent.RecursiveTask
          doJoin() : int - java.util.concurrent.ForkJoinTask
               join() : V - java.util.concurrent.ForkJoinTask
                    invoke(ForkJoinTask<T>) <T> : T - java.util.concurrent.ForkJoinPool

ExecutorService との違いは?

2013-07-25 追記

  • 最初にいきなり native なのか Java なのかと書いてありますが、これは全く予備知識がなかったためです。ただ、たくさんのスレッドを利用するのだろうなという漠然としたイメージしかなく、同僚が native 使ってるかもと言ってたのでそこから調査しました。
  • 分割統治法を全体としており、再帰処理で分割する、かつ、 fork で並行処理するので幅優先探索を利用する処理に向いてそうという理解です。
    • 深さ優先だとシングルスレッドと変わらないはずなので。
    • 手軽に使えるのはいいですが、計算量の事前計算が必要だとは思いました。結局、タスクが大量に生成されるわけで、末端まで行かないとタスクが減り始めないので。
      • そういう場合は、プロセスで利用可能なメモリサイズを確認した上で、処理可能なサイズになるまでは自前でタスク分割と実行の制御を入れればいいんでしょうが。
  • MapReduce は分割統治法には向いてないのかなとは思いました。まぁ、処理時間を気にしなければ計算量を無視出来るオーダーが増えるので、そもそも比較すること自体がナンセンスですがw
    • 結局、 MapReduce って fork & join の深さ 1 ということなので、深さが 2 以上だとジョブ自体のループを実装することになり、面倒くさそうだなぁと。
  • 再帰なのでスレッドのディスパッチコストは低いのかなと思います。結局、末端からタスクが処理されるので、親は fork した子の処理が終わるまでスレッドの割り当てが戻ってこないので。 I/O 待ちでスレッド同士を切り替えるみたいな動きはあまりないという理解です。

2013-05-19

GitHub と Jenkins の連携でハマった

社内的に GitHub に移行することになったので、 GitHubリポジトリに pull request が merge されたタイミングで Jenkins のプロジェクトが実行されるように設定しました。設定手順は GitHub Plugin - Jenkins - Jenkins WikiTrigger Jenkins builds by pushing to Github | Four Kitchens が参考になります。 1 点ハマったのが GitHubPost-Receive Hooks の所で、 Basic 認証に対応している と書いてあったのですが、なぜか手前の Apache で 401 の認証エラーとなりました。結論は Apache の設定ファイルで Basic 認証ではなく Digest 認証にしていたことが原因でした。。既存の設定は HTTP のみだったのですが、そこは Digest 認証の設定があり、ちゃんと内容を読まずにコピーして HTTPS の設定を書いたことが原因でしたorz

2013-01-03

2012 年振り返り

ちょっと遅くなりましたが、2012 年について振り返っておきます。

2012年の目標と比べるとあまり関係ない感じですね。。

3 月に転職した。

3 月に広告配信系の会社に転職しました。前職では Google Apps 周りを中心に受託開発してたんですが、どうしても Hadoop を仕事で触りたくて。Servicer も初めての経験で色々驚くことばかりでした。特定の業務ドメインに関して勉強するといこともやってみたかったので、とてもおもしろかったです。まだ、競合他社との比較とかその辺までは追えてませんが、アドテクおよび Web 広告に関しては概ね掴めたかと思っています。今まで見ている Web ページの広告がどこ経由で配信されてるのかとか、あーリタゲされてんなーとか、今までとは違った視点で見えるようになっておもしろかったりしますw

仕事で MapReduce ジョブを書いた。

Hadoop との出会いは前職で 2010 年後半に SES で派遣された先で EMR の Hive の検証・導入を行った際でした。そこで心を奪われて、仕事では扱わなかったのですが、個人的にウォッチしている感じでした。そして、今年になって転職先で MR ジョブを書いて、かなりすっきりしました。要はファイルをぶん回すだけのバッチです、以上。みたいな感じですね。オンプレミスで運用しているので、Hadoop クラスタの不安定さも身にしみましたし、概ね学びたいことは学び尽くした感じです。なので、今後は緩い感じでウォッチでもいいかなーぐらいのテンションになってますw

子象本読書会を行った。

有志で Hadoop MapReduce デザインパターン ―MapReduceによる大規模テキストデータ処理読書会を行なっていました。3 週間に 1 回ぐらいペースで行なっていて、最終的に 12 回で 10 ヶ月ぐらいかかりました。途中からデータ分析担当の同僚が参加してくれたので、参考書籍を読み漁ったり、質問しまくったりして、隠れマルコフモデルについてだいたい理解できるようになりました。6 章だけで 4 ヶ月ぐらい使ったので、辛抱強く一緒に参加してくれたメンバーにはほんと感謝しています。去年、一番嬉しかったのはこの読書会でして、一緒に勉強できる仲間と巡り会えたのはほんとに嬉しかったです!

MySQL に慣れた。

今の職場で MySQL を利用していることもあり、まぁまぁ慣れたし、色々調査して面白かったです。主に調べたのは排他制御、実行計画、金額計算、タイムアウト辺りです。MySQL はネット上の記事も多いですし、本家のドキュメントが充実しているのでほんとよいなーと思います。ただし、日本語版は古かったり翻訳していない箇所が多いので、英語版を読むようにしていて、そこはちょっと大変だったりしました。英語力をもっと上げないといけないなーと思いました。

Git に慣れた。

前々から勉強するする詐欺をしてたんですが、転職先が Git を使っていたおかげで、かなり慣れたと思います。いやー、慣れるとほんと便利ですね。CUIdiff とか絶対無理と思ってたんですが、今では慣れてしまって特に違和感なくなってたりしますw

Mac に慣れた。

MBP 自体は持ってたんですが、仕事でメインで利用するのが Windows だったこともあり、使用頻度はかなり低かったです。ですが、転職先で PC を自由に選べたので iMac にしたお陰で慣れました。一番大きいのは Eclipse で、1 ヶ月ぐらいはショートカットキーの違いに苦しみましたが、そのぐらいで慣れてその後は快適です。むしろ、今では 10 年近く書いていた Windows でのキーバインドが思い出せないぐらいです。慣れというものについて色々と考えさせられる事象でした。

まとめ

どれも今年の転職がキーになっているものばかりで、転職してよかったなーと思っています。他にも仕事上 Ruby を触ったり、ActiveMQ について調べたりと色々経験できて、面白かったです。とりあえずそこそこ成長はしたと感じられる 1 年だったので、来年も引き続き成長していきたいと考えています。

2012-12-12

今までの子育てを振り返ってみました

この記事は 子育てエンジニア advent calendar 2012 の 12 日目のエントリーです。

うちは私と嫁さんと長男 5 歳、次男 3 歳の 4 人ぐらしです。長男は早生まれなので来年には小学生になり、割りと自分の時間も取れるようになって来ました。他の方よりは多少子どもの年齢が高いようなので、今までの子育てを振り返ってみたいと思います。

時系列の振り返り

家庭面、仕事面でのイベントと年ごとの自由時間について簡単にまとめてみました。他の方も書かれているように、子どもが生まれて変わったことや学んだことはたくさんありますが、とにかく自分の時間が取れなくなったというのはあります。うちの場合は長男が 3 歳の時がピークで、次男が産まれた & 育児休業したこともあり、ほんと自分の時間が取れませんでした。あと、仕事面で思うのは忙しいと言いつつも、結構好きなようにやってたなーとは思います(^_^;)

2006 年
  • 結婚 & 長男懐妊。
  • この頃は 50 人?ぐらいのプロジェクトでアプリ基盤チームに所属していました。
  • 嫁さんは妊娠したといっても、子どもが生まれているわけではないので、とても時間に余裕があったと思います。
2007 年(長男 0 歳)
  • 長男の誕生に伴い、勤務先でエンジニアからスクール事業の講師に配置転換してもらう。
    • もともと教員免許を持っていることもあり、講師はやってみたかった。
    • 講師であれば勤務時間が安定していると考えた。実際、かなり安定していて、家で過ごせる時間も多かったです。
  • 今にして思うと、まだ長男は 0 歳台で動けないし、よく寝てるしで時間に余裕がありました。
2008 年(長男 1 歳)
  • 次男の懐妊。
  • 講師だと技術的に置いて行かれる気がしてならなかったのもあり、現場に戻る。
    • 基本的に晩御飯には間に合わない感じになった。週に 1 日とか調整して早めに帰る感じでした。
  • 長男の夜泣き & 早起き(5 時とか。。)で地味に削られていたけれど、まだ 1 歳台で昼寝も多くて、時間に余裕があった気がします。
2009 年(長男 2 歳、次男 0 歳)
2010 年(長男 3 歳、次男 1 歳)
  • 長男が幼稚園入園。
  • 仕事先のプロジェクトで Hadoop に触れる機会があり、心を奪われた。
  • やっと土日に勉強会に参加できなくもないぐらい余裕が出てきた年です。
    • 幼稚園に入ったので長男が色々病気を持って帰ってきて、家庭内に病気が蔓延するようになりましたorz
    • 次男は夜泣きばっちこい状態だったので、睡眠時間も足りないし、寝かしつけた後に勉強してて急に起きて対応とかもありました。
2011 年(長男 4 歳、次男 2 歳)
  • 多少は落ち着いた気がします。まだ次男の夜泣きがあって、睡眠時間は安定しないし、冬場は子どもが風邪を引いたら家族全員が順番に引いたりしてました。インフルエンザで 7 営業日連続で休んだりもしましたorz
    • 長男はだいぶ体が強くなったのか、風邪を引いても熱がそれほど高くならないようになりました。
  • 平日は時間を調整して週 2 日ぐらいは早めに帰って家で一緒に晩ご飯食べたりしてました。
    • 調整しやすかった理由として自宅勤務可能なのもあったとは思います。寝かしつけた後に自宅で仕事をすることも多かったです。
2012 年(長男 5 歳、次男 3 歳)
  • 仕事で Hadoop を触ってみたかったので 3 月に転職した。
  • 次男もかなり歩いてくれるようになったし、夜泣きもなくなってだいぶ楽になったと思います。
  • 転職に伴い自宅勤務ができなくなったので、基本的に平日は子どもたちが起きている時間に帰れなくなったのは残念だったりします。
    • 中途半端に 20 時半ぐらいに帰ると子どもの寝かしつけの邪魔になるので、それならばいっそ寝てから帰るという感じです。
    • 自宅勤務は出来ないですが、勤務時間は自由な会社なので、朝は子どもを送ってから出社してます。嫁さん的にはそっちの方がいいそうなので、まぁいいかとは思ってたりもします。

学んだこと

コントロール出来ないことはたくさんある。

子育て以前に、体調管理とかも含めて、独り身の頃は割りとコントロール出来ると思ってたのですが、子どもがいると管理のしようがないことを思い知りました。マスクとか付けてくれませんしね。。幼稚園とか行くようになれば病気がうつるのも仕方ないですし。こどもが熱を出して早退したことも何度もあります。外食時に騒いだり、電車で泣いたり、もちろんそういう時期は行かないようにしてたりもするのですが、どうしても行かなければ行けない場合もあったりで、まぁ大変ですよね。電車の中で泣いている子がいると、ほんと心配するようになりました。

常に余裕を持っておく必要がある。

うちは両親の実家が離れていることもあり、気軽に両親にこどもの面倒を見てもらうということが出来ません。そのため、嫁さんが体調を崩したりすると私しか子どもの面倒を見れなくなるため、何かあった際に必ず対応できるように自分自身の体調管理はかなり気をつけています。子どもが生まれてからは徹夜で飲んだりとかは全くしないようになりました。

他人と比較しない。

時間は取れないし、すごい人はいっぱいいるしで、すごく焦る時期があったのですが、焦ると余裕がなくなって、それが家族に伝わるんですよね。なので、他人と比較するのではなく、少しずつで良いので勉強し続けるということを重視するようになりました。実際、お客さんから見て対価に見合う価値が出せていればいいわけで、そこをクリアできていれば後は自分のペースでいいんだと思えるようになりました。

家庭というプロジェクトの方が優先度が高い。

仕事のプロジェクトは一定期間で終わりますが、家庭というプロジェクトはそれよりも遥かに長い期間続くわけで、目先の仕事を優先して家庭というプロジェクトを破綻させないように気をつけないといけないと考えています。とかいいつつ、ついつい仕事には熱が入りますし、転職しまくったりしているので、実践できているかは怪しいですがw

嫁さんは偉大。嫁さんは偉大。

私は仕事をしているので好きな時間に休憩を取れますが、嫁さんは子どもの相手をしている際は自分のタイミングで休憩が取れないわけで、ほんと大変だと思います。改めて土日は私が子どもの面倒を見ようと思いました。


エンジニアカレンダーとして成立しているかよく分かりませんが、他の方の参考になると幸いです(^^)

次は @ さんです。