投稿者「baw」のアーカイブ

baw について

常時睡魔と格闘を繰り広げる暇人。

AmazonJSでアフィリエイトを始める

全く興味ありませんでしたが、知識として興味があったので試してみました。色々と大変でした。

AWSアカウントの準備

まずはamazon.comのアカウントを取得します。商品を購入するamazon.co.jpのアカウントではありません。襷に長し感は有りますが、ここで取得するアカウントはAWSのアカウントです。AWSで提供されるサービスが多すぎて意味が分からなくなります。

ルートユーザ(今取得したアカウント)でアフィリエイト用キーを発行しても良いのですが、「ルートユーザから払出した子ユーザから発行したアフィリエイト用キーを使うのが最近の流行りだよ!」とAmazonから勧められるので大人しく従います。サービスメニュー(サービスが山ほどあるので頑張って見つけてください)から「IAM(正式にはアイアムと発音)」を選択します。サイドメニュー(ダッシュボード)より「ユーザ」を選択します。新規ユーザを払出して、アクセスキーとシークレットキーを取得します。シークレットキーは後では2度と確認出来ないのでメモっておきましょう。

次に、払出した子ユーザに対して権限を付与します。ユーザ詳細ページの「アクセス許可」タブから、「ポリシーのアタッチ」をして、「AdministratorAccess」を付与します。(何の権限が最低限必要なのか、最後まで不明でした。色々組み合わせて試したのですが分からず。全権限付与しちゃうと、子ユーザを払出する意味は無いのかも。)権限が足りない場合は、後で実施するAmazonJSの使用中に下記エラーが発生します。後で分かったのですが「Amazon EC2 Container Service」権限さえあれば良いと思います。

Amazon Product Advertising APIのエラー
UnauthorizedOperation
Your AccessKeyId is not authorized to perform this operation. Please check IAM policies for the Access Key.

アソシエイトアカウントの準備

支払先等を設定するためのアカウントも個別に取得する必要があります。淡々とアカウント登録を進め、トラッキングID(日本アカウントの場合は、末尾が「-22」となります)を取得して完了です。ちなみに、銀行振替の設定だと面倒そうで、Amazonギフトとして受け取る設定だとワンクリックで設定完了しました。アカウントが正常に設定できていないと、後で実施するAmazonJSの使用中に下記エラーが発生します。

Amazon Product Advertising APIのエラー
AWS.MissingParameters
リクエストには、必要なパラメータが含まれていません。必要なパラメータには、AssociateTagなどがあります。

AmazonJSの準備

AmazonJSをインストールして設定ページで、アクセスキー、シークレットキー、アソシエイトタグを入力します。

記事の執筆画面のメニューにAmazonマークが現れており、URL入力等で簡単に記事へアフィリエイトリンクを挿入できてしまいます。折角なので、最後に最近読んで面白かった漫画のアフィリエイトを貼っておきます。

愛宕山踏破

前回から始まったハイキング記録が早速1回目で止まってしまっていました。その後、愛宕山にも登ったので更新しておきます。頂上には愛宕神社があります。

道程

  1. JR京都駅前から京都バスに乗り「清滝(終点)」まで行きます。(8:58が最終バスなので注意)
  2. 橋を渡り、鳥居をくぐると、「軽い気持ちで登るな」と厳しい道中であることを警告する看板が左手に現れます。
  3. 道中は1/40、2/40~40/40と進捗具合を掲示してくれています。従って只管歩きます。
  4. 頂上直前に門があり、くぐると愛宕神社がみえます。頂上には、下界より遅い時期にも桜が咲いていました。桜の種類が違うのか、気温が違うのか、理由は不明ですが。
  5. 逆方向のルートで下山します。小石が多く、狭くて傾斜が厳しい道中です。
  6. 山を抜けると民家が現れ、熱々に熱せされたアスファルトの道を進みます。
  7. 保津峡駅にたどり着きます。橋上に設置されており、トンネルに挟まれた駅です。最終的な目的地としてもふさわしい壮観な駅です。

