restofwaterimpのぎじゅつMemo

SIerに所属。企画から運用まで幅広くやってます。C#中心に書いてます。

メモ:文字列の部分分割とeval(数学パズルQ2)

今回のお題を実施するのには数値もしくは文字列の間に四則演算を入れなければならなかった。

 

そのため、自分は「部分参照とか文字列分割だね」と思い、

 

Ruby

 hoge[n,m] ・・・ nには開始位置(0開始)、mには終了位置を指定する

 

C#

 hoge.substring(n,m)・・・nには開始位置(0開始)、mには長さをしていする

 

として、取得した値をもとに四則演算を用いて書いていた。

 

しかし、いろいろな四則演算のパターンを書くのはすっきりしないなとと思い、ページをめくったら、evalを利用していた。

 

C#でやろうとすると自前でevalを作成するか、他のスクリプト言語(例えば、JavaScript)を利用するのも一つ手らしい。

 

書籍には逆ポーランド記法を利用するとも載っていた。

結構なソースコード量になると思われる・・・ので、作成しやすい言語で今は考える元しようと思う。。。

 

また、eval利用するとコンパイラを通してや、IDEを通じて、エラーチェックや警告が走らないのが欠点。

頭の体操?にはよさそうだが、実際にものを作成するときには慎重に利用することが必要に感じた。

文字列を実行時に処理するだけなので、人間系で事前に処理の正しさ(仕様と違うか、セキュリティ的に文字解析の結果が大丈夫か)が必要ですね。

 

メモ:進数の変換と文字列の反転(数学パズルQ1)

数学パズルをやり始めました。

仕事でソースをチェックすることはありますが、コーディングすることが少なくなってきているので、楽しみながら、パズルを解いてます。

 

最近扱っている言語が、RubyC#なので、書きやすさってのが比較できないかなと。

 

Q1で利用したメソッド

 

進数の変換

Ruby

hote.to_s(num)    # numには変換したい進数

 

C#

Convert.ToString(hoge,num)   -- hogeには指定の数値、numには変換したい進数

 

文字列の反転

Ruby

  hoge.reverse

 

C#

 string.Join("" , hoge.Reverse())

 

 普通にhoge.Reverse()を記述すると、Iteratorが戻り値になるため、文字列にならない。

 また、配列に対して、Reverseをすると配列の添字の順番を逆で並び替えるということが行われる。

 

 

Q2へ続く

 

 

【メモ】アスペクト指向とオブジェクト指向

達人プログラマーの新装版の言葉で余り知らない言葉を調べてまとめてます。。。

 

AOP(Aspect Oriented Programming)

 OOPでうまく分解できないソフトウェアの「様相」や「側面」といったものが存在し、

 このような「様相」「側面」は複数のオブジェクトにまたがる操作となる。

 これを「横断要素」という。

 例として、プログラムの実行の様子を記録すするロギング操作がある

 横断要素はコード中に散在し、すべてを把握し管理することが難しい。

 その為、こうした要素を「アスペクト」としてモジュール化し、分解することで、把握・管理・変更を容易にする。

 OOPを補完する。

 

https://yo1000.gitbooks.io/self-study-spring/content/chapter7.html

 

インたセプタを織り込むタイミングは2つ。

1.コンパイル

 独自に用意されたコンパイラを利用することで、コンパイルのタイミングでインたセプタを織り込む

  代表例・・・AspectJ(Javaの拡張言語)

2.クラス・ロード型

 特別な実行環境(コンテナ)を提供することで、実行(クラス・ロード)時にいんたセプタを織り込む

 

 

OOP(Object Oriented Programming)

 属性(データ)と操作(メソッド)の集合であるオブジェクトをソフトウェアの分解単位として扱う

 コードの再利用性、継承、多態性を利用し再利用可能なモジュールを作成する

 

 

http://e-words.jp/w/AOP.html

 

http://itpro.nikkeibp.co.jp/article/COLUMN/20051122/225023/

WPF開発をするために読んだ本

昨日、自社の上司と面談を行った。

「これまでCOBOL開発ばっかりだったけど、どうやって今の開発ができるように馴染んだの?」と

と問われ、

「本を読んで、ちょっとコーディングしてみて」と軽く伝えたのですが、

何を購入してたのかな〜〜というのをちょっと振り返り。

 

