AQUOS sense7への充電とUSBケーブルについて

前提として、本記事では次のように「充電」の種類を呼称する。

• 急速充電　　　　：7.5W以上
  （例えばPDの1パターン9V・2A＝18Wなど。5V・1.5A＝7.5Wもここに分類する）


• 充電（通常充電）：7.5W未満〜1W以上（5Vなら1.5A未満〜0.2A以上）


• 低速充電　　　　：1W未満

※これは一般的な定義では無く、とりあえず今回の分類。「急速充電」は、一般には15W以上が分類される気がするが、今回に検証した端末での表示に合わせてこのようにする。
※充電と関連の規格名称に関する、本記事で必要な情報は後述。
※Type-C to Cでの充電時の実際の供給電力は未計測（計測器を持っていないため）。Type-A to Cでの充電時は5V固定として電流を記載。
※「メーカー純正の充電器とケーブルを使うが確実」なのは言わずもがな。この記事は「他にも端末を持っているので、汎用的な充電器で対応したい」が目的。
※普段使いのZenFone5Zととの比較の観点で書いたメモとなる。



AQUOS sense7の充電は、USB PD対応を用いることが推奨。つまり、「USB PD対応のACアダプター」とPD対応もしくは準ずる「USB Type-C to Cケーブル」を用いる必要がある。この組み合わせなら急速充電になる。
それ以外、たとえばUSB Type-A出力でType-A to Cケーブルの組み合わせは、（通常）充電、もしくは低速充電となる。
（通常）充電の場合でも0.5〜0.9Aくらいまでにとどまることが大半であり、またUSBケーブルとの相性が大分あって]「低速充電（0.2A未満）」となる事も少なくない。[* C to Cケーブル以外での充電はお勧めできない。

比較として、Zenfone5Zの充電はC to CケーブルでもＡ to Cケーブルの組み合わせでもどちらでも問題なし。
C to Cケーブルなら急速充電になることはもちろんのこと、A to CのケーブルでもACアダプター次第で急速充電になる（後者は1.5A）。
（通常）充電の場合でも、0.9A〜1.2Aくらい出してくれることが多く、経年劣化したケーブル以外で低速充電（0.2A未満）の表示になったことはない。利用するケーブルは「通信も可能なケーブル」を選べばどれでもよい（※QCは通信を前提にとする仕様なので、充電専用ケーブルは避けた方がよい）。

純正の充電アダプターとケーブルを用いる限りにおいては発現しない差なのだろうけど、機種によって充電周りにこのくらいの差がある、というのは驚いたね。


【参考】
「このAC充電器で急速充電が出来た」の具体的な商品名が知りたい方は、下記を参照。

* Scrapbox ＞ AQUOS sense7への充電とUSBケーブルについて



【充電と関連の規格名称】
本記事における充電関連の規格名称と、留意点は以下。

• QC = Quick Charge
  - USB 2.0や3.0とは独立の規格。Qualcomm社独自の充電規格
  - USB Type-AもType-B(micro Type-B)、Type-Cも何れのケーブルも利用可能。ケーブルごとに対応が異なり、Type-A/Bケーブルでは5V・2A（=10W）充電まで、Typc-Cケーブルならそれに加えてより高い電圧での9V・2A（＝18W）充電などもサポート
  


• PD = USB PD = USB Power delivery
  - USB Type-Cケーブルでのみ利用可能（全てのType-CケーブルがPD対応ではなく、Type-C且つPD対応ケーブルが推奨。ただし、PD未対応ケーブルでもPDで動作することある感）
  - 長さに関する決まりは無く、併用される通信側のUSB規格に準ずる感？（PDはあくまで充電に関する拡張規格なので）
  


• USB BC1.2
  - 5V・1.5A（＝7.5W）充電が可能
  - 長さに関する決まりは無く、併用される通信側のUSB規格に準ずる感？（BCはあくまで充電に関する拡張規格なので）
  


• USB 3.0( =USB3.1 Gen1)
  - 5V・0.9A（＝4.5W）充電が可能
  - 長さは最大2m
  


• USB 2.0
  - 特に断りなければ、昨今のUSBケーブル（A/B/C）はこれ。少なくともこの規格には対応している。
  - 5V・0.5A（＝2.5W）充電が可能
  - 長さは最大5m
  

JSTQBファウンデーション資格を受験してみた（ので勉強方法など）

JSTQB認定テスト技術者資格のFoundation Levelを受験してみたので、その際の勉強方法などを記録。

※本記事は、ScrapBox側からの転記です。

前提

まず、勉強開始前の当方の状況など。

• ソフトウェアテストに関して特段勉強した経験などは無し
• 「V字モデル」は知っていた
• ソフトウェア製品開発の中で「テスト項目の作成、項目に従ってテストを実行、実行結果を記録して報告」は一通り経験
  • 「一通り経験」は「やったことはあります」という程度

勉強方法

試験勉強として、やった事は以下の通り。

• JSTQBシラバスを通しで読む
  • 「書いてあることがよく分からん」を無い状態を目指して繰り返し読んだ。
  • 少なくとも「分かったつもり」と言える状態を目指した（説明できる、とは言わない）
  • 1日1時間くらいずつ、4-5週間かけて実施（したがって、7日／週として28〜35時間くらい所要）
• テス友アプリ を使って、ひたすら問題を解く
  • 10問/1セット形式。1セット/12分の時間配分で1セット/1日くらいのペースで4週くらい解いた。その後、3セット/1日を2週、4セット/1日を0.5週間、やった
    • したがって、12分×(128 + 314 + 4*4) = 17.2h 〜19時間くらい所用（+2hは間違えた問題の解説を参照するなどの分）
  • 正答率の推移：
    • 開始週：60-70％
    • 最終週：80-100％
• 参考書を買って、試験直前の週あたりで、巻末に付属の模擬試験1セットを解く
  • 本番のテストを想定したら量、時間配分などを把握するための予行演習、として位置付けた
  • 正答率は82％ほど。
    • 合格ラインが「65％以上」なので、「まぁ大丈夫だろう」と捉えて本番へ臨んだ
  • 参考書の模擬試験以外のページは、模擬試験で迷ったり誤った部分を中心にパラっと読んだ
    • シラバス読んでて＆テス友で苦手とした章、も追加でパラパラと目を通した

勉強時間の総時間としては、35+19+1=55ｈに実際はなんだかんだで確認時間等も入っているので、たぶんトータル60時間くらいかな。

※都合で、シラバスを一通り読んだ後、2ヶ月くらい勉強は中断し、それからテス友アプリで再開、してたりする。どの程度に影響があった要因かは分からないが、一応記載しておく。

上記の勉強期間を踏まえて試験に臨み、無事に「合格」を頂いた♪

感想

全体を通しての雑感としては以下。

• 参考書は、無くても合格できた気がする。

  • まぁ、念のためで、「やればよかった！」の後悔をしないために購入を決断した。
  • 模擬試験で実際の試験時間と量で通して体験すること、が目的だね。

• シラバスに書いてある内容は「まぁ、そうね」と思える内容であって、そこまで難しくは無い。

  • 「そのように定義するのね」「分類するのね」、「呼称するのね」、、、という理解していく感。
  • ・・・レビュー種別の区別、のところが一番難しかったかな。今でも少し不安。

• テス友アプリがとても優秀

  • 勉強のし易い感、が半端ない♪
  • ちょっとの時間で出来るの良い
  • こういうの、他の試験でもあると良いなぁー。

JSTQBのFLの試験勉強を経て「ソフトウェアのテストに関して会話する際の、基本用語が明確になった」感を受けた。受けて良かったと思う。

SSRアプリではMVCが主流で、SPAではMVVMが主流、だとしてそれは何故だろうか？

先ず初めに→　私はSSRアプリ作成経験はほとんど無いです。ど素人です。
その上で感想と言うか、思ったことのメモです。

※タイトル内の「SSRアプリでは〜」という表現は、「MPAでのWebアプリでは〜」（MPA=Multi Page Application）とか「従来のサーバーサイドでのWebアプリケーションでは〜」と呼称する方がたぶんが適切ですね。なぜなら「SSRは、SPAを実現するフレームワークにおいて一部をサーバー側に処理を移すためのオプション」と捉えるべきだから。もしくは「サーバーサイドでWeb画面を生成してブラウザに返します（ブラウザ側でWeb画面を変更したりしません、ページ遷移しない限りは）」という手法であって、Webアプリの種別を表現するものではないだろう。ただ、語感的に私が「MAPアプリ」と言うより「SSRアプリ」と言った方がピンと来たので、そのままこの表現で残す（素人なので、一般的ではない可能性大）。


閑話休題。
Webアプリ（Webブラウザアプリ）での話だけど、
サーバーアプリだとMVCが主流で、クライアントアプリだとMVVMが主流のように感じている。「そこの差は何故だろう？」と言うふとした疑問に対して、ふと「理由は、こういうことか？」を思えたのでメモ。
間違っていたらごめんなさい。

前提として、私は以下のように考えている。

• 「UIの実装」ってのは基本的に「データのUIへのマッパー」であるのが望ましい


• 「データをどう処理するか？」はUIとは全く別に考えるのが良い

それを踏まえるとあるべき姿は「MVVM＝Model , View ViewModel」ではないか？と思うのだ。
Viewで「データのUI表現（Mappingの仕方）」を担当して、Modelが「データ処理」を独立して扱う。そして「UI側のアクションとデータへの反映とそれに伴うUIの変化」を担当するVMはFrameworkにお任せして、実装者は触れたくない。そういう分担が分かり易いと思うのだ。

※ここでModelはCRUDを含むが、SPAの場合はその部分だけサーバー側へWeb APIで（多くの場合はREST APIで）渡して処理する、と捉えている。（したがって、Modelはクライアント側と、サーバー側にまたがっての実装、と言える）。

さて、改めて。
SPA（=Single Page App）では、MVVMが主流だと思う。
しかし、SSRではMVVMよりMVC(=Model, View, Controller)が主流に感じている。

この違いは、SPAがViewとVMを同じ言語というか動作プラットフォームであるJavaScriptで実装するからこそなのかな？、と思った。
SSRの場合、Viewの発火をVMが監視する手段、Model変更をリアルタイムでView反映する手段が、たぶん容易ではない。なぜならSSRの場合は、Viewとそれ以外の部分で言語／動作PFが異なるから（ViewはHTMLとJavaScriptであり、それ以外はJavaとかPython、もしくはRubyなど）。
なのでブラウザ側で「Viewが自身の発火をControllerに伝える」ことを起点として、そこに境界をおいて、サーバーサイドのControllerがViewとModelに対して処理を行うMVCが主流となる、、、のかな？（Controllerに制御が移ったときブラウザはサーバーからの応答待ちであって、その応答として返す画面として次のView反映され、その応答が境界となる）、
と思えてきた。

まぁ歴史的には「UIをリッチにしたいんだけど、MVCだと複雑になっていく。MVVMという概念に移行したんだが、SSRだと厳しい。・・・CSR（=Client Side Rendering）だったらMVVMを実現できるんでは？」としてSPAが生まれた、、、とかかも知らん。

さて、実際のところはどうなんだろう？　教えて、詳しい人？
（前提の「主流」からして誤っている可能性はあるｗ）


※なお、SSR＝Server Side Renderingであって、Super Special Rareの意図では無いですｗ
※あと「マッパー」は「Mapper」「Mappingをするモノ」の意図です。・・・何故かFGOのローランが脳裏に浮かぶけど、だいたい6.5部のせいだ！