twitterbotのAWS移行計画

ご無沙汰してます。

最近はもうFF11三昧で生活が大分アレな感じに。

で、もうFFだらけなので時間がないような気もするんですが、

タイトルのような事を考えてます。

現在自分はGAEを使って、L_H_A_botなるものを作って、

公開？してたりするんですけど、

どうもtwitterとGAEの相性が悪いらしい。

大元のライフハッカーのアカウントはつぶやいてるのに、

botはつぶやかないことがしばしば。

で、GAEjaのメーリスとか見てると、みんな同じような症状になったりしてるらしい。

（特にポスト関連がひどいらしい？）

という訳で、AWSから1円クラウドが大分前に出て気になっていたので、

移行しようかなーと思ったりしてます。

まぁbotはもう結構諦めてて、AWSを触りたいだけなんですけどね。

MacBookAir買っちゃってAcerのノートが鯖機になるかもしれないとか

そんなことを妄想したりもするけど、まぁそれはそれ別の話ってことで。

ちゃんと動き出したらやり方とか書けたらいいなーと思ってます。

Agileってなんだろうな？

今日は現場の人間の送別会でフグを食べに行ってきました。
まさかの5000円ポッキリで刺・鍋・唐のフルコース。
あ。あとヒレ酒もね。

まぁそれはそれで大満足だったのですが、
飲みの席でまさかのアジャイルトークになり、
ちょこっと色々疑問に思ったのでエントリ

本題に入る前にアジャイルとは？
オレの認識だとアジャイル宣言ってのがあって、
基本はその宣言に則りつつ、上手くソフトウェアを作っていこうよ
というものだと思ってます。

アジャイル宣言

• プロセスやツールよりも個人や相互作用
• 分かりやすいドキュメントよりも動くソフトウェア
• 契約上の駆け引きよりも顧客とのコラボレーション
• 計画を硬直的に守るよりも変化に対応する

以上は、このページからの引用です。


で、今回の飲みで話題になったのは、
成果物作成後のドキュメントに関して。
実際にアジャイルを用いてシステムを作成した後に、
そのシステムの品質をチェックする立場の人から聞いた話です。
その人曰く、

"確かに、アジャイルはすぐに仕様を変更したり、
業務の現場の変化に対応出来るかもしれないけれども、システム作成後の
保守をするにあたって、ドキュメントがグダグダだから、
これならウォーターフォールのがいいんじゃね？”

とのことでした。
自分はまだまだアジャイルをちゃんと勉強した訳ではない、
かつ、実際にそのシステムの開発・品質チェックどちらにも
携わっていなかったので、ちゃんとアジャイル手法が適用されていたのかどうか
わかりませんが、この疑問に対して上手く解答することはできませんでした。

というわけで、疑問に思ったのは、

開発→本社情シス・外部のソフトウェアハウス
保守→本社保守チーム

と開発を行うチームと保守を行うチームが別々になっていたときに、
仕様の引継ぎ（ドキュメント）などの問題はどのようにクリアしていくのか？

ということです。

アジャイルはこういったケースに対して解答を持っているのでしょうか？
それともそもそもそういった開発体制ではアジャイルは適用できないのでしょうか？

オレもこれから本を読んでみるつもりですが、
もしわかりやすい解答を持っている人がいたら教えてください。

Google的思考書評

iPadからDuetを使って更新の巻
ネタがあれば寝ながら更新できないこともないけど…
レイアウトの最終確認とか推敲がしにくいから
ちょっとキツイかなー。
まぁ使えないことはないってレベル
大分レイアウトがアレっぽいので、
後で修正しよう。
今日のネタは以前読んだGoogle的思考の読書メモです。
断片的だけど結構上手くキーワード拾えてるんじゃないかなーとか思う。
ちょっと長すぎるけど…
では、はじまりはじまりー

Google的思考

まえがきから
・主導権を握っているのは消費者のほうである。
・マスマーケットはもはや存在しない。今あるのは、多数のニッチである。
・流通ルート、人員、製品、さらには知的財産の所有は、
もはや成功の鍵ではない。肝心なのはオープンであることだ。


プラットフォームの重要性
プラットフォームを築くこと？
オープンにすることで好循環を築き上げる

コミュニティ
コミュニティは企業が作るモノではない。
コミュニティは企業の外にすでに存在している。
企業はそのコミュニティの場を提供してやればよい。
コミュニティは企業のモノではない。
コミュニティはコミュニティのモノである。

