感想総括 何行も読んで初めて理解できるコードではダメ、その場でイメージが湧くように書くこと 命名はとても大事。「名は体を現す」となるようにすること。 まず人間語でアルゴリズム（処理手順）を書いてみることを徹底し、ロジックの粒度で関数を分けることを

宅内クラウドストレージ環境 だいたいやりたいこと 自宅内で複数人・複数デバイスでファイル共有 RAIDで耐障害性確保 ええ具合にストレージ上のメディアを再生・視聴 スマホ等の端末から写真をアップロードし、端末で余計なディスク容量を消費しないように。 な

gitbook docker containerとか転がってるけど、まずは気持ちを新たに王道のインストールをして使い倒す。 いずれ docker container 化して、 nginx proxy のコンテナの後ろにドキュメントごとに設置したい。 インストールはほぼコレ: http://takemikami.com/2017/02/14/gitbook.html UMLのpluginは公式少し見ながら: https://www.npmjs.com/package/gitbook-plugin-uml mermaid も

DS-Lite (Dual Stack Lite) RFC: RFC6333 (Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion) fragmentation 必ず カプセル化した後 にしろ (MUST) とのこと (6.3. Fragmentation and Reassembly) Fragmentation MUST happen after the encapsulation on the IPv6 packet. Reassembly MUST happen before the decapsulation of the IPv6 header. A detailed procedure has been specified in [RFC2473] Section 7.2. RFC2473 (Generic Packet Tunneling in IPv6 Specification) - Section 7.2. IPv4 Tunnel Packet Fragmentation こう書いてある DF-bit が立っている (SET) なら: Tunnel entry-point node はパケットを破棄 (discard) して、 ICMP unreachable (packet too big, recommended MTU

サイト刷新 刷新しました。 Grav から Hugo へ移行しよう。 いままでのサイトのダメだったところ コードブロックの表示が崩れる（謎のマージン） 見た目が悪い (h1 見出し直後に普通の文章を挟まないと h2 以下の見出しが中央寄せされる) コメントフォームがイケてない toc layout イケ

ネットワークの上でどんなパケットが飛んでいるのかを知っておこうシリーズ。 NAT (Network Address Transition) NAT にも色んな種類があるんだよ Full Cone NAT Restricted Cone NAT Port Restricted Cone NAT Symmetric NAT NAT のマッピング 3 種類のマッピング： Endpoint independent Address Dependent Address and Port Dependent NAT のフィルタリング 3 種類のフィルタリング： Endpoint independent Address Dependent Address and Port Dependent

Netlify todo サンプル通りにデプロイする CD pipeline を組む 複数の api spec を html 化するように action を修正 動的にそれら html を参照できるような index.html を作成 github のリポジトリの 特定フォルダをデプロイする方法 github でログインすると自然とそういう流れになる github actions からデプロイする netlify に github-actions で自動デプロ

API Doc の公開方法調査するぞー todo openapi spec statis html generator とかで検索 redoc-cli が良さそうとの声 https://dev.classmethod.jp/articles/openapi-firebase-hosting/ swagger-codegen とかもあるかな license も気をつけて選択しなきゃねぇ 調査観点 must Open API Spec file で完結できること ある程度の可読性 なるべく sample req/res を充実させ, FAQ を潰す should 仕様と動作を整合させたい -> try ボタンと mock など

Github Actions CICD パイプラインを github 公式で提供するサービス。 sakuraの記事読んでやってる: https://knowledge.sakura.ad.jp/23478/ いい感じにわかりやすい oai-petstore リポジトリで OpenAPI Spec に対して stoplight spectral の lint を動かすようにしてみる new pipeline を作るときに、公式の node.js CI の action を定義する yaml をもらってきて使う lint の warning 以上について

GitLab CI/CD 1年前くらいにやったやつを書き出していなくて、久しぶりに手を付けて困ったので書き出していこう。 イメージはこんな感じ GitLab のインストール (余談) cicd セットアップの前に本体をね。 Amazon EC2 でやってみたときの簡単すぎるメモです。すでに GitLab の環境を持ってる人