トップ «前の日(06-14) 最新 次の日(06-16)» 追記

2003-06-15

_ Mac を通じてブラウザを考えよう、、、かな

http://slashdot.jp/comments.pl?sid=100863&cid=337894

ははぁ、なるほど。たまにこういう意見が出ると非常に参考になる。

Mac プラットフォームからデベロッパを締め出しているのはApple ではなくユーザーだと。そう言われればそういうとこ、けっこうあるかもしんないなぁ。

それとは別に msn for OS X の出現で、Microsoft は AOL と同じ方向を向いていて、Apple や Mozilla コミュニティとは正反対に向かっているような気がしている。

ユーザーが望んでいるのはブラウザなのか、統一的なインターネットプラットフォームなのか。

Tags: Tool Web

2004-06-15

_ ck と IP Messenger の話

ck は掲示板へ、IP Messenger は ML へそれぞれ要望を提出。

Tags: 日々

_ 「転職時減収やむなし」で欧米化だ?

転職時に「減収やむを得ず」、労働意識も欧米化のきざし

就業の安定性が低下しただけで、中途入社の敷居の高さや周囲の環境・文化が変わったわけではない。職を移ることへの無用のストレスが日本には潜在的にたくさん存在していることを抜きにして欧米化などと軽々しく言うべきではないだろう。

もう一つ、収入の水準が下がる一方で日本は世界一物価の高い国だということも忘れてはならない。日本人の生活水準は落ちる一方やんけ。ただでさえ家も持てず、持てても「うさぎ小屋」だった日本の生活水準がですよ。

国は分かっとんのかと。

Tags: Biz

_ ソーシャルネットワーキングネタ

そろそろチェックせなあかんかなぁ。

ソーシャルネットワーキング(social networking)整理。3/9

blog もそうだったけど、あんまり興味涌かないんだよな。特に blog はコンテンツが増えていくことに期待できるけど、日本では「面白そうなテーマに本格的にコミットしてる人間の数なんてたかが知れてる」ので、そんなに必要性がないというかなんというか、、、まぁその人がちゃんとしたサイトを用意してなくてもその人の興味、活動をチェックできるって意味ではよいのかなぁ。Web のおかげで細かい情報は拾いやすくなったけど、逆に Web に乗らない情報との流通速度、伝搬範囲の差がものすごくでかくなってるよな。

Web にそれほど興味のない人ほど blog ツール使ってくれ、ってことやろか。

Tags: Net Tool

_ CUI なメーラ

自分のマシンを持ち込んだときに職場のデスクトップからメールの情報を取り出しにくいので、Unix の CUI 上で完結するメール環境を作ろうかなと思い立つ。(いや以前から気にはなっていたが。)

  • cmail
    • あのまつもとゆきひろ氏の噛んだプロジェクト。Emacs 上で動作。フォルダの説明のところで言葉が揺れているので、結局1メール1ファイルなのかどうかは不明。できれば検索性などを考えると富豪的に1メール1ファイルであってほしいが。
  • vm-Emacs
    • これも Emacs 上で動く
  • Mew
    • Win32 バイナリもあるな。
  • MH Message Handler
  • mh-plus project
    • 今さら使おうと思っているわけではないが、どんなものなのかは知っておきたい。
  • nmh New Message Handler
    • mh improved ?
  • mutt
  • Cone
    • おや courier にこんなものが。
  • elmo
    • クッキー食べますか?
Tags: Tool

_ Mozilla Firefox 0.9

Alt 問題は解決していた。スピードは、Firefox を常用していないので比較できない。

相変わらず設定のダイアログがモーダルで Cookie Manager を見ながらブラウザを動かすことができない、Web 開発的にはダメダメな仕上がりになってますが。これって cookie 周りの動作を確認したければ別な extension を入れろってことか?

Tags: Web Tool

2006-06-15

_ システムファイルを避けるために別のシステムからデフラグ掛けたらダメなの?

先づ隗より始めよ。*1

つーことで昨日の失敗の話。

昨日、Windows のシステムの入ったドライブに対して、最大限の効果が発揮されるデフラグだぁということで別のシステムから立ち上げてデフラグを試みた。

結果、壊れた。

(ただし、未使用なので被害はゼロね。各種セットアップをしたあとでデフラグしたってだけ。もちろん丸ごとコピーも取ってある。2台のディスクで試してどっちもダメだったのでたまたまってことはないと思う。)

ファイルシステムに矛盾が見つかるらしく、起動もできない。調べてみると

のような情報は見つかるが、いずれも別なシステムから立ち上げてシステム入りのドライブをデフラグするという挑戦的な内容は触れられていない。触れられていないのでダメなのかどうかも分からないんだけど、やっぱダメなんですよね。Excel を方眼紙みたいに使うような変な裏技開発してないで売り物を使えということでしょうか。

