概要

• ソフトウェア入門講義
  • 数値計算をはじめとする研究用のプログラム
  • プログラムを書くための便利なツールやサービス

お品書き

• 前半: 使う側として使いこなす
• 後半: 作る側として使いこなす
  • プログラミング言語として Julia を中心に進める
  • 余裕があれば Python もやるかも

自己紹介

• SatoshiTerasaki
  • GitHub: @terasakisatoshi
• AtelierArith は個人事業主の屋号
  • 読み方: アトリエアリス，漢字だと「算術工房」かな？
  • 個人の立場で話す時に使っている
• 画像系の機械学習モデル開発・アプリケーション開発
  • C++/Python などで
• 最近は Julia を書いている
  • 数値計算ライブラリの高速化
  • 大学の研究室の開発基盤の整備

受講者へのお願い

• 適宜質問して
  • ディスカッションして
    • GitHub の Issue/Discussion を利用して
• 誤り・誤植があったらこっそり直して
  • Pull Request を送ってください
• できる人はガンガン進んでもらって構わない
• 周りに困ってる人がいたら助けてあげて
  • 参加者の専門・学年・プログラミング経験はみんな違う．
  • みんなナカマ・コワクナイヨ

ここでのソフトウェア開発について

• 計算機の上で実行するプログラム，コードを書くこと
  • 人間（手計算）では到底できないことを実現
    • 解析的に求めるのが難しい
    • 複雑な計算
    • 繰り返し行う操作
  • 計算機の上で自分の考えたアイデアを何回も実行させる
  • 再利用ができる・みんなに使ってもらうことができる
• みんなで開発をすることができる
  • ここをみんなに体験してもらいたい

皆さんを取りまく環境

• 計算機の進化
  • CPU, GPU がパワーアップ
  • AI/Deep Learning と呼ばれるのような分野を発展させている
• インターネットの進化
  • 知識の伝搬・取得が容易になってきた
  • 世界中の人とコミュニケーションが取れる
• 道具の整備
  • プログラミング言語，開発環境が快適に
• 従来困難だったことができるようになってきた．
  • できることが増えてきた

できることが増えると

できることが増える

やってみたくなる

できた！

今までできなかったことができる

できることが増える(おやおや？)

やってみたくなる(おやおや？)

できた！(なんと！)

今までできなかったことができる(素晴らしい?)

できることが増える(無限ループ)

この無限ループの繰り返し速度がものすごく速くなっている

さらに人類は欲張りなので

できることが増える（憧れは止められないんだ！）

やらなければいけないことが増える

煩雑になる

大変だ！

そうだ，楽をしよう

効率化しよう

楽にする道具が生まれる

作られた道具で楽になる

新しい人の参入障壁が減る

もっと楽にしたいぞ！

さらに人類は欲張りなので

もっと楽にしたいぞ！

そうだ，楽をしよう, 効率化しよう (おやおや？)

楽にする道具が生まれる

楽をするために作った道具を前提とする開発手法が進む

その道具を使いこなす必要がある（やな予感）

便利な道具の存在を知らないと苦労する

道具の使い方を知らないと参入できない

道具の存在が自明になり伝え手がいないコミュニティは苦労する

いろいろ便利になったけれどいろいろ大変な状況（イマココ）

こんな感じ

さらにみんなにとって大変なこと

• 今まで触れたことはソフトウェアにフォーカスした話
  • 大変なので専門職（ソフトウェアエンジニア）がある
  • さらに細分化が進んでいる
    • 機械学習エンジニア
    • データサイエンティスト
• 皆さんは物理学という分野を理解しないといけない
  • 難しい領域でのソフトウェアを書かなければいけない．
  • 数式をコードに落とし込む数値計算のスキルも必要

つまり?

下記の両立をし研究活動をする必要がある

1. 自分の専門領域を理解する（サイエンススキル）
2. 効率よく道具を使う・作る（エンジニアリングスキル）

