iPad Air で十分だろ？と思いながら Kindle Paperwhite 買った結果
こんにちは。今月２本目のブログです。
今月はあと１本「2022年の振り返りと2023年の目標設定」について投稿しようと思っています。
今回は、先日開催された「Amazon ブラックフライデー2022」で購入した Kindle Paperwhite(第10世代) についてです。
今回僕が、購入したのはKindle Paperwhite という電子書籍リーダーです。画面フィルムやカバーがセットのタイプで 23000円 から 18000円 ほどになっていました。
購入動機は単純で、「友人が持っていて絶対に買ったほうが良いと言っていた」「安くなっていた」からです。
僕は、普段小説や思想本など読むだけのもの（メモを書き込んだりしないもの）は電子書籍で購入し、iPad で読んでいました。iPad を使用していて、特に不便を感じていなかったので「買う必要あるのか？」と半信半疑のまま購入しました。
しかし、購入して約3週間使用した今は「絶対に買ってよかった」と思っています。
その理由を紹介していきたいと思います。
買ってよかった理由
1. 軽くて画面サイズがちょうど良い
まず、重量を比較してみましょう。
Kindle Paperwhite：213g
調べてみて驚いたんですが、なんと重量差は 245g です。個人的に「それしか変わらないの？」と驚きました。
片手で持ってみると体感的にはもっと重量さを感じます。圧倒的に違います。
次にサイズを比較してみましょう
Kindle Paperwhite：11.7cm × 16.9cm × 9.1mm
iPad Air (第4世代)： 17.8cm× 24.7cm × 6.1mm
参考 iPad mini：13.4cm × 20.3cm × 6.1mm (300g)
縦横ともに6〜8cm程度違います。
「 iPad miniを買えばいいのでは？」と思う方もいるかもしれませんが、値段が全然違います(iPad miniの方が倍高い)。また、iPad mini は本を読むには確かに良いかもしれませんが、他のiPadのユースケース（論文を読む・ノートをとるなど）で使用感が低下することが考えられます。
これらのサイズ感と重量の違いは大きくて「片手で難なく長時間使用できる」か「両手で持っていないと辛い」というぐらい違います。
「就寝前にベットで横になりながら本を読むとき」や「ソファーでくつろぎながら本を読むとき」に格段に楽になりました。というか、iPadを使用したときは片手では使用できないので基本的に机でしか電子書籍を読むことができませんでした。
ストレスなく読書できるシーンが増えたことは、個人的に大きな恩恵を感じています。
あとは、サイズが小さいので外出時に持ち出すハードルがめちゃくちゃ下がりました。
2. 防水だった
買ってみてまたまた驚きだったんですが、なんと防水設計のデバイスでした。以前はiPadを防水ケースに入れ風呂場に持ち込んでいましたが、Kindle Paperwhite は容赦無く風呂場に持ち込むことが可能です。
また、防水ケースを使用すると水滴で誤動作が多くなってしまいますが、その心配がないことも大きなメリットに感じています。
半身浴＋読書がすっかり習慣化されてしまいました。
3. その他
余計な機能を備えていない
iPadはどうしても他のアプリケーションからの通知などが目に入り集中力を削がれてしまうことが多々ありますが、その心配がありません。
ブルーライトがほとんど発生しない
Kindle Paperwhite の画面は反射式表示なのでブルーライトがほとんど発生していません。あまり実感はないですが、数年の積み重ねを考えたときの「目への負荷」や「就寝前に目を覚さないこと」の効果は大きいのではないかと感じています。
最後に
以上が、Kindle Paperwhite を買った感想のまとめでした。
１点気になるところとしては、今回 Kindle Paperwhite と保護フィルム、カバーをセットで購入しましたが、Kindle Paperwhite 本体のみの購入でもよかったかもと感じています。
カバーを付けてしまうとデバイスの厚みが増し、片方で持つ時のストレスが大きくなってしまうので、家ではカバーは使用せず外出時のみカバーを使用しています。
良さそうだなと感じた方はぜひ購入してみてはいかがでしょうか？読書週間のある方であれば確実に買ってよかったと感じるはずです。
大学院中退という判断に至るまで
久しぶりの投稿になります。
今日大学に退学願を提出しました。
なので、僕の「大学院進学を決めてから大学院を辞めるまで」をここに記録しようと思います。
※本記事における記載は、全て個人の見解です
※ざっと書いているので、誤字脱字・不適切な表現は目を瞑ってください
この記事を書くモチベーション
- 将来の自分に向けて
今の自分を将来振り返れるようにするためです。 - 今後同じような選択をしようとする人に向けて
あまり自分について発信することが得意ではないですが、あえてデジタルタトゥーになりそうな（きっとなるであろう）ブログとして残すことにしました。
「学校を辞める」というワードを聞くと悪いイメージが世間一般では先行すると思いますが、今後自分と同じような選択を考える方を支える1つになればと思います。
概要だけを知りたい方へ
完結にまとめると以下のようになります。
Q：なぜ大学院を辞めるのか？
A：大学院に進学した目的を達成したと感じたから
Q：大学院に進学した目的とは？
A：学生でいられる期間を伸ばすため、社会人として働く前に時間が欲しかったから
Q：なぜ学生でいられる期間を伸ばしたかった？社会人として働く前に時間が欲しかった？
A：学部3年の12〜2月に就活を行ったが、そこから予想できる自分の将来に対して納得できなかった（漠然とした不安と迷いを感じた）。自分の実力不足と自己理解不足を感じたから。
詳しく知りたい方へ
続きをお読みください。 僕が、大学院進学を決意してから大学院中退までの２年間を時系列に沿って紹介しようと思います。
もしかしたら成功体験のように受け取られる方がいるかも知れませんが、本来（大学の）４年間でたどり着けたでろう（辿り着きたかった）結論に、怠惰のせいで遠回りをしてしまったという内容です。
自己紹介
（2022年現在）僕は、北海道にある公立大学の修士１年です（でした）。
年齢は23歳、趣味は運動・サウナ・読書です。
大学ではコンピューターサイエンスについて学び、ラーニングアナリティクスのテーマについて研究していました。
現在の状況としては、退学願を提出したばかりです。すでに学費を払っているので、年度末まで籍は置こうと考えています。
大学院進学を決意する（学部3年12~2月）
僕が、大学院に進学を決めた理由は「就職までの期間・学生でいられる期間を伸ばすため」です。
学部３年の終わり、周りで就活の話題を耳にする増えてきたのでなんとなくエンジニアとしての就職を考えていました。
それなりにプログラミングに取り組んでいたし、プログラミングが好きだったのでこの判断に間違いはないだろうと考えていました。
そして、学部３年の12月~2月にかけて就活をしました。3、4社選考を受けましたが、結果的に全て辞退しました。
選考を辞退した理由
その当時は、「今の就活から予想できる就職先、そこから続く自分の将来」に対して漠然と不安と迷いを感じて辞退しました。
約2年たった今、その「不安と迷い」を言語化がすることができたので、以下に記載します。
「ここで働きたい」と思う企業が見つけられていない
この頃受けていた企業は、どれも就職支援サービスの方から紹介を受けた企業で自分の意志はほとんど反映されていませんでした。業界・企業分析が不足していました。
自分について知る時間が不足していた
面接の中で聞かれる「キャリアビジョン」や「就活の軸」に対して、自信のある答えを持てていませんでした。
その曖昧さは自分の将来に対する不安感を煽る原因となっていました。
なんとなく選んだ企業・内定がとれたからという理由で就職はしたくない
「大学まで進んで当たり前」という考えが日本では一般的になりつつありますが、自分はそうは思っていません。4年間大学に通わせてもらった結果、最終的にそういった曖昧な結果を出すことに納得ができませんでした。
また、なんとなくで決めた業界、職種、会社で働いた場合、ミスマッチは絶対にあると思います。おそらく僕は、仕事に対してモチベーションを長く保つことはできないと思いました。
（新卒入社3年以内の離職率が3割を超えている理由もこれと因果関係があると思います。）
仕事の目的をお金を稼ぐことにはしたくない
今後、人生の約1/3という膨大な時間を費やしていく仕事の捉え方、今後数十年働く目的について考える時間が必要でした。
求められるレベルに納得できなかった
僕が受けていた企業はどこもプログラミング未経験の方も採用している企業でした。
それ自体が悪いということはありません。しかし、一定のレベル（プログラミング経験）が要求される会社に入りたいと感じました。
求められるレベルは、企業の成熟度、ビジネスの大きさに関係している考えており、入社後に得られる経験、見える視野、その先のキャリアに大きく差を生み出すのではないかと思います。
以上が、漠然と感じていた不安と迷いの正体でした。
「不安と迷い」の正体が分からない当時の僕でも、圧倒的に実力と分析が不足していることだけは分かりました。納得できる将来を選択するため、学部3年の2月末に大学院進学を決意しました。
今焦って就職するよりかは、大学院に進むことが得策だと考えました。また、研究に対して熱中するという可能性もありました。
余談
大学院進学の判断は、学部時代の成績が大学院への推薦要件を満たしていたことも要因の1つだったと思います。入試の学力試験免除・入学料免除があったので、進学するための労力はほぼ０でした。
大学院入学までの１年間（学部4年）
進学を決めてから入学までの１年間は、準備期間にしました。
就活をしてみて感じた実力不足・分析不足を埋めるためです。
具体的には以下のようなことをしました。
実力不足に対して
- アルバイト（仕事）としてプログラムを書くことで実務経験を得た （実務経験があるという実績づくり＋技術的な成長を目的とした）
- プログラミングコンテストに参加し、成果物を作った （結果的に国内最大規模のコンテストで賞を取れたり、地方のハッカソンで優勝できたりと実績も生まれた）
- 自分の行動・行動原理・結果を残すために、ブログを始めた
自己分析不足に対して
- 自分の人生を振り返った （苦い思い出を意識的に振り返った。楽しい瞬間よりも辛い瞬間にこそ自分弱さ、価値観を知ることができるような気がしたから）
- 現役のエンジニアの方々と会話する機会を作った （実際に社会で働く人と話し、共感できる考え方・表現を参考にすることが、自分の思考を言語化する効率の良い方法だった）
企業分析に関しては、大学院に進んでからインターンシップの選考を通して行えば問題ないだろうと考えていました。
１年の準備期間を経た結果、実力不足と自己分析不足を多少補うことができました。
エンジニアとしては、学部４年の2月まで北海道のIT企業で週20時間ほどの勤務させていただきました。その後は、春休みを利用して東京のより規模感の大きい（上場済みくらいの）企業で１エンジニアとしてフルタイムで就業させていただけるようになりました。
大学院入学後（修士１年）
大学入学後は、春休みから引き続きほぼフルタイムで就業しつつ、大学院生として講義、研究に取り組みました（両立できていたかと問われると怪しい）。
スケジュールはタイトでしたが、エンジニアとして求められるハードスキル・ソフトスキル両方において成長を実感する機会が増えました。
収入も増え、学費や生活費を自分で払えるようにもなりました。
（在学期間は、大学の忙しさによって上下はあったものの月30万弱は稼げていた気がする。）
5月頃になると１年間の成果を出す最初のタイミングであるインターンシップ選考が本格化しました。(情報戦として、企業とのコネクションは３月から意識的に作っていました。)
エンジニアのインターン選考は、一般的に４次or５次選考まであります。
例）
１：エントリーシート
２：コーディングテスト
３：人事面接
４：エンジニア面接１
５：エンジニア面接２
「日本で知らない人はいないだろう」というレベルの大企業から成長途中の企業までエントリーしました。結果的には、12社受けて10社合格でした。思っていた以上の成果でした。
春休みから働かせていただいていた企業を5月末に退社し、サマーインターンという枠組みで6月の頭から複数の企業さんを短いスパンで転々としていきました。
複数の企業で働き、現場で活躍されてる方々を見ることで、自分の人生の目標、そのためのキャリアビジョン、必要な企業選びの軸が見えてくるようになりました。
本当にしたいことが明確になっていくにつれ、今学校で学んでいること・今後卒業までの間で学べることは、自分にとって価値あるものか？わざわざお金と時間を投資して学ぶことか？と違和感を感じるようになりました。
大学院を辞めるという考えが自然と芽生え、現実味を帯びていきました。
数ヶ月後、怒涛のインターンがひと段落した9月末から本選考を受け始めました。
そして、10月には大学院を中退することを前提として内定をいただくことができました。
その後も、他の志望度の高い会社さんから内定をいただくことができ、就活の終わり(大学院に進学した目的の達成)が見えました。
そこから中退の手続きをするまではあっという間でした。
指導してくれた教授や心労をかけた家族に対する申し訳なさはありますが、自分の判断を優先することにしました。
最後に
なんとなくパソコンが触りたくて、地元周辺の国公立大学から選んだ大学でした。しかし、今思うと最適な選択だったと思います。
僕が書いている文字列（プログラム）が、インターネットというプラットフォームを介することで、予想もつかないたくさんの人に価値を提供している・できるかもしれない。
この可能性に僕はめちゃくちゃ魅力を感じていますし、自分が視野に入れていた大学の中だとここでしか専門的に学ぶことはできなかったと思います。
以上が大学院進学を決めてから中退するまでの流れです。
大学院に進学したこと・中退することどちらも間違っていたとは思っていません。
（これらの判断が正しかったと今後証明していきます。）
ありがとうございました。
近況報告
こんにちは take2405です。
最近HHKBを入手したのでたくさんタイピングしたいなと思い、５月前半の近況を報告することにしました笑
1. インターンの選考が結構落ち着いてきた
現在も、まだ4、5社はインターン選考中ですがピークは超えたのかなという印象です。 自分はたくさんインターンにエントリーしていると感じていて、実際
受けすぎじゃない？そんなに受けて全部出れるの？と言われることがあります。
合格したインターンに全部いけるかはわからないです。
語弊を招きそうなので、説明すると受かったインターンには可能な限り全部参加するつもりですし、興味のないインターンは受けていないです。ただ、日程的にどうしても厳しい場合は辞退も考えています。
ただ、辞退は倫理的にちょっとどうなの？とは自分でも思うので、可能な限り辞退したくないですね。
自分としては、エントリーの段階で
「他の受けようと思っているインターンと日程が被ってるからエントリーできない」
という思考は違うと思っていて、面談を進めていく中で自分にマッチしたインターンだと気づくかもしれませんし、本命のインターンがあったとしてそれが受かるかもわかりません。
また、面談するだけでも今後の就活で重要な判断材料になると思っています。なので、自分は興味がある会社さんのインターンはどんどんエントリーしています。
実際週に4、5社ぐらいのインターン選考をこなしていますが、サイトで見るよりも実際に面接官の方と話す方が会社と自分の相性がなんとなくわかります。
面接官の方の質問内容や回答への返答などから会社のニュアンス？や、新卒エンジニアに対して求めていることなどの違いも垣間見えます。
それだけでとてもインターンにエントリーした甲斐があると感じています。
2. 競プロを始めた
前々からずっとやりたいな〜とは思っていたんですが、なかなか手が出せませんでした。
手が出せなかった理由は、競プロよりも第一に長期インターンを見つけなきゃ（実務経験が積みたい）という思いがあったからです。
長期インターンのために、業務に必要な技術を身につけなきゃ！成果物を作らなければ！と躍起になっていました。（今思うと時間を無駄にしちゃったなと感じます。）
最近やっと、週４日程度業務としてコーディングできる環境を作ることができたので、ついに競プロに挑戦してみました。
計2回ビギナーコンテストに参加しましたが、なかなか思うように結果が出せていません。
ただ、自分はめちゃくちゃ競プロが楽しくて熱が入っているのでこれからどんどん頑張りたいと思います。
3. ISUCONの個人スポンサーになった
昨年初めてISUCONに参加したのですが、全く勉強しなかった結果非常に悔しい思いをしました。（スコア：4000）
今年こそは絶対にリベンジしたいと思い、予選参加確定枠の個人スポンサーになりました。
15000円と学生には痛い出費でしたが、これで逃げることはできなくなりました笑
終わりに
とまぁ最近の近況はこんなところかなぁと思います。
ありがとうございました。
近況報告 2022.02-04
こんにちは take2405です。久々に近況報告を書こうと思います。
考えたことや学びを得たことはまた別の記事として書きたいので、本当にあったことをただ、羅列しようと思います笑
近況報告
2,3月であったこと
出来事として1番大きかったことは大学を無事卒業しました🎉
自分は大学院進学予定だったので、入学までの2ヶ月間(春休み)を利用してインターンシップに参加させていただきました。
22年間青森と北海道で生きてきた自分にとって１ヶ月間東京(しかも銀座)で働くことはとても新鮮でした。
もう歩いて街並みを見ているだけでQOL爆上がりです笑
仕事終わりに毎日3,4キロは歩いたと思います笑
インターン期間は、平日は毎日フルタイムで実務経験を積み、休日は疲労回復、コインランドリーで洗濯、観光に費やしていました。
東京にいた１ヶ月間は本当にあっという間で体感２週間もありませんでした。(それくらい充実していました)
初めてインターンの中で大規模サービス開発に携わることができたのですが、今までのハッカソンや趣味の開発とは全然違っていました。 また、実務を本格的に経験するのも初めてでした。
このトピックについては他の記事でもっと詳しく書こうと思います。
4月の近況
4月は「大学院スタート！」ということで講義が始まったのですが、講義以外の時間は基本的にインターンに時間を費やしていました。
というのも、春休みにインターンをさせていただいた会社さんで長期で働かせていただけるということで、北海道からリモートで開発に参加していました。
(本当に勉強になります。)
かつ自分は、もう１社別の会社さんでも実務アルバイトをさせていただいているので、毎週30時間前後は実務に時間を費やしていたと思います。社会人学生と言っても過言ではないかもしれないですね笑
また、サマーインターンの選考もどんどん始まっているので、毎週3,4社さんと面談しつつ実務もこなしつつという状況でした。
同年代の人よりも目上の大人と話す方が多い１ヶ月でしたが、考え方、視野がどんどん広がっていったり変化しているのが自分でもわかります。
このままメキメキと成長していきたいです！！
GraphQLについて勉強したので、メモを殴り書き
こんにちは
最近GraphQLを使ってBFFを開発することになり、色々調べた結果を殴り書きしたいと思います。
あくまでも自分に向けたメモなので、大変見づらいと思います。そのうち整備するかも？？
初めに
今回私はGoのgqlgenというライブラリを用いて開発をする予定です。 gqlgenを採用した意図はいくつかありますが、特徴としてスキーマベースということがあります。
開発に入る前に、スキーマを定義し開発メンバーで叩き上げることで仕様の確定/確認を進めつつ、認識の相違を洗い出すことができると考えています。
本記事はその過程でGraphQLの仕様やスキーマのベストプラクティスについて調べた結果です。
調べたこと
https://productionreadygraphql.com/2020-08-01-guide-to-graphql-errors API内のログとしてエラーを表示することは問題ないが、クライアントへ送信するエラーはエラーコードで抽象化する デメリット メリット
- エラーに関する一貫性が生まれる
- ステージ２では、アドホックなエラースキーマを定義することでフロントの負担もあったが、この場合は必要としない デメリット
- エラーフィールドを選択しないことで、クライアントがエラーを完全に無視するのが非常に簡単なことGraphQLエラーのガイド
読んだサイト
自分なりの理解
ステージ１
ユーザーのデータをエラーとして表すことはできない。
→ステータスコードだけでなく、エラーコードの意味を決めて用いることによって、一貫性を保つことができる
トップレベルのエラーに出すべきなのは、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、２年生をメイン対象としたイベントだったので、計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位しか公表しないつもりだったのですが、僅差すぎたので急遽３位までを公表しました。
今回のハッカソンは評価項目として「技術力」はあまり見ておらず、「チームの工夫」、「挑戦度合い」、「成長度合い」などを重要視しました。
プログラミング経験が浅い学生をメインと対象としているため、このような評価基準にしました。中には、「技術力」、「完成度」をもっと見てほしいという思いを持つ参加者がいたかもしれません。
それは、学外のハッカソンに挑戦したいという自身の隠れた合図だと思うので、是非挑戦してみてください。
終わってから見えたこと
-
[反省]技術ヘルパー不足
今回は、圧倒的なヘルパー不足でした。個人的には、学生ヘルパーをたくさん準備するべき、むしろ余るぐらいに用意しておくべきだと考えていました。
しかし、思ったよりも企業の方々が技術ヘルプ可能と事前のアンケートに答えてくださったことで、結果的に数人しか学生メンターの準備をしませんでした。
(ここが痛恨のミス)
「学生の動く時間にヘルプできるのは、学生だけ」間違いなかったです。
考えられる対策
もっと事前に学生メンターを準備する
質問のルールをより詳細に決める
-
[反省]技術ヘルパーへの質問タイミング
これは今回最大のミスだったと思います。技術ヘルパーの質問受付時間を設けずに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、２年生の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に興味があるな という方には是非触ってみてもらいたいですね(「もっとココをわかりやすくしろ！」とコメントをいただきたいです)。
さて、明日のカレンダーは西川が書いてくれる予定なのでお楽しみに！
