日記帳

プログラミングのことをつぶやく日記です。

【git】revertとresetの違い

revertとresetの違い

f:id:leokun0210:20171115004251p:plain

コミットを戻したい時にgit revertgit resetのどちらを使うか迷うyamakawa00です。

忘れないようにブログにまとめておきます。

前提条件 - commitができる。 - conflictが理解できる。

現在の状態

まずは、現在のブランチの状態です。

f:id:leokun0210:20171115000548p:plain

HEADがコミットハッシュ「4」にある状態です。

「3」にバグがあり、そのコミットを消したい状態です。




revert

1つ以上の既存のコミットがあれば、関連パッチが導入した変更を元に戻し、それらを記録する新しいコミットをいくつか記録します。これには、作業ツリーがきれいである必要があります(HEADコミットからの変更はありません)。

git公式リファレンスより

公式ドキュメントを見てもよくわかりませんね...

わかりやすく図にして見ました!

f:id:leokun0210:20171115001135p:plain

$ git revert [3のコミットハッシュ]

git revertとは、指定したコミットハッシュを打ち消すコミットを新たに行う行為をです。

上記の例では「3」のコミットを打ち消しています。

ただし基本的には、直前のコミット(つまりHEAD)を打ち消すために用いられます。

なぜ直前のコミットに適応するかというと、上記の図のように直前ではないコミットを打ち消すとコンフリクト(衝突)するからです。




revertのコンフリクト

「3」のコミットで「2」の変更点を消し、「4」のコミットで「3」の変更点を消すとどうなるでしょうか?

答えはコンフリクト(衝突)します。

実際にコンフリクトしたファイルは、こんな感じです。

diff --cc README.md
index 6a1769f,0c4a8b1..0000000
--- a/README.md
+++ b/README.md
@@@ -1,2 -1,2 +1,6 @@@
++<<<<<<< HEAD
 +4番目のcommit
++=======
+ 2番目のcommit
++>>>>>>> parent of 6c3bbd4... 3

コミットとは、コードの歴史を表すものです。

中学生の黒歴史を隠したいからといって、中学3年間を抹消すると、どこかで綻びが生じるので気をつけましょう。




reset

現在のHEADを指定された状態にリセットすることです。

ここでは、HEADを「2」に戻してみましょう。

f:id:leokun0210:20171115002253p:plain

$ git reset --hard [2のコミットハッシュ]

これで、HEADは「2」になっています。

「3」「4」は削除されます。

(厳密に言えば削除はされずに記録は残っています。ここから復元も可能です。)




reset --hardreset --soft

resetには--hard--softの二つのオプションが存在します。

$ git reset --hard [コミットハッシュ]
$ git reset --soft [コミットハッシュ]

--hardは、現在のファイルの状態をHEADの位置の指定コミットまで復元します。

--softは、現在のファイルは特に変更せずに、HEADの位置を指定コミットまで移動します。

つまり--softは強くてニューゲーム状態です




【まとめ】revertとresetの違い

最後に両者のメリット、デメリットをまとめてみます。

どちらを使えばいいかはケースバイケースでしょう。

コマンド メリット デメリット 使用ケース
revert コミットログ自体は残っているので、revertの取り消しが容易 基本的には、直前のコミットの打ち消ししかしない方が良い。なぜなら、コミットの整合性が取れなくなってしまうからである。 直前のコミットにバグがあるので消したい時
reset HEADの位置を大幅に移動できる。 以前のコミットを復元するのが少し手間 直前のコミットではないものにバグがある

# WEB DB PRESS 100 「完全HTTPS化」 感想・まとめ

はじめに

WEB DB PRESS 100 「完全HTTPS化」 感想・まとめ

1,2章のみです。

汎用的な項目のみをまとめてあります。

HTTPSとはそもそも何か

HTTPSは、みなさん同じみのHTTPによる通信をSSL(Secure Soke Layer)あるいはTLS(Transport Layer Security)によってより安全な通信とするための仕組みです。

