読者です 読者をやめる 読者になる 読者になる

「いいちこ棒」という謎の仕組みで GUGEN に展示します

gugen.jp

GUGEN というハードウェアコンテストに今年も応募しています。 無事、第1次審査は通過し(する自信はありましたが!)、本戦に進めました。

詳細は、プレスリリース をご覧いただければと思います(RBBTodayさんにも記事にしていただきました)。

GUGEN は昨年も2件だし、2件とも!予選を通過したので本戦で展示して、他の方々の展示も見ましたが 世の中は広いもので、どうでもよいものから、役に立ちそうなもの、ビジネスになりそうなものまで広くモノを作られているのが見えて面白かったです。

昨年の展示で私が一番印象深かったのが「恋のビビビを電気のビビビに!『ビビビコントローラー』」でした。

大きなディスプレイに映る女の子に向き合い、女の子が可愛らしくハートに来るセリフを行ったときに心拍の変化を検知(ほんとうかなぁ?)し、 割りとガチで「イラッ」とするほどの電気でしびれる、本当にどうでもよい(褒めてる)デバイスです

で、この記事で言いたいことは、秋葉原で12/17(土)に本戦があるので、ぜひ、見学に来て、いいちこ棒を応援してください、ということです。 よろしくお願いいたします

いいちこ

いいちこ棒は、イベンター・イベントに参加のお客様に対して「With Us, You Can」を実現すべく 弊社のエンジニアのデバイス班、アプリ班と広報部隊が協力して開発しました。

電子回路の一部は某所にお願いして設計しましたが、その回路のデバッグや検証などは完全に内部で行いました。 余談ですが、デバッグ用回路がバグっていたり、端子が間違っているなどもコツコツとテスタで確認して、発見・修正案の提案までしています。 (割りと漏れが合ったので、オフショアむずいなぁと思ったりゲフンゲフン)

ダッシュボードのフロントエンドも企画サイドの * サーバ費用持ちたくない * 運用もしたくない というニーズにお答えして、拙作の MQTTPress を導入して実現しました(もちろん、とはいえ、 MQTT はどこかでかりるのですが、誰かがマネージしてくれている)

speakerdeck.com

フロントエンドのUIも実際のイベンター様の声を聞きつつ、修正を重ね(これからも可能な範囲で手を入れていく予定)て作ったもので、「なるべくわかりやすく」「良く使う機能(3択とかYes/Noなど)」はすぐ作れる」などの改善が加えられています。

現時点では投票に特化していますが、回路/デバイス的にはもっともっと豪華な機能を詰め込めるようには作ってあるので、今後、よりエンターテイメントに向けたりもできるかと妄想しています。

おまけ

手が汚いので撮り直し・動画作り直しさせられたんですが、GUGEN の方もお忙しいのか、変更がないので、社内 Slack で「写真変わらないままだ」とか dis られてますが、僕は元気です

Docker Privileged でできること

訳そう訳そうと思いつつ放置していたのを訳す

  • docker 1.9.0 build 76d6bc9
Runtime privilege and Linux capabilities
--cap-add: Add Linux capabilities
--cap-drop: Drop Linux capabilities
--privileged=false: Give extended privileges to this container
--device=[]: Allows you to run devices inside the container without the --privileged flag.

Note: Docker 1.10 以上では、 --cap-add がコンテナに渡されたかどうかにかかわらず、デフォルトの seccopm profile が syscall をブロックします。このような場合は、用意されているデフォルトのものをベースにご自身でカスタムした seccomp profile を作成することをオススメします。そうでなく default で起動したくないのであれば、 --security-opt=seccomp=unconfined を渡して起動してください。

デフォルトでは、 Docker コンテナは "unprivileged" であり、例えば、 Docker コンテナ内で Docker daemon の起動を行うことができません。これは、デフォルトではコンテナがあらゆるデバイスへのアクセスが許されていないためです。しかし、 "privileged" なコンテナはすべてのデバイスへのアクセスが許可されます (see the documentation on cgroups devices)。

docker run --privileged を実行したすると、 AppArmor や SELinux で設定するのと同じように、コンテナ以外のホスト上のプロセスとほとんど同じレベルでホストへのアクセスを許可するように、そのホストのすべてのデバイスへのアクセスが可能になります。 --privileged での起動についての付与的な情報は Docker Blog で確認してください。

