デバッグ

何となくだが、コーディングよりもデバッグが好きなような気がしてきた。
コードを読んだ限りは正しいが誤動作する、というのを直すのが特に好きだ。
たとえば、ハードウェアに欠陥があるとか、APIの内部実装が途中で変わったとか、ライブラリのユースケースとして考慮されていないものだったとか、そういうやつ。
そういう、未定義の動作まで含めて理解できると、カバー率が上がったような気がして楽しくなる。
きちんと理解しないとバグを直すことができないので、デバッグとは、理解の解像度を上げることにかなり近い行為なのではないかと思う。

なぜピアノを弾くのか

20才のときからピアノをはじめて、途中中断ありつつ早23年。
この前ピアノが趣味の人に、なぜ続けているのかたまに考えてしまう、あなたはなぜ続けているのか、と聞かれて、いつもの答えをしてしまったんだけど、理由は始めた当初からは変わっているように思う。
はじめるきっかけは中二病的な理由(ピアノを弾けるのかっこいい、きちんとした趣味を持ちたい)だったと思うのだけど、25才くらいで上達しなくなり虚栄心を満たす手段としては失敗に終わった。
それでも続けた理由はたぶんこんな感じ。

  • 先生が良かった(進め方や難易度が自分に合っていた)
  • 単純に音が好き
  • 特にやめる理由がない
  • 他の趣味より好き(色々試した結果残った)
  • 劇的な上達はしないが、新しい曲を覚えたり、多少は進捗する
  • (主にプログラミングなど)できることだけをやることに危機感を覚えた
  • 仕事のストレス発散
  • 知っている曲がより理解できた

目的意識を強く持たないほうが長続きするのかな、という気がするが、その代わりスキルは頭打ちになる。もう人生の終わりが見えているので、意識的にやったほうがいいよなあとは思っている。
いつもの答えは「知っている曲がより理解できるようになるのが楽しい」なんだけど、これは最近そう思うようになった。できないことができるようになるのが楽しいという人もいるんだけど、自分の場合は、物事の理解の解像度が上がるのが好きな感じ。

プログラマ35才限界説について

現在42才。あと何年かはプログラマでいるつもりでいる。
自分や同僚がプログラマとしてこの先生きのこるには、を考えることが多くなった。

問1についての考察

年齢を重ねることでできなくなることの候補として
(1) 体力の衰え
(2) 吸収能力の衰え
(3) 好奇心の衰え
(1)について、健康の維持は若い頃には聞き流すトピックだが、最近はヘルシープログラマが出版されたりして認知度は上がっていると思う。
大前提としては徹夜が必要な現場では働かないこと。あとは筋トレとかスポーツがんばる。
私の場合は30才で周りに体を壊す人が出てきて、これはまずいと思って近所のテニススクールに通い始めた。有料だと行かないともったいない気持ちになるのと、時間が決まっているので生活リズムをそれに合わせざるを得ず、習慣化しやすい。
プログラマでよく聞くのはマラソン、自転車、ボルダリング。会社で部活化してもいい。
(2)については、素養があるものに関しては差分の知識だけでいいので、若者より有利な部分が多少ある。新しいパラダイムはなかなか身につかなくてつらい。
自分は(A)1年1プラットフォーム、(B)苦手なことに挑戦する、というのをゆるくやってみている。プラットフォームは最近だとnode.jsとRailsAndroidをさわっていて、こういうのはやってるのか、くらいには追いつけている。たぶん。苦手なものはSICPとか競技プログラミングとか数学とか英語とか。得意まで行かないが好きにはなった。
(3)についてはよくわからない。新しいものを純粋に楽しもうという気持ちが減衰しているのか、経験により既視感が増えているのか、どっちもな感じはする。ただ加山雄三さんのように還暦を過ぎてもゲームに熱中している人もいるので、私がApple Watchに興味がないのも年齢のせいではないと思いたい。

問2についての考察

そういう予想もあるが、よくわからない。
究極的な状態として真にプログラマが不要になったとしたら、ほとんどの単純労働は自動化されているはずで、そのような社会では労働に価値はなく、時間の潰し方が最大の関心事になるだろう。
実際のところ社会の変化はゆっくりなので、10年やそこらでみんながプログラミングできるようになるとは思えないし、現状の商慣行や給与水準などからみても、コードが書けることで特別な給料がもらえることもないだろう。
いずれにせよ、技術を取捨選択して人間が使いやすいシステムを試行錯誤して構築する、というような類いの仕事は、自動化しづらく当面はなくならないように思える。

問3についての考察

