nDiki : Web サーバ

Web サーバ - Web server

関連情報

2010年5月14日 (金)

今日のさえずり: 北海道や東北ではデズニーランドなんだ

2010年05月14日

  • 11:39 ん? 秋葉原から恵比寿って日比谷線より山手線の方が速くて安いのか。
  • 12:23 床屋予約。日曜日 9:30。
  • 12:30 通りでクーポンもらって 600円。 (@ ケンタッキーフライドチキン 秋葉原店) http://4sq.com/5g7jf6
  • 15:39 社内 Web サーバが重かったのは cron からの大量のメールで /var/spool/mail/root が巨大になりすぎ、sendmail が配信できなかったメールをがんがんリトライし続けていたためっぽい。
  • 15:58 コーラ飲んでげふってしたくなった。
  • 16:06 ペプシネックス with サタデー・ナイト・フィーバーにした 125円。 (@ ファミリーマート 東神田二丁目店) http://4sq.com/aredqe
  • 17:35 眼鏡出来上がった(再)らしい。
  • 19:07 @3_DaiMe_Yoshi 眼鏡かえるとクラクラしますよね。一度できあがって試しにかけたのですが同じ度で作ったのにずいぶん違った見えでした(レンズの大きさとかで)。
  • 19:44 眼鏡受け取りに恵比寿に向かってる。日曜日には床屋に行くし、週明けは別人ですよ。
  • 19:58 「混雑時、ひらくワキにご注意ください。」という Ban の広告の下に「ワキ、ヨォーシ!」という TBC の広告。陰謀の香りがプンプンする。
  • 20:23 眼鏡できたよ。
  • 20:33 Android 本買った 3360円。 (@ 有隣堂 アトレ恵比寿店) http://4sq.com/6FtGjA
  • 20:36 @Meg_mama ありがとうございます。今のがボロボロでようやくの新調です。そういえば Xperia 入手されたんですね!
  • 20:48 @Meg_mama 実は昨日 XperiaUstream 公式アプリ(2つ)入れて試してみました。配信・視聴それぞれできましたよ。Ustream アカウント初めて作ったぐらいのレベルなのでで画質や使い勝手の良い悪いはわかってないです。
  • 20:51 眼鏡受け取って今品川駅です。あとはまっすぐ帰りますね。
  • 20:56 やちゃった。無難な内容でよかったけど、1つ前の tweet メールするつもりだったやつ。送信押した瞬間「あって」。
  • 20:57 そして乗り換えた電車が空いてると思ったら逆方面のだったり。
  • 21:04 @Meg_mama マーケットで Ustream検索して作者が Ustream.tv の2つのアプリケーションです。配信は…ネタがないので当分ないです。
  • 21:12 Xperia 買ってから乗り過ごしとか逆方面とか東京生まれらしくない乱れっぷり。
  • 21:51 新しい眼鏡かけてご飯食べた。前のちょっと歪んだ眼鏡に脳が適応してしまっているせいか、まだ違和感あり。ああ、でもずいぶん明るくクリアになったなあ。いいね。
  • 21:54 しかし新しい物を買った時の常というか、急に今まで使っていた眼鏡がすごくボロッちく見えてきた。
  • 22:56 へー、北海道や東北ではデズニーランドなんだ。
[ 5月14日全て ]

2010年10月15日 (金)

今日のさえずり: 「We はーと blog」シールをさっそく貼っといた

image:/nDiki/Flickr/5085927367.jpg

[ 10月15日全て ]

2013年3月1日 (金)

nginx デビュー

ちょっとした 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!」ページの表示を確認。

お手軽。

[ 3月1日全て ]

2014年1月29日 (水)

git-new-workdir で複数の Git ブランチをチェックアウトして同時に作業する

Git のトピックブランチで開発している時に、他のブランチを同時にチェックアウトしておきたくなる事がままある。

  1. 割り込みで他の人のコードをレビューするため。
  2. 途中で別の不具合見つけたので、別トピックブランチで先に fix するため。
  3. 複数のブランチ上のファイルをつまみ食い的に Emacs で開いて中を見たりしたいため。
  4. 他の人に使い勝手などを確認してもらうため、あるブランチWeb サーバを起動したいため。

いったんテンポラリコミットを作ったり、あるいは 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 はこういうところがカワイイよね。

[ 1月29日全て ]

2015年5月3日 (日)

公園でパンを食べたり、MacBook Pro でこの日記を編集できるようにしたり【日記】

image:/nDiki/Flickr/16727668524.jpg

いい陽気。今日は体力的にがっつりにはしないことにしようということで、パンを買って公園で食べてくるぐらいをしてきた。ちょっとした事だけれど、天気は良いし緑も綺麗なので幸せである。

あとはようやくこの日記MacBook Pro で更新できるようにした。記事データの転送自体はこの間 Unison でできるように設定してあるのであとは、事前にドラフトを確認環境を作るぐらい。

Perl の環境は perlbrew で。Web サーバHomebrewApache HTTP Server Versoin 2.4 を入れた。最近は Debian 流の Apache 設定で馴染んでしまっているので、素に近いのは久しぶりでなんか新鮮。初めてさわる 2.4 系は設定ファイルの書き方が少し変更になっていて一発ではうまく動かなかったけれど最終的に動くようになったので良かった。

あとは写真管理方法を決めることができてデータの移動も住めば ThinkPad X200 (Debian GNU/Linux) と MacBook Pro (OS X) の併用もだんだんしなくて済むようになるかな。

