ASP.NET ボタン連打による複数回PostBackを防止する

ASP.NETでボタンを連打すると、リクエストは全て処理されるが画面に返されるレスポンスは最後の一回のものになってしまう。

これではいかん、ということで連打を防止する場合以下のようにする。


<asp:Button runat="server" ID="BtnSubmit" 
  OnClientClick="this.disabled = true; this.value = 'Submitting...';" 
  UseSubmitBehavior="false" 
  OnClick="BtnSubmit_Click" 
  Text="Submit Me!" />

ポイントはOnClientClickでボタンを無効化する(ついでにボタンテキストも変えている)点と、UserSubmitBehavior="false"にしてある点。

ボタンを無効化しただけだと、ポストバックが発生しなくなってしまう(無効なボタンからポストバックは発生しない)。UserSbumitBehavior=falseは、webにおけるformアクションに頼らず、とにかくPostBackしなさいという意味になるので、これでＯＫ(名前的に起こさなくなりそうだが・・・)。

ページが再ロードされれば無効化したのもボタンのテキストを変えたのも元に戻るので、これにて一件落着。

参考サイト
http://encosia.com/disable-a-button-control-during-postback/

ASP.NET MVC を Appharbor へデプロイする際の注意事項

少しはまったのでメモしておきます。

ASP.NET MVC (今回は最新の4を使用) をAppharborにデプロイする際、デフォルトでは勝手にライブラリをロードしてくれないようです。そのため、packageフォルダをデプロイ対象からはずしているとビルドエラーになります。

・packageのフォルダは基本.gitignoreではずす(重いので)
・しかし、この場合packageのロードが行われずビルドエラーになる（MSB3245　xxx but it didn't exist. が多発する）。

対応として、ビルド時にpackageをロードするようプロジェクトを設定する必要があります。

その方法は公式サイトで公開されています。

パッケージ再ロード設定


このページではプロジェクト＞右クリックで「Enable NuGet Package Restore」をしてくれといっているのだが、私の場合「え？そんなメニューないんですけど」という状態でした。
そんなときはこちらをご参考。

Enable NuGet Package Restoreを表示する方法


それでも出ないという場合(私の場合・・・)は、ツール＞ライブラリパッケージマネジャー＞パッケージマネージャーコンソール　でNugetのコンソールを起動し、以下コマンドを実行。


Install-Package NuGetPowerTools
Enable-PackageRestore

Nugetのコンソールツールをインストールして、そこから実行します。

これを実行するとNugetの実行ファイルがプロジェクト内にロードされ、ビルド時にパッケージを読み込んでくれるようになります。

あとはAppharborへデプロイすればビルド完了となると思います。

参考までに、今回使用した.gitignoreを掲載。


