10. その他おまけ

10.1. Google Colab との連携

Google Colaboratory (Colab) は，Google が提供している Python のノートブック環境で， Jupyter のファイルフォーマットと互換性があります． この環境を駆使すれば，IED などにログインすることなしに Python の実験環境を 手に入れることができます．

まずは Google Drive を手に入れましょう．といってもUECクラウドアカウントを持っていれば すでに容量無制限でもっているはずです．

https://drive.google.com/

を叩いてみてください．あとは "+新規" のボタンから Colab を選んでもらうと新規のノートブックを 立ち上げることができます．（最初だけ Colab を導入する操作が必要ですが，"+新規" のその他から Colab を選んでもらえればOKです．）

10.1.1. Colab たちあげ

Colab を立ち上げると，こんな画面になります．

これは，IED などで使う Jupyter Notebook と呼ばれているものとほぼ同じです． 一つのノートブックは，いくつかの セル から成り立ちます． 図の真ん中に見えているのが セル になります． セルには Python のコードを書いたり，markdown と呼ばれる記述言語をつかって 文を書くことができます． つまり，実験の記述などを markdown を使って説明し，別のセルにコードを使って実験し その結果が張り付くので，このノートブックをみれぜ全体で何をやっているかわかるという 優れモノです．

なお，Colab を使うとどんなことができるのかを知りたければ 下記のリンクをたどってもらうのが一番良いかと思います．

https://colab.research.google.com/notebooks/intro.ipynb

セルを追加したければ '+コード' もしくは '+テキスト' を選んで追加します． で，コードを各場合，一つのノートブックに割り当てられるリソースは

• n1-highmem-2 instance

• Ubuntu 18.04

• 2vCPU @ 2.2GHz/13GB RAM

• (GPUなし/ TPU)40GB, (GPUあり)360GB Storage

• GPU NVIDIA Tesla T4 16GB または Tesla K80 12GB

• アイドル状態が90分続くと停止

• 連続使用は最大12時間

• Notebookサイズは最大20MB

だそうです．出展は下記ウェブから https://qiita.com/tomo_makes/items/b3c60b10f7b25a0a5935 https://qiita.com/tomo_makes/items/ec12dd61e4ced0a3dd66

それでセルに書けるのは python コードだけでなく， Linuxのコマンドが普通に使えたりします（シェルエスケープはしないといけないけど）． ということなので，セルの上で git とかが動かせるのであれば， ウェブブラウザだけで python の課題が動いたりします．

試してみましたが， C コンパイラも入っているので適当に実験は可能だったりします． Scheme に関しては Ubuntu の apt コマンドを使えば，scm インタープリタをインストールできそう． Javascript は，ブラウザだけだし，タブレットやスマホだけでもなんとかクリアできそうな勢いですね． 実際にはキーボードがないとつらいとは思いますが．．．

10.1.2. Google Drive との連携

良いことづくめのように見える Colab ですがいくつかの制限があります．

1. ノートブックのインスタンスの生存時間ルールがある（いわゆる 90分 & 12時間ルール）． うっかりWeb ブラウザを閉じたりスリープさせたりして90分経つと実行しているかどうかにかかわらず落とされる． スリープとかにさせなくても12時間たつと問答無用で実行が中断される．

2. 実行環境があるものの記録するための媒体がついていない．実行しているデータを保存したり読み込んだりといった 媒体はついていないので入力データや，計算結果をファイルとしてどうにかする工夫がいる．

上記１は Google さんの仕様で「無制限の使用は許さん」という意思の表れなので納得できますが， 2.のファイルを媒介とした入出力が困難というのは実験環境としては致命的です． 特に github と連携している環境を作ろうとしているので，どこかにリポジトリを ダウンロードしてきてそれを利用するということをしないといけません．

そこで2.をのファイル案件を解決すべく，Google Drive にリポジトリをクローンして，その上で Colab で使うことを考えましょう． いろいろ調べたのですが，ここらへんが最小手数で実験環境を整えるための手段になるかと思います．

10.1.2.1. Google Drive のマウント

すでに Google のアカウントを持っているかと思うので，実際にマウントしてみましょう． セルに

from google.colab import drive
drive.mount('/content/gdrive')

おそらくパスワードをきかれるはずです．このときに打ち込むパスワードは Google へのパスワードではなく，リンク先で生成されるパスワードなので注意してください．

