2009年11月

インターンシップ終了後

サブリーダーの吉田です。

ハイパーキャンパスでインターンシップに企業側として参加しており、今年は三人もの学生が参加してくれました。

私が学生の頃では、手当も出ないのに夏休みに毎日会社に行くなんて考えられなかったのですが、今は学校側で単位を貰えるなどの制度として整備しているところも多いです。
学生に取っても自分が就職しようと考えている業界のことが肌で感じる数少ない機会なのではないでしょうか。就職してみたら想像していたのと大きく違って仕事に魅力を感じなかったということもあるようですし、仕事としてやっていきたいかと思えるかが一つポイントではないでしょうか。

インターンシップは私が会社にいない時期に重なってしまい、学生と接する機会は少なかったのですが、一応担当者でしたので学生からのお礼の手紙を頂いた時にはうれしくなりました。メールが凄い勢いで飛び交う時代に、紙できちんと書いた手紙には独特の暖かみがあるように思います。そこには間違いなく書いた人がある程度の時間をかけて進めた後というのが読み取れて私なんかは嬉しくなってしまうのでしょう。

さらにハイパーキャンパスの中で毎年報告書という形で冊子にまとめているのがあって、うちの会社に来てくれた学生が作文を書いてくれたのを読みました。いろいろと気付いたり、考えるきっかけになったようでインターン担当者としては喜ばしい限りです。

まあ、そんなインターンシップですがハイパーキャンパスは今年度で終了することが決定しています!少し残念ですが、別な形で移行するというお話は聞けてますのでどんな風になるのかが楽しみでもあります。

出来ないことを頼まれたので、引き受ける?


リーダーの立川です。

なにかを依頼されたり依頼したりって事は、仕事をしていれば誰でも良くあることですよね。
それが出来ることであれ、出来ないことであれ。

出来ないことを頼まれた場合、あなたはどのような対応をしますか?

「出来ません」というのは簡単ですが、依頼者からの信頼はダダ落ちですし、かといって出来もしないことを出来るといって失敗したら・・・

では、こう考えてはどうでしょう。

(今は)出来ないことを頼まれたので(出来るようにして)引き受ける。

要するに、出来るようにしてしまえばいいのです。
頼まれた時には出来なくても、大抵のことは必死にやればできてしまうのではないでしょうか。

たまには失敗することもあるでしょう。
でも、きっと失敗から学ぶことも沢山あるはずです。

何事も「はじめて」はあるのですから、失敗を恐れずにチャレンジすることが大事かなと。。

オブジェクトを守ろう

 現在行っている案件は、提案することが多いこともあり、先日も打ち合わせに行ってきました。

案件には、ソースコードの修正も含まれています。ソースコード修正も色々です。そこで今回はソースコードの話をしたいと思います。

 プログラマの仕事と言うとプログラムを最初から作成するイメージを持つ方もいるかも知れません。しかし、殆どの案件は改造です。
例えば、ある機能を追加してくれとか、重いので軽くならないかなどです。昔からもそうですが、最近多くなったと言えば、バージョン関連でしょう。最近の事例を幾つか列挙してみます。

・IE6→IE7・IE8
・Windows XP→Windows Vista・Windows 7
・シングルコア(シングルスレッド)→マルチコア(マルチスレッド)
・IPv4→IPv6
・32bit→64bit

特に、最後の2つは他の中でも大きい出来事でしょう。

 改造なので、当然完成したソースはあります。自社が関わって新規作成したプログラムを改造することもありますが、それは稀でしょう。殆どが、他の会社の人が作成したプログラムです。たださせ、プログラマーの間では、自分が書いたソースも一定期間すると忘れるとか他人のソース同様と言わるぐらいです。それが他人の書いたプログラムはなおさら理解するのに苦労します。特に、スパゲティプログラムやスパゲティコードと呼ばれるプログラムになるとさらに厄介です。

 スパゲティプログラムやスパゲティコードとは反対に、苦労しない場合も多々あります。
