#生存戦略、それは

2019-07-04

はてなグループ終了に寄せて

「セカンドライフ、はてなグループのディレクターやらへん?」

2006年、鉢山オフィスの会議室に呼び出された。当時のはてなでは、基本パブリックスペースでの会議が主だったので、何なんだろうと思った。会議室では、jkondo *1がいて、上記のようなことを言われた。曰く、はてなグループはとても価値があるサービスだと思っていて、jkondo は様々なサービスを、naoya んはブックマークをやってるし、きっと伸びるサービスだから、ディレクター(今で言うプロダクト責任者)を secondlife がやらないか、とのことだった。その時、私は即答で「えー、面白く無さそうだからやりません!」といった回答をしたと思う*2

はてなでは印象的な出来事がいくつもあったのだけど、この出来事は今でも覚えている。今でこそ当たり前に使われている Qiita::Team, Kibela といった、日本の様々な企業が導入している情報共有ツールは、はてなグループ*3 が源流となっていて、とても先見の明があったサービスのPMを自分で選択しなかった*4、という出来事として記憶している。

当時の社内情報共有言えば、基本的にはWikiを採用していた企業がほとんどの中、Blog(フロー情報、自分の考えや、「今」が大切な記事をアウトプットする)とWiki(ストック情報、蓄積される・見返すことが出来る情報)が融合され、トラックバックやidトラックバック(メンション機能)もあったためディスカッションの場としても最適で、とても便利な物だったが、その良さを知っているのは、はてな社(と、当時法人契約をしてくれていた何社か、法人契約するとSSLが使えた)、本来大口顧客になりえた他企業には時代が早すぎたこともあり、ほとんど伝わらなかった。グループウェア機能(カレンダーやタスク管理)等々も実装されていたが、こちらもしかり。

また、toB向けの機能のみならず、toC向けには趣味を同じくする人たちのコミニュケーションの場としても提供していた(g:subtechg:vim など、技術者が集まるグループもいくつもあった)し、一般ユーザからするとそちらの顔としてのはてなグループの方が記憶に残って居るであろう。

はてな社内では、はてなグループは徹底的に利用されていて、技術仕様、日報、メモ書き、ミーティングアジェンダ〜議事、プレゼンテーション、社内告知、雑談、サービスアイディアのディスカッション等々、毎日のように情報を書き込んで、誰かの書いた情報を見ていた。当時、社内を行き交っていた様々な情報は、咀嚼され自分の中に価値としていくつも蓄積されたし、jkondo がアメリカに居る時に社内グループで屈託の無いディスカッションをたくさんし、当時は毎日胃が痛くなったりもしたけど、良い出来事だった。今は振り返って見ることが出来ないけど、自分が20代半ば〜30歳前までの社会人青春時代の思い出が詰まっている。

そんなはてなグループが終了してしまうことは寂しいことだけど、いままでありがとうはてなグループ。はてなグループの血は、様々なサービスになって受け継がれていくと思う。はてなグループよ永遠に。

*1:他にも誰か同席していたと思うが、近藤さんのイメージがとても強かった…

*2:当時はてな社はとても牧歌的な会社で、様々なことを自由にやらせて貰っていた、ありがたや…

*3:Qiita::Team は元はてなアルバイトの yaotti が作ったし、Kibela は Cookpad 社内の情報共有ツールの影響を受け作られた影響元のCookpadの社内の情報共有ツールははてなグループの影響を受け作られた

*4:もし、PMになっていたとしても、当時の自分ではきっと「自分が考えた最高に便利な機能」をたくさん実装しただけで、いまのはてなグループ以上の何か大きな価値提供が出来るサービスになってたとは思えないけどね

2019-04-08

gerry++

先週末、3年ぶりぐらいの酷いgerryに見舞われたことをここに記す。

2016-08-17

Slack アプリで team アイコンが壊れたとき

Windows アプリなら ~/AppData/Roaming/Slack の Cache と GPUCache と消すと直る。異常終了すると時々なるのでメモ。

2016-08-11

Windows10で強制的にカスタムの拡大/縮小率が設定される問題

Windows10 で、高解像度ディスプレイのためのサイズ倍率だが、赤文字で「カスタムの拡大/縮小率が設定されます」という表示の共、再起動すると毎回意図しない倍率に設定される問題が発生した。めんどくさいことに、これを解除するにはログアウトが必要でカルマが溜まる。

