202108

資格勉強のしかた

  • まず過去問題などがあればとりあえず参考書をみつつでもといてみる．自分の実力を掌握し，目標達成との差分を認識する．
  • 勉強する．

https://promcon.io/2019-munich/slides/improved-alerting-with-prometheus-and-alertmanager.pdf

Rotary Encoder回路

  • ロータリエンコーダのノイズ対策
../_images/rotary_encoder_circuit.jpg

PlatformIOでLittle FS(SPIFFS)のコンテンツを転送する．

board_build.filesystem = littlefs
board_build.ldscript = eagle.flash.4m2m.ld

あたりを設定して，

platformio run --target uploadfs

こう．targetがこうだから．

% pio run --list-targets                                                 (git)-[develop]
Environment    Group     Name         Title                        Description
-------------  --------  -----------  ---------------------------  -----------------------------------------------------
FAST           Advanced  compiledb    Compilation Database         Generate compilation database `compile_commands.json`
FAST           Generic   clean        Clean
FAST           Platform  buildfs      Build Filesystem Image
FAST           Platform  erase        Erase Flash
FAST           Platform  size         Program Size                 Calculate program size
FAST           Platform  upload       Upload
FAST           Platform  uploadfs     Upload Filesystem Image
FAST           Platform  uploadfsota  Upload Filesystem Image OTA

ESP8266(esp-wroom-02)でPlatformIO

iniにかけるconfigはこんなかんじ．もちろんupload_portなども指定できる．こちらは

{
  "build": {
    "arduino": {
      "ldscript": "eagle.flash.2m.ld"
    },
    "core": "esp8266",
    "extra_flags": "-DESP8266 -DARDUINO_ARCH_ESP8266 -DARDUINO_ESP8266_ESP_WROOM_02",
    "f_cpu": "80000000L",
    "f_flash": "40000000L",
    "flash_mode": "qio",
    "mcu": "esp8266",
    "variant": "nodemcu"
  },
  "connectivity": [
    "wifi"
  ],
  "frameworks": [
    "arduino",
    "simba",
    "esp8266-rtos-sdk",
    "esp8266-nonos-sdk"
  ],
  "name": "ESP-WROOM-02",
  "upload": {
    "maximum_ram_size": 81920,
    "maximum_size": 2097152,
    "require_upload_port": true,
    "resetmethod": "nodemcu",
    "speed": 115200
  },
  "url": "http://www.esp8266.com/wiki/doku.php?id=esp8266-module-family",
  "vendor": "Espressif"
}

upload_protocol = espota
upload_port = 192.168.4.1

ESP8266のyield

ウォッチドッグタイマ（WDT）： プログラムが暴走するなどした場合に，自動的にリセットがかかる安全装置で，標準的な Arduino にはない機能です．プロセッサ内部にタイマーがあり，(1) loop() の終了・再呼出時，(2) delay() の実行時，(3) yield() の実行時にタイマが 0 に戻されますが，タイマが 3s を超えてしまうと，ESP-WROOM-02 が強制的にリセットされます．したがって，loop() の内部に while や for などで長時間実行される部分や入力待ちがある場合は注意が必要です．適宜，delay() や yield() を入れてください．delay(0) でもオーケーです．一方，delayMicroseconds() ではリセットされません． WiFi 関連の機能： 後述する WiFi や TCP/IP 関連の機能（HTTP リクエストの処理など）は，上述の WDT リセットと同様に，(1) loop() の終了・再呼出時，(2) delay() の実行時，(3) yield() の実行時に，併せて実行されます．したがって，WiFi や TCP/IP の応答性を確保するには，プログラム構造を工夫したり，適宜 delay() や yield() を呼び出すようにしてください．
  • 時間がかかりそうなところにはyield();をいれておいてやる．forで回す回数が多いとか．

ESP8266でCaptive Portalっぽいしくみ

ESP8266のresetとrestartの違い

ESP8266のconnection practice

ESP8266でDigest/Basic認証

  bool authenticate(const char * username, const char * password);
  bool authenticateDigest(const String& username, const String& H1);
  void requestAuthentication(HTTPAuthMethod mode = BASIC_AUTH, const char* realm = NULL, const String& authFailMsg = String("") );

あたりをつかってやる．

