Posts

【2020年版】リモートワークに最適なヘッドセット的デバイス

February 17, 2020
gadget, work

リモートワークが推奨される昨今、オンラインミーティングが増えてくると、通話環境をもっと良くしたいという要望が沸いているのではないでしょうか? そこで、リモートワークが多い僕が、一昨年くらいから色々と調達して試したヘッドセット的デバイスを紹介したいと思います。 オンラインミーティング用オーディオデバイスはJabra最強説 # 今回紹介するのは両方ともJabraのデバイスです。 Jabraはコールセンターなどの業務用ヘッドセットに特化しているメーカーで、Sennheiser、Sony、Plantronicsなどなどのオーディオデバイスを試した結果、個人的にJabraデバイスがマイクにのるノイズが少なくオンラインミーティング用としてはベストだと感じました。 マイク性能が良いワイヤレスイヤホン Evolve 75e # 現在、メインで使っているのがこのEvolve 75eです。主に移動先のカフェなどで利用しています。 Jabraのネックバンド型ヘッドセットの中で最上位モデルで、この手のタイプのヘッドセットの中では最もノイズが乗りにくいマイクだと実感しています。 それなりの音量で音楽が流れているカフェでも、相手にほとんど聞こえることなく通話できます。マイク部分を手で覆うと、よりノイズが軽減されます。 ネックバンド型を愛用している理由は、バッテリー時間でスペックは満充電で14時間となっているため、1日中利用してもバッテリー切れになったことがありません。 ノイズキャンセリングは、一応搭載されているのですが、やはりSonyなどの製品に比べるとあるだけましレベルなので、そこは期待しない方が良いでしょう。 僕が購入したときは、Amazonでの取り扱いがなかったのですが、いまは扱っているみたいなので手軽に購入できます。 製品詳細ページ Amazon 定番卓上マイクスピーカーのハイエンドモデル Speak 710 # 自宅でのミーティングで使っているのがこのSpeak 710です。510を使っているのを良く見ますが、個人的にはどうせ買うなら710が良いと思っています。 710は音楽再生用のスピーカーとしても利用できるためか、裏にスタンドが付いていて、立て置が可能となっているのですが、これが机のスペースを無駄にせず、またスピーカーの指向性も良くなるので、一人で使うケースでもとても便利です。 性質上、環境ノイズが多い場所での利用は難しいですが、静かな自宅であればいい感じに使えるはずです。 製品詳細ページ Amazon まとめ # Evolve 75やPro 900なども気になっているのですが、持ち運び性能を重視して購入にはいたりませんでしたが、持ち運びしない人であれば、こういったヘッドセットも候補に入れても良いかもしれません。 ほかにもモバイルディスプレイなど、自分がリモートワークをする中で活躍しているデバイスはあるのですが、今日は簡単にオーディオデバイスを紹介しました。

僕が毎日学習するために実践している方法

February 17, 2019
learning, life, programming

