Hero Image
2023年の振り返り

はじめに 今年はここ数年でも特に怒涛の 1 年でした。 公私共に変化が激しくて、心が折れそうになりながらもなんとか乗り切った感があります。 いつも通り(?)需要の有無に関わらず振り返っていきたいと思います。 バックナンバー 2021 年の振り返り 2022 年の振り返り 2023/01 仕事 新年明けてすぐ、所属チームを異動することになりました。 入社してから n 年後には、そのチームでチャレンジしたいと思っていたのですごくワクワクしました。 プライベート 週 1 で ROOFTOP サウナに行ってました。 #サウナ 今年のサウナ初めでした。 こちらに来るのは4,5回目です。 2時間で4セット回しましたがあっという間でした。 今日のアロマは木?の香りで、ロウリュ直後... (@ ROOFTOP in 東京都, 杉並区) https://t.co/pavDmbYmWE — reo (@_uhzz_) January 6, 2023 2023/02 仕事 チームを異動してすぐに、翌月のリリースに向けた機能開発が始まりました。 都度リードエンジニアに設計方針を確認しながら、のびのび開発できました。 コミット量はこんなかんじ 副業 前職で副業を始めました。 正社員時代と同じチームに参加させていただくことができ、業務内容もバックエンド開発がメインです。 大学 以下の科目習得試験を受験しました。 Web アプリケーション 離散数学 Web 技術基礎 特に離散数学で扱うグラフ理論は、入学してから一番 Computer Science してるなと実感しました。 プライベート 高校からの友人に結婚のご祝儀を渡しました。 祝儀袋を買って、お金を包むイベントは初めてだったので、とても感慨深かったです。 2023/03 仕事 2 月に開発していた機能をリリースしました。 詳細はこの後で触れるのですが、チームを異動して初めてのリリースでした。 プライベート 軽井沢観光に行きました。 長野出身の同僚に教えてもらって、旧軽井沢銀座通りやミカド珈琲を巡りました。

Hero Image
2022年の振り返り

はじめに 1年経つのは早いですね。 今年のサマリーとしては、通信大学へ入学したことと転職したこと、です。 去年はこのブログの投稿を増やしていくと意気込んでいましたが実績は、、意気込みは大事なので来年も意気込んでいきます💪 振り返りについては需要の有無に関わらず書いていきたいと思ってる所存です。 バックナンバー 2021 年の振り返り 2022/01 とくに話すトピックはありませんでした。 新年一発目こそなにかあれよ!と自分でツッコミを入れたくなったので、意識的に1月にイベントつくっていきます 2022/02 コロナの感染拡大がまた出てきたころで、予定されていた開発合宿がオンラインでの開催になりました 初のオンライン合宿開催!開発合宿についてご紹介! Gatherはこのとき初めて使いましたが、会議室に入ると強制的にビデオ通話になったりホワイトボードを共有したりと Google Meet や Zoom のような使い方ができるのに加え、マップを自分たちでつくったりゴーカートができたりと、息抜き要素があったのが推しポイントです。 このとき気に入って、合宿のあともオンボーディングを Gather でやってたりもしたなぁと思い返したり😌 2022/03 とくに話すことはありませんでした。 2022/04 ふらっと Kyash のイベントを見にいきました。 Kyash TechTalk #2 - Serverside のシステム構成とアーキテクチャ このとき、Kyash のサーバ構成を知れたのもそうですが、苦労話や課題に思っていることを対外的に発信しているのを見て、技術力求められそうだなというのと、中の人楽しそうに話してるなと思ったのを覚えています。 このイベントのあと、メールでカジュアル面談のお誘いをもらったので、転職活動はしてなかったけど、興味本位でセッティングしてもらったのが今年の転職につながりました。 またプライベートな話題としては、通信大学に入学しました 【通信教育課程】帝京大学理工学部情報科学科に編入学しました 入ってから8ヶ月目で思うことは、年間 12 科目の単位を働きながら取るのは絶対ムリ!ではないかもしれませんが、ギリギリを攻めている感覚と怠惰な休日の時間を取りづらくなるということです。 これは勉強するリズムがついていいじゃないかという反面、興味が薄い科目に関して場当たり的な勉強をしてしまいがちなのと、休日を授業やレポートで埋めると休みが休みでなくなってしまう悲しみを少なからず感じるということです。 この振り返りは、来年 2 月の区切りのいいところで改めて記事にしようと思います。 2022/05 ジムに行き始めました。きっかけはリモートワークをしていて一日座ってる時間が長いと寝つきが悪かったりするので、体を動かしてぐっすり眠りたい、と思ったからです 。 今も継続して週に 2 回くらいは走りに行ってます。 走るマシン(トレッドミル)しか活用できてないので、来年はほかのトレーニングにも手を出したいです。 2022/06 とくに話すことはありませんでした。 2022/07 通信大学の初めての単位習得試験があり、物理的な会場での受験でした。 内心なにかしら交流があるかも😌、とそわそわしていましたが、杞憂に終わりました。 2022/08 昨年から月 1 で参加していた『プログラミング言語 Go』オンライン読書会が一区切りつきました。 初めて参加した社外勉強会がこの読書会だったので、個人的に印象深く、毎回新しい知見を得る場として楽しませていただきました。 今は柴田先生が主催するべつの読書会に参加していますが、相変わらず聞き専になってしまっているので、恥ずかしがらずに質問していくのを来年の抱負にしようと思います笑 2022/09 今年は通信大学に入ったのを言い訳に、技術書以外の本を買ったり読んだりする機会が少なかったんですが、その中でも社会学のテキストが個人的に面白かったので、マイベストブックにノミネートしました。 社会学 新版 (New Liberal Arts Selection) これまでぼんやり社会学を勉強したいなと思ってたところでこの本を強制的に読むことになり、ざっと主要なトピックを俯瞰することができました。