のスレにあるとおりの状況だった。

LG のディスプレイユーティリティ OnScreen Control を入れているのだけど、こいつが起動時に自動で「Windowsのテキストサイズ調整」という機能で、旧来のコントロールパネルからの「カスタムの拡大率を設定」(非推奨)を適用してしまうためだった。

OnScreen Control を起動しないようにしたところ、再起動しても適用されないようになった。

2013-11-26

gerry++

いつでも必ず入れる個室がある安心感って幸福度に直結しそう。

と久しぶりに個室探して冷や汗ダッシュしたので感じたのでした。

2013-02-08

Rack のセキュリティフィックスと Timing Attack の話し

さきほど Rack にセキュリティフィックスバージョンが出たんだけど、セキュリティ的に何故に問題があるのかわからなった(Timing Attack をよく解ってなかった) のでメモ。

  • https://github.com/rack/rack/commit/0cd7e9aa397f8ebb3b8481d67dbac8b4863a7f07
  • このコミットで直った。HMAC で生成するハッシュ値の比較チェックを == から別のメソッドで行うようになった。
  • https://github.com/rack/rack/blob/master/lib/rack/utils.rb#L399-L408
  • え、これ戻り値の bool は Ruby の String#== と同一じゃん、なにが問題なんだろう?
  • 攻撃者が指定した digest により、== の比較速度が異なり、HMAC が推測可能になるのが問題
    • これが Timing Attack か!
    • Response Header で X-Runtime を出してると usec 単位で処理時間がばれる
  • secure_compare だとバイト列の比較で最後まで舐めるため、処理速度にばらつきが無くなる

ナルホディウスデスゾ~。mrkn / miyagawa さんに教えて貰った。

なお Rails は

use ActionDispatch::Cookies
use ActionDispatch::Session::CookieStore

な別の middleware で処理をしてるため、Rack の影響は受けない、と。

2013-01-24

GitHub Enterprise TechTalk に見る、各社の運用法

弊社もバリバリ GHE を使ってるので落ちると開発が回らなくなる(pull request できないのは、master に merge できないのとほぼ等価)ので、他社どうやってるのかーと大変気になってたのでしれて良かった。

間違ってたら教えてくだしぃ

  • クックパッド
    • 開発者は GHE へ push, webhook でメインの git サーバに同期
    • GHE の git レポジトリは本番からは利用しない
    • GHE が死んだ場合はメインの git サーバを向けることで継続開発・デプロイ可能
  • はてな社
    • 開発者は GHE に push したり場合により別のサーバに push したり
    • GHE から webhook でミラーリング
    • GHE / 別 git を開発者がうまく使いこなす必要がある。混乱するので git-hatena コマンドを用意してよしなにラップしてる
    • GHE のサーバは Active Standby 構成らしいけどどうやってるのか聞きそびれた!
  • DeNA 社
    • 開発者は GHE へ push
    • GHE から各種 ghe- ツールを使いバックアップ
    • repos は巨大すぎるので ghe- ツールで無くて rsync
      • 某権限でゴニョゴニョ…仮想マシン上のウブンツですし…
    • 構成は Cold Standby 構成
  • - VMWare の仮想冗長化はお値段が…
  • GREE 社
    • 大場さんがんばって(´;ω;`)

というわけで

  • GHE が死んで pull request できなくなると死ぬ
    • DeNA でやってる Cold Standby 構成で
  • 本番に deploy やレポジトリ参照できなくて死ぬ
    • 参照するのは GHE レポジトリで無く別のメインのレポジトリで

が良さそうだナーと思いました。へーしゃも DeNA 社的なアプローチとりたいなぁ。あと GHE も日々進化してるので、そのうちきっと低コストな手法で SPOF が排除される機能がつく…はず…といいなぁ…

あと感想で GHE 使うの苦行だけじゃ、って話しを何件か見たけど、実際 github.com の運用だけで問題ない会社なら

  • github.com を使ったときのセキュリティリスクをとれる
  • github.com が死んでてもなかない

なら、github.com を使うべきですよ。GHE に github.com で実装された機能が入ってくるのにも時差あるし、github .com を使わない理由は無いです。安易に GHE を使うと運用をしっかりしないと死ぬので。