C#/.Netでパフォーマンスのために意識すべきこと
この記事は Performance Considerations of Class Design and General Coding in .NET - CodeProject を雑に日本語でまとめて微妙に参考を付加しただけです. 元記事が2014年なのでちょっと古い.
続きを読むPythonのimportで見事ハマる
(環境: Windows10-anaconda/python3, Debian8.5-anaconda/python3)
TL;DR
循環インポートしてた
タイトル通り. python様に「おめぇのpackage認めねーから!」とお叱りを受ける.
調べると大体以下の解決策がヒットする
- ルートパスが解決できていないので
PYTHONPATH
をプロジェクトルートに設定する sys.path.append("/path/to/dir")
でパスを追加する- 自作package化するためにpackageにしたいディレクトリに空の
__init__.py
というファイルを作成する - 自作packageを呼び出す際はimportで
.py
を含めない
(上2つはパスの解決のため, 3つ目はディレクトリ構造をpackageと認識させるため(python3.3以降は不要らしい), 4つ目は拡張子を除いた文字列がモジュール名と認識されるというルールのため)
が, どれを試しても解決しなかった. エラー内容はno module named ~
や~ is not a package
といったもののみで上記以外見当付かず.
PyCharmを利用していたのでそちらも確認したがエラーのサジェストは一切なし.
動かなくなった前後の変更点を端から試したところ循環インポート, 実際には(エントリポイントのpy -> とあるモジュールA, とあるモジュールA -> エントリポイントのpy)となっていた. この循環インポートをなくしたところ実行できるようになった, めでたし. (エラーサジェスト欲しかった…)
Scala関西Summitでスタッフがscala.collection再入門(改)をしゃべってきた #scala_ks
Scala関西Summitお疲れ様でした. 自分はスタッフとして参加しつつlongで1つしゃべっていました. ひしだまさんの裏だったので1対1とかにならないか不安だったのですが意外と来て頂いたようでありがてぇありがてぇ. 「あれ…タイトルや資料に既視感が…」という方もいたと思うのですが, その通りです. 元々Scala関西勉強会で一度喋ったものなのですが, 委員長のきの子さんの強い要望(?)によりCFPを出して最終的に登壇することになりました. 時間を目一杯使いつつ最後のほうのスライドは端折りましたが実は計画通りです(あまりお行儀は良くないですが…). 「1発表スライド」としてだけでなく「完結した資料」としてまとめておきたかったんです(そのせいで文字も多めになっていたり). タスクに追い込まれれば追い込まれるほど変なところで潔癖症になるタイプ.
※注: 以前の資料と同じようで結構更新しています. 表現が怪しかったり微妙に間違っていた箇所の修正を多数含みます.
最後にどうしても記録しておきたかった名言で〆
私的今日一番の名言
— amaya (@amaya382) 2016年10月8日
きの子さん「来年もやりまスカラ」#scala_ks
Docker in Docker のメモ書き
「Dockerの中でDcckerを動かしたい」ということはよくあると思う. 主に2つのアプローチが存在する.
- dind(DockerinDocker)イメージを利用
- sockをホスト-コンテナで共有する
今回は後者を取り上げる. なお, どちらの方法もセキュリティ的にやや難ありなので注意して使う必要がある. 以降, すべてのホストをA
, 通常のコンテナをB
, コンテナ内から呼び出されるコンテナをC
とする.
利用方法は非常にシンプル. A
-B
間で「sock」と「dockerコマンドそのもの」をrun時にvolume経由で共有する. 以下, 簡単なサンプル.
# on A docker run -it -v /var/run/docker.sock:/var/run/docker.sock -v `which docker`:/bin/docker alpine sh # on B which docker # => /bin/docker docker info # => Aのデーモンのinfoが出力される docker ps # => B自身が含まれたリストが出力される
A
上でB
とC
が並列に実行されるイメージだ.
注意点
A
とB
のディストロが異なるとき
バイナリ互換?libc/glibc辺りのライブラリ不足?の関係か, 共有したはずのdockerコマンドが動かないことがある(ホストA
: ubuntu, コンテナB
: alpine で確認). どうしようもないので, B
に対してコマンドを個別でインストールまたはB
のイメージビルド時に埋め込む必要がある. (ちなみに公式docには, 「クライアントとしてのdockerコマンドならOS Xでビルドしてもlinux上でもだいたい動くはずだぜ!」とか書いてありますが動かないものは動かない, 悲しい)
Docker in Dockerのrun時にvolumeを使うとき
B
内でdockerコマンドを叩くときに -v
を使ってvolume共有したいことがあると思う. このとき, :
の前に記述したパスはsockの所有者, つまりA
のパスとして解釈される. B
のコンテンツをC
と共有したい場合は一旦A
を経由させる必要がある.
以下, 上記の注意点を考慮したサンプル
# on A docker run -it -v /var/run/docker.sock:/var/run/docker.sock -v /piyoA:/piyoB alpine sh # on B apk add --no-cache docker docker run -it -v /piyoA:/nyanC alpine sh
B
上の/piyoB
がA
上の/piyoA
を経由してC
上の/nyan
と共有される.