箱根に行って来ました

カテゴリー:  Trivialities  タグ:  photo travel

同僚が「紅葉を見たことがない、一度見たい。そして富士山も見たい」というので 箱根に行って来ました。

紅葉は微妙

当然12月ですから、紅葉の旬は過ぎていて微妙な感じでした。

とりあえず、芦ノ湖の箱根関所を見て参りました。

関所跡は、2007年に再建されたそうで、観光ボランティアらしきお婆様が「完全再建 なんですよ」と何度も念押しされました。

完全再建とは、全く同じ場所に、当時の様式のまま再建したということらしいです。

箱根関所が設けられたのは、2代目将軍秀忠の時代です。そして少し時代が降った 時期に改修されており、その時の資料が発見され細かい建物の仕様が判明したそう です。

彫刻の森美術館へ

そのまま関所近辺でランチをいただけばよかったのですが、強羅の方に移動して しまったためランチ難民となり、面倒になって彫刻の森美術館にそのまま入って バイキングをいただきました。

箱根に来て何してんだろう。

彫刻の森美術館は、とても広くピカソ館などかなり見応えがあるので、それなりに よかったのですが。

その後、裾野ICの方に抜けて帰って来て、「横浜の中華街でも行くか」となった のですが、横浜町田ICを降りた途端に同僚クルマ酔いでダウンしてしまいました。

いやいや、箱根の山道ならともかく、横は町田IC出口のループでクルマ酔いとは!

回復を待つしかなく、立ち往生してしまい大変でした。

ほんとは山道とか慣れてなくて我慢してたんですかね。悪いことしたなぁ。

ギャラリー

SpotifyからAmazon Music unlimited に

カテゴリー:  Tech  タグ:  music spotify

Spotifyをフリープランに落として、Amazon Music unlimitedの試用をはじめました。

Spotify vs Amazon Music unlimited

まず、気になるのは曲の品揃えでしょう。

調べたところ、SpotifyもAmazon Music unlimitedも4,000万曲と謳っているようです。 どちらも洋楽にはそこそこ強く邦楽には弱い傾向です。邦楽については若干Amazonの方 がカバーしてる曲が多いようですが大差なさそうです。

使い勝手は、Amazon Musicの方はこれからなので未評価ですが、Prime Musicと 大差なければ、普通に使いやすそうです。

Spotifyの方は、あくまでプレイリスト中心に聴くスタイルのようです。 雰囲気で曲を垂れ流していたい時はよいのですが、「特定のアルバムを聞きたい」 というときに、私はちょっと使い勝手がわからない場合があります。

料金的は、私はAmazonプライム会員なので、Amazon Music unlimitedの方が 200円ほど安くなります。

で、結局乗り換えた理由? いや、まだ乗り換えた訳じゃない。

実は、Amazon Music unlimitedを使ってみる一番の理由は、Amazon Echo Dot を 注文できた事です。

組み合わせて部屋で音楽流すのに良いかなと思っているのですが、まだDotが手元に 届いていないのでなんとも言えません。

つまり、乗り換えたと言っても、Amazonの方はまだ試用期間で決定した訳ではありません。 Dotが届いて使い勝手がよければ、そのままAmazon Music unlimitedに移行して、 使いにくければ、Spotifyに戻すと思います。

週末に届くといいなぁ。

textlintで文書校正する

カテゴリー:  Tech  タグ:  software writing

先日、RedPenを試したので、今度はtextlintを試して 見ました。

環境構築

textlintはNode.jsで動作するので、環境を整えます。

Macでは、Homebrewが導入されていれば、以下の手順で導入できます。

textlint-rule-preset-ja-technical-writingというルールセットをインストールしました。

textlintはデフォルトでは校正のルールセットを持っていないからです。

$ brew install nodebrew
$ nodebrew setup
install nodebrew in $HOME/.nodebrew

========================================
Add path:

export PATH=$HOME/.nodebrew/current/bin:$PATH
========================================
$ echo "export PATH=$HOME/.nodebrew/current/bin:$PATH" >> .bash_profile
$ nodebrew install-binary latest
$ nodebrew ls
V9.2.0

current: none
$ nodebrew use V9.2.0
$ mkdir textlint-test && cd $_
$ npm init --yes
$ npm install -save textlint
$ npm install -save textlint-rule-preset-ja-technical-writing

