技術屋日和

twitter用に作ってたスクリプトがBASIC認証廃止でつかえなくなったので、OAuthに対応させようとしたらかなり四苦八苦したので、その時のまとめ。

基本の流れ

まずは、流れ。

1. 接続したいサービスに登録して（今回はtiwitter）Consumer Token（利用者IDみたいなもの）とConsumer Secret（利用者を確認するための共通鍵）を発行してもらう。
2. 発行してもらったConsumer Tokenを使って利用者認証をして、Request Token（リクエスト用の一時トークン）とRequest Secret（Request Tokenを確認するための共通鍵）を発行してもらう。
3. Request Tokenを使ってユーザをサービスに誘導し、接続を許可して貰う。（このとき、クライアントアプリであればPINコード（認証コード）が発行される）
4. 発行されたPINコードとRequest Tokenを使ってAccess Token（ユーザ専用の利用者IDのようなもの）とAccess Secretを発行してもらう（Access TokenとConsumer Tokenが正しいかを確認するための共通鍵）
5. あとは、Access Tokenを使ってAPIを呼び出す。

・・・ってここまで書いた時点でかなりめんどいんだけど、実際めんどかった・・・。

Permalink | コメント(0) | トラックバック(0) | 21:28

サービス登録

ここは簡単で、サービスに必要事項を書いて申請すればConsumer TokenとConsumer Secretをあっさり発行してくれる。

Permalink | コメント(0) | トラックバック(0) | 21:28

利用者認証

ここからが面倒、というか、ここの流れを理解出来ればあとはコレの応用。

基本的には、以下のものをリクエスト認証用URLに投げてRequest TokenとRequest Secretを貰うんだけど、これがまためんどい。

ここから何をするにも必要なもの。基本的にはリクエストのクエリとしてくっつける。

1. oauth_token（ここではConsumer Token）
2. oauth_timestamp（UNIX時間のタイムスタンプ）
3. oauth_nonce（ランダム生成した文字列）
4. oauth_signature_method（署名の生成方式。twitterだとHMAC-SHA1）
5. oauth_version（基本的に1.0）
6. oauth_signature（共通鍵を使ったリクエストの署名）

で、oauth_sinatureを作るために以下の手順を踏む必要がある。

1. HTTPメソッド名
2. 宛先URL
3. 上記のなかからoauth_signatureを除いたクエリ文字列（他に必要なパラメータがあればそれも含める）

上記３つをURLエンコードした後"&"で接続した文字列を、oauth_signature_methodで指定した方式で必要な共通鍵を&で連結したもの（ここではConsumer Secert+"&"）をキーに署名を取得、base64でエンコードする。これがoauth_signatureになる。

で、めでたくクエリが完成したらリクエスト用URLにクエリをくっつけて投げる。

上手く行けば、Request TokenとRequest Secretが帰ってくる。

署名が変だったり、typoしてたりすると認証失敗したよーってメッセージが帰ってくるので、その時はやり直し。

Permalink | コメント(0) | トラックバック(0) | 21:28

ユーザーに許可して貰う

リクエスト認証用URLにRequest TokenをパラメータにくっつけたURLをブラウザで開いてもらうと、接続先サービスにログインして（既にログインしている場合はそのまま）あんたのアカウント使って接続するけど、許可していい？って聞かれるので、許可する。

許可すると（クライアントアプリの場合）PINコード（以下、ピン子）が表示されるので、こいつを入力してもらう。

Permalink | コメント(0) | トラックバック(0) | 21:28

ユーザー許可認証

もらったピン子を使ってAccess TokenとAccess Secretを取得する。

方法は利用者認証の時と大体一緒なんだけど、以下の点が違う。

1. oauth_tokenはRequest Token
2. oauth_verifierパラメータを追加（値はピン子）
3. oauth_sinatureを作成する時の共通鍵はConsumer SecretとRequest Secretを"&"で連結した文字列

上手く行けばAccess TokenとAccess Secretが帰ってくる。

こいつがあれば後はやり放題。

Permalink | コメント(0) | トラックバック(0) | 21:28

API呼び出し

API呼び出しするときも利用者認証と同じ方法で署名を付ける必要がある。

違う点は、

1. oauth_tokenはConsumer TokenとAccess Tokenを"&"で連結した文字列（だったはず・・・Access Tokenだけでよかったかも知れない）
2. oauth_signatureを作成するときの共通鍵はConsumer SecretとAccess Secret
3. POSTするメッセージも署名を作るときのパラメータに含める

と、ざっと書いただけでこんだけ。はっきり言って既存のライブラリがあるならそれを使った方が全然楽だと思います・・・（とくに、HMAC-SHA1とランダム文字列作る辺り）

情報セキュリティスペシャリスト（笑）的には抑えておきたかったのでDIYしてみたけど、丸一日使ってしまった・・・。

Permalink | コメント(0) | トラックバック(0) | 21:28

http://d.hatena.ne.jp/gothedistance/20090723/1248331426

この記事を読んで経営も会計も素人だけど考えてみた事を思いのままに書き殴ってみる。突っ込み歓迎。

人を売る商売

上記のブコメにも書いたけど、人月商売を辞められない原因はSIerの会計制度（といか売上計算法）にあると思ってます。

たとえば、某SIer（オイラが知ってる某大手SIer）は情報サービスの売上をこんな感じで計算しています。

人月単価×投入期間

これって要は、「人が商品です」って言ってる様なもの。

