以降でのリリースを目指して、鋭意研究開発中です。野心的な機能が色々と含まれますが、すべてを実装し尽くしてから出すというよりは、部分的に使えるようにして、早くリリースすることを目指しているそうです。つなぐ、安全で、簡単に使える、高速なインタフェースを構築することが大きな目標です。使用を容易にするためのライブラリも広く使われています。つの面で超えることを目指します。よくばりですね!簡単なデモもありました。ライブラリを呼び出します。クライアントコードから触ることができていて、これらのクラス/インタフェース群がすべてコマンド一発で生成されるのだとしたら、かなりナイスです。上回るとしたら......。入った機能も大いに活用して設計されており、たしかにこれならやれるのかも、と期待が持てます。研究開発段階ということで、今後仕様や設計が変わる可能性は大いにあるとのことです。実際、セッション終わりの質問タイムも紛糾しました。つらさを味わうことがちょいちょいあるので、期待したいところです。いうグルーヴィーな登壇者による、並列処理についてのセッション。今後入る予定の新機能についての議論があるかなとも思っていましたが、案外そういうのはなくて、基礎的な内容でした。並列処理についての議論をするという段取りでした。使用するほうが常によい。ループよりも)上だから」。使うのと(細部にこそ違いはあれ)同じなのかなと思います。ループを使うのには十分な正当性、たとえばパフォーマンスのボトルネックであることが特定されているとか、が必要と言えそうです。処理できるよ、という例には目を開かされました。主張はというと、こちらは「並列化するほうが常によい」......ではもちろんなく、必要なときにだけすべし、でした。理由は、「並列化は最適化だから」。並列化はたいてい、メモリ空間と効率(省エネ)を犠牲にして、スループットを向上させるために行います。よって、その費用対効果が十分だと判断できる場合以外には、すべきではありません。並列処理をサポートしています。並列処理によってスループットが上がる可能性があるための条件として、データの数が多く、一件あたりの処理コストも高いことデータの(メモリ上での)局所性が高いこと処理の分割コストが低いこと最終的な処理結果の統合コストが低いこと順序に依存しないことが挙げられていました。美しいリストです......。これらの要素を感覚で判断して決めてしまうのではなく、実データ(少なくとも、それに近いデータ)による実測が必要です。絡む場合は少し変わってきます。よる遅延処理についてのセッション。去年は縁がなく、今年初めて彼のセッションを取ったのですが、さすが期待通りの内容でした。ラムダ式で同じようなことができるよね......、といった具合に、一歩一歩下地を作ります。個人的には、評価した値を再利用するパターンも何か紹介してくれるかなと期待していた(結局なかった)ので、そこにはやや不満もありましたが、全体としての構成と運びが見事すぎて、帳消しになりました。終端処理が呼ばれるまではあくまでパイプラインを組むにすぎず、各種の条件(filter)や変換(map)は終端処理を呼んだ時点でまとめて処理されます。ループで効率的にロジックを組んだ場合とまったく変わらない。いうことを、実際の動くコードで、デバッグプリントも使いながら巧みに説明します。▲なんかペンみたいなやつでパイプラインを示す▲デバッグプリントでどのロジックが何度呼ばれたかを示すどれも既に知っていることなのですが、よく整理された説得力のある説明で、知識が更新され、定着していきます。終盤には無限ストリームを説明し、またリストを返すメソッドをストリームを返すメソッドにリファクタリングすることで、行われる処理の量(実行時間)を大きく削減するというデモも行いました。よる関数型プログラミング』でも説明されている(されていた......はず)のですが、こうして説明を受けることで本当に明日から使える知識になります。ような技術カンファレンスの価値はあります。Architects去年も色々な面白トークを聴くことができたこのセッション。名が登壇して、参加者からの数多くの質問に答えました。Bottle」を歌うなどしていました。別々のスターが同時に二人ステージ上にいる状況に混乱して、少し泣きそうになりました。One)まで気を抜かず、励みます。»プロフィールid:appressoアプレッソのエンジニアが書く技術ブログです。(1)はてなブログをはじめよう!appressoさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。