たぶん価値を生み出すプログラマが良いプログラマだと思う。例えば、
(1) 必要な機能を追加し、不要な機能を削って価値を上げる
(2) 設定した目標を効率的・効果的に達成してコストを下げる
プログラミングというよりはエンジニアリングかも。いずれにせよ、より良いものを、より早く完成させること。ユーザーに使ってもらわないと価値はゼロなので、完成力とリリース力が大事。
ベテランはマネジメントせよとなるわけだけど、個人的には、人よりも開発対象にフォーカスしたい。仕事を均等に配分することよりも、重要な箇所を見つけて集中することに力を注ぎたい。
違う側面として、
(A) 仕事でコードを書くことを楽しめる
(B) チームで開発するのを楽しめる
(C) 新しいものごとに適応するのを楽しめる
と職業としての寿命が長くなると思う。楽しくないことも多々あるので、時には真面目に考えすぎないのもあり。
できる、と、楽しい、には相関があり、できるようになると楽しくなるし、それには学習の習慣化が必要、というのが定説になっていると思う。自分に向いた学習方法を見つけられると幸せ。

その他・健康について

そもそもなぜこれを書いたかというと、ちょっと前に親を介護して看取ったのだけど、そのときに大事なのはQuality of Lifeだと思った。あと、人生は短いので、やろうと思ったことは思い立ったときにやればいいし、「これをしたほうがいい」はおおむねうざいわけだけど、言った方がいいと思ったことは躊躇しても無駄だと思い、最近はちょっとだけ周りに言うようにしている。
QoLはおおむね健康で、健康には心の健康と体の健康があるけれども、体を壊すと心の健康も維持できなかったり、技術的なスキルのミスマッチなどでもやはり健康を損なったりする。
健康のためには、適度な刺激(ストレス)があったほうがいいという気がしている。例えばお金をもらっているので仕事に行かないととか、お金を払ったのでレッスンに行かないととか、プログラマは英語ができないと、みたいな義務感とか焦燥感とか使命感のようなもの。過度だと体を壊すし、全くないと、「できる→楽しい」のループに入れない。この辺は個人ごとのバランスになる。居心地のいい場所を見つけたい。
果たして私はこの先生きのこれるのでしょうか?
Happy Hacking!

x86/x64最適化勉強会7

非正規化数のFZ(FTZ)とDAZの違い

こういうモードがあるのは知らなかった。
極小同士の乗算でも普通にやるとゼロになってしまうものが、非ゼロ判定ができたりする。

いまどきのmatmul

行列の乗算の高速化。すごい。ロードと演算とストアがフル稼働。
TLBのキャッシュミスはトレースレジスタみたいなので調べたのかと思ったけど、そうではなくて少しずつ作り変えて色々試したらわかったらしい。強い。

CSS JIT: Just-in-Time Compiled CSS Selectors in WebKit (リンクはブラウザエンジン先端観測会のもの)

CSSのスタイルのマッチング処理がめちゃくちゃ重たいので、WebKitではJITで処理しているという話。CSSがそんなにCPUパワー食うと思ってなかった。
広告をあれするやつとかが重いらしい。スライドには出てこなかったがhasは恐ろしく重いらしい。

改ざん検知暗号Minalpherの設計とIvy Bridge/Haswellでの最適化

暗号化と改ざん検出はセットでやらないといけないらしく、Authenticated Encryptionというジャンルが確立している。規格案のコンペCAESAR competitionにMinalpherを提案したとのこと。
実行スロットにフルで詰め込む実装。スケジューリングが職人芸というかCPUの気持ちになってる。
デファクトスタンダードのAES-GCMはCTRモードをベースにして、カウンタに多項式を使ったもののようだ。かなり高速で1clock per byteくらい出るらしい。

準同型暗号の実装とMontgomery, Karatsuba, FFT の性能

Somewhat準同形暗号の話。普通の準同形暗号は加算(XOR)か乗算(AND)のどちらかしかできないが、両方できると相関を取るようなこともできるので、生体認証もいけるぽい。
後者(多倍長整数)の説明で、こちらは整数演算と説明されていて、多項式演算のほうは整数演算じゃないのかな、と思ったら、(浮動小数点ではなく)整数を使った計算ではあるものの、多項式演算で通じるのでそういうものらしい。数の範囲とか性質とかで区別されているのだろうか。
ものすごい計算をするけど1単位にストアできる情報が60bitとかそのくらい。すごい。

LLVM最適化のこつ

キャリーフラグっぽく書いたらだめで、なしで書いたらちゃんとキャリーを使ってくれたみたいな話。
LLVMアセンブリ出力が手で書いたのと同じになるまでがんばるというのがなんか順番が間違っていて面白い。

