<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Blog-jas on Junpei Kawamoto</title>
    <link>https://www.jkawamoto.info/blog-ja/</link>
    <description>Recent content in Blog-jas on Junpei Kawamoto</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <managingEditor>junpei.kawamoto@acm.org (Junpei Kawamoto)</managingEditor>
    <webMaster>junpei.kawamoto@acm.org (Junpei Kawamoto)</webMaster>
    <copyright>&amp;copy; 2016-2017 Junpei Kawamoto</copyright>
    <lastBuildDate>Thu, 18 May 2017 00:00:00 +0000</lastBuildDate>
    
	<atom:link href="https://www.jkawamoto.info/blog-ja/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>fluentd &#43; influxdb &#43; grafana 起動用の docker-compose </title>
      <link>https://www.jkawamoto.info/blog-ja/docker-compose-for-logging-service/</link>
      <pubDate>Thu, 18 May 2017 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/docker-compose-for-logging-service/</guid>
      <description>概要 この記事 を参考に， Docker コンテナのログを fluentd で収集し influxDB と Grafana で 可視化する． 各サービスも Docker コンテナとして実行し， また，ひとまとめに logging サービスとして Systemd で管理させる．
fluentd の設定 fluentd コンテナを用意する． 収集したログを influxDB に出力するためには， fluent-plugin-influxdb プラグインが必要になるが， docker hub で公開されているイメージ には同梱されていないので自前で fluentd イメージを作成する．
次の Dockerfile は， fluent/fluentd:v0.12-onbuild を利用し fluent-plugin-influxdb をインストールする．
FROM fluent/fluentd:v0.12-onbuild RUN apk add --update --virtual .build-deps sudo build-base ruby-dev \ &amp;amp;&amp;amp; sudo gem install fluent-plugin-influxdb -v &amp;quot;~&amp;gt; 0.3&amp;quot; --no-document \ &amp;amp;&amp;amp; sudo gem sources --clear-all \ &amp;amp;&amp;amp; apk del .</description>
    </item>
    
    <item>
      <title>OAuthアクセストークンを使ってAzure Storageにアクセスする</title>
      <link>https://www.jkawamoto.info/blog-ja/access-azure-storage-with-oauth-token/</link>
      <pubDate>Fri, 12 May 2017 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/access-azure-storage-with-oauth-token/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 OAuthアクセストークンを使ってMicrosoft Azureにアクセスするでは Swagger で生成したクライアントで OAuth アクセストークンを利用する方法を紹介したが， 本記事では，Azure Storage SDK for Go を利用する方法を紹介する．
API アクセスキー Azure Storage SDK のクライアントはアクセストークンではなく，アクセスキーを必要とする． このアクセスキーは Storage API ではなく，Storage Accounts API 経由で取得する． また，Storage API は Azure Storage SDK からアクセスできるが，Storage Accounts API はアクセスできないので， 例によって Swagger を使って Azure REST API Specifications からバインディングを用意する必要がある．
$ swagger generate client \ -f https://raw.githubusercontent.com/Azure/azure-rest-api-specs/master/arm-storage/2016-12-01/swagger/storage.json \ -t storage  Storage Accounts API 生成されたソースコードを用いて，先ずは Storage Accounts API のクライアントを作成する NewStorageAccountsClient 関数を定義する．</description>
    </item>
    
    <item>
      <title>配列が null だと Azure サーバがエラーを返す問題</title>
      <link>https://www.jkawamoto.info/blog-ja/azure-server-returns-error-when-array-is-null/</link>
      <pubDate>Thu, 11 May 2017 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/azure-server-returns-error-when-array-is-null/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 Go から Microsoft Azure を利用するの方法でソースコードを生成すると， スライス型の構造体メンバに omitempty が付かず API 呼び出しがエラーになる場合があった． その原因ととりあえずの対策をまとめる．
