間違えがちな ActionView::Helpers についてRDocを見た

RailsのViewを書いていて、formのhelperを使おうとしたとき、styleを当てたいためにclassを指定しようとした時に書き方をよく間違える。

# classは適用されない。
<%= f.select :book_id, Book.all.collect { |b| b.title, b.id ] }, { class: 'form-control' } %>

正しくはこうだ。

# classは適用される。
<%= f.select :book_id, Book.all.collect { |b| b.title, b.id ] }, {}, { class: 'form-control' } %>

毎回あんまりにも間違えるので改めてRDocを参照した。なるほど、自分は機能的optionsを書くべきところにhtml_optionsを突っ込もうとしていた。

select(method, choices = nil, options = {}, html_options = {}, &block)

https://api.rubyonrails.org/classes/ActionView/Helpers/FormBuilder.html#method-i-select

これまで実務ベースで色々覚えてきてしまったので基本的なところがごっそり抜けている傾向がある。 適宜立ち返ってドキュメント参照しないといけないなと痛感した。

よくあるVLOOKUP失敗パターン

自社サービス開発保守者 兼 情シス 兼 何でも屋さんとしてよく相談を受けるケースとして、SpreadSheet(Excel) で思うような結果が出ないというものがある。 あるあるとしてVLOOKUPがうまくいかないケースがある。 経験則になるけども、これで困っている人はだいたい3パターンのいずれかをチェックすれば解決する。

参考: VLOOKUP - ドキュメント エディタ ヘルプ

構文:

VLOOKUP(検索キー, 範囲, 番号, [並べ替え済み])

パターン1: 検索キーのある列を範囲の先頭にしていない

参考のヘルプの言う通り、範囲の先頭列に検索キーのある列を置かなければならない。

検索キー - 検索する値です（例: 42、"ネコ"、I24）。

範囲 - 検索対象の範囲です。範囲の先頭列で検索キーとして指定したキーを検索します。

ID / ユニーク名 / ... とデータが並んでいるケースで、ユニーク名で調べたいのにID値を先頭にして範囲指定をしてしまうとうまくデータが引けない。

パターン2: 番号の指定がずれている

番号の指定は範囲に含まれる列の左から何番目か、という数値になる。これの使い方をシート全体の左から数えて何番目と覚えていると、範囲がシートの左端から始まっていない場合に誤認するケースがある。

パターン3: [並べ替え済み] にfalseに指定していない

並べ替え済みを TRUE に指定するか省略し、範囲の先頭列が並べ替え順でない場合、間違った値が返されることがあります。

と、ヘルプにある通り、[並べ替え済み]がfalseでない場合、検索キー列を並べ替えしておかないと想定通りのデータが引けない。 省略時、[並べ替え済み] は既定値のtrueなので、並べ替えを意識していない表に対してVLOOKUPを行うときはfalse指定は必須といえる。 指定していなくても結果は表示されてしまうので、あんまり意識していない人は意図しない結果が出ていても気づかないケースもあるのではと思う。

なぜtrueだとうまくいかないのか を覚えておく

ヘルプを参照しながら説明した時、そういえばなぜ未並び替えでtrueだと違った値が引けてしまうのかを知らないことに気づいた。ヘルプには流石にアルゴリズムの解説までは載っていない。軽くググったところどうやら二分探索を行っているらしい。

次、VLOOKUPの説明*1をするときのために具体例を検討してみたい。 10件のデータから一致するものを探すことを考えるとする。そして、欲しいデータは8番目に存在するとする。

[並べ替え済み]をfalseにすると、上から順に地道に調べていく(線形検索)。 そのため欲しいデータを見つけるためには8回確認処理をしなければならない。

[並べ替え済み]をtrueにすると、データを半分に割りながら調べていく(二分探索)。 並べ替え済みならば、途中をすっ飛ばして中央を調べても、目的のデータが中央より前方/後方のどちらにあるかを絞り込める。 割ったところの数が探している値より大きければ発見したとみなす。この方法だと探すための処理がぐっと少ない回数(例では2回)で済む。なので速い。

