はじめに こんにちは！コンテナ基盤グループの楠本です。 前回の記事EKSコンテナ移行のトラブル事例：FargateにおけるAZ間通信遅延の解消 - MonotaRO Tech Blogを投稿してから半年以上も経ちました。（時が流れるのは早い… 前回はSREグループコンテナ化推進チームとしてでしたが、今回は挨拶の通りコンテナ基盤グループとしての投稿です。 元々ECエンジニアリング部門のSREグループとして活動していましたが、今年初めに組織編成があり、プラットフォームエンジニアリング部門の１グループとして活動しています。 今回は組織とのミスマッチからEKS on FargateからEKS on EC2へ切り替えた話をご紹介します。 見どころは EKS on Fargateとプラットフォームエンジニアリングとの相性 EKS on EC2へ移行する際に検討したこと 移行して得られたこと の３点です

はじめに 株式会社tacomsでCTOやってる井上です！ tacomsは複数デリバリーサービスを1台のタブレットにまとめたり、様々なPOSレジ会社と連携してオペレーションをシームレスにする「Camel」というプロダクトを提供している会社でして、プロダクトの属性上めちゃくちゃ連携している会社数が多いのが特徴です。（様々な属性の連携パートナーを合わせるとなんとざっくり30以上！！！） また、tacomsではPublicAPIも作っているため、連携先のAPIに合わせて開発するだけでなく、連携先に使ってもらう汎用APIの開発にも取り組んでいます。 外部APIを使う側、作る側の双方を開発してきた経験から、連携開発に取り組む上でのスタンスや考慮事項をまとめてみました。少しでも皆さんのお役に立てると幸いです！ 外部API連携の定義 おおよそ一般的な認識だと思いますが、外部APIを 「連携先の会社が開発し

同世代男性たちがやっているポッドキャストOssan.fmで紹介されていた「あたらしい家中華」という本を買ってみた。 特別な調味料は必要なく、あっさりしていて、毎日でも食べられるそう。マジで？ MCのnagayamaさん曰く、ご家族にも評判がいいらしい。なるほどね。買ってみよ。 該当エピソードはこちら→ 311. あたらしい家中華 届いた本をパラパラ〜っと見て、これはたしかに調味料としても一般的な家庭にあるものばかり、ちょっと特殊といえば紹興酒とか黒酢くらい？なかなかよさそう 子どもたちが「これ食べたいから付箋つけておくね」と、いきなり付箋だらけ 器具について「特別なものはいらないけど筆者はこれを使ってるよ」と本の中で紹介されていて、形から入るタイプなので色々買った。中華鍋・おたま・五徳・蒸し板・蒸し板用のトングを買った。詳細は後述。 目についたものを週末いろいろと作ってみた、優しい味で家族

こんにちは。コミュニケーションアプリ「LINE」のモバイルクライアントを開発している石川です。 この記事は、毎週木曜の定期連載 "Weekly Report" 共有の第 48 回です。 LINEヤフー社内には、高い開発生産性を維持するための Review Committee という活動があります。ここで集まった知見を、Weekly Report と称して毎週社内に共有しており、その一部を本ブログ上でも公開しています。（Weekly Report の詳細については、過去の記事一覧を参照してください） ワイルドすぎる引数 「図形」というデータが、スペースで区切られた文字列として表現されているとします。以下は、その文字列の例です。スペース区切りの最初の値は、図形の種類を示す「タグ」と呼ばれるもので、2 つ目以降は図形ごとの属性 (座標など) だとします。 circle 10 20 30 rect

先日、DevLOVE関西の200回目を記念するイベントで登壇してきました。 登壇内容を考えるにあたって、大きく2案あったので、没にしたほうのネタを簡単にブログに書いて供養しておきます。 ロックバンドの成功の証は、日本武道館でのライブである、みたいなイメージがなんとなくあります。 地元の小さなライブハウスで、客席に友人しかいない状態で演奏するところからはじまって、そこそこ有名になり、対バンに呼ばれるようになって、ソロでライブハウスが埋まり、Zeppなどの大きなハコでやるようになって、そういうステップアップを繰り返した先に、ついに武道館を満員にする。 そのときの彼らの気持ちは、どんなものなんだろうか。 自分にとって、かつて武道館のような舞台がありました。 今は会場が変わりましたが、かつては毎年目黒の雅叙園で開催されていたデブサミ。ここは自分にとっての武道館のようなものでした。 2010年ごろに

