Now Playing Tracks

i11matic:

磯部光毅 新連載「手書きの戦略論。」複雑化する『戦略論』を整理しよう | 宣伝会議 2014年7月号

この連載では、これからコミュニケーション戦略の整理と再編集にチャレンジしていきます。そこでお伝えしたいのは、「コミュニケーション戦略のベースとなる戦略理論は7つある。そして、その基本さえわかっていれば踊らされないで済むし、プランニングへのヒントも見えてくる」ということ。


1. ポジショニング論
戦略とは、競合との相対的な違いを決めることだという考え方。いわゆるマーケティング理論と捉えてもらってOK。十字の二軸(マトリクスチャート)を描いて、自ブランドと他ブランドを相対的に位置づける、あれです。

2. ブランド論
戦略とは、その商品のらしさを規定し、守ることだ、という考え方。アイデンティティを決めて、そこからぶれずに伝えていくことを大切にします。

3. アカウントプランニング論
グローバルエージェンシーで一般的に用いられている方法論。戦略とは、ブランドとターゲットの隠れた心理的つながりを発見することで、それを広告制作に生かすプロセスを大切にする考え方です。「インサイト」という言葉は、この戦略論から生まれています。

4. ダイレクト論
戦略とは、ターゲットからの直接の反応(購買行動や問い合わせなど)を獲得することだ、という考え方。すぐにリアルな反応がなければ意味がないという捉え方。ダイレクトメールで発展し、ダイレクト型CMにつながり、今はネット広告の戦略に多大な影響を与えている理論です。

5. IMC論
戦略とは、顧客の購買プロセスのすべての接点で、伝える情報を統合的に設計することだ、という考え方。「カスタマージャーニー」「360°」「タッチポイント」などの言葉は、この理論が背景にあります。

6. エンゲージメント論
戦略とは、お客さんの参加や行動をいかに促すかだ、という考え方。関与が下がり、物的差別化が難しくなり、情報過多になり、財布のひもが締まっている現代では、お客さん側をその気にさせて、参加してもらったり、行動してもらわないと響かない。そうした考え方が背景にあります。

7. WOM(クチコミ)論
戦略とは、企業発信でなく、クチコミによって人づてに情報が広がっていく仕組みを設計することだ、という考え方。話題にしてもらう、情報波及を起こすためにはどうすればいいかを中心に考えます。

Roslynのコードガイドライン

  • 現地の DateTime 値は使用しないで、常に、協定世界時 (UTC) を使用する。
  • 値型の Parse メソッド (int.Parse など) の使用は避け、int.TryParse を使用する。
  • 作成するエンティティ クラスはすべて等値演算をサポートする。つまり、エンティティ クラスでは、Equals と GetHashCode をオーバーライドし、== 演算子、!= 演算子、および IEquatable<T> インターフェイスを実装する。

マイクロソフトの次世代コンパイラ プロジェクトによるコードの強化方法http://msdn.microsoft.com/ja-jp/magazine/dn296510.aspx

基本的に400番台は見る側が悪い。500番台はサーバーが悪い。

■403
一般の人は見ちゃダメよ、っていうページにアクセスした場合のエラー。別名「君には絶対見せない!」

■404
そんなページないってば、っていうアドレスにアクセスした場合のエラー。別名「何探してんの?」

■500
おいおい、プログラム間違ってんじゃねぇの? っていうエラー。たいていはCGIスクリプトの設定ミス。

■503
只今大変混みあってまぁ~~す、の状態。サーバメンテ中や、中国からのDOS攻撃の際に出ることも。


他にメジャーなのは以下。

■400
アドレスに変な文字いれるんじゃねぇボケぇ!

■401
パスワードが違うんじゃボケぇ!
403エラー 404エラー 500エラー 503エラー それぞれの意味を教えてください。ま… - Yahoo!知恵袋 (via petapeta)

のっけから「あれれれれ?」って感じだった。GitHubでもたらされたとされている「変革」が、どれも(GitHub登場前からの)ごく当たり前のプラクティスに見えたからだ。おかしな変数名に対してレビューアが対案を提示するなんて、あたりまえじゃないか。もし以前はそれがあたりまえでない世界に住んでいたのだとしたら、その職場の文化か、先輩プログラマが悪い。GitHubの導入で結果的に改善されたのは良かったけど、GitHubを導入しないと解決しない問題ではないよなぁ。

他のプレゼンでもちょくちょく感じたけど、その変革がGitHubによってもたらされたのか、そうでないのかがちゃんと分析できてない話が少なくなかったと思う*2。個人的な考えでは、GitHubがもたらしたのはスピードアップによる効率化が基本で、その「量的な変化」がどこかで「質的な変化」をもたらすのがポイントだ。もともと質に問題があった開発プロセスがGitHubによって改善したように見えるのは、本当にGitHub関係してるかどうか気にしたほうがいいんじゃないか。一方、CIサービスやデプロイツールと自動的に連携するような最近の流れは、量のフェーズを抜きにいきなり質の変化をもたらしてる気がする。これはわくわくするし「いいぞもっとやれ」と思う。

GitHub Kaigiへ行ってきた - ただのにっき(2014-06-01)

SubversionのコミットをVisual Studio Online (TFS)へ

imageJenkins + SubversionでAzureへデプロイしているプロセスのデプロイ部分をTFSに任せてみたいと思う。今回はその第1弾でSubversionのコミット内容をTFSにも反映させるのを実現します。

最終的なミッションはこの2つになります。

  1. Subversion から自動でTFSにコミット & ビルド
  2. TFS → Azureへデプロイ & テスト

今回は 1. の部分です

指定のフォルダーをサーバーのローカルフォルダーに紐付けたりプロジェクトを0から作ったりと色々と事前準備を全てコンソールから出来る整備をしようかと思ったけど面倒そう、と言うか欲しい情報が判りやすい形で転がってない。

この辺はJenkinsとかと比べて残念に思いつつ今回の 1. のSubversion → TFS辺りは将来捨てる可能性が高い部分なのでガッツリと手を抜きます。

そんな訳でプロジェクト作成してローカルフォルダに最新ファイルが落としてある状態までを手動操作で完了させます。

準備が出来たら対象のフォルダーに対して以下の操作テストを実行

  1. 変更
  2. 追加
  3. 削除
  4. SuvbersionとTFSのワークスペースを同一の場所で実行

1.変更

tf checkin /noprompt

変更は簡単で上記のコマンドをVisualStudio上でローカルにマッピングした場所に行うだけでコミット(checkin)は出来た。

2.追加

tf add

ファイル増加も簡単

3.削除(消失状態からの昇格)

tf deleteが本来の削除ですが実は自分の要求は「MissingになっているのをDeleteに昇格させる」事。tf statusできちんと消失は検知できているので文字列を見てtf deleteに渡せばいいだけど、そのもの機能は地味に見当たらない。仕方ないので文字列を見てtf deleteを呼ぶコードで対応。

最終的なPowershellのコード

tf add
$tfStatus = tf status
for ($i=1; $i -le $tfStatus.Length ; $i++) {
    if ( ($tfStatus[$i] -ne $null) -And ($tfStatus[$i].Length -ge 2) ) {
        if ( $tfStatus[$i].IndexOf("削除") -ge 0 ) {
            $split = $tfStatus[$i].split()
            tf delete $split[$split.Length-1]
        }
    }
}
tf checkin /noprompt

上記のコードをSubversionでファイルが更新される毎に実行する様に設定します。ここは当然ですがJenkinsでSubversionのトリガーで実行となります。

To Tumblr, Love Pixel Union