口では「サービスを提供します！」とか言ってるけど、結局の所会計上は「人を何人月売れば売上達成です！」となってる。

この計算方法だと、生産性があがる=値引きしている、と同じ事になるので、売り上げに直結しない。

（生産性を上げると逆に干されるのはこの辺に原因があると思ってます。）

経営者がどんなきれい事並べようと、現場がどんなに生産性をあげようと、中間層は売上で評価されちゃうんで、どうしても稼働率至上主義になっちゃう。

じゃあどうしよう。

１つの方法として「サービス」を提供しているのであれば、それを売り上げの単位として使えば良いんじゃないか。

システム開発なら「実装した機能」（的なもの）を単位として、

　納品した機能数×機能単価

これを売り上げとすれば生産性が上がれば上がるほど売り上げも上がる、お客さんもハッピーのWin-Win関係になれる筈。

もちろん簡単じゃない。

制度というのは要するにシステム。皆さんもご存じの通り、システムを移行するというのは大きいシステムほど移行時の負荷が大きい。「大手」がやろうとするならば相当な痛み（それこそアイデンティティを失うほどの）が伴うでしょう。

「機能単位」と言ったってその粒度も様々だろうし、単価設定をどうするのかとか、開発ならともかく保守・運用はどうするんだとか、下手すると客の方に「良くわかんないから人月でやって」と言われる可能性だってある。（というか、実際にやろうとして言われた事があります・・・）

でも、これを乗り越えることが出来れば先の暗い人月商売から脱却することが出来るんじゃないでしょうか。

中小こそチャンス？

ちょっと本題からそれますが、いまは中小企業こそチャンスだと思っています。

なぜなら、上でも書いたとおり制度移行のインパクトは会社の規模にあわせて小さくなりますし、アジャイル開発も小規模では適用事例もぼちぼちと出てきています。さらには、クラウドについてはインフラ構築・運用を丸投げできる（ちょっと語弊がありますが・・・）ので大手がやるようなトータルでの提案も可能になってくるのではないでしょうか。

考える技術・書く技術

読書感想文

「書く技術」が「核技術」と変換されるのはご愛敬。

４年くらい積み本になっていたけど、ようやく読了。

正直、文章を書いていると何を書いて良いか分からなくなるときが結構多いので、この本で得た知識は結構重宝しそう。

具体的には、

• 文章の書き出しは、状況-複雑化-疑問で読み手を引きつけること。
• 疑問とそれに対する回答をはっきりとさせること。
• 回答にはそれぞれ理由付けをすること。

の３点か。（この「だいたい３点にまとめる」っていうのもあったな）

で、この中でも書き出しの話がかなり役に立った。というのは、言いたい事はあるんだけどどう書き出したら良いか分からなくなるときというのが結構あって、そういうときは「状況（相手が分かっていること）」と「複雑化（疑問の引き金）」を書く事で文書に自然と入り込める、ということ。これは今後も活用していきたいなぁ。

疑問とそれに対する回答をはっきりさせるというのは、実際何となく文章を書いていると，だんだん自分が何を言いたかったのか、という事がある。で、そういうときは疑問と回答を意識することで、文章に芯が入ってくる、という事と解釈。

理由付けは言わずもがな。根拠はどうあれ、なぜ？に答えられない文章は納得感がない。

文書書きが苦手なおいらには非常に助かる一冊でした。

Permalink | コメント(0) | トラックバック(0) | 21:52

はてスタ。

今更だけど、これはすばらしい仕組みだとしみじみ思う。特にブログの方でもらうのはブコメでもらうのとはまた違う嬉しさがある。

これをもらうと随分テンション上がってまたなんか書こうって気分になる。やっぱ自分の考えを肯定してもらうってのは良い気分だよなぁ。単なる相づちみたいなモノだとしても。

また、手軽さも良い。やる事は、『うん』と思ったら☆をクリック。それだけ。手軽さってのはアクションを起こすのには重要なファクターだしね。

Permalink | コメント(0) | トラックバック(0) | 23:39

成功する要求仕様　失敗する要求仕様。

読書感想文

結局のところは『デスマーチ』でも言われている「トリアージ」に限る。全部の仕様変更を受け入れる訳にはいかないが（デスマーチ直行コース）、全部の仕様変更をはねつける訳にもいかない（誰が得するの？このシステム？）。その中間点で落としどころを見つける。そのための方法論としての、要求リスト作成とトリアージのプロセス。

その中でも「ちょうど十分（Just Enough.）」な状態に持って行く方法論はネゴシエーションスキルとしても通用する部分があると思う・・・というか、ネゴシエーションそのものなんじゃないか？お互いの利益を調整し、「出来る・出来ない」、「絶対に必要」と言った極論を廃して「○○%の確率で成功できる」「この機能が含まれていれば○○円の利益になる」という数字を使った交渉によって最適解を模索する。

著者はアジャイルプロセスには懐疑的だけど、アジャイルでもSCRUMのフィーチャリストとか、XPのTODOリストで要求を管理してるはず。別に要求を管理していない訳じゃ無い。結局、どんな方法論でも要求管理は大事ってこと。

付録の要求に点数をつけるやつは、実際のレビュー等でも使えそう、というか使ってみよう。誤字脱字とかばっかり指摘することが多いけど、それってあんまり重要じゃない。仕様の不備とか矛盾とかの方が重要。

Permalink | コメント(0) | トラックバック(0) | 22:08