けいまさんですけど

死ぬ気でやってりゃ、そりゃ死ぬわ

はじめに

ぬまさん ( @numa08 )から光栄なことにお誘いを受けまして、Live Coding de Night というイベントに参加させて頂きました。

僕はAngularJSを使ったライブコーディングをすることにしたのですが、非常に残念な感じになってしまったというお話しです。

Live Coding de Night とは

渋谷にある 21cafe さんにて開催された、ぬまさん主催のライブコーディングのイベントです。
プロジェクターとマイクがあればパフォーマンスができるのですが、そこにDJブースが組まれていたりと非常にゴージャスな感じでした。また会場が非常にオシャレでびっくりしました。さすが渋谷。

僕以外にも色んな方のいろんなジャンルのライブコーディングが行われました。個人的にはmikutterのプラグインはつくれる!というところが印象に残っています。

お前はなにをやらかしたのか

AngularJSの発表をしましたが、色々あって時間ギリギリのところで事前に用意していたリポジトリを使って緊急回避する事態になってしまいました。無念である。

以下、言い訳じみたことを書きますと。。。

プロジェクターに繋いだら画面サイズが小さくなってしまった

VAIO Proは1920x1080のメインディスプレイがあるのですが、プロジェクタに繋いでミラーリングに設定した途端、 1024x768サイズになってしまい、情報量が激減してしまいました。。ちょっと予想外で調子狂ってしまった。。。

テンパって ng-src の使い方を間違えた

ng-srcというAngularのDirectiveがあるのですが、これは {{ variable }} と書かないと動かないのです。この括弧を付け忘れて爆死しました。。。つらい。。。

そもそも練習量と本番の想定が圧倒的に足りなかった

まず普段のプレゼン程度の練習だと死にます。最低でも普段の3倍は練習しておきたい。

あと、ライブコーディングは緊張とか予期せぬトラブルとか諸々あって、練習時の10%くらいしか実力を発揮できない感があります。。。そのあたり加味して頑張らないと駄目ですね。。。

まとめ

ライブコーディングの経験があまりなかったですが非常に楽しかったです。また良い経験になりました!

しかし自分のパフォーマンスにはまったく納得できてないので、もし次回も呼んで頂けるのであればリベンジしたいです。。。

ソースコードとかスライドとか

はじめに

タイトルはナウでヤングなネットサーファーにバカウケする感じにしてみた。

一応先に言い訳すると、デザインパターンなどのソフトウェア概念については自分の知識がまだまだ乏しくて学習段階なので、間違ってることがあります。そのときはご助言お願いします><;

MVC, MVVM, MVW, .....

世の中にはMVC(モデル,ビュー,コントローラー)と呼ばれる設計・実装するための技法が存在する。小規模なアプリであればいざ知らず、大規模なアプリであるとコードの複雑性が上がるので、それをちゃんと体系づくって見通しよくしたい。それらを開発者共通の認識としておけば色々都合が良いのですね。

ただ、MVCそのものの説明については何回読んでも難解でございます(ぬまさんリスペクト)

  • ModelなるものとViewなるものとControllerなるものがある・・・?
  • Viewはなんだか描画するものっぽい・・・?
  • Modelはなんだか描画したりするのに使うデータっぽい・・・?
    • じゃあデータベースにあるデータはModelだよね・・・?
  • ControllerはModelとViewを橋渡しする・・・?

だいたいこの程度はわかる気がしますが、上記の認識のままだと、実際に開発すると綺麗に3分割できない事象がたくさん出てきます(主に悩むのはModelかControllerなので2分割かな?)。というか僕がそうでした。

例えば、データをフィルタリング(条件にマッチしたデータだけ返す)するロジックはどこに書く?Viewではないことは確かですが、ControllerかModelか・・・?ModelはしかしながらデータなんだからControllerかな?

_人人人人人人人人人_
> Fat Controller <
 ̄Y^Y^Y^Y^Y^Y^Y^Y ̄

世知辛い世の中です。良かれと思って考えて挿入したコードが、「これじゃコントローラーが肥大化するよー」と言われるのですから。つらい。しかしそう云う人も悪意があるわけではなくて、押し込められたコードは可読性を下げます。なのでちゃんとしたいということです。

