Hatena::ブログ(Diary)

word-iteration RSSフィード

2016-05-08

冨田勲が亡くなった

冨田勲氏、逝去のお知らせ http://columbia.jp/tomita/info.html

亡くなったらしい。驚いたし寂しい。新しい作品をもう聴けなくなると思うと本当に残念である。最近ブログ書いてなかったけど、追悼と、感じることもあるので書いてみる。

有名人の訃報で、好きだった人だったりするとガッカリはするけど、まぁそうかと割とすぐ受け入れてきたし、淡泊だけど大抵の人もそうだろうと思ってきたけど、今回のニュースは割と重く感じた。こういう感情もあるんだなという感じ。肉親とかじゃないのにね。多感な中学の時に出会っちゃったとか、その頃から20年以上ずっと憧れとか尊敬しつづけてしまったのがそう重く受け止めさせるんだろうなぁ。

音楽も好きだったし、作り手としての姿勢も好きだったし、その経歴も憧れる存在だった。作曲家としてはそこそこ地位を築いている段階で日本で2番目だかにモーグ個人輸入してシンセサイザーの第一人者となるとか、高齢になった時の作品ですら魅力があるとか、自分もそうありたいと思うような人だったと思う。

まあすごいのはすごいのでそういうのはWikipediaとかでいいよね。

初めて買った冨田勲のCDはドーン・コーラス。中学の時。これが今でも一番好き。

ピックアップ

いくつかピックアップしてみる。楽器はてんで駄目だし音楽を語る語彙もないので、ただだらだらと書き連ねるだけだけど。曲毎にパーマリンクがあれば良いんだろうけど世の中そこまで進んで無いので、試聴が出来るAmazonのCDページへのリンクとしておく(トラックコードを付けてるけどね)。

ドーン・コーラス : ブラジル風バッハ 第4番 ”プレリュード”

ドーンコーラス(暁の合唱)とは、明け方に無線機で受信すると聞こえる可聴域の電磁波だそうで、太陽からの宇宙線が大気と反応して起こる雑音で、朝の鳥のさえずりにも似ているからこのような名前だそうな。冨田勲は若かりし頃に夜明けにラジオで聴いていたそうで、冒頭にこの音が使われている。そのほかの曲もいろいろな宇宙の"音"が使われていて、それぞれ曲としても美しい。

惑星組曲 Ultimate Edition。

ホルストの惑星組曲の編曲。Ultimate Editionとは昔発表したアルバムをさらにリメイクしたもの。おおくの人が知ってる冨田版惑星とは少し違うけど、これはこれでいい

Ultimate Editionには、昔の冨田版惑星に"イトカワはやぶさ"という曲が追加されている。コチコチという時計っぽい音が孤独に歩む探査機はやぶさを連想させて泣けるのだ。

初音ミクとかボーカロイドが出るはるか昔の作品。イートハーブ交響曲という最近の発表曲で初音ミクに歌って貰って話題になったんだけど、これも冒頭曲の"火星"でロケット管制をする宇宙人同士の会話がシンセで作られていて、それも面白い。こういう宇宙人語を作るので昔は限界だったんだろうなぁ。

蒼き狼 チンギス・ハーン ~NHKスペシャル

タイトル通りの音楽。単純に騎馬民族の疾走感があってかっこいい。曲中の歌は実際にモンゴルの人に歌って貰ってるらしい。単体でアルバム出てたんだけど、もう廃盤だし試聴も出来なかった。悲しい。NHKテーマ音楽集にはメインテーマだけ収録されてるので、次の紹介曲のリンク経由で試聴はできる。

街道をゆく ~NHKスペシャル

司馬遼太郎の街道をゆくのNスペのテーマ曲。テレビで見てたとき映像と曲が綺麗すぎて笑った。

学校

山田洋次監督の学校シリーズのサントラ。実は映画と音楽両方好きなのである。

