gitでコンフリクトマーカーが入ったままの状態ではターミナルからコミットできないようにする設定

ターミナルでgitを操作しているとき、コンフリクトマーカー(<<<<<<<とか=======とか>>>>>>>ね)が残っていたらコミットできないようにする設定の紹介。

まぁこんなアホなことをやっちゃう人はめったにいないのか?gitのオプションにはそれらしきものはなく、日本語ではそれっぽい記事が検索でヒットしなかったのでさらに検索の範囲を広げたところ、以下の方法が良さそうでした。

上のページの手順は、

  1. 上記ページのpre-commitファイルをローカルのgitリポジトリ/.git/hooks/pre-commitにコピー
  2. このpre-commitファイルに実行権限を与える(chmod u+x pre-commit)

だけです。

上記ページの埋め込み元のgistがなぜかsecret(private)なのでここでは引用しませんが、見て分かるようにコンフリクトマーカーがあったらコミットを中止する簡単なシェルスクリプトです。

で、こうすると、コミット時にコンフリクトマーカーが残っていたらコミットが中止され、警告メッセージが表示されるようになります。

わたしの場合、上のJonさんの方法にプラス、「=======」も対象にしたかったので17行目の

echo $changed | xargs egrep '[><]{7}' -H -I --line-number

echo $changed | xargs egrep '[>=<]{7}' -H -I --line-number
にして、全部のローカルリポジトリで摘要したかったので、

を参考に
$ git config --global init.templatedir '~/.git_template'
として~/.git_template/hooks/pre-commitに置いています。

これで新規にcloneする場合は自動的にこのpre-commitファイルが.git/hooks/にコピーされます。

既存のリポジトリの場合はgit initとするとこのpre-commitが.git/hooks/にコピーされます。

ちなみに、既存のリポジトリでgit initしても安全です 😉

Running git init in an existing repository is safe. It will not overwrite things that are already there. The primary reason for rerunning git init is to pick up newly added templates (or to move the repository to another place if –separate-git-dir is given).

https://git-scm.com/docs/git-init

ではでは!

 

WP-CLI のバージョン0.22以下はこれからリリースされるWordPress 4.5と互換性がないとのことなのでご注意を!

WP-CLIのバージョン0.23.0がリリースされました。これ以前のWP-CLIはこれからリリースされるWordPress 4.5とは互換性がないとのことなので、ご注意を!

Version 0.23.0 released | WP-CLIより、

This release includes WordPress 4.5 compatibility. Older WP-CLI versions are incompatible with WordPress 4.5. If you’re planning to use WordPress 4.5 in the future, you’ll need to upgrade before you do.

このリリースにはWordPress 4.5との互換性が含まれています。古い WP-CLIのバージョンはWordPress 4.5との互換性がありません。WordPress 4.5を使う予定であれば、WordPress 4.5がリリースされる前にWP-CLIをアップグレードしてください。

 

AWS CLI(コマンドラインインターフェース)でAMIMOTOのインスタンスをいじってみる

AMIMOTO Advent Calendar 2015の20日目です!

ということで、AWS CLIでAMIMOTOインスタンスをいじってみます。

AWS CLIのホームページは、

まずはインストール。Macなのでターミナルで、

$ pip install awscli

だけ!

追記: 2015年12月28日
pyenvでPythonの環境を作ってると~/.pyenv/配下にインストールされるんで、brew install awscliの方がいいかも。

pipはPythonのパッケージ管理ツール。へー、AWS CLIはPython製なんですね。

次に設定。

$ aws configure
AWS Access Key ID [None]: YOURACCESSKEY
AWS Secret Access Key [None]: YOURSECRETKEY
Default region name [None]: ap-northeast-1
Default output format [None]: json

アクセスキーとシークレットアクセスキーはIAMコンソールから取得できます。
詳しくは
http://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-chap-getting-set-up.html
のTo get your access key ID and secret access keyを参照してください。

リージョンは近いところを。日本ならap-northeast-1(アジアパシフィック(東京)リージョン)。

出力フォーマットはデフォルトでjson。ほかにtext、tableがあります。

