SBM研究会で発表した"私がチャレンジしたSBMデータマイニング"のスライド - Ryoの開発日記 Neo!
SBM研究会で"私がチャレンジしたSBMデータマイニング"という発表を行いましたが、そのスライドを置いておきます。 ・[2008/7/21 22:43 version final] ・http://www.slideshare.net/rawwell/sbm-presentation #リンク切れしていたので、どなたかがSlideshareにアップしたものにリンクw Change Logs ・2010/8/23 リンク切れを解決 ・2008/7/21 22:43 version final 初版の2倍以上にスライドを増やした。また、"個人による高性能データマイニング"の話を追加した。 ・2008/7/16 23:45 version 1.1 TF-IDFの説明が間違っているとの指摘を受け、説明部分を修正 ・2008/7/12 23:53 version 1 公開 SBM研究会の体験記
Emacsの設定ファイル晒し - Ryoの開発日記 Neo!
やってみる。 .emacs (setq load-path (cons "~/emacs-lisp/" load-path)) ;show recent used files (recentf-mode) ;alias for dabbrev-expand (global-set-key "\C-\\" 'dabbrev-expand ) ;; for coding (global-set-key "\C-ci" 'comment-region) (global-set-key "\C-co" 'uncomment-region) (global-set-key "\C-l" 'goto-line) ;; syntax highlight of corresponding brackets (show-paren-mode t) ;; show function name where no
Ryoの開発日記 Neo!
分散システムに明るいと自称している私なので、Nostr *1なアプリケーション（ここではマイクロブログ型SNSとする）をスケール可能（全体のユーザ数が増加しても使えるものであり続ける）にするためにはどうすればよいかと、思考実験レベルで考えてみている。 これならいける！というところにはたどり着いていないけれど、アイデアとか、糸口になるかなーみたいな気づきはあったのでここに記す。 Nostrの特徴として維持されないといけないこと 大事。 中央集権的なサーバに頼らない リレーサーバは気軽に建てられて運営をやめてもユーザに迷惑がかからない （ボランティアベースになるというところはひとまず仕方がない、ということにしておく） リレーサーバに要求されるマシンスペックや通信リソースがべらぼうな量にならない クライアントはそれなりに遅延なくデータを取得できる （ピュアP2Pなアーキ等だと遅くなりがちであると
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
クラウド時代の分散マシン操作ライブラリ Svengali - インストール - Ryoの開発日記 Neo!
