SecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのか
安全なWebアプリケーションの作り方2018 - slideshare
SecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのか
Fastly + Rails + Herokuでページをキャッシュする方法 | Cat Knows
僕がつくったポートフォリオ作成サービスRESUMEでは、ページデータをFastlyにキャッシュさせています。CSSや画像などをキャッシュさせるのは簡単ですが、ページ自体をキャッシュしようとすると途端に難易度が上がります。 ページキャッシュに関してはインターネット上であまり知見が見つからなかったため、ここにまとめておこうと思います。 RESUMEの技術スタック 前提としてRESUMEでは主に以下の技術・サービスを使っています。 Ruby on rails Vue.js Heroku Fastly S3 CloudFront Fastlyにはページデータとサービスのアセット（CSSやサービス内で使われている画像など）をキャッシュさせ、S3/CloudFrontにはユーザーがアップロードした画像を保存しキャッシュしているという形です。 なぜFastlyを使ったか もともとはHerokuにデプロイ
Railsは2018年も現役か？: 前編（翻訳）｜TechRacho by BPS株式会社
次記事: Railsは2018年も現役か？: 中編（翻訳） 概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Is Rails still relevant in 2018 ? 原文公開日: 2018/08/16 著者: equivalent 記事は3分割しました。画像は元記事からの引用です。 Railsは2018年も現役か？（翻訳） Rubyから別の何かに乗り換えることを検討中のWeb開発者から、数日前にこんなメールを受け取りました。 まったく新規から始めるとしたら、バックエンドにRubyかElixirかJSのどれを選ぶ？ このメールで他に重要と思われる部分は、現在の彼はもっぱら自分のサイドプロジェクトに関心を寄せていることと、主な懸念点は開発速度と開発のしやすさであるということです。 メールに返信を書き始めたのですが随分と長くなってしまったので、この際記事にすることにしました
dev.toがなぜinsanely fastを実現出来ているか - Qiita
INSANELY FAST Qiitaを読んでる人なら https://dev.to をほとんどの人が見たはず。見てない人は見てきてください、速すぎて驚くはず。またmizchiさんがdev.toに書いた なぜ dev.to がこんなにも速く、こんなにも自分にとって感動的なのか - dev.to を見た人も多いと思う。個人的にHeroku, Railsを採用してここまで爆速なサイトを構築出来ていることは今までの常識を覆す衝撃な出来事だった。こんな新しい発見をもたらしてくれたdev.toには本当に感謝してる。自分もこんなサイト作ってみたいなと思ってdev.toのことを色々調べてて少し知見がたまったので共有してみます。 この記事はOkinawa.rb Advent Calendar 2017 7日目の記事です。 Twitterやってるのでよかったらフォローしてください🙋♀️ @saboyut
なぜいま Heroku なのか - Qiita
開発中のサービスに Heroku を採用した経緯を社内で周知するために書いた文章なんですが、ついでに Qiita にも貼っておきます（ちなみに Heroku の回し者ではないので悪しからず）。 従来、Heroku は日本で使うにはレイテンシの問題で本番環境での利用が避けられることが多かった これは Heroku の Common Runtime には Tokyo region がなく US 等のサーバーと通信するとレイテンシが大きいため1 実際、Wantedly 社なんかもレイテンシを理由に Heroku から AWS に移行している だが、Service Worker の先読みと Fastly（のような instant purge 可能な CDN）の登場により、このレイテンシの影響は極小化された のではないか 多くのリクエストは Fastly のエッジサーバー からレスポンスを返せるはず
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Ruby on Ruby on Rails