エレガントな秩序を築き上げること

・モノはお荷物
Amazonはモノを扱っているのではない。
＊モノを売買することによって顧客の嗜好情報を蓄積している。
Amazonはモノの会社ではなく知識の会社
Amazonはモノを扱うことと引き換えに知識を蓄えている

・仲介業の危機
インターネットは非効率を排除していく

・無料のビジネスモデル

Zillow.com創設者リッチ・バートンの言葉
「インターネットは無料サービスのための一大競技場だ。
無料で提供できる商品に価格をつけたりすれば、
自らの首を絞めることになるだろう。」

グーグルが行っているのは組織化と知識のビジネスモデル
グーグルの主力ビジネスは検索サービスをはじめとする、
各種Webサービスだがそこからは一切収入を得ていない。
＊グーグルの（現在の）収入源はサービスを
使用するユーザーに対しての的確な広告である。

・自分のビジネスがなんであるかを明確にする。
グーグルは自身がコンテンツビジネスモデルではないことを理解していた。
ヤフー、AOLは自身のビジネスモデルを見誤った
自問してみよう。
あなたの企業の核は知識か？データか？
コミュニティか？プラットフォームか？ネットワーク？
あなたの価値はどこにあるだろう？利益はどこから入ってくるだろう？
金銭は必ずしもいつも同じ形でもたらされるわけではないことを覚えておこう。

Chapter7　新しい心構え
・統制と信頼の関係
「消費者に主導権を与え、使わせる」

デビッド・ワインバーガーの言葉
「統制と信頼は反比例の関係にある」
自分が主導権を握れば握るほど相手からの信頼は薄れ、
相手に主導権を与えれば与えるほど信頼は深まるということ。
「自分をさらけ出し、主導権を渡せば失った信頼を取り戻せるだろう」

・民衆を信頼する
「潤沢さが商品の質を高める」

信頼を核にしたビジネス

彼は自分が信頼している仲間たちが編集したインターネットの中を巡っている。
同じ視点を持った者たちの間に、信頼のウェブが構築されているのだ。

多くの企業は、消費者への信頼ではなく、規則や禁止事項を基盤に機能している。
やってはいけないことを客に提示し、それを破った者には罰則を科す。
しかしグーグルは、我々への信頼を基盤に帝国を築き上げたのだ。

・耳を傾ける


Chapter8　新しい倫理
・うまく失敗する
失敗は本人次第で貴重な体験となり得る。
最悪の過ちは、失敗などしなかったように振る舞うことだ。
そんなことをしたら、周囲の期待が無駄に高まり、
次に失敗したときには取り返しがつかなくなるのだ。

しかし今日、インターネット上では過程が商品になる。

・人生は開発途上
重要なのは失敗をしたことではなく、それにどう対応するかなのだ。

・正直な態度
正直さと率直さを基盤にした新たなメディア世代は、身も蓋もない真実を求めている。
グーグルがある今、情報を統制したり、
昨日の発言や今日の失敗をもみ消したりするのは不可能になってきている。
真実はあっという間に広がるのだ。

・透明性
グーグルも秘密が多いから批判もしょうがないよね。

・協力体制

・邪悪なことはしない
グーグルに対する疑問と著者の姿勢。
とりあえず今んとこ大丈夫じゃね？という見解

ハークの法則
「相互作用が拡大すれば、邪悪な行為の代償は恩恵を上回る」

Chapter9　新しいスピード
・即座に出てくる答え

・人生はライブ
グーグルは記事の完成度が高いほうが検索結果の上位に来るため速報性に欠ける。
速報性は新たなビジネスチャンスとなるかもしれない。
→最近はtwitterの検索結果が表示される。

・モブ（群集）

Chapter10　新しい義務
・ドル箱商品に注意
成功は時に人の目を曇らせ、失敗の可能性を見過ごさせる。
また、失敗に対する恐怖心は、人を成功から遠ざける。

人はお金が入ってくるうちは、変化や厳しい決断や改革の必要性が目に入らない。

・革新の促進と保護
グーグルの教訓は明確だ。革新をビジネスにするのだ。

・シンプルに徹する
デザインは、単なる美観の問題ではない。デザインは美学なのだ。

・邪魔をしない

■グーグルが世界を支配したら
物事を違う見方で見て、グーグル時代における根本的な変化を理解し、
難問について考え、新しいチャンスをつかみ、
考え直し、想像し直し、作り直すということだ。
それが、グーグルに倣うということだ。

