2013年12月2日月曜日

マンガ・アニメの登場人物の収入源が気になる(ったので憶測してみた)

最近、このブログのカバーにも使ってるジョジョのアニメ放送をも一回見直してるんだけど(自分はやっぱり2部が一番好きっす。もはや少数派だけど。ジョジョの好きな部って世代でもわかれるんじゃないかな)、ふと「ジョセフってそもそもなにやってたんだ?」ってのが気になった。たしか2部時点で二十歳ぐらいだったはずとおもってぐぐったらどうやら18歳ぽい。ぎりぎり高校生ってことか。でもシーザーは?二十歳って書いあるんで学校は卒業してるし、大学いってそうもないし。
リサリサは?かなり優雅な生活してるけど?

最近新しいマンガにはあまり手をだしてないんだけど、自分が読んでた80年〜90年代のいわゆるヒーロー、少年向けマンガの登場人物ってそういやなにして食ってんのかわかんない(なかったなー)と思いはじめた。見たり読んだりしてた当時(中、高校生)は気にもしなかったんだけど。さすがにいい年で、子供もいてってことで目線が現実的になるんですな。。

まあ、そういう世俗的なものからかけ離れている純粋ヒーローものとかには愚問なんだけど、ジョジョとか設定自体は現実社会なぞらえてるし、余計気になる。

基本的に戦いものは、マンガのタイムライン中は「常にだれかのサポートのもとわるものと戦ってる」ので、働いてる暇はない(必要がない)ってのが基本筋だけど、いわゆる幼児向けでなくて設定が現実的なものについて、登場人物(主人公)の収入源が不明なものを憶測してみた。

下調べなしで記憶だけで書いてるので情報不足だったりまちがってたらごめんなさい。


ジョジョの奇妙な冒険
1部ジョナサンは設定が大学生、その後ジョースター家跡取りとして事業家とか(の前のハネムーンで死んじゃうけど)かな。

ジョセフは18歳でNYに移住だから、それまでイギリスの高校行ってて、引っ越して来てぶらぶらしてるときに2部開始てことかな。2部後は不動産で一儲け。

3部、4部は高校生、5部は既にマフィア、6部は既に服役者でそのまま世界変わってパラレルワールド、7部以降はちゃんと読んでなくてわからん。

こう考えると、ジョジョ自体の設定はちゃんとしてるぽいが、不明なのがツエッペリおじさんと孫シーザー、リサリサあたり。 リサリサはSW財団が身元消してるから、そのお金で隠匿生活(波紋教室とかぜったい無理そうだし)として、ツエッペリ一族は両方とも働いている姿が想像できん。。おじさんのほうは昔船乗りだったみたいだけど、ジョナサンにあった時なにやってたんだろう? 波紋で手品してまわってたとか?
シーザーはワルから改心してすぐリサリサに入門して、そのまま食わせてもらったてたか、各地の女のヒモになってたか。(本人はヒモでなくて奉仕だと思ってそうだけど)
なんか両者とも根はいい人だけど、社会人として見た時はちゃんとした印象がない。。

ドラゴンボール
初期は基本冒険してて、ブルマが金持ちでブルマに養ってもらってる感じだけど、チチと結婚後の悟空って何やって家族やしなってたんだろ?ほとんど戦ってるか修行してるから職歴ゼロぽいけど、チチがせっせとはらいて子供やしなってたのかなー。そりゃ小言増えるわー。

あと、ヤムチャ、クリリン、亀仙人とか、年はリアルにとっていくけど、なにして食ってたんだ?(作中触れられてたっけ?)

その他意外と想像つくもの

ゲゲゲの鬼太郎
無職で、虫とか拾って食ってる。

キン肉マン
初期の巨大化して怪獣退治の時はわからんが、(公園に住んでたのでほぼホームレス?)
人気ではじめたあとはずっとプロレスしてるんでファイトマネー?

北斗の拳
世紀末で貨幣価値がなくなってるので職業自体ほぼ無価値。盗るかもらうか交換か。

なんか挙げてる漫画で年がだいたいばれるな。。。

2013年10月21日月曜日

