ラボアプリをReactで作るモブプロ体験
この記事はラボアドベントカレンダー 4/30分です。
https://gw-advent.9wick.com/calendars/13
相変わらず投稿日時がアレですが見なかったことにしてください。マジですみません。
さて、先日erukitiさん主導のラボアプリ開発に参加してきました。
erukiti先生のデキるエンジニアとしての感想は以下です。
以下は、Reactなんも分からん、クリーンアーキテクチャもなんも分からん、ただ運用上の問題点には少しだけ敏感かもしれない、よわよわエンジニアの私から見たモブプロの感想です。
4/29
前日にFORTEさんとerukitiさんとで大まかな要件は決めていたとのことで、この日から実装を開始しました。
参加していたのはerukitiさん、FORTEさん、私。FORTEさんと私がReactにあまり詳しくないため、erukitiさんがドライバーとして環境構築部分を説明しながら進めてくださいました。
私のReact知識は大岡さんの「りあクト！」初版を一読した＋ドットインストールのReact動画を見た＋Gatsbyブログを動画に従って作った、くらい。またソフトウェア開発全般の知識としても、まっさらの所からソースを書いていく経験が独学以外ではほぼありませんでした。
そのため、普段Reactを書いている人がどんな事を考えながら実装されているのか聞きながら、本で読んだReactの知識が実装されていくのを見るのはとても刺激的な体験でした。
また、分からない事を分からないと言って良い場である空気を先輩2人が作ってくださったおかげで、気楽に質問することができました。
具体的に何だったか思い出せないのですが、erukitiさんが何気なく使った言葉の意味について、FORTEさんが「それは○○という意味であってますよね？」と質問されていたのが印象的でした。
結果的に3人共理解は違っていなかったのですが、揺らぎの余地がある言葉はこうやって適宜すり合わせていく必要があるなと再認識しました。
4/30
私は途中で別用があって抜けてしまったのですが、抜けるまではクリーンアーキテクチャについての議論がメインになっていました。
正直な所質問するためのベース知識が無い状況で議論が進んでいたのは苦しかったのですが、なんとか適宜分かる言葉に翻訳して貰いながら進めました。
議論がどうにかまとまりコードを書く段では、VSCodeのショートカットや画面配置の方法、コミット時に差分確認する方法など色々と知る事ができました。この辺り、実際に使っている人に教わらないとなかなか知らない所が多いというのは本当にそうですね。
また、ずっとCUIでgit add... git commit -m... git push origin master...とやっていたのですが、VSCodeの機能でよろしくやってくれる方法を教えていただき、感動しました。
ずっとやっていなかったGithubとのSSH接続も先輩エンジニアの助けを受けながら設定完了しました。
2要素認証はまたいずれやります。
まとめ：2日経験して
新米エンジニアであれば1度は経験しておくべき！ と断言できるくらいに良い学びの時間になりました。
先輩エンジニアが何を考えて実装するのかをライブで見る事ができるだけでももちろん学びは深いのですが「自分ならどうするか？」考えながら口出しをする事も恐れずにやることで、その考えが合っているか間違っているか、どうしてそのように判断するのかなど、より濃密に学ぶことができます。
技術に関しては独学で学ぶことも不可能ではないですが、モブプロで得られるメインの学びは知識ではなく知恵ですね。
自分はGW中は同席してのモブプロはできないのですが、この後VSCodeの拡張でリモート環境でもライブコーディングができるということで、環境セットアップ予定です。
また折角の機会を頂いたので、やはりVueよりReactを勉強したいですね。今度自分のGatsbyブログの実装を一緒にやってくれる人を募集とかしてみようかな。
ひとまず、「りあクト！」第二版を読んでこよう。
転職活動ふりかえり
この記事は、challenge-every-month全員でアウトプット芸人 Advent Calendarの3日目記事です。
https://gw-advent.9wick.com/calendars/9
実は参加しております。その振り返りもまたいずれ。
投稿日がおかしいなんてことはありません。気のせいです。きっとね。
2日目はzakiさんでした！
さて私、先日、長かった転職活動を終え、内定を頂くことができました。
既に内定承諾、退職相談をしており、入社準備を進めている所です。
今回は退職エントリでも入社エントリでもなく、
全く上手くいかなかった自分の転職活動経験を、時系列順にいくつかピックアップして語ってみようと思います。
まとめ
以下、散文的にふりかえりをしましたが、まとめると以下の通りです。
- 人に会うのが最高のソリューション
- ポートフォリオより継続学習
- 転職意思は内定が出てから伝えよう
転職前半
2018年9月頃 何社か選考
転職しようかな、と漠然と考えてアクションを起こしたのは、2018年9月でした。
この当時はエージェントの評判が悪いことなど知らず、とある会社のエージェントと会いました。
何社か紹介を受け、3社程面接を受けましたが、いずれも落選。
いま思うとこの時の私は「なぜ転職なのか？」という質問に答えられない状態で「技術を身に着けたい」と話していました。
ポテンシャル採用という言葉も知らないような状態で面接を受け、第一線で戦えるエンジニアと競り合えるわけがありませんでした。
またよく言われるようにエージェントとのマッチングが悪く、以後の転職活動で相談をすることはありませんでした。
2018年11月頃 秋の夜長の自由研究LT
「エンジニアの登壇を応援する会」のイベントで、登壇者として発表しました。
今振り返ると拙い所も多いのですが、初の社外登壇の場として良い経験となりました。
ここで得た度胸、自分の考えを実行に移すための考え方は、この後の転職活動に大きなプラスになりました。
2019年1月頃 Djangoでポートフォリオ作成
正月からポートフォリオサイトを作っていたのですが、これは時間掛けすぎました。3週間くらい掛けてしまったのではないかなと。
今思うとポートフォリオはもう少しシンプルな実装にして、アプリ開発に時間を取るべきだったなと思っています。
そしてそれより何より、自己分析や自己学習にもっと時間を割くべきでした。
成果物になっていなくとも、Githubの草を生やし続ける事の方が大事ではないかと、今なら思います。
ポートフォリオや自作アプリで勝負しようとするのは、そもそも今のスキルが実務で通用する人の振る舞いではないでしょうか。
そうでない人が伸び代として示せるのは、Githubの草を継続的に生やしているとか、現在学んでいる技術について説明できるとか、何かしらの資格を取るとか...といったもののように、今では思っています。
もし作ったアプリがウルトラCとして優れていても、今度は高いスキルを期待されるわけで、ミスマッチでしかありません。
2019年1月末
知人の会社のカジュアル面談に始まり、面接を本格的に受け始めました。
1週間に3社程受けた時も。
ろくに準備もできないまま面接に行ってお祈りされるのは心が軋む音がしました。
次があったら面接は週に1回、と決めたいと思います...
しかし数を打っている間に、企業選びの規準などが明確になってきたのはこの時期だったように思います。
2019年2月
選考が進んでいた企業で「内定貰えそうだ！」と根拠もなく信じ、3月末で辞める旨、現職の上司に伝えました。
結果的にその時考えていた企業からは落選してしまい、他社でも3月末時点で内定は出ておらず、約束通りの時期に退職することはできませんでした。
最初の転職でただでさえ色々と慣れないストレスを受けている中で、デッドラインを作ってしまったのは失敗でした。
転職意思を早めに伝えた事による、メリットらしいメリットはありませんでした。
2019年2月初め
kiitok、nitt-sanのいきなり1on1、知人の紹介で出会ったエージェントの方など、色々な人と出会い知見を溜めた1ヶ月でした。
この時お会いした方、特に転職エージェントの方には大変お世話になりました。
自分の転職活動におけるアクションに11月の自由研究LTを加えたのは、「エンジニアの登壇を応援する会」に深く関わっていなければ、出会う事も知り合う事も無かった方々だったと確信しているからです。
ただでさえITエンジニア界隈では転職エージェントの評判が悪く、かついくつか実例も見てきたので、転職エージェントを使いたくない気持ちは凄く分かります。
その上でなのですが、最初の転職を誰にも相談しないで進めることは不可能に近いなと今なら思います。
エンジニアの登壇を応援する会Slackでも時々、職務経歴書のレビューをしている光景が見られます。
2019年3月
転職エージェントの方が敏腕で、自分の職務経歴書や面接での受け答え、企業選びなど全て見直しに入り、適宜修正しました。
その上で新たに第一志望の会社も生まれ、面接対策を受け、最後には人脈にも助けられて、内定を頂く事ができました。
最後に
私が転職活動中、お世話になった方々に感謝します。
エンジニアの登壇を応援する会の皆々様、
親身に相談に乗ってくださったエージェントのKさん、
会社の先輩、同僚、全ての方々に感謝します。
これをスタートとして、これからのエンジニア人生やっていきしたいと思います！
さて、アドカレ4日目はないぱかさんです。ぜひご覧くださいませ！
学びを結果に変えるアウトプット大全 読んだ
https://www.amazon.co.jp/dp/4801400558/ref=cm_sw_em_r_mt_dp_U_bfPECbCDV2AJT
この本を読みました。 エンジニアの登壇を応援する会の@ariakiさん、@motto2さんから強いオススメを受けたので手に取ってみたのですが、凄い本でした。
感想
アウトプットを始めている人も、まだできていない人も、総じて読むべき本ですね。
端的に言うとガンガンアウトプットすべし、その方法論は用意した！ っていうカッコイイ本。それでいて「自分でもできる」と思わせる本です。
筆者の方は毎日Youtube動画やメルマガ、ブログでアウトプットを続けており、それをさせるだけの凄まじいインプットを進めています。それでいて、我々と同じ人間が、常にロジックとテクニックによって実践されている事がわかります。
特に、「アウトプットのためならばインプットを減らしても良い」という考えは自分にはありませんでした。まだまだアウトプットに対する考え方が甘いと思い知らされます。
あと「アウトプットするまで次の本を読むべきではない」という記述があり、慌ててこの記事を書いています。
今読みたい本が何冊も詰まっているのですが、アウトプットせずに次の本に手を伸ばしてしまうと...って事ですね。
これ勉強会でも同じですね。最近勉強会参加記事とか書いてないな、と反省させられました。
気付き3つ
- 読書やセミナーからは気付きとToDo3つを持ち帰ること
- アウトプット:インプット＝7:3、アウトプットを増やすためならばインプットを減らすことも厭わない！
- 継続するためのテクニック。5分でいいから始めること、15分でいいから時間を取ること、毎日記録をつけること。
ToDo3つ
GatsbyJS製ブログをNetlifyでbuildしたら3度失敗したのでその知見
こちらの動画を参考に、GatsbyJS＋ContentfulというHeadlessCMSを使ったブログを開発しました。
ぶっちゃけ作るだけならそこまで労せずでしたが、動画に書かれていない先、
Netrifyへのデプロイで3度詰まったので覚書を兼ねて記載。
アクセストークンの指定漏れ
問題：TypeError: Expected parameter accessToken
結論：開発環境なら.envで指定するアクセストークン、当然Netlifyにも教えてあげなきゃ駄目です。
特に行き詰まったというよりそりゃなって思った内容ですが、載せておきます。
セキュリティのためCMSへのアクセストークンは環境変数に指定すべきですが、
NetrifyのWebから環境変数を指定する場合の起動経路は以下。
Settings > Build&Deploy > Build environment variables
ファイルシステムが無い
問題：The path passed to gatsby-source-filesystem does not exist on your file system:
結論：指定していたディレクトリblogが、cloneしたばかりの時にMarkdownを全て消したため、Githubにpushされていませんでした。
gatsby-config.jsに書いたgatsby-source-filesystemプラグインに渡している引数としてのファイルシステムの指定が存在しないと言われている。エラーログを読む癖がある私はすぐに分かりましたとも。
いや待って、私そこイジってないよ？
{
resolve: `gatsby-source-filesystem`,
options: {
path: `${__dirname}/content/blog`,
name: `blog`,
},
},
clone元のソースからイジってないし、イジる必要があるとも思えない。
開発環境では動く。
でも無いというからには無いんだろう、と思ってGithubを見に行くとblogディレクトリ、確かに無い。
.gitignoreに書いているわけでもないのに何で？ と首を傾げましたが、どうやらgitは空のディレクトリは管理しないらしい。
管理させたい場合は.gitkeepというファイルを作って該当ディレクトリに入れるのがスタンダードだと。
Netlify関係ないし知ってる人なら知ってそうですが、とりあえずNetlifyで詰まったポイントなのでここに書きます。
プラグインの中のGraphQLが実行できなくて怒られる
問題：
8:01:17 PM: error Plugin gatsby-plugin-feed returned an error
8:01:17 PM:
8:01:17 PM: Error: Cannot query field "allMarkdownRemark" on type "Query".
8:01:17 PM: GraphQL request (3:9)
8:01:17 PM: 2: {
8:01:17 PM: 3: allMarkdownRemark(
8:01:17 PM: ^
8:01:17 PM: 4: limit: 1000,
結論：gatsby-plugin-feedは現在の私には用事が無いので外しました！
gatsby-plugin-feedは、motto2さんの記事によるとRSSを作成する責務を持つプラグインです。
mottox2.com
直近では使わないと判断したため、gatsby-config.jsからコメントアウト。
というわけでデプロイに成功しました。
この後改造していきます！
Djangoで作ったポートフォリオをHerokuで動かそうとしたら行き詰まったポイントまとめ
最初に
1月頭からポートフォリオサイトを作っていました。Django製。
dassimen-portfolio.herokuapp.com
本名とか顔バレとか今更気にしない。
Djangoの機能をフルに活用した気持ちはあんまりしないのでまだまだなのですが、それなりに苦戦したので、それらの知見をまとめてみようと思います。
デプロイしても動かない
DjangoGirls始め、DjangoをHerokuにデプロイする方法は世の中に幾つか出ていますが、各情報で書いてある事が違いすぎます。特にWhitenoise周りの設定とか書いてる事違いすぎて発狂しそうですね？
少なくともDjango 2.1.5をお使いの方は、以下に纏まっている手順を順番に実施しましょう。
https://www.djangobrothers.com/blogs/heroku_django_deploy/
その後、settings.pyを開いてALLOWED_HOSTSを変更してください。
こちらは公式ドキュメントにて、Debug=Falseの時はALLOWED_HOSTSの値を以下のようにせよとの記述があります。
When DEBUG is True and ALLOWED_HOSTS is empty, the host is validated against ['localhost', '127.0.0.1', '[::1]'].
ここまでやっても、Debug=Falseの時に最初のロケットが飛ぶスタートページが表示されない事でデプロイに失敗したと思われる方もいるかと思います。私自身そうでした。
何か適当なindexページを実装してみてherokuにデプロイしてみれば、indexページが表示されますので、お試しください。
ロケットのページが表示されない理由については、この時相談に載ってくれた @tetsunosukeさんが記事にしてくれました！
画像（ファイル）がアップロードできない
ImageFieldを使って、Django Model経由で画像やファイルをアップロードする機能を実装されようとしていますか？
これはDjangoに限らないのですが、Herokuの仕様でHerokuだけではそういった機能は実装できないようです。
実際には実装はできるのですが使い物にならない、というのが正しい。
Herokuのファイルストレージはデプロイされた状態を維持するような仕様になっています。
これにより、アップロードされた画像が保持されないという問題が発生します。
AWS S3やDropboxといった外部ストレージを別途用意してアップロード先にすることで解決するようなのですが、自分は上手く設定できなかったのでImageFieldの使用は諦めました。
急に500で落ちるようになる
Djangoのデプロイに成功して機能追加を繰り返していった時、あるタイミングで急にheroku環境でのみ500が発生するようになりました。
ローカルでは再現しないため環境変数周りか、本番用のsettings.pyを疑ったのですが、どうにも見つけることができませんでした。
少なくともコードを一切変更せず、Herokuで別環境を立ててpushすると動いたので、環境変数或いはライブラリの問題であった可能性が高いです。
同じような事象が発生して調べても調べても解決が無ければ、別環境に改めてデプロイし直すのも手という話。
まとめ
- デプロイするための情報はある程度一箇所に集まっているよ
- Heroku（だけ）で画像アップロード機能は実装できないよ
- DjangoアプリをHerokuにデプロイすると謎に動かなくなる時があるよ ちなみにデプロイし直すと治るからソースじゃないよ
kiitok受けて来た
噂のkiitok面談受けてみましたので、感想をざっくばらんに書きます！
担当メンター: 湯前さん
面談日: 2019/02/04 21:00
面談受ける前
転職を始める事は決めていたので、転職について相談しようと考えていました。
しかし転職について漠然とした悩みはありつつも、何を質問として持っていくかはあまり固まっていませんでした。
３年間IT企業で働いてきたが、保守経験のみ。製品知識であれば答えられる。あるべき運用の形などを考えることはできる。しかし技術力が圧倒的に不足している。
文系卒のため、ITの基礎知識が不足。
だからスキルアップのため転職したい。
悩みとしては、多分すぐには戦力にならない。自分の成長速度を高めるために何ができるか。何ができるとアピールすればよいか。
事前メモにこんなことを書いていたので、多分こんな事を冒頭で伝えたように記憶しています。
面談の内容
転職にあたって興味のある分野はどこなの、と聞かれました。
自分はAR・VR領域にかなり興味関心があるのですが、高校数学が上手く行かずに文系に行った事を考えると難しいかもしれないと考えている事を話しました。
そして難しさを突破できるほどの情熱を持っているかといわれると今現在はそうではない。多分そういった情熱は長期的にどうなりたいという目的、ゴールがはっきりしていると持ちやすいと思うのだが、今そういうものもない、と伝えました。
そうした所、中長期的に考えるのが苦手なら、目の前の興味あることについて全力で突き進んでみるのも良い、というアドバイスをいただきました。
また中長期的なゴールからの逆算思考には、外乱があると狂ってしまうというデメリットも存在する事を教えていただきました。
また転職先については、沢山調べた上で自分にあう企業文化を探す事をおすすめされました。
転職先にアピールしていくためのアウトプットの増やし方についてもアドバイスいただきました。OSSのissueを挙げたり、PRの出ているソースを実際に自分で使ってみたり、翻訳を手伝ってみたりなど、私でも出来ることで参加していく意義を学びました。
終わってみて
あっという間の40分で、転職について何をするのかは何とか掴めました。
目標設計の話を振り返ると、世の中トレードオフの関係であることは理解していたつもりなのですが、どうもやはり一般的に良いと思われるもので自分ができないことは、良い側面しか見えなくなるなと思った次第。
今回は転職についてでしたが、仕事や勉強、普段の成長についてざっくばらんに相談に乗ってくれる人が居てくれるととても心強いなというのは、今回ならずとも少し前から思っています。
有料化しても月額1万くらいだったらペイできそうですよねえ。
まだの方はぜひ申し込みだけしときましょう！
私が今年のセイチョウをいまいち誇れない理由（ワケ）とその対策
この記事は#セイチョウ・ジャーニー Advent Calendar 22日目の記事です。
21日目はUdomomoさんでした。
三行まとめ
成長振り返ったら何か上手く誇れない気がする
予め目標設計してないせいじゃね？ と仮説立てた
来年はPDCAサイクルを回す習慣付けを目標にするぞ
3ヶ月振り返ってみて
色々な所で話していますが、
私がエンジニアとして勉強を開始した、といえるのは今年の9月からです。
今日までの3ヶ月で、2018年は大きな躍進した年でした！ ...とは言えない気がしています。
相変わらず勉強は独学で進んでないし、転職はしてない。
2019年には開発者をやっている予定だったのですけどね？ おかしいなあ。。。
3ヶ月あれば、人によってはProgateとRailsチュートリアルを終わらせて転職する人がいるだけの時間でしょう（それは相当スゴイ事だと思うのですが）。
3ヶ月でやれた事で主なトピックは以下でしょう。
・初の社外勉強会参加
・初のインプロWS参加
・初の社外登壇
・社内の勉強会企画とファシリテート
・エンジニア仲間を激増させた（トキワの森プロジェクト、エンジニアの登壇を応援する会に参加）
またこれらの出来事を通じて、以下の事ができるようになった（自己評価）と考えています。
・他人に思っていることを伝えることができるようになった
・（多少）技術の話ができるようになった
・自分が何を望んでいるか考えて、実践できるようになった
間違いなくやれてよかったことだし、間違いなく成長しています。
しかし、これらの成果を持って私は成長を誇れる気になれないのは何故でしょう？
セイチョウとはなんだろう
広義における成長ではなく、私が胸を張ってセイチョウを誇るためには何が必要でしょうか。
2018年9月1日の私と、2018年12月22日の私とでは、前項で書いた通り色々な変化がありました。
これを持って成長していると評価されることに違和感はありません。
「ある時点でできていなかったことが、できるようになった」
これは間違いなく成長でしょう。
じゃあなんで誇れないのか、と仮説を立てたのですが、
予めこうなりたい、という目標設定をしてこなかったため、
何かできるようになっても、それ自体は素晴らしい事であっても、
「たまたまできるようになった」という感覚でしかないのではないかと考えています。
私は計画立てるのがくっっっっっそ下手で、
立てたとしてもどこにも残らずに失くしています。
毎年1月1日にも何かしら目標立てていた気がするのですが、
全くどこにも残っていません。
行動の結果得た成果は素晴らしいものと胸を張って言えますが、
成果を狙って行動できていたわけではないことが、私がセイチョウを上手く誇れない理由かなと思っています。
来年どうしたいか
目標設計から始まる、PDCAサイクルを身につける事を1年通しての目標としたいと思います。
勿論、技術の勉強や転職活動だって目標になるのですが、1年通しての目標はPDCA習慣をつけること。
これがあるのと無いのとでは、この先10年、20年のセイチョウ幅は大きく変わる事と思っています。
今年は行動できるようになった。Doができるようになった。
結果として、CheckのためのPlanがそもそも無いことに気付けた。
であれば月初めに必ずPlanを立てて、月の終わりには目標が達成できたかちゃんと振り返る！
これを繰り返して、この先ちゃんと続けられるようにする。
これが達成できたかどうかを来年のアドカレで振り返る。
ちゃんと記事として残しておけば、ブログがちょっと途切れる事があっても「果たしてこの目標が達成できたか？」という問い掛けで、目指す所までセイチョウできたか、できないとしたら何％程度か、測ることができるでしょう。
謝辞
成長について、なんていうテーマで考えた事は人生でほぼ無かった。
その機会を作っていただけただけで、GrowthFactionの方々には感謝しかなく。
またトキワの森プロジェクト、エンジニアの登壇を応援する会のメンバー方、いつもお世話になっています。来年は私から何か返せるよう、引き続きWin-Winでいられるよう努力します。
来年の私と私の回りの人々が、今日より幸せであれかしと祈りつつ。
