nDiki : 社内 Blog
2006年6月10日 (土)
Plagger のインストールが大変なので XML::RSS で RSS から JavaScript コードへ変換するスクリプトを自作
一昨日社内メイン Wiki のレイアウトを変更してサイドバーを設けたので、徐々に増えてきた社内 Blog の ヘッドラインをそこに表示することにした。
最初は Plagger を使ってみようと思ったのだが、依存 CPAN モジュールが多くて CPAN.pm を使ってもなかなかインストールが終わらない。
ということで今回は Plagger を見送って、XML::RSS でちょちょっと aggregator を自作して済ますことにした。
基本的には nDiki 用に書いた「はてなブックマーク上の最新ブックマークを表示するためのコード(2005年5月16日)」をちょっと修正して利用。 HTML フラグメントを生成するかわりに、JavaScript Include 用 JavaScript ファイルを生成するように変更した。
これで社内 Blog が読まれる回数も増えるかな。
2006年7月22日 (土)
Rubric でプライベート SBS を立てるも 0.140 では日本語に不具合
入社してから社内情報共有の一環として
といろいろ手をつけてきた。 次に狙っているのは SBS である。
Wiki や社内 Blog に書くほどではないけれどメモ程度にブックマークしておきたい URL を、気軽に晒せるようにするのが目的。
はてなブックマークのような公開サービスは
- タグ・コメント・傾向などが外に出るのはよろしくない
- あるいは、それを気にして活用されない
- そもそも社内リソースについてはブックマークできない
という点から、今回は利用できない。
ということで社内に SBS を設置したい考えている。
最初は Scuttle にしてみようと思ったのだが、PHP ベースであるのと MySQL を使うというところで気遅れしている。 いや SQLite でもいけそうらしいということで、実は Debian でちょっと試そうとしたのだが、テーブル作成の SQL が MySQL 用で、これを修正するのが面倒なので断念。
次に Perl + SQLite で動く Rubric を試してみることにした。
Rubric 0.140
Rubric は CPAN にあがっているので CPAN.pm から install Rubric でインストールできる。 モジュールをインストールしたら、セットアップ。
- CGI プログラムを動かすディレクトリを決める (以下 $RUBRIC)
- Rubric tarball の bin/rubric.cgi を $RUBRIC/ にコピーし、必要なら #! を修正する。
- Rubric tarball の templates ディレクトリを $RUBRIC/ にコピーする。
- Rubric tarball の style/rubric.css を $RUBRIC/ にコピーする。
- Rubric tarball の etc/rubric.yml を $RUBRIC/ にコピーして環境に合わせて編集する。
- データベースを初期化する。0.140 には makedb.pl が同梱されていないので、0.13_01 の bin/makedb.pl を参考に perl -MRubric::DBI::Setup -e 'Rubric::DBI::Setup->setup_tables' で初期化する。ちなみに 0.140 付属の rubric コマンドで rubric db -s してみたが、これはうまく動かなかった。
- 必要に応じて .htaccess を作成・編集し rubric.cgi を CGI プログラムとして実行できるようにする。またその他アクセスされたくないファイルを deny するようにしておく。
これで OK。
rubric.cgi にアクセスしページが表示されればひとまず成功。 メニューの「register」から、ユーザ登録する。 確認用のメールが届くはずだが、面倒くさいのでこれを待たずに
rubric user -a ユーザ名
でアクティベートする。
Rubric の HTML フォームからのブックマーキングは成功し、うまく動いているようである。 ただし、日本語の処理はどうもよくない。 title や description が化ける。 惜しい。
基本的には UTF-8 ベースでうまくいきそうなのだが、どこかで化けるようだ。 ちょっと手を入れれば直るかなと思ったが、化けるところと化けないところとがあるので逆に直す場所が多そうなので今日はやめておくことにした。
とりあえず Rubric はおいておいて、他のものも試してみることにするか。
2006年7月26日 (水)
私が情報発信を勧める理由
「社内 Blog」をまわりのスタッフに勧めているのだけれど、
と様々だ。
話を聞いているなかで、情報発信のメリットやポイントについて自分でも整理してみたくなったので思うところを列挙してみた。
- あなたが発信すれば、あなたにも発信してくれる。
- 発信のための「とりまとめ」や「書き出す」という作業は、自分の中での理解を深めることにつながる。
- 迅速に。情報の多くは時間とともに価値が下がる。
- 送り手ではなく受け手が選別する。
- 「受け手は知っているはずだから」と遠慮しない。実は知らないということも多い。
- Web ページ・Wiki・Blog・あるいは張り出しなど、うまくメディアを選ぶ。
- 情報発信そのものよりも、その情報でいろいろな事が良くなること(生産性の向上など)が重要。
すぐに思い受かんだ点はこんなところ。
どれもすでにいろいろな人に語られているようなものであり、やってみれば実感できるものである。
人のためのようで、一番自分のためだったりするのが情報発信。
2006年8月8日 (火)
Linux で使えるデスクトップ検索ツール Beagle でローカルファイルを検索
Windows だと Google Desktop でローカルファイルの検索ができるのだが、残念ながら Linux 版はでていない。 そこで Beagle を入れてみることにした。
Beagle はデーモン形式のバックエンドと、検索インタフェースであるフロンエンドに分かれたているデスクトップ検索ツールである。
ファイルシステム上にあるテキストファイルだけでなくメールや、Firefox でアクセスしたページ、OpenOffice.org や Microsoft Office のファイルなどをインデックス化し検索できるようにすることができるらしい。
ちなみに今まで
ローカルファイルの検索は
| メール | Mew 4 での検索(with Namazu)。 |
| nDiki 記事 | howm で記事ソースデータを検索 (方法)、あるいは www.naney.org 公開記事を Google で。 |
| メモ | howm。 |
| 開発中のソースコード | Emacs の grep-find でだいたい事足りる。たまに ack。 |
| 仕事のメモ | できるだけ社内 Wiki か社内 Blog に書いておいて Hyper Estraier。 |
| その他 | grep 程度。 |
といった感じかな。
それ以外はだいたいファイルの位置をうろ覚えしているので、何カ所か探せば見つかることが多い。
問題はうろ覚えの場所になかった時。 その時はなかなか見つからない。
そんなファイルを見つけるのが楽になれば、導入効果あり。
インストールして試してみる
Linux kernel の inotify を有効にする
まずは Linux kernel の設定を確認。inotify が有効になっている方が良いらしい。 この間ビルドした時の .config を見て
CONFIG_INOTIFY=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT3_FS_XATTR=y
となっていることを確認。
/home の extended attributes を有効にする。
/etc/fstab を編集し、
/dev/hda4 /home ext3 defaults 0 2
を
/dev/hda4 /home ext3 defaults,user_xattr 0 2
に変更する。書き換えたら、
mount -o remount /home
でマウントしなおす。
Beagle のインストール
Beagle を起動
一般ユーザで
beagled
で起動する。停止は
beagle-shutdown
で。
Beagle を設定
beagle-settings
で設定 UI を起動し、インデックスに含めたくないディレクトリなどを設定。
検索してみる
beagle-search
で検索 UI を起動し検索してみる。 日本語も OK のようである。
GNOME 環境をほとんどインストールしていなかったので、検索結果からファイルを開けずつまらなかたので gonome-control-center、gnome-panel あたりをインストールして環境設定等をしてみた。
Firefox 拡張
xpi ファイルを入れておく。 後は普通に閲覧したページが、Beagle でインデックス化されて検索できるようになる。
設定してしまえば、以前開発して使っていた WWWOFFLE + Namazu よりお手軽である。
感想
デーモンが逐次インデックス化していくので、明示的定期的にインデクサを走らせなくていいというのは楽でいい。
日本語関連がどの程度うまく検索できるのか、検索結果は使いやすい順に出力されるのかが未知数。 しばらく遊んでみて便利かどうか確かめてみたい。
2006年8月25日 (金)
社内 Blog をテーマ別に分けるべきか?
会社で
「テーマ別に社内 Blog を分けるべきか?」
という質問をもらった。
私の意見としては、ほとんどの場合分けるべきではないと思う。
- 分けると閲覧者が巡回する負担が増える (RSS リーダ活用などが浸透していない現状で)
- 各 Blog の更新頻度が下がる
- そのテーマが終了した時に、その Blog がメンテナンスされなくなる → 忘れられる → 蓄積された情報が目に触れる機会が減る
- そのテーマが終了した時に、その Blog がメンテナンスされなくなる → メンテナンスされていない Blog が一つ増える → 社内 Blog が活用されていないという印象が広まる
Blog 分けてそれぞれをきちんと更新していくのは、結構な手間と時間がかかるものだ。
たいがいの場合 Blog のカテゴリ機能やタギング機能を使うことで十分整理でき、その方が効果的に運用できると思う。
2007年1月8日 (月)
iCalendar 形式経由でスケジュールを社内 Blog に表示
仕事用に Skype 名を作成し、ついでに社内 Blog に Skype ボタンを貼りつけてログイン状態を表示できるようにしてみた。
そういえば電話もそうなんだけれど、本社に連絡を取るとき「もしかして会議中?」などと勘繰ってかけるかどうか迷ってしまうことがある。 かけたい人の予定がわかればいいのになと。
ならば逆もしかりだろうということで、自分の仕事のスケジュールを晒してみようと思いついた。 グループウェアとかそういうのは大袈裟なので、まずは社内 Blog のサイドバーに表示するようにしたい。
構成
入力
完全なスケジュールはほぼ日手帳に手書きで管理しているので、ミーティング・外出など晒しカテゴリのイベントだけを、電子化する必要がある。 手で HTML 毎回ごりごり書き直すのも嫌なので、スケジュール管理ソフトを使いたい。 この部分は KDE の KOrganizer を使うことにした。
サーバへアップロード
で、KOrganizer のスケジュールを iCalendar 形式でエクスポート。 このファイルを社内 Blog を配信しているサーバに rsync で転送。
この処理はちょっと手間なので自動化したいところ。
社内 Blog 内表示用 JavaScript Include ファイル生成 CGI プログラム
この iCalendar 形式ファイルを読み込んで、今日以降の10件(程度)を HTML フラグメントに変換し JavaScript プログラム (document.write() 列) として出力する Perl CGI プログラムを作成。
iCalendar の形式の読み込みについては Data::ICal や iCal::Paraser などの Perl モジュールを利用できる。 今回はシンプルに使えそうな iCal::Parser をチョイス。 基本的には
use iCal::Parser; my $parser = iCal::Parser->new; my $calendar = $parser->parse($ics_file_name);
で読み込んだデータがハッシュリファレンスとして $calendar に設定される。 イベントは $calendar->{2007}->{01}->{01}->{$uid} のように「年、月、日、イベントUID」のハッシュ階層として格納されているので、これを読み出せばよい。
社内 Blog サイドバーに表示
で、この CGI プログラムが生成する JavaScript プログラムをサイドバーで JavaScript Include。
まずは表示までできるようになった。
これで
おいおいスケジュールの表示デザインとかは改良していきたい。 hCalendar 形式にして CSS でデザインするのがいいのかな。
2007年1月11日 (木)
週次レポートは社内 Blog には邪魔
去年の11月から会社で、電子化した週次レポートをベースに週次定例ミーティングを行うようになった。 それにあわせて、書いた週次レポートを DiKicker で立てている 社内 Blog に毎週載せておいたのだが、これが思ったよりよろしくない。
DiKicker でキーワード串刺し表示を行うと、これらの週次レポートが記事リストに毎度のように沢山表示されてしまうのである。 自分が担当している各プロジェクトの1週間の成果・進捗報告なので当然各プロジェクトのキーワードを使って文が書かれているわけで、キーワードで一覧表示すると大概ひっかかってしまうというワケ。
週次レポートはその他のプロジェクトの情報も浅く広く書かれているから、串刺しで見るには邪魔なのである。肝心のキーワードに関する情報も、週次レポートという要約記事の前に別途詳細の記事があることも多いし。
ということでとりあえず週次レポート専用に社内 Blog を作って、それらの記事はひとまとめにしておくことにした。 社内 Blog にしておいて役立つかどうかちょっと様子見。
2013年4月2日 (火)
【日記】下から改善する戦略
珍しくまとまってコードを書いたり、あとはもりもり文章書いてたりで1日経ったので若干ネタ不足。20%は Web 日記に書くネタ作りに精を出したいね。
新卒2年目のエンジニアが社内 Blog で提言していてグッジョブだった。次はそこからどう広げていくかか。Joel on Software の「下っ端でも何かを成し遂げる方法」的に下から改善する戦略をとるのが一つの方法かなぁ、やっぱり。というかどのポジションにいても多くの場合やはり「実行あるのみ」「じわじわと広めていく」がやれることなんだと思う。
2015年5月13日 (水)
レクサー・リサーチ開発同窓会
2月の Developers Summit 2015 で zakwa 氏と再会したのをきっかけに、当時一緒に仕事をしていた気が置けないソフトウェア開発者4人で同窓会をすることになった。セッティングしてくれた zakwa 氏ありがとう!
COGS DINING KAGURAZAKA (コグス ダイニング 神楽坂)
手配してくれたお店は「焼きたてパンとワインのお店」COGS DINING KAGURAZAKA。神楽坂から路地に入ったところにあるお店で、上品な味の料理で満足だった。店内もうるさくなくて話しやすかったし、たばこを吸っている人もいなかったので快適だった。
ソフトウェア開発
現職のまま続けている1人と、別の場所で働くことになった3人だけれどみなそれぞれソフトウェア開発現場に関わっていて、それぞれの開発スタイルなどについて情報交換したり。
大企業だからしっかりした開発をしているとか、スタートアップだからモダンな開発をしているとかでは必ずしも無いよねという話だった。例えばバージョン管理一つにしてもうまくできていない(やっていない)場合も多いとのこと。当時を振り返ってみると小規模かつ独学の状況ながら、今では普通になってきたプラクティスやツールをその時から実践/活用していたなと自画自賛した。
- プロジェクト
- ソフトウェアかんばん
- ITS (影舞・Redmine) の利用
- BTS やコミットメント・リストとして。
- スタンドアップでの朝会
- すごい会議
- 成果物完成毎の記念撮影
- 情報共有
- 開発ツール
- バージョン管理 (CVS・Subversion・Git)
- pLaTeX2e を使ったドキュメンテーション
- その他
- 書けなくなったホワイトボードマーカーはその場で床に投げ捨て
「書けなくなったホワイトボードマーカーはその場で床に投げ捨て」に共感を持ってもらえていたのが、振り返って当時の自分の一番の成果だな。
退職時に使っていた社内 Wiki は Naney 謹製のものだったのでその後どうなったのかなとたまに気になっていたのだけれど、ビル管理会社の人に社内サーバの電源を切られたことによりサーバごと死んで闇に葬られたらしい。R.I.P.
その他
同窓会らしく「あのひとは今」的な話をしたり、当時フィルムカメラで撮っていた業務風景のアルバムを持ってきて盛り上がったり。あとはレーシックやドライアイ治療ひぇー的な話題が出たり。あとは展示会の時のレクサー・リサーチポロシャツ制作秘話とか。
そういえば出席はできなかった2013年2月開催の「LEXER設立20周年記念サロン・パーティ」で会社のるぐるロゴの立体置物が配られたと聞いて、あ、欲しかったなーと。
About Me
Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。
nDiki は1999年1月に始めたコンピュータ日誌を前身とする Naney の Web 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。
※内容は個人的見解であり所属組織とは関係ありません。
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker