ラベル 開発手法 の投稿を表示しています。 すべての投稿を表示
ラベル 開発手法 の投稿を表示しています。 すべての投稿を表示

2013年5月3日金曜日

システム開発会社として善良なる管理者の義務に基づき瑕疵のないシステム構成を設計すべき義務がある

雨で人格が完全に縮退しているみけです。

世間を騒がせたJINS PCのクレカ情報流出事故の報告が発表されたようです。


不正アクセス（JINSオンラインショップ）に関する調査結果（最終報告）




これをうけて、エンジニアの方々のエントリーがいくつかあるようです。



また、発表されたStruts2の不具合については下記の通り報告があるようです。


まあ、技術的な側面での考えはだいたいこんなもんかなとおもいます。


で？


技術的な側面に向けての記事書いたって、

もう二番煎じだし、

技術が優れている人がJava6以前使うなとかRuby1.9以前使うなとか

いろいろ発言されているので、

技術がない僕としては自分の興味にそってなんか書こうと思います。


で、僕はまあ、精神的にアレな人なので、

人間のもっと暗黒面というか、

どろくさい部分に目を向けたいと思います。


再発防止策から読み解いてみよう


JINSでは再発防止策を下記の通り発表しています。

  • PCI DSS(Payment Card Industry Data Security Standard)への準拠
  • 外部の決済代行サイトの利用

というわけで、JINSでは内部でカード決済の機能を使わないように、

システムの仕様を変更するということですね。


じゃ、なんで最初から決済代行サイトを採用していなかったのかな…(´・ω・｀)


理由はいろいろと考えられます。


  • 決済代行サービスの利用料が高かったのでカード決済の機能を作成したかった
  • カード決済機能に実績のあるベンダーから自前で機能を抱えることを提案された


いいにおいがプンプンする所で、

事故の根本原因(と考えられるもの)が

前者だとユーザー側にあって、後者だとユーザー側にないということになりますね。


実際にどういう経緯があったかはわかりませんが、

まあ、事故のあとの報告としては後者の方に倒したいところですね。


言葉遊び・数字あそび


ところでITシステムにおいて、tabula rasaなるユーザーにおいては、

システム開発のプロフェッショナルたるシステム開発会社にアドバイスをもとめるわけで、

先の理由の部分、いくらでも書き換えられます。


  • 決済代行サービスの利用料が高かいとベンダーから報告を受けたので、自前で開発することを決定した
  • カード決済機能に実績のあるベンダーから自前で機能を抱えることを提案された


こうなってくると、もうベンダーの方は完全に負け戦になります。

特にこういう提案資料とかの金額の部分って、いくらでもごまかせます。


こういった類の本が売られているほど、

数字というのはうそをつけるし、

数字によって騙されやすいもののようです。


まあ、企画提案書とかどうなっていたのかわからないから、

推測の域を出ませんけど、

もしかしたら、

スクラッチで開発する方が、外部の決済代行サービスを利用するよりも安くなるような

資料があるかもしれません。


だって


システムを開発する会社からすれば、

開発機能を増やして、

売上を高くしたいですからね…


(利益を高くするでないところに注意)


人間的、あまりに人間的


人間、一度成功を体験すると、

  • もっと挑戦をして、成功を体験したい
  • 同じ手法にて成功を増やしたい

こんな欲望が発生するかもしれません。

まあ、純粋に技術者だったら前者ですが、

企業としては確実に成功を狙いたいですから、

後者のほうを選ぶことが多いかもしれません。


ということで、Struts2のバージョンが云々とありますが、

その古いStruts2のバージョンでの成功の経験がある

リーダーないし、プロジェクトマネージャーないし、アーキテクトがいたので、

その古いStruts2を採用した可能性は否めません。


で、後者の方を選択する人の常として、

最新情報に疎いことが往々にしてあります。


といったわけでセキュリティイシューを見逃していたことは否定出来ないと思います。


で、笑えない話


ところで、JINSの発表を受けて僕がした適当なツイート、

結構リツイート頂いたようです。





JINSさん美味しいネタ提供ありがとうございました。

じゃなかった、

以前、僕が務めていた会社で、

システムを更改する案件があった時に、

お客さんに更改する旨伝えて、お金をいただくわけですが、

なんで機能が増えないのに、お金を支払わないとイケないわけ？

と文句を言われたことがありました。


システムの更改は、ハードウェアの故障率の増加とか、

ミドルウェア、ハードウェアの保守期限が切れるために

行わざるを得ないのですが、

ユーザーからすればベンダーの都合によりお金をとられるのは割にあわないと

感じているようです。


ハードウェア、ミドルウェアの保守期限が切れているため、

壊れてしまえば、もうどうすることもできなくなるのですが、

人間、壊れていないときに、壊れた時の話をしても

ピンときません。


だから更改の提案をするときは本当に嫌がられます。

で、僕のあの適当なツイートはあながち笑い事ではないです。


とりとめのない文章になって来ましたがマトメ


システムの開発・運用って、やっぱり人間的な

ドロドロしたものがあるので、

なんか、もう、アレですね。

(アレ＝適当に察して下さい)


というか、タイトルほとんど関係あらへんがな(´・ω・｀)



投稿者 時刻: 0 件のコメント:
ラベル: ,

2013年4月21日日曜日

オフショアがダメだと思う７つの理由

厨二病を発揮中のみけことみけです。

昨日のエントリーいろいろな方にファボもらいました。

ついでだから、アマゾンアフィリのリンクからポチをしてください。

本題


オフショアが日本-東アジア圏ではダメだと思う理由をあげます。


日本語が特殊すぎる

日本語は特殊な言語で多分機械翻訳はほぼ無理です。

無理と言われていた将棋がプロ棋士よりも強くなるというのは、

現実化しつつありますが、

日本語を他の言語に置き換えるのはまだまだ先の話だと思います。

したがって、日本語で書かれた仕様書をオフショア先に届けても、

まあ、良い感じに解釈してくれないでしょうね。


解決策 仕様書をもっと数学的に記述すること




プログラミングの技術レベルが低い

まあ、インターネッツ様のお陰で、

プログラミングに関するhow-to的なものを検索することは可能になっています。


だけど、もっとメンテナンスしやすいプログラム、

読みやすいプログラム、安全なプログラム、

こういったプログラムを書くためにはインターネッツ様だけでは足りません。

『達人プログラマー』とか、『Thought works アンソロジー』とか、『ドメイン駆動設計』とか

こういった書籍で勉強する必要があります。

でも、インドネシアやベトナムといったオフショア先にある国で

書店を回ってみましたが、

こういった書籍が置いてあるところは皆無でした。


これが意味するのは、オフショア先で技術が向上しているといっても、

それはコピペをする能力が向上しているだけで、

プログラムを書く能力が向上しているわけではありません。


機械化に関する考え方

オフショア先というのは人件費はマジ安いです。

ベトナムだとおそらく日本人一人雇う金額で、

ベトナム人５人くらいを雇えます。


でも、ここに落とし穴があります。


マシンの値段はあまり変わらないということです。

日本でビルド専用の結構いいマシンを買うと、

人件費の５分の２くらいで購入出来ます。


でも、オフショア先では人件費の２倍かかります。


したがってなんでもかんでも機械化するということに関する情熱は、

金額的に考えて５倍の差があります。


言い換えると面倒くさくて時間のかかる作業も、

彼らは人力でやろうとするし、

機械化したら仕事取られちゃうしで、

機械化するのを嫌います。


でも、日本では機械化してないとやってられませんね。


というわけで、テストを書くとかそういう考え方がオフショアでは希薄です。

Jenkins？そんなのオレがやるから導入するなよっていう感じだと思います。

結論 オレ(オフショアのオレくん)がリアルJenkinsだ！


責任というかなんというか

これな。

僕はこれインドネシアと中国で痛い目にあっているんだけど、

なにかしらのうまくいかないことがあると、

日本人の責任にされます。


オフショア先では教えたことはやるけど、

教えたことの応用はできなく、

それをやらないことの責めは

日本人にあることになります。

結論 オフショアがうまくいかないのは日本人が悪いニダ


コスト的なこと

まあ、テストを書かないというのは前の前に書いたことですし、

コピペが多いというのは最初のあたりに書いたことですが、

ここからの結果として、こんなことになります。

