モーグルとカバとパウダーの日記 このページをアンテナに追加 RSSフィード Twitter

モーグルやカバ(EXカービングスキー)、山スキー(BC)の山行記録などがメインの日記です。
いろんな条件のいろんなところを、その時々の条件にあった滑り方で楽しむ、フリースキーをして遊んでいます。

検索で来られた方は、上の検索窓から再度検索していただくか、右サイドバーのカテゴリーやトピックスの項目で絞り込んでみてください。
仕事柄、コンピュータ系のネタも多いので、スキー関連ネタだけ読みたい方は[ski]、コンピュータ関連ネタは[pc]、スパム関連ネタは[spam]で絞り込んでください。

2017-05-15 (Mon)

[]MacWindows混在でgit使ってる時の問題 MacとWindows混在でgit使ってる時の問題を含むブックマーク MacとWindows混在でgit使ってる時の問題のブックマークコメント

世の中の主なOSUnix系、Windows系、Mac系ではそれぞれ改行コードが違っています。

LinuxなどUnix系の改行コードは「LF」で、Windowsは「CRLF」、Macは「CR」となぜかそれぞれ別になってしまっています。


自分はWindowsではSourceTreeでgitを使っているのですが、Linux上のスクリプト言語のソースは改行コードは普通LFにする必要があるため、SourceTreeのデフォルトgitの設定では、commitする時に「CRLF」→「LF」に自動変換され、checkoutする時には逆に「LF」→「CRLF」に変換されるようになっています。


でもこれだと、なにも触ってないのに修正されているファイルとして上がってきてしまうことがあって、そしてしかたないからcommitしようとすると、変更されてないからcommitしなかったよみたいなこと言われて気持ち悪かったりします。


エディタデフォルトの改行コードを「LF」にしてしまえば良い話なので、この自動変換をしないように設定出来ます。

git config --global core.autocrlf false

これで自動変換をしないようになります。


もう一つ、Macからgitで日本語ファイル名を扱うとき、これも触ってないのに新しくファイルを作ったと言われてしまうことがあります。

その現象が起きるのは条件があり、日本語ファイル名中に「バ」や「ぱ」といった濁点や半濁点が含まれている場合でした。


MacだとNFDと言う「バ」を「ハ」と「゛」に別けて保持する形式でファイル名が記録されます。

しかし他の環境で作られたリポジトリではNFCという「バ」は一文字の「バ」として保持する形式で記録されているため、ファイル名のコード的には違ってしまうので、あたらしいファイルが作られたことにされてしまうのです。


これはMacの場合にはNFCに変換するという設定にしておくことで解決できます。


MacGit で日本語ファイル名を扱うときは core.precomposeunicode = true にしておく - かわちょでぶろぐ

http://kawachodev.hatenablog.jp/entry/mac-git-core-precomposeunicode

git config --global core.precomposeunicode true

というか、この手の改行コードの違い、NFC/NFDBOM有り無し、utf8とutf8mb4みたいな問題、いつか統一されてスッキリする日が来て欲しい…

トラックバック - http://d.hatena.ne.jp/stealthinu/20170515

2017-05-11 (Thu)

[]Windowsdocker-composeでのマウント Windowsのdocker-composeでのマウントを含むブックマーク Windowsのdocker-composeでのマウントのブックマークコメント

WindowsDocker Toolbox上でdockerを動かしているのですが、最近はWindowsでもdocker-composeも使えるようになっています。

なのですが、普通にdocker run -vではマウントできる設定でも、docker-composeでvolumes指定を使ってマウントを行おうとすると、エラーが出てマウントできないという問題がありました。


調べてみると同様の報告が見つかり、どうやら「Windows用にパスの書式を変換する」という指定が必要らしく、

COMPOSE_CONVERT_WINDOWS_PATHS=1

環境変数が設定されていると良いようでした。


docker compose volume mounts not work on Windows · Issue #4303 · docker/compose

https://github.com/docker/compose/issues/4303


