最近twitterでXSSによる攻撃があって大騒ぎだったというのがよく話題になっているようです。

自分も実は某社でwikiのような記法を使って記事が書けるwebサイトを作っているのですが、よく考えないで正規表現でごりごり実装したのでXSSを連発して苦い経験をしました。

そこで今日は、文法とか言語についてだらだらと書きます。
（ちなみに計算機系の学部では、授業で形式言語とか正規文法とかならうと思いますが、それです。）

wiki記法は文脈自由文法だと思ってパースした方がわかりやすいかも？

結局記法パーサをど根性で正規表現を駆使して書いたんですが、よく文法構造を考えてみればもっと簡単にパースが出来ただろうことに最近ふと気づきました。

細かい話は端折りますが、大抵のwiki記法というのは文脈自由文法というもので表現できそうです。
文脈自由文法で生成される言語というのは、正規表現では記述できない文があるので、どうしても無理矢理な実装になってしまうようです。（チョムスキー階層）

文脈自由文法と正規表現をメールアドレスを例にわかりやすく書いてる記事があったのでとりあえずそれをご紹介。

• 正規表現よりも文脈自由文法を

なるほど。確かに入れ子構造とかがあると正規文法よりは文脈自由文法であると考えた方がみやすそうです。（ただしメールアドレスは正規表現だけでかけるようです。）

wiki記法には、例えばテーブル要素などの、入れ子構造を持ったものがあるので正規表現だけでごりごりやっていくのはなかなかに難しそうです。

twitterの文法は何だろな

で、twitterなんですが、基本的に入れ子構造がない文法なのであれはどうやら正規文法である気がします。
なので基本的には正規表現ですっきり記述可能なはずです。（※一行の正規表現でかけるという意味ではありません）

一般的な構造テキストの解析の仕方

構造化テキストの間違ったエスケープ手法についてや(Twitter の XSS 脆弱性に関連して) 構造化テキストの正しいエスケープ手法についてでも軽く触れられてますが、もうちょっとはっきりまとめるとこういう風につくるのが一般的である様に思います。コンパイラのつくりに似てる気がする。（ある意味これもコンパイルなわけですが）

1. 字句解析（トークナイズ） : 文字列をトークンに分割
2. 構文解析（パーサ） : トークンに文法を元に構造を持たせる
3. 出力生成

ちょっとコードを書くのが面倒なので(Twitter の XSS 脆弱性に関連して) 構造化テキストの正しいエスケープ手法についてから拝借します。

PLAIN TEXT
CODE:




my $html = '';


