基調講演では、GitHubの新機能としてプロジェクトの依存関係を表示する「Dependency graph」や、このDependency graphにおいてパッケージやアプリケーションの対応や、依存関係にあるパッケージなどで脆弱性が発見された場合に通知してくれる「Security alerts」機能などが発表されました。 プロジェクトの依存関係を表示する「Dependency graph」 GitHub上で開発されているソフトウェアの多くは、ほかのプロジェクトで開発されているソフトウェア、パッケージ、アプリケーションなどを利用しています。 同社はこうしたプロジェクトの依存関係を「Code metadata」として保持しており、同社 データサイエンスチームのエンジニアリングマネージャのMiju Han氏によると、リポジトリの75％が何らかの依存関係を持ち、半分以上は10以上の依存関係を持ち、

中長期のための大きなデザインも大事だけど、そのために日々の改修が犠牲になってはならない（その逆は言語道断）。そんなわけで、しばらくの間は、1〜2日で終わる小さな改修を、コンスタントにnoteチームに提案したいなぁと考えている。 もちろん、「リソースが許せば」だけれども。なぜならpiece of cakeにはまだデザイナーが1人しかいないことだ。そんなわけで、中長期でどういうチームを作るべきかウンウン唸っている。 並行して走るスロットが3-4つ欲しい理想を言えば、デザイン/開発リソースを3つのグループにわけたい。「大局リソース」、「開発リソース」、「カイゼンリソース」の3つだ。これらはそれぞれ独立しているのが望ましい。複数のレイヤーを1人のスタッフが兼任していると、どれかが忙しくなると、他の全てがストップしてしまうからだ。 大局リソース ガイドライン、コンポーネントなど、会社全体にストックさ

tech.mercari.com 先日からお伝えしていた通り、9/30 （土） にベルサール六本木にて第1回 Mercari Tech Conf 2017 が開催されました。 テーマに Next を掲げ、過去から現在にいたるまでに実現してきたこと、そしてこれから実現する未来について発表しました。 togetter.com それでは、簡単に各発表を振り返っていきます。 基調講演 鶴岡 達也 (Head of Engineering, Souzoh) / 柄沢 聡太郎 (VP of Engineering) / 名村 卓 (CTO) 3名による基調講演でした。 メルカリ初期の話 – 鶴岡 この頃はとにかく素早くものを作る必要があった シンプルな LAMP 構成を採用した。LAMP なのは初期のエンジニアが一番触りやすい構成、言語だから。人のスケールをさせやすいから インフラはハイエンドな1つの

Pythonを使ってこの方さまざまな点につまずいたが、ここではそんなトラップを回避して快適なPython Lifeを送っていただくべく、書き始める前に知っておけばよかったというTipsをまとめておく。 Python2系と3系について Pythonには2系と3系があり、3系では後方互換性に影響のある変更が入れられている。つまり、Python3のコードはPython2では動かないことがある(逆もしかり)。 Python3ではPython2における様々な点が改善されており、今から使うなら最新版のPython3で行うのが基本だ(下記でも、Python3で改善されるものは明記するようにした)。何より、Python2は2020年1月1日をもってサポートが終了した。よって今からPython2を使う理由はない。未だにPython2を使う者は、小学生にもディスられる。 しかし、世の中にはまだPython3に

AWS ELB (ALB, CLB) には日頃からだいぶお世話になっているわけですが、新しい Network Load Balancer (NLB) がリリースされましたね。 新しいNetwork Load Balancer – 秒間数百万リクエストに簡単にスケーリング | Amazon Web Services ブログ 雑に言えば CLB TCP モードの次世代版というとこですかね。 ざっくりドキュメントを読みつつ、いくつか気になる点があったのでまとめます。 ドキュメントに記載されていない内容は私が検証した内容です。何か間違いがあればお気軽にご指摘ください。 パケットはどのように流れるのか 一応図にしておきます。なんというか懐かしい (とか言ったら怒られそうな) 流れですね。 ALB や CLB (HTTP, TCP 両方) ではロードバランサがそれぞれの通信を終端していわゆるプロキシの

