yyh-gl's Tech Blog

Kotlin言語仕様書への招待 @Kotlin Fest 2025

Sat, 01 Nov 2025 13:20:00 +0900

Kotlin Fest 2025

Kotlin Fest 2025 に参加してきました。

Kotlin Festには去年初めてプロポーザルを出しました。
結果は落選。

今年もチャレンジした結果、採用していただきました。

発表内容

『Kotlin言語仕様書への招待〜コードの「なぜ」を読み解く〜』というタイトルで話しました。

Xで嬉しいリアクションをたくさんいただきました。
聞きに来てくださったみなさんありがとうございました！

JavaのIntegerクラスがキャッシュする範囲

Sun, 18 May 2025 22:30:08 +0900

JavaのIntegerクラスにキャッシュがあることを知る

JetBrains公式アカウントで以下のクイズがポストされていた。
解答の中に以下のポストを発見。

Not equal because they are greater than 127. 127 and below would use the integer cache and then they would be equal
— Simon Martinelli (@simas_ch) May 17, 2025

“Integer cache"なるものがあることを知る。

Integerクラスのキャッシュとは

ドキュメントを見てみる。
（Javaバージョン: 24）

This method will always cache values in the range -128 to 127, inclusive

-128~127の範囲は常にキャッシュされるとのこと。

and may cache other values outside of this range.

ただし、範囲は-128~127ではないときもあるらしい。
どういうときに範囲が変わるのか気になったので調べた↓

キャッシュ範囲を深ぼる

コードを見てみると以下のとおりだった。

『暗号解読（上）』を読んで

Fri, 24 Jan 2025 00:30:40 +0900

はじめに

『暗号解読（上）』を読んだ感想を簡単にメモしておく。
なお、本記事は自分で書いた読書メモをChatGPTに整形してもらったもの。
（文章としておかしい部分だけ自分で修正）

読書メモ

ソフトウェアエンジニアとして情報セキュリティの知識を深める目的で、サイモン・シン氏の著書『暗号解読（上）』を拝読いたしました。
本書は暗号の歴史から具体的な解読手法、さらには現代の暗号理論に至るまで幅広く取り上げており、暗号に関わる者として学ぶところが多くありました。
以下に、本書を通じて特に印象に残った点を整理します。

1. 暗号システムの本質

どれほど強固な暗号方式を用いていても、鍵が漏洩すればすべてが水泡に帰すという原則は改めて肝に銘じるべき事項です。

2. ヌル文字の歴史的背景

「ヌル文字」といえばプログラマにはおなじみですが、実は16世紀にすでに「何の意味も持たないダミー文字」として暗号の世界で使われていたそうです。歴史の長さに驚き。

3. 弱い暗号の危険性

「弱い暗号を使うぐらいなら、最初から暗号など使わない方がましだ」という指摘は極めて重要です。暗号への過信は、平文なら絶対書かない内容までつい書いてしまうリスクを孕みます。セキュリティ意識の啓発においては、強固な暗号方式の採用だけでなく、その危うさを十分に理解してもらう必要があります。

4. 古典的な解読テクニック

頻度分析
連接特徴
- 例として、英語では「q」の後に必ず「u」が続く等、文字の連鎖関係を用いた分析があります。

こうしたテクニックは一見地道ですが、歴史上多くの暗号がこれらの手法によって解読されてきました。情報理論や機械学習が普及する現代でも、基本となる考え方を学ぶ意義は大きいと感じます。

5. ワンタイム・パッドの特異性

一度きりの使い捨て鍵を用いるワンタイム・パッドは理論上解読不可能とされています。しかし、膨大な鍵の管理が必要になるため実用的ではなく、あまり使われてこなかった。ただし、ロシア大統領とアメリカ大統領のホットラインのような特殊な用途では今なお採用されている点が非常に興味深いです。

6. エニグマと鍵交換の重要性

20世紀に登場したエニグマは極めて複雑な印象を与えますが、実際の仕組みは比較的シンプルであり、物理的にもコンパクト（34×28×15cm・12kg）であったことが紹介されています。打倒エニグマの歴史から、安全な鍵交換の重要性も学べます。

7. 反復は秘匿の大敵

暗号においてパターンや繰り返しは危険を伴います。同一のIV（初期化ベクトル）を使い回すといった行為が脆弱性を生むのは、まさにこの法則に通じるものがあります。暗号の設定や運用の細部にわたるまで注意が必要だと痛感させられます。

毎日決まった時間に放送される天気予報のような“当たり前”の情報でも、暗号解読のヒント（クリブ）となり得ることが紹介されています。日常に潜む定常的データが、思わぬ形で暗号解読に利用される様は、現代の情報漏洩リスクにも通じる示唆を与えてくれます。

8. 数学には論理と直感の両方が求められる

本書を通じて改めて印象に残ったのは、数学の問題を解くにあたっては「論理的思考」に加えて「直感」も欠かせない、という視点です。暗号の解読過程は、単なる数式の機械的処理だけではなく、数多くの仮説検証や柔軟な発想を必要とすることを本書は示唆しています。

9. アラン・チューリングという天才

エニグマの解読で中心的役割を果たしたアラン・チューリングに関する記述からは、彼の卓越した才能がいかに戦争の行方を左右したかが窺えます。計算機科学の父とも称されるチューリングの偉大さを再認識し、その業績を学ぶことは、現代のソフトウェアエンジニアにとっても大きな意義があると感じます。

10. 解読しても公表しない情報戦

暗号を解読しても、あえて公表せず、相手に使い続けさせるという情報戦略があることも興味深い点です。セキュリティ技術は単なる防御策ではなく、攻撃・解析そして情報操作といった多面的な視点が求められます。

総括

『暗号解読（上）』は暗号の歴史的背景、具体的な解読技術、そして現代のセキュリティに通じる核心的な部分まで網羅的に扱っており、暗号に携わるエンジニアにとって大いに参考になる一冊です。数学が中心的な役割を果たす分野であるにもかかわらず、通史としても非常に読み応えがあるため、セキュリティ技術への関心だけでなく、歴史や論理パズルに興味がある方にも大変おすすめできます。

私自身、改めて鍵管理の重要性や暗号方式の運用上の落とし穴を再認識しました。本書を通じて、暗号技術はあくまで“手段”であり、それをいかに適切に設計・運用するかが要であると痛感します。今後もセキュリティへの関心を高めつつ、情報保護に対する責任と慎重さを持って業務にあたっていきたいと思います。

VS Codeのeditor.quickSuggestionsについて調べたメモ

Fri, 10 Jan 2025 19:34:56 +0900

はじめに

VS Codeの設定にeditor.quickSuggestionsというものがある。
サジェストを出すかどうかを設定できる。

サジェストというのは以下のようなやつ。

この設定項目について調べたのでメモを残す。

editor.quickSuggestions

editor.quickSuggestionsは以下のような設定ができる。

"editor.quickSuggestions": {
"other": "on",
"comments": "off",
"strings": "off"
},

ref: https://code.visualstudio.com/docs/getstarted/settings

other, comments, strings の意味がわからず、調べた内容をメモする。

なお、公式Docsから各項目に関する説明を見つけられなかったので、 ChatGPTにざっくりした説明を聞いたうえで、実際に設定をon/offして挙動を確認した。
よって、後述の説明はあくまで自分の解釈であることに注意。
おそらく文字どおりの意味だから説明がない…？
公式Docsの説明を見つけたら更新する。
（ChatGPTからの回答で「VS Codeドキュメントによると」って言われたんだけどね）

comments

コメント内でのサジェスト有効/無効を設定できる。

strings

文字列リテラル内でのサジェスト有効/無効を設定できる。

other

その他の場所におけるサジェスト有効/無効を設定できる。

コード書いてるときに出てくるサジェストの大半はこれに該当するはず。

調査背景

自分はMarkdown編集時に改行や強調などのHTMLタグをよく使う。
HTMLやReact, Vueなどのコードを書いているときのようにHTMLタグをサジェストしてほしい。
（<や>、閉じタグを打つのめんどくさいし）
よって、Markdown編集時によく使うHTMLタグは、snippetに登録し、サジェストされるようにしている。

しかし、VS Codeのデフォルト設定では、Markdownに関するサジェストが出ないようになっている。
Markdownに関するサジェストを有効にできないか調べているとeditor.quickSuggestionsにたどり着いた。

『データ指向アプリケーションデザイン』を読んで

Thu, 09 Jan 2025 21:40:02 +0900

はじめに

『データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理』を読んだ。

会社で輪読会をして、全部読みきった。

期待以上の良書に出会った感動をそのまま殴り書いているだけ。
とりとめもない文章なので、得られる知見はないと思うけど、感動を共有したいので書いた。

感想

心の底から読んでよかったと思える一冊だった。

シンプルなリレーショナルデータベースの話だけでなく、NoSQLや分散ストレージ、ストリーム処理（Kafkaとか）など、データベースに関する話が幅広く書かれている。
データ構造の話（log-structuredやBツリー）やトランザクションの話もすごいおもしろかった。

難しい話も多いけど、ふわっとしていた理解がだいぶ具体化された。
これまで何気なく使っていたデータベース。裏側のロジックを知ることで実際の開発でもいろいろ考慮できるようになった。

データベースに関するおすすめの本を聞かれたら、絶対にこの本を薦める。
（初心者におすすめする本ではないと思う）

具体的にどういったことが書かれているかは、他の人が書いている記事がたくさんあるので、そちらを参照のこと。
というかぜひ本書を手にとっていただきたい。

評価の高い本だったので、読む前から期待はしていたものの良い意味で裏切られた。
学びが多く、本当に感動したので、この記事をなぐり書きしておく。

2024年を振り返る

Tue, 31 Dec 2024 20:53:11 +0900

仕事

本業：LINEマンガ

ユーザーが増え、より大規模なサービスになってきた。
求められる品質がさらに高くなってきており、いちエンジニアとしてとても楽しい。

k8sを本格的に使用し始めたので、k8s周りの知識を深めている最中。
資格（CKAD）の取得を目指しているが、一番の壁は受験料。

今まで資格というものに興味がなかったけど、少し興味が出てきた今日このごろ。
LPIC の取得も頑張ってみようか迷ってる。

開発以外に採用にも参加し始めた2024年。
来年で3年目に突入するので、開発以外の部分でももっと活躍できるようにしていく。

副業

4年弱携わった案件が一段落した。
本業とは全く異なる特性を持つサービスだったので様々な知見を得ることができた。
引き続き同社の別サービスの開発に従事していくので頑張っていきたい。

個人的な活動

読書

読書をたくさんしている。
AIに聞けば高い精度で答えてくれる時代になったとはいえ、まだ間違った回答もある。
正当性を判断するためにも地力をつけたい（普通に技術力を上げるという点でも頑張りたい）。
だから、信頼できるソースからのインプットを増やそうと考えた結果、読書に力を入れ始めた。
最近は常に読書中の本がある状態を維持している。
来年も続けていく。

ブログ

インプット（読書）するだけじゃなくて、ちゃんと知識として定着させたい。
なので、得た知識はブログとしてアウトプットする。

k8s

もともと個人開発で使っていたk8s。
本業でもk8sを使うようになり、ちょうど良いplaygroundとして稼働してくれている。
とても助かる。k8sクラスターを構築してくれていた過去の自分に感謝。
https://tech.yyh-gl.dev/blog/k8s-setup/

個人開発

個人でサービスを作りたいと考えて動き出している。
来年リリースを目指して頑張る。

まとめ

がんばる↓

なんといっても「仕事」。一番大事
- 開発以外でも活躍する
資格取る
- CKAD
- LPIC
always 読書
- ブログでアウトプット

分散システムにおけるID採番の勉強メモ

Sat, 28 Dec 2024 20:08:33 +0900

はじめに

分散システムにおけるID採番方法について気になったので調べたときのメモ。
（UUIDおよびULIDはスキップ）
調査の中で興味を持ったのがSnowflakeだったので、ほぼSnowflakeの話。

Snowflake

分散システムにおけるID採番方式として有名なもののひとつ。
https://en.wikipedia.org/wiki/Snowflake_ID

64bitで構成されている。

（参照： https://en.wikipedia.org/wiki/Snowflake_ID ）

基本的に、上記のフォーマットで生成されたバイナリは10進数の数値に変換される。
timestampを含むので、時刻情報に基づいたソートが可能。
高い衝突体制を持つ。

timestampを含んでいることからも分かるとおり、SnowflakeはSystem Clockに依存している。
よって、時間が巻き戻ったりするとIDが重複する可能性がある。
ただし、時刻が巻き戻った場合にはID生成をストップする機構が組み込まれている。
（最後に生成したIDが示す時刻を超えるまで生成ストップ）
https://github.com/twitter-archive/snowflake/tree/snowflake-2010?tab=readme-ov-file#system-clock-dependency

Xでも使われている（参考）。
現行のコードではないもののコードはこちら。
今使われているのはSnowflakeの進化系？

The Snowflake we’re using internally is a full rewrite and heavily relies on existing infrastructure at Twitter to run.

Snowflakeとよく比較される対象

UUID
ULID

k8s関連書籍をいろいろ読んだ

Tue, 21 May 2024 09:39:53 +0900

今回読んだ本

業務でk8sを触る機会があり、事前に知識をつけるためにいくつかの本を読んだ。
以下が今回読んだ本。

入門 Kubernetes

本書はk8sを触るうえで知っておくべき基本的な内容が書かれている。
コマンド例も書いてあるので、実際に手を動かしながら、k8sの基本について学ぶことができる。

私は趣味の開発でk8sクラスターを運用しているので、基本的には復習的な意味合いで読んだ。
とはいえ、永続化周りの知識はなんとなくでやっていたので知見が深まった。

特にk8sを初めて触る人におすすめの一冊だと思った。

注意点としては、原書は第3版まで出ており、いくつか加筆がある。
日本語版は加筆部分がないので、最新の情報を知りたい場合は原書を読むことをおすすめする。

Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス

25章『サービスとしてのコンピュート』を読んだ。

