PyData Okinawaに参加してSnowflakeを学んだ

先日、PyData Okinawaに参加してきました。

pydataokinawa.connpass.com

PyData Okinawa は Python + Data に興味のある方が交流できる沖縄を拠点にしたコミュニティです。


4年ぶりの開催だそうで、私は今回が初参加でした。

参加者のほとんどがデータ分析事業を行っている企業の方々で、学生は私だけでした。

内容はLT会で、SnowflakeエヴァンジェリストであるKTさんをゲストでお招きしていたこともあり、Snowflakeに関する話題がほとんどでした。

Snowflakeはデータの一元管理ができるクラウド型のプラットフォームです。

www.snowflake.com

データを管理することはもちろん、プラットフォーム上で開発やデータエンジニアリングなどもできるという優れものです。

環境差なく作業ができるという点がありがたいですよね。

また個人的には、他者の保管データにアクセスできる点が驚きです。

私は正直、PyData Okinawaに参加するまではSnowflakeという名前も知りませんでした。

ですが、今回参加したことで名前やサービスを知っているという段階にはなりました。

LTの中でSnowflakeチュートリアルが用意されているというお話があったので、無料トライアルが切れる前にかじってみたいと思います。

オフラインイベントということもあり、SNSで繋がっていた方とお話しできたり自己紹介で名前と顔を売れたりしたので、少し緊張しましたが参加して良かったです。

次回のPyData Okinawaにも参加したいと思います!

Gitの基本的な操作

はじめに

私がTAを担当している講義のカリキュラムにGit入門という回があったので、具体的に何を講義でするのかはまだわかりませんが、基本的な操作についてまとめてみました。

ローカルにある3つのエリア

ワークツリー

ファイルを編集し、作業を行うディレクトリ。ここにあるファイルはまだGitの追跡下には置かれておらず、変更内容もコミットされていない。

ステージ

ワークツリーで変更したファイルの中から、次のコミットに含めたい変更を選択してステージするエリア。ここに追加された変更はGitに追跡されているが、まだローカルリポジトリの履歴には含まれていない。

ローカルリポジトリ

ローカル上にあるリポジトリで、ここにコミットされた変更はバージョン履歴に保存される。ステージされた変更をコミットすると、それらはローカルリポジトリに永続的に記録される。

コミット:ワークツリーでの変更をローカルリポジトリの履歴に記録するプロセス

コマンド

リポジトリの作成

# ローカルリポジトリを作成
$ git init

# リモートリポジトリのコピーを作成
$ git clone <リモートリポジトリパス>

変更をステージに追加

# 指定したファイルをステージに追加
$ git add <ファイル名>

# 指定したディレクトリにあるファイルを全てステージに追加
$ git add <ディレクトリ名>

# カレントディレクトリにあるファイルを全てステージに追加
$ git add .

コミット(変更を記録)

$ git commit

# gitエディタを立ち上げることなくメッセージ付きで変更を記録できるオプション
$ git commit -m "<メッセージ>"

# gitエディタでファイルに変更内容(どのような変更か)を表示させるオプション
$ git commit -v

現在の変更状況を確認する

$ git status

表示内容

  • ワークツリーとステージの間で変更されたファイル
  • ステージとローカルリポジトリの間で変更されたファイル

ファイル間の変更差分を確認する

# ステージに追加する(git addする)前の変更分
$ git diff

# 指定したファイルのステージに追加する(git addする)前の変更分
$ git diff <ファイル名>

# ステージに追加した(git addした)後の変更分を表示するオプション
$ git diff --staged

リポジトリのコミット履歴を確認する

$ git log

# 1行で表示するオプション
$ git log --oneline

# ファイルの変更差分を表示
$ git log -p <ファイル名>

# 表示するコミット数を制限
$ git log -n <コミット数>

ファイルの削除を記録する

# 指定したファイルを削除(ワークツリーからもファイルが削除される)
$ git rm <ファイル名>

# 指定したディレクトリを削除(ワークツリーからもディレクトリが削除される)
$ git rm -r <ディレクトリ名>

# ワークツリーにファイルを残すオプション
$ git rm --cached <ファイル名>

ファイルの移動を記録する

$ git mv <旧ファイル> <新ファイル>

同様の操作を行うコマンド

