Learn Vimscript the Hard Wayの感想

はじまり

現在思いつきでvimscriptを勉強中だ。「vim plugin 作り方」とGoogle検索して、ヒットするページのトップ３は以下のとおり。

　1. vimプラグインができるまで
　2. 初心者のためのvimプラグイン
　3. Vim Plugin 作成の勉強のため特定のパターンに一致する行を抽出して編集するためのスクリプト作った

どのページも完結にまとまっていて上記ページをみてもらうのが一番よいと思う。以下は自分用のメモ扱いです。

vimプラグインを作るために最初にやること

言うまでもなく、最初はvimscript構文を覚えることだ。一番分かりやすかったのが以下のページ。２，３時間もあれば十分理解できると思う。

• Vimスクリプト基礎文法最速マスター - 永遠に未完成

次に、簡単な関数を書いてみる。関数宣言については、「Vimざっくりチュートリアル」がまとまっていて読みやすかった。以下引用です。

関数作成（functionは）

:function Func(flg) " グローバルスコープの場合、関数名はアルファベットの大文字で始まる
:  if a:flg         " 引数の参照は、a:引数名
:    echo "true"
:  else
:    return "false" |" 戻り値を返したい場合、return コマンドを使う
:  endif
:endfunction

関数呼び出し

:call Func(0)       " call コマンドは、渡された関数を実行するコマンド。この場合、false が返る
:let test = Func(1) " 戻り値を変数に格納したい場合
:echo Func(1)       " 戻り値をそのまま echo したい場合

次にやることだが、以下のビデオ「Your First Vim Plugin」が非常にオススメ。以下にして目的の機能をvimscriptで実装していくか？流れが手に取るようにわかるだろう。

時間の活用法と習慣化の方法まとめ 挫折しない続ける技術

日経ビジネスアソシエ2016/３月号の付録より引用

時間の活用法

いま自分がどの時間を生きているかを意識すること。

1. 朝時間

2. ランチ時間

3. スキマ時間

4．ガッツリ時間

5．ながら時間

6．ブロック時間 集中する時間。全体の3割撮りたい。

7．リラックス時間

8．マージン時間

9．睡眠時間

2日ワンセットで考える。

遅れを調整するため。
2日＊３日　＋ 1日

開始の儀式を作る。

勉強量はスタートする回数で決まる。
　文房具の準備
　コーヒーを入れる
　テキストをパラパラめくる
　好きな科目から始める。

モチベーションカレンダー

寝る前などに記録してリズムを把握する。○、△、☓
ムラを抑える対策も取れるようになる（睡眠付属の日は○になっていない＝＞睡眠は７時間確保する等。）

学びのマニフェスト

「いつまでに何を達成するのか」を、紙に書き、目の入る場所（学習場所やトイレなど）に貼る

見られていることを意識

ライバル、応援している人、将来の自分（にがっかりさせない）

自己ベスト更新思考

比較対象は過去の自分。

習慣化のポイント

1. ３０日間続けること
2. 毎日行動し続ける
3. 対策し続ける

