Rails 7でのlink_to削除時にturbo_confirmで確認ダイアログを表示する方法

開発中に遭遇した不具合の解消方法を調査したので、備忘録も兼ねて投稿します。

環境

ruby: 3.2.2 rails: 7.0.6

Rails 7での削除リンクの振る舞いの変更

link_toを使用して、掲示板の各項目を削除するリンクを作成する場合、turbo_method: :deleteを使用しないと、期待通りの動作をしません。

- <%= link_to '削除', board, method: :delete %>
+ <%= link_to '削除', comment, data: { turbo_method: :delete  } %>

詳細は以下のブログをご参照ください。

tatsuki-ju.hatenablog.com

これに併せて、data: { confirm: 'Message' }のような確認ダイアログも動作がしないようで、書き方を変える必要があるようです。

確認ダイアログの表示方法

前述の通り、従来のdata: { confirm: 'Message' }のようなJavaScriptの確認ダイアログが動作しない場合、turbo_confirmを使用して確認ダイアログを表示することができるようです。

turbo_confirmの基本的な使用方法は以下のようになります：

<%= link_to '削除', board, data: { turbo_method: :delete, turbo_confirm: '削除してもよろしいですか？' } %>

このdata: { turbo_confirm: 'Message' }を追加するだけで、リンクをクリックした際に確認ダイアログが表示されました。

Rails7でlink_toを使ったmethod: :deleteのエラーと対処法

開発中に遭遇したエラー（というか不具合）の解消方法を調査したので、備忘録も兼ねて投稿します。

環境

• ruby: 3.2.2
• rails: 7.0.6

問題の状況

以下のようなコードで、link_toを使用して掲示板の一覧ページから各項目を削除するリンクを作成しました。

<%= link_to '削除', board, method: :delete %>

しかし、このリンクをクリックすると、なぜか掲示板の詳細ページに遷移してしまいました。

ブラウザで確認しても疑似メソッドとして「delete」が認識されていますし、ルーティング・コントローラーの設定も間違っていません。

# routes.rb
resources :boards

# boards_controller.rb
def destroy
    board = Board.find(params[:id])
    board.delete

    redirect_to boards_path
end

問題の原因

Rails 7では、JavaScriptのハンドリングが大きく変わり、rails-ujsが廃止され、新しくhotwired/turbo-railsが導入されました。

この変更により、疑似メソッド（:delete, :patch など）のハンドリングが以前とは異なる動作となったことが原因のようです。

解決方法

1. importmap-railsのインストール: Rails 7でJavaScriptを扱う新しい方法として、importmap-railsを導入します。

     docker-compose run web bundle add importmap-rails
     docker-compose run web rails importmap:install
   

   Dockerを使用している場合ですが、もしこの段階でimportmapをインストールしていなかった場合は、上記コマンドを実行し、再ビルドを行います。

2. link_toの記述方法の変更: link_toでのmethod: :deleteの部分をdata: { turbo_method: :delete }に変更します。

     <%= link_to '削除', board, data: { turbo_method: :delete } %>
   

3. 必要なJavaScriptライブラリのインストール: Rails 7で新たに必要となるJavaScriptライブラリを手動でインストールします。

     docker-compose run web rails turbo:install stimulus:install
   

これらのステップを踏むことで、無事に削除機能を実施することができました。

Rails link_toメソッドの引数にモデルのインスタンスを直接渡したら、showに遷移できる

開発中にわからなかったことについて調べたので、備忘録も兼ねて投稿します。

環境

• ruby: 3.2.2
• rails: 7.0.6

概要

link_toメソッドの引数には以下の2つをとります。

1. リンクのテキスト
2. パスやURL

以下は、ボードの一覧ページから詳細ページに遷移するリンクを表示する例です。

<% @boards.each do |board| %>
    ...
    <%= link_to '詳細', "/boards/#{board.id}" %>
<% end %>

第2引数にURLを直接指定しています。

Railsの学習を始めたばかりで、link_toでリンク先を指定して遷移させられるのね、と腹落ちしていたところ、以下のように第2引数にパスでもURLでもないものが使われているのを見ました👀！

