RHEL 6 から 7 で何が変わるか

会社の自席 PC の OS を CentOS 6 から 7 にアップグレードするのに先駆けて、アップグレード方法や変更点について調べた。 本エントリでは、主に変更点についてまとめているが、アップグレード方法に関しては、付録として末尾に記載している。

続きを読む

はてなブログに API 経由で投稿する

本ブログは、 Git の til リポジトリに上げたエントリのうちまとまったものを、 はてなブログに投稿するというフローで更新している。 このあたりを自動化したいと常々考えていて、 はてなブログの API を使ったエントリの投稿を試してみる。

はてなブログの API の仕様

プロトコルは REST ではなく AtomPub。 JSON の代わりに XML でエンコードすればいいだけ、と思いきや、XML はオブジェクトに値を持たせる方法が要素と属性の2種類ある分 JSON よりも複雑なので、やや面倒に感じる。

基本的に API を叩くには認証が必要だが、これには OAuth 認証, WSSE認証, Basic認証の3つが用意されている。 テンポラリなキーを発行できる点で OAuth 認証が一番厳しくて、クレデンシャルが平文で送られる点で Basic 認証が一番ゆるい。

実行例: エントリ取得

$ curl -XGET -u minagoro0522:{API キー} https://blog.hatena.ne.jp/minagoro0522/minagoro0522.hatenablog.com/atom/entry/8599973812281828868

API の URL はドキュメントの通り。 ちなみに、ブログの「設定 > 詳細設定 > AtomPub」に「ルートエンドポイント」として、URL のプレフィクスが掲載されているので、これをコピペすると早い。

entry_id はドキュメントの説明だけだとわからない。 結論としては、記事の編集ページの URL のパスの末尾が entry_id で、例えば編集ページの URL が http://blog.hatena.ne.jp/minagoro0522/minagoro0522.hatenablog.com/edit?entry=8599973812281828868 なら 8599973812281828868 がその記事の entry_id である。

あと、出力結果は整形されていないので、xmllint するのがオススメ。

$ curl -sL ... | xmllint --format -

エントリ投稿に関して

エントリの作成と更新

作成は POST で、更新は PUT。 また、更新の場合は POST で必要なパラメータ（はてなのアカウント, ブログの ID）に加えて、エントリ ID が必要になる。 まだそのエントリが存在しない場合は作成、すでに存在する場合は更新、という風にしたかったんだけど、メソッドの違いはともかくパラメータまで違っていて厳しそう。

とりあえず試してみる

API の仕様に従って、リクエストボディを作る。

// ドキュメントのサンプルをコピーしただけ
$ vi sample.xml
<?xml version="1.0" encoding="utf-8"?>
<entry xmlns="http://www.w3.org/2005/Atom"
       xmlns:app="http://www.w3.org/2007/app">
  <title>エントリタイトル</title>
  <author><name>name</name></author>
  <content type="text/plain">
    ** エントリ本文
  </content>
  <updated>2008-01-01T00:00:00</updated>
  <category term="Scala" />
  <app:control>
    <app:draft>{yes | no}</app:draft>
  </app:control>
</entry>

エントリ作成 API を curl でコールする。

$ curl -XPOST -u minagoro0522:{API キー} -d @sample.xml https://blog.hatena.ne.jp/minagoro0522/minagoro0522.hatenablog.com/atom/entry/8599973812281828868

成功を確認。 （すでに削除済みだが）実際にエントリが作成された。

...
< HTTP/1.1 201 Created
...

参考

Dropbox Paper は Dropbox Paper であって Dropbox ではない

Dropbox Paper はチームでアイデアを出し合い、整理し、 膨らませることができるユニークなドキュメントです。 https://www.dropbox.com/paper

いざ触ってみると、自分が思っていたサービスとは全く違っていたのでメモメモ。

続きを読む

WebHook とは何か

WebHook の概要

WebHook は、あるイベントの発生をトリガーとして特定の API を呼んでもらうための仕組みで、例えば GitHub だと、イベントとしてリポジトリへの push や fork など（他にもたくさんある）が扱える。

ユーザ目線で見たときの勘所としては、スクリプトを仕込むわけでなく API の URL を仕込むところ。 なので、WebHook の使用は、どこかに API が立っている（なければ立てる）という前提を必要とすることになる。 一方、サービス提供者目線で言うと、任意のコードを自身のサーバ上で実行する必要がない。よって、セキュリティの危険を犯すことなく、任意の連携処理をユーザに提供することが出来る。

WebHook の歴史

WebHook の起源は、Glider Labs の設立者である Jeff Lindsay さんが、2006年8月にポストした ブログ記事に遡る。 この記事では、Tim OReilly さんが「Web 時代の（シェルの）パイプに当たるものはなんなのか」という発言に言及した上で、WebHook のアイデアを展開している。

WebHook の活用事例

GitHub を例にすると、master ブランチへの push があった時に、Jenkins のビルドを開始させることで、CI を回すことが出来る。 また、issue の作成やコメントがついた時に、チャットボットに報告させることで、ChatOps な環境を作れる。(※1)

ちなみに、WebHooks の使い所は SSKDs ではなく LSUDs な部分。 例えば、ビジネスロジック的な活用として、契約が入った時に自動でバッチを実行させるとかっていうのは、両方とも内部サービスなら単純にハードコードすればいいはずなので、あえて WebHook に乗っかる必要もない。

筆者の所感

API 同士をシェルのパイプのように連携させるというのは面白いアイデアだが、WebHook とシェルのパイプでは大きく使い勝手の点で違っている。 シェルのパイプはターミナルの上で | を書くだけで実現できるが、 一方 WebHook は、Web ブラウザを開き管理ページにアクセスしてポチポチするという手間が必要だ。 ただ、Web というのはそういうものだし、単純にイベントとユーザが定義した任意の処理を紐づけられるというのは、アプリケーションの可能性を広げる非常に有用な機能である。

あと、WebHook は基本的に LSUDs なサービスを念頭に置いたアイデアである。多くのエンジニアにとって、ユーザとしての利用はあっても、実装者としての利用はなさそう。

出典

Open API とは何か

調べてもいつも忘れるので、自分でまとめてみる。 API というのは（多くの IT エンジニアにとっても）身近なものなはずで、 その API の “Open” な仕様というのは興味をひくキーワードではなかろうか。

続きを読む