今年買った物で生活が劇的に変わったものがこれです。BEKANThttp://www.ikea.com/jp/ja/catalog/products/S59022793/別にイケアである必要もなくて、価格が安すぎず、作りのしっかりした、そして広い机であれば何でも良いのです。(むしろイケアは表面加工が防滴仕様ではないっぽいのでオススメしない)どういうふうに生活が変わかというと、机の上に資料をどっさり置いたときとか、ものの整理するときとか、買った物の写真を撮るときとかのワークスペースとして、おおよそ考えられるストレスから解放される点です。シンプルでコンパクトな生活を目指す最近の風潮とは反するかもしれませんが、机はモノではなくスペースです。作業場所は広いに越したことは無いです。PCに詳しい人なら、CPUの性能を上げるよりメモリを増やす方がコストパフォーマンスが高いと言うとよく分かると思います。部屋が狭くてもいいので、机は持て余すくらい広いものを買いましょう、というのがこの記事で主張したいポイントです。どのような環境で使っているか我が家はひとり暮らしの1Kマンションで、部屋の広さは6畳程度。狭いので今までは120cm×60cmの4本脚の机(大昔に買ったイケア)とアーロンチェアを使っていました。この環境だとストレスに感じる点がいくつかありました。4本脚なので、椅子を引いたりターンさせたりする場面で自分の足に当たってしまうことがありました。次に、机の上にものを置いたときに狭いので、肘で倒してしまったり、書類の山を崩してしまったりすることがありました。それからこれは椅子の話なのですが、どうも回転機能・キャスター機能付きの椅子が自分には合っていないようで、カフェなどにあるシンプルな椅子の方が作業が捗るということがありました。そこで以下のように環境を変えました。・机の脚を4本脚から2本脚タイプに変更それから椅子も。机が6畳に対して大きすぎないか、と思われるかもしれませんが、PCに向かう時間のことを考えるとこれくらい確保した方がQoLは上がると思います。小難しくいうと、机の面積が生み出す限界効用は机がスペースを占有することで失う限界損失を上回っていると思います。高さ調整機能がついているので、私は高さ67.5cmにして使っています。椅子についてベンチ式の椅子はローテーブルを使用しています。折りたたみテーブルhttp://www.emoor.jp/fs/emoor/table/az-ewt002足置きもローテーブル。STR-50L(FBR)https://www.amazon.co.jp/dp/B0056WWAEQ?tag=yagi-22高さ35cmであれば形は何でも良いですし、折りたたみ式でなくても構いません。うちに手頃な物があったので活用しているだけです。背もたれがなくなったことでダラダラ作業が減りましたし、私はもたれるものが無いと背筋を伸ばすタイプなので背筋も伸びました。椅子が固定になることで体制の自由度が広がりました。あぐらを無理なくかけるようになりました。アーロンチェアであぐらをかくと少し無理があるし姿勢も悪くなるので自重していたのですが、そうしたストレスからも解放され、好きなときに好きな体勢をとることができます。すると私には畳生活の方が向いているのかもしれません。掃除について机が広くなることで埃が堆積する面積が増えます。これはデメリットだと思います。クイックルワイパーなどを活用して対処するしかありません。まとめ半分くらい椅子の話になってしまいましたが、広い机はストレスを低減させます。皆様も持て余すくらいに広い机を導入されてはいかがでしょうか。2017年に買ってよかったものおまけですが、手短に紹介します。Z581KL-BK32S4読書タブレットその1。Nexus7の後継として購入しました。画面比が4:3なので読書をするのに快適です。16:9とか使えません。S92/T読書タブレットその2。リース品と思われる中古美品が格安で秋葉原に大量在庫されていたので購入。12.9′′とこれ以外に見当たりません。雑誌を読むにはこれくらい大きくないと苦しいです。24時間装着しています。睡眠時間の記録を完全自動でやってくれて精度も高いので重宝しています。acSOHO用無線LANルータ。Serverからルータに移行するために導入しました。日本語マニュアルがありませんが、設定が柔軟にできるところが気に入っています。技適マークの付いている正規代理店で買いましょう。Dart汎用ACアダプタ。劇的なコンパクトさです。Canvasの純正アダプタが重くて使ってられないのでこちらに置き換えました。サポート対象のPCはよく確認して使いましょう。楽天が携帯電話サービス事業に参入することが発表されました。これについて現状の整理と、今後どうなるかを公開資料から読み取ってみたいと思います。数字のない部分は全部推測です。参入スケジュールについて楽天のプレスリリースによればサービス開始予定は2019年中です。今回確定しているのは総務省が1.7GHz帯/3.4GHz帯の割り当てを受け付ける際、楽天が新会社を設立して申請を行うところまでです。実際に割り当てられるかは総務省による決定によります。名乗りを上げるということはそれなりに見込みがあるのでしょう。1.7GHz帯/3.4GHz帯の割り当ては2017年度末までを目処としているので、それに向けて審査期間などを逆算するなら事業計画などを含めて今後1〜2ヶ月のうちに申請を行う必要があります(総務省の受付期間は未開始・未定)。事業計画の大枠は楽天のプレスリリースの通りになるでしょうが、具体的な数字についてはまだ分かりません。1.7GHz帯はまだ立ち退きが終了していないため、終了促進措置を含めて数字を合わせる必要があり、既存事業者と総務省とである程度呼吸を合わせないといけません。これは邪推ですが、もしかしたら既に何らかの示し合わせがあっての申請かもしれません。1.7GHz帯/3.4GHz帯の割り当ての背景について現在日本の携帯電話事業は大手3社とそのグループによる寡占状態となっています。総務省はこれを良くない状態と考えています。過去に周波数割り当てを行った時はイー・モバイル(現ソフトバンク)やアイピーモバイル(参入断念)等の新規参入がありました。総務省は大手3社以外の新規参入事業者に対して制度上様々な便宜を図ってきましたが、現在はすべての新規参入事業者が大手3社のいずれかに吸収されるという状態になっています。プラチナバンドと言われる700/900MHz帯の割り当てに際しては、イー・モバイルへの割り当て決定後にソフトバンクグループに買収されたために、割り当てが結果的に公正にならなかったという批判を受ける事態となりました。総務省はこれを教訓として、4G用周波数では周波数を一体運用する企業グループからの複数申請を認めないなどの対策を導入しています。これで他業種から新規参入しようとする企業が周波数割り当てを受ける環境が整ったと言えます。最大残高6,000億円の資金調達について楽天のプレスリリースでは、資金調達残高は2019年のサービス開始時で約2,000億円、2025年で最大6,000億円とあります。単純な比較だとイー・モバイルの当初の資金調達額は3,600億円なので、2,000億円はこの6割程度です。イー・アクセスの決算資料によると2009年3月末(サービス開始から2年時点)の有利子負債残高が1,038.9億円、2010年9月の有利子負債残高が2,766.8億円(このあたりがピーク?)とありますので、残高2,000億円はこの間くらいになります。当時のイー・モバイルの親会社イー・アクセスと比べて楽天本体の事業規模は相当大きいですので、スタート時は大規模な資金調達で集中的な設備投資を行うものと推測できます。比較する対象が違う話ですが、NTTドコモ(7,500万人)の年間設備投資額はコンスタントに6,000億円、イー・モバイルのピーク時(2006年度)の年間設備投資額が1,000億円程度です。時期未定ながら契約者1500万人という数字を挙げつつ最大負債残高6,000億円はずいぶん控えめのように思えますが、このあたりはひとまずぶち上げただけかもしれません。楽天にとって通信事業の荷は重そう楽天の事業の柱となっているEコマース事業やカード事業と比べて、通信事業はかなり重く大きい事業になります。最初の数年は莫大な赤字を流し、他事業で支えることになるでしょう。このようなドメスティックで泥臭い事業は、本来なら楽天としては銀行業のように買収によってショートカットしたかったことでしょう。楽天は過去にも楽天スーパーWiFi(イー・モバイルとの協業)や楽天モバイル(MVNO)、Viber(IP電話)、フュージョン・コミュニケーションズ(長距離通信)など間接的に通信事業に参入しています。事業売却が容易なそれら事業と比べて、MNO事業は公益性が高く機動性に欠ける巨大ビジネスとなります。グループ経済圏を拡大して売上高の嵩増しができる・月次の売上が安定するというメリットはありますが、反面で通信事業者として各種規制の対象になり、もし事業失敗しても周波数割り当ての経緯上ほかの通信事業者による救済も期待できません(イー・モバイルの二の舞になり総務省のメンツが許さないでしょう)。大きなリスクを取りに行ったなと思います。完全に憶測ですが、外国系企業が参入しようとしたのを総務省が察知して、対抗のために渋る楽天を説得して参入させたとかだったら面白いなーなんて仲間内で話しています。ユーザにとってのメリットは個人的には、解約周りなどのオペレーションで特に評判の悪い楽天モバイルという印象があるので、行儀の悪い通信事業者がまた一社増えたなーという感じです。ユーザメリットは特にないと思います。初めこそ安くシンプルな価格体系だったイー・モバイルやUQコミュニケーションズも現在では大手3社と大差ありませんので、同じような結末を辿るでしょう。サービス展開についてイー・モバイルやUQコミュニケーションズのサービス展開シナリオが参考になります。費用対効果の高い東名阪の人口密集地と東海道新幹線沿線を埋め、続いて地方都市とJR幹線沿いに広げていく流れです。大手キャリアほどの体力はないでしょうし周波数帯も高いものを使用しているので、山間部の整備は永遠にされないと思います(総務省は許さないでしょうが)。過去のツーカーグループのように東名阪だけを整備して後は他社のローミングを使うという方法も考えられます。今後プラチナバンドと呼ばれる700MHz帯/900MHz帯あたりがまた再編されることがあれば山間部カバーも現実的になりますが、再編したばかりですし空く予定もないので期待薄でしょう。ショップ展開について大手3社は全国に代理店網を持っているため、対抗上おそらく同様に代理店を整備するかもしれませんが、津々浦々に整備すればするほど費用対効果が下がり間接コストは上がります。量販店レベルにしか店舗を持たないMVNOの考え方で少数に絞った方が安上がりです。Eコマース事業とのシナジーを狙って小売窓口と一体整備する(イオンモバイルの逆)とか、自前配送会社の足がかりとして一体整備するとかだと勝算があるかもしれません。楽天モバイルはどうなるMNO事業があればMVNO事業を持つ意味が薄れますので、今までのように積極的に販売することはなくなるでしょう。ソフトバンクがPHSユーザを巻き取ったように、各種キャンペーンで契約者の移行を促すことになると思います。既存約款の設定によっては、サービスの卸元をドコモから新MNO会社に強制移行するかもしれません。この場合は全契約者のSIMの差し替えが必要になるのでそれなりの反発が予想されます。eSIMの時代になればこうした問題は解決すると思いますがまだ時間がかかるでしょう。音声サービスについて総務省の資料をちゃんと読めてないのですが、周波数割り当ての条件に音声サービス提供が入ってないように見えます。持分調整などの面倒くさいもろもろが発生すると間接コストが増えます。するとノウハウのあるフュージョン・コミュニケーションズに一本化する算段があるのかもしれませんし、データ通信オンリーにしてViber等のIP電話をセットにする(つまり緊急機関には繋がらない)ことにするという離れ業を使うのかもしれません。音声通話以前に、3Gの設備を持たずLTE網だけで参入できる時点でランニングコストはかなり圧縮できるものと推測します。機種調達について4G対応機種が今後どのくらいの速度で普及するか分かりませんが、ラインナップは1.7GHz/3.4GHzに対応した機種がグローバルでどのくらい出るかに依存すると思います。この辺りはあまり詳しくありません。おわりに以上、部外者がテキトーに分析と予想をしてみました。ツッコミなどありましたら追記していこうと思います。2017の4日目の記事です。Dotを発売翌日に入手して意気揚々とセットアップしたものの、USとJPでアカウント結合しているのが良くなかったのか「居住国設定が正しくありません」と言われてうまく動いてくれません。仕方ないのでサポートに連絡したもののなしのつぶて。Skillsを開発しようとしても、SkillsやLambdaの設定までは行くもののアプリのスキル選択画面に反映されず、これまた断念。これでは書くことがないので、もし問題が解消されたらこのように動かしたいというユースケースを説明してお茶を濁すことにします。Piで組んだ自作スマートホームシステムがあります。Dotを音声認識トリガーとしてのインターフェースに位置づけます。Dotが追加される形になります。2017の2日目の記事です。イラストを描くようになって3年が過ぎました。はじめは手持ちの適当なシャープペンを使っていたのですが、日々のコンディションの高低がペンに左右されているような気がして(おそらく気のせいですが)、ちゃんとしたペンを買おうと思ったのが去年の年末のことです。GRAPH1000」を使っています。太さは0.5mmと0.3mmの2本。価格は1000円とお高めですが、重心が低くて持ちやすく、ペン先が細いので見通しが良く重宝しています。はじめは0.5mmの2Bを使っていたのですが、精密なものを描くにはより細いバリエーションが必要になり0.3mmのBを買い足しました。その後0.3mmも2Bで統一して現在に至ります。0.3mmの2Bはあっという間に芯が無くなるので、楽に描ける落書き用途は基本的に0.5mmの2Bです。イラスト用途に製図用のシャープペンを使うのは一般的ノウハウの一つらしく、中でもできるだけディスコンにならないものを買おうとロングセラーの商品としてこれを選択しました。ZERO」、描くのに使う用紙はA4のコピー用紙を使っています。キャンパスノート(スリムB5サイズ)無地」を使っていましたが、ノートである必要が無いことに気づいたので(記録が取れればそれで良い)、先月からコピー用紙に描いてはiPhoneのカメラでEvernoteに取り込み、紙は捨てるという運用になりました。2017の1日目の記事です。本棚の本をすべて自炊で電子化しました。実際には本棚と言うよりは山積みの段ボールに入った本だったのですけど、それがなくなり部屋がすっきりしたところで、ふと思うことがありました。電子化した本はすべてPDFになりました。購読している有料メルマガなどはメールの他にEPUBでも配信しているので、PDFとEPUBの二種類。これらをどのように読むかという問題が持ち上がったのです。手元にはデスクトップPCと多数のタブレットがあります。E-Ink端末もあります。今まで現物の本を持っていたことで隠れていた「どのデバイスでどのように本を読むか」という問題が、大問題として持ち上がってきたのです。電子化されることによって、本は画面を用意しなければ読むことができなくなりました。本ごとにバラバラだったサイズや重量が一律に、デバイスのサイズや重量に依存するようになったということです。これは一方で自由度が増したとも言えます。机に向かって読むなら液晶ディスプレイで拡大して読めますし、横になって読むなら小さなタブレットやスマートフォンで読めるようになったのです。話は自炊から脱線しますが、電子書籍の捉え方が人によって異なる理由の一つに「どのデバイスで読むかの想定が人によって異なる」というのがあると思います。スマートフォンしか持っていない人はスマートフォンという環境に限定されますし、多数のデバイスを持っている人はマルチデバイス環境での読書体験を想定することになり、両者には分断があります。プラットフォームの対応デバイスが限定されていれば、読書体験もそれに依存して限定されることになります。我が家には複数のデバイスがありますので、それぞれ適した場面で適したデバイスを選択して使うことができます。続きは明日以降にしようと思います。Touchが転がっています。5年前に友人の米国出張で買ってきてもらったやつで、けっこう当時としては優秀なデバイスです。ハックしようと思ってずっと放置していたものです。これを今更活用してみようと思い立ちました。rootを取る方法などを掲載したブログなども多数リンク切れになっています。そもそも検索して出てくる情報なんて最新でも2013年かそこらの記事ですし、日本語記事も数少ない。逆に言うとそれだけ枯れきっていて、うまくドキュメントを探せばやりたいことが全部インターネットに書かれてあります。そんな玄人好みの遊びをやってみることにしました。結論から言うと、このデバイスが持っている潜在能力を引き出して電子書籍リーダーとして活用することに成功しました。私のように死者を現代に復活させようという変わり者たちの為に、いくつか有用な情報を記すことにします。技術ポスターを額装しました某氏から、ポスターは額装すると綺麗に飾れるらしいという話を聞き、部屋に貼ってあったポスターを額縁専門店の世界堂に持って行って額装してもらいました。900mmの既製品にハマり9000円で済みました。同じポスターはこちらから購入できます。雑記エレガントなパーマリンクとはこのブログを開設してから17年、現在のドメイン(yagi.tc)を使い始めてから12年になりますが、マイナーccTLDということもあり、相次ぐ値上げと運用上の制限が気になるためにドメイン移転をすることにしました。ものはついでで、どうせ301リダイレクトを設定するのならブログのパーマリンクもより運用しやすいものに変えようと考えました。ブログに適したパーマリンクについて日本語でいろいろ調べてみても、SEOに有利かどうかについて書かれたエントリしか見つからず、しかもその内容もそれぞれ根拠のない内容を扱っているだけで、ベストプラクティスのようなものは存在しないようでした。それならひとつ自分が情報を整理してエントリに仕立て上げてみようと思い、ここにまとめることとします。前提として、個人が所有するブログのパーマリンクに主眼を置くこととします。分野をあまり絞らないパーソナルな内容で、長期間の運用をし、独自ドメインを持ち、WordPressなどのCMSでパーマリンクを選ぶときに、ハテどうしようかと悩んでいる私のようなひとのための検討材料です。近年は「URL」のことをより広い集合である「URI」と呼ぶこともありますが、このエントリではブログのパーマリンクを主眼にしている意味合いから「URL」で統一しています。コンテンツのURL全般を指す場合は「URL」、ブログやその他コンテンツが一意に持つパーマリンクのみを指す場合は「パーマリンク」と呼んでいます。参考資料と現状認識コンテンツのURLについては検索エンジンGoogleによってガイドラインが公開されています。コンテンツに関するガイドラインhttps://support.google.com/webmasters/topic/4598733?hl=jaざっくり「シンプルかつ論理的で可読性のあるURLにしなさい」と書いてあります。そのためにコンテンツに対して一意であることが望ましく、IDを使用するよりは意味のある単語を使用した方がよいようです。Platformが公開したAPI設計についてのブログエントリです。URLshttps://cloudplatform.googleblog.com/2017/10/API-design-choosing-between-names-and-identifiers-in-URLs.htmlこれは人間が理解するブログではなくコンピュータが理解するAPIのための内容ですが、両者に共通する思想を持っているために、上記のガイドラインよりも一歩踏み込んだ内容として手本となります。内容を紹介すると、例えばhttps://ebank.com/accounts/a49a9762-3790-4b4f-adbf-4577a35b1df7のようなIDを使用したフラットな構造のものとhttps://library.com/shelves/american-literature/books/moby-dickのような分類による階層構造を伴うものとあり、両者にはトレードオフが存在し、より好ましいのは後者のように見えるが、一概にそうだとは言えないということが書かれてあります。前者はパーマリンクとして、後者は検索のために使用して両立させるという例が挙げられています。実際のブログのパーマリンクの主流はどのようなものでしょうか。使用されているCMSであるWordPressでは、規定値のパーマリンクはhttps://example.com/?p=1のような形式になっています。他に、日本でもっともユーザ数の多いブログサービスであるLivedoorブログでは、https://example.com/archives/52017243.htmlのような形式になっています。いずれもエレガントとは言えないようです。エレガントなパーマリンクとはでは「エレガント」なパーマリンクって何なのでしょう。突き詰めるととても主観的な話になってしまいますが、基本的にはGoogleのガイドラインにある「シンプルかつ論理的で可読性のあるURL」でよいと思います。そこに私は「運用が単純であるURL」を加えたいと思います。この重要性については後述します。これらの各要素を順番に確認していこうと思います。シンプルさと可読性を両立させるURLとはまずはGoogleのガイドラインにある「シンプルかつ論理的で可読性のあるURL」を見ていきます。シンプルさを優先する(短縮URL)もしこれを「シンプルかつ論理的」の方向に突き詰めるとどうなるのでしょう。Twitterで使用されている短縮URLサービス「t.co」の例です。https://t.co/nEDMKlFpP4人間にとってたいへん読みにくいことを除けば「シンプルかつ論理的」であると言えるでしょう。冗長な部分を廃してもっとも短く、かつ一意になるURLです。短いことの利点は単純で無駄がないことです。保存に場所をとらず、通信するのも短時間で終わります。(あくまでURLは、の話です)このURLが生きるのはもちろんTwitterです。Twitterは一投稿あたりの文字数に厳しい制限を課しています。どのような長いURLであっても、URLが投稿に収まりきらないということはこれでなくなりました。URLが短いことの利点はモバイル環境でも発揮されます。これは短縮URLサービスを指した話ではなく、URLが短いこと自体についてです。モバイル環境ではブラウザのアドレスバーに表示される文字数が限られるため、より少ない文字で収まるURLであれば、人間にとって認識できる情報量が増えます。(※ただし認識できても理解できるかどうかは脇に置きます。短縮URLサービスでは本来URLから推測できる情報が欠落するため、フィッシングサイトの温床になっている現実があります)短縮URLサービスではなく、そのサイトのパーマリンクを「人間が理解できないほどシンプル」にしている例として以下があります。YouTubehttps://www.youtube.com/watch?v=3RDYVVmVR2U実のところ冗長であまりシンプルとは言えませんが、投稿された動画がいくつになろうと対応できる柔軟性と、それでいてURLの長さがほぼ変わらない安定性を持っていることは特筆すべきです。私ならもっと短縮URLチックに「https://youtube.com/3RDYVVmVR2U」とするところです。Qiitahttps://qiita.com/toyoshi/items/f40e6440e50b3fc5ccd9こちらもやや冗長ですが、エントリのハッシュ値をとって擬似的に一意にするという発想は特筆すべきです。Gisthttps://gist.github.com/toriwasa/7e1464d8050a596705793770fe15823416進数のハッシュ値よりさらに短くできるBASE64で良いのではないかと思いましたが、URLのルール上「/」が含まれてしまうのが微妙なので16進数で手を打っているのかもしれません。共有ノートhttp://www.evernote.com/l/ABANAls7iwVNvokclFwn2Vb-1jP8QVjXAsP/人間の理解を一切考慮せずBASE64的なURLにしており、たいへん合理的です。Qiitaに比べて衝突可能性も格段に低いと思われます。可読性を優先する(冗長なURL)上記の通り、シンプルで論理的なURLを追求すると人間の理解が難しい文字列になります。このため、たとえ短くても人間がコピー&ペースト以外で手打ちしたり読み上げたりする場合は大変です。多少冗長であれば手打ちや読み上げ時に間違いがあってもエラー訂正が可能ですが、人間の理解ができないURLでは訂正を期待できません。そこでスラッグ(slug)を使うという方法があります。私のブログはこの形式です。yagi.tchttps://yagi.tc/archives/2017/10/16/always-on-ssl/上記の例では“always-on-ssl”の部分がスラッグで、全エントリ中一意になるようになっています。設定を変えて、もっとシンプルにhttps://yagi.tc/always-on-ssl/とすることもできます。ある程度シンプルかつ論理的な形を保ったままで人間に理解しやすい形にするというバランスの取れた解決策です。Analyticsなど、配下のURLを大量に認識する必要がある場合にとても役立ちます。スラッグの難点は、タイトルとは別にいちいち設定する必要があることです。英語圏の人がエントリを書いたなら、自然とタイトルや本文はASCIIに収まるのでスラッグを設定しやすい(何なら自動で設定させても良い)のですが、ASCII以外の文字(マルチバイト文字)を使う文化圏の人にとってはどうでしょうか。WordPressでスラッグを有効にした場合、他に何もしなければタイトルの前から何文字かが自動でスラッグになります。日本語で書けば当然マルチバイト文字になります。困ったことに、スラッグがマルチバイト文字で設定され、URLもマルチバイト文字を含む形になった場合、URLエンコード(パーセントエンコーディング)が発生します。エンコードされたURLはとても長くなり、人間の理解ができない形になります。Wikipediaのパーマリンクがよい例です。Wikipediahttps://ja.wikipedia.org/wiki/%E3%82%B9%E3%83%A9%E3%83%83%E3%82%B0URLエンコードされる前は「https://ja.wikipedia.org/wiki/スラッグ」となりますが、このページを表示してアドレスバーからこのURLをコピー&ペーストした場合、ブラウザによってコピーされる文字列が異なります。Chromeなら「https://ja.wikipedia.org/wiki/%E3%82%B9%E3%83%A9%E3%83%83%E3%82%B0」が、Edgeなら「https://ja.wikipedia.org/wiki/スラッグ」が入ります。このように表面的にはマルチバイト文字はきちんと表示されても、内部的にはエンコードされた文字列になるので実装がまちまちで、とても厄介です。はじめからASCIIに収まる形にした方がよさそうです。タイトルも本文も日本語なのにスラッグをどうやって付けるのでしょうか。タイトルの日本語が「このサイトを常時SSL化しました」なら「konosaitowo-joujisslka-shimashita」にすればよいのでしょうか。これだと可読性に乏しく、URLエンコードされた文字列とあまり変わりませんね。スラッグを使っている多くの人は英単語を利用して設定していると思います。内容が日本語なのにわざわざ和英辞書を引いて英単語のスラッグを付けるなんてちぐはぐで、ちっともエレガントじゃありませんよね。するとQiitaがハッシュ値を利用しているのも、内容がマルチバイト文字であることを前提にこうした仕様にしているのかもしれません。これについての解決策は特に思いつきません。私たちはエントリを書くたびに和英辞書を引くか、自動でID番号やハッシュ値が設定されるようにするかの、どちらかの(あまりエレガントではない)選択肢を選ぶしかなさそうです。ASCII文字以外を用いる言語圏のサイトを少し見てみましたが、ロシア語では英単語で代替、フランス語やスペイン語では発音区別符号を無くした母国単語と英単語の混在などの形にしているようです。長期的な使用に耐えるURLとはブログのパーマリンクについてSEO的にどのようにすればよいか書かれたエントリは多数ありますが、正反対のことを主張する二つの勢力に分かれているようです。それは「カテゴリをパーマリンクに含めるか否か」です。WordPressのパーマリンク設定を変更して、SEOや日本語URLの対策をしようhttps://liginc.co.jp/web/wp/customize/148458http://トップレベルドメイン/カテゴリー名/投稿名(英数字)「http://liginc.co.jp/web/wp/custmize/145732」という形ですね。見ただけでも、Web関連でWordPressのカスタマイズにまつわる記事なんだろうな、ということが想像できるようになりました。結論から言うと、おおむね上のようなパーマリンク構造が理想的です。【WordPressのパーマリンク】おすすめの設定と理由https://fujimotoyousuke.com/2017/01/wordpress-permalink-setting/パーマリンクにカテゴリ名を入れたほうが良いという人もいますが、わたしはおすすめしません。二つの勢力に分かれているだけあって容易に解決できる問題ではないのですが、私は「カテゴリをパーマリンクに含めるべきではない」という立場をとります。カテゴリは(少なくともブログのパーマリンクとしては)長期的な使用に向かないと考えるからです。以下ではそれについて触れていきます。Platformのブログエントリでは、https://library.com/shelves/american-literature/books/moby-dickのような分類による階層構造を伴うURLが示されています。見たところ分かりやすいURLですし、実際インターネット上でもっともよく見るタイプのURLだと思います。ところがパーマリンクは「Permalink」の文字通り、恒久・不変である必要があります。困ったことに、こういった分類というものは途中で弄りたくなるものです。動植物の分類学でしょっちゅう変更があるように、「このページはこっちだったけど、あっちでまとめた方が良さそうだな」みたいなことが起きる可能性があります。これは長期的に運用すればするほど高まります。いった場合のために、301リダイレクトという方法があります。細かい話をすると、そのマッピングがあることで運用コストはどんどん上がっていきます。初めから無いに越したことはありません。私の場合何度かの移転を経てマッピングが膨大で、これ以上増やしたくないのです。はじめに前提条件として「個人が所有するブログのパーマリンクに主眼を置く」と述べました。個人が所有するブログである以上、私のように十数年と運用していると興味関心がどんどん変わっていきます。その都度ブログを作るのも良いですが、私は文章のはけ口を一箇所にしたいのです。いう場所でカテゴリ分けをするのであれば、なるべく長期間それが機能するものでなければなりません。この教訓は私が10年以上前、このサイトをブログに再構成したときに作ったカテゴリが現在は機能していないという事実に基づくものです。階層を廃したURLとはではカテゴリを使用しない場合、どのような形が「エレガント」なのでしょうか。私のブログのパーマリンクについて再掲します。yagi.tchttps://yagi.tc/archives/2017/10/16/always-on-ssl/これをよりエレガントにするには2つの方向性があります。一つはスラッグのみにしてしまうことです。https://yagi.tc/always-on-ssl/内容について推測ができ、それでいてシンプルです。階層構造が一切ないので、スラッグを設定する名前空間に気を付ける必要があります。TypeのようにHTMLファイルをパブリッシュ(出力)するタイプのCMSでは、一ディレクトリの直下に大量のファイル(またはディレクトリ)が存在することになるため管理が煩雑になります。これはWordPressのようなタイプのCMSに向いています。一つはタイムスタンプのみにしてしまうことです。https://yagi.tc/2017/10/16/またはhttps://yagi.tc/20171016/スラッグではないので内容については推測できませんが、ブログは時系列で更新していくので割と理にかなっていると思います。テクノロジーなど陳腐化の激しい分野を扱う際、URLから書かれた時期を把握できることは重要です。(テクノロジー系のブログエントリなのに書かれた日付がどこにも表記されてなくて怒りに震えることはよくあることです)難点は、この形式では一日に最大一エントリしか扱うことができないことです。時刻の2桁まで入れれば一時間に最大一エントリになりますが、パッと見てそれが時刻であると認識できる人は少ないと思いますので、思い切って時分秒まで入れた方が良いかもしれません。https://yagi.tc/2017/10/16/12/00/58/またはhttps://yagi.tc/20171016120058/作家の結城浩さんは自らの文章をまとめるのに以下のようなURL形式にすることを検討しているようです。以前から結城はタイムスタンプを使った14桁の数が大好きです。20171031123456のことです。散らばらずにぎゅっと集約できます。hyuki.org/20171031123456のような形で、自分の活動へのリンクとできないだろうか。結城は「仕事の集約」をそんなイメージで描いているのです。Vol.292)同じ形式ですね。一般的にはスラッグの代わりにエントリIDを用いたパーマリンクhttps://example.com/789/またはhttps://example.com/?p=789も見かけますが、万が一CMSを変更した場合にIDが変わる可能性があることから、あまり推奨できません。バージョン番号を付ける構成APIでよくあるURIにバージョン番号を付けたものがあります。https://www.googleapis.com/upload/drive/v2/files/fileIdこれを応用すればバージョン番号ごとに異なるパーマリンク体系を採用できるので長期間の運用に耐えられるのでは......と思いましたが、結局後方互換性を残すために全バージョンでCMSを運用し続けないとパーマリンクとして機能しないので、運用コスト的に現実的ではなさそうですね。HTMLファイルをパブリッシュするタイプのCMSではアリかもしれません。長期間の運用を前提にする場合、上記以外にもパーマリンクを構成する要素はなるべく普遍的なものを使用するのが良いと思います。以下は要素として挙げるのみで、具体的な議論は行いません。おわりに長くなりました。結論としては、スラッグ形式とタイムスタンプ形式を組み合わせた以下のような形式でいこうと思います。先日このサイトを常時SSL(AOSSL、または常時HTTPSとも)に対応させました。知見がありましたのでまとめておきます。私は今回以下のことを実施しました。Encryptの導入HSTSの導入(※必須ではない)ドメインのネームサーバの変更(※必須ではない)それによって得たTips/注意点は大きく以下のとおりです。混在コンテンツを許容する場合はネットワークパス参照が使えるソーシャル連携では「いいね」数やブックマーク数の引き継ぎ対応が必要ネームサーバについて今後証明書を発行するならCAAレコードが必須になりそうSSL/TLS対応状況確認について確認のための便利なサイトがあります。TESThttps://www.ssllabs.com/ssltest/このように、うまく対応できていれば「A+」の結果になります。nginxのconfigについてnginx1.12+PHP7.1環境において、nginxのconfファイルは最終的に以下のようになりました。on;}基本的にはこのコピペでいけると思いますが、初めてnginxの表示を確認するなど常時SSLがまだ始まっていないときは以下の行(19、53、54、57行目)をコメントアウトしてください。当然ながらnginxインストール直後でHTTPでの表示を確認したい場合はここをコメントアウトしてリダイレクトを無効にしてください。/etc/letsencrypt/live/example.com/privkey.pem;その場合、まだ53~54行目のファイルが存在していないので(19行目が無効であっても)エラーになりnginxが起動できません。あわせてここもコメントアウトしておいてください。Encryptのcertbotを起動しファイルが作成されたらコメントインしてHTTPSでの表示確認を行ってください。preload';57行目は常時SSLを実現するHSTSの設定です。Security)はHTTP接続を強制的にHTTPSへリダイレクトし、以後はすべてHTTPSで接続する機能です。上記では1度接続したら最大365日間(31536000秒間)HTTPSを使い続ける設定になっています。HTTPSの表示確認中の段階ではこの行はコメントアウトしてください。ないと手元の表示環境でHSTSが効いてしまい、一度HTTPSで表示したページをHTTP表示に戻したい場合などにうまく表示されなくなってしまいます。都度ブラウザのキャッシュをクリアするか、最後の最後にコメントインするようにしてください。includeSubDomainsの指定はサブドメインにもHSTSが適用されるようにするための設定です。preloadはプリロード登録のためのものです。今のところ私はプリロード登録をしていませんがいちおう残しています。HSTSの設定についてはこちらのページも参考になります。常時SSL化(https)するときのHSTS設定の方法と注意点http://tuono034s.com/web-entry/2310/それから、63行目のプロトコル指定はnginxのバージョンによりますので確認して指定してください。2017年10月現在、最新バージョンのnginxにおいてTLS1.3はドラフト版のみの対応となっており、厳密には以後の動作保証ができないため外しています。Encryptの導入について導入方法については他のサイトを参照するとして、まだ試行錯誤段階である場合はcertbotの実行時に”–test-cert”オプションを付けてテストサーバに接続するようにしてください。メインサーバの方には一定期間内の接続回数に上限があり、何回か繰り返すと弾かれます。テストサーバでテスト用証明書を取得した後、証明書をそのままにしてメインサーバへと接続すると、既にある証明書を置き換えるかどうか尋ねられるので自動実行の際は注意してください。certbotのrenewコマンドをcronで実行する時は”–force-renewal”オプションを使わないようにしましょう。Encryptのサーバに不要な負荷をかけることになります。以下のページも参考になります。Content)となり、ブラウザで警告が出ます。これらを取り除くためにはブラウザの開発者ツール機能などを利用しながら一つ一つ取り除いていく必要があります。置き換えればよいだけのものもありますし、URLが変わるために丸ごと書き換えが必要なものもあります。Regexなどのプラグインを利用するのがよいでしょう。正規表現が使えますし、置換前後を確認しながら置換していくことができます。これらのツールはエントリ内などで内部リンク(aタグやimgタグ)を絶対指定で行っている場合の置き換えにも使うことができます。◇もし常時SSLを行わない場合で、あるページがHTTPでアクセスされるかHTTPSでアクセスされるか一定しない場合、埋め込まれたリソースを「src=”http://example.com~”」などと指定して読み込んでしまうとブラウザで警告が出ることがあります(混在コンテンツ)。この場合はネットワークパス参照を使用してURIスキームを省略し、「src=”//example.com~”」などと指定することで、ブラウザ側で読み込み元ページのURIスキームに合わせて解釈してくれます。見ない記述方法ですが、RFCに準拠した方法であり、最近のブラウザでは正しく動きます。この場合、どちらのURIスキームであっても埋め込みリソースに正常にアクセスできる必要があります。常時SSLを行うとURLが変わるため、ソーシャル連携していた場合「いいね」数やはてブ数が引き継がれません。特殊な対応が必要になります。ネームサーバについて今は必須ではありませんが、今後SSL/TLS証明書の取得には、第三者による発行を防止するためドメインのネームサーバにCAAレコードを設定するよう求められるようです。CAAレコードについての解説は以下が分かりやすいです。さくらのサポート情報https://help.sakura.ad.jp/hc/ja/articles/115000139062-DNS-CAA-レコード設定について現在CAAレコードに対応しているDNSサービスは少ないですが、HTTPS化の流れとそれに伴うCAA必須化の流れに乗って今後続々と対応が進むでしょう。DNSを使用して有料で運用しています。技術Typekitでサイトのフォントを手軽に綺麗にするTypeKitを使えばドメイン管理者なら無料でサイトのフォントを美しくすることができます。Typekithttps://typekit.com/TypeKitはAdobeのWebフォントサービスです。Webフォントを使うことでユーザの環境に依存せず統一したフォント表示ができます。IDを作る必要があります。作成方法https://helpx.adobe.com/jp/x-productkb/policy-pricing/cpsid_92722.htmlIDを持っていれば、Typekitのサイトでログインするとフォントの一覧が表示されます。フォントを参照https://typekit.com/fonts任意のフォントをクリックするとこのような画面になるので、右上の「キットに追加」をクリックします。Sans)を使用しています。「キットを作成」に進みます。ポップアップウインドウが出るので、サイト名とドメインを入力します。無料アカウントの場合は1つのみ指定できます。SCRIPTタグでできたHTMLコードが表示されるので、これをサイトのHEADタグ内に記述します。HTMLコードはユーザごとに異なります。完了画面が表示されます。この時点ではまだフォントは反映されません。先ほどのHTMLコードを埋め込んで、CSSでフォント指定し、右下にある「公開」をクリックすると初めて反映されます。サンプルCSSは完了画面の左上にある「CSSでフォントを使用」をクリックするとこのように表示されます。埋め込みHTMLコードとCSSはいつでも確認できます。