  |
はてなキーワード: Canvasとは
javascript:(function(){var D=document,G=g(‘oebtnd’),f='postform’,A='setAttribute’,CE='createElement’,CT='createTextNode’,DI='drawImage’,Q='addEventListener’,N=G.parentNode,I='insertBefore’,s='style’,w='width’,h='height’,X=g('ftxa’)[s],T=g('oe3’)[s],Z=1,S=g('oejs’),ct=S.getContext('2d’),ar=[],ind=-1,fl=1,U=undefined,gID='getImageData’,pID='putImageData’;function b(v,q){var e=D[CE]('input’);e[A]('type’,'button’);e[A]('value’,v);e[Q]?e[Q]('click’,q,!1):e.onclick=q;return e}function g(n){return D.getElementById(n)}function ig(x,y){var P=ct[gID](0,0,x,y),Cv2=D[CE]('canvas’),ct2=Cv2.getContext('2d’);ct2[w]=x;ct2[h]=y;ct2[pID](P,0,0);return Cv2}function wZ(z){var oz=Z;Z=Z+z;if(Z<1)Z=1;if(Z>8)Z=8;X[w]=T[w]=(S[w]*Z+46)+'px’;X[h]=T[h]=S[h]*Z+'px’;S[s][w]=S[w]*Z+'px’;S[s][h]=S[h]*Z+'px’;ct.scale(oz/Z,oz/Z)}function MD(e){if(e.button==0){fl=1}}function MU(){if(fl){ar[++ind]=ct[gID](0,0,S[w],S[h]);fl=0;ar[ind+1]=U}}MU();S[Q]('mousedown’,MD,false);D[Q]('mouseup’,MU,false);N[I](D[CE]('div’),G);N[I](b('拡大’,function(){wZ(1)}),G);N[I](D[CE]('div’),G);N[I](b('縮小’,function(){wZ(-1)}),G);N[I](D[CE]('div’),G);N[I](b('UNDO’,function(){if(ind>0){ct[pID](ar[–ind],0,0)}}),G);N[I](D[CE]('div’),G);N[I](b('REDO’,function(){if(ar[ind+1]!=U){ct[pID](ar[++ind],0,0)}}),G)})();
去年の今頃は「今年こそはすごいWebサービス作るぞ！！！！！！！！！！！」って意気込んでたのに
なんかもう今日が最終日。
ということでこの12月頭から何か作ろうと考えていて、丁度年末だからということで作った。
前にAmazonの購入金額合計を出すブックマークレットが流行ったけど、それとほぼ同じ。
Amazonの今までの合計金額と、書籍とかPCとかカテゴリごとの合計金額出してグラフにする。
年末だしTwitterで「2014年のKindle購入金額内訳は...でした」とか投稿すれば
みんなつられてアクセスするはず！宣伝しなくても勝手に大ブーム間違いなし！！！！！！！！
って思ってたけど
投稿してもだれもアクセスしてくれない。待っても待ってもアクセス0。
e？嘘でしょ？？？って思ったら
のはずだったけど今度はrobots.txt見に来るクソbotしかアクセスしてくれない。
虚しさ半端ない。
というかTwitterでURLつぶやくと即効でどこぞやのクローラー巡回してくるんですね。
構成自体はクライアント・サーバサイド共にjs。EC2上でnode.js。
D3.jsのグラフ画像がsvgだからどうにかしてpngにしないとTwitter投稿出来ないのが微妙に面倒だった
投稿時にクライアント側でbase64→canvas→pngにしても良かったけど
商品のカテゴリ取得するためにはProduct Advertising API使うしかなくて
redis上にキャッシュしておいたりwebsocketで適当に進捗伝えたりした。
今回得た経験値としては
あたり。
今年は残念ながら目標不達成だったけど、いい最終日の過ごし方になったと思う。
お疲れ様でした。
開発側です。
IE10 はさほど問題ないんです。IE10 でやっと標準に追い付いてきたという感じ。問題は、IE 使ってるようなユーザーはアップデートしないという事実です。
スクリプトなどの実行の早さは、IE8 位までは数倍のオーダーで遅く、マップ上にたくさんのオブジェクトを表示するようなものを作ると、IE の速度面対応だけで大変でした。
それよりも問題なのが、Web の標準に対応していないことです。
CSS3 や HTML5 への対応は、他のブラウザに比べて数年単位で遅れてました。Chrome か Firefox で開発しているとします。そのままテストすると Chrome Firefox Safari では問題ありません。IE だけ問題が、というのが普通でした。IE 対応だけで工程かかるのです。IE7 や 8 を視野に入れると、諦めざるを得ない技術もあります。たいていは擬似的に対応できるのですが (Canvas にライブラリで対応するなど)、そのために余計な工程がかかるのが問題なのです。ぶっちゃけ IE 切り捨てて、その時間を他に当てたほうがより良いものを安く早く作れるということです。
という感じになるので、IE8 以前を切り捨て OK になるだけで段違いですね。
しかし、最初に言ったように IE ユーザーはアップデートしないんですよ。Chrome Firefox Safari が優れているというより、これらのユーザーはほぼ間違いなく最新版使っているのが一番のアドバンテージなんです。IE10 は IE 史上ではやっと他に並びかけるほどまともな標準対応になったので、IE 使ってる人が全員 IE10 ならこれほどネタにされることもなかったと思います。
開発側はこうした IE によるストレスを日々受けているので、擬人化や IE 死亡のようなネタになると祭りになりやすいのではと思います。
こんにちは。※すごく恥ずかしいことに中身を間違えて投稿したので修正再投稿です。
私は不景気の昨今、株で大失敗した男A（データ分析が生業）です。同じく不景気で会社が倒産した男H（Web開発が生業）と一緒にWebサービスを作りました。
私はお金を、彼は職場を失ったので、生活に困窮し、現在引越しを考えています。けれど、どこに住んだら良いかわからないので、そんなときに必要な地図Webサービスを作りました。私らは事情によりFacebookやれないし、Twitterではフォロワー少ないし、何かのビジネスプランやWebコンテンツのコンテストもほとんどなくなってしまったし、で、どうか匿名ダイアリーの場をお借りさせてください。
距離より大事な時間とお金で地図を変換・新しい地図サービスmaplas【マプラス】
距離で描かれる通常の地図に対して、これは地点間の移動に要する「時間」と「運賃」（電車）で描かれている地図です。
今回は東京の通勤圏（東京から通勤可能そうな約60km圏が対象です）の路線が変形して図示されます。デフォルトでは二人が飲み歩いている町屋近辺を「運賃」の世界で描画しています。クリックしたり検索ボックスから検索するとそこを中心に設定できます。またコントロールで時間、運賃、距離（普通の地図）の切り替えで比較できます。
距離の近い順に 田端、北千住、王子 （同心円の単位はkm）ですが
（移動）時間では早い順に、北千住、田端、王子、（同心円の単位は分）
運賃（移動料金）では安い順に、北千住、田端＝王子、 （同心円の単位は円）
で描画され、地図のようにマクロ的に把握できるようになるサービスです。比較マップで二画面分割の比較もできます。
これで毎日の通勤先に時間や料金でお得な駅、自宅から遊びに行くのに思ったよりお金は時間のかかる駅などがわかります。
通勤通学を考えた引越し先や、自分の住まいや友人の住まいからの行きたい駅候補の調査などに使っていただけたらと思います。
次は関西圏版（もうすぐ完成予定）です。
北海道版、全国版、世界版はプロタイプ開発済み、なので今後も実装＆リリースできたらいいなあと思っています。将来的には路線に限らず、航路、陸路、建物など、いろんな領域で同じようなサービスが作りたいと思っています。お金が残っているうちに、かろうじて特許出願できたのが幸いでした。
一般的な地図データの中心点からの角度を維持しながら時間と運賃（お金）の概念で距離を倍率変換しています。例えば、距離は遠くても時間が短いならより近くに、距離は近くても運賃がかかるならより遠くへと。距離が遠くになるにつれズレも激しくなる部分を補正しつつ、事前に全組み合わせを計算するコストが大変でした。
当初は計算された位置データをcanvasかGDあたりで、と考えていたのですがコスト高過ぎて断念。人間が目で見ても意味が分からない数字が一杯並んだだけじゃ、それまでの苦労が無駄になってしまうので悩みました。そこで、描画のベースにGoogle Maps APIを使うという荒技を。計算済みデータを保有するA側のサーバと、サービスを設置してるサーバのDBを連動させることで、描画用のデータを生成、あとはいわゆるLAMPなwebアプリという感じで画面出力してます。
A システムトレーダー。いつのまにかアベノミクスで大損していた。引越し検討中。
H 流しのギタリスト。いつのまにか会社が潰れていた。引越し検討中。
N 料亭の女将を夢見る才媛。いつのまにか手伝わされていた。引越し検討中。
なにか他では見たことのないものを作りたいと思っていました。
地味ですけど、電話帳のように世の中の誰かには必要とされて、長いこと使い続けて貰えたら嬉しいです。できれば引越ししなくても良いくらいに運営できれば最高です。私一人ではとても無理で、一緒に作ってくれた盟友Hの独創性ほとばしるスキルと芸術性に感謝します。Nの献身的な支援にも勇気づけられました。
使ってみた感想や、ダメ出し、いつも駄弁っている町屋に参戦表明など、やさしくこっそり伝えて頂けると3人とも喜びます。
よろしくお願いします！
私は不景気の昨今、株で大失敗した男A（データ分析が生業）です。同じく不景気で会社が倒産した男H（Web開発が生業）と一緒にWebサービスを作りました。
私はお金を、彼は職場を失ったので、生活に困窮し、現在引越しを考えています。けれど、どこに住んだら良いかわからないので、そんなときに必要な地図Webサービスを作りました。世知辛い感じで作り始めましたが、サービス自体は思わず楽しくなって作りこんでしまいました。私らは事情によりFacebookやれないし、Twitterではフォロワー少ないし、何かのビジネスプランやWebコンテンツのコンテストもほとんどなくなってしまったし、で、どうか匿名ダイアリーの場をお借りさせてください。
距離より大事な時間とお金で地図を変換・新しい地図サービスmaplas【マプラス】
距離で描かれる通常の地図に対して、これは地点間の移動に要する「時間」と「運賃」（電車）で描かれている地図です。
今回は東京の通勤圏（東京から通勤可能そうな約60km圏が対象です）の路線が変形して図示されます。デフォルトでは二人が飲み歩いている町屋近辺を「運賃」の世界で描画しています。クリックしたり検索ボックスから検索するとそこを中心に設定できます。またコントロールで時間、運賃、距離（普通の地図）の切り替えで比較できます。
距離の近い順に 田端、北千住、王子 （同心円の単位はkm）ですが
（移動）時間では早い順に、北千住、田端、王子、（同心円の単位は分）
運賃（移動料金）では安い順に、北千住、田端＝王子、 （同心円の単位は円）
で描画され、地図のようにマクロ的に把握できるようになるサービスです。比較マップで二画面分割の比較もできます。
これで毎日の通勤先に時間や料金でお得な駅、自宅から遊びに行くのに思ったよりお金は時間のかかる駅などがわかります。
通勤通学を考えた引越し先や、自分の住まいや友人の住まいからの行きたい駅候補の調査などに使っていただけたらと思います。
次は関西圏版（もうすぐ完成予定）です。
北海道版、全国版、世界版はプロタイプ開発済み、なので今後も実装＆リリースできたらいいなあと思っています。将来的には路線に限らず、航路、陸路、建物など、いろんな領域で同じようなサービスが作りたいと思っています。お金が残っているうちに、この地図変形、描画方法について特許出願できたのが幸いでした。
一般的な地図データの中心点からの角度を維持しながら時間と運賃（お金）の概念で距離を倍率変換しています。例えば、距離は遠くても時間が短いならより近くに、距離は近くても運賃がかかるならより遠くへと。距離が遠くになるにつれズレも激しくなる部分を補正しつつ、事前に全組み合わせを計算するコストが大変でした。
当初は計算された位置データをcanvasかGDあたりで、と考えていたのですがコスト高過ぎて断念。人間が目で見ても意味が分からない数字が一杯並んだだけじゃ、それまでの苦労が無駄になってしまうので悩みました。そこで、描画のベースにGoogle Maps APIを使うという荒技を。計算済みデータを保有するA側のサーバと、サービスを設置してるサーバのDBを連動させることで、描画用のデータを生成、あとはいわゆるLAMPなwebアプリという感じで画面出力してます。
A システムトレーダー。いつのまにかアベノミクスで大損していた。引越し検討中。
H 流しのギタリスト。いつのまにか会社が潰れていた。引越し検討中。
N 料亭の女将を夢見る才媛。いつのまにか手伝わされていた。引越し検討中。
なにか他では見たことのないものを作りたいと思っていました。
SNSみたく人がコンテンツになって変化が楽しめるサービスじゃないから地味ですけど、電話帳のように世の中の誰かには必要とされて、長いこと使い続けて貰えたら嬉しいです。できれば引越ししなくても良いくらいに運営できれば最高です。緯度経度、地図の変換とGoogleMapの連動なんかはものすごく難しかったけど良い経験になりました。
私一人ではとても無理で、一緒に作ってくれた盟友Hの独創性ほとばしるスキルと芸術性に感謝します。Nの献身的な支援にも勇気づけられました。
使ってみた感想や、ダメ出し、いつも駄弁っている町屋に参戦表明など、やさしくこっそり伝えて頂けると3人とも喜びます。よろしくお願いします！
先日「Flashエンジニアが今後10年食べていくには？」というテーマを元に
Flash に精通した Web 技術者達のディスカッションが行われる催し物があった。
http://www.publickey1.jp/blog/11/flash10.html
この記事だけでは内容が省略しすぎているため
時間があれば是非録画の模様もみていただきたい。前半初頭は音量が小さいので注意。
こういった催し物は面白いなと、私はとても楽しく見させていただいた。
http://www.ustream.tv/recorded/19073524
http://www.ustream.tv/recorded/19074357
ディスカッションでは Flash だけではなく HTML5 についても触れている。
ディスカッションの感想をディレクションや営業を行なっている知人に聞いたり、
ネット上の反応を見てみたところ以下のような意見がいくつかあった。
「『Flash が好きな人』だけではなく HTML5 派の人との対談もあればよかった」
「Flash 派の人の話だから HTML5 が使えないという話はいまいち参考にならない」
『Flash 派』『HTML5 派』という くくりで考えてしまう人は
まだまだ多いと実感する。
パネリスト達は
過去から現在までに様々なプログラミング言語を利用し、あらゆる技術に精通している。
Flash という表示媒体/環境開発がベター(時にはベスト)だと考え、
Flash をよく扱っている、という旨を話している。
最後の締めとして
Flash よりも優れたものが登場するのであればそちらに移行するでしょう、
とも言っている。
これだけの説明があったのに
ディスカッション内で触れた HTML5 に対する否定的な話は、
『Flash 派』とやらのポジショントークだと目に写ってしまったのだ。
Java やら C やら objective-c やら perl やら php やら
サーバサイドからスマホ用ネイティブ言語を用いてのアプリ制作まで
色んな事やってます、と言っても
現在世の中には HTML5 を推し、合わせて Flash を否定する記事が結構出回っている。
技術者が話す専門的な用語の飛び交う話よりも
HTML5 vs Flash 的な読みやすい記事に耳を傾けてしまう人はいる。
Apple 製品を好む人は「ジョブズがそう選択したのだから」と
なおさらこういった記事に目を向けてしまう。
「Flash vs HTML5 の話にのせられてしまうのは、よくわかっていない人だ。」
ディスカッション内では、
ネット上の煽り記事を読み不安に思ったクライアントから連絡を受け
きちんと状況をゼロから説明するハメになってしまった、という内容があった。
似たような状況になっている人もいるのではないだろうか。
当方周辺では、
「Flash は駄目だ」「Flash でなくても HTML5 ならできるはずだ」
「HTML5 は Flash の代わりになるものだと言われている」と
クライアント、あるいは仕事先の関係会社から耳にする機会が増えてきた。
技術者の及ばないところで
ベターではない技術が選択、あるいは勧められてしまう やっかい性。
その記事は世間の目には届かない。
TV CM でバンバン流れている iPhone や iPad では Flash を見ることができない
という状況に乗じた
勘違いを正すためには、今までよりもより一層
あるいはメッセージを発信するよう心がけていかねばならないと感じる。
パネリスト達のような
Flash を扱う事が可能な技術力を持ち合わせている人にとって
Flash が終わろうが、代わりの技術が HTML5 やらその他何になろうが
大した影響はない。
『プログラミング』についての話をしてみる事にする。
「世にあらゆるプログラミング言語があるが
「何か一つ言語を習得し
『Flash の事は全く知らないがプログラミングプロフェッショナルの人』
が近くにいるならば是非上記について伺ってみてほしい。
その通りだと答えてくれるはずだ。
他の言語で作ったものを Flash のプログラミング言語に移植することも容易いのだ。
ここで上記三行の「他の言語」を「JavaScript」に置き換えてみてほしい。
HTML の DOM 操作に必要な言語は JavaScript である。
言語は、Flash ならば ActionScript、HTML5 ならば JavaScript を用いる。
画面描画は
あるいは用意されている描画用 API を ActionScript で呼び出し、
あるいは用意されている描画用 API を JavaScript で呼び出す。
Flash と似たような技術として Java Applet や Shockwave があるが、
これらも一緒で
言語を変え、その技術に合わせた描画を行う処理を記述するだけだ。
Web 技術者が何かに属していて、何かには属していないかのような区別の仕方は
的がはずれている事を なんとなく感じていただけただろうか。
仕事に対し、あるいは表現したい事に対し、ベターな選択を行うだけの事なのである。
環境や表示内容に合わせ両方を採る選択もあるだろう。
パネリストの中に ActionScript が好きだ、という人がいた。
これは別に
Flash が好き(製品のファン)だから ActionScript が好き、と言っているのではない。
ActionScript が優れたプログラミング言語だと判断しての発言なのだ。
HTML5 を選択するだけの事であり、
その別の技術を選択し、
Flash より優れた技術が登場しなければ Flash を使い続ける、
ただそれだけの事なのである。
もう少し突っ込んだ話をすると
Flash のプログラミング言語である ActionScript(ActionScript 1.0)と
HTML 表示制御を行う言語 JavaScript は 実は同じ言語仕様である。
『ECMAScript』という単語で調べてみてほしい。
「Flash と HTML5 は対立するもの」と考えていた人、
あるいは ActionScript や JavaScript を触れたことがない人にとって
「え？そうなの？」と思う人もいる事だろう。
JavaScript は大規模開発に向いていない、という話は聞いたことがないだろうか。
同様の言語仕様である ActionScript 1.0 はこの問題を解決するため
ActionScript 2.0 から ActionScript 3.0 へと進化していった。
Flash は開発がし易い、という話がよく挙げられるが
その理由の一つがこれである。
現行の JavaScript と ActionScript 1.0 は ECMAScript 3 準拠に対し、
ActionScript 3.0 は ECMAScript 4 準拠である。
言語として進化しているものを Flash は採用しているので
開発は抜群にし易い。
ECMAScript 4 準拠の JavaScript も登場する日もあったかもしれなかったのだが、
ECMAScript 4 標準化が白紙、
ECMAScript 4 は無かったことになってしまったのだ。
ActionScript 3.0 で作成したプログラムが
ちなみに JavaScript は大規模開発に向いていない、という事に対し、
最近では Google が新言語 Dart というものを開発している。
位置づけとしては ActionScript 2.0 に近いと比喩した人もいる。
ActionScript 2.0 はコンパイル時 ActionScript 1.0 に変換されて出力される。
Dart も同じく JavaScript 変換機能を持つ。
先の事は誰にもわからない。
HTML5 が成長するとは必ずしも言えない。
技術者は身を持って知っている。
表示と動作の差異、技術者はずっと苦しめられてきている。
めんどくさい。コストがかかる。
HTML5 も同じ道を辿るのでは、と言われてしまうのも仕方がない。
実際に HTML5 の各ブラウザの実装具合はバラバラである。
Flash はといえば、
今でも 10年以上前のスクリプト言語 (ActionScript 1.0 よりも前の言語)で
Flash が動作するブラウザがいつまで携帯に搭載され続けるのか、
まだ誰にもわからない。
今後も当面携帯向け Flash を作り続ける事になるのかもしれない。
携帯向け Flash は一つの容量が小さいというのが救いである。
IE6 対応 HTML サイト制作にせよ、携帯向け Flash 制作にせよ
状況に応じて何を選択するかを判断できるほどの技術力を身につける事
選択する技術に何ができて何ができないのか、
どの技術を組み合わせるとよいのか、
自ら判断できるようになった時、一人前の Web 技術者になったと言えるだろう。
一つ何かをモノにしてしまえば前述の通り移行は容易い。
それを極めるくらいまでとことん勉強してほしい。
続けていくと見えてくるはずだ。自信という名の悟りの道が。
気になった点をいくつか。
現状の HTML5 の実装具合のバラバラさに対し、
「(HTML5の)表示の差分を埋めてくれる何かが登場するかもしれない」
と言う発言があった。
言った当人も会場にいる人達も、きっとこう思っただろう。
「それってなんて Flash Player？」と。
「あれはやめたほうがいい」という発言があった。
勝手に注釈するのであればこの発言は
「Flash で作られた重たい Web を HTML5 でまた再現するつもりなの？」
という皮肉であろう。
”リッチなインターネットコンテンツを、非常に簡潔にスマートに記述できる”と文系チックに書いたのに、
あ、ごめんなさい、そういう風に読めなかった。スペコンのことしか頭にないというか、Canvas、SVGのことしか知らない人的な思い込みで書いてしまいました。大変失礼しました。
その当たり前の事ができなかったHTML4。HTML5になればできるようになるとでも言いたいのなら、あなたもネットに向いてない。
なにが出来なかったのか意味が分からないけど、単にWeb標準のHTML5を普通に使っていこうよっていうのがいいたかった。ネットに向いてないっていうのもちょっとわからない。向いてないかもね、しらんけど。
いいたかったのはシンプルなことでして、「スペコンって必要なの？ それ誰が見てるの？」みたいなことです。Flasherのポジショントークに対して。
ぼくもだいぶいろいろ作ってきたけど、Flashの実現するインタラクティブは素晴らしい。とうぜん同じ事をやろうとすればHTML5ではまったく役不足。が、そもそも活躍の場がなくなってきていることに加えて、そこそこのことならWeb標準の技術で可能になってきた。みたいなことをカッコヨク伝えようとしたらこうなった。わかりづらくてすまん。
んー、HTMLの基本は必須かもしれないけど、Flashの仕事をするのにHTML5を駆使する必要はないっていうことじゃないかな？
HTMLの標準になるんだから、駆使とかそういう事じゃないよ。
仮に標準になったら、HTMLの文法規則や、「video,audio,canvas」などのタグが標準仕様に追加されるんだから、必須項目だよ。
使わないから知らなくていい、とかそういう話じゃない。
わざと避けてた部分を書かれたw
まぁFlashの普及という意味ではvideoタグが全部持ってくよね。あとcss3。canvasはそれほど脅威ではない印象。
videoタグの実装が整ってくれば、一定数のFlash離れは起こるんじゃないかと思う。ただ、videoタグの普及にはまだまだ時間がかかりそうだから、それまでにFlash無しじゃいられない体にしてしまえば、生き残りは十分可能な気もする。実際、Mixiアプリやってる有閑マダム達を虜にして一定数は確保してる。
あと、一度インストールしたら、重大なセキュリティホールが発見されない限り、わざわざアンインストールはされない。慎重に対応すれば現在の普及率をある程度キープすることは可能。
もっとも、Adobeは、Flashをブラウザ上からクロスプラットフォームのアプリ作成環境にまで成長させるつもりっぽいので、長い目でみてもFlashは形を変えつつ生き残るんじゃないかと思ってる。
「Flashに死んで欲しいと思ってる」ってのもある程度同意。ただし少なくともIE6ほど「みんな」ではない。
Flashが恨まれるのは、まだマシンパワーが貧弱だった時代に、わざわざ重いベクターアニメーション環境をブラウザで動かしてしまった事に起因してる。その上、かなり優秀なタイムラインアニメーションツールを提供してしまったため、敷居がぐっと下がってしまい、「負荷」という言葉を知らないアーチスト達によって、きれいだけど無茶なコンテンツが量産されてしまったという悲劇を引きずっている。
もっとも、マシンパワーがあがった今でも、負荷的に無茶なFlashコンテンツが量産され続けている状況は変わってない。これはFlashのせいというより、コンテンツ作成者の知識不足によるところが大きい。Adobeは、もっとコンテンツ作成者の成熟に力を入れたほうがよいのかも知れない。
