分かりやすいプログラムの構成はどうやったら設計できるのでしょうか? この本では、文脈と名前という二つの切り口でプログラムの構造とプログラマーの認識がどう結び付いてゆくのかを解き明かします。 本書は以下のような方々にお勧めです。 🤔大きくて複雑なプログラムを綺麗で分かりやすい設計にまとめることがうまくできなくて困っているプログラマー 😵他の人が書いたプログラムを読むときに、どこに何が書かれているのか手掛かりがつかめなくて迷ってしまう人 🧐DRY とか SOLID みたいなプログラム設計理論に関心があって、関連する事柄についての知識や考察を摂取したい設計オタク

2024年度リクルート エンジニアコース新人研修の講義資料です

2024年度リクルート エンジニアコース新人研修の講義資料です

2024年度リクルート エンジニアコース新人研修の講義資料です

https://forkwell.connpass.com/event/325649/ の登壇資料です。 書籍は https://amzn.to/3z8TLUM から

めまぐるしく変化するテックの世界。技術を身に着けるうえで学ぶべきポイントや学習環境なども年々変わっています。 そこで「もしもいまの環境で、テックのことをイチから学び直すことになったら、自分はどんな風に勉強したいか」というIFストーリーを通じて、技術との向き合い方を考え直してみる企画「テック転生」。 今回お話を伺ったのは、Ruby・Rails関連の技術書を数多く上梓し、学習環境の充実化やエンジニア育成に尽力されてきた五十嵐邦明さん（＠igaiga555）。“自分だったらこう進めたい、Ruby・Ruby on Railsの学習ロードマップ”を伺いました。 初心者に向けて執筆した『ゼロからわかる Ruby超入門』が最適 ――五十嵐さんがいま、イチからRuby・Railsを学び直すとしたら、何から始めますか？ もしも私がこれから学び直すとしたら、自分が執筆した『ゼロからわかる Ruby超入門』を使

サービスの開発をしていてPMから施策案が出てきた時、ソフトウェアエンジニアとして施策案が本当にユーザーのためになりサービスの成長につながるか納得できないことがある。 このような時にただ文句や愚痴を言っても何も始まらない。エンジニアからも何らかのアクションを起こし施策を前に進める必要がある。 そこでエンジニアができるアクションについて、自分が思っていることを書いてみる。 納得できないケースは大まかにどのようなものがあるか 納得できないケースでは大まかに2つのケースがあるのかなと思っている。 (1) 施策をしたい目的や仮説自体に納得できていない (2) 施策の目的や仮説は良いが、それを達成する手段に納得できていない 1つ目は、たとえば「ターゲットとしているようなユーザーって本当にいるか？」「ユーザーにこういう課題があると言っているが本当にそういう課題があるか？」「この指標に繋がると言っているが

読んで欲しいと思っている人 POやステークホルダーと品質について共通言語や目標が欲しい開発者 開発者と品質について共通言語や目標が欲しいPO スクラムで品質について困っている人 読むとわかること 完成の定義（Definition of Done）とはどんなものか スクラムと非機能的な品質の関係性 タイミーのWorkingRelationsSquadでどんな完成の定義を作り、活用していきたいと思っているか 完成の定義（Definition of Done）とは インクリメントが常に守るべき状態のことです。スクラムガイド1では以下のように説明されています。 完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を⽰した正式な記述である。 プロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕⽣する。 つまり完成の定義を満たしていない成果物は、いかに優れた機能であっ

Overview 背景 振り返り Good More 個人的な所感 コミュニケーションコストについて 最後に Overview 僕の担当してるプロジェクトの Slack チャンネルで1週間限定で スレッド利用原則非推奨 というルールを作って運用してみた振り返りです。 プロジェクトに関わるメンバーに協力してもらって以下のルールで1週間 Slack を利用してみました。 全ての投稿はチャンネルへの投稿する。ある依頼への返事やMTGに遅刻してる人を呼ぶDM的な使い方も含む。 Slack の流量が多くなることが想定されたので、気づいて欲しい時は臆せずメンションをつけること。 他部署や他プロジェクトの人に実験を強制するわけにはいかないので、その場合は例外的にスレッドの利用を許可しました。ただし、プロジェクトメンバーがスレッドで発言するときは also send to $Channel を必須にしても

スクラムフェス神奈川初陣 LT登壇

この記事は前作 開発生産性を標榜して効率に拘泥するチームはゆるやかに衰退する に続き、とはいえ効率を含む開発生産性的なものと向き合わねばならないチームや組織に向けた3作目です。そろそろ開発生産性がゲシュタルト崩壊してきた。 前提、わりと普通な話を述べているつもりだが、円滑になりきれないチームでは普通ないし妥当に至るハードルが思いのほか高いと感じる今日この頃。 人的効率主義に対するアンチテーゼの補足編 安直に (特に人間に起因する) 効率だけを求めて、効果や成果そのものから目を逸らすのはやめよう。 本来的な存在価値にそぐわない改善活動に腐心することは衰退の兆候である。 開発生産性を標榜して効率に拘泥するチームはゆるやかに衰退する 開発成果を念頭に起きつつも、どこかで一定の効率が必要なことを疑う余地はない。チームや組織の中長期を俯瞰すると正面から成果に向き合えるタイミングばかりではないので、そ

