--/--/--(--)


上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
コメント(-) | トラックバック(-) | --:--:--

2011/01/29(土)


menuボタンで表示されるメニューは、onCreateOptionsMenuとonOptionsItemSelectedの2つのメソッドをオーバライドすることで実装できます。onOptionsItemSelectedはメニューが選択された際に呼び出され、どのメニューが選択されたかが引数で渡されます。

import android.app.Activity;
import android.view.MenuInflater;
import android.view.MenuItem;

public class MyClass extends Activity{
 
 @Override
 public boolean onCreateOptionsMenu(android.view.Menu menu){
  super.onCreateOptionsMenu(menu);
  MenuInflater inflater = getMenuInflater();
  inflater.inflate(R.menu.menu,menu);
  return true;
 }
 
 @Override
 public boolean onOptionsItemSelected(MenuItem item){
  switch(item.getItemId()){
   case R.id.menu_item1:
   case R.id.menu_item2:
   case R.id.menu_item3:
  }
  return true;
 }
}

res/menu/menu.xml
<?xml version="1.0" encoding="utf-8"?>
<menu xmlns:android="http://schemas.android.com/apk/res/android">
 <item android:id="@+id/menu_item1"
  android:title="メニュー1"
  android:numericShortcut="1"
  android:alphabeticShortcut="a"
  android:icon="@android:drawable/menu_item1"
 />
 <item android:id="@+id/menu_item2"
  android:title="メニュー2"
  android:numericShortcut="2"
  android:alphabeticShortcut="b"
  android:icon="@android:drawable/menu_item2"
 />
 <item android:id="@+id/menu_item3"
  android:title="メニュー3"
  android:numericShortcut="3"
  android:alphabeticShortcut="c"
  android:icon="@android:drawable/menu_item3"
 />
</menu>

メニューアイコンファイル
res/drawable/menu_item1.png
res/drawable/menu_item2.png
res/drawable/menu_item3.png
スポンサーサイト
コメント(0) | トラックバック(0) | 12:18:25

2011/01/23(日)


colors.xmlに頻繁に使用する色を定義しておくと便利です。

res/values/colors.xml
<?xml version="1.0" encoding="utf-8"?>
<resources>
 <color name="white">#ffffffff</color>
</resources>

res/layout/main.xml
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
 android:layout_width="fill_parent"
 android:layout_height="fill_parent"
 android:orientation="vertical"
 android:background="@color/white"
/>

コメント(0) | トラックバック(0) | 12:56:31

2011/01/11(火)


日本の上流・下流の分離構造には確かに多くの問題点があり、欧米を見習って一刻も早くこうした構造を解消すべきだという主張を時折目にするのですが、私としてはそのような論調にも若干無理があるのではないかと思っています。結局のところ、スキルの低い人間が質の悪い仕事をすることが問題なのであって、それは上流と下流の垣根がなくなったからといってたちどころに問題が解消される類いのものではないと思うのです。

上流から下流までを一人で担当するわけですから、当然必要とされる技能・技量はぐんと上がります。一人前になるまでの道のりは遠く、結果として質の低い仕事をしている状態が今まで以上に長くなることでしょう。特に上流設計の質の悪さは、そのソフトウェアの商品価値や戦略的資産としての有益性において致命的です。上流設計は下流と比べ、より多くの目的や意図を持ち、その品質は下流工程にも影響を及ぼします。スキルレベルの高い人間が上流から下流までを担当する分には何も問題はありませんが(むしろ良い方向に向かう)、低スキル者が上流までを担当することで、その人の質の悪い仕事がソフトウェアに与える影響は恐ろしく拡大してしまいます。極端なまでに製品(サービス)の品質を求められる日本の社会においては失敗が許されません。企業としてもこのような人材を抱えることができなくなってしまい、今でさえ難しい状況にある人材の確保の面でさらに困難を極めることになってしまうのではないでしょうか。

日本特有の分離構造はこのような背景の下に、生まれるべくして生まれたものだと思います。少なくとも上流に優秀な人材を配置することで低スキル者の影響を局所化するというメリットがあり、全体のスキルレベルになるべく左右されることなく、ソフトウェアの有益性を確保することに適した組織構造なのです。また作業範囲を分担することで個々の専門性が増し、きめの細かい作業が可能になるという特徴も持っています。上流工程と下流工程にはそれぞれ必要とされるスキルに差異があり、例えばプログラミングが得意だからといって機能要件整理が得意であるとはかぎりませんが、1つの分野に特化した職人的な仕事をする人をたくさん雇うことができます。この場合個々の連携が非常に重要となってきますが、チームプレイを得意とする日本においては有効な組織構造と言えるでしょう。

分離構造の解消を訴える方の主たる要旨は、上流従事者のプログラミングに関わるスキルのなさを問題視しているように思います。確かにこのような組織構造は、下流の知識が著しく低い上流従事者を数多く生み出す要因となっています。とは言え前述のようにそれなりの原因があってこうした構造が生まれたのであり、いまさらガラガラポンと世界が変わることは難しいような気がします。やはり問題の本質は上流従事者のスキルレベルであり、プログラミング周辺の手法や新技術の習得、下流工程で発生する問題を吸い上げる能力をきちんと身につけることで、ほとんどの問題は改善されるのではないでしょうか。