不具合が発生した場合、
  • 不具合箇所のきりわけ
  • 不具合箇所の修正
  • 不具合箇所の修正の確認
に膨大なコストがかかる。

で、コピペ技術のすぐれたオフショアプログラマー、

これらの技術はありません。

そこで！日本人登場ですよ！

日本人のエンジニアがこれらプログラムの森を進み抜き、

不具合箇所を修正します。


結論 日本人がプログラム書かないためのオフショアなのになんで日本人がプログラム書いてんすか？


トータルコスト

というわけで、コストをだいたいみてみると、

こんな感じになると思います。

ちなみにウォーターフォールを前提としてます。


モデル

計画
  • 工数 : 30人月
  • 開発期間 : 3ヶ月
  • 開発体制 :
    • 日本人SE : 1人x3ヶ月(ブリッジSE兼PM) + 0.5人x1ヶ月(アーキテクトとか考える人)
    • オフショア : 10人x3ヶ月

結果
  • 工数 : 30人月 + 30人月(日本人による修正)
  • 開発期間 : 6ヶ月(バグ取りの期間を含む)

収支(便宜上、日本人1人月100万、オフショア20万)
  • 予算 : 950万円
  • 費用 : 3350万円

その他
  • ブリッジSEの過労による精神障害の発生
  • 納期遅延による顧客との信頼関係の喪失


というわけで


オフショアするなら、オフショア人員一人あたり日本人一人つけといたほうが安全です。

あれ、それってオフショアの意味なくない？


あと、7個も理由書いてないや…(´・ω・｀)
投稿者 時刻: 0 件のコメント:
ラベル: ,

2013年4月20日土曜日

日本からプログラマ技術者がいなくなるそうです。

マイナビにプログラマーとして登録しているので、

いろいろとスカウトメールが届きます。

その中からお馬鹿なものがあったので、紹介します。

日本からプログラマ技術者が・・・・！?

突然のメールにて失礼致します。 株式会社■■　代表取締役の◯◯と申します。

私は大袈裟ではなく近いうちに日本からプログラミングの仕事がなくなる日がくるのではな
いかと考えています。理由は二つあります。

ひとつは、オフショア開発の増加です。インド、中国で注目され始めたオフショア開発ですが、
リーマンショック以降情報システム業界の仕事量が激減した年でも、その発注量は増え続け
ています。しかも、発注先もベトナム、フィリピン、ミャンマーと次々に広がっています。
もうひとつの理由は、セールスフォースに代表されるsaas環境の発達です。触った事のある人
であればわかると思いますが、ノンプログラミングで大概の事が実現できるのです。

このような環境下、あなたは本当に今のままのキャリアプランで大丈夫でしょうか？
■■では、会社として環境の変化に対応し、技術者がキャリアアップを重ねながら存在
意義を保つ環境を整えました。


いいですね、なにもできないプログラマーを駆逐するという考え。

僕もうつ病でダメ人間なので駆逐されたいです。

ですが、プログラミングする人は、
これからはますますちゃんと情報工学などの教育を受けた
人であるべきだと思っているので、
この人のようなプログラミングなんてしなくていいやという考えの人とは
僕の考えは合わなそうだったので、
丁重にお断り申し上げました。

以下、その文面。

馬鹿ですか？
無知・無学・無能で人を使い捨ての駒としてしか考えていない筋脳鬼畜馬鹿とは一緒に仕事できないので辞退します。

(1)オフショアについて

オフショア開発のブリッジSEの経験をしていますが、
オフショアで開発したプログラムのほとんどは日本で書きなおされます。
その理由は日本語という言語が、言語学的に特殊すぎて
機械翻訳が難しいためです。
そのためオフショア先では誤解を元に作成されたプログラムが量産され、
結果、日本人がプログラムを修正するという事例が多数発生しています。
したがって、どんなにオフショアにプログラム開発を依頼しても、
日本人がプログラムを修正するという作業がある限り、
プログラマーが不要になるということはありえないと考えております。
また、当初の見積もりコストの１０倍に膨れ上がったプロジェクトを
僕はいくつか知っています。

これらの原因となっているオフショア先のプログラム開発の能力については、
オフショア先となるアジア各国では、
プログラムをちゃんと書くための書籍類が不足していて、
(それは各国の通貨がドルに対して弱いため)
・リファクタリングが可能なコード
・変更に強いコード
・ちゃんとテストコードのあるコード
を書く能力が乏しいという事実があります。

実際に僕はインドネシアやベトナムの書籍店を回ってみましたが、
プログラミングに関する書籍は非常に少ないばかりか、
プロフェッショナルの使用に耐えうるような書籍はほぼ皆無でした。

オフショア開発で成功するための必要最低な条件は、僕の経験上以下の３つになります。
・時差が少ない
・言語間の壁が小さい(英語-スペイン語など)
・オフショア先でもプログラミングに関するちゃんとした書籍が入手できる
　- 10日でできるAndroidのような書籍は論外です。
　- マーティン・ファウラーなどの書籍のことを指しています。

上記の事実を勘案すると、東アジア圏ではオフショア開発が
成功するというのはほとんど不可能に近いです。

上記の条件を満たせるオフショア環境は今のところ、
US-ブラジルの間だけではないかと存じています。
実際、ブラジルでオフショア開発が成功したという事例はよく聞きます。

貴殿のプログラマー不要説がこれらの必要条件を精査した結果でのものと
思えるほどには説得力のない説明であったので、
貴殿が業界の勉強や実体の調査をおこなっていないと判断するに至りました。

(2)Google Apps、GeNexus、Salesforce等のプログラミングレスアプリケーションについて

これらの既存アプリケーションの組み合わせによる業務アプリ作成は、
フルスクラッチからの開発よりもかなり高速な開発を実現できるのは事実です。

しかし、Salesforceを僕よりもご存知であろうとおもいますが、
業務的に性格を期すアプリケーションを構築するためには、
(例えば受注が成立した場合に関係者にメールを送付して、
現在ある在庫を確保するという業務)
Google AppsではJavascript、
GeNexusでは独自のプログラミング言語、
SalesforceではJavaに似た独自のプログラミング言語
でのカスタマイズが必要になります。

これらはC、Java、C#等の低水準の言語で恩恵があったIDEのサポートを得られず、
入力補完が効かない、型安全でないという生産性低下の要因を抱えています。
入力補完がない型安全でないということは、
コンパイル時にプログラムが正しいことを証明できず、
実行時にエラーとして判明するため、
不具合箇所の検出、修正に多大なるコストがかかります。

C、Java、C#といった言語の場合、
見かけ上は開発コストがかかるように見えますが、
プログラミングレス言語に比べて、
バグ検出・修正コストを調整できるメリットがあり、
コストは大して変わらないと存じます。

以上二点から貴殿のプログラマー不要という考えには同意できかねるため、
本オファーを辞退させていただきたいと思います。


…どこが丁重やねん…(´・ω・｀)

投稿者 時刻: 2 件のコメント:
ラベル: ,

2013年2月17日日曜日

今更だから笑えるオレオレフレームワーク

自分のブログに書いても誰もたどり着かないので、ここにも書く(元ネタ1、元ネタ2)。

僕は最近夜10時くらいに寝て、2時30分、5時30分に起きるという生活パターンになっています。
(２日連続しただけ…)


@btnrougeさんが荒れてんだが…


というわけで、5時30分に目が覚めた僕は、

レディグレイをいれてTwitterをひらいた。

というのも、iTunesが僕のiPhone4Sに入っている

音楽を消去して同期しようとするから、

「iTunes使いづらくなったな」とツイートしようとしてだな、

まあTwitterを見たわけだ。


ああ、どうでもいいや、そうでなくて、

Twitterを見たら、@btnrougeさんが大暴れしてたんですよ。


曰く





古代、いにしえの話


某前の前の会社にいた時にDWHのリプレースをするという案件があったわけだ。

一応、そのDWHは元々某前の前の会社が作成したもので、

お客様の都合により継続的に開発することを断念したシステムだった。


元々継続的に受注→開発することを想定していたので、

あまりドキュメントが正確ではなかった。

いや、正しく言おう。

ドキュメントが正確に書かれているSIerのプロジェクトなんて
ひとつもありゃしないんだということを。


そして、これもよくあることだが、その初代のDWHを作成する際に、