HTTPSでは公開鍵暗号を用いて、Webサーバーにあるサーバー証明書をWebブラウザにインストールされているルート証明書で検証します。その上で共通鍵暗号の鍵を生成し、公開鍵暗号を使ってWebサーバーと鍵交換を行います。

利用者がHTTPかHTTPSのどちらで通信してるかを判定するには、ブラウザのアドレスバーが「保護された通信」かそうではないか確認するばいいので、一目瞭然ですね。

なぜ完全HTTPS化するのか

これまで

HTTPSはログインや登録情報の参照など、いわゆる個人情報や認証情報を扱う箇所のみに使われていました。 その理由は、データ量増加やHTTPSの処理負荷などオーバーヘッドが大きかったことが考えられます。

企業のコーポレートサイトだと、トップページはHTTPなのに、質問ページだとHTTPSなんてことよくあります。

入力フォームがあるのに、HTTPS化されていない企業のサイトは、その会社全体のセキュリティ意識の低さが体現されてます。

これから

サービスをよりセキュアにするという目的

HTTPSの利用を考えるにあたりまず思い浮かぶ利点は、「通信を暗号化できる」そして「通信先を認証できる」ことでしょう。

情報の重要度に関わらず、全ての入力フォームをHTTPS化することで、情報の安全性の選別が必要無くなります。

OS、ブラウザ、検索エンジン等のプラットフォームの進化に対応する目的

Chorome56でリリースされた、HTTPページにログインフォームが表示されている場合に「保護されていない通信」という警告を出す機能は、多くのHTTPページでログインのモーダルを表示していたクックパッドにも影響を及ぼす変更でした。

たまに、HTTPS化されてないサイトにアクセスすると、赤い画面で警告が出ますよね

あれは心臓に悪い

Googleは検索ランキングに置いてHTTPSの利用有無をランキングアルゴリズムに利用することを発表しています。

ここ最近、はてなブロガーの間でも話題になってました。

アクセス数落ちるし

開発のしやすさを考慮して

(クックパッドの例として)HTTPSが必要な箇所全てに、HTTPSを必須化する共通のロジックを書く必要がありました。これでは、本来HTTPSであるべ画面とそうでないなどの事故が起きやすくなってしまいます。

ソースコードでURL指定してる箇所の修正って地味に面倒なんですよね

新しい技術に対応

新しいWebの仕組みは、その多くがHTTPSであることを前提としています。

最近の技術はHTTPSを前提に実装されています。

導入するまでのロードマップ

組織内での協力を得る

組織内で実践する場合はあらかじめ完全HTTPS化を宣言するなどして、多くの方の協力を得ることが重要です。なぜなら、完全HTTPS化は単純にURLが"HTTP://“から"HTTPS://"に変更されるだけではなく、コードの修正やユーザー体験の変化、壊れている箇所がないかのチェックなど様々な影響を及ぼす可能性があるためです。

トップダウンで、意識共有していかなければいけない問題です。

意思決定者が、なんのためにHTTPS化するのかを社内に浸透させて取り組まなければならないが、その意思統一が難しそう。

証明書の選び方

Webサービスに置けるHTTPS(TLS)通信には適切な公開証明書が必要です。「適切な」というのは、主に以下の要件を満たすことを指します。

・多くのブラウザが信頼する認証局から署名されている

・示したい情報を含められる認証方式が使われている

・安全な署名アルゴリズムが利用されている

公開鍵証明書は、HTTPS(TLS)を再構築する上で非常に重要な要素です。証明書そのものは検索エンジンで「SSLサーバー証明書」などと検索すれば販売しているサービスを多く見つけることができますが、それぞれの証明書が一体どういう特徴、意味を持つのかを押さえた上で利用する証明書を決めましょう。

SSLサーバ証明書の料金比較と選び方総まとめ

証明書の選び方でのポイントは、箇条書きにすると下記の通り

  • ブラウザ対応率
  • 有償無償のどちらか
  • 認証方式について
  • 署名アルゴリズム

最後に

自分はインフラの部分の知識が弱く、本特集の後半部分のリリース後の運用、影響の部分は まだ、文章にして書き残さなくてもいいかなーと思っています。