次に、.textlintrc というファイルにルールの設定を書きます。

{
    "rules": {
        "preset-ja-technical-writing": true
    }
}

そして、生成されている package.jsonscriptsに追記します。

{
  "name": "textlint-demo",
  "version": "1.0.0",
  "main": "index.js",
  "scripts": {
    "lint": "textlint ./*.md",
    "lintfix": "textlint --fix ./*.md",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "textlint": "^9.1.1",
    "textlint-rule-preset-ja-technical-writing": "^2.0.0"
  },
  "devDependencies": {},
  "description": ""
}

校正してみる

文書の検査は以下のコマンで実施できます。

$ npm run -S lint

結果はなかなか厳しいですな。

1:1   error  Line 1 exceeds the maximum line length of 90              
7:3   error  文末が"。"で終わっていません。                            
23:12  error  Disallow to use "?"                                      
25:1   error  Line 25 exceeds the maximum line length of 90             
25:18  error  漢字が7つ以上連続しています: 道路運送車両法               
25:26  error  漢字が7つ以上連続しています: 自動車検査業務等実施要領     
31:17  error  一文に二回以上利用されている助詞 "で" がみつかりました。  
31:20  error  一文に二回以上利用されている助詞 "で" がみつかりました。  
34:16  error  一文に二回以上利用されている助詞 "も" がみつかりました。  
34:19  error  弱い表現: "かも" が使われています。                       
36:19  error  一文に二回以上利用されている助詞 "と" がみつかりました。  
36:20  error  弱い表現: "思います" が使われています。                   
39:16  error  弱い表現: "思います" が使われています。                   
40:13  error  Disallow to use "?"                                      

関連リンク

やっぱりリコール対象でした、ウチのWRX

カテゴリー:  Automotive  タグ:  car subaru wrx

仕事が落ち着いたので、スバルの完成検査問題で愛車がリコール対象を調べました。 やっぱり、ウチのWRXも対象でした。

やっぱり対象か

時期が被っていて、まだ初回の車検前なのでバッチリ対象でした。

リコール詳細

と言っても、もう来月末には車検出そうと思っていたんですが。

スバルが悪いのか?

こう言った「完成検査」なるものは、道路運送車両法や自動車検査業務等実施要領なんかで 決まっているのでしょうから、アウトかセーフかで言えば資格者じゃなかったんで アウトなんでしょうね。

スバルの記者会見では吉永社長がしきりに「完成検査員のハードルが高すぎた」と繰り返して いました。これは、人が足りないから無資格者を使っていたわけでなく、社内の厳しい教育と 試験をクリアした上でさらにOJTで自力で検査ができることを社員に課していたことを指すの でしょう。結局このOJT部分がアウトなのですが。

法令を数十年も確認しなかったのも問題かもしれませんが、品質上の問題が出てるのかと 言えばむしろスキル的には十分な技術者が検査していたわけです。それが社長の 「ハードルを上げすぎた」と言葉なんだと思います。

絶対に社長の立場から言えないと思いますが、素直に考えると 「完成検査って意味あんの?」って感じますね。

検査要領や車検の点検項目を読んでも、書いてあることはほとんど目視検査 できるようなことばかりです。車検はともかく、完成検査は製造されたばかりの車です。

スバルの工場見学に行ったことがありますが、ラインにはロボットアームが並び部品と 取り付けるだけでなくアームのカメラが全方位から異常をリアルタイムに チェックしています。

人がラインに入ることもありますが、トレーに部品がきちんとまとめられ部品の欠損 も管理されているようでした。適切なタイミングで適切な工具が作動してたかも 管理されており、人のエラーを防ぐようかなり細かくチェックされていました。

こう言った管理は別にスバルに限ったことではないでしょう。

現代の工場では高いレベルでラインが自動化されているので、 異常が出るとしたら個別の問題でなくラインに異常がある確率の方が高いのではないで しょうか。その場合即座にラインを止めて異常を除去しなければ大変なことになります。 したがって、どのメーカーでもかなりの精度で厳しい検査を製造中に常に行なっているはずです。

はっきり言って、「完成検査」以前にはるかに高いレベルで品質管理されているのです。

こりゃ、もう法令の方がポンコツです。そういうことを主張してこなかった業界も悪い んですが。