for my $token (split m{(http://[0-9A-Za-z_\.\%\?\#\@/]+|\@[0-9A-Za-z]+)}, $tweet) {


    if ($token =~ m{^http://}) {


        $html .= '<a href="' . encode_entities($token) . '">'


            . encode_entities($token) . '</a>';


    } elsif ($token =~ m{^\@(.*)$}) {


        my $user = $1;


        $html .= '<a href="http://twitter.com/' . encode_entities($user) . '">'


            . encode_entities($token) . '</a>';


    } else {


        $html .= encode_entities($token);


    }


} 

このコードで説明をすると、for my $tokenの行が字句解析にあたり、そのあとのif, elsif,  elseの部分が構造解析と出力生成になっています。

ところで、さっきtwitterの記法は正規文法らしいとかきました。
その意味するところは、凄くおおざっぱに言えば、左から順番に解析していけば いいということです。
つまり、処理したトークンをあとで後方参照する必要がありません。

実際先ほどのコードを見てみると、分割したトークンを順番に処理していけばいい形になっているのがわかるかと思います。

結論

最近自分で実装したwikiパーサで結構後悔してたのもあるんですが、余程ややこしい記法でも、大概の場合、文法を意識して字句解析・構文解析をすればすっきり解析できる様に思います。

もし独自の記法をつくりパーサなどを実装することなどがありましたら、ぜひこういったことを思い出してつくってみてください。

※追記：
なんか「エスケープが間違ってた」的な話が多い気がするのだけど、個人的には字句解析とか構文解析の失敗であって、別にエスケープは失敗していない様に思う。
わかりやすく言えば、エスケープ関数にエラーはないわけで（多分

screenには大変なじみがあるのではないかと思いますが、最近windowの縦分割（左右に分ける）をしたくなり、tscreenやscreenのパッチなど色々と考えた末に、tmuxにしてみました。

理由は特にない(^^;;んですが、使ってみた結果tmuxの方が若干見た目に奇麗であるように感じました。

現在最新版はバージョン0.9なのですが、ドキュメントがなくソースを読むしかない（？）ので、軽く使えるコマンドについて言及したいと思います。

とりあえずmacの人はmacportsにあるのでコマンド一発ではいります。

そして、次は設定ファイルをおきましょう。screenでいうところの.screenrcは、.tmux.confというファイルになります。
私の設定ファイルはこちらをごらんください。
基本的にソースに付属しているscreen-keys.confをもとにしています。
このファイルを.tmux.confにリネームしてホームフォルダに置くだけで、screen風なキーバインドになります。

さて、screen-keys.confだけだとwindowを左右に分割することができないので、以下の設定を書き足してあります。
(他にも書いたんですが、ど忘れ・・・・)

こうして、tmuxを立ち上げたあとC-a C-Sで画面を分割し、C-a C-hで分割を左右にすることができます。

さて問題はこの「select-layout even-horizontal」というコマンドをどこから見つけてくるかです。ドキュメントがないっぽいので、ソースを見ます。
ビビらなくても大丈夫。大変奇麗に作られてるのですぐに読めると思います。

ソースをここからダウンロードして展開してみてください。
そして、cmd-から始まるファイル名のファイルを探します。これが全部コマンドになっています。バージョン0.9だとこんな感じになっています。

ここから「cmd-」を除いた部分がコマンド名です。機能はだいたいコマンド名見ればわかりますね。
各々のコマンドは引数を取ったりします。それを調べる時はソースを見ます。
たとえばさっきの「select-layout」であれば「cmd-select-layout.c」を見ます。すると、こんな感じのコードが見えるはずです。（一部抜粋）

細かい説明ははしょりますが、というか理解してないのですが、ここからコマンド名が「select-layout」であり、エイリアスが「selectl」であることが読み取れます。
ちなみにこの書き方はxwindowの拡張であるglxの実装の一つであるcompizのプラグインもこういった書き方になっているので、見慣れておくといいような気もします。

次に、引数ですが次の部分に注目します。

はい。ここで「even-vertical」とか出てきましたね。細かい説明はまたしてもはしょりますが、ここが引数でありそうな事はぱっと見でわかると思います。わかってください。
これをもとにさっきの設定を見てみましょう。

今まで見てきた通りですね！

じつは、他のコマンドもだいたい似たような感じになっています。それぞれのコマンドは非常にコンパクトにわかりやすく書いてあるので山勘で何とかなるかと思います。

しかし、0.8系と0.9系でコマンドが変わったりしてるようなので、まだちょっと注意がいるかもしれません・・・・

というかんじで、みなさん楽しいtmuxライフをおくりましょう！

はてなのようなキーワードリンクをRubyで付与する実例
と、いうのをつくってもらったので、これをもとにCでsennaのpatricia treeを試すプログラムを書いたよ。

機能的にはとりあえずキーワードの検出だけ。

activerecordの様なDBラッパーを作ろうと思って、 @ujm の協力の下module_evalを使って実装してみた。
必要最小限のことしか書いてないのでDBラッパーとしては貧弱だけど、module_evalの動きに注目してみてほしい。
本物のactiverecordも似たような実装をしていたと思う。（うろ覚え）

これを次のように使う。たとえばuserテーブルを扱うクラスはこんな感じ。

ModelBaseクラスを継承し、table_nameメソッドでテーブル名を指示しているわけです。

で、ポイントはModelBaseクラスの次の部分。

UserModelの冒頭でtable_nameとこのメソッドを呼んでいます。

module_evalは、そのメソッドが呼ばれたところをselfにして実行されるメソッドであるため、このtable_nameメソッドの中で定義されているget_table_nameは、UserModelのクラスメソッドとして定義されます。

つまり、UserModel内でtable_nameが呼ばれた時点では、次のコードと同じことをします。

こうすることによって、プログラム中でテーブル名をハードコードしなくてもすむようになるとともに、countなどの関数を親クラスで定義できるようになるわけです。

例えば、この方法で作ったクラスで全レコード数を数えるコードはこうなります。

大変すっきりしていますね。

蛇足：

これはtwitterのポストを扱うために書いているプログラムの一部です。
rails使おうかとも思ったのだけど、railsはまだ多機能すぎるためこの程度なら書いてしまった方が悩みが少ない（重いとかファイルの配置とか拡張性とか）かと思って自分で書いています。

しかし、自分でフレームワーク作るかというと・・・・たぶんないですね。
フレームワークは必要じゃない機能もたくさん足すことになります。
なんの目的もなしに機能追加を繰り返していくと、フレームワーク自身のメンテナンスに負荷がかかるようになってしまうし、コードの自由度がどんどん下がっていきます。

それよりは、構造化を心がけながらプログラミングをし、拡張性を担保しながら、必要十分なものを作っていく・・・と、いうのが賢いプログラミングである気がしました。

実際軽くなるかどうかは不明だけど。

config/dependencies.rbに作ったmerbアプリケーションの依存しているライブラリが乗っています。

素朴にmerb-gen app hogeでやった場合こんな感じ。

# dependencies are generated using a strict version, don't forget to edit the dependency versions when upgrading.
merb_gems_version = "1.0.1"
dm_gems_version   = "0.9.7"

# For more information about each component, please read http://wiki.merbivore.com/faqs/merb_components
dependency "merb-action-args", merb_gems_version
dependency "merb-assets", merb_gems_version
dependency "merb-cache", merb_gems_version
dependency "merb-helpers", merb_gems_version
dependency "merb-mailer", merb_gems_version
dependency "merb-slices", merb_gems_version
dependency "merb-auth-core", merb_gems_version
dependency "merb-auth-more", merb_gems_version
dependency "merb-auth-slice-password", merb_gems_version
dependency "merb-param-protection", merb_gems_version
dependency "merb-exceptions", merb_gems_version

dependency "dm-core", dm_gems_version
dependency "dm-aggregates", dm_gems_version
dependency "dm-migrations", dm_gems_version
dependency "dm-timestamps", dm_gems_version
dependency "dm-types", dm_gems_version
dependency "dm-validations", dm_gems_version

非常にたくさんのモジュールが呼ばれています。明らかにcacheとか今使ってないのでそういうのをコメントアウトするとより軽くなるのかなぁと妄想しているところです。

以前は次のようにやっていたようですが、いつの間にかかわったようです。

Mac OS X で DNS のキャッシュをクリアする。

lookupdはすでに存在しません。そのかわりdscacheutilが使われるようになっています。
これはmac上の様々なキャッシュを統一的に扱うようにしているようです。

次のようにするとdnsキャッシュの中身が見れます。

dscacheutil -cachedump -entries host

で、クリアするときはこんな感じ

dscacheutil -flushcache

なるほどなるほど。

大企業向けの情報管理ソリューションについてたまたま考える機会があったのでちょっと思ったことをば。
じつはクローズアップ現代自体は見るの忘れてた。誰か録画あったら頂戴。 

NHKクローズアップ現代「新情報革命“クラウド”の衝撃」を見て

番組中でもあったかもしれないですが、個人的に思うポイントは

• 巨大なコンピュータリソースが比較的安価に手に入る（インフラ）
• クラウドコンピューティングなどによるSaaSやPaaSは囲い込み力が強い（サービス）

の2点でしょうか。ほかにも瑣末なことがたくさんあったんですがあんまし肝心ではなかったので忘れました。しかし、主にはインフラ面とサービス面の２つから切ることができるでしょう。

巨大なコンピュータリソースが比較的安価に手に入る（インフラ）

本当に安いのかというと実はそうでもないです。たぶんフル稼働したとしたら専用サーバのほうが安いんでないかな。
どちらかというと、「使った分払う」形になったと表現するほうがいいかもしれません。Amazon EC2などは使った時間とスペックで課金されるのでわかりやすいですね。 
あれもひとつの金額設定のきり方であって、ほかにもいろんな切り口が考えられそうです。

ほとんどの人にはコンピュータリソースを恒常的に確保するニーズはないわけです。一日数時間集中的に計算できればいいとかそういう人ばかりでしょう。
一般的なユーザから見るとアイドル時間の無駄なコストを持たなくてよくなった分安くなったと感じられるということです。

これによる効用ですが、グーグルが何年も前から言っているこの問いに収束する気がします。

「さてここにＰＣ2000台分の計算資源があります。この資源を生かした何かをしてください」

実はこの問いに答えられる人は、それほど多くはないようです。しかし、これだけのリソースをわれわれ一般人が使えるようになった今、必要な発想はまさにここです。
例えば毎日ブログの記事を解析するサービスを考えて見ましょう。解析には残念ながら3日かかります。これだと毎日リリースすることができないためサービスが成り立ちません。
しかしクラウドからコンピューティングリソースを借りることで72時間かかっていた解析が24時間で終わる・・！
こうすると従来不可能だった分析・解析を提供するサービスができるようになるわけです。

他にもたくさんのケースが考えられます。従来経済の分析をすることは計算資源の面を見てもなかなか難しかったように思います。 
少なくともいろいろ数値を入れて、「分析！」ってはじめた瞬間から結果が出てくるのが一時間後だったとしましょう。
これが例えば2秒まで縮まったらどうでしょうか？ 
従来計算資源の問題でぜんぜん直感的でなかった分析が、直感的にできるようになるとは考えられないでしょうか？

むかしアシスタントを何人も並べて数値の計算をしていたという話を、この間野村や大和総研の方からうかがう機会があったのですが、それがいまやＰＣのエクセル上でできるようになっているわけです。
その時間の短縮具合といったら・・・・・それと同じことが今もう一度おきるかもしれないわけです。

クラウドコンピューティングなどによるSaaSやPaaSは囲い込み力が強い（サービス） 

どうやら、salesforceなどの話が出ていたようですが、これはインフラのクラウドとは分けて考えるべきでしょう。最近のsalesforceはよく知らないのですが、すくなくとも一年半くらい前に見た限りではそれほど強固なインフラが必要な感じはしませんでした。（もちろんインフラとしてクラウドかするメリットはあるんでしょうが、直接salesforceのサービスには影響しないでしょう）

サービス面でのクラウドを考えるときに欠かせないのは、その「囲い込み力」です。

たとえばMS Officeのことを考えてみてください。どうしてMS Officeを使っているんですか？情報システム化の概念から考えると大体こんな理由かと思います。

• ファイル形式や機能で同一のものが使えないと仕事がしにくい
• 操作方法などソフトウェアに関するノウハウやコツの共有のため（システム更新すると教育コストがかかる
• 過去の資産があるため

他にもたくさんありそうですが。これがクラウドになるとどうなるかについて考えてみましょう。

まずクラウドになるとファイルという概念がなくなります。もちろん帳票処理などのためにＣＳＶやエクセルという形でダウンロード可能でしょうが、一括でのバックアップ機能として使いやすいかというとそれはまた別問題です。

またデータとしての実態が希薄になっていくことが考えられます。 
どれが入力したデータで、どれが加工したデータなのかは使えば使うほどわからなくなってきます。すると、どれをバックアップするべきなのかがわからなくなってきます。
最終的には、将来的にシステムを移行しようとしたときに、こうしたデータの互換性が障害になる可能性も考えられます。ここが囲い込み力。

つぎに操作方法に関するやノウハウ・コツによるもの。どこぞの金融系会社は新人に死ぬほどエクセルのショートカットキーを教えるようですが、システムが変わるとこれが無駄になります。
これはクラウド化とか関係ないのですが、いま世の中の風潮として情報システムをクラウドに入れ替えようという風潮があるのは事実なので、この点は乗り越えそうです。
しかし、将来再び情報システムを乗り換えることを考えたときにこれが、再びネックになります。
そのときに情報システムを入れ替えようとするなら、クラウド以上に便利な機能を提供しなくてはなりません。
また先ほど話題にした、互換性の問題も手伝って、より囲い込まれることが予想されます。

また、データが大量になってくると当然過去の資産の問題が出てきます。
今までであれば、ソフトが変わってもエクセルが読めればいい、例えば、オープンオフィス使ってもエクセルが読めればいいという感じだったわけですが、クラウド化した瞬間データそのものがプラットフォームに帰属するようになります。
例えばsalesforceで使っていたデータを他のサービス、例えばbeyond_salesforceに移行することを考えて見ましょう。
もちろんsalesforceはデータのダウンロード機能や移行方法を提供すると予想されますが、書き出したデータがそのままbeyond_salesforceに読み込めるかどうかは疑問です。

サービスのクラウド化は、従来の方法論（アプリケーション）だけ依存していた状態から、データそのものを依存するようになる可能性を秘めています。
こういったいみで、囲い込み力が従来の製品に比べて高くなる可能性を持っています。

サービスのクラウド化の鍵は標準化

そういった意味ではデータの標準化が鍵を持っているように思います。世の中はなんでも標準化する時代ではありますが、それでも独自拡張がなされ「われこそが標準」というのが常であり今までの歴史でもあります。

いまさら出はありますが、VHSにしてもBetaにしても、ＭＳOfficeにしても、データ形式としてなにが標準なのかという点は常に重要です。
それが、クラウド化してファイルというデータのエンティティが希薄になったときどういう表現が標準になるかというのは重要であるように感じます。

まとめ

まとめるとクラウドはビジネスチャンスです。羊が退去して移動していて、その移動先にどれだけ大きな囲いを先に立てられるかという戦いといっていい気がします。

ビジネス的には結局よく考えてみると従来からよくある話なので面白みはないですが、インフラ面だけ考えればあたらしいサービスを提供する可能性があるので作る人にとっては楽しい話だと思います。

初心者がどうやってプログラミング言語を学ぶべきか。というのが、話題になっている。一方で最近はＡＰＩなどを駆使した軽量のwebを個人で作ることがブームになりつつある。
これを見て思ったのは、「じつは初心者がプログラミングを学ぶのは、こういうものをつくったりまねたりすればいいんじゃないかな？」ということである。 

ここ数年ＬＬ（Lightwieght Language）というものがはやっている。たとえばperlやruby, phpなどのスクリプト言語を指して用いられることが多く、修正などが容易な言語を指して用いられる言語である。 ここから文字って、Lightweight Software/Serviceという考え方を持ってみるのはどうだろうと考えた。

考え方としてはこうだ。

エンタープライズ向けに提供することは無理。ユーザからお金をもらうことも・・・・ちょっと難しいかも。けど、プログラミングを勉強する一環として、めんどくさい部分は全部ＡＰＩまかせにし、自分の考えを実現する。

よくよく考えてみると、自分がプログラミングを学んだひとつの方法として、他人のプログラムを見てコピペしたりまねをするというのがあった。
「これが作りたい！」と思うと、オープンソースのソフトを持ってきたりしてまねをするわけである。車輪の再発明がかっこ悪いという批判はあるものの、現代はソフトウェアの歴史なんてしらないし、世の中にあるソフトウェアを網羅的に把握してたりする人のほうが少ない時代である。

批判する人も出てくるだろうが、今回のえがちゃん騒動を見てて思ったのは、批判しない人のほうが多いしそっちのほうが一般的であるという事実である。
あれがすごいことなのかといわれると、ソフトウェア的な価値はほとんど０である。ただそれは、売り物にはならないとかいうレベルの話であって、いちいち趣味に対してセキュリティホールがどうのこうの言うのは、親切心でないとしたら、余計なお世話だろう。（俺は個人的にあの人は嫌いだが）

実はこのLightweight Software/Serveceと呼べるようなものは割と簡単にまねすることができる。ほとんどのものはＡＰＩたたいて、単純な四則演算してるだけだからである。
また、たいていの場合は、いろんなところを右クリックしてＵＲＬを調べたり、htmlのソースを見てみたりするとプログラムそのものが見れてしまう。
先にあげたamachangのものであれば、親切に画面の一番下に利用しているＡＰＩが書いてある。もうこれで材料はそろった。あとは、試行錯誤して何とか真似をすればいい。（と、言ってるほど楽でもないんだろうが）

ひとつ思うのは、プログラミング初学者のためにLightweight Software/Serviceのソースを公開してみてはどうだろうかということ。 
おそらくソースコード自体も高々数百行程度だろう。読むのもそれほど苦ではない。
最近ではgit hubやcodereposというような、自分のソースコードを公開するための仕組みも提供されている。
利用にはgitなどの利用方法がわかっていないといけないが、自分でwebで公開する手間に比べたら幾分らくだと思う。 

こういったものをプログラミング初学者のために、また自分が学ぶためにやってみるというのはどうだろうか？

なんか意地でもITを泥化したい人たちがいるらしい。これは悪意すら感じるようになってきた今日この頃です。

まず書く前に自分の立ち居地について書いておく必要があるかな。

• エンジニアの未来サミットには参加してません
• 実際にシステムの受託開発的なことを一時期していて、ほとんど中小企業だけど中には上場企業のシステムやサイトなどをコンサルティング、製作したりしてました
• ほとんど社会人とだけつるんでやってたので、学生周りの事情を知ったのは最近
• ちなみにまだ大学生（卒業できんかったのですよ）。受託向いてないと思って辞めたところで来年から大学院生

ちょっと書きたいことをバラバラ書くので読みにくかったり、語弊があったりしたらすみません。あまりエンジニアの未来サミット関係ないかもしれません。
また、多分に個人的主観が強いであろうことも付け加えておきます。突っ込みは歓迎。むしろ中々実情について調べられないでいる（と、いうかあまり自分には関係ないので調べるつもりもないんですが）ので、事実を教えてもらえるのはうれしいです。

自ら泥化する学生たち

あまり一般性はないかもしれないですが、これを最近思いました。これを思ったのはちょっと前に知り合いがwebのデザインを始めたといったときのせりふ

すごい高額な料金を取ってデザインしているのに、それにお客さんが満足していない。同じものならもっと安くできる

価格競争を自ら誘発しているわけです。で、開発やデザインの差はあれども、実際安くやることによって仕事を得てる人たちがいます。
しかし、それは本当に安くやるべき仕事だったのかどうかについてはよく考えたほうがいいんではないでしょうか？

たとえば、私も結局安い値段でやってはいたわけですが、railsやCMSなどを組み合わせ、さらに仕事を絞ることで基本的なコストを削減することを第一に考えてやっていました。
少なくともそういった工夫は必要です。

第二に一般論ではありますが、コストベースで仕事をするのは価格競争に陥りやすく、あまりお勧めではありません。
ほとんどの商売上手な人は相手によって少しずつ提案する内容を変え、利益に対する値段を考えたりしています。
請求書上項目がどうなってるのかは人によると思いますが。
特に、結果としてアウトプットに差がでにくいwebの開発やデザインなどにおいては、そうなりがちであることは想像に堅くありません。
多くの人は「信用を得るために仕事をこなすことが重要」というのを言います。これはある程度認めましょう。しかし、最終的にはサービス面での差別化をはからなければ、その会社は泥化を促進するだけのものでしかないんではないでしょうか？
安くやるというのにはそれなりの戦略性が要るのかと思います。

泥な人たちはどのくらいいるというのでしょうか？

これが私にはよくわかりません。
なんどとなく書いていますが、定時にかえってるSI屋さんというのもいます。なぞですね。

あと、なにをもって泥といっているのでしょうか？これもよくわかりません。

就業時間でしょうか？外資コンサルの人たちの初任給と労働時間について考えたことはありますか？
私も労働市場全体のことはよく知りませんが、ITに限らず残業が問題になっているのはご存知のとおりかと思います。

給与面でしょうか？
これは単純に数字をよく知りません。
しかし、IT「業界」が泥だといいたいなら、個別の事例を取り上げてうだうだ言ってもしょうがないはずです。
これに関する定量的な話をついぞ聞いたことがありません。

さらにIT業界って何でしょうか？
大手電機メーカーの研究所でエンジニアをしていると大体年収平均700万くらいで安定するそうです。
大金持ちってわけでもなさそうですが、安定度には定評があります。
これも部分的なはなしなので、一般に当てはめるには困難がありますが・・・

なんでもいいんですが、泥じゃないサンプルをいくらでも知っています。だれか定量的な説明をしてないんでしょうか？定量的じゃなくてもいいですが、事実について正確に把握してる人がどの程度いるのかが疑問です。

人月商売・多重下請構造は破綻するのか？

破綻ってなんだろう？という気がしますが、0になるという意味なら、それはありえないでしょう。なんにしても最終的に手を動かす人が必要です。
価格競争に耐えられなかった自律泥化企業は消えていくだろうなというのはありそうなシナリオな気はします。

自分の人生は自分で決めろという論理は正しい

PDSCサイクルではないですが、自分で計画して、実行して、失敗して、修正するしかないことはたくさんあります。
特に有象無象な業界ほどそれは当てはまる気がします。
教育制度のしっかりしている大手企業以外で教えてもらうことを期待することは非常に難しいです。

ほとんどの学生にとっては就職が人生を考え始める第一歩であるような気がします。
私事で恐縮ですが、実際いろいろやってみて「明日くう金がないかもしれない」というリアルな状況におかれるまで、なんか昼夜を問わず電話をかけてくる理不尽な人と出会うまで、いろんな心温かい大人たちに色々と指摘されるまで、自分の人生についてなんか考えたことはありませんでした。
もちろん将来○○系でやっていきたいという漠然な考えはあるでしょうけれども。

たたかれるにしてももちあげられるにしても、基本的には私の行動に対して世間はリアクションを取るわけで、悩んでいるだけではまさに自分の存在は世間から見たとき「空気」です。

泥の話にひっかけるなら、主体的にビジネスをできないほど泥に足を突っ込むことになるでしょう。
泥の論理自体は至極単純です。リソースに見合わない作業を強いられているだけです。
積極的なリソースの確保と作業の調整がそこには必要なわけです。自分が社会の歯車にはまっていないのであれば、なおさら努力しないとそこにはまり込むことはできません。

ほとんどの人は、そういった意味で泥にはまり込まないように、できるだけ主体的に判断しなくてもいいように、学歴とかネームバリューにこだわるんだと思いますが、その権利を得られる人は社会全体から見れば小数です。
しかしそういった学歴とかがある人でも、大成功を目指すような野心家は、やはり最終的に主体的判断が必要になるでしょう。いずれにしても社会全体に存在しているリソースは有限であり、大量の成功者を抱えるには足りません。

技術とは何なのか？

実務として何をしてるのかはよく知りませんが、文系SEというのは結構いるものです。
しかし個人的な思いとしては、プログラムかけます程度を技術と呼びたくはない気はします。もちろんプログラミングはたくさんある技術のひとつではありますが、その「プログラミング」というひとつの技術を持つ人を指してエンジニアとは言いたくありません。
一言で言えば、それだけだとほとんどの世の中にある工学的・エンジニアリング的問題が解決できないからです。
はたしてプログラム書けるだけの人がサイトに集客をしたいというニーズを解決できるんでしょうか？その問題をテクニカルに解決するのがエンジニアの価値です。
最近めっきり公的にはなくなりましたが、プログラムでスパムサイトを量産するというのはひとつの立派なソリューションです。（勧めてるわけではありません）

経営者の価値が適切な組織運営の方法を提供することであるならば、エンジニアの価値は適切な技術の選択と適応ができることが価値です。
単一の技術をもつだけではほとんどエンジニアとしての価値はないといっていいでしょう。

今まで私は「文系」と「理系」という区別には意味がないという主張をしてきましたが、それは主にシステムの開発に関する教育を行う機会が平均的には存在しないため、差がないという意味で使ってきました。
しかし技術者・エンジニアという文脈で考えた場合、より多くの技術ポートフォリオ・技術的思考になれている人間のほうが相対的に有利であと思います。
ここに関して「文系」と「理系」を区別することには意味があると思います。（正確には受けてきた教育に関してわける合理的理由はあるかと思うという感じです。）

文系エンジニアが成立するのはかなり局所的な話であり、すでにweb開発がコモディティ化している現代においては、すでに文系エンジニア論理は終わりを告げつつあるように思います。それこそ泥なのは文系エンジニアの世界ではないですか？（これは提案。実際はよくわかんない）

重要なのは敬意

以前紹介した記事(twitterに書いただけだったかも・・？)にもありましたが。

4. Failure to Show Respect
When in Rome, do as the Romans do. If you’re a tourist overseas, you shouldn’t assume that everyone speaks English. That’s just plain rude. Natives of your host country will appreciate any attempt to speak their language, however feeble it might be; it’s a sign of respect and will go a long way to making sure the waiters don’t spit in your food. Likewise, even if business execs don’t understand the “language” of their technical counterparts, they need to do their homework and try to gain a basic awareness of the job at hand. It shows respect and breeds confidence. Business execs also often fail to appreciate what inspires and motivates technical and product folks, who sometimes are creative types more interested in building cool, innovative and useful stuff than making a busload of cash.

（要約）

郷に入れば郷に従え。エンジニアたちの言葉を理解することは、彼らに対する敬意をしめすことなのである。もし理解できないのであれば、自分で勉強してちょっとでも仕事についてわかるようにしておくべきである。
また何が製品担当や技術担当のモチベーションをあげるのかをうまく理解できないことがよくある。

経営者の話を聞いていると「ずいぶん勝手なことを言うな」と思うことがしばしばある。これは本当に簡単なことであるのに気づかない人が多い。

エンジニアだから、プログラマだからといってどんなものを作ってても楽しいということはないわけです。よく「プログラムかいてれば楽しいんでしょ？」という人がいますが、大きな勘違い。もちろんそういう人もいるにはいますが・・・・

ひるがえってこう聞けばいいかもしれません。「温暖化を解消する会社を経営してよ？経営してればなんでも楽しいんでしょ？」

どんな会社でも経営できれば楽しいという人は、プログラマと同様にいるんだとは思いますが、自分の興味のない会社を経営することを考えたら、ほとんどの人はモチベーションあがらないんじゃないでしょうか？
それが将来もよくわからないような会社だったらなおさらどうでしょう？なんで自分がそんなことをしないといけないとか思いませんか？
俺も仕事じゃなきゃこんなこと考えませんが（モチベーションはやはり品質に跳ね返る。身内ならなおさら。）、すごく当たり前のこととして考えてほしいと思うことが多いです。エンジニアを少しひとくくりにしすぎじゃないでしょうか？

経営者は自分の仕事に関してよく考えてほしい

かえって俺は経営者の仕事というのがよくわかりません。いや、大体わからなくもないのですが、コードを書けるべきとかそういうのとは本来的に別次元であると思うんですよね。
やっぱりインターネット。作る側の悲鳴ばかり聞こえてきて「私はそれにメスを入れる！」みたいな人たくさんいるわけですが、果たして経営者が本来的にするべきことについてネット上で語られてきているでしょうか？
ここには相当バイアスがかかっていることに注意しなくてはいけないと思います。

たいていの場合経営者は組織の制度上の明確な権力を持っています。形式上エンジニアを首にすることは簡単なわけであり、コストに見合わなければ首をすげかえることができるわけです。
それに対して技術者は実力で対抗しなくてはいけないわけです。「私の代わりはいませんよ？」

経営者は組織上明確な権力を持っている以上は、本当に見合った仕事をしているのかについては慎重に考える必要があります。
究極毎日ゴルフしてたって誰もあなたを首にはできません（人はついてこないでしょうが）
そういった立場であることを第一に考えるべきではないでしょうか？
果たして技術なんかにうつつを抜かしている場合なんでしょうか？もっと経営者がすべきことがあるんではないですか？

これは技術がわかるべきかどうかというのとは別次元の問題であり、かつ、本来的にもっと議論されるべきところなんだと思います。

思い出したのでついでに言うと「エンジニアにとってすごしやすい会社/企業」というのはなんかおかしいのです。前項にあげた「敬意/それぞれの趣味趣向」を認めるなら、それが物理的に実現不可能であり、たとえ実現したとしてもエンジニアリングとして優れた人は来ないであろうことが想像できます。
むしろ会社として「求める人材像」があり、その人たちにすごしやすい環境を整えるべきなんではないでしょうか？

泥の原因

個人的には泥の原因はこれじゃないかというのがあります。だいたいこの中のどれかか、これの組み合わせじゃないでしょうか？

• 全方位的に興味をもった、定まらない人材
• そういった人材と誰でもできる仕事を提供する企業との幸福で不幸なマッチング
• 自主的にコスト競争をし続ける中小企業や学生とか個人
• 特定の悲惨なサンプルがすごいクロースアップしている（誰も定量的に議論していない）
• なんかよくわかんないものを過大評価したり過小評価したりする
• 他人の人格を認めない人たち

すくなくとも、「エンジニアの未来サミット」というタイトルで、なぜかプログラミングっぽい話だけをする感覚自体になにかしろの破綻が見られるように思えます。
（もちろんgihyo.jpが主催な時点である程度察しろという話はありますが）

希望というか提案

• もし泥とか何とか議論したいなら、ちゃんと業界「全体」について考察してみてはいかがでしょうか？
• 「泥」の定義は何なんでしょうか？
• 自分が何に興味があるのか、自分の目標/目的はなんなのか考えてみたらどうでしょうか？根拠のない自信がもてるくらいまでの何かが必要だと思います。
• きれいごとっぽいですが、相手の人格を認めてあげてはどうでしょうか？

そしてもうひとつ。これ個人的には重要なんですが。

• エンジニアリング＝プログラミングではありません。むしろプログラミングだけなら、たいていの場合文系の人のほうが幸せにできると思います。

理系で全うに工学してる人は、学部であっても、webとかよりはだいぶ別次元のことしています。

追記：なんかアレゲなので今後泥の話には触れません。

キャズムを超えろ

変換スピードが遅いとかそのへんの話がいろいろ出てるけど、根本的に連文節変換がないケータイとか(文字を色々入れる人なら)ありえない

はて。これは本当なんだろうかという話。「必要」というのが「これなけりゃiPhoneとか買う価値なさ過ぎる」とかいう意味ならそんなことはないと思う。
（個人的に「必要」ということばは数学的な何かを思い起こさせるのでかなり強い単語に聞こえる）
実は学科の友達も「連文節変換ないのがだめだ」と言っていたのだけど、言われるまで気づかなかったくらいに自分には不便がなかった。
というかPCとか電子機器に対してユーザビリティの点を期待したことがなかったのはあるかもしれないが・・・・たいていの場合人間がUIに順応していくもので、個人的には人間の操作を矯正するのもひとつのUIの設計なんじゃないかなと思っていた時期もあります。

そんなはなしはどうでもよくて。

先のリンク先のブログの書いてあることに誤りはないし、文句もない。しかし、「じゃぁ予測変換があったら使いやすかったのか？」に対する考察がないのはいただけないよね。と、思った。
（例に漏れず駄目だしだけしたところで、それってただの感想文だよねという話。大学で一番怒られる点。）

とりあえず、連文節変換がなくて不便であることは認める。長い文章打って一発で変換してくれればそれはそれは気持ちいいと思う。
まさにDOSの時代に一太郎＋ATOKに出会ったときの一発で変換できたときの気持ちよさに似ている。
けど、じゃぁ一発変換できなかったらどうするんだろうね？
もちろん単語の区切りを再設定して、そこから変換することになるんでしょう。

では、ここからが問題です。「どのくらいの精度で一発変換できると思いますか？」「あのiPhoneのインターフェースで区切りの再設定って容易だと思いますか？」

まず一発変換の精度。定量的な比較は難しそうですが、いくつかの文章をmacのことえりで変換してみましょう。

○もももすももももものうち → 桃もスモモも桃のうち

○となりのきゃくはよくかきくうきゃくだ → 隣の客はよく柿食う客だ

×論文投稿の期限を延長した旨メールさせていただきました → 論文投稿の期限を延長した胸メールさせていただきました

△申し込みを完了する → 申し込み・申込み・申込　などのバリエーションがある

○はっせいほうとせっとくりょく → 発声法と説得力

×工学研究科機械工学専攻　→　光学研究か機械工学専攻

これ以外にもやりましたが、ほとんどの文章でいけました。×になったのは適当にメールから拾った文章で、とりあえず意地の悪そうなのを適当にピックアップしただけなので、かなり恣意的であります。
次に「iPhoneで区切りの再設定は容易か？」という問題。

「変換が誤っている」というのはいくつかのケースに分けられることが観察できます。

• 区切りはあっているが字が違う「光学」「研究か」→「工学」「研究科」
• 区切りがあっていない

今回簡単に試したレベルではほとんどが前者でした。後者もたまにありますが、よくわかんない長い長い学術用語みたいのか、口語っぽい文章で無い限りは無いようです。ひょっとすると若い人の文章は後者多いかもしれませんね。

前者の場合はどうやって修正するのでしょうか？iPhoneには矢印キーがないので、おそらくタッチしてカーソルの場所を動かすことになるでしょう。
該当の区切り箇所にもって行き、そこでスペース（変換）をタッチして正しい候補を選ぶ。たとえばこういうインターフェースが想像できます。

では後者の場合はどうでしょう。
ことえりではshift+矢印キーで単語の境界を切り替えることができます。ではiPhoneではどうしたらいんでしょうか？
まず、iPhoneには矢印キーがないのでことえりと同じ方法は使えません。

次に単語の区切りの再設定モードを作ることを考えてみます。たとえばダブルタッチした場合とか。
すると指でなぞった部分が単語の切れ目として再設定されるというのが想像できます。しかし、iPhoneのタッチの精度は高いと思うものの、テキスト編集エリアで正しく選択できるほどセンシティブではないように感じます。（少なくとも私は）

こういうことから考えると、連文節変換の一番のネックは「一発で変換できなかった場合で、かつ、単語の区切りがあっていない場合」であることが想像できます。

もし、人間が連文節変換のないインターフェースに順応することが可能であるとすると、こんなややこしいインターフェース実装するより、連文節変換実装しないほうが便利であるという可能性が出てくるような気がします。
なんにしても、連文節変換で正しい変換がされなかったときの修正を簡単にやる方法が思いつきません。逆に言えばこれさえあればiPhoneに実装されるんじゃないでしょうか？

以上は仮説なので、所詮実証実験するまでは仮説なんですが・・・・

まとめると、

• 多くの文章で正しい連文節変換が一発でできそう
• ただし、正しくなかった場合の修正が容易ではないことが想像できる
• 予測変換でことが足りるなら、それに人間を合わせるほうが有効

これら3つのことは仮説でしかないのですが、実証実験をすることは可能です。実験の仕方もいくつかアイディアがあります。
だれか批判ばかりではなくてこういう建設的な実験してくれる人っていないのかなぁ？（タダでやる人は神な気がするけど）

なんにしても、「連文節変換がないと不便」であることは認めるものの、「あったとしても有効かどうかはかなり疑問」というのが個人的な意見です。
すくなくとも人間が順応で着るならそっちのほうが便利そうであることは確かです。

追記：

なんにしてもiPhoneが最初から不便であろうことはわかっていたのに、そこをつっつくのはなんかなぁというきがする。
自分の周りでは「まず契約の時点でソフトバンクが落ちて契約が手間取る」とかいうあたりから、ネタではあるけど、予想してた。

なんにしても、プログラムが組めて、ある程度浅くではあるがITにかかわっている身として注目しているのはandroidです。
あれはビジネス的な点でフワフワしてるのでいまだになぞですが、携帯OSのなかでは一番リナックスに近い存在です（まぁリナックスなんだけど、ライセンスやオープンソースという点で。iPhoneってappですらおーぷんにできないよねぇ？）
世間も3Gの登場で世界的に通信方式が統一してきたし、少なくとも国内は統一しつつあります。
携帯の価格あたりのハードスペックも上昇しアプリケーションが自由に開発できるところまで着ました。
じゃぁあとはPCと同じ展開になるんじゃないでしょうか？
キャリアごとの設定部分(SIM?PCだとBIOSとか)とOSが分離して、OSも自由に入れ替えられる。インターフェースもマルチタッチが普及しちゃえば、どのOSでも扱えるようになりますよね？
そもそもOSの低レイヤー部分でインターフェースの差異を吸収しちゃえば大丈夫でしょう。PCだっていろんなキーボードつなげるのと一緒です。

昔の汎用機とかの時代に詳しいわけではないですが、なんかおじさまがたの昔話を聞いてると同じことがおこっているように感じました。

あなたはどう思いますか？

追記２：

現状、app入れた程度でなにもカスタマイズしてないので、iPhoneの有用度とことん低いです。
とりあえず何人かに自慢して優越感に浸ったとかでしょうか・・・・

自分の場合、情報端末として使う目的が高いので、その辺のカスタマイズを徹底的に（時にはコーディングもして）やらないと役に立たないという・・・・
たぶん作ったものは公開しないけど。（iTunes storeに出すほどクオリティあげるのめんどくさい）