rsyncでファイルサーバとローカルディスクを同期する
背景
最近、Windowsマシンからファイルサーバ上にある数GBのファイル群を扱うことが多い。このとき、ファイルサイズが大きいのでファイルを開くたびに結構な時間を待たされていて困っている。
DropboxやGoogle driveのデスクトップクライアントのように、アクセス頻度が高いデータはローカルディスクに保存してあって直ぐに開けるようになっていてほしい。
解決方法
クライアントがWindowsなので今までその気にすらならなかったが、単にLinuxと同様にrsyncを使えば良いことに気づく。ただし、ファイルサーバがSMBしか使えないので、Linuxのようにssh経由でコピーすることはできない。
また、アクセス頻度が高いデータだけをコピーしてくる...というのは難しそうなので、今回はディレクトリ全体をファイルサーバ - クライアントマシン間で同期することにする。
1. Windowsにrsyncを入れる
メインの作業はLinuxのbashで行っているので、Windowsマシンを使うときは Git for Windows を入れたときについてくる Git bash (msys2の機能削減版) を使っている。したがって、Git bashからrsyncを使えるようにセットアップを進める。
通常版のmsys2であれば最初から入っているか pacman -S rsync
でインストール可能なのだが、Git bashは機能削減版なので簡単に入れられず。。。
(こちら)https://qiita.com/clvth14/items/5a7eb26ddca49b7f57c2 の記事を参考に、rsync と必要なdllをインストール
2. ファイルサーバのマウント
共有フォルダ もしくは ネットワークドライブ としてファイルサーバをマウントする。共有フォルダにGit bashから cd で移動したい時は、//<server_ip or host>/share
のように行頭の /
が2つ必要なことに注意。ネットワークドライブであれば割り当てられたドライブレター (/z/
など) で通常通りアクセス可能
3. rsyncで同期
rsyncとファイルサーバのセットアップが終われば、後は rsync
コマンドを実行してファイルコピーを行えばよい。
例えば、rsync -arP <file_sever> <local_disk>
みたいな感じで実行すると、コピー状況を表示しつつディレクトリを再帰的にコピーしてくれる。再帰的にコピーする際、特定のファイルやファイル形式だけコピーしたくないといった事情があるなら、 excludeオプションで除外すればよい。--exclude '*.jpg'
のような感じ。
今のところは同期したい時だけスクリプトを叩くようにしているが、定期的に同期を走らせたくなったら cron や タスクスケジューラ を使おうと思う。
スタンディングデスク (Flexispot E7)を導入した
在宅勤務を始めて2年が経過し、毎日座りっぱなしで足腰が弱ってきてる気がしたので、スタンディングデスクを導入することにしました。
安くてしっかりしているということから、ネット界隈でFlexispotという会社のスタンディングデスクが流行っている(?)ので、自分もFlexispotのデスクを購入しました。
選定
Flexispotのスタンディングデスクは、性能の違いから複数のモデルが存在するのですが、E7という最上位モデルを買いました。
別に最上位モデルにしたかった訳ではないのですが、 立った状態と座った状態の適切なデスクの高さを教えてくれるサイトで調べたところ、 自分の身長(172cm)だと、座りで67cm、立ちで100cmというのが適正らしく、この範囲を昇降できるデスクは最上位モデルのFlexispot E7しか無いみたいだったので、必然的に決まりました。
他のモデルは、下げたときの高さが足りない(高すぎる)ので、全体的に身長が高い方向けのラインナップなのかも知れません。
E7は天板付きのモデルもあるのですが、ネットを見てるとDIYで天板を作っている人が結構いて、楽しそう & 家にぴったり合うサイズで作れそうということで、脚だけのモデルを買いました。
組み立て
事前に、ホームセンターで天板用の木材、オイル、やすりを買い、天板を作っておきました。
ホームセンターには、杉、ラジアタパイン、スプルースの集成材が売っていたのですが、節が少なく、明るめの色が好みだったので、スプルースにしてみました。
集成材をそのまま天板に使うとすぐに汚れちゃうので、ニスで保護したりするのですが、今回は初めてワトコオイルを使ってみました (これまたネットで流行ってたので...)
が、個人的には微妙でした。オイルフィニッシュは表面の強度が上がらないので、そのうち傷や汚れが目立ってきそうな感じがあります。
確かに色は綺麗だし、乾くのに時間がかかるので初心者でも簡単に塗れそうな点は良いのですが、デスクの天板向きでは無さそうですね。 どちらかというと本棚とか小物みたいな、色が重要だけど触り続けないものに向いている気がします。
まぁ、自作の良いところは修正が効くことですね。汚れてきたら表面を削ってウレタンニスを塗りなおそうかと思います。
Flexispot E7は、いろんなブログに書かれていた通り、めっちゃ重いので(30kgくらい)ので、家の中を移動させて組み立てるのがめっちゃ大変でした。。。 (非力なので、玄関で段ボールをあけて、中身をバラバラに取り出して部屋の中に取り込むのがやっとでした)
使ってみた
まだ1日しか使ってませんが、立って作業してると腰の負担が減ってる感じがして良いです。
また、デスクの高さを微調整できること自体がそもそも良いですね。 今までのデスクは高さを調整できず、理想的な高さで使えてなかったので、それが解消されたことだけでも足腰の負担が減って良かったと思います。
Moonlander Mark 1を購入した
まえがき
最近、慢性的な肩こりとそれによって引き起こされる頭痛が悩みの種になっていた。 毎日ストレッチすることで改善はするものの、完治はしないので、何か別に原因があるのだろうと思っていた。
いろいろと自分なりに分析してみた結果、PCで作業しているときの姿勢に問題があるのではないかと思い、肩こりに良いといわれているエルゴノミクスキーボードの導入することにした。
入力デバイスは安定供給性が高いものを選定したいという考えを持っているので、自作キーボードには手を出さず、市販のエルゴノミクスキーボードの中から有名どころを探すことにした。 その過程で、ErgoDox Ezという有名なエルゴノミクスキーボードを販売しているサイトが、ErgoDoxの後継となる?新しいエルゴノミクスキーボード "Moonlander"を販売していることに気づいた。 組み立て済みだったり、ケーブルがUSB-Cだったりと、ErgoDoxよりも洗練されている印象だったので、Moonlanderを購入してみた。
その結果、あっさり肩こりが解決されたので、導入して良かった。
Moonlanderを購入
zsa.ioで購入した。 値段は$365 (UPSの海外配送料込み)で、当日のレートで約4万円だった。 サイトには発送まで3週間かかると書かれていたが、実際には2週間で自宅に到着した。
余談だが、UPSは土日配送しないと高を括っていたら、いつの間にかクロネコヤマトに引き継がれていて、日曜日に届いた。 その場で輸入消費税(1200円)を支払う必要があり慌ててしまったので、事前に用意しておくと良いだろう。
良かったこと
肩こりがなりにくくなった
なりにくくなったというか、ほぼ感じなくなった。 Moonlanderを使った後にHHKBを触ると、巻き肩になっているように感じるので、エルゴノミクスではないキーボードでは肩に負担がかかるというのは正しい模様。
キーのカスタマイズ
キーカスタマイズの自由度が非常に高いおかげで、PC側にキーリマッパーを入れる必要がなくなった。 単にキー自体をリマップできるだけでなく、複数キー同時押し時の挙動を制御できるのが便利。 自分はctrl + hjklで矢印キー扱いにする設定をしている。
気になること
打鍵音
カニカルスイッチに詳しくないので、一番無難そうな赤軸を選択したが、そこそこ打鍵音が気になる。 スイッチは簡単に差し替えられるので、サイレント赤軸という静かな軸に今後変えるかもしれない。 また、打鍵感もHHKBに使われている静電容量無接点スイッチのほうが好みだった
安定供給性
キー配列が特殊なので、一度慣れてしまうと他のキーボードが使いづらくなる。 そのため、故障や追加購入がいつでもできるような安定供給性があると嬉しいのだが、小さな会社が作っているので、HHKBと比べると安定供給性に不安がある。 キースイッチは簡単に交換可能だし、電気回路の知識と道具もあるので、ある程度の故障は直せそうではあるが。
値段
数年間使い続けると思うので、長い目で見ると良い投資なのかもしれないが、やはり1台で4万円というのは高価
総評
比較的高価な買い物ではあったが、導入以降、明らかに肩こりが改善されていたので、長い目で見たらかなり良い投資だったと思われる。
macOSのようにWindowsでスクリーンショットを撮影する
Windowsのスクリーンショット問題
macOSからWindows10 への移行で問題になったことの一つとして、スクリーンショットの撮影方法がある。 ショートカットキーで全画面やアクティブウィンドウのスクリーンショットを撮影してファイルに保存 という良く使いそうな撮影方法がWindowsにはないようなのだ。
macOSでは、cmd + shift + 3で全画面、cmd + shift + 4でウィンドウを選択したスクリーンショットを撮影してデスクトップに保存できる。 一方のWindows10にもスクリーンショットを撮影する方法はあり、それも何故か下記の3種類もあるのだが、どれも一長一短あって使いづらい。
- PrintScreenで全画面、Alt + PrintScreenでアクティブウィンドウをクリップボードへ保存
- Win + sで全画面、Win + Shift + sで選択範囲をピクチャディレクトリに保存
- Snipping Toolを使ってGUIでスクリーンショットを撮影して、任意のディレクトリに保存
やりたいことに最も近いのは3番目のSnipping Toolだが、GUI操作なのと、デフォルトファイル名が キャプチャ.png になるため連続してキャプチャしづらい。
キャプチャソフトを追加で入れれば解決できるとは思うが、スクリーンショットを撮影する機能のためだけに常駐アプリを増やしたくもない。
解決策
AutoHotKey (AHK)を使ってスクリーンショットを撮影するスクリプトを組んだ。
AHKとは、キーマップを変更したり、特定のキーコンビネーションでスクリプトを実行したりするための常駐アプリだ。 常駐アプリだが様々な用途で使えるので、スクリーンショット撮影アプリを常駐させるよりは良いだろう。 www.autohotkey.com
自身が慣れているmacOSのショートカットキーに似せるため、Win + Shift +3で全画面、Win + Shift + 4でアクティブウィンドウのスクリーンショットを撮影するように設定した。 撮影されたスクリーンショットは、ScreenShot + {撮影時刻}.pngという形式のファイル名でデスクトップに保存する。
Capture a screenshot on Windows using AutoHotKey …
script.ahk
、screenshot_window.ps1
、screenshot_all.ps1
を同じディレクトリに配置したうえで、script.ahk
をAHKで実行すれば利用できる。
macOSからWindowsへ移行を進めている
十年弱使い続けてきたmacOSからWindowsへの移行を進めている。移行を進めている理由は、興味がWebからARやComputer Vision(CV)へ移ったからだ。
ARやCVでは大容量なメモリやCUDAが必要になるが、Macはメモリが割高かつCUDAが使えない。CUDAというか、そもそもnvidia製GPUが使えない。
Windowsなら好きなハードウェアが使えるし拡張性もある。自分でPCを組んでしまえば、必要に応じて性能を上げられる。ただ、Unixコマンドが使えないため知識や過去のコードが使いづらい。その点だけが課題となり移行の決断をできずにいた。
ところが最近になって、Windows Subsystem for Linux(WSL)によってWindows10でUnixコマンドが使えるようになった。Dockerなど一部のアプリケーションがWSL1では動かないが、6月に正式リリースされるWSL2で解決される。DockerコンテナからのGPUアクセスやGUIアプリケーションのサポートも今後のアップデートで行われる予定らしい。
さらに、Windows TerminalというMicrosoft純正のターミナルエミュレータも開発が進んでいる。Windows Terminalではタブでシェルを切り替えることができる便利機能が搭載されている。これにより、cmd.exeやpowershell.exeだけでなくWSL上のbashもまとめて使える。
それならばということで、先月Windowsデスクトップを購入した。ショートカットキーの違いに戸惑っているが、おおむねMacで行ってきたことがWindowsでも実現できた。そもそものスペックが違うので比較にならないが、OpenCVのビルドやUE4が圧倒的に速くなって快適だ。
UnityによるOculus Questアプリ開発
Oculus Quest
PC不要の一体型HMDかつトラッカーレス6DoF対応という未来を体感してみたくて、Oculus Questを買ってしまった。
Questめちゃ良い pic.twitter.com/O40xsUJVUu
— Yuki (@yuki_tkd) 2019年5月25日
あまりゲームをするタイプではなく、スマブラ目当てで買ったSwitchが1ヶ月で飽きて放置されているので、買うのを躊躇っていたけど好奇心に勝てなかった。 5/1から買うかどうか迷っていて、結局5/15くらいにOculus公式で発注したけど、5/24の夕方に届いた。海外から発送されるのに早い。
早速beat saberやvr chatをやってみたけど、久々に凄い感動した。 HTC ViveとかOculus Riftでもやったことあるけど、全然ユーザ体験が違った。 準備の手間がほとんどかからず、被るだけでVR世界に行けるなんて、完全にレディープレイヤーワンの世界。 もうHMDはこれで良いです。完成。って感じ。
せっかく買ったので、南極に行ってペンギンに囲まれるVRアプリを自分のためだけに作ろうと思います。
Quest アプリ開発とOculus Store
Oculus Questの開発は個人でできないという噂があったのですが、結果から言うと個人でも開発はできます。 Oculus QuestはOculus Goと同じくAndroidベースのOSが搭載されているので、Androidアプリとして書き出すことができる開発環境があればOKです。
個人では難しそうなのは、作ったアプリをOculus Storeで販売すること。 審査を通過しないと販売することができず、その審査基準がかなり高いらしい。 Quest向けアプリはクオリティの高いものから展開していく方針らしいので、2019年5月現在は個人で開発して販売するのは結構ハードルが高そう。
環境
- Unity 2018.4.0f1 (2018.1.0だと動かなかったので注意)
- Android Studio 3.1.3
Oculus Quest向けアプリをUnityで作る
Unityプロジェクトの作り方
事前準備として、UnityからAndroidアプリをビルドできるようにAndroid SDKを入れておく必要がある。以前UnityからAndroidアプリを作ったことがある人は不要。
Unityを立ち上げて新規プロジェクトを作る。
Questに搭載されたセンサによる6DoF移動やOculus Touchに反応させるため、Unity StoreからOculus IntegrationをDownload & Import (Import結構時間かかることが多い) assetstore.unity.com
Quest向けにビルドするため、Build Settingsを以下の設定に変える。
- プラットフォームをAndroidに変更
Player Settings
から Minimum API LevelをAndroid 4.4 ‘KitKat’ (API level 19)
に変更- API Level 19未満にしたらエラーが出たので、おそらく現在はこれで良さそう。
Package Name
のcom.Company.ProductName
のCompanyとProductNameを登録した組織名とプロジェクト名に置き換える。Androidの
XR Settings
のVirtual Reality Supported
をチェックして、右下の+ボタンを押してOculusを追加以上でUnity側の設定は終わりなので、後は適当にUnityでアプリを作る。
アプリのインストール
Questの開発者モードをオンにする
USBケーブルでPCと接続する
PCと接続すると、Questの画面内に
このPCにファイルアクセスを許可しますか?
みたいな感じのアラート画面が出るのでYes
を選択Unityから
Build & Run
でAndroidアプリとしてビルド&書き込みQuestの画面内に
このPCからアプリのインストールを許可しますか?
みたいな感じのアラート画面が出るのでYes
を選択Questの
Home
->Library
->Unknown sources
の一覧からインストールしたアプリを選んで起動できる。
以上で、Oculus Quest上で動くアプリを作ることができます。
今回は簡単なアプリなので問題ないけど、FPSを稼ごうとすると結構テクニックが必要そう。 周辺視野部分を荒くレンダリングするFoveated Rendering(中心窩レンダリング)や、左右の視差映像を1枚のフレームとしてレンダリングする手法などを使って、 CPU/GPUのリソースをなるべく減らす必要がありそうでした。
RealSense D435でKinect Fusionする
経緯
RealSenseのDepthセンサーを使ってSLAMをしたい。
簡単なのはROSを使うことらしい。
ただ、ROSを使ったことが無いというのと将来的にUnityにリアルタイムでそのモデルを持っていきたいので、Unityに繋ぎやすい方法で実装したかった。
そこで、将来的にNative PluginとしてUnityに繋ぐことを想定して、最近OpenCVに実装された kinfu
(Kinect FusionのOpenCVコミュニティ版実装)を動かしてみることにした。
そして、このブログをもうちょっと技術的なブログにしていこうと思って書いた。
環境
- Windows 10 Home
- Visual Studio Community 2017
- OpenCV 4.1.0
- OpenCV-contrib 4.1.0
- ビルド済 RealSense SDK 2.21.0
- Cmake 3.14.4
大事なこと
やったこと
- OpenCVとOpenCV-contribをgit clone
- それぞれ4.1.0としてcheckout
- OpenCVディレクトリの下に
build
というディレクトリを作る - cmake(gui)を開いて、opencvディレクトリとopencv/buildのディレクトリを開く
以下の設定を変更する
- OPENCV_ENABLE_NONFREE (チェックを入れる)
- OPENCV_EXTRA_MODULES_PATH (opencv-contrib/modules へのパスを入れる)
- WITH_OPENCL (チェックを入れる)
- WITH_LIBREALSENSE (チェックを入れる)
- LIBREALSENSE_INCLUDE_DIR (Add EntityからDirecotry Pathとして、
C:/Program Files (x86)/Intel RealSense SDK 2.0/include
を入れる) - LIBREALSENSE_LIBRARIES (Add EntryからFile Pathとして、
C:/Program Files (x86)/Intel RealSense SDK 2.0/lib/x64/realsense2.lib
を入れる) x86もあるけど、x64選ぶこと。
configureする
- open projectする
- ALL_BUILDを右クリックしてBuild (時間かかる)
- INSTALLを右クリックしてビルド
- opencv/build/install 以下にヘッダファイルやビルド済みlibなどができるので、
opencv/build/install
ディレクトリを適当な場所と名前でコピー (例えば C:/opencv-410/) - 環境変数に
opencv-410/x64/vc15/bin/
を追加 - Visual StduioのC++のインクルードパスと、ライブラリパスに、
opencv-410/x64/vc15/lib
、opencv-410/include
を追加 - opencv-worldではなく、coreやhighguiなどがバラバラのlibとしてビルドされるので、それらすべてをVisual Studioのリンカが見に行けるように登録する
- OpenCVのビルド & 設定完了
実行
- サンプルプロジェクトを作って実行したときに、librealsense2.dllが見つからないというランタイムエラーが発生したら、RealSense SDKの中からlibrealsense2.dllを探してきてプロジェクトのディレクトリにコピーする (RealSense SDKへのパスが通っていたらおそらく不要?)
参考にさせて頂いた記事
ほとんどここの通りなのだけれど、ビルド済みRealSense SDKが64bitとは知らず32bitでOpenCVをビルドして手間取ってしまった。 qiita.com