それはともかく、明日営業にリコールの対応を確認してきます。

関連リンク

HugoからPelicanへの移行を検討中

カテゴリー:  Tech  タグ:  blogging hugo pelican

このブログは夏に静的サイトジェネレータの Hugoに移行したばかり ですが、同様に静的サイトジェネレータの Pelicanへの移行を検討しています。

Pelicanを検討する訳

1番の理由は、コンテンツの記法としてMarkdownだけでなく reStucturedTextが 使えることです。

reStucturedTextの良い点は、 以下の3つでしょうか。

  • 仕事のドキュメンテーションでreStructuredTextを使い出したので、統一したい。
  • Markdownより表などの表現力が高い。
  • ソースコードのシンタックス表示をJavaScriptに依存せずレンダリングできる。
  • コンテンツ・ソースが読みやすい。

Hugoについては、他の静的サイトジェネレータと比較すると 圧倒的なビルド速度と日本語情報の多さがメリットでした。

ビルドの早さについては、Netlifyで自動ビルドして いるのでどうでもよくなってしまいました。

情報量が多いのは助かりますが、まぁなんとかなるかと。

Pelican移行の進め方

コンテンツの移行

Pelicanもマークダウンが扱えるので、コンテンツは基本的にそのまま持ち込め そうです。

ただし、メタ情報については記法が違うのでコンバートが必要です。これはすでに HugoからPelicanへの 移行を行った方 が、メタデータ変換のPythonスクリプトを書いていらっしゃいました。テストした ところウチのブログは問題なく変換できそうです。

コンテンツ・ソースのフォルダ構成を私は年度ごとに以下のような構造にしています。 Pelicanでは USE_FOLDER_AS_CATEGORYTrueにしなければ、フォルダには特に 意味はないので問題なさそうです。

.
├── about.md
├── post
│   ├── 2011
│   ├── 2012
│   ├── 2013
│   ├── 2014
│   ├── 2015
│   ├── 2016
│   └── 2017
└── search.md

また、コンテンツ・ソースのファイル名に私はYYYYMMDD.mdという形式を使用しています。 同日に複数の記事を書く場合は、20171123-2.md などとしています。

Pelicanにはファイル名からメタデータを取得する機能があります。 以下のように設定すればファイル名からうまく日付を取ってくれます。そして、都合が よいことに、ファイルの中にメタデータが書かれている場合はそちらを優先して くれるようです。

FILENAME_METADATA=r'(?P<date>\d{4}\d{2}\d{2}).*'

以上から、ほぼ移行スクリプトと流せばコンテンツの移行は終わりそうです。

生成後の互換性について

サイトついては、現在も使用しているNetlifyに載せよう と思います。テストしたところ、Netlifyでpelicanの生成も問題なくできました。

生成する記事のURLも設定ファイルの pelicanconf.pyでうまく設定すれば大丈夫 そうです。

以下の2つの設定でHugoで生成しているこのブログと同じ構成になりそうです。

ARTICLE_URL = '{date:%Y}/{date:%m}/{date:%d}/{slug}/'
ARTICLE_SAVE_AS = '{date:%Y}/{date:%m}/{date:%d}/{slug}/index.html'

問題はテーマです。

現在HugoのHemingway2というテーマを元にかなり自分で修正を加えてしまっています。

Pelicanのテーマは、https://www.pelicanthemes.com で色々公開されていますが、気に入ったものがありません。

自分で作るかな。

関連記事

RedPenで文書校正する

カテゴリー:  Tech  タグ:  homebrew writing

文書検査ツール RedPenを導入してみました。

背景

現在仕事のプロジェクトをアーキテクトとして担当しているのですが、 要件定義で生産的な活動をしてくれるメンバがおらず、ほぼ一人で要件定義書を 書き上げることになりました。

他人のチェックが通っておらず、ちょっとしたミスも多いので校正ツールを導入する ことにしました。

最初はJustSystemのJustRightなどを考えたのですが、以下の理由によりオープンソース の RedPen で文書の検査をすることにしました。

  • JustRightを購入する費用が捻出できない。
  • そもそも 要件定義書は Sphinxで記述し て、RedPenはreStructuredTextをサポートしている。

RedPen 使用感

かなり文書を書き上げてから使用したので、最初はものすごい量のエラーに圧倒されました。