代わりに、並び替えていない場合は値がより大きいものを見つけたときに処理を終えてしまうので、意図通りの結果が得られない。

使いどころが肝心

大量のデータに対してVLOOKUPを使う場合、処理速度に問題があるようであれば検索範囲をちゃんと並び替えして、[並べ替え済み]にtrueを割り当てるのがよりよい方法と言える。単純にfalseを指定しないと、と決めてかかるよりはこういう使い分けが思い浮かぶほうがいざという時いいだろう。 今後なにかレクチャーする機会があったら補足していこう。

サマリ

ヘルプ最高なのでしっかり読もう！

*1:説明相手は特にアルゴリズムとかは知らない人を想定しているので超ざっくりです

作業時間確保機能としての帽子を導入した

エンジニアチーム(n=1)

現在自分は正社員1桁人数の超小規模ベンチャーにエンジニアという肩書きで勤めている。そして現在エンジニア的業務が可能な人間は自分ひとり*1である。よく代表氏は「エンジニアチーム」という表現を使ってくれるが残念ながら現時点でそれは自分ひとりのことを指す。言われるたびにちょっと面白いなと思っている*2。また、他のメンバーもそれぞれ自分の攻守領域を懸命に担当しているので仕事の大変さはみんな一緒である。

問題: 気づいたらプログラミングやってない説

「エンジニアチーム」に課せられている業務として、メインはサービス保守運営開発なのだが、なにせぼっちなので会社として必要な色々な仕事が降ってくる。新しくジョインしてくれたチームメンバーのPCを見繕ったり、Excelの数式のおかしい点を指摘したり、ツールのトラブルの解決に奔走したりしている。もっと大きな規模の会社さんでは情報システム部門が担当しているところ？なのだろうか。こういった対応も重要なので基本的には即応即解決するようにしているが、それを続けていた結果、メインのサービス開発業務に着手できない日もしばしばある。

振り返りでの指摘

チーム全体のサポートをすることで全体の生産性があがるのは良いことと思っている。しかしこのままメイン作業が延々とリスケされ続けるのも自分の存在意義としてまずい。そう思っていた矢先、全体会にて他メンバーから良い指摘をもらえた。

いつ声をかけていいかわかりづらい。お願いするものとしては後でいいものがあるので、集中しているときはそう言ってもらえれば緊急度の低いものは後回しにできる。

いままで緊急度の高い低いにかかわらずタスクを拾ってきたが、そろそろリスケの具合もまずいので、集中している時は細かい話は後にしてもらうというのは良い解決策かもしれない。

とはいえ、よくありがちな両耳をイヤホンで塞いで声をかけようと思ったけどやっぱり聞こえてなくて声かけた側がきまずい思いをしたりするケースや、集中を乱されて嫌な顔を無意識にしてしまうケースは避けていきたい。一応集中予定時間を社内で運用しているGoogleカレンダーに入れるつもりだが、もっとオフィスの中でパッと見でわかるサインが欲しいと思った。

再発防止策としての帽子(効果測定中)

ふと、クローゼットに置いてある帽子について閃いた。昔にすごく素敵だと思って買ったけど自分のオシャレ度が低いために持て余してしまっていたものである。こいつを活用する時がきたのではないか。

数時間やってみたところ、集中のON/OFFのスイッチとしても使えるし、他のメンバーから見たときにわかりやすいので良さそうなのではという気がしてきた。

色が黒いのと椅子と自分の髪の毛も黒いのでちょっと視認性が悪いのが難点なので、運用自体が問題なさそうならもう少し派手なやつにするかもしれない。

*1:一応、いつ何があって死んでもいいように信頼のあるフリーランスの方に諸々お任せできる体制は整えてあるが、メインで稼働しているのは自分だけという意味。

*2:もちろん増やしたいとも思っていて、増やしたいからこそブログを始めてみた。何卒よろしくお願いします。

再発防止策とSlack reminder

やらかしとそれに対する姿勢