反発期１－７日：
とにかく続けること。
ポイント：必ず実行できるハードルにする(物足りなくてよい）。シンプル記録（○、☓や時間など簡単でOK）をつける（努力の見える化）

　不安定期８－２１：
想定外事象に対応するために、継続できる仕組みを作ること。（≒　パターン化）。
ポイント：日時・内容・場所を決めてパターン化する（日常の中に学習時間を組み込むこと）。想定外の影響を受けにくい時間帯でパターン化する。例外ルールをつくる（少しだけでもする、別に日にする、特別の日として休む）

　倦怠期２２－３０日
マンネリを防止するために、変化をつけること。
ポイント：環境を変える、継続スイッチを使う（自分に褒美、誰かに褒めてもらう、遊び心（苦難を乗り越えるストーリーの映画音楽を聞く）、理想モデル（理想のモデルを設定する）、儀式（行動スイッチでやる気を出す）、悪魔祓い（行動を妨げる傷害を遠ざける工夫をする。誘惑を目に触れないようにする。）、損得勘定（買った本を横においてプレッシャーを与える）、習慣友達、みんなに宣言、バツゲーム（１日サボったら腕立て１００回等）、目標設定（具体的な数値目標を設定する。宣言、罰ゲーム、強制力と組み合わせると効果的）、強制力（コーチをやとう、専門学校に行く、重要な予定を先に決める等））

嬬恋キャベツマラソン2016の感想。日本一ハードなロードレース？？

始まり

嬬恋キャベツマラソンに参加した。

日本一厳しいロードレースという触れ込みであったが、まったくそのとおりだった。

フラットな箇所はゼロ。登って下ってを繰り返す足と身体全体に負荷のかかるきつーいレース（トレーニングには最適！！）だった。

コース

コースはこんな感じ。高低差が美しい。折り返しの地点のトンガリがきになる。

レース本番

会場着は07:40

駐車場からレース会場までシャトルバスで約5分。一面キャベツだらけ

受付を済ませて会場をぶらぶら。
その間挨拶が延々と続くのを横目にスタート地点へ移動。

スタート

そしてスタート！！

スタートからすぐにひたすら下る。最高地点から最低地点までなのだから、ほんとに一気だ。

「これ帰りは登るんだよな」と思いながらも、キロ3分を切るぐらいのペースで突っ込む。

その後やや登る。ここで心肺に一気に負担がかかる。まだ身体がレースの準備ができていないので、非常に苦しい。（※一番苦しかったもしれない）


ここでいきなり歩き始める人がいたが、その苦しさに耐え切れなかったのだろう。

その後アップダウンをひたすら繰り返す。全体的に登り基調だ。

これならなんとか耐えられるかな？と思った矢先、９キロすぎの長い上り坂が登場。

ここでは歩きたい衝動にかられること30回。歯を食いしばって走りきる。

折り返し

そして折返し地点。
折り返すとすぐに登り

後続選手とすれ違う。「ここで歩いてたら恥ずかしいよな」と更に気合を入れる。

天気は上場。「THE高原」といった感じの風景が美しい。もちろんキャベツだらけ。

折り返してからもアップダウンが続くが、追い風と全体的な下り基調に助けられて行きよりはかなり楽だった。

周りを見る余裕もあり、こんな感じで写真を何枚か撮りながらキロ4分台で飛ばす。

ラスト

そして最後の2キロ上り坂。

泣きたくなるような坂だったが、ただ歩かないことだけを考えて頑張る。

１０キロの選手はほぼ歩いているように見えた。
ハーフ選手はなんとか走るといった感じで、キロ５－６分台まで減速した。

折り返しから抜かれることは一度もなかったが、ここで一人に抜かれる。

やはり登り坂とラストに強い人はいる。
自分にはスパートする心肺が不足していたようだ。

ゴール

そしてゴール


結果はベストから約10分遅れ。これなら上出来かな。

キャベツをゲット。ついでに出店で野菜（ブロッコリーなど）もゲット。一束100円は安い！！


道が混雑するとの話を聞いたので、シャトルバスにのって早々に会場を後にして軽井沢方面へ。


軽井沢のイタリアン「プリモ」でピザとパスタを食す。20分ほど並んだ。

注文はマルゲリータとペスカトーレ。ボリュームは並以上

全体的な感想

コース誘導、全体的な運営ともにまったく問題なし。給水も十分。ただ捕食が少し少なかった（バナナだけ？？見逃しただけかも）かな。

機会があればまた出てみたい。

File.open&each_lineとreadlines&eachのどちらが早いか問題

はじまり

以前から気になっていたeachlineを使うか、readlinesをつかうか問題。

「趣味の問題」と片づけていたが、処理スピードに差があるとしたら、そうも言ってられない。

というわけで、「eachline」と「readlines」で同じ処理を行い、処理時間を比較してみた。

負荷の定義

まずは、処理時間の差につながるプログラムの「負荷」を定義してみたい。

負荷は、「CPU負荷」と「IO負荷」の2種類に大別されるが、今回は前者の「CPU負荷」について考えてみたい。

「CPU負荷≒CPU使用率」これも２種類（「システムCPU時間」と「ユーザCPU時間」）とにわけられる。

「システムCPU時間」はシステムコール等の実行に費やした時間の合計、
「ユーザCPU時間」はそれ以外（超ざっくりです）

よって、OSの機能を呼び出さない限り、システムCPU時間はゼロのままとなる。
また、上述のキーワードは、以下のように言い換えることができる。
　
　システムCPU時間（UserTime)　 ＝　カーネル空間（スペース）
　ユーザCPU時間(SystemTime)　＝　ユーザ空間（スペース）


