在宅ワークでほぼエアコンつけっぱなしというのがほぼ原因ですね。
夏も終わりに差し掛かっていますが、少しでもエアコンの効率を良くするためにこんなものを作ってみました。
バスポンプで室外機のアルミフィンに霧吹きする装置です。
バスポンプが常時ONだと1時間くらいで20Lを消化してしまうので、間欠スイッチモジュールで10秒に一回2秒間だけ霧吹きするよう調整してみました。
効果は測っていませんが、室外機から出てくる風がそこそこ冷たい感じがするので、多少効果はあるでしょう。
これで少しでも電気代が下がればいいのですが。
]]>
これめっちゃ良いのでどこか商品化してください!!
このヘッドセットの特徴は
です。
もとはAmazonで売っているこういうヘッドセットです。Aliexpressだと1000円以下で買えます。
これを一度解体して100円ショップのカチューシャに接着剤でくっつけただけです。
元のヘッドセットは一般的なイヤホンやヘッドホンと違って、直接耳道に音を入れるのではなく、耳の前にイヤホンをおいて間接的に音を聞くような構造です。骨伝導のヘッドホンと同様、周囲の音も聞こえるので、個人的には結構良いと思っています。(会話するには十分ですが、低音は聞こえないので音楽鑑賞には不向きです)
この構造は悪くないのですが、耳に引っ掛けるタイプなので長時間つけていると耳がそれなりに疲れるのと、眼鏡を使っているときにテンプルと干渉するんですよね。あと、ネックバンドがあるのでヘッドレストのある椅子だともたれかかったときにも干渉します。
オーバーヘッド型でオープンイヤーのヘッドセットないかなぁと結構探したのですが、なさそうなので作ってみました。
耳を塞がない特徴を活かしつつ、オーバーヘッド型にコンバート。しかもカチューシャは眼鏡のテンプル付近をまたぐようにヒードガンで曲げてあります。
これを作ってからしばらく使っているのですが、かなり満足したものになったと感じています。元のヘッドセットにあった欠点がすべて解消して、しかももともと軽いので体のどこにも負担がかからず、かなり快適です。
こういう商品なんでないんだろう。テレワークが広がってきた今けっこう需要あるんじゃないかと思うんですよね。プラスチック製品作っているところならそんなにハードル高くなく作れるものじゃないかなと思うので、どこか製品化してほしいなと思います。
]]>ウェブ会議で起こる事故といえば
ですよね。
特にシンプルウェイでは業務中は常にDiscordに集合しているため、マイクの切り忘れ = チャンネル内放送になります。
Discord自体にもミュート機能はあるのですが、会議してチャンネル移動して、とかやっていると切り忘れちゃったりするんですよね。
ということで、カフを作ってみましょう。
]]> カフとは、放送などで使われる手元でマイクのOn/Offができるものですね。USBオーディオインターフェイスを分解して、マイク入力にスイッチをはさみます。また、マイクのOn/Offに合わせてLEDが光るようにして、マイクOnのパイロットランプにしました。
ちなみに、原型はこれでした。
1000円付近のUSBオーディオインターフェイスはみな同じチップと基盤構造なので、どれでも同様に改造できるでしょう。
これを先日作成した雲台に組み込みます。
マイクOnのときは激しくLEDが光って目につくので、切り忘れ防止になりそうです。
]]>
ついでに、机に転がって置いてあるUSB-DACもまとめて、オーディオの入出力も雲台周辺にまとめようと思います。
ちょうど加工しやすそうな角パイプがホームセンターで売うられていたのでこれを使います。
で、加工中は何も写真を撮っていないので、いきなり完成形です。
金属に四角い穴を開けるのは大変ですね・・・。昔のミニ四駆の肉抜きを思い出しながら、穴をたくさん開けてニッパで切り開いていく方法でなんとか開けました。
そしてこれをモニターアームに固定して、カメラを乗せれば完成です。
最近のノートパソコンは標準でカメラやマイクが付いているので、気軽にウェブ会議に参加できるのですが、僕は普段デスクトップを使っているので、カメラやマイクは別途用意しなければなりません。
しばらくスマホをウェブ会議使っていたのですが、画面共有されたときにかなり見づらいのと、ログインが必要なミーティングスペースだと準備に手間取るデメリットがありました。
ところで、コロナで旅行もいけなくなり、活躍の場を失ったミラーレス一眼がありましたので、これをウェブカメラとして活用すべく準備してみました。
MiniHDMI端子がついていて、ファインダー画面をそのまま出力できます。
NEX世代のSonyのカメラはUSB入力は充電専用で、給電には使えないようです。毎度充電するわけにもいかないので、バッテリー端子から直接給電するダミーバッテリーを用意します。
純正品は高いので互換品でもいいと思います。
また、HDMI映像をPCで取り込むためにビデオキャプチャーを用意します。
これで物理的な準備が整いましたので、PC側の準備を行います。
キャプチャー入力と仮想カメラ出力の両方を兼ね備えているOBS Studioという便利なアプリケーションがありますので、これをインストールします。
シーンを追加して適当な名前をつけ、
ソースに映像キャプチャデバイスを追加します。
デバイスでHDMIキャプチャを選択して確定します。
最近の一眼はレンズ画像をそのまま出力するクリーン出力機能があるようですが、NEXの場合その機能がありません。そのため、できるだけファインダー上の表示を少なくして、OBS側でクロップします。
これで準備は完了です。
通常時はOBSを起動すれば上記までの設定が維持されていると思いますので、「仮想カメラ開始」ボタンを押してカメラ出力を開始するだけです。
あとはブラウザなりミーティングアプリケーションなりでカメラ入力を「OBS Virtual Camera」を選択すればミラーレス一眼の映像をウェブカメラとして利用できます。
]]>もともと予定通り投稿するつもりだったのですが、サーバー障害で余計な手間を食らってしまったので今から投稿しています。
こちらの記事で紹介した反響音対策がいまいちだったので、追加で対策してみたいと思います。
デスクの反対側はこんな感じの壁になっています。
これは結構効果がありそう。反響音がそこそこ低減した気がします。
ちなみにカーテンを黒にした理由は、カメラの自動露出設定でも顔が明るく映るようにするためです。
スマホのインカメラのオート設定で撮って見ましたが、狙い通りに調整されていそうです。
これでビデオありのウェブ会議でも、美しい人はより美しく、そうでない方はそれなりに、映りそうです。
さてせっかくいろいろDIYしたところですが、そもそもシンプルウェイは完全テレワークに移行したので、活躍の場が...
]]>先日の記事でも紹介した会社のテレカンブースですが、狭い上に物がなにもないので音がかなり反響します。
ついでに、デスクを昇降式に交換したせいで、もともと天板が固定されていて壁紙が貼られていない部分が露出しています。
これら2点の課題を解決するために、壁に絨毯を貼ってみました。
]]>
うーん、これは失敗。
反響音もそれほど低減していないし、見た目もあまり綺麗に仕上がらなかった。
毛足の長い絨毯だからそれなりに音を吸収するのではないかと思ったのですが。
とりあえず見た目だけでも、もう少しシワが伸びたら調整が必要ですね。
]]>サイトの障害に気がついたときはまだSSHでアクセスでき、ディスクも読み取り専用ではあったもののデータは救出できたのでなんとか助かりました。
ちょうどCentOS6でサポートも切れたタイミングだったので必要なタイミングだったのかもしれません。
ということで、仕事の合間を縫ってサーバーリプレイスを行いました。
現在サーバーはOracle Cloud Infrastructureで稼働しています。
OCIのなにが素晴らしいかって、無料なんですよね。Microインスタンスの最初の2台が無料で使えます。
これだったらGCPでも同様のサービスはありますが、OCIは東京リージョンが選べるのがアドバンテージかと思います。
スペックはかなり低いけど、MovableTypeだとほとんど負荷はないし、前段にCloudflareでCDNをはさんだので、もっと負荷はかからないので、全く不足はないですね。
ついに個人サーバーは無料の時代へ。Oracleさんありがとうございます。
]]>Qiitaはプログラムに関する記事を書く場所のようなので、雑記は個人ブログで書くことにします。
コロナウィルスの影響もあって、クライアントとのミーティングもリモート会議になることが多くなりました。シンプルウェイにはそんなシーンで使える1畳サイズのテレカンブースがあります。
ところで、会社にスタンディングデスクにできるガス圧式のPCスタンドが転がっていました。そのまま放っておくと倉庫の肥やしになってしまうので、これをテレカンブースで活用したいと思います。
作り付けのデスクを外して、加工した木材を組み付けます。
最後にPCスタンドを連結して完成です。
角材を斜めカットしたのが少し大変でした。その代わり足元は比較的広くなりました。
天板を好きな高さへ変えられるのはなかなか使い勝手がいいですね。
]]>SEIL で NGN IPv6 ネイティブ (IPoE) 接続を試す を参考にIPv6の環境を試しているのですが、自宅のPCと比べてルーターからのPingがなんとなく遅い気がします。
自宅はひかり電話なしのフレッツ光ネクストなので、PCが直接フレッツ網からRAでIPv6プレフィックスを受け取っている状態です。
違いがあるとしたらHGWが挟まっているか否かなのですが、これが影響しているのでしょうか。
SEILのページによると、ONU配下には /56 のプレフィックスが来て、HGW配下には /60 のプレフィックスが来るようです。参考ページではHGWの配下にSEILを設置する例(下図左)が載っていますが、実はHGWではなくONUの配下に置いてもいいんじゃないか(下図右)という気がしています。
技術的にできるのか不明なので試してみないとですが。体感的な通信スピードは、スループットよりもレイテンシーのほうが重要なので、高速化できるといいなぁというところです。
]]>とあるノートPCがあります。これは別の会社のActiveDirectoryに参加していて、VPNつないだり共有フォルダ参照したりするのに必要です。ログインするためには指紋認証も必要です。
ところで、このPCは普段の業務に使うものではなく、持ち歩いたりしないので会社に置きっぱなしにして、リモートで使いたいですよね。
ところが、このPCはADのポリシーで激しく制限されいるのでリモートデスクトップが使えません。まぁ当然ですね。
でもどうにかしてリモートで使いたいんですよ。出先で急にデータ見たりしたいことも発生するわけです。
で、どうするか考えて、UltraVNCで下記のような仕組みを用意しました。
ノートPCはADのポリシーでポート空けたりできないので、VNCサーバーになれません。そのため、リピーターを別途用意して、ノートPCからはクライアントとしてリピーターに接続するようにしておきます。
リモート操作する側はリピーターを経由してノートPCへアクセスします。
ちなみに、この図は会社のLAN内で操作する前提になっていますが、会社のLANはVPNで入れるので実質インターネットがあればどこからでも操作できるようになっています。
リピーターをLinux上に作成する手順は UltraVNC SC (Single Click) com Repeater CentOS 7 あたりを参考にしました。比較的小さいプログラムのようなので、必要なライブラリがあれば素直にコンパイルできるはずです。
ノートPC側は下記のショートカットをスタートアップに置いておけば、ログインしたときに自動的にリピーターに接続させることができます。
winvnc.exe -autoreconnect ID:1000 -connect 192.168.0.10:5500 -run
ノートPC側のVNCはユーザーモードで動いているので、
というあたりが気をつけなければならない点です。
スリープやロックの時間はポリシーで設定されていることが多いと思うので、その場合はメディアプレーヤーで音楽でもリピート再生しておいてください。
]]>結論
証明書と秘密鍵のディレクトリが違うことに気が付かなくて小1時間。中間証明書のファイルが cacert.pem と勘違いして小1時間。まったく手こずらせやがって。
]]>もともと CentOS6 + Apache2.2 + PHP5.3 という一昔前の普通の環境が整っているサーバーへPHP7をインストールし、特定のバーチャルホストだけでPHP7を有効にできるように設定してみます。
手順は面倒なので、ポイントだけ箇条書きにしておきます。
Action php71-fastcgi /php71-fcgi/php-fpm ScriptAlias /php71-fcgi/ /opt/remi/php71/root/usr/sbin/ FastCGIExternalServer /opt/remi/php71/root/usr/sbin/php-fpm -host 127.0.0.1:9000 <Directory "/opt/remi/php71/root/usr/sbin/"> Options None AllowOverride None Allow from all </Directory>
<FilesMatch ".+\.php$"> SetHandler php71-fastcgi </FilesMatch>
こんな感じで動くんじゃないでしょうか!?
]]>
八ヶ岳のほうがキレイに見えていて、そちらにするか迷ったのですが、縁起物ということでやはり富士山に。
本年もどうぞよろしくお願いいたします。
]]>Apacheモジュールで処理を行った結果、404(Not Found)のHTTPステータスコードを返したい場合があります。その場合、2種類の方法があります。
ap_hook_handler で登録したフック関数の戻り値で404を返すap_hook_handler で登録したフック関数の引数 request_rec 構造体の status の値を変更する(戻り値は0=OKを返す)さて、2つの違いは何でしょう。答えは、レスポンスボディに何が出力されるか、ということろに違いがあります。
Apacheのフックの処理の流れから考えてみましょう。とりあえず、今回ポイントとなっているあたりを概略図にすると下記のようになります。
正常なとき
エラーの時(ファイルがない)
Apacheがいろいろなフックを呼びだし、誰かが処理を担当してくれたらそれを返す、誰も処理してくれなかったらエラー処理して返す、という感じでしょうか。
このとき、フック関数の戻り値で404を返すと下記のように処理が流れます。
エラー処理のほうに流れるわけですね。よって、エラー処理で生成されたレスポンスボディが返されます。Apacheの設定で ErrorDocument ディレクティブを設定している場合、指定されているコンテンツがレスポンスされます。
一方、request_rec 構造体の status の値を変更する場合、フック関数自体はOK(処理完了)を返すので、エラーレスポンスには処理が流れません。よって、 ap_rwrite などでレスポンスボディをセットしていれば、その内容がレスポンスされます。
この動きは、404エラーに限らず、500(Internal Server Error)などでも同様です。
これを理解できると、
ErrorDocument ディレクティブで設定された 404 ページを表示させたいなど便利な使い方ができます。
Apacheモジュール開発している人なんてあまりいないと思いますが、ご参考までに!
]]>