Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
はじめに ここ数年は毎年リリースされてきたRuby on Rails (以下Rails)の新しいバージョンですが、今回はメジャーバージョンアップグレードの6.0（以下Rails 6)となり、2019年8月にリリースされました。 Rails 6では、Action TextとAction Mailboxの新しい2つのフレームワークの導入を始め、複数データベースや並列テストへの対応など、メジャーバージョンアップグレードにふさわしい大きな機能追加が行われています。 本記事では、GitHubのRailsプロジェクトのIssuesやPull Requestsの内容をもとに、Rails 6の主要な新機能・機能追加・変更点の紹介を行います。 ※ 以前のバージョンのRailsの主要な新機能・機能追加・変更点については以下を参照してください。 今から知っておきたいRails 5の新機能・変更点 - Qiita
この記事は RubyそしてRailsをこれから勉強したい方に、どんな技術を勉強すればいいかと、それらの技術全体のガイドマップを図示します。そしてそれを学ぶための資料（書籍、Web記事ほか）を紹介していきます。この記事は、頭の中に技術全体の地図を描き、イメージしてもらうのが狙いです。 Railsアプリを作るときに必要になたくさんの技術について説明していきますが、本当にたくさんの技術が出てきます。まだ学んでいない、分からない言葉が出てくると思いますが、全体を把握するために、ひとまずは「そういう技術があるのだな」くらいで捉えてもらえればと思います。将来、その言葉が出てきたときに「どこかで聞いたような？」と思えたら儲けものです。 勉強方法のお勧めは、1つの知識を徹底的にやるよりも、まずは全体を通して勉強し、そのあとで勉強したいところに戻って積み重ねて学んでいく方が、挫折しづらいのでお勧めです。 追
はじめまして、2018年7月入社の sue445です。自称「フルスタックキュアエンジニア」です。最近はpixiv PAYのチームでRailsを書いたり社内gemを作ったりしています。 好きなプリキュアはキュアピースです。 前置き 先日Rails 5.2.1がリリースされました https://weblog.rubyonrails.org/2018/8/7/Rails-5-2-1-has-been-released/ pixiv PAYでもその対応を行っていて、先日本番環境にRails 5.2.1を投入しました 💪 ググると特定のバージョンでのアップデート方法はいろいろ見つかるのですが、どのバージョンでも使える汎用的な方法が意外になかったので紹介しようと思います。 Rails 4.1系以降はだいたいこの方法でアップデートしてきたのでそれなりに実績のある手法だと思います。 筆者スペック 初め
こんにちは、バックエンドエンジニアのじょーです。大規模なサービスのAPIを開発する際に、ルールを決めずに開発していると無秩序なコードが散見される運用がしづらいAPIになってしまいます。また、ルールを決めたとしても共有が上手くいかないなどの理由で守られなくなってしまうこともあると思います。 本記事では、APIを運用しやすくするために、ただルールを決定しただけではなく、ルールを守るためにそれぞれ仕組み化をしたことを紹介します。 APIのレスポンスを統一する デコレーターを使ってレスポンスの定義を綺麗に書く パラメーターを統一する Validatorによりパラメーターの明記を強制する コーディング規約を守る LinterとSideCIを導入して修正とレビューの自動化 Linterのルールを適度に調節する 1. APIのレスポンスを統一する ここで言うAPIのレスポンスを統一するというのは、返すA
みなさんこんにちわ。 メドピアでエンジニアをやっている内田と申します。 現在メドピアではPHPで作られたレガシーな独自フレームワーク (以下FW) からRailsへと移行するプロジェクトが進んでいます。 今回は移行に向けて行ったことについて共有したいと思います。 移行の計画 メドピア株式会社では、医師限定のコミュニティサイト「MedPeer 」を運営しています。 「MedPeer 」サービス内では、薬剤評価掲示版、症例相談、Forum、ニュースなど、医師同士が情報交換をするための、機能の異なる複数のサービスを提供しています。 それらサービスの内部では7年前に作られたPHPの独自FWが採用されており、コードが肥大化したことで機能の変更や追加がとても困難になっていたことが課題でした。 そうした課題を解決するために、アーキテクチャの見直しを含めたリプレースがエンジニアの主導で計画されました。 様
ここで言う「Railsの中身のコード」というのはRailsを使ったRailsアプリのコードのことではない。Railsそのもののコード。DHHが書いたRailsのコード。$ rails new AppNameとかのコマンドが動く仕組みが書かれたコードのこと。 これって職場の同僚と英語で話しててもいっつもゴチャゴチャと説明が要る。RailsアプリのコードとRailsの中身のコードを区別してそれが一発で分かってもらえる表現があったら教えて欲しい。 既にご存知の方はたくさん居ると思うがそのRailsの中身のコードというのが巨大でなかなかにレベルが高い。初心者では読むのも一苦労でそこが遠ざけてしまう原因にもなっている。それでも優れたコードをコードリーディングすることはエンジニアにとってとてもいい勉強になるのでオススメ。 いかにコードリーディングが重要かは、いろんなブログなんかで優秀なエンジニアの方々
@joker1007 self.inspect @joker1007 パーフェクトRuby, パーフェクトRails 著者 Asakusa.rb, Yokohama.rb, Shibuya.rb データ分析基盤構築, Bigquery, インフラ全般 fluent-plugin-bigqueryメンテナ (株)Repro 宣伝タイム 現在のECSの活用状況 主要システムはほぼECSに移行完了 メインWeb, API, 各種非同期処理ワーカー クラスタは基本で15台 ASでその倍から3倍ぐらいまで増える 開発者用ステージング、QA環境等にも利用 何故ECS化したのか ミドルウェアのバージョン管理の容易さ Ruby, nginx, fluentd ... TaskDefinitionのリビジョンでロールバックできる 無停止デプロイメントの簡易化 AutoscaleのためのAMI管理不要 pul
クックパッドの社員が発表するCookpad TechConfというイベントの第一回が今日行われ、「Railsアプリ開発環境の高速化」というテーマで話してきた。 開発環境の改善について 僕が技術部に入る前、サービス開発をやる中で一番不満だったのが開発環境のパフォーマンスだったので、技術部に配属されたころからこの仕事をやりたいと思っていた。 今回は先輩方が既に行っていた開発環境のパフォーマンスチューニング - クックパッド開発者ブログの一部を紹介しつつ、その続きとして自分がやってきたことを発表した。 業務で出した成果のうちいままで外部で発表したのはbyebugの高速化くらいだったので、普段僕がどんな仕事をやっているのか紹介する良い機会になった。 発表内容の補足 思ったより15分の枠で話せたことが少なかったので、発表内で話し足りなかったことについて書く。 libsassおすすめです 急いでて全然
Since Redmine’s codebase was in a pretty poor shape I started a daily series to refactor it and show how I did it. This series ended up being used as the source for Refactoring Redmine (after a bunch of editing). Get the full ebook Daily Refactor #1: Extract Method in the BulkTimeEntriesController – saving a new TimeEntry Daily Refactor #2: Move Method in the BulkTimeEntriesController – saving a n
Highlights in Rails 5.0: Action Cable Rails API Active Record Attributes API Test Runner Exclusive use of rails CLI over Rake Sprockets 3 Turbolinks 5 Ruby 2.2.2+ required These release notes cover only the major changes. To learn about various bug fixes and changes, please refer to the changelogs or check out the list of commits in the main Rails repository on GitHub. 1 Upgrading to Rails 5.0If y
こんにちは。技術部の国分 (@k0kubun) です。 3/28にクラウドワークスさんで行なわれたRails Upgrade Casual Talksで、Railsアップグレードの際にクックパッドが行なっている工夫について紹介しました。 影響範囲の予測が難しいRailsのアップグレードを安全に行なうための動作確認のやり方について参考になればということで、本記事でも改めて紹介いたします。 CookpadのRailsアップグレードの流れ Rails 4.1から4.2にアップグレードした際の例を紹介します。 CIにRails 4.2用ジョブを用意 まずはRails 4.2にアップグレードするためのrails42ブランチでテストを通します。リリースするまでこのブランチはmasterからrebaseし続けるので、リリースまでテストを通る状態を保つため、CIにrails42ブランチ用のジョブを用意しま
私たちの救世主DHH™は最近の Full Stack Radioのインタビュー で、 Basecamp の最新版で彼がどのようにRailsのコントローラを書いたかを説明しています。下記は、彼のすばらしい話を書き取ったものです。 これまでに思うようになってきたのは、「RESTの原則に従うには、どのタイミングで新たなコントローラを作るべきかを一度決めたら、ほぼ異例なくその原則を遵守するべきだ」ということです。いつだってその方がうまくいくんです。自分の作ったコントローラの状態を悔やむのは決まって、作ったコントローラの数が少なすぎた時です。多くの処理を任せようとしすぎてしまうんです。 そこでBasecamp 3では、ある程度理にかなったサブリソースがあれば、毎回コントローラを分割していきます。フィルタなどの場合ですね。例えば画面があって、それがある状態になっているとします。もしこれにいくつかのフィ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く