上図の "Goto this URL in a browser ..." と書かれているリンク先を踏んで，認証パスコードをとってきます． で，パスコードをコピペして認証が通れば，Google ドライブがマウントされて，ファイルの読み書きができるようになるはずです．

10.1.2.2. ディレクトリの移動とコマンドの実行

上述のとおり Colab の一つ一つのセルはシェルとして動かすことができます． シェルコマンドを動かすには原則は，頭にエクスクラメーション（びっくり）マークを つけて，シェルエスケープすることでコマンド実行することができます．

ただしディレクトリの移動だけは特殊で，Jupyter Notebook の機能である % 記号を使う必要があります． 先ほど Google Drive がうまくマウントできているとして，マイドライブのしたに Colab Notebooks というフォルダが あったとしましょう．そこに移動するには

%cd /content/gdrive/My Drive/Colab Notebooks

とすることで移動ができます．なので，上記フォルダの中にあるファイルのリストを得たければ

%cd /content/gdrive/My Drive/Colab Notebooks
!ls

とやれば，OK です．一端移動させたフォルダは，それ以降のコマンドで有効になりますので，再度 フォルダを移動する必要がありません．

実際に git clone して python スクリプトを動かしているのが下図になります．

もし，fatal: could not read Username for 'https://github.com': No such device or address という エラーが出るようであれば，

%cd /content/gdrive/My Drive/ColabNotebooks
!git clone https://ユーザー名:パスワード@github.com/ShounoClassML/なんたら.git

のように github のユーザー名とパスワードを指定してみてください．ユーザー名やパスワードにURLに使っちゃいけない 文字が含まれる場合(RFC2936参照)は，変換を忘れないようにしてください． 例えば僕のユーザー名は shouno@uec.ac.jp ですが，この場合は @ がダメな文字なので

https://tech-unlimited.com/urlencode.html

あたりで変換すると shouno%40uec.ac.jp のようになります．

10.1.2.3. git clone して作業開始するまで

フォルダ移動とコマンドの実行の仕方がわかったので，あとは単純に git コマンドを使って

1. github からクローンを取得して

2. Colab つかって適宜ノートブックなどを編集して

3. git add, git commit で，適宜作業記録を残して

4. git push で github へ戻す

ということをやればよいはずです．ということで実行コードまとめると

%cd /content/gdrive/My Drive/Colab Notebooks

# git の設定 (commit に必要，名前とメールアドレスは適宜変更してください
!git config --global user.name "Hayaru SHOUNO"
!git config --global user.email "shouno@uec.ac.jp"

!git clone https://github/クローンしたいリポジトリ

%cd クローンしたリポジトリ

# ごにょごにょ作業

!git commit -m 'こみっとめっせーじ'
!git push # 新規ブランチを登録する場合は git push -u ブランチ名 origin かな

とかいう流れになります．

10.2. Git & Github の標準的な使い方

この演習では特にバックアップに課題と提出に重点を置いていますが，普通のプロジェクトでの使い方は 下記のような流れで使うのが一般的だと思います．

10.2.1. Git を用いた標準的なファイル管理(Workflow)

Git は特定のディレクトリ以下のファイル群を管理しますが，これは プロジェクト と呼ばれます． ただ，あくまで実態は，開発プロジェクトを行っているフォルダやディレクトリだと思ってもらえれば良いです． Git にファイル管理を委ねると，各バージョンの変更などを全て保持したデータベースを作成します． Gitではこのデータベースを含めたプロジェクト全体のことを リポジトリ (Repository)と呼びます． リポジトリという言葉は多用されますが，開発を行っているフォルダ/ディレクトリのことだと思ってもらってOKです． 一般に Git におけるバージョン管理のフローは以下の様な形をとります。

1. 下準備:

   とりあえず git で管理するフォルダを作成しましょう．

   • 現在の作業フォルダを git の管理に委ねる (git init)

   • もしくは，どこか(Github とか)から， git に管理されたリポジトリを クローン（コピー）( git clone )してきます．

   この操作により .git という作業フォルダができてきます． この .git フォルダには，差分情報とかが入ってきます． git さんの管理から外す場合は，このフォルダを中身ごと消せば良いですが， 差分情報なども全てキレイに消え去ります．

   このあとに，場合によっては，元の開発プロジェクトを，そのままにしておいて 新たにプロジェクトを派生させるために，ブランチと呼ばれる派生操作を する場合があります．

