あまりにも情報がないのでまとめてみようかと。音声認識以外の用途でつかおうと思うとなかなかとっつきにくい。

• HTK basic tutorial とてもシンプルなhtkのサンプル
• Handwriting Identification and Verification Tutorial htkを手書きで使うときのサンプル
• Course in Speech Recognition 音声認識の講義（HTKを使ってる）
• HTK3 のバッチ＆ストリーミング認識デモ 音声の例じゃないのでいいかも

以下は関連ライブラリなど

• ATK API fot HTK C++ Bindings

今回データとして音声以外を使うのでSOURCEFORMAT＝USERと、HQuantあたりが鍵かなぁ？

音声認識などでよく使われるHMM（隠れマルコフモデル）を使うときに便利らしいHTK。
環境依存みたいですが、サンプルがそのままだと実行できないことがあります。
そういうときは次のフォルダを作って見てください。

hmms/
hmms/hmm.0
hmms/hmm.1
hmms/hmm.2
hmms/tmp
proto/
test/

こうするとなぜかできる。

前回のエントリー

centOS5にmerbをインストールする

最後設定まで終わったところでrubyinlineでエラーが出ていたわけですが、それを解決しました。config.ruを書き換えます。
私は次のようにしました。

まずmerbアプリのディレクトリの直下にtmpディレクトリを作ります。
パーミッションに気をつけておいてください。その上でconfig.ruを次のようにします。

require ‘rubygems’
require ‘merb-core’

m_root = File.expand_path(File.dirname(__FILE__))
ENV["INLINEDIR"] = m_root / “tmp”
Merb::Config.setup(:merb_root   => m_root,
:environment => ENV['RACK_ENV'])
Merb.environment = Merb::Config[:environment]
Merb.root = Merb::Config[:merb_root]
Merb::BootLoader.run

# Uncomment if your app is mounted at a suburi
#if prefix = ::Merb::Config[:path_prefix]
#  use Merb::Rack::PathPrefix, prefix
#end

run Merb::Rack::Application.new

前回のエラーはruby_inlineというrubyに埋め込んだCのコードを実行するためのライブラリがテンポラリファイルを作ることに失敗していたわけです。
それをENV["INLINEDIR"]で指定してあげることで解決しました。

上のconfig.ruはこのままこぴぺしても使えるようにしてあります。tmpディレクトリだけちゃんと作ってください。

では、楽しいmerb生活を！

追記：公式wikiにpassenger + merbに関する記述があります。そちらも参考に

Deploying with Passenger

CentOS5はrubyのバージョンとかgemのバージョンとかの関係でなかなかmerbがインストールできません。

とりあえずえらく苦労したのでメモ代わりに。自分はもともとmod_railsで動く環境があったので、そこから変更をしました。

目標はpassengerのmod_rackとmerbの組み合わせで動かすこと。

まずrubyをアンインストールする

2008/11/15現在、centos5はruby1.8.5なんですがmerbはruby1.8.6以上でgem1.3以上じゃないと動きません。なのでyumで入れてる人は全部削除しましょう。

yum remove ruby

yum remove rubylibs

ねんのため次のコマンドを実行して残ってないか探してみましょう。

yum list ruby |grep installed

なにもでなければ大丈夫です。

checkinstallをインストール

なにも気にしないで入れてもいいのですが、ソースからコンパイルしてインストールすると、アンインストールが大変です。それを簡単にするのがcheckinstall。これを使ってruby1.8.7をインストールします。

rpmがあるのでダウンロード。で、インストール。

rpm -ivh checkinstall-1.6.1-1.i386.rpm

yum install rpm-build

これで完了。/usr/local/sbinにインストールされるのでルート以外だとパスが通ってません。ここ注意。
またrpmを作る場合はrpm-buildがないと動かないので入れてない人はインストールしましょう。

ruby1.8.7をインストール

とりあえずサイトからソースをダウンロード。自分は最近話題のmod_rubyやらmod_rackやらのpassengerで動かす予定なので、共有ライブラリを作るようにconfigureしました。

./configure –prefix=/usr –enable-shared

make

sudo /usr/local/sbin/checkinstall

いろいろ聞かれますが、途中でrpmを選択するところ以外は適当でok。

こうすると、rpmが/usr/src/redhat/RPMS/x86_64/につくられます。ここでインストール。

