ども、ゲストブロガーの大瀧です。 クラスメソッド在籍中の2018年2月頃社内向けにDNS勉強会を全4回で開催したことがあり、そのときの資料がひょこっと見つかったので公開してみます。(正確には第3回は聖剛さん担当だったので一緒に公開してもらいました、感謝。) 第1回 DNS入門 : DNSのしくみ、キャッシュ 第2回 DNSコンテンツサーバー : DNSサーバーの分散構成とゾーンの委任 第3回 DNSセキュリティ : DNS関連の攻撃手法とDNSSEC 第4回 AWSのDNSサービス : Route 53とAmazon DNS DNSについての理解を深める一助にしていただければと思います。現職(SORACOM)でももちろん超重要な技術です！ 第1回 DNS入門 スライド共有サービス終了に伴い、公開終了 第2回 DNSコンテンツサーバー スライド共有サービス終了に伴い、公開終了 第3回 DNS

ペアワイズ法を使うことで、効率的にテストケースを絞り込めることがわかったかと思います。 --- 2019/10/31 追記 --- どうしてテストケースを絞り込んでも大丈夫なのか？という意見がSNSやはてブのコメントで見受けられたので、フォローアップエントリを書きました。こちらも合わせてご覧ください。 ペアワイズ法は本当に有効なのか？組み合わせテスト技法と上手に付き合う方法 ｜ DevelopersIO ペアワイズ法を支えるツール「PICT」 ペアワイズ法が有効なことはわかりましたが、この組み合わせをどうやって作れば良いでしょうか？条件の数が少なければ前述のように手作業でもやれないことはありませんが、現実の問題はもっと複雑ですので、到底無理でしょう。 そこで役に立つのが、ペアワイズ法のテストケースを生成してくれるツール「PICT」です。 microsoft/pict: Pairwise I

育成チームのリーダーを行なっている都合から、エントリー向けのインフラエンジニアの書籍を読むことが多くなっています。本日は、その中で読んだ、「**インフラ設計のセオリー**」という本についてご紹介させていただきます。 基本的にはIPAの非機能要求グレードに沿って特に重要な項目を説明していく内容になっています。 インフラエンジニアを始めるときに、教科書として読んでおけば成長曲線が変わったんじゃないかな？と感じました。それくらい基礎的な知識の習得とイメージ付けには最適だと思います。 「難しい本ばっかり読んで眠くなってませんか？いい本ありますよ！」 ご機嫌いかがでしょうか、豊崎です。 育成チームのリーダーを行なっている都合から、エントリー向けのインフラエンジニアの書籍を読むことが多くなっています。本日は、その中で読んだ、「インフラ設計のセオリー」という本についてご紹介させていただきます。 基本的に

こんにちは。プロダクトグループのshoito(しょいと)です。 9/26(水)に開催された レガシーコードにドメイン駆動設計で立ち向かった5年間の軌跡 に参加してきたのでレポートします。 当日のtwitterのハッシュタグ#DDDAllianceのツイートがTogetterでまとめられています。 BIGLOBEにおける、5年間のDDDへの取り組みと今後について ビッグローブ株式会社 西 秀和さんより 30年間、事業を支えてきた業務システムをDDDで刷新する。 そのためには、組織的、エンジニアのレベルなど多くの問題があります。 その壁をどう乗り越えたのか？ そして、壁の向こうで得た恩恵とは何のか？ 5年という期間を経て、得ることのできた気づきや組織的な変化をお伝えしたいです。 アジェンダ DDD導入に至るまで 導入時の苦労 導入による効果 今後の目標 BIGLOBE販売システムについて、DD

2018年5月25日より、EU一般データ保護規則（General Data Protection Reguration: GDPR）が欧州で適用されます。欧州議会が以前に制定し各国で法制化が進んでいるデータ保護指令（Directive 95/46/EC）を置き換える統合的な規則で、従前と比べて厳しい罰則、対応する国内法を採決する必要がない、EU外へのビジネス上の影響が大きい、など、EUの単一デジタル市場戦略のマイルストーンとなるイベントです。（単一デジタル市場についてはこちら） 一言にデータ保護と言ってもカバー範囲によって目的と手段が分化されます。 個人情報の保護に関するもの データの保存、保護、監査に関するもの 商習慣や各国の政策に基づいて適者生存に結びつくもの 特にリーガル部門をもつ大手コンサルティング会社によって上記を峻別せずにGDPR対応をうたった恐怖マーケティングが盛んに展開され

はじめに クラスメソッド株式会社 AWS事業部長の佐々木です。 私は前職で創業メンバーの1人としてビジネスを立ち上げた後、エンジニアとして実業務に携わりながら、統括マネージャーとして50人規模のエンジニア組織を構築しました。 また2014年にAWSエンジニアとしてクラスメソッドに入社し、2015年7月よりAWS事業部の部長に就任。事業は順調に拡大しており、2015年と比較して組織も2倍以上に大きくなりました。これは優秀な仲間に恵まれたのはもちろんのこと、組織設計と構築プランが功を奏したことも一因だと感じています。 そこで、私がこれまでに培ってきた経験から得たエンジニア組織の構築の仕方をお伝えしたいと思います。 エンジニア組織構築マニュアル 骨子を定義する これはエンジニア組織に限りませんが、組織には3つの骨子が必要です。 ポリシー ビジョン ターゲット ポリシーは、その組織が最もこだわる一