*/packages/*
/packages/*
obj/
bin/
TestResults/
_ReSharper.*
*.csproj.user
*.resharper.user
*.resharper
*.suo
*.cache
*~
*.swp
*.resharper.user
*.rptproj.user
*.db
*.sdf
*.tmp

ASP.NET UpdatePanel内なのにPostBackが発生する

UpdatePanelで囲っている、もしくはTrigger指定しているのになんでPostBackするの、という時にはClientIDModeをチェックする。

ClientIDMode=Staticだと、コントロールのIDが一意に特定できず(ViewStateに保管されたIDと一致しない？)PostBackしてしまうことがあるようだ。なので、AutoIDなどにする。
特に、子要素を持つコントロール(ｘｘｘリスト、GridViewなど)は注意が必要。

マスターページなどを使っている場合IDにプレースフォルダのIDが付加されたりするのでClientIDMode=Staticを使いたくなる。なのでこの仕様はちときつい・・・

作業の流れで覚える Git コマンド

Gitのコマンドについて、大体の作業の流れに沿ってまとめました。GitHub想定。

○初期設定編

*ユーザー名/メールアドレスの設定

git config --global user.name "Suzuki Taro"

git config --global user.email taro@example.com

*エディタの変更

git config --global core.editor notepad

*改行コードの扱い

大体GitHub上にあがっているのは改行コードLFなので、Windowsの場合以下の設定をしておくとチェックアウト時LF - >CRLF、コミット時CRLF->LFの変換を自動で行ってくれる。

git config --global core.autocrlf true

Mac/Linuxの場合はCRLFが混じっていると困るので、チェックアウト時CRLFをLFに換えてくれる設定をしておくとよい。

git config --global core.autocrlf input

*プロキシ環境の場合
ユーザ認証なし
$git config --global http.proxy http://proxy.server.com:port

ユーザ認証あり
$git config --global http.proxy http://user:pass@proxy.server.com:port

設定結果の確認
$git config --get http.proxy


参考サイト：ssh over proxyでgithubをアクセスする（Windows）

○通常時編

1.ソースをとってくる(forkした後の自分のリポジトリから～というイメージ)

git clone git@xxxxxxxx.git

2.ソースの編集後、リポジトリに追加

git add . 

3.コミット

git commit -m "メッセージ"

4.リモートにアップロードするため、リモートを追加

git remote add リモート名(originなど) master

5.リモートに送信

git push リモート名 master

○初めてのpull Request編

1.通常時編と同様。リポジトリをフォーク＋クローン

2.ブランチを作成　※決してmasterで作業しない。

git checkout -b (ブランチ名)

ブランチ名はxxSpikeなどSpikeをつけたりdevelopとしたり・・・といろいろあるようだが、見たところ修正点がわかれば何でもいい感じだ

3.fork元のリポジトリを変更追尾用のupstreamとして登録しておく

git remote add upstream git://ｘｘｘｘｘｘ.git

4.ブランチで作業(git add / git commit)

5.fork元を更新し、元リポジトリで更新が行われていないか確認

git checkout master

git pull upstream master

マスターブランチに移動して、pullで更新するそのあと自分のブランチに戻り、差分確認。

git checkout myBranch

git diff master

横着する場合は、リモートのブランチと直接比較する方法もある。元リポジトリのmasterブランチと現在のブランチの差分を比較している。

git diff upstream/master

万が一変更が行われていた場合、rebaseなどを使用し対応。ここは細かい話になるため、その他の詳細記事を参照。

6.pull Request

元リポジトリの差分を取り込んでおり、自分の変更点はbranchにまとまっている！となれば、githubにpushし、その後pullRequestを行う(これは画面から行う)。

git push origin ブランチ名

※originはGitHubのリモート

事前にコミットまとめなさいよ、という話があるかもしれない。実際そうしたほうがいいが、マージをする際に取り込むブランチ上のコミットはまとめることができるので、そこまでするかなという気もする（タイプミスとかは確かにアレだが・・・）。

まとめる場合、rebaseを使用する。こちら を参考。

なにより、小さく速くやる、ということがpull Requestでは重要と思う。

○あるある編

*gitignoreを追加するのを忘れたので、直前の git add . を全部取り消したい

git rm -r --cached .

*git addでの変更内容を事前に確認したい

git status もしくは

git diff  --cached

※ファイルの一覧でいいんだよ！という場合は 

git diff --cached --name-only

--cachedってなんなの？という場合こちらを参考。

git diff の使い方がほんの少し理解できた

*コミットメッセージに誤字脱字。修正したい

git commit --amend -m "(新しいコミットメッセージ)"

git commit --amend で、単純にコミットの取り消しになる。

*コミット先を間違えた。取り消したい

git reset HEAD^

上記に引き続きとても分かりやすい記事があるのでこちらを参考。みんなHEADとかインデックスとか何言ってんの？という場合にもとても良いです。

git reset についてもまとめてみる

*削除したファイルがgit addで追加されない
git add -u
を実行

Scala Lift を Heroku で稼働させる

えらく苦労したが、ScalaのLiftをHeroku上で動かせた。

○前提インストール
  Scala (やたら重い気がするが気のせいか？)
  SBT  Scalaにおけるビルド/パッケージ管理ツール
  Lift   今回は下記のGitリポジトリに含んでいるのでダウンロードの必要はないが、一応

後はHerokuツールともちろんGit。Heroku自体へのGitを使用したデプロイの方法はいろいろと解説されているので、ここでは詳しく触れません。

WindowsではSSHキーの作成がめんどいと感じるかもしれませんが、GitをインストールすればGit Bashからssk-keygenを使用できるため、こちらでキー生成を行えばわざわざPuttyなどからやらなくて済みます。

Liftのスタートアップスクリプトはbashで書かれていてコマンドプロンプトからうまく動かなかったりするので、なにかコマンドを実行する際はGit Bashを使うことをお勧めします。


○方法
さっさといこう！ということでGitHubからcloneで。
  lift_basic_heroku

こちらのリポジトリをcloneして、あとはReadmeの通りに行けばHerokuへデプロイできると思います。

ソースコードのバージョン管理の考え方

ソースコードのバージョン管理については、GitやSubversionなどの様々なツールがある。最近導入の検討を行ったが、「そもそもどういう風にバージョン管理をしたいのか」という明確な戦略がないと、ツールの操作と手間に振り回されてしまうと感じた（振り回されたのだが・・・）。

なので、まずはバージョン管理の目的とその戦略についてまとめてみた。


＜バージョン管理の目的＞
バージョン管理の目的は２つあると思われる。

１．マイルストンの設置
　ある時点の安定した状態を記録しておき、いざというときにそこに戻れるようにする。また、そこからどのような作業が行われたのか、差分を確認できるようにする。リリース管理ともいえる。

２．分業の実施
　分業を実施するため、個々人（あるいはチーム）の作業エリアを別々のバージョンとし、最終的にマージを行う。

サウンドノベルのゲーム（かまいたちの夜etc）などをやったことがある人は、ゲームオーバーになった時どの章から再開するのか選べて便利だな、と思ったことはないだろうか(下図参照)。

これは立派なバージョン管理ではないか。①のマイルストンの管理ができていることで、ここまではうまくいっていたのにな～というところから再スタートできる。

ゲームでは分業することはあんまりないと思うが、仮に上記のようなゲームの攻略本を作るとしたら、「オマエはAルートで俺はBルート」のような形で担当を分け、最後にお互いのセーブデータをマージする・・・ということができたらいいだろう。

この時の「お互いのセーブデータ」がつまるところバージョンに当たり、②の目的で使っていることになる。

＜バージョン管理の戦略＞

では、どのような形でバージョン管理を行えばよいだろう。バージョン管理の手法としては、以下２つが考えられ、これはなにもソースコードの管理だけでなく企業の予算立案などでも使われている考え方である。

１．スナップショット型

ある時点での作業内容を保管しておくことで、バージョン管理を行うタイプである。これは、先ほどのサウンドノベル型に近い。

登場するバージョンは基本的に　作業バージョン・リリースバージョンの２種類である。作業バージョンでの作業がひと段落したら、その時の状態をリリースバージョンとして保管するという形式である。

○メリット

作業する場所が一つなので、作業はしやすい。複数機能を開発している場合、いい意味でも悪い意味でも、既存への影響を早めに知ることができる（同じ場で作業しているので）。

×デメリット

性質上ある機能の分だけ切り出すということは難しい。そのため、複数の機能が同時並行的に開発されていて、できた機能は一刻も早くリリースしたい・・・というような環境では不向き。

上記の例だと、機能Bの開発終了段階ではまだ機能Aの開発が終わっていないため、単純に作業バージョンをコピーするのでなく、安定板であるVer1に対し機能Bの変更のみ反映させるといった作業が必要になる。

→大きい機能でも、リリース可能な状態をキープする戦略があるとよいか。

上記点を考えると、開発する機能・納期が明確に決まっているような案件の場合、または特定機能を全員で開発していくような場合に向いていると思われる。

２．ローリング型

作業を始める前に、その作業を行うための箱を作る方式。

○メリット

他の開発の影響を気にすることなく作業できる。それと、万が一やっぱりこの機能やめた、という場合でも作業用のバージョンを消すだけで済む。

×デメリット

他機能がリリースされた際、そのリリース内容を取り込みながら開発を行っていく必要がある。そのため、長期にわたる機能開発の場合取り込み作業が大変。また、他機能の開発で自分の機能に大きく影響を与える変更があった場合、その検知が遅れることになる。

→機能開発のサイクルを一定にする工夫があると運用しやすいか（長短入り乱れると長の開発が割を食う）

上記点を考えると、不特定多数で作業する場合やリリースする機能は作りながら決めるぜ、というような場合に向いている。

以上が、バージョン管理の目的とその戦略についてである。ツールを選ぶ前にこの辺りをよく考えておくと、どんなツールでどういう風に管理するのがいいのか見通しが立てやすくなると思う。

AppHarbor と GitHub の連動設定(ServiceHook)

GitHubにpushしたらAppharborにも自動的にpushしたい！という場合ServiceHookの機能を使用する。その設定方法について解説します。

まず、GitHub側のリポジトリのAdminからServiceHookを選択

Appharborの設定は以下のようになっている。

ここで、Application SlugとTokenは、Appharbor上の以下の設定を入れる。

・Application Slug

 Appharbor上のアプリケーション名

 (カンマ区切りと言うことなので他のものでもいいのかもしれない)

・Token

BUILD URLの、authorizationの値を設定する。BUILD URLをクリックするとクリップボードに値がコピーされるので、それをテキストエディタなどに貼り付けてauthorizationの値をTokenに設定する

あとはActiveにチェック。

こうすることで、GitHubにpushするとAppharborにも反映されるようになる(ブランチがmaster以外の場合どうなるの？という点はちょっと未確認)。