山田洋次の映画に頻繁に冨田勲は参画していて、それぞれ映画の雰囲気にあった曲だけど、山田洋次の映画で冨田勲曲ではこの映画の主題曲が一番すきかな。

ただ、アルバムは廃盤。アカン…。

雪は踊っている

月の光のアルバムの一番最初に収録されてるドビュッシーの曲。元々が幻想的な曲だけど、ホントはこういう音で作ってあったって説明があっても良いんじゃないかと思った。とりあえず、同アルバム中では月の光よりこれが一番好きなのです。アルバムの最初にこの曲にすると印象持ってくよなー。これもUltimate EditionがあるのでリンクはUltimate Editionにしておく。

砂漠の大旋風(カンタータ第36番「喜んで舞い上がれ」より)

バッハファンタジーというアルバムにある曲の一つ。バッハこうしちゃうかーという感じで、アルバム全体でもよい。これも廃盤ぽい。

イートハーブ交響曲

初音ミクとの共演で話題を呼んだあれ。良い曲で、やっぱ冨田勲はすげーよ!!って思った。小並感。

2014-09-21

RubyKaigi 2014 に行ってきた

日記を書くまでがKaigi、とは聞いたこと無いけど、書いておこうという感じで。

子供が熱を出してしまって、妻と交代で看病しながらの参加だったので、全日参加できていない。いやこれは大変で、子持ちのセンパイRubyist達はこういう状況で凄い成果出してるんだと思うとなんというかいやはやどうしようという気になって、RubyKaigiも2ndシーズンらしいけど、個人的にも2ndシーズン感が出てる参加でした。ぬおー。

そんな訳でいつもだと個別の講演について個別に感想書くんだけど、参加しただけでヘトヘトなので、全体の感想で。

聴講したのは全部おもしろかったけど、特におもしろかったのは、HTMでGVL外す話, RubyMotion for Android, ServerEngine, PowerAssert, Fuluend Hacking Guide, 同期メカ, githubのキーノート。The Ruby Challenge は聞けば良かったと後悔した。

とにかく、個別の内容がレベルが凄かった。一つ一つが他を寄せ付けない技術者がもつ技術の個性にあふれていて、ホントに面白かった。便利事例や技術発表ももちろん大変な価値があるけど、そういうのじゃなくてRubyKaigiで聞かないと聞く機会無いんだろうなみたいなのが沢山あってよかった。

卜部さんのツイートがよく表現できてる。

あ、RubyHiroba には結局参加できなかった。STIとmrubyのデバッガの話を聞きたかったんだけどなー。

追記。いつもではあるけど、ジュンク堂はRubyKaigiの支店も(財布的に)やばい。興味ない分野でも本棚を一通り眺めてて、「あ、こんな本あるんだ」ってのを池袋本店で体験すると思うけど、あれがミニマムに再現されてて凄い支出になる。2万円くらいクレジットカード経由で消えた。

2014-08-12

OM-D E-M1 というカメラを買ったよ

買ったよ。オリンパスのミラーレス一眼 OM-D E-M1というの。下の写真右側。

f:id:takeshinoda:20140813003837j:image:w640

今までは上の写真左側の PEN E-P1 というミラーレス一眼を2009年からずっと愛用していた。オリンパスで最初となるミラーレス一眼で、国内メーカーだと3番目になるらしい。

特に不満とかはなかったのだけど、なんだかいろいろ古くなってきた感も否めないので思い切って買い換えてしまった。と、書くと今決めてエイと買った感じだけど、 これの発売以来10ヶ月くらい欲しくて悶々としてた。悶々としすぎて寝てる間に無意識にポチった。という感じ。

使ってみて

とにかくAFが早いし、手ぶれも5軸手ぶれ補正機構(なんか凄い)というものらしくてカメラ弱者のワタクシは大変助かってる。最近、子供が歩き回るようになって、あたふたして撮ってたんだけど、割と落ち着いて撮れるようになった。