もし、特定のデバイスへのアクセスを制限したければ、 --device フラグを利用できます。コンテナ内からアクセス可能な1つ以上のデバイスを指定することができます。

$ docker run --device=/dev/snd:/dev/snd ...

デフォルトで、コンテナはこれらのデバイスに対して readwriteおよびmknod が可能です。--device フラグのそれぞれのオプションに対して 3つぐみの :rwm を用いることで上書きすることができます。

$ docker run --device=/dev/sda:/dev/xvdc --rm -it ubuntu fdisk  /dev/xvdc

Command (m for help): q
$ docker run --device=/dev/sda:/dev/xvdc:r --rm -it ubuntu fdisk  /dev/xvdc
You will not be able to write the partition table.

Command (m for help): q

$ docker run --device=/dev/sda:/dev/xvdc:w --rm -it ubuntu fdisk  /dev/xvdc
    crash....

$ docker run --device=/dev/sda:/dev/xvdc:m --rm -it ubuntu fdisk  /dev/xvdc
fdisk: unable to open /dev/xvdc: Operation not permitted

--privileged に追加して、--cap-add および --cap-drop を使うことで、capability をより適切な粒度で制御することができます。デフォルトでは、 Docker は 下記の利用可能性を保持しています。下記のテーブルに追加や削除が可能な Linux capability options を記載します。

Capability Key Capability Description
SETPCAP process capabilities の変更
SYS_MODULE kernel modules のロードまたはアンロード
SYS_RAWIO I/O port の操作(iopl(2) and ioperm(2)). USB message とか
SYS_PACCT acct(2) を使って, process accounting on or off のスイッチが可能
SYS_ADMIN System Admin の操作範囲の実行
SYS_NICE プロセス nice 値 (nice(2), setpriority(2)) を上げる、および 任意のプロセスの nice 値の変更
SYS_RESOURCE リソース制限の上書き.
SYS_TIME System clock (settimeofday(2), stime(2), adjtimex(2)) の設定; real-time (hardware) clock の設定
SYS_TTY_CONFIG vhangup(2) の実行; employ various privileged ioctl(2) operations on virtual terminals.
MKNOD mknod(2) を利用して special files の作成
AUDIT_WRITE kernel auditing log への records の記載
AUDIT_CONTROL kernel auditing の有効化/無効化; auditing filter rules の変更; auditing status と filtering rules の取得
MAC_OVERRIDE MAC configuration の許可または state の変更. Smack LSM で実装されている
MAC_ADMIN Mandatory Access Control (MAC) の上書き. Smack Linux Security Module (LSM) で実装されている.
NET_ADMIN various network-related operations の実行
SYSLOG privileged syslog(2) operations の実行
CHOWN file UIDs and GIDs (see chown(2)) の任意の変更
NET_RAW RAW と PACKET sockets の利用
DAC_OVERRIDE file read, write, and execute permission check のバイパス.
FOWNER Bypass permission checks on operations that normally require the file system UID of the process to match the UID of the file.
DAC_READ_SEARCH ファイル読み込みおよび直接読み込みと実行の権限チェックのバイパス
FSETID ファイルが修正された時に set-user-ID と set-group-ID の権限ビットをクリアしない
KILL シグナル送信の時に権限チェックをバイパスする
SETGID プロセス GID および 補助 GID の任意の操作
SETUID プロセス UID の任意の操作
LINUX_IMMUTABLE FS_APPEND_FL and FS_IMMUTABLE_FL i-node flags の付与
NET_BIND_SERVICE 特権ポートでのインターネットへのソケットの利用
NET_BROADCAST broadcast ソケットの作成とマルチキャストへの listen
IPC_LOCK Lock memory (mlock(2), mlockall(2), mmap(2), shmctl(2)).
IPC_OWNER operations on System V IPC objects の権限チェックのバイパス
SYS_CHROOT chroot(2), change root directory の許可
SYS_PTRACE ptrace(2) を利用した任意のプロセスの trace
SYS_BOOT reboot(2) and kexec_load(2) を利用して reboot と新しいカーネルのロード load
LEASE 任意のファイルのリース Establish (see fcntl(2)).
SETFCAP file capabilities のセット.
WAKE_ALARM システム起動に対してトリガーを送る
BLOCK_SUSPEND block system をサスペンドさせるような機能を適用する

