Bash Infinity よりずっと前に Bash on Rails なるものを作った人がいると記録しておく
備忘録を兼ねて、ブログを書いておきます。
きっかけは、昨日のはてブでホットエントリに上がっていた下の記事です。
元記事から、GitHub のソースコードにたどりついて、少しだけ内部のコードを読みました。
https://github.com/niieani/bash-oo-framework
どうも、Pure Bash で書かれているようですね。
OO という名前が現すように、オブジェクト指向で書けるように型システムをも実装しているようです。と、これは記事でも紹介されていましたが。
さて、この記事を読む数カ月前に、私は Bash on Rails なるものを作っていた人を知ったので、それを想起しました。
Bash on Rails は @emasaka さんが作った Rails モドキで、「Bash の機能だけでいかに Ruby on Rails っぽいことができるか」を実践したパロディ企画とのことです。
作者のブログ でのべ14記事にわたって紹介されています。
関係する記事の一覧は、下記の検索結果からが見やすいです。
http://emasaka.blog65.fc2.com/blog-entry-379.html?q=bash+on+rails
Bash Infinity 同様、Pure Bash かつ OO で書かれており、Rails の scaffold や db:migrate を模した機能もあります。
他に、ERB を模した eBash が実装されてたり、model や controller があったりと、まるで Ruby on Rails です。
ジョークソフトにしては力が入りすぎているような気さえします(笑)
(※もちろん、本家 Rails に有って Bash on Rails にない機能はたくさんあるでしょうけど)
ブログ記事の中で、コアの部分で面白そうな記事を1つだけ挙げるとしたら、本を読む Bash on Railsを作る(10) bashOOをbashOOで作る を推します。
オブジェクト指向をどうやって実現しているか、コードを混じえて紹介されています。
この記事だけでも一見の価値はあるかな、と。
GitHub 上では shails という名前でソースコードが公開されています。
https://github.com/emasaka/shails
Bash on Rails を初めて見つけたときは、「Bash ってここまでできるのか」と感動したものです。
そこまでやる必要があるのかはさておき。
ご興味がある方は、ソースコードや記事を読んでいただくと面白いと思います。
Bash on Rails と Bash Infinity の「実用性」について
Bash on Rails はそもそもジョークプロダクトで、まともな用途で使わないでね、とブログで書かれています。
こちらも内部のコードを少し追いましたが、eval など駆使して無理やりオブジェクト指向っぽく見せているような感はありました。
あくまでオブジェクト指向を「模している」だけなので、違うものだという前提を持った方がいいでしょう。
Bash Infinity は実用的なプロダクトを目指しているのかな？ と思わせる雰囲気で、 GitHub 上でかなりスターもついてます。(昨日は1000弱でしたが、さっき見たら1000を超えていました。)
…が、どのくらい実用的なのかは疑問符です。テストライブラリは付属しているそうですが、Bash Infinity 自体のテストコードが見当たらないような…。。
最初に挙げた記事に書かれていたように、「各ライブラリでどのようなテクニックが使われているか」の勉強にはよさそうだな、と思いました。
余談
@emasaka さんのブログをあさっていたら、sinatra モドキも作っていたことを知りました(笑)
以下は、記事から引用:
「…"sh inatra"って言いたかっただけと違うか？」と思ったあなた、はい、そのとおりです。
Googleサイト上の個人WikiでMarkdown Hereを使うことにした
気づけば１ヶ月以上ブログの更新が滞っていたようです(汗)
いくつか小ネタが溜まっているので、隙を見て消化していきたいと思っています。
さて、半年ほど前に、日々の個人的な雑メモは こちらの Google サイト に書くことにしました。
その経緯については、下の記事でかんたんに紹介しています。
Google サイトは手軽にページ階層が編集できるなど、個人 Wiki として便利である一方で、 Markdown に対応していないというのが、そこそこ大きなペインポイントでした。
が、１ヶ月ほど前に何か手段はないかともう一度探してみたところ、 Markdown Here を見つけることができました。
2010年のStackExchangeで。GoogleSiteでMarkdownで書くのに、MarkdownHereがオススメされてる。https://t.co/6ZqMWgo2ab
— きいあむ → @progrhyme (@key_amb) 2016年6月19日
で、試してみて、非常に満足したので、それからこれを使っています。
以下、Markdown Here について簡単に紹介します。
Markdown Here の使い方
- Markdown で記事の原稿を書く。
- ホットキー(デフォルトは
Ctrl + Alt + M)を入力すると、HTMLにレンダリングされる。- もう一度ホットキーを入力すると Markdown テキストに戻る。
自分は Firefox か Chrome を常用していますが、どちらもデフォルトのホットキーのまま使っています。
また、オプションでシンタックスハイライトのスタイルで使われている highlight.js のスタイルを変更することができます。
自分は Tommorow Night Bright にしました。
Markdown Here の他のブラウザやメーラへのインストール方法については、公式サイトをご覧ください。
余談ですが、 Markdown Here は Google サイトだけでなく、 Gmail や Blogger など他の Google サービスでも使えます。
更には、 Facebook や Tumblr, Evernote でも動作するようです。
詳しくは Compatibility · adam-p/markdown-here Wiki · GitHub をご覧ください。*1
見た目はどんな風になるの？
Google サイトのこのページ で、 Markdown-Cheatsheet のソーステキストを入力して、 Markdown Here でレンダリングしてみました。
だいたい、いい感じになっていると思います。
ご興味のある方は、ぜひご覧ください。
終わりに
Google サイトを Markdown で書けるようになる Markdown Here を紹介しました。
Gmail 等でも使えますので、機会がありましたら試してみてはいかがでしょうか。
#PrometheusCasual #1 に行ってきた
発表資料
@wyukawa Hadoop, Fluentd cluster monitoring with Prometheus and Grafana
@mtanda Prometheus on AWS
@tokuhirom promgen - prometheus management tool
promgen - prometheus managemnet tool / simpleclient_java hacks @ Prometheus casual from Tokuhiro Matsuno
kawamuray HBase, Kafka cluster monitoring with Prometheus and Grafana
@moznion 5分で作るprometheus exporter
なお先程のライブコーディングのカンペはこちらになります https://t.co/4sep5VgvmH #prometheuscasual
— 好評分譲中 (@moznion) 2016年6月14日
Togetter まとめ
メモ
- Prometheus の特徴
- アーキテクチャ - https://prometheus.io/docs/introduction/overview/#architecture
- Pull 型
- Prometheus は監視ノードの HTTP インタフェース(Exporter)を叩いてデータを取得
- pushgateway を使うと push 型もできる
- アドホックタスクの監視に使っている @kawamuray
- 監視対象に Exporter を仕込む方法:
- 1) 監視対象自体に HTTP エンドポイントを持たせる
- 2) 独立した Exporter プロセスを動かす
- データを演算できる。クエリが書ける
- PromQL
- Local の TimeZone 使えない
- @kawamuray「彼らは local time に猛烈な嫌悪感を持っている」
- Exporter を作る
- Prometheus の運用について
- 楽でほぼ手間はないらしい @mtanda
- バージョンアップ時に非互換の変更があると、設定を書き換えないといけなかったり
- ディスクをかなり使う @mtanda
- 1ノード 150 メトリクスで1ヶ月あたり 200MB とか
- YAML 管理がつらい
- Exporter の管理など
- Solution:
- Service Discovery
- EC2, Consul, k8s などと連携して監視対象リストを自動更新
- ★ @mtanda 氏の資料
- promgen by @tokuhirom
- Service Discovery
- 設定
- データの保持期間がデフォルト15日
- storage.local.memory-chunks デフォルト 1MB
- 変える場合、max-chunks-to-persist も合わせて変更しないといけない。罠い。
- 楽でほぼ手間はないらしい @mtanda
- データを長期保存する工夫 @mtanda
- Prometheus を2台用意
- 片方で 1時間ごとにデータをサマライズしている
所感
- 勉強会
- 出席率よかった。次世代監視ツールとして、注目度が高い雰囲気
- Prometheus 手元でちょっと動かしたぐらいでほとんど情報がなかったので、ユーザ事例をたくさん聞けてよかった
- Prometheus
- 他
- promgen は公開予定はあるのだろうか？
ありがとうございました。
6/8 appengine ja night #33 に行ってきた #gcpja
後でブログ書こうと思って、土日にも書くのを忘れていた(汗)のですが、珍しく早起きして思い出したので、今更ブログを書いています。。
というわけで、掲題の通り、6/8 に appengine ja night #33 に行ってきました。
ご存知、GAE こと Google App Engine のユーザ向けイベントですね。
さて、今年はよく GAE の話題を見聞きするように思います。
今回も発表されていたメルカリアッテで採用されたという件と、GCP の年内東京リージョン開設が発表されたことがインパクトが大きかったですかね。
今回の発表資料(の一部)は Connpass の資料一覧ページ に上がっておりますので、そちらをご覧ください。
印象に残ったこと
「メルカリ アッテ」の発表
事前に 4/23 Go Conference の発表資料を見ていたこともあり、個人的に一番注目度が高い発表でした。
正確な月次コストについての言明は避けられましたが、DAU 100万あたり 200万円と、かなり具体的な数字が述べられました。
コスト試算するにあたって参考になりそうです。
また、GAE の費用内訳の紹介もありました。(詳しくは資料をご覧ください)
Standard Environment が強い
Standard Environment と Flexible Environment については公式の Google App Engine ドキュメントをご覧ください。
今回のイベントでは、Standard Environment 対応言語の中でも、Go 言語推しの方々が目立ったと思います。メルカリアッテさんも Go。
「メルカリ アッテ」の発表でも述べられていたように、急激なトラフィック変動にもロスなくシームレスにスケールできるのは、Standard Environment + Go言語の力によるところがあるようです。
逆に言うと、Flexible Environment だとインスタンスの起動が遅い(下の参考記事によれば分単位)ので、そこまで瞬間的にスケールはできないのだろうと思われます。
例えば、3月に GAE 対応が発表された Ruby や Node.js は Flexible Environment なので、これらの言語での GAE 利用を検討する場合、この点は念頭に置いておいた方がよさそうです。
この辺り、最近下の記事を読んで、参考になりました。
LT: a2cさん「GAEレスポンスの1桁ms化」
今の GAE は海外にしか拠点がなく、RTT が 300ms 以上はかかるので、それを短縮しましょうという話。
このトークでは CDN の Fastly を使って高速化した事例が紹介されました。
メモ:
- Fastly について:
- XHR のプリフライトリクエストをスキップできる
- 全てのログを即時に取得可能
- CDN なのに演算できる
- パージなど API の使い勝手がよさそう
- 価格についてはボリュームディスカウントが効く。詳しくは Fastly の営業さんに聞いて下さい、と。
その他
他にも色々おもしろい話があったので、興味があれば Togetter など見てみるとよいかもです。
所感
運用のないインフラは、インフラの理想だと思います。
GAE は、特有の制約も色々とあるようですが、レイテンシ要求の厳しくない、RDB を使わなくていいサービスであれば、有力な候補になりそうです。
なんとなく、今後スタートアップなどでの採用も増えそうだなと思いました。
Ubuntu + xkb で JISキーボードのキー配置入れ替え
はじめに
仕事で使っている Mac は、昔USキーボードがかっこいいと思っていた頃にUSキーボードにしたままなのですが、家ではJIS配置のキーボードを使っています。
JIS配置の場合、「変換」「無変換」キーが余ること、「半角/全角」「Esc」キーが遠いことから、昔から以下のように入れ替えて使っています。
- 「変換」 ⇔ 「半角/全角」
- 「無変換」 ⇔ 「Esc」
…で、最近 Ubuntu 16.04 LTS でこれのやり方を調べてやってみたので、本記事にメモしておきます。
TL;DR
xkb の設定ファイル /usr/share/X11/xkb/symbols/inet を以下のように直接編集しました。
// Evdev Standardized Keycodes
partial alphanumeric_keys
xkb_symbols "evdev" {
:
- key <HENK> { [ Henkan ] };
- key <MUHE> { [ Muhenkan ] };
+ //key <HENK> { [ Henkan ] };
+ //key <MUHE> { [ Muhenkan ] };
+ key <HENK> { [ Zenkaku_Hankaku ] };
+ key <MUHE> { [ Escape ] };
+ key <ESC> { [ Muhenkan ] };
+ key <TLDE> { [ Henkan ] };
:
ざっくり解説
xkbは X Window System の一部で、キーボードを制御するもののようです。
この xkb の設定は下のコマンドで確認することができます。
setxkbmap -print
自分の環境では次の出力が得られました。
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include "pc+jp+us:2+inet(evdev)" };
xkb_geometry { include "pc(pc105)" };
};
設定ファイル /usr/share/X11/xkb/symbols/inet は xkb_symbols の行で読み込まれています。
これには、キーボードのシンボル(キーに対するエイリアスのようなものと理解している)とその振る舞いの対応が記述されているようです。
そのマッピングを上のように書き換えた、というわけです。
なぜグローバルな設定ファイルを書き換えたか
後掲する参考記事では ~/.xkb/symbols/ 以下に独自のキーシンボル設定ファイルを作り、xkb_symbols のブロックで include するやり方が記載されています。
自分も最初、それでやろうと思ったのですが、入力モードを 日本語 ⇔ 英語 と切り替えると、設定がリセットされてしまうようで、しばらくこれにハマりました。
おそらく、xkb のグローバルな設定で、 xkb_symbols が再読み込みされるのだろうと想像しました。
その設定をログインユーザについて書き換える方がベターと思いますが、そこまで調べずに今回はこういうやり方にしてしまいました。
入力モードの切り替えは「Ctrl + Space」でもできる
冒頭で「半角/全角」キーが遠いと述べましたが、入力モードのトグルだけであれば、「Ctrl + Space」でもできます。
これは下の記事にある Fcitx の機能で、Ubuntu 16.04 LTS では、最初から有効になっているようでした。
また、下の記事もこの Fcitx の機能を使った Tips のようです。