sudo rpm -ivh /usr/src/redhat/RPMS/x86_64/ruby-1.8.7-p72.x86_64.rpm

これで完了。

rubygems1.3をインストール

これもソースをrubygemsのサイトから落としてきて展開。で、インストール。

sudo ruby setup.rb

これはこれで終了。

merbのインストール

gemで一発。

gem install merb

passengerのインストール

gem install passenger

passenger-install-apache2-module

ここでもいろいろ聞かれたり表示されたりしますが、出てきたとおりに操作すれば完了。

これでインストールは終了

これでインストールは終了です。

merbをテストで動かす

自分はちょっとエラーでまだ動かせてないんですが、基本的にこのサイトの「merbでつくる」から後をやればokなはず。

inlineのpermissionで起こられたら

このサイトの情報で直ると思ってます（まだ試してない

とりあえず動かせたら続編まとめます。

IPAの未踏プロジェクトに応募してみた。

内容は先週まで東大のビジコンに出してた内容で、一ヶ月くらいかけてビジネス面については脳内でできてきたんだけど、今度は実装がないのが問題（いつもは逆なんだが）なので、作るのにお金をくださいというのでアイディアを投げてみた。

たぶん発想としてはずっと前からあったもので、自分が調べた限りでは1980年にはすでに発想があった。まぁあのころのPCスペックでは実現するはずもない。逆に言うとそれくらい今は進歩してるんだなというのを再確認した。

基本的な内容としては俺デスクという過去の未踏プロジェクトにとてもよく似ている。たぶん違いといえば、向こうがテクノロジーであることに対して、こっちはサービスであるという差くらいなもんだろうか。
もちろんそのサービスを実現するためにテクノロジーがあることは間違いないが。

最近思うのはテクノロジーとサービスは分けて考えるべきだということだろうか。例外はあるだろうが、テクノロジーはサービスを提供する人に対してしか売れない。そしてサービスを受けたいと思ってる人はテクノロジーは買わない。この点だけ抑えておくだけでも、ITビジネスでトンチンカンなことを言わずにすむような気がする。そしてほとんどの人はサービスを提供しようとしていて、テクノロジーは提供しようとしていないように最近感じる。

サービスの根本は、お客様に代理してなにかを行うことであると最近思う。マッサージでもamazonでも基本的には、「肩をもむ」とか「本を手に入れる」という行為を代わりにやっているに過ぎない。mixiだったら「友達の近況を知る」ことを代わりにやっているといえるかもしれない。
それをすることによってお客様の行為を代替し、手間が減っていることが重要。客の視点から見れば、中身がどうであっても結果が同じなら大して興味はない。
「フェアトレードだとかチームマイナス6%とかああいうのを進んで選んでいる」という人もいそうだけど、それですら結局は南米のなにかの問題とか地球温暖化に関して自分が何かをする代わりに誰かに何かをしてもらっているということに過ぎない。

サービスとコンテンツは分けて考えるべきであるように思う。漫画とか映画とかああいうのをコンテンツと呼ぶなら、それはサービスとは違う。
映画をサービスと呼ぶなら、それは映画館が提供しているサービスであって映画製作会社が提供しているものではない。
コンテンツをうまく形容する言葉はあまり思いつかないのだけど、誤解を恐れずに言えばなくても困らないものである。コンテンツの本質は0から1を作り出す作業である。テクノロジーが価値を積み上げていくバベルの塔で、サービスが客の手間を減らす引き算だとすれば、本当の意味で価値を作り出しているのはコンテンツだけなんじゃないかと思う。もともと0なんだから、無くたって変わらないのでなくても困らない。
言ってみれば嗜好品。贅沢。暇つぶし。なんかいろいろ言い方はあるだろうけど、生活に本当にvalue addしてくれるのはおそらくコンテンツなんではないだろうか。

なんか色々書いたけど、なぜかこの辺の区別がITはなかなかされにくいと感じる。もちろんひとつのプロダクトを見たときにそれがサービス・コンテンツ・テクノロジーの組み合わせでできてるというのは十分有る話ではあるとおもう。が、その価値構造とか、それによって得られる効果とか、扱い方とかぜんぜん違う。なんか自分が知ってる範囲ではこんな混沌としている世界はITしかしらない。

