VSS2013年05月24日 06時48分49秒

どうも、ご無沙汰でやんす。

つなぎの、というつもりでもなかったんですが、とりあえず 1ヶ月半ぐらいやらせていただける案件があって、食いつなぐためにもやらせていただいているんですが、その現場のネット環境が非常に厳しい (外部とのメールのやりとり NG、 Web 閲覧は Google Web検索、 Google Map、Yahoo のトップページ、 MSDN Library 以外は概ね NG、その他のプロトコルも当然 NG) 為、仕事自体もやりにくかったりでいろいろとフラストレーションを抱え込んだりもしているわけですが。

仕事の内容は ASP.NET で作られている業務用 Web システムの機能追加のお手伝いで、 ASP の部分、つまりは表示と UI 制御辺りの実装を主に… まぁ仕事の内容の話はいいや。古いバージョンに拘泥している割にはガッチガチに M$ 様の支配下にいらっさるようで、ソースコードのバージョン管理も VSS を使用、当然 Trac のようなタスク管理ツールや BTS はなし。線表も顧客向けのを Excel かなんかで書いてただけみたいで (Project ぐらい使えよ)、進捗管理とかスケジュール管理とかの概念自体が微妙に希薄な印象…。

で、 VSS なんですが、実はおいらはこいつを使うのは今回が初めて。いやーこれはこれはありがたい経験をさせていただいております限りでございまして…。おかげでこいつがネット上では情報収集および発信に熱心なプログラマーたちの間で何で嫌われているのかが理解できてきましたよ。使う前までは単にマージではなくロック方式だから嫌われているだけなんだと思っていたのですが…

まず戸惑うのは言葉の違い。これはまぁ方式の違いもあるので仕方ないことではあるのですが、チェックインという言葉は使ったことがなかったので… この辺は恐らくホテルのチェックイン・アウトと同義だと思えばいいのかなと。

