Kousei Ikeda/Blog

2018.01.01/Daydreaming

brxxto-495155

あけましておめでとう。あっというまに1年が終わって、また1年が始まるよ。毎年、本当に早い。早すぎて怖くなるくらい。

しばらく会ってないけど調子どう?そっちは寒そう、雪が多いしね。雪には慣れたかな。寒がりで、いつも温かい所にいたよね。その才能は抜群だったな。日向で無防備にうとうとしてる姿はいつもキュートで、シャッターチャンスを狙ってたのを覚えてるな。今でもあんな風に寝てるのかな。

年々時間が経つのが早くなると、ひとは言うけれど。それは体験したもののうち、記憶に残る割合がどんどん少なくなるからなんだって。それでいうとお互い随分年を経て、歳も取ったもんだよね。今はもう何歳になったんだろう。

はじめて会った時のこと。今でも覚えているよ。きみはずいぶん疲れていて、元気がなかった。少し痩せてもいたね。それからきちんと食事をして、暖かくして、そして日が経つにつれてみるみる良くなっていったね。あれからもう10年。家族とは仲良くできてるかな。子供はいないんだっけね。

あ、もう時間だ。それじゃ、元気で。またね。

2017.11.29/Works
アートボード 1

株式会社闇と一緒に、漫画×ホラー×株&仮想通貨なウェブサイトを作りました!TD+Prを担当しました。

今回は、恒例メンバーに加え Keiko Hakuiと 西垣 香須美 (Kasumi Nishigaki)ら新戦力の天才アルバイター達が。彼らの働きとそれにあわせた設計で、地味に過去最多くらいの膨大な演出箇所を消化できた。そういう意味ではスケジュール/要件/やりたいことにあわせてリソースを最大化する設計ができたんじゃないかなと。いやでもほんとにふたりとも飲み込み早いし出来が良くてさすが。

技術的にも過去の闇案件の知見のメンバー内での蓄積から、普通ならやらない判断だろみたいな土壇場で「やったほうがクオリティ上がるからやる」判断ができたポイントも。外側もコードも全く新規なんだけど、知見としてはなんとなく元気玉みたいなイメージを感じてる。もしくは合体ロボ的な。
でまあギリギリで、この実装やったほうがおもしろいけどやるかやらないか…まあやるか、やれるでしょ、やろう!とチームがアクセル踏む瞬間。

やらない判断もありなんだけど、もしやれなくても巻き戻して成り立つっていう冷静な判断を片手に持っておきつつもう片手には、自分には絶対にそれができるしそしてやるべきだという確信を持って臨むということ。そのバランスだよね。

他人からは全くわからなくても思い出すと胸が熱くなって鼻がツンとするような、そんなエキサイティングな瞬間。そういうの存在するよね。

もちろん、ギリギリをGOに倒すか否かは案件の性質と目的や効果によると思うし。そこは適切に判断すべきだししてるつもり。ギャンブルじゃなく、リスクをとるということ。

プログラマとしての密やかな喜びとしては、コードの設計が上手く行ったなっていうのが結構あって。仕様の追加変更に対して大規模な構造変更をほぼ伴わずに対応できたかなと。こういうのってプログラマにしかわかんないと思うけど地味に結構嬉しいもの、だよね。
一方でもちろん課題も新たに感じていて。

裏側で下支えする感じにまわったのでモーションのコードもっと書きたかったなとか、もっとシェーダー書きたいとか。最近映像制作リソースが充実してきたことに端を発するプリレンダリングの映像を制御した演出とリアルタイム/インタラクティブ演出の使い分けに関する考察とか。ボリュームのほうにエネルギー持っていかれたかなぁ、より大きいものがより良いものだとは限らないよ?とか。要所要所でもっと良い判断ができたんじゃないかとか、、、。
まあ個人レビューでは課題に枚挙のいとまはないものだよね。

