There’s No Such Thing as Clean CodeのHacker Newsコメント経由でコードやシステム設計・最適化についての良いコメントを見つけた。どうやらHacker Newsで何度も引用されているらしいが日本語で言及された記事が見つからなかったので取り上げてみる。 コメントは2016年のSandi MetzのThe Wrong Abstractionに関するもので、発言者のcurun1rいわく「私は設計の優先順位をこの順序で学習することで、優れた開発者になれた」。*1 4つの基準と優先順位のガイドライン 状態 > 結合 > 複雑性 > コード量 私は状態 (state)、結合 (coupling)、複雑性 (complexity)、コード量 (code) の順に削減することでコードを最適化する。 コードがよりステートレスになるなら、結合を増やすこともいとわない 結

この記事はスターフェスティバル Advent Calendar 2021 の19日目です。 qiita.com 尽く会社と関係のない話ばっかりしていてアレですね。 抽象度揃ってる方がイイヨーみたいな話をレビューとかでたまにしているので、ちゃんと言語化しよーと思ったのでブログに書くことにしました。 自然言語で考える 抽象度を揃えるというとなんか難しそうな雰囲気がありますが、日常会話で無意識にやっていることをプログラムでもやってみようくらいの感覚です。 例えば今日の予定を家族に伝える時は「今日は友人とご飯に行ってくる」みたいなことを言うかと思いますが、こういうのが抽象度が揃った状態かなーと思います。 じゃあ抽象度が狂うとどうなるのかというと「2021年11月15日11時15分に家を出て11時30分発○○行きの電車に乗って○○駅で中学の頃から仲の良い○○くんと合流した後、東京都○○区○○１−２−

こんにちは佐々木です。NRIネットコム Advent Calendar 2021 開催中です。しかし、内部で検討した結果、私は枠外になりました。ということで、Japan APN Ambassador Advent Calendar 2021として書かせていただきます。どちらも宜しくおねがいします。 今日のテーマは技術選定とアーキテクトの育成についてです。ITエンジニアの間には、定期的にどう技術選定するのかといった議論が出てきます。いろいろな観点があるとは思いますが、私が重要であると考えている所を簡単に述べてみます。 技術選定に銀の弾丸はない まず最初に言っておきたいのが、『技術選定に銀の弾丸はない』ということです。銀の弾丸とはIT業界でもよく利用される比喩で、英語で“silver bullet”とは「狼男を倒せる武器」が元々の意味です。それが転じて「困難を解決する決め手」という意味で使われ

単一責任の原則（Single responsibility principle）について、もう一度考える はじめに オブジェクトの広場をご覧の皆様ならば、「SOLID原則」という言葉を聞いたことがあるかもしれません。 SOLIDとは、以下の5つのソフトウェア設計原則を並べたバクロニムです。 Single Responsibility Principle：単一責任の原則 Open/closed principle：オープン/クロースドの原則 Liskov substitution principle：リスコフの置換原則 Interface segregation principle：インターフェース分離の原則 Dependency inversion principle：依存性逆転の原則 ソフトウェアエンジニアが知っておくべき設計原則のセットとして、Clean Architecture や

TL;DR 分散システムにおいてキューを導入する場合、本当にキューが必要なのか再考すべき。そこが地獄の入り口だから。 システムの抽象 コンピュータの世界は、本来は0と1の信号の羅列が飛び交う無機質なものである。でも人類は信号だけですべてを語らず、様々な喩えを定義してきた。それはデスクトップ・ウィンドウ・マウスカーソルといったグラフィカルな表現に留まらず、パケットやカプセル化といった用語にロック・キュー・リスト・木などのアルゴリズムやデータ構造の世界にも自然に溶け込んでいる。これらはすべて人間の理解を助けるための喩え話に過ぎず、この喩えこそが人間のより直感的な理解をもたらす一方で、発想の制約を生み出してきた。 人間が大きなシステムを作るときも何らかの喩えを用いてシステム全体を整理する。アーキテクチャの「ポンチ絵」を描いて情報共有をするのは企業に勤めていれば経験した人も多いだろう。パワーポイン

