この記事ははてなエンジニア Advent Calendar 2020の6日目の記事です。 qiita.com 5日目は id:mizdra さんによるpolyfill を深堀りするでした。フロントエンド周りは弱い自分としてもこの記事を読むだけでpolyfillの概要から今後どうすると良いかなど知れてとてもありがたい記事でした。 www.mizdra.net さて今日は視点変えてツールの話を書きます。毎日使っているツールこそ、提供されている便利な機能を把握しておきたい。Macで使ってるターミナルアプリ「iTerm2」について書きます。 iterm2.com まずはみんながひょっとしたら知らない基本操作についていくつか紹介し、後半はTriggersという機能の使い方をいくつか紹介します。 (記事執筆時点ではver.3.4を使っています) tl;dr 公式ドキュメントにいろいろ書いてあるので読み

この記事は、下書き供養 Advent Calendar 2018 - Adventarの2日目の記事です。 めっちゃ専門的な内容になってしまいました。ごめんなさい。 某Slackでの議論内容をブログに書こうとしたのですが、下書きのまま放置していました。 Wednesday, August 15th と書いてあるので、約半年前の内容となります。 もくじ もくじ はじめに 「データ基盤の3分類」と「（一般的な）技術要素」 1.データレイク（Data Lake） 2.データウェアハウス（Data Warehouse） 3.データマート（Data Mart） 私が考えるデータ基盤の定義 私が考える「あるべき構成」 技術要素を分けるのはアンチパターン 進化的データモデリングを容易にしよう チームとアーキテクチャを選ぶ まとめ 参考 余談 追記 はじめに データ基盤と世間一般で言われるシステムには分類

2023年03月31日追記：この記事を基に、@sadnessOjisanさんより、コードレベルにより踏み込んだ、かつ、グリーンスレッドベースの新しいWebサーバアーキテクチャも含めて整理された記事 Webサーバーアーキテクチャ進化論2023 | blog.ojisan.io が公開されました。 主に新卒のWebエンジニア向けに、古典的なWebサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介します。 この辺りの話題がWeb界隈で流行っていたのは数年以上前というイメージですが、Webサービスは相変わらずWebサーバの上で動いているので、流行り廃り関係なく学ぶべき内容だと思っています。 また、HTTP/2がいよいよRFC化し、既にh2oやtrusterdなどのHTTP/2のサーバ実装があり、今後Webサーバアーキテクチャを再訪することが増えるような気がしています。 ところが、We

データベーステーブル設計の基礎の基礎～エンティティの抽出・定義から正規化まで 適切な形でデータベースのテーブルを設計し、運用するには？テーブル設計に必要な初歩を日本MySQLユーザ会副代表の坂井恵さんが丁寧に解説します。 金融系アプリ、ゲーム、人工知能などなど……。どんな種類のシステムを開発する上でも、避けて通れない領域があります。データベースです。データを適切な形式で格納し、取り出す。単純明快ながらも奥深いこの仕組みは、多くのシステムの根幹を支えています。 しかし、適切な形でデータベースのテーブルを設計し、運用するのは簡単なことではありません。「良いテーブル設計」のためには知識と経験が不可欠です。今回は日本MySQLユーザ会の副代表である坂井恵さんに、これからテーブル設計に着手する方に向け、設計に必要な技術と、良い設計を作るための考え方を教えていただきました。 坂井恵（さかい・けい） @

