【雑学/歴史】ローマ暦の変遷

現在主に用いられるグレゴリオ暦を含み、
その由来は古代ローマから連なるローマ暦を元にしている。
最初に制定されたロムルス暦から現在のグレゴリオ暦に至るまで、
どのような変遷があったかをざっくりまとめた。

ロムルス暦 B.C. 753(B.C.745説もある) ～ B.C.713

• 古代ローマの建国時に採用された暦
• ローマの初代王ロムルスの名を取ってロムルス暦と呼ばれる。
• 現在の3月～12月に当たるMartiusからDecemberの10ヶ月
• 1年を10ヶ月(304日)とし、現在の1月から2月頃の期間は、
  該当する月・日付の無い日とされた
• 当時のローマ人は1年の正確な日数を知らなかったため、
  該当する日付の無い日は王が新年を宣言するまでの期間で不定だった。

ヌマ暦 B.C. 713 ～ B.C. 45

• 二代目王ヌマが紀元前713年に作った暦。
• 29日と30日の月を交互に繰り返す
• Januarius(現在の1月)とFebruarius(現在の2月)が追加され12ヶ月(355日)とした
• 実際の暦とは10日ほどずれが存在するため、数年に一度閏月(Mercedinus)を挿入した
• 改暦当初は年始の月はMartiusのままだったが、
  紀元前153年の改暦でJanuariusが年始の月となった

ユリウス暦 B.C.45 ～ A.C. 1582

• 紀元前45年にカエサルが作成した暦
• 1年を365日とし、4年に一度閏年を設ける暦になった
• Mercedinus(閏月)が用いられなくなった
• QuintilisとSextilisがそれぞれJuliusとAugustusとなった
  JuliusとAugustusは、カエサルと皇帝アウグストゥスに由来する説と、
  ユピテルとアウグストゥス(究極の神)に由来する説がある

グレゴリオ暦 A.C. 1582 ～

• 1582年にグレゴリウス13世が作成した暦
• ユリウス暦には誤差があり、暦の上での春分と天文的な現象としての
  春分がずれていくことから、重要な祭典である復活祭の定義に支障が出たため
• ユリウス暦の閏年の条件に、西暦が100で割れ、
  400で割れない年は閏年としないといった条件を加えるなどした

【Git】自分用チートシート

• 設定項目やリポジトリの作成
  • configの確認
    • git config -l
      • -listと同義
  • ユーザー名とメールアドレス
    • git config --global user.name "[name]"
    • git config --global user.email "[email address]"
  • gitの改行コード自動変換をオフにする
    • git config --global core.autoCRLF false
  • エイリアスの設定(例)
    • git config --global alias.co checkout
    • git config --global alias.st status
    • git config --global alias.br branch
    • git config --global alias.ci commit
  • HEADの意味
    • HEADは現在の最新状態
  • git用のディレクトリの初期化
    • git init
  • 共有リポジトリ(bareリポジトリ)の作成時
    • bareリポジトリは管理ファイルのみが作成される特別なリポジトリ
    • git init --bare
• リポジトリやワーキングツリーの状態確認
  • log
    • log一行表示
      • git log --oneline
    • 変更内容確認
      • git log -p
    • 変更ファイル確認
      • git log --stat
    • ツリーの分岐を表示
      • git log --graph
  • reflog
    • 今までのHEADの移動履歴を見る
      • git reflog
  • status
    • 現在の状況を確認
      • git status
    • 現在の状況を確認(簡易)
      • git status -s
      • git status --short
  • diff
    • 差分を確認する(作業フォルダ)
      • git diff
    • 差分を確認する(ステージング)
      • git diff --cached
• 変更の保存
  • add
    • ファイルを指定してステージングに上げる
      • git add [file path]
    • 全てのファイルをステージングに上げる
      • git add .
  • commit
    • ステージングにあるものをリポジトリに反映する
      • git commit
    • エディタを開かずワンラインでメッセージ付きcommit
      • git commit -m "[message]"
    • エディタを開かずワンラインでメッセージ付きcommit(全てのファイルのaddも同時に行う)
      • git commit -am "[message]"
        • git add .
        • git commit -m "[message]"
        • と同じ意味
    • 前回のcommitを修正
      • git commit --amend
