たまにはプログラミングではなく、ロードバイクの話。

といってもライドではなく通販について。

ざっくり言うと、Wiggleで注文しても全然荷物が来ない場合の対処方法。ただしお問い合わせ番号(追跡番号、Tracking Code)がある場合に限る。

Sugilogのケース

  • Wiggleでの購入実績:ある。
  • 送り先の住所:前回購入時から変更なし。
  • 購入したもの:冬用ジャージ上下。2万円くらい。
  • 配送オプション:日本まで追跡番号付き配送

配達状況

  • 2015/12/13 : 注文、同日中に配送処理完了。
  • 2015/12/14 : 配達業者(Parcel Force)で受付完了、発送。
  • 2015/12/18 : 中国に到着。
  • ... その後消息を断つ。

問い合わせ状況

  • 2015/12/21 : Wiggleに荷物が来ないことを問い合わせ。確認する旨連絡がきて、その後連絡なし。
  • 2015/12/22 : Wiggleに問い合わせの返信を催促。配達業者(Parcel Force)に催促したとの連絡。
  • 2015/12/24 : 郵便局の国際郵便窓口に問い合わせ。郵便局ではわからないから税関に問い合わせして欲しいと言われる。
  • 2015/12/25 : 東京税関の国際郵便の窓口に問い合わせる。税関ではわからないから国際郵便局に問い合わせして欲しいと言われる。
  • 2015/12/25 : 東京国際郵便局に問い合わせる。確認の結果、中国に配達されて住所不明で返送処理がされていることがわかる。
  • 2015/12/25 - ... : Wiggle.co.ukに問い合わせ中。

どうして配達がされないか?

  • はっきりとした原因は不明。
  • 東京国際郵便局の人の仮説は2つ。
    1. 荷物のラベルに書かれた住所が間違っているケース。
    2. イギリスの配達業者が漢字の住所を中国宛だと思って送ってしまったケース。

問い合わせ先別でわかること

Wiggle.jp

日本語の窓口担当者が、イギリスと連絡をとってくれる感じ。

今回は、結果論ではあるが、十分な確認をしてもらえなかった。

Wiggle.co.uk

現在問い合わせ中。12/25はクリスマス休暇でガッツリ休みに入ってるらしい。

英語での問い合わせになるけど、たしかな情報が得られるはず(期待も込めて)

郵便局の国際郵便窓口

https://www.post.japanpost.jp/int/question/tel.html

お問い合わせ番号からなんとなくな情報を教えてもらえる程度。案内は丁寧。

イレギュラーなケースだと範疇を超えるっぽい。

東京税関の郵便窓口

http://www.customs.go.jp/tokyo/yuubin/yubinmadoguchi.htm

税関での状況を教えてもらえる。

東京税関でめちゃくちゃに荷物が届いて、仕事が滞っているのか、とか。

税関に入ってきたものはだいたいすぐにチェックはされるみたいなので、追跡していて東京税関が書かれていなければ、東京税関までそもそも届いてない可能性が高いらしい。

案内は丁寧にしてもらえる。

東京国際郵便局

https://www.post.japanpost.jp/cgi-shiten_search/shiten.php?id=5559

お問い合わせ番号を伝えれば、荷物の状況を確認してもらえる。

Sugilogのケースで言えば中国で返送処理がされてる、みたいなことを教えてもらえる。

1時間かけてやっと電話が繋がるレベル。根気が必要。電話がかかってしまえば、最も正しい情報にありつける可能性が高い。

なぜかホームページにはフリーダイヤルしか書かれていない。携帯電話からだとつながらない。

勝手に電話番号書くのもまずいのでここでは書かないけど、税関の窓口の人は教えてくれた。

荷物の実際の宛先がどこであったか、みたいな情報は確認できない。あくまで配達状況のみ。

今回からの学び

Wiggleは荷物の配送には責任をもっていない(と思われる)。

  • 6日で付くはずの荷物が全然届いていなくても気に留めていない。
  • 問い合わせをうけても、荷物の状況がどうなっているのかを確認していない。配達業者に催促するレベルまで。

イギリスから中国を経由して日本に配達されることはまずないらしい。

  • 中国でトランジットしてるの?変だな?と思った時点で問い合わせないといけなかった。
  • 配達は6日前後くらいかかるからまぁいいよね、みたいに思っていたことも購入者としての責任感もなかったのかもしれない。

クリスマスとか外国の人ががっつり休みそうなころの通販は危うい。

  • 問い合わせに対するレスポンスが、やばいくらい遅くなる。
  • はやめはやめのコンタクトを。

AWSのLambdaでyield(だめでした)

AWSのlambdaでnodejsを使って、並列処理&直列処理をうまく扱えないかと思ってテスト。

Promisecoを使いたい。

...

失敗。。。

正確に言うと、Promiseとcoというか、直列処理のyieldを書くときのfunction *()な構文がエラーしてる。

ということで確認。

var exec = require("child_process").exec;

exports.handler = function(event, context) {
  exec("node --version", function( _1, stdout, _2 ) {
      console.log( stdout );
      context.succeeded( stdout );
  });
};

