http://www.old-computers.com/news/default.asp
このページ楽しすぎる。
年代順に見るのがお勧め。
家で使っていたパソコンもちゃんと載っていた。
Sharp PC-3201 (私が触ってたのはこのデグレード版の 3150G というやつ)
http://www.old-computers.com/museum/computer.asp?st=1&c=811
--> BASIC のプログラムはこれで覚えた
--> Z80 のアセンブラはこれで覚えた。
Sharp X1 (CZ-800C)
http://www.old-computers.com/museum/computer.asp?c=313&st=1
--> ゲームばかりしてた。
--> ワープロとして使ってた。
--> Pascal はこれで覚えた。
--> CP/M はこれで覚えた。
--> Tiny Language で遊んだ。
--> 健康診断の結果をこれで集計した。女生徒に目の敵にされた
--> プロッタで年賀状印刷。年賀状印刷したのはこの時だけ。
Sharp X68000 ACE / ACE HD
http://www.old-computers.com/museum/computer.asp?c=302&st=1
--> ゲームばかりしてた。
--> ワープロとして使ってた。
--> C 言語はこれで覚えた。
--> MS-DOS はこれで覚えた。(クローンだけどね)
意外とこの頃の貯金が生きている気がする。
特にゲームね。
参考)
ボクらは「桃鉄」で日本地理を、「信長の野望」や「三国志」で歴史を学んだ
--> [2005-06-01-3]
ちなみに、昔話ばっかりしてると、おじさん認定されちゃうぞ。
気を付けましょう。
http://pc.watch.impress.co.jp/docs/2005/1110/kaigai222.htm
ブロック図を見ると Cell と似ている。
この大量の CPU をどう使うと良いのかは想像できない。
設計は明確なビジョンがないとできないわけで、
上に載るアプリケーションはデザイナーの頭の中にはあるんだろうな。
それが知りたいところ。
http://tech.braina.com/2005/1114/it_20051114_001____.html
via http://blog.nanae.biz/?eid=350343
へー。
情報を暗号化したまま演算、というのはごく普通に実装できそうだけど、
演算ロジックまで暗号化しちゃう、というのはすごいな。
どうやるんだろ？。
専門家に話を聞きたいのう。
http://d.hatena.ne.jp/naoya/20051113/1131906445
RFP に使える!!!
...... 使えねえって。
http://www.watch.impress.co.jp/akiba/hotline/20051112/etc_plathome.html
PC-UNIX をちゃんとサポートしてくれたのは有難かった。
変なものが店に置いてあるのが楽しかった。
それほど買い物はしなかったけど、
店舗がなくなっちゃうのはさみしいねえ。
http://www.amd.com/jp-ja/0,,3715_13368_13369,00.html
量産品対決らしい。
強い CPU を 200台限定生産して対決かのう。
ラリーカーみたいだな。
できればチームを作って総合力を競って欲しいかも。
- パーツは量産品を使う
- 課題は毎年適当なものを用意
- 何回かレースをする
- ポイント制
少考。
レースとしては、いけそうだけど、商業的に駄目そうだ。
でもまあコンピュータ将棋大会なんかも、
総合力レースっぽい側面はあるけどね。
強い CPU を使うのが当然有利だし。
http://yohei-y.blogspot.com/2005/04/rest_23.html
REST と Ajax、JavaScript は仲が悪いのかも？、
と思ったこともあったけど、意外とそうじゃない気もしている。
REST はあくまでネットワークアーキテクチャで、
UI じゃないんだよね。
再利用性を高めるためには、やっぱり REST という
デファクトスタンダードは考慮する必要があると思うですよ。
過去の日記)
REST なんてどうでも良いかも、と思った日記 --> [2005-09-16-1]
REST についてのまとめ --> [2005-09-14-7]
http://ameblo.jp/ki6ra/entry-10005963914.html
女性は Yahoo、男性は Google らしい。
http://www.atmarkit.co.jp/farc/rensai2/proto01/proto01a.html
上流工程っていうのは
- 要件定義
- 基本設計
なんかを指すのが普通。まあ一般的には。
その上流工程の前段階には、
- なんのためにシステムを入れるか
ということに関する議論は必須。
これをちゃんと議論しないでシステムを作っちゃう、
というのはありがちな悲劇の元。
要はユーザの気持ちを理解しなきゃ駄目よ、と。
その議論のためには、システムを導入したいユーザの商売、
つまり
- どういう業務を
- 誰が
- どんなふうにやっていて、
- お金をどう使って
- お金をどう回収してるか
というようなことを、予備知識として、
きちんと理解しとく必要がある。
業務知識がある SE が欲しい、と言うのは、
この辺の知識がある、ということよね。
ただ業務知識というものは、実際に業務に携わらないと、
ちゃんとは身につかないもので、
システムだけ作ってて身につくものじゃないのよ。
なのでシステムを作る方で業務知識がある人を
揃えられるか、というとなかなか難しい。
でもユーザ側は、システムを作る側に、
業務知識は当然ある、ということを要求しがち。
お金だけ出せばシステムができてハッピーになるぞ、
と思ってるわけだ。
その辺もありがちな悲劇の元。
アジャイル的なアプローチが絶対っていうわけじゃないとは思うけど、
少なくともアジャイル的なアプローチでは、
- 顧客がやりたいことを、顧客と開発者で明確化し共有できる
というメリットはあるのは確か。
アジャイルの考え方や理念は、従来型の開発にも応用ができるので、
上流工程の人こそアジャイルの勉強をして欲しいなあ、と思うね。
http://slashdot.jp/linux/article.pl?sid=05/11/10/0950212
問題提起の原文は以下。
Problems with the IETF's copying permissions
http://josefsson.org/bcp78broken/
ここで以下の問題提起がされている。
- No Rights To Adapt Parts Of Contributions
- No Rights Are Granted To Third Parties
RFC3978、RFC2026 を斜め読みした感じだと、
たしかに Rights にうるさくなってるみたいだ。
http://rfc.net/rfc3978.html
http://rfc.net/rfc2026.html
なんで Rights にうるさくなってるのか、という背景が知りたい。
やっぱりガバナンス絡みなのかなあ。
余談)
RFC を調べるには以下が便利。
http://rfc.net/
最新の STD、BCP、FYI 等をまとめて読める。
STD : standard - 標準プロトコル
BCP : Best Current Practices - プロトコルの使い方、設定方法等
FYI : For Your Information - インターネットに関する有用な情報
IETF をちゃんと追いかけていないけど、たまに RFC を見る必要がある
人にとっては、こういうまとめページはむちゃくちゃ助かる。
余談2)
こういうページにも PayPal DONATE が貼ってある。
有用なページでお金を稼ぐにはアサマシじゃなくて
寄付という選択肢もあるのう。
昨日から使ってみてるけど Cacti 良いね。
情報源をメモ。
Cacti オフィシャルサイト
http://www.cacti.net/
グラフツール cacti とは？
http://cacti.loaded.jp/
日本語の情報が良くまとまっている。
カスタムグラフ作成のやりかたも書いてある。
Cacti の内部構造
http://cacti.loaded.jp/index.php?%C6%E2%C9%F4%B9%BD%C2%A4%A4%CB%A4%C4%A4%A4%A4%C6
Cacti - Additional Script
http://www.cacti.net/additional_scripts.php
メールやウェブのステータス取得、Nagios 連携等を
行なうスクリプトがある。
いくつか試してみよう。
Cactid
http://www.cacti.net/cactid_info.php
Cacti は、cron を使ってポーリングする。
その際に cli 版の PHP が必要になる、というのがダサイ。
遅いしね。
Cactid は C で書かれた代替品。
ports でインストールできるみたいなので入れてみるかのう。
CactiUsers.org - Cacti のコミュニティサイト
http://cactiusers.org/
プラグインがいくつか紹介されている
ホスト監視や、メールでの通知もできるようだ。
Cacti
http://www.cacti.net/index.php
Cacti は近頃流行りの RRDTools のフロントエンドツール。
要は MRTG の代替品。
PHP が必要だったり、PHP の拡張モジュールが必要だったり、
MySQL が必要だったり、真面目にインストールするのは大変だけど、
FreeBSD の場合は、/usr/ports/net/cacti から
お手軽にインストールできる。
インストールの後は、/usr/ports/net/cacti/work/pkg-message
を読んでその通りに実行するだけでセットアップできる。
やり方が簡単、と言っても、もちろん自分が何をやっているのかは
知ってなきゃいけないけどね。
セットアップできてしまえばウェブからアクセスして、
ちょいちょい、とするだけでグラフ化完了。
簡単すぎる。
参考にした URL は以下。
特徴についてもまとまっている。
http://cacti.loaded.jp/
http://www.stackasterisk.jp/tech/systemManagement/snmp05_01.jsp
前に Cacti について書いた日記 --> [2005-02-08-2]
問題は、複数のソフトウェアが連携してる、ということかなあ。
- MySQL
- PHP
- PHP の extension いくつか
- RRDTools
- Apache
- NET-SNMP
これだけ動かすと以下の問題は当然発生しちゃう。
- サーバ資源をかなり消費しちゃう
- 設定のためにそれぞれのソフトウェアについての知識が必要
- セキュリティ対応のためのアップデート等の、
メンテナンスに苦労しそう。
とりあえず試用しながら様子を見るつもり。
http://www.microsoft.com/japan/licensing/openvalue/default.mspx
Open Value ライセンスは、最新の OS + Office Professional が
15,500 円 / 年 で利用できるライセンス。
古いOS、または現行からの移行の場合には 1年目は半額になる。
移行キャンペーン
http://www.microsoft.com/japan/licensing/campaign/openvalue.mspx
ポイントは以下
- すごく古いものを除くすべてのバージョンの OS が使える
- すごく古いものを除くすべてのバージョンの Office が使える
- OS も Office も Professional Edition まで使える
- 3年契約、年額使用料払い
- 永続ライセンスではないので、契約期間が終わると利用できない
- 全社で導入しなければいけない
- 技術サポート等のサービスも全部付き
通常のライセンスだとお金の管理の点で、
- 一括で3年分のお金が一度に出ていく
- 資産管理等が面倒
という問題があるんだけど、サブスクリプションライセンスだと、
資産管理する必要はないし、年間払いだし、ということで、
予算計画を立てやすい、というメリットもある。
このライセンス発表と同時に、ライセンスの販路の変更も
アナウンスされている。
パートナーから卸すのではなく、通常の流通ルートに乗せる、
という形態で販売するらしい。
今までは、大規模顧客向けのライセンスは、
パートナーに管理をしてもらうようにしていたけれど、
そういう量があいまいになりがちなライセンスもマイクロソフトで
ちゃんと管理できるようになったよ、ということなんだろうな。
広く薄く取れるような体制が整ったよ、ということね。
黙認していた違法PCを本気で撲滅する気満々な気がする。
ヤマダ電機の格安リサイクルPC用に格安で、
Windows ライセンスを提供している、というのも、
広く薄く取って、その代わりに黙認していた違法PCを
本気で撲滅するぞ、という戦略の一貫だと思う。
どうでも良いことだけど、資料を見ると、
Microsoft ソフトウェアへの投資を....
と書いてある。
ちょっとカチンとくるね。
OS や Office にかけるお金って、コスト(費用)じゃないの？、と。
追記)
小さい会社や個人事業主であれば、
Microsoft Action Pack サブスクリプションもお勧め --> [2005-03-31-8]
これだと、開発ツールとか全部入りで、10ライセンス付いて
なんと 37,800円。
http://blog.bulknews.net/mt/archives/001852.html
新しいサービス立ち上げには、他のサービスと連携するための
こういう API の実装は必須だと思う。
認証が今後のインターネットにおいて重要なものになるのは
間違いないけど、認証機構の標準についてはまだ、これだ、
という機構はない気がする。
認証についてのパネルセッションとかどこかでやらないかな。
http://biz.ascii24.com/biz/news/article/2005/11/07/658934-000.html
http://pcweb.mycom.co.jp/news/2005/11/08/102.html
過去の日記をあさったところ、
KAME を最初にインストールしたのは 6年半前だったらしい。
http://www.pochi.cc/~sasaki/diary/199905.html?to=199905101#199905101
アドレスを割りあててもらったりいろいろ遊んではみたけど、
今だに生活で IPv6 は使ってなかったり。。。。
IPv6プロトコルスタックインストール大会があったのもその頃なのね。
http://www.pochi.cc/~sasaki/diary/199906.html?to=199906261#199906261
この時に貰った kame ロゴシールは、
今も PORTEGE 3020CT に貼り付けられております。
この頃は IPv6 を真面目に勉強したけど、その後は勉強していない。
だいぶ知識が古くなっているはずなので再度勉強しなきゃいかんのよね。
IPv6 再入門、みたいなチュートリアルセッションどこかでやんないかな。
ちなみに残念ながら KAME ぬいぐるみは持ってません。
http://pcweb.mycom.co.jp/articles/2005/11/07/freebsd/
家のサーバの作り直すには良いタイミングかのう。
暇を作る必要があるな。年末か？。
Wiki 等にまとめといたほうが良い気もするけど、
思いついたときに書くのが ChangeLog way!。
○リモートオペレーションが快適になる
1つのコネクションで複数のターミナルが使える。
キーボードから手を放さなくてもサクサク画面が開けて、
画面を切り換えられるのが素敵。
慣れると複数の窓を開いていたのが馬鹿馬鹿しくなる。
○安心感が違う
セッションが切れても前の状態に復活できる。
回線が不安定なときに重宝する。
回線が切れて、あああ!、ということがなくなる。
サーバが再起動すると、あああ!、になっちゃうけどね。
作業の途中でも接続を切ってノートPC等を閉じることができる。
○ペア作業で重宝
1つの窓を複数人が操作可能なので、
ペアオペレーションやペアプログラミングするときに便利。
リモート環境にいても使えるし。
ペアオペレーションのベーシックなやり方。
- 自分の操作するターミナルを画面右側に配置
- ペアの相手の自分の操作するターミナルを画面左側に配置。
- メインオペレータがコマンドを打って作業を行なうのを見たら、
ペアオペレータが確認コマンドを打って確認する
- 会話はできれば記録が取れるチャットで行なう
http://www.morishima.net/~naoto/software/elscreen/
via http://www.kunitake.org/xoops/modules/weblog/blog-287.html
Mew でメールを読み書きする画面から、他のバッファに移ると、
画面の分割具合が微妙で、その都度 C-x 1 とかを打ち直すことになる。
バッファの操作は指が覚えてるのでそんなに困ってないんだけど、
分割やバッファの設定を保存したまま別のバッファを開けると、
たしかに便利そうだ。
/usr/ports/misc/elscreen からインストールできたので、
ちょっと使ってみるつもり。