Article

はじめに 本記事のカバー画像は sasint による Pixabay からの画像です。 今年は良くも悪くも変化のあった年でした。特に 1 月から暗雲立ち込めすぎて終わった…と思ってたことを思い出しました。。ｗ 来年の自分が今を振り返れるように、今年始めからの記憶を引っ張り出しながら総括しました。ただ今年の初めの方の記憶については大分薄れていて覚えてる限り記す感じで。。 今年問わず作ったものは Tech ページに、技術記事については RSS Feeds にまとめてあります。 出来事 1 月 400 万をドブに捨てることとなる (詳細についてはいつかアウトプットしたい) 諸々人生を真剣に考え始めるキッカケとなる ただそんな中でも自費で M1 Mac mini を購入していた…w Rust 入門のため Actix Web で Gyazo の利用者向けウェブアプリ作ってた Bloggimg ってやつで知見を 記事 として残してた Bloggimg をデプロイした際に得た知見は この記事 で残してた 得た知見は記事として残す行動が習慣化してきた 2 月 テックブログを Vercel 上に Team Blog Hub 使って開設した その際の知見を この記事 でまとめてた 3 月 仕事で初めて Gatling を使った その際の知見を まとめた記事 当時を思い出すと手触りは悪くなかったし、出力されるレポートも見やすかったけど k6 + Grafana のほうが慣れればカスタマイズ性も含めて良い印象 Zenn の記事を DEV に共有するための GitHub Actions を開発してた -> sync-zenn-with-dev-action DEV のアカウント作ってたけど全く使っていなかったので有効活用のためクロスポストできるようにしたいがモチベだった気がする 負荷テスト対策のためのアレコレを記事にまとめていた [Tips] Jest で private readonly な値をモックする方法 - Qiita 📔 PlayFab の API 制限に引っかかった - Qiita Azure + PlayFab で初めて開発したけど、それなりに落とし穴にハマったりコンソールが個人的に見辛かったりしてマイクロソフトェ… になってた記憶…w 4 月 Twitter DM や Lapras でちゃんとしたメッセージをいただけるようになり転職を意識し始める 自分の技術者としての能力が外の世界で本当に通用するのか、試したくなってきた時期だった気がする 個人的にも気になっていた企業様からメッセージいただけたりした感じで嬉しかった 技術教材を作ってみないかのお誘いが Twitter DM で来てた めちゃくちゃしっかりと記事を見てくださって感想をいただけたのと、ドキュメント作成能力は今後絶対に向上させたいスキルの 1 つだったので、受けさせていただくことに決めた SecretSky を VR で見てめっちゃ盛り上がってた 人生初の履歴書作成が数年分の経歴が溜まっていたので、めちゃくちゃ大変すぎて疲れ果てていた 転職の意思がなかったとしても定期的に経歴の欄を更新していくことを決意 5 月 GameCI で Unity の CI 環境構築してみてた この記事 に知見まとめてた 大規模プロジェクトでは GitHub Actions で GameCI 使うときは、セルフホストランナー 必須だなと感じた 転職することを決意し、転職先が決まり 8 月から働けることになる 転職のための作業に時間を割きたくなかったことと、最初から興味がそそられるオファーを色々いただけたのでスグに決められた 6 月 転職することを会社にご報告した 大学生の頃からの関わりも含めると 10 年近く期間があるのでめちゃくちゃエモくなった 自分の技術研鑽のサイクルが確立してきたので、記事として残しておいた 会社の同僚に感銘を受けて真似すると言われてめっちゃ嬉しかった 諸々仕事も落ち着いた段階だったけど、引き継ぎ項目が多かったので 2 ヶ月後の 8 月から転職先で働かせていただくことになる 7 月 エンダーリリーズ にハマり倒してプラチナをゲットする 有給休暇で 1 ヶ月休んでたけど、パートナーに開発の勉強を教えててほぼ自分の時間はなかった… あと長期休暇を取ってみて、今度もしまたそういった機会があったら半年くらい休みたいなと思った 8 月 転職先で仕事が始まる Unity + OAuth2.0 関連をやり始める モバイルアプリでセキュアに情報を保存するための知見を 記事 で残してた 9 月 API インフラバックエンド関連をやり始める ステートフルなインフラバックエンドをやり始める 大規模なステートフルなインフラバックエンド関連の経験が皆無だったので新鮮で楽しいになる ロストジャッジメントにハマり倒す。ストーリーもめっちゃ好きでプラチナを取る educative で教材を書かないかお誘いが来てめちゃくちゃビビる 現在進行形で教材書いてることもあり、今回は受けないことに決めた 10 月 Unity + OAuth2.0 関連が一旦落ち着く とにかくステートフルなインフラバックエンド関連やってた 想定利用者数が想像より桁違いに多かったので色々焦りながら勉強しまくりの日々を過ごす 早々に負荷テストのクラウド環境を整備して開発の度に回してパフォーマンス計測したりしてた インフラのみならずアプリケーション開発も並行して担当していたため、シームレスに開発が進められたのは良かったが、やること多すぎワロタ状態に突入 11 月 我武者羅にステートフルなインフラバックエンド関連やってた おかげでスケールイン・アウトから監視、諸々含むシステムの安定性向上がようやく安心できるレベルまで持っていけた 知見をメモる時間ももったいないになってしまったので、とりあえず諸々 Notion に書きなぐってた 12 月 今まで培った知見を何もアウトプットしていないことに気づき焦る 来年から頑張ろうになる (えっ とりあえずアドベントカレンダーには参戦した ECS Fargate のメトリクスを Prometheus Agent 使って AMP に送って Grafana で監視する 4 月から進めていた技術教材の初稿ができて推敲しまくりステータスに入る おわりに 今年は割と波 & 緩急のあった 1 年でした。来年は今年の変化を形にしつつものにしていく感じで行きたいです。記事にできそうな技術ネタもめっさ溜まってるので放出しまくりたいです。強めのエモネタもいくつかあるので、良さげなタイミングで放出したいです。 ...

はじめに 本記事のカバー画像は tookapic from Pixabay の画像です。 技術研鑽のための行動が習慣化して確立してきたので、また困り始めた時に参照するための備忘録的な感じで、習慣化に至るまでの流れを記事化しておくことにしました。自分の中では努力していると一切感じず自然に技術研鑽及び技術者としてのプレゼンス向上のために行動できるサイクルができた印象です。 昔から色々なやり方で上記の習慣化にはトライしていたものの、全てが長続きしなかった自分でも継続できるやり方なので、ある程度の再現性はあるかもしれません。(が、あくまでも自分のやり方にはなります。。🙃 ちなみに本記事の内容を推敲していたところ、最近読んだ心理的安全性のつくりかたに出てきた 「きっかけ・行動・みかえり」 のパターンになっていることに気づきました。 技術研鑽のサイクル 自分で自分のモチベを保ちつつ、自然な技術研鑽サイクルとして定着したフローを説明していきます。 「きっかけ」：実現したい開発アイデアが浮かぶ Image by Hans Braxmeier from Pixabay 個人的に突発的にコレ作れたら面白そうとか、自分はコレがあったら便利だなっていうアイデアが浮かぶことがあるのですが、大体そのアイデアを本気で実現したいと本当に思えるピークは体感最長でも 3-4 日くらいです。 そのため、アイデアを具体化して開発に着手するまでの期間としては 3-4 日以内を目安に考えています。 アイデアが思い浮かんでから長く期間が空いてしまい、具体化する気が無くなってしまった場合はメモアプリにアイデアをストックしておきます。 それらを見返すとより有益なアイデアが浮かんだりするので今後のきっかけ作りに有効活用できます。 また、 開発のアイデアについてですが、プライベートだけでなく仕事で開発しているシステムの新機能/改善案等もアイデアとして扱うことが可能です。 自身の仕事の質向上にもつながりますし、行動を起こすためのきっかけ作りとしても利用できて、技術検証や実装等は業務時間で行えるため割とオススメの方法です。1 「行動」：開発アイデアを検証可能な形で実装する Image by Sasin Tipchai from Pixabay 開発では、とにかく動作確認が可能な形で実装を行うことに注力します。細かい設計などは置いておいて仮説検証を優先していくイメージです。 そのため、技術選定は何基準でも問題ありませんが、アイデアの内容によってそこら辺の技術基準は変えていくのが良いと考えています。 例えば、プラグインやライブラリの開発については使い慣れた言語や業務で利用している技術を選定すると、知識や知見を深めることに繋がりやすかったです。サービス開発については初期は触れる技術領域が広く浅くになりがちなので、新しい技術など使い慣れていない言語などを採用して知識や知見を広げることを意識すると最後まで楽しく開発できました。 技術研鑽という名目で取り組む開発なので、完成を目指す必要はありません。しかし、成果物として完成させることを目指したいという場合は、モチベーションを絶やさないようベースとなる機能の実装を短期間で行うことを意識します。ベースとなる機能の実装というのは、一通りそのシステムの動作検証を他者が行える状態を示します。 システムの動作検証を他者が行える状態まで持っていければ、正しく成果物が評価できる状態になっているはずだからです。 まとめると、モチベを保てるやり方を意識して技術選定を行い、具体的な成果物を意識してベースとなる機能の実装を短期間の細かいサイクルで進められると、満足感のある形で開発を進めることができました。 「みかえり」：過程で得たもの全てをアウトプットする Photo by Greg Rakozy on Unsplash 成果物の公開だけでなく、その開発を通して得た知見や知識及びソースコードなど全てアウトプットします。行動の途中だとしてもモチベが下がってきたら、みかえりのフェーズに移行します。 例えば、成果物で言うと、ストア公開するだけでなくソースコードも GitHub の公開リポジトリにアップします。知識や知見などは技術ブログで記事化してまとめて公開します。 他者の目に触れる場所へ公開することを意識すると、アウトプットの質を高めるモチベに繋がります。 承認欲求を満たすためではなく、あくまで自分のアウトプットの質を高める施策の一貫として考えます。 上記を意識するとリファクタリングやベスプラに沿った開発ができているか等のチェックに繋がり、知識や知見をより深めることに繋がります。記事化も同様で、文章として知見や知識を残す過程で正しい内容なのか、本当に正しく動作するソースコードが書けているかに意識が向くため、誤った知識の修正や復習に繋がります。 成果物だけでなく身につけた技術も含めて全てをアウトプットすることで、余すこと無く行動した結果を有効活用できます。このサイクルを何回か行い習慣化してくると、インプットした内容を全てアウトプットしきるための行動が自然と起こせるようになっていきました。 アウトプットする過程できっかけが生まれて更に行動することにつながっていくという流れも生まれました。 具体例としては、シンプルなプラグインを作っていく過程で、ライブラリ化やモジュール化した方が良い機能がでてきたので、別リポジトリに切り出してパッケージマネージャーからインストール可能にしました。また、業務で特殊な事情で取り組んだ開発内容を新たな知見として記事化してアウトプットを増やすことができるようになりました。 ちなみに私はアウトプットする手段としての記事化には重い腰が中々上がらない人間だったのですが、堤 修一さんの Youtube 動画 と同様の考え方に自然に至りました。 全てが自分のやった成果として目に見える形で残っていくので、後から見返したときに自分の実績として実感が湧きやすく、作りっぱなしで終わっていた頃と比べると相当な達成感を味わうこともできます。 ゲームでいう様々な実績を解除してくような感覚に近いかもしれません。🎮 おわりに 現状個人的には上記のサイクルが上手く機能していて、最近習慣化の軌道に乗った感じが自分の中にあったので知見として記事化しておくことにしました。今後、上記サイクルについては改善を繰り返しながらアップデートしていきますが、一旦現状の内容を後から見返せるようにしました。 また今回始めて記事内でイメージ画像をふんだんに使ってみましたが、画像探すの楽しいし記事のクオリティが上がったと錯覚できるので、今後もポエム記事については積極的に画像を利用していこうと思いました (違 ...

はじめに 📝 最近とある事情により Twitter の DM を利用しているのですが、Slack などのように絵文字をショートカット入力できないことにフラストレーションが溜まってきていました。そのため、絵文字をショトカで入力可能にしてくれる Chrome 拡張機能を探したのですが見つけられませんでした。 そこで、無いなら作ろうということで Teemo を開発しました。 ソースコードは GitHub 上で公開しています。 何かご要望等ございましたら PR や Issue 作成頂けますと喜びます。Teemo の実際の挙動については下記の動画で確認できます 🎥 考えていたこと 💭 今回 Teemo の開発を行うに当たり、考えていた点は下記になります。 よくある : 入力からの絵文字ショートカットを導入する Slack や GitHub、JIRA などではおなじみの入力方法 ⌨️ パレットから選択する際は半角英数字で検索できるようにしたい Twitter では日本語で検索しないと絵文字が探せない 🔍 普段英数字で絵文字検索をするので目的の絵文字が見つけづらい 🕵️ 拡張機能を利用することで文章入力の煩わしさが増加することは避けたい コピペや文章クリアの機能等にもショトカ利用できるようにしたい 💨 プロトタイピングしながら友人に進捗をシェアしながら開発は進めていきました。本当は個人で利用する想定で進めていたのですが、割と評判が良かったため Chrome ウェブストアに公開するのを目標に動いていました。そして、Chrome ウェブストアで公開できるクオリティを目指して動いたことで満足のいく拡張機能が作れました。 ...

はじめに PlayFab で CloudFunction を利用しているときに API 制限に引っかかってしまいました。負荷テストをした際に初めて気づいたのですが、公式ページにも言及が無かったため発覚が遅れてしまいました。そのため、PlayFab に依存していた機能を部分的に外す必要が出てきてしまい苦労しました。 本記事では、上記のような事態に陥る方を減らすため、API 制限に気づくまでの軌跡を辿りながら、PlayFab の CloudFunction を利用する際の注意点について、記事として残しておきたいと思います。 PlayFab の API 制限に引っかかった要因 PlayFab の CloudFunction を利用すると、PlayFab 経由で独自 Web API を実行することが可能になります。また、CloudFunction 経由で独自 Web API を実行すると、PlayFab ユーザ情報が含まれたパラメタが含まれた状態でリクエストが飛んでくるため、その情報を利用することでサーバーサイドで PlayFab の操作を行うことが出来るようになり大変便利です。 そのため、あるプロジェクトでは PlayFab CloudFunction を Azure Function や AWS Lambda のような FaaS を使っている感じで利用しておりました。そして、その利用の仕方は誤りであったことに後々気づきます… 負荷テストを実装するフェーズで CloudFunction を大量に叩いてみる PlayFab の CloudFunction を実行するにあたり利用した PlayFab の API は Server-Side Cloud Script - Execute Function というものになります。 同接 2000 人想定で負荷テストのシナリオを実装することが求められていたため、その通りシンプルに 2000 件同時に Server-Side Cloud Script - Execute Function を実行するシナリオを Gatling で組んでみました。すると、何回やっても数十件以上は必ずエラーが発生していることが分かりました。 ...

はじめに いつもブログ記事に載せるキャプチャ画像の編集 & アップロード先として Gyazo を利用させていただいているのですが、日々使っている中で不満に感じる点もちょくちょく出てくるようになってきました。 そのため、3 連休を用いて Rust の勉強がてら Bloggimg というウェブアプリケーションを作ってみました。ソースコードは MIT ライセンスで GitHub のリポジトリにアップしております。ちなみに最初は Gyazo for Blog という名称で開発をしていたため、本記事内のスクショには Gyazo for Blog という文字列が出てきますが、現在は Bloggimg という名称になっております。。 Bloggimg を開発したのは、ブログ記事を書く際に利用する画像のアップロードから加工、マークダウンとして利用するまでのフローを最適化したかったからです。 ブログ記事を書く際に、記事内で用いるスクショ画像の加工や、そのアップロードにすごく時間を取られてしまうなーと日頃から感じていたのでそれを解決したかったのです。✅ 開発中に得た知見等については別途技術記事として書いて残す予定です。 考えていたこと 今回 Bloggimg の開発を行うに当たり、考えていた点は下記になります。 画像の編集ツールは引き続き Gyazo に用意されているものを使う 既に最高に使いやすい 👑 キャプチャ画像をアップロードする際に、自動的に特定のコレクションに紐付けるようにする 技術記事毎にコレクションを分けて管理しているため、技術記事を書いている最中にアップするキャプチャ画像は全て特定のコレクションにまとまっていて欲しい ワークスペースのようなツールを目指し、ブログを書く時だけに使える機能を開発する 例えば、ワンクリックで画像マークダウンの記述がコピーできたり、画像のアップロードをし直しやすくするため画像削除がお手軽に出来るよう削除ボタンに即アクセス出来るようにしたり… 特にアップした画像を 自動的に特定のコレクションに紐付けるようにする については本記事で紹介しているウェブアプリケーションを作成するキッカケとなった点なので外せない点でした。 使い方 Bloggimg の使い方についてご紹介いたします。 ログインする Bloggimg を利用するためには、まず Gyazo アカウントでログインして頂く必要がございます。トップページの右上にあるログインボタンから Gyazo アカウントでログインします。 1. トップページ右上に配置されたログインボタンから Gyazo アカウント認証を行う 2. Gyazo アカウント認証が正常に完了したら、再度トップページを開く 3. トップページを開いた時に Gyazo にアップした直近の画像が確認できるはずです ...

はじめに 本記事のカバー画像は Vladimir Fedotov による Unsplash の画像です。 最近「ちゃんと理解してくれた？」ということを聞かれた時に「理解したけど、そういう行動を取るつもりはない」というと、「理解してないじゃん」と言われることが何回かあったので、その時の対処法及び感じた心情などをこの記事で吐露したいと思います。 年始からこういう記事を書くのは気が引けたのですが、あまりにも本記事タイトルのような方と多く遭遇したため… 理解するということ 「理解する」というのは、相手の言動の意味が正しく分かったということを意味します。 その言動をそのまま自身に取り入れることは意味しません。例えば、犯罪者の行動理由が正しく分かったところで、それを自分の行動規範に取り入れることはしないはずです。 双方がコミュニケーションを取り正しく分かったという状態になっている前提ですが、「理解したけど、そういう行動を取るつもりはない」という発言を受けてから「理解してないじゃん」という言動を発してしまうのは勘違いも甚だしいです。 上記はもはや理解した・してないとかの次元ではなく、相手を自分の言動でコントロールしたいがために会話している状態と捉えられても文句は言えません。 一種のマインドコントロールに近いかもしれません。 ちなみにこの傾向は、直接話したいと言ってくる人に多いです。しかも、そういった人に限り相手の都合を考慮せずに何回も同期的なコミュニケーションを取ろうとしてきたり、スグに語気を強めて自分が不満であることを感情でアピールしようとしてきます。また、「絶対」 とか 「必ず」 とか 「必要」 という言葉を不適切に多用する傾向が多いです。 例えば、突然語気が強くなったり、攻撃的なメッセージの後に「電話して」等送ってくる人らが該当します。更に特筆すべき事項としては 怒ったと思ったらいきなり優しくなる DV の典型的なパターンであることが多いです。 筆者はコミュニケーションは双方の歩み寄りが前提で成り立つものと考えている ので、そういったやり取りになってしまった場合は残念ですが、親戚だろうが親族だろうが関係なく断絶か、それが出来ない場合は自分から可能な限り距離を置くようにしています。 受け入れるということ 「受け入れる」というのは、相手の何らかの言動をそのまま自分に取り入れることを意味します。 相手の言動を理解した上で、自分が間違っていたり知識不足であった場合に、それを認めて言動を正しく自身に取り入れるということは視野を広げる上で重要です。 しかし、注意点として「理解してないけど受け入れる」場合は、自分で何も考えないで言動を取り入れることを意味するため危険です。 世の中には根気よく話せば伝え方を変える等の工夫をせずとも無条件にこちらを説き伏せることが出来ると思ってたり、一回考えを相手に話しきったらその思いが全て伝わり、勝手にこちらがその思い通りに行動すると思っている人が意外と多いです。 上記のような人物への対策としては、自分の言動の主導権を他人に握らせないが基本戦略となります。 そういった人物は会話のペースや話の進め方が自分勝手なことが多いので、そこで折れずに反応もせずに自分の意思は持ちつつ、適当にいなすような感じで話を流すと無駄に疲れずに済みます。 例外として、自分が相手の言動に勝手にレッテルを貼り一方的に理解したつもりで、「受け入れない」という選択肢を取ることはオススメしません。自分の視野を狭める行為だからです。 つまり、理解するという行為はどんな状況であれ双方が取り組むべきであるが、受け入れる行為はお互いに選択の自由があるという前提を忘れずにいるべきと考えます。特に、こちらが決める権利があるはずの選択肢を、逆も然りですが、どんな人物が相手だろうがコントロールする権利は一切無いのでそのような話が出たときは注意する必要があります。 いずれにせよ、受け入れるというのは行為は、理解という前提があった上での、主体的な行動の結果であるべきと考えています。 自分を押し殺して受け入れるということ 前項でも簡単に説明した、「理解してないけど受け入れた」状態のことを指しますが、その場合のメリット・デメリットは下記になると考えています。 メリット 相手の言動が 自分にとって 100% 正しかった場合 、自分だけでは対処できなかった問題を解決できる可能性がある 自分が納得することはないかもしれないが、 少なくとも相手を納得させることは出来る あくまでも、少しの間は相手を静かにさせることが出来るかもしれない程度 自分で考える労力を割くことが出来る。物事を真剣に検討するのにはそれなりの労力がかかる ただし、自分で物事を検討して行動するための方法が身につかない。他者に依存する デメリット 無意識下に相手の意のままに行動させられる可能性がある 経緯はどうであれ、自身の言動の責任は自身に帰属するため、責任を取る必要がある 自分の言う通りに相手が動いてくれることが嬉しいと感じる人種は存在していて、その人達に面倒を見るといったような名目で監視されるようになる 自分が検討して取り入れたわけではないため、その結果の是非に関わらず学びが薄い 結果を反省して、自分の知見として次に繋げることがしづらい 他人の意見に忖度して物事の決断を行うようになると、主体的に行動を起こすエネルギーが無くなっていく 与えられた選択肢の中から最後に後悔しない決断が出来るのは自分しかいません 選択肢の意味を正しく理解しないまま行動すると、失敗したときのダメージが大きくなります 上記を見ていただければ分かる通り、メリットは非常に薄い上に基本的にデメリットに直結するような内容が多いです。 つまり、メリットに感じる点は刹那的な効用であって、本質的には問題の要因でもあるということです。 また、上記の中で最も重要な観点は 他人の意見に忖度して物事の決断を行うようになると、主体的に行動を起こすエネルギーが無くなっていく という点です。筆者はこの点を生きていく上で非常に重要な点の 1 つと考えています。 その理由として、主体的に行動を起こすエネルギーが無くなると、1 日過ごす際の時間を有効活用できなくなったり、重要な決断をいつまでも先延ばしにしてしまうようになり、人生を楽しむ時間が削られていくと考えているからです。 要は、面倒だからと言って理解せずに受け入れたり、他人の意見に忖度して決断を行うという行為を繰り返してしまうと、時間を浪費したり、1 日に楽しい時間を過ごせる割合が減っていき幸せの総量が減る ということです。 理解したを受け入れたと捉える人たちへの対策 まず距離を置くという対策をオススメします。反論や反発はオススメしません。時間を浪費するだけでなく、無駄にダメージを負わされる可能性が高いです。 また、強い言葉で一方的にコミュニケーションを取られた後「反省している」「言い過ぎた」等の言葉で優しくされたとしても決して距離は近づけないでください。もしそれで距離を近づけてしまうと相互依存のような形になっていき粘着されやすくなります。 ...

はじめに 本記事のカバー画像は Michal Jarmoluk による Pixabay からの画像です。 今年は結果的にプライベートと仕事の両面で充実した年にできました。来年の自分が今を振り返れるように、今年始めからの記憶を引っ張り出しながら総括しました。 今年問わず作ったものは Tech ページに、技術記事については RSS Feeds にまとめてあります。 出来事 1月 Death Stranding のプラチナ獲得 弊社に面接にいらっしゃったベテラン開発者の方に何でうちに応募してくださったのか聞いたら、僕の Twitter や Qiita アカウントを見てくださり技術力がありそうと判断してくれたからと聞いて爆嬉しかった ambr オフ会参加 (オフィシャルなオフ会に初参加) Quest 用アプリケーションの初リリース体験実績解除 申請時の知見の一部については Qiita 記事 として投下 Android で AR アプリケーションの開発及び、マルチプレイを可能にするバックエンド開発を担当した 2月 Docker で各種モバイル VR 向けの Unity ビルドが出来るようにした フルリモートでアジャイルな開発チームにジョインする (WebView/ReactNative/iOS/Android) 主は ReactNative の iOS/Android のネイティブプラグイン開発 コア機能の実装にのみ注力しパフォーマンスチューニング等々を行っていたためポジション的にはひたすら地味だった 3月 note デビューした 初投稿は 精神衛生を保つため Chrome で Twitter を閲覧している時にフォロワー数を非表示にする っていうやつ お題が「Home」の web1week に参加した 参加した時に投稿した記事はこちら 4月 会社の Medium ブログ開設 したのと、いくつか記事を寄稿した Azure Kinect DK の開発環境構築から KinectFusion のサンプルを動かすまで 最短で Magic Leap 1 の開発環境を構築する 色々工夫して iPhone TrueDepth を WebRTC でブラウザに転送して、Three.js で表示する仕組みを実現した Twitter でシェア してみたら、予想だにしないことに一方的に尊敬していたエンジニアの方々からいいねを貰えてモチベが爆上がりした CloudFormation と和解。IaC の利便性を完全に理解し始める 今更 SEKIRO にハマりまくる & プラチナトロフィー獲得 デス・ストランディングから学んだこと が現在の自分の考え方の基礎として根付き始める 全ての考え方を 0 or 1 ではなく、グラデーションにハメ込むことが出来るようになった 5月 再びお題が「Like」の web1week に参加した 参加した時に投稿した記事はこちら (あとから確認したら投稿先を間違えていた…) Medium に目次が無いことに不満をいただき Chrome プラグインを作成する プラグインの紹介記事 まで書いてたけど全くインストール数伸びなかった、、けど今みたら 12人ほど使ってくれている人いるぽくて嬉しい お題が「密」の unity1week に 参戦した 6月 S3 + EventBridge + CloudWatch + CloudFront + MediaLive + MediaPackage + AppSync + Amplify + DynamoDB + Cognito + Lambda + API Gateway + SSM という AWS ガッツリなインフラ構築から、バックエンド開発及び iOS アプリ開発までをおもむろに始めた まず DynamoDB の仕様にハマる (自分のリサーチ & 勉強不足によるせい…) つぎに MediaPackage + CloudFront の構築 に苦戦する そしてデバッグが辛くなり Serverless Framework でエラーを検知して Webhook で Slack に通知を飛ばす方法 を実践し始めたりしていた シェンムー3 のプレイを開始。ワクワクするし美しすぎる町並みに興奮し、しばらくの間深夜までプレイする日々が続く 映画の HELLO WORLD を見て、劇中 3回号泣する 元々は Unity で作られたシーンがあるという記事 を見て興味を持ち見ようと思い立った感じだった 7月 ひたすらトラブルバスターしてた (一番忙しかった気がする) 8月 Ghost of Tsushima にハマりまくる & プラチナトロフィー獲得 DDD 開発の際、DI コンテナ入れたいよねっていう話から TypeScript 環境で利用可能なライブラリを調査して InversifyJS と tsyringe を見つける 最初 InversifyJS を発見してそれで開発をしていたものの、microsoft 製の tsyringe を発見し、「メンテナが大手だしコンストラクタインジェクションだけしか使わないし、こっちのが良くね？」という話になり InversifyJS から tsyringe へのリライト作業を行う…w AWS SDK for Go で関数の引数と返り値を Type で定義するっていう考え方は非常に参考になった 引数が *Input という定義で、返り値が *Output という定義で分かりやすく読みやすい 自作 iOS ライブラリの CocoaPods 対応について C++ 周りの linker error に対する解決のためのアドバイスを急ぎ求められたので、共有された情報から自分がハマった経験に照らし合わせてソレっぽい対策案を共有したらガチッとハマって解決でき、経験が生きた感がめっちゃあって、めちゃくちゃ嬉しかった 9月 フライパンでコーヒーの焙煎を始める チャフの飛散に苦しめられるが、風呂場で作業することで諸々ストレスフリーになる このときはまだ、後ほど焙煎機を購入することになるとは夢にも思わなかったのである… Azure を用いた開発に本格的に携わり始める その際得た知見は Zenn で 本としてまとめた。本来は記事として書くつもりだったが、分量が増えすぎたため記事内容を分割して、本としてまとめた PlayFab CloudFunctions のための関数実装のために Azure でシステム構築していたため、PlayFab にもそれなりに詳しくなる とある案件から別案件に移る際に、 「えー、〇〇 に行っちゃうんですか。nikaera さんは今後も 〇〇 を一緒にやっていって欲しいのに」 って結構強めに言われたことが未だにめちゃくちゃ嬉しい シンガポール現地のフリーランスの方と仕事を共同で進めることになる。技術に関する事柄やプライベートに関する事柄のやり取り等々、全て英語でコミュニケーションを行わざるを得なくなり、そのおかげで英語でコミュニケーションを取ることに一切抵抗が無くなる 10月 約 10 年ぶりに私用携帯を HTC EVO から iPhone 12 mini に機種変する 開発用途でなく普段生活で使うことのみを考慮するということであれば iPhone 12 mini は最強にオススメできるスマホです 会社支給のスマホで 7年近くを賄っていたため、特に不便がなかったため… AWS Amplify への PR がマージされる もとは serverless-amplify-simulator の Issue で議論していたのだが、改修すべき内容は amplify-cli にあったのでそちらで PR を提出した 細かくづまづいた点を進捗共有兼ねて Issue で一人投稿しまくっておくと、他の開発者の役にも立てるし自然とその問題に詳しくなっていくし、OSS 活動への取っ掛かりとしては最高なんじゃないかと勝手に思い始める NPM に初自作ライブラリを公開する serverless-amplify-auth という Amplify 開発を行う際は必ず行うであろう IAM Policy の制限を Serverless で行うことが出来るようにするやつ 11月 Hugo で自分のブログ(nikaera.com)を GitHub Pages 上に構築する カジュアル面談した人に Qiita のネタ記事 見ましたって言われて嬉しいよりも恥ずかしいが上回った Etsy でアクセサリ販売している方に日本のフリマ事情を詳細にお伝えしたらおまけのプレゼントを送付してくださった ちなみに購入物は Death Stranding の ドリームキャッチャー Moonlander が自宅に届きテンション上がって紹介記事を書く 12月 今年学んだ重要なことを 記事 として残しといた (これもある意味総括な気がする) GitHub Profile を充実させる こんな感じ -> https://github.com/nikaera 更に GitHub Profile を充実させるために Zenn のバッジを作成するサービス を作った Lapras の技術力スコアが 3.36 になってた 基準とか良く分からないけど純粋に上位 13% に入ったと言われてるのは嬉しかった いくつか空いてたアドベントカレンダーに参戦した MediaPackage 用の CloudFront ディストリビューションを AWS SDK で作成する Serverless のプラグインを TypeScript で作成する方法 AWS Lambda を用いた他社製品との連携システムが好評で、去年から今年末まで特に目立った不具合等も起きずに運用できたため、次期開発に繋がりそうとの連絡があり開発者として爆喜ぶ おわりに 今年は後半からすごい勢いでギアが入ってきた感があり、諸々活動するための足がかりを作れた気がします。身も心も進化したなと思えて成長できたなという充足感は割と高めな 1年だったので、この勢いのまま 2021 年もマイペースに色んなことにチャレンジしていければなーと思っております。 ...

はじめに 最近 ErgoDox EZ からの乗り換えで Moonlander というエルゴノミクスキーボードを使っているのですが、諸々非常に満足しています。コンパクトながら安定感のある打ち心地でカスタマイズ性も高く、試行錯誤しながら自分好みにセットアップして使い勝手を最適化することができます。 バックライトがあり、デフォで 様々な光り方 が用意されているのも非常にカッコよいです。あまりキーボードのバックライトを気にしたことは今まで無かったのですが、何となく 1日毎にエフェクトを切り替えると良い気分転換になります。なんとなくだけど。。ｗ また、これについてはエルゴノミクスキーボード全般に言える話で Moonlander に限った話では無い気がしますが、体がこわばった姿勢にならなくなり、肩が開いてリラックスした姿勢でタイピングできます。 そのため、長時間 PC で作業していても、呼吸が浅くなりづらく、肩への負担も少なく感じます。現に筆者はキーボードを変えただけで生活習慣変えた覚えがないにも関わらず、長時間作業しても疲れにくくなりましたし、肩こりになりにくくなりました。 毎年冬になると肩こりになる体質だったのですが、ErgoDox EZ を採用し始めてから肩こりに悩まされることは無くなりました。 今回はそんな気に入って仕事プライベート問わず酷使している Moonlander についての紹介記事を書いていこうと思います。 ちなみに筆者はキーコンフィグを軽くカスタマイズしている程度のライトユーザーです。 セットアップが簡単 Web から簡単にキーコンフィグを設定することが可能です。キーコンフィグ設定のためのサービスは Ergodox EZ Configurator というやつです。名前に Ergodox がついていますが ZSA Technology Labs から購入可能なキーボード全てに対応しています。(Moonlander にも Planck にも対応) 今回は Moonlander Mark I を利用する Search layouts ボタンをクリックすることで、他の人が既にカスタマイズしたキーコンフィグをダウンロードしたり、そのキーコンフィグを元に自分用のキーコンフィグをカスタマイズすることも可能です。 ちなみにデフォルトのキーコンフィグは Configure ボタンをクリックすると確認することができます。もちろん、そこからキーコンフィグをカスタマイズしていくことも可能です。 また、カスタマイズした設定内容は常に Ergodoz EZ Configurator に保存されるので、後から細かくキーコンフィグを修正していくといったことも可能です。 最初のうちは頻繁にキーコンフィグに微修正入れると思うので、めっちゃ便利でした。 Ergodoz EZ Configurator の Search layouts で “coding” で検索した結果 ...

はじめに まず、私の誕生日は 11/6 なので本日 12/6 は誕生日からちょうど 1ヶ月後になります。 誕生日なので何か書くことにした✍️ | なんでもに参加しました！ https://t.co/1NXySfMlak #Crieit #crieit_advent_calendar @crieitcommunityより — 𝚗𝚒𝚔𝚊𝚎𝚛𝚊 (@nikaera) November 2, 2020 はい。完全にノリで参加しようと投稿予約してから、後日確認して気づきました。。ｗ しかし、その間違えに気づいてから、何を投稿しようかなあと考え始めた時に、ふと「以前の自分だったら絶対ノリでアドベントカレンダーに登録するっていう行動しないよなあ」ということに気づきました。 そこで、今回は以前の自分と比較して、今の自分がどう変わったのか考察してみることにしました。この記事書いてるときは誕生日からまだ 1週間経ってないし、ちょうど考察するには良い機会かなと思って。 以前の自分 Photo by Luis Villasmil on Unsplash 以前はやりたいことがあっても全部後回しにしてしまっていました。何故かと言うと仕事やプライベートも含めて、他に直近でやらなければならない、もしくはそう思いこんでいる TODO があったときに、それらが残っていると次々に心配事や考え事が増えていってしまい、やりたいことに集中出来なくなるからです。 つまり、やりたいことは本気で集中できるタイミングが来たらやろうと考えていました。 そのため、読もうと思って買った本を読みたい、買って届いた新作ゲームをやりたい、OSS 活動をしてみたい、ライブラリを自分で作成してみたい等々のやりたいことは全て後回しになっていました。 何も考えないでサクッと取り組めるプレイ済みのゲームを遊んだり、気に入っている Youtube の動画を何度も繰り返し見たりして時間を浪費していました。 ボーッとしながら何も考えないで過ごす時間や遊ぶ時間は気力を養う上で重要で必要だと認識しているのですが、それだけを余暇に費やすのは少し勿体ないなと感じていました。 そして、ある時ふと気づきました。多分このままの生活してると連休とか仕事の区切りのタイミングとかでしか、自分がやりたいことに取り組むことはできないなと。。ちなみに、私はいわゆる ON/OFF みたいな切り替えが出来ないタイプなので、「仕事が終わったらスイッチを OFF にしてプライベートを全力で楽しむようにする」とかは無理なタイプです。 そこで、過去自分が気分がノリ続けて作業できたり、新しいことに挑戦し始めたときのことを思い返しながら、現状改善のために簡単に出来ることからやってみようと 1年前くらい前から行動を起こし始めました。 試したこと Free-PhotosによるPixabayからの画像 まず、前提として下記項目はあえて頑張って解決するとかは諦めました。理由は中学生くらいの時から「そうだったなあ」って感じていることだったので潔く諦めた感じです。 仕事プライベート関係なく、やりたくない面倒な TODO を意識してしまい無駄に疲れる ふとした瞬間に思い出して不快になるかつ、それらの TODO は後回しにしてしまいがちなので、更に不快になる機会が増えてきて、結果疲れ続ける やるべき必要がある TODO が増えてくると最優先で迅速に全部片付けたくなる それらが意識の端にあると心を休めた状態で日々を過ごすことが難しくなってきて、結果疲れ続ける 上記の解決を諦めても、やりたいことが自然と出来る環境が作れるようにしようとしました。 仕事プライベート問わず TODO の総量を減らしていく TODO が増えてくることによって、やるべき TODO も必然的に増えてきます。最初は優先度の低い TODO だったのに、作業していくうちにそこから更にやるべき他の TODO が生まれてくることもあります。 ...