むちゃくちゃ大量のデータを扱えるらしい
機能的には目新しいものはないぽい
3rd party data のプロバイダーが日本だといないよね
2M/Mon yen くらいらしい、高い
プログラミング言語における継承について
Golang には継承がない、という指摘について少し調べたメモ
元ネタ
なぜGo言語 (golang) はよい言語なのか・Goでプログラムを書くべき理由
Goには継承はありません。 そもそも継承はプログラミング言語にあまり必要ない機能だと思います。 継承が本当に有益なこともありますが、経験上大半のケースでは設計を手抜きするために継承が使われていて、結果長い目で見た際のreadabilityやmaintainabilityが著しく劣化してしまっていることが多いと思います。Composition over inheritanceやリスコフの置換原則のような基本的な原則が守られておらず(そもそも多くの人は名前すら知らない)、単に一部のコードをクラス間で共有するために継承が使われていて可読性が著しく低いコードもよく目にします。
そのため、そもそもプログラミング言語が継承をサポートしないというのは非常に良いデザインだなと思います。継承が非常に有益な場合も稀にあるもの分かりますが、大規模プロジェクトにおいては正しく使われない害のほうが確実に大きいです。
Composition over inheritance
継承をもちいた場合の構成、というくらいの意味
Composition over inheritance - Wikipedia
リスコフの置換原則
一般的なやつ
T 型のオブジェクト x に関して真となる属性を q(x) とする。このとき S が T の派生型であれば、 S 型のオブジェクト y について q(y) が真となる。
- オブジェクト x がある
- オブジェクト x の型は T である
- オブジェクト x は 属性 q(x) をもつ
- q(x) の導出は true である
型S が 型T の subtypeであるとき、以下も成り立つ
- オブジェクト y がある
- オブジェクト y の型は S である
- q(y) の導出は true である
Zak Abel - Only When We're Naked
掠れた声がいいね 声に伸びがあるのもナイス
Heroku と Docker と 12 Factor
Heroku が目指した世界観（12 factor app）を実現しようとしているのが Docker なのよね。「なぜDocker がひろまったか？」というのは、技術的なことより、Heroku が Salesforce のものになってしまった故、AWS や Google が 12 factor app インフラなビジネスを自分たちが主導できるように環境を整えた、という政治的な利害関係があると思う。
Docker に触れる前に Heroku にまず触れてみるといいと思う。というか大抵の人は Docker 使うより Heroku を使ってしまったほうが幸せなんじゃないですかね。僕は金ないので個人では Docker 使いまくってますが、所属してる会社には金があるので Heroku を使っている。いずれにせよ、 Heroku に慣れてみると Docker やその周辺に散在する思想によって何が得られるかがはっきりとしてくる。
超同意。
建築設計の記述方法
情報システムというのは多数の人が関わるものであり、適切な情報の伝達というのは常に重要なトピックです。そのなかでも、そのシステムが何を目的として、どう構築されるか、どのような要素で構成されているか、どのように振る舞うか、などの情報の記録先、まぁ設計書と呼ばれるものだけれど、どのようなものが最適なのかというのは常に悩ましいものだと思います。いやまぁ、いわゆるテンプレートは世に数多あるし、それらに沿えば大体のケースでは間に合うんだけど。常により良いものへの改良は考えておきたいと思うのが男の性ではないかと考えています。
ということで、今までにない情報システムの設計記述方法の検討のため、未だ私が知らないアプローチのネタはないかと思って、最近は建築関係の設計書の記述について学んでます。正確にいうと学ぼうとしている。どう学んでいいかわからない。とりあえず書店で、建築関係の書物など立ち読みしたりしてます。パース図？などみてるだけでも楽しい。この建物の目的はなにか？重視すべき事柄はなにか？制約事項はなにか？など割とシステム設計と観点が似通っているように感じます。
とりあえずいまは学び方を模索している段階。続く。
