てすと

たかろぐ

自分のログを刻みます。

ここ数日死んでいた

最近溜め込んでいた色々なストレスが臨界点に達したのか、先日ついにその症状が表面に出てきてしまったみたいで、ここ数日間大変でした。 いわゆる鬱っぽいものですね。

症状は色々ありましたが、明らかに初めての感覚だったし、「あっ、これ本当にヤバいやつだ」って危機感も覚えました。

発症のトリガーは自己嫌悪ループで、常に意識が自分自身の方に向いてしまうので、何やっても効率が悪いしやる気も減衰するしで良い事が無かった。 自分に厳しい方が良いと思っていて常に反省していたけど、こうなるならもう少しスタンス変えないとマズイですね。

もしかしたら、これ読んでいる人は「コイツ大丈夫か」って感じると思うんですけど、最初に比べれば、良くなってきましたね。 また走り出してくぞ!!

腹痛+気持ち悪い+眠気

朝目が覚めると、いきなり腹痛+気持ち悪さ+眠気の3連コンボを食らわせられて大変だった。 午後には治ったけど、アレはなんだったんだろう...(苦笑)

体調管理、大事

ということで最近、JavaScriptの勉強ということで問題を解いたりもしています。

今日はnpmのモジュールロードについての学び。

nodeを使って開発する時、npmyarnで外部ライブラリを管理すると思います。 その時インストールされたライブラリはnode_modulesというディレクトリ内に保管されるというのは知られた話で、 実際にモジュールをロードしたい時は、require文やimport文を使って読み込みます。

僕は、その時の内部動作を詳しく知らずに使っていたので、今日はその内部動作を知ることができたのが今日の収穫です。

参考として、日本語ページと公式ページの両方載せておきます。

詳細は参考リンクを見て欲しいのですが、node_modules/以下にrequire等で指定したモジュール名が見つかった時以下のように読み込みを行うそうです。

  1. モジュールを展開してpackage.jsonを探す。見つかればそのmainプロパティ先のファイルを読み込んで返す
  2. package.jsonが無ければindex.jsを探す。見つかればそれを読み込んで返す
  3. index.jsが無ければindex.nodeを探す。見つかればそれを読み込んで返す
  4. index.nodeも無ければエラーを吐く

という流れらしいですね。 (漠然とやってたら、なかなか知る機会無さそう...)

サービスの質を高めるって大変ですね

今日は、今携わっているプロジェクトを進めた。

そこで最近感じているのは、「人に使ってもらえるレベルまで質を高める」ことの難しさです。 といっても、まだ仮で置いたりしている所があるので、まだまだこれからって感じなんですが...。

多分、より良いUXを提供するに当たって、この過程はすごく大事なんじゃないかなと漠然と思っていますが、どうなんでしょうね...。 分かりやすい例でいうと、ページの表示速度なんかがそうだと思います。コンマ数秒違うだけで、ユーザの印象は変わるとよく聞きますし。

まぁ、そういうのも大事だけど、今の優先順位はより速く質の高いコードを生み出すメソッドを身に付ける方が高いかな。

道具の選定

プログラムで何かを実現する時、その方法は1通りではありません。 でも、最終的な実装は1つになると思います。

例えば、JavaScriptで「重複の無い集合を求めたい」とします。 そのためには、少なくとも次の2つの方法が考えられます。

  • ES2015から導入されたSetを使う
  • 配列として要素を保持して、lodashのuniqメソッドを使う

自分は、「わざわざSetが新しく導入されたんだし、必ずSetを使うべき理由があって、それを使うべきなのでは?」と思いました。

でも今日、逆に「Setを使わないポリシーを持っている」旨の意見を聞いて、かなり衝撃を受けました。 JavaScriptのSetが持つ機能の利便性と、Set導入によるコーディングスタイルの乱れを天秤に掛けた結果だと思います。

これについては納得で、確かにドキュメントを見るとSetの機能は少なく感じるし、同じことを実現しているのにその方法が乱立していると保守しにくいというのも理解できました。

なるほどなぁと思いつつ、道具の選定の判断基準は上に挙げた2つだけでなく、プロダクトの特徴によっても変わるかもしれないので、 視点が変われば「Setを使うべき」という結果になるかもしれないとも思っています。

まず実現したいことと特徴を考えて、そのためにはどこまで機能があれば足りるのか最も大事な要素は何なのかをしっかり考えていけるようになりたいですね。

グローバルオブジェクト

相変わらずjsの勉強。

ブラウザのコンソールで簡単に始められるのに、奥が深い。

今日はグローバルオブジェクトを少し見た。

グローバルオブジェクトは1つのプロセスにつき1つ存在する特別なオブジェクトで、 この中にはバージョン情報や、OS情報、環境変数などの情報が全て入っていて、プログラムのどこからでもアクセスできる。

ただし、実行する環境によってアクセスの仕方が違う。 - ブラウザ上で実行している場合はwindow - node.jsで実行している場合はglobal でアクセスできる。

ところで、jsでグローバル変数を定義するには、var/let/constなどで宣言せずに、新しい変数に値を代入すれば作れるらしい。 すると、グローバルオブジェクトのプロパティとして登録され、どこからでもアクセスできるようになる。 uxmilk.jp

ただ、この方法だと既に同じ名前の変数が同スコープ内に存在していたらただそれが上書きされるだけで、グローバル変数は生成されないから、 できればwindow.xglobal.xのように明示的に示して生成した方が良いようだ。 これ、結構ハッとしましたね。

勉強すればするほど発見があるので楽しいですね。

もやもやする一日

もうなんか最近、自分の足りない部分が沢山見えてきて、自己嫌悪に陥りそう。 「なんで自分はこうなんだろう」って思う部分があって辛いです。

そのことに脳のリソースが取られている状態。 それでも、自分にはやることがあるので、こなしていく訳ですが当然質はお察し。 明らかに良くないことは明らかですね。

鬱々した気持ちの中、メンタリストDaiGoさんの動画とか見ていたんですけど、色々と考えさせられました。

どうしたらこれからを自分を最善化できるか、ちゃんと考えていきたいですね。

JavaScriptの型が柔軟過ぎる

夜書こうと思っていたら、寝落ちしてしまった...。

最近、やっとまともにJavaScriptを勉強しています。 勉強していくにつれて、良い点・良くない点共に見えてきたような気がします。

型について

JavaScriptは動的型付け言語ですが、それゆえ色々面倒臭い問題があるなって思っています。

その一つが暗黙の型変換。 下の画像は型の変換テーブルです。 f:id:g-knk-9410:20180520070321p:plain

参考リンクはこちら。 JS Comparison Table

テーブル表を見ての通り、あまりにもガバガバなので、あらかじめ型検証したりして、しっかり制御しないと不安定な挙動になるかもしれないので、注意ですね。