Powershell の psake でビルドスクリプト書いてみた

powershell psake

昨年から .Net なプロジェクトに携わっているんだが、ビルドスクリプトをなにで書けばいいかなーとか思ってたら Powershell にpsake というのがよさそうだったので色々調べたのでメモっておく。

参考: http://84zume.wordpress.com/2011/12/14/first-psake/

今回は Powershell 2.0, psake 4.1.0 で試した。
環境は以下。

Powershell のインストール

2008 にはデフォルトでインストールされているが、XPは入っていなので以下を入れる
http://www.microsoft.com/ja-jp/download/details.aspx?id=16818

psake インストール

https://github.com/psake/psake からダウンロードし適当な場所に解凍する。解凍フォルダにPATHを通しておく。

こんなのかいてみた

だいたいこんな雰囲気の "build.ps1" を書いてみた。

import-module build-functions.ps1 #自作util

property {
  $env = $parameters.env
  import-module $env.ps1 #パラメータ読み込み

  $slnFilePath = path¥to¥Hoge.sln

  $compiledDir = compiled
  $zipFIlePath = path¥to¥Hoge.zip
}

task package -depends clean, compile, zip

task compile {
  msbuild $slnFilePath /Configuration=Release
}

task zip {
  zip $compiledDir $zipFilePath
}

task clean {
  remove-item $compiled -force -recurse
  write-host "$compiled Deleted."
}

package タスクをコマンドプロンプトから動かすときはこんなかんじ。

> psake build.ps1 -framework 3.5 -parameters @{env='test';hoge='fuga'} package

コマンドラインパラメータをスクリプトから参照するには $parameters.env といった感じでアクセスできる。

ついでに zip/unzip 使えるようにしてみた

標準だと zip 使えないようなので、調べてみたら Ionic.Zip.dll でできるらしい。
ので、 zip と unzip の function を作ってみた。

第2回 IT英語学習法カンファレンス #itencon に参加してきた

report english

2月29日 第2回 IT英語学習法カンファレンス #itencon(東京都)に参加してきた。
講演頂いた柴原早苗さん、主催の@kaorun55さん、参加者の皆様ありがとうございました！

今回の勉強会は英語をどうやって学習していくかの勉強会でした。
詳しい内容は@shinyaa31さんにより素晴らしくまとまっています。いつもお世話になってます。

第1回のまとめをみて「これは行きたい！」と思ってたので今回参加できてよかったです。

講演

柴原さんのBBCで通訳するまでのお話。

お話の中で、

  • 諦めないこと
  • 好きであること、そのことを通して何ができるか
  • 運も必要
  • 人との縁
  • ダメなときはどんだけあがいてもダメなので、ときには待つことも必要

といったことを感じた。
諦めないこと、継続することはやっぱり大事、と改めて思った。

日々の学習においては大事なこと
  • 時間を決めて集中して行う。だらだらやらない
    • ワークショップもキッチンタイマーでやってた、メリハリ重要
    • 1,2分でもいいので少しでも時間を確保すれば学習はできる
英語の捉え方
  • 情報を得るため、伝えるためのツールであること
    • 英語そのものを目的にすると疲れちゃうし、行き詰まるかも

ワークショップ

大事なことはこんなことと感じた。

  • 音読すること
    • 五感を使って習得する感じ
    • 発音する(アウトプットする)経験はあるのとないのでは全然違う
  • 反復すること
    • 定着させる
  • 楽しくやること
    • 継続させる

独習する際の教材の選び方

  • 音声
  • スクリプト
  • 訳文

これらがあるものを選ぶとよい

以下ワークショップでやったこと。

Warm Up
  • Shadowing
    • 日本語のラジオニュースを聴いて、日本語で追っかける
      • 意外と完璧に追いかけきれない
      • 自分の知らない分野の言葉とかは出てきづらい、英語でも同じ
      • 知識だけでなく口にしているかどうかで、全然違う
Vocabulary

