Vim Advent Calendar の19日目です。昨日はyoshikawさんのサーバ管理に役立つVim技10選でした。
さて、@modsoundさんの記事、Vimmer名刺を持ってVimConfへ出かけよう に触発されてvim-splashの可能性を最大限に引き出す使い方を提案します。
Vim Advent Calendar の19日目です。昨日はyoshikawさんのサーバ管理に役立つVim技10選でした。
さて、@modsoundさんの記事、Vimmer名刺を持ってVimConfへ出かけよう に触発されてvim-splashの可能性を最大限に引き出す使い方を提案します。
いままでのビムに足りなかったもの、それは…
携帯端末との連携手段だ!
というわけで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!のストレステスト協力
代表者挨拶の準備・手続き
代表者挨拶の打ち合わせ
最悪の失態を未然に防止
写真のご提供
この方々の協力なくして、今回の成功はありませんでした。 協力してくれた皆さん、本当にありがとうございました!
写真を掲載しました。 写真を提供してくださった広報部の皆様、大月さん、ありがとうございました!