やり方は簡単で、タイマーを25分にセットして１つのタスクに取り組み、終わったら5分休憩を取って、また25分かけて１つのタスクに取り組むというのを繰り返す。１つのタスクに取り組みっていうのが重要で、この25分間(これを1Pomodoroと換算するらしい)は、Twitterをしたり、メールの返信をしたりしてはいけない。割り込みやマルチタスクを捨てて、１つのタスクに集中する。これを繰り返すことで、タスクに取り掛かり始めた最初のほうのやる気と、休憩間際にギリギリまで頑張る時間が効果的に利用されて、結果的にタスクが早く終わるという仕組みらしい。

実はRebuild.fm聞く前からポモドーロテクニック自体は知っていて、簡単に始められるからという理由でやってみたこともあったけど、長続きしなかった。そのときは、キッチンタイマーで25分計っていたのだけれど25分ごとにタイマーが鳴るのが煩くて、タイマーをしなくなってしまった。このときの反省を活かして、音は鳴らないけど振動で教えてくれる、スマホアプリのポモドーロタイマーを使っている。

いろいろ試してみたけど、僕が一番良さそうだと思ったのは、充電しながらスマホをキーボードの前において残り時間がすぐ見れるようにしながらタスクに取り掛かる方法。このアプリ立ち上げてると、自動画面ロックが解除される？みたいで途中で暗くなったりしないので快適。

ただ、課金しないと下に広告が出るのでチカチカして気が散る気がするっていうのと、ヘッドホンで音楽流しながら作業してると振動に気づかないときがあるっていうのが問題かな。広告は課金すれば消えるらしくて、そんなに高くはないので気になるなら有料版買ってみても良いかなって思ってる。振動に気づかないのは...スマホを机の上に置いてる限りは仕方無さそう。これこそスマートウォッチを使うべきな気がする。

Pebble Time Roundとか良さそうだよね。

(この文章も1Pomodoroで書かれた)

2015-10-24

Scalaハマりポイント

Scala始めて1ヶ月くらい経つけど、良くわからないことがまだたくさんある。

OptionとEitherってどう使い分けるんや !!

ScalaではOption型とEither型が使えて、どちらも正常値or異常値を入れられるみたいな感じなんだけど、どういうときに使い分けたら良いか分からなかった。

しばらく書いてたら分かってきて、Optionは成功or失敗を表すとき、Eitherは意味が正しいか正しくないかを表すときに使うってことが分かった。

とりあえず何か値を取り出せるかどうかみたいなときはOptionを使うと良くて、取り出した値が正しいか正しくないかみたいな判別をしたいときに、Eitherを使うと良い。

matchにtoRightするのは括弧つけなあかん !!

match式の戻り型は、各caseの共通の親クラスになっているけれど、それに対してメソッド呼びたいときは()で囲う必要がある。例えば、こういうmatch式書いたとする。

foo match {
  case hoge => Some(fuga)
  case piyo => None
}

fooの型がhogeのときはEitherのRightにSome(fuga)を、piyoならEitherのLeftにエラーメッセージを入れて返したくなったときは、こう書く。

(foo match {
  case hoge => Some(foo)
  case piyo => None
}).toRight("error")

matchを囲っている()を忘れるとコンパイルエラーになるので注意

foo match {
  case hoge => Some(foo)
  case piyo => None
}.toRight("error")

matchの内側が部分関数みたいになってて、toRightを括弧を付けずに書くと、この部分関数全体にtoRightすることになる？みたい (良く分かってない) たぶん、forの後のyieldにtoRightとかを括弧無しで書くと同じことになるので、とにかくforとかmatchにtoRightしたいときは括弧つけたほうが良さそう。

2015-10-07

点字ブロックは何故黄色なのか

f:id:yuki_tkd:20151007213416j:plain 写真: フリー写真素材ぱくたそ

大学に向かう途中、駅の点字ブロックを見て疑問に感じたので、調べてみたらすぐに答えが出てきた。

http://www.h-road-s.co.jp/service/texturedpavingblock/tpb05.html

答え

一言で言うと、点字ブロック(視覚障害者誘導用標示)が黄色なのは、「弱視者は視覚障害者誘導用標示の色を見ながら歩くことが多い」からだそうだ。視覚障害者の約７割は弱視者らしく、点字ブロックの色を見ながら歩いていることも多いそうだ。先ほど記載したページに図を交えて分かりやすく解説されているので、詳しい話は見ていただいたほうが僕が説明するよりも良さそう。

気づき

こういう細かいことに気づけるかどうか、理解できているかどうかって大事だと思っていて、自分がもし点字ブロックの設計をすることになったら、どういう点に気をつけて設計するだろうといったことを調べる前に考えてみた。

僕ならこう設計するだろう。

点字ブロックを設置するからには、その点字ブロックをすべての動線に繋ぐ必要がある。街の地面はアスファルトやレンガで出来ているので、点字ブロックをすべて同じ色にすると目立つ箇所が出てくるはずだ。ならば色を変えてアスファルト上では黒色、レンガ上では赤色にしよう。

ただ、こうすると街の景観は良くなるが、点字ブロックの存在に気づかない晴眼者が増えるだろう。点字ブロックの上で立ち止まったり、居座ったりされると点字ブロックの意味が無い。

点字ブロックの上に居座らないような色... その場に立ち止まらないような、危機感を煽る色。警告とかって赤色が多い気がする。緑がOKなら赤はNGっていうイメージは誰もが持っている。よし、点字ブロックは赤色で統一しよう！

