WebOS Goodies へようこそ！ WebOS はインターネットの未来形。あらゆる Web サイトが繋がり、共有し、協力して創り上げる、ひとつの巨大な情報システムです。そこでは、あらゆる情報がネットワーク上に蓄積され、我々はいつでも、どこからでも、多彩なデバイスを使ってそれらにアクセスできます。 WebOS Goodies は、さまざまな情報提供やツール開発を通して、そんな世界の実現に少しでも貢献するべく活動していきます。 最近、 Infosketch の開発などで rsync を利用する機会が増えてきました。 rsync はネットワーク経由のコピーも可能なファイル・ディレクトリ同期ツールで、コマンドひとつでディレクトリツリーを一気に転送できるほか、差分のみの転送やコピー対象の条件指定といった多彩な機能を搭載しています。 rsync という名前に反してローカル間のコピーも可能で、 m

基本形 rsync -av -e "ssh" [myDir] [remoteServer]:[remoteFile] SSHのポート変更 rsync -av -e "ssh -p 7022" [myDir] [remoteServer]:[remoteFile] 除外ファイル指定 rsync -av -e "ssh -p 7022" --exclude="*.tar.gz" [myDir] [remoteServer]:[remoteFile] 除外ファイル指定（外部ファイル指定） rsync -av -e "ssh -p 7022" --exclude-from=[exclude-file] [myDir] [remoteServer]:[remoteFile] [exclude-file]2階層以上の除外フォルダ指定をする場合は、パスの先頭から記述します。 _svn/ *.tar.gz

Local側とServer側で証明書を持ち、その用途を限定することでパスワード入力無しで特定コマンドを受け付けるようになる。 Local側で鍵ペアを作る。 Server側のauthorized_keyに公開鍵を追加する。 Server側のsshd_configを修正する。 Local側のrsyncスクリプトにおいて、鍵を使うように設定変更する。 Local側で鍵ペアを作る # ssh-keygen -t rsa -f rsync1 ※この際、パスフレーズは入力しないこと。 Server側のauthorized_keyに公開鍵を追加する SCP等を使って、(1)で生成した鍵ペアのうち公開鍵の方をServer側の /root/.ssh に置く。 # cd /root/.ssh # cat rsync1 >> authorized_keys /root/.ssh/authorized_keys

まあ、この辺は普通に。たいていは既にインストール済みのはず。 # yum install rsync openssh-server openssh-clients vixie-cron # service sshd start パスフレーズを入れずに作成します。 秘密鍵は ~/.ssh/id_rsa 公開鍵は ~/.ssh/id_rsa.pub にそれぞれ保存されます。 $ ssh-keygen -t rsa Generatingpublic/private rsa key pair. Enter file in which to save the key (/home/testuser/.ssh/id_rsa): Created directory '/home/testuser/.ssh'.Enter passphrase (empty for no passphrase): Ente

TODOリストを愛用している。 1日の作業を書き込んでいって、終わったらチェックして消してゆく。消す瞬間はちょっとした達成感である。テトリスでブロックを消すときのような爽快感がある。 どうせなら本当にゲームのように派手なクリア画面があったほうがよりカタルシスを得られるのではないか。 派手なクリア画面付きでモチベーションがあがるTODOリストを作ってみたい。

祭りと工事現場は似てると思う。 いきなりそんなこと言われても理解しにくいかもしれない。 たしかにその二つはまったく異なるものだ。 しかし祭りを彩る赤提灯と工事現場で赤く光るパイロンは意外なほどよく似ている。 あとはもう一つ祭り的要素があれば完全に祭りになるのではないか。 工事現場で踊ってみた。

Test, Objective-C, iPad, iPhone(iOSのテストを書くとViewControllerがコントローラーになれる話 - yaakaito::Blog を先に見ておくと、何がやりたいか分かり易いかもしれません。)iOSアプリケーションのテストの書き方、難しいですよね。僕もよく分からないので手探り状態です。とりあえず、標準のOCUnit使ってTDDっぽいことしてみれば、何か叩き台になるかな？と思ったのでその過程を公開してみます。書くテストロジックテストだけです。後々アプリケーションテストもやる予定なのですが、というか一緒にやってたんですが、重すぎたので一旦ロジックテストだけです。ロジックテスト主体で書けるようにできる限りViewContollerと切り離してコードを考えています。ツッコミ大歓迎！(ロジックテストだけやるので、ビューに表示するところまで書いてません)リク

