@kotyのブログ

PythonとかAWSとか勉強会のこととかを、田舎者SEがつづります。記事のライセンスは"CC BY"でお願いします。

TFSの作業項目のrss feedを作ってみた

最近ようやくVSSからTFSへ移行しつつあります。ソース管理だけでなく、せっかくなので作業項目管理の機能も使ってみています。その中で、redmineのactivityタブみたいな画面が欲しいなーと思って作ってみました。元ネタは、こちらを参考にさせていただきました。

作成したソースはこちら。
https://skydrive.live.com/redir?resid=F4AE3396D1EB6FC7!168

  • 認証のことを考えていない
  • 何でいったんファイルに出すんだ。そもそもWCFサービスの方がいいんじゃない?

など突っ込みどころは満載です。。。

と、ここまで作って気づいたんですけど、カスタマイズしたクエリをプロジェクトポータルに張り付ければいいんすね。それにLAN内でしか参照できないRSSって使いづらいですよね。だからTFSの作業項目のRSSが欲しいっていう需要がなくて、ネットにも情報がないのかなと思いました。

#NSEG 合宿に行ってきた

先週末開催されました、24回NSEG勉強会に参加してきました。
今回は長野市を飛び出して白馬にてお泊り合宿であります。幹事のid:stealthinu さんは宿の手配からハンズオンに至るまで本当に尽力いただきました。

前座

せっかくの白馬ですので、私は朝から現地に入り八方にてひとすべり。一緒に滑った@さんが、頼んでもいないのにコブにガンガン突っ込んでいくという、穏やかな容貌からは想像もつかないアグレッシブさでありました。あの攻めるハートが私も欲しい。おかげで午前券で滑っただけにも関わらずへろへろでした。id:stealthinuさんにコブの滑り方を教えてもらえれば、と思ったのですがそれはまたの機会ですね。

(@naganumat さん撮影)

勉強会

その後、昼飯→温泉→ときて本題の勉強会へ。想像つくように、すでにこの時点で眠気がきてました。。。

勉強会は宿となるペンションブルーマウントさんにて開催されました。内容は、node.js+WebSocket+enchat.jsを使ってチャットゲームを作るハンズオンでした。id:stealthinu さんの準備がものすごく、20程の工程に分けて見本ファイルが用意されていましたので、分かりやすかったです。

夕飯兼懇親会を挟み、みなさんほろ酔い一部酩酊状態で、ハンズオン再開。内容の濃さも手伝って、ハンズオンはなかなか終わりません。0時を回ったところで私が先陣を切ってギブアップ。朝の4時までやってた人もいました。。。合宿形式だと、良くも悪くもエンドレスですね。

翌日は前日やるはずだったLTが開催されました。

まとめ

これだけ集中してやったので、node.jsとWebSocketの勉強に非常になりました。業務システムでも、サーバからクライアントに情報をpushしたいことがあるので、可能性を感じます。が、かなーり心身を削られました。深夜に及ぶハンズオンて聞いたことないって。これのレベルをやるのは年に一度が限度でしょう。というか、id:stealthinu さんの多大なご尽力あってなので、そう頻繁には無理ですね。

世の中のトレンドに揺れるココロ

しかし、JavaScriptには慣れないし、好きになれません。大人数で開発できる気がしない。そんな中でもnode.jsの台頭によって、JavaScriptはクライアントサイドのみならずサーバサイドにも進出してきちゃってます。まったくもって暗い気持ちになります。そうはいっても、世の中のトレンドに合わせて自分を変えていかねばいけないのでしょう。

参加された皆さま、ほんとにお疲れさまでした。WebSocketについては.NETの観点からまた何か書ければなと思います。

謹賀新年

昨年の反省と今年の抱負。昨年の反省の話は、できなかった自慢になってしまいました。会社では新しいことをやらせてもらってるので、今年はその中でできるだけoutputしていきたいです。

仕事以外で勉強するテクノロジー

昨年目標に掲げていたけどもどちらもほぼノータッチ。。。今年は.NET4.5を勉強しとかないといかん気がする。

資格を取る!

  • システム監査 → 午前2で落選。今年もリトライ
  • システムアナリスト → 午後2で落選(評価B)。今年もリトライ
  • 日商簿記2級 → 3級で落選。。。モチベーション戻らないので保留
  • ビジネス法務検定3級 → 受けれてない。どこかで受けたいな。
  • MCPの何か → 70-515に合格。会社のプレッシャーもあるためSQL Serverの試験を近々受ける。たぶん。

社外の活動

金銭が発生するかは別にして、本業以外で何らかのプロダクトorソリューションを世に出したい。
→ 結局ノータッチ。とりあえず第一歩として、ただ今放置していた家業のシステムを更新作業中。

