謹賀新年
あけおめでございます。
あまりまとまりませんが、昨年のふりかえりと今年の抱負なんかを。
さようなら.NET
最近は諸事情で.NET+Windowsから離れてJava+Linuxやってます。「あ…ありのまま今起こった事を話すぜ!『俺はTFSを使っていたと思ったら、いつの間にかRedmineを使っていた』。な…何を言っているのかわからねーと思うが、(以下略」という表現がしっくりきます。
Javaを勉強すればするほど.NETの素晴らしさを痛感します。が、新しい技術を仕事で学べることを前向きにとらえて、日々試行錯誤していきたいです。
それでも.NET
仕事はそんな感じですが、仕事以外は.NETで。。。
WPF
昨年は、WPFでデスクトップアプリを作る機会があり、*1今年も細々と継続することになりそうです。今までデスクトップアプリを本格的に*2開発した経験はなく、WPFはもちろんインストーラやら難読化やら何やらで、試行錯誤しつつ非常に勉強になりました。 そして何より、ユーザーと直接会話して一緒に作りユーザーから直接感謝の言葉を頂くのはやりがいがあります。*3
kinect
実は勢いで買ったkinectがわが家にありまして。。。昨年は上記WPFアプリの関連に時間を割いたのでkinectは埃をかぶったままでした。今年は少し余裕ができるハズなので、何か作れたらなあと。
windows phone
ドコモさんはオレオレOSを発表する始末で結構絶望的なんですが、windows phoneが国内で発売されたら端末をゲットしてアプリを作ってみたいです。ほんとたのみますよ、ドコモさん。 というか、コンシューマ向けのOSについてはこの先windowsは先細りなんじゃないか?もう業務システムの端末でしかwindowsは生きていけないんじゃないか?と結構本気で心配になります。
ことよろでございます
今年も今までどおりマイペースで6割の力で日々過ごしたいですが、そうはいっても自分の真剣みが足りんなーと感じること最近多々あったので、ちょっと足して7割くらいの力でいこうと思います。そして何より健康第一で!
TFSへのチェックインをフックする
メモっとく。チェックインをトリガーにメールを出したい、くらいならalert機能を使えばいいんですけどね。
詳しいことはソースを見てください。変更セットに関連づいた作業項目の取り方が分からないので、もう少し調べてみようと思います。というか、誰か教えてください。。。
これを使えばいろんなことができそう。
using System; using System.Net.Mail; using System.Text; using Microsoft.TeamFoundation.Common; using Microsoft.TeamFoundation.Framework.Server; using Microsoft.TeamFoundation.VersionControl.Server; namespace TfsHookEvent { /// <summary> /// ・Microsoft.TeamFoundation.Framework.Server.dll /// ・Microsoft.TeamFoundation.VersionControl.Server.dll /// はTFSをインストールしたサーバの /// c:\Program Files\Microsoft Team Foundation Server 2010\Application Tier\Web Services\bin /// から持ってきて参照設定する。 /// /// ・Microsoft.TeamFoundation.Common.dll /// を参照の一覧から、参照設定する。 /// /// ビルドしたDLLを、TFSサーバの /// c:\Program Files\Microsoft Team Foundation Server 2010\Application Tier\Web Services\bin\Plugins /// に置く。 /// </summary> public class CheckinHooker:ISubscriber { public string Name { get { return "TFS Hook Event Sample"; } } public SubscriberPriority Priority { //何の優先順位かは不明。。。ProcessEventが呼ばれる順番?? get { return SubscriberPriority.Normal; } } public EventNotificationStatus ProcessEvent(TeamFoundationRequestContext requestContext, NotificationType notificationType, object notificationEventArgs, out int statusCode, out string statusMessage, out ExceptionPropertyCollection properties) { statusCode = 0; properties = null; statusMessage = string.Empty; if (notificationType == NotificationType.Notification) { try { var checkinNotification = notificationEventArgs as CheckinNotification; Debug.WriteLine("変更セットID={0}", checkinNotification.Changeset); Debug.WriteLine("チェックインユーザーID={0}", checkinNotification.ChangesetOwnerName); Debug.WriteLine("チェックインコメント={0}", checkinNotification.Comment); //ほかにもいろんな情報を取れそう。 } catch (Exception exception) { //ここで出したエラーはイベントログに出る TeamFoundationApplication.LogException("ProcessEventでエラー", exception); //エラーは潰しとく。 } } return EventNotificationStatus.ActionPermitted; } public Type[] SubscribedTypes() { //フックするイベントの型を指定 //http://msdn.microsoft.com/en-us/library/dd545177(v=vs.110) //にある、なんちゃらNotificationを指定すれば良いと思われる。いろいろあるな。 return new[] {typeof (CheckinNotification)}; } } }
夏サミに行ってきた所感とえらい人が”ソーシャル”に対して感じてい
(この記事は2012/08/01に書きました。)
久々にトーキョーのイベントに行ってきました。
「ソーシャル・エンタープライズ」がテーマということで、yammerについていろいろ話が聞けることを期待していったのですが、聞けることは聞けたのですが期待ほどではありませんでした。ダイアモンドスポンサーが、chatterを抱えるsalesforceでは止むを得んところもあったのかもしれません。
以下メモ。
- 複数のAPIからの情報を統合してタイムラインに情報を出す
- →所感)順位付けとタイムラインの生存期間の決め方が重要だ
- 信頼こそが最大のコスト削減→所感)まったくもっておっしゃるとおり
所感)
- sharepointとoffice talkとyammerの関係がよく分からなかった
- Atlassian Tシャツをもらった!
- yammerのbotを作ってみたくなった
ソーシャルってのは部門や企業間の壁を取り去ってフラットに人と人が繋がれるようになる。個人的にはいいことだと思うし、私の観測範囲でもみなさん好意的に思っているようにうかがえる。
でも会社の中を見れば必ずしもそういう人だけじゃない。実際某社で企業内SNSが導入されたときに、「本来の組織構造を逸脱した情報の流れ」ができてしまい、「自分のあずかり知らない所で何かが決まってしまう」ということを理由にSNSを否定している部長が複数いた。これは伝聞ではなく、本人から面と向かって聞いたときのことだ。そのときは私はひどく落胆し絶望したのを今でもはっきり覚えている。
私の話し方が悪かったのかもしれないし(SNSで何かが決まってしまうことはないだろうし...)、ひとつの部を預かる責任的なものを私が理解できてないからなのかもしれない。でもこういう人は確かにいる。
時間が解決する話なのかもしれんけどなー。
特に上場企業の場合は、内部統制やコンプライアンスの点から厳密な権限管理が要求されるだろう。今後のyammerはADと連携させて権限管理ができるようになってほしいな。
Server.Transferで画面遷移が無限ループ
ハマったのでメモ。
一度のリクエストの中で、Server.Transferを使ってA→B→A(異常系に多い画面遷移)という風に画面遷移をすると、画面遷移が無限ループした。B→Aの遷移でAに来たときに、btnTransfer_Clickが発火してしまう。そして再度Server.Transferが呼ばれるという状況。
コード例:
■A.aspx.cs (A.aspxは、ボタンが一個置いてあるだけ)
public partial class A : System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { } protected void btnTransfer_Click(object sender, EventArgs e) { this.Server.Transfer("B.aspx", true); } }
■B.aspx.cs (B.aspxにはコントロールは何も置いてない)
public partial class B : System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { //this.Server.Transfer("A.aspx");だとループしない this.Server.Transfer("A.aspx", true); } }
第二引数無しのServer.Transferだとループしない。preserveFormがTrueのときはポストパラメータが保存されるけど、一度のリクエストの中で元の画面が再度呼ばれたときはポストパラメータが消えるようにASP.NETの内部で制御している模様。しかし第二引数にtrueを指定すると、ポストパラメータが残っており、クリックイベントが発火してしまう。
this.Server.Transfer("A.aspx"); //OK
と
this.Server.Transfer("A.aspx", true); //NG
はMSDNを見る限り等価なように思えるが、そうではないようだ。connectにそれっぽいのがあったけど、詳しい話が書いてあるであろうリンク先が消えていた。まあたぶん同じ現象なんだろう。どうやら.NET1.1からある話のようだ。
というわけで、
public static void MyTransfer(Page page, string Url, bool preserveForm) { if (preserveForm) { page.Server.Transfer(Url); } else { page.Server.Transfer(Url, false) } }
みたいなパッと見は意味不明なラッパを用意すればいいかな、という結論になった。ということの調査に一日を費やした。。。
ググってもあんま情報のってなかったんだけど、みんなハマることはないんだろうか。それとも、ASP.NET Web Formなんていう、おわこんなものを使っているのはうちだけだからか。。。
ソフトウェア技術者サミット in 長野 2012 に行ってきた
2012/06/04に行われた、ソフトウェア技術者サミット in 長野( http://www.agileprocess.jp/news-1/nagano2012 )に行ってきました。開催を聞いたときは「何で長野でやるんでしょ?」って思ったんだけど、数年前から全国津々浦々を巡業して回っており、今回で16回目だそうです。NSEG関係者も数名ほど来てました。せっかくの長野開催なのでもう少し人が集まれば良かったんですけど、平日の日中なので仕方ないですかね。
印象に残ったことをメモ。細かな記録は、議事録の人がきっとレポートしてくれるでしょう。
湯本 剛 氏「ソフトウェアテストにまつわる3つの疑問」
パネルディスカッション「アジャイル開発での悩み相談」
- 情シスはアジャイルを喜ばない(ことが多い)。「ちゃんと考えている」ユーザーにリーチし信頼関係を築ければ、アジャイルでやろうという話もできる
- 見積もりは外れる、という前提で。バッファでいかに吸収するか
- BTSなどのツールは、コミュニケーション手段にしてはいけない。トレースするもの。会話のきっかけを作るもの。(所感:確かに、コメント機能で会話を始めてしまわないようにしないと。。。)
- BTSはチケット登録のルールを決めた方が良い
- アジャイルだとプロジェクトの問題が良く見えてくるようになる。問題がたくさん出てくるので短期的には大変だし不安を感じてしまう。でも長期的にみれば、問題が早く出てくるので良いのです。
どうせだからと、「イテレーションとイテレーションの間で依存している部分はどうするんですか?(あまり訳されてないけど意訳)」という質問してみました。これに対する回答は、いろいろ脱線したりしたんですけど、アジャイル開発の考え方のひとつに「YAGNI(You Aren't Gonna Need It」」というものがあるため、その考え方に従って「そのイテレーションで必要なもののみ作る」んだそうです。帰り際に@tmtms(ペンネーム:とみたまさひろ)さんと立ち話ししときに「作ると分かっている部分は、そのつもりで作っておきますよ。」とのこと。まあそう固く考えるなってことですね。アジャイルの経験がないもんで、「イテレーションごとに作る」ってところがいまひとつ想像がつきません。
パネルディスカッションの中で、「機能間のやりとりはキューにして依存関係を弱くする」、とか「イテレーションごとにテストがしやすいようにアーキテクチャ設計すべきだ」、みたいな話があって非常に面白かったです。この辺はアジャイル云々を抜きにしても大事な考え方ですね。
あと、某HDDの話もあり、やっぱり他社の方と話すと勉強になるなーと思いました。HDDについては居酒屋で酒の肴にでもどうぞ。
第27回 #nseg 勉強会(Titanium Mobile ハンズオン)に行ってきた。
第27回#nseg勉強会が2012/05/26(土)に長野高専にて開催されました。参加された皆さま、講師の増井さん、お疲れさまでした。
開催概要はこちらです。
NSEG勉強会は普段はテーマを大まかに決めて5分から30分のLT(Lightening/Long Talk)をするという形式なのですが、今回はAppcelerator社の増井さん(@masuidrive)を招いてのTitanium Mobileハンズオンが行われました。ハンズオンはおおまかにこちらに沿って進められました。
Titanum Mobileについて
Titanium Mobileについての詳しくは、このへんをご覧ください。うたい文句は「Write Once, Adapt Anywhere」で、同一のコードで各モバイル端末に「最適化した」UIを描画するという意味だそうです。
ハンズオンを受講した限りでは、なかなか期待できる開発プラットフォームですね。以下は.NET 開発者の視点から見た感想。
良い点
- JavaScriptで開発できる
私はJavaとobjective-cは未経験なので、経験のあるJavaScript(好きじゃないけど)*1で開発できるというのは個人的には嬉しいことです
これが一番のウリですからね。そうはいっても、ソースコードの中で if (Titanium.Platform.osname == 'android') といったどの端末で動いているかによる分岐は避けられません。このへんを理解した上での設計が重要かなと思いました。
今後はwindows phoneにも対応する予定だそうです。個人的には期待。
どーしようもないときの逃げ道があるのは大事ですね。
気になった点
- UIのデザイナが無い
すみません、Visual Studioで育ったもので。。。XcodeやAndroid SDKでの開発でUIデザイナ画面があるのか知らんのですけど、Visual Studioみたいにデザイナから.designer.csみたく開発環境がコードを生成してくれると嬉しいんじゃないでしょうか。