はじめに 皆様こんにちは、ソーシャル経済メディア「NewsPicks」(Media Infrastructureチーム)エンジニアの北見です。 弊社では Server Side Kotlin を採用しており、昔に書かれた一部のコードは Java ですが、基本的に新規コードは Kotlin で書いており、既存の Java コードも Kotlin 化を推し進めています。 tech.uzabase.com tech.uzabase.com 今回は Kotlin の sealed class を使って、コードをシンプルにする例をご紹介します。 kotlinlang.org 微妙に異なるけど殆ど同じ処理を共通化 例えば、クレジットカードとキャリア決済の2通りで商品を購入するユースケースを考えてみます。 class PurchaseService( val productRepository: Pro

高品質と高スピードを両立させるテストアプローチ/Test Approach that Improves Quality and Agility Together

こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 今月でカミナシに入社してちょうど 1 年が経ちました。前職では 6 年間 SRE チームにいたのでプロダクト開発はブランクがありましたが、さまざまな挑戦をさせてもらっていたらあっという間に 1 年が経っていました。 カミナシのエンジニアリング組織もこの 1 年で急拡大しており、入社当初から比べると正社員のエンジニアも倍以上に増えました。 GitHub の権限管理、どうしていますか？ ところで、みなさんが所属されている組織ではどのように GitHub の権限管理を行なっていますか？ カミナシではつい先日まで、ほとんどのエンジニアが Organization の Owner 権限を持っていました。理由は、メンターになったエンジニアがニューカマーのユーザーを招待していたからです。 しかし、統制が取れていないことでいく

「学生時代にもっと勉強しておけば良かった」大人ならば一度は思ったことがあるのではないでしょうか。 特に「英語をもっと勉強しておけば、今このような苦労はしなかったのに……」という後悔の念に駆られ、大人になってから英語を学び直す方はとても多いです。 英語は大人になってからでも十分、習得できます。しかし、記憶力も体力も充実していた学生時代とは、少し勉強のアプローチを変える必要があります。 今さら中学生向けの文法問題集を解いたり、大学受験用の頻出単語帳を一から暗記したりするのは、大人の学び直しとしては正しいアプローチとは言えません。望むような英語力はつかないのです。 この記事では、大人になってから英語を学び直すときの勉強方法についてご紹介します。 学習に取り組む上で抑えておきたいポイントや、活用したい無料の動画サイトなどおすすめの教材もご紹介しています。 「英語を学び直そうと思うが、何から始めたら

はじめに 職務経歴書を使用する機会はそれほど多くありませんが、いざ必要になって作成しようとすると、さまざまな手間がかかります。自分の経歴を振り返り、情報を整理し、記載し、修正して完成させる必要があるためです。また、これは社会人生活が終わるまで継続的に続けていかなければならない作業でもあります。 まさに長期的なプロジェクトといえるでしょう。そこで、これまで培ってきたITエンジニアとしての経験を活かし、職務経歴書の管理方法について検討した結果、「Githubで職務経歴書を管理し、Webで公開する」という方法にたどり着きました。 職務経歴書を公開しておくことで、「職務経歴書をください」と依頼された際にリンクを送るだけで対応できるので非常に便利です（PDFが求められた場合はPDF化して渡せば問題ないと思います）。 当初はGithubの公開リポジトリのREADMEに職務経歴書を記載していましたが、情

www.oreilly.co.jp 前半はJavaのラムダ式とStream APIの概要と使い方）、後半は遅延評価・再帰処理・最適化・関数合成についてJavaで紹介してくれる本。 自分がプログラムを書き始めた時には、既にJavaでラムダ式とStream APIが導入されていた。気づけばラムダ式とStream APIを使わずにfor文を使っているコードの方が気持ち悪いなと思うようにくらいには経験を積んだようなので、復習と新たな知見を得るためにさらっと読んだ。 4章の『ラムダ式で設計する』で、ラムダ式で主要な関心を分離するところのテクニックが現場でもよく使えそうで勉強になった（恥ずかしながら本のリファクタリング前のようなメソッドを書いてしまっていた）。JavaScriptで関数を引数で渡して再利用性を高めるテクニックがJava側でも使えることを再認識した。 ラムダ式で主要な関心を分離するサンプ

下記に登壇した際の資料です。 https://findy.connpass.com/event/331621/ スライドはメモ書き程度のものとなっており、実際には講演の中で口頭で数多くの補足が入っています。講演の内容をまとめた記事も近日公開される予定なので、あわせてご覧ください。

プロジェクト新規参入者のリードタイム短縮の観点から見る、品質の高いコードとアーキテクチャを保つメリット

概要 今日は技術書を電子書籍で買うことが比較的多いわたくしが、普段技術書を購入する際に使っているサイトなどを紹介していく記事です。 経緯 技術書の電子書籍版は今どきわりといろんなところで買えます。かくいう自分は以前は Kindle で買うことが多かったです。 ただ、Kindle だと以下の点でちょっと不便さを感じるようになりました。 とはいえ品揃えは文句のつけようもないし、Amazonで技術書を買うこともあるにはあるんですが、Amazon で電子書籍を買うと前述の点で困るので、最近はなるべく PDF や EPUB といった汎用的なファイル形式での配信に対応しているサイトで技術書を買うようになった、というわけでした。 ということで前置きが長くなりましたが、表題のとおり PDF/EPUB による電子書籍を購入可能なサイトたちを紹介していきたいと思います。 おことわり 本記事に載ってないけどPD

こんにちは、Platform Team の荒引 (@a_bicky) です。前回は続・何でも屋になっている SRE 的なチームから責務を分離するまでの道のり 〜新設チームでオンコール体制を構築するまで〜という話を書いたんですが、今回は Repro の運用に 7 年以上携わる中で私が遭遇して印象的だった Aurora MySQL 絡みのトラブルについて紹介します。 Aurora MySQL が詰まってデータ処理のスループットが下がるとか、API のレスポンスが遅くなるとか、ALTER TABLE する度にアプリケーションエラーが発生するとか、胃が痛くなる胸が熱くなる話が多いので、Aurora MySQL を利用していなくても楽しんでいただけるのではないかと思います。Aurora MySQL を利用している方であれば参考になる情報もあるでしょうし、通常の MySQL にも適用可能な話もあります

Webブラウザは，開発者にとってもユーザーにとっても，もはや日常の一部となっているほど身近なソフトウエアですが，近年のブラウザはあまりにも高機能かつ巨大になってしまったため，その仕組みを詳しく理解することは困難です。そこで，シンプルなブラウザをRustを用いて実装することによって，ブラウザ上でWebサイトを開くまでに何が起きているのかを理解することを目的とします。さらに，作成したブラウザを，別冊で解説・実装している自作OSの上で動かすことによって，ブラウザと更にその裏側を理解していきます。

こんにちは、モノタロウ コアシステムエンジニアリング部門 配送ドメイングループの安見です。 この記事では私が関わっていた社内システムを仮想サーバ(AWS EC2)からコンテナに移行した後にコンテナをやめて仮想サーバに戻した話をご紹介します。 諸説明 コンテナ移行について コンテナ化対象システムについて 直面した様々な問題 リリース後の多数の残課題 展開する機能の数が多すぎる コンテナ化のメリットが薄かった なぜこうなったか よかったこと まとめ 追記： 現在なら... 諸説明 コンテナ移行について システムのコンテナ移行とは、アプリケーションやサービスを動作させるための必要なすべての環境を、一つの「コンテナ」としてパッケージ化して動作できるようにすることです。これにより、アプリケーションは他のシステムと独立して実行され障害分離ができたり、環境の違いによる影響を受けにくくなるため移植性が向上

Goの開発現場では、ビルドやテストをビルドツールのMake(Makefile)で実行することがよくあります（例: $ make test）。たとえば、Mobyプロジェクト(Dockerの主要コンポーネント)やTerraformもそうです。 TerraformのMakefile MobyのMakefile Makefileは一度書いてしまえば変更の頻度は少ないとはいえ、最近では configure; make; make install といった手順でMakefileと触れる機会も減少しています。また、JSONやYAMLに慣れた人には、1970年代から存在するMakeの書式をとっつきにくく感じることもあり、保守性に課題が生じる場合もあります。 そこで登場するのがTaskです。Taskは、Makeの主要なユースケースをシンプルかつ簡単にYAML形式で記述できるツールです。 本記事では、Goプロ

エンジニア大好き「推測するな、計測せよ」。これは、Plan 9, UTF-8やGoの作者としても知られる、Rob Pike氏の Rob Pikes's 5 Rules of ProgrammingのRule 3.に由来すると認識している。以下に原文を引用する。 Rule 3. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest. Rob Pike's 5 Rules of Programming 訳すと以下のようになる。 「計測せよ。計測するまでチューニングをするな、そしてそこが支配的じゃないならチューニングするな。」 要は「チューニングする前に計測せよ」という主張で「推測」と言う言葉は出てこない。なの