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


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


• 低速充電　　　　：1W未満

• 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
  

前提

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

• ソフトウェアテストに関して特段勉強した経験などは無し
• 「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の試験勉強を経て「ソフトウェアのテストに関して会話する際の、基本用語が明確になった」感を受けた。受けて良かったと思う。

1. 「Microsoftアカウント」のページにアクセスしてログインする。
   https://account.microsoft.com/


2. 上部バーの「セキュリティ」を押す。


3. 「高度なセキュリティ オプション」を押す。


4. 「サインインまたは確認の新しい方法を追加」から、コード送付先のメールアドレス、を追加する。
   

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


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

Windows10マシンのCドライブの容量不足に陥って、不要ファイルを消した話。 「私の環境では、xxxあたりを削除することで空き容量を確保できた」 ってだけなので、汎用性のほどは不明だが、誰かの参考に成れば幸い、と思って記す。

発端

OSさんが「Cドライブの残り空き容量が300MB切ったよ」と言ってきた。（正確な値は覚えてない）

んなバカな？と見に行ったら、確かに空きがほとんどなかった。。。

やったこと

以下では、Cドライブに対して「システムのクリーンアップ」を実施済みとする。Windowsアップデート関連のシステムファイルもクリーンアップ済みとする。

ChromeとFireFoxのキャッシュクリア

これで、1.2GBくらい、空き容量が増えた。

主な削減フォルダは C:\Users 配下。

まだ空き足りないので、フォルダが容量食ってるのか？をリストアップ

フリーソフトの「DiskInfo」を用いて、Cドライブのどのフォルダが容量を食っているのか？を調査（ https://forest.watch.impress.co.jp/library/software/diskinfo/ ）。

• Windows
  • 19GB
  • まぁ、これは仕方ない。
• Users
  • 14GB
  • 減らすとしたら、ここか？
• Program Files (x86)
  • 5GB まぁ、これは仕方ない。
• w32tex
  • 4GB
  • あー、これなぁ。。。。

Usersフォルダで容量が大きいやつは？

• C:\Users\ユーザー名\AppData が13GBで主因
  • AppData\Local が10GBで主因
    • AppData\Local\Packages が6GB主因
      • Packages\CanonicalGroupLimited.Ubuntu16.04onWindows(略) 4.2GBで主因
      • あー、WSLか。これは仕方ない罠
    • AppData\Local\SquirrelTemp 1.5GB
      • これ、消せない？（結論としては見送り）
  • AppData\Roaming が2GB
    • AppData\Roaming\Jane\Janetter2 が1.5GB犯人か？

SquirrelTempフォルダは、検討の結果「見送り」（必要になってから消す）とする

あまり情報が無いが、「窓アプリで、最近使われ始めたアップデート時に利用されるフレームワークSquirrelの一時フォルダ」っぽい。「clean up "SquirrelTemp"」でGoogle検索すると、少し情報が出る。