要求仕様を決めた人っていうのは他の部署に転属していて、

もはやそのDWHで出力される帳票がどういう理屈でデータを集計して、

吐き出しているかを知っている人なんて皆無だった。

まあ、こんなの自社サービスで開発しているプロダクトでなければ、

よっぽどのことがない限り分かる人なんていないわけだよね。


RFPあるある


で、まあ、サーバーとかの耐用年数がアレになったので、

サーバーをリプレースすることになったのだが、

要求を書くことのできる人がいないわけで、

故あってそのDWHを使っているユーザー部門に

人を派遣している某前の前の会社がRFPを書くことになったわけなのです。


で、RFPを書くことになった担当者というのが、

まあ所謂、

娘「パパァ、意識たかい、たかいやってぇ〜」
  パパ「ほうら、意識たかい、たか〜い」


社員で
(別にバカにはしていませんので…
って書くと本当にバカにしているように
受け取られますが、
本当にバカにしていません。
むしろ僕は本当に意識が低いので、
敬意の念を抱くほどです。)

意識高く、要領よく、良い感じのRFPを書いてくれたわけです。


検索条件の画面定義と出力項目の意味と入力データの仕様と運用周りの要求だけ…


どういう業務をやっていて、どういうシチュエーションで、

どういうデータが必要になるか、それはどのデータのどの部分にあるので、

どういう風に集計して欲しいのかという情報は一切なし。


たぶん、そのRFPに書かれていたこと、

およびRFPを書いた人にユーザーが求めていたことは、

次のたった一つの短歌で言い表すことができる。


なるべくね

  はやくやすく

    作ってよ

  今と同じで

    後はよろしく( ｀・∀・´)ﾉﾖﾛｼｸ
        (結構字余り)



いわゆる、丸投げですね。





…以下、力尽きた…(元ネタ)


投稿者 時刻: 0 件のコメント:
ラベル:

2012年12月7日金曜日

git、svn、mercurial、Bazaar、何一つ使えないIT技術者は技術者辞めて下さい

以上。
投稿者 時刻: 2 件のコメント:
ラベル: , ,

2012年12月5日水曜日

オフショアに10万払うんなら、日本のエンジニアに2００万払う準備をしておけ

自殺未遂もしたし、

この世にもう未練のないミケです。


オフショア


オフショアのエンジニアの

能力は馬鹿に出来ません。


彼らはネットからサンプルを拾ってきて、

真似して、すぐものを作り上げます。


凄いスキルだと思います。

だから、彼らに月10万円払って、

雇うのは経営的な観点からお勧めします。




うひひ



オフショア


とりあえず、持ち上げておきましたが、

オフショアの人の能力で決定的に足りないものがあります。


それはトラブルシューティングの能力です。


僕は一昨日までの３日間、

オフショアの人達のトラブルシューティングに付き合わされました。


そこで、まず気付いたのが、彼らの報告です。

〇〇ができない！


は？意味がわからない？


何をしようとして、何をどういう状況でやったら、本来はこうなるべきなのに、こうなってしまって、◯◯ができない。

っていう風に報告してくれれば、検討はつくかもしれないんですが、


そういう状況を全く報告してくれない。


まず、基本的な主語が欠けているから、

主語を推測するためにあれこれ質問しなければならない。

これで、二～三回のメールを投げるから、

まず、何が問題になっているかを把握するために

１日以上かかります。


次に何をやったかを確認します。

これがまた面倒で、奴らコピペでやっているんで、

何をやったかを説明できないんです。

これまた我々が推測しながら、

何をやったかを確認するので、

まあ１日位上はかかります。


次に、条件の確認をします。

これが一番ひどくて、

オフショアの人はすべての条件が同じと

考えたりしていますが、

そんなことはありえない。

これは聴きだすのに数日かかります。


この時点で約一週間はかかります。


オフショア


さて、問題を解決するために色々とコマンドを打たせるわけですが、

これがまた一筋縄ではいかない。


このコマンドにはどういう意味があるのかと、

急に好奇心旺盛になったり、

コマンドの順番を間違えたり(これで振り出しに戻る)

はっきり言って、解決は二週間くらいかかります。


この前、私がトラブルを解決したときは、

コマンドのログのハードコピーを送りつけました。

それくらいしないと奴ら解決できません。


なんだかんだ言って、結局問題を解決するためには

一ヶ月くらいかかります。


オフショア


こんなくだらないことに時間を、しかも二人分の時間を費やすくらいなら、

一人優秀な日本人のエンジニアを雇ったほうがお得です。


もし、オフショア+普通の日本人エンジニアなら10 + 100万円で110万円 x 2ヶ月で220万円です。

優秀な日本人エンジニアを雇えば200万円 x 1ヶ月で200万円です。

どっちが安いですか？


まあ、そのあたりは経営判断に任せましょう。


トラブルシューティングしている間に、仕様書書き終えたっしょと言われて、

むかついているので、僕はもうロヒプノールを飲んで寝ます。


終わり。
投稿者 時刻: 0 件のコメント:
ラベル:

2012年12月3日月曜日

僕は怒っている

オーバードーズしました。

事の顛末を書くのも、ありうるべき姿かなとおもいますので、

書きます。

ちなみに毒だらけです。

その辺はご容赦下さい。


また、原因の多くは僕の大人の発達障害だと思っています。






PHP氏ね


今、現在、僕は月額10万円でアプリケーションの仕様書を書く仕事をしています。

(Excel方眼紙は書いていない)

その契約では実装・サーバー設定・リリースは僕の仕事外です。

ちなみに僕の契約条件を総括すると

  • PHPはできない。全く知らない。これは相手方も了承済み。
  • JavaとGroovyしかやりませんよと提言している。
  • 体調の関係で冬は仕事できませんと契約書に記述している。相手方も了承済み。
  • データベースの設定はやらない。これは僕のお客さんのお客さんがどのようなサーバーを利用するかということを決定するので、僕はタッチできない。そもそもお客さんのお客さんとの交渉する場に入ることはできない。
  • タスクの管理などはbitbucketのチケットを使いたいと進言して、相手方も了承している。
  • VCSとしてGitを使いたいと提案して、相手方の了承を得ている。
  • 僕はリリース・アプリ制作等の作業はやらない。相手方からの提案。僕も了承済み
  • 相手方はオフショア開発なので、ドキュメントは英語で書く。

さて、相手方のスキルなのですが、

  • PHP、しかも素のPHPしかできない。
  • mysqlはphpMyAdminしか使えない。CUIは使えない。
  • git使えない。
  • チケットでタスク管理、なにそれ美味しいの状態






さて、この度アプリをリリースすることになりました。






リリースの際に、





  • リリースの際に、zipファイルを渡されて、リリースよろっ(・ω<)。された




この時点で契約違反(PHP知らないから、PHPに関わりませんという契約の違反)なので、

これに応じなければいいのですが、

応じちゃったのがまずかったです。

なぜなら、納品先のお客さんのサーバー情報、知っているの僕だけ←


(とは言いつつ、サーバー情報を記述したWikiページ教えているんですけどね…)

まあ、この時点でも契約違反しているんですが…

さて、渡されたPHPファイルですが、

PHPよくわからないので、テストを探しました。

テストがねぇ！

おい、お前これ本気でヤル気あんのか？

まあ、リリースだけしろということなので(契約違反ですが…)

コードベースをちゃんと整えておきたいので、

bitbucketにgitにちゃんとコミットしてから、

gitでリリースしました。

データベーススキーマとかもちゃんと調べて

設定等もちゃんと接続するようにしてリリースしました。

つながんねーよ！コラ！



リリースしてから、なんか繋がんねーよと言われました。

知らんがな…

  • ちゃんとテストしたんですか？
  • リリースの際にスキーマ設定とかちゃんと指示しましたか？
  • お客さんの環境の下調べしましたか？


こういう不信感が募ってきました。

まあ、いいんですけどね…

僕、ちゃんとやることやったし…(´・ω・｀)

やっと契約通りに戻った、つかの間



さて、そういった状況の中、

オフショア先にリリースさせる(これはやっと契約に戻った)のでログイン先の情報教えてくれ

とメールが来ました。

メールにパスワードを書くのはド素人がやることなので、

ログイン情報(mysqlとsshのユーザー、パスワード)の記載しているWikiのurlを教えました。