専門領域にフォーカスしたいぞ

• 気持ちはわかる
• 効率の悪いワークフローで仕事を進めて”非効率”なまま仕事を進めている人を観測する
  • プログラムの実行速度が十分に出ない
  • 道具を十分に使いこなせてない（存在を知らない）
  • 道具の作り手・プロが意図しないワイルドな使い方をする
    • 他者が開発に参入できない
    • 他の人がマジで困る
  • 研究の進行速度がトータルで遅くなる可能性

困る例

• 自分がわかればそれでいい!
  • 本当にそうか？
  • 困った時に「他人」からのサポートを受けにくくなる
• 読みやすいコードを書ける人はわかりやすい説明を作ってくれる
  • 「他人」への気遣いができる人でもある

ここでの他人とは

他人 = 未来の自分 + “一般用語としての他人”

• 無遠慮に書いたコードは自分が書いたものでもあたかも狭義の他人が書いたものにしか見えなくなる
• 他人に思いやりのある開発をするべきです

困る例

• 割り切りも大事だが乱暴な使い方は控えてほしい
  • 共同開発において何も考えずに git push origin main -f みたいなのをされるのも困る
  • 巨大なデータをコミットされても困る
• 構造化をしない
  • main にベタ書き
  • パラメータのハードコーディング
  • p = 1.429967 # なんだこれは？

プログラミングは誰でもできる？

• 任意の人が物理学をあなた程度理解できると思い込んでいるぐらい愚か
  • 仮に真の場合，あなたの知識・専門性にどれだけの価値があるのか？
• 誰でも書けるかというとそうではない
  • 私が「物理なんて簡単www誰でもできるでしょ？」っていうと皆さん内心どこかで怒るでしょ？それと一緒

プログラミングは誰でもできる？

• わからないことを解決できる身近な人（先輩や指導教官，メンター）の存在がキーになってくる
  • 環境は大事
• 努力は必要
  • 「ちょっと考えたらできる」を具体的に「ちゃんとできることを示す」まで行う細部を埋める労力は非自明
  • エラーメッセージと向き合って解決する気力
  • 諦めない根気づよさ，知的な体力
• 計算機の知識，計算機を触る道具を正しく使いこなすのが大事
  • ただそれはそれで難しい

不寛容な態度は自分の首を絞める

• 他の分野に無関心な態度は他者から見たあなたの分野・研究にたいするそれとして返ってくる
• 他の分野に対するリスペクトを持ちましょう
  • それができるだけでもだいぶ社会で生きやすくなる

そうはいうけれどめんどい

• エンジニアリングなんて泥臭い，嫌い
  • 言いたいことはわかる
  • 口だけで手を動かさない人は嫌われる
• 面倒なことはカネで解決できる
  • 金をもらえれなやる人はいる

どうすればいいか？

• 出世をする
• 石油王になる
• または自分が努力する(現実解)

将来の皆様へ

• お仕事お待ちしております

石油王になった将来の皆様

• GitHub だとスポンサー機能があり，開発者を支援することができる．
• 例えば julialang に $1,000 a month をするとスーパーヒーローになれます．

怠けたい．便利な道具の上に乗りたいぞ！

• 楽をする，効率化しようとする気持ちは大事ではある
  • 楽をしたいから便利な道具が増えていく
• 計算物理の文脈だと高級なレイヤーに乗っかって仕事（研究）をすることになる．
  • 大量の便利な道具の積み重ね・ノウハウの蓄積のもとで仕事をする
  • 多くの人が便利と感じる道具には多くのリソースが割かれている
  • 道具の作成に携わった人に対する感謝を忘れてはいけない

コミュニティ内での人材育成

• 物理屋さんにとって真に便利なものは物理屋さんの中からしか生まれない
  • 道具を作れる人は各々のコミュニティ（分野）で必須
    • そういった人材を育成しないといけない
• 専門知識がある人がソフトウェア・道具作りにコントリビューションしなければいけない
  • 門外漢の人にでも気軽に参入できる仕組みが必要
