"腸に効く"アイスは可能か?(細菌の定着の観点から)
以前とある事情から少し調査した内容(と一部私見)。
- 胃腸の温度を冷やすと、消化機能が低下するらしい。もしかしたら"腸内バリア機能"も?(要出典)
- -> 細菌が定着しやすくなる可能性はある?
- Ericsson, A., Personett, A., Turner, G., Dorfmeyer, R. & Franklin, C. Variable Colonization after Reciprocal Fecal Microbiota Transfer between Mice with Low and High Richness Microbiota. Frontiers Microbiol 8, (2017).
- FMTにおいてfrozen sampleはfresh fecesと同様の効果があった
- frozenの方が良いわけではない
- FMTはそもそも最初に抗生物質で元々いる細菌叢を崩してから行うので、単なる細菌の経口摂取で効果があるかは不明
- frozenだとサンプル調整が楽らしい
- FMTにおいてfrozen sampleはfresh fecesと同様の効果があった
- David, L. et al. Diet rapidly and reproducibly alters the human gut microbiome. Nature 505, 559–563 (2014).
- 食事由来の細菌は長期的には細菌叢の変化をもたらさないが、当日などの短期的には遺伝子発現を含めて変化させる
- 腸内で増えることは増えるが、どうやって定着させるかが結局は問題
- 食事由来の細菌は長期的には細菌叢の変化をもたらさないが、当日などの短期的には遺伝子発現を含めて変化させる
- Donaldson, G., Lee, S. & Mazmanian, S. Gut biogeography of the bacterial microbiota. Nat Rev Microbiol 14, 20–32 (2016).
- Anselmo, A., McHugh, K., Webster, J., Langer, R. & Jaklenec, A. Layer‐by‐Layer Encapsulation of Probiotics for Delivery to the Microbiome. Adv Mater 28, 9486–9490 (2016).
- 多糖類のカプセルで細菌を包むと腸に届くまでに死ににくい
- そりゃそうだ
- 1時間後の増殖率しか見ていないので、定着は無理だったか
- 多糖類のカプセルで細菌を包むと腸に届くまでに死ににくい
- Chassaing, B. et al. Dietary emulsifiers impact the mouse gut microbiota promoting colitis and metabolic syndrome. Nature 519, 92–96 (2015).
- 乳化剤が炎症を起こす
- アイスにも入っていることが多い
- 乳化剤が炎症を起こす
- Roberfroid, M. Prebiotics: the concept revisited. The Journal of nutrition (2007).
- prebiotics = (腸内の)細菌の増殖を促進させるもの
- トランスガラクト−オリゴ糖やイヌリン
- Sanders, M. & Marco, M. Food Formats for Effective Delivery of Probiotics. Food Sci Technology 1, 65–85 (2010).
- prebiotics + probioticsが効果を促進する
- Lourens-Hattingh, A. & Viljoen, B. Yogurt as probiotic carrier food. Int Dairy J 11, 1–17 (2001).
- ヨーグルトだと酸に耐性のない菌は入れにくい
- Bifidobacteriumの増殖には37度が最適
- アイスだと当然だが真逆
Bear: Markdownエディタ
Bearとかいう素晴らしいものを見つけてしまった。
Kobitoと比較した場合、個人的に特筆すべき点は、
- UIがきれい
- Markdownを書いたそばから解釈して修飾してくれる
- メモ一覧にピン機能がある
- メモのリンクが可能
- チェックボックスを書ける
- PDFその他ファイルを埋め込める、さらにAcrobatで開けるのでハイライト・コメント編集も可能
- (Pro版だと)PDFにエクスポートできる(未確認)
すごい。ただ、現時点では以下のような至らない点もいくつかある。
- 数式、表の入力ができない(LaTaXiTでPNGに出力してそれを貼り付けることはできる)
- バックアップをどうするかまだよく分からない
- Pro版は有料
数式と表は使いたいので少し痛いが、それを補っても余りあるほどのメリットがBearにはある。
すでにいくつかのメモをKobitoから以降したが、今後機能が順調に充実していけばおそらくBearに完全以降するだろう(このブログも怪しいと一瞬思ったが、短いメモや利用頻度の低いメモが一覧を圧迫するのが嫌いなので、そういったものや、今回のような一過性のメモについては今後もこちらに書くことになるだろう)。
あと余談だが、Bearはググラビリティが低すぎる。。。ググラビリティと使用率に相関があったりしないかなと考えたりするのだが、見つけたい人はちゃんと見つけるので大丈夫か。
Git(Hub) の使い方
レポジトリの作成・管理
- まだどこにも存在しない新規 git レポジトリをローカルに作成
$ cd ディレクトリ名; git init
- GitHub 等に存在する(自分の・他人の)リモートレポジトリをローカルにコピー
$ git clone URL
- submodule も一緒に取得したい場合は
--recursive
をつける
- 現在のリモートリポジトリ一覧表示
$ git remote -v
- リモートレポジトリを追加
[url "git@github.com:"] insteadof = https://github.com/
- リモートレポジトリの URL を変更
$ git remote set-url エイリアス名 URL
レポジトリの状態の管理
- 変更状況を確認
$ git status
- ログツリーを表示
$ git log --oneline --graph --decorate
.bash_profile
に以下のように記述しておくと$ git log
だけで済む
git() { if [[ $@ == "log" ]]; then git log --oneline --graph --decorate else command git "$@" fi }
- ブランチの一覧表示
$ git branch
変更の反映
- ローカル上の変更をリモートレポジトリに反映
$ git add .; git commit -m "コミットメッセージ"; git push
fatal: The current branch master has no upstream branch.
と表示されたら$ git push origin master
- リモートレポジトリを指定してプッシュ
$ git push -u エイリアス名
- リモートレポジトリ上の変更をローカルに反映
$ git pull (origin master)
ブランチ
- 新規ブランチの作成
$ git branch ブランチ名
- ブランチの移動
$ git checkout ブランチ名
サブモジュール
- サブモジュールの追加
$ git submodule add URL
- 最新の commit に更新
$ cd サブモジュールディレクトリ名; git pull origin master
$ cd レポジトリルート; git add/commit/push
(これをするまでstatusは更新されない)
SSH接続
Host github.com User ユーザ名 HostName ssh.github.com IdentityFile ~/.ssh/秘密鍵ファイル名 ServerAliveInterval 60
Gtk-WARNING **: cannot open display
と表示されたら$ unset SSH_ASKPASS
.gitignore
ファイル
- 複数のディレクトリに置くことができる
- 深い階層の
.gitignore
に書かれた指定の方が優先順位が高い - 以下の上の行から順に解釈される
/
を含まない、もしくは末尾以外にのみ/
を含む行(e.g.file
,/file
,path/to/file
,/path/to/file
)- 末尾が
/
の行(e.g./path/to/directory/
,path/to/directory/
) !
で始まる行(e.g.!/path/to/file
)!
以降のパターン文字列が示すファイルまたはディレクトリを無視しない- 前の無視指定を上書きする
- 以降の無視指定に上書きされうる
- 空行もしくは
#
で始まる行- 解釈されない
- ワイルドカード(
*
,?
,[0-9]
など)も使える
所得
所得 = 収入 - 必要経費
いつも分からなくなるので、ここに書いておく。今年はちゃんと確定申告で必要経費を引いておいてよかった。
それにしても、税金高い。こりゃ文句言われるわけだ。自分の場合年金はまだ免除されるけど。
Wordに貼り付けたPDFがベクトル形式ではなくなってしまう現象
タイトルの通り。外部のPDFからWordに貼り付けたPDFは、大抵はそのままベクトル形式で配置され、拡大・縮小しても綺麗なまま保たれる。
しかし、たまにこれがうまく行かず、貼り付けたその時点は綺麗に写っているものの、一度ファイルを閉じて再度開くと(!)荒くぼやけたサムネイルになってしまうことがあった。
- MacOS Sierra 10.12.4
- Microsoft Office for Mac 2016 15.32
- Adobe Acrobat Pro XI 11.0.19
- Adobe Illustrator CC 2017
色々試してみて分かったことは以下の通り。
- ある特定のPDFファイルをIllustrtorを使って編集すると起こる(AcrobatとKeynoteで編集すると大丈夫だった)
- それぞれを別々に貼り付けても大丈夫だったものが、複数を(Illustrator, PowerPoint, Keynote等で)1枚のPDFにまとめてから貼り付けるとダメ
- PDFを経由しないでPowerPointオブジェクトを貼り付けるとうまくいく
結局解決できずPowerPointからオブジェクトを直接コピーして貼り付けることにしたのだが、謎すぎる。Wordが勝手にサイズを圧縮していると思ってそれ関連と思われる色々な機能をオフにしてもダメ。
普段はWord (というかOffice全体)なんて使わないのだが、今回は様々な兼ね合いで使わざるを得ず仕方なくdocxを用意した。途中、何度嫌になったことか。。この手のソフトウエアは、便利さを謳いながら、その実制限された機能を詰め込んでいるだけで、自由度が低く結局やりたいことなんかできないというのが個人的な印象だ。タダ飯は無いのである。
2017/5/22追記
おそらく原因が判明したので追記。Keynoteからオブジェクトをコピーする時に、どうやらベクトル形式のオブジェクトであってもラスター形式でクリップボードに保持されるらしい。。
以前はベクトル形式のままできたと思うのだが(ググるとクリップボード経由でpdf保存みたいな記事がいくつか出てくる)。。。
PowerPointは大丈夫。謎仕様だ。Keynoteの株は自分の中で大暴落。(2017/7/5追記: どうやらこのKeynote由来の現象は全体の一部らしく、Keynoteを使わなくても起こるらしい。昔のMavericksとかも引っ張り出して近いうちに原因をちゃんと調査したい。)
画像の一部分の比較
画像処理というには簡単すぎる内容かもしれないが、画像の一部分を切り出してすでにあるものと比較、という処理。最近やっていないのにブックマークが邪魔だったので、ここにまとめようと思い立った。
簡潔にまとめると以下の通り。
画像切り出し
$ convert -crop 横ピクセル数x縦ピクセル数+横始点ピクセル+縦始点ピクセル 元画像 出力画像名
- 例:
$ convert -crop 960x720+160+0 src.png dest.jpg
- ピクセル指定のところは代わりに
50%
のような割合指定も可能
- 例:
画像比較
$ perceptualdiff -threshold 閾値ピクセル数差 画像1 画像2
- 例:
$ perceptualdiff -threshold 100 fig1.png fig2.png
- 例:
参考文献
Rust
最近流行っているらしいRustの解説動画。半分くらいまで視聴。
Ownership/Borrowingという概念でポインタ周りの(潜在的)バグをコンパイル時に見つけたりできるようにしたらしい。発想としてはshared reference (SR; 共有参照?不変参照?とでも言うべきか)/mutable reference (MR; 可変参照?とでも)をうまく使い分けることでC++では未定義動作だった解放済みのアドレス参照を防いでるようだ。1つのオブジェクトに対してshared/mutableを同時に両方は使えないようにして、オブジェクトの参照と変更がお互いを気にしないで行われることを防いでいる(と自分は受け取った)。
また、Ownership概念を使うと、スレッドのmutationを明示的に行わなくてもよくなる?(Ownershipは非同期なスレッドであっても同時にはどちらか一方にしか与えられないから)。いちいちOwnershipのやり取りをしないといけないので実行速度が少し気になるが、どうなのだろうか。
そもそもOwnershipがどのようなものか、どのように付与しているのかがまだよく分かっていないので、機会があれば使用を検討して実際に使いながら理解していきたい。