CPU時間と空間。一見違う種類の言葉に見えるが、ネットの記事をいろいろ見ていると、どうも同じコンテキストで使われているようだ。

ユーザスペースでプログラムが実行されたときの時間

次に気になるのが「空間」の定義である。これはこのへんかLinux純正の説明が詳しい。

以下の図をみれば一目瞭然だろう。

測定

以下のコードで各スペースでの処理時間の測定を行なった。時間測定には「benchmarkモジュール」を利用した。


```rb
require 'benchmark'

Benchmark.bm 10 do |r|
  i = 0
  r.report "open + each" do
    File.open("test.txt").each_line do |j|
       j
    end
  end

  r.report "readlines" do
    File.readlines("test.txt").each do |j|
       j
    end
  end
end
```

eachlineとreadlinesの実装の違い

cのソースコードで実装の違いを確認してみる。

まずはreadlines。

　readlines  : io_s_readlines => rb_io_readlines => rb_io_getline_1 
　の順で関数を呼び出して、１行ずつフェッチして、arrayに追加、最後にarrayを返却。

続いてeach_line。

　each_line  : rb_io_each_line => rb_io_getline_1
　で１行ずつブロックにyieldするだけ。よって１行ずつストアして行列を拡大させる処理が必要ない。よって早いはず？？


以下はスタックオーバーフローでの質問回答

Digging into the source, readlines is implemented by io_s_readlines which calls rb_io_readlines. rb_io_readlines calls rb_io_getline_1 to fetch line and rb_ary_push to push result into the returning array.
each_line is implemented by rb_io_each_line which calls rb_io_getline_1 to fetch line just like readlines and yield the line to your logic with rb_yield.
So, there is no need to store line results in a growing array for each_line, no array resizing, copying issue.

結果

概ね「readlines」が約２倍遅い結果となった。
（※まったく逆の結果readlinesが２倍早くなる場合もあったが原因は不明。）

　　                 　user     　system      total        　real

open + each  0.016000   0.000000   0.016000 (  0.021503)

readlines    　0.031000   0.000000   0.031000 (  0.028004)

リンク

http://stackoverflow.com/questions/15677521/in-ruby-file-readlines-each-not-faster-than-file-open-each-line-why

https://github.com/Shinpeim/process-book

Copywriting is Interface Designの意味について考える。

短い文章だが非常に参考になった。

自分はまずコピーライティングの意味がわからなかった。コピーライトと聞いてすぐ思いつくのが、○○はすすむ、○○はすすめる。といういつもの文章。いまだによくみかけるこの文章をみて思うのは、すすめる気ないな。である。

で、コピーライティングだが、文章の力で人を振り向かせること、文章の技術のことらしい。

完結にまとめると、ユーザが知りたいこと（知る必要のあること）は何か？また、簡潔に説明するにはどうやって説明するのがよいか？を考えて、文章を書くことらしい。

これはいわずもがなで特に新しい視点はなかった。ポイントは言葉もデザインということ。アイコンやフォントなどのいわゆるデザインキャラクタよりもより多くを語るのだ。

Every letter matters
Copywriting is interface design. Great interfaces are written. If you think every pixel, every icon, every typeface matters, then you also need to believe every letter matters. When you're writing your interface, always put yourself in the shoes of the person who's reading your interface. What do they need to know? How can you explain it succinctly and clearly?

Do you label a button Submit or Save or Update or New or Create? That's copywriting. Do you write three sentences or five? Do you explain with general examples or with details? Do you label content New or Updated or Recently Updated or Modified? Is it There are new messages: 5 or There are 5 new messages or is it 5 or five or messages or posts? All of this matters.

You need to speak the same language as your audience too. Just because you're writing a web app doesn't mean you can get away with technical jargon. Think about your customers and think about what those buttons and words mean to them. Don't use acronyms or words that most people don't understand. Don't use internal lingo. Don't sound like an engineer talking to another engineer. Keep it short and sweet. Say what you need to and no more.

Good writing is good design. It's a rare exception where words don't accompany design. Icons with names, form fields with examples, buttons with labels, step by step instructions in a process, a clear explanation of your refund policy. These are all interface design.

Link:
https://gettingreal.37signals.com/