• ワーキングツリーの状態変更や整理
  • checkout
    • 対象のファイルをHEADの状態に戻す
      • git checkout [branch name] --[file path]
    • 対象のcommitに作業ディレクトリを戻す
      • git checkout [commit id]
    • branchを切り替える
      • git checkout [branch name]
        • 作業ディレクトリの内容も選択したbranchに置き換わるので注意
    • branchを作って新しいbranchに切り替える
      • git checkout-b [branch name]
  • reset
    • ステージングをHEADの状態に戻す
      • git reset HEAD [file name]
        • 作業ディレクトリのファイルには影響しない
        • git reset --mixedの省略
    • すべて(作業ディレクトリ・ステージングエリア)を[commit id]の状態に戻す
      • git reset --hard [commit id]
    • すべて(作業ディレクトリ・ステージングエリア)を[commit id]のひとつ前の状態に戻す
      • git reset --hard [commit id]^
    • すべて(作業ディレクトリ・ステージングエリア・リポジトリの状態)を[commit id]の状態に戻す
      • git reset --hard [commit id]
    • [commit id]を取り消してHEADを[commit id]のひとつ前のcommitに戻す
      • git reset --soft [commit id]^
        • HEADの状態しか変わらない
    • 直前のHEADに戻る
      • git reset --hard ORIG_HEAD
        • 間違えてresetした時など、HEADを変更した場合にreset前のHEADの状態に戻れる
        • ORIG_HEADにはひとつ前のHEADの位置が記録されている
  • branch
    • 現在のbranchの一覧を確認する
      • git branch
    • branchを作る
      • git branch [branch name]
    • branchを削除する
      • git branch -d [branch name]
  • merge
    • branchをmerge(merge先のbranchにいる状態で)
      • git merge [branch name]
        • masterにdevelopをmergeするときはmasterにいる状態で
          • git merge develop
    • branchをmerge(ファストフォワードしない)
      • http://d.hatena.ne.jp/sinsoku/20111025/1319497900
      • git merge --no-ff [branch name]
        • ファストフォワードは、merge時に全てのcommitを統合すること
        • ファストフォワードをしない場合は、mergeをした時点のcommitが作成される
  • rebase
    • http://liginc.co.jp/web/tool/79390
    • http://tkengo.github.io/blog/2013/05/16/git-rebase-reference/
    • 別のコミットになる
      • rebaseは以前のコミットを取り消して、新しくコミットしなおしている
      • リモートリポジトリにコミットしている場合、巻き戻りや衝突の原因になる
    • --onto
      • $ git rebase --onto どこへ どこから どのブランチを
    • brunchの派生元を切り替える
      • git rebase [branch name]
        • 現在のブランチの参照元を[branch name]のHEADに付け替える
    • 競合を解決した後に実行して、再度rebaseする
      • git rebase --continue
    • rebaseを中止する
      • git rebase --abort
    • エラーを無視してrebaseする
      • git rebase --skip（エラーを無視する）
    • interactiveモード
      • rebase -i [commit]
        • pick（コミットを残す）
        • reword（コミットを残すが、コミットメッセージを変更）
        • edit（コミットを残すが、コミットしたファイルを修正する）
        • squash（一個前のコミットと統合してコミットメッセージを変更する）
        • fixup（一個前のコミットに統合する。コミットメッセージは統合先のものを使う）
        • exec（shellでコマンドを実行する）
  • revert
    • 指定のコミットの変更を差し戻すコミットを作成する
      • git revert
      • git resetは対象のコミットまで状態を巻き戻してしまうため、リモート上では行えない。こういう場合にrevertで行った変更を全て戻すコミットを作成する
    • Merge Commitの時
      • https://www.atlassian.com/ja/git/tutorial/undoing-changes#!revert
      • http://qiita.com/awakia/items/5fad0c454ddc7b478ff1
  • tag
    • 現在存在するtagの一覧を見る
      • git tag
    • 直前のcommitにtagをつける
      • git tag [tag name]
    • 特定のcommitにtagをつける
      • git tag [tag name] [commit id]
    • tagを削除する
      • git tag -d [tag name]
• 作成中のワーキングツリーの退避
  • stash
    • 変更を一時的に退避する
      • git stash
      • git stash save
    • 変更を一時的に退避する際にメッセージをつける
      • git stash save "message"
    • 現在退避されている一覧を表示
      • git stash list
    • N番目に退避したファイルの一覧を表示
      • git stash show stash@{N}
    • N番目に退避したファイルとHEADの差分を表示
      • git stash show -p stash@{N}
    • 退避した状態を作業ディレクトリに戻し、退避リストから削除する
      • 最新を対象にする
        • git stash pop
      • 指定の番号を対象にする
        • git stash pop stash@{N}
    • 退避リストから削除せずに退避した状態を作業ディレクトリに戻す
      • 最新を対象にする
        • git stash apply
      • 指定の番号を対象にする
        • git stash apply stash@{N}
    • 退避リストから削除
      • 最新を対象にする
        • git stash drop
      • 指定の番号を対象にする
        • git stash drop stash@{N}
    • unstage ファイルを全てスタッシュ
      • git stash -k
    • untrackファイルも含めて全てスタッシュ
      • git stash -u
