投稿

2月, 2015の投稿を表示しています

新人を追い出したチームの話

このような話を聞いたことがある。以下の話から予想されるとおり、そこそこ大きい、安定したIT会社での話だ。話をしてくれた人を仮に「彼」とする。 チームリーダーが新人に別のチームに移ってもらうことを検討していた。そこにいた「彼」は驚いたという。「え、判断するには早すぎないか。単にコードベースに慣れてないだけだろう」リーダーは否定した。この動きは「彼」が所属した会社の中でもあまり見ない速度のものだった。入社後ものの数ヶ月弱で、新人は別のチームへ移された。しかし、「彼」が驚いたのはそこではない。 リーダーはその後もその新人とはコミュニケーションを密に取った。チーム内の会食にその元新人を誘った。「彼」いわく、チームを離れた後に新人をチームのテリトリーで見ることが多く、戸惑ったという。 もちろんその新人の心中は分からない。しかし談笑の雰囲気からして、タイミングが合えばそのリーダーと(元)新人が組むことはあり得るようには見えたらしい。追い出した・追い出された、という視点からすればあり得ない程度に和やかである。「彼」はそれ以降も追い出された新人の悪評も一切聞かなかった。適性のあるチームに入れたのだろう。当のチームでは、そもそもその新人が大いに問題を起こしたわけでもないため、元新人がそこにいたからといって顔をしかめるような人がいるはずもなかった。 話の最後に、彼はその行動を見て自分を恥じたと言った。「チーム全体で、新人をチームから外に放出したことを個人の否定だと解釈したのは、多分俺だけだったんだよね」。 私が聞いている時も「彼」は「追い出す」という表現を使いたがったが、実際にリーダーが使った表現と行動はその言葉にまずそぐわないのではないか、と私は感じたものだ。そのリーダーは「適正にもとづいて放り出す」ことと「個人の能力否定する」ことの違いが、しばしば曖昧になることがわかっていたのではないかと想像する。早期移籍の処置とアフターケアは、その区別を明確にするためであり、本当に新人のためを考えての行動だったのだろう。恐れ入る。 ただ、自分がリーダーという立場でいても多分この采配は容易には取れないとも同時に感じた。まず追い出すことは出来ず、どこそこかで愚痴を流すだけな気がする。しかし、それは、チームのためとも、その新人のためとも、会社のためとも、とても言えたものではない

[PR] DroidKaigiは現地での発表がオススメ?

DroidKaigi運営メンバーの一人です、こんにちは。 本家:  http://droidkaigi.github.io/ はてブ:  http://b.hatena.ne.jp/entry/droidkaigi.github.io/ 代表ひだか:  http://d.hatena.ne.jp/hdk_embedded/20150205/1423077706 募集は既に結構いただいてます。が、 発表希望者もっと多いと嬉しいなぁ 、と運営メンバーで話してました。是非、お願いします m(_ _)m http://droidkaigi.github.io/#cfp 締め切りは2015年2月25日(水) 締め切りまで後1週間強です。興味をお持ちの方、是非お願いします。 で、はてブコメントに特に一つ「ああ、なるほどなぁ」と思ったコメントがあったので紹介します。 Ustなんかの動画配信しないらしいのでこれは現地に行くしか! ( http://b.hatena.ne.jp/entry/240779200/comment/luccafort ) るっか和尚! DroidKaigiの最も大事なポイントは「Android技術者オンリーのイベント」だと自分は解してます。「動画を後から見ればいいやぁ」などと言わず、是非会場に足を運んでもらって、技術者間の直接のコミュニケーションを楽しんでもらえると嬉しいなぁ、と改めて思った次第です。最近、減ってるんですよね、そういうイベント。 特に 発表すると半強制的にコミュニケーション取ることになる ので、更に良いはずですよ! http://droidkaigi.github.io/#cfp 締め切りは2015年2月25日(水) ちなみにPRはPull Request(注目を引けリクエスト)の略だよ!

C87『Android実践プログラミング』の電子版が発売されているようです

Android実践プログラミング 「第6 章Docker が切り開くソフトウェア開発の未来」を担当してます。興味があればどうぞ。 Dockerの直近の技術解説ではなくて、議論が浮つく危険を受け入れて3手先を想像してみた内容を意識しました。直近でDockerコマンドの使い方やDocker入門を期待している方にはそもそも有益な情報はあまりありません。 「コンテナ技術って新しくもないのになぁ」みたいな疑問を持つ筋には役に立つかもしれません。類似技術が昔からあると言われていて、私もそういう疑問は妥当だと思うのですが、ソフトウェア屋から見た時に見える「未来」が過去技術と違うから、Docker流行る契機になった、という気がしています。ここで「jail」というキーワードで思考停止するのはまずいだろうな、じゃぁ何が違うんだろうな、という風に考え、自分なりに説明できる素材を集めて考えてみたかった、という面があります。本章の説明には若干ファンタジー入ってるというのは私も同意するんですが、過去技術のままなら、本章の描いた同じファンタジーはまぁ描けないっていうのは、夢想する上では大事だと思うのですね。 Androidとはあいにく関係ありません。本のタイトルと明らかにズレてるよね。 2015-02-13 10:59: わーおHTMLが壊れてテーマと合ってない。直しました