Hero Image
netパッケージで非推奨のTemporaryメソッドの扱いについて

はじめに こちらはKyash Advent Calendar 2022 の 13 日目の記事です。 今年の 11 月に Kyash に入社しました!サーバサイドチームのueharaです👋 今回はnet/httpパッケージの非推奨メソッドであるTemporary()について、社のメンバーから知見を共有してもらったのでその話をします。 net/http パッケージの 非推奨メソッド Temporary() について Temporary()については、フューチャー社の記事にわかりやすくまとめられています。 https://future-architect.github.io/articles/20220203a/ 上記の記事を踏まえて、ここでは非推奨になった経緯と対応について言及しようと思います。 サッと概要を話すと、Temporary()はnet.Errorインターフェースに定義されているメソッドで、一時的なエラーかどうか判定するために用意されています。 ただし、「一時的」というのがうまく定義されていないとの理由で、こちらのメソッドは Go1.18 で非推奨になりました。 net.Error.Temporary has been deprecated. https://tip.golang.org/doc/go1.18 Temporary()が非推奨になった経緯 前提として、net.Errorインターフェースは、以下のように定義されています ※ソースは Go 1.19 です // An Error represents a network error. type Error interface { error Timeout() bool // Is the error a timeout? // Deprecated: Temporary errors are not well-defined. // Most "temporary" errors are timeouts, and the few exceptions are surprising.

Hero Image
Futureパターンが使われているOSSを見てみた

はじめに @uh-zzです! この記事は、Go Advent Calendar 2022の 10 日目の記事になります! 今年は、個人的に色々なことに挑戦した年だったなあと振り返るとともに、去年のアドベントカレンダーからもう1年経つのか〜という気持ちです この記事では、Go における Future パターンをご紹介できればと思います Future パターンとは あるメソッドを呼び出すとします。 もしもオブジェクトが、そのメソッドを実行できる状態なら、実行します。 でも、実行できない状態なら、将来実行できる状態になるまで待つようにしたいとします。 その時に使えるのがこの Future パターンです。 future は「未来」という意味です もう少し正確にお話しましょう。 単にあるクラスに 「実行できる状態になるまで待つ」 という機能を入れるわけではありません。 すでに存在しているクラスに一皮かぶせて、 「実行できる状態になるまで待てるような機能を追加する」 というのが Future パターンです。 出典: 結城浩, Future パターン, デザインパターン紹介 上記の参考記事内では、Java をつかったマルチスレッドプログラミングで Future パターンが実装されています。 引用箇所の説明がほぼすべてですが、イメージ図で補足するとこんな感じになります flowchart LR 呼び出し元 --> Futureメソッド -- 実行できるようになるまで待つ --> 処理するメソッド 呼び出し元と処理するメソッドの間に Future メソッドを挟むことで、Future メソッドがプロキシ的に働き、非同期的に処理するメソッドを実行できるようになっています。 Go だとこんなかんじにかけるらしい 以下の記事で Future/Promiseという説明書されています https://ascii.jp/elem/000/001/486/1486902/ package main func readFile(path string) chan string { // ファイルを読み込み、その結果を返すFutureを返す promise := make(chan string) // readFile とは別のゴルーチンでファイルを読み出す go func() { content, err := os.

Hero Image
2022年07月に読んだ記事とか本とか