答え:v0.10.36

だめでした。(2015.08.24の僕のアカウント)

きっとどこかにnodeのバージョンもかいてあるんでしょうね。僕は見落としが多い男です。

fluentd pluginを作ってみて

最近elasticsearchやらfluentdやらのことについて勉強していて、理解が浅いことに気づいたので、とりあえずfluentdのpluginを作ってみた。

fluent-plugin-nested-hash-filter | RubyGems.org | your community gem host

作ってみて気づいたことをメモ的にまとめておく。間違っていることもおおいにあるだろう。

テストはtest-unit

rspecも使えるらしい記事はいろいろ出ているけど、guardを併用するとなんか色々めんどくさい(というか諦めた)。

その煩わしさを味合うのは、rspecを使って気持よく開発をする目的に反するきがしたので、test-unitを使うことにした。

そもそもfluentdがベーシックにサポートしているのがtest-unitだから、まぁいいんじゃないか、と。

普通のrubygemsとは異なるディレクトリ構造

普通なら、lib/{gem_name}.rbを作ってメインでrequireさせるソースを用意して、追加のライブラリはさらにlib/{gem_name}/...につくってくと思う。

fluentd用のソースは、基本がlib/fluent/plugin/の下に作っていく。一つのプラグインでinputとoutputをそれぞれ提供するなら、lib/fluent/plugin/の下に2つ(以上)のソースファイルができることになる。

名前空間を切っておこうとか、あまり考えないほうが楽そう。

fluentdに登録するプラグインのtype

登録するプラグインの種類と、typeの名前、そのソースファイル名は連動している。

https://github.com/fluent/fluentd/blob/master/lib/fluent/plugin.rb

   def try_load_plugin(name, type)
      case name
      when 'input'
        path = "fluent/plugin/in_#{type}"
      when 'output'
        path = "fluent/plugin/out_#{type}"
      when 'filter'
        path = "fluent/plugin/filter_#{type}"
      when 'buffer'
        path = "fluent/plugin/buf_#{type}"
      else
        return
      end
   end

そこんとこ自分は、ドキュメントで読み飛ばしていたかもしれなくて、プラグインが読み込まれないと言って、時間を使ってしまった。

outputプラグインをfilter的に使う場合

タグの名前を変更できるようにするなり、何か工夫しないと、タグの名前が常に同一になるため、ループしてしまう。

今回は、タグ名にプレフィックスをつけてもらうようにしてみた。

Vagrantを使って検証環境を作る

VagrantVirtualBoxだったりEC2だったりをセットアップから起動まで簡単(?)にできるっぽいのでやってみた。

途中ハマりまくったので、徒然にメモを残しておくレベルでご勘弁。

リポジトリ

https://github.com/sugilog/vagrant.local

環境

クライアント: Mac OSX Yosemite 10.10.3

VirtualBox

Vagrant

  • v1.7.2
  • .dmgからセットアップ。
  • provision関連はドキュメントを参照。
  • Plugins
  • vagrant-berkshelfはとりあえず使わない。

Chef-DK

  • v0.4.0
  • Chefを使うのにこちらのほうが便利そうだったので。
  • Berkshelfもこみこみ。

EC2

手順

環境に描き上げたパッケージは予めインストール。

作業用のディレクトリを作成する。

metadata.rbを作成する。

  • Berkshelfをinitするときに必要。
  • 最低限必要なのはname 'NAME'のみ。

berks initする。

Berksfileに必要なcookbooksを追加してインストール。

  • berks vendor DIRNAME
  • chef.ioでレシピを探す。
  • 個人で使用するくらいなら、バージョンの指定は省略して良さそう。

Vagrantfileに設定を書き込む。

  • VirtualBox向けの設定
  • EC2向けの設定。
    • dummy boxの指定。
      • urlはhttps://github.com/mitchellh/vagrant-aws/raw/master/dummy.box
    • アクセスキーなどのEC2へのアクセスデータ
    • リージョンやサブネットなど設定周りのID。
    • Chefの設定
    • Provisioningするときのシェルスクリプト的な。
  • VirtualBoxとEC2向けの設定はうまく設定すれば共通化できる。
    • VirtualBoxでセットアップをテストしておけば、EC2でのセットアップを必要最小限にできる。
  • Provisioningについて
    • rootユーザーでなく実際に作業するときのユーザー向けの設定をする場合は、privileged: falseにするのを忘れずに。
  • EC2向けのアクセスキーなどの管理。
    • バージョン管理の対象から外したファイルに設定を書き込んでおいた。
    • 本当はアクセスキーのファイル管理は危ないので、環境変数からの読み込みがいいか。
  • うまく行かなかったレシピ。
    • vim
    • mysql
    • redis
    • あとで手動で入れればいいのでスルー。

vagrant up

  • まずはVirtualBox向けに。
    • Chefでうまくいかないものはどんどん外したほうが良さそう。
  • AWSはマネジメントコンソールを開きっぱなしにして、変なリージョンにインスタンスが立ち上がってないかとか、確認しながらが吉。

Vagrantの後

個人利用のみなので、いろいろ手動ですがご容赦を。

参考

