omohayui blog

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

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 チャンネルにニュースを投下
  • 日時やチャンネル、ニュースの数は変更可能

YAPC::Asia 2015 リファクタリングの話

先日、今年で最後という YAPC::Asia に参加してきました。
中でも面白かった Benさんのリファクタリングの話についてまとめてみたのでご共有。
(実は職場で紹介する予定だった)

テーマ

  • Adventures in Refactoring

発表した人

トーク概要

リファクタリングとは

  • 振る舞いやIOを変えずにソースコードを変えること
    ⇒ あたりまえのことだけど機能を変えてはダメ絶対

リファクタリングをする理由

悪い理由の例

  • コードの一貫性を増すこと
  • DRYにこだわること
  • 抽象化レイヤを追加すること
    ⇒これら自体は良いこと。でも、これをやるためにリファクタするというのはよくない
     リファクタリング結果の成否を測定できないから

良い理由

  • Developer がハッピーになること
  • パフォーマンスの向上
  • 将来の作業への自信(技術的負債の返上)
  • Developer の教育
    ⇒これらはリファクタリングの成果が計測しやすい

どのようにリファクタリングするか

計測できること

  • git diff stats でコードが減っている(例:+31 -40だと10行減った)
    ⇒行数が減るということは、エラーが起こりうるコードが減ったということ
  • テストカバレッジの改善
  • パフォーマンスの改善
  • 開発者満足度

スタイルガイドの重要性

  • メンバーの方針をあわせる
  • スタイルガイドも PullReq でメンテナスしていく

具体的なテクニック

  • ”_” でつないでいる長いメソッド名の一部をオブジェクトに切り出す
pull.branch_valid?
pull.branch_exists?
 ↓
pull.branch.valid?
pull.branch.exists?
  • ひとつのクラスからしか継承されていないクラスがある場合はまとめてしまう
  • ツールの導入( for Ruby
    • Backscatter
    • scientist

リファクタリングの落とし穴

  • 既存バグの修正と一緒にリファクタリング
  • 抽象化レイヤの追加によるパフォーマンスの悪化

小さなところからハッピーになる

感想

  • スタイルガイド(規約)の github管理やりたい。PullReq 上でお互いに意見を出し合ってメンテナスできそう。
  • デザインパターンに固執するとコードがテストに合わせがちになる。良いテストは良いコードの結果であるべき " というテストに関するご意見も面白かった。
  • :hocho: は使うようにしたい。

ノンデザイナーズ・デザインブック勉強会(1)

1.ジョシュア・ツリーの悟り

近所にあるジョシュア・ツリーに気付かなかった作者
 ⇒ 問題や原則、ものごとには名前がないと意識することができない

4つの基本原則

4つの基本原則は互いに関連してあっている

2.近接

ロビンの近接の原則

関連する項目をまとめてグループ化する

類似の要素をグループ化して視覚的ユニットを作成
 ⇒ ページが組織化される
 ⇒ 情報をより明確に伝えられる

コントラストとの組み合わせ
 ⇒ 見出しを強調することで、より組織化する

整列との組み合わせ
 ⇒ インデントで余白を操作する

まとめ

  • 知覚的に関連するものは視覚的にも組織化させる
  • 視線の流れを意識する
  • 要素間に均等の空白をつくらない
  • 見出し、小見出し、キャプション、画像などで要素間の関連をつくる

3.整列

ロビンの整列の原則

ページ上のすべてのものを意識的に配置しなければならない

共通の境界線を作成することで、各要素を結びつける
 ⇒ より組織的に情報を伝える
 ⇒ レイアウトに強さを与える

ありがちな中央揃え
 ⇒ 安心感を与えるが、退屈に見えがち
 ⇒ 洗練されたデザインにはあまり使われていない
 ⇒ 中央揃えにひねりを加えることで洗練させることもできる

1ページに1種類の文字揃え
 ⇒ 左揃えの要素と右揃えの要素が関連していればOK
 ⇒ 訓練積んでいる人ならOK

強い線を意識する
 ⇒ 強い線を意識できればそこを基準に全体のレイアウトがくめる
 ⇒ 強い整列が存在すれば”意図的”にくずした要素も入れられる

まとめ

  • 基準となる線で一体化、組織化させる
  • 空間的に離れていても意識的に揃える要素を見つけて配置する
  • 同じページ内で2種類以上の文字揃えを使用しない