gorogoroyasu

福岡の開発会社で働いている。

何も考えずに銀歯入れてない?

歯医者で被せ物をした。

 

一般に、被せ物といえば銀歯だ(日本語がおかしいかも)。 笑うと奥の方の歯がシルバーに輝く。それはそれで、嫌いではない。

 

だけど、僕は、白いセラミックスで作られた歯を入れる選択をした。理由は幾つかある。

 

1. 金属を噛んだ時の電流が流れる感じがしないか不安だったから

 

アルミホイルを噛んだ時とかに感じる嫌な感じ。あれが不安だった。噛むたびに嫌な思いをしてたら、食べることが嫌いになってしまうと思う。まあ、大丈夫だとは思うんですけどね。教えて、エロい人!

 

2. 銀歯は、相当枯れた技術であること

 多くのサイトで言及されてるように、銀歯は昔から使われている技術らしい。参考:http://nichigopress.jp/healthcare/healthcare_sodan/29008/

枯れた技術のいいところは、その安定感だ。安定感とは、多くの人がやってるから自分も大丈夫だろうという無責任な安心感のことを指す。でも、銀歯って本当に大丈夫なの?戦後すぐってものが本当に何もなかった頃でしょ?ものをふんだんに使える現在でも、使い続けてる意味って何?そんな疑問を持たずに枯れた技術の侵略を許すのが嫌だった。

 

3. 3Dプリンタを使うって、なんかイマドキっぽいから!

それじゃあ、セラミックスは?要は陶器でしょ?土器を口の中に詰めてるのと何が違うの? まああまり違いはない。でも、3Dプリンタで作るって聞いたら、なんかカッコいいと思ってしまうじゃん!材料を研究してた人として、今回使ったお金が材料研究のお金に使われると嬉しいし、ソフトウェアエンジニアとして、「俺の歯、3Dプリンタで出来てますよ」って言うの、掴みとしてはめっちゃいいと思うし。いいことづくめ!

 

ということで、セラミックスの歯を入れました。理由は全部後付けです。

 

気になるお金の話

正直、お金はかかった。 歯の土台と被せ物で合わせて約6.5万円。かなり高い買い物だ。だけど、いいと思った技術にはお金を払うべきだし、意識改革にも繋がると思うから、高かったとは思ってない。ソニッケアのダイヤモンドクリーンも最近買ったから、歯への投資が最近半端ない。まあ、いい事だと思っておこう。

 

ということで、何も考えずに銀歯を入れるのはどうなの?という話でした。

メール確認ってめんどくさい

メールを送るのって、大変ですよね?

誤字脱字があったら信頼が下がるとか超だるい。

複数の意味に取れる言葉を使うと相手に混乱を与えるけど、自分で読み返しても気づかないことが多いし。

 

そこで考えたのが、メールやドキュメントをチェックするバイトを雇うこと。

 

バイトの人からすると、メールをさらっと読んで分からないところがあったら指摘する、簡単な仕事。逆に、メールを送る人は、無駄な時間を使わなくて済む。メールなんて、即時性はそんなに重要じゃないし。

やりとりをbacklog とかslackにすると、会社に来てもらう必要もない。

これって結構いいアイディアだと思うんだけど、どうですかね?

 

たぶん、メールチェックを外注するのは少し怖いから、バイトの人にやってもらったほうがいいと思うけど。

秘密保持等がうまくできる仕組みができれば、結構流行ると思うんですけどね。そうすると、会社ができたりする。

まあでも、皆が秘密を守ることを前提にしたシステムはいずれ破綻するから、微妙かもな。Twitterとかに社外秘書かれたりしたら損害半端ないし。

来年(今年でも可)の新卒とかに、この仕組みを取り入れてみればいいんじゃないですかね?

実際に社会人が送ってるメールを見る機会なんてそうそうないし、面白いと思うのですが?

対面レビューに参加した話

対面レビューの重要性

僕は、新卒で今の会社に入社した。 ほんの数カ月前まで、全くの未経験だった。

ここ数ヶ月で手取り足取り色々なことを教えて頂き、 本当に楽しい毎日をすごしている。

ところで、今日、同期の対面レビューがあった。 うちの会社のレビューの流れは、
1. コードを書く
2. GitLab で主にチームメートがレビュー
3. 修正する
4. ある程度修正が溜まった段階で、会議室でディスプレイにコードや作ったものを映しながらレビュー

という流れになっている。

僕のレビューは約2週間前にあった。
その時は、結構つっこみが多く、修正するのが大変だった。

そんな思い出もありつつ、今日、同期の対面レビューに参加した。