PackerBuild and manage images as code​​​​‌‍​‍​‍‌‍‌​‍‌‍‍‌‌‍‌‌‍‍‌‌‍‍​‍​‍​‍‍​‍​‍‌‍‌​‌‍​‌‌‌​‌‍‌‍​‌‍‌‌​​‍‍‌‍​‌‍‌‍‌​‍​‍​‍​​‍​‍‌‍‍​‌​‍‌‍‌‌‌‍‌‍​‍​‍​‍‍​‍​‍‌‍‍​‌‌​‌‌​‌​​‌​​‍‍​‍​‍‌‍‍​‌‍​‌‌​‌‍‍​‌‍‍‌‌‍​‌‍‌​‍‌​​​‍‍‌‍​‌‌‍‌​‌‍‌‌‍‍‌‌‍‍​‍‍‌‍‌​‌‍​‌‌‌​‌‍‌‍​‌‍‌‌​​‍‍‌‍​‌‍‌‍‌​‍‌‍‌‌‌‍‌​‌‍‍‌‌‌​‌‍‌​‍​‍‌‍‍‌‌‌​‌‍‌‌‌‍‌‌‌‌‌​‌‍‌‌​​‌‍‌‌‌​​‍‌‌‍‌​‌‍‌‍‌‍

CircleCI now supports GitLab SaaS and self-managed code repositories.

GitHub と AWS CodeBuild を連携させるサーバーレスなツールを作りました [中身編] 紹介編の続きです. 本記事では github-codebuild-integration の構成や実装などについて掘り下げてみます. このあと何回も github-codebuild-integration と書くと疲れそうなので、以下 gci と書きます. また、本記事中でコードやファイルに対して張られているリンクはすべて記事公開時点で最新の v0.1.1 のものです. 目次 gci リポジトリの中身の話 デプロイまわりの話 Amazon API Gateway じゃなくて Amazon SNS を選んだ理由 AWS SAM と node_modules の関係がエグい AWS Step Functions ええやん CloudFormation Lambda-backed カスタム・

AWS Summit Tokyo 2017のServerless Evolution Dayでの講演資料です。

本日（現地時間 8/21）、Route 53 が CAA レコードに対応しました。 Amazon Route 53 now supports CAA records CAA Format - Supported DNS Record Types - Amazon Route 53 さっそくマネジメントコンソールから設定できるようになっているわけですが、その前に CAA レコードについて少し解説します。 CAA (Certification Authority Authorization) レコード ひとことで言うと、 「このドメインに関する証明書(SSL, TLS)を発行できる認証局(CA) を指定する」ためのレコードです。 例えばこのレコードに「認証局 A しか発行してはならない」と記述した場合は、認証局 B はたとえリクエストがあったとしても証明書を発行しません。 勝手に他人のドメイン

セクションナイン の 吉田真吾（@yoshidashingo）です。 SRE本の原書が出てから早1年半が経ちました。原書はすでにオンラインで無料で読めるようになっています。 Google - Site Reliability Engineering 前回このブログでSREについて書いたのが、原書の出る1ヶ月くらい前ですね。 yoshidashingo.hatenablog.com 国内でもSRE部署の設置が急速に進んでますが、運用部門をSREと看板を掛け替えただけの劣化コピーが大量生産されていることも否めなかったりなかったり。 そもそもSREは、従来のシスアドではなくソフトウェアエンジニアです。そして、開発／運用の分断による必然的な対立関係をインセンティブ設計で統合し、サービスの成長と運用コストが比例しないように切り離すための組織設計であり、そのための技術ノウハウです。 今日は今週末発売さ

tl;dr RailsのコネクションプールとAmazon Auroraのフェイルオーバーの仕組みは相性が悪く、フェイルオーバー時に致命的な問題が発生する 解決方法の1つは、コネクションプールを使わないこと ただし、都度接続だと接続コストがかかる New Relicなどを使ってる場合は、自分の実装以外で使ってるコネクションまで都度接続になってしまう 別スレッドでDB操作を行っている場合、処理中であってもそのスレッドのコネクションまで切断されてしまう（Railsのコネクション破棄がプロセス単位のため） コネクションプールを活かしたままこの問題を解決できたので、その方法をご紹介します。ちなみにRails 4.2の話。 RailsとAmazon Aurora利用時のフェイルオーバー問題とは 詳しくはこちら qiita.com 問題が発生する状況をまとめると以下の通りです。 Amazon Auror