<% @boards.each do |board| %>
    ...
    <%= link_to '詳細', board %>
<% end %>

なぜか問題なく詳細ページに遷移できていたので、どういうことなのか調べました。

結論

Railsのlink_toメソッドは、非常にスマートなようで。

第2引数としてモデルのインスタンスを直接渡すことで、そのインスタンスのshowアクションへのパスを自動的に生成できるようです！

モデルのインスタンスを直接指定して、showアクションのURLに遷移する方法

どうやってそれが可能なのか？

リソースベースのルーティングを使用する必要があります。

resourcesメソッドを使ってルーティングを定義すると、Railsは一連の標準的なルート（URLパターン）を自動的に生成します。そして、それぞれのルートには特定の命名規則があります。

例：

resources :boards

上記のようにルーティングを定義すると、以下のようなURLパターンが自動的に生成されます：

• /boards: 全てのボードのリスト（indexアクション）
• /boards/:id: 特定のボードの詳細（showアクション）

ここで、:idはボードのID（モデルのインスタンスのID）を示します。

実際の使い方：

今回はBoardsControllerの中で、ボードの一覧を取得して表示するためのindexアクションと、特定のボードの詳細を表示するためのshowアクションを定義します。

class BoardsController < ApplicationController
    def index
    @boards = Board.all
  end
  
  def show
    @board = Board.find(params[:id])
  end
end

ボードの一覧ページに各ボードの詳細ページへのリンクを作成したい場合、/boards/index.html.erbで以下のように書くことができます：

<% @boards.each do |board| %>
  <%= link_to '詳細', board %>
<% end %>

上記のlink_toメソッドでは、第2引数にboard（ボードのインスタンス）を直接指定しています。

これにより、Railsは自動的に/boards/:idの形式のURLを生成します。

そして、:idの部分には、boardインスタンスのIDが埋め込まれます。

まとめ

Railsのlink_toメソッドについて以下のことがわかりました。

• モデルのインスタンスを直接渡すだけで
• 詳細ページへ遷移するリンクを作ることができる

そのためには、

• リソースベースのルーティングと組み合わせる必要がある

参考

link_toメソッドを使ったリンクの作成

Rails カスタムフォーマットの利用時に「.to_s」メソッドで引数を渡すと発生するエラーの解消方法

開発中に遭遇したエラーの解消方法を調査したので、備忘録も兼ねて投稿します。

環境

• ruby: 3.2.2
• rails: 7.0.6

概要

以下のコード例のように、config/initializers/配下に定義したカスタムフォーマットをviewファイルで利用する際に、.to_sメソッドで引数を渡すとエラーになりました。

#config/initializers/time_formats.rb
Time::DATE_FORMATS[:datetime_jp] = '%Y年 %m月 %d日 %H時 %M分'

#app/views/~~index.html.erb
--
<th><%= board.updated_at.to_s(:datetime_jp) %></th>

エラーメッセージ：

ArgumentError in ~~#index
wrong number of arguments (given 1, expected 0)

引数の数が間違っている（1が指定され、0が予想される）ことによりエラーが発生しました。

原因

以下の内容が原因だったと思われます。

「to_s(format)を非推奨とし、to_formatted_s(format)を優先」

• Ruby 3.1でいくつかのタイプのオブジェクトの補間を高速化する最適化が導入される
• しかし、この最適化はto_sにカスタムの実装が存在する場合には効果がなくなる
• Railsが多くのコアクラスでto_sをオーバーライドしていることから、この最適化はRailsアプリケーションで無効になる可能性がある
• そのためRailsでは、to_sのオーバーライドを非推奨とする

解決策

非推奨となったto_sの代わりにto_formatted_s（またはto_fs）を使用することでエラーを回避できました。

<th><%= board.created_at.to_formatted_s(:datetime_jp) %></th>
<th><%= board.updated_at.to_fs(:datetime_jp) %></th>

（まとめ）REST APIの基礎

REST APIの基礎的な内容についてまとめてみました！

1. RESTについて

