Markdown in 2016 - Hack like a rolling stone
Markdown、あなたのすぐとなりに潜む問題 昨日は toc 拡張の話ついでに、現在の Sphinx と markdown を取り巻く環境について愚痴ったわけですが、Markdown 業界は 2016年のこの時期になっても、いまだに共通的な仕様が決まっていません。 2004年、John Gruber によって生み出された Markdown は、12歳を迎えた現在、さまざまな markdown 処理系を持っています。 そして、不幸にも実装によって markdown の処理はそれぞれ異なってしまっています。 これは Markdown の仕様が曖昧であることと、それぞれの処理系で文法の拡張を行っていることから来ています。 Markdown 処理系による違い Markdown の仕様が曖昧であることは、さまざまな混乱を生み出しました。 babelmark2 が示すように、同じマークアップであって
RFC 6570: URI Template
Internet Engineering Task Force (IETF) J. Gregorio Request for Comments: 6570 Google Category: Standards Track R. Fielding ISSN: 2070-1721 Adobe M. Hadley MITRE M. Nottingham Rackspace D. Orchard Salesforce.com March 2012 URI Template Abstract A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion. This specification def
中里一日記: 地層
地層 TCP/IPスタックを介さずに直接Ethernetフレームを送受信すれば遅延が減るはず、なら低遅延のためにデータリンク層をEthernetとL2スイッチに決め打ちしたプロトコルがあるはず、と思ってぐぐっていたら、こんなものを見つけた。 Ethernet Type Codes 消滅してしまった企業の数々と、忘れ去られたRFCの数々が並んでいる。 わざわざEthernet Typeを割り当ててもらうくらいなのだから、それぞれ当時はそれなりに力の入った規格だったのだろう。成功する規格がどれほど少ないかを客観的に見せ付けられて、ため息が出た。 なお、Ethernet決め打ちプロトコルは現状GAMMA一択のようだが、プロトコルの詳細がどこにも出ていないような気がする。
L'eclat des jours(2007-02-01)
_ 仕様書を読む本 RHGは、実装を読む本だったわけだが、仕様書を読む本というのはどうだろうか？ 仕様自体があまりに長かったり複雑だったりすると躓いたり途中で嫌になりそうだから（まあ、そういうのはあるなぁ）、たとえばECMAScriptとか、いや温故知新でNewtonScriptとかでも良いかも。 で、仕様書の読み下し＋実装という感じ。実装言語はやっぱりCかな？ C++でも良いかも。でも実装はどちらかというとおまけで、仕様の読み方とリファレンス実装として既存の実装での動作の確認とか。 #別に言語じゃなくても、RFC2616とか、RFC821（古いな。多分これだけじゃだめなんじゃないか？）RFC2821とかでも良さそうだ。 追記：高橋さんが教えてくれた RFCの読み方―インターネット技術の公式仕様書(聖, 瓜生) って、実装の仕方はついてなさそうだけど、結果的にBNFの読み方を知ることもでき
ちょっとしたメモ - 時間軸を使うURIスキーム、tag:がRFCに
今どきtagというと流行のfolksonomyのことと思ってしまいそうだが、これは全く別物で、tag:というスキームを用いる新しいURIを定義するもの。近くInformational RFCとなることが告知された。特徴としては、名前解決（リソース取得）を前提としないのでネットワーク上に存在しないものの名前付けに使いやすいこと；時間軸を持っているので、将来にわたって名前の衝突（重複）を回避できること；が挙げられる。 URIは、ブラウザなどでリソースを取得するための「アドレス」としてだけでなく、リソース一般を名前付け（識別）する役割を持つ。しかし、このときhttp:を使うと、そこには何か取得できるリソースがあるように思われやすいため、以前から混乱の要因になっていた。たとえば、名前空間URIにはその文書型のスキーマがあるべきかどうかとか、RDFのリソースはHTTPでアクセスできるのか、など。 t
Message-ID
Message-ID に関する考察（第三版）：改訂作業中 1998年8月9日初版発行、1999年2月5日第二版発行、2001年3月16日第三版改訂中 目次 はじめに Message-ID とは何か？ Message-ID は付けるべきものか？ Message-ID はどこで生成されるのか？ Message-ID はどのような形式で生成されるのか？ ユニークな Message-ID をクライアントマシンのメイラーが生成できるか？ 補足文書 qmail とヘッダーの補完に関して RFC2476 Message Submission Windows における TCP/IP の設定 はじめに この文書はメイルにおける Message-ID に対する考察を行ったものである。ニューズに関しては行っていないことをあらかじめ考慮していただきたい。 この議論の叩き台として、メイルのメッセージの形式を定めた
技術メモ帳 - URI の data スキーム
今日初めて知ったのだが、data スキームを使えば URIにデータを組み込めるそうだ。 以下のようにすれば、 dataスキームで、任意の画像を表示させる事が出来る。 <img src="data:image/gif;base64,BASE64データ"> たとえば、 google のロゴを dataスキーム を 利用して表示したかったら、 $ curl -s http://www.google.com/images/logo_sm.gif | openssl base64 | tr -d '\n' こんな感じで base64 化したロゴ画像データを 該当部分に、貼付ければ良い。 <img src="data:image/gif;base64,ここに貼付ける。"> 該当RFC: http://www.ietf.org/rfc/rfc2397.txt
ちょっとしたメモ - application/jsonがRFC4627に
3月末にアナウンスされていたJSON仕様のRFCが、RFC 4627 The application/json Media Type for JavaScript Object Notation (JSON)として公開された。メディアタイプは表題の通りapplication/jsonで、標準ファイル拡張子は.jsonとなっている（拡張子の話は前回書き忘れた）。一部のミス修正以外は最終I-Dとほぼ同じ内容でRFCとなった。 XMLHttpRequestでの処理にはメディアタイプはあまり関係ないが、ブラウザで直接ファイルを開こうとするとapplication/jsonの場合はダウンロードが始まってしまう（Opera9では「XMLの解析に失敗しました」となる…？？）。実用には支障ないものの、手軽にデータを確認できないのは残念なところ。.jsonにapplication/jsonをマッピングするか
みんなで渡れば怖くないの罪 ― au by KDDI メールアドレスにRFC違反を故意に許すの巻
Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Healthy Weight Loss Migraine Pain Relief Health Insurance fashion trends Parental Control Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy|Do Not Sell or Share My Personal Information
Ywcafe.net
Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Credit Card Application Dental Plans Cheap Air Tickets Parental Control song lyrics Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy|Do Not Sell or Share My Personal Information
ＲＦＣ日本語版リスト
リンク上の問題や追加情報があるようでしたらどしどし連絡してください。 インターネットに散らばるＲＦＣの 日本語訳（和訳）のリンクリストを作りました。 多分、同じ翻訳で、コピーが複数あると思えるのはまとめて１行にしています。 （高橋邦夫さんが訳したＲＦＣ１８５５はあまりにもコピーが多いので一部のリンクのみ掲載しています） 同じＲＦＣを、多分別の人が翻訳したと思えるのは別の行にしています。 時代の流れでなくなったページもあります（場所が変わって見つかっていないだけかもしれません）。 [日本語訳]が付いていない所はそんなページと思ってください。 ソースにはコメントとしてＵＲＬを残してあります。 いずれかのアーカイブを探せば見つかるかもしれません。 これらの日本語訳は完全なものとは限りません。 間違って翻訳していたり、 途中だけ翻訳されてたり、翻訳の途中で中断・中止してる事もあります。 翻訳の公開
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Unicode: UTF-9 への変換方法 - seclan のほえほえルーム
mac-server.com - このウェブサイトは販売用です！ - mac server リソースおよび情報
[ruby-dev:29462] Re: [ruby-cvs:17256] ruby, ruby: * time.c (time_to_s): generate RFC822 style date string.
RFC4627 JSON (ざっくり訳)
RFC 4627 The application/json Media Type for JavaScript Object Notation (JSON)
RFC3029 Etymology of "Foo" 「foo」の語源
http://rfc.net/rfc3043.html
fam.cx
void GraphicWizardsLair( void ); //