ちょっとした Web サーバが欲しくなったんだけれど Apache 面倒だなと思って、初めて nginx 触ってみた。
tarball ダウンロードして適当に configure、make install して conf で port 番号変えて起動。ドキュメントほとんど読む必要無くて10分かからなかった。
wget http://nginx.org/download/nginx-1.2.7.tar.gz tar zxvf nginx-1.2.7.tar.gz cd nginx-1.2.7 ./configure --prefix=$HOME/local/nginx-1.2.7 make make install emacs $HOME/local/nginx-1.2.7/conf/nginx.conf # http {} の中の server {} の中の listen を 80 から 8000 に変更。 ~/local/nginx-1.2.7/sbin/nginx
で Web ブラウザで 8000 にアクセス。「Welcome to nginx!」ページの表示を確認。
お手軽。
Git のトピックブランチで開発している時に、他のブランチを同時にチェックアウトしておきたくなる事がままある。
いったんテンポラリコミットを作ったり、あるいは stash したりして作業ツリーを保存してチェックアウトしなおして用事を済ませて元に戻すとかはやるのだけれど、ちょっと面倒。3番目のケースは同時にチェックアウトしたいのでこの方法だと駄目だし、4番目のケースだとしばらくそのままにしておかないのでもっと困る。
そのような時はローカルリポジトリから別ディレクトリへ clone して、そちらをサブで使ったりするんだけれど、サブの方でちょっと修正したりした際にローカル間で push/pull とかしなければならなくてこれまた面倒。
なんかいいのないかなと思ったら Git の contrib に git-new-workdir というのがあるのを昨日知った。
git-new-workdir . ../sub あるいは git new-workdir . ../sub
で作業ツリーを新しく作れる。/tmp/git/main を /tmp/git/sub に new-workdir すると sub の方の .git の中は
drwxr-xr-x 3 naney naney 4096 1月 30 00:37 . drwxr-xr-x 3 naney naney 4096 1月 30 00:37 .. -rw-r--r-- 1 naney naney 23 1月 30 00:37 HEAD lrwxrwxrwx 1 naney naney 25 1月 30 00:37 config -> /tmp/git/main/.git/config lrwxrwxrwx 1 naney naney 24 1月 30 00:37 hooks -> /tmp/git/main/.git/hooks -rw-r--r-- 1 naney naney 104 1月 30 00:37 index lrwxrwxrwx 1 naney naney 23 1月 30 00:37 info -> /tmp/git/main/.git/info drwxr-xr-x 2 naney naney 4096 1月 30 00:37 logs lrwxrwxrwx 1 naney naney 26 1月 30 00:37 objects -> /tmp/git/main/.git/objects lrwxrwxrwx 1 naney naney 30 1月 30 00:37 packed-refs -> /tmp/git/main/.git/packed-refs lrwxrwxrwx 1 naney naney 23 1月 30 00:37 refs -> /tmp/git/main/.git/refs lrwxrwxrwx 1 naney naney 26 1月 30 00:37 remotes -> /tmp/git/main/.git/remotes lrwxrwxrwx 1 naney naney 27 1月 30 00:37 rr-cache -> /tmp/git/main/.git/rr-cache lrwxrwxrwx 1 naney naney 22 1月 30 00:37 svn -> /tmp/git/main/.git/svn
のような感じで HEAD と index と logs/HEAD 以外はもとのローカルリポジトリへのシンボリックになっている。なので sub での checkout や index の Git 操作など以外は main の方へ反映されるようになっている。わざわざ push/pull しなくて良いのでこれは楽ちん。もちろん作業ツリーはそれぞれ独立しているので、例えばサブの方で Web サーバを起動しておいたり時間のかかるフルテストを走らせておくとかもできる。
ただ複数チェックアウトして作業していると、気がつくと Emacs で違うほうの作業ツリーのファイルを開いて編集していたりして「あれ? 変更したけれどなぜか反映されない……」とかやっちゃうので(実際やった)ちょっと注意が必要ではある。
git-new-workdir は contrib の中(Debian GNU/Linux sid だと /usr/share/doc/git/contrib/workdir/git-new-workdir)にあるみじかいシェルスクリプトなので適当に PATH の通ったところにコピーして実行権限を設定しておけば OK。
Git はこういうところがカワイイよね。
いい陽気。今日は体力的にがっつりにはしないことにしようということで、パンを買って公園で食べてくるぐらいをしてきた。ちょっとした事だけれど、天気は良いし緑も綺麗なので幸せである。
あとはようやくこの日記を MacBook Pro で更新できるようにした。記事データの転送自体はこの間 Unison でできるように設定してあるのであとは、事前にドラフトを確認環境を作るぐらい。
Perl の環境は perlbrew で。Web サーバは Homebrew で Apache HTTP Server Versoin 2.4 を入れた。最近は Debian 流の Apache 設定で馴染んでしまっているので、素に近いのは久しぶりでなんか新鮮。初めてさわる 2.4 系は設定ファイルの書き方が少し変更になっていて一発ではうまく動かなかったけれど最終的に動くようになったので良かった。
あとは写真管理方法を決めることができてデータの移動も住めば ThinkPad X200 (Debian GNU/Linux) と MacBook Pro (OS X) の併用もだんだんしなくて済むようになるかな。
この nDiki に写真を載せる際は2005年から Flickr にアップロードしてそれを貼りつけるようにしています。これを今後は普通に画像ファイルを Web サーバ側に置くことにしました。
一方デメリットとしては
があります。
Flickr 利用で使い勝手的には問題が無いのですが、長期的に継続する Web 日記のコンテンツとしては他のサービスに依存しすぎないようにした方が良いということで、今後は普通に Web サーバに置くことにしました。
そうするとどのサイズの画像ファイルを用意するかを改めて考える必要が出てきました。
今までは Flickr で生成されるから適当そうなもの(たいがい長辺 500px のもの)を選んで貼っていました。今後は自分で適切なファイルを作ってアップロードすることになるので画像サイズについてちょっと見直してみました。
Bootstrap 3 だと広くても幅 1140px (1170px - 30px) なので画像幅もこれだけあれば十分です。しかし考えてみると nDiki は1カラムなのでラージデバイス(≥1200px)向けのコンテナ 1170px はいささか広すぎます。ということでいったんミディアムデバイス向けのコンテナ 970px までしか広げないようにしました。
@media (min-width: 1200px) { .container { width: 970px; } }
写真は基本 max-width: 100% の .img-responsive で表示しているので、これで最大 940px 幅で表示されることになります。
幅 940px だと 4:3 なら高さは 705px、3:2 なら高さは約 627px になります。13インチMacBook Pro 上の Google Chrome でこのサイズの写真を貼るとほぼ縦いっぱいになってしまいます。記事中の写真では 480px ぐらいまでかなという印象でした。ということで
max-height: 480px;
としました。
これだと 4:3 なら 640x480px、3:2 だと 720x480px の画像サイズがあれば十分なことになります。縦位置だと 3:4 で 360x480px、 2:3 だと 320x480px です。
これで 640x480px (4:3) や 720x480px (3:2) にリサイズして Web サーバに置けば現時点では過不足ないということがわかりました。
ただこれだとデバイスの変化でサイトデザインを見直す時がきた時に解像度不足になってしまいます。Bootstrap のラージデバイス向けのコンテナサイズを考えていったん長辺 1200px で画像ファイルを用意することに決めました。
写真を左右に寄せた際に現状テキスト部分が狭くなりすぎることがあるのでこのあたりも合わせて今回調整しました。
.img-responsive { display: inline-block !important; max-height: 480px; } @media (min-width: 768px) { .pull-left.img-responsive { max-width: 50%; } .pull-right.img-responsive { max-width: 50%; } } @media (min-width: 992px) { .pull-left.img-responsive { max-width: 50%; } .pull-right.img-responsive { max-width: 50%; } } @media (min-width: 1200px) { .pull-left.img-responsive { max-width: 50%; } .pull-right.img-responsive { max-width: 50%; } }
ノート/メモははライティングアプリ Ulysses を使い Markdown で書いていて、検索・閲覧・整理も Ulysses で基本済ませています。ただいくつかの良く参照するファイルはブックマークやハイパーリンクから Web ブラウザでさっと表示させたかったりします。なので以前は Plack::App::Directory::Markdown を使った自作 PSGI アプリケーションを使ってました。
が、セットアップしたり保守したりという手間を今とれないなと思って、 Markdown ビューアを探してみたところ MkDocs が良さそうなので試してみました。
MacBook Pro に Homebrew で入れて動かしてみます。
$brew install MkDocs $mkdir -p ~/var/mkdocs $cd ~/var/mkdocs $mkdocs new local $cd local $mkdocs serve
で Web サーバが立ち上がるので http://127.0.0.1:8000/ にアクセスすると ~/var/mkdocs/local/docs/index.md の内容を HTML に変換したものが表示されます。お手軽! 設定変更は ~/var/mkdocs/local/mkdocs.yml できます。
あとは docs の下に Markdown ファイルを置いておけば Web ブラウザで閲覧できます。docs の下に既存の Markdown ファイルノートディレクトリへシンボリックリンクを作ればそれらも辿って表示されます。
試していてブラウザでのレンダリング表示が重いなと思って HTML ソースを見たら同じ JavaScript ファイルを何十回も読み込んでいて何か変ぽかったので Homebrew のをやめて pip で入れなおしました。どちらも現在 mkdocs 0.17.2 ですが pip で入れた方は問題なかったのでこちらを使うことにします。
$brew uninstall mkdocs $brew install python $pip2 install mkdocs
MkDocs は静的サイトジェネレータで、プレビューサーバは補助的機能ですがまずまず使えそうです。
「Markdown で書いているノートを Web ブラウザで見るのに MkDocs を使う」とつぶやいたら @bsdhack 氏が Grip を紹介してくれました。
私はgithubなどのmdファイル(https://t.co/nyoqRnjsN7)を読むために python製の grip 使って↓なスクリプトを書いて使ってます。
— Mitzyuki IMAIZUMI (@bsdhack) 2018年2月28日
grip --export ${1:-README.md} - | w3m -T text/html
さっそく試してみました。
$pip2 install grip
でインストールしたら Markdown ファイルを指定して Grip を起動します。
grip index.md
Grip が http://localhost:6419/ で Web サーバとして立ち上がるので Web ブラウザでアクセスすると index.md の HTML 変換されたものを見ることができます。なお
grip -b index.md
とすれば起動と同時に Web ブラウザで開いてくれます。URL でパスを指定すればそのまま同じ/サブディレクトリにある Markdown ファイルもプレビューできるので、ハイパーリンク付けをしておくことでドキュメント群をブラウジングすることもできます。なるほどお手軽で便利。 GitHub 上とほぼ同様の見慣れたデザインになるのがいいですね。
そもそも Grip は「GitHub Readme Instant Preview」で GitHub 上での表示確認のためのツールで、 GitHub の REST API を使ってレンダリング結果を生成しているので当然といえば当然だったりはします。
ただそのかわり GitHub の API を使うので
と場合によっては不便な部分があります。なお後者については GitHub Enterprise があるなら Grip でそちらを指定するとう手もあります。
GitHub に push する前にチェックしたい時はもちろん、それ以外でさっと Web ブラウザで見てみたい時にも便利なツールですね。
とんかつ屋さん#α6300 + GIZMON #Utulenshttps://t.co/KUHQRJ3qgg pic.twitter.com/mNUuKKt3ep
— Naney (@Naney) February 28, 2018
6月上旬に使い始めた Markdown エディタ Typora で mermaid を使いダイアグラムを作成してみたらなかなか良かったので、先日 mermaid のデータから画像を単独で生成できるよう CLI を入れてみた。しかしやはり都度画像ファイルに変換して管理するのは面倒。ちょっとしたノートを置いておくスペース nNote では事前に画像ファイルに変換しないで直接ページ上に書かれた mermaid ダイアグラムを SVG 変換して表示されるように設定してみた。
mermaid.min.js を Web サーバに配置し、ページの下部に以下が含まれるようにフッタファイルを編集。
<script src="/path/to/mermaid.min.js"></script> <script>mermaid.initialize({startOnLoad:true});</script>
これでページ中に
<div class="mermaid"> graph LR a --- b a --- c </div>
のようにダイアグラムの定義をmermaid クラスの要素の中に書いておくと、ダイアグラムの SVG 要素が生成し置き換えてくれる。表示は以下のような感じ。
画像ファイルの管理から解放されるのでいろいろ捗って嬉しい。
とりあえず nNote 全フッタで mermaid.min.js を読み込むようにしちゃったけれど 8.0.0 ので 1.11MB ありダイアグラムの無いページで読み込ませるのはちょっと忍びない。 mermaid ダイアグラムの定義がある時だけ読み込むようにした方が良いね。
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。