*ペッパーランチ [#geaf0458] -書評 -まちBBS検証 -小さい事件は扱わない警察 -振り込め詐欺が解決できない警察 -告発サイト検証 -女性を守る録音サーバ http://www.nanbu.com/wiki/index.php?blog%A5%CD%A5%BF [ ト -クラスタサーバ -Winnyは武器になるのか -シェルターは安全か? -船は治外法権 −フェミの沈黙 −公開するのは被害者のため -ワゴン車拉致の歴史 -知は力 - *crackされたxoopsサーバ [#m6229118] 旧いRedHat。 サーバ *Ubuntu Server First Impression [#wc093a6b] インストール画面がかっこいい。LAMPサーバインストール インストール画面はOKが無い。このまま進んでいくといいのだが、 一端デフォルトから外れると迷子になってしまう。 インストールするとCUI画面が立ち上がる。 まずはapt-get 画面がこの通り。 sudo apt-get install ssh /etc/init.d/ssh start その他入れたもの sudo apt-get install postgresql-8.1 postgresql-client-8.1 php5-pgsql nanbuwks@evodevo:~$ sudo apt-get install postgresql-8.1 postgresql-client-8.1 php5-pgsql パッケージリストを読み込んでいます... 完了 依存関係ツリーを作成しています... 完了 以下の特別パッケージがインストールされます: libpq4 postgresql-client-common postgresql-common 提案パッケージ: oidentd ident-server postgresql-doc-8.1 以下のパッケージが新たにインストールされます: libpq4 php5-pgsql postgresql-8.1 postgresql-client-8.1 postgresql-client-common postgresql-common アップグレード: 0 個、新規インストール: 6 個、削除: 0 個、保留: 1 個。 4117kB 中 3999kB のアーカイブを取得する必要があります。 展開後に追加で 18.6MB のディスク容量が消費されます。 続行しますか [Y/n]? y メディア変更: 'Ubuntu-Server 6.06.1 _Dapper Drake_ - Release i386 (20060807.1)' とラベルの付いたディスクをドライブ '/cdrom/' に入れて enter を押してください なんで??!!! *SATA [#yfef475b] /dev/sdb1 1 48641 390708801 83 Linux root@ttyp1[knoppix]# mkfs.ext3 /dev/sdb1 mke2fs 1.35 (28-Feb-2004) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 48840704 inodes, 97677200 blocks 4883860 blocks (5.00%) reserved for the super user First data block=0 2981 block groups 32768 blocks per group, 32768 fragments per group 16384 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968 Writing inode tables: done Creating journal (8192 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 30 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. root@ttyp1[knoppix]# なぜ? http://www.nanbu.com/mubonblog2/index.php?id=blog1&group=blog *nanbulog2.0 [#a74d4d30] **失敗学の見地からのブログ [#qdcd0d56] 失敗学というのがしばらく前にはやっていた。 失敗は日本とはかなり相容れない。 例えば、宇宙機の開発過程においては失敗してナンボというところがある。 アメリカの初期の月探査計画であるレンジャー計画は6号まで失敗続きで、7号でようやく成功した。 実用期に入ってからでもスペースシャトルチャレンジャーの爆発事故で、宇宙開発は加速した。 ところが日本では、開発過程においても成功してあたりまえ、というムードだ。 宇宙開発にこだわらなくても、一般的に実験に失敗したら、予算の無駄使いではないかと計画の 見直しを迫られ、人が死んだら、計画の中止という話があたりまえのように出てくる。 余談だが、開発過程で過労死するのは珍しくないのだが、それは問題にはならない。 中国の宇宙開発では、事故しようが人が死のうがとにかくやるんだ、という姿勢で友人飛行まで こぎつけた。中国の姿勢がいい、とは言わないが、こういうところは間違いなく伸びる。 しかし、失敗学は日本はやらないとダメだと思っている。 テクノロジーは失敗してなんぼだ。 失敗学は失敗学会によって運営されている。 http://www.shippai.org/shippai/html/ この主宰者である畑村洋太郎氏の著作がたくさんあるが、 なによりも失敗を隠さず直視する「決定版 失敗学の法則」畑村洋太郎 p215 あと、実名で公開するとか、「失敗学のすすめ」p46 責任追及を優先すると原因究明ができない「失敗に学ぶものづくり」p84 とかある。 また、テクノロジーではなくても、経営やマネジメントなどでも、失敗が示唆するものは多い。 日本人の特性として、とことん痛い目にあわないと直らないというのがある。 太平洋戦争、バブル景気、拉致問題など、これらは間違いのしっぺ返しをとことんまで食らった 後にようやく改善に向かい始めた。なぜ間違っていたのかの究明はなされていないようだが。 日本人は、失敗を認めない反面、なあなあで収め、都合の悪いことはふたをして、なかったこと にしてしまう。 それとは反対に、失敗を認めて原因を追求し、ディティールをオープンにしなければならない。 そのためには、過去の失敗を認める立場をとらないといけない。 過去に恥ずかしいことをしていても、それから学ぶことができれば良いという評価の目を持つことが 必要だ。 例えば、私の2015 future domain researchに5年後のパソコンの推移を予想している。 http://www.nanbu.com/keizi_show1_2.php?category1key=&keizikey=1057501181000000004 2003-07-07エントリーの「ムーアの法則による5年後のエントリーパソコンの予測」 2007年 新規格電源が量産され安くなる ハードディスクが外付が主流となり、内蔵しなくなる 外付記憶装置としてUSB接続フラッシュメモリデバイスが主流となる 個人が管理するデータは動画以外はローカルハードディスクに保存しなくなる OSの入ったストレージを持ち運び可能としたり、ネットワーク起動する対応が進む ケースのコンパクト化、低耐久性化が進行する GigabitNetworkの性能が500Mbpsのスループットを期待できるようになる これによりローカルデバイスとネットワークデバイスの違いの感覚がなくなる 構成 |category| device| SPEC| USD| | Semicondacter Device|||| || CPU | 3.0G| 30| || マザーボード||40| || メモリ| 1G| 10| | Drive Device|||| || HDD| 60G|40| || DVD-ROM CD-RW combo Drive | x16x48 | 20| | CKM(Case/Keyboard/Mouse)|||| || Case|| 22| || Keyboard|| 5| || Mouse|| 3| | 合計||| 170| いいところまでいっているが、メモリの価格は現在USD100程度で一桁違う。また、 原文にはNeo-ATXの規格化の普及が前提となっているが、そんなものは影も形もない。 来年はUSD100が実現すると予測していたのだが、まだ道のりは長そうだ。 何よりも、このクラスのデスクトップパソコンがメインストリームから外れ、 普及機としてはノートパソコンに遷移している。 このレポートはエントリーパソコンの予測をしているのであり、レポートの目的からも外れてしまうかもしれない。 このレポートが外れた場合、消し去りたいのが普通だが、これは残しておかなければならない。 これは、過去にどういう予測をしてどういう間違いをしてきたかを公示し、今後の私の評価の 材料としてもらいたい。 一方、拉致被害者について旧社会党は 「二〇年前に少女が行方不明となったのは、紛れもない事実である。しかし、それが北朝鮮の犯行とする少女拉致疑惑事件は新しく創作された事件というほかない。」という論文を過去にWebページに掲載していたことがある。(「食糧援助拒否する日本政府」 社会科学研究所 日韓分析編集 北川広和 ) http://www5.sdp.or.jp/central/gekkan/syamin07kitagawa.html(リンク切れ) 日朝首脳会談で拉致事件が明るみになった後も、この論文はしばらく掲載され、「記載を取りやめるつもりはない」という見解だったらしい。 (http://www.sankei.co.jp/news/morning/04pol001.htmにあったらしいが、確認できない) しかし、相当な非難がなされ、2002/10月のはじめに削除された。 削除の理由は、「個人の考えであった」ということだそうであるが、私的に言わせてもらえば、 ここは「現在の見解は異なります。この時点ではこれが正しいと判断しました。誤っていたことを 痛感します。将来への教訓となるべく、このまま残します。」と書いて掲示を続けてほしかったと思う。 ということで、失敗学という観点からは、誤りであっても公開はしないといけない。 blogは、それがいつ書かれたかというのが明示でき、パーマリンクでそこにアクセスされる ことが期待されている。 そして、コメントを書いて、評価したり、未来に関連記事としてフォローができる。 blogを、失敗学をベースに活用するとかなりいいんじゃないかと思うのである。 *組織とパーマリンクとブログ [#v11a482c] **日付名前空間 [#o0889971] ニュースサイトなどはある程度古くなると閲覧できなくなることが多い。 そうなると資料的価値はない。 5年も10年も経って、発掘する重要な情報もある。 デジタルデータは蓄積し、再利用できるようにすることが重要だ。 情報サイトを運営していて、アクセスを稼ぎたい と思ったら、コンテンツを充実させることも重要だが、 ずっとこれからも、ここに行けば大事な記事が読める、ということを保証するのもまた大事だ。 今日は読めたけど、明日はどうなるかわからないというだけでは、情報の蓄積価値はないであろう。 前回、失敗は隠蔽しないという論点を書いたが、アンカーを切れさせない ことが必要だ。 URIは永続性がある。ブログでパーマリンクを公開したら、それについては責任を持たねばならず、 情報サイトをいかに切れさせないポリシーを持つことが重要かということを認識する必要がある。 具体的な方法として,以下のレポートがある。 "Style Guide for Online Hypertext" 「クールなURIは変わらない」として、翻訳がここにある。 http://www.kanzaki.com/docs/Style/URI.html ここでは、永続的な名前づけとして日付を使う提案をしている。 日付はかなりいい。 **組織ブログ [#p009472e] 組織で公開ブログを書くときに、誰か一人が担当になって書くやりかたもあるけれど、 これからはブログという重要なメディアをもっと活用したい。 当然、複数の人間に書かせようとするけれども、これが大変だ。 個人の個性をもって、別個のブログのように運営するのもいいけれど、その個人が組織を離れたら どうするか。あっさり削除するか? そうできればいいけれども、資産という観点からは有効活用 したいし、原則公開というポリシーに沿う方が望ましい。 ところが、残しておくと、うちの組織などもそうなのだが入れ替わりが激しかったりすると, エントリーの少ないブログが累々ということになってしまう。 一見、アクティブなユーザはたくさんエントリーを書いているが、 ちょっと書いてから、何年も放置状態のブログが沢山。 それでは貧相だから、退社したりしたユーザはアーカイブに移動したりしたい。 そうすると、アーカイブ内には多数のメンバーが混在することになる。 前回紹介した、「クールなURIは変わらない」で日付を使うやりかたが提案されていたが、 多数のメンバーが混在すると、日付は競合を起こす。 では、どうしたらいいだろうか。 組織ごとにブログを作るとなると、 http://ホスト名/組織名/組織名/.../組織名/個人名/記事ID または http://ホスト名/組織名/組織名/.../組織名/個人名/?カテゴリや日付などのパラメータ指定 あるいは両方となる。 ここで、個人は組織を移籍する。また、組織は永続的ではない。 特に、組織ツリーはダイナミックに変更していくものであるから、URI中に組織を入れるべきではない。 しかし、組織ごとにブログを管理させるようなことがあれば、URI中に組織ツリーを入れておき、 URIを末尾から削ることで親組織にアクセスするということはできるようになっておいた方が望ましい。 ここで、mod_rewriteを使うことを前提とすると以下のようなことができる。 http://ホスト名/個人名/記事ID でアクセスし、組織名は記事IDから補間するようにすればよい。 補間した組織名を基に、URIを再構成し、 http://ホスト名/組織名/組織名/.../組織名/個人名/記事ID というURIに302 Temporaly moveで移動すればSEO対策とも整合性がとれる。 こうすると、組織ツリーは全く永続的ではないが、永続的なURIを実現指定するとすると、 でも、これだけでは万全ではない。 複数の組織中で、個人名がダブル可能性がある。 とすると、こうなるわけだ。 http://ホスト名/記事ID として、組織名と個人名は記事IDから補間するようにすればよい。 こうすれば、記事を組織の都合で移動することも簡単だ。 でも、ブックマークしたときの問題がある。 このためには、上で述べてきたことを一旦全部破棄して、逆のやりかたを採用すると 全て解決する。 http://ホスト名/組織名/組織名/.../組織名/個人名/記事ID でアクセスされた場合、 301 Moveでhttp://ホスト名/記事IDを表示するようにする。 **記事ID [#j3c84a14] ここで、記事IDは個人名や日付など、ダブる可能性のあるものは使えない。 nanbulogはSaaSを狙っているため、自分の組織より上のレベルでダブらないことが保証されなければならない。 南部製作所の研究で、それを保証するキーを開発していて、それがclankeyと呼ばれている。これは100年間の使用、10000000人の使用においてダブらないことを保証し、また更にセッション競合しても90%の確率で競合を回避できるものだ。キーの生成時間をユリウス暦秒でキー自体に埋め込んでいるので、ユーザの追跡にも使え、 LongInt型なので動作も軽いものだ。 これを使って、記事IDがユニークなことを保証するものである。 *組織ツリーとSQL [#t8578b1d] -組織ツリーは自己結合でツリー状に表される。 -このツリー内に個人が属する。 -組織ツリーのノードが1レコードとなる→仮称gseed -gseedは組織だけではなく、個人、カテゴリ、タグが含まれる これを踏まえて、gseed内では基本的に組織、個人、カテゴリ、タグの区別はしない。 こうすると、かなり強力だ。個人の下に、更に複数の個人や組織を含めることができるのだ。 *組織ツリー [#kb343ba8] このブログは組織で使うことを目的としている。 -組織がインターネットで公開 -組織内部でイントラブログとして使用 -複数の組織に対してSaaSとして使用 -ISPがサービスとして使用 ここで、組織内部でイントラブログとして使う例をあげてみよう -会社全体-徳島支店-営業部-南部太郎 -会社全体-サークル-ラーメン研究会-南部太郎 というふたつのツリー末端に同一人物が存在しているとしよう。 この情報の扱いをどうするか。 南部太郎は同じブログを指すという考えかたもある。 しかし、Mubon-blogでは、同じ人物でも別ブログという考えかたをしている。 それは、人間の本質として、属するツリーによって人間は多面的なプロフィールを持つという考えからである。 それを尊重したシステムとしたいし、また、組織も属するツリーによってプロフィールを切替えることを 要求する。例えば、 -会社全体-徳島支店-営業部-南部太郎 では日報を書くことを要求されているよする。更に、仕事で大失敗をして矢面にたたされているとしよう。 -会社全体-サークル-ラーメン研究会-南部太郎 では、息抜きをしたいし、ここではラーメンウマーとおちゃらけたキャラクターでいたい。 また、営業部では実名だけれど、ラーメン同好会では匿名でいたいという場合もある。 これの、デザインやコンテンツを共有するのは良くないだろう。 営業部とラーメン研究会とのコンテンツ共有は、少なくともワンクッションおいた操作で行うようにしたい。 *ツリー管理 [#b628633a] ブログはツリー管理できるものは大変少ない。 というか、どういうわけかWeb2.0サービスでツリー構造をもつ情報管理をするものが少ない。 ツリー構造はディレクトリだが、Web2.0サービスはタグや強力な検索を使って、ディレクトリ構造を使わないものが多い。 このブログはツリー構造にこだわっている。 残念ながら、情報整理の本質にツリー構造が必要な理論があるわけではない。どうしてもツリー構造が必要なニーズがゼロにならないだろうというマーケティング的な思惑からである。 ツリー管理するにあたり、単にツリー管理するだけではなく、デザインの継承機能という考えかたを導入している。 *SNSとの比較 [#tcacb525] このブログは組織で使うことを目的としている。 -組織がインターネットで公開 -組織内部でイントラブログとして使用 -複数の組織に対してSaaSとして使用 -ISPがサービスとして使用 上のいずれにも適合するように考えているが、組織内部でイントラブログとして使うことにメリットはあるだろうか? SNSを使った方がいいのではないだろうか? 私はSNSは情報を消すのが前提だと思っている。ブログは情報を保存するのが前提だと思っている。 というのは、SNSは厳しいことはなかなか言えない。ブログは批判をばんばん書ける。 ブログは圧力に負けずに批判できるということは、SNSとは決定的に違うと言える。 その特性を生かそうとすると、パーマリンクの保証などにこだわった Mubon-blogに価値が出てくるのではないかと思っている。 *組織マネジメントとMubon-blog [#h7fd2f29] 「なんだ、この記事は、けしからん!」と社長が叫ぶ。 下っ端の書いた記事は抹消。よくあることだ。 しかし、耳に痛い記事を消さないことが、重要なことなのである。 普通の会社は、投稿する前に承認が必要だ。 しかし、mubon-blogはそれすらも使わないことを推奨する。最低、外部公開分のみ承認をするべきだろう。 そんなのでやっていけるのか? 確かに、くだらない書き込みや単純な間違いの記事は価値は無い。しかし、組織に対して「これはおかしい」 という声は閉じてはいけない。耳に痛いことを言う風土をつくらないと組織はだめなのである。 しかし、忠告と、くだらない書き込みの線引きはどうするのか? 例えば個人情報を出してしまった場合 などは、改訂しなければならない。 そのために、バージョン管理機能を持つ。昔の書き込みを遡って参照できる。 バージョン管理機能でさえもアクセス禁止する条項はある。それはアメリカ公文書の扱いと同等にする必要がある。 *ファイル配置 [#ae5512a9] /..ルートディレクトリ /index.php ,detail.php, detail2.php, ... /Services/ /Services/Trackback.php , ... /Smarty/ /Smarty/Smarty.class.php, internals, plugins, ... /admin/ /admin/addmin.php, add_afi.php, fix_article.php, fix_title.php, ... /admin/fckeditor/ /admin/templates/ /admin/templates_c/ /root_templates/ /templates/ /templates_c/ /userdir/ *Impress Tips [#m2e96f85] -ページをはみ出ると、保存→読み込み すると、勝手に補正される場合がある -箇条書きのアニメーションができない - *https://www.google.com/analytics/reporting/entrances?id=2439267&pdr=20070416-20070516&cmp=average# [#we782cf4] において、グラフの実数がわかりません。本来はグラフ内に文字が表示されているのだろうと思いますが、文字類は全く表示されていません。閲覧環境はFedora Core 6 Linux + Firefox 1.5.0.10です。 貴サイト内Flashのフォントの設定が恐らく不適切だろうと考えています。適切に表示するにはどうしたらいいですか? なお、この問い合わせのメールやご返事いただいた内容につきまして、http://www.nanbu.com/blog/blog2/ で公開することがありますことをご了承下さい - - - - - - *SIREN DF100 Tips [#af07b5f4] 順番はよくわからない FIRMWARE:V4.16, 16:00:42 Jul 18 2006をしよう [root@localhost media]# fdisk /dev/sda Command (m for help): p Disk /dev/sda: 32 MB, 32768512 bytes 8 heads, 16 sectors/track, 500 cylinders Units = cylinders of 128 * 512 = 65536 bytes Device Boot Start End Blocks Id System /dev/sda1 * 1 500 31982+ 4 FAT16 <32M Command (m for help): q [root@localhost media]# dd if=/dev/zero of=/dev/sda1 dd: writing to `/dev/sda1': デバイスに空き領域がありません 63966+0 records in 63965+0 records out 32750080 bytes (33 MB) copied, 1.38507 seconds, 23.6 MB/s [root@localhost media]# mount /dev/hda3 on / type ext3 (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) /dev/hda2 on /backup type ext3 (rw) /dev/hda1 on /boot type ext3 (rw) tmpfs on /dev/shm type tmpfs (rw) /dev/hda6 on /home type ext3 (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) /dev/sda1 on /media/disk type vfat (rw,noexec,nosuid,nodev,shortname=winnt,uid=500) [root@localhost media]# umount /media/disk *なぞなぞのお詫び [#q28583f4] このブログの運営に使用しているプログラム「mubon-blog」は南部製作所独自で作成しています。 まだ注目されていないと思ってたかをくくっていたら、 この度、遂にこのブログにもSPAMコメントがやってくるようになりました。 知名度が上がったかな?目出たい!・・・かどうかは別として、SPAMコメントを防がないといけません。いくつかアイデアがありますが、今回は独自の試みとして、コメント投稿時に「なぞなぞ」を出題することにしてみました・・・これが失敗でした。 「なぞなぞ」に正解しないとコメントが投稿できない、という仕組みを考えました。これにより、ロボットが機械的に投稿することを防ぐことができます。人間が投稿するSPAMは防ぐことができませんが、これについては実際にこういうSPAMがあってから対応することにしました。 また、「なぞなぞ」の出題・回答はブログシステムとは別に稼動させる予定です。この「なぞなぞ」API は自由に使えるようにする予定なので、「なぞなぞ」を使ったマッシュアップも可能にする予定です。更に、現在はまだ対応していませんが、質問の内容を選ぶことにより、特定の知識を持った人しかコメントができなくするという機能も狙っています。 ということで、プログラムはNori君に簡単に作ってもらいました。おお、GJ! で、調子に乗って出題も彼に任せていたら・・・。 | 1 | ガルマは何故死にましたか?ひらがな6文字で答えて下さい。 | ぼうやだから | 2007-04-20 22:18:49 | | 2 | ジョン万次郎は遭難し、アメリカの捕鯨船ジョン・ハウランド号に救助されたのは一般常識ではすが、この時のハウランド号の船長の名前を答えなさい(アルファベット9文字) | Whitfield | 2007-04-20 22:23:24 | | 3 | 人生、宇宙、すべての答え(数字2桁) | 42 | 2007-04-20 22:24:23 | わからない!こんなのわからないって! そりゃ、特定の知識を持った人しかコメントできない、という機能も考えているけれども、あくまで将来の話で、現在の「なぞなぞ」システムはあくまでSPAM回避を目的とした、人間なら普通に答えられる質問で運用しなければなりません。 実際に皆様に使っていただく前に、僕が差し替えをするつもりが・・・忘れてしまっていました! 申し訳ございません。 4/20夜から、5/8朝まで、なぞなぞの質問が上記のものになったままで、実質的にコメントできなくなっていました。 コメントしようとした方、不快に思われた方、大変申し訳ございませんでした。 なお、現在のなぞなぞは、以下の質問になっています。 |4 | 光の三原色は青、赤、そして? (漢字一文字で答えてください) | 緑 | 2007-05-08 09:51:00 | | 5 | 空気には重さがある? ない? (「ある」か「ない」かで答えてください) | ある | 2007-05-08 09:55:56 | | 6 | 桃栗3年,柿○年。○を半角数字で答えてください | 8 | 2007-05-08 09:56:26 | | 7 | ガンダム、スターウォーズ、おしん。舞台が未来なのは? | ガンダム | 2007-05-08 09:57:14 | | 8 | 沖縄と北海道。朝日が先に登るのは? | 北海道 | 2007-05-08 09:57:38 | | 9 | ( 245 + 843 ÷ 43 - 17 ) × 0 = ? | 0 | 2007-05-08 09:57:52 | | 10 | 通常の植物は 1 緑の光と 2 赤の光,どちらがよく育つでしょう。番号で答えてください(半角)。 | 2 | 2007-05-08 09:58:11 | | 11 | ゼロを発明し、カレーでおなじみの国は? 全角カタカナで答えてください。 | インド | 2007-05-08 09:58:48 | | 12 | ドレミファソラシドで、最初のドから最後のまでの間に音の周波数が倍になります。この範囲を8つの音階の「オクト」をとって、いち○○○○○といいます。<br />○に入る言葉を全角カタカナで入れてください。 | オクターブ | 2007-05-08 09:59:01 | なぞなぞについては、今後質問を増やしていく予定です。今回に懲りず、ご活用をお願いします。 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) 221.150.5.133 - - [05/May/2007:12:14:08 +0900] "POST /blog/blog1/add_comment.php HTTP/1.1" 200 8366 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) 69.50.173.10 - - [22/Apr/2007:12:45:45 +0900] "POST /blog/blog1/./add_comment.php HTTP/1.1" 200 7828 Opera/9.0 (Windows NT 5.1; U; en) 210.66.111.170 - - [16/Apr/2007:08:31:01 +0900] "POST /blog/blog1/add_comment.php HTTP/1.1" 302 - Opera/9.0 (Windows NT 5.1; U; en) 200-138-105-8.ctame7044.dsl.brasiltelecom.net.br - - [16/Apr/2007:08:32:12 +0900] "POST /blog/blog1/add_comment.php HTTP/1.1" 302 - Opera/9.0 (Windows NT 5.1; U; en) broadband-dynamic-central1200.connect.com.fj - - [16/Apr/2007:08:31:19 +0900] "POST /blog/blog1/add_comment.php HTTP/1.1" 302 - Opera/9.0 (Windows NT 5.1; U; en) user-24-214-96-189.knology.net - - [17/Apr/2007:09:51:47 +0900] "POST /blog/blog1/add_comment.php HTTP/1.1" 302 - Opera/9.0 (Windows NT 5.1; U; en) net-100-162.jasatel.net.id - - [17/Apr/2007:09:51:30 +0900] "POST /blog/blog1/add_comment.php HTTP/1.1" 302 - Opera/9.0 (Windows NT 5.1; U; en) 64.37.150.220.ap.yournet.ne.jp - - [17/Apr/2007:09:52:11 +0900] "POST /blog/blog1/add_comment.php HTTP/1.1" 302 - Opera/9.0 (Windows NT 5.1; U; en) user-24-214-96-189.knology.net - - [17/Apr/2007:09:52:30 +0900] "POST /blog/blog1/add_comment.php HTTP/1.1" 302 - Opera/9.0 (Windows NT 5.1; U; en) 12-226-244-51.client.mchsi.com - - [17/Apr/2007:09:51:31 +0900] "POST /blog/blog1/add_comment.php HTTP/1.1" 302 - Opera/9.0 (Windows NT 5.1; U; en) 200.172.37.51 - - [17/Apr/2007:09:54:18 +0900] "POST /blog/blog1/add_comment.php HTTP/1.1" 302 - Opera/9.0 (Windows NT 5.1; U; en) tools.ubm.ro - - [17/Apr/2007:09:55:17 +0900] "POST /blog/blog1/add_comment.php HTTP/1.1" 302 - Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727) Sleipnir/2.5.10 p1121-ipbf10tokusinwcc.tokushima.ocn.ne.jp - - [18/Apr/2007:05:03:52 +0900] "POST /blog/blog1/add_comment.php HTTP/1.1" 302 - Web2.0で使うblogは? (1) nanblog紹介 会社組織などのグループで使うblogはどんなものがいいだろう? メンバーがそれぞれエントリーを書いて個人ブログのように公開できる けれど、メンバーの属するグループや、更にその上の親グループと連携 して使えるものはどんなものがいいだろうか? フリーとして公開しているものを調べてみましたが、ぴったりのものは無い感じです。 ひとつの解決方法として、XOOPSにWordPress MEモジュールがあり、これを「ハックする(xoops用語でいう独自改良する)」 とかなりいけそうでした。 でも、ここはあえて独自に作ってみることにしました。 それが今ここで公開しているnanblobです。 開発はのんびりしたもので、現在はこういう状況です。 このnanblogは、以下のような特徴を持っています(一部は、まだ実現していません。構想や妄想が入っています)。 :GPL | LAMP/LAPP環境で動きます :マルチグループ管理機能 | メンバーは完全に独立した個人としても使えますが、 会社や、グループに属した管理も行えます。更に、グループは階層化しており、 それぞれの階層ごとに完全独立か、親グループと連携するかを選べます 会社組織や、異業種交流、サービスプロバイダなどでの使用を想定しています。 :デザイン機能 | 現在は完全に自由にテンプレートデザインが可能。(→ですがデザインの自由度を制限して、はてなテンプレート互換に仕様を変更する予定です) :マルチロールデザイン | リキッドデザインを更に押し進めたデザイン構想を取り入れます。 :入力エディタの工夫 | デスクトップアプリケーションに比較して、実用に耐えるWeb入力環境を構想中です。 :ファイル管理の工夫|画像アップロードやサムネイル作成機能など。NetPBMを使うことで画質に気をつかった処理を行います。 :などなど、など 現在はまだアルファ版程度の出来で、設計思想自体を模索するための習作のような位置付けです。 しかし、アジャイル開発を行っているため、問題がない限りは正式版を別開発するのではなく、 このまま実用化する予定です。 現在、うちで実際に使用してみることで仕様や設計思想をフィードバックしていってます。 設計思想 Web2.0アプリケーションのスタンダードを確立する Webアプリの本質的な欠点 入力がめんどい 本当に入力しやすいものは何か -記述言語の問題 --htmlをしろうとが慣れるのは無理 --Wikiに慣れるとWISYWIGはめんどくさい --WISYWIGに慣れるとWikiはめんどくさい -JavaScript --入力者のデータからはコードを無効化しないといけない -AJAX --単なるTEXTAREA入力だと、以下の問題がある ---認証、回線切断、バグによって入力が消える恐れ ---TEXTAREAのサイズがブラウザサイズに追随しない ---入力途中、検索などのエディタコマンドが使えない --したがって、AJA(X)は必須 -衝突の検出 フリーの背景を作る Nanbulogのデザイン:フォント 最近までデザインもこういった感じでした。 でも、スタッフよりさすがにデザインを言われて、それなりのものを作ろうと思った。 ここで、以下の注意点をしています。 -画像を作成する -マルチロールデザイン -拡大縮小画像 -フォントを選ぶ -角を丸くする フリーのフォント これにワンポイントをいれたりします。 これに使うフォントは何がいいでしょうか? 日本語フォント 個人的には平成丸ゴシックや、平成ゴシック体が好みですが、 フォントライセンスがめんどくさいです。 ライセンス 商用に使えないと意味が無い。 ほとんどは商用禁止だ。 つまり、金儲けするなら金を払え!ということだ。 これは知の高速道路に反している。 金儲けしようがどうしようが関係無く使えるものが必要だ。 また、改変も禁止だ。 後に書くが、改変が使えないと意味が無い。 フォント オンラインダイナミック生成することを考えると、pdf埋め込みやFLASH埋め込み も可能なものとなると、ほとんどがややこしい ことになる。しか使えない。 本当はフォント -小さいものにはビットフォントが欲しい -しかし、Linuxのフォントを見るとビットフォントよりもきれいだ -したがって、適切なゴシック体を使えばよい -12*12ドットのX68000フォントは美しい明朝であった。 -http://www.geocities.jp/littlimi/font.htm -8*8ドット日本語フォント「美咲フォント」 -6*8ドット日本語フォント「k6x8」 それ以上のフォントは東雲フォントなどのビットマップ部分が使える 英語フォント 英語は須子シ違います。 -Linuxの中に安心して使えるフォントはたくさんあります。 -フォントフェイスの判例 とはいうものの、生きているうちは尊重するというのは素晴らしいことです。 USALight,USABlackは Altaiだそうです。とはいっても、少し違います。 南部製作所で使う上で必要な機能 -GPL -アフィリエイト アフィリエイト をすることで、お金を儲けます マイレージ 南部製作所の競争力 PRをしていませんでした。 でも、小さいところが勝つには露出を多くしないといけません。 弊社の仕事をするうえで得たノウハウも捨てたものではないと思います。 以前からGPLを適用してきましたが、要を欠いていました。 それを公開し、それでお金を稼ぎます。 このお金を稼ぐのを、半々程度にする予定です。 こうすることで、以下の利点があります -南部製作所のサービスのPRができる -しかし、いいところだけをPRするのではなく、冷静な比較が出来る -採算がとれなくても良い -逆に言うとデータが取れれば良い -とことんすることになる -お客様からは、公開した手順をとることで安心できる マルチロールデザインの提案 Webのデザイン:マルチロールデザイン Webデザインにおいて、DTP脳な方々からのご要望にきっちり答えていくと、ページ全部アニメーションGIFで作ることになる。いや、それだと印刷したときにボケてしまう。ページ全部PDFで作ったら完璧だ。 この要望と真向から反対する、html原理主義の思想がある。 * 誰もが読める * 共有を制限しない * 再利用を制限しない 具体的には正しいhtmlを書き、lynxで読め、機械処理可能なマークアップをする。今、世の中の流れはWeb2.0になり、html原理主義のベクトルが強い。 しかしコマーシャルサイトを作る場合、どちらかのみというのは不可能だ。そこををとをどう落とし込むかということがサイト構築者のマネジメントということになる。顧客がDTP脳的な要望を出したとしても、その意向を無視するのも、意向べったりなのもマネジメント不在だ。うちの作成するWebサイトは大きなプロジェクトでは無いけれど、「顧客が説明した要件」から必要なものだけを抽出して、規格や技術的制約や予算や哲学、もろもろの枠内で別物を再構築する作業がなければ、どんなものでもグロテスクなものができてしまう。 html原理主義やCSS原理主義というのはこうるさい輩だと思うかもしれないが、サイト構築にはデザイナーの哲学が必要であり、SEOとしてなんとかをすればよい、というTIPSではなく、デザインの裏にある理論があり、それを支える哲学があり、それを顧客に説明できるようにしなければならない。 巷では、ユニバーサルデザインとか、人にやさしいとかいうデザインがキャッチフレーズになっている。ここらへんも、裏に哲学や理論がないと、表面のテクニックだけなぞるだけになってしまう。 さて、「ページ全部PDF」のようなベクトルも、ある見方であることは否定しない。これも確かにユニバーサルデザインだ。これを現実的に落とし込むと、以下のサイトで書かれているようなことになるのだと思う サイトの横幅を640ピクセルにする理由――統計と現状に基づく結論http://www.kotono8.com/2006/11/25640px.html さて、これとは別方向のベクトルが、リキッドデザインだ。ブラウザの横幅の変化に、液体のように追随するデザインだ。このデザインのコツは、横幅を %指定で行うことだ。リキッドデザインのメリットは、くどくなるけど改めて示すと * 印刷対応がやりやすい A4短辺21cm → 印刷領域18cm≒7in → 印刷300dpi:画面96dpi横幅Displayで600px相当 しかし、これには欠点がある。ピクセル指定で行っているのだ。これはただ単に、ブラウザの横幅の変化に過ぎない。 本当なら、枠線とかも大きくなりたい。 さて、私はこれを更に進めたマルチロールデザインを提唱したい。詳細は次回。 ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー マルチロールデザインとは 再利用できる 具体的には、htmlを書いて、それを拡大縮小できる 通常のhtmlはいまなら横800pxや1024pxが前提だろう。これを30%に縮小し、300%に拡大しても崩れないようにする。30%に縮小したときは携帯画面サイズで十分読める。300%に拡大したときはPowerPointのような表示にする。 では、この拡大縮小をするには、どうしたらいいか? Opellaには、拡大縮小機能があるが、これを使うのではない。ブラウザのフォントサイズの指定、あるいはブラウザのウィンドウサイズ指定で行う。 コンピュータの技術文書の作り方Ver.20050209 http://www.nanbu.com/keizi_show1_2.php?category1key=1&keizikey=1107908682000000017 マルチロールデザイン * レイアウトは余裕をもたせる(例えばプリンタが異なってマージンが変わった時にはみ出るように) * 改行はなるべく論理改行のみ * フォントが変わってもはみ出ないように(表組みなどの場合にはフォントが変更されてもいいように20%程度の余裕が必要) * 画面サイズが変わっても体裁が崩れないように これに加えて、EMで行うということを追加する。 ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー cssでする苦労 EMでする場合、苦労する。 包含ブロックの話を理解していなかったのでこれをみっちりしなければならない floatレイアウトとpositionレイアウトとどちらをするべきか?? [[ブログのブックマーク]] ----- SNMPツール cheops TWSNMP PLANEXの監視万能はこれのOEM OverView インシデントサポートに必要 ----- Webのデザイン:マルチロールデザイン Webデザインにおいて、DTP脳に汚染された方々からのご要望にきっちり答えていくと、ページ全部アニメーションGIFで作ることになる。いや、それだと印刷したときにボケる。ページ全部PDFで作ったら完璧だ。 このベクトルを現実的に落とし込むと、以下のサイトで書かれているようなことになるのだとおもう。 サイトの横幅を640ピクセルにする理由――統計と現状に基づく結論http://www.kotono8.com/2006/11/25640px.html ユニバーサルデザインとか、人にやさしいとかいうデザインがキャッチフレーズになっている。 この手法も、確かにユニバーサルデザインであることは否定しない。 さて、これとは別方向のベクトルが、リキッドデザインだ。ブラウザの横幅の変化に、液体のように追随するデザインだ。このデザインのコツは、横幅を%指定で行うことだ。 リキッドデザインのメリットは、くどくなるけど改めて示すと -印刷対応がやりやすい A4短辺21cm → 印刷領域18cm≒7in → 印刷300dpi:画面96dpi横幅Displayで600px相当 - - - - 私はこれを更に進めた。 マルチロールデザイン 弊社では、オンサイトでWebサイト構築をするサービスをやっている。1回1時間のみだが、その コンピュータの技術文書の作り方Ver.20050209 http://www.nanbu.com/keizi_show1_2.php?category1key=1&keizikey=1107908682000000017 マルチロールデザイン -レイアウトは余裕をもたせる(例えばプリンタが異なってマージンが変わった時にはみ出るように) -改行はなるべく論理改行のみ -フォントが変わってもはみ出ないように(表組みなどの場合にはフォントが変更されてもいいように20%程度の余裕が必要) -画面サイズが変わっても体裁が崩れないように ----- 無産主義 http://d.hatena.ne.jp/DocSeri/20070113/1168672829 いきなりコーヒー BROOK'S テーブルタグで最悪だ。 共有ファイルを現在使用しているユーザーを特定する方法 http://www.atmarkit.co.jp/fwin2k/win2ktips/083opened_net_file/083opened_net_file.html せたがや行政法務事務所>医療機器の製造販売 http://www.asahi-net.or.jp/~ny9n-kdir/kiki/index.htm XPUnlimited 以下のようなエラーメッセージが出る この FileMaker Pro のシングルユーザーライセンスコピーは起動できま せん。他のユーザがこのコンピュータで同じライセンスの FileMaker Pro のコピをすでに起動しています。 北米現地採用社員集まれ55 名前:名無しさん []:2006/05/08(月) 21:50:39 ID:8Y+icTSE (2) >>244 日系の会社から現地企業に転職している 技術の人がいるんだけれど、 その人、神扱いされているよ。 日本の仕事の進め方が上司に評価 されるようなことを言っていた。 256 名前:名無しさん []:2006/05/08(月) 22:14:22 ID:Gy6AWlLo 現場で生産技術をやってたオサーン達の海外の同業他社への 再就職は引く手数多だよ。 あのポルシェでさえ、トヨタのOBを招へいして生産性を改善した ちゅうのは有名だからな。 アジア系企業だとマジ神格化されてる技術系オサーンを結構知ってる。 257 名前:名無しさん []:2006/05/08(月) 23:51:32 ID:8Y+icTSE (2) じゃ、やっぱり日系から他国企業への転職って 重宝される噂は本当なのかな? まぁ、技術に限ってだけれど。 258 名前:名無しさん []:2006/05/09(火) 01:48:35 ID:z7nwhmws 中国系企業は日本の定年技術屋のハンティングに熱心だと聞く。 生産技術は、どの分野でも圧倒的に日本が世界一だからね。 仕事でこっちの生産技術と話す機会が多いけど、管理レベルからして全然違うよ。 俺が行く殆どのローカル企業は現場のあちこちでラジカセがガンガン鳴ってる。 こんな雰囲気で良品なんか出来るわけがないって確信したよ。 見学に行って、ラジカを止めさせろって一喝した日本人のオサーンがいたけど、 組合強いから止められないとか何とか言ってた会社があったなぁ。 そう言う会社は出荷前の検品で見つかる製品不良率が凄い。材料業者は喜んでるわな。 その検品すらちゃんと出来ない会社が五万とあるからね。 ---- USALight,USABlackというフォントがある。 南部製作所のデザインに使用していたものだ。 CorelDraw!3で使用していた。 LinotypeのUnivers LightとUSABlackらしい。 更に、Bitstreamの代替書体はZurichというそうだ。 フォントの由来はわかりにくいですね。ここが参考になります。 http://www.tg.rim.or.jp/~hexane/ach/hfw/hfw08.htm 更に、BitstreamはCyberbitがあるそうだ。 CyberCJK(等幅) Core fonts for the WebはMicrosoftが提供しているが、 これはGPLだそうだ! http://www.microsoft.com/typography/fonts/default.aspx ここにフリーフォントはあるが疑わしい http://www.freefontarchive.com/fonts-un-1.html http://fontopedia.com/fontopedia.php?cpage=815 http://www.free-fonts.com/ 無料で使えるベクターデータを配布しているサイト27選 http://www.simplexsimple.com/archives/2007/02/27.html 女性向けサイトに使える?きらきら文字ジェネレータ http://www.simplexsimple.com/archives/2007/03/post_54.html FontForgeについて、著作権の問題を解説している。 http://fontforge.sourceforge.net/ja/faq.html よく使うライセンス・フリーのフォント http://hail2u.net/blog/webdesign/lovely-license-free-fonts.html 潮待フォントのページ http://mambo.kuhp.kyoto-u.ac.jp/~miyoshi/shiomachi/ 他社と比較して、はてなのテーマファイルはそう劣ってないと思うんだけど http://d.hatena.ne.jp/DocSeri/20070115/1168859539 http://opentechpress.jp/opensource/article.pl?sid=06/03/03/0329203 歌の問題にあてはめることができるのではないか ---- サイトの横幅を640ピクセルにする理由――統計と現状に基づく結論http://www.kotono8.com/2006/11/25640px.html フリー写真 商用可能しかし著作権表示をする必要がある http://www.yunphoto.net/jp/photo.html ----- CPUFSB (Change the frequency of your PC) nTUNE ----- Web受発注 発展途上国決済システムが必要だ。 それも、日本円にして1000円未満である。また、 できれば毎日のアクセスがお金になるように、したい。とすれば、日本円にして数十円でも決済ができる必要がある。あるいは、通貨の代わりとして使用できるものでもいい。 ----- このエラーを調べるには、以下のヘルプメッセージを入手します。 http://www.microsoft.com/japan/technet/prodtechnol/windows2000serv/proddocs/reskit/msgs.mspx ちなみに、イベントログのエラーもここで解説されています。 ここに以下のように書いてありました。 -STOPエラー一覧 -http://park12.wakwak.com/~iktryc/diary/2005/stoperror.html イベントビュー輪 www.eventid.net 年間15ドルであらかじめ登録するとメールで ----- Skypeが調子悪い。 Skypeのバージョンを戻せばいいのだが、しゃくだ。 というのは、プロプラエタリのソフトの悪いところが出ている。 簡単なところだと思うのだが、手が出せないというのがしゃくである。 これを、ソフトの提供者が慈悲の心を持って直していただくのをじっと待っているしかない。 OSS精神をもって、Linuxを使っている私としては、 何か調べてみた。 Skypeにクローンが登場 http://opentechpress.jp/desktop/05/10/04/0116242.shtml wengoがある ----- WikiのWemaがある。 それの考えを元に、agaxを作りました。 wikiは今後発展していきます。S3記法を考えないといけません。 @nifty TimeLine ----- ファイル名を指定して実行 の便利な使い方 http://www.itmedia.co.jp/bizid/articles/0703/02/news115.html ----- 最近は少なくなりましたが、 心霊写真やUFO写真など、気味悪い写真の雰囲気があります。 写真修正をした写真は、どことなくそのような不自然さがあります。 超常の世界では、そのようなものを映した写真は、通常の画像にはならないと考えることができます。 しかし、ロドファーフィルムのように、画像を丹念にチェックすると、 そのようなことも否定できるものです。 ということで、チェックしてみました。 ----- フォントフェイスの問題 このようなトラブルがある http://blog.dgcr.com/mt/dgcr/archives/19990323000000.html ----- PCIの監視万能、100万円程度 Netseeker ライセンスが使いづらい 監視万能 トポロジーが自動コネクトしない サーバ監視サービス http://www.cman.jp/network/ ----- UNICODE NBSP (No Break SPace http://www.fileformat.info/info/unicode/char/search.htm?q=space&preview=entity によると、NBSPとSpaceとは別ですね。 ----- 携帯問題 RFC2821に従っていないメールアドレス 個体識別情報とutn情報 http://d.hatena.ne.jp/astronote/20070224 そして、IPアドレスの詐称問題 IP 制限が http://rblog-ent.japan.cnet.com/tamon/2007/03/20_dfdd.html 要トラックバック ----- トラックバック技術仕様書 http://lowlife.jp/yasusii/stories/8.html 伝えたいこと 第6回 2007.2 連載コラム 新聞を読もう 「新聞を読むことは社会について知るもっとも手近なよい方法です。」 とある。ふたばの軍版 ----- バックグラウンドにFLASHやCANVASやSVCができればいいのですが、できませんでした。 CANVASはファイルになららず、要素であり、また、JavaScriptで描画しないといけません。 なので、background img url:では解決しそうに無いです。 ----- Color me shopを開店しました。 ----- 日本人は虐殺などしない、という嘘 これは軽々しく言えるものではない。というのは、ひとつの証拠 で決まるものではないからだ。うそ情報がかなりふくまれている。 そのウソ情報を丹念に取り除いても、大勢のかかわった事件である ため、統計的な見方が必要だ。 延々と議論をしていかなければいけない問題だ。 学術的な態度、つまり実証的な態度だけが白黒決着をつけるものだ。 ----- Vistaを使ってXPUNLIMITEDだと互換性門ダイアgう一挙に解決 ----- Googleの決済システム ----- 巡回サイト ホームページを作る人のネタ帳 ----- 本を買う シリコンバレー精神 ―グーグルを生むビジネス風土 僕の妻はエイリアン 「高機能自閉症」との不思議な結婚生活 (単行本) ----- オープンソースでWebでビジネス EC-CUBE MosP人事給与 OpenPNE www.atopic-info.com (2007/3//8のエントリー~ ----- 社内SNS/ブログも大炎上するのか? http://www.future-planning.net/x/modules/news/article.php?storyid=2106 精神を鍛えねばならなり 2chで。 炎上で。 長期的には会社のためです。 ----- ----- 南部製作所の作業は安くしています。 それの補完をWebでします。 だとしています。 ----- 著作権の話 ここにトラックバック http://tail.s68.xrea.com/blog/2007/03/post_42.html CCの話 http://www.virtual-pop.com/tearoom/archives/000185.html Webを作るには、コンサルと同じ手法を用いなければならない。 http://kumamoto.lin.go.jp/shidou/01/shidou.html ----- こんなものでいいのか? http://rblog-ent.japan.cnet.com/geeklog/2007/03/post_2da4.html インディーズのデザイナーたち イメージで見出しを作るが、 問題点は マルチロールデザインにならない。 ベクターデザインで ボタンっぽくする方法 http://www.mozilla.gr.jp/standards/webtips0004.html ブロックレベル要素をセンタリングする方法 CSSとJavaScriptでブロック要素の角を自在に操るライブラリ『Transcorners』 http://phpspot.org/blog/archives/2006/10/cssjavascripttr.html ----- http://www.epson.jp/products/printer/inkjet/em930c/b_930c1.htm EM-930C ----- 私は 産学連携でやったことがあるが、 その当時の経験では、医療情報というのは3年は遅れている。 アカデミズムでそうであるから、実際のはもっと遅れているのだろう。 ORCAの体たらく http://column.chbox.jp/home/kiri/archives/blog/main/2005/11/19_095934.html 本当に技術が必要とされる現場にgeekがいない 医療機器 本当に技術が必要とされる現場はgeekを排除している。 政治屋がいるのだ。geekは、テクノロジー主導で動かしているものだから、 Thunderbirdの問題点 Thunderbird2が出るようだが http://www.itmedia.co.jp/bizid/articles/0703/09/news103.html こちらのほうがいいのではないか Ajaxを駆使したWebメールとスケジューラ「Scalix」日本語版 http://www.itmedia.co.jp/bizid/articles/0703/12/news077.html http://www.upsold.com/ ドロップシッピング http://www.imagemagic.co.jp/dairiten.html スカーフからネクタイ http://www.chiyoda-necktie.co.jp/ T-シャツ アレシボ天文台 ネクタイ:シュレディンガー方程式