$ mv <旧ファイル> <新ファイル>
$ git rm <旧ファイル>
$ git add <新ファイル>

リモートリポジトリ(GitHub)にpushする

# リモートリポジトリを新規追加する
$ git remote add <リモートリポジトリ名> <リモートリポジトリURL>
  • 指定したリモートリポジトリ名でリモートリポジトリとのやりとりが可能になる
  • 慣習として「origin」と命名する
# リモートリポジトリへ送信する
$ git push <リモートリポジトリ名> <ブランチ名>

コマンドにエイリアスを付ける

$ git config --global alias.<エイリアス> <コマンド>
  • エイリアス:別名
  • コマンドの入力を短縮することが目的

バージョン管理しないファイルを無視する

「.gitignoreファイル」に無視するものを指定する

# ファイル指定
ignore.txt

# ディレクトリ以下を指定
ignore_dir/

# 拡張子を指定
*.txt

# 無視しないファイルを指定
!index.html

ファイルの変更を取り消す

# 指定したファイルの変更を取り消す
$ git checkout -- <ファイル名>

# 指定したディレクトリにあるファイルの変更を取り消す
$ git checkout -- <ディレクトリ名>

# 全てのファイルの変更を取り消す
$ git checkout -- .

ステージに追加した変更を取り消す

# 指定したファイルの変更をステージから取り消す
$ git reset HEAD <ファイル名>

# 指定したディレクトリにあるファイルの変更をステージから取り消す
$ git reset HEAD <ディレクトリ名>

# 全てのファイルの変更をステージから取り消す
$ git reset HEAD .

直前のコミットを修正する

# ファイルを修正しステージに追加(git add)してから
$ git commit --amend

リモートリポジトリの情報を表示する

# リモートリポジトリ名を表示
$ git remote

# 対応するURLを表示するオプション
$ git remote -v

リモートリポジトリから情報を取得する(フェッチ)

# リモートリポジトリの情報をローカルリポジトリに取得する
$ git fetch

# 指定したリモートリポジトリの情報をローカルリポジトリに取得する
$ git fetch <リモートリポジトリ名>

# 指定したブランチの情報をローカルリポジトリに取得する
$ git fetch <リモートリポジトリ名> <ブランチ名>

# 取得したリモートリポジトリの情報をワークツリーに反映させる
$ git merge <リモートリポジトリ名>/<ブランチ名>

リモートリポジトリから情報を取得する(プル)

# リモートリポジトリの情報をローカルリポジトリに取得してワークツリーに反映させる
$ git pull <リモートリポジトリ名> <ブランチ名>

# コマンドは省略可能
$ git pull

同様の操作を行うコマンド

$ git fetch <リモートリポジトリ名> <ブランチ名>
$ git merge <リモートリポジトリ名>/<ブランチ名>

リモートリポジトリの詳細情報を取得する

$ git remote show <リモートリポジトリ名>

表示される情報

  • fetchとpushのURL
  • リモートブランチ
  • git pullの動き
  • git pushの動き

リモートリポジトリを変更・削除する

# リモートリポジトリを変更する
$ git remote rename <旧リモートリポジトリ名> <新リモートリポジトリ名>

# リモートリポジトリを削除する
$ git remote rm <リモートリポジトリ名>

ブランチを新規追加する

# ブランチを作成する
$ git branch <ブランチ名>

ブランチの一覧を表示する

$ git branch

# リモートリポジトリを含めた全てのブランチを表示するオプション
$ git branch -a

ブランチを切り替える

$ git checkout <既存ブランチ名>

# ブランチを新規作成して切り替える
$ git checkout -b <新ブランチ名>

変更を取り込む(マージ)

$ git merge <ブランチ名>

# リモートリポジトリにあるブランチの変更を取り込む
$ git merge <リモートリポジトリ名/ブランチ名>

ブランチ名を変更する

作業ブランチの名前を変更する
$ git branch -m <ブランチ名>

ブランチを削除する

# maseter(main)にマージされていない変更が残っている場合ブランチを削除しないオプション
$ git branch -d <ブランチ名>

# 強制削除するオプション
$ git branch -D <ブランチ名>