例えば、
・ドキュメントがしっかりしている
・ソースコードにコメットが適切に入り、ソースコードと連動している
・ソースコードが見やすい
と言ったところでしょうか。


 以前、私が扱った案件では、オブジェクト指向が出来ていなかったり汎用性がないプログラムもありました。スパゲティプログラムとは行かないまでもとても読みにくいソースコードです。オブジェクト指向を取り入れている場合、比較的複雑な処理にはなりにくいと言われますが、それは設計の話です。設計が出来ていなければ、プログラムはオブジェクト指向とは言えません。

文章で説明するのは大変なのですが、オブジェクト指向の場合、クラスにあるメンバ変数はクラスの中だけで処理を完結するという原則を守るだけでもコードはすっきりします。それはメンバ変数がオブジェクトの場合に、クラスにアクセスした先で処理が行われていることがなくなるからです。

例えば、クラスにアクセスした先で処理が行われる処理の場合は以下のようなコードになっています。

return arrayList;

「arrayList」がメンバ変数でオブジェクトだった場合、取得する方は「arrayList」を自由に値を変えることが出来てしまいます。

そこを「return new ArrayList<Hoge>(arrayList);」にすることにより「arrayList」取得する先を別のオブジェクトとして返せば良いです。そうすれば、取得した先で変更しても呼び出し先のクラスのオブジェクトには影響しません。よって、「arrayList」の値を勝手に変えられることが無くなります。実際に、操作したければ、「arrayList」を宣言したクラスの中で処理を行えばよいです。

 大変な案件ほど、ソースコードも複雑なことが多いです。それは一概には言えませんが、仕様が複雑だったり、仕様変更が多かったりするからです。複雑なソースコードも一つだけ効用があるとすれば、自分は真似しないようにと思う事です(笑)。人の振り見て我が振り直せということです。

ローカルポート2

前回、ローカルポートの固定方法をご説明しましたが、
今回は、ローカルポートを固定することによって起こった問題をご紹介します。

通常のTCP/IP通信を行うにあたって、ローカルポートの固定設定を行っても、
なんら弊害はないのですが、通信異常がおこりクライアント側でコネクションを切断し、
再度接続する場合に、接続出来ない問題が発生します。

なぜ、接続できないかと言いますと、サーバ側でcloseしたソケットがTIME_WAIT状態になりしばらくの間破棄出来ないからで、破棄できない原理としては下記になります。

 最終的にコネクションがクローズした時、
 コネクションを確立し、データ伝送を実行後、
 アクティブクローズ(先にクローズ要求を出した)側と
 パッシブクローズ側でのやりとりは、
  アクティブ側      パッシブ側
       → ①FIN →
       ← ②ACK ←
       ← ③FIN ←
       → ④ACK →
 で終了します。
 
 このとき、パッシブ側は、自分の出した③FINに対して、
 ④ACKが確認できない場合、TIME_WAITとなり、
 通常、2~4分後、クローズ終了となります。

ローカルポートを設定していなければ、再接続時に前回と違うポートで接続しますので、問題なく接続出来ます。

 

試験項目の作成について

先日、第6回 g* ワークショップに参加してきました。

GrailsやGroovyの話がメインでしたが、綿引さんの「G*におけるソフトウェアテスト」の中でユニットテスト(単体テスト)について興味深い話をされていました。
それはプログラマーと、品質保証部門の人とでは試験の項目数が違っていたということでした。プログラマーは自分のソースに自信があるせいか試験が少なくなってしまう傾向があり、プログラムの品質が落ちていることの原因があるのではないかということでした。プログラマーでもきっちり試験項目を考えて実施、修正できる人も多いこととは思います。

最近、私のチームでも試験項目については、よく利用とされる試験項目を作成しておき、案件ごとに応じて必要な試験項目を選択して、その案件の試験項目にするように仕組みを考えているところです。
まずはフォーマットを作成し、実践し、見直しをかけるというサイクルで進めていこうと思います。
livedoor プロフィール
QRコード
QRコード
  • ライブドアブログ