omohayui blog

おも‐はゆ・い【面映ゆい】[形][文]おもはゆ・し[ク]《顔を合わせるとまばゆく感じられる意》きまりが悪い。てれくさい。

GAE で監視ファイルが多すぎて auto reload が走らない件

何が起きていたか?

・ローカル開発環境で go のテンプレートファイルを更新しても GAE の auto reload が走らない
*.go ファイルを更新したときは走る
・go version go1.6.2 (appengine-1.9.40) darwin/amd64

goapp 起動時の error log

/usr/local/Cellar/app-engine-go-64/1.9.40/share/app-engine-go-64/google/appengine/tools/devappserver2/mtime_file_watcher.py:115: UserWarning: There are too many files in your application for changes in all of them to be monitored. You may have to restart the development server to see some changes to your files.

原因

  • 監視ファイルが多くなった為、ファイル監視の閾値を超えてしまった
  • たぶん node module 系が含まれてしまっている

閾値と監視対象ファイルをどこで設定しているのか

ファイル数上限

github.com

_MAX_MONITORED_FILES = 10000

監視対象外ファイル

python-compat-runtime/watcher_common.py at ee5cffab9b62ba293c61228260735ad5c9a9395c · GoogleCloudPlatform/python-compat-runtime · GitHub

_IGNORED_FILE_SUFFIXES = (
    # Python temporaries
    '.pyc',
    '.pyo',
    # Backups
    '~',
    # Emacs
    '#',
    # Vim
    '.swp',
    '.swo',
)

とりあえずの対応

  • これらの設定は固定値で外から指定できなさそうなので一旦直接書き換えた・・

(その1)ファイル上限数を変更

vim /usr/local/Cellar/app-engine-go-64/1.9.40/share/app-engine-go-64/google/appengine/tools/devappserver2/mtime_file_watcher.py

下記のように書き換え

-- _MAX_MONITORED_FILES = 10000
++ _MAX_MONITORED_FILES = 100000

(その2)除外ファイルに追加

vim /usr/local/Cellar/app-engine-go-64/1.9.40/share/app-engine-go-64/google/appengine/tools/devappserver2/watcher_common.py

下記のように追記

_IGNORED_FILE_SUFFIXES = (
    # Python temporaries
    '.pyc',
    '.pyo',
    # Backups
    '~',
    # Emacs
    '#',
    # Vim
    '.swp',
    '.swo',
++    '.js',
)

デザイニング・インターフェース(1)

読書会向けの自分用のメモです。

1章 ユーザの行動

インターフェースデザインの格言

「汝のユーザを知れ ― 彼らはあなたとは別人なのだ!」

インターフェースデザインはユーザとマシン(モノ)の会話を仲介する手段

目的達成の手段

ユーザが本当に達成しようとしている目標が何なのか見極める

”なぜ” その機能やソリューションを求めているのか、十分に現状把握ができるまで質問を繰り返そう

(!) より魅力的で成功するアプリケーションをつくるためには、
 既存のメソッドにあてはめるだけでなく、数多くの「よりソフトなファクター」を考慮する必要があるよ

ユーザ調査の基礎

ユーザグループはそれぞれ固有の性質を持っている

秘訣は対象となるユーザーグループについて “おおむね” 該当する事実は何なのかを見極めること

そのメソッドとして挙げられたもの

ユーザの学習意欲

ユーザーは自分の作ったインターフェースを学習するためにどれくらいの努力をしてくれるのか考慮しよう

  • 中級〜上級のユーザ
    • 開発・管理ツールなど
  • 永遠の初心者
    • インストールウィザードなど

ユーザの学習意欲がインターフェースの随所に関係してくるよ

(!) いずれのユーザ層にも対応するデザインを作りたいという苦悩も発生してくる
⇒ それは2章のマルチレベルのヘルプでやるよ

パターンの解説

14個もあるので簡単に

1. 安全な探検

優れたソフトウェアでは、慣れていない操作をやってみてからもとに戻して、また別の操作を試してみる、ということがストレスなく実施できる

⇒ ユーザは探検することで多くを学び意欲的になる

2. 即座の喜び

アプリケーションを使い始めて即座に “成功体験” が得られる

⇒ プリケーションに対する信頼が強まると同時に、ユーザの自信も増していく

3. 最小限での充足

より良いモノや手段があると知っていても、多くの時間や労力がかかる場合、人は “最善” ではなく “必要十分” な結果を受け入れたがる

(!) 最小限での充足は、多くのユーザに中途半端な習慣を身につけてしまう要因でもある
 効率の良い新しい手順で改善される労力 と 古い習慣を打破して新しいことを身につける労力 のトレードオフ

4. 途中での方針変更

ユーザのゴールは操作途中に変化することがある

⇒ ユーザが方針変更できる機会を提供する必要がある

(!) ただし、方針変更させない妥当な理由が伴うケースは別だよ
 ⇒ それは2章、3章で

5. 回答の先送り

ユーザに対して、最初からあまり多くの先行的選択を迫らないこと

⇒ 「2. 即座の喜び」につながるよ

6. 少しずつの組み立て

ユーザの創造的活動は小さな変更の積み重ねによって少しずつ行われることが多い

⇒ 素早い変更と保存やプレビュー、フィードバックなどの機能で創造的活動をサポートしたほうがいいよ

7. 習慣化

習慣化はユーザがそのツールの上級者へと成長していくのに役立ち効率をアップさせる

