SPLOUT BLOG - Part 62

VSCodeでEmmet入門

コーディングはやり始めるときは楽しいのですが、どんどん進めていくうちに、だんだんと入力が面倒になってきますよね。
そこで、コーディングを効率的に進める上で欠かせないのが「Emmet」です！

Emmetというのは、HTMLやCSSの入力をサポートするツールです。

「そんなのエディタの自動補完を使ってもいいじゃん。」という声も聞こえてきそうですが、Emmetに慣れてくるとコーディングのストレス軽減に大きな違いを実感できると思います。

入力例として

「height:100px」を入力するときは、
「h100」と入力→「Tab」キーを押す

「<div class=”wraper”></div>」を入力するときは、
「div.wraper」と入力→「Tab」キーを押す
というような感じになります。

慣れれば慣れるほどその効果を実感できると思います。

それではVSCodeでEmmetを使って行きましょう。

「Tab」キーでEmmet省略記法が展開されるようにする

①基本設定＞設定から「設定」を開きます。
②上部の検索窓から「emmet」を入力
③「trigger Expansion On Tab」にチェックをいれます。

これで準備が整いました。

HTMLの雛形を出力

まずは、HTMLの雛形を出力していきましょう。
VSCodeを開いてtest.htmlというファイルを作成して保存します。

それでは「html:5」と入力して「Tab」キーを押してください。下記のように展開されましたね。

html:5

↓↓↓

<!DOCTYPE html>
<html lang="en">
<head>
  
  
  Document
</head>
<body>
  
</body>
</html>

このままでは、「lang=”en”」になっているので、「基本設定＞設定」から「emmet」を入力して、「settings.jsonで編集」をクリックします。
そして下記の１行を追加します。

{
  "emmet.variables": {"lang" : "ja"}
}

「html:5」と入力して「Tab」キーを押すと、先程enになっていたところがjaになります。

EmmetのHTMLサンプル

基本的には「○○＋Tab」なので、下記を参考に一度試してみていただければと思います。

aタグ

↓↓↓

class名

a.top

↓↓↓

ID名

a#header

↓↓↓

リストタグを並べる場合

ul.test_list>li.test_item*3

↓↓↓

EmmetのCSSサンプル

height

h10

↓↓↓

height: 10px;

width

w100%

↓↓↓

width: 100%;

border-radius

bdrs4

↓↓↓

border-radius: 4px;

上記はほんの一例で、下記のリンクに各スタイルの記述する方法が書かれています。
https://docs.emmet.io/cheat-sheet/

これらをすべて覚えるのは難しいので、よく使うスタイルやhtmlだけでも覚えるとコーディングの負荷を軽減できると思います。
ぜひ活用してみてください！

唇に唐辛子がついたら大パニック

こんにちわ。
リエです。

とつぜんですが、皆さんは辛いものは好きですか？
わたしは程よく好きなのですが、これは唇に唐辛子がついたときのお話です。

あれは今年の6月頃。お家で麻婆豆腐を食べていました。
もう少し辛い方がいいなぁと思い、たまたまお家にあった乾燥唐辛子を数本刻んで追加しました。思ったとおり辛くなり美味しく食べていたのですが、ふいに唇を指で触ったら唇がなんか痛くなってきました。

それからがもう地獄。
めっちゃ唇が痛い。焼けるようにヒリヒリ痛い。

唐辛子を刻んだ指で唇を触ったことにより、カプサイシンが唇についてしまい激痛を引き起こしたのです。

すぐに水で洗ったのですが、全然痛みはマシにならず。。
Google先生に助けを求めました。

唐辛子が唇についたときはどうすればいいの？

唐辛子のヒリヒリの原因であるカプサイシンは脂溶性。つまり、油に溶けるということです。なので油で拭くと痛みが和らぐそうです。
ご家庭にある油といったら以下でしょうか。
・サラダ油
・ごま油
・オリーブオイル　など

また乳製品もカプサイシンと結びつき痛みを和らげる効果があるそうです。
油も乳製品もどのご家庭にも常備しているものだと思うので、すぐ使うことができますね。

実際に試したこと

わたしがまず試したのは、サラダ油で拭くということ。
拭いた直後はマシになりましたが、少し時間が経つとまたヒリヒリ。。
そうだ、乳製品も試してみようと冷蔵庫を空けたらなんと！乳製品（牛乳やヨーグルトなど）が一切ないですやん／(^O^)＼もう絶体絶命のピンチ。
泣きそうになりながら冷蔵庫を見ていたら、ミックスジュースを発見。
ミックスジュースには牛乳が入っているから、もしかしていけるんちゃうかということでミックスジュースで唇を拭いてみました。
すると【痛みが収まったではありませんか( ；∀；)！！！】
もうミックスジュースに感謝しかありません。
油で拭いてみて痛みが取れない方は乳製品で拭くことをオススメします。