東京の勉強会にも行きたいな。

水泳

  • 100m Fr 1'00切る → 1'02'74
  • 200m Fr 2'20切る → 2'20'93

今年はもう少しのんびりやる。今まで筋トレをまじめにやったことないけど、故障防止のために取り組みたいです。

そんなわけで

みなさん、仕事はほどほどに。代わりはいくらでもいる。自分と自分の家族を大切に。

TDDBC NAGANO 0.1 に行ってきました

東京をはじめ各地で開催されているTDD BOOT CAMP(以下TDDBC) が長野で開催されました。
午前中は@さんと@さんの発表に続き、私も「.NETのテスティングフレームワーク」と題して発表しました。


今回は事前に練習してたんで、まあまあ言いたいことが言えてやりたいことができました。それほど難しい題材じゃないのでできて当たり前なんですけどね。。。

その後に@さんと@さんでペアプロ実演。ほんとはfizzbuzzを題材にする予定だったそうですが、私がそのネタを取ってしまったので、ボウリングのスコア計算機を苦心しながら実装することに。。

午後はプログラミング言語別にペアプログラミングをしました。題材はTDDBC東京で出題された自動販売機の実装です。

1.
・千円札と硬貨を投入することができる(1円玉5円玉は使えない。Exceptionを投げる)
・それ以外を投入された場合、Exceptionを投げる
・現在投入されている合計金額を算出できる

2.
・ID1 コーラ5本120円を在庫として保持する
・お金を投入すると、現在購入できるIDを算出する
・購入できるIDを指定して、ジュースを買うとコーラの在庫が減る
・現在の売上金額が算出される
・現在の在庫数が算出される
・在庫切れを考慮する

3.
・千円札5枚、硬貨はそれぞれ10枚保持する
・ジュースが1つ購入されるとお釣りとして、お金が減算される
・お釣りが足らなくて購入できない状態を考慮する
・現在のお釣り用のお金が算出される

4.
・ID2 レッドブル 5本 200円 を追加
・ID3 水 5本 100円を追加

ペアプロについて

私はC#ペアプロさせてもらいました。サボれないし、ちょっと気を使いながら、というのもあってかかーなり疲れました。

C#も含め下位互換を意識した(というか何かの流れをくむ)プログラミング言語って、人によって記述スタイルがまちまちに書けてしまうので、それを合わせるのにちょっとストレスですね。具体的にはfor eachで書くかforループで書くかとか。LINQ使う使わないとか。何度かペアを続けていけば、そういったプログラミングスタイルをすり合わせていって、本来注力すべきロジックに専念できるのでしょう。
rubyはそういうプログラミングスタイルの違いがC#/VB.NETと比較しては出にくいのかなー、と成果発表を見ながら感じました。

TDDに合う組織合わぬ組織

TDDは仕様を明確にしつつ内部実装を"その場"で作っていくというスタイルなので、箸の上げ下げレベルまで詳細に記述したプログラム設計書を事前に要求している開発プロセス、組織には合いませんね。ふむー。

ありがとうございました

それにしても、東京や名古屋に行かないと参加できなかったTDDBCが、チャリで15分の所で開催されたことは本当に嬉しい限りです。企画してもらった@さんに感謝いたします。ありがとうございました。また、NSEGを立ち上げてくれた皆さん、毎回参加している皆さん、幹事の皆さんに重ねて感謝いたします。今後もどういう形であれ続けていきましょう。
最後に、KPT形式で振り返り。

keep

会場が無料だった。良い会場でした。
お菓子を仕入れておいたのは良かったと勝手に思っている。
NUnit初心者の方に、ちょっと教えることができた。

problem

自社の人間の招へいが実現しなかった。私の力不足。
絶妙なタイミングで家を出て雨に降られた。

try

次のネタとしてはレガシーコード改善でしょうか。
自社の人間を呼びたい。タダでこの体験ができるのにもったない。

勉強会でfizzbuzz的なものをみんなで書いてみた

社内勉強会で、下記のようなお題でプログラミング大会的な催しをしてみた。

下記のような機能を持ったメソッドを実装してください。
クラス名、メソッド(関数)名、アクセス修飾子等は自由ですが、名前はレビューの対象としますので、処理内容を現すそれなりのものを考えてください。
入力:整数の配列
戻り値:文字列の配列
戻り値文字列の条件
・入力の整数配列の中から、3または5で割り切れる要素のみを抽出したものを文字列配列化したものであること
・ただし、3でも5でも割り切れる要素には文字列を付加(以下、付加文字列と表記)すること
 付加文字列の内容はクラスの外側から設定できること
 付加文字列の設定が無い場合は":hoge!"を既定値とすること
 クラスの概念のないプログラミング言語の場合は、メソッド(関数)の引数で付加文字列を指定すること
