tmuxとMacのクリップボードを共有する(tmux2.4以降対応)

tmuxとMacのクリップボードを共有する(tmux2.4以降対応)

なぜ書いたか

この記事を読んで、tmuxとMacのクリップボードの共有をしたらエラーになりました。ネットで調べたら情報が少ないので、まとめました。

qiita.com

再現手順

環境:

macOS Sierra 10.12.4

zsh

---

まずrettach-to-user-namespaceをインストールします。tmuxセッションの中で、MacOS Xのクリップボードにアクセスできるパッケージです。

github.com

$ brew install reattach-to-user-namespace

~/.tmux.confを以下のように書きます。

# ~/.tmux.conf

# Mac OS X pasteboardを使用できるようにする
set-option -g default-command "reattach-to-user-namespace -l zsh"

# コピーモードでvimキーバインドを使う
setw -g mode-keys vi

# 'v' で選択を始める
bind-key -t vi-copy v begin-selection
bind-key -t vi-copy y copy-pipe "reattach-to-user-namespace pbcopy"

# `Enter` でもcopy-pipeを使う
unbind -t vi-copy Enter
bind-key -t vi-copy Enter copy-pipe "reattach-to-user-namespace pbcopy"

# ']' でpbpasteを使う
bind ] run "reattach-to-user-namespace pbpaste | tmux load-buffer - && tmux paste-buffer"

bind-keyの引数の使い方が間違っているとのエラーメッセージが表示されます。

$ tmux source-file ~/.tmux.conf
/Users/ryuutarou/.tmux.conf:8: usage: bind-key [-cnr] [-T key-table] key command [arguments]
/Users/ryuutarou/.tmux.conf:9: usage: bind-key [-cnr] [-T key-table] key command [arguments]
/Users/ryuutarou/.tmux.conf:12: usage: unbind-key [-an] [-T key-table] key
/Users/ryuutarou/.tmux.conf:13: usage: bind-key [-cnr] [-T key-table] key command [arguments]

原因

tmux2.4からコマンドがリネームされているみたいです。

qiita.com

これが公式のドキュメントです。

https://raw.githubusercontent.com/tmux/tmux/master/CHANGES

CHANGES FROM 2.3 TO 2.4, 20 April 2017

Incompatible Changes
====================

* Key tables have undergone major changes. Mode key tables are no longer
  separate from the main key tables. All mode key tables have been removed,
  together with the -t flag to bind-key and unbind-key.

  The emacs-edit, vi-edit, emacs-choose and vi-choose tables have been replaced
  by fixed key bindings in the command prompt and choose modes. The mode-keys
  and status-keys options remain.

  The emacs-copy and vi-copy tables have been replaced by the copy-mode and
  copy-mode-vi tables. Commands are sent using the -X and -N flags to
  send-keys. So the following:

解決

まずは、tmuxのバージョン確認からです。私が今使用しているtmuxは2.6です。

$ brew  list tmux
/usr/local/Cellar/tmux/2.6/bin/tmux
/usr/local/Cellar/tmux/2.6/etc/bash_completion.d/tmux
/usr/local/Cellar/tmux/2.6/share/man/man1/tmux.1
/usr/local/Cellar/tmux/2.6/share/tmux/example_tmux.conf

2.4以降の記法にて.tmux.confを書き換えていきましょう。

2.3から2.4へ書き換える際に気をつけることは以下の通りです。

1. フラグ-tを-Tに変更する
2. vi-<name>を<name>-mode-viに変更する
3. 実行するコマンドの前にsend -Xもしくはsend-keys -Xを追加する

参考 github.com

書き換えた後の.tmux.confがこちらです。

# .tmux.conf

# Mac OS X pasteboardを使用できるようにする
set-option -g default-command "reattach-to-user-namespace -l zsh"

# コピーモードでvimキーバインドを使う
setw -g mode-keys vi

# 'v' で選択を始める
bind-key -T copy-mode-vi v send-keys -X begin-selection
bind-key -T copy-mode-vi y send-keys -X copy-pipe-and-cancel "reattach-to-user-namespace pbcopy"

# `Enter` でもcopy-pipeを使う
unbind -T copy-mode-vi Enter
bind-key -T copy-mode-vi Enter send-keys -X copy-pipe-and-cancel "reattach-to-user-namespace pbcopy"

# ']' でpbpasteを使う
bind ] run "reattach-to-user-namespace pbpaste | tmux load-buffer - && tmux paste-buffer"

再度読み込みます。

$ tmux source-file ~/.tmux.conf
tmux source-file ~/.tmux.conf