感想

毎度のごとく難しかったが、素晴らしい会でした。堪能しました。

エンジニアの未来サミット2014

エンジニアの未来サミット2014〜働く場所の見つけ方、作り方」というイベントに行ってきたのでメモを残す。一部時系列順ではない。

テーマ

Engineer's Paradise

インテック 先端技術研究所 中川さん

  • テーマ: (会社だけでなく)業界を変える
  • 社長に業界を変えるような技術開発をさせろと直訴したら会社ができた
  • MPLSなど特定の分野に注力した結果、3大キャリアに導入されるなど、製品化に成功した
  • パートナー企業からエース級のエンジニアに出向してもらうという取り組みをした。終了後社長にプレゼンしたり、ポジションを作ってもらうなど、先方でも会社をあげてバックアップしてもらった
  • 本人の技術的チャレンジと、経営者の期待でエンジニアはすごく伸びる

Preferred Infrastructure 西川さん

  • テーマ: あらゆることをコンピューティングで加速する
  • 技術と実用製品のギャップを埋める、技術とビジネスの両方を考える
  • 研究者が実用化の困難さを理解することが重要
  • 行動原理を大切にするため、外部資本(VCとか)を入れないことにした
  • 受託は製品につながるものだけやる
  • 今はedge-heavy dataに注目している
  • 最初はとにかく組織を作るのに注力
  • 今は持続的に技術的なチャレンジを作ることに注力
  • Haskellで世界を変えるよ、みたいな人もいる。技術が好きすぎて妄想するくらいでもいい
  • エンジニアは鮪 = 成長しないと死ぬ
  • 技術に対するモチベーションがほぼ全て 福利厚生はおまけ

サイボウズ・ラボ 畑さん

  • 旧テーマ: 既存の製品にとらわれず、世界に通用する技術を追究する
  • 現テーマ: 製品に結びつく技術開発
  • 目立つし制度も別にできるので、研究部門ではなく子会社にした
  • 社名とか50%ルールなど、弱者が目立つための方策
  • プロダクトに結びつかなかったので方向修正した
  • 評価は難しいので主観でやりますと伝えている
  • その人に合ったテーマを設定することに注力
  • サイボウズ・ラボユースで合宿したりしている

サイバーエージェント Ameba Technology Laboratory 福田さん

  • 飲み会でlabo作るなら秋葉原がいいと言ったら翌日やることになっていた
  • 物件も自分で探した
  • 部品: Hadoop, Hive, Flume, HBase, Solr
  • 毎月研究会、半期に1度の研究レポート
  • 実サービスに使えて、かつ、新規性のある部分をやっている
  • 実サービス部隊と連携しすぎると研究に影響が出てしまうので、室長がコントロールしている

統計数理研究所 丸山さん

  • if you are given a change, you take it
  • 自然言語処理から、XML&Java
  • 研究者として挫折したと思ったが、実用性のあることをやれて良い経験になったし、結果的に研究所の所長のオファーが来た
  • research that matters
  • 研究は面白いからやるのではない 必要だからやるのだ
  • 研究の3フェーズとして、(1)研究提案(2)研究実施(3)技術移転・論文発表
  • 日本人は(2)が得意だけど(1)と(3)(入り口と出口)が苦手なイメージ
  • 参考文献: 素人のように考え、玄人として実行する
  • 読んでもらえることが論文の価値
  • どの組織に勤めているかは仮の姿 真の姿は人のつながり
  • 同じ環境に長くいすぎると幅を狭めるかも

楽天 技術研究所 安武さん

  • テーマ: インターネットを軸にアカデミアをつなぐ
  • 研究者になりたかったが会社が急成長しすぎて運用で手一杯
  • 参考: 大学への数学
  • 少し余裕が出てきたので技術研究所を作った
  • ハコだけ用意して何をしてもいいよ、はうまくいかなかった
  • 所長として森さんを迎えて、ビジョンを決めたら回り始めた
  • 研究者は運用の部署のとなりにいる
  • 実サービスに結びつくことが重要
  • 社内公募制度があり、異動できる。がんばらないと部下を失う
  • 日本の大学だとインターンシップは1〜3ヶ月が一般的だが、海外だと1年とかはざらにある
  • 日本の大学は密な連携が取りづらい
  • アメリカのほうがさばけていて、教員の副業を認めている大学が多く、協業しやすい