継続的な学習は、僕の中で近年のひとつの大きなテーマとなっています。といっても、どうすれば継続学習ができるのかという話ではなく、世の中には日々の学習を行わない人がいるけど、どうして学習をしないのか、というのがこのテーマの中心課題です。 今回は、そのテーマについて論じる前に、僕が日々実践している学習方法を紹介したいと思ったのでブログに書いておきます。 毎日学習するための方法 # 僕が実践している毎日学習するための方法はとても簡単で、具体的には次の通りです。 特定のリポジトリを毎日git pullして、追加されたコミットを見る 面白い変更があればシェアやメモする 見ての通り、とても簡単です。僕は毎日これを1日の作業開始前に行っています。 毎日リポジトリをチェックすることで得られるメリット # これを続けていることで得られるメリットは色々ありますが、僕が考える代表的なものは次の通りです。 そのプロジェクトについて詳しくなれる そのプロジェクトで使われている言語について詳しくなれる 一般的なコミットメッセージの書き方を知ることができる 一般的なコミットの粒度を知ることができる それでは具体的にそれぞれのメリットについて説明していきます。 なお、ここからは僕が現在ウォッチしているEmacsのリポジトリを題材に話をすすめていきます。 そのプロジェクトについて詳しくなれる # プロジェクトを毎日git pullすると、少しづつ変化を確認できます。大きめなプロジェクトの場合、リリースが行われると大量の変更が入るため、変更をすべて確認するのはとても大変ですが、毎日の変更であればそこまで労力はかかりません。 例えば、この記事を書いているときの最新のコミットは上図のように1行(3文字)だけです。これだけあれば、時間をかけずに読むことが可能です。 Emacsの場合、リリースは平均して1年以上の間隔が空くのですが、コミットはほぼ毎日行われています。そのため、リリース後にすべての変更を確認するのはほぼほぼ困難となりますが、毎日であれば、おおよそ漏らさずに確認が行えるため、普通の人よりもEmacsについて詳しくなれます。 これは、もしそのプロジェクトについての書籍を書くことになるような場合にとても有益です。 そのプロジェクトで使われている言語について詳しくなれる # コードリーディングは、スキルの向上にとても役立ちますが、すでにできあがったプロダクトのコードを一から読むのはとても大変です。ですが、毎日のコミットを読むだけであれば、そこまで時間をかけずに行うことが可能となります。 Emacsは、基本的にEmacs LispとCで書かれているプロジェクトです。そのため、毎日コミットを読めば、この2つの言語について少しづつ詳しくなれます。 僕自身はCは書くことがないので、ほぼコミットメッセージだけ読んで流していますが、Emacs Lispについてはコミットされたコードを見て、少しづつ他の人の書き方を学習しています。 お陰で、自分がEmacs Lispコードを書くときには、そこで得た知識を活用してコーディングできるようになります。 一般的なコミットメッセージの書き方を知ることができる # もし、コミットメッセージと関係のない変更が行われているコミットがあれば、変更を見たときに意味を考えてしまいますが、Emacsのリポジトリではそういったコミットは一切ありません。そのため、悩むことなくコミットを読むことが可能となっています。 逆に、コミットを読んでいて、変更の意味が理解できずに悩んでしまうことがあるとすれば、それはコミットメッセージかコミット粒度のどちかが悪い可能性がありますので、自分自身がコミットを行う際に、そのようなことがないように気をつけるポイントとして学習しておく必要があります。 一般的なコミットの粒度を知ることができる # コミットの粒度は、明確な答えがないため、なかなか学習が難しいスキルです。ですが、色々なプロジェクトのコミットを見ていると、一般的に正しいとされているコミットの粒度を知ることができます。 個人的にコミットを見つづけることであらためて最重要と感じたのは、コミットメッセージ以外の変更は行わないという、当たり前のことを当たり前に行っていく姿勢です。 例えば、上図のドキュメント変更のコミットは、どちらもminibufferに関するコミットですが、それぞれ追加と修正が分けれていて、コミットメッセージと変更が等しくなっています。 更に言えば、ドキュメントのタイポや単純な空白の削除であっても、Emacsのリポジトリではコードの変更と合わせたコミットは行っていません。タイポの修正はタイポ修正として、空白の削除は空白の削除として、コードの変更はコードの変更として、変更内容と一意のコミットメッセージでコミットされています。 そのため、コミットメッセージとコミットに乖離がなく、コミットを読む際に余計な意味を考えずに変更を確認することができます。 こういった適切な粒度でコミットを行うことは、当たり前と思えるかもしれませんが、会社などでは意外とできていなかったりするため、こういったプロジェクトで当たり前に行われていることを噛み締めることで、あらためて肝に命じておくことができます。 毎日コミットを読む方法 # 僕が毎日コミットを読むために利用しているツールは基本的にはTig だけです。git pullしてTigを起動(lをTigのエイリアスにしています)して、コミットにひとつづつ目を通していきます。 ターミナルに慣れていない人であれば、SourcetreeやGitHub Desktopなどのデスクトップクライアントでもまったく問題ありませんので、好きなツールを使うと良いしょう。 おわりに # 今回は僕が実践している毎日の学習方法を紹介してみました。本を読むなどの方法ももちろん効果的ですが、こういった方法でもプログラマは自主的に学習できます。 学校や本では学べない、より実践的なエッセンスを学習することができますので、もし、何か気になるプロジェクトがあればぜひ試してみると良いでしょう。

