2024/10/24
laprasdrum.icon 時間を増やしたい
/icons/hr.icon
Apple Intelligence + SiriKit/App Intents使うときの注意点
(ii) お客様のアプリケーションは、App Intents および/または SiriKit を通じて取得した情報を、サポートされている Apple 製品でのみ使用できます。また、ユーザーへの適切な応答を提供または改善するため、またはユーザーのリクエストを実行するために必要な範囲、あるいはお客様のアプリケーションに関連する場合を除き、そのような情報をデバイスからエクスポート、リモートアクセス、または転送することはできません。第 3.3.3(B) 項にこれと異なる定めがある場合でも、お客様およびお客様のアプリケーションは、ユーザーへの適切な応答を提供したり、SiriKit ドメイン、App Intent ドメイン、インテント、またはお客様のアプリケーションでサポートされているアクションに関連してユーザーのリクエストやインテントを実行したり、ユーザーのリクエストに対するアプリケーションの応答性を向上させる (広告を配信しないなど) 以外の目的で、App Intents および/または SiriKit、または App Intents および/または SiriKit を通じて取得した情報を使用することはできません。
3.3.3(B)は以下の通り。
B. データの収集と使用
お客様およびお客様のアプリケーション（およびお客様が広告配信の契約を結んだ第三者）は、ユーザーから直接取得したデータか、Apple ソフトウェア、Apple サービス、または Apple SDK の使用を通じて取得したデータかを問わず、事前のユーザー同意なしにユーザーまたはデバイスのデータを収集することはできません。また、その場合でも、アプリケーションの使用に直接関連するサービスまたは機能を提供するため、またはセクション 3.3.3(E)に従って広告を配信するためにのみ、収集されるものとします。お客様は、データ収集の拡大または変更について事前にユーザー同意を得ることなく、以前に収集したユーザーまたはデバイスのデータの使用範囲を拡大したり、変更したりすることはできません。お客様もお客様のアプリケーションも、デバイスを一意に識別する目的で、永続的なデバイスベースの識別子またはそこから派生したデータを使用することはできません。また、お客様もお客様のアプリケーションも、デバイスまたはユーザーを一意に識別する目的でデバイスからデータを派生させることはできません。
お客様は、お客様のアプリケーション（サードパーティの SDK（Apple が提供していない SDK）を含む）が本契約およびドキュメントに準拠していることを保証する責任を負います。お客様のアプリケーションがドキュメントで特定されている特定の API を使用する場合、お客様のアプリケーションのメタデータには、各 API の使用およびその使用から得られたデータを正確に反映する 1 つ以上の許可された理由を特定する必要があります。お客様は、これらの API およびその使用から得られたデータを、特定された理由にのみ使用できます。さらに、お客様のアプリケーションに、ドキュメントで一般的に使用されていると特定されているサードパーティの SDK が含まれている場合、お客様は、そのようなサードパーティの SDK が SDK プロバイダーによって署名され、ドキュメントに記載されている必要なメタデータが含まれていることを確認する必要があります。
(iii) お客様のアプリケーションが App Intents および/または SiriKit を使用して Apple によるオーディオ データの処理を可能にする場合、お客様は、お客様とお客様のアプリケーションが録音されたオーディオ データを音声認識、処理、および/または文字起こしの目的で Apple に送信すること、およびそのようなオーディオ データが Apple 製品およびサービスの改善と提供に使用される可能性があることをエンド ユーザーに対して明確に開示することに同意するものとします。お客様はさらに、そのようなオーディオ データ、および App Intents および/または SiriKit から返される認識されたテキストを、エンド ユーザーから明示的に同意され、本契約で明示的に許可されている場合にのみ使用することに同意するものとします。
Async Algorithm
Actor移行に向けてCombineをAsyncStreamに移行するステップを入れる必要がありそう。
とはいえ、Backpressureが未実装。
議論も1年間進んでない。頻度の高い更新があるプロパティ監視によるリソース潰し（CPU/RAM）がエッジケースとしてあり得る。
スクロール監視をしようものなら一瞬でフリーズ・クラッシュしそう。
CombineにはBackpressure機構はある。
ちなみにBackpressureの解説はNode.jsやRxJavaが理解しやすい。データ処理のシチュエーションとしてはNode.jsの方がイメージつきやすい。
RxJavaだとUberのブログが実例を伴っててよさそうだった。
Donny Walsとほぼ同意見。
私の意見では、AsyncSequenceは、始まりと終わりがあるプロセスから時間の経過とともに値を取得するのに非常に便利なメカニズムです。
オブジェクトの状態を観察するなど、よりオープンエンドのタスクの場合、Combine の方が優れたソリューションだと個人的には思います。少なくとも今のところはそうですが、将来何が起こるかは誰にもわかりません。
全体的にActor含めSwiftの並行処理機能は発展途上であり、それを認識するために様々な角度で学ばないといけない。
プロダクションで利用するには相応のリスクがあることを脳にとどめておかねばならない。
悪いコーディング文化を抜けるには
最初のループは通常次のようになります。
1. 企業はコードを書くためにソフトウェアエンジニアを雇います。
2. 書くコードが増えるほど、技術的負債（エントロピーと呼ばれることもあります）が増えます。
3. システム内のエントロピーが増加すると、新しいコードを書くのが難しくなり、全員の作業が遅くなります。
4. 進捗が遅いほど、採用する人数が増えます。
5. これでステップ 1 に戻ります。
最初のループを解決するために、企業は同様に脱出が困難な 2 番目のループを作成することがよくあります。
1. 進捗が遅いほど、採用担当者にはより早く採用しなければならないというプレッシャーがかかります。
2. 全員に対する採用のプレッシャーが強くなるほど、採用のハードルは下がります。
3. 基準が低いほど、採用されたエンジニアのスキルレベルは低くなります。
4. スキルが低いほど、システム内に悪いコードプラクティスが蓄積されます。
5. コードの品質が低下すると、速度が低下します。
これでステップ 1 に戻ります。
こうしたループが形成されるには長い時間がかかり、数年または数十年かかることもあります。いったん企業がこうしたループに陥ると、そこから抜け出すのは簡単でも早くもありません。(残念ながら、悪いコードに効く魔法の薬はありません。) あなた自身の健康と同様に、ソフトウェアの健康も「予防は治療に勝る」という格言に従っています。
しかし、すでにスパイラルに入っている場合は、次の手順に従ってください。
1. 凍結、つまりコードの作成を中止します。もちろん、これは完全には不可能ですが、コードのホットスポットを時間内に凍結することは可能です。これらのホットスポットの拡大を止め、新しい場所に新しいコードを作成できます。たとえば、LinkedIn の Operation InVersion は、 LinkedIn の古くなった旧式のソフトウェア インフラストラクチャを完全に再構築したもので、すべての新機能の開発が 2 か月間凍結されました。
2. 採用基準を引き上げます。採用方法を転換します。人材獲得チームは質の高い候補者に重点を置くという考えを強化します。
3. 開発者のスキルアップ。チームの学習と開発に力を入れます。知識ベースを現在のトレンドと今後のトレンドに合わせます。
4. 技術的負債を減らす。ミッションクリティカルなタスクフォースを編成することで、最も基本的なレベルで不良コードを排除し、再発を防ぐことができます。負債を修正し、チームのスキルを向上させるためのロードマップとタスクフォースを作成します。(たとえば、『The DevOps Handbook: How to Create World-Class Agility, Reliability and Security in Technology Organizations 』という書籍を参照してください。)
SwiftUI Preview mock data
https://www.youtube.com/watch?v=Yw7H4Ujpwtg
エンジニア採用市場調査
OracleがSenior/Eng. managerを多く囲ってるのが意外だった。
Evernoteの裏側
あとで見る。
リザード最適化
このポッドキャストは、Gojko AdzicとShane Hastieによる、ユーザー行動の観察（オブザーバビリティ）とそれを活用したプロダクト改善についてのディスカッションです。Adzicは、ユーザーの行動を測定し、意図的に変化させることが、プロダクトが価値を提供しているかどうかの判断において非常に重要であると強調しています。以下に、より詳細な解説をします。
### 1. **ユーザー行動の測定と価値提供の関係**
Adzicは、ユーザー行動の変化を観察することが、プロダクトの成功にとって重要であると主張しています。たとえば、ユーザーが新しい機能を使うことで行動がどのように変わるかを測定し、望ましい結果が出ているか確認します。これにより、プロダクトが単に動作しているだけでなく、実際に価値を提供しているかどうかが判断できます。
- **例**: Adzicは、自身のプロダクトで、ユーザーがテキストを音声に変換する機能を使う際、空白のPowerPointをアップロードしていることを観察しました。この行動は一見無意味に思えますが、実際にはユーザーが音声トラックを作成するためにこの機能を使っていたことが分かり、そのニーズに合わせて機能を最適化することでユーザー体験を改善できました。
### 2. **リザード最適化（Lizard Optimization）**
「リザード最適化」とは、ユーザーが行う一見不合理な行動（Adzicはこれを「リザード行動」と呼びます）に対応し、プロダクトを改善する手法です。多くのユーザーは、予想外の方法でプロダクトを利用することがあり、それが新しい機会を生み出すことがあります。このような行動を観察し、適切に対応することで、プロダクトの価値をさらに高めることができます。
- **リザード行動の例**: Adzicは、ユーザーが意図しないファイル形式（JPEGやAPKなど）をアップロードしてしまう行動を観察しました。このようなエラーの中には、ユーザーが意図していない操作もありますが、中にはプロダクトに新しい機能を追加するヒントとなるケースもあります。
### 3. **プロダクト成長の5つの段階**
Adzicは、プロダクトの成長における5つの段階（Empathy, Stickiness, Growth, Revenue, Scale）についても言及しています。それぞれの段階に応じた適切なアプローチを取ることで、プロダクトの成功を確実にできます。
1. **Empathy（共感）**: 最初の段階では、プロダクトがユーザーの課題を的確に解決しているかを確認することが重要です。
2. **Stickiness（定着）**: ユーザーがプロダクトを継続して使用するかどうかを測定し、ユーザーの定着率を高めるための改善を行います。
3. **Growth（成長）**: 定着が確認されたら、次に市場へのリーチを拡大し、ユーザー数を増やすための戦略を立てます。
4. **Revenue（収益）**: ユーザー数が増えた後は、持続可能なビジネスモデルを構築し、収益化を図ります。
5. **Scale（スケール）**: 最後に、ビジネスモデルが成功した段階で、より大規模に展開するための最適化を行います。
- **エンジニアへの示唆**: これらの成長段階に応じて、どのタイミングで技術的な最適化やスケーリングを行うべきかを判断することが重要です。特に、プロダクトがまだ市場に定着していない段階で過度に最適化に時間をかけることは避け、段階ごとに適切な優先事項に集中すべきだと述べています。
### 4. **開発者や運用チームの役割**
Adzicは、開発者や運用チームがプロダクト改善に大きく貢献できると考えています。彼らは、既存のツールや技術（例: DevOpsや分散トレーシング）を活用して、ユーザー行動を観察することで、プロダクトに対するフィードバックを収集し、プロダクトマネジメントに貢献できます。
- **エラーの追跡**: アプリケーションがクラッシュしなくても、ユーザーがエラーに遭遇した時点でログを取得し、どのような問題が発生しているのかを把握することで、プロダクトの改善点を特定できます。
### 5. **ユーザー行動からの学びとプロダクト改善**
ポッドキャストでは、ユーザーの行動を細かく分析し、それを活用してプロダクトを改善する重要性が強調されています。特に、予想外の行動をキャッチし、それに対応することで新しい価値を提供できることが強調されています。この「リザード行動」によるフィードバックループを短くし、迅速に対応することが、成功への鍵となるとAdzicは述べています。
このように、ユーザー行動の観察と分析を通じて、予期しない行動パターンを見つけ出し、プロダクトの改善に活かすことが成功のポイントであることが強調されています。