【レビュー】Bose QuietComfort35 wireless headphones を買って数日使ってみた
はじめに
数年前からカナル型イヤホンを使っていたのですが、家電量販店で「Bose」という
名前をよく見ていました。また、一部のエンジニアにも人気ということで
気になっていました。
そして、つい最近新しいのが出るということで
どうしようか迷っていたのですが（値段的な意味で）一大決心をして
購入に踏み切りました。
購入したのはこちら
- 出版社/メーカー: BOSE
- 発売日: 2016/06/24
- メディア: エレクトロニクス
- この商品を含むブログを見る
週末と職場で使ってみたので、レビュー（感想）を書きたいと思います。
製品概要
- ノイズキャンセリング（以下、NP）を搭載
- NPで初のワイヤレス
- つけていても疲れない、高級感あふれ、快適な装着感
- バッテリー持続時間が連続使用20時間＋モバイルバッテリーで充電できる
自分もこのぐらいであれば、4万も出すほどではないと思いました。
音楽を聞くだけならお手頃価格で良いものはたくさんありますし。
場所
自宅
自宅は比較的静かなので、そんな実感ないかな？思っていたのですが
すぐに実感することになりました。
まず、この時期から稼働することになるであろう「エアコン」の音がなくなりました。
これにはビックリして「まさか？！」と思ってしまうほどで、ものすごく集中することができました。
カフェ
せっかくなので、Macbook Airを持ってスタバでドヤってきました。
今まではカナル型イヤホンをつけてやっていたので、雑音＋人の声＋音楽の3つが
同時に聞こえて集中できていたかというとそうでもありませんでした。
そして、装着して音楽をかけたところ・・・
若干、人の声はするものの（これは音量次第でどうとでもなる）
変な雑音は一切聞こえませんでした。
「こんなに静かだったっけ？」とヘッドホンを外してみると
いつものように聞こえて、逆にいつも以上にうるさく感じてしまいました。
通勤
さすがに歩いている時に着けるのは危ないので、電車に乗ってから着けました。
そして、前評判通りキレイに雑音が消えて人の声のみとなりました。
音楽をかけなくても電車の中であの静けさを手に入れることができるのは
すごいことだなと思いました。
職場
職場は比較的静かなところなので、あまり意味がないですが
集中したりするときに装着して、長時間の装着感を主に確かめました。
結果は数時間つけていても疲れず、NPのおかげで周りの音が消え
音楽をかけていつも以上に集中することができました。
全体を通して
NPの力は偉大だとすべてを通して思えたのと、無線というのも大きかったです。
バッテリーも20時間もつので頻繁に充電しなくてもいいというのも良い。
さらにつけ心地も問題なし。
素晴らしい商品です。
まとめ
オーバーヘッドイヤホンを本格的に使うのは、かなり戸惑いました。
しかし、それを覆すほどの商品だったので、興味ある方は実際に
手にとって体感してもらえればと思います。
ただ、値段がかなり高いので覚悟を決めて買った方がいいです。
自分も半分「えい、やー！」で買ったようなものです。
【Rails】【Capistrano】SCMを使わずにデプロイする方法
はじめに
Webサービスを開発していて、かなりハマったのでメモをする。
環境
- OS X El capitan
- Ruby 2.3.0
- Ruby on Rails 4.2.7
- Capistrano 3.4.0
前提条件
Vagrantなどでローカル環境でSCMからソースを取得して、
デプロイできる環境となっていること。
または、SCMからソースを取得しないで、ローカルにあるファイルを
デプロイしたい場合。
詳細
通常のCapistranoは、「cap staging deploy」を実行した場合
以下の記述に沿って、デプロイしたいサーバーでSCMからソースを
pullしてからデプロイを実行します。
# config/deploy.rb set :repo_url, 'git@github.com:[User Name]/[Repository Name].git' set :scm, :git
ただし、サーバーからSCMにアクセスできない場合があります。
※セキュリティ的な理由だったりする。
これは自分にとってかなり困った状態となった。
Capistrano標準だと何も考えずやればよかったが、デプロイ方法を
考えなおさなければなりませんでした。
そして、1日考えたあげく解決方法として2つ見つかりました。
解決策：Capistranoコマンドを実行した箇所からファイルをコピー
その１
アクセスできないのであれば、アクセスできるところで
ファイルを取得して、それをまるっと持っていけばいいという方法です。
以下のものを使えばいけるようです。
ただし、メインの場所は開発がストップしており
フォークされたものが有志でメンテナンスしているみたいです。
余談ですが、以下のやつも同じようなことができるようです。
その２
別のものを使っても、同じようなことができます。
※Capistrano2では、もともとあった機能のようです。
使い方はQiitaの記事を見れば、簡単に実装できます。
まとめ
便利なものがすでに用意されており、今回ローカルマシンでというのが
メインでしたが、CIサーバで同じことをすれば問題なく動くと思います。
標準的な動作でやれることに越したことはないですが
別の方法を知っておくことで、想定外のことを想定内にしておくことって
とても大切だと思わされた内容でした。
【Rails】Deviseを使って管理側のログインURLをスマートにする
はじめに
Webサービスを開発していて、ハマったところなのでメモ。
環境
- OS X El capitan
- Ruby 2.3.0
- Devise 3.4.1
- Ruby on Rails 4.2.4
前提条件
- ローカル環境でDeviseが正常に動作すること。
- ApplicationControllerを管理画面用のコントローラーを使っている。
- 管理者テーブルは「admin_users」という名前で定義している。
上記内容は、各アプリごとに違うので適度読み替えてください。
詳細
app/controller/admin/admin_controller.rb
class Admin::AdminController < ApplicationController layout "admin/layouts/application" before_action :authenticate_admin_admin_user! end
config/routes.rb
# home/indexはダッシュボードみたいなところとして定義している。 namespace :admin do get '/', :to => 'home#index' # controllersは独自でカスタマイズしているため、明示的に書いている。 devise_for :admin_users, controllers: { sessions: 'admin/devise/sessions', registrations: 'admin/devise/registrations', passwords: 'admin/devise/passwords' } end
rake routesでパスを確認すると以下の通りとなる。
new_admin_admin_user_session GET (/:locale)/admin/admin_users/sign_in(.:format) admin/devise/sessions#new
admin_admin_user_session POST (/:locale)/admin/admin_users/sign_in(.:format) admin/devise/sessions#create
destroy_admin_admin_user_session DELETE (/:locale)/admin/admin_users/sign_out(.:format) admin/devise/sessions#destroy
改修した経緯
- URLがまったくスマートではなく、モデル名が露出していたため。
- adminが2つ並んでいて、よろしくない。
解決策
以下のように記述すれば、スマートになります。
config/routes.rb
# home/indexはダッシュボードみたいなところとして定義している。 namespace :admin do get '/', :to => 'home#index' end # controllersは独自でカスタマイズしているため、明示的に書いている。 devise_for :admin_users, path: :admin, controllers: { sessions: 'admin/devise/sessions', registrations: 'admin/devise/registrations', passwords: 'admin/devise/passwords' }
app/controller/admin/admin_controller.rb
class Admin::AdminController < ApplicationController layout "admin/layouts/application" before_action :authenticate_admin_user! end
rake routesでパスを確認すると以下の通りとなる。
new_admin_user_session GET (/:locale)/admin/sign_in(.:format) admin/devise/sessions#new
admin_user_session POST (/:locale)/admin/sign_in(.:format) admin/devise/sessions#create
destroy_admin_user_session DELETE (/:locale)/admin/sign_out(.:format) admin/devise/sessions#destroy
参考
【書籍】GILT(ギルト)という本を読みました。
はじめに
ひとりのプログラマとして、技術書を読み漁るのもいいですが
ビジネスにコミットしていく上でビジネス書も読まないとダメだな
と思い、書店の「起業コーナー」を眺めていると以下の本を発見しました。
GILT(ギルト) ITとファッションで世界を変える私たちの起業ストーリー
- 作者:アレクシス・メイバンク,アレクサンドラ・ウィルキス・ウィルソン
- 発売日: 2013/04/18
- メディア: 単行本
ハードカバーであり、結構なページ数だったので
読めるか心配だったのですが、内容はそこまで小難しくなく
書かているようなので、朝読書をメインに読み続けました。
5月終わりぐらいに読み終えて、得られるものが結構あったので
読書メモとしてここに書く。
読書メモ
スタートアップのメンバーとして
スタートアップのビジネスは、1人ひとりが臨機応変に判断し
柔軟に独創的に行動して、いくつもの役割を果たすことが大事。
反対意見
反対意見は価値がある。
否定的意見と計画していたことを照らしあわせて検討した。
否定的な見方をする人の耳障りな意見や疑問に
耳を傾けることで、起こりうるあらゆる状況が想定できるだけでなく
潜在的なライバルがわかってくる。
人脈
立ち上げ準備時の人脈ネットワークを作る。
人付き合いが苦手な人でも、アドバイザー、客の紹介
取引先を探す労をとってくれる支援者を自分の人脈リストの中に
少なくても、2,3人は見つけておくこと。
スタートアップに重要なこと
スタートアップにとって、1番重要なのは
プレゼンテーション、自分の見せ方にこそ投資をする。
強烈な第一印象を与えることにお金を使わないといけない。
エンジニア
エンジニアが「この人のために仕事をしたい」と思うような
リーダーシップとカリスマ性を備えたトップがいることが大事である。
トップクラスのエンジニアを採用し、採用者に満足して働いてもらうためのノウハウ。
- 前もってふるいをかける
オフィスで会う前に筆記試験を受けさせる。
仕事のスピード、経験と技術スキルを判断するためだが試験をするのは、
スキルよりむしろ人柄を見るほうが大きい - エンジニアとしての能力だけでなく、企業文化に合う人を採用する。
直近3ヶ月間に手助けしてくれる人より、今後2〜3年勤めて、会社に貢献してくれる人を待望する。
面接の時には、エンジニアとしての優秀さと、一緒にやっていける人柄かを五分五分で見る。 - 外部に誇れるテクノロジー・ブランドをつくり上げる
トップクラスのエンジニアに来てもらうためには、トップクラスのエンジニアが在籍し、すばらしい問題解決能力を
発揮している会社として認められることが重要。大きな会議のスポンサーになり、講演したり、ブログを開設して、
エンジニアの質の高さを示す。こういう形でアピールすることにより「一緒に働きたい、仕事に興味がある」と言う人が増える。 - トップクラスの才能を引き入れるための工夫を凝らす
最高のエンジニアは職探しなんてしない。口説き落とすには、オフィスに呼んで気軽におしゃべりしたり、
エンジニアに引き合わせたりすることが役立つ。 - 創造する時間を与える
エンジニアを本来の仕事以外のことで悩ませてはいけない。エンジニアが関心を持つ製品の開発に、
長時間にわたって邪魔されずに集中して取り組めるようなハッカソンを定期的に開催したりする。
トップに立つ人へのアドバイス
- 怒りを感じたときには絶対に人と話さない
大きく深呼吸して、むずかしい話ができる準備が整うまで気持ちを落ち着かせる。 - 取り返しのつかない失敗はないと覚えておくこと
一生懸命に働き、かなりの能力もある人が下す決断は、いいことが悪いほうを上回るもの。
失敗から立ち直るには、いさぎよく失敗を認め、どうすれば取り戻せるかをすばやく説明し、そして行動すること。 - 相手に花を持たせることも忘れない
完勝はいつもいいことだとは限らない。 - 何が人を発奮させるかに気づく
数字を見ると興奮する人もいれば、創造的な仕事に満足感を得る人もいる。
どんな仕事に高いモチベーションを持つかは、人によって違う。年齢や性別では決めつけられない。
人を理解するための唯一の方法は、何が相手を動かすかを理解しようと働きかけ、一緒に時間を過ごすこと。 - 内なる声に耳を澄ます時間を取る
どんなに多忙でも一人きりになる時間を取る。精神を落ち着かせることがある。
ノート一冊持っていかず、ただ座って、とりとめのないことを考える。
そんなときに、放置しておいては解決できない問題について、ベストなアイデアを思いついたりする。
まとめ
スタートアップについて書かれた内容だったので、エンジニアについても
しっかりと書かれていたのでかなりためになりました。
特に上に書いたエンジニアの採用に関しては頷ける人がたくさんいると考えています。
結局「新しいことをやりたい」と思ってもなかなかできず
いざそのチャンスが来た時も準備できておらず「どうしよう」となってしまい
動けない人では意味がないです。
また、社内で新規事業が立ち上がりそのチームのメンバーとして動くことに
スタートアップと似た何かがあるように思います。
ちなみに本の中に書いてあったことですが
2008年とかそのぐらいの話なのに、立ち上げ時はRuby on Railsを使う
ということになっていたようです。
やはり、Ruby(Ruby on Rails)はビジネスと密接しているなぁと思いました。
【Rails】【Capistrano】Staging環境で「bundle exec rails console」しても動作しない
はじめに
Webサービスを開発していて、ハマったところなのでメモ。
環境
- OS X El capitan
- Ruby 2.3.0
- carrierwave 0.11.2
- fog 1.38.0
- Ruby on Rails 4.2.4
- Capistrano 3.4.0
- capistrano-bundler 1.1.4
詳細
CapistranoでVPSサーバなどにデプロイした後
サーバ側で「bundle exec rails console」を実行した際に
以下の様な情報が出力されてしまいました。
$ bundle exec rails c Usage: rails new APP_PATH [options] Options: -r, [--ruby=PATH] # Path to the Ruby binary of your choice ...以下略...
また、config/deploy.rb は以下の通り設定していました。
set :linked_dirs, %w{bin log tmp/pids tmp/cache tmp/sockets bundle public/system public/assets vendor/assets/bower_components}
なお、おさらいとしてですが
rails consoleを起動するとき、bin/railsの内容が呼び出されるようになっています。
この設定は、新規でプロジェクトを作ったときから有効です。
元にローカル環境では問題なく使えていました。
bin/rails
#!/usr/bin/env ruby APP_PATH = File.expand_path('../../config/application', __FILE__) require_relative '../config/boot' require 'rails/commands'
解決策
config/deploy.rb に以下の記述を追加する。
set :bundle_binstubs, -> { shared_path.join('bin') }
また、「set :linked_dirs」から「bin」を削除する。
上記のように定義した後、Capistranoでデプロイして bin配下にファイルが設定されていればOKです。
原因
1つ目は、binをsharedディレクトリにしていたのにも 関わらず、bin配下の内容を配置していなかったことです。
set :linked_dirs, %w{bin log tmp/pids tmp/cache tmp/sockets bundle public/system public/assets vendor/assets/bower_components}
2つ目は、capistrano-bundler 1.1.4から仕様が変更になったようです。
そして、GitHubにあるドキュメントのUsageを見ると、bin配下のものは
以下のように定義するように書いてありました。
set :bundle_binstubs, -> { shared_path.join('bin') }
【Rails】【Capistrano】Carrierwave (fog)を含んだ形でデプロイするとエラーになってしまう
はじめに
Webサービスを開発していて、ハマったところなのでメモ。
環境
- OS X El capitan
- Ruby 2.3.0
- carrierwave 0.11.2
- fog 1.38.0
- Ruby on Rails 4.2.4
- Capistrano 3.4.0
詳細
Carrierwaveの動作確認がローカルでできたのですが
Capistranoを使ってデプロイしようとしたところ
以下の様なエラーが発生しました。
rake aborted! ArgumentError: Missing required arguments: aws_access_key_id, aws_secret_access_key
「idとkeyが必須だが、設定されていないよ」というエラー内容。
実装は以下の通りとなっている。
config/initializer/carrierwave.rb
CarrierWave.configure do |config| config.fog_credentials = { provider: 'AWS', aws_access_key_id: ENV['IMG_UP_AWS_S3_ACCESS_KEY_ID'], aws_secret_access_key: ENV['IMG_UP_AWS_S3_SECRET_ACCESS_KEY'], region: 'ap-northeast-1' }
実装方法としては、環境変数から取ってくるようにしていました。
さらにCapistranoを動かすホスト側には環境変数を定義せず、dotenv管理。
クライアント環境には環境変数定義済みです。
解決策
Capistranoでデプロイ時に使用する環境変数を明示的に設定するようにします。
# Default value for default_env is {} set :default_env, { rbenv_root: "/usr/local/rbenv", path: "/usr/local/rbenv/shims:/usr/local/rbenv/bin:$PATH", IMG_UP_AWS_S3_ACCESS_KEY_ID: ENV["IMG_UP_AWS_S3_ACCESS_KEY_ID"], IMG_UP_AWS_S3_SECRET_ACCESS_KEY: ENV["IMG_UP_AWS_S3_SECRET_ACCESS_KEY"] }
こうすることにより、デプロイ時のみ使われる環境変数を定義することができます。
また、ホスト側に環境変数を定義せず実行できるので、無駄に変数を書かなくても済みます。
以下、Capistrano実行時のログ。
Command: ( RBENV_ROOT=/usr/local/rbenv PATH=/usr/local/rbenv/shims:/usr/local/rbenv/bin:$PATH IMG_UP_AWS_S3_ACCESS_KEY_ID= IMG_UP_AWS_S3_SECRET_ACCESS_KEY= RBENV_VERSION=2.3.0 /usr/bin/env mkdir -p /tmp/sample/
原因
Capistranoでは、ホスト、クライアントの環境変数を読まずに実行するようです。
そのため、明示的に指定してあげないといけないようです。