怖くないScala勉強会で発表してきました(スライドまとめ)

先日、株式会社DTSさんで「怖くないScala勉強会」という勉強会で発表させていただきました。

connpass
http://connpass.com/event/3420/

USTREAM
http://www.ustream.tv/recorded/39973316

まとめ
https://yukar.in/note/ckFiLF

もうなんかすでに発表者の方や来場者の方がたくさんまとめられているので、まとめとしてはあまり意味ないかもですが、とりあえずリンクあつめたいので書いときます。

 わたしの発表はこれ。

前日夕方から、途中specのまとめ再放送全部観てしまうという失態をのりこえて寝ないで書いてそのまま発表、打ち上げは終電近くまで参加と、おっさんらしからぬ暴挙に出てしまいましたが、なんとか無事終わりました。

感想
一言でいうと、とってもいい勉強会、発表だったと思います。内容がすごく実践的であるのにおもしろいという前半の発表と、大爆笑をさらった後半のLTがいいバランスで退屈しない、いい雰囲気の勉強会だったと思います。

これもひとえに、ぼく以外のプレゼンターの方の話力と内容のたまものと、主催者の方の頑張りのおかげかと思います。

個人的に印象的だったのは、色んな方が触れられていますが、@teppei_tosaさんの
「Scala稟議の通し方」(プレゼン中に別のスライドで架空のプレゼンを始めるという斬新さ!)、@mumoshuさんの「ScalaとUnityをつなぐ方法」(こちらは逆で初めみていたスライドが実はUnity上の3Dゲーム空間のボックスの中に映されていたものだった!という世にも奇妙的アプローチ?)です。

そして、やはり100人近くの勉強会を食事+お酒+UST中継付きでがんばって運営された@garbagetownさんとDTSさんのボランティアスタッフさんです。

登壇者とスタッフの方とは打ち上げまで一緒にさせていただきましたが、DTSの皆さんはとても賢そうなのに謙虚で、大したことないのにすぐに調子にのってしまう自分とは正反対でとてもまぶしかったです。運営の様子は、garbagetownさんご本人がブログにまとめられているのでぜひご覧になってください。
怖くないScala勉強会を開催しました-garbagetown

これを見るとやはり勉強会のドタキャンはいけませんね。。特にダマのやつは。
(実は数日前のHTTP2のやついけなくなってドタキャンしてしまったんですが。。)

次回もし機会があれば、ちょっとしたお手伝いとかもうちょっとテキテキしたLTなんぞやらせていただければと思います。(今回どっちかというと後半根性論ぽい話になってちょっと怖くなってたかもなんで)

あと、今回USTREAMの録画見ましたが、自分の話し方の反省にもなっていいですね。
自分は話しもチャットも「まあ」が多すぎるので、「まあ」禁止令を自分に課したいと思います。

以下全部ではないですが、ピックアップできた登壇者の方(LT含む)のスライドです。

「Scala陰陽術!こわくない型の話」
 https://docs.google.com/presentation/d/1H-cUi2GdBmFE8kBoaf6eogJU0IjafpNDLLaxu3C9CZw/present#slide=id.p

「Scala稟議の通し方」
 http://www.slideshare.net/ironpeace/scala-27368882

「Scalaを扱った2年間のよもやま話」
http://www.slideshare.net/daiksy/scala-27374463

「めんどくさくないScala」
http://www.slideshare.net/seratch/kwkni-scala

「SIerでScalaを使うために私がしたこと」
http://www.slideshare.net/takezoe/s-ierscala

「Heroku Addon BounscaleでPlay2/Scalaをオートスケールする」
http://www.slideshare.net/mobile/shoutaaaaaaaaaa/heroku-addon-bounscaleplay2scala

「最高のScalaコンパイラにしようぜ」
 https://dl.dropboxusercontent.com/u/36583594/outsource/saikoNoScalaCompiler/assets/fallback/index.html

「最高のコンパイルにしようぜ」
 http://tototoshi.github.io/slides/kwkni-scala-best-compiling-ever/

「Finagleを使ってMVCフレームワークを作ってみました的なお話」
 http://prezi.com/zwkwg0ml4d7d/finaglemvc/?utm_campaign=share&utm_medium=copy