テキスト(教材)によっては、ボキャブラリー(単語の説明)がある場合も。しっかり音読する。

  • 英語→和訳で音読。少し早いかなぐらいのテンポでリズムよく。
Over Wrap

(スクリプトを見ながら)英語音声に合わせて音読する。

  • 多少言えなくても、とばして音声についていく。
  • 和訳も読む。時間で切って集中する。
Slash Reading

文を意味のある塊に区切って音読、続けて区切った塊の訳す（和訳を音読する）

  • 少し長い文でも、ちょっとずつ
後ろから音読→暗唱

文の最後の部分（文節）を音読→文を見ずに(look up)音読→最後の前の文節を追加し音読→文を見ずに音読→・・・続く

  • 英語の場合後ろから音読すると覚えやすい
例文の一部を入れ替え
  • 文中の数字や曜日など入れ替えて文を作って、音読する
    • 反復にもなるしよさそう

こんな勉強法もあるよ

メモ取り

これぞ同時通訳という感じのメモ。速記ではなく同時通訳するための備忘録だそう。
英語を聴いて、話のポイントをメモする。（備忘録なので自分がわかればいい。柴原さんは記号（矢印）なんかもつかってた）

  • 最初は難しいけど、リスニングのポイントを意識するトレーニングとしてもいい
音読筆写

英文を聞きながら書き写す

  • ディクテーション力アップ
  • 書き写す紙には罫線があるといい
  • 聞き取れなかったところを虫食いにすると見つけやすい
日々の学習Tips
  • 電車の中で音読できないときは?
    • 口パクする。この季節はマスクつけることも多いのでやりやすいｗ
  • 英字新聞でボキャブラリーを増やす
    • 日本語と対比することにより、「英語ではこう言うんだ」というのを感じる
    • 例えば、同じ新聞の英字と日本語の同じ見出しを対比する
    • 例えば、英字のテレビ欄を対比する。（英語で徹子の部屋ってなんていうんだろうとかｗ）


英語をどうやって勉強していこうか悩んでたこともあり非常に勉強になった。
これを参考に自分の日々の学び方を考えてみよう。

iOSのRemote Notificationを試してみた

iOS

iOSのRemote Notifiacation(Apple Push Notification service:APNs)を試したので手順をメモっとく。
環境は OSX(Lion)+Xcode4.2

準備しとくこと

大まかには以下。

  1. iOS 実機でiOSアプリを動作確認できるようにする
  2. APNs可能なProvisioning Profileを準備する
  3. プロバイダ(サーバアプリ)に必要な証明書ファイルを準備する
iOS 実機でiOSアプリを動作確認できるようにする

iOSアプリを実機で動作確認しよう-プロビジョニングファイルの作成手順- ｜ クラスメソッド開発ブログ にキレイにまとまってる。
実際にこれと同じことをやった。

ハマったことと言えば、Developer Programを登録する際のAppleIDの名前が日本語だったので、申請途中でペンディングになったこと。
申請とおらないなぁと思いつつしばらく気づかず、数日後に気づいて（名前が????になってた）、
Apple IDの名前を英語表記にしたら、数時間後Apple側で処理再開してくれったぽい。

名前や住所は英語表記に、日本語の住所をiTunesなどで使いたい場合は別アカウントのほうがいいかのかも。

あと、Organizerのサイドバーの"Provisioning Profile"で、"Automatic Device Provisioning"というのをチェックしておくと、
"Use for Development"ボタンを押した際に、自動的に登録される模様。

APNs可能なProvisioning Profileを準備する