あと表題のネタね。
この案件の納品日のまさに翌朝、起きたら右手がなんかおかしいのよ。キーボード打てないのね。過去に闇V2を作った時に突発性難聴になったことがあったんだけど、今回は撓骨神経麻痺になって利き手が麻痺してキーボード打てなくて過去最高に焦った、みたいな。納品終わるまでならないとかどんだけ優秀な労働者なんだ、と思いつつ、他にも案件あったからすぐ医者2件行って。1週間〜2週間くらいっていわれてこれはやばいと思い速攻で外注リソースの確保に奔走したけど何故か翌日寝て起きたら治ったからセーフ。
健康だからすぐなおったのか。医者に脅されたのか。それとも忙しいから一番すごい薬下さいって言ったのがよかったのか。まあ治療法で急に治る類ではないと言われてたけど。
この話をすると不健康さをよく心配されるけど、呪いでも内部疾患でもなくて疲れて変な場所で寝てしまった外因性らしく、酔っぱらいとかは電車に乗ってるだけでなったりするときもあるらしい。どんな健康な人でもなるときはなるらしいから、硬くて尖った物の上で寝ないことをオススメします!
まあおいといて、とりあえず、知見の元気玉みたいな感じだったし次は全然違うことやろうかな。全然違うことしよう。

ともあれありがとうございました!

KOWAKABU | Archive | Kousei Ikeda http://ikekou.jp/archive/2017/10/kowakabu/

2017.11.26/Note
green-chameleon-21532

ブログはいつしか気軽に投稿する場所じゃなくなってしまって、かといって技術的Tipsを書く場所でもなくなって、用途が見えなくなってしまった。もう一度用途を探してみようと思う。

書くというのは話すこと、次に絵を描くこと、その次に身体に寄った行為かなと思う。ただ、勉強をしようとしたら机を整理したくなるもので、文章を書こうとしたらどこに書こうか、と悩んでしまうもの。ただ書けば良いんだけどね。

Mediumがいいのかnoteがいいのか問題。またははてなブログなのか問題。

タスク実行の最小単位時間を15分と設定しているので、とりあえず15分間だけと決めて書くというのはどうだろう?900秒だ。900秒あったら何ができるだろう。何が書けるだろう。

プログラミングは仕事としてやってきているけど、なかなか文章を書くというほどには自由ではない。@yugopのように、絵筆のように扱うにはまだまだ修行が足りないなぁ。

何の話だっけ。あ、ヘッダ画像探さなきゃ。

2017.07.13/Event, Works

og

いよいよ明日、7/14からスタート。毎年夏恒例な株式会社闇で、MBSさん&NTTさんでご一緒させて頂いてるMBSお化け屋敷プロジェクト、今年はひらパーでやります!

着ぐるみとか人形ってなんとなく怖い、、、そんな恐怖を主題に、長年ひらパーにあって今年4月にクローズした「ファンタジーキャッスル」を題材に「呪いきぐるみギギ」というひとつの世界観で昼と夜で全く別で2つのお化け屋敷なんです。

ほんとに長年使ってた人形ならではのホコリとか汚れとかほんともうすごいいい感じで、こんな機会はもうそうないだろなぁと。

演出はさすがのお化け屋敷プロデューサー五味さん。「ここで来る」ってわかってても声でちゃう怖さです。

昼は屋内で、例年の梅田お化け屋敷の数倍の圧倒的ボリュームで楽しめるお化け屋敷。ついこないだまで光のあたる場所で人とともにいた人形たちが終わりの時を迎えて暗闇に佇む姿はいますぐに付喪神になって動き出しそうでもうむっちゃ怖い。

夜は夜で、閉園後の暗いひらパー全域を使った屋外型お化け屋敷。こちらも同じくファンタジーキャッスルの人形たちが出迎えてくれて、ひらパー全体が、いいようのない恐怖に包まれます。ほんでまあ普通に、閉園後の遊園地を歩き回れるまわれるってだけでまずないレア体験で、不思議でキレイで楽しいし、普段は怖いのが苦手だからお化け屋敷とか行かないわ〜って方も、楽しんでもらえる感じがしてます。行かないと勿体無いです。

個人的には呪い着ぐるみのギギがだんだん可愛く見えてきてます。ストーリー含めてかなり魅力的なキャラクター。グッズ発売したら欲しい。

夜のほうはチーム参加なので4人一組(または5人)で申し込んでね、っていうのが若干ありますが、そこはご友人と連れ立っていただいて、ぜひに昼夜ともに遊びに行ってみて頂けると嬉しいです!

お化け屋敷xホラーナイトツアー ひらパーの怖い夏

2017.06.04/Works

20170525-DSC_5215