rsync についてかなり深く調べる機会があったので、そのまとめです。この記事を書いている時点の最新版は 3.0.7 で、すでに 3.0.8pre1 が出ています。 Red Hat Enterprise Linux 5.x (CentOS5 )に付属しているのは 2.6.8 です。 2系と3系での違いとして、2系では差分比較がすべて終わってからファイルの転送が開始されていましたが、3系ではファイルの差分比較をしながら並行してファイル転送されるようになっています。 転送元、転送先ともに rsync コマンドがインストールされている必要があります。ファイルを取ってくることも、送ることもできます。 基本的なオプション rsync -acvz -e ssh --delete server1:/var/log/hoge/ /var/backup/log/hoge/ server1 の /var/lo

独創的発想で活躍している若手エンジニアを探し出して紹介するこのシリーズ！今回登場するのは、日本初のSNSサービスで今や、1110万人を超えるユーザーを有する『mixi』で、膨大なコンテンツの検索システムを自社開発した研究開発グループの若手マネージャーだ。 1978年生まれ。立命館大学政策科学部を卒業後、01年に大手OA機器メーカーに入社。システムエンジニアに。独立行政法人情報処理推進機構(IPA)の2004年度第2回未踏ソフトウェア創造事業で、全文検索システム「Hyper Estraier」を開発、スーパークリエータに認定される。2006年6月、ミクシィ入社。研究開発に従事。 株式会社ミクシィ 2004年2月から日本初のSNS（ソーシャル・ネットワーキングサービス）として『mixi』を展開。「居心地の良いサイト」「身近な人や趣味・興味が同じ人との交流」をコンセプトに開発、人気を集め、今や1

最強最速アルゴリズマー養成講座： そのアルゴリズム、貪欲につき――貪欲法のススメ アルゴリズムの世界において、欲張りであることはときに有利に働くことがあります。今回は、貪欲法と呼ばれるアルゴリズムを紹介しながら、ハードな問題に挑戦してみましょう。このアルゴリズムが使えるかどうかの見極めができるようになれば、あなたの論理的思考力はかなりのレベルなのです。（2010/9/4） 最強最速アルゴリズマー養成講座： 病みつきになる「動的計画法」、その深淵に迫る 数回にわたって動的計画法・メモ化再帰について解説してきましたが、今回は実践編として、ナップサック問題への挑戦を足がかりに、その長所と短所の紹介、理解度チェックシートなどを用意しました。特に、動的計画法について深く掘り下げ、皆さんを動的計画法マスターの道にご案内します。（2010/5/15） 最強最速アルゴリズマー養成講座： アルゴリズマーの登

浸透いうな(その3):まずいNS設定 この状況で「浸透」はおこりますか? SMALL-IS-BEAUTIFUL.JPでは、現在、NSのひとつが ftp.small-is-beautiful.jp 、そしてもうひとつ外部のセカンダリ ns.internot.jp を利用しているとします。そして、新しいDNSサーバ ns.example.jp に引越しをしたいと考えているとしましょう。ありがちな状況ですね。 今、これまでのDNSサーバに旧来の設定を残したまま、上位レジストリ(ここではJP)への Name Server の登録をたとえば ns.example.jp に変更したとしましょう。さて、世界中のDNSキャッシュは ns.example.jp へうまく切り替わってくれるでしょうか。 以下に古いキャッシュをもった、あるDNSキャッシュサーバ(127.0.0.2)の様子を再現してみました。 最

そもそもDNSの設定がうまく変更できたかどうかをうまく確認できていない人をよくみかけます。設定の確認には、DNSの仕組みを知り、「再帰検索要求」と「非再帰検索要求」をうまく使い分ける必要があります。 コンテンツサーバの設定確認 「非再帰検索要求」でNSとなっているサーバの設定を個別に確認しましょう。こんな感じ、、、 委譲元の確認(djbdnsのツール推奨) % dnsq ns e-ontap.com a.gtld-servers.net(できるだけIPアドレスで) 2 e-ontap.com: 130 bytes, 1+0+3+3 records, response, noerror query: 2 e-ontap.com authority: e-ontap.com 172800 NS ns.e-ontap.com authority: e-ontap.com 172800 NS ns