道中記録

最初の鳥居

最初の鳥居


神聖そうな石が無造作に投げられている

神聖そうな石が無造作に投げられている


家みたいなのがある

家みたいなのがある


こんなのあり!?

こんなのあり!?


時期外れの桜

時期外れの桜


またここから登ります

またここから登ります


入口

入口


下山して駅付近まで歩くと橋が見える

下山して駅付近まで歩くと橋が見える


橋上に駅が設置されている様子が見える

橋上に駅が設置されている様子が見える


壮観な駅

壮観な駅

[新企画]六甲山(おいしい水コース)踏破

新企画

登った山を記録する新企画を開始します。撮影した写真を交えつつご紹介できればと思います。

趣旨

今回は、六甲山を登る過程に点在する「おいしい水」を巡るコースがあるブログで紹介されていましたので、実際に辿ってみました。初めに言っておくと、結局飲めたのは「天然炭酸水」だけです。

道程

実際に辿ってみると、2016/05/05時点では過去の台風で一部の道が崩落しており、通行禁止となってしまっておりました。そのため、残念ながら「鼓ケ滝」付近にある「高塚の清水」は飲めませんでした。

コース

目印となるポイントを記します。

  1. JR六甲道駅(付近に「六甲宮ウォーター」有)以降はひたすら北に向かって歩く。
  2. 阪急六甲駅
  3. 神戸大学のキャンパス脇(ものすごい急坂です)
  4. 六甲ケーブル下駅(駅を正面にして右に逸れる道を行きます)
  5. たくさんの老人ホーム(登山口が分かりにくいので注意してください。一見何もなさそうに見えますが、老人ホームの道をひたすら行った突き当りです)
  6. 六甲ケーブル上駅(道中ではないのでトイレ休憩等に寄り道してください)
  7. 六甲山ガーデンテラス(昼食に最適な場所です。レストランもあると言えばあります。通り抜けると左右にわかれて下り坂がありますので、右の坂を下ってください。)
  8. 極楽茶屋跡(私は発見できませんでした。かなり分かりにくいのではないかと思いますので、目印にならないかもしれません)
  9. 紅葉谷コース(ひたすら下ります。ここに「有馬四十八滝」と各滝においしい水があるようです。序盤に見える「蟇滝」「百間滝」「似位滝」「七曲滝」などは初心者の装備では危険が伴うため、私はいきませんでした。「鼓ケ滝」は公園化しているので手軽に行けるようですが、前述した通り道が封鎖されているので行けません)
  10. 封鎖口(3箇所くらい封鎖されているルートがあります。大変残念ですが迂回しましょう。「六甲ガーデンテラス」から「ずっと下り坂だ!」と思っていると、迂廻路はキッツイ上り坂となっていて心を挫かれるので注意してください)
  11. 他下山ルートと合流
  12. 杖置き場(山を下りきりアスファルトが見えてくる頃、左手にあります。右手に曲がると左右にホテルが点在しています)
  13. S字下り坂(上記アスファルトの道をしばらく行くと、左手にS字の下り坂が見えますので下ります)
  14. 炭酸泉源公園(S字下り坂を降り切る前に右手に見えます。一見、全く飲めなさそうですが、上を見上げると祠があり、その前に設置してある蛇口から天然の炭酸水を飲むことが出来ます。ぶっちゃけ、硫黄臭と鉄分臭で不味いです。珍しさだけでした……)
  15. 有馬温泉(温泉にでも入って体を休めましょう)

道中記録

なんと、最初の「おいしい水ポイント」である「六甲宮ウォーター」を見逃してしまい飲めませんでした。最初の写真は「六甲ケーブル下駅」の右脇を抜けた老人ホーム街から始まります。

老人ホームを右手と左手に見ながら突き当りに登山口があります

老人ホームを右手と左手に見ながら突き当りに登山口があります


登山口を入ったところ

登山口を入ったところ

