Postach.io

Postach.ioからHexoへの移行

Postach.ioの記事ファイルをHexoが解釈できるように編集する

記事がローカルのテキストファイル(この場合はMarkdownファイル)として残るため、それを他のフレームワークに放り込むだけで概ね移行が完了するのが、静的サイトジェネレータのよいところです。

とは言え、Postach.ioとHexoではフロントマターの構文が異なるため、少しは手を加える必要がありました。その少しがなかなか大変でしたが。

Postach.ioとHexoのフロントマター構文

Postach.io
1
2
3
4
5
title: Postach.ioからHexoへの移行
date: 2014-09-14 20:07
tags:
- Postach.io,Hexo
type: post

以上が指定でき、また全て必須です。

Hexo
1
2
3
4
5
6
title: Postach.ioからHexoへの移行
date: 2014-09-14 20:07
tags:
- Postach.io
- Hexo
---

他にも指定できる項目はありますが、初期設定ではhexo newコマンドで生成されるのは以上の項目です。

ターミナルで一括処理

必要な処理は以下の通りです。

  1. type項目の削除
  2. ---を挿入
  3. tags項目をList形式に修正

これを手作業で、77個くらいの記事ファイルすべてに対して行うのは発狂しそうなので、ターミナルで処理しようと思いました。

とりあえず、1,2については以下のコマンドでできました。

1
find ./ -name "*.md" -print0 | xargs -0 gsed -i -e '5i ---' -i -e '/type/d'

前提条件として、GNU sed(とHomebrew)のインストールが必要です。

1
brew install gnu-sed

内容を分解すると、以下のような感じです。

  • findで指定フォルダ以下の「ファイル名に.mdを含む」ファイルを検索してパイプで渡す
    • ファイル名に半角スペースを含む場合があるので-print0オプションを付ける
  • xargsfind結果を受け取り、gsedコマンドで正規表現置換
    • -iで上書き保存、-eで検索式を利用
      • 5行目に---を挿入
      • typeを含む行を削除
    • ファイル名に半角スペースを含む場合があるので-0オプションを付ける

3についてもgrepでできるとは思うんですが、検索式をすぐに書けそうになかったので、泣きながら手作業でやりました。

少しでも楽をするために、Sublime Textを利用。

  • 記事ファイルがあるフォルダを読み込んでおく
  • 改行とListフォーマットの挿入は正規表現置換で行う

ファイルのリネーム

ここまでやればHexoでのレンダリングは問題なくできるのですが、hexo newで自動生成されるファイルとファイル名ルールが違います。

禁止文字のエスケープ

タイトルに含まれる近似文字は強制的にエスケープされます。前にも書きましたが、確認した限りでは以下の通りです。

  1. 半角スペースを-に置換
  2. .を削除
  3. /を削除

3はもともと自分でエスケープしてあるので、今回必要なのは1,2です。

これはrenameを利用すれば簡単でした。事前にインストールが必要です。

1
brew install rename

renameをインストールして、

1
2
3
rename "s/\.//g" *.md #ドットを削除
rename "s/ /-/g" *.md #半角スペースをマイナスに置換
rename "s/md$/.md/" *md #間違えて拡張子のドットまで消しちゃったので直すよてへぺろ

一部アヤしい処理も見えましたがキニシナイ。

日付の挿入

まず、Hexoでは_config.ymlの記述によっては作成日をファイル名に自動挿入できるため、そのようにしてあります。

Hexoでは別に必須ではないのですが(Jekyllだと必須)、付けておいたほうが後の管理も楽なので、付けておきたいところです。

要するに、grepdate項目から日付を切り出して、それでリネームするシェルスクリプトを書いて、Automatorでループ処理してやればいいのだと思いますが、元のファイル名取得が難航して結局これも手作業に。

Sublime TextにSIdebarEnhancementパッケージを入れて、リネームにショートカットキーを割り当てておくと少しだけ楽です。