コンフリクトの解決

  • コンフリクト:管理する複数のデータに、重複や競合が発生している状態
  • コンフリクトを起こしたファイルの内容を書き換える
<<<<<<< HEAD
<p>コンフリクト</p>
=======
<p>conflict</p>
>>>>>>> feature

ファイルが表すもの

  • << HEAD から == が表すもの:HEAD(作業ブランチ)の変更分
  • == から >> feature が表すもの:マージしてきたブランチ(feature)の変更分

変更を取り込む(リベース)

# 親となるコミットを移動して変更を取り込む
$ git rebase <ブランチ名>

マージとの違い

  • マージ:変更内容の履歴(コミット)はそのまま残るが、履歴が複雑化する
  • リベース:履歴は単純になるが、元の変更内容の履歴が消える

タグを付ける

コミットを参照しやすくするために、名前を付ける

# 注釈付きタグ(名前、コメント、署名を付けることができる)
$ git tag -a [タグ名] -m "[メッセージ]"

# 軽量タグ(名前を付けることができる)
$ git tag [タグ名]

# 昔のコミットに後からタグを付ける
$ git tag [タグ名] [コミット名]

# タグのデータを表示する
$ git show [タグ名]

# タグをリモートリポジトリに送信する
$ git push [リモート名] [タグ名]

# タグを一斉に送信する
$ git push origin --tags

作業を一時退避する

作業が途中でコミットしたくないが、別のブランチで作業しないといけない時に使う

$ git stash

# 退避した作業を確認する
$ git stash list

# 退避した作業を復元する(ステージの状況は復元されない)
$ git stash apply

# 特定の作業を復元する(ステージの状況は復元されない)
$ git stash apply [スタッシュ名]

# ステージの状況も復元する
# git stash apply --index

# 退避した作業を削除する
$ git stash drop

# 特定の作業を削除する
$ git stash drop [スタッシュ名]

# 全作業を削除する
$ git stash clear

スクラムによるアジャイル開発の実践記

学部3年次に「ICTを活用するIoT時代のイノベーション人材育成のためのビジネスアプリケーション / システムデザイン実践教育ネットワークenPiT-BizSysD」を修了しました。

bizsysd.enpit.jp

enPiTビジネスシステムデザイン分野(通称:BizSysD)は、社会やビジネスニーズに対する実用的なソリューションとしてのビジネスアプリケーションやシステムデザインを自ら提案、開発し、顧客の潜在的要求を満たすことのできる人材育成を目指します。


私のチームは大学内の渋滞問題を解決するべく、相乗りアプリを作りました。

私が在籍する大学は、学内に大きな池があるせいで橋がかかっていたり、信号機があったりと、全国的に敷地面積が大きい大学です。

そんな大学内は移動がとても大変なので、車やバイクでの移動がほとんどです。

自転車に乗る人もいますが、坂が多いのであまり向きません。

そんな中、車もバイクもないという学生は、移動に大変苦労しています。

こうした学内の移動に苦労している学生の声を元に、このアプリを考案しました。

このアプリは、移動に悩んでいる学生と、それを助けてあげたい学生ドライバーをつなぎます。

このアプリを使うことで、同じ目的地に向かう学生ドライバーを見つけることができ、車やバイクを持っていなくてもスムーズな移動が可能になります。

プロダクトの紹介1

プロダクトの紹介2


このアプリ開発を行う中で、スクラムによるアジャイル開発を学びました。

アジャイル開発とは、小さな単位で動くソフトウエアを作っていく考え方(概念)で、スクラムはその手法の一つです。

スクラムスクラムマスター1人、プロダクトオーナー1人、複数人の開発者で構成されるチームです。

機敏な開発を行えるための十分な小ささと、作業を完了できる十分な大きさが必要で、一般的に10人以下で構成されます。

スクラムマスター
  • スクラムチームをまとめるリーダー

  • スクラムの理論や活動をチームメンバーに理解してもらえるように支える

プロダクトオーナー
  • プロダクトの価値を最大限に引き出すことを責務とする責任者

  • プロダクトゴールを決定する

  • プロダクトバックログ(プロダクトの改善に必要なものに優先順位をつけたリスト)を作成する

  • プロダクトバックログアイテムを並び替える