しかし、指摘をチェックして気づいたことも結構あり大変ためになりました。

まず、指摘が多かったのは以下のものです。

  • KatakanaEndHypeh
  • JapaneseAmbiguousNounConjunction
  • ParenthesizedSentence

KatakanaEndHypeh

これは、カタカナの語尾がハイフンで終わるケースですね。

「コンピューター」や「アーキテクチャー」などが古いJISZ8301などの規約だと、 ハイフンで終わらせず「コンピュータ」や「アーキテクチャ」なのだそうです。

RedPenではこれにならって、以下のルールになっているようです。

  1. 単語が三文字もしくはそれ以上の場合には、ハイフンで単語は終わらない。
  2. 単語が二文字もしくはそれ以下の場合には、単語はハイフンで終わってもよい。
  3. 単語が複合語の場合には各々の部分単語について条件が適用される。
  4. 以上のルールにおいて、拗音をのぞきハイフンは一文字としてカウントされる。

これは私の感覚と違っているのですが、私自身も表現が揺れてるところがあった ので、今回はRedPenに従いました。

平成3年6月28日 内閣告示第二号『外来語の表記』から事情が変わっていて、 本来は「コンピューター」「アーキテクチャー」の方が正しい気がします。

JapaneseAmbiguousNounConjunction

私の場合、これが一番たくさんひっかったエラーでした。

「他のコンポーネントのエラーを」などのように格助詞「の」で文章を繋いだものです。

自分では気づいなかったのですが、この表現を予想以上に使っていました。そして確かに 言われてみれば文章の意味が曖昧になっているケースに気づきました。

例えば「他のコンポーネントのエラーを」というのは、「他のコンポーネント」のエラー なのか「他の」コンポーネントのエラーのなのかわかりませんね。

これを格助詞を並べずに言い換える表現を考えると、意外にも文章の意味がはっきりし てくることに気づいたのです。

JapaneseJoyoKanji

これは括弧に関する規約で、一文で使用される括弧の頻度や括弧のネストなどをみて くれるのです。

実際には括弧がおかしいというよりは、箇条書きの句読点が抜けていたり、どこかで 文の区切りがおかしかったりということが原因でした。

このような文はSphinx上もエラーを抱えているケースが多かったので、その事前の チェックとしても有効でした。

導入に当たっては

私はかなり文書が書き上げた状態で導入したので、ものすごい量のエラーを除去で 疲弊してしまいました。

反省としては、2点あります。

  1. プログラムのテストツールと同様テストファーストです。CIで組み込んで書き始め からチェックして言った方がおそらく生産性が高く、除去の工数も小さくすみます。
  2. 先のKatakanaEndHypenのように実情と合わないルールもあると思います。その場合は、 サクッと外しちゃいましょう。

なお、設定はファイルは導入フォルダ1に設定ファイルがあるので、プロジェクトの フォルダにコピーしてきて、不要なルールを消していきましょう。


関連リンク


  1. macOSの場合は、/usr/loca/Cellar/redpen/1.9.0/libexec/conf にxmlの設定ファイル があります。 

備忘録:Mac/neovimでCSVファイルを扱うときのTips

カテゴリー:  Tech  タグ:  editor vim

EXCELなどから吐き出したCSVをMac上のneovimで扱うノウハウをいつも忘れてしまうので、忘れないようメモっておきます。

改行コードの問題

Mac上のMicrosoft Excelは、CSV形式でファイルを保存する際になぜか改行コードにCR(0x0d)を使いやがります。

Vimで開くと、^Mって文字が並んで全然改行できてない訳です。

これを改行させるためには、コマンドモードで以下を実行します。

:%s/^M/\r/g

これで全行の^Mが改行コードに変換されます。

あれ?^Mってどうやって入力するんだっけ?

そう、置換するのはわかるのですが、 Vimで^Mをどうやって入力するかよく忘れてしまいます。

Vimで^Mを入力するには、以下のようにタイプします。

Ctrl-V Ctrl-M

あぁ、\ (バックスラッシュ)はどうやって入力するんだっけ?

どこまでも人の記憶は当てにならないものです。

バックスラッシュの入力方法を忘れるので、\r がタイプできません。

Macでは以下で入力できます。

Option + ¥

Karabiner-Elemetsを改めて使う