上記のProvisioning Profileは汎用的なものなようなので、APNsが利用できない。
なので、新しくProvisioning Profileを作成し、そっちでAPNsできるようにする。

  • Provisioning Portal にいく
  • サイドバーの"App IDs"からApp IDを作成する
    • New App IDボタンから必要事項を入力する
  • 証明書を取得し、キーチェーンアクセスに登録する
    • 作成したApp IDが一覧に追加されるので、Configureボタンを押下
    • "Enable for Apple Push Notification service"のチェックボックスを押下
    • 今回は"Development Push SSL Certificate"の”Configure"ボタンを押下
      • 証明書要求ファイルは前節で作成したものを使った
      • 証明書をDLする
      • 証明書をダブルクリックしキーチェーンアクセスに登録
  • Provisioning Profile を作成
    • ProvisioningPortal でサイドバーのProvisioningを選択
    • "New Profile"ボタンから必要事項を入力
      • App IDは上で作ったものにする
    • 画面リフレッシュすると一覧に追加されているのでDL
  • Provisioning Profileを登録
プロバイダ(サーバアプリ)に必要な証明書ファイルを準備する

Macのキーチェーンアクセスとopensslで証明書を作成する

  • キーチェーンアプリを起動
  • 自分の証明書を秘密鍵を選択状態にする
    • 左上のキーチェーンを"ログイン"、左下の分類を"自分の証明書"から行くと、証明書と秘密鍵が階層になっているのでこの２つを選択
  • メニューバーの[ファイル] - [書き出す] を選択
    • フォーマット".p12"形式で書きだす
      • パスワードを何か決めて入れる
  • 以下のコマンドで"pem"形式に変換
    • openssl pkcs12 -in CertificateName.p12 -out CertificateName.pem -nodes
      • パスワード聞かれるので".p12"形式で書きだした際のパスワードを入れる

CertificateName.pem をプロバイダが使用してAPNsにアクセスする。
また、このやりかただと接続する際にパスフレーズは不要だった。

プロバイダでやんないといけないこと

大まかには以下。

  1. iOSからデバイストークンを受け取る
  2. プロバイダからAPNsに通知したい情報を送信する
    1. 通知したいデバイスのデバイストークンも渡す
    2. APNsとはSSL通信するので証明書が必要。（このへんの準備の理解があやしい）
  3. APNsからプロバイダへのフィードバックを受け取れるようにする
    1. (iOSアプリのアンインストールなどで)通知に失敗した場合など、APNsからフィードバックされる


プロバイダ側も色々あるが、今回はiOSで通知を受け取るのに必要最低限なところだけ書く。
動作確認用に、Apple Push Notification Services Tutorial: Part 1/2 にあるPHPのサンプルをプロバイダとして利用した。
なので、以下を行った。

  • iOSからデバイストークン受け取る代わりに、iOSのデバッグログからコピってコードに直接書く
  • APNsからのフィードバックはやんない
  • 先ほど準備した証明書を"ck.pem"という名前でPHPサンプル(simplepush.php)と同フォルダに置く

で、実行すると

$ php simplepush.php
Connected to APNS
Message successfully delivered

といった感じで成功した。

iOSアプリでやんないといけないこと

大まかには以下。

  1. iOSに対してAPNsにデバイストークンを登録するための依頼をする処理を書く
  2. iOSからデバイストークンを受け取ったときの処理を書く
  3. iOSからデバイストークンを受け取れなかったときの処理を書く
  4. APNsから通知を受けたときの処理を書く

以下のようなコードをApplicationDelegate.mに追記。
今回はiPod touch(4th)+iOS 5.0.1 で試し、通知を受け取ることができた。

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    //画面起動時の初期化がここで行われる

    //以下を追加。通知を受けたい種別を引数に渡す
     registerForRemoteNotificationTypes:(UIRemoteNotificationTypeBadge |
                                         UIRemoteNotificationTypeSound |
                                         UIRemoteNotificationTypeAlert)];
    return YES;
}

//デバイストークン取得に成功した場合呼ばれる
- (void)application:(UIApplication *)app
didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)devToken
{
    NSLog(@"Registration Successed. token: %@", devToken);

    //ここでプロバイダにデバイストークンを送信すべし
}

//デバイストークン取れなかった場合（シミュレータの場合ここにきた）
- (void)application:(UIApplication *)app
didFailToRegisterForRemoteNotificationsWithError:(NSError *)err
{
    NSLog(@"Error in registration. Error: %@", err);
}

