bitcoin と ビザンチン将軍問題 - 超ウィザード級ハッカーのたのしみ
bitcoin はビザンチン将軍問題を解決したとしばしば言われます。これが厳密には誤りだそうです。私もそんなに詳しくないのだけれども、確かにそうかなと思います。 ビザンチン将軍問題というのは――離れた場所にいる複数の将軍間で作戦の合意をとりたい；ただし将軍の中に裏切り者がいたり、伝令が失踪したり遅れたりする可能性がある――という問題です。 bitcoin がこれを解決したと言われるのは、悪意のある参加者が過半数以下の場合は帳簿が改竄できないようになっていて、参加者が帳簿を共有しているので、bitcoin では帳簿の内容について合意がとれているように見えるからでしょう。 しかし、上でいう「合意」というのは「分散システムにおける合意」（以下 consensus とする）とは全く別物です。例えば、bitcoin には最も長いブロックチェーンを参加者がみんな知っている、つまり consensus
bitcoin: Proof of Work の肝 - 超ウィザード級ハッカーのたのしみ
bitcoin の仕組みは「ようできてる」と感嘆します。ポイントはデータベースの更新を承認する「Proof of Work」(PoW) という仕組みです。 さて、bitcoin が PoW で上手く回っているのは、PoW の特徴によるものに思います。PoW がなかったどうなるのかというのを仮定してみて、PoW の意義について考えてみる。同期とかの用語は厳密な意味は分からずに使っています。 PoW とは、bitcoin クラスタに投げられたトランザクションをいくつかまとめて承認して、トランザクションログに追記することです。トランザクションログは、トランザクションの塊（ブロック）がチェーン上につながっているので、ブロックチェーンと呼ばれます。ブロックチェーンに追記できるブロックは特定の条件を満たす必要があり、その条件を満たすブロックを見つける作業は CPU コストがかかります。PoW の CP
CAP定理について - 超ウィザード級ハッカーのたのしみ
CAP定理という分散ストレージシステムの設計において非常に重要な定理がある。まだ、以下の元の論文を読んでいないので、正確な理解かどうかは保証できないが、理解している範囲で考えることを記す。 https://www.comp.nus.edu.sg/~gilbert/pubs/BrewersConjecture-SigAct.pdf CAP定理によると、分散システムでは以下の３つを同時に満たすことはできない： Consistency 一貫性、 Availability 可用性、 Partition tolerance 分断耐性。 それぞれ、 all nodes see the same data at the same time, every request receives a response about whether it succeeded or failed, the system
TT-Runner: テストスクリプトのディレクトリ構造フレームワーク - 超ウィザード級ハッカーのたのしみ
以前書いたテストツールがある程度できたので、公開する。TT-Runner と名付ける。 GitHub - fjkz/ttap: A Test Scripts Runner 結合テスト以降のユニットテストフレームワークがうまいこと使えなくて、スクリプトをだらだらと書いているような場合を想定したツールです。テストスクリプトの中身はシステムによって大きく異なるので、ディレクトリ構造の方を規定してしまおうという考えです。 以下のような、テストスクリプト群があったとする。 sample/test-before-after ├── after1.sh ├── after2.sh ├── before1.sh ├── before2.sh ├── test1.sh └── test2.sh これを実行すると、JUnit風に実行してくれるという、単純なツールです。 $ ./bin/tt-runner.py
構造化されたテストスクリプト群の実行ツール - 超ウィザード級ハッカーのたのしみ
テストコードってどんどん増えていく。だらだらスクリプトを書くのは簡単だが、すぐに収拾が付かなくなり、経済的に耐えられないレベルで混乱してくる。何のテストをしているのかももちろんわからないが、動かし方も分からないし、どうなったらpassなのかも分からないような、テストスイートが乱立して、もう全部すてればと思ってしまうほどになる。 テストの自動化を整備するなら、アーキテクチャが必要だ。ユニットテストは、JUnitやSpockやBatsなどの便利なフレームワークがあるので、散らかりっぷりが抑えられる。フレームワークの良さは、それに従えば勝手に整理されるということだ。 システムテストになってくると、システムによってテストも大きく異なってくるので、テスティングフレームワークと呼べるほどに親切なフレームワークを作るのは難しい。だが、既存のテスティングフレームワークの思想は参考にできることが多い： テス
テスト駆動開発で品質が上がる証拠 - 超ウィザード級ハッカーのたのしみ
テスト駆動開発（TDD)で品質が上がる証拠を得た。 Realizing quality improvement through test driven development: result and experiences of four industrial teams*1 性質が異なる４つの製品の開発プロジェクトで TDD を行って、TDD でない類似の開発プロジェクトとの比較をした。４つのプロジェクトはデバイスドライバ・OS・Webアプリケーション・PCアプリケーションと全く異なる種類のものである。 欠陥密度は40%から90%減少し、一方で実装時間は15%から35%増加するという結果が得られた。データだけ見ると、TDDの導入は投資としてはお得だと言える。 *1:http://link.springer.com/article/10.1007%2Fs10664-008-9062-z h
可読性に関するソフトウェアメトリクスを考えた - 超ウィザード級ハッカーのたのしみ
新しいソフトウェアメトリクスを思いつきました。 ソフトウェアメトリクスとは、ソフトウェアの特性を推定するための定量値のことです。バグの数とかレビューの時間とか開発の過程で得られる値もありますし、テストの数だとかカバレージといったテストを評価する値もあります。ソースコード自体から測定されるものとしては、LOC (Line Of Code)やCyclomatic Complexityがよく知られています。それぞれ、ソースコードの規模・複雑さを示すものです。*1 近年では、ソフトウェアの特性としてソースコードの可読性が重要視されるようになっています。ソースコードは書く時間よりも読まれる時間の方が長い。読むための労力が少ないソースコードは、生産性を向上させ、バグも少なくなります。 可読性を高めるためには、適切な名付けやコメント、明快な処理のフローが必要です。名付けやコメントについては、数値化するこ
抽象クラスとは - 超ウィザード級ハッカーのたのしみ
今日は抽象クラスについて考えてみる。 前々回： クラスとは 前回： インターフェイスとは 抽象クラスとは、必ず継承して使わなければならないクラスのことである。ある抽象クラスAに属していて、Aのサブクラスに属していないようなオブジェクトはいない。 定義としてはただこれだけなのだが、一体何に使うのだろうか。 １つは置換可能性を保証するためである。リスコフの置換原則では、サブクラスはスーパークラスと置換可能でなければならないとする。 しかし、スーパークラスのメソッドをオーバーライドしたときに置換可能性を満たせるのか。既に実装が存在して、その振る舞いを変えずに新しい実装に置き換えるなんてことは難しい。振る舞いを記述したものが実装だからだ。普通は実装を変えたら振る舞いも変わる。オーバライドする人は気を使わなければならない。 ならば、オーバーライドされることが分かっているメソッドは空で実装なんてなけれ
単体テストの数とコードの行数の関係 - 超ウィザード級ハッカーのたのしみ
興味深い記事を見つけた。 Cyclomatic Complexity and Lines of Code: Empirical Evidence of a Stable Linear Relationship http://dx.doi.org/10.4236/jsea.2009.23020 コードの行数(LOC)と循環的複雑度には強い相関があるとのことだ。 循環的複雑度とは、プログラム内のif, for, whileといった制御構文の数に１を足した数である。つまり、プログラム内の分岐の数を示している。分岐の多いプログラムは複雑度が高く、分岐の少ないプログラムは複雑度が低い。サブルーチンの循環的複雑度は10ぐらいにしておくのが、最も障害が少ないとのことだ。*1 また、循環的複雑度はプログラム内の分岐の数であるので、C1カバレージを100%にするテストの数と一致している。したがって、単体テス
クラスとは - 超ウィザード級ハッカーのたのしみ
classとはなんぞやと考えている。たどり着いたところまでまとめる。 クラスとは、同じ性質を持ったオブジェクトを分類 (classification) したものである。漢字で書くと類です。同じクラスに属しているオブジェクトは同じような性質を持っている。クラスは、その要素 (element, 元という) が共通して持つ性質によって定義される。名前が付いているというのも大事なところだ。*1正しいソースコードであれば、クラスには属するオブジェクトの共通した性質を代表した名称がついている。 オブジェクトの性質とはなんだろう。それはメソッドだ。性質というのは、外から観察できるもののことだ。オブジェクトはメソッドによって外部とやりとりする。したがって、同じメソッドを持っていて、そこから外部に出力されるものが似ているオブジェクトは共通した性質を持っていると言え、それらは同じクラスに属していることとなる。
BashでStrategyパターン - 超ウィザード級ハッカーのたのしみ
デザインパターンはオブジェクト指向言語だけのものではない。シェルスクリプトにもデザインパターンの概念は適用可能です。 Strategyパターンとは、アルゴリズムを動的に付け替えることができるデザインパターンです。 この概念は決してオブジェクト指向だけのものではありません。Cでもコールバック関数という形で実現することができます。 シェルスクリプトであっても、処理を動的に付け替えるコマンドを作ることができます。例えば、 exec nohup chroot time strace などのコマンドは引数に指定されたコマンドで動きが変わります。Strategyパターンと同じ発想と言えると思います。 こういうコマンドを引数に取るようなコマンドを作ると便利なことが多い。例えば、前処理と後処理を共通化したいときに有効かと思われる。 以下は例。 function do_between_before_afte
Martinのオブジェクト指向設計メトリクス - 超ウィザード級ハッカーのたのしみ
コードの品質のスカウターをどうにか作れないかと考えていて、ソフトウェアメトリクスについて調べている。 古い記事ですが、読んだのでメモ書きする。 Robert Martin, OO Design Quality Metrics. An Analysis of Dependencies https://linux.ime.usp.br/~joaomm/mac499/arquivos/referencias/oodmetrics.pdf Instability パッケージ*1の不安定性 (Instability) I は I = Ce / (Ca + Ce) で定義される。ここで、Ca は被依存数 (Afferent Couplings) でパッケージ内のクラス*2に依存しているパッケージ外のクラスの数である。また、Ce は依存数 (Efferent Couplings) でパッケージ内のクラス
ユニットテストの綺麗な書き方 - 超ウィザード級ハッカーのたのしみ
テストばっかり書いている。テストコードなんかの綺麗さを追求しても仕方ないかなと思っていたのだけれど、適当に書いていると重複が多くて大変で、シンプルに楽に書くコツみたいなのを掴んできたのでメモしておく。JUnitを対象にする。 テストクラスの単位 ユニットテストは機能要件をテストするものだ。非機能要件（性能、保守性、etc）などはテストできない。ユニットテストを書けるようなコードは保守性も上がるし、テストがあるコードは壊せないのでチューニングもしやすいというのは事実だろうが、これらをユニットテストで確認することはできない。 機能をテストするのだから、JUnitのクラスは機能（function)ごとに分けるのが自然だ。基本的にはクラス・メソッドごとになるかと思う。普通は機能ごとにクラスがあって、そのサブ機能がメソッドになっているものでしょう。したがって、クラスとそのテストのクラスは１対多にする
Test Driven DeveopmentとDesign By ContactとAll Pair Testing - 超ウィザード級ハッカーのたのしみ
Test Driven Deveopment (TDD) とDesign By Contact (DbC)とAll Pair Testingを組みわせたら最強の開発プロセスを実現するテスティングフレームワークが作れるのではないかと思った。だらだらとまとまりなく書きます。 TDDは仕様を決定したら、先にテストを書き、テストが通るようにコードを書く。テストが不合格ならテストが間違っているかコードが間違っている。だから、どちらかを直せばよい。テストが通れば両方が正しい。両方が間違っている場合もありうるが、正解は１個だが間違いは多様なので両方を同じように間違えることは無視していいほど小さい。仮に両方を同じように間違えるときは仕様を誤解していたときだけで、それは人間のバグで手が滑ってコードを書き間違えたようなケースとは別の問題となる。少なくともサブルーチンレベルでは単純な間違いをなくせる非常に有効な
Batsというテストツールが便利だった - 超ウィザード級ハッカーのたのしみ
Batsというテストツールをしばしば見るので、使ってみたら便利だった。 github.com シェルのコマンドのテストに使います。テストコードは、ほとんどBashのDSLで書かれます。テストケースは以下のように書きます。 @test "echo hello" { out=$(echo hello) [ "$out" = "hello" ] } ""内がテスト名で、[]で結果を比較する。 $ bats hello.bats ✓ echo hello 1 test, 0 failures TAP (Test Anything Protocol)で結果を出力することもできる。 $ bats hello.bats --tap 1..1 ok 1 echo hello テストコードって乱立しがちだから、結果のフォーマットぐらいは揃えたい。その一つがTAPで、これで出力すればJenkinsとも連携した
Jupyterはデータとか数式いじる人には最強のツールかもしれない - 超ウィザード級ハッカーのたのしみ
「Jupyter」という主にPythonのためのWebベースのシェルに感動した。 インストールと起動 Ubuntu14.04なら、 $ sudo apt-get install build-essential python3-dev $ sudo pip3 install jupyter でインストールできるはずです。 $ jupyter notebook と打つとブラウザが開きます。 Pythonパッケージが足りなくて起動できないときは、 $ sudo pip3 install で適宜追加します。 Notebook 右上のNewボタン → Python3で「Notebook」というシェルが開きます。 %matplotlib inline と入力してShift + Enterを押すとmatplotlibのグラフがブラウザ上に表示されるようになります。こんな感じ SympyというMathem
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ubuntuでブートプロセスを表示 - 超ウィザード級ハッカーのたのしみ