2026年7月10日金曜日

AppleとAdobeの関係は長い歴史があります。

 AppleとAdobeの関係は長い歴史があります。実際、私たちはAdobeの創業者たちが、いわゆる「ガレージ」で活動していた頃に彼らと出会いました。AppleはAdobeにとって最初の大口顧客であり、当社の新しいLaserWriterプリンターにAdobeのPostScript言語を採用しました。AppleはAdobeに出資し、長年にわたり同社の株式の約20%を保有していました。両社は緊密に連携してデスクトップパブリッシングの先駆者となり、多くの素晴らしい時間を共有しました。しかし、その黄金時代以来、両社の関係は疎遠になっていきました。Appleは存亡の危機を乗り越え、一方のAdobeはAcrobat製品を武器に法人市場へと進出していきました。今日でも両社は、共通のクリエイティブユーザーにサービスを提供するために協力関係を続けています――MacユーザーはAdobeのCreative Suite製品の約半数を購入しています――が、それ以外には共通の関心事はほとんどありません。

顧客や批評家の方々に、なぜ私たちがiPhone、iPod、iPadでFlashを許可しないのかをより深く理解していただくため、アドビのFlash製品に関する私たちの考えをいくつか書き留めておきたい。アドビは、私たちの決定を主にビジネス上の理由によるものと位置づけている――彼らは、私たちがApp Storeを守りたいだけだと言っている――が、実際には技術的な問題に基づいている。アドビは、私たちがクローズドなシステムであり、Flashはオープンであると主張しているが、実際にはその逆である。説明させてほしい。

まず、「オープン」についてです。

アドビのFlash製品は100%独自仕様です。これらはアドビからのみ入手可能であり、将来の機能強化や価格設定などについてはアドビが単独で決定権を持っています。アドビのFlash製品は広く利用可能ですが、それらは完全にアドビによって管理され、アドビからのみ入手できるため、オープンであるとは言えません。ほぼあらゆる定義において、Flashはクローズドなシステムです。

Appleにも多くの独自製品があります。iPhone、iPod、iPadのオペレーティングシステムは独自仕様ですが、私たちはウェブに関連するすべての標準はオープンであるべきだと強く信じています。AppleはFlashを使用する代わりに、HTML5、CSS、JavaScript――これらすべてがオープン標準――を採用しました。Appleのモバイルデバイスには、これらオープン標準を高性能かつ低消費電力で実装したものがすべて搭載されています。AppleやGoogleをはじめとする多くの企業が採用している新しいウェブ標準であるHTML5により、ウェブ開発者は(Flashのような)サードパーティ製のブラウザプラグインに依存することなく、高度なグラフィックス、タイポグラフィ、アニメーション、トランジションを作成できます。HTML5は完全にオープンであり、Appleもメンバーである標準化委員会によって管理されています。

Appleは、ウェブのためのオープンスタンダードを自ら策定することさえあります。例えば、Appleは小さなオープンソースプロジェクトから着手し、WebKitを開発しました。これは完全なオープンソースのHTML5レンダリングエンジンであり、当社のすべての製品で使用されているSafariウェブブラウザの中核を成しています。WebKitは広く採用されています。GoogleはAndroidのブラウザでこれを使用しており、Palmも、Nokiaも使用しています。また、RIM(BlackBerry)もこれを使用すると発表しています。マイクロソフト製を除くほぼすべてのスマートフォンのウェブブラウザがWebKitを採用しています。AppleはWebKit技術をオープン化することで、モバイルウェブブラウザの標準を確立しました。

第二に、「フルウェブ」という問題があります。

アドビは、ウェブ上の動画の75%がFlash形式であるため、Appleのモバイルデバイスでは「フルウェブ」にアクセスできないと繰り返し主張しています。しかし、彼らが言及していないのは、これらの動画のほぼすべてが、より新しいフォーマットであるH.264でも利用可能であり、iPhone、iPod、iPadで視聴できるという点だ。ウェブ上の動画の約40%を占めると推定されるYouTubeは、すべてのAppleモバイルデバイスにプリインストールされたアプリでその真価を発揮しており、特にiPadでは、おそらく史上最高のYouTubeの検索・視聴体験を提供している。これに加え、Vimeo、Netflix、Facebook、ABC、CBS、CNN、MSNBC、Fox News、ESPN、NPR、Time、The New York Times、The Wall Street Journal、Sports Illustrated、People、National Geographic、その他数え切れないほどのメディアからの動画も利用可能です。iPhone、iPod、iPadのユーザーは、動画コンテンツをほとんど見逃しているわけではありません。