パネルディスカッション

  • ゴールやビジョンの共有は重要 最初にきちんと話し合う
  • 共有できないと「臨機応変」が「朝令暮改」になる
  • 優秀な人が集まればいいというわけでもない
  • 会社に誘うということは研究者の人生を左右しかねないが、最終的には本人のリスクなので、その人の人生を背負うみたいなことは考えすぎないようにした
  • 企業の研究に個人名が入ってないことが多い
  • 有名になりすぎると辞めちゃう?
  • 成功にリソース(お金、工場)が果たす役割は低下しつつある
  • 個人にフォーカスする時代 (安いPC、クラウド)
  • IBMは一人会社が何十億もできるかもと言っている(IBMの希望・都合もあるかもしれない)
  • 企業の意義が薄れているかも
  • そうはいってもフリーランスの場合はcompetitorでもあり運命共同体ではないので、同じ会社の仲間は重要
  • 国を越える手段ではある

感想

研究所の運営者がこれだけ集まるというのはなかなかない貴重なイベントだった。仮題は「研究所の作り方ワークショップ」だったらしく、研究所を運用するには、または、研究者として生きるには、という話だったのだが、研究職でなくても当てはまる部分はあったと思う。全体として、よい環境を作るということは、本分を追究することと同義なのだなと感じた。
一昔前は技術者はメーカーが囲い込んでいたので、こういうイベントというのは学会くらいしかなかったような気がするが、終身雇用が崩れて転職が珍しくなくなり、色々な働き方が増えてきた中で、働き方を共有するというのはすごくいいテーマだと思った。

サンタのためのコードゴルフ

CodeIQアホな素敵な企画をやっていたので参加。
1回目の「最短コードを書く!」は円状のアスキーアートを出力する問題。
2回目の「もしもエンジニアがサンタだったら」はツリー上のアスキーアートを出力する問題。

1回目に提出したコードはこれ(75文字)

for(w='',x=y=z=40;y+z;)w+="-*\n"[x+z?0|x*x--+y*y<900:(x=z,y-=2,2)];return w

2回目に提出したコードはこれ(215文字)

for(a=c=k=y=t=z='',b=[],i=h=40;j=y%8+y>>1,r=(a+k)*k*49999-5537&65535,v=r%38-y+1,w=r%78-h+i+1,a<4;)
h+i?k++<160?z=v*v+w*w<2?v?4:w?2:6:z:(c+="_%--||**"[z|i*i--<j*j],k=z=0):
(i=h,++y<h?c+='\n':(b[a++]=c,c=y=''));return b

ゴルフといえばPEゴルフしかやったことなく割と初心者。
1回目は最短タイ、2回目は5位でなかなか楽しめた。

オフラインイベントにも参加してきた。全員がサンタ帽かぶってコードゴルフしてる横でへそだしサンタと写真撮影という愉快なイベントだった。ここではドーナツ状のアスキーアートを出力する問題が出題されてこれを回答。

for(h=x=y=48,r="";z=x*x+y*y,h+y;)r+=h+x--?z<256?2:0|z<1024:(x=h,y-=2,"\n");return r

83文字で制限時間内ではトップだったが、すぐ縮みそうみたいな5位っぽさを発揮してきた。その後twitterで@notfuncさんが縮めてくれたので、それを77文字まで縮めた。

for(h=x=y=48,r="";h+y;r+=h+x--?!z+(z<4):(x=h,y-=2,"\n"))z=x*x+y*y>>8;return r

出題者の柳井氏が詳細に解説してくれたが、JavaScriptコードゴルフはなかなか奇天烈だったのでメモ。

  1. 2重以上のforループは1重に変換できる
  2. カンマでつなげばforの中だけで処理できる
  3. 演算子の優先順位とにらめっこ
  4. ifを3項演算子
  5. ビット演算子は短いので有用
  6. 59999≡-5537 (mod 1<<16) ※ ビット演算だと余りが必ず正になる

〜 この辺からJavaScript

  1. セミコロンは省略可能なことがある
  2. varをつけない代入文でグローバル変数が作れる(=短い)
  3. 色んな場所でグローバル変数が作れる
    例: a=[i=4]
  4. 型が異なるもの同士の演算は暗黙の型変換が行われる
    例: 文字列に数値100を足すと、'100'が足される
  5. 数値でないものを数値として扱うとゼロ(初期化や評価に使える)
    例: a='',++a → aは1
  6. Booleanは加減乗除やビット演算すれば数値化できる
    例: c+="ab"[0|a==b]
  7. ビット演算で浮動小数点を整数化できる
  8. 素数1以下の配列は数値として扱える(これは驚き...)
    例: a=[4],a+=1 → aは5

柳井さんありがとうございました。
JavaScript面白い!