何かをやらかしてしまったとき、では次気をつけます、では十中八九それは再発する。 何かしら気持ちで気をつける以外の仕組みがないと、人間は忘れたり注意散漫になる生き物なので、なにかしら対応しないといけない。 気持ちドリブンは信用できないということをこれまで何度も痛感してきた。

Slackはいいぞ

自分が最近よく会社でやっているのはreminderの設定である。さっとできるし、システムは人間と違って忘れっぽくなることもない。 過去に何回かやらかした経験上、弊社のSlack botは次のリマインドをしつこくしてくれる。

• 出勤、退勤ボタンを押したか
• 郵便受けをチェックしたか
• 観葉植物に水をあげたのか
• 月末月初の対応について実施したか

何をやらかしたのかは推して知るべしである。

簡単な割に再発防止策としてはかなり効果を上げているように感じるので、引き続き「次回からは気をつけます」は禁句にして対応策を細かく講じていきたい。

日付ドリブンのやり方

今度しましょうの「今度」はなかなか来ない

「今度こうしましょう！」「いいですねそうしましょう！」というやりとりがよくあると思うが、この会話で終わってしまった事柄に関して、事態が進捗した試しはあまりない。 楽しみにしている飲み会など、ふわっと消えていきそうで悲しくなったときは「ではいつにしましょうか？」を投げかけるようにしている。 ついでに日付系はいわゆる決めの問題というやつなので、自分が都合の良い日時を2~3個あげて、その中で相手に選んでもらうとスムーズに進むことが多い。 ここまでやってなかなか決まらないときはご縁がなかったというやつかなと思って諦めるときもある。

認識誤解にも気をつける

相手と自分の予定をブロックしたところで、ごく稀に次のような認識誤解が発生する場合もある。

• 日付で空いてると思っていたけど実は曜日ベースで予定が入っていた
• いくつか出ていた時間候補の中で決定された項目を勘違い
• 月末月初の予定で1ヶ月勘違い（"今月の"20日 <-> "来月の"20日）

そういった行き違いでの予定の爆発四散を防ぐため、決まったら次のフォーマットで復唱するようにしている。 「m月d日(曜日)のh時〜 よろしくお願いします！」

個人でも日付ドリブン

人対人のやりとりでもそうだが、自分個人のタスクベースでも日付を決めないと永遠にリスケされてなかなか着手されないことがある。ある日火を噴くまで見捨て続けてしまわないように、何日に手をつけると決めてしまうようにしている。 それでも優先順位によっては延々繰り下げられることもあるが、次に何日に決めるということを再度決めることで、どこかのタイミングで消化されるようにしている。

三日坊主の挑戦

初心表明

自分はいわゆる三日坊主というやつで、あらゆることが思うように続けられない。
しかし、勤めているスタートアップがいよいよ第2次創業期とも言えるフェーズを迎えてきている。ぼっちエンジニアで厳しいとかぶつぶつ言っているだけでなく行動しないとやばいという危機感を持ち始めた。

最近あらゆるシーンで「とにかくアウトプットだ」という言葉を再三聞くようになってきたので「よろしいとにかくアウトプットだ」という気持ちでいま書いてみている。

きっかけ

ohbarye.hatenablog.jp 

konifar.hatenablog.com

めちゃくちゃ感銘を受けた。くじけそうになったらまた読む。
長期的目標は弊社にエンジニアという肩書きをもつメンバーを増やすことである。

どう対処するか

とはいえただ初めてもまたやめてしまうと思うので、いくつか自分を楽にする対策を導入した状態で開始する。仮の再発防止策なので問題があれば適宜見直す。

• 技術的話に縛ると一気にしんどくなるので、どうでもいい日常話でもよしとする。
• むしろ技術的話はもっとすごい人がやってくれるので、ぼっちエンジニアとして感じているよもやま話をメインに据える。
• 開始前に7日間やってみて、下書きを貯めることが成功してから開始する。

開始にあたって

とりあえずタイトルだけは10件程度貯め込めたのでやってみる。今週終わったくらいから地獄かもしれない。しまっていこう。