アドビのもう一つの主張は、AppleデバイスではFlashゲームが再生できないというものです。これは事実です。幸いなことに、App Storeには5万本以上のゲームやエンターテインメントタイトルがあり、その多くは無料です。iPhone、iPod、iPad向けに利用可能なゲームやエンターテインメントタイトルの数は、世界のどのプラットフォームよりも多いのです。

第三に、信頼性、セキュリティ、そしてパフォーマンスがあります。

シマンテックは最近、2009年のセキュリティ実績が最悪の部類に入るものとしてFlashを指摘しました。また、Macがクラッシュする最大の原因がFlashであることも、私たちは身をもって知っています。私たちはこれらの問題を解決するためにアドビと協力してきましたが、問題はここ数年ずっと続いています。Flashを追加することで、iPhone、iPod、iPadの信頼性やセキュリティを低下させることは望んでいません。

さらに、Flashはモバイルデバイス上で良好なパフォーマンスを発揮していません。ここ数年、私たちはAdobeに対し、モバイルデバイス――どのデバイスでも構わない――上でFlashが良好に動作する様子を提示するよう繰り返し求めてきました。しかし、そのような例を一度も目にしたことはありません。Adobeは当初、2009年初頭にスマートフォン向けFlashをリリースすると公言していましたが、その後2009年後半、さらに2010年前半と延期され、現在は2010年後半になると言っています。最終的には搭載されるだろうとは思うが、期待しすぎて待たなくてよかったと安堵している。実際にどのようなパフォーマンスになるかは誰にも分からない。

第四に、バッテリー駆動時間の問題がある。

動画再生時のバッテリー駆動時間を長くするためには、モバイル端末はハードウェアで動画をデコードしなければならない。ソフトウェアでのデコードでは消費電力が大きすぎるからだ。現代のモバイルデバイスに使用されているチップの多くには、H.264と呼ばれるデコーダーが搭載されている。これは、あらゆるブルーレイDVDプレーヤーで使用され、Apple、Google(YouTube)、Vimeo、Netflix、その他多くの企業に採用されている業界標準である。

Flashは最近H.264のサポートを追加したが、現在、ほぼすべてのFlashウェブサイトの動画は、モバイルチップには実装されていない旧世代のデコーダーを必要とし、ソフトウェアで実行しなければならない。その違いは顕著です。例えばiPhoneでは、H.264動画は最大10時間再生できますが、ソフトウェアでデコードされる動画は、バッテリーが完全に消耗するまでに5時間未満しか再生できません。

ウェブサイトがH.264を使用して動画を再エンコードすれば、Flashを一切使用せずに動画を配信することが可能になります。AppleのSafariやGoogleのChromeといったブラウザでは、プラグインを一切必要とせずに完璧に再生され、iPhone、iPod、iPadでも見栄えが抜群です。

第五に、「タッチ」があります。

Flashは、マウスを使うPC向けに設計されており、指で操作するタッチスクリーン向けではありません。例えば、多くのFlashウェブサイトは「ロールオーバー」に依存していますが、これはマウスのカーソルを特定の場所に合わせると、メニューやその他の要素がポップアップ表示される機能です。Appleの革新的なマルチタッチインターフェースはマウスを使用せず、ロールオーバーという概念自体が存在しません。ほとんどのFlashウェブサイトは、タッチ操作対応デバイスをサポートするために書き直す必要があります。開発者がFlashウェブサイトを書き直す必要があるのなら、HTML5、CSS、JavaScriptといった最新の技術を採用しない手はないでしょう。

たとえiPhone、iPod、iPadでFlashが動作したとしても、ほとんどのFlashウェブサイトがタッチ操作対応デバイスをサポートするために書き直さなければならないという問題は解決されません。

第六に、最も重要な理由です。

Flashがクローズドでプロプライエタリであり、重大な技術的欠点があり、タッチ操作対応デバイスをサポートしていないという事実に加え、iPhone、iPod、iPadでFlashを許可しないさらに重要な理由があります。ウェブサイトからの動画やインタラクティブコンテンツの再生にFlashを使用することのデメリットについてはすでに議論しましたが、アドビは開発者に対し、当社のモバイルデバイス上で動作するアプリを作成するためにFlashを採用するよう求めています。

