実現したいこと bundle exec rails でアプリを立ち上げた後、アプリ画面を開くと以下のエラーが出力されるため解決したいです。 前提 Ruby on Railsで作成したアプリのバージョンアップデートを行なっております。 ローカル環境で作成していたため、作成当初の環境がなく最新バージョンをインストールして実装中です。 エラー内容として :scheme と :namespace がRedis初期化時に渡されるが、 Redis側で認識されないためエラー出力される認識です。 発生している問題・エラーメッセージ ArgumentError (unknown keywords: :scheme, :namespace): redis-client (0.14.1) lib/redis_client/config.rb:21:in `initialize' redis-client (0.

stack level too deep エラーの解決について 今回上記エラーによりrails s およびrail c（というか多分全railsコマンド）ができなくなり、その解決方法を備忘録的に記載しておきたい。 症状 => Booting Puma => Rails 5.2.0 application starting in development => Run `rails server -h` for more startup options Exiting Traceback (most recent call last): 11639: from bin/rails:4:in `<main>' 11638: from bin/rails:4:in `require' 11637: from /home/ec2-user/.rvm/gems/ruby-2.6.3/gems/rail

はじめに テストコード一般の考え方 壊れにくいテストを書く 実装した通りに動作することではなく、仕様通りに動作することをテストする テストコードはシンプルにわかりやすく書く 失敗の原因がわかりやすくなるように意識する RSpecの書き方 テストケース名をitの引数で明記する letよりもlet!を使う 通常の変数と同じ方針に基づいてlet!を利用する subjectを使わない 不要なcontextでのネストを避ける matcherを適切に使い分ける factoryのデフォルト値に依存しないテストを書く 参考にしたブログ記事等 付録：RuboCop設定 We are hiring! サムネイル画像 はじめに テストコードを書く習慣も、近年ではかなり一般的なものになってきました。 ドワンゴ教育事業のバックエンドチームでも自発的にテストコードを書く文化は根付いており、実際に計測はしていませんが、

ブログ用に使用しているEC2の使用メモリを調査したいなあと思ったので、AWSのCloudWatchでEC2のメモリを視覚的に監視できるよう設定しました。少しハマったのでメモ。 CloudWatchとは ログの収集や監視を行うAWSのマネージドサービスです。公式には以下のように紹介されています。 CloudWatch は、ログ、メトリクス、およびイベントという形式でモニタリングデータと運用データを収集し、AWS とオンプレミスのサーバーで実行される AWS のリソース、アプリケーション、およびサービスの統合されたビューをユーザーに提供します。CloudWatch を使用して、環境内における異常動作の検知、アラームの設定、ログとメトリクスを並行させた視覚化、自動化されたアクションの実行、問題のトラブルシューティング、およびインサイトの検出を行い、アプリケーションのスムーズな実行を維持することが

ActiveRecord には SSL によるデータベースアクセスをサポートする機能が付属しているので、それを使って通信を暗号化してみます。検証には VirtualBox にインストールした CentOS 5.6 を使用し、作業はすべて root ユーザで行いました。 前提 mysql と openssl は yum からインストールしており Rails アプリケーションを通常の方法で動作させる環境は整っているものとします。 証明書の作成 今回は動作の確認が目的なので、自己証明書を使ってテストします。証明書の作り方は以下のアドレスを参考にしました。 http://blog.livedoor.jp/burtman/archives/51962114.html 記事中で www.hoge.com となっている箇所を 192.168.1.156（テスト用仮想マシンのプライベートIP）に置き換えて

pdf = render_to_string pdf: "#{params[:id]}.pdf", #PDFファイル名 template: "xxx/show.pdf.erb", #ビューファイル encoding: "UTF-8", layout: "pdf.html" #レイアウトファイル send_data(pdf) #ファイルのDL開始 詳しく PDFを出力してくれるgemであるwicked_pdfは大変便利だ。 他のPrawnのように独自DSLを使うことなくErbやHamlでPDFを生成出来て非常に効率がよい Railsのプロジェクトでwicked_pdfを使ってPDFを出力する場合は、普通にrenderしてしまうと 1. フォームボタン押下 2. PDFのページに遷移 3. PDFをブラウザ操作で「ファイル名前をつけて保存」などしてPCに保存 と言う流れになる、これはこれで中身