より詳細なリファレンスは capabilities(7) - Linux man page で御覧ください。

(--cap-add / --cap-drop)両方のフラグの値として ALL をサポートしているので、例えば、 MKNOD 以外のすべての権限を付けたい場合は、下記のようにすることが可能です。

$ docker run --cap-add=ALL --cap-drop=MKNOD ...

ネットワークスタックを操作するのであれば、 --privileged ではなく、 --cap-add=NET_ADMIN として、ネットワークインターフェイスを変更するべきでしょう。

$ docker run -it --rm  ubuntu:14.04 ip link add dummy0 type dummy
RTNETLINK answers: Operation not permitted
$ docker run -it --rm --cap-add=NET_ADMIN ubuntu:14.04 ip link add dummy0 type dummy
To mount a FUSE based filesystem, you need to combine both --cap-add and --device:

$ docker run --rm -it --cap-add SYS_ADMIN sshfs sshfs sven@10.10.10.20:/home/sven /mnt
fuse: failed to open /dev/fuse: Operation not permitted
$ docker run --rm -it --device /dev/fuse sshfs sshfs sven@10.10.10.20:/home/sven /mnt
fusermount: mount failed: Operation not permitted
$ docker run --rm -it --cap-add SYS_ADMIN --device /dev/fuse sshfs
# sshfs sven@10.10.10.20:/home/sven /mnt
The authenticity of host '10.10.10.20 (10.10.10.20)' can't be established.
ECDSA key fingerprint is 25:34:85:75:25:b0:17:46:05:19:04:93:b5:dd:5f:c6.
Are you sure you want to continue connecting (yes/no)? yes
sven@10.10.10.20's password:
root@30aa0cfaf1b5:/# ls -la /mnt/src/docker
total 1516
drwxrwxr-x 1 1000 1000   4096 Dec  4 06:08 .
drwxrwxr-x 1 1000 1000   4096 Dec  4 11:46 ..
-rw-rw-r-- 1 1000 1000     16 Oct  8 00:09 .dockerignore
-rwxrwxr-x 1 1000 1000    464 Oct  8 00:09 .drone.yml
drwxrwxr-x 1 1000 1000   4096 Dec  4 06:11 .git
-rw-rw-r-- 1 1000 1000    461 Dec  4 06:08 .gitignore
....

Ansibrest というツールを作りました

ものすごい久しぶりに記事を書く。理由は気がつかないままに bang されてたから (stanaka さん, daiksy さん, songmu さんありがとうございます)

掲題の通り Ansibrest というツールを作った

  • github
  • 最近のプロダクトでは ansible をほぼ全面的に使ってる
  • チーム的にもうちのチームはほとんどが ansible に移行した(利用し始めた)
  • 遅まきながらようやく chatops 環境が整いつつある(この辺りは情報解禁されたらどこかで書きたい)

Ansible はとてもよいツールなので積極的に使っていきたいけど、結局どこかの端末にログインしてコマンドを実行するか、 Jenkins おじさんの手をわずらわせるかしないといけない。 slack とかで利用するときも直接叩くなんてことはなく実際には jenkins おじさんに頼んで ansible を実行してもらう。

かといって jenkins おじさんを定常的に育てるのは手間でもっとカジュアルに ansible を叩きたいと思ったので ansibrest 作った。 やれることは単純でプロダクトのリポジトリ内に次みたいな構成で ansible playbook があるとする

% tree -L 2 ansible                   
ansible
├── group_vars
│   └── development.yml
├── inventories
│   └── development
├── roles
│   └── sample2
├── sample1.yml
└── sample2.yml

この状態で

% npm install ansibrest -g

としたのち

% ansibrest 

とするとデフォルトでは2400番でWebサーバが立ち上がる。

キャプチャを見ればわかると思うけど、 playbook の一覧、それぞれの playbook のタスク一覧と inventories の設定を閲覧できて、その場で実行ができる。

  • トップ f:id:muddydixon:20160308004640p:plain

  • 実行 f:id:muddydixon:20160308004704p:plain

  • playbook タスクリスト f:id:muddydixon:20160308004720p:plain

あと、当然これは API を持っている。

% curl -X POST "http://localhost:2401/api/playbook/sample2.yml"

こんな感じで叩くことができる。