前使っていたPENシリーズは宮崎あおいがCMやってるくらいなので、カメラ女子層も取り込めるわりとあっさりしたデザインで、それも気に入って使っていたけど、新しく買った方は割と持ちやすさとかガチ勢を意識してるデザインらしくてゴツゴツして複雑なインターフェースになってる。でも、そのゴツゴツして複雑なインターフェースが凄く使いやすくて意外。PENでオリンパス機に慣れていたというのもあったんだろうけど、意外にすぐに慣れたし、早くも手に馴染む感じがしてきていてとても良い。まぁなんか気持ちが良い。

画質とか。カメラとかレンズについては詳しくないので、どう撮ったらどうだったとかは書けないけど、より綺麗に撮れるようになって満足している。

Amazonにいくよw

2014-06-11

Swift の配列で append すると変数が参照する値まで変わる話のしょぼいメモ

Swift の Array の append の振る舞いが直感に反する的な意味で話題になってて、自分も面白かったので、調べたメモ。

一応注意:調べ方が雑なのでウソ書いてるかもしれないので注意してください。

話題のSwiftコード

var a = [1, 2, 3]
var b = a

println(a) // [1, 2, 3]
println(b) // [1, 2, 3]
a.append(4)
println(a) // [1, 2, 3, 4]
println(b) // [1, 2, 3] <= b はいったい何を見ているんだ…?

Rubyならこうなる。大体のOOPLならこうなると思う。

a = [1, 2, 3]
b = a

p a # => [1, 2, 3]
p b # => [1, 2, 3]
a.push(4)
p a # => [1, 2, 3, 4]
p b # => [1, 2, 3, 4]

append で、破壊せずに新しい配列を作ったからだよって話だけど、変数aが見てるものを勝手にappendが変えても良い訳ないだろと思って調べた。

クラスと構造体

Swiftには インスタンスを定義するものとして Class と Structure と Enumeration があるけど、 Class から生成されたオブジェクトは変数に対して参照を渡すのに対して、 Structure と Enumeration は value type と呼ばれ、変数にアサインされた時点で値を渡すという前提があって、 Swift の Array と Dictionary は Structure で構成されている。

all of the basic types in Swift―integers, floating-point numbers, Booleans, strings, arrays and dictionaries―are value types

副作用のある操作

構造体は変数へのアサインや破壊的操作(副作用のある操作)をやったときにはコピーを作る。仕様的にはメンバ変数を上書きする(副作用を及ぼす)メソッドには mutating というキーワードが必要。

配列の場合は、長さが変わるメソッドを呼んだときにコピーが作成されるので、 append した時点で a と b は違うものを見ている。そして、 value type は自分自身と同じ型ならコピーで自分を書き換えられる(self = と出来る)ので、変数が参照しているオブジェクトを代入無しに書き換えているように見える。ということみたい。

小並感

Cの構造体における代入時の仕様とほとんど同じだけど、mutating があることで副作用を明示的に指定でき、コンパイラのチェックを受けることが出来る。同じ仕組みを普通のオブジェクトに導入してないのが面白い。ネイティブアプリ用の言語だから性能要求や下位レイヤーへの親和性を保たせつつ、OOPLっぽい仕様としたかったのかな。言語仕様業界に詳しくないので分からないけど。

実験

mutating を付けていないところで、メンバ変数を上書きしようとするとコンパイルエラーである。

$ cat kero.swift
struct Aaa {
  var a: Int

  func aaa() {
    self.a = 1
  }
}
$ xcrun swift kero.swift
kero.swift:6:12: error: cannot assign to 'a' in 'self'
    self.a = 1
    ~~~~~~ ^

mutating 付けると通った。

$ cat kero.swift
struct Aaa {
  var a: Int

  mutating func aaa() {
    self.a = 1
  }
}
$ xcrun swift kero.swift

チンプイがワンダユウさんに変身するコードで実験してみた。

struct Chinpui {
  var namae: String

  func name() -> String {
    return self.namae
  }

  mutating func chinpui() {
    self = Chinpui(namae: "wandayu")
  }
}

