ウェブ時代をゆく

とりあえず一回目、読みました。


ウェブ進化論はネットというのはこうだ!という教科書みたいな本でしたが、

ウェブ時代をゆくは、十人十色な人生に関する本だと思うので賛否両論分かれると思います。

時代の流れというやつを感じて、「じゃあどーすりゃえんなら?」と思ってる人は読まざるを得ない本かと思います。

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

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


あとはうだうだ書きますと、


ぼくは、おそらくは読者として想定されている、何をやってもそれなりにこなせるけど、突出した何かを未だ見出せていないナナロク世代です。そんなに本を読むという経験が豊富なタイプじゃないので、読むスピードは遅いのですが、目的がはっきりしてたから「読書を楽しむ」ではなく斜め読みしちゃいました。

その目的というのは前のエントリで書いた、ウェブ時代を生きていかなくても、IT産業を横目にみながら、SI産業は衰退しながらも残り続ける。しかし、この息苦しい世界を抜け出す=ウェブ時代を生きていく=ご飯を食べていくならどうやって?というところです。


これには現状広告収入モデルしかなく、現状難しい。という内容でした。


実際、困難だなと思ってます。


より多くの自由と、自分の勉強を兼ね、はてなではない別のところでサーバを立ててブログを書いたりもしてるのですが、そこで得られる検索連動広告による収入なんてのは、1年ぐらいかけてもショボいもので、1日リヤカーひいてアルミ缶拾って歩く方が効率的なぐらいです。


しかし、dankogaiさんとか、チームですがGIGAZINEさんとかみたいに究めていけば、それ(ネットで食べていく)も不可能ではないかな、と思ったりもします。ま、好きじゃなけりゃ続けれないし、競合相手に勝てないと思いますが。


出だしから否定されたので、読み方が雑になったのですが、それでもスモールビジネスはヒットです。「ハッカーと画家」を読んだ後だったので、大企業で閉塞感漂うIT戦士を続ける以外にはベンチャーで融資を受けながら、死に物狂いで頑張るしかないのか?いや、そんなことはないはず。とか考えてたので、大きなヒントになりました。


これはもうid:umedamochioさんの提案されているやり方を鵜呑みにして取り組んでみるしかないです。



もう一度お金の話に戻り、ウェブで飯を食うことについての異論です。
(本書のテーマから外れるから、広告収入以外の可能性というか未来予測は外したのかな?と思ってます)


もし、不特定多数の人間を肯定して生きていくのであれば、誰かのためのサーバ設定やプログラムのTIPSを書き、それが有益なものだったのであれば、興味がなくてもそこに貼ってある広告を押してあげる、あるいは、はてなブックマークしてページの価値を上げてあげる。といった、利益の還元の仕方があるんじゃないか?と思ってます。(ぼくは時々そうしてます)

また、あちら側とこちら側で動くお金の量が違うとありますが、仮想通貨やはてなポイントみたなものであちら側へお金がどんどん移っていく。もしくは、時代が流れ消費者があちら側でお金を使うことに慣れれば、広告収入主体のネットのお金の規模や動きも変わっていくんじゃないか?と考えたりします。

そういった流れを仮定して妄想を繰り広げると、googleが検索で世界中の人からx円ずつ集めれるのであれば、ぼくが夜なべしてWebアプリを作り、そのうちの1つが300個に1個ぐらいの確率でヒットして終身100円の課金で600万アカウントとかできちゃうと、1発で満塁逆転ホームランなわけです。PCはちょっと微妙ですが、ケータイのように決済機能を内蔵し、よりお金を払いやすいと思われるデバイスもあります。

そして現状、Rubyが爆発的に普及することになった原因のRuby on Railsを作ってる37signalsはネットで有償のサービスを展開しスモールビジネスを営んでるわけですから、これから遠くない未来が、広告収入による無償サービスだけで回る世界じゃないことを夢みてます。

「ウェブ時代をゆく」欲しい!

id:umedamochioさんに読んでもらえるということなので、書きます。


ウェブ時代を見ないふりしていても今のところは、生きていけてます。

ウェブにより、世界が縮んでいる感がありますが、

