Secure Vibe Coding Starts Here. Wherever code is built, we keep it secure. Learn more →

12/23の朝方、DHHが以下のツイートを発信しました。 Hotwire aka NEW MAGIC is finally here: An alternative approach to building modern web applications without using much JavaScript by sending HTML instead of JSON over the wire. This includes our brand-new Turbo framework and pairs with Stimulus 2.0 😍🎉🥂 https://t.co/Pa4EG8Av5E — DHH (@dhh) December 22, 2020 取りあえず様子を知りたかったのでDHHのツイートを追ってみました。お気づきの点がありましたら@hachi8833までお知ら
毎年12月25日のクリスマスにアップデートされるオブジェクト指向スクリプト言語の「Ruby」。今回も新バージョンとなるRuby 2.7正式版が予定通り、2019年12月25日にリリースされました。 Ruby 2.7の主な新機能は、case文でのオブジェクトのパターンマッチ、コマンドラインからRubyが利用できるirbにおける複数行編集の対応、コンパクションガベージコレクタ、JITコンパイラ性能の改善などです。 Ruby 2.7の主な新機能 実験的実装による新機能として追加されたオブジェクトのパターンマッチ機能は、case文で使うことができます。 一般にパターンマッチとは文字列などの値に関するパターンの一致や不一致を思い浮かべますが、Ruby 2.7で追加されたのオブジェクトの構造がパターンと一致するかどうかが調べられ、一致した場合に処理が実行される、というものです。 これまでif分などを組
RailsのモデルをフロントのJavaScriptで持っているデータとリアルタイム同期させるためのgem(ar_sync)を作っている。 そのために、俺の考えた最強のシリアライザ(ar_serializer)を作っていたら、ほぼGraphQL互換(mutationはないけど)ぽい作りになった。 せっかくなのでGraphQLのパーサを書いて、GraphiQLが動くところまでできた。 GraphQLは良いぞ ar_serializerについて https://github.com/tompng/ar_serializer queryは、as_jsonとかincludesの引数みたいな(見慣れたものに近い)記法で書く GraphQLのqueryと機能的にはだいたい同じ モデルにガリガリfield書いてく 個人的には書きやすいと思う(typeも指定しなければ適当にassociationとかから引っ
Integration Test / Request Spec ではあくまでもactionのカバレッジを満たすために実行しています つまり疎通確認とactionにおける例外処理のみ spec/graphql/ に、KibelaSchema.execute() を行うspecを追加して必要な単位(queryのfieldやtype)ごとにテストしています test patternのカバレッジはargumentsの違いのみで、たとえばフィールドは全部指定するパターンを1つだけ行ってます .execute() の戻り値は #to_json() して rspec-json_matcher でexpectationを書いています resolverを直接呼ぶテストはしていません tips: RubyMineの場合、 queryを書くときのheredoc tokenを GRAQPHQL にすると、quer
JSONデータ圧縮方式をzstdに切り替えデータ量を38.3%削減した事例、及びマイクロサービスの無停止アップデート事例について紹介したいと思います。 はじめに JPRゲーム事業本部開発基盤部の池田周平です。先日 Rails5対応についてDeNA techブログに投稿 した@namusyakaと同じチームで働いています。 JSON文字列をRDBに格納する際の圧縮フォーマットをSnappyからzstdに切り替え、データ量を削減した事例を紹介したいと思います。本対応を実施した目的はDB負荷対策です。DBで扱うデータをより小さくすることで、DBサーバのDiskI/O負荷とMaster-Slave間のレプリケーション遅延対策を目的としています。 「Sakasho」は、DeNAが持つモバイルゲームのためのプラットフォームです。複数タイトルのゲームを取り扱っており、一部データはゲーム毎の仕様差を吸収し
本記事はRubyについて書かれたものではありますが、Python、JavaScript、Javaなど、全ての言語コミュニティに当てはまる事実を述べたものです。依存関係が引き起こす負の連鎖は誰のためにもなりません。 上の図は、私がこれまでに使用した全てのRailsアプリの依存関係を可視化したものです。以下の例はいずれも、どこかで聞いたことのあるものではないでしょうか。 何百ものエントリを含むGemfile 本番環境で読み込まれるテスト用Gem 数百メガバイトもRAMを食うRailsのプロセス Rubygemsシステムは、それを再利用する誰もが容易にRubyのパッケージを作ることができるという点で、賞賛に値するものです。しかし、その便利さが意味するところは、そうしたGemと他のGemを非常に安易に結び付け、さらにそれが、「インターネットでダウンロード」され、数百もの依存関係を持つRailsアプ
Sendagaya.rb #114に来たので、目標のブログ記事を書いてた。 今日はsendagaya.rbへ行ってブログ記事を一本仕上げるのが目標。— Koshikawa Naoto (@ppworks) August 10, 2015 今日は、React.jsの会なので、RailsからReact.jsをざっくり使って見る準備をしてみます。 目指すもの sprocketsのままとりあえず進む jsのライブラリをnpmで管理したい React.jsをES6で書きたいし、JSX書きたい herokuで動かすぞ! react-railsは使いたくない 方針 sprocketsと共存するために、browserify-railsを利用し、ES6はBabelを利用します。ライブラリはそのまま、npmで管理します。 npmを入れます もし入っていなければnpmを入れましょうね。 brew install
シングルページアプリケーションやモバイルアプリなどの普及により、サーバサイドではJSONを出力するWeb APIの必要性が高くなってきています。みなさんはどのようにWeb APIを作っているでしょうか。 JSONはビュー RailsでJSON APIを定義する時、素のままでやろうとすると コントーラでto_jsonを呼んだり、モデルにas_jsonを定義したりすることになるかと思います。 モデルに書くとAPIによって出力内容を変えたい場合にとても苦労します。 API数が増えれば増えるほどモデルが複雑になっていきます。 APIレスポンスとしてのJSONはコントローラやモデルに書くべきでしょうか? ビューに書いた方が自然ではないでしょうか? これはRailsでの話ですが、Railsに限らず、フレームワークを使ってWeb APIを作るときに一般的にあてはまることだと思います。 変化に強い、再利用
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く