diff --git a/404.html b/404.html index 4f018e10..bf4d1fb1 100644 --- a/404.html +++ b/404.html @@ -8,5 +8,5 @@
Page Not Found

404

The page you are looking for is not there yet.

\ No newline at end of file diff --git a/categories/aws/index.html b/categories/aws/index.html index 4851159e..eaf75654 100644 --- a/categories/aws/index.html +++ b/categories/aws/index.html @@ -16,5 +16,5 @@ パーティションキーはダミー列 ソートキーに日付 これで同じ日付範囲の複数データを引っ張ってくることが可能になります。 確かに美しいと言えないかもしれませんが、機転の効いた方法だと思いました。

Friday, June 5, 2020 Read
\ No newline at end of file diff --git a/categories/basic/index.html b/categories/basic/index.html index ceea06b7..39825051 100644 --- a/categories/basic/index.html +++ b/categories/basic/index.html @@ -41,7 +41,7 @@ 節目というか、ちょっと時間ができたので、私が履修している科目一覧を Notion で管理しようと思い立ち、さくっと作ってみました。 科目一覧 - Notion これから同じように学習される方の参考になれば幸いです。（私も諸先輩方のブログを見て、参考になったので恩返しできれば！） -近況 元気にやっています:pduck_b: +近況 元気にやっています👋 備考 表紙イラスト：Loose Drawing

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

はじめに 表題の通り、今年の 4 月から帝京大学理工学部情報科学科の通信教育課程に 2 年次編入しました。 そもそもの経緯と入るまでの話、入って 1 ヶ月経過した後の所感をまとめておきたいと思います。 @@ -96,5 +96,5 @@ 2021/05 緊急事態宣言の期間に入り、ほぼフルリモートになりました。 この頃のコミットを見てみると、主に Rails プロジェクトでのバグフィックスや、小さな機能追加をしていました。

Friday, December 31, 2021 Read
\ No newline at end of file diff --git a/categories/basic/index.xml b/categories/basic/index.xml index db45f632..422412dd 100644 --- a/categories/basic/index.xml +++ b/categories/basic/index.xml @@ -31,7 +31,7 @@ Kyash TechTalk #2 - Serverside のシステム構成とアーキテクチャ 節目というか、ちょっと時間ができたので、私が履修している科目一覧を Notion で管理しようと思い立ち、さくっと作ってみました。 科目一覧 - Notion これから同じように学習される方の参考になれば幸いです。（私も諸先輩方のブログを見て、参考になったので恩返しできれば！） -近況 元気にやっています:pduck_b: +近況 元気にやっています👋 備考 表紙イラスト：Loose Drawing【通信教育課程】帝京大学理工学部情報科学科に編入学しましたhttps://uh-zz.github.io/posts/category/look-back-on/2022/05/31/go-to-the-teikyo-university/Tue, 31 May 2022 18:07:06 +0900https://uh-zz.github.io/posts/category/look-back-on/2022/05/31/go-to-the-teikyo-university/はじめに 表題の通り、今年の 4 月から帝京大学理工学部情報科学科の通信教育課程に 2 年次編入しました。 そもそもの経緯と入るまでの話、入って 1 ヶ月経過した後の所感をまとめておきたいと思います。 きっかけ 大学進学について 通信制大学へ進学したいと思ったのは今年に入ってからではなく、ここ 2 年くらい検討していました。 diff --git a/categories/computer-science/index.html b/categories/computer-science/index.html index 020abdfa..da52429c 100644 --- a/categories/computer-science/index.html +++ b/categories/computer-science/index.html @@ -86,5 +86,5 @@ 子プロセスの fork 実行時の戻り値は 0 です。 (戻り値 0 は正常終了のステータスコード)そして親プロセスの fork 実行時の戻り値は子プロセスのプロセス ID です。

Sunday, July 5, 2020 Read
\ No newline at end of file diff --git a/categories/ddd/index.html b/categories/ddd/index.html index 0c9ea5c3..545e5621 100644 --- a/categories/ddd/index.html +++ b/categories/ddd/index.html @@ -46,5 +46,5 @@ 備考 現場で役立つシステム設計の原則 表紙イラスト：Loose Drawing

Saturday, December 5, 2020 Read
\ No newline at end of file diff --git a/categories/development/index.html b/categories/development/index.html index 781f42ab..7e39a2ee 100644 --- a/categories/development/index.html +++ b/categories/development/index.html @@ -64,5 +64,5 @@ まとめ 、、とすごく大変そうに見えますが(実際に大変ですが)、スクラムならではの団体戦みのある開発でまあうまく回せるんではないでしょうかというのが感想です。 備考 表紙イラスト：Loose Drawing

Friday, June 5, 2020 Read
\ No newline at end of file diff --git a/categories/dynamodb/index.html b/categories/dynamodb/index.html index 2b0d00fb..e9a9db7a 100644 --- a/categories/dynamodb/index.html +++ b/categories/dynamodb/index.html @@ -16,5 +16,5 @@ パーティションキーはダミー列 ソートキーに日付 これで同じ日付範囲の複数データを引っ張ってくることが可能になります。 確かに美しいと言えないかもしれませんが、機転の効いた方法だと思いました。

Friday, June 5, 2020 Read
\ No newline at end of file diff --git a/categories/go/index.html b/categories/go/index.html index 0d52c6f6..7c7eb623 100644 --- a/categories/go/index.html +++ b/categories/go/index.html @@ -48,5 +48,5 @@ 以下「ソートを極める！ 〜 なぜソートを学ぶのか 〜」を元に実装してみた（なるべくソースを見ないで実装を試みたがマージする箇所は折れた、、） package main import ( "fmt" "time" "github.com/uh-zz/traning/algorithm/shuffle" ) func main() { // ランダムな要素 n 個のスライス取得 input := shuffle.RandomIntList(n) inputLength := len(input) // マージソート MergeSort(&input, 0, inputLength) } // MergeSort マージソート func MergeSort(input \*[]int, left, right int) { // 要素数1つの場合は抜ける if right-left == 1 { return } // 配列を２つに分けるインデックス middle := left + (right-left)/2 // 配列左側 MergeSort(input, left, middle) // 配列右側 MergeSort(input, middle, right) var buffer []int // 左側と右側をバッファにためる（右側反転） for index := left; index < middle; index++ { buffer = append(buffer, (*input)[index]) } for index := right - 1; index >= middle; index-- { buffer = append(buffer, (*input)[index]) } // マージする scopeLeft := 0 scopeRight := len(buffer) - 1 for index := left; index < right; index++ { if buffer[scopeLeft] <= buffer[scopeRight] { // 左側採用 (*input)[index] = buffer[scopeLeft] scopeLeft++ } else { // 右側採用 (*input)[index] = buffer[scopeRight] scopeRight-- } } } これ考えたのぶっ飛んでるなあと思って Wikipedia 見てたら、考案者がフォン・ノイマンでやっぱりぶっ飛んでた（凄すぎ）

Sunday, July 5, 2020 Read
\ No newline at end of file diff --git a/categories/index.html b/categories/index.html index c3bcd159..a23dce4b 100644 --- a/categories/index.html +++ b/categories/index.html @@ -8,5 +8,5 @@
\ No newline at end of file diff --git a/categories/oauth/index.html b/categories/oauth/index.html index 5d573a22..9c831766 100644 --- a/categories/oauth/index.html +++ b/categories/oauth/index.html @@ -27,5 +27,5 @@ (2.0 は経路を TLS 化していることで、1.0 よりも提示するパラメータが少なくなっているという事実はあるそうな) まとめ 実装のことを考えてこれからも 2.0 を使っていきましょうという締めです。

Tuesday, January 5, 2021 Read
\ No newline at end of file diff --git a/categories/oss/index.html b/categories/oss/index.html index 65739ba8..23079343 100644 --- a/categories/oss/index.html +++ b/categories/oss/index.html @@ -17,5 +17,5 @@ 余談 たかがバージョニング、されどバージョニングといった感じでした。知ってて損はないですよね。 備考 表紙イラスト：Loose Drawing

Wednesday, August 5, 2020 Read
\ No newline at end of file diff --git a/categories/poem/index.html b/categories/poem/index.html index abe32b3e..9aa770fd 100644 --- a/categories/poem/index.html +++ b/categories/poem/index.html @@ -43,5 +43,5 @@ 顧客の注文履歴を参照する 注文履歴から特定の注文オブジェクトを取得する 注文オブジェクトの総額を返す 総額から割引した値をオブジェクトにセットする 次のような考え方がある 照会せずに依頼する TDA(Tell, Don’t Ask)

Friday, March 5, 2021 Read
\ No newline at end of file diff --git a/categories/security/index.html b/categories/security/index.html index b95eeb0a..fa22ec4a 100644 --- a/categories/security/index.html +++ b/categories/security/index.html @@ -27,5 +27,5 @@ (2.0 は経路を TLS 化していることで、1.0 よりも提示するパラメータが少なくなっているという事実はあるそうな) まとめ 実装のことを考えてこれからも 2.0 を使っていきましょうという締めです。

Tuesday, January 5, 2021 Read
\ No newline at end of file diff --git a/categories/system-design/index.html b/categories/system-design/index.html index 885ff4fd..9afa4263 100644 --- a/categories/system-design/index.html +++ b/categories/system-design/index.html @@ -46,5 +46,5 @@ 備考 現場で役立つシステム設計の原則 表紙イラスト：Loose Drawing

Saturday, December 5, 2020 Read
\ No newline at end of file diff --git a/en/about/index.html b/en/about/index.html index ca7c54d8..f7756b10 100644 --- a/en/about/index.html +++ b/en/about/index.html @@ -7,7 +7,7 @@ -
Author Image

Monday, January 1, 1

+
Author Image

Monday, January 1, 1

Improve this page
\ No newline at end of file diff --git a/en/index.html b/en/index.html index 8f89b8b5..e2017430 100644 --- a/en/index.html +++ b/en/index.html @@ -7,7 +7,7 @@
-
Hero Image

Monday, January 1, 1 +
Hero Image

Monday, January 1, 1 Read
\ No newline at end of file diff --git a/index.html b/index.html index 7279ceb5..bf0eff43 100644 --- a/index.html +++ b/index.html @@ -6,7 +6,7 @@ Recent Posts
  • Posts
    • Author Image

    uh-zz

    Reo Uehara

    Software Engineer -at Kyash Inc.

    I am a software engineer with 4 years of working experience. Also, I am working and studying computer science as a student.

    AWS Certified Solutions Architect - Associate

    Skills

    Experiences

    1
    Software Engineer
    Kyash Inc.

    Nov 2022 - Present, +at Kyash Inc.

    I am a software engineer with 6 years of working experience. Also, I am working and studying computer science as a student.

    AWS Certified Solutions Architect - Associate

    Skills

    Experiences

    1
    Software Engineer
    Kyash Inc.

    Nov 2022 - Present, Tokyo

    Kyash Inc. is develop an app that allows users to issue prepaid cards and easily make payments at stores and online.

    Software Engineer
    Fukurou Labo, inc.

    Apr 2021 - Oct 2022, Tokyo

    Fukurou Labo, inc. is plan, develop and provide Circuit X, an ad serving platform for apps.

    Responsibilities:
    • Design and develop Circuit X.
    • Create of development support tools.
    2
    3
    Software Engineer
    AvintonJapan Co.,Ltd.

    May 2019 - Mar 2021, Kanagawa

    AvintonJapan Co.,Ltd. is a business and IT consulting firm based in Japan.

    Responsibilities:
    • Design and develop Vehicle management system using drive recorders.
    • Create of development support tools.
    Network Engineer
    Toyo Systems Development Co.,Ltd.

    Apr 2018 - Apr 2019, @@ -79,5 +79,5 @@ 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.

    Saturday, December 10, 2022 Read
    \ No newline at end of file diff --git a/index.json b/index.json index d9b7cd52..42dc451f 100644 --- a/index.json +++ b/index.json @@ -1 +1 @@ -[{"categories":["Basic"],"contents":"はじめに １年経つのは早いですね。\n今年のサマリーとしては、通信大学へ入学したことと転職したこと、です。\n去年はこのブログの投稿を増やしていくと意気込んでいましたが実績は、、意気込みは大事なので来年も意気込んでいきます\u0026#x1f4aa;\n振り返りについては需要の有無に関わらず書いていきたいと思ってる所存です。\nバックナンバー 2021 年の振り返り 2022/01 とくに話すトピックはありませんでした。\n新年一発目こそなにかあれよ！と自分でツッコミを入れたくなったので、意識的に１月にイベントつくっていきます\n2022/02 コロナの感染拡大がまた出てきたころで、予定されていた開発合宿がオンラインでの開催になりました\n初のオンライン合宿開催！開発合宿についてご紹介！\nGatherはこのとき初めて使いましたが、会議室に入ると強制的にビデオ通話になったりホワイトボードを共有したりと Google Meet や Zoom のような使い方ができるのに加え、マップを自分たちでつくったりゴーカートができたりと、息抜き要素があったのが推しポイントです。\nこのとき気に入って、合宿のあともオンボーディングを Gather でやってたりもしたなぁと思い返したり\u0026#x1f60c;\n2022/03 とくに話すことはありませんでした。\n2022/04 ふらっと Kyash のイベントを見にいきました。\nKyash TechTalk #2 - Serverside のシステム構成とアーキテクチャ\nこのとき、Kyash のサーバ構成を知れたのもそうですが、苦労話や課題に思っていることを対外的に発信しているのを見て、技術力求められそうだなというのと、中の人楽しそうに話してるなと思ったのを覚えています。\nこのイベントのあと、メールでカジュアル面談のお誘いをもらったので、転職活動はしてなかったけど、興味本位でセッティングしてもらったのが今年の転職につながりました。\nまたプライベートな話題としては、通信大学に入学しました\n【通信教育課程】帝京大学理工学部情報科学科に編入学しました\n入ってから８ヶ月目で思うことは、年間 12 科目の単位を働きながら取るのは絶対ムリ！ではないかもしれませんが、ギリギリを攻めている感覚と怠惰な休日の時間を取りづらくなるということです。 これは勉強するリズムがついていいじゃないかという反面、興味が薄い科目に関して場当たり的な勉強をしてしまいがちなのと、休日を授業やレポートで埋めると休みが休みでなくなってしまう悲しみを少なからず感じるということです。\nこの振り返りは、来年 2 月の区切りのいいところで改めて記事にしようと思います。\n2022/05 ジムに行き始めました。きっかけはリモートワークをしていて一日座ってる時間が長いと寝つきが悪かったりするので、体を動かしてぐっすり眠りたい、と思ったからです 。\n今も継続して週に 2 回くらいは走りに行ってます。\n走るマシン（トレッドミル）しか活用できてないので、来年はほかのトレーニングにも手を出したいです。\n2022/06 とくに話すことはありませんでした。\n2022/07 通信大学の初めての単位習得試験があり、物理的な会場での受験でした。\n内心なにかしら交流があるかも\u0026#x1f60c;、とそわそわしていましたが、杞憂に終わりました。\n2022/08 昨年から月 1 で参加していた『プログラミング言語 Go』オンライン読書会が一区切りつきました。\n初めて参加した社外勉強会がこの読書会だったので、個人的に印象深く、毎回新しい知見を得る場として楽しませていただきました。\n今は柴田先生が主催するべつの読書会に参加していますが、相変わらず聞き専になってしまっているので、恥ずかしがらずに質問していくのを来年の抱負にしようと思います笑\n2022/09 今年は通信大学に入ったのを言い訳に、技術書以外の本を買ったり読んだりする機会が少なかったんですが、その中でも社会学のテキストが個人的に面白かったので、マイベストブックにノミネートしました。\n社会学 新版 (New Liberal Arts Selection) これまでぼんやり社会学を勉強したいなと思ってたところでこの本を強制的に読むことになり、ざっと主要なトピックを俯瞰することができました。\n個人的に、「文化と再生産」の話が好きです。\n2022/10 今年もしれっと hacktoberfest に参加していました。\nTシャツ届いてました〜thanks#Hacktoberfest pic.twitter.com/9K8N2eBpvg\n\u0026mdash; reo (@_uhzz_) March 2, 2022 以下の記事で紹介されているように、スパムが大量生産される問題を含みつつ、OSS 活動ををタイポ修正やちょっとしたバグフィックスから始められる、始めるモチベーションに使っています。（自分のプルリクがそうなっているかもしれないという思いもありつつ、健全な活動をしていると自分に言い聞かせています）\n「プログラムの修正を送ると T シャツがもらえる」キャンペーンが開発者に迷惑がられる理由とは？\n、とまあ今年も達成できたので、また特典が届いたたらツイートします。\nあとは、サウナ遠征（一人）で名古屋に行きました。 このときのスケジュールがスムーズすぎて、また来年遠征の予定を立て始めています笑\n※ツイート忘れてますが、ウェルビー栄デビューもこの遠征で達成しました\ncanal resortでととのいました pic.twitter.com/LxcUEt82Qu\n\u0026mdash; reo (@_uhzz_) October 27, 2022 ミライタワーだそうです pic.twitter.com/KRD0Vqy2QQ\n\u0026mdash; reo (@_uhzz_) October 27, 2022 2022/11 Kyash に入社しました\u0026#x1f44d;\n全体の感想としてカジュアル面談で話を聞いてから、選考に進み、オファーをいただくまでがすごく速かった気がします笑\n※このとき並行で数社選考を進めていたんですが、どのチームも魅力的だったとここで断っておきます\nその中でも、オンラインイベントで楽しそうに話してたのが忘れられず決断をしたのでした\nkyashに入社しました👍\n\u0026mdash; reo (@_uhzz_) November 1, 2022 ※転職エピソードについてはもっと語ることあるだろと自分にツッコミを入れつつ別途どこかで振り返ります。\n2022/12 Kyash に入って、初めて社のアドベントカレンダーに参加しました\n【Go】net/http パッケージで非推奨の Temporary の扱いについて\nあとは、Go アドベントカレンダーに今年も細々と投稿しました\n【Go/並行処理】Future パターンってなにか調べてみた！\nあとは、nilerrに影響を受けてnilpointerなるものを書いて静的解析ツールを作る実績も解除しました。\n作ったのはいいものの使い道なくね？と我に返ってしまい告知はしませんでしたが、ここで供養させていただこうと思います笑\nまとめ なにかアウトプットをたくさんしたという感じではないものの、人生してるなあという振り返りでした。\n来年の抱負は引き続きアウトプット増やすようにパブリックなコミットを意識しつつ、言い訳せずに積んでる本を消化します笑\nあとは、コミュニティに入れるように気持ち前のめりになって日々を過ごそうと思います。\n備考 表紙イラスト：Loose Drawing\n","date":"December 31, 2022","hero":"/posts/category/look-back-on/2022/12/31/hero.png","permalink":"https://uh-zz.github.io/posts/category/look-back-on/2022/12/31/","summary":"はじめに １年経つのは早いですね。\n今年のサマリーとしては、通信大学へ入学したことと転職したこと、です。\n去年はこのブログの投稿を増やしていくと意気込んでいましたが実績は、、意気込みは大事なので来年も意気込んでいきます\u0026#x1f4aa;\n振り返りについては需要の有無に関わらず書いていきたいと思ってる所存です。\nバックナンバー 2021 年の振り返り 2022/01 とくに話すトピックはありませんでした。\n新年一発目こそなにかあれよ！と自分でツッコミを入れたくなったので、意識的に１月にイベントつくっていきます\n2022/02 コロナの感染拡大がまた出てきたころで、予定されていた開発合宿がオンラインでの開催になりました\n初のオンライン合宿開催！開発合宿についてご紹介！\nGatherはこのとき初めて使いましたが、会議室に入ると強制的にビデオ通話になったりホワイトボードを共有したりと Google Meet や Zoom のような使い方ができるのに加え、マップを自分たちでつくったりゴーカートができたりと、息抜き要素があったのが推しポイントです。\nこのとき気に入って、合宿のあともオンボーディングを Gather でやってたりもしたなぁと思い返したり\u0026#x1f60c;\n2022/03 とくに話すことはありませんでした。\n2022/04 ふらっと Kyash のイベントを見にいきました。\nKyash TechTalk #2 - Serverside のシステム構成とアーキテクチャ\nこのとき、Kyash のサーバ構成を知れたのもそうですが、苦労話や課題に思っていることを対外的に発信しているのを見て、技術力求められそうだなというのと、中の人楽しそうに話してるなと思ったのを覚えています。\nこのイベントのあと、メールでカジュアル面談のお誘いをもらったので、転職活動はしてなかったけど、興味本位でセッティングしてもらったのが今年の転職につながりました。\nまたプライベートな話題としては、通信大学に入学しました\n【通信教育課程】帝京大学理工学部情報科学科に編入学しました\n入ってから８ヶ月目で思うことは、年間 12 科目の単位を働きながら取るのは絶対ムリ！ではないかもしれませんが、ギリギリを攻めている感覚と怠惰な休日の時間を取りづらくなるということです。 これは勉強するリズムがついていいじゃないかという反面、興味が薄い科目に関して場当たり的な勉強をしてしまいがちなのと、休日を授業やレポートで埋めると休みが休みでなくなってしまう悲しみを少なからず感じるということです。\nこの振り返りは、来年 2 月の区切りのいいところで改めて記事にしようと思います。\n2022/05 ジムに行き始めました。きっかけはリモートワークをしていて一日座ってる時間が長いと寝つきが悪かったりするので、体を動かしてぐっすり眠りたい、と思ったからです 。\n今も継続して週に 2 回くらいは走りに行ってます。\n走るマシン（トレッドミル）しか活用できてないので、来年はほかのトレーニングにも手を出したいです。\n2022/06 とくに話すことはありませんでした。\n2022/07 通信大学の初めての単位習得試験があり、物理的な会場での受験でした。\n内心なにかしら交流があるかも\u0026#x1f60c;、とそわそわしていましたが、杞憂に終わりました。\n2022/08 昨年から月 1 で参加していた『プログラミング言語 Go』オンライン読書会が一区切りつきました。\n初めて参加した社外勉強会がこの読書会だったので、個人的に印象深く、毎回新しい知見を得る場として楽しませていただきました。\n今は柴田先生が主催するべつの読書会に参加していますが、相変わらず聞き専になってしまっているので、恥ずかしがらずに質問していくのを来年の抱負にしようと思います笑\n2022/09 今年は通信大学に入ったのを言い訳に、技術書以外の本を買ったり読んだりする機会が少なかったんですが、その中でも社会学のテキストが個人的に面白かったので、マイベストブックにノミネートしました。\n社会学 新版 (New Liberal Arts Selection) これまでぼんやり社会学を勉強したいなと思ってたところでこの本を強制的に読むことになり、ざっと主要なトピックを俯瞰することができました。","tags":["Basic"],"title":"2022年の振り返り"},{"categories":["Go"],"contents":"はじめに こちらはKyash Advent Calendar 2022 の 13 日目の記事です。\n今年の 11 月に Kyash に入社しました！サーバサイドチームのueharaです\u0026#x1f44b;\n今回はnet/httpパッケージの非推奨メソッドであるTemporary()について、社のメンバーから知見を共有してもらったのでその話をします。\nnet/http パッケージの 非推奨メソッド Temporary() について Temporary()については、フューチャー社の記事にわかりやすくまとめられています。\nhttps://future-architect.github.io/articles/20220203a/\n上記の記事を踏まえて、ここでは非推奨になった経緯と対応について言及しようと思います。\nサッと概要を話すと、Temporary()はnet.Errorインターフェースに定義されているメソッドで、一時的なエラーかどうか判定するために用意されています。 ただし、「一時的」というのがうまく定義されていないとの理由で、こちらのメソッドは Go1.18 で非推奨になりました。\nnet.Error.Temporary has been deprecated. https://tip.golang.org/doc/go1.18\nTemporary()が非推奨になった経緯 前提として、net.Errorインターフェースは、以下のように定義されています ※ソースは Go 1.19 です\n// 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 \u0026#34;temporary\u0026#34; errors are timeouts, and the few exceptions are surprising. // Do not use this method. Temporary() bool } 非推奨になったときの issue を追ってみます\nhttps://github.com/golang/go/issues/45729\nissue によると、Temporary()を実装していて、かつ true を返している標準パッケージのメソッドは以下の２パターンになります。\nパターン 1: Timeout 系のエラーだけど、 Temporary() メソッドで true を返す context: context.DeadlineExceeded crypto/tls: All Dial timeouts. net: Various timeouts. net/http: Timeout when reading headers or bodies. (The error type is named httpError, but it is only used for timeouts.) net/http: Also, HTTP/2 timeout reading response headers. os: os.ErrDeadlineExceeded (defined in internal/poll) パターン 2: Timeout 系ではないエラーで Temporary() が true を返す(本来こっちだけの想定) net: ECONNRESET and ECONNABORTED errors returned by accept(). net: EAI_AGAIN errors returned by getaddrinfo(). syscall/syscall_plan9.go, syscall/syscall_unix.go, syscall/syscall_js.go,syscall/syscall_windows.go: EINTR, EMFILE, ENFILE, plus errors also considered timeouts: EAGAIN, EWOULDBLOCK, EBUSY, and ETIMEDOUT. (Some minor \u0026gt; variation between operating systems.) つまり、実際に「一時的なエラー」とみなされるエラーは、以下のようなシステムコールエラーとのことです。\nECONNRESET ECONNABORTED EAI_AGAIN EINTR EMFILE ENFILE EAGAIN EWOULDBLOCK EBUSY ETIMEDOUT 結論として、Timeout 系のエラーなのにTemporary()でtrueを返しているパターンを除くと、本来のTemporary()は少数のシステムコールエラーによるもの（few exceptions are surprising）である。しかし、前者をカウントしていることにより、Temporary()がtrueになるパターンが頻繁に発生してるように見えるため、Temporary()の定義が明確でないから非推奨にしたほうがいいんじゃね、とのことでした。\nlinter でも非推奨であることを警告されます 社のメンバーから共有してもらうきっかけになった問題です。\n以下のコードは、net.Errorインターフェースを満たし、Temporary()をつかうサンプルです\npackage main import ( \u0026#34;fmt\u0026#34; \u0026#34;net\u0026#34; ) type MyNetError struct{} func (m MyNetError) Error() string { return \u0026#34;my net error\u0026#34; } func (m MyNetError) Timeout() bool { return false } func (m MyNetError) Temporary() bool { return true } var _ net.Error = \u0026amp;MyNetError{} func myFunc() error { return MyNetError{} } func main() { if ne, ok := myFunc().(net.Error); ok \u0026amp;\u0026amp; ne.Temporary() { fmt.Println(ne.Error()) } } このプログラムを linter でチェックすると、以下のように警告が出ます。 linter のランナーに、golangci-lintをつかいます。\n$ golangci-lint run net.go:19:44: SA1019: ne.Temporary has been deprecated since Go 1.18 because it shouldn\u0026#39;t be used: Temporary errors are not well-defined. Most \u0026#34;temporary\u0026#34; errors are timeouts, and the few exceptions are surprising. Do not use this method. (staticcheck) if ne, ok := myError().(net.Error); ok \u0026amp;\u0026amp; ne.Temporary() { この警告を回避するために、２つの方法が挙げられます。\n回避方法１: Temporary() をつかわない シンプルにTemporary()を消してしまうパターンです\nif ne, ok := myError().(net.Error); ok { fmt.Println(ne.Error()) } ただし、標準パッケージではつかわれている箇所もあり、(限定的な)代替案についても議論されています。\n回避方法 2: linter のチェックをしない linter のチェックを行わないよう、ディレクティブを設定します。\ngolangci-lint で linter のチェックをスキップする https://golangci-lint.run/usage/false-positives/#nolint-directive\n//nolint:staticcheck if ne, ok := myError().(net.Error); ok \u0026amp;\u0026amp; ne.Temporary() { fmt.Println(ne.Error()) } 直接 staticcheck を実行する //lint:ignoreディレクティブをつかいます。\n//lint:ignore SA1019 no problem, thanks if ne, ok := myError().(net.Error); ok \u0026amp;\u0026amp; ne.Temporary() { fmt.Println(ne.Error()) } さいごに Temporary()で判定したいようなケースはなるべくさけて代替のエラーを見つけるのがよさそうですね\n学びとしては、非推奨になったきっかけの issue を読んでみて、標準パッケージを読むことに対する抵抗が少しなくなったような気がしたことです\u0026#x1f4a6;\n","date":"December 13, 2022","hero":"/posts/category/go/2022/12/kyash-advent-calendar/hero.png","permalink":"https://uh-zz.github.io/posts/category/go/2022/12/kyash-advent-calendar/","summary":"はじめに こちらはKyash Advent Calendar 2022 の 13 日目の記事です。\n今年の 11 月に Kyash に入社しました！サーバサイドチームのueharaです\u0026#x1f44b;\n今回はnet/httpパッケージの非推奨メソッドであるTemporary()について、社のメンバーから知見を共有してもらったのでその話をします。\nnet/http パッケージの 非推奨メソッド Temporary() について Temporary()については、フューチャー社の記事にわかりやすくまとめられています。\nhttps://future-architect.github.io/articles/20220203a/\n上記の記事を踏まえて、ここでは非推奨になった経緯と対応について言及しようと思います。\nサッと概要を話すと、Temporary()はnet.Errorインターフェースに定義されているメソッドで、一時的なエラーかどうか判定するために用意されています。 ただし、「一時的」というのがうまく定義されていないとの理由で、こちらのメソッドは Go1.18 で非推奨になりました。\nnet.Error.Temporary has been deprecated. https://tip.golang.org/doc/go1.18\nTemporary()が非推奨になった経緯 前提として、net.Errorインターフェースは、以下のように定義されています ※ソースは Go 1.19 です\n// 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 \u0026#34;temporary\u0026#34; errors are timeouts, and the few exceptions are surprising.","tags":["Go"],"title":"netパッケージで非推奨のTemporaryメソッドの扱いについて"},{"categories":["Go"],"contents":"はじめに @uh-zzです！\nこの記事は、Go Advent Calendar 2022の 10 日目の記事になります！\n今年は、個人的に色々なことに挑戦した年だったなあと振り返るとともに、去年のアドベントカレンダーからもう１年経つのか〜という気持ちです\nこの記事では、Go における Future パターンをご紹介できればと思います\nFuture パターンとは あるメソッドを呼び出すとします。 もしもオブジェクトが、そのメソッドを実行できる状態なら、実行します。 でも、実行できない状態なら、将来実行できる状態になるまで待つようにしたいとします。 その時に使えるのがこの Future パターンです。 future は「未来」という意味です\nもう少し正確にお話しましょう。 単にあるクラスに 「実行できる状態になるまで待つ」 という機能を入れるわけではありません。 すでに存在しているクラスに一皮かぶせて、 「実行できる状態になるまで待てるような機能を追加する」 というのが Future パターンです。\n出典: 結城浩, Future パターン, デザインパターン紹介\n上記の参考記事内では、Java をつかったマルチスレッドプログラミングで Future パターンが実装されています。\n引用箇所の説明がほぼすべてですが、イメージ図で補足するとこんな感じになります\nflowchart LR 呼び出し元 --\u0026gt; Futureメソッド -- 実行できるようになるまで待つ --\u0026gt; 処理するメソッド 呼び出し元と処理するメソッドの間に Future メソッドを挟むことで、Future メソッドがプロキシ的に働き、非同期的に処理するメソッドを実行できるようになっています。\nGo だとこんなかんじにかけるらしい 以下の記事で Future/Promiseという説明書されています\nhttps://ascii.jp/elem/000/001/486/1486902/\npackage main func readFile(path string) chan string { // ファイルを読み込み、その結果を返すFutureを返す promise := make(chan string) // readFile とは別のゴルーチンでファイルを読み出す go func() { content, err := os.ReadFile(path) if err != nil { fmt.Printf(\u0026#34;read error %s\\n\u0026#34;, err.Error()) close(promise) } else { // 約束を果たした promise \u0026lt;- string(content) } }() return promise } func printFunc(futureSource chan string) chan []string { // 文字列中の関数一覧を返すFutureを返す promise := make(chan []string) // printFunc とは別のゴルーチンで文字列操作する go func() { var result []string // futureSource は readFile で読みだしたファイルの中身です // // readFile(ファイル読み込み)が完了して、 futureSource(=promise) に // 中身が送信されるまでこの処理は実行されません for _, line := range strings.Split(\u0026lt;-futureSource, \u0026#34;\\n\u0026#34;) { if strings.HasPrefix(line, \u0026#34;func \u0026#34;) { result = append(result, line) } } // 約束を果たした promise \u0026lt;- result }() return promise } func main() { futureSource := readFile(\u0026#34;future_promise.go\u0026#34;) // 一見、 readFile が実行されたあとに、すぐ printFunc が実行されるように見えます // しかし、 printFunc の引数(futureSource)がチャネルになっているので、 // futureSourceが値を受信するまで関数内で、futureSource を使うことができない // // よって関数内で実行待ちが発生します futureFuncs := printFunc(futureSource) // チャネル(futureFuncs)を受信するまでブロック fmt.Println(strings.Join(\u0026lt;-futureFuncs, \u0026#34;\\n\u0026#34;)) } ※記事内にあるコードに、コメントを追記させていただきました。\u0026#x1f64f;\nJava で実現していた Future メソッドとは違い、Go ではチャネルをつかって実行待ちを表現できるようです。 main 関数だけ見ると、呼び出し側では同期的に見えますが、内部でチャネルによる非同期処理が行われています。\n実際に使われているところを深ぼってみた https://github.com/hashicorp/raft\nError()の実装はここ https://github.com/hashicorp/raft/blob/6b4e32088e0bda22ea219fc89b0ee47f420e2b0b/future.go#L168\nraft の apply だけを深堀りしてみるのもいいかもしれない\nおわりに Future パターンを取り上げてみましたが、蓋を開けてみるとチャネルを使った並行プログラミングでよく目にするような処理に、”名前がついてたんだ〜！”と思う方もいるでしょう（私のことです）\nパターンを知る → 使っている OSS を見にいく流れは体験としていいなと思ったので、来年も引き続きやっていきます\u0026#x1f44b;\n","date":"December 10, 2022","hero":"/posts/category/go/2022/12/qiita-advent-calender/hero.png","permalink":"https://uh-zz.github.io/posts/category/go/2022/12/qiita-advent-calender/","summary":"はじめに @uh-zzです！\nこの記事は、Go Advent Calendar 2022の 10 日目の記事になります！\n今年は、個人的に色々なことに挑戦した年だったなあと振り返るとともに、去年のアドベントカレンダーからもう１年経つのか〜という気持ちです\nこの記事では、Go における Future パターンをご紹介できればと思います\nFuture パターンとは あるメソッドを呼び出すとします。 もしもオブジェクトが、そのメソッドを実行できる状態なら、実行します。 でも、実行できない状態なら、将来実行できる状態になるまで待つようにしたいとします。 その時に使えるのがこの Future パターンです。 future は「未来」という意味です\nもう少し正確にお話しましょう。 単にあるクラスに 「実行できる状態になるまで待つ」 という機能を入れるわけではありません。 すでに存在しているクラスに一皮かぶせて、 「実行できる状態になるまで待てるような機能を追加する」 というのが Future パターンです。\n出典: 結城浩, Future パターン, デザインパターン紹介\n上記の参考記事内では、Java をつかったマルチスレッドプログラミングで Future パターンが実装されています。\n引用箇所の説明がほぼすべてですが、イメージ図で補足するとこんな感じになります\nflowchart LR 呼び出し元 --\u0026gt; Futureメソッド -- 実行できるようになるまで待つ --\u0026gt; 処理するメソッド 呼び出し元と処理するメソッドの間に Future メソッドを挟むことで、Future メソッドがプロキシ的に働き、非同期的に処理するメソッドを実行できるようになっています。\nGo だとこんなかんじにかけるらしい 以下の記事で Future/Promiseという説明書されています\nhttps://ascii.jp/elem/000/001/486/1486902/\npackage main func readFile(path string) chan string { // ファイルを読み込み、その結果を返すFutureを返す promise := make(chan string) // readFile とは別のゴルーチンでファイルを読み出す go func() { content, err := os.","tags":["Go"],"title":"Futureパターンが使われているOSSを見てみた"},{"categories":["Basic"],"contents":"ご連絡 4 月から通信大学での学習を始めて、もう少しで半年になります。\n節目というか、ちょっと時間ができたので、私が履修している科目一覧を Notion で管理しようと思い立ち、さくっと作ってみました。\n科目一覧 - Notion\nこれから同じように学習される方の参考になれば幸いです。（私も諸先輩方のブログを見て、参考になったので恩返しできれば！）\n近況 元気にやっています:pduck_b:\n備考 表紙イラスト：Loose Drawing\n","date":"September 4, 2022","hero":"/posts/category/look-back-on/2022/09/04/preview-courses-at-teikyo-univ/hero.png","permalink":"https://uh-zz.github.io/posts/category/look-back-on/2022/09/04/preview-courses-at-teikyo-univ/","summary":"ご連絡 4 月から通信大学での学習を始めて、もう少しで半年になります。\n節目というか、ちょっと時間ができたので、私が履修している科目一覧を Notion で管理しようと思い立ち、さくっと作ってみました。\n科目一覧 - Notion\nこれから同じように学習される方の参考になれば幸いです。（私も諸先輩方のブログを見て、参考になったので恩返しできれば！）\n近況 元気にやっています:pduck_b:\n備考 表紙イラスト：Loose Drawing","tags":["Basic"],"title":"履修科目一覧をNotionでつくりました"},{"categories":null,"contents":"はじめに 読んだ記事とか本のリンクを張っておきます\n読んだ記事 アーキテクトに求められるマインドとは / mindset for an architect\n「少なくとも、最悪ではないアーキテクチャを狙う」\n自分の中で新しい視点だった(常に選択肢の中で(世間的に)最善とされているものがいいという思考をしてる)\n「変更が容易であれば、最初から望ましいアーキテクチャを正確に設計しなければならないという、プレッシャーも少なくなる」\nRe: スクラム開発チームと業務委託エンジニアの相性が最悪だと思っている\nSpring で快適な DB 疎通ユニットテストライフを送りたい\nyaml、json、または csv などのファイルでテスト用データの事前投入や結果比較を容易にしてくれます\nDatabase RIder はテストメソッド単位で使用するデータファイルを指定できる\n友達に教えてもらった。テストデータをコードと別で、テスト前後の比較も簡単にしてくれるのはすごい。\n「“楽しくないけどお金のためにやる人”はやはり伸びない」まつもとゆきひろ氏が説く“プログラマーに向いている人”\n「ノーコードによって仕事が奪われるイメージはない」まつもとゆきひろ × 高橋直大 × 楠正憲が語る、これからのプログラマーの仕事\nAmazon DynamoDB: A Scalable, Predictably Performant, and Fully Managed NoSQL Database Service\nまだよんでない\nDomain-Driven Design Simplified.\nまだよんでない\n読んだ本 自分に気づく心理学-加藤 諦三(著)\nLean と DevOps の科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (impress top gear)-Nicole Forsgren Ph.D. (著), Jez Humble (著), Gene Kim (著), 武舎広幸 (翻訳), 武舎るみ (翻訳)\nJABEE 対応 技術者倫理入門-小出 泰士(著)\nやさしく学べる基礎物理-基礎物理教育研究会(編集)\n星の王子さま-サン=テグジュペリ(著)\n","date":"July 5, 2022","hero":"/images/default-hero.jpg","permalink":"https://uh-zz.github.io/posts/category/inputs/2022/07/","summary":"はじめに 読んだ記事とか本のリンクを張っておきます\n読んだ記事 アーキテクトに求められるマインドとは / mindset for an architect\n「少なくとも、最悪ではないアーキテクチャを狙う」\n自分の中で新しい視点だった(常に選択肢の中で(世間的に)最善とされているものがいいという思考をしてる)\n「変更が容易であれば、最初から望ましいアーキテクチャを正確に設計しなければならないという、プレッシャーも少なくなる」\nRe: スクラム開発チームと業務委託エンジニアの相性が最悪だと思っている\nSpring で快適な DB 疎通ユニットテストライフを送りたい\nyaml、json、または csv などのファイルでテスト用データの事前投入や結果比較を容易にしてくれます\nDatabase RIder はテストメソッド単位で使用するデータファイルを指定できる\n友達に教えてもらった。テストデータをコードと別で、テスト前後の比較も簡単にしてくれるのはすごい。\n「“楽しくないけどお金のためにやる人”はやはり伸びない」まつもとゆきひろ氏が説く“プログラマーに向いている人”\n「ノーコードによって仕事が奪われるイメージはない」まつもとゆきひろ × 高橋直大 × 楠正憲が語る、これからのプログラマーの仕事\nAmazon DynamoDB: A Scalable, Predictably Performant, and Fully Managed NoSQL Database Service\nまだよんでない\nDomain-Driven Design Simplified.\nまだよんでない\n読んだ本 自分に気づく心理学-加藤 諦三(著)\nLean と DevOps の科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (impress top gear)-Nicole Forsgren Ph.D. (著), Jez Humble (著), Gene Kim (著), 武舎広幸 (翻訳), 武舎るみ (翻訳)","tags":null,"title":"2022年07月に読んだ記事とか本とか"},{"categories":["Basic"],"contents":"はじめに 表題の通り、今年の 4 月から帝京大学理工学部情報科学科の通信教育課程に 2 年次編入しました。\nそもそもの経緯と入るまでの話、入って 1 ヶ月経過した後の所感をまとめておきたいと思います。\nきっかけ 大学進学について 通信制大学へ進学したいと思ったのは今年に入ってからではなく、ここ 2 年くらい検討していました。\n当初は理工系ではなく、社会学/哲学に興味があり、その方面の勉強がしたいと漠然と考えていました。\nただ 2 年の間、大学への入学を躊躇してたのは以下の理由がありました。\n通信制大学の卒業が難しい、また卒業率が低いといった情報を見て腰が重かった 働きながら時間が取れない、平日のフルタイムかつ出社している場合、早朝か、仕事から帰ってきて勉強時間を確保する必要が出てくるので、リモートできないと厳しい とりあえず入門書を買って積んでおけば自分で勉強できるし、進学しなくてもいいのでは？と諦めムードを出していた 以上の理由から悩んでは忘れるを一人繰り返しては日々を過ごしていました。\nキャリアについて考えるようになった そんな中、昨年末に以下の記事を拝見しました。\n生涯現役のソフトウェアエンジニアでありたい。IC（Individual Contributor）のキャリアパスがあると自覚するまで 10 年の軌跡\nIC(Individual Contributor)というキャリアがあるのかというのと、記事中の主張から自分のキャリアについて振り返る様になりました。\nこれまでのキャリアは前述のようにかなり行きあたりばったりでしたが、その中にも不動となる主軸が 2 つありました。(中略)\n1 つは「毎日楽しく開発したい」ということ。(中略)\nもう 1 つの軸は「選択肢を常に複数確保する」ことです。(中略)\nこの「毎日楽しく開発したい」は、私がエンジニアになりたいと思った動機「楽しく(刺激的に)生きたい」に通じるものがあり、IC というキャリアないしはテクニカルスキルをあげることで自分の幸福につながるのかという気づきがありました。\n遠回りのような近道のような、どちらとも言えないですが、自分で出した答えの１つが大学進学、それもコンピュータに関する学位を取得するということでした。\nここについては自分の中で消化しきれていない部分もあるので、別の記事で改めて振り返ることにします。\n帝京大学に決めたのはそこまで時間がかからなかった フルタイムで働きながらコンピュータに関する学位が取得できる通信制大学は、調べた限りだと選択肢は限られました。\nまた、同じくエンジニアとして働きながら勉強されている方のブログが大変参考になりました。\n帝京大学理工学部(通信教育課程)の社会人大学生 1 年目をふりかえる\n帝京大学の通信教育課程の学生やってます\n@gkzvoice さんには twitter でブログに関して質問させていただき、またアドバイスまでいただいたので感謝です。\n入るまでの手続きなど 詳細な手続きは募集要項にあるので、ここでは所感を述べるだけにします。\n調査書、成績表の発行を、所属していた専門学校に依頼する必要があるので、余裕を持って出願する 志望理由を記載する必要があるので、動機と抱負は棚卸ししてたほうがスムーズかも 2 年次編入について 今回 2 年次編入で出願することができました。\nというのも、情報系専門学校の 2 年制を卒業しているので、編入の要件を満たしていたからというのが理由です。\n要件を満たしていれば、専門学校での授業内容がまとめられたシラバス？を願書と一緒に提出した後、大学にて専門学校の授業内容から、関連する大学側での科目が履修済みとして、認定されます。\n今回は認定された科目が上限数に達していたので、晴れて編入することができたのでした。\nそして入学しました 出願から約 2 ヶ月後、晴れて入学式を迎えることができました。\n日本武道館で約 1 時間のコンパクトな式が執り行なわれ、あれよあれよと駅に流れ着き帰宅しました。\n早起き成功して入学式参加してきました、午後からはお仕事します pic.twitter.com/tnncLx3J7x\n\u0026mdash; reo (@_uhzz_) April 4, 2022 社会人なので、午後からはお仕事しました\n1 ヶ月が経過して 学生という自覚を少し感じるようになりました。\nここ数日はレポート期限と授業の多さにやられていてどこか上の空でした。（まだ試験が残っているのでしばらくはこの状態が続きそう）\n今回、履修登録した科目と進捗状況についても別の記事でまとめます。\nまとめ 通学してないこともあり、社会人大学生になった自覚は正直実感しにくいというのが所感です。\nただ勉強する習慣ができつつあることや、レポートを通してドキュメンテーションの大切さを日々感じるようにはなりました。\n今後はブログを通して、進捗や所感をアウトプットしていければなとぼんやり考えています。\n本業と学業、どちらも進捗出していくぞ〜\n備考 表紙イラスト：Loose Drawing\n","date":"May 31, 2022","hero":"/posts/category/look-back-on/2022/05/31/go-to-the-teikyo-university/hero.png","permalink":"https://uh-zz.github.io/posts/category/look-back-on/2022/05/31/go-to-the-teikyo-university/","summary":"はじめに 表題の通り、今年の 4 月から帝京大学理工学部情報科学科の通信教育課程に 2 年次編入しました。\nそもそもの経緯と入るまでの話、入って 1 ヶ月経過した後の所感をまとめておきたいと思います。\nきっかけ 大学進学について 通信制大学へ進学したいと思ったのは今年に入ってからではなく、ここ 2 年くらい検討していました。\n当初は理工系ではなく、社会学/哲学に興味があり、その方面の勉強がしたいと漠然と考えていました。\nただ 2 年の間、大学への入学を躊躇してたのは以下の理由がありました。\n通信制大学の卒業が難しい、また卒業率が低いといった情報を見て腰が重かった 働きながら時間が取れない、平日のフルタイムかつ出社している場合、早朝か、仕事から帰ってきて勉強時間を確保する必要が出てくるので、リモートできないと厳しい とりあえず入門書を買って積んでおけば自分で勉強できるし、進学しなくてもいいのでは？と諦めムードを出していた 以上の理由から悩んでは忘れるを一人繰り返しては日々を過ごしていました。\nキャリアについて考えるようになった そんな中、昨年末に以下の記事を拝見しました。\n生涯現役のソフトウェアエンジニアでありたい。IC（Individual Contributor）のキャリアパスがあると自覚するまで 10 年の軌跡\nIC(Individual Contributor)というキャリアがあるのかというのと、記事中の主張から自分のキャリアについて振り返る様になりました。\nこれまでのキャリアは前述のようにかなり行きあたりばったりでしたが、その中にも不動となる主軸が 2 つありました。(中略)\n1 つは「毎日楽しく開発したい」ということ。(中略)\nもう 1 つの軸は「選択肢を常に複数確保する」ことです。(中略)\nこの「毎日楽しく開発したい」は、私がエンジニアになりたいと思った動機「楽しく(刺激的に)生きたい」に通じるものがあり、IC というキャリアないしはテクニカルスキルをあげることで自分の幸福につながるのかという気づきがありました。\n遠回りのような近道のような、どちらとも言えないですが、自分で出した答えの１つが大学進学、それもコンピュータに関する学位を取得するということでした。\nここについては自分の中で消化しきれていない部分もあるので、別の記事で改めて振り返ることにします。\n帝京大学に決めたのはそこまで時間がかからなかった フルタイムで働きながらコンピュータに関する学位が取得できる通信制大学は、調べた限りだと選択肢は限られました。\nまた、同じくエンジニアとして働きながら勉強されている方のブログが大変参考になりました。\n帝京大学理工学部(通信教育課程)の社会人大学生 1 年目をふりかえる\n帝京大学の通信教育課程の学生やってます\n@gkzvoice さんには twitter でブログに関して質問させていただき、またアドバイスまでいただいたので感謝です。\n入るまでの手続きなど 詳細な手続きは募集要項にあるので、ここでは所感を述べるだけにします。\n調査書、成績表の発行を、所属していた専門学校に依頼する必要があるので、余裕を持って出願する 志望理由を記載する必要があるので、動機と抱負は棚卸ししてたほうがスムーズかも 2 年次編入について 今回 2 年次編入で出願することができました。\nというのも、情報系専門学校の 2 年制を卒業しているので、編入の要件を満たしていたからというのが理由です。\n要件を満たしていれば、専門学校での授業内容がまとめられたシラバス？を願書と一緒に提出した後、大学にて専門学校の授業内容から、関連する大学側での科目が履修済みとして、認定されます。\n今回は認定された科目が上限数に達していたので、晴れて編入することができたのでした。\nそして入学しました 出願から約 2 ヶ月後、晴れて入学式を迎えることができました。","tags":["Basic"],"title":"【通信教育課程】帝京大学理工学部情報科学科に編入学しました"},{"categories":["Basic"],"contents":"はじめまして！\nこのページでは、いくつか自己紹介をしたいと思います。\n内容に関しては追って更新しますので、しばらくお待ちくださいませ。\n※「待てないよ!早く知りたい!」という意見がありましたら、お気軽に Twitter にてご連絡ください。\n備考 表紙イラスト：Loose Drawing\n","date":"May 5, 2022","hero":"/posts/introduction/hero.png","permalink":"https://uh-zz.github.io/posts/introduction/","summary":"はじめまして！\nこのページでは、いくつか自己紹介をしたいと思います。\n内容に関しては追って更新しますので、しばらくお待ちくださいませ。\n※「待てないよ!早く知りたい!」という意見がありましたら、お気軽に Twitter にてご連絡ください。\n備考 表紙イラスト：Loose Drawing","tags":["Basic"],"title":"Introduction"},{"categories":["Basic"],"contents":"はじめに 今年のふりかえりをするために個人ブログを数ヶ月ぶりに更新しています。\nしばらくぶりに拙ブログを見ていて、ぜんぜんメンテしてなかったや。。の反省を強く感じたので来年はアウトプットをもっともっと増やします！\n2021/01 とくに話すトピックはありませんでした。\n読んでた本 改訂 2 版 みんなの Go 言語\nGo プログラミング実践入門　標準ライブラリでゼロから Web アプリを作る\n2021/02 とくに話すトピックはありませんでした。\n読んでた本 達人プログラマー ―熟達に向けたあなたの旅― 第 2 版 2021/03 このころから年内に引っ越しを考えはじめました。\n部屋に不満はありませんでしたが、ぼんやりと中央線沿い(=東京の西側)がかっこいいというイメージをもっていたので一人でちょくちょく出向いていました。\n主に、杉並区エリア(中野/高円寺/阿佐ヶ谷/荻窪)を中心にまわっていました。\n特に、荻窪にある杉並アニメーションミュージアムは、展示も楽しく見れますが、ミュージアムが入っている杉並会館の雰囲気が抜群にいいのでおすすめです。\n2021/04 転職しました。社会人４年目にして３社目になります。\n前職と同じくサーバーサイドのポジションです。\n前職では、コロナ以降フルリモートでしたが、転職後は週３出社になりました。\n出社になってからは、ランチをメンバーと取るようになり、コミュニケーションが増えたのがメリットに感じました。\n仕事に関して前職では主に、Java/Go/Node.js での開発を２年ほどしていましたが、転職直後は Ruby on Rails での開発がメインになりました。\nはじめての Ruby と Rails ということもあり、メンバーにはだいぶお世話になりながらも、プライベートではおすすめの参考書をかたっぱしから読む生活をしていました。\n読んでた本 プロを目指す人のための Ruby 入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plus シリーズ)\nパーフェクト Ruby on Rails 【増補改訂版】 (Perfect series)\nリーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)\n2021/05 緊急事態宣言の期間に入り、ほぼフルリモートになりました。\nこの頃のコミットを見てみると、主に Rails プロジェクトでのバグフィックスや、小さな機能追加をしていました。\n(レビューでいろいろ教えてくれたメンバーには感謝です 💦)\nコードレビューに関して前職ではほぼ対面レビューだったのに対して、転職してからは Github 上でのレビューに切り替わったことで、レビュアー以外のメンバーにも非同期的にチェックしてもらえたのがすごくよかったです。\n2021/06 コミットを見てみると、この頃に担当したタスクにだいぶ時間を割いていました。\nというのも、タスクを進める上で発生した海外担当者とのメールであくせくしていた思い出があります。\n慣れない英語メールのやり取りが長引いてしまったものの、説明するのに必要なドメイン知識の理解がだいぶ進んだので、トレードオフだったのかなあと後になって感じています。\n読んでた本 インタフェースデザインの心理学 第 2 版 ―ウェブやアプリに新たな視点をもたらす 100 の指針\nNO RULES(ノー・ルールズ) 世界一「自由」な会社、NETFLIX\n2021/07 この月から、「プログラミング言語 Go」オンライン読書会に参加するようになりました。\n月に 1 度の読書会ですが、毎回新しい発見があって楽しいです。\nプライベートではそろそろ引っ越しをしようと suumo を見ていて、何件かピックアップして不動産に行きました。\nピックアップした物件ではなかったものの、ちょうどその日に空いた物件を一番乗りで見に行くことになり、初日で即決しました。\n当初の予定通り、中央線沿いに決まったのでこの頃は浮かれていました。\n2021/08 社外のオンライン LTに参加したりしました。\n2021/09 この頃のコミットを見ると、社内での Go プロジェクトへのコミットが少しずつ増えてきました。\nプライベートでは、一人散歩でよく歩いてました。\nよかったコース 国営昭和記念公園\n新宿御苑\n読んだ本 プリンシプル オブ プログラミング 3 年目までに身につけたい 一生役立つ 101 の原理原則 2021/10 この頃、ようやく緊急事態宣言が解除されました。\n開発合宿があり、LTなどしました。\nプライベートでは、hacktoberfestに参加したりしました。\n初参加かつ、OSS も初めてではありましたが、コミットできそうなリポジトリに５つプルリクエストを出しました。\nT シャツ獲得！の要件を満たしたので現在、発送待ちです。（届いたらツイートします）\n2021/11 Go Conference 2021 Autumnにボランティアスタッフで参加させていただきました。\nパートナーやスタッフに、社のロゴや twitter アカウントを載せてもらえたのは感無量でした。\n(運営の方ありがとうございます！)\n来年は、もっともっと関わっていくぞ〜の気持ちになりました。\n読んだ本 Software Design (ソフトウェアデザイン) 2021 年 12 月号 2021/12 Go に対する機運が社内でも高まってきました。(有志で勉強会を開くようになりました。)\nまた、個人的にGo アドベントカレンダーにも初参加してみました。\n読んだ本 達人に学ぶ SQL 徹底指南書 第 2 版 初級者で終わりたくないあなたへ まとめ 今年は、転職＆引っ越しと、いろいろ変化の多い年でした。\nあと、少しずつ社外のイベント/コミュニティにも参加できるようになってきました。\n来年は、アウトプットを増やして、社と私の認知度を上げていくのを目標にします。\n（コミュニティ活動も積極的に参加していくぞ〜！！）\n備考 表紙イラスト：Loose Drawing\n","date":"December 31, 2021","hero":"/posts/category/look-back-on/2021/hero.png","permalink":"https://uh-zz.github.io/posts/category/look-back-on/2021/","summary":"はじめに 今年のふりかえりをするために個人ブログを数ヶ月ぶりに更新しています。\nしばらくぶりに拙ブログを見ていて、ぜんぜんメンテしてなかったや。。の反省を強く感じたので来年はアウトプットをもっともっと増やします！\n2021/01 とくに話すトピックはありませんでした。\n読んでた本 改訂 2 版 みんなの Go 言語\nGo プログラミング実践入門　標準ライブラリでゼロから Web アプリを作る\n2021/02 とくに話すトピックはありませんでした。\n読んでた本 達人プログラマー ―熟達に向けたあなたの旅― 第 2 版 2021/03 このころから年内に引っ越しを考えはじめました。\n部屋に不満はありませんでしたが、ぼんやりと中央線沿い(=東京の西側)がかっこいいというイメージをもっていたので一人でちょくちょく出向いていました。\n主に、杉並区エリア(中野/高円寺/阿佐ヶ谷/荻窪)を中心にまわっていました。\n特に、荻窪にある杉並アニメーションミュージアムは、展示も楽しく見れますが、ミュージアムが入っている杉並会館の雰囲気が抜群にいいのでおすすめです。\n2021/04 転職しました。社会人４年目にして３社目になります。\n前職と同じくサーバーサイドのポジションです。\n前職では、コロナ以降フルリモートでしたが、転職後は週３出社になりました。\n出社になってからは、ランチをメンバーと取るようになり、コミュニケーションが増えたのがメリットに感じました。\n仕事に関して前職では主に、Java/Go/Node.js での開発を２年ほどしていましたが、転職直後は Ruby on Rails での開発がメインになりました。\nはじめての Ruby と Rails ということもあり、メンバーにはだいぶお世話になりながらも、プライベートではおすすめの参考書をかたっぱしから読む生活をしていました。\n読んでた本 プロを目指す人のための Ruby 入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plus シリーズ)\nパーフェクト Ruby on Rails 【増補改訂版】 (Perfect series)\nリーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)\n2021/05 緊急事態宣言の期間に入り、ほぼフルリモートになりました。\nこの頃のコミットを見てみると、主に Rails プロジェクトでのバグフィックスや、小さな機能追加をしていました。","tags":["Basic"],"title":"2021年の振り返り"},{"categories":["Development","poem"],"contents":"はじめに エンジニアとしてコードを書くようになって、もうすぐ２年というタイミングに差し掛かりました\n心境の変化としては、がむしゃらに毎日のタスクを通して「動く」コードを書くことから、メンテナンスしやすいコードを意識することが多くなりました\n「達人プログラマー」は、プログラマとして次のステップを踏み出そうというときにベストな一冊となっています\n達人の哲学 ソフトウェアのエントロピーの話は心当たりがありすぎた\nエントロピー とは、物理学の用語で「ある系における無秩序の度合い」のことで、 時間が経つたびにエントロピーは増大していく\nソフトウェアも同様に、時間が経つたびに無秩序になっていく\nこれを 割れ窓理論 というメカニズムで説明していたのもわかりやすかった\n窓が１枚割れているのを長期間放置しておくと、それをメンテナンスする気力もなくなるマインドが 植え付けられて、最終的には建物全体が破壊されていく\nソフトウェアではこれを、悪い設計、誤った意思決定、質の悪いコードに見立てることができて、 放置しておくと潜在的なバグを生み出すことになりかねない\nこういった「割れた窓」を発見したと同時に速やかに修復するべきだ、そして時間がなくてもコメントを 残すといった何らかのアクションをしてくださいと言った主張だった\n茹でガエルの話は、ある程度精神的に余裕がないと気づくことが難しいと感じた\nあっつあつの熱湯にカエルを放り込むとびっくりして飛び出してくるが、 常温の水にカエルを入れて段々と温度をあげていくと、カエルは気づかないまま茹で上がると言った話\n要するに、いつもメタ認知を意識して行動しようということ\nこれは仕事に限らずしていきたい\n達人のアプローチ 章前半のDRY 原則については膝を叩いて同意できるといった実感があった\nまた、曳光弾の考え方については目からウロコだった\n複雑なシステムを構築していくときに、各機能を一つずつ作り込んでいくのではなく、各機能を最低限使えるようにするシンプルな箇所を探していくといった手法\nシンプルな箇所に最初に取り組んでその他は後回しにする（未実装）というのは初心者視点では至らないと感じた\n章後半のプロトタイプ、見積もりの話は現実でも問われることがあるものの、 実際に見積もりが大きく外れるような難しい設計をした経験がないということもあって実感が持てなかった\n「言語の制約はそれを使う人の世界を制限する」 - ヴィトゲンシュタイン\n毎回トピックの初めに、名言があってモチベーションが上がる\nプログラミング言語に限らず、日常使っている日本語にも問題に対する考え方や コミュニケーションに対する考え方に影響を及ぼしているという構造主義的な話もあって興味深い\n基本的なツール 「悩んでいる君、そしてその悩みの原因は他の誰でもない、君自身によるものだ」 ということを知るのはつらいものだ\n- ソフォクレス\nデバッグの最初の心構え → 「パニクるな」\n妄想の達人 契約プログラミング(DbC) は素晴らしい\n仕様を記述(契約)しておくことで、プログラマにバグになりかねないようなことをさせないプログラミングをする\nトラッシュ（メチャクチャ）にするのではなく、クラッシュ（停止）させる\nGo のif err != nilで毎回エラーチェックしてるのはこれに則っているのかなと思った。\n確かにcatchで新しいエラーがくるたびに分類するのは怠い気もするかな、、\n柳に雪折れなし 列車の衝突事故を例にして依存をわかりやすく説明している\n１つのメソッドであまりにも多くのことをやろうとすると、 連結されている全ての車両に影響が及ぶように、メソッドと属性が影響を受ける\n例)割引料金を算出するメソッドの中で、これらの操作を行う。\n顧客の注文履歴を参照する 注文履歴から特定の注文オブジェクトを取得する 注文オブジェクトの総額を返す 総額から割引した値をオブジェクトにセットする 次のような考え方がある\n照会せずに依頼する TDA(Tell, Don\u0026rsquo;t Ask)\nつまり、取得した結果でオブジェクトを更新するのではなく、 メソッドに更新や参照を依頼する\nデメテルの法則\nプログラミングはコードについての話であるが、プログラムはデータについての話である\n継承は「結合」\n継承の代わり以下のテクニックを使用する\nインターフェースとプロトコル 委譲 mixin と trait ポリモーフィズムを表現するためにインターフェースを愛用する\n設定をサービス API の背後に配置する\n並行性 時間的な結合を破壊する\n並行性を向上させるためにワークフローを分析する\n並行処理を考えるときは時間のかかる手順を見つけることが大事\n並行処理はソフトウェアのメカニズムであり、並列処理はハードウェアの関心事です　← 大事!!\n共有状態は間違った状態　←泣\nセマフォー とは、ある時点で誰か一人しか占有できない「なんらかのもの」\n相互排他形式を説明するためのキーワード\nアクターとプロセス\nアクター とは局所的かつ固有の状態を保持した、独立した仮想プロセッサ\n各アクターはメールボックスを備えている\nメールボックスにメッセージが届くと、アクターが待機中の場合はメッセージ処理を始める\n処理が完了すると、メールボックス内の別のメッセージを処理する\nメールボックスが空だと、アクターは待機状態に戻る\nメッセージを処理するときに、アクターは他アクターを生成したり、アクター同士でメッセージを送ったりする\n次のメッセージを処理する時に遷移する新たな状態をつくることもできる\nプロセス とは汎用プロセッサのことであり、並行処理を簡単にするために OS によって実装される\nプロセスはアクターのように振る舞う制約が課されている\n共有状態を持たないアクターを並行処理で使用する\nアクターモデルでは明示的な並行処理が必要ない → 状態を保持しないため\nコーディング段階 偶発的プログラミングを行わないこと\n新人に対して、コードの詳細をできるか\n→ できない場合は偶発的プログラミングに頼ってる可能性あり\n仮定をドキュメント化する。\n他メンバーとのコミュニケーションを効率化したり、心の中にある仮定を明確にする\n→ 契約による設計(DbC)が参考になる\n過去のしがらみにとらわれてはいけない。 既存のコードによって未来のコードが影響されないようにする\n自分の行った作業が次に行う作業の制約になってはいけない ←大事!!\nアルゴリズムのオーダーを見積もること\nソフトウェアは「建築」ではなく「ガーデニング」に近い ←大事!!\nリファクタリングはごくたまにしか実行しない特別かつ高尚な儀式的アクティビティ ではない\n雑草抜きや落ち葉をかき集めるようなリスクの低い、ちょっとした作業を 日々実施するアクティビティである。\nテストとはバグを見つけることではない\nテストの利点は、テストについて考え、テストを記述しているときにあり、 テストを実行しているときではない\n→ テストを契約と見做せば重要度とモチベーションの変化になるのではないか\n象を一頭食べるにはどうすれば良いか\n→ 一口ずつ食べる ←大事!!\n明確な目的地を心に描けてなかった場合、どのような方法論であっても 堂々巡りになってしまう可能性がある。 ←泣\nプロジェクトを始める前に ひとりぼっちでコーディングに取り組んではいけない\n達人のプロジェクト 猫の群れを飼い慣らすことに匹敵するほど、優秀なプログラマーをまとめるのは難しい\n50 人はチームとは言わずに「群れ」といった方がしっくりくる\n事を成し遂げるにはまずスケジュールする\nカーゴカルト的な手法は、開発においてもテストやツールにおいても危険\nユーザーが必要としたタイミングで調達すること\n早めにテスト、何度もテスト、自動でテスト\nまとめ このタイミングで１周できたのは幸運でした。\n折に触れてて再読したいと思います。\n備考 表紙イラスト：Loose Drawing\n","date":"March 5, 2021","hero":"/posts/category/development/2021/03/pragmatic-programmer/hero.png","permalink":"https://uh-zz.github.io/posts/category/development/2021/03/pragmatic-programmer/","summary":"はじめに エンジニアとしてコードを書くようになって、もうすぐ２年というタイミングに差し掛かりました\n心境の変化としては、がむしゃらに毎日のタスクを通して「動く」コードを書くことから、メンテナンスしやすいコードを意識することが多くなりました\n「達人プログラマー」は、プログラマとして次のステップを踏み出そうというときにベストな一冊となっています\n達人の哲学 ソフトウェアのエントロピーの話は心当たりがありすぎた\nエントロピー とは、物理学の用語で「ある系における無秩序の度合い」のことで、 時間が経つたびにエントロピーは増大していく\nソフトウェアも同様に、時間が経つたびに無秩序になっていく\nこれを 割れ窓理論 というメカニズムで説明していたのもわかりやすかった\n窓が１枚割れているのを長期間放置しておくと、それをメンテナンスする気力もなくなるマインドが 植え付けられて、最終的には建物全体が破壊されていく\nソフトウェアではこれを、悪い設計、誤った意思決定、質の悪いコードに見立てることができて、 放置しておくと潜在的なバグを生み出すことになりかねない\nこういった「割れた窓」を発見したと同時に速やかに修復するべきだ、そして時間がなくてもコメントを 残すといった何らかのアクションをしてくださいと言った主張だった\n茹でガエルの話は、ある程度精神的に余裕がないと気づくことが難しいと感じた\nあっつあつの熱湯にカエルを放り込むとびっくりして飛び出してくるが、 常温の水にカエルを入れて段々と温度をあげていくと、カエルは気づかないまま茹で上がると言った話\n要するに、いつもメタ認知を意識して行動しようということ\nこれは仕事に限らずしていきたい\n達人のアプローチ 章前半のDRY 原則については膝を叩いて同意できるといった実感があった\nまた、曳光弾の考え方については目からウロコだった\n複雑なシステムを構築していくときに、各機能を一つずつ作り込んでいくのではなく、各機能を最低限使えるようにするシンプルな箇所を探していくといった手法\nシンプルな箇所に最初に取り組んでその他は後回しにする（未実装）というのは初心者視点では至らないと感じた\n章後半のプロトタイプ、見積もりの話は現実でも問われることがあるものの、 実際に見積もりが大きく外れるような難しい設計をした経験がないということもあって実感が持てなかった\n「言語の制約はそれを使う人の世界を制限する」 - ヴィトゲンシュタイン\n毎回トピックの初めに、名言があってモチベーションが上がる\nプログラミング言語に限らず、日常使っている日本語にも問題に対する考え方や コミュニケーションに対する考え方に影響を及ぼしているという構造主義的な話もあって興味深い\n基本的なツール 「悩んでいる君、そしてその悩みの原因は他の誰でもない、君自身によるものだ」 ということを知るのはつらいものだ\n- ソフォクレス\nデバッグの最初の心構え → 「パニクるな」\n妄想の達人 契約プログラミング(DbC) は素晴らしい\n仕様を記述(契約)しておくことで、プログラマにバグになりかねないようなことをさせないプログラミングをする\nトラッシュ（メチャクチャ）にするのではなく、クラッシュ（停止）させる\nGo のif err != nilで毎回エラーチェックしてるのはこれに則っているのかなと思った。\n確かにcatchで新しいエラーがくるたびに分類するのは怠い気もするかな、、\n柳に雪折れなし 列車の衝突事故を例にして依存をわかりやすく説明している\n１つのメソッドであまりにも多くのことをやろうとすると、 連結されている全ての車両に影響が及ぶように、メソッドと属性が影響を受ける\n例)割引料金を算出するメソッドの中で、これらの操作を行う。\n顧客の注文履歴を参照する 注文履歴から特定の注文オブジェクトを取得する 注文オブジェクトの総額を返す 総額から割引した値をオブジェクトにセットする 次のような考え方がある\n照会せずに依頼する TDA(Tell, Don\u0026rsquo;t Ask)","tags":["Development","poem"],"title":"達人プログラマーとは"},{"categories":["security","oauth"],"contents":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\nOAuth とは ひとまず、一番分かりやすい OAuth の説明で大体の感覚がつかめますのでオススメです。\nこちらでもざっくり説明させてもらうと、OAuth は複数のアプリを連携させるための仕組みです。\n例えば、ブログの記事を更新した瞬間に、ブログから更新情報をツイートしたかったりする場合に使われます。\nただ、そのままツイートできるわけではなくて、ブログアプリがツイートする許可(認可)をしてあげる必要があります。\nそして許可されたアプリは許可証(アクセストークン)を持っていることで、Twitter を使ってツイートできるという仕組みです。\nメリット OAuth を使うことで、上の例であげたブログアプリは、Twitter のユーザ名とパスワードを知らなくてもツイートできるという点です。\n巷のアプリはこれを使うことで、Google アカウントや Twitter など SNS アカウントを持っているだけでユーザ登録できちゃいます。最初の煩わしい登録の手間が省けて良いです。\nOAuth1.0 OAuth の初期バージョンです。他に 1.0a という名前のバージョンもありますが、Twitter では 1.0a を使うことができるみたいです。 (後述の 2.0 も同様に使用可)\n特徴としては、認証と署名を用いて実現される仕様でありますが、実装が複雑で使用する言語が限られてしまうというデメリット?があるみたいです。(堅牢ではあると思いますが)\nまた、1.0 は Web アプリのみ対応しているので、デスクトップ/モバイルアプリは蚊帳の外とこれまた制限されるみたいです。\n(Twitter は Web アプリ以外でも使える xAuth という OAuth 拡張を開発したりしてたみたいです)\nさらに悲しいことに、1.0 の仕様は次の 2.0 の策定を持って廃止されたみたいです。\nOAuth2.0 後継です。複雑と言われていた署名(とトークン交換)をバッサリ省いています。\nこれによって実装しやすいものになりましたがセキュリティが気になるところです。\nOAuth 1.0 のほうが OAuth 2.0 より安全なの？でも言われている通り、2.0 はクライアントアプリケーションの幅が広がった分、秘密鍵の隠蔽が難しくなるみたいです。。\n隠蔽できるかの違いはありますが、セキュリティレベルは両者それほど変わらないみたいです。\n(2.0 は経路を TLS 化していることで、1.0 よりも提示するパラメータが少なくなっているという事実はあるそうな)\nまとめ 実装のことを考えてこれからも 2.0 を使っていきましょうという締めです。\n(Twitter 以外のほとんどのアプリが 2.0 を採用していることもあり、、)\nこの辺の仕様がやはり読んだだけではイメージしづらいところがありますので、簡単に実装してみて実務で使えるようになりたいですという感想です。\n備考 表紙イラスト：Loose Drawing\n","date":"January 5, 2021","hero":"/posts/category/security/2021/01/oauth/hero.png","permalink":"https://uh-zz.github.io/posts/category/security/2021/01/oauth/","summary":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\nOAuth とは ひとまず、一番分かりやすい OAuth の説明で大体の感覚がつかめますのでオススメです。\nこちらでもざっくり説明させてもらうと、OAuth は複数のアプリを連携させるための仕組みです。\n例えば、ブログの記事を更新した瞬間に、ブログから更新情報をツイートしたかったりする場合に使われます。\nただ、そのままツイートできるわけではなくて、ブログアプリがツイートする許可(認可)をしてあげる必要があります。\nそして許可されたアプリは許可証(アクセストークン)を持っていることで、Twitter を使ってツイートできるという仕組みです。\nメリット OAuth を使うことで、上の例であげたブログアプリは、Twitter のユーザ名とパスワードを知らなくてもツイートできるという点です。\n巷のアプリはこれを使うことで、Google アカウントや Twitter など SNS アカウントを持っているだけでユーザ登録できちゃいます。最初の煩わしい登録の手間が省けて良いです。\nOAuth1.0 OAuth の初期バージョンです。他に 1.0a という名前のバージョンもありますが、Twitter では 1.0a を使うことができるみたいです。 (後述の 2.0 も同様に使用可)\n特徴としては、認証と署名を用いて実現される仕様でありますが、実装が複雑で使用する言語が限られてしまうというデメリット?があるみたいです。(堅牢ではあると思いますが)\nまた、1.0 は Web アプリのみ対応しているので、デスクトップ/モバイルアプリは蚊帳の外とこれまた制限されるみたいです。\n(Twitter は Web アプリ以外でも使える xAuth という OAuth 拡張を開発したりしてたみたいです)\nさらに悲しいことに、1.0 の仕様は次の 2.0 の策定を持って廃止されたみたいです。\nOAuth2.0 後継です。複雑と言われていた署名(とトークン交換)をバッサリ省いています。\nこれによって実装しやすいものになりましたがセキュリティが気になるところです。\nOAuth 1.0 のほうが OAuth 2.0 より安全なの？でも言われている通り、2.0 はクライアントアプリケーションの幅が広がった分、秘密鍵の隠蔽が難しくなるみたいです。。\n隠蔽できるかの違いはありますが、セキュリティレベルは両者それほど変わらないみたいです。\n(2.0 は経路を TLS 化していることで、1.0 よりも提示するパラメータが少なくなっているという事実はあるそうな)\nまとめ 実装のことを考えてこれからも 2.0 を使っていきましょうという締めです。","tags":["security","oauth"],"title":"OAuth について"},{"categories":["system-design","ddd"],"contents":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\n※現場で役立つシステム設計の原則を元に記事を作成しています。\n設計パターン 値オブジェクト(Value Object) Java で変数を扱うとき、int や String などで型定義しがちな初心者丸出しの実装をしていた私ですが、値オブジェクトを知ったとき眼からウロコでした。\n値オブジェクトとは、汎用的な型(int や String)で型を定義するのではなく、専用の型(クラスやインターフェース)を定義します。\n範囲の広い汎用的な型を使うのではなく、業務に合わせた値で制限するというものです。\n値オブジェクトクラスはこんなかんじ\nclass Quantity { static final int MIN = 1; static final int MAX = 100; int value; Quantity(int value) { if (value \u0026lt; MIN) { throw new IllegalArgumentException(\u0026#34;不正\u0026#34; + MIN + \u0026#34;未満\u0026#34;); } if (value \u0026gt; MAX) { throw new IllegalArgumentException(\u0026#34;不正\u0026#34; + MAX + \u0026#34;超\u0026#34;); } this.value = value; } } そして参照はこんなかんじ\nQuantity quantity = new Quantity(50); こうすることで Quantity 型は値の制限(0~100)付きの実装ができるので安全です。\n制限を超えた値は不正と見なせるので業務ルールから外れることもありません。\n値オブジェクトは不変！！ 変数の上書きは禁止しておきましょう。\nもし上書きしそうであれば、新しいオブジェクトを作成しましょう。\nオブジェクトは常に１つの値を持つように実装します。\nこのように不変なオブジェクトを設計する方法を完全コンストラクタと言います。\n今回の Quantity 型のような値オブジェクトのようにクラス名も業務で実際に使用している用語にするべきです。\nそうすることで業務の理解とプログラムの設計を関連付ける手助けになり、変更のしやすいコードを維持することができます。\nコレクションオブジェクト 値オブジェクトは単一の型(int や String)のデータとそれに関連するロジックを１つのクラスにまとめるというコンセプトです。\nコレクションオブジェクトも同様に、List/Set/Map といったコレクション型のデータとロジックを１つのクラスに閉じ込めようといったものです。\n※オブジェクト指向ではデータとロジックを閉じ込めるというところがミソといっても過言ではないでしょう。\nクラスはこんなかんじ\nclass Customers { List\u0026lt;Customer\u0026gt; cutomers; void add(Customer customer) {...} void removeIfExist(Customer customer) {...} int count() {...} Customers importantCustomers() {...} } Customer に関するロジックを寄せ集めたような感じです。\nこうすることで変更箇所のこのクラスだけに閉じ込めることができます。(楽ちん)\n使う側は Customer に関するメソッドを呼ぶだけでよくなるので、使う側のソースもスッキリするという みんなハッピーになれるというわけです。\n参照をそのまま渡すべからず 値オブジェクト同様、「不変」であることが求められます。\nもしも getList()が欲しくなる禁断症状があった時に有効な方法は、同じ型のコレクションオブジェクトを返すことです。\nclass Customers { List\u0026lt;Customer\u0026gt; customers; Customers add(Customer customer) { List\u0026lt;Customer\u0026gt; result = new ArrayList\u0026lt;\u0026gt;(customers); return new Customers(result.add(customer)); } } こうすることで、既存の customers を渡すことなく新しいオブジェクトを生成して返します。または、変更不可にして返します。\nclass Customers { List\u0026lt;Customer\u0026gt; customers; List\u0026lt;Customer\u0026gt; asList() { return Collections.unmodifiableList(customers); } } 意地で不変なオブジェクトを返すようにします。そうすることで変更による副作用の起きにくいプログラムを作ることに繋がります。\nまとめ 値オブジェクトもコレクションオブジェクトもどちらも「不変であれ」ということです。同じインスタンスを使い回そうとすればするほど、変更によるバグが出る可能性が高くなります。 データとロジックは１つのクラスに閉じこめましょう。ロジックをまとめておくことで、使う側はメソッドを呼ぶだけで済むし、変更する場合はそのクラスだけを対象にすればよいわけです。人類の英知ですね。 備考 現場で役立つシステム設計の原則\n表紙イラスト：Loose Drawing\n","date":"December 5, 2020","hero":"/posts/category/system-design/2020/12/principles-of-the-systems-architecture/part1/hero.png","permalink":"https://uh-zz.github.io/posts/category/system-design/2020/12/principles-of-the-systems-architecture/part1/","summary":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\n※現場で役立つシステム設計の原則を元に記事を作成しています。\n設計パターン 値オブジェクト(Value Object) Java で変数を扱うとき、int や String などで型定義しがちな初心者丸出しの実装をしていた私ですが、値オブジェクトを知ったとき眼からウロコでした。\n値オブジェクトとは、汎用的な型(int や String)で型を定義するのではなく、専用の型(クラスやインターフェース)を定義します。\n範囲の広い汎用的な型を使うのではなく、業務に合わせた値で制限するというものです。\n値オブジェクトクラスはこんなかんじ\nclass Quantity { static final int MIN = 1; static final int MAX = 100; int value; Quantity(int value) { if (value \u0026lt; MIN) { throw new IllegalArgumentException(\u0026#34;不正\u0026#34; + MIN + \u0026#34;未満\u0026#34;); } if (value \u0026gt; MAX) { throw new IllegalArgumentException(\u0026#34;不正\u0026#34; + MAX + \u0026#34;超\u0026#34;); } this.value = value; } } そして参照はこんなかんじ\nQuantity quantity = new Quantity(50); こうすることで Quantity 型は値の制限(0~100)付きの実装ができるので安全です。","tags":["system-design","ddd"],"title":"システム設計-part1-"},{"categories":["system-design","ddd"],"contents":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\n※現場で役立つシステム設計の原則を元に記事を作成しています。\n設計パターン 早期リターン 複雑になりがちな場合分けのロジックの見通しをよくしようというものです。\nありがちなif-elseをつなげた(例 1)\nYen fee() { Yen result; if (isChild()) { result = chidFee(); } else if (isSenior()) { result = seniorFee(); } else { result = adultFee(); } return result; } さっきのコードからローカル変数を抜いて結果をすぐにreturnするようにした(例 2)\nYen fee() { if (isChild()) { return chidFee(); } else if (isSenior()) { return seniorFee(); } else { return adultFee(); } } このように、値が決まるとすぐにreturnするやり方を早期リターンと言います。\nガード節 上記の例 2 からelseを抜いた(例 3)\nYen fee() { if (isChild()) return chidFee(); if (isSenior()) return seniorFee(); return adultFee(); } elseを抜いた早期リターンをガード節と言います。非常にコンパクトですね。\n単文の並びに変えることで、独立性が高くなります。また、単文同士が結合していない（疎結合)ので追加が容易です。\n多態 それぞれのクラスを包括するようなクラス(インターフェース)を作ることで、使う側のクラス、メソッドはインターフェースさえ実装していれば、それがどのクラスでも気にする必要がありません。\nインターフェースを用意する(例 4)\ninterface Fee { Yen yen(); String label(); } // 大人クラス class AdultFee implements Fee { Yen yen() { return new Yen(1000); } String label() { return \u0026#34;大人\u0026#34;; } } // 子クラス class ChildFee implements Fee { Yen yen() { return new Yen(50) } String label() { return \u0026#34;子供\u0026#34;; } } 使う側(例 5)\nclass Reservation { List\u0026lt;Fee\u0026gt; fees; // 大人と子供のリスト Reservation() { fees = new ArrayList\u0026lt;Fee\u0026gt;(); } // Feeはインターフェースなので、大人と子供の両方に使える void addFee(Fee fee) { fees.add(fee); } // 大人と子供の合計料金 Yen feeTotal() { Yen total = new Yen(); for (Fee fee : fees) { total.add(fee.yen()); } reuturn total; } } インターフェースを使うことで、大人と子供の料金クラスをまとめて処理できました。\nif 文を使わずに済むと見通しがよいですね。\nこのようにインターフェースを使用して、異なるクラスのオブジェクトを同じ型として扱う仕組みを多態と言います。\n多態にすることでFeeのインターフェースを実装した別のクラス(シニアクラスなど)を追加してもReservationクラスを変更することはありません。改修箇所が少なくなるのは大きなメリットです。\n列挙型 多態は同じインターフェースを実装したクラスの一覧が分かりにくくなる場合がありますclass宣言のimplementsを見れば一目瞭然ですが、一つ一つ見ていくのに時間がかかります。\n列挙型を使うことで区分(インターフェースのグループ)の一覧を作成することができます。\n列挙型を使って料金区分ごとのロジックを表現(例 6)\nenum FeeType { adult(new AdultFee()); child(new ChidFee()); senior(new SeniorFee()); private Fee fee; private FeeTypt(Fee fee) { this.fee = fee; } Yen yen() { return fee.yen(); } String label() { return fee.label(); } } 使う側(例 7)\nYen feeFor(Stirng feeTypeName) { FeeType feeType = FeeType.valueOf(feeTypeName); return feeType.yen(); } enumクラスのvalueOf()メソッドはMapのget()メソッドと同様に、if 文を使うことなく料金区分ごとのオブジェクトを取得できます。\nこのような振る舞いを持った列挙型(enum)を区分オブジェクトと言います。\nまとめ 前回同様、コードをスッキリさせる手法を見てきました。インターフェースを使うことで抽象的なメソッドを作ったり、列挙型を使って if 文をなるべく減らせることはコードの保守性、拡張性を高めてくれますね。\n備考 現場で役立つシステム設計の原則\n表紙イラスト：Loose Drawing\n","date":"December 5, 2020","hero":"/posts/category/system-design/2020/12/principles-of-the-systems-architecture/part2/hero.png","permalink":"https://uh-zz.github.io/posts/category/system-design/2020/12/principles-of-the-systems-architecture/part2/","summary":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\n※現場で役立つシステム設計の原則を元に記事を作成しています。\n設計パターン 早期リターン 複雑になりがちな場合分けのロジックの見通しをよくしようというものです。\nありがちなif-elseをつなげた(例 1)\nYen fee() { Yen result; if (isChild()) { result = chidFee(); } else if (isSenior()) { result = seniorFee(); } else { result = adultFee(); } return result; } さっきのコードからローカル変数を抜いて結果をすぐにreturnするようにした(例 2)\nYen fee() { if (isChild()) { return chidFee(); } else if (isSenior()) { return seniorFee(); } else { return adultFee(); } } このように、値が決まるとすぐにreturnするやり方を早期リターンと言います。\nガード節 上記の例 2 からelseを抜いた(例 3)\nYen fee() { if (isChild()) return chidFee(); if (isSenior()) return seniorFee(); return adultFee(); } elseを抜いた早期リターンをガード節と言います。非常にコンパクトですね。","tags":["system-design","ddd"],"title":"システム設計-part2-"},{"categories":["system-design","ddd"],"contents":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\n※現場で役立つシステム設計の原則を元に記事を作成しています。\n業務ロジック メソッドをロジックの置き場所にする 現場で役立つシステム設計の原則では、\u0026ldquo;従来\u0026quot;という表現をされていますが、手続き型と呼ばれている設計ではデータクラスと機能クラスに分けて表現します。\nその名の通りデータクラスはデータを格納して、機能クラスはデータクラスのデータを判断、加工、計算するといった使い方です。\nこの手続き型の問題は、拡張するときの変更箇所の特定に時間がかかるということです。\nなぜかというと、データクラスが参照できるクラスであれば、アーキテクチャのどのレイヤーにでもロジックが書けてしまうからです。\n便利のようには見えますが、先に言った変更箇所の特定に時間がかかるこの方法は最善ではありません。\n解決としては、Java 本来のクラスの使い方を踏襲することです。\nデータとロジックを 1 つのクラスに閉じてしまおうという考え方です。\nclass PersonName { private String firstName; private String lastName; String fullName() { return String.format(\u0026#34;%s %s\u0026#34;, firstName, lastName); } } データであるfirstNameとlastName、そしてロジック(メソッド)のfullName()が同じクラス内にあります。\nこうするとクラス内でデータを扱うことができて変更もこのクラス内で閉じることができます。\nまた、メソッドはクラス内のインスタンス変数(firstNameやlastName)を使って何らかの処理を行う用途で作成します。\nクラスが肥大化したら小さく分ける これもやってしまいがちですが、改修を繰り返していくうちに、クラスが大きくなっていきます。\n大きくなったクラスは手続き型同様に変更箇所の特定に時間がかかります。\nそれを防ぐために、大きくなってしまったクラスを次のルールで細分化します。\nインスタンス変数とメソッドを対応付ける メソッドが全てのインスタンス変数を使うようになる 細分化したクラスはそれぞれ独立性が高くなるので、別のクラスで使う時にも再利用ができるようになります。\nこうした関連の強いデータとロジックをまとめたクラスを凝集度が高いと言います。\n凝集度が高いクラスは、変更箇所もそのクラスに閉じることになるので、疎結合になり他への影響が少なくて済みます。\nまとめ 時すでに遅しと言いますか、現場での反省点をつらつら振り返ってベストプラクティスを学んでいるという感じです。\n次回に活かそうというモチベーションは上がるのでいい復習方法だと感じます。\n備考 現場で役立つシステム設計の原則\n表紙イラスト：Loose Drawing\n","date":"December 5, 2020","hero":"/posts/category/system-design/2020/12/principles-of-the-systems-architecture/part3/hero.png","permalink":"https://uh-zz.github.io/posts/category/system-design/2020/12/principles-of-the-systems-architecture/part3/","summary":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\n※現場で役立つシステム設計の原則を元に記事を作成しています。\n業務ロジック メソッドをロジックの置き場所にする 現場で役立つシステム設計の原則では、\u0026ldquo;従来\u0026quot;という表現をされていますが、手続き型と呼ばれている設計ではデータクラスと機能クラスに分けて表現します。\nその名の通りデータクラスはデータを格納して、機能クラスはデータクラスのデータを判断、加工、計算するといった使い方です。\nこの手続き型の問題は、拡張するときの変更箇所の特定に時間がかかるということです。\nなぜかというと、データクラスが参照できるクラスであれば、アーキテクチャのどのレイヤーにでもロジックが書けてしまうからです。\n便利のようには見えますが、先に言った変更箇所の特定に時間がかかるこの方法は最善ではありません。\n解決としては、Java 本来のクラスの使い方を踏襲することです。\nデータとロジックを 1 つのクラスに閉じてしまおうという考え方です。\nclass PersonName { private String firstName; private String lastName; String fullName() { return String.format(\u0026#34;%s %s\u0026#34;, firstName, lastName); } } データであるfirstNameとlastName、そしてロジック(メソッド)のfullName()が同じクラス内にあります。\nこうするとクラス内でデータを扱うことができて変更もこのクラス内で閉じることができます。\nまた、メソッドはクラス内のインスタンス変数(firstNameやlastName)を使って何らかの処理を行う用途で作成します。\nクラスが肥大化したら小さく分ける これもやってしまいがちですが、改修を繰り返していくうちに、クラスが大きくなっていきます。\n大きくなったクラスは手続き型同様に変更箇所の特定に時間がかかります。\nそれを防ぐために、大きくなってしまったクラスを次のルールで細分化します。\nインスタンス変数とメソッドを対応付ける メソッドが全てのインスタンス変数を使うようになる 細分化したクラスはそれぞれ独立性が高くなるので、別のクラスで使う時にも再利用ができるようになります。\nこうした関連の強いデータとロジックをまとめたクラスを凝集度が高いと言います。\n凝集度が高いクラスは、変更箇所もそのクラスに閉じることになるので、疎結合になり他への影響が少なくて済みます。\nまとめ 時すでに遅しと言いますか、現場での反省点をつらつら振り返ってベストプラクティスを学んでいるという感じです。\n次回に活かそうというモチベーションは上がるのでいい復習方法だと感じます。\n備考 現場で役立つシステム設計の原則\n表紙イラスト：Loose Drawing","tags":["system-design","ddd"],"title":"システム設計-part3-"},{"categories":["computer-science"],"contents":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\nスレッド プロセスが最低１つは持っている実行単位のことです。\nこんな言い方をするのは、プロセスが複数のスレッドを管理できるからです。\n実行単位という視点でプロセスとの違いは、「アドレス空間」を共有できるという点です。\n尾を引くようにプロセス管理の話に繋がりますが、プロセスにはそれぞれ１つのアドレス空間が割り当てられます。\nそして別のプロセスからアドレス空間へのアクセスは原則できません。(これを可能にするために共有メモリという方法を使います)\nそれに対して、スレッドは１つのプロセスの実行単位を分けたものですから、同じアドレス空間を共有できるというわけです。\nそういうわけで、スレッドとプロセスをそれぞれ複数起動する場合は、スレッドの方がアドレス空間を１つで済ませることができるため省コストになります。\nでは、複数のスレッドを起動してやることは?というと並行処理です。\n並行処理 これもすでに出てきている話ではあります。プロセス管理の記事で出した複数アプリを同時に起動させるという部分です。\n「同時に」というのは私たちユーザがそう解釈しているだけで、アプリはカーネルが割り当てた非常に短い処理時間ごとに切り替えているのでしたよね。これが並行処理です。\nスレッドでも同じように短い処理時間ごとに切り替えて「同時に」処理させることができます。\n並列処理との違い 私自身、再三調べては納得 → 忘れるを繰り返していましたが、プロセス管理(3 度目)をまとめることでやっと理解できたと思います。\n並行処理では処理時間ごとに切り替えると言いましたが、並列処理では CPU １つは言わず２つで処理してしまえばいいじゃないという考え方です。\n図で見ると非常にわかりやすいのですが、並行処理だとパン食べてチーズ食べてハム食べてレタス食べて、、を繰り返して食べ切る作戦なのに対して、並列処理はミックスサンドとして食べ切るようなイメージです。\nそんなの絶対ミックスサンドとして処理したら無限じゃんと思われますが、並列処理にも上限があるようです。\nアムダールの法則といって複数のプロセッサ(CPU のことですね)を使って並列化による高速化を行う場合、そのプログラムの中で逐次的に実行される処理部分(並列)の時間によって、高速化が制限されるというものです。\n出典：wikipedia「アムダールの法則」より引用\nまあ、上限があるといっても高速するのに変わりはないわけです。\n今回はその中でも比較的面白い実装を見つけたのでそれを紹介します。\nワーカープール スレッドプールとも呼ばれるものです。並行処理でたくさんのスレッドを起動して、、というのももちろん可能ですが、それには代償が伴います。\nワーカープールはそのようにいくつもスレッドを起動させるのではなく、すでに起動したスレッドを使い回そうの精神で実装される並行処理です。\n以下のような実装です。\nこちらを参考にさせていただきました。\n(ほぼコメントつけただけですが)\npackage main import ( \u0026#34;fmt\u0026#34; \u0026#34;time\u0026#34; ) // 使い回し用のワーカー func worker(id int, jobs \u0026lt;-chan int, results chan\u0026lt;- int) { for j := range jobs { fmt.Println(\u0026#34;worker\u0026#34;, id, \u0026#34;started job\u0026#34;, j) time.Sleep(time.Second) // 1秒待ち(重い処理を想定) fmt.Println(\u0026#34;worker\u0026#34;, id, \u0026#34;finished job\u0026#34;, j) results \u0026lt;- j * 2 } } func main() { // タスクの数 const numJobs = 5 // こなさなければいけないタスク jobs := make(chan int, numJobs) // タスクの成果物 results := make(chan int, numJobs) for w := 1; w \u0026lt;= 3; w++ { // 使い回し用のワーカーだけ生成しておく(この状態ではまだタスクをもらってないのでブロック) go worker(w, jobs, results) } // タスク数だけjobsに渡す for j := 1; j \u0026lt;= numJobs; j++ { // チャネルへの書き込みを契機にワーカー起動 jobs \u0026lt;- j } // タスク数だけ格納されたらチャネルを閉じる close(jobs) for a := 1; a \u0026lt;= numJobs; a++ { \u0026lt;-results } } // 結果 worker 3 started job 1 worker 1 started job 2 worker 2 started job 3 worker 3 finished job 1 worker 3 started job 4 worker 1 finished job 2 worker 1 started job 5 worker 2 finished job 3 worker 1 finished job 5 worker 3 finished job 4 実行するとわかりますが、順番がごっちゃになって処理されているのがわかります。\nこれにより、ワーカーというスレッドごとに並行処理されているという動作を確認することができました。\n余談 他にも面白そうな実装をいくつか見つけましたが、ただ羅列するだけでは萎えると思ったので気が向いたら別で紹介したいと思います。\nなにげに goroutine を使用していますが、goroutine の中身の処理内容(work stealing アルゴリズム)も面白いので、後々まとめたいと思ってます。\n備考 表紙イラスト：Loose Drawing\n","date":"October 5, 2020","hero":"/posts/category/computer-science/2020/11/thread-and-concurrency/hero.png","permalink":"https://uh-zz.github.io/posts/category/computer-science/2020/11/thread-and-concurrency/","summary":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\nスレッド プロセスが最低１つは持っている実行単位のことです。\nこんな言い方をするのは、プロセスが複数のスレッドを管理できるからです。\n実行単位という視点でプロセスとの違いは、「アドレス空間」を共有できるという点です。\n尾を引くようにプロセス管理の話に繋がりますが、プロセスにはそれぞれ１つのアドレス空間が割り当てられます。\nそして別のプロセスからアドレス空間へのアクセスは原則できません。(これを可能にするために共有メモリという方法を使います)\nそれに対して、スレッドは１つのプロセスの実行単位を分けたものですから、同じアドレス空間を共有できるというわけです。\nそういうわけで、スレッドとプロセスをそれぞれ複数起動する場合は、スレッドの方がアドレス空間を１つで済ませることができるため省コストになります。\nでは、複数のスレッドを起動してやることは?というと並行処理です。\n並行処理 これもすでに出てきている話ではあります。プロセス管理の記事で出した複数アプリを同時に起動させるという部分です。\n「同時に」というのは私たちユーザがそう解釈しているだけで、アプリはカーネルが割り当てた非常に短い処理時間ごとに切り替えているのでしたよね。これが並行処理です。\nスレッドでも同じように短い処理時間ごとに切り替えて「同時に」処理させることができます。\n並列処理との違い 私自身、再三調べては納得 → 忘れるを繰り返していましたが、プロセス管理(3 度目)をまとめることでやっと理解できたと思います。\n並行処理では処理時間ごとに切り替えると言いましたが、並列処理では CPU １つは言わず２つで処理してしまえばいいじゃないという考え方です。\n図で見ると非常にわかりやすいのですが、並行処理だとパン食べてチーズ食べてハム食べてレタス食べて、、を繰り返して食べ切る作戦なのに対して、並列処理はミックスサンドとして食べ切るようなイメージです。\nそんなの絶対ミックスサンドとして処理したら無限じゃんと思われますが、並列処理にも上限があるようです。\nアムダールの法則といって複数のプロセッサ(CPU のことですね)を使って並列化による高速化を行う場合、そのプログラムの中で逐次的に実行される処理部分(並列)の時間によって、高速化が制限されるというものです。\n出典：wikipedia「アムダールの法則」より引用\nまあ、上限があるといっても高速するのに変わりはないわけです。\n今回はその中でも比較的面白い実装を見つけたのでそれを紹介します。\nワーカープール スレッドプールとも呼ばれるものです。並行処理でたくさんのスレッドを起動して、、というのももちろん可能ですが、それには代償が伴います。\nワーカープールはそのようにいくつもスレッドを起動させるのではなく、すでに起動したスレッドを使い回そうの精神で実装される並行処理です。\n以下のような実装です。\nこちらを参考にさせていただきました。\n(ほぼコメントつけただけですが)\npackage main import ( \u0026#34;fmt\u0026#34; \u0026#34;time\u0026#34; ) // 使い回し用のワーカー func worker(id int, jobs \u0026lt;-chan int, results chan\u0026lt;- int) { for j := range jobs { fmt.Println(\u0026#34;worker\u0026#34;, id, \u0026#34;started job\u0026#34;, j) time.Sleep(time.Second) // 1秒待ち(重い処理を想定) fmt.Println(\u0026#34;worker\u0026#34;, id, \u0026#34;finished job\u0026#34;, j) results \u0026lt;- j * 2 } } func main() { // タスクの数 const numJobs = 5 // こなさなければいけないタスク jobs := make(chan int, numJobs) // タスクの成果物 results := make(chan int, numJobs) for w := 1; w \u0026lt;= 3; w++ { // 使い回し用のワーカーだけ生成しておく(この状態ではまだタスクをもらってないのでブロック) go worker(w, jobs, results) } // タスク数だけjobsに渡す for j := 1; j \u0026lt;= numJobs; j++ { // チャネルへの書き込みを契機にワーカー起動 jobs \u0026lt;- j } // タスク数だけ格納されたらチャネルを閉じる close(jobs) for a := 1; a \u0026lt;= numJobs; a++ { \u0026lt;-results } } // 結果 worker 3 started job 1 worker 1 started job 2 worker 2 started job 3 worker 3 finished job 1 worker 3 started job 4 worker 1 finished job 2 worker 1 started job 5 worker 2 finished job 3 worker 1 finished job 5 worker 3 finished job 4 実行するとわかりますが、順番がごっちゃになって処理されているのがわかります。","tags":["computer-science"],"title":"スレッドと並行処理"},{"categories":["computer-science"],"contents":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\n仮想メモリ プロセス管理でもあったように、メモリはアドレス空間ごとにプロセスを管理します。\nアドレス空間は 4KB/8KB 単位のページに分割して管理されています。\nページはそれぞれ論理アドレス、物理アドレスを対応づける単位でもあります。\n論理アドレスと物理アドレスは常に紐づけられているわけではなく、そのページが必要になった時点で割り当てることも可能です。\nそのため、論理アドレスを実際の物理アドレスの容量より大きく確保することができます。\n(実際に使えるメモリの量よりも大きなメモリを想定できるということです。)\n仮装メモリとして使う仕組みには次の３つが挙げられます。\nページング 仮想メモリといえばこれ、という風に教えられるものの筆頭かと思います。\nハードディスクを物理メモリの代わりに使うといったものです。\n物理メモリが不足すると、OS のコアであるカーネルは使われていないページをハードディスクに移して論理アドレスを解放します。\nそしてプロセスがハードディスクに移されたページにアクセスしようとすると、カーネルがプロセスを停止し、ハードディスクのページを再度物理メモリに読み込み、論理アドレスを対応づけます。\nまた、プロセス全体を単位にする場合はスワッピングと呼ばれます。\nメモリマップトファイル ファイルをメモリとしてアクセスすることができるものです。\nアクセスがあった瞬間に、カーネルがファイルをメモリに読み込みます。プロセスがメモリを使い終わると、論理アドレスと物理アドレスを解放して、メモリの内容をファイルに保存します。\n共有メモリ １つの物理アドレスを、複数のプロセスの論理アドレスに対応づけるものです。 アドレス空間をまたぐと危険では？！という見方もありますが、複数プロセスで処理できるため、巨大な画像データを編集するときには都合が良いみたいです。\n※Go では共有メモリを使わずに Message Passing を使っています。\nメモリ管理 API malloc(3) メモリをヒープ領域に割り当てます。プログラム実行時に決まるサイズのメモリはヒープ領域から確保します。\nヒープは「何かを積み重ねた山」のことで、その名の通り、プログラムを実行してから決定する量だけメモリを確保しておく領域なので納得です。\nmalloc で確保したメモリはfreeで解放しなければいけません。\ncalloc(3) メモリをヒープ領域に割り当てます。malloc と異なる点は、割り当てたメモリをゼロクリアすることです。\nこちらも malloc 同様、確保したメモリはfreeで解放しなければいけません。\nrealloc(3) malloc で割り当てたメモリのサイズを拡大、縮小します。こちらも確保したメモリはfreeで解放しなければいけません。\nfree 割り当てたメモリを開放します。いったん開放したアドレスにはアクセスしてはいけません。\nメモリの開放漏れを防ぐために、malloc で確保したメモリは常に free で開放されるべきです。\nbrk(2) malloc や realloc が割り当てるためのメモリを探してくるものです。\n物理アドレスが割り当てられていないページに物理アドレスを対応づけます。\n余談 メモリはエラーでもかなりお世話になる部分なので、次回以降、実際のエラーやプログラミング言語(Go か Java)に絡めた記事を書きたいです。\n備考 ふつうの Linux プログラミング 第 2 版 Linux の仕組みから学べる gcc プログラミングの王道\n表紙イラスト：Loose Drawing\n","date":"October 5, 2020","hero":"/posts/category/computer-science/2020/10/memory-management/hero.png","permalink":"https://uh-zz.github.io/posts/category/computer-science/2020/10/memory-management/","summary":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\n仮想メモリ プロセス管理でもあったように、メモリはアドレス空間ごとにプロセスを管理します。\nアドレス空間は 4KB/8KB 単位のページに分割して管理されています。\nページはそれぞれ論理アドレス、物理アドレスを対応づける単位でもあります。\n論理アドレスと物理アドレスは常に紐づけられているわけではなく、そのページが必要になった時点で割り当てることも可能です。\nそのため、論理アドレスを実際の物理アドレスの容量より大きく確保することができます。\n(実際に使えるメモリの量よりも大きなメモリを想定できるということです。)\n仮装メモリとして使う仕組みには次の３つが挙げられます。\nページング 仮想メモリといえばこれ、という風に教えられるものの筆頭かと思います。\nハードディスクを物理メモリの代わりに使うといったものです。\n物理メモリが不足すると、OS のコアであるカーネルは使われていないページをハードディスクに移して論理アドレスを解放します。\nそしてプロセスがハードディスクに移されたページにアクセスしようとすると、カーネルがプロセスを停止し、ハードディスクのページを再度物理メモリに読み込み、論理アドレスを対応づけます。\nまた、プロセス全体を単位にする場合はスワッピングと呼ばれます。\nメモリマップトファイル ファイルをメモリとしてアクセスすることができるものです。\nアクセスがあった瞬間に、カーネルがファイルをメモリに読み込みます。プロセスがメモリを使い終わると、論理アドレスと物理アドレスを解放して、メモリの内容をファイルに保存します。\n共有メモリ １つの物理アドレスを、複数のプロセスの論理アドレスに対応づけるものです。 アドレス空間をまたぐと危険では？！という見方もありますが、複数プロセスで処理できるため、巨大な画像データを編集するときには都合が良いみたいです。\n※Go では共有メモリを使わずに Message Passing を使っています。\nメモリ管理 API malloc(3) メモリをヒープ領域に割り当てます。プログラム実行時に決まるサイズのメモリはヒープ領域から確保します。\nヒープは「何かを積み重ねた山」のことで、その名の通り、プログラムを実行してから決定する量だけメモリを確保しておく領域なので納得です。\nmalloc で確保したメモリはfreeで解放しなければいけません。\ncalloc(3) メモリをヒープ領域に割り当てます。malloc と異なる点は、割り当てたメモリをゼロクリアすることです。\nこちらも malloc 同様、確保したメモリはfreeで解放しなければいけません。\nrealloc(3) malloc で割り当てたメモリのサイズを拡大、縮小します。こちらも確保したメモリはfreeで解放しなければいけません。\nfree 割り当てたメモリを開放します。いったん開放したアドレスにはアクセスしてはいけません。\nメモリの開放漏れを防ぐために、malloc で確保したメモリは常に free で開放されるべきです。\nbrk(2) malloc や realloc が割り当てるためのメモリを探してくるものです。\n物理アドレスが割り当てられていないページに物理アドレスを対応づけます。\n余談 メモリはエラーでもかなりお世話になる部分なので、次回以降、実際のエラーやプログラミング言語(Go か Java)に絡めた記事を書きたいです。\n備考 ふつうの Linux プログラミング 第 2 版 Linux の仕組みから学べる gcc プログラミングの王道","tags":["computer-science"],"title":"メモリ管理"},{"categories":["oss"],"contents":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\nセマンティックバージョニング？ アプリに振るバージョン番号をSemVerというルールに従って付与しましょうというものです。\n確かにバージョン番号に意味を持たせることで、ユーザからもアプリのバージョン番号が上がればバグ修正なのか機能追加なのかわかりますし、プログラムからも互換性を考慮して処理を分けることができるのでよいですね。\nこれだけ覚えておけば OK バージョン番号の形式は、メジャー.マイナー.パッチです。(例：1.0.0)\nメジャー 後方互換性がない変更があった時にはこの番号を上げなければいけません(MUST) この番号を上げた際には、マイナー/パッチの番号は 0 にリセットしなければいけません(MUST) この番号が「0」の場合は初期開発用として扱います。リリースの段階でこの番号を「1」に上げます。 マイナー 後方互換性を保ちつつ、機能追加のある時にはこの番号を上げなければいけません(MUST) この番号を上げた際には、パッチの番号は 0 にリセットしなければいけません(MUST) パッチ 後方互換性を保ちつつ、バグ修正のある時にはこの番号を上げなければいけません(MUST) ※バグ修正とは間違った振る舞いを修正する内部の変更のことをいいます。\nちょっと踏み込むと プレリリースバージョンには、パッチ番号の後ろにハイフンで区切って識別子をつけることができます。 (例：1.1.0-alpha / 1.1.0-beta / 1.1.0-rc) ※ちなみに識別子のrcは「release candidate」の略でベータ版よりもさらに製品版に近い品質のバージョンにつけるそうです。（略を初めて知りました。）\nあと npm の packagge.json でもモジュールをセマンティックバージョンで管理してます。（~や^が付与されているのをよく見ると思います。） これについては上、真ん中、下で覚えるバージョニング範囲指定がわかりやすかったので共有しておきます。\n余談 たかがバージョニング、されどバージョニングといった感じでした。知ってて損はないですよね。\n備考 表紙イラスト：Loose Drawing\n","date":"August 5, 2020","hero":"/posts/category/oss/2020/08/semantic-versioning/hero.png","permalink":"https://uh-zz.github.io/posts/category/oss/2020/08/semantic-versioning/","summary":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\nセマンティックバージョニング？ アプリに振るバージョン番号をSemVerというルールに従って付与しましょうというものです。\n確かにバージョン番号に意味を持たせることで、ユーザからもアプリのバージョン番号が上がればバグ修正なのか機能追加なのかわかりますし、プログラムからも互換性を考慮して処理を分けることができるのでよいですね。\nこれだけ覚えておけば OK バージョン番号の形式は、メジャー.マイナー.パッチです。(例：1.0.0)\nメジャー 後方互換性がない変更があった時にはこの番号を上げなければいけません(MUST) この番号を上げた際には、マイナー/パッチの番号は 0 にリセットしなければいけません(MUST) この番号が「0」の場合は初期開発用として扱います。リリースの段階でこの番号を「1」に上げます。 マイナー 後方互換性を保ちつつ、機能追加のある時にはこの番号を上げなければいけません(MUST) この番号を上げた際には、パッチの番号は 0 にリセットしなければいけません(MUST) パッチ 後方互換性を保ちつつ、バグ修正のある時にはこの番号を上げなければいけません(MUST) ※バグ修正とは間違った振る舞いを修正する内部の変更のことをいいます。\nちょっと踏み込むと プレリリースバージョンには、パッチ番号の後ろにハイフンで区切って識別子をつけることができます。 (例：1.1.0-alpha / 1.1.0-beta / 1.1.0-rc) ※ちなみに識別子のrcは「release candidate」の略でベータ版よりもさらに製品版に近い品質のバージョンにつけるそうです。（略を初めて知りました。）\nあと npm の packagge.json でもモジュールをセマンティックバージョンで管理してます。（~や^が付与されているのをよく見ると思います。） これについては上、真ん中、下で覚えるバージョニング範囲指定がわかりやすかったので共有しておきます。\n余談 たかがバージョニング、されどバージョニングといった感じでした。知ってて損はないですよね。\n備考 表紙イラスト：Loose Drawing","tags":["oss"],"title":"Semantic Versioning"},{"categories":["Go"],"contents":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\n地球上の２点間の距離計算ってアプリだと Google Map API を使えば完了！だと思いますが、どう計算してるかって気になりますよね？\n今回は球面三角法を利用した地球上の２点間の距離計算を Go で実装します。（調べたらフツーにあるんですが）\n球面三角法とは その名の通り、三角関数を利用して球面上の辺や角の大きさを導出するものです。平面と球面とでの違いは辺の大きさが 球面では中心角によって表されることにあります。\nよって、球面三角法を使用して算出した弧の長さ(中心角)と赤道の半径を乗算すると距離が求まります。\n球面三角法の証明については、球面三角形の定理を参考にしました！\n(\u0026ldquo;高校生に向けて\u0026quot;とある通り、非常にわかりやすかったです)\n球面三角法の余弦定理を利用して実際に距離を算出する方法は球面三角法の余弦定理がわかりやすいです。\n実装 実装したソースコードは Github でも確認できます。\n球面三角法を利用した２点間の距離計算\npackage main import \u0026#34;math\u0026#34; // Coordinate 緯度経度 type Coordinate struct { Longitude float64 Latitude float64 } // EarthRadius 赤道半径 const EarthRadius = 6378140 // DistanceOnTheEarth 地球上の 2 点間の距離を出す（球面三角法） func DistanceOnTheEarth(from, to Coordinate) float64 { fromLadLon := from.Longitude * math.Pi / 180 fromLadLat := from.Latitude * math.Pi / 180 toLadLon := to.Longitude * math.Pi / 180 toLadLat := to.Latitude * math.Pi / 180 alpha := math.Sin(fromLadLat)*math.Sin(toLadLat) + math.Cos(fromLadLat)*math.Cos(toLadLat)*math.Cos(fromLadLon-toLadLon) arcAlpha := math.Acos(alpha) return arcAlpha * EarthRadius / 1000 } 動かしてみる それでは実装した Go の関数を呼び出す簡単なアプリを動かしていきます。\n※今回使用するアプリも Github 上の同じディレクトリにあるのでビルドすると使用できます。\nアプリの挙動としては、\n2 点間の緯度経度情報を取得する（取得するために外部 APIを利用します） 1 で取得した２点の緯度経度情報を今回実装した距離計算の関数へ渡して算出する 比較するためにこちらのサイトを利用します。\n結果 場所 比較サイト 今回のアプリ 西東京市 ~ 大阪市都島区 383.344422 383.3444215569602 札幌市厚別区　~ 沖縄市 2,231.318234 2231.3182342761 ※地球上の半径 r は 6378.140km にしています。\n。。。同じになってしまいました。。比較とはなんだったんだろう\nまあよく捉えると、比較サイトのような便利計算サイトと同等?のものが作れたということでしょうか。\n余談 久しぶりに証明を見たり計算を手で追っていく作業をしたので懐かしい気持ちになりました。\n普段の業務でそこまで計算式を使わない分、こう自発的に調べて実装するのも楽しいと思いました。\n","date":"July 6, 2020","hero":"/posts/category/go/2020/07/spherical-trigonometry/hero.png","permalink":"https://uh-zz.github.io/posts/category/go/2020/07/spherical-trigonometry/","summary":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\n地球上の２点間の距離計算ってアプリだと Google Map API を使えば完了！だと思いますが、どう計算してるかって気になりますよね？\n今回は球面三角法を利用した地球上の２点間の距離計算を Go で実装します。（調べたらフツーにあるんですが）\n球面三角法とは その名の通り、三角関数を利用して球面上の辺や角の大きさを導出するものです。平面と球面とでの違いは辺の大きさが 球面では中心角によって表されることにあります。\nよって、球面三角法を使用して算出した弧の長さ(中心角)と赤道の半径を乗算すると距離が求まります。\n球面三角法の証明については、球面三角形の定理を参考にしました！\n(\u0026ldquo;高校生に向けて\u0026quot;とある通り、非常にわかりやすかったです)\n球面三角法の余弦定理を利用して実際に距離を算出する方法は球面三角法の余弦定理がわかりやすいです。\n実装 実装したソースコードは Github でも確認できます。\n球面三角法を利用した２点間の距離計算\npackage main import \u0026#34;math\u0026#34; // Coordinate 緯度経度 type Coordinate struct { Longitude float64 Latitude float64 } // EarthRadius 赤道半径 const EarthRadius = 6378140 // DistanceOnTheEarth 地球上の 2 点間の距離を出す（球面三角法） func DistanceOnTheEarth(from, to Coordinate) float64 { fromLadLon := from.Longitude * math.Pi / 180 fromLadLat := from.Latitude * math.Pi / 180 toLadLon := to.","tags":["Go"],"title":"球面三角法による２点間の距離計算をGoで実装してみた"},{"categories":["Go"],"contents":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\nマージソート マージソートは、ソートのアルゴリズムで、既に整列してある複数個の列を 1 個の列にマージする際に、小さいものから先に新しい列に並べれば、新しい列も整列されている、というボトムアップの分割統治法による。大きい列を多数の列に分割し、そのそれぞれをマージする作業は並列化できる。\n出典：wikipedia「マージソート」より引用\n最悪の計算量が O(n log n) であるから少なくとも O(n^2)よりは速いんだろうなという印象（雑すぎるか）\n以下「ソートを極める！ 〜 なぜソートを学ぶのか 〜」を元に実装してみた（なるべくソースを見ないで実装を試みたがマージする箇所は折れた、、）\npackage main import ( \u0026#34;fmt\u0026#34; \u0026#34;time\u0026#34; \u0026#34;github.com/uh-zz/traning/algorithm/shuffle\u0026#34; ) func main() { // ランダムな要素 n 個のスライス取得 input := shuffle.RandomIntList(n) inputLength := len(input) // マージソート MergeSort(\u0026amp;input, 0, inputLength) } // MergeSort マージソート func MergeSort(input \\*[]int, left, right int) { // 要素数1つの場合は抜ける if right-left == 1 { return } // 配列を２つに分けるインデックス middle := left + (right-left)/2 // 配列左側 MergeSort(input, left, middle) // 配列右側 MergeSort(input, middle, right) var buffer []int // 左側と右側をバッファにためる（右側反転） for index := left; index \u0026lt; middle; index++ { buffer = append(buffer, (*input)[index]) } for index := right - 1; index \u0026gt;= middle; index-- { buffer = append(buffer, (*input)[index]) } // マージする scopeLeft := 0 scopeRight := len(buffer) - 1 for index := left; index \u0026lt; right; index++ { if buffer[scopeLeft] \u0026lt;= buffer[scopeRight] { // 左側採用 (*input)[index] = buffer[scopeLeft] scopeLeft++ } else { // 右側採用 (*input)[index] = buffer[scopeRight] scopeRight-- } } } これ考えたのぶっ飛んでるなあと思って Wikipedia 見てたら、考案者がフォン・ノイマンでやっぱりぶっ飛んでた（凄すぎ）\n挿入ソート 挿入ソート（インサーションソート）は、ソートのアルゴリズムの一つ。整列してある配列に追加要素を適切な場所に挿入すること。平均計算時間・最悪計算時間がともに O(n2)と遅いが、アルゴリズムが単純で実装が容易なため、しばしば用いられる。安定な内部ソート。基本挿入法ともいう。in-place アルゴリズムであり、オンラインアルゴリズムである。\n出典：wikipedia「挿入ソート」より引用\nこれも「ソートを極める！ 〜 なぜソートを学ぶのか 〜」を元に実装してみた\npackage main import ( \u0026#34;fmt\u0026#34; \u0026#34;time\u0026#34; \u0026#34;github.com/uh-zz/traning/algorithm/shuffle\u0026#34; ) func main() { // ランダムな要素 n 個のスライス input := shuffle.RandomIntList(n) // 挿入ソート for index := 1; index \u0026lt; len(input); index++ { // 挿入したい値 insertValue := input[index] // 挿入位置 point := index for ; point \u0026gt; 0; point-- { if input[point-1] \u0026gt; insertValue { input[point] = input[point-1] } else { break } } input[point] = insertValue } } こっちは実装もしやすく理解するのも難しくないという印象。最終的にはどちらもソートするというのにこの差は、、と思ってしまう。\n速度比較 今回はソートアルゴリズムの実装がメインだったけど、２つあるなら比較するまでがアウトプットだろうなと感じたので比較します。\nマシンスペック OS: macOS Catalina プロセッサ: 1.6 GHz(Core i5) メモリ: 16 GB 実施方法 要素数 n 個のスライスのソート時間を比較する。要素はそれぞれランダムになっている。\n結果 要素数(n) マージソート(O(n log n)(sec) 挿入ソート(O(n^2)(sec) 1,000 0.000357 0.000277 10,000 0.005002 0.024778 100,000 0.036705 1.524296 1,000,000 0.341336 - ※挿入ソート（1,000,000）は 1 分以上かかったので省略\n要素が倍になるほどマージソートの速さがわかりますね。\nこのページのソースは GitHub にもあります。\nソートアルゴリズムの比較\n余談 アルゴリズムを１ヶ月で把握しようとしてましたがソートアルゴリズムの雰囲気を掴むだけでそれくらい時間かかりました、、\n１つずつ精進ですね。。\n","date":"July 5, 2020","hero":"/posts/category/go/2020/07/compare-sort-aligorithm/hero.png","permalink":"https://uh-zz.github.io/posts/category/go/2020/07/compare-sort-aligorithm/","summary":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\nマージソート マージソートは、ソートのアルゴリズムで、既に整列してある複数個の列を 1 個の列にマージする際に、小さいものから先に新しい列に並べれば、新しい列も整列されている、というボトムアップの分割統治法による。大きい列を多数の列に分割し、そのそれぞれをマージする作業は並列化できる。\n出典：wikipedia「マージソート」より引用\n最悪の計算量が O(n log n) であるから少なくとも O(n^2)よりは速いんだろうなという印象（雑すぎるか）\n以下「ソートを極める！ 〜 なぜソートを学ぶのか 〜」を元に実装してみた（なるべくソースを見ないで実装を試みたがマージする箇所は折れた、、）\npackage main import ( \u0026#34;fmt\u0026#34; \u0026#34;time\u0026#34; \u0026#34;github.com/uh-zz/traning/algorithm/shuffle\u0026#34; ) func main() { // ランダムな要素 n 個のスライス取得 input := shuffle.RandomIntList(n) inputLength := len(input) // マージソート MergeSort(\u0026amp;input, 0, inputLength) } // MergeSort マージソート func MergeSort(input \\*[]int, left, right int) { // 要素数1つの場合は抜ける if right-left == 1 { return } // 配列を２つに分けるインデックス middle := left + (right-left)/2 // 配列左側 MergeSort(input, left, middle) // 配列右側 MergeSort(input, middle, right) var buffer []int // 左側と右側をバッファにためる（右側反転） for index := left; index \u0026lt; middle; index++ { buffer = append(buffer, (*input)[index]) } for index := right - 1; index \u0026gt;= middle; index-- { buffer = append(buffer, (*input)[index]) } // マージする scopeLeft := 0 scopeRight := len(buffer) - 1 for index := left; index \u0026lt; right; index++ { if buffer[scopeLeft] \u0026lt;= buffer[scopeRight] { // 左側採用 (*input)[index] = buffer[scopeLeft] scopeLeft++ } else { // 右側採用 (*input)[index] = buffer[scopeRight] scopeRight-- } } } これ考えたのぶっ飛んでるなあと思って Wikipedia 見てたら、考案者がフォン・ノイマンでやっぱりぶっ飛んでた（凄すぎ）","tags":["Go"],"title":"ソートアルゴリズムをGoで実装してみた"},{"categories":["computer-science"],"contents":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\nプロセスとは プロセスという概念は Linux において、ファイルシステム、ストリームに並んで重要な構成要素の１つです。\nプログラマが作成したソースコードはファイルに保存されます。そしてファイルの保存先はハードディスクです。\nプログラムの実行時、プログラムはハードディスクからメモリへと読み込まれます。\nCPU はメモリに読み込まれたプログラムを順次処理していきます。このとき、メモリに読み込まれて CPU に処理されているプログラムをプロセスといいます。\n１つのプロセスを処理できるのは１つの CPU のみです。\nそのため、同じプロセスしか一度に実行できなくなるといったことを避けるために、CPU はプロセスごとに処理時間を決めて次々に切り替えます。\n普段使っている PC やスマホは Youtube や Line や Twitter など、複数アプリを同時に起動して使用しています。\nあれは CPU が処理時間を決めて順に処理しているために実現されています。\nOS のコアであるカーネルはプロセスの優先順位を考慮して、各プロセスに処理時間を割り当てます。\n(この機能をスケジューラ、またはディスパッチャといいます。)\nアドレス空間 プロセス１つに対して、CPU とメモリがそれぞれ１つ必要です。CPU は前述の通り、処理時間を割り当てるのに対し、メモリはプロセスごとにアドレス空間を割り当てます。\nメモリにプログラムを書き込む際にはアドレスが必要です。\nしかしプロセスには 0 番地から始まるメモリが必要なため、１つのプロセスしか使えなくなってしまいます。\nそこでプロセスから見えるアドレス(論理アドレス)と実際のアドレス(物理アドレス)を分けてしまいます。\nこうすることで、カーネルと CPU によって論理アドレス → 物理アドレスと変換された実際のアドレスに対して書き込むことができます。\n１つのプロセスの論理アドレス、物理アドレスを全体としてアドレス空間といいます。\nアドレス空間はプロセスごとに割り当てられるので他のプロセスにアクセスできなくなります。\nプロセス API fork(2) 自分のプロセスを複製して新しいプロセスを作ります。\nGithub でも fork がありますが、意味合いは同じです。既存のリポジトリを複製します。複製したリポジトリは自由に更新できますが、fork した元のリポジトリに対しては更新はできません。\nプロセスの fork は元からあるプロセスを親プロセス、複製されたプロセスを子プロセスと呼びます。\n子プロセスの fork 実行時の戻り値は 0 です。\n(戻り値 0 は正常終了のステータスコード)そして親プロセスの fork 実行時の戻り値は子プロセスのプロセス ID です。\nシェルでもps auxコマンドを使用して確認できます。\nexec プロセスを新しいプログラムで上書きします。fork したプロセスで即座に exec することで新しいプログラムを時刻したことになります。\nwait(2) fork したプロセスの終了を待ちます。\n以上で、プロセスのライフサイクルは fork で子プロセスを生成し、exec で実行して wait によって、親プロセス側で終了判定するといった流れになります。\npipe(2) シェルではパイプ「|」を使って複数のコマンドをつなぐことができます。\n言い換えると、パイプはプロセスからプロセスにつながったストリームのことです。(ストリームはバイトの流れ道のイメージ)\npipe を実行すると、１つのプロセスでは、自身の書き込み用から読み込み用のファイルディスクリプタへ一方向のストリームが生成されます。\nまた、プロセスを fork するとストリームも複製されます。\nそこで pipe を実行した後に、fork し親プロセスの読み込み側、子プロセスの書き込み側を close すると、\n親プロセスの書き込み側 → 子プロセスの読み込み側への１つのストリームが生成されます。\nこれがシェルのパイプの原理です。\nデーモンプロセス http サーバや mysql サーバ、いわゆる常駐プロセスと呼ばれるものです。\nps auxコマンドを実行した際、TTY の項目が?になっているプロセスで、制御端末を持たないプロセスのことを言います。\nサーバのようにずっと動作し続けるプロセスは、実行したユーザを持たないことで停止されることがなくなります。\n(プロセスは、起動したユーザがログアウトするとプロセスも停止してしまうからです。)\n余談 プロセスについての情報がなかなか探せない中、本棚に眠っていた良書を思い出して引っ張り出した甲斐がありました。\n日々の業務でも触れていますが、 汎用的な知識は重要だと痛切に感じます。\n備考 ふつうの Linux プログラミング 第 2 版 Linux の仕組みから学べる gcc プログラミングの王道\n表紙イラスト：Loose Drawing\n","date":"July 5, 2020","hero":"/posts/category/computer-science/2020/09/process-management/hero.png","permalink":"https://uh-zz.github.io/posts/category/computer-science/2020/09/process-management/","summary":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\nプロセスとは プロセスという概念は Linux において、ファイルシステム、ストリームに並んで重要な構成要素の１つです。\nプログラマが作成したソースコードはファイルに保存されます。そしてファイルの保存先はハードディスクです。\nプログラムの実行時、プログラムはハードディスクからメモリへと読み込まれます。\nCPU はメモリに読み込まれたプログラムを順次処理していきます。このとき、メモリに読み込まれて CPU に処理されているプログラムをプロセスといいます。\n１つのプロセスを処理できるのは１つの CPU のみです。\nそのため、同じプロセスしか一度に実行できなくなるといったことを避けるために、CPU はプロセスごとに処理時間を決めて次々に切り替えます。\n普段使っている PC やスマホは Youtube や Line や Twitter など、複数アプリを同時に起動して使用しています。\nあれは CPU が処理時間を決めて順に処理しているために実現されています。\nOS のコアであるカーネルはプロセスの優先順位を考慮して、各プロセスに処理時間を割り当てます。\n(この機能をスケジューラ、またはディスパッチャといいます。)\nアドレス空間 プロセス１つに対して、CPU とメモリがそれぞれ１つ必要です。CPU は前述の通り、処理時間を割り当てるのに対し、メモリはプロセスごとにアドレス空間を割り当てます。\nメモリにプログラムを書き込む際にはアドレスが必要です。\nしかしプロセスには 0 番地から始まるメモリが必要なため、１つのプロセスしか使えなくなってしまいます。\nそこでプロセスから見えるアドレス(論理アドレス)と実際のアドレス(物理アドレス)を分けてしまいます。\nこうすることで、カーネルと CPU によって論理アドレス → 物理アドレスと変換された実際のアドレスに対して書き込むことができます。\n１つのプロセスの論理アドレス、物理アドレスを全体としてアドレス空間といいます。\nアドレス空間はプロセスごとに割り当てられるので他のプロセスにアクセスできなくなります。\nプロセス API fork(2) 自分のプロセスを複製して新しいプロセスを作ります。\nGithub でも fork がありますが、意味合いは同じです。既存のリポジトリを複製します。複製したリポジトリは自由に更新できますが、fork した元のリポジトリに対しては更新はできません。\nプロセスの fork は元からあるプロセスを親プロセス、複製されたプロセスを子プロセスと呼びます。\n子プロセスの fork 実行時の戻り値は 0 です。\n(戻り値 0 は正常終了のステータスコード)そして親プロセスの fork 実行時の戻り値は子プロセスのプロセス ID です。","tags":["computer-science"],"title":"プロセス管理"},{"categories":["AWS","DynamoDB"],"contents":"はじめに Dynamo のテーブルに GSI(グローバルセカンダリインデックス)を貼ってハッシュキー＋ソートキーでクエリするパターンが通常の使い方かと思います。\nではソートキーを日付にしていた場合、同じ日付範囲のデータを一括で取得できる方法はありますでしょうか？\n公式ドキュメントにはその辺の Tips なかったのですが、同僚から以下の記事を教えてもらいました。\nDynamoDB の設計力をあげたい\nこれの設計２を参考にしました。\n全データ共通のダミー列を用意して、以下の GSI を作成します。\nパーティションキーはダミー列 ソートキーに日付 これで同じ日付範囲の複数データを引っ張ってくることが可能になります。\n確かに美しいと言えないかもしれませんが、機転の効いた方法だと思いました。\n","date":"June 5, 2020","hero":"/posts/category/aws/2020/06/dynamo-only-sortkey-without-partionkey/hero.svg","permalink":"https://uh-zz.github.io/posts/category/aws/2020/06/dynamo-only-sortkey-without-partionkey/","summary":"はじめに Dynamo のテーブルに GSI(グローバルセカンダリインデックス)を貼ってハッシュキー＋ソートキーでクエリするパターンが通常の使い方かと思います。\nではソートキーを日付にしていた場合、同じ日付範囲のデータを一括で取得できる方法はありますでしょうか？\n公式ドキュメントにはその辺の Tips なかったのですが、同僚から以下の記事を教えてもらいました。\nDynamoDB の設計力をあげたい\nこれの設計２を参考にしました。\n全データ共通のダミー列を用意して、以下の GSI を作成します。\nパーティションキーはダミー列 ソートキーに日付 これで同じ日付範囲の複数データを引っ張ってくることが可能になります。\n確かに美しいと言えないかもしれませんが、機転の効いた方法だと思いました。","tags":["AWS","DynamoDB"],"title":"DynamoDB のソートキーだけで絞り込みたいとき"},{"categories":["Development"],"contents":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\nアジャイル開発 「アジャイル開発」っていうとなんかカッコいいしモダンっぽいというイメージをおそらく持っている人もいるでしょう。(私を含めて)\n逆に「ウォーターフォール開発」はなんか古臭いし、どこぞの金融系ぷ r、、おっと誰か来たみたいなのでこの辺で。\nとまあ、もてはやされたアジャイル開発ですが、フタを開けてみれば「要件定義 → 設計 → 実装 → テスト」の全工程を１つの単位として反復するという手法なのです。\n反復する期間はチームやプロジェクトによってまちまちですが、1 週間〜4 週間ほどです。\nってことはですよ、V 字モデルのウォーターフォールを短いスパンで回してるだけ？、、それウォーターフォールじゃねぇか！！\n、、というヤジも分からなくはありませんが、ちゃんとメリットがあります。\nメリット 1. スピーディー(早い) だってそうですよね。ウォーターフォールでは全工程を段階的に進めていくのでリリースまでに時間がかかってしまいます。\n対してアジャイルでは前工程を１つのサイクルとして反復するのでリリースまでの期間が短く済みます。\n2. やすい(安い ×) しかもアジャイルは、開発サイクルが短い分、仕様変更や追加機能の対応がしやすいというのもあります。\nウォーターフォールだと、段階的に進めるので、１つの仕様変更があった場合、工程を戻すことになり、、おぉ、、考えただけでも恐ろしいですね。\n3. ユーザーファースト(うまい?) これも納得ですね。\nリリースが早い分、クライアント(ユーザー)に効率よく素早く提供できる → クライアント喜ぶ → 褒められる → 嬉しい=うまい?\n(これは数合わせです)\nアジャイル開発の手法 手法は以下の３つです。\nスクラム エクストリームプログラミング ユーザ機能駆動開発 この中で私が経験したのは、スクラムのみです。(2020/07 時点)\nどのサイトでも言われている通り、この開発手法ではメンバーとのコミュニケーションが非常に重要です。\nそのイテレーション(スプリント)でリリースする機能も複数人が関わっていたり、メンバー間での連携が必要な機能だったり。。\n極めつけは１つのアプリの全機能を全メンバーが把握しているのがヨシとされるので、知らない機能は教えたり教わったりしないといけないからです。(これは私のチームだけなのかは知りませんが)\nまとめ 、、とすごく大変そうに見えますが(実際に大変ですが)、スクラムならではの団体戦みのある開発でまあうまく回せるんではないでしょうかというのが感想です。\n備考 表紙イラスト：Loose Drawing\n","date":"June 5, 2020","hero":"/posts/category/development/2020/08/agile-software-development/hero.png","permalink":"https://uh-zz.github.io/posts/category/development/2020/08/agile-software-development/","summary":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\nアジャイル開発 「アジャイル開発」っていうとなんかカッコいいしモダンっぽいというイメージをおそらく持っている人もいるでしょう。(私を含めて)\n逆に「ウォーターフォール開発」はなんか古臭いし、どこぞの金融系ぷ r、、おっと誰か来たみたいなのでこの辺で。\nとまあ、もてはやされたアジャイル開発ですが、フタを開けてみれば「要件定義 → 設計 → 実装 → テスト」の全工程を１つの単位として反復するという手法なのです。\n反復する期間はチームやプロジェクトによってまちまちですが、1 週間〜4 週間ほどです。\nってことはですよ、V 字モデルのウォーターフォールを短いスパンで回してるだけ？、、それウォーターフォールじゃねぇか！！\n、、というヤジも分からなくはありませんが、ちゃんとメリットがあります。\nメリット 1. スピーディー(早い) だってそうですよね。ウォーターフォールでは全工程を段階的に進めていくのでリリースまでに時間がかかってしまいます。\n対してアジャイルでは前工程を１つのサイクルとして反復するのでリリースまでの期間が短く済みます。\n2. やすい(安い ×) しかもアジャイルは、開発サイクルが短い分、仕様変更や追加機能の対応がしやすいというのもあります。\nウォーターフォールだと、段階的に進めるので、１つの仕様変更があった場合、工程を戻すことになり、、おぉ、、考えただけでも恐ろしいですね。\n3. ユーザーファースト(うまい?) これも納得ですね。\nリリースが早い分、クライアント(ユーザー)に効率よく素早く提供できる → クライアント喜ぶ → 褒められる → 嬉しい=うまい?\n(これは数合わせです)\nアジャイル開発の手法 手法は以下の３つです。\nスクラム エクストリームプログラミング ユーザ機能駆動開発 この中で私が経験したのは、スクラムのみです。(2020/07 時点)\nどのサイトでも言われている通り、この開発手法ではメンバーとのコミュニケーションが非常に重要です。\nそのイテレーション(スプリント)でリリースする機能も複数人が関わっていたり、メンバー間での連携が必要な機能だったり。。\n極めつけは１つのアプリの全機能を全メンバーが把握しているのがヨシとされるので、知らない機能は教えたり教わったりしないといけないからです。(これは私のチームだけなのかは知りませんが)\nまとめ 、、とすごく大変そうに見えますが(実際に大変ですが)、スクラムならではの団体戦みのある開発でまあうまく回せるんではないでしょうかというのが感想です。\n備考 表紙イラスト：Loose Drawing","tags":["Development"],"title":"アジャイル開発"},{"categories":null,"contents":"","date":"January 1, 0001","hero":"/images/default-hero.jpg","permalink":"https://uh-zz.github.io/en/about/","summary":"","tags":null,"title":""}] \ No newline at end of file +[{"categories":["Basic"],"contents":"はじめに １年経つのは早いですね。\n今年のサマリーとしては、通信大学へ入学したことと転職したこと、です。\n去年はこのブログの投稿を増やしていくと意気込んでいましたが実績は、、意気込みは大事なので来年も意気込んでいきます\u0026#x1f4aa;\n振り返りについては需要の有無に関わらず書いていきたいと思ってる所存です。\nバックナンバー 2021 年の振り返り 2022/01 とくに話すトピックはありませんでした。\n新年一発目こそなにかあれよ！と自分でツッコミを入れたくなったので、意識的に１月にイベントつくっていきます\n2022/02 コロナの感染拡大がまた出てきたころで、予定されていた開発合宿がオンラインでの開催になりました\n初のオンライン合宿開催！開発合宿についてご紹介！\nGatherはこのとき初めて使いましたが、会議室に入ると強制的にビデオ通話になったりホワイトボードを共有したりと Google Meet や Zoom のような使い方ができるのに加え、マップを自分たちでつくったりゴーカートができたりと、息抜き要素があったのが推しポイントです。\nこのとき気に入って、合宿のあともオンボーディングを Gather でやってたりもしたなぁと思い返したり\u0026#x1f60c;\n2022/03 とくに話すことはありませんでした。\n2022/04 ふらっと Kyash のイベントを見にいきました。\nKyash TechTalk #2 - Serverside のシステム構成とアーキテクチャ\nこのとき、Kyash のサーバ構成を知れたのもそうですが、苦労話や課題に思っていることを対外的に発信しているのを見て、技術力求められそうだなというのと、中の人楽しそうに話してるなと思ったのを覚えています。\nこのイベントのあと、メールでカジュアル面談のお誘いをもらったので、転職活動はしてなかったけど、興味本位でセッティングしてもらったのが今年の転職につながりました。\nまたプライベートな話題としては、通信大学に入学しました\n【通信教育課程】帝京大学理工学部情報科学科に編入学しました\n入ってから８ヶ月目で思うことは、年間 12 科目の単位を働きながら取るのは絶対ムリ！ではないかもしれませんが、ギリギリを攻めている感覚と怠惰な休日の時間を取りづらくなるということです。 これは勉強するリズムがついていいじゃないかという反面、興味が薄い科目に関して場当たり的な勉強をしてしまいがちなのと、休日を授業やレポートで埋めると休みが休みでなくなってしまう悲しみを少なからず感じるということです。\nこの振り返りは、来年 2 月の区切りのいいところで改めて記事にしようと思います。\n2022/05 ジムに行き始めました。きっかけはリモートワークをしていて一日座ってる時間が長いと寝つきが悪かったりするので、体を動かしてぐっすり眠りたい、と思ったからです 。\n今も継続して週に 2 回くらいは走りに行ってます。\n走るマシン（トレッドミル）しか活用できてないので、来年はほかのトレーニングにも手を出したいです。\n2022/06 とくに話すことはありませんでした。\n2022/07 通信大学の初めての単位習得試験があり、物理的な会場での受験でした。\n内心なにかしら交流があるかも\u0026#x1f60c;、とそわそわしていましたが、杞憂に終わりました。\n2022/08 昨年から月 1 で参加していた『プログラミング言語 Go』オンライン読書会が一区切りつきました。\n初めて参加した社外勉強会がこの読書会だったので、個人的に印象深く、毎回新しい知見を得る場として楽しませていただきました。\n今は柴田先生が主催するべつの読書会に参加していますが、相変わらず聞き専になってしまっているので、恥ずかしがらずに質問していくのを来年の抱負にしようと思います笑\n2022/09 今年は通信大学に入ったのを言い訳に、技術書以外の本を買ったり読んだりする機会が少なかったんですが、その中でも社会学のテキストが個人的に面白かったので、マイベストブックにノミネートしました。\n社会学 新版 (New Liberal Arts Selection) これまでぼんやり社会学を勉強したいなと思ってたところでこの本を強制的に読むことになり、ざっと主要なトピックを俯瞰することができました。\n個人的に、「文化と再生産」の話が好きです。\n2022/10 今年もしれっと hacktoberfest に参加していました。\nTシャツ届いてました〜thanks#Hacktoberfest pic.twitter.com/9K8N2eBpvg\n\u0026mdash; reo (@_uhzz_) March 2, 2022 以下の記事で紹介されているように、スパムが大量生産される問題を含みつつ、OSS 活動ををタイポ修正やちょっとしたバグフィックスから始められる、始めるモチベーションに使っています。（自分のプルリクがそうなっているかもしれないという思いもありつつ、健全な活動をしていると自分に言い聞かせています）\n「プログラムの修正を送ると T シャツがもらえる」キャンペーンが開発者に迷惑がられる理由とは？\n、とまあ今年も達成できたので、また特典が届いたたらツイートします。\nあとは、サウナ遠征（一人）で名古屋に行きました。 このときのスケジュールがスムーズすぎて、また来年遠征の予定を立て始めています笑\n※ツイート忘れてますが、ウェルビー栄デビューもこの遠征で達成しました\ncanal resortでととのいました pic.twitter.com/LxcUEt82Qu\n\u0026mdash; reo (@_uhzz_) October 27, 2022 ミライタワーだそうです pic.twitter.com/KRD0Vqy2QQ\n\u0026mdash; reo (@_uhzz_) October 27, 2022 2022/11 Kyash に入社しました\u0026#x1f44d;\n全体の感想としてカジュアル面談で話を聞いてから、選考に進み、オファーをいただくまでがすごく速かった気がします笑\n※このとき並行で数社選考を進めていたんですが、どのチームも魅力的だったとここで断っておきます\nその中でも、オンラインイベントで楽しそうに話してたのが忘れられず決断をしたのでした\nkyashに入社しました👍\n\u0026mdash; reo (@_uhzz_) November 1, 2022 ※転職エピソードについてはもっと語ることあるだろと自分にツッコミを入れつつ別途どこかで振り返ります。\n2022/12 Kyash に入って、初めて社のアドベントカレンダーに参加しました\n【Go】net/http パッケージで非推奨の Temporary の扱いについて\nあとは、Go アドベントカレンダーに今年も細々と投稿しました\n【Go/並行処理】Future パターンってなにか調べてみた！\nあとは、nilerrに影響を受けてnilpointerなるものを書いて静的解析ツールを作る実績も解除しました。\n作ったのはいいものの使い道なくね？と我に返ってしまい告知はしませんでしたが、ここで供養させていただこうと思います笑\nまとめ なにかアウトプットをたくさんしたという感じではないものの、人生してるなあという振り返りでした。\n来年の抱負は引き続きアウトプット増やすようにパブリックなコミットを意識しつつ、言い訳せずに積んでる本を消化します笑\nあとは、コミュニティに入れるように気持ち前のめりになって日々を過ごそうと思います。\n備考 表紙イラスト：Loose Drawing\n","date":"December 31, 2022","hero":"/posts/category/look-back-on/2022/12/31/hero.png","permalink":"https://uh-zz.github.io/posts/category/look-back-on/2022/12/31/","summary":"はじめに １年経つのは早いですね。\n今年のサマリーとしては、通信大学へ入学したことと転職したこと、です。\n去年はこのブログの投稿を増やしていくと意気込んでいましたが実績は、、意気込みは大事なので来年も意気込んでいきます\u0026#x1f4aa;\n振り返りについては需要の有無に関わらず書いていきたいと思ってる所存です。\nバックナンバー 2021 年の振り返り 2022/01 とくに話すトピックはありませんでした。\n新年一発目こそなにかあれよ！と自分でツッコミを入れたくなったので、意識的に１月にイベントつくっていきます\n2022/02 コロナの感染拡大がまた出てきたころで、予定されていた開発合宿がオンラインでの開催になりました\n初のオンライン合宿開催！開発合宿についてご紹介！\nGatherはこのとき初めて使いましたが、会議室に入ると強制的にビデオ通話になったりホワイトボードを共有したりと Google Meet や Zoom のような使い方ができるのに加え、マップを自分たちでつくったりゴーカートができたりと、息抜き要素があったのが推しポイントです。\nこのとき気に入って、合宿のあともオンボーディングを Gather でやってたりもしたなぁと思い返したり\u0026#x1f60c;\n2022/03 とくに話すことはありませんでした。\n2022/04 ふらっと Kyash のイベントを見にいきました。\nKyash TechTalk #2 - Serverside のシステム構成とアーキテクチャ\nこのとき、Kyash のサーバ構成を知れたのもそうですが、苦労話や課題に思っていることを対外的に発信しているのを見て、技術力求められそうだなというのと、中の人楽しそうに話してるなと思ったのを覚えています。\nこのイベントのあと、メールでカジュアル面談のお誘いをもらったので、転職活動はしてなかったけど、興味本位でセッティングしてもらったのが今年の転職につながりました。\nまたプライベートな話題としては、通信大学に入学しました\n【通信教育課程】帝京大学理工学部情報科学科に編入学しました\n入ってから８ヶ月目で思うことは、年間 12 科目の単位を働きながら取るのは絶対ムリ！ではないかもしれませんが、ギリギリを攻めている感覚と怠惰な休日の時間を取りづらくなるということです。 これは勉強するリズムがついていいじゃないかという反面、興味が薄い科目に関して場当たり的な勉強をしてしまいがちなのと、休日を授業やレポートで埋めると休みが休みでなくなってしまう悲しみを少なからず感じるということです。\nこの振り返りは、来年 2 月の区切りのいいところで改めて記事にしようと思います。\n2022/05 ジムに行き始めました。きっかけはリモートワークをしていて一日座ってる時間が長いと寝つきが悪かったりするので、体を動かしてぐっすり眠りたい、と思ったからです 。\n今も継続して週に 2 回くらいは走りに行ってます。\n走るマシン（トレッドミル）しか活用できてないので、来年はほかのトレーニングにも手を出したいです。\n2022/06 とくに話すことはありませんでした。\n2022/07 通信大学の初めての単位習得試験があり、物理的な会場での受験でした。\n内心なにかしら交流があるかも\u0026#x1f60c;、とそわそわしていましたが、杞憂に終わりました。\n2022/08 昨年から月 1 で参加していた『プログラミング言語 Go』オンライン読書会が一区切りつきました。\n初めて参加した社外勉強会がこの読書会だったので、個人的に印象深く、毎回新しい知見を得る場として楽しませていただきました。\n今は柴田先生が主催するべつの読書会に参加していますが、相変わらず聞き専になってしまっているので、恥ずかしがらずに質問していくのを来年の抱負にしようと思います笑\n2022/09 今年は通信大学に入ったのを言い訳に、技術書以外の本を買ったり読んだりする機会が少なかったんですが、その中でも社会学のテキストが個人的に面白かったので、マイベストブックにノミネートしました。\n社会学 新版 (New Liberal Arts Selection) これまでぼんやり社会学を勉強したいなと思ってたところでこの本を強制的に読むことになり、ざっと主要なトピックを俯瞰することができました。","tags":["Basic"],"title":"2022年の振り返り"},{"categories":["Go"],"contents":"はじめに こちらはKyash Advent Calendar 2022 の 13 日目の記事です。\n今年の 11 月に Kyash に入社しました！サーバサイドチームのueharaです\u0026#x1f44b;\n今回はnet/httpパッケージの非推奨メソッドであるTemporary()について、社のメンバーから知見を共有してもらったのでその話をします。\nnet/http パッケージの 非推奨メソッド Temporary() について Temporary()については、フューチャー社の記事にわかりやすくまとめられています。\nhttps://future-architect.github.io/articles/20220203a/\n上記の記事を踏まえて、ここでは非推奨になった経緯と対応について言及しようと思います。\nサッと概要を話すと、Temporary()はnet.Errorインターフェースに定義されているメソッドで、一時的なエラーかどうか判定するために用意されています。 ただし、「一時的」というのがうまく定義されていないとの理由で、こちらのメソッドは Go1.18 で非推奨になりました。\nnet.Error.Temporary has been deprecated. https://tip.golang.org/doc/go1.18\nTemporary()が非推奨になった経緯 前提として、net.Errorインターフェースは、以下のように定義されています ※ソースは Go 1.19 です\n// 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 \u0026#34;temporary\u0026#34; errors are timeouts, and the few exceptions are surprising. // Do not use this method. Temporary() bool } 非推奨になったときの issue を追ってみます\nhttps://github.com/golang/go/issues/45729\nissue によると、Temporary()を実装していて、かつ true を返している標準パッケージのメソッドは以下の２パターンになります。\nパターン 1: Timeout 系のエラーだけど、 Temporary() メソッドで true を返す context: context.DeadlineExceeded crypto/tls: All Dial timeouts. net: Various timeouts. net/http: Timeout when reading headers or bodies. (The error type is named httpError, but it is only used for timeouts.) net/http: Also, HTTP/2 timeout reading response headers. os: os.ErrDeadlineExceeded (defined in internal/poll) パターン 2: Timeout 系ではないエラーで Temporary() が true を返す(本来こっちだけの想定) net: ECONNRESET and ECONNABORTED errors returned by accept(). net: EAI_AGAIN errors returned by getaddrinfo(). syscall/syscall_plan9.go, syscall/syscall_unix.go, syscall/syscall_js.go,syscall/syscall_windows.go: EINTR, EMFILE, ENFILE, plus errors also considered timeouts: EAGAIN, EWOULDBLOCK, EBUSY, and ETIMEDOUT. (Some minor \u0026gt; variation between operating systems.) つまり、実際に「一時的なエラー」とみなされるエラーは、以下のようなシステムコールエラーとのことです。\nECONNRESET ECONNABORTED EAI_AGAIN EINTR EMFILE ENFILE EAGAIN EWOULDBLOCK EBUSY ETIMEDOUT 結論として、Timeout 系のエラーなのにTemporary()でtrueを返しているパターンを除くと、本来のTemporary()は少数のシステムコールエラーによるもの（few exceptions are surprising）である。しかし、前者をカウントしていることにより、Temporary()がtrueになるパターンが頻繁に発生してるように見えるため、Temporary()の定義が明確でないから非推奨にしたほうがいいんじゃね、とのことでした。\nlinter でも非推奨であることを警告されます 社のメンバーから共有してもらうきっかけになった問題です。\n以下のコードは、net.Errorインターフェースを満たし、Temporary()をつかうサンプルです\npackage main import ( \u0026#34;fmt\u0026#34; \u0026#34;net\u0026#34; ) type MyNetError struct{} func (m MyNetError) Error() string { return \u0026#34;my net error\u0026#34; } func (m MyNetError) Timeout() bool { return false } func (m MyNetError) Temporary() bool { return true } var _ net.Error = \u0026amp;MyNetError{} func myFunc() error { return MyNetError{} } func main() { if ne, ok := myFunc().(net.Error); ok \u0026amp;\u0026amp; ne.Temporary() { fmt.Println(ne.Error()) } } このプログラムを linter でチェックすると、以下のように警告が出ます。 linter のランナーに、golangci-lintをつかいます。\n$ golangci-lint run net.go:19:44: SA1019: ne.Temporary has been deprecated since Go 1.18 because it shouldn\u0026#39;t be used: Temporary errors are not well-defined. Most \u0026#34;temporary\u0026#34; errors are timeouts, and the few exceptions are surprising. Do not use this method. (staticcheck) if ne, ok := myError().(net.Error); ok \u0026amp;\u0026amp; ne.Temporary() { この警告を回避するために、２つの方法が挙げられます。\n回避方法１: Temporary() をつかわない シンプルにTemporary()を消してしまうパターンです\nif ne, ok := myError().(net.Error); ok { fmt.Println(ne.Error()) } ただし、標準パッケージではつかわれている箇所もあり、(限定的な)代替案についても議論されています。\n回避方法 2: linter のチェックをしない linter のチェックを行わないよう、ディレクティブを設定します。\ngolangci-lint で linter のチェックをスキップする https://golangci-lint.run/usage/false-positives/#nolint-directive\n//nolint:staticcheck if ne, ok := myError().(net.Error); ok \u0026amp;\u0026amp; ne.Temporary() { fmt.Println(ne.Error()) } 直接 staticcheck を実行する //lint:ignoreディレクティブをつかいます。\n//lint:ignore SA1019 no problem, thanks if ne, ok := myError().(net.Error); ok \u0026amp;\u0026amp; ne.Temporary() { fmt.Println(ne.Error()) } さいごに Temporary()で判定したいようなケースはなるべくさけて代替のエラーを見つけるのがよさそうですね\n学びとしては、非推奨になったきっかけの issue を読んでみて、標準パッケージを読むことに対する抵抗が少しなくなったような気がしたことです\u0026#x1f4a6;\n","date":"December 13, 2022","hero":"/posts/category/go/2022/12/kyash-advent-calendar/hero.png","permalink":"https://uh-zz.github.io/posts/category/go/2022/12/kyash-advent-calendar/","summary":"はじめに こちらはKyash Advent Calendar 2022 の 13 日目の記事です。\n今年の 11 月に Kyash に入社しました！サーバサイドチームのueharaです\u0026#x1f44b;\n今回はnet/httpパッケージの非推奨メソッドであるTemporary()について、社のメンバーから知見を共有してもらったのでその話をします。\nnet/http パッケージの 非推奨メソッド Temporary() について Temporary()については、フューチャー社の記事にわかりやすくまとめられています。\nhttps://future-architect.github.io/articles/20220203a/\n上記の記事を踏まえて、ここでは非推奨になった経緯と対応について言及しようと思います。\nサッと概要を話すと、Temporary()はnet.Errorインターフェースに定義されているメソッドで、一時的なエラーかどうか判定するために用意されています。 ただし、「一時的」というのがうまく定義されていないとの理由で、こちらのメソッドは Go1.18 で非推奨になりました。\nnet.Error.Temporary has been deprecated. https://tip.golang.org/doc/go1.18\nTemporary()が非推奨になった経緯 前提として、net.Errorインターフェースは、以下のように定義されています ※ソースは Go 1.19 です\n// 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 \u0026#34;temporary\u0026#34; errors are timeouts, and the few exceptions are surprising.","tags":["Go"],"title":"netパッケージで非推奨のTemporaryメソッドの扱いについて"},{"categories":["Go"],"contents":"はじめに @uh-zzです！\nこの記事は、Go Advent Calendar 2022の 10 日目の記事になります！\n今年は、個人的に色々なことに挑戦した年だったなあと振り返るとともに、去年のアドベントカレンダーからもう１年経つのか〜という気持ちです\nこの記事では、Go における Future パターンをご紹介できればと思います\nFuture パターンとは あるメソッドを呼び出すとします。 もしもオブジェクトが、そのメソッドを実行できる状態なら、実行します。 でも、実行できない状態なら、将来実行できる状態になるまで待つようにしたいとします。 その時に使えるのがこの Future パターンです。 future は「未来」という意味です\nもう少し正確にお話しましょう。 単にあるクラスに 「実行できる状態になるまで待つ」 という機能を入れるわけではありません。 すでに存在しているクラスに一皮かぶせて、 「実行できる状態になるまで待てるような機能を追加する」 というのが Future パターンです。\n出典: 結城浩, Future パターン, デザインパターン紹介\n上記の参考記事内では、Java をつかったマルチスレッドプログラミングで Future パターンが実装されています。\n引用箇所の説明がほぼすべてですが、イメージ図で補足するとこんな感じになります\nflowchart LR 呼び出し元 --\u0026gt; Futureメソッド -- 実行できるようになるまで待つ --\u0026gt; 処理するメソッド 呼び出し元と処理するメソッドの間に Future メソッドを挟むことで、Future メソッドがプロキシ的に働き、非同期的に処理するメソッドを実行できるようになっています。\nGo だとこんなかんじにかけるらしい 以下の記事で Future/Promiseという説明書されています\nhttps://ascii.jp/elem/000/001/486/1486902/\npackage main func readFile(path string) chan string { // ファイルを読み込み、その結果を返すFutureを返す promise := make(chan string) // readFile とは別のゴルーチンでファイルを読み出す go func() { content, err := os.ReadFile(path) if err != nil { fmt.Printf(\u0026#34;read error %s\\n\u0026#34;, err.Error()) close(promise) } else { // 約束を果たした promise \u0026lt;- string(content) } }() return promise } func printFunc(futureSource chan string) chan []string { // 文字列中の関数一覧を返すFutureを返す promise := make(chan []string) // printFunc とは別のゴルーチンで文字列操作する go func() { var result []string // futureSource は readFile で読みだしたファイルの中身です // // readFile(ファイル読み込み)が完了して、 futureSource(=promise) に // 中身が送信されるまでこの処理は実行されません for _, line := range strings.Split(\u0026lt;-futureSource, \u0026#34;\\n\u0026#34;) { if strings.HasPrefix(line, \u0026#34;func \u0026#34;) { result = append(result, line) } } // 約束を果たした promise \u0026lt;- result }() return promise } func main() { futureSource := readFile(\u0026#34;future_promise.go\u0026#34;) // 一見、 readFile が実行されたあとに、すぐ printFunc が実行されるように見えます // しかし、 printFunc の引数(futureSource)がチャネルになっているので、 // futureSourceが値を受信するまで関数内で、futureSource を使うことができない // // よって関数内で実行待ちが発生します futureFuncs := printFunc(futureSource) // チャネル(futureFuncs)を受信するまでブロック fmt.Println(strings.Join(\u0026lt;-futureFuncs, \u0026#34;\\n\u0026#34;)) } ※記事内にあるコードに、コメントを追記させていただきました。\u0026#x1f64f;\nJava で実現していた Future メソッドとは違い、Go ではチャネルをつかって実行待ちを表現できるようです。 main 関数だけ見ると、呼び出し側では同期的に見えますが、内部でチャネルによる非同期処理が行われています。\n実際に使われているところを深ぼってみた https://github.com/hashicorp/raft\nError()の実装はここ https://github.com/hashicorp/raft/blob/6b4e32088e0bda22ea219fc89b0ee47f420e2b0b/future.go#L168\nraft の apply だけを深堀りしてみるのもいいかもしれない\nおわりに Future パターンを取り上げてみましたが、蓋を開けてみるとチャネルを使った並行プログラミングでよく目にするような処理に、”名前がついてたんだ〜！”と思う方もいるでしょう（私のことです）\nパターンを知る → 使っている OSS を見にいく流れは体験としていいなと思ったので、来年も引き続きやっていきます\u0026#x1f44b;\n","date":"December 10, 2022","hero":"/posts/category/go/2022/12/qiita-advent-calender/hero.png","permalink":"https://uh-zz.github.io/posts/category/go/2022/12/qiita-advent-calender/","summary":"はじめに @uh-zzです！\nこの記事は、Go Advent Calendar 2022の 10 日目の記事になります！\n今年は、個人的に色々なことに挑戦した年だったなあと振り返るとともに、去年のアドベントカレンダーからもう１年経つのか〜という気持ちです\nこの記事では、Go における Future パターンをご紹介できればと思います\nFuture パターンとは あるメソッドを呼び出すとします。 もしもオブジェクトが、そのメソッドを実行できる状態なら、実行します。 でも、実行できない状態なら、将来実行できる状態になるまで待つようにしたいとします。 その時に使えるのがこの Future パターンです。 future は「未来」という意味です\nもう少し正確にお話しましょう。 単にあるクラスに 「実行できる状態になるまで待つ」 という機能を入れるわけではありません。 すでに存在しているクラスに一皮かぶせて、 「実行できる状態になるまで待てるような機能を追加する」 というのが Future パターンです。\n出典: 結城浩, Future パターン, デザインパターン紹介\n上記の参考記事内では、Java をつかったマルチスレッドプログラミングで Future パターンが実装されています。\n引用箇所の説明がほぼすべてですが、イメージ図で補足するとこんな感じになります\nflowchart LR 呼び出し元 --\u0026gt; Futureメソッド -- 実行できるようになるまで待つ --\u0026gt; 処理するメソッド 呼び出し元と処理するメソッドの間に Future メソッドを挟むことで、Future メソッドがプロキシ的に働き、非同期的に処理するメソッドを実行できるようになっています。\nGo だとこんなかんじにかけるらしい 以下の記事で Future/Promiseという説明書されています\nhttps://ascii.jp/elem/000/001/486/1486902/\npackage main func readFile(path string) chan string { // ファイルを読み込み、その結果を返すFutureを返す promise := make(chan string) // readFile とは別のゴルーチンでファイルを読み出す go func() { content, err := os.","tags":["Go"],"title":"Futureパターンが使われているOSSを見てみた"},{"categories":["Basic"],"contents":"ご連絡 4 月から通信大学での学習を始めて、もう少しで半年になります。\n節目というか、ちょっと時間ができたので、私が履修している科目一覧を Notion で管理しようと思い立ち、さくっと作ってみました。\n科目一覧 - Notion\nこれから同じように学習される方の参考になれば幸いです。（私も諸先輩方のブログを見て、参考になったので恩返しできれば！）\n近況 元気にやっています\u0026#x1f44b;\n備考 表紙イラスト：Loose Drawing\n","date":"September 4, 2022","hero":"/posts/category/look-back-on/2022/09/04/preview-courses-at-teikyo-univ/hero.png","permalink":"https://uh-zz.github.io/posts/category/look-back-on/2022/09/04/preview-courses-at-teikyo-univ/","summary":"ご連絡 4 月から通信大学での学習を始めて、もう少しで半年になります。\n節目というか、ちょっと時間ができたので、私が履修している科目一覧を Notion で管理しようと思い立ち、さくっと作ってみました。\n科目一覧 - Notion\nこれから同じように学習される方の参考になれば幸いです。（私も諸先輩方のブログを見て、参考になったので恩返しできれば！）\n近況 元気にやっています\u0026#x1f44b;\n備考 表紙イラスト：Loose Drawing","tags":["Basic"],"title":"履修科目一覧をNotionでつくりました"},{"categories":null,"contents":"はじめに 読んだ記事とか本のリンクを張っておきます\n読んだ記事 アーキテクトに求められるマインドとは / mindset for an architect\n「少なくとも、最悪ではないアーキテクチャを狙う」\n自分の中で新しい視点だった(常に選択肢の中で(世間的に)最善とされているものがいいという思考をしてる)\n「変更が容易であれば、最初から望ましいアーキテクチャを正確に設計しなければならないという、プレッシャーも少なくなる」\nRe: スクラム開発チームと業務委託エンジニアの相性が最悪だと思っている\nSpring で快適な DB 疎通ユニットテストライフを送りたい\nyaml、json、または csv などのファイルでテスト用データの事前投入や結果比較を容易にしてくれます\nDatabase RIder はテストメソッド単位で使用するデータファイルを指定できる\n友達に教えてもらった。テストデータをコードと別で、テスト前後の比較も簡単にしてくれるのはすごい。\n「“楽しくないけどお金のためにやる人”はやはり伸びない」まつもとゆきひろ氏が説く“プログラマーに向いている人”\n「ノーコードによって仕事が奪われるイメージはない」まつもとゆきひろ × 高橋直大 × 楠正憲が語る、これからのプログラマーの仕事\nAmazon DynamoDB: A Scalable, Predictably Performant, and Fully Managed NoSQL Database Service\nまだよんでない\nDomain-Driven Design Simplified.\nまだよんでない\n読んだ本 自分に気づく心理学-加藤 諦三(著)\nLean と DevOps の科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (impress top gear)-Nicole Forsgren Ph.D. (著), Jez Humble (著), Gene Kim (著), 武舎広幸 (翻訳), 武舎るみ (翻訳)\nJABEE 対応 技術者倫理入門-小出 泰士(著)\nやさしく学べる基礎物理-基礎物理教育研究会(編集)\n星の王子さま-サン=テグジュペリ(著)\n","date":"July 5, 2022","hero":"/images/default-hero.jpg","permalink":"https://uh-zz.github.io/posts/category/inputs/2022/07/","summary":"はじめに 読んだ記事とか本のリンクを張っておきます\n読んだ記事 アーキテクトに求められるマインドとは / mindset for an architect\n「少なくとも、最悪ではないアーキテクチャを狙う」\n自分の中で新しい視点だった(常に選択肢の中で(世間的に)最善とされているものがいいという思考をしてる)\n「変更が容易であれば、最初から望ましいアーキテクチャを正確に設計しなければならないという、プレッシャーも少なくなる」\nRe: スクラム開発チームと業務委託エンジニアの相性が最悪だと思っている\nSpring で快適な DB 疎通ユニットテストライフを送りたい\nyaml、json、または csv などのファイルでテスト用データの事前投入や結果比較を容易にしてくれます\nDatabase RIder はテストメソッド単位で使用するデータファイルを指定できる\n友達に教えてもらった。テストデータをコードと別で、テスト前後の比較も簡単にしてくれるのはすごい。\n「“楽しくないけどお金のためにやる人”はやはり伸びない」まつもとゆきひろ氏が説く“プログラマーに向いている人”\n「ノーコードによって仕事が奪われるイメージはない」まつもとゆきひろ × 高橋直大 × 楠正憲が語る、これからのプログラマーの仕事\nAmazon DynamoDB: A Scalable, Predictably Performant, and Fully Managed NoSQL Database Service\nまだよんでない\nDomain-Driven Design Simplified.\nまだよんでない\n読んだ本 自分に気づく心理学-加藤 諦三(著)\nLean と DevOps の科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (impress top gear)-Nicole Forsgren Ph.D. (著), Jez Humble (著), Gene Kim (著), 武舎広幸 (翻訳), 武舎るみ (翻訳)","tags":null,"title":"2022年07月に読んだ記事とか本とか"},{"categories":["Basic"],"contents":"はじめに 表題の通り、今年の 4 月から帝京大学理工学部情報科学科の通信教育課程に 2 年次編入しました。\nそもそもの経緯と入るまでの話、入って 1 ヶ月経過した後の所感をまとめておきたいと思います。\nきっかけ 大学進学について 通信制大学へ進学したいと思ったのは今年に入ってからではなく、ここ 2 年くらい検討していました。\n当初は理工系ではなく、社会学/哲学に興味があり、その方面の勉強がしたいと漠然と考えていました。\nただ 2 年の間、大学への入学を躊躇してたのは以下の理由がありました。\n通信制大学の卒業が難しい、また卒業率が低いといった情報を見て腰が重かった 働きながら時間が取れない、平日のフルタイムかつ出社している場合、早朝か、仕事から帰ってきて勉強時間を確保する必要が出てくるので、リモートできないと厳しい とりあえず入門書を買って積んでおけば自分で勉強できるし、進学しなくてもいいのでは？と諦めムードを出していた 以上の理由から悩んでは忘れるを一人繰り返しては日々を過ごしていました。\nキャリアについて考えるようになった そんな中、昨年末に以下の記事を拝見しました。\n生涯現役のソフトウェアエンジニアでありたい。IC（Individual Contributor）のキャリアパスがあると自覚するまで 10 年の軌跡\nIC(Individual Contributor)というキャリアがあるのかというのと、記事中の主張から自分のキャリアについて振り返る様になりました。\nこれまでのキャリアは前述のようにかなり行きあたりばったりでしたが、その中にも不動となる主軸が 2 つありました。(中略)\n1 つは「毎日楽しく開発したい」ということ。(中略)\nもう 1 つの軸は「選択肢を常に複数確保する」ことです。(中略)\nこの「毎日楽しく開発したい」は、私がエンジニアになりたいと思った動機「楽しく(刺激的に)生きたい」に通じるものがあり、IC というキャリアないしはテクニカルスキルをあげることで自分の幸福につながるのかという気づきがありました。\n遠回りのような近道のような、どちらとも言えないですが、自分で出した答えの１つが大学進学、それもコンピュータに関する学位を取得するということでした。\nここについては自分の中で消化しきれていない部分もあるので、別の記事で改めて振り返ることにします。\n帝京大学に決めたのはそこまで時間がかからなかった フルタイムで働きながらコンピュータに関する学位が取得できる通信制大学は、調べた限りだと選択肢は限られました。\nまた、同じくエンジニアとして働きながら勉強されている方のブログが大変参考になりました。\n帝京大学理工学部(通信教育課程)の社会人大学生 1 年目をふりかえる\n帝京大学の通信教育課程の学生やってます\n@gkzvoice さんには twitter でブログに関して質問させていただき、またアドバイスまでいただいたので感謝です。\n入るまでの手続きなど 詳細な手続きは募集要項にあるので、ここでは所感を述べるだけにします。\n調査書、成績表の発行を、所属していた専門学校に依頼する必要があるので、余裕を持って出願する 志望理由を記載する必要があるので、動機と抱負は棚卸ししてたほうがスムーズかも 2 年次編入について 今回 2 年次編入で出願することができました。\nというのも、情報系専門学校の 2 年制を卒業しているので、編入の要件を満たしていたからというのが理由です。\n要件を満たしていれば、専門学校での授業内容がまとめられたシラバス？を願書と一緒に提出した後、大学にて専門学校の授業内容から、関連する大学側での科目が履修済みとして、認定されます。\n今回は認定された科目が上限数に達していたので、晴れて編入することができたのでした。\nそして入学しました 出願から約 2 ヶ月後、晴れて入学式を迎えることができました。\n日本武道館で約 1 時間のコンパクトな式が執り行なわれ、あれよあれよと駅に流れ着き帰宅しました。\n早起き成功して入学式参加してきました、午後からはお仕事します pic.twitter.com/tnncLx3J7x\n\u0026mdash; reo (@_uhzz_) April 4, 2022 社会人なので、午後からはお仕事しました\n1 ヶ月が経過して 学生という自覚を少し感じるようになりました。\nここ数日はレポート期限と授業の多さにやられていてどこか上の空でした。（まだ試験が残っているのでしばらくはこの状態が続きそう）\n今回、履修登録した科目と進捗状況についても別の記事でまとめます。\nまとめ 通学してないこともあり、社会人大学生になった自覚は正直実感しにくいというのが所感です。\nただ勉強する習慣ができつつあることや、レポートを通してドキュメンテーションの大切さを日々感じるようにはなりました。\n今後はブログを通して、進捗や所感をアウトプットしていければなとぼんやり考えています。\n本業と学業、どちらも進捗出していくぞ〜\n備考 表紙イラスト：Loose Drawing\n","date":"May 31, 2022","hero":"/posts/category/look-back-on/2022/05/31/go-to-the-teikyo-university/hero.png","permalink":"https://uh-zz.github.io/posts/category/look-back-on/2022/05/31/go-to-the-teikyo-university/","summary":"はじめに 表題の通り、今年の 4 月から帝京大学理工学部情報科学科の通信教育課程に 2 年次編入しました。\nそもそもの経緯と入るまでの話、入って 1 ヶ月経過した後の所感をまとめておきたいと思います。\nきっかけ 大学進学について 通信制大学へ進学したいと思ったのは今年に入ってからではなく、ここ 2 年くらい検討していました。\n当初は理工系ではなく、社会学/哲学に興味があり、その方面の勉強がしたいと漠然と考えていました。\nただ 2 年の間、大学への入学を躊躇してたのは以下の理由がありました。\n通信制大学の卒業が難しい、また卒業率が低いといった情報を見て腰が重かった 働きながら時間が取れない、平日のフルタイムかつ出社している場合、早朝か、仕事から帰ってきて勉強時間を確保する必要が出てくるので、リモートできないと厳しい とりあえず入門書を買って積んでおけば自分で勉強できるし、進学しなくてもいいのでは？と諦めムードを出していた 以上の理由から悩んでは忘れるを一人繰り返しては日々を過ごしていました。\nキャリアについて考えるようになった そんな中、昨年末に以下の記事を拝見しました。\n生涯現役のソフトウェアエンジニアでありたい。IC（Individual Contributor）のキャリアパスがあると自覚するまで 10 年の軌跡\nIC(Individual Contributor)というキャリアがあるのかというのと、記事中の主張から自分のキャリアについて振り返る様になりました。\nこれまでのキャリアは前述のようにかなり行きあたりばったりでしたが、その中にも不動となる主軸が 2 つありました。(中略)\n1 つは「毎日楽しく開発したい」ということ。(中略)\nもう 1 つの軸は「選択肢を常に複数確保する」ことです。(中略)\nこの「毎日楽しく開発したい」は、私がエンジニアになりたいと思った動機「楽しく(刺激的に)生きたい」に通じるものがあり、IC というキャリアないしはテクニカルスキルをあげることで自分の幸福につながるのかという気づきがありました。\n遠回りのような近道のような、どちらとも言えないですが、自分で出した答えの１つが大学進学、それもコンピュータに関する学位を取得するということでした。\nここについては自分の中で消化しきれていない部分もあるので、別の記事で改めて振り返ることにします。\n帝京大学に決めたのはそこまで時間がかからなかった フルタイムで働きながらコンピュータに関する学位が取得できる通信制大学は、調べた限りだと選択肢は限られました。\nまた、同じくエンジニアとして働きながら勉強されている方のブログが大変参考になりました。\n帝京大学理工学部(通信教育課程)の社会人大学生 1 年目をふりかえる\n帝京大学の通信教育課程の学生やってます\n@gkzvoice さんには twitter でブログに関して質問させていただき、またアドバイスまでいただいたので感謝です。\n入るまでの手続きなど 詳細な手続きは募集要項にあるので、ここでは所感を述べるだけにします。\n調査書、成績表の発行を、所属していた専門学校に依頼する必要があるので、余裕を持って出願する 志望理由を記載する必要があるので、動機と抱負は棚卸ししてたほうがスムーズかも 2 年次編入について 今回 2 年次編入で出願することができました。\nというのも、情報系専門学校の 2 年制を卒業しているので、編入の要件を満たしていたからというのが理由です。\n要件を満たしていれば、専門学校での授業内容がまとめられたシラバス？を願書と一緒に提出した後、大学にて専門学校の授業内容から、関連する大学側での科目が履修済みとして、認定されます。\n今回は認定された科目が上限数に達していたので、晴れて編入することができたのでした。\nそして入学しました 出願から約 2 ヶ月後、晴れて入学式を迎えることができました。","tags":["Basic"],"title":"【通信教育課程】帝京大学理工学部情報科学科に編入学しました"},{"categories":["Basic"],"contents":"はじめまして！\nこのページでは、いくつか自己紹介をしたいと思います。\n内容に関しては追って更新しますので、しばらくお待ちくださいませ。\n※「待てないよ!早く知りたい!」という意見がありましたら、お気軽に Twitter にてご連絡ください。\n備考 表紙イラスト：Loose Drawing\n","date":"May 5, 2022","hero":"/posts/introduction/hero.png","permalink":"https://uh-zz.github.io/posts/introduction/","summary":"はじめまして！\nこのページでは、いくつか自己紹介をしたいと思います。\n内容に関しては追って更新しますので、しばらくお待ちくださいませ。\n※「待てないよ!早く知りたい!」という意見がありましたら、お気軽に Twitter にてご連絡ください。\n備考 表紙イラスト：Loose Drawing","tags":["Basic"],"title":"Introduction"},{"categories":["Basic"],"contents":"はじめに 今年のふりかえりをするために個人ブログを数ヶ月ぶりに更新しています。\nしばらくぶりに拙ブログを見ていて、ぜんぜんメンテしてなかったや。。の反省を強く感じたので来年はアウトプットをもっともっと増やします！\n2021/01 とくに話すトピックはありませんでした。\n読んでた本 改訂 2 版 みんなの Go 言語\nGo プログラミング実践入門　標準ライブラリでゼロから Web アプリを作る\n2021/02 とくに話すトピックはありませんでした。\n読んでた本 達人プログラマー ―熟達に向けたあなたの旅― 第 2 版 2021/03 このころから年内に引っ越しを考えはじめました。\n部屋に不満はありませんでしたが、ぼんやりと中央線沿い(=東京の西側)がかっこいいというイメージをもっていたので一人でちょくちょく出向いていました。\n主に、杉並区エリア(中野/高円寺/阿佐ヶ谷/荻窪)を中心にまわっていました。\n特に、荻窪にある杉並アニメーションミュージアムは、展示も楽しく見れますが、ミュージアムが入っている杉並会館の雰囲気が抜群にいいのでおすすめです。\n2021/04 転職しました。社会人４年目にして３社目になります。\n前職と同じくサーバーサイドのポジションです。\n前職では、コロナ以降フルリモートでしたが、転職後は週３出社になりました。\n出社になってからは、ランチをメンバーと取るようになり、コミュニケーションが増えたのがメリットに感じました。\n仕事に関して前職では主に、Java/Go/Node.js での開発を２年ほどしていましたが、転職直後は Ruby on Rails での開発がメインになりました。\nはじめての Ruby と Rails ということもあり、メンバーにはだいぶお世話になりながらも、プライベートではおすすめの参考書をかたっぱしから読む生活をしていました。\n読んでた本 プロを目指す人のための Ruby 入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plus シリーズ)\nパーフェクト Ruby on Rails 【増補改訂版】 (Perfect series)\nリーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)\n2021/05 緊急事態宣言の期間に入り、ほぼフルリモートになりました。\nこの頃のコミットを見てみると、主に Rails プロジェクトでのバグフィックスや、小さな機能追加をしていました。\n(レビューでいろいろ教えてくれたメンバーには感謝です 💦)\nコードレビューに関して前職ではほぼ対面レビューだったのに対して、転職してからは Github 上でのレビューに切り替わったことで、レビュアー以外のメンバーにも非同期的にチェックしてもらえたのがすごくよかったです。\n2021/06 コミットを見てみると、この頃に担当したタスクにだいぶ時間を割いていました。\nというのも、タスクを進める上で発生した海外担当者とのメールであくせくしていた思い出があります。\n慣れない英語メールのやり取りが長引いてしまったものの、説明するのに必要なドメイン知識の理解がだいぶ進んだので、トレードオフだったのかなあと後になって感じています。\n読んでた本 インタフェースデザインの心理学 第 2 版 ―ウェブやアプリに新たな視点をもたらす 100 の指針\nNO RULES(ノー・ルールズ) 世界一「自由」な会社、NETFLIX\n2021/07 この月から、「プログラミング言語 Go」オンライン読書会に参加するようになりました。\n月に 1 度の読書会ですが、毎回新しい発見があって楽しいです。\nプライベートではそろそろ引っ越しをしようと suumo を見ていて、何件かピックアップして不動産に行きました。\nピックアップした物件ではなかったものの、ちょうどその日に空いた物件を一番乗りで見に行くことになり、初日で即決しました。\n当初の予定通り、中央線沿いに決まったのでこの頃は浮かれていました。\n2021/08 社外のオンライン LTに参加したりしました。\n2021/09 この頃のコミットを見ると、社内での Go プロジェクトへのコミットが少しずつ増えてきました。\nプライベートでは、一人散歩でよく歩いてました。\nよかったコース 国営昭和記念公園\n新宿御苑\n読んだ本 プリンシプル オブ プログラミング 3 年目までに身につけたい 一生役立つ 101 の原理原則 2021/10 この頃、ようやく緊急事態宣言が解除されました。\n開発合宿があり、LTなどしました。\nプライベートでは、hacktoberfestに参加したりしました。\n初参加かつ、OSS も初めてではありましたが、コミットできそうなリポジトリに５つプルリクエストを出しました。\nT シャツ獲得！の要件を満たしたので現在、発送待ちです。（届いたらツイートします）\n2021/11 Go Conference 2021 Autumnにボランティアスタッフで参加させていただきました。\nパートナーやスタッフに、社のロゴや twitter アカウントを載せてもらえたのは感無量でした。\n(運営の方ありがとうございます！)\n来年は、もっともっと関わっていくぞ〜の気持ちになりました。\n読んだ本 Software Design (ソフトウェアデザイン) 2021 年 12 月号 2021/12 Go に対する機運が社内でも高まってきました。(有志で勉強会を開くようになりました。)\nまた、個人的にGo アドベントカレンダーにも初参加してみました。\n読んだ本 達人に学ぶ SQL 徹底指南書 第 2 版 初級者で終わりたくないあなたへ まとめ 今年は、転職＆引っ越しと、いろいろ変化の多い年でした。\nあと、少しずつ社外のイベント/コミュニティにも参加できるようになってきました。\n来年は、アウトプットを増やして、社と私の認知度を上げていくのを目標にします。\n（コミュニティ活動も積極的に参加していくぞ〜！！）\n備考 表紙イラスト：Loose Drawing\n","date":"December 31, 2021","hero":"/posts/category/look-back-on/2021/hero.png","permalink":"https://uh-zz.github.io/posts/category/look-back-on/2021/","summary":"はじめに 今年のふりかえりをするために個人ブログを数ヶ月ぶりに更新しています。\nしばらくぶりに拙ブログを見ていて、ぜんぜんメンテしてなかったや。。の反省を強く感じたので来年はアウトプットをもっともっと増やします！\n2021/01 とくに話すトピックはありませんでした。\n読んでた本 改訂 2 版 みんなの Go 言語\nGo プログラミング実践入門　標準ライブラリでゼロから Web アプリを作る\n2021/02 とくに話すトピックはありませんでした。\n読んでた本 達人プログラマー ―熟達に向けたあなたの旅― 第 2 版 2021/03 このころから年内に引っ越しを考えはじめました。\n部屋に不満はありませんでしたが、ぼんやりと中央線沿い(=東京の西側)がかっこいいというイメージをもっていたので一人でちょくちょく出向いていました。\n主に、杉並区エリア(中野/高円寺/阿佐ヶ谷/荻窪)を中心にまわっていました。\n特に、荻窪にある杉並アニメーションミュージアムは、展示も楽しく見れますが、ミュージアムが入っている杉並会館の雰囲気が抜群にいいのでおすすめです。\n2021/04 転職しました。社会人４年目にして３社目になります。\n前職と同じくサーバーサイドのポジションです。\n前職では、コロナ以降フルリモートでしたが、転職後は週３出社になりました。\n出社になってからは、ランチをメンバーと取るようになり、コミュニケーションが増えたのがメリットに感じました。\n仕事に関して前職では主に、Java/Go/Node.js での開発を２年ほどしていましたが、転職直後は Ruby on Rails での開発がメインになりました。\nはじめての Ruby と Rails ということもあり、メンバーにはだいぶお世話になりながらも、プライベートではおすすめの参考書をかたっぱしから読む生活をしていました。\n読んでた本 プロを目指す人のための Ruby 入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plus シリーズ)\nパーフェクト Ruby on Rails 【増補改訂版】 (Perfect series)\nリーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)\n2021/05 緊急事態宣言の期間に入り、ほぼフルリモートになりました。\nこの頃のコミットを見てみると、主に Rails プロジェクトでのバグフィックスや、小さな機能追加をしていました。","tags":["Basic"],"title":"2021年の振り返り"},{"categories":["Development","poem"],"contents":"はじめに エンジニアとしてコードを書くようになって、もうすぐ２年というタイミングに差し掛かりました\n心境の変化としては、がむしゃらに毎日のタスクを通して「動く」コードを書くことから、メンテナンスしやすいコードを意識することが多くなりました\n「達人プログラマー」は、プログラマとして次のステップを踏み出そうというときにベストな一冊となっています\n達人の哲学 ソフトウェアのエントロピーの話は心当たりがありすぎた\nエントロピー とは、物理学の用語で「ある系における無秩序の度合い」のことで、 時間が経つたびにエントロピーは増大していく\nソフトウェアも同様に、時間が経つたびに無秩序になっていく\nこれを 割れ窓理論 というメカニズムで説明していたのもわかりやすかった\n窓が１枚割れているのを長期間放置しておくと、それをメンテナンスする気力もなくなるマインドが 植え付けられて、最終的には建物全体が破壊されていく\nソフトウェアではこれを、悪い設計、誤った意思決定、質の悪いコードに見立てることができて、 放置しておくと潜在的なバグを生み出すことになりかねない\nこういった「割れた窓」を発見したと同時に速やかに修復するべきだ、そして時間がなくてもコメントを 残すといった何らかのアクションをしてくださいと言った主張だった\n茹でガエルの話は、ある程度精神的に余裕がないと気づくことが難しいと感じた\nあっつあつの熱湯にカエルを放り込むとびっくりして飛び出してくるが、 常温の水にカエルを入れて段々と温度をあげていくと、カエルは気づかないまま茹で上がると言った話\n要するに、いつもメタ認知を意識して行動しようということ\nこれは仕事に限らずしていきたい\n達人のアプローチ 章前半のDRY 原則については膝を叩いて同意できるといった実感があった\nまた、曳光弾の考え方については目からウロコだった\n複雑なシステムを構築していくときに、各機能を一つずつ作り込んでいくのではなく、各機能を最低限使えるようにするシンプルな箇所を探していくといった手法\nシンプルな箇所に最初に取り組んでその他は後回しにする（未実装）というのは初心者視点では至らないと感じた\n章後半のプロトタイプ、見積もりの話は現実でも問われることがあるものの、 実際に見積もりが大きく外れるような難しい設計をした経験がないということもあって実感が持てなかった\n「言語の制約はそれを使う人の世界を制限する」 - ヴィトゲンシュタイン\n毎回トピックの初めに、名言があってモチベーションが上がる\nプログラミング言語に限らず、日常使っている日本語にも問題に対する考え方や コミュニケーションに対する考え方に影響を及ぼしているという構造主義的な話もあって興味深い\n基本的なツール 「悩んでいる君、そしてその悩みの原因は他の誰でもない、君自身によるものだ」 ということを知るのはつらいものだ\n- ソフォクレス\nデバッグの最初の心構え → 「パニクるな」\n妄想の達人 契約プログラミング(DbC) は素晴らしい\n仕様を記述(契約)しておくことで、プログラマにバグになりかねないようなことをさせないプログラミングをする\nトラッシュ（メチャクチャ）にするのではなく、クラッシュ（停止）させる\nGo のif err != nilで毎回エラーチェックしてるのはこれに則っているのかなと思った。\n確かにcatchで新しいエラーがくるたびに分類するのは怠い気もするかな、、\n柳に雪折れなし 列車の衝突事故を例にして依存をわかりやすく説明している\n１つのメソッドであまりにも多くのことをやろうとすると、 連結されている全ての車両に影響が及ぶように、メソッドと属性が影響を受ける\n例)割引料金を算出するメソッドの中で、これらの操作を行う。\n顧客の注文履歴を参照する 注文履歴から特定の注文オブジェクトを取得する 注文オブジェクトの総額を返す 総額から割引した値をオブジェクトにセットする 次のような考え方がある\n照会せずに依頼する TDA(Tell, Don\u0026rsquo;t Ask)\nつまり、取得した結果でオブジェクトを更新するのではなく、 メソッドに更新や参照を依頼する\nデメテルの法則\nプログラミングはコードについての話であるが、プログラムはデータについての話である\n継承は「結合」\n継承の代わり以下のテクニックを使用する\nインターフェースとプロトコル 委譲 mixin と trait ポリモーフィズムを表現するためにインターフェースを愛用する\n設定をサービス API の背後に配置する\n並行性 時間的な結合を破壊する\n並行性を向上させるためにワークフローを分析する\n並行処理を考えるときは時間のかかる手順を見つけることが大事\n並行処理はソフトウェアのメカニズムであり、並列処理はハードウェアの関心事です　← 大事!!\n共有状態は間違った状態　←泣\nセマフォー とは、ある時点で誰か一人しか占有できない「なんらかのもの」\n相互排他形式を説明するためのキーワード\nアクターとプロセス\nアクター とは局所的かつ固有の状態を保持した、独立した仮想プロセッサ\n各アクターはメールボックスを備えている\nメールボックスにメッセージが届くと、アクターが待機中の場合はメッセージ処理を始める\n処理が完了すると、メールボックス内の別のメッセージを処理する\nメールボックスが空だと、アクターは待機状態に戻る\nメッセージを処理するときに、アクターは他アクターを生成したり、アクター同士でメッセージを送ったりする\n次のメッセージを処理する時に遷移する新たな状態をつくることもできる\nプロセス とは汎用プロセッサのことであり、並行処理を簡単にするために OS によって実装される\nプロセスはアクターのように振る舞う制約が課されている\n共有状態を持たないアクターを並行処理で使用する\nアクターモデルでは明示的な並行処理が必要ない → 状態を保持しないため\nコーディング段階 偶発的プログラミングを行わないこと\n新人に対して、コードの詳細をできるか\n→ できない場合は偶発的プログラミングに頼ってる可能性あり\n仮定をドキュメント化する。\n他メンバーとのコミュニケーションを効率化したり、心の中にある仮定を明確にする\n→ 契約による設計(DbC)が参考になる\n過去のしがらみにとらわれてはいけない。 既存のコードによって未来のコードが影響されないようにする\n自分の行った作業が次に行う作業の制約になってはいけない ←大事!!\nアルゴリズムのオーダーを見積もること\nソフトウェアは「建築」ではなく「ガーデニング」に近い ←大事!!\nリファクタリングはごくたまにしか実行しない特別かつ高尚な儀式的アクティビティ ではない\n雑草抜きや落ち葉をかき集めるようなリスクの低い、ちょっとした作業を 日々実施するアクティビティである。\nテストとはバグを見つけることではない\nテストの利点は、テストについて考え、テストを記述しているときにあり、 テストを実行しているときではない\n→ テストを契約と見做せば重要度とモチベーションの変化になるのではないか\n象を一頭食べるにはどうすれば良いか\n→ 一口ずつ食べる ←大事!!\n明確な目的地を心に描けてなかった場合、どのような方法論であっても 堂々巡りになってしまう可能性がある。 ←泣\nプロジェクトを始める前に ひとりぼっちでコーディングに取り組んではいけない\n達人のプロジェクト 猫の群れを飼い慣らすことに匹敵するほど、優秀なプログラマーをまとめるのは難しい\n50 人はチームとは言わずに「群れ」といった方がしっくりくる\n事を成し遂げるにはまずスケジュールする\nカーゴカルト的な手法は、開発においてもテストやツールにおいても危険\nユーザーが必要としたタイミングで調達すること\n早めにテスト、何度もテスト、自動でテスト\nまとめ このタイミングで１周できたのは幸運でした。\n折に触れてて再読したいと思います。\n備考 表紙イラスト：Loose Drawing\n","date":"March 5, 2021","hero":"/posts/category/development/2021/03/pragmatic-programmer/hero.png","permalink":"https://uh-zz.github.io/posts/category/development/2021/03/pragmatic-programmer/","summary":"はじめに エンジニアとしてコードを書くようになって、もうすぐ２年というタイミングに差し掛かりました\n心境の変化としては、がむしゃらに毎日のタスクを通して「動く」コードを書くことから、メンテナンスしやすいコードを意識することが多くなりました\n「達人プログラマー」は、プログラマとして次のステップを踏み出そうというときにベストな一冊となっています\n達人の哲学 ソフトウェアのエントロピーの話は心当たりがありすぎた\nエントロピー とは、物理学の用語で「ある系における無秩序の度合い」のことで、 時間が経つたびにエントロピーは増大していく\nソフトウェアも同様に、時間が経つたびに無秩序になっていく\nこれを 割れ窓理論 というメカニズムで説明していたのもわかりやすかった\n窓が１枚割れているのを長期間放置しておくと、それをメンテナンスする気力もなくなるマインドが 植え付けられて、最終的には建物全体が破壊されていく\nソフトウェアではこれを、悪い設計、誤った意思決定、質の悪いコードに見立てることができて、 放置しておくと潜在的なバグを生み出すことになりかねない\nこういった「割れた窓」を発見したと同時に速やかに修復するべきだ、そして時間がなくてもコメントを 残すといった何らかのアクションをしてくださいと言った主張だった\n茹でガエルの話は、ある程度精神的に余裕がないと気づくことが難しいと感じた\nあっつあつの熱湯にカエルを放り込むとびっくりして飛び出してくるが、 常温の水にカエルを入れて段々と温度をあげていくと、カエルは気づかないまま茹で上がると言った話\n要するに、いつもメタ認知を意識して行動しようということ\nこれは仕事に限らずしていきたい\n達人のアプローチ 章前半のDRY 原則については膝を叩いて同意できるといった実感があった\nまた、曳光弾の考え方については目からウロコだった\n複雑なシステムを構築していくときに、各機能を一つずつ作り込んでいくのではなく、各機能を最低限使えるようにするシンプルな箇所を探していくといった手法\nシンプルな箇所に最初に取り組んでその他は後回しにする（未実装）というのは初心者視点では至らないと感じた\n章後半のプロトタイプ、見積もりの話は現実でも問われることがあるものの、 実際に見積もりが大きく外れるような難しい設計をした経験がないということもあって実感が持てなかった\n「言語の制約はそれを使う人の世界を制限する」 - ヴィトゲンシュタイン\n毎回トピックの初めに、名言があってモチベーションが上がる\nプログラミング言語に限らず、日常使っている日本語にも問題に対する考え方や コミュニケーションに対する考え方に影響を及ぼしているという構造主義的な話もあって興味深い\n基本的なツール 「悩んでいる君、そしてその悩みの原因は他の誰でもない、君自身によるものだ」 ということを知るのはつらいものだ\n- ソフォクレス\nデバッグの最初の心構え → 「パニクるな」\n妄想の達人 契約プログラミング(DbC) は素晴らしい\n仕様を記述(契約)しておくことで、プログラマにバグになりかねないようなことをさせないプログラミングをする\nトラッシュ（メチャクチャ）にするのではなく、クラッシュ（停止）させる\nGo のif err != nilで毎回エラーチェックしてるのはこれに則っているのかなと思った。\n確かにcatchで新しいエラーがくるたびに分類するのは怠い気もするかな、、\n柳に雪折れなし 列車の衝突事故を例にして依存をわかりやすく説明している\n１つのメソッドであまりにも多くのことをやろうとすると、 連結されている全ての車両に影響が及ぶように、メソッドと属性が影響を受ける\n例)割引料金を算出するメソッドの中で、これらの操作を行う。\n顧客の注文履歴を参照する 注文履歴から特定の注文オブジェクトを取得する 注文オブジェクトの総額を返す 総額から割引した値をオブジェクトにセットする 次のような考え方がある\n照会せずに依頼する TDA(Tell, Don\u0026rsquo;t Ask)","tags":["Development","poem"],"title":"達人プログラマーとは"},{"categories":["security","oauth"],"contents":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\nOAuth とは ひとまず、一番分かりやすい OAuth の説明で大体の感覚がつかめますのでオススメです。\nこちらでもざっくり説明させてもらうと、OAuth は複数のアプリを連携させるための仕組みです。\n例えば、ブログの記事を更新した瞬間に、ブログから更新情報をツイートしたかったりする場合に使われます。\nただ、そのままツイートできるわけではなくて、ブログアプリがツイートする許可(認可)をしてあげる必要があります。\nそして許可されたアプリは許可証(アクセストークン)を持っていることで、Twitter を使ってツイートできるという仕組みです。\nメリット OAuth を使うことで、上の例であげたブログアプリは、Twitter のユーザ名とパスワードを知らなくてもツイートできるという点です。\n巷のアプリはこれを使うことで、Google アカウントや Twitter など SNS アカウントを持っているだけでユーザ登録できちゃいます。最初の煩わしい登録の手間が省けて良いです。\nOAuth1.0 OAuth の初期バージョンです。他に 1.0a という名前のバージョンもありますが、Twitter では 1.0a を使うことができるみたいです。 (後述の 2.0 も同様に使用可)\n特徴としては、認証と署名を用いて実現される仕様でありますが、実装が複雑で使用する言語が限られてしまうというデメリット?があるみたいです。(堅牢ではあると思いますが)\nまた、1.0 は Web アプリのみ対応しているので、デスクトップ/モバイルアプリは蚊帳の外とこれまた制限されるみたいです。\n(Twitter は Web アプリ以外でも使える xAuth という OAuth 拡張を開発したりしてたみたいです)\nさらに悲しいことに、1.0 の仕様は次の 2.0 の策定を持って廃止されたみたいです。\nOAuth2.0 後継です。複雑と言われていた署名(とトークン交換)をバッサリ省いています。\nこれによって実装しやすいものになりましたがセキュリティが気になるところです。\nOAuth 1.0 のほうが OAuth 2.0 より安全なの？でも言われている通り、2.0 はクライアントアプリケーションの幅が広がった分、秘密鍵の隠蔽が難しくなるみたいです。。\n隠蔽できるかの違いはありますが、セキュリティレベルは両者それほど変わらないみたいです。\n(2.0 は経路を TLS 化していることで、1.0 よりも提示するパラメータが少なくなっているという事実はあるそうな)\nまとめ 実装のことを考えてこれからも 2.0 を使っていきましょうという締めです。\n(Twitter 以外のほとんどのアプリが 2.0 を採用していることもあり、、)\nこの辺の仕様がやはり読んだだけではイメージしづらいところがありますので、簡単に実装してみて実務で使えるようになりたいですという感想です。\n備考 表紙イラスト：Loose Drawing\n","date":"January 5, 2021","hero":"/posts/category/security/2021/01/oauth/hero.png","permalink":"https://uh-zz.github.io/posts/category/security/2021/01/oauth/","summary":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\nOAuth とは ひとまず、一番分かりやすい OAuth の説明で大体の感覚がつかめますのでオススメです。\nこちらでもざっくり説明させてもらうと、OAuth は複数のアプリを連携させるための仕組みです。\n例えば、ブログの記事を更新した瞬間に、ブログから更新情報をツイートしたかったりする場合に使われます。\nただ、そのままツイートできるわけではなくて、ブログアプリがツイートする許可(認可)をしてあげる必要があります。\nそして許可されたアプリは許可証(アクセストークン)を持っていることで、Twitter を使ってツイートできるという仕組みです。\nメリット OAuth を使うことで、上の例であげたブログアプリは、Twitter のユーザ名とパスワードを知らなくてもツイートできるという点です。\n巷のアプリはこれを使うことで、Google アカウントや Twitter など SNS アカウントを持っているだけでユーザ登録できちゃいます。最初の煩わしい登録の手間が省けて良いです。\nOAuth1.0 OAuth の初期バージョンです。他に 1.0a という名前のバージョンもありますが、Twitter では 1.0a を使うことができるみたいです。 (後述の 2.0 も同様に使用可)\n特徴としては、認証と署名を用いて実現される仕様でありますが、実装が複雑で使用する言語が限られてしまうというデメリット?があるみたいです。(堅牢ではあると思いますが)\nまた、1.0 は Web アプリのみ対応しているので、デスクトップ/モバイルアプリは蚊帳の外とこれまた制限されるみたいです。\n(Twitter は Web アプリ以外でも使える xAuth という OAuth 拡張を開発したりしてたみたいです)\nさらに悲しいことに、1.0 の仕様は次の 2.0 の策定を持って廃止されたみたいです。\nOAuth2.0 後継です。複雑と言われていた署名(とトークン交換)をバッサリ省いています。\nこれによって実装しやすいものになりましたがセキュリティが気になるところです。\nOAuth 1.0 のほうが OAuth 2.0 より安全なの？でも言われている通り、2.0 はクライアントアプリケーションの幅が広がった分、秘密鍵の隠蔽が難しくなるみたいです。。\n隠蔽できるかの違いはありますが、セキュリティレベルは両者それほど変わらないみたいです。\n(2.0 は経路を TLS 化していることで、1.0 よりも提示するパラメータが少なくなっているという事実はあるそうな)\nまとめ 実装のことを考えてこれからも 2.0 を使っていきましょうという締めです。","tags":["security","oauth"],"title":"OAuth について"},{"categories":["system-design","ddd"],"contents":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\n※現場で役立つシステム設計の原則を元に記事を作成しています。\n設計パターン 値オブジェクト(Value Object) Java で変数を扱うとき、int や String などで型定義しがちな初心者丸出しの実装をしていた私ですが、値オブジェクトを知ったとき眼からウロコでした。\n値オブジェクトとは、汎用的な型(int や String)で型を定義するのではなく、専用の型(クラスやインターフェース)を定義します。\n範囲の広い汎用的な型を使うのではなく、業務に合わせた値で制限するというものです。\n値オブジェクトクラスはこんなかんじ\nclass Quantity { static final int MIN = 1; static final int MAX = 100; int value; Quantity(int value) { if (value \u0026lt; MIN) { throw new IllegalArgumentException(\u0026#34;不正\u0026#34; + MIN + \u0026#34;未満\u0026#34;); } if (value \u0026gt; MAX) { throw new IllegalArgumentException(\u0026#34;不正\u0026#34; + MAX + \u0026#34;超\u0026#34;); } this.value = value; } } そして参照はこんなかんじ\nQuantity quantity = new Quantity(50); こうすることで Quantity 型は値の制限(0~100)付きの実装ができるので安全です。\n制限を超えた値は不正と見なせるので業務ルールから外れることもありません。\n値オブジェクトは不変！！ 変数の上書きは禁止しておきましょう。\nもし上書きしそうであれば、新しいオブジェクトを作成しましょう。\nオブジェクトは常に１つの値を持つように実装します。\nこのように不変なオブジェクトを設計する方法を完全コンストラクタと言います。\n今回の Quantity 型のような値オブジェクトのようにクラス名も業務で実際に使用している用語にするべきです。\nそうすることで業務の理解とプログラムの設計を関連付ける手助けになり、変更のしやすいコードを維持することができます。\nコレクションオブジェクト 値オブジェクトは単一の型(int や String)のデータとそれに関連するロジックを１つのクラスにまとめるというコンセプトです。\nコレクションオブジェクトも同様に、List/Set/Map といったコレクション型のデータとロジックを１つのクラスに閉じ込めようといったものです。\n※オブジェクト指向ではデータとロジックを閉じ込めるというところがミソといっても過言ではないでしょう。\nクラスはこんなかんじ\nclass Customers { List\u0026lt;Customer\u0026gt; cutomers; void add(Customer customer) {...} void removeIfExist(Customer customer) {...} int count() {...} Customers importantCustomers() {...} } Customer に関するロジックを寄せ集めたような感じです。\nこうすることで変更箇所のこのクラスだけに閉じ込めることができます。(楽ちん)\n使う側は Customer に関するメソッドを呼ぶだけでよくなるので、使う側のソースもスッキリするという みんなハッピーになれるというわけです。\n参照をそのまま渡すべからず 値オブジェクト同様、「不変」であることが求められます。\nもしも getList()が欲しくなる禁断症状があった時に有効な方法は、同じ型のコレクションオブジェクトを返すことです。\nclass Customers { List\u0026lt;Customer\u0026gt; customers; Customers add(Customer customer) { List\u0026lt;Customer\u0026gt; result = new ArrayList\u0026lt;\u0026gt;(customers); return new Customers(result.add(customer)); } } こうすることで、既存の customers を渡すことなく新しいオブジェクトを生成して返します。または、変更不可にして返します。\nclass Customers { List\u0026lt;Customer\u0026gt; customers; List\u0026lt;Customer\u0026gt; asList() { return Collections.unmodifiableList(customers); } } 意地で不変なオブジェクトを返すようにします。そうすることで変更による副作用の起きにくいプログラムを作ることに繋がります。\nまとめ 値オブジェクトもコレクションオブジェクトもどちらも「不変であれ」ということです。同じインスタンスを使い回そうとすればするほど、変更によるバグが出る可能性が高くなります。 データとロジックは１つのクラスに閉じこめましょう。ロジックをまとめておくことで、使う側はメソッドを呼ぶだけで済むし、変更する場合はそのクラスだけを対象にすればよいわけです。人類の英知ですね。 備考 現場で役立つシステム設計の原則\n表紙イラスト：Loose Drawing\n","date":"December 5, 2020","hero":"/posts/category/system-design/2020/12/principles-of-the-systems-architecture/part1/hero.png","permalink":"https://uh-zz.github.io/posts/category/system-design/2020/12/principles-of-the-systems-architecture/part1/","summary":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\n※現場で役立つシステム設計の原則を元に記事を作成しています。\n設計パターン 値オブジェクト(Value Object) Java で変数を扱うとき、int や String などで型定義しがちな初心者丸出しの実装をしていた私ですが、値オブジェクトを知ったとき眼からウロコでした。\n値オブジェクトとは、汎用的な型(int や String)で型を定義するのではなく、専用の型(クラスやインターフェース)を定義します。\n範囲の広い汎用的な型を使うのではなく、業務に合わせた値で制限するというものです。\n値オブジェクトクラスはこんなかんじ\nclass Quantity { static final int MIN = 1; static final int MAX = 100; int value; Quantity(int value) { if (value \u0026lt; MIN) { throw new IllegalArgumentException(\u0026#34;不正\u0026#34; + MIN + \u0026#34;未満\u0026#34;); } if (value \u0026gt; MAX) { throw new IllegalArgumentException(\u0026#34;不正\u0026#34; + MAX + \u0026#34;超\u0026#34;); } this.value = value; } } そして参照はこんなかんじ\nQuantity quantity = new Quantity(50); こうすることで Quantity 型は値の制限(0~100)付きの実装ができるので安全です。","tags":["system-design","ddd"],"title":"システム設計-part1-"},{"categories":["system-design","ddd"],"contents":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\n※現場で役立つシステム設計の原則を元に記事を作成しています。\n設計パターン 早期リターン 複雑になりがちな場合分けのロジックの見通しをよくしようというものです。\nありがちなif-elseをつなげた(例 1)\nYen fee() { Yen result; if (isChild()) { result = chidFee(); } else if (isSenior()) { result = seniorFee(); } else { result = adultFee(); } return result; } さっきのコードからローカル変数を抜いて結果をすぐにreturnするようにした(例 2)\nYen fee() { if (isChild()) { return chidFee(); } else if (isSenior()) { return seniorFee(); } else { return adultFee(); } } このように、値が決まるとすぐにreturnするやり方を早期リターンと言います。\nガード節 上記の例 2 からelseを抜いた(例 3)\nYen fee() { if (isChild()) return chidFee(); if (isSenior()) return seniorFee(); return adultFee(); } elseを抜いた早期リターンをガード節と言います。非常にコンパクトですね。\n単文の並びに変えることで、独立性が高くなります。また、単文同士が結合していない（疎結合)ので追加が容易です。\n多態 それぞれのクラスを包括するようなクラス(インターフェース)を作ることで、使う側のクラス、メソッドはインターフェースさえ実装していれば、それがどのクラスでも気にする必要がありません。\nインターフェースを用意する(例 4)\ninterface Fee { Yen yen(); String label(); } // 大人クラス class AdultFee implements Fee { Yen yen() { return new Yen(1000); } String label() { return \u0026#34;大人\u0026#34;; } } // 子クラス class ChildFee implements Fee { Yen yen() { return new Yen(50) } String label() { return \u0026#34;子供\u0026#34;; } } 使う側(例 5)\nclass Reservation { List\u0026lt;Fee\u0026gt; fees; // 大人と子供のリスト Reservation() { fees = new ArrayList\u0026lt;Fee\u0026gt;(); } // Feeはインターフェースなので、大人と子供の両方に使える void addFee(Fee fee) { fees.add(fee); } // 大人と子供の合計料金 Yen feeTotal() { Yen total = new Yen(); for (Fee fee : fees) { total.add(fee.yen()); } reuturn total; } } インターフェースを使うことで、大人と子供の料金クラスをまとめて処理できました。\nif 文を使わずに済むと見通しがよいですね。\nこのようにインターフェースを使用して、異なるクラスのオブジェクトを同じ型として扱う仕組みを多態と言います。\n多態にすることでFeeのインターフェースを実装した別のクラス(シニアクラスなど)を追加してもReservationクラスを変更することはありません。改修箇所が少なくなるのは大きなメリットです。\n列挙型 多態は同じインターフェースを実装したクラスの一覧が分かりにくくなる場合がありますclass宣言のimplementsを見れば一目瞭然ですが、一つ一つ見ていくのに時間がかかります。\n列挙型を使うことで区分(インターフェースのグループ)の一覧を作成することができます。\n列挙型を使って料金区分ごとのロジックを表現(例 6)\nenum FeeType { adult(new AdultFee()); child(new ChidFee()); senior(new SeniorFee()); private Fee fee; private FeeTypt(Fee fee) { this.fee = fee; } Yen yen() { return fee.yen(); } String label() { return fee.label(); } } 使う側(例 7)\nYen feeFor(Stirng feeTypeName) { FeeType feeType = FeeType.valueOf(feeTypeName); return feeType.yen(); } enumクラスのvalueOf()メソッドはMapのget()メソッドと同様に、if 文を使うことなく料金区分ごとのオブジェクトを取得できます。\nこのような振る舞いを持った列挙型(enum)を区分オブジェクトと言います。\nまとめ 前回同様、コードをスッキリさせる手法を見てきました。インターフェースを使うことで抽象的なメソッドを作ったり、列挙型を使って if 文をなるべく減らせることはコードの保守性、拡張性を高めてくれますね。\n備考 現場で役立つシステム設計の原則\n表紙イラスト：Loose Drawing\n","date":"December 5, 2020","hero":"/posts/category/system-design/2020/12/principles-of-the-systems-architecture/part2/hero.png","permalink":"https://uh-zz.github.io/posts/category/system-design/2020/12/principles-of-the-systems-architecture/part2/","summary":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\n※現場で役立つシステム設計の原則を元に記事を作成しています。\n設計パターン 早期リターン 複雑になりがちな場合分けのロジックの見通しをよくしようというものです。\nありがちなif-elseをつなげた(例 1)\nYen fee() { Yen result; if (isChild()) { result = chidFee(); } else if (isSenior()) { result = seniorFee(); } else { result = adultFee(); } return result; } さっきのコードからローカル変数を抜いて結果をすぐにreturnするようにした(例 2)\nYen fee() { if (isChild()) { return chidFee(); } else if (isSenior()) { return seniorFee(); } else { return adultFee(); } } このように、値が決まるとすぐにreturnするやり方を早期リターンと言います。\nガード節 上記の例 2 からelseを抜いた(例 3)\nYen fee() { if (isChild()) return chidFee(); if (isSenior()) return seniorFee(); return adultFee(); } elseを抜いた早期リターンをガード節と言います。非常にコンパクトですね。","tags":["system-design","ddd"],"title":"システム設計-part2-"},{"categories":["system-design","ddd"],"contents":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\n※現場で役立つシステム設計の原則を元に記事を作成しています。\n業務ロジック メソッドをロジックの置き場所にする 現場で役立つシステム設計の原則では、\u0026ldquo;従来\u0026quot;という表現をされていますが、手続き型と呼ばれている設計ではデータクラスと機能クラスに分けて表現します。\nその名の通りデータクラスはデータを格納して、機能クラスはデータクラスのデータを判断、加工、計算するといった使い方です。\nこの手続き型の問題は、拡張するときの変更箇所の特定に時間がかかるということです。\nなぜかというと、データクラスが参照できるクラスであれば、アーキテクチャのどのレイヤーにでもロジックが書けてしまうからです。\n便利のようには見えますが、先に言った変更箇所の特定に時間がかかるこの方法は最善ではありません。\n解決としては、Java 本来のクラスの使い方を踏襲することです。\nデータとロジックを 1 つのクラスに閉じてしまおうという考え方です。\nclass PersonName { private String firstName; private String lastName; String fullName() { return String.format(\u0026#34;%s %s\u0026#34;, firstName, lastName); } } データであるfirstNameとlastName、そしてロジック(メソッド)のfullName()が同じクラス内にあります。\nこうするとクラス内でデータを扱うことができて変更もこのクラス内で閉じることができます。\nまた、メソッドはクラス内のインスタンス変数(firstNameやlastName)を使って何らかの処理を行う用途で作成します。\nクラスが肥大化したら小さく分ける これもやってしまいがちですが、改修を繰り返していくうちに、クラスが大きくなっていきます。\n大きくなったクラスは手続き型同様に変更箇所の特定に時間がかかります。\nそれを防ぐために、大きくなってしまったクラスを次のルールで細分化します。\nインスタンス変数とメソッドを対応付ける メソッドが全てのインスタンス変数を使うようになる 細分化したクラスはそれぞれ独立性が高くなるので、別のクラスで使う時にも再利用ができるようになります。\nこうした関連の強いデータとロジックをまとめたクラスを凝集度が高いと言います。\n凝集度が高いクラスは、変更箇所もそのクラスに閉じることになるので、疎結合になり他への影響が少なくて済みます。\nまとめ 時すでに遅しと言いますか、現場での反省点をつらつら振り返ってベストプラクティスを学んでいるという感じです。\n次回に活かそうというモチベーションは上がるのでいい復習方法だと感じます。\n備考 現場で役立つシステム設計の原則\n表紙イラスト：Loose Drawing\n","date":"December 5, 2020","hero":"/posts/category/system-design/2020/12/principles-of-the-systems-architecture/part3/hero.png","permalink":"https://uh-zz.github.io/posts/category/system-design/2020/12/principles-of-the-systems-architecture/part3/","summary":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\n※現場で役立つシステム設計の原則を元に記事を作成しています。\n業務ロジック メソッドをロジックの置き場所にする 現場で役立つシステム設計の原則では、\u0026ldquo;従来\u0026quot;という表現をされていますが、手続き型と呼ばれている設計ではデータクラスと機能クラスに分けて表現します。\nその名の通りデータクラスはデータを格納して、機能クラスはデータクラスのデータを判断、加工、計算するといった使い方です。\nこの手続き型の問題は、拡張するときの変更箇所の特定に時間がかかるということです。\nなぜかというと、データクラスが参照できるクラスであれば、アーキテクチャのどのレイヤーにでもロジックが書けてしまうからです。\n便利のようには見えますが、先に言った変更箇所の特定に時間がかかるこの方法は最善ではありません。\n解決としては、Java 本来のクラスの使い方を踏襲することです。\nデータとロジックを 1 つのクラスに閉じてしまおうという考え方です。\nclass PersonName { private String firstName; private String lastName; String fullName() { return String.format(\u0026#34;%s %s\u0026#34;, firstName, lastName); } } データであるfirstNameとlastName、そしてロジック(メソッド)のfullName()が同じクラス内にあります。\nこうするとクラス内でデータを扱うことができて変更もこのクラス内で閉じることができます。\nまた、メソッドはクラス内のインスタンス変数(firstNameやlastName)を使って何らかの処理を行う用途で作成します。\nクラスが肥大化したら小さく分ける これもやってしまいがちですが、改修を繰り返していくうちに、クラスが大きくなっていきます。\n大きくなったクラスは手続き型同様に変更箇所の特定に時間がかかります。\nそれを防ぐために、大きくなってしまったクラスを次のルールで細分化します。\nインスタンス変数とメソッドを対応付ける メソッドが全てのインスタンス変数を使うようになる 細分化したクラスはそれぞれ独立性が高くなるので、別のクラスで使う時にも再利用ができるようになります。\nこうした関連の強いデータとロジックをまとめたクラスを凝集度が高いと言います。\n凝集度が高いクラスは、変更箇所もそのクラスに閉じることになるので、疎結合になり他への影響が少なくて済みます。\nまとめ 時すでに遅しと言いますか、現場での反省点をつらつら振り返ってベストプラクティスを学んでいるという感じです。\n次回に活かそうというモチベーションは上がるのでいい復習方法だと感じます。\n備考 現場で役立つシステム設計の原則\n表紙イラスト：Loose Drawing","tags":["system-design","ddd"],"title":"システム設計-part3-"},{"categories":["computer-science"],"contents":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\nスレッド プロセスが最低１つは持っている実行単位のことです。\nこんな言い方をするのは、プロセスが複数のスレッドを管理できるからです。\n実行単位という視点でプロセスとの違いは、「アドレス空間」を共有できるという点です。\n尾を引くようにプロセス管理の話に繋がりますが、プロセスにはそれぞれ１つのアドレス空間が割り当てられます。\nそして別のプロセスからアドレス空間へのアクセスは原則できません。(これを可能にするために共有メモリという方法を使います)\nそれに対して、スレッドは１つのプロセスの実行単位を分けたものですから、同じアドレス空間を共有できるというわけです。\nそういうわけで、スレッドとプロセスをそれぞれ複数起動する場合は、スレッドの方がアドレス空間を１つで済ませることができるため省コストになります。\nでは、複数のスレッドを起動してやることは?というと並行処理です。\n並行処理 これもすでに出てきている話ではあります。プロセス管理の記事で出した複数アプリを同時に起動させるという部分です。\n「同時に」というのは私たちユーザがそう解釈しているだけで、アプリはカーネルが割り当てた非常に短い処理時間ごとに切り替えているのでしたよね。これが並行処理です。\nスレッドでも同じように短い処理時間ごとに切り替えて「同時に」処理させることができます。\n並列処理との違い 私自身、再三調べては納得 → 忘れるを繰り返していましたが、プロセス管理(3 度目)をまとめることでやっと理解できたと思います。\n並行処理では処理時間ごとに切り替えると言いましたが、並列処理では CPU １つは言わず２つで処理してしまえばいいじゃないという考え方です。\n図で見ると非常にわかりやすいのですが、並行処理だとパン食べてチーズ食べてハム食べてレタス食べて、、を繰り返して食べ切る作戦なのに対して、並列処理はミックスサンドとして食べ切るようなイメージです。\nそんなの絶対ミックスサンドとして処理したら無限じゃんと思われますが、並列処理にも上限があるようです。\nアムダールの法則といって複数のプロセッサ(CPU のことですね)を使って並列化による高速化を行う場合、そのプログラムの中で逐次的に実行される処理部分(並列)の時間によって、高速化が制限されるというものです。\n出典：wikipedia「アムダールの法則」より引用\nまあ、上限があるといっても高速するのに変わりはないわけです。\n今回はその中でも比較的面白い実装を見つけたのでそれを紹介します。\nワーカープール スレッドプールとも呼ばれるものです。並行処理でたくさんのスレッドを起動して、、というのももちろん可能ですが、それには代償が伴います。\nワーカープールはそのようにいくつもスレッドを起動させるのではなく、すでに起動したスレッドを使い回そうの精神で実装される並行処理です。\n以下のような実装です。\nこちらを参考にさせていただきました。\n(ほぼコメントつけただけですが)\npackage main import ( \u0026#34;fmt\u0026#34; \u0026#34;time\u0026#34; ) // 使い回し用のワーカー func worker(id int, jobs \u0026lt;-chan int, results chan\u0026lt;- int) { for j := range jobs { fmt.Println(\u0026#34;worker\u0026#34;, id, \u0026#34;started job\u0026#34;, j) time.Sleep(time.Second) // 1秒待ち(重い処理を想定) fmt.Println(\u0026#34;worker\u0026#34;, id, \u0026#34;finished job\u0026#34;, j) results \u0026lt;- j * 2 } } func main() { // タスクの数 const numJobs = 5 // こなさなければいけないタスク jobs := make(chan int, numJobs) // タスクの成果物 results := make(chan int, numJobs) for w := 1; w \u0026lt;= 3; w++ { // 使い回し用のワーカーだけ生成しておく(この状態ではまだタスクをもらってないのでブロック) go worker(w, jobs, results) } // タスク数だけjobsに渡す for j := 1; j \u0026lt;= numJobs; j++ { // チャネルへの書き込みを契機にワーカー起動 jobs \u0026lt;- j } // タスク数だけ格納されたらチャネルを閉じる close(jobs) for a := 1; a \u0026lt;= numJobs; a++ { \u0026lt;-results } } // 結果 worker 3 started job 1 worker 1 started job 2 worker 2 started job 3 worker 3 finished job 1 worker 3 started job 4 worker 1 finished job 2 worker 1 started job 5 worker 2 finished job 3 worker 1 finished job 5 worker 3 finished job 4 実行するとわかりますが、順番がごっちゃになって処理されているのがわかります。\nこれにより、ワーカーというスレッドごとに並行処理されているという動作を確認することができました。\n余談 他にも面白そうな実装をいくつか見つけましたが、ただ羅列するだけでは萎えると思ったので気が向いたら別で紹介したいと思います。\nなにげに goroutine を使用していますが、goroutine の中身の処理内容(work stealing アルゴリズム)も面白いので、後々まとめたいと思ってます。\n備考 表紙イラスト：Loose Drawing\n","date":"October 5, 2020","hero":"/posts/category/computer-science/2020/11/thread-and-concurrency/hero.png","permalink":"https://uh-zz.github.io/posts/category/computer-science/2020/11/thread-and-concurrency/","summary":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\nスレッド プロセスが最低１つは持っている実行単位のことです。\nこんな言い方をするのは、プロセスが複数のスレッドを管理できるからです。\n実行単位という視点でプロセスとの違いは、「アドレス空間」を共有できるという点です。\n尾を引くようにプロセス管理の話に繋がりますが、プロセスにはそれぞれ１つのアドレス空間が割り当てられます。\nそして別のプロセスからアドレス空間へのアクセスは原則できません。(これを可能にするために共有メモリという方法を使います)\nそれに対して、スレッドは１つのプロセスの実行単位を分けたものですから、同じアドレス空間を共有できるというわけです。\nそういうわけで、スレッドとプロセスをそれぞれ複数起動する場合は、スレッドの方がアドレス空間を１つで済ませることができるため省コストになります。\nでは、複数のスレッドを起動してやることは?というと並行処理です。\n並行処理 これもすでに出てきている話ではあります。プロセス管理の記事で出した複数アプリを同時に起動させるという部分です。\n「同時に」というのは私たちユーザがそう解釈しているだけで、アプリはカーネルが割り当てた非常に短い処理時間ごとに切り替えているのでしたよね。これが並行処理です。\nスレッドでも同じように短い処理時間ごとに切り替えて「同時に」処理させることができます。\n並列処理との違い 私自身、再三調べては納得 → 忘れるを繰り返していましたが、プロセス管理(3 度目)をまとめることでやっと理解できたと思います。\n並行処理では処理時間ごとに切り替えると言いましたが、並列処理では CPU １つは言わず２つで処理してしまえばいいじゃないという考え方です。\n図で見ると非常にわかりやすいのですが、並行処理だとパン食べてチーズ食べてハム食べてレタス食べて、、を繰り返して食べ切る作戦なのに対して、並列処理はミックスサンドとして食べ切るようなイメージです。\nそんなの絶対ミックスサンドとして処理したら無限じゃんと思われますが、並列処理にも上限があるようです。\nアムダールの法則といって複数のプロセッサ(CPU のことですね)を使って並列化による高速化を行う場合、そのプログラムの中で逐次的に実行される処理部分(並列)の時間によって、高速化が制限されるというものです。\n出典：wikipedia「アムダールの法則」より引用\nまあ、上限があるといっても高速するのに変わりはないわけです。\n今回はその中でも比較的面白い実装を見つけたのでそれを紹介します。\nワーカープール スレッドプールとも呼ばれるものです。並行処理でたくさんのスレッドを起動して、、というのももちろん可能ですが、それには代償が伴います。\nワーカープールはそのようにいくつもスレッドを起動させるのではなく、すでに起動したスレッドを使い回そうの精神で実装される並行処理です。\n以下のような実装です。\nこちらを参考にさせていただきました。\n(ほぼコメントつけただけですが)\npackage main import ( \u0026#34;fmt\u0026#34; \u0026#34;time\u0026#34; ) // 使い回し用のワーカー func worker(id int, jobs \u0026lt;-chan int, results chan\u0026lt;- int) { for j := range jobs { fmt.Println(\u0026#34;worker\u0026#34;, id, \u0026#34;started job\u0026#34;, j) time.Sleep(time.Second) // 1秒待ち(重い処理を想定) fmt.Println(\u0026#34;worker\u0026#34;, id, \u0026#34;finished job\u0026#34;, j) results \u0026lt;- j * 2 } } func main() { // タスクの数 const numJobs = 5 // こなさなければいけないタスク jobs := make(chan int, numJobs) // タスクの成果物 results := make(chan int, numJobs) for w := 1; w \u0026lt;= 3; w++ { // 使い回し用のワーカーだけ生成しておく(この状態ではまだタスクをもらってないのでブロック) go worker(w, jobs, results) } // タスク数だけjobsに渡す for j := 1; j \u0026lt;= numJobs; j++ { // チャネルへの書き込みを契機にワーカー起動 jobs \u0026lt;- j } // タスク数だけ格納されたらチャネルを閉じる close(jobs) for a := 1; a \u0026lt;= numJobs; a++ { \u0026lt;-results } } // 結果 worker 3 started job 1 worker 1 started job 2 worker 2 started job 3 worker 3 finished job 1 worker 3 started job 4 worker 1 finished job 2 worker 1 started job 5 worker 2 finished job 3 worker 1 finished job 5 worker 3 finished job 4 実行するとわかりますが、順番がごっちゃになって処理されているのがわかります。","tags":["computer-science"],"title":"スレッドと並行処理"},{"categories":["computer-science"],"contents":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\n仮想メモリ プロセス管理でもあったように、メモリはアドレス空間ごとにプロセスを管理します。\nアドレス空間は 4KB/8KB 単位のページに分割して管理されています。\nページはそれぞれ論理アドレス、物理アドレスを対応づける単位でもあります。\n論理アドレスと物理アドレスは常に紐づけられているわけではなく、そのページが必要になった時点で割り当てることも可能です。\nそのため、論理アドレスを実際の物理アドレスの容量より大きく確保することができます。\n(実際に使えるメモリの量よりも大きなメモリを想定できるということです。)\n仮装メモリとして使う仕組みには次の３つが挙げられます。\nページング 仮想メモリといえばこれ、という風に教えられるものの筆頭かと思います。\nハードディスクを物理メモリの代わりに使うといったものです。\n物理メモリが不足すると、OS のコアであるカーネルは使われていないページをハードディスクに移して論理アドレスを解放します。\nそしてプロセスがハードディスクに移されたページにアクセスしようとすると、カーネルがプロセスを停止し、ハードディスクのページを再度物理メモリに読み込み、論理アドレスを対応づけます。\nまた、プロセス全体を単位にする場合はスワッピングと呼ばれます。\nメモリマップトファイル ファイルをメモリとしてアクセスすることができるものです。\nアクセスがあった瞬間に、カーネルがファイルをメモリに読み込みます。プロセスがメモリを使い終わると、論理アドレスと物理アドレスを解放して、メモリの内容をファイルに保存します。\n共有メモリ １つの物理アドレスを、複数のプロセスの論理アドレスに対応づけるものです。 アドレス空間をまたぐと危険では？！という見方もありますが、複数プロセスで処理できるため、巨大な画像データを編集するときには都合が良いみたいです。\n※Go では共有メモリを使わずに Message Passing を使っています。\nメモリ管理 API malloc(3) メモリをヒープ領域に割り当てます。プログラム実行時に決まるサイズのメモリはヒープ領域から確保します。\nヒープは「何かを積み重ねた山」のことで、その名の通り、プログラムを実行してから決定する量だけメモリを確保しておく領域なので納得です。\nmalloc で確保したメモリはfreeで解放しなければいけません。\ncalloc(3) メモリをヒープ領域に割り当てます。malloc と異なる点は、割り当てたメモリをゼロクリアすることです。\nこちらも malloc 同様、確保したメモリはfreeで解放しなければいけません。\nrealloc(3) malloc で割り当てたメモリのサイズを拡大、縮小します。こちらも確保したメモリはfreeで解放しなければいけません。\nfree 割り当てたメモリを開放します。いったん開放したアドレスにはアクセスしてはいけません。\nメモリの開放漏れを防ぐために、malloc で確保したメモリは常に free で開放されるべきです。\nbrk(2) malloc や realloc が割り当てるためのメモリを探してくるものです。\n物理アドレスが割り当てられていないページに物理アドレスを対応づけます。\n余談 メモリはエラーでもかなりお世話になる部分なので、次回以降、実際のエラーやプログラミング言語(Go か Java)に絡めた記事を書きたいです。\n備考 ふつうの Linux プログラミング 第 2 版 Linux の仕組みから学べる gcc プログラミングの王道\n表紙イラスト：Loose Drawing\n","date":"October 5, 2020","hero":"/posts/category/computer-science/2020/10/memory-management/hero.png","permalink":"https://uh-zz.github.io/posts/category/computer-science/2020/10/memory-management/","summary":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\n仮想メモリ プロセス管理でもあったように、メモリはアドレス空間ごとにプロセスを管理します。\nアドレス空間は 4KB/8KB 単位のページに分割して管理されています。\nページはそれぞれ論理アドレス、物理アドレスを対応づける単位でもあります。\n論理アドレスと物理アドレスは常に紐づけられているわけではなく、そのページが必要になった時点で割り当てることも可能です。\nそのため、論理アドレスを実際の物理アドレスの容量より大きく確保することができます。\n(実際に使えるメモリの量よりも大きなメモリを想定できるということです。)\n仮装メモリとして使う仕組みには次の３つが挙げられます。\nページング 仮想メモリといえばこれ、という風に教えられるものの筆頭かと思います。\nハードディスクを物理メモリの代わりに使うといったものです。\n物理メモリが不足すると、OS のコアであるカーネルは使われていないページをハードディスクに移して論理アドレスを解放します。\nそしてプロセスがハードディスクに移されたページにアクセスしようとすると、カーネルがプロセスを停止し、ハードディスクのページを再度物理メモリに読み込み、論理アドレスを対応づけます。\nまた、プロセス全体を単位にする場合はスワッピングと呼ばれます。\nメモリマップトファイル ファイルをメモリとしてアクセスすることができるものです。\nアクセスがあった瞬間に、カーネルがファイルをメモリに読み込みます。プロセスがメモリを使い終わると、論理アドレスと物理アドレスを解放して、メモリの内容をファイルに保存します。\n共有メモリ １つの物理アドレスを、複数のプロセスの論理アドレスに対応づけるものです。 アドレス空間をまたぐと危険では？！という見方もありますが、複数プロセスで処理できるため、巨大な画像データを編集するときには都合が良いみたいです。\n※Go では共有メモリを使わずに Message Passing を使っています。\nメモリ管理 API malloc(3) メモリをヒープ領域に割り当てます。プログラム実行時に決まるサイズのメモリはヒープ領域から確保します。\nヒープは「何かを積み重ねた山」のことで、その名の通り、プログラムを実行してから決定する量だけメモリを確保しておく領域なので納得です。\nmalloc で確保したメモリはfreeで解放しなければいけません。\ncalloc(3) メモリをヒープ領域に割り当てます。malloc と異なる点は、割り当てたメモリをゼロクリアすることです。\nこちらも malloc 同様、確保したメモリはfreeで解放しなければいけません。\nrealloc(3) malloc で割り当てたメモリのサイズを拡大、縮小します。こちらも確保したメモリはfreeで解放しなければいけません。\nfree 割り当てたメモリを開放します。いったん開放したアドレスにはアクセスしてはいけません。\nメモリの開放漏れを防ぐために、malloc で確保したメモリは常に free で開放されるべきです。\nbrk(2) malloc や realloc が割り当てるためのメモリを探してくるものです。\n物理アドレスが割り当てられていないページに物理アドレスを対応づけます。\n余談 メモリはエラーでもかなりお世話になる部分なので、次回以降、実際のエラーやプログラミング言語(Go か Java)に絡めた記事を書きたいです。\n備考 ふつうの Linux プログラミング 第 2 版 Linux の仕組みから学べる gcc プログラミングの王道","tags":["computer-science"],"title":"メモリ管理"},{"categories":["oss"],"contents":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\nセマンティックバージョニング？ アプリに振るバージョン番号をSemVerというルールに従って付与しましょうというものです。\n確かにバージョン番号に意味を持たせることで、ユーザからもアプリのバージョン番号が上がればバグ修正なのか機能追加なのかわかりますし、プログラムからも互換性を考慮して処理を分けることができるのでよいですね。\nこれだけ覚えておけば OK バージョン番号の形式は、メジャー.マイナー.パッチです。(例：1.0.0)\nメジャー 後方互換性がない変更があった時にはこの番号を上げなければいけません(MUST) この番号を上げた際には、マイナー/パッチの番号は 0 にリセットしなければいけません(MUST) この番号が「0」の場合は初期開発用として扱います。リリースの段階でこの番号を「1」に上げます。 マイナー 後方互換性を保ちつつ、機能追加のある時にはこの番号を上げなければいけません(MUST) この番号を上げた際には、パッチの番号は 0 にリセットしなければいけません(MUST) パッチ 後方互換性を保ちつつ、バグ修正のある時にはこの番号を上げなければいけません(MUST) ※バグ修正とは間違った振る舞いを修正する内部の変更のことをいいます。\nちょっと踏み込むと プレリリースバージョンには、パッチ番号の後ろにハイフンで区切って識別子をつけることができます。 (例：1.1.0-alpha / 1.1.0-beta / 1.1.0-rc) ※ちなみに識別子のrcは「release candidate」の略でベータ版よりもさらに製品版に近い品質のバージョンにつけるそうです。（略を初めて知りました。）\nあと npm の packagge.json でもモジュールをセマンティックバージョンで管理してます。（~や^が付与されているのをよく見ると思います。） これについては上、真ん中、下で覚えるバージョニング範囲指定がわかりやすかったので共有しておきます。\n余談 たかがバージョニング、されどバージョニングといった感じでした。知ってて損はないですよね。\n備考 表紙イラスト：Loose Drawing\n","date":"August 5, 2020","hero":"/posts/category/oss/2020/08/semantic-versioning/hero.png","permalink":"https://uh-zz.github.io/posts/category/oss/2020/08/semantic-versioning/","summary":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\nセマンティックバージョニング？ アプリに振るバージョン番号をSemVerというルールに従って付与しましょうというものです。\n確かにバージョン番号に意味を持たせることで、ユーザからもアプリのバージョン番号が上がればバグ修正なのか機能追加なのかわかりますし、プログラムからも互換性を考慮して処理を分けることができるのでよいですね。\nこれだけ覚えておけば OK バージョン番号の形式は、メジャー.マイナー.パッチです。(例：1.0.0)\nメジャー 後方互換性がない変更があった時にはこの番号を上げなければいけません(MUST) この番号を上げた際には、マイナー/パッチの番号は 0 にリセットしなければいけません(MUST) この番号が「0」の場合は初期開発用として扱います。リリースの段階でこの番号を「1」に上げます。 マイナー 後方互換性を保ちつつ、機能追加のある時にはこの番号を上げなければいけません(MUST) この番号を上げた際には、パッチの番号は 0 にリセットしなければいけません(MUST) パッチ 後方互換性を保ちつつ、バグ修正のある時にはこの番号を上げなければいけません(MUST) ※バグ修正とは間違った振る舞いを修正する内部の変更のことをいいます。\nちょっと踏み込むと プレリリースバージョンには、パッチ番号の後ろにハイフンで区切って識別子をつけることができます。 (例：1.1.0-alpha / 1.1.0-beta / 1.1.0-rc) ※ちなみに識別子のrcは「release candidate」の略でベータ版よりもさらに製品版に近い品質のバージョンにつけるそうです。（略を初めて知りました。）\nあと npm の packagge.json でもモジュールをセマンティックバージョンで管理してます。（~や^が付与されているのをよく見ると思います。） これについては上、真ん中、下で覚えるバージョニング範囲指定がわかりやすかったので共有しておきます。\n余談 たかがバージョニング、されどバージョニングといった感じでした。知ってて損はないですよね。\n備考 表紙イラスト：Loose Drawing","tags":["oss"],"title":"Semantic Versioning"},{"categories":["Go"],"contents":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\n地球上の２点間の距離計算ってアプリだと Google Map API を使えば完了！だと思いますが、どう計算してるかって気になりますよね？\n今回は球面三角法を利用した地球上の２点間の距離計算を Go で実装します。（調べたらフツーにあるんですが）\n球面三角法とは その名の通り、三角関数を利用して球面上の辺や角の大きさを導出するものです。平面と球面とでの違いは辺の大きさが 球面では中心角によって表されることにあります。\nよって、球面三角法を使用して算出した弧の長さ(中心角)と赤道の半径を乗算すると距離が求まります。\n球面三角法の証明については、球面三角形の定理を参考にしました！\n(\u0026ldquo;高校生に向けて\u0026quot;とある通り、非常にわかりやすかったです)\n球面三角法の余弦定理を利用して実際に距離を算出する方法は球面三角法の余弦定理がわかりやすいです。\n実装 実装したソースコードは Github でも確認できます。\n球面三角法を利用した２点間の距離計算\npackage main import \u0026#34;math\u0026#34; // Coordinate 緯度経度 type Coordinate struct { Longitude float64 Latitude float64 } // EarthRadius 赤道半径 const EarthRadius = 6378140 // DistanceOnTheEarth 地球上の 2 点間の距離を出す（球面三角法） func DistanceOnTheEarth(from, to Coordinate) float64 { fromLadLon := from.Longitude * math.Pi / 180 fromLadLat := from.Latitude * math.Pi / 180 toLadLon := to.Longitude * math.Pi / 180 toLadLat := to.Latitude * math.Pi / 180 alpha := math.Sin(fromLadLat)*math.Sin(toLadLat) + math.Cos(fromLadLat)*math.Cos(toLadLat)*math.Cos(fromLadLon-toLadLon) arcAlpha := math.Acos(alpha) return arcAlpha * EarthRadius / 1000 } 動かしてみる それでは実装した Go の関数を呼び出す簡単なアプリを動かしていきます。\n※今回使用するアプリも Github 上の同じディレクトリにあるのでビルドすると使用できます。\nアプリの挙動としては、\n2 点間の緯度経度情報を取得する（取得するために外部 APIを利用します） 1 で取得した２点の緯度経度情報を今回実装した距離計算の関数へ渡して算出する 比較するためにこちらのサイトを利用します。\n結果 場所 比較サイト 今回のアプリ 西東京市 ~ 大阪市都島区 383.344422 383.3444215569602 札幌市厚別区　~ 沖縄市 2,231.318234 2231.3182342761 ※地球上の半径 r は 6378.140km にしています。\n。。。同じになってしまいました。。比較とはなんだったんだろう\nまあよく捉えると、比較サイトのような便利計算サイトと同等?のものが作れたということでしょうか。\n余談 久しぶりに証明を見たり計算を手で追っていく作業をしたので懐かしい気持ちになりました。\n普段の業務でそこまで計算式を使わない分、こう自発的に調べて実装するのも楽しいと思いました。\n","date":"July 6, 2020","hero":"/posts/category/go/2020/07/spherical-trigonometry/hero.png","permalink":"https://uh-zz.github.io/posts/category/go/2020/07/spherical-trigonometry/","summary":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\n地球上の２点間の距離計算ってアプリだと Google Map API を使えば完了！だと思いますが、どう計算してるかって気になりますよね？\n今回は球面三角法を利用した地球上の２点間の距離計算を Go で実装します。（調べたらフツーにあるんですが）\n球面三角法とは その名の通り、三角関数を利用して球面上の辺や角の大きさを導出するものです。平面と球面とでの違いは辺の大きさが 球面では中心角によって表されることにあります。\nよって、球面三角法を使用して算出した弧の長さ(中心角)と赤道の半径を乗算すると距離が求まります。\n球面三角法の証明については、球面三角形の定理を参考にしました！\n(\u0026ldquo;高校生に向けて\u0026quot;とある通り、非常にわかりやすかったです)\n球面三角法の余弦定理を利用して実際に距離を算出する方法は球面三角法の余弦定理がわかりやすいです。\n実装 実装したソースコードは Github でも確認できます。\n球面三角法を利用した２点間の距離計算\npackage main import \u0026#34;math\u0026#34; // Coordinate 緯度経度 type Coordinate struct { Longitude float64 Latitude float64 } // EarthRadius 赤道半径 const EarthRadius = 6378140 // DistanceOnTheEarth 地球上の 2 点間の距離を出す（球面三角法） func DistanceOnTheEarth(from, to Coordinate) float64 { fromLadLon := from.Longitude * math.Pi / 180 fromLadLat := from.Latitude * math.Pi / 180 toLadLon := to.","tags":["Go"],"title":"球面三角法による２点間の距離計算をGoで実装してみた"},{"categories":["Go"],"contents":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\nマージソート マージソートは、ソートのアルゴリズムで、既に整列してある複数個の列を 1 個の列にマージする際に、小さいものから先に新しい列に並べれば、新しい列も整列されている、というボトムアップの分割統治法による。大きい列を多数の列に分割し、そのそれぞれをマージする作業は並列化できる。\n出典：wikipedia「マージソート」より引用\n最悪の計算量が O(n log n) であるから少なくとも O(n^2)よりは速いんだろうなという印象（雑すぎるか）\n以下「ソートを極める！ 〜 なぜソートを学ぶのか 〜」を元に実装してみた（なるべくソースを見ないで実装を試みたがマージする箇所は折れた、、）\npackage main import ( \u0026#34;fmt\u0026#34; \u0026#34;time\u0026#34; \u0026#34;github.com/uh-zz/traning/algorithm/shuffle\u0026#34; ) func main() { // ランダムな要素 n 個のスライス取得 input := shuffle.RandomIntList(n) inputLength := len(input) // マージソート MergeSort(\u0026amp;input, 0, inputLength) } // MergeSort マージソート func MergeSort(input \\*[]int, left, right int) { // 要素数1つの場合は抜ける if right-left == 1 { return } // 配列を２つに分けるインデックス middle := left + (right-left)/2 // 配列左側 MergeSort(input, left, middle) // 配列右側 MergeSort(input, middle, right) var buffer []int // 左側と右側をバッファにためる（右側反転） for index := left; index \u0026lt; middle; index++ { buffer = append(buffer, (*input)[index]) } for index := right - 1; index \u0026gt;= middle; index-- { buffer = append(buffer, (*input)[index]) } // マージする scopeLeft := 0 scopeRight := len(buffer) - 1 for index := left; index \u0026lt; right; index++ { if buffer[scopeLeft] \u0026lt;= buffer[scopeRight] { // 左側採用 (*input)[index] = buffer[scopeLeft] scopeLeft++ } else { // 右側採用 (*input)[index] = buffer[scopeRight] scopeRight-- } } } これ考えたのぶっ飛んでるなあと思って Wikipedia 見てたら、考案者がフォン・ノイマンでやっぱりぶっ飛んでた（凄すぎ）\n挿入ソート 挿入ソート（インサーションソート）は、ソートのアルゴリズムの一つ。整列してある配列に追加要素を適切な場所に挿入すること。平均計算時間・最悪計算時間がともに O(n2)と遅いが、アルゴリズムが単純で実装が容易なため、しばしば用いられる。安定な内部ソート。基本挿入法ともいう。in-place アルゴリズムであり、オンラインアルゴリズムである。\n出典：wikipedia「挿入ソート」より引用\nこれも「ソートを極める！ 〜 なぜソートを学ぶのか 〜」を元に実装してみた\npackage main import ( \u0026#34;fmt\u0026#34; \u0026#34;time\u0026#34; \u0026#34;github.com/uh-zz/traning/algorithm/shuffle\u0026#34; ) func main() { // ランダムな要素 n 個のスライス input := shuffle.RandomIntList(n) // 挿入ソート for index := 1; index \u0026lt; len(input); index++ { // 挿入したい値 insertValue := input[index] // 挿入位置 point := index for ; point \u0026gt; 0; point-- { if input[point-1] \u0026gt; insertValue { input[point] = input[point-1] } else { break } } input[point] = insertValue } } こっちは実装もしやすく理解するのも難しくないという印象。最終的にはどちらもソートするというのにこの差は、、と思ってしまう。\n速度比較 今回はソートアルゴリズムの実装がメインだったけど、２つあるなら比較するまでがアウトプットだろうなと感じたので比較します。\nマシンスペック OS: macOS Catalina プロセッサ: 1.6 GHz(Core i5) メモリ: 16 GB 実施方法 要素数 n 個のスライスのソート時間を比較する。要素はそれぞれランダムになっている。\n結果 要素数(n) マージソート(O(n log n)(sec) 挿入ソート(O(n^2)(sec) 1,000 0.000357 0.000277 10,000 0.005002 0.024778 100,000 0.036705 1.524296 1,000,000 0.341336 - ※挿入ソート（1,000,000）は 1 分以上かかったので省略\n要素が倍になるほどマージソートの速さがわかりますね。\nこのページのソースは GitHub にもあります。\nソートアルゴリズムの比較\n余談 アルゴリズムを１ヶ月で把握しようとしてましたがソートアルゴリズムの雰囲気を掴むだけでそれくらい時間かかりました、、\n１つずつ精進ですね。。\n","date":"July 5, 2020","hero":"/posts/category/go/2020/07/compare-sort-aligorithm/hero.png","permalink":"https://uh-zz.github.io/posts/category/go/2020/07/compare-sort-aligorithm/","summary":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\nマージソート マージソートは、ソートのアルゴリズムで、既に整列してある複数個の列を 1 個の列にマージする際に、小さいものから先に新しい列に並べれば、新しい列も整列されている、というボトムアップの分割統治法による。大きい列を多数の列に分割し、そのそれぞれをマージする作業は並列化できる。\n出典：wikipedia「マージソート」より引用\n最悪の計算量が O(n log n) であるから少なくとも O(n^2)よりは速いんだろうなという印象（雑すぎるか）\n以下「ソートを極める！ 〜 なぜソートを学ぶのか 〜」を元に実装してみた（なるべくソースを見ないで実装を試みたがマージする箇所は折れた、、）\npackage main import ( \u0026#34;fmt\u0026#34; \u0026#34;time\u0026#34; \u0026#34;github.com/uh-zz/traning/algorithm/shuffle\u0026#34; ) func main() { // ランダムな要素 n 個のスライス取得 input := shuffle.RandomIntList(n) inputLength := len(input) // マージソート MergeSort(\u0026amp;input, 0, inputLength) } // MergeSort マージソート func MergeSort(input \\*[]int, left, right int) { // 要素数1つの場合は抜ける if right-left == 1 { return } // 配列を２つに分けるインデックス middle := left + (right-left)/2 // 配列左側 MergeSort(input, left, middle) // 配列右側 MergeSort(input, middle, right) var buffer []int // 左側と右側をバッファにためる（右側反転） for index := left; index \u0026lt; middle; index++ { buffer = append(buffer, (*input)[index]) } for index := right - 1; index \u0026gt;= middle; index-- { buffer = append(buffer, (*input)[index]) } // マージする scopeLeft := 0 scopeRight := len(buffer) - 1 for index := left; index \u0026lt; right; index++ { if buffer[scopeLeft] \u0026lt;= buffer[scopeRight] { // 左側採用 (*input)[index] = buffer[scopeLeft] scopeLeft++ } else { // 右側採用 (*input)[index] = buffer[scopeRight] scopeRight-- } } } これ考えたのぶっ飛んでるなあと思って Wikipedia 見てたら、考案者がフォン・ノイマンでやっぱりぶっ飛んでた（凄すぎ）","tags":["Go"],"title":"ソートアルゴリズムをGoで実装してみた"},{"categories":["computer-science"],"contents":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\nプロセスとは プロセスという概念は Linux において、ファイルシステム、ストリームに並んで重要な構成要素の１つです。\nプログラマが作成したソースコードはファイルに保存されます。そしてファイルの保存先はハードディスクです。\nプログラムの実行時、プログラムはハードディスクからメモリへと読み込まれます。\nCPU はメモリに読み込まれたプログラムを順次処理していきます。このとき、メモリに読み込まれて CPU に処理されているプログラムをプロセスといいます。\n１つのプロセスを処理できるのは１つの CPU のみです。\nそのため、同じプロセスしか一度に実行できなくなるといったことを避けるために、CPU はプロセスごとに処理時間を決めて次々に切り替えます。\n普段使っている PC やスマホは Youtube や Line や Twitter など、複数アプリを同時に起動して使用しています。\nあれは CPU が処理時間を決めて順に処理しているために実現されています。\nOS のコアであるカーネルはプロセスの優先順位を考慮して、各プロセスに処理時間を割り当てます。\n(この機能をスケジューラ、またはディスパッチャといいます。)\nアドレス空間 プロセス１つに対して、CPU とメモリがそれぞれ１つ必要です。CPU は前述の通り、処理時間を割り当てるのに対し、メモリはプロセスごとにアドレス空間を割り当てます。\nメモリにプログラムを書き込む際にはアドレスが必要です。\nしかしプロセスには 0 番地から始まるメモリが必要なため、１つのプロセスしか使えなくなってしまいます。\nそこでプロセスから見えるアドレス(論理アドレス)と実際のアドレス(物理アドレス)を分けてしまいます。\nこうすることで、カーネルと CPU によって論理アドレス → 物理アドレスと変換された実際のアドレスに対して書き込むことができます。\n１つのプロセスの論理アドレス、物理アドレスを全体としてアドレス空間といいます。\nアドレス空間はプロセスごとに割り当てられるので他のプロセスにアクセスできなくなります。\nプロセス API fork(2) 自分のプロセスを複製して新しいプロセスを作ります。\nGithub でも fork がありますが、意味合いは同じです。既存のリポジトリを複製します。複製したリポジトリは自由に更新できますが、fork した元のリポジトリに対しては更新はできません。\nプロセスの fork は元からあるプロセスを親プロセス、複製されたプロセスを子プロセスと呼びます。\n子プロセスの fork 実行時の戻り値は 0 です。\n(戻り値 0 は正常終了のステータスコード)そして親プロセスの fork 実行時の戻り値は子プロセスのプロセス ID です。\nシェルでもps auxコマンドを使用して確認できます。\nexec プロセスを新しいプログラムで上書きします。fork したプロセスで即座に exec することで新しいプログラムを時刻したことになります。\nwait(2) fork したプロセスの終了を待ちます。\n以上で、プロセスのライフサイクルは fork で子プロセスを生成し、exec で実行して wait によって、親プロセス側で終了判定するといった流れになります。\npipe(2) シェルではパイプ「|」を使って複数のコマンドをつなぐことができます。\n言い換えると、パイプはプロセスからプロセスにつながったストリームのことです。(ストリームはバイトの流れ道のイメージ)\npipe を実行すると、１つのプロセスでは、自身の書き込み用から読み込み用のファイルディスクリプタへ一方向のストリームが生成されます。\nまた、プロセスを fork するとストリームも複製されます。\nそこで pipe を実行した後に、fork し親プロセスの読み込み側、子プロセスの書き込み側を close すると、\n親プロセスの書き込み側 → 子プロセスの読み込み側への１つのストリームが生成されます。\nこれがシェルのパイプの原理です。\nデーモンプロセス http サーバや mysql サーバ、いわゆる常駐プロセスと呼ばれるものです。\nps auxコマンドを実行した際、TTY の項目が?になっているプロセスで、制御端末を持たないプロセスのことを言います。\nサーバのようにずっと動作し続けるプロセスは、実行したユーザを持たないことで停止されることがなくなります。\n(プロセスは、起動したユーザがログアウトするとプロセスも停止してしまうからです。)\n余談 プロセスについての情報がなかなか探せない中、本棚に眠っていた良書を思い出して引っ張り出した甲斐がありました。\n日々の業務でも触れていますが、 汎用的な知識は重要だと痛切に感じます。\n備考 ふつうの Linux プログラミング 第 2 版 Linux の仕組みから学べる gcc プログラミングの王道\n表紙イラスト：Loose Drawing\n","date":"July 5, 2020","hero":"/posts/category/computer-science/2020/09/process-management/hero.png","permalink":"https://uh-zz.github.io/posts/category/computer-science/2020/09/process-management/","summary":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\nプロセスとは プロセスという概念は Linux において、ファイルシステム、ストリームに並んで重要な構成要素の１つです。\nプログラマが作成したソースコードはファイルに保存されます。そしてファイルの保存先はハードディスクです。\nプログラムの実行時、プログラムはハードディスクからメモリへと読み込まれます。\nCPU はメモリに読み込まれたプログラムを順次処理していきます。このとき、メモリに読み込まれて CPU に処理されているプログラムをプロセスといいます。\n１つのプロセスを処理できるのは１つの CPU のみです。\nそのため、同じプロセスしか一度に実行できなくなるといったことを避けるために、CPU はプロセスごとに処理時間を決めて次々に切り替えます。\n普段使っている PC やスマホは Youtube や Line や Twitter など、複数アプリを同時に起動して使用しています。\nあれは CPU が処理時間を決めて順に処理しているために実現されています。\nOS のコアであるカーネルはプロセスの優先順位を考慮して、各プロセスに処理時間を割り当てます。\n(この機能をスケジューラ、またはディスパッチャといいます。)\nアドレス空間 プロセス１つに対して、CPU とメモリがそれぞれ１つ必要です。CPU は前述の通り、処理時間を割り当てるのに対し、メモリはプロセスごとにアドレス空間を割り当てます。\nメモリにプログラムを書き込む際にはアドレスが必要です。\nしかしプロセスには 0 番地から始まるメモリが必要なため、１つのプロセスしか使えなくなってしまいます。\nそこでプロセスから見えるアドレス(論理アドレス)と実際のアドレス(物理アドレス)を分けてしまいます。\nこうすることで、カーネルと CPU によって論理アドレス → 物理アドレスと変換された実際のアドレスに対して書き込むことができます。\n１つのプロセスの論理アドレス、物理アドレスを全体としてアドレス空間といいます。\nアドレス空間はプロセスごとに割り当てられるので他のプロセスにアクセスできなくなります。\nプロセス API fork(2) 自分のプロセスを複製して新しいプロセスを作ります。\nGithub でも fork がありますが、意味合いは同じです。既存のリポジトリを複製します。複製したリポジトリは自由に更新できますが、fork した元のリポジトリに対しては更新はできません。\nプロセスの fork は元からあるプロセスを親プロセス、複製されたプロセスを子プロセスと呼びます。\n子プロセスの fork 実行時の戻り値は 0 です。\n(戻り値 0 は正常終了のステータスコード)そして親プロセスの fork 実行時の戻り値は子プロセスのプロセス ID です。","tags":["computer-science"],"title":"プロセス管理"},{"categories":["AWS","DynamoDB"],"contents":"はじめに Dynamo のテーブルに GSI(グローバルセカンダリインデックス)を貼ってハッシュキー＋ソートキーでクエリするパターンが通常の使い方かと思います。\nではソートキーを日付にしていた場合、同じ日付範囲のデータを一括で取得できる方法はありますでしょうか？\n公式ドキュメントにはその辺の Tips なかったのですが、同僚から以下の記事を教えてもらいました。\nDynamoDB の設計力をあげたい\nこれの設計２を参考にしました。\n全データ共通のダミー列を用意して、以下の GSI を作成します。\nパーティションキーはダミー列 ソートキーに日付 これで同じ日付範囲の複数データを引っ張ってくることが可能になります。\n確かに美しいと言えないかもしれませんが、機転の効いた方法だと思いました。\n","date":"June 5, 2020","hero":"/posts/category/aws/2020/06/dynamo-only-sortkey-without-partionkey/hero.svg","permalink":"https://uh-zz.github.io/posts/category/aws/2020/06/dynamo-only-sortkey-without-partionkey/","summary":"はじめに Dynamo のテーブルに GSI(グローバルセカンダリインデックス)を貼ってハッシュキー＋ソートキーでクエリするパターンが通常の使い方かと思います。\nではソートキーを日付にしていた場合、同じ日付範囲のデータを一括で取得できる方法はありますでしょうか？\n公式ドキュメントにはその辺の Tips なかったのですが、同僚から以下の記事を教えてもらいました。\nDynamoDB の設計力をあげたい\nこれの設計２を参考にしました。\n全データ共通のダミー列を用意して、以下の GSI を作成します。\nパーティションキーはダミー列 ソートキーに日付 これで同じ日付範囲の複数データを引っ張ってくることが可能になります。\n確かに美しいと言えないかもしれませんが、機転の効いた方法だと思いました。","tags":["AWS","DynamoDB"],"title":"DynamoDB のソートキーだけで絞り込みたいとき"},{"categories":["Development"],"contents":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\nアジャイル開発 「アジャイル開発」っていうとなんかカッコいいしモダンっぽいというイメージをおそらく持っている人もいるでしょう。(私を含めて)\n逆に「ウォーターフォール開発」はなんか古臭いし、どこぞの金融系ぷ r、、おっと誰か来たみたいなのでこの辺で。\nとまあ、もてはやされたアジャイル開発ですが、フタを開けてみれば「要件定義 → 設計 → 実装 → テスト」の全工程を１つの単位として反復するという手法なのです。\n反復する期間はチームやプロジェクトによってまちまちですが、1 週間〜4 週間ほどです。\nってことはですよ、V 字モデルのウォーターフォールを短いスパンで回してるだけ？、、それウォーターフォールじゃねぇか！！\n、、というヤジも分からなくはありませんが、ちゃんとメリットがあります。\nメリット 1. スピーディー(早い) だってそうですよね。ウォーターフォールでは全工程を段階的に進めていくのでリリースまでに時間がかかってしまいます。\n対してアジャイルでは前工程を１つのサイクルとして反復するのでリリースまでの期間が短く済みます。\n2. やすい(安い ×) しかもアジャイルは、開発サイクルが短い分、仕様変更や追加機能の対応がしやすいというのもあります。\nウォーターフォールだと、段階的に進めるので、１つの仕様変更があった場合、工程を戻すことになり、、おぉ、、考えただけでも恐ろしいですね。\n3. ユーザーファースト(うまい?) これも納得ですね。\nリリースが早い分、クライアント(ユーザー)に効率よく素早く提供できる → クライアント喜ぶ → 褒められる → 嬉しい=うまい?\n(これは数合わせです)\nアジャイル開発の手法 手法は以下の３つです。\nスクラム エクストリームプログラミング ユーザ機能駆動開発 この中で私が経験したのは、スクラムのみです。(2020/07 時点)\nどのサイトでも言われている通り、この開発手法ではメンバーとのコミュニケーションが非常に重要です。\nそのイテレーション(スプリント)でリリースする機能も複数人が関わっていたり、メンバー間での連携が必要な機能だったり。。\n極めつけは１つのアプリの全機能を全メンバーが把握しているのがヨシとされるので、知らない機能は教えたり教わったりしないといけないからです。(これは私のチームだけなのかは知りませんが)\nまとめ 、、とすごく大変そうに見えますが(実際に大変ですが)、スクラムならではの団体戦みのある開発でまあうまく回せるんではないでしょうかというのが感想です。\n備考 表紙イラスト：Loose Drawing\n","date":"June 5, 2020","hero":"/posts/category/development/2020/08/agile-software-development/hero.png","permalink":"https://uh-zz.github.io/posts/category/development/2020/08/agile-software-development/","summary":"はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。\nアジャイル開発 「アジャイル開発」っていうとなんかカッコいいしモダンっぽいというイメージをおそらく持っている人もいるでしょう。(私を含めて)\n逆に「ウォーターフォール開発」はなんか古臭いし、どこぞの金融系ぷ r、、おっと誰か来たみたいなのでこの辺で。\nとまあ、もてはやされたアジャイル開発ですが、フタを開けてみれば「要件定義 → 設計 → 実装 → テスト」の全工程を１つの単位として反復するという手法なのです。\n反復する期間はチームやプロジェクトによってまちまちですが、1 週間〜4 週間ほどです。\nってことはですよ、V 字モデルのウォーターフォールを短いスパンで回してるだけ？、、それウォーターフォールじゃねぇか！！\n、、というヤジも分からなくはありませんが、ちゃんとメリットがあります。\nメリット 1. スピーディー(早い) だってそうですよね。ウォーターフォールでは全工程を段階的に進めていくのでリリースまでに時間がかかってしまいます。\n対してアジャイルでは前工程を１つのサイクルとして反復するのでリリースまでの期間が短く済みます。\n2. やすい(安い ×) しかもアジャイルは、開発サイクルが短い分、仕様変更や追加機能の対応がしやすいというのもあります。\nウォーターフォールだと、段階的に進めるので、１つの仕様変更があった場合、工程を戻すことになり、、おぉ、、考えただけでも恐ろしいですね。\n3. ユーザーファースト(うまい?) これも納得ですね。\nリリースが早い分、クライアント(ユーザー)に効率よく素早く提供できる → クライアント喜ぶ → 褒められる → 嬉しい=うまい?\n(これは数合わせです)\nアジャイル開発の手法 手法は以下の３つです。\nスクラム エクストリームプログラミング ユーザ機能駆動開発 この中で私が経験したのは、スクラムのみです。(2020/07 時点)\nどのサイトでも言われている通り、この開発手法ではメンバーとのコミュニケーションが非常に重要です。\nそのイテレーション(スプリント)でリリースする機能も複数人が関わっていたり、メンバー間での連携が必要な機能だったり。。\n極めつけは１つのアプリの全機能を全メンバーが把握しているのがヨシとされるので、知らない機能は教えたり教わったりしないといけないからです。(これは私のチームだけなのかは知りませんが)\nまとめ 、、とすごく大変そうに見えますが(実際に大変ですが)、スクラムならではの団体戦みのある開発でまあうまく回せるんではないでしょうかというのが感想です。\n備考 表紙イラスト：Loose Drawing","tags":["Development"],"title":"アジャイル開発"},{"categories":null,"contents":"","date":"January 1, 0001","hero":"/images/default-hero.jpg","permalink":"https://uh-zz.github.io/en/about/","summary":"","tags":null,"title":""}] \ No newline at end of file diff --git a/index.xml b/index.xml index 73c0226b..a5e4e6e9 100644 --- a/index.xml +++ b/index.xml @@ -52,7 +52,7 @@ package main func readFile(path string) chan string { // ファイルを読み 節目というか、ちょっと時間ができたので、私が履修している科目一覧を Notion で管理しようと思い立ち、さくっと作ってみました。 科目一覧 - Notion これから同じように学習される方の参考になれば幸いです。（私も諸先輩方のブログを見て、参考になったので恩返しできれば！） -近況 元気にやっています:pduck_b: +近況 元気にやっています&#x1f44b; 備考 表紙イラスト：Loose Drawing2022年07月に読んだ記事とか本とかhttps://uh-zz.github.io/posts/category/inputs/2022/07/Tue, 05 Jul 2022 18:07:06 +0900https://uh-zz.github.io/posts/category/inputs/2022/07/はじめに 読んだ記事とか本のリンクを張っておきます 読んだ記事 アーキテクトに求められるマインドとは / mindset for an architect 「少なくとも、最悪ではないアーキテクチャを狙う」 diff --git a/notes/index.html b/notes/index.html index 4e344a85..43aa0ec5 100644 --- a/notes/index.html +++ b/notes/index.html @@ -8,5 +8,5 @@
    \ No newline at end of file diff --git a/notes/page/2/index.html b/notes/page/2/index.html index 6f4c26cc..baa4360e 100644 --- a/notes/page/2/index.html +++ b/notes/page/2/index.html @@ -8,5 +8,5 @@
    \ No newline at end of file diff --git a/posts/category/aws/2020/06/dynamo-only-sortkey-without-partionkey/index.html b/posts/category/aws/2020/06/dynamo-only-sortkey-without-partionkey/index.html index e0aaa582..7751015a 100644 --- a/posts/category/aws/2020/06/dynamo-only-sortkey-without-partionkey/index.html +++ b/posts/category/aws/2020/06/dynamo-only-sortkey-without-partionkey/index.html @@ -21,7 +21,7 @@
    -
    Author Image

    Friday, June 5, 2020

    DynamoDB のソートキーだけで絞り込みたいとき

    はじめに

    Dynamo のテーブルに GSI(グローバルセカンダリインデックス)を貼ってハッシュキー＋ソートキーでクエリするパターンが通常の使い方かと思います。

    ではソートキーを日付にしていた場合、同じ日付範囲のデータを一括で取得できる方法はありますでしょうか？

    公式ドキュメントにはその辺の Tips なかったのですが、同僚から以下の記事を教えてもらいました。

    DynamoDB の設計力をあげたい

    これの設計２を参考にしました。

    全データ共通のダミー列を用意して、以下の GSI を作成します。

    • パーティションキーはダミー列
    • ソートキーに日付

    これで同じ日付範囲の複数データを引っ張ってくることが可能になります。

    確かに美しいと言えないかもしれませんが、機転の効いた方法だと思いました。

    +
    Author Image

    Friday, June 5, 2020

    DynamoDB のソートキーだけで絞り込みたいとき

    はじめに

    Dynamo のテーブルに GSI(グローバルセカンダリインデックス)を貼ってハッシュキー＋ソートキーでクエリするパターンが通常の使い方かと思います。

    ではソートキーを日付にしていた場合、同じ日付範囲のデータを一括で取得できる方法はありますでしょうか？

    公式ドキュメントにはその辺の Tips なかったのですが、同僚から以下の記事を教えてもらいました。

    DynamoDB の設計力をあげたい

    これの設計２を参考にしました。

    全データ共通のダミー列を用意して、以下の GSI を作成します。

    • パーティションキーはダミー列
    • ソートキーに日付

    これで同じ日付範囲の複数データを引っ張ってくることが可能になります。

    確かに美しいと言えないかもしれませんが、機転の効いた方法だと思いました。

    Improve this page
    \ No newline at end of file diff --git a/posts/category/aws/index.html b/posts/category/aws/index.html index 43b73a5b..500e5b27 100644 --- a/posts/category/aws/index.html +++ b/posts/category/aws/index.html @@ -7,7 +7,7 @@
    -
    Hero Image
    DynamoDB のソートキーだけで絞り込みたいとき

    はじめに Dynamo のテーブルに GSI(グローバルセカンダリインデックス)を貼ってハッシュキー＋ソートキーでクエリするパターンが通常の使い方かと思います。 +

    Hero Image
    DynamoDB のソートキーだけで絞り込みたいとき

    はじめに Dynamo のテーブルに GSI(グローバルセカンダリインデックス)を貼ってハッシュキー＋ソートキーでクエリするパターンが通常の使い方かと思います。 ではソートキーを日付にしていた場合、同じ日付範囲のデータを一括で取得できる方法はありますでしょうか？ 公式ドキュメントにはその辺の Tips なかったのですが、同僚から以下の記事を教えてもらいました。 DynamoDB の設計力をあげたい @@ -16,5 +16,5 @@ パーティションキーはダミー列 ソートキーに日付 これで同じ日付範囲の複数データを引っ張ってくることが可能になります。 確かに美しいと言えないかもしれませんが、機転の効いた方法だと思いました。

    Friday, June 5, 2020 Read
    \ No newline at end of file diff --git a/posts/category/computer-science/2020/09/process-management/index.html b/posts/category/computer-science/2020/09/process-management/index.html index 616ba345..e3c00abd 100644 --- a/posts/category/computer-science/2020/09/process-management/index.html +++ b/posts/category/computer-science/2020/09/process-management/index.html @@ -51,7 +51,7 @@
    -
    Author Image

    Sunday, July 5, 2020

    プロセス管理

    はじめに

    バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。

    プロセスとは

    プロセスという概念は Linux において、ファイルシステム、ストリームに並んで重要な構成要素の１つです。

    プログラマが作成したソースコードはファイルに保存されます。そしてファイルの保存先はハードディスクです。

    プログラムの実行時、プログラムはハードディスクからメモリへと読み込まれます。

    CPU はメモリに読み込まれたプログラムを順次処理していきます。このとき、メモリに読み込まれて CPU に処理されているプログラムをプロセスといいます。

    １つのプロセスを処理できるのは１つの CPU のみです。

    そのため、同じプロセスしか一度に実行できなくなるといったことを避けるために、CPU はプロセスごとに処理時間を決めて次々に切り替えます。

    普段使っている PC やスマホは Youtube や Line や Twitter など、複数アプリを同時に起動して使用しています。

    あれは CPU が処理時間を決めて順に処理しているために実現されています。

    OS のコアであるカーネルはプロセスの優先順位を考慮して、各プロセスに処理時間を割り当てます。

    (この機能をスケジューラ、またはディスパッチャといいます。)

    アドレス空間

    プロセス１つに対して、CPU とメモリがそれぞれ１つ必要です。CPU は前述の通り、処理時間を割り当てるのに対し、メモリはプロセスごとにアドレス空間を割り当てます。

    メモリにプログラムを書き込む際にはアドレスが必要です。

    しかしプロセスには 0 番地から始まるメモリが必要なため、１つのプロセスしか使えなくなってしまいます。

    そこでプロセスから見えるアドレス(論理アドレス)と実際のアドレス(物理アドレス)を分けてしまいます。

    こうすることで、カーネルと CPU によって論理アドレス → 物理アドレスと変換された実際のアドレスに対して書き込むことができます。

    １つのプロセスの論理アドレス、物理アドレスを全体としてアドレス空間といいます。

    アドレス空間はプロセスごとに割り当てられるので他のプロセスにアクセスできなくなります。

    プロセス API

    fork(2)

    自分のプロセスを複製して新しいプロセスを作ります。

    Github でも fork がありますが、意味合いは同じです。既存のリポジトリを複製します。複製したリポジトリは自由に更新できますが、fork した元のリポジトリに対しては更新はできません。

    プロセスの fork は元からあるプロセスを親プロセス、複製されたプロセスを子プロセスと呼びます。

    子プロセスの fork 実行時の戻り値は 0 です。

    (戻り値 0 は正常終了のステータスコード)そして親プロセスの fork 実行時の戻り値は子プロセスのプロセス ID です。

    シェルでもps auxコマンドを使用して確認できます。

    exec

    プロセスを新しいプログラムで上書きします。fork したプロセスで即座に exec することで新しいプログラムを時刻したことになります。

    wait(2)

    fork したプロセスの終了を待ちます。

    以上で、プロセスのライフサイクルは fork で子プロセスを生成し、exec で実行して wait によって、親プロセス側で終了判定するといった流れになります。

    pipe(2)

    シェルではパイプ「|」を使って複数のコマンドをつなぐことができます。

    言い換えると、パイプはプロセスからプロセスにつながったストリームのことです。(ストリームはバイトの流れ道のイメージ)

    pipe を実行すると、１つのプロセスでは、自身の書き込み用から読み込み用のファイルディスクリプタへ一方向のストリームが生成されます。

    また、プロセスを fork するとストリームも複製されます。

    そこで pipe を実行した後に、fork し親プロセスの読み込み側、子プロセスの書き込み側を close すると、

    親プロセスの書き込み側 → 子プロセスの読み込み側への１つのストリームが生成されます。

    これがシェルのパイプの原理です。

    デーモンプロセス

    http サーバや mysql サーバ、いわゆる常駐プロセスと呼ばれるものです。

    ps auxコマンドを実行した際、TTY の項目が?になっているプロセスで、制御端末を持たないプロセスのことを言います。

    サーバのようにずっと動作し続けるプロセスは、実行したユーザを持たないことで停止されることがなくなります。

    (プロセスは、起動したユーザがログアウトするとプロセスも停止してしまうからです。)

    余談

    プロセスについての情報がなかなか探せない中、本棚に眠っていた良書を思い出して引っ張り出した甲斐がありました。

    日々の業務でも触れていますが、 汎用的な知識は重要だと痛切に感じます。

    備考

    ふつうの Linux プログラミング 第 2 版 Linux の仕組みから学べる gcc プログラミングの王道

    表紙イラスト：Loose Drawing

    +
    Author Image

    Sunday, July 5, 2020

    プロセス管理

    はじめに

    バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。

    プロセスとは

    プロセスという概念は Linux において、ファイルシステム、ストリームに並んで重要な構成要素の１つです。

    プログラマが作成したソースコードはファイルに保存されます。そしてファイルの保存先はハードディスクです。

    プログラムの実行時、プログラムはハードディスクからメモリへと読み込まれます。

    CPU はメモリに読み込まれたプログラムを順次処理していきます。このとき、メモリに読み込まれて CPU に処理されているプログラムをプロセスといいます。

    １つのプロセスを処理できるのは１つの CPU のみです。

    そのため、同じプロセスしか一度に実行できなくなるといったことを避けるために、CPU はプロセスごとに処理時間を決めて次々に切り替えます。

    普段使っている PC やスマホは Youtube や Line や Twitter など、複数アプリを同時に起動して使用しています。

    あれは CPU が処理時間を決めて順に処理しているために実現されています。

    OS のコアであるカーネルはプロセスの優先順位を考慮して、各プロセスに処理時間を割り当てます。

    (この機能をスケジューラ、またはディスパッチャといいます。)

    アドレス空間

    プロセス１つに対して、CPU とメモリがそれぞれ１つ必要です。CPU は前述の通り、処理時間を割り当てるのに対し、メモリはプロセスごとにアドレス空間を割り当てます。

    メモリにプログラムを書き込む際にはアドレスが必要です。

    しかしプロセスには 0 番地から始まるメモリが必要なため、１つのプロセスしか使えなくなってしまいます。

    そこでプロセスから見えるアドレス(論理アドレス)と実際のアドレス(物理アドレス)を分けてしまいます。

    こうすることで、カーネルと CPU によって論理アドレス → 物理アドレスと変換された実際のアドレスに対して書き込むことができます。

    １つのプロセスの論理アドレス、物理アドレスを全体としてアドレス空間といいます。

    アドレス空間はプロセスごとに割り当てられるので他のプロセスにアクセスできなくなります。

    プロセス API

    fork(2)

    自分のプロセスを複製して新しいプロセスを作ります。

    Github でも fork がありますが、意味合いは同じです。既存のリポジトリを複製します。複製したリポジトリは自由に更新できますが、fork した元のリポジトリに対しては更新はできません。

    プロセスの fork は元からあるプロセスを親プロセス、複製されたプロセスを子プロセスと呼びます。

    子プロセスの fork 実行時の戻り値は 0 です。

    (戻り値 0 は正常終了のステータスコード)そして親プロセスの fork 実行時の戻り値は子プロセスのプロセス ID です。

    シェルでもps auxコマンドを使用して確認できます。

    exec

    プロセスを新しいプログラムで上書きします。fork したプロセスで即座に exec することで新しいプログラムを時刻したことになります。

    wait(2)

    fork したプロセスの終了を待ちます。

    以上で、プロセスのライフサイクルは fork で子プロセスを生成し、exec で実行して wait によって、親プロセス側で終了判定するといった流れになります。

    pipe(2)

    シェルではパイプ「|」を使って複数のコマンドをつなぐことができます。

    言い換えると、パイプはプロセスからプロセスにつながったストリームのことです。(ストリームはバイトの流れ道のイメージ)

    pipe を実行すると、１つのプロセスでは、自身の書き込み用から読み込み用のファイルディスクリプタへ一方向のストリームが生成されます。

    また、プロセスを fork するとストリームも複製されます。

    そこで pipe を実行した後に、fork し親プロセスの読み込み側、子プロセスの書き込み側を close すると、

    親プロセスの書き込み側 → 子プロセスの読み込み側への１つのストリームが生成されます。

    これがシェルのパイプの原理です。

    デーモンプロセス

    http サーバや mysql サーバ、いわゆる常駐プロセスと呼ばれるものです。

    ps auxコマンドを実行した際、TTY の項目が?になっているプロセスで、制御端末を持たないプロセスのことを言います。

    サーバのようにずっと動作し続けるプロセスは、実行したユーザを持たないことで停止されることがなくなります。

    (プロセスは、起動したユーザがログアウトするとプロセスも停止してしまうからです。)

    余談

    プロセスについての情報がなかなか探せない中、本棚に眠っていた良書を思い出して引っ張り出した甲斐がありました。

    日々の業務でも触れていますが、 汎用的な知識は重要だと痛切に感じます。

    備考

    ふつうの Linux プログラミング 第 2 版 Linux の仕組みから学べる gcc プログラミングの王道

    表紙イラスト：Loose Drawing

    Improve this page
    \ No newline at end of file diff --git a/posts/category/computer-science/2020/10/memory-management/index.html b/posts/category/computer-science/2020/10/memory-management/index.html index c24599b8..ced82f19 100644 --- a/posts/category/computer-science/2020/10/memory-management/index.html +++ b/posts/category/computer-science/2020/10/memory-management/index.html @@ -63,8 +63,8 @@
    -
    Author Image

    Monday, October 5, 2020

    メモリ管理

    はじめに

    バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。

    仮想メモリ

    プロセス管理でもあったように、メモリはアドレス空間ごとにプロセスを管理します。

    アドレス空間は 4KB/8KB 単位のページに分割して管理されています。

    ページはそれぞれ論理アドレス、物理アドレスを対応づける単位でもあります。

    論理アドレスと物理アドレスは常に紐づけられているわけではなく、そのページが必要になった時点で割り当てることも可能です。

    そのため、論理アドレスを実際の物理アドレスの容量より大きく確保することができます。

    (実際に使えるメモリの量よりも大きなメモリを想定できるということです。)

    仮装メモリとして使う仕組みには次の３つが挙げられます。

    ページング

    仮想メモリといえばこれ、という風に教えられるものの筆頭かと思います。

    ハードディスクを物理メモリの代わりに使うといったものです。

    物理メモリが不足すると、OS のコアであるカーネルは使われていないページをハードディスクに移して論理アドレスを解放します。

    そしてプロセスがハードディスクに移されたページにアクセスしようとすると、カーネルがプロセスを停止し、ハードディスクのページを再度物理メモリに読み込み、論理アドレスを対応づけます。

    また、プロセス全体を単位にする場合はスワッピングと呼ばれます。

    メモリマップトファイル

    ファイルをメモリとしてアクセスすることができるものです。

    アクセスがあった瞬間に、カーネルがファイルをメモリに読み込みます。プロセスがメモリを使い終わると、論理アドレスと物理アドレスを解放して、メモリの内容をファイルに保存します。

    共有メモリ

    １つの物理アドレスを、複数のプロセスの論理アドレスに対応づけるものです。 +

    Author Image

    Monday, October 5, 2020

    メモリ管理

    はじめに

    バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。

    仮想メモリ

    プロセス管理でもあったように、メモリはアドレス空間ごとにプロセスを管理します。

    アドレス空間は 4KB/8KB 単位のページに分割して管理されています。

    ページはそれぞれ論理アドレス、物理アドレスを対応づける単位でもあります。

    論理アドレスと物理アドレスは常に紐づけられているわけではなく、そのページが必要になった時点で割り当てることも可能です。

    そのため、論理アドレスを実際の物理アドレスの容量より大きく確保することができます。

    (実際に使えるメモリの量よりも大きなメモリを想定できるということです。)

    仮装メモリとして使う仕組みには次の３つが挙げられます。

    ページング

    仮想メモリといえばこれ、という風に教えられるものの筆頭かと思います。

    ハードディスクを物理メモリの代わりに使うといったものです。

    物理メモリが不足すると、OS のコアであるカーネルは使われていないページをハードディスクに移して論理アドレスを解放します。

    そしてプロセスがハードディスクに移されたページにアクセスしようとすると、カーネルがプロセスを停止し、ハードディスクのページを再度物理メモリに読み込み、論理アドレスを対応づけます。

    また、プロセス全体を単位にする場合はスワッピングと呼ばれます。

    メモリマップトファイル

    ファイルをメモリとしてアクセスすることができるものです。

    アクセスがあった瞬間に、カーネルがファイルをメモリに読み込みます。プロセスがメモリを使い終わると、論理アドレスと物理アドレスを解放して、メモリの内容をファイルに保存します。

    共有メモリ

    １つの物理アドレスを、複数のプロセスの論理アドレスに対応づけるものです。 アドレス空間をまたぐと危険では？！という見方もありますが、複数プロセスで処理できるため、巨大な画像データを編集するときには都合が良いみたいです。

    ※Go では共有メモリを使わずに Message Passing を使っています。

    メモリ管理 API

    malloc(3)

    メモリをヒープ領域に割り当てます。プログラム実行時に決まるサイズのメモリはヒープ領域から確保します。

    ヒープは「何かを積み重ねた山」のことで、その名の通り、プログラムを実行してから決定する量だけメモリを確保しておく領域なので納得です。

    malloc で確保したメモリはfreeで解放しなければいけません。

    calloc(3)

    メモリをヒープ領域に割り当てます。malloc と異なる点は、割り当てたメモリをゼロクリアすることです。

    こちらも malloc 同様、確保したメモリはfreeで解放しなければいけません。

    realloc(3)

    malloc で割り当てたメモリのサイズを拡大、縮小します。こちらも確保したメモリはfreeで解放しなければいけません。

    free

    割り当てたメモリを開放します。いったん開放したアドレスにはアクセスしてはいけません。

    メモリの開放漏れを防ぐために、malloc で確保したメモリは常に free で開放されるべきです。

    brk(2)

    malloc や realloc が割り当てるためのメモリを探してくるものです。

    物理アドレスが割り当てられていないページに物理アドレスを対応づけます。

    余談

    メモリはエラーでもかなりお世話になる部分なので、次回以降、実際のエラーやプログラミング言語(Go か Java)に絡めた記事を書きたいです。

    備考

    ふつうの Linux プログラミング 第 2 版 Linux の仕組みから学べる gcc プログラミングの王道

    表紙イラスト：Loose Drawing

    Improve this page
    \ No newline at end of file diff --git a/posts/category/computer-science/2020/11/thread-and-concurrency/index.html b/posts/category/computer-science/2020/11/thread-and-concurrency/index.html index 390f57ee..56fc909b 100644 --- a/posts/category/computer-science/2020/11/thread-and-concurrency/index.html +++ b/posts/category/computer-science/2020/11/thread-and-concurrency/index.html @@ -57,7 +57,7 @@
    -
    Author Image

    Monday, October 5, 2020

    スレッドと並行処理

    はじめに

    バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。

    スレッド

    プロセスが最低１つは持っている実行単位のことです。

    こんな言い方をするのは、プロセスが複数のスレッドを管理できるからです。

    実行単位という視点でプロセスとの違いは、「アドレス空間」を共有できるという点です。

    尾を引くようにプロセス管理の話に繋がりますが、プロセスにはそれぞれ１つのアドレス空間が割り当てられます。

    そして別のプロセスからアドレス空間へのアクセスは原則できません。(これを可能にするために共有メモリという方法を使います)

    それに対して、スレッドは１つのプロセスの実行単位を分けたものですから、同じアドレス空間を共有できるというわけです。

    そういうわけで、スレッドとプロセスをそれぞれ複数起動する場合は、スレッドの方がアドレス空間を１つで済ませることができるため省コストになります。

    では、複数のスレッドを起動してやることは?というと並行処理です。

    並行処理

    これもすでに出てきている話ではあります。プロセス管理の記事で出した複数アプリを同時に起動させるという部分です。

    「同時に」というのは私たちユーザがそう解釈しているだけで、アプリはカーネルが割り当てた非常に短い処理時間ごとに切り替えているのでしたよね。これが並行処理です。

    スレッドでも同じように短い処理時間ごとに切り替えて「同時に」処理させることができます。

    並列処理との違い

    私自身、再三調べては納得 → 忘れるを繰り返していましたが、プロセス管理(3 度目)をまとめることでやっと理解できたと思います。

    並行処理では処理時間ごとに切り替えると言いましたが、並列処理では CPU １つは言わず２つで処理してしまえばいいじゃないという考え方です。

    図で見ると非常にわかりやすいのですが、並行処理だとパン食べてチーズ食べてハム食べてレタス食べて、、を繰り返して食べ切る作戦なのに対して、並列処理はミックスサンドとして食べ切るようなイメージです。

    そんなの絶対ミックスサンドとして処理したら無限じゃんと思われますが、並列処理にも上限があるようです。

    アムダールの法則といって複数のプロセッサ(CPU のことですね)を使って並列化による高速化を行う場合、そのプログラムの中で逐次的に実行される処理部分(並列)の時間によって、高速化が制限されるというものです。

    出典：wikipedia「アムダールの法則」より引用

    まあ、上限があるといっても高速するのに変わりはないわけです。

    今回はその中でも比較的面白い実装を見つけたのでそれを紹介します。

    ワーカープール

    スレッドプールとも呼ばれるものです。並行処理でたくさんのスレッドを起動して、、というのももちろん可能ですが、それには代償が伴います。

    ワーカープールはそのようにいくつもスレッドを起動させるのではなく、すでに起動したスレッドを使い回そうの精神で実装される並行処理です。

    以下のような実装です。

    こちらを参考にさせていただきました。

    (ほぼコメントつけただけですが)

    package main
+
    Author Image
    Monday, October 5, 2020
    スレッドと並行処理
    はじめに
    バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。
    スレッド
    プロセスが最低１つは持っている実行単位のことです。
    こんな言い方をするのは、プロセスが複数のスレッドを管理できるからです。
    実行単位という視点でプロセスとの違いは、「アドレス空間」を共有できるという点です。
    尾を引くようにプロセス管理の話に繋がりますが、プロセスにはそれぞれ１つのアドレス空間が割り当てられます。
    そして別のプロセスからアドレス空間へのアクセスは原則できません。(これを可能にするために共有メモリという方法を使います)
    それに対して、スレッドは１つのプロセスの実行単位を分けたものですから、同じアドレス空間を共有できるというわけです。
    そういうわけで、スレッドとプロセスをそれぞれ複数起動する場合は、スレッドの方がアドレス空間を１つで済ませることができるため省コストになります。
    では、複数のスレッドを起動してやることは?というと並行処理です。
    並行処理
    これもすでに出てきている話ではあります。プロセス管理の記事で出した複数アプリを同時に起動させるという部分です。
    「同時に」というのは私たちユーザがそう解釈しているだけで、アプリはカーネルが割り当てた非常に短い処理時間ごとに切り替えているのでしたよね。これが並行処理です。
    スレッドでも同じように短い処理時間ごとに切り替えて「同時に」処理させることができます。
    並列処理との違い
    私自身、再三調べては納得 → 忘れるを繰り返していましたが、プロセス管理(3 度目)をまとめることでやっと理解できたと思います。
    並行処理では処理時間ごとに切り替えると言いましたが、並列処理では CPU １つは言わず２つで処理してしまえばいいじゃないという考え方です。
    図で見ると非常にわかりやすいのですが、並行処理だとパン食べてチーズ食べてハム食べてレタス食べて、、を繰り返して食べ切る作戦なのに対して、並列処理はミックスサンドとして食べ切るようなイメージです。
    そんなの絶対ミックスサンドとして処理したら無限じゃんと思われますが、並列処理にも上限があるようです。
    アムダールの法則といって複数のプロセッサ(CPU のことですね)を使って並列化による高速化を行う場合、そのプログラムの中で逐次的に実行される処理部分(並列)の時間によって、高速化が制限されるというものです。
    出典：wikipedia「アムダールの法則」より引用
    まあ、上限があるといっても高速するのに変わりはないわけです。
    今回はその中でも比較的面白い実装を見つけたのでそれを紹介します。
    ワーカープール
    スレッドプールとも呼ばれるものです。並行処理でたくさんのスレッドを起動して、、というのももちろん可能ですが、それには代償が伴います。
    ワーカープールはそのようにいくつもスレッドを起動させるのではなく、すでに起動したスレッドを使い回そうの精神で実装される並行処理です。
    以下のような実装です。
    こちらを参考にさせていただきました。
    (ほぼコメントつけただけですが)
    package main
 
 import (
   "fmt"
@@ -122,5 +122,5 @@
 worker 3 finished job 4
 
    実行するとわかりますが、順番がごっちゃになって処理されているのがわかります。
    これにより、ワーカーというスレッドごとに並行処理されているという動作を確認することができました。
    余談
    他にも面白そうな実装をいくつか見つけましたが、ただ羅列するだけでは萎えると思ったので気が向いたら別で紹介したいと思います。
    なにげに goroutine を使用していますが、goroutine の中身の処理内容(work stealing アルゴリズム)も面白いので、後々まとめたいと思ってます。
    備考
    表紙イラスト：Loose Drawing
    
 Improve this page
    \ No newline at end of file diff --git a/posts/category/computer-science/index.html b/posts/category/computer-science/index.html index a55a4288..9032251d 100644 --- a/posts/category/computer-science/index.html +++ b/posts/category/computer-science/index.html @@ -7,7 +7,7 @@
    -
    Hero Image
    スレッドと並行処理

    はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。 +

    Hero Image
    スレッドと並行処理

    はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。 スレッド プロセスが最低１つは持っている実行単位のことです。 こんな言い方をするのは、プロセスが複数のスレッドを管理できるからです。 実行単位という視点でプロセスとの違いは、「アドレス空間」を共有できるという点です。 @@ -86,5 +86,5 @@ 子プロセスの fork 実行時の戻り値は 0 です。 (戻り値 0 は正常終了のステータスコード)そして親プロセスの fork 実行時の戻り値は子プロセスのプロセス ID です。

    Sunday, July 5, 2020 Read
    \ No newline at end of file diff --git a/posts/category/development/2020/08/agile-software-development/index.html b/posts/category/development/2020/08/agile-software-development/index.html index 35ae5850..86e59bdb 100644 --- a/posts/category/development/2020/08/agile-software-development/index.html +++ b/posts/category/development/2020/08/agile-software-development/index.html @@ -47,7 +47,7 @@
    -
    Author Image

    Friday, June 5, 2020

    アジャイル開発

    はじめに

    バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。

    アジャイル開発

    「アジャイル開発」っていうとなんかカッコいいしモダンっぽいというイメージをおそらく持っている人もいるでしょう。(私を含めて)

    逆に「ウォーターフォール開発」はなんか古臭いし、どこぞの金融系ぷ r、、おっと誰か来たみたいなのでこの辺で。

    とまあ、もてはやされたアジャイル開発ですが、フタを開けてみれば「要件定義 → 設計 → 実装 → テスト」の全工程を１つの単位として反復するという手法なのです。

    反復する期間はチームやプロジェクトによってまちまちですが、1 週間〜4 週間ほどです。

    ってことはですよ、V 字モデルのウォーターフォールを短いスパンで回してるだけ？、、それウォーターフォールじゃねぇか！！

    、、というヤジも分からなくはありませんが、ちゃんとメリットがあります。

    メリット

    1. スピーディー(早い)

    だってそうですよね。ウォーターフォールでは全工程を段階的に進めていくのでリリースまでに時間がかかってしまいます。

    対してアジャイルでは前工程を１つのサイクルとして反復するのでリリースまでの期間が短く済みます。

    2. やすい(安い ×)

    しかもアジャイルは、開発サイクルが短い分、仕様変更や追加機能の対応がしやすいというのもあります。

    ウォーターフォールだと、段階的に進めるので、１つの仕様変更があった場合、工程を戻すことになり、、おぉ、、考えただけでも恐ろしいですね。

    3. ユーザーファースト(うまい?)

    これも納得ですね。

    リリースが早い分、クライアント(ユーザー)に効率よく素早く提供できる → クライアント喜ぶ → 褒められる → 嬉しい=うまい?

    (これは数合わせです)

    アジャイル開発の手法

    手法は以下の３つです。

    • スクラム
    • エクストリームプログラミング
    • ユーザ機能駆動開発

    この中で私が経験したのは、スクラムのみです。(2020/07 時点)

    どのサイトでも言われている通り、この開発手法ではメンバーとのコミュニケーションが非常に重要です。

    そのイテレーション(スプリント)でリリースする機能も複数人が関わっていたり、メンバー間での連携が必要な機能だったり。。

    極めつけは１つのアプリの全機能を全メンバーが把握しているのがヨシとされるので、知らない機能は教えたり教わったりしないといけないからです。(これは私のチームだけなのかは知りませんが)

    まとめ

    、、とすごく大変そうに見えますが(実際に大変ですが)、スクラムならではの団体戦みのある開発でまあうまく回せるんではないでしょうかというのが感想です。

    備考

    表紙イラスト：Loose Drawing

    +
    Author Image

    Friday, June 5, 2020

    アジャイル開発

    はじめに

    バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。

    アジャイル開発

    「アジャイル開発」っていうとなんかカッコいいしモダンっぽいというイメージをおそらく持っている人もいるでしょう。(私を含めて)

    逆に「ウォーターフォール開発」はなんか古臭いし、どこぞの金融系ぷ r、、おっと誰か来たみたいなのでこの辺で。

    とまあ、もてはやされたアジャイル開発ですが、フタを開けてみれば「要件定義 → 設計 → 実装 → テスト」の全工程を１つの単位として反復するという手法なのです。

    反復する期間はチームやプロジェクトによってまちまちですが、1 週間〜4 週間ほどです。

    ってことはですよ、V 字モデルのウォーターフォールを短いスパンで回してるだけ？、、それウォーターフォールじゃねぇか！！

    、、というヤジも分からなくはありませんが、ちゃんとメリットがあります。

    メリット

    1. スピーディー(早い)

    だってそうですよね。ウォーターフォールでは全工程を段階的に進めていくのでリリースまでに時間がかかってしまいます。

    対してアジャイルでは前工程を１つのサイクルとして反復するのでリリースまでの期間が短く済みます。

    2. やすい(安い ×)

    しかもアジャイルは、開発サイクルが短い分、仕様変更や追加機能の対応がしやすいというのもあります。

    ウォーターフォールだと、段階的に進めるので、１つの仕様変更があった場合、工程を戻すことになり、、おぉ、、考えただけでも恐ろしいですね。

    3. ユーザーファースト(うまい?)

    これも納得ですね。

    リリースが早い分、クライアント(ユーザー)に効率よく素早く提供できる → クライアント喜ぶ → 褒められる → 嬉しい=うまい?

    (これは数合わせです)

    アジャイル開発の手法

    手法は以下の３つです。

    • スクラム
    • エクストリームプログラミング
    • ユーザ機能駆動開発

    この中で私が経験したのは、スクラムのみです。(2020/07 時点)

    どのサイトでも言われている通り、この開発手法ではメンバーとのコミュニケーションが非常に重要です。

    そのイテレーション(スプリント)でリリースする機能も複数人が関わっていたり、メンバー間での連携が必要な機能だったり。。

    極めつけは１つのアプリの全機能を全メンバーが把握しているのがヨシとされるので、知らない機能は教えたり教わったりしないといけないからです。(これは私のチームだけなのかは知りませんが)

    まとめ

    、、とすごく大変そうに見えますが(実際に大変ですが)、スクラムならではの団体戦みのある開発でまあうまく回せるんではないでしょうかというのが感想です。

    備考

    表紙イラスト：Loose Drawing

    Improve this page
    \ No newline at end of file diff --git a/posts/category/development/2021/03/pragmatic-programmer/index.html b/posts/category/development/2021/03/pragmatic-programmer/index.html index 540d8e68..d04e9232 100644 --- a/posts/category/development/2021/03/pragmatic-programmer/index.html +++ b/posts/category/development/2021/03/pragmatic-programmer/index.html @@ -75,7 +75,7 @@
    -
    Author Image

    Friday, March 5, 2021

    達人プログラマーとは

    はじめに

    エンジニアとしてコードを書くようになって、もうすぐ２年というタイミングに差し掛かりました

    心境の変化としては、がむしゃらに毎日のタスクを通して「動く」コードを書くことから、メンテナンスしやすいコードを意識することが多くなりました

    「達人プログラマー」は、プログラマとして次のステップを踏み出そうというときにベストな一冊となっています

    達人の哲学

    ソフトウェアのエントロピーの話は心当たりがありすぎた

    エントロピー とは、物理学の用語で「ある系における無秩序の度合い」のことで、 +

    Author Image

    Friday, March 5, 2021

    達人プログラマーとは

    はじめに

    エンジニアとしてコードを書くようになって、もうすぐ２年というタイミングに差し掛かりました

    心境の変化としては、がむしゃらに毎日のタスクを通して「動く」コードを書くことから、メンテナンスしやすいコードを意識することが多くなりました

    「達人プログラマー」は、プログラマとして次のステップを踏み出そうというときにベストな一冊となっています

    達人の哲学

    ソフトウェアのエントロピーの話は心当たりがありすぎた

    エントロピー とは、物理学の用語で「ある系における無秩序の度合い」のことで、 時間が経つたびにエントロピーは増大していく

    ソフトウェアも同様に、時間が経つたびに無秩序になっていく

    これを 割れ窓理論 というメカニズムで説明していたのもわかりやすかった

    窓が１枚割れているのを長期間放置しておくと、それをメンテナンスする気力もなくなるマインドが 植え付けられて、最終的には建物全体が破壊されていく

    ソフトウェアではこれを、悪い設計、誤った意思決定、質の悪いコードに見立てることができて、 放置しておくと潜在的なバグを生み出すことになりかねない

    こういった「割れた窓」を発見したと同時に速やかに修復するべきだ、そして時間がなくてもコメントを @@ -94,5 +94,5 @@ テストを実行しているときではない

    → テストを契約と見做せば重要度とモチベーションの変化になるのではないか

    象を一頭食べるにはどうすれば良いか

    → 一口ずつ食べる ←大事!!

    明確な目的地を心に描けてなかった場合、どのような方法論であっても 堂々巡りになってしまう可能性がある。 ←泣

    プロジェクトを始める前に

    ひとりぼっちでコーディングに取り組んではいけない

    達人のプロジェクト

    猫の群れを飼い慣らすことに匹敵するほど、優秀なプログラマーをまとめるのは難しい

    50 人はチームとは言わずに「群れ」といった方がしっくりくる

    事を成し遂げるにはまずスケジュールする

    カーゴカルト的な手法は、開発においてもテストやツールにおいても危険

    ユーザーが必要としたタイミングで調達すること

    早めにテスト、何度もテスト、自動でテスト

    まとめ

    このタイミングで１周できたのは幸運でした。

    折に触れてて再読したいと思います。

    備考

    表紙イラスト：Loose Drawing

    Improve this page
    \ No newline at end of file diff --git a/posts/category/development/index.html b/posts/category/development/index.html index ece9ed39..c925058e 100644 --- a/posts/category/development/index.html +++ b/posts/category/development/index.html @@ -7,7 +7,7 @@
    -
    Hero Image
    達人プログラマーとは

    はじめに エンジニアとしてコードを書くようになって、もうすぐ２年というタイミングに差し掛かりました +

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

    はじめに エンジニアとしてコードを書くようになって、もうすぐ２年というタイミングに差し掛かりました 心境の変化としては、がむしゃらに毎日のタスクを通して「動く」コードを書くことから、メンテナンスしやすいコードを意識することが多くなりました 「達人プログラマー」は、プログラマとして次のステップを踏み出そうというときにベストな一冊となっています 達人の哲学 ソフトウェアのエントロピーの話は心当たりがありすぎた @@ -64,5 +64,5 @@ まとめ 、、とすごく大変そうに見えますが(実際に大変ですが)、スクラムならではの団体戦みのある開発でまあうまく回せるんではないでしょうかというのが感想です。 備考 表紙イラスト：Loose Drawing

    Friday, June 5, 2020 Read
    \ No newline at end of file diff --git a/posts/category/go/2020/07/compare-sort-aligorithm/index.html b/posts/category/go/2020/07/compare-sort-aligorithm/index.html index f6af26f5..ca786a86 100644 --- a/posts/category/go/2020/07/compare-sort-aligorithm/index.html +++ b/posts/category/go/2020/07/compare-sort-aligorithm/index.html @@ -17,7 +17,7 @@
    -
    Author Image

    Sunday, July 5, 2020

    ソートアルゴリズムをGoで実装してみた

    はじめに

    バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。

    マージソート

    マージソートは、ソートのアルゴリズムで、既に整列してある複数個の列を 1 個の列にマージする際に、小さいものから先に新しい列に並べれば、新しい列も整列されている、というボトムアップの分割統治法による。大きい列を多数の列に分割し、そのそれぞれをマージする作業は並列化できる。

    出典：wikipedia「マージソート」より引用

    最悪の計算量が O(n log n) であるから少なくとも O(n^2)よりは速いんだろうなという印象（雑すぎるか）

    以下「ソートを極める！ 〜 なぜソートを学ぶのか 〜」を元に実装してみた（なるべくソースを見ないで実装を試みたがマージする箇所は折れた、、）

    package main
+
    Author Image
    Sunday, July 5, 2020
    ソートアルゴリズムをGoで実装してみた
    はじめに
    バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。
    マージソート
    マージソートは、ソートのアルゴリズムで、既に整列してある複数個の列を 1 個の列にマージする際に、小さいものから先に新しい列に並べれば、新しい列も整列されている、というボトムアップの分割統治法による。大きい列を多数の列に分割し、そのそれぞれをマージする作業は並列化できる。
    出典：wikipedia「マージソート」より引用
    最悪の計算量が O(n log n) であるから少なくとも O(n^2)よりは速いんだろうなという印象（雑すぎるか）
    以下「ソートを極める！ 〜 なぜソートを学ぶのか 〜」を元に実装してみた（なるべくソースを見ないで実装を試みたがマージする箇所は折れた、、）
    package main
 
 import (
 "fmt"
@@ -116,5 +116,5 @@
 }
 
    こっちは実装もしやすく理解するのも難しくないという印象。最終的にはどちらもソートするというのにこの差は、、と思ってしまう。
    速度比較
    今回はソートアルゴリズムの実装がメインだったけど、２つあるなら比較するまでがアウトプットだろうなと感じたので比較します。
    マシンスペック
    • OS: macOS Catalina
    • プロセッサ: 1.6 GHz(Core i5)
    • メモリ: 16 GB
    実施方法
    要素数 n 個のスライスのソート時間を比較する。要素はそれぞれランダムになっている。
    結果
    要素数(n)マージソート(O(n log n)(sec)挿入ソート(O(n^2)(sec)
    1,0000.0003570.000277
    10,0000.0050020.024778
    100,0000.0367051.524296
    1,000,0000.341336-
    ※挿入ソート（1,000,000）は 1 分以上かかったので省略
    要素が倍になるほどマージソートの速さがわかりますね。
    このページのソースは GitHub にもあります。
    ソートアルゴリズムの比較
    余談
    アルゴリズムを１ヶ月で把握しようとしてましたがソートアルゴリズムの雰囲気を掴むだけでそれくらい時間かかりました、、
    １つずつ精進ですね。。
    
 Improve this page
    \ No newline at end of file diff --git a/posts/category/go/2020/07/spherical-trigonometry/index.html b/posts/category/go/2020/07/spherical-trigonometry/index.html index 608e2892..52e9067c 100644 --- a/posts/category/go/2020/07/spherical-trigonometry/index.html +++ b/posts/category/go/2020/07/spherical-trigonometry/index.html @@ -27,7 +27,7 @@
    -
    Author Image

    Monday, July 6, 2020

    球面三角法による２点間の距離計算をGoで実装してみた

    はじめに

    バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。

    地球上の２点間の距離計算ってアプリだと Google Map API を使えば完了！だと思いますが、どう計算してるかって気になりますよね？

    今回は球面三角法を利用した地球上の２点間の距離計算を Go で実装します。（調べたらフツーにあるんですが）

    球面三角法とは

    その名の通り、三角関数を利用して球面上の辺や角の大きさを導出するものです。平面と球面とでの違いは辺の大きさが +

    Author Image

    Monday, July 6, 2020

    球面三角法による２点間の距離計算をGoで実装してみた

    はじめに

    バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。

    地球上の２点間の距離計算ってアプリだと Google Map API を使えば完了！だと思いますが、どう計算してるかって気になりますよね？

    今回は球面三角法を利用した地球上の２点間の距離計算を Go で実装します。（調べたらフツーにあるんですが）

    球面三角法とは

    その名の通り、三角関数を利用して球面上の辺や角の大きさを導出するものです。平面と球面とでの違いは辺の大きさが 球面では中心角によって表されることにあります。

    よって、球面三角法を使用して算出した弧の長さ(中心角)と赤道の半径を乗算すると距離が求まります。

    球面三角法の証明については、球面三角形の定理を参考にしました！

    (“高校生に向けて"とある通り、非常にわかりやすかったです)

    球面三角法の余弦定理を利用して実際に距離を算出する方法は球面三角法の余弦定理がわかりやすいです。

    実装

    実装したソースコードは Github でも確認できます。

    球面三角法を利用した２点間の距離計算

    package main
 
 import "math"
@@ -60,5 +60,5 @@
 }

    動かしてみる

    それでは実装した Go の関数を呼び出す簡単なアプリを動かしていきます。

    ※今回使用するアプリも Github 上の同じディレクトリにあるのでビルドすると使用できます。

    アプリの挙動としては、

    1. 2 点間の緯度経度情報を取得する（取得するために外部 APIを利用します）
    2. 1 で取得した２点の緯度経度情報を今回実装した距離計算の関数へ渡して算出する

    比較するためにこちらのサイトを利用します。

    結果

    場所比較サイト今回のアプリ
    西東京市 ~ 大阪市都島区383.344422383.3444215569602
    札幌市厚別区　~ 沖縄市2,231.3182342231.3182342761

    ※地球上の半径 r は 6378.140km にしています。

    。。。同じになってしまいました。。比較とはなんだったんだろう

    まあよく捉えると、比較サイトのような便利計算サイトと同等?のものが作れたということでしょうか。

    余談

    久しぶりに証明を見たり計算を手で追っていく作業をしたので懐かしい気持ちになりました。

    普段の業務でそこまで計算式を使わない分、こう自発的に調べて実装するのも楽しいと思いました。

    Improve this page
    \ No newline at end of file diff --git a/posts/category/go/2022/12/kyash-advent-calendar/index.html b/posts/category/go/2022/12/kyash-advent-calendar/index.html index e45fdde3..4321257a 100644 --- a/posts/category/go/2022/12/kyash-advent-calendar/index.html +++ b/posts/category/go/2022/12/kyash-advent-calendar/index.html @@ -25,7 +25,7 @@
    -
    Author Image

    Tuesday, December 13, 2022

    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インターフェースに定義されているメソッドで、一時的なエラーかどうか判定するために用意されています。 +

    Author Image

    Tuesday, December 13, 2022

    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.
@@ -78,5 +78,5 @@
 	}

    さいごに

    Temporary()で判定したいようなケースはなるべくさけて代替のエラーを見つけるのがよさそうですね

    学びとしては、非推奨になったきっかけの issue を読んでみて、標準パッケージを読むことに対する抵抗が少しなくなったような気がしたことです💦

    Improve this page
    \ No newline at end of file diff --git a/posts/category/go/2022/12/qiita-advent-calender/index.html b/posts/category/go/2022/12/qiita-advent-calender/index.html index c38248ef..a96357af 100644 --- a/posts/category/go/2022/12/qiita-advent-calender/index.html +++ b/posts/category/go/2022/12/qiita-advent-calender/index.html @@ -31,7 +31,7 @@
    -
    Author Image

    Saturday, December 10, 2022

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

    はじめに

    @uh-zzです！

    この記事は、Go Advent Calendar 2022の 10 日目の記事になります！

    今年は、個人的に色々なことに挑戦した年だったなあと振り返るとともに、去年のアドベントカレンダーからもう１年経つのか〜という気持ちです

    この記事では、Go における Future パターンをご紹介できればと思います

    Future パターンとは

    あるメソッドを呼び出すとします。 もしもオブジェクトが、そのメソッドを実行できる状態なら、実行します。 でも、実行できない状態なら、将来実行できる状態になるまで待つようにしたいとします。 その時に使えるのがこの Future パターンです。 future は「未来」という意味です

    もう少し正確にお話しましょう。 単にあるクラスに 「実行できる状態になるまで待つ」 という機能を入れるわけではありません。 すでに存在しているクラスに一皮かぶせて、 「実行できる状態になるまで待てるような機能を追加する」 というのが Future パターンです。

    出典: 結城浩, Future パターン, デザインパターン紹介

    上記の参考記事内では、Java をつかったマルチスレッドプログラミングで Future パターンが実装されています。

    引用箇所の説明がほぼすべてですが、イメージ図で補足するとこんな感じになります

    flowchart LR
+
    Author Image
    Saturday, December 10, 2022
    Futureパターンが使われているOSSを見てみた
    はじめに
    @uh-zzです！
    この記事は、Go Advent Calendar 2022の 10 日目の記事になります！
    今年は、個人的に色々なことに挑戦した年だったなあと振り返るとともに、去年のアドベントカレンダーからもう１年経つのか〜という気持ちです
    この記事では、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
 
@@ -93,5 +93,5 @@
 main 関数だけ見ると、呼び出し側では同期的に見えますが、内部でチャネルによる非同期処理が行われています。
    実際に使われているところを深ぼってみた
    https://github.com/hashicorp/raft
    Error()の実装はここ
 https://github.com/hashicorp/raft/blob/6b4e32088e0bda22ea219fc89b0ee47f420e2b0b/future.go#L168
    raft の apply だけを深堀りしてみるのもいいかもしれない
    おわりに
    Future パターンを取り上げてみましたが、蓋を開けてみるとチャネルを使った並行プログラミングでよく目にするような処理に、”名前がついてたんだ〜！”と思う方もいるでしょう（私のことです）
    パターンを知る → 使っている OSS を見にいく流れは体験としていいなと思ったので、来年も引き続きやっていきます👋
    
 Improve this page
    \ No newline at end of file diff --git a/posts/category/go/index.html b/posts/category/go/index.html index 79875001..fcab5b1f 100644 --- a/posts/category/go/index.html +++ b/posts/category/go/index.html @@ -7,7 +7,7 @@
    -
    Hero Image
    netパッケージで非推奨のTemporaryメソッドの扱いについて

    はじめに こちらはKyash Advent Calendar 2022 の 13 日目の記事です。 +

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

    はじめに こちらはKyash Advent Calendar 2022 の 13 日目の記事です。 今年の 11 月に Kyash に入社しました！サーバサイドチームのueharaです👋 今回はnet/httpパッケージの非推奨メソッドであるTemporary()について、社のメンバーから知見を共有してもらったのでその話をします。 net/http パッケージの 非推奨メソッド Temporary() について Temporary()については、フューチャー社の記事にわかりやすくまとめられています。 @@ -48,5 +48,5 @@ 以下「ソートを極める！ 〜 なぜソートを学ぶのか 〜」を元に実装してみた（なるべくソースを見ないで実装を試みたがマージする箇所は折れた、、） package main import ( "fmt" "time" "github.com/uh-zz/traning/algorithm/shuffle" ) func main() { // ランダムな要素 n 個のスライス取得 input := shuffle.RandomIntList(n) inputLength := len(input) // マージソート MergeSort(&input, 0, inputLength) } // MergeSort マージソート func MergeSort(input \*[]int, left, right int) { // 要素数1つの場合は抜ける if right-left == 1 { return } // 配列を２つに分けるインデックス middle := left + (right-left)/2 // 配列左側 MergeSort(input, left, middle) // 配列右側 MergeSort(input, middle, right) var buffer []int // 左側と右側をバッファにためる（右側反転） for index := left; index < middle; index++ { buffer = append(buffer, (*input)[index]) } for index := right - 1; index >= middle; index-- { buffer = append(buffer, (*input)[index]) } // マージする scopeLeft := 0 scopeRight := len(buffer) - 1 for index := left; index < right; index++ { if buffer[scopeLeft] <= buffer[scopeRight] { // 左側採用 (*input)[index] = buffer[scopeLeft] scopeLeft++ } else { // 右側採用 (*input)[index] = buffer[scopeRight] scopeRight-- } } } これ考えたのぶっ飛んでるなあと思って Wikipedia 見てたら、考案者がフォン・ノイマンでやっぱりぶっ飛んでた（凄すぎ）

    Sunday, July 5, 2020 Read
    \ No newline at end of file diff --git a/posts/category/index.html b/posts/category/index.html index 2076e931..90b9fc9e 100644 --- a/posts/category/index.html +++ b/posts/category/index.html @@ -7,7 +7,7 @@
    -
    Hero Image
    2022年の振り返り

    はじめに １年経つのは早いですね。 +

    Hero Image
    2022年の振り返り

    はじめに １年経つのは早いですね。 今年のサマリーとしては、通信大学へ入学したことと転職したこと、です。 去年はこのブログの投稿を増やしていくと意気込んでいましたが実績は、、意気込みは大事なので来年も意気込んでいきます💪 振り返りについては需要の有無に関わらず書いていきたいと思ってる所存です。 @@ -64,7 +64,7 @@ 節目というか、ちょっと時間ができたので、私が履修している科目一覧を Notion で管理しようと思い立ち、さくっと作ってみました。 科目一覧 - Notion これから同じように学習される方の参考になれば幸いです。（私も諸先輩方のブログを見て、参考になったので恩返しできれば！） -近況 元気にやっています:pduck_b: +近況 元気にやっています👋 備考 表紙イラスト：Loose Drawing

    Sunday, September 4, 2022 Read
    Hero Image
    2022年07月に読んだ記事とか本とか

    はじめに 読んだ記事とか本のリンクを張っておきます 読んだ記事 アーキテクトに求められるマインドとは / mindset for an architect @@ -224,5 +224,5 @@ 備考 現場で役立つシステム設計の原則 表紙イラスト：Loose Drawing

    Saturday, December 5, 2020 Read
    \ No newline at end of file diff --git a/posts/category/index.xml b/posts/category/index.xml index af5b2cf4..94aa96bf 100644 --- a/posts/category/index.xml +++ b/posts/category/index.xml @@ -52,7 +52,7 @@ package main func readFile(path string) chan string { // ファイルを読み 節目というか、ちょっと時間ができたので、私が履修している科目一覧を Notion で管理しようと思い立ち、さくっと作ってみました。 科目一覧 - Notion これから同じように学習される方の参考になれば幸いです。（私も諸先輩方のブログを見て、参考になったので恩返しできれば！） -近況 元気にやっています:pduck_b: +近況 元気にやっています&#x1f44b; 備考 表紙イラスト：Loose Drawing2022年07月に読んだ記事とか本とかhttps://uh-zz.github.io/posts/category/inputs/2022/07/Tue, 05 Jul 2022 18:07:06 +0900https://uh-zz.github.io/posts/category/inputs/2022/07/はじめに 読んだ記事とか本のリンクを張っておきます 読んだ記事 アーキテクトに求められるマインドとは / mindset for an architect 「少なくとも、最悪ではないアーキテクチャを狙う」 diff --git a/posts/category/inputs/2022/07/index.html b/posts/category/inputs/2022/07/index.html index fade56a4..94ecbe51 100644 --- a/posts/category/inputs/2022/07/index.html +++ b/posts/category/inputs/2022/07/index.html @@ -41,7 +41,7 @@
    -
    Author Image

    Tuesday, July 5, 2022

    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 (著), 武舎広幸 (翻訳), 武舎るみ (翻訳)

    JABEE 対応 技術者倫理入門-小出 泰士(著)

    やさしく学べる基礎物理-基礎物理教育研究会(編集)

    星の王子さま-サン=テグジュペリ(著)

    +
    Author Image

    Tuesday, July 5, 2022

    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 (著), 武舎広幸 (翻訳), 武舎るみ (翻訳)

    JABEE 対応 技術者倫理入門-小出 泰士(著)

    やさしく学べる基礎物理-基礎物理教育研究会(編集)

    星の王子さま-サン=テグジュペリ(著)

    Improve this page
    \ No newline at end of file diff --git a/posts/category/inputs/index.html b/posts/category/inputs/index.html index fc3ba14e..444091ed 100644 --- a/posts/category/inputs/index.html +++ b/posts/category/inputs/index.html @@ -7,7 +7,7 @@
    -
    Hero Image
    2022年07月に読んだ記事とか本とか

    はじめに 読んだ記事とか本のリンクを張っておきます +

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

    はじめに 読んだ記事とか本のリンクを張っておきます 読んだ記事 アーキテクトに求められるマインドとは / mindset for an architect 「少なくとも、最悪ではないアーキテクチャを狙う」 自分の中で新しい視点だった(常に選択肢の中で(世間的に)最善とされているものがいいという思考をしてる) @@ -26,5 +26,5 @@ 読んだ本 自分に気づく心理学-加藤 諦三(著) Lean と DevOps の科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (impress top gear)-Nicole Forsgren Ph.D. (著), Jez Humble (著), Gene Kim (著), 武舎広幸 (翻訳), 武舎るみ (翻訳)

    Tuesday, July 5, 2022 Read
    \ No newline at end of file diff --git a/posts/category/look-back-on/2021/index.html b/posts/category/look-back-on/2021/index.html index 2e0e064e..be7cc8da 100644 --- a/posts/category/look-back-on/2021/index.html +++ b/posts/category/look-back-on/2021/index.html @@ -7,7 +7,7 @@
    -
    Author Image

    Friday, December 31, 2021

    2021年の振り返り

    はじめに

    今年のふりかえりをするために個人ブログを数ヶ月ぶりに更新しています。

    しばらくぶりに拙ブログを見ていて、ぜんぜんメンテしてなかったや。。の反省を強く感じたので来年はアウトプットをもっともっと増やします！

    2021/01

    とくに話すトピックはありませんでした。

    読んでた本

    2021/02

    とくに話すトピックはありませんでした。

    読んでた本

    2021/03

    このころから年内に引っ越しを考えはじめました。

    部屋に不満はありませんでしたが、ぼんやりと中央線沿い(=東京の西側)がかっこいいというイメージをもっていたので一人でちょくちょく出向いていました。

    主に、杉並区エリア(中野/高円寺/阿佐ヶ谷/荻窪)を中心にまわっていました。

    特に、荻窪にある杉並アニメーションミュージアムは、展示も楽しく見れますが、ミュージアムが入っている杉並会館の雰囲気が抜群にいいのでおすすめです。

    2021/04

    転職しました。社会人４年目にして３社目になります。

    前職と同じくサーバーサイドのポジションです。

    前職では、コロナ以降フルリモートでしたが、転職後は週３出社になりました。

    出社になってからは、ランチをメンバーと取るようになり、コミュニケーションが増えたのがメリットに感じました。

    仕事に関して前職では主に、Java/Go/Node.js での開発を２年ほどしていましたが、転職直後は Ruby on Rails での開発がメインになりました。

    はじめての Ruby と Rails ということもあり、メンバーにはだいぶお世話になりながらも、プライベートではおすすめの参考書をかたっぱしから読む生活をしていました。

    読んでた本

    2021/05

    緊急事態宣言の期間に入り、ほぼフルリモートになりました。

    この頃のコミットを見てみると、主に Rails プロジェクトでのバグフィックスや、小さな機能追加をしていました。

    (レビューでいろいろ教えてくれたメンバーには感謝です 💦)

    コードレビューに関して前職ではほぼ対面レビューだったのに対して、転職してからは Github 上でのレビューに切り替わったことで、レビュアー以外のメンバーにも非同期的にチェックしてもらえたのがすごくよかったです。

    2021/06

    コミットを見てみると、この頃に担当したタスクにだいぶ時間を割いていました。

    というのも、タスクを進める上で発生した海外担当者とのメールであくせくしていた思い出があります。

    慣れない英語メールのやり取りが長引いてしまったものの、説明するのに必要なドメイン知識の理解がだいぶ進んだので、トレードオフだったのかなあと後になって感じています。

    読んでた本

    2021/07

    この月から、「プログラミング言語 Go」オンライン読書会に参加するようになりました。

    月に 1 度の読書会ですが、毎回新しい発見があって楽しいです。

    プライベートではそろそろ引っ越しをしようと suumo を見ていて、何件かピックアップして不動産に行きました。

    ピックアップした物件ではなかったものの、ちょうどその日に空いた物件を一番乗りで見に行くことになり、初日で即決しました。

    当初の予定通り、中央線沿いに決まったのでこの頃は浮かれていました。

    2021/08

    社外のオンライン LTに参加したりしました。

    2021/09

    この頃のコミットを見ると、社内での Go プロジェクトへのコミットが少しずつ増えてきました。

    プライベートでは、一人散歩でよく歩いてました。

    よかったコース

    読んだ本

    2021/10

    この頃、ようやく緊急事態宣言が解除されました。

    開発合宿があり、LTなどしました。

    プライベートでは、hacktoberfestに参加したりしました。

    初参加かつ、OSS も初めてではありましたが、コミットできそうなリポジトリに５つプルリクエストを出しました。

    T シャツ獲得！の要件を満たしたので現在、発送待ちです。（届いたらツイートします）

    2021/11

    Go Conference 2021 Autumnにボランティアスタッフで参加させていただきました。

    パートナーやスタッフに、社のロゴや twitter アカウントを載せてもらえたのは感無量でした。

    (運営の方ありがとうございます！)

    来年は、もっともっと関わっていくぞ〜の気持ちになりました。

    読んだ本

    2021/12

    Go に対する機運が社内でも高まってきました。(有志で勉強会を開くようになりました。)

    また、個人的にGo アドベントカレンダーにも初参加してみました。

    読んだ本

    まとめ

    今年は、転職＆引っ越しと、いろいろ変化の多い年でした。

    あと、少しずつ社外のイベント/コミュニティにも参加できるようになってきました。

    来年は、アウトプットを増やして、社と私の認知度を上げていくのを目標にします。

    （コミュニティ活動も積極的に参加していくぞ〜！！）

    備考

    表紙イラスト：Loose Drawing

    +
    Author Image

    Friday, December 31, 2021

    2021年の振り返り

    はじめに

    今年のふりかえりをするために個人ブログを数ヶ月ぶりに更新しています。

    しばらくぶりに拙ブログを見ていて、ぜんぜんメンテしてなかったや。。の反省を強く感じたので来年はアウトプットをもっともっと増やします！

    2021/01

    とくに話すトピックはありませんでした。

    読んでた本

    2021/02

    とくに話すトピックはありませんでした。

    読んでた本

    2021/03

    このころから年内に引っ越しを考えはじめました。

    部屋に不満はありませんでしたが、ぼんやりと中央線沿い(=東京の西側)がかっこいいというイメージをもっていたので一人でちょくちょく出向いていました。

    主に、杉並区エリア(中野/高円寺/阿佐ヶ谷/荻窪)を中心にまわっていました。

    特に、荻窪にある杉並アニメーションミュージアムは、展示も楽しく見れますが、ミュージアムが入っている杉並会館の雰囲気が抜群にいいのでおすすめです。

    2021/04

    転職しました。社会人４年目にして３社目になります。

    前職と同じくサーバーサイドのポジションです。

    前職では、コロナ以降フルリモートでしたが、転職後は週３出社になりました。

    出社になってからは、ランチをメンバーと取るようになり、コミュニケーションが増えたのがメリットに感じました。

    仕事に関して前職では主に、Java/Go/Node.js での開発を２年ほどしていましたが、転職直後は Ruby on Rails での開発がメインになりました。

    はじめての Ruby と Rails ということもあり、メンバーにはだいぶお世話になりながらも、プライベートではおすすめの参考書をかたっぱしから読む生活をしていました。

    読んでた本

    2021/05

    緊急事態宣言の期間に入り、ほぼフルリモートになりました。

    この頃のコミットを見てみると、主に Rails プロジェクトでのバグフィックスや、小さな機能追加をしていました。

    (レビューでいろいろ教えてくれたメンバーには感謝です 💦)

    コードレビューに関して前職ではほぼ対面レビューだったのに対して、転職してからは Github 上でのレビューに切り替わったことで、レビュアー以外のメンバーにも非同期的にチェックしてもらえたのがすごくよかったです。

    2021/06

    コミットを見てみると、この頃に担当したタスクにだいぶ時間を割いていました。

    というのも、タスクを進める上で発生した海外担当者とのメールであくせくしていた思い出があります。

    慣れない英語メールのやり取りが長引いてしまったものの、説明するのに必要なドメイン知識の理解がだいぶ進んだので、トレードオフだったのかなあと後になって感じています。

    読んでた本

    2021/07

    この月から、「プログラミング言語 Go」オンライン読書会に参加するようになりました。

    月に 1 度の読書会ですが、毎回新しい発見があって楽しいです。

    プライベートではそろそろ引っ越しをしようと suumo を見ていて、何件かピックアップして不動産に行きました。

    ピックアップした物件ではなかったものの、ちょうどその日に空いた物件を一番乗りで見に行くことになり、初日で即決しました。

    当初の予定通り、中央線沿いに決まったのでこの頃は浮かれていました。

    2021/08

    社外のオンライン LTに参加したりしました。

    2021/09

    この頃のコミットを見ると、社内での Go プロジェクトへのコミットが少しずつ増えてきました。

    プライベートでは、一人散歩でよく歩いてました。

    よかったコース

    読んだ本

    2021/10

    この頃、ようやく緊急事態宣言が解除されました。

    開発合宿があり、LTなどしました。

    プライベートでは、hacktoberfestに参加したりしました。

    初参加かつ、OSS も初めてではありましたが、コミットできそうなリポジトリに５つプルリクエストを出しました。

    T シャツ獲得！の要件を満たしたので現在、発送待ちです。（届いたらツイートします）

    2021/11

    Go Conference 2021 Autumnにボランティアスタッフで参加させていただきました。

    パートナーやスタッフに、社のロゴや twitter アカウントを載せてもらえたのは感無量でした。

    (運営の方ありがとうございます！)

    来年は、もっともっと関わっていくぞ〜の気持ちになりました。

    読んだ本

    2021/12

    Go に対する機運が社内でも高まってきました。(有志で勉強会を開くようになりました。)

    また、個人的にGo アドベントカレンダーにも初参加してみました。

    読んだ本

    まとめ

    今年は、転職＆引っ越しと、いろいろ変化の多い年でした。

    あと、少しずつ社外のイベント/コミュニティにも参加できるようになってきました。

    来年は、アウトプットを増やして、社と私の認知度を上げていくのを目標にします。

    （コミュニティ活動も積極的に参加していくぞ〜！！）

    備考

    表紙イラスト：Loose Drawing

    Improve this page
    \ No newline at end of file diff --git a/posts/category/look-back-on/2022/05/31/go-to-the-teikyo-university/index.html b/posts/category/look-back-on/2022/05/31/go-to-the-teikyo-university/index.html index 4b939585..fe431e82 100644 --- a/posts/category/look-back-on/2022/05/31/go-to-the-teikyo-university/index.html +++ b/posts/category/look-back-on/2022/05/31/go-to-the-teikyo-university/index.html @@ -7,7 +7,7 @@
    -
    Author Image

    Tuesday, May 31, 2022

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

    はじめに

    表題の通り、今年の 4 月から帝京大学理工学部情報科学科の通信教育課程に 2 年次編入しました。

    そもそもの経緯と入るまでの話、入って 1 ヶ月経過した後の所感をまとめておきたいと思います。

    きっかけ

    大学進学について

    通信制大学へ進学したいと思ったのは今年に入ってからではなく、ここ 2 年くらい検討していました。

    当初は理工系ではなく、社会学/哲学に興味があり、その方面の勉強がしたいと漠然と考えていました。

    ただ 2 年の間、大学への入学を躊躇してたのは以下の理由がありました。

    • 通信制大学の卒業が難しい、また卒業率が低いといった情報を見て腰が重かった
    • 働きながら時間が取れない、平日のフルタイムかつ出社している場合、早朝か、仕事から帰ってきて勉強時間を確保する必要が出てくるので、リモートできないと厳しい
    • とりあえず入門書を買って積んでおけば自分で勉強できるし、進学しなくてもいいのでは？と諦めムードを出していた

    以上の理由から悩んでは忘れるを一人繰り返しては日々を過ごしていました。

    キャリアについて考えるようになった

    そんな中、昨年末に以下の記事を拝見しました。

    生涯現役のソフトウェアエンジニアでありたい。IC（Individual Contributor）のキャリアパスがあると自覚するまで 10 年の軌跡

    IC(Individual Contributor)というキャリアがあるのかというのと、記事中の主張から自分のキャリアについて振り返る様になりました。

    これまでのキャリアは前述のようにかなり行きあたりばったりでしたが、その中にも不動となる主軸が 2 つありました。(中略)

    1 つは「毎日楽しく開発したい」ということ。(中略)

    もう 1 つの軸は「選択肢を常に複数確保する」ことです。(中略)

    この「毎日楽しく開発したい」は、私がエンジニアになりたいと思った動機「楽しく(刺激的に)生きたい」に通じるものがあり、IC というキャリアないしはテクニカルスキルをあげることで自分の幸福につながるのかという気づきがありました。

    遠回りのような近道のような、どちらとも言えないですが、自分で出した答えの１つが大学進学、それもコンピュータに関する学位を取得するということでした。

    ここについては自分の中で消化しきれていない部分もあるので、別の記事で改めて振り返ることにします。

    帝京大学に決めたのはそこまで時間がかからなかった

    フルタイムで働きながらコンピュータに関する学位が取得できる通信制大学は、調べた限りだと選択肢は限られました。

    また、同じくエンジニアとして働きながら勉強されている方のブログが大変参考になりました。

    @gkzvoice さんには twitter でブログに関して質問させていただき、またアドバイスまでいただいたので感謝です。

    入るまでの手続きなど

    詳細な手続きは募集要項にあるので、ここでは所感を述べるだけにします。

    • 調査書、成績表の発行を、所属していた専門学校に依頼する必要があるので、余裕を持って出願する
    • 志望理由を記載する必要があるので、動機と抱負は棚卸ししてたほうがスムーズかも

    2 年次編入について

    今回 2 年次編入で出願することができました。

    というのも、情報系専門学校の 2 年制を卒業しているので、編入の要件を満たしていたからというのが理由です。

    要件を満たしていれば、専門学校での授業内容がまとめられたシラバス？を願書と一緒に提出した後、大学にて専門学校の授業内容から、関連する大学側での科目が履修済みとして、認定されます。

    今回は認定された科目が上限数に達していたので、晴れて編入することができたのでした。

    そして入学しました

    出願から約 2 ヶ月後、晴れて入学式を迎えることができました。

    日本武道館で約 1 時間のコンパクトな式が執り行なわれ、あれよあれよと駅に流れ着き帰宅しました。

    社会人なので、午後からはお仕事しました

    1 ヶ月が経過して

    学生という自覚を少し感じるようになりました。

    ここ数日はレポート期限と授業の多さにやられていてどこか上の空でした。（まだ試験が残っているのでしばらくはこの状態が続きそう）

    今回、履修登録した科目と進捗状況についても別の記事でまとめます。

    まとめ

    通学してないこともあり、社会人大学生になった自覚は正直実感しにくいというのが所感です。

    ただ勉強する習慣ができつつあることや、レポートを通してドキュメンテーションの大切さを日々感じるようにはなりました。

    今後はブログを通して、進捗や所感をアウトプットしていければなとぼんやり考えています。

    本業と学業、どちらも進捗出していくぞ〜

    備考

    表紙イラスト：Loose Drawing

    -Improve this page
    -
    Hero Image
    2022年の振り返り

    はじめに １年経つのは早いですね。 +

    Hero Image
    2022年の振り返り

    はじめに １年経つのは早いですね。 今年のサマリーとしては、通信大学へ入学したことと転職したこと、です。 去年はこのブログの投稿を増やしていくと意気込んでいましたが実績は、、意気込みは大事なので来年も意気込んでいきます💪 振り返りについては需要の有無に関わらず書いていきたいと思ってる所存です。 @@ -41,7 +41,7 @@ 節目というか、ちょっと時間ができたので、私が履修している科目一覧を Notion で管理しようと思い立ち、さくっと作ってみました。 科目一覧 - Notion これから同じように学習される方の参考になれば幸いです。（私も諸先輩方のブログを見て、参考になったので恩返しできれば！） -近況 元気にやっています:pduck_b: +近況 元気にやっています👋 備考 表紙イラスト：Loose Drawing

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

    はじめに 表題の通り、今年の 4 月から帝京大学理工学部情報科学科の通信教育課程に 2 年次編入しました。 そもそもの経緯と入るまでの話、入って 1 ヶ月経過した後の所感をまとめておきたいと思います。 @@ -91,5 +91,5 @@ 2021/05 緊急事態宣言の期間に入り、ほぼフルリモートになりました。 この頃のコミットを見てみると、主に Rails プロジェクトでのバグフィックスや、小さな機能追加をしていました。

    Friday, December 31, 2021 Read
    \ No newline at end of file diff --git a/posts/category/look-back-on/index.xml b/posts/category/look-back-on/index.xml index 5efab36c..b72a634e 100644 --- a/posts/category/look-back-on/index.xml +++ b/posts/category/look-back-on/index.xml @@ -31,7 +31,7 @@ Kyash TechTalk #2 - Serverside のシステム構成とアーキテクチャ 節目というか、ちょっと時間ができたので、私が履修している科目一覧を Notion で管理しようと思い立ち、さくっと作ってみました。 科目一覧 - Notion これから同じように学習される方の参考になれば幸いです。（私も諸先輩方のブログを見て、参考になったので恩返しできれば！） -近況 元気にやっています:pduck_b: +近況 元気にやっています&#x1f44b; 備考 表紙イラスト：Loose Drawing【通信教育課程】帝京大学理工学部情報科学科に編入学しましたhttps://uh-zz.github.io/posts/category/look-back-on/2022/05/31/go-to-the-teikyo-university/Tue, 31 May 2022 18:07:06 +0900https://uh-zz.github.io/posts/category/look-back-on/2022/05/31/go-to-the-teikyo-university/はじめに 表題の通り、今年の 4 月から帝京大学理工学部情報科学科の通信教育課程に 2 年次編入しました。 そもそもの経緯と入るまでの話、入って 1 ヶ月経過した後の所感をまとめておきたいと思います。 きっかけ 大学進学について 通信制大学へ進学したいと思ったのは今年に入ってからではなく、ここ 2 年くらい検討していました。 diff --git a/posts/category/oss/2020/08/semantic-versioning/index.html b/posts/category/oss/2020/08/semantic-versioning/index.html index 4f1cc330..b0d6a946 100644 --- a/posts/category/oss/2020/08/semantic-versioning/index.html +++ b/posts/category/oss/2020/08/semantic-versioning/index.html @@ -23,8 +23,8 @@
    -
    Author Image

    Wednesday, August 5, 2020

    Semantic Versioning

    はじめに

    バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。

    セマンティックバージョニング？

    アプリに振るバージョン番号をSemVerというルールに従って付与しましょうというものです。

    確かにバージョン番号に意味を持たせることで、ユーザからもアプリのバージョン番号が上がればバグ修正なのか機能追加なのかわかりますし、プログラムからも互換性を考慮して処理を分けることができるのでよいですね。

    これだけ覚えておけば OK

    バージョン番号の形式は、メジャー.マイナー.パッチです。(例：1.0.0)

    メジャー

    • 後方互換性がない変更があった時にはこの番号を上げなければいけません(MUST)
    • この番号を上げた際には、マイナー/パッチの番号は 0 にリセットしなければいけません(MUST)
    • この番号が「0」の場合は初期開発用として扱います。リリースの段階でこの番号を「1」に上げます。

    マイナー

    • 後方互換性を保ちつつ、機能追加のある時にはこの番号を上げなければいけません(MUST)
    • この番号を上げた際には、パッチの番号は 0 にリセットしなければいけません(MUST)

    パッチ

    • 後方互換性を保ちつつ、バグ修正のある時にはこの番号を上げなければいけません(MUST)

    ※バグ修正とは間違った振る舞いを修正する内部の変更のことをいいます。

    ちょっと踏み込むと

    • プレリリースバージョンには、パッチ番号の後ろにハイフンで区切って識別子をつけることができます。

    (例：1.1.0-alpha / 1.1.0-beta / 1.1.0-rc) +

    Author Image

    Wednesday, August 5, 2020

    Semantic Versioning

    はじめに

    バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。

    セマンティックバージョニング？

    アプリに振るバージョン番号をSemVerというルールに従って付与しましょうというものです。

    確かにバージョン番号に意味を持たせることで、ユーザからもアプリのバージョン番号が上がればバグ修正なのか機能追加なのかわかりますし、プログラムからも互換性を考慮して処理を分けることができるのでよいですね。

    これだけ覚えておけば OK

    バージョン番号の形式は、メジャー.マイナー.パッチです。(例：1.0.0)

    メジャー

    • 後方互換性がない変更があった時にはこの番号を上げなければいけません(MUST)
    • この番号を上げた際には、マイナー/パッチの番号は 0 にリセットしなければいけません(MUST)
    • この番号が「0」の場合は初期開発用として扱います。リリースの段階でこの番号を「1」に上げます。

    マイナー

    • 後方互換性を保ちつつ、機能追加のある時にはこの番号を上げなければいけません(MUST)
    • この番号を上げた際には、パッチの番号は 0 にリセットしなければいけません(MUST)

    パッチ

    • 後方互換性を保ちつつ、バグ修正のある時にはこの番号を上げなければいけません(MUST)

    ※バグ修正とは間違った振る舞いを修正する内部の変更のことをいいます。

    ちょっと踏み込むと

    • プレリリースバージョンには、パッチ番号の後ろにハイフンで区切って識別子をつけることができます。

    (例：1.1.0-alpha / 1.1.0-beta / 1.1.0-rc) ※ちなみに識別子のrcは「release candidate」の略でベータ版よりもさらに製品版に近い品質のバージョンにつけるそうです。（略を初めて知りました。）

    • あと npm の packagge.json でもモジュールをセマンティックバージョンで管理してます。（~や^が付与されているのをよく見ると思います。）

    これについては上、真ん中、下で覚えるバージョニング範囲指定がわかりやすかったので共有しておきます。

    余談

    たかがバージョニング、されどバージョニングといった感じでした。知ってて損はないですよね。

    備考

    表紙イラスト：Loose Drawing

    Improve this page
    \ No newline at end of file diff --git a/posts/category/oss/index.html b/posts/category/oss/index.html index 54450725..f5496632 100644 --- a/posts/category/oss/index.html +++ b/posts/category/oss/index.html @@ -7,7 +7,7 @@
    -
    Hero Image
    Semantic Versioning

    はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。 +

    Hero Image
    Semantic Versioning

    はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。 セマンティックバージョニング？ アプリに振るバージョン番号をSemVerというルールに従って付与しましょうというものです。 確かにバージョン番号に意味を持たせることで、ユーザからもアプリのバージョン番号が上がればバグ修正なのか機能追加なのかわかりますし、プログラムからも互換性を考慮して処理を分けることができるのでよいですね。 これだけ覚えておけば OK バージョン番号の形式は、メジャー.マイナー.パッチです。(例：1.0.0) @@ -17,5 +17,5 @@ 余談 たかがバージョニング、されどバージョニングといった感じでした。知ってて損はないですよね。 備考 表紙イラスト：Loose Drawing

    Wednesday, August 5, 2020 Read
    \ No newline at end of file diff --git a/posts/category/page/2/index.html b/posts/category/page/2/index.html index cb24da5c..ac8714bb 100644 --- a/posts/category/page/2/index.html +++ b/posts/category/page/2/index.html @@ -7,7 +7,7 @@
    -
    Hero Image
    スレッドと並行処理

    はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。 +

    Hero Image
    スレッドと並行処理

    はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。 スレッド プロセスが最低１つは持っている実行単位のことです。 こんな言い方をするのは、プロセスが複数のスレッドを管理できるからです。 実行単位という視点でプロセスとの違いは、「アドレス空間」を共有できるという点です。 @@ -141,5 +141,5 @@ まとめ 、、とすごく大変そうに見えますが(実際に大変ですが)、スクラムならではの団体戦みのある開発でまあうまく回せるんではないでしょうかというのが感想です。 備考 表紙イラスト：Loose Drawing

    Friday, June 5, 2020 Read
    \ No newline at end of file diff --git a/posts/category/security/2021/01/oauth/index.html b/posts/category/security/2021/01/oauth/index.html index 05cc23fd..03eef016 100644 --- a/posts/category/security/2021/01/oauth/index.html +++ b/posts/category/security/2021/01/oauth/index.html @@ -43,8 +43,8 @@
    -
    Author Image

    Tuesday, January 5, 2021

    OAuth について

    はじめに

    バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。

    OAuth とは

    ひとまず、一番分かりやすい OAuth の説明で大体の感覚がつかめますのでオススメです。

    こちらでもざっくり説明させてもらうと、OAuth は複数のアプリを連携させるための仕組みです。

    例えば、ブログの記事を更新した瞬間に、ブログから更新情報をツイートしたかったりする場合に使われます。

    ただ、そのままツイートできるわけではなくて、ブログアプリがツイートする許可(認可)をしてあげる必要があります。

    そして許可されたアプリは許可証(アクセストークン)を持っていることで、Twitter を使ってツイートできるという仕組みです。

    メリット

    OAuth を使うことで、上の例であげたブログアプリは、Twitter のユーザ名とパスワードを知らなくてもツイートできるという点です。

    巷のアプリはこれを使うことで、Google アカウントや Twitter など SNS アカウントを持っているだけでユーザ登録できちゃいます。最初の煩わしい登録の手間が省けて良いです。

    OAuth1.0

    OAuth の初期バージョンです。他に 1.0a という名前のバージョンもありますが、Twitter では 1.0a を使うことができるみたいです。 +

    Author Image

    Tuesday, January 5, 2021

    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 を使っていきましょうという締めです。

    (Twitter 以外のほとんどのアプリが 2.0 を採用していることもあり、、)

    この辺の仕様がやはり読んだだけではイメージしづらいところがありますので、簡単に実装してみて実務で使えるようになりたいですという感想です。

    備考

    表紙イラスト：Loose Drawing

    Improve this page
    \ No newline at end of file diff --git a/posts/category/security/index.html b/posts/category/security/index.html index 859088b9..b831dba0 100644 --- a/posts/category/security/index.html +++ b/posts/category/security/index.html @@ -7,7 +7,7 @@
    -
    Hero Image
    OAuth について

    はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。 +

    Hero Image
    OAuth について

    はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。 OAuth とは ひとまず、一番分かりやすい OAuth の説明で大体の感覚がつかめますのでオススメです。 こちらでもざっくり説明させてもらうと、OAuth は複数のアプリを連携させるための仕組みです。 例えば、ブログの記事を更新した瞬間に、ブログから更新情報をツイートしたかったりする場合に使われます。 @@ -27,5 +27,5 @@ (2.0 は経路を TLS 化していることで、1.0 よりも提示するパラメータが少なくなっているという事実はあるそうな) まとめ 実装のことを考えてこれからも 2.0 を使っていきましょうという締めです。

    Tuesday, January 5, 2021 Read
    \ No newline at end of file diff --git a/posts/category/system-design/2020/12/principles-of-the-systems-architecture/part1/index.html b/posts/category/system-design/2020/12/principles-of-the-systems-architecture/part1/index.html index 0bd8cc6d..d2ad35b7 100644 --- a/posts/category/system-design/2020/12/principles-of-the-systems-architecture/part1/index.html +++ b/posts/category/system-design/2020/12/principles-of-the-systems-architecture/part1/index.html @@ -21,7 +21,7 @@
    -
    Author Image

    Saturday, December 5, 2020

    システム設計-part1-

    はじめに

    バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。

    ※現場で役立つシステム設計の原則を元に記事を作成しています。

    設計パターン

    値オブジェクト(Value Object)

    Java で変数を扱うとき、int や String などで型定義しがちな初心者丸出しの実装をしていた私ですが、値オブジェクトを知ったとき眼からウロコでした。

    値オブジェクトとは、汎用的な型(int や String)で型を定義するのではなく、専用の型(クラスやインターフェース)を定義します。

    範囲の広い汎用的な型を使うのではなく、業務に合わせた値で制限するというものです。

    値オブジェクトクラスはこんなかんじ

    class Quantity {
+
    Author Image
    Saturday, December 5, 2020
    システム設計-part1-
    はじめに
    バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。
    ※現場で役立つシステム設計の原則を元に記事を作成しています。
    設計パターン
    値オブジェクト(Value Object)
    Java で変数を扱うとき、int や String などで型定義しがちな初心者丸出しの実装をしていた私ですが、値オブジェクトを知ったとき眼からウロコでした。
    値オブジェクトとは、汎用的な型(int や String)で型を定義するのではなく、専用の型(クラスやインターフェース)を定義します。
    範囲の広い汎用的な型を使うのではなく、業務に合わせた値で制限するというものです。
    値オブジェクトクラスはこんなかんじ
    class Quantity {
 
     static final int MIN = 1;
     static final int MAX = 100;
@@ -71,5 +71,5 @@
 }
 
    意地で不変なオブジェクトを返すようにします。そうすることで変更による副作用の起きにくいプログラムを作ることに繋がります。
    まとめ
    • 値オブジェクトもコレクションオブジェクトもどちらも「不変であれ」ということです。同じインスタンスを使い回そうとすればするほど、変更によるバグが出る可能性が高くなります。
    • データとロジックは１つのクラスに閉じこめましょう。ロジックをまとめておくことで、使う側はメソッドを呼ぶだけで済むし、変更する場合はそのクラスだけを対象にすればよいわけです。人類の英知ですね。
    備考
    現場で役立つシステム設計の原則
    表紙イラスト：Loose Drawing
    
 Improve this page
    \ No newline at end of file diff --git a/posts/category/system-design/2020/12/principles-of-the-systems-architecture/part2/index.html b/posts/category/system-design/2020/12/principles-of-the-systems-architecture/part2/index.html index 549de1d1..3dbb348e 100644 --- a/posts/category/system-design/2020/12/principles-of-the-systems-architecture/part2/index.html +++ b/posts/category/system-design/2020/12/principles-of-the-systems-architecture/part2/index.html @@ -21,7 +21,7 @@
    -
    Author Image

    Saturday, December 5, 2020

    システム設計-part2-

    はじめに

    バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。

    ※現場で役立つシステム設計の原則を元に記事を作成しています。

    設計パターン

    早期リターン

    複雑になりがちな場合分けのロジックの見通しをよくしようというものです。

    ありがちなif-elseをつなげた(例 1)

    Yen fee() {
+
    Author Image
    Saturday, December 5, 2020
    システム設計-part2-
    はじめに
    バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。
    ※現場で役立つシステム設計の原則を元に記事を作成しています。
    設計パターン
    早期リターン
    複雑になりがちな場合分けのロジックの見通しをよくしようというものです。
    ありがちなif-elseをつなげた(例 1)
    Yen fee() {
   Yen result;
 
   if (isChild()) {
@@ -122,5 +122,5 @@
 }
 
    enumクラスのvalueOf()メソッドはMapのget()メソッドと同様に、if 文を使うことなく料金区分ごとのオブジェクトを取得できます。
    このような振る舞いを持った列挙型(enum)を区分オブジェクトと言います。
    まとめ
    前回同様、コードをスッキリさせる手法を見てきました。インターフェースを使うことで抽象的なメソッドを作ったり、列挙型を使って if 文をなるべく減らせることはコードの保守性、拡張性を高めてくれますね。
    備考
    現場で役立つシステム設計の原則
    表紙イラスト：Loose Drawing
    
 Improve this page
    \ No newline at end of file diff --git a/posts/category/system-design/2020/12/principles-of-the-systems-architecture/part3/index.html b/posts/category/system-design/2020/12/principles-of-the-systems-architecture/part3/index.html index 84874253..80569151 100644 --- a/posts/category/system-design/2020/12/principles-of-the-systems-architecture/part3/index.html +++ b/posts/category/system-design/2020/12/principles-of-the-systems-architecture/part3/index.html @@ -49,7 +49,7 @@
    -
    Author Image

    Saturday, December 5, 2020

    システム設計-part3-

    はじめに

    バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。

    ※現場で役立つシステム設計の原則を元に記事を作成しています。

    業務ロジック

    メソッドをロジックの置き場所にする

    現場で役立つシステム設計の原則では、“従来"という表現をされていますが、手続き型と呼ばれている設計ではデータクラスと機能クラスに分けて表現します。

    その名の通りデータクラスはデータを格納して、機能クラスはデータクラスのデータを判断、加工、計算するといった使い方です。

    この手続き型の問題は、拡張するときの変更箇所の特定に時間がかかるということです。

    なぜかというと、データクラスが参照できるクラスであれば、アーキテクチャのどのレイヤーにでもロジックが書けてしまうからです。

    便利のようには見えますが、先に言った変更箇所の特定に時間がかかるこの方法は最善ではありません。

    解決としては、Java 本来のクラスの使い方を踏襲することです。

    データとロジックを 1 つのクラスに閉じてしまおうという考え方です。

    class PersonName {
+
    Author Image
    Saturday, December 5, 2020
    システム設計-part3-
    はじめに
    バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。
    ※現場で役立つシステム設計の原則を元に記事を作成しています。
    業務ロジック
    メソッドをロジックの置き場所にする
    現場で役立つシステム設計の原則では、“従来"という表現をされていますが、手続き型と呼ばれている設計ではデータクラスと機能クラスに分けて表現します。
    その名の通りデータクラスはデータを格納して、機能クラスはデータクラスのデータを判断、加工、計算するといった使い方です。
    この手続き型の問題は、拡張するときの変更箇所の特定に時間がかかるということです。
    なぜかというと、データクラスが参照できるクラスであれば、アーキテクチャのどのレイヤーにでもロジックが書けてしまうからです。
    便利のようには見えますが、先に言った変更箇所の特定に時間がかかるこの方法は最善ではありません。
    解決としては、Java 本来のクラスの使い方を踏襲することです。
    データとロジックを 1 つのクラスに閉じてしまおうという考え方です。
    class PersonName {
   private String firstName;
 
   private String lastName;
@@ -60,5 +60,5 @@
 }
 
    データであるfirstNameとlastName、そしてロジック(メソッド)のfullName()が同じクラス内にあります。
    こうするとクラス内でデータを扱うことができて変更もこのクラス内で閉じることができます。
    また、メソッドはクラス内のインスタンス変数(firstNameやlastName)を使って何らかの処理を行う用途で作成します。
    クラスが肥大化したら小さく分ける
    これもやってしまいがちですが、改修を繰り返していくうちに、クラスが大きくなっていきます。
    大きくなったクラスは手続き型同様に変更箇所の特定に時間がかかります。
    それを防ぐために、大きくなってしまったクラスを次のルールで細分化します。
    • インスタンス変数とメソッドを対応付ける
    • メソッドが全てのインスタンス変数を使うようになる
    細分化したクラスはそれぞれ独立性が高くなるので、別のクラスで使う時にも再利用ができるようになります。
    こうした関連の強いデータとロジックをまとめたクラスを凝集度が高いと言います。
    凝集度が高いクラスは、変更箇所もそのクラスに閉じることになるので、疎結合になり他への影響が少なくて済みます。
    まとめ
    時すでに遅しと言いますか、現場での反省点をつらつら振り返ってベストプラクティスを学んでいるという感じです。
    次回に活かそうというモチベーションは上がるのでいい復習方法だと感じます。
    備考
    現場で役立つシステム設計の原則
    表紙イラスト：Loose Drawing
    
 Improve this page
    \ No newline at end of file diff --git a/posts/category/system-design/index.html b/posts/category/system-design/index.html index e7b7dfd2..fa1de89e 100644 --- a/posts/category/system-design/index.html +++ b/posts/category/system-design/index.html @@ -7,7 +7,7 @@
    -
    Hero Image
    システム設計-part1-

    はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。 +

    Hero Image
    システム設計-part1-

    はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。 ※現場で役立つシステム設計の原則を元に記事を作成しています。 設計パターン 値オブジェクト(Value Object) Java で変数を扱うとき、int や String などで型定義しがちな初心者丸出しの実装をしていた私ですが、値オブジェクトを知ったとき眼からウロコでした。 値オブジェクトとは、汎用的な型(int や String)で型を定義するのではなく、専用の型(クラスやインターフェース)を定義します。 @@ -46,5 +46,5 @@ 備考 現場で役立つシステム設計の原則 表紙イラスト：Loose Drawing

    Saturday, December 5, 2020 Read
    \ No newline at end of file diff --git a/posts/index.html b/posts/index.html index 18841538..4acbe8ba 100644 --- a/posts/index.html +++ b/posts/index.html @@ -7,7 +7,7 @@
    -
    Hero Image
    2022年の振り返り

    はじめに １年経つのは早いですね。 +

    Hero Image
    2022年の振り返り

    はじめに １年経つのは早いですね。 今年のサマリーとしては、通信大学へ入学したことと転職したこと、です。 去年はこのブログの投稿を増やしていくと意気込んでいましたが実績は、、意気込みは大事なので来年も意気込んでいきます💪 振り返りについては需要の有無に関わらず書いていきたいと思ってる所存です。 @@ -64,7 +64,7 @@ 節目というか、ちょっと時間ができたので、私が履修している科目一覧を Notion で管理しようと思い立ち、さくっと作ってみました。 科目一覧 - Notion これから同じように学習される方の参考になれば幸いです。（私も諸先輩方のブログを見て、参考になったので恩返しできれば！） -近況 元気にやっています:pduck_b: +近況 元気にやっています👋 備考 表紙イラスト：Loose Drawing

    Sunday, September 4, 2022 Read
    Hero Image
    2022年07月に読んだ記事とか本とか

    はじめに 読んだ記事とか本のリンクを張っておきます 読んだ記事 アーキテクトに求められるマインドとは / mindset for an architect @@ -207,5 +207,5 @@ ガード節 上記の例 2 からelseを抜いた(例 3) Yen fee() { if (isChild()) return chidFee(); if (isSenior()) return seniorFee(); return adultFee(); } elseを抜いた早期リターンをガード節と言います。非常にコンパクトですね。

    Saturday, December 5, 2020 Read
    \ No newline at end of file diff --git a/posts/index.xml b/posts/index.xml index 10a24d13..3360216f 100644 --- a/posts/index.xml +++ b/posts/index.xml @@ -52,7 +52,7 @@ package main func readFile(path string) chan string { // ファイルを読み 節目というか、ちょっと時間ができたので、私が履修している科目一覧を Notion で管理しようと思い立ち、さくっと作ってみました。 科目一覧 - Notion これから同じように学習される方の参考になれば幸いです。（私も諸先輩方のブログを見て、参考になったので恩返しできれば！） -近況 元気にやっています:pduck_b: +近況 元気にやっています&#x1f44b; 備考 表紙イラスト：Loose Drawing2022年07月に読んだ記事とか本とかhttps://uh-zz.github.io/posts/category/inputs/2022/07/Tue, 05 Jul 2022 18:07:06 +0900https://uh-zz.github.io/posts/category/inputs/2022/07/はじめに 読んだ記事とか本のリンクを張っておきます 読んだ記事 アーキテクトに求められるマインドとは / mindset for an architect 「少なくとも、最悪ではないアーキテクチャを狙う」 diff --git a/posts/introduction/index.html b/posts/introduction/index.html index 5f57e13a..8ccec893 100644 --- a/posts/introduction/index.html +++ b/posts/introduction/index.html @@ -7,7 +7,7 @@
    -
    Author Image

    Thursday, May 5, 2022

    Introduction

    はじめまして！

    このページでは、いくつか自己紹介をしたいと思います。

    内容に関しては追って更新しますので、しばらくお待ちくださいませ。

    ※「待てないよ!早く知りたい!」という意見がありましたら、お気軽に Twitter にてご連絡ください。

    備考

    表紙イラスト：Loose Drawing

    +
    Author Image

    Thursday, May 5, 2022

    Introduction

    はじめまして！

    このページでは、いくつか自己紹介をしたいと思います。

    内容に関しては追って更新しますので、しばらくお待ちくださいませ。

    ※「待てないよ!早く知りたい!」という意見がありましたら、お気軽に Twitter にてご連絡ください。

    備考

    表紙イラスト：Loose Drawing

    Improve this page
    \ No newline at end of file diff --git a/posts/page/2/index.html b/posts/page/2/index.html index 24e015b9..d68451b4 100644 --- a/posts/page/2/index.html +++ b/posts/page/2/index.html @@ -7,7 +7,7 @@
    -
    Hero Image
    システム設計-part3-

    はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。 +

    Hero Image
    システム設計-part3-

    はじめに バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。 ※現場で役立つシステム設計の原則を元に記事を作成しています。 業務ロジック メソッドをロジックの置き場所にする 現場で役立つシステム設計の原則では、“従来"という表現をされていますが、手続き型と呼ばれている設計ではデータクラスと機能クラスに分けて表現します。 その名の通りデータクラスはデータを格納して、機能クラスはデータクラスのデータを判断、加工、計算するといった使い方です。 @@ -163,5 +163,5 @@ まとめ 、、とすごく大変そうに見えますが(実際に大変ですが)、スクラムならではの団体戦みのある開発でまあうまく回せるんではないでしょうかというのが感想です。 備考 表紙イラスト：Loose Drawing

    Friday, June 5, 2020 Read
    \ No newline at end of file diff --git a/search/index.html b/search/index.html index e8a24a3b..61ce7bd1 100644 --- a/search/index.html +++ b/search/index.html @@ -7,7 +7,7 @@
    -
    \ No newline at end of file diff --git a/tags/aws/index.html b/tags/aws/index.html index 77b4d873..72904b1a 100644 --- a/tags/aws/index.html +++ b/tags/aws/index.html @@ -16,5 +16,5 @@ パーティションキーはダミー列 ソートキーに日付 これで同じ日付範囲の複数データを引っ張ってくることが可能になります。 確かに美しいと言えないかもしれませんが、機転の効いた方法だと思いました。

    Friday, June 5, 2020 Read
    \ No newline at end of file diff --git a/tags/basic/index.html b/tags/basic/index.html index ebb8382c..013fcca2 100644 --- a/tags/basic/index.html +++ b/tags/basic/index.html @@ -41,7 +41,7 @@ 節目というか、ちょっと時間ができたので、私が履修している科目一覧を Notion で管理しようと思い立ち、さくっと作ってみました。 科目一覧 - Notion これから同じように学習される方の参考になれば幸いです。（私も諸先輩方のブログを見て、参考になったので恩返しできれば！） -近況 元気にやっています:pduck_b: +近況 元気にやっています👋 備考 表紙イラスト：Loose Drawing

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

    はじめに 表題の通り、今年の 4 月から帝京大学理工学部情報科学科の通信教育課程に 2 年次編入しました。 そもそもの経緯と入るまでの話、入って 1 ヶ月経過した後の所感をまとめておきたいと思います。 @@ -96,5 +96,5 @@ 2021/05 緊急事態宣言の期間に入り、ほぼフルリモートになりました。 この頃のコミットを見てみると、主に Rails プロジェクトでのバグフィックスや、小さな機能追加をしていました。

    Friday, December 31, 2021 Read
    \ No newline at end of file diff --git a/tags/basic/index.xml b/tags/basic/index.xml index 08466d99..54bb5e2f 100644 --- a/tags/basic/index.xml +++ b/tags/basic/index.xml @@ -31,7 +31,7 @@ Kyash TechTalk #2 - Serverside のシステム構成とアーキテクチャ 節目というか、ちょっと時間ができたので、私が履修している科目一覧を Notion で管理しようと思い立ち、さくっと作ってみました。 科目一覧 - Notion これから同じように学習される方の参考になれば幸いです。（私も諸先輩方のブログを見て、参考になったので恩返しできれば！） -近況 元気にやっています:pduck_b: +近況 元気にやっています&#x1f44b; 備考 表紙イラスト：Loose Drawing【通信教育課程】帝京大学理工学部情報科学科に編入学しましたhttps://uh-zz.github.io/posts/category/look-back-on/2022/05/31/go-to-the-teikyo-university/Tue, 31 May 2022 18:07:06 +0900https://uh-zz.github.io/posts/category/look-back-on/2022/05/31/go-to-the-teikyo-university/はじめに 表題の通り、今年の 4 月から帝京大学理工学部情報科学科の通信教育課程に 2 年次編入しました。 そもそもの経緯と入るまでの話、入って 1 ヶ月経過した後の所感をまとめておきたいと思います。 きっかけ 大学進学について 通信制大学へ進学したいと思ったのは今年に入ってからではなく、ここ 2 年くらい検討していました。 diff --git a/tags/computer-science/index.html b/tags/computer-science/index.html index 8c5fe0aa..6b651141 100644 --- a/tags/computer-science/index.html +++ b/tags/computer-science/index.html @@ -86,5 +86,5 @@ 子プロセスの fork 実行時の戻り値は 0 です。 (戻り値 0 は正常終了のステータスコード)そして親プロセスの fork 実行時の戻り値は子プロセスのプロセス ID です。

    Sunday, July 5, 2020 Read
    \ No newline at end of file diff --git a/tags/ddd/index.html b/tags/ddd/index.html index f74b61e9..a6197ba6 100644 --- a/tags/ddd/index.html +++ b/tags/ddd/index.html @@ -46,5 +46,5 @@ 備考 現場で役立つシステム設計の原則 表紙イラスト：Loose Drawing

    Saturday, December 5, 2020 Read
    \ No newline at end of file diff --git a/tags/development/index.html b/tags/development/index.html index 6ddde002..8a691f27 100644 --- a/tags/development/index.html +++ b/tags/development/index.html @@ -64,5 +64,5 @@ まとめ 、、とすごく大変そうに見えますが(実際に大変ですが)、スクラムならではの団体戦みのある開発でまあうまく回せるんではないでしょうかというのが感想です。 備考 表紙イラスト：Loose Drawing

    Friday, June 5, 2020 Read
    \ No newline at end of file diff --git a/tags/dynamodb/index.html b/tags/dynamodb/index.html index 895e471e..aa0df331 100644 --- a/tags/dynamodb/index.html +++ b/tags/dynamodb/index.html @@ -16,5 +16,5 @@ パーティションキーはダミー列 ソートキーに日付 これで同じ日付範囲の複数データを引っ張ってくることが可能になります。 確かに美しいと言えないかもしれませんが、機転の効いた方法だと思いました。

    Friday, June 5, 2020 Read
    \ No newline at end of file diff --git a/tags/go/index.html b/tags/go/index.html index b2775d32..1504cd5e 100644 --- a/tags/go/index.html +++ b/tags/go/index.html @@ -48,5 +48,5 @@ 以下「ソートを極める！ 〜 なぜソートを学ぶのか 〜」を元に実装してみた（なるべくソースを見ないで実装を試みたがマージする箇所は折れた、、） package main import ( "fmt" "time" "github.com/uh-zz/traning/algorithm/shuffle" ) func main() { // ランダムな要素 n 個のスライス取得 input := shuffle.RandomIntList(n) inputLength := len(input) // マージソート MergeSort(&input, 0, inputLength) } // MergeSort マージソート func MergeSort(input \*[]int, left, right int) { // 要素数1つの場合は抜ける if right-left == 1 { return } // 配列を２つに分けるインデックス middle := left + (right-left)/2 // 配列左側 MergeSort(input, left, middle) // 配列右側 MergeSort(input, middle, right) var buffer []int // 左側と右側をバッファにためる（右側反転） for index := left; index < middle; index++ { buffer = append(buffer, (*input)[index]) } for index := right - 1; index >= middle; index-- { buffer = append(buffer, (*input)[index]) } // マージする scopeLeft := 0 scopeRight := len(buffer) - 1 for index := left; index < right; index++ { if buffer[scopeLeft] <= buffer[scopeRight] { // 左側採用 (*input)[index] = buffer[scopeLeft] scopeLeft++ } else { // 右側採用 (*input)[index] = buffer[scopeRight] scopeRight-- } } } これ考えたのぶっ飛んでるなあと思って Wikipedia 見てたら、考案者がフォン・ノイマンでやっぱりぶっ飛んでた（凄すぎ）

    Sunday, July 5, 2020 Read
    \ No newline at end of file diff --git a/tags/index.html b/tags/index.html index 07da6085..4fcc3783 100644 --- a/tags/index.html +++ b/tags/index.html @@ -8,5 +8,5 @@
    \ No newline at end of file diff --git a/tags/oauth/index.html b/tags/oauth/index.html index 7f2343f7..cbe05aa0 100644 --- a/tags/oauth/index.html +++ b/tags/oauth/index.html @@ -27,5 +27,5 @@ (2.0 は経路を TLS 化していることで、1.0 よりも提示するパラメータが少なくなっているという事実はあるそうな) まとめ 実装のことを考えてこれからも 2.0 を使っていきましょうという締めです。

    Tuesday, January 5, 2021 Read
    \ No newline at end of file diff --git a/tags/oss/index.html b/tags/oss/index.html index 2ef35e2f..f1b64dd4 100644 --- a/tags/oss/index.html +++ b/tags/oss/index.html @@ -17,5 +17,5 @@ 余談 たかがバージョニング、されどバージョニングといった感じでした。知ってて損はないですよね。 備考 表紙イラスト：Loose Drawing

    Wednesday, August 5, 2020 Read
    \ No newline at end of file diff --git a/tags/poem/index.html b/tags/poem/index.html index 3e524c01..9616ffc2 100644 --- a/tags/poem/index.html +++ b/tags/poem/index.html @@ -43,5 +43,5 @@ 顧客の注文履歴を参照する 注文履歴から特定の注文オブジェクトを取得する 注文オブジェクトの総額を返す 総額から割引した値をオブジェクトにセットする 次のような考え方がある 照会せずに依頼する TDA(Tell, Don’t Ask)

    Friday, March 5, 2021 Read
    \ No newline at end of file diff --git a/tags/security/index.html b/tags/security/index.html index ed34861f..68c28f03 100644 --- a/tags/security/index.html +++ b/tags/security/index.html @@ -27,5 +27,5 @@ (2.0 は経路を TLS 化していることで、1.0 よりも提示するパラメータが少なくなっているという事実はあるそうな) まとめ 実装のことを考えてこれからも 2.0 を使っていきましょうという締めです。

    Tuesday, January 5, 2021 Read
    \ No newline at end of file diff --git a/tags/system-design/index.html b/tags/system-design/index.html index 56544e07..7698b4be 100644 --- a/tags/system-design/index.html +++ b/tags/system-design/index.html @@ -46,5 +46,5 @@ 備考 現場で役立つシステム設計の原則 表紙イラスト：Loose Drawing

    Saturday, December 5, 2020 Read
    \ No newline at end of file