大学時代に石屋でバイトしてた1995〜1998年ぐらいにはグローバル化というものを感じてました。

(国産だった主だった墓石が、中国産にシェアが奪われていってました)

で、氷河期の就職活動を迎えた訳ですが、石屋での経験から簡単なものづくりだとまずい。という予感と、

地元で働きたい。という願望があったのです。

そんな1998年ごろ、大学の図書館にあるパソコンの電源をビビリながら入れて、初めてネットに触れたんです。

その時には、コンピュータ(ネットワーク)なら距離を越えられる!!とか思ってました。


そういった理由で、地元のSI会社に就職してみました。

しかし、そこにはパンチカードの時代から受け継がれた伝統産業的な世界があったんです。

就職してみてようやく分かったのは、何もコンピュータなんて新しいものではなく、

この業界は1960年代ぐらいからあり、ゼネコン体質であること。でした。


このサーバの製造から客先SEや社内システムSEまでひっくるめてのSI産業というものは、

サバイバルしなくても、御上に言われるがまま、ピラミッドを作ってりゃ法律だのなんだのの障壁があるから、お金にはなるし、

EDSとかも、そう簡単には参入してこれません。

(携帯の持込禁止の職場もあるし、ネットから遮断されてて困った時にグーグル先生に質問できない職場だってあります)

日本のコンピュータサービスの市場規模は、5兆円。

SI開発、ソフトウェア、アウトソーシング各市場規模合計は5兆円

ウェブ屋さんの商売をネットの広告で稼ぐだけとすると、4000億円ぐらい。

ネット広告費、雑誌に迫る

伸びてるとはいえ、ドコモとKDDIの契約者数どころじゃない開きがあります。

危機感を持って、未来を考え抜いて生きていくことは重要ですが、

ウェブ時代をいかなくても、とりあえず食べてはいける現実があります。ゆで蛙ですけど。


しかし、


他の国がこぞって英語という共通語でしゃべり、神様に近づくため、空を目指してバベルの塔を作ってる間に、

1国だけ、ファラオのためのピラミッドを作ってる。

例えて言うならそんな感じでしょうか?

とにかく、内々だけでカネを循環してイノベーションを起こさない。そんな浪費をどこまで許容していけるのか?

(私が無知なだけで、他の分野で頑張ってるんならいいんですが…)


ウェブ時代をゆく」が、僕の目を完全に覚ましてくれることに期待してます。


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

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

フレークワーク MVCのV(ビュー)に関して

フルスタックに限らず、フレームワークの乗り換えって面倒ですよね。


そして乗り換えの際、一番面倒なのがビューじゃないか?と最近は感じてます。

Webアプリに限っていえば、データはデータベースが持ってるのが一般的だと思います。

最近の流行はORマッピング部分を自動生成して、ロジック部分からフレームワークの提供するapiを呼び、

永続化されてるデータを取得しましょう。です。

ORマッピングは難しい所だし、自動生成してくれるから許容できるんですが、ビューはいかんともしがたいです。


ビューみたいにコロコロ変わりやすいものの、専用の記法とかを覚える気力がもう湧かないわけです。

strutsとかJSFとか、超クールと盲信してた頃と違い、もうすぐ31のオジンですから。


今はrailsからrubyの世界に迷いこんで、rubyという言語を使えるようになりたい。と思ってますが、

数年後、railsを淘汰するようなグレートなフレームワークが、例えばhaskellで出たとしたら宗旨変えせずにいられるかは分からないです。


だから、永続化はデータベースで決まっているように、

テンプレート言語を使ってサーバサイドでビューを生成するんじゃなくて、

非同期じゃなくてもいい処理も全部、 .to_jsonみたいにjsonxmljavascriptにデータを渡して

素のhtmlのdiv要素を更新していく。なんてのはどうかなぁ?と考えたりする訳です。


共通のview

<html>
<head>
<title>Ajax (prototype.js used)</title>
<script type="text/javascript" src="./javascript/prototype.js"></script>
<script language="JavaScript">
function request(data, method, uri, async) {
  var parm1 = $F('txt1');
  var uri = uri + '?txt1=' + parm1;

  var myAjax = new Ajax.Request(uri, {
      method: method,
      parameters: '',
      onComplete: on_loaded
  });
}