1.1 まずWeb APIとは

Web API（Web Application Programming Interface）とは、HTTPなどのWeb技術を応用して、異なるソフトウェアやアプリケーション間で情報をやり取りできるようにする仕組みのことを言います。

具体的には、一つのアプリケーションが他のアプリケーションの機能やデータにアクセスするための手段や方法を提供しています。

Web APIの代表例には、「Google Map API」や「Twitter API」などがあります。

1.2 RESTの意味と概念

REST（Representational State Transfer）は、Web上でデータや機能を提供・利用するための設計スタイルの一つで、Web APIの設計手法として定番です。

RESTの考え方の中心は、ROA（リソース指向アーキテクチャ）と呼ばれるもので、「リソース」を中心に設計する方法を取ります。

1.3 ROA（リソース指向アーキテクチャ）

ROA（リソース指向アーキテクチャ）は「リソース」を中心に設計する方法です。

「リソース」とは、具体的な「データ」や「動作」「概念」など、サービスが提供する「もの」全てを指します。（例：APIで提供したい「ユーザー」や「商品」など）

ROAの主な特性として以下の4つが挙げられます。

1. アドレス可能性（Addressability）: それぞれのリソースが一意のURIで表されること。
2. ステートレス性（Statelessness）: 一つひとつのリクエストが独立して処理されること。
3. 統一インターフェース（Uniformed Interface）: すべてのサービスが同じHTTPメソッドを使って操作されること。（例：データ取得であれば「GET」を使う）
4. 接続性（Connectedness）: 関連するリソース同士がお互いのURIを参照し合うこと。

リソース中心の設計方法をとることで、直観的で統一感のあるAPIを設計することが可能になります。（一意で明確なURIを持ち、統一されたHTTPメソッドを使用するなどの特性によって）

そしてREST自体もこのROAの思想を取り入れているため、RESTfulなAPIは「直観的で統一感のあるAPI」であると言えます。

2. REST原則

ROAと同様、「リソース」を中心とするRESTにはROAと類似するものを含めたいくつかの原則が存在します。

そしてこれらの原則を全て（あるいは部分的に）満たしたAPIのことをRESTful API（REST API）と呼びます。（※実際の定義は柔軟。最も重要なのは、APIの使用者にとってわかりやすく、効率的なAPIであること）

2.1 クライアント/サーバー構造

特徴:

• クライアントとサーバーは別々の役割を持ち、独立して動作します。
• クライアントとサーバーの間の通信は、定義されたインターフェースを通じて行われるため、一貫性が保たれます。

メリット:

• 拡張性: クライアントやサーバーのどちらかを独立してアップグレードまたは変更することが容易になります。
• メンテナンスの容易性: 特定の部分（クライアントまたはサーバー）のみを修正することができるため、全体のダウンタイムを最小限に抑えることができます。
• 専門化: クライアントはユーザー体験の最適化に焦点を当て、サーバーはデータの処理やビジネスロジックに特化することができます。

デメリット:

• 通信オーバーヘッド: クライアントとサーバー間の通信が必要になるため、ネットワークの遅延やオーバーヘッドが生じる可能性があります。
• 複雑性の増加: クライアントとサーバーが独立して動作するため、通信やデータの同期に関する複雑性が増加する場合があります。
• セキュリティ懸念: クライアントとサーバー間の通信はセキュリティの脅威となる可能性があり、適切な暗号化や認証が必要です。

2.2 ステートレス性

• ステートレス (Stateless):

  特徴：

  • サーバーはクライアントの以前の活動や履歴を覚えていません。
  • クライアントが何かを要求するたびに、全ての必要な情報を毎回提供する必要があります。

  メリット:

  • 拡張性: クライアントの状態を保存しないため、サーバーが要求に応じて迅速に拡張できます。
  • 単純性: セッション情報を管理する必要がないため、設計と実装がシンプルになります。
  • 予測可能性: 同じリクエストは常に同じレスポンスをもたらすため、動作が予測可能です。

  デメリット:

  • 冗長性: クライアントが毎回全ての情報を提供する必要があるため、通信が冗長になることがあります。
  • パーソナライズが困難: クライアントの前回の状態や選択を知らないため、パーソナライズされた体験が難しくなることがあります。

