読み書きができる能力 (Literacy) は、ながらく教育水準をはかるバロメータとして使用されてきました。読み書きソロバンと言われてきたように、
基礎的な数学能力を表す Numeracy という言葉もあります。
これに加えて、近い将来プログラミングをする能力が人間の基本的な素養として重要になってくるのではないかと思っていましたが、同じようなことを考えている方が記事を書いていたので紹介します。
彼は Coderacy （コーデラシー）と名付けていますが、なかなかいい名前じゃないでしょうか。
色々考えてしまうので、考えたことをメモしておきます。
CC8800-1という巨大なクレーン車があるそうです。
国内にも何台かあるっぽい。
140mぐらいアームを伸ばせる。
これを使って放水ホースの先端をプールに取り付ける。
取り付けたらあとは使用済み核燃料が冷えるまで、数カ月間注水を続ける。
取り付けは大変そうだけど、ホース先端に錘を付けてプール内に吊るし落とせばいけそうな気がします。
Though it may be needless to say.
There must be languages or grammars hidden in the manner of developing games to have human-beings worked for various tasks.
The main reason of which I was felt in love with Merb is it uses same context for controller and view.
By sharing same context, view_helpers and instance variables become simple.
You just use them in controller then you can use them in view by same manner.
But as you know, Rails3 doesn't.
The reason Rails3 doesn't is probably for caching.
If the view has many outer variables that affects its result, the cache key tends to be very complicated.
In the manner of Rails3, we can use both action caching and partial caching easily. Because the all variables used in view are clear and small.
But in these days, I am doubting the use of those caching.
Now we don't use browsers that has no capability of JavaScript.
In addition, Google treats Ajax pages for indexing well.
Haven't you ever seen the URI that has '#!'?
That's for it.
So now, the most of pages can be provided as static html with dynamic JSON. They are combined by JavaScript.
There's few situations that the action caching and the partial caching go well.
In conclusion, I think the context should be shared between view and controller so that we can use view helpers simply.
fltkもGLUTも気がつけばFATになっていっている気がします。
だいたいこのぐらいで十分なので、
GUI toolkitが欲しいです。無かったら作ろうかな。
ストレージを操作するための言語として、SQLは制約が大きすぎ、MapReduceは自由すぎるので、中間ぐらいの自由度のストレージ操作言語があると良いと思う。
GIレンダリング言語（aka GIRL）の立ち位置はそのあたりかな。
残念なことに、技術者がその技術だけで名前を上げることが出来るシステムは、世界中探してもない。つーか、世の中ってそんなものなのだ。
いまであれば、そんな事は無いと言えると思う。
金子勇さん、おめでとうございます。
技術だけで名を挙げるには、冒険家である必要があるのかもしれない。
本当に先鋭的で革新的な技術は、社会を不可逆的に大きく変更してしまうので、強い反発や抵抗もあるだろうから。
自然言語の場合はよくわからないけれど、
プログラミング言語に関しては、まず書きたいプログラムが特定の言語に依存せずにプログラムそのものとして脳内にあって、それをプログラミング言語に翻訳しながらソースコードに置き換えていっているように感じる。
多分、フローやデータ構造については、言語の力を借りずに思考できるのかもしれない。
Through my investigation for writing about the parallel computing,
I found there are many "incoherences" and "inconsistencies" all over various terminologies regarding parallel computing.
I guess surrounding environment is so fastly changing, the center of excellence of this research field has been moved very frequently.
Most of significant works had been done in the era of sequential computing.
But for very near future, we will be going into the era of parallel computing. The terms that had been spawned in the hypothetic world would get real body and require coherent and consistent definition of themselves.
ちょっと趣向をかえて製本の話です。
分厚すぎて持ち歩きにくい技術書などを、章ごとに解体するという事はまれにあると思いますが、いつも困るのが章見出しが見開きの左側に来てる事です。
見出しが見開きの左側に来ている場合、章ごとに本を解体すると、見出しのページの裏に前の章のページがあったりして難しい事になります。
それに対して、見出しが見開きの右側に来ていれば、簡単に章ごとに分解して持ち歩く事が出来るようになります。
In these days, I am thinking about how web services can be provided without shutting down.
An answer I got is keep it small.
Small services can be provided without maintenances.
For example, the Formula (http://formula.s21g.com/) has been provided for more than a year. But it had virtually neither maintenances nor updates.
But it is used by someone sometimes.
The cost of keeping such services is about $50 a month.
It consists of only the cost of an EC2 instance.
An instance can offer several such services, so the cost would be shared by them.
So thus the individual cost becomes more low.
Suppose the cost is $20 a month,
we can gain it by a fund of $4800 if it earns 5% a year constantly.
If it is possible, it can be a new way for providing services such as the Formula.
I am very surprised to hear this.
Needless to say, Eric Veach is a guru of GI researcher.
I have wondered where he vanished after his great doctor thesis.
And now I know he was at Google, and used his speciality of probability statistics for the AdWords.
I've been believing that GI problem has very rich context.
It can be used as the best tool to think algorithms.
弊社は、deployツールとしてcapistranoを使っています。
しかし、Capistranoのメンテナンスが終了するという話("Jamis Buck氏, CapistranoやSQLite/rubyの開発を終了"参照)を聞いても、
特に困らないという事に気がついて、あらためて驚きを感じました。
なぜだろうと考えてみると、それはGitとGitHubの存在による所が大きい。
GitHubにソースがある限り、メンテナが不在でも勝手にforkして
野良patchを書いたり、それを集めてきてちょっとした
stable release的なものを作ったりする事ができてしまう。
もちろんそれは、今までだって頑張れば出来た事だけれど、
Git/GitHubは、それを全く違う次元で簡単にしてしまった。
かつてはメンテナやコミッタが専権的にソフトウェア開発の決定権を握っていた構造が、Git/GitHubの登場によって、気がつかないうちに崩れ去っている。
これはソフトウェア開発史上、非常に大きな出来事なんだろう。
See Also
名もないベンチャーが億単位の案件を獲るには (Re: 真のソフトウェア工学はもう存在している)
ただ500億円ほどのプロジェクトであれば、そのすべての金額を1社に任せるのではなく、保険のために金額の1割を小さいベンチャー企業に任せるというのはありだと思うんですけど、どうでしょうか。どんなに大手でも失敗するときは失敗するから、無名だが優秀そうなベンチャーにも同時に案件を任せてみるというのは、リスクを回避するという観点から十分にありだと思います。
イメージ的には、自動車保険の代車費用担保特約みたいな感じですね。
実績があるが高コストな方法が主流を占めている状況で、実績は無いが低コストな方法を売り込んでいく手法というのは、過去の歴史の中に色々と成功例があるはずなので、調べてみたいですね。
従来のソフトウェア工学が決定的に間違っている点は、
ソフトウェアを作るソフトウェアに関する工学ではない事だと思う。
100倍の生産性を達成するためには、ひとつ階段を上にのぼる必要がある。
従来のソフトウェアエンジニア人事工学が決定的に間違っている点
「やらなきゃいけない」仕事が20%で、残りの80%が「やりたいしごと」。たとえ単純作業でも、残り80%にそれが属しているのであれば嬉々としてやってしまう。彼らからこれを取り上げてしまうと、残り20%も小さくなってしまう。好きなようにやらせておくのが吉である。
つまらないコードを生成するコードを書く事は、
つまらないコードを書く事自体と比べて何倍も面白い。
手でコードを書くプログラマと、コードにコードを書かせるメタプログラマでは、
規模が大きな仕事になるほど差が開いていくと思う。
真のソフトウェア工学はまだ未来のものだ。一年とかけずに三千人以下でエンパイアステートビルを造り上げるようなものは、現在のソフトウェア工学に存在しない。(中略) 何十万もの奴隷を何十年も使い石に石を重ねてゆく様は、まさに今日ほとんどのソフトウェア開発で行われている事だ。
真のソフトウェア工学は、もう存在している。それは、
タワークレーンを使った高層ビル建築
に似ている。
メタプログラマーの仕事は、タワークレーンを組み立てるために小さなクレーンを動かす事だ。
それを実現するための道具はもう揃っていると思う。
それを使いこなしてる人もそれなりにいる。
では何が足りないのだろうか。
それはなんと言っても、実績が足りない。というか無い。
例えば5人のメタプログラマーの会社が、500億円の案件を50億円で受注したというような事例は皆無だと思う。
経営者は、万が一プロジェクトが失敗に終わった時に、実績が無い事に手を出した事を責められる事になる。
しかしながら、これについては成功事例が生まれれば改善する可能性があると思う。
営利企業の経営者が、これほどの節約機会を見過ごすとは思えない。
という事で、システム経費を劇的に圧縮する方法をお探しの方は、
までご相談ください :-)
追記
と、ふと思った。
その誰か、というのは、実は明らかすぎる。
医師不足と言うけれど 医師不足の中の諦め「今よりもっと良い周産期医療体制を望みたい」
と誰かが望んでも
「今より少し不便になっても良い」
と誰かが許容しなければ議論は進みません高齢者たち、である。
I thought that the engineer's happiness is always in an expanding market of which it's expansion is benefit to all players.
Because the market is tolerant to mutual cooperation.
長い時間がかかるテストを実行してる間に。
もはやテストがない開発なんて考えられないけれど、
テストの実行時間が昔のコンパイル時間のように感じられます。
ちょっと前にデスクトップPCがPCの主流をノートPCに譲ったように、
iPhoneのようなモバイル端末がノートPCに取って代わるのは時間の問題であるように思います。
このような世代交代は、かつて人類が何度も経験してきたことであり、
ことコンピュータに関する限り、プログラマーという人種は最先端のデバイスを使いこなしてきたのですが、今回の大波を乗りこなすのはちょっと大変なんじゃないかと思っています。
モバイル端末の小さなキーボードや、iPhoneのようなソフトウェアキーボードにしても、どうにもこうにもプログラムを書くには不便すぎるのです。
プログラムを書くための環境は、デバイスの進化の本流から零れ落ちてしまうのでしょうか。
その昔、プログラマーがパンチカードを捨てて、キーボードによるプログラミングを覚えて以来、長いことお世話になってきたキーボードが、
プログラマーを椅子に縛り付ける鎖となってしまうのかもしれません（ノートPCがあれば多少は動けるでしょうが、iPhoneの機動性とは比べるべくもないですね）
そうならないようにするためには、モバイルキーボードに特化した言語を考える事も意味があるかもしれません。例えば、10個のアルファベットからなる英語のサブセットみたいなものを考えたら良いでしょうか？(Brainf*ckよりもっとフレンドリーなものを希望）
それとも記号をなるべく使わないプログラミング言語を考えたら良いでしょうか。
あるいは、キーボードではない入力方法でコーディングをする事を考えるべきでしょうか。図形を並べるようなプログラミング手法をGUIで行うようになるのでしょうか。
はたまた、プログラムを作るためのデバイスと、プログラムを使うためのデバイスは、永久に袂を分かつ事になるのでしょうか。
I had felt an interestingness when I used the seesmic.
I had kept thinking that it is really interesting because its service is cool.
But recently, I found that it might be not truth.
I have tried plurk.com since yesterday.
It seems to have an interestingness same to what I had felt from seesmic.
And I found the interestingness comes from not its own uniqueness nor good design but from its users.
New community site is a meetup place for early adoptors.
They usually add me as a friend even if they don't know about me.
And they speak to me friendly.
These are all good enough user experience of which I think this service is nice.
The language is the first tool and is the last shackle.
Or rather, every useful tool easily becomes a shackle.
The more useful tool is the stronger shackle.
The language is the most useful tool for us mankinds, whether programming languages or natural languages.
マーク・ピーターセン氏の「日本人の英語」、「続・日本人の英語」を読んでいる最中なのですが、この本はとても良いですね。
日本語は複数形が無いので、片足なのか両足なのかを決定せずに、「足が痛い」といっても何の問題も無いですが、英語では必ず片足が痛いのか両足が痛いのか決定しないとならないようです。
一瞬、Lazy Evaluationをサポートする言語としない言語の違いのようなものかなと妙な理解をしかけました。
が、実際のところ、
僕の場合、「足が痛い」といわれたらなんとなく片方の足が痛いのだろうと推測するし、「目が痛い」といわれたら両目とも痛いような気がする。
何が痛いのかによって、両方なのか片方なのか暗黙の了解があるゆえに、日本語では複数形や単数形の明示を要しなかったのかもしれないですね。
文化的な等質性のなせる業なのかな。
そういう意味では、英語の方が異文化コミュニケーションに適した言語なのかもしれないですね。
拙作の
vimouse
を改良してくれてる人がいるのを見つけました。
自分が作ったものに興味を持ってもらえて、あまつさえ改良を加えてもらえるのって、単純に嬉しいですね。
オープンソースは楽しい。
Insecure OPs easily bring problems to consumers trusting them.
I think that there should be a kind of world wide reliability evaluation system for OPs.
Suppose every OPs has its score on the list of OPs and they should make an effort to keep its score high.
RPs are able to exploit it to know which OP is trustworthy.
But obviously, the list is centralized.
This is the SPoF and is a quite big drawback.
It should be kept decentralized as well as OpenID itself.
These days, I have been thinking about OpenID.
It is able to gather privacy informations at one place and they would be maintained easily.
On the other hand, thus it may become easy to cause a security crisis.
In order to find the solution, I have thought for a while.
I think that the secret sharing scheme (SSS) could be useful for solving this problem.
In other words, it could be reasonable way for achieving convenience and security to share the encrypted privacy informations between several OIPs by using SSS.
But I have no idea to make it run on the current OpenID spec. Hmm.
しばらく前からOpenIDについていろいろ調べているのですが、
個人情報が一箇所に集中することで、便利になる反面、
セキュリティ上のリスクが高まるという指摘があります。
確かにその通りで、対策を考えていたのですが、
マスターキーを秘密分散方式で複数作るのが、妥当な解決策かもしれないと思いました。
２つ鍵穴があるドアのイメージですね。
どちらか一方を奪われても安全なわけです。
セキュリティ強度の必要に応じて３つ、4つと増やしても良いですね。
現状のOpenIDの仕様の上でうまいこと運用できないかなあ。
See Also
I am worrying about the future of our natural right on the Internet.
Here right I say is for us to be human obviously.
In a word, it is becoming harder and harder for computers to distinguish human and bot.
Our activities on the Internet is too simple to recognize ourselves as human beings.
There are only click, click, click many clicks and sometimes typings.
Needless to say about clicks, nowadays, even typings are easy to be imitated by using algorithms of a sort of Markov-chain.
I think that this problem is worth discussing more.
If we lose this identity war, most of internet companies will lose their values brought by advertisements.
I guess that the identity provider such as OpenID Providers becomes very important role in near future.
They will become providing not only an identity but human proofs.
I remember a lot of his works I had read when I was a child. Especially I'd loved "Childhood's End" and "Rendez-Vous With Rama".
I think that his achievement tells us that the science fiction is not only a sort of fictions.
It can have a mission of a prediction of the future for us.
It may be possible even to make our future if it was written by excellent SF writer such as Arthur C. Clarke.
We engineers have been chasing their works.
Sometimes we have achieved or forestalled them even, but yet there are too many things which are waiting for us.
I pray for the future to keep attractive futures.
The title of this blog has the meaning of forcing me to think English as a programming language so that I can learn it as well as programming languages.
I have started English lesson since last Saturday.
I had found myself that my listening skill of English is so poor. It's necessary to do strong effort.
I have also started to listen
ESL podcast.
That is very easy to listen, because the speakers speak very slowly and clearly.
天才の成せなる技とは思わずに、
- 努力しないでいいように
- 論理的に考えなくてもいいように
- 頭を使わないでもいいように
最初からそう組み上げていく。
頭を使うプログラミングと、頭を使わないプログラミングは、
同じプログラミングでも本質的に違うものなのではないかと思う。
IMHOだけど、頭を使わなくてもいいプログラムを書き続けることは、
将来的に自分の可能性を狭めることになるんじゃないだろうか。
組み上げるほうに時間を使う、という話なのであれば納得だけど。
僕自身に関していえば、
コードを書いている時間よりも、頭を使ってる時間のほうが何倍も長いです。
一日100行もコードを書かないこともありますが、
そういう日のほうが仕事をした感じがします。
キーボードに向かってコードを書いているときは、
あまり仕事をした気がしないかも。
脳内で出来上がったものを書き下ろしてるだけだからね。
傍目にはぼんやりしてるように見えるとき、一番仕事をしていると思う。
See Also
実感としてそうだなと思うのだけれど、どうしてそうなんだろうか。
素朴な疑問が残った。
21世紀は都市の時代。都市を地方化するのは時代の逆行にしか思えない。
インターネットなどの情報通信技術が発展し、
地理的な制約は徐々に少なくなっていくにもかかわらず、
都市人口率はむしろ増加している。
Figure 1 Percentage Change in Urban Population, 1950-2030.
(from Urban Harvest: A Cgiar Global Program on Urban and Peri-Urban Agriculture)
通信技術のもつ、人間の面白いもの・楽しいものに集まろうとする性向を
助長する要素のほうが、
コミュニケーションを地理的な制約から解放する要素よりも
勝っているという事なんだろうか。
楽しいものや便利なものが飽和してくると、
逆に都市人口率が下がったりするのかな。
Matz might have a plan to introduce the method that calculates a cartesian product of two ranges into future Ruby. It is very interesting.
CS 11: Python track: python idioms
He has been thinking a good name for the method.
I wish that there could be more set operators in future Ruby.
In this weblog system, "nickname" and "email" required to IdP.
This is from a behaviour of the original RestfulOpenIDAuthentication plugin.
(I think that it is expecting the myopenid.com as default IdP and it has them as mandatory parameters.)
If you are using other IdP, it might have neither "nicknames" nor "email". In that case, you need to fill the lacking parameters and to retry.
Obviously, that was a big barrier for users.
So I have changed this system so that can make IdPs free from required parameters and make a chance to add the lacking informations immediately.
I consider that every IdCs require such the mechanism due to the architecture of OpenID.
身の回りに溢れているほとんど全てのプログラムは、
静止状態の表現としてソースコードを持ち、
計算機上で実行され、そして終了します。
少なくとも、終了しようと思えばできるように作られています。
しかしながら、近年では、Webサーバやネットワークプログラムのように、
継続的に動作することが当たり前で、停止状態に移行する事自体が
例外とされるようなプログラムが珍しくなくなってきています。
RubyやPerl, Pythonなどの動的言語と呼ばれる言語が普及し、
プログラム言語の価値は、実行速度から開発速度で測られる
比率が高くなりました。
そんな中、去年ぐらいから、静的言語でも動的言語でもない、
新しいプログラミング言語のパラダイムの可能性について考えています。
はてしない物語。終了状態の無いプログラム。
停止することなく、動き続けることが想定されるService型プログラムを
記述することに特化した言語があってもいいのではないか。
そんな事を思うようになったのは、
Rubyistにはお馴染みの
irb
と
druby
を頻繁に使っていたからかもしれません。
NEPL ≒ irb + druby + Erlang + Sandbox
今のところ、open な druby サーバに対して irbで接続しに行くというのが、
一番それらしいものが得られる方法だと思います。
しかしながら、openなdrubyサーバを用意するのは非常にリスキーです。
ErlangのActorモデルや、エラー処理に関する哲学が参考になりそうです。
NEPL処理系が実現すると、
ソフトウェア開発のスタイルが大きく変わるのではないかと思います。
何かとりあえず動くものを形にしてみるべきですね。$SAFE = 4なrubyとdrubyをベースにするか、
JavaScriptを使ってやるか、そのあたりを考えています。
See Also
OoO workshop has been successfully held on last Sunday thanks to SGI Japan.
Syoyo, the founder of this event, had predicted the future of GPU in his presentation using a comparison of two charts which are about the Nikkei 225 index and the speed of GPU. Detail is
here.
This is the most interesting prediction about GPU I ever met. Nowadays, CPU is speeding up much faster than GPU and its power consumption is still low against GPU's.
I think that FPGA can be a competitor of CPU rather than GPU in near future. The number of gates in FPGA has become very large so that it could be used for development of very complex processor such as Raytracing Processing Unit as known as RPU.
2/13のIE7のWindows Updateの影響か、
2006年の6/12（1年半ぐらい前）に書いた記事
IE7からIE6に戻す方法
のアクセス数が増えていた。
当時は、ブラウザの互換性のためにIE7のベータ版をインストールした後に
元に戻す方法を調べて書いていたのでした。
今になって参照されるというのも面白いですね。
最近はJavaScriptを使っておれおれスクリプト言語の処理系を
実装するのが流行っていますね。
ちょっとその実用性について考えてみたのですが、
限定されたデータに対してだけアクセス可能な、
サンドボックス的なスクリプト言語というのは、Webサービスの
プラグイン記述言語（サイト内DSLと呼んでみる。
サイト内とDSが被ってる気がするけど気にしない）
としての需要があるきがします。
例えば、次のような特徴を備える言語が考えられます。
どうでしょう。Facebookのようにサードパーティが
アプリケーションを追加できるようなプラットフォームを
作る場合に、JavaScript自体ではなく、JSで実装された、
よりSecureなまったく別の言語を使うことで
より安全性を高めることができるのではないでしょうか。
先日はお疲れ様。
もうね、上だけを見てレンダラの巨塔を登り詰める、じゃダメなのですよ。
どんどん下から登ってくるヤツらが、自分をすっ飛ばして上に挑戦しているわけです。
私の存在？もちそんなの認識されてないよ。皆私をスルー。
同感ですね。CG研究を取り巻く環境は日に日に良くなっていく。
しかし、僕が18歳だったころには、面白い問題はあらかた先輩方に解かれて
しまった後だと、己が生まれてきたのが遅すぎた事を恨んだものでした。
問題を解決することよりも難しいのは、面白い問題を見つけること。
結局のところ、今僕がこうしてCGとは関係ないことをやっているのは、
CGの分野で、自分が一生かかっても解決できるかどうかという問題に
出会ったからですね。その問題が解かれるところが見られるのであれば、
それを解くのは自分でなくてもかまわないのかもしれない。
プログラムの変更のせいか、最近lighttpd+fastcgiの構成で不安定に
なってきた感じがしたので、Thin+Swiftply構成の情報を探してみることに。
しかし、検索してみたけれど、先日書いた自分のエントリとブックマークばかりHitする。どうやら未開の地に迷い込んだようだ。
…と思ったが、よく調べてみたら Swiftplyじゃなくて
Swiftiplyが正しいようだ。良かった。
特に好きなわけではないのだけれど、気がつけば10年以上VAIOを使っていた。
しかし、SONY製のソフトウェアを使った記憶が残ってない。
アップルがiPod+iTunes+iTunes Storeというハード・ソフト・サービスを巧みに組み合わせてネット時代にふさわしいコンシューマ・エレクトロニクス・ビジネスモデルを見せてくれたことに関しては、ここでもさんざん書いて来たが、反面教師として注目すべきなのは、ソニーになぜそれができなかったのか？ということ。
それに対して、Appleのソフトウェアは結構使っている気がする。
わざわざベータ版のWindows Safariまで持ってきて使っている。
ちょっと前の記事だけど、偶然目にして興味深かった。
TechCrunch Japanese アーカイブ ? Skypeダウンの原因はWindowsユーザーだった
Skypeによれば、サービスがダウンした原因は「国際的な規模での定期的なパッチ配布に伴い、ユーザーが非常に短い期間内に一斉にコンピュータの再起動を行ったこと」
P2Pサービスは、ピアの数が一時に大量に減少すると安定性が損なわれる。
それ以外の様々な効率の面で言っても、例えばWindowsアップデートの
ような大規模なシステムの更新は、時間差を伴って行われるべきだろうな。
○○が××の一斉自動更新の影響でダウン、
という現象はこれから増えてくるのかもしれない。
Twitterで話題になってたのでちょっとやってみたのだけれど、
MyMiniCity
が面白いです。
なにやらSimCityを髣髴とさせる画面なのですが、
特に何か操作できるようなことも無く、町が発展するのを眺めているだけ。
メッセージボードみたいなのがあって、一応そこでコミュニケーションは
取れるみたいですね。
自分が作った町のページに人が訪れてくると、町の人口が増える
仕組みらしい。これは良いアイディアだなあ。
気がついたら、何語で書いてあるかわからないブログを購読してた。
ブログの中に書いてあるソースコードだけが頼り。
それでも言いたいこと、書きたいことは伝わってる。多分。
もしも、もしも、
発音されることを意識されて設計されたプログラミング言語
が広く普及したら。
百科事典はクラスライブラリだ。
思い返せば、Widgetという名前を最初に見かけたのは、
wxWindowsなどのGUIツールキットのクラス名（wxWidgetとか）
だったような気がします。
最近、Yahoo! WidgetやGoogle Gadgetなど、WidgetやGadgetという名称を
よく見かけますが、意味的な違いの認識が曖昧だったので
ちょっと調べてみました。
グラフィカルユーザインターフェースを構成する部品要素、およびその集まり→ウィジェット (GUI)、ウィジェット・ツールキット。「window gadget」の合成語ともいわれている。
なるほど、Window + GadgetでWidgetだったのか。
昔、Rails勉強会の懇親会で
yuguiさん
と話した、走り続けるプログラムの事を思い出した。
そして、それを記述するための言語。
継承、遺伝、進化。
だいぶ前に少し試したきり放置していたのだけれど、このところ知人の間で急速に広まっている気がします。
この勢いは、Twitterが出始めた時に似たものを感じますね。
ちなみに僕のページはこちらです。
日比さんが会社のページも作ってくれた。
Value Transformer KingofSmack: Here also good reads for this mobile application d... 05/10 18:02 Spencer: You don't have to re-compile it, this version work... 04/08 07:15 staiano: Any chance we can get a recompile for 10.9? 01/10 01:47 dsjf: https://gist.github.com/6bf1bf2c3cbb5eb6e7a7
これでも出... 01/08 23:23 yoku0825: nkfの方が使いやすいですが、glibcに含まれているiconvの方が
確実にどの環境にも入っている... 06/11 07:03 falsefalse: @tiancongxin try using this one https://github.com... 02/14 08:04