「 ウェブ時代をゆく」を読んだので部分的にアウトプット

ウェブ時代をゆく ─いかに働き、いかに学ぶか (ちくま新書)

ウェブ時代をゆく ─いかに働き、いかに学ぶか (ちくま新書)

この本↑を読んだら妙にoutputしたくなった。「ウェブ進化論」の続編で梅田望夫著の本です。僕がIT業界に興味をもったのは大学1年の時にウェブ進化論を読んでからで、プログラミングなんて1度もしたことないのにプログラマバイトを何社も受けたのを思い出します。(今の会社以外は全て落ちたんですが。。。。)
当時はプログラミングが好きというより梅田さんがいうあちら側のシステムがどうなっているのか知りたいという願望の方が先にあったような気がする。そんなもんだからその時と今ではウェブに対しての考え方が違うことを再確認したので、ここで「ウェブ進化論」、「 ウェブ時代をゆく」について自分なりに思ったことをまとめます。(てか、作る側にまわっているので当然と言えば当然なんですが。。。)

まず梅田さんはネットに対してオプティミズム(楽観主義)を前提にして問題提起を進めています。これは作者がウェブの力を誇張してしているのではなく、ウェブ進化の先頭に立っているオープンソースプログラマの精神がそうだからです。この前提がないと梅田さんの議論が成り立たないので。。。。

googleオープンソースについて
この本を読むとたいていはgoogle信者になってしまうような気がします。クールでクリーンでオープンで固定観念に問われない、ネット世界の新栄企業て感じで。実際に「世界中の情報を全て整理する」という信念に基づいてgoogleは世界最大のサーチエンジンカンパニーになりました。僕がgoogleオープンソースに初めて触れたのはgoogle MapでjavascriptでhtmlにMapを表示させる簡単なプログラムを書いたのを覚えています。google Mapの実装は結構簡単で、javascript初心者でも1,2週間もあれば作れるてイメージを受けました。(あくまで個人的なイメージですが)
こんなに簡単にajaxを取り込んで、ユーザーに負荷をかけないリッチなサイトがタダ同然で作れるなら、HPを出してる会社なら取り込みたくなる。現在ではgoogle Mapが飲食店のHPで動いてのは当たり前になりました。(他にもYahoo Mapなどもありますが)このようにMapユーザー数が増えれば増えるほど、google Map→google searchという流れは出やすいわけで、googleはこれを狙ったオープンソース公開であったことは言うまでもありません。このように、googleはオープンにサービスを提供しているけど、それをユーザーが利用する時は全てがオープンにはならないてこと。ここがgoogleが作り出すオープンソースLinuxの様なオープンソースの相違だと思う。決してgoogle批判をしてるわけではなくgoogleでもyahooでも、企業なんだからユーザーを取り込もうとするのは当然。このように企業オープンソースでもユーザーが使いやすいなら、取り込んでいくのがウェブの特徴であると捉えて、相違があることにも意識したいと思う。

・お金を稼ぐことに興味がないリードプログラマについて
このようなエンジニアについて外の人には理解しがたいような印象を持つことが多いです。絵を描くのと同じように、アプリケーションやシステムを作ってもお金に換えることをこれっぽっちも考えていない人が世界中に沢山いて、この人たちがソースコードをオープンにすることで、ウェブ技術の進歩に大きな影響を与えていることがかなり重要だと思う。これはプログラマーをやってよく分かったけど、純粋に面白いという好奇心が生まれて、バイト代が出なくても家で仕事のプログラムを書くことはざらです。それがまだ創造されていない未知の物だったらなおさらだと思う。
本書ではこのような人たちが、自然な形でリアル世界が受け入れるような社会になるようにと問題提起しています。
それと同時に「高速道路渋滞論」について書かれている。実際に、あらゆるネットを利用できる人々がweb2.0によって高速に情報を収集することができ「時間」、「距離」に関係なく渋滞が見えるまで知識を得ることが容易になっている。では渋滞が見えたら、そのまま高速を突き進むのか、それとも高速を降りるのかという進路選択である。個人的には高速を降りて進む方法を考えています。自分がエンジニアとして作ることに好奇心がわくことが、学生だからではないかという疑問がかなりあるからです。時間があって、責任がない環境とその反対では全くもってその時の重要性や好奇心がわく場所が違うと思うからです。何よりお金を稼ぐことに興味がある方なので。しかし、こればかりは志向の問題で、お金を稼ぐことに興味がないリードプログラマの人生は楽しいてことはある程度想像できる。