としておけば op サーバあたりで git clone して、 ansibrest を上げておけば、 hubot から簡単に実行できる。

カジュアルにチーム皆の(slackの)前で

@repo_hubot play sample2.yml development

とか実行することができる(はず

残項目

  • playbook は通常、結構時間がかかるので、ウェブから実行する場合には stream / websocket にしたいところ(hubotの場合はなんか進捗的なやつを定期的に処理できるようにするか)
  • sshの鍵とかそういうのの管理ができない
    • これはしないほうがいい気もする
  • ansible ini フォーマットと yaml が混ざってるし、 playbook 作る人によって書き方違うのでアレなのどうしたらいいのか

エンジニアのためのデータ可視化実践入門 の訂正

今年のはじめに「エンジニアのためのデータ可視化実践入門」を出版しました。 私の不手際で多くの方にご迷惑をお掛けしました。

遅くなってしまいましたが、その中でもソースコードを確認する時間を十分に確保できなかったために 多くの間違いがございました。

共著者のあんちべ様はじめ、レビューしてくださった皆様とは無関係の私の責任です。 購入してくださった皆様、申し訳ありません。

下記サポートページで訂正しております。 サポートページ:エンジニアのための データ可視化[実践]入門 ―D3.jsによるWebの可視化:|技術評論社

下記のリポジトリに実際に動作するコードをすべて置きました。

muddydixon/WebVisualizationSample · GitHub

お世辞にも素晴らしいコードではありませんが、よろしければご参考ください。

また、CoffeeScriptで書かれていることにも言及されておられる方がおりましたが、 この目的は、共著者の方と相談し、なるべく安価な値段設定にできるようにとも 考え、どうしても増えると考えられたソースコードの記述量を減らすために用いたものです。

今後、このような機会をいただけた際には、自分自身で行うだけではなく、 お願いする方にはお手数おかけするかもしれませんが、コード自体のより十分な レビューをお願いし、対応したいと思います。

家庭を支える技術アドベントカレンダー 14日目(ごめんなさい

家庭を支える技術 Advent Calendar 2014 - Adventar

数日、夫婦の家庭が続いたので、子どもがいる家庭について多めに書いてみます。

スペック * 妻 * 子(年長) * 子(年少)

夫婦間のコミュニケーションツール

  • Google Calendar
    • 幼稚園の行事の共有は大事
    • 習い事の予定の共有は大事
  • Google Spread Sheet
    • 年賀状やお歳暮を送る。最近はネットで年賀状が便利
    • スマホで見られるので、不意に何か贈ろう!と思った時にも便利
  • Line
    • 帰るコールなどはこちらで

子どものデータ

  • 外付けHDD/メモリースティック: データぶっ飛び2回
    • 1回目8GBで10万近い金額
    • 2回目250GBで見積もり怖くて出してない) 1人目の出産時動画・・・どうしよう
  • flickrのプロ契約で対応(解像度下がっても見られないよりまし
    • 依存度が高すぎて困る
    • アップロード時間かかりすぎ
    • 選択ダウンロードのUIへぼすぎ

子どもへのデータ

  • ChromeCast
    • 映画とかビデオを見せるのにとても良い
    • motownのplaylistとか流しっぱなしでレゴやったりもしてます
  • Kano
    • キーボードの刻印が大文字のみ、「次をタイプしろ」という表示は「小文字」で、子どもは探せない
    • 4歳時が「startx」を打った時にちょっと感動した

f:id:muddydixon:20140927100608j:plain

その他、非IT技術

うちがいっている幼稚園は、小規模幼稚園なので保護者の協力が不可欠で、大変ですが楽しいです。 また、マンションもマンモスマンションなので同年代がだいたい30人近くいるのでそこのコミュニケーションも多く、こちらもなかなか円満な関係を築いていて楽しいです。

餅つき

30臼とかを15人位のお父さんたちでつききるので体力まじ大事。あと、手返しができる(うまい)ヒトも希少価値があります。

f:id:muddydixon:20141130102236j:plain

行事もの

行事ごとに「あれ作れ」「これ作れ」と言われるのですが、子どもたちが喜ぶのであればと思ってシコシコ作っています

f:id:muddydixon:20141007022915j:plain

家事

  • 料理: なんだかんだで平日一日中子どもたちの相手をしている妻に代わって、土日料理を作ったりすることが多いので、料理スキルは大事です。
    • 小松菜をどう食べさせるか→ミキサーに掛けてパスタのソースに
    • ほうれん草をどう食べさせるか→餃子の皮にねりこむ
    • ごぼうをどう食べさせるか→ボロネーゼにしてパスタのソースに
    • 魚をどう食べさせるか→子どもたちにはあえて与えず、僕が美味しそうに食べ始めてから味見させ、一人前食べさせる
      • あいつら、ちゃんと出すと食べないくせに、ヒトが食べだすと取りに来る

レゴ

レゴを始めると子どもたちは1〜2時間遊んでくれるので、こちらも作りがいがあります。

f:id:muddydixon:20141214105553j:plain

地域とのコミュニケーション

  • 幼稚園の連絡手段がメーリングリスト(広告入り)なので、なんとかしたい
  • 地域の人とは、FBグループ/LINE/メールなのでなんとかしたい
  • 幼稚園お父さんたちとも仲がいいととても楽
    • 仕事関係ない友だちができて楽しい
  • マンションのお父さんたちとも仲がいいとても楽
    • 仕事関係ない友だちができて楽しい

欲しいガジェット

Chipolo :: Nothing Is Lost

やってみたい

これが次世代の砂遊びか……! 本物の砂を使うセガのアーケードゲーム「え〜でる すなば」が面白そう - ねとらぼ

まだ早いですが子どもの小遣いはこうやりたい

鉄道系電子マネーを利用した子供のお金管理が便利な件 - ベンチャー役員三界に家なし

mackerel meetup #2 に参加しました

mackerel meetup #2に参加しています

Mackerel Current Status @stanaka

  • Overview & Update
  • 正式化と今後の予定

Overview & Update

監視

  • ホスト/ロール単位:来月そうそう
  • サービスメトリクス:来月早々

アラート通知(チャンネル)

  • メール
  • Webhook
  • sladk 来週くらい

正式化と今後の予定

  • ベータリリース(5/8)
  • 正式リリース(9/19)

  • 2000円/ホスト/月(台数20+でディスカウントあり)

  • 無料トライアルあり

    • 5台, ログ24h, サービスメトリクス・監視数に制限
  • 個人・小規模ユーザ向けプラン

  • GitHubログイン
  • Monitor対象の詳細化(ロール単位)
  • サービスメトリクス監視
  • カスタムメトリックプラグイン拡充
  • Slack連携など通知先拡充

イベント機能

  • アラート・デプロイなど
  • グラフ改善
  • アラート改善
  • ダッシュボードカスタマイズ

ヌーラボがMackerelに移行した3つの理由 @tksmd

まとめ

id:stanaka さん, id:songmu さん、はじめhatenaの皆様、会場のフリークアウトの皆様ありがとうございました!

Travis CI Meetup Tokyoに参加しました

Travis CI Meetup Tokyo

Hiro Asari さんの Travis CI の demo

Travis-CI のライフサイクル

Setup -> Services
 |
 v
before_install
 |
 v
install
 |
 v
before_script
 |
 v
script
 |
 v
after_success   after_failure
 |                    |
 v                    |
 before_deploy        |
 |                    |
 v                    |
 after_deploy         |
 |                    |
 v                    v
after_script

.travis.yml

# build地にsudoを利用しない設定
sudo: false # アカウントに依存して、通常は動かない設定

language: ruby

bash の wait というオプションで標準出力がない場合に殺されないで済む

110+ vms 68+ servers heroku

openvz and docker

82000 jobs 125,435 jobs per day 7,000 repositories

|node.js | 2800| | python |1900| | ruby |1600| |php| 1500| |default (=ruby)|1000| ...

in COM, ruby is top usage.

team

  • team teal: ui ux
  • team blue: infrastructure
  • BIWOMM but it works on my machine

points

  1. Case sensitive
  2. inode deference
  3. Package difference dev and travis CI
  4. Services which are slow to start or configured differently
  5. 'apt get update' system packages change and are removed overtime
  6. test ordering and isolation
  7. time zone dependent test and timing differences
  8. capabilities turned off in container based virtualization systems

tachikoma.io

  • 依存関係とかのチェックを実現する

travisselenium

  • travisならxvfbもfirefoxjavaも入ってる!
  • screenshopを撮るAPIもある!→エクセルの証跡も作れる!