これで問題なくマウントされるようになりました。


ちなみに自分はnyagosから使いたかったため、.nyagosに下記設定を追加して対応しました。

set {COMPOSE_CONVERT_WINDOWS_PATHS='1'}

(関連)

NYAGOSからDockerを使う設定 - モーグルとカバとパウダーの日記

http://d.hatena.ne.jp/stealthinu/20161028/p1

トラックバック - http://d.hatena.ne.jp/stealthinu/20170511

2017-04-19 (Wed)

[]WordPressのW3 Total Cache導入時の注意点 WordPressのW3 Total Cache導入時の注意点を含むブックマーク WordPressのW3 Total Cache導入時の注意点のブックマークコメント

とあるサイトで使われているWPを高速化・低負荷化したいという話があり、いくつか提示した中で一番簡単なキャッシュプラグインの導入を試したいということで、W3TCの導入をしました。

その時にテスト用サーバで試して問題が出たこととその対策と、tipsをメモします。


W3TCの基本的な設定

W3TCの導入については下記ページが大変参考になりました。

基本的な設定はここのサイトの設定にしたがっています。


W3 Total Cache のおすすめの設定方法

https://bazubu.com/w3-total-cache-23854.html


ログイン後にW3TCの設定ができなくなる

このWPではマルチサイトで運用されていました。

W3TCの設定終了後にログアウトして再度ログインすると、W3TCの詳細設定メニューが出ないというか、特権管理者(ネットワーク管理者)になれなくなっている感じでした。

これは下記設定で回避出来ました。


「Miscellaneous」の「Use single network configuration file for all sites.」はチェック外す


特定の環境で文字化けが発生した

自分のブラウザ環境では問題なかったのですが、一部の人が文字化けと言うか完全に化けた表示しかされない状況になりました。

見た感じでgzipがそのまま表示されている感じだったので、下記設定で解決できました。


「Browser Cache」の「Enable HTTP (gzip) compression」はチェック外す


同じ症例を探してみると、どうも古いPHP(PHP5.4以前)だとこの現象が発生するらしいです。


Wordpress】W3TCが原因で文字化けする場合の対処 | TeraDas−テラダス

http://www.teradas.net/archives/24204/


500 Internal Server Error が発生する

毎回ではないのですが、たまに500エラーが発生するようになりました。

エラーログを確認すると、W3TCのオブジェクトキャッシュ処理中にPHPがメモリ不足で落ちていることがわかりました。

その環境ではmemory_limitが128Mになっており、同様の件を探すとやはりW3TC導入でメモリ不足でエラーになっている件がいくつか見つかりました。

その結果からObjectキャッシュとDatabaseキャッシュを利用する場合、512M程度までは上げておいたほうがよい感じでした。


メモリ割り当てを増やしてもメモリ不足でエラーが出る

上記問題に対応するため、memory_limitを512Mにしてもメモリ不足でエラーが出ることがありました。

調査すると、Pageキャッシュでは問題なく、ObjectキャッシュとDatabaseキャッシュで問題が出るため、このキャッシュを利用しないように設定しました。

ObjectキャッシュとDatabaseキャッシュは、Pageキャッシュに比べると速度への貢献が低いので、無理に使わなくても良いと思われます。

また後述のようにObjectキャッシュを使うと、スマホとPCでページ切り替えをしている場合にうまく表示できないという問題がでるようです。


「Database Cache」と「Object Cache」の「Enable」をチェック外す


スマホ用とPC用でページが混在してしまう

このサイトは同一URLスマホ用とPC用のページが出るサイトだったのですが、スマホ用ページとPC用ページがうまく切り分けられず混在してしまう問題が発生しました。

そこでPC用とスマホ用、携帯用で別々のキャッシュを持つように設定します。


「User Agent Groups」の「1. High」と「2. Low」の「Enabled」をチェックする


PCとスマホを分けて綺麗に高速表示してくれるWPキャッシュプラグイン「W3 Total Cache」の簡単設定方法