ところでこの例(データをフィルタリングするロジック)だと、どこに何をすればいいのか?ということですが。。。言語やフレームワークの事情が色々あるので一概には言えないですが、Javaだったらモデル層に DataAdapter クラスを作って List を返すようにするのがいいのかな、とふと思いました。が、いやしかし List を継承したクラスを書いてそこにロジックを書くほうが良いのだろうか、とか色々思うところはあります。あと「データ」がSQLiteにあるなら直接クエリ叩いて得たものを返せばいいわけで、結局やはり一概には言えないのかも。助けて!

まぁそれはそれとして。

MV○についての長年のモヤが晴れるたった1つのスライド

最近はそういうもやもやをずっと抱えていたのですが、Twitterで流れてきた以下のスライドを見てすごく腑に落ちました。

このスライドは(Windowsのソフトウェア開発で提唱されている)MVVMパターンについて書かれていますが、MVVMについての説明がこのスライドの本旨ではなくて、

MVVMのよく云われる説明だけだとMVCとの違いがわからないし何も説明できてない、ちゃんと理解しないとMVVMの旨味を享受できないからちゃんと基礎部分から説明するね(そもそもなんでMVCに代表されるパターンが必要なのかも)

という感じだと僕は理解しました。

これを読んでからさっきのWikipediaを読んでみると、あんま大したこと書いてないという印象です。だってMVCパターンは各アーキテクチャの都合を叶えるためにあるのだから、MVCそのものの説明はかなり抽象的にならざるを得ない。

また、このスライドは結局MVVMを強制しているわけでもない感じです(わかったうえで型を崩すことについても言及している)。「MV○使え!」と強制されるより、「MV○使わなくてもいいけど使ったらこういう利点あるよ〜」のほうが心理的に受け入れやすい感じがするのは僕だけではないはず・・・。たぶん。

まとめ

どこかしらから怒られそうな感じもしないでもないですが、特定の事情を考慮しないMVCパターンのあるべき論というのは不毛な感じがしました。モデルとコントローラが言語やフレームワークのわがままをうまくやるためのアイデアであるなら、その言語やフレームワークでのあるべき論を追求することは出来ても、抽象概念のMVCパターンには関係のない感じがします。(だからAngularJSのMVWパターンがこうあるべきだ、は成立しえても、MVCとはこうあるべきだ、についてはフレームワークや言語の事情があるので話がオチない)

まぁそんなわけで、まだまだ勉強せねばならないですね。

地方からITエンジニアがいなくなる

一番上の記事を読んで、「そうだよね地方でITエンジニアとして頑張れれば良いよね」という考えをもって、ITエンジニアが地方からいなくなる(首都圏に集まる)ようになった理由が技術的な教育指導が充分整っているかどうか(地域的に、社内的に)と安直に考えていたのですが、色々他の方の感想記事を読むにあたり、もっと基礎的なところ(カネの部分)でネックになっていたという感じで、分かるんだけどなー、でもなー、、、という感想です。

業界的には、カネ稼ぎのために権限の集約化をして、大企業がそれに追随した結果として、そこから得られる利益が目当ての企業が首都圏に移動という流れは本当に自然だと思います。さながらジンベエザメに群がる魚のような感じです。

地方の技術力が落ちていく

その流れ自体には全く自然だと思うのです。ですが、地方の人材面から考えるに、地方からITエンジニアがいなくなっていくと、その地方の技術力が落ちていく感じがします、というか、人が集まるところに情報が集約されていく印象があるので、ただでさえ人の少ない地方でITエンジニアが首都圏に移ってしまうのは、その地方でエンジニアを育てることが難しくなるんじゃないかなと思っています(「エンジニアは自ら勉強すべきだ」という意見はごもっともですが、そういう態度は人から与えられなければ気がつかないので、そういうエンジニアの姿勢も含めて、地方でエンジニアとして成長する機会を与えられることが出来なくなるのではないかという懸念を抱いています)。地方でエンジニアが育たないと地方の技術力は下がる一方な気がします(とはいえ地方でエンジニア育っても東京に行ってしまうんじゃ意味ないか、じゃあ別に育てなくてもいいのか・・・)。

そもそも問題でも何でも無いのでは?

