はとのーと

エジソンノート(アイデア、思い付き、メモ)として使っています。誰かの役に立つかもしれないので公開しています。

愚考 2020-11

2020-11-10

リバースプロキシを使って Docker サービスをまとめることが可能

Docker のサービスに個別にポート番号を割り当てると煩雑になる。 リバースプロキシを使うとポートを 80 にまとめたりサブディレクトリに入れたりできる。

Apache と Nginx はどちらがよいか? ApacheとNginxについて比較 - Qiita によると Apache は設定が簡単で Nginx は軽くて速い。

Alpine Linux

Dockerイメージを軽量化する - Qiita

ベースを Alpine Linux にすると軽量化するよという話。

超軽量なAlpine Linuxについて調べた - Qiita

パッケージマネージャ apk の使い方など。

軽さは正義!を口癖にしよう /「Alpine Linux Meetup Tokyo #1」に参加した - kakakakakku blog

スライドあり↓

speakerdeck.com

軽量イメージ時代を 生きるためのAlpine Linux - Speaker Deck

  • apk が扱えるようになれば Alpine は難しくない
  • Alpine 化は軽量化の入り口にすぎない
  • 素の Alpine には glibc がない

speakerdeck.com

ミニマリストのためのAlpine

  • X 周りでエラーが発生するので Alpine はヘッドレスで使う
  • インフラチームの成果物はサーバそのものと膨大な設定リスト、構築手順書。それらの更新と再実施はプロジェクトのコストを考えると現実的ではない→Docker ならばインフラのスクラップ&ビルドがしやすい
  • 軽さは正義
ACM Queue: 自動化はアイアンマンのようにすべき。ウルトロンではなく

Automation Should Be Like Iron Man, Not Ultron - ACM Queue

  • トニースタークは飛行パワーや軌道の計算ができるが代わりにスーツがそれをやることでトニーは別のことに集中できるし、スーツの軌道をトニーが修正できる
  • ウルトロンは完全自律型で決定を修正できない
Windows で使われるクライアントポート番号範囲

【図解】初心者にも分かる TCP/UDP 〜違いや共通点,使い分け,ポート番号,具体例について〜 | SEの道標

Windows Vista 以降は IANA の勧告に従い Ephemeral Port (49152~65535) を使用する (49152+16384-1 = 65535)。

C:\>netsh interface ipv4 show dynamicport tcp
プロトコル tcp の動的ポートの範囲
---------------------------------
開始ポート : 49152
ポート数 : 16384
C:\>netsh interface ipv4 show dynamicport udp
プロトコル udp の動的ポートの範囲
---------------------------------
開始ポート : 49152
ポート数 : 16384

2020-11-11

サーバ内での Web アプリの置き場所を考える

Debian 系の場合:

ここから考えると自作サービスは /var/lib/サービス名/var/lib/service/サービス名 のようなディレクトリに置くのが良いかも。

Slim Framework リンクメモ

2020-11-13

w3m のデフォルトのキーバインドを知りたい

w3mキーバインドopenSUSE Tumbleweed と Ubuntu 20.04.1 LTS で異なる。 たとえば ? キーは

という動作をする。 バージョンはそれぞれ

公式のデフォルト動作はどちらなのだろう?(→下記にデフォルトキーマップを発見した話あり)

Docker と LXC で開発ファイルを共有する場合のユーザとディレクトリの案

f:id:paz3:20201113183445p:plain

サーバ上に Docker とそのDocker で動かすサービスを開発するための LXC 環境がある場合、ユーザと開発用ファイルの置き場所はどうすればよいか?

ひとつのやり方として次を思いついた。

  • サーバ上にユーザ foo を作成する
  • LXC 上のユーザ foo とサーバのユーザ foo の UID を一致させる
  • /home/foo/share を LXC の同じディレクトリにマウントする
  • /home/foo/share/{サービス名} を Docker にマウントする
人生における様々なことを実行するためのメソッド
  1. 目標を設定する
  2. 目標をクリアするためのステップを考える
  3. 各ステップをクリアするためのサブステップを考える

これって TDD と同じなのではないだろうか?

2020-11-21