・志向の共同体について
なんか哲学ぽくなりますが"志向"について。梅田さんの志向についての考えを読んで、自分が志向=人が持つ価値観と考えてきたと思った。(てか、こう解釈しました。)
人間は志向が類似している方向にベクトルが向いていて、その方向に進んでいるように考えるとかなりすんなり受け入れられることが多いような気がする。あたりまえだと思うけど、小学、中学と比べ、高校、大学の友達の方が志向が近い人が多いと思う。てか、大学ではある一定の志向の一致がある上に人間関係が成立しているとも考えている。リアルでの自然の流れでは、小学→中学→高校→大学→大学院とステップしていかなければ志向の共同体を形成できないのも、ネットではSNSなどを通して簡単に形成することができる。だからこそ、ネットでは積極性がリアルよりもとても重要で自分から何かアクションしなければ何も無い世界。(リアルでも積極性は重要だけど)
また、梅田さんは志向性を模索する方法として「ロールモデル志向法」を提案している。これは自分の志向性(何が好きかとか)を外に探すことで情報を収集することらしい。これは自然とやる行動の様な気がするが、やりたいことが見つからないフリーターが増えているのは、ここら辺が漠然とした人が増えてるてことかもしれない。


以上でととりあえず3つだけまとめたけど、真面目に書きすぎた。。。。。

DWRの入れ子JavaBean

これでかなりつまずいた。
入れ子JavaBeanとは例えば、


class ChildBean {
//
}
class ParentBean{
public ChildBean child = null;

public ChildBean getChild(){
return this.child;
}
public void setChild(ChildBean child){
this.child = child;
}
}

みたいなやつ。
このbeanをDWRでクライアントに持ってきてjavascriptjavaと同じようにbeanのbeanにアクセスすることができます。
ただdwr.xmlajaxで通るbeanはに書き込まなければいけなくて、作ってたアプリでたくさんのbeanを書き込んでたからname競合が起こって名前が変わっていた。それに気付かずに2時間ほど悩んだ。。。。
name競合の問題はstrutsでも色々と出てきて設計のまずさを感じる場面が最近多い。バイトも来週で終りなので仕様書をまとめてヤバかっとこを見直さないといけないかな。

実装から理論を学んだ1年でした


四ツ谷からの眺望↑
あと卒研発表と卒論が残っていますが、今のメンバーと研究するのもほぼ終わりになった。大変なことばかりだったが、やりきった感がある。1年を振り返る会話が増えたので、ここでまとめます。
個人的には、研究もバイトも「実装」を中心に考えて、ひたすらプログラミングからサーバー構築もしてきた。理論が分からなくてもとりあえず実装したって感じ。で実装したら理論が気になってくる。それでも作っていって、どこかで理論本を読んでリンクしたりしなかったりする。時間はかかるけど"実装→理論"の方が「理解」を実感できる点では楽しい気がした。
また、将来の職種としてITコンサルやITアナリストなどを考えているから、この方法がよかったとも思っている。就職したらモノを作ることはしないからこそ、やっとくべきことでもある。
でも、大学院へいったらそうもいかない。ソフト開発の研究は別として、サーバーの研究としては"理論→考察→実装/構築"の流れは崩せない。動いたからそれでいこう、てことにもならないから。実装から入るていうめちゃくちゃな考え方もこれで終わりかな。。。。。

で、1年で新しく勉強した事はこれぐらいかな。

物理以外はすべて独学という荒行をした。てか4年までC言語を知らずにjavaを書いていたことも今となってはめちゃくちゃだなと思う。ほんとに無理あったけど、筑波でどれほど通用するものか楽しみでもあるかな。

rootログイン可能なrshサーバーの構築方法

