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年6月8日 (月)

Simplenote のノート共有はシンプルすぎた

昨日から Simplenote を使い始めたのだけれど、ノートの共有機能が漢だった。生成されたノート URL がわかれば誰でも編集可能になる潔い共有範囲だった。

Simplenote では「共有したい相手のメールアドレスでノートをタグ付け」するとノートの共有が有効になる。タグにしたメールアドレスの Simplenote アカウントがあればその人のノートリストに(問答無用に)そのノートが追加される。同時に通知メールが送られるのだけれど、そこに書かれている

 http://simp.ly/share/<ハッシュ値>

という URL にアクセスすれば非サインイン状態でもノートを閲覧することができる。というか閲覧だけでなく編集までできてしまう! 清々しい。とりあえずノート共有は使わないでおくことにしよう。

ちなみに公開機能の方は、ノートを公開にすると

 http://simp.ly/publish/<ハッシュ値>

という URL が生成される。こちらは閲覧専用 URL なのでさすがに誤解ない機能で必要なら使っても良いかなと。なお同一ノートについて公開と共有をした場合でも URL に含まれるハッシュ値はそれぞれで異なるので公開 URL から共有 URL を類推することはさすがにできないようになっていた。

スポンサード リンク

今日のさえずり: 絶滅危惧種の生茶パンダを発見

2015年06月08日

  • 09:34 絶滅危惧種の生茶パンダを発見。
  • 09:46 着席。 (@ 株式会社ミクシィ (mixi, Inc.) in 渋谷区, 東京都) https://www.swarmapp.com/c/ayJTvwpRgB0
  • 12:18 RT @mixi_PR: 弊社エンジニアブログ、新エントリはこちら! Padrino (WAF) の仕様変更にともなって発生した障害の原因を追いかけた話 - mixi Engineers' Blog http://alpha.mixi.co.jp/.../06/08/114539 #mixi
  • 16:03 月9のためにスクー会員登録しました。
  • 18:05 企画レビューしてもらいました。
  • 21:23 スクーでみんな「なるほど!」って言っているのなんでだろうと思ったら「なるほど!」ボタンがあるのか。なるほど。
  • 21:41 “Padrino (WAF) の仕様変更にともなって発生した障害の原因を追いかけた話 - mixi Engineers' Bloghttp://bit.ly/1eXNCfO
  • 22:21 Simplenote で特定のメールアドレスの人とノートを共有するとサインインしなくても閲覧できる URL が発行されると知って腰が抜けそうになった。
  • 25:15 Simplenote で共有ノートURL を渡せば、タグ付けにより指定したメールアドレス以外のアカウントでも編集まで許可されるのか。すごいな。
  • 25:22 あー、アカウントすら必要なかった。サインインしなくても編集までできる……。

[ 6月8日全て ]

2015年8月13日 (木)

nDiki を HTTPS に対応させる

昨日ラピッドSSLを申し込んで TLS 1.0 接続できるようになったので、ここからはコンテンツ側の対応です。

URL 処理を修正する

nDiki (DiKicker) はかなり昔に作ったので CGI.pm を使っています。CGI.pm の url メソッドで絶対 URL を取得して permalink の生成などをしています。ここでさくらのレンタルサーバでは HTTPS 用の Apache はプロキシとしてとして動いていることもあり https://www.naney.org/diki でアクセスすると CGI.pm の url メソッドが https://naney.org:80/diki を返してしまうようになってしまいました。

ここはいったん設定ファイルでスクリプトの URL を明示的に設定できるようにして対応しました。

内部リンクを修正する

http スキームで書かれた内部リンクは順次 https に修正します。結構な量があるのでおいおいという感じです。画像などのリソースを http で指定しているところは優先して対応した方が良いですね。

外部からのリンクを修正する

外部サイトのプロフィールなどで htts スキームで書いたリンクなども順次修正です。こちらもおいおいという感じで。


[ 8月13日全て ]

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日全て ]

Related term

About Me

Naney Naney (なにい)です。株式会社ミクシィで SNS の企画開発を行うグループのマネージャーをしています。CS 向上・コミュニティマネジメント・ユーザーサポート・健全化などにも取り組んでいます。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。

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

月別インデックス

Process Time: 0.097619s / load averages: 0.79, 0.72, 0.58
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker