読者です 読者をやめる 読者になる 読者になる

ソフトウェアの拡張と劣化

デカルトの『方法序説』に面白いことが書いてあった: たくさんの部品を寄せ集めて作り,いろいろな親方の手を渡ってきた作品は,多くの場合,一人だけで苦労して仕上げた作品ほどの完成度が見られない.たとえばよくあることだが,一人の建築家が請け負って…

ブロックチェーンについての考察

タイトルが雑だが、最近ブロックチェーンについてぼんやり考えていて、その覚書。 元の bitcoin の Proof of Work (PoW) は以下の式を満たすブロックをブロックチェーンにつなげることができる。 hash(prev, tx, nonce) < 1 / difficulty * hash_max (eq.1) …

bitcoin と ビザンチン将軍問題

bitcoin はビザンチン将軍問題を解決したとしばしば言われます。これが厳密には誤りだそうです。私もそんなに詳しくないのだけれども、確かにそうかなと思います。 ビザンチン将軍問題というのは――離れた場所にいる複数の将軍間で作戦の合意をとりたい;ただ…

bitcoin: Proof of Work の肝

bitcoin の仕組みは「ようできてる」と感嘆します。ポイントはデータベースの更新を承認する「Proof of Work」(PoW) という仕組みです。 さて、bitcoin が PoW で上手く回っているのは、PoW の特徴によるものに思います。PoW がなかったどうなるのかというの…

ディレクトリ構造のスキーマ

私はファイルシステムとかブロックストレージとかには少しだけ詳しいと思うが、現実に興味があるのはもう少し上の階層だ。RDB でいうとどのようにスキーマを設計すべきかという階層の話に興味がある。昔に書いた以下の記事でいうと「シンタックス層」が関心…

CAP定理について

CAP定理という分散ストレージシステムの設計において非常に重要な定理がある。まだ、以下の元の論文を読んでいないので、正確な理解かどうかは保証できないが、理解している範囲で考えることを記す。 https://www.comp.nus.edu.sg/~gilbert/pubs/BrewersConj…

寄付と投資

歳をとったのか世のため人のために多少は貢献できないかなと思うようになった。手っ取り早い手段は寄付をすることだ。世の中にはお金で解決できる問題は多い。ただお金を出すだけで世の中のためになるなら楽なものだ。金は命よりも重いが、負担にならない程…

『Who Gets What』

アルビン・E・ロス著『Who Gets What――マッチメイキングとマーケットデザインの新しい経済学』を読んだ。本の内容とは別に考えたことを記す。 Who Gets What (フー・ゲッツ・ホワット) ―マッチメイキングとマーケットデザインの新しい経済学作者: アルビン・…

出版業は市場データで効率化できるはず

Amazonは手に入りにくい本が簡単に手に入るのでよくお世話になっている。特に便利だと思うのは、中古本のマーケットプレイスというシステムだ。欲しい本が予め決定しているときに、Bookoffに行くことはない。非常によく出ている本はBookoffで探せば見つかる…

ソフト開発にも生産技術者が必要

製造業には必ず生産ラインの世話をする役職の人がいる。製造業においては、この役割の人は階級が高くて、会社内ではエリートがする仕事である。昔は社会的にも地位の高い仕事だったのだろう。現在だと聞かないが、かつては製鉄業の現場監督はエリートの仕事…

可読性に関するソフトウェアメトリクスを考えた

新しいソフトウェアメトリクスを思いつきました。 ソフトウェアメトリクスとは、ソフトウェアの特性を推定するための定量値のことです。バグの数とかレビューの時間とか開発の過程で得られる値もありますし、テストの数だとかカバレージといったテストを評価…

トヨタ生産方式とアジャイル開発

トヨタ生産方式には7つのムダというものがあります。それぞれ、以下のようになっています。 作りすぎのムダ 手待ちのムダ 運搬のムダ 加工そのもののムダ 在庫のムダ 動作のムダ 不良を作るムダ トヨタ的な考え方では、製品を加工している作業が唯一付加価…

オブジェクト指向で再利用性が高まるは嘘