[ 5月3日全て ]

2016年12月9日 (金)

nDiki に貼る写真Flickr ではなく同じサーバに置く

この nDiki写真を載せる際は2005年から Flickr にアップロードしてそれを貼りつけるようにしています。これを今後は普通に画像ファイルを Web サーバ側に置くことにしました。

Flickr写真を置いておくメリットは以下があります。

一方デメリットとしては

  • Flickr にベンダーロックインされている。長期的には一抹の不安。
  • 一度画像URL が変わったタイミングで過去の写真が一部表示できなくなっている(記事側の URL を変更していく必要がある)。今後も同様の自体があり得る。

があります。

Flickr 利用で使い勝手的には問題が無いのですが、長期的に継続する Web 日記のコンテンツとしては他のサービスに依存しすぎないようにした方が良いということで、今後は普通に Web サーバに置くことにしました。

そうするとどのサイズの画像ファイルを用意するかを改めて考える必要が出てきました。

画像サイズ

今までは Flickr で生成されるから適当そうなもの(たいがい長辺 500px のもの)を選んで貼っていました。今後は自分で適切なファイルを作ってアップロードすることになるので画像サイズについてちょっと見直してみました。

Bootstrap 3 でのサイトの幅の見直してコンテナを 970px までに

Bootstrap 3 だと広くても幅 1140px (1170px - 30px) なので画像幅もこれだけあれば十分です。しかし考えてみると nDiki は1カラムなのでラージデバイス(≥1200px)向けのコンテナ 1170px はいささか広すぎます。ということでいったんミディアムデバイス向けのコンテナ 970px までしか広げないようにしました。

 @media (min-width: 1200px) {
     .container {
         width: 970px;
     }
 }

写真は基本 max-width: 100% の .img-responsive で表示しているので、これで最大 940px 幅で表示されることになります。

表示される写真の高さは最大 480px に

幅 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 です。

画像ファイルの画像サイズは長辺 1200px に

これで 640x480px (4:3) や 720x480px (3:2) にリサイズして Web サーバに置けば現時点では過不足ないということがわかりました。

ただこれだとデバイスの変化でサイトデザインを見直す時がきた時に解像度不足になってしまいます。Bootstrap のラージデバイス向けのコンテナサイズを考えていったん長辺 1200px で画像ファイルを用意することに決めました。

ついでに .pull-left と .pull-right の画像幅も調整

写真を左右に寄せた際に現状テキスト部分が狭くなりすぎることがあるのでこのあたりも合わせて今回調整しました。

 .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%;
     }
 }
[ 12月9日全て ]

2017年6月28日 (水)

今日のさえずり: ニンテンドークラシックミニ Atari C-380 が出たら実家へのプレゼントとして買う

2017年06月28日

[ 6月28日全て ]

2018年2月26日 (月)

Markdown で書いているノートWeb ブラウザで見るのに MkDocs を使う

ノート/メモははライティングアプリ Ulysses を使い Markdown で書いていて、検索・閲覧・整理も Ulysses で基本済ませています。ただいくつかの良く参照するファイルはブックマークやハイパーリンクから Web ブラウザでさっと表示させたかったりします。なので以前は Plack::App::Directory::Markdown を使った自作 PSGI アプリケーションを使ってました。

が、セットアップしたり保守したりという手間を今とれないなと思って、 Markdown ビューアを探してみたところ MkDocs が良さそうなので試してみました。

MkDocsHomebrew で入れてみる

MacBook ProHomebrew で入れて動かしてみます。

 $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 ファイルノートディレクトリへシンボリックリンクを作ればそれらも辿って表示されます。

pip で入れ直す

試していてブラウザでのレンダリング表示が重いなと思って HTML ソースを見たら同じ JavaScript ファイルを何十回も読み込んでいて何か変ぽかったので Homebrew のをやめて pip で入れなおしました。どちらも現在 mkdocs 0.17.2 ですが pip で入れた方は問題なかったのでこちらを使うことにします。

 $brew uninstall mkdocs
 $brew install python
 $pip2 install mkdocs

MkDocs静的サイトジェネレータで、プレビューサーバは補助的機能ですがまずまず使えそうです。

[ 2月26日全て ]

2018年2月28日 (水)

GitHub Flavored Markdown ファイルの Web ブラウザでのプレビューに Grip を使う

Markdown で書いているノートを Web ブラウザで見るのに MkDocs を使う」とつぶやいたら @bsdhack 氏が Grip を紹介してくれました。

さっそく試してみました。

 $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 ブラウザで見てみたい時にも便利なツールですね。

今日のさえずり: イトーヨーカドー 大井町店のポッポとうとう今日まで。名残惜しい。

[ 2月28日全て ]

2019年6月25日 (火)

HTML ページ中の mermaid 定義を自動的にクライアント側で SVG 変換し表示させる

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 要素が生成し置き換えてくれる。表示は以下のような感じ。

graph LR a --- b a --- c

画像ファイルの管理から解放されるのでいろいろ捗って嬉しい。

とりあえず nNote 全フッタで mermaid.min.js を読み込むようにしちゃったけれど 8.0.0 ので 1.11MB ありダイアグラムの無いページで読み込ませるのはちょっと忍びない。 mermaid ダイアグラムの定義がある時だけ読み込むようにした方が良いね。

[ 6月25日全て ]

About

Naney Naneymx

Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。

※本サイトの内容は個人的見解であり所属組織とは関係ありません。

Process Time: 0.026296s / load averages: 0.25, 0.25, 0.24