この記事は Mackerel プラグインアドベントカレンダー(全部CRE） の20日目です。 qiita.com soudai.hatenablog.com それでは20日目は mackerel-plugin-mysql 第二弾、InnoDBの監視です。 mackerel-plugin-mysqlはRDBMSとして広く使われているMySQL専用のプラグインです。 第一弾はこちら。 soudai.hatenablog.com インストール方法や使い方、MySQLのデータ取得で使っているSQLは前回説明したので割愛します。 前回はMySQL全般に言える監視の内容でした。 今回はその中でもInnoDBに特化した内容でお送りします。 見れるメトリック それでは各グラフ定義ごとに説明します。 また表に出てくるdiffとはプラグイン上で差分値計算をするかどうかです。 ◯ となっている項目はプラグインで

こんにちは。SPEEDA開発チームの鈴木です。 これまでマルチホストでのContainer間通信について、 Dockerのネットワークの基礎(前々回) マルチホストでのContainer間通信を実現する手段の一つとしてのOverlayNetwork(前回) といった話をしてきましたが、3回目となる今回はこれまでの内容を踏まえた上でKubernetesのネットワークについてお話します。内容としては大きく次の2つになります。 どうやってマルチホストでのContainer間通信を実現しているか Service名でPodと通信できるようするための仕組み では早速1つ目の話をはじめましょう。Kubernetesを利用する場合、基本的には複数のノード上にKubernetesクラスタを構築することになります。 （minikubeを使って単一ノードからなるKubernetesクラスタを構築するような例外は

こんにちは。SPEEDA開発チームの鈴木です。 前回はマルチホストでのDocker Container間通信の説明の前段として、Dockerのネットワークが次のようになっているという話をしました。 今回はいよいよ、マルチホストでどうやってDocker Container同士の通信を実現するのかを説明していきます。 はじめに DockerによるContainerのマルチホスト間通信 Port Forwarding Overlay Network 1. Docker Swarm mode 2. 分散KVSとdocker network create -d overlayコマンドを使って自前で構築 3. flannelのようなOverlay Network構築ツールを使う Overlay Networkだけで解決できないこと シリーズ はじめに マルチホスト間でのDocker Container

こんにちは。SPEEDA開発チームの鈴木です。 調べてみるとなかなか興味深い技術であるマルチホストでのDocker Conainer間通信。 これをどのように実現しているのか説明したいと思います。 が、その前に今回の投稿では、まず基礎知識的な話としてDockerのネットワークについて順を追って説明をします。 Dockerのネットワーク docker0 docker0に接続されているネットワーク・インタフェース veth ネットワーク名前空間 Docker Containerのネットワーク名前空間を参照する ルーティング シリーズ Dockerのネットワーク docker0 Dockerをインストールしたあと、ifconfigやip addr showするとdocker0なるものが表示されるようになるので、気になっていた人もいるかと思います。 これは一体何者なのでしょうか。 [kenji@a

仕事は大変なものだ、仕事は楽しいものだ、楽しいことを仕事にすれば良い、楽しいことばかり考えていては仕事にならない....などなど、仕事に対する言論がこれまで幾度となく繰り返されてきた。楽しいことを仕事にすれば良い、楽しいことをやれば良い、と言ったり言われたりしていたものの、やはり自分の中ではその考え方がうまくまとまっていなかった。しかし、2017年を振り返ると、自分なりに技術そのものを楽しみ、楽しく仕事をすることの意味が理解できた年だった。 僕にとって技術を学ぶこと、それ自体はとても楽しいことであるし、技術を持って仕事をなすサイクルはそれもまた自分にとって大変楽しいことである。では、楽しくない仕事だとやらないのか、と言われるとそんなことはなく、会社を通じて社会に貢献することが対価を生み出しその対価によって生かされているのだから、当然楽しくない仕事も社会に貢献するためにやるのである。ただ、僕

嫌になるほど苦手だったブログ執筆は、 デザイン制作に欠かせないスキル向上の宝庫だった会社の技術ブログ執筆に誘われたことがきっかけです。 「ブログ執筆を習慣化すればデザイナーは一石二鳥だ！」と感じたデザイナーにとっての3つのメリットについて。そして、ブログ執筆の苦手意識をどのように克服したかについてお話します。 先日SketchとAdobe XDの比較についての記事を会社ブログに書きました。 【チームの課題から考える、Adobe XDとSketchの導入メリット】 予想に反して多くの方に読んでいただきまして恐縮しております。振り返れば執筆依頼されたときは正直本当に嫌で（笑）全く筆が進まず完成まで2週間以上もかかっています。発狂しそうでした。 ただ一方で、書くことで得たスキルや工夫したことは、デザイン制作に欠かせないコミュニケーション力とよく似ていると感じました。 デザイン制作におけるコミュ力

この記事は RECRUIT MARKETING PARTNERS Advent Calendar 2017 の投稿記事です。 こんにちは！現在キッズリーのデザインを担当しているデザイナーの町田（@macheri_me）です。 今年で中途入社３年目となりました。本日は弊社の制作事例をもとに、AdobeXD・Sketchの活用法についてご紹介します。 【この記事を読んでもらいたい人】 これからAdobe XD、Sketchどちらを導入しようか悩んでいる人 デザイン制作フローの中で課題を抱えており、解決したい人 Adobe XDとSketch。自分のチームにはどちらが最適か サービスのデザインを制作する際、何のツールを使っていますか？少し前だと Adobe Illustrator、Photoshop、Fireworksといったグラフィックツールが多かったかと思います。しかしながら、これらはUIデ

VPCエンドポイントの方式 ゲートウェイVPCエンドポイント（既存方式） VPCエンドポイントは、今までS3とDynamoDBが対応していました。仕組みは下図のようにVPCのルートテーブルを書き換えてインターネットゲートウェイでなくVPCエンドポイントのゲートウェイ経由でAWSのAPIエンドポイントへアクセスしていました。今回この方式はゲートウェイVPCエンドポイントと呼ばれるようになりました。ゲートウェイVPCエンドポイントではAWSのAPIへはパブリックIPへ向いており、アクセス制御はゲートウェイのアクセスポリシーで行います。 インターフェイスVPCエンドポイント（新方式） 今回追加されたものは、下図のようにサービスのエンドポイントとENIをPrivateLinkと呼ばれるものでリンクされます。DNSを使ってENIのプライベートIPに<サービス名>.<リージョン&gt

はじめに re:Invent2017のセッション「CON308 - Mastering Kubernetes on AWS」を聞いてきました。以下がセッションの概要です。 A lot of progress has been made on how to bootstrap a cluster since Kubernetes' first commit and is now only a matter of minutes to go from zero to a running cluster on Amazon Web Services. However, evolving a simple Kubernetes architecture to be ready for production in a large enterprise can quickly become overw

はじめに re:Invent 2017 Keynote Day1で発表され大盛り上がりを見せたElastic Container Service for Kubernetes(EKS)。 【速報】AWSのマネージドKubernetesサービス、Elastic Container Service for Kubernetes(EKS)が発表されました！ #reinvent AWSサービスの内側まで含めて詳しく聞けるDeepDiveセッションのEKS版「CON409 - Deep Dive into Amazon EKS」に参加してきました。そのレポートです。 セッション概要 Amazon Elastic Container Service for Kubernetes (Amazon EKS) is a new managed service for running Kubernetes o

AWS re:Invent 2017で発表されたコンテナ関連サービス(EKS、Fargate)のまとめと自社サービスへの活用 大島 雅人 2017.12.01 113 18323924 この記事は RECRUIT MARKETING PARTNERS Advent Calendar 2017 の投稿記事です。 こんにちは、開発支援Gでインフラ運用をしている大島です。アドベントカレンダー 2017 の記念すべき1日目は AWS re:Invent in ラスベガス からお届けします。 AWS re:InventはAmazon Web Service, Inc.が毎年開催している技術とマーケティングののカンファレンスで、今回は6回目の開催となります。新しいサービスや機能のアップデートが基調講演で発表されたり、1000以上のセッションが行われたりするなどお楽しみが盛り沢山な5日間のイベントです。

Speee社でISUCON7の復習会をやったのでその資料を公開します。 ISUCON7復習会 2017/11/08 at Speee Lounge. original repo: https://github.com/isucon/isucon7-qualify 概要 ISUCON7の予選突破組の上位陣の戦略をいくつか分析してみました。 †空中庭園†《ガーデンプレイス》 repo: https://github.com/ryotarai/isucon7q http://eagletmt.hateblo.jp/entry/2017/10/24/010832 https://mozami.me/2017/10/24/isucon7_qualify.html スギャブロエックス repo: https://github.com/gfx/isucon7-qualify http://memo.su

ここからはサーバーサイドにフォーカスした大規模改修の詳細についてご紹介します。 大規模改修前のサーバーサイドの構成 当時はこのようなレイヤードアーキテクチャを採用していました。縦はController、UseCase、Repository、データ層で区切り、横はコンテキスト毎にパッケージで区切られています。当初から複雑な仕様・要件でしたが、それぞれの影響範囲は明確となっているので、新規に参画するエンジニアにとっても十分に見通しの良いものとみなしていました。 事実、この設計で２年ほどエンハンスを続けてきましたが、大きな問題が発生することはありませんでした。 なぜ大規模改修が求められるようになったのか 『TOEIC対策コース』の新設が決まり、その仕様を詰めていくうちに次のことが浮き彫りとなってきました。 TOEIC対策コースと日常英会話コースとでは『レッスン』と『トレーニング』のツリー構造が根

(c) Recruit Co., Ltd.

どうですか？ Rubyって新参者のイメージがあると思うんですけど、実はJavaと同じぐらい古いんですよ。 ちなみに、World Wide Webの原型になるものが作られたのは1990年だったそうです。Rubyを作りはじめた当時の1993年の時点では、World Wide Web自体は存在はしていたのですが、世間一般にはほとんど認知されていませんでした。つまり、冒頭でも申し上げたとおり、Rubyはweb用に開発されたわけではなかったのです。 当時すでに先輩としてPerlという言語があったのですが、その代わりになるような言語を作りたかった。でも単にまったく同じものを作ってもしょうがない。その頃の私はオブジェクト指向に傾倒していたので、こう考えました。 「オブジェクト指向に基づいて言語をデザインすることで、既存のものよりも良い言語が作れるんじゃないか」 ―― それがRubyの始まりです。 国際色