たれぱんのびぼーろく

わたしの備忘録、生物学とプログラミングが多いかも

ソフトウェアやサービスの何が重要なのか

ソフトウェア、サービス: ユーザーに使われるもの
ユーザーに価値を提供するもの

価値そのものを生む場所、価値を生むことを実現する技術
スーパー黒子

DDDにおけるドメイン: 価値の源泉

ソフトウェア/サービスと金の延べ棒の違い

利用に価値があるのか、存在に価値があるのか
道具なのか、資産なのか

金は存在自体に価値がある。金の延べ棒を貰ったらとても嬉しいけど、金は食べれもしないし明日の天気を教えてくれもしない。金は利用して価値を生むものではなく、存在自体が(交換可能な)価値をもつ類の存在である。要は資産。

一般に、ソフトウェアやサービスは資産(動産)、すなわちその存在そのものが交換可能な価値をもっている存在ではない。
ソフトウェアやサービスは、使って価値を生む道具である。
だから生み出す価値が全て。ソフトウェアやサービスの存在/所有自体に対する価値は小さい。
利用者が生み出す価値が全て。利用者に提供できる価値が全て。
ソフトウェアの価値は、ユーザーに提供できる価値で決まる。

ToDoリストサービスは、やるべきことリストの書き留めと引き出しという価値を提供する。
DBアクセス権を売ってるわけではない。DBを無くすことができるかどうかは価値に直結しない。

開発手法

価値を生む仕組みが完璧に構築できるのなら、それに従ったソフトウェアを書けば完全なソフトウェアができる (価値を生むことが約束された仕組みを実装したのだから)
現実には、人間は不完全。価値を生む仕組み(ビジネスモデル)を完全に予見できる人間なんかいない。
不完全な価値産生仮説に基づいてソフトウェアを書き、仮説を検証・修正し、それに合わせてソフトウェアを改修する。
この方が合理的。
この方法を取るためには、ソフトウェアの柔軟な改修を可能にする必要がある。
また、仮説の考察にソフトウェア側から貢献できればなおよい。

kuranuki.sonicgarden.jp

ソフトウェアが占める、ユーザーの価値産生における重要度、もポイント。
ソフトウェアの重要度が上がれば上がるほど、開発手法を合理化する意味が大きくなる。

Dual-Interface & Adapter (Dual-IA)

Dual-Interface & Adapter

良い分離面設計をするために、各coreがownershipもってinterfaceを定義する. interface間をadapterでつなぐ.

どう分割面を設計するか、の指針 (何に基づいて分割するか、は扱わない.)
domain - interface <= adapter => 外部API
と同じ感じで、coreを自分で定義したのちに必要なinterfaceを自分で定義.

アーキテクチャとは

アーキテクチャとは

architecture

fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution

システムの根源的な概念/特性

  • 要素
  • 関係性
  • 設計/進展を支配する原理

として体現される

www.iso-architecture.org

アーキテクチャに含まれる要素:
どう区切るか (インターフェースを切るか)、パーツ同士をどう(依存させながら)組み合わせるか

アーキテクチャは戦術論 (神がカオス神柔軟性ソフトを作ったら、目的は達成される)

コードフォーマットに関する考え方

前提: 「完全なる唯一の正解」は存在しない
各フォーマットはメリット・デメリットがあるし、その程度はユーザー・環境に依存する

ポイント: 統一感のなさが問題を引き起こす

  • 不慣れなフォーマットでひっかかる
    • ひっかかること自体がリソースを食う
    • ひっかからないように無意識に気にしながらコードを書く
  • フォーマット修正がdiffを生む

存在しない正解を追い求めてコストを払うのは終わり。何かに従って統一感を得よう
JSならprettierに従う
prettierに文句をつけるのは、存在しない正解を追い求めるのと一緒
決着の存在しない議論をする暇があったらコード書け

コードの実体と表示が同じ限り、フォーマット戦争は起きてしまう
統一formatterに隷従するか、コードviewと実体の分離を実現するかしかない
実体を分離するにせよ、実体の統一フォーマットはいるのでformatterは大事

inside.pixiv.blog

脂肪肝の基礎情報と医学的根拠

脂肪肝: 肝細胞に脂肪が蓄積した状態・疾患