自分が指摘される側では気づけないことがあると思ったからだ。

そして、気づいたことは、

  • コメントアウトはイラッとする(console.log('hoge');とかも)
  • 適度にスペースを使わないと見づらい
  • 2箇所以上で用いる処理は、メソッドとして切り出す
  • コードレビューはメモを取りながらしてもらう

みたいな感じだ。

コメントアウトはイラッとする

僕も結構コメントアウトを残したままpush してしまうことがある。
だけど、初めてレビューする側に回ってかなり嫌な気持ちになった。
理由は、
- 画面に映せる範囲が限られているので、スクロールしなくてはならなくなる。
- なぜ残っているのかを考えてしまう
だ。他にも何か思った気もするから、思い出したら書く。

適度にスペースを使わないと見づらい

コードを書いているときは、集中しているから、多少見づらくても関係ない。
だが、読む人からすると、少しの見づらさは致命的だ と気づいた。
似たような処理をしている箇所はまとめて、少し毛色が違う処理はスペースを開けるといいと思った。

2箇所以上で用いる処理は、メソッドとして切り出す

これは、同期のコードを見て気づいたことだ。
僕は、2行ぐらいでかけてしまう部分は、わざわざメソッドとして切り出す必要はないと思っていた。
可読性とかあんまり関係ないし。
だが、実際に、メソッドに切り出されたコードを見て、
読みやすいことに気づいた。
これは、即実践しようと思う。

コードレビューはメモを取りながらしてもらう

これは、録音とかでもいいかもしれない。
とりあえず、後で見返せる何かが欲しい。
僕は、コードに直接 // TODO を書いていったが、
TODOは、その箇所を修正したら消してしまう。
見方を変えれば、プロのエンジニアが僕にかけた時間が水の泡になっている。
もちろん、一度言われたことを二度と間違えない人間なら問題無いだろうが、僕は超人ではない。
ということで、今度から対面レビューをしてもらうときはメモを取ろうと思う。

今日学んだことは、こんな感じです。
今日作ってしまった ポンコツAPI の話はまた次回。

ルール

今日は、1ポモドーロ以内!読みなおす時間も少し残っている!素晴らしい!

limit を使うか where を使うか問題

今日学んだこと

$table->find()->limit()

は、使いドコロが肝心ということ。

limit を使うべきなのは、paginate のように、データの内容によらずDBからデータを抽出したい時。 limit を使って条件判定するべきではない。

limit を使うか where を使うか問題

例:

Table名前 : 商品タグ

id tag created
1 売れ筋 2016-07-01
2 期間限定価格 2016-07-08
3 芸能人が着用 2016-07-10
4 新着 2016-07-12

みたいなテーブルを考える

4の新着は、基本的には商品が到着したタイミングでしか使わない。
だから普段見えていて欲しい情報を表示するには、

$table->find()->order(['id' => 'asc'])->limit(3);

というコードを書けば問題ない。

ただ、この書き方が議論になった。

$table->find()->order(['id' => 'asc'])->where(['tag !=' => '新着'] );

と書いたほうがいいという宗教の人が現れたからだ。

この宗教家が!!!と思ったが、
社内で最もDBに詳しいと言われる人に聞いてみたところ、後者の書き方のほうがいいと言われた。

理由は、
1. 新しいtag が追加された時に困る から
2. DBの id は、基本意味がないものとして取り扱うから

というものであった。

理由1 は自明である。
上記のコードでは、レコードが増えた時に対応できない。
さすがに素人に毛が生えた程度の僕でもこんなミスはしない。

では、理由2は?
この理由を考えるにあたって、普段人がどのような気持ちでレコードを取り扱っているかという精神論が大切になる。

気持ちを言語化する。
それは、自然キーという考え方、サロゲートキーという考え方に起因する問題だ。

キーとは?

情報を一意に特定するために用いられる目印のこと。
自然キー、サロゲートキー、複合主キーなどがある。

自然キーとは?

自然に作られたキーのこと。
例えば、人名などがそれにあたる。
人の名前は自然発生的につけられる(と仮定する)が、
同姓同名の人がいなければ、人名で人を一意に特定することができる。
この場合、人名は自然キーの役割を果たしているといえる。
自然キー派の主張

複合主キーとは?

自然キーの派生版のような感じ。 自然キーのところに書いたが、同姓同名の人がいる場合もある。
そのような場合に、もう少し情報を足すことによって人を一意に特定できることがある。 xx さんという同姓同名のひとがいた場合でも、
○○県からお越しの xx さんといえば、人を特定できるという考え方だ。 これを 複合主キーという。

サロゲートキーとは?