もちろん、リリース手順を記載しているWikiページのurlも教えました。

なんか、オフショア先のデベロッパーさん、git詳しくなさそうなので、

gitの説明も英語で書きました。

すごい、僕には至れり尽くせりの対応をしました。

そもそも、プロダクション環境なのでphpMyAdminとかのポートを開放している訳ありませんし、

ちゃんとsshでつないで、mysqlをコマンドで叩けよ！とアドバイスを送りました。

僕、もう怒った



さて、そうしてしばらくするとオフショア先から、

  • mysqlに繋げないんだけど、なんか設定必要？


とかいうメールが来ました。



…



は？

教えましたけど…

まあ、いいんですけど、

相手方からも

  • mysqlのログイン画面はどこですか？ユーザー設定の画面はどこですか？
  • rootのパスワードを教えてください
  • リリース情報教えてくれ


…



お前ら何回オレから説明受ければ気が済むんだよ！

ちゃんとWikiに書いとるやんってメールを返しました。

その後



なんか、僕、怒っちゃったので、

その後の記憶がありません。

なんとなくロヒプノールを80錠ほど飲んだ記憶だけがあります。

その足で、自治会の会長の仕事が、通常鬱病と、季節性鬱病のせいで

仕事がはかどりませんという掲示用の紙を貼り付けた記憶だけが残っています。


その後２




気付いたら、救急隊員が８人位着ていました。

気付いたら、1m歩く毎にこけていました。

気付いたら、階段登ろうとして、他の家のドアに頭ぶつけていました。

気付いたら、救急車で運ばれていました。

気付いたら、病院で点滴受けていました。

気付いたら、オヤジが病院にいました。

気付いたら、家で寝ていました。

後は覚えていません。

反省



生まれてきて、大人の発達障害してすみません。

僕、この世に居ないほうがいいですね。

そして、phpMyAdminしか使えないで、mysqlできると言っている輩は死んでください。

投稿者 時刻: 0 件のコメント:
ラベル: , , ,

2012年8月5日日曜日

工数盛っちゃいましょう

みけです。

ドラクエやばいですね。

ハマります。

工数削減＝売上減なのか？


まあ、単なる屁理屈を述べるんですけどね、

「減った分の工数も稼働していたことにして、工数盛っちゃえ」

とおもいます。


ShinSemiyaの日記 - なぜSIerの管理職は変化を受け入れないのか


一番大きいのはJenkinsの自動テストを提案し、「手動テストを自動テストに置き換えれば手動テストの工数を他に回せます！」と言ったら「減った分の工数だけ売上が減るじゃないか！」と言われた点だと思う。最大の問題は契約。


「減った分の工数だけ売上が減るじゃないか！」は屁理屈なので、

屁理屈で返しましょう。


少しガチ


少しだけガチなことを言えば、

企業の経営にとっては売上よりも利益のほうが大切です。

売上があっても、利益がない会社は力尽きていきます。

オワリ
投稿者 時刻: 1 件のコメント:
ラベル:

2012年1月5日木曜日

Oekonomisch-philosophische Manuskripte -- マルクス『経済学・哲学草稿』

さてこのエントリは…


巷のエンジニアで話題のテーマ：設計に関するエントリ


の2つのエントリーを読んで、ちょっと微妙な横槍を失敗したオフショアでの現場の技術者についての評価をたまたまやったので、そんな話をしつつ、これまた巷のエンジニアで話題のテーマである英語について


和書じゃないと売れないなんて、おまいら何してんだと叱責しつつ、たまたま読んでいたカール・マルクスの『経済学・哲学草稿』(岩波文庫)のある一説を踏まえて、昨今の話題になっている少子化および就職難からショッキングな一節を引用して、少子化と就職難について論じてみるという無謀な試みをしたいと思います。

まあ、色々と取り込んだ関係上、焦点がぼやけていますので、少し対象読者を絞りつつ書きたいと思います。

対象読者


  • 英語を読むのが苦痛というか、日本語の文献しか読まないというか、日本語の文献も読まないエンジニア
  • 大学でまともに勉強しないで、就職活動に勤しむアレな人とそれを強いる企業の人事部
  • 要求と仕様と実装の板挟みに合っている人
  • リブ管理というお仕事で、決められたフローに基づき朝に申請を受けたソースを夕方頃やっと編集していいよとドヤ顔している超高速なGitみたいな人
  • TOCを下げて利益を得たい人

設計の話


@ryoasai74さんのお話


非常に面白い内容で、松屋で読んでいたんですが、かなり熱中して読んでいました。問題点としては
  • ウォーターフォールから離れられないこと
  • 実装する立場ではないので実現可能性の観点が仕様設計に盛り込まれていないこと

というあたりが問題だったと思います。

ウォーターフォールから離れられないことについては、

@megascusさんのエントリー


に書いてる要点

  • 昔はマシンのコストが高かったから、コストの低い人間が頑張って効率的に計算機を使えるように頑張るというのが、計算機の低廉化によりそんなことがなくなってきているんだよ

という解説が、まあ的を得ていると思います。

オレのデスマ


なんかで思ったんですが、実装と企画は同時進行できたらいいよねなんて思ったりするわけであります。

夢を見るのは構わないですよっと。現実も見て欲しいんですね。

G****とかD***N*とかのプラットフォームを既に持っている会社はそれほどコストかけなくても、まあコピゲーは開発できるんですね。

で、そういうプラットフォームを持っている会社はどの層が課金するユーザーであるかといったデータを持っていますし、本屋でちょっと探せばそういうデータは見つけられます。どの層のユーザーにヒットを出せるかというのも、まあ、あの手この手を打ちながらですけど、探るパターンは持っていたりしますし、まあ、今更ね、そういうソーシャルなところに新規参入したって、時間がかかって成果が上がらんだけですよなんて、冗談半分に酔狂で語ってみるわけです。

オフショアのエンジニア


というわけで、オフショアの開発を振り返るのですが、実は@megascusさんのエントリーは、半分正しいのですが、オフショアでは半分正しくないんです。

というのも、スマートフォンを買うのに、給料3ヶ月分もかかるオフショア先の環境では、やはりマシンは高いんです。

だから、オフショアで開発するには、結局ウォーターフォールが前提になってくるわけです。

日本 + 西欧諸国レベルで開発を考える場合は、企画の段階で開発者が入ってCIでリスクを軽減していくというアプローチは生産性が高くなりますが、

なんてことはない、オフショアの国々ではマシンが高いから、

人件費でやったほうがよいというCIとかに慣れた我々には想像のつかないソリューションが大手を振って歩いているわけです。

それだって、コストはめちゃくちゃ安いんです。

オフショア開発者の技術スキル


実はオフショア先の国々では、そんな低賃金ながらも、実はIT系の企業は高収入ということで人気があって、金融の分野に続いて二番目に人気が高いそうです。

というわけで、実はオフショア先の国々のエンジニアは結構優秀だったりするわけです。

英語とかもスラスラしゃべります。

エンジニアの英語嫌い


だから、日本語で書かれた技術書なんて別にいらないし、

別に技評の本が日本人にとってユーザービリティが高くても、オライリーのほうがバリバリ活躍するし、

洋書の方が安価で、早く情報が得られる。

TOEICが大体600点なかばくらいの私と英語で話していて、別に困らないから、

オフショア先のデベロッパーの方々は、まあ大体TOEIC600点くらいのスコアは取れるでしょうね。

で、これは彼らの学歴が良いことにも関係あるし、いい大学に行けるということは彼らはそのプレッシャーに負けずに勉強しているわけで、

やっぱり優秀なわけです。

英語ができない日本人がオフショアでコストが安くなるからと言って、行こうものなら、自分たちの考慮不足をガンガン指摘されます。

@ryoasai74さんの記事に戻って


不良っぽいAPIとか接続定義書とかについても、多分、ガンガンに文句言われるので、

まあ、プライドだけは高い某○ティー・ティーのことですから、メンツ潰れて、だからオフショアはダメなんだって

言い出しかねない……あ、懇意にしていただいている人で某エヌ・○・ティー系列の方がいるから、悪口はよしておこう…

いや、何が言いたいかというと、

オフショアの技術者舐めたらアカンぜよ


というわけです。

少子化


