2012年2月29日水曜日

The next work of Art in the age of Informational Reproduction - 2

さて、前回は英語も交えて意見を書いていたのですが(意見は何も書いていないけど)、

ここから先はいわゆるベンヤミンの思想を中心に語っていきたいと思っていて、

それを英語で書き表すには若干英語の書く力が足りないので、

日本語だけでやります。

ご了承ください。

アウラ


『複製技術時代の芸術作品』に登場するメインのテーマである「アウラ」。

これは一般的にはオーラとか呼ばれて、「アノ人独特のオーラを発しているよね」の「オーラ」と同じようなものととりあえず解釈しておいてもらいたいと思います。

で、この本を読みなおそうとしたのですが、『複製技術時代の芸術作品』の晶文社版を探したら手元に無く、

岩波学芸文庫版の解説付きのやつを読もうと思ったら持っていなくて、

どうしようと考えた結果、とりあえず簡略に書いてある三島憲一の『ベンヤミン』(講談社学術文庫2010年)があったので、

そちらに準拠しながら考えていきたいと思います。

ベンヤミンが『複製技術時代の芸術作品』にて述べようとしていたことを三島の解釈を元に簡単に書いていきます。

  • それまで芸術作品として呼ばれているものは、宗教的な儀礼の道具であった
    • 近づきがたいものとしての存在として輝いていた
    • 触ってはならないものとしての尊厳を誇示していた
  • 脱魔術化の傾向(プロテスタンティズムなど)の中で、そうした儀礼の道具からは礼拝上の価値が失われ、展示的な価値が生まれてきた。
    • 額縁に飾られる絵画は教会のフレスコ画に比べて移動させることが可能である。
    • 展覧会のための芸術作品が生じてくるようになる
      • かつては教会を訪れてフレスコ画を鑑賞することにより、「今ここで目の前に」フレスコ画「がある」という一回限りの体験という尊厳があった。
      • この一回性の尊厳を当面「アウラ」と呼ぶことにする。
      • 展示的な側面の価値が優劣になると、「今ここで目の前に」「ある」という一回性「アウラ」が減少する。
  • しかし、展示のための芸術作品はその作品が「1つだけである」という点で「アウラ」が完全に消えきっているわけではない。
  • 一方で印刷術の発展、映画という複製技術によってもたらされる芸術作品では、作品はもはや「1つだけ」という事実が排除されている。
  • 「アウラ」の消失そのものをベンヤミンが「芸術の終焉」と捉えているのではなく、「政治の美学化」(政治を儀礼の場にする、信仰の対象とする)によって最終的に戦争を目的とするファシズムに対向する手段として捉えていた。
  • 「アウラ」の消失によって狙うのは芸術の政治化である。

つまりベンヤミンの『複製技術時代の芸術作品』は、

芸術作品というのはかつてはそれが置かれている土地へ移動しなければ享受することが出来なかった対象であったという時代から、

芸術作品は複製によって享受でき、いつでもそれを享受できるものへと変化しつつあるという弁証法的な流れの中に

位置づけようと試みた批評であったと考えてよいであろう。


さて、ここではベンヤミンの「アウラ」概念の概説を眺めたわけであるが、我々は一度、これをマルクスに基づいて再評価していくことになる。

続く。












追記

Amazonで検索したら『ベンヤミン・コレクション-1 近代の意味』が挙がっていて、実はそれを持っていたらしい…orz

The next work of Art in the age of Informational Reproduction - 1

Today I read my Time Line in the Twitter, I found an interesting Tweet.
今日、タイムラインを眺めていたら、ちょっと気になるツイートを見かけました。





Well, there is some change in a singer's vocalization according to the linked article.
さて、このリンク先の記事を読むと、最近のボーカリストの発声が何かおかしいらしい。


I quote most important part for me from the article .
重要だと思われる部分を少し、引用してみたい。

まっすぐ歌うボーカリストが多い

《節回し(しゃくり)が全く出来ていない、というかやっていない》ということです。歌の入りから語尾までまっすぐ歌っているのです。

どうしてそんな不自然な歌い方をするのでしょうか?

これは最近の音楽業界が作っているCDに問題があるのでは?と思えてなりません。

実際にデビュー予備軍のボーカリストに「どうして語尾も含めてまっすぐ歌うの?」と私が訪ねると、「私が好きなアーティストがそう歌っているから」と答えました。

愛情のない歌の直しがはびこっている

最近はDAWの発達でいとも簡単に歌を直せてしまうため、音楽制作者側が音程や節回しを直し過ぎている現状があります。せっかくナチュラルな良い節が入っている歌を、むやみやたらとまっすぐ線を引くように、直してしまうのです。

