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 のようです。
参考記事
"clenv" というシェルスクリプトのパッケージ管理ツールのようなものを作った
主に先月、開発していました。
いまバージョンは 0.1.12 です。
最近、久しぶりにやりかけだった機能拡張を進めようかと思ったのですが、拡張した機能を今後、自分自身でもあまり使うイメージが持てなくて、現状をひとまずこの記事にまとめておくことにしました。
目次:
- clenv とは
- clam モジュール
- clam を使う前に 〜 clenv セットアップ
- その他便利かもしれない使い方
- clenv を作ってよかったこと
- あれ、シェルスクリプトあんまり関係ない…？
- 他に似たようなものないの？
- 余談 〜 shove との関係
- おわりに
clenv とは
シェルスクリプトのパッケージ管理システムがあったら、流行るんじゃないかという妄想があって、試しにちょっと作ってみた、という感じです。
WindowsでBashが動くようになったからといって2016年はBashが流行るというのは安直だけど、誰かがいい感じのパッケージ管理システムを作ったら、すごく流行る気がする。
— きいあむ → @progrhyme (@key_amb) 2016年4月11日
今のところ、シェルスクリプトに限らず、コマンドラインで実行可能なファイルをまとめる用途には使えるかな、というぐらいのもので、実際に自分でも使っています。
できること:
$CLENV_ROOT/shims/というパス配下にモジュールの実行ファイルの symlink を貼る$CLENV_ROOT/environments/に任意の名前で「環境」を作り、モジュール群をその「環境」にインストール
お察しかと思いますが、clenv という名前は rbenv や plenv の類推です。
clam モジュール
clenv で利用されるモジュールを clam モジュールと呼ぶことにしました。
モジュールの形式としては「Git リポジトリ」か、「ローカル環境からアクセスできるファイルシステム内の特定ディレクトリ」のみサポートされています。
いずれの場合も、clam.spec というファイルをトップ階層に持つ必要があります。
拙作のシェルスクリプトテストツールである shove も、実はこの clam モジュール形式に対応しておりまして、その clam.spec は下のようになっています。
# bash name=shove version=0.7.2 executables=bin/shove resources=lib/*
このファイルは clam という bash スクリプト内で評価されます。
clam スクリプトは Ruby の gem, Perl の cpan コマンド相当です。
clam https://github.com/key-amb/shove.git を実行すると shove を clenv の環境下にインストールします。
デフォルトの default environment を使っている場合、$CLENV_ROOT/environments/ 以下のディレクトリ構成は以下のようになります。
~/.clenv/environments
└── default
├── Clamdb.txt
├── bin
│ └── shove -> ~/.clenv/environments/default/modules/shove/bin/shove
├── lib
│ ├── shove.bashrc -> ~/.clenv/environments/default/modules/shove/lib/shove.bashrc
│ └── t.shrc -> ~/.clenv/environments/default/modules/shove/lib/t.shrc
└── modules
└── shove/ # モジュールのディレクトリが丸っとコピーされる
で、 ~/.clenv/environments/default/bin が ~/.clenv/shims に symlink されるので、 ~/.clenv/shims に PATH を通しておけば shove をパスなしで実行できる、というわけです。
clam を使う前に 〜 clenv セットアップ
順番が前後したのですが、上の clam の機能を使う前に clenv のセットアップが必要です。
README.md にも書いている通りですが、転記しておきます。
インストール:
git clone https://github.com/key-amb/clenv.git ~/.clenv
シェルの設定:
export CLENV_ROOT=$HOME/.clenv export PATH="$HOME/.clenv/bin:$PATH" export PATH="$HOME/.clenv/shims:$PATH" . ${CLENV_ROOT}/shrc.d/clenv.shrc
初回はこれを .bashrc ないし .zshenv に書いて exec $SHELL -l を実行して下さい。
最後の . clenv.shrc は clenv_switch と clenv_use という2つのシェル関数をロードします。
環境の作成には clenv init-env [ENV] を実行します。(ENV のデフォルトは default)
これは $CLENV_ROOT/environments/ 以下に所定のディレクトリを作るだけです。
clenv_switch ENV で、~/.clenv/environments/ENV/bin が ~/.clenv/shims に symlink されます。
clenv_use ENV だと更に ~/.clenv/environments/ENV/lib/* をシェルスクリプトとして現在のシェルに読み込みます。(が、この機能は要らないかなと思っていたりします。)
その他便利かもしれない使い方
Clamfile
Ruby の Gemfile, Perl の cpanfile 相当です。
モジュールをこのファイルに記述して clam -r Clamfile でまとめてインストールできます。
気になる方は README.md をご覧ください。
任意の実行ファイルを勝手に clam 化してインストール
「この実行ファイルに PATH を通したいから clenv 下に入れておきたい」というときに便利な使い方です。
単純にソースをローカルにダウンロードして clam.spec を記述すればいいです。
wget https://example.com/any-program.zip unzip any-program.zip cd any-program cat <<EOS > clam.spec name=any-program version=0.x executables=bin/* EOS clam . # インストール
こんな感じで any-program/bin/* 以下の実行ファイルに PATH を通せます。
clenv を作ってよかったこと
自分は割とリポジトリを細かく分ける性格で、小さな CLI を含むリポジトリがちらほらあります。
clenv 以前は、それらを submodule にまとめて管理していました。
その管理や、各環境で PATH を通す作業がやや面倒だったのですが、clenv + clam に移行して Clamfile だけの管理になったので、ちょっと楽になった気がします。
clam は消すのも簡単なので、ツールを試しに使うようなときに、とりあえず PATH を通しておくことも気軽にできます。
あれ、シェルスクリプトあんまり関係ない…？
そうなんです。
一応シェル・リソースをロードする機能もあるにはあるのですが、今のところ、「任意の実行ファイルをまとめる君」になっており、「シェルスクリプトのパッケージ管理ツール」としては不完全かな、と思います。
最初に考えていた構想では、シェル関数などを再利用しやすいようにしようなどの企てもあったのですが、今は手が止まってる感じです。
Bash でライブラリ関数的なものを作る気になったら、この構想も進めたい気持ちが高まるかもしれません。
Zsh だとけっこうプラグインがたくさんあって、プラグインの管理ツールもあるようなので、ひょっとしたらここで考えているようなことは実現されているかもしれませんね。
(そもそもシェル関数にしたいケースってけっこう限られそうだと最近思いました。その話はまた機会があれば。)
他に似たようなものないの？
シェルスクリプトのパッケージ管理システムとして見つけたのは下の2つです。
それぞれ、各々のフレームワークの中でモジュール化して再利用できそうな雰囲気ですが、さらっと眺めたところ、各々の形式に合わせてモジュール/パッケージを作らないといけなさそうな感じ。
自分が妄想しているものとは少し違うかなー、と思いました。
余談 〜 shove との関係
下の記事でもちらっと言及していましたが、shove を作ったのは、この clenv のテストを書くためでした。
おわりに
…というわけで、かなり個人用途な感じのツールですが、GitHub で公開していますので、ご利用・ツッコミなどご自由にどうぞ。
また、他に「こういうのあるよ」という情報をいただけましたら幸いに思います。
Enjoy!