ソースの取得 (Subversion 辺りでいうところの update) も微妙に戸惑いますね… 何で毎回「サブプロジェクトも取得」とか「ツリーを構築する」とかチェックボックスにチェック入れなきゃあかんのでしょう… んなもん指定した場所以下は全部落とせに決まってるじゃないですか… ていう。それでディレクトリが追加されていたりすると「ディレクトリ無いけどどうする? 作るの?」みたいな確認ダイアログをわざわざ出してきてブロックする… メール確認してたりで VSS ほったらかしにしてるとそのダイアログが裏に隠れちゃってたりして気がつかないまま作業開始しちゃって、あれ、直したって言われてたビジネスロジックの動きが変わってないなぁ、何か間違えてるのかなぁ… なんてことに無駄に時間を割いたり… orz あと自分でチェックインした以外の変更があれば「xxx を置換」ってログメッセージが出るから取得が終わったんだなって分かるけど、そうじゃないと何にもログ吐かんのな。キャンセルボタンが消えてるから一応気づきはするんだけど、時間かかるんだからせめてもうちょっと「終わったよ!」ってのアピールして欲しい ('A`)。

で、作業に入るわけですが、 Visual Studio は VSS と自動で連携していて、 Visual Studio 上で書き換えようとした瞬間に、そのソースファイルのチェックアウトをしに行ってくれるようになってる。まぁロック方式ですし、手動でやらされることを考えれば便利なんでしょうけど、間違えて触っちゃってアンドゥで直してそっ閉じしたファイルがチェックアウトしっぱなしになっていてチームにご迷惑を… みたいなのは方々で多発していらっさるんでしょうなぁとか思うとちょっと胸熱…。

ロック方式とマージ方式のどっちかが絶対に優れているとかは言うつもりはないです。普通の開発体制であれば同じファイルを複数人が同時に触るということはそうそうないですし、チェックインし忘れによる不便とコンクリフト発生時の面倒を秤にかけても仕方ないですし。個人的には、テキストファイルをテキストファイルとして編集するようなもの (ソースコードとか XML とか HTML とか) はマージ方式、それ以外 (バイナリファイル全般とか、 XML でも MS-Office のドキュメントみたいにアプリ上での状態まで保存するためにちょっといじっただけでファイル全体にわたって diff が出まくるようなものとか) はロック方式で管理するのがやりやすいかなとか思っていたりはするわけですが。 Subversion なんかはファイルの種類ごととかディレクトリごととかでマージ方式かロック方式かを指定できたりするのは良いですよね。

それから VSS では変更内容のログを残しておくという文化がないっぽいのも気になります。一応、 Visual Studio 上でチェックインを行う際にはログメッセージを記入することも出来るようにはなっているのですが、現場の人には「別に特に書かなくて良いですよ」とか言われてしまい、それでもなんか嫌なので何かしら変更内容を記入するようにはしていたんですが、変更履歴のログを見る機能とかそういえば使ったこと無いですね… (一応無いことはないらしい)。 この辺はちゃんとやろうと思えばやって出来ないことではないとは思うんですが。

ログと関連して、最近は Trac や Redmine などといったタスク管理ツールと連動させる使い方が結構広まってきていると思うんですが、 VSS にはそういうソリューションってあるんですかね? コミットログにはチケット番号を、チケットにはリビジョン番号を書いて相互リンクとかやると結構便利だったりするわけですが…。

そんなわけで、結論としては VSS 不便だなぁというお話でした。それでもこうすればもうちょっと便利に使えるよ、という話はあるのかも知れませんが、 VSS と Visual Studio で完結できない話であるなら、そも今の現場はネットからファイルをダウンロードすること自体フィルタリングで物理的に不可能なので、まぁ 1ヶ月半だし我慢しましょうという感じですかね。(*sigh*)

問題を生じる可能性のあるアドオン2009年10月17日 13時37分47秒

Firefox の主張

これ、どちらも Express 版の Visual Studio と一緒にインストールされたものだと思うのだが (製品版でも入るのかな?)、今日 Firefox を起動したらこんな alert が表示されて、ブロックされてしまいました。もともとこいつら 3.5 には対応していなかったよーな気もするんだが… (WPF はんなことなかったっけかな?)

IE のテーブルセルに width スタイルを指定する気力が失せる例2009年04月23日 11時13分33秒

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>

<head>
	<meta http-equiv="content-style-type" content="text/css" />
	<title>teble cell width test</title>
	<style>
table {
	width: 100%;
	border-collapse: collapse;
}
table td, table th {
	border: 1px solid #666;
}
table th {
	width: 10ex;
	background: #cef;
	text-align: right;
	padding-right: 1ex;
}
table td {
	text-align: left;
	padding-left: 2px;
}
	</style>
</head>

<body>

<table>
  <tr>
    <th>name</th> <td colspan="3">T.MURACHI</td>
  </tr>
  <tr>
    <th>age</th> <td>31</td>
    <th>sex</th> <td>male</td>
  </tr>
  <tr>
    <th>comment</th>
    <td colspan="3">
      Hi! I'm a fat programmer.
      I like music, playing, listening, singing, and so on...
      I own a company named "Harapeko Inc."
    </td>
  </tr>
</table>

</body>

</html>
  • Firefox での表示例:
    firefox で表示
  • Safari での表示例:
    safari で表示
  • IE7.0 での表示例:
    IE7 で表示

結論: 神は死んだ

…いや、とぼけている場合ではなくて、この現象、ネットでうまく検索することができないので、対策が分からずにいます。誰か教えて下さると有り難いデス…。

たかだか事務処理の不便の話を一般化したところで詮無き話2008年12月17日 09時34分52秒

後者は前者の記事に対する文化面での反論として秀逸だと思ったんだけど、その割にあんまり注目されてないっぽいのでリンクしてみた。

でもこれって、所詮は事務処理の不便にまつわる話でしかないのよね。だから池田氏もわざわざガラパゴスや北朝鮮を蔑視するような書き方しなくても、「事務処理上不便なのでそういうシーンではサイン・西暦・横書きで統一しましょうよ」、でとどめときゃよかったんじゃないの? とか思った。

一プログラマーとしても、そういう意味ではありがたい提言なのよ。サインならタブレットで可能だし (電子印鑑ってあるけど単なるビットマップだし…って最近のはそうでもないのか?)、西暦で統一されれば時刻管理は確かに楽だし (っていうか年号変わるたびにプログラム作り直しとかまぢあり得ねーし)、そして縦スクロール UI にマウスまでもが特化されちゃった状況で縦書き文章は扱いづらいし。

でもこれらってあくまで事務処理に限ったお話であるべきで、事務処理の都合のために文化まで捨ててしまえ、というお話になるべきではない。歳とるとその辺面倒なのでひっくるめてしまいがちなんだけど、周囲も周囲でその辺汲んで話し合わせてあげればいいのにwとは思う。

まぁその割には週アスだのだいもやんどだのの紙メディアが引き合いに出されるのは意味不明だし、掲載前の契約締結 (金銭面的なことを考えればとても親切な対応) を「失礼」だと斬って捨てるのはもっと意味不明だけんども。

XOOPS 使うのやめたっ2008年04月23日 21時02分36秒

とりあえずホダ塾入れてみたはいいものの、そこから先で右往左往。。。なに、CMS ってシステム突っ込んだらあとは全部ブラウザからできるものなんじゃないの? から始まり、メニューのカスタマイズに自由さを感じなかったり URI 規則 (あの必ず「module」って入る) が気に入らなかったり結局 PHP コード叩かなきゃいけなかったり基本がテーブルデザインだったりと知れば知るほど気に入らん事のオンパレード。そして如何にも Web デザイナー的なコミュニティー文化に毒されたテキストを読んでいるうちにおいらの XOOPS への期待はふにゃりふにゃりと萎えてゆき、代わりに別の欲求が腹の底から湧きあがってきてしまった。

そんなわけで、やっぱり XOOPS 使うのやめます。w

でも取り急ぎ企業サイトを作る必要はあるので (そうしないと会計報告ができなくなっちゃう…株式会社なのに)、とりあえず以下の方針で行こうかなと。

  1. とりあえず普通に HTML 書いて静的にホームページを作ります。そのために、サイト全体で共通する部分のテンプレートデザインをまず考えることにします。

  2. 企業の公式ブログを設置するかどうかは微妙ですが、設置する場合はおそらくサブドメインを設け、1. の HTML から普通にリンクして終了です (あるいはリンクしないかもしれない)。使うのはたぶん WordPress 辺りになると思います。

  3. 将来的にはやっぱり CMS が欲しいですが、そんな将来のために、 CMS は自作することにします。ちょうど、今仲間内のためにこっそり作っている掲示板システムの核の部分がそのまま流用できる可能性もあるので、うまくすれば年内にある程度出来上がってくるかもしれません。

とりあえずそんな感じで。晩飯食ってこよー。

とりあえずホダ塾入れてみた。2008年04月22日 13時39分52秒

XOOPS Cubeホダ塾ディストリビューション入れてみた。いろいろと勘違いとかもあって入れるだけでも随分と時間がかかったが。。。

ドメイン移転終わったらまた入れなおす予定なので、セットアップ手順をメモしておく。あ、一応、ファーストサーバのデルタ1・シリーズ対象ってことで。

  1. Apache を使える状態にしておく。 mod_php5 とかは既に入ってた。

    %su -
    %vi /etc/httpd.conf  # 必要に応じて。 AddDefaultCharSet noneoff とか
    %vi /etc/php.ini  # 必要に応じて。デフォルトで概ね大丈夫そうだけど
    %/etc/init.d/httpd start  # 既に起動中の場合は restart
    %ntsysv  # httpd にチェックを入れる。ソフトバンクIDC が停電しても自動起動するように
    %chown murachi:apache /var/www/html    # だっけかな? ディレクトリ名変えちゃったからもう忘れたw
    %chmod g+s /var/www/html
    %exit
    %cd /var/www/html
    %cat > test.php  # 動作確認後、すぐ消す
    <?php phpinfo() ?>^D
    
  2. MySQL を使える状態にしておく。これも最初っから入ってる。

    %su -
    %mysql_install_db --user=mysql
    %vi /etc/my.cnf  # default-character-set=utf8 にする (後述)
    %/etc/init.d/mysqld start
    %ntsysv  # mysqld にチェックを入れる
    

    /etc/my.cnf は大体こんな感じ。矢印付きが書き加えた行。

    [mysqld]
    datadir=/var/lib/mysql
    socket=/var/lib/mysql/mysql.sock
    # Default to using old password format for compatibility with mysql 3.x
    # clients (those using the mysqlclient10 compatibility package).
    old_passwords=1
    default-character-set=utf8  # ←
    
    [mysql.server]
    user=mysql
    basedir=/var/lib
    
    [mysqld_safe]
    log-error=/var/log/mysqld.log
    pid-file=/var/run/mysqld/mysqld.pid
    
    [client]  # ←
    default-character-set=utf8  # ←
    
    [mysqldump]  # ←
    default-character-set=utf8  # ←
    
  3. MySQL の root ユーザーを設定する。 set password がなぜか使えなかった。

    %mysql -u root mysql
    mysql> update user set password=password('password') while user='root';
    mysql> flush privileges;
    mysql> quit
    %mysql -u root  # これで入れちゃったら設定失敗
    
  4. MySQL にデータベースとユーザーを追加する。

    %mysql -u root -p mysql
    Enter password:
    mysql> create database xoopsdb;
    mysql> grant all on xoopsdb.* to xoopsuser identified by password 'password';
    mysql> update user set host='localhost' while user='xoopsuser';
    mysql> flush privileges;
    mysql> quit
    %mysql -u xoopsuser  # これで入れちゃったら設定失敗
    %mysql -u xoopsuser -p xoopsdb
    Enter password:
    
  5. ホダ塾Xoops を環境にコピーする。 chmod g+s をうまく使えばグループ apache で統一されるので、書き込み権限必要なファイルやディレクトリも chmod 777chmod 666 ではなく、 chmod g+w で足りるようになる。

    %cd
    %mkdir hodajuku
    %cd hodajuku
    %wget http://jaist.dl.sourceforge.net/sourceforge/hodajuku/hd_full_1_0_1b.tar.gz
    %tar -xzvf hd_full_1_0_1b.tar.gz
    %cp -R html/* /var/www/html/
    %su  # XOOPS_TRUST_PATH のコピー先ディレクトリを先に用意する。グループを apache で統一するため
    %mkdir /var/www/xoops_trust_path
    %chown murachi:apache /var/www/xoops_trust_path
    %chmod g+s /var/www/xoops_trust_path
    %exit
    %cp -R xoops_trust_path/* /var/www/xoops_trust_path
    %cd /var/www/html
    %chmod g+w cache uploads templates_c mainfile.php
    %cd ../xoops_trust_path
    %chmod g+w . cache uploads templates_c modules/protector/configs
    
  6. ブラウザからサイトにアクセスすると、インストールが始まる。指示に従って進める。言語は ja-utf8 (だっけ?) を選択。

  7. すべてが終わったら、不要なインストールの残骸の除去と、権限設定の修正を行う。

    %cd /var/www/htdocs/
    %rm -rf install
    %chmod g-w mainfile.php
    

Tue Apr 29 21:19:28 JST 2008 - 追記

以下の修正をしました。指摘 thanks >ぐるりさめ。

  • × AddDefaultCharset none
    • → ○ AddDefaultCharset off

ちなみに、実際の鯖の設定を確認してみたら、ちゃんと「off」になってた。何を見て間違えたんだろう>ヲレ。。。

最もタメになる「初心者用言語」2008年02月05日 01時43分50秒

いくつかの視点があります。断定できるほど確からしい結論が出せていないのでとりあえず列挙してみます。

1. 言語というよりツールとして、何が出来るのかが見て取りやすいもの

多くの人は、プログラミングを学び始めるきっかけは、目的を伴うのではないかと思っています。そこで、その目的を達成するまでの道のりが明確であればあるほど、初心者を呼び込みやすいのではないかと思っています。

この場合、以下のような例が挙げられるのではないかと思います。

  • ブラウザの画面上で、Web ページに動きを加えたい。 -> JavaScript
  • CGI 的なもの (いわゆる Web アプリケーション) を作りたい。 -> PHP, RoR
  • ゲームを作りたい。 -> 時代によってさまざまだが、旧くは N-BASIC 的なものから、 VB, HSP, Flash (ActionScript) など。あるいは ASCII のツクールシリーズ的なゲーム作成ツール。
  • 家計簿っぽいものを作りたい。 -> Excel VBA
  • グループウェア上で掲示板的なものを作りたい。 -> LotusScript

ごめん、最後のほうはかなりヤケッパチw

よーするに、ただ漠然と「プログラミングやってみようかなぁ」で始めちゃうと持続しづらいので、何らかの「やりたいこと」あるいは「作りたいもの」を達成するために使うと便利な「ツール」として、これらのプログラミング言語を触れ始める、というのは、入り口としては最もポピュラーなんじゃないかと思う。

昔はそれこそ入り口が本当に BASIC か機械語 (ダンプモニタ) しかなかったものだから、いやでも「プログラミング」というものを意識せざるを得なかった。 HyperCard 的なものが出始めた辺りから、いつしかプログラミング言語は開発環境とセットで「ツール」としての存在感を増し、結果として、多くの初心者に「プログラミング」を意識させないようになっていった。 Microsoft が自社の開発環境に Visual *** なんて名前をつけているのも、そういうニーズを意識しているからこそなんじゃないかと思う。マウス操作で UI が簡単に作れて、ハンドラにロジックをちょこっと加えれば、ほ~ら、あっという間に業務アプリのできあがり~、みたいな。

で、そこから、「プログラミング」という概念そのものに興味を抱くようになるか否かは、その人次第としか言いようが無いと思う。個人的には、自分がやっていることがプログラミングなのかどうか、ということに自分で判別か付くようであれば、割と素質があるんじゃないかと思ってる。一方で、ググって見つけたサンプルを、ただワケも分からずにコピペして、動いたからこれでいいやで済ませちゃっている人は、頭では「俺ってプログラミングやってる、すげー」とか思っているつもりでも、実際にはプログラミングになっていないので、間違っても将来プログラマーになろうとか思わないで欲しい。

こういう気付きのきっかけを、プログラミング言語の仕様が手助けするということは、残念ながら無いと思う。優れた抽象化概念を備えた応用性の高いプログラミング言語は、大抵の場合、こうした気付きを超えた人たちが後から興味を示して入っていくものなので、そこに期待はしないほうがいいと思う。

2. お金がかからず、準備に手間もかからない環境

次に重要なのはこれじゃないかなぁ。今の時代で考えるなら、大抵の初心者の所持する PC には Windows が入っていて、 MS-Office が入っている。この状態で既に整っている開発環境といえば、 Javascript と VBA ぐらいじゃないかと思う。

一方、 Windows であっても、ただでダウンロードしてインストールできる開発環境というのは物凄くたくさんある。 VC++ でさえ、MFC を使わないのであれば、 Express 版の Visual Studio をインストールすれば、プログラミングからデバッグまで完全にこなせるようになった。ホントいい時代だよ。

そうした中で、初心者が食いつきやすくなる目安として重要なのは、開発環境自体のセットアップの容易さと、面倒見のよさと、メンテナンスの不要さ、なのではないかと思う。 HSP なんかが同人ゲーム作家に喜ばれる一番の理由はそこなんじゃないかと思う。とりあえず HSP をインストールしてしまえば、大抵のものはそれ一つで作れちゃうからだ (使ったこと無いので嘘かもしれませんが ^_^;)。Python なんかも実はそういう意味での魅力がある (らしい)。ブラウザがあればとりあえず動かせちゃう JavaScript なんて、目的が目的ならその極北なんじゃないかとも思う。

一方、Perl でも頑張れば Windows 上でゲーム作りに利用することも出来なくは無いんだけれども、それは ActivePerl を入れただけでは多分無理で、例えば DirectX を扱うためのモジュールは存在すらしない (いや、物凄く一生懸命探せばネットの片隅に転がってはいるかもしれないけど)。ウィンドウイングは Win32::GUI を入れれば可能だけど、そもそも Windows 上でモジュールを入れるためには ActivePerl に付属の ppm というツールを用いなければならないことを知っていなければならないし、最新版を使いたければ cpan を動かすために Visual Studio を導入しなければならず、しかも VC++ 2005 で cpan によるコンパイルを通過させるためには、既存のモジュールの一部を修正しなきゃならなかったりする。そしてそうやって頑張って Win32::GUI を使えるようになった、じゃあ使ってみようって弄ってみてから、実は GDI が使えないことに気がついてひっくり返るというオチ。。。初心者が「やりたい」と思えるようなことにたどり着くまでの道のりが、あまりにも遠すぎるのだ。

3. 「プログラミング」そのものに興味を持ち始めたら…

そんなわけで、個人的には入り口は低くて単純でツールとしての使い勝手に長けているもの、というような、計算機科学者や言語マニアがあんまり重視しない部分を特徴とした環境でもいいのではないかと思う。まぁ、時代が時代だし。

ただ、一方で、そうした活動を通じて、「プログラミング」という概念そのものに、あるいは更には「コンピュータ」とか、「通信」とか、情報学的により広い、よりメタな概念に対して興味を抱くようになった人に対して、そういう人が高みを目指すまでの「道」としての役割を担う存在っていうのは、絶対に必要だと思う。

これは情報学全般という意味では実はプログラミング言語に限ったことではなくて、他の多くの技術的知識に通じるものだとも思う。セキュリティなんてのもその一つだわね。後はネットワークだとか、並列処理だとか、アルゴリズムや数学的なものだとか。

で、プログラミング言語に関して言えば、おいらはここで重要なものはやっぱり「古典」だと思う。そういう意味では、構造化言語でありコンパイル言語であり、「ポインタ」なんていう、いまどきの「参照」なんかよりずっと原始的な概念を用いている言語ということで C 言語、それから C よりも不自由な Pascal 、関数型言語の始祖 LISP、コンピュータがどう動いているのか、っていう部分のリアリズムを見せてくれるアセンブリ or 機械語、といった辺りから、性に合ってそうなものを幾つかかいつまんでみるといいんじゃないかな。

オブジェクト指向を理解するための言語ってのがイマイチ思いつかないんだけど、それこそ Ruby が良かったりするのかな? Java 通はオブジェクト指向ってよりも、デザインパターンドリブンでシステムを組み上げたい人向け、って感じがする。この辺は、古典とは言いがたい「次のステップ」と言うべき存在で、初心者が目的無しに使うべきものかどうかは微妙な気がする。

4. まとめ

結局「この言語がいいよ!」みたいな形でまとめることは、おいらには出来ない、ってのが結論なんだけど、一方でプログラマーを育てるためには、まず未経験者を初心者にしなきゃいけないってこと、それから初心者がレベルアップするための道筋が必要ってこと、この 2点がかなり重要なんじゃないかと思う。逆に、この 2つさえ乗り越えちゃえば、プロの現場に送り込まれても自分で経験を能力へと精進できるようになるんじゃないかと思う。

だから、処方箋としてはこんな感じかなぁ。

  • 餌は必要だよ。VB や HSP や Flash や PHP みたいに、「○○をやりたい (or 作りたい) ならこれ!!」っていうのはあってもいい。
  • 餌は手に届きやすいところに置いた方がいいよ。自分で料理しないと食えない餌に食いつく未経験者はあんまりいないよ。
  • 上級者は初心者と積極的にコンタクトをとるべきだと思うよ。その為には初心者に喜ばれやすそうな技術についてもある程度知識を持っておいたほうがいいかもしれないよ。
  • 分からないところがあると表明する初心者は徹底的に歓迎しよう!! 疑問を抱くということは興味があるということ。こういう子をほったらかしにしちゃいけない!!!
  • より深く学びたい人が、その道筋を見つけられるような環境があるといいと思うよ。掲示板や ML は殺伐となりがち (職人気質の恐いお兄さんがきつい言葉を乱発する場になりがち) だからあんまりオススメできない。ブログもいいけど、本当は地域にサークル的なものがあって、リアルな交流があるほうがいいのかもしれないね。あとは、より良い情報へのアクセスをより容易にしていくこと。これはもう、Web 上での発信に尽きると思う。

蛇足

ところで、PHP のような、言語仕様がイマイチな環境に慣れてしまうと、プログラミングに悪い癖が付く、という話が流布されているけれども、これって真実なんだろうか? おいらは単に、世界観の狭い人が、より良い方法に気付くことができないまま、良くない方法をとり続けているだけのことなんじゃないかと思っているんだけど、どうだろう?

8bits マイコン時代の BASIC だって、今からすれば決して褒められたような言語ではないけど、 Nxx-BASIC から入ったっていう人はこの業界に決して少なくない。でも、そういう人たちでも、今ではずっとずっと抽象的な概念を理解し、うまく活用してプログラムを書くことができている人がほとんどだと思う (おいらも僭越ながらそういう一人に数えられる程度には自信がある)。結局重要なのは入り口の質ではなくて、その後の経験と、当人自身の向上心なんじゃないかな。

MS Office 2007 のサイトからオンライン登録しようとするとオレオレ証明書が表示される件2007年11月30日 15時48分03秒

Microsoft Office 2007 インストール後に表示されるこのサイトから、「無料のオンラインサービスへの登録」をクリックしたら、上図の画面が表示された。オレオレ証明書は信用するわけにはいかないので、これより先に進めませんっ><

Trac 微妙。。。2007年11月13日 00時47分47秒

職場で Trac というタスク管理ツールを使っているのですが、最近なんだかこいつが微妙だなぁと思えるようになってきた。

どういうことかというと、タスク管理って、出来るだけ細かく細かく再分化したほうが、仕事の能率は上がりやすいんだけれども、このツールはタスクを細かく管理するには機能が豪華すぎちゃって、細かくタスクを設定するだけでひと苦労な上に、そのメンテナンスにもひと苦労だったりするので、使い込めば使い込むほど使いにくくなってしまう感があるのだ。

おいらとしては、仕事内容について長々と説明するための欄も、ステータスの多くも省いてしまって、タイトルと、コンポーネントと、モジュールだけ入力できれば十分かな、とか思い始めている (強いて言えばそれらプラス 3段階程度の優先度かな)。タスクごとのメモ用掲示板も必須だけど、Wiki 文法使えるようなリッチなやつじゃなくて、一行コメント程度の軽いやつでいい。

コンポーネントの選択もコンボボックスから選ぶ感じじゃなくて、マイリストにコンポーネントのリストがまずありきで、その中から選んで付近の「追加」ボタンを押すとその場にすぐ入力欄がぽこっと出てきて、タイトル入力するともうタスク追加完了、残りのステータスは随時入れてね、みたいな。

でもそれだけシンプルながら、しっかり svn との連携が取れていたりして、付箋紙的な UI でちゃっかりコードレビューとか出来たりするといいかも。でもプラグインで機能追加みたいな仕掛けは要らない。

あと、Trac を BTS 代わりに使うのはやっぱり無理があると思う。BTS ともなると今度は逆に Trac ではステータスが足りなくて力不足なんだわ。そういう意味でも Trac ってなんか微妙。。。

タスク管理と Wiki とソース履歴管理の統合環境って強力だからとってもいいツールではあるんだけどね。。。作るか?

Microsoft が「気にならない存在」になってしまっている件2007年04月10日 13時23分13秒

邦訳を読んだ後で /. での反応を見ると、いまどきここに集まってくるのは文盲か、あるいは昔を懐かしむことしかできないじじぃばかりなのか、と思えてしまう。そういう意味ではサプライズだった。マジびっくりした。

「死んだ」という表現が誤解を招いている、という意見が多いようだが、例えこれを「脅威ではなくなった」と読み替えたとしても、いまいち何のことを言っているのだかよくわからないという人は多いように思う。この辺のコメントがモデレーションで支持されているのを見るにつけ、つくづくそう思う。

その背景には、少なくともこの国では、今後、多くのアプリケーションが特定の OS のアーキテクチャ上で動作するスタンドアロンソフトウェアから Web サービスへ移行してゆくであろうという実感も危機感も非常に小さい、ということが挙げられるんじゃないかと思う。なんだかんだ言って、たいていの主要なアプリは Windows 上で動いているし、「それで十分だ」と思っている。MS-Office を捨てて OOoGoogle Docs を利用する「理由がない」し、Windows を捨てて Mac OS X や Linux を選択する理由もない。

しかし、Paul Graham はそもそもそんな趣旨のことは一言も言っていない。君たちは以下のセンテンスを理解することもできないのか?

マイクロソフトは80年代後半からおよそ20年にわたり、ソフトウェアの世界に影を落してきた。マイクロソフトの前には IBM がそうだったと言える。私はこの影をほとんど無視した。私はマイクロソフトのソフトウェアを決して使わなかったので、間接的にしか影響を受けなかった――例えば、ボットネットからスパムをもらうとか。つまり私はマイクロソフトに注意を払ってなかったので、その影が消え失せたのに気づかなかったのだ。

Microsoft のソフトウェアを使わずにいた Paul Graham にとって、そもそも Microsoft による脅威は間接的なものでしかなかったのだ。逆に言えば、Microsoft の脅威にさらされるべき人間とは、すなわち Microsoft のソフトウェアに依存する生活を送っている人間のことである

例えば、Windows ユーザーは、Windows に脆弱性があれば、その脆弱性をつく攻撃の脅威にさらされる。もちろんそれは、Windows じゃなくても同じことだが、一方で、そのユーザーにとって Windows 以外の選択肢がありえないのだとしたらどうか? 例えば Windows でしか稼動しないアプリケーションをどうしても使う必要があるならば、彼は Windows に脆弱性があることを知りながら、それでもなお、Windows を使い続けなければならない。

Windows はかつて、独占的な地位を保ち続けてきた。この状況は、少なくとも日本国内の事務処理シーンを見る限りにおいてはあんまり変わっていないようにも見える。しかし一方で、Windows 以外の、あるいは Office 以外の、IE 以外の選択肢が、さまざまに誕生した。Mac OS X が Microsoft を殺した要因のひとつとして数えられているのは、シェアの問題ではなく、Office が稼動し、他の多くの似たようなアプリケーションが稼動し、もちろん Web ブラウザも稼動し、UI もユーザーフレンドリーで、なおかつ UNIX ベースであることから開発者層も取り込んだ、といったことから、多くの人間にとって 「Windows 以外の選択肢」たりうる要件を備えているからなのではないのか?

つまり、実用面で言えば、PC の世界において Windows は多くの人々にとって「唯一の選択肢」であった状況が、崩れてきているということだ。

この状況は、アプリケーションの稼動領域が特定の OS のアーキテクチャから Web へと移行してゆく流れが追い討ちをかけている。Gmail は Outlook の領分を侵食し、Google Docs は将来的には Office の領分を侵食するかもしれない。もちろん、現在 Web でできていることが、デスクトップでできていることのすべてを侵食しているわけではないし、この点について実感がわきにくいのも無理はない。しかし、少なくともシリコンバレーに存在する多くの先鋭的な企業・技術者は、特定の OS アーキテクチャで稼動するアプリケーションを作ることへの関心を失っており、とっくの昔に Web へとその矛先を転換している。

そういう状況で、かつての Microsoft のような、独占的な地位による脅威を持ちうる企業があるとしたら、それは Google かもしれない、というのは納得できる。何故か。

API への依存だ。

もしも今後、多くの企業が Google の提供する多くのサービスや API へ依存してゆくことになれば、それらの仕様は Google の気分次第でどうとでもされてしまうことの危険性に晒されなければならないことになるだろう。

もっとも、個人的には、Google が脅威となる可能性については、あまり心配していなかったりする。インターネットがインターネット足りうる以上、インフラのすべてが Google のみに集約するということは考えにくいし、すでにインフラを持っている企業であれば、いくらでも Google が提供するサービスの代替を提供できるだろうし、Google とはまったく関係のないサービスも、いくらでも出てくるだろうと思う。かつて Windows という OS の上でシステムを組まなければならなかった時代に比べれば、Web への参入障壁は、決して高くはないのだから。