はてなキーワード: canvasとは
開発側です。
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は、もっとコンテンツ作成者の成熟に力を入れたほうがよいのかも知れない。
FlexSDK使うだけならCanvasでいいんじゃね。
あの花っていうのは「あの日見た花の名前を僕達はまだ知らない。」っていうアニメね。
途中までスルーしてたんだけどある時見てからはまった。最後はいい年して涙腺崩壊 (T_T)
まどか厨には申し訳ないけど今年のアニメNo.1はあの花で決まりだね!
あの花のEDがすごい好きで(OPも好き)、アニメ見るとOP,EDは飛ばしがちなんだけどこれは全部見てた。
曲はZONEのカバー曲『secret base~君がくれたもの~(10 years after Ver)』
花が落下しながらサビの手前でズームアウト後に上昇っていう演出も d(・∀・)Good !
で、これhtmlで再現できそうだな~と思って作ってみることにした。
htmlは初歩しか分からないので使えそうなコードを拾ってきて
Canvasを使いたかったんだけど難しそうなので諦めて違う方法でやってたら
なんと数日後に1からCanvasを使って作ってくれた人が現れました!超嬉しい!
http://zz.x0.com/anohana/canvas.html
http://zz.x0.com/anohana/font.html
png版
http://hibari.2ch.net/test/read.cgi/hp/1155395444/193-
Audio
Opacity
第壱話 HTML5、襲来
第弐話 見知らぬ、ブラウザ
第参話 鳴らない、Audio
第四話 WAI-ARIA、逃げ出した後
第伍話 Safari、心の向こうに
第七話 WWWの造りしもの
第八話 Chrome、来日
第九話 瞬間、Canvas、重ねて
第拾話 セクションダイバー
第拾壱話 静止したACID3の中で
第拾弐話 先行実装の価値は
第拾参話 バグ、混入
第拾四話 Firefox、魂の座
第拾伍話 バグとハック
第拾六話 死に至る非標準、そして
第拾七話 四人目のECMAScriptエンジン
第拾八話 DTDの選択を
第拾九話 ベンダーの戰い
第弐拾参話 IE
第弐拾四話 最後のCSS
第弐拾伍話 終わるXHTML2
第弐拾六話 世界の中心でセマンティックを叫んだけもの
やっすい中古品から自作PCなんて既に確立された技術でちゃんと集めれば誰でも出来るんじゃないの?http://b.hatena.ne.jp/entry/hamusoku.com/archives/627391.html
家鍋なんて既に確立したレシピでちゃんと調理すれば誰でもできるんじゃないの?http://b.hatena.ne.jp/articles/200911/568
効率的な物件の探し方なんて既に確立したノウハウで経験すれば誰でも出来るんじゃないの?http://r.nanapi.jp/286/
石器なんて既に判明した事実で歴史を学べば誰でも出来るんじゃないの?http://www.google.co.jp/search?q=%E7%9F%B3%E5%99%A8
OSなんて既に開発された製品で本を読めば誰でも出来るんじゃないの?http://www.monaos.org/
ま、Canvasで動く3Dってどういう[アルゴリズム|ルーチン|オブジェクト|ライブラリ|フレームワーク|設計]で作ってるんだろう?→なにこのそーすあほせつない、か?
だから、Canvas自体に3Dの描画の機能は無くて、3Dの図形を2Dとして描画するときの座標を計算して2Dで描画してるだけだと思うけど。
Canvasは、FlashやJavaのようにプラグインを使わずに、JavaScriptベースで図を描くこと
↓ソース見てないの?
view-source:http://www.geocities.jp/nbdemo/canvas.html
海外製のフリーのビジュアルノベルエンジン"Ren'Py"の作者が、昨今のエロゲ規制騒動に関して氏のwebサイトでメッセージを掲示しました。
以下に紹介します。
http://www.renpy.org/wiki/Censorship
今まで生きてきた中で、私はさまざまな形のアートに触れてきました。
そして、この5年間にわたってずっと普及に向けてつとめてきたアートの形態が一つあります。ビジュアルノベルです。
文章と絵と音楽が絡み合うビジュアルノベルは、コンピュータ技術を用いてインタラクティブな物語を形作ります。
正しく用いられれば、この媒体は様々な文化圏に渡って真にすばらしい物語を伝えるために使えることでしょう。
ルカ・ジョルダーノ ルクレティアの陵辱 (キャンバス地、油絵 1663)
この数ヶ月、これらの物語の作者たちは規制を求める声に追い立てられています。
他のアートの形態であれば、そのような規制は忌避すべきものと公正に判じられることでしょう。
ビジュアルノベルは比較的新しい媒体であり、美術館や書店で見られるような、他のアートの形態と同様の題材を扱うことは認められない、と
こうした規制の推進者は考えているのでしょうか。
日本政府にお願いします。ビジュアルノベルを、私人に向けて私的に販売される、他のアートの形態と同様に扱ってください。
書籍や漫画や映画で語ることのできる物語を、ただコンピュータの画面に写されているからと言うだけの理由で禁止するというのは
あってはならないことです。
日本および世界中のビジュアルノベル制作者の方々へお願いします。自主規制を求める声に屈しないでください。
あなた方が伝えたいと思う物語、読み手が読みたいと願う物語を語り続けてください。
それ以外の道をたどることは、わたしたちのアートをいかなる意味であれ価値の劣るものとして扱うということです。
そんなことは受け入れられません。
Ren'Py ビジュアルノベルエンジン 主開発者 PyTom
Regarding Censorship of Visual Novels
Over the course of my life, I've been exposed to many different forms of art. And yet, there's one form that I've spent the past five years of my life trying to encourage, and that's the visual novel. Involving text, pictures, and music, visual novels use computer technology to create a interactive stories. In the right hands, this medium can be used to tell truly great stories that span cultures.
Luca Giordano, The Rape of Lucretia (Oil on canvas, 1663)
Over the past few months, the creators of these stories have been hounded with calls for censorship; censorship that we would rightly find abhorrent in other forms of media. Perhaps these censors believe that since the visual novel is a relatively young medium, they should not be allowed to cover same range of material as other art forms — material one can find in art galleries and bookstores.
To the Japanese government, let me ask that you treat visual novels in the same way as other art, sold privately to private consumers. Stories that can be told in books, comics, and movies should not be prohibited simply because they are displayed on a computer screen.
To the creators of visual novels, in Japan and the rest of the world, let me just ask that you resist calls for self-censorship and continue to tell the stories that you wish to tell, and that audiences wish to experience. To do otherwise would be to treat our art as somehow less worthy, and that is unacceptable.
PyTom, Lead Developer, Ren'Py Visual Novel Engine
June 29, 2009
http://www.new-makura.com/archives/562475.html
ここで話題にあがっていたけど、肝心の日記の内容が掲載されてないみたいなのでmixiのチャンコ増田氏の日記から転載(転載OKらしいので)
(改行修正済み)
四月馬鹿には一日早い3/31、ホワイトキャンバスを運営する有限会社セルビテックより取引サークルに対して下記のメールが送りつけられた。 ↓ここから引用 ---------- 拝啓 時下ますますご清栄のこととお喜び申しあげます。平素は格別のお引き立てにあず かり、ありがたく厚くお礼申しあげます さて、この度は3月度の委託支払いにつきましては、従来より細心の注意を払ってきたところでございますが、委託集計のデータ破損により、委託支払額の過払いが生じましたことをご報告させていただくと共に、多くのサークル様にご迷惑をおかけしたことを深くお詫び申し上げます。 本メールは過払いに該当するサークル様へ、個別にご連絡させていただいております。 現在、弊社は多額な過払いにより出納業務に支障をきたしております、また今後の委託支払いの経理処理にも問題が生じるため、大変にご迷惑をおかけいたしますが、過払額の返納に何卒ご協力いただけますようお願い申し上げます。 誤データによる振込金額 xxxxx円 データ修復後の修正金額 xxxxx円 A様への過払金額は、xxxx円となります。 過払分弊社返金先につきましては、以下の口座になります。 (以下省略) ---------- ↑ここまで引用(一部略&伏字) 言葉を選んで丁寧な文章で書いてありますが、要約すると 1、うっかり間違えて振り込みすぎちゃった 2、原因は管理ミス 3、悪いけど金返してね ということです。 しかしながら、取引先サークルにこの手のメールを送るのはご法度です。 なぜならば、金員の支払いは信用を築く最も根本的な事項にもかかわらず、自社ではそれを管理できる能力が無いというのを自分で言ってしまっているからです。サーバー用PCが火災などでクラッシュしてしまっうなどのやむを得ない事情の場合でも、それは会社の自己都合ですので取引先には関係ないことです。さらに過入金してしまった場合でも、委託作品は預かり続けているので次月の売上と相殺するのが一般的な処理の方法です。 実際にこのメールを送ってからの反応はどうなったか。 私のマイミクさんとその先に連なっている例大祭やコミケで(西だけど)壁取っているサークルさんが片手では足りないほど、取引停止&在庫引き上げを明言しています。2ちゃんねる同人板では、とうとう単独スレが立てられてしまうほどです。まあ炎上というほどでは無いですが。 同人誌取扱店として、仕入先であるサークルさんを怒らせてしまうのは愚の骨頂ですしそれを送ったときにどういうことになるのか、わかっていないのか天然なのか確信犯なのか……そのあたりについても考察したいと思います。 1、わかっていない場合・天然の場合 たいへん申し訳ないのですが、商売でも会社経営でも全ての根本は「人」、人材です。資金とか経営手腕は二の次です。人を人として思っていない企業とはとてもではないですがお付き合いできないと考えるのが通常です。 2、確信犯の場合 こちらの方がより深刻で取引サークルは速やかなる在庫の引き上げと清算をお勧めします。 なぜならば、会社を畳むのを前提となるからです。 4月末が会社の決算ですので、思いっきり黒字で決算出して銀行から金借りて2-3ヶ月したら計画倒産する……とここまで想像するのは難しく無かったです。なんでこういうことがいえるからというと、普段の会話の中でも「債務の圧縮の仕方」(子買いの名目上第三者に債権を1掛けで売り飛ばす)とか「会社をコカすまえには借りられるだけ借りてから」というのが再三再四でていたからです。 どちらの場合でも、即時取引停止・在庫の引き上げをするのが正常の反応です。 在庫をとりもどして、各自の目で在庫数を確認してそれでも返金しなければいけないという場合のみ返金するというのが筋というものでしょう。 返金額については、振り込み手数料以下のものから50万円代のものまで聞き及んでおります。 私が責任者でしたら ・一万円以下→報告だけして来月以降の売上で調整 ・1~10万円→同上+電話で連絡 ・10万円以上→上にプラスしてさらに個別対応 あたりの対応ですかね。 返金してくれっていうのは口が裂けても言いません。 先に「人が大切だ」と書きましたが、それがわかっていない明確な証拠があります。 諫言苦言を呈した人物は全て解雇されたか不当な扱いをされて辞職したからです。 みんな若くて真っ直ぐでイイ奴らでした。 これ以上無い悪い待遇で必死に働いて会社の売上が5年で7倍になったのになにも報いてくれませんでした。資本論のとおりで、ただ経営者は搾取するばかりです。中にいるときはネタで「プロレタリアートよ団結せよ! われわれ労働者は食料を要求する」とやったものです。そうしたらピザくらいはおごってくれましたが(苦笑)。一度たりとも深夜残業手当てなどついたことはないですが、それでも店一件まかせられたんだから……というプライドだけで、私は金沢と大阪の店を切り盛りしていました。それを取り上げられたときのショックは……仕事している方なら深くご理解していただけると思います。ポジティブなことは自分でも認めますが、それでも正直一ヶ月腑抜けになりました。 元々人付き合いのヘタクソさには定評のある同社でしたが、その原因の根本は全て経営責任者S氏の資質と性格にあります。私は5年ほど付き合いがありましたが、最後に喧嘩別れするときに本性を表して如何に人を見下しているか・俺たちが一番頭いいんだというのがひしひしと伝わってきましたし、 「おまえを含めてサークルの奴らは所詮オタクで常識がない。だからお前は会社を潰したんだ。俺が引き取ってやって面倒見ていたのに言うこと聞かないとは何ごとだ」 とまで罵られました。 喧嘩別れした理由はカンタンで、Sオーナーに全く誠意が無かったからです。 当時販売代行・委託管理をしていた「dakimakura.net」の売上の報告はあったり無かったり。支払いについては時給800円の時給月給と社宅の支払い以外一円もありませんでした。何度請求しても「後で」「そのうち」の繰り返しで、挙句の果てに「てめーしつこいんだよ!」とキレて私と同姓の事件屋まがいのまで出てきて脅されました。 私も小さいながらも会社を経営していた人間ですので、ほどほどのところで見切って企画も出さないでノウハウもしまい込んで適当にしていましたが、充分ノウハウ吸収して自分でも同じようなことができると思ったころ、先方からお払い箱にされました。むこうから手を切ってくれたYO! (・∀・)bヤッタネ! (※一部改変) 下の点線内は一部追記しました。 追記部分は【】すみつきカッコでくくってあります。 --------------- そのあと【同社では】「サークル・ホワイトキャンバス」としてZUN氏に無許可で「企業が商品作って販売」しております。 【以下同社HPリンク】 ttp://www.w-canvas.com/shopping/doujins.cgi?sec=show_catalog&search_type=maker_key&key=405&no_item=1&listing_style=graphic 【最近同社では】抱き枕をいろいろと頒布していたのは周知のご存知の通りです。【製造元や製造、販売のノウハウまで盗用して】在庫残さないシステムなにのになんで死ぬほど在庫残しているの? バカなの? 死ぬの? といのが感想です。企画と製造ルートの盗用も看過出来ないのですが、どっちかっていうとアホさ加減に空いた口がふさがりませんでした。 --------------- 前半はメールの分析でしたが、後半は内情バラシになっちゃいましたね。 しかしながら、一点の誇張も虚偽もない事実であることを明記しておきます。 サークルの友人各位に置かれましては、ご判断の材料としていただければ幸いです。 ひとりでも多く被害者が減ればこれ以上のことはありませんので。 ※転載・抜粋はご自由に。日記も全公開にしています。
●メールの考察・追記 担当者の名前がありませんでした。 このことはどういうことか客観的に考察してみました。 甲、故意に書かなかった 乙、流石に名前を出すのが恥ずかしかった 丙、名前を書けるだけの人がいない 丁、単に書き忘れ 甲についてですが 「明確に責任を取る」という企業倫理の点からいただけません。 サークル側が誰に連絡していいかわからなくて困るからです。 この手のデリケートな内容の場合、特定の担当を決めるかor全社に通達を出して「どう対応するか、誰に話をふるか」を決めておかない会社はありえません。 この場合の担当者って誰? 電凸して担当誰だったか分かった方は、ぜひ教えてください。 乙については 恥を知るという点は理解できるのですが、以下は1-甲と同じなので割愛 丙については これが一番深刻かもしれない事態でして、実際に営業担当者がクビになったり配置転換でいなくなったりということがままありました。3月半ばに「最後の良心」と二つ名与えたい営業担当者が退職しましたが、そのこと自体を知っているサークルさんが少ないようです。 常識的に考えて 「担当者がコロコロかわる、退職する」(特に経理) 「金員の支払いがおかしくなる」 あたりの地雷を踏むのは、取引先としてどうかと思うのは皆様方にもご理解いただけると思います。 参考までに http://www.j-cast.com/kaisha/m/2009/02/10035712.html 丁についてですが これも論外だ。事実ならアホすぐるw 過去に同社から届いたメールには、ほとんど営業担当者の苗字が書いてあります。 ですから、名前が無いほうがおかしいです。 ただし、これもないとは言い切れなかったので併記してみました。
地味になって残念
Canvasはどこに行ったんだっけ
インスピレーションは便利だったのに…
Strataって一応未だあるんだよね
ベクター系ペイントツールのExpressionは最終的にMicrosoftが買ったけど、これもう原形留めてないよね?
ロータスとかジャストシステムユーザーは未だ使ってるのか?ノーツは?
クラリスワークス改めAppleWorksはどういう幕のひきかたしたんだろ
タグ「delphi」を含む注目エントリー - はてなブックマーク
Delphiアプリケーションのメモリリーク検出法 (山本隆の開発日誌)
http://www.componentsource.co.jp/features/delphi/
TMS Software | Productivity software building blocks
Components > Effects and Multimedia > Video. Torry's Delphi Pages
Components > Effects and Multimedia > Audio. Torry's Delphi Pages
Components > Effects and Multimedia > Voice. Torry's Delphi Pages
Components > Effects and Multimedia > Direct X. Torry's Delphi Pages
eXeScope(Windows95/98/Me / ユーティリティ)
Delphi-ML〓〓〓〓〓〓〓〓〓〓〓??About Delphi
Delphi Q & A 〓f〓〓〓〓 〓〓〓〓〓〓O〓〓(HTML〓o〓[〓W〓〓〓〓)
Delphi WAVEサウンド音を鳴らす/Tips & Tricks
5分ではじめるDelphi - 第1回 簡単なメディアプレーヤの作成(前編)
Controling sound volume from code
lsMicrophone: mxl.dwComponentType :=MIXERLINE_COMPONENTTYPE_SRC_MICROPHONE;
MIXERLINE_COMPONENTTYPE_DST_SPEAKERS
MIXERLINE_COMPONENTTYPE_SRC_WAVEOUT
SwissDelphiCenter.ch : ...set the volume for the microphone/ mute it (enhanced)?
Components > Sound Effects > Mixer. Torry's Delphi Pages
PlaySound('C:\WINNT\Media\start.wav', 0, SND_FILENAME or SND_ASYNC);
Delphi6でプログラミング ビットマップの半透明コピー AlphaDraw
procedure TForm1.Button1Click(Sender: TObject);
bmp1.LoadFromFile('C:\Program Files\Common Files\Borland Shared\Images\Splash\256Color\FINANCE.BMP');
bmp2.LoadFromFile('C:\Program Files\Common Files\Borland Shared\Images\Splash\256Color\FACTORY.BMP');
Form1.Canvas.Draw(10,10,bmp1);
Form1.Image1.Canvas.Draw(10,10,bmp2);
bmp1.Free;
bmp2.Free;
無料版Delphi6でSTGをつくるためのプログラミング講座 Ver.2005 Jan.
SwissDelphiCenter.ch : ...get the MAC Address?
もっと楽にGUIとの連携がしたい:Python + Delphi = P4D(Python for Delphi) - ふにゃるん
Delphi WindowsのOSのバージョンを取得する/Tips & Tricks
SourceForge.net: Gecko SDK for Delphi
BDS(Delphi/BCB)用SQLiteライブラリ (山本隆の開発日誌)
SwissDelphiCenter.ch : programming tips
ナッキーの「Turbo Delphiはじめて奮戦記」- 第1回 Turbo Delphi のインストール
フリーのTurbo Delphiで始めるWindowsプログラミング:ITpro
フリーのTurbo Delphiで始めるWindowsプログラミング:ITpro
http://torrent.borland.com/turbo_hotfix_rollup.zip
http://torrent.borland.com/prereqs_jp.zip
http://torrent.borland.com/turbodelphi_jp.exe
(1) \dotNETRedist\dotnetfx.exe
(2) \dotNETRedist\langpack.exe
(3) \dotNETRedist\NDP1.1sp1-KB867460-X86.exe