「SIerでScalaを使うために私がしたこと」@takezoenさん
「ScalaとUnityをつなぐ方法」@mumoshuさん
のを探しております。。

takezoenさんのはリンク教えていただきました!

mumoshuさんのは厳しいかな。。






2013年6月14日金曜日

sbt-Play parallelExecution in test と parallelExecution in Test がscctで致命的に挙動が違って泣きそうなので調べてみた

こちらのブログ http://ikeike443.hatenablog.com/entry/2012/12/10/000000
(ちなみに元上司です、今は某球団持ってる会社さんにいらっしゃいます)
にあるとおり、 playやsbtのテスト(実体同じだけど)で並列化を止めるためには

parallelExecution in test := false

がBuild.scalaに必要なのですが、ネットの情報やPlayのドキュメントみると

parallelExecution in Test := false
が正しいのかなと思い、

 http://www.playframework.com/documentation/2.0.3/SBTSettings


一文字だけ直してローカルでplay test してOkでPullRequest出して
いざJenkinsでテスト実行してって、やれやれ、、と思ってたら

テストこけてるー!

なんでやねん、ってみてみたらplay test はOKだけど、 カバレージとるための
scct:test でこけてるみたいす。

しかもなんかド派手というか、ぐちゃぐちゃなこけかた。

で、 ローカルでためしてみるとやっぱりこける。。

このプロジェクトにはScct系の設定いれてないし、変えてもないんで気にしてなかったけど、どうやら「test」と「Test」の違いが、scct:testに影響してるみたいです。

再現率100%で test だとOK、 Testだと失敗。

まあ、 戻せばとりあえずいいんだけど、 別のプロジェクトでやはりscct:testがうまく動いてないので、色々試してみました。


parallelExecution in test := false  -> OK
parallelExecution in Test := false  -> Failure
//parallelExecution in test := false (コメント化) -> Failure
parallelExecution in test := true  -> Failure
parallelExecution in Test := true  -> Failure

ってことで test := false しか成功しないんですけど、うーんてなってたら
同じチームの同僚が下記のsbtのリンク教えてくれて

http://www.scala-sbt.org/release/docs/Detailed-Topics/Testing

よくよむと、

scala parallelExecution in Test := false Test can be replaced with IntegrationTest to only execute integration tests serially. Note that tests from different projects may still execute concurrently.
とか、書いてあって、 it:test のテストだけ直列化するぽい。。

だから、 全部のテスト直列化には in test が正解なのか。


※ちなみに、 sbtのソースコード自体のテストは in test ってなってるみたいです。

でも、 とにかく紛らわしいです。。。

ちなみに、 うまくいかないほうのプロジェクトは

parallelExecution in Scct := false
parallelExecution in ScctTest := false

つけてもダメ。 

ていうか、 play test 自体は

parallelExecution in test := true

でもとおちゃうんだよなー。

とかおもってるんと、そういえば、強制的に並列実行阻止するため、
def running[T](fakeApp: FakeApplication)(block: => T): T = {
    synchronized {
      try {
        Play.start(fakeApp)
        block
      } finally {
        Play.stop()
        play.core.Invoker.system.shutdown()
        play.core.Invoker.uninit()
      }
    }
  }

みたいなoverride他のメンバーがいれてるんだった。

あれ、じゃあそもそも並列実行しないはずじゃ。と思って、このoverride外して
parallelExecution in test := true

とかにするとテストこけた。

逆にいうと、 runningつかってるとこは排他きいてるってことか。

scct:compileでなにかコードがつけたされて挙動がかわってるのかな?


うーん、 結局もやもやのままだなー。 どっかで腰すえてやんないとわけわからん。

2013年5月23日木曜日

EclipseでScalaを快適にするおまじない(StackOverFlowの対処)

JavaでもヒープサイズやPermサイズとかはよくチューニングするけど、ScalaでEclipseが遅い、固まる、StackOverFlowがちょくちょく出てうざいって人は

-Xss1m

をeclipse.iniにつけるだけでも解消される。

ちなみに自分の設定はこんな感じ。