JavaScriptを題材に、オブジェクト指向プログラミングの入門講座の講師をした。お声がけいただいたのは京都の制作会社三社、有限会社アーキテクトタイタンさん、株式会社おいかぜさん、株式会社翠灯舎さん。場所は株式会社おいかぜさんのoikazeCUBE。

さて、JSでOOPを扱うということになり、当初の自分の想像以上にかなり内容をまとめるのに苦労した。普段自分が業務で書く分には特に問題ない程度に使っている使えていると思っている部分も、教えるとなるとやはりいったん復習。あらためて調べ直しはじめると、とにかく(少なくともES5までは)言語レベルで定まった書き方がないため特にクラスや継承まわりが「良くみかけるこの書き方はここがダメだ、俺の考える正しい書き方はこれだ」という記事が、知ってはいたが星の数ほど出て来る。いや、星の数ほどは言い過ぎだけど。

こりゃあかんやっぱ本だ、と思ってオライリーのJS関係の本もわさっと買ってあらためて目を通したが、それぞれ微妙に否定し合う部分もあったりして、自分では困らないレベルに普段ある書き方に定めて書けているとしてもどれを「正しい」と教えてよいのかかなり悩んだ。というか、どの書き方もそれぞれにメリット/デメリットがあってそれゆえに多様な意見があるのだとおもうし、でなければそろそろたった1つの方法に収斂していてもよいはずだし。とにかくあらためて初学者にはこれはかなりつらいのではないか、と思った。

クラスベースの言語じゃないと言われつつ糖衣構文としてclassキーワードが使えるようになったり、やっと導入されたそのclassキーワードすら、導入は失敗だった、これは使うべきではない、と書いてある本も見かけた気がするし、「classキーワードを使うやつと同じプロジェクトに入るのは俺はまっぴらごめんだ!」なんて言ってる方もいたし、初学者が色々調べたら調べるほどに完全に混乱すると思う。というか自分も今回あらためて調べまくって一時的にかなり教え方に悩んだ。

とはいえ、色々な情報をわ〜っと自分の中に入れて今回の講座向けにどうしようか考えをまとめたところ、いろんな書き方を都度試行錯誤して自分なりの究極の書き方をトリッキーに実現するより、もうみんなそろそろES6で書いてclassキーワード使うのでいいんじゃないかな、究極のJSマスターからするとclassキーワードを使うのはベストな方法ではないかもしれないけど、みんなが読んで理解しやすくコードがシンプルになるという意味でのコストメリットも考えると、それなりの場面でそれ(classキーワードを使う)でいいんじゃないかな、っていうもともとの思考に一周して戻った。

それにそもそも本講座の目的自体がどちらかというとOOPをしようとするということはどういうことか?という思考の指針を初学者に示してあげることだと考えていたから、JSの高度な書き方のテクニックの部分にあまり余計な気を取られたくなかったので、とにかく今回はシンプルにclassとextendsを使うことにした。今日はES6でclassキーワード使うけど、案件によってはBabelを入れれないものもあると思うしということでES5での最も基本的な気がする書き方への変換も示しつつ。

結果として狙いは成功したと感じていて、classを作るのが人生初でES6とclassキーワードを書いたことが一度もない受講生さんもその部分は全くひっかかりなく書き方は覚えてくれて、OOP的な考え方、ひいてはクラスにどういう機能をもたせてどういうインターフェースを持たせるか、の部分に頭を悩ませることに時間とリソースを割けたと思う。

今回、講座の準備をしていて改めて思ったのは、インターネットにはやはり情報が無限(に感じられる程)にあるということ。そしてそれはときとして迷いを生じさせコストを増加させるということ。そういう時にはやはり本を手に取ることに一定の利点があるということ。(でも本でも情報がバラバラなことがあるということ・・・でも多分今回が自分史上最高にまとめるのに苦労したし他の言語ではここまでの苦労はあまりないようにも思うが。)

そしてそれら知識を得る方法がたくさんある今、じゃあどういうところに直接教える利点があるかというと、やはりコミュニュケーションを取ること。言語化しづらい、検索しづらい悩みを引き出す問いかけをして、それにフィードバックをするということ。

今回でいうと、classの書き方を覚えるのはすぐだが、とにかく初学者なので「そもそも良きクラスとはなんだろう」という指針が自分の中にない。だからとにかく基礎の書き方を教えたら、課題を出して、チャレンジしてもらいながら「その機能はそのクラスが持っているべきかな?」とか「そのメソッド名を見た人がする機能の想像と実際の中身があってるかな?」とかそういうやりとりを個別にしていくことに、結構手応えがあったように思う。