開発者
  • プロダクトの価値を生み出し、品質を守り抜く専門家

  • スプリントバックログ(スプリントで行う作業リスト)を作成する

  • スプリントゴールに向けて計画を実行する

スクラムを組み、スプリントと呼ばれる1ヶ月以内の決まった期間に4つのスクラムイベントをこなすことで、「無駄を省き、本質に集中する(リーン思考)」ことができます。

スプリントプランニング
  • スプリントで実行する作業の計画を立てる
デイリースクラム
  • 計画された今後の作業と、スプリントゴールに対する進捗を確認し、必要に応じてスプリントバックログを調整する

  • スプリント期間中は毎日同じ時間に開催する

スプリントレビュー
  • スプリントの成果を確認し、今後の活動を決定する

  • スクラムチームは、ステークホルダー(利害関係者)に成果を示し、プロダクトゴールに対する進捗について議論する

スプリントレトロスペクティブ
  • スクラムチーム内で、今回のスプリントがどのように進んだかを確認する

  • スプリント中にうまくいったこと、発生した問題、そしてそれらの問題がどのように解決されたか、されなかったかについて議論する

  • スクラムチームの効果を高めるために必要な改善点を特定する

私のスクラムチームはスクラムマスター1人、プロダクトオーナー1人、開発者2人の計4人で構成されており、私はプロダクトオーナーを務めました。

大変だったこと
  • 限られた時間の中で、どの機能を優先すべきかを決めること

授業の一環として取り組んだ内容だったので、チームとして定期的に集まれるのは限られていました。

そんな中で、どの機能を実装すればリリースできるかといった線引きが難しかったです。

  • ユーザーの視点になって物事を考え、最大の価値を提供する機能を選ぶこと

ユーザーのニーズを理解し、それらを満たす機能を特定することは困難でした。

相乗りアプリのユーザーは「車を運転する人」と「車に乗せてもらう人」に分かれます。

「車を運転する人」がアプリを利用するメリットを見出すことに苦労しました。

工夫したところ
  • タスク管理ツールTrelloの導入

私はプロダクトオーナーとして、「プロダクトバックログを可視化し、理解しやすくする」ことを意識しました。

可視化と並べ替えのしやすさを考慮して、タスク管理ツールTrelloを導入しました。

活動のほとんどが遠隔だったこともあり、Trelloを導入したことで、コミュニケーションが一段と取りやすくなりました。

タスク管理ツールTrello

  • ユーザーに使ってもらうこと

私の身近に、学内の移動に苦労している学生がいたので、定期的にアプリの使用レビューをしてもらいました。

実際に使ってもらうことでユーザーの需要がわかり、私が考えるユーザーの視点と、実際に使ったユーザーの視点のギャップを埋めることができました。

おわりに

授業の一環で、スクラムによるアジャイル開発を体験しました。

私はこの期間で「振り返りの大切さ」を再認識しました。

授業という細切れの作業時間では、目標に対してどこまで進んでいて、どこから始めないといけないということが把握しにくいです。

そこでスクラムイベントに従ってチーム活動をすることで、意識的に振り返りをすることができ、チームの状況を客観的に見つめ直し、今後の活動の方向や今何をすべきかを明確にすることができました。

もっと実装したかった機能もありましたが、短いスパンで一連の開発工程を繰り返すことで、ユーザーのニーズに対応したプロダクト開発やスクラムチームのコミュニケーションの改善がしやすく、最終的に相乗りアプリとして形になりました。

スクラムが基づくリーン思考はさまざまな領域で活用できるアプローチだと思うので、鍛えていきたいと思います。

enPiT修了証

kboyさんからFlutterを学んだ

先日、「第3回FlutterTechBeach ~kboyさんによるFlutter講義~」に参加してきました。

codebase.connpass.com

FlutterTechBeachは、プログラミングスクール等もされているCODE BASE OKINAWAで開催される、Flutterを1から学ぶことができるイベントです。

第3回FlutterTechBeachでは、Flutter大学創設者であり、YouTuberとしての顔もある、kboyこと藤川慶さんがFlutterの講義をしてくださりました。

参加費はなんと無料!!

flutteruniv.com

www.youtube.com

私は沖縄に住んでいながら、FlutterTechBeachのイベントは第3回まで知りませんでした。