//通知センタや通知ダイアログから起動すると呼ばれる
//アプリがforegroundの場合もこれが呼ばれた
- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo
{
    NSLog(@"ReceiveRemoteNotification on foreground: %@", userInfo);
}

もっと他にも色々ありそうだけど、とりあえずここまで。

参考資料

Developers Summit 2012 (#devsumi) に参加してきた

report devsumi

2/16,17に開催されたデブサミに参加してきた。3年ぶりの参加。

運営・スタッフの皆様、スピーカーの皆様、参加者の皆様お疲れさまでした。ありがとうございました！

今回はキャリアプラン的なセッションを主に聴いたので、
初日の最後のセッション「あの人の自分戦略を聞きたい！」を聴いて感じたことなどをとりとめもなく書いてみる。

オーナーシップ

kuranukiさんがおっしゃっていた。
起業するとかそういうことではなく、会社の一部に組み込まれているような感覚を排除する、
会社が自分のお客様、自分と会社を切り離して考える、と自分は理解した。
つまり自分がより「個」になるというイメージかな。
こう考えるといろいろと繋がってきたような気がする。

アウトプットする

  • 仕事以外では、ブログやコードなどでアウトプットする。自分を高める、学びに繋げる、自分を表現する。
    • もしかしたらいつか誰かの役に立つかもしれない！
  • 今まで出会えなかったようないろいろな人と繋がる。

会社がアウトプット（仕事）する場と考えると、
ブログやソーシャルメディアや勉強会なども、アウトプットする場と考えられる。
こう考えると、どちらの場でもアウトプットできるものは外（より広いところ）でアウトプットしたほうがいいよね。フィードバックもらえるかもしれないし。

学ぶ姿勢

  • アウトプットをよりよいものにするために。より価値あるものにするために。
  • 年齢関係なく年下からも学ぶ姿勢。
  • 会社以外でもアウトプットしよりよいインプットを得る。

セルフブランディング

  • 自分の実力を価値ある状態にする

より「個」になっていくと考えると、自分の価値をきちんと表現すべきということか。
会ったこともない人とも繋がるわけだし、とりあえずプロフィール欄は整理しよう・・。

継続する

  • 継続してこそ自分を高める、よりよくなる。
  • 無理せず自分の出来る範囲で。少しずつ、ちょっとずつ。

自分のペースで少しずつでも続ける。
自分の感覚を信じてアウトプットを続けよう。

SCMBootCamp in Tokyo 2 に参加してきた

bazaar git report scmbc

11月19日 SCMBootCamp in Tokyo 2（一次募集）(東京都)に参加してきました。
スタッフの皆様、参加者の皆様お疲れさまでした。ありがとうございました！

第１回に続いて２回目の参加で、今回はBazaarで参戦しました。

当日の状況は、

にまとまっているので、
自分が得たことや感じたことをつらつらと書いていく。

基調講演：分散リポジトリ型時代のソフトウェア構成管理

非常に資料・説明ともに分かりやすかった。非常に参考になります。
僕も第三世代で幸せになりたい。

  • SCMツールなくても同等なことできるでしょ？⇒やってやれなくないが労力の無駄。
  • 分散SMCツールの「分散」はリポジトリが「分散」。リモートリポジトリを頼らなくてもSCMツールの機能低下なし。
  • リモートリポジトリへの連携(push/pullなど)は明示的に行わなう必要がある。
    • いちいちpush/pullしないといけないのがめんどくさいと感じるけど、リモートへpushする前に手元で確認できるタイミングがあるのはいいと思う。
  • コミットログは汚れても気にしない、そもそも数が多くなると全部みることは少なく検索するほうが多い。
  • オフラインサテライトなどネットワークに制限があるなかでの利用方法は非常に参考になる。
  • 品質管理ゲートウェイやってみたい！
    • 単に構成管理として利用するだけでなく、ワークフローやデプロイに組み込んでみたい。
  • めんどくさいツールで構成管理していた（第二世代）。納得。

講演：SCMBC Git入門セッション発表資料

  • Gitの内部構造の説明は非常に分かりやすい。
    • 特にコマンドとそれに伴うオブジェクトの変化が理解しやすかった。
  • "A successful Git branching model"参考になりそう。
  • コミットメッセージの書き方あったのか・・・あー、入門Gitにも書いてあるし。
    • 1行目：変更内容の概要
    • 2行目：空行
    • 3行目：変更した理由

講演：Bazaar入門セッション - SCM Boot Camp #2 — Bazaarスタートアップガイド 0.0.1 documentation

  • コマンドはsvnとほぼ一緒、挙動もあまり違和感がない。
  • ブランチはフォルダで表現
  • メインラインが存在する。
    • Bazaarがメインラインとそれ以外を区別している

演習

前回同様グループでそれぞれのDVCSのチートシート作成。
実際にコンフリクト起こして競合解決してDVCSを体感。

  • bzr はメインラインがはっきりしていて、qlogで見てもブランチでおきたごちゃごちゃしたところが気にならない。
  • ごちゃごちゃしてたらuncommitしてコミットもまとめられる
  • よく使うコマンドはsvnの感覚でイケル
  • 演習３セット目あたりで、少し変化があってもいいかなぁ。ちょっと物足りない感じがした。
  • bzr-svn使えばsvnでマージに激しく時間が掛かっているのは改善されるかなぁ。今度ためしてみよ。
  • (今回ためした範囲では)理解が難しい部分はそれほどなかったので、SVNからの乗り換えは比較的敷居が低そうな感じがした。

MacOS X(Lion)にBazaarをインストールしてみた

bazaar mac

11月19日 SCMBootCamp in Tokyo 2（一次募集）(東京都)に申し込んだところBazaarでの参加になった。
ので、さっくりインストールするつもりだったが、少しはまったのでメモしておく。
環境はMacOS X(Lion)。

Bazaar のインストール

結論としては、500 Internal Server Errorのとおりにやると動いた。

  • stableのdmgをダウンロードする
  • 落としたdmgを展開しインストール

Bazaar の動作確認

で、自分の環境だとこのまま動かすと以下のようなエラー発生。

$ bzr --version
bzr: ERROR: Couldn't import bzrlib and dependencies.
Please check the directory containing bzrlib is on your PYTHONPATH.

Traceback (most recent call last):
  File "/usr/local/bin/bzr", line 102, in <module>
    import bzrlib
ImportError: No module named bzrlib

調べてみたらどうやらbazaar-mac-installerのバグっぽい。

python2.6ではないからか。たしかに自分の環境はpython2.7がデフォルトのようだ。
解決方法もある模様。というか、LionにするとPythonのバージョンが2.7にあがるのか・・・。

/usr/local/bin/bzr の中身を変えるのもなんだかなぁという感じだったので、(これでも動いたっぽいけど)
もう少し調べたらPythonのデフォルトバージョンを指定するよさげな方法がでてきた。

$ export VERSIONER_PYTHON_VERSION=2.6
    • 恒久的に変える場合
$ defaults write com.apple.versioner.python Version 2.6

＃500 Internal Server Errorの上の方にちゃんと書いてあるし・・・

というわけで、インストールできたっぽい。

$ bzr --version
Bazaar (bzr) 2.4.1
  Python interpreter: /usr/bin/python 2.6.7
  Python standard library: /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6
  Platform: Darwin-11.2.0-x86_64-i386-64bit
  bzrlib: /Library/Python/2.6/site-packages/bzrlib
  Bazaar configuration: /Users/username/.bazaar
  Bazaar log file: /Users/username/.bzr.log

Copyright 2005-2011 Canonical Ltd.
http://bazaar.canonical.com/

bzr comes with ABSOLUTELY NO WARRANTY.  bzr is free software, and
you may use, modify and redistribute it under the terms of the GNU
General Public License version 2 or later.

Bazaar is part of the GNU Project to produce a free operating system.

(たぶん)MacPorts使っている場合の注意点

MacPortsでpythonをいれると /opt/local/bin/python にインストールされる模様。しかもそのパスがシステムのPython(/usr/bin/python)より優先されている。
ので、上で書いたデフォルト指定しても、フルパスでないpythonコマンドのみだとバージョンは変わらない。
あくまでもデフォルトは、システムの /usr/bin/python のバージョンが変わるようだ。
Bazaarは /usr/bin/python を使っているので2.6で動いてくれる。

第27回すくすくスクラム 〜タスクカンバンはこれだ！〜 に参加してきた

scrum agile report

すくすくスクラムに初めてに参加してきた。
スタッフの皆様、参加者のみなさまお疲れさまでした！ありがとうございました！

先日の Scrum Gathering Tokyo 2011 Day2 に参加したときに今回の開催を知ったのと、
最後のWRAPUPで参加する！と宣言したので実行してみた。

今回はタスクかんばんの回ということで、割と身近な話題。現場でも活用したい。
感じたことや得たことなど書いてみる。(スクラム実戦経験ゼロ)

ユーザストーリ

  • ビジネスの言葉で表現する（開発、PO、ステークホルダ全員がわかる言葉で）
  • よいユーザストーリはINVEST
    • scrumの考え方や価値観がよく表れていると感じた
    • ワークではINVESTを踏まえる暇もなかったなぁ・・
  • 見積もり
    • 相対見積もり(SP)
    • 見積もりはストーリのバックグラウンドがわからないと当然ブレる
    • そもそも見積もりは（最初のうちは）よく外れる、スプリントを進めていく中で精度を上げる（あがっていく？）
    • プランニングポーカーやりだすと時間あるだけつかっちゃいそう。
      • 優先度を高いストーリからやる、できなかったものは都度でやっていく（だったかな？）
      • ストーリだけでなくて、タスクもやるのかな？ますます時間が・・・
  • 粒度の問題
    • ゴールがよくわからないものはエピックとして、さらに細かい粒度のストーリに分割する
    • SPが2桁になるとエピックにしていることも。(塹壕よりXP でも 13SP 以上でストーリ分割といっていたような)
    • コンテキストにより良い粒度は異なる模様

タスク分割

  • そのストーリでやらなければならないこと作業すべて洗い出す
    • 技術スパイク(見積もれないときの調査など)も
    • ミーティングやレビューも
    • ドキュメント作成も
  • 理想時間で見積もる
    • 2〜8h程度がいいよ
    • バーンダウンチャートに使う
  • 実際には理想時間でなかなか作業できない(現実時間)
    • 1日でいうと AM:2h, PM:2h+2h ぐらいで考えるとよさそう
    • 初めての時など、フォーカスファクタで現実時間を割りだすといいかも
      • 実績から読めるときは、実績を信じたほうがいい
  • グループ発表でタスク分割して見積もりするの大変という意見が思ってたより多かった
    • 自分はタスクを洗い出すことは普段からやっているせいなのか、ちょっと意外だった
    • (特にマネージャなどの)各所への調整タスクなどは見積もりにくいに激しく同意。どうしたものか
      • マネージャだけ、かんばんに参加していないのもなぁ、うーん・・・
      • それでも見積もって振り返るべきか
  • スプリント中にタスクが増えたら、バーンアップさせるといつ増えたかがわかりやすい。振り返りなどで分析できるかも。
  • 2週間ぐらいのスプリントだったらバーンダウンチャートいらないんじゃ、という意見もあった
    • 個人的には振り返るときにはあったほうがいいかなと思った。たしかに作るのはめんどくさいかもしれないけど。

その他

  • 2時間があっという間だった
    • 1日や半日の勉強会と同じ感覚で臨んでしまった・・・あんまり喋れてない
  • sgt2011 のユーザストーリファーストジェネレーションの資料をもう一度見直す
  • またすくすくに参加する

今回の勉強会とは直接関係ないけど、スクエニCTO橋本さんの資料が興味深かった。
今度2点見積もりやってみよう。