| A | B | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | AA | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Speakers | Title | タイトル | Category | サマリー | TalkPage | YouTube | YouTube Link Corrected | LLM used to summarize | Note | ||||||||||||||||
2 | Jeffrey van GoghMichail ZarečenskijJulie GundersonEgor TolstoyEkaterina PetrovaVsevolod TolstopyatovSebastian AignerSvetlana IsakovaEve Matthaey | Opening Keynote | 開会基調講演 | 1. General | こちらはKotlinConf'24基調講演の要点を日本語でまとめたものです： 1. **新しいマスコットと参加者**：基調講演では、新しく再考されたマスコットが紹介され、現地に約2,000人の参加者、オンラインでの視聴者も含めて37か国、71のグローバルイベントから多くの参加者がいることが報告されました。 2. **プログラムのハイライト**：イベントでは、5つの並行セッション、15分のライトニングトーク、コードチャレンジ、Touch Labのパートナーによるコードラボが行われました。夕方にはライブバンドの演奏やクイズが楽しめるパーティーも開催されました。 3. **Kotlin 2.0リリース**：Kotlin 2.0が発表され、日常の生産性を大幅に向上させる新しいコンパイラと2倍のコンパイル速度向上を特徴とし、パフォーマンスの大幅な向上が約束されました。 4. **MetaのKotlin導入事例**：Metaは、Kotlinを導入した経緯を共有し、Androidコードベースの信頼性の向上や新しいK2コンパイラによる20％のAndroidコンパイル速度向上などの成果を報告しました。 5. **GoogleのKotlinへの投資**：Googleは、Kotlin 2.0に対する貢献、Android lint、Kotlin Symbol Processing、Compose Compiler Pluginの改善について説明し、Kotlin 2.0のサポート強化を目指していることを述べました。 6. **Kotlin Multiplatform**：Kotlin Multiplatformは、Android、iOS、Web、サーバーなどのプラットフォーム間でコードを共有するための機能であり、GoogleはAndroid Studioおよび関連ツールでの公式サポートを発表しました。 7. **新しいKotlin言語機能**：ガード付き条件、多ドル記法、インライン関数などの新機能が発表され、言語の表現力と使いやすさの向上が目指されています。 8. **ツールとライブラリ**：新しいツールやライブラリ（KotlinX RPC、KotlinX Dataframe、KotlinX IOなど）が紹介され、マルチプラットフォームプロジェクトのサポートを強化し、開発エコシステムを向上させています。 9. **AIとKotlin**：JetBrainsは、IDEに統合されたAIアシスタントを紹介し、スマートなコード補完、コードの説明、コンテキストに基づいた支援などで生産性を向上させることを発表しました。 10. **コミュニティとエコシステムのサポート**：Kotlin Foundationは、Kotlinエコシステムへの優れた貢献をサポートするための助成プログラムの継続を発表し、Uberがシルバーメンバーとして参加することも報告しました。Amazonも、様々なチームやツールでKotlinの使用が増加していることを共有しました。 | https://kotlinconf.com/talks/623200/ | https://www.youtube.com/embed/Ar73Axsz2YA?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | https://youtu.be/Ar73Axsz2YA | ChatGPT | |||||||||||||||||
3 | Hadi Hariri | Closing Panel | クロージングパネル | 1. General | 要約: クロージングパネル | KotlinConf'24 歓迎と紹介: パネルは、参加者への歓迎メッセージと火災警報の謝罪で始まりました。フォーマットが説明され、観客からの質問を奨励しました。 学生コンテストの受賞者: Googleのジェフリーが、印象的なKotlinマルチプラットフォームアプリを開発した学生コンテストの受賞者を紹介しました。彼らはステージに招待され、賞品が贈られました。 パネリストの紹介: KotlinやGoogleなどからのプロジェクトリードやマネージャーが、彼らの役割を簡単に紹介しました。 KotlinのJava互換性: パネルは、JVM開発者のためにJavaとの互換性を維持することの優先順位を再確認しました。 KotlinマルチプラットフォームとWASM: Kotlin JSとKotlin WASMの改善に関する議論がありました。Kotlin JSの継続的な改善を強調しつつ、ウェブ開発におけるWASMの将来性を信じていると述べました。 マルチプラットフォームライブラリの開発: マルチプラットフォームライブラリの開発の複雑さについて触れ、プラットフォーム固有の機能がマルチプラットフォーム用に抽象化されると優雅さを失うことがあると指摘しました。 Kotlinコンパイラとプラグイン: Kotlinコンパイラプラグインの課題について触れ、将来的に安定したAPIを提供する計画を説明しました。 働く親への支援: 技術会議における働く親への支援の欠如に対する意見が出され、登録時に支援オプションを追加するなどの改善策が検討されました。 iOS開発者へのKotlinマルチプラットフォームの導入: マルチプラットフォームの詳細を高レベルのAPIの背後に隠し、仕事の安全性や自律性についての懸念を和らげるために共感を促進する戦略が取られました。 KMPの将来ビジョン: Kotlinマルチプラットフォームのビジョンについて議論し、コミュニティのフィードバックと継続的な実験に焦点を当てて、最良のプラクティスとエコシステムのサポートを自然に進化させることを強調しました。 | https://kotlinconf.com/talks/616756/ | https://www.youtube.com/embed/hSpdXn2kCGs?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | https://youtu.be/hSpdXn2kCGs | ChatGPT | |||||||||||||||||
4 | John Pampuch | A Tale of Two Languages | 2 つの言語の物語 | 1. General | ### 「二つの言語の物語 | ジョン・パンプシュ」 1. **講演の概要**: ジョン・パンプシュの基調講演は、KotlinとJavaの歴史と進化に焦点を当て、それらの補完的な性質と互いに影響を与え合ってきたことを強調します。 2. **Java対Kotlin**: 両方の言語は互いによく機能し、Kotlinはしばしば開発の先を行っています。JavaとKotlinは互いに多くの影響を受けています。 3. **開発環境の違い**: KotlinはJVMに依存せず、JavaはJDKとVMの開発に密接に結びついているため、それぞれ異なる利点があります。 4. **設計目標**: Kotlinの設計目標は実用的であり、簡潔さ、高い使いやすさ、明確な理解可能性に重点を置いています。Javaの設計目標はシンプルでオブジェクト指向、堅牢で安全です。 5. **主要な特徴と改善**: KotlinとJavaは、過去数年間で多くの主要な特徴と改善を導入しました。例えば、Kotlinはスマートキャスト、文字列テンプレート、名前付き引数などの機能を持ち、Javaはラムダ式、モジュールシステム、レコードなどを導入しました。 6. **互換性とエコシステム**: KotlinとJavaはどちらも後方互換性が高く、広範なエコシステムを持っています。Kotlinはマルチプラットフォーム対応が優れており、JVM、Android、iOS、Webで動作します。 7. **Kotlinの優位性**: Kotlinはコルーチン、非同期フロー、チャネルなどの非同期機能を持ち、これによりプログラミングモデルが大幅に改善されます。DSL（ドメイン特化言語）もKotlinの強みです。 8. **開発の速度とリリースサイクル**: Kotlinは新機能のリリースが速く、Javaは予測可能なリリースサイクルを持っています。Kotlinは開発者フレンドリーで実用的な機能を提供し続けています。 9. **競争と進化**: JavaとKotlinの競争は、言語の進化を加速させ、新しいアイデアと興奮をもたらします。これは、より良い結果を生み出すための重要な要素です。 10. **今後の展望**: Kotlinは多くの先進的な機能を持ち、Javaもこれに追随する形で進化しています。両言語は引き続き互いに影響を与え合い、開発者にとって魅力的な選択肢となるでしょう。 | https://kotlinconf.com/talks/587051/ | https://www.youtube.com/embed/1w7S_iP5-s0?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | https://youtu.be/1w7S_iP5-s0 | ChatGPT | |||||||||||||||||
5 | Erik Meijer | Virtual Machinations: Leveraging the Linguistic Bytecode of Large Language Models to Emulate Program | 仮想マシネーション: 大規模言語モデルの言語バイトコードを利用してプログラムをエミュレートする | 1. General | 1. **イントロダクションと背景**: - スピーカーはサンフランシスコでの最初のKotlinカンファレンスから現在までのKotlinコミュニティの成長を振り返ります。 - プログラミングの未来の可能性について強調し、Kotlinを超えた新しい展望について話します。 2. **現在のプログラミングモデル**: - 現在のプログラミングスタックには、異なるCPU、抽象化レイヤー、プログラミング言語、および再利用可能なライブラリが含まれます。 3. **新しい仮想マシンの提案**: - LLM（大規模言語モデル）をCPUとして使用する新しい仮想マシン「Out of Mind」を紹介します。 - 「Prompt once, run anywhere」の概念に基づく、新しいプログラミング言語を使用します。 4. **コード生成とユーザーの役割**: - ユーザーが自然言語でコードを生成できるため、従来の開発者の役割が減少する可能性について議論します。 5. **具体例とデモ**: - 金の価格とビットコインの取引に関する具体的な質問を例に、ChatGPTの現在の制限を示します。 - 新しいプログラミング言語を使用して同じ問題を解決する方法をデモンストレーションします。 6. **自然言語とコードの統合**: - リテラルプログラミングの形式を採用し、自然言語とコードのスニペットを組み合わせた新しいプログラミング言語の特徴を説明します。 7. **歴史的背景とAIの認識**: - ライプニッツやチューリングなどの歴史的人物の考えを引用し、AIに対する楽観的な見方を示します。 - AIを知的と見なすかどうかに関する議論を避け、有用性に焦点を当てます。 8. **現状の問題と改良点**: - 現在のデータベースクエリとLLMの制限を例示し、動的情報の提供と正確な回答の重要性を強調します。 - コンテキスト情報とモデルの訓練データを組み合わせて使用する「Retrieval Augmented Generation (RAG)」の概念を紹介します。 9. **新しいプログラミングアーキテクチャ**: - 従来のコンピュータアーキテクチャと新しいニューロコンピュータのアーキテクチャの類似点を示します。 - 「ツール呼び出し」や「関数呼び出し」の概念を使用して、AIモデルがどのようにして複雑なタスクを処理するかを説明します。 10. **プログラミング言語の設計と未来**: - 新しいプログラミング言語の設計原則と、チェーンオブソートや変数の使用方法について詳しく説明します。 - この新しい言語がより多くの人々にアクセス可能であり、エンドユーザーが直接問題を解決できるようにすることを目指しています。 この要約は、仮想マシン、プログラミング言語、AIの役割についての詳細な講演のポイントを強調しています。 | https://kotlinconf.com/talks/616537/ | https://youtu.be/ySKS719R6fc | ChatGPT | ||||||||||||||||||
6 | Rahul Ravikumar | Hacking Sony Cameras for Fun and Profit | 楽しみと利益のためにソニーのカメラをハッキングする | 1. General | 以下は、「Hacking Sony Camera's for fun and profit | Rahul Ravikumar」のトークの要約です： - ラーフル・ラヴィクマールは、Googleのソフトウェアエンジニアで、Sony Alpha a7r Mark 5をハッキングする方法について語りました。 - SonyのImaging Edge mobileアプリは、大きなサイズとパフォーマンスの問題で批判され、別の方法を模索するきっかけとなりました。 - 彼はSonyカメラで使用されているBluetooth Low Energy（BLE）プロトコルを詳述し、デバイス発見にはGeneric Access Profile（GAP）、データ通信にはGeneric Attribute Profile（GATT）を使用しています。 - SonyがWi-Fi Directを使用しているため、通常のAndroidツールであるBluetooth Snoopを使用できなかったため、BLEスニッファーを使用しました。 - Wiresharkで製造業者固有のデータを分析することで、ラーフルはカメラのリバースエンジニアリングを行いました。 | https://kotlinconf.com/talks/585280/ | https://www.youtube.com/embed/nE3_HzxNL9Q?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | ChatGPT3 | ||||||||||||||||||
7 | David Denton | Kotlin's Elegant Deceptions: Simple APIs, Unusual Tactics | Kotlin のエレガントな欺瞞: シンプルな API、珍しい戦術 | 1. General | 承知いたしました。以下に、講演内容を10個の箇条書きで日本語でまとめます。 1. **KotlinでシンプルなAPIを:** Kotlinの言語機能は、ユーザーにとってよりシンプルなAPIを作成するために、意外な方法で使用できます。 2. **スタイリッシュな欺瞞:** 良いAPIデザインは、複雑さを隠しつつ（欺瞞）、ユーザーフレンドリーな状態を維持することを含みます。 3. **APIとしての関数:** 最もシンプルなAPIは関数であり、Kotlinの関数型アプローチは、関数を理解しやすく、使いやすくします。 4. **プリミティブの構成:** 複雑なシステムは、単純な関数とデータ型を組み合わせることで構築できます。 5. **コンストラクタよりもファクトリ関数:** ファクトリ関数は、コンストラクタよりも柔軟性と制御性を提供します。 6. **発見のためのコンパニオンオブジェクト:** コンパニオンオブジェクトは、関連する関数をグループ化し、ユーザーのための発見ポイントを提供するために使用できます。 7. **無効な型を表現不能にする:** 値クラスとコンパニオンオブジェクトを使用して、より強力な型安全と検証を強制します。 8. **動的データのための委譲プロパティ:** 委譲プロパティは、動的データソースを静的に型付けされたコードにシームレスに統合することを可能にします。 9. **拡張インターフェース:** 拡張関数を持つインターフェースを定義することで、契約を強制し、拡張性を提供します。 10. **優れたAPIを調査する:** 優れた設計のAPIから学び、新しい技術を発見し、独自のAPI設計を改善しましょう。 これらのポイントのいずれかをさらに詳しく説明してほしい場合は、お知らせください。 | https://kotlinconf.com/talks/575677/ | https://www.youtube.com/embed/NA9orTe_QWc?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | Gemini | KotlinFest | |||||||||||||||||
8 | Duncan McGregorDmitry Kandalov | Refactoring to Expressive Kotlin | 表現力豊かな Kotlin へのリファクタリング | 1. General | **表現豊かなKotlinへのリファクタリング：主要なポイント** 1. **自然言語 vs. コード:** 自然言語は人間にとって直感的ですが、プログラミングには十分な正確さを持ち合わせていません。Kotlinは自然言語とコードのギャップを埋め、より表現豊かなコードを可能にします。 2. **前置詞の重要性:** 「to」や「from」などの前置詞は、コードの意図や方向性を明確にし、理解を容易にします。 3. **呼び出し場所の重要性:** 関数が呼び出される場所での可読性が重要です。関数の定義を変更する際に、それが呼び出し側にどう影響するかを考慮しましょう。 4. **文脈の変化:** コードを変更する際は、文脈（周囲のコード）が変更にどう影響するかを考慮しましょう。必要に応じて文脈を調整し、明確さを保ちましょう。 5. **エイリアスと柔軟性:** メソッドにエイリアスは設定できませんが、スタンドアロン関数にエイリアスを設定することで柔軟性が得られ、文脈に応じた名前変更が可能になります。 6. **パラメータとレシーバーの入れ替え:** パラメータをレシーバーに、またはその逆に切り替え、名前を変更することで、コードの表現力を高めることができます。 7. **スコープ関数:** * **apply:** 変更可能なオブジェクトの設定や小さな副作用に。 * **also:** 引数のパイプやヌル性の処理に。 * **let:** 変数からのインポートに。 * **with:** (あまり使用されませんが、文脈のために言及されています) * **run:** (あまり使用されませんが、文脈のために言及されています) 8. **拡張関数:** コードの構成を改善し、コンポーネント間の結合を減らすことができます。 9. **分離:** コンポーネント（例：DB設定とアプリケーション）を分離することで、保守性と柔軟性を向上させることができます。 10. **単一式:** 関数を単一式にリファクタリングすると、多くの場合、より宣言的で読みやすくなります。 | https://kotlinconf.com/talks/583997/ | https://www.youtube.com/embed/p5WylVjtzBQ?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | Gemini | KotlinFest | |||||||||||||||||
9 | Ty SmithEve MatthaeyAnton YalyshevJames WardKevin Bierhoff | Tools & Techniques for Java to Kotlin Migrations | Java から Kotlin への移行のためのツールとテクニック | 1. General | 1. Uber、Google、Metaなどの企業は、JavaからKotlinに移行することで、開発者の生産性向上、コードの複雑性軽減、レビュー時間の短縮など、大きなメリットを享受しています。 2. Kotlinへの移行は、特に大規模なコードベースの場合、ビルド時間、未成熟なツール、既存のJavaコードとの相互運用性の維持などの問題により、困難な場合があります。 3. JetBrainsのJ2Kコンバータ、UberのRectifyツール、Metaのcinnatボットなど、移行プロセスを自動化し合理化するためのさまざまなツールや技術が開発されています。 4. null許容性は、null値の慎重な処理が必要であり、正しく対処しないと実行時エラーにつながる可能性があるため、移行プロセスにおける大きな課題です。 5. J2Kやcinnatのような自動マイグレーションツールは、ある程度慣用的なKotlinコードを生成するのに役立ちますが、コードの品質と正確性を確保するためには、手動でのレビューや後処理が必要になることがよくあります。 6. 移行の目標は、たとえ最初から完全に慣用的でなくても、保守性があり、正しく、安全なKotlinコードを作成することです。開発者は後でコードをさらに最適化することができます。 7. Googleは、移行されたコードが元のJavaコードと全く同じように動作することを確認するために、広範なテストスイートを使用しています。 8. 企業間およびより広範なKotlinコミュニティとの協力は、移行ツールやベストプラクティスを開発し共有するための鍵となります。 9. コード生成やマルチフレームワークエージェントのようなAIを活用したソリューションは、移行プロセスをさらに自動化し、改善するための有望な手段です。 10. 小規模な企業は、大規模なJavaからKotlinへの移行に着手する前に、ビジネス上の動機と利用可能なリソースを慎重に検討する必要があります。 | https://kotlinconf.com/talks/587118/ | https://www.youtube.com/embed/POmlM7OshwA?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | Gemini | KotlinFest | |||||||||||||||||
10 | Daniel Terhorst-North | The best programmer I know | 私が知っている最高のプログラマー | 1. General | 「最高のプログラマー」からの学び 1. **仕事(ジョブ)を終わらせる:** コードを書くことだけでなく、望ましい結果を達成することに集中する。最高のコードとは、問題解決に必要な最小限のコードである。 2. **どこからでも始める:** 最初から完璧を求めすぎない。完璧でなくてもコードを書き始め、そこから改善していく。 3. **どんどん試す:** 実験し、様々なアプローチを試み、失敗を恐れない。失敗から学び、改善し続ける。 4. **今を解決する:** 目の前の問題に集中し、過剰な設計をしない。後からでも適応し、改善することは可能。 5. **ドメインを学ぶ:** 解決しようとしている問題の背景と、製品を使うユーザーのニーズを理解する。 6. **適切なツールを選ぶ:** チームが慣れているものだけでなく、特定の製品や問題に最適な技術を選択する。 7. **小さなものを作る:** 小さく、組み合わせ可能で再利用しやすいコンポーネントを作る。 8. **チームを大切にする:** 誰もが安心してアイデアを共有し、互いに学び合えるような協力的な環境を育む。 9. **最新情報を追う:** 最新の技術やトレンドに遅れないようにするが、健全な懐疑心を持ち、盲目的に流行を追わない。 10. **自分を大切にする:** 健康的なワークライフバランスを維持し、プログラミング以外の興味を追求する。 | https://kotlinconf.com/talks/617143/ | https://www.youtube.com/embed/D6aUoGK2rkk?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | Gemini | KotlinFest | |||||||||||||||||
11 | Geoffrey De Smet | Free the world from wasteful scheduling with Timefold AI | Timefold AI で世界を無駄なスケジュールから解放 | 1. General | **タイトル: 「Timefold AIで無駄なスケジューリングから世界を解放 | Geoffrey De Smet」** 1. Geoffrey De Smetは18年前にオープンソースプロジェクトを開始し、現在では世界中でスケジューリングやプランニングの問題解決に使用されています。 2. この技術は、週末にどの薬局が開いているかを決定したり、ケーブルインストールの技術者を割り当てたり、裁判官のスケジューリングを行うなど、さまざまなシナリオで役立っています。 3. プロジェクトはソルバーであり、プランニング問題に特化したAIの一形態ですが、機械学習ではありません。 4. 空港のメンテナンス、荷物チェックイン、フライトスケジューリング、セキュリティスタッフ配置、ゲートスケジューリングなど、多くの実世界のスケジューリング問題が存在します。 5. 学校の時間割スケジューリングの例を用いて、ソルバーがどのようにレッスンを部屋と時間枠に割り当て、コンフリクトを避けるかを示しています。 6. 多くのスケジューリングは手動または不十分な自動化で行われていますが、高度なアルゴリズムを使用すると、これらのプロセスを最適化できます。 7. 複雑なスケジューリングには指数関数的な複雑さがあるため、ブルートフォースアルゴリズムの非効率性を強調しています。 8. ローカルサーチ、タブーサーチ、シミュレーテッドアニーリングなどの高度なアルゴリズムを使用して、効率的に準最適な解を見つけます。 9. Timefoldは、Kotlinやその他の技術と互換性のある最適化アルゴリズムを提供するオープンソースライブラリです。 10. ビークルルーティングや学校の時間割作成の例を通じて、Timefoldが複雑なスケジューリング問題をどのように解決し、効率を向上させ、コストや排出量を削減するかを示しています。 | https://kotlinconf.com/talks/587887/ | https://www.youtube.com/embed/3k0LTugXLEk?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | CjatGPR4 | ||||||||||||||||||
12 | Tarik Eshaq | Crossing the barrier from Kotlin to Rust (and back)! | Kotlin から Rust へ (そしてその逆も) 障壁を越えてください! | 1. General | 1. **導入とスピーカーの背景**: タリク・イシャク (TK) はMozillaのエンジニアであり、3年間にわたりKotlinとRustの組み合わせで開発を行ってきました。特にFirefox Syncに焦点を当てています。 2. **講演の概要**: プレゼンテーションでは、KotlinからRust、そしてその逆の呼び出し方法について説明し、このプロセスに伴う複雑さと、それを容易にするためのツールについて解説します。 3. **課題と考慮点**: KotlinとRustのような2つの言語間の橋渡しは、開発者の経験やツールの問題を含め、大きな複雑さを引き起こします。 4. **KotlinとRustを組み合わせる理由**: 既存のRustライブラリの活用、詳細なメモリ管理の必要性、ガベージコレクターのオーバーヘッドの回避など、KotlinとRustを組み合わせるシナリオがあります。 5. **基本的な問題**: 言語間の相互運用性における核心問題は、両言語が理解できる共通のABI（アプリケーションバイナリインターフェース）を確立することです。これは通常、共通の仲介者としてCを使用することを伴います。 6. **FFIサンドイッチ**: KotlinとRust間のインターフェースは、外国関数インターフェース（FFI）サンドイッチを通過することを含み、言語間の通信に必要なCのようなコードを処理します。 7. **UniFFIツール**: MozillaはUniFFIというツールを開発し、RustとKotlinのバインディング生成を自動化して、エラープローンなCのようなコードを処理し、開発者の負担を軽減します。 8. **実用的な例**: Q&Aアプリケーションを使用して、UniFFIがどのように機能するかを実演し、Rustの構造体と関数をKotlinに公開し、KotlinがRustのトレイトを実装する方法を紹介します。 9. **エラーハンドリングと非同期サポート**: UniFFIはRustのエラータイプと非同期関数をサポートしており、それらをKotlinの規約（例えばsuspend関数）に変換してシームレスな統合を確保します。 10. **パッケージングとデプロイメント**: 本番環境では、Gradleを使用してRustコードをコンパイルし、Kotlinのバインディングを生成します。これはMozillaのGradleプラグインとUniFFIによって促進されます。 | https://kotlinconf.com/talks/578348/ | https://www.youtube.com/embed/cUKcrfdFRqk?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | CjatGPR4 | KotlinFest | |||||||||||||||||
13 | Martin Bonnin | Building libraries for the next 25 years | 今後 25 年間に向けてライブラリを構築する | 1. General | ### 次の25年間に向けたライブラリの構築 | Martin Bonnin 1. **トークの動機**: 2020年にJavaの25周年を迎えたことに触発され、長期的に使用されるKotlinライブラリの構築について考察。Kotlinを試行錯誤する幼児に例えながら学びの過程を説明。 2. **ライブラリ開発の課題**: 主な課題には、プロジェクトの命名、API設計、公開、既存の機能を壊さずに安定性を確保することが含まれる。APIの変更は、ソース、バイナリ、行動の3つの方法で壊れる可能性がある。 3. **API設計のベストプラクティス**: - **拡張関数**: 開発者が所有していない型に対しても利用できる。 - **シールドクラス**: 可能な型を限定し、APIを予測しやすくする。 - **バリュークラス**: 型安全性とパフォーマンスを提供。 - **DSLビルダー**: 簡潔な構文を提供するが、発見可能性やJava互換性が低下する可能性がある。 4. **命名とマーケティング**: 記憶に残りやすく、独自性のある名前を使用し、過度に説明的な名前（例：Kotlin Yaml Parser）は避ける。 5. **公開**: - **Maven Central**: 安定性とセキュリティで知られる優先リポジトリ。 - **Gradleプラグイン**: 異なるプロジェクトタイプにわたる公開を合理化するために、Gradle Maven Publish Pluginを使用。 6. **バージョニングと進化**: - **セマンティックバージョニング**: 安定性と変更を明確に伝える。 - **非推奨化戦略**: 非推奨の注釈を使用して、即座に機能を壊さずにユーザーに変更を案内。 7. **バイナリ互換性バリデーター（BCV）**: APIの安定性を追跡および維持するための重要なツールで、破壊的変更を早期に検出するためにCIシステムと統合。 8. **エラーハンドリング**: 例外よりも型安全なエラーハンドリングを推奨し、Kotlinの将来の改善（ユニオン型など）を期待。 9. **Gradle設定**: 公開と依存関係管理のための適切なGradle設定の重要性を強調。 10. **コミュニティとリソース**: コミュニティの貢献の価値を強調し、Kotlinライブラリガイドラインなどのリソースを活用し、議論やツール開発への参加を奨励。 | https://kotlinconf.com/talks/586999/ | https://www.youtube.com/embed/1HK2TrBwC1o?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | |||||||||||||||||||
14 | Edwin Jakobs | Creative Coding with OPENRNDR | OPENRNDR を使用したクリエイティブなコーディング | 1. General | こちらはEdwin Jakobsによる「Creative Coding in OPENRNDR」についての主なポイントです： 1. **クリエイティブコーディングの紹介**：Edwin Jakobsは自身をクリエイティブコーダーと称し、コードを使って視覚的に魅力的で複雑な描画やアニメーションを作成することに焦点を当てています。 2. **彼の作品の特徴**：彼の作品は多くの場合、ベクター、ASCIIアート、鉛筆画、複雑なベクター構成、精巧なタペストリーのようなさまざまな芸術形式に似た視覚システムを作成することが含まれます。 3. **OPENRNDRの使用**：Jakobsは、クリエイティブコーディングフレームワークであるOPENRNDRを使用してツールや視覚システムを開発しています。OPENRNDRはベクターグラフィックスに優れており、複雑な形状や曲線を操作してアニメーションを作成することが可能です。 4. **ストリートビューのプロジェクト**：Jakobsのスタジオは、Googleストリートビューの画像を通じて空間を表現することを探求しており、これらの画像を物理的な球体に投影し、センサーと連動させる実験を行っています。 5. **データをアートとして扱う**：彼のプロジェクトはしばしば画像やデータを粒子として扱い、それらを使用してより大きな視覚構成を作成します。例として、アムステルダム博物館のアーカイブからの画像を公共空間に展示するための大きな画像にマッピングすることが含まれます。 6. **図書館プロジェクト**：Jakobsはデルフト大学の図書館のプロジェクトに取り組み、学生の論文コレクションを視覚化してマップにし、ユーザーが新しい方法でコレクションを探索できるインタラクティブなインターフェースを作成しました。 7. **OPENRNDRのツールと機能**：このフレームワークは、シェードスタイル、ポストプロセシングエフェクト、アニメーション、ベクトル操作など、Jakobsの創作プロセスに欠かせないさまざまなツールや機能をサポートしています。 8. **教育と指導**：Jakobsは、アートやデザインの学生にプログラミングを教えており、OPENRNDRを使用して、クリエイティブな文脈でのコーディングの基本を紹介しています。彼の授業では、学生に視覚的なアート作品を作成する課題を与えることが多いです。 9. **プロジェクトのデモンストレーション**：彼は、OPENRNDRを使用してスペキュレーティブなIntelliJ IDEAスプラッシュスクリーンを作成するプロセスをデモンストレーションし、視覚システムとタイポグラフィレイヤーを組み合わせて動的で美しい結果を生み出す方法を示しました。 10. **コミュニティとリソース**：Jakobsは、OPENRNDRを学び、使用するためのリソース（包括的なガイドや追加ツールとエフェクトのリポジトリなど）を強調し、他の人々がこのコミュニティを探索し、貢献することを奨励しています。 | https://kotlinconf.com/talks/586859/ | https://www.youtube.com/embed/GysSoSwmLYo?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | |||||||||||||||||||
15 | John O'Reilly | Hitchhiker’s Guide to Kotlin Multiplatform Libraries | Kotlin マルチプラットフォーム ライブラリへのヒッチハイク ガイド | 2. KMP | 1. **紹介と背景** - ノルウェーのNeatでリモートワーカーとして働くジョン・オレイリーが、コペンハーゲンで開催されたKotlinConfで発表。 - Kotlin Multiplatform（KMP）とCompose Multiplatform（CMP）の成長と採用について説明。 2. **Kotlin Multiplatformとの旅** - ジョンのKMPへの関心は2018年後半、ゴールウェイバスプロジェクトから始まりました。 - プロジェクトはAndroid専用から複数のプラットフォームを含むものに移行しました。 3. **ライブラリの概要** - 5年間で作成された11のKMPサンプルの概要を説明し、異なるアーキテクチャ、リモートアクセス、永続化アプローチ、さまざまなライブラリをカバー。 4. **主要なライブラリの紹介** - **Koin:** 依存性注入フレームワークで、KMPプロジェクトで広く使用されています。 5. **具体的なサンプルプロジェクト** - **People in Space:** 人々のリストと国際宇宙ステーションの位置を表示。Koin、Ktor、SQLDelight、KMP Native Coroutinesを使用。 - **Confetti:** 複数のカンファレンス情報を表示するプロジェクト。Apollo Kotlin、Decompose、Multiplatform Settings、Coilを使用。 - **Bike Share:** 自転車シェアネットワークのリストを表示。Realm Kotlin、KMP Observable ViewModel、Gradle Plugin for Swift Packageを使用。 - **Climate Trace:** 各国の排出情報を表示。Voyager、Window Size Class、Jetpack Navigationを使用。 - **Fantasy Premier League:** イングランドのサッカーリーグの情報を表示。Jetpack ViewModel、Jetpack Room、Jetpack DataStore、Skie、KMP Native Coroutines、KMP Observable ViewModelを使用。 6. **KotlinとSwiftのインタープ** - **KMP Native Coroutines:** KotlinのコルーチンをSwiftのコンカレンシー機能にマッピング。 - **Skie:** Kotlinのサスペンド関数やフローをSwiftで利用可能にし、KotlinのシールドクラスをSwiftの列挙型に変換。 7. **その他のライブラリ** - **Multiplatform Settings:** キーバリューデータを保存するためのライブラリ。 - **Coil:** 画像の読み込みとレンダリングを行うライブラリで、Compose Multiplatformもサポート。 8. **移行とマイグレーション** - JetpackのライブラリのKMPサポートにより、既存のAndroidアプリからの移行が容易に。 9. **まとめ** - さまざまなKMPサンプルプロジェクトで使用されるKotlinとCompose Multiplatformのライブラリの迅速なツアーを提供。 - 発表のスライドは後で参照できるように利用可能にする予定。 10. **質問と感謝** - 発表終了後、質疑応答の時間を設け、参加者に感謝の意を表明。 | https://kotlinconf.com/talks/664992/ | https://youtu.be/Ki9UdMMpYx4 | ChatGPT | ||||||||||||||||||
16 | Giancarlo Buenaflor | Uniting Native SDKs into KMP | ネイティブ SDK を KMP に統合する | 2. KMP | **"Uniting Native SDKs into KMP | Giancarlo Buenaflor"の要約:** 1. **導入と背景:** - Giancarlo Buenaflor（通称Gino）、Sentryのソフトウェアエンジニア。Dart、Flutter、KMP SDKに取り組む。 - Google Summer of CodeでC Foundationのプロジェクトに参加し、GoogleのログフレームワークのKMPバージョンを開発。 2. **目的と概要:** - 既存のネイティブSDK（iOSとAndroid）をKotlin Multiplatform（KMP）に統合する方法についての説明。 - 既存のSDK機能を活用してKMP SDKを作成。 3. **Androidの統合:** - ビルドファイルに依存関係を追加し、AndroidメインのソースセットでSDKライブラリを使用するシンプルなプロセス。 4. **iOSの統合:** - Kotlinバインディングの作成が必要なため、より複雑。 - 定義されたヘッダーを使用するcinteropや、簡単なセットアップのためのCocoaPodsなどのツールを使用。 5. **方法の利点と欠点:** - **定義されたヘッダー:** - 不要な部分を削除することが可能だが、基盤となるフレームワークの変更に弱い。 - **CocoaPods:** - 使用が簡単で、全てのヘッダーのバインディングを自動的に作成するが、すべてのヘッダーが対象になるため柔軟性に欠ける。 6. **API設計:** - Sentryでは、SDK設計のためのガイドラインが既に定義されており、それに従ってAPIを設計。 7. **プラットフォーム固有の実装:** - プラットフォーム固有のSDKを使用して初期化関数を実装。 8. **Type Aliasの使用:** - プラットフォーム固有の型を直接使用するためにType Aliasを使用し、コードの重複を削減。 9. **問題と回避策:** - Javaのゲッターとセッターの問題に対処するため、Type Aliasを使ったAPIの調整が必要。 10. **ユーザー視点での使用:** - ユーザーはCocoaPodsを使用してフレームワークをリンクし、簡単にSDKを初期化して使用できる。 | https://kotlinconf.com/talks/587001/ | https://youtu.be/F4E-AkgTPSM | |||||||||||||||||||
17 | Marco Gomiero | The rollercoaster of releasing an Android, iOS, and macOS app with Kotlin Multiplatform | Kotlin マルチプラットフォームを使用した Android、iOS、macOS アプリのリリースのジェットコースター | 2. KMP | ### 「The rollercoaster of releasing an Android, iOS, and macOS app with KMP | Marco Gomiero」の要約 1. **はじめに**: - マルコ・ゴミエロは昼はAndroid開発者、夜は他のプラットフォームを探求。 - Android、iOS、macOS用のOSSリーダーアプリに取り組み、Kotlin Multiplatform（KMP）とSwiftUIを使用。 2. **Android開発**: - 慣れているため、最初にAndroidで開始。 - 主な手順：アプリの署名、Playストアへのアップロード、レビューとリリースプロセスの通過。 3. **iOS開発**: - Androidに似たプロセスだが、セキュリティのためにプロビジョニングプロファイルなどの追加手順が必要。 - アップロードプロセスはXcodeやCIツールで管理。 4. **macOS開発**: - Kotlin Multiplatformを使用してJVMデスクトップアプリケーションを開発。 - 配布オプション：手動で配布、App Store外で配布。 5. **手動配布**: - アプリの署名、ノータリゼーション（AppleのGatekeeperによるチェック）。 - GitHubリリースなどの手段でバイナリをアップロード可能。 6. **App Store配布**: - アプリの署名とプロビジョニングプロファイルの提供。 - TestFlight経由でのアップロードやTransporterアプリの使用。 7. **課題と解決策**: - Apple silicon専用バージョンの作成やサンドボックス対応のためのネイティブライブラリのロード。 8. **クラッシュレポートとロギング**: - モバイル用にCrashlytics、macOS用にSentry Java SDKを使用。 - Kermitライブラリを使用してログを管理。 9. **国際化対応**: - Lyricistライブラリを使用して、多言語対応を実現。 - 現在はCompose Multiplatform Resourcesを使用せず、将来的に変更する可能性。 10. **結論とさらなるリソース**: - ブログでの投稿でさらに詳しく説明。 - 質問があれば対応することを提案し、聴衆に感謝の意を表明。 | https://kotlinconf.com/talks/587174/ | https://www.youtube.com/embed/JRlR4NWX-nc?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | https://youtu.be/JRlR4NWX-nc | ||||||||||||||||||
18 | Elif BilginYiğit BoyarDaniel Santiago | Enabling Kotlin Multiplatform Success: The Android Jetpack Journey | Kotlin マルチプラットフォームの成功を可能にする: Android Jetpack の旅 | 2. KMP | ### 「Kotlinマルチプラットフォームの成功を可能にする: Android Jetpackの旅」要約 1. **Kotlinマルチプラットフォームの紹介**: - Kotlinマルチプラットフォームは、複数のプラットフォーム（Android、iOS、Windows、Web）向けに共通のコードを書くことを可能にします。 - Jetpackは、Androidのライブラリスイートであり、Android開発の向上のためにKotlinマルチプラットフォームと統合されています。 2. **目標と利点**: - 主な目標は、魅力的なアプリケーションを作成し、収益性のあるビジネスを築き、プラットフォーム間で再利用可能な開発者スキルを提供することでAndroidエコシステムを向上させることです。 3. **ネイティブの相互運用性**: - Kotlinマルチプラットフォームのネイティブ相互運用性により、既存のプラットフォームの機能を最大限に活用できます。 - コード量の削減により、マーケット投入までの時間を短縮し、アプリケーションの品質向上に時間を割けます。 4. **JetpackとKMPの統合**: - JetpackはAndroid専用ですが、JetpackとKotlinマルチプラットフォームを組み合わせることで、Android開発がより良くなります。 - Googleは引き続きKotlinマルチプラットフォームに投資し、より多くのJetpackライブラリのマルチプラットフォーム化を進めています。 5. **技術的な挑戦**: - 800以上のモジュールや多数のライブラリが存在するため、すべてをKotlinマルチプラットフォームに変換することは困難です。 - 各プラットフォーム向けのCIインフラやテスト環境の再構築が必要です。 6. **進捗と実験**: - Googleは2019年からKotlinマルチプラットフォームの実験を開始し、2020年には初のプロダクトレビューを実施しました。 - Gmail、Googleドキュメント、Googleカレンダーなどのアプリを所有するワークスペースグループと協力して、複数の実験を行っています。 7. **ツールとライブラリの開発**: - Kotlin Symbol Processing（KSP）を導入し、RoomライブラリをKotlinコードで処理できるようにしました。 - X ProcessingやX Poetなどのツールを開発し、コード生成やテストのためのインフラを構築しました。 8. **Roomライブラリのマルチプラットフォーム化**: - RoomはSQLiteデータベースを使用するためのJetpackライブラリで、注釈処理APIを通じてコードを生成します。 - Roomのマルチプラットフォーム化のために、KSPサポートやランタイムソースの移行など、多くの技術的な課題に対処しました。 9. **互換性と移行戦略**: - 既存のユーザーへの影響を最小限に抑えるために、共通コードへの移行やプラットフォーム固有の実装を用意しました。 - ファイルロックやSQLドライバのような具体例を通じて、期待されるクラスや共通インターフェースの使用方法を説明しました。 10. **将来の展望**: - Roomのアルファ版は大部分の機能をサポートしていますが、いくつかの機能はまだAndroid専用です。 - 将来的には、WebAssembly（Wasm）サポートの追加を計画しています。 | https://kotlinconf.com/talks/623652/ | https://www.youtube.com/embed/iInVEuFPSkg?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | https://youtu.be/JRlR4NWX-nc | ||||||||||||||||||
19 | Paulina Sadowska | Pushing the limits of the Server Side UI platform with KMP | KMP を使用してサーバー側 UI プラットフォームの限界を押し上げる | 2. KMP | ### 「KMPを使用したサーバーサイドUIプラットフォームの限界に挑戦 | Paulina Sadowska」の概要 1. **導入**： - Paulina SadowskaはAllegroのエンジニアリングマネージャーであり、Kotlin Multiplatform (KMP)を用いて製品開発の課題を克服した経験を共有。 - Allegroはポーランドの主要なeコマースプラットフォームで、多くのモバイル開発チームがいる。 2. **プロジェクトの背景**： - チームは、品質を犠牲にすることなく開発スピードを上げるために、サーバー駆動のUIプラットフォーム「Mbox」を開発。 - Mboxは、AndroidとiOSの両方でネイティブビューを使用して、バックエンドで定義された画面をレンダリングすることを可能にし、Allegroアプリの約50画面をサポート。 3. **課題と解決策**： - 当初は、限られたインタラクションを持つコンテンツ画面向けに設計されたMboxは、クライアントサイドロジックとインタラクションの必要性について開発者からの懸念があった。 - 解決策として、ビューのバインディングとクライアントサイドロジックのメカニズムを追加する必要があり、これをKotlin Multiplatformで実装。 4. **技術的アプローチ**： - JavaScriptエンジンの使用は、一貫性の欠如やアプリサイズの影響を理由に避けた。 - 代わりに、カスタムクライアントサイドロジックエンジンを開発し、エンジン、契約層（JSONロジックの使用）、TypeScriptでの開発者フレンドリーな抽象化レイヤーの3つのコンポーネントを作成。 5. **JSONロジック**： - JSONロジックは、JSON形式で操作を定義するフォーマットを提供し、複雑なビジネスロジックを作成するために操作を組み合わせることができる。 - チームは、必要に応じてJSONロジックを追加の操作で拡張。 6. **Kotlin Multiplatformの実装**： - KMPは、AndroidとiOSの両方を対象とする能力があり、一貫した動作を保証。 - 共有コードベースにより、プラットフォーム間の不一致やバグが減少。ただし、iOS統合には課題があった。 7. **利点と結果**： - カスタムエンジンはアプリサイズにほとんど影響を与えず、サポートされる機能の品質を確保。 - プロジェクトは安定しており、リリース後ほとんどメンテナンスが不要。 8. **遭遇した課題**： - 新しい操作を追加しても過度に複雑にならないようにアーキテクチャの維持。 - 型安全なKotlin環境でJavaScriptの癖や不一致を処理。 9. **Kotlin Multiplatformの広範な使用**： - 他のAllegroチームも、ディープリンクナビゲーション、ビジネスイベント追跡、デザインシステム要素、API契約などのプロジェクトでKMPを使用。 - KMPは複雑なプロジェクトの簡素化と開発効率の向上に役立つことが証明。 10. **結論**： - Paulinaは、Kotlin Multiplatformが開発プロジェクトでの成功と有用性を強調し、複雑なタスクにおいてその使用を推奨した。 | https://kotlinconf.com/talks/575249/ | https://www.youtube.com/embed/PQSGD9ySuM0?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | https://youtu.be/PQSGD9ySuM0 | ChatGPT4 | |||||||||||||||||
20 | Pamela Hill | Kotlin Multiplatform Alchemy: Making Gold out of Your Swift Interop | Kotlin マルチプラットフォームの錬金術: 迅速な相互運用性から金を生み出す | 2. KMP | こちらはPamela Hill氏による「Kotlin Multiplatform Alchemy: Making Gold out of Your Swift Interop」の要約です： - Pamela Hill氏はJetBrainsの開発者アドボケートで、KotlinとSwiftのインターオペラビリティの課題と可能性について説明しています。 - **KotlinとSwiftの現在のインターオペラビリティの状況**： - Kotlinは間接的にObjective-Cを介してSwiftと互換性があります。 - Kotlinのほとんどの機能は期待通りに動作しますが、一部の機能にはワークアラウンドやコミュニティソリューションが必要です。 - 問題点としては、データクラスや特定の関数タイプなど、サポートされていない機能があります。 - **今日から改善できるKotlin Swiftインターオペラビリティ**： - `@ObjCName`での名前変更、`@ShouldRefineInSwift`での関数の改良、`@HiddenFromObjectiveC`でのObjective-Cからの非公開化などのテクニックがあります。 - `@KOC`コメントを使ったドキュメンテーションがAPIの明確さと使用方法を向上させます。 - **インターオペラビリティの小さな秘訣8つ**： - エラーの処理、インターフェースの改良、`KMP Native Coroutines`などのライブラリを使った非同期プログラミングの管理などのテクニックとAPIソリューションが紹介されています。 - **JetBrainsによるSwift Exportプロジェクト**： - KotlinのSwiftインターオペラビリティ体験を向上させることを目的としたプロジェクトで、生成されるAPIの精緻化、より多くの言語機能のサポート、IDEツールの統合の改善が計画されています。 - Kotlinのモジュール/パッケージ構造をSwiftの単一モジュールアプローチに合わせることの課題も取り上げられています。 - **設計プロセスの例**： - Kotlinのモジュール/パッケージをSwiftのモジュールにマッピングする際の設計課題について議論されています。Swiftのネストモジュールと循環依存の制約に対応する必要があります。 - **まとめ**： - KotlinとSwiftのインターオペラビリティには課題がありますが、現在のテクニックを活用し、Swift Exportプロジェクトの展望に期待して、よりシームレスなクロスプラットフォーム開発体験が実現することを強調しています。 この要約は、Pamela Hill氏がKotlinとSwiftの深い統合について行った議論の要点を捉えています。 | https://kotlinconf.com/talks/577200/ | https://www.youtube.com/embed/P_5ZEtK05kc?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | ChatGPT3 | ||||||||||||||||||
21 | Sumayyah Ahmed | Making the Big Kotlin Multiplatform Decision | Kotlin マルチプラットフォームに関する大きな決定を下す | 2. KMP | 「Kotlin Multiplatformを採用すべきか？」重要なポイント10選 1. **KMPは時間を節約するか？：イエスでもありノーでもある** - 事前コスト（ビルド、CI設定、学習曲線）は高い。 - メンテナンスコストはネイティブプロジェクトとほぼ同じ。 - 新機能でコードを共有する場合に時間の節約が起こる。 2. **KMPは「一度書けば終わり」か？：ほとんどイエス** - 共有ビジネスロジックはこれに大きく恩恵を受ける。 - プラットフォーム固有のコードが必要な場合もある。 - 共有ロジックのデバッグは容易になる。 3. **KMPはお金を節約するか？：イエスでもありノーでもある** - 機能ごとのコストは減少する。 - KMP専門家の雇用とネイティブ専門知識の維持が節約を相殺する可能性がある。 - 組織全体がKMPを採用した場合に大幅な節約が起こる。 4. **KMPは低リスクか？：ほとんどイエス** - React NativeやFlutterよりも後戻りしやすい。 - KMP専門家の確保と維持はリスク。 - iOS開発者からの感情的、文化的な抵抗が要因となる可能性がある。 5. **KMP採用が容易な場合：** - 強いユースケースがある（ドリフト、一貫性）。 - チームが小さく、製品がシンプルである。 - Greenfield開発であるか、レガシーコードが限定的である。 - チームメンバーがKMPに熱心である。 6. **KMP採用が困難な場合：** - ネイティブインフラへの多大な投資が存在する。 - パフォーマンスまたはセキュリティが最優先事項である。 - カスタムの非標準フレームワークが使用されている。 - 即時デリバリーが必要である。 7. **重要な決定要因：** - KMPが解決する問題（リスク、コードのドリフト、ペインポイント）。 - チームへのリスク（リソース、現在の実装）。 - チームの能力と専門知識（学習曲線、KMP専門家の有無）。 8. **成功への最適化：** - 明確な成功基準を定義する（リスク軽減、機能提供）。 - 小さく独立したモジュールから始めて、より迅速な成果と専門知識の構築を目指す。 9. **人材は重要：** - iOS開発者の感情や懸念を考慮する。 - 組織文化とリーダーシップの姿勢が役割を果たす。 10. **KMPはツールである：** - 魔法の弾丸ではない。 - 特定のニーズと状況に適合するか評価する。 - 実用的かつ情報に基づいた意思決定を行う。 | https://kotlinconf.com/talks/587119/ | https://youtu.be/oqEU8Rb7XYQ | Gemini | KotlinFest | |||||||||||||||||
22 | Salomon Brys | Using C & native platforms in Kotlin : Building a multi-platform advanced library | Kotlin での C およびネイティブ プラットフォームの使用 : マルチプラットフォームの高度なライブラリの構築 | 2. KMP | 以下は「Using C and native platforms in Kotlin | Salomon Brys」の内容の要約です： 1. Kotlin MultiplatformとCompos Desktopを使用して、CとネイティブプラットフォームをKotlinで利用する方法を説明。 2. サポートされているプラットフォームにはJVM（およびAndroid）、Appleデバイス（iOSなど）、Windows、Linux、Web（Wasm、JS）が含まれる。 3. C APIをKotlin Multiplatformプロジェクトで使用する際の課題として、標準化された方法がないことが挙げられる。 4. 外部のCライブラリ（例えば、OpenSSLのsha256やsecp256k1）を統合する際、各プラットフォームごとに異なるアプローチが必要。 5. JNIを使用して、AndroidとJVM向けのライブラリとしてCコードを統合する手順も解説。 6. Objective-Cを介してSwiftのAPIをKotlin Multiplatformに統合する方法についても説明。 7. Windowsの場合は、CLR（Common Language Runtime）を介してCコードを統合する方法が複雑であることが触れられている。 8. 最後に、JS向けのライブラリ（npm依存など）を統合する手法についても述べられています。 このプレゼンテーションでは、異なるプラットフォームでのCとネイティブAPIの統合における課題と解決策が詳細に説明されています。 | https://kotlinconf.com/talks/576195/ | https://www.youtube.com/embed/w_mkLrzb_I4?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | ChatGPT3 | ||||||||||||||||||
23 | Stanislav Erokhin | KMP libraries evolution: format and publication model | KMP ライブラリの進化: フォーマットと出版モデル | 2. KMP | 以下はスタニスラフ・エロヒン氏による「KMPライブラリの進化」に関する要約です。 はじめにと概要: JetBrainsのコンパイラリードであるスタニスラフ・エロヒン氏が、KMPライブラリの進化について説明します。 KMPテクノロジーの理解が、ライブラリのシームレスな統合とデバッグにどれだけ重要かを強調します。 コンパイラの構造と基本用語: コンパイラのフロントエンドとバックエンドの役割について説明します。 JVMとネイティブプラットフォーム向けのコンパイルをKIPファイルを使って異なる方法で行うことを示します。 ライブラリの公開プロセス: KMPライブラリをMaven Centralに公開するプロセスを説明します。 異なるプラットフォームターゲット向けにKIPファイルを生成する詳細を示します。 ホスト要件とプラットフォームの制限: 現在、AppleプラットフォームのバイナリはmacOSでしか生成できないツールチェーンの制約について述べます。 macOSを必要とする特定のケースを除いて、どんなホストからでもKMPライブラリの生成を許可するための将来の計画について議論します。 フォーマットの変更と簡素化: 複数のメタデータファイルを単一のアーティファクト（UKファイル）に統合する提案をします。 メタデータの複雑さを減らすことで、ビルドシステム間の依存関係の解決を簡素化する目的を示します。 互換性とバージョニング: ライブラリバージョン間でのバイナリ互換性の維持における課題に焦点を当てます。 ライブラリ開発者向けのバイナリ互換性検証ツールの導入を紹介します。 将来の方向性と課題: クロスプラットフォームライブラリ開発を簡素化するためのUniversal KPS（Universal Common Code）の計画について議論します。 inline関数の取り扱いやプラットフォーム固有の依存関係の課題など、進行中の課題を述べます。 今後の変更: どんなホストからでもKMPライブラリの生成を許可するタイムライン（2.1リリース）を示します。 フォーマットの統一（2.2リリース）およびプラットフォーム間でのinline関数の挙動の標準化について説明します。 まとめ: 新しいツールとフォーマットの採用を奨励し、ライブラリ開発と統合の円滑化に向けた質問を受け付けます。 この要約は、コンパイラのメカニズム、公開プロセス、フォーマットの簡素化、互換性の問題、そしてKMPライブラリの将来的な発展に焦点を当てています。 | https://kotlinconf.com/talks/582224/ | Internal | |||||||||||||||||||
24 | Jason Parachoniak | Kotlin Multiplatform in Google Workspace | Google Workspace の Kotlin マルチプラットフォーム | 2. KMP | 以下は、Jason Parachoniak 氏による「Google Workspace における Kotlin Multiplatform」に関するトークの要約です： - **紹介と背景**: Google Workspace の Jason Parachoniak 氏が、Kotlin Multiplatform（KMP）とそのエコシステム内での採用について説明します。 - **Google におけるマルチプラットフォームの歴史**: Gmail や Docs などでの一貫したユーザーエクスペリエンスの実現に向け、Google は10年以上にわたりマルチプラットフォームソリューションを活用してきました。 - **ビジネスロジックへの焦点**: 生産性アプリにおいて特に重要なビジネスロジックのターゲティングに注力し、一貫したユーザーエクスペリエンスを確保します。 - **Kotlin Multiplatform への移行**: Google は、Google Docs を始めとするアプリで Kotlin Multiplatform に移行しており、パフォーマンスメトリクスの既存のコード注釈を活用して改善を進めています。 - **課題と解決策**: - **ビルドパフォーマンス**: ビルドには Bazel を使用し、キャッシュやコンパイラ最適化の問題に対処しています。 - **ランタイムレイテンシ**: Kotlin Native のガベージコレクション改善に関する JetBrains チームとの協力。 - **パフォーマンスの問題**: インタープレイヤーレイヤーでの文字列パフォーマンスなど、さまざまな問題に対処しています。 - **ヒープダンプツール**: Kotlin Native でヒープダンプを分析するツールの開発と、インフラ改善の上流への貢献。 - **技術的な課題と解決策**: - LLVM ビットコード生成の最適化に向けた取り組み。 - LLVM と JVM チームとの協力による互換性の問題の解決。 - **今後の方向性**: メトリクスとフィードバックの収集を続け、Google Workspace アプリ間でのコードの標準化を進め、完全な Kotlin 採用に向けて進展する予定です。 最後に、Jason は、JetBrains と Android チームとの協力を強化し、Kotlin Multiplatform の更なる進化を目指すと述べています。 | https://kotlinconf.com/talks/581520/ | https://www.youtube.com/embed/5sOXv-X43vc?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | |||||||||||||||||||
25 | Annyce Davis | KMP in Action: A Production Case Study | KMP の実際の運用: 生産ケーススタディ | 2. KMP | Annyce Davisの講演「KMP in Action: A Production Case Study」の主なポイントを以下にまとめました： 1. **Kotlin Multiplatform（KMP）の紹介**：Annyce Davisは、KMPがどのように開発プロセスを変革し、プラットフォーム間でコードを共有することで、創造性を高め、実行速度を向上させるかについて説明しました。 2. **支持の獲得**：KMPを導入するためには、経営陣の支持を得ることが重要です。コストメリット、より早い市場投入、そして一貫したユーザー体験を強調することで、ステークホルダーを納得させます。 3. **探索フェーズ**：初期段階で予備的なアーキテクチャを確立し、統合について決定することが重要です。KMPの柔軟性は、SwiftUIやJetpack Composeのような宣言的フレームワークでの作業を容易にしました。 4. **課題への対応**：iOSエンジニアは当初、複雑さや仕事の安全性の脅威を理由に抵抗しました。協力を奨励し、懸念に対処することで抵抗を軽減しました。 5. **チームの形成**：KMPプロジェクトの成功には、強力なKotlinエンジニア、優れたコミュニケーター、柔軟なメンバーが必要です。チームの構成と明確な役割分担が重要です。 6. **開発フェーズ**：最初はビジネスロジックと共通コードを共有することでうまくいきました。時間が経つにつれて、チームはモノレポ（モノリシックリポジトリ）を提案し、さらに開発を効率化しました。 7. **テストとフィードバック**：質的なユーザーインタビュー、量的な分析、内部での試用を組み合わせて包括的なフィードバックを得ました。専用のSlackチャンネルを設けることで、継続的な入力を促進しました。 8. **パフォーマンスの向上**：KMPでコードを統合することで、共通のGraphQLクエリを使用することでキャッシングが改善され、iOSアプリが高速化しました。 9. **iOSとAndroid開発者のニーズへの対応**：オフサイトを開催してiOS開発者にKMPを教え、Android開発者がiOS開発を学ぶことを奨励し、より一体感のあるチームを作りました。 10. **長期的なメリットとアドバイス**：KMPを採用することで、機能の提供速度が速まり、コスト削減が実現しました。Davisは、開発者に新しい技術を試し、チーム内で建設的な提案を行うことを奨励しています。 | https://kotlinconf.com/talks/585329/ | ||||||||||||||||||||
26 | Oliver Okrongli | Mastering Concurrency: End-to-End Stress Testing with Kotlin Multiplatform | 同時実行性の習得: Kotlin マルチプラットフォームを使用したエンドツーエンドのストレス テスト | 2. KMP | **要約: 「Kotlinマルチプラットフォームによる並行性のエンドツーエンドストレステスト – Oliver Okrongli」** 1. **はじめに**: Oliver Okrongli氏は、Kotlinマルチプラットフォームを使用した並行性バグのエンドツーエンドストレステストについて説明します。 2. **並行性の理解**: 並行性は、複数のタスクを重なり合う時間帯に実行することで、逐次実行に対するものです。効率と応答性を向上させます。 3. **並行性の重要性**: CPUとエネルギーを効率的に使用し、特に現代のリアクティブフロントエンドとバックエンドシステムでアプリケーションの応答性を維持するために不可欠です。 4. **並行性テスト**: ユニットテスト、サービステスト、エンドツーエンドテストなどの異なるテスト層は、異なるレベルの並行性カバレッジを提供しますが、通常のテストではシステム全体の並行性の問題を見逃しがちです。 5. **ストレステスト戦略**: ストレステストは、単一のJVM上でシステム全体を統合して、実際の大量並行性をシミュレートし、効率的なテストとデバッグを可能にします。 6. **Kotlinマルチプラットフォームのセットアップ**: バックエンドとフロントエンドクライアントにはKtorを使用し、UIにはComposeを使用します。このセットアップにより、すべてのプラットフォームで共通のコードが確保され、テストが簡素化されます。 7. **フロントエンドのストレステスト**: 複数のフロントエンドを起動し、大量の更新を行うことで並行性ストレステストを行い、バグを引き起こします。ゲートやエベンチュアル関数などの技術を使用して非決定性を管理します。 8. **並行性バグのデバッグ**: スタックトレースやロギングなどの標準ツールは不十分なことが多いです。デバッグトレースは特定のオブジェクトに関する焦点を絞った情報を提供し、より効果的です。 9. **デバッグツールの組み合わせ**: CoTestの手がかりを使用して、デバッグトレースとスタックトレースを組み合わせることで、バグを診断するための包括的なコンテキストが提供され、複雑な並行性の問題をデバッグしやすくします。 10. **結論**: 単一のJVM上で分散システムを統合し、Kotlinマルチプラットフォーム、Ktor、Composeを使用し、高度なデバッグ技術を活用することで、並行性バグを本番環境に到達する前に検出して解決する能力が向上します。 | https://kotlinconf.com/talks/547002/ | https://youtu.be/ndQ0Ehv1RuI | |||||||||||||||||||
27 | Simon Vergauwen | Unlocking the Power of Arrow 2.0: A Comprehensive Guide | Arrow 2.0 の力を解き放つ: 包括的なガイド | 3. Framework/Library | 1. **イントロダクションと背景**: - ベルギー出身のサイモン・ベルガウウェンがKotlinのArrow 2.0について説明。 - 彼の経験はバックエンド、フロントエンド、関数型プログラミング、オブジェクト指向プログラミングに及ぶ。 2. **Arrowの目的**: - Kotlinはすでにエレガントで型安全なコードを書くための素晴らしい機能を提供しているが、Arrowはそれをさらに進めるためのツール。 3. **DSLの紹介**: - ArrowでのDSL（ドメイン固有言語）の使用方法を説明。 - 具体的には、最も小さなモジュールであるautoclose DSLを紹介。 4. **Typed Error Handling**: - 型付きエラーハンドリングの重要性と方法について。 - 例として、プレミアムユーザー登録フローを構築。 5. **エラーモデルとレイヤリング**: - 独自のエラーモデルを使用して、異なるドメインのエラーを統合する方法。 - コンテキストパラメータを使用してレイヤリングの必要性を解消。 6. **再試行とスケジューリング**: - Arrowのスケジュールタイプを使用した再試行メカニズムの説明。 - 例として、エクスポネンシャルバックオフを紹介。 7. **分散トランザクション管理**: - Sagaパターンとトランザクションを使用した分散トランザクションの処理方法。 - Sagaスコープとコンテキストパラメータを使用して、トランザクションのロールバックを実現。 8. **Arrow Optics**: - Arrow Opticsを使用して、ネストされた不変データ構造を簡単に操作する方法。 - データクラスやコレクションの変換を効率化。 9. **結論と今後の展望**: - ArrowとKotlinの相性の良さを強調。 - Arrowの小さくて特定の機能に特化したモジュールの利点について。 10. **コミュニティとリソース**: - Kotlin SlackやArrowのウェブサイトなどのリソースを紹介。 - プレゼン資料やコードサンプルはGitHubで公開されている。 | https://kotlinconf.com/talks/586193/ | https://www.youtube.com/embed/JcFEI8_af3g?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | https://youtu.be/JcFEI8_af3g | ChatGPT | |||||||||||||||||
28 | Alexander Sysoev | kotlinx.rpc – a brand new approach for multiplatform RPC | kotlinx.rpc – マルチプラットフォーム RPC のためのまったく新しいアプローチ | 3. Framework/Library | 以下は、"kotlinx.rpc – a brand new approach for multiplatform RPC" の要点のまとめです： 1. **kotlinx.rpcの紹介**：JetBrainsのソフトウェア開発者、Alexander Sysoevが、Kotlinのkotlinxファミリーから新しいライブラリであるkotlinx.rpcを紹介しました。このライブラリはリモートプロシージャコール（RPC）を簡素化することを目的としています。 2. **RPCとは？**：RPCはリモートプロシージャコールの略で、1台のマシンが別のマシン上の関数を実行することを可能にします。これは分散アプリケーションに有用です。 3. **基本的なセットアップ**：kotlinx.rpcのセットアップは簡単で、Gradle設定にいくつかのプラグインと依存関係を追加するだけです。 4. **RPCサービスの定義**：共通コードにRPCサービスを定義し、任意のRPCインターフェースとしてマークし、関数を定義します。 5. **マルチプラットフォーム対応**：kotlinx.rpcはマルチプラットフォーム対応で、さまざまなKotlinバージョンに対応しています。 6. **コルーチンの活用**：kotlinx.rpcはコルーチンを利用して、リクエストやサービスのライフタイム管理を行います。 7. **シリアライズのサポート**：データクラスをシリアライズ可能にすることで、ライブラリはシリアライズプロセスを自動的に処理します。 8. **クライアントとサーバーの実装**：クライアントコードとサーバーコードは、それぞれRPCクライアントとRPCサーバーエンティティを使用して、サービス間の通信を管理します。 9. **ストリーミングのサポート**：kotlinx.rpcはフローをサポートし、クライアントからサーバーへのデータストリーミングやその逆も可能です。 10. **今後の展望**：ライブラリはまだ実験的ですが、将来的にはより多くのサービス機能、インテグレーション、gRPCのサポート、完全なマルチプラットフォーム対応を目指しています。ユーザーからのフィードバックを募集中です。 | https://kotlinconf.com/talks/586856/ | https://youtu.be/C13v_FXmhvU | ChatGPT | KotlinFest | |||||||||||||||||
29 | Aaron ToddIan Botsford | Generating Kotlin SDKs with Smithy | Smithy を使用した Kotlin SDK の生成 | 3. Framework/Library | **Smithyを使ったKotlin SDKの生成 – Ian Botsford、Aaron Todd** - **Smithyの紹介**: Smithyは、サービスやクライアント（SDK）を構築するためのツールキットで、AmazonやAWSで広く使用されています。独自のインターフェース定義言語（IDL）を持ち、サービス、その操作、および機能を定義します。 - **歴史と目的**: Smithyは、初期のAWSサービスフレームワークの課題に対応するために開発されました。モデルベースでプロトコルに依存しないアプローチを提供し、サーバーサイドおよびクライアントサイドのコード生成を念頭に置いて設計されています。 - **モデルの重要性**: Smithyのすべてはモデルを中心にしており、APIレビューのプロセスの一部として使用されます。モデルは宣言型コードであり、ソースコントロールにチェックインされ、レビューや差分比較が可能です。 - **コード生成の利点**: Smithyの主要な設計決定の多くは、コード生成を第一級の機能として構築されています。これにより、モデルからコードを生成し、それに基づいてデモアプリケーションを構築できます。 - **実例デモ**: デモでは、Smithyを使用してKotlinコードを生成し、それに基づいてデモアプリケーションを作成しました。このプロセスには、サービスの作成、リーダーボードの作成とリスト、ハイスコアの送信などが含まれます。 - **将来の展望**: Smithyは現在、Rust、Swift、Kotlin用の最新のSDKを含むすべての新しいAWSサービスとクライアントに使用されています。今後はKotlin Nativeや他のプラットフォームサポートの追加、サーバーサイドコード生成のサポート強化を計画しています。 - **コミュニティの参加**: GitHubでのフィードバックやコントリビューションを通じて、Smithyの改善に参加できます。ユーザーのフィードバックは、開発の優先順位を決定する上で非常に重要です。 - **まとめと質疑応答**: プレゼンテーションの最後に、参加者はセッションの投票を行い、Q&Aセッションが行われました。 | https://kotlinconf.com/talks/577491/ | https://www.youtube.com/embed/Wsra04prG-E?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | |||||||||||||||||||
30 | Chantal Loncle | Exploring the Exposed Library: A Kotlin Solution to Database Access | Exposed ライブラリの探索: データベース アクセスへの Kotlin ソリューション | 3. Framework/Library | 承知いたしました。以下に、日本語で要約したものを箇条書きで示します。 **Exposed ライブラリ概要** 1. **歴史:** JetBrains が社内利用のために開発し、後にオープンソース化されたデータベースアクセスライブラリです。 2. **メンテナンス:** 当初は主にコミュニティによってメンテナンスされていましたが、現在はJetBrainsの専任チームが担当しています。 3. **人気:** JetBrainsの公式製品ではありませんが、GitHub上でのスター数はJetBrainsのリポジトリの中で6番目に多いです。 4. **最近の進捗:** チームは、機能リクエストやバグ修正を含む、未解決の問題の大部分を解決しました。 5. **コミュニティ貢献:** コミュニティのサポートと貢献は、プロジェクトの進捗にとって不可欠です。 6. **目標:** ドキュメント、マイグレーションサポート、IDEツーリングに焦点を当て、安定版1.0リリースを目指しています。 7. **データベースにとらわれない:** 様々なデータベースの違いを抽象化する一貫したAPIを提供します。 8. **接続設定:** `databaseConnect`関数を使用して、接続の詳細を含むデータベースインスタンスを作成します。 9. **データマッピング:** Kotlinのデータクラスを、`Table`オブジェクトと`Column`定義を使用してデータベーステーブルにマッピングします。 10. **クエリと更新:** データのクエリ、更新、削除にDSLとDAOの両方のアプローチを提供します。 不明な点がありましたら、お気軽にお尋ねください。 | https://kotlinconf.com/talks/586918/ | https://youtu.be/YOXWnM_8vz8 | Gemini | KotlinFest | |||||||||||||||||
31 | Erik Westenius | Compose beyond the UI: Molecule at Swedish Railways | UI を超えた Compose: スウェーデン鉄道のMolecule | 3. Framework/Library | 以下は「スウェーデン鉄道でのUIモレキュールを超えたコンポーズ」エリック・ウェステニウスの講演の要約です： 1. **導入**：エリック・ウェステニウスがスウェーデン鉄道でのUIモレキュールを超えたコンポーズについて講演。 2. **UIモレキュールの概念**：ユーザーインターフェースの構築ブロックとしてのUIモレキュールの概念を説明。 3. **課題**：スウェーデン鉄道でのUIコンポーズにおける課題を議論。 4. **高度なコンポーズ技術**：基本的なモレキュールレベルを超えたUI要素の高度なコンポーズ技術を紹介。 5. **ケーススタディ**：これらの高度な技術が実装されたスウェーデン鉄道の具体例を提示。 6. **利点**：これらの高度なコンポーズ技術を使用することで、ユーザー体験の向上や開発プロセスの効率化などの利点を強調。 7. **ツールとフレームワーク**：プロセスで使用されたツールやフレームワークについて言及。 8. **ベストプラクティス**：UIコンポーズのベストプラクティスと、それを実際のプロジェクトに適用する方法を共有。 9. **学んだ教訓**：スウェーデン鉄道での実装から得られた教訓を議論。 10. **Q&Aセッション**：聴衆からの質問に答えるQ&Aセッションで締めくくり。 | https://kotlinconf.com/talks/587019/ | https://youtu.be/XWk_FJm5fEU | https://youtu.be/XWk_FJm5fEU | Later | |||||||||||||||||
32 | Ehsan MehranvariChristian Fredriksson | Turbocharge Your Data: Harnessing Kotlin and gRPC to Handle Real-Time Data From Connected Cars | データをターボチャージ: Kotlin と gRPC を利用してコネクテッド カーからのリアルタイム データを処理する | 3. Framework/Library | 以下の内容を要約します。最大10個の箇条書きで表現します。 - タイトル: "Turbocharge Your Data: Harnessing Kotlin and gRPC to Handle Real-Time Data From Connected Cars" - プレゼンターは、WVO Carsのソフトウェアエンジニア、AsanさんとChristianさん。 - gRPCとは、リモートプロシージャコール（RPC）のためのプロトコルで、スキーマ駆動であり、Protocol Buffers（ProtoBuf）を使用してデータを定義し、自動生成されたクライアントスタブとサーバー実装を提供する。 - Volvo Carsは、2018年ごろにgRPCを導入し、iOSとAndroidでのサポートが良好であり、バックエンドサービス間での使用が自然だった。 - gRPCの利点は、スキーマ定義型であり、コンパクトで高性能なデータシリアライズを提供する点にある。 - HTTP/2を利用し、単一のリクエストと複数のデータフレームを使用して通信を効率化する。 - リアルワールドの例として、車両からの位置情報をストリーミングするサーバーストリーミングコールが示された。 - gRPCを使用した実装では、サービス間通信の効率性が向上し、リアルタイムデータの取得を実現する。 - エラーハンドリングについても触れ、gRPCクライアントが自動的にリトライポリシーを適用してサーバーの可用性問題に対処できることを示した。 - サービス設定の適用により、エクスポネンシャルリトライポリシーを設定し、サーバーの障害回復を確認した。 - gRPCを用いることで、モバイルアプリからのリアルタイムデータの効率的な取得と更新が可能になることを強調した。 | https://kotlinconf.com/talks/570564/ | https://youtu.be/NwneaxZFPDo | Server? Case Study | ||||||||||||||||||
33 | Arnaud Giuliani | Android, Compose, Multiplatform & Server - Inject them all with Koin | Android、Compose、マルチプラットフォーム、サーバー - すべてを Koin で注入 | 3. Framework/Library | こちらは「Android、Compose、Multiplatform＆Server - Koinで注入するすべて | Arnaud Giuliani」の要約です： - Arnaud Giuliani氏はKotlin向けの依存性注入フレームワークであるKoinを紹介しました。 - Koinは2017年に開始され、モバイルアプリケーションで広く使用されています。 - Jetpack Composeとの統合により、依存関係の注入がシームレスに行えます。 - Composeでは、ローカル依存関係には`coinInject`、ビューモデルには`coinViewModel`を使用します。 - ComposeとKoinを設定するには、`coinContext`または`coinAndroidContext`を使用します。 - Koinは共有コードとプラットフォーム固有の実装をサポートし、`expect`と`actual`を使用します。 - バックエンド開発では、KoinはKtorとの統合を通じて効率的な依存性注入を提供します。 - 将来の計画には、Kotlin 2.0向けのKoin 4.0が含まれ、DSLとツールサポートの向上が焦点です。 - Koinは企業向けのサポートや、Kotlinマルチプラットフォームアプリケーションの監視とデバッグツールを提供しています。 - コミュニティとの連携は、Slack、GitHub、Twitter、Koinのウェブサイトを通じてフィードバックやリソースの提供が奨励されています。 | https://kotlinconf.com/talks/625045/ | https://www.youtube.com/embed/ih_ChWaCFcU?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | ChatGPT3 | ||||||||||||||||||
34 | Jan Holesovsky | Kotlin/Native BigDecimal - a drop-in replacement for java.math.BigDecimal | Kotlin/Native BigDecimal - java.math.BigDecimal のドロップイン代替品 | 3. Framework/Library | 1. **Kotlin/Native BigDecimalの紹介**: Jan Holesovskyが、科学計算用のアプリに使用される`BigDecimal`クラスをKotlin/Nativeに移植することについて説明しています。 2. **移植の目的**: 古いAndroidアプリをiOSで再開発することなく、共通APIを使ってクロスプラットフォーム開発をサポートすることが目的です。 3. **BigDecimalの概要**: `BigDecimal`は、大きな数値や多くの小数点以下の桁数を正確に表現・操作するためのJavaパッケージで、金融や科学計算に不可欠です。 4. **実装の課題**: 既存のマルチプラットフォーム向けBigDecimal実装は、彼らのアプローチと互換性がなく、iOS向けの`NSDecimalNumber`は38桁の精度制限があるため不十分でした。 5. **解決策**: Android Open Source Projectの`BigDecimal`実装を移植することに決定しました。この実装は、大きな素数を扱う計算タスクにOpenSSLを使用しています。 6. **変換プロセス**: JavaからKotlinへのファイルごとの逐次変換を行い、互換性の問題を解決しつつコードのビルド可能性を保ちました。 7. **Cライブラリとのインターフェース**: Java Native Interface (JNI)技術を使用して、OpenSSL用のKotlinバインディングを作成するための大規模な作業が必要でした。 8. **利用されたKotlinの機能**: `mempool`を使ったメモリアロケーションや、配列へのポインタを提供するための`pin`など、Kotlin特有の機能がCとの互換性に重要でした。 9. **デバッグと安定性**: デバッグには、計算エラーやクラッシュの解決が含まれ、特に`InvalidMutabilityException`が大きな課題でしたが、Kotlin 1.7.20の新しいメモリマネージャーで解決しました。 10. **配布とドキュメント**: バイナリパッケージを作成し、GitHubで公開しました。包括的なドキュメントも提供しており、将来的にはMaven Centralなどのパッケージマネージャーを通じての統合を計画しています。 | https://kotlinconf.com/talks/579085/ | https://youtu.be/-or1np8tO64 | CjatGPR4 | ||||||||||||||||||
35 | Simon Billingsley | Using Vertx with Kotlin | Kotlin で Vertx を使用する | 3. Framework/Library | 1. **Vert.xとKotlinの紹介**: Simon Billingsleyは自己紹介をし、Java、Kotlin、Vert.xでの豊富な経験について述べています。彼は英国に拠点を置く金融サービススタートアップCodyで働いています。 2. **Vert.xの概要**: Vert.xはJVM上でリアクティブなアプリケーションを構築するためのツールキットで、複数のイベントループとノンブロッキングI/Oをサポートしており、Nettyを基盤としています。 3. **Vert.xインスタンスの作成**: Vert.xアプリケーションのメインメソッドでは、単一のVert.xインスタンスが作成され、複数のイベントループを処理し、アプリケーションロジックが開始されるメインのヴァーティクルをデプロイします。 4. **ヴァーティクルのデプロイ**: ヴァーティクルのデプロイは非同期で行われ、Futureを返します。onSuccessとonFailureイベントの処理が重要で、コルーチンコンテキストを使用してコルーチンを管理します。 5. **Webヴァーティクルの実装**: WebヴァーティクルはHTTPリクエストを処理するためのルーターを作成し、コルーチンサポートを活用してノンブロッキング操作を維持し、リクエスト処理をシンプルにします。 6. **HTTPリクエストの処理**: HTTPリクエストは、メソッド、パス、コンテンツタイプなどの基準でルートを設定して管理します。レスポンスはJSON形式で返され、エラーは例外をカスタムエラーレスポンスに変換して処理します。 7. **gRPCの統合**: gRPCヴァーティクルはVert.xのgRPCサーバーにサービスメソッドを登録します。リクエストはオブジェクトに変換され、コルーチンを使用して処理され、シンプルでクリーンなコードを実現します。 8. **データベース接続**: Vert.xはデータベース接続をサポートしており、接続プールが自動的に管理されます。SQLテンプレートとプリペアドステートメントを使用してクエリを実行し、結果をKotlinのデータクラスにマッピングします。 9. **トランザクション管理**: Vert.xはデータベーストランザクションを管理し、成功時にはコミットし、失敗時にはロールバックします。クエリはコルーチン内で実行され、シームレスな非同期操作を保証します。 10. **コード構造とリポジトリ**: アプリケーションはWebおよびgRPCサービス専用のヴァーティクルを中心に構築されており、クリーンで高性能なコードが特徴です。完全なコードはSimonのGitHubリポジトリで参照できます。 | https://kotlinconf.com/talks/585411/ | https://www.youtube.com/embed/S8nW4RzUQLs?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | ChatGPT4 | ||||||||||||||||||
36 | Pim van Gurp | Using FModel to structure architecture from route to event store | FModel を使用してルートからイベント ストアまでのアーキテクチャを構造化する | 3. Framework/Library | 1. **シンプリシティの理解**：スピーカーは、シンプルさは継続的な努力を要し、簡単であることとは異なると強調しています。シンプルな解決策は、複雑さを削減して本質に到達することを含み、簡単な解決策は偶然に生じる可能性があります。 2. **FModelの核心要素**：FModelは、コマンド、イベント、状態の3つの主要な要素に焦点を当てています。コマンドは実行されるアクション、イベントは発生した事実、状態は特定の時点のデータ表現です。 3. **コマンド**：これらは現在形で書かれ、システムに対する意図を設定します。例として「ユーザーを登録する」があります。 4. **イベント**：過去形で書かれ、発生したことを表します。例えば「ユーザーが登録された」が該当します。 5. **状態**：これは特定の時点での現在のデータを表し、過去のイベントから計算できます。システムのステータスのスナップショットを示します。 6. **イベントソーシング**：スピーカーは、現在の状態だけでなく、イベント（発生した事実）をデータベースに保存する重要性を強調しています。これにより、過去のイベントに基づいてどんな状態でも再計算できます。 7. **実践的な応用**：レシピウェブサイトのデモを使用して、コマンド、イベント、状態がどのように相互作用するかを説明しています。コマンドがイベントを引き起こし、それが現在のレシピとキッチンの状態を計算し表示します。 8. **イベントソースシステムの利点**：イベントソーシングにより、過去のアクションやシステム状態に関する複雑な質問に答えるために、履歴データを照会することができ、報告および分析機能が向上します。 9. **実装の詳細**：スピーカーは、FModelを使用してイベントソーシングシステムを設定するために必要なコードの概要を簡単に説明し、コマンドがどのようにしてイベントと状態に進化するかを示しています。 10. **結論**：スピーカーは、シンプルな解決策は実現が難しいものの、価値があり追求するに値することを繰り返し強調しています。特にイベントソーシングシステムでは、時間と履歴データが重要な役割を果たします。 | https://kotlinconf.com/talks/583516/ | https://www.youtube.com/embed/VLuGvEugkGg?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | https://youtu.be/VLuGvEugkGg | ChatGPT4 | |||||||||||||||||
37 | Garth Gilmour | Managing Complexity With Ktor | Ktor を使用して複雑さを管理する | 3. Framework/Library | **Ktorによる複雑性の管理 | Garth Gilmour - 要約:** 1. **導入とコアバリュー:** - JetBrainsのデベロッパーアドボケイトであるGarth Gilmourが、非同期クライアントおよびサーバーアプリケーションのためのフレームワークであるKtorを紹介。 - Ktorはミニマリスト、柔軟、シンプル、高速を重視し、ボイラープレートやマジックを避けることを目指している。 2. **他のフレームワークとの比較:** - 設定よりも規約を優先するフレームワークとは異なり、Ktorは自動機能を含まないことで、ユーザーが何が起こっているかを理解するようにしている。 3. **ケーススタディアプリケーション:** - Gilmourは、KtorのHTTPクライアントを使用してStack Overflowの質問を取得するスーパーヒーローをテーマにしたアプリケーションを紹介。 - このアプリケーションは、強く型付けされたデータアクセスのためにKotlin DataFrameライブラリを使用してデータを取得し、処理する。 4. **Ktorサービスの作成:** - Ktorサービスを作成する手順：質問タイプの定義、Stack Exchangeクライアントの作成、ルートの設定、およびクライアントをサーバーに埋め込む。 5. **テスト:** - Ktorは簡単なテストアプリケーションの設定と統合テストを提供。 - 効果的なユニットテストを作成するためにモックを使用する重要性を強調。 6. **Koinによる依存性注入:** - Koinは依存性注入を簡素化し、オブジェクトを複数のレイヤーに渡すパターンを避けることができる。 7. **GraphQLの統合:** - GilmourはKtorでのGraphQLの設定方法を示し、クエリを作成し、結果を返すのがどれほど簡単かを示した。 8. **WebSockets:** - KtorのWebSocketsサポートにより、リアルタイムデータストリーミングが可能になり、高頻度の更新が必要なアプリケーションに適している。 9. **Kotlin Multiplatformとネイティブ実行:** - Ktorのクライアントはマルチプラットフォームで、Android、iOS、デスクトップアプリ、Kotlin Nativeをサポートし、高速なネイティブ実行ファイルの作成が可能。 10. **高度な機能:** - Gilmourは、監視用のOpenTelemetryやリクエスト再試行の細かな制御など、Ktorの柔軟性と強力な機能セットを紹介。 11. **コミュニティとエコシステム:** - コミュニティの貢献とプラグインの開発を重視し、活気あるKtorエコシステムを促進。 - Ktorプロジェクトジェネレーターの使用を奨励し、プラグインレジストリへの参加を呼びかけた。 | https://kotlinconf.com/talks/587400/ | https://www.youtube.com/embed/RiNRQNLcpj8?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | |||||||||||||||||||
38 | Rafael Roman | From Code to Streams: A Kotlin Odyssey with Apache Flink | コードからストリームへ: Apache Flink を使用した Kotlin の旅 | 3. Framework/Library | 1. **自己紹介と背景**: - ラファエル・ロマンはブラジル出身で、現在はバルセロナに住み、Personioで働いています。 - この講演では、彼が以前働いていたデジタル銀行N26での経験に焦点を当てています。 2. **金融犯罪防止の課題**: - 即時金融取引の必要性から、バッチ処理からリアルタイムの不正検出への移行が求められました。 - SEPAやクレジットカードなど、複数のソースからのデータを統合して顧客行動を把握することが重要でした。 3. **リアルタイムデータ処理におけるFlinkの役割**: - Flinkは様々なデータソースを処理し、リアルタイムで複雑な集計を行う能力が評価されました。 - Flinkのシステムアーキテクチャは、ジョブマネージャー、タスクマネージャー、複雑なタスク実行環境で構成されています。 4. **並行処理と状態管理**: - Flinkのアーキテクチャにより並行処理が難しい場合があります。タスクスロットを使用してスレッドを実行します。 - Flinkはローカル状態ストレージとセーブポイントを提供し、ジョブの再起動時に状態を管理します。 5. **シリアライゼーションの問題**: - FlinkのCryoシリアライザ依存は、スキーマ進化に問題を引き起こす可能性があります。 - 安定性のためにカスタムシリアライザやAvro、Protobufなどの代替シリアライゼーションフレームワークを使用することを推奨します。 6. **パフォーマンスの考慮事項**: - Flinkでの過度のログ記録はバックプレッシャーとパフォーマンスのボトルネックを引き起こします。 - 適切なシリアライゼーションがパフォーマンスに不可欠であり、CryoよりもPojoや他の最適化されたシリアライザが好ましいです。 7. **ジョブグラフと状態の管理**: - FlinkのジョブグラフIDを慎重に管理し、ジョブの更新時に状態の一貫性を確保します。 - グラフ内の各ノードに固有のIDを設定することで、状態進化をスムーズに管理できます。 8. **ベストプラクティスと推奨事項**: - スキーマ進化を徹底的にテストします。 - Flinkジョブを小規模かつ管理しやすく保ち、更新とメンテナンスを容易にします。 - アプリケーションのプロファイルを作成し、最適なパフォーマンスを確保します。 9. **結論と主要なポイント**: - Flinkは強力である一方で、複雑なリアルタイムデータ処理ツールです。 - 適切なシリアライゼーションと状態管理に注意を払うことで、KotlinをFlinkと効果的に使用できます。 - リアルタイム処理には、状態、シリアライゼーション、ジョブアーキテクチャの慎重な計画と管理が必要です。 10. **観客との対話**: - 観客はKotlinのシリアライゼーションとイベントの関係処理について質問しました。 - ラファエルはカスタムシリアライザを使用したKotlinのシリアライゼーションと、Flinkのウォーターマーキングがイベントの関係をどのように処理するかについて説明しました。 | https://kotlinconf.com/talks/551172/ | https://youtu.be/sYo06vkLkC4 | |||||||||||||||||||
39 | Johannes SvenssonParthasarathy Muruganandam | Compose Multiplatform on mobile at Instabee for over a year | 1 年以上 Instabee でモバイル上の Compose Multiplatform | 4. Compose | 1. **導入**：InstabeeのリードAndroid開発者であるヨハネスと彼の同僚パートが、Instabeeでのモバイル向けCompose Multiplatformの1年以上の経験について話しました。 2. **早期採用**：Instabeeは、iOSをサポートする必要性から、まだアルファ版であったCompose Multiplatformを早期に導入しました。これは、すでにKotlinとComposeで構築された既存のAndroidアプリを持っていたためです。 3. **会社の背景**：Instabeeは、スマートロッカーと宅配サービスを利用してラストマイル配送を専門とするスウェーデンの物流技術会社です。 4. **決断の背景**：JetBrainsがCompose for iOSのアルファ版を発表した際、Instabeeは既に生産環境で数ヶ月間使用しており、Compose Multiplatformの採用を決断しました。 5. **技術的な詳細**：講演では、プラットフォームのパリティ、ツール、テスト、アーキテクチャについての技術的な詳細が説明されました。具体的には、AndroidとiOSの両方でカメラプレビューを表示するためのUIキットビューの使用方法が紹介されました。 6. **ツールの利用**：InstabeeはAndroid StudioとKotlin Multiplatform Mobileプラグインを使用しており、単一のIDEでAndroidとiOSアプリの実行およびデバッグを行っています。 7. **テストの実施**：共通UIテストのサポートが追加され、共通テストターゲットでテストを実行することで、AndroidとiOSの両方でテストを実施できるようになりました。 8. **開発の進行**：Compose Multiplatformの採用により、コードの40%を削減し、生産性を2倍に向上させました。 9. **課題と改善**：初期のビルド速度の問題やiOSライブラリの統合の課題がありましたが、Kotlinの更新により多くの問題が解決されました。 10. **将来の展望**：InstabeeはCompose Multiplatformのさらなる発展に期待しており、SwiftインターオペラビリティやSwift Package Managerのサポートなど、新しい機能を取り入れる予定です。 | https://kotlinconf.com/talks/584799/ | https://www.youtube.com/embed/HNFi7dw_mp8?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | ChatGPT | ||||||||||||||||||
40 | Thomas Künneth | There's more than a mouse - how to truly integrate your app on the Desktop | マウスだけではありません - アプリをデスクトップに真に統合する方法 | 4. Compose | - 「There's More Than a Mouse」というタイトルのトークは、Thomas Künnethがデスクトップアプリを統合する方法について話しています。 - プレゼンテーションでは、デスクトップの定義、メニューバー、複数ウィンドウの管理、ファイル関連付けの4つの主要トピックを取り上げています。 - Thomas Künnethは、AndroidとJava Enterpriseアプリケーションの背景を持ち、いくつかの関連書籍を執筆しています。 - デスクトップメタファーは、ウィンドウ、アイコン、メニュー、ポインター（WIMP）を含むグラフィカルユーザインターフェース（GUI）に関するものです。 - 歴史的背景：GUIの開発は1970年代に始まり、1980年代にはApple、Atari、Commodoreなどの企業によって大きな進歩がありました。 - 現代のデスクトップ環境も依然としてWIMPユーザインターフェースに従っています。 | https://kotlinconf.com/talks/585375/ | https://www.youtube.com/embed/XFi1WJsH1BY?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | https://youtu.be/XFi1WJsH1BY | ChatGPT | |||||||||||||||||
41 | Mohit Sarveiya | Guide to Improving Compose Performance | Compose のパフォーマンスを向上させるためのガイド | 4. Compose | 1. **イントロと目的**: - KotlinとAndroidのGoogle Developer ExpertであるMohit Sarveiyaは、Jetpack Composeアプリケーションのパフォーマンス改善、特にリコンポジションに焦点を当てて話しています。 2. **パフォーマンスに影響を与える主な要因**: - 初期コンポジション時間、レイアウト、リコンポジションがComposeのパフォーマンスに影響を与える主な要因です。 3. **安定性の重要性**: - Composeにおける安定性とは、安定した型を再コンポーズせずにスキップできる能力を指し、これによりパフォーマンスが大幅に向上します。 4. **安定性の基準**: - 不変性（イミュータビリティ）や既知の安定した構造（例：プリミティブ型、Kotlinの不変コレクション）を使用することで安定性が達成されます。 - 可変型、ジェネリックリスト、および外部型はしばしば不安定性を引き起こします。 5. **パフォーマンス改善のためのヒント**: - 事前の最適化を避けること。パフォーマンス問題が発生している重要な領域でのみ最適化を行うことが推奨されます。 - ベースラインプロファイルを設定し、測定、改善、検査を繰り返すことが重要です。 6. **安定性の仕組み**: - 安定性はコンパイラプラグインによって決定され、コンポーザブル関数の再起動可能グループ、移動可能グループ、置換可能グループなどがあります。 - 安定性の影響を受けるビットマスクロジックが生成されます。 7. **実験的機能**: - Strong Skippingなどの実験的機能がCompose 1.7 Alphaで導入されており、全てのコンポーザブル関数をスキップ可能および再起動可能にします。 - 強いスキッピングを使用すると、インスタンスの等価性で不安定な型を比較することができます。 8. **グループ生成の最適化**: - 非再起動可能なコンポーザブル関数の場合、置換グループを生成しない最適化が行われます。 9. **状態の保存と再利用**: - `movableContentOf`を使用すると、親コンポーザが変更されても状態を保持し、再コンポーズを防ぐことができます。 10. **結論**: - 事前の最適化を避け、問題のある領域に対してのみ最適化を行うこと。 - 測定し、改善し、検査を繰り返すことが重要です。 - プレゼンテーションの最後に、Jeb BrainsとColin Kに感謝の意を表しています。 | https://kotlinconf.com/talks/572379/ | https://www.youtube.com/embed/h1xTtTl0k7Q?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | |||||||||||||||||||
42 | Sebastian Aigner | Evolving Compose Multiplatform on iOS and Beyond | iOS 以降の Compose マルチプラットフォームの進化 | 4. Compose | iOSおよびそれ以降のCompose Multiplatformの進化 進捗: 初期リリース以降、アクセシビリティ、スクロール物理、相互運用機能、インセット/カットアウト、UIテストにおいて大幅な進歩。 アクセシビリティ: VoiceOver、ジェスチャーナビゲーション、および正しいコンポーネント動作に対するそのまま使えるサポート。 スクロール物理: オーバー スクロールやスプリング物理など、ネイティブの iOS エクスペリエンスを反映するように刷新されました。 相互運用性: Swift UI と Compose 要素間のスムーズなインタラクションのための新機能。 インセットとカットアウト: フルスクリーンレンダリングと適切な要素配置のサポートが強化されました。 共通 UI テスト: すべてのプラットフォームで一度テストを作成して実行するための新しい API。 マルチプラットフォーム ライブラリ: リソース、ライフサイクル、ビュー モデル、ナビゲーションは、共通コードで使用できます。 リソース: 一部の IDE で自動再生成される、リソース (ドロウアブル、文字列、フォント) へのタイプセーフなアクセス。 ライフサイクル: Android、iOS、Web、デスクトップをサポートする、堅牢なアプリケーションを構築するためのクロスプラットフォーム ライフサイクル抽象化。 ビューモデル: 単方向データフロー、ライフサイクルとの統合、中断操作のサポート。 ナビゲーション: Jetpack Navigation を共通コードにもたらし、タイプセーフ性とビュー モデルおよびライフサイクルとの統合を提供します。 | https://kotlinconf.com/talks/613830/ | https://www.youtube.com/embed/iIk755YpQlI?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | Gemini | ||||||||||||||||||
43 | Louis CAD | It's Compose O'Clock, draw on my watch! | Compose O'Clock です。時計に絵を描いてください。 | 4. Compose | こちらはルイ・CADによるトーク「It's Compose O'Clock, Draw on My Watch!」の主なポイントです： 1. **プログラムによる描画の紹介**：ルイは、Compose UIを使ったプログラムによる描画について説明し、その応用がAndroid、iOS、Compose Desktopなどのさまざまなプラットフォームで可能であることを強調しています。 2. **プログラムによる描画の利点**：プログラムによる描画は、ピクセル完璧なデザイン、自動化、アニメーション、複雑な形状やエフェクトの作成を可能にし、基本的なジオメトリに限定されません。 3. **Compose Canvasの強力さ**：基本的な形状や背景の描画に比べて、Compose Canvas（または「draw scope」）の多様性と強力さが強調されています。 4. **APIの使いやすさとパフォーマンス**：Compose UIのAPIは使いやすく、高性能に最適化されており、JVMインライン値クラスなどの機能を活用して不要なメモリ割り当てを回避します。 5. **マルチプラットフォーム対応**：ComposeのAndroid、iOS、Web、デスクトップなど、複数のプラットフォームで動作する能力について説明され、その幅広い適用性が強調されています。 6. **Composeでの描画の使用例**：カスタムウォッチフェイス、ローディングアニメーション、アプリアイコン、スプラッシュスクリーン、カスタムアート、背景、さらには透明なビデオやグリーティングカードの生成など、いくつかの使用例が紹介されました。 7. **効率と最適化の技術**：描画における高効率を達成するための主な技術として、作業回避、不必要な再コンポジションの回避、rememberやGraphicsレイヤーなどを使った操作のキャッシュが紹介されました。 8. **描画のためのツールとエントリーポイント**：キャンバス、modifier.drawBehind、drawWithContent、ウォッチフェイス用に設計されたルイ自身の作成物であるoCanvasなど、Composeでの描画のためのさまざまなツールとエントリーポイントが説明されました。 9. **実践的なデモと例**：ルイは、draw scopeを使用して形状、パス、テキストを描画する方法を示す簡単なデモを行い、レンダリングの効率性の重要性について説明しました。 10. **テストアプローチ**：ルイは、Android Studioのプレビューと電話テストを使用してウォッチに展開する前にコードが正しく動作することを確認するという、時間を節約しながらさまざまなデバイスでコードが正しく動作することを保証するためのテストアプローチを共有しました。 | https://kotlinconf.com/talks/614934/ | https://www.youtube.com/embed/wlP4LMJcsEg?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | https://youtu.be/wlP4LMJcsEg | ChatGPT4 | |||||||||||||||||
44 | Jake Wharton | Compose UI for... a light switch? | 照明スイッチの ための Compose UI ? | 4. Compose | 「Compose UI for... a light switch」キーポイント 1. Jake Wharton氏は、root権限を持つスマートライトスイッチ上でCompose UIを実行することに成功した。 2. このプロセスには、Flutterベースの組み込みアプリの動作原理を解明する作業が含まれていた。 3. デバイスのリソースの制限や特定のライブラリがサポートされていないことから、Compose UI desktopを使う最初の試みは失敗した。 4. レンダリング、ハードウェアとのインタラクション、グラフィックスタックのセットアップのために、Kotlin Nativeを使ってCコードを移植した。 5. KotlinマルチプラットフォームライブラリであるSkikoは、低レベルグラフィックライブラリのSkiaとCompose UIの統合に重要な役割を果たした。 6. Linux arm向けにSkikoをビルドするには、サポートされていないターゲットや、デバイス上の特定のライブラリバージョンに対してコンパイルする必要性から、修正が必要だった。 7. タッチスクリーンからの入力イベントを解析し、Compose UIに送り込むことで、インタラクティブなUIを作成した。 8. 最終的なUIデザインには、ドラッグ＆タッチ可能なスイッチに加え、設定や時計のプレースホルダーページが含まれていた。 9. このプロジェクトは、Compose UIマルチプラットフォームの可能性と、それを従来とは異なるハードウェアに適応させる際の課題を示している。 10. Jake Wharton氏はプロジェクトのコードをGitHubで公開し、更なる開発や実験を呼びかけている。 | https://kotlinconf.com/talks/580409/ | https://www.youtube.com/embed/D0P5Lb-2uCY?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | |||||||||||||||||||
45 | Elijah Semyonov | Compose Multiplatform: performance on iOS | Compose Multiplatform: iOS でのパフォーマンス | 4. Compose | 1. **Compose Multiplatformの紹介**：Elijah Semyonovが、複数のプラットフォーム（Android、iOS、デスクトップ、Web）でUIを共有するためのフレームワークであるCompose Multiplatformを紹介。パフォーマンスと一貫したユーザー体験に焦点を当てる。 2. **モバイルデバイスでのパフォーマンス目標**：主なパフォーマンス目標は、最大かつ一貫したリフレッシュレートの達成、入力と視覚的フィードバックの間の低遅延、滑らかでスムーズな視覚的変化、バッテリードレインと熱スロットリングの最小化。 3. **Composable関数**：Composeは、Composableアノテーションを持つ関数を使用してインターフェースを記述。これらの関数は、効率的なパフォーマンスのために実行時に管理され、いつ何を実行するかを決定。 4. **レイアウトと描画のステージ**：レイアウトステージではUI要素の測定と配置を行い、描画ステージではこれらの要素を画面にレンダリング。この全過程はComposeランタイムによって管理される。 5. **iOSでの実装**：iOSでは、Composableブロックを持つUIViewControllerを作成し、SkiaのSKCanvasを使用してUI要素を描画。Metalを使用してテクスチャを管理し、効率的なレンダリングを実現。 6. **無効化と同期の処理**：フレームワークは状態変更時に無効化イベントをリッスンし、レンダリングをディスプレイのリフレッシュレートと同期させて不要な計算やバッテリードレインを避ける。 7. **パフォーマンスの課題と解決策**：課題には、高リフレッシュレートスクリーン（例えばAppleのProMotion）の表示リンク管理、入力遅延の処理、CPUおよびGPUの負荷最適化が含まれる。解決策としてトリプルバッファリングや表示リンクスケジュールの調整が挙げられる。 8. **レンダリングコマンドの最適化**：描画コマンドの収集とエンコードを効率的に行うプロセスが含まれ、エンコードを別のスレッドに移動させることでパフォーマンスを向上させ、メインスレッドのブロックを回避。 9. **ネイティブとの相互運用性**：ComposeはSwiftUIやUIKitなどのネイティブUIコンポーネントとの統合をサポートし、Composeとネイティブビュー間のスムーズな相互作用を確保。 10. **将来の改善**：ベンチマークの設定、マルチスレッドの最適化、Kotlin/Nativeのパフォーマンス向上、さらに複雑なユースケースやデバイスのサポートを強化する計画。 | https://kotlinconf.com/talks/578918/ | https://www.youtube.com/embed/Df1ZCmmHWzM?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | ChatGPT4 | KotlinFest | |||||||||||||||||
46 | István Juhos | Compose Migration Side Effects - What Can Go Wrong? | Compose 移行の副作用 - 何が問題になる可能性がありますか? | 4. Compose | 以下は、István Juhosの講演「Compose移行の副作用 - 何がうまくいかない可能性があるか？」の要点です。 1. **導入と背景**： - Jetpack ComposeとCompose Multiplatform (KMP) に関連する移行問題。 - 「デクスターズラボ」のエピソードに例える：古い発明品がプロタゴニストに対して反乱を起こす。 2. **コードベースの断片化**： - 新しい技術が追加されると、既存のコードベースが更新されない場合に発生。 - Androidプロジェクトは、ビュー、データバインディング、ビューバインディング、そして現在のComposeへと進化してきた歴史がある。 3. **完全なCompose移行の課題**： - 資源（時間、資金）の制約が完全なリファクタリングを妨げることがある。 - ビジネスニーズが完全な移行を正当化しないことがあり、混在するコードベースになる。 4. **モジュラー化のアプローチ**： - Composeを導入する前に、モジュラー化や他のリファクタリング作業を完了させることを推奨。 - モジュールごとにComposeを導入して断片化を最小限に抑える。 5. **ビューとComposeの混在**： - ビューとComposeを組み合わせると、コンテキストスイッチが増え、複雑さが増す。 - ハイブリッドUIはComposeに対応したUIテストを必要とし、更新に時間がかかることがある。 6. **パフォーマンスと可読性の問題**： - Composeとビューの深い相互運用は、パフォーマンスや読みやすさに問題を引き起こす可能性がある。 7. **Composeでのテーマ設定**： - デフォルトではマテリアルテーマを使用するが、特定のデザインシステムにはカスタムテーマが必要。 - カスタムテーマは、マテリアルの実装詳細がコンポーザブル階層に漏れるのを防ぐ。 8. **ナビゲーションと組織化の課題**： - フラグメントやアクティビティにComposeを導入する場所を決定する。 - Composeコードを効率的に組織化し、プレビューを管理する。 9. **パフォーマンステスト**： - デバッグモードではComposeがパフォーマンスが悪いように見えることがあるので、常にリリースビルドでテストする。 10. **iOSエンジニアの説得**： - iOSエンジニアにKotlin MultiplatformとCompose Multiplatformを採用するよう促す。 - 彼らがSwiftやSwiftUIから移行する際の懸念に対応しながら、利点を強調する。 11. **結論**： - ComposeまたはCompose Multiplatformを採用する前に、既存の移行を完了する。 - 将来の問題を避けるために、コードベースを清潔で最新の状態に保つ。 - 新しいツールの採用において、学習とチームの協力を強調する。 | https://kotlinconf.com/talks/581753/ | https://www.youtube.com/embed/FQtyKbwx3-c?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | ChatGPT4 | ||||||||||||||||||
47 | Meike Felicia Hammer | Diving into Advanced Compose Multiplatform Modifiers and Their Impact on Multiplatform Development | 高度な Compose マルチプラットフォーム修飾子とそのマルチプラットフォーム開発への影響について詳しく見る | 4. Compose | 以下は「高度なComposeマルチプラットフォーム修飾子とそのマルチプラットフォーム開発への影響」というタイトルの講演の要約です： 1. **導入と背景**：Mel Felicia Hammer氏が自己紹介し、マルチプラットフォーム開発の重要性とその採用が増えていることを強調しています。 2. **修飾子の基本**：修飾子の基本概念を説明し、カットルフィッシュ（コウイカ）の適応能力に例えています。修飾子がコンポーザブルの外観や動作をどのように変えることができるかを説明します。 3. **順序の重要性**：修飾子の順序がレイアウトや外観にどのように影響するかを示す具体例を紹介し、異なる結果が得られることを説明しています。 4. **マルチプラットフォームでの統合**：Androidの視点から始め、Compose Multiplatformの修飾子をどのように統合できるか、エコシステム内での修飾子の役割について説明します。 5. **カスタム修飾子の作成**：独自のカスタム修飾子を作成する方法を示し、「変更の狂気（modification madness）」と呼ばれる複雑な修飾子の使用例をいくつか紹介します。 6. **描画修飾子**：描画修飾子の主要な種類（draw with content、draw behind、draw with cache）を説明し、それぞれの使用例と実装方法を紹介します。 7. **パフォーマンスの考慮事項**：パフォーマンスに関する考慮事項を説明し、特に大規模な計算やキャッシュが必要な場合に使用すべき描画修飾子について述べています。 8. **マルチプラットフォームの例**：Android、iOS、デスクトップでの修飾子の使用例を示し、それぞれのプラットフォームでの動作の違いを比較しています。 9. **プラットフォーム固有のコード**：プラットフォーム固有のコードをできるだけ少なくすることで、マルチプラットフォーム開発を最適化する方法について説明しています。 10. **結論**：マルチプラットフォーム開発における修飾子の影響についてまとめ、ユーザー入力やプラットフォームごとの期待に応じた対応の重要性を強調しています。 | https://kotlinconf.com/talks/554617/ | https://www.youtube.com/embed/tleGdk63_GY?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | |||||||||||||||||||
48 | Nicole Terc | Tap it! Shake it! Fling it! Sheep it! - The Gesture Animations Dance! | タップしてください！振って！飛ばせ！羊だよ！ - ジェスチャーアニメーションが踊ります！ | 4. Compose | 以下は「Tap it! Shake it! Fling it! Sheep it! - The Gesture Animations Dance! | Nicole Terc」の要点です： 1. **イントロダクションと概要**: - Nicole Terc、Android GDEかつHoops Sportのテックリードが、このセッションでジェスチャーとセンサーを使った楽しいアニメーションの作成について紹介。 2. **三つの主要コンポーネント**: - このセッションではアニメーション、ジェスチャー、センサーの利用をカバーし、特に羊のキャラクターを使ったアニメーションの作成に焦点を当てる。 3. **アニメーションのプロセス**: - アニメーションは、「何をアニメートするか」「いつ変更を起こすか」「どのように実装するか」の三つの質問に答えることで作成。 4. **Jetpack Composeアニメーション**: - Jetpack Composeのアニメーションドキュメントを探索することを推奨し、特にジェスチャー駆動のアニメーションのためのコルーチンベースのAPI「Animatable」に言及。 5. **ジェスチャーベースのアニメーション**: - 例として： - **タップしてスケール**: タップ時にオブジェクトをスケーリング。 - **ドラッグ＆ドロップ**: ドラッグ可能なジェスチャーでオブジェクトを画面上に移動。 - **フリングして戻る**: フリングジェスチャーでオブジェクトを動かし、画面外に出た場合に元の位置に戻るアニメーション。 6. **センサーの使用によるアニメーション**: - センサーは回転や加速度などのデータを利用してインタラクションを追加。 - ステップには、センサーの選択、センサーデータのリスニング、センサーイベントの消費が含まれる。 7. **マルチプラットフォームセンサーマネージャー**: - AndroidとiOSの両方のセンサーデータを処理するマルチプラットフォームセンサーマネージャーの実装について、両プラットフォーム間のセンサーデータ処理の違いを強調。 8. **センサーベースのアニメーションの例**: - **回転センサー**: デバイスの向きに基づいてオブジェクトの回転を変更。 - **シェイク検出**: デバイスがシェイクされたときにオブジェクトの位置とスケールを更新。 9. **実践的なヒント**: - ジェスチャーに続くアニメーションで即時応答を得るために「snapTo」を使用。 - AndroidでセンサーデータをテストするためにAndroid Studioのセンサーエミュレーターを使用することを推奨、iOSには同様のツールがないことに注意。 10. **奨励とリソース**: - 様々なジェスチャーやセンサーを使って独自のアニメーションを作成する実験を奨励。 - アニメーションやセンサーに関する詳細な学習のために、Rebecca Franksの作品を含むドキュメントやリソースの探索を推奨。 | https://kotlinconf.com/talks/568147/ | https://www.youtube.com/embed/AOV9CrYAexQ?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | |||||||||||||||||||
49 | Igor WojdaNatalia Peterwas | Harmonizing Kotlin codebase with Konsist | Kotlin コードベースと Konsist の調和 | 5. Tools | 1. **導入と背景**: - 発表者はナタリア・ピーターウォスとイゴール・ウォイダで、Konsistプロジェクトのリードデベロッパー。KonsistはKotlinのコードベースの品質向上を目指しています。 - コードの一貫性の重要性と、プロジェクトの複雑さや変更によってコード品質を維持する上での課題に対処することの重要性を強調。 2. **コード品質の課題**: - 一般的な問題としては、一貫性のないコード構造、ドキュメントの欠如、時間的なプレッシャー、テストの不足などが挙げられ、これらが時間と共にコードの品質を低下させます。 3. **リンターの重要性**: - リンターはソフトウェア開発において重要であり、コードを実行せずに分析し、コーディング標準を強制し、プロジェクト全体で良いプラクティスを促進します。 4. **既存のリンター**: - KotlinにはDetekt、Ktlint、Android Lintの3つの主要なリンターがあります。それぞれが異なる目的に特化しており、パフォーマンス問題やコードスタイルの一貫性を確保するために使用されます。 5. **Konsistの必要性**: - KonsistはKotlin特有の構造を検証し、カスタムチェックを作成するための新しいリンターです。既存のリンターでは困難なチェックも可能にします。 6. **Konsistの基本機能**: - スコープの作成、宣言のフィルタリング、アサーションの定義の3つの主要なステップがあります。 - スコープはプロジェクト内のKotlinファイルの集合を表し、必要に応じて詳細なスコープを作成できます。 7. **宣言のフィルタリング**: - Konsist APIはクラスや関数のフィルタリングを容易にするための専用メソッドを提供し、Kotlinのコレクション処理と似た柔軟なフィルタリングが可能です。 8. **アサーションの定義**: - Konsist APIは宣言の情報を取得するためのプロパティを提供し、アサーションメソッドを使用してコーディング標準を検証できます。 9. **Konsistの使い方**: - JUnitやKotestのテストフレームワークを使用してKonsistテストを実行できます。プロジェクト内のコーディング標準を強制し、コードの一貫性を保ちます。 10. **プロジェクトの状態とコミュニティ**: - Konsistはオープンソースプロジェクトであり、コミュニティのフィードバックを基に継続的に改善されています。GitHubでのスター数やコミュニティメンバーの数からも支持がうかがえます。 | https://kotlinconf.com/talks/569136/ | https://youtu.be/3qbKYSI1u1k | ChatGPT | ||||||||||||||||||
50 | Vitaly Bragilevsky | Custom Fleet Plugins for Your Kotlin Codebase | Kotlin コードベース用のカスタム Fleet プラグイン | 5. Tools | 1. **イントロダクションとスピーカー:** Vitaly Bragilevskyは、JetBrainsの開発者アドボケイトで、Fleetプラグインの開発に携わっていると自己紹介しました。 2. **Fleetの概要:** Fleetは、複数のプログラミング言語に対応するコードエディタで、リモート開発やコラボレーションシナリオの実現を目指して設計されています。 3. **プラグインの必要性:** 既存の機能だけでは不足する場合に、カスタムビューや外部ツールの統合、コードベースの追加情報取得（例：サイクロマティック複雑度）などのためにカスタムFleetプラグインが必要になることがあります。 4. **プラグインの作成手順:** プラグインの作成は簡単で、ラッパーを作成し、コードを書き、Fleetでプラグインを開発モードで実行し、最終的にマーケットプレイスで公開します。 5. **現在のプラグインのステータス:** 現在、Fleetプラグインは開発中であり、すべてのユーザーが利用可能ではありませんが、公開プレビューに向けて進行中です。 6. **プラグインの例:** Fleetでの非常に簡単なプラグインの例として、コードファイル内の関数の数をカウントするプラグインが紹介されました。 7. **Fleetのアーキテクチャ:** Fleetはワークスペースを中心に設計されており、ユーザーとの対話を担当するフロントエンドコンポーネントと、インデックス作成や静的解析を行うバックエンドコンポーネントがあります。 8. **プラグインのコーディング原則:** Fleetは分散データベースとリアクティブクエリを基盤としており、すべての変更はトランザクションとして実行されます。また、コルーチン構造化並行性を採用しています。 9. **プラグインの実装:** プラグインのクラス定義や通知の管理、アクションの定義方法が具体的に説明されました。例として、コード内の関数をカウントし通知するプラグインが取り上げられました。 10. **今後の展望:** Fleetプラグインの公開プレビューが近々予定されており、ユーザーが独自のプラグインを開発できるようになる見込みです。 | https://kotlinconf.com/talks/614971/ | https://youtu.be/reK6sBTVHko | ChatGPT | ||||||||||||||||||
51 | Márton Braun | Simplifying Build Configuration with Amper | Amper を使用したビルド構成の簡素化 | 5. Tools | 1. **導入と目的**：JetBrainsのデベロッパーアドボケートであるマートン・ブラウンが、Kotlin開発者向けにビルド設定の体験を簡素化することを目的とした実験的なビルドシステム「Amper」を紹介します。 2. **Amperの主要機能**： - **シンプルさ**：Amperは開発者の邪魔をしないように設計されており、プロジェクトの他の部分に集中できるようにします。 - **ツール対応**：宣言型の設定ファイルを通じて実現されます。 - **マルチプラットフォーム対応**：初日からマルチプラットフォーム開発をサポートするように設計されています。 3. **デモの概要**：ブラウンはJetBrains Fleetの空のフォルダーを使用してAmperのデモを行い、JVMアプリケーションをAmperで設定する方法を示します。 4. **Gradle統合**：AmperはGradleベースのプロジェクトで設定可能で、`settings.gradle`ファイルを介してAmperプラグインが取り込まれます。 5. **設定オプション**：デモには、Amperモジュールファイル内での設定、依存関係の追加、Kotlinコンパイラの設定のカスタマイズが含まれます。 6. **複雑なプロジェクトのデモ**：次に、複雑なGradleベースのAmperプロジェクトとして、Kotlinマルチプラットフォームプロジェクトを紹介します。 7. **マルチプラットフォーム対応のモジュール構造**：Amperはフラットなソースセット構造を持ち、共通ソースとプラットフォーム固有のソースを分けて管理します。 8. **モジュールファイルの設定**：モジュールの設定は宣言型で、プラットフォームの追加や依存関係の設定が簡単に行えます。 9. **依存関係の自動補完**：依存関係のブロックでの自動補完機能があり、必要な依存関係を簡単に見つけて追加できます。 10. **将来の展望**：Amperチームは、プラットフォーム固有のテストやパッケージング、ビルドバリアントのサポートなど、さらなる拡張機能を開発中です。GitHubリポジトリやSlackのAmperチャンネルでフィードバックを求めています。 | https://kotlinconf.com/talks/613974/ | https://www.youtube.com/embed/239XnWOLCW8?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | https://youtu.be/239XnWOLCW8 | ChatGPT | |||||||||||||||||
52 | Marharyta NedzelskaEvgeny Mandrikov | The state of code coverage for Kotlin | Kotlin のコード カバレッジの状態 | 5. Tools | Kotlinにおけるコードカバレッジの現状：主要ポイント コードカバレッジは、テスト中に実行されたコードの量を測定するためのメトリックです。 Kotlinで人気のあるコードカバレッジツールには、JaCoCo、JetBrains Coverage Engine、PITestなどがあります。 これらのツールは、Kotlinコードから生成されたバイトコードを分析することで機能します。 when式、インライン関数、コルーチン、コンポーザブルといったKotlin特有の言語機能は、コードカバレッジツールにとって課題となることがあります。 JaCoCoとJetBrains Coverage EngineはKotlinの機能をサポートするために進歩を遂げていますが、いくつかのエッジケースはまだ残っています。 PITestは、突然変異テストツールであり、テスト品質に関する追加の洞察を提供しますが、Kotlinプロジェクトでは手動での調整が必要になる場合があります。 コードカバレッジツールはパフォーマンスに影響を与える可能性があり、JaCoCoは一般的にJetBrains Coverage Engineよりもオーバーヘッドが少ないです。 Kotlin 2.0では、enum entriesメソッドなど、コードカバレッジツールにさらなる適応を必要とする新しい課題が導入されました。 観察者効果：コードカバレッジを測定する行為は、プログラムの動作を変更し、正確性とパフォーマンスに影響を与える可能性があります。 ツールメンテナにフィードバックを提供して、Kotlinのコードカバレッジツールを改善することが重要です。 | https://kotlinconf.com/talks/580612/ | https://www.youtube.com/embed/K08BaISw27I?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | Gemini | ||||||||||||||||||
53 | Sterling GreenePaul Merlin | Developer-first Gradle builds | 開発者優先の Gradle ビルド | 5. Tools | 以下は、Sterling GreeneとPaul Merlinによる「Developer first Gradle builds」のトークの要点です。 - Gradleビルドのメンテナンスと理解の課題 - 開発者ファーストビルドのビジョンとその現在の状態 - デモの実演 - 次に取り組むこととその方向性 - 実験的なDSLとその利点、ツール連携の強化 - パフォーマンスとスキーマに基づく設定管理の改善 - ID統合とツール連携の進展 - ミューテーションフレームワークの導入とリファクタリング能力の強化 - 長期的なビジョンと将来の展望 | https://kotlinconf.com/talks/584014/ | https://youtu.be/-4HMXAKEXzU | |||||||||||||||||||
54 | Vladislav Tankov | AI and Kotlin: A Perfect Mix | AI と Kotlin: 完璧な組み合わせ | 5. Tools | 1. Kotlin開発におけるAI機能は、開発者の生産性と効率を向上させることを目的としています。 2. JetBrainsのコードエディタであるFleetは、チャット、コードリファクタリング、コード補完などのAIを活用した機能を組み込んでいます。 3. Fleetのチャット機能は、世界の知識と特定のKotlinの専門知識を活用して開発者を支援します。 4. 機械学習モデルは、コード生成などのタスクのために、現実世界の機能を近似する様々なAI機能を強化するために使用されます。 5. GPT-4のような大規模言語モデル（LLM）は、膨大な量の情報をエンコードし、インテリジェントな応答を生成するのに役立ちます。 6. ファインチューニングとは、特定の例や指示を与えることで、訓練されたモデルを新しいタスクに適応させるプロセスです。 7. 開発アシスタントは、ファイル、ユーザーの行動、プロジェクト構造からのコンテキストを組み込み、LLMを活用してコードを生成します。 8. 埋め込みとは、意味情報を捉えたテキストのベクトル表現であり、関連するコンテキストの特定や情報検索を可能にします。 9. AIサービスの主なコスト要因は、推論、つまりユーザー入力に対してモデルを実行するプロセスです。 10. LLMは強力ですが、特定のタスクには、より小規模なモデルや微調整されたモデルの方が費用対効果が高い場合があります。 | https://kotlinconf.com/talks/671939/ | https://www.youtube.com/embed/1ipJ-tdcmwE?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | https://youtu.be/1ipJ-tdcmwE?feature=shared | Gemini | |||||||||||||||||
55 | Nikita Nazarov | Debugging the Future: Exploring Coroutine Debugger Tools | 未来のデバッグ: コルーチン デバッガー ツールの探索 | 5. Tools | こちらはNikita Nazarov氏による「未来をデバッグする：コルーチンデバッガーツールの探索」というタイトルの講演の要約です。 - **導入** - Nikita Nazarov氏は、Googleのコルーチンコンパイラエンジニアとして、コルーチンのデバッグの課題について議論します。 - デベロッパーによるprint lineデバッグの一般的な使用について言及します。 - **コルーチンのデバッグの課題** - コルーチンの非同期性がデバッグを困難にします。 - マルチスレッドのデバッグ環境での問題点を指摘します。 - **デバッグテクニック** - 特定のコルーチンインスタンスを追跡するための条件付きブレークポイントの使用。 - デバッグモード (`-Dkotlinx.coroutines.debug`) を有効にして、コルーチンに一意の名前を割り当て、追跡を容易にする方法。 - **スタックトレースの回復** - コルーチンのスタックトレース回復を利用して、非同期の境界を越えた例外のトレース能力を向上させます。 - JVMでアサーションを有効にするか、特定のデバッグフラグ (`-ea`) をアクティブにする必要があります。 - **注意点と最適化** - デバッグに影響を与えるコンパイラの最適化について議論し、サスペンド関数での変数最適化を紹介します。 - デバッグ目的での `-Xdebug` フラグの使用を紹介し、リリースビルドでの使用を控えるよう注意を促します。 - **デバッグツール** - デバッグに役立つコルーチンデバッグツールの概要： - IntelliJ IDEAなどのIDEでのコルーチンパネル。 - コルーチンスタックトレースを可視化するためのCoroutines Text Plugin。 - オフライン分析のためのコルーチンダンプのキャプチャ。 - **パフォーマンス考慮** - デバッグフラグやコルーチンツールによる最小限のパフォーマンス影響は、開発環境での使用に適しています。 - **将来の方向性** - 仮想スレッドなどの新しいJVM機能とコルーチンデバッグの統合における課題。 - JetBrainsやコミュニティによるコルーチンデバッグツールの持続的な改善について。 - **結論** - コルーチンのデバッグはその強力さと多様性から挑戦的であるが、重要性が高い。 - デベロッパーに対して、利用可能なコルーチンデバッグツールを効果的に活用するよう奨励します。 この要約は、Nikita Nazarov氏がコルーチンのデバッグに関するプレゼンテーションで共有した主要なポイントと洞察を網羅しています。 | https://kotlinconf.com/talks/542869/ | https://youtu.be/QomoVqZSXP0 | ChatGPT3 | KotlinFest | |||||||||||||||||
56 | Tor Norbye | Write your own Kotlin lint checks! | 独自の Kotlin lint チェックを作成してください。 | 5. Tools | 承知いたしました。以下に、日本語で要約した内容を箇条書きで示します。 1. **Lintとは:** Kotlin、Java、XMLなど、様々なファイルタイプのコードエラー、悪いプラクティス、潜在的な問題を発見するための静的解析ツール。 2. **GoogleでのLintの活用:** Google内では、LintがKotlinとJavaのコード分析に使用されており、毎日数百万行のコードを処理している。 3. **Lintによる問題の報告方法:** ビルドシステムではレポートを作成し、重大なエラーの場合はビルドを中断させることができる。IDEでは、リアルタイムでハイライト表示し、バックグラウンドで実行される。 4. **相互参照チェック:** Lintは、リソースファイル内のフォーマット文字列の不一致など、異なるファイル間での不整合を検出するのに優れている。 5. **組み込みチェック:** Lintには約500個の組み込みチェックが付属しており、その半分はKotlinとJavaのコードに関連している。 6. **拡張性:** Lintはライブラリによる追加チェックで拡張可能であり、カスタムチェックを作成することもできる。 7. **パフォーマンスへの注力:** Lintを高速にするために多大なエンジニアリング努力が払われており、APIの選択にも影響を与えている。 8. **簡単なLintチェックの作成:** 問題のメタデータ（問題ID、説明など）と、問題を特定して報告するための検出器を定義する必要がある。 9. **UAST (Universal Abstract Syntax Tree):** KotlinとJavaのコードを統一的に表現するもので、言語に依存しないチェックを書きやすくする。 10. **Kotlin Analysis API:** コンパイルされたKotlinコードを分析するための強力なツールであり、型分析やスマートキャストの推論などに特に役立つ。 上記以外にも質問があれば、お気軽にお尋ねください。 | https://kotlinconf.com/talks/587199/ | https://www.youtube.com/embed/q5q-y3eZTSA?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | Gemini | KotlinFest | |||||||||||||||||
57 | Sam Edwards | Dynamic Exploration of Static Analysis with Compose | Compose を使用した静的分析の動的探索 | 5. Tools | ### 静的解析の動的探索とCompose | サム・エドワーズ 1. **紹介と背景:** - サム・エドワーズはKotlinConfでの発表に興奮しており、Composeを使用した静的解析の動的探索について紹介します。 2. **背景と動機:** - サムはSquareのAndroid Foundationチームに参加し、会社内で開発アプリでの実装モジュールの使用状況を理解する任務を与えられました。 3. **初期の課題:** - 複雑なモジュール構造と依存関係グラフの理解に直面し、サムは以前の知識とオープンソースライブラリを使用してプロトタイプソリューションを作成しました。 4. **ソリューションの開発:** - 彼は依存関係を解決し、包括的なJSONファイルを生成するGradleプラグインを作成し、最初はReactJSを使用して可視化しましたが、その後Composeを使用したKotlinマルチプラットフォームに移行しました。 5. **技術的な実装:** - 依存関係データを収集し、KotlinのComposeマルチプラットフォームを使用してブラウザ互換性を持つ対話型ウェブレポートを作成しました。 6. **ユーザーエクスペリエンスの向上:** - ユーザーフィードバックに応じて、結果のコピーや複数の構成をサポートするなど、よりアクセスしやすいデータを提供するためにツールを強化しました。 7. **コンテキスト解析と静的解析の統合:** - PSIやKotlin Analysis APIなどの静的解析ツールを使用して、コード構造を解析し、依存性注入やモジュール使用状況に関する詳細な洞察を提供するようツールを改良しました。 8. **動的探索の機能:** - このツールは、開発者がコードベースを動的に探索し、モジュールの依存関係や使用パターンに関する複雑な質問に答えることを可能にし、移行やリファクタリングの作業を支援します。 9. **課題と今後の改善:** - サムは進行中の改善について議論し、より高度なクエリ機能とコンテキスト認識解析のためのAIサービスとの統合の可能性を模索しています。 10. **結論とオープンソース計画:** - サムはInvertという名前のツールをオープンソース化し、他の開発者がプロジェクトで静的解析の動的探索の恩恵を受けられるようにし、コミュニティの貢献とフィードバックを促進することを目指しています。 | https://kotlinconf.com/talks/586687/ | or General or Compose | |||||||||||||||||||
58 | Simon Ogorodnik | K2: How to make a better compiler but keep Kotlin the same | K2: Kotlin をそのままにしながら、より良いコンパイラーを作成する方法 | 6. Language | ### 「K2: Kotlinをそのままに、より良いコンパイラを作る方法」サイモン・オゴロドニク 1. **K2とK1の紹介**: - サイモン・オゴロドニク、JetBrainsのK2プロジェクト（Kotlin 2.2としても知られる）のテックリード、K2（新しいコンパイラ）とK1（現在のコンパイラ）の用語を明確にするために紹介。 2. **K1コンパイラの背景**: - K1は、Kotlin 1.0リリース時の小規模なKotlinチームによる迅速な反復のために設計された。 - Kotlinの成長と複雑な新機能の追加にもかかわらず、K1のアーキテクチャは変更されなかった。 3. **K2の必要性**: - Kotlinチームの拡大と、より良い言語進化の必要性により、コンパイラのアーキテクチャの大幅な再設計が求められた。 4. **K2プロジェクトの目標**: - 主な目的は、新機能を追加しながら既存のコードを壊さずに言語の互換性を維持すること。 5. **FIR（フロントエンド中間表現）の導入**: - FIRは、コードをより効率的に処理し、言語理解を向上させるための新しいコンパイラ構造。 6. **課題と戦略**: - 言語をそのままにしながらコンパイラを書き直すことの課題について説明。 - K2はほとんどのK1テストを再利用し、互換性と正確性を確保するための新しいテスト手法を導入。 7. **努力と開発**: - プロジェクトのタイムラインに沿った努力の分布を示すチャートが示され、安定性と互換性を確保するための最後の努力が強調された。 8. **テストと品質保証**: - 内部および公共プロジェクトを含む広範なテストが行われ、1,000万行以上のコードをカバー。 - Early Access Program（EAP）が広範なテストとバグ修正に重要な役割を果たした。 9. **言語のモダン化**: - Kotlin Language Committeeが変更を監督し、改善と隅々までの問題解決を確保。 - スマートキャスト、型引数の削除、型チェックなどの問題をK2がどのように解決したかの例を示す。 10. **結論**: - サイモンは、K2によって達成された改善と安定性を強調し、ユーザーにKotlin 2.0へのアップグレードを呼びかけて講演を締めくくった。 これらのポイントは、サイモン・オゴロドニクのK2プロジェクトに関する講演の要点を捉え、新しいKotlinコンパイラの動機、開発プロセス、課題、および利点を強調しています。 | https://kotlinconf.com/talks/627087/ | https://youtu.be/U34MyLWDJR0 | ChatGPT | ||||||||||||||||||
59 | Michail Zarečenskij | Kotlin Language Features in 2.0 and Beyond | 2.0 以降の Kotlin 言語機能 | 6. Language | 1. **導入と概要**: - コトリンの言語デザインを担当するミハイル・ザレチェンスキーが、コトリン2.0以降の言語機能について発表しました。 - コトリンの進化について、過去8年間の変遷を簡単に紹介しました。 2. **コトリン2.0の機能**: - コトリン2.0には80以上の新機能が含まれており、パフォーマンス、正確性、コンパイラの改善に焦点を当てています。 - 主要な機能には、複雑な言語構造を早期に簡素化する新しいフロントエンド中間表現（IR）が含まれています。 3. **制御フローの改善**: - 新しい制御フローエンジンが導入され、コードの実行パスの分析をより高度に行えるようになりました。 4. **スマートキャストの強化**: - K2コンパイラにより、ローカル変数やラムダ式内でのスマートキャストが可能になり、型チェックの精度が向上しました。 5. **マルチプラットフォーム機能の強化**: - マルチプラットフォーム機能が強化され、異なるターゲット間でのコードの統合がより簡単になりました。 6. **ID統合とプラグインの改善**: - コンパイラプラグインとIDEの統合が改善され、IDEが新しいコンパイラ拡張を自動的に認識するようになりました。 7. **言語機能の将来の展望**: - 今後のリリースでは、ガード条件、コンテキストセンシティブな解決、データクラスの改善などが予定されています。 8. **データクラスの改良**: - データクラスの構造化の際に、任意のプロパティ名を使用することができなくなり、より安全なコードが実現されます。 9. **エラー処理のためのユニオンタイプ**: - エラーや例外の処理に特化したユニオンタイプが導入され、より直感的なエラーハンドリングが可能になります。 10. **抽象化の向上**: - コンテキストパラメータ、明示的なバックフィールド、文字列リテラルなどの新機能が追加され、コトリンの抽象化能力が向上します。 | https://kotlinconf.com/talks/671726/ | https://www.youtube.com/embed/tAGJ5zJXJ7w?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | ChatGPT | ||||||||||||||||||
60 | Anastasiia Nekrasova | ‘Context parameters’ from the language design perspective | 言語設計の観点から見た「コンテキストパラメータ」 | 6. Language | アナスタシア・ネクラソワ氏のコンテキストパラメータに関する発表の要点を日本語で要約します： - コトリン言語進化チームの一員として、コンテキストパラメータの導入を紹介。 - コンテキストパラメータは呼び出しスコープ内で暗黙的に利用可能なパラメータで、冗長なコードを削減することを目的としています。 - ユースケース1：複数の関数でのログ記録を明示的なパラメータ渡しをせずにシンプル化。 - ユースケース2：外部依存性（例えばUIフレームワークのdensity）をライブラリの改変なしに統合。 - ユースケース3：DSL内での関数の可視性管理、スコープ汚染の防止とコードの明確化。 - 技術的詳細には、ラムダの命名規則やコンストラクタでの使用不可などの制約が含まれる。 - 複数のレシーバーやコンテキストレシーバーからの進化を経て、コンテキストパラメータはスコープ汚染の問題に対応。 - コトリンチームはコンテキストパラメータを改良中で、Kotlin 2.2以降にプロトタイプを提供予定。 この要約は、コトリンにおけるコンテキストパラメータに関する主要な議論を網羅しています。 | https://kotlinconf.com/talks/621119/ | https://www.youtube.com/embed/ZvnXLB4Gdig?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | ChatGPT3 | ||||||||||||||||||
61 | Brian Norman | Kotlin + Power-Assert = ❤️ | Kotlin + Power-Assert = ❤️ | 6. Language | こちらはBrian Norman氏による「Kotlin + Power-Assert = ❤️」と題されたトークの要約です： - Brian Norman氏はJetBrainsのKotlinコンパイラチームで働いています。 - 初期の課題：`assertTrue`などの基本的なアサーションはエラー情報が限られています。 - 検討された解決策：より詳細なエラーメッセージを提供するAssertJ（`assertK`）などのライブラリの使用。 - Power Assertの紹介：Kotlinのコンパイラプラグインとして2.0から導入されました。 - Power Assertの機能：中間値を含む詳細なエラーメッセージを自動生成します。 - カスタマイズ：Power Assertが変換する関数をユーザーが設定できます。 - メリット：手動でメッセージを作成する必要なく、本番用のアサーションに適しています。 - 使用例：複雑なブール式やカスタムタイプを効果的に処理します。 - 将来の改善点：図の構築の向上、Kotlin標準ライブラリとの統合、サードパーティのアサーションライブラリのサポート計画。 - コミュニティ参加：KotlinのSlackチャンネルを通じてのドキュメンテーションとサポートが利用可能で、フィードバックが求められています。 - 結論：Power Assertの試用を奨励し、さらなる改善のためのフィードバックを呼び掛けています。 | https://kotlinconf.com/talks/585611/ | https://www.youtube.com/embed/N8u-6d0iCiE?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | ChatGPT3 | ||||||||||||||||||
62 | Andrei Shikov | Going fast with Kotlin | Kotlin で高速化 | 6. Language | Andrei Shikov氏のトーク「Going fast with Kotlin」の要約です： - **Jetpack Composeの紹介**: Jetpack Composeは完全にKotlinで構築されたAndroid向けの宣言型UIフレームワークです。 - **パフォーマンスに焦点**: CPUとGPUの使用を最適化するために、シングルスレッドのパフォーマンスに重点を置いています。これはバッテリー駆動のデバイスで重要です。 - **メモリとフレームバジェットの制約**: 効率的にメモリを管理し、厳格なフレームレート（60-120 FPS）を維持します。 - **パフォーマンスツール**: 変更後のパフォーマンスを測定するためのベンチマークを使用し、リグレッションを検出して修正するためのアラートを設定します。また、メモリトレースやパフォーマンストレースを使用して、遅延している箇所を特定して修正します。 - **パフォーマンスレンズ**: Kotlinコードの遅い部分を特定し、高速な代替手法を使用するよう開発者に促すことで、小さながらも累積的な性能向上を実現します。 - **コンパイルパイプラインの理解**: KotlinコードのJVMバイトコードへのコンパイルと、AndroidのDEXバイトコードおよびネイティブコードへの最適化に関する洞察を提供します。 - **カスタムコレクション**: androidx.flatmapなどの最適化されたコレクションを活用して、イテレーションの高速化とメモリ使用量の削減を実現します。 - **コルーチンの最適化**: コルーチンの使用における遅延を特定し、launchやキャンセル操作の最適化を検討します。 - **チャネルの最適化**: Kotlinでのconflatedチャネルのパフォーマンス問題を報告し、よりシンプルな代替方法とのパフォーマンス差を強調します。 - **ベストプラクティス**: 継続的なベンチマークの実施、コンパイラ出力の理解、使用するコンポーネントのパフォーマンス特性の把握が重要であることを強調します。 このトークは、Androidアプリケーションでの効果的なKotlin使用による最適なパフォーマンスの達成の重要性を示しています。 | https://kotlinconf.com/talks/586541/ | https://www.youtube.com/embed/WAbaEE8qRdw?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | https://youtu.be/WAbaEE8qRdw | ||||||||||||||||||
63 | Vsevolod Tolstopyatov | Why we can't have nice things | なぜ私たちは良いものを手に入れることができないのか | 6. Language | 1. **講演者の紹介**：Vsevolod TolstopyatovはJetBrainsのKotlin Librariesチームの一員で、Kotlinライブラリのリリースに新機能が少ない理由について説明します。 2. **文字列の課題**：Kotlinの文字列関数（例：`toUpperCase`、`toLowerCase`）はロケールによって動作が異なることがあり、トルコ語の点ありと点なしの'I'の問題のような問題を引き起こすことがあります。 3. **名前付けの難しさ**：関数の名前付け（例：`capitalize`）は解釈の違いや他のプログラミング言語に既存の不一致のために困難です。 4. **タイムゾーンの複雑さ**：日付と時刻の処理は、タイムゾーンの違いや歴史的な変更（例：サモアがタイムゾーンを変更したときに1日をスキップしたこと）により複雑です。 5. **夏時間の問題**：夏時間の変更により、特定の時間が存在しなかったり2回存在したりすることで、日付と時刻の計算が複雑になります。 6. **人為的エラー**：API設計のミスがユーザーの問題を引き起こすことがあります。例えば、時間変更の誤解によりアラームが正しく設定されないことです。 7. **API設計のトレードオフ**：APIを迅速に設計して後悔するか、慎重に設計しても問題が発生するかのトレードオフがあります。 8. **多言語・多文化のサポート**：ソフトウェアにおいて様々な言語や文化をサポートする必要があるため、ライブラリの設計と機能が複雑になります。 9. **ソフトウェアは現実の複雑さを反映**：ソフトウェア開発は歴史的、政治的、社会的な文脈を含む現実の複雑さを考慮する必要があります。 10. **継続的な改善**：課題やミスがあっても、Kotlinチームは信頼性があり使いやすいAPIを提供するために改善と修正に努めています。 | https://kotlinconf.com/talks/586412/ | https://www.youtube.com/embed/lxoKilLSJ4k?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | https://youtu.be/lxoKilLSJ4k | ChatGPT | |||||||||||||||||
64 | Nikita Koval | Channels in Kotlin Coroutines | Kotlin コルーチンのチャネル | 6. Language | ### 「Kotlin コルーチンのチャンネル | ニキータ・コバル」の要約 1. **イントロと背景**: ニキータ・コバルはJetBrainsで並行プログラミングに関するプロジェクトに携わっており、Kotlinチームの一員として、学術と産業の両方の視点を持っていることを紹介しました。 2. **チャンネルとFlowの比較**: 多くの開発者が高レベルのFlow APIを使用していますが、Kotlinコルーチンにおける並行操作の基盤であるチャンネルの理解が重要であると説明しました。 3. **Flowの順次性**: Flow操作は順次実行され、同時に構築および収集することはできません。並行処理を行うためには、channelFlowビルダーを使用し、これがチャンネルを内部で利用します。 4. **リアクティブフレームワークにおけるチャンネル**: チャンネルは、RxJavaなど他のリアクティブフレームワークとKotlinコルーチンを統合する際の基本的なコミュニケーションプリミティブとして機能します。 5. **プロデューサー・コンシューマー問題**: チャンネルがない場合、並行キューが使用されますが、これは高いCPU使用率やメモリ問題を引き起こす可能性があります。チャンネルは、必要に応じて送信および受信操作を一時停止することで、より効率的な解決策を提供します。 6. **ランデブーチャンネル**: これらのチャンネルは、対応するコンシューマーやプロデューサーが利用可能になるまで送信および受信呼び出しを一時停止することで機能し、制御不能に成長することを防ぎます。 7. **効率的な実装**: チャンネルを効率的に実装するために、メモリ使用量とパフォーマンスのバランスをとるために、例えば並行リンクキューや固定サイズに分割された無限配列などのさまざまなデータ構造設計が探求されました。 8. **バッファ付きチャンネル**: これらのチャンネルは、一時停止せずに要素のバッファを送信することができ、データが消費されるよりも速く生成されるシナリオでのパフォーマンスを向上させます。 9. **アルゴリズムの複雑さ**: バッファ付きチャンネルの実装は複雑さを増しますが、新しい設計は以前の実装と比較して大幅に高速でメモリ効率が良いです。 10. **実践的な影響**: 講演は、Kotlinコルーチンにおけるチャンネルの実践的な影響（スケーラビリティとメモリ効率）についての議論で締めくくられ、参加者にさらなる探求を促し、今後の講演や詳細なドキュメントを通じて理解を深めるよう勧めました。 | https://kotlinconf.com/talks/571571/ | https://www.youtube.com/embed/ee0cG2SDJNE?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | ChaGPT4 | ||||||||||||||||||
65 | Ross Tate | Revamping and Extending Kotlin's Type System | Kotlin の型システムの改良と拡張 | 6. Language | ### 「Kotlinの型システムの刷新と拡張」概要 1. **トークの紹介**： - Ross Tateは、Kotlinの型システムの刷新と拡張に関する自身の研究について説明。 - 可能な拡張機能として、ユニオン型（Union types）のプレビューを提供。 2. **型システムの問題の例示**： - 整数から文字列への変換プログラムを例に取り、型の安全性に関する問題を強調。 - 型プロジェクションや存在量化型引数がコンパイラを騙す方法を示す。 3. **型チェックの刷新**： - 型チェックが確実であることを保証し、意図しないバックドアを防ぐことに重点を置く。 - 型チェックと型推論の両方の重要性を強調。 4. **型推論の問題**： - ジェネリック型を持つツリークラスの例を挙げ、型推論の課題を説明。 - 分解原則と信頼性のある型推論の必要性を強調。 5. **型システムの非決定性**： - Javaにおけるサブタイピングの非決定性とそのKotlinへの影響について議論。 - 標準化、信頼性、安定性のために決定性の重要性を説明。 6. **材料パターンと形状パターン**： - 型システムの決定性を改善するための材料パターンと形状パターンの導入。 - これらのパターンを支持するために、1億3500万行のJavaコードを分析。 7. **新しい型チェックアルゴリズム**： - 完全で信頼性のある新しい型チェックアルゴリズムの紹介。 - 効率性、拡張の容易さ、使いやすさの利点を強調。 8. **Nullとエラーの処理**： - Nullとカスタムエラー値を処理するためのユニオン型の導入。 - カテゴライズされたユニオン（categorized unions）と、それが効率的な型チェックを維持する方法を説明。 9. **エラーハンドリングの拡張**： - エラー伝播のための新しい構文（例：bang dot、bang colon）の紹介。 - エラー値と例外の区別を明確にし、既存のコードとの互換性を確保。 10. **今後の作業とコミュニティからのフィードバック**： - プロトタイプと実験の継続的な作業。 - 提案された変更を洗練し、潜在的な問題に対処するためにコミュニティからのフィードバックを奨励。 | https://kotlinconf.com/talks/576782/ | https://youtu.be/3uNpmhHwkuQ | CjatGPR4 | KotlinFest | |||||||||||||||||
66 | Arnaud Giuliani | From Zero to Billions: Building a High-Performance Kotlin App in Two Months | ゼロから 10 億まで: 2 か月で高性能 Kotlin アプリを構築 | 7. Server | 承知いたしました。以下に、日本語で要約した講演内容を箇条書きで示します。 物語の始まり: Koin 依存性注入フレームワークの開発元である Kotzilla は、オープンソース以外にも開発者に価値を提供したいと考えました。アプリのアーキテクチャをデバッグ・分析するプラットフォームの作成を目指しました。 技術スタック: プラットフォームは Kotlin、Ktor（ウェブフレームワーク）、Koin、Exposed（データベース連携用）、PostgreSQL、Google Cloud Platform（Cloud Run、Cloud Storage、Pub/Sub）を用いて構築されました。 スケーリングの課題: プラットフォームはすぐに大量のデータ流入（2日間で17億イベント）に直面しました。リソースを管理するため、レート制限、手動ページネーション、機能フラグなどの戦略が必要でした。 開発者の生産性: チームは迅速なイテレーションとテストを優先しました。モックサービス、テストコンテナ、ローカル環境設定などの手法を用いて、ライブシステムへの依存を回避しました。 教訓: Ktor ではカスタムページネーションとドキュメント生成が必要でした。 Google Cloud API と Exposed トランザクションは慎重な取り扱いが必要でした。 Cloud Run での長時間実行プロセスの調整は、学習経験となりました。 ヘルスチェックとワーカー管理は信頼性のために重要でした。 現状: プラットフォームは現在、顧客ごとに数十億件のイベントを処理しており、自動スケーリング機能とコスト最適化に重点を置いています。 今後の展望: チームはパフォーマンス向上のため Kotlin Native などのオプションを検討しており、Kotlin でのバックエンド開発を改善する方法を引き続き模索しています。 上記の内容について、さらに詳しく知りたい点があればお聞かせください。 | https://kotlinconf.com/talks/624953/ | https://youtu.be/i4nfYD0pgx8 | Gemini | ||||||||||||||||||
67 | Urs Peter | Grow with the Flow: How Kotlin Flow Became a Game-Changer for our Business | フローとともに成長する: Kotlin Flow がどのようにしてビジネスの変革をもたらしたのか | 7. Server | 1. 発表者は、Kotlin FlowをKotlin標準ライブラリにおけるリアクティブストリームの実装として紹介し、コレクションとは異なり、時間の経過とともに要素を生成するという点を強調しました。 2. 小規模なチームで多数のマイクロサービスを管理するという課題を取り上げ、自動化の重要性と偶発的な複雑さを最小限に抑えることの重要性を強調しました。 3. 通信業界でのユースケースを例にCQRSパターンを紹介し、読み取りモデルと書き込みモデルを分離し、イベントを使用して変更を伝播する方法を示し、アプリケーションや企業全体への適用可能性を示しました。 4. 従来のメッセージングミドルウェアの欠点について議論し、アウトボックステーブルからイベントを直接ストリーミングすることでミドルウェアの必要性をなくすEvent Streamerパターンを提案しました。 5. Server-Sent Events (SSE)を、サーバーからクライアントへの一方向通信のためのシンプルで信頼性の高いプロトコルとして紹介し、2006年から存在していることを強調しました。 6. Kotlin Flow、Spring Boot、SSEを使用して境界を越えてユーザーデータを複製するイベント駆動型システムを構築する実践的な例を示しました。 7. Event Streamerパターンの利点として、ミドルウェアの排除、クライアント接続の簡素化、オープンスタンダードの活用、一貫性の確保、柔軟性の提供などが挙げられました。 8. 発表者の会社では、Event Streamerパターンをうまく活用して、高アップタイムで低レイテンシーのサービスを管理しており、社内でもこのパターンを適用することで自社製品を積極的に活用しています。 9. このアプローチにより、チームは同じリソースでより多くのソフトウェアを処理できるようになり、偶発的な複雑さを最小限に抑え、ビジネスの成長に貢献することができました。 10. 発表の最後には、データベースへの影響、スケーラビリティに関する懸念、データベースレコードの複製などの代替手法についての質疑応答が行われました。 | https://kotlinconf.com/talks/581244/ | Gemini | |||||||||||||||||||
68 | Zalim Bashorov | Kotlin/Wasm: Present and Future | Kotlin/Wasm: 現在と未来 | 7. Server | タイトル: "Kotlin/Wasm: Present and Future | Zalim Bashorov" 要約: 1. **Web Assembly (Wasm)**: バイナリ命令形式で、プラットフォームとCPUに依存しないポータビリティを提供。 2. **安全性と隔離性**: Wasmは、プラグインや信頼できないコードの実行に適しており、セキュリティと安定性を向上させる。 3. **パフォーマンス**: ネイティブに近いパフォーマンスを実現し、Webアプリケーションでも重要。 4. **コンパイラ**: Kotlin Wasmコンパイラは、高速なコンパイルを目指し、ツールとしての改善を進めている。 5. **インタープリタ**: ストリーミングコンパイラにより、ダウンロード中にコンパイルし、パフォーマンスと予測可能性を向上。 6. **サイズと軽量性**: Wasmバイナリとランタイムのサイズが小さく、ダウンロードと起動が迅速。 7. **インタープリタビリティ**: 異なる言語との良好な相互運用性を提供。 8. **Web以外での使用**: 組み込み、IoT、クラウド、エッジコンピューティングなど、多岐にわたる利用事例がある。 9. **Compose Multiplatform**: KotlinのマルチプラットフォームUIフレームワークを活用し、高性能なWebアプリケーション開発を可能に。 10. **ツールとデバッグ**: JetBrainsのIDEやデバッグツールのサポートが充実し、開発体験を向上。 このセッションでは、KotlinとWeb Assemblyの組み合わせによる、現在と将来の可能性が詳細に説明されています。 | https://kotlinconf.com/talks/587178/ | https://www.youtube.com/embed/5NTVZrlRzsk?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | ChatGPT3 | KotlinFest | |||||||||||||||||
69 | Andrew O'Hara | Have your Serverless Kotlin Functions and Eat Them Too | サーバーレス Kotlin Functionsを用意して使用する | 7. Server | こちらは、Andrew O'Hara氏による「Have your Serverless Kotlin Functions and Eat Them Too」の要約です。 イントロダクション - Andrew O'Haraはカナダ出身で、カナディアンメイプルシロップに関するユーモラスな逸話を共有しました。 サーバーレスとKotlin - KotlinなどのJVMベースの言語におけるコールドスタートの課題について議論します。 - 特にHTTP API向けの迅速な応答時間の重要性を強調します。 フレームワークの比較 - Micronaut、Quarkus、Spring Boot、HTTP4KなどのサーバーレスフレームワークをAWS Lambdaでのコールドスタート性能を比較します。 - 各フレームワークの限界と強みを強調し、特にコールドスタートの最小化に焦点を当てます。 AWS Lambda Snap Start - AWS LambdaのSnap Start機能を導入し、関数初期化状態のキャッシュによるコールドスタートの削減を示します。 - Snap Startのパフォーマンス改善と、ファイルシステムやエントロピーの問題といった制限についても言及します。 代替手法 - GraalVMを利用して、Kotlinをネイティブコードにコンパイルすることで、起動時間を高速化する解決策を探りますが、特定のライブラリやリフレクションといった課題も指摘します。 アプリケーションの最適化 - Kotlinアプリケーションをサーバーレス向けに最適化する戦略について詳述します。初期化の最小化、依存関係の削減、リフレクションの排除を含みます。 ケーススタディ: HTTP4K - HTTP4Kアプリケーションの最適化方法を実証し、依存関係の削減、軽量なJSONライブラリの使用、ランタイム環境のカスタマイズを通じてコールドスタート時間の著しい改善を達成します。 さらなる最適化手段 - よりシンプルなロギングフレームワークへの切り替えや、AWS Lambdaのカスタムランタイム構成の探索など、さらなる依存関係の削減についても言及します。 結論 - フレームワークの互換性とパフォーマンス最適化のバランスを示し、サーバーレスKotlinアプリケーションでの最小のコールドスタート時間を達成するための持続的な課題について締めくくります。 この要約は、Andrew O'Hara氏のトークからの主要なポイントと技術的な洞察を捉えています。 | https://kotlinconf.com/talks/558194/ | https://www.youtube.com/embed/L1DvD83sjAw?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | ChatGPT3 | KotlinFest | |||||||||||||||||
70 | Francesco GuardianiGiselle van Dongen | Microservices with Restate and Kotlin | Restate と Kotlin を使用したマイクロサービス | 7. Server | 1. **マイクロサービスと耐久実行の紹介**：Francesco GuardianiとGiselle van Dongenが、RestateとKotlinを使用したマイクロサービスに関するプレゼンテーションを行い、障害を処理し、マイクロサービスアーキテクチャの回復力を確保するための耐久実行に焦点を当てています。 2. **従来のマイクロサービスの課題**：彼らは、支払いの失敗、再試行、ロールバック、サービス間の一貫した状態の維持など、マイクロサービスアーキテクチャにおける一般的な問題について説明しています。 3. **耐久実行による解決策**：耐久実行は、実行の状態を記録し、クラッシュや失敗の場合に最後の成功したポイントから再開できるようにします。 4. **Restateによる実装**：Restateは耐久実行エンジンとして機能し、サービス実行の各ステップをログに記録し、再試行時に操作が重複したり失われたりしないようにします。 5. **耐久実行のデモ**：デモでは、意図的な障害が発生しても、支払いと配達を回復力のある方法で処理するフード注文アプリを使用して、耐久実行がどのように機能するかを示しています。 6. **状態と通信の処理**：Restateは、ログベースのデータ構造を使用して、一貫性を確保し、競合状態や重複リクエストなどの問題を回避しながら、複数の実行間で状態を管理できます。 7. **一貫した状態のための仮想オブジェクト**：Restateの仮想オブジェクトは、呼び出しを順序付けし、状態の変更が正しく順次適用されることを保証することで、一貫性を維持します。 8. **Kafkaとの統合**：Restateは、イベント駆動型アーキテクチャのためにKafkaと統合し、Kafkaイベントの処理を簡素化し、マイクロサービス全体での順序と一貫性を維持します。 9. **サーバーレスおよびFunction as a Service**：耐久実行は、サーバーレスアーキテクチャにとって有益であり、関数が効率的に一時停止および再開できるようにし、コストを削減し、回復力を向上させます。 10. **アプリケーションとユースケース**：Restateの耐久実行は、インフラストラクチャのプロビジョニング、ワークフローのオーケストレーション、イベント駆動型アプリケーション、ステートフルマイクロサービスなど、さまざまなユースケースに適用でき、モダンアプリケーションのための回復力と一貫性のある基盤を提供します。 | https://kotlinconf.com/talks/584974/ | https://www.youtube.com/embed/zuPepVB52sM?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | ChaGPT4 | ||||||||||||||||||
71 | Aleksei Zinovev | Unlocking SQL Databases with Kotlin Data Analytics: A Practical Exploration | Kotlin データ分析を使用して SQL データベースのロックを解除する: 実践的な探索 | 8. Data | 以下は、アレクセイ・ジノヴェフによる「Kotlinデータ分析でSQLデータベースを解放する実践的な探求」という講演の主要なポイントです： 1. **イントロダクションと目的**： - アレクセイ・ジノヴェフは、SQLデータベースとKotlinデータ分析を探求することを目指しています。 - セッションには、Kotlinを使用してデータベースに接続し、探索する実践的な演習が含まれています。 2. **スピーカーの背景**： - アレクセイは、データサイエンス分析のためのKotlinのプロジェクトリードです。 - 分散システムとデータベースに関する経験があります。 3. **動機と課題**： - この講演は、データタスクのためにエコシステムを頻繁に切り替えることの課題に対処しています。 - ツールを頻繁に変更することなく、データの操作と視覚化を簡素化することを目指しています。 4. **基本的な概念**： - KotlinにおけるDataFrameの概念の紹介。 - DataFrameは、表形式のデータの操作を可能にし、CSVなどのさまざまなファイル形式をサポートします。 5. **Kotlin DataFrameの特徴**： - KotlinエコシステムでDataFrameを操作するための機能。 - データの読み込み、変換、および可視化のための豊富な操作機能が提供されています。 6. **デモと実践的な例**： - 実際のデータを使用したデモ、特にSQLデータベースからのデータの読み込みと可視化。 - IMDbデータベースの例を使用して、映画と俳優に関する情報を探索。 7. **SQLデータベースとの統合**： - Kotlin DataFrameライブラリを使用して、SQLデータベースに接続し、クエリを実行する方法の説明。 - SQLクエリの結果をDataFrameとして操作する方法。 8. **データの視覚化**： - KotlinのCandyライブラリを使用して、データの視覚化を行う方法。 - 棒グラフ、ヒストグラム、パイチャートなどのグラフの作成。 9. **データの共有とコラボレーション**： - 結果を同僚と共有するためのツールと方法の紹介。 - GitHub Gistやノートブックを使用した簡単な共有方法。 10. **ドキュメントとリソース**： - Kotlin DataFrameとCandyライブラリに関する詳細なドキュメントの紹介。 - オフィシャルな例やチュートリアルが提供されていることの説明。 | https://kotlinconf.com/talks/583665/ | https://youtu.be/9iSj7vza32o | ChatGPT | ||||||||||||||||||
72 | Roman Belov | DataFrame: Kotlin's Innovative Approach to Data Structures | DataFrame: データ構造に対する Kotlin の革新的なアプローチ | 8. Data | タイトル: 「DataFrame: Kotlin のイノベーティブなデータ構造のアプローチ | Roman Belov」 - Kotlin のデータクラスは大きなイノベーションでしたが、今ではそれほど印象的ではなくなった - Jupyter 形式のノートブックを IntelliJ IDEA に統合する Kotlin Notebooks プラグインを紹介 - Kotlin Notebooks を使ってAPIからデータを取得し、JSON レスポンスを解析することを実演 - データクラスにプロパティを追加/削除する際の課題を強調 - 表形式のデータを柔軟に扱うためのソリューションとして DataFrame を紹介 - DataFrames が入れ子になったデータ構造と階層的データを扱う方法を示した - Notebooks 内で Kotlin Candy ライブラリを使ってデータを可視化することを実演 - スキーマをオンザフライで生成することで、本番コードでDataFramesを使う方法を説明 - DataFrames に基づいて型を生成する実験的な Kotlin コンパイラプラグインについて説明 - 革新的な Kotlin 技術を扱う JetBrains での機会を観衆に案内 | https://kotlinconf.com/talks/587120/ | https://www.youtube.com/embed/vQM6pQF8W1s?autoplay=true&rel=0&modestbranding=1&enablejsapi=1&origin=https%3A%2F%2Fkotlinconf.com&widgetid=3 | Claude | ||||||||||||||||||
73 | Maia Grotepass | A walk in the Lindenmayer fractal forests with a Kotlin notebook | Kotlin ノートブックを使用してリンデンマイヤー フラクタル フォレストを散歩する | 8. Data | マイア・グローテパスさんの講演「Kotlin Notebookでのリンデンメイヤー・フラクタルの森への散歩」の要約です： - **自己紹介**: マイア・グローテパスさんはAndroidエンジニアであり、Kotlin Notebookなどの新しいテクノロジーに興味を持っていることを紹介しました。 - **Kotlin Notebooks**: IntelliJ IDEAでのKotlin Notebookの使用方法をデモンストレーションしました。コードの実行や画像の表示、マークダウンの統合などの機能を紹介しました。 - **リンデンメイヤー・システム（L-Systems）**: 植物学者アリスティッド・リンデンメイヤーによって開発された再帰的なアルゴリズムで、文字ベースのルールを使って植物の成長をモデル化する方法を説明しました。 - **タートルグラフィックス**: 「亀」のメタファーを使って、これらのL-Systemsがどのように視覚化されるかを説明しました。'F'（前進する）、'+'（右に回転する）、'[' ']'（状態の保存/復元）などのコマンドが図形を描画するために解釈されます。 - **フラクタル**: ベノワ・マンデルブロのフラクタルを触れ、L-Systemsが単純なルールから複雑で自己相似的な構造を生成する方法について言及しました。 - **変化の追加**: 確率的なルール適用や描画のための確率的な角度など、L-Systemsの描画にランダム性を導入する技術を紹介しました。 - **森の生成**: L-Systemsを使ってプログラムで木や灌木の森を生成する方法を紹介し、異なる設定が多様な視覚的結果を生み出すことを示しました。 - **データフレームと可視化**: Kotlinのデータフレーム機能を使って生成された植物データを管理し、位置や色などの属性を可視化する方法を紹介しました。 - **インタラクティブな可視化**: Kotlin Notebookでのキャンバスや画像処理を使った動的な森のシーンの可視化方法を実演しました。 - **ライブラリの統合**: コルーチンを使った並列画像処理などの高度な機能を持つ外部のKotlinライブラリを統合する方法を示しました。 マイアさんは、Kotlin Notebookを通じて、自然からインスパイアされた複雑な視覚的結果を生み出すための単純なルールの力を、芸術、科学、プログラミングの交差点で探求しています。 | https://kotlinconf.com/talks/548456/ | https://youtu.be/WdeCsUzv0c8 | ChatGPT3 | ||||||||||||||||||
74 | ||||||||||||||||||||||||||
75 | ||||||||||||||||||||||||||
76 | ||||||||||||||||||||||||||
77 | ||||||||||||||||||||||||||
78 | ||||||||||||||||||||||||||
79 | ||||||||||||||||||||||||||
80 | ||||||||||||||||||||||||||
81 | ||||||||||||||||||||||||||
82 | ||||||||||||||||||||||||||
83 | ||||||||||||||||||||||||||
84 | ||||||||||||||||||||||||||
85 | ||||||||||||||||||||||||||
86 | ||||||||||||||||||||||||||
87 | ||||||||||||||||||||||||||
88 | ||||||||||||||||||||||||||
89 | ||||||||||||||||||||||||||
90 | ||||||||||||||||||||||||||
91 | ||||||||||||||||||||||||||
92 | ||||||||||||||||||||||||||
93 | ||||||||||||||||||||||||||
94 | ||||||||||||||||||||||||||
95 | ||||||||||||||||||||||||||
96 | ||||||||||||||||||||||||||
97 | ||||||||||||||||||||||||||
98 | ||||||||||||||||||||||||||
99 | ||||||||||||||||||||||||||
100 |