テレビ

子育て中である。家であやしている時、BGMもいいのだが雑にTV番組を見たい時がある。 確かにネットの批判はもっともで、平均的な質は下がっているかもしれないと思った。一方、インプットのある種の意外性はテレビの方が上で、だからチャンネルがもう少しあれば平均的な質の低下は許容してテレビを見るのかもしれないな、とも思った。 ひな壇芸人のコメント字幕付きはつまらない。大事件であるとはいえ枠を取り過ぎだ。いい加減同じ演歌の繰り返しはやめてくれ。というわけでチャンネルを変えて、チャンネルが枯渇することは多い。 ネット生活で自分の手元に届いて欲しいけどおそらく届かない性質のトリビアルなネタはテレビで見ると軽く気持ちが上向く。それほど信ぴょう性があるものではないかもしれないし、ひたすらテンポは悪いし、代替はネットで検索したほうが量が多い。 ある種商品として、大衆が見たことがないものを何とか切り口を見出して提供しようとする人がいるのだろう、という気はする。そういう押し付けを嫌がる人がいるのはあるとして、それでなお公衆で流すというのにはある程度の企画力が要ると思う。ひな壇の数が増えたと言って、とどめを差せたと思うのは早計かもしれない。勝手に消滅し尽くすまでにはまだもう少し時間がある。自発と任されのメディアでは基本的な性質が違うんだろうと再認識した。 時空転抄ナスカを見ていたのだが、振り返ってみるとlainの方が記憶に残るのである。まぁ、テレビというのはそういうもんだと思う。

12人の優しい日本人

12人の怒れる男:  http://dmiyakawa.blogspot.jp/2015/01/12.html 怒れる男がアツい作品だったのに対して、こちらはそこはかとなく「ダルい」作品。いや作品がダルいのではなく、12人の日本人がダルい。人間のダルさは今よりも昭和っぽい感じがする。 良くも悪くも元になった『怒れる男』を見る必要はない。どちらの方が良い悪いという評価も正直出来ない。ベクトルが全く違う。 敢えて言えば、『怒れる男』は陪審員制での議論のあり方のようなものが強く出ている気がする。『優しい日本人』は、陪審員制をネタに(当時の)日本人の色々なびみょーな態度が強調されている。『怒れる男』は「ああすげぇ」なのに対して『優しい日本人』が「ああだりぃ」になったのは、各々の態度が分かってしまう自分がいるからなのかもしれない。 『優しい日本人』の陪審員による事件の結論は『怒れる男』のそれよりもグダグダに見える。要は最終的には合意が取れればよし、にちょっと近い。穿ってみると、視聴者は陪審員より一歩先を見て「ああ……これは……」と事件の真相を見れる気もする。そこまで行かず、なんというか「あ、全員一致になったんでwww」みたいなところがある。 (以下ネタバレ) 思うに製作者が暗に示したいのは「男が女を突き飛ばして救った」のに、何故か裁判になってる状況なのではないかと思ったのだ。男が飛び込んだ、というのはあり得るけどおかしいし、そこで日本人が手を打ってしまうというのは、それはそれで気が利いている。物語の最後の説明は、自分には男が「悪魔のような形相で」トラックが自分たちに飛び込んでいることに気づき、女を突き飛ばしたというものだ。もっともそれなら女は尻もちを付いているのではないか、といったもっと別の疑問は湧くのだが、本編でそんな説明はもちろんない。 (以上ネタバレ) 風刺というか、茶化す目的としては非常に手が込んでいていいのだけど、ストーリーとしてはそれほど興奮する真っ直ぐさがない (『怒れる男』は興奮するのだ)。『優しい日本人』について言うと、途中で切り上げてもそれはそれで面白いだろうし、最後まで見ても全くすっきりしない。

SAML Single Log Out

https://wiki.shibboleth.net/confluence/display/SHIB2/SLOIssues IdPから渡される認証情報は3レイヤ、場合によっては4レイヤで保持される IdP SP SP上のアプリ ブラウザ 特に厄介だと思われるのは、フェデレーションにおいてSPとIdPはN:1、かつSPと同士は互いに相手を知り得ないのがプロトコル上明らかなことだと思う。ある特定のSPがIdPと一気通貫でログアウト (そもそもこれもShibbolethでは比較的最近できるようになったらしい) したとして、他のSPはそれを知り得ない。SPが知り得ない以上、その上の(例えばShibboleth SP上で構築された)アプリが知るのは更に難しい。仮にSPが知っていたとして、アプリが気をつけていない場合、アプリ上のセッション情報が残ってしまうことがある。ブラウザキャッシュはブラウザが壊れていなければ比較的対策方法が自明かもしれないが、バグっていたりすると目も当てられず、SAMLのノウハウというのは他ほど出まわらない。 やや脱線するが、SPという表現で示されるものがしばしば異なることも問題をややこしくさせると思う。ある人は認証を要求するホストと思うかもしれないが同じURIを共有していればIdPからは一つのSPだ。1ホストで2つ以上ののURIを持つことは可能で、一つのSPが一つのアプリを意味するわけでもない (Shib-SPにSAMLプロトコルの処理をまるなげした場合、IDを分けてなければSPとしては「同じ」になるが、それに依存しているアプリは複数あり得る)。