• ステートフル (Stateful):

  特徴：

  • サーバーはクライアントの以前の活動や履歴を覚えています。

  メリット:

  • 効率性: サーバーがクライアントの状態を覚えているため、クライアントが毎回同じ情報を提供する手間が省かれます。
  • パーソナライズ: クライアントの過去の選択や嗜好を基に、カスタマイズされたサービスや体験を提供することができます。

  デメリット:

  • 拡張性の問題: セッション情報やクライアントの状態を維持する必要があるため、システムのスケーラビリティに制約が生じることがあります。
  • 複雑性: クライアントの状態を管理するための追加のロジックやストレージが必要となり、システムが複雑になることがあります。

2.3 キャッシュ可能性

特徴:

• クライアントはレスポンスデータをキャッシュして再利用することができます。
• これにより、同じデータの再度のリクエストを減少させることができます。

メリット:

• 効率性: サーバーへの再リクエストを避けることで、効率が上がります。
• 高速な応答: キャッシュされたデータを使用することで、より迅速なレスポンスを提供することができます。

デメリット:

• 古いデータ: キャッシュのデータが古くなると、ユーザーが最新の情報を取得できなくなる可能性があります。
• 管理の複雑性: キャッシュの有効期限や更新に関する管理が必要になります。

2.4 階層システム

特徴:

• システムは複数の層（レイヤー）で構成されます。
• クライアントは直接最終的なサーバーにアクセスするのではなく、中間のレイヤーを通じてアクセスする場合があります。

メリット:

• 拡張性: 新しい層の追加や既存の層の変更が容易になります。
• 再利用性: 各レイヤーが独立して動作するため、一部のレイヤーを他のプロジェクトやシステムで再利用することができます。
• セキュリティ: 特定のレイヤーでセキュリティポリシーや認証を施行することができます。

デメリット:

• パフォーマンスの問題: クライアントとサーバー間の複数のレイヤーを通過することで、一定の遅延が発生する可能性があります。
• 複雑性: システムが複数のレイヤーで構成されるため、設計やデバッグが複雑になることがあります。

2.5 統一インターフェース

特徴:

• URIで示したリソースに対する操作を、統一したインターフェースで行います。

メリット:

• シンプルさ: 一貫したインターフェースを使用することで、学習のカーブを緩和し、実装のシンプルさを保つことができます。
• 階層化のしやすさ: システム全体を階層化しやすくなります。

デメリット:

• 柔軟性の欠如: すべてが同じインターフェースを使用する必要があるため、特定の要件に特化したインターフェースの導入が難しくなる可能性があります。

2.6 コード・オン・デマンド (オプション)

特徴:

• サーバーからクライアントに実行可能なコードを送信し、クライアント側でそのコードを実行する能力を持ちます。
• この原則はオプションであり、必須ではありません

メリット:

• 柔軟性: 必要に応じてクライアントの機能を動的に拡張または変更することができます。
• 帯域の節約: コードは必要に応じてのみダウンロードされるため、常に全てのコードをクライアントにロードする必要がありません。
• 最新の機能: サーバー側で更新されたコードをクライアントに提供することで、ユーザーは常に最新の機能や修正を利用できます。

デメリット:

• セキュリティの懸念: クライアントでのコード実行はセキュリティリスクをもたらす可能性があります。ダウンロードしたコードの信頼性や安全性を確保する必要があります。
• 互換性: 異なるクライアント環境でのコードの動作を確保するためのテストや検証が必要になる場合があります。
• パフォーマンス: クライアントで実行するコードのダウンロードや実行に伴う遅延が生じる可能性があります。

3. REST APIとは

REST APIは、ここまで解説した「RESTの原則」に基づいて設計されたWeb APIのことを指します。

REST APIの主な目的は、異なるシステムやアプリケーション間で情報のやり取りを容易にすることにあります。

