@941 → @obra → @miyagawa → @naoya_ito → @ockeghem → @fujiwara → @zigorou → @ikasam_a → @overlast → @lestrrat (LT)
今年は講堂に YAPC タイムラインを写すスクリーンが公式に用意されたため、発表者が Growl 起動してなくても Tweet をシェアできるようになった。自分の端末に目を落とさなくても良いのでいいね。機材や場所の制約があって難しいのだろうけど、他の会場にもあると嬉しいな。
Perl 5 が互換性を大切にしていく。コアを小さくしていく。
成熟期に入っているので、膨大な資産が継続して使い続けられることはとても重要な要素。
CPAN モジュールインストール状態の記録と再構築を容易にする Carton の紹介。
6年前とかにこういうの欲しかった。 特にパッケージ製品とか作っていると、動作確認のとれた依存ライブラリ一式の保存と管理が大切。自前で tarball 保存(+ PPM パッケージ作成と PPM リポジトリの構築)をしていた日々が思い出される。
JavaScript のお話。
まだまだソルト健在。レインボーテーブルは発想が賢い。
稼働中のサービスのサーバ移転に関する顛末。
MySQL なお話。
テストフレームワーク・テスト用モジュールいろいろあるね。 浅く広く紹介。
前半は技術開発プロセスに関する雑感、後半は類似文字列検索 Apporo の紹介。
@overlast 氏とは懇親会で話をさせていただいて「うーん、やはり悪徳業者投稿コンテンツの検出はヒューリスティックにやっていくしかないのかな」という点で意見が一致。
いろいろ。
思ったより食えました。
前職で一緒に研究開発をしていた @k12u 氏と再会できて嬉しかった。かわらず元気そうで何より。
「Perlっ!」って話は最初の2本で、後はその他の技術もろもろ。アリだけど個人的にはもっと Perl の話も聞きたーい。
デスクトップ Windows PC 上でメールを送受信している時は社内で POP3 しか提供されていなくても問題なかったんだけれどノート PC をあわせて使うようになったら、こちらでメール閲覧できなくてちょっと不便してた。 POP3 サーバ上に数日残すようにしておいて両方の端末で受信するというありがちなやり方はイケてないのでローカルに IMAP サーバ立てることにした。
今回は母艦が Windows デスクトップ PC なので Windows 用の IMAP サーバからセレクト。
選んだのは hMailServer。
バージョン 4 までは GPL、バージョン 5 以降はオープンソースではなくなったが free product として提供されている。
POP3 サーバからメールを POP してきてローカルのデータベースに保存し IMAP4 プロトコルでのアクセスを提供してくれるサービスとして動いてくれる。SMTP サーバ機能も持っている。データストアとしては MySQL や PostgreSQL なども選択できるが、パーソナルユースなら embedded されている Microsoft SQL Server が使えるので手間いらずである。
実際使ってみたけれど GUI ベースで特に迷うことなく設定ができ、すぐに使い始めることができた。メール関係のサーバを Linux とかで立てる時は結構神経が磨り減るものだがストレスセットアップできた。ローカルにあった MH 形式のメールを数万通 Sylpheed で IMAP 経由でつっこんだけど今のところ順調。いい感じ。
これで OK。
あとは同じホスト上の MUA からは IMAP サーバとして localhost を指定して設定した ID とパスワードで受信設定を行えば OK。 送信については hMailServer を通さずに普通に送信するように設定し、送信したメールを IMAP 上の Sent フォルダ等に保存するようにしておく。
別のノート PC 等の MUA からは IMAP サーバとして hMailServer を立てている Windows PC のホスト名(等接続できる名前)を指定して同様に設定。
これで hMailServer が定期的にメールを POP3 にて受信してくれるので、あとは各 MUA から hMailServer に接続してメールを読めばよい。IMAP なので既読管理やフォルダ管理なども一元的にできる。
その他 hMailServer にはルールを設定して IMAP フォルダ振り分けしたり、迷惑メールフィルタやウイルスフィルタ設定したりできるので、必要なら設定するとよさそげ。
ちょうど1年前に、デスクトップ PC とノート PC の両方でメールを読めるようにと hMailServer で Windows にローカル IMAP サーバを立て(記事)運用してきたんだけれど、もうやめてとりあえず POP3 でおとなしくメールフェッチすることにした。
結局のところノート PC ではあまりメールを読まなかったので、あまりメリットが無かったのが理由の1つ。そしてメイン理由は「性能」。管理しているメール数が多くなるにつれて、Thunderbird 上でフォルダを開いたり既読に変更したり移動したりといった操作がストレスになるぐらい遅く感じられるようになってきた。また大きな添付ファイルのあるメールがあったりする時もかなり遅い。森本さんが「マルチスレッド的な性能が著しく低かった」とコメントくれていたのもうなずける。さっとメール処理をしたい時に仕事にならないのはちょっと困る。
あとついでにいうと、メールを送信するようなコードを書くことがよくあって、テストで自分にメールを送るわけだけど、この構成だと Thunderbird で受信を実行しても駄目で、hMailServer の POP3 フェッチ定期実行待ちをしなければならないというのも不便だったりする(hMailServer の管理ツールから強制的にフェッチを実行させることもできるけどめんどい)。
数少ない Windows 上で動くフリーの IMAP サーバだっただけに性能問題は残念。hMailServer 自体はバックエンドで MySQL を使えたりする(デフォルトでは組み込まれている Microsoft SQL Server)ので、きちんと設定すればもうちょっと速くなるのかもしれない。そこまで手間かけたくないけど。
ここ2回、急用が入ったり都合が悪かったりで聞けなかった 社内 LT に久しぶりに参加。
RubyMotion・Gource・DSP・某コードネームの由来と深いこだわり・OpenStack・MySQL・そして最高技術責任者によるインシデントハンドリングのお話。
特に印象に残ったトークの1つは某コードネーム命名へのこだわりの話。中二病的由来からスタートしつつ、名前空間に現れた時の事を意識して仕上げられた名前だぜ的な。タイプのしやすさは大切だよね。あと愛せるクールな名前かどうか。何年か前に YAPC::Asia Tokyo でパッケージ名の話が上がっていたよねぇ。どのトークだったかなあ。
もう1つはインシデントハンドリングについてのトークで、インシデントが起きたらまず「おちつきましょう」というもの。で(直接の)当事者以外は冷静に支援に回ると。
開発チームで不具合/障害に対応する時は、メインで対応している人は集中して忙しいので、他のメンバが支援に回って迅速なクローズを目指すんだけれど、この時も「おちついて」をもっと意識していけるようにしたいなと思った次第。
いろいろバタバタっとして、コードリーディングしたり mysql コマンドやら hive コマンドやら叩いたり、初セルフ定時外チョメチョメしたりした。
やはり tmux が必要だなあ。1年前に prefix key を C-b から何に変えるかで迷って早1年。
C-t 派というコメントとC-a 派、C-q 派というコメントをもらっていてちょっと迷うところ。
tmux、まず prefix key を C-b から何に変えるかで1週間かかりそう。
— Naney (@Naney) January 30, 2013
昨日の前夜祭から一夜明けての YAPC::Asia Tokyo 2014 1日目。昨年に引き続き慶應義塾大学 日吉キャンパス開催なのでなんとなく勝手がわかってちょっと気楽。去年はなんか多目的教室に入りそびれたので、今回は早めに移動とかしてそちらも回ってみた。
電源の取れる藤原洋記念ホールがなんだかんだいって居心地が良かったりはするんだけれどね。
今日は Go 使ってみようかなと思ったのが収穫。会場でとりあえず golang Debian パッケージをインストールして hello.go ぐらいはしてみた。goroutine 以外は思っていたより普通の言語……なのかな?
お昼は @syamata 氏と @bornite 氏と日吉天神でラーメン。去年と同じ店だった。と思ったら去年は同じ場所で「らーめん 元山亭」という店だった。日吉天神は去年10月7日オープンらしい。 @syamata 氏が最近 Facebook で Yelp のフィード流しているのでモチベーションとか聞いてみたら「アーリーアダプターとして、まだデータにないお店やレビューを登録していくのが楽しい」とのこと。あーわかる。
インフラエンジニアのメンタル的な面に視点を当てたトーク。
Go 使ってみたくなった。
テストフレームワーク関連はできるだけ枯れて安定したものがいいなと思う(テストフレームワークの不具合とか仕様変更まで追いかけ続けなくていいように)。便利さとのトレードオフ。
わりに泥臭い世界なのではと思ったら、やはり泥臭い感じだった(実装的に)。
C スタイル for だって goto だって適材適所なので使った方が良い場面だってあるので、そういうのはきちんと説明できるといいんじゃないかと思う(lint がそこまで判別できたら凄いけど)。
フルフルの汎用モジュール使わないで、軽くて速い機能を削った専用モジュールを作って使うのもいいよという話。
経営的な視点まで入った技術選択の考え方の概論トーク。
MySQL のインデックスを Perl データ構造で擬似的に説明。
フォントかわいいけどコード部分とかちょっと見辛かった。
ビギナー向け。
ハッシュタグ #yapcramen
(画像は http://yapcasia.org/2014/ より)
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。