var dare1 = Chinpui(namae: "chinpui")
var dare2 = dare1
println("dare1: \(dare1.name())")
println("dare2: \(dare2.name())")
dare1.chinpui()
println("dare1: \(dare1.name())")
println("dare2: \(dare2.name())")

実行結果

dare1: chinpui
dare2: chinpui
dare1: wandayu
dare2: chinpui
最終的によく分からない

最終的に配列の要素の修正でコピーが発生しない理由(というか仕様の所在)だけが分からず、深夜になったので終了。[]って特別扱い?

コピー発生のタイミングを知りたいけど、ポインタの取り方か object id の取り方が分からず調べ切れていない。

2014-02-02

退職しました

知り合い向けのエントリなので、「で、誰?*1」という方は、お手数ですがタブをそっ閉じでお願いしますm(__)m。退職エントリ、書いてみたかったんです。

1月末をもって退職し、2月よりリブセンスという会社でお世話になることになりました。

ここからながーい、自分語りが入るので、以下はお時間あれば読んでくださいw。

前職について

所属企業名はググればすぐにわかりますが、ここではあえて大きめのSIerとしておきます。

2003年に新卒で入社したので丸10年以上勤めていたことになります。

何年だか忘れましたが、人間の場合、神経細胞など一部を除いて一桁年数で多くの細胞は入れ替わると聞いています。「ってことは、俺の体はほとんど前職のお給金でできあがってる訳だなぁ」という、「まずは感謝」みたいな妙な感覚があります。

新卒以来、ずっと技術支援部隊所属で、現場では支援という形でプロジェクトに参画することがほとんどでした。一時期総合技術研究所などにも所属してましたが、支援の割合が減っただけで同じようなもんでした。

業界やお客様に付いている訳ではないので、金融や流通、製造、エネルギーなどいろんな業界を見ることができたのが、私にとっては面白かったです。ただし、長くても2年ほどしか留まらなかったので、浅いところしか見れないわけですが、ただただ受託だSIだと言っても、それを指す内容は人それぞれ違いが大きく、あるのはただただその現場のみってのは感じるところでした。

愚痴や不満はたくさんありましたが、主張さえすればいろんな経験をさせてもらえると言う点でとてもよい会社だったと思います。他のSIer勤務の人と会話してみると、お堅いお仕事が多い割に、割と自由にさせてもらえてえるし、稼働率を平準化しないといけない業種の割に人事上の配慮もされてる方だったと思います。嫌な上司には会ったことがないですし(これは運もあるだろうけど)。

ポツポツと強力な個性と技術力をもった人が社内にはいるのですが、そういうところがあったからだと思います。そこが強みでもあり、弱みでもある会社なんですが。

アジャイルとかRubyとかエンタープライズとか

比較的自由に出来ると言っても無理がある事をやってきたというのが正直なところです。

エンプラとかSIとかって、上で書いたようにその人の経験や、やってる領域が背景にあって語り出すみたいなところがあるので、そういった人たちにただ説明するという段階(説得とか関係なしに)からしてなかなか難しかったです。技術的なところだとJavaをおもちゃって言い出す人とかUNIXをおもちゃって言い出す人がいると思ったら、反対にJava以外はおもちゃって言う人も当然いて、それが同じ社内で共存しています。(自然に言い出す人はそれなりに面白いからいいんですけど、戦略的に言う人は面倒くさい。まぁこれはいい。)

それなりに大きな会社だったので、やってる仕事はものすごい多種多様なのに、「少ない種類の技術ややり方に統一していって、人の交換性を高めて稼働率の平準化と開発効率化」みたいな流れがあります。なんか、なんかだなーという気分でした。

そうすることでプロジェクトの数をこなして売り上げをあげる。多分どこでもそうでしょうし、受託開発のビジネスモデル下では正しいと思います。そういった慣習が生み出すゆがみが社会や顧客にとってどうかという批判は多くありますが、依頼してお金を払う人が数兆円規模で存在する市場である限り、なにかのあるべき論だけで語る以上の意義があるとは思いますし、実際のところ生活のいろんな場面でその成果のお世話になっています。生活のいろんな場面でお世話になってる。これ大事。