function on_loaded(obj) {
  $('test').innerHTML = obj.responseText;
}
</script>
</head>
<body>
<form>
  <input type="text" id="txt1">
  <input type="button" value="SUBMIT" onclick="request('', 'GET', '呼び出すuri', true)" />
</form>
<div id="test"></div>
</body>
</html>
package ajax;

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class AjaxServlet extends HttpServlet {
	public void doGet(HttpServletRequest req, HttpServletResponse res)
	throws ServletException, IOException {
		String result = req.getParameter("txt1");
		PrintWriter pw = res.getWriter();
		pw.write("<p>hello " + result + " </p>");
	}
}

なぜだか例はしょぼいperl

use CGI;

$q = new CGI;
$txt1 = $q->param('txt1');

print "Content-type: text/html; charset=iso-8859-1\n\n";
print "<p>hello";
print $txt1;
print "</p>";

javaからrubyへ

JavaからRubyへ ―マネージャのための実践移行ガイド

JavaからRubyへ ―マネージャのための実践移行ガイド

会社にあったので、読んでみました。


会社として、あるいは職場としてjavaからrubyへ移行するには。というこの本の肝心要なとこは飛ばして読んだので、正しい読み方じゃないかもしれません。


rubyってどうなの?railsってどうなの?という所に絞って読んだのですが、以前書いた型変換でrubyだとintがBignumになるってところとか書いてました。javaの大きすぎる桁の変換エラーはバグだとされてました。。。


railsについては、フルスタックだからStruts,Spring,Hibernateみたいにあまたあるフレームワークから最適な解を選ぶ必要ないよ。というトーンでしたが、それって本当なんでしょうか?


いろんなところで言われてるRailsは万能じゃない説は当然として、フルスタックなフレームワークこそがリアルフレームワークなんでしょうか?


フルスタックだと、確かに選定する際は楽だし、統一されたapiとかメリットも多いとは思いますが、例えば他の、railsを凌駕するフレームワークが出たとします。

それがMVCのVにはerbじゃなくて、amirtaだとか、もしくは全然別の新しいテンプレート言語だったとすると、ビューのために、新しい事を覚えるのも面倒かと。。。


フルスタックだからこそ、別の新しいフルスタックなフレームワークが出た時に一からの出直しになるリスクがあるんじゃないかなぁ。と思ったりするわけです。

ファイルアクセス

rubyの場合、ファイルアクセスというと、よく目にするのはこんなコードだと思います。

File.open(ARGV.to_s).each {|line| puts line}


1行で書けるなんて、javaでプログラムを学んだぼくにとっては驚きでした。


読みは簡単だとして、ファイルに書くというのはどんなでしょう?
ログの処理とかでよくありそうな、最終行に追加書きというケースを試してみたいと思います。

foo = File.open("foo.txt",'a')
foo <<  "bar\n"
foo.close


参考にしたのは以下のサイトです。
逆引きRuby
しがない「げのまー」の・・・。 2000-01-04 python を使ってみた。その三。


最後にjavaでの追加書きです。
余分な処理は多いですが、核となる、追加書きでファイルを開く、そこに文字列をwriteする。
という処理はあまり変わらないような気がします。
と言いつつも、rubyの追加 << って記法が好きです(^^)

import java.io.*;

public class LastAdd {

	public static void main(String[] args) {
		LastAdd add = new LastAdd();
		add.start();
	}
	
	public void start() {
		try {
			File file = new File("/home/user/foo.txt");
			FileWriter fw = new FileWriter(file,true);
			fw.write("baz");
			fw.close();
		} catch (FileNotFoundException e) {
			e.printStackTrace();
		} catch (IOException e) {
			e.printStackTrace();
		}
	}
}

bean

java beanはrubyになるとどうなるか。ですが
よくよく調べてみるとjavaからrubyへ移行してく人向けに日経ソフトウェア2006年10月号に詳しくのってました。
あと、ネットならkbmjとかにもありました。
下調べが足りてないわけですが、自分の勉強も兼ねてるので
なるべくネタが被らないようにマッタリとやってきます。