プラットフォームと開発者の間にサードパーティ製のソフトウェア層を挟むことは、結局のところ水準以下のアプリを生み出し、プラットフォームの機能強化や進歩を妨げる結果になることを、私たちは苦い経験から知っています。開発者がサードパーティ製の開発ライブラリやツールに依存するようになれば、プラットフォームの機能強化の恩恵を受けられるのは、そのサードパーティが新機能を採用することを選択した場合に限られます。私たちの機能強化をいつ、どのように開発者に提供するかを、サードパーティの裁量に委ねるわけにはいきません。

この状況は、サードパーティがクロスプラットフォーム開発ツールを提供している場合、さらに深刻になります。サードパーティは、サポートするすべてのプラットフォームで利用可能にならない限り、あるプラットフォームの機能強化を採用しない可能性があります。その結果、開発者が利用できるのは、機能の「最小公倍数」に過ぎなくなります。繰り返しになりますが、競合他社のプラットフォームで利用できないという理由だけで、開発者が私たちの革新や機能強化を利用できなくなるような結果は、決して容認できません。

Flashはクロスプラットフォーム開発ツールです。開発者が最高のiPhone、iPod、iPadアプリを作成できるよう支援することは、アドビの目標ではありません。彼らの目標は、開発者がクロスプラットフォームアプリを作成できるよう支援することです。そして、アドビはAppleのプラットフォーム向けの機能強化の採用において、痛々しいほど遅れています。例えば、Mac OS Xがリリースされてからすでに10年近く経っていますが、アドビがこれを完全に(Cocoaとして)採用したのは、CS5をリリースしたわずか2週間前のことです。アドビは、主要なサードパーティ開発者の中で、Mac OS Xを完全に採用した最後の企業でした。

私たちの動機は単純です。開発者に最も先進的で革新的なプラットフォームを提供し、開発者がこのプラットフォームを土台として、世界がこれまでに見たことのない最高のアプリを創り出せるようにしたいのです。開発者がさらに素晴らしく、強力で、楽しく、便利なアプリケーションを作成できるよう、プラットフォームを継続的に強化していきたいと考えています。これは皆にとってメリットがあります。最高のアプリがあるからこそ、私たちはより多くのデバイスを販売でき、開発者はますます幅広いユーザー層や顧客基盤にリーチでき、ユーザーはどのプラットフォームよりも豊富で最高品質のアプリラインナップに常に喜びを感じることができます。

結論。

FlashはPC時代に、PCとマウス向けに開発されました。Flashはアドビにとって成功したビジネスであり、彼らがPC以外の分野へ展開したいと考える理由も理解できます。しかし、モバイル時代とは、低消費電力のデバイス、タッチインターフェース、そしてオープンなウェブ標準が鍵となる時代であり、これらはすべてFlashが及ばない分野です。

Appleのモバイルデバイス向けにコンテンツを提供するメディアが雪だるま式に増えていることは、動画の視聴やあらゆる種類のウェブコンテンツの閲覧に、もはやFlashが不要であることを示しています。また、AppleのApp Storeに20万ものアプリが存在することは、数万人の開発者がゲームを含むグラフィカルに豊かなアプリケーションを作成する上で、Flashが不要であることを証明しています。

HTML5のような、モバイル時代に生まれた新しいオープン標準が、モバイルデバイス(そしてPCでも)で主流となるでしょう。おそらくアドビは、過去を捨て去ったアップルを批判することに注力するよりも、将来に向けた優れたHTML5ツールの開発に、もっと力を入れるべきでしょう。

スティーブ・ジョブズ

2010年4月


https://web.archive.org/web/20100501010616/http://www.apple.com/hotnews/thoughts-on-flash/

2026年7月9日木曜日

🔨ブラウザ上で電子工作 論理回路構築を勉強できる簡単電子工作のlogic.ly(ロジックリー) 線でつなげてできあがり  everycircuitとの違い

 

ローコード電子工作 GUIで作れるよ

無料版だとセーブできないが、電球がピカピカつくのでわかりやすい

https://logic.ly/demo