やっと登山っぽくなってきました

やっと登山っぽくなってきました

トイレ休憩のために立ち寄った六甲ケーブル上駅

トイレ休憩のために立ち寄った六甲ケーブル上駅

六甲ガーデンテラスには昼食に最適な場所

六甲ガーデンテラスには昼食に最適な場所

ガーデンテラスから降り始めて暫くすると立てかけてある看板

ガーデンテラスから降り始めて暫くすると立てかけてある看板

最後の迂廻路は厳しい上り坂

最後の迂廻路は厳しい上り坂

これほど社会貢献するラクガキを初めて見た

これほど社会貢献するラクガキを初めて見た

蛇口から炭酸水

蛇口から炭酸水

PostgreSQLのpg_dumpで単一のfunctionのみ取得する

pg_dumpでは-tオプションで単一または複数のtable/view/sequenceを指定して定義の抽出が可能ですが、functionの指定はできません。これを解決する、裏技チックな方法が英語ページにしか掲載されていなかったので、日本語ページの一人目になるべく本記事を執筆しました。

pg_dump -Fc -s | pg_restore -P 'funcname(args)' > function_define.dmp

-sオプションでスキーマ(定義)のみを抽出します。(ここでいうスキーマとは、テーブルの完全修飾名の前半に使う名称(schema)ではないので注意。単なる定義情報(雑に言うとcreate table)のことを指します。この注意事項は本家にも記されています。ややこしいですね。)

これと–schemaオプションと混乱しないでください。”schema”という単語を異なる意味で使用しています。pg_dump

結果をパイプでpg_restoreに繋いでいます。pg_restoreはcustom形式しか処理できないため、-Fcオプションを付与しています。(デフォルトはplainです。)

-Pは名称を指定してcustomからfunctionの定義を取り出すことができます。また、pg_restoreは特に接続先データベースが指定されていない場合、標準出力にplain形式で吐き出すため、リダイレクトでファイルに出力しています。

データベース名が指定された場合、pg_restoreはそのデータベースに接続し、アーカイブを直接そのデータベースにリストアします。 データベース名が指定されなかった場合は、データベースを再構築するために必要となるSQLコマンドが含まれたスクリプトが作成されます(ファイルもしくは標準出力に書き出されます)。pg_restore

functionに引数(args)がある場合、正しい引数の数だけ、型を指定してやる必要がありますので注意が必要です。不明の場合は下記コマンドで確認できるでしょう。

pg_dump -Fp -s | less

注意事項

私の環境では2回以上-Pを指定した場合、最後に指定したfunction以外が無視されました。そのため、下記のように工夫する必要があります。

pg_dump -Fc -s | pg_restore -P 'funcname(args)' > function_define.dmp
pg_dump -Fc -s | pg_restore -P 'funcname2(args)' >> function_define.dmp
pg_dump -Fc -s | pg_restore -P 'funcname3(args)' >> function_define.dmp

最終的な出力ファイルを見ると、SETが重複して出力されていますが、特に弊害はありません。

参考

Linuxの/proc/cpuinfoからわかる情報メモ

Linuxの/proc/cpuinfoを初めてまともに読もうとしたのでメモを残しておきます。複数コアを搭載したCPUや、HT(ハイパースレッディング)により、論理プロセッサ数と物理CPU数が一致しないことがよくあります。cpuinfoを読み解いていけば、いずれも判別可能となるようです。

シンプルな構造

下記はあるサーバでcpuinfoを覗いた例です。キーワードはgrepにかけている通りです。まずは生で見てみるのも良いでしょう。コロン以降は私が説明を追記したものです。

# cat /proc/cpuinfo | grep -E "physical id|cpu cores|siblings|processor" | sort | uniq