オブジェクト指向でプログラムを作れば再利用性が高くなるというのは誤りだったと思う。オブジェクト指向プログラミング(OOP)についての本を呼んでいるとOOPは再利用性が高いというようなことが書いてある。すでに結論が出ている話な気もするが、これは必…

FlyweightパターンとMemoizationとメモリリーク

デザインパターンの1つFlyweightパターンは要するにMemoization (メモ化) のことです。Flyweightパターンというと何のことか良くわからないので、Memoizationパターンと読んだ方が適当なように思います。 メモ化とは、関数が返した値を覚えておいて、再度同…

抽象クラスとは

今日は抽象クラスについて考えてみる。 前々回: クラスとは 前回: インターフェイスとは 抽象クラスとは、必ず継承して使わなければならないクラスのことである。ある抽象クラスAに属していて、Aのサブクラスに属していないようなオブジェクトはいない。 …

インターフェイスとは

前回(クラスとは)はclassとは何かを考えてみたので、今日はinterfaceについて考えてみる。 インターフェイスとは、オブジェクトのに付与される性質の1つである。 クラスとは、同じ性質を持ったオブジェクトを分類 (classification) したものです。同じメソ…

クラスとは

classとはなんぞやと考えている。たどり着いたところまでまとめる。 クラスとは、同じ性質を持ったオブジェクトを分類 (classification) したものである。漢字で書くと類です。同じクラスに属しているオブジェクトは同じような性質を持っている。クラスは、…

リスコフの置換原則は呼び出し側にも責任が伴う

以前にオブジェクト指向になっているならば、あるクラスを継承したクラスは継承元のクラスと置き換えても動かなければならないという気付きについて書きました。名前がついていて、それはリスコフの置換原則と呼ばれるらしいです。 fj.hatenablog.jp このリ…

SQL on HadoopだったらDWHでよくね?

ちょっと前からモヤモヤしていたこと――HiveやPrestoのようなSQLでHadoop上のデータを集計できるというようなものを使うのだったら、昔からあるデータウェアハウス(DWH)でよくないか? データを扱うにはSQLが、なんやかんやで向いているということが再確認…

データにもOSI参照モデルがある

計算機の通信機能(プロトコル)には階層があって、OSI参照モデルだとかDARPAモデルだとかが知られている。有名なものものとして、物理層はイーサネット、ネットワーク・トランスポート層はTCP/IP、アプリケーション層にはHTTPが挙げられる。イーサネットの…

Test Driven DeveopmentとDesign By ContactとAll Pair Testing

Test Driven Deveopment (TDD) とDesign By Contact (DbC)とAll Pair Testingを組みわせたら最強の開発プロセスを実現するテスティングフレームワークが作れるのではないかと思った。だらだらとまとまりなく書きます。 TDDは仕様を決定したら、先にテストを…

碁と統計

fj.hatenablog.jp ニューラルネットワークである局面を入力したら終局図が出力できるようなものを作れるはずだと考えていたが、よくよく考えると別にニューラルネットワークでなくてもよいかもしれない。 碁と統計が相性が良さそうだという事実はモンテカル…

ニューラルネットワークと囲碁

結構前にニューラルネットワークを碁の思考エンジンに使えるのではないかとほんの少しだけ試みてみた。その時は特に成果もなく終わったが、同じように考えている人はいて、科学は進んでいる。 以下の論文は、深層畳み込みニューラルネットワークとモンテカル…

継承はメソッドを使いまわすためにあるのでない

まだまだオブジェクト指向を極めたわけではないのですが、最近気になったこと。 オブジェクト指向の継承はメソッドを使いまわすためにあるのではないということです。 Fooというクラスがあって、BarというクラスがFooを継承(inherit)しているとする。つまり…

ブロックチェーンとクラウド事業

今更、bitcoinについて評価し始めました。bitcoinの価格がちょうど最高の頃に興味持っていたのですが、実益がないので放ったらかしになっていました。 しかし、bitcoin自体は忘れ去られつつありますが、ブロックチェーン技術について最近耳にするようになり…

