短所と不向きな用途、他の選択肢など(翻訳)|TechRacho(テックラッチョ)〜エンジニアの「?」を「!」に〜|BPS株式会社エンジニアの「?」を「!」に。Railsの人気に陰りが生じつつありますが、人気の下落にはそれなりに深刻な理由がいくつかあります。理由が致命的なものとは限りませんが、ものによってはプロジェクトで厄介な問題を引き起こす可能性もありえます。パフォーマンスこれについては触れないわけにはいきません。Railsはスピードにおいて強者ではありません。Railsは明らかに不向きです。これはあくまで極端な場合であることを忘れてはなりません。数百万ユーザーをさばくことを期待しているのでもない限り、ほとんどのプロジェクト(特にスタートアップやMVP)ではそんなスピードを必要としません。ユーザーは、便利なアプリを安全かつ直感的に使えているうちは、パフォーマンスのことなど気にしないものです。Railsは忘れがたいドラマでした。当時「Railsはスケールできない」といった議論が噴出したものです。Railsは実際にはスケール可能です。サーバーのRailsをアップグレードすることも、複数のサーバーやツールで処理を手分けすることも可能です。する価値はあるのでしょうか?こればかりはアプリ次第です。前述のとおり、Railsのテクノロジーはバックエンドとしてそこまで高性能ではないと考えられています。他のフレームワークやバックエンドソリューション並のパフォーマンスをRailsで得ようとすれば、もっと性能の高い本格的なサーバーインフラに莫大な資金を注ぎ込まなければならなくなるでしょう。Node.jsやPhoenixといった高性能なテクノロジーを選択すれば、月に数千ドルは節約できることもあります。Railsフレームワークを使い慣れている方からすれば、これはものすごく偏った意見に見えるかもしれません。wayに乗ったアプリしか’お望み’にならない」ということです。wayから外れたありきたりでないアプリを開発しようとすると、たちまちつらくなることもあります。Railsにはデフォルト値やオブジェクトの詰め合わせセットなどがずらりと揃っているので、開発者が独自の創意を発揮する余地があまり残されていないように見えるかもしれません。開発者が「オレのやりたいようにやらせろ」と心ゆくまでオリジナリティを発揮しようと思えばできますが、その分開発期間も圧迫されるので、開発期間とオリジナリティを天秤にかけなければならなくなります。用途によっては「オーバーキル」ここで大事なことを指摘しておきます。RailsがなくてもWebアプリは作れるのです。私たちは、プロジェクトの種類に合わせて最適なテクノロジーをお客様におすすめしています。お客様の要件によっては、Railsだと少々トゥーマッチなこともあれば、別の既存ツールならどんぴしゃりとはまることもあります。Ruby言語と機械学習AI(人工知能)やML(機械学習)はここ4年ほどホットな話題に顔を出しています。今どきのアプリの大半は、何らかの形で機械学習と統合されており、退屈な仕事を手伝ったり、主に既存の業務や人員をコードで置き換えることで業務を自動化したりしています。この分野は、一言で言うと残念ながら今のRuby言語には荷が勝ちすぎます。ALやMLとくれば、Pythonが最適なテクノロジーです。言うまでもなく、Pythonは世界中で使われている人気上位のプログラミング言語であり、Rubyよりずっと高速です。Javaですら、AI/MLに適しているテクノロジーとみなされています。惜しいことに、愛しのRubyは主に必要なライブラリの不足が原因で、MLというもうひとつの大きなトレンドをフォローできていません。言語というものはどんな用途にも使える万能性までは想定されていないことを忘れてはなりません。したがって、これはさほど大きな問題ではありません。自社紹介に毛の生えたようなサイトわざわざ不要な複雑さを持ち込まないようにしましょう。Railsは、シンプルな静的サイトを作るには少々トゥーマッチです。した特定の用途であれば、コーディングをほとんど必要とせずにやれる選択肢がいくらでもあります。ブログ中心のサイトその気になればRailsでブログWebサイトを15分で作れることは、皆さんもデモでとっくにご存知かと思いますが、その後Webの世界ではさまざまなものが登場しました。Railsという戦車をわざわざ繰り出す必要もありません。開発者が好きでもないテクノロジーや、開発者が不慣れなテクノロジーを強要してはいけません。開発者がGo言語やNode.jsなどのバックエンドフレームワークに通じているのであれば、それを使ってアプリを開発してもらいましょう。納期がなく、プロトタイプも不要な案件ここは重要です。Railsは開発者の生産性を最大限に高めることができるがゆえに、開発期間を大きく短縮できます。残念ながら、Railsはその過程でパフォーマンスの一部を犠牲にしています。納期が明確に定まっておらず、MVPアプリも不要であれば、他のバックエンドソリューションを検討すべきです。アプリの要件やその他の要素によって変わってきますが。Railsに代わるミニマムな選択肢です。Sinatraの作者は、Railsとは少しばかり異なるアプローチを採用しており、アプリのセットアップに必要なコンポーネントを絞り込んでいるので、読み込みが比較的高速です。Railsを使うわけにいかなくなった場合は、Hanamiをお試しください。Railsの短所のいくつかを修正することを保証します。Hanamiのメモリ消費量はRailsの60%に抑えられており、セキュアかつ応答も高速で、かなりの程度の軽量化を保証します。Rails以外では初めてと言える「本物の」Rubyフレームワークの選択肢です。詳しくはHanamiRBをどうぞ。サーバーレスRuby本記事を書いている間に、何やら面白いことが起きました。「サーバーレスで使える」Rubyをぜひチェックしましょう。LambdaでRubyをサポートすると公式にアナウンスしました。これはRubyコミュニティにとって一大ニュースです!Java、Node.js、Go言語、C#などと同じくAmazonのクラウドにRubyも参入しました。「サーバーレスRuby」にはどんな意義があるのでしょうか?開発者はサーバーインフラのことを気にしなくてよくなりますし、コードを正しく書きさえすれば、アプリの特定の機能をAmazonのクラウドの計算機パワーの一部として実行できるようになります。支払いが計算時間ベースだけで済むのもクールです。Lambdaやその他のサーバーレステクノロジーの登場が比較的新しいので、サーバーレスのコンセプトに精通した開発者や、サーバーレス経験のある開発者を見つけるのは今の段階では一苦労です。Lambdaについて詳しくはこちらをどうぞ。Rails開発についての打ち明け話を記事で公開しました。Railsが使われています。Railsを選択したのはまさしく先見の明であり、そのおかげでさまざまな高品質の機能を苦もなく実現できていると述べています。それだけではありません。GitLabの開発チームはさらなる課題への挑戦を続けています。コードの一部をGo言語で書き換えたり、Vue.jsフレームワークを採用したりすることで、パフォーマンスの問題を克服しました。3×3」と銘打った新しいバージョンのRubyを手がけていると発表しました。2.0の3倍の高速化を目指しています。リリース予定日は残念ながら未定ですが、2020年終わりまでのリリースとしてスケジューリングされるであろうと期待されています。Ruby世界は1つのWebフレームワークで終わる。RailsはRubyを活かすと同時に苦しめてもいる。3×3の一部が既に導入されていることに気づいています。JITコンパイラの導入によってパフォーマンスが著しく向上したことがさまざまなベンチマークで示されました。変わるのはスピードだけではありません。2.6は予定どおりリリースされました)。Matzは他にも、過去のRubyアプリケーションではRubyのバージョンが変わると互換性が失われていたと述べています。Matzはさまざまな変更を導入して「巨大なギャップ」が生じ、それによってRubyコミュニティが分裂したことがありました。Matzは今後そうした間違いが起きないようにするとのことです。3で動くようにすると述べています。Surveyでは、Rubyを愛する開発者が減少しつつあるという残念な結果が出ていました。実際、トップ10にも入っていません。Matzは、現状のRubyは既に「ホットな言語」ではないとみなされているが、その分安定しているとも述べており、3×3がリリースされたときに再び「ホットな言語」として愛用されることを願っています。成熟と停滞Rubyは成熟のときを迎えています。自らを「成熟した」と言い切れるプログラミング言語はそう多くはありません。現状のRubyは、人気の高い言語の中では今も古株であり、実績も信頼もあるテクノロジーとして世界中で使われています。Rubyのコミュニティは絶え間なくRubyを支援しています。コードで何か困ったことがあれば、そして運良く同じ問題を数千人が踏んでいれば、かなり楽に解決方法を見つけられるでしょう。残念ながら、成熟と停滞は表裏一体です。前述の通り、ここ数年はRubyを「ホットな言語」にする変更や新機能はそれほどありませんでした。Rubyもコミュニティももうお終いだという意見もあったりします。私個人は、Rubyのテクノロジーは停滞期を迎えていると考えています。率直に言うと、Rubyは極めてゆっくりとですが、レガシー言語になりつつあります。少なくともここ数年、Rubyからときめきが失われていた。ときめきがないとだめということではない。長い目で見れば、プログラミング言語にとってときめきが必要だとも私は思わない。私としては、プログラミング言語には成熟と安定性と信頼性を求めたい。私は2019年のRubyについてそう考えている。私がRuby以外の言語に乗り換える必要のある分野は年々減り続けている。Rubyがこれまで「エンタープライズ向け」テクノロジーであったことはないし、今後そうなるかどうかも疑問ではあるが、高速かつ柔軟にやりたいことがあれば、Rubyは今後もよい選択のひとつである。Railsを使うことで生産性が向上するとも思えず、アイデアとして非常に優れているとも思えないかもしれませんが、Rubyのエコシステムはまだまだやることをたくさん抱えています。Railsのパワーを余すことなく活用すれば、洗練されたアプリをすぐにでも開発できるようになります。この機能については、他の多くのフレームワークでそこまで自信たっぷりに言い切ることはできません。(はい、皆さんご一緒に)「欲しいgemは必ずある」からです。Railsのリリースはとても有望に思えます。開発者から寄せられた不満の多くが修正され、新バージョンが出るたびに素晴らしい新機能が追加されています。Ruby、そしてRailsが近い将来再び勢いを盛り返すことを願っています。僕の場合「楽しく書けるか?」「エレガントに(=シンプルかつ美しく)書けるか?」が最重要事項なので、いまだにRuby以上に「おっ」と思える言語はないんだよな〜。短所を挙げられてもRailsから乗り換える気が起きない。2019Railsが成熟し、停滞しつつあることにしっかり触れて、向いていないケースの解説も丁寧だった。コボラー、ITコンサル、ローカライズ業界、Rails開発を経てTechRachoの編集・記事作成を担当。チュートリアル第2版の監修および半分程度を翻訳、Railsガイドの初期翻訳ではほぼすべてを翻訳。その後も折に触れて更新翻訳中。enno.jpを運営。実は最近Go言語が好きで、Goで書かれたRubyライクなGoby言語のメンテナーでもある。仕事に関係ないすっとこブログ「あけてくれ」は2000年頃から多少の中断をはさんで継続、現在はnote.muに移転。Storageを使ってはいけない(翻訳)#Tags#会社紹介#自社サービス#勉強会#Rails#PHP#デザイン#実績#週刊RailsウオッチCONTACTお気軽にご相談ください。(翻訳)CONTACTTechRachoでは、パートナーシップをご検討いただける方からのご連絡をお待ちしております。お気軽にご意見・ご相談ください。