ErgoDox EZを買ってみて1週間使った感想

参考にしたページ

購入したきっかけ

キーボードのこだわりはない派だったので、可も不可もないbuffaroあたりやmac pro備え付けのものを使ってましたが長時間使用していて疲れないという触れ込みのkinesisはちょっと気になっていました。(同時に価格的に気軽に試せないかなとも。。。) 色々な所でErgodox EZの噂を聞き、築いていたらポチっていることに

尚、色々とパーツ毎に買えるらしいが不足があって買い足すのもメンドそうなので$295の「ErgoDox EZ Bundle: Blank」に

到着まで

注文後にキースイッチをどれにするかメールで聞いてくるので公式サイトに「Quiet, great for office use.」を掲載されていたBrownにした。

5/2に注文して5/16に届いたので2週間。

自分の場合はUPSの配達だったが不在だったので不在票に書かれていた電話番号に連絡したら簡単に再配達の手配(再配達はヤマト運輸だった)をしてもらえた。

物理的な使用感

  • コネクタ・アクセサリについて

    • 余計なパーツがなく、リストレストも本体の形状に合わせて作ってあることもありしっくり来たので「ErgoDox EZ Bundle: Blank」を選んで正解だった
    • USBが若干長めなのでデスクトップ用途でもラップトップでも丁度良く、追加購入する手間が省けた
    • キーボードの高さを調整できるパーツが金属製でしっかり作ってあった。最初、調整に六角の金具が必要かと思ったが、指で締めただけでも安定しているので自分にとってはデメリットではなかった
    • 会社でmac proをマジックトラックパッド2と使用しているのでUSBポートが足りず、USBハブを使うことになった。欲を言えばカスケードできるポートが付いていたらと思った。
  • キーボード使用感

    • レイヤ機能(特定キーで全てのキーマップを変えられる)はまだ有効に使えておらず。とりあえず、キーマップに試行錯誤中
    • 打鍵感は正直高級キーボードを使ったことがあまりないので、あまり良くわからないがストロークも有り、不快感はない
    • 打鍵音はBrown(「Quiet, great for office use.」)を選んだはずだがオフィスだと若干大きいかも

キーマップ

正直一番好き嫌いが別れるのがこのキーマップだと思う。デフォルトだと特に記号が謎のキーマップなので自分にとっては超絶使いづらかった。
もちろんErgoDox Ezは全てオープンソースツールも充実している。macを持っていれば慣れれば1,2分でキーマップを再構成させることが可能。
(尚、キーマップ変更で最初に詰まったのは物理リセットボタンが深すぎて押せない所、コンビニで売っているゼムクリップを伸ばして使うのが最適解だと思う)

現状は、このようなキーマップに落ち着いている(というかだいぶ変更している)

hiracy/qmk_firmware

f:id:hiracy:20160526181711p:plain

f:id:hiracy:20160526181720p:plain

  • Shift,Ctrl,Alt,Cmd,かな、英数をmac pro USキーボードの場所っぽくした
  • Escapeキーはvimでよく使うので右手親指で
  • 十字キー、マウス機能をホームポジションで使えるようにした。(正直マウス機能はあまり使ってない)
  • 記号全般のキー配置がイケてないので、レイヤ2でUSキーボードの場所っぽくした。(これはまだ試行錯誤中)
  • 脳が追いつかなくなるので?レイヤ3は使わない予定

1週間使った感想

左右分離+ポジション調整できるキーボードになっただけでも長時間使用時の疲労は減った気がするが、キーマップがどうカスタマイズしても特殊にならざるを得ないので慣れるまでは相殺されている気がする。
あと、慣れたらもう通常のキーボードが苦痛で使用できない気もするので(特にキーマップ弄ったら)ある程度このキーボードと心中する覚悟が必要かも。

gemを作った時に複数サーバにRundockでシュッとインストールする

概要

gemのツールを作った時、bundle exec rake releaserubygemsにアップロードしてからツールを使う複数のサーバにインストールする際、わざわざAnsibleやChefといった構成管理を使うのも面倒臭かったで、RundeckにビルトインのRake Taskを実装して、使ってみた時の知見

前提

既にbundle exec rake releaserubygemsにアップロードできる環境があるものとします

準備

  • gemspecファイルに以下の1行を追加
spec.add_development_dependency 'rundock'
  • Rakefileファイルに以下の1行を追加
require 'rundock/gem/tasks'
  • パッケージをインストールして確認
$ bundle install
$ bundle exec rake -T
  • 以下の行が表示されればok