13年振りのインフルエンザ

February 15, 2019
life

13年振りのインフルエンザになりました(過去のブログで確認しました)。おそらく人生で3度目のはずで、記憶の怪しい1回目が20歳以前、2回目が13年前、そして今回の3回です。 僕がインフルと無縁の生活を送っている13年の間に、インフルエンザ界では大きな変化がありました。 昔はインフルに特効薬がなかった # その中で最も大きい変化はやはり、特効薬的な薬が生まれたことでしょう。そう、登場時に色々と問題になった「タミフル」です。いまでは普通に使われていますよね。 もしかしたらミレニアム世代には「インフルエンザは特効薬なんてなくて、かかったら熱が下がるまで、ひたすら耐えるしかなかったんだよ。」と伝えたら、あきれられるのかもしれません。でも、13年前は実際にそうでしたし、医学の進歩が早いのか、時の流れが早いのかはさておき、色々と変ったものです。 そんなわけで、今回、いよいよ話題のタミフルを飲むときがやってきたのかと思って、ドキドキしていたのですが、処方されたのは「イナビル」という聞いたことのない薬でした。 新薬イナビルを体験 # タミフル以後、どうやら「リレンザ」というやつと「イナビル」という2種類の薬が増えていたそうで、一気に浦島気分です。 イナビルは口から吸い込む吸入タイプの薬で、1回使えば5日間くらい効果が持続するという便利なやつだそうです。使い方は、第一三共がオウンドメディアでイナビル吸入方法|インフルエンザの情報ならインフル・ニュースというページやiPhoneアプリまで作って頑張っていますが、処方する際に医師から「薬局で飲んで帰ってね」と言われたので、特に困ることはありませんでした。 久しぶりのインフルの感想 # 僕の場合、熱が上がりきる前にインフルだと判明して薬を服用したので、僕の中のイメージでは、そのまま熱が出ず、5日外出を控えれば大丈夫くらいに思っていたのですが、残念ながらそんなことはなく、次の日から2日間は熱と頭痛で動けず、3日目でようやく動けるようになりました。 残念ながらまだまだ世の中甘くはないですね。 まとめ # というわけで、昔懐しい感じのインフルエンザになったときの記録をしただけのブログになります。 13年の間にはてなダイアリーはお亡くなりましたが、こちらは生き残っていると信じて、またお会いしましょう〜。

プログラマ35歳定年説について個人的所感

February 4, 2019
life, career

