どらのブログ

2017/09/10

WebPayments と仮想通貨の関連性について

この記事について

　少し前から仮想通貨に興味があり、界隈の動きが気になっている。

　動機としては、「日本での支払いはクソめんどくさすぎる、何とかしてくれ」という事がある。中国では QR コードでサクッとどこでも支払いができるとか、硬貨で支払いをしようとしたら「硬貨とか紙幣使うなんて恥ずかしいからやめてくれ」と言われた、といった話は聞くが、完全に日本は置いていかれている感がある。日本終わりです、終わり！…一応日本でも Suica で支払いができたりするが、日常で接する全ての店舗でそういった便利な支払いができるかと言うと全くそんな事はない。実際、硬貨や紙幣なしに生活できるかと言ったらできないでしょう。

　リアルワールドでの支払いはそんな感じで絶望的な状況な訳だが、Web での支払いは比較的デジタルで便利だ。とは言え、仮想通貨での支払いはまだまだ整備されていない。WebPayments はここに関係してくるのか？WebPayments とは一体何なのか？という事について、少しだけ調べたので備忘的に書いておこうと思う。

　そして、おそらく色々間違っているところがあると思うので、専門家の人に是非ツッコミを入れて頂きたいと思っている。

結論

　一応、調べた限りの結論を先に書いておこうと思う。結論は、こうだ。

　WebPayments は仮想通貨での支払いに使われる可能性も秘めているが、現状形はなく、将来に期待。

　仮想通貨で支払う時には「支払いに同意する」という行為をどうやって実現するかが問題になるが、詳細は後に書く。この結論に至るまでには色々と知識が必要なので、面倒に感じるかもしれないが順を追って書いていく。

WebPayments とは何なのか？

　これがいきなり難しい問いだ。結構浮ついたワードとして出回っていて、実態がよく分からない。個人的な理解としては、こうだ。

　WebPayments とは、Web 上で支払いを行うための、"HTTP 上の仕組み" と "JavaScript 上の仕組み" を総称したものである。

　間違ってるかな？（笑）よく分からないので専門家の方に教えて頂きたいところである。具体的に W3C 上での参照を下に記す。

HTTP 上の仕組み

https://www.w3.org/TR/webpayments-http-api/

JavaScript 上の仕組み

　具体的な利用例としては、下記の様になるのではないかと思う。

HTTP 上の仕組み

サーバーサイドから支払いのリクエスト（ステータスコード 402 のレスポンス）をクライアントに送り、支払いをしてもらう。アプリとの連携などが考えられる（ブラウザが対応するのかはよく分からない）。

JavaScript 上の仕組み

ウェブサイト上のスクリプト発端で、支払いを行う。ショッピングサイトでの支払いなどが考えられる。

　どちらにしても、実際の支払いの方法は下記の様なものになるのではないかと思う。

カード情報や発送先などの情報をサーバーに送り、サーバーが別途それを利用し、支払いを行う。支払いをされる側がカード情報を一旦でも保持するのが特徴。
カード情報は送らずに事前にカード会社から取得したトークンと発送先などの情報をサーバーに送り、サーバーは別途トークンをカード会社に送って支払いを行う。支払いをされる側としては、カード情報にタッチしないのが特徴。

　両者の違いが分からない人は、@agektmr さんの Web Payments はなぜ避けて通れないものになるのか - ウェブでの新しいお金の払い方の記事を読んで理解してもらいたい。

仮想通貨で WebPayments を利用するには？

　さて、もともとの疑問であった「仮想通貨で WebPayments を利用する事はできるのか、できるのならどうやってするのか」という事だが、先ずは「現状は形がない」という認識だ。何故なら、現状の Payment Request API はクレジットカード情報の利用が前提となっているからだ（合ってる？）。

　仮想通貨で支払いをする時に問題になるのが、「どうやって支払いに同意した事にするのか（秘密鍵で署名しなければならない）」という部分だが、現状の仕組みを見ると、Payment App を利用すれば可能性がある様に思う。例えば下記の様な形ではないだろうか。

クライアントは、Payment App で仮想通貨のトランザクションに署名した状態でトランザクション情報を返す。それをサーバーに送信し、サーバーは仮想通貨に応じたバリデーションプロセスに乗せる。
クライアントは、Payment App で仮想通貨（の秘密鍵）を管理するサーバーにトークンを発行してもらい、そのトークンを被支払い者のサーバーに返す。被支払い者はそのトークンを仮想通貨を管理するサーバーに送って支払いを行う。
※情報を秘匿したいというよりも、秘密鍵をクライアントで管理しない可能性があるのではないか、という話