<参考となる方>

今回のプロジェクトの役割はプログラマーではなく、プロジェクトリーダーですが、設計も開発もテストもしている身でした。

ちなみにこれまでのC#経験はなし。WPFも初めて知ったという人間です。。。

そんな人でも開発者と会話しながらプロジェクトが進められるようになるために・・・という書籍だと思います。

 

 

C#の知識

購入、図書館を元に参考。猫で基本を知り、独習C#はパラパラと見ました。

プログラマーとして参画するならば、独習C#までしっかり読み込むのがいいかと。

他言語のプログラム経験があれば、十分かなと。

Effective C#は購入したけど、自分自身には少しハイレベルだった。

ただ、開発メンバーと話をするときの話のきっかけとして利用。

 

猫でもわかるC#プログラミング 第3版 (猫でもわかるシリーズ)
粂井 康孝
SBクリエイティブ
売り上げランキング: 275,968
独習C# 第3版
独習C# 第3版
posted with amazlet at 16.02.15
ハーバート・シルト
翔泳社
売り上げランキング: 23,934
Effective C# 4.0
Effective C# 4.0
posted with amazlet at 16.02.15
ビル・ワグナー
翔泳社
売り上げランキング: 175,035

■.NETフレームワーク

 難易度の順番で書きました。

 .netの内面がわからないとも、.netFrameworkがどこを包含しているのか。

WPFの基礎知識やLINQのさわりもここで知ることも出来ます。

ただ、読んだからといってすぐ開発できるか・・というとちょっと違うなと。

全体概要をつかむための書籍という印象です。

 

.NET開発テクノロジ入門 2014年版 VisualStudio2013対応版 (MSDNプログラミングシリーズ)
酒井 達明 山田 祥寛 小高 太郎 中原 幹雄 芝村 達郎 和田 健司
日経BP
売り上げランキング: 200,284
C#によるiOS、Android、Windowsアプリケーション開発入門 (MSDNプログラミングシリーズ)
エッセンシャルWPF:Windows Presentation Foundation (Programmer's SELECTION)
インタフェースデザインの実践教室 ―優れたユーザビリティを実現するアイデアとテクニック
ひと目でわかる Visual C# 2013/2012 アプリケーション開発入門 (MSDNプログラミングシリーズ)
アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技
ロバート・C・マーチン Robert C. Martin
SBクリエイティブ
売り上げランキング: 20,458
スクラム 仕事が4倍速くなる“世界標準”のチーム戦術
ジェフ・サザーランド
早川書房
売り上げランキング: 88,766
スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)
貝瀬 岳志 原田 勝信 和島 史典 栗林 健太郎 柴田 博志 家永 英治
技術評論社
売り上げランキング: 243,320
アジャイルなゲーム開発 スクラムによる柔軟なプロジェクト管理
SBクリエイティブ (2013-11-15)
売り上げランキング: 72,379
アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣
Venkat Subramaniam Andy Hunt
オーム社
売り上げランキング: 168,799
リーン・スタートアップ
エリック・リース
日経BP
売り上げランキング: 6,419
実践 反復型ソフトウェア開発
津田 義史
オーム社
売り上げランキング: 541,253
UMLモデリング入門
UMLモデリング入門
posted with amazlet at 16.02.15
児玉 公信
日経BP
売り上げランキング: 40,609
UMLモデリングの本質 第2版
児玉 公信
日経BP
売り上げランキング: 148,534
■テスト
システムテスト自動化 標準ガイド (CodeZine BOOKS)
Mark Fewster Dorothy Graham テスト自動化研究会 伊藤 望 玉川 紘子 長谷川 孝二 きょん
翔泳社
売り上げランキング: 24,097
JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

【メモ】ITCAの研修を受けて

プロジェクトマネジメントの体系をしる講座を受けた。

 

PMI系のPMBOKの講座を受けていたが、やっぱり体系集のため、うまく現場に還元できないなと感じていた。

どうも、PMI以外にPM系の体系をまとめているものは他にもあり、イギリス系、ドイツ系などあるようである。

 

 

特に、事例集的に書いてあるのは

イギリス系の

www.axelos.com

 

axelosというものであった。

 

もちろん前編英語みたいですが、ポートフォリオから運用系のITILまで幅広くBestPracticeが記載されているようです。

 

