PLAZMA TD Tech Talk 2018 at Shibuya
![How to Work with Legacy Ruby on Rails Applications in Treasure Data](https://cdn-ak-scissors.b.st-hatena.com/image/square/b0d36b0a24f74b45207916392de8906913c96602/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F8dcf5bb8fa73430392082e2e716d4a3d%2Fslide_0.jpg%3F10979415)
PLAZMA TD Tech Talk 2018 at Shibuya
module BillingErrorRescuer extend ActiveSupport::Concern included do rescue_from Billing::LimitExceeded, with: :rescue_billing_limits def rescue_billing_limits render status: 402, json: Billing::PlanPresenter.new(@account).to_json end end end require 'spec_helper' describe BillingErrorRescuer, type: :controller do controller do include BillingErrorRescuer def action @account = FactoryBot.create :a
2018.10.15 週刊Railsウォッチ(20181015)Rails初心者と一発でバレる書き方、次のVue.js構想、RubyのOpenStruct、Twilioほか こんにちは、hachi8833です。Pixel 3がちょい気になっています。 各記事冒頭には⚓でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ 「つっつきボイス」はRailsウォッチ公開前ドラフトを社内有志でつっついたときの会話です👄 つっつきボイス:「お、Pixel 3か、値段の割にストレージが少ないんですよね📱: 今の自分のiPhoneも、いつか見るつもりのNetFlix動画やら音楽やらであっというまにストレージ埋まっちゃうし」「私はWikipedia(日と英)がまるっと入ればいいかな...」「Pixelを見てると、ちゃんとしたスマホを作れば結局このぐらいの値段になるよなって思いますね
2018-04-25 MRI, the standard Ruby interpreter, has a serious problem with memory bloat in large Rails apps. It’s quite common for me to see Sidekiq processes which are 1-2GB in RSS or even larger! It turns out that a large part of this memory usage is due to memory fragmentation: MRI uses the OS’s memory allocator by default (on Linux, almost always GNU glibc), which seems to work poorly with Ruby
One of the earliest projects I was involved in at Valiant was investigating ways to optimise performance and memory consumption in our Rails web application. Although I had heard the age-old complaints about Rails applications being slow, bulky and prone to memory bloat, I had yet to come across any practical, easy-to-navigate solutions to these issues. Until we discovered jemalloc. In this blog p
tl;dr : We reduced the Docker image building time from 10 minutes to 5 minutes by re-using bundler cache and by precompiling assets. We deploy one of our Rails applications on a dedicated Kubernetes cluster. Kubernetes is a good fit for us since as per the load and resource consumption, Kubernetes horizontally scales the containerized application automatically. The prerequisite to deploy any kind
RailsアプリケーションをKubernetes(以後、k8s)で運用できるようにするための手順を書きます。 この記事はシリーズ連載記事の第二回です。 第一回 Docker編 第二回 Docker Compose/Dockerfile編 第三回 Kubernetes入門編 第四回 Kubernetes基礎編 第五回 Kubernetes応用編 第六回 Helm編 今回は下記について書きます。 最小限のDocker Compose入門 Docker Composeを使った各種ミドルウェアのインストールと管理 RailsアプリケーションのDockerイメージの作り方 Docker Composeによるローカルプレビュー環境の構築 サンプルアプリケーション簡単なRailsアプリを例に、Docker Composeの使い方やDockerfileの書き方を説明します。 このサンプルアプリrails-
以降の節で順にこれらのコマンドの使い方を説明します。見出しの括弧は旧コマンドです。 また、各節の終わりにリファレンスへのリンクを置いていますが、 少なくとも本稿の執筆時点においては旧コマンドの方が詳細に書かれているので、必要に応じてそちらも参照してください。 なお日本語版のドキュメントにはまだ新コマンド版のリファレンスはありません。 シェルの補完についてdockerのサブコマンドは、 861162a44 のようなハッシュ値や、 romantic_neumann のようにランダムな英単語の組み合わせで自動生成されたコンテナ名をパラメータとして受け取ります。 Docker for Macにはbashやzshでコマンドの補完を行うためのスクリプトが同梱されていますが、 ただインストールするだけでは有効になりません。 補完のための設定については別に記事を書いたのでこちらを参照してください。 bas
TL;DR 現プロジェクトと近似した構成で素振り出来るよう Rails + PostgreSQL による backend と React + TypeScript による frontend を docker-compose で立ち上げる boilerplate 作ったhttps://t.co/iCqMc2TWrD— 広島の粗大ゴミ (@ohbarye) 2018年7月7日 github.com Motivation 最近は "Backend developer" と名乗ろうが "Frontend developer" と名乗ろうが、web application を開発するエンジニアとして求められる知識は広範囲にわたることを、改めて実感しなおしている。 自分の経験でいえば、ここ数年は Rails エンジニアとしてやっているのだが、最近は React.js と TypeScript による
アプリケーションエンジニアの西辻です。 今回のブログでは、弊社のローカル開発環境を Docker 化した話をご紹介したいと思います。 このブログでは、なぜローカル開発環境を Docker 化する考えに至ったのかに始まり、 具体的にどのような方法で Docker 化を進めていったかを振り返りながら書いていきます。 また、Docker 化したことで受けた恩恵などを最後に書いて終わります。 Overview 大きく以下の項目について書いていこうと思います。 自分の仮想化環境への考え方について 今の現場に Docker 開発環境を導入する判断について 実運用している構成例を用いての説明 Docker for Mac のファイルI/Oのパフォーマンス改善方法 Tips: Docker コンテナに対して binding.pry を利用する ローカル開発環境を Docker 化した恩恵 自分の仮想化環境
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く