「自分の得意な感覚」を知っておくと良い

vakモデル、vak理論など呼ばれる、そのいずれが正式名称かなのかはわからないのですが、そういう考え方があります。あんまり良い資料やページにあたれなかったので、詳しいことは適当にググってください。
ざっくり書くと、vakというのは視覚、聴覚、体感覚のそれぞれの頭文字を取ったものです。人にはそのみっつのうち、ひとつまたはふたつの優位な感覚があり、わたしたちは日々その得意な感覚を主に用いて認知を行っているそうです。
どれが得意でどれが不得手か、というのはその人によるみたいですが、わたしはおそらく「体感覚」派です。

時は遡って3年前、新人研修を受けていたころ、わたしは言葉が出てこなくてうまく話せない、と、講師の方に相談をしたことがあります。研修時間後の立ち話くらいの感覚で、腰を据えて話したわけではないのですが、その時に講師の方から言われたのが「もしかしたらあなたは体感覚なのかもしれない」でした。

視覚、聴覚は高次の感覚であるのに対して、触覚・味覚・嗅覚を含む低次の感覚である体感覚は、言語で表しにくい傾向があるようです。見たものや聴いたものを言い表すよりも自分が感じたことを言い表すほうが難しい気がするので、それはなんとなくわかる。
おそらくわたしは体感覚が優位、サブが視覚、聴覚が劣位です。

で、タイトルに戻る。
これがわかるとなにが良いかというと、まず、考えたり学んだりするときに得意な感覚を使う方が覚えやすい。

体感覚なわたしの場合は、なんでもまずやってみるのが一番早い。
とりあえず、手を使って書く。体感覚は言語化が難しいのですぐ喋りだすのは苦手。視覚情報は比較的頭に入りやすいので、文字や図にするのはGood。聴いたことはすぐ忘れるから絶対に書きとめておく、もしくは復唱する。喋るというのは体感覚だからわりと覚えられる。みっつ聴いても最後のひとつしか覚えてないみたいなことはよくあるから、口頭で言われたことは忘れないように工夫しておかないとダメ。

もうひとつ、うまく仕事するためのコミュニケーションの方法を周りに知ってもらうことができる。
会話ベースの場合、わたしは聴いて理解するのが苦手なので「復唱する」または「自分の言葉で言い換える」ことで理解しやすくなる。ので、よくやるけど、あんまりやりすぎると微妙かなとも思うので、「わたしはこれをすると頭に入るので、うざいかもしれないけど許してください…」と周りの理解を得ておくと仕事が進めやすくなると思う。
ちなみに今自分がこれをやってるかというとあんまりやってないんですけど。これに気づいたころにはもうチームが受け入れてくれていたので。やさしいチームメンバーでよかったなあ

たぶん人に対しても同じように得意な感覚を使えるようなアプローチをしてあげることで理解を促せるようになる、気が、する……。まだそこまではいけないけど。特に春先は人に教えることが増えてくると思うので、意識してみてもいいのかな〜、とか。*1

新人の、とくに自分の興味分野外の社会人研修ってだるいとかってめんどいとかよくわかんなかったみたいなこと結構多かった(すみません)けど、こんなふうに、意外と役立ってるな〜って内容もたまにはあったので、一概にナメてかからずに、一応聴いておくと良いことがあるかもしれないね、って思います。

*1:念のため記しておきますが、これは新人教育をしたいと言っているわけでは、決して、決して!ありませんので、上司各位におかれましては誤解なさらずによろしくお願いいたします。

わからないの理由

アホの子を教えるのは楽しかった、という増田の記事を読んだ。勉強のできない子が抱えている、放置されたままの些細なつまづきを取り除いてあげられる先生の話。はてブホッテントリに入っているので興味があればすぐ見つかると思います。
追記でかつて本人が九九を覚えていなかった話をしていて、それを読んで思い出した話。自分が似たようなつまづきをして、英語ができなかったこと。