で、ここで、たまたま読んでいたマルクスの『経済学・哲学草稿』の一節を引用するのですが、

あらゆる他の商品の場合と同様に、人間に対する需要が、必然的に人間の生産を規制する。

マルクス『経済学・哲学草稿』(岩波文庫、p.18)


ちうことで、実は、日本の少子化とか就職難とかいった問題は、

日本人の需要が少ないから、子供はいらないし、就職もできない

ということではないのかな…などと思うわけです。

マルクスは『経済学・哲学草稿』のほかで『ドイツ・イデオロギー』(岩波文庫)、『資本論』(岩波文庫)などで、

労働者の「再生産」という表現をよく使っています。

これは『経済学・哲学草稿』の一部ではこのように書かれています。

労賃にとって最低の、どうしても必要な水準は、…(中略)…、労働者が家族を扶養することができ、労働者という種族が死滅しないですむという線である。

マルクス『経済学・哲学草稿』(岩波文庫、p.18)


ということから推測すると、日本人の労働者としての需要は、高い給料を要求するくせに、仕事は賃金の安いオフショア先と変わらんというわけで、需要がなくなりつつあるのではないでしょうか。

そんあわけで、日本人という種別はこれから絶滅への道に歩んでいくので、まあ別に子供作らなくてもいいし、まあ、若い人が就職できなくてもいいんじゃないなんて思うわけです。

で、私は、この状況に対して、何か抗えということも思いません。

実はマルクスの著作から、勘違いした何人かが共産主義だとかコミュニズムだとか、ソビエトだとか、赤とかいう過激な発想や、

まあ、こんな張り紙をする人が現れるわけです。


大阪市役所の大阪府労組連の張り紙がヤバイｗｗｗｗｗｗｗｗｗｗｗ

あの、ひとこと言っておきますが、マルクスも、エンゲルスも、彼らが擁護しているように見せかけている労働者ではありませんよ。

マルクスは会社経営者であるエンゲルスから金を無心して、呑んだくれているオヤジですし、

エンゲルスは会社経営者で労働者ではなく資本家の方の立場です。

マルクスの本当に滑稽なところは、「お前労働者の味方のふりして、実は労働者じゃないだろ！」というような悪酔いしたヒゲ爺が

シュールに労働者問題を達観したような顔で述べていく所ですよ。

これは滑稽でないとは思えませんね。

あ、で話を少し戻すと、マルクスは抗えといったのではなくて、現実を直視しろと言っていたのではないかななどと思う、今日この頃なのであります。

柄谷行人


で、私がマルクスを読むきっかけになったのが、柄谷行人の『マルクスその可能性の中心』(講談社学術文庫)という本なのですが、これは非常に面白いので、まあ読んでみてください。労働者とかそういうネタは転がっていなくて、あくまで文学として読もうとする試みですから。


で、そんな柄谷行人が反原発のデモに参加していたみたいです。



デモというのは非常に効果があった。かつては。

なぜなら機械の値段が高い時に、賃金の安い労働者が機械を壊すのだから。

@megascusさんの話に戻る


今はマシンは安くて人件費は高いんですって。

だから、今デモなんかやったって、あまり費用対効果はない。

2チャンネラー湘南ゴミ拾いオフ


なんてイベントがありました。

コレですよ。

警察すら出てきていないんですよ。

効果は、う～ん、まあともかく、費用はほとんどかかっていないはず…


結び



さて、話がどんどんとあらぬ方向に突き進みつつあるので、強引に終わりにするわけですが、

  • 英語に取り組まないエンジニアは再生産を諦めてください。
    • それでも再生産しちゃった場合は、自分と同じレベルかそれ以下の再生産しかできないと諦めましょう。
    • 英語に取り組まないなら真摯に最新技術にキャッチアップしてください。きっと英語が必要になるんですけど…
  • オフショアする場合は、オフショア先は旧プロセスを使っていることが多々あります。
    • アジャイルっぽいのを目指す場合は、オフショア先にマシンの投資をしてあげてください。
      • 賃金が低いからって無茶な要求はしないでください。マシンスペックが低いんですよ。マシンスペックが高い自分ができないことを求めないで挙げてください。
      • 賃金が違いからって上から目線やめましょう。相手のほうがスキルに富んでいることがあります。経緯を払ってください。



ちなみに、私、本当に英語が苦手でした。

今でこそ、「a」と「the」の違いを感覚で使い分けられるようになりました。

  • This is an apple.
  • This is the apple.

中学の時に習った

He was so tired that he canceled the party.


とか、高校で習うような、

I would appreciate, if you would have stopped smoking.


みたいなのも、まあなんとなくわかります。

ちなみに、中学の時の英語の平均を晒すと5段階で3、高校の時に英語の平均を晒すと5段階で2、大学での英語の成績は可がほとんどでした。

今でも英語を時折やっているのは、ずっと出来なかったので、英語コンプレックスがあって勉強しているだけです。

ちなみに、大学でスペイン語が第二外国語でした。成績の平均は優でしたけど…

ちなみに、大学で第三外国語にラテン語やっていました。成績の平均は優でしたけど…

ちなみに、大学で第四外国語でフランス語をやりました。成績は不可でした。

ちなみに、大学で必要にかられて第五外国語にイタリア語をやりました。授業を途中で出なくなりました。

ちなみに、大学入試センター試験での英語の成績は一回目154点、二回目197点でした。

ちなみに、某大学の後期試験の得点の配点は、英語100、数学100、物理300で、物理満点、数学80点、英語80点くらいで入学しました。

投稿者 時刻: 0 件のコメント:
ラベル: ,

2012年1月1日日曜日

Summary of 2011 and objective of 2012

Now looking back to 2011, there was some change in my environment.

About 2011


From my impression, changes are ...

  • Found new jobs at TopGate Inc.
  • Attracted Google's technologies.
  • Attracted Groovy programming language.
  • Trying to do off-shore work in Vietnam.

About No.2

I just started to study Android technologies at a community named Saitama Android Board.
As I learned Android technologies, I found that there are limitation of Android to create an interesting application without any server or any service.
So I had become tending to learn cloud technologies like Google App Engine.


About No.1

And it was good time to learn Google App Engine because my former company gave me a time to learn Google technologies. But in my former company there is some wasting and boring procedure to search and to learn new technologies. So I decided to change my job, to get a new environment. And luckily vvakame, one of my twitter friend, told me to work together in TopGate Inc where there are some programmers familiar with Google technologies. And I changed my employment from former one to TopGate Inc.


About No.3

At the same time to change my job, I was introduced to Groovy programming language. It was kimkou_26, one of my twitter friend, that told me the most powerful and exciting language. Groovy works on Java Virtual Machine with supporting almost all of Java technologies and with light syntax. Groovy attracted me very much. And with Groovy I met some programmers on groovy community.


If you ask me to decide which gave more impact on me, Google or Groovy, it is too difficult for me to decide. Because the objective is different and I love both technologies.


About No.4

Working foreign country become common to programmers in Japan. Because Japanese Yen is becoming so strong among these days that it costs higher to employ Japanese than to employ Chinese or Vietnamese for them to do same thing. In my project it finished in failure. But I'll get success on off-shore projects this year.


Next 2012


I'd like to work as listed bellow.

  • To work on Google Apps Installation
  • Create TopGate's additional value
  • To get success on off-shore project

About No.3

As I mentioned before, I'd like to get success in off-shore projects. From the view of the cost of project to work outside Japan cannot be ignored.


About No.1

This is my objective to work installation Google Apps to a customer. It seems Google considers Google Apps as their most successful cloud technology. And I think the tendency of companies to move from owning their server to using existing service becomes more popular. So it is business chance to become major company.


About No.2

TopGate Inc. is the re-seller of Google technologies. But I want to add additional G technology, I call it Yet Another G Technology. I mean Groovy and its co-production, like Grails, Griffon, Gradle, with these production we can offer some solutions faster than ordinal technologies. And this may cause create a value for our customer. By becoming familiar with these technologies, we -- TopGate Inc. -- will be able to establish our excellent brand image.


To reader of this blog and to another person, thank you this year!


投稿者 時刻: 0 件のコメント:
ラベル: , , , , , ,

2011年12月30日金曜日

あんまり書きたくない投稿

まあ、このブログを定期的に購読されている方
(そんなのいるかどうか知らんが…)
は、ご存知のことかと思いますが、

