「キャッシュは麻薬」という標語からの脱却 - id:onk のはてなブログ
これは はてなエンジニア Advent Calendar 2023 の 18 日目の記事です。昨日は id:gurrium による private-isuで70万点取るためにやったこと - ぜのぜ でした。私は 50 万点ぐらいで満足してしまっていたので、しっかり詰めていて凄いなと思う。 developer.hatenastaff.com Web アプリケーション開発において、「キャッシュは麻薬」という言葉がインターネット上をよく飛び交っています。YAPC::Kansai OSAKA 2017 の id:moznion のトークでよく知られるようになったワードじゃないかな。 初出はちゃんとは分からないんですが、少なくとも 2011 年には言われていますね。 「キャッシュは麻薬」とはよく言ったものだ。— TOYAMA Nao (@nanto_vi) November 5, 2011 キャッシ
なぜ Rails の前段に Nginx を置くのか - Qiita
追記（2023.09.13） X にて、この記事が引用されて多くの議論が投稿されました。 それらの多くは以下の通り「ALB等の利用できる環境の現代であればもうNginxコンテナは不要」という内容が多数です。 その上で、本文に入って頂ければと思います。一部「いいね」が多いポストを貼り付けさせていただきます。 本文にショートカットしたい場合は、ここをクリック ここから本文 以前、チームで以下のような会話が生まれました。 「コンテナに nginx 立てずに、直で rails Appサーバに ALB から流せばいいじゃん？」 みたいな話。その際に理由を即座にレスできなかったので、調査しました。 puma や Unicorn はあくまでAppサーバなのでユーザ直アクセス用途として設計されていない バッファリング処理が弱い バッファリング処理（処理速度や処理にかかる時間の違いを調整すること） ngin
GitHubは200万行規模のRailsアプリケーションであり、毎週RailsとRubyを最新版にアップデートし続けている
GitHubは200万行規模のRailsアプリケーションであり、毎週RailsとRubyを最新版にアップデートし続けている 4月10日でサービス開始からちょうど15周年を迎えたGitHubは、当初からRuby on Railsを用いたモノリシックなアプリケーションとして作られてきました。現在では200万行近い規模のコードになっているそうです。 今年1月にはGtHubを利用しているデベロッパーが1億人に到達したことも発表しました。GitHubはまさに世界最大級のRailsアプリケーションだと言っていいでしょう。 そのGitHubは5年前の2018年、Railsのバージョンを3.2から5.2に上げる作業に1年半を費やし。そして二度とこのようなことにならないよう、より頻繁にアップデートを行うべき、などの教訓を得たとしていました。 そして現在、GitHubは毎週月曜日にRailsのアップデート作業
株式会社アンドパッドに転職した, Kindle 本を初めて返品した - HsbtDiary(2022-11-04)
■ 株式会社アンドパッドに転職した 今日、情報が解禁されました: https://andpad.co.jp/news/1623/ 以前からヘッドハンティングやスカウトがあった時に、ペパボに在籍していた時もミドル以上のマネジメントの採用は続けていたので、とりあえず話を聞いて市場感を探るということをやっていた。出てくる話としてはどこもエンジニアのトップマネジメントだけではなく、テックリード、エンジニアリングマネージャも全然足りんので採用したいという状態で「まあペパボと同じだよね」という感想で終わることがほとんどだった。 ただ、自分の場合は話をした先が Ruby をメインに使っている会社なら「自分をフルタイムの Ruby コミッターとして雇えないか」というのをここ数年ぶつけていて、大体の会社は「エンジニアリングマネージャを採用したいのに、OSS開発者はいるか?と言われても...」という困惑した顔
16: Working on a service I love (with @kyanny) 作成者：Middle Aged Developers にゲスト出演した #madevs - @kyanny's blog
前回に引き続き。ライブドアとペパボ時代の話をした。 エピソードタイトルはホストのお二人の方で内容を端的に表すものをいい感じに考えてつけてくれている。今回のエピソードタイトルに関連する話は最後の数分間でしてる。 「自分が愛せるサービスに関わる」というのは必ずしも「ジャンルでナンバーワンのものに関わる」わけではない。livedoor Clip はナンバーツーだったけど、はてなダイアリーは livedoor Blog やアメブロなどと比べるとニッチな存在だったと思う。自分が身を置いていたコミュニティにおいての知名度は抜群に高かったけども。 その点、ペパボのサービスは総じて「ナンバーワンよりオンリーワン」なものが多かったと思う。ビジネスとしての成功よりも、中の人たちが作りたいものを素朴に作って世に出していた感じがする。それがちゃんと受け入れられる、ある意味優しい時代だった。
DNSリバインディング(DNS Rebinding)対策総まとめ
サマリ DNSリバインディングが最近注目されている。Google Chromeは最近になってローカルネットワークへのアクセス制限機能を追加しており、その目的の一つがDNSリバインディング対策になっている。Googleが提供するWiFiルータGoogle Nest WiFiはデフォルトでDNSリバインディング対策機能が有効になっている。 DNSリバインディング対策は、攻撃対象アプリケーションで行うべきものであるが、ブラウザ、PROXYサーバー、リゾルバ等でも保護機能が組み込まれている。本稿ではそれら対策機能の状況と対策の考え方について説明する。 DNSリバインディング（DNS Rebinding）とは DNSリバインディングはDNS問い合わせの時間差を利用した攻撃です。DNSのTTL（キャッシュ有効期間）を極めて短くした上で、1回目と2回目の問い合わせ結果を変えることにより、IPアドレスのチ
最初の一歩はドキュメントの英語化。Rubyが世界で使われるまでの「運と縁」をRubyのパパまつもとゆきひろ氏が振り返る - Findy Engineer Lab
グローバルで通用するプロダクトやソフトウェアを作りたい。一度は考えたことのあるエンジニアにとって「Ruby」の生みの親、まつもとゆきひろ氏は偉大かつ心強いパパです。 今回は、まつもと氏をお招きし、Rubyが世界に広がるまでのプロセスや日本から世界的なシステムやソフトウェアが生まれづらい理由、グローバルなOSS活動から得られる機会などを語っていただきました。聞き手はファインディの山田が務めます。 「自分の使うツールを良いものにしたい」が最大のモチベーション ——初めに、Rubyを開発するまでのキャリアを教えてください。 筑波大学でコンピュータサイエンスを学び、新卒で受託開発を行う独立系のソフトウェア企業に就職しました。 当時はバブル末期で、就職活動も売り手市場。プログラミング経験のある人のうち、わざわざ知名度の低いソフトウェア会社を選ぶ人は少なかったんです。2000名の社員に対し、新入社員は
DDD(ドメイン駆動設計)、理念に大賛成、実装に大反対。
※追記あり。最後の追記は 2021/04/25 21:40頃※ タイトルの通りのことを思っているけど、顕名のブログで書くと社内で干されるので、増田に書く。社内の心理的安全性がそんなに低い訳ではないけども、潮流が凄いので今は慎重に振る舞いたい。 この記事を見て「キミはDDDのことを誤解している」と思われた方はコメント等で優しく（易しく、ではない）ご指摘願いたい。 ※この記事では Web Application を前提とした話になっている。 DDDとは？https://ja.wikipedia.org/wiki/%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E9%A7%86%E5%8B%95%E8%A8%AD%E8%A8%88 DDD、ここがイケてる ソフトウェア開発者は開発対象のドメインのことをほとんど知らない、という問題意識およびその提起。 俗に言う「ビジネスサ
Ruby on RailsのGPL汚染まとめ（mimemagicの件） - 大根's ＩＴブログ
("汚染"という言葉をあまり良く思わない方もいると後から知りました。たしかにその通りだと思います。次から気を付けようと思いますが、とりあえず本記事ではそのまま"汚染"の表現を使います。ご了承ください。) 2021年の3月、突如としてRailsのGPL汚染の話題がネット上を駆け巡りました。 リチャードストールマンがFSFへの復帰を発表した途端にこんなことが起きるなんて…。 偶然にしてはすごいタイミングですね。 GitHub Enterpriseのコードが公開されるの？と盛り上がっておりますが、果たしてどうなりますでしょうか。 さて今回は本件についてまとめていきます。技術者だけでなく法務や知財の目線でも分かるように書いていこうかと思います。 ★私は法律の専門家ではありません。この記事に法的根拠はありませんので何かあっても責任は取れません。ご理解ください。 概要（経緯） 概要はこのissueのや
Railsアプリの開発環境向けDockerfile + docker-compose.yml - アジャイルSEの憂鬱
人に説明するときに記事あると便利なので、開発環境向けのDockerfileとdocker-compose.ymlを書いておく。 Dockerfile FROM ruby:3.0.0 WORKDIR /app # Using Node.js v14.x(LTS) RUN curl -fsSL https://deb.nodesource.com/setup_14.x | bash - # Add packages RUN apt-get update && apt-get install -y \ git \ nodejs \ vim # Add yarnpkg for assets:precompile RUN npm install -g yarn # Add Chrome RUN curl -sO https://dl.google.com/linux/direct/google-ch
Re: Rails を主戦場としている自分が今後学ぶべき技術について
この記事は、 Rails を主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ についてのアンサー記事です。 うなすけ君が Ruby on Rails で育ってきたように、僕も JavaScript とともに育ってきたという自覚があります。なので、これについて書くことは、ポジショントークは避けられない、という感覚があります。 冷静に比較しようとも思いましたが、やっぱり開き直って思いっきりポジショントークをすることにしました。そっちのほうが面白いと思うので。 自分の基本的な主張は、こちらの記事にあるとおりです。 Frontend Study #1: 基調講演 - Frontend 領域を再定義する 自分と Ruby on Rails 僕は、キャリアとしては Rails の会社で JavaScript を書いてきたことが多かったです。学生の頃は socket.io
Railsを主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ
Rails の問題は Rails のベストプラクティスがフロントエンドのベストプラクティスの邪魔になるどころか全く逆方向で相反してる点です。DHHの思想がフロントエンドと根本的に逆行してる。そういう人が作るフレームワークなのでwebpackerの抽象化を根本的に間違ったりする。 — prev.js (@mizchi) December 1, 2020 昨日もリプライで少し書いたけど、DHH自体が直近のHeyの開発でも明確にJavaScriptというものを触れないようにすることを是としているような主張をしているので、DHH wayが色濃く反映される以上この状態はもう避けられない気がしている — potato4d / Takuma HANATANI (@potato4d) December 1, 2020 Railsがフロントエンドの最先端をゆく人々1から良く思われないのは事実として。 Vie
プログラミング初心者のための JavaScript と Node.js の歴史、それを踏まえた勉強方法
プログラミング初心者のための JavaScript と Node.js の歴史、それを踏まえた勉強方法 2020年でJavaScript学ぶならきっとブラウザ向けJSガン無視していきなり初手node.js（ただし暫く何も足さない）がいいんじゃないかというメモ - min.t (ミント) Node.js を教えることについて、自分は賛成なんですが、その学習パスが整理されてないなと思っていたのと、学習パスがなぜ整理されていないかについて書きます。 はじめに 問題意識として、今のプログラミングスクールや独学勢が Ruby on Rails に偏っていて、 Node.js の人間としては、歯がゆく感じているんですが、実際 Node.js を教えるとしても問題も多いと認識しています。 歴史の話は、当時の実情や政治を省いて結果だけを書きます。具体的には第一次ブラウザ戦争、第二次ブラウザ戦争を言及しませ
著名なオープンソースRailsアプリのapp/以下を見る
Railsにおける app/ とは app/はRailsのアプリケーション用ディレクトリで、普通のRailsアプリケーションでは、この下にmodels,controllers,viewsを含めた様々なディレクトリが作られます。 基本的には新しいディレクトリを追加する必要はないのですが、アプリケーションが複雑になると、Railsを拡張するべくここにアプリケーション固有のディレクトリを作って、その下に関連するファイルを置くことがあります。 中には、servicesやserializersのように、多くのRailsアプリケーションで見られるものもあれば、完全にアプリケーション独自のものが作られることもあります。また、アプリケーションによっては独自のディレクトリは一切作らないものもあれば、大量に作るものもあります。それぞれアプリケーションの開発方針によるものです。 本記事では、比較的有名なOSSの
パーフェクトRails著者が解説するdeviseの現代的なユーザー認証のモデル構成について - joker1007’s diary
最近、パーフェクトRuby on Railsの増補改訂版をリリースさせていただいた身なので、久しぶりにRailsについて書いてみようと思う。 まあ、書籍の宣伝みたいなものです。 数日前に、noteというサービスでWebフロント側に投稿者のIPアドレスが露出するという漏洩事故が起きました。これがどれぐらい問題かは一旦置いておいて、何故こういうことになるのか、そしてRailsでよく使われるdeviseという認証機構作成ライブラリのより良い使い方について話をしていきます。 (noteがRailsを使っているか、ここで話をするdeviseを採用しているかは定かではないので、ここから先の話はその事故とは直接関係ありません。Railsだったとしても恐らく使ってないか変な使い方してると思うんですが、理由は後述) 何故こんなことが起きるのか そもそも、フロント側に何故IPアドレスを送ってんだ、という話です
認証自作、 Rails 、 Devise - Diary
認証自作、 Rails 、 Devise https://ockeghem.pageful.app/post/item/uQFX4oRNbnax82V これを読んで思ったことなんですけど、 Ruby On Rails 界隈では「認証は自作すべきではない、デファクトスタンダードの Devise を使うべき」という考え方が一般にあるように思います。 ではその Devise なんですけど、ドキュメントに以下のようにあります。 Starting with Rails? If you are building your first Rails application, we recommend you do not use Devise. Devise requires a good understanding of the Rails Framework. In such cases, we ad
RailsでTZ環境変数を設定するハックを不要にした話 - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)
TL;DR 『環境変数を設定するだけでRuby on Railsサーバが10%高速化する(かもしれない)話』 でRailsを高速化させる素晴らしいハックが紹介されましたが。いまや有効なハックではなくなりました。 TZハックさん、ながい間（2日間）おつかれさまでした。 はじめに アカツキさまで技術顧問をさせていただいている小崎です。 このエントリは『環境変数を設定するだけでRuby on Railsサーバが10%高速化する(かもしれない)話』をRubyコミッタが読んだらこうなったというアンサーソングになっています。合わせてお読みください TZ環境変数でTime.newが10倍近く速くなるのは素晴らしい発見ですが、コミッタとしてはTZなしでも速くなって欲しいなと思いました。だってめんどうだし。 現状分析 まず問題のテストプログラムを軽く分析してみましょう % strace -c ruby .
まつもとゆきひろの履歴書｜仕事中にこっそり作ったRubyが世界を驚かせるまで #ぼくらの履歴書 - ぼくらの履歴書｜トップランナーの履歴書から「仕事人生」を深掘り！
※この記事は2019年8月に取材・撮影した内容です 私たちが使う便利なアプリの数々は、“プログラミング言語”によって作られています。言語の種類は数え切れないほど存在していますが、「多くの人々に利用されているもの」となると、ごくわずか。優れたプログラミング言語を生み出せる人物は、世界的に見ても一握りなのです。 その数少ない人物のひとりが、日本にいます。プログラミング言語・Ruby（ルビー）の作者である、ソフトウェア技術者のまつもとゆきひろ（ @yukihiro_matz ）さんです。使い勝手の良さや生産性の高さから、まつもとさんの生み出したRubyは世界中で高い評価を受け、まつもとさん自身も世界中のコンピュータエンジニアから「Matz（マッツ）」の愛称で知られるようになりました。 では、まつもとさんは戦略的に、現在のキャリアを築き上げてきたのでしょうか。その答えは「NO」です。むしろ、「自分
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
N+1問題におけるORMの重たさについて - Atsuo Ishimoto's blog
blacklist/whitelist master/slave に関する情報集め