画像
こんな画面です。こちらえずLチカ(バルブチカ)しましょ
画像
部品置きの
画像
線でつなげてできあがり、ボタンをおします
画像
ピカー

というわけで、誰でも簡単に論理回路を作れるが、お気づきの通りプラスとかマイナスとかはないので、あくまで論理的な思考をこれで鍛えていこう

本格的に直流やら交流やらやりたいひとは everycircuitがおすすめですが、結局電子回路買ってのシミュレーションなので、ほんとにわかんないうちはロジックリーでつなげて遊んで見るものいいと思います。

『ファイブスター物語』において、アマテラスがジュノーンを見て「可動ラインが見えない」ことを高い耐久性の証拠として評価する場面

 『ファイブスター物語』において、アマテラスがジュノーンを見て「可動ラインが見えない」ことを高い耐久性の証拠として評価する場面は、工業製品における構造統合の美を端的に示している。可動部には本来、ヒンジ、分割線、クリアランス、逃げ、段差などが必要であり、それらはしばしば弱点や設計上の制約を外観に露出させる。これに対し、隠し蝶番、フラッシュドア、格納式ドアハンドル、航空機のギャップシールなどは、可動機構を内部に処理し、閉鎖時には一体の面として見せる。ここでの美しさは装飾ではなく、可動、耐久、放熱、整備性といった複数条件が破綻なく統合された結果として現れる。したがって「線が見えない」とは、単に継ぎ目が少ないことではない。構造上必要な余白や変形を、外部に弱点として露出させない設計完成度の象徴である。ジュノーンの美は、性能を誇示する鋭さではなく、無理なく動き、長く耐え、なお一体として美しい機械に宿る機能美なのである。

関連キーワード:
アマテラス、ジュノーン、可動ライン、構造統合、隠し蝶番、フラッシュサーフェス、クリアランス、耐久設計、応力分散、工業デザイン、機能美、永野護、モーターヘッド

ABAP CDS

 ABAP CDSは、関係データベース上の表や列を、単なる保存構造ではなく、業務上の意味を備えたデータモデルとして記述するための仕組みである。従来のSQLが主として取得対象、結合条件、集約方法を表現するのに対し、CDSはAssociation、Composition、型、権限、通貨・単位、UI、分析、API公開などのメタデータを同一モデルへ重ねる。これにより、受注、顧客、明細といった企業内の概念を、画面や個別プログラムごとに再定義せず、中央の意味モデルとして共有できる。この思想は、Javaオブジェクトを中心とするEJBやSpringのORMよりも、AEMの基盤となったJCR、Apache Jackrabbit、Apache Slingの構造に近い。JCRがコンテンツを型、属性、参照、階層を持つノードとして保存し、SlingがHTTPリソースとして公開するように、ABAP CDSは業務データを意味付きエンティティへ変換し、Service DefinitionとODataを通じて外部へ公開する。ただし、AEMが記事や画像などのコンテンツ管理を主目的とするのに対し、CDSは会計、在庫、販売など、整合性と権限制御を伴うトランザクションデータを扱う。したがってABAP CDSは、SQLビューの拡張ではなく、企業の帳簿をセマンティックな情報資源へ変換するモデル記述言語として理解できる。

関連キーワード:ABAP CDS、セマンティックデータモデル、OData、JCR、Apache Jackrabbit、Apache Sling、AEM、Association、Composition、メタデータ駆動、業務エンティティ、Service Definition

2026年7月7日火曜日

I²Cは、SDAとSCLの2線を用いて複数の集積回路を接続する同期式シリアル通信方式である。

 I²Cは、SDAとSCLの2線を用いて複数の集積回路を接続する同期式シリアル通信方式である。しかし、I²C規格そのものが温度、加速度、表示内容などの意味を定義しているわけではない。規格が担うのは、START/STOP条件、デバイスアドレス、読み書き方向、ACK/NACK、バイト転送といった通信上の共通手順である。その上に、各ICが独自のレジスタマップ、コマンド体系、データ形式を実装する。したがって、レジスタ領域はI²Cに内在するものではなく、接続されたIC内部の設計として存在する。ドライバは、この階層差を吸収するため、下位のI²C送受信ルーチンと、上位のIC固有処理に分離される。PIC、STM32、Raspberry Pi Picoなどでは関数名や周辺回路の制御方法が異なるが、レジスタ番号を指定し、値を読み書きするという構造は共通している。Wokwiのようなシミュレーターを利用すれば、I²Cスキャナーによるアドレス探索、SSD1306へのコマンド送信、ロジックアナライザーによる信号観察を通して、通信規格と上位プロトコルの境界を実験的に理解できる。「味わう」学習では、ライブラリを単に利用するのではなく、共通ルーチン、IC固有ドライバ、実際の信号波形を往復して観察することが重要である。