REST APIは、一般的にHTTPを通信プロトコルとして使用し、リソースを操作するための標準的なHTTPメソッド（GET、POST、PUT、DELETEなど）をサポートしています。

3.1 REST APIの設計レベル

REST APIの設計レベルとは、一般的にLeonard Richardsonが提唱した「Richardsonの成熟度モデル」として知られています。

このモデルは、RESTful APIの「成熟度」や「RESTらしさ」を0から3の4つのレベルで示しています。

レベル 0: シングルURI, シングルHTTPメソッド

• このレベルのAPIは、ほとんどの操作が単一のURIとHTTPメソッド（たいていはPOST）を使用して実行されるものです。
• 具体例：古いタイプのSOAPサービスなど。
• このレベルのAPIはRESTとは言えません。

レベル 1: 複数のURI

• このレベルでは、異なるリソースに異なるURIが割り当てられます。
• しかし、まだ全ての操作が同じHTTPメソッド（例えばPOST）を使用しています。
• 具体例：/usersと/ordersという2つの異なるURIが存在するが、データの取得や変更のために常にPOSTを使用するサービス。

レベル 2: HTTPメソッドの活用

• このレベルでは、HTTPメソッド（GET, POST, PUT, DELETEなど）を活用してリソースに対する操作を表現します。
• これにより、APIの意図がURLだけでなくHTTPメソッドによっても明確にされるようになります。
• 具体例：ユーザー情報を取得する場合はGET /users/{id}、新しいユーザーを作成する場合はPOST /users、ユーザー情報を更新する場合はPUT /users/{id}など。

レベル 3: HATEOAS (Hypermedia as the Engine of Application State)

• 最も成熟したレベルです。レスポンスには、リソースの現在の状態だけでなく、次にどのような操作が可能かを示すハイパーメディア（リンクやアクションなど）も含まれます。
• これにより、クライアントはAPIのドキュメントを頻繁に参照することなく、動的にアクションを決定・実行することができます。
• 具体例：ユーザー情報の取得レスポンスに、そのユーザーを削除するためのリンクや、関連する注文情報にアクセスするためのリンクが含まれるなど。

このモデルは、APIがどれだけRESTの原則に従っているかを評価するためのガイドラインとして提供されています。

ただし、すべてのAPIがレベル3に到達する必要はありません。使用する状況や要件に応じて、適切なレベルでの設計を選択することが重要です。

4. HTTPメソッドとRESTfulな操作

REST APIの設計では、HTTPメソッドを使用してリソースに対する具体的な操作を指定します。

これにより、APIのエンドポイントが行う動作が明確になります。

4.1 各HTTPメソッドの役割

HTTPメソッド	概要	例示
GET	リソースを取得します。	商品一覧を取得: GET /products
POST	新しいリソースを作成します。	新しいユーザー作成: POST /users
PUT	既存のリソースを完全に更新または置き換えます。	ユーザー情報更新: PUT /users/123
DELETE	リソースを削除します。	ユーザー削除: DELETE /users/123
HEAD	リソースのメタデータのみを取得します。ボディは含まれません。	ヘッダー情報取得: HEAD /products
OPTIONS	対象のリソースでサポートされているHTTPメソッドを知るためのリクエスト。	サポートメソッド確認: OPTIONS /users
PATCH	リソースの一部を更新します。	部分的更新: PATCH /users/123

4.2 冪等性と副作用

REST APIの操作の際に、二つの重要な概念として「冪等性」と「副作用」があります。

• 冪等性 (Idempotency): 同じ操作を何度実行しても、結果が常に同じである性質を指します。例えば、GETやPUT、DELETEは冪等性を持つ操作です。 何度同じリソースに対してこれらのメソッドを実行しても、結果は同じです。 一方、POSTは冪等ではありません。同じデータをPOSTする度に、新しいリソースが作成される可能性があります。
• 副作用 (Side Effects): 操作がシステムの状態やデータに変更を引き起こす性質を指します。GETは副作用がないとされるのが理想的であり、データやシステムの状態に変更を加えずにデータを取得することが期待されます。 一方、POST, PUT, PATCH, DELETEは明確な副作用を持つ操作です。