rake rundock                   # Run rundock with default configuration
rake rundock:do                # Run rundock with scenariofile.(env:SCENARIO_FILE_PATH)
  • インストール先の設定に以下のようなYAMLファイルを用意します(他にも色々したい場合、仕様はこちら)
# ホスト毎にタスク実行の流れを書く
- target: client-01
  task:
    - gem_install
- target: client-02
  task:
    - gem_install
---
# インストールしたいサーバのsshログイン情報
# sshオプションのport,user,keyは省略可能
client-01:
  host: 192.168.1.11
  ssh_opts:
    port: 22
    user: anyuser
    key: "~/anyuser/id_rsa_any"
client-02:
  host: 192.168.1.12
  ssh_opts:
    port: 22
    user: anyuser2
    key: "~/anyuser/id_rsa_any2"
---
# タスク(gemのインストールの実処理の配列)
gem_install:
  command:
    - "echo \"start: `hostname`\""
    - "sudo gem install <your gem name>"

実行

$ bundle exec rake release
$ bundle exec rake rundock

成功すれば以下の様な結果になるはず

start: client-01
Fetching: your_gem-x.x.x.gem (100%)
Successfully installed your_gem-x.x.x
1 gem installed
start: client-02
Fetching: your_gem-x.x.x.gem (100%)
Successfully installed your_gem-x.x.x
1 gem installed

RundockというYAMLベースな構成管理ツールを作ってみた

f:id:hiracy:20150925222611p:plain

RundockというYAMLベースな構成管理ツールを作ってみました

github.com

※以降NGワード
Ansible

経緯

以前からChef(Chef-Solo) や itamae といった構成管理ツールを使っているのですが、複数サーバにおける即時実行管理までサポートしてないので他のツールを選定していたのと、現在選定の結果として使用している Rundeck というsshベースの構成管理ツールの弱点をなんとかしたいと思い、軽い気持ちで車輪の再発明してみました。

前提

AWSやオートスケーリングに対応した環境を前提に考えるとcloud-initやrc.local、最近ではTerraformを使用してプロビジョニングするほうがスマートではあるので、sshでログインして管理したほうが都合が良い混み入った事情があるレガシーな環境やアドホックにちょっとしたサーバの情報を収集、設定をする用途に限定されます。

解決したかった点

複数の環境の異なるサーバに対してアドホックに任意の構成管理の処理を実行することと実行結果をトレースできること。
この点ではRundeckでそれをほぼ満たしていると思っているのですが、唯一実行計画をYAMLXML等のテキストファイルでバージョン管理し辛いことが不満でした。*1

設計思想と利用させて頂いたOSS

設計思想としてはUNIX哲学である”一つのことをうまくやれ”に従い、"複数以上の環境への実行管理"に特化しており、環境の取り扱い(backend)と実行の内容(operation)は全てプラグインにすることを目指しています。*2
backendについては現在mizzy氏のspecinfraを利用させて頂いております。
また、実装について多くの箇所でitamaeを参考にさせて頂きました。(特にログ周り)

実行例

インストール

$ gem install rundock

プラグインは"rundock-plugin-[プラグインタイプ]-[プラグイン名]"の命名規則のgemパッケージを判別して自動でロードされます

$ gem install rundock-plugin-operation-itamae

実行に必要な設定ファイル

itamae用

  • nginx.rb
package 'nginx' do
  action :install
end

service 'nginx' do
  action [:enable, :start]
end

template "/var/www/html/index.html" do
  source "/tmp/index.html.erb"
end
  • index.html.erb
<%= node[:name] %>

Rundock用
Rundockでは"---"で別れたドキュメントのYAMLを使います。(ドキュメント毎に別のファイルを指定することも可能)

  • scenario.yml
- target_group: hiracy-dev
  command: hostname
  itamae:
    - /path/to/nginx.rb                   # recipe files
    - sudo: true                          # itamae --sudo option
    - node_json: /path/to/attr.js         # itamae --node-json option
                                          # you can use itamae any options here
---
hiracy-dev:
  target_type: group
  targets:
    - hiracy-dev-01
    - hiracy-dev-02
hiracy-dev-01:
  host: 192.168.10.121            # specify ssh options(Net::SSH options compatible)
  ssh_opts:
    port: 22222
    user: hiracy_01
    key:  ~/.ssh/id_rsa_hiracy_01
hiracy-dev-02:
  host: 172.16.10.122
                                          # use ssh_opts by ./default_ssh.yml