k8sそのものの話はあまりない。
「コンピュート（プログラムを実際に実行するのに必要な計算能力）」というワードを中心に、スケールする環境でプログラムを動かすことの大変さと、その大変さを解消するために考えるべきことを深ぼっていく。

この話の中で、 k8sの前身であるBorgの話が出てくる。
こういった考えのもとBorgが生まれたんだなというのがよくわかった。

特に以下2点が私にとっては有益な情報だった。

スケールする環境における「コンピュート」関連の課題
『ペット対家畜』の話

コンテナセキュリティコンテナ化されたアプリケーションを保護する要素技術

k8sのための本というわけではないが、コンテナ技術の上に成り立つk8sを触るうえで知っておくと役に立つ内容が書かれている。

僕はこれまでコンテナ技術を触ってきたにも関わらず、「Linuxの機能を使って実現されているんだよなぁ」という抽象的な理解しかしていなかった。

本書を読むことで、コンテナ技術がLinuxのどういった機能によって実現されているかをきちんと理解できた。
そして、上記の話をベースに、タイトルにもあるセキュリティの話へと繋がっていく。

僕自身、コンテナセキュリティについては、頑張ってキャッチアップしているつもりだった。
しかし、ベースとなるコンテナ技術について学んだ後だと、また違った角度からセキュリティについて再考できた。

すでに実務で困らない程度にはコンテナをさわれるという方に、ぜひとも読んでほしい一冊だと思った。

2024年もよろしくお願いします！

Mon, 08 Jan 2024 17:05:16 +0900

転職で始まった2023年も、あっという間に終わりました。
お世話になった方々ありがとうございました！

今年も精一杯頑張っていくのでよろしくお願いします。

Indigo VPS上に個人開発用のk8sクラスターを構築する

Thu, 04 May 2023 11:20:17 +0900

概要

WebARENA Indigo でVPSを2台借りて、個人開発用のk8sクラスターを構築したので、その手順をメモとして残します。

k8sクラスターの構築は下記2つの公式ドキュメントを参考に進めました。

ドキュメントに記載のある手順を最終的にはスクリプトにしています。
（本ブログ公開時点では自動構築スクリプトとして活用可能ですが、 k8sまわりのアップデートにより動かなくなる可能性が高いと思います）

k8sクラスターについて

Masterノード 1台, Workerノード 1台の計2台構成
- 個人開発なのでお金の節約のために冗長構成は取っていません
サーバーOSは Ubuntu 22.04
k8sのバージョンは v1.27.1
CNIはFlannelを使用

Indigo VPS固有の内容

Swapの無効化は不要

k8sを構築するサーバーに関して、公式ドキュメントに以下の記載があります。

Swapがオフであること。kubeletが正常に動作するためにはswapは必ずオフでなければなりません。

参考

Indigo VPSではデフォルトでSwapが無効になっているのでこの手順は不要です。

ファイアウォール

インバウンドに対してのみ制限を設けます。
公式ドキュメントに公開しないといけないポート情報が記載されているので、こちらを参照して必要なポートだけ開けます。
公開しないといけないポート情報

ufwについては特になにもしていません。

このままでは手元のPCからSSHができなくなりますが、そこはTailscaleで解決しています。
Tailscaleのインストールはスクリプト内で行っています。

スクリプト

下記リポジトリに置いています。

yyh-gl/k8s-setup

以下のとおり実行すれば、k8sクラスターが構築されます。

Masterノード：setup_common.sh→setup-master.shの順で実行
- 注意：setup-master.shの<Master node IP>部分はMasterノードのIPアドレスに置き換える必要あり
  - advertise addressの変更に使用（僕はTailscaleが払い出すIPにしたかったので）
Workerノード：setup_common.shを実行後にkubeadm join

gomockのgenerics対応状況

Sun, 09 Apr 2023 00:25:48 +0900

gomock

gomock はGo用のモック生成ツールです。

今回はこのgomockのgenerics対応状況について共有します。

gomockのgenerics対応状況

残念ながらgomockはまだgenericsに対応していません。

ただし、generics対応がリリースされていないだけで、すでにmainブランチには generics対応のPR がマージされています（Issueはこちら）。したがって、go install github.com/golang/mock/mockgen@mainとすればgenerics対応したgomockを利用可能です。

いつリリース？

v1.7.0としてリリース予定らしく、すでにタグは作成されています。 https://github.com/golang/mock/releases/tag/v1.7.0-rc.1

ただ、タグが作成されてからもうすぐ1年が経とうとしています…

無事リリースされることを祈りましょう。

（タグがあるのでgo install github.com/golang/mock/mockgen@v1.7.0-rc.1でもOKですね）

まとめ

generics対応したgomockを使いたい場合は、 go install github.com/golang/mock/mockgen@mainか go install github.com/golang/mock/mockgen@v1.7.0-rc.1を実行しましょう。

DMM.comを退職しました

Wed, 11 Jan 2023 00:00:00 +0900

合同会社DMM.comを退職しました

2019年4月1日に新卒入社し、2023年1月11日に退職しました。
4年弱お世話になりました。

節目なのでDMM入社前〜退職までをまとめておきます。
メインは自分の振り返りのためですが、DMMに興味がある方の参考になると幸いです。

入社まで

私は将来起業したいと思っており、そのために事業立ち上げを近くで見てみたいと考えていました。
（実はリッチマンプアウーマンに影響を受けてエンジニアになってたりします）

起業に興味がありつつも、エンジニアとして大規模なシステム開発に携わってみたいという相反する気持ちもありました。

どうしようかなぁと思っていたときに出会ったのがDMM.comでした。

20年以上稼働しているシステムがある上に、新規事業が毎月のように生まれてくる会社です。
0→1から1→10, 10→100まで全部やってみたい僕にはうってつけの場所でした。

入社してから

新卒研修が終わり、配属となったチームでは最初はリプレイス案件を担当し、半年ほどすると新規事業が始まりました。
（詳しくは About にある経歴をご覧いただければと思います）

直属の上司である石垣さん（@i35_267 ）の元で働いていたわけですが、開発だけでなく様々な機会をいただきました。

フルサイクルエンジニアリングの考えに則った開発から始まり、損益計算書（P/L）を読んだり、データ分析や施策検討など、「エンジニア」という枠組みに縛られない様々な経験をしました。

もちろんやることは増えるので忙しかったですがとても楽しかったです。
良い経験だったと心の底から思います。

テックリード、そして、チームリーダーへ

リプレイス案件の途中からテックリードを任せてもらうことになります。
大それたことをやっていたわけではないですが、技術周りをリードできるように勉強してはチームに還元するといったことをしていました。
（技術的関心とビジネス的関心のバランスを考えるのが楽しかった）

結果として2019年度のゴールデンルーキー賞（新人賞みたいなの）をいただきました。
自分のやってることが正しいのか分からない中で必死に突き進んでいた自分にとっては、みんなに認めてもらえたと実感できてとても嬉しかったです。
（自慢話に聞こえるかなと思って、今まで社外で話したことなかった）

無事にリプレイスが完了し、次に僕がDMMで最も関わっていた『DMMポイントクラブ』プロジェクトが始まります。
（間で他にもプロジェクトをやってましたが話の流れ的に今回は割愛）

本プロジェクトが始まるにあたり僕はチームリーダーになりました。
DMMにはテックリードという役職がないので、ここで初めて役職がつきました。

肩書きにまったく興味がない僕は今までどおりがむしゃらに頑張りました。
（さすがにもう少しどういう役職があるかは知っといた方がいいと石垣さんに言われたのも懐かしい）

チームリーダーになると開発業務以外にメンバーのマネジメントやプロジェクト管理なども入ってきます。
手を動かす（開発）時間が減ってしまいストレスを抱える時期もありましたが、ユーザーに価値を届けるという目標は同じであり、十分にやりがいを持ちながら仕事していました。

特にピープルマネジメントには正解がなく、あーでもないこーでもないと試行錯誤しながら突き進んでてきた2年でした。
やってきたことが合っていたのかは分かりませんが、最終出社日にチームメンバーからもらった色紙のメッセージを見て、ある程度はリーダーとしてみんなのためになれていたのかなと思いました。

フルサイクルエンジニアリングを掲げたチームにおけるリーダー経験はとても良い経験だったと思います。

『DMMポイントクラブ』での開発やマネジメントに関して各メンバーが意識していたことなどは以下の動画にまとまっているので興味があれば御覧ください。
『DMM meetup #38〜フルサイクルエンジニアリングの現場【技術書典出版記念】〜』
（本も書きました『DMM PointClub Tech Book #1 』）

10→100の開発

DMMの大黒柱といっても過言ではない動画サービス（10→100）にも少しだけ（本当に少しだけです）参加しました。
20年以上運用されているサービスですので、いわゆる「レガシー」と呼ばれる部分もありますが、
そこにネガティブなイメージはなく、こういう工夫によって支えてきたんだという学びが大きかったです。
（もちろん改善も進んでいます）

KtorとStripeでECサイトを作ってみた

Wed, 21 Dec 2022 00:00:00 +0900

Kotlin Advent Calendar 2022

本記事はKotlin Advent Calendar 2022 の21日目の記事です。

概要

クリスマスといえばプレゼント。
ということでECサイトを作ってみます。

ECサイトと言いつつもあまり複雑なことはせずに、Stripeから取得した商品情報を表示する画面を作るところまでやります。
本画面を実装する過程で、APIを経由した情報のやりとり→受け取った情報を画面に表示するところまで触れます。
よって、本記事を読めばKotlinで外部API（主にStripe）を使ったシステムの実装イメージをざっくり掴めると思います。

ただただKotlinで作るだけではなくて、個人的にこれまで触ったことないフレームワークやサービスを使ってみたいと思っています。

個人的にこれまで触ったことない

あたかもKotlinは触ったことあるような言い方ですが、私はこれまでGo中心のエンジニア人生でした。
したがって、そもそもKotlin自体あまり触ったことがないです←
Kotlinのお作法を守れていないところもあると思いますが、こんな感じで作れるのかぁとイメージしてもらえると幸いです。

では、採用技術を紹介したら、さっそくECサイトを作っていこうと思います。

⚠️ 本記事内に記載するコードはpackageやimport周りのコードを省略しています。
コード全体を見たい場合は以下のリポジトリにコードを置いているのでこちらを参照ください。
https://github.com/yyh-gl/ktor-shop/

採用技術

Webフレームワーク：Ktor
テンプレートエンジン：FreeMarker
決済および商品管理：Stripe
DI：Koin

Hello World

まずは「Hello World」していきます。

プロジェクトの作成は下記公式サイトに記載の手順を参考にしてください。

https://ktor.io/docs/intellij-idea.html#create_ktor_project

インストールしたプラグインは以下のとおりです。

コードがひととおりできあがったら下記コマンドを実行しサーバーを起動します。

$ ./gradlew run

サーバーが起動したら http://localhost:8080/ にアクセスします。

「Hello World!」を表示できました。

Auto-reloadの有効化

開発していく上ではAuto-reloadがあった方が便利なのでAuto-reloadを有効にしていきます。

Auto-reloadを有効化する手順は以下のとおりです。

developmentモードを有効化
継続的なビルドを実行
$ ./gradlew -t build
サーバーを起動
$ ./gradlew run

サーバー起動手順がHello Worldのときよりも2つ増えています。
詳しく見てみましょう。

複数のdocker-compose.ymlを使って、設定の追加や上書きをやってみる

Sat, 19 Mar 2022 00:55:40 +0900

要約

Docker Composeの設定ファイルは複数指定できて、設定の追加や上書きができる。

早速詳細に見ていきましょう↓

`docker-compose.yml`は複数指定可能

docker compose up実行時に-fオプションを使うことで、参照するdocker-compose.ymlファイル（設定ファイル）を指定できることは、ご存知の方も多いと思います。
しかし、複数の設定ファイルを指定できることはあまり知られていないと思います（勝手な決めつけ）。

Docker-docs-ja では、以下のページで説明がされています。

『ファイル間、プロジェクト間での Compose 設定の共有』

実際の動きを見てみる

以下のようなdocker-compose.ymlを用意します。

docker-compose.yml

version: '3'
services:
web:
image: "nginx:latest"

docker compose -f docker-compose.yml upでコンテナを起動した後に、ブラウザを開いてhttp://localhost/にアクセスしてみます。

Webサイトにアクセスできませんでした。

ポートを公開していないので当然の結果ですね。

次に、以下のようなdocker-compose.override.ymlを用意します。

docker-compose.override.yml

version: '3'
services:
web:
ports:
- "80:80"

そして、今度は以下のようにして、複数の設定ファイルを指定します。

docker compose -f docker-compose.yml -f docker-compose.override.yml up

では、http://localhost/にアクセスしてみます。

今度は無事にアクセスできました。

ポート公開がうまくできているようです。

上記の挙動を見ることで、docker-compose.ymlで使用イメージの指定ができており、なおかつ、 docker-compose.override.ymlでポート公開の設定ができていることが分かります。

すなわち、Docker Composeは追加で設定ファイルを指定することで、設定を追加できます。

なお、今回はサンプルを省きましたが、追加だけではなく、上書きも可能です。
（後ほど出てくるサンプルを見れば、上書きの挙動も分かると思います）

【2021年】アクティビティまとめ

Sun, 02 Jan 2022 20:59:04 +0900

今年も…

昨年に引き続き、今年もLAPRAS で1年間のアクティビティを出してみました。

コロナ禍真っ只中でも、オンラインでたくさんの勉強会に参加できました。

今年は良い出会いが特に多く、運営側として関わったものも増えました。

来年もさらに良い年になるように、多方面で頑張っていきます！

では、本題の2021年のアクティビティです↓

2021年アクティビティ

2021年のアウトプットと参加イベントを振り返ると

アウトプットしたものや参加したイベントなどをまとめてみました。

connpass

