「ダイエットや飲酒後にラーメンや炭水化物食べたくなるの、お腹空いてるじゃなくて、単純に身体が塩分と油分を欲っしてるだけだよね」「塩舐めりゃいんじゃね」「油舐めればいんじゃね」「鞄から塩の小瓶を取り出して舐める」「コンビニで売ってるちっちゃいオリーブオイルの小瓶を取り出して、舐める」「むしろ、ちっちゃいマヨネーズを取り出して吸うと塩分と油分を同時に摂取できるのでは」など、侃侃諤諤の議論が起こった。いずれも、実際にやってたら、完全に終わってる人っぽく見えるだろう。しかし、いつの時代もイノベーションは奇異に映るのだ。実践してみてくれるひと募集！俺はやらない！
Salesforce DMP
むちゃくちゃ大量のデータを扱えるらしい
機能的には目新しいものはないぽい
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 やその周辺に散在する思想によって何が得られるかがはっきりとしてくる。
超同意。