例:
 入力:1, 2, 3, 5, 10, 11, 12, 13, 15, 16, 17, 18, 19
 戻り値:"3", "5", "10", "12", "15:hoge!", "18"

解答者はみんなモチベーションの高い人ばかりだったので、彼らにとっては楽なお題になってしまい、またプログラミング言語の条件もなかったので「オレの中でナウでヤングな言語はコレだぜ!」ってな感じでプログラミング言語品評会のようになってしまいました。VB.NETC#、F#、JavaScriptpython、そしてVBA@accessなど、みなさん思い思いの実装をしていました。

かくいう私もF#にトライしてみました。書いてみたコードが下記です。

    module Study.ProductionFS
    open System.Linq

    type Filter() =
        class
            let mutable additionalString = ":hoge!"
            member this.FilterBy3and5multiples (list:int[]) = 
                list.Where(fun x -> (x%3 = 0) || (x%5 = 0))
                    .Select(fun x ->
                            if (x%15 = 0) then 
                                x.ToString() + additionalString
                            else
                                x.ToString()
                        ).ToArray()

            member this.AdditionalString
                with get () = additionalString
                and set (value) = additionalString <- value
        end

どーやらF#っぽい書き方じゃないらしい。のと、ProductionFSがnamespaceじゃなくてclassとして定義してることになってるような気がする。。。まあ初めてのF#ってことでこのまま掲載してみます。あと、はてなのシンタックスハイライトはF#に対応しているんでしょうか。。。?

何にしても、やっぱり勉強会は楽しいですね。

追記:シンタックスハイライトはocamlで代用しているとのコメントを頂きましたので、設定してみました。構文が似てるってことですかね。

TDD BOOT CAMP 信州をいつかやってみたいと妄想

何で「長野」じゃなくて「信州」なんだ?という疑問もありますがあえて。

近頃開催されて盛り上がった模様のTDDBC 札幌2.0の主催者id:shuji_w6e さんが、スモールスタートによる地方開催をすすめられています。
TDD Boot Camp 札幌 2.0 開催しました!(運営編)

先に結論を言ってしまえば、地方でTDD Boot Campをやってみたいな、と思っている人がいるならば、まずは自分たちでコンパクトにやってみると本編で生きてきます。主催者の得意な言語を使って、テスト駆動開発について勉強しようというのをやってみるべきです。

ちなみに、今後の地方開催も多く予定されていますね。

前回のNSEGid:tmtms さんが「TDDBCやってみたいですね」という話をしていたのですが、「やってみたいけどちょっとハードル高いなぁ。。。」と尻込みしているというのが正直なところでした。


だけど手始めということで定例NSEGの中で、ver0.1開催というのはいいですね。

  • 簡単なTDD体験をしてみる。FizzBuzzとはちょっと違う題材がいい。。。
  • 使用言語はrubyJava? ほんとは.NETがいいけど人口が少ない。。。
  • いつもの3時間だと少ないのか?15時19時とかにした方が良いのかな?

古いコードをコメントとして残すか否かの不毛な議論

世間一般では既に結論が出ているんだとは思いますが。未だに議論がある、というかようやく議論が起きてきたという状況(汗。

コメントとして残せ派

  • リポジトリがもし消えた時に過去の変更も消えちゃって困る
  • 直近の版を見るだけで変更の経緯を追いやすい
  • コードが見にくくても気合でやれ

コメントは不要だ派

  • リポジトリのバックアップは取るだろ、jk
  • VSS、SVN等のSCMを使えば過去の経緯は分かるだろ
  • いらんコメントがあったらコードが見にくいだろ

何言ってんだよ結論は出てんだろ、とおっしゃる方が大多数だとは思いますが、一応論点を絞ると「どうなっていれば、改修がしやすいか?」になると思います。

  • 改修実作業前の調査のしやすさ。(修正の経緯の読み取りやすさ)
  • 改修実作業のしやすさ

どちらを重要視するかで、古いコードをコメントとして残す/残さない の判断が分かれてくるのではないでしょうか。

とはいえ、このようなご指摘があり。。


どんな形で過去のソースコードを残すにしても「何故」が読み取れることはまずなく、だったら残さなくて良いだろう、という話になろうかと思います。
こんな議論をするよりもむしろ、tracやTFSなどでタスク(←ここに「何故」が含まれている)と変更セットを関連づけることにより「何故」を追いやすくすることを考える方が前向きなのでしょう。

ああ、TFS使いたい。