サーバサイドjavascriptについて語りましょう。
node.js - googleが開発したV8エンジン上で実行できる処理系
ttp://jump.5ch.net/?http://nodejs.org/
ayo.js - node.js 互換で Rod の影響からの脱却を目指す処理系
ttp://jump.5ch.net/?https://github.com/ayojs/ayo
Nashorn - Java8 からRhinoに代わって同梱されているJavaScriptエンジン
ttp://jump.5ch.net/?http://www.oracle.com/webfolder/technetwork/jp/javamagazine/Java-JA17-Nashorn.pdf
ayo.js の経緯
ttp://jump.5ch.net/?https://web.archive.org/web/20170821212745/https://github.com/nodejs/TSC/issues/310
javascriptはrubyと比較してもかなり速い
ttp://jump.5ch.net/?http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=v8&lang2=yarv
基礎から学ぶNode.js
ttp://jump.5ch.net/?http://gihyo.jp/dev/serial/01/nodejs
node.jsの概要とアプリケーション開発の準備
ttp://jump.5ch.net/?http://gihyo.jp/dev/serial/01/realtimeweb/0002
前スレ
【node.js】サーバサイドjavascript 4【io.js】
ttp://mevius.5ch.net/test/read.cgi/tech/1460359714/
【node.js】サーバサイドjavascript 3【io.js】
ttp://echo.2ch.net/test/read.cgi/tech/1419673207/ 【node.js】サーバサイドjavascript 2【Rhino】
ttp://peace.2ch.net/test/read.cgi/tech/1358937029/ 【node.js】サーバサイドjavascript【Rhino】
ttp://toro.2ch.net/test/read.cgi/tech/1310087535/ 占有型ではもちろん使えるけど今なら間違いなくVPSのほうがいい
昔ながらのFTPとかでファイル置くしかできないようなサービスならまずそんなもの導入されてないだろうな
どうしてもエラーが解消できないのでどなたかご教授頂けませんか？（exportsにオブジェクトを突っ込む方法）
古い記述方法では動作しますが、新しい記述方法ではどうしても動作しません。
色々ググったのですが、どのサイト（英語サイトも含め）も古い記述方法で書かれており困っています。
公式も古い書き方に記述されています。（ejsだけ新しい書き方に対応していない？）
ttp://jump.5ch.net/?https://www.npmjs.com/package/gulp-ejs
//old
gulp.task('ejs', function() {
//
}
新しい記述方法では、どうしても下記のエラーが解消できません。
- The following tasks did not complete
- Did you forget to signal async completion?
また`ps aux`で別のプロセスも走っていないことを確認しており、別のgulpタスクも全てオフにした状態で
デバッグしております。
関数の引数にdoneを入れてdone()で締めたり、return除いてみたり試行錯誤していますが、数時間ハマっています。
どなたら分かる方いらっしゃたらご教授お願い致します。
//new
function ejs() {
return gulp
.src(srcPath.ejs)
.pipe(ejs());
}
exports.ejs = ejs;
それか、意味を考えてみれば？
The following tasks did not complete
Did you forget to signal async completion?
もっと単純な例で、動くかどうか試してみれば？
状況全く分からんが、JSのパーサーはややおかしい？所があって、returnの後はぶった切られる。
よって、 return gulp.src(srcPath.ejs).pipe(ejs()); と改行を無くして試す事を勧める。
ttp://jump.5ch.net/?https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Lexical_grammar#automatic_semicolon_insertion
これ return と yield (と後置演算子もか？)はパーサの仕様バグだよな？
直感的じゃ無いという意味で。
お前の直感がおかしい
いや実際660はそうしてるだろ。俺も以前嵌った事があったし、
実際セミコロン必須の言語だとどこで切ってもいいから、660の書き方はよく見るよ。
俺はお前がおかしいと思うが。
結局これもMDNで説明するのに例外扱い("no LineTerminator here" 規則)になってるし。
統一された文法ではないよね。（=もっとましな仕様にする事も出来たし、実際他言語はそう）
その書き方よくみるというけど
1行で書けば見やすいのにわざわざ複数行で見にくくしている意図がわからない
そりゃ、そうした方が見やすいと思う人がそうするだけだよ。
お前がそう思わなければしなければいいだけ。
ただ実際、660にある公式のコードもそうなってるだろ。
俺も個人的には横に長いコードを書くけど、一般的には縦に長いコードの方が多いと思うよ。
660の「新しい記述方法だと動かない」とされてるコードは return gulp で改行してる。
660内の公式はこれが出来ない事を知ってるから、 gulp.src(...) で改行してる。（ただしreturnはないが)
それは長い行を分けて改行しているだけ
一方での人は長い行にならないのに無意味に改行しまくり
return
gulp.src()
ならreturnの後にセミコロンが自動挿入されるけど
return gulp
.src()
ならgulpの後にセミコロンは自動挿入されないでしょ
それよりfunction ejs(){}って名前がダメなんじゃないの？
.pipe(ejs())で再帰になってる
長さではなく、意味で切るんだよ。
> return gulp
> .src()
> ならgulpの後にセミコロンは自動挿入されないでしょ
されて gulp が返されるはずだぞ。
意味で切るならgulpと.src()の間で改行を入れてるのは明らかにおかしい
無意味な改行だ
すまん、674は間違い。
試してみたところ、確かに挿入されないようだ。
相手するだけ無駄っぽいが、そういうのは物によるんだよ。
そうした方が見やすいと思う奴がそうするだけ。
return ウンコ製造器675号
.src(ケーキ)
.pipe(胃)
.pipe(小腸);
.pipe(大腸);
なら、675によってケーキがウンコに変わるのが見やすくなると思う奴もいるだろ。
（詳しくないが）gulpの場合は基本はフィルタで型が変わらないし、出発点はソースファイルに決まってるから、
return gulp.src(ソース）
.pipe(フィルタ1)
.pipe(フィルタ2)
のケースが多いとは思うけど。
ついでに言っておくと、お前JSによくいる、やたら文法に拘る奴なら、止めた方がいい。
それだと全く進歩しないので。
上記の通り、まあどちらもいるわな、程度で進めていかないと、上達しない。
どちらが正しいとか、そういう問題ではない。
どうにもJS初心者は「改行を極める」「セミコロンを極める」とかになりがちのようで、よろしくない。
別スレで見た
ゆとりにはそれがお似合いだね
仕事でレス遅くなりました。
ありがとうございます！
このコメントからピンときて修正したら無事に動作しました。
超初歩的なミスでした、、
こちらの書き方は関数の中にejs(gulp-ejsオブジェクト)を書いても動作しましたが
gulp.task('ejs', function() {
}
こちらでは関数に同じ関数入れたらまだタスク終わってないよと、動作しませんよね。（気づけば当たり前なのですが、、）
function ejs() {
}
お騒がせしました。コメント頂いた方もありがとうございました！
. を行末に置く
a.
b( ).
c( )
JavaScriptで駄目なのはreturnのみの行の時だけだよ
return
a
.b()
は駄目だけどこう書く人はいないから問題は起きることはない
return a
.b()
なら大丈夫
それを知ってないと嵌るだけの無駄仕様だよ。
セミコロンなしの筆頭だったAirbnbも諦めたようだし。
> ASI contains a few eccentric behaviors, though, and your code will break if JavaScript misinterprets your line break. These rules will become more complicated as new features become a part of JavaScript. Explicitly terminating your statements and configuring your linter to catch missing semicolons will help prevent you from encountering issues.
> ttp://jump.5ch.net/?https://github.com/airbnb/javascript#semicolons
他にセミコロンなしの有名ルール勢ってあったっけ？
return
'qwerty'
+'asdfgh';
とは書きたくなるだろ。書きたいように書けないのはよろしくないよ。今風ではないね。
セミコロン書くルールならASIなんて無い方がマシだし。
好みだけの問題ならスクリプトの仕様に従うしかない。
俺向けではないと思うが、
return
'qwerty'
+'asdfgh';
の利点は見れば分かるとおり、インデントを揃えられる事だよ。
タグの方が分かりやすいかもしれんが一々引っかかると面倒なので止めただけ。
return '<div>'
+'<span>'+
+'</span>'+
+'</div>';
だと最初のdivのインデントがずれるだろ。
まあ言うほどではないし、実際俺はこの書き方をしているが、出来れば return の後に改行したいね。
それが今のデファクトだ
Airbnbがセミコロンなしの筆頭って頭腐りすぎたろ
git時代に歴史改ざんしてもすぐにバレる
2012年にセミコロンの章が初めて書かれたときからAirbnbはセミコロン派だ
ttp://jump.5ch.net/?https://github.com/airbnb/javascript/blob/cab510342f93791a7487d16258d06ff73edb4507/README.md#semicolons
ならAirbnbというのは俺の勘違いだな。
俺がJSを始めた2013-14頃、有名なコーディングルールが4つほどあって、Airbnbが一番トンデモだった(が、人気は一番という話だった)
その中にはセミコロンを打つな、というルールもあった。誰か思えてないかね？
なお俺はgoogleのルールが一番マシっぽいのでそれを参考にした。(こちらはセミコロンあり）
どこだか覚えてないけど、確かにどっかでセミコロン打たないで、短文を1行に書くときだけセミコロン使うてなの見たか聞いたりした記憶ある。
> Always use semicolons. (google)
> Use them. Never rely on ASI. (jQuery)
> あなたからセミコロンを奪おうとする反抗的な軍隊があるようです。でも確かに私達の伝統的な文化はまだ元気に生き残っています。だからコミュニティに従って、セミコロンを使いなさい！(Node)
> ttp://jump.5ch.net/?https://qiita.com/takeharu/items/dee0972e5f39bfd4d7c8
npmのもかなりトンデモだった記憶があり、改めて確認すると、打つな派だ。
> ;(x || y).performAction()
> ;[a, b, c].forEach(performAction)
> for (var i = 0; i < 10; i ++) {
> switch (state) {
> case 'begin': start(); continue
> case 'end': finish(); break
> default: throw new Error('unknown state')
> }
> end()
> }
> ttp://jump.5ch.net/?https://www.w3resource.com/npm/npm-coding-style.php
となると俺の勘違いはnpmという事になるが、npm==Nodeじゃねえのか？という疑問は発生する。Nodeはnpmからのフォークか？
多分俺が当時見たのは Airbnb, npm, jQuery, googleだと思う。
npmはIsaac Z. Schlueterが始めてセミコロンなし
IsaacはNodeの2代目リーダーだけどNodeではセミコロンを書いてた
カスタマイズも許さない
ttp://jump.5ch.net/?https://github.com/standard/standard
初コミット2015年なのにstandardと主張して他と違うルールとか、頭おかしいな。
とはいえ議論する時間が一番無駄というのは同意だが。
多分セミコロン無し言語出身者用のルールが一つは必要で、
それに向けてのstandard命名なのだろうけど、なんだかね。
「ｴ」(バッククォート)で括ればいいじゃん
このルール入れろ
ttp://jump.5ch.net/?https://eslint.org/docs/rules/prefer-template
初心者が情報公開の練習として解説を書くからそうなる
読む方が気を付けて取捨選択するしかない
中途半端で使いにくい。
どういう所？
同意だが、C#はかなりマシ
一般的に上級者は初心者向けの説明なんて書きたくないものだが、
プログラミング自体について語りたい連中も多少はおり、そいつらを上手く取り込んでる
上っ面だけのクラスベース。
内容はプロトタイプのまま。
まぁ、中途半端というなら何かそういう部分が見えているということなんだろうが。
オブジェクト指向的センスが無いと言う事だね
今の時代、両方出来ないとプロだと厳しいと思うがね
クラスで閉じて使ってる限りプロトタイプの側面は見えないはずだが
混ぜて使うのってありだっけ？(class宣言した物にgetPrototypeOfとか)
class構文の時にどうプロトタイプが配置されるか仕様で確定してないと駄目だと思うが、これってしてるのか？
時代遅れとなったC++やJava風のクラス構文を導入する必要はなかったわな
TC39的にはES4で入れ損なったから悲願だったんだろうけど
仮にそうだとしても、IDEの都合を優先してプログラミング言語を簡素化するのは完全に本末転倒だろ
初心者専用のオモチャが欲しければScratchで満足しとけ
既存との互換を保ったまま機能追加されてるわけだから言語自体は簡素化されたのてはなく複雑化されたのでは
それはさておき従来の機能が使えなくなるわけでもなく何が不満なのかわからない
してない。
だから細かい設定が解りづらい。
糖衣構文を導入した分言語は複雑化してるし、IDEも余計に対応する必要がある。
IDEを優先するなら何もしないのが最善。
（もちろん仕様を削れるのが最善だが、JSの場合はこれはかなり無理なので）
仕様で確定してないのなら、混ぜて使う事は禁止だし、
クラスで閉じて使う分にはプロトタイプベースは見えないから問題ないだろ。
何を問題視してる？
ECMAScriptの仕様書も読んだことない低脳が堂々と嘘を書くなよ
ES2020の14.6.12
自己レス「ES2020の14.6.13」の書き間違い
そもそもプロトタイプベースの方が静的解析難しいからちゃんと補完できるIDE作るの難しいと思うよ
例えばプロトタイプベースでtypescript作れるかというと結局クラス宣言的な物を導入せざるを得ないと思う
構文解析なんかは大して難しい話ではない
最終的に何が言いたいのかさっぱり分からんが、既に言ったとおり、
IDEの都合でプログラミング言語の仕様を決めるものではない。それは逆だ。
プロトタイプベースではIDEを構成出来ないからクラスベースを導入した、と考えてるのなら、上記の通り。
IDEの為にプロトタイプベースを廃止してクラスベースに一本化すべき、でも上記の通りだし、JSでは無理。
IDEの為にクラス構文なんてそもそも導入すべきではなかった、と考えてるのなら、それもありだし個人的には賛成だが、
一般論としては現在の、メジャー言語でほぼクラス導入済みの状況で、JSだけ不採用も、メジャー言語としては難しい。
GoやRustは今も今後ともマイナー言語でしかないし、勝手にやってろでしかない。
静的解析自体はクラスの方が簡単だろうけど、だからどうしたでしかない。
実行エンジンはあるのだから、実装難易度の上限は実行エンジンを実装する程度でしかなく、出来る範囲だ。
最悪、実行エンジンをそのままコールして結果を得る事も出来る。Flycheckとかそういう構造のように見えるけど。
ちなみにTSが型を導入したのも、IDEを作るためではなく、
プログラマが型を明示的に示す事によって、間抜けなエラーを静的に検出するためだぞ。
そこにIDEが勝手に乗っかっただけであって、IDEが無くとも型の導入自体は意味も効果もある。
型無し言語出身者は型をIDEでの補完をするための物だと勘違いしてるが、そうじゃない。
言いたかったこととしてはプロトタイプベースがクラスベースの機能包含しているとしても
静的解析のこと考えるとプロトタイプベースが必ずしもクラスベースのスーパーセットではないよねということ
実行エンジンを実装してもあらゆるパスが評価できるわけでないので宣言的記法の方に軍配が上がると思うが
実行エンジン内包する方式で宣言的記法と同等の静的解析できてる例ってあるの？
flycheckってemacsのパッケージのことだと思うけどあれも静的解析走らせてるだけで実際にJS評価してるわけじゃないでしょ？
IDEのためだけではないというのはその通りで、途中から略して書いてしまっているが ではIDEや静的解析といっている
> 静的解析のこと考えるとプロトタイプベースが必ずしもクラスベースのスーパーセットではないよねということ
IDEの「実装」をプログラミング言語の「仕様」比較（スーパーセットかどうか）に含めるのがおかしい。
それは「○○は△△のスーパーセットではない。なぜなら『僕が』それを『実装』出来ないから」と言ってるのと同じだろ。
IDEは開発をサポートする道具であり、サポート対象はプログラミング言語だ。
よって、仕様上どんなに構文解釈が難しかろうが、必要ならやるしかないし、それだけだよ。
上下関係で言えばプログラミング言語の『仕様』が完全に上であって、
IDEの『実装』の都合をプログラミング言語側に押しつける事は出来ない。
> 静的解析走らせてるだけで実際にJS評価してるわけじゃないでしょ？
俺が使ったのはGoだけど、見た目は実際にコンパイルを走らせてそれをアノテートしてただけ。
でも確かにこれが一番生産性が高いんだよ。
当たり前だが、コンパイラはエラー時には何行目の何文字目でこけた、という情報を持ってる。
だから静的解析が目的ではなく、ソースコード作成時にエラーを表示する事が目的なら、これでいいんだよ。
最大のメリットは構文解釈を自前で実装する必要がない事。
構文解釈機の再開発をやめ、本体コンパイラのエラー情報をより詳細に出す事にリソースを突っ込み、
IDE側はその詳しいエラー情報を解釈してアノテートするだけに徹する。
これで言語側の仕様変更に自動的に追従するようになる。
IDEの数だけ構文解釈機を再開発するのは手段が目的化してる。
> 実行エンジン内包する方式で宣言的記法と同等の静的解析できてる例ってあるの？
Flycheckは外部から呼んでるだけ。でもそれでコンパイラが吐くエラー（=静的エラー）は全て検出出来る。
しかも自前の実装もなしだから、最も生産性が高い。
自前の構文解釈機でコンパイラ/ビルドシステム以上のエラーを検出する気なら、
それはIDEではなくリンターと呼ぶべきだが、
それが出来るのなら、コンパイラ/ビルドシステムにそのリンターを内包して、
IDEはそのエラーを表示する事に徹するのが最も生産性が高い。
IDEで構文解釈するのではなく、エラーを出来るだけ早い段階で検出して修正するのが目的だから。
> IDEの『実装』の都合をプログラミング言語側に押しつける事は出来ない。
なぜそうあるべきなのですか？
近年の言語はサードパーティーのツール含めたエコシステム全体で生産性をいかに高めるかという観点で設計されることも多いと思うのですが
また、あなたの言う実行エンジンとは静的解析器の意味で実際にJSをevalするものではないということですね？
なぜか構文解析の話になっていますが意図してたのはintellisenseのような意味解析が必要な機能です
プロトタイプベースの記法では解析のためにコードの実行パスを追いかけプロトタイプの設定箇所を検出しなければならないのに対して
宣言的記法であればスコープ内のクラス宣言を見ればだいたい事足りるので実装難易度は大幅に異なるかと
クラスベースじゃないからってRustやGoを出してるがそれらはプロトタイプベースですらないわけで。
はクラスベースを時代遅れと書いたんだが
ぶっちゃけオブジェクト指向が過去のものになってきてるのみんな分かってるだろ
> 近年の言語はサードパーティーのツール含めたエコシステム全体で生産性をいかに高めるかという観点で設計されることも多いと思うのですが
「多い」というのならまず具体的に名前を複数挙げてみろ。
出来なければそれは君の妄想だね。
> また、あなたの言う実行エンジンとは静的解析器の意味で実際にJSをevalするものではないということですね？
違うぞ。それは今の話に関係ない。（どっちでもいい）
> 意図してたのはintellisenseのような意味解析が必要な機能です
だから何？これも君の考えが間違ってる。
flycheckのやり方でも原理的にインテリセンスは出来るんだよ。
インテリセンスで出なかったキーワードだとコンパイルエラーになるのなら、
仮にコンパイラが無限に速ければ、ソース内の全キーワードで試せば、コンパイルが通るキーワードのリストは得られる。
実際こんな事をしてる物はないと思うが、構文解釈で100%絞る必要なんて無くて、
候補が数個程度なら全部試してエラーが出なかった物を出す程度でも十分実用的なんだよ。
今時emacsでもインテリセンスするようだから、そんなにIDEが気になるのなら、彼等のアプローチを確認してみるといいよ。
全言語向けに自前でやってる事なんてないと思うよ。
プロトタイプを自分で追うのが技術的に無理なら、evalさせてgetPrototypeOfやinstanceofを使って追えばいいだけ。
自前の構文解釈器でソースからデータツリー構築をする気だからおかしくなる。
それはevalすれば実行エンジン内に構築されるものでしかないのだから、完全に再開発だろ。
eval出来る環境があり、それが一番近道なら、やればいいだけ。
君は多分「生産性」を勘違いしてる。
むしろ再開発しすぎてるし。
現状どうなってるのか知らないのだけど、メジャーなIDE、
例えばVSCodeとかだとクラスベースならインテリセンス出来るが、プロトタイプベースだと無理とかなのか？
誰か使ってたら教えてくれ。
○クラス構文
クラス構文で書いてもプロトタイプベースなのは変わらん
確かにクラスベースがってよりオブジェクト指向が時代遅れって感じだね。
JS自体は関数プログラミングもいける。
> 「多い」というのならまず具体的に名前を複数挙げてみろ。
例えばgolangやrustはコアチームがツール開発に積極的ですね
ツールのチームがコア言語に対してフィードバックしていたりする
> eval出来る環境があり、それが一番近道なら、やればいいだけ。
"構文解釈機" という言葉を使っているから静的解析を意図してるのかと思ったけど動的解析も含んで言っていたのね
それで実用に耐えうる速度と精度が実現できるならそういうアプローチもありかもね
それから別にIDEが自前で静的解析器を開発すべきなんて主張はしてないから藁人形論法はやめてくれ
オブジェクト指向というか継承が忌避されてる気はする
OOPLが提供していた継承以外の特性の多く(カプセル化など)は抽象データ型から来ていてそれは時代遅れになってないし忌避されてもいない
classとfunctionを混在した書き方でも問題ないの？
混在した書き方っての次第だが
class A {}
A.prototype.x = () => {}
a = new A()
a.x()
こんなのは当たり前に動くぞ
つかまずは自分で試せよw
JSなんかブラウザあれば動かせるんだからさー
> 例えばgolangやrustはコアチームがツール開発に積極的ですね
それで、それらの言語のどの仕様がIDEの都合で採用されたものなの？
> 藁人形論法はやめてくれ
なら最初から分かるように主張しろ。
何が言いたいか分からないからエスパーして複数挙げてみただけ。
馬鹿は無視してきっちり自分の意見を書ききれ。
3行しか読めない馬鹿はプログラミングなんてどうやっても出来ない。
MDNその他のリファレンス見りゃ分かるが、そんな世界じゃない。
5ch程度の文にすら手こずるようではどだい無理だよ。
解釈が動的か静的かは意味無い。
出来るだけ早い段階でエラーを検出して修正したいだけであって、それが出来れば何だっていいんだよ。
その手段の一つが静的解析でソース作成時にエラーを表示する事であって。
でも、エラー表示だけなら、コンパイラやevalにぶち込めば出来るし、それをやってるっぽいのがflycheck。
構文解釈器を自前で作るとしても、クラス構文でもプロトタイプ構文でも、大して難易度は変わらない気もするが。
実際に問題になるのは、構文解釈そのもの、具体的にはJS的な様々な書き方でも問題なく動くパーサの構成だろ。
構文解釈後の親class/プロトタイプ追跡なんて辿ればいいだけだからアホでも出来る。
それで今時のIDEで実際どうなのか聞いたんだよ。
もしプロトタイプ構文ではインテリセンスが動かないのなら、何か理由はあるのだろうけど。
継承が忌避されてるのは、JAVAでは関数ポインタが使えず、同様の事をするためには継承をこねくり回すしかなくて、
それの残骸がデザインパターンなのだが、
結果、継承すべきでない局面での継承で酷い事になってるからだよ。
でも、継承すべき場所では継承した方がよくて、全部捨ててるGoはいちいち全部書かないといけないのが糞。
あれは1周目はまだしも、2周目以降でそのコピペされたソースにメンテコストがかかるから、先すぼみになると予想してる。
Rustはやってないから知らん。
このスレ伸ばすにしてもnodeにScheduling APIが入ったとか普通にネタあるだろ
それでexpressなどnode用のライブラリが動くように互換性を高める方針になった
でもそれならnode使い続ければいいやってなりそう
実行してもエラーを起こさず無反応なんだよね
Headless Recorerを使ってるからHTML部分の間違いはないと思うのだけど、
UserAgent以外で何か対策ないっすかね
一般論として言えるのはpuppeteerでも普通にWebページのコンテキストからDOM APIを叩ける
使ってるところは諦めてるんだけど、使ってないところはどうやってるのかな～と思って
UserAgentをガラケーにしてみたり、プレステにしても無反応なんだよね
間違いなく妥当なリクエストが投げられてるのが大前提
あとは“how to detect headless browser”でググるといいよ
ttps://mevius.5ch.net/test/read.cgi/tech/1635193843/538
ここに、YouTube で有名な、雑食系エンジニア・KENTA のサロンの、
Ruby on Rails 初心者用コースの内容を書いておいた
基本的に、Rails以外のフレームワークは、シェアが少ないのでおすすめしない。
学習環境も揃わないので、無理
Railsでは、Railsチュートリアル・Railsガイド・
黒田努の3冊の本・パーフェクト Ruby on Rails・Ruby on Rails 6 エンジニア養成読本とか、
Rubyでは、改訂2版 パーフェクトRuby・改訂2版 Ruby逆引きハンドブックなどの教科書が揃っている
これほど、良い教科書が揃っているフレームワークはない！
Laravel のシェアは少しあるけど、KENTAがPHP は一生やる必要がないと言ったので、
PHP自体がオワコンになってしまったw
日本のウェブ開発の将来は、ほぼKENTAが決めている。
Scala を滅ぼしたのも、KENTA