-vmargs
#-server
-Xms1512m
-Xmx2048m
-Xss1m
#-XX:MaxPermSize=256m
#-XX:PermSize=256m

-serverとかはEclipseよりもScala(Play)コンパイルまたは実行環境のほうにつかたほうがいいのかも。

PermSizeはデフォルトで足りそうなので、コメントアウトしている。


色々試して効果があきらかなものだけ残して後はでデフォルトに戻すってのが設定いじる時のルールにしてます。

2013年4月19日金曜日

Play framework Enumerator.fromFile とjava.io.File.delete の不思議

ファイルをレスポンスとして送信する処理で、一時ファイルとしてサーバーに作成し、送る前にコンテンツを読み込んで削除するってコードを書いたんだけど、(以下)


val fileContent: Enumerator[Array[Byte]] = Enumerator.fromFile(file)
val size = file.length.toString
file.delete // (1) THE FILE IS TEMPORARY SO SHOULD BE DELETED 
SimpleResult(
 header = ResponseHeader(200, Map(CONTENT_LENGTH -> size, CONTENT_TYPE -> "application/pdf")),
 body = fileContent)
fromFileってcallbackをwrapしてchunkごとにファイル読み込むから、ファイルの内容すぐにロードしなくて、実際はおくるときにbufferしてるから、先にfile.deleteするとおくれないんじゃないかって疑問わいてきて、「ひょっとしたらjava.File.deleteが待ってる?」って憶測をStackOverFlowとPlayのグループに質問したら、
多分そうなんじゃないかということなんだけど、 本当かなー? 
久々にJavaのソース読んでみるか。
fromFileはinputstreamqを中で生成してるけど、 生成しただけでFPってつかまれるんだっけな?
あと、File.deleteが非同期でエラーもはかず待つってのもうそくさいし、やっぱりfromFile時点でコンテンツロードされてて、 Resultの時にクライアントにstream送信されてるだけぽいけど、Enumeratorのコードざっとよんだかぎり、やっぱりResult時にファイル読んでる気もするし、、、うーん。
Javaのコード読んだら、追記しよう。

2013年4月9日火曜日

Scala Seq(List) 便利メソッドメモ

こちらのブログで知った
http://d.hatena.ne.jp/sudix/20110217/1297928331

zipIndex

添字付きでごにょにょしたいときに便利。

こういうのあるからScalaいいなと思ってしまう。

そしてまだまだだな自分。


自分にとっての格言とは

気がつけばインターネットで膨大な量の情報を取得しはじめて久しく経つが(自分の場合、ほぼ社会人生活の長さと一致する)、実はそういった情報過多生活、そして職業エンジニアとしての多忙な日々を生き抜く上でいつも頭の片隅にある言葉がある。

いつどこで言われたかは定かでないが、もう15年ぐらいは前に、どこかのTV番組で教授こと坂本龍一さんがインタビュアーに向かって言われた言葉。
 (以下うる覚えだが確かこんなやりとりだった)

聞き手「どのように(そうやって新しい膨大な)情報を吸収されているのですか?」
教授「どの情報を耳にいれないかを常に考えていますね

「今の時代勝手にほしくもない情報が入って来るので、いかに無駄な情報に脳みそをうばわれないかを考えています」

もはやうるおぼえなので、発言自体は全く違ったものだったかもしれないが、今でもそのときのTV画面と共にこの発言が頭に残っている。特に予定して見た番組でもなく、なんとなくつけたTVでたまたまとびこんできた内容だったと思う。そして自分は坂本さんはすごいとは思うが特にファンとかそういうわけでもない。(YMOもすごいと思うがそれよりPerfumeのほうが好きだ)

これって今でいうキュレーションの発想なんだけども、なぜかそれ以降こころの奥にささって自分のエンジニアキャリアのヒントのひとつになっている。

そう、ITの進歩で人間は情報発信について格段にその量を増やし、内容も充実したかにみえるが、吸収する人間自体の肉体の進化は古代からそれほど進んでいない。
(これは「ウェブはグループで進化する」 の中で述べられてる表現を拝借した)