カプサイシンおそるべし。

NGINXでキャッシュを行う

NGINXでリバースプロキシする際、キャッシュを行いパフォーマンスを上げることができます。

メリット
・upstreamサーバへのリクエストを減らすことができる。
・NGINXとupstreamサーバ間のトラフィック削減
・レスポンス速度が早くなる

デメリット
・キャッシュの更新を考えた場合に処理が複雑になる可能性がある。
・NGINXサーバでディスク使用量の増加
・NGINXサーバでIO負荷がかかる

設定方法

現在の一時ファイルについての設定確認

# nginx -V 2>&1 | sed 's/ --/\n --/g' | fgrep proxy-temp-path
# fgrep -nr proxy_temp_path /etc/nginx/

設定

http {
  #proxy_temp_path /var/cache/nginx/proxy_temp;
  proxy_cache_path /var/cache/nginx/cache_1 levels=1:2 keys_zone=cache_zone_1:16m max_size=100m inactive=120m;

  upstream backend {
    server 192.168.0.101;
    server 192.168.0.102;
  }

  server {
    listen 80;
    server_name _;

    location / {
      proxy_pass http://backend;

      proxy_set_header Host $http_host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;

      proxy_ignore_headers X-Accel-Expires Cache-Control Expires;

      proxy_cache cache_zone_1;
      proxy_cache_key "$scheme$proxy_host$request_uri";
      proxy_cache_valid 200 60m;
      proxy_cache_valid any 5m;

      add_header X-Cache-Status $upstream_cache_status;
    }
  }
}

proxy_cache_pathディレクティブ

/var/cache/nginx/cache_1：キャッシュファイル保存場所
キャッシュを行う場合、一旦レスポンスをproxy_temp_pathで指定した一時ファイルに保存してからのrenameとなるため同じデバイスになるよう注意
実ディレクトリは/var/cache/nginxまで存在していればcache_1は自動で作成されます。

levels=1:2：キャッシュを保存する階層
キャッシュファイル名はproxy_cache_keyをmd5したものになり、階層はファイル名の一部が利用されます。
md5が3858f62230ac3c915f300c664312c63fだった場合のファイルパス
/var/cache/nginx/cache_1/f/63/3858f62230ac3c915f300c664312c63f

keys_zone=cache_zone_1:16m：キャッシュゾーンの名前とメモリサイズ。
メモリサイズは1つのキャッシュにつき128バイト使われる(64bit環境)
この例だと16mになっているので約130000ファイル保存できます。
※よく使われるサイズの単位
g：ギガバイト
m：メガバイト
k：キロバイト

max_size=100m：キャッシュファイルの総容量
nginxは定期的にcache managerと呼ばれるプロセスを起動し、容量を監視しています。この時最大容量を超えていた場合は最も長い期間アクセスされなかったファイルから削除されます。
※最大容量を超えた瞬間ではなく、定期的にチェックされる＝一時的に最大容量を超えた状態になる。

inactive=120m：最後にアクセスされてからキャッシュファイルが削除されるまでの時間
120mの場合、最後にアクセスされてから120分アクセスがないと削除されます。
※よく使われる時間の単位
M：月
d：日
h：時間
m：分
s：秒

proxy_cacheディレクティブ

proxy_cache_pathで設定したキャッシュゾーンの名前を指定

proxy_cache_keyディレクティブ

キャッシュのキーとして使用する値を指定

proxy_cache_validディレクティブ

ステータスごとのキャッシュの有効期限の指定
ステータスを指定しない場合は200,301,302のレスポンスのみがキャッシュされる。anyを指定した場合は明示的に指定していないすべてのステータスコードに設定することができる。

proxy_ignore_headersディレクティブ

backendからのレスポンスで無視するヘッダーを指定する
Cache-Control及びExpiresを指定することでproxy_cache_validの設定が生きる
キャッシュ設定の優先順位
X-Accel-Expiresヘッダ > Cache-Controlヘッダ > proxy_cache_valid

※Set-Cookieヘッダがある場合、通常はキャッシュされませんがproxy_ignore_headersで無視してキャッシュする事も可能です。
ただしこの場合proxy_hide_headerも指定しておかないと他人にもcookieがセットされてしまいます。

add_headerディレクティブ

サンプルの場合X-Cache-Statusというレスポンスヘッダ名でキャッシュのステータスを返しています。

簡単にNGINXのキャッシュ設定について説明しました。
NGINXの設定は奥が深いので色々試してみましょう。