私、今月半ばまでソーシャルゲームの開発でベトナムでデスマっていました。
結局、このプロジェクトは発注者側が契約解除という形でプロジェクトが収束したのですが…

その時に感じた今のソーシャルゲーム開発の落とし所と言うか、SIに慣れきったオレには開発プロセスとしてあかんやろコレと思ったところを列挙していきます。
もちろん、私自身のマネージメント能力が足りない部分もあるので、そのあたりは良い感じに読んでください。
また、私は開発者であるので、あくまで開発者側の視点であるということも考慮の上、読んでください。

  • 発注者(ゲーム企画)側はたいてい要求と仕様の違いを全く理解していない。
  • 最初に仕様書とか要望書とか渡されるが、そんなものは当てにはならない。かならず、プロジェクトの終盤で大きな変更が入る。
  • 新規にソーシャルゲームに参加しても勝てない。
  • 発注者(ゲーム企画者)側があとは実装するだけと言っても、それを信用してはならない。
  • 発注者(ゲーム企画者)側が仕様が確定していると言っている場合は、たいてい開発可能性を考慮していない上での仕様確定なので、その分の仕様確定プロセスは見積もりに載せておいたほうがよい
  • コピーゲームっぽい要素があって、そのゲームをやったことがないなら、そのゲームを勉強する期間を1ゲームに付き1人月程度は工数に上乗せしたほうがよい
    • 発注者(ゲーム企画者)側が該当するゲームに関連するゲームの開発を始めてやる場合には、仕変があとから大量変更するので、参考ゲームの数分、人月を上乗せしたほうがよい
  • 仕様変更が発生した場合は、リリース時期等の調整を行いましょうと確約しても、そんなものは守られない
  • マルチプラットフォームでやりたいということはしばしばあるが、自社でマルチプラットフォームの経験がない、あるいは発注者(ゲーム企画者)側がその経験がない場合は、対応しないほうが良い。それがどんな理由を並べられたとしても。もし、それでもとゴリ押しされるなら工数は2倍とっとけ。
  • 発注者(ゲーム企画者)側で画面を用意しますとかいうことを言われるが、この画面の精度は当てにしてはならない。はっきり言って同じ画面を作りなおすだけの工数は上乗せしておけ。
  • 運用を考慮して設計して欲しいと言われたら、実開発コストに倍位の工数を加算しておいたほうがよい。


いろいろと不満だったことを書き連ねました。

少しづつ解説。

No.1とNo.4とNo.5に関して

まあ、得てして発注者というのは要求と仕様との区別はわからないものです。
これは仕方ありません。
だから、こういう部分についてはプロフェッショナルである開発者側がちゃんと要求と仕様とを整理する必要があります。

…で、ここからが重要ですが、

「あとは実装するだけ」と発注者側が言ったとしても、要求から仕様を抽出、もとい、ちゃんと要求を整理する必要はあります。
発注者のもう要求も整理できているし、仕様も固まっているなんていう甘い文句につられてはいけません。

仕様が整理できているというのは、ゲームとしての企画ができているという状態で、ゲームを実装する仕様としての仕様はまったく定義されていません。
なので、開発側としてはこの部分の工数をけちってはいけません。
そして、これは発注者と開発者とで同じ言葉を使いながら、まったく別の意味を指しているので、互いに共通認識をあわせておく必要がある場所です。

No.2について

はい、これもよくあります。SIerでもよくありますね。
なんかプロジェクト終盤になって、考慮漏れが発覚するケース。

これ、まだエンプラ方面だったらまだ意外となんとかなるケースが多いのです。
代替策(これによって、目的をどのような形でもいいから達成できる方法)を何か一つ考えればいいから。

ゲームではこの辺は違います。
目的を達成するのは当然のことで、その上でクオリティを重視してきます。
なので、考慮漏れだった箇所について確認すると、もれなくその考慮漏れを隠すかのようにメチャメチャでかい仕様が追加されて返ってきます。

ちなみに、ベトナムでデスマっていたときに、このような確認をしましたが、半端無い仕様追加で返ってきました。

むしろ、この返答によって、私は発注者(ゲーム企画者)側の人間が、日本語を理解していないのではないか、ゲーム開発を終わらせる気がないのではないかという疑念を抱きました。

No.6に関して


発注者(ゲーム企画者)側が、「これこれの部分はドラ○コレやればすぐわかります」とか言った場合は、ゲーム企画者側の協力放棄にも近い(ゲームで何をやりたいのか要求を明確に伝えようとする努力を怠っている)ので、こんなやり取りがあるのであれば、ちゃんと参考ゲームを理解するための工数およびゲームの課金にかかる費用は請求しておいた方が良いでしょう。(あくまでSIerの立場でしゃべっていますが…)。

というのも、こういう説明でかたされる場合は、ゲームの要求あるいは仕様に明文化された形で仕様が残らないので、開発側に非常にリスクが残ります。
なので、こういう説明のされ方をなされた場合は、参考ゲームを実施した記録を保存しておき、どのゲームのどの箇所であるかリバースエンジニアリングして明文化しておいたほうが無難です。

で、で、で、さらにゲーム開発を現在するということは課金要素が必ず関係していますので、参考ゲームの調査には課金部分を通過しないといけません。
それは費用ですので、ちゃんと請求してください。

さらに、No.2でも触れましたが、複数ゲームのコピペな場合は、複数ゲームの要素で埋め尽くされていて、その部分を解体する必要があります。キメラを解体して、各内臓諸器官をどの動物のどの臓器であるかをマッピングする作業が発生してきます。なので、プロジェクト終盤の仕変に備えて、工数は多めに見積もっておいたほうが良いでしょう。

No.7くらい


諦めましょう。
大概はスコープは変えてくれません。

ちゃんとスケジュールを出しても、どうにかして間に合わせろと言われます。
そういう場合は、発注者(ゲーム企画者)側のキーマンを拉致って、開発現場の中に投入して、軟禁状態にしてください(キケン)。
そうでもしない限り、無理なんだということを実感させることは不可能です。

No.8くらい


マルチプラットフォームは今のうちに抑えておきましょう。
Unity、Titanium、Phonegapなどがありますが、Unityは知らんですが、他のはWebViewを用います。
HTML5の企画などに精通しておきましょう。

それでも、Native周りの実装、特にIn-App PurchaseとかIn-App Billing、C2DM、APNsとかは必ず関わってきますので、Android、iOSともに勉強していないと厳しいです。
コレに加えて、ゲーム関連のプラットフォームなどがありますので、このあたりはちゃんと勉強しておかないと厳しいです。

で、開発者側がそれらのスキルがなく、発注者側にもそれらのスキルがない場合は、地獄を見ますので、それでもやりたいと発注者側が主張するときは、片方だけに限定してもらえるように交渉するしかありません。

または、もう片方のプラットフォームには倍の工数をかけて見積もりを提出してください。

No.9


これは、私のプロジェクトだけがおかしかったのかもしれませんが、画面制作担当者がゲームの仕様に詳しくなく、出来が悪い画面ばかり送りつけられて、心のなかで「んだよ、これ！」と思いながら、ここのこの部分、こういう動きをした場合の画面がないので製作していただけませんか？とお願いする次第になります。

私はデザイナーさんを馬鹿にする気持ちは全くありませんが、チームとして目的が共有できていないような発注者(ゲーム企画者)のもとで作業しているデザイナーさんはヤル気が欠如してしまいがちです。そしてそれらは、開発者側の作業遅延として発注者側から指摘されることが多いです。

ですので、発注者側が画面を準備しますという場合は、ほぼ作りなおしを想定して工数をくんでおいたほうが安全です。



結論


この世からコピゲーはなくなるべき。




投稿者 時刻: 0 件のコメント:
ラベル:

2011年12月11日日曜日

JIRA Advent Calendar 11日目

突然のムチャぶり


昨日の夕方頃、ベトナムのホテルでだらだらとしていたときにこんなツイートが…


yuskey
山本裕介
@mike_neck 明日 #jiraadvent がんばってください atnd.org/events/22899 /cc @Sean_SF


ん、オレ、まだJIRA買っていないんだが…困ったな。

で、よく見ると順番が大貫さんの次になっているし、エントリー内容もみんなレベル高い(・_・;)