ずっと学校の成績はわりと良い方だったので深刻にできない子というわけではなかったのだけど、中学に上がって始まった英語が苦手だった。90点以上がアタリマエだったはずの学校のテストで、中1の秋頃には英語は60点程度しか取れなくなっていた。
上はいなくても下はたくさんいるド田舎の公立中学校、なまじ勉強ができる分つまづいてることは外からはわかりにくく、ごまかしがきくから、先生から問題視されることはない。つまづきを解消できないまま授業のカリキュラムは進んでいって、そのつまづきの負債は次第に膨れ上がって、どんどん大きくなっていく。
増田を読んでふと自分に重ねて思い出したのはこういうところだった。当時、わたしはbe動詞がわからないまま中学2年生になろうとしていた。

親は英語の塾に通わせてくれた。ちょうど友達の家の近所に外国人の先生がやっている個人塾があったので、友達に連れられる形で通わせてもらうようになったのだと思う。
ド田舎なので、外国人の存在自体とても珍しかった。個人塾なので少し広めの自宅の一室を教室として使っていた。いいにおいがする綺麗なお家。白いモジャモジャ髭のおじさん先生は、最初、少しだけ怖かった。
そこで薄いワーク本を1冊とホワイトボードを使い、友達とたったふたりのごまかしのきかない教室で、ゆっくりと最初から勉強をやり直した。

そこから中学の終わりまで一杯、わかったふりでごまかしきれない授業を受けた。やり直しの過程でわかったのは、単語の意味は暗記できても、文法というものが理解できていなかったということ。S,V,O,C。特にOとC、その区別はずっと難しかった記憶がある。
本ばかり読む子だったのに、不思議なものだけど、たぶんあの頃は日本語の文法だって理解していなかった。文のつくりかたに理屈があることを知らなくても日本語は読めるし、物語を感じることはできた。それまで困らなかったらしい。

そういうわけで塾に通ってやり直していくうちに、文法をちゃんと理解し、授業にも追いつけるようになり、高校に入ってからは国語と英語が一番得意(ド文系!)になった。ゴミのような点数の数学と理科をひっさげつつも大学合格できたことを思うと、あのとき英語ができるようになってほんとうに良かった。

わかったふりで本質的な理解をしないまま進んでいくと後からしんどくなることを忘れずにいたいし、もし人がそうなっていたらそのつまづきに気づいてあげられると最高。教える側としても教わる側としてもいろいろ考えさせられる話。

今思えば、理屈のわからないものをそのまま飲み込むのが昔からすごく苦手だった。
まぁ結局、高校化学のmolでつまづいて赤点ギリギリの低空飛行だし、数学は微積以降なにもできなかった(ただ数学は受験にどうしても必要だったので、理屈がわからないまま仕方なく解き方の型だけ叩き込んだ記憶がある)。「理屈がわからないけどそのとおりにする」は未だに苦手だ。

この流れで思い出したのでvakモデルの話とかしたい。
またこんど

自由に生きるのに必要な名前

いくつ名前があるのかと問われ、彼は「自由に生きるのに必要なだけ」と答えた。

映画「ハウルの動く城」でソフィーの問いかけに答えるハウル
元々児童文学育ちなので原作小説の「魔法使いハウルと火の悪魔」が好きで、大きくストーリー改変されてしまった劇場版に思うことがないわけではないけれど、劇場版ハウルのこの台詞は好きでずっと覚えている。
児童文学における名前の扱いといえば、ハリー・ポッターの「名前を呼んではいけないあの人」や、バーティミアスの魔術師は本名を呼ばれると魔術を無効化される世界観も思い出せる。名前に対するわたしの考え方は小中学生のころに読んだ児童書、海外のファンタジー小説によって育まれたのだと思う。