　この様なプロセスが実際可能な仕様になっているのかはいまいち分からなかった。Payment App まわりがどうなっているか、情報が収集できなかったためだ。ごめんなさい。そのうち調べます。

仮想通貨で支払う時の問題

　仮想通貨で支払いを行おうと思った場合、支払いを行う者と支払いを行われる者でメインとしている通貨が違う事が起こり得る。例えば、A さんは BTC で支払いをしたいと思っていて、B ショップはいやいや円が欲しいです、といった場合や、C ショップでは LTC がよいと思っているかもしれない。

　どこかで聞いた事のある様な話だ。まさに ILP と IoV が解決してくれる話だと思う。具体的なフローは疲れてしまったので割愛するが（ぉぃ）、Payment App が ILP に対応したレジャーに対して支払いをさせる様にすれば、可能だと思う。

　次回がもしあれば、そのフローについてもう少し詳細に書いてみたいと思う。

参照

2017/05/08

暗号通貨界隈に最近入ってきた方に言いたいこと

前書き

#暗号通貨界隈に最近入ってきた方に言いたいことっていうハッシュタグが Twitter で盛り上がっている様なので自分もポエムを書いてみる事にした。ブログにしたのは Twitter に書くには長くなりそうだなと思ったから。

　なお、「俺たちは先にいたんだぞ、お前ら後から来て何も分かってないだろ？え？」みたいな事を言うつもりはないし、そういう慢心スタイルのやつがいそうなのでこのハッシュタグも微妙に気持ちワリィなと思ってはいるんだけど、ポエムの機会としてよさそうなので書いてみる。

　まず前提として、自分の知識レベルを書いておこうと思う。要は素人です。

仮想通貨まわりの動きは 2014 年くらいからチラチラは見ていた
ただし、本当にチラチラ見ていただけでそこまで深い知識がある訳ではない

ブロックチェーンのコードが書けるかと言ったら書けない

実際に初めて購入したのは 2016/02 で、BTC を購入した
現状の投資比率は以下の通り（ざっくりの値）

JPY 52%
BTC 27%
XRP 11%
LTC 7%
ETH 2%

何を書こうか迷ったのだが、以下の点に集約されるのではないかと思った。それぞれについて、少し詳しく書いてみようと思います。

うかれるな、お前は何も価値を生み出してはいない
最終的には自分で判断しろ
絶対安心な通貨なんてない

うかれるな、お前は何も価値を生み出してはいない

　どっかの某バカ芸人が「XRP! XRP!」とか叫んでるの見るとほんまにイライラしてくるんだけど、お前は何も価値生み出してねーんだよ、うかれるなって思う。仮想通貨って、株と違って「社会に何か価値を生み出した人がその利益の一部を投資（＝価値を生み出す手助け）をしてくれた人に還元する」とかいう構図ではなくて（厳密に言うと XRP はそれに近いトコはあると思う）、先に手に入れてた人が後から来た人に高く売りつける事で価値が移動する、っていう事だと思っています。だから、含み益が出たところでそれはその人が何か社会に価値を生み出したっていう事ではなく、「知らなかった」、あるいは「買う勇気がなかった」人から取ってるだけ。別に完全に悪いとは言わないけど、パッパラパーみたいに浮かれるのはみっともないしなんかこいつ人間浅いなっていう感情しか浮かばない。

　なお完全に悪いと言わない理由は、仮想通貨に早めに価値を見出してそこに価値の保存をしようと思うのは自由だし、後からそういう人がたくさん出てきてその結果として価値が上がるのは市場の原理として普通だし、それを認められるのは嬉しいし、別にいいと思うから。けど、そこには「知らなかった人たちが相対的に損をしている」っていう構図があるし、一昔前に言われたデジタルディバイド的な意味での「仮想通貨ディバイド」が起きているだけだと思っていて、社会的にとてもいい構図かと言われたらそうでもないと思っている。要するに俺らは仮想通貨ディバイドに乗じた悪モンなんだよ、っていう意識はどっかに持って欲しい気がしている。

　また、仮想通貨が長期的に見て社会に対してよいものだとすると、早めにそれを取り入れて実験して広める努力をしているとも見る事もできるので、そういう意味も込めて完全に悪いとは思っていない。