知ったきっかけは、「ゆめみ x Flutter大学 今さら聞けないFlutter開発」のライブ配信です。

www.youtube.com

この配信はDartに関する勉強会で、「Flutter実践開発」著者の渡部陽太さんと、「ゼロから学ぶFlutterアプリ開発」著者の藤川慶さんが登壇されていました。

gihyo.jp

gihyo.jp

配信内では書籍のプレゼント企画があり、私はなんと当選しました!!

モバイルアプリ開発の経験がないので、これを機にFlutterを使って開発してみようと思いました。

プレゼント企画の様子


そして配信の最後に、第3回FlutterTechBeachの告知がありました。

kboyさんから直接Flutterについて学び、そしてプレゼントのお礼ができる!と思い、すぐに参加登録しました。

こういった経緯で参加した第3回FlutterTechBeachでは、Flutter大学の教材をもとにしたハンズオンや質問コーナーを通して、Flutterによるモバイルアプリ開発の第一歩を踏み出すことができました。

Flutterに関することのみならず、企業の話や就活事情などkboyさんからお話を聞くことができ、本当にあっという間の3時間でした。

画面上で見ている方とお話しする機会はなかなかないので緊張しましたが、動画通りの声、トーン、そして何も見ずに淡々と話される姿を見て、 「あっ、kboyさんだ」と感じました(笑)。

イベント後にはプレゼントしていただいた書籍にサインを書いていただきました!

これを戒めにしてイケてるアプリを作れるように勉強頑張りたいと思います!!

kboyさんからいただいたサイン

はじめての学会

先日、2つの学会に参加して、学会発表の実績を解除しました!

1つ目が、2023年度学生研究発表会です。

www.jsise.org

九州・沖縄地区の合同開催で、沖縄と長崎を配信で繋ぎ、2会場ハイブリッド形式での発表となりました。

きっかけはゼミ内で指導教員から「誰か参加してみませんか?」と言われたことです。

誰も参加しない雰囲気だったので、「やります!」と名乗り出ました。

発表形式は発表15分+質疑4分でした。

これがはじめての学会発表でしたが、沖縄会場には発表者の5名と担当者1名の少人数しかおらず、トップバッターだったこともあり、緊張はしませんでした。

発表は14分30秒ほどで終わり、質疑では質問と応答を3ラリーしたところでタイムアップとなりました。

質問は全て長崎会場にいる教員の方からのもので、痛いところを突くような質問もあり、学会発表の洗礼を浴びましたが、

適切な質問がもらえた = 内容をしっかり伝えられた

ということなのでよかったです。

2つ目が、第259回自然言語処理研究発表会です。

sites.google.com

第259回自然言語処理研究発表会

これは電子情報通信学会言語理解とコミュニケーション研究会(NLC)と情報処理学会自然言語処理研究会(NL)の合同研究会で、兵庫県三宮コンベンションセンターで開催されました。

きっかけは学部生のうちに大学院生の研究や発表のレベルを感じてみたいと思ったことです。

指導教員にも相談し、「研究会は大学院生レベルを想定しているケースが多く、レベルは高いですが、他と交流することのメリットは大きいのでやるのはアリです。」と後押ししていただき、挑戦することにしました。

発表形式は発表20分+質疑5分でした。

会場には錚々たる大学や企業、研究所の方々が50名ほどおり、素晴らしい発表が続いていたので、とても緊張していました。

ですが、発表序盤に生成結果を示す場面で会場全体に笑いが起こり、少し気が楽になりました。

発表は19分30秒ほどで終わり、質疑では座長以外の方から質問やアドバイスを3ついただきタイムアップとなりました。

私は質疑で専門家(先輩研究者方)からの「素人質問で恐縮ですが・・・」といった一撃を恐れていたのですが、杞憂でした。

「興味深い研究テーマでした」や「似たようなテーマを取り組んだことがあるから、こういうところ難しいの共感できる」など優しいお言葉や適切なアドバイスをいただき、大学院進学後の研究活動に向けた励みになりました。

正直なところ、大学院進学後は研究テーマを変えるつもりでした。

しかし、この学会発表を通して、同じテーマで研究活動を続けようと思えるようになりました。

卒業論文執筆と合わせて3つの原稿を仕上げるのは大変でしたが、指導教員のサポートもあり、なんとか学会発表を経験することができました。