• ファイルの削除や移動　名前の変更
  • rm mv
    • git rm [file　path]
    • git rm　--cached [file　path]
      • バージョン管理からファイルを削除する
    • git mv [file　path] [renamed　file　path]
      • ファイル名を変更してcommitする
    • git rm -r --cached
      • ステージングを綺麗にする
• リモートへの同期や反映
  • remote
    • 共有リポジトリの場所を設定する
      • git remote add [bookmark name] [remote url]
        • [bookmark name] = originは必須の名前ではないけどよく使われる
        • git config -lでそれぞれの[remote url]がどこにあるか確認できる
    • 共有リポジトリを削除する
      • git remote rm [bookmark name]
  • clone
    • 共有リポジトリを複製する
      • git clone [remote url]
      • git clone [remote url] [local directory]
  • push
    • 共有リポジトリにpush(反映)する
      • git push [bookmark name] [branch name]
        • remoteの[bookmark name]に[branch name]branchをpushする
  • fetch
    • リモートリポジトリから状態を取得し、ローカルリポジトリを更新する
      • http://qiita.com/osamu1203/items/cb94ef9da02e1ec3e921
      • http://www.backlog.jp/git-guide/stepup/stepup3_2.html
      • git fetch
      • git fetch
  • pull
    • fetch→mergeを自動で行う
    • 共有リポジトリからpull(取得)する
      • git pull [bookmark name] [branch name]
        • remoteの[bookmark name]から[branch name]branchを取得してmergeする
    • fetch→rebaseを自動で行う
      • git pull --rebase [bookmark name] [branch name]
        • remoteの[bookmark name]から[branch name]branchを取得してrebaseする

【デザインパターン】デザインパターンの勉強中メモ 構造に関するパターン

Adapter

利用したいクラスに利用したいメソッドが存在せず、
直接振る舞いを変えることにリスクがあるような場合に使う。
既存のクラスに修正を加えること無く、必要なインターフェースを追加するパターン。
継承を利用する場合と委譲を利用する場合の2通りがある。
継承の場合は、Adapterクラスの中からスーパークラスのメソッドを呼び出すなどして利用する。
委譲の場合は、利用したいクラスのインスタンスを内部で作成し利用したいメソッドを呼び出す。

Bridge

クラスを拡張しやすくするため、実装を呼び出す部分と実際の実装部分を分割するパターン。
拡張された呼び出しクラスは、スーパークラスを経由して実装を呼び出すので実装を意識しない。
拡張された実装クラスは共通のインターフェースを持つことで呼び出し元を意識しない。

お互いを意識しなくなることで、少ないクラスで同じ機能を実現できるようになる

Composite

木構造を伴う再帰的なデータ構造を、操作対象が枝か葉かを意識すること無く扱うパターン。
枝と葉の両方で同じインターフェースを持ち、同じように呼び出すことができるようにする。
枝のメソッドを呼び出した場合は枝全体を操作し、
葉のメソッドを呼び出した場合は自分自身の操作を行う。

Decorator

既存のオブジェクトに機能や振る舞いを動的に追加するパターン。
Decoratorクラスは引数に既存のオブジェクトを取り、拡張機能のみを実装したクラス。
拡張したい機能をDecoratorクラスのメソッドでラップし、
それ以外は実行時に引数で取った既存のオブジェクトのものを利用する。

Facade

複数のクラスの関与する、手順化された処理を一つにまとめ、
共通関数の公開メソッドとして実装するパターン。
実際に利用するクラスを隠蔽し、Facadeクラスのみを呼び出すことでシンプルな実装にできる。

Flyweight

別々の場所で複数回同じインスタンスを使用したい場合に、
同じインスタンスを保持して再利用するパターン。
利用時に生成するコストがインスタンスを使いまわすデメリットを上回ったときとかに使う。
DBアクセスを含む処理を行う場合やインスタンスの生成の数が膨大な場合など。

Proxy

既存のクラスと共通のインタフェースをもつProxyクラスを作成し、
Proxyクラスを経由して実際の処理を呼び出すパターン。
実際の処理を呼び出す前にフックした処理を行いたい場合や、
処理の実行可否を判断したい場合などに、
Proxyクラスのみの修正で対応できるようになる。

Decoratorパターンと類似しているが、
Decoratorパターンは動的に動作を変更することが目的、
Proxyパターンは既存のクラスの責務を減らし、代理できる処理を引き受けることが目的、
という目的の違いがあるので異なる。