フレームワーク等により割り振られる、意味を持たないキーのこと。 1から始まり、被りなく1 ずつ増加していく値が用いられる。
サロゲートキー派の主張

本題

本当に簡単な説明で済ませてしまったが、 上記が自然キーとかサロゲートキーとか言われているものだ。

上記のテーブルの例で用いられているid は、サロゲートキーだ。
すなわち、id の値はフレームワークが勝手に振った値であり、意味が無い。
つまり、 id 4新着2016-07-12 が割り当てられているということには意味が無い。
一方、 新着2016-07-12 が同一レコード内に存在するということには意味がある。

これらを端的に並べると、以下のようになる。

レコードの縦の並び順には意味が無い。  
レコード内のサロゲートキーには意味が無い。  
サロゲートキー以外の値が同一レコードに存在していることには重要な意味がある。

すなわち、

$table->find()->order(['id' => 'asc'])->limit(3);

というコードを書くと、何をしているのかがわからないのだ。
何をしているのかがわからないということは、 勝手に順番を変えられる可能性があったり(そんなことはまずないと思うが)
メンテナンシビリティが下がったり(主な問題はこれだと思う)する可能性があるということだ。

だから、一番上で書いたように、

$table->find()->order(['id' => 'asc'])->limit(3);

と書くよりも、

$table->find()->order(['id' => 'asc'])->where(['tag !=' => '新着'] );

と書くほうがずっといい ということになる。

説明が難しくて、うまく伝わったか不安だが、
少しでも同じことで悩む人が減るといいと願っています。

補足

本文中で何度か縦の並び順には意味が無い と書いたが、実は横の並び順にも意味はない。

意味があるのは、同一レコードの特定のカラムに入った情報だけだ。
ただ、長くなりそうなので続きは次回にしようと思う。

一言

ブログは1ポモドーロと決めていたが、早速ルールを破ってる。

諸言

目的

昨日の夜突発的にはてなブログを開設したので、目的も何もない。 つまり、書くことが何もない。

なので、TIL (Today I Learned ) を書こうと思う。 ダイアリーに書けば? とかはなし。

過去のブログ遍歴

実は今まで過去何度かブログに挫折したことがある。

  • mixi
    大学に入ったばかりで右も左もわからなかった頃。 mixi というのが流行ってると聞いて なるほど! と思って始めた。 最初の1年ぐらいは継続的に更新していたが、 パタリと更新するのをやめてしまった。

  • seesaa アフィリエイトってなんだろう?とか思っていた頃。 ポッドキャスト番組を始めて(50回ぐらい続いた。) けっこう色々な人に見てもらってた頃。 毎日ポッドキャストをするのは正直つらかった。 ポッドキャストの終了と同時に終了。

  • サクラのレンタルサーバ + WordPress 半年ほど前、今の会社に入社する直前に始めた。 ちょこちょこ更新はしていたが、全記事で10個ぐらい。 大学を辞める理由とかを長々と書いた思い出。 たぶん良い文章だったんだろうと思う。 4000の論文を書くのはとても大変なのに、 自分の思いを4000字書くのは超簡単だということに驚いた思い出。 今もネットのどこかに転がっていると思う。 早く契約を解除しないと来年もレンサバ代を払ってしまう。 急ごう。

始めた理由

うっかり口が滑ったから。 この業界では、一部にGithub にTIL を上げるという文化があるらしいが、 僕はそれをやってもうまく続かなかった。 というか、はじめてもいない。

昨日、先輩社員的な人たちとの面談があった。 その時の会話

先輩社員O 「TIL やれば?」
僕 「いやー、一歩が踏み出せなくてー」
僕(心の声) 「絶対いやだ。」

先輩社員O 「そっかー。残念だなー。」
僕  笑顔
僕(心の声) 「この先輩怖いって聞いてるし怒られるかな?」

先輩社員O 「まあでも、TIL なんかよりもブログ書くのが一番なんだけどね。」
僕(心の声) 「ブログならやったことある!楽勝じゃん!」
僕 「じゃあブログ書きます!」

先輩社員O 「あ、言った」
先輩社員S 「よし、聞いた」
先輩社員Y 「OK、メモった」

という感じ。 まあどこまで続くかわからないけど、やってみる。

ルール

  • 25分(1ポモドーロ)で書く
  • MarkDown 記法で書く(今後変更されるかも)
  • プログラミング関係の話は極力Qiita に書く
  • 基本的に今日学んだことを書く -> 書き溜めをしない!

一言

頑張る!

first commit

うっかり口を滑らせてしまったので、ブログを作った。

やると決めたらやる!