nmcli で隠されたSSIDに接続する

1

nmcli device wifi connect "essid" password "password" hidden yes private no

nmtuiだとできないっぽい。

Trailblazer::Tokyo #1

昨日、Trailblazer::Tokyo #1 という勉強会を主催しました。

apotonick先生 Trailblazer の勉強会でした。

数ヶ月前に僕がたまたま Trailblazer本 を読んで以来 Trailblazer の思想に夢中になっていて、 色んな所ですごいすごい言っていたんだけどいまいち伝わっていなくて、今回の勉強会で自分が感じている「すごい」をほかの人にも伝えられてよかった。

3週間ほど前、たまたま飲みに行った @yuukigoodman に Trailblazer の話をしたら 次の日くらいから彼の TL に Trailblazer の文字が流れていて意識の高さに驚いて、僕も嬉しくなって勢いで勉強会開いた。 やってよかったと思う。

急な勉強会の開催にもかかわらず会場の提供と発表をして頂いた @yuukigoodman に圧倒的感謝！！ Trailblazer::Tokyo というRubyの名前空間っぽいイベント名前も @yuukigoodman のアイディアでした。 とても Trailblazer らしい良い名前だと思います。

自分の発表資料

雑感

勉強会は発表だけだと時間が余る気がして、座談会みたいな感じでやりたくて、わりと参加者から質疑応答がたくさん出たのでいい感じに話ができてよかった。 やはり業務で使うにはどうするかをイメージしてみんなはなしを聞いたり考えたりしていたようで、 それは僕も同じで自分が今仕事で実践している話ができたのも具体例を示せてよかったように思う。 あと、会のはじめにチェックインとして自己紹介してもらったのも、話しやすい空気を作れたんじゃないかなぁという気がする。

ここ数年間、というか社会人になってから、ずっとLTしかして来なかったので、人前で長い時間発表するのは久しぶりで 発表中は自分の説明が伝わっているかどうか少し不安になりながら発表していた。 でも終わってみると、 Trailblazer をプラスに捉えてくれる人が多くてよかった。

Trailblazer は小さく作られているのでフルセットで入れなくても導入できるし、 Rails への依存も極力抑えられているというのが伝えられたので満足している。

Trailblazer::Tokyo は今後も Ruby コミュニティのひとつとして活動していきたい。 (僕が東京を離れる可能性がちょっと高いけど)

Trailblazer::Tokyo #2 では実際に Trailblazer を使ってアプリ開発をした話ができる(or 聞ける)といいなぁ。 月1で開催してもちゃんとした話題になるような活動ができる気がしないけど、半年に一度だと熱が冷めそうでやだなあ。 3ヶ月に1度くらいがいいのかなぁ。

最近知った gem まとめ

model や DB 周り

• kakurenbo-puti 論理削除
• phony_rails 電話番号を処理するgem
• validates_overlap 時間の期間に対するバリデーションを書ける (start_at と end_at が重複しないようにするとか)
• geocoder DB中で位置情報を扱うためのgem。 google map などへのクライアントとしての機能もある。
• counter_culture カウンターキャッシュ。Rails の counter_cache との違いは http://qiita.com/kanekomasanori@github/items/8155dff193e961828d02

seedデータの投入

• seed_fu seed を複数にわけられる
• seedbank 優先度をつけて seed を実行できる
• flextures CSV か YAML を元にして fixture を読み込む。FactoryGirl のようにテスト中でデータにアクセスできる。

API やコントローラ周り

• rails_param controller でパラメータの簡単なバリデーションを書くためのDSLを提供する gem
• gaffe ramblance と同系統のgem. ramblanceと違い、エラー用のコントローラを提供するようだ

HTML やテンプレート周り

• html-pipeline MarkdownやSyntaxHighlightのパースをまとめて行える
• gakubuchi 静的なHTMLでassets pipelineを使えるようにするgem
• high_voltage 静的なHTMLをRailsの中で作るgem。routes と view だけ定義する感じ

Test 、 Development

• gimei Faker をより日本語に特化したようなもの
• vcr 一度アクセスしたhttpをyamlでキャッシュするgem。 webmock と合わせて使うと良い
• view_source_map 開発環境でHTMLソース中にパーシャルのファイル名を入れる
• airborne JSON を扱う API のテストを書きやすくする RSpec 用の gem

その他

• rack-cors Cross-Origin Resource Sharing のためのgem
• ransack 検索条件やorderを手軽に提供するgem

過去の記事のアーカイブ

Rails routes について

• Rails3 routes.rb まとめ
• Rails Guides - Rails Routing from the Outside In

