「Prototype.js」を含む日記 RSS

はてなキーワード: Prototype.jsとは

2023-12-17

年末大掃除

jQueryとかPrototype.jsとかサイ本とか捨てたるわー。

これでフロントエンドエンジニアだった過去におさらばだ!

かにCSSの本とかオライリーの本とかも捨ててやる。

「行けっ!アクシズ!忌まわしい記憶と共にっ…!」のときシャアの心境、わっかるわぁ

なお、React系は電子書籍で眠っている模様。

2019-03-15

JavaScriptがあればなんでもできる?

つのまにか○○.jsかいうやつが、すごい沢山あるらしい。適当検索しただけで、これくらいでてきた。

JavaScriptが使える」というエンジニアはこれらの違いくらいは把握しているのか。大変そう。

ちなみに、どれが一番強いんだろう?

2017-08-08

Webフロントエンド業界への素朴な疑問

なんか最近Webフロントエンド界隈でイキっている人良く見るけど、そもそもどのくらいの経験で語ってるんだろ。

感覚的には、10年前はすっごいしょぼいJavaScriptばっかだったし、それで要件を満たせてたと思うんだけど。

複雑な要件ときは、JavaAppletとか使ってたような。

ちょっと昔を振り返ってみると、

5年前はJSFがすっごいイケてるように思ってたな。今は完全に終わってるけどね。

10年前は、これからprototype.js じゃなくてjQueryだ!と思ってた時代かな?

15年前は、IE Onlyです!で全然許されてた

20年前は、JavaScriptは、ブラウザステータスバーに文字を表示したり、マウスの動きに合わせて星をキラキラさせるのに使ってたかな。

ぶっちゃけ今でも、本質サーバーサイドであって、フロントエンドなんてノリで作っとけば、と思っている

2016-11-14

http://anond.hatelabo.jp/20161114194700

jQueryスクリプトは$.(...)ではなく$j.(...)やjQuery.(...)で書く(prototype.jsとの競合を避けるため)

2016-07-06