今年というか去年末に35歳になりまして、いわゆるプログラマ35歳定年説の歳になったのだということに、最近気づきました。 35歳になってまだ2ヶ月くらしか経っていないのですが、いわゆる35歳定年説について、どのように感じるかを記録しておきたいと思います。 ここからは実感値として以下の5項目について触れていきます。 学習能力 集中力 体力 速度 品質 学習能力は上がっている # 学習能力については上がっていると思います。最大の理由は次の2つの能力が20代に比べて向上しているからです。 知識量が増えた 英語の文章を読む速度が上がった この結果、検索能力は20代と比べようもないほどに上がっているかと思います。そのため、分からないことがあっても、回答を得るまでかなりスピーディーですし、新しいことを学ぶときにも、ポイントを絞って要領よく学ぶことができるようになりました。 これらの能力が向上した理由としては、2冊の本(Emacs実践入門とAtom実践入門)を書いたことが大きな要因だと思います。なので、技術書を何のために書くのかと聞かれれば「自身の成長のため」と答えるのも良いでしょう(お金持ちにはなれません)。 集中力は特に変わらず # 集中力については特に変っていない気がします。小中と9年くらい書道していたからか、わりと集中するのは得意なのかなと思っています。 集中力に関しては幼少のトレーニングと性格が関連しているのかなと思っています。 体力は徐々に衰えている # 体力は徐々に衰えを感じています。特に20代には特に感じなかった肩凝り(というか正確には首痛)が慢性的に火を噴いていて、月に最低でも2万円は治療代に費しています。 結局のところ、肩首の疲れから目が痛くなったり、頭痛がしたりすると仕事を続けるのが困難なので、その日はもう終了といった感じです。 また、執筆業的には1日に1万文字以上書くこともあるのですが、それが続くと腕が痛くなって、キーボードをタイプするのが困難になって、仕事ができなくなるということもあります。 これについては、音声入力とかに本格的に切り替えるなどして対策を講じれば何とかなるかもしれないので、そろそろ真剣に検討していきたいと考えています。 速度は下っている # 仕事をするスピードは20代の頃に比べて下がってきている気がします。しかし、これは次の品質とのトーレドオフのような気もしていて、作業スピード自体は下っていても、完成したものの品質は以前よりも上がっていると思われるので、総合的に見れば完成までのスピード自体は維持、あるいは向上しているような気がします。 プログラミングについては、いきなり書き出すよりも脳内での設計に時間を割いて、実際に書く時間は短くなっている気がします。そのため、場当たり的なスピードは下ったかもしれませんが、結果的に手直しするコストは下がっているかと思います。 品質は上がっている # 上記で述べた通り、スピードは低下したものの完成したものの品質は向上していると思われます。 特に日本語の文章では、校正時の手直しが減っているように思われますが、ここらへんについては担当編集の意見も聞いてみたいところです。 まとめ # 以上、35歳定年説について自分自身が現状仕事をしている上でやっていけているのかという部分を5つの項目から振り返ってみましたが、体調について気をつければひとまずあと5年くらいは特に問題なくやっていける気がしました。 もちろん、これまでの仕事や学習の積み重ねで今があるので、今後も成長し続けていかなければ、将来的にはかなり厳しくなるという自覚はあります。 なので、今後については健康第一にしつつ、これまで同様に学習を続けていこうと思いました。 ちなみに学習する方法については、WBD+DB PRESSに特集を書くのが個人的には良いと思います。強制的に学習できて、かつ、しばらくの間WEB+DB PRESSが貰えますのでオススメです。いまだとTypeScriptあたりの特集を提案すると良いでしょう。

Emacsで自動修正を実現する auto-fix.el

January 30, 2019
emacs