https://nelog.jp/w3-total-cache


Objectキャッシュを使っていると、この設定をしてもうまくいかないらしいので、そのためにも前述のようにObjectキャッシュは使わないようにする必要があるようです。


W3 Total Cacheスマホ版レスポンシブ表示でもキャッシュが効く

https://iphone-lab.net/page-cahe-mobile-397832/



スマホページが表示されるはずがPC版ページが表示されてしまう

キャッシュ導入後、スマホページが表示されるはずの条件でPC版ページが表示されてしまう問題が起こりました。

キャッシュファイルとアクセスログから調べてみると、iPadからの閲覧が行われたときに間違ったキャッシュが生成されていることがわかりました。


このサイトではPCとスマホ、携帯の表示切り替えを行っており、スタイルの切り替えは「Ktai Styleプラグインにより行っていました。

https://wordpress.org/plugins/ktai-style/


そこで、スマホ判定を行っている部分のコードを確認すると

/wp-content/plugins/ktai-style/operators/base.php

preg_match('/\b(iP(hone|od);|Android )/', $ua, $name)

となっていました。


この判定を行なう条件が、W3TCのスマホの条件と違っており、Ktai Style では iPad からのアクセスでスマホページの表示は行わないが、W3TCではスマホページとして扱うため、そこで差異が生じて iPad から見られた場合に、PC版ページがスマホ版のページとしてキャッシュされていることがわかりました。


そこでW3TCの設定を、Ktai Styleの判定条件に合わせるよう変更しました。

User Agent Groups -> Group name: 1.high -> User agents:

android
iphone
ipod

携帯ページがキャッシュ化されると文字化けする

携帯向けページがキャッシュ生成時には文字化けしないが、キャッシュから表示された場合には文字化けしてしまうことがわかりました。

調査すると、携帯向けはShift-JISで表示しているのですが、HTTPレスポンスヘッダのcharsetではUTF-8になっているためでした。


前述のように携帯向けページ表示はKtai Styleを利用しており、下記ソースから携帯向けは全て「SJIS-win」で出力されていることを確認しました。

/wp-content/plugins/ktai-style/operators/

emobile.php ezweb.php i-mode.php softbank.php willcom.php

$this->charset = 'SJIS-win'

W3TCの標準設定ではUTF-8として出力されるようになっていたため、まずはそこを修正しました。

各ページキャッシュディレクトリ.htaccess に AddDefaultCharset UTF-8 が付けられてしまうことを抑止します。

Page cache -> Advanced -> Charset:

「Disable UTF-8 blog charset support」をチェック


しかし、ここを修正してもUTF-8として返っていました。

/etc/php.ini にあるPHPデフォルトcharsetでUTF-8が設定されており、キャッシュ表示でそれが強制されてしまっていたためでした。

しかし、キャッシュファイルはHTMLを直接apacheから表示しているはずなのに、なぜPHPデフォルトcharsetが使われるのかが不思議でした。

ディレクトリ指定で表示されるページが、W3TC が生成した mod_rewrite のルールで _index_low.html などが返されるようになるのですが、元々の apachePHPの設定で DirectoryIndex の指定が index.php になっており、先にPHPが動く設定が生きてしまうようです。


そこでWPのルートのディレクトリにある .htaccess (W3TCの設定が追記されるファイル)に、PHPデフォルトcharsetを設定しないように追記しました。

/.htaccess

### for W3TC Ktai cache
php_value default_charset none
###

これでやっと携帯向けページのレスポンスヘッダに charset=UTF-8 がつかなくなり、文字化けが発生しなくなりました。


カテゴリーページのキャッシュが更新されない

カテゴリー(category)ページだけは、そのカテゴリーのエントリーを編集しても更新がされないという問題がありました。

ページキャッシュの設定で「Purge Policy」の「Post terms pages」などをチェックを入れてもダメでした。


調べてみると同様の問題がレポートされていました。


Page cache for categories not updating with W3 Total Cache - WordPress Development Stack Exchange