みなさんこんにちは。@ryuzeeです。 プロダクトバックログアイテムは、複数スプリントにまたがって1つのものに着手することはありません。 必ず、1スプリントで完成できる大きさになっている必要があります。 これは、複数にまたがってしまうと変化に柔軟に対応できなくなること、成果の量の把握が難しくなること、大きいものを扱うのはそもそも難しいことなどが理由です。 そのため、プロダクトバックログアイテムがプロダクトバックログのなかで上位になっていくにつれて、リファインメントなどを活用しながら、適切なサイズに分割していきます。 最初の段階から細かく分割してしまうと、変化に対応しにくくなったり、数が多くなりすぎて管理しきれなくなったりするので避け、着手が近づいてきたらジャスト・イン・タイムで分割していくのがポイントです。 こうすることで、チームの成長にあわせてプロダクトバックログアイテムのサイズを変え

Hi everyone 👋, Jordan here. I’m excited to feature , L6 Staff Engineer and Tech Lead at Google, and author of , a blog with recurring deep dives on technical topics. Micah attributes a large part of his growth to reading technical whitepapers. In today’s guest post, he will share the value he’s experienced and how you can see similar results. Hi everyone 👋, Micah here. As a tech lead at Google,

切り替える理由 自社の主力製品で利用している技術(WebRTC / WebTransport)がブラウザベースのため TypeScript を利用する Go を採用したのは sqlc が使いたかったという理由 sqlc-gen-typescript が出てきたのでもう Go を使う理由がなくなった 自社サービスチーム全員が Go にまったく興味が無い sqlc 自体は便利 そもそも自社に Go への興味がある人がいない 自社サービスの規模ではボトルネックになるのはデータベースであって言語ではない もしアプリでスケールが必要なときは Rust や Erlang/OTP に切り替えれば良い コネクションプールは PgBouncer を利用すればいい TypeScript からは 1 コネクション 1 接続で問題無い どうせフロントエンドでは TypeScript を書く 自社では React

たまたまお仕事の断り方という記事を読んだ。ひとり会社を経営してもうすぐ5年が経とうとしている。うちの会社では過去に1度、大きな失敗を経験してふりかえりを行った。その際に引き受けないお仕事の基準というものを社内で作成した。その失敗に至った原因の1つとして、本来引き受けるべきではないお仕事を受けてしまったと後になって反省した。 時代の流れや人手不足もあり、システム開発やプログラミングのお仕事はまだまだ好況にみえる。うちのような零細企業でも、実際に引き受けられるお仕事より依頼の方がずっと多い。そして残念ながらせっかくいただいた依頼をお断りすることもまた多い。 引き受けないお仕事の概要経理の本に書いてあったやるべきではない取引起業したばかりの頃に読んだ次の経理の本にも「やるべきではない取引」として次のリストを提案していた。 報酬が魅力的でも信用できない相手や嫌いな相手との取引 入金が遅い取引 自分

5Gインフラ支援事業 主要会社 主要サービス 5G生活様式支援事業 主要会社 主要サービス 企業・クリエイター5G DX支援事業 主要会社 主要サービス

神戸でWeb制作を行なっております、ちぃのポートフォリオサイトへようこそ。 お客様の思いに寄り添い、最高のサポートを全力でお届けします。お客様にとって最適な手段を考え、見やすく使いやすいユーザーファーストなページ作りにこだわります。

wp_mail() 関数のソースコードは wp-includes/pluggable.php にあります。ソースを読むと、メール送信部分は PHPMailer/PHPMailer を利用していることが分かります。PHPMailer の SMTP サーバを指定する方法を調べると、サンプルのコード の例のように SMTP の設定をすることができそうです。 つぎに WordPress に組み込まれている PHPMailer に SMTP サーバを設定する方法を調べます。再び wp_mail() 関数のドキュメント読み進めると、User Contributed Notes に SMTP サーバを設定する方法が載っていました。 add_action( 'phpmailer_init', 'mailer_config', 10, 1); function mailer_config(PHPMailer