ShellScriptを使ってElasticsearchから10000件以上のデータを取得する方法
Elasticsearchには１度のクエリーで取得できるドキュメントの数に制限があり、通常は１度で10000件まで取得することができます。
10000件以上のドキュメントを取得したい場合はScrollを利用します。
Scrollを利用すると、サーバへの1回目のリクエストでは、クエリをボディにセットして投げますが、２度目以降は前のリクエストの応答で取得したscroll_idを用いて、データを取得します。
1回目のリクエスト
- scrollパラメータで、search contextをどれぐらいの期間有効化しておくのか指定します。search contextに指定する値は全てのデータを取得するまでに要する時間を指定しなくて大丈夫です。リクエストを投げる度に、そのリクエストに設定されたscrollパラメータの有効期間が更新されるので、前のリクエストを投げてデータを処理してから次のリクエストを投げるまでの間隔よりも長くなるように指定すれば十分です。大半のケースでは、
scroll=1mの指定で十分だと思われます。
POST /twitter/_search?scroll=1m
{
"size": 100,
"query": {
"match" : {
"title" : "elasticsearch"
}
}
}
2回目以降のリクエスト
- 1回目のリクエストのサーバからの応答で、scroll_idというパラメータを取得する事ができます。2回目以降のリクエストでは、その前の応答で取得したscroll_idの値をリクエストボディに設定する事で、10000件以上のドキュメントを順番に取得していく事ができます。
POST /_search/scroll
{
"scroll" : "1m",
"scroll_id" : "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAD4WYm9laVYtZndUQlNsdDcwakFMNjU1QQ=="
}
このように、scroll_idを継続的にリクエスト中に投げることで、10000件以上のドキュメントの場合でも取得することが出来ます。
このやり方にならって、Elasticsearchから10000件以上のデータを取得する操作を、シェルスクリプトにすると次のようになります。
- query.json
- elastisearchに投げるクエリーを記述
- search.sh
- 特定のindexからのみ検索する場合は、index変数を設定
- TODO processというコメントの箇所に抽出したデータをどうやって処理するのか記載。このsearch.shでは、result.jsonというファイルの中に応答データをそのまま書き込んでいる。
このシェルスクリプトを利用すれば、scrollを使ってElasticsearchで10000件以上のデータを取得することが出来ます。MySQLなどと違って、ちょっと工夫が必要ですね。
IoT物理ボタンのswitchbotを使って換気扇操作をタイマー式にする
うちのマンションのお風呂の換気扇にはタイマー機能はありません。だいたい寝る直前にお風呂に入って出た後に換気扇を回すのですが、この換気扇を止めるタスクがいつも煩わしく感じていました。 ベッドに入る前に換気扇を止めると、まだ湿気が抜けない。ベッドに入ってしばらく経ってから換気扇を止めに行くと目が覚める。朝まで換気扇を回していると電気代が勿体無い。そこで、この悩みを解決するためにIoT物理ボタンのswitchbotを購入しました。
switchbotは、家電製品などのスイッチをbluetoothを使って、物理的にオン・オフ出来るようにするIoT製品です。 これをお風呂の換気扇のスイッチに取り付けると、スマホから換気扇をオン・オフが出来るようになりました。取り出してすぐに使えて、プログラミングの知識は必要ありません。 うちの換気扇は、コスモワイド埋込型というタイプのスイッチですが、付属のシールを使えば問題なく動きます。
パナソニック 埋込ダブルスイッチB(片切) ホワイト パック商品 WTP50012WP
- メディア: Tools & Hardware
動画には映っていませんが、iPhoneのアプリを利用してswitchbotを動かしています。 switchbotはapple watchでも動かすことが出来るのですが、iPhoneがswitchbotとapple watchを中継する役割をしているようで、iPhoneがbluetoothでswitchbotを認識しているときしか動きません。つまり、apple watch単体ではswitchbotを動かせないので、apple watchをつけてお風呂に入っている時に、換気扇をオン・オフしようとしても近くにiPhoneがなければ動きません。
switchbotのiphoneアプリを利用すると、動作時刻を指定することが出来ます。例えば、深夜2:00に換気扇を止めるようにswitchbotを設定といったことが出来ます。これは換気扇の操作のためにあるような機能ですね。
惜しいのは、いまから何分後という指定は出来ないみたいなので、指定したい時刻が異なる場合はその度に新しい時刻設定を追加する必要があるということです。ここは、アプリのアップデートで機能追加して欲しい。
Google Homeなどのスマートスピーカーから操作する場合は、別売りのSwitchBot Hub Plus/Hub Miniを購入しないと動かないようです。
APIがあるようなので、ラズパイをいじってプログラミング出来る人であれば、ラズパイと連携してスマートスピーカー から操作できるように設定出来るかもしれません。
スマートスピーカー との連携にはHubが必要なのは残念ですが、それでもこれで換気扇を気にせずに眠れるようになったのでだいぶ楽になりました。また時間が取れたら、APIをいじってラズパイとスマートスピーカーの連携が出来ないか試してみたいと思います。
Ruby Gemのoctokitを利用してGitHub Issueを作成する
仕事でGitHub Issueを作成するRubyプログラムを書く機会があったので、必要最小限の要素だけ取り出したものをまとめてみます。
GitHub用のアクセストークンの発行
RubyプログラムからGitHub Issueを作成するには、まずGitHubのサイトから、アクセストークンを取得する必要があります。アクセストークンの取得方法は、いろんなサイトで公開されているので、適当なものを参照してください。
アクセストークンに付与する権限ですが、Issueを発行する権限がどれになるのかいまいちよく分からなかったのですが、repo Full control of private repositories にチェックを入れてアクセストークンを発行すれば、プライベートレポジトリでもIssueを作成することが出来ました。特定のレポジトリだけにこの権限を絞り込む方法も調べてみたのですが、調べた限りではよくわかりませんでした。
このアクセストークンは、GitHubの操作のための鍵となる情報なので、秘密にしておかないといけません。外部への公開は絶対してはいけません。
octokit gemのインストール
octokit gemをインストールします。octokitは、GitHub APIに繋ぐためのクライアントツールです。
gem install octokit
GitHub Issueを発行するプログラムを作成
以下は、jsonファイル(data.json)からデータを読み込んで、その読み込んだデータを利用してGitHub Issueを発行するスクリプトの例です。
- access_token には、自分のアクセストークン値を代入
- repo_name には、Issueを紐づけたいレポジトリ名を代入
- ヒアドキュメントを利用して、チケットのbody（本文）に挿入する文字列を作成
- "Greeting Message"というラベルを挿入
Rubyスクリプトの実行
これで、以下のように作成したRubyスクリプトを実行すれば、
ruby create_github_issue_sample.rb
自分の好きなレポジトリに、GitHubチケットを作成できます。
米株の外国税額控除とふるさと納税の確定申告
2年ほど前からアメリカ株の取引をしていて、配当を受けるときに引かれる現地課税とふるさと納税のために、毎年確定申告をしています。
確定申告の方法
確定申告をするときはいつも国税庁確定申告書等作成コーナーのページから、必要な情報を入力して作成した確定申告書を印刷して、必要な書類と一緒に税務署まで持って行きます。
www.keisan.nta.go.jp Macだと正しく動かないのではないかと思うかもしれませんが、意外にも、Macのsafariでも確定申告書を作成することが出来ます。 普通の会社員の場合は、所得税及び復興特別所得税の確定申告書作成コーナーから作成します。
ふるさと納税
"収入金額・所得金額入力"に収入の情報を入力して、"所得控除入力"のところで、"寄附金控除"の項目からふるさと納税の金額を入力します。 ふるさと納税の項目では、以下の画像のように入力をします。合計額をまとめて入力してもよいと説明が記載されていたので、画像のように寄付金額をまとめました。
米株の外国税額控除
"税額控除・その他の項目の入力"の"外国税額控除"の項目から外国所得税の額を入力します。自分は楽天証券の特定口座（源泉徴収あり）を利用して株を売買しているのですが、楽天証券の場合はサイトにログインして"特定口座年間取引報告書"というpdfファイルを開いて、1ページ目の"外国所得税の額"の項目を見ればどれだけ米株の配当に対して現地課税がされたのか分かります。この"外国所得税の額"に記載された金額を、以下の画像のように入力します。
（一応、これで還付は問題なく受けられたのですが、本当は、以下のブログのように、外国税額控除の計算がお済みでない方のほうで入力するのが正しいような気もします。。。ちょっとぐらい間違っていても、税務署の方でこれぐらいはいい感じに処理してくれるのかもしれないですが、このやり方を真似する場合は自己責任で。）
これで、ふるさと納税と米株の外国税額控除の入力が完了しました。税務署には、国税庁確定申告書等作成コーナーのページから作成して確定申告書の紙と、各自治体から送られてきたふるさと納税の寄附金受領証明書、楽天証券の特定口座年間取引報告書を印刷したものを持っていって提出すれば確定申告を完了出来ます。郵送だと心配だからいつも税務署まで直接持参していたのですが、書類に不備があった場合は電話で連絡してくれると教えてもらったので、来年からは税務署に郵送で送るかもしれません。
二週間ほど前に、無事に還付金が税務署から振り込まれていました。確定申告をすると、自分が税金を払っているという実感が持てて、申告方法を調べる中で前よりも税金に詳しくなるのでふるさと納税などやっている人は1度確定申告してみても良いかもしれません。
参考
- 今回確定申告するときに、源泉徴収票の見方もあらためて調べたのですが、これは詳しく解説されていてよかった。 internet.watch.impress.co.jp
リモートワークの気分転換に温泉のあるビジネスホテルに泊まってみた
新型インフルの影響で２月の中頃からうちの会社は原則リモートワークとなってしまいました。リモートワークは会社に行かなくていいので楽なのですが、下手すると数日間、ごはんを買いに外に出る以外はずっと家に閉じ篭ることになってしまいます。中国人観光客の減少でホテルは人が来なくて困っているそうですし、ちょっと気分をリフレッシュしたいので平日にビジネスホテルに泊まってきました。
ビジネスホテルの価格をみると、一泊朝食付きでも6000~7000円ぐらいでは泊まれるみたいです。（探せばもっと安いホテルもあるかも？）飲み会に行く感覚で予約してみました。僕の予約したビジネスホテルは、ドーミーイン川崎です。
ビジネスホテルなのに温泉の大浴場が付いていたり、朝食が50種類のバイキング形式で口コミの評価が高かったのでここにしました。仕事を少し早く切り上げてから家を出て、川崎駅まで気分は小旅行。
いつもの川崎駅でも、ここで一泊すると考えると少し異国の地に見えてきます。（完全に気のせいだろうけど笑）チェックインをして（チェックインでおしぼりが提供された）、部屋に荷物を置いて、ホテル周辺で回転寿司を食べたあと、部屋でずっとキングダムを読んでいました。ここのホテルはブックオフと提携をしていて、大浴場のフロアの近くにライブラリコーナーがあります。ライブラリコーナーの漫画は部屋に持ち帰って読んでもよいということだったので、部屋でずっと読んでいました。
夜鳴きそばという醤油ラーメンを提供するのがドーミーインでは有名なそうなので、食べようと思っていたのですが、キングダムが面白すぎて逃してしまいました。
2019年の秋にオープンしたホテルなので、温泉は綺麗です。髭剃りとか・寝巻きも用意してくれているので、特にこだわりなければ、こちらで温泉のために家から持っていかないといけないものは特にありません。最上階にあるので川崎の夜景を見ることが出来ます。0時までならサウナもやっています。インフルの影響なのか、人はそんなに多くいませんでした。
お風呂から出て、コーヒー牛乳を買おうとしたのですが、現金しか対応してなかったので、1階のフロアから直結しているセブンイレブンでカフェオレを買いました。このホテルはコンビニと直結していて、寝巻きのままでも体を冷やさずに買いに行けます。
朝食はバイキング形式で和洋中の料理が50種類ぐらい提供されています。洋と中をメインに選んでいただきました。担々麺と中華粥美味しかったです。おでん食べ忘れた。
朝食を食べたあと、ホテルをチェックアウトして、周辺のパン屋で昼ごはんを買って、仕事をするために会社ではなく家に帰りました。
温泉がやっぱり最高ですね。本当にサービスは良かったので、今度宿泊する時は、15時ぐらいにチェックインしてもっと昼から温泉とサウナに入り浸ろうと思いました。1週間ぐらい泊まっていたい。
ウィークリーとかマンスリープランもあるそうなので、東京出張でここに泊まっている人は羨ましいですね。ホテル内に貼ってあった、マンスリープランの内容を見ると、マンスリーで宿泊をして朝食なしで一泊7000円に設定されていたので、多分この内容はインフル発生前に設定されたものだと思うのでやっぱり今は少し安くなっているのかなと思いました。予約サイトで見てみたら大阪のほうのビジネスホテルは、いまだと一泊朝食付きで4000~5000円ぐらいで泊まれるようです。5年ぐらい前に会社の出張で大阪のホテルを予約した時は、どこも一杯でやっと予約できたビジネスホテルの料金が8000円ちょっとぐらいだったので安くなっているのかなと思います。関西の人はビジネスホテルを助けるという意味でも、気分転換で泊まってみてもいいかもしれないですね。
追記2
北海道で1週間ワーケーションをしてきました
追記
5月下旬頃にまた泊まってきました
Mac iTerm2のタブ切り替えのショートカットキーをカスタマイズする
Chrome, Atom, VS Codeと続いて、iTerm2でもタブ切り替えのショートカットキーを変更してみました。
command + ,で、Preferencesを表示する
Keysのメニューを選択、KeyBindingsのタブを選択、Key Combinationを変更したいActionをダブルクリック
- 右のタブに移動するAction:
Next Tab - 左のタブに移動するAction:
Previous Tab
- 右のタブに移動するAction:
Keyboard Shortcutに設定したいショートカットーキーを直接入力してOKボタンをクリック
- 画像では、
Command + Contrl + lというショーカットキーをNext TabActionに設定している
- 画像では、
Preferencesのウィンドウを閉じる、設定したショートカットキーを入力してみて動作確認
これで、カスタマイズしたショートカットキーをiTerm2に割り当てられるようになりました。
タグと階層構造 ドキュメントの管理・共有に求められるもの
社会人になってそろそろ１０年経ちますが、その間に色々なドキュメント共有ツールを社内で使ってきました。一番最初に使っていたのはpukiwiki。社内サーバで管理されていて、手順書を作成したり、業務フローなど共有していました。 社会人3年目ぐらいになってくると、アトラシアンのconfluenceが登場。それからは前の会社をやめるまで、このconfluenceを6年ぐらい使い続けました。 confluenceは、人によってはあまり良い印象を抱かない人もいるかもしれないですね。実際、テーブルやインデントなどを挿入しようとするとよく崩れて、綺麗に見せるようにいじるというあまり本質的ではない作業で苦労することがありました。
このconfluenceでは、ドキュメントのページを階層構造で管理する事ができます。例えば、インフラチームの場合だと、以下のような階層構造を作ってドキュメントを管理するかもしれないですね。
インフラチーム --- 手順書
|
-- 議事録
|
-- プロジェクト
|
-- 技術 --- Apache
|
-- Tomcat
この階層構造、人によってイメージするモノが異なることが多くて、このページはどこの階層に所属すればいいのか分からないから、よくTMPという階層（もしくは、個人のページの階層）を作ってとりあえずそこに置いて後から決めようということになりがちでした。 （例えば、上で例に挙げた階層構造だと、Apacheの手順書を作った時に、人によって手順書の配下におこうとする人もいれば、技術の配下におこうとする人も出るかもしれません） ドキュメントのページをどこの階層に配置するかというのは、時間をとって話合いをすれば解決できるのかもしれませんが、エンジニアそれぞれ優先させないといけない仕事を持っていますし、正解は１つではないのでなかなか決まらないこともありどうしても後回しにされがちでした。
まあ、それでも、だいたいよく利用されるページとあんまり利用されないページがあるので、重要なページはブックマークをしておくことで、いびつな階層構造でも業務はまわっていました。 （新しい人が入って来ると、古い情報に惑わされたり、欲しい情報に辿り着くのに苦労するというのが、最初の１週間ぐらいは問題になる。でも、その新しく入ってきた人も直ぐに慣れるので大丈夫。）
2年ほど前に転職してからは、Qiita Teamを使っていました。Qiita Teamには、ドキュメントを階層化する機能がありません。 ドキュメントを階層化する機能がないと知って、これでどこの階層におくか、もう悩む必要がないんだなとほっとしました。 Qiitaの場合は、ドキュメントのグルーピングは、タグを利用して管理するようです。このタグ付けにも課題があり、人によって紐づけるタグが異なるので、タグによるグルーピングが有効に機能していたかというと、、、。 ドキュメントのページになんのタグを付与するかというのは、時間をとって話合いをすれば解決できるのかもしれませんが、エンジニアそれぞれ優先させないといけない仕事を持っていますし、正解は１つではないので 略）
ということで、だいたいよく利用されるページとあんまり利用されないページがあるので、重要なページはブックマークをしておくことで、若干いびつなタグ付けでも 略） （新しい人が入って来ると、古い情報に惑わされたり、欲しい情報に辿り着くのに苦労するというのが、最初の１週間ぐらいは問題になる。でも、その新しく入ってきた人も 略）
今年ぐらいになってから、Qiita Teamからesaというドキュメント管理ツールに移行することになりました。このesaというドキュメント管理ツールは、Qiita Teamにはなかった、階層構造でドキュメントを管理できる機能があります。（おやおや？） また前の会社のconfluenceのような運用となってしまうのか？この歴史の繰り返し、断ち切りたい。でも、そもそもドキュメントがある階層のどこか一つの地点に留まることができるという前提が間違いなのかもしれないですね。
昔のYahoo Japanはディレクトリ構造を辿ってサイトを探していましたが、いつの間にかGoogleのような検索ボックスに言葉を入力して目的のサイトにたどり着く方法に変わってしまいました。 元も子もない結論ですが、結局のところドキュメント共有ツールも最終的に磨いていかないといけない機能は、タグでも階層構造でもなくて、キーワードを入力したらいい感じに欲しいページを表示してくれる機能なのかもしれないですね。
