nDiki : URL

URL - Uniform Resource Locator

URI escape (Perl)

http://www.din.or.jp/~ohzaki/...

によると

 $str =~ s/(\W)/'%' . unpack('H2', $1)/eg;

と

 $str =~ s/%([0-9A-Fa-f][0-9A-Fa-f])/pack('H2', $1)/eg;

がはやいそうです。

application/x-www-form-urlencoded でのエンコード (Perl)

同じく

http://www.din.or.jp/~ohzaki/...

によれば、

 $str =~ s/([^\w ])/'%' . unpack('H2', $1)/eg;
 $str =~ tr/ /+/;

 $str =~ tr/+/ /;
 $str =~ s/%([0-9A-Fa-f][0-9A-Fa-f])/pack('H2', $1)/eg;

がはやいそうです。

RFC

RFC1738 - Uniform Resource Locators (URL).
RFC1808 - Relative Uniform Resource Locators.
RFC2368 - The mailto URL scheme.
RFC2396 - Uniform Resource Identifiers (URI): Generic Syntax.

記事

URI の長さに関する制限

web

2016年5月17日 (火)

Google Spaces とかシンクルとか【日記】

このあいだリリースされた Google Spaces を入れてみました。グループチャット的なサービスです。スペースへの招待は招待リンク (URL) を伝えるタイプなので、ゆるい半クローズドなタイプですね。 Google 上の機能やコンテンツとの親和性や検索は強そうですが、コミュニケーション設計的には目新しいところは無い印象です。ちなみに1ユーザーにつき作成できる Space は100個まで。

また、今日はシンクルも入れてみました。アプリをインストールしたらプロフィール設定をほとんどせずに使えたり、比較的軽いトークが中心だったりすることころはアンサーっぽいなと感じました。サービス内で中の人が「出会わない系」明言しています。状況に応じて ID 交換投稿を削除している様子。暇つぶしのポジションかな。

スポンサードリンク

[ permalink ]

今日のさえずり: Authy みたいにクラウドに保存されることがないのが好み

2016年05月17日

09:39 着席。 (@ 株式会社ミクシィ in 渋谷区, 東京都) https://www.swarmapp.com/c/gBYaIUUyN9p
13:22 今日もハッピーセット。 (@ マクドナルド渋谷新南口店 in 渋谷区, 東京都) https://www.swarmapp.com/c/5pE9K2jqeCg
20:27 Google Spaces 入れてみました。1ユーザーにつき作成できる Space は100個まで。招待は招待リンク (URL) を伝えるタイプ。
21:02 シンクルも入れてみました。アンサーっぽいです。
21:24 IIJ SmartKey を使って2台以上で2段階認証(2要素認証)できるようにしています。 Authy みたいにクラウドに保存されることがないのが好み。

[ permalink ]

[ 5月17日全て ]

2016年5月20日 (金)

FeedBurner へのリダイレクトを停止

この nDiki のフィードは2008年8月から FeedBurner を挟むようにしているのですが、もう特にメリットも無さそうなので外すことにしました。

.htaccess から以下を削除。

 RewriteEngine on
 RewriteCond %{HTTP_USER_AGENT} !FeedBurner
 RewriteCond %{HTTP_USER_AGENT} !feedzirra
 RewriteRule ^diki/d/rss\.rdf$ http://feedproxy.google.com/nDiki [L,R]

http://feeds.feedburner.com/nDiki の方は削除してオリジナルの方にリダイレクトさせることもできるようですがいったんそのままにしておくことにします。

