いままでのﾋﾞﾑに足りなかったもの、それは…
携帯端末との連携手段だ！
というわけでvim-QRCodeつくりました。 QRCodeが新しいタブとして作成されます。
neobundle などのプラグイン管理ツールでインストールするとよいでしょう。
gem install rqrcode でインストールしてください。
コマンドを叩くだけです。なお、140文字までという制限があるのでご注意を：
:QRCode https://twitter.com/orga_chem
範囲選択後に下のコマンドでもOKです：
:'<,'>QRCode
いやこれほんと、誰得…
Vim Advent Calendar 2013 のトップ絵を描きました。 ひさしぶりのお絵かきです。
VimGirl のデザインは@IMAGEDRIVEさんの VimGirl ver.7.3 をお借りしました（背中の部分は資料がなかったので想像で描きました）。ところどころに散りばめられた蛍光色のワンポイントがかっこよいのですよ！
この絵には、いくつかこだわりの小物を3つ登場させています。 どれだかわかりましたか？
続きを読むメールアドレスのルールのまとめ系のサイトの内容が間違っています。 なので、この類のまとめは安易に信じないように 、という注意喚起をしておきます。
twitterやはてブをみていたところ、「ユーザーへの啓蒙という観点ではまとめの内容間違ってない」というご意見をたくさんいただきましたので、補足をしておきますね。
どうも「ルール」と「トラブルを避けるためのガイドライン」が混同されているように思います。まとめで紹介されている内容がユーザ向けの「ガイドライン」なのであれば、「+ 記号使わせてよ」ぐらいしか文句はありません。
ですが、ほとんどのまとめは上記の内容を「ルール」として説明しています。ひどいものにはRFCに基づいてまとめを書いたようにミスリードさせる記事もありました。このような現状を憂い、このような記事を書いたのです。
そもそもこれに気づいた発端は@kusano_kさんのつぶやきです。
間違っている。ここの出典は何なのだろう？"・次の文字は原則として使用できない。/ ! “@ # $ % & ‘ ( ) = ~ | \ ^ : ; * + ? < > , ` [ ] { }"大丈夫？実は知らないメールアドレス…URL
ググってみたところ、上位陣のサイトの内容は 軒並み間違っていました 。これは由々しき事態です。
内容が間違ってる検索結果の上位陣はこちら。
（2013/11/27：曝すことが本意ではなかったので削除しました）
そして、間違っているのはこの部分です：
- 次の文字は原則として使用できない。
/ ! “@ # $ % & ‘ ( ) = ~ | \ ^ : ; * + ? < > , ` [ ] { }＠の直前には英数字しか使えない。.（ドット）、_（アンダースコア）は2つ以上連続してはいけない。- メールアドレスの最初の文字は英数字しか使えない。
正しくは：
半角の英数字記号であれば使用できない文字はない
ただし一部の記号（( ) , : ; < > @ [ ] " \）を含める場合には @ よりも前の部分全体を " で囲む必要があり、特に " と\ を含める場合には、直前に\ を配置しなければならない。
@ の直前には英数字・記号（! # $ % & ' * + - / = ? ^ _ ` { | } ~ "）が使える
ただし " を使う場合には、先頭にも " を配置する必要がある。
@ の前の部分全体を " で囲んでいない場合は . を連続させてはいけない
メールアドレスの最初の文字は英数字・記号（! # $ % & ' * + - / = ? ^ _ ` { | } ~ "）が使える
ただし " を使う場合には @ の直前にも " を配置する必要がある。
RFC5322 に書かれているメールアドレスの仕様を引用して、それぞれの項目を解説していきます。
続きを読む「GitHub トレーニングチームから学ぶ Git の内部構造」に行ってきました！Gitの中・上級者向けの素晴らしい勉強会でした。おもしろかった！
今回の勉強会で一番面白かったのは、「とりあえずコミットをしろ。そうすりゃあとでなんとでもなる」です。git reset --hard によって消えたはずのコミットが git reflog から復元できるなんて目から鱗でした。現在の変更を破棄したい場合でもとりあえずコミットしておけ、という教訓の意味がやっと分かりました。
末尾に勉強会のノートを添えておきます。 このイベントは、その場で図を書くような説明などアドリブが多く、とてもわかりやすかったのですが、まとまった資料を貼るのが難しそうな発表でした。したがって、資料は公開されないかもしれません。とすると、このノートはいまのところ唯一の資料です！
ちなみに、会場の様子はこんな感じでした。勉強会の後の DrinkUp も最高でした！ベルギービールのHoegaardenや、アイルランドビールのKilkennyうまー！！
昨日、株式会社ミクシィの内定式でエンジニア代表として挨拶をしてきました。挨拶の場で披露したリアルタイムフィードバックアプリpiine!開発の舞台裏を紹介します。
内定式の2週間ほど前に代表挨拶の打診があり、私はチキンなのでかなりビビりました。しかし、最終的には引き受けることに決めました。決心の理由は2つあります:
特に後者が重要で、リスクコントロールができそうになかったら引き受けていませんでした。 そして、リスクコントロールのための小道具のひとつが「piine!」です。
リスクコントロールには2つの戦略があります。ダメージの発生確率を抑えること、ダメージを軽減することです。この2つの戦略をどのように取り入れたかを見ていきます。
まず、自分にありえそうな失敗をリストアップします。今回は2つ考えられました。
前者は練習でなんとかします。ダメージの発生確率を抑える戦略です。 後者は挨拶の原稿をよく練ることでダメージの発生確率を抑えることもよいですが、会場の雰囲気など制御しづらい因子が作用することを忘れてはいけません。最高に考え尽くされた原稿が、会場の空気からなんとなくずれてしまうことはありがちです。そこで、ここから先はダメージを軽減する戦略を採用します。
自信満々な態度で挑んで玉砕するのは最悪のパターンです。なので正直にビビってることを白状します。この方がハードルが下がり、受けるダメージが少なくなります。ということで、内定式の日よりも前に、挨拶を聞く立場の人達にビビってることを白状しておきました。
挨拶は喋ることしかできないかというと、実はそうではありません。挨拶以外にも、いろいろと小道具を用意することができるはずです。それなりに手間をかけたことが見て取れる小道具であれば、挨拶が滑ったしても悪くは思われないものです。
そして、今回の小道具こそ「piine!」でした。
「presentation iine!」の略で、ピーネと呼びます。挨拶を聞いてる人がスマフォのpiine!アプリを通してリアルタイムに「共感」の気持ちを伝えられるようにするために開発しました。 操作は一つしかありません。piine!アプリ開いて画面をタップするだけです。強い共感の場合は連打で表現できます。すると、プロジェクターの画面にあなたの共感がリアルタイムに投影されます。
技術的なこだわりについては、また次の記事で。
さて、挨拶が終わってみて、これらの戦略がどのような結果をもたらしたかをまとめてみました。
ダメージの発生確率を抑制
よく練習 → 成功
喋る内容の順序は変わってしまったものの、大筋は外れませんでした。 繰り返し想起する練習を続けていた成果です。
原稿を練る → 成功
無難な内容でまとめていったため、期待通り難はありませんでした。
ダメージを軽減
ハードルを下げる → 不発
ビビっている事実を白状する投稿にリーチした人の数が多くなかったせいか、あまり効果を感じませんでした。
抱き合わせ商法 → 成功
エンジニアから見てもそれなりに手のかかっている代物に見えたようで、評判は良かったです。
まとめてみると、ダメージの発生確率を下げる戦略の方がよく成功したようです。 練習は無駄にならないということかもしれませんね！
代表者挨拶にあたっては様々な方が協力してくださいました。
サーバー提供
piine!のストレステスト協力
代表者挨拶の準備・手続き
代表者挨拶の打ち合わせ
最悪の失態を未然に防止
写真のご提供
この方々の協力なくして、今回の成功はありませんでした。 協力してくれた皆さん、本当にありがとうございました！
写真を掲載しました。 写真を提供してくださった広報部の皆様、大月さん、ありがとうございました！
パスワード管理ソフト「1Password」のiOS版（¥1,600）とMac版（¥4,300）を購入しました。今までは人力でパスワードを管理していたんですが、もはや 限界を感じていた のです。今回の記事は1Password運用の勘所と限界を書きます。
パスワード管理ソフトは上手に使わないと、むしろ不安全になります。運用の勘所を書いておきます。
マスターパスワードはなるべく強いものを選びます。覚える必要があるパスワードは1つだけなのですから、難しくはないはずです。ただ、単に強くすればいいと良いわけではなくて、入力のしやすさも考慮してあげなければいけません。 マスターパスワードは頻繁に入力するものです。入力しづらいものを設定してしまうと負担になるので、パスワードをコピーしたままにするといった不安全な運用の種になるのです。 私は入力しやすくて強いパスワードをつくるために、以下の項目に気をつけています。
1029475、Better: 12~OMg8）^や|、¥など）を含ませる（NG: 145kasfje、Better: ^14kasfje）61937Gring、Better: 61Gring937）MyBirthday1231、Better: 4hllo_$WO）123qwer、Better: 312werq）AospqMnw、Better: AqwMpno）A、Z、Sを含めない（NG: 108XAF.+k、Better: 108XKF.+k）1.K@a7d.S、Better: 17.@aKdS）連続する大文字にA、Z、Sを含めないのは、iPhoneなどのタッチデバイスでShiftキーを押したままA、Z、Sを入力することが困難だからです。
当然の話ですが、パスワード管理ソフトの外にもパスワードが保存されているようでは意味がありません。 ログインの度に、いちいちダイアログが出てくるのもうざいので、思い切ってオフにしてしまいましょう。
また、ブラウザのパスワード保存をオフにしても、よくあるログイン画面の「保存する」チェックをオフにしてログインするようにします。この仕組みはCookieを使っているので、ブラウザのパスワード保存機能とは関係なく動作してしまうからです。
パスワードを新規に保存するときには、その度にパスワードを生成するようにしましょう。 これによって、パスワードの使い回しを狙った攻撃（リスト型攻撃）を防御できるようになります。
生成されたパスワードは覚える必要性が小さいので複雑で強度の高いものにします。 16桁程度で数字x3、記号x3（出現頻度の低い記号含む）ぐらいでよいと思います。
再発行されるパスワードのメールアカウントの安全性についてはかなり盲点な気がします。 攻撃の手順を考えてみると、パスワード再発行はかなり危険であることがわかります。
大惨事になることは容易に想像がつきますね。しかも、これらの攻撃は素早く終えることができるので、被害者が対処できる時間は長くありません。いったんメールアカウントが奪取されてしまうと、ユーザーには対処する術がないのです。 しかも、パスワード管理ソフトはこの手の攻撃に対してなんら効果がありません。メールアカウントを厳重に保護するほかないのです。
再発行されるパスワードを受信するメールアカウントの認証は 特に厳重 にしましょう。
保存されたパスワードは暗号化されていますが、時間をかければ解読できるものです。 GPUによるオフライン攻撃は高速化の一途をたどっていますから、パスワードが保存されたファイルはなんとしてでも守らなければなりません。二要素認証はよい方法のひとつです（Dropboxで二要素認証を使う）。ただし、二要素認証ではストレージサービスの事業者側からのパスワードファイル流出を防げません（実例があります：Dropboxでセキュリティ障害--一時的にパスワード不要のアクセス可能に）。パスワードファイルを端末内に留めておくことが一番よいのです。同期をするのなら、それを承知の上で、ということですね。
保存されたパスワードを同期するときには、認証を厳重にするようしましょう。
パスワード管理ソフトにも限界があります。
また、二要素認証にも限界があるので過信は禁物です（さらにDropboxの二要素認証に回避方法が報告されているようです）。また、二要素認証を使う場合には復旧できるようによく配慮しておく必要があります。Gmail+二要素認証の場合は、アカウント復旧の設定で代替の電話番号などを登録しておけばよいでしょう。