2. プロジェクト開始．

   普通にファイルを編集します．(プログラムを書くとか，文書ファイルを更新するとか) クローンしてきた場合はそれをベースに変更を行います．

   いつでももとに戻せるのでガンガン変更しちゃって構いません．

3. ステージング．

   とりあえず，変更したら git に更新をお願いしましょう． git は便利ですが， 自動的に監視して更新してはくれません．

   git の更新は，2段階構造になっています． 最初の段階はステージングとかインデクシング(git add)と呼ばれる作業で， 今回行った更新作業が，どのファイルたちに該当するか を指定します． git add することで，git さんに どのファイルたち を登録してくれとお願いすることが できます．ただし，この段階では，変更ファイルリストが作られるだけで変更詳細は記録されてはいません．

4. コミット．

   次の段階は，ステージングされたファイルの変更を記録します．この作業は コミット (git commit) などと呼ばれます． git commit を行うを行うことで，実際の差分が記録されます． このとき， 何のために変更を行ったのか というメッセージを記録します． git さんは "いつ"，"だれが"，"どこを" 変更したかは記録できますが， "なぜ" に関しては知ることができません． この理由をコミットメッセージとして書いていきましょう．

   通常は，この 2. と 3. のプロセスを繰り返して更新作業を行っていきます． コミットは，どのような段階で行ってもよく，中途半端な状態でも， 作業の中断や，一日の終わり とかの状況での保持したほうが良いです．

5. 必要ならばリポジトリをリモートサーバにアップロードする(git push) 自分の変更をリモートサーバーに上げることによって， 各受講者の PC が壊れても良い状態(良くは無いですが最悪の自体は防げます)です． コードや解きかけの課題本体は Github においてあるのですから．

   また，作業場を変えても，ネット環境さえあれば，Github からのクローン操作を行ない 更新されたものをクローンしてしまえば，問題なく作業を続行できます．

   また，すでに存在している git の管理フォルダで作業を再開するときは， 最初に git pull を行うことで，更新作業を行えば常に最新版での 作業を行うことが可能です．

というのが基本的なフローになります．追記する場合もその繰り返しです。

10.2.2. 例題

それでは，練習のために，実際に git を使ってみましょう． Hoge というプロジェクトを開始してみます．

10.2.2.1. 自分でプロジェクトをゼロから構築する場合

0. 下準備とプロジェクトの開始 git init

   最初に適当なフォルダ下にプロジェクトの管理単位となるフォルダをつくり移動します． その後，ディレクトリを git init で git さんの管理下におきます

   $ cd `適当なフォルダ名`
   $ mkdir ProjectHoge
   $ cd ProjectHoge
   $ git init
   

   このコマンドを実行すると .git/ というフォルダができるはずです． ls -la で確認して見てください．

   この .git/ 以下にファイルの変更の情報などが書き込まれます． このディレクトリ以下の情報を直接変更することは基本的にありません． むしろリポジトリ構成を壊すことになるので触らないようにしましょう．

   git リポジトリの作成手順は以上です． もし git さんによる管理をやめる場合には .git/ ディレクトリを削除するだけでOKです．

   端末上での作業をみてみると，こんな感じになります．

   

   注釈

   上記の作業は Linux の端末作業なので，ls コマンドを用いてファイルを見ていますので 使っている端末が Windows の場合は異なる確認コマンドが必要になるケースがあります．

1. ファイル編集，作成，テスト

   さて、リポジトリを作ったら何でもいいのでファイルを追加してみましょう． まずは，ファイルの編集作業からです． ソースコードでもテキストでも何でも構わないので， 作成した ProjectHoge/ 以下にファイルを作成します． ここでは練習がてらエディタなどで hoge.py を作って何か変更を加えてみます． 内容は

   print("Hello World.")
   

   で構いません． エディタを立ち上げるのが面倒であれば cat コマンドでもOKです．

   $ cat > hoge.py
   print("Hello World.")
   

   とか打って Ctrl-D などで抜けて編集作業終了でもファイルができます．

2. 更新ファイルのステージング git add

   ある程度書いたり，動いたり，疲れて中断したいと思ったら，変更を git add でステージングします．

   まずは現状確認からです．現状確認には git status を使います．

   $ git status
   

   とすると， " hoge.py なんてファイルが管理フォルダの下にあるけど，登録されてへんぞ" と怒られます．

   

   そこで， hoge.py を登録ステージに上げるために git add を使います．

   $ git add hoge.py
   

   これで 変更を加えた時点での hoge.py が gitの管理下に入りステージングされます．

   

   更新したファイルがありすぎてファイル名の指定が面倒であれば，カレントディレクトリ以下の全ての ファイルを管理下に入れるように

   $ git add .
   

   を実行してもOKです．

