2024 ソフトウェア設計及び演習用の班Wiki

• 班決めをした。
• プロジェクトのテーマを話し合った。
• LINEグループを作成した。

(コメント)

具体的な仕様についてはまだ話し合っていないので、次回までに自分で考えて、アイデアをグループで共有できるようにしたい。

体調不良のため欠席。

(コメント)

休んでしまい参加できなかったが、チームのメンバーが作成してくれた企画書をよく読んで次回からの活動で役に立てるようにしたい。

• Gitの設定を行った。
• 簡易企画書を見直し、修正を行った。
• プロジェクト内の名詞と動詞を書き出した。
• 書き出した名詞と動詞のつながりを図示して説明を書き加えた。

(コメント)

具体的な機能についてイメージができてきたので、どんなツールを使用したらよいかなど、自分でこれからの活動を先取りして考えておきたいと思った。

• ものと操作の洗い出しを再度行った。
• 画面遷移のイメージを作成した。

(コメント)

ものと操作を前回よりも詳細に書き出すことができたし、そこからどのように実現するかを具体的にイメージすることができたのが良かった。

• モジュール化を行った。

(コメント)

モジュール化をしてそれぞれについて考え、調べてみると新たな疑問や問題がいくつか出てきたので、解決できるように自分で調べておきたいと思う。

• プロトタイプ作成を行った。

(コメント)

やるべきことは多いが、一つひとつのプログラムは実現できそうなのでコツコツと進めたいと思う。

• プロトタイプ作成を行った。

(コメント)

サンプルデータをグラフで表示し、タブで表示するグラフを切り替えられるようにした。中間発表までに実現しようと思っていたところができたので、次回でページ遷移やCSSなどの全体的な動きを調整できればと思う。

• プロトタイプ作成を行った。
• 中間発表の準備を行った。

(コメント)

中間発表にむけてページ遷移を確認することができた。しかし、データベースからデータを取得するところで問題が生じてしまったので、解決法を調べて対処できるようにしておきたいと思う。また、gitlabで開発を行う上でファイル名などチーム開発特有の問題にも気づくことができ、良いきっかけとなったと思う。

• 中間発表を行った。
• 今後の方針を話し合った。

(コメント)

他の班の発表を見たことでさらに改善すべき点がいくつも出てきたので、より見やすく使いやすいものになるように修正したいと思う。

• 消費カロリーと摂取カロリーのグラフをまとめて表示するように変更した。

(コメント)

中間発表までで一度大まかな仕様は決まっているため、改善しようとすることで今までの構成が崩れていまうリスクがあると思った。コードを書く際には、変更しやすいような書き方をする必要があると感じたし、Reactなどのライブラリを利用してみたいと思った。

• 視認性の観点から前回行ったグラフの変更を元に戻した。
• コードのリファクタリングを行った。

(コメント)

今回の作成の中で初めて変更を元に戻すという作業を行ったが、gitlabを使用していたことで簡単に以前の状態に戻すことができ、変更を保存することのメリットを実感した。また、普段から読みやすいコードを意識したりこまめにリファクタリングを行ったりすることで、自分が修正するときだけでなく他の人が修正するときにも作業がしやすくなると感じた。

• グラフにクリックイベントを追加した。
• コードのリファクタリングを行った。

(コメント)

グラフにクリックイベントを追加できたのが意外だった。Chart.jsについて他にも調べてみると今まで知らなかった機能があることが分かったので、個人的に何か作成する際にも使ってみたいと思った。最終発表までの時間の関係で諦めたところがあり悔しくもあるが、後で個人的にやってみようと思う。

• コードの微調整を行った。
• 最終発表の準備を行った。
• 班wikiの記入と整理を行った。

(コメント)

今回の講義中に作業を終えることができ、良かったと思う。見た目は中間発表からあまり変わっていないかもしれないが、細かいところで機能を追加したり視認性を高めたり改善することができた。次回の最終発表で他の班の発表を見るときには、大きな改善点だけでなく細かい機能や工夫にも注目したいと思う。

• 最終発表を行った。

(コメント)

他の班の発表を見て、自分達と同じような機能を作っていてもその実現の仕方は異なっていることに気づいたことにより、今回作成した機能を他の手段ではどのように実現できるのか考えてみたいと思った。また、作品の機能自体はそれほど難しくないものであっても、UIの部分で工夫してデザイン性を高めることで作品の完成度を上げられることにも気がついた。これは逆のことも言え、プログラムが複雑で高度であったとしてもUIの部分で見にくかったりモダンでなかったりすると作品全体の完成度が低く見えてしまうと思った。

破壊的メソッド（https://maasaablog.com/development/frontend/javascript/1171/）

特にJavaScriptの場合、配列を操作するときにはもとの配列を直接操作してしまっていないか意識する必要がある。 JavaScriptのArrayオブジェクトに属するメソッドには「破壊的な」メソッドが存在しており、「破壊的な」メソッドはもとの配列を直接操作（破壊）してしまう。

• splice()
• copyWithin()
• fill()
• pop()
• push()
• shift()
• unshift()
• reverse()
• sort()

default export と named export（https://engineering.linecorp.com/ja/blog/you-dont-need-default-export）

以下の2点から、JavaScript/TypeScript 環境においては、default export ではなく named export を行うべき。

• import 側の裁量で対象を自由に命名できてしまうことによるリファクタリングのしにくさ
• エディタの自動 import が named export でのみ効果を発揮するというエディタとの親和性

Firebase StorageにおけるCORS（https://qiita.com/chima91novice/items/0cd46b5965e087609ef5）

CORS による許可なしに他のオリジンから読み込んだ何らかのデータをキャンバスに描画すると、キャンバスは汚染されてしまう。汚染されたキャンバスは安全とみなされなくなり、そのキャンバスから画像データを取得しようとすると、例外が発生する。
ブラウザで直接データをダウンロードするには、Cloud Storageバケットに対してクロスオリジンアクセス（CORS）を構成する必要がある。この構成はgsutilコマンドラインツールを使って行う。