onConnectの挙動超概略

最近全然ネタをメモってないっす・・・
とりあえず昔（と言っても半年位前）に書いたネタで
イケそうな奴をちょこちょこっと公開します。
今回はChromeExtensionsネタですが、
Google先生は変化のスピードが尋常じゃないので、
もしかしたら今はもう通用しないかもしれません。
ネタメモをほぼそのままコピペなので始まりが唐突です。
書いた当時はChromeExtensionsを触っていて、
contents.jsとbackground.html間のやりとりを
追いかけた時のメモです。

onConnectの挙動超概略


まずはコンテントスクリプトから

var port = chrome.extension.connect({name:"test"});

でバックグラウンドページに対してラブコールを送る
（ちなみにここで引数として渡してるname:"test"で
portの名前が決まる。今回のコードでは"test"になる。）

バックグラウンドページは

chrome.extension.onConnect.addListener(function(port) {});

この関数がコンテントスクリプトからのラブコールを受け取る受け口を用意する。
ラブコールを受け取る受け口の中でさらに

port.onMessage.addListener(function(msg){});

を宣言しておく。これが実際にラブコールの応酬をやり取りする関数になる。

全体の流れとしては

コンテントスクリプトでonConnectしてバックグラウンドページに対しての道を開ける。

道が開いたらコンテントスクリプトからport.postMessge({key:"value"});
で値を送信する。コンテントスクリプトから値が送信されたら、
バックグラウンドページは
onConnect.addListenerの中で宣言している
port.onMessageでコンテントスクリプトのpostMessageを受け取る。
んでバックグラウンドでやりたい処理（まぁ基本的にはXHR的な処理だと思うけど）
ゴニョゴニョやったらその結果をport.postMessage({key:"value"});
でコンテントスクリプトに返してあげる。
んでコンテントスクリプト側での
port.onMessage.addListener
で送信されたデータを受け取る。
もらったデータを受け取ってコンテントスクリプト内で
やりたいことをゴニョゴニョやるって寸法ですね。


最初はconsole.logの追い方がわからなかったのもあるんですが、
個人的にはコンテントスクリプト側もバックグラウンド側も
送受信に使う関数名が一緒なのがちょっと理解に時間を要した原因かも。
だからといって変えられる訳でもないんですけど。


とりあえず冒頭で紹介した、動きの追い方を把握すれば難なく理解できると思います。
console.logの嵐でね！

BlogWriterからテスト

タイトル通りなんですが、何も書かないのもあれなので近況でも。

とりあえず、今携わってる案件は無事に担当機能の作成を終え今日でおしまいっす。
そして明日からしばらく静岡に行くことになるようです。

ajn#10のまとめは元気があったらそのうちやります。

そんな感じ

漫画を読むならi文庫HDよりComicGlass！！

お久しぶりです。大分更新に間隔が空いてしまいました。
今回はiPadのおはなしです。（output的な内容じゃない・・・

昨日までずーっと漫画を読むときはi文庫HDを使ってました。
今までは特に不満を感じてないつもり、
あるいは感じていてもそんなに大きいモノではなかったのですが、
この連休で続き物の漫画を読むときに色々と不満が爆発しました。

下の方は個人的なi文庫HDへのdisだらけなので、
先に結論からいうと

①ComicGlassはタップ操作をカスタマイズできるから
   ページ送りやメニュー表示などが自分の思い通りにできるので便利
   
②ComicGlassは本棚の概念がないのでファイルを開くのが楽

③ComicGlassは外部フォルダをデフォルトで見に行ってくれるので、
   iFunBoxからの転送もやりやすい。

以上3点の理由からオレはiPadの漫画リーダーには
現時点ではComicGlassをオススメします。

というわけで、ここからは詳細な不満や要望です。
まずはi文庫HDへの不満点を述べつつ、
ComicGlassへの賛辞を述べていきます。


不満点①　タップ操作のカスタマイズが出来ない！

i文庫HDだとページ送りをするにはスワイプするか、
画面左端をシングルタップするかなのですが、
これをカスタマイズすることが出来ないのです。
多分通常右利きの人だったら画面右端シングルタップで
ページ送りが出来たほうが使いやすいですよね？
（オレはComicGlassで試してみた結果こっちのが
断然使いやすかったでした。）
あとはカスタマイズが出来ない故に
メニューが不用意なタップで出て来ないように
制御したりも出来ません。
ComicGlassは結構自由にタップ操作をカスタマイズできるので、
右利きだろうが左利きだろうがなんでもこい。
欲をいえばトリプルタップも設定出来れば更に神だった。