忘れそうなのでメモ。
rootでログイン可能のしかもパスワードなしのrshサーバーの構築方法です。
セキュリティはヤバいので注意が必要です。
1. rsh-serverのインストール
rsh-serverがインストールされているか確認して、


rpm -qa rsh-server
なかったらyumでインストールする

yum install rsh-server
2. /etc/xinetd.d/rsh,/etc/xinetd.d/rloginの設定
rhs,rloginでアクセス制限を持たせるために/etc/xinetd.d/rsh,/etc/xinetd.d/rloginにrshアクセスを許可するIPアドレスをonly_fromに書く。今回は192.168.100.254からのアクセスを許可します。

only_from = 192.168.100.254
3. /etc/hosts.equivの設定
rshサーバーはTCP Wapper(/etc/hosts.allow,/etc/hosts.deny)による認証の後/etc/hosts.equivと/root/.rhostsを参照して、記述されているホストのユーザーに対してrshログインを許可する。まずは/etc/hosts.equivに許可するIPアドレスを追加する。

#echo 192.168.100.254 >> /etc/hosts.equiv
5. /etc/securettyの設定
このままではrootでログインすることはできないので/etc/securettyにrshとrloginを追加してrootログインを許可する。

#echo rsh >> /etc/securetty
#echo rlogin >> /etc/securetty
6. /root/.rhosts(もしくは/etc/.rhosts)の設定
これはデフォルトでは無いファイルなのでファイルを作成してから、許可するIPアドレスを書き込む。5.6.でrootでの接続を許可したことになる。

#echo 192.168.100.254 >> /root/.rhosts
7. rshの自動起動設定
rshを自動起動するように設定する.

#chkconfig rsh on
#chkconfig rlogin on
最後にxinetdを再起動して終わりです。

#service xinetd restart
8. rshサーバーの動作確認
以下のコマンドでrootログインできるか確認する。

rsh -l root
設定がうまくいっていればパスワードなしでログインできているはず。
・port 544 Connection refusedが出たら
このようなエラー出たら、色々と原因があるらしいが/etc/xinetd.d/rsh,/etc/xinetd.d/rlogin周りがあやしい。only_fromに2つ以上アドレスを指定したい場合はスペースで連続記述する。またdisable = noになっている必要があるらしい。

DWRで受信中インジケーター表示をする+受信完了と同時に関数に移る方法


今日バイトっでやったことまとめます。DWRajax受信完了を待って次の処理をしたいときがある。
例えば、以下のようなプログラムを書いたとする

ajaxでサーバーからデータをもってくる
      ↓
もってきたデーターを使ってhtmlを生成する
      ↓
生成したhtmlの要素(buttonやformなど)にイベントを登録する

通常ではajax受信後はcallback関数で処理させて終わりだが、その後もプログラムを続けたいときがあるが(グローバル変数がcallback内からではアクセスできないから外に書くときとか)、そこでバグが発生する。これは、ajaxで持ってくるデータの量や通信速度によって受信が終了する前に次の処理にいってしまうためイベントが登録されないからである。この問題を回避するために、DWRのプロパティか何かで受信状況のstateを取得できないかと思って探してみたんだけど、見つからなかった。。。。。。
しょうがなく、javascriptで以下の2つを実装することにした。

・受信中のインジケータを表示させる
・表示終了と同時に次の処理に移るようする

要するに、画像と連動させて表示終了を受信完了と見て次の処理も進めるてことです。
プログラムは以下のサイトのものを参考に少し修正しました。

受信中のインジケータを表示させる

    • インジケータ オブジェクト


function jsgt_Indicator(src)
{

this.div = setIndicatorDIV(src);
this.indi_append = indi_append;
this.indi_start = indi_start;
this.indi_stop = indi_stop;

this.img = new Image();
this.img.src = src;
//終了フラグ
this.FIN_FLAG = false;

function setIndicatorDIV(src){
// インジケータを出力するdiv
id = "_indicator"+(new Date()).getTime();//idを生成;
this.div = document.createElement("DIV") ;

// インジケータ用DIVのデフォルト値(インスタンスで上書き変更できます)
this.div.style.position = "relative";
this.div.style.top = "0px";
this.div.style.left = "0px";
this.div.style.width = "0px";
this.div.style.height = "0px";
this.div.style.margin = '0px' ;
this.div.style.padding = '0px' ;

return this.div
}

function indi_append(id){
if(typeof document.getElementById(id) != 'object')return;
document.getElementById(id).appendChild(this.div);
}

//インジケータ スタート
function indi_start(){
this.FIN_FLAG = false;
//サイズを与えることで表示する
this.div.style.height ="12px";
this.div.style.width ="auto";
this.div.innerHTML = '<img src="'+this.img.src+'">' ;
}

//インジケータ ストップ
function indi_stop()
{
this.div.style.width ="0px";
this.div.style.height ="0px";
this.div.innerHTML = '' ;
this.FIN_FLAG = true;
}
return this
}

