けいまさんですけど

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

地方から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 に圧力かけてください・・・)

Android Test Casual Talks #1

2013年12月13日(金曜日)にリクルート Media Technology Lab にて開催された、
「Android Test Casual Talks #1」なるイベントに参加し、登壇させて頂きました。

# 実は就職して、また東京に来て初の勉強会登壇でした。緊張しました!

めちゃオシャレな会場で、「うわっすげっうわっ」って言ってました。

スライド

今回、僕は「テスト配信プラットフォーム」について発表させて頂きました。

Androidアプリのテスト手法では色んなレイヤーの話があり、主に技術的な解決作としてはJUnitを使ったりRobotiumとかCalabash-androidとかEspressoとか色々あるのですが、あまりユーザーテストやそのツールについては情報少なそうだったので、あえて焦点を当ててみました。

TestFlightやDeploygateの話は皆さんご存じという印象でした。今回はQuoraで偶然見つけた「Vessel」というプラットフォームを調査してご紹介しました。これは多分日本語の記事がなかったので初めて知ったという方が多かったのではないかと思いました。

Vesselが得意とする「A/Bテスト」は「Android Test Casual Talks」のネタとして扱うテストの範疇外な気はしますが、まぁ多少はね?

反省点としては、時間配分がちょっとまずかった(スライド枚数多かった)のと、個人的な「推し」についてあまり紹介できなかったところです。

会社としてはTestFlightを使ってますが、システムとしてはDeploygateのほうが魅力的ですし、今後重要になってくる効果測定をやっていきたいのであればVesselは使いたい、、、というようなことを入れたかったんですが失念してしまった。。

他の皆様のLTを拝見して

テストフレームワークを色々触ってみた ( @dagezi さん )

今流行のlessでプレゼンするスタイル良かった(こなみかん)

BDDとしてNative系(Robotium、Espresso)、Web系(Appium、Calabash)の分類があり、それぞれ特徴を紹介して頂きました。

Robotiumを使っていこうかな〜という話だったと記憶しています。ですよねーという感想でした。(とはいえEspressoもアーリーアダプター的に触っておきたい感はあります)

Androidで使えるモックフレームワーク ( @nowsprinting さん )

Test Doubleというワードを初めて知りました。積極的に使っていこうと思います!

テストをやるにあたりDOC(依存オブジェクト)を解決するのが重要で難しいという話から、AndroidのMockフレームワークの歴史もおさらいして下さり、大変ためになりました。

「最強」のチームを「造る」技術基盤 ( @hageyahhoo さん )

自分が徳島に居た頃に、吉岡さんと接する機会があったのですが、楽天のおじさまエンジニアの方々はアツい方々が多くていいな〜と思いました。

楽天で取り入れられたCI・CDについての苦労・要点などを紹介して頂き、非常に良かった。「これなら俺達でも出来そう!」って思うような説得力のあるプレゼンだったと思います。

なにげに周囲の理解を得るやりかたについても言及されていて参考になりました。

Androidアプリの自動テストケース作成へのチャレンジ ( @geotana さん )

実際の数字を交えたAndroidのテストの状況と、自動テストケース作成への試行錯誤が面白かったです。フランス人エ・・・

詳しい数字は出せませんが、Androidで機種依存は切っても切れそうにないな、と思いました。また、自動テストケース作成は夢物語かと思いましたが、案外いけそうな気もしました。あと1年後くらいにはGoogleがサービス提供してそうだ。

uiautomatorを使うときの一工夫 ( @sumio_tym さん )

Modified-UTF7を挿入して言語入力するアイデアはすげーと思いました。

基本的にAndroidのテスト環境に限らないことですが、日本語やマルチバイト文字の扱いはめんどくさかったりします。(KitKatで文字列関連のAPIがぶっ壊れて酷い有様だった時期もある・・)

「全て選択」を認識できないのには笑ってしまいましたw

Espressoに関して ( @ngsw_taro さん )

熱いKotlin推し。

Espressoは今年Googleが出したテスト用フレームワークで、僕もかなり気になっていたので非常に興味深かったです。ただ本利用するには少し機能が少ないかなという印象もあります。

Fixture Replacement on Android ( @rejasupotaro さん )

レジャスポ太郎さんのブログはよく参考にさせて頂いており(しかもAndroidのトピックかつナウい話題がたくさんある)、是非お会いしたかったのですが。。残念。

まとめ

久々に人前で話す機会を得て、だいぶ緊張しましたが良かったです!機会を下さった @androhi さんと @hotchemi さんに感謝m(_ _)m

あと懇親会のピザうまかったです^^ またピザ食べたいです^^

はじめに

艦これメンテナンスなのでブログ書きますね 意識高いのでブログ書くことを己に強いている

FrameLayout内のViewがFrameLayoutの外に出ても描画されるようにするには

ちょっと意味わからないと思うので図で示します。

@numa08 https://t.co/qNMZRqUkkb pic.twitter.com/a1FACMN8a8— 今中幸太 (@pside) 2013, 11月 26

FrameLayoutの中身としてImageViewなりなんなりが入っている状態でアニメーションなりなんなりをさせてLayoutの境界線を超える場合、基本的にはLayoutの外にいった領域は描画されないようです。

実はこれが非常に微妙で、手元のAndroid2.3端末では境界の外の部分も描画されていたように見受けられたのでちょっと困惑しました。
どうもAndroid4系とAndroid2系ではmarginやpaddingの扱いが微妙に異なるっぽく、そこで機種依存を出していたような気がします。今となってはどうでもよいことなので詳しく検証してません!

結果的には以下のようにして対応しました。

@numa08 僭越ながら自己レスさせていただきますと、 FrameLayout にandroid:clipChildren="false" android:clipToPadding=“false" と書くことで顧客がほんとうに必要だったものを得ることが出来ました— 今中幸太 (@pside) 2013, 11月 26

なんてことないですが、ViewGroupクラスについてのリファレンスをよく読まないと気が付かない感じでつらかった。。。

ちなみに

iOS(Cocoa touch)で同じことをするには、 UIView の clipToBouds なるフィールドを@NOとかにすると良い感じっぽいです。

# 前職でこれを使ったUI改善を行って大満足だった事案ある