はじめに 読んだ記事とか本のリンクを張っておきます 読んだ記事 アーキテクトに求められるマインドとは / mindset for an architect 「少なくとも、最悪ではないアーキテクチャを狙う」 自分の中で新しい視点だった(常に選択肢の中で(世間的に)最善とされているものがいいという思考をしてる) 「変更が容易であれば、最初から望ましいアーキテクチャを正確に設計しなければならないという、プレッシャーも少なくなる」 Re: スクラム開発チームと業務委託エンジニアの相性が最悪だと思っている Spring で快適な DB 疎通ユニットテストライフを送りたい yaml、json、または csv などのファイルでテスト用データの事前投入や結果比較を容易にしてくれます Database RIder はテストメソッド単位で使用するデータファイルを指定できる 友達に教えてもらった。テストデータをコードと別で、テスト前後の比較も簡単にしてくれるのはすごい。 「“楽しくないけどお金のためにやる人”はやはり伸びない」まつもとゆきひろ氏が説く“プログラマーに向いている人” 「ノーコードによって仕事が奪われるイメージはない」まつもとゆきひろ × 高橋直大 × 楠正憲が語る、これからのプログラマーの仕事 Amazon DynamoDB: A Scalable, Predictably Performant, and Fully Managed NoSQL Database Service まだよんでない Domain-Driven Design Simplified. まだよんでない 読んだ本 自分に気づく心理学-加藤 諦三(著) Lean と DevOps の科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (impress top gear)-Nicole Forsgren Ph.D. (著), Jez Humble (著), Gene Kim (著), 武舎広幸 (翻訳), 武舎るみ (翻訳)

Hero Image
【通信教育課程】帝京大学理工学部情報科学科に編入学しました

はじめに 表題の通り、今年の 4 月から帝京大学理工学部情報科学科の通信教育課程に 2 年次編入しました。 そもそもの経緯と入るまでの話、入って 1 ヶ月経過した後の所感をまとめておきたいと思います。 きっかけ 大学進学について 通信制大学へ進学したいと思ったのは今年に入ってからではなく、ここ 2 年くらい検討していました。 当初は理工系ではなく、社会学/哲学に興味があり、その方面の勉強がしたいと漠然と考えていました。 ただ 2 年の間、大学への入学を躊躇してたのは以下の理由がありました。 通信制大学の卒業が難しい、また卒業率が低いといった情報を見て腰が重かった 働きながら時間が取れない、平日のフルタイムかつ出社している場合、早朝か、仕事から帰ってきて勉強時間を確保する必要が出てくるので、リモートできないと厳しい とりあえず入門書を買って積んでおけば自分で勉強できるし、進学しなくてもいいのでは?と諦めムードを出していた 以上の理由から悩んでは忘れるを一人繰り返しては日々を過ごしていました。 キャリアについて考えるようになった そんな中、昨年末に以下の記事を拝見しました。 生涯現役のソフトウェアエンジニアでありたい。IC(Individual Contributor)のキャリアパスがあると自覚するまで 10 年の軌跡 IC(Individual Contributor)というキャリアがあるのかというのと、記事中の主張から自分のキャリアについて振り返る様になりました。 これまでのキャリアは前述のようにかなり行きあたりばったりでしたが、その中にも不動となる主軸が 2 つありました。(中略) 1 つは「毎日楽しく開発したい」ということ。(中略) もう 1 つの軸は「選択肢を常に複数確保する」ことです。(中略) この「毎日楽しく開発したい」は、私がエンジニアになりたいと思った動機「楽しく(刺激的に)生きたい」に通じるものがあり、IC というキャリアないしはテクニカルスキルをあげることで自分の幸福につながるのかという気づきがありました。 遠回りのような近道のような、どちらとも言えないですが、自分で出した答えの1つが大学進学、それもコンピュータに関する学位を取得するということでした。 ここについては自分の中で消化しきれていない部分もあるので、別の記事で改めて振り返ることにします。 帝京大学に決めたのはそこまで時間がかからなかった フルタイムで働きながらコンピュータに関する学位が取得できる通信制大学は、調べた限りだと選択肢は限られました。 また、同じくエンジニアとして働きながら勉強されている方のブログが大変参考になりました。 帝京大学理工学部(通信教育課程)の社会人大学生 1 年目をふりかえる 帝京大学の通信教育課程の学生やってます @gkzvoice さんには twitter でブログに関して質問させていただき、またアドバイスまでいただいたので感謝です。 入るまでの手続きなど 詳細な手続きは募集要項にあるので、ここでは所感を述べるだけにします。 調査書、成績表の発行を、所属していた専門学校に依頼する必要があるので、余裕を持って出願する 志望理由を記載する必要があるので、動機と抱負は棚卸ししてたほうがスムーズかも 2 年次編入について 今回 2 年次編入で出願することができました。 というのも、情報系専門学校の 2 年制を卒業しているので、編入の要件を満たしていたからというのが理由です。 要件を満たしていれば、専門学校での授業内容がまとめられたシラバス?を願書と一緒に提出した後、大学にて専門学校の授業内容から、関連する大学側での科目が履修済みとして、認定されます。 今回は認定された科目が上限数に達していたので、晴れて編入することができたのでした。 そして入学しました 出願から約 2 ヶ月後、晴れて入学式を迎えることができました。

