近況報告 2022.02-04
こんにちは take2405です。久々に近況報告を書こうと思います。
考えたことや学びを得たことはまた別の記事として書きたいので、本当にあったことをただ、羅列しようと思います笑
近況報告
2,3月であったこと
出来事として1番大きかったことは大学を無事卒業しました🎉
自分は大学院進学予定だったので、入学までの2ヶ月間(春休み)を利用してインターンシップに参加させていただきました。
22年間青森と北海道で生きてきた自分にとって1ヶ月間東京(しかも銀座)で働くことはとても新鮮でした。
もう歩いて街並みを見ているだけでQOL爆上がりです笑
仕事終わりに毎日3,4キロは歩いたと思います笑
インターン期間は、平日は毎日フルタイムで実務経験を積み、休日は疲労回復、コインランドリーで洗濯、観光に費やしていました。
東京にいた1ヶ月間は本当にあっという間で体感2週間もありませんでした。(それくらい充実していました)
初めてインターンの中で大規模サービス開発に携わることができたのですが、今までのハッカソンや趣味の開発とは全然違っていました。 また、実務を本格的に経験するのも初めてでした。
このトピックについては他の記事でもっと詳しく書こうと思います。
4月の近況
4月は「大学院スタート!」ということで講義が始まったのですが、講義以外の時間は基本的にインターンに時間を費やしていました。
というのも、春休みにインターンをさせていただいた会社さんで長期で働かせていただけるということで、北海道からリモートで開発に参加していました。
(本当に勉強になります。)
かつ自分は、もう1社別の会社さんでも実務アルバイトをさせていただいているので、毎週30時間前後は実務に時間を費やしていたと思います。社会人学生と言っても過言ではないかもしれないですね笑
また、サマーインターンの選考もどんどん始まっているので、毎週3,4社さんと面談しつつ実務もこなしつつという状況でした。
同年代の人よりも目上の大人と話す方が多い1ヶ月でしたが、考え方、視野がどんどん広がっていったり変化しているのが自分でもわかります。
このままメキメキと成長していきたいです!!
GraphQLについて勉強したので、メモを殴り書き
こんにちは
最近GraphQLを使ってBFFを開発することになり、色々調べた結果を殴り書きしたいと思います。
あくまでも自分に向けたメモなので、大変見づらいと思います。そのうち整備するかも??
初めに
今回私はGoのgqlgenというライブラリを用いて開発をする予定です。 gqlgenを採用した意図はいくつかありますが、特徴としてスキーマベースということがあります。
開発に入る前に、スキーマを定義し開発メンバーで叩き上げることで仕様の確定/確認を進めつつ、認識の相違を洗い出すことができると考えています。
本記事はその過程でGraphQLの仕様やスキーマのベストプラクティスについて調べた結果です。
調べたこと
https://productionreadygraphql.com/2020-08-01-guide-to-graphql-errors API内のログとしてエラーを表示することは問題ないが、クライアントへ送信するエラーはエラーコードで抽象化する デメリット メリット
- エラーに関する一貫性が生まれる
- ステージ2では、アドホックなエラースキーマを定義することでフロントの負担もあったが、この場合は必要としない デメリット
- エラーフィールドを選択しないことで、クライアントがエラーを完全に無視するのが非常に簡単なことGraphQLエラーのガイド
読んだサイト
自分なりの理解
ステージ1
ユーザーのデータをエラーとして表すことはできない。
→ステータスコードだけでなく、エラーコードの意味を決めて用いることによって、一貫性を保つことができる
トップレベルのエラーに出すべきなのは、DBが使えない!なども致命的なもののみで良いステージ2
type Mutation {
createUser(input: CreateUserInput!): CreateUserPayload
}
# 💡The "MutationPayload" wrapper type is a common convention
# initially specified by the GraphQL client Relay
type CreateUserPayload {
user: User
userNameWasTaken: Boolean!
userNameAlternative: String!
}
この例では、エラーの処理に役立つ2つのフィールドをミューテーションペイロードタイプに追加しました。createUser誰かが作成したいユーザー名がすでに存在する場合、はエラーになる可能性があります。この場合、エラーを表示し、入力内容に基づいてより適切なユーザー名を提案します。
- エラー時の内容によったクライアントの追加機能実装が必要になり困難かもしれない
- エラースキーマが増えるので、別途説明を記載したドキュメントを作成する必要が出てくる
- エラーのスキーマに一貫性がなくなっていくので、人間のエラー発見難易度が高くなる可能性があるステージ3
→注釈を追記する(選択必須など)ステージ4
エラーの共通インターフェースがあることで、クライアントはエラー間の共通の契約を知っているだけでなく、必要に応じて新しい、より具体的なエラータイプを作成することが可能ステージ5以降は割と直感的に理解ができたため、メモしていない
GraphQLスキーマ設計のためのベストプラクティス
https://kaminashi-developer.hatenablog.jp/entry/2020/12/11/093000 調査の結果今回自分が開発するものには必要ないかな(部分的には使える)と思いました。GoでGraphQL Subscriptionsを実装する
読んだサイト
メモ
ページングについて
後書き
まだまだデータローダー、ページングなど勉強しないとならない部分しか見つかりません🥺
どんどん追記して行きたいと思います。
ハッカソンを開催する側になってみた
HCB Advent Calendar 2021の19日目を担当する、taketoです。
カレンダー HCB Advent Calendar 2021
初めに
この記事ではハッカソンを開催したことについてお話ししたいと思います。
ハッカソンのレポート、運営視点からの反省など色々書きたいと思うので、興味のある部分だけ読んでみてください。
開催背景
自分の所属する大学では1年に1度、有志の学生によって学内限定のハッカソンが開催されてきました。
今年度は僕を含めた6人の学生が主体となってハッカソンを開催させていただきました。(開催に至った動機は割愛)
目次
ハッカソン概要
ハッカソンの名前は「Smile Hackathon」、テーマは「誰かを笑顔に」です。
コロナ禍の今だからこそ、このテーマでよかったと思います。
ハッカソン参加者と勉強会参加者のトータル申し込み件数は101件でした。
(内訳:ハッカソン & 勉強会参加 66名、勉強会のみの参加 35名)
おそらく歴代最大規模だったのではないでしょうか?
今回のハッカソンは、プログラミング経験の浅い1、2年生をメイン対象としたイベントだったので、計5回の事前勉強会を準備・開催しました。
うち3回はスポンサー企業様が実施してくださり、非常に内容もわかりやすく助かりました。
勉強会内容
・Swift
・Kotlin
・Git/Github
・Adobe XD
・Firebase
その他ハッカソン情報は下記のページから確認してみてください
これまでに開催された歴代の学内ハッカソンについて
未来大学では毎年学内限定のハッカソンが開催されています。
僕が知る限りの学内ハッカソンのホームページを紹介します。
2018年度学内ハッカソン
(2019年に開催してますが、2018年度です。)
2019年度学内ハッカソン
2020年度学内ハッカソン
どうですか?
先輩方が代々開催してきたハッカソンのホームページです。
僕自身も2018年度ハッカソンの勉強会、2019年度ハッカソンに参加した経験があります。
大学で開催されるハッカソンということで参加のハードルが低く、プログラミングに興味を持つとても良いきっかけになると思います。(僕もそうでした。)
先輩が開催したハッカソンに参加していた自分が、今では開催する側になっている。
感慨深いものがありますね。
ぜひ今回のハッカソンに参加してくれた学生の中から来年、再来年度のハッカソンを開催してくれる人たちが出てきてくれることを期待しています。
ハッカソン本番のレポート
先にハッカソン本番のスケジュールを示しておきます。
今回のハッカソンの特徴として挙げられることが以下の2点になります。
- 開発期間が7日間
プログラミング経験が浅い参加者を対象としているので、短期間での開発は難しいと考え、開発期間を長めに設定しました。
- 中間メンタリング実施
これは歴代のハッカソンにはなかった取り組みだと思います。協賛企業の方と参加学生だけで話す時間を設け、進捗確認とお悩み相談の機会を設けました。
その際に各チームの進捗、目標などの評価もしてもらいました。
それによって最優秀賞の選出を最終的なプレゼンだけでなく、開発期間も含めて評価できるようにしました。
また、イベントに参加してくれた学生に貴重な企業の方と話す時間を提供できたのではないかと思います。
開会式(12/12)
開会式当日は、参加学生約50名と協賛企業11社の方々が集まってくださりました。
運営側としては、準備漏れでドタバタが発生しないかどうか不安でしたが問題なく開会式(11 - 13時)を終えることができました。
開会後は、お昼休憩を挟んで開発期間スタートです。
各チームアイデア出しを開始し、早いチームは開発に着手し始めていました。
初日の最後にその時点での各チームのアイデアを発表し解散としました。
てっきりここで初日は終了かと思ったのですが、Discordを除くと1/4ほどのチームが解散後も作業を続けていました。
開発期間(12/13 - 12/17)
主な開発期間は平日の5日間でした。
平日にも関わらず、毎日毎日複数のチームが早い時間から夜遅くまで長時間Discordにこもっていて感心しました。
それに伴い裏側では学生技術ヘルパーが死に物狂いで対応してくれていました。
約8割ほどのチームがモバイルアプリケーションを開発していたため、自分はあまり出番がありませんでしたが、、、
中には大学で直接質問に来たチームもあったようで、行動力がすごい笑
Slackなどを見ているときちんとアセットからオリジナルのものを用意しているチームがあり、この時点で本当に1、2年生か?と感じていました。
閉会式(12/18)
あっという間の開発期間も終わり、ついに発表です。
プレゼンテーション資料と最終的なプログラムを提出してもらい、発表会を開始!
始まってびっくりしたのは、どのチームもレベルが高い!!
参加者の大半が1、2年だったにも関わらず、技術面、プレゼンテーションどれをとってもとても質が高かったです。
PVやロゴなどを用意しているチームが多くて見応えがありました。
(本当に1、2年生なのか??)
発表後に最優秀賞を決めるための投票結果を見たときには、全体的に僅差でした。
本来であれば、1位しか公表しないつもりだったのですが、僅差すぎたので急遽3位までを公表しました。
今回のハッカソンは評価項目として「技術力」はあまり見ておらず、「チームの工夫」、「挑戦度合い」、「成長度合い」などを重要視しました。
プログラミング経験が浅い学生をメインと対象としているため、このような評価基準にしました。中には、「技術力」、「完成度」をもっと見てほしいという思いを持つ参加者がいたかもしれません。
それは、学外のハッカソンに挑戦したいという自身の隠れた合図だと思うので、是非挑戦してみてください。
終わってから見えたこと
-
[反省]技術ヘルパー不足
今回は、圧倒的なヘルパー不足でした。個人的には、学生ヘルパーをたくさん準備するべき、むしろ余るぐらいに用意しておくべきだと考えていました。
しかし、思ったよりも企業の方々が技術ヘルプ可能と事前のアンケートに答えてくださったことで、結果的に数人しか学生メンターの準備をしませんでした。
(ここが痛恨のミス)
「学生の動く時間にヘルプできるのは、学生だけ」間違いなかったです。
考えられる対策
もっと事前に学生メンターを準備する
質問のルールをより詳細に決める
-
[反省]技術ヘルパーへの質問タイミング
これは今回最大のミスだったと思います。技術ヘルパーの質問受付時間を設けずに24時間OKにしてしまいました。
その結果、助けを求める通知が毎日深夜に複数件届いていました。
質問すること自体は悪くありません。しかし、試行錯誤せずに脳死で質問している学生が度々みられ、これは運営側のミスだなと感じました。(質問が全くできない状況よりは全然マシですが笑)
何らかの制限、ルールを設けることで、学生自身で考える、開発の段取りを考える、わからことを言語化するなど新たな学びの機会を生むことができたはずだったと思います。
来年度以降は何かしらの工夫が必要だと思います。
考えられる対策
質問解答時間を決める
質問する際に何が原因か、何を試したのかを言語化してもらう
-
[反省]開発面に関して
今回のハッカソンは、歴代の学内ハッカソンと同様にGithubを利用したチーム開発を前提としました。
Githubを利用したことがない学生向けに事前に1回の勉強会を設けていたこともあって、多少Githubで躓くチームはあっても大体はうまくいくだろうと考えていました。
しかし、現実は甘くありませんでした。ほとんどのチームがGithubで躓いていたように感じます。
個人的に原因の一部は、大学内のICT演習というチーム開発を行う活動に参加する下級生が減ったことが大きいのではないかと感じています。
考えられる対策
複数回のGithub勉強会の実施
そもそもGithubを利用しないような形式にする(難しい)
-
[反省]スケジュール共有時期について
ハッカソンのスケジュールを参加者、協賛企業の方々に伝えることがかなりギリギリになってしましました。これに関しては結構どうしようもないような気がしています。協賛企業様がいる以上レスポンスを待つ間の数日の遅延など避けられないものがあります。
ですが、大まかなスケジュールなどはもっと早めに共有しても良かったのかもしれないと感じています。
-
[学び]告知について
今回のハッカソン運営を通して、最も悩まされたことが参加者を集めるための告知です。色々試した結果、1番効果的な方法は授業へお邪魔して直接告知することでした。正直これだけで学生は集まってくれます。
2番目に効果的だと感じたのは、直接大学でビラを配ることです。これは配る人のメンタルがいかれますが、ハッカソン参加のハードルを大きく下げることができたんじゃないかなと思います。
-
[良かった点]デザインツール勉強会の実施
今年はどのチームもとてもレベルが高く非常に見ていて楽しかったと思います。その要因の一つとしてプレゼンテーション、成果物の見た目が良かったことが挙げられます。
今年は運営の「デザインに関する知識を培ってほしい、力を入れて欲しい」という思いのもと、Adobe XD の勉強会を開催しました。
その影響かどうかは分かりませんが、デザインツールを利用するチームが多く見られ、自然とデザインに意識が向いたのではないかと考えています。
運営陣の準備スケジュールについて
今回のハッカソンは4月から8ヶ月ほどの時間をかけて準備をしてきました。
今後学内ハッカソンを開く人に向けて参考程度にスケジュール感を示しておこうと思います。
4月:昨年度のハッカソン開催者や教授にお話を伺いました。
この時点では、イベントの運営に関する知見がなく、右往左往していました。
とりあえず、教授にハッカソンを開催したいとの旨を伝え、昨年度運営を経験した先輩に知見を共有していただきました。
(資料なども共有してもらえたので、とても助かりました。)
5月:ハッカソンのスケジュール・勉強会・協賛企業検討
ハッカソンの開催期間や協賛企業のリストアップ、勉強会スケジュールなど12月への見通しを立てました。
主に12月までの大まかな構想を立てていたと思います。
6月:協賛企業募集用資料の作成、ハッカソン優秀賞の評価軸検討、昨年の運営メンバーへインタビュー
協賛企業募集開始にむけ、声がけする企業のリストアップ、共有用資料を作成しました。
いくつか運営に関する疑問点も出てきたため昨年度の運営メンバーへインタビューをさせていただき知見を得ました。
確か、この時期にハッカソンのテーマ、名前が決定したと思います。
7月:運営メンバーの研究が炎上、活動は一旦休止しました
これは運営メンバーが怠けていたわけではありません笑
4年生なら誰でもこの時期は研究やら発表やら炎上すると思います笑
8月:各部門責任者の決定、タスク実施
運営メンバーでU-22プログラミングコンテストに参加しました。
(374チーム上位37チームに選出されました😊)
8月初旬に1度メンバーで集まり、後期に向けて必要なタスクを全て洗い出し、分野ごとに責任者を決定し各自でタスクをこなしました。
この記事はあまり全員で集まってオフラインで活動しませんでした。
9月:各自タスクの実行、告知準備
割り振った各自のタスクをこなしつつ、協賛企業の方々へお願いしたいこと(企業賞、技術面ヘルパー)や参加者募集の告知に向けた準備をしました。
10月から参加者募集が始まる予定だったので、告知資料、ポスターなどを作成するタスクをメインに進めました。
10月:告知、協賛企業とのやりとり
参加者の募集が始まりました。ここで問題が、、、
全然参加者が集まらない😭
おそらく参加者集めが1番苦労したと思います。
協賛してくださる企業が6、7社集まっていたのに参加者が0人でした笑
「このまま参加者が集まらなかったらどうしよう」と不安で眠れない時もありました。
(企業を巻き込んだくせに参加者0はやばい笑)
11月:告知が爆発、運営の忙しさも爆発しました。
10月に続き、11月初旬も参加者が全然集まりませんでした。
Twitterアカウントを作成したり、授業で宣伝したりなどいろいろな告知を試しました。(告知については「運営をしてみて得た学び」で書きたいと思います。)
なんとか努力が実り、11月中旬にはなんとイベント参加者が100人近く集まりました。
(マジでビビった)
参加者不足問題は解決したものの、今度は参加者が多いことによる運営としてのプレッシャー、責任がどんどんが増えてきました。
11月下旬は、5つの勉強会実施、PC貸し出し、レッドブル配布など怒涛のスケジュールでした。
12月:ハッカソン本番
あとはハッカソン本番のみということで綿密なスケジュール確認、資料準備をしました。
オープニング、クロージングスライドの準備、スケジュールの確認、企業とのアポイント、学生からの質問対応、Slackへの参加確認、、、、
終わりが見えないタスクの山でした。
あと2週間踏ん張れば、、、、という精神で持ち堪えた気がします。
終わり
ハッカソン全体の感想
この記事では各チームの作品を紹介していませんが、本当に全チームレベルが高かったです!
各チームの作品紹介と運営メンバーからの好評を書きたいぐらいです。
最後は、どれだけ自分の作っているものに愛情を持つことができたか、どれだけきちんと細かい部分まで考え込んで作れたかどうか勝敗を分けたと思います。
今回のハッカソンで分かったのでは、めちゃくちゃできる人たちがたくさんいるということでした。
近年のコロナウイルスの影響により、1、2年生のICT演習(学年関係なくチーム開発を経験できる活動)の参加人数が減少しているので、ぜひみんな来年はICT演習に参加して欲しいですね。
ICT演習に参加してチーム開発のノウハウや技術力の育成に励んでいただきたいです。
ちなみに運営 + 技術メンター2人は「Funcy」というICT演習チームに属していますので、興味があればぜひ!(さらっと告知)
そのほかにも技術メンターで奮闘してくれていた学生の数人は「はこだてSweets」というICT演習チームに属しています!
自身の興味のあるチームに参加してみてください!
個人的な感想
個人的には、なにはともあれ無事にハッカソンを終えることができてよかったです。
来年はきっと就活で追われている頃だと思うので、twitterで眺めるぐらいにしようかなと思います笑
まさか自分がハッカソンを開催する側になるなんて思ってもいませんでした。
この経験は僕としても貴重な経験だったと思う(多分もうない)ので、しっかり記憶に残したいと思います。
Go+MysqlのREST API テンプレートを作成しました
こんにちは、HCB Advent Calendar 2021の15日目を担当する、take-2405です。
カレンダー HCB Advent Calendar 2021
今回の記事ではGo+MySQLの簡単なAPIを構築するHands-on的な記事を書こうと考えていました(過去形)
しかし、そんな内容の記事はより良い内容のものがたくさんあります。しかも、記事にしたところであまり自分の今後に生きることはないな、、と感じました。
その結果今回は「Go+MysqlのREST API テンプレートを作成しました」というタイトルでやっていきたいと思います。
テンプレート概要
今回用意したテンプレートは、ニュースアプリのような記事管理系サービスを想定したAPIになっています。
簡単なGET、POST、DockerによるDBの構築を簡単に実現できるようになっています。
注意
過去に自分で書いたコードを引用して30分ほどで作成したので、ディレクトリ構成や中身の処理などを詳しく確認できていません(今後見るかも) 。
最低限動作するという状況です。
パフォーマンスにこだわらず、最低限動けばいいやという場合にご利用ください。
テンプレート説明
それでは本題のテンプレートの中身を軽くみていきたいと思います。
以下が作成したテンプレートになります。
書かれているコードを見ながら少しずつ改変していけば、Goの開発経験が少ない人も簡単にAPIを開発できると思います。
ディレクトリ説明
. ├── Dockerfile:docker image 作成の設定を記載(基本変更不要) ├── LICENSE:ライセンスを記載(基本変更不要) ├── Makefile:コンテナを立ち上げるためのコマンドを簡略化(基本変更不要) ├── README.md:リポジトリの説明を記載(各自変更) ├── build │ └── docker-compose.yml:コンテナの設定を記載(基本変更不要、MySQL以外を使用したい場合は変更) ├── configs │ ├── config.go:DBとの接続(基本設定不要、MySQL以外を使用したい場合は変更) │ └── config_test.go:DBとの接続テスト(基本設定不要、MySQL以外を使用したい場合は変更) ├── db │ └── mysql │ ├── init │ │ └── init.sql:DBのテーブル定義などを変更(各自必要なテーブルを設定) │ └── my.cnf:(基本設定不要、MySQL以外を使用したい場合は変更) ├── docs │ └── api.md:作成したAPIの仕様を記載(各自変更) ├── go.mod ├── go.sum ├── main.go:(基本変更不要) │ 以下各自テンプレートの処理を見ながら適宜変更 └── pkg ├── controller │ ├── article.go │ ├── nice.go │ └── nice_test.go ├── model │ ├── dao │ │ ├── article.go │ │ ├── conn.go │ │ ├── nice.go │ │ └── nice_test.go │ └── dto │ ├── article.go │ └── nice.go ├── server.go ├── server_test.go └── view ├── article.go └── nice.go
アーキテクチャについて
今回採用したアーキテクチャは mvc です。 コードを改変する際に以下の責務分けを意識してみてください
- view:リクエスト&レスポンスの構造体を定義、レスポンスを返す関数を定義
- model(dao):データベースとやりとりする処理を記載
- model(dto):データベースとのやりとりためのデータを入れる構造体を定義
- controller:view&modelを繋ぐための処理を書きます。ファットコントローラーに注意!!
─── pkg ├── controller ├── model │ ├── dao │ └── dto └── view
終わりに
いかがでしたか?
Goに興味があるな という方には是非触ってみてもらいたいですね(「もっとココをわかりやすくしろ!」とコメントをいただきたいです)。
さて、明日のカレンダーは西川が書いてくれる予定なのでお楽しみに!
HCBについて紹介
アドベントカレンダー1日目の記事になります。
よろしくお願いします!
さて、初日ということで今日の記事のテーマは「HCBについて」です。
本記事は以下の構成で記載しています。
- HCBの由来
- メンバー紹介
- これまでの活動
- おわりに
HCBの由来
まず、HCBとは何かというと。
ズバリ、、「HCB=北海道6種のチーズ牛丼」です。
これじゃわからないですよね笑
由来は、北海道に住んでいるチー牛6人で構成されているからで、略称ぐらいはかっこよくしたいなと思いHCBと呼んでいます。
メンバー紹介
HCBは以下の6人で構成されています。
- 大崎敬太:シェーブルチーズ
twitter:http://twitter.com/@BaseKeita - 木村圭太:ブルーチーズ
twitter:https://twitter.com/mokuson_ssbu - 工藤海斗:チェダーチーズ
twitter:https://twitter.com/kudokai00 - 鳥山英峻:クリームチーズ
twitter:https://twitter.com/remlimsan - 西川昂志:モッツァレラチーズ
twitter:https://twitter.com/takashi54461358 - 若松丈人:バジルチーズ
twitter:https://twitter.com/wkmt2405
全員公立はこだて未来大学の4年生です。(2022年現在)
これまでの活動
HCBは2021年の3月から活動しています。週に1回の活動で、プログラムを書いたり、コンテストに出たり、イベントを企画したりと約9ヶ月ほど活動をしてきましたが、本当にあっという間でした。以下に主な活動実績を記載します。
詳細な内容は、アドベントカレンダーの他の記事で出てくると思うので、お楽しみに!!
活動
- 3月:ハックツハッカソン優勝
コロナ禍で珍しくオフライン開催のハッカソンがあったので、参加しました!わざわざ北海道から福岡まで飛びました。頭も飛んでますね笑
- 10月:U-22プログラミングコンテストBEST37
経済産業省が主体となって開催している日本最大規模のプログラミングコンテストに出場しました。
- 12月:所属大学内ハッカソンを開催
大学の1,2年を対象とした勉強会の実施、ハッカソンの開催を現在進行形でしています。
おわりに
さて、ざっとですがHCBについて何となくわかっていただけたと思います。12月の毎週日曜にこれまでのHCBの活動をより詳しく紹介していきたいと思うので、お楽しみに!
明日の記事は、西川(twitter:https://twitter.com/takashi54461358)が「Next」について記事を書いてくれる予定なので、お楽しみに!
U-22 プログラミングコンテスト2021でcertificateをいただくことができました
こんにちは
今回は「U-22 プログラミングコンテスト2021」に参加した体験談を記事にしたいと思います。
目次
1. 参加のきっかけ
僕は某情報系国公立大学に通う4年生です。普段は、大学の友人6人とチームを組み、週に1度活動をしています。
活動内容は、ハッカソンや技術系イベントへの参加、サービス展開を視野に入れたプロダクトの開発です。
そんなある日、いつも通りチームで活動を行っていると、メンバー内で「U-22 プログラミングコンテスト出てみない?」と言う声が上がりました。そこがきっかけでした。
浅っと思う方もいるかもしれませんが、そうです。初めは勢いでエントリーをしました笑
2. エントリーから作品提出まで
勢いでエントリーしたものの、作品提出までの期間はスケジュールを組み、きちんと計画的に進めました。(結局最後の1週間がバタバタでしたが、、、)
大体のエントリーから作品提出までのスケジュール感を以下に示したいと思います。
5月
下旬 エントリー(確か)、製作作品のアイデア検討
6月
上旬 製作作品のアイデア検討
中旬 製作作品のアイデア検討・決定
下旬 機能・要件検討、実装技術検討、論文調査
7月
上旬 実装技術検討、UI/UX設計、論文調査
中旬 活動休止(学校が忙しかったため)
下旬 活動休止(学校が忙しかったため)
8月
上旬 開発
中旬 開発
下旬 開発、作品提出資料作成、作品提出(31日)
以上がスケジュールになります。
私のチームは、もともとビジネスに興味があったということもあり、
- アイデアの考案(ビジネス展開できそうかどうか、ニーズがあるかどうかなど)
- 機能・要件定義
を重要視し、きちんと時間を取って検討、メンバー間の認識共有を行いました。
また、開発に取り掛かる前に論文を調べ、実装機能のロジックを念入りに検討、裏付けを行いました。
最後の1週間は怒涛の追い込みでした。(どれだけ順調に実装できていたとしても、最初からこうなると思っていました笑)
3. 作成した作品概要
提出作品
Focus Box
PV
ロゴ
製作背景
昨今コロナウイルスの蔓延により、働き方が変化しています。その中でも、出社することなく、自宅やカフェなどで作業するリモートワークが広がっています。リモートワークは、感染対策とともに、移動時間や費用が不要になるというメリットがあります。
一方でデメリットとして、仕事とプライベートの境界が曖昧になってしまい作業中の集中力維持が難しくパフォーマンスが低下してしまうことなどが挙げられます。このことから、リモートワーカーの集中維持をサポートすることは多くのニーズがあると考えられます。
そこで今回、リモートワーカーをメインユーザーとして、ユーザーの集中力の低下を検知し、パフォーマンスの維持をサポートするFocus Boxを開発しました。
作品概要
Focus Boxは、リモートワーカーの顔の情報から集中力の低下を検知し、作業場所の環境情報より集中力を阻害する要因の改善策を提案します。
Focus Boxでは、リモートワーカーの集中力低下を検知するための情報として瞬きの回数を採用しました。兜森ら[1]の研究では、タスクに依存した傾向はややあるものの、瞬きは集中度の指標になりうることが報告されています。
次にリモートワーカーの集中力を阻害する1つの要因として、周囲環境の情報に着眼した川隅ら[2]の研究では、温湿度から判断できる不快指数とCO2濃度が上昇するにつれて、集中度が低下することが報告されていました.これらの関連研究をもとに,瞬きの回数から利用者の集中度合いを、集中力を阻害する要因を温湿度とCO2濃度からそれぞれ評価しています。
それぞれの情報の収集方法として瞬きは、Webカメラからワーカーの顔を検知し一定時間における瞬きの回数を定期的に測定・記録しています。温湿度、CO2濃度は、センサーモジュールを搭載したデバイスを作成し、情報を収集しました。
参考文献
[1]兜森仁志,安彦智史,長谷川大,佐久田博司,“webカメラを用いた瞬き検出による集中度評価”,情報処理学会 第77回全国大会講演論文集, Vol. 2015, No. 1, 2015年3月, pp. 931–32.
[2]川隅恭介,岩井将行,“室内環境・生体情報による複数のセンサを用いた非接触集中測定システム”,情報処理学会研究報告ヒューマンコンピュータインタラクション(HCI), Vol. 2017-HCI-171, No. 35, 2017年1月, pp. 1–7.
(実装する際に採用した判定基準や、機能ロジックなどそれぞれに裏付けとなる論文があり、かなり長くなってしまうのでざっと書きました)
4. 結果
U-22プログラミングコンテストの選考フローは以下のようになります。
事前審査(全作品のうち10%に絞り込み)
↓
1次審査(事前審査を通過した作品の中からさらに半分に絞り込み)
↓
最終審査(結果発表&各企業賞決定)
結果は事前審査突破(1次審査選考落ち)でした。
順位的には、総エントリー作品数374作品のうち上位37作品に選ばれたという結果でした。
事前審査突破のcertificate(証明書)が後日もらえるそうなので楽しみです。
5. 自分の担当タスクについて
作成した作品「Focus Box」は今回Webを対象とした作品です。
開発タスクをプラットフォームごとに分類すると以下のようになります。
- Webフロント
- バックエンド
- デバイス
- インフラ(デプロイ環境など)
申し訳程度のアーキテクチャ図
今回私はWebフロント、バックエンド、デバイスの開発タスクを担当しました。以下に簡単に担当したタスクを書かせていただきます。
Webフロント:UI開発、状態管理実装
バックエンド:DB構築、テーブル設計、WebAPI開発(ログイン、ユーザーのステータス管理など)
デバイス:センサーによって取得したデータのAPIへの送信処理
詳しい話が気になる方はコメントしていただけると幸いです。
6. あとがき
今回出場したチームメンバーは全員大学4年生で来年から大学院へ進むもの、就職するものそれぞれ進路が異なります。そのためおそらく今回がこのメンバーでイベントに出場できる最後の機会だと思います。
その最後の機会でかつ、全国規模のコンテストで結果を残すことができ、とても嬉しく思います。
現状に満足せず、今後は実務などに触れられる機会を見つけ、インフラ周りの知見を得ていきたいと思います。
近況報告-2021.09.16-
こんにちは take-2405 です。
初めましての方はどうも、北海道に住んでいる情報系大学生です。
日々プログラミングなどIT分野の勉強をしています。
しばらくこのブログで記事を書いていなかったので、久しぶりに近況報告を書こうと思います。
最後に書いた記事が5ヶ月前のJavaScript/TypeScript(以下JS/TS)を触り始めたという内容の記事でした。
実は投稿がなかった間も、qiitaの記事はちょくちょく更新していたので見ていただけると幸いです。
更新がなかった期間サボっていたかというとそんなこともなく、大学の研究/学校の仲間とチーム開発/アルバイトで割と忙しい日々を送っていました笑
特に4月からで個人的に大きかったイベントは
- 研究の発表会
- ISUCON11出場
- U-22 プログラミングコンテスト出場
だと感じています。外部のイベントに参加することで自分の実力のなさを痛感しつつも少しずつ自分の知識や経験が積み重なっている気がします。
僕のqiitaを見てもらうとお分かりの通り、最近はJS/TSに関する記事を投稿していますね。
そうです。前回の記事投稿からの5ヶ月間少しずつJS/TSの開発をしていました。またAWSを用いたサーバーレス開発しており、今流行りのクラウドに関する知識も身についてきました。
そして、つい最近U-22 プログラミングコンテストに参加した際に、初めてReact+Reduxの開発を行いました。
Webフロントの開発経験ができたことで、今までは「バックエンド(API作成、DB構築など)はできるけどフロントができない、、、」と言って避けてきた個人プロダクトの開発も、少しずつ行なっています。