が、ちょっと極端すぎる気がしていて、エンプラ市場での何かの価値を提供するというのは、何もSIによる受託やパッケージだけではなくて、SaaSやその前のASPやSFDCみたいなPaaSの流行を見るまでもなく、技術がコモディティ化してるなかでやり方も多様化していると思いますし、多様化しないと社会に貢献できなくなってきたというのはもう当たり前になっていると思います。

卑近な例だと、利用しないといけない大企業のサービスのWebページだけはなんかイケてない社内ページみたいだし、融通もきかないけど、大資本がやらざるを得ないサービスだから代替が無いという体験って時々あると思いますが、そういうのも含めていろいろみんなで損しているとか。一方で実は資本はそう要らんかったんや的にそれらを突き崩すアイディアがどんどん出てきている。いいサービス出すクラスタとイケてないサービス出すクラスタが分断されるきらいがある。もちろんビジネスモデルのせいだけにするにはいかないけど、状況がディフェンシブな開発を誘発し、その結果がイケてないというからくりはあると思います。

そういうのって、ただSIerイケてないとかいつまでもしょうもないページ使わされるとかエクセルだ(とばっちり?)とかdisるだけじゃつまんないというか、disるならその素敵な理想論でdisの対象から仕事をとればいいじゃないとは思っています(出来てたかは別だけどorz)。まぁ幸か不幸かdisの対象になりがちな場所に自分がいるので、ちょっと変えられるか試してみようかと思えば出来るわけです。だから面白いところもあったし、それを上回るくらいのしんどいことも沢山ありました。

なんやかんやで、なんかそういうの言い出していきなりプロダクション出せるレベルのチームを作るのは無理なので、数年かけてというのは最初から考えてることでした。流石に会社を変えようとか社会を変えようとは思ってなかったですが、自分の仕事の範囲くらいは変えたいと思ってやってきて、それなりに出来たかなと感じています。ここ1年くらいは何も宣伝してないところから問い合わせが来るなどしてきて、周辺事情も変わってきたのかなぁと思います。対外的にはRubyWorld Conference 2012*2とか大江戸Ruby会議03*3で発表してきたような思いでやってて、発表自体もできたのがいい思い出です。

ともかくも、上司その上の人や一緒にやってくれた同僚や後輩のおかげでやってこれました。なんだかんだで難しい状況だと認識してる人は多く、理解してくれる人がたくさんいてほんとうれしかったです。ご迷惑ばかりだった気もします。ただ感謝です。

これから

RWC・大江戸Ruby会議とかで発表したようなタクシーもやってて楽しかったですし、違うアイディアでなんとかしてやろう、みたいなことを最初からやってる人たちと仕事をしてみたいと思って転職をきめました。次の会社のメッセージの「あたりまえを、発明しよう」というのがどんなことかは入ってみないとわからないかもしれませんが、賛同できることでもありました。

これからはもっと、なんかイケてないサービスなりを作っちゃう人たちとなんかわかってる人たちってのが分かれてくると思います。エンプラでやってる人やってない人という区切りは意味あるのかな、その辺はわからないです。これまで「オープン化の流れ」とかそういったわかりやすい「流れ」が今までいろいろありましたけど、だんだん流れの幅が狭いバズワードになってきてる気がしてて、こうなるともう割と塹壕戦で、わかってる人みたいになるには地道に学び続ける必要がある。

「それって基幹系でも同じ考えなの」みたいな返しがある業界にいましたが、どうなんでしょうかね(基幹系って何ってのはあるけど)。数年は変わんないでしょうけど、十数年後はどうなんでしょうかね代替は無いとは思いますが、何かに溶け込んでいくのではとは思います。なにかわかんないですけどw。

要するに

とりとめなく書きましたが、これからもがんばります。よろしくお願いいたします。