Hero Image
2021年の振り返り

はじめに 今年のふりかえりをするために個人ブログを数ヶ月ぶりに更新しています。 しばらくぶりに拙ブログを見ていて、ぜんぜんメンテしてなかったや。。の反省を強く感じたので来年はアウトプットをもっともっと増やします! 2021/01 とくに話すトピックはありませんでした。 読んでた本 改訂 2 版 みんなの Go 言語 Go プログラミング実践入門 標準ライブラリでゼロから Web アプリを作る 2021/02 とくに話すトピックはありませんでした。 読んでた本 達人プログラマー ―熟達に向けたあなたの旅― 第 2 版 2021/03 このころから年内に引っ越しを考えはじめました。 部屋に不満はありませんでしたが、ぼんやりと中央線沿い(=東京の西側)がかっこいいというイメージをもっていたので一人でちょくちょく出向いていました。 主に、杉並区エリア(中野/高円寺/阿佐ヶ谷/荻窪)を中心にまわっていました。 特に、荻窪にある杉並アニメーションミュージアムは、展示も楽しく見れますが、ミュージアムが入っている杉並会館の雰囲気が抜群にいいのでおすすめです。 2021/04 転職しました。社会人4年目にして3社目になります。 前職と同じくサーバーサイドのポジションです。 前職では、コロナ以降フルリモートでしたが、転職後は週3出社になりました。 出社になってからは、ランチをメンバーと取るようになり、コミュニケーションが増えたのがメリットに感じました。 仕事に関して前職では主に、Java/Go/Node.js での開発を2年ほどしていましたが、転職直後は Ruby on Rails での開発がメインになりました。 はじめての Ruby と Rails ということもあり、メンバーにはだいぶお世話になりながらも、プライベートではおすすめの参考書をかたっぱしから読む生活をしていました。 読んでた本 プロを目指す人のための Ruby 入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plus シリーズ) パーフェクト Ruby on Rails 【増補改訂版】 (Perfect series) リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) 2021/05 緊急事態宣言の期間に入り、ほぼフルリモートになりました。 この頃のコミットを見てみると、主に Rails プロジェクトでのバグフィックスや、小さな機能追加をしていました。

Hero Image
達人プログラマーとは