とかいってみても、別にこういった議論だってあまり意味が無いように感じる。お金大好きな私とすればこんなこと考えなくても売れれば別にいいわけです。単にこういうこと考えるのはブログ書くのと同様趣味でしかない。
実際的にものを売ろうと思うんだったら、少なくともやらないといけないことは「商品を作る」「売る」の2つである。これをやらずに儲からないだなんだと言ったところで意味は無い。
今まで書いたような妄想は、それがもう実行されているか、もしくは、実行される予定がすでにある状態で始めて役に立つように思う。
だからといって、「がんがんつくれ」とか「がんがん売れ」とかいうのもなんかなぁと思うんだけど、要はいつも思うとおり3秒頭を使ってほしいということだろうか。
頭使ったからといってわからんものはわからんのだけど、3秒思いをめぐらすだけでも無駄が減るんじゃないかなといつも思います。

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

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にしても、データ形式としてなにが標準なのかという点は常に重要です。
それが、クラウド化してファイルというデータのエンティティが希薄になったときどういう表現が標準になるかというのは重要であるように感じます。

まとめ

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

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

理科離れについて

理科離れなんだろうか？ということをよく考える。自分は大学に行きながら実は「学生の勉強離れ」を感じることが時々ある。「数学とか理科ができて何の意味があるの？」というタイプの人間は、実は文系理系関係なく存在して、どっちにしても勉強していないのであって理科離れが深刻化しているわけではないように思う。

さらに、「数学と理科ができて何の意味があるの？」は、即そのまま「歴史や心理がわかってなんになるの？」につながる。一見社会に役立ちそうな法学部や経済学部であってもあまり生活に役立つようには思えない。判例をたくさん知っていたところでなんになるというのだろうか？
実は理科離れの「なんの役に立つの？」という問題ではないのである。それどころではない。理系文系関係なく「勉強して何の意味があるの？」というレベルにすでに達しているのではないかと思う。

少なくとも自分の経験している範囲について思うことをいえば、高校・大学は実際に役立つことなんかひとつも教えていない。抽象的な議論だけを教えて、いいとこ見れたとしても研究の世界までである。それが現実にどう応用されているかまで教えてくれることはレアである。
現実への応用は個々人のイマジネーションに任せているわけである。
もちろん、工学部であれば卒業論文を書くにあたって、それがどういうふうに社会的意義があるのかという点を書かされるので全くそこに対する想像力がないわけでもないが、逆に言うとそこまで全くそんなことを考えるチャンスはない。

言い方が悪かった気がするので、言い直すと「実際に役立つようには教えていない」

そのくらい脳みそ使えよとか思わないことはないけども、インストールされていないソフトは使えないのである。誰かがインストールしなくてはいけない。
自分がこんなこと思うのも、割と偶然ＩＴ関連で仕事をしているなかで、ちょっとした数学や統計的手法が使えた体験があるので思うのであって、ほとんどの人はそんなことには気づかないのではないだろうか？
少なくとも実際の応用までたどり着いてるのはオタクと思われてる人たちしか知らない。これは非常にハードルが高い。

個人的には、こうして根本的に勉強離れが起きていて、それが理系だと「理科離れ」、文系だと「後継者不足？」とかになっているんではないだろうかと思うことがある。

ちょっと角度を変えて考えてみよう。

理系は果たして儲からないのだろうか？こっからはどっかの教授から聞いた話であるので、真贋のほどはよくわからないが。

実は証券うったりかったりして儲けている人にはものすごく偏りがあり、平均ではなく中央値をとると技術職のほうが実は給料が高い。 
しっかり勉強していればという前提はつくかもしれないが、じつは積み上げられたものが全否定される可能性は技術職のほうが小さい。
最近人気だった外資コンサルにしても、ＭＢＡなしではそれほどたいした話ではない。
ここで「お金じゃなくて経験なんだ」という話が出てきたりするが、そんなの技術職でも同じことが言える。国際学会いって発表して交流するのと、外資コンサルいって大企業の偉い人と交渉するのはベクトルの方向の差こそあれ、長さに差があるようには思えない。
こう考えると金銭的面をとってもそれほど理系職が不利であるようにも思えない。 

