論理学を基礎から〈テキストを読むこと〉だけで独習しようとするひと――こうしたひとにとって役立つかもしれない講義テキストを置いておく。これは某大学で私が担当している論理学の講義のテキストであり、その授業では安井邦夫『現代論理学』（世界思想社、1991年（新装版2021年））も教科書に指定されている。ただし、以下のテキストは、安井の教科書がなくても読むことができる（他方で、「論理学Ⅰ」のテキストを読み終えた後に、その続きとして安井本で述語論理などを学び進めることもできる）。 ちなみに、論理学をまなぼうとするひとの中には《ふつうの散文は却って読みにくく、とりあえず記号を並べてほしい（あとは自分で考えるから）》という方もいると思う。そうした方にとっては、残念ながら、私のテキストは却って読みづらいだろう。なぜなら私のテキストは――最近はこうした言葉づかいがあるらしいが――形式化の背景にある「お気持ち

Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp

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

こんにちは！ 2023年度エンジニア新卒の、吉田です。 株式会社リクルート 新卒エンジニアコースでは、部署への配属前に、BootCampと呼ばれる新人研修を行っています。 本日は2023年度の研修の内容を、実際に受講した新卒の立場から紹介させていただきます。 研修の内容については毎年反響をいただいていますが、今年度も一段と進化し、より充実した研修でした。 ページ下部に研修資料を公開していますので、ぜひ研修の雰囲気を感じ取っていただけると嬉しいです。 研修の概要 エンジニアコースの新人研修は、配属後にスピード感を持って成長できるようになることを見据え、 「さまざまな技術領域の講座を受け、興味関心を広げて、知らなかった好奇心に出会う」 「現場で求められる『仕事への取り組みスタンス』をつかむ」 「気軽に相談できる仲間（同期）をつくる」 の３点が目的とされています。 今年度は、入社前に行われたスキ

先達エンジニアに学ぶ 思考の現在地 Online Conference https://findy.connpass.com/event/313119/

こんにちは、一休.comスパ(以下、「スパ」)の開発を担当しているshibataiと申します🙏 今回はスパのデータベースの在庫の持ち方で試行錯誤した話をさせていただきます。 背景 2024-03-29追記: 一休.comスパにおける在庫の特徴について 一休.comスパが扱う「在庫」は、「ある日付の特定の時間に対する空き枠」です。以降の説明では、スパ施設ごと、日付ごと、また時間ごとに増えていく「在庫」をいかに効率よく扱うかについて説明しています。 詳細については次のスレッドも参照してください！ https://t.co/Y0SPmDE4yZ この記事のコメントみてると、少し我々のシステムの要件が伝わってないというかそこの説明が記事に不足しているように思った。ので以下その補足— naoya (@naoya_ito) March 29, 2024 現在の実装 スパは予約を受け付けるために在庫の

より価値を届けていくためにどのようにプロダクトマネジメントをすればよいのか？をまとめてみました。