カテゴリー:  Tech  タグ:  keyboard software

Pafuxuさんの「171112 Karabinerの設定」という記事を読んで、 Macではキーバインド変更アプリ定番の"Karabiner-Elements"を導入しました。

Karabiner-Elementsを導入した訳

Karabinerは定番アプリですが、MacがSierraに移行した時動作しないということで問題になりました。そこで、全く新規に作られたのがKarabiner-Elementsでした。

私も昨年試しました が、そもそも使用していませんでした。そのためその便利さは実感できず、すぐにアンインストールしてしまいました。

今回Pafuxuさんの記事を見て、「便利だな」と思ったのは内蔵キーボードを無効にできる機能です。

あと使っているのがワイヤレス外部キーボードを使用するときは内臓キーボードを無効にする。HHKB BTを内臓キーボードの上に置いて使用したいため。

171112 Karabinerの設定 - pafuxumac

確かに、これでHHKB BTを内蔵キーボードの上に置いて使用でき、スペース効率が上がります。

また、以下のような拡張がなされています。nvimを愛用している私には大変便利な機能です。

  • escキーを押した時に、英数キーも送信する (vim用)
  • Ctrl+[ を押した時に、英数キーも送信する。(vim用) <- こっちのキーアサインは私は使っていませんが。

ちょっと疑問

使っていてちょっと疑問は、内蔵キーボードと外部キーボードのタイプが日本語と英語 というように違う場合はどうするんだろう。

よくわからないので、Karabiner上は英語キーボードとして登録して内蔵キーボードで問題がある キーを見つけるごとにぽちぽちと修正していました。しかし、面倒になって内蔵キーボードはKarabinerをオフにしてしまいました。

関連リンク

Aoyama Sake Flea Vol.7

カテゴリー:  Dining  タグ:  event sake

半年ぶりに、また開催された国連大学前のマーケットでやっているAoyama Sake Fleaに行ってきました。

これで、昨年11月のVol.5 から3回連続参加です。

Aoyama Sake Flea Vol.7

今年も20杯飲めておちょこがついてくるチケットを予約購入して参りました。一日で20杯だと、ちょっと 酔いすぎてしまうのですが、今回は同僚も来るというので一旦20杯をシェアすることにしました。 前回まで20枚のシールだったのですが、今回から専用のコインに変わっていました。

予約窓口に行って予約購入した際に送られて来るメールを見せると、コインとおちょこを頂きます。今回同僚がいるので、新しくいただいたおちょこは同僚に譲って私は前回のおちょこを持参しました。

今回出店の銘柄は以下です。

参加酒蔵一覧 - 11/11&12 | AOYAMA SAKE FLEA vol.07

陸奥八仙 (青森) 米鶴   (山形) 山の井  (福島) 鶴齢   (新潟) 妙高酒造(新潟)(土曜のみ) 岩清水  (長野) 真澄   (長野) 仙禽   (栃木) 若駒    (栃木) 来福   (茨城) 結    (茨城) 豊明 (埼玉) 文楽   (埼玉) 木戸泉  (千葉) awa 酒協会 (東京) 白隠正宗 (静岡) 手取川 (石川) 天狗舞 (石川) よしのとも (富山) 羽根屋 (富山) 津島屋   (岐阜) 喜楽長 (滋賀) 紀土    (和歌山) 作 (三重) みむろ杉 (奈良) 播州一献 (兵庫) 土佐しらぎく(高知) 東鶴   (佐賀) 天吹 (佐賀) 豊潤 (大分) 熊本県ブース(熊本)

今回は岐阜の津島屋を気に入ってしまいました。

蔵は御代桜醸造株式会社で、岐阜県美濃加茂市にある8人でやっている小さな小さな蔵だそうです 。とは言え、現在6代目の蔵元とのことで、地元では歴史ある蔵みたいです。

主力のブランドは「御代桜」というらしいですが、「津島屋」は純米にこだわった比較的新しいブランド で力を入れているそうです。

「津島屋」の純米大吟醸を頂きましたが、香りも良く、甘みと旨みのバランスのよいすっきりと飲める力強いお酒です。

いつもはひたすら飲んで帰るのですが、今回は日本酒が初めてという同僚が一緒だったので様子を見つつ、ゆっくりと頂きました。時折雲が出て風も強かったので少し寒かったのですが、概ね良い天気で気持ち よく昼間から飲めました。

沖縄の三線の演奏をやっていて、青空の下テーブルで歌を聴き沖縄時代の話で盛り上がり、 日本酒を飲み、屋台で出ている煮込み、おでん、すっぽん雑炊 昼食がわりにまったりと頂く。なんとも贅沢な飲んだくれの休日でした。

同僚が日本酒飲んだことがないと言うので若干不安でしたが、 酔いつぶれることもなく、酒蔵の方のウンチクを聴き興味を 持ったようで美味しいと楽しんでいたのでホッとしました。

ウォーキング

2時間ほどかけて20杯を楽しんだ後、うちの会社の渋谷サテライトを見てたいと同僚が言うので 渋谷まで20分ほど歩きました。

さらにテレビ録画用のHDDが欲しいというので、銀座線で末広町に出て秋葉原を散策。以前の 電気街を想像していたらしく、メイドとケバブ屋さんだらけになっている秋葉原には面食らって いたようです。

湯島で夕食をいただくことになり秋葉原から湯島までなぜか歩くことに。 お目当てだったお店は何故か土曜の早い時間なのに満席で、適当にバルに入ってホッピーをいただきました。

その後千代田線に乗って大手町で半蔵門線乗り換えだったのですが、同僚が「そういえば大手町のサテライトも見たい」と言い出し、またもや会社のサテライトに「出社」してしまいました。

結局1日で2万歩近く歩きました。

関連リンク

シェービングフォームを巡る旅

カテゴリー:  Gadget  タグ:  shaving

ここ数年、両刃カミソリを使うようになってから、ずっとシェービング・フォームで悩んでいます。 普通に売ってるあの泡が出てくるシェービング・フォームでもいい気もするのです

ただ、やはり両刃カミソリだともう少し厳かなものが良いかなと思ってしまっています。

シェービング・ソープ(石鹸)

最初に試したのは、シェービングソープです。

Amazonで購入したスペイン製の石鹸と、英国出張の時に買った石鹸を使っていました。

最初のスペイン製のものは香りが好みでなく、英国のものは香りは良いのですが石鹸用のトレイが 痛んできてしまって一緒に捨ててしまいました。

日本だとあまり選択肢がなく、たまに見かけても異常に高いのが課題です。

ただ、使ってみるとそれぞれなかなか無くならず年単位で使えるので、多少値が張っても経済的かもしれません。

シェービング・ソープ(粉)

次に試したのが粉のシェービング・ソープです。

昔ながらの床屋さんで使ってたやつです。

これをふた振り、熱湯が入ったシェービングカップに入れて、厳かにシェービングブラシでかき混ぜ、 たっぷりと泡だていく。

茶道のように厳かです。

しかし、レトロすぎて2つ問題があります。

  1. 成分的にはほぼ界面活性剤しか入っていないため、保護的な機能がないので結構キレます。保護剤のクラシエ シェーブエッセンスなんかを併用する羽目になり面倒です。
  2. 泡立ちはいいんですが、結構ダマになりやすく一度ダマになるとなかなか溶けません。

シェービングクリーム(洗い流し不要)

美容液も入って「洗い流し不要」って謳い文句で結構売れたクリームです。

シアバターを中心とした成分で、潤滑性能も高く保湿効果もあるそうです。

確かに塗るとすぐにヌルヌル状態で、お湯で髭を濡らさなくても綺麗に剃れます。また、剃った後も、血が出るようなこともないし、ヒリヒリ感もありません。そのまま美容液がわりにと言うのもわかります。

ただし、いくらクリームの成分がよくても、髭剃ってるんで剃ったヒゲが出てします。当然水で洗い流す必要があり、そのまま美容液がわりにってわけには行きません。

そう考えると、洗い流してしまうクリームにこの値段はないかな。

シェービングクリーム

こちらは通常のクリームです。今の所、一番お気に入りです。

成分的に際立ったものはありませんが、ハーブ系の香りが朝を引き締めてくれます。

ただ少しコスパが悪いので、セカンドチョイスで似たような成分のスパイク メンズ・シェイビングクリームも時々使っています。ほぼ半額です。

しかし、今の所1番のお気に入りはヴェレダ シェイビングクリームですね。

関連リンク