先を見通す力は時間的な予測に限らず、空間的な認識の広がりや人に対する配慮のできる深さにも同じ資質がかかわる

自分に不足してることを考えてみるとそう感じる

予測して予定を計画すること。車を運転するとき先を見越して滑らかにハンドリングすること。言葉を人が聞いてそのあとどういう気持ちになるだろう、という心遣い

苦手なものの共通項としてくくると、先を見通すこと、となる

だから人を思いやる心を養う為に、時間的な先を見通す力を訓練したり、空間的な先を見通す力を訓練することが役に立つ？かも

と、感じた

キャンペーンシステムの品質チェックについて

たいてい「どういう条件要求にも対処できるように」生のRDBなりから任意にクエリを組んでデータが抜けるシステムが用いられてる気がする

この場合に問題になるのが「条件要求のバリエーションが複雑化し過ぎた時の仕様が正しいかどうか」を担保する方法が定型化しづらいことだ

ユーザーの属性や行動ログやコンバージョン条件に応じて条件要求がきまると、抜いたデータが本当に要求仕様に沿っているか確認するのが難しい

ひとつここに案として、今思いついたものを書き留めておく

そもそもユーザーに対して処理を行う、という賞品付与から発想が出発すると行き詰まる。つまりこれこれこういう人はどれくらい賞品をもらえるのか？といったかたちでテストするのはほとんど毎回ターゲットが変わるこの類の要件に対応しづらい

逆に、賞品の付与され方から発想するのはどうか。クレカ入会で5000ポイント付与、という要件では「クレカ入会の定義」は複雑化しがちだ。仮入会があるのか、審査結果NGの場合はどうするのか、など。一方で5000ポイントを1人の人がもらう、という賞品付与の定義は明快

だから、5000ポイントもらえる人は誰と誰と誰なのか、をシステムの判定条件から網羅的に示すことは出来そうなので、これを要求元に確認してもらえば少なくとも「意図してないターゲットに付与」してしまうことは避けられそうだ

もらえる人と貰えないひととがある場合は賞品付与の量が0の人達、というふうに示せば良い

これであれば賞品付与のパターンごとに1行ずつ、対象者像を出力するのも出来そうである


引き続き検証していきたい

■

初夢

夜の実家にいる。古い公団の団地で3階

治安が悪いはずがないが、近所のおじさんがなぜかうちに「若い奴らが下の自販機のところで暴れてるぞ！」と知らせに来る

正義感があるキャラの心境から恐怖が自分を支配していって、俺なんて特にうでっぷしが強いわけじゃないし、いったん鍵を閉めて身を守ろうとドアに手を掛けた

鍵が閉まりかけたとき外からドアを引っ張られて、少しひらいたドアの向こうにギャルがいた。子供のときにフラれた娘によくにているその人が「見つけた」といわんばかりに笑みを浮かべたその瞬間

おれは危険を感じて必死で力任せにドアを閉める。今度はちゃんと鍵もしまってチェーンを掛けるかかけないかのとき外で舌打ちが聞こえ、地上の方で取り逃がしたことを悔しがるチンピラたちの声が聞こえた

fabric使ってインシデント一次対応の自動化をすることになった

pythonあんまり良くわかんないけど

 

目的
  • オペレーション手順をプロダクト単位に管理していく上でメンテコスト（現行は手順書ドキュメント管理）が肥大化し続けることが課題となっている

 

方針
  • メンテナンス性重視。出来うる限りDRYな状態が保ち続けられるような設計
  • プロダクトを横断して使うのでプロダクトそれぞれの価値観によって同じ手順の亜種が大量にできてしまいうる
    基本的には「標準処理」で対応可能なミドルウェアのみ処理対象としておきたい、が
  • 【？】最終的なゴールとして自動オペレーションの対象とする要求はどこまでを許容範囲とするか。（いちばん細い単位まで自動化対象とするとすると結局、メンテコストが大きくなってしまう状況が避けえないのじゃないか）

 

pythonとfabricについて

fabricタスクをデコレートして異なるミドルウェア同士のクラスを抽象クラスで定義できる。構造化というよりはfactoryMethodに近い

fabricの中でも多少の構造化する仕組みがある。タスク定義するfabfileが、普通に書いてると1ファイルの中にタスクがたくさんできてってしまうが、__init__使うことでネームスペースを区切る程度のことはできる
が、これだけだとやはり結合を疎に保ち続けるのはなかなか厳しい

デザインパターン使ってやりたい。最初に挙げたfactoryMethodがなかなかいいかな、と感じているがそれでもまあまあ苦しいはず

 

Jenkinsについて

本当はbuildPipeLineとかでビジュアル的に作業手順を処理としてまとめて管理していく方がメンテコストを低く保ち続けやすいんじゃないだろうか
確か、自分が参画する前のツール選定で弾かれてたきがする

 

勉強しなあかん

pythonとfabricについて

プロジェクトの構造 — Pythonヒッチハイク・ガイド

Python 言語リファレンス — Python 3.5.1 ドキュメント

Welcome to Fabric’s documentation! — Fabric ドキュメント

 

ドキュメンテーションついて

doxygenで生成してgithub-pagesで公開できる。pj上にドキュメントを展開できるから全部そこに集まるし便利

www.doxygen.jp

www.graco.c.u-tokyo.ac.jp

 

ドキュメンテーションはどうするか迷うな、しかし

メンテナンス性とか考えるとDoxygen + Graphiz がいいと思うけど、せっかくpythonだしSphinx使って綺麗に書けるといい。でもconfuluence使える環境があるので、わざわざSphinx使うくらいならそっちかなー、とも思う。けど、Sphinx + blockdiag 使えるとか図があるかどうかで結構差が出る。confuluenceはエディタが本当に素晴らしいけど結局、デベロッパーとして本気出そうとするとUMLとかもっと導入しやすくないとなあ

 

こうやってDoxygenとblockdiag組み合わせるとかもありかも

http://qiita.com/umiyosh/items/d73f1e507aa8018b5cf2

 

pythonのコーディング規約やドキュメントやデザインパターンなど

https://myekps1te.wordpress.com/2014/08/15/大規模なプログラムをpythonで始めるときに知ってお/