不満点②　ページ送りのスワイプの動作が大げさじゃないと次のページにいけない。

オレは基本的に漫画を読むときは横向きで使う人なのですが、
i文庫HDは画面半分位スワイプしないと次のページにいかないんですよね。
その点ComicGlassはかなり少ない量のスワイプで次のページへいけます。


不満点③　本を読むときにわざわざ本棚に登録しないとイケない。

ビジュアル的な観点からすれば確かに本棚はキレイなのかもしれませんが、
大量に本を読もうとするとなると、ハッキリいって本棚登録は
邪魔な動作以外のなにものでもありません。
本のファイルを開く時はファイルから直接開けるのですが、
（それでもわざわざ本棚に登録してくるかどうか聞いてくるのが煩わしいですが）
本と閉じたときに戻る画面が本棚になると、
次の巻へ行こうとしたときに本棚からわざわざファイルがある
フォルダへ移動しなければなりません。
上の結論でも書いたようにComicGlassには本棚の概念がないので、
次のファイルへ行くのが明らかにi文庫HDより楽


不満点④　ページが最後に到達しても自動で本をとじてくれない

これはComicGlassにも言えることなのですが、
その本の最終ページに到達して、なおページ送りの
動作をした場合は本を閉じて欲しいです。
もしくは設定でそういう設定を選べるようにして欲しいです。
漫画を読んでる時なんて最後のページに到達したら、
滅多にページ戻しなんてしないでしょう？
（オレの偏見かもしれませんが）


以上色々ツラツラと述べましたが、
ページ送りのアニメーションに関してはi文庫HDの圧勝です。
コレはもうグウの音も出ません。
ただ、オレの場合はページ送りのアニメーションよりも読書中の操作性が
なによりも重要だったので、今後のiPadのメイン漫画リーダーは
ComicGlassを使っていこうかなと思ってます。
勿論i文庫HDにしろComicGlassにしろまだまだアップデートは
すると思うので、その都度チェックしていきたいとは思いますが。

Pythonチュートリアル一人読書会 vol.3

■第5章 データ構造

リストについて

リストオブジェクトが持ってるメソッドの紹介

リストを使って簡単にStackとQueueを実現できるよ。

Stack

→append()で要素を追加して引数なしのpop()で要素を取り出せばおｋ

Queue

→append()で要素を追加して引数'0'のpop(0)で要素を取り出せばおｋ

リストの内包表記

filter(func, seq)

→ seq内のすべての要素に対してfuncを実行し、

実行した結果がtrueとなるような値のリストを返却します。

map(func, seq)

→ seq内のすべての要素に対してfuncを実行し、

実行した結果の戻り値からなるリストを返却する

reduce(func, seq)

→ 引数を二つとるfuncに対して、seqの先頭から処理を実行していく。

最初にseqの先頭の二つの要素に対してfuncを実行し、

以降は実行した結果と、次の要素を用いてfuncを実行する。

ex)1から10までの総和を求める場合

def add(x,y): return x+y

[1,2,3,4,5,6,7,8,9,10]

1+2=3→3+3=6→6+4=10→10+5=15...45+10=55

seqの要素がひとつしかない場合はその値自体が返却される。

空の場合例外投げます

a**2でaの二乗になる

→strには使えない

タプルとシーケンス

タプルは常に丸括弧で囲われるよ

タプルは変更不可だよ

（スライスと連結を使えば変更みたいなことはできるけど）

参考：

タプルの分かりやすい説明

集合やべぇ

diff取れるとかすげぇ

辞書型

keyにタプルを使えるよ

keyの存在を調べるにはhas_key()

すべてのkeyのリストを取得するならkeys()

iteritems()

→キーとそれに対応する値を同時に取り出せる

enumerate()

→要素のインデクスと要素を同時に取り出せる

比較演算子の優先順位

"and", "or", "not" などは比較演算子より優先順位が低い

式の内部で代入は行えませんよ

→=と==のミスタイプを防止するため

str1,str2,str3 = '','Trondheim','Hammer Dance'

not_null = str1 or str2 or str3

#この式がなにを評価しているかがわからにぃ

#実行すると'Trondheim'が出力されるということは

#not nullになる一番最初の値を代入してるってこと？

過去記事

Pythonチュートリアル一人読書会 vol.1

Pythonチュートリアル一人読書会 vol.2