…(中略)…

以前【ボーカルエディット】の記事にも書きましたが、通常皆さんが聴いているCDは、ボーカリストが何本かレコーディングした歌の中で、良い部分を選んで、それをつなげて1本の歌にしているんですね。

歌選び(ボーカルセレクト)をきちんとした歌は、ピッチ修正やタイミングを直すより、とても良い歌に仕上がります。
ただ、ボーカルレコーディングは通常6~7回は歌うので、当然膨大な量の言葉を聴き分ける事になり、かなり大変な作業になります。


10 years ago I was working on DTM and recording musics so that i know to compile musical fragments into one works takes much times and is hard work.

一応、オレも10年前くらいに、DTMとかレコーディングとかやったことあるので、このあたりの作業は半端無く時間がかかる大変な作業だったと記憶しています。



Especially 10 years ago, instruments called sampler(like AKAI MPC2000XL or Roland MC-808) was commonly used, to create music is to compile some sampled sounds into one music.

特に10年前はサンプラーと呼ばれる楽器(赤井電機のMPC2000XLとかRoland MC-808など)が一般的によく使われていて、音楽の制作というのは収集したサンプルを組み立ててひとつの楽曲に編集する作業といっても過言ではありませんでした。


Sometimes we took a cool sample sounds from records or CDs which inspired us to create new works.

時にはレコードやCDなどのカッコイイ音は新しい曲を作るモティベーションにつながりました。


By the way, these style of creating work of art, to make works with by copying and pasting amount of fragmentation, had been already mentioned by some critics 40 - 50 years ago. In them there are Jack Derrida having mentioned it as "ecritur", and Walter Benjamin in his 'The Work of Art in the Age of Mechanical Reproduction'.

しかし、これらの手法というのは既に40~50年前の批評家たちからすでに登場することがすでに言及されていました。例えば、ジャック・デリダは『エクリチュール』という概念でそれを指摘していたし、ヴァルター・ベンヤミンも『複製技術時代の芸術作品』という本で指摘しています。


We can imagine the thought of them via cinema. For example, Yasujiro Ozu, Japanese famous movie director, might think that editing and compiling fragment is most important phase of creating movie. His movie is was construct of small parts of fragment shots.

映画を通してその考えは理解できる。例えば、小津安二郎、日本を代表する映画監督は、編集こそが映画を作り上げると考えていた節がある。彼の映画は小さなショットの連続で構成されている。


to be continued...

続く

2012年2月25日土曜日

Gradle、ちょっと面倒な所

どうも。

ビルドツールではGradleを一押ししているのですが、
まだまだ開発中故に残念なところがあるので、
そのメモです。

Dependencyの指定にGStringが使えない




プロジェクトの依存ライブラリーを指定するときに、
同じGroupIdで同じバージョンを使うときに、
プロパティを設けておいて、
それを利用する方がのちのち便利です。

Groovyの場合、文字を展開するのに便利なGStringクラスがあり、
変数を置き換える際にそれを利用します。

というわけで、dependencyの指定にはGStringを利用したいわけです。



上記のbuild.gradleでは、
GAEのバージョンやSlim3のバージョンをプロパティに設定して利用しているわけですが、
こんな感じのエラーが発生します。



GStringがStringにキャストできないということらしいです。

対策


仕方が無いので、カッコ悪いですが、toString()メソッドを利用します。



これはソースを読んで、パッチでも送りましょうかね…

Windowsでの問題


Macなら多分問題はないと思いますが、
Windowsでやっていると、
文字コードの問題が出てきます。

これについては、@nobeansさんの『豆無日記』「Gradleで文字エンコーディングを指定する方法」に詳しく書かれています。

先ほどのbuild.gradleでWindowsでコンパイルする場合、こんなエラーが出ます(コードページは932、ソースはUTF-8)。



@nobeansさんのページに書かれたとおりに修正するとこんな感じのbuild.gradleファイルになります。



これで、なんとかうまく走りました。



ココらへんは、今年中にmilestoneが30くらいまでになるというGradleですので、対策してくれるんじゃないかななどと勝手に期待してみたり…


追記:2012/02/25 8:45

@orange_cloverさんからアドバイスがあったページ
『設計と実装の狭間で。』の「[Gradle]Gradleで文字エンコーディングを指定する方法」に書いてあった方法でも
エンコーディングの指定が可能なようです。



ところが、ひとつだけ残念なところが…



IntelliJ IDEAの10.5だとエラーになってしまうんですよね…

もちろん実行できますが…


2012年2月22日水曜日

MavenからGradleに移行するただひとつの理由

MavenかGradleか?