cpu cores       : 4 ←1個の物理CPUに搭載されている"物理"コア数
physical id     : 0 ←物理CPU(1個目)
physical id     : 1 ←物理CPU(2個目)
processor       : 0 ←論理プロセッサ(=合計論理コア数:1個目)
processor       : 1 ←論理プロセッサ(=合計論理コア数:2個目)
processor       : 2 ←論理プロセッサ(=合計論理コア数:3個目)
processor       : 3 ←論理プロセッサ(=合計論理コア数:4個目)
processor       : 4 ←論理プロセッサ(=合計論理コア数:5個目)
processor       : 5 ←論理プロセッサ(=合計論理コア数:6個目)
processor       : 6 ←論理プロセッサ(=合計論理コア数:7個目)
processor       : 7 ←論理プロセッサ(=合計論理コア数:8個目)
siblings        : 4 ←1個の物理CPUに搭載されている"論理"コア数

上記を読み解くと、本サーバは物理CPUを2個搭載しており、CPUには1個あたり4個の物理コア(合計8個)搭載されていることがわかります。1コアを仮想的に2コアに見せるintelのHTが適用されないCPUであるため、物理コア=論理プロセッサとなっており、前述したとおりシンプルな構成となります。

模式図にしてみました。

シンプルなCPU

シンプルなCPU

HTが有効となっている構造

HTの環境を用意できなかったため、下記の実行結果は手で作りました。現状販売されているモデルでは、あり得ないと思います。また、不整合等あったら申し訳ないです。

# cat /proc/cpuinfo | grep -E "physical id|cpu cores|siblings|processor" | sort | uniq

cpu cores       : 1 ←1個の物理CPUに搭載されている"物理"コア数
physical id     : 0 ←物理CPU(1個目)
physical id     : 1 ←物理CPU(2個目)
processor       : 0 ←論理プロセッサ(=合計論理コア数:1個目)
processor       : 1 ←論理プロセッサ(=合計論理コア数:2個目)
processor       : 2 ←論理プロセッサ(=合計論理コア数:3個目)
processor       : 3 ←論理プロセッサ(=合計論理コア数:4個目)
siblings        : 2 ←1個の物理CPUに搭載されている"論理"コア数

物理CPUを2個搭載しており、CPUには1個あたり1個の物理コア(合計2個)が搭載されており、HTにより仮想的に2個の論理コア/プロセッサ(合計4個)となることがわかります。ポイントは、cpu coresとsiblingsの差に着目する点です。この場合、物理コア×2=論理プロセッサとなります。

HT有効モデル

HT有効モデル

スマートフォンのタッチパネルが全く反応しない場合の対処(Android)

落としたり踏んづけたりしてタッチパネルが全くきかず、反応がなくなった場合にどう対処したかメモしておきます。結論は「PC用マウスをスマートフォンに接続して操作する」です。

具体的には、USB変換アダプタを用いてUSB接続のマウスをスマートフォンに直接接続するか、もしくは、Bluetoothでワイヤレス接続するかだと思います。ただし「タップに全く反応しない」前提条件があるので、ペアリングという事前作業が必要な後者の選択肢は自ずと落ちます……。

上記以外にも、PCからリモート接続で操作をする等の選択肢もあるかのように見えますが、大概スマホ側でリモート接続を「承認(タップ)」する必要があるので、やはり落ちます。

そして最後に残るのが、前述した「USB変換アダプタを使ってUSB接続でマウス操作する」です。変換アダプタは500円程で購入できます。代替スマートフォンを買いに行く足でついでに調達してしまいましょう。

また、次の相棒はASUS製の「Zenfone2Laser」にしました。ASUSはZenbookでもお世話になっているので、元々の印象から良いです。購入後に数時間初期設定で触ってみましたが、初期IME(ATOK?)に癖がある程度で、目につく挙動や作りの悪さは見えてきませんでした。

Zenfone2Laser

Zenfone2Laser

ただし、背面パネルが開けにくすぎです。不要なカード等を隙間にねじ込んでこじ開けるしかありませんでした。加えて、デュアルSIMが可能な設計となっているため、SIM/SIM/MicroSDで差し込む場所に迷います。実際、MicroSDを誤ってSIM側に挿してハマりかけました。マニュアルは事前にキチンと読んだほうが良いですね。(書いてありました……。)