コードレビューに限らず、いろいろなレビューがいろいろなプロセスに組み込まれている。 だが、レビューにおいて、たとえ内容に瑕疵があっても承認されるなら、そのレビューは単なる形式・儀式に過ぎない。 "何かを保障するためのプロセス"としてのレビューを機能させることを目的とするなら、そこには却下の可能性があることが必要条件だ。 保障: ある状態がそこなわれることのないように、保護し守ること。(https://kotobank.jp/word/%E4%BF%9D%E9%9A%9C-630029) 却下と批判的立場 そのようなレビューにおいて、レビュアーは「これは承認しても大丈夫か」と思考する。 「承認しても大丈夫だ」という確信を得るということは、裏返せば「却下すべき理由がない」という確信を得ることである。 その確信が得られるのは「却下すべき理由を探したが見つからなかった」ときである。 つまりレビュア

本記事は日頃筆者がパッケージアップデートという活動に関して思っていることを書き出した記事です。ちなみに筆者はこういうものです (Wantedly, Inc. 所属) はじめに 筆者の所属する会社でも「なぜ我々はパッケージアップデートを行うのか」「どういう戦略でパッケージアップデートを行うのか」についてたびたび議論されています。これはなかなか難しいトピックで完全に全員の意見が一致したり、深く整理しきれないまま先に進むことも多いです。 さて、筆者もそんな状況にのまれてしまっていた一人ではありましたが先日公開された@autotaker1984 さんの ソフトウェアはなぜバージョンアップしなければならないのかという素晴らしい記事を読んで心にくるものがありました。見事に触発されてしまったので筆者も一度自身がパッケージ (ソフトウェア) アップデートに対して思っていることを書き出してみようと思います。

YAP::Hiroshima 2024にて登壇 #yapcjapan

git-schemlexとddl-makerを使ったDB migrationの紹介 / git-schemalex and ddl-maker migration #golangtokyo

リモートワークで仕事をしていると、Slack や Teams といった何かしらのチャットツールでコミュニケーションを取ることが多い。そうやって仕事を続けていく中で「こう伝えたらよりスムーズに話が進んだかな...」という後悔は多々あり、日々試行錯誤を続けている。 そうやって試行錯誤を続けていく中である程度テキストコミュニケーションを取る上でのフォーマットが定まってきた気がするので、箇条書きでまとめてみようと思う。（随時更新予定） prefix （接頭辞）をつける文章の先頭にその文章の目的がわかるような prefix をつけて、何のためにポストしたかを一目で分かりやすくする。例えば以下のような prefix をつけることがある。 【質問】→ 相手の返信が欲しい時 【共有】→ 返信は不要だが、内容は把握しておいてほしい時 【メモ】→ 返信不要で、後から検索できるよう残しておきたい時 箇条書きする

プロトタイピングとユーザビリティテストで「UXデザイン」を練りあげよう！ | UXデザイン基礎セミナー 第4回

リリースするたびに「影響範囲の考慮漏れ」によるトラブルを起こす。こういう症状は、既存のソフトウェアシステムに追加開発を繰り返す組織によく見られるのではないかと感じます。コードやシステムの変更が影響を及ぼす箇所を見逃してしまい、未修正な箇所が残されたまま本番リリースされたために発生するトラブルです。 このようなトラブルが頻発すれば、関係者らは不満を感じます。エンジニアたちの能力に不信感を抱くかもしれません。 しかし、不満の矛先をエンジニアに向けたところで問題が解決することはありません。そもそも原因を見誤っているからです。根本的な原因は、もっと奥深くにあります。 影響範囲の考慮漏れの多発は、ソフトウェアシステムが大きな問題を抱えていることを知らせるサインです。このサインを見逃して表面的な対策ばかりを続けていると、症状が良くなるどころか、かえって悪化し続けることになるでしょう。 問題/原因の3層

2023年10月にGoogleとYahoo!がメール送信者向けのガイドラインを更新してから早3か月。いよいよ適用開始の2024年2月が近づいてきました（ドキドキ）。 私は昨年から本件の対応を進めていて、地味に大変だな、と感じています。多くの企業では自社ドメインから様々なメールを送信していると思います。利用しているツール・サービスも様々で、たとえば、Sendmail/Postfix/Eximのサーバを立てている、Google WorkspaceやMicrosoft 365を使っている、といった他に、CRMであるSalesforce、マーケティングツールのHubspotやAccount Engagement(旧Pardot)、メール送信用のAmazon SESやSendGridを使っているなど、多くのツール・サービスを併用している企業が多いのではないでしょうか。 そういった状況では自社のどこか

こんにちは、デジスマチームでエンジニアをやっている堀田です。 これまで、TypeScriptの型で色々試したことがあります。 2年前: TSの型で麻雀の点数計算 最近: 型で足し算 遊ぶことの方が多かったですが、先日M3 TechTalkで実用的かも？と思える話をしました。 そこでは、3つの場面を想定して、それぞれの場面でより安全なコードを書くための型定義を提案しました。 この記事では、その時の話をまとめて紹介します。 1. key? 2. ログ送信 Rest parameters with tuple types Function Overloadsでも実現可能 3. 画面遷移パス生成 まとめ We are hiring!! 1. key? 早速、1つ目の場面です。 ここでは、「パラメータを受け取って、その値によって生成か更新か挙動が変わる」以下のような関数を扱うことを考えます。 fun

PHPカンファレンス北海道2024 https://fortee.jp/phpcon-hokkaido-2024/proposal/7d223fcd-ecc8-4cfb-92b2-4987749463d8 Lについての補足記事 https://asumikam.com/entry/2024/01/12/144338 Sについての補足記事 https://asumikam.com/entry/2024/01/13/152513

はじめに 皆さんこんにちは、株式会社エムアイ・ラボのエンジニアです！ 今回はソフトウェア設計のSOLID原則について学習したので、弊社のメインの開発言語であるTypeScriptのサンプルコードを使って共有できればと思います。 SOLID原則は、オブジェクト思考プログラミングにおいて、ソフトウェアがメンテナンスしやすく、拡張や変更に強いソフトウェア設計を行うための原則です。 SOLID原則にはSOLIDの頭文字をそれぞれとった、５つの原則があります。 単一責任の原則（Single Responsibility Principle） 単一責任の原則とは、クラスが一つの機能や責任を持つべきで、クラスが変更される理由は一つであるべきというです。 クラスが一つの機能や責任のみを持つようにすることにより、コードは再利用可能でテストが容易になります。 単一責任の原則を遵守している例 以下のBirdクラ

新規事業立ち上げのアンチパターンについて考えてみる。 このアンチパターンは、完全な飛地の新規事業だけではなく、複数プロダクトを経営する中での隣接領域の新規プロダクトの立ち上げのときや、あるセグメントにPMFした状態から次のPMFを探すときも同様のアンチパターンが適用されうる。 ここでのアンチパターンは、1つ目の事業立ち上げ・プロダクト立ち上げで起こることはない。2つ目の事業や2つ目のプロダクトを立ち上げる際に留意する点であり、コンパウンドスタートアップを正しく経営するには必ず頭に入れておきたい内容である。 規模からの逆算と顧客インサイトの軽視新規事業における市場選択のアンチパターンである。 例えば、売上の30%成長を続けるための、計画と現実のギャップを埋めるために新規事業を規模から探してしまうみたいなケースで見られる。 大前提として、市場規模の推定は重要である。実際に事業をやっていると、い