これは聞いた話なので実はよくわからんのだけど、これが本当だとするなら実際の差はそれほどない気がする。むしろ文系職は今まで積み上げてきたものを全部捨てて一から覚えなおしたりするわけである。よほどそっちのほうが大変じゃなかろうか？それともいままで何も積み上げてこなかったということなのか？

しかし、理系離れというのは事実として起こっているらしい。ひとつには理系のオタクなイメージがありそうではある。けど実際は勉強するという行為自体がなくなってきてるんじゃないかなと感じる。逆に言ってみるとオタクじゃないと勉強とかやってられん状態なのではないだろうか？

結局結論はよくわからんのだけど、個人的に思うのは「勉強なんてくだらない」という風に思ってる人がたくさんいるのではないかというところである。これは理系離れという枠を超えて深刻なのではないだろうか？

しかし、実際は「勉強なんかどうでもいいや」なんてことないんだけど、まぁそれはまた別の話。参考にこれくっつけておこうかな・・・・

知っておきたかったこと　Paul Graham, January 2005

「すぐやる！」技術

自分に足りない要素は多々あれど、そのうちのひとつが「すぐやる技術」である気がしていたので買ってみた。

たいがいやりたいことやってるつもりではあるんだけども、それでもチャンスを逃したと思うことは多いし、他人を見てて「あぁとりあえずやってみりゃよかったのかぁ」とか思うことが少なくはない。

特に感銘を受けたのは、一章「相手の懐に飛び込む」だろうか。
自分は割りと今まで周りがちやほやしてくれることが多く、ほっといても人が寄ってくるし、なんだかんだ仕事もふってきたりするし、なんとなく有名人がゴロゴロっと周りにいたりもするし、色んなイベントなども紹介してもらえたりとかしていた。
なんというか、受身で結構何事も何とか回ってしまう不思議空間が出来上がっていた。
むしろ、「自分から働きかけるのなんてかっこ悪い」とさえ思っている節すらあった。けどそれは単純に「こっちから話しかけて無視されたらどうしよう」という恐怖の裏返しでもあったのかなと思う。「こんなこといってdisられたらどうしようとか。」
けど、それでも周りは「自主的にやってる」と評価していてくれたので、そう思ってはいたんだよね。

しかし、事実はそうでもなかったわけです。
なんだかんだで一生懸命仕事やったり勉強したりしていたわけですが、それもやりつくすとこうなりました。「こっからどうしようかね・・・？」

何はともあれ、起業っぽいことをしてみたくて仕事としてのＩＴを覚え、仕様書書きからテストの仕方まで荒くではあるけど勉強し、なんやかんや仕事をし、プログラミングもある程度はできるようになり、けどじゃぁこっからどうしようか？
急に選択肢が出てしまったときに「ウッ・・・」と立ち止まってしまったわけですね。
ここ長いのではしょりますが、要は自分から何かを働きかけていたわけではないという結論になったわけです。

ポイントは、用意された組織の中で誰かに誘われるままいき、そこで自己満足したり威張り散らすのは簡単なわけです。物凄く。 
そうではなくて組織の外に、まったく知らない人にどうアプローチしていくか。重要なのは結局ここであり、それは自分自身のモチベーションに基づいていることが重要です。 

そんなことをここ１，２年思いながら生きてるわけですが、そのための入門本としてはお勧めです。
分量があまりないのですぐ読めるし、馬鹿みたいに簡単なことしかことしか書いてないのですっと理解することができる。
筆者の体験も絡めて書いてあるので勇気ある第一歩を踏み出すためにはいいかもしれません。

なにかひとついい具合に回ると、ついつい安定志向に走ってしまいがちな人にはいいと思います。

某女史からリンク申請が来て「おー、そういえばmixiやってたんだっけかな」とか思い出したので、復活してみた。

何でやめたのかというと、しばらくネットからは引きこもろうという趣旨で半年～一年くらいはtwitterのみでやってたんですが、mixiでないにしてもfacebookとかlinkedinとかからバラバラとリンク申請来るのを見て「あぁやっぱしSNSっていいコミュニケーション手段になってんだなぁ」と感じました。

あんまみない気もしますが、近況報告見たいのは書きます。

たぶん本名で探すと出てくるので、思い出した人はリンク申請をば。

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

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

考え方としてはこうだ。

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

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

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

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

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

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