たれぱんのびぼーろく

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

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)要素を持っている.

プログラミングの依存とうまくやっていく

依存とは

依存 (dependency): 対象の存在を前提とし、対象の変更に影響を受ける状態. couplingとも

依存は悪いものなのか

依存対象を必要とする

対象の存在を前提としている
-> 対象が存在していない(?)とそこへ依存した部分が構築できない
e.g. 利用するデータ保存手法が未定->そこに依存したコードが書けない

変更

対象の変更に影響を受ける
-> 対象の変更が自分の修正を引き起こしうる
-> 依存"されている"場合、変更が他箇所へ影響を与えうる

依存を無くすことは可能か

他要素との相互作用(呼び出し、変更など)を除去すれば可能だが、それは他要素を削除することと同義

無くせないならポイントは

何に、どの方向で、依存するか

自分(のようなもの)に依存する分には構築が始めやすいし、他者に振り回されずに済む
依存するinterfaceを自分で定義すればある程度コントロールできる
依存するinterfaceを自分で定義したら楽なのはそれはそう.
使われる側は自身がimplicit interfaceなので楽.

中心的関心領域が様々なEntityへ"依存している"ことの弊害:

依存対象が存在しないと依存部分の設計ができない
中心的関心領域が肝だから、そこだけに注目してまず設計したい
-> 中心的関心領域側でinterfaceを切り、自ら設定したinterfaceへ依存する

# Interface: 明示され、変更頻度を低くすることが合意された、構造体・命令の形式

依存の良い扱い方
中心的関心領域が自らinterfaceを定義し、それに依存する
ヘキサゴナル・オニオン・クリーン
人間は不完全なので、実装が存在する領域を起点としてそこに依存したアーキテクチャを作ってしまう
e.g. RDBMSがあるので、そのAPIを起点にデータ保存を抽象化し、その後データ保存関数へ入れるデータをモデリングしていく
抽象がどうしてもRDBMSに引っ張られてしまう
DBアクセス速度を売りとした超高速アプリ、みたいな場合、DBアクセスは中心的関心領域なのでは?
DBは主役級、DBはinterfaceを切る側に立つのは合理的

依存関係

Coupling (computer programming) - Wikipedia