ZOZOテクノロジーズ・一休・PayPayの3社が、AWS をどう活用しているか紹介する合同イベントで、 ZOZOテクノロジーズの岡元政大氏が中国版ZOZOTOWNでのAWS活用事例を紹介しました。 なぜBtoB事業部が中国版ZOZOTOWNの開発に関わっているのか 岡元政大氏（以下、岡元）：ZOZOテクノロジーズBtoB事業部の岡元政大と申します。本日は「Fulfillment by ZOZOと中国版ZOZOTOWNでAWS Lambdaをどのように用いて開発を行なっているのか」について紹介します。 あらためまして、自己紹介をさせてください。岡元政大と申します。BtoB事業部所属で、こちらは今年の4月に株式会社アラタナが統合されてできた部署になります。拠点が宮崎と東京にあり、自分は東京で働いています。また、個人的な活動として、Serverless Frameworkやその周辺のプラグイン

エムスリーエンジニアリンググループ AI・機械学習チームの中村(@po3rin) です。 好きな言語はGo。仕事では主に検索周りを担当しています。 エムスリーの検索基盤ではElasticsearchを利用しています。社内で積極的に検索改善が行われており複数のIndexが管理がしづらいという問題がありました。 そこで定義ファイルからIndexの状態を冪等性を持って同期させるeskeeperというOSSを作りました。 この経験から「定義ファイルで〇〇を宣言的に管理する系のツール」を作る時のちょっとしたコツを紹介します。タイトルの通り今回はIaCツールを作るのではなくIaCのプラクティスを意識してCLIを作るお話になるのでご了承ください。 なぜeskeeperを作るに至ったか チームでのElasticsearchの運用と課題 eskeeperとは IaCを意識したCLI開発のエッセンス コマンド

▲登壇時の写真 はじめまして、様々なバックエンドの開発をしている竹澤（@ex_takezawa）です。 PHPやGo、Scalaなどを用いてWebアプリケーションからビッグデータを扱う分析システムや、基盤システムを行っています。 今回は、これまでエンジニアとして経験したことを踏まえて、視野を広げることや事業性を理解してシステム開発を行うことの大切さなどを紹介していきます。 みなさんのエンジニアとしてのキャリアにとって少しでも参考になれば幸いです。 副業を起点としたエンジニアの学習サイクル 副業のススメ まず、エンジニアの副業ですが、個人的には、収入が増えるというメリットがフォーカスされがちですが、本業とは異なる事業、会社の規模、ドメイン領域に触れることが出来るという点に大きなメリットを感じています。 副業で得意な開発スキルを伸ばす、ということも当然できますが、本業とは異なるドメイン領域に触

はじめに こんにちは。SRE部BtoBチームの蔭山です。Fulfillment by ZOZO（以下FBZ）で提供しているAPIシステムの運用及び監視を担当しております。 FBZではAWS Lambdaを主軸としてAWSが提供しているフルマネージドサービスのみを利用するサーバーレスアーキテクチャを採用し、構築・運用してきました。今回は実際にどのようにサーバーレスアーキテクチャを活用してサービスを構築・運用・監視しているかご紹介します。 これからサーバーレスアーキテクチャを活用してサービスを構築されようとしている方の参考になれば幸いです。 なぜサーバーレスを採用したのか FBZはZOZOTOWNとブランド様が運営されている自社ECサイト間でリアルタイムに在庫情報を連携し、ZOZOTOWNと自社ECサイトでの在庫の一元管理を実現するAPIサービスです。そのため、マスタであるZOZOTOWNの在