必要な時期がきたら、本棚からこの号を引っ張ってきて見返します。

プロになるためのWeb技術入門 感想 読書感想

はじめに

Web業界に転職して、そろそろ1年が経過します。

今まで勉強した知識にどの程度抜け漏れがあるのか確認のために、今更ながら「プロになるためのWeb技術入門」を読みました。

改めて理解が促進した箇所、新たな発見があった箇所を列挙します。

なお、私の頭脳のワークスペースの都合上、書籍の前半部しかまとめられてないです。

プロになるためのWeb技術入門

リソースの位置を示すURL

URLの仕組みは、なんとなく使っているので、改めて復習しました。

URLは、ブラウザにアドレスバーに打ち込む文字列です。

インターネット上のコンテンツを一意に指定するための仕組みが「URL(Uniform Rsource Locator)なのです。

日本語に訳すと「統一資源位置子(とういつしげんいちし)」となります。

http :// /www.littleforest.jp / webtext/index.html
スキーム ホスト名 パス名

パーセントエンコード

https://www.test/index.php?name=%E3%83%86%E3%82%B9%E3%83%88

インターネットサーフィンをしてるとURLに「%」が混じることがありますよね

URLは全角文字は使用できないので、ブラウザ側がサーバーでも読み取れる文字にエンコードしてくれます。

これが「パーセントエンコード」です。

スキーム

そもそもhttpsとは何なんか最初のうちはよくわかりませんでした。

スキームは、リソースを取得するための方法を表します。Webアプリケーションにえいては、ほとんどの場合「http」となります

スキーム名 説明
https 暗号化されたhttp通信を表すスキーム
mailto 電子メールの宛先を表すスキーム
ftp FTPプロトコルによる入手を表すスキーム
file ファイルシステム中のファイルやディレクトリを参照するためのスキーム

業務では、httpsftpはよく触れる印象があります。

URLとURIの違い

他のWeb技術の基礎本を読んでいるときに、URLという単語という単語がほぼ登場せず、代わりにURIという単語で使われていることがあります。

URLとURIの違いはなんでしょうか。

URIは、URLをより拡張した概念として、URI(Uniform Resource Idenrifier)が考え出されたのです。

URIとは、URLに加えて「URN(Uniform Rsource Name)」を合わせたものを指します。

URNはインターネット上に存在する名前を一意に識別するために用意されたものです。

URLの場合は、ホストが移動すると移動先のURLを知らないとアクセスできなくなります。

URNは、このようなリソースの移動に関しての問題を解決するために、インターネット上に存在するリソースに対しては統一的な名前を決めようと考え出されたものです。

例えば、「nrn:itif:rfc:2616」は、HTTP1.1のRFCに対するURNです。この文書が物理的にどのような位置に存在しようと、同じURNで指し示すことができるというわけです。

現状ではURNはあまり利用されておらず、実質的にはURIもURLもほぼ同じ意味で扱われています。

混乱の元はURIとURLもほぼ同様の意味で使用されているため、なぜ2種類もの呼び方があるのか理解できないことです。

このように背景を理解してしまえば、理解しやすいですね。

Webベンチャーで働いている人に、あまり馴染みのないサーブレットJSP

PHPRubyでアプリケーションを作っていると、Javaに対してあまり馴染みがありません。

しかしJavaエンタープライズでのWeb開発で使用されている言語、歴史的変遷だけでも知っておくのがいいかと思いました。

サーブレットの誕生

Webが普及しCGIが一般的になると、新たな問題が生まれました。

1つはPerlの仕様による問題、もう一つは多数のリクエストによるアクセス負荷の増大する問題です。

Java自体はWebアプリケーションのために開発された言語ではありません。しかし、Webアプリケーションは当時企業に置けるシステム開発でも主流になりつつありました。

そこで、JavaEE(Java Enterprise Edition)の一部として「サーブレット(Servlet)」というWebアプリケーション開発をサポートするため目の機能が供給されるようになったのです。