5. REST API のリクエスト

REST APIのリクエストとは、クライアント（例: ウェブブラウザ、モバイルアプリ、他のサーバーなど）がサーバー上のリソースやデータにアクセス、操作を行うために送信するメッセージのことを指します。

REST APIリクエストは、HTTPプロトコルを基にしており、特定の方法や構造に従ってデータを送信することで、サーバーとのやり取りを実現します。

REST APIのリクエストには以下の要素があります。

1. HTTPメソッド

• リクエストの種類や目的を示します。
  • 主に使用されるメソッドは
    • GET（データの取得）
    • POST（データの作成）
    • PUT（データの更新）
    • DELETE（データの削除）など。

2. エンドポイントURL

• アクセスしたいリソースを特定します。例: /users や /products/123 など。

3. クエリパラメータ

• エンドポイントURLに追加することで、特定の情報の絞り込みやページネーションなどの操作を指定します。例: /users?age=25 など

4. ヘッダー情報

• リクエストに関連するメタ情報や設定を提供します。

5. リクエストボディ

• POSTやPUTなどのメソッドでデータを送信する際に使用される部分で、実際に送信するデータを含みます。
• 通常、JSONやXMLの形式で送信します。

6. 認証情報

• APIへのアクセスを保護するため、リクエストにはAPIキー、トークン、ユーザー名/パスワードなどの認証情報を含むことが多いです。

6. REST APIのレスポンスとHTTPステータスコード

REST APIのレスポンスとは、クライアントからREST APIへのリクエストを受けた後、サーバーからクライアントに返されるデータや情報のことを指します。

REST APIのレスポンスは、通常、HTTPプロトコルを使用して送信されます。

REST APIのレスポンスには以下の要素があります。

1. ステータスコード

• リクエストの結果を示す3桁の数字です。

2. ヘッダー情報

• レスポンスに関するメタ情報を提供します。

3. レスポンスボディ

• 実際のデータが含まれています。JSON、XMLなどが使われます。

4. エラーメッセージ

• リクエストが失敗した場合や、何らかの問題が発生した場合、エラーメッセージや詳細情報を含めることで、クライアントが問題を診断しやすくなります。

5. リンク情報

• 特定のRESTful設計のスタイル（例：HATEOAS）では、関連するリソースへのリンクやアクションをレスポンスに含めることが推奨されています。

6.1 ステータスコードの分類

• 2xx (成功): リクエストが正常に処理された。
• 4xx (クライアントエラー): クライアント側に問題がある（例: 誤った情報を送信）。
• 5xx (サーバーエラー): サーバー側に問題がある。

6.2 主なメソッドとステータスコードの組み合わせ

• GET:
  • 200 OK: リソースが正常に取得された。
  • 404 Not Found: 要求されたリソースが見つからない。
• POST:
  • 201 Created: 新しいリソースが正常に作成された。
  • 400 Bad Request: リクエストに誤りがあり、リソースが作成されなかった。
• PUT:
  • 200 OK: リソースが正常に更新された。
  • 201 Created: 新しいリソースが作成された。
  • 400 Bad Request: リクエストに誤りがあり、更新ができなかった。
  • 404 Not Found: 更新対象のリソースが見つからない。
• PATCH:
  • 200 OK: リソースが部分的に更新された。
  • 400 Bad Request: 更新のリクエストに誤りがある。
  • 404 Not Found: 更新対象のリソースが見つからない。
• DELETE:
  • 204 No Content: リソースが正常に削除された（応答に内容はない）。200は応答に内容を含んでしまうが、DELETEは基本的に内容はない。
  • 404 Not Found: 削除対象のリソースが見つからない。

参考：

• REST WebAPI サービス 設計 Udemy
• 今さら聞けない REST とリソース指向
• REST（レスト）とは何か？わかりやすくまとめました【WEBの勉強】
• REST APIとは何かを調べまくったらようやくイメージができてきたのでまとめた
• REST APIとは何ですか？他のタイプとどのように異なりますか？
• 0からREST APIについて調べてみた
• 【よく見るものを一覧で解説】HTTPステータスコードとは？コード番号別に詳しく解説