最終的には自分で判断しろ

　どっかの某取引所のチャットとか見てると「〜って上がるんですか？」「〜って儲かりますか？」みたいな書き込みをたくさん見るんだけど、お前らそんなところで聞いた話を鵜呑みにする訳？！バカなんじゃないの？！死ぬの！？って思う。その場の繋がりだけで全く信用できない（ただ自分が儲かればいいと思ってるやつも当然たくさんいる）し、全く根も葉もない噂を書いてる可能性もある。「BTC って実はクラッカーに狙われてて、セキュリティをついて全データ壊せちゃうセキュリティホールが見つかったらしいよ」みたいな事を言われたらそれ信じるんですか？！っていう（これは例え話ですよ）。

　BTC はすごい！とか、XRP はすごい！とか、そんなもんその仮想通貨持ってる人がやんややんや騒いで盛り上げて売り抜けようとしてる可能性もあるんだから、自分で判断するしかねーんだよ、と思う。

　補足しておくと、一部の人はその通貨の可能性を信じている根っからの HODLER（HODL する人 = HOLD する人 = 基本的には売らない人）で、単純にその通貨が素晴らしいものだと思って発信している人もいる。そういう人含めて、「一見見分けは付かないから注意しろ」っていう事。

絶対安心な通貨なんてない

　結局のところ、絶対安心な通貨なんてないと思っている。BTC も危ないし XRP も危ないし JPY や USD だって危ないと思う。俺は通貨の価値は持続可能性にあるんじゃないかなと思っていて、それはどういう事かと言うと、

　持続可能性 = 依存度 × 代替可能性 × 利便性 × 運用安定性

依存度 = 国家依存度 × 企業依存度 × 組織依存度とか。国家や企業や組織がぶっ飛んだら通貨もぶっ飛ぶ可能性
代替可能性 = 似た様な別の手段でも同じ様に価値を保存できる可能性
利便性 = 速度 × セキュリティ × 可用性 × 維持効率 × 実生活での利便性など
運用安定性 = 意思決定がきちんとできるかどうか、メンテナンスが行き届くかとか

　とかかなと思っている（ぱっと考えたので MECE じゃないかも、すいません）。例えば BTC は国家依存度や企業依存度はとても低いが、LTC に代替できるのでは？と言われたらそうかもしれないし、速度の面でスケール問題が出ているし、意思決定ができないために分裂問題も起きている。XRP は国家にはあまり依存しなさそうだけど企業には依存してるのでリップル社がぶっ飛んだらどうなるか分からない（XRP 最終的にやっぱ使いませーん！って言われたらどうなるの？っていうのもある）し、代替可能性も現時点ではあるっちゃある。

　日本円だって国家依存度ガチガチだし、少子化していく日本の事を考えたら、人口下がる・年寄りだけになる→生産力下がる・消費下がる・競争力下がる→日本終わり・JPY 終わりってなって価値激減とかもあり得ると思う。

　まぁこの辺は詳しい人はいろいろ意見があると思うけど、「絶対安心です」っていう通貨なんて結局ないでしょう？と思う。

　だからこそ、自分でどこにどれだけの持続可能性があるかを判断して分散して保存していくしかないと思う。言うて、仮想通貨ディバイドが起きる前提で考えると一点集中で未来に爆発するっていうシナリオに掛ける人もいるだろうし、したいならすればいいと思う。

終わり

　疲れた。ばばっと書いたからなんか色んな人に突っ込まれそうだし批判もされそうだけど、とりあえず今思っている事を吐き出せたのでスッキリした。おやすみなさい。

2015/06/10

Realforce を Mac で使う

　単刀直入に Mac で Realforce を使う時の設定です。頑張って超丁寧に書く気力がないので要点だけ書きます。

私が使ってるキーボード

Realforce 91UDK-G

必要なソフトウェア

設定

システム環境設定→キーボード→修飾キーのマッピングを下記にする

Caps Lock = Control
Control = Caps Lock
Option = Command
Command = Option

Karabiner

Change Backquote Key

Backquote to Escape

Seil

For Japanese

■ Enable NFER Key on PC Keyboard
■ Enable XFER Key on PC Keyboard

　これで全体的に Mac っぽい扱いができるはずです。私はこれがお気に入りです。Realforce サイコー！

2014/04/22

コンピュータの基礎について学び直す