この前の日曜日、MavenかGradleかといった論争がTLを賑わしていました。


Gradleがいいよとか、Mavenがいいよとか、Ivyだよとか、sbtだよとか、やっぱここは老舗のAntだとか…

Gradle一押しのオレの意見


MavenからGradleへ移行するたった一つの理由










それは











特にない




Mavenでちゃんとビルドができているプロジェクト、それでいいんじゃない。
それで顧客に価値が提供できているという時点で、Mavenは大きな貢献をしていると思います。

Gradleでビルドができているプロジェクト、それでいいんじゃない。
SpringとかHibernateなんかがそうです。
それで顧客に価値が提供できているという時点で、Gradleは大きな貢献をしていると思います。

だから、そういうプロジェクトがMavenからGradleへ無理に移行することもとくにないと思うし、GradleからMavenへも然り。

Mavenのpom.xml読みづらいけど、IntelliJ IDEAで読めば、結構読める。
そもそもpom.xmlわかりづらいっていう問題は、数カ月努力すれば読めるようになる。
これはオレの経験則から。
Antのbuild.xmlよりはわかりやすいですよ。pom.xml。


GradleやMavenを本当に導入するべきプロジェクトというのは、

開発者各自がjarとかzipとかをダウンロードしたり、特定の端末でないと商用ビルドができないとか、特定の担当者がいないとビルドができないとかそういう属人的、属端末的、個々人がバラバラ的なプロジェクト、そういうプロジェクトにこそ導入するべきだと思うわけです。

その意味で、
@ikeike443さんのツイート「ライブラリを探すのに未だにGoogleで検索して適当に見つかったものを手でダウンロードして、依存関係は手と目で一生懸命さがして解決して、みたいにやってる方いるもんなあ。プロダクションではまたバージョンの違う組み合わせのライブラリを使ってて動かないみたいな。」が最も的を得ていると思いました。


というわけで、多分世の中にたくさんあるであろう各自が勝手にライブラリーを落としてきて自分とこだけうまくいくようなプロジェクトにこそ、Mavenは導入してもらいたいし、Gradleは導入してもらいたい。

2012年2月19日日曜日

久々にAppEngineをやってみた。

まあ、以前も小川さんの『Slim3』本を写経していましたが、かなり忘れていたっていうのもあるので、写経しました。

だいぶAppEngineのバージョンも上がっており、
色々と気になるところはありますが、
まだまだ情弱なオレのことですので、
基本をもう一回みっちりと叩きこんでおきたいと思います。

使用した環境は以下のとおりです。

  • IDE : IntelliJ IDEA 10.5
  • Google AppEngine 1.6.2.1
  • Slim3 1.0.15
  • maven 3.0.4
  • gradle-milestone-8

一応必要そうな依存性はpom.xmlで集めましたが、
ここは、小川さん、わかめが嫌いそうなGradleでやって見ることにします。

なお、今回はテストはChapter5-Section3-example1のコードを少し改造してやっています。

まずは、pom.xml



長いです。

pom.xml情弱のオレには辛かったです。
この編は小川さんのサポートがないと生きていけません。

これをbuild.gradleで書きなおしてみました。



テストコードはこんな感じです。



Gradleでの実行結果はこんな感じです。



mavenでの実行結果はこんな感じです。




maven情弱のオレにはmavenは敷居が高すぎましたorz


2012年2月18日土曜日

Developers Summit 2012 17-D-7 実践Androidデベロッパーズテストにて講演してきました。

通称デブサミ2012の二日目最終セッションでAndroidテスト部の一員として講演してきました。

講演資料はスライドシェアにあります。
こちらの26ページから56ページを担当させて頂きました。

また、その期間のツイートはtogetterにまとめてあります。

なお、今回の講演にあたってサンプルで作成していたアプリケーション「お小遣い・ログ」のソースコードはGitHubにて公開しています。

Twitter上で私をフォローしていただいている方はご存じの方も多いかもしれませんが、最近の私のTwitterのプロファイルは「冬眠中」となっています。

実は、これは文字通り意味していまして、若干過眠症気味な状態になっています。

そういったわけで、今回資料を作成するにあたっては、メンバーの皆さん @snskさん、@nowsprintingさん、@ussy00さんには大変ご迷惑をおかけいたしました。

ここで感謝を表したいと思います。

また、今回の資料を作成するにあたって、何度か会社を休んでしまいました。

相談に乗っていただいた株式会社トップゲートの加藤社長ならびに同僚の皆様にも大変感謝しております。


2012年2月15日水曜日

今さらJavaのCalendarとか調べた

Calendar#add(int, int)の動きが気になったので、ちょっと確認した。



結果はこうなった