またよく耳にするのが、下流従事者の地位が低いせいでより重要な工程に対して意見が通らない、という話です。特に上流と下流で会社が分かれる請負構造となっている世界では、日常茶飯事的に聞かれる話でしょう。しかしこれは単純に地位うんぬんだけの問題ではなく、上流側の能力的・体質的・人事的・経営戦略的な都合に合わさざるを得ない下流側の事情であったり力量の話であり、分離構造上の問題というよりも発注者と受注者、上司と部下といった主・従の関係によるところが大きいと思います。

そもそも上流と下流の線引きはプロジェクトによっても異なりますし、優れたIT技術者を目指すプログラマはおのずと上流に目線がいくので、そういった方は上流にも下流にも精通する技術者となり、欧米で言うところの「プログラマ」とほぼ同等のスキルを持ってそれなりのポジションで仕事をしており、日本でも中小規模のプロジェクトではそういった方が案外多いのではないかなと思います。どちらかというとプログラマ自身の向上心や目指すキャリアパスの違いといった要因が少なからず影響しているのではないでしょうか。
コメント(0) | トラックバック(0) | 18:19:49

2011/01/07(金)


達人プログラマーを目指して:
高い品質のプログラムを作らなくてはならないと考えている職人PGの考えは間違っていた?

SI業界の分野ではその事業内容の特性上、ソフトウェア品質に対する理想を追うことが非常に困難な現状があります。SIerの分野に限らず、主に受託でまかなっている企業は、短い工数でより多くのプログラムを絶えず生産していかなければ経営が成り立たないというところがほとんどではないでしょうか。

ところがこうした企業こそソフトウェアの保守性・生産性を強く意識していかないと、今後生き残っていくことは難しくなると思います。なぜならハードウェアの性能向上などによりソフトウェアの寿命が延び、繰り返しリビジョンアップを行う必要が出てくるであろうことと、般化された他社製のクラウドシステムと競合していかなければならなくなっていくであろうと予測されるからです。*1

クラウドを分散コンピューティング技術と見たとき、分類化された業務を複数のシステムが担当するという構図が生まれ、結果としてシステムの置き換えが容易に行われるようになることで競争が激化する可能性が出てきます。いつまで経っても似たようなシステムを作るのに同じ工数・同じ人件費がかかっていては、機能に特化した安価で優れたクラウドシステムに徐々に侵食され、いずれは完全に置き換えられていってしまうでしょう。保守性・生産性が向上することは納期や金額の面で営業力の向上にも繋がりますし、競争力をつけるという意味でもこれらの施策をどう打てるかがカギとなってくると思います。

ただソフトウェアの保守性や生産性はプログラマだけが担っているものではなく、事業戦略やシステム構成設計・機能仕様設計などの上流工程においても多くの部分が盛り込まれます。あくまで推測ですが、恐らくSIerの方が本当に言いたいのは、(SI業界においては)下流工程の品質担保に対する優先順位は、上流のそれに比べて低くなる傾向にある、ということではないかなと思いました。そもそも上流設計は顧客に見せる必要があり、受託の成否や受託金額に関わる重要な業務ですので、どうやってもしっかりとやらざるをえないんですね。限られた工数でプロジェクトをまわして行くにはおのずと下流工程にしわ寄せがいくという構図です。

またプログラマのアウトプットは、プログラミングの経験を持った人間でないと評価ができない専門性があり、このため下流工程の品質が十分に議論されないという問題があります。そして一番の問題は、こうした問題が上層部に認識すらされていないということではないでしょうか。このような企業は保守フェーズや新規開発にかかる人件費をどうしても下げることができず、いずれ営業面において競争力を失っていくと思います。

*1:SI 業界におけるクラウドの現状は、今はまだ単なるwebシステム化にしかすぎないのかもしれませんが、近い将来、複数の企業にまたがる分散システム連携まで進化すると思います。なお私が「クラウド」という単語を使う場合は、主に分散コンピューティング技術あるいは分散システム連携の意味で使用します。
コメント(0) | トラックバック(0) | 18:19:04

2011/01/05(水)


ソースコードの可読性を議論する際に注意すべきことは、そもそも可読性とは一体なんなのか、なんのために議論するのか、それがどういう効果をもたらすのかを明確にしなければならないということです。プログラムにおける「可読性」という単語は非常に曖昧で明確な定義を持っておらず、個々人がそれぞれの我流解釈で論理展開するため、しばしば議論が発散したり、そもそも議論ができるのか? といった意見が必ず噴出するという、かなりナイーブな題材です。

ところが保守フェーズを経験したことのある多くのプログラマは、可読性の低いコードがソフトウェアの保守性を恐ろしいほどに下げてしまうことを身を持って経験しており、非常に深刻な問題だと認識しているにもかかわらず、いまだにたいした解決策も進展もないまま今日に至っている現状があります。一番やっかいなのは、問題意識のない上司や上流工程に携わる人達にこのことを理解してもらえず、保守にかかる工数や複雑さを担当者が一人で抱え込えこんでしまっている状況です。プログラミングの知識のない人にとっては理解のしづらい部分であり、上流と下流の担当が分かれている日本の組織構造においては、特に顕著にあらわれる問題ですね。

以前のエントリでも書きましたが、今後は保守フェーズが長期化する時代が来ると予想されます。IT業界に携わる技術者は、まず可読性に関する問題をしっかりと認識し、周りに認知してもらうよう努力する必要があると思います。そうしないといつまで経っても事態が改善されず、自分の首がどんどん絞まっていくだけですので……。
コメント(1) | トラックバック(0) | 12:47:14

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。