sidebarmuo-notesソフトとハードの隙間で生きたいエンジニアの関心記PagesホームGitHubTwitterFPGAマガジンNo.12の誤記/誤植一覧2016年3月31日木曜日FPGAマガジンは毎号技術的にエッジーな記事が多く勉強になる、本当にありがたい存在です。誤植が割とコンスタントに多いです。技術専門誌としての本分は「他で得難い情報」にあるので、限られた執筆・編集時間をそちらへ割くのは当然なのですが、利用者の裾野を広げる意味ではちょっと悲しいです。No.12もけっこう誤植多いな...と思いつつ読んでいたのですが、毎回「誤植多いぽよ~~」と言っているだけでも改善しない気がします。著者の方々に誤植一覧が届けば次以降の原稿で気をつけるヒントになるかもしれない、という期待も持ちつつ精読して洗い出しました。多くは細かな表記上のミスや写植上のミスです。脳内で補正しながら読めば良いので大した問題ではなく、放っておいても良いようにも感じられます。自分の慣れているエリアの文章は脳内での読み替えが効きます。バイナリトランスレーション大変でしょ。私の場合、記事の序盤で複数のミスを見つけると不安になってじっくり読むフェーズに入り、1/5ぐらいのスピードでしか読めなくなってしまいます。私は、初心者向けの技術記事では写経可能性もかなり大事だと思っています。ここでは特に間違いを減らしたいものです。写経で経典が間違ってるとかそもそもやばいし、当該環境に慣れていないと自力で誤りを見つけて乗り越えるのが難しいから。近年は雑誌でキーワードを拾い、その後にネットで調べて深めるフローも多用されます。キーワードが間違っていたら先を調べていくのも一苦労します(Googleのキーワード補正に期待することもできますが、著者側がこれをいうと開き直りにしかなりません)。いうわけで、この一覧が誰かの学習の役に立てば幸いです。Treeのドキュメント(http://www.devicetree.org/Device_Tree_Compiler)で確認しました。Sysfsp.80のリスト3キャプション部分表記に揃え。フルスピード」がヘッダとして網掛けになっているのはおかしい仕様表記なので最上段はヘッダ無しでも成立する。IPこれはどちらの表記でも良いのかもしれない。usbCdcROM.vではないか。EEPROMの接続例ですEEPROMもEPROMのうちなので"EPROM表記でも"間違ってはいなさそう。Basys3ボードにここまで一貫してBasys3と表記しているので、ここも揃えるべき。p.50こういう、日本語として(???)な記述はすべて無視しました。技術用語が間違っていたり、明らかに意味が通らないものだけを書きました。Coreのdotnetコマンドを試そうとしたら試せなかったの通りハングアップしました。issueを立てて置いていたのですが、その後の話を書きます*1。少々タイトルの範囲が大きいですね。Core公式イメージ実行時に発生した問題ですが、もっと一般的な問題だとわかったのでこうしました。Fusionベース)でも、手持ちのDebianサーバ上に作ったDocker環境でも同じように発生しました。#26というissueを立てましたよという話で終えていました。その後issueを立てた時点で一番疑っていたのはDocker自体です。ホストとのコミュニケーションを多用するメモリ管理かI/Oのどこかでミスっているのだろうという読みでした。その後の手元テストにより、この問題はBoot2Docker(b2d)を新しいバージョン(1.10系)へ上げると発生しなくなることがわかっていました。このためひとまずb2d環境でdotnetコマンド群のテストをおこなっておけば良いか、と考えていました。#18180関連の問題では?というコメントをもらいました。本当の原因(Dockerコミュニティの阿鼻叫喚)このissueは私が見た時点でクローズ済みでしたが、なかなか壮絶で壮大な戦闘録が残っていました。結論をまとめると、これはLinuxカーネル内のmm/filemap.cに対する改善(sendfileシステムコールを利用したデータの書き込み処理で、停止シグナルを受けて途中終了できるようにしたもの)と、Dockerが利用するレイヤードファイルシステムのひとつであるAUFSのデータ書き込み部分の一部に従来のカーネル実装へ依存するコードが存在したことで発生した問題でした。2016年2月末時点で主要ディストリビューションでの対応は終わっており、OSアップデートにより解消します。この問題の解決までを時系列でざっと見てみます。事態は12/21にAUFS内で動作停止に至る具体的な箇所が特定されたのをきっかけに再び動き始めワークアラウンド版の実装、カーネルバージョンを下げる緊急回避策の確立、AUFSの新版を取り込んだカーネルビルド策での対応を経てb2dを含む各ディストリで徐々に新版AUFSの取り込み作業がおこなわれDebianが2/29に3.16.7-ckt20-1+deb8u4を出したことで主要ディストリでの問題対応が収束3ヶ月に及ぶ、長く苦しい戦いだったようです。https://github.com/docker/docker/issues/18180#issuecomment-161843456にてAUFSとmm/filemap.cへの変更によるものだと突き止めているのすごいなと思いました(小並感)。この問題へ取り組み、さっそうとトラブルシュートしつつ更に広い視点からの解決策を模索してAUFSへ潜って本家とやりとりをし、更に主要ディストリ(Ubuntu、Debian)へfix取り込みの働きかけをおこない、それらの状況をトラッキングしissueへ追記していくAkihiroSuda氏まじぱねぇという感想でした。手練というか、なんかNINJA感がありました。いうわけで、私が試した環境2つがたまたま該当してDocker本体の問題と思い込んだのが敗因(?)でしたね。その後、dotnetコマンドは普通にうごきました。立てたissueも先ほどcloseされました。2016年5月号に寄稿しました。2016年5月号(3/24発売。~そのとき、PC上では何が起こっているのか?~」という特集記事を寄稿しました。UWP)の登場背景と基本構造という話を広く書きました*1。Nativeの話なども挟まっていますが、いずれも概要のみです。言語はなぜ動く」というものがあります。これは、Windowsプログラムを含めて様々な言語(JSなど)で書いたプログラムが実際に実行されるまでの流れを解説した、なかなかクールなものでした(私が書いたものではありません)。この流れを一定汲みつつ、よりWindows上そして主にC#で書かれたプログラムへと振ったのが今回の特集です。各分野を専門的にやっている人からするとイントロぐらいの話です。読めて、初心者の方でもなんとなく分かる(そして、更に興味を持って書籍やネットで調べたくなる)というのを狙いにしました。読んでみて「これざっくり把握するのに良いから読んでみて」と後輩へ渡すようなシーンが生まれると最高に嬉しいです。muo.jp宛に指摘を頂けると幸いです。なくなっていましたが、実は一番書きたかったのがこれです。Frameworkの内部やWindowsの内部処理に関する紹介をおこないました。これらのトピックについては、次に挙げる書籍が大変参考になります。なかには入手しにくい本も存在しますが、興味が湧いたらぜひ読んでみてください。Frameworkの構造やCILからネイティブコードへの変換などについて今回の特集では扱いませんでしたが、SOSを利用してJITコンパイル後のx86コードを追いかけるくだりはシビれます。10世代では多少事情が異なるポイントもありますが、原則の部分はほとんど通用します残念ながら絶版本なので、古本在庫が尽きたら異常に値段が上がりそうです。早めに買うことをおすすめしますクラスライブラリのソースコードに迫ってみる内容の割に長かったためかボツになったのがこれです。FrameworkではCLRとクラスライブラリの組み合わせによって実行環境で要求される機能を実現しています。これらの中身にもっと迫ってみることはできないのでしょうか。Frameworkのソースコードを一部MITライセンスという非常に制限の少ない(利用者側の自由度が高い)ライセンスで一般公開しました。この中をたどっていくことで、CLRの実装詳細やクラスライブラリの中身を追いかけることができます。Frameworkが提供する機能のソースコードを追いかける例を紹介します。C#でプログラムを書いていて、プログラムの状態をデバッグ出力することがしばしばあります。Cプログラミングでいうところのprintfデバッグの類です。多く利用される方法はSystem.Diagnosticsパッケージに含まれるDebug.WriteLineメソッドの利用です。この部分はオープンソースで公開されているので、コードを完全に追いかけることができます。試しに追いかけてみましょう。以下の説明でのソースコードはMicrosoft社がMITライセンスにてGitHubで公開しているreferencesourceの抜粋です*2。me!");というコードを書いた場合のクラスライブラリ側コードを追いかけてみます。Debug.WriteLineメソッドはSystem/compmod/system/diagnostics/ディレクトリ以下のDebug.csを起点として呼び出されます。TraceInternalクラスは同ディレクトリにあるTraceInternal.csで定義されています。その中で、呼びだされているWriteLineメソッドは次のとおりです。}ここではロックの取得方法によって処理が2パターンありますが、いずれもListenersからTraceListenerを取り出してそれぞれに対する出力処理をしていることがわかります。同じファイル内を読むと、Listenersはプロパティとして宣言されており、このプロパティを最初に取得するタイミングでデフォルトの内容が作成されることがわかります。ここで実際に生成されるのはDefaultTraceListenerのインスタンスです。DefaultTraceListenerのコードはDefaultTraceListener.csにあります。WriteLineメソッドの中でWriteメソッドを呼び、その中でinternalWriteメソッドを呼び出しています。internalWriteメソッドの記述は次のとおりです。}デバッガでのログ出力が有効であればメッセージをデバッガへ流し、そうでなければSafeNativeMethodsOutputDebugStringメソッドを呼び出しています。この実体はSystem/compmod/microsoft/win32/SafeNativeMethods.csファイルの次の部分です。message);ここでWindows用のDLLへのバインドをおこなう処理が登場しました。APIのリファレンスはhttps://msdn.microsoft.com/ja-jp/library/cc428973.aspxにあります。Frameworkのライブラリは2008年から閲覧専用のライセンスで公開されています*3。Frameworkである4.6.1のソースコードが公開されています。Frameworkでメッセージボックスを表示するプログラムについて、挙動がおかしいとします。その問題を調査したり、フレームワークとの適合度を高めるための用途であれば、ここのソースを読むことができます。コードをコピー&ペーストして利用したり再配布するような行為は禁止されている(GitHubのreferencesourceリポジトリにあるものと違って、ライセンス上の制限がかなり厳しい)ので注意が必要です。ライセンスの全文はhttps://github.com/Microsoft/referencesource/blob/master/LICENSE.txtで公開されています。特集の中では細かな事情として省くことになったのですが、Windowsの構造について話をしていくと避けて通れないのがサブシステムです。Windowsはもともと多様なアーキテクチャの実行ファイルを実行できるように設計されています。Windows向けのexeファイルは素直に実行されますが、たとえばUNIXの仕様に基づくPOSIXサブシステム(以前SFUと呼ばれていたもので、最近のWindowsではSUAと呼ばれます)を利用するものはposix.exeというプロセスがホストする形で実行し、psxdll.dllをライブラリとして利用します。WindowsなのになぜUNIX標準にもとづくプログラムを?と思うかもしれません。これには歴史的な事情があり、1980年代の米国政府が業務に利用するOSの調達要件としてPOSIX.1というUNIX標準への準拠を必須としていたためです。8の時代まで、Enterprise版のWindowsはSUAをサポートしていました。8.1ではSUAが削除されました。代わりにUNIX系の機能をWindows上で利用したい場合にはHyper-Vで仮想化されたUNIX系OSを利用したりCygwinのような仕組みを利用することを推奨するようになりました。Astoriaは、Windows上にAndroidサブシステムを実装してプログラムを実行するという構造をとっていました。これも残念ながら2016年2月にプロジェクトの終了が発表されました。このように、Windowsはシステムコンポーネント次第でさまざまな役割を果たすことができるように設計・実装されてきました(ビジネス的に成功しているかとは別に、このような拡張をおこないやすい内部アーキテクチャというのが肝要です)。補足やセルフツッコミ以下では、もう少し書きたかったけれど紙面の都合上削ることになったものや、少々蛇足で雑誌媒体には合わずカットとなったものなどを挙げていきます。原則的に紙面の各文言へセルフツッコミを入れていく形で書いてみます。テキストかバイナリか的な話でも、テキストエディターで記述したソースコードは、あくまでテキスト形式です。このままでは、コンピュータは実行できません。EICARテストファイルというものがあります(http://www.eicar.org/86-0-Intended-use.html)。これは完全にASCIIの範囲のテキストのみで書かれた、アンチウィルスソフトの動作確認用ファイルです。Modelでないほう)実行形式として正当なものであり、32-bit版のWindowsでは実行可能です(64-bit版のWindowsではCOMファイルを実行できないので、残念ながら最近の多くの環境では実行して試せないのですが)。いう変わり種もありますが、バイナリ芸のエリアですね。フレームワークのくだりWebアプリを作成できるようなライブラリ群を指します。Webアプリに用途を限定しているわけではありません。文の収まりの都合です。コンパイルして実行か逐次実行かというくだりただし、現在のスクリプト言語では、すべてを逐次実行しているわけではありません。プログラムの起動の高速化や、実行速度の改善のために様々な処理を実行前に施しています。いうわけで、JSがJITコンパイルの領域で世界の先端エリアまで行っていたり、PyPyがCPythonより(コード種にもよりますが)何倍も速くコードを実行できる現代に我々は住んでいます。Coreなどでは原則的に事前のCIL生成・アセンブリ生成を捨てて「実行時コンパイルでいいよね?」と来ているわけですし、扱い方の容易さでいうともはやほぼJSです。個人的には、事前コンパイルをおこなって中間言語コード・アセンブリを出力しておく言語群とそれ以外との切り分けは近年ほぼ意味を成さなくなってきていると思っています。runというサブコマンドがあり、実行時に一時ディレクトリでバイナリをビルドしてから実行するスタイルもとれるわけです)。フレームワークについて本文のどの場所というわけではないのですが、フレームワークというフレーズは本当に界隈と人によって持つイメージが違うものです。iOSだとずいぶん小さめの粒度でフレームワーク(framework)という言葉を使います。インポート可能なパッケージの、パッケージングフォーマットというレベルでの利用です。いわゆるシステムフレームワークはかなり大きな規模で切り分けられたものですが、ユーザが好きに作って配布できるフレームワーク(*.framework)はnpmやgemのパッケージレベルです。コラム「corflags.exe」です結局本文では使いませんでしたね。dumpbin.exeで事足りるケースも多いのです。書き換えをしたい時にはcorflags.exeを利用します。いう人も居るので、世の中面白いのです。CILディレクティブとCILオペコードのくだりCILディレクティブは、コンパイラやランタイムによるコードの最適化に利用されます。処理内容ではありません。最適化だけではなくてもちろん.entrypointとか、実行するコードパスを決定するのにも利用されます。SxSマニフェストのくだり.NETアプリのプログラムでは、後述するマニフェスト(SxSマニフェスト)もこのセクションに格納します。SxSマニフェストは.NET固有事情によるものではないのですが、確認した限りはVSからの標準ビルドで常時出力されているのでこのように記載しました。マニフェストたちややこしい話ですが、マニフェストには2種類あります。実際は、まだあります。.NETとWindows界隈、便利な言葉ゆえ「マニフェスト」というのを多用します。DLLへ処理を切り出す動機のくだりDLLが多用される理由は、ライブラリによって勝手に再配布することが許されないものがあるからです。アプリの配布サイズが増えることを許容すればバージョン差異による問題を避けられるのになんで、という話を先回りした話です。Photoshopの内部DLLとかを勝手に同梱して配布したら猛烈に怒られますからね...。DLLにコードを切り出す恩恵つまり、メモリーの節約につながるのですこれは主にシステムコンポーネントの話ですね。ユーザコンポーネントだと、Chromeのように大量のプロセスを生成するプログラムでは恩恵大きいはずですが、普通はせいぜい2-3しかプロセスを立ち上げないのでメリットそこまで大きくありません(無理に切り分けるほどでもないの意)。「ntkrnlpa.exe」ほかにもntkrnlmp.exeやntkrpamp.exeがあります。なんと、このあたりはWikipediaに分かりやすいサポート特性リストがあります(Ntoskrnl.exe)。ntkrnlmp.exeです。CILコードからWindowsのAPI呼び出しまでの話この処理は、CLRの内部でWindowsのMessageBoxWというAPIの呼び出しに変換されています。CLRの内部というのは嘘ではないですが、実際にこの変換をしているのはFX側ですね。このことはソースを参照するとわかります。この部分のコードは残念ながらGitHubのreferencesourceリポジトリには含まれないので、制限付きのほう(前述の、ソースコードを探っていくくだりを参照してください)で読むことになります。APIとは異なる新しいAPIセットが必要だったのです(図1)。導~アプリライフサイクルが大きく違うというのもありますね。なにぶんモバイルではバッテリ消費をおさえやすい構造にする必要があったのだし。タブレットでは、うん。その後にWinRT専用タブレットが消滅したのを見ると、WinRT専用へ振り切るのが早すぎたのは間違いありません。Win32APIの重要度というか、「デスクトップが今まで通りにあってOfficeがこれまで通りウィンドウ状態で動く」というあって然るべきUXを激変させるのがキツかったという話かなと。種類のWindows系OSが存在しました。種類のバイナリファイルを生成してパッケージ内に含めることになります。だいたいx64も別にするので3種類ですけれどね!MIPS増えないかなー(増えない)。Oxfordは、簡単にいうと「Microsoft(Research)のすごい研究成果をAPIで提供するもの」です。Vision、画像認識)や音声認識など、多彩なAPIを提供しています。Oxfordのエントリで簡単に紹介したので、よければ参照してください。実はこのエントリとタイミングが被っていたのですが、2015/12/15に音声認識APIが強化されていました。Galgon氏によるもの)のメモです。APIs)の話へ行きます。話者の音声を記録して個人を特定するのに必要な声紋(voiceprint)を抽出します。これらは話者の口や喉の物理的な構造に由来するもので、数式であらわせます。identification)」のコンポーネントにわけられます。話者検証は認証向けのシナリオで利用されるものです。話者登録と話者識別の際に特定のパスフレーズを唱えて認証するイメージです。この精度は実験上90%以上、拒否率5%*1とありました。話者特定は、入力音声の話者を複数人の候補者の中から特定するものです。これは話者検証と違って、話している文章に依存しません。※原文にはi-vector話者識別モデルの構造概要が書かれているので、興味があれば読んでみてください。rateつまり本人拒否率の意味だと解釈しました。Oxfordプロジェクトサイト上でのAPI紹介はhttps://msdn.microsoft.com/en-us/library/mt612813.aspxにあります。APIリファレンスはhttps://dev.projectoxford.ai/docs/services/563309b6778daf02acc0a508/operations/5645c3271984551c84ec6797ですね。verification)APIでは確度情報をHigh/Middle/Lowで返してくれるので、使い方によっては便利そうです。認識対象の音声は1秒以上15秒以下という制限があるので、事前に沈黙部分をカットしておくのがよさそうです。identification)APIでは事前に登録した話者候補情報を渡すのですが、ここで渡せる最大数は今のところ10です。複数人の会話から部分ごとに話者を識別するようなことはできないのに加えて、沈黙状態を除いて60秒以上のサンプルが必要という制限が書かれています。自分で使ってみないと。使ったらまた書きます。blogから面白そうなエントリを掘り出してポイントをまとめるシリーズのものです。blogメモ)2016年3月22日火曜日Azureでササッと立ち上げられるVMとしてデータサイエンス向けのものが増えていたという話です。Kumar氏によるもの)を読んだメモです。2015年の暮れに公開されていたのですが、全然気付いていませんでした。データサイエンスVM、なにそれAzureのMarketplace(公式やサードパーティのさまざまなVMイメージを探して利用できる仕組み)で作れる、Windowsベースのデータサイエンティスト向けのもろもろ入りVMイメージです。すごいもの、というわけではないのですが、環境構築の手間を減らしてくれるえらいやつです。入っているものリストは前述のblogからほぼそのまま抜粋し、コメントをそれぞれにつけていきます。Edition」と明示されていますねここまでは「え、それ普通にUbuntuベースのDockerイメージあたりでよくね?」という感じですが、ここからがWindowsベースのイメージであるうれしみを感じるところです。Editionこれは正直なところいまひとつピンと来ませんでした。SDKデータを読み込んでくるにも、加工して書き出すにも、何かと使いますからね。Community版を入れてくるのは、ライセンス的に企業内利用は微妙なところがありますね。21世紀は個人の時代だ!万歳!!(なんか違う)。実際に使う際の注意はhttps://azure.microsoft.com/en-us/documentation/articles/machine-learning-data-science-provision-vm/に事細かく書かれているので読んでスタートするのがよさそうです。Learning)のblogから面白そうなエントリを掘り出してポイントをまとめるシリーズです。5事情を調べた)と思ったら半年も経たないうち(2015年のうち)にまた変わりました。newなる環境新規作成コマンドが増えたようです。Docker環境でサクッと試・・・せないさっそく公式Dockerイメージを利用して簡単に使ってみます。microsoft/dotnet:latestしばし待って完了です。/hello.コンテナ環境内でチュートリアルに従ってnewをおこないますが、なかなか終わりません。気持ち的には一瞬で終わってほしいコマンドで、特にprogressが表示されるわけでもないので不安になります。killを試みるも反応なし。stopコマンドでホストVMごと停止して再起動しました。FusionのVMがシステム時間を食い尽くして応答しなくなる)なので、何かおかしそうです。環境情報を書いておきましょう。linux/amd64Linuxホスト上で実行してみる原因を切り分けるために適当なコンテナホスト上で作業をしてみます。対象のビルドは現時点でlatestタグの打たれているhttps://hub.docker.com/r/microsoft/dotnet/builds/btl9c2jpeyehe89ivzdvfcr/です。linux/amd64はい。/hello_world.固まりました。killでも殺せません。結果issue作りました。1.10系を使えばよさそうな雰囲気ですね。雑感せっかく関連コマンド群を1つに集約したのだから、Docker環境内へdotnetコマンドを隔離しつつホスト側環境のファイルをいじるのをデフォにしたいところですね。本来はこっちの話を書きたかったのですが、存外まともに動いていなかったので1回休みの格好です。あと、チュートリアルとしてはDockerコンテナ作成時に--rmオプションを付けて終了即削除にしておいたほうが何かと楽(Dockerをよく知らない状態だと、大量にたまってきたコンテナの残骸に気付かず厄介事になりやすい)かなと思いました。充電ケーブル交換プログラムというページが公開されました。MacBook)で採用されている電源用のUSB-Cケーブル(2m)の設計上の不具合により充電できなくなるケースがあるという問題への対応とされています。AppleCare入っててよかったなと思いますね。瀕死なのはUSB-Cケーブル側の模様。逆の端をMacBookへつなぐようにしたら起こらなくなった。2015年8月4日とぼやいていました。ケーブルの値段が高いので、本格的に使えなくなったらかなり凹んでいたところですが、修理で持ち込むのも相応に面倒だったので逆側を挿して問題なく使っていました。お送りさせていただきます。前述のページにある通り、私の手元にも早速2/17に代替品が届きました(図1)。配送はヤマトのメール便あらためクロネコDM便でした(図2)。ヤマトDM便DM便の中には、製品のパッケージが二重になっていました(図3)。梱包内のパッケージDM便の中には交換に関するお便りが入っていたのですが、「勝手に文書アップするなよ!」(意訳)という文言が含まれていたのでチキンな私は載せないことにしました。予備用に購入した追加ケーブルも(まだ確認していませんが)おそらく交換対象品なので、気が向いた時に交換手続きをしようと思います。blogを眺めていて、最近少し話題になっていたVSでのRサポートの記事を見かけました。Mortazavi氏によるもの)今回はこの記事についてざっとメモしてみます。いっても統計は専門ではないので、気の利いた突っ込みは入れられないのですが。Rが強力な統計処理言語というのは知っていて、元々はSインスパイア系だったこと、最近ではSよりもRのほうが一部界隈で支配的ということ、あたりを前提にはします。Studioから入手できます。RTVSはOSSであり、GitHubのRTVSリポジトリにて公開されています。スクリプトや関数の編集、IntelliSense、書いたコードの即時実行結果確認などの基本的~近代的な諸々の機能を持つ旨が記載されています。NDKの時の初期版を思い出し、広い心が求められそうという感覚で居ます)。パッケージマネージャのGUIやVSCでの動作サポートは将来のバージョンでおこなうとあります。MLとの親和性の良さをアピールしていて、CRANに登録されているAzureMLパッケージを入れておけばクラウド対応の分析コードをサクサク書けるとしています。MLでRを書きたくなったらきっと利用する拡張機能だろうなという感想です。ML自体の機能強化についても半年近く見ていないのでそろそろ確認しないと。Learning)のblogから面白そうなエントリを掘り出してポイントをまとめるシリーズです。MacBookを4/10に注文、4/14出荷、届いたのは4/17だったので正確にはもうすぐ2ヶ月ですが。Dockerで簡単にGPU対応のTensorFlow入りコンテナを作る方法こんにちは。作品群を読んでいたら連休が終わりそうです。重くなるので読み込まないようにすればOK。資料を補足するシリーズです。途中でやったことや、参考情報を書いていきます。