関連キーワード:I²C、シリアル通信、レジスタマップ、デバイスアドレス、ACK/NACK、上位プロトコル、デバイスドライバ、HAL、PIC、ARM Cortex-M、STM32、Raspberry Pi Pico、SSD1306、Wokwi、ロジックアナライザー

「えに熊」は、意図的に脆弱性を組み込んだ暗号通信プロトコルを設計・実装・観察することで、暗号技術の構造を体験的に理解する教育プロジェクトである

 「えに熊」は、意図的に脆弱性を組み込んだ暗号通信プロトコルを設計・実装・観察することで、暗号技術の構造を体験的に理解する教育プロジェクトである。本プロジェクトの目的は、強い暗号方式をブラックボックスとして利用することではなく、なぜ暗号が破られるのか、また安全性がどの要素によって成立しているのかを、通信過程そのものから味わうことにある。教材として扱う弱点は、単純な鍵長不足に限定されない。換字暗号の頻度分析、固定鍵XOR、反復鍵、乱数やnonceの再利用、リプレイ攻撃、中間者攻撃、認証不在、改ざん検出の欠如、情報を漏洩するエラー応答、暗号方式のダウングレードなど、異なる原理に基づく脆弱性を体系的に構成する。それぞれのプロトコルは、送信者、受信者、通信路、攻撃者という役割を明示し、パケットの盗聴、改変、再送、解析を可能とする。これにより学習者は、暗号化のみでは完全性や認証を保証できず、安全な通信が暗号、鍵交換、乱数、状態管理、再送防止を組み合わせた総合的設計であることを理解する。「えに熊」は、失敗するプロトコルを安全な実験対象として提示し、破る経験を通じて正しい設計原則を獲得する、暗号プロトコル教育環境である。

関連キーワード:暗号プロトコル、教育用暗号、脆弱性、換字暗号、XOR暗号、鍵再利用、nonce、リプレイ攻撃、中間者攻撃、完全性、認証、鍵交換、パケット解析、セキュリティ教育、ENIKUMA


ずらし熊 シーザー暗号
XOR熊 固定鍵XOR
くり返し熊 反復鍵
再送熊 リプレイ攻撃
なりすまし熊 中間者攻撃
乱数熊 nonce・乱数の失敗

Qualcomm系のFastRPC周辺コード

 Qualcomm BREWは、2000年代の携帯電話市場において、端末メーカー、通信事業者、開発者を結び付けるアプリケーション実行・配布基盤として重要な役割を果たした。しかし、その技術的系譜をiOSやAndroidへ直結させる見方は慎重であるべきである。BREWはAEEを中心とする独自API、署名付きモジュール、キャリア審査、専用SDKという閉じた流通構造を備えていたのに対し、AndroidはAPK、DEX、Binder、Linux権限モデルを基盤とし、iOSもMach-O、Darwin、Apple独自の署名体系を採用している。したがって、公開アプリ基盤としてのBREWは、後継へ発展したというより、歴史的に断絶したとみるのが妥当である。

ただし、BREW/AEE由来の型名やヘッダ、識別子体系が、Qualcomm系のFastRPC周辺コードなどに残存した例は確認できる。これはBREWの実行環境や配布モデルが継承されたことを意味せず、過去の共通基盤、互換層、社内ミドルウェアにおける技術的残滓と解釈すべきである。「味わう」という観点では、BREWは成功した仕様が次世代標準へ受け継がれるとは限らず、プラットフォーム本体が消滅しても、その語彙や部品だけが周辺コードに沈殿することを示す好例である。

関連キーワード
Qualcomm BREW、Brew MP、AEE、FastRPC、モバイルプラットフォーム、キャリア主導型配布、署名モデル、専用SDK、互換層、技術的残滓、Android、iOS、ミドルウェア、API系譜、プラットフォーム断絶