組織のトップダウン・ボトムアップと動的計画法

組織あり方としてトップダウンというものとボトムアップというものがあります。全知全能の神がいるならトップダウンで上手くいくと思います。 しかし、下に降りてくると現実と合わないことが明らかになったり、降りてくる間に現実が変わっていたりします。こ…

Visual Studio Codeがオープンソース化

最近使っているテキストエディタVisual Studio Code (VSCode) がOSS化されまして、注目しています。 Linux is a cancer とかつては公言したMicrosoftが今やOSSを積極的に公開する時代です。 このように企業がOSSを公開するのがトレンドになっていますが、な…

ステップあたりのバグ数の確率分布

1Kステップあたりx個のバグが検出されるべきという基準があって、それを元に品質管理をするという手法があります。これ自体は古いやり方だなとは思いますが、否定することもできません。 多分何かを仮定して品質というのを見積もろうとしているのでしょうが…

単純バグなんて解決済みの問題だ

前回言及したような if (value = expected) と間違って書いてしまう類のバグがある。設計ミスとか勘違いとか調査不足とかでなくて、単純に書き間違えたことによるバグである。こういうのを単純バグと呼ぶならば、単純バグなんてもう世の中では解決済みの問題…

期待値は左か右か

つまらない論争なんですが、値を比較をするするときに期待値を演算子の左と右のどちらに置くべきなのでしょう。つまり、 if (value == expected) と書くべきか、 if (expected == value) と書くべきかという問題です。 私は前者にすべきと考えています。 も…

開発プロジェクト統合環境が必要

散々ぼやいているが、ITこそITで効率化するべきだと思っていて、現在その道具が揃いつつある:GitHub、JIRA、Jenkins、Maven、XUnit、Chef、etc。先進的な組織はこういうのをどんどん取り込んでいって、気持よく働ける環境を作り出している。 しかしながら、…

なぜRedHatだけ成功しているのか?

以前、サポートはOSSを商売にするには一般的な方法だと書きました。 オープンソースの弱点(4)サポート - 超ウィザード級ハッカーのたのしみ しかし、OSSのサポートをするというビジネスモデルで大成功している企業はRedHatぐらいではないでしょうか。RedH…

COBOLは悪くない

COBOL排除の動きが進んでいるそうで…… itpro.nikkeibp.co.jp 私はCOBOL触ったことないですし、COBOLerの実態もよく知らないし、そもそもSEではないので、以降完全に推測で書きます。 私は別にCOBOL言語自体は悪くないと思っている。確かに古いので、新しい言…

プログラミング言語の選択

プログラミング言語の選択は、ソフトウェアの価値を決定する大きな要素の一つだと思っている。言語はソフトウェアが依存する規格の中で最も大きい物だからだ。規格の重要性については、 OSSとは標準規格である(1)――ソフトウェア規格の奪い合い - 超ウィザ…

AWS Lambda

クラウドのデファクトスタンダードAWSに「Lambda」というサービスが出ています。これはすごいです。何がすごいのかというと、Lambdaは計算機の抽象化の新しい形態と思われるからだ。 Lambdaは何をしてくれるのかというと、データが投げられるイベントを検知…

開発プロセスの目指すべきところ

プロジェクト・マネジャーをしているわけでもないのに、開発プロセスについて誰よりも考えていると思います。残念ながら私の考えを試してみて実証する機会がないので、私の考えが正しいかは分かりません。しかし、実績ができたら開発プロセスの指南だけで十…

オープンソースの弱点(4)サポート

OSSが弱そうなところについて書いています。 日本語 GUI 運用 サポート のうち今回はサポートについて。 サポート OSSで商売をするとしたら最も一般的な方法はサポートだ。*1したがって、弱そうなところというのはウソです。サポートを考えると安価であると…

オープンソースの弱点(3)運用

OSSが弱そうなところについて書いています。 日本語 GUI 運用 サポート のうち今回は運用について。 運用 運用はオープンソースに関わらずソフトウェアにとっての鬼門だ。開発するのと運用するのとの間には大きな断絶がある。左から右に流れるウォーターフォ…