• 私みたいな人よりも物理に詳しく，民間の人並みにコードがバリバリ書ける教育的な人が皆さんの中から生まれてほしいと思っています

コミュニティ内での人材育成に必要なこと

• 道具作り，コントリビューションを体験してみよう！
• 既存のソフトウェアを動かしてみる
• 改善案を提示する訓練の場
  • あなたの能力・時間が道具の改善の余地を与えるならば積極的にそれらの発展を促すべきである

ということでやってみよう

• みんなで作るご飯データベース
• GitHub で公開されているリポジトリに対してプルリクエストを送る

お題（WordCloud）

こんな感じのことができるやつ

• せっかくなので沖縄関連のものがいいなぁ
  • OkinawaCompPhysfoodurvey2024.jl
• 物理とは程遠いけれど多くの概念を習得できるはず．

何をすればいいのか？

• わかる人向け
  • フォークして，プルリク送って．詳しくは README.md を読んで

以上

何をすればいいのか？

• もう少し詳しく
  • リポジトリをフォーク
  • README.md にある説明を読む
  • poll/<your-gh-name>/food/Data.toml を作成・編集
  • プルリクエストを送る

な，何をすればいいのか？

• リポジトリをフォーク
• フォークしたリモートリポジトリをローカル環境にクローン
• README.md を読む
• git switch -c <your-gh-name>/okinawa-food
• git add poll/<your-gh-name>/food/Data.toml
• git commit -m "add Data.toml"
• git push origin <your-gh-name>/okinawa-food
• プルリクエストを送る

キューン(´；ω；｀) ???

• アザラシ状態（困った状態）になった場合
  • もう少し詳しく説明しますね（次のページ）
• GitHub Docs の About version control and Git なども参考にどうぞ

Git

• 皆さんが今後目にするであろう多くのソフトウェアは何かしらのバージョン管理システムでソースコードを管理している．
  • 例えば Git
• 次のような情報を管理している
  • どのような変更をしたか
  • いつ行ったか
  • 誰が
  • なぜ（コミットメッセージ）

リポジトリ

• ソースコード，変更履歴を含めたもの
• About repositories を参考
• Git の場合，リポジトリをローカル環境（手元）にダウンロードして履歴の調査・コードの変更（追加・修正）を行うことができる．(ローカルリポジトリ)
• git push でローカルリポジトリからリモートリポジトリ（リモート環境にあるリポジトリ）に変更を加えることができる．
• ローカル環境で行った各自の修正結果はリモートリポジトリに取り込まれる

GitHub

• リモートリポジトリを管理する必要がある．
• リモートリポジトリをホスティングするプラットフォームとして GitHub がある
  • 他にも GitLab や Bitbucket などがある
  • どれがいいかは要件次第

GitHub のサービス

• Issue
  • 開発の TODO を管理
  • バグレポート
• Pull Request
  • 変更を取り込む際に使う
• GitHub Actions
  • 自動テストをはじめとする様々な作業を自動化してくれる
• その他 Discussion, Wiki, Project などがある

GitHub Actions の例

• このスライドは lecture.qmd というテキストファイルから生成されています
• lecture.qmd をソースコードとして管理
• git commit で変更を記録
• git push で GitHub で管理しているリポジトリを更新
• git push によるトリガーからスライド生成をするコマンドを実行
• 皆さんは特定の URL から入手
• Quarto 便利ですねぇ（独り言）

履歴・コミット・ブランチ

• 変更はコミットという単位でおこなわれる
  • 朝起きる
  • 歯を磨いて
  • 着替えて
  • 荷物を持って
  • ホテルにPCを忘れたので回収
  • 朝ごはんを食べる
  • 春の学校出席
• 変更の系列をブランチと呼んでいる

履歴・コミット・ブランチ

• 変更はコミットという単位でおこなわれる

• 変更の系列をブランチと呼んでいる