タダでもしくは安価に大量に発信でるようになったoutputとしての情報にくらべ、自分の脳みそで吸収できるinputとしての情報は希少価値なのだ。

吸収に限界がある脳を未熟ととらえ、ひたすら多くの情報を得ようとするか、脳みそのキャパを貴重な場所としてとらえ、そこに入れる情報を常に吟味するかで仕事や学習の仕方が大分かわってくるように思う。

自分の場合、「何が本質的に重要か」「何が後回しでいいか」「何が人に譲っていいことか」「本当にやりたいことは何か」などを考えて、やること、やらないこと(例えば覚える業務や技術の内容、読む本、読まない本を決めるなど)をばっさりわけることで、自分の能力より少し上の評価を得て来たと思う。自分では地頭はそれほどよくないと思っている。

逆に自分よりはるかに頭はいいだろうと思う人が以外と結果を残せてなかったり、評価が低いのを見うけると、この脳みそバランスがうまくできてないのかなと思う。
つまり、なまじ頭がいいので、全部を飲み込み消化しようとする人。(頭よくなくてもやる人もいるが)

こういった感じで、自分には「本当の意味や詳しいことは知らないがなんとなく頭に残っててそれを自分流に解釈して生きるヒントにしている言葉」があり、それを勝手に格言と呼んでいる。

で、自分の限りある一次記憶装置の内容を適切に二次記憶から置き換えてきたことで高スペックでないCPUを活用できてきたように思う。

まあ、この考え方には自分のスペックを低く見積もりすぎたり、成長や衰退を考慮しないといった落とし穴もあるのだが。

ちなみに、他にもいくつかそういう自分にとってもヒント的な格言があるのだが、いますぐ思い出せない。 ヒントなので、その局面に来た時あたまのどこかからにょきっと顔を出すんだろう。

















Heroku Meetupに参加してきました

こないだのサンフランシスコ出張で参加したWAZAカンファレンスの発表もちょっくらしてきました。
内容はほとんど会社のブログに書いちゃった。。
(最近このパターン多いな)

2013年3月12日火曜日

サンフランシスコに行ってきました

会社の出張で一週間ほどサンフランシスコに行ってきました。
目的はカンファレンスに参加するため。
(出張の内容については、会社のブログに書いてあるので興味のある方ぜひ)

ここではどっちかと言うと旅行記としてメモ書き。

・食べ物、結構うまい。かに、えび、牡蠣は魚嫌いの人でもたべれるように調理してある

 ・横断歩道の信号のカウントダウンは日本にもあればいいと思った。(点滅だけだとあと何秒で赤になるかわからん)

・勝手にあったかいとことおもってたけど、そうでもない。夜結構冷える。

・路面電車がアトラクションぽくて、広島出身の自分としてはちょっと負けた気がした。

・ワイン、コーヒーとかの嗜好品は安くてうまい。

・地下鉄、バス、徒歩、チャリとかでほぼどこでも観光できる。

・人は結構親切、治安はよいほう。(もちろん危険なところもあるが)

次はプライベートでもうちょっとゆっくり観光したい。ゴールデンゲートも行ってないし、ナパのワイナリーも見たい。

2013年1月4日金曜日

sbtの依存解決エラーを直接jarファイル指定で解決する方法

こないだ社内mavenのpomがsbt(実際にはivy)でちゃんと読めず(${}変数をversionに指定した場合変数として扱ってくれないみたい)依存解決エラーが出た場合の対処法。

build.sbtに、
libraryDependencies ++= Seq(
...
"Hoge" % "HogeCommon" % "1.0" from "http://hoge.com/....hoge.jar"


 と、末尾にfromでjarを指定すると、問答無用でjarをダウンロードしてくれます。

以外と知られてないのではと思い備忘録に。

(まあ、ダウンロードするjarが分かってるわけだし、ある意味依存解決無視なんでsbt使ってる意味なくなるけど、とりあえずsbtのエラーなくしたい場合にってことで)

参考URL:(後半、この件に関するmavenのバグについてのリンクもあるので
ご興味あるかたぜひ)
http://dwins.wordpress.com/2011/10/15/workaround-sbtmaven-inconsistent-module-descriptor/