Rakeで俺たちはもっとtmuxと仲良くなれるんじゃないか？と思った - 愛と勇気と缶ビール
gist: http://gist.github.com/557598 きのこかたけのこかと問われればたけのこ、犬か猫かと問われれば猫、VimかEmacsかと問われればVim、screenかtmuxかと問われればtmux。 というわけでtmuxを使っているのだけど、一年くらい使っているにも関わらず「新しいウィンドウ（端末）を開き、そのウィンドウで任意のコマンドを実行させる方法」を知らなかった。 昨日分かった、そのやり方をbash/zshの関数で書くとこんな感じ。 hoge() { tmux new-window -a -n $1; tmux send-keys -t:$1 "do something" C-m } ("-a"はtmux1.3からのオプションで、このオプションをつけると現在のウィンドウの真横に新しいウィンドウを開ける。） tmux new-window -n で新しいwind
ぼくがかんがえたさいきょうのRails API開発環境 - Qiita
今やっているバイトでRails APIを作成しています。 APIを作成する際に、以下のような問題点が出てきました。 APIのdocumentがないとフロントエンドの開発者が開発しづらい documentを書くのにopenapiを採用するが、文法を覚えるのに一苦労するし、見づらいので書き忘れが生じる。 API responseの構造に開発者間で違いが出てしまう。 実際のAPIとdocumentの挙動が違うのに修正を忘れてしまう 結論 結論から言うと、これらの問題を解決するために以下のようにしました。 APIのPRを出す時にopenapiでdocumentを書く。 SpotlightStudioを使ってopenapiを書く。 responseの形はJsonAPIに従い、gemにfastjsonapiを導入する。 committeeというgemを使って実際の挙動とopenapiに書かれていること
GraphQL Ruby でクエリの複雑度をレスポンスヘッダで応答する - Qiita
概要 GraphQLでクエリをしたときにそのクエリの複雑度がどの程度だったのかを把握したくなることがあります。 この問題を解決する手段として複雑度をHTTPレスポンスヘッダで応答できるようにしてみます。 このAPIデザインがどの程度一般的なのかはちゃんとわかっていないのですが、Contentful の GraphQL Content API にはレスポンスヘッダで複雑度を応答するデザインが含まれていましたので特別に異常なことではないでしょう。 コード 複雑度の計算をするアナライザとして GraphQL::Analysis::AST::QueryComplexity が標準で提供されていますので、これを継承してアナライザーを実装します。 OverseQueryComplexityComplexityAnalyzer をクラスを作り、#result メソッドをオーバーライドし 、ここではGra
Railsで作ったシステムのER図を日本語で出してほしいと言われたときにやったこと - Qiita
Ruby on Railsを使った開発をしていると「システムのER図が欲しい」といったお願いされることがあります。 Railsを使っているのであれば、rails-erd というRubyGemを使うことで簡単にER図を出力できます。 rails-erdで出力されるER図はEntityもAttributeも全て英語です。 提出先がエンジニアである場合や、普段からモデル名を使ったコミュニケーションをしている場合であればこのままでもなんとかなるかもしれません。 一方、相手がビジネスサイドのメンバーである場合や、普段はモデルを日本語変換してコミュニケーションしている相手の場合はこのER図をそのまま出しても困惑されてしまいます。 そこで、今回はなんとかしてEntity・Attributeを日本語化できないか検討しました。結論とそこに至った過程をメモしておきます。 結論 結論としては、rails-erd
Ruby 3.3.0 Rails 7.1.3 でYJITを有効にする - Qiita
if defined? RubyVM::YJIT.enable Rails.application.config.after_initialize do RubyVM::YJIT.enable end end 運用中に何かの理由で無効にしたくなったら、コメントアウトするかファイルごと削除します。 この方法は、最新のRuby on Railsに取り込まれているそのままです。 YJITとは Rubyを高速に実行する機能です。Ruby 3.3 から Ruby on Rails に適用するのも実用的になったそうです。次の記事で詳しく説明されています。 Ruby 3.3 YJITのメモリ管理とRJIT 〜すべてが新しくなった2つのJITを使いこなす | gihyo.jp RubyはJust-In-Time（JIT）コンパイラという機能を備えており、これを有効化すると実行時に機械語を生成して様々な最適
Rails のブラウザテストを Playwright で動かすようにしたらデバッグが簡単になって捗った - Qiita
Rails, RSpec でブラウザテストというと System Spec, Feature Spec などが挙げられます。バックエンド、フロンテエンド両方を End-to-End でテストするには便利ですが、複雑さ故に、たまに落ちるテストになってしまったり、落ちたときのデバッグが大変という難しさがあります。 Qiita でも主要な機能 (エディタ、記事ページなど) をテストするのに使っているのですが、CI で時折よくわからない理由で落ち、 更に何故落ちたかの再現や調査が難しい というのが結構つらいポイントでした 今回 Qiita で RSpec で利用するブラウザ自動化ツールを Selenium から Playwright を使うように置き換えたら、かなりデバッグが行いやすくなりました 移行自体も Cabybara 用の Driver を使うことで、大きく書き換えることなく移行することが
Ruby で Quarto を活用する - Qiita
これは Ruby アドベントカレンダー 2022 の23日目の記事です。 Quarto とは何か？ Quarto は、Pandoc 上に構築されたオープンソースの主に科学技術分野での利用を想定した出版システムです。 Quarto は下記の特徴を持つ、と https://quarto.org/ は主張しています。 Python、R、Julia、および Observable を使用して動的なコンテンツを作る。 ドキュメントをプレーンテキストのマークダウン、または Jupyter ノートブックでもって執筆する。 高品質の記事、レポート、プレゼンテーション、Web サイト、ブログ、書籍を HTML、PDF、MS Word、ePub などで公開する。 数式、引用、相互参照、図パネル、吹き出し、高度なレイアウトなどを含む、科学に関するマークダウンを用いて執筆する。 2 番目のリスト項目内の「マークダウ
【RubyKaigi2023】debug.gem 1.8.0 で Ruby のデバッグをしてみる【VSCode】 - Qiita
はじめに Qiita株式会社でエンジニアをしている @wataru86 です。 Qiita株式会社は RubyKaigi 2023 に Platinum Sponsor として協賛・ブース出展しています！ 僕もそのメンバーとして、現地で参加していました。本記事では、2日目の @ono-max さんによるセッション「Introduction of new features for VS Code debugging」で発表された debug.gem v1.8 の機能の概要と、実際に使う方法について簡単に説明します。 また、発表時のスライドは以下に公開されていました。 debug.gem debug.gem は Ruby3.1 からデフォルトでRubyに同梱されている gem です。ソースコードは以下リポジトリにあります。 debug.gem 自体は以前から存在していますが、 先日公開された
ここがいいよねGraphQL - Qiita
こんにちは。フリーランスで、主にRailsを使った開発の仕事をしている ymstshinichiro と申します。 直近約3年GraphQLの現場で仕事をしつつ、今年4月からはOpenAPIの現場でも並行で稼働しているのですが、両方を使ってみて個人的にGraphQLのここが良いなと思ったポイントをまとめてみました。 おことわり: 「これからGraphQLを使っていくべきか迷っている」という方へ向けた記事になったので、既にGraphQLをガンガン使いこなしている人には当たり前のことしか書いてないかもです あくまで僕の 好み・主観・経験 に基づく記事なので、その辺考慮の上で読んでいただけると助かります 記事中のサンプルコードはRailsで書かれています GraphQLを使うと自然にCQSに近づく 先日、YOUTRUSTさんが主催する実際のproductionコードを見ながら会話する勉強会 に参
最小限のテスト容易性を確保するための一提案 - Qiita
要約 システムの保守性をあげるために自動テストを書くのは良いアプローチといえる しかし自動テストを書く時間がなかったり書くスキルがないメンバがいるという諸事情はよく発生する そうした時は最初(書き始め)のタイミングで、テスト対象のクラス・メソッドの処理を最後まで処理が通る1ケースだけ書こう このアプローチはシステムの保守性をあげるだけではなく、個人・メンバのスキルアップにも繋がることがある テスト容易性とは テスト容易性をGoogleで調べると難しそうな話が出てきますが、本記事では テストがしやすい というふんわりとした言葉の意味合いで使っていきます テスト容易性はシステムの保守性を支える1要素ともいえ、このテスト容易性を高めることでシステムの保守性を少しでも高めることができるものです。(もちろん銀の弾丸ではありません) 質とスピード by t_wadaさん テスト容易性をあげるアプローチ
RSpecでit / example / specifyはどのように使い分けるのか？〜日本語で書くならexampleって本当？〜 - Qiita
RSpecでit / example / specifyはどのように使い分けるのか？〜日本語で書くならexampleって本当？〜RubyRailsRSpec はじめに 最近ときどき「RSpecでit/example/specifyをどのように使い分けたら良いのか」という話題を見かけるので個人的な私見を書いてみます。 使い分けに何か決まりはあるのか？ → 技術上の決まりは何もありません it/example/specifyは技術的にはまったく同じメソッドです。なので、itをexampleやspecifyに置き換えても問題なく動きます。 # itを使う it 'adds numbers' do expect(1 + 1).to eq 2 end # itの代わりにexampleを使う example 'adds numbers' do expect(1 + 1).to eq 2 end # i
cancancanのテストをRSpecで書く - Qiita
cancancanを使った際、テストに学びがあったので投稿します。 前提：cancancanとは 権限による制御が簡単にできるgemです。 cancancan Rails|CanCanCanの使い方解説 ↓私も1つ記事を書きました。 cancancanでモデル名に紐づかない制御をする方法 cancancanのテスト requestスペックなどで特定の権限が各アクションを実行できるかどうかをテストする方法もあると思いますが、今回はcancancanが用意しているmatcherを使ってテストする方法を紹介します。 参考 https://github.com/CanCanCommunity/cancancan/blob/develop/docs/testing.md require "cancan/matchers" describe "User" do describe "abilities"
リーダブルRSpec（カスタムマッチャー+RSpec::ContextHelper編） - Qiita
読みやすいRSpec書いていますか？ 読みやすいRSpecって何？ 「簡潔でテストケースを見てテスト内容が理解しやすいもの」と考えています ここでのテストケースとは、it/exampleブロックのことを指しています 例題 例えば、Rails製REST APIのRequest Specを書くことを考えてみます コードは正しいか確認していないので、多少間違っていてもお許しください🙇 前提 APIはたくさんある 良くないけど、クエリパラメータのチェックをcontrollerでしているため、テストはRequest Specで行う APIの共通仕様 Server Errorを除き、HTTPステータスコードは必ず200で返す HTTPレスポンスボディはJSON形式で返す 成功時のレスポンス
最近思うrspecをシンプルにする書き方（オレ流） - Qiita
rspec書き方指南ではない 最近自分でやってみて、テストが意外に楽に書けるのではないかと思うやり方をまとめてみた。 ベストだとか唯一の書き方だとかそういう事を言いたいわけではない。各自自分の好きなやり方で書けばいいと思う。最終的には自分の書いたクラスがちゃんとテスト出来ていれば目的は達成している。 個人的な主観としてテストは出来るだけシンプルにしたい。そうじゃないと個人的にテストを書くのが嫌になるし、テストが間違ってて、そもそも何をテストしてるのか？という事になりたくない。 と言うことを解決できるのではないかという投稿。 要点 クラス内のメソッド（処理）は出来るだけシンプルにしたい 一度しか呼ばれないようなロジックでもメソッドに落とし込みたい メソッドが増える分、内部のメソッドと外部向けのメソッドをちゃんと意識する itに説明は要らない テスト中に使用する変数内容は実際の条件を意識しない
AWS SDK Rubyでスタブを行う - Qiita
はじめに AWS SDKを使用したコードに対してテストを記述したい場合、AWSのSDKで用意されているClientStubsを使用して、スタブを行うことが可能です。 ドキュメント自体は公式が出しているものがありますが、この例だけではやりたいこと（Aws::S3::Client以外のインスタンスを使うケース）が実現できなかったので、今回調べたことについてまとめました。 環境 Ruby: 2.7.1 aws-sdk: 3.1.0 aws-s3-sdk: 1.114.0 公式ドキュメントから このドキュメントにあるようにAws::ClientStubsというモジュールが、各サービスに対応したClientクラスにincludeされています。 今回はS3を使って、その例を紹介します。 このモジュールに定義されているのはapi_requests, stub_data,stub_responsesの３つ
RSpecでElasticsearchを使用しているモデルのテストでのみインデックスの初期化を行う方法 - Qiita
TL;DR RailsのメソッドをRspecでテストする際に、Elasticsearchを使ったモデルに対してのテストの実行時にのみ、実行前後でElasticsearchのインデックスを初期化する処理を入れる方法です。 やりたかったこと elasticsearch-railsgemを用いたRailsのアプリケーションにおいて、下記のようにElascticsearchを用いて検索や絞り込みを行うメソッドを実装しました。 class SampleClass < ApplicationRecord def search(filter_ids, target_ids: [], min_price: nil, max_price: nil, size: 200) __elasticsearch__.search({ size: size, query: build_query(filter_ids,
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RubyでつくるRubyみたいな言語のコンパイラ
フレームワークを作らない方法/How NOT to build frameworks
技術的負債の借り換え on Ruby and Rails update
RubyKaigiのプロポーザルを通したい。 / rubykaigi-proposal
