多くの場合、増悪因子が慢性上咽頭炎 不適切に対処すると筋痛性脳脊髄炎/慢性疲労症候群(ME/CFS)に該当する状態まで増悪する。(*1) 適切な対処で十分治療可能。 ペーシングで酸欠にならないことが何より大事。 呼吸リハビリ(*3) PS別呼吸リハビリ 鼻うがい・ミサトールリノローション 上咽頭擦過療法(EAT、Bスポット療法)(*2) 追加の倦怠感が出ることをしない ゆるめる瞑想 セルフケア|頭痛の治し方(鎖骨から上のケア) セルフケア|腰から脚のケア 高圧酸素療法(酸素カプセルで効く場合あり。治るわけではなく一時しのぎ。)(*4) できれば血液検査で亜鉛の量をチェックして、80より少なければ補充 できれば血液検査でフェリチンをチェックして、50より少なければ鉄をサプリや薬で補充 市販のBCAA(アミノバイタル・アミノバリューなど) 市販のプロテイン 陽証の場合は、「柴胡剤+駆瘀血剤」o
はじめに Ansible Playbookで、OS/ディストリビューションの差異がある場合には、Factsの情報を利用してTaskを分けることが多いと思います。 Amazon Linux(初代)とAmazon Linux 2はベースとなるOSディストリビューションが違うこと(それぞれRHEL6、RHEL7をベースにしているように見える)、その他大きな変更が行われていることから、場合によっては同じTaskを適用できないことがあります。 Amazon Linux(初代)とAmazon Linux 2を判別する方法をまとめます。 TL;DR 2019/4/27現在、きれいに判別する方法はまだ無さそう 「ansible_distribution」と「ansible_service_mgr」で判別するのが一番現実的 「ansible_distribution_major_version」はいずれも「
Ansible getting started Getting started with Ansible Getting started with Execution Environments Installation, Upgrade & Configuration Installation Guide Ansible Porting Guides Using Ansible Building Ansible inventories Using Ansible command line tools Using Ansible playbooks Ansible playbooks Working with playbooks Templating (Jinja2) Using filters to manipulate data Tests Lookups Python3 in temp
エンティティの識別子の生成タイミング問題 DDD[1]では,一意な識別子を持ち,その識別子によって識別できるモデルをエンティティ (Entity) として表現します.このエンティティの識別子の生成方法には様々な種類がありますが,大きく分けて永続化前に生成する早期生成と永続化後に生成する遅延生成の2種類に分けられます. エンティティの識別子の生成に遅延生成を用いると本来 Not Null な識別子を Nullbale として扱う必要性が生じてしまいます.これを避けるのであれば,早期生成を採用すると良く,IDDD本[2]などではUUIDやGUIDをアプリケーション側で生成し識別子に用いる例が紹介されています. しかし,技術的な問題でUUIDなどのランダムな値を識別子として採用しづらいケースも存在します.たとえば,MySQL (InnoDB) ではプライマリキーにランダムな値を用いるとINSER
似て非なるもの多すぎ問題 UUIDとULIDの違い UUID(Universally Unique Identifier) ULID(Universally Unique Lexicographically Sortable Identifier) よくわからない ソートの可否(’21 6月追記) UUID ULID 一意性にかわりない 参考URL 違いシリーズ第三弾! 第一弾と第二弾はこちら↓。(シリーズ化するつもりもない) bonoponz.hatenablog.com bonoponz.hatenablog.com 似て非なるもの多すぎ問題 いや、多いのよまじで。 故に、初心者にとって単語が理解できずに話についていけないシーン多いです。似た単語の違いを調べることがまだあるかもしれないので、先にシリーズ化を予兆する。 UUIDとULIDの違い 根本的には同じものなのかもしれない、と調べ
この画像は本文とは関係ありません。 こんにちは、エムスリー・エンジニアリングG・基盤開発チーム小本です。 みなさん、git submodule コマンドは好きですか?git submodule は特定の状況下では便利なコマンドです。 社内アンケートでも25%が怖いという結果に しかし、なぜか世間にはgit submodule が怖いという人が相当数いるようです。推測ですが、git submodule は動作モデルや使用手順が誤解されがちなところがあり、それで「怖い」と思われているのないでしょうか。git 本体でも昔そんなことがありましたよね。 この記事では git submodule の誤解を解き、適切な使い方を解説します。また、記事の最後にチートシートをつけます。 git submoduleはトモダチ!怖くないよ! git submodule って何? 誤解1 「プロジェクトが大きくなっ
結果を取得したいモジュールの箇所にregisterを入れるだけです。値は自由。 今回は中に何が入ってるか見る為にdebugモジュールとmsgパラメータを使います。 - hosts: vagrants tasks: - name: yumモジュールチェック shell: rpm -qa | grep yum | wc -l register: yum_check - name: 実行結果 debug: msg: "{{ yum_check }}" [実行結果] TASK [yumモジュールチェック] ****************************************************************************************************************************************************
Ansible getting started Getting started with Ansible Getting started with Execution Environments Installation, Upgrade & Configuration Installation Guide Ansible Porting Guides Using Ansible Building Ansible inventories Using Ansible command line tools Using Ansible playbooks Protecting sensitive data with Ansible vault Using Ansible modules and plugins Using Ansible collections Using Ansible on W
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く