2019年2月28日木曜日

Hugo Cheet Sheet

久々にHugoを使ったら使い方を忘れてたので、 最低限の機能を最速で使うためのチートシートを残しておきます。 まずは以下を実行してサイトを作るための雛形を作ります。
hugo new site my_site

my_siteディレクトリでは以下のようなディレクトリ構成でサイトを作る。 index.md/_index.md と、list.html/single.html あたりの仕組みがポイントです。
my_site/
  content/  <----- 記事やページの中身はここに置く
    _index.md  <----- 配下ディレクトリを作りたい時はこの _index.md を使う
    posts/
      _index.md  <--- //example.com/post/
      2011.md  <----- //example.com/post/2011/
      2012.md  <----- //example.com/post/2012/
      11/  <--------- //example.com/post/2012/11/  (index.mdがないと閲覧不可)
        foo.md  <---- //example.com/post/2012/11/foo/
      help/  <------- //example.com/help/
        index.md  <-- 配下ディレクトリがいらないなら index.md を使う
        bar.md  <---- //example.com/help/bar/
    terms.md  <------ //example.com/terms/

  layouts/  <----- テーマ設定はここで書く
    _default/  <------ デフォルトのレイアウト
      list.html  <---- _index.md のページに適用するレイアウト
      single.html <--- その他のページに適用するレイアウト
    posts/  <--------- content/posts/ に対応したレイアウト
      li.md  <-------- single.htmlやlist.html から呼ぶ部品レイアウトも置ける
      list.md            ex: {{ .Render "li" }}
      single.md
    partials/  <------ レイアウトの部品  ex: {{ partial "sidebar.html" . }}
    shortcodes/  <---- コンテンツの部品  ex: {{< tweet 877500564405444608 >}}

  themes/  <------ 外部テンプレートを置く、layouts/ のほうが優先度が上
  archetypes/  <-- content/*.md の markdown の雛形を設定するディレクトリ
  static/  <------ 静的ファイルはここに置く

content/*.md の書き方の基本はこんな感じ。高機能なので公式マニュアルを参照しよう。
---
title: "This is a content file in HTML"  <-- ここに変数を書く
draft: true
---
<div>
  <h1>Hello, Hugo!</h1>  <-- Markdown/HTML で記事を書く
</div>

サイトを作り終わったら以下のコマンドのどちらかで確認できます。
hugo            # my_site/public/ に完成品を出力
hugo server -D  # localhost にサイトを出力


Tips

1. markdown に HTML を書きたい

以前は書けましたが、ver 0.60.0 から エラーが出るようになりました。書かない人はいるのだろうか…。 この問題は、config.toml に以下の内容を書くことで回避できます。
[markup.goldmark.renderer]
  unsafe = true

2. markdown に JavaScript を書きたい

3. ページ生成を高速化したい

4. リンク切れチェックしたい → raviqqe/muffet

5. sitemap.xml の changefreq / priority をページ単位で設定する




もっと様々な機能があるので、残りの部分についてはやはり公式マニュアルをどうぞ。

2019年2月24日日曜日

Linuxで動くUSB Wi-Fi 無線LAN子機の選び方

以前購入したWi-Fiカードに難のあるLinuxノートPCが、購入直後は野良ドライバで対応できたものの、カーネルのバージョンアップによって動かなくなってしまいました。 バージョンダウンもなあ…という事で仕方なくLinuxで動くUSB Wi-Fi 無線LAN子機 (通称: ドングル) を購入したので、その選び方のポイントをまとめてみました。


まずUSB Wi-Fi 無線LAN子機の買い方を説明するより前に、LinuxノートPCの買い方も自戒を込めてポイントを1つだけ書いておきます。 BTOで買う時にはドライバが表示すらされていない事が多いので、本気で地雷を踏まないようにするには、購入前から問い合わせしないとまず無理。 そして地雷を踏んでしまったら、下手に野良ドライバを入れるよりはUSB Wi-Fi 無線LAN子機を使うほうが、対応状況の問題によって動かなくなるリスクが少なくて良いと思います。 これは以下の理由による。


対応状況を事前に調べる事の大切さ

USB Wi-Fi 無線LAN子機に限らず、Linuxでドライバが必須のハードウェアを購入する際は、カーネルのバージョンアップも考慮して製品を選ぶ必要があります。 メーカー独自でLinuxドライバを用意しているケースは注意が必要です。 例えば16.04に対応していても、18.04に対応しているような記載がない場合、動く確率は低いと思う。 実際動かないで困っているような報告が海外で散見されたので、対応バージョンも注視しよう。 Wi-Fiなら動かないだけで済むけど、GPUだと最悪OSが起動しなくなる

この問題があるので、買い方のポイントとしては、(1)きちんとLinuxドライバを更新してくれるメーカーの製品を使うか、(2)少し古めでもドライバが対応している事がわかっている製品を買うと良いと思います。 1に関しては昨今のドライバの対応状況を見るに、私はもう無理なんじゃないかと諦めている。 なので2で、まずは動くところを重視したほうが良さそう。 この部分をもう少しきちんと説明していく。



ドライバの対応状況の調べ方

製品のドライバがLinuxに対応しているかを調べるには、(1)その製品が利用しているドライバを調べ、(2)Linuxがそのドライバを公式サポートしているかを調べる必要があります。 1は意外と大変で泥臭い作業が必要になります。 公開されていれば良いのだけど、USB Wi-Fi 無線LAN子機は公開している製品がほとんどないので、人柱の報告に頼るしかない。 「製品の型番 ドライバ」などで検索してチマチマ調べましょう。 候補が多すぎる場合は、まず Realtek 製なので、「製品の型番 ドライバ Realtek」なども併用しよう。

製品のドライバを調べるのは大変だけど、幸いな事にLinuxがそのドライバをサポートしているかは以下のコマンドで簡単に確認できます。
ls -R /lib/modules/`uname -r`/kernel/
このリストと人柱報告による製品のドライバを照合して、一致していればまず動きます。 名称ズレがあると認識してくれないので注意しよう。 一致しなくても、非公式の野良ドライバが公開されていて助かるケースは多いのだけど、先に述べたように動かなくなるリスクがある。 やはり購入前に公式サポートされているか調べるべきでしょう。

Lubuntu 18.04で実行すると、Realtek製品は以下のようなサポート状況が示されました。
:
/lib/modules/4.15.0-45-generic/kernel/drivers/net/wireless/realtek/rtlwifi:
btcoexist
rtl8188ee
rtl8192c
rtl8192ce
rtl8192cu
rtl8192de
rtl8192ee
rtl8192se
rtl8723ae
rtl8723be
rtl8723com
rtl8821ae
rtl_pci.ko
rtl_usb.ko
rtlWi-Fi.ko
:

現時点で良さそうな製品

このリストに含まれていて公式サポートが確認できる「小さな」USB Wi-Fi 無線LAN子機がないか探してみました。 Amazonでヒットしたものはすべて見たつもりですが、ドライバが対応しているのはおそらく、WN-G150UMK と TL-WN725N だけでした。 この 2 つの製品に関しては、実際に購入して、何もせず認識する事も確認済みです。 Wi-Fi周りで困っている方には、手堅い一品になるのでは。



他にも動くものはあるかも知れないけど、型番がない製品が多過ぎる。 そのような製品はドライバの確認のしようがないので、Linuxユーザ的には購入候補には入れにくい。 購入前から「まず動くだろう」と確認できる製品の少なさは残念です。 メーカーもドライバを開示すればきっと売上が伸びるので、是非表示して欲しいなあ。

大きめのアンテナ型モデルは型番がないものばかりで、割とつらいです。

ここ2-3年のエンジンの性能進化が地味に凄い

外車に試乗していてエンジン性能の向上度に驚きました。 車にほとんど乗らない私でさえここ2-3年で体感性能が段違いに進化している事がわかった。 「こいつ…動くぞ!」と私でさえ感じるくらい、静かで滑らかで機敏な挙動に進化していた。 何がどれくらい進化したらこうなったんだ?と思って少し調べてみました。

自動車はまったく詳しくないから間違ってるかも知れないけど、最近の外車のエンジンの仕組みを見ていると、電子制御ターボが売りとの事で、そこが大きいように思いました。 ターボ(チャージャー)というのは下図のような仕組み (Wikipedia参照)。赤い部分に排気が導入され、青い部分で吸気が圧縮される。 圧縮した空気を噴射する事で推進力を得るんだな。



古めの日本の記事を見ているとターボは燃費が悪いと言われてるけど、 試乗した時には以前より燃費も良くなっているとも言われました。 ターボの問題として挙げられがちな初速での燃費の悪さも、実際に運転しているとエンジンの掛かり具合から想像しても、以前よりずっと燃費が良いように感じる。 体感の振動が1/3以下くらい。つまり弱点がない。

日本も電子制御ターボは2年くらい前からやってるみたいだけど外付けだし、中国は独自にやってる (ベンツと手を組んでるからやってて当然という気もする)し、韓国は日本との合弁でやっているようだ。


日本車は昔の燃費の悪さからターボがあまり採用されてないらしいんだけど、 欧州では燃費規制や排ガス規制に適合するためダウンサイジングの要求が強くなり、ターボを採用したらしい。 つまり燃費問題が皮切りになって急激に進化したようだ。 確かに電子制御のターボできめ細かく調整すれば滑らかで機敏な挙動になるし、 路面の凹凸を先読みしてサスペンションを制御すれば静音になる事はわかる。 燃費もたぶんきちんと制御すればかなり抑えられるんじゃないかと思う。

何ていうか、自動車も完全に電子制御の時代だよね。 最終的な結果がEVかどうかではなく、既にITの差が実力の差に直結し始めている事がわかる。 エンジンといういかにも枯れた分野でさえ、たった2-3年でこんなに進化するとは思わなかった。 1/30の記事だけど、スターリングエンジンに言及があった。 水面下ではエンジンさえも大きく動こうとしている可能性がある。 最適形状設計とかDeep某でもようやく動きつつあるから、ハードの世界はこれからが本当の進化の始まりとも言えるのかも。 ターボは燃費が悪いみたいな、安直な認識をしてると痛い目を見そう。 同様の古典的な認識はどんどん覆っていくんじゃないかなあ。

トッププログラマのコーディング速度の凄まじさ

プログラマのアイドルであるmattnさんの、ここ15年くらいで書いたコード量が公開されていた。 驚異的なコーディング能力を持つ事で知られるmattnさんは、一体どれくらいコードを書いてるか。 初めてそのコード量がわかってきた。

1年間にどれくらいのコードを書いているか計算してみると、
1023046/12 +   # C
 355174//10 +  # Go
 156495/15 +   # Vim script
 157427/15 =   # config
146915.866667
計測可能な変更量だけでも15万行/年くらい。でもこれJavaとか入ってないから正確に計測すると一体何行になるんだろう…、20万行は普通に突破してそう。 他にもリポジトリにアップロードされているものしか測定してないし、リポジトリに上げるのはコミュニケーションが増えるからコスト掛かって過少評価されるような問題はある。 この数字だけでも凄まじいけど、より重要なのは「変更量の内訳」だ。

mattnさんは既存の大きなリポジトリに手を加えてる量が凄く多いけど、これ平均的なプログラマからすると通常のコーディングの10倍は時間が掛かる作業だ。 そしてコアな領域は平均的なプログラマでは100倍でも無理というか、対処不能になってくるから測定不能になる。 実際の価値はどんなに過小評価してもそれくらいには見積もるべきだし、すべてのコードのクオリティが凄まじいからなあ。


ところで私はコア領域でOSSの仕事をしている人たちを横目に見てた事あるんですが、普通はコストが高過ぎてコード量が本当に「ゼロ」に近付いていく。 それくらいコストが高い仕事なんですが、mattnさんは早過ぎる。

つまり平均的なプログラマから見たコード量は、適当かつ少なく見積もってもクオリティx2、変更コストx10を加味した数値はある。 ようするにOSS部分のコードだけで300万行/年の価値はある計算になる。 さらにさらに普段のお仕事で書いてるコードはここには含まれないという凄みがある。 お仕事でも同じくらい書いてるとすると、平均的なプログラマ換算では600万行/年くらいは書いている計算になる。

…人智を超えてるなあ。mattn流仕事の極意本が読みたい。

2019年2月18日月曜日

fff: Fuzzy Finding Filer

go-fuzzyfinderという素敵なライブラリが公開されたので、ファイラを作ってみた。 以前作ったファイラにソート機能を付けた感じ。
package main
import (
  "flag"
  "fmt"
  "log"
  "os/exec"
  "regexp"
  "strings"
  fuzzyfinder "github.com/ktr0731/go-fuzzyfinder"
  // termbox "github.com/nsf/termbox-go"
)

var (
  cmdOpt = flag.String("cmd", "ls -al --time-style=long-iso", "command for filtering")
)

func main() {
  var arr [][]string
  var customCmds = [][]string{
    []string{"sort    by time",  "ls -alt --time-style=long-iso"},
    []string{"reverse by time",  "ls -altr --time-style=long-iso"},
    []string{"sort    by ctime", "ls -alc --time-style=long-iso"},
    []string{"reverse by ctime", "ls -alcr --time-style=long-iso"},
    []string{"sort    by atime", "ls -alu --time-style=long-iso"},
    []string{"reverse by atime", "ls -alur --time-style=long-iso"},
    []string{"sort    by size",  "ls -alS --time-style=long-iso"},
    []string{"reverse by size",  "ls -alSr --time-style=long-iso"},
  }

  flag.Parse()
  cmds := strings.Split(*cmdOpt, " ")


  loop := true
  for {
    if !loop {
      return
    }

    ls, err := exec.Command(cmds[0], cmds[1:]...).Output()
    if err != nil {
      log.Fatal(err)
    }
    rows := strings.Split(string(ls), "\n")[1:]  // 0: header
    rowsLen := len(rows) - 2
    re := regexp.MustCompile(`\s+`)
    for _, row := range rows {
      arr = append(arr, re.Split(row, -1))
    }
    for _, cmd := range customCmds {
      rows = append(rows, cmd[0])
      arr = append(arr, cmd)
    }


    indices, err := fuzzyfinder.FindMulti(
      rows,
      func(i int) string {
        return rows[i]
      })
    // if err != nil {
    //   log.Fatal(err)
    // }
    pos := len(re.Split(rows[1], -1)) - 1
    for _, idx := range indices {
      if idx <= rowsLen {
        fmt.Printf("%v\n", arr[idx][pos])
        loop = false
      } else {
        cmds = strings.Split(arr[idx][1], " ")
      }
    }
  }
}

上記はちょっといい加減な実装してるけど、動くから良しとしておく。

使い方としては fff.go という名前で保存し、go build fff.go してバイナリを作る。 以前作ったファイラの代わりに呼び出しても良いし、外部コマンドの呼び出しに使っても良い。 私は以下のように登録してみたけど、まあまあ使い物にはなってるかな。
alias c='cd "`fff ${1}`"; ls'

一瞬で作れて凄いと思った。

2019年2月17日日曜日

vim-lsp + asyncomplete.vimを使い始めた

mattnさんおすすめとの事で vim-lsp + asyncomplete.vim を使い始めてみましたが、これは凄く…良い! 超高速に動作します。

vim の補完ライブラリはもともと凄く便利なものがたくさんあるのですが、 実は私、少し前に補完ライブラリを豪快に切ってしまってました。 Python で Numpy などを使ってる人は同じ経験があるかも知れませんが、 候補が多過ぎてフリーズする事がよくありました。 その後この問題は解決されていたかも知れないのですが、 仕事にならなかったので、それ以来、補完をバッサリ切っていました (そして忘れていた)。 補完がなくても意外と生きていけていたのですが、やっぱあると便利ですね。

vim-lsp + asyncomplete.vim が良いなと思った点は3つあります。
  1. Numpy などの巨大ライブラリでも気持ち良く動く
  2. 必須ライブラリのインストールが楽ちん
  3. 設定が楽ちん (マニュアル通りの設定で気持ち良く動く)

(1) 素晴らしいとしか言いようがありません。Numpy をぬるぬる補完してくれて凄い。 (2-3) 私は設定を書くのが面倒というか苦手なので、設定は極力しません。 ライブラリのトップページに書いてある設定だけで思い通りに動いてくれるのは素晴らしい。

実際の設定はほぼマニュアル通りなので書く必要もない気がしますが、以下のように設定しました。 各言語ごとのインストールの前提条件をよく読めばそんなにつまらないはず。 特によく使っていて行数の増えやすい Python/JavaScript だけ設定してみましたが、必須ライブラリと if executable ... の設定だけで済むなら気軽に言語を増やしていけますね。
Plug 'prabirshrestha/vim-lsp'
Plug 'prabirshrestha/asyncomplete.vim'
Plug 'prabirshrestha/asyncomplete-lsp.vim'

Plug 'ryanolsonx/vim-lsp-python', {'for' : 'python'}
if executable('pyls')
  " pip install python-language-server
  au User lsp_setup call lsp#register_server({
        \ 'name': 'pyls',
        \ 'cmd': {server_info->['pyls']},
        \ 'whitelist': ['python'],
        \ })
endif
Plug 'ryanolsonx/vim-lsp-javascript', {'for' : ['javascript', 'javascript.jsx']}
if executable('typescript-language-server')
  " npm install -g typescript typescript-language-server
  au User lsp_setup call lsp#register_server({
        \ 'name': 'javascript support using typescript-language-server',
        \ 'cmd': { server_info->[&shell, &shellcmdflag, 'typescript-language-server --stdio']},
        \ 'root_uri': { server_info->lsp#utils#path_to_uri(lsp#utils#find_nearest_parent_directory(lsp#utils#get_buffer_path(), '.git/..'))},
        \ 'whitelist': ['javascript', 'javascript.jsx']
        \ })
endif
私の確認した限りでは Ruby はまだきちんと動かない感じでしたが、とても期待の持てる感じでもありました。 まだまだ発展途上の感じはありますが、今後に大期待です。


2019-12-25: mattn さんお手製のプラグインとして mattn/vim-lsp-settings が出てきました。 このプラグインを使うと if executable ... の設定も不要になり、上記の設定は以下に短縮できます。 また言語ごとに必要な Language Server のインストールも :LspInstallServer コマンドを打つことで、一発でできるようになりました。
Plug 'prabirshrestha/vim-lsp'
Plug 'prabirshrestha/asyncomplete.vim'
Plug 'prabirshrestha/asyncomplete-lsp.vim'
Plug 'mattn/vim-lsp-settings'
" ここから下も :LspInstallServer に頼れば書かなくていい
" Plug 'ryanolsonx/vim-lsp-python', {'for' : 'python'}
" Plug 'ryanolsonx/vim-lsp-javascript', {'for' : ['javascript', 'javascript.jsx']}
これは楽ちんだ!

2019年2月16日土曜日

vimで巨大なファイルを開く

vimで巨大なファイルを開かないといけなくなりました。 そのような時には以下のコマンドで開けば気楽に編集できる事が知られています。 ただこれは設定ファイルを読み込まない方法なので、ちょっとした編集をしようとした時に使いにくい。
vim -u NONE test.xml


解決策を考えてみました。

1. 巨大ファイル用の設定ファイルを用意する

NONEのところを巨大ファイル用の設定ファイルに置換します。 クリップボード経由のコピペができると嬉しいので、Neovimの設定例を以下に載せます。
syntax off
set clipboard=unnamedplus
上記を ~/.config/nvim/simple.vim などと保存し、以下のコマンドで起動します。
nvim -u ~/.config/nvim/simple.vim test.xml


2. 起動オプションでシンタックスハイライトをOFFにする

巨大ファイルではシンタックスハイライトが重くなる一番の原因なので、そこさえ切れば十分かも知れません。 その場合、以下の方法で十分です。
vim "+syntax off" test.xml
私はこちらの方法をメインで使ってます。


Linuxでは巨大ファイルを開くための専用エディタとかを用意するのは難しいので、困った時はやはりvimに頼るしかないですね。

2019年2月10日日曜日

フリゲ紹介: Sacrifice -サクリファイス-

Sacrifice -サクリファイス-はロックマンちっくなアクションゲーム。 あっさりしたゲームですが、こういったミニアクションは気軽に楽しめるので、最近は結構好きです。



前置きもなく唐突に始まるのですが、プレイを進めていくと創造主を名乗るアカシャと話をし、その命令を聞いて敵を倒していく事になります (左下)。 アクションはロックマンそっくりなのでプレイしやすいです (右下)。



武器はノーマルショットだけではなく、もちろん特殊武器もありますし (左下)、ボスも居ます (右下)。 特殊武器が増えてくると結構面白くなってきます。



ステージの概念はない作品ですが、全部で4ステージと考えると良さそうです。 1時間くらいでクリアできるので、短時間で楽しめて良い作品でした。

フリゲ紹介: 【リアルタイム将棋】有閑妖精の盤上遊戯

【リアルタイム将棋】有閑妖精の盤上遊戯は、ターン制を廃止した将棋ゲーム。 将棋のルールを知ってれば何となくはプレイできます。



将棋が初心者の方も「お知らせ」機能をONにすれば (左下)、色々なヒントを提示してくれるので (右下)、将棋の勉強にも良いかも知れない。 通常の将棋とはまったくコツが異なるのでおすすめしてはいけない気もするけど…。



有段者でもかなり歯ごたえのあるゲームです。 私も段位くらいは持ってるので、普通にやればターン制がなくても負けないだろうなどと思っていましたが…、何回か負けました。 とにかく慎重に指さないと酷い事になる。

まず王将の生命力がヤバイ。すべての駒で包囲網を組んで抹殺しに掛からないと酷い事になる事があります。 これ王将だけ若干速度が早いんじゃないかなあ。 フリーモードの光速でプレイしたら玉単騎で粉砕された事がある (左下)。 相手側には王将くらいしか駒が残ってないのに逆転されかけた事もありますし、駒を取られ始めるといきなりキツくなりますね。 他にもと金1枚に蹂躙される事もよくあります。 例えば右下のような画面で2七とを放置すると、一瞬で敗勢になりかねません。



このゲームのコツというか複雑な理由は、駒を取ろうとしている待ち時間に、間に駒を挟んでブロックできる事です。 ブロックすると指手が無効化されるため、被害が予想以上に拡大する傾向がある。 攻撃をブロックされて大駒2枚とも取られて負かされた事があります。

普通の将棋とはまったく違った神経の使い方をするゲーム。単純ですが面白いですね。

2019年2月2日土曜日

ドイツの肉食文化の衰退は興味深い

ベジタリアンやヴィーガンの増加についてテレビで放送しているのをたまたま見ていました。 ベジタリアンやヴィーガンというのは肉食文化のない人たちの事です。 訪日外国人の5%がベジタリアンで、欧州ではかなり増えているらしいです。 そしてヴィーガンが暴徒化して肉屋さんを襲撃したりする事もあるとか。 将来的に食糧危機で肉食文化は衰退するとも言われてますが、 ソーセージで有名なドイツでは既に売上が15%近く落ちているとの事で、食品分野でそれは凄い数字です。

ベジタリアンとヴィーガンの増加は、クジラに対する日本と世界の差のような何かを感じなくもなかったのですが、何かちょっと違うような感もありました。 テレビでは肉食文化の変化は動物愛護、環境問題、食料問題が起因と言われていましたが、もっと根源的な理由があるのではないかと感じました。



何となく検索してみて、気候の変化による考察などは、ああそうかもなと思いました。 冬の厳しさや保存食としてソーセージやハムが発達したという考察があったのですが、 今となってはそのような問題は起きなくなっている。 ようするに科学技術の進歩によって、食文化も少なくとも影響を受けているとも考えられる。 イスラム文化の流入とも言われていて、これも納得感はある。 この2つによるマインドの変化は大きそうな気がする。


日本は今後かなりの多国籍国家になりそうな気もしているのですが、 アジア圏の流入が一番多いだろうとは言え、イスラム圏の方も相当量の流入があると思います。 となると宗教の取り扱いってかなり重要になってくると思う。 ドイツのようにキリスト教な国にイスラム教が流入すると、まあ相性は悪そうではある。 一方、日本は八百万の神という最強理論があるので、私にはどうなるかあまり予測が付かないです。 八百万の神な国に対して宗教理論をぶつけても、そういう神様も居るよねという解釈になる利点がある。 それでも影響ゼロは無理でしょうね。何らかの変化は起きるでしょう。

ところでドイツは人口が増えている国なんですが、人口の20%が移民とも言われているし、急速に移民の数が増えている。 そして人口の16.5%が貧困とも言われていて、色々感じるところはある。 特にちょっと気になるのが人口の中身で、きちんと調べた事はないけど、純粋なドイツ人人口の減少は移民を無視すると日本と大差ない可能性もあると思ってる。 例えばこのグラフを見るとパッと見でも移民によって平均50万人/年の人口増があり年齢を押し下げているように見えるのですが、これは全体の人口増加よりたいてい大きな量ですから、正直移民がなければ日本の人口減少の状況とそこまで変わらないようにも思えます。 ちなみに日本では人口の11.5%が移民で、貧困率は15.6%です。

何にしても気候や人口が何らかの臨界点を超えると、 精肉というメジャーな分野でさえクリティカルな変化が起きるという、良い例と思いました。 どのような形かはわかりませんが、日本の食文化にもそのうち変化があるのかも。 ご飯を食べる人の減少などが既にそうなのかも知れませんけど。 ドイツは移民や社会構造から見ると非常に参考になる国ですから、色々見ておきたいなと思いました。

バブルと仲介業と手数料

中間業者の手数料に変化が進んでいるように思う。 その根源にあるのは仲介業者の利益が実店舗と比較して優位過ぎる問題なのかも知れない。

一番わかりやすい例はアプリストア。 Apple/Googleはロイヤリティを最近30%→15%に変更しましたNetflixなどの大手の影響かなと思っていたけど、 30%の手数料が独占禁止法に引っ掛かる可能性があるとさらっと書いてあって、私はこのニュースを見逃していたので、あーそっちのほうが大きいのかもなあと思ったりしました。これも元ネタは2018/11/26の記事ですから、どのような判決になるかはわからないけどやはり直近で大きな変化が出始めている事がわかる。仮に独占禁止法が確定すれば、Appleに限らず割と大きな変化になる可能性がある。 まあいずれにしても高ロイヤリティは、それを払うだけの効果が望めないと利用する意義がないので、維持するのは存外に難しいんだけども。

そもそも世の中のロイヤリティがどれくらいかというと、eコマースのテイクレートは10%もないし、 フィンテックのテイクレートは3%以下である。 でもAdSenseの収益分配率は68%だし、まさに業界次第という感じはある。 Adsenseとかこれだけマージンを取っても実質的な還元率は一番高いしね。 日本ではアパレル業界では35%近い手数料が掛かると聞いて驚いた。 スマホのようにマシンの維持費しかないアプリストアで15%が相場なら、 店舗維持費の高いアパレルで、35%の手数料は相当きついんじゃないだろうか。 でも家電量販店って40%くらいロイヤリティ取ってるとこもあるらしいです。 ほんと業界次第。


別業界の色々なロイヤリティから言うと、私はリアルなら20%以下を基本に考えてる。 私の感覚だと、20%のロイヤリティというのは大手の採用する余裕のある数字なので、そこからどれくらい下げられるかという感じ。 アプリストアがそれを割り込んできたので、20%が平均という感覚にも少し割高感が出ているかも知れない。

ロイヤリティや消費税、手数料は馬鹿にならない。 仮にロイヤリティを変化させても1000円の固定利益を得ようとした場合、必要な価格設定は以下のようになる。
  • 5%: 1053円
  • 10%: 1111円
  • 15%: 1176円
  • 20%: 1250円
  • 30%: 1429円
10%までならさほど割高感を感じないけど、15%でちょっと高いかな、20%を超えた辺りから明らかに割高と感じないだろうか。 人間の感覚は不思議なものである。


ついでなので直近1-2年のロイヤリティ引き下げニュースを少し調べてみた。 やはりカードとアプリストア辺りの話が大きいかなあ。


そもそも仲介業者というのは実店舗より圧倒的にリスクが少ないので、 本来なら実店舗以下の利益率に抑えて業界全体を大きくする立場にある。 20%のロイヤリティでも仲介業者だったりフランチャイズの元締めのほうが有利だと私は思ってるし、 30%のロイヤリティを取ったらたいていのケースで仲介業者のほうが儲かると思ってる。 そういうのってまさにバブルそのものの問題だよなと私は思った。

ただこのような数値の適正値も効率化のレベルによる。 非効率な産業では40%でも安く見える事もあるかも知れないし、効率的な産業では5%でも高く見える事は実際にある。 適正値は海外とも影響を及ぼし合っているので、仮に世界平均が5%で日本が10%なら、日本はバブルと言えるのであろう。 これをよく考えると不景気でもバブルなものはたくさんあって、具体的に何がバブルを作っているのかが、少しわかった気がした。

ただ直近1年で急激にこの点が是正され始めてきており、世の中が思いのほか面白い事になってきている。 もちろんチャンスもあると思う。