はじめに エンジニアとしてコードを書くようになって、もうすぐ2年というタイミングに差し掛かりました 心境の変化としては、がむしゃらに毎日のタスクを通して「動く」コードを書くことから、メンテナンスしやすいコードを意識することが多くなりました 「達人プログラマー」は、プログラマとして次のステップを踏み出そうというときにベストな一冊となっています 達人の哲学 ソフトウェアのエントロピーの話は心当たりがありすぎた エントロピー とは、物理学の用語で「ある系における無秩序の度合い」のことで、 時間が経つたびにエントロピーは増大していく ソフトウェアも同様に、時間が経つたびに無秩序になっていく これを 割れ窓理論 というメカニズムで説明していたのもわかりやすかった 窓が1枚割れているのを長期間放置しておくと、それをメンテナンスする気力もなくなるマインドが 植え付けられて、最終的には建物全体が破壊されていく ソフトウェアではこれを、悪い設計、誤った意思決定、質の悪いコードに見立てることができて、 放置しておくと潜在的なバグを生み出すことになりかねない こういった「割れた窓」を発見したと同時に速やかに修復するべきだ、そして時間がなくてもコメントを 残すといった何らかのアクションをしてくださいと言った主張だった 茹でガエルの話は、ある程度精神的に余裕がないと気づくことが難しいと感じた あっつあつの熱湯にカエルを放り込むとびっくりして飛び出してくるが、 常温の水にカエルを入れて段々と温度をあげていくと、カエルは気づかないまま茹で上がると言った話 要するに、いつもメタ認知を意識して行動しようということ これは仕事に限らずしていきたい 達人のアプローチ 章前半のDRY 原則については膝を叩いて同意できるといった実感があった また、曳光弾の考え方については目からウロコだった 複雑なシステムを構築していくときに、各機能を一つずつ作り込んでいくのではなく、各機能を最低限使えるようにするシンプルな箇所を探していくといった手法 シンプルな箇所に最初に取り組んでその他は後回しにする(未実装)というのは初心者視点では至らないと感じた 章後半のプロトタイプ、見積もりの話は現実でも問われることがあるものの、 実際に見積もりが大きく外れるような難しい設計をした経験がないということもあって実感が持てなかった 「言語の制約はそれを使う人の世界を制限する」 - ヴィトゲンシュタイン 毎回トピックの初めに、名言があってモチベーションが上がる プログラミング言語に限らず、日常使っている日本語にも問題に対する考え方や コミュニケーションに対する考え方に影響を及ぼしているという構造主義的な話もあって興味深い 基本的なツール 「悩んでいる君、そしてその悩みの原因は他の誰でもない、君自身によるものだ」 ということを知るのはつらいものだ - ソフォクレス デバッグの最初の心構え → 「パニクるな」 妄想の達人 契約プログラミング(DbC) は素晴らしい 仕様を記述(契約)しておくことで、プログラマにバグになりかねないようなことをさせないプログラミングをする トラッシュ(メチャクチャ)にするのではなく、クラッシュ(停止)させる Go のif err != nilで毎回エラーチェックしてるのはこれに則っているのかなと思った。 確かにcatchで新しいエラーがくるたびに分類するのは怠い気もするかな、、 柳に雪折れなし 列車の衝突事故を例にして依存をわかりやすく説明している 1つのメソッドであまりにも多くのことをやろうとすると、 連結されている全ての車両に影響が及ぶように、メソッドと属性が影響を受ける 例)割引料金を算出するメソッドの中で、これらの操作を行う。 顧客の注文履歴を参照する 注文履歴から特定の注文オブジェクトを取得する 注文オブジェクトの総額を返す 総額から割引した値をオブジェクトにセットする 次のような考え方がある 照会せずに依頼する TDA(Tell, Don’t Ask)

Hero Image
OAuth について

はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。 OAuth とは ひとまず、一番分かりやすい OAuth の説明で大体の感覚がつかめますのでオススメです。 こちらでもざっくり説明させてもらうと、OAuth は複数のアプリを連携させるための仕組みです。 例えば、ブログの記事を更新した瞬間に、ブログから更新情報をツイートしたかったりする場合に使われます。 ただ、そのままツイートできるわけではなくて、ブログアプリがツイートする許可(認可)をしてあげる必要があります。 そして許可されたアプリは許可証(アクセストークン)を持っていることで、Twitter を使ってツイートできるという仕組みです。 メリット OAuth を使うことで、上の例であげたブログアプリは、Twitter のユーザ名とパスワードを知らなくてもツイートできるという点です。 巷のアプリはこれを使うことで、Google アカウントや Twitter など SNS アカウントを持っているだけでユーザ登録できちゃいます。最初の煩わしい登録の手間が省けて良いです。 OAuth1.0 OAuth の初期バージョンです。他に 1.0a という名前のバージョンもありますが、Twitter では 1.0a を使うことができるみたいです。 (後述の 2.0 も同様に使用可) 特徴としては、認証と署名を用いて実現される仕様でありますが、実装が複雑で使用する言語が限られてしまうというデメリット?があるみたいです。(堅牢ではあると思いますが) また、1.0 は Web アプリのみ対応しているので、デスクトップ/モバイルアプリは蚊帳の外とこれまた制限されるみたいです。 (Twitter は Web アプリ以外でも使える xAuth という OAuth 拡張を開発したりしてたみたいです) さらに悲しいことに、1.0 の仕様は次の 2.0 の策定を持って廃止されたみたいです。 OAuth2.0 後継です。複雑と言われていた署名(とトークン交換)をバッサリ省いています。 これによって実装しやすいものになりましたがセキュリティが気になるところです。 OAuth 1.0 のほうが OAuth 2.0 より安全なの?でも言われている通り、2.0 はクライアントアプリケーションの幅が広がった分、秘密鍵の隠蔽が難しくなるみたいです。。 隠蔽できるかの違いはありますが、セキュリティレベルは両者それほど変わらないみたいです。 (2.0 は経路を TLS 化していることで、1.0 よりも提示するパラメータが少なくなっているという事実はあるそうな) まとめ 実装のことを考えてこれからも 2.0 を使っていきましょうという締めです。