Sinatra の configure で書く必要がないかも知れない項目
小さい規模で WEB Application を書く場合において、Sinatra はサイコーに便利です。
ビューのあるアプリの場合はだいたいこういうディレクトリ構成にしますよね。
$ tree ore_tachi_no
ore_tachi_no
├── config.ru
├── lib
│ └── ore_tachi_no
│ └── application.rb
├── public
│ ├── css
│ │ └── application.min.css
│ └── js
│ └── application.min.js
└── views
├── index.slim
└── layout.slim
6 directories, 6 files
application.rb の内容
/ へのアクセスで index.slim を表示させるだけのカンタンなアプリですね。
require 'sinatra/base' require 'slim' module OreTachiNo class Application < Sinatra::Base configure do app_root = File.dirname(__FILE__) + '/../..' set :public_folder, app_root + '/public' set :views, app_root + '/views' end get '/' do slim :index end end end
Sinatra をお使いの皆さんにおかれましては、こいつの configure に違和感を覚えませんか？
application.rb の内容(改)
実は余計な記述がありました。
ので削ります。こうなりました。
require 'sinatra/base' require 'slim' module OreTachiNo class Application < Sinatra::Base configure do set :root, File.dirname(__FILE__) + '/../..' end get '/' do slim :index end end end
わがままなあなたのために diff を貼りますね。
diff --git a/lib/ore_tachi_no/application.rb b/lib/ore_tachi_no/application.rb index 28852eb..bf9ca17 100644 --- a/lib/ore_tachi_no/application.rb +++ b/lib/ore_tachi_no/application.rb @@ -4,9 +4,7 @@ require 'slim' module OreTachiNo class Application < Sinatra::Base configure do - app_root = File.dirname(__FILE__) + '/../..' - set :public_folder, app_root + '/public' - set :views, app_root + '/views' + set :root, File.dirname(__FILE__) + '/../..' end get '/' do
どういうこと？
set :root, [directory path] が設定されていない場合は、configure の記述があるファイルのディレクトリをルートディレクトリとして扱います。
ルートディレクトリは、settings.root で参照出来ます。
そして、Sinatra の設定の views, public_folder はそれぞれ settings.root + '/views', settings.root + '/public' がデフォルトです。
それぞれ settings.views, settings.public_folder で参照出来ます。
つまり、
- アプリケーションのトップレベルのディレクトリに、
views,publicという名前でテンプレートと静的ファイルを設置する場合は、set :rootでディレクトリを設定しておくだけでいい settings.root直下 以外に置く場合や、views,public以外の名称のディレクトリに設置したい場合はこの限りではない
ということです。
ドキュメント読もう
Pingdomで外形監視
3号です。3番目に書くので3号になってしまいました。外形監視についてゆるく書きます。
私の会社では外形監視にPingdom - Website Monitoringを利用しています。Pingdomは世界中の拠点から対象のエンドポイント(http(s), smtp, DNSなど)の死活監視をしてくれるサービスで、比較的簡単な設定でエンドポイントの監視が実現できます。SaaS/PaaS/IaaSをうまく活用するのが最近のトレンドであることもあり、Slackなど他サービスとのインテグレーションにも優れています。
主に以下のようなものを監視しています。
- HTTP(S)：自社サービスのエンドポイント
- HTTP(S)：他社の連携先のAPIエンドポイント
- HTTP(S)：社内システムのエンドポイント
- SMTP：AWS SES
- Name Resolve：AWS Route 53
自社のサービスはもちろん、連携先のシステムの死活監視もPingdomで行っていて、重要度に応じてPingdomからSlack/メール/PagerDuty(※)と通知する仕組みにしています。 なお、現時点ではPingdomはDNSの監視としてCNAMEの正当性の確認はできないようです。AレコードのIPが正しいこと、のみ。
※ PagerDutyはアラート時に電話をかけてくれるサービスです。インシデント発生時にサンフランシスコから国際電話がかかってきますw 平日日中帯はslack、夜、休日はPagerDutyで電話、という工夫をしています。
rpmのconfigfilesクエリ
2号です。1号挨拶しか書いてないやんけ…!
飲み会であった話でtd-agentのインストール云々があったのでそこから派生してrpmの話。
パッケージの同梱される設定ファイルのみをリストする術。既にインストールされているものなら
rpm -qc {パッケージ名}
これからインストールされる中身が知りたいなら
rpm -qp --configfiles {rpmパッケージ}
な感じです。オプションがショートが-cでロングが--configfiles。
えーと何だったけかなあの話。具体的には
- td-agent2から/opt/以下にまるっと環境を放り込むようになっている
のだけれど、その兼ね合いで
- RPMで管理する%filesセクションも変更になっていて同一のファイルとみなされず、パッケージreplaceの際に設定ファイルがtd-agentのアンインストール処理で消えてしまう
という話だった多分。