指導教員からも、

関西での発表で笑いを取ったというのは「偉業を成し遂げた」といえるぐらいの実績達成なんじゃなかろうか。
座長以外から質問コメントもらいまくりでとても良い発表でした!

と言ってもらえて、少しではありますが恩返しすることができたのではないかと思います。

とはいえ、大学院生の研究や発表のレベルは私にとってとても高く感じました。

学部生のうちにそれを肌で体感し、多くの学びや刺激を得れたので頑張ってよかったなと思います。

あと 学会発表はスーツでなくてもいい ということも学びました(笑)。

1年後・2年後により良い成果を出して戻って来れるように、研究活動に励もうと思います。



はじめての兵庫でもあり、ちゃっかり満喫してきました(笑)。

スターバックスコーヒー神戸メリケンパーク店

スターバックスコーヒー神戸北野異人館

そばめし

【書評】「技術書」の読書術

はじめに

私は情報工学を学ぶ大学4年生で、来年度から大学院進学予定の者です。研究活動を行う学生として、技術書や論文を読むことは避けては通れません。そこで、それらを効果的に読む方法はないかと思い調べたところこの本に出会い、読むことにしました。

書籍情報

タイトル:「技術書」の読書術

著者:IPUSIRON、増井敏克

出版社:株式会社翔泳社

発行年月:2022年11月

ページ数:269ページ

www.shoeisha.co.jp

概要

「読書にルールはない」 ということを前提にしながら、「技術書の選び方」「技術書の読み方」「アウトプットの仕方」について著者らが各々の考え方を述べています。

印象的な内容

この本は「読書術」というタイトルですが、どういった基準・手順で本を選べば読書における失敗の可能性を抑えられるかといった「選書術」から述べられています。そこでは良本の定義を見直すことができました。

良本 = 読むことで目的を達成できる本

読書目的は読む本のジャンルによって違います。

人によって違うかもしれませんが、技術書の場合は大抵技術を習得することでしょう。

目的を達成できるような本を選ぶためには、自分のものさしで測る必要があるのです。

他の人が目的を達成できて良本だと評価したとしても、自分もまた同じように目的を達成できるわけではありません。

出来杉くんが理解できても、のび太が理解できるかわからないということです。

また、のび太が満足する内容であっても、出来杉くんが満足するかわかりません。

つまり、技術書を選ぶときはレベルを見極め、自分と合うか考える必要があるのです。

私は「入門」という言葉に釣られ、失敗したことがあります。

これからは書店に出向き、技術書のレベルを感じてから購入しようと思います。

また、レビューは「誰が」書いているかに注意して参考にしたいと思います。

私は技術書を読んでいて、序盤は良かったものの急に内容が難しくなり、やる気が失せそのまま読むのをやめた経験があります。

この時、私は1冊で読書目的を達成しようとしていたことが問題だったのです。

同じテーマの本を複数冊読む

第1部の話にも繋がることですが、同じテーマに関する本はごまんとあります。

そこで、読書目的を達成するために同じテーマの本を複数冊読むのです。

すると、ある本でつまずいてしまっても別の本で理解できるかもしれません。

これからはできるだけ「入門書」「専門書」「逆引き」の3種類を読もうと思います。

最後に、重要なことはわかっていてもなかなかできないアウトプット。(私だけ)

成長したいならアウトプットする

この本でもやっぱりアウトプットが重要だとされていました。

アウトプットは間違った理解や習熟度を確認することが目的です。

重要なことはわかっているのに、理解した気になってアウトプットをせずに学習を終わることが多々あります。

そんな私に朗報がありました。

アウトプットに「遅すぎる」ことはない

この言葉に救われました。

今までアウトプットしてこなかったものたちも、これから恐れずにどんどん発信していきたいと思います。

まとめ

この本を読んで、「技術書の選び方」「技術書の読み方」「アウトプットの仕方」についてインプットすることができました。

私はアウトプットとして読書記録をつけ、ブログにまとめてみました。

タイトルは「技術書」の読書術ですが、他ジャンルの本にも応用できる内容だったので、エンジニアに限らず多くの人にオススメできる本でした。

学んだ術を使って技術書を血肉にしていきたいと思います。