2023年9月に読んでおもしろかった本📗

先月読んでおもしろかった本について、ネタバレにならない程度にざっくりご紹介します！

母という呪縛、娘という牢獄

毒親を持つ子どもの凄惨な人生が辛すぎる１冊

Amazonリンク

「娘（あかり）が母親を殺害し、その遺体をバラバラにして遺棄」。2018年3月、滋賀県で起きた実際の事件です。
女性記者の著者が、獄中のあかりに直接取材を重ねた結果、浮かび上がってきた母娘の関係性は深く考えさせられる内容となっています。

国立大学の医学部進学を母に強要され、9年間もの間、浪人生活を続けた娘・あかり。
テストの点数が低ければ鉄パイプで殴られる。
19歳の時、ある企業から内定を受けるも、母が勝手にそれを辞退する。
持っていた携帯は、母親に発見され、庭で破壊される。
母から受けた悪質な「躾」は挙げるとキリがありません。 似た経験を持たれている方は、精神的に結構危険なレベルかもです。

この本には、裁判での証拠として提出された、母と娘のLINEのやり取りが多数紹介されているのですが、それが本当に生々しいです。
母が娘の努力、才能、容姿、そして思想を全否定し、自らを裏切られた被害者として振る舞うやりとりには、あかりへの同情も生まれます。（実際に懲役15年の1審判決から2審では10年に減刑されています）

この事件自体を知らなかった私ですが、毒親とその子供との共依存の関係に興味を抱き、この本を手に取りました。
親子関係に実際に悩んでいる方には、正直刺激が強すぎると思いますが、ぜひ読んでもらいたい本です。

偉大な組織の最小抵抗経路 リーダーのための組織デザイン法則

エネルギーは最も楽な方に向かう。組織もそうだ！

Amazonリンク

組織論、とりわけ組織の改革に関して「構造」というキーワードをもとに論じた書籍です。 本書の大前提は、人も組織も、社会や経済システムも、ほとんど何もかもが「構造」によって支配されている、ということにあります。
「構造」とは、「全体として完成した一つの実体」のことを指します。
個々のパーツがひとまとまりになり、総合的な関係性のシステムとなって初めてまともな「構造」が作られます。
例えば、現代の自動車を様々なパーツをもって自動車という一つの実体を形作ります。
しかし、自動車を空に飛ばすことはできません。それは構造的に飛行が不可能だからです。

つまり、会社組織も様々な部署や人、ステークホルダーが関連して組織（という実体）となります。そしてそれを支えるのは「構造」です。
もしその「構造」が変革の目的を達成できる要件を満たしていなければ、どれだけ優れた施策・制度を実施しても意味がありません。（まさに空飛ぶ自動車のように）

「構造」という観点に立つ時、重要な発想が「最小抵抗経路」。 「最小抵抗経路」とはつまり、最も楽な方向・方法ということで、組織も「構造的」に「最も楽な方にしか進まない」というのが本書のキーです。
本書では、組織変革が失敗に至る理由は、その組織にとっての「最小抵抗経路」が変革を支えていないことだと主張しています。

本書は、「構造」という観点から語る組織論ですが、内容的にはそれほど奇抜な印象ではありません。
ゴールと現状の差を、適切な目標を立てて埋めていくといった、割と当たり前な手法なども多く語られます。 ただ、耳障りのよい施策ばっかりしても、基盤がグラグラだから意味なくないか？というのは、何においてもよくあることだと思うので、一歩俯瞰して物事を考えるきっかけとして良い内容でした。

大学4年間の西洋美術史が10時間でざっと学べる

絵画を見るときはこうやって見るのだ👀

Amazonリンク

大学で、少し西洋美術史について学んでいたのですが、改めて学びたくなったので読んでみました。
本書は、図版が多く登場するというよりは、絵画の見方（概ね「なぜこの絵が描かれたのか？」を考える方法論）を中心に教えてくれる内容です。