エラーがなくなり使えるようになりましたね!!

これでctrl + bの後に[を押して、選択モードにしてから、vで選択開始、yで選択終了してコピーします。

眠っているRaspberry pi 3をLINEのビーコンにしてみた

眠っているRaspberry pi 3をLINEのビーコンにしてみた

この記事はGMOペパボ Advent Calendar 2017の8日目の記事です

なぜつくったか

GMOペパボ Advent Calendar 2017の3日目の記事、「"Hello, World."の次としてのチャットボット」に触発されて、大急ぎでつくりました。家でRaspberry pi 3を眠らせておくのももったいなかったので、活用してみました。

どのようにして使える想定か

趣味で外回りの営業さん向けに、営業さんがLINE@にメッセージを送ると自動的にメールで本社宛に転送できるシステムを昔につくりました。実際に帰社したら、帰社をビーコンにより検知してイベント発火させて色々できることを想定してつくりました。(想定であり、実運用はしてません)

ソースコード github.com

どうやってつくるか

準備編

前提知識

• LINE BOTでHello Worldをリプライできる
• Raspberry piがBluetoothを使える状態にできるぐらいの習熟度

用意するもの

• Raspberry pi 3
• LINEの入ったスマホ
• Messaging APIのアカウント

動作環境

• PHP5.6.32
• line-bot-sdk1.1

今回つくったLINEbotはline-bot-sdkを導入しています。

LINE Bot SDK

LINE BOTを作成したことがない人は、こちらのページを見れば比較的に簡単につくれます。

codezine.jp

作成編

まずは、Raspberry pi 3側の設定をします。

LINEの公式ブログで詳しい記事があるので、詳細はそちらを参照してください。

engineering.linecorp.com

HWIDの発行

LINE@MANAGER ビーコン設定画面

上記のサイトのLINE Simple BeaconのハードウェアIDの払い出し > アカウント一覧で連携したいアカウントを選択 > ハードウェアID発行でHWIDの発行は完了です。

次にRaspberry pi 3側でコマンドを実行していきます。

まずはパッケージのインストールです。Linux向けのBluetoothのプロトコルスタックであるbluezおよび関連するパッケージをインストールします。

sudo apt-get install bluetooth bluez libbluetooth-dev libudev-dev

パッケージがインストールできたら、実行します。

# 発行されたHWIDを2桁ごとにスペースで区切ったものを指定
# ここで気をつけるのが、英字がLINE@MANAGERでは小文字なので大文字にします
HWID='01 0C 36 A2 95'

ADVERTISE_DATA="13 02 01 06 03 03 6F FE 0B 16 6F FE 02 ${HWID} 7F 00"

# Bluetooth HCIを有効にし、初期化します
sudo hciconfig hci0 up

# LE Controller Commands(OGF: 0x08), HCI_LE_Set_Advertising_Data(OCF: 0x0008) を実行し、
# 出力データを設定します
sudo hcitool -i hci0 cmd 0x08 0x0008 ${ADVERTISE_DATA}

#  Non connectable undirected advertising(3)で、Bluetooth LEのアドバタイズを有効にします
sudo hciconfig hci0 leadv 3

以上でRaspberry pi 3側の処理は完了です。次はwebhook先の処理です。

PHPでコードを書く

webhookとして設定しているサーバー側のエンドポイントに、ビーコンイベントをキャッチできるコードを書きます。これはビーコンイベント処理周辺部分のみを切り取ったものです。

<?php
// SDKをrequire
require __DIR__ . '/vendor/autoload.php'; // path to vendor/
$httpClient = new \LINE\LINEBot\HTTPClient\CurlHTTPClient(getenv('CHANNEL_ACCESS_TOKEN'));
$bot = new \LINE\LINEBot($httpClient, ['channelSecret' => getenv('CHANNEL_SECRET')]);
$signature = $_SERVER["HTTP_" . \LINE\LINEBot\Constant\HTTPHeader::LINE_SIGNATURE];
$events = $bot->parseEventRequest(file_get_contents('php://input'), $signature);

//ユーザーからのメッセージ取得
$json_string = file_get_contents('php://input');
$json_object = json_decode($json_string);

foreach ($events as $event) {
    // ビーコン処理
    if (($event instanceof \LINE\LINEBot\Event\BeaconDetectionEvent)) {
        $type = $json_object->{"events"}[0]->{"beacon"}->{"type"};
        if ($type === "enter") {
            $message = "お帰りなさい";
        } elseif (($type === "leave")) {
            $message = "行ってらっしゃい";
        }
        $body = <<<EOD
{$message}!!
EOD;
        replyTextMessage($bot, $event->getReplyToken(), $body);
        exit;
    }
}

function replyTextMessage($bot, $replyToken, $text) {
    $response = $bot->replyMessage($replyToken, new \LINE\LINEBot\MessageBuilder\TextMessageBuilder($text));
    if (!$response->isSucceeded()) {
        error_log('Failed!'. $response->getHTTPStatus . ' ' . $response->getRawBody());
    }
}
?>

ビーコン処理部分のみ解説していきます。

    if (($event instanceof \LINE\LINEBot\Event\BeaconDetectionEvent)) {

line-bot-sdkを利用して、LINEビーコンのイベントを簡単にハンドリングできるようになります。

        $type = $json_object->{"events"}[0]->{"beacon"}->{"type"};

LINEビーコンイベントによりwebhookされて送られてくるjson形式は、このような形になっています。

{
  "replyToken": "nHuyWiB7yP5Zw52FIkcQobQuGDXCTA",
  "type": "beacon",
  "timestamp": 1462629479859,
  "source": {
    "type": "user",
    "userId": "U4af4980629..."
  },
  "beacon": {
    "hwid": "d41d8cd98f",
    "type": "enter"
  }
}

詳細なドキュメントは、こちらを参照してください。

APIリファレンス

webhookされて送られてきたjsonオブジェクトの{"events"}[0]->{"beacon"}->{"type"}を参照して、ビーコンのイベントにより文言を変更します。

        if ($type === "enter") {
            $message = "お帰りなさい";
        } elseif (($type === "leave")) {
            $message = "行ってらっしゃい";
        }

テスト

早速ビーコンの範囲外に出てから範囲内に入ってみましょう。

赤丸の部分がleaveイベント(ビーコンの範囲外になる)とenterイベント(ビーコンの範囲内になる)を拾っています。

ビーコンから離れると行ってらっしゃい!!、ビーコンに近くとお帰りなさい!!が返ってきました！うれしいですね！ここからさらにIFTTTなどを使えば様々な応用が効きそうです。

大変だったこと

テストです。ビーコンの有効範囲が10メートル近くあり、物理的に移動しないとビーコンが反応しないので、外出から帰宅時しかテストできないのが辛かったです。

またline-bot-sdkの仕様のドキュメントが無さすぎて、手探りな感じも辛かったです。コードをみて使い方を覚えよみたいな感じでした。

それらの困難を乗り越えて動いたら楽しいですよ！！！家で余っているRaspberry piがあったらぜひ試してみてください。

【zsh】.zsh_historyを全端末に共有させる

.zsh_historyを全端末に共有させる

最近「余計なことしかしない男」とよく言われています。

なので、余計なコマンドを打たないように.zsh_historyファイルを全端末で共有して履歴からパパッと呼び出せるようにします。

環境はMacです。

Dropboxのセッティング

まずは.zsh_historyを全端末で共有するために、Dropboxをインストールします。

インストール - Dropbox

ホームディレクトリの直下にDropboxができれば、準備完了です！

.zshrcの編集

次にzshのhistoryファイルの場所を変更しましょう。

# historyファイルのパスの確認
$ echo $HISTFILE
/Users/name/.zsh_history

# Dropboxファイルに移動
$ mv ~/.zsh_history ~/Dropbox/

# 実行権限を付与
$ chmod 600 ~/Dropbox/.zsh_history

# .zshrcを編集して、$HISTFILEの変更
$ echo 'HISTFILE=$HOME/Dropbox/.zsh_history' >> ~/.zshrc

# .zshrcの再読み込み
$ source ~/.zshrc

# historyファイルのパスの確認
$ echo $HISTFILE
/Users/name/Dropbox/.zsh_history

これで１台目の準備は完了です。

２台目移行のセットアップ

先ほどと同じように、Dropboxをインストールします。

次に$HISTFILEを変更しましょう。

# .zshrcを編集して、$HISTFILEの変更
$ echo 'HISTFILE=$HOME/Dropbox/.zsh_history' >> ~/.zshrc

# .zshrcの再読み込み
$ source ~/.zshrc

お疲れ様でした！

これで端末間で.zsh_historyを使いまわせるハズです。

一度実行したコマンドは、履歴から呼び出して楽しましょう！！

【git】revertとresetの違い

revertとresetの違い

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

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

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

現在の状態

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

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

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

revert

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

git公式リファレンスより

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

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

$ 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」に戻してみましょう。

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

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

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

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

reset --hardとreset --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サーバ証明書の料金比較と選び方総まとめ

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

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

最後に

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

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