ついでなんで、シェルでタブ補完できるようにします。bashなら以下のコマンドを実行
$ complete -C '/usr/local/bin/aws_completer' aws
すると、
$ aws s
とうってからタブキーを押すと

s3 ses ssm support
s3api sns storagegateway swf
sdb sqs sts

のように補完候補が表示されるはずです。

それ以外のシェルは
http://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-command-completion.html
を参考にしてください。

さて、ではインスタンスの情報を取得してみます。

$ aws ec2 describe-instances

たぶんjson形式でずらずらっと表示されるはずです。

で、ちょっとここでインスタンスIDの一覧だけ表示してみましょう。ちょっと調べたのですがそういうコマンドなりコマンドオプションなりはないようなので
http://docs.aws.amazon.com/ja_jp/cli/latest/userguide/controlling-output.html
に掲載されているように --query オプションを使って以下のようにしてみます。

$ aws ec2 describe-instances --query 'Reservations[*].Instances[*].[Placement.AvailabilityZone, State.Name, InstanceId]' --output text | grep running | awk '{print $3}'

どうでしょう? 普通に網元を使ってるだけならインスタンスIDが一つだけ表示されたと思います。

次にそのインスタンスの状態をしらべてみます。

aws ec2 describe-instance-status --instance-id i-XXXXXXXX

(略)
"InstanceId": "i-9d58d538",
"InstanceState": {
"Code": 16,
"Name": "running"
},
(略)

“running”になってますね。
ではいきなりですが、停止してみます。

aws ec2 stop-instances --instance-ids i-XXXXXXXX

でふたたび

aws ec2 describe-instance-status --instance-id i-XXXXXXXX

とすると、

"InstanceStatuses": []

となりました。これでサイトにアクセスしても接続できないはず。
ではまた開始。

aws ec2 start-instances --instance-ids i-XXXXXXXX

起動するまで少し時間がかかるので、ちょっとたってからまた状態を確認すると、

aws ec2 describe-instance-status --instance-id i-XXXXXXXX

(略)
"InstanceId": "i-9d58d538",
"InstanceState": {
"Code": 16,
"Name": "running"
},
(略)

となりました!

以上、簡単な紹介でしたが、やっぱウェブサイトのインターフェースよりは楽ですなw
他にもいろいろできそうなので、おいおい調べていきたいと思います。

では快適な網元ライフを!

Transifex Live Translation Pluginを使ったWordPressサイトの多言語化

これは言い出しっぺの特権により初日をゲットした、WordPress Advent Calendar 2015への記事です。

Transifexというウェブ翻訳プラットフォーム(ウェブサービス)はご存知でしょうか? OSS界隈の翻訳プラットフォームとしてはけっこう使われていて、わりと古くからあります。

ここで紹介するのは、このTransifexTransifex Liveという最近出た機能を利用したWordPressの多言語化(多言語表示?)のためのプラグインです。

西川さんが「WordPress の多言語化で考えることとプラグインの比較 | Shinichi Nishikawa’s」で紹介されている他の多くのプラグインとはだいぶん違った仕組みなので、ざっと説明すると、

  1. Transifex Liveが該当のウェブページをスクレイピングして翻訳元になるテキストをTransifex上に取り込む
  2. それを自分で(もしくは誰かが)Transifex上で翻訳してプッシュすると、翻訳されたテキストがTransifexのCDN上に配備される
  3. その翻訳したテキストが該当のウェブページ上でJavaScriptによってオリジナルのテキストと直接置換される

という感じです。

このサイトでも入れてますので、左上の「日本語」のタブクリックして「English」に変えてみてください。

transfix-en

どうでしょう? サイトタイトルの「わーどぷれすっ!」とその下の「WordPressに関するあれとかこれとか」がそれぞれ「waadopuresu」と「Something about WordPress」に変わりましたでしょうか?

ブラウザの言語設定がもし「English」になっていれば、最初から翻訳されたテキストが表示されているかもしれません。

他のプラグインとの比較でメリットになると思うのは、

  1. Transifex上の翻訳メモリ機能が使える
  2. パラグラフで分割されるので、同じページを複数人で同時に翻訳できる

