  |
はてなキーワード: 記法とは
退職所得控除額が大きければ、退職所得も減り、かかる税金も減る。
退職所得控除額 = 40万円 * 勤務年数
※（最低でも80万円）
800万円 + 70万円 *（勤務年数 - 20年）
| 勤続年数 | 控除額[万] |
|---|---|
| 1 | 80 |
| 2 | 80 |
| 3 | 120 |
| 4 | 160 |
| 5 | 200 |
| 6 | 240 |
| 7 | 280 |
| 8 | 320 |
| 9 | 360 |
| 10 | 400 |
| 11 | 440 |
| 12 | 480 |
| 13 | 520 |
| 14 | 560 |
| 15 | 600 |
| 16 | 640 |
| 17 | 680 |
| 18 | 720 |
| 19 | 760 |
| 20 | 800 |
| 21 | 870 |
| 22 | 940 |
| 23 | 1010 |
| 25 | 1150 |
| 26 | 1220 |
| 27 | 1290 |
| 28 | 1360 |
| 29 | 1430 |
| 30 | 1500 |
| 31 | 1570 |
| 32 | 1640 |
| 33 | 1710 |
| 34 | 1780 |
| 35 | 1850 |
| 36 | 1920 |
| 37 | 1990 |
| 38 | 2060 |
| 39 | 2130 |
| 40 | 2200 |
参考：https://www.nta.go.jp/taxanswer/shotoku/1420.htm
画像表示されないのなんでだろ。。
Twitterにおける「@username」に近いかもしれない。
記事中のどこかに記事のURLを入れておけば、その記事に対して自動でトラックバックが飛んで、トラックバックツリーが形成される。
ちなみにURLを記事タイトルの欄に入れるのは慣習にすぎないので遵守する必要はない。
はてな記法と少し違う。
はてなダイアリーでは改行2つで空行だが、
↑このように半角スペースを入れることでも空行が作れるが、
これはHTML的に言えば<br />ではなく<p></p>なので微妙に違う。
改行タグを挿入する（改行記法） - はてなダイアリーのヘルプ
はてな記法と同じ。
[http://anond.hatelabo.jp/:title]と書けばページタイトルが取得されて表示される。→はてな匿名ダイアリー
[http://anond.hatelabo.jp/:title=自由なタイトル]と書くこともできる。→自由なタイトル
リンクを簡単に記述する（http記法、mailto記法） - はてなダイアリーのヘルプ
はてな記法と同じ。
>>
オルフェーヴル (Orfevre）は日本の競走馬。 中央競馬史上7頭目のクラシック三冠馬。おもな勝ち鞍は皐月賞、東京優駿、菊花賞（2011年）、宝塚記念（2012年）、有馬記念（2011年、2013年）。馬名はフランス語で「金細工師」（仏：Orfèvre）。
<<
こう書くと、
オルフェーヴル (Orfevre）は日本の競走馬。 中央競馬史上7頭目のクラシック三冠馬。おもな勝ち鞍は皐月賞、東京優駿、菊花賞（2011年）、宝塚記念（2012年）、有馬記念（2011年、2013年）。馬名はフランス語で「金細工師」（仏：Orfèvre）。
こうなる。
引用ブロックを作る（引用記法） - はてなダイアリーのヘルプ
はてな記法と同じ。
|*馬名|*出生年|*獲得賞金|
こう書くと、
| 馬名 | 出生年 | 獲得賞金 |
|---|---|---|
| オルフェーヴル | 2008年 | 13億4408万円 |
| ディープインパクト | 2002年 | 14億5455万円 |
こうなる。
はてな記法と少し違う。
増田では記事タイトルは別入力なので、「*」ひとつで小見出し記法の扱いになる。
もちろん時刻付き見出し記法は使えない。
小見出しをつける（小見出し記法、小々見出し記法） - はてなダイアリーのヘルプ
記事のタイトルの最初に[今日知った言葉]などと書くとカテゴリーを設定できる。
カテゴリーを設定しておくと、同じカテゴリーの記事を簡単に一覧できる。
使えたり使えなかったりする。
とりあえず、リンクと引用と表組みの使用頻度が高いんじゃないだろうかと思ったので、それ以外の説明は省く。
記事タイトルが長くなると、ちゃんと表示されるかと心配になって、つい「確認する」ボタンを押してしまいがちだが、実は確認画面では長いタイトルはちょん切られてしまう。
「確認する」ボタンを押さずに、そのまま「この内容を登録する」ボタンを押せば、記事タイトルが長大でも省略されずに投稿される。
増田標準のCSSを利用することでいろんなスタイルを使えるが裏ワザみたいなものだからあんまり多用してはいけません。
はてな匿名ダイアリーの標準スタイルシートでデコるバッドノウハウ
増田には連投規制がないので、記事登録時に「この内容を登録する」を連打すると、そのぶんだけ同じ記事が投稿されてしまう。
悪意はなくても、増田が重くなったときなどに投稿が反映されなくて、思わず連打してしまうことがある。
「反応が遅いだけできっと増田に投稿できている」と信じて、登録ボタンを押すのは一回だけに留めよう。
警告なしにぶった切られるので、めちゃくちゃ気合の入った長文記事ほど途中で終わり、
しかも執筆者本人はそれに気付かない、という悲劇が起こったりする。
<> ←ちゃんと表示される。
あなたの夢はどの馬ですか？ 伝説の名馬へ投票もできちゃうスペシャル企画！現時点ではサイレンススズカが単勝１番人気です。 【JRA】スペシャルＣＭ「夢の第１１レース」特設サイトを開設します！ https://t.co/911dJ2ZP09— (株)中央競馬ピーアール・センター (@JRA_PRC) 2015, 12月 10
増田は実験サービスなので、連投規制もないし、それが実装される予定もない。
はてなは増田なんかロクに見てないので、荒らしやbotが跳梁跋扈していてもBANしてくれる可能性は少ない。
そういう迷惑な増田を見かけたら問い合わせフォームから通報しよう。
twitterのツイートを増田に埋め込む方法を丁寧に書きます。
＊さっき一部の半角文字を増田で書けないと書きましたが数値文字参照にすれば書けました。訂正します！教えてくれた人あんがとー！でもスーパーpre記法ではこのやり方通用しなかったのでシンタックスカラーは無し。
twitter.comに行き ツイートの ... ボタンを押す。ツイートをサイトに埋め込むを押す。そうすると以下のHTML要素がコピー出来る。ここではサンプルにしても無害そうなifttt公式アカウントのツイートを引用します。
<blockquote class="twitter-tweet" lang="ja"><p lang="en" dir="ltr">Connect <a href="https://twitter.com/instagram">@Instagram</a> to <a href="https://twitter.com/Dropbox">@Dropbox</a> and automagically save every photo you post for safe keeping <a href="https://t.co/YVrgcSJZAD">https://t.co/YVrgcSJZAD</a> <a href="https://t.co/3vEiFZ3ADW">pic.twitter.com/3vEiFZ3ADW</a></p>— IFTTT (@IFTTT) <a href="https://twitter.com/IFTTT/status/662023324306837504">2015, 11月 4</a></blockquote> <script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
まあ増田を書く
先ほどのHTML要素のうち末尾のscript要素は引用する際,埋め込んだtwitter引用からはみ出て表示されるので邪魔です。取りましょう。
末尾のこれを取ります。
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
そうするとこうなります。これを増田にそのまま貼り付けてください。
<blockquote class="twitter-tweet" lang="ja"><p lang="en" dir="ltr">Connect <a href="https://twitter.com/instagram">@Instagram</a> to <a href="https://twitter.com/Dropbox">@Dropbox</a> and automagically save every photo you post for safe keeping <a href="https://t.co/YVrgcSJZAD">https://t.co/YVrgcSJZAD</a> <a href="https://t.co/3vEiFZ3ADW">pic.twitter.com/3vEiFZ3ADW</a></p>— IFTTT (@IFTTT) <a href="https://twitter.com/IFTTT/status/662023324306837504">2015, 11月 4</a></blockquote>
確認するボタンでツイートが埋め込まれてないのであれ？と思うかもしれませんがそのまま「この内容を登録する」を押してください。
増田のタイムラインでも埋め込みツイートは表示されずたんなる引用として表示されます。あれ？となるけど書いた増田記事の本文URLを開いてください。本文を表示した場合のみツイートが埋め込みで表示されます。
Connect @Instagram to @Dropbox and automagically save every photo you post for safe keeping https://t.co/YVrgcSJZAD pic.twitter.com/3vEiFZ3ADW— IFTTT (@IFTTT) 2015, 11月 4
応用すると以下のようにツイート内にインラインされている動画を増田にインライン出来るなど夢が広がりますね。あと増田はコードサンプルを書くにはクソですね。
気づいてない人も多そうですが、『マッドマックス 怒りのデス・ロード』の主役マックス役は 『ダークナイト ライジング』でベインを演じたトム・ハーディです https://t.co/cJ816F5Mpu https://t.co/Qh0iuQKFTl— アメコミ大全集（TM） (@amecomic) 2015, 12月 1
http://developers.linecorp.com/blog/ja/?p=3591
Letter Sealing って何でしょうか。私気になります。
必要な範囲で、原文を引用しています。原文は先に引用元のアドレスと閲覧日時を記し、引用記法によって地の文と識別できるようにしています。
ECDHとAES256-CBC 使ってみた。通信相手の認証については読み取れない。
図2 において、 Server のところで Re-Encryption (一度復号されて、再度暗号化されている) ことが明示されています。
この図を素直に読むと、送信者からサーバーまでの通信路は暗号化されているものの LINE のサーバーが受信したところで復号されて平文で保存され、サーバーから受信者までの通信路は暗号化されていると理解できます。文脈から、この流れを変えたいのであると推測できます。
http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年10月14日 22時40分に閲覧：
加えて、LINEでは、仮に通信ネットワークの傍受が行われたとしてもメッセージを覗くことができないように、公開鍵暗号(public key encryption)方式を使っています。ユーザーに対してLINEアプリを提供する際、暗号化ができる公開鍵のみをアプリに入れて提供し、ユーザー端末とサーバが接続されたときだけLINEサーバでのみ解析できる暗号化された安全なチャネルを作ります。こうすることで、SSL(Secure Socket Layer)より軽く、LINEの全バージョンで使用できる安全な暗号化を実現できます。
SSL はすでに時代遅れの代物で、 2015年秋現在は皆さん TLS を利用されていることでしょう。 Web ブラウザで SSL 2.0 や SSL 3.0 を有効にしているそこのあなた、今すぐ無効にしましょう。
TLS では、公開鍵暗号方式や共通鍵暗号方式、電子証明書、暗号学的ハッシュ関数といった複数の暗号技術要素を組み合わせて安全な通信路を確保しています。
RSA に代表される公開鍵暗号方式は一般的に AES に代表される共通鍵暗号方式と比べて計算量が大きい、つまり重たい処理となります。
このため TLS では、通信路を流れるデータの暗号化に共通鍵暗号を用いて、共通鍵の共有や相手の認証のために公開鍵暗号方式を用いるのが一般的です。
仮にメッセージの暗号化に RSA を用いているとしたら、 SSL より軽いという点をどのように実装しているのか気になります。
http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年10月14日 22時40分に閲覧：
ユーザー側のLINEアプリ(クライアント)には、サーバが発行したRSA鍵を使用してデータの暗号化に使う暗号化鍵値を共有します。この鍵を利用してデータを暗号化すると、第三者はメッセージを見ることができなくなります。
これは上で説明したとおり SSL や TLS でも行っていることです。
RSA を用いているので安全であるという主張をしていますが、メッセージの暗号化に用いられている暗号スイート（アルゴリズムの種類、鍵の長さ、ブロック暗号の場合は暗号利用モード、そしてハッシュアルゴリズムの種類）は、その通信路が安全であると判断できるか否かを決める大切な情報です。
http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年10月14日 22時40分に閲覧：
既存のRSA方式も秘密データの共有に使う安全な方式ではありますが、鍵管理の面から見ると、ユーザー側の端末でそれぞれのRSA鍵をすべて管理しなければならないという問題があり、その代替手段としてDHを使用するようになりました。
DH および ECDH による共通鍵暗号に用いる鍵の交換は SSL や TLS でも実装されており近年では広く使われています。 SSL より軽いと主張し、 SSL や TLS が公開鍵暗号方式以外の要素によって担保している安全性をどのように確保しているか不明な実装に比べると、大きな改善です。
なお SSL や TLS においては通信相手の公開鍵を全て管理する必要がないように、上で説明した電子証明書による公開鍵基盤 (PKI) の仕組みを利用しています。
つまり共通鍵暗号に用いる鍵の交換にどのような手段を用いるかは、鍵管理とは（ほぼ）独立です。
http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年10月14日 22時40分に閲覧：
ここでメッセージの暗号化に使用している暗号化アルゴリズムはAES-CBC-256という方式で、現在一般に使われている暗号化アルゴリズムの中で最も強度が高いと評価されています。
メッセージ認証と組み合わせない CBC はビット反転攻撃に弱いことが知られています。 GCM ではデータの暗号化と認証を同時に行うためビット反転攻撃に耐性があります。 AESを GCM で利用するのは、 最近の TLS の実装では広く用いられており、 Google や twitter も利用しています。
CBC も CBC-MAC のようにメッセージ認証と組み合わせることでビット反転攻撃に強くなります。
図6 のとおり、 ECDH で共通鍵暗号に用いる鍵の交換を行うにしても通信相手の公開鍵は必要です。 上で説明したとおり鍵管理という問題への解決策になりません。また公開鍵が本当に通信相手のものであることをどのように検証するのかについても不明です。通信相手の検証は、送信側では秘密の話を他の人に知られないように、受信側では他の人になりすまされないように、双方にて必要です。
ここからは安易なパターンの想像ですが、通信相手の公開鍵情報は LINE ユーザー情報の一部として LINE サーバーで管理されており、必要に応じて安全な通信路を用いて LINE サーバーから取得するようなものではないかと思います。公開鍵情報のやりとりに用いられる通信路に正しく実装された TLS が用いられていて、サーバーとクライアントの両方が認証されていて、現在の水準から見て妥当なレベルの暗号スイートが用いられていることを願うばかりです。
公開鍵と秘密鍵がどこでどのように保管されているのか気になります。各端末で保管するのが安全ですが、サービスの要求として端末を乗り換えてもメッセージが読めるという条件を安易に満たすために秘密鍵を LINE サーバーに預託していないことを祈るばかりです。
ECDH 鍵の生成は計算量が大きい処理であり質の良い乱数を必要とします。 PC に比べると非力なスマートフォンで生成した鍵の質をどのように担保しているのか気になります。
先ほど閲覧したところ、上記引用箇所の多くは削除されていました。公開鍵が本当に通信相手のものであることをどのように検証するのかについては明らかではないようです。 LINE サーバーが介在する形であれば、鍵をすり替えることで別のユーザーになりすますことが可能でしょう。または、 LINE アプリに何か細工をする方がより簡単でしょう。
ECDH 鍵はその場限り (ephemeral) という説明がないので Perfect Forward Secrecy ではないと考えられ、望ましくないという意見もあるようです。 LINE サーバーとの間に安全な通信路を確立する目的で ECDH 鍵を用いる場合、 LINE サーバーが用いる秘密鍵の漏洩は全てのユーザーに影響を与えうるため PFS は非常に重要です (TLS を用いた Web サーバーでも同様です) 。一方ユーザー間でメッセージを暗号化する場合、ユーザー所有の ECDH 鍵についてはそのユーザーに影響が限定されます。通信相手ごとに必要なその場限りの鍵生成とユーザー所有の ECDH 鍵を利用した鍵交換にかかる計算量と ECDH 鍵漏洩のリスクを天秤にかけて PFS を採用しないという判断かもしれません。
通信の秘密という観点ではメッセージの内容だけではなく誰と通信したか (または、していないか) という情報も守りたくなります。宛先を LINE サーバーで確認できない形に暗号化されるとメッセージの配送ができなくなるため、通信相手や通信の有無については秘密ではないと考えられます。
http://tradenote.info/blog-entry-3.html
一般に、バッカスナウア記法は正規表現では処理できないネストの階層を記憶できるなどの根本的な差があります。
これは正規表現が有限決定性オートマトン（DFA）ないしε遷移と不特定の同種記号の遷移を用いる非決定性オートマトン（NFA）に基づいているのに対し、BNF記法での解析は必然的にスタックを内部状態に持つからです。
https://ja.wikipedia.org/wiki/LL%E6%B3%95
これは左からトークンを走査して、導出する非終端記号を左から決定していくアルゴリズムです。
例えばA→A Bという構文規則があった場合に、Aの還元内でAを還元できるかどうか判定し続けて無限ループに陥ってしまい、いつまで経ってもBの判定に辿り着けません。これを左再帰といい、LLでは左再帰を直接扱う事ができません。
非終端記号の間接的還元を考慮したはじめに現れる終端記号の集合（FIRST集合）を構築して上手く左再帰を回避しなければなりません。
マッチングに用いる規則をベタに関数内部に再帰させながら順番に書いていくだけなので実装は容易です。
https://ja.wikipedia.org/wiki/LR%E6%B3%95
https://ja.wikipedia.org/wiki/LALR%E6%B3%95
こちらは左からトークンを走査して、導出する非終端記号を右から構築するアルゴリズムです。
BNF構文規則から走査に相応するDFAを構築し、DFAの遷移を記憶しながらスタックに状態をpush/popし構文解析を行います。
なのでLL法にあるような左再帰を直接扱えないという欠点がなく、むしろスタックが簡潔になるため積極的に左再帰のBNF記述を行った方が効率よく処理を進められます。
LR法はDFAの大きさが巨大になるため、実用的ではないようです。
LALR法はLR法を改良したアルゴリズムで、扱える構文クラスの範囲はLRよりも少し小さくなりますが現実的な計算資源で構文解析を行う事ができます。
２０代の女が４０代男と恋愛、しかも不倫、さらに金をもらってる、専業主婦予定…
文章に無駄がなく、伝えたい舞台設定・要点が簡潔に盛り込まれている。
自分と相手の状況、恋愛関係であること、金銭の受け取りがあっても恋愛と言えるかとの問題提起まで、ごく短い文章中に無駄なく収められている。
誤解しやすい表現、独り善がりな表現、ノロケや愚痴や陶酔といった感情の吐露も一切ない。
段落まで改行しない、文章的に正しい記述方法。句読点のタイミングでブツブツ改行入れたり、無駄な改行でスペースとったりもしない。
以上、自分が
要するに巧い文章だということ。
逆に言えば、ブツブツ改行入れて・たまにポエミーなこと言いつつ・おまえは何を言ってるんだ、と突っ込みたくなるほど下手な文章だったら、釣りだとは思わなかったと思う。
半角の不等号はスマートフォン用の表示で見るとちゃんと表示されるという…。
var s1 = (new Func＜string＞(() =＞ { var o = "Wow!"; return o; }).Invoke());
var s2 = (new Func＜int, string＞((f) =＞ { return f.ToString(); }).Invoke(100));
var s3 = (new Func＜int, int, string＞((f, g) =＞ { return (f + g).ToString(); }).Invoke(100, 30000));
半角の不等号が使えないとか、pre記法？で日本語が文字化けするとか、ほかの皆さんはよく不便しないよな。。
増田では表示できないはずのTwitterの呟きや巨大文字、色文字、シンタックスハイライト済みのコード、
これらが正しく表示される増田を書く増田が11人の中に紛れこんでいる。
彼らはどうやってそのような増田を書いているのだろうか。私は下記の可能性を疑っている。
今回はメイキング関連。
真面目に答えず、出来る限り嘘と虚構を織り交ぜて答えていきたい。
基本的には関心のある事柄から選んでいるが、「回答できそう」という漠然とした感覚で選ぶこともある。
ふざけて答えるか、真面目にふざけて答えるかは、その時の気分次第だ。
書くときに「嘘八百にしよう」と思っていたものが、書いている途中で「嘘八千にしよう」となるときもある。
ただ、出来る限り「それっぽいことを言っている」ように回答することは心がけているかな。
このシリーズのテーマは「質問と回答」だが、私の中では「如何にそれっぽく言語化できるか」、「自身の心と切り離せるか」というのもあるから。
では、なぜ今回この質問を選んだかというと、最近とあるメイキング映像を観たんだよ。
「ああ、この体で話すのいいな」と率直に思ったのさ。
あとモーションキャプチャーで猿の演技をしている役者と、笑わずに演技している役者たちの姿に心を打たれてね……。
言っておくが、別に記法を把握していないから、不恰好なリンクで済ませていたとかではないからな。
見返して欲しいような内容を書いていないからだ。
「どうせ需要ないからテキトーでいいだろ」とか思っていたわけでもない。
まあ、要望には答えよう。
今回のカテゴリ付けで、「振り返り関連」などの過去の記事が一貫性のない内容になってしまった箇所もあるがそのままにしておく。
どうもしないね。
私の求めるものの7割は書いた時点で達成されている。
このシリーズはちょくちょく書いているが、それら全部のブクマ数を合わせても、私が数年前に書いたとある記事のブクマ数には遠く及ばない。
その記事はユーザー初心者を装って、如何に面白いブコメをするかの思考模様を書いたものだ。
なのだが、真面目に考察しているようにみせて、実は皮肉った構成にしてある。
他にも漏れを作ったり、あからさまな誤用や誤字を入れたりして、反応しやすいようにした。
そうしてその記事は200以上のブクマ数になり思わず口元が緩んだ。
ただ、しばらくすると「これがこんなにも注目されるのか」と空しくなってきたんだ。
それからは反省して、書いていて「楽しい」と思えることを第一にした。
今でも本質的な部分は変わらないけれど、真面目さのベクトルを変えた。
実際に変わったのは私だけだが、世界が変わって見えたよ。
朝目覚めてスっと起きられるようになったし、あれだけ昔は吸っていたタバコも必要なくなった。