2018-05-20

https://scripter.co/org-contribution-flowchart/

org-modeでフローチャートを描くためのものらしい

SPRINT 最速仕事術

INTRODUCTION

スプリントはGV(Google ベンチャー)のプロセスで、アイディアをプロトタイプに落とし込み、それを顧客とテストすることで短期間で問題の答えを出すためのフレームワーク。 単なるブレーンストーミングは発散するだけで何も決まらないが、スプリントは確実にゴールに向かうことができる、と本では説明されている。なぜならブレーンストーミングは議論するだけで何かを決定することはできない。スプリントは実際にそれを作るためのチームメンバーをそろえた状態ではじめるので、すぐにアイディアをプロトタイプ化することができる。

第一章

スプリントでは、とりあえず外見を作って反応をみる。細部まで作り込む必要はない。 このやりかたは課題が大きいほど役に立つ。

第二章

スプリントをやるには必ず決定者を入れること。でないと、やったことが無駄になってしまう。 また人数が多すぎると発散してしまう。7人までがよいらしい。

第三章

集中力を分断しないために、スプリントの日はそれだけに取り組む。 週末をまたぐと発散するので5日がよいらしい

第四章

スプリントに入ったら、まず長期目標を定める 次にスプリントクエスチョン(失敗するとしたらその原因となるもの)を出す これらはスプリントを進める上での指針となる

LIFE SHIFT

序章

平均寿命がいまのびつつあり、100歳までの人生があたりまえになる。 そのとき、今と同じように教育→勤労→引退の3ステージでは、勤労のステージだけが伸びてしまってハッピーな人生とはいえないし、同じスキルでいつまでも働きつづけられるとは限らない。

たとえば100歳まで生き、働いている間は10%を貯蓄、引退後は勤労時の半分の年収分の貯蓄を得たいとすれば80代まで働き続けなければならない。 余暇もレクリエーション(娯楽)ではなく、リ・クリエーション(投資・最創造)に使わなければならない。

どう考えても、ぞっとする話であるし、はたして本当だろうか。 確かに医療は進化しているので、今は寿命は伸びているかもしれないが、生まれたときからジャンクフードに囲まれた私たちが同じように長生きするかは、実際歳とってみないとわからないと思う。

第一章

序章で思ったことが書かれていた。 楽観的に寿命伸びてくだろうという派と生活習慣から寿命はむしろ落ちていく悲観派がいる。

第二章

年代ごとに、3ステージの人生をあゆむとして、その歳の引退後の収支の推定

cadvisorのdockerイメージをアップデートしたら起動しなくなった

cadvisor_1 | F0102 14:18:53.414915 1 cadvisor.go:156] Failed to start container manager: inotify_add_watch /sys/fs/cgroup/cpuacct,cpu: no such file or directory

というメッセージとともに、終了コード255で起動処理中に落ちてしまう。 ぐぐってみると、類似のissueがみつかり、 docker起動時の引数の --volume=/sys:/sys:ro がいけないらしい。

https://github.com/google/cadvisor/issues/1843

これをはずすことで無事起動できるようになった。

20180103追記

はずすと起動はできたが、当然ながら、/sys/fs/cgroups配下が見れなくなるので、コンテナごとの情報が取れなくなってしまう。 同issueにある

mount -o remount,rw '/sys/fs/cgroup'
ln -s /sys/fs/cgroup/cpu,cpuacct /sys/fs/cgroup/cpuacct,cpu

で解決したほうがよい。

Elixirの概要

概要 本家の記載は確認していないが、いろいろとWebをみるとサーバを書くのに適しているらしい。 学習 https://elixirschool.com/jp/ これが一般的なチュートリアルらしいので進めた。 マッチ演算子 https://elixirschool.com/jp/lessons/basics/pattern-matching/ iex(65)> x = 1 1 iex(66)> 1 = x 1 iex(67)> x 1 iex(68)> 1 1 iex(69)> 2 = x ** (MatchError) no match of right hand side value: 1 ちょっとよくわからない。 1 = xの解釈がいちばん難しい。 たぶんマッチングをとるというぐらいだから、右辺と左辺で一致させられるかを見て、一致した場合に左辺に右辺を代入。今回のケースだと1と1で一致はするけど、左辺に変数がないからなにもしない、ということなのだろう。 別の奴で、elixirの変数の概念は代入ではなく、ラベル付けだ!みたいのも読んだきがするけど。 ということが、ピン演算子まで読んだら、理解できた。 iex(88)> case {1, 2, 3} do ...(88)> {x, y, 3} when y > 0 -> x ...(88)> _ -> "Not match" ...(88)> end 1 マッチングとるのでこういうこともできるらしい。表現力すごい。 caseだとC言語のdefineに該当するような、elseに該当するのが _ - なのにcondだと true なのが、複雑ちゃ複雑。統一できそうなもんだけど。 [Read More]

config.tomlの内容

pluralizeListTitles

セクション等の一覧ページのタイトルを複数形にする。 javascript→javascripts, github→githubsなどなど。

なぜかemacsはemacsのままだったので気付くのが遅れてしまった。 うっとうしいので、config.tomlでオフに設定しておくのがよいと思う。

pluralizeListTitles = false

lastmod

enableGitInfoをtrueにすると、GITの情報でLastModを自動で取得してくれる、とあるのだけどうまくいかない。 content配下だけをgit管理にしてもだめで、hugoのフォルダ一式を管理下におかないとだめなのかも。

mode-line系のパッケージ

powerline

https://github.com/milkypostman/powerline

vimのpowerlineをemacsに実装したもの 見た目がクールになる、以上の用途を知らない

smart-mode-line

https://github.com/Malabarba/smart-mode-line

できるだけmode-lineの限られた幅を有効活用しようとする。 たとえば、.emacs.dを:ED:と省略表示できたり、とか diminishっぽい設定ができたり、とか。

見た目はそこまで変わらないけど、powerline-themeもあるので、powerlineっぽくすることも可能

spaceline

https://github.com/TheBB/spaceline

spacemacsのモードライン設定を抜き出したパッケージっぽい powerlineよりクールになる他、flycheckとかanzuとかの定番パッケージをクールに表示できる。 (その反面、設定変えないと表示が重複するので、オリジナルはdiminishすべし)

現状spacelineをベースとして、自分でテーマを書いて使ってる。all-the-iconsとかも使ってなかなかクールに作れてるんじゃないかと思うが、はたしてモードラインがクールであることに意味があるのだろうか

GitHubのシンタックスハイライト

以下で定義されている

https://github.com/github/linguist/blob/master/lib/linguist/languages.yml

GFMのシンタックスハイライトで使えると書いてあるが、たぶんorg-modeの #+BEGIN_SRC / #+END_SRC でも使えるはず。

https://help.github.com/articles/creating-and-highlighting-code-blocks/#syntax-highlighting

Ansibleの制御構造

Ansibleの制御構造

ループ

- name: add several users
  user:
    name: "{{ item }}"
    state: present
    groups: "wheel"
  with_items:
     - testuser1
     - testuser2

のように、with_itemsを使うことで、変数itemに値が入りそれぞれについて実行できる。 複数の属性を持たせたり、辞書型にすることもできるが基本は上記の形

ansibleの概念上、複数回繰り返すというより、リストを回すのが適切なので、forよりはforeachに近いイメージ(ただし、N回繰り返すというuntilループも可能)

条件分岐

tasks:
  - command: /bin/false
    register: result
    ignore_errors: True

  - command: /bin/something
    when: result|failed

の形で、whenを使う。registerで結果を格納し、それ以降のタスクのwhenで判定に使うことができる。