ソースコードの著作権表示

いつごろからある慣例なのかは知らないが、ソースコードのファイルの先頭は必ず著作権についてのコメントが入れられている。おそらくフリーソフトウェア運動が始まった頃からだと思う。ソースコードの著作権がなかったら、表記なんてできないし、ソースコー…

オープンソースの弱点(2)GUI

OSSが弱そうなところについて書いています。 日本語 GUI 運用 サポート のうち今回はGUIについて。 GUI 一般にOSSのGUIはあまり使いやすくないと思う。GNOMEも何が悪いのかは分からないが、なんか使いにくい。UbuntuのUnityもなんか使いにくい。 コミュニテ…

オープンソースの弱点(1)日本語

今やオープンソース・ソフトウェア(OSS)を無視して計算機は語れない。OSSを制するものが業界を制する状態だ。 ソフトウェアを作って売るという商売をしているとどうしてもOSSと比べて競争しようとしてしまう。縄張りに侵入してきている外敵に見えるのだ。…

大きいコードを書くには

前回、コードに垂直方向のスケーラビリティ――コード規模のスケーラビリティについての式を考えた。 Nがコードの規模、Wがそのコードを作る労力であり、wが単位規模のコードを作る労力、rがコードを加える際に既存のコードを調べたり・改造したりする割合を示…

コード規模のスケーラビリティ

前回、ソフトウェアの開発には水平方向・垂直方向のスケーラビリティがあると軽く触れた。水平方向のスケーラビリティとは人を増やせばそれだけ開発能力が向上するということで、垂直方向のスケーラビリティとはソフトウェアの規模が大きくなっても開発速度…

ソフトウェア開発のスケーラビリティ

人月あたりの生産量、1kステップあたりのバグ数みたいな指標は便利なのでよく用いられる。私も、 プログラマの生産性の公式 - 超ウィザード級ハッカーのたのしみ で単位時間あたりの動くコードの生産量といった数をおいた。単に数値を数値で割っているだけ…

ビルドツールに関数型プログラミングが向いている

世の中にビルドツールは数あれどどれも気に食わない。いっそのこと自分で作っちまおうかとすら思い、ビルドツールに必要な機能を考えている。 ビルドツールは手続きを書くのが主流だが、関数型プログラミングを意識して作った方が上手く作れるのではないか。…

プログラマの生産性の公式

n行の動くコードをコーディングするのにかかる時間をTとすると、Tはざっくり以下のようになるだろう。 T = n*(tc + tw) + n*b^2*(tc + tw + tb) + n*b^3*(tc + tw + tb) + ... = n*(tc + tw + tb) / (1 - b) - n * tb ここにtcはバグの有無を問わず1行のコ…

読まないドキュメントより読めるコード

ウォータフォール開発はとにかく仕様書を書くことが求められる。文章を書くこと自体は嫌いでないが、仕様書を書くことは嫌いだ。なぜなら、意味がないからだ。その仕様書を他の人が読んで意思決定が行われたり、その仕様書をもとに他の人が開発をするなら、…

機械が使うものか人間が使うものか

機械には 人間が使う機械 機械が使う機械 の2種類がある。 人間が使う機械とは、UI(ユーザーインターフェース)を持っている機械のことだ。従来道具と言われてきたものは、人間が使う機械である。自動車もスマートフォンもそうだ。 システムとして見た場合…

ITこそITで効率化せよ

情報通信技術(IT)の主な用途は既存の業務の効率化である。計算機は決まった作業を正確にするのに優れている。帳簿をつけたり、そろばんを弾いたり、書類を回送したりする作業は人間がするよりも機械がおこなった方が効率がよい。そのため、計算機はこれらの…

ブログの文章は1500字

ブログの記事にするのに調度良い長さというのはどれぐらいなのだろうか。 一般に文章は短くなっている傾向だ。比較的活字に親しんでいる年齢層が使う掲示板もコメントは3行以内だ。ほとんどの場合は1行である。ニコニコ動画のコメントは単語のみで、文にな…