  |
はてなキーワード: prototype.jsとは
なんか最近Webフロントエンド界隈でイキっている人良く見るけど、そもそもどのくらいの経験で語ってるんだろ。
感覚的には、10年前はすっごいしょぼいJavaScriptばっかだったし、それで要件を満たせてたと思うんだけど。
複雑な要件のときは、JavaAppletとか使ってたような。
ちょっと昔を振り返ってみると、
５年前はJSFがすっごいイケてるように思ってたな。今は完全に終わってるけどね。
１０年前は、これからはprototype.js じゃなくてjQueryだ！と思ってた時代かな？
２０年前は、JavaScriptは、ブラウザのステータスバーに文字を表示したり、マウスの動きに合わせて星をキラキラさせるのに使ってたかな。
jQueryのスクリプトは$.(...)ではなく$j.(...)やjQuery.(...)で書く（prototype.jsとの競合を避けるため）
コンピュータ言語って世の中に山ほどあるけれど、それぞれの言語ごとに特徴がある（特徴のない言語は廃れていく）。
あまり言語に詳しくない人相手に、俺の考えるそれぞれの言語の特徴を書いてみようと思う。
なお、取り上げるのはある程度広く使われている言語に限りたいと思う。
| 言語名 | 概要 |
|---|---|
| C言語 | 高速動作するバイナリ生成を目的としたコンパイル言語。だいたいどんな環境でも使えるがバグ出やすい |
| C++ | マニアック言語、高速、習得大変 |
| Java | サーバで高速かつ安定に動作するコンパイル言語、大規模でよく使われる |
| C# | 主にWindowsクライアント用のバイナリ生成に使われるコンパイル言語 |
| Perl | 広く使われていたが今は若干時代遅れのスプリクト言語。汚い |
| Python | Perlにかわって主流になりつつあるスクリプト言語。綺麗 |
| PHP | Web開発にフォーカスされたスクリプト言語。一世を風靡した。 |
| Ruby | とても綺麗なスクリプト言語 |
| JavaScript | ブラウザで実行出来る唯一の言語。言語自体はいまいちだが、ブラウザの事情で需要あり |
| Go | サーバサイドで安全かつ高速動作するバイナリ生成を目的としたコンパイル言語 |
メモリに直接アクセスして書き換えるといったコンピュータの機械語に近い言語構文を持つため、高速な処理が可能な言語。
コンパイラの歴史も古く環境も整っており、組み込み系などを含むほぼ全ての環境で利用可能な万能言語。
一方で、メモリの確保や解放といった基本的なことも自前で処理する必要があるため、コーディングの効率が良くなく、多種多様のバグを生みやすい側面も持つ。
ある程度以上のエンジニアであれば常識として知っておきたい言語だが、初めて覚える言語としてはあまり適当ではない。
C言語にオブジェクト指向を導入した言語。C++言語とはあまり呼ばれず、しーぷらすぷらす、もしくは略してしーぷらぷら、しーたすたす、などと呼ばれる。
C言語の速度を維持したままオブジェクト指向やテンプレートなどの効率的な記述を可能にしようとした意気は真っ当だったのだが、
当時最先端だった色々な技術や思想を叩き込んだおかげで、あり得ないほど複雑化した言語としても有名。
「C++を理解しています」という人はほぼ初級者で、本当に理解していくほど「C++には自信がありません」となっていく。
速度を追求する分野では良く使われている。完全に理解するのは難しいとしても、テンプレートくらいまでは理解しておくと仕事上なんとかなる…かもしれない。
サーバサイドで安全にコードを実行する目的でよく使われる言語。長い歴史を持っており、比較的高速に動作する。
当時は画期的だった「バーチャルマシン」や「ガベージコレクション」という機構を備え、CやC++でよく問題になるメモリの解放忘れというバグを生まず、
サーバサイドなどで何千時間と動作するソフトウェアに適した言語として受け入れられた。
必然的にエンタープライズ用途で利用されることが多く、各種ツールなども豊富。人海戦術がしやすい言語という側面も出てきた。
一方でブラウザにHello Worldを出すだけでも大変な労力を必要とするので、スタートアップなどではあまり使われない。
ガラケーのアプリや（ちょっと違うが）Androidなど、クライアントサイドでも使われることがある。
プログラミング言語で最初にJavaを覚えるという人は結構多いが、仕事としてJavaを使うのは大抵SI系の業務になり、なかなか辛い労働を強いられる可能性が高い。
クライアントサイドで安全にコードを実行する目的でよく使われる言語。こちらも比較的高速に動作する。
元々はWindowsのクライアント用の言語であり、Javaとは違ってクライアント向きのAPIが多数ある。
マイクロソフトが開発した言語ということもあり、マイクロソフトの優れた開発環境が利用出来るので開発効率は非常に高い。
Unityなどでも利用可能であるが、基本的にはクライアントの実行形式ファイルを生成する目的が大きく、サーバサイドではあまり使われない。
自作のゲーム開発をしたいのであればうってつけの言語。初めて覚える言語としても十分に良いだろうが、C#を使う仕事は近年無くなりつつある。
ほぼ全てのLinux系ディストリビューションに含まれており、ツールや様々な用途で使われていた。
上に紹介したC、C++、Java、C#のようなコンパイル言語とは違い、（少し語弊はあるが）1行ずつ実行してエラーがあれば止まるスクリプト言語である。
ちょっと開発してすぐに実行ということが出来るのと、コマンドラインでワンラインのコードを読み込ませてちょっとした処理が出来るなど応用範囲の広い言語である。
20年近く前にWebでCGIが普及した時には、ほぼどのようなサーバ環境でも実行可能だったこともあり、Perlを使うことが極めて多かった。
しかし、主に読みづらい言語仕様のせいで、近年新規ではほとんど使われなくなった。既存のコードもどんどん別の言語に置き換えられていることが多い。
日本の大手Web企業の一部が使っているので、そこに就職するために覚えるのもアリっちゃアリだけど、今からPerlをわざわざ覚えるのは強くオススメしない。
後発のスプリクト言語。こちらもほぼ全てのLinux系ディストリビューションに含まれており、それゆえに広く使われている。
インデントまで言語仕様で規定することで、誰が書いても読みやすいコードになるように考えられている言語である。
Perlの代わりに使われることが増えていて、周辺ツールなども充実しており、小規模から大規模までカバーする勢いがある。
ただ、Python2とPython3のバージョン間での非互換性があまり綺麗に設計されていなかったため、そこで混乱を招いていたこともあった。
最近だとマシンラーニング系のライブラリでPythonが使われていたり、海外ではPerlに代わる言語として受け入れられつつある。
Web開発に特化したスクリプト言語。CGIの代わりに使われ始め、一世を風靡した。
以前CGIでWebに何かを表示するには比較的大変な労力を割かなければいけなかったのが、PHPを使うと誰でも即座にWeb開発が出来たので爆発的に普及した。
またphp.netの豊富なドキュメント＆スニペットのおかげもあり、開発初期の効率が大変に良い言語である。
残念なことに、言語やAPIの設計がいけていない点が多く、一部の人からは蛇蝎の如く嫌われている。
今でも根強い人気があり、海外でも小規模プロジェクトの最初の開発にPHPを選ぶのは比較的よくある選択肢であるようだ。
Webアプリを開発をしたいという明確な目的を持つ人が、最初に学ぶ言語としてPHPを選ぶのは理にかなっていると思う。
なおこの言語を本気でディスってる人は大体視野の狭いエンジニアであることが多いので、地雷エンジニアを見分けるのにも役立つ。
綺麗なスクリプト言語。日本発で世界的に普及している数少ないIT技術の一つ。
言語仕様が美しく、それゆえにファンが多い。Ruby on RailsというWeb用フレームワークの登場で、Webアプリでの採用例も一気に増えている。
基本的には他のスクリプト言語と同じくサーバサイドでのプログラミングに用いられることがほとんどである。
スクリプト言語で何かを作成するのであれば、Rubyを選んでおけばそう失敗することはない万能言語。
サーバサイドで何かすることに興味を持っているならば、最初に覚える言語としてはとてもオススメ出来る。
一方で、なぜかRubyが採用するWeb側のフレームワーク（具体的にはprototype.jsやCoffeeScript）はいつもクソなので、そちらは深入りしないのが吉。
ブラウザで動くスプリクト言語。ブラウザ戦争が勃発していた18年前、奇跡のようなめぐり合わせでベンダー間の合意が取れ実装された言語。
言語としてはプロトタイプベースのオブジェクト指向という少しめずらしい形式を取っているが、実際にはあまりその特徴は利用されていない。
言語仕様がイマイチで、大変バグを生みやすい言語であり、また関数のスタックが深くなる特性もあり、あまり積極的に使うべき言語ではないが
ブラウザで動く言語が現在これしかないので、大きなシェアを持っている。
一部の物好きがサーバサイドでこの言語を使おうと（主にnode.jsで）四苦八苦している（とはいえ、1つの言語でWebとサーバが完結するのは大きなメリットだ）。
ブラウザで動く唯一の言語のくせにとにかく書くのが面倒ということもあり、多数のAltJSと呼ばれるJavaScriptに変換される別言語を生み出されている。
まあJavaScript本体人が手で書く言語ではない…というのがECMAScript5までの印象だったが、新しい規格が順次導入されており、今後に期待。
Web業界で生きていくならば、好むと好まざるとにかかわらず覚えなければいけない言語である。
最初に覚える言語としては、ブラウザ上でゲームなども作れるし、node.jsでサーバサイドもできるしで、意外とオススメだったりする。
C、C++やJavaと同じでコンパイル言語。サーバサイドで高速かつ安定なバイナリを出力することを目的とされ設計されたGoogle発の言語。
その目的においてはかなり高性能を誇るので、特に速度を要求されるサーバサイドでのプロジェクトでは導入が進んでいる。
それ以外の目的ではあまりこの言語を採用するメリットはないが、ニッチな用途をピンポイントで抑えており、これから広く利用されることも期待される。
コミュニティも活発であり、初めて言語を覚える人が参入すれば喜ばれるだろう。言語としても美しい言語なので、サーバ系のプログラムに興味があればオススメである。
繰り返しだけれど、それぞれの言語ごとに特徴があり、特徴のない言語は廃れていく。
ここに挙げた言語は何らかの特徴があり、何らかの用途で必要なので生き残っている。
その背景を知った上で、ここにある言語は全部ある程度読み書きが出来るようになると素晴らしいと思う。
**誰かみんなの主張のまとめを作ってくれないですか？** (まあそれこそお前がやれよって話かもしれないので、誰もやってくれなかったら私がしますが。。)
最近、JQueryはもはや不要でReactさえあればOK,みたいな記事をよく見ますね。
論旨としては、どうせトランスパイラ使ってるんだからもっと便利な書き方しようぜ！ってことなんだと思います。(virtual DOMがメインだ！という話もあったけど、じゃあ何でReactなの？というのは聞きたいかな。メジャーだから？)
ちなみに私は昔coffeeとbackbone.jsか何かで業務用のページ（SPAではなかったような気がする）を作るお仕事をしたことがありますが、フロントエンドエンジニアというわけではないです。どちらかというとサーバー管理とかのほうがよく知っていると思いますが、Javascriptもそれなりには書くくらいの感じの人です。Reactは不幸にして一度も触ったことがないので、以下の文章はすべてコードサンプルをみたうえでの感想です。
まずこれ。正直そんなにたくさん動的にがりがり書き換えているページをあんまり見ない気がするんですよね。その上正直そういうウェブページ、あったとしても大体使いづらいです。
世の中のページが全部FBならいいのかもしれませんが、具体的にはどんなところで使ってるんでしょう。業務ページとかですか？あと、なぜSPAにしなければいけないのかもよくわからないです。画面遷移するのだめなの？という感じで。
トランスコンパイラを使うのって、結局「将来的には全部ES6になるのだから、今のうちからES6で書いておけば将来のメンテナンスコストとかも減ってうれしいよね！」っていうことなんだと思います。
こういう例、JS以外にもいろいろあって、例えばboost、Androidのsupport library, Pythonのfrom __future__ importなどなどあると思うんですが、どれもやっぱり将来的なコストを見据えて、非標準のライブラリ・記法を使いましょう、ってことですよね。
でもJSXってそういうのじゃないじゃないですか。いわばsupport libraryを使うのとmonoで全部書くのと、位の違いがあるように見えます（そこまでは違わないかｗ）。そういう考察を一切入れずに、「どうせトランスパイラ使ってるんだから拡張記法使っちゃおうぜ！！」っていうのはかなり危ういように見えます。
そもそも、JSって結構独特な言語ですよね。もちろん今はnode.jsとかあるわけですけど、まあやっぱりスクリプト言語の標準の座ってPythonやRubyですよ。世の大多数の人はそっちのが使いやすいとおもってるんでしょう。ということでそもそもトランスパイラ通すんだったらもっと普通の言語から変えるようなソフトウェアが流行ってもいいんじゃないかなあとか思いますけど、そういうのがないのも謎です。dartとかどうなってるんですかね。(まtypescriptとか一種それだという話もあるか)
五年、十年あとにReact.jsって流行ってるんでしょうか。例えば五年前はcoffee scriptが結構流行ってましたけど、たしかもうサポート打ち切りとかになっちゃったんですよね。もちろん営利企業がバックなので、そこまで急になくなるかはわからないですけど、五年したらみんなまた別のライブラリがすごい！！みたいに言ってるんじゃないでしょうか。
まあだからこれはフロントエンドエンジニア業界全体の問題なのかもしれませんが、そういう将来的な保守コストをどう考えているのかが気になります。特にもし業務ページであるなら、せいぜいがなるべく枯れたライブラリ（≒JQuery）と、テンプレートエンジンあるいはフォーマットストリングでも使ってpure ES6で書いたほうがいいんじゃないでしょうか。そうすると結局SPAにはしないですよね。
まあこれを突き詰めるとじゃあetaxもactivexで、銀行のシステムはcobolで、マシンはpc98で、、、とかなっちゃうかもしれないんで、難しいところではあるとは思いますが、、、
とりあえずこんなところで、有識者の皆さんよろしくお願いします。
React.jsでした。angularと混ざりました。。あと特に喧嘩売ってるつもりとかは全くないですがそう見えたらごめんね。
id:murishinai 主張は単純で、せいぜいES6+トランスコンパイラ(+JQuery)とかでいいんじゃね、遷移はサーバー側でやったほうが楽じゃない？という感じです。
id:wordi virtual domが最大のメリット、ってのはよく見る意見ですね。例えば実際どんな場面で（どのくらいの規模のプログラムで）domの改変コストが効いてくるのか、みたいな実例を教えてくださると助かります。（もちろんFBとかはそうでしょうけど、もっとなんだろう、身近な例でお願いしたいです。）なんかReactががりがり（かつユーザー目線から見て有効的に）使われている例がイメージ出来ないのが問題な気がしてきました。
id:logic ええっと、それはそうなんですけど、なんだろう。標準のもので、少なくとも今後10年はあるだろうと言うもの(たとえばES6+フォーマットストリング)があるのにも関わらず、今後5年持つかもわからないライブラリを全面に押し出すの、ちょっと怖く見えるなあという気持ちです。
id:erukiti 具体的に頭の悪い点をご教授くださるとたいへんありがたいです。小規模だとそもそもvirtual domのメリットもなさそうですし、ES6標準でええんちゃうのんという気がしてならないのですが。
id:manaten もちろんFBやGMailをJQueryだけで作るのは不可能だと思います。だからFBはReactを、GはAngularを作ったのでしょうが、逆にそんなに気軽に使うようなものにも思えないのですよね。それこそ何百ブクマも付くのやべえなあ、と。（ところで私にはReactよりAngularJSのほうがずっと気持ちよく見えます）
SPAが使いづらいってのは言いすぎかな。正確には、「ページ遷移型のUIに比べて、SPAであることのメリットが明らかに生きているページって少なくないですか？」ということです。もちろんFBとかGとかtwとかは例外だと思いますけど、DOMを1000個とか10000個とかいじくり回しているページばっかあるようには思えない。もちろんどーーしてもSPAじゃなきゃダメなんだっていうならこの手のライブラリを使うといいとは思うんですが、どっちかというとニッチな需要じゃないでしょうか。
あとなんか保守点検に関する意識がちょっと違うのかなっていうコメントが散見されたんですけど、うーん、一発書いて書きっぱなしっていう案件そんなにあるんですかね？ちょっとそこがよくわかんないです。一度書いてもやっぱりn年先、さらにもっと言えば自分がその職場からいなくなった後のことまで考えてプログラム書くべきだと思うんです。そうすると、例えば数年後のプログラマにとってのReactは今のprototype.jsになってるかもしれない。そういうリスクが怖いです。勉強すればいいじゃんっていう意見もそうなんですが、なんでしょう、どちらかと言うと保守を気にしているので、そっちじゃないです。まあ幸いにして私は人の書いたJSをいじくり回した経験はないので、ただの推測なんですが。
それともしかしたら「枯れた技術」あるは「標準化」という意識があんまりないのかなとも思いました。まあ確かに「Webの世界は日進月歩！」ってことなのかもしれないんですが…。別のページのブコメとか見ても、「枯れた技術を使う」=「不勉強」みたいなのがあって、不思議です。。
あとcoffeeのころ、っていうコメントありましたが、あの頃はみんな夢がありましたよね。AltJSが世界を救う！みたいな。翻って今はどうか。それを思うと、やっぱり何でもかんでもReactじゃ、という意見には違和感を感じるんですよ。
増田に書いたのは単にみんなが見てくれるというだけの理由です。そもそも今諸般の事情でお仕事としてのエンジニアはしていないですし。ほんとに純粋な質問だと思ってもらえればうれしいです。
まあ長くなってきたので私のブログにまとめ直してもいいのですけど。
そういえばモバイルという話も出ていましたが、先日のandroid instant appsって、アレ「HTMLでモバイル向けに軽快なリッチUI作るの無理だからやめような」ってことかと思ったんですが、どうでしょうか。もちろん今現在は必要ですけど～。
Action Script は 3 からかなりしっかりしたクラスベースの OO だよ。
JS も馬鹿みたいな使い方しないでちゃんとしたスタイルで使えば OO だし、全てがハッシュというオブジェクトだし、関数もオブジェクトだしその辺わからないと JS をつかっててもコピペプログラミングに終始して面白くないから結局 OO 理解しないといけない。prototype.js や jQuery やの中身とか読んで理解できるくらいになるには。
Perl だって悪しき過去の遺産が残ってるから OO じゃないイメージが一部にあるけど、モダンな Perl は OO だよ。CPAN にあがってるまともなモジュールは殆ど OO スタイルだし、もっとモダンなスタイルの環境でもいける。モダン Perl や Moose あたりで検索してみるといい。今からやるなら OO しかないけど、初心者は昔のうんこを踏みがちだよね。JS も同じ事が言えるけど。
JS や Perl というゆるい LL は OO を理解していなくても一応使えるってだけで、それじゃマスターには程遠い。あと言語仕様でやっちゃいけないことを縛っていないから、しっかりした開発をやるには 規約もしっかりしないといけない。 初心者は最初からいい出会いをするわけじゃないから、誤解が多いのかもしれない。
JS と Perl はレガシースタイルが残ってる例としてあげたけど、LL でも Python や Ruby はもともと OO スタイルしかない。だから、自分でやってることを理解してないと過去のうんこを踏む可能性のあるゆるい LL よりは、どうやっても綺麗にしかかけない Python は初心者向けだと思う。知り合いが何でも良いからプログラミングやってみたいと言い出したら GAE で Python 弄らせる。
ぶっちゃけ LL でもいまどき OO を避けて通るなんて無理。
プログラミングスキルは、本質的には言語に依存しない。 (よほど糞な言語を使うのでなければだが) OO への理解やアルゴリズムの理解ってのは LL か巨大な言語かに依存しない。絵を描くのに道具によって慣れの差はあっても画力は道具を変えても持ち越せる共通した力だというのに似ている。一つの言語をちゃんとある程度マスターすれば、他の言語の習得はとても早い。たとえ最初にやる言語が LL でもね。別の言語をやるときに壁になるのは関数型かそうでないかくらいのパラダイムの差がある場合だけど、JS や Perl でさえ 関数型で使うようなテクニック を実装できるし使いどころがあるから、やっぱり共通点はあって、～だから～を学ばなくていい、なんてのは上達したいなら殆どない気がする。
時間と予算がある初期開発では作られるが、あとあとの予算がなかったり急だったりしたときに入るメンテナンスで変更が入って、ドキュメントが置いて行かれるってのはよくある話。
だったらそれは最初に書かれた話とは全く関係の無い話じゃん。
最初に確りと「１０年もつものを」って作っても、後続が文書保守の予算をケチれば劣化するんだから。
オープンソースでも同じだよ。１０年の間にプロジェクトが閉じるかもしれない。
途中のバージョンからドキュメントが雑になったりスカスカになったりするかもしれない。
自分の業務に必要なトコに限ってね。
指示だよ指示、作業指示。コメントじゃない。
後輩が実装しちまってから設計にコメントしてもしょうがないでしょうよ。
僕は貴方の後輩では無いので、甘える余地も義理も権利も無いけれど。
それだけでもう「違うんじゃないか!?」って気がしてならない。
仕事の仕方っていうのは、学校じゃなくて職場に有るものだろう。
まぁOpenSSL並みの物を調べられないで云々という趣旨自体は解る。
元増田の後輩が実際に持ってきたものが、それくらい有名なものなんだね？
だったら指示が悪かったのかもね。
「OpenSSLを使え、と一言言えば済むのに、この仕様書の厚さ・・・
これは俺に作れと言っているな？」みたいにね。
なまじ作れるだけにそういう勘違いをする。
OpenSSLが使えない職場っていうのは具体的に思いつかないけど、
うちはprototype.jsが使えないので、
「無料かつ安定したライブラリだけど使えない」というのは珍しい話じゃない。
無論この場合、後輩は後輩で「これは俺に作れと言っているな？」と勝手に解釈せずに、上司に確認に行くべきだよ。
でも、１から１０まで都度、再確認に来られても先輩は仕事にならない。
しかも作っちまう能力はある。そうすると、ある程度は察するのもコミュニケーションの内。
手を動かす前に教えたら良いじゃんって話。
完全に一致を作るための勉強法
コメントもたくさん頂いてまして、それにお答えするのに「ブログでもつくろうかいな」とのぼせましたが、そんなテーマで続くわけもないので、やはりアノニマスダイアリーにしました。
【製作期間について】
まず、皆さん仕事しながらたった4ヶ月で！と褒めて頂いてますが、たったじゃないですよ。4ヶ月って。
仕事が終わって、毎日2～3時間。土日関係無くやると、多分300時間くらいになります。
専門学校の2年間の授業時間がこのくらいだったりするんじゃないですかね。結構長いです。
【モチベーションの維持について】
モチベーションを保つのがすごいというのも褒めてもらいましたが、私は一回やり始めると、意外に長く続きます。
コツがあるんです。
毎年、日々の単純作業が続かない新入社員が入ってきますが、そんな新人に言います。
「息をするように続けるんだよ。」
毎日やるんです。土日関係無く。毎日。
前回の日記で「勉強した」と何度も使ってしまった為、誤解をされている方が多くいらっしゃいます。
正確には、「調べ」ました。
職業柄「調べる」という事が多い為、WEBサービスを作るという事に関してはそれが訳に立ちました。
追記でも書いているのですが今回のシステムはほとんどが、先人達が作った既存のシステムがベースになっています。
ぱくりと言われてしまえばそれまでなんですけど、丸ごとはやってないですよ。というか、丸ごと合うモノがなくて、いろんな所からソースコードを拝借させてもらいました。
なので、中身はぐちゃぐちゃです。けど、検索システムはそれでも200行くらいしかありません。クローラーは80行くらいでしょうか。
【HTMLについて】
というか、それすら途中で挫折してAdobe社のDreamWeaverというソフトを使いました。
適当に書けばソースは綺麗にしてくれるし、CSSの体裁はプロパティを設定しながら見た目のまま調整すれば良いし、一番助かったのはテンプレート機能でした。
最初は全部のHTMLファイルをコピーしながら作っていたのですが、ヘルプを見るとテンプレートとライブラリという機能があるのをしってライブラリがいまいち分らなかったのでテンプレートを使いました。
■Dreamweaver便利
■テンプレート便利
【Javascriptとの出会い】
最初に本やで立ち読みした本に、「プログラムをやってみよう」ということでJavascriptの事が書いてありました。
なので、自然とプログラムの最初のさわりがコレになっただけなんですね。
でも、アラートを出したりとかばっかりで、面白くありませんでした。
インターネット黎明期からのネットユーザーなのですが、「最近よく見るページが移動しないのにページの中身が切り替わるやつかっこいいよな」と思って「ページ遷移しない 読み込み」で検索をすると、Ajaxという文字を見つけ、「ajax 入門」で検索してトップに出たサイトでAjaxの概要だけ調べて、「ajax 簡単」でprototype.jsとjQueryの文字を見つけて「ああ、jQueryってよく見るな」というのがjQueryとの出会いでした。
「最近よく見るページが移動しないのにページの中身が切り替わるやつ」は、非同期通信という名前でした。
jQueryを使うと、下記のように1行コピペするだけで外部のHTMLを読み込む事ができました。
--------------------------------------------------------------------------
var http = $.get("abc.html",null, function(data) {$("#main").html(data);});
--------------------------------------------------------------------------
すごい簡単。最初は意味は分りませんでしたが、目的の事ができればそれで良いので次に進みました。
■jQueryすごい
■非同期通信かっこいい
【Perlとの出会い】
jQueryがちょこっと書くとダイナミックに色々変わってくれるので、日々いろんなプラグインを探して遊んでいました。
でも、作りたかったのは検索システムだったのを思い出し、また近くの大きな本屋に。
検索するパソコンで”プログラム 検索”で探しだした棚に行くと、「CGI/Perl」の本棚でした。
大量にありすぎてどれをかって良いか分らなかったので、いくつか立ち読みして家に帰り、「CGI/Perl 入門」で検索すると
このページにたどり着きました。
Windowsだった為、ActivePerlを入れていくつかプログラムをやりましたが、これがまた面白くないんですね。
すごい地味で。このPerlをさわった最初の1日は正直かなり苦痛でした。
その後、”AV女優の検索システムって不動産の検索システムに似てるな”って思って「CGI/Perl 不動産検索 無料」で検索したら、http://www.yumemaboroshi.net/ってサイトが引っかかって、ここのおかげでかなり進みました。
先人が作った大量のプログラムがダウンロード出来るサイトなんですね。
【PHPとの出会い】
いくつもダウンロードしては、サンプルと中身を見てを繰り返してたら、Perl/CGI以外にPHPがたくさんありました。
どう違うのかと思い検索したら、PHPはすごい叩かれてて、Perlがえらいみたいに書いてあったのですが、叩かれてる理由がいまいち理解できませんでした。
結果PHPを使う事になったのですが、その大きな理由は、DreamweaverでPHPが開ける。なおかつHTMLファイルをそのまま使うテンプレート機能のプラグインがあったという事でした。
PHPでテンプレートを使うには、Smartyというプラグインを使えば良いということが分って、「Smarty 入門」で調べて、いくつかのタグを覚えました。
実際にSmartyで使ったタグは、{$変数}と{if}{/if}と{foreach}{/foreach}の3つだけだと思います。
色々高機能らしいのですが、まあ目的は達成できたのでいいか。と。
PHPの検索プログラムは、HTMLファイルでボタンを押すと、テキストファイルに書いてある内容を、表示してくれる簡単なものを作って、そこに肉付けしました。
（最終的にテキストファイルがSQLサーバーになりましたが。）
■PHPはDreamweaverと相性がいい
■Smartyでやると見た目が壊れない
【Rubyとの出会い】
簡単にPHPで動くプログラムが出来たので、実際に女優のデータを登録しようと思い、DMMに行きました。
DMMのサイトを見ていると、いったい何人いるんだってくらいAV女優が登録されています。
数人集めてみて「こりゃぁ。無理だな。」と途方にくれて1日を過ごしました（笑）
次の日、「ホームページ 自動 巡回 プログラム」とかで検索して、ボットとクローラーという存在を知りました。
自動巡回で拾ってくるのは、どちらかというとクローラーと呼ばれるそうで、「クローラー 作り方」で調べたホームページに、Perl+LWPモジュールで似たことができるということで、とりあえずペタペタとソースを貼ってうごかしてみたら、まあなんと簡単に取れました。
しかし、取ってきた後に気がついたのが、HTMLファイルをそのまま取ってきても結局手動でコピペの必要があり、あんまり意味がない。と。
で、もう少し調べると、「WWW::Mechanize」を使うといいよって書いてあって、Mechanizeで調べたサイトをみるとrubyを使ったサイトが出てきました。
rubyのサンプルがすっごい短くてわかりやすかったので、Perlは苦痛だったのでRubyにしようと、このときRubyを始めました。
■Rubyきれい
■Mechanize簡単
【デザインは・・・】
はてなブックマークのコメントで、DoCoMoのサイトが元ネタと書いてありましたが、ハズレです。
デザイナーの友人が居て世間話でどうやって作るの？って聞いたら、「まあ、パｋ、じゃない。参考にするよ。他社のを。」っていうもんでどうやって見つけるか聞いたら、あるんですね、綺麗なデザイン集めたサイトが。http://www.ikesai.com/ここでたくさん見ました。
それから、スライダーのインターフェースは、「selectToUISlider」jQueryのプラグインそのまま使ってます。
■世の中のデザイン全てぱｋ（略
■selectToUISliderかっこいい
という感じで、ほんとにちょっとずつ進みました。
楽しかったですね。Perl以外は。なんであんなに読みづらいんでしょう。
と、またもや長くなりすぎたのでこの辺で。
DMMのクリックが10万クリックほどあり、その結果、購入された金額が、なんと！
報酬額が245円。
----------------------
今回のサーバーダウンは結構深刻でなかなか復旧が出来ていません。。。
申し訳ないです。
----------------------
http://twitter.com/#!/kanzen21_com
----------------------
ショックだね。超高速道路というか、そういう以前の問題だよこれは。
やろうとすることを普通の人が身につけるのに３年は掛かるだろうに、しかも、ここまでのクオリティはでない。
唸ってしまう。
回避できるのであれば使うHTMLやCSSは限られる。覚えるのは最小限。
Dreamweaverつこーてるのかな？
ツールが解決してくれるのならコードを書く必要すらない。
jQueryでやられていることを自前実装するには技術力が必要。
中で何をやっているかなんて詳しく知る必要などない。
世界中のもっと詳しい人がチェックをいれてくれている。jQueryを利用したライブラリやサンプルコードも転がっている。jQueryでできないことがでてきたらどうするか？ prototype.jsでも使えばいいじゃない。
扱いがかわいそう。
自分に必要がないもの、目的に合致するのに遠回りなものを切り捨てる能力がないと何時まで経っても勉強だけして終わる。
PHPで何かしようとしたのではなく、単なるテンプレートエンジンとして割りきって利用したようだ。
表示したいところに表示させたいものを埋め込むだけなら、それはHTMLとほぼ同等の何かでしかなくなる。
どの言語でやっても一緒なら、できるだけ自分がつくる部分が少ないほうがよい。
phpではクローラーをつくるのにいいライブラリがあるというのを聞いたことがない。
RubyならPerlみたいな正規表現に悩まされることもない。なるほど。
素人がRuby環境を例えばLinux上に構築しようとしたらかなり躓くところがあると思う。Railsを使わずにRubyで済ませたというところか。ここらへんから何か恐ろしい。
逆算するとクローラーをつくるまで学習を初めてから２ヶ月も掛かっていないことになる。
クローラーをつくってからApacheを知ったというのがリアルで笑えるのだけど、恐ろしい。
Ruby環境とPHP環境をどうやって同居させたのかとかそういう苦労が見えない。ということ苦労しなかったのかもしれない。やはりRailsではなくてRubyなのか。
技術者を名乗る人でもRubyの環境構築ができない人も多いのにこの人は素直にすごい。
何もないところからLinux環境にPHPやらmySQLやらRubyやらの環境構築は熟練した人でも半日かかるめんどくさい作業なのでそれをやれてしまうというところで、３年生ぐらいのエンジニアスキルがあると俺は認める。
それは言い直すと普通に仕事として身につけたとしても一般的には３年はかかるということだ。
はてさて、SQLまでかけるようになったというのだろうか。
DB設計は？ 確かにこの内容であれば設計を要するほどの複雑さはない。１テーブルで十分。
インデックスとか貼ってないだろうなとは思わせるが、5GBのデータでもこれだけのレスポンスが出てしまう時代だ。
チューニングするぐらならいいハードにのっけなよということか。
デザイナーとしても食っていけるだけのスキルがあるんじゃなかろうかとおもってしまう。
もう、なんていうか調査能力もすごい。
というか調査能力がすごいんだろうな。
超横だけど、世の中をわかっているようで、単にＳＥの毒に犯されてるだけでしょ、あんた。
プログラムだったらプログラマがいて、言語がある、そのスタイルは絶対に変わらない。どこかのサイトの試験用スクリプトを読んだところでGoogle Earthが組める？
無理無理。絶対的なプログラムへの深い知識が必要でしょ。prototype.jsのソース読み込んで、いつどこで何が動くかキッチリ理解してなきゃ無理。
そして何より、JavaScriptを完全にマスターしてる人がみんな有名企業のスペシャルなプログラマになって、貴方の数倍の年収を得ているのは事実だ。
（X）HTMLとCSSは浪人の間の一年でだいたい覚えた俺が通りますよｗ
で、それを覚えたらとりあえずJavascriptを覚えよう。
モダンなライブラリ（prototype.jsとかjQueryとか）使えるようになるといいかな。
このあたりはネット上に入門ごろごろのっかっているし、本屋行けば入門書あるだろう。
??????????Webプログラマコース??????????
Perl、PHP、Ruby、Pythonのどれかをせめて覚えるべきかな？
後のことを考えるとPerlがいちばんかな？他のやつのほうが習いやすいみたいだけど
どれか一つ覚えれば他のはお互いに参考になっているから覚えやすいかも。
入門書一冊フルコンプすればとりあえず使えるんじゃね（ぇ
あ、Java忘れてた。これも手だけど初心者はきつくね と思ってスルー（ぁ
上のどれか覚えたならやってもいいとおもう。
ここらへん職業訓練で教えてくれるみたいだからそれで習うのもいいかも。
??????????Webデザイナコース??????????
このあたりがいるらしい。だいたい放送大学でいける（配色とか確かあったはず）から、↑の職業訓練と平行でいくといいかも。
配色とかのは資格もあるから、とるといいかも。
というかこっちも職業訓練でたしかあったと思った。
まぁ、まだJavascript覚えていないんで俺はそこからだけどなorz
やっぱりprototype.jsのClass.create？
使った事無いけどスーパークラスのメソッド呼び出しできるんだっけ？
http://iandeth.dyndns.org/mt/ian/archives/000664.html
とか参考に自分で書いたら段々でかくなって、4行が今57行w
やっぱ言語のサポートないと辛いわ。こんなに大変だと思わなかった。
って事で「javascriptの継承方法の決め手」なーい？と聞いてみる。
欲しいのは、多重継承が可能で、オーバーライドした子クラスのメソッドから、簡単にオーバーライドされてる親クラスのメソッド呼びたい。ただし、thisは子クラスのオブジェクトのままで、しかも何段でもチェーンをたどれるように。
それとも、あきらめて、クラス名付きで直接親メソッド呼んだ方が良いのかな。やっぱり。
ま。とりあえずシュミグラマだから趣味に走ってみるけれども。
<script language="javascript" type="text/javascript" src="/static/js/prototype.js?1191207813"></script>
<script language="javascript" type="text/javascript" src="/static/js/swfobject.js?1186571328"></script>
<script language="javascript" type="text/javascript" src="/static/js/video.js?1188959159"></script>
<script language="javascript" type="text/javascript" src="/static/js/youtube.js?1186571328"></script>
<script language="javascript" type="text/javascript" src="/static/js/prototype.js?1191207813"></script>
<script language="javascript" type="text/javascript" src="/static/js/Jemplate.js?1186571328"></script>
<script language="javascript" type="text/javascript" src="/static/js/json.js?1186571328"></script>
<script language="javascript" type="text/javascript" src="/static/js/decolink/decolink.js?1191207813"></script>
<script language="javascript" type="text/javascript" src="/static/js/prototype.js?1191207813"></script>
<script language="javascript" type="text/javascript" src="/static/js/effects.js?1186571328"></script>
<script language="javascript" type="text/javascript" src="/static/js/windowstate.js?1186571328"></script>
<script language="javascript" type="text/javascript" src="/static/js/overlay.js?1186571328"></script>
<script language="javascript" type="text/javascript" src="/static/js/popup.js?1186571328"></script>
<script language="javascript" type="text/javascript" src="/static/js/emoji_palette_base.js?1191207813"></script>
<script language="javascript" type="text/javascript" src="/static/js/emoji_palette_1.js?1188367218"></script>
<script language="javascript" type="text/javascript" src="/static/js/mixi.js?1191207813"></script>
<script language="javascript" type="text/javascript" src="/static/js/prototype.js?1191207813"></script>
<script language="javascript" type="text/javascript" src="/static/js/mixi/util.js?1191207813"></script>
<script language="javascript" type="text/javascript" src="/static/js/mixi/form.js?1191207813"></script>
<script language="javascript" type="text/javascript" src="/static/js/mixi/searchbox.js?1191207813"></script>
<script language="javascript" type="text/javascript" src="/static/js/mixi/navigation.js?1191207813"></script>
http://anond.hatelabo.jp/20070411180408の人へ
Javascriptの言語仕様を読めば、語句があって構文があって構造化やらオブジェクトやら関数やらなんやらの作り方がわかる。
私もそれについては何の問題もなかった。少々、特徴はあるけれど、さほど困惑するほどのものではなかった。
ただ、それから先で、はたと困惑するんだよね。やりたいことをどう作っていけば良いのかわからない。それ、よくわかる。
Javascript(正確にはちょっと違うのだけれど)の特異な点は、こちらがJavascriptの枠組みで何か設計する前に、すでに互いに関連しあったインスタンスがある、または他の枠組み(HTMLやらXMLやら)でインスタンスを生成したあと、Javascriptで操作する、って所なんだ。
他の言語は、I/OやI/Fを設計して、それをその言語で作って操作して、という手順になるんだよね。プログラミングはそのI/OやI/Fを作ることから始まることが多い。
しかし、Javascriptはその部分のほとんどをインスタンスとしてブラウザが作った後に動く。すでに形になっているインスタンス群がある状態で動く。そして、プロトタイプ言語だから、インスタンスを作る際に他のインスタンスを使用する事が多い。
つまり、すでに出来ているインスタンス群の状態を知る、つまりDOMを知って、実際にどんなインスタンスが出来ているのか、どんなインスタンスを作ればよいのか、を知る必要がありました。
以上、prototype.jsも満足に使えないへぼい奴からの言葉です。
と、書きながら書籍を読まずに覚える人です。
今更１から勉強するのもなんなので、prototype.js使用を前提にしちゃっていいと思う。
で、まずはそのラベルをクリックしてテキストボックスに変化させて、入力、Enterでラベルに戻す処理を作ってみたらどうだろう。
ちっちゃいサンプルをいっぱい作るのが覚えるコツ。
後は、どうやってその挙動になってるのか、先人の魔法使いっぷりを考えまくろう。
いや、仕様は大体本読めば分かるんだよ。
全部がオブジェクトで実は中身はハッシュだとか、プロトタイプベースのオブジェクト指向だとかそう言うのは。
ただ、具体的にプロダクトにこう言う機能を実現させたい！って時に何をやればいいのかさっぱりイメージが浮かんでこない。
例えば、ちょっとテーブルで表を作ってどこかのカラムをクリックしたら入力フォームになってデータ入力出来る様にしたい、とかでも何から手をつけていいやら。
結局色んなライブラリを探してその説明通りちょこちょこ流用できる時以外は、あうあうあうああーーで全然ナニやれば良いのか頭が働かない。
DOMの操作が分からないってだけなのかなぁ？
phpとかでXML文書をパースして色んな処理、とかは特に躓かなかったんだけど。
AJAXとかprototype.jsとかMochiKitとか色んな技術を使おうとワケワカメになってるのもあるのかも。
昔から地道にwindowオブジェクトをチョコチョコ弄って、とかのjavascriptを書いてきた経験が無いから。
【コラム】そろそろきっちりJavaScript 第1回 "Firebug"の導入〜関数リテラルとは? (MYCOMジャーナル)
多彩な演出効果をカンタンに導入できる事で脚光を浴びたprototype.jsの登場を皮切りに
のっけから間違ってて読む気なくす。冒頭くらいちゃんと調べて書こうよ。prototype.jsのどこを読めば多彩な演出効果なんて出てくるんだ。使ったことないだろ。多彩な演出効果はたぶんprototype.jsベースのScript.aculo.usのことだ。prototype.jsが流行ったのはいろいろあるけど、主としてAjax.*の存在が大きい。
function mtof(x) { return x*3.2808399 }
mtof(3)
;書こうよ。そりゃなくても動くけど、初学者向けの解説としてはダメだろう。タイトルも「きっちり」なんだし、Rubyで;ないのとは意味が違う。思わぬところでハマったりするよたぶん試したことないけど。
ちなみに仕様的には、「セミコロンを補完可能なら補完する」なので、補完不可なら補完できずエラー、そもそも補完ってことはセミコロンついてるのが正規の状態って意味だろう。何にしろ;なしで改行してるの見ると気持ち悪い。
取り上げるのは下の3つ。便宜的に上からapng、alphafilter、ie6pngとする。
IT戦記 - 僕も半透明 png を使うためのライブラリ作った！
アルファ画像を扱うalphafilter.jsライブラリ-とあるWEBクリエイターのblog
ウノウラボ Unoh Labs: IE6でアルファチャンネルを含むPNGを表示する
特になし。ごめんなさい。
new AlphaChanneledPNG("imageId1","/blank.gif").show();
new AlphaChanneledPNG("imageId2","/blank.gif").show();
...
Google Maps以前のころ。ヘビーユーザーのあいだではJavascriptオフが常識になっていた。度重なる時計の再発明に業を煮やし、IEのActiveXに警戒心を抱き、不安定なOSをさらに不安定にするため暗躍するのがJavascriptでありJScriptだった。
Google Mapsがあれだけのインパクトを与えたのは、ひとえに、こういった先入観を打ち砕いたからに尽きる。信じられないことに、Javascriptって便利なのだ。実に見事な枯れた技術の水平思考である。
Ajaxという言葉が帰納され、ライブラリがぼこぼこと発表される。ネイティブオブジェクトの拡張と、クロスブラウザのための供物ラッパー集合体たるprototype.jsを筆頭に、様々なものが世に出、様々なアプリケーションがより手軽に実装できるようになった。
script.aculo.usやLightBoxやmoo.fxといった、エフェクト中心のライブラリも出回り始める。IEのせいで煩雑な記述を強要されたグラフィックアーティストが、DOM操作によって問題を解決しようとし始めた。リンクにmouseoverしたらうっとうしいエフェクトを振りまくスクリプトが当たり前のように設けられた。このはてなも、いつの間にか大量のMochikit/*.jsを読み込んでページのレンダリングを遅らせている（たまにad.hatena.ne.jpのレスポンスが遅いときなど目も当てられない）。これらに共通することは、多くの人がそれを望んでいないということだ。
もちろん好ましい方向への進化もあった。OperaがUser Javascriptを発案・実装し、FirefoxもGreasemonkeyでそれに追随。SafariもCreammonkeyを得て、いわゆるモダンブラウザユーザーは、豊かなスクリプトライフを楽しめるようになった（IEにもなんとかいう同様の機構を実現する環境はあるが、IEユーザーには敷居が高いのかほとんど見かけない）。Livedoor ReaderやGoogle Readerはイベントを操作することで、キーボードでの操作を今までにないほど豊穣にした。入力フォームのリアルタイムバリデーション、Google AnalyticsやAdsenseの導入容易さなど、見るべき意匠もいくつかある。
しかし平均的に考えて、何の変哲もない個人ブログにJavascriptは必要ないものだ。素人がつくったタイマーは、いつもユーザーを憂鬱にする。素人がつくったAjaxサイトは、だいたいの場合IEとFirefox以外を排除するもっともらしい理由を得るためにAjaxを使う（Dellが自社サイト上で「Netscape4.6以上で閲覧せよ」と警告することによって、やる気のなさを主張するようなものだ）。
我々が自分のブラウザ上でページを表示するとき、Javascriptによる意外な効果などまったく期待していない。UIにおいては最速こそ正義、というmala氏の言葉を引用するまでもなく、不必要に重いサイトはそれだけで忌避するに足る理由となる。流行を追って常識を忘れるのは愚かとしか言いようがない。
Firefox(のNoScriptアドオン)とOperaは、ページごとサイトごとにきめ細かなJavascriptの挙動を設定できる（不勉強にしてSafariについては知らない。IEはできない）。Javascriptに限らず、広告ブロックや不要ファイルの無視、特定Flashの再生可否など、ユーザーは「何が要らないか」を指定でき、要らないものを気軽に突っぱねられるようになった。不要なものを除去する習慣が、ヘビーユーザーのあいだで間違いなく形成されつつあるのだ。
何かひとつのことをするためのJavascriptは、これからしばらく出現し続けるだろう。ウェブマスターが、重厚長大な飾りで貧弱なコンテンツを隠すためだけに。何かを拒絶するテクノロジーは、今後しばらく発展し続けるだろう。十重二十重のラッピングに疲れた人たちのために。