AtomからEmacsに引越しする中で、AtomにあってEmacsにはなく、これがないと快適なプログラミングは厳しいというパッケージや機能が幾つかありました。 その中のひとつが、コードの自動修正機能を提供するパッケージです。 エディタでコードを自動修正する # 個人的な感覚ではGo言語とgofmtの登場以降、いわゆるインデントのタブ・スペース論争やコーディングスタイルについては、プロジェクト毎に利用するコードフォーマッタに任せるという流れで決着がついたと思っています。 最近良く書くJavaScriptやTypeScriptでは、ESLint、TSLint、Prettierが主流になったお陰もあり、僕みたいな様々な会社のプロジェクトで開発を行う人間も、インデント、クォート、文末のセミコロンなどの修正はプログラムに任せて、僕は適当に書いて保存するだけで自然に統一がはかられるようになりました。 Atomでは、この自動修正とエディタとの連携はlinter-eslintやatom-beautifyなどのプラグインによって実現していましたが、Emacsでは、個別の言語で修正させるパッケージはちらほらありますが、汎用的に使えるパッケージは僕の中ではまだ見つかっていません。 そこで、Elispの練習がてら自分でパッケージを作成してみることにしました。 汎用自動修正パッケージauto-fix.el # auto-fix.elはgo-mode.elのgofmt()を参考にして汎用的なコードの自動修正を実現するパッケージです。 コードの自動修正を実現するための方式として、ファイルを直接書き換える方式とバッファを書き換える方式の2種類がありますが、Emacsは設定によってはファイルを直接書き換えてしまうと読み込み直す手間が発生するため、go-mode.elで使われているファイルを保存する前にバッファを書き換える方式を採用しました。 また、コードの自動修正が必要かどうかを判別するためのテンポラリファイルの作成場所に、システムのtmpディレクトリを利用してしまうと、自動修正プログラムが利用する設定ファイルでプロジェクト内のディレクトリに関する設定がある場合(例えば特定のディレクトリのファイルは対象外にするなど)にリスペクトされないようになってしまうため、修正の対象となるファイルと同じディレクトリに作成するようにしています。 auto-fix.elの使い方 # auto-fix.elの使い方はgo-mode.elと同じようにauto-fix-before-save()をbefore-save-hook()にひっかけて利用します。 そして、auto-fix.elはマイナーモードとして実装されているため、auto-fix-commandとauto-fix-optionという2つのバッファローカル変数に修正したいプログラムと自動修正を実行するための引数をセットした上で、メジャーモードのフックで有効化します。 例えばシンプルにRubyでrubocopを実行させたい場合は次のような設定になります。 (add-hook 'auto-fix-mode-hook (lambda () (add-hook 'before-save-hook #'auto-fix-before-save))) (defun setup-ruby-auto-fix () (setq-local auto-fix-command "rubocop") (setq-local auto-fix-option "-a") (auto-fix-mode +1)) (add-hook 'ruby-mode-hook #'setup-ruby-auto-fix) これでruby-modeでファイルを編集して保存するだけで、ファイル保存時にrubocopによる自動修正が実行されるようになります。 flycheckとの組み合わせ # 僕はflycheckを利用していてプロジェクトごとの修正プログラムを利用しているため、次のような設定で利用しています。 ;; flycheck (defun my-use-local-lint () "Use local lint if exist it." (let* ((root (locate-dominating-file (or (buffer-file-name) default-directory) "node_modules")) (eslint (and root (expand-file-name "node_modules/.bin/eslint" root))) (tslint (and root (expand-file-name "node_modules/. ...

AtomからEmacsに乗り換えて気付いたEmacsの底力

January 28, 2019
emacs

2018年の年末にAtomからEmacsにスイッチしてしようと決めてから、年末年始を利用して快適にコードが編集できるようにEmacsを鍛えていました。 Atomは大変素晴しいコードエディタで、初心者がプログラムを書く上で、必要な機能が最初から備わっています。これはVSCodeも同様でしょう。まさに生まれながらのプログラミングエディタと言えます。 Emacsに復帰してあらためて思ったのは、Emacsは生まれながらのプログラミングエディタではないということです。Emacsの初期設定でプログラミングをするには、自動補完もなければGitの対応も不十分で、あまりにも機能が足りていません。 ですが、Emacsが他のエディタと比べて劣っているかと言えばそうではありません。 Emacsの最大利点は即時拡張性 # 僕が感じたEmacsがAtomやVSCodeと比べて優れている点は「即時拡張性」です。 Emacsはエディタとして操作している途中の、ありとあらゆるタイミングで設定の変更が可能です。つまり、コードを書いているときでも、キー操作、文字装飾、編集機能、表示項目、コマンドなど不満に感じた部分をリアルタイムで自分の手に馴染むように調整できます。 もちろん、AtomやVSCodeでもたいていの設定変更はできますが、そのためには設定画面を開いて、該当する項目があるかどうかを調べたり、ブラウザでAPIドキュメントを開いて調べる必要があるため、設定がそもそも変更可能なのかを調べるだけでも時間がかかります。 しかし、Emacsの場合は、M-x describe-function(C-h f)、M-x describe-variable(C-h v)、M-x apropos-command(C-h a) 、M-x customize、M-x find-libraryなどのコマンドから、関数、変数、用意されている設定(変数)、コマンド、ライブラリのソースコードを探索して 、すべての調査をEmacsの中のみで完結して行い、提供されているすべての設定が変更可能となります。 もちろん慣れもあるのですが、慣れた人にとってEmacsの設定を調べて変更するまでの速さは圧倒的なスピード感があります。 M-x customizeによる設定 # 今回設定に関しては、リハビリと実験をかねて新規で作り直した上で、できるだけM-x customizeによって自動生成される設定を利用して設定を行っています。 M-x customize(Easy Customization Interface)はEmacsに用意されている設定画面で、なんとなくGUIっぽい雰囲気でインタラクティブに設定を変更できる機能です。上部のサーチボックスに調べたい機能名を入力してエンターを押せば、設定を検索することができます(M-x customize-aproposでミニバッファから検索することも可能です)。 M-x customizeによる設定の利点は、設定値を入力して保存すれば自動的に設定内容がinit.elに書き出されることと、設定値の型が定義されているため、設定すべき値を間違いにくいという点です。 これまでのinit.elに直接設定を書く方式に慣れている人からすると、若干やぼったさはありますが慣れてくれば悪くない感じです。 Emacsと私の今後 # とりあえず、現在開発中のプロジェクトとブログを快適に書けるようにすることを目標に設定をしてましたが、ようやく良い感じになってきました。 自分が快適にコードを書くために、久しぶりにElispパッケージを書いたりして楽しいEmacsライフを送っていますので、それらについては徐々に紹介していければと思います。 なお、自分が書いたEmacs実践入門を片手に設定していたのですが、自分で書いだけあって自分が欲しい設定が書いてあり大変便利でした。ちなみに、年末からKindle版が発売されていて、[改訂新版]Emacs実践入門 Gihyo Digital PublishingからEPUBを買うことも出来るので電子書籍で欲しい方はぜひ。