resources について

基本的な 7 つのルーティングを作成する。

1
2
3
4
5
6
7
8
9

resources :photos

# GET       /photos                 index        photos_path
# GET       /photos/new             new          new_photo_path
# POST      /photos                 create       photos_path
# GET       /photos/:id             show         photo_path(:id)
# GET       /photos/:id/edit        edit         edit_photo_path(:id)
# PUT       /photos/:id             update       photo_path(:id)
# DELETE    /photos/:id             destroy      photo_path(:id)

resource について

resource は resources に比べて id を伴わず、 index を作らない。 ただし、 controller は複数形にする。

1
2
3
4
5
6
7
8

resource :profile

# GET        /profile/new      new       new_profile_path
# POST       /profile          create    profile_path
# GET        /profile          show      profile_path
# GET        /profile/edit     edit      edit_profile_path
# PUT        /profile          update    profile_path
# DELETE     /profile          destroy   profile_path

プレフィックスについて

namespace を使うと path とcontroller にプレフィックスを付けることが出来る。

1
2
3
4
5
6
7
8

namespace :admin do
  # コントローラは Admin::PhotosController
  resources :photos
end

# GET        /admin/photos      index   admin_photos_path
# GET        /admin/photos/new  new     new_admin_photo_path
# 省略...

次のようにすると controller にのみプレフィックスを付けることが出来る。

1
2
3
4
5
6
7
8
9
10
11
12

scope module: 'admin' do
  # コントローラは Admin::PhotosController
  resources :photos
end

# または
resources :photos, module: "admin"

# path は変わらない
# GET        /photos         index      admin_photos_path
# GET        /photos/new     new        new_admin_photo_path
# 省略...

次のようにすると path のみプレフィックスを付けることが出来る。

1
2
3
4
5
6
7
8
9
10
11

scope '/admin' do
  resources :photos
end

# または
resources :potos, path: '/admin/photos'

# pathが下記のように変わる。 controller は変わらない。
# GET        /admin/photos          index       photos_path
# GET        /admin/photos/new      new         new_photo_path
# 省略...

基本の 7 つ以外のルーティングを追加する場合

member か collection を使う。 member は id あり、 collection は id なし。

1
2
3
4
5
6
7
8
9
10

# GET /photos/:id/preview で preview アクションを呼ぶ

resources :photos do
  member do
    get 'preview'
  end

  # または
  get 'preview', on: :member
end

1
2
3
4
5
6
7
8
9
10

# GET /photos/search で search アクションを呼ぶ

resources :photos do
  collection do
    get 'search'
  end

  # または
  get 'search', on: :collection
end

match と get, post 等について

match は HTTPメソッドを指定せずにルーティングを設定する。

1

match 'hoge' => 'hoges#show'

とすれば http://ホスト名/hoge にアクセスした時に hoges コントローラの show メソッドを呼ぶ。 メソッドを指定するときは

1

matche 'hoge' => 'hoges#show', via: :get

と書くけど、長いので

1

get 'hoge' => 'hoges#show'

でいい。 post , put, delete も同様。

ただし、複数メソッドをつけるときは下記のようにする。

1

matche 'hoge' => 'hoges#show', via: [:get, :post]

パラメータの指定

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# id が必須
match 'photos/:id' => 'photos#show'

# id は省略可能
match 'photos/(:id)' => 'photos#show'

# パラメータに正規表現をかけてチェックすることができる。
# 下記では id が数字の場合のみルーティングを設定する。
# 数字以外の場合ルーティングエラーになる。
match 'photos/:id' => 'photos#show', id: /\d/

# ワイルドカード
#
#   'songs/rock/classic/stairway-to-heaven' sets
#    params[:category] = 'rock/classic'
#    params[:title] = 'stairway-to-heaven'
match 'songs/*category/:title' => 'songs#show'

Linuxでユーザーを特定のグループに追加する

いつも忘れるのでメモ書き。

グループ、ユーザーの一覧表示

• グループの一覧: /etc/group
• ユーザーの一覧: /etc/passwd

追加するとき

usermod でもできるけどこっちの方が余計なこと考えなくて楽

1

# gpasswd -a USER_NAME GROUP_NAME

削除するとき

1

# gpasswd -d USER_NAME GROUP_NAME

参考

• http://kazmax.zpp.jp/linux_beginner/etc_passwd.html#ah_3
• http://www.linux-beginner.com/linux_kihon24.html

Capybaraでブラウザを再起動するステップを書く方法

Cucumber や Turnip 等でセッションやクッキーに関するテストを書くときに、 時々ブラウザを再起動したい時がある。 そのような場合には show_me_the_cookies が便利。