研究室の整備に例えると

ソフトウェア開発は研究室の整備に似てるかも

• main ブランチは研究室本体
• 各ブランチは各々のやりたいことを進める
  • 部屋がある
  • A さんは支給済みの机の上にコーヒマシンを配置する
  • B さんは本棚を整理する
  • C さんはリラックスするためのソファーをこっそり持ってきた
• main にマージは実際に行動にうつすことに対応

main には直接コミットをしない

• main ブランチに直接コミットするとトラブルの元
  • A さんは机とコーヒマシンを配置するはずの場所に
  • C さんは机を捨ててリラックスするためのソファーを配置
  • ソファーを配置した近くに本棚があって B さんが作業できない
• 困る
• 交通整理が必要
  • ブランチというパラレルワールドを作って各々が作業をする
  • main にマージして研究室を整える

ブランチによる交通整理

研究室のバージョン管理の効果

• 誰がいつ何をどのような理由で研究室を整えたかがわかる
  • A: なんかすごい立派なソファーがあるんだけれど？
  • B: え？ C さんがやったの？
• そしてものすごい勢いで人が入ってくる

研究室のバージョン管理の効果

• このソファーを持ち込んだやつ誰だ!来客用のやつだぞ!
  • お前か!C!!!元に戻せ
• C: はわわ……

revert によって過去の変更を打ち消す

実践的なブランチの利用法

新しいアイデアを試すための試し書き

ハンズオン

ここの手順書を参考にします

WordCloud.jl

wordcloud

OkinawaCompPhysFoodSurvey2024.jl をみんなで育てよう

Fork

• 皆さんには書き込み権限がない
• 変更を加えたいリポジトリをコピーする（これがフォークすること）

各自がすること

ここの手順書を参考にします - フォークしたリポジトリは編集ができる - クローン - ブランチを作る - 次のページへ

Julia をインストールされた方は

git clone ...
cd ...
julia --project interactive.jl
git switch -c "<your-gh-name>/okinawa-food"
cat poll/<your-gh-name>/food/Data.toml

素朴に編集をする場合

mkdir -p poll/<your-gh-name>/food
poll/<your-gh-name>/food/Data.toml

items=["ヤギの刺身"]

ブランチ作成・コミット・プッシュ

$ git switch -c "<your-gh-name>/okinawa-food"
$ git add poll/<your-gh-name>/food/Data.toml
$ git commit -m "add Data.toml"
$ git push origin <your-gh-name>/okinawa-food

ブランチを作る理由

• 自分だけがリポジトリに手を入れるわけではない
• 他の人と共同開発をするために必要
• 一時的なパラレルワールドを作り自分の変更履歴をそこに追加

競合する可能性について

• 今回は各自の専用のディレクトリ・ファイルを作成させた

poll/<your-gh-name>/food/Data.toml

コンフリクトは起きないはず

git add

• これから変更するスナップショットを作成（ディレクトリ，ファイル，行単位で可能）
• スナップショットを作成するためにステージングと呼ばれる一時領域に変更内容を追加する

git commit

• git add で追加したステージングからスナップショットを作成(コミット)

git push

• ローカルリポジトリの変更を自分の管理しているリモートリポジトリにプッシュ
• origin は各自のリモートリポジトリを参照している
• git remote get-url origin で確認できる

プルリクエスト

• ブランチから別のブランチに一連の変更をマージする提案のこと
  • GitHub Docs の pull requests について を参照
• 各自のリモート環境にあるブランチをAtelierArithが管理しているリポジトリに取り込んでもらうよう依頼する
• GitLab の用語の Merge Request の方がしっくりくるかも

プルリクエストのマージ

これは AtelierArith (講演者) の中の人がします

無事マージがされたら

• 各自の main ブランチを更新する
• GitHub の UI からできる
• ローカルリポジトリの main ブランチを更新

$ git checkout main
$ git pull origin main

おめでとうございます

• これでコントリビューションができました．