例えば、ルネサンス時代のフィレンツェなどでは、『旧約聖書』の外典『トビト書』の逸話をテーマとした「金貸しの息子が天使に守られながら旅をする」という主題の絵が多く描かれました。
この地域では、当時金融業が非常に盛んでしたが、当時の金融業はお金を物理的に運ぶ危険がつきものな仕事であったため、お守り代わりにこのような絵が多く描かれたと言われています。

「なぜこの作品が生まれたのか」を考えることは、関連する人物や土地、時代背景など、歴史を複合的に見ることになるため、歴史っておもしろい！と思える瞬間の一つです。
本書は、西洋美術史の入門書として、その体験ができる良い1冊だったと思います！

オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方

オブジェクト指向をRubyで学べる１冊

Amazonリンク

Rubyの学習をしていたのですが、クラスを用いた設計方法のベストプラクティスがイマイチよくわからず、本書を読みました。
中盤以降は、初心者の自分にとっては難しく、また読み直しが必要かなと思っていますが、基本的なオブジェクト指向の考え方を理解することができたと思います。

教科書的ではなく、少しポエミーなところもあるので、読解が難しいところはあります。

前半部分だけでも、クラスを用いた設計の考え方が頭の中で明確になるので、Ruby初心者の方にもお勧めできると思います。

『達人に学ぶDB設計 徹底指南書』感想ブログ

『達人に学ぶDB設計 徹底指南書』という書籍（以下、本書）を読み終えたので、その感想を共有したいと思います。

結論

本書は、データベース設計をしてみたいと考えている初心者の方にとって、非常に価値ある一冊であると感じました。
特に、美しい論理設計を行う方法やトレードオフの重要性、現実の業務でのヒントなど、多くの実践的な知識を身につけることができます。

一部初心者には難しい内容も含まれていますが、データベース設計のスキルアップはもちろん、業務でのトラブルを避けるための知見も得られると感じました。

良かったところ

1. 論理設計の理解が深まる
   論理設計に関して深く学ぶことができました。
   「論理設計における妥協は基本的には許容しない」という思想で書かれているので、美しい論理設計を目指すための指針になると思います。

2. 物理設計の重要性
   美しい論理設計を持つだけではなく、物理設計の重要性も強調してくれています。業務で実際にデータベースを運用する際に必ず意識しないといけないことだと感じました。

3. 業務での実践ポイント
   論理設計のバッドパターンや、バックアップ・リカバリ設計など、実際の業務で注意すべき点が詳しく説明されています。実際の現場でのトラブルを未然に防ぐヒントがたくさん詰まっています。

4. トレードオフの理解
   論理設計の美しさとパフォーマンスの向上という、2つの視点からのトレードオフ関係について、具体的なケーススタディを交えて解説されていました。これは、現実の業務で必ず検討しなければいけないポイントだと感じました。

学んだこと

• 3層スキーマモデルやデータ独立性についての基本的な知識
• データベースのパフォーマンスを向上させるためのRAIDやB-tree インデックス
• バックアップやリカバリの設計方針
• データベース設計の基礎となる正規化やER図
• オプティマイザの動作を理解するための統計情報やその収集方法
• 論理設計の一般的なバッドパターンとその対処法

難しかったこと

• 本書では、簡単なSQL文が時折出てきます。わからなくても支障はないですが、SQL文に関する詳しい説明はないので、既に知っている方が理解が深まると感じました。
• かなり理論的にデータベース設計について解説されているので、完全に初心者の方は少し取っつきにくいかもしれません。
• 物理設計についての解説もあるものの、詳細は別のリソースで学ぶ必要がありそうです。
• そして、本書を読んで特に感じたことは、「物事はトレードオフ」であることです。
  論理設計の美しさとパフォーマンスのバランスをどのように取るかは、結局はケースバイケースなので、実践しながら学んでいく必要があると感じました。

まとめ

本書は、データベース設計に関する深い知識や技術を学びたい方にはおすすめの一冊です。実際の業務での設計やトラブルシューティングのヒントとして役立つと思いました。