けいまさんですけど

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

はじめに

ひっさびさに技術的な話を書くよ。でも技術の話というよりも、俺はこう思うという話なのでQiitaに上げるよりはブログに書くことにした次第。

extends Activity OR extends MyActivity

Androidアプリ開発するうえで、以下のようにしてActivityクラスを継承したクラスを作ることは非常に多いかと思う。

public class HomeActivity extends Activity {
    // snip
}

まぁ最近はandroid.support.v7.app.ActionBarActivityとかを継承することが多いのですが。
それはそれとして、Activityをそのまま継承する方法はサンプルコードでは非常によく出てくることです。
しかし、Githubなどで公開されているプロジェクトを見ると、あえてActivityクラスを継承したMyActivityという具合のクラスを作り、実体となるHomeActivityなどではMyActivityを継承しているケースが多い。こんなかんじ。

public class HomeActivity extends MyActivity {
    // snip
}

public class MyActivity extends Activity {
    // snip
}

で、どっちが良いかという話が個人的にずっと付きまとっていたのだけど、最近やっと自分なりの答えが出たので書いておきます

結論:どんな規模のアプリであれActivityを継承したクラスを作ったほうが良い

理由としては、例えば以下のようなことをしたいときが多々ある。

  • ネットワーク通信中にProgressBarもつ画面をスクリーン全体に表示させたい
  • 頻繁に似たデザインのダイアログを表示する
  • Toastをよく出す

こういう場合に、直接Activityを継承していると、毎回別々のActivityに同じような命令をコピペしていくことになるわけです。
今更書くことでもないですが、全く同じ実装が複数箇所に点在するというのはひどい。

しかし、Activityを継承したクラスを継承している場合、「Activityを継承したクラス」に実装しておけば命令を使いまわせるわけですね。

public class MyActivity extends ActionBarActivity {

    ProgressDialogFragment progress;

    // snip

    private void toggleProgressHID(boolean isVisible) {
        FragmentManager manager = getSupportFragmentManager();

        if (isVisible) {
            if (progress == null) {
                progress = new ProgressDialogFragment();
            }
            progress.show(manager, "progress");
        } else {
            if (progress != null) {
                progress.dismiss();
            }
        }
    }
}

ちなみに ProgressDialogFragment は以下のURLにあるコードを参照しました。
- Full screen ProgressDialog (for Android)

こうしておけば、toggleProgressHID(true)すると画面全体をProgressBarで覆い、toggleProgressHID(false)すると消えるようになるはず。

注意点として、DialogFragmentを使っているので、Activityを継承していると古い端末で使えないので、継承するクラスはFragmentActivityとかActionBarActivityを使うと良いです。

はじめに

最近まとまったブログ書いてないっすね。。。良くない。

もっと自分をアピールしていかなければ駄目なんだが、リハビリがてらブログを書いてみる。

マチアソビ行ってきた

ちょっと特殊な形でマチアソビに参加していた。非常に良かった。

眉山山頂で日光に当たりすぎて顔面が焦げた。ビビった。

マチアソビの良さは、あらゆる面で非常に緩いこと。これは資金面とか人的リソースという面で仕方ない面もあるんだけど、その緩さを観衆も含めた関係者一同で守ろうとするのが良い。

(尤も、そのあたりの事情をよく知らない方々が緩さを壊してしまうところがあって難しい。暗黙的なものなので、知らない人にとってはそりゃ知らんがな、という事情も理解できるので、そういう問題が出てきたということはかなりメジャー化してきたということの現れなんだろうなぁ)

幾原邦彦と庵野秀明と星野リリィの対談

今回、一番印象に残っているイベントは、幾原邦彦と庵野秀明、星野リリィの対談。渋い。

マチアソビで幾原邦彦と庵野秀明、星野リリィの対談を聞いたのだけど、そのときに庵野さんが「個性を出すということは(東映という)組織には必要とされていない」ということを言ってた気がする。
詳細は覚えてない、俺はこういう風に受け取った。

会社としてのルーチンやスキームにはめていけば収益は保証されるということで、これに逸脱することは許されない。まぁ確かに合理的である。ただ、これは「経営者目線での合理的」である。

IT系業界と人月

IT系業界におけるプロジェクトの大きさとか作業量を表す単位で「人月」というワードがある。ひとりの人間が1ヶ月かかる仕事量を1人月。10人が6ヶ月かかるならば60人月。

この単位はプロジェクトの規模を経営者なり営業担当者が"特殊事情をそぎ落として"勘案するには非常に便利な言葉だと思う。

けれど、微妙な感じである。全員の能力がすべからず一定であれば成り立つと思うが、そうではない。そもそも、俺と俺より優れた人の1ヶ月あたりの生産性であれば、俺のほうが少なくなるに決まっている。俺と俺より劣った人であれば、俺のほうが多くなる。それを平均化してまとめて10人月だ何だと言われれば、能力的に優れた人は優れている部分を評価してもらえないし、劣っている人にとっては高いハードルとなる。場合によっては連日の残業必至である。土日?なんですかねそれは状態。

思うに、ちゃんと人物の得意不得意を考慮できるマネージャであれば人月での丸め込みはしないと勝手に思っている(とはいえ営業担当や経営者や外部とのやりとりで人月という言葉を使う可能性はあるだろう)。もっと言えば、世の中には人月で判断できない生産性を出す人がいる。そういう人をプロジェクトに組み込む意義なりを理解している人間というのはどのくらいいるのだろうか。ともあれ、人月という単位で人を評価し続ける限り、没個性化していくと思う。そこから良いアイデアが生まれるとは思わない。「お前はプログラムを書くためのモジュールなのだ、我々は10のモジュールを6ヶ月稼働させて60人月分のプロジェクトを成功させるのだ!」

