水底

ScalaとかC#とかk8sとか

ノートパソコンで内蔵スピーカーとヘッドホン(イヤホン)の音量設定を個別にするやつ

OS再インストール時などにタイトル通りのものを設定して, 「内蔵スピーカーは消音だがイヤホンを刺すと自動で音が出るようにしたい」と思うものの, n回忘れて時間を無駄にしがちなのでメモ

@thinkpad x1 yoga

  1. Control Panel
  2. Smart Audio
  3. CLASSIC → MULTI-STREAM

デバイスによってはSmart Audioではなく蟹のAudio Directorを変更すると言った感じ

ところでこの設定に名称はないのだろうか…(googlabilityが低い)

私的WindowsのUnixShell環境(暫定)

OUCC Advent Calendar 2016 - Adventar 二日目の記事にしましたが特にOUCCは関係ありません. 他のadvent二日目の記事を偶然見かけて「いや, 明日やろwww」とか思ったら今日でした. 今日は九条カレンさんの生誕祭が終わってしまったという悲劇的な日です.

Windowsを利用していても, 結局のところUnixShellが必要になる. Anniversary updateでBash on Windowsが追加されるなどWindows上のUnixShell(モドキ含む)の発展が著しいが, ある程度自分用の環境が整ったので簡単にまとめる.

続きを読む

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)となっていた. この循環インポートをなくしたところ実行できるようになった, めでたし. (エラーサジェスト欲しかった…)

キーバインディング暫定まとめ(Win/OSX/Linux)

keyboard

(Linuxに追記アリ 2016/12/3)

独自のキーバインディングを多用する, しないと死ぬタイプの人種のため全ての環境でなにかしらのキーバインディングソフトにお世話になっている. 一段落したため各環境について簡単にまとめておく.

続きを読む

Scala関西Summitでスタッフがscala.collection再入門(改)をしゃべってきた #scala_ks

scala

Scala関西Summitお疲れ様でした. 自分はスタッフとして参加しつつlongで1つしゃべっていました. ひしだまさんの裏だったので1対1とかにならないか不安だったのですが意外と来て頂いたようでありがてぇありがてぇ. 「あれ…タイトルや資料に既視感が…」という方もいたと思うのですが, その通りです. 元々Scala関西勉強会で一度喋ったものなのですが, 委員長のきの子さんの強い要望(?)によりCFPを出して最終的に登壇することになりました. 時間を目一杯使いつつ最後のほうのスライドは端折りましたが実は計画通りです(あまりお行儀は良くないですが…). 「1発表スライド」としてだけでなく「完結した資料」としてまとめておきたかったんです(そのせいで文字も多めになっていたり). タスクに追い込まれれば追い込まれるほど変なところで潔癖症になるタイプ.

※注: 以前の資料と同じようで結構更新しています. 表現が怪しかったり微妙に間違っていた箇所の修正を多数含みます.

最後にどうしても記録しておきたかった名言で〆

Docker in Docker のメモ書き

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と共有される.