(追記)あとで知ったけど、for使えば良かった。こんなん。

1
2
3
4
5
for file in *.md
do
date=`grep '^date:' $file | cut -c 7-16`
mv $file $date-$file
done

test.md → yyyy-mm-dd-test.md

デプロイ

これでHexo形式への変換が完了しました。

後は、Hexoプロジェクトフォルダ内のsource/_postsフォルダにコピーしてhexo d -gでデプロイするだけです。

はてなブログからの移行が全く進んでいない件

一応、Markdownフォーマットで保存してはあるんですが……はてなからとなると、特有のブログパーツがあるからめんどくさいんですよねえ。

ただし、Hexoには各種フォーマットからの移行(Migration)機能があります。

とりあえずRSSからの移行を試してみましたが、7記事しか移行できませんでした。

そこで、はてなブログ→WordPress→Hexoというルートが考えられるのですが、疲れたのでまた今度にします。

Postach.ioの日本語不具合

Hexo相手に悪戦苦闘するハメに陥った原因についてまとめる。

経緯/現状

  • Postach.ioのアップデートが行われる。(Bug Fixes, Better Markdown & Faster Syncing | Postach.io Blog
  • 直後、運用中のPostach.ioブログで全ての記事が表示されなくなる。
  • 再構築を行ったところ、表示されるようにはなったものの、Dropbox内元ファイルの英語文字のみが表示され、日本語文字が全て無視されている。
  • さらによく見ると、アップデート前に公開した記事については残っており、その後に「英語のみバージョン」が複製されている。
  • 追加した記事は「英語のみバージョン」のみが表示される。
  • Evernoteからの追加も同様。
  • Postach.ioのTwitterアカウントに報告したものの、ふぁぼられた以外は特に反応なし。
  • Source Editorが改装中のため、ヘッダーとかにねじ込む形での告知も不可。(こんな状態
    • いるのか知らんが、RSSリーダー経由の読者なんかから見たら私がくるったかのごときだ。

対策/移転

  • とりあえずHexoで更新体制は整えたが毎回デプロイするのそこそこめどい
  • Mac/Windowsで同期取るのめどい、とりあえずMacでしか更新してない
    • あんま推奨されてないけど、GitのローカルリポジトリをDropboxに置いちゃうのってどうなんだろう?
  • Dropboxに置いただけで更新したいので、他のそういうツールへの切り替えも検討。
  • いやまあCoqoo ―虚空―のことなんだけども。
    • ドキュメントのどこを読んでもソースをDropboxに置く方法が分からん。
    • 別途Coqoo本体をホストするサーバーが必要なのでそれはそれでめどい
  • はよPostach.io復活してくれたのむ

引っ越しました

Postach.ioがぶっ壊れた

Postach.ioのDropboxが楽すぎて、しばらく利用していたのですが、9月3日のアップデート以来、日本語での更新が一切できなくなりました。

厳密には、元データ内の2バイト文字が無視されて更新される感じ。EvernoteでもDropboxでも同じです。他の日本人ユーザーもまとめて死んでるのか?

とりあえずバグ報告はしておきましたが、すぐに治る気配もないので、とりあえずHexo+Github Pagesで更新することにしました。

Jekyllはどうした?

Hexoだと、パーマリンクに自動生成のIDが使えるんですよ。

前にも書きましたが、いわゆるスラッグを考えるのがイヤなんです。Jekyllでも日付は使えるんですが、1日に複数の記事を書こうとするとURL考えなきゃいけないので、Hexoを使うことにしました。既存のテーマもわりときれいなのが多いし。

もっとも、記事ごとのパーマリンク指定がなぜかできなかったりで困ったことも多いので、そのうち別のフレームワークに乗り換えるかもしれません。JekyllでID生成さえできれば、Jekyllが一番なんですけどね。なんか、分かりやすくて。

現状の問題点

  • なぜか記事ごとにfrontmatterでパーマリンク指定するのができない。なので元からGithub Pagesに置いてあった記事のURLが変わってしまってます。
  • あと、Github ユーザページはJekyllやりたいとき用に取っておきたかったので、Heroku使おうと思いましたがワケワカでした。
  • なぜかデプロイ時にテーマ変更が反映されない。ローカルhexo serverでは反映されてるんだからなにが何やら。

AutoHotKeyのスクリプトファイルが長い

AutoHotKeyの利用を再開してからこれまで、全てのスクリプトを単一のファイルに記述していました。

しかし、スクリプトが長大になるとともに、編集の際に該当箇所を見付けるのが難儀になってきました。

そこで、編集しやすくするために、スクリプトファイルを分割することにしました。

スクリプトの分類

概ね、AutoHotKeyのスクリプトは、利用状況によって次のとおりに分類できると考えられます。

ウインドウを問わず利用するコマンド

主にホットストリングが当てはまります。これらは、そもそもテキスト入力フィールドでしか利用できないこともあり、特定のウインドウで利用するようなものが今のところないためです。

ウインドウごとに指定するもの

主にホットキーが当てはまります。ホットキーはウインドウごとに指定しないと競合を起こすためです。

他のコマンドから参照する関数・変数

関数(及びグローバル変数)が当てはまります。このスクリプトに対する変更は、他のスクリプトに影響します。

上記のような変数を定義し、コマンド内で呼び出すことで、別に定義された変数を利用できます。

(実行ファイル化するもの)

一連の処理をスクリプトとして記述し、実行ファイル化するもの。そもそも常駐するスクリプトファイルには記述されていないので今回は関係ありません。

常駐型スクリプトの構成

今回は、以下のように分割しました。

  • ホットストリング展開するスニペット
    • 単語
    • コード
    • フォーマット(Markdown、クリップボードの内容を加工)
    • メールアドレスや管理するウェブサイトURL等の情報
  • ホットキー
  • 関数

#Includeと関数ライブラリによる組み込み

上記を踏まえて、ファイル構成は下記のようにしました。AutoHotKey.exeと同じフォルダに置いてあります。

  • AutoHotKey.ahk(スタートアップ時に起動する常駐スクリプト)
  • /Include
    • Name.ahk(単語)
    • Code.ahk(コード)
    • Input.ahk(フォーマット)
    • Info.ahk(メールアドレスなどの情報)
    • Keymap.ahk(ホットキー)
  • /Lib
    • (関数別ファイル)

関数は、関数ライブラリ機能により自動的に組み込まれるため、特別に常駐スクリプトの記述を変更する必要はありません。

その他のスクリプトを組み込むため、AutoHotKey.ahkに以下の記述を追加しました。

#Include Include/Name.ahk
#Include Include/Keymap.ahk
#Include Include/Code.ahk
#Include Include/Input.ahk
#Include Include/Info.ahk

これにより、スクリプトファイルの編集が容易になりました。

リロードするホットキーを変更

以下は、oeditでスクリプトファイルを編集する場合のみ検証済みです。

どのスクリプトファイルを編集した場合も、ctrl+sで保存しつつリロードできるよう、ホットキーを設定します。

#IfWinActive,c:\apps\AutoHotkey\
^s::
    Send,^s
    sleep,100
    Reload
    return
#IfWinActive

c:\apps\AutoHotkey\の部分は、AutoHotKey.exeが存在するフォルダに合わせて変更してください。

#IfWinActiveにおけるWinTitle引数は、特に指定のない場合は前方一致です。

例えば、oeditでAutoHotKey.ahkを編集している場合、ウインドウタイトルは以下のようになります。

c:\apps\AutoHotkey\AutoHotkey.ahk - oedit

フォルダパスまでを指定しておけば、そのフォルダ以下の全てのファイルについて、編集時のウインドウタイトルが前方一致するようになります。

しかしこれ、Sublime Textで機能しないんですよね。なぜだろう。

Postach.ioのCSSを書き換えた時のメモ

CSS編集したときのメモ。

Postach.ioでデフォルトテーマを適用した状態で、Source Editorからテンプレートを読んでみる。

CSSに関する指定は以下の通り。

<link href="" rel="stylesheet">
<link href="" rel="stylesheet">
<link href="" rel="stylesheet">

3行目がテーマ別の指定であるようだ。

Postach.ioのCSSはレスポンシブデザインであり、ブラウザの幅によって表示が変化する。そのため、以下は全て幅最大=PC向けの表示を前提とする。

現在の表示は以下の通り。(多少ヘッダー・サイドバーに手を加えてある)

通常デザイン

ここで、このページをHTMLとして保存する。上記のCSS指定が、以下のようにHTMLとして展開されている。

<link href="http://postach.io/static/bootstrap/css/bootstrap.min.css" rel="stylesheet">
<link href="http://postach.io/static/bootstrap/css/bootstrap-responsive.min.css" rel="stylesheet">
<link href="http://postach.io/static/themes/default/default.css" rel="stylesheet">

そこで、3行目をコメントアウトしてみる。その場合の表示は以下の通り。

テーマ固有のCSSを削除

ここから読み取れるdefault.cssによる指定は以下の通り。

  • ヘッダーとボディの重なりを解消
  • フォント指定、背景指定
  • プロフィール画像を丸アイコン化
  • タグクラウドの回り込み

したがって、これらの部分に手を加えるためには、default.cssを自作のCSSに置き換えればよい。また、追加指定も行う。

なお、以下のような指定もあったが、影響範囲は不明だった。

<link rel="stylesheet" href="http://postach.io/static/site/css/social-bar.css?v=05022014" />

そこで、default.cssをダウンロードし、保存したHTMLで読み込むようにして修正・懸賞を行う。

default.cssの編集

ここから、CSSを編集していく。

丸アイコン化を解除

プロフィール画像が丸アイコンに対応していないため、指定を変更する。

HTMLの該当箇所は以下の部分。

<img class="avatar" src="http://postachio-images.s3-website-us-east-1.amazonaws.com/b41cb417d61ac3406bf98585f8bc9a69/avatar.jpg" alt="もりやん" />

CSSの該当箇所は以下の部分。

.bio img.avatar {
  position: absolute;
  top: -33px;
  left: 25px;
  width: 66px;
  height: 66px;
  border-radius: 50%;
}

border-radius: 50%;をコメントアウトするか、値を小さくすることで、画像の全体を表示することができる。今回は、10%で指定した。

テーブル

  • ボーダーを表示
  • 背景色の縞模様化
  • テキストを中央寄せ

CSSの該当箇所は以下の部分。

.post .post-content table {
  margin: 0;
  padding: 0;
}

これを、以下の通りに変更。なお、内容はほぼSublime Text Markdown Previewからパクり。

.post .post-content table {
  border-collapse: collapse;
  border: 1px solid #ddd;
  background-color: #fefefe;
}
.post .post-content table tr:nth-child(2n) {
  background-color: #f8f8f8;
}
.post .post-content td, th {
  border: 1px solid #ddd;
  padding: 6px 13px;
  text-align: center;
}

これで、テーブルの表示が以下のように変更された。

テーブル表示例

画像に縁取りを追加

CSSの該当箇所は以下の部分。

.post .post-content img {
  max-width: 100%;
}

これを、以下の通りに変更。

.post .post-content img {
  max-width: 100%;
  box-shadow:0 0 5px 1px rgba(0, 0, 0, 0.2);
  padding:5px;
  border:1px solid #ccc;
  border-radius:5px;
}

以下のページを参考にした。

画像に縁取りが追加され、見やすくなった。

インラインコードを折り返す

code要素が折り返しされずにボックスからはみ出していたため、以下のページを参考にCSSを追加。

追加内容は以下。

.post code {
  overflow: auto;
  white-space: pre-wrap;
  word-wrap: break-word;
}

見出しのフォントサイズを調整

default.cssの該当箇所は以下の部分。

.post h1 {
  font-size: 28px;
  margin-top: 15px;
  font-weight: 300;
}
.post h2 {
  font-size: 24px;
  line-height: 34px;
}
.post h3 {
  font-size: 20px;
  line-height: 30px;
}
.post h4 {
  font-size: 16px;
  line-height: 26px;
}
.post h5 {
  font-size: 12px;
  line-height: 22px;
}
.post h6 {
  font-size: 8px;
  line-height: 18px;
}

本文の指定は以下の部分。

.post p {
  font-size: 14px;
  line-height: 24px;
}

h5以下の見出しには、本文より小さいフォントサイズが適用されていることが分かる。

なお、本文内の見出しをどのレベルから始めるべきであるかは、実は微妙な問題。

  • トップページで記事全文を表示する場合、記事タイトルがh2なので、本文はh3から始めるべきとなる。
  • 記事個別ページでは、記事タイトルはh1であるため、本文はh2から始めるべきとなる。

この場合、本文は一律にh3から開始するものとする。

今回は、h6を本文と同じ14px指定とし、フォントサイズによって見出しレベルの差を表現する。

また、太字にするとともに、行頭に#を付けることによって、見出しであることを表現する。

よって、以下のように変更する。

.post h1 {
  font-size: 28px;
  margin-top: 15px;
  font-weight: 300;
}
.post h2 {
  font-size: 24px;
  line-height: 34px;
}
.post h3 {
  font-size: 20px;
  line-height: 30px;
}
.post h4 {
  font-size: 18px;
  line-height: 26px;
}
.post h5 {
  font-size: 16px;
  line-height: 25px;
}
.post h6 {
  font-size: 14px;
  line-height: 24px;
}
.post h3,h4,h5,h6 {
  font-weight: bold !important;
}
.post h3:before {
  content: "# ";
  color:#9e9e9e;
  font-weight: bold;
}
.post h4:before {
  content: "# ";
  color:#9e9e9e;
  font-weight: bold;
}
.post h5:before {
  content: "# ";
  color:#9e9e9e;
  font-weight: bold;
}
.post h6:before {
  content: "# ";
  color:#9e9e9e;
  font-weight: bold;
}

下記参考ページのバグが確認されたため、擬似要素のbeforeではセレクタの複数指定を避けている。

編集したCSSをアップロードする

今回は、Github Pagesでホストすることにした。

Github Pagesのローカルリポジトリに編集したdefault.cssを置き、プッシュした。

<link href="" rel="stylesheet">

Source Editorで、上記の部分を以下のように書き換え、ホストしたCSSを参照する。

<link href="http://catfist.github.io/Postachio_default.css" rel="stylesheet">

これにより、編集したCSSが反映された。

ついでに:Postach.ioテーマをBitbucketで管理

Postach.ioのテーマについてもバージョン管理したかったので、Bitbucketに置くことにした。

ただ、当然ファイルとしては存在しないので、わざわざローカルにHTMLファイルとして保存してやる必要があった。

CSSに比べると頻繁にいじるものではないので、そこまでしなくてもいいような気はするが、Dropboxとかに置いておくよりはスマートであるような気もする。

Dropboxの同期コンフリクトによるファイルの複製が、Postach.ioで公開された場合の対処方法

Dropboxの同期コンフリクトによるファイルの複製

Dropbox内のファイルがアップロードされている時、さらに異なるアプリケーションによる変更が行われた場合、Dropboxはコンフリクトを解消するためにファイルを複製します。(「(ユーザー名)’s conflicted copy」がファイル名末尾に付く)

これがPostach.io同期フォルダ内で発生した場合、当然このコピーも公開されてしまいます。まあ、それならそれでどちらかを削除すればいいのですが、タイミングによっては、ファイルが削除された後も記事が残る場合があります。

他にも、間違えてタイトルのないファイルを保存してしまったときなど、意図せずに記事が作成されてしまう場合があります。

この場合、再度同名(かつ同タイトル)のファイルを作成+削除しても、記事は削除されません。また、記事を削除するというメニューはそもそも存在しません。

誤って作成された記事の削除方法

ではどうするかというと、一度DropboxをDISCONNECT(「Delete all posts from this source?」にチェック)した後、再度ソースを追加すれば、存在するファイルのみで記事が再度作成されます。

そこまでしなくても、 http://postach.io/account にアクセスしてループ矢印ボタンをクリックすればブログが再構成されるのですが、どうも妙に時間がかかったり、記事が足りなかったりで失敗することが多いです。

スクリーンショット

一度DropboxをDISCONNECTする方法では、いまのところ失敗したことはありません。

Postach.ioフロントマター入力用スニペット

承前。

Postach.ioのDropbox投稿に必須のフロントマターを、簡単に入力できるようにした。

総じて、タイトルは書き終わってから入れたほうが楽だと思われ。

TextExpanderの場合

title: %filltext:name=タイトル%
date: %Y-%m-%d %H:%M
tags: 

タイトルをフィルイン。まあなくてもいい。
日時を自動挿入。

AutoHotKeyの場合(2014/07/27修正)

日時を自動挿入する。

Sublime Textの場合

<snippet>
<content>
title: 
date: $1
tags: 

$2
</content>
<tabTrigger>::</tabTrigger>
<!-- <scope></scope> -->
<description>Postach.ioフロントマターのテンプレート</description>
</snippet>

日時を展開する方法が見当たらないので、手動で入力した後、タブキーで$2位置に飛べるように。

Postach.ioでDropbox連携する時の注意点

Postach.ioはEvernote連携サービスという印象が強すぎるせいか、Dropbox同期更新に関するまとめがなさげなので、ざっくりと。

とりあえず公式のリリース。

フロントマター

同期フォルダに置くファイルには、先頭に次のようなフロントマターを記述する必要があります。

1
2
3
4
5
title: Postach.ioでDropbox連携する時の注意点
date: 2014-07-21 00:14
pid: 9LBqvA5sq1
tags:
- blog,Postach.io

これらは全て必須であり、要素ごと欠けている場合はおろか、内容が空である場合さえ公開されません。(逆に言うと、下書きとして置いておくのに使える)

なお、公式リリースでは、date要素を「YYYY-MM-DD」のフォーマットで記述するよう求めていますが、実は時刻も反映されます。

「YYYY-MM-DD」のフォーマットで、同日の記事が複数存在する場合、通常はタイトル順に記事が並ぶのですが、時刻も付け加えておくと、時刻順に並ぶようなのです。

もっとも、公式の仕様ではないので、そのうち修正されるのかもしれません。

拡張子

同期フォルダに置くファイルの拡張子は、「.md」でなければ公開されません。これも、下書き管理のために有用かもしれません。

「.md」のMarkdownドキュメントは、実際には「.txt」と同じ単なるプレーンテキストであるため、下書きを「.txt」で保存しておけば、拡張子を変更するだけで公開されます。

公開タイミング

アップロードされたら即時です。Evernoteの場合のように、タグで公開状態をコントロールしたりとかいう気の利いたことはできません。ファイル数が増えると公開までの時間が延びるような噂もありますが、このブログでは現状、保存から公開まで数秒です。

フロントマター入りのテンプレートファイルを作っておいて、ファイルを複製してゴニョゴニョとかやってると、うっかり保存した瞬間に公開されます(経験談)。自動保存機能のあるエディタを利用する場合は要注意です。

なので、そういうことをしたい場合は、フロントマターや拡張子でコントロールすればよいでしょう。

記事の削除

ファイルを削除した場合、記事は削除(非公開化)されます。フロントマターを削除して公開条件を満たさなくなった場合は、ファイルの更新が反映されなくなるだけで、記事削除はされません。

ただし、管理画面で「DISCONNECT DROPBOX」を行う際は注意が必要です。「Delete all posts from this source?」にチェックを入れなかった場合は記事が残り、かつ、管理画面から削除する方法がありません。

連携解除時のメッセージ

こうして残ってしまった記事を削除するには、再度Dropbox連携を許可する必要があります。これは、Evernote連携についても同様です。

Dropbox同期に対応したPostach.ioはScriptogr.amに勝つか

あるいは引っ越しのご挨拶。

Postach.ioがDropbox同期に対応していた

Postach.ioといえば「Evernoteをブログにできる」で有名ですが、原稿はプレーンテキスト(Markdown)で管理したいと考えており、Evernoteでプレーンテキストを管理することにはいくつかの問題があったため、今まで利用を避けていました。(空白文字が改変される、単純に重いなど)

しかし、Dropbox同期が実装されたため、改めて検討してみました。

Dropbox同期の利点

投稿が楽、好きなエディタが使えるなど色々ありますが、なんといっても、記事の修正が楽なことが利点でしょう。

管理画面を開く必要もなく、Dropbox内のファイルを修正するだけ。投稿したあとで間違いに気付くのがしょっちゅうの私としては、ぜひともそのワークフローを取り入れたい。というか、MarsEditなしではてなブログ修正するのとか修行に近い。なんなのあの無駄にJavascriptめいたUI。

Scriptogr.amとの比較

Dropboxでブログを投稿できるシステム・サービスは数年前に流行ったことがあり、候補もいくつかあります。しかし、インストール不要のホスティングサービスであることを前提にすると、現状で選択しうるのはScriptogr.amくらいでした。

Scriptogr.amとPostach.ioを比較すると、以下のような違いがあります。

Scriptogr.am Postach.io
同期 手動(自動同期オプションあり) 自動
URLスラッグ オプション(事実上必須) 不可
タイトル オプション 必須
投稿日時 オプション(時刻指定可能) 必須(時刻指定不可)
URL重複時 新しい投稿のみ表示 新しい投稿に連番を付与
  • スラッグ、タイトル、投稿日時はフロントマターで指定
  • オプション項目を指定していない場合、他の要素から補完
    • ファイル名→タイトル
    • タイトル→URLスラッグ

Scriptogr.amにおけるURL重複問題

Scriptogr.amにおいては、「ファイル名→タイトル」、「タイトル→URLスラッグ」が補完されます。

ここで問題なのは、日本語が省略される点です。英語部分のみが残るため、URLが読みにくいだけでなく、重複してしまう恐れがあります。そして重複した場合、実際にブログ上に表示されるのは、そのうち最新の記事のみとなります。そのため、スラッグ指定が「事実上必須」というわけです。

Postach.ioにおけるタイトル問題

Postach.ioにおいては、スラッグ指定ができません。つまり、必ずタイトルから補完されるのですが、この際、日本語が中国語読みに変換される仕様となっています。

したがって、日本語で書く場合、タイトルかURLのどちらかがおかしくなることを許容しなければなりません。

また、タイトルを修正した場合、URLが変わってしまうことも問題だといえます。

Postach.ioを選んだ理由

スラッグというものが嫌いです。憎んでいると言ってもよい。

そもそも、「テキストとして美しいURL」というものに魅力を感じません。SEO効果とも関係するらしいですが、どうしても生理的に好きになれないのです。生理的に好きになれないものを毎回考えるのは、想像するだに耐えられないストレスです。

それに、開発が停滞気味に見えるScriptogr.amに比べ、Evernote Dev Cupを獲ったPostach.ioには日の出の勢いがあります。デザインセンスも時代に即しています。サービスとしての「セクシーさ」を比べたら、現状ではPostach.ioに軍配が上がるでしょう。

というわけで、ひとまず更新をPostach.ioで行うことにしました。