【研究成果・プレスリリース】熱平衡化の問題は、一般的な形では解決不可能な問題であることを証明 | 学習院大学

  • Undecidability in quantum thermalization | Nature Communications
  • 物質には温度差を与えた後にエントロピー不変空間に十分な時間放置したときに熱平衡になるものとならないものがある．ほとんどの物質は熱平衡になる．これを熱平衡化という．
  • 熱平衝化するかどうかを調べたかったけどよくかんがえると熱平衡化するかどうかって決めることができるんだろうかという思想．
  • 熱平衡化するためにはどういう条件が必要なのかということについて観測的アプローチをとり研究されてきた．
  • 今回はそもそも熱平衡化するか否かは（何らかの要因によって）決定づけることがそもそもできるのかどうか，という点に着目．これが否である場合，あらゆる要素は熱平衡化するか否かを決定することはできない．つまりあらゆる物質の熱平衡化の可否を決定づける(一般化可能な)要因/原因が存在しないことを意味することになる．
  • 今回はこれを計算機科学におけるチューリングマシンと停止性問題に類似した手法で証明するものである．
  • かんたんに眺めたところ，物質の熱平衡におけるダイナミクスを表現する量子システムをチューリングマシンのテープに対応させ，る熱移動と対応するセルの移動をテープデータの操作(seek/read/calc./seek/write)に対応させているようにみえる．
  • このとき，熱平衡化する場合，このチューリングマシンは操作が完了し停止することに対応する．熱平衡化しない場合，チューリングマシンは停止しないことに対応する．
  • 停止性問題については決定不能であるため，熱平衡化か否かについても(今回用いた量子システムの視野においては)決定することはできない．
  • 物質の熱平衡現象と計算機科学および数学に深い関連があることにも意味がある．

15 minutes rule

データベースにおけるLock

  • 共有ロックと占有ロック(悲観的排他制御)
    • 共有ロック(LOCK IN SHARE MODE)
      • 自身のconnectionはread/write可能，他のconnectionからはwrite不可read可．
      • 参照整合性の担保のためなどに利用される．
    • 占有ロック(FOR UPDATE)
      • 自身のconnectionはread/write可能，他のconnectionからはwrite不可read不可．
  • lockを掛ける場合はtransaction内で必要に応じてLOCK IN SHARE MODE/FOR UPDATEを利用しlockを取得する．writeも同一transactionに含めなければ正常な整合性担保は行うことはできない．
  • InnoDBの場合UNIQUEかINDEXがついていれば行ロック，ついてなければテーブルロックになるらしい．
  • innodbでサブクエリを使ったときの FOR UPDATE のロックの範囲 - ngyukiの日記
    • サブクエリ/結合についてはLOCKのセンテンスの位置によってロックのかかる対象が異なってくるので十分注意する必要がある．

トランザクション分離レベル

  • transaction isolation level
    • transactionは一般に並行処理可能であるから，transactionにおいて競合状態は一般に発生しうる．
      • 発生するものの，transactionの性質からACIDは担保されるべき(but, この一貫性についてはパフォーマンスとの兼ね合いで不完全なのでユーザが考慮することも求められている)．
  • リード事故
    • Dirty Read
      • Commitされていない他のtransactionのdataをreadしてしまうこと．
      • readしたdataには他transactionによる変更が起きる可能性を孕んでいる．
    • Fuzzy Read/Non--Repeatable Read
      • あるtransactionで複数回dataをreadしたとき，他のtransactionのwriteによってtransaction内で再現性のないreadが起こること．
      • 異なるdata間で整合性を担保する必要がある場合に担保できなくなる可能性を孕んでいる．
    • Phantom Read
      • Fuzzy Readと似ているが，他transactionによるINSERTにより，繰り返しreadした際のテーブルデータが増えてしまうこと．
      • isolation levelをserializableにすることでしか解決できない(いくら既存のものをロックしても"増えるもの"については無駄)．
  • LEVELS
    • READ UNCOMMITTED
      • いみふめいな(整合性のとれてない)かわりかたをするかも！
    • READ COMMITTED(postgresqlのdefault)
      • かわるかも！
    • REPEATABLE READ(InnoDBのdefault)
      • かわんないけどふえるかも！
    • SERIALIZABLE
      • かわんないしふえない！
  • isolation levelでの対策による解決が担保されるか否か
┌─────────────────┬───────┬───────┬─────────┐
│ isolation level │ dirty │ fuzzy │ phantom │
├─────────────────┼───────┼───────┼─────────┤
│ READ UNCOMMITED │  NG   │  NG   │   NG    │
├─────────────────┼───────┼───────┼─────────┤
│ READ COMMITED   │  OK   │  NG   │   NG    │
├─────────────────┼───────┼───────┼─────────┤
│ REPEATABLE READ │  OK   │  OK   │   NG    │
├─────────────────┼───────┼───────┼─────────┤
│ SERIALIZABLE    │  OK   │  OK   │   OK    │
└─────────────────┴───────┴───────┴─────────┘
  • トランザクション分離レベルについてのまとめ - Qiita
  • ロックとの違いはなんなのか
    • read onlyについては同一transactionにおいてlockを活用することで解決可能である．
    • transactionで変更するdataが存在する場合，このtransaction内においてのreadについて通常lockを使って気を遣う必要があるが，このtransaction分離機構によりそれぞれのtransactionによるisolationを自ずと保証するという便利な機能となっている(と思う)．
    • isolation levelはtransaction単位の整合の話であり行ロックとは必ずしもlock対象が一致ではない可能性がある？
      • transaction内部においても必要がある場合はlockをする必要がある(たぶん？transaction lessのreadのために．) # TODO: あとでexp.してcheck
  • Autocommit