後で、参考として見てみることに。

 

この研修で一番印象に残る講師のコメントは

「実行権限も予算権限も決断力もない人とアジャイル開発をしてはいけない。」

ということ。

 

ごもっともということ。プロダクトオーナーに携えるのはそれなりの権限を持つ人を

持ってこなければ、混乱の元になるのは目に見えている。

 

そんな経験も私もしているので。。。

 

 

スクラム始めました-スプリント5実施【#3】

ずいぶん間が会いてしまいましたが・・・

 

4月より進めてきたスプリントもすでに5サイクル目に。

スクラムっぽくは実施しているが、なかなかうまくいかないなということが

多く出てきているので、自分の整理を込めて今回は記載。

 

<遂行が難しい点>

1.新規開発での難しさ

開発フレームも整っておらず、利用する言語について、深い見識があるメンバーがいない中で始めて入る部分もあり、開発の生産性が高まらない中、スプリントを繰り返している。

徐々に部品は出来上がっており、作り始めにおけるコストは下がっているのだが、要求の変化に伴う、機能の変化にうまく対応できておらず、波に乗れない。

 

2.ふわふわすぎる要求

プロダクトオーナーとの打ち合わせを実施しているが、要望ではなく、確認会になっているのも原因と考えている。本来ならば、オーナー側に業務プロセスのイメージを固めてもらい、「こうやって進めたい」というのベースに、システムとしてはどうするというのを検討する形になるのだが、業務プロセスもシステムも構築サイドで検討している状況。

作成したものを見て、業務プロセスを考えなおすというやり方になっているため、機能要求に沿ったテストが出来ないことやいつまで立っても仕様が確定しない。

(スプリントのゴールは出しているが、リリースの条件を満たさない状況になっている)

 

3.広がる要求

小さく進めて開発しているのだが、今回はWebサービスではなく、ビジネスアプリケーションの一部分の開発である。そのため、スプリントで作成したものだけではリリースはできず、複数機能を全て作成し、システムテスト、ユーザテストを経ないとリリースができない。

 

が、エンドは切られているにも関わらず追加で要求が増える状況。。

これくらいの規模だったらこれくらいかかるなという感覚がプロダクトオーナーにはないことと、要求を持ってきた時点でエンドユーザーと入れる方向性で話を持ってきているため、柔軟に納期を変更できない。しかし、要求は増えていく。。。

 

<やっていて良い点>

スクラムでやることによって、今までの分業制で開発していたのとは異なるという点もありました。

1.実装時に仕様やユーザ視点に立った場合の問題点に気づいてくれる

がちっとした仕様書を書いているわけではなく、Redmineにチケットを発行し、やりたいことを備考欄に記載して、タスクを割り振っている。

また、都度あることにプロダクトオーナーと話したこと、エンドユーザの仕事、業務の内容を説明している。そのため「こういう機能だと、ここにこまらないかな?」と考えてながら実装する意識が芽生えてきている。

言われたとおり作成するというのではなく、考えて作る意識に変えられるのがいいこと。

 

2.タスクの分割

タスクが大きすぎると分割!とすぐ気づく文化が醸成できている。

タスクが大きいと進捗が個人の内部に隠れ、「どこまで進んでいるんだろうか?」が分からないが、細かくし、都度進捗を記載してもらうことである程度状況を把握できる。

 

 

<ロケーション上困っていること>

スクラムの書籍などを読んでいると、壁にタスクボードやカンバンがはられ可視化できているが、私のプロジェクトはできてない。

と、いうのもお客さん先の環境で実施しており、他のベンダーとの共有環境で作業を実施しているため、情報を外に出せない。

システムが充実してきており、デジタルで実施できることは増えている一方、コンプライアンスやセキュリティーなどの要件で、アナログな手法が使えなくなっているのが制約だなと・・。プロダクトオーナーへのインパクトがデジタルだと弱い・・と感じています。

スクラム始めました-スプリント1実施【#2】

前回の続き

スクラムを始めました【#1】 - restofwaterimpのぎじゅつMemo

 

 

まずはやってみようということでスタート。試行錯誤の中、徐々に良くなればいいやという思いを持ち、進めることに。