すごい困った。





まあいいか。

JIRA Advent Calendarなのですが、あえてここでは、Confluenceの話でもしようかなと思います。

題して、

Confluenceを使ってみたい！



先述の通り、まだJIRAもConfluenceも買っていないんですが、Confluenceすごい楽しそうだなと思った動画があるので、それをどうぞ。



RedmineやTracのWikiなどは、非常に使い勝手が良いのですが、図も入ったようなドキュメントを書くのには若干向いていない気がしています。
そういう場合は仕方がないということで、MS Officeなどの製品に頼るわけですが、これがまた難敵で、各自の端末で編集するのでコラボレーションが難しいと思っていたわけです。

で、この動画を見たとき、すごい高い編集性能を持ちながら、Webで共有できるという機能に驚いてしまったわけです。


さて


さて、Confluenceほんとうに使いたいなんて思っているわけで、今なら円高だから10ユーザーでも850JPY程度。
JIRAとあわせて1,700JPY、ついでだからAtlassian Universityで習いつつやるということで、申し込んでも3,400JPY。

意外とお得かもしれません。

はい、以上、夢を語ってみました。



まあ、でもJIRAでObjective-Cの学習をチケット立てて管理するのもありだな
というわけで、来年くらいにはAmazon EC2か自宅鯖にでも導入しようと思います。

さて、次回のJIRA Advent Calendarですが、えっと、オレのムチャぶりに大人対応していただいたしょうゆさんです。

投稿者 時刻: 3 件のコメント:
ラベル: , , ,

2011年10月16日日曜日

第4回Jenkins勉強会に行って来ました

第4回Jenkins勉強会に行って来ました。



さて、内容の詳細ですが、
ブログまとめ職人の@shinyaa31さんが素晴らしいものを書いていますので、
そっち読んでください。

あと、トゥギャッターもまとめられているので、読んでみてください。

togetter - 10月15日 第4回Jenkins勉強会(東京都)
2011/10/15_第4回Jenkins勉強会( #jenkinsstudy )

当日のUST録画もありますので、興味のある方は御覧ください。

以上、報告終わり！


(´・ω・｀)

投稿者 時刻: 0 件のコメント:
ラベル: , , ,

2011年9月11日日曜日

Gradleでスローテスト問題を解決するAgain

前回、こんな記事書きました。
見事に効果がわからないという結果が出てきて、どうやればいいのか考えていましたが、
さすがGroovyクラスタに素晴らしい先輩がいらっしゃいました。

@bluepapa32 先輩です。
単純に、スリープするコード


    for (int i = 0; i < 100; i++ ) {
        Thread.sleep(10);
    }


を埋め込めばよかったわけですね。

というわけで、こんなテスト生成スクリプトでテストを大量に作ってみることにしました。


CreateTest.groovy

import static groovyx.gpars.GParsPool.*;
def packagePath = 'C:/Users/mike/IDEA_Project/GradleSample/src/test/java/orz/mikeneck/gradle/sample/boxunbox/test'

def head = $/
package orz.mikeneck.gradle.sample.boxunbox.test;
import org.junit.Before;
import org.junit.Test;
import java.util.Arrays;
import java.util.List;
import static org.hamcrest.CoreMatchers.*;
import static org.junit.Assert.*;
/$

def body = $/
    public static final int SIZE = 100;
    private List<Integer> intList;
    private List<Long> longList;
    @Test
    public void testInteger()   throws InterruptedException {
        int[] array = new int[SIZE];
        int position = 0;
        for(Integer item : intList) {
            array[position++] = item;
            Thread.sleep(10);
        }
        for (int i : array)
            assertThat(i, is(intList.get(i)));
    }
    @Test
    public void testLong()  throws InterruptedException {
        long[] array = new long[SIZE];
        int position = 0;
        for (Long item : longList) {
            array[position++] = item;
            Thread.sleep(10);
        }
        position = 0;
        for(long item : array)
            assertThat(item, is(longList.get(position++)));
    }
    @Before
    public void setUp() throws Exception {
        Integer[] integers = new Integer[SIZE];
        Long[] longs = new Long[SIZE];
        for(int i = 0; i < SIZE; i++)
            integers[i] = new Integer(i);
        intList = Arrays.asList(integers);
        for (int i = 0; i < SIZE; i++)
            longs[i] = new Long(i + Integer.MAX_VALUE);
        longList = Arrays.asList(longs);
    }
}
/$

def numbers = []
(1..300).each {
    numbers << it
}

withPool {
    numbers.collectParallel { number ->
        def className = "BoxUnboxTest${number}"
        def name = "${className}.java"
        def fileName = "${packagePath}/${name}"
        def define = "public class ${className} {"
        def content = new StringWriter()
        content << head
        content << define
        content << body
        println ' ---- '
        println "now processing : $fileName"
        println ' ---- '
        new File(fileName).write(content.toString(), 'UTF-8')
        assert new File(fileName).exists() == true
    }
}


10msecを100回Sleepするテストメソッドが二つで、ひとつのテストの実行にかかる時間は2sec。
これが300個あるので、必要な時間は600sec = 10min かかるテストです。

実際に一つテストを実施してみました。


2secかかっていますね。
これが300個用意されるので、10minかかることが想定されます。

では、次のGradleスクリプトで実行してみましょう。


build.gradle

apply plugin: 'java'

repositories {
    mavenCentral()
}

dependencies {
    testCompile 'junit:junit:4.8.2'
}


なお、マシンの環境は次のような感じです。
OS : Windows 7
CPU : Intel Xeon X3460 (8Core) (64bit)
RAM : 8.00GB




では、実行、というかその間に色々と他のことで負荷がかからないように、
IntelliJ IDEAが起動していて、このブログだけがChrome上で起動しているという状態にしておきます。
で、IntelliJのRunツールで実行するのではなく、ふつうにコマンドから起動します。

さて、オレはその間、『JOJOの奇妙な冒険』を読むこととします。

では、いざ実行…




c:\Users\mike\IdeaProjects\TestingGradle>gradle build
:buildSrc:compileJava UP-TO-DATE
:buildSrc:compileGroovy UP-TO-DATE
:buildSrc:processResources UP-TO-DATE
:buildSrc:classes UP-TO-DATE
:buildSrc:jar UP-TO-DATE
:buildSrc:assemble UP-TO-DATE
:buildSrc:compileTestJava UP-TO-DATE
:buildSrc:compileTestGroovy UP-TO-DATE
:buildSrc:processTestResources UP-TO-DATE
:buildSrc:testClasses UP-TO-DATE
:buildSrc:test UP-TO-DATE
:buildSrc:check UP-TO-DATE
:buildSrc:build UP-TO-DATE
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:jar UP-TO-DATE
:assemble UP-TO-DATE
:compileTestJava
:processTestResources UP-TO-DATE
:testClasses
:test
:check
:build

BUILD SUCCESSFUL

Total time: 15 mins 42.983 secs


15分43秒、マジ遅え。
しかも、最初の数個目までのテストは結構サクサク進んでいたけど、200を越えたあたりからテストの実行速度が落ちてきた感じがする。
こういう時はJVMの再起動などが必要なのかもしれん。

というわけで、さっそく、並列処理を試してみようと思う。

build.gradle

apply plugin: 'java'

repositories {
    mavenCentral()
}

dependencies {
    testCompile 'junit:junit:4.8.2'
}

test {
    maxParallelForks = 6
    forkEvery = 30
}


前回にも書きましたが、
  • maxParallelForksは並列するスレッド数。
  • forkEveryは指定した回数テストを実行するとJVMを再起動して、OutOfMemoryExceptionを回避する仕組みです。

では、実行開始です。


c:\Users\mike\IdeaProjects\TestingGradle>gradle build
:buildSrc:compileJava UP-TO-DATE
:buildSrc:compileGroovy UP-TO-DATE
:buildSrc:processResources UP-TO-DATE
:buildSrc:classes UP-TO-DATE
:buildSrc:jar UP-TO-DATE
:buildSrc:assemble UP-TO-DATE
:buildSrc:compileTestJava UP-TO-DATE
:buildSrc:compileTestGroovy UP-TO-DATE
:buildSrc:processTestResources UP-TO-DATE
:buildSrc:testClasses UP-TO-DATE
:buildSrc:test UP-TO-DATE
:buildSrc:check UP-TO-DATE
:buildSrc:build UP-TO-DATE
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test
:check
:build

