タグ

ブックマーク / naoya-2.hatenadiary.org (14)

  • Dash - naoyaのはてなダイアリー

    Twitter で知人に紹介したら周囲から「これは便利」という声が結構聞こえてきたので、ブログでも紹介しておこう。Dash というドキュメントビューワー。 iOS や RubyMotion、あるいは node や ruby そのほかのマニュアルをまとめてインクリメンタルサーチして API を調べる、ということができる。メジャーな色んな言語に対応している。 来 Dash は "Snippet Manager" ということで、コードスニペットを管理するためのアプリケーションのようだけど自分は単なるドキュメントビューワーとしてしか使っていない。RubyMotion の勉強会に行ったときに、これが便利というのを教えてもらってその後愛用しています。主に iOS の開発のときに利用していた。 http://satococoa.github.com/blog/2013/01/22/view-rdoc-

    Dash - naoyaのはてなダイアリー
    kenichiice
    kenichiice 2015/05/01
    「iOS や RubyMotion、あるいは node や ruby そのほかのマニュアルをまとめてインクリメンタルサーチして API を調べる、ということができる。メジャーな色んな言語に対応している。」
  • ポータブルなWebアプリケーション - naoyaのはてなダイアリー

    140文字で書ききれなかったのでブログに殴り書き。 Heroku のアプリケーションを人に渡す 昨日、「naoyaさんが作ってるiOSアプリのバックエンドサーバーに相乗りさせてもらえないか」という話をいただいた。自分でも同じようなAndroidアプリを作っているけど、サーバーサイドは作ってないからということらしい。 対して「githubにコードあるからgit cloneしてheroku pushすれば動くし、自分で heroku にデプロイしてよ」と応えた。相乗りしてもらってもよかったのだけど、こちらでコードを書き換えたりメンテしたときに先方のアプリが停止することを考えると同じコードベースでサーバーは自分で立ててもらう方が何かと良い。 対象になったソフトウェアは Heroku で動かしていたので、Heroku Ready な形、つまり、必要な外部パッケージの一覧やサーバーの起動手順なんかは

    ポータブルなWebアプリケーション - naoyaのはてなダイアリー
    kenichiice
    kenichiice 2013/12/05
    「Immutable Infrastructure、あるいは Disposable Infrastructure という考え方が昨今話題だ。」
  • 「書く」のは特別な道具 - naoyaのはてなダイアリー

    This is why you shouldn't interrupt a programmer (なぜプログラマの作業に割り込むべきではないか) という4コマ漫画が話題になっていた。これは別にプログラマではなくても「わかるわかる」という感じの話。 コメントを見ると、だから作業を中断してもすぐ再開できるように自分の考えることをなるべく書き出すようにしているという人が結構多かった。なるほど。 今日は雨が降ったせいで予定が一つキャンセルになったことだし、ちょうどいい機会なので、文章で何かを書くということについて自分が思っていることを書いてみようとおもう。以前 Software Design のドキュメントの書き方特集みたいな号に似たような趣旨の話を寄稿したのだけど、「書く」というのは単に物事を忘れないようにするための行為に留まるものではなくて、自分の考えを整理するための道具なのだ、ということが

    「書く」のは特別な道具 - naoyaのはてなダイアリー
    kenichiice
    kenichiice 2013/11/08
    「エンジニアがドキュメントを書かされてしんどいみたいな話ではなく、自分の仕事を助けるためのツールとして DesignDoc という仕組みはとても良いと思うと評価していた。」
  • Treasure Data - naoyaのはてなダイアリー

    少し前にログの話を書いた http://d.hatena.ne.jp/naoya/20130219/1361262854 ときに、Treasure Data については後日にもう少し詳細に書くと言ったので書くとしよう。 近頃 Treasure Data (以下、時折 TD) という名前をちらほら聞いたことがある人は多いのではないかと思います。「ビッグデータのクラウドサービスである」とか「日人が創業したシリコンバレーのベンチャー」、あるいは Yahoo! 創業者の Jerry Yang が投資したとか、Fluentd と何か関係があるといった文脈などなど。 けど、具体的に Treasure Data がどういうサービスで、どういう機能を持っていて、どんな場面で利用されるものなのかはまだあまり良く知られていないかもしれない・・・ようにも見える。今日はその辺から少し紹介していこうかなと思う。

    Treasure Data - naoyaのはてなダイアリー
    kenichiice
    kenichiice 2013/03/25
    「ごくごく単純化して言うとTDは「手元のサーバーとかからログをどんどん送りつけておくとそれを保存しといてくれて、SQL を投げると MapReduce で大規模並列にそれを実行して結果だけ返してくれるクラウドなサービス」」
  • Vagrant - naoyaのはてなダイアリー

    先日 Vagrant を触ってみたら便利すぎて鼻血が出ました。しばらく見ないうちに色々進んでるもんですねえ、いやはや参っちゃいました。 Vagrant は仮想マシンの VirtualBox のフロントエンドに相当する、ruby で書かれたツールです。vagrant コマンドなどを使ってコマンドラインから簡単に新しい VM を作れる。 % gem install vagrant % vagrant box add centos http://developer.nrel.gov/downloads/vagrant-boxes/CentOS-6.3-x86_64-v20130101.box % vagrant init centos % vagrant upこれだけで CentOS の Linux box をローカルマシン内に立ち上げることができる。*1 *2 なにこれすごい。 % vagra

    Vagrant - naoyaのはてなダイアリー
    kenichiice
    kenichiice 2013/02/06
    「Vagrant は仮装マシンの VirtualBox のフロントエンドに相当する、ruby で書かれたツールです。vagrant コマンドなどを使ってコマンドラインから簡単に新しい VM を作れる。」
  • String::Dictionary - naoyaのはてなダイアリー

    String::Dictionary という Perl のライブラリを作ってみました。 http://github.com/naoya/perl-String-Dictionary/tree/master String::Dictionary は検索エンジンその他を作る時に必要になる「辞書」のためのデータ構造 + API です。辞書は単語の集まりですが、これを配列やハッシュなどで持つのではなく、単語をすべて繋げた一つの大きな文字列として保持することでメモリ領域を節約したものです。単語は単に文字列連結で持つだけでなく、Front Coding で圧縮しています。以下簡単な解説です。 辞書は例えば [0] ・・・ jezebel [1] ・・・ jezer [2] ・・・ jezerit [3] ・・・ jeziah [4] ・・・ jeziel ...という風に単語を配列で持つことで実現でき

    String::Dictionary - naoyaのはてなダイアリー
    kenichiice
    kenichiice 2009/06/11
    「これを配列やハッシュなどで持つのではなく、単語をすべて繋げた一つの大きな文字列として保持することでメモリ領域を節約したものです」
  • あるプロセスが利用しているメモリサイズを procfs 経由で調べる - naoyaのはてなダイアリー

    お題は「あるプロセスがどの程度の物理メモリを利用したかを知りたい」です。 手っとりばやく知りたいときは top や ps などで調べると良いでしょうか。例えば手元の coLinuxtop して M キーでソートすると emacs のプロセスが最もメモリを使っているようです。 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1923 naoya 18 0 23120 19m 3096 S 0.0 2.0 0:55.40 emacsメモリサイズは VIRT と RES がありますが、VIRT は Virtual の略で仮想メモリ領域のサイズ、RES が Resident の略で、実際に使用している物理メモリ領域のサイズ。19MB ほど使っているようです。この emacs のプロセスが利用するメモリ領域はざっくり 20MB 程度と

    あるプロセスが利用しているメモリサイズを procfs 経由で調べる - naoyaのはてなダイアリー
  • Linux のスリープ処理、タイマ処理の詳細を見る - naoyaのはてなダイアリー

    UNIX でプロセスを一時的にスリープさせるには sleep(3) が使えます。sleep() は引数に秒単位でしか時間を指定できないので、より短い時間を指定したい場合は usleep(3) (マイクロ秒) や nanosleep(2) (ナノ秒) を使うことになります。sleep(), usleep() はライブラリ関数、nanosleep() はシステムコール*1です。 この usleep() や nanosleep() で 1ms 程度の短い時間プロセスを停止したとして、正確にその時間だけ停止させることはできるでしょうか。http://shiroikumo.at.infoseek.co.jp/linux/time/ にあるコードを参考に、実際に動かしてみます。カーネル 2.6.19 x86_64、CentOS 5 で試します。 まず、nanosleep() で 1ms のスリープを行

    Linux のスリープ処理、タイマ処理の詳細を見る - naoyaのはてなダイアリー
  • マルチスレッドのコンテキスト切り替えに伴うコスト - naoyaのはてなダイアリー

    また Linux カーネルの話です。 Linux では fork によるマルチプロセスと、pthread によるマルチスレッドでの並行処理を比較した場合、後者の方がコストが低く高速と言われます。「スレッドはメモリ空間を共有するので、マルチプロセスとは異なりコンテキストスイッチ時にメモリ空間の切り替えを省略できる。切り替えに伴うオーバーヘッドが少ない。」というのが FAQ の答えかと思います。 が「オーバーヘッドが少ない」と一言にいわれても具体的にどういうことなのかがイメージできません。そこで Linux のスレッド周りの実装を見て見ようじゃないか、というのが今回のテーマです。 3分でわかる(?) マルチプロセスとマルチスレッド まずはうんちく。マルチプロセスとマルチスレッドの違いの図。以前に社内で勉強会をしたときに作った資料にちょうど良いのがあったので掲載します。Pthreadsプログラミ

    マルチスレッドのコンテキスト切り替えに伴うコスト - naoyaのはてなダイアリー
  • Linux I/O のお話 write 編 - naoyaのはてなダイアリー

    write はページに dirty フラグを立てるだけなので決してユーザープロセスを待たせない って、当にそうなんでしょうか?(否定しているわけではなく、純粋な疑問です。) と質問をもらったので、最近追ったことをここでまとめます。かなり長文です、すいません。また、まだまだ不勉強なので間違っているところもあるかもしれません。ツッコミ大歓迎です。 まず、オライリーのカーネルの 15章 ページキャッシュ 15.3 汚れたページのディスクへの書き込み から引用。 ご存知のように、カーネルは、ブロック型デバイスのデータを含むページをページキャッシュに蓄えています。プロセスが何らかのデータを更新した場合は、必ず対応するページに汚れている印をつけます。すなわち、PG_dirty フラグを設定します。 UNIX システムでは、汚れたページのブロック型デバイスへの書き込みを遅延することができます。この方

    Linux I/O のお話 write 編 - naoyaのはてなダイアリー
  • naoyaのはてなダイアリー - Linuxのページキャッシュ

    世間では PHP が、Perl が、と盛り上がっているようですが空気を読まずまたカーネルの話です。今回はページキャッシュについて。 /dev/shm に参照系DBを持っていくと I/O 負荷が激減した件(当たり前だけど) - drk7jp で、ディスク上にあったファイルを /dev/shm (tmpfs) に移したら I/O 待ちがなくなって負荷がさがった、ということなんですがおそらくこれは tmpfs に置く必要はないかなと思います。Linux (に限らず他の OS もそうですが) にはディスクの内容を一度読んだらそれはカーネルがキャッシュして、二度目以降はメモリから読む機構 = ページキャッシュがあります。tmpfs にデータを載せることができた、ということは物理メモリの容量に収まるだけのデータサイズかと思うので、放っておけば該当のファイルの内容すべてがメモリ上にキャッシュされて io

    naoyaのはてなダイアリー - Linuxのページキャッシュ
  • マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー

    ちょっと煽り気味のタイトルですが、CPU がマルチコアになり 2個、4個と増えていく中 Linux の負荷の指針になるロードアベレージをどう読むべきか、という話です。気になったところを少し調べたのでそのまとめを。 http://d.hatena.ne.jp/naoya/20070222/1172116665 でも書いたとおり、Linux のロードアベレージは「ロードアベレージは過去1分、5分、15分の間の実行待ちプロセス数の平均数 = 実行したくても他のプロセスが実行中で実行できないプロセスが平均で何個ぐらい存在してるか」を示す値です。ボトルネックが CPU、メモリ、ディスク等々どこにあるかは関係なく、仕事の実行までにどれぐらい待たされているかを示す値なので、システムのスループットを計測する指標の入り口になる値です。 このロードアベレージですが、実装を見るとランキュー(待ち行列)に溜まった

    マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー
  • naoyaのはてなダイアリー - 負荷とは何か

    調べごとをしたので blog に書いて理解を深めようのコーナーです。長文です。 Linux でシステム負荷を見る場合にお世話になるのが top や sar (sysstat パッケージに同梱されてるコマンド) などのツールです。 top ではシステム統計のスナップショットを見ることができます。今システムがどういう状態かなーというときは top が便利。 top - 08:16:54 up 3 days, 14:43, 6 users, load average: 0.18, 0.07, 0.03 Tasks: 43 total, 2 running, 41 sleeping, 0 stopped, 0 zombie Cpu(s): 18.2% us, 0.0% sy, 0.0% ni, 81.8% id, 0.0% wa, 0.0% hi, 0.0% si一方の sar では10分ごとのシ

    naoyaのはてなダイアリー - 負荷とは何か
  • naoyaのはてなダイアリー - MySQL の負荷分散に LVS + keepalived を使う

    あとで書く、と言った手前なので書くとします。 DSASの中の人がすごい勢いで LVS の話を書いてくれてます。この辺。LVS を使うと Linux と箱でロードバランサが作れちゃいます。普通に買ったら数百万とかしちゃうやつ。 DSAS の中のひとに感謝しつつ、いい機会なのでやってみよう! と思っていろいろ試して昨日あたりからはてなの中でも LVS + keepalived で動かしはじめてます。いまのところ問題なし。 そのロードバランサをどこに使ってるかですが、普通ロードバランサというとインターネットからの入り口のところに置いてウェブサーバーの負荷分散に使うイメージがあります。が、今回ははてなでは MySQL のスレーブの手前に置くという役割でとりあえず使いはじめました。 +-----------+ +-----------+ | mod_perl | | mod_perl | +----

    naoyaのはてなダイアリー - MySQL の負荷分散に LVS + keepalived を使う
  • 1