react-bootstrapでWarning: validateDOMNesting(...): <div> cannot appear as a descendant of <p>
react-bootstrapでこのエラーに遭遇して対処法を調べたのですが日本語の記事が少なくて解決に時間がかかったのでメモとして残しておきます。
エラーの原因
コンソールには以下のエラーが出力されます
Warning: validateDOMNesting(...): <div> cannot appear as a descendant of <p>.
原因がわからずググってみたら、このサイトによると<div>タグを<p>タグでラップしているとこのエラーが起こるようです。
しかし、<p>タグを使っている箇所がない、、、
解決策
原因となっていたのは以下のコードでした
<Card.Text>
<Row style={{ clear: "both" }}>
<SelectButton
isSelected={selectedPictureList.includes(picture)}
target={picture}
selectedFunc={selectPicture}
unselectedFunc={unselectPicture}
/>
<PicturesCommentNewContainer pictureId={picture.id} />
</Row>
</Card.Text>
こちらのサイトによると、<Card.text>の出力は<p>タグになってしまうそうです。
その中のコンテナ(PicturesCommentNewContainer)でdivタグを返す処理をしていたので、エラーが起こっていたみたいですね...
<Row style={{ clear: "both" }}>
<SelectButton
isSelected={selectedPictureList.includes(picture)}
target={picture}
selectedFunc={selectPicture}
unselectedFunc={unselectPicture}
/>
<PicturesCommentNewContainer pictureId={picture.id} />
</Row>
このように、単純に<Card.Text>を使わなければエラーは無事なくなりました
bootstrapめんどい！
※この記事はqiitaから転載したものです
ハウテレビジョンのサマーインターン2020に参加してきて楽しかった
どーもです。前回の記事で書いたChatworkでのオンラインインターンシップに続いて、
株式会社ハウテレビジョンさんでのインターンに参加してきました。土日挟んですぐ次って感じだったので、ハードではありましたが、こちらはこちらですんごい楽しかったのでその記録を残したいと思います。
インターンの流れ
1. 応募するまで
エンジニアのサマーインターンを色々探していて、Wantedlyでこの募集を見かけました。前回のインターンと同様、魔法のスプレッドシートにも載っていました。ほんとこのスプレッドシート見とけばだいたい募集情報わかります。なんなんだこれは（笑）
内容は、実際に運用されている「外資就活ドットコム」に新機能を企画し、実装するというもの。期間は9/7〜9/14の一週間プラス一日で、最終日に発表を行います。参加賞は10万円で、なんと優勝チームには賞金でプラス10万円がもらえるとのこと。すげえ、、🤤
正直この期間に企画＆実装ってホントにできるんかなあ？とは思いました。ただ、いわゆるチーム開発「体験」ではなく、実際に動いているソースコードに触れそうだと思い、応募してみました。サービスの利用者も中々の数がいて、多くの人が利用するだけあって機能も多く、どうやって保守・運用しているんだろうとかを知ってみたかったんですね。
バックエンドにGoを使ってるそうで、触ってみたいなあとも思ってました。
あとなにより、このインターンはオフラインらしいとのこと。多分募集してたのは６〜７月で非常事態宣言が解除された直後だったので、相当攻めてますよね（笑）
でもインターンに行く前から、なんとなくオフラインのほうが得るものが多く良いだろうなとは確信していて、数少ないオフラインのインターンだったので応募しました。
2. 面接
結構あっさりめなESを書いてエントリーした気がします。色々応募しすぎて、だいたい書くことが毎回同じになるんですよね（笑）。
エントリーしたあとはいきなり面接でした。面接は１時間で、30分コーディング面接＋30分普通の面接でした。
面接にはエンジニアの方とPMの方が同席して、最初の30分のコーディング面接は問題を出されてリファレンス見ないでエディターに書いてみてーって感じでしたね。
問題自体は一応伏せておきますが、１０分くらい考えて思いつくような易しめな問題だったと思います。atcoderみたいな競技プログラミングやったことない僕でもいけたので、競プロやってる人には多分問題なく解けると思います。
そして残り３０分は書いたコードの説明と、いわゆる普通の面接ってやつです。
色々インターン応募した＆落ちまくったので、研究と長期インターンのことはだいぶ話し慣れたと思います
3.受かってからインターン当日まで
受かった後は、事前1day研修とのことで８月のうちに一度オフィスに集まります。
やっぱり、きれいなオフィスはテンション上がります。
六本木一丁目の駅の目の前にあるでっっかい森ビルの３２階にあって、東京中を見下ろせます（笑）
そしてこの一日で、インターン期間中なにをやってもらうか、 インターン期間までなにをやってもらうかを大まかに説明されます。
インターンの説明の後のほとんどの時間は、環境構築に費やされます。フロントエンドはReact+Redux, バックエンドはGoを使っており、どちらもdockerを使って開発環境の管理をしているのですが、なかなか複雑で実はよく理解しきっていません、、
事前に用意されてるシェルスクリプトを実行して、いろんなdockerイメージ持ってきて、docker-compose で色々動いてました（適当）
まあなんとか動かせたところで、バックエンドとフロントエンドのコードの解説的なのを聞きます。
バックエンドはクリーンアーキテクチャを採用しているらしく、責務の分断が細かくされていました。
ginというgoのwebフレームワークを使っていましたが、ginはrailsなんかと比べて軽めなフレームワークで、生のgoを書ければほとんど問題なく書けると思います。なんかこっちの方が自由度高くて僕は好きです笑
気になる方はこの辺を参考に。ほんとシンプルで書きやすいです。
とはいえ、goの経験は全くなく、インターン決定後にちょっと自学したくらいだったので、コードリーディングがめちゃしんどかったです。その上クリーンアーキテクチャで、ただのCRUD処理でも5、6層階層をまたいで処理が分けてあって、😐←こんな顔になってました。
なんですが、この時点で全てを理解する必要はないようです。というのも、インターン本番までに課題を与えられて、それをやっていくと少しずつ理解できるとのこと。ありがたいです。
そしてその日は終了し、事前課題に取り組みます。
外資就活に日記の機能を作ってみようという内容でした。やることは単純なCRUDの処理っすね。
直前までchatworkのサマーインターンに参加したので、そっちではscala書いて、夜には課題でgoを書くという刺激的な毎日でした。
ただchatworkのインターンの中で、ドメイン駆動設計とクリーンアーキテクチャをガッツリ教えてもらい、外資就活にもそれらが取り入れられてたので、「これあの時言ってたやつだ！」と進研ゼミ状態が続いておりました笑
4. ついにインターン初日
なんとか課題を終わらせ、インターン本番です。
初日は、やってきた課題の発表と作る機能の企画をします。
まずは課題の成果発表です。バックエンドコースの参加者と社員の方に、やってきたことを見せ合います。他の人は「Goとかクリーンアーキテクチャとかようわからんかった」と喋りながら、みんなちゃんと仕上げてきてレベルの高さを感じます。
そしてお昼をはさみ(くそうまい弁当だった)、いよいよチームに分かれて企画が始まります。
僕のチームは3人で、バックエンド2人とフロントエンド1人。
1人は小学校からPHPとかを触ってたような人で、もう1人は海外の大学でCSを専攻していてベンチャーとかでガンガンフロント書いてるような人。すごい人たちと一緒になってしまった(笑)。
作る機能は特に制約はなく、とにかく「ユーザーファースト」にこだわること、と伝えられます。
企画は、最初に時間とってみんなで付箋にアイディアを書きまくって、ホワイトボードに貼ってて似たものを集約していきました。発散→収束の流れですね。
やはり優秀な方達と一緒にやるとなんでもスピード感持ってできて、超楽しいです。
だいぶ色々なアイディアが出た中で、結構多めかつ良さげだったのが、「就活生同士の横の繋がり」に着目したものでした。
既存の機能で、外資就活コミュニティというものがあります。これは要は就活生の2ちゃんみたいなもので、不特定多数の就活生と会話できるというものです。
これはこれですごく面白くて、就活生同士でつらいことや嬉しいことなどを気軽に共有できるものです。(色んな機能の中でこれのアクセスが結構な割合を占めてるらしい)
しかし、あくまでこれはオープンな繋がりができるもので、その場限りの会話で終わってしまいます。そこで僕らは、就活生同士のクローズドでかつ深い繋がりを作れる機能が欲しいと考えました。
そして僕らは、グループを作成して承認制でグループに入ってチャットできる機能、「外資就活クローズドコミュニティ」(そのまま)という機能を作ることにしました。
例えば、ある企業のサマーインターンの決定者同士でグループを作って、インターンの前に仲良くなってご飯とか行けたら、インターン当日も楽しくなりそうじゃないですか？
そんな未来を描いて、一日目の企画を終了します。
2〜5日目(開発)
企画が終わり、いよいよ開発です。
といってもまずはDBと画面の設計ですね。
これまたドメイン駆動設計的な知識が少し活きて、まずどんな登場人物(ドメイン)があるかな？というところを考えました。進研ゼミより進研ゼミしてました。
細かいところは長くなるので割愛しますが、画面、テーブル構造は全員で話し合って大まかに決めたあと、APIのインタフェースをバックエンドで、画面の詳細をフロントエンドで作りました。(フロントエンドの人が初めてのfigmaだったのに爆速で作ってくれて神すぎた)
大体の仕様が固まったらもう、ひたすらに開発。
バックエンドの2人はgoが初めてだったので、最初はペアプロしてなんとなく一緒にコツを掴んでいきました。
今回そこまで複雑なDB操作を実装するわけでもなかったので、責務を何層かに分けるクリーンアーキテクチャの恩恵をあまり感じられなかったというのが正直な感想です笑
単一リソースのCRUDとかだと、いわゆる変数のバケツリレー的なことが起こり、「こんな色んなとこに値渡して何の意味があるん？」とか2人で愚痴りながらやってました笑
とはいえ、開発するにつれて、何の処理がどこに書いているか、という見通しが立てやすいと感じます。(APIリクエストのバリデーションをするなら、一番外側の層に書けばいいよね、的な)
これを分かっていると、自分以外の人が書いたコード、自分で書いたけど昔すぎて覚えてないコードに付け足していく際に開発しやすいですね。とてもクリーンですね。
クリーンアーキテクチャお馴染みのあの図の中で、今どこの層を書いているかを意識するとやりやすい気がします。
おなじみのコイツ(詳しくはこの辺を参考に→
そんなこんなで、あっという間に金曜日(発表は次の月曜日)になります。
ぜんっぜん、終わってません。笑
APIは一通り作ったんですが、フロントがなかなかしんどそうです。単純に1人しかいないし、react+redux sagaとか使っていて相当作業量多そう、、
僕も割とreact触ってたし、バックエンドのもう1人も結構やってるらしい。
もうこうなったら、3人でフロントやるしかないっしょ！ということで、3人がかりで片付けにかかります。
しかしこれを始めたのは、金曜の夕方あたり笑
満場一致で、土日もやることになりましたとさ。
そして迎える最終日
土日必死にやって、最終日を迎えました。
発表はお昼頃なので、それまでに発表準備を終わらようという算段。
なのですが、
フロントまだまだバグだらけ！！！
特に、APIとの結合が上手くいかない笑
一番大事なところがうまくいかずこれじゃデモも見せれない、、
しかし、時間だけはどんどん過ぎていきます。
チャット機能だけ辛うじて動くのですが、それ以外はほんとに動きません。redux sagaでうまくstateの更新ができないのです。(原因は今もわからないまま、、)
発表の1、2時間前になっても解決せず、結局APIと結合できなかったんです 😢
ですが発表は動いてるものが見せたいので、APIを全部モックに置き換えます（笑）
実は、フロントが開発しやすいように、API Blueprintというツールでモックを作っていました。ドキュメントを書くと勝手にモックサーバーになってくれる便利な代物です。
要は、毎回書いた通りに決まった値を返してくれるだけのハリボテです。DBは一切いじりません。
発表までの残り一時間ほどをつかって、作った8割以上のAPIは、モックに置き換わりました。（笑）
発表内容に関しては、僕とバックエンドの人もうひとりがバグ潰しとかしてる間に、フロントの人が大体準備してくれてました。神すぎる。ありがとう。
その人がプレゼンを作るときに使ってたCanvaというサービスがめっちゃイカしてました。テンプレートを選んで変えてくだけで、超カッケースライドが作れます。
そして発表。ここに関しても、フロントの人がだいぶ引っ張ってくれて、作った機能、なぜ作ったか、どういうところがユーザーファーストか、将来はこうしたい、などを伝えました。
動作デモも動くかドキドキでしたが、なんとかチャット機能とかは動いてくれました。モックで実装しているところは、あたかもデータが作られている体でゴリ押しました。笑
他のチームの発表も見たのですが、どこもめちゃすごかったです。特に、企業の雰囲気や給与などのデータを、グラフで見せてその企業の傾向などをひと目で見れる機能を作っているチームがいて、強すぎました。一週間でなんでそんなできるんや。
濃厚な1週間の成果を全チーム発表し終わり、役員の方々による審査で優勝チームが決まります。
結果は、、、、
優勝！！！！！！！！！
たとえ実装が終わってなくても、見せ方次第では上手くいくもんですね。（笑）
やはり、ユーザーファーストを意識している点を評価していただけました。
終わりよければ全てよしということで、無事にこのインターンを締めくくる事ができました。
感想
ベンチャーはやることが多そうだけど楽しそう
今回のハウテレビジョンという会社は、サービス自体はすごい勢いで成長しているものの、エンジニアの数はまだそこまで多くなさそうでした。おそらくこれからエンジニアの採用は増えていくものの、ある領域に特化していればいい、というより、やらなきゃいけないことなら得手不得手関係なくやる、という雰囲気でした（個人の意見です）。
結構僕はそっちのほうが楽しそうだなと思います。全員がいろんな箇所を知っていた方が、チームとしてはまとまって開発出来るような気がしています。しかも僕のようなまだ自分の得意不得意がわかっていない人なら、それを見極めたりエンジニアの総合力を上げたりするいいきっかけにもなりそうですしね。
チームメンバーがすごすぎた
ほんとにすごい二人と一緒にチームになれました。なんというか、二人とも思考のスピードがすごくて、何事も機敏にこなしていけました。開発に入ってからもすごいスピードで進めていけて、めっちゃ楽しかったです。
こういう優秀な方と一緒になると、すごいモチベーションになります。オフラインで実際あって色々喋るとなおさらです。このような刺激的な経験が出来るのは、サマーインターン特有のものですね。
オフラインで開発するほうが楽しい
このインターンの前の週までに行っていたChatworkさんのインターンはオンライン開催でチーム開発をしました。２つを比べると、やっぱり実際にチームメンバーと顔を合わせてやる方が断然刺激的で、楽しかったです。
オンラインだとどうしても、必要な時以外はコミュニケーションを取らなくなっちゃうんですよね。実際集まって一緒にお昼食べたり、雑談しながら開発したりする重要性を痛感しました。
お昼ごはんおいしかった
お昼は基本的にお弁当が出たのですが、どれもめちゃんこ高そうな弁当でした。
特に初日の叙々苑の焼肉弁当は、最高でした☺️
おまけ
チャット機能を作ってる時に生まれた、激ダサデザインがおもろかったので置いときます。
Chatworkのオンラインサマーインターンシップ2020に参加してきたよ
こんにちは。
8月中旬～9月頭の3週間でChatwork株式会社のオンラインインターンシップに参加してきたので記録を残そうと思いますー
オンラインでの開催は初の試みらしく、僕もオンラインのインターンシップは初めてだったので、不安な部分はありました。
しかし、めちゃめちゃ楽しかった＆勉強になりました。
インターンの流れ
参加するまで
LabBaseというサイトに登録していたら、スカウトをいただきました。
chatwork自体は知っていたし、scalaを使ってるとのことで触れてみたいと思いました。それと、1週間の講義＆2週間の実務というめちゃ充実の内容だったので、そんなにしっかりやってくれるところは中々ないだろうなと思って応募してみました。
研究のことや開発経験のことをプロフィールに書いておけば結構スカウトをもらえるので、院生とかにはLabbaseはおすすめです。(魔法のスプレッドシートなるものを見ておきさえすればいいという噂も)
面接は人事の方とエンジニアの方が同席し、2対1で行いました。
確か時間は1時間弱くらいで、最初に人事の方からいわゆる人事面接的な質問をされ、その後にエンジニアの方から技術的な質問をされました。
内容はあんまり覚えていません（笑）けどそんなに変わった質問はされた覚えもなく、めちゃゆるい雰囲気で喋りやすかったです。
どこの面接でもそうだと思うんですが、院で研究してたり個人で開発されてる方はなんでそれをしてるのか？を自分なりに考えていれば大丈夫な気がします（テキトー）
技術的なことに関しては、長期インターンでやってることを中心に開発経験を聞かれました。使用してる言語やFW、どんな機能作ったかとかです。おそらくすでに業務で開発したことがあるというところは評価していただけたのかなとは思います。
面接は一回だけで決まり、コーディングテストとかもありませんでした。面接した次の日にぜひ来てくださいというメールが届き、ほんとにいいのかな？とかちょっと思いました笑
参加決定後
インターンではバックエンドはScalaを使用するので、事前学習として「実践Scala入門」が配送されてきて、これを一通り読んできてとのことでした。入門といいつつなかなかのボリュームで、だいぶしんどかったです。
全然scalaを知らなかったので、match文ってなに？case classってなに？なんですぐOptionで包むん？みたいな感じでした。正直未だにふわっとしてる。
あと16インチのMacが届き、テンションがあがります。
1週目
そしていよいよインターンが始まります。
インターン中は基本ずっとGoogle meetをつないで行いました。
講義を受けるときはコメントで色々茶々入れながら聞けるのがいいですね。やっぱりオフラインの講義でその場で手を上げて質問するって中々抵抗あって、疑問に思ったタイミングでその都度コメントしたほうが聞きやすいです。話す側も非同期的にコメが溜まっていくので、その場で話を止めなくていいですし。
1周目は講義パートですが、講義といってもすごい実践的。
ソフトウェア開発の基礎、チーム開発のことを教わったり、実際に手を動かしながら(僕はバックエンドコースだったので)scalaを学んだりで盛りだくさんです。
特に最後の講義の、ドメイン駆動設計のお話が一番聞けてよかったです。後の実務パートで活きてきます。
運用のお話などもあり、chatworkがないと仕事が出来ない会社も多くあると聞きました。そのためちょっとでも障害が出て止まったりするとYahooニュースに載っちゃうみたいですね…
ただそれくらい社会インフラの一部になっているサービスを開発できるのは、相当やりがいがありそうです。
2週目
2週目からはいよいよ業務パートです。
2チームに分かれましたが、僕のチームバックエンド3人フロントエンド2人でした。
社員の方がスクラムマスター兼プロダクトオーナーになって、最初に1週間でやるタスクを決めて、開発して、週の最後に振り返るという感じです。
今回は既存の掲示板アプリが用意されており、そこに「お気に入り機能」を設計して実装するというのが主な目標でした。
最初は設計なのですが、今まではいざ設計しようとなると、画面こんな感じかなーって考えて、それに合わせてテーブル定義して、みたいな感じでした。が、チーム開発ではそういうわけにはいきません。
これでは、後に変更や機能追加を行う際にどんどんカオスになっていきます。チームで開発するとなるとなおさら、個人間で解釈が違ってしまうことが多発します。
それを防ぐために、ドメイン駆動設計の考え方を導入し、ドメインモデルの定義をしました。（ドメインモデリングというやつ）
ドメインモデルとは何か？というのが捉え方が難しいのですが、個人的には
「ある問題を解決するために必要な登場人物」
「組織内でその登場人物の名前や振る舞いの共通認識を決定すること」
になるのかなあと。
ドメインモデリングをすることで、エンジニア間だけでなく、組織全体で共通認識や共通言語（ユビキタス言語という）が決まり、そのドメインを使ってどのように問題を解決していくかを共有することが出来ます。
詳しいことはここらへんの本読むと良いみたいです。
あとかとじゅんさんの資料なども参考に（めちゃ重めです）
- ユーザー
- スレッド
- メンバー
- メッセージ
- お気に入り
があたり、振る舞いとしては
- スレッドはメンバーを持つ
- メッセージはスレッドに投稿される
などなど…
元々用意してあるアプリには、お気に入り機能以外はすでに実装されていたので、お気に入り機能のドメインモデルをチーム内で話し合いました。
まあけど、チームメンバーはみんなドメイン駆動設計なんてしたことなく、初めてのことばかりでした。
そもそも、ドメイン駆動設計で出てくる単語が多すぎる（笑）。エンティティ、リポジトリ、値オブジェクト、集約、境界など‥
しかしメンターさんや社員のサポートもあり、なんとかやってみました。miroという、オンラインで付箋を貼れるサービスを利用して、みんなで色々書きまくりました。
オンラインだとやりにくいところはあるんですが、こういうサービスがあるとすごく進めやすくていいですね
そしてある程度全員で認識を揃えたらいよいよ開発。
僕らのチームのバックエンド担当３人はscala経験者がいなかったので、基本画面共有しながらモブプロって感じでした。
そして一週間の最後にスプリントレビューを行います。最初に計画したタスクをどのくらい達成できたか、このスプリントで何が良くて何がビミョーで次はどうしたいのか、などをきっちり振り返ります。
確か一週目は、計画した半分も終わらなかった気がします （笑）
3週目
３週目は2週目と同じ感じです。一週経験すると、タスクの見積もりも少し精度があがり、ちょっと慣れてきます。
ただ開発してるとどんどん「この設計じゃまずくない？」なことが起こり、その都度話し合って修正して、とやってるとすぐ時間が溶けていきました。
ドメインモデルの関係を意識しすぎて、フロントがクソ使いにくいAPIレスポンスを作っちゃったりして、ごめんなさいになりました。（リードモデルとドメインモデルは区別する必要があった）
結局全部終わらせることは出来なかったですが、なんとか動くとこまではもっていけました。（というか、そうさせてもらった）
masterブランチにpushされるとcircleCIが走ってデプロイされるんですが、最後だけ無理やり違うブランチを社員の方にデプロイしてもらいました。yu_shu_no_bi（有終の美）ブランチとかいうふざけた名前のブランチを動かしてもらって、ちゃんと動作してめちゃ盛り上がりました（笑）
感想
ドメイン駆動設計わからん
DDDを実践してみたものの、まだまだわからないことだらけです。
ただ、DDDの第一人者的な人であるかとじゅんさん（@j5ik2o）をはじめ社員の方々は、完璧な正解や教科書が存在するわけではないので、やりながら学んでいくしかないとのこと。それもそのはず、DDDはあくまで設計なので、解決したい問題によってチームで議論してアプローチを決定していく必要があります。
特に集約の決め方がむずいです。今回で言うと、「お気に入り」というドメインはどこに属するのか。ユーザの集約に持たせるのか、メッセージの集約に持たせるのか、というところで詰まりました。
一般的な集約の基準としては、「集約元が更新されるときには同じタイミングでそれも更新されてほしい」かどうかというところらしいですが、多分どちらも間違いというわけではないんですよね〜
いろんなエンジニアの方から聞きますが、アーキテクチャや設計は「正しさ」よりも「決めること」の方が大事なようです。スピード感を持って決めてしまって、変更の必要があるときになったら変える。Done is better than perfectってやつですねー
あとドメインの振る舞いを考えるときは、受動態で考えると良いと教えていただき、なるほどなあってなりました。
無生物主語が日本語だと違和感があるので、「AがBをCする」を考えると大体「A=ユーザー」になっちゃうんですよね。そのため、「BがAによってCされる」と考えるとBがドメインとなり、振る舞いをコードに落とし込みやすくなります。
これぞオブジェクト指向。すげえー
オンラインでモブプロむずい
モブプロもオンラインだと難しいですね。オフラインなら一個のPCをかわりばんこで使えばいいですが、「こここう書いたほうがいいんじゃない？」的なことがオンラインだと非常にしにくかったです。
ただその分、自分の考えていることややりたいことを的確に伝える訓練にはなったと思います。 しかもモブプログラミングの心得の一つに、「ドライバーが勝手に進めてはいけない」というのがあって、全員の認識を揃えながらすすめるにはオンラインの方が効果があるなあとも思いました。
モブプログラミングはみんなで考えながらコードを書いていく分、モブプロ中の開発効率は確実に犠牲になります。全員の理解を揃えるところに狙いがあるので、その犠牲を払っていることを全員が十分に理解しないとですね。
チーム開発楽しい
なによりこれです。他のサマーインターンでも思ったことですが、みんなで「こういうもの作ろう！」と決めて、全員でわいわい開発していくのは本当に楽しいです。 チームのメンバーがめちゃめちゃ優秀な人ばかりでだいぶ頼っちゃいましたが、その分刺激も得られて超楽しかったです。
インターンはオフラインがいい
正直、オフラインで出来たなら絶対そっちのほうが良かったです（笑）
短期のインターンに行く意味って、一番は体験が得られるからだと思うんですね。なのでその体験を余すことなく享受するには、実際のオフィスに行って、チームで一緒のディスプレイ見ながら開発して、というような物理的な体験が必要な気がしました。
あとやっぱりきれいなオフィスいくとテンションあがりますしね（笑）
あとあと、去年のインターンに参加された方がメンターとしてついてくれたのですが、全員「オフィス近くのご飯がめちゃうまかった」と言っていたので、食べたかったなあーー
まとめ
3週間めちゃめちゃ良い時間過ごせました。知らない人とチームになって短期間だけで開発するというのは、後にも先にも中々できない経験だと思うし超楽しいです。楽しい上にすごい量の知識をインプットし、実践できる機会なんてホントに貴重です。
あと、オンラインだと中々物理的な会社の雰囲気はわかりにくかったですが、社員の方々の雰囲気が優しくて気さくな方ばかりでした。「働くをもっと楽しく、創造的に」というミッションを掲げている会社だけあって、それを体現している人が集まっているんだろうなあという印象です。今度オフィスツアーに行けるらしいので楽しみです。
他の会社のインターンなども行きましたが、やっぱりエンジニアは楽しそうです。楽しいだけじゃないと思うけど、きつくてもやっていたい仕事だなと思います。
どこで働くことになるのでしょ〜
追記
一緒に参加した人のブログ
オフィスツアー行ってきた
11月にオフィスツアー行ってきて、インターン生と社員の方々とオフ会をしました（笑）。
3週間顔を合わせていたものの、あくまでmeetの画面上だったので、「ほんとに存在するんだ、、」と口々に言ってました。
そしてオフィスがキレイでした。めっちゃ広いってわけじゃないですが、バーカウンターとかあって働いたら楽しそう。
あとエンジニアの業務スペースを見てみると、めっちゃ高そうな椅子とか作業環境が充実してて羨ましいっす。
オフィスは東京タワーの目の前にありました。
オフィス出て道路を挟んだ向かい側に東京タワーの入り口があります笑
東京タワーを見ながら美味しいご飯とお酒をいただいてきました😉