去年8月にさくらのレンタルサーバ + ラピッドSSL にして HTTPS 対応した時にフィードの中の URL 処理を修正していなかった (https://naney.org/80/diki/〜になってしまっていた)のに気がついたのでここもあわせて修正しておきました。

[ permalink ]

今日のさえずり: できるだけシンプルなルールに

2016年05月20日

09:41 渋谷駅、警官がいっぱい。
13:59 渋谷駅に警官が多かったのサミットのせいですね。 https://flic.kr/p/Gpkt8f
22:02 できるだけシンプルなルールに。
26:28 FeedBurner へのリダイレクトを停止。ついでにフィード中の URL が HTTPS 化で変になっていたのに気がついたので修正。

[ permalink ]

[ 5月20日全て ]

2016年6月16日 (木)

タイトルと短縮 URL を好きな形式でコピーできる Google Chrome 拡張機能 Template

URL をシェアする時ははてなブックマークの形式に似せて

 コメント / “{title}” URL

のようにしているのですが、手でこの形式にするのはちょっと面倒です。Google Chrome 拡張機能で良いものが無いかと探したら Template というのがありました。

短縮 URL は Bitly と Google URL shortener に対応しています。私は普段使っている Bitly を選びました。

テンプレートに新しいテンプレートを追加し Content に以下を指定することで希望の形式の文字列でコピーすることができます。

 “{title}” {#shorten}{url}{/shorten}

Toolbar Behavior 設定で Action を Template にしておくと、Toolbar 上のボタン1クリックでコピーできて便利。

[ permalink ]

[ 6月16日全て ]

2016年7月19日 (火)

Twitter と Facebook の連携を設定したけれど、すぐ解除した

最近 Facebook にあまり投稿しなくなったので Twitter の Facebook Connect をまた設定してみました(以前2014年12月に設定して、2015年5月に解除)。

でいくつか投稿してみたのですが、 URL を含んだ Tweet が Facebook 側に投稿された際にでかでかと t.co と表示されたりするなどしてこれはないなと。

それで Twitter → Zapier → Buffer → Facebook の設定をしてみたところ、いい感じの表示になりました。ただ Zapier の実行サイクルが15分間隔なのと1カ月のタスク数上限があるのとがやはり嫌なので、やっぱり止めました。

[ permalink ]

[ 7月19日全て ]

2016年7月20日 (水)

Buffer の Awesome Plan のトライアルを開始してみた

IFTTT や Zapier と Buffer をいじっていて、 Buffer の RSS フィード連携機能が気になったので Buffer の Awesome Plan のトライアルを開始してその機能を使ってみました。

https://buffer.com/

Buffer の RSS フィード連携機能は、アイテムの URL と description をフェッチできる超簡易フィードリーダですね。そこからポストしたいものを選んでキューに入れる(あるいはすぐにポストする)という使い方をするようになっています。

IFTTT や Zapier で自動的に Buffer のキューに入れるようにしている場合は、キューに入ってから次の投稿スケジュールがくる前に必要に応じて再編集したり不要なものを削除したりする必要があって気ぜわしいのですが Buffer の RSS フィード連携機能の場合は好きなタイミングでその作業ができるので良いですね。

ただこの機能のために月 $10 (Apple の決済機能だと1,200円)はかなり割高に感じます。Free Plan とくらべて他には「キューに入れておけるのが10件から200件になる」「カレンダー機能が使える」「曜日別にスケジュールを変えられる」などがあるのですが、個人的にはどうしても欲しいものではありません。

ちょっと微妙ですね。RSS フィード連携機能を使っても必ず手作業が入るので、これなら直接キューに入れていくので私には十分な気もしてきました。

[ permalink ]

[ 7月20日全て ]

2016年10月30日 (日)

Markdown でプレゼンテーションスライドを書ける Deckset for Mac

ここ最近はプレゼンテーションスライドを用意する時は reveal.js を使っています。Markdown で内容を書けるので便利なのですが、個人的には書き始めが億劫というネックがあります。ディレクトリを作って reveal.js のファイル一式を最初に用意するのがちょっとしたことなのですが面倒くさいのです(自分用に若干アレンジしたサンプル一式をコピーする作業)。

Markdown で書けるもので、かつもうちょっとさくっと書けるツールがあるかなと探してみたところ Deckset for Mac が良さそうなので使ってみることにしました。

http://www.decksetapp.com/

スライドを書く

Deckset 方言の Markdown で記述したファイルを1つ用意すれば Deckset でスライドとしてレンダリングしてくれるのでお手軽。Deckset アプリ自体には Markdown エディタは内蔵されておらず Emacs や Atom など好みのテキストエディタで編集するスタイルというのも良いです。テキストエディタ側で保存すると Deckset 側が更新を検知してスライドを更新してくれます。

スライドに使う画像は URL で指定することができる(そして推奨している)ので、ローカルディレクトリに用意してという必要がありません(もちろん Markdown ファイルと同じディレクトリに用意して読み込ませることもできます)。「プレゼンテーション時にネットワークにつながっていなかったり URL 先から消えていたら困るのでは?」というのが気になるところですが、 Deckset 側でローカルホスト上にキャッシュしてくれるので大丈夫になっています。

テーマ

テーマは Deckset が用意しているものから選びます。欧文系らしいちょっと派手なのが多く、個人的に使えるなというのはそれほど多くない印象です。個人的には Titillium がいちばんしっくりくるかなと。

エクスポート

PDF ファイルや画像でエクスポート可能なので困ることはなさそうです。

好みの設定

スライドの冒頭にそのスライドの設定を書いておくことができます。

 theme: Titillium,1
 footer: [各ページ下部のフッタに載せたい文字列]
 slidenumbers: true
 autoscale: true

が良さそげ。

reveal.js との比較

reveal.js と比べて良いなというところは以下です。

すぐ書き始められる。
さくっと画像を貼れる。
「右半分画像」というレイアウトが簡単にできる(reveal.js だと厳しい)。
autoscale を有効にするとページに収まるようにフォントサイズを調整してくれる。

reveal.js では Web ブラウザで表示するため縦横比が変わる前提である程度余裕をもってページを書く必要があるのですが、Deckset はそこを気にしなくて良いのが楽です。CSS や JavaScript コードをいじれる reveal.js に比べると細かいカスタマイズは全然できないのですが、その分デザインは Deckset に任せると割り切って内容だけに集中してさくっと書けます。

reveal.js が便利なところもあるのでプレゼンテーションシーンに合わせて使い分けることにします。

(画像は http://www.decksetapp.com/ より。)

[ permalink ]

[ 10月30日全て ]

2016年12月9日 (金)

nDiki に貼る写真を Flickr ではなく同じサーバに置く

この nDiki に写真を載せる際は2005年から Flickr にアップロードしてそれを貼りつけるようにしています。これを今後は普通に画像ファイルを Web サーバ側に置くことにしました。

Flickr に写真を置いておくメリットは以下があります。

スマートフォンから簡単にアップロードしておける。Flickr アップロード + Twitter シェアした写真をそのままあとで nDiki に貼れる。
Flickr で様々なサイズの画像にしてくれるので自前でリサイズしなくて済む。
Web サーバの容量を圧迫しない(当時は容量が少なかった)。

一方デメリットとしては

Flickr にベンダーロックインされている。長期的には一抹の不安。
一度画像の URL が変わったタイミングで過去の写真が一部表示できなくなっている(記事側の URL を変更していく必要がある)。今後も同様の自体があり得る。

があります。

Flickr 利用で使い勝手的には問題が無いのですが、長期的に継続する Web 日記のコンテンツとしては他のサービスに依存しすぎないようにした方が良いということで、今後は普通に Web サーバに置くことにしました。

そうするとどのサイズの画像ファイルを用意するかを改めて考える必要が出てきました。

画像サイズ

今までは Flickr で生成されるから適当そうなもの(たいがい長辺 500px のもの)を選んで貼っていました。今後は自分で適切なファイルを作ってアップロードすることになるので画像サイズについてちょっと見直してみました。

Bootstrap 3 でのサイトの幅の見直してコンテナを 970px までに

Bootstrap 3 だと広くても幅 1140px (1170px - 30px) なので画像幅もこれだけあれば十分です。しかし考えてみると nDiki は1カラムなのでラージデバイス(≥1200px)向けのコンテナ 1170px はいささか広すぎます。ということでいったんミディアムデバイス向けのコンテナ 970px までしか広げないようにしました。

 @media (min-width: 1200px) {
     .container {
         width: 970px;
     }
 }

写真は基本 max-width: 100% の .img-responsive で表示しているので、これで最大 940px 幅で表示されることになります。

表示される写真の高さは最大 480px に

幅 940px だと 4:3 なら高さは 705px、3:2 なら高さは約 627px になります。13インチMacBook Pro 上の Google Chrome でこのサイズの写真を貼るとほぼ縦いっぱいになってしまいます。記事中の写真では 480px ぐらいまでかなという印象でした。ということで

 max-height: 480px;

としました。

これだと 4:3 なら 640x480px、3:2 だと 720x480px の画像サイズがあれば十分なことになります。縦位置だと 3:4 で 360x480px、 2:3 だと 320x480px です。

画像ファイルの画像サイズは長辺 1200px に

これで 640x480px (4:3) や 720x480px (3:2) にリサイズして Web サーバに置けば現時点では過不足ないということがわかりました。

ただこれだとデバイスの変化でサイトデザインを見直す時がきた時に解像度不足になってしまいます。Bootstrap のラージデバイス向けのコンテナサイズを考えていったん長辺 1200px で画像ファイルを用意することに決めました。

ついでに .pull-left と .pull-right の画像幅も調整

写真を左右に寄せた際に現状テキスト部分が狭くなりすぎることがあるのでこのあたりも合わせて今回調整しました。

 .img-responsive {
     display: inline-block !important;
     max-height: 480px;
 }

 @media (min-width: 768px) {
     .pull-left.img-responsive {
         max-width: 50%;
     }

     .pull-right.img-responsive {
         max-width: 50%;
     }
 }

 @media (min-width: 992px) {
     .pull-left.img-responsive {
         max-width: 50%;
     }

     .pull-right.img-responsive {
         max-width: 50%;
     }
 }

 @media (min-width: 1200px) {
     .pull-left.img-responsive {
         max-width: 50%;
     }

     .pull-right.img-responsive {
         max-width: 50%;
     }
 }

[ permalink ]

[ 12月9日全て ]

2017年1月29日 (日)

nNote 始めました

永続的に残しておくほどではないちょっとしたノートを置いておくスペースとして nNote を始めることにしました。

https://www.naney.org/note

nDiki と同じく自作の DiKicker を使用しています。

Medium であったり note であったりその他の Blog サービスであったりと「何か」を書いて公開しておけるサービスを触ってみるたびに「この nDiki とは別に書くとしたら何だろう? 何を書きたいんだろう?」と考えを巡らせていました。

この nDiki は長く続けてきた中で

永続的に残すことを前提にきちんとした URL (記事 ID) にする。
誤読されないように、ある程度自分なりに推敲する。
AutomaticLink のために正確な用語で書く。
フィードが拾われて消費されることを前提に、きちんと書けてから公開する。

といった縛りが自分の中にできてきているので、もっと自由なスペースが自分は欲しいのではと思えてきました。

必要が無くなったら 404 を恐れずさくっと消して良い。
まだ自分としてこうだという結論に至っていない考えだったり何かの断片だったりを書いて良い。
最初から用語の正確性を追わなくて良い。
頻繁に更新して良い。

そういったノートを書き留めておく場所が欲しいんだなと。

そのためのサービス・プラットフォームで何がいいかと考えると、やはりテキストファイルでさっと新規作成・再編集をしてサーバに同期して公開・更新できるものがいいなぁという結論に至って、結局欲しいと思って自作して使っているこれ (DiKicker) じゃないですかと。日付有りノート中心になってしまいますが、まあいいかなと。

ということでさくっと設定だけ増やして nNote を立てるに至りました。

[ permalink ]

[ 1月29日全て ]