肝臓に脂肪分が沈着した脂肪肝
link

肝臓の細胞の中に脂肪が溜まっている状態
link

  • アルコール性肝疾患(Alcoholic Liver Disease, ALD)
  • 非アルコール性脂肪性肝疾患(nonalcoholic fatty liver disease, NAFLD): アルコールでもウイルスでも薬でもない脂肪性肝疾患
    • 非アルコール性脂肪肝 (nonalcoholic fatty liver, NAFL): NAFLDのうちNASHには至らない脂肪肝
    • 非アルコール性脂肪肝炎(NASH): 炎症による線維化が発生、肝硬変へ悪化する可能性あり

NAFLDのうちNASHが10~20%程度。肝硬変10年進行率が20%程度.
NASH->肝硬変->肝癌
20代のNAFLD有病率はおよそ15% link先グラフ

アルコールが原因でない脂肪肝の人の中で実に10~20%がこのNASHになり、更にNASHのうち5~20%が5 ~10年の間に肝硬変まで進むとされています。
link

脂肪肝の診断

男性ではウエストが85センチ以上、女性は95センチ以上の場合、脂肪肝を持っている人が半数以上となります。
link

NAFLDの治療

NAFLDの治療法は生活習慣改善以外確立されていない。

何かいい薬物療法はないでしょうか?残念ながら、現状ではあまりいいものはありません。
link

肥満の場合は減量が第一。7%減量を第一目標。2kg/monthが一つの指標。

体重の7%を目標に減量し、徐々に標準体重を目指すことが進められます
日本消化器病学会 (2016) 患者さんとご家族のための NAFLD/NASH ガイド

月に2kgを越えない程度の減量が適切
...
発症機序からは、脂肪肝の段階で食事や運動で生活習慣を改善し、肥満、糖尿病、高脂血症、高血圧を是正することが重要です。
link

NAFLD組織像

www.kanen.ncgm.go.jp

CycleGAN-VC2

CycleGAN-VCの改良版。
Discriminatorの追加、2D-1D-2D Conv Generator、Patch Discriminatorが変更点。

情報

論文:
デモ:
コード:

詳細

背景

RBMやVAEじゃない理由: over-smoothing through statistical averaging
統計モデル(生成モデル。確率分布を考えるもの)の一般的問題

改良点

  • objective (two-step adversarial losses): G(G(source))に対するDを新たに用意
  • generator (2-1-2D CNN)
  • discriminator (PatchGAN)

実験

データセット

検証データセット: VCC2018 spoke (SF3, SM3, TF1, TM1, 81:35=train:eval, S&M is non-parallel)

preprocessing

down to 22.05 kHz
wave to (34MCEPs, logFo, APs) per 5msec with WORLD
MCEP normalization: μ=0, σ=1 on Source|Target trainings
Random clop 128 frames

conversion

MCEPs変換
inter-gender: Vocoder-based (WORLD synth)
LogFo: logarithm Gaussian normalized transform
APs: no conversion

intra-gender: Vocoder-free (DIFFVC)

Network & Training 詳細

基本はCycleGAN-VCと一緒。
LadvはLeast Square
Adam, β1=0.5
Nbatch = 1
Niteration = 2 * 105
LR: G/0.0002, D/0.0001
Lidは最初の104iterationのみ
λcycle=10, λId=5

評価

客観評価指標

  • global structures: Mel-cepstral distortion
  • local structures: modulation spectra distance

主観評価

  • naturalness: MOS
  • similarity: XAB (reference -> baseline | proposed -> the other, then A|B|fair)

読破状況

4: conversion processのところ、わからない点複数
5: 終わり

インターフェースを記述する

TypeScript

Function Types
interfaceにより関数型を定義できる

interface SearchFunc {
    (source: string, subString: string): boolean;
}

IDL

インターフェース記述/定義言語
Interface Description/Definition Language

OpenAPI Specification (OAS) はIDLの一種といえる.

いまどきのwebAPI/RPC

IDLを書いてclient/server、documentを自動生成。
OAS+Swagger/OAGen, gRPC with Protobufsなどが有名どころ.
GraphQLもIDL要素を持っていて、あれはさらにバックエンド問い合わせ(Query language)要素を持っている.