go-swagger が生成する構造体 例えば，
$ swagger generate client \ -f https://raw.githubusercontent.com/Azure/azure-rest-api-specs/master/batch/2016-07-01.3.1/swagger/BatchService.json \ -t batch  上記のコマンドで Batch API のバインディングを作った場合， ジョブプールの追加に必要なパラメータを表す構造体として，下記のような PoolAddParameter が生成される．
type PoolAddParameter struct { // The list of application packages to be installed on each compute node in the pool. // // This property is currently not supported on pools created using // the virtualMachineConfiguration (IaaS) property.</description>
    </item>
    
    <item>
      <title>OAuthアクセストークンを使ってMicrosoft Azureにアクセスする</title>
      <link>https://www.jkawamoto.info/blog-ja/access-azure-using-oauth-tokens/</link>
      <pubDate>Wed, 10 May 2017 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/access-azure-using-oauth-tokens/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 
Microsoft Azureを利用するデスクトップアプリのデバイス認証にて取得したアクセストークンを， Go から Microsoft Azure を利用するにて紹介した Swagger で生成したクライアントから利用する方法． API によって微妙に関数の形が変わるため，生成されたソースコードを見ながらどこでトークンを渡せるのか調べる必要があるが，おおよそ次の二種類に分かれると思われる．
メソッドが認証情報を受け取る場合 最も簡単なのは，認証情報を受け取るタイプのメソッドが生成された場合である． 例えば，次のようにして生成できる 2016-09-01 版の Resource API
$ swagger generate client \ -f https://raw.githubusercontent.com/Azure/azure-rest-api-specs/master/arm-resources/resources/2016-09-01/swagger/resources.json \ -t resource  では，リソースグループの作成または更新を行う関数が次のように定義されている．
func (a *Client) ResourceGroupsCreateOrUpdate( params *ResourceGroupsCreateOrUpdateParams, authInfo runtime.ClientAuthInfoWriter ) (*ResourceGroupsCreateOrUpdateOK, *ResourceGroupsCreateOrUpdateCreated, error)  この runtime.ClientAuthInfoWriter型 は，go-openapi/runtime ライブラリにて
import &amp;quot;github.com/go-openapi/strfmt&amp;quot; type ClientAuthInfoWriter interface { AuthenticateRequest(ClientRequest, strfmt.Registry) error }  と定義されているのだが，go-openapi/runtime/client に OAuth アクセストークン (BearerToken) から ClientAuthInfoWriter を生成する BearerToken 関数が用意されている．</description>
    </item>
    
    <item>
      <title>Microsoft Azureを利用するデスクトップアプリのデバイス認証</title>
      <link>https://www.jkawamoto.info/blog-ja/device-authorization-for-azure/</link>
      <pubDate>Tue, 09 May 2017 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/device-authorization-for-azure/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 
Go から Microsoft Azure を利用する場合，アクセストークン使用する． このアクセストークンの取得には複数の方法が用意されているが， CLI コマンドでも利用されているデバイスコードを用いた認証方法についてまとめる．
アプリケーションの登録  認証プロセスで必要となるクライアント ID を取得するために， Azure ポータルにてアプリケーションの登録を行う．

アプリの登録は，ポータルのセキュリティ + ID カテゴリにある「アプリの登録」から行える．

今回作成するのは，デスクトップアプリケーションなので，アプリの種類としてネイティブを選ぶ． リダイレクト URL は文字列として有効な URL であれば適当で良いので， 例えば，http://localhost:18230 などとしておく．
デバイスコードの取得 デバイスコードの取得には， https://login.microsoftonline.com/common/oauth2/devicecode にクライアント ID とアクセスを要求するリソースをクエリとして追加し問い合わせることで取得できる． レスポンスは次のような構造を持つ JSON 形式で取得できる．
type DeviceCode struct { UserCode string `json:&amp;quot;user_code&amp;quot;` DeviceCode string `json:&amp;quot;device_code&amp;quot;` VerificationURL string `json:&amp;quot;verification_url&amp;quot;` ExpiresIn string `json:&amp;quot;expires_in&amp;quot;` Interval string `json:&amp;quot;interval&amp;quot;` Message string `json:&amp;quot;message&amp;quot;` }  次の関数はデバイスコードを取得し上記の構造体として返す．</description>
    </item>
    
    <item>
      <title>Go から Microsoft Azure を利用する</title>
      <link>https://www.jkawamoto.info/blog-ja/access-azure-from-go/</link>
      <pubDate>Mon, 08 May 2017 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/access-azure-from-go/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 
Microsoft Azure をプログラムから利用する場合 .Net が一般的な選択肢だと思われるが， あえて Go から利用する方法について調べた．
Microsoft Azure SDK for Go &amp;ldquo;go azure&amp;rdquo; で検索すると見つかる公式の SDK が Microsoft Azure SDK for Go と Azure Storage SDK for Go である．後者は前者のうち storage に関する API だけを切り離したもので，今後は別リポジトリとして開発されるそうだ．
公式 SDK のため，基本的にはこれらを使えれば良いのだが，まだ preview 版であり未実装の API が多い．個人的には，Azure Storage SDK for Go は必要な機能は揃っていたが，それ以外は別の方法を探した方が良いと感じた．
余談だが，Microsoft Azure SDK for Go は一つの操作 Foo に対して Foo, FooPreparer, FooResponder, FooSender と４つの関数がセットで定義されているのだが，後ろの３つはパブリックにする必要はあるのだろうか？補完やドキュメント検索がごちゃごちゃするのだが・・・．
Azure REST API Specifications Azure REST API Specifications は REST API 定義書を管理している公式のリポジトリである． こちらの方は，ほぼ全ての API を網羅していると思われる． REST API 定義書さえあれば，Swagger を使って Go 用のパッケージを自動生成できる．</description>
    </item>
    
    <item>
      <title>Google Cloud for Goで OAuth アクセストークンを使う</title>
      <link>https://www.jkawamoto.info/blog-ja/use-access-token-from-google-cloud-go/</link>
      <pubDate>Fri, 05 May 2017 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/use-access-token-from-google-cloud-go/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 GoogleAPIを利用するデスクトップアプリのOAuth2.0認証では，アクセストークンの利用例として Google APIs Client Library for Go を使って利用可能な Zone リストを取得する方法を紹介した．
Go から Google Cloud Platform にアクセスする方法には，Google Cloud for Go を利用する方法もある． Stackdriver Logging からログを取得するや Stackdriver Logging からログを取得する(その２) で用いている logadmin，logging パッケージはこの Google Cloud for Go ライブラリに含まれている．
本記事では，取得した OAuth 2.0 アクセストークンを，Google Cloud for Go のクライアントから利用する方法を紹介する．
Google Cloud for Go のクライアント Google APIs Client Library for Go では，アクセストークンが付与された http.Client を渡すことで，そのトークンを使用していた． 一方 Google Cloud for Go のクライアントでは，TokenSource を接続オプションとして NewClient に渡すことで使用する．</description>
    </item>
    
    <item>
      <title>GoogleAPIを利用するデスクトップアプリのOAuth2.0認証</title>
      <link>https://www.jkawamoto.info/blog-ja/oauth2-for-google-api/</link>
      <pubDate>Thu, 04 May 2017 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/oauth2-for-google-api/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 Google の API を利用するデスクトップアプリが OAuth 2.0 プロトコルを走らせる方法． Go 標準のoauth2パッケージはほとんどの処理を実行してくれるが， 認証コードを受け取るために一時的な ローカルWebサーバを立てることと， Code verifier の計算は自前で行う．
アプリの登録 まず初めに，コンソールの認証情報ページでアプリのクライアント ID とクライアントシークレットを取得する．
コンソールの API Manager から認証情報を開き，認証情報を作成，OAuth クライアント ID を選択する．

デスクトップアプケーションから使用するため，その他を選び作成する．

クライアント ID とクライアントシークレットが表示されるので控えておく． なお，忘れてしまっても認証情報ページで再確認できる．

Code verifier の計算 サーバから送られてくる認証コードを横取りされる中間者攻撃を防ぐため， Code verifier というものを利用できる． 具体的には，認証コードの要求時にランダム文字列(Code verifier)のハッシュ値を送っておき， アクセストークンを要求する時にはランダム文字列を送る． 認証コードが横取りされてもランダム文字列の方がバレなければ アクセストークンを不正に取得されることを防げる．
Code verifier は，次の文字からなる長さ43から128の文字列と決められている．
 [A-Z] / [a-z] / [0-9] / - / . / _ / ~  まずは，Code verifier の生成関数を作る．</description>
    </item>
    
    <item>
      <title>Stackdriver Logging からログを取得する(その２)</title>
      <link>https://www.jkawamoto.info/blog-ja/get-log-entries-from-stackdriver-logging-2/</link>
      <pubDate>Tue, 02 May 2017 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/get-log-entries-from-stackdriver-logging-2/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 Google Cloud Platform からログデータを取得する場合， Stackdriver Logging からログを取得するに記した logadminパッケージを利用する方法に加えて， APIバージョン2のlogging パッケージを使うこともできる． （バージョン１の方はログを書き出せるが読み出せなかったはず）
ざっと見た限り，logadminパッケージに比べて取得できるログの種類が多いように見えたので， その使用方法についてまとめる．
loggingパッケージ(Ver.2) logadmin パッケージのドキュメントにはベータ版との記載されているが， バージョン２のloggingパッケージのドキュメントには実験的(EXPERIMENTAL)と書かれている． 将来大幅な変更があるかもしれないので，その点は注意．
loggingパッケージのクライアントを使って，変数 filter にマッチするログデータを取得する場合， 次のようなコードになる．
import ( &amp;quot;context&amp;quot; &amp;quot;cloud.google.com/go/logging/apiv2&amp;quot; &amp;quot;google.golang.org/api/iterator&amp;quot; loggingpb &amp;quot;google.golang.org/genproto/googleapis/logging/v2&amp;quot; ) func GetLogEntries(ctx context.Context, filter string) error{ client, err := logging.NewClient(ctx) if err != nil { return } defer client.Close() iter := client.ListLogEntries(ctx, &amp;amp;loggingpb.ListLogEntriesRequest{ ResourceNames: []string{ fmt.Sprintf(&amp;quot;projects/%v&amp;quot;, &amp;quot;your-project-id&amp;quot;), }, Filter: filter, }) for { e, err := iter.</description>
    </item>
    
    <item>
      <title>ComputeEngineでCoreOSを選ぶとスタートアップスクリプトからdockerが見えない</title>
      <link>https://www.jkawamoto.info/blog-ja/startup-script-cannot-find-docker/</link>
      <pubDate>Sun, 23 Apr 2017 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/startup-script-cannot-find-docker/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 Google Compute Engine で CoreOS イメージ（coreos-stable-1298-7-0-v20170401） を使ってインスタンスを作成すると，スタートアップスクリプトから docker コマンドが使えないような気がする．
Apr 21 12:20:59 xxx.internal rkt[1110]: + /usr/bin/google_metadata_script_runner --script-type startup Apr 21 12:20:59 xxx.internal startup-script[1361]: INFO Starting startup scripts. Apr 21 12:20:59 xxx.internal startup-script[1361]: INFO Found startup-script in metadata. Apr 21 12:20:59 xxx.internal startup-script[1361]: INFO startup-script: /tmp/startup-qconLt/tmpI9QQlX: line 29: /usr/bin/docker: No such file or directory Apr 21 12:20:59 xxx.internal startup-script[1361]: INFO startup-script: /tmp/startup-qconLt/tmpI9QQlX: line 33: /usr/bin/docker: No such file or directory Apr 21 12:20:59 xxx.</description>
    </item>
    
    <item>
      <title>リストまたは値のいずれかを取るYAMLの読み込み</title>
      <link>https://www.jkawamoto.info/blog-ja/parse-ambiguous-yaml-in-go/</link>
      <pubDate>Wed, 01 Feb 2017 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/parse-ambiguous-yaml-in-go/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 通常はリストを取るが，要素が一つしかない場合はリストにせず値を直接書いて良い， というフォーマットの YAML 文書を読み込む方法．
例 次の文書のように author はリストを受け取るのだが，
title: some book author: - Alice - Bob  著者が一人しかいない場合は，
title: some book author: - Alice  と
title: some book author:　Alice  のどちらでも OK というような場合を考える． この時，次のような構造体を用意して，
type Book struct { Title string Author []string }  yaml.Unmarshal で次のように読み込もうとすると，author がリストになっていない場合にエラーになる．
t := &amp;amp;Book{} // data は bool.yml のバイト列 err := yaml.Unmarshal([]byte(data), t) if err !</description>
    </item>
    
    <item>
      <title>PyPIに登録するパッケージの説明文を半自動生成する</title>
      <link>https://www.jkawamoto.info/blog-ja/generate-readme-for-pypi/</link>
      <pubDate>Fri, 27 Jan 2017 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/generate-readme-for-pypi/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 PyPI にパッケージを登録するとき，特に指定しなければ説明文として README.md が使用される． しかし， Markdown 形式ではレンダリングされないため下記のように醜い文章が表示されることになる．

この説明文は，reStructuredText 形式ならばレンダリングされる． そこで，README.md から README.rst を生成し，説明文として設定する方法を備忘録として記す．
Markdown から reStructuredText への変換 GitHub 等でコードベースを管理しているならば，README.md は用意されていると考えられるので， この Markdown テキストを reStructuredText 形式へ変換する．
変換には，Pandoc を使う．
$ pandoc --from markdown --to rst README.md -o README.rst  なお，Pandoc は brew でインストールできる．
$ brew install pandoc  パッケージ情報への登録 README.md と README.rst が両方ともパッケージに含まれている場合， README.md の方が優先されてしまうので， setup.py で README.rst を説明文として使用するように設定する．
具体的には，setup 関数の long_description キーワード引数に README.</description>
    </item>
    
    <item>
      <title>PyPIに登録するパッケージバージョンをGitから取得する</title>
      <link>https://www.jkawamoto.info/blog-ja/determine-package-version-from-git-tags/</link>
      <pubDate>Fri, 27 Jan 2017 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/determine-package-version-from-git-tags/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 PyPI にパッケージを登録する場合，setup.py で呼び出す setup 関数に version 引数を渡す必要がある． このバージョン情報を今までは手作業で編集していたのだが，Gitのタグから引っ張ってこれたので備忘録として記しておく．
setuptools_scm setuptools_scm はバージョン管理システムから適当に情報を引っ張ってきて，setup.py を設定してくれるライブラリである． これを使えば，タグ情報を元にバージョン番号を算出し設定できる． また，トラッキングされているパッケージデータを自動的にパッケージへ追加する機能もある．
setuptools_scm を使用してバージョン番号を設定する場合， setup.py の setup 関数に次のようなパラメータを渡す．
from setuptools import setup setup( use_scm_version=True, setup_requires=[ &amp;quot;setuptools_scm&amp;quot; ], ... # 他の項目は省略 )  これで，python setup.py sdistとする時に適切にバージョン番号が計算される． バージョン番号の計算方法は次のルールに従っている．
 最新コミットにバージョンタグが付いており，更新されたファイルがない場合: そのバージョンタグ 最新コミットにバージョンタグが付いており，更新されたファイルがある場合: バージョンタグ＋現在の日付 バージョンタグ付きコミット以降にコミットがあり，更新されたファイルがない場合: 次のバージョン.dev(何コミット離れているか)+n(ハッシュ) バージョンタグ付きコミット以降にコミットがあり，更新されたファイルがある場合: 次のバージョン.dev(何コミット離れているか)+n(ハッシュ).日付  より詳しい情報はマニュアルを参照のこと．
パッケージデータの追加 トラッキングされているパッケージデータを自動で追加する場合， setup 関数に include_package_data=True を追加する． つまり，
from setuptools import setup setup( use_scm_version=True, include_package_data=True, setup_requires=[ &amp;quot;setuptools_scm&amp;quot; ], .</description>
    </item>
    
    <item>
      <title>pip install中に他所からデータファイルを取得する</title>
      <link>https://www.jkawamoto.info/blog-ja/download-data-files-during-pip-installation/</link>
      <pubDate>Wed, 25 Jan 2017 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/download-data-files-during-pip-installation/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 そんなことをしても良いのか分からないが，パッケージに必要なデータを PyPI サーバ以外から取得してインストールしたい． setup.pyに記載できるデータファイル関連の引数，package_data と data_files はどちらもソースコードと共に配布される ファイルしか対応していないと思われる． そこで，pip install中に呼び出される install_data コマンドをフックして，必要なファイルを別途ダウンロードするようにした．
コマンドのフック コマンドのフックというか置き換えは，setuptools.setup関数にキーワード引数 cmdclass として， 置き換えるコマンド名をキーに，実装を値にした辞書を渡すことで行える．(参考: 新しいコマンドの統合)
今回置き換える install_data コマンドの本来のソースは，ここにあるので， 参考にしながらカスタムの install_data コマンドを作成した．
import distutils.command.install_data from os import path import site import sys import urllib class CustomInstallData(distutils.command.install_data.install_data): def run(self): # self.data_files に setup 関数の data_files 引数に渡した値が入る． # これは，(データファイルの保存先，データファイルパスのリスト) タプルのリスト担っているので，個別に処理する． for f in self.data_files: if not isinstance(f, tuple): continue for i, u in enumerate(f[1]): # データファイルのパスが URL でなければ何もしない． if not u.</description>
    </item>
    
    <item>
      <title>レビューグラフ解析アルゴリズム評価用のTripAdvisorデータセット</title>
      <link>https://www.jkawamoto.info/blog-ja/rgmining-tripadvisor/</link>
      <pubDate>Wed, 25 Jan 2017 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/rgmining-tripadvisor/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 
スパムレビュア発見アルゴリズムの評価用データセットに加えて， イリノイ大学で公開されている TripAdvisor データセットを読み込むパッケージを作成しました．
インストール パッケージは PyPI に登録してあるので，次のコマンドでインストールできます．
$ pip install --upgrade rgmining-tripadvisor-dataset  なお，このインストール中に元データ配布先からファイルをダウンロードするので， ある程度の時間を要します．（参考: pip install中に他所からデータファイルを取得する）
グラフデータの読み込み rgmining-tripadvisor-datasetには tripadvosirモジュールが含まれており， load関数をエクスポートしています． この関数はレビューグラフオブジェクトを受け取り， TripAdvisor データセットのレビューデータを追加します．
このグラフオブジェクトは， グラフインターフェイス を実装し次のメソッドを持っている必要があります．
 new_reviewer(name): name という名前を持つレビュアーオブジェクトを作成して返す． new_product(name): name という名前を持つ商品オブジェクトを作成して返す． add_review(reviewer, product, rating, date): date に投稿された reviewer による product へのスコアが rating であるレビューを追加する．なお rating は 0 以上 1 以下に正規化されているものとする．  先日紹介した，Fraud Eagle, FRAUDAR は共にこのグラフインターフェイスを実装しているので， TripAdvisor データセットを読み込むことができます．
Fraud Eagle で解析する場合(事前に pip install --upgrade rgmining-fraud-eagle が必要)，</description>
    </item>
    
    <item>
      <title>カモフラージュするスパムレビュアの発見アルゴリズム</title>
      <link>https://www.jkawamoto.info/blog-ja/rgmining-fraudar/</link>
      <pubDate>Tue, 17 Jan 2017 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/rgmining-fraudar/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 
結託したスパムレビュアを発見するアルゴリズムに引き続き， オンラインショッピングやレストランレビューサイトにおいてスパムレビュアーを発見するために， 通常のレビュアーにカモフラージュするようなスパムレビュアを発見するアルゴリズム FRAUDAR を用意した．
FRAUDAR は 2016年の ACM SIGKDD International Conference on Knowledge Discovery and Data Mining (KDD 2016) でベストペーパー賞を受賞したアルゴリズムで， 著者らによって実装が公開されている．
今回は， スパムレビュア発見アルゴリズムの評価用データセットなどをより簡単に解析できるように 結託したスパムレビュアを発見するアルゴリズムと共通の インターフェイスを作成した．
使い方 今回作成した，FRAUDARのラッパー rgmining-fraudar は PyPI に登録してあるので，pip コマンドにてインストールできる．
$ pip install --upgrade rgmining-fraudar  fraudar というパッケージが追加され，その中の fraudar.ReviewGraph がこのアルゴリズムを実装するグラフクラスである． ReviewGraph クラスのコンストラクタは，オプションで何種類のカモフラージュパターンを考えるかというパラメータと，内部で使うサブアルゴリズムを受け取るが，前者のみデータセットに合わせて与えれば良いと思う（両方デフォルトでも問題ない）．
import fraudar # 例えば 10パタンのカモフラージュを考える場合． n = 10 graph = fraudar.ReviewGraph(n)  そして，グラフにレビュア，商品，そしてレビューを追加する． 結託したスパムレビュアを発見するアルゴリズムの例と同じ方法で追加できる．
reviewers = [graph.</description>
    </item>
    
    <item>
      <title>Travis でのテストを事前にローカルで試す</title>
      <link>https://www.jkawamoto.info/blog-ja/test-remote-ci-scripts-locally/</link>
      <pubDate>Sat, 07 Jan 2017 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/test-remote-ci-scripts-locally/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 

GitHub などでホストしているプロジェクトのテストに，Travis CI などのクラウド CI サービスを利用するケースは多いだろう．
基本的に，ローカルの開発環境でテストに通ったことを確認してから，コミット，プッシュを行うはずなので，Travis 上でもテストはパスするはずである．しかし，Travis の設定ファイルである.travis.ymlのミスや，依存ライブラリの追加忘れなどのうっかりで時々テストが失敗する．特に依存ライブラリの場合，開発環境ではたまたまインストールされていると，ローカルでのテストはパスしてしまうため，見落とすことがある．
テストが失敗すると，ローカル環境で修正の後，再プッシュとなりリモートブランチのコミット履歴が汚れて行くので，ミスはできるだけ避けるべきである（特に，他人のリポジトリでやらかすと気まずい）．そこで，Python または Go 言語のプロジェクト用に，Docker を使ってローカルにまっさらな環境を用意し，.travis.ymlに記載された通りにテストを実行するツール，Loci を作成した．
インストール まず，Docker が必要になるので，あらかじめインストールしておく（Docker の導入方法については割愛する）．
Loci のインストールは，Go がインストールされている環境ならば，
$ go get github.com/jkawamoto/loci  Homebrew がインストールされている環境ならば，
$ brew tap jkawamoto/loci $ brew install loci  にて行える．それ以外の場合は，GitHubにコンパイル済みのバイナリがあるので，ダウンロードしてパスの通ったところへ置けば良い．
使い方 カレントディレクトリに，.travis.yml がある場合，loci コマンドを実行するだけで良い．別ファイルをテストする場合は，loci &amp;lt;filepath&amp;gt;とファイルパスを渡す．
Loci はカレントディレクトリ以下に含まれるファイルを持ち，.travis.yml に記載されたパッケージをインストールしたコンテナイメージを作成する．元になるイメージは ubuntu:latest である．初回実行時は，パッケージのインストールなどである程度の時間を要するが，2回目以降は，依存パッケージに変更がなければ，過去のコンテナイメージを適宜再利用する（Dockerの機能）．
もし自前で， APT キャッシュサーバや PyPI キャッシュサーバを用意している場合，--apt-proxy や --pypi-proxy フラッグを使うことで，それらを利用するようになる．（参考: QNAP に Apt キャッシュサーバを建てる, QNAP に Pypi キャッシュサーバを建てる）</description>
    </item>
    
    <item>
      <title>Stackdriver Logging からログを取得する</title>
      <link>https://www.jkawamoto.info/blog-ja/get-logs-from-stackdriver-logging/</link>
      <pubDate>Fri, 30 Dec 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/get-logs-from-stackdriver-logging/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 
Google Cloud Platform からログデータを取得する． logadmin パッケージが提供する，Stackdriver クライアントは使いやすいのだが， 手に入る各ログエントリーは logging.Entry型で，ペイロードの取得が手間である． 本稿では，ログエントリー及びそのペイロード取得方法をまとめる．
logadmin パッケージ logadmin は，比較的新しいパッケージで， ログの取得に関わる操作を提供している． 変数filterに入っているクエリにマッチするログデータのみを取得するならば， 下記の通りでよい．
import ( &amp;quot;cloud.google.com/go/logging/logadmin&amp;quot; &amp;quot;golang.org/x/net/context&amp;quot; &amp;quot;google.golang.org/api/iterator&amp;quot; ) func GetLogEntries(filter string) error{ ctx := context.Background() client, err := logadmin.NewClient(ctx, &amp;quot;your-project-id&amp;quot;) if err != nil { return err } defer client.Close() iter := client.Entries(ctx, logadmin.Filter(filter)) for { e, err := iter.Next() if err == iterator.Done { return nil } else if err !</description>
    </item>
    
    <item>
      <title>GitHub のリポジトリを requirements.txt に含める</title>
      <link>https://www.jkawamoto.info/blog-ja/include-github-repositories-to-requirements-txt/</link>
      <pubDate>Wed, 19 Oct 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/include-github-repositories-to-requirements-txt/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 
PyPI には登録されていないが，GitHub では公開されているライブラリを依存関係に含める方法． また，setup.py から requirements.txt を参照している場合の対応方法について忘備録としてまとめる．
requirements.txt GitHub リポジトリの URL が https://github.com/rgmining/common の場合， requirements.txt には，
-e git+https://github.com/rgmining/common.git#egg=rgmining_common-0.9.0  のように書く．#egg= 以降は &amp;lt;パッケージ名&amp;gt;-&amp;lt;バージョン&amp;gt; という書式にするようだ． また，pip-tools を使って requirements.txt を生成している場合， requirements.in には上記と同じ文字列を記入する．
setup.py 今まで，setup.py では下記のようにrequirements.txtの内容をinstall_requiresに渡していた．
from setuptools import setup, find_packages def load_requires_from_file(filepath): with open(filepath) as fp: return [pkg_name.strip() for pkg_name in fp.readlines()] setup( # その他の項目は省略 install_requires=load_requires_from_file(&amp;quot;requirements.txt&amp;quot;) )  requirements.txtにURLが含まれている場合は，もう少し改良してパッケージ名だけをリストアップする．
def take_package_name(name): if name.startswith(&amp;quot;-e&amp;quot;): return name[name.</description>
    </item>
    
    <item>
      <title>スパムレビュア発見アルゴリズムの評価用データセット</title>
      <link>https://www.jkawamoto.info/blog-ja/rgmining-synthetic/</link>
      <pubDate>Wed, 12 Oct 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/rgmining-synthetic/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 
スパムレビュア発見アルゴリズムの評価用に， 論文 A Bipartite Graph Model and Mutually Reinforcing Analysis for Review Sites にて作成した 人工データを公開しました．本記事では使い方をまとめます． また，Google Cloud Platform を使った並列評価についてもまとめます．
インストール パッケージは PyPI に登録してあるので，pip コマンドでインストールできます．
$ pip install --upgrade rgmining-synthetic-dataset  人工グラフデータの読み込み rgmining-synthetic-datasetには，syntheticパッケージが含まれており， synthetic.load関数とsynthetic.ANOMALOUS_REVIEWER_SIZE定数をエクスポートします． synthetic.load関数は人工レビューグラフデータの読み込みを行い， synthetic.ANOMALOUS_REVIEWER_SIZE定数はこのデータセットに含まれている 特異なスパムレビュアの人数（５７）を表しています． 特異なスパムレビュアは，その名前に anomaly が含まれています． よって，このデータセットを使った評価では， ５７人のスパムレビュアをどれだけの精度・再現率で発見できるのか？を調べます．
なお人工データがどのようにして作られたのか，については割愛します． 興味のある方は元論文を参照してください．（いつか別記事でまとめるかも知れません）
synthetic.load関数は，引数としてグラフオブジェクトを受け取ります． このグラフオブジェクトは，
 new_reviewer(name): nameという名前を持つレビュアーオブジェクトを作成して返す． new_product(name): name という名前を持つ商品オブジェクトを作成して返す． add_review(reviewer, product, rating): reviewerによるproductへのスコアがratingであるレビューを追加する．なお．ratingは 0 以上 1 以下に正規化されているものとする．  という三つのメソッドを持っている必要があります．</description>
    </item>
    
    <item>
      <title>結託したスパムレビュアを発見するアルゴリズム</title>
      <link>https://www.jkawamoto.info/blog-ja/rgmining-fraud-eagle/</link>
      <pubDate>Wed, 05 Oct 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/rgmining-fraud-eagle/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 はじめに 
オンラインショッピングやレストランレビューサイトにおいて， 結託してレビュー結果が不当に高くまたは低くなるようにダミーレビューを投稿する スパムレビュアーを発見したい．
今回は，2013年に AAAI Conference on Weblogs and Social Media という国際会議で発表された，Fraud Eagle アルゴリズムを実装した．
レビューデータ Fraud Eagle では下の図のようなレビューグラフを考える．

つまり，レビューを投稿した人（レビュア）とレビューの投稿先（商品）をそれぞれ頂点とし， レビュー関係を枝で表す．レビュー自体は文章でも星何個でも良いが， そのレビューがポジティブなのかネガティブなのか判断できる必要がある． 今回は，レビューは 0 から 1 までの間の数値を取ることにし，0.5 以上ならばポジティブ， そうでなければネガティブと判断することにした．
使い方 今回作成した rgmining-fraud-eagle は PyPI からインストールできる．
pip install --upgrade rgmining-fraud-eagle  fraud_eagle というパッケージがインストールされるので， その中からReviewGraph クラスのインスタンスを作成する． なお，Fraud Eagle は 0 より大きく 0.5 未満ののパラメータを一つとる． パラメータはデータセットによって最適値が変わるが，今回は中央 0.25 を設定してみる．
import fraud_eagle as feagle graph = feagle.ReviewGraph(0.25)  次に，グラフにレビュア，商品，そしてレビューを追加する． 上記図の通りのグラフを作成する場合，</description>
    </item>
    
    <item>
      <title>Wercker で Sphinx ドキュメントをコンパイルする</title>
      <link>https://www.jkawamoto.info/blog-ja/compile-sphinx-documents-in-wercker/</link>
      <pubDate>Sat, 03 Sep 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/compile-sphinx-documents-in-wercker/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 
Wercker で Sphinx ドキュメントをコンパイルするための設定をスクリーンショット付きでまとめる．
手順 Wercker の Create → Application から対象のリポジトリをインポートする． インポート後の画面は下記のようになっているので，Workflow タブへ移動する．

その中から build パイプラインの設定を開く．

build パイプラインの設定画面をスクロールし，Permission level 項目を表示させる．

そして，Permission level は，他人がパイプラインを実行することを防ぎ， また不用意にログを公開しないようにexecute pipeline を選ぶ． また，Ignore branches に gh-pagesを追加しておく． これを忘れると，ドキュメントを gh-pages に push 後，またコンパイルが始まってしまう．

次に，ワークフロータブへ戻り，新しいパイプラインを作成する．

新しいパイプラインに deploy という名前をつけて，フックタイプをデフォルトにする．デフォルトは，前のパイプラインに繋げて使うための設定である．

コンパイルしたドキュメントを GitHub へアップロードするために， このパイプラインへ GitHub へのアクセストークンを環境変数として登録する． 環境変数名は GIT_TOKEN とし，protected オプションにチェックを入れる．

GitHub のトークンは https://github.com/settings/tokens から取得できる． 公開リポジトリの場合は，public_repo にのみチェックを入れれば良い． 非公開リポジトリの場合は，repo にチェックを入れる必要があると思われる（試していない）．</description>
    </item>
    
    <item>
      <title>GitHub Pages にドキュメントを配置する  Wercker step</title>
      <link>https://www.jkawamoto.info/blog-ja/wercker-step-for-pushing-documents/</link>
      <pubDate>Thu, 18 Aug 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/wercker-step-for-pushing-documents/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 Hugo のマニュアルによれば， GitHub Pages にドキュメントをプッシュするWercker step には， lukevivier/gh-pages がある．しかし，この step は過去のコミットを上書きしてしまうため， コミットログを残す別の step jkawamoto/ghp-import を作った．
使い方 jkawamoto/ghp-import step の実行には，pip が必要です． wercker.yml の steps に
- install-packages: packages: python-pip  を追加するか，box に jkawamoto/ghp-box を使ってください．
jkawamoto/ghp-import step には，次のオプションがあります．
 token: Github のアクセストークン． basedie: ドキュメントのルートパス． msg: 省略化のコミットメッセージ. branch: ブランチ名．デフォルトは gh-pages.  公開リポジトリには public_repo 権限付きのアクセストークン必要です．プライベートリポジトリの場合は，repo 権限が必要になると思います．また，wercker.yml に直接値を書くのではなく環境変数経由で渡してください．環境変数は下記の画面から登録できます．

例 roadie で実際に使用している例は次の通り．
box: jkawamoto/ghp-box build: steps: - script: name: Prepare submodules code: |- git submodule update --init - arjen/hugo-build: version: &amp;quot;0.</description>
    </item>
    
    <item>
      <title>Sphinxドキュメントをコンパイルする Wercker step</title>
      <link>https://www.jkawamoto.info/blog-ja/wercker-step-for-compiling-sphinx-documents/</link>
      <pubDate>Thu, 18 Aug 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/wercker-step-for-compiling-sphinx-documents/</guid>
      <description>  本稿は Qiita 投稿記事 のバックアップです．
 概要 ちょろっと調べた限り良さそうなものが無かったので， SphinxドキュメントをコンパイルするWercker step jkawamoto/sphinxを作った．
使い方 jkawamoto/sphinx step の実行には，pip が必要です．wercker.yml の steps に
- install-packages: packages: python-pip  を追加するか，box に jkawamoto/ghp-box を使ってください．
jkawamoto/sphinx step には，次のオプションがあります．
 target: make コマンドのターゲット (デフォルトは html)． basedir: Makefile があるディレクトリのパス． packages: 空白区切の Sphinx の実行に必要な PyPi パッケージリスト．使用するテーマなどを渡す． options: make コマンドに渡すオプション引数．  なお，リポジトリに requirements.txt が含まれている場合， 自動で pip install -r requirements.txt するので， 依存ライブラリを packages に含める必要はありません．
例 dsargparse で実際に使用している例は次の通り．
box: jkawamoto/ghp-box build: steps: - jkawamoto/sphinx: basedir: docs packages: sphinx_rtd_theme deploy: steps: - jkawamoto/ghp-import: token: $GIT_TOKEN basedir: docs/build/html  </description>
    </item>
    
    <item>
      <title>講義ビデオ: 形式言語とオートマトン</title>
      <link>https://www.jkawamoto.info/blog-ja/2016-08-17/</link>
      <pubDate>Wed, 17 Aug 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/2016-08-17/</guid>
      <description> 教科書    講義ページ  講義ビデオ           </description>
    </item>
    
    <item>
      <title>Wercker で GitHub のトークンが漏れてないか調べよう</title>
      <link>https://www.jkawamoto.info/blog-ja/check-github-token-leakage-in-wercker/</link>
      <pubDate>Tue, 16 Aug 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/check-github-token-leakage-in-wercker/</guid>
      <description>  本稿は Qiita 投稿記事 のバックアップです．
 概要 Wercker で成果物を GitHub に保存させる場合， Personal access token を取得して，環境変数に登録すると思う． この時，Protected にチェックをつけると，秘匿されるように見えるのだが， 使用している step によっては漏れていることもあるので気をつけよう．
漏れている例 Wercker でドキュメントをコンパイルして GitHub Pages にアップロードする時に使われる step の一つ， lvivier/step-gh-pages を使った例．
(2016年9月2日追記) PR が取り込まれたので，最新版の lvivier/step-gh-pages はトークンを公開していません．

git の push メッセージにトークンが含まれている．
環境変数を Protected にすると， その環境変数を直接表示するような処理はログから秘匿されると思われるが， 別のプログラムがうっかり出力している場合には対応していないと思われる．
対策？ ビルドログを調べてトークンらしき文字列が出力されていたら，
 別の step の利用を検討するか， private プロジェクトに変更するか， 少なくとも実行権限を public 以外にしてログを公開しないようにする  </description>
    </item>
    
    <item>
      <title>SphinxドキュメントからGitHubへリンクする</title>
      <link>https://www.jkawamoto.info/blog-ja/link-github-from-sphinx-doc/</link>
      <pubDate>Sun, 14 Aug 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/link-github-from-sphinx-doc/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 Sphinx テンプレートの一つ sphinx_rtd_theme では， メタデータ :github_url: に URL を渡すことで，Edit on GitHub のリンクを生成してくれる．
ではそのメタデータはどこで定義するのか？という話．
メタデータの定義 Sphinx におけるメタデータは二種類ある．一つは今回必要なテンプレートの処理に使うメタデータであり， もう一つは HTML の meta タグを出力するためのものである．
前者は，.rst ファイルの先頭付近（A field list near the top of a file）に置く必要がある． 曖昧な表現だが，要するに他のマークアップより前に書いておけば良い．
:github_url: https://github.com/jkawamoto/roadie-gcp .. ここから本文を始める  などとすれば良い．
ちなみに，後者の方は .. meta:: で始まるセクションに記述する．
.. meta:: :viewport: width=device-width  メタデータの一括登録 上記の通り，各 .rst ファイルの先頭に :github_url:メタデータを追加すれば， 生成されたドキュメントには GitHub へのリンクが付く． しかし，一々記述するのは手間なので，rst_prolog オプションを使って一括登録する．
conf.py に rst_prolog 変数を定義すると，その内容を各 .rst ファイルの先頭に追加してくれる． よって，</description>
    </item>
    
    <item>
      <title>AngularJSでfullPage.jsを使う </title>
      <link>https://www.jkawamoto.info/blog-ja/fullpagejs-in-angularjs/</link>
      <pubDate>Sat, 13 Aug 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/fullpagejs-in-angularjs/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 
AngularJS から fullPage.js を使う場合の備忘録．
angular-fullpage.js はあるが，npm で配布されているバージョンはイベントハンドラが動いていないので， GitHub にある最新版を利用する．
また，fullPage.js は各セクションが兄弟ノードにあることを期待しているが， コンポーネントの関係によっては全てのセクションを兄弟ノードに集めることが難しい場合もある． その場合は，修正した fullPage.js を使う．
angular-fullpage.js AngularJS 用に fullPage.js のディレクティブを提供してくれるライブラリ． ただし，npm に登録されているものは少し古いバージョンなので， GitHub からインストールする様に package.json を編集する．
{ &amp;quot;dependencies&amp;quot;: { &amp;quot;angular-fullpage.js&amp;quot;: &amp;quot;hellsan631/angular-fullpage.js&amp;quot;, ... }, ... }  dependencies に上記を追加して，npm install すれば良い．（参考：node.jsのnpm（package.json）にGitHubを指定する：更新の止まったモジュールを勝手に改修して使う）
利用方法は，fullPage.js を適用したい要素に full-page 属性を付ける．
&amp;lt;div full-page&amp;gt; &amp;lt;div class=&amp;quot;section&amp;quot;&amp;gt;Section 1&amp;lt;/div&amp;gt; &amp;lt;div class=&amp;quot;section&amp;quot;&amp;gt;Section 2&amp;lt;/div&amp;gt; &amp;lt;div class=&amp;quot;section&amp;quot;&amp;gt;Section 3&amp;lt;/div&amp;gt; … &amp;lt;/div&amp;gt;  また，オプションは options 属性経由で渡す． 例えば，コントローラを次の様にしておいて，</description>
    </item>
    
    <item>
      <title>Meteorでi18nパッケージを使う</title>
      <link>https://www.jkawamoto.info/blog-ja/i18n-package-in-meteor/</link>
      <pubDate>Sat, 13 Aug 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/i18n-package-in-meteor/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 
Meteor を使った Web アプリケーションを国際化 (i18n) する際の備忘録． universe:i18n パッケージの使い方をまとめる．
universe:i18n Atmosphere に登録されている国際化パッケージの一つ． サポートしているロケールの一覧は，ここから確認できる． また，JSON または YAML で翻訳対応表を渡すことができる．
インストールには，次のコマンドを実行する．
$ meteor add universe:i18n  インポートは，必要なスクリプトファイルで
import i18n from &amp;quot;meteor/universe:i18n&amp;quot;;  とすれば良い．
翻訳語の登録 翻訳対応表はファイルで与えることもできるが，API を使って個別に登録することもできる．
i18n.addTranslation(&amp;quot;ロケール&amp;quot;, &amp;quot;名前空間&amp;quot;, &amp;quot;キーワード&amp;quot;, &amp;quot;語&amp;quot;);  の形式で登録できる．
翻訳語ファイル 前節の様に個別に i18n.addTranslation 関数を使って登録するのは手間なので， ファイルで与えることができる． 翻訳語のファイルは JSON か YAML に対応しており， ファイル名がそれぞれ .i18n.json または .i18n.yml で終わる必要がある． ここでは，YAML 形式を使うことにする．
翻訳ファイルは単純なキー・バリューの組み合わせを列挙する．
ok: 決定 cancel: キャンセル  また，_namespace 属性を使って各ファイルが属する名前空間を指定できる．</description>
    </item>
    
    <item>
      <title>AngularJSでChart.jsを使う</title>
      <link>https://www.jkawamoto.info/blog-ja/chartjs-in-angularjs/</link>
      <pubDate>Fri, 12 Aug 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/chartjs-in-angularjs/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 
AngularJS から Chart.js を使う場合の備忘録． 結論から言えば，Angular Chart を利用すれば良い．
Angular Chart の利用 ドキュメント にもあるように，canvas タグに chart クラスと表示するグラフタイプ別のクラスを付ける． 例えば，bar グラフを表示したい場合，class=&amp;quot;chart chart-bar&amp;quot; を表示先の canvas に追加する．
プロットするデータは，chart-data, chart-labels, chart-series, chart-dataset-override などの属性を使って渡す．ここの渡し方が，元々の Chart.js とは異なっていて，少しトリッキーである．
chart-data は Chart.js におけるdata.datasets に対応する項目だが，配列か二次元配列しか渡せない． Char.js では，ラベルや色情報も合わせた次のようなオブジェクトを渡していた．
datasets: [{ label: &#39;# of Votes&#39;, data: [12, 19, 3, 5, 2, 3], backgroundColor: [ &#39;rgba(255, 99, 132, 0.2)&#39;, &#39;rgba(54, 162, 235, 0.2)&#39;, &#39;rgba(255, 206, 86, 0.</description>
    </item>
    
    <item>
      <title>Sphinxドキュメントにトラッキングコードを追加する</title>
      <link>https://www.jkawamoto.info/blog-ja/add-tracking-codes-to-sphinx-documents/</link>
      <pubDate>Fri, 12 Aug 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/add-tracking-codes-to-sphinx-documents/</guid>
      <description>  本稿は Qiita 投稿記事 のバックアップです．
 概要 sphinx_rtd_theme を使ったSphinx ドキュメントにトラッキングコードを追加する方法の備忘録．
方法 sphinx_rtd_theme の layout.htmlにある，extrabody ブロックを使う．
作成中ドキュメントの _template ディレクトリに次のような内容の layout.html を作成する．
{% extends &amp;quot;!layout.html&amp;quot; %} {% block extrabody %} &amp;lt;script&amp;gt; トラッキングコードを埋め込むスクリプト &amp;lt;/script&amp;gt; {% endblock %}  {% extends &amp;quot;!layout.html&amp;quot; %} で sphinx_rtd_theme の layout.html を拡張することを宣言し，extrabody の内容を定義している．
後はコンパイルすれば良い．
参考  Google AnalyticsやGoogle Adsenceを貼りたい  </description>
    </item>
    
    <item>
      <title>Mac に numba をインストール</title>
      <link>https://www.jkawamoto.info/blog-ja/install-numba-to-mac/</link>
      <pubDate>Fri, 29 Jul 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/install-numba-to-mac/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 
お手軽に python コードを高速化するために，numba を導入してみた． しかし，pip だけではインストールできなかったので，備忘録としてインストール手順を記録しておく．
インストール llvm と enum34 が別途必要らしい． 特に，llvm は最新の 3.8.x ではなく 3.7.x が要るようなので， homebrew/versions を tap してインストールする． また，環境変数 LLVM_CONFIG の設定を忘れないようにする．
$ brew tap homebrew/versions $ brew install homebrew/versions/llvm37 $ export LLVM_CONFIG=/usr/local/Cellar/llvm37/3.7.1/bin/llvm-config-3.7 $ pip install enum34 $ pip install numba  インポート numba がインストールされていない環境でも動くように， インポートできなかった場合は何もしないデコレータに差し替えておく．
try: from numba import jit except ImportError: def jit(*args, **_kwargs): if len(args) &amp;gt; 0 and hasattr(args[0], &amp;quot;__call__&amp;quot;): return args[0] else: def _(func): return func return _  @jit 以外も使う場合は同様のものをそれぞれ定義する． また，この場合型指定はオブジェクトではなく文字列で渡す必要がある．</description>
    </item>
    
    <item>
      <title>QNAP に Apt キャッシュサーバを建てる</title>
      <link>https://www.jkawamoto.info/blog-ja/apt-cache-server-on-qnap/</link>
      <pubDate>Wed, 27 Jul 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/apt-cache-server-on-qnap/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 はじめに docker を使って開発をしていると apt-get をよく利用する． 特に，ディスクサイズを節約するためにキャッシュを削除したり古いイメージを削除するため， 必要なパッケージを毎回一からインストールすることも多い． これは色々なところに負荷をかけているので， APT のパッケージリポジトリキャッシュサーバ (Apt-Cacher NG) を用意することにした．
ちょうど QNAP の NAS が利用可能であり，また QNAP は Docker を使える と分かったので， Docker ベースで Apt-Cacher NG を用意する．
Apt-Cacher NG イメージの準備 Apt-Cacher NG イメージの準備には， (Docker で) ローカルに APT のパッケージリポジトリキャッシュサーバ (apt-cacher-ng) を建てたら幸せになった。 が参考になった．注意点としては，NAS の CPU アーキテクチャを調べること． 使っている NAS は ARM であったため，ARM 用のイメージを用意する必要があった．
なお，作成した ARM 用 Apt-Cacher NG イメージの Dockerfile は GitHub に， イメージそのものは，Dockerhub に置いてある．</description>
    </item>
    
    <item>
      <title>QNAP に Pypi キャッシュサーバを建てる</title>
      <link>https://www.jkawamoto.info/blog-ja/pypi-cache-server-on-qnap/</link>
      <pubDate>Wed, 27 Jul 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/pypi-cache-server-on-qnap/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 はじめに QNAP に Apt キャッシュサーバを建てるに続き， QNAP の NAS に Docker コンテナとして Pypi キャッシュサーバを建てる． LAN 内での pip の高速化とトラフィック削減を目指す．
Pypi キャッシュサーバ Pipit のキャッシュサーバとして，devpi server を用いる．Docker で運用するので，devpi のイメージを探す． 例えば，scrapinghub/docker-devpi などが見つかった．
前回 にも述べた通り，手元の NAS は ARM ベースであった． そのため，別途 ARM 用 devpi イメージを作成した． 作成したイメージの Dockerfile は，GitHub に，イメージは DockerHub に置いてある．
devpi server コンテナの起動 コンテナの管理には，Container Stationを利用する． もしなければ，App Center からインストールする．Container Station のマニュアルは ここ から参照できる．

コンテナの作成タブから，利用するコンテナイメージを検索する． デフォルトでは DockerHub にあるイメージを利用できる．

目的のイメージが見つかったらインストールする．</description>
    </item>
    
    <item>
      <title>Go言語以外のリポジトリを.goimportsignoreに追加する</title>
      <link>https://www.jkawamoto.info/blog-ja/ignore-non-golang-projects-in-goimport/</link>
      <pubDate>Sun, 24 Jul 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/ignore-non-golang-projects-in-goimport/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 はじめに ghqを使ったローカルリポジトリの統一的・効率的な管理についてや ghq: リモートリポジトリのローカルクローンをシンプルに管理するで紹介されているように， $GOPATH/src以下に言語に関わらずすべてのソースコードを集めると， リポジトリ管理が楽になる反面$GOPATH/srcがどんどん大きくなっていく．
goimportsのスキャン対象から特定ディレクトリを除外するによると， .goimportsignore に記載されたパスは goimports の対象から外れるそうなので， Go言語以外のリポジトリを追加することにした．
gii gii は $GOPATH/src 以下にある git リポジトリのうち， .go ファイルを含まないものを $GOPATH/src/.goimportsignore に追加するツール．
インストールは，
go get github.com/jkawamoto/gii  か，Homebrew を使っている場合は，
brew tap jkawamoto/gii brew install gii  または，ここからバイナリを取得する．
実行は，単に gii を呼ぶだけ．--gopath オプションで $GOPATH 以外をルートにできる． ヘルプテキストは次の通り．
gii [global options] GLOBAL OPTIONS: --gopath GOPATH GOPATH [$GOPATH] --help, -h show help --version, -v print the version  すでに，.</description>
    </item>
    
    <item>
      <title>Pythonモジュールの関係図を作る</title>
      <link>https://www.jkawamoto.info/blog-ja/relationship-graph-of-python-modules/</link>
      <pubDate>Sun, 24 Jul 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/relationship-graph-of-python-modules/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 はじめに リファクタリングのために，モジュール間の関係図を作る． Pythonでモジュールの依存関係図を描きたいとかPython dependencies inside a package によると， snakefood が良さそうだったので使ってみた．
snakefood pip でインストール可能．
$ pip install snakefood  いくつかのコマンドが提供されているが， sfood で解析し，stood-graph で Graphviz 用の dot ファイルを書き出せる．
解析したいパッケージのルートが ROOT だとすると，
$ sfood ROOT | sfood-graph &amp;gt; graph.dot  で graph.dot ができるので，後は適当にプロットする．
$ dot -Tjpg graph.dot -o graph.jpg -Gdpi=800  モジュールが多い場合解像度(-Gdpiオプションの値)は大きめに設定しないと潰れて読めなくなる． jpg 以外で出力する場合は，-Tpng などとすれば良い．
なお，sfood に -i オプションをつけると，外部パッケージは省くことができる．
サンプル 参考までに，selenium で試した結果を掲載しておく．

その他 pyreverseの結果の見方とオプションの使い方 によるとpyreverse というツールでもいけるみたい．</description>
    </item>
    
    <item>
      <title>もっと簡単にGoogleCloudPlatformを使う</title>
      <link>https://www.jkawamoto.info/blog-ja/roadie-gcp/</link>
      <pubDate>Sun, 17 Jul 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/roadie-gcp/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 はじめに 
Google Cloud Platform で単発処理を行う Docker コンテナ は，Cloud Platform を使うための事前・事後処理を助けてくれるものの，Docker の知識や Cloud Platform でのインスタンス管理の知識は必要だった．そこで，もっと簡単に Google Cloud Platform を使うためのコマンドラインツール roadieを作成した．
このツールはローカル端末で動作し，インスタンスの作成，ソースコードの配置，実行，そして計算結果の管理まで行う．クラウドに関する知識はほとんど不要でクラウドが利用可能になると思う．
インストールと事前準備 まず Google Cloud Platform が利用可能な状態になっている必要がある．また，ローカル端末から Google Cloud Platform にアクセスするために，Cloud SDK が必要になる．別途インストールした後，初期化を行ってください．gcloud auth list を実行してみて，Credentialed accounts にアカウントが表示されれば初期化済みである．
roadie のインストールは，コンパイル済みバイナリ をパスの通った所へ置くか，Go言語が設定済みの場合は
$ go get github.com/jkawamoto/roadie  にて，Mac ユーザで Homebrew を使っている場合は，
$ brew tap jkawamoto/roadie $ brew install roadie  によって行える．
インストール後，クラウドで実行したいソースコードのあるディレクトリで，
$ roadie init  を実行する．Google Cloud Platform に登録してある Project ID とデータ保存先のバケット名を聞かれるので適宜適宜入力する．バケット名は，特にこだわりが無ければ Project ID と同じで良い．なお，設定可能な Project ID 一覧は，ここから取得できる．</description>
    </item>
    
    <item>
      <title>Sphinx のセットアップまとめ</title>
      <link>https://www.jkawamoto.info/blog-ja/sphinx-setup/</link>
      <pubDate>Wed, 13 Jul 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/sphinx-setup/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 Python パッケージのドキュメント作成には Sphinx が便利．sphinx-apidoc, autodoc を使えば，docstrings から API リファレンスを自動で作成してくれる．これらを使う時，いつもだいたい同じセットアップが必要なので，備忘録としてまとめておく．
前準備 sphinx のインストールとドキュメント用ディレクトリの作成．
$ pip install sphinx $ mkdir docs $ cd docs  その結果，次のようなディレクトリ構成になっているとする．
. ├── README.md ├── docs ├── &amp;lt;your package&amp;gt; └── tests └── テストたち  sphinx-quickstart 基本的にはデフォルトで，次の項目だけ設定する．
 source と build は分ける autodoc: automatically insert docstrings from modules は yes mathjax は必要に応じて yes viewcode も必要に応じて yes  sphinx-apidoc の設定 Makefile を編集して，ドキュメントのコンパイル時に sphinx-apidoc を呼ぶようにする．</description>
    </item>
    
    <item>
      <title>GoogleCloudPlatformで単発処理を行うDockerコンテナ</title>
      <link>https://www.jkawamoto.info/blog-ja/roadie-gcp-container/</link>
      <pubDate>Mon, 11 Jul 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/roadie-gcp-container/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 あるところからデータの塊を取ってきて何らかの解析にかけたい．それらを GCP (Google Cloud Platform) で行いたいが，インスタンスの設定やファイルのダウンロード，アップロードが面倒．そんな時に使える Dockerコンテナイメージを作った．
なお，ここでの処理は，毎日ログデータを深夜に処理するなどのバッチ処理を考える．ストリーム処理には向かない．
Roadie-GCP GCP でプログラムを実行する時に使える補助コンテナ．必要なファイル，処理内容，実行結果の保存先などをまとめた YAML スクリプトファイルを渡せば後はうまくやってくれる．なおベースイメージは Ubuntu である．
スクリプトファイル名が conf.yaml の場合，実行方法は次の通り．
$ docker run -i jkawamoto/roadie-gcp &amp;lt; conf.yml  なお，このコンテナは実行が終わり，結果をアップロードし終わるとインスタンスを削除する．そのため，インスタンスの作成時に https://www.googleapis.com/auth/compute スコープを指定する必要がある．この挙動を変える場合には --no-shutdown オプションを指定する．
スクリプトファイル スクリプトファイル conf.yaml は apt, source, data, run, result, upload の６要素を定義するYAML ファイル．それぞれ，プログラム実行に必要な apt パッケージ，プログラムのソースファイル，プログラムの実行に必要なデータファイル，プログラム実行手順，実行結果の保存先，そして実行結果のファイルパターンを定義する．script.yml は次のような形になる．
apt: - unrar source: https://github.com/abcdefg/some-program.git data: - http://mmnet.iis.sinica.edu.tw/dl/wowah/wowah.rar run: - unrar x -r wowah.rar - ./analyze WoWAH result: gs://somebucket/ upload: - &amp;quot;*.</description>
    </item>
    
    <item>
      <title>docstrings から argparse を補完する</title>
      <link>https://www.jkawamoto.info/blog-ja/dsargparse/</link>
      <pubDate>Fri, 08 Jul 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/dsargparse/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 はじめに python でコマンドラインツールを作る場合，引数のパーサーには click が便利． しかし，複雑なことをやろうとすると argparse の方が簡単な気がして使い分けている． 一方で，argparse を使うと description や help をサブコマンドや引数に与える必要がある． これらは，大体の場合 docstring と情報が重複していて二度手間である． そこで，docstring を使って argparse に情報を渡す方法を考えてみる．
なお，docstrings は Googleのスタイルガイドに従って書かれているとする．
プログラム全体の description コマンド本体の説明，つまり argparse.ArgumentParser の description 引数． これは main 関数のあるモジュールの docstring に書かれているはずである． よって，ArgumentParser の作成は，
parser = argparse.ArgumentParser( description=__doc__, formatter_class=argparse.RawTextHelpFormatter)  とすれば良さそうである． なお，formatter_class に argparse.RawTextHelpFormatter を渡しているのは， これ以降設定する description や help から改行や空白を削除されるのを防ぐためである．
サブコマンドの description サブコマンドは,それを実行する関数とセットになっていると仮定する． つまり最低限，
a1_cmd = subparsers.add_parser(&amp;quot;a1&amp;quot;) a1_cmd.set_defaults(cmd=a1)  となっていると思う．であれば，サブコマンドを実装する関数，ここでは a1 が与えられれば，</description>
    </item>
    
    <item>
      <title>Travis で PhantomJS 2.1.1 を使う</title>
      <link>https://www.jkawamoto.info/blog-ja/install-phantomjs-in-travis/</link>
      <pubDate>Sun, 05 Jun 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/install-phantomjs-in-travis/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 Travis CI で PhantomJS と Selenium を使ったテストを行っているのだが， PhantomJS のバージョンが古くて上手くいかなかった．PhantomJS 2.1.1 をインストールする方法を調べたのでまとめておく．
方法 Travis CI には PhantomJS 1.9.8 が予め用意されているので，このバージョンで問題ない場合は何もする必要は無い．バージョン 2.1.1 が必要な場合， .travis.yml に下記の項目を追加する．
before_script: - mkdir travis-phantomjs - wget https://assets.membergetmember.co/software/phantomjs-2.1.1-linux-x86_64.tar.bz2 -O $PWD/travis-phantomjs/phantomjs-2.1.1-linux-x86_64.tar.bz2 - tar -xvf $PWD/travis-phantomjs/phantomjs-2.1.1-linux-x86_64.tar.bz2 -C $PWD/travis-phantomjs - export PATH=$PWD/travis-phantomjs/phantomjs-2.1.1-linux-x86_64/bin:$PATH  この https://assets.membergetmember.co/software/phantomjs-2.1.1-linux-x86_64.tar.bz2 が使えない場合は， 代わりに https://bitbucket.org/ariya/phantomjs/downloads/phantomjs-2.1.1-linux-x86_64.tar.bz2 も使えるらしい． Bitbucket の方はブロックされたらしいと聞いたので，assets.membergetmember.co の方を使った．こちらは今のところ問題無い模様．
参考 https://github.com/travis-ci/travis-ci/issues/3225 （というか，このスレから解決方法を抜き出しただけ．）</description>
    </item>
    
    <item>
      <title>データ解析のための統計モデリング入門 第10章 を PyMC で解く</title>
      <link>https://www.jkawamoto.info/blog-ja/pymc-lesson-10/</link>
      <pubDate>Tue, 24 May 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/pymc-lesson-10/</guid>
      <description>  参考書籍  </description>
    </item>
    
    <item>
      <title>gulp-watchify で browserify と parcelify を差分ビルド</title>
      <link>https://www.jkawamoto.info/blog-ja/incremental-build-by-gulp-watchify/</link>
      <pubDate>Tue, 17 May 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/incremental-build-by-gulp-watchify/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 
利用するライブラリが増えてビルドに時間がかかるようになったので， watchify を使った差分ビルドを試してみる． タスクランナーに gulp を使用しているので， gulp-watchify を使い， browserify と Parcelifyによるビルドを差分ビルドにする．
gulp-watchify の使い方 サンプルファイル によると，単純な使い方は，
gulp = require &amp;quot;gulp&amp;quot; $ = require(&amp;quot;gulp-load-plugins&amp;quot;)() watching = false gulp.task &amp;quot;browserify&amp;quot;, $.watchify (watchify) -&amp;gt; gulp.src &amp;quot;src/*.js&amp;quot; .pipe watchify watch:watching .pipe gulp.dest &amp;quot;public/js/&amp;quot; gulp.task &amp;quot;watch&amp;quot;, -&amp;gt; watching = true  となるようだ．これで，gulp browserify とすれば通常のビルドを gulp watch browserify とすれば，watchify による監視を始めることができる．
なお，gulp-load-plugins に関しては，[gulp] 効率的にプラグインを読み込む を参照．上の例では変わらないが，require を減らすために使っている．
注意 gulp-watchify をインストールしただけでは，watchify はインストールされない模様．なので，</description>
    </item>
    
    <item>
      <title>Dockerで別ネットワークにあるコンテナをセキュアにリンクする</title>
      <link>https://www.jkawamoto.info/blog-ja/secure-link-another-container/</link>
      <pubDate>Wed, 11 May 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/secure-link-another-container/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 あるホストで動作している Docker コンテナから別のネットワークにある別ホスト上で動作しているコンテナをリンクしたい．しかし，ネットワーク間の通信は信頼できないためセキュアな通信を張る必要がある．本来ならば，VPNを用意してオーバーレイネットワークを構築すべきかもしれないが，小規模な実験的プロジェクトのため，SSHトンネルとAmbassadorパターンで解決する．
AmbassadorS AmbassadorS は Ambassador パターンを SSH トンネル上で実行するための Docker イメージである．
現在，Alpine Linux ベースのイメージと Raspberry Pi 用に Raspbian ベースのイメージの二種類を公開している．以下では，Alpine Linux ベースの jkawamoto/ambassadors を使う場合を考える．（Raspberry Pi から利用する場合は jkawamoto/rpi-ambassadors を使う．）
AmbassadorS には，サーバ，クライアントそしてトンネルの三つのモードがある．それぞれ次のように接続して使用する．
つまり，リンク先のコンテナが走っているホスト上にサーバモードの AmbassadorS コンテナを走らせ，リンク元のコンテナが走っているホスト上でクライアントモードとトンネルモードの AmbassadorS コンテナを走らせる．
リンク先のコンテナが複数ある場合でも，各ホストにサーバモードのコンテナは一つあれば良い．トンネルモードのコンテナは，接続先のホスト一台に付き一つ必要になる．クライアントモードのコンテナは，元々の Ambassadorパターンと同じくリンク先のコンテナ数分必要になる．
AmbassadorS の実行は，基本的に
$ docker run -dt jkawamoto/ambassadors (server|client|tunnel) [-v] Options: -v Verbose mode for debugging.  の形で，第一引数としてモードを指定 (server, client, tunnel のいずれか) する．第二引数に -v を渡すとデバッグ用に詳細なログを出力するようになる．
なお，各モードとも上記に Docker へのオプション指定，マウントやリンクの設定が必要になる．具体的な設定方法は次の接続例で説明する．</description>
    </item>
    
    <item>
      <title>npm 管理のライブラリが提供する css をインポートする</title>
      <link>https://www.jkawamoto.info/blog-ja/import-css-from-npm/</link>
      <pubDate>Wed, 11 May 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/import-css-from-npm/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 
クライアントサイドのパッケージ管理は，bower から npm に移した方が良いらしい．npm 管理の JavaScript パッケージは，Browserify を使えばインポートできる．では，CSS はどうやってインポートすれば良いのか？例えば，bootstrap を npm でインストールして bundle.css に取り込むにはどうすれば良いのか？調べた結果をまとめる．
前提 タスクランナーとして Gulp を使う．また，各パッケージのフォルダ構成に依存しない方法を探す．また，下記の例では bootstrap を使用しているが， npm i --save bootstrap にてインストール済みとする．
Parcelify を使う JavaScript のインポートに Browserify を使う場合，プラグインの一つである Parcelify の利用はメジャーな方法だろう．逆に，JavaScript をまったく使わないプロジェクトではダミーが必要になると思う．
Parcelify を使う場合，package.json の style 要素にインポートする CSS ファイルを列挙する必要がある．
{ &amp;quot;style&amp;quot;: [ &amp;quot;./node_modules/bootstrap/dist/css/bootstrap.min.css&amp;quot;, &amp;quot;./src/css/main.css&amp;quot; ] }  例えば，bootstrap と自前の CSS ファイルの両方をインポートする場合は上記のように書く（他の項目については省略した）．そして，Gulp のタスクは次の通り．
gulp = require &amp;quot;gulp&amp;quot; browserify = require &amp;quot;browserify&amp;quot; parcelify = require &amp;quot;parcelify&amp;quot; source = require &amp;quot;vinyl-source-stream&amp;quot; gulp.</description>
    </item>
    
    <item>
      <title>Youtubeのコメントをスクレイピングする</title>
      <link>https://www.jkawamoto.info/blog-ja/youtube-comment-scraper/</link>
      <pubDate>Fri, 22 Apr 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/youtube-comment-scraper/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 コメントの親子関係を利用したビデオ共有サイトにおけるネットいじめコメントの検出では，Youtubeに投稿されたコメントを対象に，いじめコメントの検出を行っている．この研究のために，YoutubeコメントのスクレイピングツールYoutube comment scraperを作成した．
Youtube comment scraper そのなの通り，Youtubeの動画再生ページをスクレイピングして，投稿されたコメントを取得する．パッケージはnpmに登録してあるので，npmコマンドにてインストールできる．
スタンドアロンで利用する場合，
$ npm install -g youtube-comment-scraper  とすれば，scraperコマンドが利用できるようになる．このコマンドの利用方法は，
Usage: scraper url [options] url URL for a Youtube video page or video ID. --help, -h Displays help information about this script --version Displays version info  となっていて，要するにYoutubeの動画再生ページのURLか，動画IDを渡せば良い． 例えば，
# URLを渡す場合． $ scraper &amp;quot;https://www.youtube.com/watch?v=vN4U5FqrOdQ&amp;quot; # IDを渡す場合 $ scraper vN4U5FqrOdQ  などとなる．出力はJSON形式で下記のようなフォーマットである．
{ &amp;quot;id&amp;quot;: &amp;quot;動画 ID&amp;quot;, &amp;quot;channel&amp;quot;:{ &amp;quot;id&amp;quot;: &amp;quot;チャンネルの ID&amp;quot;, &amp;quot;name&amp;quot; : &amp;quot;チャンネル名&amp;quot; }, &amp;quot;comments&amp;quot;: [ { &amp;quot;root&amp;quot;: &amp;quot;親コメント&amp;quot;, &amp;quot;author&amp;quot;: &amp;quot;このコメントの投稿者&amp;quot;, &amp;quot;author_id&amp;quot;: &amp;quot;投稿者のID&amp;quot;, &amp;quot;like&amp;quot;: &amp;quot;いいねスコア（下記参照）&amp;quot;, &amp;quot;children&amp;quot;: [ { &amp;quot;comment&amp;quot;: &amp;quot;親コメントへのリプライ&amp;quot;, &amp;quot;author&amp;quot;: &amp;quot;リプライの投稿者&amp;quot;, &amp;quot;author_id&amp;quot;: &amp;quot;投稿者のID&amp;quot;, &amp;quot;like&amp;quot;: &amp;quot;いいねスコア&amp;quot;, }, .</description>
    </item>
    
    <item>
      <title>福岡市の公共施設予約状況をスクレイピングする</title>
      <link>https://www.jkawamoto.info/blog-ja/fukuoka-city-community-space-finder/</link>
      <pubDate>Fri, 22 Apr 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/fukuoka-city-community-space-finder/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 福岡市では，公共施設の予約状況を調べるウェブサービスが提供されている． しかしながら，かなり昔に設計されたサービスで，RESTでもなければ， 他のサービスと連携させることもできない仕様になっている．そこで，このサービスをスクレイピングし， 各公共施設の予約状況を取得するライブラリ Fukuoka City Community Space Finderを作成した．
インストールとサンプル npm に登録しているので， npm コマンドを使ってインストールできる．
$ npm install fukuoka-city-community-space-finder  Fukuoka City Community Space Finder は４つの関数 area, building, institution そして status を提供する．初めの３つの関数は公共施設名を検索するためのものである． area 関数は福岡市の地域名，要するに区名を返す． building は地域名を引数に取り，その地域にある公共施設の一覧を返す． そして，institution は地域名，公共施設名を引数に取り，その施設に含まれるレンタル可能な単位の名前，例えば「会議室１」や「テニスコート１」などの一覧を返す．
ちなみに， area, building, institution という名称は元々のサービスで使われていた名称に合わせた．
下記にそれぞれの実行例を示す． なお，スクレイピングは非同期処理のため，各関数とも戻り値は Promise である． (参考：今更だけどPromise入門)
var finder = require(&amp;quot;fukuoka-city-community-space-finder&amp;quot;); // 地域名の列挙． finder.area().then(function(res){ console.log(res); }); // -&amp;gt; [ &#39;中央区&#39;, &#39;博多区&#39;, &#39;東区&#39;, &#39;西区&#39;, &#39;南区&#39;, &#39;城南区&#39;, &#39;早良区&#39; ] // 中央区にある公共施設の列挙． finder.</description>
    </item>
    
    <item>
      <title>Travis CI に CVXOPT, NumPy, SciPy をインストールする</title>
      <link>https://www.jkawamoto.info/blog-ja/install-cvxopt-numpy-scipy-to-travis/</link>
      <pubDate>Thu, 24 Mar 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/install-cvxopt-numpy-scipy-to-travis/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 Travis CI で CVXOPT, NumPy, SciPy を使った Python プログラムをテストしたい． これらのライブラリは pip だけではインストールできなかったので，他に必要なパッケージをまとめる．
CVXOPTがSuiteSparseの同梱を辞めたことによる修正（2017年2月5日）
前提 テストの実行に必要なライブラリは requirements.txt に書かれているものとする． この時，Travisは自動で pip install -r requirements.txt してくれるので， install ステップは不要．
.travis.yml まとめると，CVXOPT のインストールに libblas-dev と liblapack-dev が， SciPy のインストールに gfortran が必要なので，.travis.yml の addons.apt.packages を使って用意しておく．
また，CVXOPTがSuiteSparseの同梱を辞めたため，自前で用意しておく必要がある． この手続きは before_install に記述する．
language: python python: - 2.7 addons: apt: packages: - libblas-dev - liblapack-dev - gfortran before_install: - wget http://faculty.cse.tamu.edu/davis/SuiteSparse/SuiteSparse-4.5.3.tar.gz - tar -xf SuiteSparse-4.</description>
    </item>
    
    <item>
      <title>Let&#39;s Encrypt で証明書の更新</title>
      <link>https://www.jkawamoto.info/blog-ja/renew-certifications-of-letsentrypt/</link>
      <pubDate>Mon, 07 Mar 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/renew-certifications-of-letsentrypt/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 Public Beta である Let&amp;rsquo;s Encrypt の証明証は３ヶ月で有効期限が切れる．言い換えれば，３ヶ月ごとに更新手続きが必要なので，備忘録としてまとめる．
証明書の更新 letsencrypt-auto コマンドに renew サブコマンドが用意されているが，証明書の取得に用いる certonly サブコマンドで更新も行える．今回は certaonly コマンドを使用した．
ドメインが sample.com でドキュメントルートが /var/www の時，証明書の更新（というか再発行）は，
$ letsencrypt-auto certonly --webroot -w /var/www -d sample.com  で行える．/var/www にアクセス権がある状態で実行すること．
letsencrypt-auto コマンドがない場合 $ git clone https://github.com/letsencrypt/letsencrypt $ cd letsencrypt $ ./letsencrypt-auto certonly --webroot -w /var/www -d sample.com  注意 letsencrypt-auto certainly は -w オプションで指定した場所に .well-known というフォルダを作る．このフォルダが Web から見えていないと認証されない．なので，リバースプロキシを設定している場合でも，このフォルダだけは転送しないようにしておく．
server { listen 80; server_name sample.</description>
    </item>
    
    <item>
      <title>64bit Anaconda に cvxopt をインストールする</title>
      <link>https://www.jkawamoto.info/blog-ja/install-cvxopt-in-anaconda/</link>
      <pubDate>Fri, 26 Feb 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/install-cvxopt-in-anaconda/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 Windowsで 64bit版 の Anaconda に cvxopt をインストールしようと思ったら非常に苦労したので作業内容をまとめる．
cvxopt のドキュメントには Windows へのインストール方法が書かれている． しかし，32bit 版の Python を想定しているらしく，ドキュメント通りにすんなりとインストールは出来ないので注意．本稿は，このドキュメントに沿って変更すべき点をまとめる．
想定環境  Windows 10 (64bit) Anaconda for 64bit Windows (Python2.7) MinGW (64bit)  これらは既にインストールされているものとする．
なお，以降の作業は専用のディレクトリを作って，その中で行うものとする．例として D:\glpk 内で行う場合は，次のようにすればコマンドプロンプトを開くことができる． 依存ライブラリの準備 これは ドキュメント 通りで良い．
BLAS BLAS のソースファイル をダウンロードする．そして，コマンドプロンプトから次のコマンドを実行する．
$ tar -xvf blas.tgz $ cd BLAS-3.5.0 $ sed &#39;s/_LINUX/_WIN/&#39; make.inc -i $ make &amp;amp;&amp;amp; cp blas_WIN.a ../libblas.a $ cd ..  ただし，2行目のディレクトリ名は取得した BLAS ソースファイルのバージョンによって変わるので適宜読み替える．</description>
    </item>
    
    <item>
      <title>コンテナにインストールする python パッケージの管理</title>
      <link>https://www.jkawamoto.info/blog-ja/python-package-management-for-containers/</link>
      <pubDate>Wed, 24 Feb 2016 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/python-package-management-for-containers/</guid>
      <description>  本稿は Qiita 投稿記事 のバックアップです．
 概要 プログラムの実行に必要な python パッケージを Dockerfile に直接記述していたので，requirements を用いて一元管理する．
pip-tools で requirements の管理 requirements.in に必要なパッケージを記入する．
webapp2 paste webob  Dockerfile に pip-tools のインストールと，requirements.in の追加，パッケージのインストールに関する項目を追加する．
RUN apt-get update &amp;amp;&amp;amp; apt-get install -y python-pip RUN pip install -U pip pip-tools ADD ./requirements.in ./ RUN pip-compile &amp;amp;&amp;amp; \ pip install -r requirements.txt &amp;amp;&amp;amp; \ rm requirements.txt  参考  pip-toolsでrequirements.txtのパッケージバージョン番号を管理しよう  </description>
    </item>
    
    <item>
      <title>Onion Omega の初期設定</title>
      <link>https://www.jkawamoto.info/blog-ja/onion-omega-first-boot/</link>
      <pubDate>Sat, 28 Nov 2015 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/onion-omega-first-boot/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 IoT向け小型 Linux ボード Onion Omega が届いたので， 初期設定を行ってみた．Wifi の設定，ブラウザからターミナルに接続するなど基本的なことはできているものの， Node.js や Python といった開発環境は未完成の模様．
（参考: TechCrunch日本語版）
起動と Wifi 設定 基本的にスタートアップガイドの通りにやれば良い．本体を Dock に乗せてマイクロ USB ケーブルを挿し，電源を入れる．
(写真はスタートアップガイドより)
しばらくすると，Omega-???? という Wifi アクセスポイントが見つかるので接続する．初期設定では暗号化も何もされていないが後で変更できる．
アクセスポイントに接続後，ブラウザから http://192.168.3.1 にアクセスすると認証を求められる．初期設定ではユーザ名 root，パスワードは onioneerである．後は，画面に従って普段使っている Wifi の情報を入力しファームのアップデート，再起動を行えば完了．
再起動後（Omega 本体のLED点滅が終われば），再びOmega-????というアクセスポイントに接続し，http://192.168.3.1 にアクセスすればその他の設定及びインストール済みのアプリケーションを利用できる．
なお，Onion Omega が提供するアクセスポイントは，http://192.168.3.1 以外の通信を上で設定した Wifi アクセスポイントにバイパスしてくれるので，Onion Omega に接続したまま，通常の作業が行える．（トラブったらどうせGoogleで検索するので，いちいちアクセスポイントを切り替えなくて済む仕様は便利）
初期アプリ画面など GPIOツール ブラウザ上からGPIOの設定を変更できるツール．回路のデバッグなどには便利かも．ただ，動的に変更はできないので，複雑なことはさせられない．
ターミナル その名の通り，ブラウザベースのターミナル．
ステータス 容量は16MBで半分ほど使用済み．ノーマルの Dock には USB 端子が一つ付いてるので必要ならば外部ストレージを付ければ良いと思う．ただ，コンセプト的にはプログラムはクラウドの方に置いておく様な使い方をすべきだろうな．
その他 USB でシリアル接続することもできる．が，Onion のコンセプトから言うとブラウザ経由で使った方が良いだろう．何か設定をミスってどうにもならなくなった時用かな．
Macからシリアル接続する方法は，Silicon Labs CP2102 ドライバをインストールし，</description>
    </item>
    
    <item>
      <title>Raspbian に Docker Compose をインストールする</title>
      <link>https://www.jkawamoto.info/blog-ja/install-docker-compose-to-raspbian/</link>
      <pubDate>Sat, 17 Oct 2015 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/install-docker-compose-to-raspbian/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 Raspbian に Hypriot の Docker パッケージをインストールすると Docker Compose が付いてこない．そこで，ARM 用 Docker Compose を自分でコンパイルする．
インストール Docker composeのソースは GitHub にある． ただし，そのままでは動かないため Hypriot のパッチ を当ててからコンパイルする．
コンパイル方法は次の通り．
まずパッチが入っているリポジトリを clone する．
$ git clone https://github.com/hypriot/arm-compose.git $ cd arm-compose  パッチが対応している Docker Compose のバージョンが VERSION に書かれているので， それを元に，Docker Compose のソースをダウンロードする．
$ git clone -b `cat VERSION` https://github.com/docker/compose  そしてパッチを当てる．
$ cp -r patches/* compose/  最後に，コンパイルする．
$ cd compose $ script/build-linux  コンパイルが終われば，docker-compose のイメージと dist 以下に実行ファイルができる． dist 以下にある実行ファイルを docker-compose のファイル名で /usr/local/bin などに置けば良い．</description>
    </item>
    
    <item>
      <title>Raspberry Pi で F-PLUG のログ収集</title>
      <link>https://www.jkawamoto.info/blog-ja/receive-fplug-log-by-raspberypi/</link>
      <pubDate>Thu, 15 Oct 2015 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/receive-fplug-log-by-raspberypi/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 販売終了 が決まった富士通F-PLUGのログを， 今更ながらRaspberry Piにて集約する．
構成 Raspberry Pi の OS には Raspbian を使った． また，F-PLUG のデータは Docker コンテナを用いて取得し， Fluentd を使って収集することにした．
Raspberry Pi への Docker インストールは 別記事を参照． FluentdのインストールはRaspberry Pi に fluentd をインストールするを参考にした．
Bluetooth の設定とペアリング まず，関連パッケージをインストールする．
$ sudo apt-get install bluetooth bluez-utils bluez-compat  次に，F-PLUGのアドレスを取得する．
$ sudo hcitool scan  得られたアドレスを用いてペアリングを行う． 下記のコマンドを実行すると F-PLUG の LED が点滅するので， 本体のボタンを長押しする．点滅が止めばペアリングは完了です．
$ sudo bluetooth-agent 1234 &amp;lt;address&amp;gt;  最後に，起動時に接続するように設定ファイル /etc/bluetooth/rfcomm.conf を編集する．</description>
    </item>
    
    <item>
      <title>Raspberry Pi に upstart と Docker をインストール</title>
      <link>https://www.jkawamoto.info/blog-ja/upstart-and-docker-in-raspberry-pi/</link>
      <pubDate>Tue, 13 Oct 2015 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/upstart-and-docker-in-raspberry-pi/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 Raspberry Pi に Docker をインストールする場合，ARM 用のパッケージを使う． この時，サービス管理に upstart を使っていると，upstart 用の設定ファイルが見つからず インストールが失敗する．そのため，他の環境から設定ファイルをコピーしておく必要がある．
Hypriot Docker ARM 用の Docker パッケージとして， Hypriot Docker Debian Packages を使う． ダウンロードは ここ からできて， インストール方法も書いてある．
ただし，upstart を使っている場合，設定ファイルが足りずインストールが失敗するため，下記の docker.conf を /etc/init/ に用意しておく．
description &amp;quot;Docker daemon&amp;quot; start on (local-filesystems and net-device-up IFACE!=lo) stop on runlevel [!2345] limit nofile 524288 1048576 limit nproc 524288 1048576 respawn kill timeout 20 pre-start script if grep -v &#39;^#&#39; /etc/fstab | grep -q cgroup \ || [ !</description>
    </item>
    
    <item>
      <title>Apache のエラーログを slack に送る</title>
      <link>https://www.jkawamoto.info/blog-ja/send-apache-log-to-slack/</link>
      <pubDate>Fri, 18 Sep 2015 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/send-apache-log-to-slack/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 はじめに ようやく slack を使い始めたので，手始めに Apache のエラーログを転送してみる． ほぼ ここ にある通りで動作するが， 多少変更した部分もあるので備忘録も兼ねてまとめておく．
準備 ログの収集・転送には fluentd を使う．fluentd はインストールされているものとして， 今回必要となるプラグインをそれぞれインストールする．
$ sudo td-agent-gem install fluent-plugin-slack $ sudo td-agent-gem install fluent-plugin-rewrite-tag-filter $ sudo td-agent-gem install fluent-plugin-record-reformer  また，apache のログが置かれている /var/log/apache2 へのアクセスは root 権限が必要になっている． そのため，fluentd の実行ユーザを root に変更しておく． Ubuntu の場合，/etc/init.d/td-agent を開き td-agent から変更する （参考）．
# TD_AGENT_USER=td-agent # TD_AGENT_GROUP=td-agent TD_AGENT_USER=root TD_AGENT_GROUP=root  CentOS の場合，/etc/sysconfig/td-agent に下記を追加する．
TD_AGENT_USER=root TD_AGENT_GROUP=root  fluentd の設定 次に fluentd の設定を行う．使った設定は下記の通り．</description>
    </item>
    
    <item>
      <title>LaTeX スニペット集</title>
      <link>https://www.jkawamoto.info/blog-ja/latex-snippets/</link>
      <pubDate>Wed, 02 Sep 2015 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/latex-snippets/</guid>
      <description> </description>
    </item>
    
    <item>
      <title>fluentd で Compute Engine のログを収集する (2015年7月28日版)</title>
      <link>https://www.jkawamoto.info/blog-ja/fluentd-in-compute-engine-2/</link>
      <pubDate>Tue, 28 Jul 2015 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/fluentd-in-compute-engine-2/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 はじめに Google Compute Engine インスタンス (CoreOS) 上で走っている Docker コンテナの出力を Cloud Logging に集めたい．fluentd とfluent-plugin-google-cloudを使うとサービスアカウントを使って認証してくれるので簡単に収集できる．
ここに書いた時からバージョンが上がったらしく，動かなくなったため再調査した．
fluentd コンテナの準備 ドキュメントによると，インストールスクリプトが用意されているので，これを用いる．ただし，このスクリプトでインストールするとデーモンとして起動してしまうので，一旦停止したのちフォアグラウンドジョブとして実行する必要がある．さらに，/etc/google-fluentd/config.d/ に色々設定が含まれているので削除しておく．
FROM ubuntu:latest RUN apt-get update &amp;amp;&amp;amp; apt-get install -y curl # fluentd のインストールとデーモンの停止 RUN curl -L https://storage.googleapis.com/signals-agents/logging/google-fluentd-install.sh | bash \ &amp;amp;&amp;amp; service google-fluentd stop # fluent-plugin-record-reformer のインストール RUN /opt/google-fluentd/embedded/bin/gem install fluent-plugin-record-reformer # 不要な設定ファイルの削除 RUN rm /etc/google-fluentd/config.d/*.conf # 設定とエントリーポイントの追加 ADD docker.conf /etc/google-fluentd/config.d/ ADD entrypoint.sh /root/ ENTRYPOINT [&amp;quot;/root/entrypoint.</description>
    </item>
    
    <item>
      <title>高度プログラミングサンプルコード</title>
      <link>https://www.jkawamoto.info/blog-ja/programming-sample-codes/</link>
      <pubDate>Tue, 21 Jul 2015 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/programming-sample-codes/</guid>
      <description> 概要 九州大学基幹教育科目「高度プログラミング」総合課題３のサンプルコードです． 課題の内容や配布資料を参照してください．
 </description>
    </item>
    
    <item>
      <title>GCE スタートアップスクリプトで gsutil を使う</title>
      <link>https://www.jkawamoto.info/blog-ja/use-gsutil-in-startup-script/</link>
      <pubDate>Fri, 17 Jul 2015 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/use-gsutil-in-startup-script/</guid>
      <description>  本稿は Qiita 投稿記事 のバックアップです．
 問題 GoogleComputeEngine(GCE) CoreOS では，gsutil などのツールは，google/cloud-sdk という docker イメージ内にあるものを利用している．しかし，これらが使えるようになるのは スタートアップスクリプト終了後になっているため，スタートアップスクリプト内で gsutil などを使うと command not found となる．
解決策 スタートアップスクリプト内で google/cloud-sdk を pull し， そこに含まれているコマンドを利用する．また，なぜか gcloud components update しろと警告が出るので，予めアップデートしておく．
$ docker pull google/cloud-sdk $ docker run -t --name updating google/cloud-sdk /google-cloud-sdk/bin/gcloud components update -q $ docker commit updating google/cloud-sdk:latest  その後，gsutil コマンドを利用する，
$ docker run -t --rm google/cloud-sdk /google-cloud-sdk/bin/gsutil cat &amp;lt;url&amp;gt;  </description>
    </item>
    
    <item>
      <title>GCE 上の docker コンテナ内部から gsutil を使う</title>
      <link>https://www.jkawamoto.info/blog-ja/use-gsutil-in-containers/</link>
      <pubDate>Fri, 17 Jul 2015 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/use-gsutil-in-containers/</guid>
      <description>  本稿は Qiita 投稿記事 のバックアップです．
 概要 GoogleComputeEngine (GCE) インスタンスから gsutil などのツールを使うと， metadata サーバから適切に情報を取得してサービスアカウントを用いた認証を自動で行ってくれる． しかし，インスタンス内で走っている docker コンテナから同じことをする場合，boto の設定が必要となる．
設定方法 /etc/boto.cfg に
[GoogleCompute] service_account = default  を追加する．下記は，Dockerfile に記述する場合の例．
FROM ubuntu RUN apt-get update &amp;amp;&amp;amp; \ apt-get install -y libssl-dev python-pip python-dev \ libffi-dev python-crypto python-openssl RUN pip install -U gsutil RUN echo &amp;quot;[GoogleCompute]\nservice_account = default&amp;quot; &amp;gt;&amp;gt; /etc/boto.cfg  参考  boto - gsutil not working in GCE - Stack Overflow  </description>
    </item>
    
    <item>
      <title>ローカル通信以外を https に転送する</title>
      <link>https://www.jkawamoto.info/blog-ja/redirect-to-https-in-apache/</link>
      <pubDate>Sun, 21 Jun 2015 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/redirect-to-https-in-apache/</guid>
      <description>  本稿は Qiita 投稿記事 のバックアップです．
 概要 単なる備忘録．Apache への通信を https 強制にしたい．その一方で，サーバ内の通信はわざわざ https にする必要がないため http を使いたい．そこで，mod_rewrite を使ってアクセス元を見て https に転送するか決定する．
設定ファイル &amp;lt;VirtualHost *:80&amp;gt; ServerName http://sample.com RewriteEngine On RewriteCond %{REMOTE_ADDR} !=127.0.0.1 RewriteCond %{REMOTE_ADDR} !=%{SERVER_ADDR} # Docker コンテナからのアクセス RewriteCond %{REMOTE_ADDR} !^172\.17\. RewriteRule ^/?(.*)$ https://sample.com/$1 &amp;lt;/VirtualHost&amp;gt;  参考  Apache mod_rewrite Introduction - Apache HTTP Server Version 2.4  </description>
    </item>
    
    <item>
      <title>insecure string pickle を読み込む</title>
      <link>https://www.jkawamoto.info/blog-ja/read-insecure-string-pickle/</link>
      <pubDate>Thu, 18 Jun 2015 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/read-insecure-string-pickle/</guid>
      <description>  本稿は Qiita 投稿記事 のバックアップです．
 概要 バージョン 0 の pickle プロトコルは ASCII 表現でデータ直列化する．このテキストファイルを別のプラットフォームで利用する場合や，テキストモードでファイル転送する時にうっかり改行コードが書き変わるなどすると，insecure string pickle エラーが出て読み込めなくなることがある．
そんな時は，自前でファイルから読んで文字列を作成してから読み込めば良い．
ソースコード import pickle with open(inputfile, &amp;quot;r&amp;quot;) as fin: data = pickle.loads(&amp;quot;\n&amp;quot;.join([line.strip() for line in fin]))  参考  11.1. pickle — Python オブジェクトの整列化 - Python 2.7ja1 documentation  </description>
    </item>
    
    <item>
      <title>React で Google Map API を使う</title>
      <link>https://www.jkawamoto.info/blog-ja/google-map-api-from-react/</link>
      <pubDate>Fri, 05 Jun 2015 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/google-map-api-from-react/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 はじめに React が面白いので，Google Map を使っているアプリも React ベースに移行しようと思った．予想通り，既にライブラリ react-google-maps があって，これを使えば良いのだけれど，どうもオーバースペックな感じがする．そこで簡易コンポーネントを作った．
ソースコード Map コンポーネントのソースコードです．よりによって Coffee-React です．
Map = React.createClass propTypes: height: React.PropTypes.number.isRequired lat: React.PropTypes.number.isRequired lng: React.PropTypes.number.isRequired getInitialState: -&amp;gt; map: null mousemove_listener: null touchmove_listener: null componentDidMount: -&amp;gt; map = new google.maps.Map React.findDOMNode(@), center: new google.maps.LatLng(@props.lat, @props.lng) zoom: 15 mapTypeId: google.maps.MapTypeId.ROADMAP if &amp;quot;onmousedown&amp;quot; of window # Use mouse events @setState mousemove_listener: google.maps.event.addListener map, &amp;quot;mousemove&amp;quot;, (e) =&amp;gt; @handleMouseMove e if &amp;quot;ontouchstart&amp;quot; of window # Use touch events @setState touchmove_listener: google.</description>
    </item>
    
    <item>
      <title>fluentd で Compute Engine のログを収集する</title>
      <link>https://www.jkawamoto.info/blog-ja/fluentd-in-compute-engine/</link>
      <pubDate>Wed, 03 Jun 2015 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/fluentd-in-compute-engine/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 はじめに Google Compute Engine インスタンス上で走っている Docker コンテナの出力を Cloud Logging に集めたい。fluentd と fluent-plugin-google-cloud を使うとサービスアカウントを使って認証してくれるので簡単に収集できる。
バージョンアップに伴い下記の内容は古くなっています．2015年7月28日時点の情報はこちら．
fluentd コンテナの準備 reactivehub/google-fluentd-base というベースイメージがあったので，これを使うことにした．(ビルドステータスが若干不穏な感じなので別のものに変えた方が良いかもしれない．)
ログの収集設定は 公式のものを使うことにする．よって，次の設定を適当なファイル名で保存．
&amp;lt;source&amp;gt; type tail path /var/lib/docker/containers/*/*-json.log pos_file /var/log/fluentd-docker.pos time_format %Y-%m-%dT%H:%M:%S tag docker.* format json &amp;lt;/source&amp;gt; &amp;lt;match docker.var.lib.docker.containers.*.*.log&amp;gt; type record_reformer tag docker.all &amp;lt;record&amp;gt; container_id ${tag_parts[5]} &amp;lt;/record&amp;gt; &amp;lt;/match&amp;gt;  なお，上記の設定では最終的に docker.all というタグのレコードが用意されるが，Cloud Logging 上ではこのタグ名に対応するコレクションが作られる．
ついでに fluentd の出力も収集するために次の設定も用意した．下記の場合，gfluentd というコレクションが作られる．
&amp;lt;source&amp;gt; type tail path /var/log/google-fluentd/google-fluentd.log pos_file /var/log/google-fluentd.pos time_format %Y-%m-%dT%H:%M:%S tag gfluentd &amp;lt;/source&amp;gt;  続いて，reactivehub/google-fluentd-base を基にしたイメージを作成する Dockerfile を用意する．</description>
    </item>
    
    <item>
      <title>CoreOS で CloudStorage 上のスタートアップスクリプトを利用する</title>
      <link>https://www.jkawamoto.info/blog-ja/startup-script-in-cloud-storage/</link>
      <pubDate>Tue, 27 Jan 2015 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/startup-script-in-cloud-storage/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 Google Compute Engine にて，インスタンスの OS に CoreOS を選んだ場合，なぜか CloudStorage からスタートアップスクリプトを読み込めない．CloudStorage にアクセスするためのパッケージを準備するスクリプトを別サーバからダウンロードして対応する．
スタートアップスクリプト Google Compute Engine ではインスタンス起動時に実行する スタートアップスクリプト を指定できる．ドキュメント には CloudStorage に置いたファイルをスタートアップスクリプトに指定できると書かれているが，OS が CoreOS の場合，URL スキーム gs を扱うコマンドがスタートアップスクリプト実行時点では用意されていないようだ．http や https にはアクセスできるため，gs を扱い本当のスタートアップスクリプトを取得，実行するスクリプトを別に用意して対処する．
そのスクリプトは，下記の通りで gist に置いてある．
#!/bin/bash URL=$(curl http://metadata/computeMetadata/v1/instance/attributes/startup -H &amp;quot;Metadata-Flavor: Google&amp;quot;) docker pull google/cloud-sdk cd /tmp docker run -t --rm google/cloud-sdk /google-cloud-sdk/bin/gsutil cat $URL | tr -d &amp;quot;\r&amp;quot; &amp;gt; startup.sh chmod a+x startup.sh .</description>
    </item>
    
    <item>
      <title>CoreOS 利用時の GCE スタートアップスクリプトログ</title>
      <link>https://www.jkawamoto.info/blog-ja/startup-script-log-of-coreos/</link>
      <pubDate>Tue, 13 Jan 2015 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/startup-script-log-of-coreos/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 Google Compute Engine ではインスタンス起動時に実行するスタートアップスクリプトを指定できる． そのスタートアップスクリプトのログは，マニュアル によると
/var/log/startupscript.log  にあると書かれている．しかし，CoreOS の場合，Systemd を用いてスタートアップスクリプトを起動しているので， ログの取得には journalctl を使う． スタートアップスクリプトのサービス名は google-startup-scripts.service なので，
$ sudo journalctl -u google-startup-scripts.service  にて取得できる．</description>
    </item>
    
    <item>
      <title>Python から I2C 接続のディスプレイを操作する</title>
      <link>https://www.jkawamoto.info/blog-ja/use-i2c-displayes-from-python/</link>
      <pubDate>Wed, 31 Dec 2014 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/use-i2c-displayes-from-python/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 RaspberryPi に I2C 経由で繋いだ LCD を Python から操作する． 今回は，HD44780 に SpikenzieLabs の MPTH を付けた LCD を使用する．
準備 RaspberryPi 側で I2C を利用する準備が必要． 先ずは，/etc/modules に次の2行を追加する．
i2c-bcm2708 i2c-dev  次に，/etc/modprobe.d/raspi-blacklist.conf から次の行を削除 / コメントアウトする．
blacklist i2c-bcm2708  一旦再起動し，その後 i2c-tools と python-smbus をインストールする．
sudo apt-get install i2c-tools python-smbus  I2C バス番号とデバイスアドレスの取得 始めに，使用する LCD のバス番号とアドレスを取得する． sudo i2cdetect 0 と sudo i2cdetect 1 を実行し， エラーの出ない方がバス番号（0 か 1）であり，出力からアドレスを取得する． 例えば，出力が次のような場合，0x20 がアドレスである．</description>
    </item>
    
    <item>
      <title>コンテナの終了を通知するアプリ</title>
      <link>https://www.jkawamoto.info/blog-ja/notify-container-end/</link>
      <pubDate>Mon, 29 Dec 2014 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/notify-container-end/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 コンテナで単発の計算をさせていて、終了を通知してほしい。 iPhone 用の Pushover アプリを使っているので、これを利用する。
通知コンテナ イベントの取得は、ここ に書いた通り。 後は die イベントを取得して Pushover API を叩く。
簡単な実装を GitHub と DockerHub にて公開中。
使い方 $ docker pull jkawamoto/docker-notifier $ docker run -v /var/run/docker.sock:/var/run/docker.sock \ jkawamoto/docker-notifier &amp;lt;USER&amp;gt; &amp;lt;TOKEN&amp;gt; --filter sample.*  ここで  と  は、Pushover から渡されるユーザ API キーとアプリケーションキー。 --filter オプションに正規表現を渡すとマッチするコンテナ名を持つもののみ通知するようになる。</description>
    </item>
    
    <item>
      <title>Bootstrap の modal dialog が影の下に隠れる問題</title>
      <link>https://www.jkawamoto.info/blog-ja/fix-modal-dialog-of-bootstrap/</link>
      <pubDate>Wed, 24 Dec 2014 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/fix-modal-dialog-of-bootstrap/</guid>
      <description> 本稿は Qiita 投稿記事 のバックアップです．
 Bootstrap の modal dialog でダイアログ自体が影の下に隠れてしまうことがあった。 .modal-dialog の z-index が影のレイヤよりも小さいこと問題で、 適当に大きな値を設定しておけば回避できる。
設定例
&amp;lt;div class=&amp;quot;modal-dialog&amp;quot; style=&amp;quot;z-index: 1500&amp;quot;&amp;gt;...&amp;lt;/div&amp;gt;  </description>
    </item>
    
    <item>
      <title>Mac での pdfplatex</title>
      <link>https://www.jkawamoto.info/blog-ja/pfdplatex-in-mac/</link>
      <pubDate>Wed, 24 Dec 2014 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/pfdplatex-in-mac/</guid>
      <description> 本稿は Qiita 投稿記事 のバックアップです．
 pdfplatex コマンドが用意されていない場合、下記のコマンドをパスの通った所に置いておけば良い。
#! /bin/bash # # pdfplatex # pdfplatex コマンドの代用スクリプト # filename=${1%.*} platex $filename &amp;amp;&amp;amp; platex $filename &amp;gt; /dev/null &amp;amp;&amp;amp; dvipdfmx $filename  </description>
    </item>
    
    <item>
      <title>Pythonモジュールのインポート</title>
      <link>https://www.jkawamoto.info/blog-ja/importing-python-modules/</link>
      <pubDate>Wed, 24 Dec 2014 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/importing-python-modules/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 目的 いくつかのモジュールからなるパッケージを作成した場合、インポート時にフォルダ名(パッケージ名)、 ファイル名(モジュール名)、インポートする関数やクラス名を書く必要があり import 文が長くなる。 これらを短くしたい。もしくは、モジュールを跨いでデフォルト設定でインポートしたい。
Python におけるインポートの仕様 ここ によると、 &amp;gt; import されたモジュール名は import を行っているモジュールのグローバルなシンボルテーブルに置かれます。import 文には、あるモジュール内の名前を、import を実行 しているモジュールのシンボルテーブル内に直接取り込むという変型が あります。(from..import..)
とのことなので、__init__.py で import を行うと，パッケージを import するだけで，__init__.py 内で import したシンボルを利用できる．
例えば，
/foo - __init__.py - bar.py  というフォルダ構成で、
$ cat bar.py PIYO=100 $ cat __init__.py from bar import PIYO  とした場合、import foo で，foo.PIYO が利用できる．これを使えばモジュール内での複雑な実装を隠してライブラリを提供できる。</description>
    </item>
    
    <item>
      <title>Requests で Docker Remote API にアクセスする</title>
      <link>https://www.jkawamoto.info/blog-ja/docker-remote-api-from-requests/</link>
      <pubDate>Fri, 12 Dec 2014 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/docker-remote-api-from-requests/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 概要 Python Requests から Docker Remote API を利用したい． 暗号化を行えば TCP からでも利用できるが，API を同じホストから利用することを考えているため unix ソケットを使う．
Unix ソケットの読み書き Docker のソケットファイルは /var/run/docker.sock にある．ソケットファイルの読み書きは，次の通り．
import socket s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) s.connect(&amp;quot;/var/run/docker.sock&amp;quot;) # s.recv, s.send, etc.  Requests で独自ソケットを使う こちらはかなり面倒で，Transport Adapterを実装する必要がある．そして，そのためには，PoolManager，HTTPConnectionPool，HTTPConnection も合わせて実装する必要がある．
import socket import requests from requests.adapters import HTTPAdapter from requests.packages.urllib3 import PoolManager, HTTPConnectionPool from httplib import HTTPConnection class MyAdapter(HTTPAdapter): def __init__(self, sockfile, **kwargs): self._sockfile = sockfile super(MyAdapter, self).</description>
    </item>
    
    <item>
      <title>Bash で IP と PORT 番号を取得</title>
      <link>https://www.jkawamoto.info/blog-ja/qiita-2014-12-10/</link>
      <pubDate>Wed, 10 Dec 2014 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/qiita-2014-12-10/</guid>
      <description>  本稿は Qiita 投稿記事 のバックアップです．
 docker run コマンドの link オプションで受け取った環境変数を bash スクリプト内で解析する。
#!/bin/bash URL=tcp://127.0.0.1:80 IPPORT=${URL#*//} # IP echo ${IPPORT%:*} # Port echo ${IPPORT#*:}  参考  shとbashでの変数内の文字列置換など | ろば電子が詰まっている  </description>
    </item>
    
    <item>
      <title>Compute Engine インスタンスから Cloud Storage にアクセスする</title>
      <link>https://www.jkawamoto.info/blog-ja/use-cloud-storage-from-compute-engine/</link>
      <pubDate>Wed, 10 Dec 2014 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/use-cloud-storage-from-compute-engine/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 はじめに GCE インスタンスから Cloud Storage にアクセスしたい．プロジェクト内部からのアクセスなので OAuth 2.0 を直接用いた方法 より簡単なサービスアカウントを用いる．
認証 始めに，メタデータサーバからアクセストークンを取得する．
import json import urllib2 METADATA_SERVER = &amp;quot;http://169.254.169.254/computeMetadata/v1/instance/service-accounts&amp;quot; SERVICE_ACCOUNT = &amp;quot;default&amp;quot; req = urllib2.Request(&amp;quot;{0}/{1}/token&amp;quot;.format(METADATA_SERVER, SERVICE_ACCOUNT)) req.add_header(&amp;quot;Metadata-Flavor&amp;quot;, &amp;quot;Google&amp;quot;) data = json.load(urllib2.urlopen(req)) token = data[&amp;quot;access_token&amp;quot;] token_type = data[&amp;quot;token_type&amp;quot;]  トークンを用いたアクセス Cloud Storage へのアクセスは受け取ったトークンを使う．
オブジェクトの取得 from apiclient import discovery sp = discovery.build(&amp;quot;storage&amp;quot;, &amp;quot;v1&amp;quot;) req = sp.objects().get_media(bucket=&amp;lt;BUCKET&amp;gt;, object=&amp;lt;PATH&amp;gt;) req.headers[&amp;quot;Authorization&amp;quot;] = &amp;quot;{0} {1}&amp;quot;.format(token_type, token) res = req.execute()  サンプルコードでは oauth2_client.</description>
    </item>
    
    <item>
      <title>svg 要素を png 形式の画像に変換する</title>
      <link>https://www.jkawamoto.info/blog-ja/convert-svg-to-png/</link>
      <pubDate>Wed, 10 Dec 2014 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/convert-svg-to-png/</guid>
      <description>本稿は Qiita 投稿記事 のバックアップです．
 はじめに D3.js で作成した svg 要素を png 形式の画像に変換する方法． 注意事項として，svg 要素の大きさ (width と height) が絶対値で指定されてないといけない （つまり 100% などでは駄目）． また、テキスト要素にフォントを指定する必要がある．
フォントの指定の例
obj.attr(&amp;quot;font-family&amp;quot;, &amp;quot;sans-serif&amp;quot;) .attr(&amp;quot;font-size&amp;quot;, &amp;quot;14px&amp;quot;) .attr(&amp;quot;fill&amp;quot;, &amp;quot;black&amp;quot;)  実際の変換 方針は，svg 要素の中身をデータ URI スキームで表し，canvas 要素に読み込ませる．
// #svg1: ターゲットの svg 要素 var width = $(&amp;quot;#svg1&amp;quot;).width() var height = $(&amp;quot;#svg1&amp;quot;).height() $(&amp;quot;body&amp;quot;).append(&amp;quot;&amp;lt;canvas id=&#39;canvas1&#39; class=&#39;hidden&#39; width=&amp;quot; + width + &amp;quot; height=&amp;quot; + height +&amp;quot;&amp;gt;&amp;lt;/canvas&amp;gt;&amp;quot;) var canvas = $(&amp;quot;#canvas1&amp;quot;)[0] var ctx = canvas.</description>
    </item>
    
    <item>
      <title>Upstart で Docker コンテナを起動</title>
      <link>https://www.jkawamoto.info/blog-ja/starting-docker-container-via-upstart/</link>
      <pubDate>Sat, 08 Nov 2014 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/starting-docker-container-via-upstart/</guid>
      <description>合っているのかイマイチ分かっていないけれど，下記の方法でとりあえず動いていると思う．
start on filesystem and started docker.io stop on runlevel [!2345] respawn respawn limit 5 5 pre-start script # 古いコンテナが残っていたら削除 OLD=`docker ps -a | grep “foo&amp;quot; | cut -d &amp;quot; &amp;quot; -f 1` if [ $OLD ]; then /usr/local/bin/docker kill $OLD /usr/local/bin/docker rm $OLD fi end script exec /usr/local/bin/docker run —name=foo -v /data:/var/data bar:latest  </description>
    </item>
    
    <item>
      <title>Systemd の設定</title>
      <link>https://www.jkawamoto.info/blog-ja/systemd-configurations/</link>
      <pubDate>Thu, 25 Sep 2014 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/systemd-configurations/</guid>
      <description> マウントユニット ファイルシステムのマウントを設定する． ユニットファイルはマウントポイントによって決まり拡張子は .mount．例えば，/var/data にマウントする場合， ユニットファイル名は var-data.mount と / を - に置き換える．パスに - が含まれている場合はエスケープする．
NFS を用いてマウントする例 [Unit] Description=some network hdd [Mount] What=192.168.0.5:/data Where=/var/data Type=nfs Options=nolock [Install] WantedBy=multi-user.target  サービスユニット Docker 用サービスを起動する設定．docker イメージの作成から行えるが，今回は既にあるイメージを起動する．
[Unit] Description=Apache2 After=docker.service var-data.mount Requires=docker.service var-data.mount [Service] TimeoutStartSec=0 ExecStartPre=-/usr/bin/docker kill apache2 ExecStartPre=-/usr/bin/docker rm apache2 ExecStart=/usr/bin/docker run --name apache2 -v /var/data:/var/www/html:rw -p 80:80 apache2:latest ExecStop /usr/bin/docker stop apache2 [Install] WantedBy=multi-user.target  ユニットの有効化 $ sudo systemctl enable /etc/systemd/system/var-data.mount  参考書籍  </description>
    </item>
    
    <item>
      <title>XSLT にてノード名別に処理を切り替える</title>
      <link>https://www.jkawamoto.info/blog-ja/switching-action-in-xslt/</link>
      <pubDate>Tue, 23 Sep 2014 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/switching-action-in-xslt/</guid>
      <description> for-each 要素 + when 要素で対応しようとしていたがうまく行かなかった． XPath にてノード名を比較する方法が無いため？
XSLT 的には apply-templetes 要素を使うのが正しいかと思われる．
参考書籍  </description>
    </item>
    
    <item>
      <title>パブリックデータセット</title>
      <link>https://www.jkawamoto.info/blog-ja/public-dataset-list/</link>
      <pubDate>Sun, 13 Jul 2014 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/public-dataset-list/</guid>
      <description>パブリックデータセットまとめページのリスト。
 Datasets for Data Mining and Data Science Amazon Public Datasets Some Datasets Available on the Web  </description>
    </item>
    
    <item>
      <title>個人情報の固まり</title>
      <link>https://www.jkawamoto.info/blog-ja/lots-of-private-information/</link>
      <pubDate>Sun, 13 Jul 2014 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/lots-of-private-information/</guid>
      <description>電話長などで公開されているデータだと思うけれど，住所氏名電話番号が簡単に手に入るウェブページ．
 住所でポン！2012  </description>
    </item>
    
    <item>
      <title>プライバシ保護データマネジメント関連のプロジェクト</title>
      <link>https://www.jkawamoto.info/blog-ja/ppdm-projects/</link>
      <pubDate>Sat, 12 Jul 2014 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/ppdm-projects/</guid>
      <description>プライバシ保護データマネジメント関連のプロジェクト
 OpenPDS 情報銀行コンソーシアム  </description>
    </item>
    
    <item>
      <title>PDF から EPS への変換</title>
      <link>https://www.jkawamoto.info/blog-ja/converting-pdf-to-eps/</link>
      <pubDate>Sun, 09 Mar 2014 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/converting-pdf-to-eps/</guid>
      <description>brew install xpdf pdftops -eps hoge.pdf piyo.eps  フォントの問題がある場合は，
cd /usr/local/ghostscript sudo ln -s ./9.07/Resource/Font ./font  と /usr/local/etc/xpdfrc を編集してフォント設定のコメントを有効にする．</description>
    </item>
    
    <item>
      <title>伊豆さんの楕円曲線暗号資料</title>
      <link>https://www.jkawamoto.info/blog-ja/lecture-notes-of-cryptography/</link>
      <pubDate>Tue, 11 Feb 2014 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/lecture-notes-of-cryptography/</guid>
      <description>どこで公開されていたのか忘れやすいのでメモ．
 http://researchmap.jp/mulzrkzae-42427/#_42427  </description>
    </item>
    
    <item>
      <title>Windows8 でネットワーク名を変更する</title>
      <link>https://www.jkawamoto.info/blog-ja/windows8-networkname/</link>
      <pubDate>Mon, 16 Dec 2013 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/windows8-networkname/</guid>
      <description>コンテキストメニューに「名前変更」を付ければ良いだけのことなのに， かなり面倒な手続きを踏まないと変更できない．
まず，コントロールパネルから管理ツールを開き，ローカルセキュリティポリシーを起動． ネットワークリストマネージャの中に接続先のリストがあるので，変更したい接続のプロパティを開いて変更する．
しかし，これ名前変更ではなくてエイリアスを作っているだけな気がする． ローカルセキュリティポリシー上では，「ネットワーク 2」 や「ネットワーク 3」のままで， どこの設定か分かりにくいし「説明」欄は変更できないようす．酷い設計である．</description>
    </item>
    
    <item>
      <title>python で RSS フィードを読む</title>
      <link>https://www.jkawamoto.info/blog-ja/reading-rss-by-python/</link>
      <pubDate>Thu, 12 Dec 2013 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/reading-rss-by-python/</guid>
      <description>feedparser が良さそう</description>
    </item>
    
    <item>
      <title>Deep Learning ライブラリのリンク集</title>
      <link>https://www.jkawamoto.info/blog-ja/deep-learning-libraries/</link>
      <pubDate>Mon, 09 Dec 2013 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/deep-learning-libraries/</guid>
      <description> deeplearning.net  </description>
    </item>
    
    <item>
      <title>改行をカンマに置換</title>
      <link>https://www.jkawamoto.info/blog-ja/replacing-newlines/</link>
      <pubDate>Tue, 06 Aug 2013 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/replacing-newlines/</guid>
      <description>sed で変換するのは色々面倒で，ここによると，
$ tr &#39;\n&#39; &#39;,&#39; &amp;lt; filename  が一番簡単．</description>
    </item>
    
    <item>
      <title>R でのパッケージインストール</title>
      <link>https://www.jkawamoto.info/blog-ja/installing-r-package/</link>
      <pubDate>Wed, 12 Jun 2013 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/installing-r-package/</guid>
      <description>もっと良い方法があるのかも知れないが・・・． ChangeAnomalyDetection パッケージをインストールする場合，ルートで R を起動し
install.packages(&amp;quot;ChangeAnomalyDetection&amp;quot;)  を実行する． 依存パッケージがあるとエラーが出るので， そのエラーで必要と言われたパッケージを同様の方法でインストールしてから再度インストールする．</description>
    </item>
    
    <item>
      <title>某 BibTeX スタイルで DOI を非表示にする</title>
      <link>https://www.jkawamoto.info/blog-ja/disable-doi/</link>
      <pubDate>Tue, 16 Apr 2013 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/disable-doi/</guid>
      <description>DOI を参考文献リストに載せたくない場合，bstファイルの以下の部分
FUNCTION {format.doi.url} { doi empty$ { url empty$ &#39;skip$ { format.online output.nonnull format.url } if$ } { format.online output.nonnull &amp;quot;\doi{&amp;quot; doi &amp;quot;}&amp;quot; * * } if$ }  を
FUNCTION {format.doi.url}{}  としておけば良い．</description>
    </item>
    
    <item>
      <title>Hadoop CDH4 で hadoop-env.sh が見つからない</title>
      <link>https://www.jkawamoto.info/blog-ja/hadoop-cdh4-missing-hadoop-env-sh/</link>
      <pubDate>Tue, 19 Mar 2013 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/hadoop-cdh4-missing-hadoop-env-sh/</guid>
      <description>入れ忘れていただけみたいなので，ここからダウンロードして conf 以下におけば良い．</description>
    </item>
    
    <item>
      <title>MSRA 公開の移動履歴データセット</title>
      <link>https://www.jkawamoto.info/blog-ja/msra-open-dataset/</link>
      <pubDate>Thu, 14 Mar 2013 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/msra-open-dataset/</guid>
      <description> GeoLife GPS Trajectories  Last.fm データセット
 Last.fm dataset 360K Last.fm Dataset - 1K users  </description>
    </item>
    
    <item>
      <title>matplotlib で日本語を使う</title>
      <link>https://www.jkawamoto.info/blog-ja/matplotlib-in-japanese/</link>
      <pubDate>Wed, 13 Mar 2013 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/matplotlib-in-japanese/</guid>
      <description> 日本語フォントのインストール  Takao Fonts を Python\Lib\site-packages\matplotlib\mpl-data\fonts\ttf へ．  設定ファイルの編集
 Python\Lib\site-packages\matplotlib\mpl-data\matplotlibrc を ~/.matplotlib/ にコピー FONT セクションに下記を追加 (もちろん別のフォントを使う場合はそちらを指定)
font.serif : TakaoPMincho font.sans-serif : TakaoPGothic   フォントキャッシュの削除
 ~/.matplotlib/fontList.cache を削除    </description>
    </item>
    
    <item>
      <title>Python ライブラリ</title>
      <link>https://www.jkawamoto.info/blog-ja/windows-python-library/</link>
      <pubDate>Fri, 01 Mar 2013 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/windows-python-library/</guid>
      <description>Windows 用のライブラリは，ここ から探す． (64bit 用に自前でコンパイルするには VC コンパイラが要るため)</description>
    </item>
    
    <item>
      <title>pdfoutput が定義されていない問題</title>
      <link>https://www.jkawamoto.info/blog-ja/not-found-pdfoutput/</link>
      <pubDate>Fri, 01 Mar 2013 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/not-found-pdfoutput/</guid>
      <description>某 LaTeX スタイルファイルを使ったとき， pdfoutput が定義されていないと言われてコンパイルが通らない． とりあえず，
\def\pdfoutput{0}  と書いておけば，エラーは消える． 本当は別のパッケージやオプションで設定すべきだとは思うが・・・．</description>
    </item>
    
    <item>
      <title>macで256色表示可能な screen をコンパイル</title>
      <link>https://www.jkawamoto.info/blog-ja/compiling-screen-256/</link>
      <pubDate>Fri, 29 Jun 2012 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/compiling-screen-256/</guid>
      <description>下記のコマンドを実行する．
git clone git://git.savannah.gnu.org/screen.git cd screen/src ./autogen.sh ./configure --enable-colors256 make sudo make install  上記を実行するために，automake が必要．これは，brew でインストールできる．（以下は，autoconf もインストールする例）
sudo brew install autoconf sudo brew install automake  256色表示できているかの確認は，256colors2.pl で行える．</description>
    </item>
    
    <item>
      <title>Aspell を用いたスペルチェック</title>
      <link>https://www.jkawamoto.info/blog-ja/aspell-from-emacs/</link>
      <pubDate>Tue, 06 Mar 2012 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/aspell-from-emacs/</guid>
      <description>emacs コマンドリスト
 M-$ (ispell-word): カーソルの位置にある単語のチェック M-x ispell-region: リージョン内のスペルチェック M-x ispell-buffer: バッファ内すべての単語のチェック M-x ispell: 範囲選択されていれば範囲内の，そうでなければバッファ内のチェック M-x ispell-complete-word: カーソルの位置にある単語の補完  スペル候補表示中のコマンドは，
 x: 選択一覧から抜ける q: Aspellのプロセスを中断  </description>
    </item>
    
    <item>
      <title>GNU Make を入手する</title>
      <link>https://www.jkawamoto.info/blog-ja/getting-gnu-make/</link>
      <pubDate>Tue, 06 Mar 2012 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/getting-gnu-make/</guid>
      <description>GetGunWin32をここからダウンロードする．
GetGunWin32.exe を実行すると，GetGnuWin32フォルダが作られる． GetGnuWin32\download.bat を実行して必要なパッケージをダウンロードする．
ダウンロードが完了したら，GetGnuWin32\install.bat を実行する． ここでインストール先を指定できる．
あとは，環境変数にインストール先を追加すれば良い．</description>
    </item>
    
    <item>
      <title>プロキシ環境から magit で pull する</title>
      <link>https://www.jkawamoto.info/blog-ja/pull-via-proxy/</link>
      <pubDate>Tue, 06 Mar 2012 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/pull-via-proxy/</guid>
      <description>PuTTY が設定してあれば，msysgit の bin/ssh.exe を PuTTY の plink.exe に置き換えれば良い．</description>
    </item>
    
    <item>
      <title>WebCGIRoleでPHPを使う</title>
      <link>https://www.jkawamoto.info/blog-ja/php-in-webcgirole/</link>
      <pubDate>Thu, 10 Feb 2011 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/php-in-webcgirole/</guid>
      <description>基本的な設定は，ここを参考にすれば良い． しかし，Azure Cloud Tools 1.3 を使用している場合，HTTP 500 Internal Server Error が出ることがある． この場合，ServiceDefinition.csdef の &amp;lt;Sites&amp;gt; 要素を削除する必要があるらしい．
&amp;lt;WebRole name=&amp;quot;WebCgiRole1&amp;quot; enableNativeCodeExecution=&amp;quot;true&amp;quot;&amp;gt; &amp;lt;!-- &amp;lt;Sites&amp;gt; &amp;lt;Site name=&amp;quot;Web&amp;quot;&amp;gt; &amp;lt;Bindings&amp;gt; &amp;lt;Binding name=&amp;quot;Endpoint1&amp;quot; endpointName=&amp;quot;Endpoint1&amp;quot; /&amp;gt; &amp;lt;/Bindings&amp;gt; &amp;lt;/Site&amp;gt; &amp;lt;/Sites&amp;gt; --&amp;gt; &amp;lt;Endpoints&amp;gt; &amp;lt;InputEndpoint name=&amp;quot;Endpoint1&amp;quot; protocol=&amp;quot;http&amp;quot; port=&amp;quot;8080&amp;quot; /&amp;gt; &amp;lt;/Endpoints&amp;gt; &amp;lt;Imports&amp;gt; &amp;lt;Import moduleName=&amp;quot;Diagnostics&amp;quot; /&amp;gt; &amp;lt;/Imports&amp;gt; &amp;lt;/WebRole&amp;gt;  参考: Avkash Chauhan’s Blog</description>
    </item>
    
    <item>
      <title>mod_python と mod_filter でフィルタを登録する際の注意</title>
      <link>https://www.jkawamoto.info/blog-ja/mod_python-and-mod_filter/</link>
      <pubDate>Tue, 16 Nov 2010 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/mod_python-and-mod_filter/</guid>
      <description>Apache 2.2 で mod_python と mod_filter を用いてフィルタを作成する際の注意というかバグ． Python スクリプトをフィルタとして使う場合，まず，python 関数をフィルタプロバイダ</description>
    </item>
    
    <item>
      <title>historic と historical の違い</title>
      <link>https://www.jkawamoto.info/blog-ja/historic-vs-historical/</link>
      <pubDate>Thu, 04 Nov 2010 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/historic-vs-historical/</guid>
      <description>今日，TLに，
 民主党大敗を報じる The Washington Timesの見出しはThe Democrats are on the verge of a historical defeat。 やはり格落ちの所はhistoricとhistoricalを使い分けられないようで。 (@hinatakiyoto)
 というツイートがあって，historic と historical の違いが気になったので調べてみた（正確には聞いてみた）． 詳細は，
 Historic and historical have different usages, though their senses overlap. Historic refers to what is important in history: the historic first voyage to the moon. It is also used of what is famous or interesting because of its association with persons or events in history: a historic house.</description>
    </item>
    
    <item>
      <title>m2eclipse を使って scp でデプロイ</title>
      <link>https://www.jkawamoto.info/blog-ja/scp-with-m2eclipse/</link>
      <pubDate>Thu, 04 Nov 2010 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/scp-with-m2eclipse/</guid>
      <description>Maven2 のプライベートリポジトリを作成し， 公開鍵認証を行う scp プロトコルを用いて eclipse の m2eclipse プラグイン からデプロイする設定のメモ． なお，m2eclipse version 0.10.0 に含まれる Maven 3.0-SNAPSHOT では scp 認証に失敗する． 別途 Maven 2 系を ダウンロード して，eclipse のウインドウ → 設定 → Maven → インストールに追加しデフォルトに設定しておく必要がある．
準備が整えば，scp でアクセスする Maven リポジトリの作成から始める．作成するリポジトリの ID 及び，URL は次の通りとする．
 ID: foo.org リポジトリ URL: scp://foo.org/var/maven2/repo スナップショットリポジトリ URL: scp://foo.org/var/maven2/reposnap  つまり，/var/maven2/repo と /var/maven2/reposnap 以下にそれぞれのリポジトリ内容物を格納する． そのため，リポジトリを利用するユーザに /var/maven2/repo と /var/maven2/reposnap への読み書き権限を与える．
scp プロトコルを使用するためには，wagon-ssh エクステンションが必要となるので，pom.xml の build – extendsions に以下を追加する．
&amp;lt;build&amp;gt; &amp;lt;extension&amp;gt; &amp;lt;groupId&amp;gt;org.apache.maven.wagon&amp;lt;/groupId&amp;gt; &amp;lt;artifactId&amp;gt;wagon-ssh&amp;lt;/artifactId&amp;gt; &amp;lt;version&amp;gt;1.</description>
    </item>
    
    <item>
      <title>ホームディレクトリを暗号化すると公開鍵認証でログインできない</title>
      <link>https://www.jkawamoto.info/blog-ja/encrypt-home/</link>
      <pubDate>Wed, 03 Nov 2010 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/encrypt-home/</guid>
      <description>Ubuntu 10.04 (lucid)で，深く考えずにホームディレクトリを暗号化してしまった結果， ssh の公開鍵認証ログインができなくなった． というか，ローカルコンソールでログイン済みの時は問題なく ssh でもログインできるが， ローカルでログインしていないと認証に失敗するようになった． よく考えれば，ホームディレクトリに置いている公開鍵を sshd が読めないので認証に失敗するのは当然である．
bear.mini : Ubuntu 9.10 (Karmic Koala) でホームディレクトリを暗号化すると、ssh で公開鍵認証ログインが出来ない問題（解決） や MacBookの憂鬱日記 : sshの設定 その２　っていうか、追記 を参考に，次のようにして解決．
まず，暗号化されていないディレクトリに公開鍵を配置（今回は，/home/.ecryptfs/USERNAME/.ssh/authorized_keys を選んだ） そして，鍵置き場と公開鍵のパーミション設定（/home/.ecryptfs/&amp;lt;username&amp;gt;/.ssh は 700, authorized_keys は 600）． 最後に，sshd_config の編集．具体的には，AuthorizedKeysFile の部分を次のように変更．
AuthorizedKeysFile /home/.ecryptfs/%u/.ssh/authorized_keys  </description>
    </item>
    
    <item>
      <title>Servlet で Velocity (1.6.4) を使う</title>
      <link>https://www.jkawamoto.info/blog-ja/servlet-velocity/</link>
      <pubDate>Tue, 05 Oct 2010 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/servlet-velocity/</guid>
      <description>Servlet で Velocity を使用する場合，org.apache.velocity.runtime.log.ServletLogChute エラーが出ることがある． これは，デフォルトログシステムの初期化に失敗しているからで，ServletContext を渡すか別のログシステムを使えば解決する．
ServletContext を渡す場合，次のようにすれば良い．
VelocityEngine engine = new VelocityEngine(); engine.setApplicationAttribute( ServletContext.class.getName(), servletContext); engine.init();  また，別のログシステムを使用する場合は，runtime.log.logsystem.class プロパティに設定する．
 参考: Apache  </description>
    </item>
    
    <item>
      <title>Arm 用 OpenJDK で Selector#select の挙動がおかしい</title>
      <link>https://www.jkawamoto.info/blog-ja/arm-jdk-selector/</link>
      <pubDate>Wed, 22 Sep 2010 00:00:00 +0000</pubDate>
      <author>junpei.kawamoto@acm.org (Junpei Kawamoto)</author>
      <guid>https://www.jkawamoto.info/blog-ja/arm-jdk-selector/</guid>
      <description>ARM 用の OpenJDK VM (OpenJDK Core VM) では， 選択できるキーが有ろうが無かろうが一つのキーも選択せずに Selector#select() が即座に返る． そして CPU 使用率がどんどん上がっていく．
final Selector sel = Selector.open(); final ServerSocketChannel s = ServerSocketChannel.open(); s.configureBlocking(false); s.socket().bind(address); s.register(sel, SelectionKey.OP_ACCEPT); while(true){ // nc は常に 0 final int nc = sel.select(); for(final SelectionKey key : sel.selectedKeys()){ if(key.isAcceptable()){ // 適当に accept する ((ServerSocketChannel)key.channel()).accept(); } } }  選択できるキーが無い場合はともかく，実際に繋ぎに来ている場合でも無視されるので使い物にならない． なお，別の VM (OpenJDK Zero VM) に切り替えたところ正常に動いた．</description>
    </item>
    
  </channel>
</rss>