サーブレットJavaで作られたHTMLなどのWebコンテンツを生成するためのプログラムのことで、CGIを経由して起動されるPerlC言語Java版に相当します。

サーブレットは基本的にCGIと同じ考え方ですが、コンテンツを生成する言語がJavaであり、オブジェクト志向のサポートによって大規模アプリケーションの開発に向いていることと、Webサーバーと同じプロセスの中でコンテンツを生成するプログラムが動作するため、CGIのように新たなプロセスを毎回起動する必要がなく、比較的高速に動作するということが利点でした。

Javaの優れた特徴をWebの世界に持ち込み、発展させたということですね。

ただJavaエンタープライズ要素が強いので、なかなか個人開発では使用する機会がないです。

サーブレットのコードの例はこんな感じです。

mport java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class Calc extens HttpServlet {
    public void doGet(HttpServletRequest request,
        HttpServletResponse response)
        throws ServletEception,IOException {
        // コンテキストタイプの設定
        response.setContentType("text/html;charset=Shift_JIS");

        // HTML出力の準備
        PrintWriter out=response.getWriter();

// HTMLの出力
    out.println("<html><head>");
    out.println("<title>Calcurator</title>");
    out.println("</head><body>");
    out.println("<p>1000円の税込み価格 ="+ (1000 * 1.08) +"円</p>");
    out.println("</body></html>");

// HTML出力の完了処理
out.flush();
out.close();
    }
}

今見ると可読性が悪いですね。

HTML部分を追うのに一苦労です。

サーブレットのコードは、レガシーPHPに通づるものがあると考えています。

サーブレットの弱点を改善したJSP(Java Server Pages)の誕生

サーブレットの弱点は、画面デザインの変更が初制するたびに、プログラムの変更が必要になること。

さらに、Javaソースコードの中にHTMLが点在するため、可読性が悪いことです。

この弱点、ノンフレームワークPHPプロジェクトに類似する部分がありますよね

これを解消したものがJSP(Java Server Pages)です。

先ほどのサーブレットソースコードJSPに置き換えます。

<html>
<head>
<title>Calcurator</title>
</head>
<body>
<p>1000円の税込価格 = <% out.println(1000 * 1.08); %> 円</p>
</body>
</html>

これってRailsとかCakePHPのview部分に似てますね。

用途の近しい技術は類似していくんですね。

感想

最初は自分用のまとめにしようと思ったのですが、段々熱が入り、少しでもまとめようという気持ちが出てきました。

しかし、読み手を考えると、書籍の感想のまとめは難しく、結局前半部分しかまとめられませんでした。

後半は、何か別の書籍とミックスしたいと思います。

S3にアップロードしようと思ったら、時計がズレていたので失敗した。

S3にアップロードしようと思ったら、時計がズレていたので失敗した。

環境

S3にアップロードしようと思ったら失敗した。

S3にアップロードしようと思ったら、以下のメッセージが返ってきました。

The difference between the request time and the current time is too large.

日本語訳:リクエストサーバーとS3の時間のズレが大きすぎる

同様の問題の解決記事

[Rails] 時計のズレが原因でS3への画像アップロードが失敗した

原因は、S3のサーバー時刻とWebサーバー時刻にズレがあったため

まずntpdateで自分のサーバーの時刻と日本標準時間を同期します。 Webサーバーは、vagrantを使用しています。

$ sudo ntpdate ntp.nict.jp
 6 Aug 14:02:10 ntpdate[7681]: adjust time server 133.243.238.244 offset 0.003161 sec

## ntpdateとは

ntpdateコマンドでは、日付と時刻をNTPサーバーと同期するコマンドです。

ntpdate - 日付と時刻をNTPサーバーと同期 - Linuxコマンド

以下ntpd関連資料

NTPサーバー構築(ntpd)

14.4. ntpd の起動と動作確認

ntpdデーモンの設定を変更したので、ntpdを再起動しましょう。

$ sudo /etc/rc.d/init.d/ntpd restart
ntpd を停止中:                                             [  OK  ]
ntpd を起動中:                                             [  OK  ]

これでOK!!