nDiki : URL

URL - Uniform Resource Locator

URI escape (Perl)

によると

 $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)

同じく

によれば、

 $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.

関連情報

スポンサード リンク

2015年12月9日 (水)

今日のさえずり: 宇宙パワーシール届きました!

2015年12月09日

  • 09:57 隕石パワーシール届きました!
  • 10:01 宇宙パワーシールでした!
  • 13:29 Slack 分報、ぼっちる可能性があるのですね。
  • 13:56 真似して Slack に分報チャネル作ってみました。
  • 13:56 Twitter 世代ですから。
  • 13:59 Google Chrome のホームボタンの URL を分報チャネルに設定。
  • 20:54 お腹が空いているせいか家路が寒いです。
  • 21:02 “スマホゲーに「レア」がでてくる理由と、人間が「課金したゲーム」を消せない心理。海外コンサルが教える、ゲームに使われている7つの心理テクニック。 | アプリマーケティング研究所” http://bit.ly/1M2Gmb0
  • 24:25 紀伊國屋書店男前! / “勝手に作った巨大ブックカバーを紀伊國屋書店に引き取ってもらう - デイリーポータルZ:nifty” http://bit.ly/1Y28S3b
  • 24:55 もちだっつを食べている我が本部のみなさま、しろくまはどうなりましたか。
[ 12月9日全て ]

2016年5月17日 (火)

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

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

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

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

2016年05月17日

[ 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/〜 になってしまっていた)のに気がついたのでここもあわせて修正しておきました。

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

2016年05月20日

[ 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クリックでコピーできて便利。

[ 6月16日全て ]

2016年7月19日 (火)

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

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

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

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

[ 7月19日全て ]

2016年7月20日 (水)

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

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

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

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

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

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

[ 7月20日全て ]

2016年10月30日 (日)

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

https://www.naney.org/nDiki/2016/10/30/Deckset.jpg

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

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

スライドを書く

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 はそこを気にしなくて良いのが楽です。CSSJavaScript コードをいじれる reveal.js に比べると細かいカスタマイズは全然できないのですが、その分デザインは Deckset に任せると割り切って内容だけに集中してさくっと書けます。

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

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

[ 10月30日全て ]

2016年12月9日 (金)

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

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

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

一方デメリットとしては

  • 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%;
     }
 }
[ 12月9日全て ]

2017年1月29日 (日)

nNote 始めました

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

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

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

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

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

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

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

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

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

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

[ 1月29日全て ]

2017年5月26日 (金)

東京ディズニーランドの準備

明日東京ディズニーランド(TDL)へ行くので準備。

2015年10月26日に発表された東京ディズニーリゾート公式 ショー抽選アプリもインストールしました。一昨年 TDL に行った時はまだ無かったので今回が初。現地でないと機能しないように作られているので明日使ってみます。

それから、やはり公式ページの情報が確実なので当日見やすいように Xperia Z5 のホーム画面にショートカットを追加しておきます。

旅のしおり的なやつは今回は個人のメモとして Google Keep に入れておくことにしました。スポット別にメモを作って公式サイトの URL を貼りつつ、テーマランド名をハッシュタグでつけたり、ポイントを書いてます。他人と共有したり印刷したりするつもりが無ければ手軽でよさそげです。

[ 5月26日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィでマネージャー・PO をしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

follow us in feedly

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.074374s / load averages: 0.43, 0.62, 0.68
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker