When teams use Code Climate to improve the quality of their Rails applications, they learn to break the habit of allowing models to get fat. “Fat models” cause maintenance issues in large apps. Only incrementally better than cluttering controllers with domain logic, they usually represent a failure to apply the Single Responsibility Principle (SRP). “Anything related to what a user does” is not a
ちなみに、最初に結論だけ言っておくと、まずSandi Metzの「オブジェクト指向設計実践ガイド」を読め、という話です それだけで終わってしまいたい気持ちはあるが、不親切過ぎるしもうちょっとRails向けの話を書こうと思う。 ただ言いたいことは、よく分かってないのに使うのは止めろということ。 自分も本で書いたりした手前、それが参考にされた結果なのかもしれないが、世の中には本当に酷いクラスが存在するもので、雑にサンプルで書くと以下の様な感じのコードが存在したりする。 class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.activ
この資料で説明している ActiveRecord::BiTemporal は https://github.com/kufu/activerecord-bitemporal よりアクセスできます。 以下、セッション説明: データはWebアプリケーションの中心であり、最も重要なものです。私の勤めるSmartHRでも、人事情報を軸とするWebサービスを展開する事業者として最大限の注意を払って運用を行っています。 データは活動によって刻々と変わっていくものですが、通常のWebアプリケーションでは最新の情報しか表現できていません。そのため、いつ・どのような変更を加えたのかを知りたい、あるいはある時点の情報にアクセスしたいといった要望には応えることができませんでした。SmartHRでは入退社や被扶養者の追加など多様なライフイベントに応じてデータの変更が発生するため、その変遷も表現したいというニーズが
本READMEの他に、以下のWebpacker公式ドキュメントの歩き方記事もどうぞ。これら2本で、Webpackerの公式ドキュメントは概観できるかと思います。次は公式のユースケースが欲しいです🍰🍵。 【保存版】Rails 5 Webpacker公式ドキュメントの歩き方+追加情報 概要 MITライセンスに基いて翻訳・公開いたします。 READMEリポジトリ: webpacker/README.md at master · rails/webpacker 原文更新日: 2018/05/18 ライセンス: MIT 更新や誤りにお気づきの方は@hachi8833までお知らせください。 Webpackerを用いることで、JavaScriptのプリプロセッサ兼バンドラーであるwebpack 4.x.x+を簡単に使えるようになり、アプリ的なJavaScriptをRailsで管理できます。Webpa
株式会社iCAREでは、Vue2.6(※2.7に移行中)+Composition APIで開発を行っており、vue2系では比較的モダンな構成です。一方、Ruby on RailsのView毎にVueインスタンスを生成するMPAであり、アプリケーション全体の構成としては、レガシーな構造になっています。 エントリーポイントが多いことによる弊害で、サービス拡大に伴いビルド時間は長くなり、最近では開発サーバーの立ち上げに約2分も掛かるようになりました。これを改善すべく、Vue2.7化と併せてビルドシステムのWebpackからViteへの移行を試みています。 SPAへのVite導入等に関しては記事がありますが、レガシーなMPAアプリケーションでのVite移行に関する記事はあまりなく、移行できるか?等の不安や疑問を抱きながら実装を進めています。本LTでは、この取り組みを通して得た知見を共有させて頂きま
認証認可とワンセットで語られることが多い印象だが、今回話すのは「認可(Authorization)」の話だ。「認証(Authentication)」の話は含まない。 (システムで言う)認可とは、大雑把に言うと「誰が」「何を」「どうすることが」「できる/できない」の要素に従って判定することだ。 どちらも略すと「Auth」になってしまってクラス名が衝突したりするので困ることがある。区別するために認証はAuthN、認可はAuthZと略されることがある。「WebAuthn」などは一例と言えるだろう。 弊社内ではまず話題になってこなかったため、実装の話が流れたとき、非エンジニアからは「認可?権限と何が違うの?おいしいの?」といった声が聞かれたり聞かれなかったりした。 認可制御の種類 MNTSQで採用した認可制御 認可のrailsのgemの紹介 pundit cancancan MNTSQの認可制御の
こんにちは、@f_subal です。普段はおもに pixivFACTORY のフロントエンドを見ています。 今回は pixivFACTORY において、フロントエンドのビルドに Webpacker を利用するのをやめた話をします。 Webpacker をやめよう rails/webpacker は Ruby on Rails のプロジェクトに webpack を導入する際に用いられる gem です。必要な webpack の設定ファイルの生成や、Rails のテンプレートからビルド済みの JavaScript ファイルを読み出すために用いるヘルパー関数など、多数の機能を提供します。 結論から言うと、Webpacker を入れてもあまり良いことがありませんでした。単に必要が無いというより、あることによって面倒が増していると感じたので、剥がしました。以下 Webpacker が導入された Ra
iCARE の提供しているサービス Carely では 2020年の 10月から半年ほどかけて Webpacker からの脱却を行いました。似たような記事はいくつかありますが、まったくの未着手から解説したものはないと思うので、記録をかねてまとめました。長めの記事になりますが同じことで困っている方の参考になれば幸いです はじめに - Carely の構成について もともとは Rails5 のスタンダードな構成だったものを、 Webpacker を導入して GraphQL + Vue2 の構成に移行。SPA ではなくエンドポイントごとにエントリーポイントがあるような構成になっています ルーティングなどは Rails に則りつつ、画面はほぼ Vue2 で構成されています。もちろん古い slim + sprockets の画面も残っているため coffee script のファイルも一部健在です
言いたいこと webpackをあまり知らない人がwebpackerを用いることで簡単に導入できるけど以下のことはちゃんと知っておいてほしかったり、考えてほしい。(切実) ビルドはRubyからコマンド実行してるけど、実際に発行しているnpm scriptはwebpack(-dev-sever) --config config/webpack/(development|test|production).jsなんで覚えておけ。 デフォルトでmultiple entryになっているのでSplitChunksPluginかCommonsChunkPluginの設定はとりあえず入れておけ。 本当にwebpackerは必要ですか?時期が来たら捨てろ。 webpackerの落とし穴 昨今では当たり前となっているwebpackの導入をwebpackをあまり理解していない人が簡単に入れれるという特徴がある。こ
September 6, 2021 Rails 7 will have three great answers to JavaScript in 2021+ Rails has been unapologetically full stack since the beginning. We've continuously sought to include ever-more default answers to all the major infrastructure questions posed by modern web development. From talking to a database, to sending and receiving emails, to connecting web sockets, to rendering HTML, to integrati
スタディスト開発ブログ Advent Calendar 2021の20日目の記事です。本日は技術支援ユニットの笹木(@s_sasaki_0529) が、開発環境で Rails を立ち上げずに、リモートAPIサーバに接続してフロントエンド開発を行えるようにした話をします。 TL;DRSPA なのに Rails と Vue が密になってるアプリケーションを開発してるせめて開発環境ぐらいはフロントエンド単体で開発できる状態にしたい様々な問題を対処し、理想のフロントエンド開発環境を実現したTeachme Biz の現状のアーキテクチャスタディストが開発・運用する、マニュアル作成・共有システム Teachme Biz は、Vue.js (≠ Nuxt.js) によるフロントエンドと、Ruby on Rails によるバックエンドで構成されています。 Teachme Biz (Web) の大雑把な構成
Ruby言語によるWebアプリケーションフレームワークの最新版となる「Rails 7」が正式リリースされました。 Rails 7.0 FINAL: The fulfillment of a vision to present a truly full-stack approach to web development that tackles both the front- and back-end challenges with equal vigor. https://t.co/WxJ0nKYfE7 — Ruby on Rails (@rails) December 15, 2021 Rails 7の最大の変更点は、フロントエンド開発環境が刷新されてNode.jsを用いない構成がデフォルトとなったことでしょう。 Rails 6では、優れたフロントエンド開発環境を実現するためにトランスパ
はじめに 僕が代表をしている株式会社KOSKAでは製造業の原価管理をIoTで自動化するGenkanというサービスを提供しております。 そんな弊社では半年前、バックエンドをRoRからScalaに移行したのですが、これが素晴らしく効果が高かったので以下の記事を書きました。 スタートアップである弊社が全員ほぼ未経験でRoRをScalaに移行した理由、その効果と苦労点 しかし、最後に書いたのですが、苦労する点もとても多いです。 弊社CPOが苦労する点を抽象的な部分に関しては以下の記事で書いてくれてはいます。 0からScalaを本番導入して感じたこと・考えたこと - Qiita ただ、実際にコードを書き始めた時に引っかかりやすい点をできるだけ詳しくあげておくことで、導入しようと考えた人がなるべく簡単に導入できるという状況を作りたかったので、書きました。 それではスタートです。 RubyやPHP、Py
すろっくさんです。 tl; dr 2019年7月末でBASE株式会社を退職します思い出話今後のこと 誰? このアイコンの人です。 Rubyとインフラのエンジニアのすろっくさん(@srockstyle)です。今まではRuby on Rails使ってWebアプリケーションの設計・構築・運用、サーバ・ネットワークの設計・構築・運用の自動化、Chef / puppet / ansibleなど構成管理ツールやserverspecなどのツールの導入、Infrastructure as Code的な仕事をしてました。それらの知識を合わせてAWS-SDKやGithubのAPIを使っていろんなものを操作するアプリケーションも書いてました。BASEではそういった経験を活かしてWebアプリケーションより一階層下のレイヤー、インフラの知識を持つソフトウェアエンジニア、SREという仕事してました。 Twitter:
【爆速】React+Amplify+AppSyncでリアルタイム掲示板アプリを15分で作り上げる 〜これが最高のDeveloper Experienceだ〜JavaScriptAWSReactamplifyAppSync Railsを使って15分でブログアプリを作り上げる動画が一斉を風靡したのはもう何年前でしょうか。 私はまだその頃Developerですらいなかったですが、いまその動画を見ても感動してしまいますね。 Webのアーキテクチャは進化し、API非同期通信、フロントエンドとバックエンドの分離、仮想DOMによるフロントエンド描画、GraphQLバックエンドの台頭といった具合に圧倒的な進化を遂げてきました。 では、この技術スタックを使ってRailsを使ってブログアプリを作り上げることと同様のことがどれだけの開発効率で実装できるのでしょうか? 今回はAmplifyCLIとReactを使っ
エンジニアの @suusan2go です。2017年の10月まではクラウドワークスに社員として参画していましたが、現在はフリーランスのエンジニアとして、主にフロントエンド環境の改善・支援を行ったり、ちょっとだけRailsのアップグレードを手伝ったりしています。 Railsのアップグレードを手伝っている様子 Sprocketsを2=>3にあげると数倍メモリ消費増えるのなんなんだろな— すーさん二号 次に夜飲みにいけるのは8月ごろになります (@suusan2go) 2019年5月7日 Sprocketsがメモリを大量に消費する問題、結局よくわからんかったので、馬鹿でかいjsを生成する js.erb をなんとかした— すーさん二号 次に夜飲みにいけるのは8月ごろになります (@suusan2go) 2019年5月17日 今回は、わかるエンジニアがいなくなり無人化してしまいメンテナンス不能になっ
最近のフロントエンドに関するお気持ち。正直まとまってはない。 最近、こんな感じのツイートや記事が増えた。 web 技術をキャリアの中心にしない シングルページアプリケーション (以下SPA) の台頭により、私の観測範囲ではモダンな Web サイトは SPA で作られるようになった。サーバーサイドは JSON を返す API サーバーとなり、DB やバックエンドシステムのプロキシのような存在になりつつある。 私はサーバーサイドエンジニアとしてキャリアを積んできた。SPA が流行りだした頃、いずれサーバーサイドエンジニアは不要になって自分のキャリアを考え直さなくてはいけない時期がくるのではないかと戦々恐々としていた。 自分も元々、SPA を他サイトとの「差別化技術」と定義していた。ブラウザのタブページのライフサイクルにおいて、初期化プロセスを一回にまとめてシームレスな遷移を実現する技術。たとえ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く