こんにちは、スタディサプリ ENGLISH SREグループの大島です。 オンライン英語学習サービスであるスタディサプリ ENGLISHは2015年10月のリリース1)当時は英語サプリという名前でリリースしていましたから5年が経ち、おかげさまでサービスを拡充させることができています。リリース当初からインフラにはコンテナを採用し、長い間AWSのコンテナオーケストレーションサービスのAmazon Elastic Container Service（以下、ECS）で運用してきましたが、この度ECSからAmazon Elastic Kubernetes Service（以下、EKS）に移行しました。 今回の記事では、その歴史の変遷となぜEKSにしたのかというところを書いていきたいと思います。 コンテナと歩んできた5年間 まず、ECSからEKSに移行しようと思ったきっかけの前に、インフラの歴史を少し振

RDBのレコードに、作成日時や更新日時を自動で入れ込むコードを書いたりすることあると思いますが、それに対する個人的な設計指針です。ここでは、作成日時カラム名をcreated_at、更新日時をupdated_atとして説明します。 tl;dr レコード作成日時や更新日時をRDBのトリガーで埋めるのは便利なのでやると良い ただ、アプリケーションからそれらのカラムを参照することはせず別に定義した方が良い MySQLにおける時刻自動挿入 MySQL5.6.5以降であれば、以下のようにトリガーを設定すれば、レコード挿入時に作成日時と更新日時を、更新時に更新日時を、DATETIME型にも自動で埋めてくれます。いい時代になりました。(MySQLが遅すぎたという話もある) `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_

研修中に「マイクロサービス」の解説をしていると，たまに「モノリス分割」に関する質問が出てディスカッションをすることがある．当然ながら万能な分割アプローチはないけど，例えば DDD (Domain-driven design) などのアプローチを選択するなど，選択肢はいろいろある．そして最近「モノリス分割」に役立つアプローチを紹介した martinfowler.com の記事「How to break a Monolith into Microservices」を読んだ． 具体的には以下の「計8種類」のアプローチが紹介されている．原著を翻訳するのではなく，あくまで個人的なメモとしてまとめる．なお，日本語も個人的に載せているため，参考程度にしてもらればと！ Warm Up with a Simple and Fairly Decoupled Capability（シンプルかつ分離された機能で準

STORESのECサービスを開発している@morihirokです。 STORES ECはRuby on Railsで開発されているWebアプリケーションですが、データベースにはMySQLやPostgreSQLといったリレーショナルデータベースではなく、MongoDBを採用しております。 この記事ではカジュアル面談等で必ず聞かれる「MongoDBって正直どうなの？」といったところを、ストレートにお伝えできればと思います。 なぜMongoDBを採用しているのか そもそもなぜMongoDBを採用しているのか。それは考古学になるのでフィールドワークが必要です。筆者も開発に携わるようになったのは2018年の終わり頃からなので、まずは一緒にSTORES ECの歴史について紐解いていきましょう。 STORES EC（旧STORES.jp）は、heyグループとなるずっと前の2012年、会社名がブラケットだ

はてなブログでSREをやっているid:cohalzです。 2019年12月頃からid:utgwkkやid:onkとともに、はてなブログにおけるキャッシュ周りの改善を行いました。その結果、次のような成果が得られました。 ブログ記事のキャッシュヒット率が、1日平均で8％から58％に向上 アプリケーションサーバの台数を、以前の半数以下に削減 DBに届くリクエスト数が、以前の3分の2まで減少 レスポンスタイムの平均が、以前の8割まで減少 この記事では、実際にどういった改善を行ったのか、その際に気をつけたことや大変だったことを紹介します。 はてなブログがVarnishを導入した経緯と課題 開発合宿をきっかけに問題が明らかになる 進め方をまず考える ホストのメモリをできるだけたくさん利用する メモリを積んだホストでなぜかレイテンシが悪化 キャッシュが分散しないようVaryヘッダを使う デバイス情報を適

AWS Lambdaの環境がどのようになっているか、ユーザが用意したLambdaファンクションがどんな感じで実行されるかってあたりを可能な限り詳しく説明したいと思います。 はじめに 大前提 コールドスタート/ウォームスタート コントロールプレーン/データプレーン アイソレーション AWS Lambdaのコンポーネント群 同期実行かつ初回呼び出し（コールドスタート）、もしくはスケーリング 同期実行かつ再利用（ウォームスタート） 非同期実行 スケールアップ エラーハンドリング リトライ その他 ネットワーク まとめ はじめに この投稿は2020年9月29日の21時から開催予定のイベント（ライブストリーミング）で話す内容です。 serverless-newworld.connpass.com もし間に合えば、かつ時間があればぜひライブ配信のほうにも参加ください。 （2020.09.30 upda

DA事業本部の春田です。 AWS Summit Online絶賛開催中！ということで、本記事では「CUS-60: インフラエンジニアは働かない～AWSのフルマネージドサービスでメンテフリーになるまで～」の内容についてまとめていきます。 セッション情報 株式会社カプコン システム開発部 中村 一樹 氏 株式会社カプコン システム開発部 中島 淳平 氏 DL数500万を超える大型タイトル、モンスターハンターライダーズ。 メンテフリー、省コスト、最先端、をテーマにしたカプコン史上最大のインフラアーキテクチャはどの様に設計され、どう運用されているのか。コンテナって実際どうなの、Kubernetes？ECS？RDBMSを使わずしてサービスを提供することは可能？大量アクセスにより生成されるログを安全に回収するにはどうする？実際に運用してみた経験や事例を踏まえて、カプコンの考えるクラウドネイティブ時代の

最近、パーフェクトRuby on Railsの増補改訂版をリリースさせていただいた身なので、久しぶりにRailsについて書いてみようと思う。 まあ、書籍の宣伝みたいなものです。 数日前に、noteというサービスでWebフロント側に投稿者のIPアドレスが露出するという漏洩事故が起きました。これがどれぐらい問題かは一旦置いておいて、何故こういうことになるのか、そしてRailsでよく使われるdeviseという認証機構作成ライブラリのより良い使い方について話をしていきます。 (noteがRailsを使っているか、ここで話をするdeviseを採用しているかは定かではないので、ここから先の話はその事故とは直接関係ありません。Railsだったとしても恐らく使ってないか変な使い方してると思うんですが、理由は後述) 何故こんなことが起きるのか そもそも、フロント側に何故IPアドレスを送ってんだ、という話です

クレジットカード決済情報を扱うためには、カード情報や取引情報を保護するために策定されたPCI DSSに準拠することが求められる。これら基準を厳格に満たしつつ、プラットフォームの設計や工夫でうまく複雑さを吸収し、運用負荷を下げることはできないだろうか。そんな課題を自ら課して、”普通の決済サービス”ではなく”プラス1の決済サービス”作りを実現したミクシィの田岡文利氏とIDペイメント事業部のチームメンバーたち。同氏はPCI DSS対応の基本や要件を整理しながら、負担少なく運用可能な決済サービス基盤を構築するためのポイントを紹介した。 講演資料：「サーバーレスPCI DSS対応クレジットカード決済 基盤システムを運用しながら、みんなでわいわい DIYの精神で、新しいモバイル決済サービス 6gramをともにつくっている話/6gram-DIY」 運用負荷を押さえながらPCI DSS対応するには ミクシ

目次 本エントリの概要 前提と環境条件 背景 要件 移行手順詳細 既存の構成 1. スキーマ定義の取得 2. 5.6のインストール 3. 5.7のインストール 4. 8.0のインストール 5. 中間インスタンスへのデータ投入 6. 中間インスタンスのデータ同期 7. 本番およびスタンバイに8.0をインストール 8. 本番およびスタンバイにデータ複製 9. 本番およびスタンバイの準備完了 10. 切替作業 11. 後始末 感想 参考) 非サポートな操作(のひとつ） 本エントリの概要 この記事は MySQL Advent Calendar 2019 - Qiita の15日目です。 タイトルの通り、職場のMySQL5.5を8.0にマイグレーションした話を書きます。 前提と環境条件 登場するサーバーはすべてWindows ほぼ政治的な理由（主題ではないので具体的な理由は割愛） システムは小規模で