デメリットとしては、

  1. TransifexのCDNからのネットワーク上にもし不具合が発生したら機能しなくなる
  2. まぁいまどきのブラウザではありませんが、ブラウザのJavaScriptが動作しなければ機能しなくなる
  3. 「現時点ではSEO的に、そしてアクセシビリティ的によろしくない」
    Toruさんのコメントより

    パーマリンクが同一なので言語と地域が分からず、かと言ってhreflangも埋め込まれておらず…SEO的にもアクセシビリティ的にも、ウェブサイトでは使えなさそう?

あとは、、なんだろ。もしほかに思いついたら教えてください!

では詳しい手順:

  1. Transifex Live Translation PluginをWordPressにインストールして有効化
  2. Transifex Live WordPress Plugin Settingsをクリックし、ページを開く
  3. Click here to sign up and get a API key for free.」をクリックして、Transifexにサインアップ、ログインします。
  4. 次に、Transifex上にプロジェクトを作り、テキストを取り込む元のURL等を設定したりするのですが、まだ最近出来たサービスなのでUIとかステップとかが変わりそうななので、詳しくは公式のドキュメントを参照してください。
    ポイントとしては、「2. Choose project type」で「Web Project, using Transifex Live」を選びます。
  5. 翻訳元のテキストを取り込みます(この辺の画面遷移やUIもちょっとわかりにく)。
    1. プロジェクトの「LIVE」ボタンを押す
      Transifex-live-1
    2. 該当のウェブページが取り込まれて、wyswygで各パラグラフや項目毎にハイライトされ、そこにマウスをホバーさせると「Collect string」や「Ignore String」「View string in strings list」などが小さいアイコンとともに表示されます。
      Transifex-live-2
      ここで「Collect string」を選択していいのですが、そうするとテキストがひとつずつしか選択できないので、「View string in strings list」をクリックしてみます。
    3. 右上のチェックボックスをクリックして全部の文字列を選択し、「Collect」をクリックします
      Transifex-live-3
  6. とりあえず上3つを訳してみます。まず右上のターゲット言語で「English」を選び、左ペインの翻訳する文字列をクリック、翻訳テキストを入力し、「Save」「Review」をクリックします。
    Transifex-live-4
  7. APIキーの取得がまたちょっとわかりにくいのですが、
    1. 右上、クエスチョンマークの左横の歯車マークをクリックすると以下のようなメニューが表示されるので、この左ペイン(メニュー)の「Install」をクリックし、scriptタグ内のapi_keyのダブルクオーテーション内の文字列をコピー
      Transifex-live-5
    2. WordPress側、プラグインの設定画面のAPIキー入力欄にペーストします
  8. 反映させる
    1. 上のAPIキーを取得したさいに開いた画面で「Take Live」をクリックし、「Publish to Production」をクリックします
      Transifex-live-6

以上です。

で、実は、7-1の「Install」でおわかりかと思いますが、他のCMSや素のHTMLでもここの

<script type="text/javascript">// <![CDATA[
window.liveSettings={api_key:"xxxxxxxxxxxxxxx"};
// ]]></script>
<script src="//cdn.transifex.com/live.js" type="text/javascript"></script>

を入れれば機能します!

では素敵な他言語ライフを!

明日はnatsumiineさんです。ヨロピク!

AMP(Accelerated Mobile Pages)用のプラグイン

先日Googleが「モバイルウェブのパフォーマンスを劇的に改善することを目的とする(aims to dramatically improve the performance of the mobile web)オープンソースイニシアチブ(イニシアチブ=構想?)」、Accelerated Mobile Pages (AMP) プロジェクトを発表しましたが、それようのWordPressのプラグインがもうできてました(まだバージョン0.1ですけど)。

With the plugin active, all content on your site will have dynamically generated AMP-compatible versions, accessible by appending /amp/ to the end your permalinks.

(このプラグインを有効化してパーマリンクの最後に /amp/ をつけてアクセスすれば、サイトのすべてのコンテンツのAPM互換バージョンを動的に生成します)

このサイトでも有効化してるので、例えば以下にアクセスするとAMP対応バージョンのウェブページが見れます。

なんだかwp.comっぽいスタイルですね。

参考:

Google、モバイルWeb高速化のオープンイニシアチブ「AMP」立ち上げ Twitterや大手メディアが参加 – ITmedia ニュース