シェアする

  • このエントリーをはてなブックマークに追加

Python(Flask)からRuby(Rails)に鞍替えしての所感。あるいはマイクロフレームワークとフルスタックフレームワークの比較。

こんにちは。かねしろ@pinkrootです。

前回のブログ更新は去年の11月。9ヶ月も間があいたようです。
そんなこんなで勝手を忘れてしまいましたが、最近Railsをゴリゴリと使って開発してみているのでその所感を。
Rails初心者としての感覚がまだフレッシュなうちに備忘として残しておきます。

そもそもどういう環境で開発をしていたのか

7年程前から個人として、あるいは友人・知人とのチーム開発ではpythonを用いて開発を行っていました。
正確にはflaskというフレームワークを用いて、pythonは2系でWebアプリケーションを開発していました。
一部開発ではpythonの3系を使っていましたが、過去の開発資材の使い回しやライブラリの都合で2系を使うことが多かったです。

特段不満はなかったものの、フルスタックなフレームワーク、そのなかでも人気を博していたRailsに興味がなかったわけではありません。
開発にハマり始めた頃からRailsは界隈を賑わせていたのですが、一緒に開発していた後輩の趣味(もとい厨二病的嗜好)に引っ張られる形でpython + flaskという構成を覚えてしまい、以降その組み合わせで開発を続けていくに至りました。
今では機械学習文脈でpythonが盛り上がってきているため、身につけたスキルは無駄にはならないどころかむしろ利点になっているので後輩には感謝しています。
ついでにいうとflaskというマイクロフレームワークから馴染んでいったおかげで自分で細かなところまで実装したり、必要なライブラリのみ組み込むスタイルが身についたりという点でも良い経験を積めているなと感じています。

そんな私がRails使いに

仕事の都合でrubyやsinatra、railsを使うことは度々ありましたが、イチからフルで実装した経験はありませんでした。
とはいえフルスタックフレームワークについての造詣が深いとはいえず、かつWeb界隈標準としてサンプルソースがRailsで書かれたりしている流れを組むと、一度本腰を入れて学んでみたほうがいいのでは、と思うに至ったのが昨年末頃です。

その学習の仮定は別途記事にまとめようと思いますが、ざっくり言うと

  1. Railsチュートリアルをざっくり通す
  2. チュートリアルをベースに日記サービスを開発
  3. Ajaxを使ったTODO管理サービスを開発
  4. バッチ処理を多用する某自動生成系サービスを開発
  5. 会社の製品開発にRailsを採択し、メンバーの開発をレビュー(とはいえざっくり)

という流れでスキルを身につけていきました。
そんなこんなで

  • マイクロフレームワークとフルスタックフレームワークの違い
  • pythonとruby、あるいはflaskとRailsの違い

というのをいろいろと考えるようになったのでこの記事として残しておこうというのが趣旨です。前置きが長い。ブログ難しい。

マイクロフレームワークとフルスタックフレームワーク

大言壮語なタイトルですが、実際にはflaskとrailsを使って感じたことです。主語がでかい問題。

Railsを使って最初に思ったのは「ブラックボックスこわい」です。

冷静に考えると発行されたコマンドに応じて内部的にファイルを作成したり、ルールに基づくルーティング・処理が行われているだけなのですが、仕組みやルールが分かるまではオマジナイ的なコマンド・処理が多くて頭を抱えました。
「なぜこのURLにアクセスしたらファイル的には存在していないこんなページが表示されるの?」とか。

flaskの場合は良くも悪くも自分が知らない処理・ページはほとんどないため、全容が把握できたのですが、
Railsの場合は単数形・複数形の自動変換の仕組みやPost時の処理の隠蔽などが躓きどころでした。
今でも時々「このときは複数形で呼び出せばいいんだっけ」と悩むシーンがあります。
ベースとして英語力がないと複雑な変換に対応できないというのもハマりどころ。イレギュラーな変換パターンとか。

いまでは「ここだけ書いておけばあとはRailsさんがよしなにやってくれるよね」と判断つくようになってきたので開発がスピードアップしましたが、やはり前提としてある程度開発に理解がある人が触らないと謎が謎のままになってしまうのでは、と思います。
この点はあまり突っ込みすぎると「アセンブラがー」と手斧を投げてくる人がいるのでこれ以上の言及は避けます。
インターネットこわい。

PythonとRuby

Pythonは今でも好きな言語です。
その出自を背景として、誰が書いても一定のフォーマットに則った書き方になるのでレビューもしやすく、OSSでも読みやすいです。

一方Rubyはやんちゃな感じがします。メタプロとかしているコードを読むと何がなんだか、となるシーンが多々あります。
まだ慣れていないせいかもしれませんが、書き手にとってクールな記法であっても、処理的に合理的な書き方であっても、ついていけない買い方があった途端に処理全体を掴めなくなったりします。

ただ、Rubyの「すべてがオブジェクト」という思想は好きです。たまに謎のメソッド持ってたりしてびっくりしますが。

処理速度が云々とかは気になるレベルで感じたことないので割愛。

エコシステム

一番でかいな、と思ったのはエコシステムです。

得意分野の問題が根底にあると思うのですが、やはりWeb開発をするにあたってはRailsエコシステムは強力です。
大概のことはgemがあるし、Tipsや問題回避法もネットに載っています。しかも日本語情報も多くて助かります。

MySQLでならさくっと調べられることがMongoDBなら出てこない、のもっと極端な感じ。わかりづらいか。

この「情報の量」「gemの豊富さ」によって短期間でサービスを複数作り、実際業務システムの開発までできているという現状に繋がっていると思っています。
ActiveAdminとか感動しました。

おわりに

久しぶりのブログでとりとめもなくなってしまいましたが、今の考え・感想をまとめておくのは大切だと思ったので筆を取りました。
これがまた数ヶ月経つと変わるんだろうなーと思いつつ、どなたかの参考になれば幸いです。

個人的にはマイクロフレームワークで一通り実装する経験を積んでから、フルスタックフレームワークに移行してその便利さを享受する、というのが良いかと思っています。
昔の自分にアドバイスするなら「sinatraで一つ何か作ってからRailsやったらいいのでは。何からやってもどうにでもなるけど。」という感じでしょうか。
pythonは覚えておいて損はないですが、1つの言語でマイクロフレームワークとフルスタックフレームワークを経験するのがスマートでしょう。
とか言いながらDjangoをまともに使ったことないのは秘密。(Django覚えるくらいならRails覚えよう、と思ってました)

なにはともあれ、エコシステム大事ですね。

先人の叡智や残されている資産、およびインターネットに感謝です。

おしまい。

スポンサードリンク

AdSense

AdSense

シェアする

  • このエントリーをはてなブックマークに追加

フォローする

コメントをどうぞ

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です