https://wordpress.stackexchange.com/questions/25425/page-cache-for-categories-not-updating-with-w3-total-cache


そこでさらに調べると、この問題だけ解決するためのプラグインがありました。

やはりタグやカテゴリーでの生成ページを消去することが出来ないという問題があるようです。


W3 Total Cache Purge All Page — WordPress Plugins

https://ja.wordpress.org/plugins/w3-total-cache-purge-all-post/


非常に小さなプラグインですが、これで解決できました。


動的なコンテンツの含まれるページの更新が遅い

デフォルトのページキャッシュの維持時間が1時間になっているため、動的なコンテンツが含まれる場合、最大で1時間更新が遅れます。


Page Cache -> Advanced -> Garbage collection interval:

で設定が行なわれており、デフォルトは「3600」秒となっています。


キャッシュ保持時間を例えば10分程度と短くすれば、設定時間より最大で10分遅れ(期待値で5分遅れ)でコンテンツが更新されるようになります。


このキャッシュ保持時間ですが、WP-CronというWordPressの持っている疑似cron機能を利用して、そこにキャッシュ削除の呼び出しを登録することで行われています。

このWP-Cron機能は、何分毎という指定ではなく、毎回何時以降に実行という登録を行なう必要があります。

W3TCでは、既にキャッシュ削除の登録が行われていると登録のし直しが行われず、その登録された処理が行われた後に再度登録されるとき、あたらしい設定での登録が行われます。

つまり、キャッシュ保持時間の変更を行っても、次のキャッシュ削除が行われるまではキャッシュ保持時間が変わりません。

また、WP-CronはWordPressへのなんらかのアクセスをトリガとして動くため、ほとんどアクセスがない場合は指定した時間にcronの処理が動くとは限りません。


どうしてもリアルタイムで更新させたい場合、特定ページのみキャッシュさせないようにすることが出来ます。


Page Cache -> Advanced -> Never cache the following pages:

に下記のように指定すると、example_directory以下のページはすべてキャッシュされなくなります。