　最近仕事でネイティブ層の事についてごにゃごにゃする事が多く、あれ、もはやその辺の事を勉強したのって10年以上前だしぶっちゃけほとんどちゃんと書いてないし覚えてないよ…って事で少しネイティブの事を学び直してみようと思ってます。目指せ・脱なんちゃってエンジニア※。「その年になってそれかよ…お前…」（齢30）と思われるかもしれませんが、この年だからこそ問題だと思ったらさっさと克服しないとそれこそ手遅れになるので、いい機会でしょう。

　コンピュータの基本的な動き方を理解するという所で、コンピュータの基本的な構造をおさらいしつつ、アセンブラでちょこちょこっと相当低レイヤーな所を書いてみるというのは手頃な気がします（手頃にそんな事できるんかっていう話もありつつ…）。

　が、あえてその過程については書かない事にします。何故なら過程をそのまま書いた記事は恐ろしく分かりにくいという事を知っているからです。一番分かりやすいのは、分からなかった人が、分かった時に、分からなかった時には何が分からなかったのかを思い出しながら、全体を把握した上で構造的に記述した記事、だと考えています。

　なので、そういった記事が書ける様になったらまた書こうと思います。その日が割と近い日に訪れる事を願って…（笑）

※余談。ちなみにネイティブの事が分からないエンジニアはなんちゃってエンジニアなのか？という話もあると思います。結論から言うと触る領域の事が分かっていないエンジニアはなんちゃってエンジニアである、という事だと思います。ネイティブより上の所にも相当深い議論が必要な領域が存在しており、決してその層のエンジニアだからと言ってレベルが低いとか一概になんちゃってという事もできないと思いますが、ネイティブアプリを作るとなってくるとチート対策やらで割と低レイヤーの事も理解していないと「あれ、どうやるんだっけ」という事になってくる場面も多いです。なので、ネイティブアプリをいじる機会がある以上はネイティブの事が分かっていないと「使えないネイティブエンジニア≒なんちゃってネイティブエンジニア」になり得るので、今の私には必要な知識だと考えています。…あれ、待って？いかなるレイヤーのシステムであっても必ずネイティブ層の上に位置するんだから、どの層をいじっていようがそれを理解していないというのはなんちゃってエンジニアなのではないか？　う…うん。

2014/04/14

【映画】サンブンノイチ

　最近はエンタメというと映画を観る事が多いのですが、割と観るだけで何かアウトプットするとかいう事をしておらずすぐに忘れてしまうので、後に積み上がる様にできるだけエンタメ体験を書き残しておこうかと思います。

　とは言っても私は映画の専門家でもないしツウでもなんでもないので、割と素人視点で感じた事を思いのままに書いていくというスタイルにします。

　で、先日サンブンノイチを観て来たのでちょろっと書いてみます。主に感じた事は下記です。

全体として割と面白かった

吉本興業の芸人が出演しているという事で、演技としては三流な雰囲気なんだろうなぁと思っていたら、意外にそれを感じさせなかった（漫才風な雰囲気がない訳ではないのだが、違和感なく組み込まれている）
物語も単調にならない様に裏切り・騙しの要素が多く織り込まれている

藤原竜也の演技はタイミング（セリフの調子・抑揚含め）が巧妙で、吸い込まれる
窪塚洋介の演技は相変わらず窪塚流なのだが、役とうまくマッチしていい味出してた
品川ヒロシ＝品川祐（品川庄司）が監督をしていたというのは知らなかった。ぶっちゃけそんなに好きな芸人ではないし意外だったが、バランスのよい作品を作るなぁと感心した。
銀行強盗してクズ野郎どもが這い上がる的な調子で描かれていて、「おいおい、でもやってる事は銀行強盗だよ」という感情はきっとどこかにあって、そこも忘れず釘を刺してくるあたり、面白かったし、「続きを観てみたい」という気になった
Pia-no-jaC というグループの音楽が使われていたが、ここも漫才ぽさを緩和してやや上品・洗練された雰囲気にする要素になっていたと思う。そういう所を含めて、バランスがよかった。

という訳で、「面白かった？」と聞かれたら「面白かったよ」と答える映画でした。原作は木下半太という方が書いているらしく、サンブンノイチ以外にもゴブンノイチやナナブンノイチといった作品もあるらしく、そちらにも興味を持ちました。

基本データ

公式サイト

http://www.sanbunnoichi.jp/

Wiki