で、beanはrubyだとどうなるかですが、
今回はどらえもんの4次元ポケットを題材にしてみることにしました。


Pocket.java

public class Pocket {
	private String item;

	public String getItem() {
		return item;
	}

	public void setItem(String item) {
		this.item = item;
	}
}

implements Serializableがないとか、細かいことは言いっこなしで...
このポケットを使って未来の道具をやりとりするコードは、


Dora.java

public class Dora {

	public static void main(String[] args) {
		Dora dora = new Dora();
		dora.exec();
	}

	private void exec() {
		String smallright = "スモールライト";
		Pocket pocket = new Pocket();
		pocket.setItem(smallright);
		System.out.println(pocket.getItem() + "〜!");
	}
}


テレ朝からクレームが来ないか、ちょっと心配になってきました...
とりあえず、これでbeanを使うコードのできあがりです。


ruby版だと、いろんな所でかかれているように
ゲッター/セッターがなくなり、attr_accessorという定義を書きます。
これはどうやらメソッドのようです。


このattr_accessorを使って四次元ポケットを書くと


pocket.rb

class Pocket
  attr_accessor :item
end

このポケットを使うどらえもん側のコード、dora.rbです。

require "pocket"

class Dora
  def exec
    smallright = "スモールライト"
    pocket = Pocket.new
    pocket.item = smallright
    puts smallright + "〜!"
  end
end

dora = Dora.new
dora.exec


attr_accessorを使うとゲッター/セッターを使うよりコード量は減りますね。
eclipseとか使えば、自動生成ではあるんですが。


ただし、bean相当を操作する時にsetナニガシ("もごもご")と書かずに
プロパティを設定するような書き方ができるのが分かりやすいと思います。

2. 型、型変換

JavaからRubyへ ―マネージャのための実践移行ガイド

JavaからRubyへ ―マネージャのための実践移行ガイド

JavaからRubyへ。という本がありますが、中をチラ見したら
コードを書くという所にはあまり触れてなかったので、コードの違いについて書いてみようかと思いました。
自分の勉強になるし。


ということで型変換です。
プログラムをしてない人には"1"と1って違うということが「は〜?」って感じだと思います。
例えていうなら、百十四足す50の答えは?
と言われると難しいのと同じで、コンピュータに計算させるときには、扱える単位を揃えてあげる必要があります。


で、javaの場合、この型を変換して揃えてあげるのがとても難解なのです。
以下は文字列型のa,bを足し算して、答えを求めるプログラムです。

Main.java

public class Main {
    public static void main(String args[]) {
        String a="1";
        String b="2";
        /* System.out.println("answer:" + (a + b)); */
        Main main = new Main();
        int answer = main.add(a,b);
        System.out.println("answer: " + answer);
    }

    private int add(String a, String b) {
        int i;
        int j;

        i = Integer.parseInt(a);
        j = Integer.parseInt(b);

        return i + j;
    }
}

この中で型変換にあたるのが、Integer.parseInt(文字列型の変数)です。
なんで、こんなややこしい処理をするのかは、ちと古いですがこの本が詳しいです。

Java 謎+落とし穴 徹底解明 (標準プログラマーズライブラリ)

Java 謎+落とし穴 徹底解明 (標準プログラマーズライブラリ)


前置きが長くなってしまいましたが、rubyではこんな風にかけます。
main.rb

class Main
  def add(a,b)
    i = a.to_i
    j = b.to_i
    return i + j
  end
end

main = Main.new
ans = main.add("1","2")
p ans


型変換の処理は.to_iです。
如何にスクリプト言語といえど、.to_iをしない場合には、"1"+"2"は"12"となってしまいます。


javaだとint型への変換に失敗すると例外が発生するのであまり良い例とは言えないのですが、
rubyだと"1"を"9999999999999999999999999999999999999999999"としても処理してくれます。
どうやら、Integerは抽象クラスで、桁が大きいものはBignumクラスとして処理されるみたいです。