2016-05-17

技術的な負債を返済するための挑戦の話

技術的負債を返済するために

今，僕が所属しているチームで，技術的な負債を返済していくために，最低限，必ず，毎週金曜日の一時間を当てることにしました．これは，僕がチームに配属されてから，技術的な負債についてまとめられているタスクボードからタスクが減らないことに危機感を感じたことがきっかけて，提案しました．

そして，抱えている技術的な負債のリストを洗い出し，幾つかの方法で分類し，とりかかるべきタスクを決定していきました．

その中で得た幾つかの知見・考えたこと，感じたことについてまとめていきたいと思います．

技術的な負債を効果と工数で分類する

まず，技術的な負債を効果・工数の２つで分類しました．効果が高く，工数が低いものから順番に消化していこうという動機です．

しかし，残念ながら，この方法ではうまく行きませんでした．後から考えると，当たり前なのですが，効果の高い側に付箋が集まりすぎて，分類があまり意味をなしませんでした．

重要でないタスクについては，そもそも提案すらされないということですね，当たり前っちゃあ当たり前です...．

ただ，工数の大小については，分類していくことができたため，更に．「効果」というものに対して考察を加え，分類を繰り返しました．

効果とは何か

さて，改めて，「効果」とは何なのかについて考えてみましょう．

効果には複数あります．

サービス非荷室に対する効果
セキュリティに対する効果
生産性に対する効果

ぱっと思いつくだけでも，上記の事がリストできました．これ以外にでも，いくらでも思いつくことができるでしょう．

では，どの「効果」がよくなるタスクについて，最初に，とりかかるべきでしょうか？．

結論としては，「生産性」にフォーカスし，改善していくことにしました．

生産性とは？

さて，では，生産性とは何でしょうか？．簡単に調べてみたところ，生産性とは

生産性=アウトプット/インプット

で，あるそうです．であるならば，インプットを減らすか，アウトプットを増やすかすればよいわけです．

インプットについては，おそらく，時間でしょう．アウトプットは，タスクごとにまちまちなように思います．

少なくとも，「何らかのインプットが減り，何らかのアウトプットが増える」改善に最初はフォーカスしよう．

結果，生産性を高めることで，余剰ができた時間で，その他の改善ができればよいのではないだろうか，こう考えて，次に取り組むべき改善を見つけました．

まだまだ，この挑戦を行ってからの時間が浅いので，どのような効果があったかについては，未知です．いずれ，ある程度の結果が出たら，ここでまとめて報告をしたいと思います．

2016-05-13

ErgoDox Ez のキーボード配列

最終的に，下記のキーボード配列に落ち着きました．復帰戦なので，短めです．

* ,--------------------------------------------------.           ,--------------------------------------------------.
 * |   =    |   1  |   2  |   3  |   4  |   5  | LEFT |           | RIGHT|   6  |   7  |   8  |   9  |   0  |   -    |
 * |--------+------+------+------+------+-------------|           |------+------+------+------+------+------+--------|
 * | TAB    |   Q  |   W  |   E  |   R  |   T  |  L1  |           |  L1  |   Y  |   U  |   I  |   O  |   P  |   \    |
 * |--------+------+------+------+------+------|      |           |      |------+------+------+------+------+--------|
 * | CTL    |  A   |   S  |   D  |   F  |   G  |------|           |------|   H  |   J  |   K  |   L  |   ;  |   '    |
 * |--------+------+------+------+------+------| LGui |           |Backsp|------+------+------+------+------+--------|
 * | LShift |  Z   |   X  |   C  |   V  |   B  |      |           |ace   |   N  |   M  |   ,  |   .  |   /  | RShift |
 * `--------+------+------+------+------+-------------'           `-------------+------+------+------+------+--------'
 *   |Grv/L1|  '"  |AltShf| App  | LGui |                                       | RGui | Alt  |   [  |   ]  | ~L1  |
 *   `----------------------------------'                                       `----------------------------------'
 *                                        ,-------------.       ,-------------.
 *                                        | ESC  | L2   |       | L2   | ESC  |
 *                                 ,------|------|------|       |------+--------+------.
 *                                 |      |      | Home |       | PgUp |        |      |
 *                                 | Space| Tab  |------|       |------|  Tab   |Enter |
 *                                 |      |      | End  |       | PgDn |        |      |
 *                                 `--------------------'       `----------------------'

