Windows のリソースモニターで使用中のファイルやフォルダを表示する
あるディレクトリを消そうとしたけど下層ディレクトリにcdしてて消せないとか .exeを実行しているから消せないとか、MacやLinuxだとそういう事がないからいいよなぁ… こういうのでひっかかると地味にイラつく。どのプロセスが握ってるか分からないから結局再起動したりとか。
— tyru (@_tyru_) September 22, 2016
@_tyru_ リソースモニター使うとわかりますよ。https://t.co/qK6kRiuIDa
— MURAOKA KoRoN Taro (@kaoriya) September 22, 2016
@kaoriya ありがとうございます!cdしてて消せない場合もリソースモニターで分かるんでしょうか?
— tyru (@_tyru_) September 22, 2016
@kaoriya 「CPU」タブの「関連付けられたハンドル」でディレクトリ名を検索して分かりました。ありがとうございます! https://t.co/Kn2puNcdbf pic.twitter.com/10zgs5r58g
— tyru (@_tyru_) September 22, 2016
一応画像はブログにもアップロードしておく(Twitter の永続性を信用してない)。
変更履歴
業務アプリで malloc() のアルゴリズムを実装する羽目になるとは思わなかった話
釣りタイトルだけど嘘は言ってない。
DBから連続的な番号をN個取る処理は考え方としては malloc() と同じだと気付いて Twitter でアレコレ考えたのをまとめた。
要点だけ言うと、
- 連続的な番号をN個取得し、それを ID として貸し出す処理は(考え方としては)malloc() と同じ
- チーム開発で高度な技術を使ったら負け(誇張あり)
- 飲酒は程々にしましょう
あるシステムで連番をN個(1,2,3とか4,5とか)取得する要件があって、これ malloc() を実装しろって言ってるのと一緒や、って気付いてしまった…
— tyru (@_tyru_) 2016年9月6日
ちなみに連番は予約番号といって、貸し出した連番はは他の人は使えないので本当に malloc() と要件は同じ。
— tyru (@_tyru_) 2016年9月6日
一つ分の領域(番号)を貸し出すだけなら業務アプリにありふれた処理だし色々実装が簡単になるのに、2つ以上になると複雑になるの面白いな。まぁ足りなくなったら prefix つける(sbrk(1)ぽい)とか色々安易な逃げ道はある訳だけど
— tyru (@_tyru_) 2016年9月6日
領域が足りなくなったら prefix つける、の他にどんな実装が考えられるだろうか?
— tyru (@_tyru_) 2016年9月6日
しかしこれ設計段階の今気付いて良かった…型を数値から文字列に変えるとかするなら色々影響出そうだしなぁ
— tyru (@_tyru_) 2016年9月6日
とりあえず malloc() によくありがちな free した領域を list に突っ込む、は DB が対象なのでやりにくい… 永続化すると検索する分計算時間増えたりテーブル定義変更とかしないといけないけどそれは避けたい
— tyru (@_tyru_) 2016年9月6日
まぁそこまで考えるか、って話だけど。あれは最適化のためのテクニックだし、とりあえず要件満たす分にはもっとシンプルでいいんだよな(最初言った文字列にする案とか)
— tyru (@_tyru_) 2016年9月6日
テーブル定義を全く変えず、数値のまま実装するなら、せめてサイズによって領域を区切った方がいいと思う(ハッシュみたいな感じ)。そうでないと3つ分の番号が必要なのに2つしか空いてなくて再検索…とかが頻発すると計算時間どんどん増えていく。それも運用開始後随分経ってから発覚する設計ミス。
— tyru (@_tyru_) 2016年9月6日
まぁそもそも肝心の「それ本当に必要なの?」っていう所の理由を聞いてないから、もっと要件聞かないとダメだな。これは情報連携とかじゃなく俺が悪い。
— tyru (@_tyru_) 2016年9月6日
言い訳としては、そんなに仕様確認する時間もなかったってのもあるけど!!1
— tyru (@_tyru_) 2016年9月6日
要件ちゃんと聞かないと独り善がりな実装して「一方ロシアは」状態に陥る。正直高度な技術使ったらチーム開発では負け、と自分は思ってる。もちろん必要に応じてそれができるだけの能力を持っておくに越したことはないけど。大抵それが必要とされる事はない。
— tyru (@_tyru_) 2016年9月6日
ナイーブな実装こそが正義(は言い過ぎか)
— tyru (@_tyru_) 2016年9月6日
ただそうやって適当な落とし所を早すぎる段階で探る癖が付いてしまうとそれも思考停止だと思う。拘りを無くしても負け。難しい。
— tyru (@_tyru_) 2016年9月6日
つまりこれって、「あともう一歩」っていうのを考えなくなったら終わりだよ、って事なんだよな。その観点が仕様面か実装面かの違いはあるけど。思考停止だけはしないっていうのはいつも思ってる事で、エンジニアは考える事が仕事なんだから、思考停止は職務放棄と同義。
— tyru (@_tyru_) 2016年9月6日
そう、正にこれと言ってる事は同じなんだよな。 https://t.co/pAywcYCb9p これめっちゃ共感したのよ。独り善がりになりがちだった自戒も込めてなんだけど。
— tyru (@_tyru_) 2016年9月6日
とりあえずこれの結論としては、テーブル定義の型を変えられるなら文字列型でも配列でも何でも返せるので、修正は容易(今なら大丈夫だろうし影響範囲もそんなでかくないはず)。
— tyru (@_tyru_) 2016年9月6日
etckeeper で commit されたら GitLab に push する
手順 (各ホスト)
以下の手順を自動化したスクリプトはこちら(実際のものとは多少異なります)。
etckeeper-setup-host.sh · GitHub
1. SSH鍵を生成
# ssh-keygen -t rsa -C "$(hostname)@gitlab-root.url" -N '' -f /root/.ssh/gitlab-$(hostname)
2. /root/.ssh/config に以下を追記
Host gitlab-root.url User (ホスト名) IdentityFile /root/.ssh/gitlab-(ホスト名)
3. gitlab-root.url
の SSH 鍵を /root/.ssh/known_hosts
に登録する
※ 自動化されたスクリプトでは ssh-keyscan
コマンドを使っている(関連:非対話的に ~/.ssh/known_hosts を更新 - Humanity)。
# ssh gitlab-root.url
4. リポジトリの初期化
# etckeeper init
5. GitLab の remote URL を追加
# etckeeper vcs remote add gitlab git@gitlab-root.url:etckeeper/etckeeper-$(hostname).git
6. 設定ファイルの PUSH_REMOTE
に gitlab
を追加
# vim /etc/etckeeper/etckeeper.conf # To push each commit to a remote, put the name of the remote here. # (eg, "origin" for git). Space-separated lists of multiple remotes # also work (eg, "origin gitlab github" for git). PUSH_REMOTE="gitlab"
手順 (GitLab の Web GUI から)
こっちの手順も自動化したい。 たくさんコマンドラインツールがあるみたいだけどあんまり調べてない。そのうちやるかも。
- 各ホストのユーザを作成
- ログアウトした状態のトップページでアカウントを作成すれば、パスワードも一緒に設定できる
- Admin Area からだとメール記載の URL から設定する必要がある
- ユーザのSSH鍵を追加 (各ホストごとの手順で作成)
- 各ホストのリポジトリを作成
- 各ホストのユーザを etckeeper/{ユーザ名} のプロジェクトに Master として追加
以上
これで /etc/cron.daily/etckeeper が実行されるたびに git push される。