目次 目次 はじめに 送信者ガイドライン 送信ドメインの認証 迷惑メール率の監視 ワンクリックでの登録解除 設計について 対応方針 配信停止リクエストについて 案 1:自前実装 処理の流れ メリット デメリット 案 2:外部のメール配信システムの機能を利用 処理の流れ メリット デメリット 比較と結論 グルーピングによる一括配信停止 動作検証及びリリース 開発環境での検証 本番検証及びリリース さいごに はじめに こんにちは！ 食べログ開発本部ウェブ開発 1 部に所属している城戸です。 2021 年に新卒入社してから、現在はメディアマネジメントチームに所属しており、 食べログの一般ユーザー向けページの機能開発、他社との外部提携機能の開発、 制度改正に伴う改修、社内システムの改善など様々な開発に日々携わっています。 今回は食べログメールへのワンクリックでの登録解除導入についてご紹介します。

https://gitlab.com/gitlab-org/gitlab/-/tree/master/rubocop/cop https://postd.cc/how-dhh-organizes-his-rails-controllers

成果 最終的に、Cloud Run のコストが$6/day前後から$1/day前後に！ ちなみに、Cloud Tasks は1ヶ月あたり最初の100万回のオペレーションまで無料なので余裕で収まっています。 モチベーション 今回リプレイスを検討したシステムは軽量な非同期処理が大半で、もともと絶対に Sidekiq でないと困るということが少なかった Sidekiq は Redis をポーリングしてジョブを取得する方式なので、Cloud Run で実行するには min-instances を1以上にしなければいけない 何もジョブがない状態が続いてインスタンスが0になると起こしてくれる人がいないので... 絶対に Sidekiq でないと困らないなら Cloud Tasksにして、非同期処理がない時は寝ていても良いようにしたい => コストダウン！ Pub/Sub との比較検討もしましたが今回は

今回の記事は普段の GS2 のアップデート告知とは少し毛色が異なり、技術的なトピックを扱うエントリーです。 gs2.hatenablog.com こちらで告知した消費アクションの分岐処理を実装するにあたって、どのようなアプローチで課題に向き合ってきたのかを解説しようと思います。 非同期処理とリトライ まずは、非同期処理とリトライについて考えてみましょう。 非同期処理とは？ 「API を呼び出すと、処理の結果が返ってくる。処理の途中でエラーが発生したらエラーが返ってくる」というのが同期処理です。 この場合、エラーハンドリングは呼び出し元に委ねられますので、比較的シンプルに処理を行うことができます。 一方で、非同期処理とはどういうものか？というと 「API を呼び出すと、処理を動かし、処理IDを応答する」「処理IDを指定して完了を通知」「処理IDを指定して処理結果を取得」 というように呼び出し

こんにちは。 名刺アプリ「Eight」でエンジニアをしている鳥山（@pvcresin）です。 最近、ミスタードーナツのミニオンコラボの商品を食べたのですが、 どれも美味しくて見た目もかわいいので最高でした。 特にポン・デ・リングベースのものは、表面のキャンディが口の中でパチパチと弾けて楽しいのでオススメです。 さて今回は、RailsのViewで使う、HTML用ERBファイルのフォーマットを統一した話をします。 ERBとは ERB（eRuby、embedded Ruby）はテキストにRubyのコードを埋め込むための仕様です。 Railsでは特にViewの部分のHTML生成によく利用されます（拡張子は.erb）。 ERBでは、以下のような記法でRubyのコードを埋め込めます。 <ul> <% @features.each do |f| %> <li><%= f %></li> <% end %

「楽しく楽にcoolにsmartに」を理想とするprogrammer/philosopher/liberalist/realist。 好きな言語はClojure, Haskell, Python, English, français, русский。 読書、プログラミング、語学、法学、数学が大好き! イルカと海も大好き🐬

こんにちは、趣味でコーポレートエンジニアをやっていますyamashuです。 タイトルの通りかなり昔の話になるのですが、勤怠打刻の課題解決についてそういえば社外へ向かってアウトプットしていなかったなと思い、この度したためている次第です。 社外と接点が多い営業の社員が弊社での打刻の方法をたまたまお話したりして、その話を聞いた会社様から「話を聞かせてほしい」とヒアリングをいただくことも最近まで何度かありました。 そのため、もしかしたら同じ悩みに直面している方がいらっしゃるかもしれないので、1つの解決策としてやったことを書いておこうと思います。 課題 🤔 勤怠管理SaaS（弊社だとAKASHI）を使っているが、打刻（出勤、退勤）しても本人以外にはその結果が見えない、わからない。 そのため、コミュニケーションツールのSlackでも「出勤したよ〜」となにかしらの報告がチームメンバーに対して必要となる

もしそうしたクリニックが存在したとして、そのクリニックがあなたの家から1時間半かかるとしたら、そのクリニックをかかりつけにしますか？　しませんよね？　だから「自宅から近い」ことも自然と大事な条件になります。 さて、あなたの自宅の周囲にはどういうクリニックがあるのでしょうか？　すぐにいくつかのクリニックが思い浮かぶでしょう。でも本当にそれだけでしょうか。ほかにもあるかもしれません。 ネットの「病院ランキング」は信頼してはいけない そういうときは検索をします。え、当たり前？　ちょっと待ってください。私は千葉市に住んでいますが、小児科を探そうとして「千葉市」「小児科」などをワードにして検索をかけると、「医師探しのサイト」とか「病院・医院のランキング」とか信じていいかどうか分からないものが出てきます。これはよくありません。 最もいい検索の方法は、地元の医師会から検索することです。たとえばあなたが東