#ccc_ef3凄いボリュームですww。この人全部話すつもりないだろうwwって思ってました。時間がない割に、小ネタも挟んでくるしw。スムーズかつ分かりやすい説明で最後まで説明して頂けました。Reactiveについてはまだまだ理解できていないことが多いですが、この発表でだいぶと理解が進んだように思います。周りより1年早く先を行くmakingさんの発表ですね。機能豊富なオープンソースJavaコレクションフレームワーク伊藤さんの発表です。Collectionsになるということで、もう一度復習したい気持ちがあって参加させて頂きました。28Eclipseという名前に変わっただけで、現場への導入障壁が格段にさがったように思います。機会があれば、業務に導入したいと考えています。「我々としては、Javaの標準に入ってもいいくらい優れたフレームワークだと考えている。Eclipse傘下になることで、標準化への道が開ける、かも。」とありますが、僕もJavaの標準に入ってくれると嬉しいライブラリです。資料の問題がボリュームあったので、家で復習したいと思います。これからのコンピューティングの変化とJavaきしださんの発表です。コンピュータの今の課題とそれに対するJavaの変化をスムーズに解説して頂けました。「CPUのクロックは頭打ち、でもコア数は今後どんどん増える。今までは黙っていてもコンピュータがどんどん早くなっていったけれど、今後は物理的に限界がある。」という話しから始まり、今までのノイマン型コンピュータとは異なる非ノイマン型コンピュータ技術の説明。Java技術への話しへと、つながりのある話しで理解しやすかったです。僕的には、Java言語からHDLソースが生成されるのが驚愕で面白かったですね。Pointクラスの説明もつながりがあって理解しやすかったです。【こっそり始める】Javaプログラマコーディングマイグレーションやんくさんの発表です。【こっそり始める】Javaプログラマコーディングマイグレーションとてもやんくさんらしい発表でした。開発現場の現状とそれに対するアクション。やんくさんの人柄や経験が素直に資料にでていて共感できる資料だと感じました。古いバージョンのJava知識から抜け出せない現場を改善したい方にとって、とても参考になる発表だったと思います。Frameworkの類似点・相違点やんくさんの資料も事前にレビューさせて頂いていたので、途中からひしだまさんの発表に参加しました。生ひしだまさんを見たかったにつきます。Frameworkの話しです。僕も最近はバッチ処理は並列処理を前提で設計するので、このようなフレームワークの知識も取り入れないといけないなと感じています。途中参加で話についていけなかったので、家でゆっくり資料を拝見したいと思います。ひしだまさんへの質問コーナーで拍手喝采がありました。28さすがはひしだまさんです。DQ10のフレンド募集中とのことです。コミュニティディスカッション~みんなもやろうコミュニティ運営~コミュニティディスカッションです。最近、コミュニティ活動もする僕としても凄く気になる議論です。東京と地方で抱える課題の違いや同じ課題、それに対する取り組みや意見など面白かったです。感じたのは、女性はピザはあまり好ましくないとのことです^^;.そうなのか〜(><)。どこかでリベンジしたいです。いうか、LTのレベルがみんな高すぎです。まとめ本当に刺激満載の楽しいイベントでした!!それと共に、まだまだ頑張らないといけないな〜と感じました。し、おじさんまだまだ若い子には負けないぞ!!!(既に負けている気がするが)。「資料の内容が技術的に正しくなく、フェアでもない」と多方面から注意を受ける事態となりました。(−_−;)この記事はその資料の検証と反省を目的としたものです。資料は取り下げたのですが、迷惑をおかけした方たちへのお詫びと反省をかねて、問題の資料内容について自分なりに検証したいと思います。問題となった資料の構成は次のとおりです。Functorのコードを書いているが間違っている(技術的に正しくない)・Scalaのコードが型クラスを実現しようとしているのに対して、Kotlinのコードはそれを実現しようとしていない(フェアじゃない)が指摘された内容だと考えています。Functorのコードを書いているが間違っているまずこれについて。F.myMap(self)(f)}上記コードについては問題ないと思います。}}mapの実装を不必要にややこしく書いています。A](l)暗黙の型変換を目的としたロジックが不適切です。このロジックだと、Functorを実装した分だけ同じような定義をしないといけないです。まーまー、正しいかと思われるコードについて書きました。fa.map(f)}まず、myMapの実装を簡単に書きました。実装内容は今回の資料の対象ではないので。A](fa)次に、暗黙の型変換を目的としたロジックを修正しました。MyFunctorの実装を型ごとに暗黙の引数で受け取れるように修正したことで、同じ定義を書く必要がなくなりました。Scalaのコードが型クラスを実装しようとしているのに対して、Kotlinのコードはそれを実現しようとしていない先ほどのFunctorは型クラスを実現しようとしていました。異なる型の間で共通したインターフェースでの異なる振る舞いを定義済みの型に対して拡張するものらしいです。・型クラスの利用という手順を踏む必要があります。今回拡張するFunctorについて、Functorは型パラメータをもつ型です。conversionの機能を用いています。資料の中で「implicitだらけでScala怖い」と表現した件について、僕の現状のScala力では読みにくいという感想でした。その比較としてKotlinの拡張関数で以下のコードを提示し、Kotlinが簡単と表現したのはフェアじゃないですね。異なる型の間で共通したインターフェースでの異なる振る舞いは実現できていないです。conversionでも簡単に実現できます。l.map(f)}ちなみにですが、Kotlinの拡張関数はただのシンタックスシュガーです。l.map(f)のような関数定義があり、第一引数の型をレシーバとして呼び出せる簡易構文を提供しているみたいです。実際に、上の定義を同じパッケージ内で定義すると、コンパイラにJVM上では同じシグネチャだよって怒られます。KotlinでFunctorを定義してみるはい、ではフェアである為にKotlinでFunctorの定義を頑張ってみます。Genericsもimplicitのような機能もありません。違う方法で異なる型の間で共通したインターフェースでの異なる振る舞いを定義済みの型に対して拡張するを実現できるよう考えてみました。Delegation*2の機能がありますので、拡張する型がインタフェースであれば、委譲クラスを簡単に作成できます*3。異なる型の間で共通したインターフェースでの異なる振る舞いを定義済みの型に対して拡張するは実現できたのではないかと思います。今回の反省LTはライトニングトークであって、軽いノリで誤った資料でいい訳ではないってことですね。深夜のテンションで酒飲みながら資料作るのはもうやめようっと。Kozakewww.slideshare.netまた、上記コードは以下にアップしています。追記>上記Kotlinコードにおいても、Scalaで実現していることを実現出来ていないと指摘を受けました。確かに実現できていないので、比較対象としては不適切です。参考レベルの記事とさせてください。*1:まあ、資料の中でもあくまでネタで、Scalaでも簡単に実現できるとは書いていましたが。8徹底再入門(大阪,7/11)に参加しました。