SREのすすめ：アプリケーションエンジニアとプロダクションエンジニアの架け橋になろう
前回の記事はこちら 上の記事で、ご指摘をいただきました。曰く、「問題意識は伝わったが、なぜSRE (Site Reliability Engineer）になったのかという繋がりが理解しにくかった」 読み返してみて、その通りだと思いました 🤦 なので、今日はちょっとそこを深堀りしてみたいと思います。 組織が成長するにつれて、「API設計者」と「API利用者」でデベロッパーのピラミッド構造ができるという話をしました。 つくる人と使う人 今日はもう少し視野を広げてみます。 今自分が見ている地形図 なぜ、直接コア要素の設計側に行けないのか がむしゃらに設計者にまわろうと思ってもパイは少ないです。現在勤めている会社にも Ruby/Railsのコミッターチームや、MySQLの独自実装を行うチームがあります。少数精鋭のチームで、それぞれ何かしら業績があった上で、チームに加わっているイメージです。 AP
Rails7がもつフロントエンドへの「答え」
Rails7のアルファ版がリリースされました。 最近、Railsニューリリースの記事をみてもテンションがあがらなかったのですが（個人開発ではもっぱらNext.jsとかFlutterのお世話になってました）、下記のDHHによるデモが久々に 「Railsっていいかも」 って思える内容だったので、背景も含めて解説します。 Railsの存在意義 みなさんは、どうやってRails使い始めましたか？ 自分はRails3.1あたりで独学でウェブアプリ開発をはじめました。そのときに「簡単に始められて」「ビジネスロジックが増えても生産性が落ちない」 というあたりで、他に浮気する理由がなかった、というのが私の理由です。 それから数年が経ちますが、最近のRailsのアップデートは Basecamp(Railsの基となった製品)が必要としている機能がポートされているだけ という印象でした。 アプリケーションの複雑
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