えー現段階での自分の推測を書いておきます。

  • Windows のシステムには MFT, ページングファイルなどシステムのロックするファイルがあり、これは標準のデフラグでは最適化できない。
  • ロックしないように別のシステムからデフラグを掛けてみたわけだけど、これにはまず前提があって、ページングファイルは別に壊れても作り直せるだろうし、まったく起動しないってことはなかろうと思っていた。
  • MFT は本当に最初のセットアップ後なので断片化が見つかって最適化されて壊れるということはちょっと考えにくい。
  • ちゅーことは何かまだ自分の知らない謎の領域をデフラグでぶち壊してしまったんだろうか?

壊れた状況は

  • デフラグ終了直後からデフラグツールでディスクのレポートを正常に生成できない
  • chkdsk で不明なエラー
  • 何やらファイルシステムに矛盾があると言われる
  • 起動できない*2

です。

起動できないだけならまだ分かるんだけど、ファイルシステムに矛盾つーのが分からないんだよなぁ。データだけのドライブでは矛盾は起きないのにシステムの入ったドライブだと矛盾が起きるの? まぁ Windows の出すエラーメッセージを真に受けて悩みすぎるのもよくないんだけど。

以下、言い訳。なんでデフラグにこだわったかというと、sysprep の話にまた戻るんですが、sysprep で展開するシステムのマスタイメージを DVD に保存しようと思ったの。ディスク丸ごとでもセットアップ直後ならほとんどは空き領域だし、圧縮すれば焼けるだろう、と。*3ついでにデフラグも掛けておけば圧縮率も上がるし、そうだ、システムファイルなんかもデフラグできたらいいじゃーんと思ったと、こういうわけです。

さらに言い訳。実際には、これは自分のアイディアじゃないです。正直イヤな予感はしてたので。ただ実行に移したのは自分です。

今のところの結論。

システムの入ったドライブはそのシステムで起動してデフラグを掛けろ。最大限の効果が欲しければ売り物のデフラグソフトを使え。

Tags: MS Disk

*1 なんか意味が違うような。ただの言い出しっぺの法則だよな、これ。

*2 エラーメッセージはメモするの忘れました、ごめんなさい。

*3 遊んでる HDD がないというのが根本的な理由。


2008-06-15

_ RDoc::usage がやっぱりあった。けど。

先日 pragger を眺めていて

またドキュメントのためにコードを丸ごと文字列で持つのは RD とか RDoc をうまく使えば避けられるんじゃないかと思ったけど、よく分かんないorz

なんてことを書いていたけど Pod と同じ発想で探したらあった。

require 'rdoc/usage'
RDoc::usage( [[STATUS,] SECTION_NAME, ...] )

するだけで、起動したスクリプトに書かれている RDoc コメントを表示することができる。

んが。

この rdoc/usage.rb の中身を見ると、gets( file ) 以降は private なので任意のファイルの usage を生成することはできないようになっている。うーむ。まぁ RDoc module をゴニョゴニョして plugin の usage を表示させる方法もなくはないけど、そこまでコスト掛けるなら現状の pragger のように妥協案として

## コメント

行を抽出して表示するってのはアリなのかもなぁ。現状でも一応 rdoc コマンドでドキュメントを生成することはできるんだし。

Tags: Ruby Pragger

2013-06-15

_ Kanazawa.rb meetup #10に飛び入りしてまたノースライドで喋ってきた

今回は実は以前から分かっていた個人的な事情とさらにやんごとなき事情が重なって、準備の手伝いもしてないし、不参加を最初から決めていたんだけど、どうもこれは企画の重さで大変なことになってないかな?と思い、無理矢理 meetup だけ 参加表明せずに参加してきた。

そう、つまり飲んでないのです。ビールクズの名折れ…。

そこで

  1. Git入門
  2. GitHub入門
  3. Pull-req入門

の話があったんですが、どうもこの 3 の pull-req の話の前に branch の話がこなれてなくて、branch, clone, fork, push, rebase, merge の話がやや渾然一体となった感じで受け止められている気がしたので、以下のような話を飛び入りでしました。

そして以下のような話を。

  • 「branch の正体を知るといいよ」「branch は commit の alias なんだよ!」「???」「branch は名前を付けた何かの commit、その commit に次の commit を重ねれば名前の指す先が変わる」「だから pull-req 用の branch を作って放置するのがベストプラクティス」

結局は Pro Git のこの話

Git - ブランチとは

なんですが。

で、atomic commit の話を少々。

  • 「”明日の自分”を含む他人が読んで分かることが大事」「読みやすく分かりやすい commit こそ受け入れられやすい。pull-req の話は結局それ」
  • 「branch って大げさに聞こえるけど git の (local)branch はとてもお手軽で便利」「だから”あれもこれも branch をうまく使えば実現できるよね?”と気づいたコミュニティのノウハウが多い」
  • 「”今からやる作業の名前を付けた branch”を作るという習慣」「余計な commit を入れにくくなる」「大きな commit は扱いにくい。小さく」

てな感じ。

Kanazawa.rb でがっつり Git の話をしたのは初めてで、今までにない面白さだった。普段から commit 単位とか branch の運用(これは学習機会など様々な要因で考え方が変わる)とか頭を悩ませているので、ここぞとばかりに喋ることができて

個人的には面白かった

んだけど、ちゃんとウケたのかどうか、そう言えばあんまり気にしてなかった…。

どうもすいません、またリベンジしましょう。