2021/12/08
- ユースケース駆動開発をやってみた
2021/12/01
- Go Language Specification 輪読会 #32
2021/11/25
- merpay Tech Talk 〜決済基盤の未来〜
2021/11/17
- Go Language Specification 輪読会 #31
2021/11/03
- Go 1.18+ 言語仕様勉強会 #3 【Generics】
2021/10/30
- ライブモデリングとコーディングで理解するDDD (DDD勉強会2021#1)
2021/10/21
- mercari.go #17 オンライン開催
2021/10/20
- Go Language Specification 輪読会 #30
2021/10/06
- Go Language Specification 輪読会 #29
2021/09/22
- Go 1.18+ 言語仕様勉強会 #2 【Generics】
2021/09/11
- DDD質問箱のつまみ喰い - 1軒目
2021/09/08
- Go Language Specification 輪読会 #28
2021/09/07
- モデリングの学び方：座談会
2021/09/01
- LAPRAS公開設計レビュー「t_wadaさんにこのテストでサバンナを生き抜けるか聞いてみた」
2021/08/25
- Go Language Specification 輪読会 #27
2021/08/22
- Kyoto.go remote #23 golang/go の Issues を読み漁る会
2021/08/11
- GeekGig #1 〜Goと私の一年〜
2021/08/01
- Type Sets Proposal 勉強会
2021/07/31
- エリック・エヴァンスのドメイン駆動設計輪読会「第17章戦略をまとめ上げる&エピローグ」
2021/07/26
- Merpay Tech Fest 2021
2021/07/21
- Go Language Specification 輪読会 #26
2021/07/20
- DMM.go #3
2021/07/19
- mercari.go #16 オンライン開催
2021/07/17
- エリック・エヴァンスのドメイン駆動設計輪読会「第16章大規模な構造」後半
2021/07/14
- Go Language Specification 輪読会 #25
2021/07/06
- 吉祥寺.pm27【オンライン】
2021/07/03
- エリック・エヴァンスのドメイン駆動設計輪読会「第16章大規模な構造」前編
2021/06/25
- Future Tech Night #12～Goで始めるサーバレスファーストという選択肢～
2021/06/24
- Kubernetes Meetup Tokyo #42
2021/06/23
- Go Language Specification 輪読会 #24
2021/06/22
- 【出版記念オンラインイベント】生産性を最大化する！『チームで育てるAndroidアプリ設計』
2021/06/20
- Kyoto.go remote #21 Discord もくもく会
2021/06/19
- エリック・エヴァンスのドメイン駆動設計輪読会「第15章蒸留」後編
2021/06/16
- iOS Tech Talk 〜 Multi module 戦略座談会〜
2021/06/11
- Infra Study 2nd #2「クラウドネイティブを支えるインフラ技術」
2021/06/10
- Fukuoka.go#17 (オンライン開催)
2021/06/09
- 公開設計レビュー「LAPRASのDB設計についてそーだいさんに相談してみた」
2021/06/09
- Go Language Specification 輪読会 #23
2021/06/08
- 『ドメイン駆動設計入門』×『事業をエンジニアリングする技術者たち』パネルディスカッション
2021/06/05
- エリック・エヴァンスのドメイン駆動設計輪読会「第15章蒸留」前編
2021/05/30
- Kyoto.go remote #20 Discord LT会
2021/05/28
- The Global Dev Study #2 - JAMstack
2021/05/26
- Chatwork Dev Day 2021
2021/05/26
- Go Language Specification 輪読会 #22
2021/05/25
- 『レイヤードアーキテクチャと Redux』～ FPUI 研究ラジオ #3
2021/05/22
- エリック・エヴァンスのドメイン駆動設計輪読会「第14章モデルの整合性を維持する」後編
2021/05/21
- Future Tech Night #10 ～進化するJava。標準API/Tomcat編～
2021/05/20
- 製造現場を変えろ。ソフトウェアエンジニアが挑む爆速DX
2021/05/17
- GaaS Study #1 ー平井大臣に聞く、デジタル庁が解くべき課題とITエンジニアの役割
2021/05/12
- Go Language Specification 輪読会 #21
2021/05/08
- エリック・エヴァンスのドメイン駆動設計輪読会「第14章モデルの整合性を維持する」中編
2021/04/25
- Kyoto.go remote #19 GoCon感想戦
2021/04/24
- Go Conference 2021 Spring (Online)
2021/04/24
- エリック・エヴァンスのドメイン駆動設計輪読会「第14章モデルの整合性を維持する」前編
2021/04/22
- Go Conference 2021 Spring Online 前夜祭
2021/04/21
- Go Language Specification 輪読会 #20
2021/04/20
- 吉祥寺.pm26【オンライン】
2021/04/15
- 入門Go言語仕様輪読会第3回（初心者でも丁寧にサポート）
2021/04/07
- Mercari Platform Group Tech Talk #1 (Day2)
2021/04/07
- Go Language Specification 輪読会 #19
2021/04/03
- エリック・エヴァンスのドメイン駆動設計輪読会「第12、13章」
2021/03/31
- サーバーレスアンチパターン今昔物語最終回
2021/03/26
- 『クライアントサイド DDD を考える』～ FPUI 研究ラジオ #2
2021/03/25
- Kubernetes Meetup Tokyo #40
2021/03/24
- Go Language Specification 輪読会 #18
2021/03/21
- Kyoto.go remote #18 Discord LT会
2021/03/20
- エリック・エヴァンスのドメイン駆動設計輪読会「第11章アナリシスパターンを適用する」
2021/03/19
- Future Tech Night #7 〜フューチャーの開発事例と共に学べるGo勉強会〜
2021/03/18
- 入門Go言語仕様輪読会第2回（初心者でも丁寧にサポート）
2021/03/15
- HTTP/Tokyo #2 (オンライン開催)
2021/03/10
- Go Language Specification 輪読会 #17
2021/03/08
- GCPUG Tokyo GKE Day March 2021
2021/03/06
- エリック・エヴァンスのドメイン駆動設計輪読会「第10章しなやかな設計」後半
2021/03/03
- オンライン開催【シューマイ】Tech Lead Engineerから最新技術を学べ！Go編
2021/03/02
- Monthly AWS Serverless Update 2021/02
2021/02/24
- Go Language Specification 輪読会 #16
2021/02/21
- Kyoto.go remote #17 Discord LT会
2021/02/20
- エリック・エヴァンスのドメイン駆動設計輪読会「第10章しなやかな設計」前半
2021/02/19
- GAE 1st Gen Migration Plan Discussion Day Part 2
2021/02/18
- 入門Go言語仕様輪読会（初心者でも丁寧にサポート）
2021/02/13
- 『ドメイン駆動設計入門』パネルディスカッション with レビュアーズ
2021/02/10
- Go Language Specification 輪読会 #15
2021/02/06
- エリック・エヴァンスのドメイン駆動設計輪読会「第9章暗黙的な概念を明示的にする」後半
2021/02/05
- mercari.go #15 オンライン開催
2021/02/03
- Monthly AWS Serverless Update 202101
2021/01/28
- Container Runtime Meetup #3
2021/01/28
- エムスリーアンケートシステムの技術：マイクロサービス/認証
2021/01/27
- merpay Tech Talk ~ BackendのテストとQAのフレームワークとツールについて
2021/01/27
- Go Language Specification輪読会 #14
2021/01/26
- Infra Study Meetup #10 パネルディスカッション - 2021年インフラ始め編
2021/01/23
- エリック・エヴァンスのドメイン駆動設計輪読会「第9章暗黙的な概念を明示的にする」前半
2021/01/20
- メルペイCTO & CBOによる、Fintech業界現在のトレンドと未来の話（つづき）
2021/01/16
- Kyoto.go remote #16 あけましてLT会
2021/01/15
- Qiita Advent Calendar Online Meetup
2021/01/13
- Go Language Specification輪読会 #13
2021/01/09
- エリック・エヴァンスのドメイン駆動設計輪読会「第8章ブレイクスルー」

Github

2021/10/16
- yyh-gl/gomish
2021/03/31
- yyh-gl/yyh-gl.deno.dev
2021/03/07
- yyh-gl/JetBrainsIDE-settings
2021/01/04
- yyh-gl/cron-jobs

LAPRASポートフォリオはこちらから

徒然なるままに go build と build tag を見ていく

Sun, 19 Dec 2021 09:00:00 +0900

本記事は『Go #1 Advent Calendar 2021 19日目』の記事です。

はじめに

Goには標準で便利なコマンドがたくさんあります。

有名どころで言えば、

generate
fmt
vet

などがあります。

中でも、Goのコードをコンパイルするためのbuildコマンドは、みなさんも日頃の開発で使用しているのではないでしょうか。

buildは特に難しいことをしなければ、とてもシンプルに使えるコマンドです。
よって、直感的に「こうすればコンパイルできるんでしょー」くらいの感覚で、ドキュメントを注視しなくても使い始められるでしょう。

しかし、buildは深く見ていくと意外と奥が深いコマンドです。
今回はそんなbuildについて深ぼっていこうと思います。

`build`コマンドとは

まずはbuildとはどういったコマンドなのか見ていきましょう。

helpを使って調べてみます。

$ go help build
Build compiles the packages named by the import paths,
along with their dependencies, but it does not install the results.
<省略>
When compiling packages, build ignores files that end in '_test.go'.
<省略>
When compiling multiple packages or a single non-main package,
build compiles the packages but discards the resulting object,
serving only as a check that the packages can be built.
<省略>
-tags tag,list
a comma-separated list of build tags to consider satisfied during the
build. For more information about build tags, see the description of
build constraints in the documentation for the go/build package.
(Earlier versions of Go used a space-separated list, and that form
is deprecated but still recognized.)
<省略>

buildはコンパイルするやつですよという文章から始まり、いろいろ書かれていますが、今回は以下の4点について見てみます。

【2020年】アクティビティまとめ

Tue, 23 Feb 2021 18:41:54 +0900

LAPRASでおもしろい機能を見つけた

LAPRAS に2020年のアクティビティをまとめてくれる機能がありました。
今回はその機能を使って（今さらながら）去年のアクティビティをメモしておきたいと思います。

以下、LAPRASで出力されたアクティビティを転記したものです。

・

2020年のアウトプットと参加イベントを振り返ると

今年アウトプットしたものや参加したイベントなどをまとめてみました。

connpass

2020/12/23
- サーバーレスアンチパターン今昔物語第八夜サーバーレスゆく年くる年2020/2021
2020/12/22
- merpay Tech Talk｜QAx DevOps/マイクロサービス/Backend vol.2
2020/12/21
- Software Design 1月号［第1特集］Goプログラミングスキルをレベルアップ執筆者座談会
2020/12/19
- エリック・エヴァンスのドメイン駆動設計輪読会「第7章言語を使用する：応用例」
2020/12/16
- Go Language Specification輪読会 #12
2020/12/15
- Front-End Study #2「Performance Tuning in depth（仮）」
2020/12/09
- Go Language Specification輪読会 #11
2020/12/05
- エリック・エヴァンスのドメイン駆動設計輪読会「第6章ドメインオブジェクトのライフサイクル」後編
2020/12/03
- merpay Tech Talk ~ 決済基盤（Payment Platform）Backend裏話
2020/11/30
- DMM meetup #22 〜DMMのプラットフォームが目指す経済圏とパーソナライズ戦略〜
2020/11/27
- Sandbox Live 第2回目〜ゲスト: ミノ駆動さんととーますさん〜
2020/11/27
- サーバーレスアンチパターン今昔物語第七夜
2020/11/26
- merpay Tech Talk〜DevOpsxQA、マイクロサービスxQA、BackendxQA〜
2020/11/21
- エリック・エヴァンスのドメイン駆動設計輪読会「第6章ドメインオブジェクトのライフサイクル」前編
2020/11/18
- 開発ライブ実況 #7 高難易度Goクイズ大会
2020/11/14
- Umeda.go 2020 Autumn Online
2020/11/11
- Go Language Specification輪読会 #10
2020/11/11
- オンライン開催【シューマイ】Tech Lead Engineerから最新技術を学べ！マネジメント編
2020/11/07
- エリック・エヴァンスのドメイン駆動設計輪読会「第5章ソフトウェアで表現されたモデル」（後編）
2020/11/05
- Monthly AWS Serverless Update 202011
2020/11/04
- 開発ライブ実況｜メルカリのUIをJetpack Composeで再現してみよう
2020/11/02
- Gophers Office Hours #14 Goとセキュリティ vol.2
2020/10/28
- Go Language Specification輪読会 #9
2020/10/24
- エリック・エヴァンスのドメイン駆動設計輪読会「第5章ソフトウェアで表現されたモデル」（前編）
2020/10/23
- 【オンライン開催】銀座Rails#26@リンクアンドモチベーション
2020/10/22
- サーバーレスアンチパターン今昔物語第六夜
2020/10/19
- Gophers Office Hours #13 〜セキュリティ回〜
2020/10/14
- Go Language Specification輪読会 #8
2020/10/13
- Gophers Office Hours #12 〜IoT, スマートホーム回〜
2020/10/10
- エリック・エヴァンスのドメイン駆動設計輪読会「第4章ドメインを隔離する」
2020/10/10
- Go Conference ‘20 in Autumun SENDAI
2020/10/09
- そーだいなるVOYAGE GROUPの裏側 #Zucks フルサイクル開発者の文化
2020/09/30
- Go Language Specification輪読会 #7
2020/09/29
- サーバーレスアンチパターン今昔物語第五夜 - 解体新書 -
2020/09/26
- エリック・エヴァンスのドメイン駆動設計輪読会「第3章モデルと実装を結びつける」
2020/09/25
- MediaDo.go #2
2020/09/23
- オンライン開催【シューマイ】Tech Lead Engineerから最新技術を学べ！Go編
2020/09/23
- サーバーレスアンチパターン今昔物語番外編
2020/09/16
- Go Language Specification輪読会 #6
2020/09/16
- 開発ライブ実況 #5 デバッグしているところを見てみよう (メルペイBackendエンジニア)
2020/09/09
- サーバーレスアンチパターン今昔物語第四夜 - 夏の残り香 -
2020/09/08
- Gophers Office Hours #10 〜コンパイラ、低レイヤ回 vol.2〜
2020/09/05
- エリック・エヴァンスのドメイン駆動設計輪読会「第2章コミュニケーションと言語の使い方」
2020/09/02
- Go Language Specification輪読会 #5
2020/08/31
- (Online only) Go 1.15 Release Party in Japan
2020/08/25
- Gophers Office Hours #9 〜静的解析回〜
2020/08/22
- エリック・エヴァンスのドメイン駆動設計輪読会「第1章知識をかみ砕く」
2020/08/19
- Go Language Specification輪読会 #4
2020/08/18
- Gophers Office Hours #8 〜自作コンパイラ、低レイヤ回〜
2020/08/12
- 開発ライブ実況#3 エディタの設定しない人編 byメルペイExpertチームBackendエンジニア
2020/08/11
- Gophers Office Hours #7 〜とにかく溜まった質問に答える回〜
2020/08/08
- エリック・エヴァンスのドメイン駆動設計輪読会 1回「序文、目次、索引」
2020/08/06
- mercari.go #14 オンライン開催
2020/08/05
- Go Language Specification輪読会 #3
2020/08/01
- TDD Boot Camp 2020 Online #1
2020/07/29
- 開発ライブ実況 #2 〜メルペイ Solutionsチームデフォルト好きエンジニア〜
2020/07/28
- Gophers Office Hours #6 〜gRPC回〜
2020/07/22
- Go Language Specification輪読会 #2
2020/07/18
- Zli × DMM 合同LT
2020/07/18
- Container Runtime Meetup #2
2020/07/15
- 開発ライブ実況〜メルペイ Architectチーム Backend Engineer〜
2020/07/14
- Gophers Office Hours #5 〜API、アーキテクチャ回〜
2020/07/14
- Fukuoka.go#16 (オンライン開催)
2020/07/09
- サーバーレスアンチパターン今昔物語
2020/07/08
- go/analysisでテストファイルかどうか確かめる方法について説明する会
2020/07/08
- Kyoto.go remote #6
2020/07/08
- Go Language Specification輪読会 #1
2020/06/30
- 【オンライン】Mercari Gophers Office Hours_6/30
2020/06/26
- #7 Open Go Friday Online
2020/06/24
- Kyoto.go remote #5
2020/06/23
- 【オンライン】Mercari Gophers Office Hours_6/23
2020/06/20
- コードを読もうぜ！～Laravel編～
2020/06/10
- Kyoto.go remote #4
2020/06/03
- 【オンライン】プログラミング言語Go完全入門質問会
2020/05/29
- 【オンライン開催】GCPUG Tokyo Spanner Day May 2020
2020/05/15
- 【オンライン開催】DMM.go #2
2020/05/06
- チームリーディング　フロントエンドコンポーネントの指針【オンライン】
2020/05/04
- テスト駆動開発(TDD)オンライン勉強会 #1 「TDD入門」
2020/05/02
- 【オンライン】実践クリーンアーキテクチャ
2020/04/20
- DDD Talk MeetUp Online #0
2020/04/16
- DDDオンライン勉強会 #4「DDDのアーキテクチャ」
2020/03/29
- DDDオンライン勉強会「設計の基本原則"高凝集・低結合"とアーキテクチャ」
2020/03/15
- DDDオンライン勉強会「集約・境界付けられたコンテキスト・設計の基本原則」
2020/03/08
- ドメイン駆動設計モデリング/実装入門勉強会(オンライン)
2020/02/27
- ゴリラ.Go #1
2020/02/16
- Object-Oriented Conference
2020/02/16
- （本募集）Object-Oriented Conference
2020/02/10
- mercari.go #13
2020/01/28
- DeNA.go #4
2020/01/23
- DMM.go #1
2020/01/10
- DDD Talk MeetUp #3

Github

2020/09/22
- yyh-gl/delsla
2020/09/07
- yyh-gl/go-flat-package
2020/08/27
- yyh-gl/real-env-recorder
2020/08/24
- yyh-gl/yyh-gl
2020/08/02
- yyh-gl/akindo
2020/08/01
- yyh-gl/tdd_handson
2020/07/19
- yyh-gl/tdd_handson_demo
2020/06/21
- Ladicle/tcardgen
2020/06/12
- yyh-gl/go-ec2
2020/05/26
- yyh-gl/gocr
2020/05/17
- yyh-gl/go-playground
2020/05/14
- yyh-gl/goa-tutorial
2020/04/11
- yyh-gl/go-starter-kit
2020/01/24
- yyh-gl/go-assembler

LAPRASポートフォリオはこちらから

【GitHub Actions】GitHubのプロフィールを自動更新する仕組みを作った

Fri, 19 Feb 2021 18:53:19 +0900

おもしろいツイートを見つけた

GitHub ActionsでQiita/Zennの投稿をGitHubプロフィールに自動反映できるようにした pic.twitter.com/o47E7YHSsx
— mikkame (@mikkameee) February 14, 2021

とても便利そうだったので僕もやってみました。

作った

↑こんな感じで Recent posts - Blog 📝 に直近5個のブログ記事を表示するようにして、
なおかつ自動で更新されるようにしました。

コードはこちらに置いてあります。

やっていることはとてもシンプルで、
Goで書いたプロフィール（README）更新スクリプトをGitHub Actionsで実行しているだけです。

興味あったらコードを覗いてみてください。

The Go Programming Language Specificationで知った「こんなことできるだ」を紹介

Tue, 08 Dec 2020 09:00:00 +0900

本記事は『Go 5 Advent Calendar 2020 8日目』の記事です。

Go Language Specification輪読会

現在、Go Language Specification輪読会という、 Goの言語仕様を読んでいく会に参加しています。

今回は、そんな輪読会で「こんなことできるんだ」と驚いたコードを紹介します。
（振り返ると結構たくさんあったので、今回はその中から5個選んで紹介します）

ちなみに、だいたいのコードは現場で使うと怒られそうです😇
（いや、まず間違いなく怒られる）

1. Comments

package main
import (
"fmt"
)
func main() {
var/*comment*/a = 1
fmt.Println(a)
}

https://play.golang.org/p/9Dun0LiT5N5

まずはこちら。
変な位置にコメントが挿入されています。
コメント部分を消すとvara = 1となるのでエラーになりそうです。

しかし、実行してみると、すんなりと変数aを表示してくれます。

解説

Spec を参照すると以下の一文があります。

A general comment containing no newlines acts like a space.

改行を含まないgeneral commentはスペースのように作用する。

（general commentとは/**/で囲われたコメントのことを指します）

よって、先程のコードは以下と同じということです。

package main
import (
"fmt"
)
func main() {
var a = 1
fmt.Println(a)
}

こうして変換してみると、エラーでないことは明白ですね。

ブログの画像をWebPに変えた話とSafariで表示されない件について

Thu, 26 Nov 2020 13:50:31 +0900

画像の形式をWebPに変えた

本ブログにて、Lighthouse使ってみると、表示速度あたりで怒られていたので、
まずはサムネ画像をWebPに変えてみました。

WebPとは、Googleが開発しているオープンな静止画像フォーマットで、
トラフィック量軽減と表示速度短縮を目的しています。（wikiから拝借）

WebPを採用した結果

以下のツイートのとおりです。

たまたま100が撮れただけで、もう一回テストしみると少し落ちました。
それでも90台はキープできていそうです。

個人ブログ（Desktop版）のPerformanceが78だったので、画像をwebpに変えたら一気に100になった🎊
（モバイルは未だに70切ってる😇） pic.twitter.com/VNxztIsR28
— hon-D (@yyh_gl) November 19, 2020

Safariでは注意が必要

多くのブラウザでWebPへの対応が既に完了しています。
ただし、Safariに関してはv14でようやく対応しました。

対応状況

Safari v14は2020年9月17日（日本時間）にリリースされたばかりなので、
まだ画像をちゃんと見れないユーザが多く存在すると思われます。

リリースノート

Safariのwebp対応ってバージョン14からだったんだ😇

自分のブログに来る人の90%弱がSafariじゃないから、まぁいいか←
— hon-D (@yyh_gl) November 26, 2020

自分のブログに来る人の90%弱がSafariじゃないから、まぁいいか←

嘘です、10%ほどの方々すみません🙇‍♂
WebPにしたのはサムネ画像だけで、記事本文内の画像はWebPじゃないので許してください。。。

【Go】Switch文のfallthroughに関するまとめ

Sat, 03 Oct 2020 09:00:00 +0900

fallthrough とは

GoではSwitch文でfallthroughというキーワードが使用可能です。

機能としては、処理を次の節（caseやdefault）に進めます。（参考）
言葉で説明するよりも、サンプルコードを見てもらった方がイメージしやすいと思います。

package main
import "fmt"
func main() {
num := 1
switch num {
case 1:
fmt.Print("I ")
fallthrough
case 2:
fmt.Print("am ")
fallthrough
case 3:
fmt.Println("yyh-gl.")
// fallthrough // 次の節がなければコンパイルエラー
}
}
// 実行結果：
// I am yyh-gl.

Playground

defaultにも飛べるという例

fallthroughは、Go言語のORMライブラリとして有名な『GORM』でも使用されています。(使用箇所 )

texta.fm #1 まとめ

Thu, 01 Oct 2020 09:00:00 +0900

texta.fm

texta.fm #1（2020年8月27日放送分）を聞いて、特にDDDについて学びが多かったのでまとめました。

エヴァンス本を読む前に知っておいた方がいい時代背景、そして、意識すべき点を知ることができるので、
時間があればぜひ実際に聞きに行ってみてください。

話者：

@_yasaichi さん
@t_wada さん

以降、勉強になった点を抜き出していきます。
なお、<>内に記載している時間は、記述内容が実際に話されている時間を示しています。

DDDが解決したかった問題

<6分30秒ぐらいから>

エリック・エヴァンスがDDDで解決しようとしていた問題は以下の2点

分析モデルとコード間の乖離：詳細は後述
ビジネス側と開発側の乖離：ビジネス側の言葉と開発側の言葉が異なることによる開発の複雑化

分析モデルとコード間の乖離ってなに？

<9分45秒ぐらいから>

2000年代前半はフェーズで区切ったソフトウェア開発が主流だった。
そして、その区切られたフェーズのひとつである「モデリングフェーズ」では、
分析や設計を通してモデルを作り上げていくのであるが、
開発の対象領域をきちんと写し取った抽象的なモデル（分析モデル）を作ることが最大の目的であった。

しかし、開発フェーズに入った時、分析モデルでは不完全なことが多かった。
よって、開発で使えるように修正が加えられ、最終的には分析モデルとは全く異なるモデルができあがる。

コードを書かないと分からないこと、実際にシステムが使われ始めないと分からないことがたくさんあるので、当然の結果である。

解決策：改善のループを回そう

<17分20秒ぐらいから>

分析モデルとコード間の乖離を解決するために、
分析モデル→開発時のモデルの一方通行ではなく、
開発時のモデル↔分析モデルのように両方向にフィードバックする。
そして、フィードバックをもとに改善のループを回していくことが重要。
（＝アジャイルソフトウェア開発時代の改善ループの回し方）

今はあまり分析モデルとコード間の乖離が問題にならない

<25分00秒ぐらいから>

現在ではあまり分析モデルとコード間の乖離が問題にならない。
理由としては、分析モデルの作成フェーズ（モデリングフェーズ）と開発フェーズを担当する人が同じになってきたから。

昨今の開発ではこうした開発体制が普通になっているので、
そもそも今いる大半のエンジニアにはイメージがつきにくい事象である。

したがって、現在は、DDDと言われるとビジネス側と開発側の乖離に注目が行きがち。

エヴァンス本から学ぶべき大事なこと

<21分40秒ぐらいから>

コードとドメイン知識間の乖離を無くし、
一致させ続ける反復的作業こそが大事であると訴えたことがとても良かった。

つまり、先述したとおり、
フィードバックが 分析モデル→開発時のモデルの一方通行 だったものを
開発時のモデル↔分析モデルのような両方向 にしようと提唱したことこそが最重要。

ここを意識して学ぼう！

<33分00秒ぐらいから>

デザインパターンの部分（2部、3部あたり）はもちろん大事であるが、
エヴァンス本の本質的な部分ではない。

【Go+DDD】エンティティと値オブジェクトの実装方法（自己流）

Fri, 08 May 2020 09:00:00 +0900

GoでDDD

今担当しているプロジェクトでは、GoでAPIを作っています。
このプロジェクトでは、DDDの考え方や設計パターンも取り入れています。

今回はDDDの設計パターンの中でもEntityとValue Object（VO）について、
僕がGoでどうやって実装しているのか紹介していきます。

実装例

兎にも角にも、まずはコードを示します。

// animal/dog/dog.go
package dog
type Dog struct {
name Name
}
func New(name string) (*Dog, error) {
n, err := newName(name)
if err != nil {
return nil, err
}
return &Dog{
name: *n,
}, nil
}

// animal/dog/name.go
package dog
import (
"errors"
"unicode/utf8"
)
type Name string
func newName(v string) (*Name, error) {
// 名前は3文字以上というビジネスロジック
if utf8.RuneCountInString(v) < 3 {
return nil, errors.New("名前は3文字以上！")
}
n := Name(v)
return &n, nil
}

// main.go
package main
import (
"fmt"
"playground/animal/dog"
)
func main() {
// d := dog.Dog{name: "犬太郎"} できない
d, _ := dog.New("犬太郎") // できる
fmt.Printf("%+v\n", d)
d, err := dog.New("犬")
if err != nil {
fmt.Println(err) // 犬の名前が「犬」は可愛そうだからできない()
}
}

playground

go test におけるキャッシュの消し方

Thu, 30 Apr 2020 09:00:00 +0900

go test のキャッシュを消すのは簡単

$ go clean -testcache

以上です！

$ go test ./...
ok github.com/oxequa/realize (cached)
ok github.com/oxequa/realize/realize (cached)

このように (cached) となっていたものが、、、

$ go clean -testcache
$ go test ./...
ok github.com/oxequa/realize 0.086s
ok github.com/oxequa/realize/realize 0.389s

このように、実行時間が表示されており、キャッシュが消えていることが分かりますね。

ちなみに、キャッシュを無視する方法はもうひとつあり、
以下のように -count=1 をつけてやればOKです。

$ go test ./... -count=1
ok github.com/oxequa/realize 0.076s
ok github.com/oxequa/realize/realize 0.384s

ここからは上記コマンドが一体なにをしてくれたのか、
もう少し詳細に話していきます。

go clean とは

こちらにドキュメントがあります。

Clean removes object files from package source directories.

【Go】jsonパッケージの知っておくと便利な機能

Sun, 26 Apr 2020 09:00:00 +0900

jsonパッケージ

Goを触ってる人ならだれもが一度はお世話になるであろうパッケージ「json 」

今回はそんな json パッケージについて、
知っておくと便利な機能を2つ紹介します。

（比較的有名なものしかないですが🙏）

1. 独自の変換ロジックを実装できる

例えば、下記のコードのように、
ある構造体（Human）のフィールドを外部公開したくない場合、
jsonパッケージの Unmarshal()，Marshal() が使えません。
（上記関数は外部公開されたフィールドのみ変換できる）

type Human struct {
// フィールドを外部公開したくない
name string
age int
}
func main() {
h := Human{
name: "Taro",
age: 21,
}
// 構造体 → JSON
j, _ := json.Marshal(h)
fmt.Println(string(j)) // {}
// JSON → 構造体
var uh Human
_ = json.Unmarshal(j, &uh)
fmt.Printf("%+v\n", uh) // {name: age:0}
}

playgroud

【Go】errorの同値性と表示について調べた

Tue, 10 Mar 2020 09:00:00 +0900

errorについて疑問があった

Goのコードを書いてて、ふと気になったことがあったので調べてみました。

errorの同値性

1つ目の疑問は、下記コードで e1 と e2 がイコールではないことです。
（同値性なんて仰々しく言ってすみません。たったこれだけの疑問です😇🙇‍♂️）

func main() {
e1 := errors.New("error1")
e2 := errors.New("error1")
e3 := e1
fmt.Println(e1 == e2) // false
fmt.Println(e1 == e3) // true
}

Playground

結論（errorの同値性）

errors.New() が返しているのがポインタでした。

つまり、さきほどのコードの6行目はポインタの値を比較しているので、そりゃfalseになりますね。

errorの表示

2つ目の疑問は、下記コードで e1 を表示すると、
errors.New()の戻り値である構造体の値ではなく、エラー文言が表示されることです。

package main
import (
"fmt"
"errors"
)
func main() {
e1 := errors.New("error1")
fmt.Println(e1) // error1
}

Playground

errors.New()が返しているのは構造体なので、
下記コードのように構造体の内容が表示されないのはなんでだ？ってなったわけです。

package main
import "fmt"
func Hoge() interface{} {
type hoge struct {
s string
}
return &hoge{s: "hoge"}
}
func main() {
h := Hoge()
fmt.Println(h) // &{hoge}
}

Playground

【Go】errorsパッケージの中身覗いてみた

Mon, 09 Mar 2020 09:00:00 +0900

errorsパッケージに興味持った

v1.13からerrorsパッケージに Unwrap() Is() As() といった関数が追加されました。
（もう1.14もリリースされているのに今さらですね😇）

今回はこれら3つの関数について、内部実装を追いかけていきます。

と、その前に、errorsパッケージの概要と関連パッケージについて軽く説明しておきます。

errorsパッケージと関連パッケージ

errorsパッケージ

名前の通り、エラー関連の処理がまとまっているパッケージですね。
Goの標準パッケージです。
→ GoDoc

v1.13にて、先述の Unwrap() Is() As() という関数たちが追加されました。

errorを扱うパッケージとして、もうひとつ有名なパッケージがあります。
xerrorsパッケージです。

xerrorsパッケージ

xerrors とは、 Goのサブリポジトリで開発が進められているパッケージです。
（準標準パッケージといった感じでしょうか）

xerrorsのGoDoc に下記の記述がある通り、

These functions were incorporated into the standard library’s errors package in Go 1.13: - Is - As - Unwrap

もともとは本パッケージに Unwrap() Is() As() が実装されていましたが、
v1.13にて標準パッケージに取り込まれました。

さて、軽くerror関連のパッケージについて触れたところで、
早速、Unwrap() Is() As() の内部実装を見ていきたいと思います。
なお、Goのコードはv1.14.0を参照しています。

Unwrap()

ラップされたエラーから中身のエラーを取り出す関数です。

処理としては下記のようになっています。

func Unwrap(err error) error {
u, ok := err.(interface {
Unwrap() error
})
if !ok {
return nil
}
return u.Unwrap()
}

https://golang.org/src/errors/wrap.go?s=372:400#L14

Goのバージョン管理について

Tue, 03 Mar 2020 09:00:00 +0900

Goのバージョン管理

注意1：本記事はGo自体のバージョン管理についてです。Go Modulesなどは対象外です。
注意2：基本的にMacユーザを対象にしています。（WindowsとLinuxももちろん好きです）

開発において言語のバージョン管理はつきものだと思います。
そのニーズは高く、rbenv や nodenv といったバージョン管理ツールが普及しています。

ただし、Goの場合は少し話が変わってきます。
もちろんGoでも goenv が用意されていますが、
（今のところ）Goは後方互換性が担保されているので、基本的に最新バージョンに上げ続ければOKです。

…と言いつつも、GAEを使用するといった場合に、どうしてもバージョン管理したくなることがあると思います。

そこで今回はまずGoのバージョン管理ツールの紹介をした後で、
最新バージョンをインストールする方法を紹介していきたいと思います。

Goのバージョン管理ツール

▼ goenv

◯◯env系は有名ですよね。
言語のバージョン管理といえばこれです。

導入手順は公式の手順通りなので省略します。

1点はまりどころがあります。
$GOPATHが変わらなくなってしまうという問題です。

本件に関しては以前、僕のブログで対処法を書いているので、
こちらを参考にしてみてください。

▼ go get（公式サイトに記載のある方法）

（バージョン管理"ツール"とは言えませんが…）

本方法は公式サイトに記載されている方法です。

$ go get golang.org/dl/goX.Y.Z
$ goX.Y.Z download
$ goX.Y.Z version
go version goX.Y.Z linux/amd64

コマンド打つたびに、バージョンまで打つのがめんどくさいという方は、
bash や zsh の設定でエイリアスでも貼ってやればOKですね。

【DDD】集約とトランザクション境界について調べたことメモ

Tue, 18 Feb 2020 09:00:00 +0900

簡単まとめシリーズ

今回は 集約とトランザクション境界 について、
自分のわからないところを調べたので、メモとして残しておきます。

集約

集約の説明を『ドメイン駆動設計入門ボトムアップでわかる! ドメイン駆動設計の基本』から拝借すると、
「データを変更するための単位として扱われるオブジェクトの集まりを集約といいます」とのこと。

↓ もうすこし具体的に言うと

DDDではエンティティと値オブジェクトというものがありますが、
値オブジェクトを直接触らず、エンティティ経由でしか変更しないようにするというものですね。

このような制限をかけることで、
ひとまとまりにされたオブジェクト間で維持されるべき不変条件を守ることができます。

トランザクション境界

基本的な考えとしては、集約ごとにトランザクションを貼ります。

↑この基本を守るためにも、理想としては正しいモデリングにより、
正しいトランザクション境界を見つけることが大事です。

正しいトランザクション境界を見つけることは、不用意に大きなDBロックの発生を防止します。

しかしながら、集約をまたいでトランザクション制御したくなるときもあります。
→ 参考例

こういうときにどうするか、上記リンクでもいくつかの方法が挙げられています。
他のサイトも調べてみましたが、だいたい同じような方法が出てきました。

結果整合性

主流っぽい
- いろいろなサイト、書籍の中で紹介されていました
整合性を担保するための仕組みづくりが必要
- 整合性をチェックするためのバッチなど

集約をまたいでトランザクションを貼る

下記理由のためにあまり推奨されない
- ロック範囲が大きくなってしまう
- 守るべき「データの一貫性の境界」をコード上で表現できなくなる
  - 参考サイト

複数の集約をさらにまとめた集約をつくる

ロック範囲が大きくなってしまうため、あまり推奨されない

結果整合性

結果整合性については、
『ドメイン駆動設計入門ボトムアップでわかる! ドメイン駆動設計の基本』の
12章3説「集約の大きさと操作の単位」で言及されているので、もう少しだけ詳しく調べました。

結果整合性とは、最終的に整合性の取れていればOKという考え方。
したがって、整合性が取れていない状況が起こり得るが、それは許容する。

「最終的に整合性を取る」ってどうやるの？
→ こちらが参考になる。

まとめ

設計周りの話は、唯一無二の答えがあるわけではありません。

よって、今回の話においても「データの一貫性の境界」を意識し、
ちゃんとメリットとデメリットを理解した上で最善の解を選択する必要がありますね。

参考資料

【簡単まとめシリーズ】Go1.12からの変更点

Mon, 03 Feb 2020 09:00:00 +0900

簡単まとめシリーズ

『簡単まとめ』では、僕が記事や書籍で学んだ内容をメモ程度に簡単にまとめていきます📝

今回は Go1.12からの変更点 についてです。

The State of Go 2020

Twitterで『The State of Go 2020 』というタイトルのスライドを見つけました。

Go1.12から変わったところに焦点を当て、
Go1.13でどのような機能が追加されているのか、
Go1.14でどのような機能が追加される予定なのかまとめてあります。

今回は、完全主観で自分が興味のある内容をハイライトします〜😇

完全主観ハイライト

【merpay Tech Talk】マイクロサービスの冪等性に関する勉強会

Fri, 20 Dec 2019 09:00:00 +0900

Tech Talk vol.2 Backend Engineer 〜マイクロサービスの冪等性〜

connpass
ハッシュタグ：#merpay_techtalk
質問板

merpay社で開催された勉強会です。
参加者のツイートも含めてメモを残しておきます。

かなり雑なのでコンテキストが読み取れないところもあると思いますが、
なにかの参考になれば幸いです。

（@sonatard さんの実況にとても助けられました。ありがとうございました！）

1. 500万ユーザーを支える残高の冪等性

登壇者：（@knsh14）

~~スライド~~

参考スライド（ベースとなる話は↑これ）

残高管理サービス（Balance Service）

使ってるDBはCloud Spanner

外部サービスや他のマイクロサービスには依存してない

DeleteなしでCRUのみ

かなりシンプルで冪等性を担保しやすい

冪等性があるAPI

最初に成功した一度だけ処理される

同じリクエストを何回繰り返しても内部的には処理されない

何度リクエストしても同じ結果が返ってくる何度でもリトライできる

取引IDが保存されていれば既に行われた取引である

冪等性の担保

冪等性キーが同じ外部から指定される取引IDのこと
残高の種類が同じポイント/メイルペイ残高など
操作する金額が同じ

冪等なレスポンス

レスポンスはDBから引ける情報で組み立てる
取引IDから引ける情報
- 取引後残高は返さない

Twitterメモ

冪等なAPIでのエラー

リトライしても良いエラー：ex. タイムアウト
リトライだめなエラー：ex. 残高不足

誰がどう使うのか？

リクエストを投げる側の使い方1つで簡単に冪等性が壊れる → ex. 取引IDを毎回変えるとか

2. コード決済における冪等性と整合性

登壇者：（@susho0220）

スライド

モノリスであれば、リクエスト、レスポンス内のトランザクションで整合性を保てる。

マイクロサービスでは、トランザクションが分かれるため、
決済の進捗状態を保持するDBを用意し、状態を管理
→ Pending、Authorized、Captured

GolangCI-Lintの設定ファイルを理解する

Mon, 09 Dec 2019 09:00:00 +0900

DMM Advent Calendar 2019

本記事は DMM Advent Calendar 2019 の 9日目の記事です。

私は現在、DMM.com の CDS というチームに所属し、
主にユーザレビュー基盤のバックエンドを開発しています。

今回は、Go用Linterである GolangCI-Lint を軽く紹介した後に、
GolangCI-Lint のハマリポイントとその解決策である設定周りの話をします。

Linter 導入していますか？

突然ですが、みなさんの開発環境には Linter が導入されているでしょうか？

私の所属するチームでは、
コーディング規約違反およびコンパイラでは見つけられないエラーを検知するために、
ローカルと CI において Linter を回すようにしています。

GoにおけるLinter

Goの場合、Linterがデフォルトで用意されているうえに、
ライブラリとして公開されているものも多く存在します。

なかでも有名なものに以下のようなものがあります。

govet：GoデフォルトのLinter
errcheck：ちゃんとエラーハンドリングしているかチェックしてくれる
unused：未使用の定義をチェックしてくれる
goimports：未使用のimportを消してくれたり、フォーマット修正してくれる
gosimple：コードをシンプルにしてくれる

しかしながら、多すぎるがゆえにどれを選択すればいいのか分からなくなりがちです。
加えて、導入する Linter が増えれば、その分だけ導入・管理コストが増加します。

この問題を解決してくれるツールが GolangCI-Lint です。

GolangCI-Lint

勉強会でもよく耳にするようになってきている＋多くの紹介記事があるので、
ここで詳しく説明する必要もないかもしれませんが、いちおう少しだけ触れておきます。

GolangCI-Lint とは、 GoのLinterを一元管理するためのツールです。
開発者は GolangCI-Lint を導入するだけで様々な Linter を実行することができます。

【Go+VCR】外部APIとの通信を保存してテストに使用する話

Sun, 08 Dec 2019 09:00:00 +0900

Go3 Advent Calendar 2019

本記事は Go3 Advent Calendar 2019 の 8日目の記事です。

ではでは、早速本題に入っていきます。

モック使ってますか？

みなさんモックコードは書いていますか？

テストコードを書いているなら、ほぼ必ず登場するあのモックです。
DB処理や関数のモックなどいろいろありますよね。

そんなモックコードですが、作ったり管理するのめんどくさいなぁとか思ってないですか？
モックだからといって雑なコードになっていませんか？

今回は、外部API通信のモック化にフォーカスし、
モックコードの作成・管理コストを軽減する
VCR ライブラリを紹介します。

VCR ライブラリとは？

VCR（Video Cassette Recorder）とは、通信を保存し、再生するライブラリです。

つまり、APIリクエストの初回通信の内容を保存し、
次回以降その保存内容（レスポンス）を使いまわしてくれるというものです。

言い換えれば、外部APIのモックを自動生成してくれるということですね！

VCR ライブラリ in Go World

Go用のVCRライブラリはいろいろあります。
スター数が多いのは以下のものです。

go-vcr および vcr-go，govcr の開発は盛んではないようです。

rpcreplay は google-cloud-go に包含されるパッケージであり、安心して使えそうです。
ただし、gRPC 用なので、その点は注意が必要です。
GoDocはこちらです。

今回は REST API を使って説明していくので、go-vcr を使用します。

go-vcr は、vcr-go と govcr よりスター数が多いです。
Ruby 製の vcr というライブラリがもとになっているようです。

【React+TypeScript】TypeScript入門

Mon, 02 Dec 2019 09:00:00 +0900

TypeScript Advent Calendar 2019

本記事は TypeScript Advent Calendar 2019 の 2 日目の記事です。

内容としては、TypeScript 初級者のための TypeScript 入門です。

基礎的な内容から入り、
最終的には、企業や個人の技術ブログを参考に、
React の実プロジェクトにおいて、
どのように TypeScript が使われているのか紹介できればと思います。
（APIリクエスト周りのTypeScript活用事例を紹介）

今日の記事を読んで TypeScript に入門し、
今後の TypeScript Advent Calendar をお楽しみいただけると幸いです！

基礎編

TypeScript とは

TypeScript は Microsoft 社によって開発され、現在は OSS として開発が進められています。

「TypeScript とは何か」を簡単に説明すると、
JavaScript に対して、省略も可能な静的型付けとクラスベースオブジェクト指向を加えたスーパーセットです。

公式サイトはこちらで、
2019年12月2日現在、最新版は 3.7.2 となっています。

では、実際にコードを交えながら基礎的な部分を説明していきます。
ただし、実践編で使用する内容に絞って説明していきますので、
その点はご了承ください🙇‍
（足りない情報は公式ドキュメントを参考にしてください）

型

では、早速、TypeScript の型に触れていきましょう。
TypeScript で使用できる基本的な型として以下のものがあります。

Boolean
Number
String
Array
Tuple
Enum
Any
Void
Null and Undefined
Never
Object

だいたいの型は他言語でも用意されているので、
説明がなくても理解できると思います。

【DeNA.go #3】Go活用事例やパフォーマンスチューニングの話聞いてきた

Fri, 01 Nov 2019 09:00:00 +0900

DeNA.go #3

connpass
ハッシュタグ：#DeNAgo

初参加です！
ビールとお弁当もらいました。

そしてなんとなんと
k8sの技術書をいただいちゃいました！！！
もちろんステッカーもありましたよ👍

1. [Go活用事例]安全運転支援サービスを支える運用サイト

登壇者：@suhirotaka さん
オートモーティブ事業本部スマートドライビング部システム開発グループ

スライド

主題

管理画面をGoで作成

Railsで作ってるものをGoで作る理由

実証実験時はスピード重視でRails
本サービスはパフォーマンス重視でGo

順次Goに書き換えていく

Goのフレームワーク

GoのWAF（Web Application Framework）には

フルスタック・MVC
ミニマル・高速

の2種類がある

この辺の話は、僕の旧ブログにもいろいろ書いているのでどうぞー

DeNAではフルスタック・MVCを選択

GoにおけるフルスタックなWAF

Beego：採用！
Revel：開発が止まってきている
Iris：プロジェクトの運用がうまくいっていないようだった

Beego

フルスタックのMVCフレームワーク
ORMまでついてる
セッション管理、ロガー、キャッシュなどのライブラリがいろいろついてるけど、全てモジュール化されていて、部分的に他のライブラリを使うことができる
Railsライクなフレームワーク
- Railsのbefore/after_actionに相当するものもある（Prepare(), Finish()）

ライブラリ

使用ライブラリはこちら

こういうの教えてくれるのめっちゃ嬉しい

ORM：GORM
ロガー：logrus
PDF生成：gopdf → 日本語もきれいにでるので最高にクール
画像生成：gg
バーコード生成：Barcode

2. WebシステムのパフォーマンスとGo

（写真撮り忘れた…）

登壇者：（@karupanerura）ゲーム・エンターテインメント事業本部ゲーム事業部Publish統括部共通基盤部アライアンスシステムグループ

スライド

Webシステムにおけるパフォーマンスとは

たくさんリクエスト処理できるかつリソース消費が少ないのが
システム全体で見たときの理想的なパフォーマンス

パフォーマンスチューニングのいろいろ

詳しいチューニング方法はこちら

【GitHub Actions】プライベートアクションを使ってみた

Tue, 22 Oct 2019 09:00:00 +0900

プライベートアクションとは

GitHub Actions では、開発者がアクション（Lint やテストといったジョブなど）を作って、公開することができます。
この公開されたアクションは、世界中の人が使えるため、もちろん自分のプロジェクトに持ってきて使用できます。
この公開されたアクションのことをパブリックアクションといいます。

パブリックアクションが溢れた世界を想像するだけでワクワクしますね👍
（野良 Docker イメージと同様に、ほいそれとは使えないでしょうが…）

今回、とりあげるのはパブリックアクションの正反対にあるものです。
つまり、公開しない（できない）アクション＝プライベートアクションです。

プライベートアクションを使うための準備

ディレクトリ構成は以下のとおりです。

.github
├── actions
│   └── golang-test
│   ├── Dockerfile
│   ├── action.yml
│   └── entrypoint.sh
└── workflows
└── golang.yml

/actions ディレクトリ配下に golang-test という、Lint とテストを実行するアクションを作ってみます。

/workflow ディレクトリ配下には、golang 用のワークフロー定義ファイルを置いています。

では、次から各ファイルの定義を見ていきます。

プライベートアクションの定義

# /actions/golang-test/action.yml
name: 'Golang Lint and Test Action'
description: 'Lint and Test for Golang'
author: 'yyh-gl'
runs:
# Docker を使って実行することを宣言
using: 'docker'
# 使用する Docker イメージを指定
image: 'Dockerfile'

アクションの定義は上記のとおりです。
公式ドキュメントを参考にしました。

【mercari.go #11】エラーハンドリング＋ singleflight ＋ ISUCON ベンチマーカー

Mon, 07 Oct 2019 09:00:00 +0900

mercari.go #11

connpass：リンク
ハッシュタグ： #mercarigo

今回もお弁当とドリンクがありました！ありがたや

[追記：2019年10月12日]
[Mercari Engineering Blog](https://tech.mercari.com/entry/2019/10/11/160000) にて、本イベントの記事が公開されました。
発表資料が載せてあります。ありがたや🙏

1. About error handling in Go

登壇者：jd さん（@JehandadKamal）

資料（正式に共有されたものでないので、発表の内容が少し異なります）

Errors are values

”Errors are values ” という考え方。

Goでよくあるエラー処理パターン

エラーをラップしてより詳細な情報を付与する
専用構造体を作る
スタックトレースを構成する

”Error is your domain”

Domain Error Struct を作成する。

type Error struct {
Op Op
Kind Kind
Serverity zapcore.ErrorLevel
Err error
}

Op：Operation → 関数名とか
Kind：エラー種別 → NotAvailable, NotFound といったもの
Serverity：エラーレベル
Err：エラー内容

上記のような構造体を作る理由

error を比較するときは、基本的に文字列の比較になるため取り回しが悪い
→ ”NotFound” という文字列を比較するとかとか

React.memo について調べたのでメモを残しておく

Wed, 18 Sep 2019 09:00:00 +0900

React.memo とは

公式ドキュメントを見ると、

これは React.PureComponent に似ていますが、クラスではなく関数コンポーネント用です。

とあります。

つまり、 React.PureComponent を関数コンポーネントで実現するための手段らしいです。

React.PureComponent とは

公式ドキュメントを見ると、

React.PureComponent は React.Component と似ています。両者の違いは React.Component が shouldComponentUpdate() を実装していないことに対し、 React.PureComponent は props と state を浅く (shallow) 比較することでそれを実装していることです。

とあります。

shouldComponentUpdate() によって、どういった変更があれば再描画するかを定義するようです。

追加でこの参考記事を読んでみると、

PureComonentはprops及びstateの変更を検出した場合のみレンダリングを行います。 Messageコンポーネントではmessage propsの変更を察知し、必要分の更新を行うようになります。

とあります。

自分で再描画条件を定義できるので、無駄な再描画を省くことができ、パフォーマンス向上を期待できるんですね。

→ React.PureComponent を用いることでパフォーマンスを向上させることができるようです。
（参考記事内にもあるとおり銀の弾丸ではないようですが…）

浅い比較とは

shouldComponentUpdate() は浅い比較によって変更検知を行う。

とありましたが、浅い比較とはなんでしょうか。
（shouldComponentUpdate() のデフォルトが浅い比較というだけで、オリジナルの比較方法を実装可能なようです）

さきほどの参考記事にて説明されていました。

浅い比較というのは、簡潔に述べるとオブジェクトの参照先が同じであれば等しいと見なすことです。

参照先しか見ていないので、中身は見ていないということですね。
（このような実装なのは、React の思想として、props や state といったデータは immutable であるべきだとしているからだと思います）

【Backend Engineer’s meetup】メルカリ社主催バックエンダーのための Meetup イベント行ってきた

Wed, 21 Aug 2019 09:00:00 +0900

Backend Engineer’s meetup マイクロサービスにおける認証認可基盤

connpass
ハッシュタグ：#merpay_meetup

メルカリさん恒例のオリジナルドリンクもらいました

1. マイクロサービスの内部通信における認証について

登壇者：@pospome さん

スライド（日本語が消えてしまっていますが、ダウンロードしたら見れました）

上記スライドの簡易メモ

アカウント管理とログイン処理はそれぞれのチームに任せている
- SubjectID という全サービス共通のID に変換して扱う
メルカリでは、OIDCベースの認可の仕組みを採用
- RFCに書いてあるものと大差ないので、今回は マイクロサービスの内部通信における認証 について話す
全サービスは Gatwway を経由
- Gateway から Authority Service にくる
Authority Service を認証基盤チームが管理
- 外部からのリクエスト検証と内部通信用のトークンを生成している
内部トークンは毎リクエストごとに生成
- マイクロサービス間で使用されるトークンはリクエスト単位で同一
内部トークン用のSDKを提供
- Goのみ対応
- SDKを使うといろいろとよしなにしてくれる
  - クレームをいい感じに取得
  - SubjectID のパースとかをいい感じにしてくれる
マイクロサービスはバッチのためのエンドポイントをもつことがあるので、Gatewayによってユーザが直接叩くことがきない環境を作れるのはメリットとなる

2. パネルディスカッション

登壇者：

Keigo Watanabe さん
@kazegusuri
@nerocrux
@pospome

パネルディスカッションのはずがほとんど質疑で終わりましたｗ

質疑はさきほどの発表に対するものが主でした。

したがって、以下、上記発表に関する質問と回答になります。

Q. 第三パーティーにスコープを指定させるのではなく、外部スコープと内部スコープのマッピングを行ったのはなぜか

ユースケースベースでスコープを提供した方が第三パーティーの開発者がわかりやすい。

リソースベースだとどれが必要なスコープなのかが分かりづらい。

（yyh-gl 感想）

AWSのポリシーがリソースベースだと思うんだけど、どのポリシーが必要か分かりづらいもんねー

【Go同miniConf】Goの勉強会に参加してきた話

Tue, 06 Aug 2019 09:00:00 +0900

概要

CyberAgent ＆ merpay が共催したGoのイベント

Connpass情報
ハッシュタグ：#godo_miniconf

（写真撮るの忘れた…）

以下、発表まとめ

1. マイクロサービスとMonoRepo

登壇者：江頭宏亮さん（@_hiro511）
発表スライド

リポジトリ管理について

WinTicket というサービス開発・運用中

36個のマイクロサービスで動いている

マルチリポジトリ：マイクロサービスごとにリポジトリが別れている
モノリポジトリ：ひとつのリポジトリ。WinTicket ではこっち

モノリポジトリ

Google, FB, Tiwtter, Uberが採用
メリット
- 依存管理をシンプルにできる
  - マルチリポジトリの場合、複数のリポジトリに変更を加える必要があるし、変更を取り込むのが面倒
  - モノレポだとすべてのコードが一箇所にあるので変更が楽
- 一貫性のある変更
  - 複数のサービスにまたがる変更においても、アトミックなコミットが可能
- コードの共有と再利用が用意
  - common ディレクトリがあればできる
- 大きなリファクタリングが容易

ビルドとテストを効率良くしたいという

モノリポジトリだと、ビルドとテストに時間がかかるので、効率よくビルドとテストしたい

Bazel（ベイゼル）：ビルド・テストツール
- Go, Andoroid, iOSなど様々な言語に対応
- Googleが使っている（Googleの自社ツールがOSS化）
- 必要箇所だけビルド・テストする
  - 速い
- スケーラブル
- 拡張可能
  - StarDarkという独自言語で設定定義
- WinTicketではDockerビルドもこれ

Go with Bazel

Bazel のインストール by brew
WORKSPACEファイルの作成
- 外部の依存関係を記述
BUILDファイルを作成
- ビルド方法を示したもの
- Gazzelを利用して自動生成可能

ディレクトリ構成例

.
├BUILD.bazel
├WORKSPACE
└cmd
└main.go

Gazzelは Go Modules と dep に対応

go.mod, Gopkg.lockファイルから依存パッケージを取りこみWORKSPACEファイルに書き込んでくれる

【徒然なるままに】サービス発案における主観と客観のバランスについて

Tue, 18 Jun 2019 09:00:00 +0900

研修でのサービス発案をやった

新卒研修でサービス発案について学び、実際に

問題提議
ソリューション検討
サービスに落とし込む

など、チームで作業しました。
（今回考えたサービスを、今後チームで開発していきます）

そして、一日考えたサービスをターゲット層となる人たちに
「こんなサービスどうですか？あったら欲しいですか？」といったアンケートを行いました。

返ってきた答えは「欲しくない」が過半数でした。

そのとき僕たちは

正直、意気消沈しました。

ただ、こういう結果になった原因は明白でした。

なぜかというと、この時、チーム内から多く出た声が

「必死に考えたサービスだったのに」
「絶対欲しいでしょこれ」
「俺は欲しい」

といった内容だったからです。

ハッカソンでもあるあるですよね。
自分たちが考えたサービスに愛着が出てきて、客観性がなくなっている状態。

そうです。僕たちは客観的になれていなかったんです。

それでもめげずに僕たちは動いた

めそめそしていても仕方ないので、僕たちはアンケートを答えてくれた人に
話を聞きに行ってみることにしました。

この行動が大正解でした。

チーム外の人の話を聞くと、どういったところがだめだったのかが見えてきました。
加えて、自分たちもサービスを客観視することができるようになり、
他にもだめなところが見えてきました。

後、意外だったのですが、自分たちが特にどこに力を入れていて、
どういった解決方法を取ろうとしているのか、熱量を持って伝えると、
相手方が理解して、共感・納得してくれることがありました。

つまり…

サービスを提案する上で、第一に大事なのは客観性だと感じました。

自分たちがどれだけいいものだと思っても、
他の人々がいらないと言ったら、そのサービスは世の中には受け入れられません。

つまり、客観的に見る＝世の人々がなにに課題を感じているのか調査し、
ソリューションを提供していくことが大事です。

しかしながら、さきほど言ったとおり、

熱量を持って伝えると、相手方が理解して、共感・納得してくれることもありました。

こういうケースもあります。

これは、多少主観的でも論理的に正しいことを熱量持って伝えることで、
世の人々がまだ気づいていない課題に気づき、提案サービスの必要性を感じてもらえた瞬間だと思います。

ただ、相手にサービスの良さを気づいてもらうには、
サービスに対する絶対的自信（主観）がないと難しいですよね。

すなわち、主観も大事ってことですね。

主観と客観のバランスが難しい

ここまでの内容をまとめると
僕は「サービス発案において、主観と客観どちらも大事」という結論に落ちつきました。

でも、主観と客観のバランスってめちゃくちゃ難しくないですか？

主観的意見もある程度は受け入れてもらえるんです。
そして、そこがそのサービスのユニークな機能になると思います。

しかし、主観的意見が多くなりすぎると、誰にも求められないサービスができあがってしまう。

いかに、この主観と客観を両立するのか。
まだまだサービス発案について学ぶことは多いと感じました。

【OGP】リンク先のサムネイル画像を表示できるようにした話

Mon, 17 Jun 2019 09:00:00 +0900

Twitter のリンクにサムネイル画像が表示されない

このように Twitter でブログのリンクを載せても、サムネイルが表示されない。

はてなブログをやっていたときは、何もしなくてもサムネイルが表示されていました。

トップ画像をよしなにサムネイルにしてくれるのかなぁっと思っていましたが違ったんですね…。

どうやったらサムネイル画像が表示されるか

Twitter や Facebook などの SNS でタイトルやサムネイルといったWebページの情報を表示するには、 Open Graph Protocol（OGP）というものを設定する必要があります。

OGP を設定することで Twitter や Facebook でサムネイル付きのリンクを表示できます。

こちらのサイトで詳細が説明されています。

OGP の設定

今回設定する OGP 情報は以下のとおりです。

og:title
og:type
og:url
og:description
og:image

これらの情報を head タグ内に埋め込みます。

<meta property="og:title" content="【Go + レイヤードアーキテクチャ】DDDを意識してWeb APIを実装してみる">
<meta property="og:type" content="article">
<meta property="og:url" content="https://tech.yyh-gl.dev/blog/go_web_api/">
<meta property="og:description" content="hoge">
<meta property="og:image" content="https://tech.yyh-gl.dev/img/2019/06/go_web_api/featured.png">

ただし、僕の場合、Hugo のテーマの方で og:image 以外は設定してくれていました。
したがって、今回は og:image だけを追加で設定します。

【HTML + CSS + Prism.js】ブログの見た目を整えた話

Sun, 16 Jun 2019 09:00:00 +0900

シンタックスハイライト導入

このブログ、ちょっと前までコードのシンタックスハイライトが効いていませんでした。

正確には対応していない言語が（めちゃくちゃ）ありました。

このとおり、 Goにも対応していませんでした…。

もともと、このブログのテーマは Hugo Themes （Hugo 公式テーマショップ的なの）に
あったものを使わせてもらっているのですが、さすがに対応していない言語が多すぎたので、
シンタックスハイライト部分だけ個別に導入することにしました。

Prism.js

さっそく、「HTML シンタックスハイライト」で調べてみました。

そしたら、だいたい以下の3つが出てきました。

どれにしようか迷ったのですが、見た目が一番好みだった Prism.js を使うことにしました。

導入

導入方法については記事がたくさんあるので、そちらをご覧ください。

導入後

きれいですねー

今回導入した Prism.js のプラグインは、

Line Highlight：行指定した箇所をハイライトする機能（上記画像内では使用していません）
Line Numbers：行番号を表示する機能
Show Language：右上に言語名を表示している機能

の3つです。

困ったこと

行番号が表示されない

行番号を表示するには、

<pre class="line-numbers"><code class="language-c">
コード
</code></pre>

上記コードのように、表示するコードスニペットに対して、
line-numbers というクラスを付与してあげるだけでOKです。

…が、なぜか行番号が他の要素の下にいってしまい、見えなくなっていました。
したがって、prism.css を修正して行番号が他の要素の上に来るようにしました。

リスト表示の行間が異様に広い

Prism.js 導入後…

【mercari.go #8】メルカリのGoに関する勉強会メモ

Sat, 15 Jun 2019 09:00:00 +0900

mercari.go #8

connpass：リンク
ハッシュタグ： #mercarigo
独自ルール：懇親会のGルール
懇親会のときに登壇者を囲んでもいいけど、自分たち以外にもう一人入ってこれるスペースを常に開けておこうねっていうルール。とてもよい！
雰囲気

ビール以外にもおいしそうなご飯もありましたが、写真を撮るの忘れ…

以降、自分用のメモを書き連ねます。
詳細はスライドの方をご覧ください。

1. Goで学ぶKnative

登壇者： @toshi0607 さん

スライドリンク

Knative

Knative ＝最新のサーバーレスワークロードをビルド、デプロイ、管理できる Kubernetes ベースのプラットフォーム
- AWS の Lmabda に近いことを k8s 上でできると解釈
登壇者含め、会場内で Knative を本番に導入している人はなし。
まだ時期尚早っぽい
k8s のリソースを抽象化し、独自のPaaS/FaaSを構築するためのパーツを提供
k8s 上にのっかる。
Knative の構成
- Serving
- Build
- Eventing
現状、一部、Istio に依存してしまっているので、Istioの導入が必要不可欠
登壇者は機能実装に一層集中するための基盤として注目している
yml ファイルで定義した内容に基づいてコード生成

感想

終盤、 Knative の内部処理をコードリーディングしていたのですが、
見入ってしまいメモを忘れていました。。。

Knative 初めて聞いたのですが、おもしろそうだなという感想。

k8s の勉強しないとな。

2. Gotham GoとGopherCon EUに参加してきました

登壇者： @tenntenn

【Go + レイヤードアーキテクチャ】DDDを意識してWeb APIを実装してみる

Fri, 14 Jun 2019 09:00:00 +0900

更新（2019年10月30日）

初回投稿から3ヶ月経ちました。
この3ヶ月で新しく得た知見を基に、内容を一部アップデートしました。

今回やること

Goのディレクトリ構成についていろいろと調べる中で、
こちらの資料がとても分かりやすかったので、
今回はこちらを参考にGoでWeb APIを作っていきたいと思います。

加えて、本プロジェクトでは、DDD とレイヤードアーキテクチャを取り入れます。
（内容はほぼレイヤードアーキテクチャになってしまいましたが…）

DDD については、「DDD を Go とレイヤードアーキテクチャでやるなら、こんな感じかな？」という個人の見解レベルです。
パッケージ構成の参考になれば幸いです。
（なので、ドメインモデルは重度の貧血症）

環境

MacOS Mojave 10.14.6
Go 1.12.5

なお、今回は、Gin や Mux などといったフレームワークは使わず、
httprouter のみで薄く作っていこうと思います。

Mux を使った実装は僕の前のブログで紹介しているのでよければどうぞ。

・

では、早速本題に入っていきましょう。

採用アーキテクチャ：レイヤードアーキテクチャ

参考記事内で紹介されているのはレイヤードアーキテクチャをベースに
いろいろカスタマイズされたものらしいです。

クリーンアーキテクチャに似たアーキテクチャだとか。

ユースケース層という呼び方はクリーンアーキテクチャ由来ですね。

DDD の文脈ではアプリケーション層と呼ばれますが、
アプリケーションって意味が広くて分かりづらいので、
本プロジェクトではユースケースという単語を使用します。

とりあえず、今回はスライドページ19で紹介されているディレクトリ構成に従って、
DDD を意識して Web API を実装していこうと思います。

（意識だけして、実践できずに終わりましたが😇）

レイヤードアーキテクチャにおける各層の依存関係について説明します。

依存関係の図は下記のとおりです。

矢印は依存の方向を示しています。
例えば、上図だと Handler層は UseCase層の処理を利用することを意味します。

【goenv】GOPATH が変わらないときの対処法

Thu, 13 Jun 2019 09:00:00 +0900

GOPATH が変わらない…

今日こんな現象に遭遇した。

$ export GOPATH=/Users/yyh-gl/workspaces/Go
$ echo $GOPATH
/Users/yyh-gl/workspaces/Go
$ go env GOPATH
/Users/yyh-gl/go/1.12.5

GOPATH が書き換わらない。

解決方法

社内Slack で適当につぶやいたら、同期が助けてくれた（神）

画像にある Qiita のリンクがこちら

ちなみに僕の環境の goenv はバージョン 1.12.5 だったので、2系に上げなくても発生する模様。

（追記：19/06/14）またまた同期が教えてくれました。
こちらの記事によると、 goenv による管理はバージョン 1.12 からとのこと。

結論：goenv が GOPATH を管理しようとしてた

goenv の管理から外してやるには GOENV_DISABLE_GOPATH=1 にしてやればOK。

僕は zshrc に以下のとおり追記しました。

export GOENV_DISABLE_GOPATH=1

（zshrc の読み込み直しを忘れずに）

結果

$ go env GOPATH
/Users/yyh-gl/workspaces/Go

変わった。よかった

【エリック・エヴァンスのドメイン駆動設計】DDD入門 Part 1

Tue, 11 Jun 2019 09:00:00 +0900

DDD の勉強始めます

新卒研修を受ける中で DDD が出てきて、勉強したくなったので、
『エリック・エヴァンスのドメイン駆動設計』（エリック・エヴァンス著，今関剛監訳，和智右桂、牧野祐子訳）を読んでいこうと思います。

今回は第1部「ドメインモデルを機能させる」の 1章と 2章をまとめます。

注意：僕の理解をそのままメモとして書き連ねていきます。
したがって、誤った理解もあると思うので、そのときはDMとかでご指摘お願いします！

1章知識をかみ砕く

ソフトウェアを作るときに、はじめから対象を十分に理解している開発者などいない。

対象＝これから作るソフトウェアで実現する作業＝ドメイン

したがって、対象について詳しい人（ドメインエキスパート）と開発者で
十分に話し合って理解を深めることが重要である。

理解したことはモデルとして書き出す。
そして、ドメインエキスパートは足りないところがあれば追加で説明する。
開発者は分からないところがあれば質問する。

上記工程を何度も繰り返し、その都度得た知識をモデルに落とし込んでいく。
→ 継続的学習（継続的学習は開発が始まった後でも行う）

はじめから対象を如実に表したモデルを作れることは滅多にない。

ドメインエキスパートと開発者では見ている視点が違うので少し話を聞いたぐらいで
完璧なモデルを作ることができないのは当たり前である。

だからこそ、対話を通して、互いに疑問点や不要な点を洗い出し、洗練する必要がある。
これが知識のかみ砕きである。

1章まとめ

ドメインエキスパートと開発者が話し合ってドメインをモデルに落とし込んでいく
- 用語の説明や不足点の追加などとにかく話す
- ドメイン：ソフトウェア化する対象（業務やサービスなど、ソフトウェア化の対象となりうる万物）
一発で完璧なモデリングはできないから、継続的に改善していく

2章コミュニケーションと言語の使い方

ドメインエキスパートが使う専門用語を開発者は理解できないし、
開発者が使う専門用語をドメインエキスパートは理解できない。

ドメインエキスパートと開発者の両者が同じ意味だと思って使っていたとしても
たいていの場合、差異がある。

このような差異があると通訳が必要となる。
通訳はコミュニケーションを鈍らせ、知識のかみ砕きを沈滞させる。

共通言語としてのモデル

通訳をなくすために、モデルを言語の骨格として使用する。

ドメインエキスパートと開発者のコミュニケーションやコード、ドキュメント、図など
全てにおいて、その言語を使用する。

【大規模サービス技術入門 5章】大規模データの処理方法についてまとめた

Mon, 10 Jun 2019 09:00:00 +0900

はじめに

社内で伊藤直也さんと田中慎司さんが書かれた

『Web開発者のための大規模サービス技術入門』を輪読しました。

今回は、僕が担当した第5回の「大規模データ処理[実践]入門」についてまとめます。

なお、本書は2010年に出版された本であるため、

少なくとも第5回の内容は今では当たり前のことという印象を受けました。

それでも、しっかりと文章で学んでおくことは大事だと思うのでまとめます。

★印は個人メモです。

以下まとめ

大量なデータを扱う場面

全文検索やデータマイニングなど RDBMSで処理できない規模のデータを

処理したい場面は多く存在します。

では、RDBMSが使えない規模のデータをどう処理すればいいでしょうか。

データを抽出

結論から言うと、RDBMSで扱うことができないデータは、適宜RDBMSから抽出して利用します。

具体的には

バッチ処理でRDBMSからデータを抽出し、

別途インデックスサーバのようなものを作って、そこに入れていきます。

★ ここで言っているインデックスサーバというのは、例えば全文検索用であれば

「検索用にチューニングした（検索しやすくした）データ構造」と考えるべきでしょう。

★ 最近は、Fluentd を使用してログを外部に吐き出してから解析したりしますよね。

それと考え方は一緒だと思います。

インデックスサーバにはRPC（Remote Procedure Call）を使ってアクセスします。

（なお、RPCと言いましたが、現在では Web API でのアクセスが一般的なので、以降、 Web API を例に使用します）

イメージとしては下図のようになります。

用途特化型のインデクシング

上述した方法を、はてな社（著者がはてな社出身の方なのでよく出てきます）では、

用途特化型インデクシングと呼ぶそうです。

用途特化型インデクシングとRDBMS

RDBMS はデータソートや統計処理、JOIN など、データに対して様々な処理を行うことができます。

しかし、汎用的故に、特定の目的だけに使うときには、それ用にチューニングしたデータ構造、

すなわち用途特化型インデクシングを使う方が圧倒的に速くなります。

★ 先ほど言っていた Fluentd を用いたログ解析システムはログ解析用にチューニングしたものと言えるでしょうか。

用途特化型インデクシングの使用例：全文検索エンジン

全文検索エンジンでは、以下3点の要求をどう満たすか考える必要があります。

【Web API（Rails） + Vue.js】ブログのいいねボタン自作してみた

Sat, 08 Jun 2019 09:00:00 +0900

いいねボタンがないブログ

本ブログ、いいねボタンがありませんでした。

だから、作っちゃいました。っていう記事です。

構成

上図のように

記事ページからAPIサーバにリクエストを送り、いいねの数を取得・加算します。

記事ページからAPIサーバへのリクエスト部分（クライアント）には Vue + axios を使用。

APIサーバは Rails で実装しました。

（以前から Slackのスラッシュコマンド用に使用していたAPIサーバを流用しました）

APIサーバ

Rails で APIサーバを建てる方法に関しては、

以前に Qiita で入門記事書いたのでそちらをご覧ください。

（少し古い記事ですが、そんなに問題はないはずです）

DB にテーブル作成

今回、ブログ記事を管理するために、下記のテーブルを作成しました。

mysql> describe blog_posts;
+------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+------------+--------------+------+-----+---------+----------------+
| id | bigint(20) | NO | PRI | NULL | auto_increment |
| title | varchar(255) | NO | | NULL | |
| count | varchar(255) | NO | | 0 | |
| created_at | datetime | NO | | NULL | |
| updated_at | datetime | NO | | NULL | |
+------------+--------------+------+-----+---------+----------------+
5 rows in set (0.00 sec)

titleには、日本語のタイトル（本記事だと『【WEB API（RAILS） + VUE.JS】ブログのいいねボタン自作してみた』）ではなく、記事ファイル（マークダウン）の名前（本記事だと『good_api』, 拡張子抜き）が入ります。

スクラムについて学んだ話

Wed, 05 Jun 2019 09:00:00 +0900

スクラムとは

概要

変化に対し柔軟に開発を運用するためのアジャイルフレームワーク
開発に常に優先度をつける
仕事を進めることを主眼に考え、そのために改善を常に行う
ロールが3つあり、協調しあい開発する
- プロダクトオーナー
- スクラムチーム
- 開発チーム
POが満足するアウトプットがあったかのみを検証
5つのイベントがある（後述）
2つのアウトプット（成果物）がある（後述）

特徴

非常にシンプルなフレームワーク
- 定められたルールが他の手法より少なくアレンジが容易
実践的で経験主義
世界的に普及している

アジャイル開発とは

アジャイルとスクラムの違い

スクラムとはアジャイル開発手法のひとつ

他にもXPとかがある

アジャイルソフトウェア開発宣言

ここにいろいろな言語で宣言されています

この宣言では以下のことを重要視している

個人と対話
動くソフトウェア
顧客との協調
変化への対応

スクラムとウォータフォールの違い

ウォータフォール
- 計画、設計、実装、テストが一方向に進む
- リリース直前の実装や仕様に漏れがあると最悪の場合プロジェクトがぽしゃる
- 運用・保守には強い。新規案件向けではない
スクラム
- 開発期間中に計画、設計、実装、テストのリサイクルを何度も回す
- 細かいスパンでリリースするので、大きな手戻りが少ない

スクラムで登場するロール（役割）

あくまでテンプレの内容を紹介

自分のチームに合わせて変えてOK（むしろカスタマイズすることが重要）

プロダクトオーナー（PO）

役割
- プロダクトのビジネス価値に責任を持つ
- リリース判断をすることができる
- 優先度の判断役
求められる力
- 情報アウトプット（見える化、透明性） → 実現したいことをちゃんと伝える力
- クライアントとチームを繋ぐハブ役

スクラムマスター（SM）

役割
- スクラム開発に関わる全ての人を支援し、成功に導く
  - POのビジネス的な相談を受けたり、開発チームの技術的な相談を受けたりなどなど
- スクラムの理論や価値を関係者全員に教え、理解してもらう
- 開発チームへの障害や外部干渉を取り除き、防ぐ
求められる力
- サーヴァントリーダシップ（奉仕型リーダー）
  - 下からみんなを持ち上げるようなリーダー
- 理解と実行の話づくりと良きファシリテーター

SMが開発に加わるのはOK？

チームが良しとするならばOK。

はじめから参加することは基本的にない。

開発チーム

役割

【Terraform + ECS + RDS】Terraform で ECS環境構築してみた

Tue, 04 Jun 2019 09:00:00 +0900

Terraform とは

最近流行りの IaC です。

つまり、コードベースでインフラリソースを管理するためのツールです。

中でもTerraform はクラウドに特化した IaC ツールという立ち位置です。

AWSやGCP, Azure などの他に様々なクラウドプラットフォームに対応しています。

（ちなみに、Vagrant 開発元の HashiCorp 社が開発しています）

今回やること

Terraform で AWS 上に下記のような環境を自動構築します。

ECS でデプロイされるサービスは ECR から引っ張ってくるようにします。

そして、そのサービスは Aurora を使うシステムを想定しています。

【⚠注意⚠】上記構成はお金が発生します！まったくもって無料枠ではありません！

【⚠注意⚠】今回独自ドメインを使用していますが、ドメイン取得に関しては省略しています。

今回やる内容は…

僕が所属する会社の研修資料を参考に進めています。

資料を作成してくださった@_y_ohgi さんに感謝。

自動構築プロセス全体で使用する共通設定を定義

まず、 main.tf を作成し、以下のとおり共通設定を定義していきます。

# AWS を利用することを明示
provider "aws" {
# リージョンを設定
region = "ap-northeast-1"
}
# これから作成するリソースに付与する名前のプリフィックスを設定
# グローバル変数的な立ち位置で定義
variable "prefix" {
default = "sample-project"
}

provider で使用するクラウドを指定することができます。

variable は変数定義です。

【Android + Kotlin + Firebase】Androidアプリにプッシュ通知を実装してみた

Thu, 30 May 2019 09:00:00 +0900

僕がひっかかった場所は「つまづきポイント」という章にまとめているので

なにか困ったときはそこを一度見てみてください。

tl;dr

Firebase使ってAndroidアプリにプッシュ通知を実装した
フォアグラウンドとバックグラウンドで表示方法が異なる
めちゃくちゃ簡単

開発環境

macOS Mojave 10.14.4
Android Studio 3.4.1
Gradle 3.4.1
Java 1.8.0_202
Kotlin 1.3.21

Firebaseに登録

Firebaseを使用するためには登録が必要です。

Googleアカウントを持っている方なら公式サイトから簡単に登録できます

Firebaseにプロジェクト作成

プロジェクト登録ページでプロジェクトを登録します。

プロジェクト名は特に指定はありません。ご自由にどうぞ。

アプリ情報を登録する

プロジェクト選択後のホーム画面より「Project Overview」をクリック。

画面の指示に従って進めていてください。

デバッグ用の署名証明書 SHA-1 の取得方法

以下コマンドを実行

Mac/Linux

keytool -list -v \
-alias androiddebugkey -keystore ~/.android/debug.keystore

Windows

keytool -list -v \
-alias androiddebugkey -keystore %USERPROFILE%\.android\debug.keystore

パスワード入力

パスワードは android です。
表示される SHA-1 をメモ

ひととおり作業が進むと、↓このような画面が表示されます。

自分の環境では、登録したアプリがFirebaseと通信できているかのチェックに少し時間がかかりました。

【エンジニアリング組織論への招待】メンタリングの技術

Sat, 25 May 2019 09:00:00 +0900

概要

今回は、広木大地さんが書かれた『エンジニアリング組織論への招待不確実性に向き合う思考と組織のリファクタリング』という本から、

2章「メンタリングの技術」についてまとめます。

（初投稿の内容が技術系じゃなくてチームマネジメント系かよとか言わないでくださいね）

最初に覚えておいてほしいこと

メンタリングは、自律的な人材を育むために行う。

そのために、下記3点の状態にメンティ自身からなれるように導く。

自分の気がつかなかった問題に気がつくようになる
認知の歪みによる感情と問題の癒着を切り離せる
答えではなく、次の一手を生み出す行動が取れるようになる

これらがとても重要です。

以下いろいろな話が出てきますが、結局は上記3点の状態を実現するための方法です。

ここをしっかりと意識して読んでいただければ、

より一層理解が深まると思います。

以下まとめ（★マークは個人的解釈・感想です）

そもそもメンタリングとは

相手を上から押し付けるような教育方法ではない
相手の考え方を少しずつ変えることで、問題解決の力を育む手法

対話を通じて、以下の2点を行い、相手を成長させる。

歪んだ認知を補正
次の行動を促進

メンタリングと聞くと、

大学で何年も学ばないと身に着けられないような技術であると思いがちだが、

体得すればだれでもできるようになる。

エンジニアリングにおけるメンタリングの重要性

エンジニアリングは知識が全てではない

エンジニアリングでは技術的な課題がよく取り上げられるが、

技術的な課題というのは心理的な課題と密接に関係している。

例えば、

ソフトウェア開発はチームプレイ

★ 技術的な課題解決だけでなく、人間関係とかもあるってことかな

各個人の開発における問題解決は、自分自身との対話によって制御するもの

★ 自身を制すものがエラーを制す

上記のようにエンジニアリングには心理的な課題も存在する。

プロダクト開発では不確実性を排除することがとても重要である。

したがって、不確実性のひとつである心理的な課題は排除すべき対象である。

★ だから、メンタリングが重要なんですね。

メンタリングは自ら考える人材を作るためのテクニック

自立型人材と依存型人材

自ら考える人材を自立型人材、そうでない人材を依存型人材とすると、

それぞれ下記のような特徴がある。

自立型人材
- 自ら問題を発見し、解決することができる
- 問題について、自分ごととして捉えている
- 問題の根本的原因は自分にあると考える
  - 改善のために行動できる
依存型人材
- 問題を与えられてから考える
- 問題と解決策を渡されてから動ける
- 問題の根本的原因は他人にあると考える
  - 改善のために行動できず、他人のせいにしてしまう

両人材の境界線

多くの人は時には自立型人材、しかし、ある場面では依存型人材になってしまう。

それが普通である。

大事なのは、上司と部下という関係における期待値を合わせておくこと。

Hello Wolrd

Wed, 22 May 2019 09:00:00 +0900

技術ブログはじめます

不定期で学んだことをアウトプットしていきます。

サーバサイドのネタを中心に、フロントやインフラ（クラウド）の話も書いていく予定です。

まさかり大歓迎です。

自己紹介

19新卒として社会人1年目を始めたエンジニアです。

学生時代はインターンやアルバイトで

ECサービスやスマホゲームのバックエンドなどを開発していました。

現在は、フルスタックエンジニア目指して、日々修行中。

（メインはサーバサイド）

学んだことをアウトプットする場として

本ブログを始めました。

頑張ります

yyh-gl's Tech Blog

Kotlin言語仕様書への招待 @Kotlin Fest 2025

Kotlin Fest 2025

発表内容

JavaのIntegerクラスがキャッシュする範囲

JavaのIntegerクラスにキャッシュがあることを知る

Integerクラスのキャッシュとは

キャッシュ範囲を深ぼる

『暗号解読（上）』を読んで

はじめに

読書メモ

1. 暗号システムの本質

2. ヌル文字の歴史的背景

3. 弱い暗号の危険性

4. 古典的な解読テクニック

5. ワンタイム・パッドの特異性

6. エニグマと鍵交換の重要性

7. 反復は秘匿の大敵

8. 数学には論理と直感の両方が求められる

9. アラン・チューリングという天才

10. 解読しても公表しない情報戦

総括

VS Codeのeditor.quickSuggestionsについて調べたメモ

はじめに

editor.quickSuggestions

comments

strings

other

調査背景

『データ指向アプリケーションデザイン』を読んで

はじめに

感想

2024年を振り返る

仕事

本業：LINEマンガ

副業

個人的な活動

読書

ブログ

k8s

個人開発

まとめ

分散システムにおけるID採番の勉強メモ

はじめに

Snowflake

Snowflakeとよく比較される対象

k8s関連書籍をいろいろ読んだ

今回読んだ本

入門 Kubernetes

Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス

コンテナセキュリティ コンテナ化されたアプリケーションを保護する要素技術

2024年もよろしくお願いします！

Indigo VPS上に個人開発用のk8sクラスターを構築する

概要

k8sクラスターについて

Indigo VPS固有の内容

Swapの無効化は不要

ファイアウォール

スクリプト

gomockのgenerics対応状況

gomock

gomockのgenerics対応状況

いつリリース？

まとめ

DMM.comを退職しました

合同会社DMM.comを退職しました

入社まで

入社してから

テックリード、そして、チームリーダーへ

10→100の開発

KtorとStripeでECサイトを作ってみた

Kotlin Advent Calendar 2022

概要

採用技術

Hello World

Auto-reloadの有効化

複数のdocker-compose.ymlを使って、設定の追加や上書きをやってみる

要約

docker-compose.ymlは複数指定可能

実際の動きを見てみる

コンテナセキュリティコンテナ化されたアプリケーションを保護する要素技術

`docker-compose.yml`は複数指定可能

`build`コマンドとは