show_me_the_cookies の expire_cookies というメソッドを使うとブラウザを再起動した状態を再現できる。

1
2
3
4

# Turnip のステップの例
step 'ブラウザを再起動する' do
  expire_cookies
end

alsa-tools入れてるのに音が出ない時の対処

ThinkPad x240 に Debian jessie を入れた際、音声ドライバをうまく認識できていなかったらしく音がならなかったので、以下の方法で対処した。

まず /proc/asound/cards で id とインデックスを調べる。

1
2
3
4
5
6

 0 [PCH_1          ]: HDA-Intel - HDA Intel PCH
                      HDA Intel PCH at 0xf0634000 irq 65
 1 [PCH            ]: HDA-Intel - HDA Intel HDMI
                      HDA Intel HDMI at 0xf0630000 irq 66
29 [ThinkPadEC     ]: ThinkPad EC - ThinkPad Console Audio Control
                      ThinkPad Console Audio Control at EC reg 0x30, fw unknown

上記だと id=PCH_1 index=0 となる。 （設定前は id=HDMI index=0 , id=PCH index=1 だったんだけど何故か変わってしまったようだ…）

/etc/modprobe.d/alsa-base.conf の末尾に次を追加。 サウンドドライバとして snd-hda-intel を使うように設定する。

1
2

options snd-hda-intel id=HDMI index=0
options snd-hda-intel id=PCH index=1

参考 https://bbs.archlinux.org/viewtopic.php?pid=1045829#p1045829 https://bbs.archlinux.org/viewtopic.php?id=137653 http://superuser.com/questions/613016/debian-sound-on-hdmi-instead-of-jack http://lists.debian.or.jp/debian-users/201108/msg00070.html https://wiki.debian.org/InstallingDebianOn/Apple/MacBookAir/6-1 https://wiki.debian.org/ALSA

Rails での API 作成について調べた

フレームワーク

• Rails API
• garage
• grape

認証周り

おおまかに次の２つのどちらかになりそう

• emailとパスワードなどでログイン用APIを叩いて、そのレスポンスとしてトークンを発行し、他のAPIを使うときはトークンをHTTPリクエストヘッダーに入れてやりとりする
  • http://lucatironi.github.io/tutorial/2012/10/15/ruby_rails_android_app_authentication_devise_tutorial_part_one/
  • https://github.com/baschtl/devise-token_authenticatable
  • http://qiita.com/k-shogo/items/6d687c38b0f7b3ade6f5#1-6http://qiita.com/k-shogo/items/6d687c38b0f7b3ade6f5#1-6
• OAuthをサーバー側で提供する
  • https://github.com/doorkeeper-gem/doorkeeper
  • https://github.com/iainporter/oauth2-provider

エラーハンドリング

方針として、 Rack層を利用して Rails の外側で行うほうが良さそう。 rescue_from は以前やったことあるけど大変だった。

• rambulance 例外型に応じて動的にエラーとしてrenderするViewを変更するための gem
• Rails の rescue_from で拾えない例外を exceptions_app で処理する ちょっと難点が多そう
• RailsでAPIをつくるときのエラー処理 Rack層の話

テスト

基本的に rspec の feature テストで Rack::Test 等でテストを書けば良さそう。

JSON Schema を rspec の matcher として使えるようにする gem もあるようだ。

• https://github.com/sharethrough/json-schema-rspec
• https://robots.thoughtbot.com/validating-json-schemas-with-an-rspec-matcher 上を手動でやるような話

ただ、どちらかと言えば JSON Schema は実装で用いたほうが良さそう。 JSON Schema でリクエストの妥当性を検証するような仕組みを作っておいて、そのテストは愚直に RSpec で書く。 これによりサーバーサイドでのAPIと Schema の仕様をテストで担保しておく。 JSON Schema はクライアントやドキュメント生成で使うので、この方針のほうが筋が良いように思う。

JSON を作成する方法

• jbuilder, rabl
• roar
• garage

apotonick先生が好きなので roar かなぁ

Hypermedia API について

• http://magazine.rubyist.net/?0050-Hypermedia
• http://www.designinghypermediaapis.com/

JSON の派生フォーマット

• JSON HAL
• JSON API ember.js と相性が良い?

JSON Schema

• JSON Schema
• http://qiita.com/taizo/items/2528c16a2a48deb1c2e5
• https://github.com/interagent/prmd
• http://blog.qiita.com/post/120746062029/json-schema-for-qiita-api-v2
• http://r7kamura.hatenablog.com/entry/2014/06/10/023433
• https://github.com/r7kamura/rack-json_schema json_schema でリクエストの妥当性を検証する。他にも便利な機能が多々あるようだ。