ゆっくりと動きながら高速でこなす、一流の研究者の Doing リスト
元記事

ゆっくりと動きながら高速でこなす、一流の研究者の Doing リスト | Lifehacking.jp

不明点について考察した皆さん
続編による公式の回答

今、そこにある未来:脳内バイパスを作る Doing リストの実践例 | Lifehacking.jp

  • リストから行動が発生する。リストにないことはしない
  • 割り込み、前提条件が満たされていない、達成不能などタスクができない時は割り込みタスクか「次に何をするか」をリストに加えて次に進む。決して止まらず進み続ける
  • リストの下まで行ったら残っているのは割り込みタスクと次のアジェンダになるので、それを元にして次の Doing リストを作って上からこなしていく
  • TODO リストで詳細にプランニングすると突然の変化や割り込みに対応できなくなる
  • TODO リストに書ききれなかった粒度の細かいタスクを Doing リストに箇条書きにして実行する
  • TODO リストでは頭のギアは未来になっていて、Doing リストでは頭のギアは現在になっている
  • いつやっても良い割り込みタスクなどは別のリストに書いておいてコンパイル待ちなどの時間に実行する
活用されている方の記事

clmemo@aka: 我流ながら Doing List を二年間試して得た Tips

  • 1日1ページ
  • 結果を4色ボールペンでチェック、コメントする
  • 『Doing List は GTD やチケットから「自分の手元」に降りてきたタスクを「自分でマネージメント」する道具だと思う』

Doingリストあれこれ(2) clmemo@akaのDoingリストと科学者のDoingリストの相違点 - works4Life

twitter でのコメント一覧

Ceron - ゆっくりと動きながら高速でこなす、一流の研究者の Doing リスト | Lifehacking.jp

2020-11-23

自分の場合の Doing リスト

TODO リストのタスクの粒度やレベル分けに悩んでいたので Doing リストを導入してみることにした。 自分が日々の仕事を進める場合、リストは4つになった。

  1. TODO リスト (アプリケーションで管理)
  2. 今日やること (上記 TODO リストから抜粋。ここから下は紙)
  3. 上記2を詳細化したもの
  4. 上記3を実行するための Doing リスト

3は2との関連がわかる程度の詳細化。 4は3を1つずつの手順に分けたもの。

たとえば請求書作成の場合、以下の感じに分かれる。

  • 請求書作成
    • 作成
      • 入力
      • 印刷
      • 押印
    • 差し出し
      • 封筒印刷
      • 重量チェック
      • 切手貼付
      • 投函
トランスメタ Crusoe

x86 命令を VLIW 命令に変換して非 x86 な CPU で実行する。 しかし性能が出なかった、とのこと。

2020-11-24

w3m のデフォルトキーマップ

w3m - Browse /w3m at SourceForge.net から w3m-0.5.3.tar.gz をダウンロードしたところデフォルトキーマップが記載されている doc-jp/keymap.default というファイルを発見した。

上の方で書いた ? キーの機能は次のようになっていた。

keymap  ?       SEARCH_BACK

こちらの方が馴染みがある。

2020-11-25

Docker でボリュームをマウントした時の権限

dockerでvolumeをマウントしたときのファイルのowner問題 - Qiita

Linux の Docker でホスト側のボリュームをマウントするとコンテナ側の UID の権限でファイルアクセスされる。 たとえばコンテナ内でサービスが root で実行されている場合、ホスト側のファイルに root でアクセスされる。

上記記事にはこれをホスト側の一般ユーザーに変更する方法が書かれているが、複雑度が増しそうなので、自分の環境では当面は「Docker ボリュームは root でアクセスされる」という前提にしようと思う。

2020-11-26

migr8 は Firebird に対応していない

データベース管理システム Firebird は サーバ名:フルパス でデータベースにアクセスできるのが素晴らしいと思う。 たとえば個人の DB ファイルをどんどん作って server1:/home/foo/db1.fdb などでアクセスすることができる。

参照: データベース上での作業 - Firebird1.5 クイックスタート

しかし Ruby 製の DB マイグレーションツール migr8Firebird に対応していない。 残念。