■どういうものを作るのか

 ・とあるビジネスアプリを完全に作り変える

 ・要求は漠然としており、モックやプロトを見せながら要件を決めていく。

 ・また、データが散在・ダブルネーミングや一定のルールが無いデータを一元化するため、クレンジングをしながらデータ移行業務あり

 ・.netで作成

  (詳しくかけないので、いろいろ伏せています)

 

まずは、計画を作成・・・

 

■チームメンバーの構成

 全員で5名のチーム

 ・スクラムマスター

 ・プロダクトオーナー

  本来はプロダクトオーナーは企画チームやお客様に実践してもらうのが良く、プロダクトの優先順位をつけてもらうのがベスト。

  しかし、今回はお客様も掛け持ちで色々持っているため、兼務で私が実施。

  

  他メンバーは

   設計・移行担当・・・1名

   開発メンバー ・・・3名(今回使う言語、アプリの技術を知る人1名

                他言語の経験者1名。

                .netもJavaなどWeb経験無し 1名)

  マルチスキルというわけでもなく、特定要素に偏ったメンバー構成でスタート。

  また、チームメンバーはそれぞれ異なる会社のパートナー社員

  

 

■スプリントの期間の設定

書籍などを参考に、スプリント期間は2週間で実践し、まずは自分たちの力量を知ることをスプリント1に決定

 

■ゴール定義

 スプリント完了後にどこまでできているかを決定。

 今回は

  ・モックアップ完了

  ・α版・・・単体テストまで完了

  ・リリース版・・・本番に載せられる状態

 と意味付けた。実施しながら定義は見直すことも可能とした。

 

■コミュニケーション

 ・朝会を実施。基本30分とし、超えそうな場合は別で時間を確保。

 ・別時間で打ち合わせをする場合は、

  「打ち合わせの目的」

  「会議のゴール」

  を明確にして、打ち合わせを行う。

 ・極力、メンバーの一部だけしか情報を知らないということをなくすため、共有するときはチームメンバー全員で実施

 

ツール

 ・お客様環境の都合上、初期はツールを入れられず。

  Excelを基本に管理を実施。

  下記のサイトなどを参考に、バックログを書き、バーンダウンチャートを作成

河西 高明 BLOG: ガントチャートを捨てろ(2) バーンダウンチャートを使う

   → 資料作るのに時間がかかり、細かな管理がおろそかに。

     また、Excelだと基本、メンバーは入力をしない。。。のがわかりました。

 

■プロダクトログの作成

 ・進める前にお客様の企画部隊と話はしていたので、おおよそのユーザーストーリーを作成し、必要と思われるフィーチャーを箇条書きにした。

 ・優先度が高く、すでに具体的に書けそうなものは具体的に記載し、優先度が低そうでまだまだ要望が固まっていないものはあらく記載。

 ・細かく出来る部分は極力、1つのプロダクトログに対し、1,2日で終る範囲まで切り分けた。

 ・粒度の記載のばらつき具合には目をつぶり、まずは作るべき機能を書きだした。

 ・環境面で作成しなければならないことは「環境改善」という名前でグルーピング化

  アプリ基盤の作成などはフィーチャーとは分けてラベル付

 

■タスクの考え方

 ・開発の作業に必要なタスクを形式化。

 ・言葉ジリにこだわらず、チームメンバーの中で「DONE」できそうな内容で、意味が共有できていれば良いという形で記載。

 

■まずは見積もろう!

 作成したプロダクトログの中から、スプリント1で作成する機能を私がピックアップ。

 その機能に対して、メンバーに見積もりをしてもらった。

 ここで有識者が「ざざっと」基準となる機能を見積もり、ほかの機能は相対的に複雑度や規模から見積もりを行おうと思ったが、できそうもないので、ざっくり見積もりに。スプリント1の状況を見て、見積の正しさを検証することに・・・

 ・極力、スクラムマスターが「この工数でいきます」とは言わず、メンバーに工数を話してもらい、「合意」「宣言」という形で言ったことをコミットしてもらう雰囲気にしました。

 

 

■実践開始!

 ・いろいろと問題が・・・。

  スプリント1の振り返り後に記載することに。 

                        (つづく)

 

<追加の参考にした書籍>

 

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣
Venkat Subramaniam Andy Hunt
オーム社
売り上げランキング: 61,478