/example_directory/*



キャッシュの場所

/wp-content/cache 以下のファイルにキャッシュが作られます。

その下の page_enhanced にページキャッシュが、dbデータベースキャッシュ、object にオブジェクトキャッシュが作られます。

ページキャッシュは対応するドメイン/ディレクトリ/ファイル毎に対応するディレクトリが掘られてそこに「_index.html」という名前でキャッシュが作られます。

スマホ用や携帯用のキャッシュは、「User Agent Groups」で設定した名前「high」や「low」を使って「_index_high.html」のようにキャッシュが作られます。

動きがおかしくて、どこまでは正しくキャッシュが生成されているのかを見たい場合にここから確認します。


ページキャッシュの表示方法と有効期間

ページキャッシュは「Disk: Enchanced」の場合、前記キャッシュ場所にHTMLとして保存されます。

そしてページキャッシュの表示は、WordPressPHPを介さずにapacheからこの場所のファイルが直接表示されるようになっています。

これは /.htaccess にW3TCにより追記された mod_rewrite のルールにより行われます。

キャッシュが存在していればそのキャッシュが表示されるようになっており、キャッシュの有効期間という考えはありません。

編集が行われた時に古いキャッシュが削除されることでキャッシュの同期が行われるようになっています。

トラックバック - http://d.hatena.ne.jp/stealthinu/20170419

2017-03-18 (Sat)

[]「みんなのPython勉強会 in 長野」で発表した「ディープラーニングハンズオンを準備して学んだこと」のスライド 「みんなのPython勉強会 in 長野」で発表した「ディープラーニングハンズオンを準備して学んだこと」のスライドを含むブックマーク 「みんなのPython勉強会 in 長野」で発表した「ディープラーニングハンズオンを準備して学んだこと」のスライドのブックマークコメント

もう2ヶ月も前になるんですが(これを書いてるのは2017/5/18)


みんなのPython勉強会 in 長野 #1 - connpass

https://startpython.connpass.com/event/48846/


で発表させていただいたスライドを公開しておきます。


ディープラーニングハンズオンを準備して学んだこと

https://www.slideshare.net/stealthinu/ss-73399682



「みんなのPython勉強会」だったので、ディープラーニングのことがメインじゃなくて、ハンズオンで便利だったJupyterとかDockerの環境だとかnumpyだとかのことがメインの話です。

トラックバック - http://d.hatena.ne.jp/stealthinu/20170318

2017-03-02 (Thu)

[]Alpineに入れたPython3にh5pyを入れる Alpineに入れたPython3にh5pyを入れるを含むブックマーク Alpineに入れたPython3にh5pyを入れるのブックマークコメント

友人に alpine + Python3 + TensolFlow + Jupyter のdockerイメージを作ってもらって、それベースにKerasとサンプルデータ入りのdockerイメージを作ったのですが、Kerasからモデルのsaveをしようとするとエラーになってしまいました。


KerasはHDF5形式という科学技術計算で大量データを吐く時に使われるデータ形式でsaveするのですが、PythonでHDF5を扱うためにはh5pyというモジュールを入れる必要があり、さらにh5pyはlibhdf5というライブラリを必要としています。

ありがたいことにlibhdf5はAlpineでもパッケージが用意されているのですが、testingにしかないため、apkのリポジトリにtestingを追加してやる必要がありました。

またh5pyはpip3で入るのですが、コンパイルされるためコンパイル環境が必要になります。少なくともgccと、musl-devというglibc-devにあたるもの、あとcythonとPython3のヘッダファイルも必要になるためpython3-devが必要になります。


なので必要なことをまとめると


/etc/apk/repositories に追加

http://dl-cdn.alpinelinux.org/alpine/edge/testing

コマンド実行

# apk add gcc musl-dev cython python3-dev hdf5-dev
# pip3 install h5py

でh5pyを入れることが出来ました。

トラックバック - http://d.hatena.ne.jp/stealthinu/20170302

2017-02-20 (Mon)

[]Firefoxが起動して時間が経つごとにすごく重くなる問題 Firefoxが起動して時間が経つごとにすごく重くなる問題を含むブックマーク Firefoxが起動して時間が経つごとにすごく重くなる問題のブックマークコメント

去年の11月辺りからFirefoxがすごい重くなる現象が発生していました。

起動時点では重さは感じないのですが、ずっとPC起動してるとだんだんとFirefoxの動きが重くなってきて、タブ切り替えやスクロールですら非常に時間がかかってから動き出す、という感じでした。


で、あまりにも耐えられない感じになってきたので調査してみようと思いtweetしたところ、@hATrayfloodさんからアドバイス頂き、色々と試しました。


とりあえず「アドオン無効にして再起動」だと重くならずに動くため、一旦全プラグインを無効にして使って試し、そこから必須なプラグインを徐々にオンにして試していく、という方法で調べていきました。


すると自分の今回の問題では

Evernote web clipper

が重くなっていた原因であることがわかりました。


厄介なのは、起動時点では重くなくある程度動かすと段々と重くなってくるというものだったので、すぐに確定できないので時間がかかることでした。

今は、Evernote web clipperだけ無効にして快適に動いています。


同様にFirefoxがだんだん重くなるようになってしまった方の参考になれば。

2017-01-27 (Fri)

[]ExcelCSV読み込みでセル内改行がある場合 ExcelのCSV読み込みでセル内改行がある場合を含むブックマーク ExcelのCSV読み込みでセル内改行がある場合のブックマークコメント

セル内に改行があるCSV

"111","aaa"
"222","bbb
ccc"

のように「"」でくくってやれば表現可能です。


しかしセル内改行がある場合にExcelで読み込むと、セル内改行で切れてしまい表が崩れてしまう、という問題が起こりました。


実は最初にそのCSVを吐き出すモジュールを作成した時のテスト時にはうまくいっていたので、その後の修正でバグが混入したのだろう、ということで調査しました。

すると、出力するファイル名拡張子が「.csv」だったものを、後から出た要望で「.txt」に変更していたことがわかりました。


Excelは、拡張子が「.csv」の場合だと何も聞かずにCSVとして読み込んでくれるのですが、「.txt」の場合だとCSVや固定桁フォーマットのテキストを読み込むためのウィザードを動かしてそれで読み込みます。

ウィザードの場合でも「"」でくくられたCSVを読むことはもちろん出来るのですが、レコードを先に必ず改行で切ってしまってからパースするため、「"」でくくられている中に改行があってもそこでレコードは切れてしまうのです。


なので、状況を説明して変更された拡張子「.txt」を「.csv」に戻してもらうことで対応することになりました。


ちなみにExcelでセル内改行したものをCSVで出力すると、改行コードを可視化して表示すると

"111","aaa"\r\n
"222","bbb\n
ccc"\r\n

のようにセル内改行は「\n」のみで表現されています。

最初はこの違いのせいかと思ったのですが、セル内改行が「\r\n」になっている場合でも、拡張子が「.csv」であれば正しく読み込めます。

逆に、Excelが吐いたファイルでも拡張子を「.txt」に変更してしまうと、正しく読み込めなくなります。


(追記)

セル内改行コードを最初「\r」と書いてたのですが「\n」の間違いでしたので修正しました。

@tmtmsさんと@kotyさんに指摘頂きました。ありがとうございます!

トラックバック - http://d.hatena.ne.jp/stealthinu/20170127

2016-12-14 (Wed)

[]numpyで多次元配列の一部を渡した時の動作について numpyで多次元配列の一部を渡した時の動作についてを含むブックマーク numpyで多次元配列の一部を渡した時の動作についてのブックマークコメント

※追記で解決しました


最近、趣味でニューラルネット系のことをやっているためnumpyを触っているのですが、不可解な動作をすることがありました。

a = np.array([[1, 2], [3, 4]])

def test2(x):
  test1(x[0])

def test1(x):
  x += np.array([2, 3])

test2(a)

これでaを表示すると、期待通り

array([[3, 5], [3, 4]])

となります。


がtest1の関数

def test1(x):
  x = x + np.array([2, 3])

のように「x += …」を「x = x + …」と書いてしまうと

array([[1, 2], [3, 4]])

のように計算結果が保存されないのです。


どうやら「x += …」の場合は多次元配列の中身への参照として扱われるのですが「x = x + …」でやってしまうと値渡しとして扱われてしまっている?ようです。


Python引数は全部参照渡しとのことなのですが、intやstringのようなプリミティブなものはImmutableとして扱われるとかなってて、渡されるものによって動作が変わるようでハマる元な感じです。

Pythonでの引数の取り扱いの罠等


ただ今回のこの例の場合は、numpyが「+=」と「=」をオーバーライドしてる中の処理の違いが問題になってるのでは、という指摘をいただきました。


Cのポインター的に、多次元配列の一部を取り出したものを明示的に参照渡しするような書式があったらうれしいのですが。


(追記 2017/1/26)

配列から一部を取り出すスライス記法(r=o[0:2, 1:3]みたいにして多次元配列の範囲を取得できる)を試してたときも同じような状況になって、困ってたらわかりました。


NumPy配列のスライス表記の参照と代入

https://hydrocul.github.io/wiki/numpy/ndarray-ref-slice.html


その取得した範囲全体に対して値を入れる場合には

r = o[0:2, 1:3]
r[:] = 0

とやるとその選択範囲を0に出来るとのことでした。


そこで同様に考えて

r = o[0:2, 1:3]
# r *= 2 と同じ
r[:] = r*2

とやるとその範囲の値だけを全て2倍にできました。

トラックバック - http://d.hatena.ne.jp/stealthinu/20161214

2016-11-10 (Thu)

[]WindowsでDockerToolboxとVBoxHeadlessTray使って起動時点でdocker使える環境にする WindowsでDockerToolboxとVBoxHeadlessTray使って起動時点でdocker使える環境にするを含むブックマーク WindowsでDockerToolboxとVBoxHeadlessTray使って起動時点でdocker使える環境にするのブックマークコメント

ここのところずっとvagrant+ansibleでやってたんですが、最近なにかとdockerいいよってのを見せつけられて、やっぱこれからはdockerだよね、ってなってました。


が、Windows環境ってdocker使いにくいですよね。


Docker for Windows使えばいいんでしょうが、まずHomeでは使えないのでProじゃないといけないし、Hyper-Vを効かすとVirtualBoxが使えなくなるためvagrantとの共存ができなくなるとか色々不都合があります。

というわけで、あえてDocker for Windowsは使わずに、VirtualBox上で動くDockerToolboxを使うようにしています。


でそれはいいのですが、DockerToolboxは自動的に起動してくれないので、コンソール開いてdocker〜と打つ前にDocker Quickstart Terminal開いてdocker用のVMを起動してやる必要がありました。それがなんかなあと。

あと、Windowsを終了するときも意識的dockerVMを落としてやる必要があります。


DockerToolboxをWindows起動時に立ち上げる方法ないの?と思って探したところ、DockerToolbox自体にはないけどVBoxHeadlessTrayを使うと自分の望みどおりの動きをしてくれることがわかりました。

VBoxHeadlessTrayはタスクトレイからVirtulBoxのVMを操作出来るようにするツールで、Windows起動時に一緒にVMを起動したり、シャットダウン時には勝手に終了させてくれる機能があるのです。


VBoxHeadlessTray - Topten Software


インストールすると最初に「Select Machine」と言われてどのマシンを起動するか選びます。

DockerToolboxは「default」という名前で入るのでそれを選んで「Power on machine」をチェックしておくと、起動時にdockerVMも一緒に立ち上げてくれます。

これ、間違って設定しちゃった時にどうやって設定変更するんだろう?


(追記)

コメントでa13さんから教えていただきました。

自動起動する仮想マシンを変えたいとき、あるいは自動起動をやめたいときは、システムトレイから一旦VBoxHeadlessTrayを終了させて、もう一度普通に起動すると対象マシンの選択画面が出るとのこと。


これでWindowsでも起動時点からdockerが使えるようになりました。


(関連)

NYAGOSからDockerを使う設定 - モーグルとカバとパウダーの日記

Docker for Windowsオープンベータのインストールと問題点 - モーグルとカバとパウダーの日記

a13a13 2017/02/11 15:21 自動起動する仮想マシンを変えたいとき、あるいは自動起動をやめたいときは、システムトレイから一旦VBoxHeadlessTrayを終了させて、もう一度普通に起動すると対象マシンの選択画面が出ますね。

stealthinustealthinu 2017/02/14 01:44 おお、なるほど。
一旦終了させて再度起動するといいのですね。ありがとうございます!

トラックバック - http://d.hatena.ne.jp/stealthinu/20161110

2016-11-01 (Tue)

[]s3fs配下でchmod 0755/0644する速度 s3fs配下でchmod 0755/0644する速度を含むブックマーク s3fs配下でchmod 0755/0644する速度のブックマークコメント

S3をs3fsでマウントしている環境で、アップロードされたファイルのパーミッションを、ディレクトリは0755、ファイルは0644にchmodするスクリプトがあり、だいぶ処理時間が掛かっているので改善できないか調べていました。

s3fs使ってS3にアクセスするのは非常に遅いため、通常のファイルシステムに対しての常識とはまた違った気遣いが必要になります。


最初のスクリプト

find ./example -type d -exec chmod 0755 {} +
find ./example -type f -exec chmod 0644 {} +

という感じだったので、これを1コマンドにまとめたら少なくとも倍速になるんでは、と思ったわけです。


こういうのってうまく書いたらchmodだけで出来ないのかなあ、とも思っていたのでtweetしたところ、@mnb0327さん、@tatsushi_dさん、@satoh_fumiyasuさんからリプいただきました。

というわけで簡単に書く方法はなくて、やはりfind使うかperlとかでごりごりやるしかない、という感じでした。


(2016/11/2 追記)

chmodだけでディレクトリに対してのみ+x出来る記述方法を教えていただきました。

chmod -R a=,u=rwX,go=rX ./example

「0755」系のビットフィールド使った指定ではなく、「x」系の指定で「X」を使うと、ディレクトリに対してのみ実行権限「x」を付けられるのですね。

知らんかった…


そこで教えていただいた方法や、対照実験用のchmod単体でやった場合など、いくつか試してtime取ってみました。

2回データ取ってよかったほうを採用しましたが、だいたい近い時間で処理されていました。

s3fs-1.74で約950ファイルに対して行っています。

time ./chmod.pl
real    2m39.680s

time chmod -R 0755 ./example
real    2m44.186s

time find ./example -exec chmod 0644 {} +
real    2m47.660s

time find ./example -type d -exec chmod 0755 {} + -o -type f -exec chmod 0644 {} +
real    2m53.486s

time find ./example -exec chmod 0755 {} +
real    2m58.552s

time find ./example -depth -type d -exec chmod 0755 {} + -o -type f -exec chmod 0644 {} +
real    3m8.701s

time (find ./example -type d -exec chmod 0755 {} +; find ./example -type f -exec chmod 0644 {} +)
real    3m38.750s

chmod.pl

sub recursive {
    my ($dir) = @_;
    my @files = glob("$dir/*");
    foreach my $file (@files) {
        if (-d $file) {
            system("chmod 0755 $file");
            recursive($file);
        } else {
            system("chmod 0644 $file");
        }
    }
}

recursive("./example");

(参考)ディレクトリの中をを再帰的にたどってすべてのファイルに対してなにかの処理をするには | 入出力・ファイル操作 | プログラミング言語の比較 | hydroculのメモ


結局、perlで書いたのが一番早く、その場合は単純にchmodで全部0755にしてしまうよりも早く処理が終わりました。

単純なchmodよりもperlのが早いというのはちょっと不思議ですが、他の処理も動いていたため揺れの範疇かもしれません。

そして、find で -o オプション使って処理を変えるものも、ほとんど遜色ない時間で処理が終わりました。

さらに意外だったのが、元々のfindを2回書くパターンが実はそれほど遅くないということで、だいたい2割増程度の時間で済んでいました。


(2016/11/2 追記)

エントリ書いた後、さらにこのようなアドバイスいただいたので

  • chmodだけでディレクトリに対してのみ+x出来る記述方法
  • perlのchmodを内部コマンド使う方法
  • xargs経由でやる方法

を追加テストしました。

今日は全体的にS3へのアクセス速度が早くなっていて昨日やったテストの時間と直接比較できないため、代表的なものを比較用に再度テストしています。

time chmod -R a=,u=rwX,go=rX ./example
real    2m19.232s

time chmod -R 0755 ./example
real    2m22.987s

time ./chmod2.pl
real    2m26.634s

time ./chmod.pl
real    2m41.052s

time find ./11434 -type d -exec chmod 0750 {} + -o -type f -exec chmod 0640 {} +
real    3m18.127s

time (find ./example -type f -print | xargs chmod 0644; find ./example -type d -print | xargs chmod 0755)
real    3m19.146s

chmod2.pl

sub recursive {
    my ($dir) = @_;
    my @files = glob("$dir/*");
    foreach my $file (@files) {
        if (-d $file) {
            chmod 0755, $file;
            recursive($file);
        } else {
            chmod 0644, $file;
        }
    }
}

recursive("./example");

というわけでchmodでラージ「X」使うのが一番良くて、記述ももっともスッキリしました。

アドバイスいただいた皆様、多謝です!!

トラックバック - http://d.hatena.ne.jp/stealthinu/20161101