たぶんこんな感じになる。が、これは明らかに晴眼者の考えでしか無いし、何よりも前提条件がいつの間にか視覚障害者から全盲の視覚障害者に変わっている。もうちょっと考えたら、色覚障害の人も居るのだから赤とか緑は良くないとか、色々考えるかもしれないが、視覚障害者の多くが色を見ながら点字ブロックを歩くだろうなんて考えは、たぶん出ない。

実際に視覚障害者に聞かないかぎり。

視覚障害者っていうと全盲っていう固定観念を無意識に考えてしまうし、色眼鏡で見てるって気づくのも難しい。良くないと思っていても、そう考えている以上仕方ないし、どうしても自分は中立の立場で考えていると思ってしまうだろう。

点字ブロックの話だけでなく、物事を当事者の視点で考えるのって、本当に難しい。こういうことを考える経験を積めば、違う立場からの見方も出来るようになるのだろうか。

2015-09-29

C言語のユニットテストライブラリPicoUnitを作った

C言語でテスト

僕が通っている大学のソフトウェア演習で、C言語で(BASIC風の)独自言語のコンパイラを作る課題が出た。 1ヶ月おきくらいに進捗のチェックと機能追加があって、それを5回くらい繰り返すと完成するらしい。

今までもソフトウェア演習はあったけど、この課題は今までと違ってテストのテストデータを提出することが必須になっている。

ただ、手動でテストすることを想定しているらしく、ユニットテストを書いてテストするみたいなことではないらしい。手動で確認だと大変だし、カバレッジ下がりそうだし、何よりも僕は機械で出来ることは全部機械に任せる主義なので、手動でテストはナンセンスに感じて仕方無い。

assert()

調べてみたらC言語にはassert()関数というものがあって、それを使うと期待する値と違う結果が渡されたときにConsoleに何かしら表示してくれる。ただ、assert()関数はプログラム内のどこか一度でもテストが失敗すると、その場でexitされてしまう。

まとめて全部をテストした上で落ちたテストを表示してくれる機能が欲しかったので、ライブラリ？マクロ？を書いてみた。 C言語のマクロを使ってプリプロセッサーでテストコードを差し込んで表示するだけのライブラリなので、一つのヘッダファイルだけで動く。

github.com

PerlのProveみたいにしたかったので、結果の出力形式を似せている。使い方は簡単でテストしたいところでpu_test()して、全体のテストが終了するときにpu_print()すれば結果が表示される。

2015-08-29

VimからAtomへの乗り換えを進めてる

趣味のコーディングのときだけ、Atomを使って様子を伺っている。 1年くらい前に、Vimを使い続けるかAtomを使うか悩んだときには、起動速度の差とかパッケージの量とかで、まだまだVimだなぁって考えたんだけど、久々にMarkdownでメモを取る機会があって、Atomを起動したら思いの外良かった。起動速度が早くなってるし、パッケージもだいぶ充実して良さそうなのでAtomに移れないかなと思いながらしばらく使ってみている。

Vimのキーバインドになれてしまっているので、まずVimのキーバインドに設定した。入れてるパッケージはこんな感じ。とにかくVimに近づけようとしている感じがするけど気にしない。

Vim-mode

vim-mode (キーバインドをVim風にしてくれる)
vim-mode-visual-block (vim-modeだけではC-vに対応してないのでvim-modeが対応するまで入れてる)
ex-mode (:w, :qとかに対応)
Sublime-Style-Column-Selection (Sublime text風のマルチカーソルをサポート)

Atom

file-icon (ファイルのアイコンを良い感じにする)
minimap (Sublime text風のマップを表示)
project-maneger (複数プロジェクトを切り替えれるようにする)
regex-railroad-diagram (正規表現を可視化)
term2 (シェルをAtom内で実行できる)
Color-Picker (カラーコードを実際の色で表示してくれる)

Linter系

linter (linter本体)
linter-perl (perl)
linter-jshint (JavaScript)
linter-less (less)
linter-tidy (HTML)
linter-flake8 (Python)

だめなところ

vim-modeの問題なんだけど、insert-modeからnormal-modeへの切り替えをjjに割り当てると、insert-modeで1文字だけのjが入力できなくなってしまう。

jだけを入力することは滅多に無いし今後のアップデートで治るらしいけど、ときどき不便。

それから、Perlのインクルード補完欲しい。今のところ無さそう。自分で書けって話ですね。

起動が遅いのが気になる。普通に使うときは気にならないけど、ターミナル内で開きたかったりするときに重いなぁ...ってなる。

2015-07-29

Perlで、ある配列から順序そのままで別の配列の重複除いた配列を作る

Perlである配列から、順番はそのままで別の配列に含まれる要素を除いたリストを作りたかったけど、すぐ出来なかったのでメモ

例えば、以下のfoo, barが与えられたとき、

foo = (1,2,3,4,5,6)

bar = (1,3,6)

次のようなbazを手に入れたい。

baz = (2,4,5)

簡単なのはfooとbarをハッシュにしてしまって統合することだけど、順番も保証したい。

答え

my @foo = (1,2,3,4,5,6);
my @bar = (1,3,6);
my %bar = map { $_ => 1} @bar;
my @baz = grep { !$bar{ $_ } } @foo;

ポイントは、最終的に重複を消したい方の配列はそのままで、もう一つの配列をハッシュにすること。こうすれば、取り出した要素は元の順になる。

一番最後の行はこれでも行けるはず(未確認)

my @baz = grep { $_ != $bar{ $_ } } @foo;