サンブンノイチ

Pia-no-jaC

2014/01/05

【スーパーまとめ】カンブリア宮殿を飾った経営者たちの金言

　いつのビデオかよく分かりませんが、昔ビデオにとっていたカンブリア宮殿の経営者の金言が面白かったのでスーパーまとめです。必ずしも彼らの言っている事全てが正しいとかそういう事はおそらくない訳ですが、ベースになっている考え方は参考になると思います（やや意訳の部分もあり）。

早く失敗して、早く考えて、早く修正しろ　ファーストリテイリング　柳井正

　新しい事に挑戦していけば失敗して当然。連戦連勝という事はあり得ない。ビジネスは計画通りには絶対行かない。なので、失敗するなら早く失敗し、早期に修正する事が必要である。

ダントツを作るために　負けてもいい所を決めろ　コマツ　坂根正弘

　どこの企業でも、評価→改善→評価→改善のプロセスは経ているだろう。しかし、ややもすると他社に負けている所を改善し、「少し他社よりもいい製品」が出来上がってしまう。それでは差別化にならない。ワークする差別化を行うには、負けてもいい所を定義し、それ以外に注力する事で「ダントツ（＝模倣不可能な差別化要因）」を作り出す事が重要である。

勝算７割で勝負せよ　ソフトバンク　孫正義

　7割以上の勝つ確率がなければ参入しない。5割では博打だし、9割まで待つのでは、競合の参入を許した後になってしまい、後手に回る。日本の大企業の典型である。

2012/07/22

キーボードを買ってみた。

スーパーまとめシリーズもずいぶんとサボってしまっていますね（笑）まぁもともと続くかどうか分からんという感じで始めたので許して下さい（笑）突然ですが今回はキーボードを買ってみたのでその話を…。

　何だか最近仕事中にキーボードが微妙に打ち辛いと感じる事があったのと、仕事場のまわりにはマニアックなキーボードを使ってズギャンズギャンと個性的なタッチをしている人が多いので自分もそろそろキーボードの禁断の世界に踏み入ってみるかという感じたのが購入に至った理由です（理由になってるのか？（笑））。

　結論として、購入したのは Majestouch(Ninja) の茶色キーです。何故これがよかったのかという点については後述します。検討した候補としては、1)HHKB, 2)Realforce, 3)Majestouch(Ninja) がありました。

　HHKB は理由はよく分からないが打ち辛かった（配列が一般的なものと微妙に異なるらしいが、その関係？）。打鍵感はまぁ悪くないなという感じ。

　Realforce はキーの打鍵感がフカフカしすぎていて自分にはちょっと馴染まなかった。しかし、キーの配列に関しては一般的な形になっており、その辺は問題なかった。

　Majestouch はキーの種類が４種類あり、赤、茶、青、黒と、それぞれ味付けが異なるものになっている。自分なりのインプレとしては、赤はフカフカしすぎていて打ちにくい。青はカチカチうるさくて微妙。黒は重すぎて逆に打ち辛い。その中で茶色は適度に軽くて適度に重くてちょうど良かった。なので茶色にした。

　で、密かに気になっているのが Realforce の HHKB の打鍵感（と外観）をパクったバージョンの様なもの。秋葉をウロウロしていたらこれの ~~US 配列~~テンキーバージョンがあって少し打ってみたんだけど、悪くなかった。静電容量無接点方式である分、もしかしたら Majestouch よりもいいのかもしれない。家用に買ってみようかなぁ。

東プレ「Realforce 91UDK-G」　テンキーレス・ALL45g

　Mac で使う時には、下記のソフトをインスコして設定をいじる事である程度 Mac の標準のキーボードと近い感じで使う事ができる。

KeyRemap4MacBook
http://pqrs.org/macosx/keyremap4macbook/document.html.ja

PCKeyboardHack
http://pqrs.org/macosx/keyremap4macbook/extra.html.ja

2011/11/06

ここ数日 Perl を学んで分かった事 #Perl

　最近、会社では Perl を使います。Perl は中学生〜高校生の時にちょろっとやっただけで、しかもその時は独学だったのでものすっごいガラパゴスなコードを書いていました。しかし、仕事で使うとなるとそういう訳にはいかないので今勉強しているのですが、会社でコードを読んでいて「なんじゃこりゃ？？」と思って勉強して分かった事をちょっと書いてみようかと。