[20170809追記] nginx-1.13.4に ngx_http_mirror_module は含まれました Nginxで、リクエストを複製するmirrorモジュールがコミットされ、何もせずとも使用できるようになりそうです(現状最新コミットをビルドする必要あり)。 例えば本番環境のproxyからリクエストを複製して開発環境に流すような事も出来ます。もちろん複製処理は本来のリクエスト処理をブロックしません。 例えば以下のように、mirrorに来たリクエストを複製してバックエンドサーバに投げるようにしてみます conf server { listen 80 ; server_name localhost; mirror_request_body on; log_subrequest on; location /mirror { mirror /proxy; #/proxy宛にリクエストを

10年以上金融機関で働いているインフラエンジニアの落ちないサーバにするための考察です。 ハードウェアの専門家ではないので、正確ではないかもしれません。 今までの経験からの個人的考え方になります。 私たちオンプレ重視のインフラエンジニアは、 クラウドサービスではできない高可用性サーバを導入したり、 複数台構成で１台故障しても問題ない構成のサーバはコスト重視するなど、 システムに最適なサーバを導入しようとしています。 #高可用性サーバを追求する目的 ■アプリに影響を与えないように Active/Standby構成にしていて、インフラ的にはダウンタイムが数秒だとしても、 アプリによっては復旧に時間がかかったり、問題ないことの確認にも時間がかかってしまいます。 また、正しくサーバが落ちればアプリが問題ないとしても、 サーバが中途半端な状態のままになってしまい、なんだかおかしいということもあります。

デザイナーという職業柄 クリエイティブやサービスやアプリなどなど デザインという観点で 意見を求められることが多いのですが こういう時って気を抜いているというか油断してると 悪いところの指摘が先行して 良いところの指摘を忘れるので 気をつけているという心がけがあります デザインに対して 特に見た目に関しては 悪いところを言語化するのは 非常に難易度が低くやりがちで 逆に良いところを言語化するのは 難易度が高く 意識してないとあえて言わないケースが 多くなるのかなあと デザインの 良いところを意識して言うようにしてるというのは 悪いところの改善をしやすくするためという文脈があり 悪いところだけ指摘すると そこだけ直して整合性が取れなくなったり 逆に良いところを改悪してしまう場合があるため 良いところを指摘して認識してもらうというのは 重要だと思っています あと 単純に 褒めてから足りないとこ

こんにちは。村☆☆☆ハンターの @sugitak です。freee ではインフラ的なことをしていて、個人では一年に一度くらいbundlerの記事書いています。あとCONBUとか参加してます。 freeeでは日々様々な革命が行われていますが、革命にはパンがつきものです。パン、すなわち無線です。革命家にパンが必要なように、エンジニアが自由に働くためには無線が必須なのです。有線ではいかんのです。 ということで、今回はfreee Engineers Advent Calendar 2015 5日目の記事では、スタートアップのオフィス無線を良くするにあたって大事な 5 つのポイントについて説明したいと思います。 アクセスポイント(AP)の収容端末数を気にしよう さて、まずは「収容端末数」について説明します。 10人以下のオフィスでは、ヨ○バシで売っている buffal○ や I○DATA など、普段

クラスメソッドが運営するIT系技術ブログDevelopers.IOのカンファレンスイベントDevelopers.IO 2017にて、セッション「Amazon Elasticsearch Service の使いドコロ」を発表しました。そのレポートです。 発表スライド セッション概要 Amazon Elasticsearch Service の使いドコロ というテーマで今回は大きく 2つのテーマで 45分間お話しました。 全文検索と RDBMS と Elasticsearch と 私は AWS 事業部に所属しており、全文検索、Elasticsearch、Kibana を活用したデータ可視化に関して問合せを受けた時にお客さんとディスカッションするプリセールスや、お客様が導入している Elasticsearch インフラの改善提案などのコンサルティングを行っています。その中の知見の一つとして、お客