Today we’ve released an initial version of audit-cis. This is an “audit mode only” cookbook that runs on a node to check for compliance with The Center for Internet Security (CIS) benchmark for a specific platform. This release targets CentOS 7, CIS Benchmark version 1.0.0. CIS Benchmarks are consensus based security recommendations for various operating systems, platform distributions, or commonl
対訳表を作るのが面倒 システム設計をする時に、データベース名や変数名や表示名などを決めるのが面倒だ。一般的には英字文字列で作るのだけど、ローマ字で「kokyaku」とか付けるのはダサいし、いちいち辞書を引いていくのは億劫。 多言語対応のために表示名をフランス語にするみたいな要件もでてくるが、これらの作業の下準備を実現する手段として、Google Docsのスプレッドシート(表計算ソフト)の翻訳関数を利用する方法が考えられる。 =IF($A2<>"", GOOGLETRANSLATE($A2,"ja","en"),"") 指定セルの内容を翻訳するには「GOOGLETRANSLATE(値,ソース言語,ターゲット言語)」関数を入力する。例えばセルの計算式に上記式を入力すると「A2セルの内容がある場合にA2セルの値を日本語から英語に翻訳する」という意味になる。 スプレッドシートで多言語対訳表を作る
本稿は System Archaeology Through Testing (2015/05/15) の和訳です。 みなさんご存知の通り、私はChefのAudit Modeを使ってCookbookでCISベンチマーク (訳注:和訳)を実装しました。最近、Ubuntu 14.04に対応しました。本稿では、ベンチマークの推奨を背景とした本質的なOSレベルの設定についての発見と、ユーザがChefを使って改善する方法を共有したいと思います。 Ubuntu 14.04のCISベンチマークの13.7項では次のように述べられています。 解説: システム管理者がユーザのホームディレクトリに安全なパーミッションを設定している限り、ユーザはそれらを容易に上書きできます。 理由: グループまたはあらゆるユーザが書き込み可能なユーザのホームディレクトリは、悪意あるユーザによって他のユーザのデータを盗んだり変更し
Droneが遅いから、dockerのstorage driverを変更して、ざっくりとビルドの速度比較をしてみたdevopsDockerdrone.iodrone やりたいこと、やっていること ossの drone を利用したお手軽なCI環境を構築しようとしています。 droneの中身をちょっと修正したりしながらdroneおよびdockerコンテナ、カスタムイメージまわりの検証を実施しています。 Dockerのヴァージョンをあげると遅くなりました。。 AWS上で作成したubuntu14.04をホストにして単発で動かしたところさくさく動きました。 「おー、速い。」ということで、色気をだして、dockerのversionを1.7にあげたところ、ものすごく遅くなりました。。なぜ。。 ということで、droneのgitterで質問、および、droneの issues #271 を見てみました。 @b
やりたいこと Docker上にMySQL Serverを構築する データは永続化したいためMySQL Serverのコンテナとは別コンテナにする データ保持用のコンテナからバックアップおよびリストアする データ保持用コンテナの作成 参考:Manageing data in containers Dockerの公式サイトのドキュメントには、永続的なデータをコンテナ間で共有したい場合や非永続コンテナから使用したい場合、Data Volume Containerと呼ばれるコンテナを作成し、そこからデータをマウントするのが最善であると記述されています。 このベストプラクティスに従い、MySQL Serverコンテナ用のデータボリュームコンテナを以下の様に作成します。 条件 最低限のOS機能のみ必要なため、ベースとするdockerイメージは busyboxにする MySQL ServerコンテナはM
今シーズンのスノーボード滑走日数がもうすぐ30日になる渡辺です。 社内には雪山部なる活動もあります。 さて、Git, Subversionなどソースコードのバージョン管理システム自体は使う機会が多いかと思います。 しかし、ブランチの運用やリリース管理については知識が曖昧であったり、難しいと敬遠してしまうことも多いところです。 最近は、Gitの普及によってブランチの運用は浸透してきたかもしれません。 ですが、リリース管理については、主にチームリーダーなどがやってしまうために学ぶ機会が少なく、知らない人も多いと思います。 今回はGitのプラグインのひとつであるGit Flowを使って、リリースする作業を解説します。 なお、GUIクライアントのSouceTreeを利用してみます。 リリース前の確認 はじめに全てのコードがdevelopブランチにMergeされているかを確認してください。 Push
渡辺です。 スノーボードでのスピン(回転)では、フロントサイド(前回り)は視界に向けて回るので比較的に簡単です。 ところが、バックサイド(背中周り)は非常に難しいと感じます。 これは見えない方向への回転なので見えないためであり、恐怖心が原因です。 解らないのは怖いことです。 解ってしまえば意外と簡単だったりします。 「幽霊の正体見たり枯れ尾花」とは良く言ったものですね。 Git(バージョン管理)のMergeも同様です。 Mergeの正体を理解し、恐怖心をなくしましょう。 最後の最後は気合いで手動Merge はじめにお断りしますが、Mergeを理解したとしても、手動でMergeする作業がなくなるわけではありません。 そして、手動でMergeするときは、最終的に気合いでMergeする以外の方法はありません(笑) しかし、Mergeを理解しConflict(競合)が発生しにくい運用を行うことで、
渡辺です。 東京では雪が降って騒ぎになっていますが、札幌では雨が降って騒ぎなっています。 これっていわゆる「北から目線」ですが、目線の違いってのは結構大切なことです。 はじめにお断りしておきますが、今回紹介する手法はひとつの運用方法です。 自分はこんなやり方が好きだ/嫌いだといったことを言われても、「そうっすかw」としか言えません。 特にGitを使うと様々なやり方があるでしょう。 それらを否定するつもりも、今回紹介する方法が完璧な方法だとも考えていません。 あくまでGit(バージョン管理)運用手法のひとつとしてご紹介いたします。 マサカリを投げるのは歓迎しますが、好みの押しつけはご遠慮ください(笑) メインBranchへのMerge 安全なMergeを行う開発フローでも解説しましたが、Gitでは各開発者がそれぞれ作成したBranchに変更をCommitし、最後にメインBranchへMerg
6/23(現地時間)に Packer の最新安定版 version 0.8 が公開されました。例によって、日本語参考訳です。内容の把握程度にどうぞ。 原文: Packer 0.8 – HashiCorp https://hashicorp.com/blog/packer-0-8.html ■ Packer 0.8 私達は Packer 0.8 をリリースします。Packer は仮想マシンイメージやコンテナなど、デプロイ可能なアーティファクト(訳者注;成果物の意味、抽象化された仮想イメージに対する呼称)を構築するためのツールです。 Packer 0.7 を公開してからほぼ一年ですが(マイナーリリースはありました)、ようやくメジャーリリースの時だと決めました。Packer 0.8 は非常に大規模なリリースであり、1ダース以上もの新機能を備えています。コミュニティにおいて 100 を越えるプルリ
■ Docker Machine とは? Docker Machine は、Docker Engine( docker デーモン等)をコンピュータ上や仮想マシン、クラウド・プロバイダなどに自動的に展開・設定する(プロビジョニングの)ためのツールです。オープンソース・プロジェクトとしてDocker 社とコミュニティによって開発が進められています。 概要については、以前 SlideShare にアップロード(第11回クラウドごった煮コンテナ勉強会)した資料がありますので、こちらも併せてご覧ください。 具体的には下図のようなイメージです。「docker-machine」コマンドが、VirtualBoxだけでなく、Amazon Web Services や DigitalOcean など、リモート上のクラウドサービスと接続して、Docker がすぐに利用できる環境を作ります。 Docker Mac
はじめに 最近ではInfrastracutre as codeやImmutable Infrastructreの考え方によるインフラ管理が浸透してきました。 ChefやAnsibl、最近ではItamaeといったプロビジョニングツールの選択肢が増えてきとはいえ、未だに敷居の高さを感じ導入に踏み切れていない方も多いのではないでしょうか。 そこで今回はお手軽に始められるインフラ構築ツールとしてconfdについてまとめてみました。 confdとは goで書かれた設定ファイル管理ツールです。 kelseyhightower/confd 主要機能は設定ファイルのテンプレートエンジンなのですが、設定ファイルの生成前後で外部コマンドを実行することが可能です。 そのため 設定反映のための前処理 設定ファイルの自動生成 設定反映のためプロセス再起動 といった一連の作業を担わせることができます。 また、構成もシ
chef-clientでnodejsをインストールするときに「gpg: keyserver timed out」エラーが発生するNode.jschef ================================================================================ Error executing action `add` on resource 'apt_repository[node.js]' ================================================================================ Mixlib::ShellOut::ShellCommandFailed ------------------------------------ execute[install-key 1
About 何らかの理由で公開鍵が登録されておらず、パスワード認証でcookしないといけない場合の対応です。 Environment ローカルマシン --- 踏み台 --- 対象ホスト ※ 全てパスワード認証 対応前 chefでcookする際に何度もパスワードを聞かれてしまいました。 dev@192.168.1.2's password: dev@10.0.0.2's password: Uploading the kitchen... dev@192.168.1.2's password: dev@10.0.0.2's password: Killed by signal 1. dev@192.168.1.2's password: dev@10.0.0.2's password: Killed by signal 1. dev@192.168.1.2's password: dev@1
よく訓練されたアップル信者、都元です。jqというツールはご存知でしょうか。ご存じない方は、まずはこの辺りのエントリーを御覧ください。 jqで簡単JSON加工 軽量JSONパーサー『jq』のドキュメント:『jq Manual』をざっくり日本語訳してみました jqは要するに、入力したJSONに何らかの加工をして、その結果のJSONを出力するツールです。どのような加工をするのかを指定するためのクエリ言語があり、それを解釈して実行する役割を持っています。 AWSをはじめとして、各種Web APIのレスポンスはJSONで取り扱うことが多く、そのJSONから欲しい情報のみをリストアップしたい、というニーズは常に存在します。 例えば aws ec2 describe-instances コマンドを使えば、全てのEC2インスタンスの情報が一度に取れます。筆者が扱うとある環境でコマンドを実行してみたところ、
2014/06/24 に Opscode 公式ブログで From Solo to Zero: Migrating to Chef Client Local Mode という記事が公開されました。記事を要約すると「Chef Solo はオワコンだから Chef Client Local Mode を使え」ということのようです。 Chef Client Local Mode (旧 Chef Zero) って? Chef Client Local Mode (旧 Chef Zero) は Chef Solo の全ての機能を備えており、Chef Server に移行する際にも楽です。Chef Client 11.8.0 から採用されました。実行するには chef-client に --local-mode または -z オプションを付けます。 Local Mode ではローカルのファイルシステムか
本稿は Overview of Test Driven Infrastructure with Chef (2015/04/21) の和訳です。また、長文のため、独自に目次をつけました。 Chefによる開発フェイズ 収束前 収束 収束後 テストの種類 ユニットテスト インテグレーションテスト よく使われるChefのテストツール RuboCop Foodcritic ChefSpec Serverspec Chef Audit Mode Test Kitchen サポートツールと、依存関係にあるソフトウェア RakeとThor Guard RSpec Fauxhai Busser あまり使われないか、非推奨のツール Cucumber BATS minitest minitest-chef-handler この記事はChefによるテスト駆動インフラに関するすべてです。現時点でのChef Coo
$ vagrant up Bringing machine 'default' up with 'virtualbox' provider... ==> default: Importing base box 'opscode-ubuntu-14.04'... .... SSH address: 127.0.0.1:2201 ... $ knife zero bootstrap 127.0.0.1 --ssh-port 2201 --ssh-user vagrant --node-name test -i ./.vagrant/machines/default/virtualbox/private_key --sudo Doing old-style registration with the validation key at ... Delete your validation key
はじめに ChefのCookbookを作成するにあたって,スケーラブルやメンテンナス性といった観点からどんなCookbookを作成すればいいか悩むことがある. これの解決策として,The Environment Cookbook PatternにしたがってCookbookを作成する方法があります. この記事の和訳やより詳しくかかれているのに以下があります. 大規模にchefを使い倒すためのcookbook pattern Chef Cookbook の管理方針、The Environment Cookbook Pattern について そしてすごくありがたいことに,2つ目の記事のなかに実際のCookbooksのStructureに関する件まで載せてくださっていました. environment-cookbook |_ .chef |_ knife.rb |_ cookbooks |_ env
最近インフラの自動化に、興味がありいろいろ試行錯誤しているが、結局どういうソリューションがいいのかよく分からないので、ちょっと今考えていることを書きなぐる やりたいこと OSをインストールして、インストール後のミドルウェア設定までを完全自動でやりたい 今回は、下記ツールを使う Cobbler = OSインストール Chef = ミドルウェア設定 ソリューション1 「Preseedのlate_commnadでchefの設定/rc.localにchef実行スクリプトを仕込む」 実現に向けた事前準備 chef-serverのnodeをあらかじめ作成しておく必要がある nodeのpermissionに気をつける(clientにwrite権限を付与) --考察-- OSインストールからミドルウェアの適用まで、インストール対象サーバが自立的に行う。 また、サーバのあるべき姿をChefサーバ上に持ってお
この投稿は私がCentOS6.6の環境を構築する時に色々調べたりしたことをまとめたものです。 (2015年6月17日現在) Chefを使って環境を整えたい、VPS契約したけど初期設定めんどくさいという人が対象です。 読者が30分以内ですぐに開発に取り掛かれるようになることがゴールです。 やること セキュリティ関連のセットアップ(開発ユーザー作成、sudo権限付与、rootログインできないようにする、パスワードログインできないようにする、iptablesを設定) nginxを入れる(バージョン:1.9.2) DB(MySQL)を入れる(5.6) Ruby(rbenv:2.2.2), Go(1.4)を入れる せっかちな方のために Gitで公開しているので、cloneしたら後はコマンド一発です。 https://github.com/Islands5/vps_settings.git 最低限やる
2014/07/17追記 この方法だとcentosが起動しなくなりました。なので、実施しないでください。原因は調査中です。 基本中の基本かもしれないけど、地味にやっていなかったのでlinuxの作業ログを起動時から全部取得するのをやっておく。 $ mkdir -p /usr/local/dev/script_log $ chmod 777 /usr/local/dev/script_log $ sudo su $ vi /etc/rc.local #!/bin/sh # # This script will be executed *after* all the other init scripts. # You can put your own initialization stuff in here if you don't # want to do the full Sys V sty
SpreadSheetで、セルとか行を引数にとって何か実行して返すような関数をApps Scriptで書いた場合、どうやってその関数をデバッグするのかさっぱりわからない。 例えばこういう引数をとらない関数だったら、関数実行するボタン押せば実行されてログが表示される。 function printProductInfo() { var sheet = SpreadsheetApp.getActiveSheet(); var data = sheet.getDataRange().getValues(); for (var i = 0; i < data.length; i++) { Logger.log("Product name: " + data[i][0]); Logger.log("Product number: " + data[i][1]); } }
OSの操作ログを取得したい(しなければならない)という要求は、まぁけっこうあるだろう*1。 セキュアOSではない従来のLinuxの機能で、比較的容易に実現可能な典型的な方式として、(1) scriptコマンド、(2) sudoコマンド、(3) acctコマンドを用いる3通りがある。この解説は、次の記事がいけてる。 http://www.atmarkit.co.jp/fsecurity/rensai/unix_sec06/unix_sec02.html いずれも、特権ユーザのログを厳密に取得するものではないが、お手軽なので(感覚的には)けっこう使われているのではないかと思う。 で、ただ今、基盤チームのスミッコメンバなので、めでたく初実装することになった。今回は、シェルの起動時にscriptコマンドを実行することで*2、操作ログを自動的に取得することに。 どこにscriptコマンドを記載すれば
はじめに Linuxサーバ上で直接SSHで作業をする際に、その作業ログを取得する方法についてまとめてみます。 スクリプトを自前で書く、専用のツールを利用するなど様々な方法が考えられますが、ここではLinuxの標準的なコマンドでの作業ログ取得について記載します。 今回は以下のコマンドを利用します。 history script 各コマンドの基本的な使い方や、覚えておくと役に立つちょっとした設定方法、最後に自動で作業ログを取得する方法について記載しました。 history 現在の作業ユーザがコマンドライン上で実行したコマンド履歴を表示するコマンドです。 $ history 1 ls 2 env 3 history 4 ls -la 5 ls -la 6 vim .bashrc 7 zsh 8 exit 9 lsblk 10 hostname …
実践編はこちらです。 新米エンジニア(アプリ・インフラエンジニア問わず)に知っておいてほしいトラブルシューティング入門 実践編 6/24追記:本記事中にも記載した操作ログの取得方法について、入門記事を作成しました。 Linuxサーバでカジュアルに作業ログを取得する はじめに 今の時期、多くの企業では新卒入社向けの新人研修真っ最中であるところが多いかと思います。 弊社も新人研修の真っただ中でして、私も新人向けに主にインフラ周りの講義や研修サポートを実施しています。 その中で最も質問の多い内容が 「~に接続できないのですが、、」 「○○を見ながら設定したのですが起動しません、、」 「自分のノートPCだと動いていたのですがサーバ上だと動かなくて、、、」 といった「○○できないのですが、どうしたらよいでしょうか」といったものでした。 入社当初は自分もこんな感じだったなーと思いながらも、質問を受ける
※前回記事にてトラブルシューティング実施にあたって準備しておきたいこと(作業ログの取得方法など)を記載しておりますので、本記事では割愛します。 はじめに 前回の記事の続きとなります。 新米エンジニア(アプリ・インフラエンジニア問わず)に知っておいてほしいトラブルシューティング入門 はじめの一歩編 前回に記事を書いたあと、現場でも意外と基礎を押さえた切り分けができない人が多いのではと思い、よりいろんな方に読んでいただきたくタイトルをかえてみました。 前回の記事では、トラブルシューティングの前に実施しておきたい事や心構えについて記載しました。 今回はそれを受けて実際にトラブルが起きた際の簡易的な切り分け方法についてまとめてみます。 本記事の対象と扱う範囲 前回記事と同様に、初めてエンジニアとして働くことになった方々向けです。 本記事のゴールが「○○できないですのですが、、」といった事象に対して
Talk that I gave at #dockercon 2015. Video is at https://www.youtube.com/watch?v=sYQ8j02wbCYRead less
printfは複雑な挙動をするので信頼できないことが多い。おいつめられると以下のようなものをprintfがわりに使う。 デバッグwhile(1) コードが止まるかどうかを判定することでフローを確認する。マシン語数命令で完結するのでかなり信頼できる。OS無し環境でも使えるのが嬉しい。Windows環境下ではプログラムを終了させるのが面倒。副作用が無いので時間かかっているだけなのか判定できない。 デバッグ *(int*)0 = 0; (デバッグSEGV) プログラムが終了するかどうかを判定してフローを確認する。さらにcoreを吐かせたり、JITデバッグしたりしやすい。ライブラリを必要としないので、abortよりも信頼できるしバックトレースもきれいに出る。が、Windows GUIはたまに例外を握り潰してることがある気がする(やめてくれ) デバッグexit(1) プログラムが終了するかどうかでフ
弊社でChatWorkを利用していることは何度か紹介していますが、最近特定のGmailについてChatWorkにメッセージ投稿をしたいというケースがありました。そこでGoogle Apps Script(以下GAS)を利用してChatWork APIを操作したので、そのコードスニペットについてご紹介します。 function postMessageToRoom(token, roomId, message) { var params = { headers : { "X-ChatWorkToken" : token }, method : "post", payload : { body : message } }; var url = "https://api.chatwork.com/v1/rooms/" + roomId + "/messages"; var result = Url
これはだいぶ前に書いたエントリです。MINCS作者による最新の解説があるのでそちらもご覧ください。 (2016-11-21追記) コンテナは使いたいけど、たくさんコンテナを起動すると結局それぞれのコンテナに対するセキュリティアップデートなどのメンテナンスは必要だし、コンテナ内独自のプログラムやライブラリ以外はホストと共有したいよね、って話が出てきたりします。みんな考えることは同じで、bind mount を使えば良いよね、って話はでてきてました。 こないだもブログで紹介した kazuho さんの jailing 私が LXC でも結構簡単にできるよ、っていう提案を兼ねて作った lxc-bind こないだのLinuxConでもDockerでたくさんのオプションを並べて、色々工夫して bind mount を使ってやってる発表もありました (Using Docker for existing
EclipseのAWS Toolkitを利用するとLambdaのプロジェクト生成時にJUnitなどのテストも入っていて便利なのですが、Eclipseだけでビルドできる状態だとCIなどやりにくいのでGradleでビルドできるようにしてみたのでその時のメモを記載します。(Eclipse以外でもビルドできるのかもしれませんが...) とりあえず使いたい プロジェクトは以下にあるのでご利用ください。 LambdaGradle 上記をcloneして環境変数JAVA_HOMEにJava8が指定された状態で とすることとでビルド、テスト、Lambda用のjarファイルが生成されるかと思います。gradlewを使っているのでGradle自体のインストールを事前に行っていなくてもビルドが可能です。Lambda用のjarファイルはbuild/libs/LambdaGradle-0.0.1-SNAPSHOT.j
初めに MongoDBで追加したRecordにTTLを設定したい場合には、expireAfterSecondsのOptionでIndexを作ってあげると良いのですが、nodeからmongoを操作する時に(一部ハマったのと)ずばり参考になるCodeが無かったので、ご参考までにCodeをチラシの裏しておきます。 nodeからMongoDBへのアクセスは、mongodbを使っています(mongooseでは無いです) node上でSchedule jobを動かすのにnode-scheduleを使っています。npm install node-schedule --save-devとかで入れておいて下さい Node Sample Code Sample codeのnodeの処理内容は、以下の2つです。1分毎にmongoに追加されるRecordのTTLは90秒なので、2分後には消えている事が確認できます
過去に 書籍「実践SeleniumWebDriver」のPageObjectパターンをRSpecでテストコードにしてみた。 で「写経」はしてみたのですが、いよいよ実戦で使う時が来たのでこれを思い出す意味で書いていこうと思います。(前任者が残してくれたコード、資料があったのでここまでできるようになりました) 前提 SeleniumWebDriverとRubyとRSpecはそこそこわかる PageObjectデザインパターンもそこそこわかる これについては前任者が書いてくれた「Selenium2でつくるテストケースの構成について」 がものすごくわかりやすいです。 環境は諸事情によりWindows8.1 (多分Linuxでも同じことができるハズ)ブラウザが立ち上がるのでGUIがあったほうがいいです。 headlessでもできるみたいです 「Seleniumをブラウザなしで起動するための方法を調べ
Selenium談話会 in Slackとは 私、@oh_rusty_nail が主催しているSlackを使ったオンライン勉強会です https://seleniumjp.slack.com 地方に住んでいて勉強会に行くのも遠征しないときびしい!といった方には特におすすめです 月1回程度の頻度で計画しています 日本Seleniumユーザーコミュニティで開催の案内を出しています 2015/06/19現在の登録ユーザ数:35名 参加方法 以下どれからも可能です https://seleniumjp.herokuapp.com から登録してください TwitterID: @oh_rusty_nail をフォロー後にDMで受信可能なメールアドレスをお知らせください takonoyawarakaage@gmail.com宛に受信可能なメールアドレスをお知らせください 前回のまとめ 「第1回Selen
アナウンス Selenium 談話会 in Slack まだまだ活動続けています!!(2019/09/09追記) https://selenium-danwakai.connpass.com/ でアナウンスを出しています。 2015/春から「Selenium 談話会 in Slack」というものをはじめました Slack(チャット)を使って日々の困りごとなどを同士とリアルタイムで情報交換することができます 登録されたユーザは2015/06/25時点で35名 => 2019/09/09時点で596名 半年に1回程度でチャット上に集まってテーマを決めて話をしています Ex) 「第3回Selenium談話会 in Slack」 のまとめ 詳細、参加方法などは上記リンク先に書いています 2018/09/18時点で13回開催しています。ご興味のある方はお気軽にご参加ください https://sele
注意 React Router v0.13.3 時点の情報です。 多分今だと動かないです。 key の設定方法で嵌ったのでメモ。 デモ https://jsfiddle.net/mota2/ec5cfb16/3/ ポイント RouteHandler を CSSTransitionGroup で囲う RouteHandler の key に pathname を指定する CSSTransitionGroup は直下の要素の key の変化をトリガーにアニメーションするので、遷移前と後で異なる値を設定する必要がある。 Route のパスがちょうどいいので、ReactRouter.State mixin の getPathname の値を key に使う。 ソース App の中に Main を表示し、Main -> Sub に遷移させる。 var {CSSTransitionGroup} = R
はじめに 先日のブログでも書きましたが、電子書籍「Everyday Rails - RSpecによるRailsテスト入門」の追加コンテンツとして「Minitest版のテストコードとその解説書」を書いています。 執筆はまだ完全に終わっていませんが、キリのいいところまで書き終えたのでいったんベータ版としてリリースすることにしました。 追加コンテンツのタイトルは「RSpecユーザのためのMinitestチュートリアル」です。 今回のエントリではこの書籍の内容について紹介します。 2015.7.29 追記:正式版を公開しました! 2015年7月29日に正式版を公開しました。 詳しい内容は以下のエントリで紹介していますのでこちらも併せてご覧ください。 blog.jnito.com 「RSpecユーザのためのMinitestチュートリアル」 「RSpecユーザのためのMinitestチュートリアル」の
『Stuff Goes Bad: Erlang in Anger』は『すごいErlangゆかいに学ぼう』の原著者のFred Hebertさんが書いた本。 ライセンスはCC BY-NC-SA 4.0でオンラインでPDFとして公開されている。 Erlang/OTPで構築したシステムの運用や調査に役立つ情報が色々と書かれている割には、周りで読んだことのある人が少なさそうだったので、ここで紹介してみた。 当初は要約的なものを書こうかと思っていたが、ここに書くには分量が多くなり過ぎてしまいそうだったのと、PDF自体が100ページにも満たなく内容も分かりやすいと思うので、興味のある人は冒頭のリンク先のPDFを直接読んで貰えればと思う。 (そのためこの記事自体にはほとんど有益な情報はない...) 内容的には、実システムの運用時に発生するであろう問題に対処/調査するための方法や知見がかなり網羅的に書かれて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く