Zanmemo

by esehara

RSS

New Memo

いい言語が必ずしも好きな言語であるとは限らない


考えてみれば、前提として「いい言語」が「好きな言語」みたいな風潮があるけれども、決してそういうことでない感じもする。

好きな言語

良い言語


一つの仮説としては、良い言語と思わせる部分としては一貫性があるということに尽きると思う。例えばRubyは基本的にはオブジェクト指向を崩そうとしない部分がある。それは同じようなスクリプト言語であるところのPythonと比較すればわかりやすい。Pythonの場合、どうしても突貫的なオブジェクト指向という側面は避けられない。


場合によっては、一貫性があることと簡潔であるかということはまた別問題のような気がする。本来、一貫性があるということは、ルールができるだけ一意に決まるため、簡潔になる側面がある筈なのだが、どうもそうではない部分も多い気がする。


Random Pickup

Qiitaでgemが公開されたときに修正した話


Qiitaでとあるgemが公開されたときに、ソースを一読して、ちょっとアイデアがあったのでPull Requestするために改造をしていたら、割とエラーハンドリングが上手くいっていない感じだったので、その辺を整えてPull Requestした。

もちろん、エラーハンドリング自体をちゃんとやる必要は多くの場合あるのだけれど、そもそもそのパッケージのアイデア自体が刺さるかどうかというのがわからないといけない。

そういう意味では「とりあえず作ってみてアイデアが刺さるかどうか調べる→アイデアが刺さった上で、周辺のパッケージのエラーハンドリング等の完成度を高める」というような動きというのは、案外いいのではないかと思ったりした。


受動的攻撃性

この言葉を知ったのは割と前なんだけど、自分に当てはまるので、あまりにもドキッとしてしまい、以降結構気をつけている。Wikipediaの項目を見ると下のような感じである。

いやなこと、やりたくないことに対して、「いやだ」「やりたくない」と言うかわりに、わざとゆっくりやったり、忘れたふりをしたり、いわば後ろに引くことで反抗する。不機嫌な気持ちになると受け身的なやりかたで攻撃感情を表現し、あてつけや抵抗を示すために、対人関係に広く支障をきたしてしまう


自己診断的に

要するにはっきりと「否定」とか「嫌悪」を表明するのが苦手で、それ故に、それを「曲がりくねった形」で表明してしまう。


いい言語が必ずしも好きな言語であるとは限らない


考えてみれば、前提として「いい言語」が「好きな言語」みたいな風潮があるけれども、決してそういうことでない感じもする。

好きな言語

良い言語


一つの仮説としては、良い言語と思わせる部分としては一貫性があるということに尽きると思う。例えばRubyは基本的にはオブジェクト指向を崩そうとしない部分がある。それは同じようなスクリプト言語であるところのPythonと比較すればわかりやすい。Pythonの場合、どうしても突貫的なオブジェクト指向という側面は避けられない。


場合によっては、一貫性があることと簡潔であるかということはまた別問題のような気がする。本来、一貫性があるということは、ルールができるだけ一意に決まるため、簡潔になる側面がある筈なのだが、どうもそうではない部分も多い気がする。


その仕事にとって「優秀な人」というのはなんだろう

優れたエンジニアを採用できないワケ」を読んでいて、少々冷汗を書いたりしていた。以下はその理由だ。

傲慢さやだらしなさ、細かいことに対する注意力の欠如などは、すぐに目に付きます。それらに気付いた場合、採用は見送ったほうが賢明でしょう。

ここはモロに当てはまるのだけれど、同様に、「優秀さ」ということについて、深く考えさせられる。技術者にとって「優秀さ」といった場合、「技術的な解決方法に長けている人」であったり、「チームで開発する上において、足並み揃えて仕事が出来る」であったり、あるいは「その物事に対して深く精通している」という意味であるかもしれない。これら三つについて、どれに焦点を絞るのか、ということについて混乱がある気がする。

上の記事は、「自分たちが欲しい人材」、つまり「僕達にとって優秀さということはこういうことですよ」という意味での価値だと思うし、それを提示するのは正しい一方で、多くの人々にとって、そもそも「自分たちにとって優秀なエンジニアとはなにか」ということを具体化せずに「優秀さ」という曖昧な概念を考えているというのがアレなのかもしれないな、とは思う。

とはいえ

何度も面接を落ちている自分がこういうことを書くのは滑稽なのかもしれない。


プレビューナイトやってみたい


この「Zanmemo」にも、形だけのMarkdownプレビューをつけてみたのだが、意外と「なんか変だな」って思ったりもする。


プレビューの表示の仕方には、こういった両者を並列するタイプと、タブで切り替えるタイプがある。どっちがいいかは難しい。

確かに、リアルタイムで平行しながら、文字を打てるというのはとてもありがたい一方で、しかしこういうメモを書く人なんて言うのは、既に頭の中でMarkdownの記法を組み立てていて、だとするとDomのrenderが結構重い問題とかを考えると、そもそもプレビューなんて並列されてもうざったくて仕方ないので、自信のないところだけプレビューすればいいじゃんというのは、割と正当なことだと思う。他の人がどう考えているのか、割と知りたい感じだ。


自分で使うと改善がはかどる一方で、ソースが目に付かなくなる

なんとか毎日、思いつくところであったり、目につくところを考えながらアップデートしている。

自分で使うと改善が進むのでいいのだけれど、とはいえ従来の怠け癖のためか、じゃあリファクタリングしようか、とかそういう部分に関しては「動いているからいいじゃないの」という感じになってしまうのは良くない気がしている。

そういうことを考えると、そもそもリファクタリングという行動自体が、何らかの強いモチベーションとなっているのだな、ということに気がつかされる。人間は、元々ブロックをAからBに動かすのも面倒くさいという場合もあるのだと思う。

汚さと未熟さ

基本的に、汚く書くのは簡単だ。それは「速さの面」からも言えるけれども、「未熟さの面」からも言えるような気がしている。例えば、自分はRails 4で始めてCoffeeScriptに触った。

もちろん、CoffeeScriptの熟練度なんて無しに近いわけだから、当然のことながら汚い感じになってしまっている。もちろん、CoffeeScriptなんてそんなに書いていないわけだから、汚いということがどういうことなのか、という問題があるが、「たぶんこういう筈じゃないんだよな」というのは、直感として解る。

別段、綺麗に書けというわけではなく、「そこそこに見られるコードを書く」というのは、熟練度の問題でもあるなあということに気がつかされた。そもそも、熟練したら「読めなくはないコード」は書けても、汚いコードは書けなくなる。料理人のまかないがそこそこおいしいのと一緒で、「なんかこんな筈じゃない」と思ったら、少し見直す必要があるのかもしれない。