本当に欲しいものをわかっているとは限らない

消費税増税や面倒しかない軽減税率が目前に迫っています。カツラです。
それに伴い個人的に今年の初めから漠然と家計簿をつけ始めましたが、思いの外長く続いているのでその中で思ったことを書きます。

最近のアプリだと手で入力するだけではなくレシートから自動で読み取ってくれたりグラフ表示があったりするので当初はアプリを使う予定でした。
ですが、自分の欲しい機能が入っているアプリを見つけるまでが長く機能も色々あるけど最終的には面倒になったので、途中で探すのをやめてスプレッドシートで管理するようにしました。

ゲームやエンタメ系であればランキングやおすすめ系はわかりやすくて良いのですが、管理系で複数アプリが存在するものは機能の一覧比較等の方がわかりやすいと思います。

そして最初は分類毎の合計金額を月単位で推移が見れればいいだけでしたが

PC等高額商品は別扱いにしたい
食費、外食費は分けて記録するけどグラフでは統合したい
Kindleで購入したものは別枠で詳細が見たい

などなど家計簿をつけているうちに後付けで色々と欲しいものが見えてきた点が多く、個人的にはスプレッドシートだったので柔軟に対応できてよかったのですが、このことから家計簿をつけるのにアプリよりスプレッドシートを推奨するという意味ではありません。

この出来事を通して思ったのは自分がサービスを作る上でも

本当に欲しい機能をユーザー自身が最初からわかっているとは限らない
なんでもかんでも機能を搭載する必要はない、むしろ邪魔になることも
いくら良いものでも認知されなければないものと同じ

とわかっているつもりでしたが、今回のことで再確認できた気がします。

[Solr]ドキュメントルーティングのcompositeIdのハッシュを実際に計算してみる

前回の記事に書いたように、compositeIdによるドキュメントルーティングを採用した場合、compositeIdのハッシュ値のどの範囲をどのシャードが担当するのかはSolrの管理画面で確認することができます。ただし、実際のハッシュ値を知ることは実はできません。

簡単なテストプログラムを書いて、compositeIdのハッシュ値がどのように計算されるのかを確認してみました。

まずは単独のIDでハッシュを計算してみます。

$ java -cp .:solr-solrj-8.1.0.jar CompositeIdTest '1234'
id = 1234
hash = 721c5dc3
$ java -cp .:solr-solrj-8.1.0.jar CompositeIdTest '中央区'
id = 中央区
hash = a812f493
$ java -cp .:solr-solrj-8.1.0.jar CompositeIdTest '公園'
id = 公園
hash = eb2b06c4

IDを組み合わせてみます。

$ java -cp .:solr-solrj-8.1.0.jar CompositeIdTest '中央区!1234'
id = 中央区!1234
hash = a8125dc3
$ java -cp .:solr-solrj-8.1.0.jar CompositeIdTest '中央区!公園!1234'
id = 中央区!公園!1234
hash = a82b5dc3

8ビットで16進数2桁、16ビットで16進数4桁です。
「中央区!1234」の場合は16ビット:16ビットになるので
「中央区(a812f493)」の上位4桁
「1234(721c5dc3)」の下位4桁
でa8125dc3になっていることが分かります。
「中央区!公園!1234」の場合は8ビット:8ビット:16ビットなので
「中央区(a812f493)」の上位2桁
「公園(eb2b06c4)」の3桁目と4桁目
「1234(721c5dc3)」の下位4桁
でa82b5dc3となります。

さらにビット数を指定してみます。

$ java -cp .:solr-solrj-8.1.0.jar CompositeIdTest '中央区/4!公園/4!1234'
id = 中央区/4!公園/4!1234
hash = ab1c5dc3
$ java -cp .:solr-solrj-8.1.0.jar CompositeIdTest '中央区/4!公園!1234'
id = 中央区/4!公園!1234
hash = ab2c5dc3

「中央区/4!公園/4!1234」の場合は4ビット:4ビット:24ビットなので
「中央区(a812f493)」の上位1桁
「公園(eb2b06c4)」の2桁目
「1234(721c5dc3)」の3桁目以降
でab1c5dc3となります。
「中央区/4!公園!1234」の場合に無指定の「公園」の扱いがどうなるか興味があったのですが、2階層の場合はデフォルト8ビットなので「中央区/4!公園/8!1234」と同じになるようです。
「中央区(a812f493)」の上位1桁
「公園(eb2b06c4)」の2,3桁目
「1234(721c5dc3)」の4桁目以降
でab2c5dc3となります。

簡単なプログラムではありますが、特定のレコードがどのシャードに配置されているのかを確認したい場合に便利に使えそうです。