NetlifyではじめるHugo

January 27, 2019
hugo, netlify

2019-03-04 追記 後にドメインを blog.tomoya.dev へ移行しました。 はてなダイアリー終了のお知らせから、ブログをどうしようか悩んでいたのですが、はてなダイアリーが終了するのであれば、はてなブログもいつかは終了するかもしれないということで、自分でブログを運用することにしました。 自分で運用する場合は、サーバーやソフトウェア(CMS)などのメンテナンスが面倒なのですが、いわゆる静的 サイトジェネレーターのHugoと静的サイトホスティングサービスのNetlifyを組み合わせれば、基本的に無料でhttpsにも対応したサイトが運用できるのでは?ということに気付き、自分で運用しても良いかなと思った次第です。 Hugoを選択した理由 # HugoはGoで書かれた静的サイトジェネレーターです。同様のもとしてはJekyllが老舗で、最近ではGatsbyなどが有名です。 そんな中、今回なぜHugoを選択したのかと言うと、HugoとEmacs(org-mode)の相性が良さそうだからというのが一番の理由です。去年末のEmacs忘年会を機会にEmacsに本格復帰することにしたので、その肩慣らしとしてブログもEmacsと相性の良いものにしました。 テーマは、とりあえずざっとHugo Themesを見て、スマホでも見やすいEvenにしました。そのうち自分でテーマを書くかもしれまねせんが、当面はこれでいきます。 Netlifyを選択した理由 # 静的サイトのホスティングであれば、別に自前でAWSで構築しても良かったのですが、NetlifyはGitHubにプッシュすれば自動でデプロイまでしてくれるということで、無料ということもあり試してみようと思いました。 同様の無料静的サイトホスティングのGitHub Pagesとの違いについては、GitHub PagesとNetlifyの比較を用意しているので確認してみると良いでしょう。 Hugoによるサイト構築メモ # このブログのURLがhttps://blog.tomoya.appなので、GitHubでblog.tomoya.appというリポジトリを作成しました。そして、Quick Start | Hugoを参考にしながら次のようなコマンドでサイトを構築しました。 $ brew install hugo $ hugo new site blog.tomoya.app $ cd ./blog.tomoya.app $ git init $ git add . $ git commit -m 'Initial commit' $ git submodule add https://github.com/olOwOlo/hugo-theme-even themes/even $ git commit -m 'Add even theme' $ cp . ...

Hello World

January 25, 2019
hugo

This is my first post using Hugo. これはHugoを使った私の最初の投稿です。 見出しレベル2 # コードサンプル const world = 'World'; const greeting = (someone) => `Hello, ${someone}!`; console.log(greeting(world)); 見出しレベル3 #