表示終了と同時に次の処理に移るようする

// 監視タイマーのID
var g_IdViser = new Array();
// 監視器のの数
var g_NumViser = 0;
// グローバルカウンタ
var g_i = 0;
function setViser( cond , funcCall , timeVise){
// 条件が満たされれば、タイマーをクリアして関数を呼び出す
strFunc = "" +
"if(" + cond +"){ " +
"clearInterval(g_IdViser[" + g_NumViser + "]);"
+ funcCall + ";" +
"}";
// 監視タイマーをセット ( setInterval)
g_IdViser[g_NumViser] = setInterval( strFunc , timeVise);
g_NumViser++;
}

実装例
インジケータオブジェクトを生成して、スタート/ストップ関数をDWRの前後にはさむことで画像を表示することができます。ここで、インジケータの終了と次の処理を連動させるために、タイマーに次の関数を入れて指定秒ごとにフラグを見て、trueになったら関数の処理を始めるようにします。


<script>
//インジケータインスタンスを生成
var = new jsgt_Indicator('./pleasewait.gif') ;
//インジケータを追加するDIVを指定
window.onload = function(){indi.indi_append("");}
//インジケーター開始
indi.indi_stop();
//1秒ごとにフラグをみて次の処理に移る
setViser("'" + indi.FIN_FLAG + "'","next_func()",1000);

Test.setContent( in_data, function( back_data ){
///////callbackの処理
//

//インジケーター停止
indi.indi_stop();
});

//次の処理の関数
function next_func(){
///////次の処理



}

<!-- 画像を表示する場所-->
<div id="indidiv">

これで、受信完了よりも先行してプログラムは動かなくはなった。てかDWRの何かを使えば、受信完了の値を正確に取得できるはずなんだろうけど分からない。。。。

(参考サイト)
この人たちのおかげです。

PSP-1000とPSP-2000


ゲーマーでもないのに、PSPを2台もってる状況になった。はじめはPSP-2000を新品で買ったんだけど思っていた基盤と違ったのでCFWが入れられないらしく、中古で1000を買った。CFWが入ったら、2000は売るしかないか。。。。。

自宅サーバーをshutdownしてしまった→仮想サーバーの弱点について


昨日の風景↑大学から自宅のxenサーバー構築をしていたらゲストと間違えてホストをshutdownしてしまった。徹夜も決まっていたので完全に作業が中断した。研究もできない状況でげんなりしたので、企業や研究室での仮想サーバーの無停止運用について少し考えてみた。
仮想サーバーの弱点としてホストが停止したら、それにぶら下がっている全てのサーバー群も停止することがある。仮想化によって1台のマシンが持っているサーバーの数が多くなることから損害も甚大になる。そのことから、全てのサービスを1台で運用ことは無理に近い(普通のサーバーの場合でも同じことですが)。このような問題の回避方法としては、単純に同じ構成のサブの仮想サーバーをもう一台用意して、メインが停止したらサブを機能させて連続稼働させるのが一般的らしいが、そのための機能の自動化やサービスの同期なども、企業や研究室で導入する場合には重要なってくる。素早くサービスを再開できたり、再開したとしてもコンテンツが停止時と同じなくてはいけない。仮想化によって、いくら小スペースでロードバランスが取れていても、このような問題が考慮されていなのであれば導入を考えなおした方がいいと思う。(仮想化によるサービスの分散をしていれば、もっと複雑になると思うから)

(仮想サーバー無停止運用のソフトウェア)