世界、国内、個人的にも激動の1年が終わろうとしています。早いものです。
先月分はこちら -> じぶん Release Notes ver 0.31.0 - ざきの学習帳（旧 zackey推し ）
この記事はwrite-blog-every-week Advent Calendar 20201日目の記事です。
今年の9月から副業を始めました。始めた経緯や理由は以下記事に記載しています。
この記事では、実際にやってみて良かったこと、悪かったことをエンジニアとしての経験やプライベート等々、振り返りながら分けずに記載していきます。
副業先で求められる成果を果たすことが第一ですが...自分の場合は、現職と副業でVue.jsという同じ技術を使っていることにより、現職を通して感じた自分の知識・技術的な課題を副業先で実践し、血肉にできた場面が何回かありました。
例としては、以下のような内容です。
これらは個人開発でもやろうと思えば実践できます。
が、自分は個人開発に対してそこまでのモチベーションが湧かない（もしくは、あくまで勉強だから...という理由に逃げ、頓挫してしまう）ため、副業という成果を求められるものに頼り、強制的に成長する機会を得ています。
副業をこなすと、報酬をいただけます。
「報酬が発生する＝お金がもらえる」という考えから手抜きを許さず、成果を出そうと自分を戒めることができます。
私は、個人開発や写経だとたるんでしまいがちです。成果を出さないといけないという縛りをつけることで、現職・副業にまつわる勉強に締まりが出たと感じています。
私の副業先は前職なのですが、また一緒に仕事ができて嬉しい...というのが本音です。
前々職以前は業務形態等々の関係で、人とのつながりをあまり持続できていませんでした。しかし、前職のみなさんは肯定的に自分の副業を受け入れてくれています。
以前関わった人々とプロダクトに貢献し続けられている
このことが個人的に一番嬉しくて、楽しいことです。
継続が難しい状況にならない限りは、副業を続けていこうと思います。
当然ですが、平日業務後や休日の時間を副業に割り当てるため、遊びの時間が減りました。
COVID-19の影響も少なくないですが、週末は副業に時間を割く必要があり、外出（とくに遠出）する機会も減りました。
が、副業を始めた目的である成長機会を得ているので、この辺は仕方がないかぁ...と思っています。
副業で収入が増えるのは良い事柄の1つですが、代わりに請求書提出、確定申告等の手続きが増えます。
来年は青色申告を行う予定です。
電子で完結したいがために、以下を行いました。
屋号登録や口座登録有無等、まだまだやることはあるのですが、とりあえずここまで。あとは確定申告手前になったら考えようと思います。。。
ずーっと積んでいたカイゼン・ジャーニーを読み終わりましたので、気になったところ等々をメモします。
手に取ったのは「チームやプロジェクトで問題にぶち当たったけど、それは自分だけの問題？それともチームの問題？」ってのがわからなくなり、その答えを見つけたいという理由からです。
ストーリー仕立てでプロジェクトの改善を推し量っていく手法や立ち向かう問題・解決策が紹介されていました。筆者である市谷さんの実際の経験に基づいて書かれており、普段の開発現場で起こり得る問題への対処方法や理論は、非常に勉強になりました。（ストーリーも楽しみました。）
結論、答えは見つからなかったですが、チームとして協働していくことを記載したチーム・ジャーニーも続けて読み進めていこうと思います。
提唱されている理論や手法が主です。
単にワークショップを開いて、チームの関係を仲良くするだけで本当に仕事の成果は上がるの？って思ってましたが、組織において結果の質をあげるためのグッドサイクルというものがすでに提唱されており、本書で紹介されていました。
関係 -> 思考 -> 行動 -> 結果 -> 関係...のサイクル。会社で働くにあたって、チーム・個人としても目標に対する結果が求められる中、グッドサイクルを目指すのって気が遠くなりますが、この理論等をお互いに理解・共感してやっていくしかないんですかね...。
自分への期待値を整合する機会を得るドラッガー風エクササイズと、スキルの得意・苦手・今後習得したいを記載する星取表はチームの相互理解を深めるために使えると思いました。
なんとなく「あの人はフロント / サーバサイドができる」ってイメージで捉えてますが、実はやっているだけで得意ではない（勉強中）というケースもあり得ます。チームメンバー増減が頻繁におきたり、グループではなくチームとして協働するプロジェクトなどが立ち上がった際は、これらを活用すると開発時の細かいコミュニケーションズレや軋轢が少なくできるんじゃないかと思います。
「ふりかえり」じゃなくて、「むきなおり」が紹介されていました（初めて聞きました）。方向性を定め直して、共通認識する機会を作ることだそうです。
事後ではなく、これからの未来を見つめ直したい場合に使ってみようと思います。
個人ごとにバッファを持つのではなく、プロジェクトとしてのバッファを設ける手法...と解釈しました。（以下を拝見した感じ、実際はプロジェクト管理手法の一種っぽい）
ざっくり言うと、みんなの経験と知恵を繋ぐ機会。本書の説明と、以下の記事を読むと理解が捗りそうです。
コミュニティの人たちと、leetcodeの問題を週1で解いていく活動をはじめました。
この記事では、leetcode回答までの流れを書き留めておきたいと思います。
leetcode始めたい...という方の参考になれば、幸いです。
leetcodeは様々な言語で回答可能となっており、自分はTypeScriptで選択しています。
budougumiさんの上記記事を拝見し、自分もCLIを自作したい...と思ったのですが、
LeetCodeのAPIの仕様はドキュメント化されていないので、RustのCLIをリバースエンジニアリングして解析する必要があった（Rustわからない）
で、心が折れ
という流れで実施しています。
テストを書いているのは、単純にJestの素振りをしたいがためです。
typescript-sandboxにleetcodeというディレクトリを作り、leetcode回答専用の環境を整えています。
ts-jestのセットアップTypeScript x Jestの環境でテストを書くため、ts-jestのドキュメントを元に環境セットアップをしました。
以下抜粋です。
# typescript未導入なら `npm i -D typescript` も必要 npm i -D jest ts-jest # jest.config.jsの生成 npx ts-jest config:init
始めてからまだ3週間かつ比較的簡単な問題ばかりを解いていますが、
というような効果があると感じています。
何を勉強しようか...と悩まれている方は、とりあえずleetcodeに手を伸ばしてみるのも一興と思います。
前提条件として、バージョンは以下。
タイトル通り、Facebookログイン〜Instagram Graph APIの実行までできたので、雑に作ったサンプルと手順を以下リポジトリ・ディレクトリに置きました。（コードからREADMEまで雑なので、よければ参考程度にしてください）
本記事では、素振りしたときのことや所感を書き残しておきたいと思います。
は、以下のスタートガイドに記載されていました。
先ほど紹介したサンプル実装は、スタートガイドに長期トークン取得処理を加えたものになっています。
Facebookログイン時に得られるトークンは期間が短いため、システム要件に応じて、60日間有効な長期トークンに変換した方がよいかもしれません。
ただし、長期トークンの取得にはappSecretの指定が必要なため、実装するならフロントではなくサーバサイドが望ましいと思います。
スタートガイドのBefore You Startに漏れなく書いてありました。
ざっと必要なものは以下です。
自分の場合は、FacebookページとInstagramビジネスアカウントのリンク設定を失念し、APIは成功している（200OKを返している）のにInstagram Business IDが取得できない...という状態に陥ったので、注意してください。
graph.facebook.comは同じなので、バージョンはv9.0で統一していいかも以上です。