3. 変更の記録 git commit

   git status で状態を確認すると，ファイルはステージングされたけど，まだ記録されていないよ というメッセージがでてきます．

   そこで，どういったこと内容で更新させたか等のコメントを付与して，記録保存 git commit します．

   -m オプションをつけてコマンドラインでコメントを付与します．

   $ git commit -m '今日は疲れたからおしまい'
   

   このように， -m オプションのあとにコメントをクォートでくくって追加します． このコメント部分が，何を目的にしたか，どういう状況での更新だったのかを示す情報になります．

   なお，

   $ git commit
   

   このようにオプションなしに git commit するとエディタが立ち上がり，コメント入れるように促されます． エディタの指定は vi, emacs や，Visual Code Studio, Atom, などいろいろなものが使えます． 下記は，Linux のデフォルトエディタの nano の画面です．

   

   最初の１行目がコミットメッセージの記録場所になりますので，１行以内で適宜記録してください． ここでは "最初の変更記録" をコミットメッセージにしています． このメッセージを記録しないと コミットはできない 仕組みなので必ずなにか埋め込んでください．

   ただこの実験では簡潔さを重視して，コマンドラインで完結する -m オプションを使っていきます．

   コミット後， git status で，状態確認すると最新の状態に保たれている ことがわかります．

   注釈

   なぜ，git の保存がこんな面倒な２段階の仕組みになっているか？というと，これを作った人の 哲学が表れていると思ってます．

   • 変更には何らかの意味があるはずなのでそれはメッセージとして残すべき．

   • また変更記録の１回分は一つのメッセージのみを含むべき．

   たぶんこんな感じ（Linus に聞いたわけではないけど...）

   いろいろ開発をやっていると，さまざまな（複数の）仕様要求によって ファイル変更をすることになります．で，その仕様要求変更を１回の記録で行おうとすると， 後で困ることが多いです．

   何故かといえば，一回分のコミットで複数目的を記録してしまうと， その中のどれかの更新をなかったことにして一部分だけもとに戻したいと思っても， その更新部分だけを抽出することが難しくなるからです．

   ですから コミットは，なるべく細かい粒度で行ったほうがよいという話になります． （特に複数人で一つのプロジェクトを取り扱う場合は．）

   このように考えると，git が git add と git commit に2段階で登録する意味は， git add で，ある目的の更新作業を行ったファイルをピックアップし， git commit で それを登録するという構えになっていることにあるように思えます． git add で，登録し忘れたりすることを確認しながら作業できるような仕様は， 複数ファイルを開いて同時更新するプログラマ向けのものと言えるでしょう．

4. 追加でファイルの修正をしてみる

   さらにファイルの修正をしてみます．エディタ等でファイルに追加を行います． たとえば２行目に付け足して

   print("Hello World.")
   print("My name is hoge.py")
   

   といったファイルにしてみます．

   この状態で git status をとると，変更が加えられているよというメッセージが 出てきます．変更を記録していくなら git add を，変更を破棄するなら git checkout -- hoge.py をしてくださいというメッセージがでてきます．

   

   さらに追加する場合は， git add と git commit を行っていってください． 更新登録は自動的に行われないので，毎回行う必要があることに留意してください．

5. リモートサーバへの登録 git push

   これは，Github の説明 Github へのアップロード のところでやります．

10.2.3. Github の基本的な使い方

Git だけでは開発履歴が特定の計算機に保持されるだけで，他の人と共有が面倒だったり， バックアップとしてはやや弱いので，クラウド上に保存しておいて

• 他の開発者と共有したり

• バックアップとして保存したり

ということは自然に出てくる話になります．これを大々的にやっているのが Github です． 様々なプロジェクトが保持されています． 最近ではエンジニアが自分のプログラムを作品としておいておいて，評価に使ってもらうてきな 使われ方もします．

10.2.3.1. 既存のローカルリポジトリを Github に登録する場合

それでは，手元の計算機で作業している Git のリポジトリをローカルリポジトリと定義しておきます． また，バックアップとして保存を行いたい Github 上のリポジトリをリモートリポジトリとします．

の "Start a Project" を選んでみてください．リモートリポジトリの作成画面に遷移します． ここでは， HelloPython という名前のプロジェクトとしましょう．