BUILD SUCCESSFUL

Total time: 2 mins 42.544 secs




えっ、2分Σ(ﾟдﾟlll



めちゃくちゃ早くなっていません？
元々15分43秒かかっていたのがたったの2分43秒。

単純に計算すると

15min43sec / 6(core) = 2min37sec


となるから、妥当な値ですね。

では、テストのサマリーを比較してみましょう。



並列化前



並列化後



これを見るとCPU時間は変わっていません。
つまり、CPU時間をすべて複数コアで実行したために早くすることが出来たという事になります。

というわけで、結論

GradleのmaxParallelForksを使うともれなくスローテスト問題が解決できる。



投稿者 時刻: 0 件のコメント:
ラベル: , , , , , , ,

2011年8月10日水曜日

『アジャイルサムライ』読書記録 - 7章 - 見積もり：当てずっぽうの奥義

単なる読書メモなので、あまり読んでもおもろくないと思う。

まあ、SIerはそれをずっと維持し続けようとするから、あとで火を噴く訳だな。
開発なんてやってみなければどれくらいのスピードでできるかわからない。

  • 今後の計画をたてられる
  • 見積もりは当てずっぽうだという前提を踏まえている
  • ソフトウェア開発の複雑さを認めている


このプロジェクトをやり遂げられそうなのか？！は非常に重要なところだと思う。

できないものをできるとかいうと後々痛い目を見そうだし。

7.2 ピンチをチャンスに


  • ストーリーそれぞれを互いに相対的なサイズで見積もる
  • ポイントをもとにして進捗を追跡する



相対的な見積もりについて

ポイントについて

見積もりは確実なものでないとわかっているので、日数でなく、これくらいみたいな感じで見積もっておいたほうがよいってことかな。

SIer「このプログラム何日かかる？」
プログラマー「わかりませんが、この前の仕事の5割増ですね。」
SIer「つまり3日だね？」
プログラマー「どうですかね？この前の仕事は確かに2営業日でできていますけどね。まあ、たぶんこの前の仕事より5割増くらいだということですね。」
SIer「つまり３日だね？」
プログラマー「いや、分かりません。」
SIer「この前のは２日でできたのだから、それの５割増だから、３日だろう。」
プログラマー「どうですかね？この前の仕事は確かに2営業日でできていますけどね。まあ、たぶんこの前の仕事より5割増くらいだということですね。」
SIer「つまり３日だね？」
…以下続く

見積り技法


三角測量

ストーリーの一覧から１回のイテレーションの期間に収まりそうなサイズのストーリーを大中小選び出す。
選び出す際の視点。
  • 論理的なグループ分けができる
  • エンド・トゥ・エンドになっている
  • プロジェクトを象徴するストーリー

スパイク

今まで経験したことのないようなストーリーに対する見積もり方法。
タイムボックス化して数日以内でストーリーを見積もれる程度に様々な調査を行う。

プランニングポーカー

開発メンバーが一つ一つのストーリーを自分自身で見積もる。
その結果をメンバー同士で共有する。
一致していたら、その見積もりにする。
異なっていたら相違について話し合って見積りを出す。

重要なポイントは話し合いがあること。
プランニングポーカーは投票システムではないこと。
ストーリーのサイズは小さくする。(1、3、エピックを表すのに5を使う。)



投稿者 時刻: 0 件のコメント:
ラベル: , , ,

2011年7月5日火曜日

なんとかDDをまとめてみた

情弱なので、なんとかDDというのがどういうものかあまり良くわかっていないので、キーワードだけでもと思って、まとめてみた。

TDD

Test Driven Development
テスト駆動開発。
私が初めて知ったなんとか駆動開発というやつです。
ソフトウェアのコンポーネントに期待する振る舞いをテストとして記述して、そのテストを通るように単純に実装していく手法(間違っていたら、ツッコミをお願いします)。比較的コンポーネントが単純になるので、変化に強いソフトウェアが作成される。
代表的なフレームワークにJUnitがある。


BDD

Behavior Driven Development
振る舞い駆動開発。
TDDの発展した形態の開発手法。要求仕様を自然言語に近い形で記述し、それをソフトウェアが満たすように実装していく。
代表的なフレームワークにRSpecがある。


DDD

Domain Driven Design
ドメイン駆動設計。
'複雑なドメインの設計はモデルベースで行うべきであり'、'また大半のソフトウェアプロジェクトではシステムを実装するための特定の技術ではなくドメインそのものとドメインのロジックに焦点を置くべき'とする
出典 Wikipedia


TiDD

Ticket Driven Development
チケット駆動開発。
Redmine、Trac、JIRA、BacklogなどのBTS/ITSに登録されたチケットをベースに開発していく手法。
現在のタスクの状況が把握しやすく、VCSとの連携により、どのようなコミットなのかも関連付けて管理できる。

23:33 @diceaさんからTiDDということを教えていただきました。


2011/07/06 20:38 追加
次のなんとかDDは、ktz_aliasさんに教えてもらいました。

RDD

Responsibility-Driven Design
責務駆動設計。
オブジェクトに必ず責務を持たせて設計する設計手法。また、その責務に6つのパターンを当てはめるという方法。
全然知らない言葉だったので、こちらを参考にどうぞ。
Pinto公開に向けて #16 ― 責務駆動設計で仕切り直すことに決めた - 岩本隆史の日記帳



こっから下はネタなので注意。


EDD

Excel Driven Development / Excel Driven Design
エクセルで設計、開発。
これは実は近年のアンチパターン。
COBOLの時代には効果があったかもしれない。なぜならCOBOLは一台しかなく、マシン上でテストする場合に事前にバグを取り除いておく必要があったし、いやそもそもマシンにコードを打ち込める人など限られた人たちだけだったから。
この時の開発手法に慣れた人がExcelでのドキュメントでバグを取り除くという考え方を引きずったまま、現代の誰でもIDEを持っている環境で、この手法を使うと、面倒なことを何度もやらなければならないので、プログラマーは間違いなくやめるか、職業プログラマーになり下がる。
一方で、プログラマーを単なる代替可能なリソースとしてしかとらえていない人からすると、Excelからプログラムを算出できるのは魅力的であり、Excelからプログラムを出力することに執念をかけている人もいる。


PDD

Politics Driven Development
政治駆動開発。
どんなに完全などを現場が提案しようと、もはや決まったものは決まったものとして実施せざるを得ない開発手法。
根回し、資本関係、上司とのコネクション関係、契約関係ありとあらゆる交渉上優位になる条件を確実に抑えていって、何が起ころうとも、すでに何もかもが決定しているという残念な開発手法。
ボッチプログラマーやコネクションがないプログラマーは、たとえ決まった方針が間違っているとしても従わざるを得ない。


SDD

Smoking-Room Driven Development
喫煙室駆動開発。
会議では建設的な意見が出てこないため、喫煙室でいい加減に言ったアイデアが通ってしまうという、非喫煙者にとって最悪な開発プロセス。
喫煙室ではお客さんもポロっと本音が出るために、意外と本当の要求が聞けたりするのだが、この手法の残念なところは、その情報を得た人たちが、喫煙所で決定した事項をなんらのWikiとかメールで共有することなく動く点にある。
そのため、会議室とか作業部屋で作業している人からすると、突然方針が翻ったりして、はっきり言って、喫煙野郎を殴ってやりたくなる。


DDD

Deadline Driven Development
締め切り駆動開発。
リリース日から逆算してスケジュールを決めていく開発手法。
とくに何の戦略もないPJがとる手法の一つ。
ただただ、人材が送り込まれてくるだけで、スキルもバラバラなので、どうしようにも手が負えない。
PJの末期状態。


ZDD

Zangyo Driven Development
残業駆動開発。
最初から社員の残業をあてにしてスケジュールを組んでいる、最悪なPJの開発手法。
いや、もしくは職業プログラマーが残業手当を見越してわざと残業しているという生産性無視の開発手法。
いずれにしても、PJの後半で体力的にきつくなって、倒れる人が続出するのでやめたほうがいい。


まあ、その他いろいろあると思うので、みなさん教えてください。
投稿者 時刻: 1 件のコメント:
ラベル:
登録: 投稿 (Atom)