Dash - naoyaのはてなダイアリー
Twitter で知人に紹介したら周囲から「これは便利」という声が結構聞こえてきたので、ブログでも紹介しておこう。Dash というドキュメントビューワー。 iOS や RubyMotion、あるいは node や ruby そのほかのマニュアルをまとめてインクリメンタルサーチして API を調べる、ということができる。メジャーな色んな言語に対応している。 本来 Dash は "Snippet Manager" ということで、コードスニペットを管理するためのアプリケーションのようだけど自分は単なるドキュメントビューワーとしてしか使っていない。RubyMotion の勉強会に行ったときに、これが便利というのを教えてもらってその後愛用しています。主に iOS の開発のときに利用していた。 http://satococoa.github.com/blog/2013/01/22/view-rdoc-
RubyMotion開発者インタビュー記事 - naoyaのはてなダイアリー
I was thrilled earlier this month when Laurent agreed to do an interview with me for RubySource. I would be able to learn more about RubyMotion directly from its inventor. Since I had so many questions, I've divided the interview into two posts. First today I'll ask Laurent some basic questions: What is RubyMotion, exactly? What does it do? How should we use it? Is writing Ruby for iOS any differe
開発メモ#2 : AWS でのホスト / クラウドネイティブなデプロイ - naoyaのはてなダイアリー
開発メモ#1 : Cinnamon によるデプロイ - naoyaのはてなダイアリー に引き続き、その2です。 最近は個人で作るような小規模なものでも AWS を利用してホストしています。たとえ個人で作ったものとはいえ、利用するユーザーがいる以上はおいそれと落とすこともできない。かといって運用にあまり手間をかけたくない。その辺り、AWS で解決できる点が多い。 AWS の良いところはインフラが動的なので「後からどうとでもなる」ところ。 インスタンスの性能が足りないのであればスケールアップするでもいいし、冗長性が欲しくなったらそのタイミングで ELB (ロードバランサ) を用意すれば良い。その時、仮想化されていないハードウェアを使っていると移行のためにサーバーを再セットアップしたりアプリケーションをデプロイし直したりと手間がかかるところ、AWS ではその辺りの手間がほとんどかからない･･･と
ファーストサーバ社の障害に関して - naoyaのはてなダイアリー
あまりまとめられないので箇条書きで。 「クラウド (IaaS)」と「レンタルサーバ」の区別 技術的には「クラウド (における IaaS)」と「レンタルサーバー」は明確に異なるものなので、そこは混同されないことをおすすめしたい 今回障害が起こったファーストサーバのサービスはレンタルサーバであって、クラウドサービスではないだろう クラウド = Amazon Web Services (AWS) や Heroku がその代表例だと思ってもらえばいい *1 具体的には、日経新聞の当該記事のこと → http://www.nikkei.com/article/DGXNASFK2600L_W2A620C1000000/ 意図は不明だが「クラウド」のような目新しいものと今回の事件とを結びつけて何かしらの印象を与えようとするのは、個人的には感心しない 業者が「クラウド」と謳っていたかどうかは知らない。例え
リアルグラフへの違和感 - naoyaのはてなダイアリー
なんか facebook のコメント blog とかに表示するやつに投稿されてるコメント、なんか素直に読めない感じのコメントが多い。･･･うまく言葉にできないので過激な言い方をすると気持ち悪いと感じるというか。ひどい言い方で、すみません。 実名とかで現実のアイデンティティを担保にとれば、コメントとか炎上もなくなってまともになるでしょうって話だったけれど、facebook でそれが現実になってみたが結果的にはぜんぜんまともじゃなかった。 アイデンティティが現実世界のそれだから、いろんな意味で発言の評価が本人に結びつけられた場合のフィードバックが強すぎるんじゃないだろうか。書く側は、なんだか立派なことを言ってみたり思ってもないことを言ってみたりと格好つけるし、読む側からの印象としてはそれ全部がひどいポジショントークに見えてしまって気分が萎える。 たしかに自分も、実名･･･というか現実のアイデン
Titanium Mobile 2.0 対応など - naoyaのはてなダイアリー
Titanium Mobile がメジャーバージョンアップして SDK が 1.8 から 2.0.1 になりました。HBFav を SDK 2.0.1 に対応させる作業をひとまず終えたので、以下雑感など。 Titanium Mobile 2.0.1 で何が変わったか Release Notes http://docs.appcelerator.com/titanium/release-notes/?version=2.0.1.GA 大きな変更点はレイアウトシステムの更新です。加えていろいろとバグフィックス。ほかにも Appcelerator Cloud Services (ACS) という BaaS 連携が発表されていますが、純粋に SDK のアップデートというとレイアウトシステムとバグ修正が主なところ。Andorid位置情報対応の強化、Module API のアップデートもありますが、こ
HBFav というはてなブックマーク iPhone アプリを作りました - naoyaのはてなダイアリー
ちょこちょこと余暇の時間を使って、HBFav という iPhone アプリを作りました。 HBFav は、はてなブックマークの「お気に入り」機能を閲覧するためのアプリです。はてなブックマークの「お気に入り」は、気に入ったユーザーがブックマークしたブックマークを一覧する機能、つまり、Twitter で言うところのタイムラインです。それを見る専用のアプリがほしかった、ということで作ったものです。 ･･･ということで、繰り返すと、HBFav はタイムライン形式でソーシャル・ブックマークを楽しむためのアプリ。はてなブックマークのお気に入り機能を活用しているぜ! という方におすすめです。 HBFav は、App Store からインストールできます。 App Store - HBFav : http://itunes.apple.com/app/id477950722 Kindle とともに HBF
退職のお知らせ - naoyaのはてなダイアリー
本日8月31日をもって、はてなを退職しました。 入社は2004年9月1日でしたから、今日でちょうど6年です。6年間の間に、はてなブックマークをはじめとする各種サービスの企画開発やディレクション、インフラの構築、技術チームのマネジメント等々、色々な経験を積むことができました。その一方で、なかなか自分の思うようにはサービスを成長させる、会社を伸ばすことができず自分の力量不足を感じる毎日でもありました。その足りない能力と経験を埋め合わせる日々が、成長を促してくれたとは思います。 この6年は、はてなという会社が、個人あるいは家族のような繋がりから組織に変っていく過程でした。会社というものが何なのかを全然知らなかった自分が、Webサービスの開発と運営に、組織がなぜ必要かというのを体で知ることになりました。なかなかに得難い経験でした。 遠回りもありましたが、はてなは組織になりました。新サービスは日々ユ
List::FrontCode - naoyaのはてなダイアリー
先日 Array::Gap という Variable Byte Codes による整列済み整数の圧縮の実装を作りました。(id:naoya:20080906:1220685978) 今日は Front Coding を使った同じような圧縮リストクラス、List::FrontCode を作ってみました。Front Coding は辞書式順に整列済みの文字列リストなどを圧縮する手法です。WEB+DB PRESS Vol.42 のアルゴリズム&データ構造の記事で PFI の岡野原さんによる解説があったので、それを参考に実装しました。 Front Coding Front Coding は http://www.hoge.jp http://www.hoge.jp/a.htm http://www.hoge.jp/index.htm http://www.fuga.com/ http://www.
OSC 2008 Kansai in Kyoto - naoyaのはてなダイアリー
7/18・19の二日間、京都でオープンソースカンファレンスが開催されます。自分も一枠、スピーチ枠をいただきました。はてな創業当時からこれまでの間、バックエンドシステム、開発体制や開発環境がどのように変遷してきたかを紹介させていただければと思っています。 株式会社はてな ではブログやソーシャルブックマークなどをはじめとする ウェブサービスを提供しています。それらサービスの バックエンドシステムの構成、開発手法を、創業当時からの変遷を追いながら紹介していきます はてなは創業当時、社長とスタッフの二名の会社でした。当時のサーバーは余っていたパーツで組み立てたPCサーバー、回線は ADSL でした。Perl でベタなアプリケーションを書く毎日だったそうです。同じことの繰り返しを効率化するためにMVCフレームワークが開発がされます。フレームワークができて開発効率がぐっと上がりました。一方の自社サービ
中島さんと古川さんの対談 - naoyaのはてなダイアリー
中島聡さん の おもてなしの経営学 アップルがソニーを超えた理由 (アスキー新書) を読みました。とにかく古川さん との対談が面白い。「経営学」と題している書籍ではあるのですが、この対談の箇所だけを抜き取ると、一人のソフトウェアエンジニアがどのようにして未来を切り開いたかというエンジニア論の体をなしています。 著者の中島さんの blog ははてなブックマークでも人気エントリーの常連なので、ご存じの方も多いことかと思います。 ところで 1998 年に、マイクロソフトがブラウザ戦争 (wikipedia:ブラウザ戦争)の結果、独占禁止法で提訴されたことがありました。個人的にはネットスケープがマイクロソフトにボコボコにされて「もうやめて、ネットスケープのライフは 0 よ!」と勝敗が完全についた区切り/象徴である事件だと認識していて、当時はまだそれほど IT ビジネスに関心がなかったにも関わらず興
ソフトウェア技術者としての残り時間 - naoyaのはてなダイアリー
年始の NHK でのイチロー特集番組を見ていて一番印象に残ったのは、他の人の道具を絶対に触らないというイチローのこだわりでした。曰く、人の道具を触るとその道具の感覚が体に残ってしまい、自分の道具を利用するときの感覚の妨げになるから、ということでした。全体を通して、イチローは他のプレイヤーとの相対的な競争の中に身を置いているのではなく、絶えず自分を改良し続けるという過程の中にいるのだというのがよくわかる内容でした。良い番組だったと思います。 気づけば自分も 30 歳になりました。まだ若いとは思っていますが、さすがに 20 代の頃に比べると、病気や怪我の治りが少し遅くなったと感じることもあり、少しずつ自分の人生、「死」ということを考えるようにもなりました。時間は有限ということが少しずつ実感できるようになってきました。あるいは実感できるようになってしまった、と言った方が良いかもしれません。 ここ
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 のスリープを行
Perl で 8ビット CPU を作る - naoyaのはてなダイアリー
CPU を作る、と言ってもハードではなくソフト、仮想機械です。 2001 年から UNIX USER で連載されていた西田亙さんの「gccプログラミング工房」。いまさらながら、バックナンバーを取り寄せて初回から順番に読んでいます。とてもためになる連載です。 この連載中で第10回から数回に分けて開発されていた octopus という 8 ビット CPU の仮想機械があります。オリジナルは C 言語で書かれていたのですが、その設計を見て、これは他の言語でも作れるのではないか、と思い Perl に移植してみたところなんとか動作させることができました。以下の URL にコードを公開します。(西田さんに確認を取ったところ、オリジナルのソースは Public Domain とのことでした。オリジナルは http://www.skyfree.org/jpn/unixuser/ からダウンロード可能です。
さくらインターネット移行記#5 久しぶりの移転作業
だいぶ間が空いてしまいましたが、久しぶりのデータセンター移行記です。 アンテナ、カウンター、検索を移転 完全移行もぼちぼちゴールが見えて来た今日この頃ですが、先日もサーバーの移行作業を行いました。はてなアンテナの巡回システム周り一式、はてなカウンター、はてな検索などをまとめて移行しました。今回の移行も深夜作業。夜の 2:00 に集合して作業開始です。上の写真は僕のメンテナンス時の作業着です。 サーバールームからサーバーを運び出します。台車が大活躍です。 ぎっしりサーバーが詰まっていた旧サーバールームも、だいぶ閑散としてきました。まだ 70 台近くのサーバーが残っていますが、開発機などを除くと残り 40 台程度になりました。年内には全部移行できるのではないかと思います。 アンテナやカウンターともなるとはてなの中では古いサービスなので、使っているハードも古い。移転にあたって古いサーバーはハード
マルチスレッドのコンテキスト切り替えに伴うコスト - naoyaのはてなダイアリー
また Linux カーネルの話です。 Linux では fork によるマルチプロセスと、pthread によるマルチスレッドでの並行処理を比較した場合、後者の方がコストが低く高速と言われます。「スレッドはメモリ空間を共有するので、マルチプロセスとは異なりコンテキストスイッチ時にメモリ空間の切り替えを省略できる。切り替えに伴うオーバーヘッドが少ない。」というのが FAQ の答えかと思います。 が「オーバーヘッドが少ない」と一言にいわれても具体的にどういうことなのかがイメージできません。そこで Linux のスレッド周りの実装を見て見ようじゃないか、というのが今回のテーマです。 3分でわかる(?) マルチプロセスとマルチスレッド まずはうんちく。マルチプロセスとマルチスレッドの違いの図。以前に社内で勉強会をしたときに作った資料にちょうど良いのがあったので掲載します。Pthreadsプログラミ
x86 Linux のメモリモデル、プロセス空間切り替え、カーネルスタック - naoyaのはてなダイアリー
ひとつ前のエントリ id:naoya:20070924:1190653790 では Linux のコンテキストスイッチにおける、主にハードウェアコンテキストの退避/復帰の処理を追ってみました。その中で カーネルスタック (switch_to() 内で pushl %ebp とかして値が積まれるスタック)とはそのときの実行コンテキストに紐づくカーネルプロセススタックという理解でよいか。 という疑問がもやもや湧いて出てきました。ここ数日 はじめて読む486―32ビットコンピュータをやさしく語る を読んでいたのですが、その中にこの疑問への答えへの入り口が載っていまして、そこを糸口に調べてみました。で、結果としては 答え: 良い でした。 x86 は特権レベルの移行と連動してスタックポインタを切り替える仕組みを持っています。Linux の場合モードはカーネルモード(特権レベル0) とユーザーモード
ithreads でスレッドプール - naoyaのはてなダイアリー
マルチスレッドなサーバー実装を色々模索していて、Perl の ithreads で遊ぶ。ithreads は Linux の pthread にリンクさせた perl なら一応 NPTL で動いてくれるので、pthread アプリケーションの設計を試すのにも良い。 試しににやってみたのは、たとえば mod_perl とかで重い SQL でブロックするのが嫌なときとかにそれを別プロセスに丸投げしてやる、その丸投げされる側のサーバー実装。(やりたいことだけに関して言うと、TheSchwartz に似てる) クライアントとサーバーの IPC は UNIX ドメインソケット メッセージングのプロトコルは JSON サーバーはクライアントからのリクエストをバッファリングしたら、SQL を実行する前にクライアントとの接続を切断 この時点でクライアントは制御が戻る サーバーは内部ではフロントエンド /
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
YAPC::Asia 2009 1日目 「Perlで圧縮」の資料 - naoyaのはてなダイアリー
YAPC::Asia 2日目 「はてなブックマークのシステムについて」 - naoyaのはてなダイアリー