コンピュータ言語言語ごとの特徴を俺が教えてやる(異論は認める

コンピュータ言語って世の中に山ほどあるけれど、それぞれの言語ごとに特徴がある(特徴のない言語は廃れていく)。

まり言語に詳しくない人相手に、俺の考えるそれぞれの言語の特徴を書いてみようと思う。

なお、取り上げるのはある程度広く使われている言語に限りたいと思う。

TL;DR

言語概要
C言語高速動作するバイナリ生成を目的としたコンパイル言語。だいたいどんな環境でも使えるがバグやす
C++マニアック言語、高速、習得大変
Javaサーバで高速かつ安定に動作するコンパイル言語、大規模でよく使われる
C#主にWindowsクライアント用のバイナリ生成に使われるコンパイル言語
Perl広く使われていたが今は若干時代遅れのスプリクト言語。汚い
PythonPerlにかわって主流になりつつあるスクリプト言語。綺麗
PHPWeb開発にフォーカスされたスクリプト言語一世を風靡した。
Rubyとても綺麗なスクリプト言語
JavaScriptブラウザで実行出来る唯一の言語言語自体はいまいちだが、ブラウザ事情需要あり
Goサーバサイドで安全かつ高速動作するバイナリ生成を目的としたコンパイル言語

詳細

C言語

メモリに直接アクセスして書き換えるといったコンピュータ機械語に近い言語構文を持つため、高速な処理が可能言語

コンパイラ歴史も古く環境も整っており、組み込み系などを含むほぼ全ての環境で利用可能な万能言語

一方で、メモリの確保や解放といった基本的なことも自前で処理する必要があるため、コーディング効率が良くなく、多種多様バグを生みやすい側面も持つ。

ある程度以上のエンジニアであれば常識として知っておきたい言語だが、初めて覚える言語としてはあまり適当ではない。

C++

C言語オブジェクト指向を導入した言語C++言語とはあまり呼ばれず、しーぷらすぷらす、もしくは略してしーぷらぷら、しーたすたす、などと呼ばれる。

C言語の速度を維持したままオブジェクト指向テンプレートなどの効率的記述可能にしようとした意気は真っ当だったのだが、

当時最先端だった色々な技術思想を叩き込んだおかげで、あり得ないほど複雑化した言語としても有名。

C++理解しています」という人はほぼ初級者で、本当に理解していくほど「C++には自信がありません」となっていく。

速度を追求する分野では良く使われている。完全に理解するのは難しいとしても、テンプレートくらいまでは理解しておくと仕事上なんとかなる…かもしれない。

Java

サーバサイドで安全コードを実行する目的でよく使われる言語。長い歴史を持っており、比較的高速に動作する。

当時は画期的だった「バーチャルマシン」や「ガベージコレクション」という機構を備え、CやC++でよく問題になるメモリ解放忘れというバグを生まず、

サーバサイドなどで何千時間動作するソフトウェアに適した言語として受け入れられた。

必然的エンタープライズ用途で利用されることが多く、各種ツールなども豊富人海戦術がしやす言語という側面も出てきた。

一方でブラウザHello Worldを出すだけでも大変な労力を必要とするので、スタートアップなどではあまり使われない。

ガラケーアプリや(ちょっと違うが)Androidなど、クライアントサイドでも使われることがある。

プログラミング言語最初Javaを覚えるという人は結構多いが、仕事としてJavaを使うのは大抵SI系の業務になり、なかなか辛い労働を強いられる可能性が高い。

C#

クライアントサイドで安全コードを実行する目的でよく使われる言語。こちらも比較的高速に動作する。

元々はWindowsクライアント用の言語であり、Javaとは違ってクライアント向きのAPIが多数ある。

マイクロソフトが開発した言語ということもあり、マイクロソフトの優れた開発環境が利用出来るので開発効率は非常に高い。

Unityなどでも利用可能であるが、基本的にはクライアントの実行形式ファイルを生成する目的が大きく、サーバサイドではあまり使われない。

自作ゲーム開発をしたいのであればうってつけの言語。初めて覚える言語としても十分に良いだろうが、C#を使う仕事は近年無くなりつつある。

Perl

ほぼ全てのLinuxディストリビューションに含まれており、ツールや様々な用途で使われていた。

上に紹介したC、C++JavaC#のようなコンパイル言語とは違い、(少し語弊はあるが)1行ずつ実行してエラーがあれば止まるスクリプト言語である

ちょっと開発してすぐに実行ということが出来るのと、コマンドラインでワンラインコードを読み込ませてちょっとした処理が出来るなど応用範囲の広い言語である

20年近く前にWebCGIが普及した時には、ほぼどのようなサーバ環境でも実行可能だったこともあり、Perlを使うことが極めて多かった。

しかし、主に読みづらい言語仕様のせいで、近年新規ではほとんど使われなくなった。既存コードもどんどん別の言語に置き換えられていることが多い。

日本大手Web企業の一部が使っているので、そこに就職するために覚えるのもアリっちゃアリだけど、今からPerlをわざわざ覚えるのは強くオススメしない。

Python

後発のスプリクト言語。こちらもほぼ全てのLinuxディストリビューションに含まれており、それゆえに広く使われている。

インデントまで言語仕様規定することで、誰が書いても読みやすコードになるように考えられている言語である

Perlの代わりに使われることが増えていて、周辺ツールなども充実しており、小規模から大規模までカバーする勢いがある。

ただ、Python2とPython3のバージョン間での非互換性があまり綺麗に設計されていなかったため、そこで混乱を招いていたこともあった。

最近だとマシンラーニング系のライブラリPythonが使われていたり、海外ではPerlに代わる言語として受け入れられつつある。

最初に覚える言語としては良い選択肢だろう。

PHP

Web開発に特化したスクリプト言語CGIの代わりに使われ始め、一世を風靡した。

以前CGIWebに何かを表示するには比較的大変な労力を割かなければいけなかったのが、PHPを使うと誰でも即座にWeb開発が出来たので爆発的に普及した。

またphp.net豊富ドキュメントスニペットのおかげもあり、開発初期の効率が大変に良い言語である

残念なことに、言語API設計がいけていない点が多く、一部の人から蛇蝎の如く嫌われている。

今でも根強い人気があり、海外でも小規模プロジェクト最初の開発にPHPを選ぶのは比較的よくある選択肢であるようだ。

Webアプリを開発をしたいという明確な目的を持つ人が、最初に学ぶ言語としてPHPを選ぶのは理にかなっていると思う。

なおこの言語を本気でディスってる人は大体視野の狭いエンジニアであることが多いので、地雷エンジニアを見分けるのにも役立つ。

Ruby

綺麗なスクリプト言語日本発で世界的に普及している数少ないIT技術の一つ。

言語仕様が美しく、それゆえにファンが多い。Ruby on RailsというWebフレームワークの登場で、Webアプリでの採用例も一気に増えている。

基本的には他のスクリプト言語と同じくサーバサイドでのプログラミングに用いられることがほとんどである

スクリプト言語で何かを作成するのであれば、Rubyを選んでおけばそう失敗することはない万能言語

サーバサイドで何かすることに興味を持っているならば、最初に覚える言語としてはとてもオススメ出来る。

一方で、なぜかRuby採用するWeb側のフレームワーク(具体的にはprototype.jsCoffeeScriptはいつもクソなので、そちらは深入りしないのが吉。

JavaScript

ブラウザで動くスプリクト言語ブラウザ戦争が勃発していた18年前、奇跡のようなめぐり合わせでベンダー間の合意が取れ実装された言語

言語としてはプロトタイプベースオブジェクト指向という少しめずらしい形式を取っているが、実際にはあまりその特徴は利用されていない。

言語仕様イマイチで、大変バグを生みやす言語であり、また関数スタックが深くなる特性もあり、あまり積極的に使うべき言語ではないが

ブラウザで動く言語現在これしかないので、大きなシェアを持っている。

一部の物好きがサーバサイドでこの言語を使おうと(主にnode.jsで)四苦八苦している(とはいえ、1つの言語Webサーバが完結するのは大きなメリットだ)。

ブラウザで動く唯一の言語のくせにとにかく書くのが面倒ということもあり、多数のAltJSと呼ばれるJavaScriptに変換される別言語を生み出されている。

まあJavaScript本体人が手で書く言語ではない…というのがECMAScript5までの印象だったが、新しい規格が順次導入されており、今後に期待。

Web業界で生きていくならば、好むと好まざるとにかかわらず覚えなければいけない言語である

最初に覚える言語としては、ブラウザ上でゲームなども作れるし、node.jsサーバサイドもできるしで、意外とオススメだったりする。

GO

C、C++Javaと同じでコンパイル言語サーバサイドで高速かつ安定なバイナリを出力することを目的とされ設計されたGoogle発の言語

その目的においてはかなり高性能を誇るので、特に速度を要求されるサーバサイドでのプロジェクトでは導入が進んでいる。

それ以外の目的ではあまりこの言語採用するメリットはないが、ニッチ用途ピンポイントで抑えており、これから広く利用されることも期待される。

コミュニティも活発であり、初めて言語を覚える人が参入すれば喜ばれるだろう。言語としても美しい言語なので、サーバ系のプログラムに興味があればオススメである

まとめ

繰り返しだけれど、それぞれの言語ごとに特徴があり、特徴のない言語は廃れていく。

ここに挙げた言語は何らかの特徴があり、何らかの用途必要なので生き残っている。

その背景を知った上で、ここにある言語は全部ある程度読み書きが出来るようになると素晴らしいと思う。

2016-05-21

React.js界隈の人に聞きたい

**誰かみんなの主張のまとめを作ってくれないですか?** (まあそれこそお前がやれよって話かもしれないので、誰もやってくれなかったら私がしますが。。)

最近JQueryはもはや不要でReactさえあればOK,みたいな記事をよく見ますね。

論旨としては、どうせトランスパイラ使ってるんだからもっと便利な書き方しようぜ!ってことなんだと思います。(virtual DOMがメインだ!という話もあったけど、じゃあ何でReactなの?というのは聞きたいかな。メジャーから?)

ただちょっと個人的違和感が拭えないので聞きたいです。

ちなみに私は昔coffeeとbackbone.jsか何かで業務用のページ(SPAではなかったような気がする)を作るお仕事をしたことがありますが、フロントエンドエンジニアというわけではないです。どちらかというとサーバー管理とかのほうがよく知っていると思いますが、Javascriptもそれなりには書くくらいの感じの人です。Reactは不幸にして一度も触ったことがないので、以下の文章はすべてコードサンプルをみたうえでの感想です。

そもそも世の中にそんなにSPAがあるのか

まずこれ。正直そんなにたくさん動的にがりがり書き換えているページをあんまり見ない気がするんですよね。その上正直そういうウェブページ、あったとしても大体使いづらいです。

世の中のページが全部FBならいいのかもしれませんが、具体的にはどんなところで使ってるんでしょう。業務ページとかですか?あと、なぜSPAにしなければいけないのかもよくわからないです。画面遷移するのだめなの?という感じで。

JSXを使うことに抵抗ないんですか?

トランスコンパイラを使うのって、結局「将来的には全部ES6になるのだから、今のうちからES6で書いておけば将来のメンテナンスコストとかも減ってうれしいよね!」っていうことなんだと思います

こういう例、JS以外にもいろいろあって、例えばboostAndroidのsupport library, Pythonのfrom __future__ importなどなどあると思うんですが、どれもやっぱり将来的なコストを見据えて、非標準のライブラリ記法を使いましょう、ってことですよね。

でもJSXってそういうのじゃないじゃないですか。いわばsupport libraryを使うのとmonoで全部書くのと、位の違いがあるように見えます(そこまでは違わないかw)。そういう考察を一切入れずに、「どうせトランスパイラ使ってるんだから拡張記法使っちゃおうぜ!!」っていうのはかなり危ういように見えます

そもそも、JSって結構独特な言語ですよね。もちろん今はnode.jsとかあるわけですけど、まあやっぱりスクリプト言語の標準の座ってPythonRubyですよ。世の大多数の人はそっちのが使いやすいとおもってるんでしょう。ということでそもそもトランスパイラ通すんだったらもっと普通言語から変えるようなソフトウェア流行ってもいいんじゃないかなあとか思いますけど、そういうのがないのも謎です。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 もちろんFBGMailJQueryだけで作るのは不可能だと思います。だからFBはReactを、GはAngularを作ったのでしょうが、逆にそんなに気軽に使うようなものにも思えないのですよね。それこそ何百ブクマも付くのやべえなあ、と。(ところで私にはReactよりAngularJSのほうがずっと気持ちよく見えます

トランスパイラですねごめんなさいw

SPAが使いづらいってのは言いすぎかな。正確には、「ページ遷移型のUIに比べて、SPAであることのメリットが明らかに生きているページって少なくないですか?」ということです。もちろんFBとかGとかtwとかは例外だと思いますけど、DOM1000個とか10000個とかいじくり回しているページばっかあるようには思えない。もちろんどーーしてもSPAじゃなきゃダメなんだっていうならこの手のライブラリを使うといいとは思うんですが、どっちかというとニッチ需要じゃないでしょうか。

あとなんか保守点検に関する意識ちょっと違うのかなっていうコメント散見されたんですけど、うーん、一発書いて書きっぱなしっていう案件そんなにあるんですかね?ちょっとそこがよくわかんないです。一度書いてもやっぱりn年先、さらもっと言えば自分がその職場からいなくなった後のことまで考えてプログラム書くべきだと思うんです。そうすると、例えば数年後のプログラマにとってのReactは今のprototype.jsになってるかもしれない。そういうリスクが怖いです。勉強すればいいじゃんっていう意見もそうなんですが、なんでしょう、どちらかと言うと保守を気にしているので、そっちじゃないです。まあ幸いにして私は人の書いたJSをいじくり回した経験はないので、ただの推測なんですが。

それともしかしたら「枯れた技術」あるは「標準化」という意識あんまりないのかなとも思いました。まあ確かに「Web世界日進月歩!」ってことなのかもしれないんですが…。別のページのブコメとか見ても、「枯れた技術を使う」=「不勉強」みたいなのがあって、不思議です。。

あとcoffeeのころ、っていうコメントありましたが、あの頃はみんな夢がありましたよね。AltJS世界を救う!みたいな。翻って今はどうか。それを思うと、やっぱり何でもかんでもReactじゃ、という意見には違和感を感じるんですよ。

増田に書いたのは単にみんなが見てくれるというだけの理由です。そもそも今諸般の事情お仕事としてのエンジニアはしていないですし。ほんとに純粋質問だと思ってもらえればうれしいです。

まあ長くなってきたので私のブログにまとめ直してもいいのですけど。

そういえばモバイルという話も出ていましたが、先日のandroid instant appsって、アレ「HTMLモバイル向けに軽快なリッチUI作るの無理だからやめような」ってことかと思ったんですが、どうでしょうか。もちろん今現在必要ですけど~。

2011-10-17

http://anond.hatelabo.jp/20111017173201

Action Script は 3 からかなりしっかりしたクラスベースの OO だよ。

JS馬鹿みたいな使い方しないでちゃんとしたスタイルで使えば OO だし、全てがハッシュというオブジェクトだし、関数オブジェクトだしその辺わからないと JS をつかっててもコピペプログラミングに終始して面白くないから結局 OO 理解しないといけない。prototype.jsjQuery やの中身とか読んで理解できるくらいになるには。

Perl だって悪しき過去の遺産が残ってるから OO じゃないイメージが一部にあるけど、モダンPerl は OO だよ。CPAN にあがってるまともなモジュール殆ど OO スタイルだし、もっとモダンスタイル環境でもいける。モダン PerlMoose あたりで検索してみるといい。今からやるなら OO しかないけど、初心者は昔のうんこを踏みがちだよね。JS も同じ事が言えるけど。

JSPerl というゆるい LL は OO を理解していなくても一応使えるってだけで、それじゃマスターには程遠い。あと言語仕様でやっちゃいけないことを縛っていないから、しっかりした開発をやるには 規約もしっかりしないといけない。 初心者最初からいい出会いをするわけじゃないから、誤解が多いのかもしれない。

JSPerlレガシースタイルが残ってる例としてあげたけど、LL でも PythonRuby はもともと OO スタイルしかない。だから自分でやってることを理解してないと過去うんこを踏む可能性のあるゆるい LL よりは、どうやっても綺麗にしかかけない Python初心者向けだと思う。知り合いが何でも良いかプログラミングやってみたいと言い出したら GAEPython 弄らせる。

ぶっちゃけ LL でもいまどき OO を避けて通るなんて無理。

プログラミングスキルは、本質的には言語依存しない。 (よほど糞な言語を使うのでなければだが) OO への理解やアルゴリズムの理解ってのは LL か巨大な言語かに依存しない。絵を描くのに道具によって慣れの差はあっても画力は道具を変えても持ち越せる共通した力だというのに似ている。一つの言語をちゃんとある程度マスターすれば、他の言語の習得はとても早い。たとえ最初にやる言語LL でもね。別の言語をやるときに壁になるのは関数型かそうでないかくらいのパラダイムの差がある場合だけど、JSPerl でさえ 関数型で使うようなテクニック を実装できるし使いどころがあるから、やっぱり共通点はあって、~だから~を学ばなくていい、なんてのは上達したいなら殆どない気がする。

2011-01-24

http://anond.hatelabo.jp/20110123224124

時間予算がある初期開発では作られるが、あとあとの予算がなかったり急だったりしたときに入るメンテナンスで変更が入って、ドキュメントが置いて行かれるってのはよくある話。

だったらそれは最初に書かれた話とは全く関係の無い話じゃん。

最初に確りと「10年もつものを」って作っても、後続が文書保守予算ケチれば劣化するんだから

オープンソースでも同じだよ。10年の間にプロジェクトが閉じるかもしれない。

途中のバージョンからドキュメントが雑になったりスカスカになったりするかもしれない。

自分の業務に必要なトコに限ってね。

 

まぁ、だからコメントしたわけだが・・・コメントしたことに突っ込んどいて、コメントすること言われても、スゲー困る。

指示だよ指示、作業指示。コメントじゃない。

後輩が実装しちまってから設計コメントしてもしょうがないでしょうよ。

 

また、甘えないでしいんだけど、大学卒業していれば(以下略)

僕は貴方の後輩では無いので、甘える余地も義理権利も無いけれど。

大学勉強たい仕事をやれって表現は、

それだけでもう「違うんじゃないか!?」って気がしてならない。

仕事の仕方っていうのは、学校じゃなくて職場に有るものだろう。

 

まぁOpenSSL並みの物を調べられないで云々という趣旨自体は解る。

元増田の後輩が実際に持ってきたものが、それくらい有名なものなんだね?

だったら指示が悪かったのかもね。

「OpenSSLを使え、と一言言えば済むのに、この仕様書の厚さ・・・

これは俺に作れと言っているな?」みたいにね。

なまじ作れるだけにそういう勘違いをする。

OpenSSLが使えない職場っていうのは具体的に思いつかないけど、

うちはprototype.jsが使えないので、

無料かつ安定したライブラリだけど使えない」というのは珍しい話じゃない。

無論この場合、後輩は後輩で「これは俺に作れと言っているな?」と勝手解釈せずに、上司に確認に行くべきだよ。

でも、1から10まで都度、再確認に来られても先輩は仕事にならない。

しかも作っちまう能力はある。そうすると、ある程度は察するのもコミュニケーションの内。

これは事故たいな側面もある。

 

うん、だから教育コストを掛けて、実地させて、繰り返し、実例で教えているわけだが・・・何が不満なの?

コストをかけるタイミング

手を動かす前にしてほしい事、知っていてほしい事は、

手を動かす前に教えたら良いじゃんって話。

2010-12-06

http://anond.hatelabo.jp/20101203150748

完全に一致を作るための勉強法

たくさんのアクセスありがとうございました

コメントもたくさん頂いてまして、それにお答えするのに「ブログでもつくろうかいな」とのぼせましたが、そんなテーマで続くわけもないので、やはりアノニマスダイアリーしました





製作期間について】

まず、皆さん仕事しながらたった4ヶ月で!と褒めて頂いてますが、たったじゃないですよ。4ヶ月って。

仕事が終わって、毎日2~3時間。土日関係無くやると、多分300時間くらいになります

専門学校の2年間の授業時間がこのくらいだったりするんじゃないですかね。結構長いです。


モチベーションの維持について】

モチベーションを保つのがすごいというのも褒めてもらいましたが、私は一回やり始めると、意外に長く続きます

コツがあるんです

毎年、日々の単純作業が続かない新入社員が入ってきますが、そんな新人に言います。

「息をするように続けるんだよ。」

毎日やるんです。土日関係無く。毎日。


勉強したという言葉の誤り】

前回の日記で「勉強した」と何度も使ってしまった為、誤解をされている方が多くいらっしゃいます。

正確には、「調べ」ました

職業柄「調べる」という事が多い為、WEBサービスを作るという事に関してはそれが訳に立ちました

追記でも書いているのですが今回のシステムほとんどが、先人達が作った既存システムベースになっています。

ぱくりと言われてしまえばそれまでなんですけど、丸ごとはやってないですよ。というか、丸ごと合うモノがなくて、いろんな所からソースコードを拝借させてもらいました

なので、中身はぐちゃぐちゃです。けど、検索システムはそれでも200行くらいしかありません。クローラーは80行くらいでしょうか。


HTMLについて】

基本をやったのは、恐らくHTMLCSSだけです

というか、それすら途中で挫折してAdobe社のDreamWeaverというソフトを使いました

適当に書けばソースは綺麗にしてくれるし、CSSの体裁はプロパティを設定しながら見た目のまま調整すれば良いし、一番助かったのはテンプレート機能でした

最初は全部のHTMLファイルコピーしながら作っていたのですが、ヘルプを見るとテンプレートライブラリという機能があるのをしってライブラリいまいち分らなかったのでテンプレートを使いました

Dreamweaver便利

テンプレート便利


Javascriptとの出会い】

最初に本やで立ち読みした本に、「プログラムをやってみよう」ということでJavascriptの事が書いてありました

なので、自然プログラム最初さわりがコレになっただけなんですね。

でも、アラートを出したりとかばっかりで、面白くありませんでした

インターネット黎明期からのネットユーザーなのですが、「最近よく見るページが移動しないのにページの中身が切り替わるやつかっこいいよな」と思って「ページ遷移しない 読み込み」で検索をすると、Ajaxという文字を見つけ、「ajax 入門」で検索してトップに出たサイトAjaxの概要だけ調べて、「ajax 簡単」でprototype.jsjQueryの文字を見つけて「ああ、jQueryってよく見るな」というのがjQueryとの出会いでした

最近よく見るページが移動しないのにページの中身が切り替わるやつ」は、非同期通信という名前した

jQueryを使うと、下記のように1行コピペするだけで外部のHTMLを読み込む事ができました

--------------------------------------------------------------------------

var http = $.get("abc.html",null, function(data) {$("#main").html(data);});

--------------------------------------------------------------------------

すごい簡単。最初意味は分りませんでしたが、目的の事ができればそれで良いので次に進みました

jQueryすごい

■非同期通信かっこいい

プラグインいっぱいあって楽しい


Perlとの出会い】

jQueryがちょこっと書くとダイナミックに色々変わってくれるので、日々いろんなプラグインを探して遊んでいました

でも、作りたかったのは検索システムだったのを思い出し、また近くの大きな本屋に。

検索するパソコンで”プログラム 検索”で探しだした棚に行くと、「CGI/Perl」の本棚した

大量にありすぎてどれをかって良いか分らなかったので、いくつか立ち読みして家に帰り、「CGI/Perl 入門」で検索すると

http://www.kent-web.com/perl/

このページにたどり着きました

Windowsだった為、ActivePerlを入れていくつかプログラムをやりましたが、これがまた面白くないんですね。

すごい地味で。このPerlをさわった最初の1日は正直かなり苦痛した

その後、”AV女優検索システムって不動産検索システムに似てるな”って思って「CGI/Perl 不動産検索 無料」で検索したら、http://www.yumemaboroshi.net/ってサイトが引っかかって、ここのおかげでかなり進みました

先人が作った大量のプログラムダウンロード出来るサイトなんですね。

Perl面白くない

フリーソフトを集めたサイトソースがいっぱい見れる


PHPとの出会い】

いくつもダウンロードしては、サンプルと中身を見てを繰り返してたら、Perl/CGI以外にPHPがたくさんありました

どう違うのかと思い検索したら、PHPはすごい叩かれてて、Perlがえらいみたいに書いてあったのですが、叩かれてる理由がいまいち理解できませんでした

結果PHPを使う事になったのですが、その大きな理由は、DreamweaverPHPが開ける。なおかつHTMLファイルをそのまま使うテンプレート機能のプラグインがあったという事でした

PHPテンプレートを使うには、Smartyというプラグインを使えば良いということが分って、「Smarty 入門」で調べて、いくつかのタグを覚えました

実際にSmartyで使ったタグは、{$変数}と{if}{/if}と{foreach}{/foreach}の3つだけだと思います。

色々高機能らしいですが、まあ目的は達成できたのでいいか。と。

PHP検索プログラムは、HTMLファイルボタンを押すと、テキストファイルに書いてある内容を、表示してくれる簡単なものを作って、そこに肉付けしました

(最終的にテキストファイルSQLサーバーになりましたが。)


PHPDreamweaverと相性がいい

Smartyでやると見た目が壊れない


Rubyとの出会い】

簡単にPHPで動くプログラムが出来たので、実際に女優データを登録しようと思い、DMMに行きました

DMMサイトを見ていると、いったい何人いるんだってくらいAV女優が登録されています。

数人集めてみて「こりゃぁ。無理だな。」と途方にくれて1日を過ごしました(笑)

次の日、「ホームページ 自動 巡回 プログラム」とかで検索して、ボットクローラーという存在を知りました

自動巡回で拾ってくるのは、どちらかというとクローラーと呼ばれるそうで、「クローラー 作り方」で調べたホームページに、Perl+LWPモジュールで似たことができるということで、とりあえずペタペタとソースを貼ってうごかしてみたら、まあなんと簡単に取れました

しかし、取ってきた後に気がついたのが、HTMLファイルをそのまま取ってきても結局手動でコピペの必要があり、あんまり意味がない。と。

で、もう少し調べると、「WWW::Mechanize」を使うといいよって書いてあって、Mechanizeで調べたサイトをみるとrubyを使ったサイトが出てきました

rubyのサンプルがすっごい短くてわかりやすかったので、Perl苦痛だったのでRubyにしようと、このときRubyを始めました

設定が大変だったんですが、まあ面白くないので割愛。


Rubyきれい

■Mechanize簡単


デザインは・・・】

はてなブックマークコメントで、DoCoMoサイト元ネタと書いてありましたが、ハズレです

デザイナーの友人が居て世間話でどうやって作るの?って聞いたら、「まあ、パk、じゃない。参考にするよ。他社のを。」っていうもんでどうやって見つけるか聞いたら、あるんですね、綺麗なデザイン集めたサイトが。http://www.ikesai.com/ここでたくさん見ました

それからスライダーインターフェースは、「selectToUISlider」jQueryプラグインそのまま使ってます


■世の中のデザイン全てぱk(略

■selectToUISliderかっこいい


という感じで、ほんとにちょっとずつ進みました

しかったですね。Perl以外は。なんであんなに読みづらいんでしょう。


と、またもや長くなりすぎたのでこの辺で。





あ、ちなみに、アクセス数収益をご報告します。

金、土、日、月と約4日間爆発的にアクセスを頂きました

アクセス数は、4日間で約200アクセスほどありました

DMMクリック10クリックほどあり、その結果、購入された金額が、なんと!









700円でした

報酬額が245円。

ありがとうございました

http://www.kanzen21.com/


----------------------

12/8 12:00追記

アクセス過多でまたもやサーバーがダウンしました

今回のサーバーダウンは結構深刻でなかなか復旧が出来ていません。。。

申し訳ないです。


----------------------

12/8 12:10追記

全然起動しません。なんなんだこれは。

サーバー会社に問い合わせ中です

状況は、Twitterでお知らせします。

http://twitter.com/#!/kanzen21_com


----------------------

12/8 13:00追記

サーバー復活しました

サーバー会社の方、ありがとうございました

2010-12-04

http://anond.hatelabo.jp/20101203150748

ショックだね。超高速道路というか、そういう以前の問題だよこれは。

やろうとすることを普通の人が身につけるのに3年は掛かるだろうに、しかも、ここまでのクオリティはでない。

唸ってしまう。

HTML+CSS

意図したものを意図したように表示させるのは困難。

だが自分意図で作れる場合は、できないことは回避できる。

回避できるのであれば使うHTMLCSSは限られる。覚えるのは最小限。

Dreamweaverつこーてるのかな?

ツールが解決してくれるのならコードを書く必要すらない。

JavaScript

jQueryでやられていることを自前実装するには技術力が必要。

逆に言うとjQueryが利用できるならそれですむ。

中で何をやっているかなんて詳しく知る必要などない。

世界中のもっと詳しい人がチェックをいれてくれている。jQueryを利用したライブラリやサンプルコードも転がっている。jQueryでできないことがでてきたらどうするか? prototype.jsでも使えばいいじゃない。

ともかく回避方法はいくらでもある。

Perl

扱いがかわいそう。

自分に必要がないもの目的に合致するのに遠回りなものを切り捨てる能力がないと何時まで経っても勉強だけして終わる。

php

PHPで何かしようとしたのではなく、単なるテンプレートエンジンとして割りきって利用したようだ。

表示したいところに表示させたいものを埋め込むだけなら、それはHTMLとほぼ同等の何かでしかなくなる。

LL学習目的はないので寄り道をする必要などない。

クローラー

どの言語でも実装できる。phpを使っていて、なぜRuby

どの言語でやっても一緒なら、できるだけ自分がつくる部分が少ないほうがよい。

phpではクローラーをつくるのにいいライブラリがあるというのを聞いたことがない。

コマンドラインベースで動かす人は皆無だからね。

RubyならPerlたい正規表現に悩まされることもない。なるほど。

素人Ruby環境を例えばLinux上に構築しようとしたらかなり躓くところがあると思う。Railsを使わずにRubyで済ませたというところか。ここらへんから何か恐ろしい

逆算するとクローラーをつくるまで学習を初めてから2ヶ月も掛かっていないことになる。

Apache

クローラーをつくってからApacheを知ったというのがリアルで笑えるのだけど、恐ろしい

Ruby環境PHP環境をどうやって同居させたのかとかそういう苦労が見えない。ということ苦労しなかったのかもしれない。やはりRailsはなくてRubyなのか。

技術者を名乗る人でもRuby環境構築ができない人も多いのにこの人は素直にすごい。

何もないところからLinux環境PHPやらmySQLやらRubyやらの環境構築は熟練した人でも半日かかるめんどくさい作業なのでそれをやれてしまうというところで、3年生ぐらいのエンジニアスキルがあると俺は認める。

それは言い直すと普通に仕事として身につけたとしても一般的には3年はかかるということだ。

MySQL

はてさて、SQLまでかけるようになったというのだろうか。

DB設計は? 確かにこの内容であれば設計を要するほどの複雑さはない。1テーブルで十分。

インデックスとか貼ってないだろうなとは思わせるが、5GBのデータでもこれだけのレスポンスが出てしまう時代だ。

チューニングするぐらならいいハードにのっけなよということか。

デザイン

デザイナーとしても食っていけるだけのスキルがあるんじゃなかろうかとおもってしまう。

GIMPボタンひとつ作るのでもしんどいよ。

Face.com

もう、なんていうか調査能力もすごい。

というか調査能力がすごいんだろうな。

2009-10-01

http://anond.hatelabo.jp/20091001171551

超横だけど、世の中をわかっているようで、単にSEの毒に犯されてるだけでしょ、あんた。

プログラムだったらプログラマがいて、言語がある、そのスタイルは絶対に変わらない。どこかのサイト試験スクリプトを読んだところでGoogle Earthが組める?

無理無理。絶対的なプログラムへの深い知識が必要でしょ。prototype.jsソース読み込んで、いつどこで何が動くかキッチリ理解してなきゃ無理。

そして何より、JavaScriptを完全にマスターしてる人がみんな有名企業スペシャルプログラマになって、貴方の数倍の年収を得ているのは事実だ。

あんたの年収ダンコーガイ年収の何分の1?

2008-09-04

http://anond.hatelabo.jp/20080904150727

(X)HTMLCSS浪人の間の一年でだいたい覚えた俺が通りますよw

で、それを覚えたらとりあえずJavascriptを覚えよう。

モダンライブラリprototype.jsとかjQueryとか)使えるようになるといいかな。

このあたりはネット上に入門ごろごろのっかっているし、本屋行けば入門書あるだろう。

??????????Webプログラマコース??????????

PerlPHPRubyPythonのどれかをせめて覚えるべきかな?

後のことを考えるとPerlがいちばんかな?他のやつのほうが習いやすいみたいだけど

どれか一つ覚えれば他のはお互いに参考になっているから覚えやすいかも。

入門書一冊フルコンプすればとりあえず使えるんじゃね(ぇ

あ、Java忘れてた。これも手だけど初心者はきつくね と思ってスルー(ぁ

上のどれか覚えたならやってもいいとおもう。

ここらへん職業訓練で教えてくれるみたいだからそれで習うのもいいかも。

??????????Webデザイナコース??????????

ウェブデザイナー - Wikipediaより。

配色、色彩心理学レイアウト人間工学

このあたりがいるらしい。だいたい放送大学でいける(配色とか確かあったはず)から、↑の職業訓練と平行でいくといいかも。

配色とかのは資格もあるから、とるといいかも。

というかこっちも職業訓練でたしかあったと思った。

まぁ、まだJavascript覚えていないんで俺はそこからだけどなorz

ちなみにhtmlはez-htmlcssはstylenote使っているな(ぉ

2008-07-02

javascript継承方法の決め手

やっぱりprototype.jsClass.create?

使った事無いけどスーパークラスのメソッド呼び出しできるんだっけ?

http://iandeth.dyndns.org/mt/ian/archives/000664.html

とか参考に自分で書いたら段々でかくなって、4行が今57行w

でもまだバグあり機能不足。絶対車輪の再発明してる。

やっぱ言語サポートないと辛いわ。こんなに大変だと思わなかった。

って事で「javascript継承方法の決め手」なーい?と聞いてみる。

欲しいのは、多重継承が可能で、オーバーイドした子クラスのメソッドから、簡単にオーバーイドされてる親クラスのメソッド呼びたい。ただし、thisは子クラスオブジェクトのままで、しかも何段でもチェーンをたどれるように。

それとも、あきらめて、クラス名付きで直接親メソッド呼んだ方が良いのかな。やっぱり。

ま。とりあえずシュミグラマだから趣味に走ってみるけれども。

2007-10-02

1回でいいよ

mixiのview_diary.plで読み込んでるjs群。

<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>

2007-05-20

[]今日の嫁との会話

俺「こんにちはこんにちは

嫁「はまちちゃんか?」

俺「そういえばはまちちゃんの顔画像が出てる記事があって話題になってたよ」

嫁「まじか!? どこ??」

ちょっとまてよ、お前そんなにはまちや2が気になるのかよ。なんかくやしい。

嫁「テクニカルタームが多すぎて記事の内容がわからん」

俺「prototypeとか?」

嫁「そうそう。それもわからん」

その後prototype.jsDojoJavascript言語仕様について二人で盛り上がった。

2007-04-11

私が躓きかけたjavascriptと他言語の違い

http://anond.hatelabo.jp/20070411180408の人へ

Javascript言語仕様を読めば、語句があって構文があって構造化やらオブジェクトやら関数やらなんやらの作り方がわかる。

私もそれについては何の問題もなかった。少々、特徴はあるけれど、さほど困惑するほどのものではなかった。

ただ、それから先で、はたと困惑するんだよね。やりたいことをどう作っていけば良いのかわからない。それ、よくわかる。

Javascript(正確にはちょっと違うのだけれど)の特異な点は、こちらがJavascriptの枠組みで何か設計する前に、すでに互いに関連しあったインスタンスがある、または他の枠組み(HTMLやらXMLやら)でインスタンスを生成したあとJavascriptで操作する、って所なんだ。

他の言語は、I/OやI/Fを設計して、それをその言語で作って操作して、という手順になるんだよね。プログラミングはそのI/OやI/Fを作ることから始まることが多い。

しかし、Javascriptはその部分ほとんどインスタンスとしてブラウザが作った後に動く。すでに形になっているインスタンス群がある状態で動く。そして、プロトタイプ言語だから、インスタンスを作る際に他のインスタンスを使用する事が多い。

つまり、すでに出来ているインスタンス群の状態を知る、つまりDOMを知って、実際にどんなインスタンスが出来ているのか、どんなインスタンスを作ればよいのか、を知る必要がありました。

以上、prototype.jsも満足に使えないへぼい奴からの言葉です。

おすすめ書籍

と、書きながら書籍を読まずに覚える人です。

今更1から勉強するのもなんなので、prototype.js使用を前提にしちゃっていいと思う。

で、まずはそのラベルクリックしてテキストボックスに変化させて、入力、Enterでラベルに戻す処理を作ってみたらどうだろう。

ちっちゃいサンプルをいっぱい作るのが覚えるコツ。

後は、どうやってその挙動になってるのか、先人の魔法使いっぷりを考えまくろう。

javascriptが分からない

いや、仕様は大体本読めば分かるんだよ。

全部がオブジェクトで実は中身はハッシュだとか、プロトタイプベースオブジェクト指向だとかそう言うのは。

ただ、具体的にプロダクトにこう言う機能を実現させたい!って時に何をやればいいのかさっぱりイメージが浮かんでこない。

例えば、ちょっとテーブルで表を作ってどこかのカラムクリックしたら入力フォームになってデータ入力出来る様にしたい、とかでも何から手をつけていいやら。

結局色んなライブラリを探してその説明通りちょこちょこ流用できる時以外は、あうあうあうああーーで全然ナニやれば良いのか頭が働かない。

DOMの操作が分からないってだけなのかなぁ?

phpとかでXML文書をパースして色んな処理、とかは特に躓かなかったんだけど。

AJAXとかprototype.jsとかMochiKitとか色んな技術を使おうとワケワカメになってるのもあるのかも。

昔から地道にwindowオブジェクトチョコチョコ弄って、とかのjavascriptを書いてきた経験が無いから。

何か良い書籍とか教えてください増田

2007-02-28

【コラム】そろそろきっちり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で;ないのとは意味が違う。思わぬところでハマったりするよたぶん試したことないけど。

ちなみに仕様的には、「セミコロンを補完可能なら補完する」なので、補完不可なら補完できずエラー、そもそも補完ってことはセミコロンついてるのが正規の状態って意味だろう。何にしろ;なしで改行してるの見ると気持ち悪い。

2007-02-23

ウィジェットに夢をみた

なんか凄いね。寝る前になんか作ろうとあれこれ触ってたら5時になってしまった。

これはプラットフォームというか、開発言語だよね。。

Googleが提供しているAPIを誰かが利用してつくったなにがしをYahoo!が配る。

どんな世界だそれ!

でも、面白い。winアプリがこのレベルで作れるならちょっと面白いものがいっぱいつくれそう。

prototypeをつかってるんだけどprototype.jsをつこーてる様子がない。

どこにはいってるんですか>< 教えてください。

ドキュメントからみつけられなかった。

2007-02-06

古いブラウザで透過PNGを表示させるJavascriptの比較検証

取り上げるのは下の3つ。便宜的に上からapng、alphafilter、ie6pngとする。

IT戦記 - 僕も半透明 png を使うためのライブラリ作った!

アルファ画像を扱うalphafilter.jsライブラリ-とあるWEBクリエイターのblog

ウノウラボ Unoh Labs: IE6でアルファチャンネルを含むPNGを表示する

apng

特長
萌えポイント
好みがわかれるところ
  • 対象PNGの直後にscriptロードするだけで使える / 何度もロードしなきゃいけないのが嫌
びみょうなところ
  • imgにwidthとheightを指定しなきゃいけない(詳細不明)
簡単カスタマイズ
  • elmScript.src.replaceのとこをいじって好きなファイル名(/blank.gifとか)に置換する
想定される用途

alphafilter

特長
好みがわかれるところ
  • classを使って処理を適用するかどうか決める / class指定しなきゃいけないのが面倒
  • Event.observeが組み込まれてる
萌えポイント
びみょうなところ
  • prototype.jsが必要
  • どうせEvent.observe使うなら無名関数にしてほしい
  • window.onload時に実行されるので若干ラグ
簡単カスタマイズ
  • 複雑なことはしてない(Event.observeとdocument.getElementsByClassNameだけ)のでprototype.jsレスにするのが容易
  • document.getElementsByClassNameの第二引数を指定できるようにしたり、対象エレメントの配列ダイレクト引数で受け取れるようにしたり
想定される用途
  • 複数PNGに適用したいとき
  • 透過PNGを背景に使いたいとき

ie6png

特長
  • 代替GIFを指定できる
萌えポイント

特になし。ごめんなさい。

びみょうなところ
簡単カスタマイズ
  • AlphaChanneledPNG.initializeのEvent.observeを消して、実行コードを以下のようにして、HTMLの最後に書けばすっきりしていいとおもう
new AlphaChanneledPNG("imageId1","/blank.gif").show();
new AlphaChanneledPNG("imageId2","/blank.gif").show();
...
想定される用途
  • うーん……。

結論

  • 手っ取り早く使うならapng、CSSbackgroundに使うとか、PNGの数が多いならalphafilter
  • jQueryと衝突するのでprototype.jsはカンベンしてください
  • 欲を言えばIE7が出る前に開発してほしかったです

2007-02-01

そろそろまたJavascriptオフの時代が来た

Google Maps以前のころ。ヘビーユーザーのあいだではJavascriptオフ常識になっていた。度重なる時計の再発明に業を煮やし、IEActiveXに警戒心を抱き、不安定なOSをさらに不安定にするため暗躍するのがJavascriptでありJScriptだった。

Google Mapsがあれだけのインパクトを与えたのは、ひとえに、こういった先入観を打ち砕いたからに尽きる。信じられないことに、Javascriptって便利なのだ。実に見事な枯れた技術の水平思考である。

Ajaxという言葉帰納され、ライブラリがぼこぼこと発表される。ネイティブオブジェクト拡張と、クロスブラウザのための供物ラッパー集合体たるprototype.jsを筆頭に、様々なものが世に出、様々なアプリケーションがより手軽に実装できるようになった。

script.aculo.usLightBoxやmoo.fxといった、エフェクト中心のライブラリも出回り始める。IEのせいで煩雑な記述を強要されたグラフィックアーティストが、DOM操作によって問題を解決しようとし始めた。リンクにmouseoverしたらうっとうしいエフェクトを振りまくスクリプトが当たり前のように設けられた。このはてなも、いつの間にか大量のMochikit/*.jsを読み込んでページのレンダリングを遅らせている(たまad.hatena.ne.jpレスポンスが遅いときなど目も当てられない)。これらに共通することは、多くの人がそれを望んでいないということだ。

もちろん好ましい方向への進化もあった。OperaUser Javascriptを発案・実装し、FirefoxGreasemonkeyでそれに追随。SafariCreammonkeyを得て、いわゆるモダンブラウザユーザーは、豊かなスクリプトライフを楽しめるようになった(IEにもなんとかいう同様の機構を実現する環境はあるが、IEユーザーには敷居が高いのかほとんど見かけない)。Livedoor ReaderGoogle Readerイベントを操作することで、キーボードでの操作を今までにないほど豊穣にした。入力フォームのリアルタイムバリデーション、Google AnalyticsAdsenseの導入容易さなど、見るべき意匠もいくつかある。

しかし平均的に考えて、何の変哲もない個人ブログJavascriptは必要ないものだ。素人がつくったタイマーは、いつもユーザー憂鬱にする。素人がつくったAjaxサイトは、だいたいの場合IEFirefox以外を排除するもっともらしい理由を得るためにAjaxを使う(Dellが自社サイト上で「Netscape4.6以上で閲覧せよ」と警告することによって、やる気のなさを主張するようなものだ)。

我々が自分のブラウザ上でページを表示するとき、Javascriptによる意外な効果などまったく期待していない。UIにおいては最速こそ正義、というmala氏の言葉引用するまでもなく、不必要に重いサイトはそれだけで忌避するに足る理由となる。流行を追って常識を忘れるのは愚かとしか言いようがない。

Firefox(のNoScriptアドオン)とOperaは、ページごとサイトごとにきめ細かなJavascriptの挙動を設定できる(不勉強にしてSafariについては知らない。IEはできない)。Javascriptに限らず、広告ブロックや不要ファイルの無視、特定Flashの再生可否など、ユーザーは「何が要らないか」を指定でき、要らないものを気軽に突っぱねられるようになった。不要なものを除去する習慣が、ヘビーユーザーのあいだで間違いなく形成されつつあるのだ。

何かひとつのことをするためのJavascriptは、これからしばらく出現し続けるだろう。ウェブマスターが、重厚長大な飾りで貧弱なコンテンツを隠すためだけに。何かを拒絶するテクノロジーは、今後しばらく発展し続けるだろう。十重二十重のラッピングに疲れた人たちのために。

 
ログイン ユーザー登録
ようこそ ゲスト さん