名前をいれたら， "Create repository" ボタンを押します．

しばらく待つと下記のような画面に遷移します． ここでは https 通信を使うので，画面中の https ボタンを押しておきます．（ssh 通信を使いたい場合はおまけを参照のこと

すると，ローカルリポジトリと Github 上のリモートリポジトリとをどのように紐付ければよいかが出ていることがわかります．

• "... or create new repository on the command line"

これは新しくローカルリポジトリを始めるやり方です．下記，1.〜3. でローカルリポジトリを作成し，それを 4., 5. の手続きで紐付けてアップロードするというやり方になります．

1. README.md と呼ばれるファイルを(エディタなどで)作成します（しなくてもできますが）．

2. git init でフォルダをリポジトリ登録し，

3. git add , git commit を行い，作業している計算機のローカルリポジトリを更新します．

4. 最後の2行は，作業しているローカルリポジトリと GitHub 上のリポジトリ（リモート先）を紐付ける作業(git remote)と

5. GitHub へのアップロード作業 git push を行っています．

• "... or push an exisiting repository from the command line"

  このやり方は既存のローカルリポジトリをリモート側に登録するやり方です． すでに git commit 作業が行われていることが前提になります．

  1. 紐付け作業の git remote と，

  2. アップロード作業の git push が記載されています．

前述の Git の項では， git commit まで行っているので， 後者の作業がメインとなります． ただし Github では REAME.md を作成しておくのがお作法なので， このファイルを追加した上で， git add, git commit (ここまでがローカルリポジトリでの git 登録作業) し， Github への紐付け git remote と，アップロード git push を 行ってみます．

ターミナルへ戻って， ProjectHoge フォルダへ移動してください．

$ cd ProjectHoge
$ echo "# HelloPython" >> README.md

で， README.md を作成します．

ここで， git status をとると REAME.md が追跡されていないファイルとなりますので，

$ git add README.md
$ git commit -m 'Add README.md'

をして，ローカルリポジトリでの登録作業を行います． git commit の "-m" オプションは，コミットメッセージをコマンドラインから与える方法です．

こんな感じになります．

次に git remote で，ローカルリポジトリを リモート側の HelloPython プロジェクトに紐付けます．

$ git remote add origin https://github.com/Githubユーザー名/HelloPython.git
$ git push -u origin master

Githubユーザー名 の部分は，github のアカウント名が入ります． なお，この最初の紐付け作業が終わってしまえば，どこに紐付いているかは git さんの管理化に置かれるので，

$ git push

だけで，バックアップはできるようになります．

警告

2021/8/13 に github のパスワード認証が廃止されました．．． これに伴い，毎回パーソナルトークンなるパスワード代わりのものを要求されるようになりました． https://docs.github.com/ja/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token

面倒なのですが，このパスワードを ~/.netrc などにおいて，アクセスできるようにします． https://qiita.com/mashi0923/items/861b4b45a271a2862805 21世紀の人らしく キーチェーンツールに覚え込ませるのもありです． ここは，授業で説明します．忘れていたら指摘してください．

うまく通信が行えれば，こんな感じになります．

最後に GitHub リポジトリの web ページをリロードすると，このような感じになります．

これで，リポジトリがアップロードされ，バックアップ完了です．

このリポジトリは，紐付けは済んでいるので，あとはファイル変更， git add, git commit, git push のループを回していけばOKです．

10.3. おまけ: 実験環境の自前構築

自宅などで実験する場合，実験環境を自前で構築したくなります．あとカスタマイズに傾倒する人も 大学の環境だと満足できないかも

10.3.1. Git の導入

10.3.1.1. Windows の場合

Windows の場合は，Git for Windows https://gitforwindows.org/ を使いましょう． ダウンロードしてインストールを標準で行います．

ここらへんが参考になるかと↓ https://qiita.com/elu_jaune/items/280b4773a3a66c7956fe

注釈

また，Windows などで，Git GUI を使ってなんとかしたいんだけど， 日本語コードが化けるような場合は，

$ git config --global gui.encoding utf-8

などで回避してください．

10.3.1.2. MacOSX の場合

git さんはデフォルトで入っていますが，少々古い場合もあるので， Homebrew などを利用して入れてしまいましょう．

homebrew https://brew.sh/index_ja

を入れて

$ brew install git

で導入してしまいましょう．

10.3.1.3. Linux さんの場合

普通は標準で入ってきますので特に何もしなくてもOKです