俺はIT系業界で仕事をしていて、おおよそ人月で図るには微妙なスキルばかり持っている。だいたいのポピュラーな言語はそれなりにこなせるが、けれど広く浅くなので速度が出ない。そういう意味で自分を人月単位に当てはめれば雑魚そのものである。ただ、JenkinsなりGitなりを使ってビルド環境を構築したり、業務支援ツールをこさえてみたりするというのは、人月に含まれない概念だと思う(そして直接的に組織の利益に関与するわけでもないのでなかなか評価して貰えない)。そういう方向性ばかり強くなってしまった自分にとっては人月という言葉に支配された世界はアウェイな環境だった。

ちょっと話が横道にそれてしまったけれども、自分の強みやアピールポイントがはっきりと分かっていて、その強みを生かして働きたい場合、多くの大きな組織にいることでミスマッチを起こしてお互い損をすると思う。重大な問題が出る前に早くその組織から抜けてアピールポイントを生かせる場に行くほうが良いのかも知れない。あるいはフリーランスとして活動するとか。(ただ、土地という鎖に縛られている人もいる。これは別の機会があれば書きたいけれど、都心部ほど地方は職業選択の自由がない。)

ともあれ自分にとっても何が正解かはよく分からない。人それぞれだとも思う。けれど自分にとっては人月という言葉はいろいろあってNGワードになってしまった。やれやれ。

影響を受けた記事

こういう真面目なこと書くのは、以下のブログを読んだからです。

俺は今はAndroidアプリエンジニアとして活動してますが、高校・大学時代はもっぱらウェブエンジニア的側面のほうが強かったりして、結果いろんなことを知ったり適用できています。それでも知らない世界は広い。

ともあれ、自分の方向性とかを考えなければならないのだけど、自分の創作意欲の根底にある「人を幸せな気持ちにするものづくり」というところはずっとあって、それはかなり原始的な考えで、でも原始的であるからこそ揺るぎなくて強くて。

自分が「一人月」で満足か

人月より、人間がスケールする方を選ぶし、その手段をとる

この見出し文は2013年上半期の自分に対する苛立ちへの回答そのものだと思った。

ルーチンは人月によって解決できるが、そもそもルーチンのタスクはプログラマがコードによって解決するべきであるし、実際にそうされてきた。それを認めないのは非生産的な場所にいた人間の自己保身であると思っている。

これは2013年上半期の周囲に対する苛立ちとか怒りへの回答そのものだと思った。

マチ★アソビ

10月12日から14日にクライマックスを迎える、徳島県徳島市で行われるマチ★アソビも今回で11回目です。どんどん規模が大きくなっていき、徳島の地で学生をしていた私といたしましても非常に感慨深い思いでございます。

マチ★アソビのイベントを纏めたGoogleカレンダーをつくりました!

さて、マチ★アソビのフライヤーも、年々大きくなったり折り方が変わったりしております。年々密度が高くなっていくのはイベントが大きくなっていると言うことで嬉しい限りです。

ただ、お目当てのイベントを探すのがけっこう難しい感じです。

個人的に「このイベントの裏のイベントなんだっけ?」というのを一発で見れるようにしたかったので、せっかくなのでGoogleカレンダーにイベントをまとめてみました。

マチ★アソビのGoogleカレンダー

※当カレンダーの制作者はマチ★アソビおよびこのイベントの主催や関係者とは関係がございません。よって、当カレンダーの妥当性を保証するものではございません。当カレンダーに記載されている会社名並びに商標は各団体や各企業に属します。

つかいかた

上記リンクを開くと、「予定リスト」の形式で主要会場のイベント一覧が確認できます。

右上の「週」「月」で表示形式をお馴染みのカレンダー表示にすることができます。

右下にある「+ Googleカレンダー」リンクを押すことで、あなたのGoogleカレンダーにイベント一覧カレンダーをインポートすることができます。

例えば「林間ステージ」だけが欲しいという操作も可能です。

Googleカレンダーにインポートして、お使いの携帯端末でイベントの情報を見たり作戦を立てたり、色々とお使い頂けると思います。

間違いを見つけたら・・・

以下のフォームからご連絡頂ければ対応させて頂きます。

つくったひと

はじめに

皆様お元気でしょうか。ご無沙汰しております。

Googleウェブマスターツールが「サーバーエラー多いよ」って連絡をくれて、

riafさんが対応して頂いたので久々にブログ書くよ!

就職しました。

これまで「とある徳島の国立大学生」として、ゆるく頑張っておりましたが、
この4月から、東京のとあるIT系企業にて勤務しております。

学生時代は趣味で頑張っていたAndroidアプリ開発の延長として
研究でもAndroidアプリを開発しておりました。

現在は、業務でAndroidアプリを作成するということは特にしておらず、
普段はObjective-Cを書きつつ、たまにChefとかを使ってサーバーデプロイをお手伝いしつつ、
あるときはWindows機をセットアップしたりしつつ、あるときは変なリクエストを送った結果、
開発用サーバーを3時間落とすということをしたりしております。

そんなわけで、東京にいる皆様宜しくお願いしますm(_ _)m

前略。本題。

Nexus7などの電話アプリの存在しない端末では、
「*#*#2432546#*#*」に代表されるシークレットコードを認識させるには、
PCと接続してadbコマンドを使うのが楽なように思いました。

adb shell am broadcast -a android.provider.Telephony.SECRET_CODE -d android_secret_code://2432546

上記コマンドの数字部分を他のモノに置き換えれば、別のコマンドも通るのではないでしょうか。

参考文献