fv17の日記

Webエンジニアの備忘用ブログです。主にWeb界隈の技術に関して書いています。

【Git】直前のコミットを取り消す

直前のコミット取り消す

# コミット取り消し・作業ディレクトリはそのまま
$ git reset --soft HEAD^

# コミット取り消し・作業ディレクトリも取り消し
$ git reset --hard HEAD^

その後、再度修正を加えてGithubにpushする

修正後、git commitして再度push。
pushする時 -f オプション付けないとGithubRejectされるため注意。

graphql-rubyのAuthorizationに関する学習メモ

Authorization
https://graphql-ruby.org/guides#authorization-guides

概要

Authorization: GraphQL vs REST

  • REST APIはリクエストされたアクションの直前に、クライアントがそのアクションに対して権限を持っているかを判断する。
  • この考え方はGraphQLではマッチしない。その理由は、GraphQLの場合はコントローラが一つしかないため。
class GraphqlController < ApplicationController
  def execute
    # すべてのqueries、mutationsがここを通るため、この段階でどのような権限が必要か判断できない
    if current_user.can?(:"???")
      MySchema.execute(query_str, context: ctx, variables: variables)
    end
  end
end

では、どのような考え方をするべきか?

  • queriesの場合、取得するオブジェクトに対する権限を持っているか
  • mutationsの場合、それぞれのmutationを実行する権限があるか

GraphQLにおける認証

そもそも認証とは?

  • 認証とは、どのユーザーが現在のリクエストを行っているかを判断するプロセスのこと。例えば、usernameやpasswordによる確認、sessionによる確認など。
  • 認可とは、現在のユーザーが何をする/見る権限を持っているかを確認するプロセスのこと。例えば、admin?ステータスの確認やデータベースからの権限グループの検索。

認可の例 (https://graphql.org/learn/authorization/より)

Only authors can see their drafts

認証はGraphQLでは扱われていない。代わりに、コントローラはHTTPリクエスト(例えば、HTTPヘッダやクッキー)に基づいて現在のユーザを取得し、その情報をGraphQLクエリに提供する。そうすれば、GraphQLのコードにおいて、current_userはcontext[:current_user] でアクセスできる。

class GraphqlController < ApplicationController
  def execute
    context = { current_user: current_user }
    MySchema.execute(query_str, context: context, ...)
  end
end

ビジネスロジックに認可を委任する

リンク先参照

オブジェクト指向のこころ - 12章 エキスパートはどのように設計するのか?

勉強用メモ

概要

  • Alexanderの設計アプローチを学ぶ
  • まず全体像を捉え、そこから詳細やそれらの関連を探っていくというアプローチ

まとめると?

建築学においても、中庭、車庫、玄関、トイレなどの概念を洗い出し、それらが使われる場面・コンテキストを把握し、大まかな関連(配置)を決定した後、それぞれの詳細を考える。その詳細を考えながら大枠との整合性は取れているか、大枠と詳細を行ったり来たりしながら詰めていく。この考え方をソフトウェアにも応用する。

オブジェクト指向のこころ - 11章 Abstract Factoryパターン

勉強用メモ
書籍のUML図ないと、これだけ見ても何もわからないな...

Abstract Factoryパターンとは

  • オブジェクトの生成と使用の責務を分ける
  • 状況に応じてオブジェクト群を使い分ける際に用いる

switchやif分岐は抽象化を示す赤信号の可能性

  • アルゴリズムや利用するオブジェクトの選択するための分岐は危険
  • 高い結合度と低い凝集度により、メンテナンスコストが上がり、カオスになりがち
  • 特に、ある変数が複数のswitchに使われ、switch同士が結合した時

下記で "MIDDLE" が増えた場合にどうする?

if RESOLUTION = "LOW"
  # 処理
elsif RESOLUTION = "HIGH"
  # 処理
end

安易な継承も赤信号。将来的に組合せ爆発が発生するから。

税計算の問題でも同様のことが記述されていた。ifやswitchによる処理の分岐や、継承による問題の解決には危険が潜んでいることが繰り返し述べられている。

どうすればいい?

  • Bridgeパターンで学んだように、共通性/可変性分析でオブジェクト群に分ける
  • それらのオブジェクト群を使用する側、使用される側に分けて設計する

ここで新たな問題、「適切なオブジェクトをどうやって生成するのか?」が生まれる。
必要なオブジェを実体化するFactoryオブジェクトを用意する。

オブジェクト指向のこころ - 10章 Bridgeパターン

勉強用メモ

P.152以前は電車で

継承の多用はNG

  • 流動的要素をクラス継承で扱うのは間違え。クラス数の爆発が発生する
  • オブジェクトを責務で考え、集約を多用することが正しい
  • 流動的要素をカプセル化する

パターンを導き出す

  • まずは、共通性/可変性分析で流動的要素を洗い出す cf.図10.9(P.158)
  • 次に、クラス群の関連性を考える。一方のクラス群からもう一方を使用する

オブジェクト指向のこころ - 6章 Facadeパターン

勉強用メモ

Facadeパターンとは

Facadeとは「建物の正面(窓口)」、「見せかけ」等の意味を持つ。

  • 問題:複雑なサブシステム群があり、クライアントはどのメソッドを呼び出せばいいか把握できない
  • 目的:理解しやすいインターフェースを提供し、クライアントが理解しやすく呼び出しやすくする

Facadeパターンの利用場面

  • 呼び出し方法の簡易化:既存システムの学習コストが高く、簡潔なインターフェースを作成したい
  • システムの利用状況の追跡:特定のシステムに対するアクセスをFacade経由にする
  • システムの交換や刷新:既存クラスをFacadeのprivateメソッドにしておけば、クライアント側へ影響を最小限にできる

CAD/CAMの問題とFacadeパターンの関連

  • V1SlotやV1HokeがV1Systemを使用する場面で上手く使える