名前は存在を、キャラクターを縛る。
たとえば会話をするとき、大抵の場合はすぐ目の前に聞いてくれる人がいて、口に出した瞬間にその言葉は自分自身と強く結びつく。その積み重ねによってこう考え、こう話し、こう振る舞う、「この人はこういう人である」と理解していく。その理解した形を扱うための識別子が名前である。
ハリー・ポッターの世界の魔法使いたちはヴォルデモートの名前を呼ばないことでその存在に対する理解を放棄した。バーティミアスという悪魔に本名を知られた魔術師ナサニエルは、自らのしもべとして召喚した悪魔に対する支配力を失ってしまう。魔法とファンタジーの世界において、名前は存在そのものを理解するための最も簡単な手がかりになる。
だからこそ、もし名前を変えることができるならそれはつまり、別の存在になれるということだ。
ハウルは「魔術師ジェンキン」「魔法使いペンドラゴン」「恐怖のハウル」そして「ハウエル・ジェンキンス」の名前を持った。作中で、その理由は身元を隠すためだと語られている。とかげのしっぽのように、名前を自分から切り離すことで、いつでも逃げられるように。

社会に生きるわたしたちがハウルのように「自由に生きるのに必要なだけ」の名前を持つことは難しいけれど、インターネット上においては、こうしてリアルな自分自身と一対一ではない「わたしではない個人」の名前を持つことも簡単にできる。
だからこの場所は居心地が良い。誰でもない個人として認知され、自分自身のある側面を縛られることなく表現することができる。

いま人がインターネット上で持つアカウントの数は、それがその人にとって「自由に生きるのに必要なだけ」の名前の数なのだと思う。

Sinatra + ActiveRecordでアプリ作るよ

社内勉強会でSinatra + ActiveRecord + vue.jsのタスク管理アプリを作っているので、そこで困ったことのメモ。
今回はSinatra + ActiveRecordのサーバサイド。

qiita.com

このページを参考につくる。

SQLite3::CantOpenException: unable to open database file

$ bundle exec rake db:migrate
rake aborted!
SQLite3::CantOpenException: unable to open database file
...

DBのファイルが開けない。
ぐぐったらファイルやディレクトリのパーミッション周りが怪しいとあったので変えてみるも通らない。
パスの指定がおかしいのかな?と疑い出す。

berofe models/todo.rb

ActiveRecord::Base.establish_connection('sqlite3:///todo.db')
class Todo < ActiveRecord::Base
end

after models/todo.rb

ActiveRecord::Base.establish_connection(
  adapter: 'sqlite3',
  database: 'todo.db'
)
class Todo < ActiveRecord::Base
end

establish_connectionはハッシュで書く方法とURLで書く方法がある。
establish_connection (ActiveRecord::Base) - APIdock

DBのファイル作成

$ sqlite3 todo.db

このあたりをやってみたらふと成功。

$ bundle exec rake db:migrate
== 20180201054009 CreateTodos: migrating ======================================
-- create_table(:todos)
   -> 0.0021s
== 20180201054009 CreateTodos: migrated (0.0022s) =============================

書き方変えたからなのか、DBファイルを事前に作っておかなきゃいけないのか…。
理由がわからなかったのでまた今度試してみる。

Encoding::UndefinedConversionError - "\xE7" from ASCII-8BIT to UTF-8:

sinatraのほう
文字コードの変換に失敗。paramsで受け取った値に文字コード指定すると直る。

str.force_encoding('utf-8')

でOK
force_encoding (String) - Rubyリファレンス
パラメータ受け取った時に毎回これやるのはどうなのっていう話はある。うーん

When assigning attributes, you must pass a hash as an argument

これもsinatra

エラーメッセージをちゃんと読むとハッシュで渡すようにと言っているので、変更する

todo = Todo.new(params[:name])

todo = Todo.new(name: params[:name])

エラーメッセージをぐぐるとこういう記事が出てくるので、時勢に乗り遅れていた説…
rails5.2への準備を整える - Qiita