Squirrel (https://github.com/Squirrel/Squirrel.Windows) is a framework used for installing/updating windows apps. For example - Atom editor is using it.

ref. https://www.reddit.com/r/Windows10/comments/8bgsn1/what_is_squirreltemp/

開発リポジトリにて「（本来消えるべきTempだが、インスト失敗時などに残るものなので）消しても問題ないよ。残してゴメン」って回答があった。

This folder cleans itself up, but if you had a lot of failed installations / upgrades that might not happen. There are no repercussions to deleting this folder, sorry about the disk space

ref. https://github.com/Squirrel/Squirrel.Windows/issues/1195

Janeフォルダは、データベースを削除（して削減設定後に再構築）とする

AppData\Roaming\Jane\Janetter2\sqlite が1.5GB弱あって、ここが犯人。 このフォルダは、どうもツイート保存用。消しても問題なさ気。

listtweet,mention,message,search,tweet フォルダを手動で削除しても構わない ref. https://www.mazn.net/blog/2014/07/06/1365.html

Janetterを使うことは最近あまり無くなったのでJanetterごと削除しようかな、とも思わなくはないのだが、、、再インストでユーザー新規登録が「出来ない」状況を顧みるに、今すぐアンインストールは早計かな。

先ずは、このデータベースを削除する。

w32tex はLaTex関連。しばらく使ってないから、、、消すこととする

どうしてもLaTexはサイズが大きくならざるを得ない、ようだ。 ここ1年くらいLaTex単独のコンパイルはしてない。LaTexを全く使っていないわけでは無く、Re:VIEWコンパイルの過程で使ってはいるのだが、そちらはDocker経由でコンパイルしている。LaTexを直接使うことは今後は無さ気。

必要になったら、またインストールし直すことにしましょうか。幸い、過去と異なり今は、下記のインストーラーを使えば容易に（DL時間はかかるが）再導入可能となっているので。

https://www.ms.u-tokyo.ac.jp/~abenori/soft/abtexinst.html https://texwiki.texjp.org/?W32TeX

フルインストールで 2.8 GiB 程度の容量が必要です． ↑たぶん、これはだいぶ前の話。今はもっと増えて、おそらく4GBくらいになっている、のだろう。

（※自己メモ：Docker経由での利用がメインなので、もうないとは思うが、ピュアなRe:VIEWをインストールする必要が出たときは、こちらの記事に従って、実施する→ https://qiita.com/implicit_none/items/398c6e0bbedc8b160621 ）

LaTex関連のアンインストール手順

1. GPL Ghostscript
   • コンパネからアンインストール
2. GSview
   • コンパネからアンインストール
3. dviout for Windows
   • ツールを立ち上げて「Option＞uninstall」からアンインストール
4. W32Tex
   • C:\w32tex フォルダを削除

ref. https://did2memo.net/2012/04/27/tex-uninstall/

結果

9GBくらい空いた。 今回に限定した操作（使わなくなったアプリの削除、データベース削減）なので、汎用性はないが、まぁこういう事例メモが役に立つこともあるだろうから、記す。

以上ー。

これは、「技術同人誌 Advent Calendar 2019」の21日目の記事です。

昨年に「同人誌を書く理由～2年間を振り返り～」って 記事を書いた。 その中で「小さな内容でもイイから、薄い本を書き続けていこう」と結論付けていた。 あれから1年が経って試行錯誤する中で「このアプローチ方法なら書き続けていけるんじゃないかな？」と 思えたので、「このアプローチ方法」を言葉にしてみるのが、この記事の目的。

なお、昨年の記事を3行でまとめると以下。

• 技術同人誌を書いて即売会に出る、と「知見が集まってくる」。
• 「知見が集まってくる」のは、きっと楽しいこと。
• 小さくても良いから、書き続けていきたいな。

ついでに、今回の記事を3行でまとめると以下。

• 新刊のネタを意識しつつ、ネタになるか否かに関係なくブログに書く
• 技術書典や技書博（技術書同人誌博覧会）などの即売会に合わせて、ブログを見直して「もう少し調べたい」があったら新刊を目指す
• ブログからの切り貼りをメインにすることで、「イキオイ」がなくても同人誌を書ける！（と思う）

結果だけ見ると「どこかで聞いた方法」かもしれない。

一般的な「継続する方法」について

私自身に適用できそうな「継続する方法」を探したときに聞えてきたのは、 次のようなアプローチ方法。

• 短期集中よりも毎日コツコツとするのが良い
• 習慣化すればよい
• 目標を設定する

なるほど、この方法は良さそうだ。 これに従って、、、などと書くと計画的に取り込んだように聞こえるかもしれないので、 ここでぶった切る。確かに「あぁ、その方法は良さそうだ」と思ったけど、 「どうやって習慣化して、いつコツコツ行い、何を目標にすれば良い」のかな？。 少なくも私は、このアプローチ方法の具体的のところで止まった。

※なお、「締め切り駆動開発」は私は駄目だったｗ　締め切りが定まろうとも、書けないものは書けない。出来る方々は凄いわ～。

結果論だけど、「こうやったら続けられた、続けられる」気がする

今年2019年も、9/22の技術書典７で新刊を頒布することが出来た。

#技術書典 7で頒布させていただいた新刊「Vue.jsとExpressでWebアプリをテスト駆動開発する」製本版の通販が、とらのあな様で始まりました！
PDF版はBOOTH様にて通販開始しております。当日にお手に取れなかった方はぜひ♪ https://t.co/0X9HPxvIBwhttps://t.co/6TwoXp6ajphttps://t.co/Mpzxsmv8FJ

— ほしまど＠12/14[土]技書博2/2F-え05 (@hoshimado7) September 24, 2019

なんとか設営終わったー！「う47C」で新刊「Vue.jsとExpressでWebアプリをテスト駆動開発する」にて、お待ちしております #技術書典♪https://t.co/Mpzxsmv8FJ pic.twitter.com/dmf2qk86eK

— ほしまど＠12/14[土]技書博2/2F-え05 (@hoshimado7) September 22, 2019

今回は、前回までの「ノリと勢いで出した」とは異なり、 「書き続けるには？」と考えながら辿り着いた新刊だった。 どうやったか、というと先ずは次のように取り組んでみた。

• 気になったネタがあったら、先ずはブログに書こう
• それを切り貼りしたら、技術同人誌の新刊になるんじゃないかな？

簡単でもいいから、方向性は様々でも良いから、先ず書こう、って言うスタンスで臨んでみた。 実際に、今年2019年に入ってから秋の技術書典の前までに書いた記事は以下。

• 2019/07/03, Vue.js-CLIとMochaでtestを実行する
• 2019/06/24, 初めてのVue-CLI（CDNのVue.jsからの移行をメインに）
• 2019/06/19, マークダウンとは？を数行で説明
• 2019/05/10, Re:VIEW環境をWindows10上で簡単に構築してPDFを出力するまで
• 2019/03/20, Vue.jsでjQueryの slideDown()とslideUp() 相当を行う方法
• 2019/03/17, Re:VIEWのVer2系からVer3系への移行に関する覚書き
• 2019/02/26, Paizaのチュートリアル問題をTDDしてみるメモ
• 2019/01/15, 支出を簡単にメモしたい（家計簿を楽に記録したい）

「何かあったら、とりあえず書いてみよう」で臨めた。 「技術同人誌を書こう」と思うと筆が止まるけど、「同人誌にまとめるほどじゃないが、ブログとしてはありかな」って思えれば、未だハードルは低い。 書ける範囲で書けばいい、書けた範囲で投稿すればいい。これなら続けられる。

技術同人誌の申込み日が近づいたら、書いたブログの記事を読み返して 「この辺りをもう少し追記したいなー」ってがあるかを探す。 見つかったらサークル参加を申し込む。見つからなかったら、その回は参加を見送る。 幸いなことに、技術書典が年２回、技書博（技術書同人誌博覧会）が年２回ほど開催される現状なら、 年に４回チャンスがある。「必ず参加する」じゃなくて「参加できるところで参加する」でOK。 そのくらい緩い方が継続できる（と思う）。　・・・落選すれば参加できないけど、その時はその時で。

「このネタで新刊を書こう」って決めたら、ブログに書いた内容を元に 目次を決める。つづいて、ブログに書いた内容とブログ書く過程でメモした内容から、 コピペして新刊を作っていく。 この「コピペで進める執筆」はあくまで「どう並び替えよう」って作業がベースで、少しだけ途中をつなげるために追加書く。 ゼロから「どう書こう？」って悩まなくてよいので、時間当たりで圧倒的進捗が出やすくて、 精神的に楽（そりゃあ、ねぇ？笑）。おすすめ♪　これなら続けられる。

それでも、締め切りギリギリになった

さくさく上手い事進んだように見えるけど、何故か締め切りはギリギリになった。 当初の予約入稿日に対して、途中で１日延期依頼した。 何処に手間取ったかと言うと、「コピペで繋げた、その間の部分」と 「（ブログでは）書ける範囲で、なのでここ少し気になるけど後回し」 した部分の追記ね。 まぁでもこれは、「無理せずに継続する方法」というよりは「動き始めた後の、日程管理の方法」かな。

「無理せず続けられる」と「締め切りがギリギリにならない」は必ずしもイコールではない、と。

まとめ

とりあえずの思い付きで始めた「ブログを書く。それを継接ぎして1冊の新刊に出来そうなら、同人誌にまとめる」 ってアプローチ方法は思ったよりも功を奏したように思う。 ポイントは次の３つかな。

• 気になったネタを、書ける範囲で、ブログに書く。この時点ではジャンルや内容を問わない
• 即売会への参加は、「このブログの記事にもう少し追加したいな」があれば申し込む。無ければ見送る
• 技術系同人誌は「書く」のではなく、「ブログ記事をコピペして並べる」と捉えて、書き進める

結果論だけど、目標１「新刊を出す」と、ソコに届かくとも達成感のある目標２「ブログ記事を書く」、とを定められたのも良かったかもしれない。

なお、今年にやってみたアプローチ方法は次のことが前提。

• 定期的にブログを書く時間と場所を確保できる（もくもく執筆会へ参加等を含む）
• 技術同人誌即売会に定期的に参加できる（開催されて、且つ当選すること）。

どちらかの前提が崩れると、また新しいアプローチ方法を探さなきゃいけない。 しばらくは、崩れないといいなぁ。