詳細はwikiのほうを見て頂きたいのですが、"itamae ssh"とオプションをYAMLファイルの中で指定しています。
また、"command"という項目を見て分かる通り、単純なコマンド実行をデフォルトでサポートしています。

実行

$ rundock do /path/to/your/scenario.yml

--dry-runオプションを付けることで実際には実行せずにログ出力だけすることが可能です

$ rundock do /path/to/your/scenario.yml --dry-run

フック

ノードやグループ単位の実行後にフックを仕掛けることも可能です。こちらも全てプラグインにしています。
サンプルとしてSlackに実行後のログを送るプラグインを使ってみます。

$ gem install rundock-plugin-hook-slack
  • scenario.yml
- target_group: hiracy-dev
  command: hostname
  itamae:
    - /path/to/nginx.rb                   # recipe files
    - sudo: true                          # itamae --sudo option
    - node_json: /path/to/attr.js         # itamae --node-json option
                                          # you can use itamae any options here
  hook:
    - hook_slack
---
hiracy-dev:
  target_type: group
  targets:
    - hiracy-dev-01
    - hiracy-dev-02
hiracy-dev-01:
  host: 192.168.10.121            # specify ssh options(Net::SSH options compatible)
  ssh_opts:
    port: 22222
    user: hiracy_01
    key:  ~/.ssh/id_rsa_hiracy_01
hiracy-dev-02:
  host: 172.16.10.122
                                          # use ssh_opts by ./default_ssh.yml
---
# task section(no use in this case)
---
hook_slack:
  hook_type: slack
  token: xxxx-9999999999-999999999-99999     # token argument(required)
  channel: my_channel                        # channel argument(required)
  username: rundock-bot                      # username(optional)
  icon_url: http:/hiracy.org/rundock-bot.png # icon_url(optional)

実行

$ rundock do /path/to/your/scenario.yml

f:id:hiracy:20150926231549p:plain

課題

Rundeckの場合だと実行履歴の検索・フィルタリングが優れているので保管するプラグインを作ってみてもいいかもしれない。
後はYAMLファイルを再利用してtmuxでコンソールを直接開く機能は良いと思いますね。

最後に

A○sibleFabricに不満がありましたらこちらにプルリク送ってみたりプラグイン作成してみてはいかがでしょうか!!!

*1:実行計画はXMLに出力可能なので作りこめば実現は可能

*2:backendのプラグインは未対応

Linuxでサマータイムが切り替わる瞬間について

海外向けのサービスのためにLinuxサマータイムのある地域のタイムゾーンを設定することもあるかと思いますが、サマータイムに切り替わる瞬間にどうなるのか気になったのでちょっと試してみました。

[条件]

  • dateコマンドでPST(太平洋標準時)がサマータイムに入る/戻る瞬間
  • 環境:CentOS6.4 Kernel: 2.6.32-358.el6.x86_64
  • 実行方法:一時的に時間変更した後、watchコマンドで1秒毎に経過監視

[サマータイムに入る瞬間]


[サマータイムから戻る瞬間]

この通り 2015年のサマータイムにて PST(太平洋標準時)からPDT(太平洋夏時間)にかけてdateコマンドの結果取得が瞬時に切り替わることがわかります。 もちろんdateコマンドの表示フォーマットを変えても同じ結果となります。

phprubyといったプログラム言語で時間取得していた場合はどうなるでしょう

続きを読む

SSL証明書が切れたと思ったら別の原因で通信できなかった件

Vagrant にていつもの通りCentOS上でサーバ構築するためにbundle install実行したらこんなエラーメッセージが表示されました。

Gem::RemoteFetcher::FetchError: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (https://rubygems.global.ssl.fastly.net/gems/diff-lcs-1.2.5.gem)
続きを読む

ITインフラ 業務自動化現状確認会で発表してきました

2014/10/7 ITインフラ業務自動化現状確認会で発表して参りました!!

続きを読む

CentOS5からCentOS6へ移行する際にサーバ構築でハマりそうな箇所のメモ

最近CentOS5系からCentOS6系にシステムを移行する機会がありましてその時サーバ構築でハマりそうになった箇所のメモです webサービスで利用するための最小限の構成なので用途によっては他のハマり所があると思うので悪しからず

  1. yum groupinstall のパッケージ内容の違い
  2. bashバージョンアップによるシェルスクリプト正規表現判別文法の違い
  3. resolv.confの"options single-request-reopen"対応
  4. sysctlのip_conntrackからnf_conntrackへの名称変更
  5. NetworkManargerのoff
  6. ユーザ毎のプロセス数制限デフォルトポリシーの変更
続きを読む