Automatorで自動化する

「PDFファイルを一ページずつ画像ファイルに変換」
「画像のファイル名はプレフィックス+ページ番号にする」
みたいなことがやりたいときに使ったAutomatorのめも。

macOSにはAutomatorっていうめっちゃ便利なアプリがある。
ワークフローを作れるアプリらしいです。
みんな知ってましたか?わたしはこれを作るまで知りませんでした。

確か前はシェルでなんとかしてたんですが、用途的にinとoutのファイルやディレクトリの指定やらprefixの文字やら毎回変えたいというのもあり、Automator使ってみたら使いやすかった。
GUIって便利だなあと思いました

つかいかた

やりたいことを書き出す
今回はこんなかんじ

f:id:eri-twin:20180221234848p:plain

この最後の連番付きの名前にする設定がけっこう融通きく。
プレフィックスを前後どっちにつけるか、始まりの番号、区切り記号とか指定できる。
桁数指定しておくと0埋めしてくれるのがかなり良いかんじです。

で。これを実行すると

f:id:eri-twin:20180221235013p:plain

こうなる
わーい

たまにしか使わないんだけど、めっちゃ便利。
左のほうにアクションがずらずら並んでてかなり種類がある。今回の用途であればシェルでも全然できると思うんだけど、アプリの操作がいろいろできて、office系も強いので使い所によってはつよそう
自動化の選択肢の一つとして頭に入れておけたらいいなとおもいます

以上
たまにはコード書いてプログラマらしさを見せていきたい

エンジニアでよかったな

注意力がない。
最近なんとか普通に働いてるけど、逆にこれまでどう生きてきたのか?と思う。

3つ指摘されたら最後の1つしか覚えてないとかよくある。
先日もレビューの指摘コメントをなぜか見逃して2回言われてやっと気づいたりとか
んん
普通に働けていない気がしてきたんですけどね

社内チャットのタスク機能が弱くて、期限切れてもなにもしてくれないので困る!っていう話をしたらチームメンバーが通知ツールを作ってくれて、まあ、自分でつくってないんですけど、こういう解決法を取れるというだけでエンジニアでよかったなと思った。
そもそも土壌として意識じゃなくて仕組みでミスを防ごうという考え方があるのめっちゃよかった〜って感じる。

これがほしい!って言うのが一番得意(めんどくさいひとだ)
ツール作るのは好きだからもっと手が早くなりたい!

納期を見間違える

プライベートで、ものを作って納期までに提出するようなことをやっています。
もう2年くらいやってるのでだいぶ慣れてきたはずなのですが今回「納期を見間違える」という重大なインシデントを発生させてしまったためふりかえりをしたいと思います。
(ちなみに早めに間違えた方なので納期という意味ではセーフ。ただ勘違いしたまま作業したことでいろんな人に影響が出たので)

まあ単純に納期の日付を見間違えたのが原因なのですが

  • 普段であれば数人チームでやっているため、他メンバーへの作業依頼の際に必ず確認している
  • しかし今回は個人作業だったため最初の一度しか確認するタイミングがなかった
    • 最初の一度確認した以降は、その際に入力したgoogleカレンダーで確認していたため見直すことがなかった

うーん。見直すくらいしかTryが出ない。
でも見直すという作業は実際必要だった
個人作業だと、どこかでこれはこう!って思い込んで進めてしまってると気づけない
ていうか思い込みが強いから一人でよくやってるけど
仕事でも仕様書→設計→実装→評価のどこかで取り違えが発生してるというのは普通にありそう。
サービス仕様書に対するST仕様、詳細設計に対するFT仕様がちゃんと対応してるかどうかとか
人が仕様こうです、って言ってそれでふーんてなる時あるけど仕様書は見よう OK

それにしたってミスったことに対する気持ちのダメージが大きい……
昨日までだと思ってたから時間捻出してがんばってきたのに……はあ…………寝よう