株式会社ずんだもん技術室AI放送局 podcast 20241101
内容紹介
AIやテクノロジーに関する記事を紹介 Gemini in Android Studio, now helping you across the development lifecycle、Playwrightを参考にブラウザ内テキスト検索を高速化する (事例紹介:サードパーティスクリプト提供会社)、Pythonプロジェクトでflat layoutではなくsrc layoutが推奨される理由を理解する
出演者
関連リンク
Android Studioに搭載されたAIコーディングアシスタント「Gemini」の大規模アップデートがリリースされました。今回のアップデートでは、開発ライフサイクルの全段階でAIを活用できるようになり、生産性の向上に大きく貢献します。
主な新機能は以下の通りです。
1. コード編集・改善機能:
- Gemini Code Transforms: プロンプトによるコードの修正やリファクタリングが可能になります。複雑なコード変更も簡単に実行できます。
- コミットメッセージ生成: コード変更を分析し、適切なコミットメッセージを自動生成します。バージョン管理の効率化に役立ちます。
- Rethink and Rename: クラス、メソッド、変数名の変更を支援します。より直感的で分かりやすい名前に変更できます。
- プロンプトライブラリ: よく使うプロンプトを保存・管理できます。再利用することで作業時間を短縮できます。
- ドキュメント生成: 選択したコードスニペットのドキュメントを簡単に生成できます。コードの可読性向上に役立ちます。
2. UI開発支援機能:
- Composeプレビューの自動生成: Composeを使ったUI開発において、プレビューに必要なモックデータを自動生成します。UIデザインの確認を迅速化できます。
- マルチモーダル対応（近日公開予定）: 画像をコンテキストとして利用できるようになり、より直感的なUIデザインが可能になります。
3. アプリ品質向上機能:
- 単体テストシナリオ生成: ローカルのコードコンテキストに基づいて、単体テストのシナリオを自動生成します。テスト作成の負担を軽減できます。
- ビルド/同期エラー分析: ビルドや同期エラーに関する分析機能が強化されました。エラー解決の時間を短縮できます。
- App Quality Insightsの機能強化: Google Play ConsoleとFirebase Crashlyticsから報告されたクラッシュに関する分析と修正提案機能が強化され、ローカルコードコンテキストも活用できるようになりました。バグ修正の迅速化につながります。
GeminiはAndroid StudioのCanaryチャンネルで利用可能です。多くの機能は年末にリリースされるLadybug Feature Dropで安定版チャンネルにも提供される予定です。
制約事項:
Geminiの開発支援機能を利用するには、ソースコードをサーバーに送信することに同意する必要があります。GoogleはAIの責任ある利用に尽力しており、ユーザーのプライバシー保護にも配慮しています。詳細については、提供されているプライバシーに関するドキュメントを参照ください。
新人エンジニアの皆さんにとって、GeminiはAndroidアプリ開発における強力な味方となるでしょう。ぜひ活用して、効率的な開発を目指してください。
引用元: https://android-developers.googleblog.com/2024/10/whats-new-in-gemini-in-android.html
本事例は、サードパーティスクリプト提供会社(社名は非公開)におけるブラウザ内テキスト検索の高速化プロジェクトの報告です。 既存のブラウザ自動操作技術(E2Eテスト応用)では、テキスト検索が遅いため、Playwrightのコードを参考に高速化を図りました。
まず、PlaywrightのChrome拡張機能からテキストセレクタ生成コード(InjectedScript)を移植・調査しました。Playwrightは独自のセレクタを用いてテキスト検索を実現しており、DOM全体を走査してテキストインデックスを作成していました。このインデックス作成と、DOM変更監視のためのMutationObserverが、パフォーマンスボトルネックとなっていました。
計測にはDevToolsのPerformanceタブを使用し、特にJavaScriptタスクの処理時間をBottom-Up表示で分析しました。その結果、lodash.isElementによる要素判定(約9ms)と、PlaywrightのelementText関数によるテキストインデックス作成(約13ms)が問題点として浮上しました。
lodash.isElementについては、el instanceof HTMLElementに置き換えることで、不要なオブジェクト走査を排除し、処理時間をゼロに削減しました。これは、lodashがIE時代のレガシーコードを含み、現代の環境ではオーバーヘッドとなることを示しています。
elementText関数については、DOM走査にdocument.createTreeWalkerを使用することで大幅な高速化を実現しました。createTreeWalkerは、従来のforループによるDOM走査に比べて10倍以上の速度向上を示すベンチマーク結果も確認しています。 さらに、検索クエリを事前に把握していることを活かし、検索クエリに完全一致するテキストノードのみを抽出することで、インデックス処理時間を2ms、検索時間を0.1msにまで短縮しました。
本プロジェクトを通して、以下の知見を得ました。
- 木構造のトラバースは遅い。
document.createTreeWalkerを用いることで高速化できる。 - ライブラリ関数は、過剰な汎用性によりパフォーマンスを低下させることがある。必要に応じて、より制約の強い実装に置き換えることで高速化できる。
- 現代のフロントエンド開発では、DOM操作のコストを意識することが重要である。
本事例は、既存のライブラリを適切に活用し、パフォーマンスボトルネックを特定・解決することで、ブラウザ内テキスト検索を大幅に高速化できたことを示しています。 特に新人エンジニアにとって、DevToolsによるパフォーマンス計測と、ライブラリ関数の適切な選択・改良の重要性を示唆する事例となっています。
引用元: https://zenn.dev/mizchi/articles/fast-dom-text-search
Pythonプロジェクトのディレクトリ構成には、パッケージをプロジェクトルート直下に置くflat layoutと、srcサブディレクトリに置くsrc layoutの2種類があります。多くのPythonプロジェクトではsrc layoutが推奨されています。その理由は、テストの安全性にあります。
flat layoutでは、Pythonインタプリタがカレントディレクトリをインポートパスの先頭に置くため、開発中のコードが誤ってインポートされる可能性があります。例えば、テストコードがまだパッケージに含まれていない開発中の関数を呼び出してしまうと、テストが通ってしまい、潜在的なバグを見逃す危険性があります。
一方、src layoutでは、パッケージはsrcディレクトリ内に配置され、ビルド時にパッケージ化されます。テストを実行する際には、ビルド済みのパッケージが使用されるため、開発中のコードが誤って実行されることはありません。テストは、実際にリリースされるコードに対して行われるため、より信頼性の高いテスト結果が得られます。
記事では、flat layoutとsrc layoutでそれぞれパッケージを作成し、テストを実行する実験が行われています。その結果、flat layoutでは開発中のコードが意図せず使用され、テストが誤って成功するケースが確認されました。src layoutでは、開発中のコードが使用されず、テストが適切に失敗することで、問題を早期に発見できることが実証されました。
ただし、多くの著名なPythonプロジェクト(pandas、numpy、scikit-learnなど)はflat layoutを採用しています。これは、テスト方法やプロジェクトの規模、開発スタイルなど、様々な要因が影響していると考えられます。src layoutはテストの安全性という点で優れていますが、プロジェクトの状況に応じてflat layoutを選択することもあります。
新人エンジニアとして、Pythonパッケージ開発を始める際には、src layoutを採用することで、テストの信頼性を高め、バグを早期に発見できる可能性が高まります。 flat layoutとsrc layoutのそれぞれのメリット・デメリットを理解し、プロジェクトの状況に合わせて適切な構成を選択することが重要です。 本記事は、src layoutの利点を理解するための良い例題となっています。 GitHubリポジトリには、flat layoutとsrc layoutの具体的な実装例とテストコードが公開されているので、ぜひ参照して理解を深めてください。
引用元: https://nsakki55.hatenablog.com/entry/2024/10/28/095509
（株式会社ずんだもんは架空の登場組織です）