middleman しか使ったことなかったので jekyll を素振りしていた。 github pages の上で動かすことを考えれば middleman よりもシンプルだと思った。 blog 機能もデフォルトであるし。

ただ slim とか bourbon のような github pages が想定していないものを gem とかで 使おうとすると middleman と変わらなくなってくるような気がした。 (サポートしてるのかなぁ???)

簡単なページを github pages で作るだけなら jekyll のほうがファイルが少なくなるので良いかも。

あと atom も触り始めた。 デフォルトの機能は sublime text より多いようなので、なるべく設定を変えずに使っていきたいなぁ。。。 設定厨の自覚はあるんだけど少しずつ疲れているというか、デフォルトに合わせたくなってきた。

久しぶりに Mac を触っていた。

homebrew

homebrew-cask とか homebrew-file とかが便利だったので、ソフトウェアのインストールは基本的に homebrew で一元管理することにした。

ただ、 Apple store で入れる必要があるものは brewfile には記録できるものの自動でインストールするのはできないようだ。

brewfile はオワコンみたいな記事がいくつかあったけど、homebrew と別プロジェクト切り離されただけっぽいので、使ってみたら便利だった。

brew file init を実行すると現状 brew でインストールしている一覧を brewfile に書き込んでくれるのが楽だった。 そのため、日常的に気軽に brew install して気が向いた時に brew file init && brew file push するようにしている。 (当然 brewfile は github で管理するようにしたため)

https://github.com/rcmdnk/homebrew-file#use-github-or-any-git-repository-for-brewfile-management がちょっと良くわからなかったけど、 http://www.task-notes.com/entry/20150316/1426474800 のブログ記事がわかりやすかった。

homebrew は良く出来ていると思う。

他の開発環境など

良い機会なのでエディタを atom にした。 前々から atom にしたいとはずっと思っていたんだけど、なぜか僕の Debian 環境だとうまく動かなかったので放置していた。 (おそらく node 等を自分で入れているせいなので、 Debian を入れなおして環境を綺麗にすれば動くと思う)

SublimeText3 は Linux だと日本語が入力できないこと以外は特に不満ないけど、もはやユーザーは atom に移っていると思うので、私も完全 atom 以降したい。

ターミナルははじめは標準のでもいいかなと思っていたけど、tmux と合わせて使った時に細かいところが気に入らなかったので、結局 iterm2 をいれた。 mac のターミナルで command と control がぐちゃぐちゃになる感じがあるんだけど、あれはどうも気に入らないなぁ。。。やっぱり。 macでターミナル使う人はあのへんはあきらめているんだろうか。 mac と linux を併用しているとだいぶ辛いんだけど…。 結局僕の場合、 iterm2 上だけは command と control を入れ替えているけど、それはそれで使うにくいという…。 この辺は諦めたほうが良さそうかなぁ。 あと全体的に Home と End の挙動が Linux と違うのだいぶ面倒くさい…。

Rails の開発環境として DB や Node.js などをいれる必要があるけど、この辺は docker-compose でまとめていく予定。 docker が苦しいケースでは vagrant を使うとか、適当に調整したい。 もはや必要なソフトウェアのバージョンがシビアになる開発環境まわりをローカルに直接入れたくないので、この辺はすべて仮想環境で動かせるようにしたい。 できれば gem や ruby も仮想環境に入れてしまったほうが良い気がする。 メモリとかディスク容量は無駄になる部分もあるけど、その程度で依存関係が切れになるならそっちのほうがいいし、気軽に再構築できる開発環境はやはり便利。 ただ、Linux 環境なら vagrant-lxc のような手段もあるわけで… この辺もあるものでなんとかしよう。docker を積極的に使いたい。

雑感

Linux が一番使いやすいな〜と思いつつ、 mac や windows でしか動かないソフトも結構あるが悩みどころ。 以前ほどではないとは思いつつ…。

mac はまだ細かいところを諦めれば使えるのでまーいいかー。 面倒なのは .zshrc などの設定ファイルを mac 用と linux 用を用意する必要があって、管理が面倒くさいこと。。。 共通して使える部分は１ファイルにしておいて、 各OSの .zshrc から source で読み込むのが筋が良さそう。 prezto になるべく寄せたいけど、これもあんまりうまくいってない…。

環境周りはそろそろ作り直しの時期なのかもしれない。 もーひたすらに面倒くさい。 やってると時間だけ過ぎていくし…。