2016-05-09

ABC #36 の C について

今，僕が所属している会社では，「インフラエンジニアたちが Ruby を勉強する会」が毎週開催されています．

今回から，ABC(http://atcoder.jp/，この中で，beginner 向けのもの) を説いてきて，それらをレビューしてもらおう，という活動が始まりました．

今回は， ABC #36 がお題に挙げられていて，その中の，「座圧」の話をします．

この問題に，僕はドハマリして，2 ~ 3 時間ぐらいかかりました．

問題文としては，下記の URL のようになります．

ref : http://abc036.contest.atcoder.jp/tasks/abc036_c

まず，ハマった，難しかったポイントの一つ目です．

問題文の意味がわかりませんでした，日本語なのに．マジで．

なので，問題文が何を意味しているのかを把握する必要がありました．不親切なことに(問題，なので当たり前ですが)，入出力例は一例しか与えられていません．

まず，この例が，問題文の条件をみたすことを確認しました．

そして，次に，同様の条件を満たすように適当な，値の列を幾つか作り，共通点を探しました．

この作業を繰り返すうち，どのような条件を満たす値の列を作成すればよいかが，把握でき，コードに落としこむことができました．

次に，この問題には，入力から出力までにかかる時間に制限が設けられていました．

これが，満たせませんでした.. .．結局，配列の走査にかかる時間が問題でした．

配列の走査をする箇所を最小にし，利用できる箇所は Hash を利用することで，制限時間をクリアできました．

以上が，問題を解くまでの流れです．

この問題は，簡単です．少なくとも，AtCoder はそう言ってます．

ですが，この簡単であるはずの問題も，僕はまともに解けませんでした．

しかし，解いてみた感想としては，このレベルの，あるいは，もう少し上の問題に対してなら訓練で対処できるかもしれない，ということです．

年々，頭も悪くなっています，集中力もなくなっています，でも，そのまま何もしなければ，そのままなのです．意識高く頭を使っていきたいと思います．

がんばる．

このくらいの問題ならさっと解いてしまう，若者の存在が怖いよぅ．

2016-05-08

負荷試験のはなしの続き

さて，遅くなってしまいましたが「負荷試験のはなし」の続きを書いていきたいと思います．

負荷試験のツールに locust を採用したという話までしましたね．

では，locust のコードについて書いていきたいと思います．前に書いたとおり，Install などについては省略しますね．

構成について

master が 1 台，slave が 2 台の合計 3 台で負荷をかけていきます．

実行方法について

master で下記のようなコマンドを，実行します．

sudo locust -f locustfile.py --host=http://stress-test.xxx.xxx --master --logfile='./log/locust.log'

そして，slave で下記のようなコマンドを実行します．

sudo locust -f locustfile.py --slave --host=http://stress-test.xxx.xxx --master-host=1.1.1.1

master と slave の間では，必要なポートを許可しておく必要があります．

また，負荷試験の対象となるサーバーは，コマンドラインオプションで指定します．

コードについて

resource.setrlimit(resource.RLIMIT_NOFILE, (10000, 10000))

URLS = [
    "a=1",
    "a=2",
    "a=3"
]

PW = getpass.getpass(' Enter Password:')
logfile = open('./log/result.csv', 'w')
var  = 0
data = []

def output_request_log_as_csv_format(request_type, name, response_time, response_length, **kw):
  .
  .
  .
  
def close_log_file():
  .
  .
  .
  
events.request_success += output_request_log_as_csv_format
events.quitting   += close_log_file

class UserBehavior(TaskSet):
    def on_start(self):
        self.client.headers = self.headers

    @task(5000)
    def action_landing_page(self):
        self.client.get(random.sample(URLS, 1)[0], auth=("user", PW))

class WebsiteUser(HttpLocust):
    task_set = UserBehavior
    min_wait=1000
    max_wait=3000

コード全体のイメージとしては，上記のようになります．

events.request_success と events.quitting でリクエストが成功した時と，リクエストが終了した時にそれぞれ処理を実行しています．

ここでは，レスポンスタイムなどの情報が欲しかったので，CSV として，結果を書き込んでいます．

そして，リクエストが終了した時に CSV ファイルを閉じています．

我々の環境では，負荷試験用の環境には認証をかけているので，elf.client.get("/", auth=("user", PW)) のようにしています．

そして，UserBehavior でいわゆるシナリオ，ユーザーの振る舞いを記述しています．

URLS 配列の中からランダムに１つを選び，Get しています．

また，十分にresourcesを使えるよう

resource.setrlimit(resource.RLIMIT_NOFILE, (10000, 10000))

のようにして，RLIMIT_NOFILE を増やしています．

この子たちは，Python の Script などで自由度はとても高いです．

反面，やりたいことは自分で書かなければならない部分も大きいですが，この程度の処理ならさほど時間もかからないでしょう．

最後に，所感ですが，複数台でそれなりの負荷がかけられるツールとしては，locust は利用しやすいと思います．詳細な分析を必要としなければ，locust を採用してみてはいかがでしょう？

2016-05-06

日数を途切れさせないための記事

諸々立て込んでしまったので，昨日の記事の続きはまた明日にします...

2016-05-05

負荷試験についてのはなし

こんばんは．

今日こそは，技術的な話題を書いていきます．

僕はインフラエンジニアなんですが，最近，仕事でとあるサイトの構成を変更しました．そこで，構成変更後のサイトが十分な req/sec を発揮できるかを確かめる必要がありました．

以前までの負荷試験では，gatling を利用していましたが，今回，負荷試験するサイトは１つのサーバーからかける負荷には十分耐えられるだろうということがわかっていました．

そこで，複数のサーバーから分散して負荷をかけられるようなツールを使う必要がありました．代表的なものとしては，jmater などがあります．

しかし，構成変更を完了するまでの時間が少なかったこと，そして，最悪でも元のサーバーのスペックから必要な resources を見積もれるだろうということもあり，jmater ほどきちんとした情報を集める必要はありません．

そこで，もっと簡単に付加をかけることができそうな locust を採用することにしました．

この子は，Python 製の負荷試験のためのフレームワークというようなもので，簡単なコードを書くだけで負荷試験を実現できます．もちろん，複数のサーバーから負荷をかけることもできます．

インストール方法などは，他のブログ等を参考にしてもらうとして，ここでは，locust を利用した負荷試験のためのコードを紹介したいと思います．

ということで，明日はコードについて解説します

2016-05-03

禁煙を始めたはなし

人生何度目かの禁煙を始めました．

何度かタバコをやめていて，最長で 1 年とちょっと，挫折したきっかけはとある古いミドルウェアとの戦いでイライラしすぎて...と言った感じです．

僕は，禁煙するときに ”ニコチンパッチ” か ”チャンピックス” を使います．どちらも禁煙にあたっての離脱症状をとっても抑制してくれます．ストレスフリーな連休中(ちょうど今だね！)に始めると，辛さは殆ど無く禁煙を続けていくことができます．

以前，根性だけでやめようとした時は，まぁ，キツかったです．

ということで，挫折したら罵倒すると良いと思うよ！．

ブログを一ヶ月連続で続けようという活動を，会社の仲間としています．２日目にして，技術的な内容ではなくなっちゃいましたが，何個か書きたい技術的な話題もあるので，次とかその次とかにはきっと技術的な話題を書きます...．