マニュアル

マニュアル

2年間使用したリチウム電池は大して劣化していない(XperiaA(SO-04E))

件名で結論が出ていますが、実際試してみたことと試してみるべきだったことを先人の知恵として書き記しておきます。

約2年半前に購入して以来、docomoからDMMmobile(MVNO)に乗り換えても使い続けていたXperiaA(SO-04E)が、いくらなんでも普段の電池消費が激しすぎる。リチウム電池の劣化だろうと言う仮説の元、とるべき行動について調査と検討をしていました。個人ブログを中心に様々な感想等を拾い集めると「リチウム電池の交換は有効」という結論に至りました。

そこで、まずは電池が本当に劣化しているのか確認しようと思いました。docomoショップに行けば、回線契約が無くとも(docomoで購入した端末であれば)無料で診断できます。(docomoヘルプデスクに問い合わせ確認済み。)ただ、ふらっとdocomoショップに行って用件を言うと「ひとまず1時間待って欲しい」と言われ、確認せずに諦めて帰ってしまいました。

ここがそもそもの間違いです。しっかり確認しておくべきでした。

Amazonで見つけた若干怪しい商品をポチると、20日もかかって遥々中国から国際郵便で届きました。まあ、元々の正規品もmade in chinaなので、あまり気にはしませんでした。

そんなこんなで種々の稼働をかけて手に入れたリチウム電池ですが、入れ替えても改善の実感を得られません。分析まではできていませんが、今更の結果論で言うと、常駐アプリをもう一度見なおすべきだったのかもしれません。2年程度ではリチウム電池は劣化しないという教訓を得られました。高い授業料です。

ちなみにその直後、SO-04Eは画面にヒビを入れてしまい、当たりどころが悪かったのかタッチパネルが死に、結局端末を買い換えるというオチまで付きました……。

LINEで友だちを擬似グループ管理する

今やインフラと言って差し支えない程に普及したLINEですが、未だに友だちのグループ管理機能は実装されません。管理・整理整頓魔として大変気持ち悪いので、擬似的にグループ管理するアイデアを記しておきます。

ポイントは「表示名」にあります。スマートフォン版LINEでは、「友だち」タブから対象をタップして、名前の横にある小さな「ペン」をタップすると変更可能です。一方、PC版LINEでは、「友だち」タブから対象を右クリックして「表示名の変更」から呼び出せます。

「表示名」の命名規約は「[擬似グループ名]_[本名]([渾名/HN])」です。例えば、ABC社2015年度入社の後輩である渡辺太郎君の渾名が「なべさん」だった場合は、「ABC2015_渡辺太郎(なべ)」とします。

これを全ての友だちに実施します。友だちは表示名でソートされますので、めでたく擬似的にグループ管理できました。

また、副産物としては、プロフィールの「名前」に渾名を設定している人も少なくないので、「誰だったっけ?」も防止できます。擬似グループの命名センス次第で便利さは増すかと思います。

同じテーブル構造で違うスキーマにデータをコピーする

違うschemaに存在する、同じ構造のtableに対して、pg_dumpでデータを抽出/挿入する方法を記します。最初にオチを言うと、\COPYを使用したほうが楽です。

環境

PostgreSQL
8.4.20
CentOS
6.7

前提条件

下記の通り、test1.testからtest2.testに対してデータをコピーします。

postgres=# \dn
        List of schemas
        Name        |  Owner   
--------------------+----------
 information_schema | postgres
 pg_catalog         | postgres
 pg_toast           | postgres
 pg_toast_temp_1    | postgres
 public             | postgres
 test1              | postgres
 test2              | postgres
(7 rows)

postgres=# \d test1.test
    Table "test1.test"
 Column | Type | Modifiers 
--------+------+-----------
 val    | text | 

postgres=# \d test2.test
    Table "test2.test"
 Column | Type | Modifiers 