　Perl を今さら始める人ってのもかなり奇特だとは思いますが、まぁ何かの役に立てば。

+{ } って？

結論から言えばただの無名ハッシュです。
何故プラスを付けるのかと言えば、それがブロックではなく無名ハッシュなんだと明示するため、ただそれだけです。
逆に、ブロックである事を明示したければ {; hogehoge} の様に、ブレースの中に ; を書きます。

関数呼び出しには & がいるんじゃないの？付いてないやつはなんなの？

関数呼び出しは「基本的には & を付けます」。ただ、それがコンテキスト上関数と分かるもの（例えば、それ以前に既に sub によって関数が定義されている時）に関しては、& を付けなくても動作します。
なんか定義があいまいなので、個人的にはあくまで & を付けた方がいいだろうな、と思ってます。その方が単純に分かりやすい。

リファレンスを参照しているはずなのに、中身が取れてしまう？

矢印記法（->）は、添字的なモノの間に挟まっている場合は省略できます。
添字的なモノとは、[] とか {} だと理解していますが、ちょっと怪しいので間違ってたらごめんなさい。
例えば、$a[0]->[0] は $a[0][0] と書く事もできます。
なので、こちらのコードも動作します。
詳しくは「続・初めてのPerl」など参照の事…。

　Perl Mongers の方からすれば当たり前すぎる事かもしれないんですが、イチから学んでる人にとっては、この辺すら理解不能だったりするのでメモがてら書いてみました。

2011/09/21

How to install MongoDB 2.0 on Mac OS X (>= Leopard)

　Mac 的な作法で MongoDB 2.0 をインストールする方法を gist に上げてみました。…………しかし何か見にくいですね。gist で見た方がいいかもです。gist はこちらです→How to install MongoDB 2.0 on Mac OS X (>= Leopard)

　間違いや作法的におかしい部分などありましたら是非ご指摘頂ければと思います。

2011/09/20

【スーパーまとめ】メソッドのエラー処理を考える　高橋徹

　Java でのエラー処理の方法についてまとめます。出典は、WEB + DB PRESS vol.51 「巧いメソッド設計　第六章　メソッドのエラー処理を考える」です。

【対象】

言語は Java
「契約による設計」を採用した場合の実装方法

【そもそもエラーとは】

A の条件の元、B という処理を行い、C という条件になったとする。
この時、以下のものをエラーとする。

A の条件が不正だった時は、B の呼び出し元のメソッドのバグによるエラー
C の条件が不正だった時は、B のメソッドのバグによるエラー

【エラーの通知方法】

上記の様なエラーは、事前条件（A）チェック、および事後条件チェック（C）により検出ができるが、その通知方法は大まかに下記の３通りである。

戻り値による通知

true/false や int などなどで返す事が考えられるが、メソッド本来の戻り値との切り分けが難しい

例外による通知

B 自体のバグの場合、チェック例外（Exception のサブクラス）にしても呼び出し元が対処できる訳ではないので非チェック例外（RuntimeException のサブクラス）とする
例外に使用するクラスの使用基準があいまいである
非チェック例外の場合、ドキュメントに明記しておかないと例外仕様が不明瞭になってしまう

アサーションによる通知

事前、事後のチェックを行い、エラーがあった場合には assert 文で通知する
記述が若干少なく、楽である
例外の型の問題はなく、コメントを付ければ例外仕様は分かりやすいという点において、例外による通知よりも使いやすい
リリース時にオフにした場合、何も把握できなくなってしまう
パッケージ、クラス単位でアサーションのオン / オフを指定する事ができるので、パフォーマンスが問題になるならそれを利用するという手も

プログラムの出荷時に表明（アサーション）をオフにすることは、綱渡りの練習を一度うまくやり終えただけで本番の綱渡りに挑戦するようなものです。ドラマチックな価値はありますが、生命保険は下りないでしょう。

※まとめ注：要するに出荷時にアサーションを一概にオフにする事はオススメしないと言っている

【事前条件チェックの注意点】

呼び出し側が条件の成立を判定できない条件を事前条件に含めてはならない。例えば、下記の様なものである。

外部からアクセスできない変数の値
処理を開始しないと判定できない事項
そもそもプログラムで判定できない事項

下記の様なものは、「プログラム外部の異常」なので事前条件チェックには含めない

DB と正しく接続できる事
ハードディスクや RAM に十分な空きがある事
ファイルが読み出し可能である事

登録: 投稿 (Atom)