森永です。 新年早々大変な脆弱性が出てきてセキュリティクラスタがざわついてます。 内容によって2つの脆弱性に分かれていて、「Meltdown」と「Spectre」と名前がつけられています。 現在使用されているほぼ全てのCPUにおいて対象となりうるという相当影響範囲が広い脆弱性です。 まだ詳細が公開されていない部分もありますが、パッチで対処できる脆弱性ですので落ち着いて対応し、続報を待ちましょう。 現在分かっている範囲の情報をまとめます。 Meltdown and Spectre 概要 今回の脆弱性は大きく3つに分けられます。 Variant 1: bounds check bypass (CVE-2017-5753) Variant 2: branch target injection (CVE-2017-5715) Variant 3: rogue data cache load (CV

はじめに 小室です。2017年も最後の日になりました。 ここ最近は読書によるインプットが少なくなったことによって、文章の質が自ら目を背けたくなる程度に低下していたため、仕事納めから数日はひたすら本を読む生活をしていました。まだまだインプットが足りていないので充電が完了していないのですが、年末恒例になったエントリーを書かないことが自分の中でモヤモヤとして残っていたので、重い腰を上げて文章を書いてみようと思います。 ここ数年は珍しく1つのプロジェクトにつきっきりで設計／実装から運用までを通して担当しています。 *1特に運用を担当するようになって多くを学んだ一年でした。もはや設計・実装者が一人も残っていないアプリケーションのメンテナンス、改修に関わったり、インフラ側とアプリケーション側の狭間を埋めるように動くためにAWSのサービスについて本格的に勉強をしたりするなど、1アプリケーションエンジニア

メールやチャットなど色々なところに通知が飛びます。 例えば会議が始まる前にチャットに通知したり、CircleCIがビルドを完了したらメールに通知したりしていますが、どちらも私が見に行かないといけません。 チャットを全然気にしていないタイミングで会議が始まったら通知を逃し、会議に行けない（遅れる）、といった結果が想定されます。 OSの機能で通知することで、私が気づく確率が上がるのではないかと思い調べていたところ見つけたのが今回紹介するAlerterです。 Alerter Alerter/Send User Alert Notification on Mac OS X 10.8 from the command-line. alerter is a command-line tool to send Mac OS X User Alerts (Notifications), which are

なんて操作をしたあと、そのディレクトリにcdしたい場合ってまれによくありますよね。 どんなやり方があるか考えてみました。 1. コピペする そのまんまですが、これをやりたくなくてこの blog を書いてます。 2. TAB 補完で頑張る これも無いわけではないですが、間違えたりすることを考えると正直あんまりやりたくないです。 3. 上矢印キーで前コマンドを呼び出し、右矢印キーで先頭に戻ってmkdirをcdに書き直す よく見る方法ですが、もうすこし少ない手数でできないでしょうか。 4. 上矢印キーで前コマンドを呼び出し、Ctrl-Aで先頭に戻ってCtrl-Dx5 のあとにcd BASH のキーバインドはデフォルトだと emacs モードなので、このやり方が出来ます。 でもまだちょっと手数が多いですね… 5. 上矢印キーで前コマンドを呼び出し、Ctrl-A → Alt-F → Ctrl-W →

先日開催されたAWS Summit Tokyo 2017、わたしもいくつかセッションを聴講してきたのですが、「DevSecOps on AWS - Policy in Code」というセッション1にてgit-secretsというツールが紹介されていました。 awslabs/git-secrets: Prevents you from committing secrets and credentials into git repositories これ以外にも、いくつかのセッションで言及されていたと思います。 git-secretsのことは以前から聞いてはいたのですが、自分自身があまりコードを書く環境にいなかったので、良くないとは思いつつも今まであまり気にしていませんでした。 ただ、AWSアクセスキーの漏洩が原因と思われる話を聞く機会はなかなか減りませんし、考えてみれば自分でも、AWSクレデ

主にクラスメソッドメンバーズにおけるサポートサービスとフートシリーズ（運用保守オプション）を担当するグループです。運用保守、システム監視、セキュリティ監視、継続的コンサルティングと、システム稼動後のお客様インフラを24時間365日体制で安定した状態に保つために日々お客様とやりとりしています。 このように、一つの部の中に担当業務が違う複数のグループがありますが、部全体のビジョンはただ一つ、「AWSに関する圧倒的な量のノウハウを用いて、AWSインフラを安く早く構築し、AWSのことをまるっとお任せしてもらうことで、お客様のビジネスに貢献する」です。そして同じビジョンを掲げたチームとして、採用方針もグループ毎に分けず、部として統一しています。 今回はAWS事業部の採用方針をご紹介します。 AWS事業部の採用方針 AWS事業部の採用方針は以下の3つです。 技術が好きな人を採る クラスメソッドはエンジ

よく訓練されたアップル信者、都元です。「認証 認可」でググると保育園の話が山程出て来ます。が、今日は保育園の話ではありません。そちらを期待した方はごめんなさい。こちらからお帰りください。 さて、先日のDevelopers.IO 2016において、マイクロWebアプリケーションというテーマでお話させて頂きました。一言で言うと OAuth 2.0 と OpenID Connect 1.0 のお話だったのですが、これらを理解するにあたっては「認証」と「認可」をはっきりと別のものとしてクッキリと認識する必要があります。 まず、ざっくりとした理解 認証と認可は密接に絡み合っている一方で全く別の概念です。正直、理解は簡単ではないと思います。 まず「認証」は英語では Authentication と言います。長いので略して AuthN と書いたりすることもあります。意味としては 通信の相手が誰（何）であ