--------+------+-----------
 val    | text | 

postgres=# select * from test1.test;
    val     
------------
 testvalue1
 testvalue2
 testvalue3
(3 rows)

postgres=# select * from test2.test;
 val 
-----
(0 rows)

手順

対象テーブルに対して、pg_dumpをplainでダンプします。customで色々と試してみましたが、結局徒労に終わりました。

pg_dump --file=./test.dmp --format=p --data-only --table=test1.test

plainのため、中身はviで見ることができます。

-bash-4.1$ ll
total 12
drwx------.  2 postgres postgres 4096 Jun 29 08:59 backups
drwx------. 12 postgres postgres 4096 Oct  8 22:38 data
-rw-r--r--.  1 postgres postgres  463 Oct  8 23:06 test.dmp
-bash-4.1$ cat test.dmp 
--
-- PostgreSQL database dump
--

SET statement_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = off;
SET check_function_bodies = false;
SET client_min_messages = warning;
SET escape_string_warning = off;

SET search_path = test1, pg_catalog;

--
-- Data for Name: test; Type: TABLE DATA; Schema: test1; Owner: postgres
--

COPY test (val) FROM stdin;
testvalue1
testvalue2
testvalue3
\.


--
-- PostgreSQL database dump complete
--

スキーマが書かれている箇所を手で直してしまっても構いませんが、コマンドで自動化してしまいます。

sed -i.`date "+%Y%m%d-%H%M%S"` -e 's/test1/test2/g' test.dmp

念のため、diffで確認してみます。

diff test.dmp*
12c12
< SET search_path = test2, pg_catalog;
---
> SET search_path = test1, pg_catalog;
15c15
< -- Data for Name: test; Type: TABLE DATA; Schema: test2; Owner: postgres
---
> -- Data for Name: test; Type: TABLE DATA; Schema: test1; Owner: postgres

後は普通にpsqlで流し込みます。

psql --file=test.dmp

下記の通り確認してみます。成功です。

postgres=# select * from test2.test;
    val     
------------
 testvalue1
 testvalue2
 testvalue3
(3 rows)

最後に

今回はpg_dumpにこだわってみたのですが、\COPYを使用するほうが楽だと思います。対象のテーブルをコマンド実行時に指定できますしね。

docomoからDMMmobileにMNPしました

NTTdocomoからDMMmobileにMNPしました。手順や感想をメモしておきます。端末は、Xperia A(SO-04E)を持ち込んでいます。

  1. docomoのお客様サポートからMNP申込をします。インターネットからの手続きにも関わらず、何故か営業時間(受付時間)があります。意味がわかりませんが、昼間に申し込まなければなりません。ちなみに、docomoの2年縛りは契約月+2年+1月です
  2. DMMmobileのページからMNP付きのプランを選択して、必要情報を入力します。SO-04Eの製造メーカは「ソニーモバイルコミュニケーションズ」です。「SONY」ではありませんのでご注意を。ちなみに、SO-04Eは「マイクロSIMサイズ」ですので、直接選択しても構いません。
  3. その後、本人確認書類の提出をします。具体的には、普通運転免許証をスマートフォンで撮影してアップロードすれば良いです。
  4. 数日すると、docomoの通信が何の前触れもなく切断されます。モバイルWi-Fiルータ類を持っていないと死にます。死にます。(迫真)SIMカードが郵送されてくるまで何もできなくなるので、本当に気をつけてください。
  5. 端末設定は公式マニュアル(APN設定マニュアル)の通り実施すれば良いです。
  6. SO-04Eが「docomoIDを設定しろ」とうるさく言ってくるので、docomoのお客様サポートからID変更(電話番号→メールアドレスに変更)して、端末に再設定すれば何も言ってこなくなります。
  7. デフォルトではテザリングができなくなっているため、ここの記事を参考にして、設定変更します。(SO-04Eの場合。)

私はこれで毎月の通信量がかなり安くなりました。