これってふと考えると要はペアプロみたいなもので、規模の大きな企業、自社サービス系だとそんなの普通に行われてるよなにいってんの、というものだとは思うが、受託メインだったり、中小の制作会社だとなかなかそうもいかないと思う。自分もそういう環境を享受できた経験はない。自分ももし自分よりできる人とそういうやりとりを日々しながら仕事をできていたらなんて良かっただろうと思っていた・・・というか今でも毎日思っている。が、みんな忙しいし、人手が足りないから呼ばれたり採用されたりするわけだし、各々が前に進んでいるので、なかなかどうしてそういう機会を得るのは簡単ではない。

あと、一人で全員見きれないことも想定して、翠灯舎の佐野さんに補助講師していただきつつの、佐野さんは普段はPHPメインの人で(そしてJSもやってらっしゃる)言語は違えど時折佐野さんと「こういう時僕はこういう感じなんですけど、どうしてます?」「あーPHPの人はこんな感じにしてる人が多いですね」みたいな別の視点も入れて頂いたりしながらの雑談も交えつつのスタイル。多分、受講生全員をみてまわるという点と、講師・補助講師間のかけあいという点で、補助講師は重要、いていただいたほうが良いと痛感した。

実は、果たして僕がこの題材を教えることが適切なのか、は正直迷った。自分はOOPの全てを知り尽くしている、だから教えれるとは全然思えていない。そもそも僕は普段の仕事内容的に演出重視のサイトやインタラクティブコンテンツを作ることが多いし、長期保守するプロダクトばかりでもない。つまり究極に設計をつきつめることが利益につながる立場になく、そこまではしていないできていない自覚はある。またGoFの全パターンをそらで書けるわけでもないし、大規模なシステム系のJSを日々書いてるわけでもない。SIer勤務でもない。毎回「あーここの設計もっとこうすればよかったなぁ」というのもある。しかし理想的にまでつきつめられていないとはいえ、各プロジェクトにおいてスケジュールとリソースと座組を考えてここまでというバランスの判断を適切にすることに意味はあると思っているし、界隈の同業と比較してそれついて考えるのがどうやら好きであるという肌感はあるし、それに受講生の方々の普段のお仕事も大規模システム系ではなく近いものでその点においては受講生の方々より自分にはいくらかの経験があるし伝えられることもある、という自信はある。じゃあ何をやろう?という思いで組み立てた講義アウトラインだ。ただやはり学びのロードマップを考えいてった時に、あるレベル以上のより高度なテーマについては、大規模・多人数・長期保守・自社プロダクトゆえにスケジュールとリソースが潤沢にかけられている、そういう会社の設計のエキスパートを招いて、一緒に内容を考える企画をしたいな、と感じた面もあった。まあ今回は初学者講座だし、それはまだまだ先のレベルの話だ。

さらに余談だが、今回の資料は、Marxico、Dropbox paper、Keynote、色々迷った。Marxicoはプレゼンテーションモードがない。Keynoteはシンタックスハイライト機能がない。Dropbox paperは両方あるが、僕の環境では日本語入力時に1文字目が勝手に確定される謎のバグが起きていて(サポートにも投げたのだが)きつかったのと、書体を指定したかった。ということでMarkdownで書いてPDF化できるElectronアプリMarp – Markdown Presentation Writerを見つけて、ソース落としてきて吐き出すPDFの見た目とかを好みにいじってビルドして、出力した。便利だ。多分次もこのスタイルで行きそう。

話は戻るが、結果として受講生さんから良い感想を頂いているのも聞こえてきて、講座をどう組み立てるのかにかなり試行錯誤した分、嬉しかった。ありがとうございました。そして講座はまだ続く。準備頑張ろう。

JavaScript course in KYOTO vol.2 : OOP with JavaScript | Archive | ikekou.jp

2017.05.16/Photo

20170514-IMG_3817-2

2017.05.15/Photo

20170512-IMG_3787-2

2017.05.14/Photo

20170514-IMG_3812-2

2017.05.10/Photo

20170507-IMG_3745

2017.05.09/Photo

20170507-IMG_3649

>

Next page