この問題(そもそも問題でも何でも無く「当然の流れ」と論じる向きもありますね)については、「業界・会社的な側面」、「労働者・教育的な側面」、「地域の繁栄衰退的な側面」などから色々と着眼できそうではあります。ただ、どこかで首都圏への人材移動の流れを変えないと、地方はスッカスカになってしまう気がしないでもない。「スッカスカになったからなんだというのだ」という向きもあるでしょうけど、その割には皆さん「日本の海外での影響力がー」という論調には なびく感じですよね。。。(或いは地方をスッカスカにして今の現状を維持しているのかも知れません)

ともあれ理想としては、満員電車で憂鬱な思いをしない地方で暮らしつつ仕事が出来れば良いのです。そしてそういう思いを抱いている人が一定数て行動に移したなら、多少は首都圏の通勤事情も緩和するのではないですかね。。。しかしながら、今の業界の流れ上なかなか難しいのだな、ということを情報収集して思った次第です。

まとめ

地方に安定した賃金があれば全て解決するのです(ゲス顔

とは言え誰かが地方にUターンして解決する問題なのであれば、(自分が基準を満たすのであれば)地方に飛び込んでも良いのかも知れない。

そもそも「地方で働きたい」と一口に言えど、「地方で(賃金は安定していて通勤が苦ではなくて仕事も激務は嫌だしインフラは完備されている所で)働きたい」というニュアンスが含まれているので、単に地方で働きたいならいくらでもできるんだけど、そういう理想というか幻想的な世界は我々に構築できるのだろうか。。。

余談

こういう関心ごとがあり、地方(特に徳島県)で働くことにはずっと関心を寄せています。
もし地方(特に徳島県)で何かしら企んでいてITエンジニアを必要としている人がいればお声がけ頂きたい次第です。

ただし、自分のスキルセットも中途半端なので今すぐに(少なくとも1年以内)何かすることは難しいです。

しばらくの間は東京で研鑽したいので、今すぐに何かすることが出来ません。「地方のITエンジニア問題」を何とかしたいとの思いで書いております。

連絡先: k.imanaka@gmail.com

「地方で(賃金は安定していて通勤が苦ではなくて仕事も激務は嫌だしインフラは完備されている所で)働きたい」という幻想的な世界を実現させたい皆様、何卒宜しくお願いします(?)。特に神山の方面は私気になります!

はじめに

折角なので2013年を振り返ってみようと思います。

1月

  • 大学で行っていた研究が一段落付く

2月

  • 北海道に初音ミクのライブ観に行く(ついでに雪祭り見てきた)

卒論も佳境という時期に初音ミクのライブのために北海道行きました。頭がおかしい。
でも非常に満足の旅でした。あと北海道の冬は本当に死ねる、マジで。

3月

  • 徳島大学を卒業しました

卒論を無事に提出することが出来ました。
邪悪なJavaソースと格闘したりしましたが、何とか動くモノを用意し、評価実験も行うことが出来たので良かったと思います。
現在も僕の作ったシステムを引き継いでいる人がいるとかいないとか。。。

  • OSC StartDASH!を開催

3月9日に行われたOSC徳島に参加出来ない腹いせに、前日イベントとしてLT大会を開催しました。
大学サークルの人たちや知人に登壇をお願いしましたが、最終的にはOSC徳島に参加される方々にも登壇して頂き、
非常に良いマッシュアップを図ることが出来たと思っております。如何でしたでしょうか。

  • 和歌山の初音ミクライブ観に行く

3月9日はミクさんの日、ということで、和歌山のビッグホエールで行われた初音ミクのライブに行ってきました。
初めて友人を連れてライブに参加しましたが、一人で参加するよりも感動を共有することができて良かったです!
今でもあのときのライブの光景は脳裏に焼き付いております。本当に行って良かった。

4月

  • 東京に住民票を移しました
  • 就職しました

東京のとある企業に就職しました。その都合で東京住まいをする必要があったので、東京に住民票を移して生活することとなりました。

5月・6月・7月

  • 特になし

8月

  • 横浜の初音ミクライブ観に行く

マジカルミライを観に行きました。演出も最高でしたが、1万人の初音ミクファンが集結したというのが感慨深く思いました。

9月

  • 会社を辞めました

10月

  • 転職しました

現在お世話になっている会社に転職をしました。(そういえばまだ転職エントリーなるもの書いてないですね、まぁ書いてないということは[お察し下さい])

11月

  • 特になし

12月

  • 仕事で作ったAndroidアプリをリリースしました
  • Android Test Casual Talks に登壇しました

転職しての初仕事としてAndroidアプリの改修作業がありました。
基本的にはiOSアプリと同じように作るということで、またAPI設計も非常に綺麗だったので作業が楽にできました。
(とは言えAndroid特有の機種依存などで思ったよりも完成が遅れてしまいましたが・・・)

Android Test Casual Talksへの登壇は、止まっていた半年間の再始動という意味合いが非常に強かったです。
もともとAndroidに限らずIT系勉強会が好きだったので、そこに回帰していこうという態度の表れでした。

まとめ

2013年は4分の1は学生、残りが社会人として生きてきた1年でした。
まさか半年で転職することになるとは思いませんでしたが、Androidに注力していたこともあり、なんとか踏ん張ることが出来ました。

あとなにげに初音ミクのライブとかいろいろ行けてるなーという感じ。これは譲れません。

2014年はどんな年になるでしょうか、楽しみです。

はじめに

Androidを専従しており、今も一応はその形をとっているのですが、スタートアップ特有の人手不足によりフロントサイドも着手することにしました。ちなみに既存の管理画面のリプレイス目的です。

なぜAngularJS?

もともとAngularJSに興味があったのが第一。あとTwitterのタイムラインを見ている限り、他と比較してAngularJSのほうが良い流れがある感じがしました(よく話題になっているという意味で、困った時なんとかなりそう感)。ぶっちゃけBackbone.js使おうが何を使おうが、とにかくフレームワークに載せているだけ既存のやつよりはるかに良いという感触はあります。

AngularJSの問題点としては以下の記事が的確だと思いました。実際にその通りだと思います。ただ僕自身の能力がそんなに高くないので、AngularJSの重力に吸われている方が安定したコード書けるかもしれないと思いました。

最初にしたこと

AngularJSの公式サイトにあるチュートリアルを1日かけて制覇してみました。

なんとなく動きはつかめましたが、問題点として全部コントローラーにぶち込む書き方をしやがるのでコントローラーに機能集中してしまいます。このあたりは以下の記事を読んでどうすべきか考えてみる必要はあります。

あとDeferredPromiseについてよく理解をするのも大事です。これは別にAngularJSに限りませんが、非同期プログラミングをするうえでコールバック地獄とかの諸問題を解決するアプローチを取るための現状最善の方法だと思います。

※ なおjQuery.DeferredとAngularJSの$q実装では微妙にメソッド名が違うので注意!詳しくは→ AngularJS: ng.$q を見てください。不正解ながら簡単に書くと、then(successCallback)で成功をつないで、catch(errorCallback)でエラーを記述して、finally(callback)で終了処理を書く、みたいな。

これだけ理解したとしても、イマイチ正解が見えない部分があったりします(定数どこ置けばいいねん、等)。このあたり僕もよくわかりません。何か参考になるような大規模アプリとかあればいいんですがね。。。

まとめ

mizchiさんのブログにある文章を引用します:

最近Angularの検索数が跳ね上がってて一番人気です!っていう紹介をたくさんみるようになったんだけど、正直「ググらなければわからないこと」が多すぎて他のフレームワークより検索という行為に高度に依存しているというのを感じている。この場合の検索数は、人気ではなく複雑さに依存している。この辺railsに似ている。

これはAngularJSをやるうえでの重要なポイントです。本当に検索しないとわからない。しかしながらこれはもともとJavaっぽい言語のAndroidでも経験してきたことだった(そもそもJavaのUtilクラスとかライブラリとかググらんと気が付かん)ので、IDEとかでコード補完されたり、ググってクソ便利なDirectivesとか見つけてウヒョー俺TUEEE!みたいなのが好きな人にはAngularJS向いてると思います。逆に、既にある程度コーディングスキルが高くてフレームワークの裏でやってる挙動にイラつくタイプの人は薄いフレームワーク(それがBackbone.jsなのかどうかは僕にはわかりかねますが)のほうが適しているのでしょう。

結論。好きなの使え。楽しくコーディングせよ。

次回予告

AngularJSの最終兵器(?)、$rootScope.$broadcast()およびそれをキャッチする$scope.$on()について。

(もし2014年になっても次回作が投稿されてなかったら @pside に圧力かけてください・・・)