nodejsを使っていて気付いた点。

最初に断っておくけど、私はjavascript初心者です。なので9割方はjavascriptをディスってます。あと変なネタ混じってます。スルーしてください。それとTipsでも何でもありません。ただの作文です。感想です。

---

prologue-始まりの詩-

趣味で家計簿サーバ作ってるんだけど、
①リアルタイム処理をすごく簡潔に書ける。
②サーバの構築がものすごい楽。
という風の噂を小耳に挟んだ事があった様な気がしたので、「nodejs」を使って最近日曜の半分以上を使ってがりがりやってたので、分かった事の5分の1くらいを纏めます。

最初は何とかなるって思ってました、nodejsって結構前から出てる最新型なので、javascriptのほうも全く知らなかったのでいい勉強になると思い、そしてリアルタイム通信が魅力的でした。
扱いづらいプラットフォームと言語とかって話だが、最新型が負けるわけねえだろ！行くぞおおぉぉあ！！

outbreak-体験-

nodejsの後ろめな性質

1. サーバ側でnodejs特有の書き方を覚える必要がある
2. 実はそんなに速度ない
3. 頻繁に更新される
4. 致命的な不具合があるとサーバが即停止する
5. 「co」を使わないとお話にならないじゃん・・・
6. 「co」も割と頻繁に更新されてる
7. 言語がjavascriptである

nodejsの良さある性質

1. サーバの構築がapacheとphpとmysqlのサーバ組むより、アホみたいに楽
2. クライアント側であるwebビュアー側との通信もそれなりに楽
3. サーバとクライアントとのリアルタイム通信がアホみたいに楽

こんな感じですね、感想。
それでまとめとして。

1. javascriptのせいで大きな開発をするべきではない
2. 不具合あるとサーバが即停止するので絶対ミスれない
3. javascriptのせいでメンテ性がアホみたいに低い
4. 初期開発効率がめちゃくちゃ高いけど、javascriptのせいですぐに急激に開発効率が下がる

結論「だいたいjavascriptのせい」

callback-未来への退路-

前章のまとめでは(javascriptのせいで)デメリットが大きすぎて割りに合わないと言い切りましたが、初期開発効率が非常に高いという点に重点を置くならば、小さいプログラムを書く上では非常に良いものです。

よく訓練されたjavascripterならコールバック地獄を中をすがすがしくコーティングしていくでしょう。なので、要はjavascriptでの開発耐性がものを言う戦場なのです。

しかし、javascriptでコールバックとか知らんとか、jquery信者とか、でもしかプログラマーな方々は、即座にコールバック地獄の中を渡り歩いて行かなければならないのです。ですが、もし、この茨の道を通り、生存しているならば、あなたはjavascriptでの開発力を上げられるでしょう。

それでまとめとして。

• javascript初級者なら見事なまでのコールバック地獄を堪能できる。
• コールバック知らない人はこれで嫌でもコールバックが分かる。
• これで生きていれば素養の持ち主として認められる可能性が上がる
• もし思考停止すると「お前で28人目。恐れるな、バグまみれになる時間が来ただけだ」

• 訓練されたjavascripterなら大規模開発も出来る。
• 不具合が絶対許されないので変な気分に浸れる。

結論「javascriptのクソさを学ぶなら最適じゃない？」

co-nodejs界のZIVAにゃん-

前章でコールバック地獄に揉まれるので、初心者だと生きているだけで奇跡に近いと言いました。ですが別にひたすらコールバックに揉まれることがあまりありません。知能が高ければ「co」というモノがあり、これを使いこなせればある程度コールバックを緩和することが出来ます。

しかし、そもそもこの「co」が非常に癖の強いモノで、まず例文を動かす事ができたらやっぱり大したことない！　言われたとおりだ、ハハハ！って調子に乗っていいと思っていいです。そのあと過信しすぎてしまったが為に死にます。

1. カリー化を知らないといけない
2. カリー化しないといけない
3. トップコードに書けない
4. 自らもコールバック関数を書かないといけない

mysql-ServerSideDataBaseとの融和性-

まずmysqlを使おうとすると、mysqlのライブラリをカリー化しなければいけないのですが、これ自体は問題は無いのです。問題はこのライブラリのメソッドを使った自作ライブラリなんか作ろうとすると死にます。なぜならクラスオブジェクトの中の関数なので、関数というよりメソッドなのです。

メソッドは使えるところが限られますし、使う条件もあります、クラスがなければ絶対に動きませんし、クラスのほかの関数に依存だってしてあるときがあります。これを自作関数でラッパーしてカリー化するにはクラス内部にカリー化を仕込まないといけないのですが、私はメンドクサイので、参照だけ解決して無理やり実装しました。このあたりの実装は様々あると思うので詳しくはググってください、無いかもしれないけどね。

maker-作ったり作られたり-

じゃあ「co」は使えないのか？っていうと、正直デメリットが大きすぎて微妙です。提供されたライブラリにある関数だけなら何とかなります。ですがこれをラップした自作関数等は色色メンドクサイ作業が山積みになります。さらにそもそも「co」を使用することによって速度低下に繋がるのでは？といった検証しなければならない問題があります。

「じゃあ小規模で収まるならば、それこそ使わなくて良いのでは？コールバックも10重もしないし、変なのに頼りすぎるのも駄目だろう。なにより無駄に保守性が下がるのはよろしくない。」と私は思っているので、正直、小規模であれば「co」を使おうが使わまいがあまり状況は変わらないと思ってます。初心者だとコールバック地獄から脱出したい一心で「co」に過度な期待をすると返り討ちにされます。

また、この「co」は2014年に更新されまして、気軽にアップデートしたら動いてたプログラムが動かなくなりました。原因は「co」の基本構文が変わった事で構文エラーが吐かれたことでした。「co」は特殊な構文なので探すのは容易で修正も容易ですが、なかなかぞっとします。話が…違うっすよ…coは…特別だって…

それでまとめとして。

• 「co」はすごい
• すごいけどカリー化とかしないといけない
• mysqlのライブラリとかをラッパーした奴は大体カリー化できない

結論「coは既存の問題を幾つか解決するが、
それ以上に問題を生産する。カリー化しなければいけない。」

freedom-結末-

前章で「co」なくてもいいんじゃね？って結論が出ました。
問題はこれを使うか使わないかですが、それは他人が決めることじゃなかろうさ。
最終的な決定権は自分にあります。責任も自分にあります。
好きにコードを書き、理不尽に不具合が起きる。楽しいjavascriptライフを！