先に、参考にした記事とかを。

Heroku via Dropbox; Part 2

HerokuのDropbox Syncが終了するとのこと。おせわになりました。

devcenter.heroku.com

Support for Dropbox Sync will end on 24 July 2018.


前回からの続き

Heroku via Dropbox - sugilogのブログ

やること

手順

好きなテンプレートを探す。

たとえば、Start Bootstrapで探してみる。

今回は、ここのGrayscaleなテンプレートを使います。(Download!)

ファイル設置

ダウンロードして展開したファイルの中身をDropboxディレクトリ(Herokuのサイト向けのディレクトリ)につっこむ。

lessとか本当はいらないけど、とりあえずは細かいことは気にしない。

f:id:sugilog:20150211232022p:plain

デプロイ

Herokuの管理画面からデプロイ!

f:id:sugilog:20150211232100p:plain

確認してみます。

f:id:sugilog:20150211232125p:plain

↓↓↓

f:id:sugilog:20150211232445p:plain

うまくいかない場合

デプロイして、失敗する時がある。

  • 今やっている方法だと、Herokuにphpで書かれたアプリケーションとして認識されているのだけど、phpファイルが無いと思われる(らしい)。
  • そういうときは、phpファイルに空文字を足すとかして編集保存して、わざと変更があった状態にしておくと、うまくいくかもしれない。

f:id:sugilog:20150211232353p:plain

Heroku via Dropbox

HerokuのDropbox Syncが終了するとのこと。おせわになりました。

devcenter.heroku.com

Support for Dropbox Sync will end on 24 July 2018.


Herokuのデプロイ方法に、Dropbox Syncが追加されていたらしいので、試してみる。

とりあえず、できるだけ簡単に、HTMLを設置して表示することを目指す。

前提

  • Dropboxアカウントを持っている。
    • なければ作ってください。
  • Herokuアカウントを持っている。
    • なければ作ってください。
  • なんか、シングルページのHTMLで、何かしら公開したい人。
    • プログラムを組む気はないし、Facebookとかで公開してればいいし、ぐらいな人。
  • HTMLを少しいじれる人。

Gitを使わなくて良くなるので、簡単なことはHerokuで、無料でできちゃう、とか思ってます。

手順

Herokuで新しくAppを作成する。

App = 新しいサイト、ということで、まずは設置場所をつくる。

ログインをして

f:id:sugilog:20150211192538p:plain

右上の「+」のリンクをクリックして

f:id:sugilog:20150211192548p:plain

Appの名前(サイト名っぽいのん)を入力する。

ここで入力した内容は、デフォルトでのサブドメインになる。

Dropboxと連携する。

予め連携したいDropboxのウェブサイトにログインしておくと良いです。

「Deploy」タブで「Dropbox」を選んで

f:id:sugilog:20150211192554p:plain

「Connect to Dropbox」な感じで進んで

f:id:sugilog:20150211192546p:plain

連携を承認して

f:id:sugilog:20150211192555p:plain

おわりです。

Dropboxをみると、Dropbox > Apps > Heroku > (入力したApp名)ディレクトリが作られる。

f:id:sugilog:20150211192545p:plain

ファイル設置

ここだけ、自分のパソコンで作業。

f:id:sugilog:20150211192551p:plain

ここでは、index.htmlindex.phpの2つのファイルを設定してみます。 Dropbox > Apps > Heroku > (入力したApp名)ディレクトリの下に置く感じ。

HerokuにDropbox経由でStaticなファイルを設置してみる

デプロイ

HerokuのDropbox Syncは自動的にデプロイされるわけではないので、Herokuの管理画面から作業が必要です。

  • おかげで、Dropboxにファイルを設置したまま、作業ができて便利。

「Deploy」タブの「Dropbox」から

f:id:sugilog:20150211192549p:plain

「Deploy Changes」のメッセージに変更内容の要約を入力して

f:id:sugilog:20150211192552p:plain

「Deploy」押して、少し待つと完了。

f:id:sugilog:20150211192543p:plain

表示されました。

Go言語:Channelsのselect

select の話

  • selectステートメントで、複数のChannelsを条件分岐できる。
    • 受信、送信、どちらも可能。
    • Channelsの送信があるのに、受け取りを行ってなかったら、selectをしていない場合と同じで例外になるので注意。
    • 複数条件に一致する場合は、ランダムに選択される。
  • selectの中のいずれにも該当しない場合の条件をdefaultで指定可能。
    • Channelsに限定した話ではない。注意。

試してみた

Channelsのselect

実行結果

start? 1
0 0
1 1
2 1
3 2
4 3
5 5
6 8
7 13
8 21
9 34
10 55
11 89
12 144
13 233
14 377
15 610
16 987
17 1597
18 2584
19 4181
quit
0 0
1 1
2 1
3 2
4 3
5 5
6 8
7 13
8 21
9 34
10 55
11 89
12 144
13 233
14 377
15 610
16 987
17 1597
18 2584
19 4181
quit

コード中のコメントアウトしているdefault内の行を解くと、演算実行の間(繰り返されている間)に、何度もdefaultが呼び出されていることがわかる。