ノイズキャンセリングヘッドホン WH-1000XM3を２ヶ月使ってみた感想
こんにちは。
自分が働いているオフィスはオープンスペースになっているのですが、そこに打ち合わせスペースができた＋打ち合わせスペースのスピーカーが自席に近いという状況になり、仕事に集中しにくくなってしまいました。
今まで2000円くらいのワイヤレスイヤホンを使っていたのですが、イヤホンを貫通して打ち合わせ内容が聞こえてくるのが辛すぎました。
これはもうノイズキャンセリングの付きのイヤホンを買うしかないと考えた結果、気がついたらソニーのヘッドホンを購入して２ヶ月経過していたのでレビューしてみたいと思います。
よかった点
なんといってもまずはノイズキャンセリングです。オフィスでコードを書く時や集中したいときに付けていたのですが、打ち合わせの声やまわりの話し声がまったく聞こえなくなりました。素敵。
WH-1000XM3を買ったおかげで元々悩んでいた問題は解消されました。他にも自宅や電車の中で試してみましたがオフィス同様、外部の音がほとんど聞こえませんでした。快適すぎてどこへ行くにも持ち歩くレベル。アクティブノイズキャンセリング万歳！
バッテリー
購入時の決めてはここでした。ノイズキャンセリングイヤホンだとだいたい連続再生３時間のものが多く、１日何時間も使う想定だったのでやめました。
一方、WH-1000XM3は連続再生３０時間と１日中使ってても問題ありません。
よく電源を付けっ放しにしたまま放置してしまうのですが、それで困ったことが１度もありません。
環境音取り込み
これは買ってから気づいた機能なのですが、ノイズキャンセリングしないで周囲の音が聞こえやすくなるモードがありました。これを使うと、電車からオフィスまで移動する時とか、外を歩く時に付けっ放しにしても周囲の音が聞こえてるので問題ありません。
付けっ放しで移動できるとリュックに入れる手間が省けるので良いです。
悪かった点
メガネと相性が悪い
ヘッドホン全般に言えることなのですが、メガネをしているとメガネの上にホッドホンを被せることになります。すると、メガネの締め付けが強くなって長時間付けてるとこめかみが痛くなってきます。
ヘッドホンの付ける位置を調整することで多少緩和されたりしますが、根本対策はできてません。オフィスでも付けたり外したりを繰り返してますが、集中力も限界があるのでこめかみが痛くなったら休憩みたいな運用にしています。
呼ばれても反応できない
これは褒め言葉なのですが、隣の席やちょっと離れた席の人から呼ばれてもまったく気づきません。肩を叩かれたり、横にずっと立たれたりしてようやく気づく感じです。まあ、社内のヘッドホン勢はだいたいそんな感じなのでほぼ問題にはなってませんが。
まとめ
こめかみが痛くなったときは失敗したかなと思いましたが、運用で回避できてるので今回の購入は大満足でした。メガネをしていなければ１００点中１５０点くらい付けたいレベルです。
あと、最近気がついたのがWH-1000XM3は有線でも使えます。ケーブルも付属されているので、スプラトゥーンをするときに使ったらサウンドプレイもできるのでは！？とワクワクしてます。
我が家のコーヒー事情２０１９
約２年前に下記の記事で、自宅のコーヒー事情を公開しましたがそれから色々購入して進化したので改めて記事にしてみたいと思います。
コーヒー豆
コーヒー豆は基本的に楽天で購入してます。後は出かけた時に、コーヒー屋さんがあったら気まぐれに購入とかしたり。 楽天では主に下記のお店でコーヒー豆を購入しています。
後、一時期自家焙煎もしてました。生豆を入れて手焙煎用の器具を１０分ぐらい振り続けるとできます。
実際やってみると１０分振り続けるのが辛かったり、焙煎前の豆の選別・焙煎後のチャフの除去とかあって色々めんどくさいことが判明して最近やってないです。
ドリッパー
ドリッパーは
- カリタV60
- コーノ式ドリッパー
の２つを使用しています。カリタV60は小と中を持っていて一人で飲むときは小を、複数人で飲むときは中を使うといった感じで使い分けています。
形も綺麗なのでキッチンに外出しにしておいてもインテリアとして使えて素敵な感じです。
また、水出しアイスコーヒーも作ってます。名前は忘れてしまったのですが、点滴型の安いやつです。点滴の落ちる速度を調節できなかったりたまに詰まったりといまいちですが、点滴の速度を調整できるものはお高いので妥協してます。
ミル
ミルはネクストGを使っています。挽いた豆の粒が均一になっていいです。 他に手動のミルも買ってみましたが粒の均一具合はネクストGが一番ですね。コマンダンテが気になっていますが、今のままで満足してるので購入はだいぶ先になりそう。
ポット
お湯を注ぐポットですが、点滴ができると噂のタカヒロの雫を購入しました。
お高いのですが注ぎ口がとても綺麗な流線型をしていていい感じです。点滴は正直使いこなせていません。
注ぎ口が細いので植物の水やりもできます。
所感
少しずつ買い足してだいぶ充実してきた感がありますがまだまだ色々やっていきたいです。
今後は、自動焙煎機を購入して焙煎を強化したいと思ってます。が、自動の焙煎機はどれもお高いので手が届く値段のものがでてきたら購入するかも。
技術書展５に行ってきました！
技術書展５に行ってきたのでその感想など書いてみようと思います。 技術書展への参加は２回目で、前回参加したときは台風の中、列に並んでいた記憶があります。 今回は天候に恵まれてよかった！（その分来る人が多くて大変だったかもですが）
滞在時間
当日は１０時頃に並び始め、開場して列が動き始めるとそのまま中に入れました。会場では目当てのサークルを探したり興味を惹かれた本を手にとって読んだりして、昼前に人口密度が高くなり身動きが取りづらくなってきたので退散しました。
だいたい２時間弱滞在してました。開場時間を１０時だと勘違いして早めに並んでしまいましたが、結果的に開場後にほぼ待たずに入れたので結果オーライ。
戦利品
８冊書いました。Androidに関する本が多めです。肉の本は完全に衝動買いでした。低音調理イイよね！
良かった点
各サークルの書籍が見本として置かれている場所
個人的に一番有難かったのはこのスペースです。すべてのサークル？の本が一箇所にまとまっているので面白そうな本がないか探すために開場を歩き回らなくてもよかったので体力を温存できました。
決済アプリ
さすがテクブさんと思ったのが決済アプリ。同人イベントで決済アプリ見たのは初めてでした。このアプリを使えば後払いでじゃんじゃん本を購入することができるみたいです。
自分の場合、このアプリは使わず現金払いにしました。イベント事では財布の紐が緩んでしまうタイプなので、後払いというシステムは嫌な予感しかしません。
素敵な標語
書かれている事が深いですね。こういうの好きです。
他にもありましたが、特に気に入ったものを撮りました。
気になった点
行列に行く手を遮られる
自分が滞在していた時間に一箇所、行列ができてました。その行列にサークルさんが隠れて見えない＋行列で通路が狭くなり動きづらいという状態になってました。 コミケとかで人気サークルを壁際に配置していたのはこういう理由だったのかと得心しつつKIAIで通りました。 技術書展はコミケとかに比べるとまだまだ歴史は浅いし行列になるであろうサークルを特定するのは無理ゲー感ありますね。
まとめ
自分は基本的にネット通販でしか技術書を買いません。そうすると必然的に自分が興味を持った分野の書籍しか購入できないのですが、技術書展は自分の興味の外にある技術（技術書）を知る事ができる良い機会だと思い参加しています。
今回も「fitbitってAPIあるのかー」「システム管理者を題材にしてる漫画があるの知らなかった」「低音調理器って自作できるの！？」といった新しい発見がありました。
本屋さんは、その人が自分でも知らない興味の種を発見できるような仕掛けを準備している
と何かの本に買いてありましたが、技術書展はそれをITという限られた分野で行なっているように思いました。
そんな出会いを提供して頂いた技術書展の運営様やサークルの皆様に感謝です。ありがとうございました。いつの日かサークル参加できたらいいなぁ・・・
アウトプット大全を読んでみた
前々から、「アウトプットって大事だよな〜」と思いつつなかなか行動に移せていなかったのですが、学びを結果に変えるアウトプット大全を読んで改めてアウトプットの大事さを感じたので早速実践ということで書いてみたいと思います。
この本に読書感想用のテンプレートも準備されているのでそれに則って書いてみます。
概要
この本は全５章で、１章がアウトプットのメリット、２〜５章が具体的なアウトプットの方法という構成になっています。
私としてはアウトプットのメリット・方法どちらも知りたかったので全体的にとてもためになりました。個人的に特に目からウロコだった事柄を３つあげてみたいと思います。
1. アウトプット＝運動
アウトプットするときは、書いたり話したりして運動神経を使うと記憶が定着しやすいです。「運動性記憶」と呼ばれるもので神経細胞が使われるほど記憶に残りやすくなります。
実感として声に出して読んだり・ブログに書いたりするとアウトプットすると記憶に残りやすい印象があります。
2. アウトプットのハードルは高ければいいとは限らない
アウトプットのハードルは、高すぎるとモチベーションが上がらないし不安や恐怖を感じてしまって長続きしません。
この本ではアウトプットの難易度を「快適領域」、「学習領域」、「危険領域」の３つに分類して学習領域となるちょい難のアウトプットを行うことを勧めています。
私はアウトプットのハードルを危険領域に設定する傾向があるみたいで、楽しさよりも不安が勝るときの方が多いので見直した方がよいと感じました。
3. やる気スイッチは時限式
やる気スイッチはやる前に入るのではなく、やり始めると入ります。人の脳は作業を始めると、だんだんやる気が出てくるような性質を持っています。知らなかった・・・。
たしかに、やる気はないけどポモドーロテクニックを１サイクルだけ回してみようかと思って始めた作業が２サイクル以上続いた経験は割とあります。
ポモドーロテクニックは２５分間ですが、２５分と言わず５分でもいいから始めた方がエンジンがかかりやすいみたいです。
まとめ
他にもたくさんためになることが書いてありますが、一度に吸収できない量なので何度も読み返したいと思います。興味を持たれた方は購入してみてください。
サービスを開発するエンジニアとして働いていると、アウトプットすることは生存戦略上大事なんだろうなーと思う時が多々ありました。
しかし生存戦略という動機だけでアウトプットするのは楽しくなくて、楽しくアウトプットできる理由を探していました。
この本はその疑問に答えくれる本でした。
Kotlinとスプラトゥーンで学ぶデザインパターン【7. Builder】
休日にやりたいことがありすぎてなかなかブログを更新できてません。
気がついてたら半年ぶりの更新になってた。
スプラトゥーン２は地味に続けてますが最近はNine Parchmentsにはまってます。
Builder パターンとは
普段Androidアプリの開発をしているとBuilderパターンで書かれているクラスをよく見ます。
StringBuilderとかOkHttpClientとか。
Builderパターンは複雑な処理を、段階的に組み上げていくパターンです。
また組み上げ方は固定ですが、組み上げる時に使用するオブジェクトは柔軟に変えられるようになってます。
実装
メインとなるクラスはDirectorとBuilderで、この２クラスで組み上げ方を決めています。
Director.kt
class Director(private val builder: MainWeaponBuilder) { fun construct() { builder.name(".96ガロン") builder.power(62) builder.range(31) builder.quickness(10) } }
MainWeaponBuilder.kt
abstract class MainWeaponBuilder { abstract fun name(name: String) abstract fun range(range: Int) abstract fun power(power: Int) abstract fun quickness(quickness: Int) }
今回はスプラトゥーン熱が低かったせいか例があまり良くないですがDirectorクラスは.96ガロンを作成するクラスとなっています。
デコるかどうかは使用するBuilderクラスに寄ります。
無印を作りたい場合はUnmarkedWeaponBuilderを、デコを作りたい場合はDecoratorWeaponBuilderを使用すれば作成できます。
UnmarkedWeaponBuilder.kt
class UnmarkedWeaponBuilder : MainWeaponBuilder() { var name: String? = null var range: Int = 0 var power: Int = 0 var quickness: Int = 0 override fun name(name: String) { this.name = name } override fun range(range: Int) { this.range = range } override fun power(power: Int) { this.power = power } override fun quickness(quickness: Int) { this.quickness = quickness } fun getResult(): Weapon { return Weapon(name!!, range, power, quickness) } }
DecoratorWeaponBuilder.kt
class DecoratorWeaponBuilder : MainWeaponBuilder() { var name: String? = null var range: Int = 0 var power: Int = 0 var quickness: Int = 0 override fun name(name: String) { this.name = "${name}デコ" } override fun range(range: Int) { this.range = range } override fun power(power: Int) { this.power = power } override fun quickness(quickness: Int) { this.quickness = quickness } fun getResult(): Weapon { return Weapon(name!!, range, power, quickness) } }
改めて見ても例がいまいち・・・。
実行結果
それぞれの.96ガロンを作成して見ます。
Main.kt
fun main(args: Array<String>) { val unmarkedBuilder = UnmarkedWeaponBuilder() var director = Director(unmarkedBuilder) director.construct() println(unmarkedBuilder.getResult()) val decoratorBuilder = DecoratorWeaponBuilder() director = Director(decoratorBuilder) director.construct() println(decoratorBuilder.getResult()) }
結果は
Weapon(name=.96ガロン, range=31, power=62, quickness=10) Weapon(name=.96ガロンデコ, range=31, power=62, quickness=10)
Kotlinとスプラトゥーンで学ぶデザインパターン【5. Singleton】
最近チャージャーに限界を感じてきました。特にガチホコだと思わぬ奇襲を受けやすいです。
奇襲に対処できるチャージャーになりたい。
Singleton パターンとは
Singletonとは対象のクラスが絶対に１つしか存在しないことを保証するデザインパターンです。
今回は、ダウニーの上位互換ことスパイキーをSingletonパターンで表現してみました。
スパイキーはゲソタウンで指定したギアの受け取りをしてくれます。
当たり前ですが、スパイキーは一人（匹？）しかいないです。
複数いたらどのスパイキーからギアを受け取ればいいかわからなくなりますね。
実装
Spiky.kt
class Spiky { private constructor() {} var delivery: Delivery? = null companion object { val spiky = Spiky() fun getInstance(): Spiky { return spiky } } fun receiveDelivery(delivery: Delivery) { this.delivery = delivery } fun requestReceiveOrder() { delivery?.let { println(it.name + "が届いてるぜ！") } ?: println("そんなものはない") } }
まずはスパイキークラス。コンストラクタをプライベートにして外部からインスタンス化できないようにして、
インスタンスはクラス内で生成しgetInstanceで渡すようにしてます。
あとは配達物が届いてるか判定して文字を出力します。セリフは雑です。
Delivery.kt
data class Delivery(val id: Int, val name: String)
配達物のデータクラスです。良い英語が思いつかなかった・・・
Main.kt
val spiky = Spiky.getInstance() spiky.requestReceiveOrder() spiky.receiveDelivery(Delivery(1, "ガチガサネ")) val spiky2 = Spiky.getInstance() spiky2.requestReceiveOrder()
スパイキーを２回生成するようにして同じインスタンスを参照できているか確認します。
別インスタンスであればspikey2には配達物が届いてないことになります。
Kotlinとスプラトゥーンで学ぶデザインパターン【6. Prototype】
久しぶりの更新になってしまいました。
スプラトゥーン２が発売されたし仕方ないよね。ちまちま空いてる時間にプレイしてます。
↓今の状況です。
#Splatoon2 #SplatNet2 pic.twitter.com/Rk4OgkqwA3
— kzt (@seiizo) 2017年9月30日
今回はPrototypeパターンです。Singletonパターンをすでにやってるつもりになってとばしてしまった・・・
Prototype パターンとは
インスタンスを作る時、通常は作りたいクラスをnewして作成しますが、
そうではなく既存のインスタンスをコピーして作る。それをPrototypeパターンと呼ぶらしいです。
なぜそのような実装をするかというと
などの理由が挙げられます。
実装
スプラトゥーンからは離れてしまいますが、セーブデータを題材にしてみました。
セーブデータの中にはいろいろな情報が入っており、クラスからインスタンス化するには難しいというか面倒くさいです。
そこでprototypeパターンを使って実装してみます。
SaveData.kt
class SaveData(val user: User, val games: Array<String>) : Cloneable { fun createClone(): SaveData { return clone() as SaveData } fun print() { println("id:" + user.id) println("name:" + user.name) println("registered game datas:") games.forEach { println(it) } } }
SaveDataManager.kt
class SaveDataManager { fun create(user: User, games: Array<String>): SaveData { return SaveData(user, games) } fun copy(data: SaveData):SaveData { return data.createClone() } }
SaveDataにCloneableインターフェースを実装してクローンできるようにしてます。これが今回のキモですね。
cloneは外部に見えないので別途メソッドを作って対応しました。
Main.kt
fun main(args: Array<String>) { val user = User(123, "seito") var games:Array<String> = arrayOf("Splatoon2", "Mario Kart") val manager: SaveDataManager = SaveDataManager() val newSaveData = manager.create(user, games) newSaveData.print() val copiedSaveData = manager.copy(newSaveData) copiedSaveData.print() }
一度セーブデータを作ってそれをコピーして同じ出力結果になるよねーって確認をしています。
実行結果
id:123 name:seito registered game datas: Splatoon2 Mario Kart id:123 name:seito registered game datas: Splatoon2 Mario Kart
感想
デザパタ本を読みながら作ったらManagerクラスができたんですが、今回の場合Manager内で扱うクラスは１種類なのでManagerクラスを作らないでMainから直接createCloneを呼んだほうがすっきりするだろうなーと思ったり。
スケーラビリティを考えるとManagerクラスがあってもいいけどスケールする可能性あるのか。