(!) ただし、アプリケーション間での一貫性が重要だよ
 アプリケーションごとに習慣が違うと逆に混乱させるよ

8. 小刻みな休止

小刻みな休止に対応するポイントは、その機能を簡単に実行でき、すばやく呼び出せるものにすることだよ

9. 空間的な記憶

何かを探すときに人は空間的な記憶を用いることが多い

  • 既に配置されているコントロールの位置を変えることによる混乱
  • 「7. 習慣化」と同様にプラットフォーム間を跨いだときの一貫性の欠如

⇒ 3章ログインツール、4章反応的な追加表示 で詳しくやるよ…

10. 展望的な記憶

ユーザはこれから何かしようと計画するとき展望的な記憶を忘れないように手元に残す

⇒ 展望的な記憶を促すためのインターフェースを提供しよう

(!) 機能を提供することよりも、作成中のものを勝手に片付けたり、
 ユーザの要求なしに自動的に整列やソートするような "親切" 処理が行われてしまっていないか注意しよう

11. 繰り返しの効率化

ユーザはさまざまな種類のアプリケーションで、同じ操作を何度も繰り返し実行していることがある

  • よく使われる機能の繰り返し処理のサポート
  • 操作の記録と再生 ⇒ 6章のマクロで詳しくやるよ

12. キーボードのみ

身体上の困難によってマウスを使うことができない人々やキーボードに手を置きっぱなしで作業したい人がいるよ

13. 他者のアドバイス

他のユーザのアドバイスは直接的か間接的かに関わらず、何かきめるべきことがある時に我々の判断に影響を与える

そしてそれが良い結果につながるケースが多い(と言っているように聞こえる)

⇒ 他者のアドバイスを集める仕組みを考えてみよう 2章マルチレベルのヘルプ など

14. 個人的レコメンデーション

「13. 他者のアドバイス」をさらに有効にする個人的レコメンデーションを促す仕組みについても考えよう

まとめ

より効率良くユーザの目標達成を可能にするインターフェースのパターンや考え方を学ぼう!

iTerm2 の screen でスクロールバッファ

ほんと今更ですけど...

screen のバッファをマウススクロールできるようにする

https://github.com/omohayui/dotfiles/blob/master/_screenrc#L16

termcapinfo xterm* ti@:te@

.screenrc にこの1行を追加するだけ

iTerm2 で status bar 表示時もスクロールできるようにする

[Preferences] ⇒ [Profile] ⇒ [Terminal] ⇒ "Save lines to scrollback when an app status bar is present" にチェック

f:id:omohayui:20160619173219p:plain

Exercise on A Tour of Go

A Tour of Go の練習問題 『Loops and Functions』 についてのメモ

ニュートン法の式

文系(美術系)の自分にはそもそも計算式の意味が・・・

10回ループ

問題文に書いてある通り、とりあえず ニュートン法の式をそのまま関数に入れて 10回ループさせて x の値を増やしていき math.Sqrt との近似値を確認する。

package main

import (
    "fmt"
    "math"
)

func Sqrt(x float64) float64 {
    z := float64(1)
    for i := 0; i < 10; i++ {
        z = z - (z * z - x) / 2 * z
    }
    return z
}

func main() {
    x  := float64(2)
    sq := Sqrt(x)
    ms := math.Sqrt(x)
    fmt.Println(ms, sq)
    // Diff
    fmt.Println(ms - sq)
}

10回ループした結果

1.4142135623730951 1.3351578377717581
0.07905572460133703

10000回ループした結果

1.4142135623730951 1.4106685607006662
0.0035450016724289934

ここまではなんとか・・・ 10000回ループすると math.Sqrt に近づいているのがわかる

zの値の直前との差が小さくなったら停止するようにループを変更

if 文を追加して直前のzの値との差が定義した許容値以下になったら break するように修正

package main

import (
    "fmt"
    "math"
)

const tolerance = 0.001

func Sqrt(x float64) float64 {
    z := float64(1)
    t := z
    for {
        z = z - (z * z - x) / 2 * z
        if math.Abs(z - t) < tolerance {
            break
        }
        t = z
    }
    return z
}

func main() {
    x  := float64(2)
    sq := Sqrt(x)
    ms := math.Sqrt(x)
    fmt.Println(ms, sq)
    // Diff
    fmt.Println(ms - sq)
}

結果

1.4142135623730951 1.414713296482291
-0.000499734109195904

最初、自分は直前との差を出すのに if z - t < tolerance { とやっていてうまくいかず・・・

調べたら差分がマイナスになることもあるので絶対値をもとめる math.Abs を使うべしということがわかった

がしかしチュートリアル充実してるし
思ってたよりGoシンプルでわかりやすいし
逃げずにコツコツ勉強しようと思います。たぶん。

Slackに野球ニュースをpostするbotを作った

職場のSlackに #baseball チャンネルを追加したついでに、
野球ニュースを投下するbotをつくりました。

f:id:omohayui:20151013100624p:plain

開発環境

  • node.js : v0.12.0
  • npm : 2.5.1
  • hubot : 2.16.0
  • CoffeeScript : 1.10.0
  • Heroku

データ元

ソース

github.com

利用方法

  • 毎朝10時に #baseball チャンネルにニュースを投下
  • コマンド "baseball news" で #baseball チャンネルにニュースを投下
  • 日時やチャンネル、ニュースの数は変更可能