Blogスマートフォン用の表示で見るスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。Blog2017-01-102016年振り返りと2017年に向けて考えている事あけましておめでとうございます。気がつけば2016年もあっというまに過ぎ去り、2017年になりました。新年明けたばかりで良い機会なので、2016年にどういう事をしたか、どういう事を考えていたかを振り返った上で、2017年に何をしていきたいか考えてみたいと思います。2016年の仕事の振り返りまずは仕事面での振り返りです。僕は2015年4月から新卒のソフトウェアエンジニアとして働き始めたので、2016年は2年目として過ごす事になりました。取り組む内容として「ソフトウェア開発というアプローチで『サービスを作る』」という部分は変わりません。2年間働いて積み重ねてきた事の結果として、取り組む内容や責任を持つ範囲が広がった様に思います。2016年に取り組んでいたのは、主に「新規サービスの立ち上げ」や「小さく始まったサービスをリニューアルして本格的に始動させる」といった事で、エンジニア2人程度の小さなチームではあるものの、「チームのリーダー」として働く様になりました。ここで「チームのリーダー」と表現したのは、サービスを開発するチームの技術的選択と人事的な評価に責任を持つのが求められる役割で、いわゆるテックリード+エンジニアリングマネージャーみたいなポジションです。経験なのでどんなものかと思いつつ、最近はこの辺の話題がRebuild.fmのおかげでいろいろ盛り上がっていて参考になる情報も多かったので、手探りながらも取り組んでいました。その他、弊社では会社の文化として「サービスの成長の為の"取り組み"にもエンジニアが責任を持つ」様にしているのですが、そこにはいつも難しさを感じています。弊社では、開発する機能や施策の決定、その効果に対してエンジニアが責任を持ち、サービスの成長を評価するための数字を目標として設定します。このあたりの取り組みは、過去に別のブログにもまとめました。目標に向けてのアプローチを自分で考える為、やりがいや責任感を強く感じる一方、より良い取り組みは無いだろうかと常に頭を悩ませる事にもなります。アイディアなども重要になって来る上に正解は無く、自由と責任はセットだなーと常に感じています。「意思決定」という言葉はよく聞くものの、それに伴う「責任」について最近は考える様になりました。2016年のプライベートの振り返りプライベートを振り返ると、2016年はずっと本を読んだりコードを読んだりしていた様に思います。Moritaさんという方を勝手に一方的に尊敬していて、彼のブログやツイート、Podcastでの発言をいつもありがたく読んだり聞いたりします。ep127に置ける「実装のアイディア(最適化のアイディア)はOSやプログラミング言語、RDBみたいな昔から研究されてるソフトウェアの実装から盗める」発言を聞いて以来、コードを読むことに対するモチベーションが増しました。これが、本を読んだりコードを読んだりする事に専念していた主な理由の様に感じます。備忘録も兼ねて、2016年に興味を持ったトピックをリンク付きでまとめて見たいと思います。microscopeなど)を読んだりしていました。Haskelを写経してみたり、8ccのcommitを最初から追いかけて写経してみたりしていました。JSONやSQL、汎用プログラミング言語などソフトウェアの至る所でParserは必要になる(情報を表現するにはその情報を表現する為のフォーマットとそのフォーマットから情報を取り出せるParserが必要になる)ものの、ほとんどの場合には既存の実装を用いて済ましてしまう為、自分で興味を持たない限り「どう実装されてるかを知る機会が無い」と感じていました。重要性の割に、自分はちゃんと仕組みを理解してないと感じたのです。yaccの文法は昔勉強した事があったのですが、「yaccの使い方」が分かっただけで、内部で何をしてるか、あるいは他の方法が無いのかなどが気になってました。いう訳で書籍を読んだりコードを読んだりしてた訳ですが、結果として自分の中で知識が整理されて、すごく良かった様に思います。「文法」と一言で言っても、その文法のParserの作りやすさ、実行時間はその「文法」に依存します。文法が許すなら、LL(1)再帰下降Parserの様な「入力文字列長に対して線形の実行時間で処理できる」Parserを作ることができます。自分で書く事も簡単にできます。僕の実装はmatchの判定しかしない&色々バグはあるんですが。)一方、複雑な文法になると「固定長先読み再帰下降Parser」では次にmatchする文法規則は決定出来ず、matchを試して失敗したらバックトラックしてまた別の文法規則でのマッチを試して、、、といった動作が必要になります。増大し、実装も複雑になります。その為、文法をどう設計するかはparserの実装に対して重要な意味を持ちます。combinatorなどのライブラリを利用したりします。)を利用したりも出来ます。generatorが何をやってるか、また自分でparserをイチから書くならどう書くか、parseが簡単な文法というのはどういったものか、parserを書く為に利用できるツールやライブラリにどういったものがあるか、といった事について自分の中で知識が整理されたので、スッキリしました。すごく勉強になりました。オートマトン理論ベースの実装とVMベースの実装の概念とコードがどちらも詳しく解説されていて、読むと正規表現エンジンに対する理解が深まりました。計算理論の話Parserや正規表現エンジンの勉強をしていたらだんだんオートマトンやチューリングマシンに対してしっかりした理解をしておきたいと考える様になり、一時期計算理論の基礎を読んでいました。個人的に一番良かったのは非決定性に対する理解が深まった事だと思います。以前までNPの説明がイマイチピンと来てなかったのですが、非決定性チューリングマシンの動作やツリー状の探索パスがイメージできる様になった事で、しっくり来る様になりました。仕事をする様になると「大きなコードベースに触れる機会」が増加し、コードを整理して「変化に強い状態を保つ重要性」を実感する様になりました。その為のテクニックには様々なものがありますが、特に同僚にオススメされたオブジェクト指向のこころという書籍が「デザインパターンというアプローチで変化に強いシステムを作る方法」を大変わかりやすくまとめていて、良い本だなーと思いながら読んでいました。個別のパターン以上に、「インターフェース・集約の利用、流動的要素のカプセル化」みたいな原則とその理由がまとまってるのが良かったです。Concurrencyムーアの法則の終焉が噂される現代において、Concurrencyの重要性は高まり続けています。理解しておきたいと考えて、Concurrencyにも興味を持っていました。実現しようと考えた時、最も一般的な方法はthreadを利用する事です。threadと違いカーネルにschedulingされるthreadという意味でこの用語を用いています。Unixであればpthreadを意味してます。)の利用が必要で、pthreadの利用方法についてインターネットサーバでのPthreadとepollやPthreadsプログラミングを読んだりしていました。scheduler)を読んだりもしてました。どちらもカーネルthreadをうまく利用してマルチコアを活用してくれるので、とても便利な道具だと思います。programmingの複雑さに生身で立ち向かうのは辛いので、これらの抽象化はうまく活用したいです。Architecturesの5章が良い感じにまとまっていました。通して読めてはいないですが、興味深いと思ってます。分散システムコアレベルでの並列化に加えて、マシンレベルでの並列化の重要性も高まっています。計算リソースの確保という意味ではHadoopやSparkが、またデータベースの地理的な分散や可用性の確保、書き込みのスケーラビリティの実現という意味ではCassandraなどがオープンソースの分散システムとして注目されていると思います。自分はkuenishiさんのブログを読んで分散システム自体には興味を持っていたものの、具体例を知らないためにイマイチ理解できていませんでした。そこで一念発起してCassandraを読んで見たのですが、これがとても良い本でした。いった用語の明確な定義(読み込み時に、最新の書き込み結果を反映している事を保証するかどうかが違う)、CAP定理が意味する事、Cassandraがネットワーク分断時にどういった動作をするのか、コントロール可能な一貫性とはどういう事か、そういった事について理解を深める事ができました。立ち向かっているかについての理解でもあって、具体的な例を知れたのはとても良かったです(今後、別のシステムの説明を見たときの比較対象になるので)。ちなみに、Cassandraは他のNoSQLや内部の細かいアルゴリズムの説明もしたりしていて、内容がとても充実していたのも魅力的でした。その他、興味深かった本Unix考古学という本を気まぐれで読んでいたのですが、これがかなり面白かったです。UnixやC言語が生まれる時代的背景も興味深いですし、Unixベンダーが1980年代後半に争っていた話なども噂でしか知らなかったので面白かったです。創造するちからという本もかなり良かったです。これは、ピクサー、ディズニー社長のエド・キャットムルが映画制作というクリエイティブな作業を行うチームをどう作りあげてきたか、またどういう取り組みをしてきたかをまとめた本なのですが、エドが「常によく考え続けてる」ことを強く感じる本となっています。個人的に強く印象に残ったのは、「ピクサーで作られるどんな映画も、作り始めた段階では例外なく駄作」という話です。彼らは毎回挑戦をするからこそ最初はひどい出来で、しかしそこから何度も何度も修正を加え続けるからこそ「素晴らしい映画」を作り上げられる事、それを経験からくる実感と共に語っているのが興味深かったです。映画制作の最中には「どうしようもないと行き詰まるタイミングが必ずやって来る」というのも、それを何度も経験して乗り越えてきたからこそ言える事だと思います。その為のプロセスを確立していて、プロセスやチームを信じられるというのもすごい話だと思いました。2016年振り返りまとめと2017年の取り組み2016年は「知りたい事、興味のある事についてちゃんと理解を深めよう」と思って過ごしていました。それはそれで学ぶことが多くて良かったのですが、一方で本を読んだりコードを読んでそのまま満足してしまうケースが多すぎた様に感じています。2017年は、コードを書く事、特にそれをpublicにする事を強く意識していきたいと思っています。OSSへの貢献などは、興味がありつつも全く出来てない分野なので、取り組みたいと思っています。仕事面では、取り組んでる内容に習熟することに加えて、「責任」というものとの付き合い方にも慣れていきたいと思っています。僕は技術書を買ったり読んだりするのが好きです。昨年4月からソフトウェアエンジニアとして働き始めて、学生の頃に比べると経済的に余裕が出来たため、技術書を買うペースが飛躍的に上昇しました。自分でも何を持っているのか、何冊持っているのかが分からなくなってきていたので、リストアップして数えてみました。数えた結果2015年、2016年に買った本は105冊でした。思ったよりも多かったです。並べてみるとなかなか面白くて、同一ジャンルのものも何冊か買ってます。同じものについての説明でも別の観点があったり、あるいは説明の分かりやすさ自体が異なったりするので、個人的には意味があるんじゃないかと思ってます。積読もあるので、今後も読み進めて行こうと思っています。~Rubyの実例から学ぶ。07:512015年、2016年に買った技術書105冊listTweetもっと読むコメントを書く2016-12-12「題名だけ知ってた小説」を読み始めた突然ですが、先週くらいから「題名だけ知ってて気になってた小説」を読み始めました。きっかけはテッド・チャンの「あなたの人生の物語」というSFです。これはSFの短編集で、特に理由もなく気まぐれに買ってみただけなのですが、普段全くSFを読まない自分でも面白く感じられました。「もしかしてSFって面白いんじゃないか」と思い、その勢いで他の「題名だけ知ってて気になってた本」も買い始めた次第です。4冊くらい読んだので、ちょろっと書評を書いてみたいと思います。ネタバレは無い方が良いと思うので、本当に簡単な感想です。あなたの人生の物語8つの短編が載っているSF短編集です。どれも興味深い世界観であり、それが「ただ現実に起きたことを記述しているだけ」の様に描かれています。毎話、「次はどんな世界の日常が描かれるんだろう」とワクワクしながら読めました。実は、最初の1編目を読んだ時は楽しみ方が分からなかったんですが、途中から「描かれた世界観そのものを楽しめば良い」んだと気がついて、それからグッと面白くなりました。自分も著者のテッド・チャンと同様に「物理」と「コンピュータ科学」がバックグラウンドにあるので(大学院まで物理を学び、コンピュータ科学は独学&仕事で触れているので)、「知識として知っているもの」や「知識として知っているがテッド・チャンとは解釈が違うもの」なんかが出てきたのも楽しめたポイントでした。その他のレビューサイトでかなり評価が高く若干自分の中のハードルが上がっていたのですが、それをきちんと超えてきてくれた様に思います。幼年期の終わりSFの古典として有名な本です(古典というと怒られるかも。書かれたのが1953年なので、そこまで古くはないです)。実は粗筋は知っていたのでストーリーに驚きは無かったのですが、個人的には「高い知性」というものの描かれ方が興味深かったです。「高い知性」をどう記述するかという事については、「全てがFになる」という本を読んだ時もちょっと考えたので、後でまとめて考えを述べたいと思います。アンドロイドは電気羊の夢を見るか?1968年に書かれたSF。タイトルにやけに聞き覚えがあって、内容を全然知らないまま買いました。どこでタイトルを聞いたんだろう?この本は、描かれる世界観がかなり自分好みでした。調べてみたら、著者のフィリップ・K・ディックが「個性的な世界観」で有名な人みたいです(昔映画で見たマイノリティ・リポートなんかもこの人の作品でした)。自分は、どうも「自分が今持ってる常識や自分の世界に対する捉え方」と全く異なった"常識"が描かれる事に、面白さを感じる様です。何が正しいか分からなくなる感覚を味わったり、「あり得たかもしれない別の物語」を想像したりして、なかなかに楽しめました。すべてがFになる森博嗣という日本の作家さんの本です。SFではないですが(分類するならミステリ)、ずっと気になってたので読んでみました。自分が理系の学生として大学、大学院を過ごしているので、描写を見て色々懐かしい気持ちになりました(年1回の研究室旅行の事や、研究所で実験をしていた頃の事を思い出しました)。著者は大学で助教授を勤めていたらしく、大学運営の手続きを揶揄する描写は「自身の本音を書いてる」様に感じたのも面白かったです。実際、大学の教員の仕事の量は壮絶だと思うので。(自分の研究室の助教も大変そうでした)お話も面白かったですし、登場人物が魅力的でした。犀川先生は良いですね。この本でも、「幼年期の終わり」の様に「高い知性」というものが描かれます。その描かれ方がちょっと違っていて、そこも興味深い点でした。「高い知性」についてここで、ちょっとだけ「高い知性」について考えてみたいと思います。人は、どんなものを「高い知性」と考えるのでしょうか?また、普通の人間の知性では理解が及ばないほどの「高い知性」というのは存在し得るのでしょうか?高い知性の描写には色々な形があります。膨大な知識量、高い記憶力、素早く広範囲な言語習得、甚大な語彙力、圧倒的な計算速度、そして常軌を逸した思考回路。いったものを目にした時、人々は「知性」を感じるようです。「知性」を感じるのでしょうか?1つの仮説としては、「自身に出来ないこと」が出来るのがポイントかもしれません。自身では一生かかっても獲得できない様な知識量を持つ人物を目にしたら、きっと僕も「高い知性を持つ人」だと感じると思います。上記に挙げた「普通の人の延長線上にある知性(量的な変化によってもたらされる知性)」だけでなく、「質的に異なる知性」というのも存在するかもしれません。それは、そういったものを目にしてない僕には想像もつきませんが、その存在を否定する事はできません。これはざっくりいうと「量的な変化が質的な変化をもたらす」みたいな意味合いなのですが、適用範囲が幅広い上に納得感があり、さらに現実に起きていることを言い表していて、自分の好きな言葉です。今回のケースにも当てはまるかもしれません。)書評からは脱線しちゃいましたが、「高い知性」の描写には作家ごとに個性が現れるので、なかなか面白いと思います。まとめという事で、最近「題名だけ知ってて気になってた小説」を買い始めたという話でした。物語自体を楽しめますし、「気になってたことが分かってスッキリ」する感覚も味わえたので、やってよかったと思います。「買ったけどまだ読んでない本」と「これから買おうとしてる本」についてとりあえず、題名を知ってて目についた本を買ったり欲しい物リストに入れたりしてます。大体以下の様な内容です。09:25「題名だけ知ってた小説」を読み始めたlistTweet広告を非表示にするもっと読むコメントを書く2016-11-19「HACKING」や「Linuxカーネル2.6解読室」など、最近の「買って良かった技術書」について「技術書の積読は悪いことでは無いと言いたい」という前回のブログにも書きましたが、自分は適当に技術書を買う事が多いです。south37.hatenablog.comその中でも、最近自分の中で「当たり」だったものについて簡単に紹介してみたいと思います。HACKINGまず、期待値の割にすごく良かったのが、「HACKING」という本です。この本では、様々なパターンの脆弱性が豊富なコード例とともに解説されています。いうページでこの本の存在を知りました。気になっていたもののそれほど期待していなかったのですが、詳細な説明とともに実践的な(?)脆弱性攻撃の手法などが載っており、内容がものすごく充実していました。バッファオーバーフローについて、自分は最初は「バッファオーバーフローぐらい知ってるぞ」などと調子づいていたのですが、それを実現するための鮮やかな手際、環境変数を利用したスマートな攻撃方法、はたまたシェルコードの説明やシェルコードを自作する方法まで載っていて、自分の知らなかった情報が詰まっていてすごく面白かったです。「root権限で動くprocessに脆弱性があるとすごく危険」という事実も、知識としては知っていたものの、実際に「脆弱性を突いてrootでshellを立ち上げるコード」を目にすることで「実感」を持つことが出来るようになりました。Linuxカーネル2.6解読室また、別の本で買って良かったなーと思ってるのは、「Linuxカーネル2.6解読室」という本です。これは「明倫館」という神保町の古本屋で買ったもので、完全に「ちょっと気になったから適当に買ってみた」ものでした。古本だから新品で買うより安くて、お得に感じたのも買った理由の1つです。実は、自分はLinuxやBSDのカーネル本を他にもいくつか持ってるのですが、それらはあまりモチベーションを保って読み進められませんでした。「Linuxカーネル2.6解読室」も積読されちゃうかもなーと思ってあまり期待してませんでした。ところが、この本はすごく読みやすくて、モチベーションが尽きることがありませんでした。3のメモリ管理周りをつまみ食いしてる感じです。)この本が自分にとって良いと感じたのは、「コードと説明のバランスが良いから」かもしれません。カーネルの説明というと、場合によっては「図による概念の解説」や「パラメータや定数の網羅的な説明」に終始しがちで、イマイチ何が起きてるかイメージしづらかったり、単なる暗記作業になってしまったりします(リファレンス的な本ならそれで良いと思いますが)。ところがこの本では、Linuxカーネルがどういう戦略でどういった機能を実現してるか、またその動作が実際のコードとともに解説されていて、覚えやすいしイメージしやすくなっていました。コード自体もすごく参考になるものでした。ep.127で「最適化手法については、OSの最適化戦略などを知っておくとすごく勉強になる」と言っているのを聞いたからでした。Linuxカーネル2.6解読室は、そういった自分の目的を叶えてくれる本でした。その意味でも、「適当に買って」本当に良かったと思っています。最近の「買って良かったシリーズ」まとめという訳で、最近の自分のマイブームはHACKINGとLinuxカーネル2.6解読室でした。今後も適当に買いながら、たまに面白い本に出会うんだろうなーと思ってます。18:19「HACKING」や「Linuxカーネル2.6解読室」など、最近の「買って良かった技術書」についてlistTweetもっと読むコメントを書く2016-11-19技術書の積読は悪いことでは無いと言いたいいきなり自分語りをしたいと思います。自分は結構ソフトウェア関連の技術書を読むのが好きで、よく本屋で適当に買っては読んだりしています。週に1~2冊くらいは買うので読みきれないものはどんどん積読しています。中に眠ってる本、机の上や棚に積み上げられた本、様々な本が日に日に増えて行くなーと感じています。この積読の是非について考えてみたいと思います。積読は避けるべきこと、悪いことか?「積読は避けるべきこと、悪いことか?」という問について。この問に対しては、いくつかの考え方、答えがあると思います。1つの意見として、「本を買うのはお金がかかるから、積読して読まないのは勿体無い。避けるべきことだ」という考え方もあります。別の意見として、「買わなかったせいで2度と読めなくなる本もある。読む可能性を作るためなら、積読される可能性があろうとも買うべきだ」という考え方もあります。それぞれ、意見は違えど言い分はもっともです。僕自身はどうなのかと言えば、僕は完全に「積読肯定派」です。理由は、自身の経験として「積読しておいて良かった」ことが多々あったからです。僕がどういった経験をして積読肯定派になったのか?一例を紹介したいと思います。僕は技術書を買った時、読まずにそのまま机に置く、あるいは「はじめに」だけ適当に呼んでそのまま放置する事が多々あります。読み始めたらものすごく面白くて止まらなくなって、休日を潰して一気に読んでしまう事もあります(そういった場合、土日で終わらなかったら平日の通勤時間や帰宅後の時間を使って読み進めます)。「適当に買ってみたけどすごく良かったパターン」が、1つの大きな成功事例として僕の中で強く印象づいています。積読になろうとも技術書を買った方が良いと僕は思います。僕が積読を肯定する理由がそれだけかというと違っていて、もう1つ別の理由もあります。それは、「昔買ってあまり読んでなかったけど、読んでみたらすごく面白い技術書だった」という経験があるからです。僕は技術書を色々なところに積み上げていて、手持ち無沙汰になると適当に手にとってパラ見をします。した時、まれに「自分はこんな面白い技術書を持っていたのか」と感動する事があります。それは、例えば「中盤の章に自分がまだ読んでない面白いトピックがあった」ケースであったり、あるいは「自分の知識がついた事によって面白さが理解できるようになった」ケースであったりします。状況は様々ですが、手元にある事によって偶然面白さに気づけることがあります。これが僕が積読を肯定する2つ目の理由です。まとめ自分の考えをまとめてみます。僕は「積読肯定派」、つまり「積読になる可能性があろうとも、ガンガン技術書を買った方が良いと思う派」です。それは、「買ってから面白さに気づく本もあるから」であり、はたまた「積んで置く事で後から面白さに気づける場合もあるから」です。自身の考えをまとめておこうと思い、ブログに書いてみました。18:13技術書の積読は悪いことでは無いと言いたいlistTweet広告を非表示にするもっと読むコメントを書く2016-02-28ブログテーマを変えてみました2016年にもなって心機一転という事で、ブログテーマを更新してみました。いうブログサービスのデザインです。使って記事を書いていて、あまりにカッコよかったのでついつい真似してしまいました。パクりみたいになっちゃったのは反省してます。最近は顔出しが流行ってるみたいなのでそこも真似してみました。若干の恥ずかしさはありますが、気にしない事にします。2016年の抱負2016年の抱負を書きたいと思います。新卒として入社して、目の前の仕事を必死でこなしていたらあっという間に1年が過ぎました。若干の焦りを覚えていて、特にアウトプットがすごく少なかったのが反省点だと思っています(このブログも1回しか更新しませんでした)。2016年はブログや発表といった形でアウトプットを増やしていけたらと思ってます。最近のマイブーム最近は、値段が高くて学生時代には手が出せなかった「古典的名著」を買うのがマイブームになってます。ドラゴンブック、赤い悪魔本など、買って満足してどんどん積み上がっていってます。積み上げるだけだと勿体無いので、少しずつでも読んでいこうと思います。わからないしお金無いし。丸2日行ったけど、振り返ってみたらなんだかあっという間だった。さんの話の面白さとトークの完成度の高さが最高だった。http://togetter.com/li/863417「Ruby作者だからRubyをdisれる」とか「Rubyの良くないところはPerlの影響を受けたこと」とか問題発言もぶち込みつつ、言語デザイナーとしての考えとかが聞けたのが良かった。さんは将来的に「ほとんどコードを書く必要が無い未来」が来ると考えてて(1ファイルくらいのスクリプトで考えた事が実現できる未来、おそらく高度に抽象化された基盤の上に乗ってる)、昔は自分もそういった未来が来ると無邪気に考えてたけど今はそう思えなくなってるのを実感した。自分は基盤となるライブラリやフレームワークが全てをカバーするのは無理なんじゃ無いかと思ってる。アプリケーションに必要な機能が作れるけど、Railを外れると自分でガリゴリ実装を書く必要がある。抑えるだけなら出来ると思うし、実際そういった流れはあると思うけど)とりあえず雑にまとめると、言語デザイナーとしての生き方が楽しそうだった。回を聞いてどんな人か気になってたので、話が聞けて良かった。取り上げられてたのはちょっと嬉しかった。決まっててお作法は覚えなきゃいけないけど、簡単な処理をするモジュールくらいなら作れそうに感じた。昔一瞬だけ使ったことがあって、その時は外部プロセスを一瞬起動するみたいな簡単な処理をしただけだったけど、それでもすごく使いやすかったのが印象的だった。Webサーバにスクリプティング環境があるのは、夢があると思う。【特別企画】YAPCあるある(仮)まさにオールスター企画。振り返りトークで、安定して面白かった。RFC化されたから世間的にも注目浴びてるけど)。降ってくるのが速くなってもフロントで詰まる事は全然あって、大きな画像がページの上部に6枚あればそれで簡単にコネクションが占有されてしまうというのが印象的だった。サーバーがどうせ実装する(&ブラウザは既に実装してる)から、素直にみんな使うようになるんじゃないかと思う。著名な人が集まってて、オールスター感がすごかった。みたいなPodcastを最近は聴きまくってたので、そこに出てた人が喋ってるのを見れたのが嬉しかった。これはまあ構造上仕方が無い事ではあるんだけど、面白そうなトークが被りまくってて他の直接聞けないのは悲しいと思った。直接トーク聞いて感じたのはスライドだけでは伝わらないものがけっこうあるって事で(例えばスライドに載せてないけど話してた重要な事とか会場での盛り上がりとか)、よく発表したスライドが公開されてるけどトークの動画も公開して欲しいと感じた。全体として、YAPCが開催されて、こうやってYAPCに行けて良かったと思う。ありがとうございました。Blog|ブログを報告する。