Tech系サービスやガジェットの使い心地、自分の作業環境、資産運用について気が向いたときに記録を残しています。

記事内のAmazonアソシエイト適格販売及び、Google Adsenseでお小遣いを得ています。

銀軸キーボードの代わりにNiz Plum 82キーボードを買いました

キーボード交換のモチベーション

昨年、オフィスがフリーアドレス化して各人にロッカーが割り当てられたのですが、仕事用に使っていたフルキーボードはロッカーのサイズに収まりきらず泣く泣く手放しました。

しかしその後1ヶ月経ち、やはりノートPCのキーボードで仕事をするのには耐えられそうにない…という結論に。

そして、2020年のCOVID-19流行に伴ってオフィス用のキーボードというものがいらない可能性に気が付き、自宅とたまに行くオフィス兼用のキーボードということで、US配列のコンパクトなBT兼用キーボードがほしい!ということになりました。

※今までの自宅用キーボードはARCHISSの銀軸テンキーレス、東方やるのに喰らいボム精度が良かった

ひとまず、交換に際しての要件を書き出してみます。

  • コードを書くことが増えたのでUS配列がいい
  • 自宅ではゲームもやるので、有線接続が必要
  • 持ち運びと会社PCの接続を考えてBT接続とのハイブリッドは必須
  • HHKBみたいな割り切った配列は無理!(Winユーザーなのでファンクションキーの頻度が高い)
  • 今更TypeC充電じゃないデバイス増やすとかありえない

キー配列の問題さえなければ、HHKBのHybrid-Sが最も良い候補だったのですが、US配列はあまりにもミニマル。カーソルキーほしいしHomeとかPgUp/Down結構使うしF1~F12も使う。

出会い・購入

そんな中知人から勧められたのが中国の新興メーカーNizのキーボード。

www.nizkeyboard.com

HHKBやRealforceと同じ静電容量無接点方式で、BTモデルを持ちつつなおかつキー配列が豊富! 欠点はちょっと筺体が安っぽいところ。

販売は主にAliexpressの公式ストアや、Amazonの輸入代理店っぽいセラーからとなる模様。

Aliexpressのほうがちょっと安いのでそちらで注文、Standard ShippingやePacketではなくJCEX Expressという良い発送方法で発送されたので、わずか3週間ほどで到着した。

Amazonで買うと日本語でもサポートも提供されるらしい。

開封

f:id:gensobunya:20200510184520j:plain
開封したところ

f:id:gensobunya:20200510184611j:plain
82キーモデルを購入

購入したのは、ファンクションキーと右端にいくつかのキーが付いた82キーモデル。BLE対応のモデルで、ゲーミングなRGB LEDはオミットした。

f:id:gensobunya:20200510184726j:plain
開封

同梱物は、USB-Type Cケーブル・キープラー・BLEアダプタ(専用?)・荷重変更スプリング・Macキートップなど。

f:id:gensobunya:20200510184900j:plain
内容物

説明書が中国語ーーーーーーーーーーーー!英語にしろ英語に!!!!!!!! 雰囲気でBTの接続方法(Fn+F9~11長押し)だけはわかった。

f:id:gensobunya:20200510185011j:plain
英語でおk

f:id:gensobunya:20200510185125j:plain
LEDの明るさは調節できる(これは輝度最大)

ペアリング中は細かく該当のBT端末対応のキーが点滅する。待機中はゆっくり点滅。

Fn+上下キーでLED輝度も調節できるので明るすぎる対策はできる。

キートップはARCHISSに比べて低め。プリントではなく二色整形キートップが気に入っていたのでこれは後々交換かもしれない。

f:id:gensobunya:20200510185321j:plain
キートップの高さがやや低め

新しいファームウェアが出ていたので、公式のサポートから落として公式ツールを使ってインストール。 サポートのファイル置き場がGoogle Driveなのはちょっと笑った。中国メーカーでも使えるんだ…

drive.google.com

インプレ

f:id:gensobunya:20200510185349j:plain
カニカルキーボード勢からすると異様なほど静か

銀軸に比べてとにかく静かになった。タイピングしている実感が薄いがそのうち慣れるだろう…スコスコという触感、これはこれで癖になりそう。

BTペアリングは非常にすんなり通った。LEDのおかげで切り替えに伴うあれこれも視覚的にわかりやすいのもGood。

Win10の場合、最初は日本語キーボードとして認識していたので設定から変更して再起動する必要があった以外はすんなり導入完了。キーマクロやマッピング変更などの機能もモリモリなのだが、今の所BT接続先変更以外の機能は利用しなさそうだ。

このモデルは人気らしく、2019モデルの中で唯一売り切れになっている。2020年モデルもちょっと興味があるのでウォッチしておきたい。

ウルトラワイドディスプレイでQoLを爆上げした話

給付金は曲がった板になりました

f:id:gensobunya:20200425011800j:plain
曲がった板

今まで、ASUSの21.5インチディスプレイを使っていたのですが、Slackワークスペースの細かいemojiが読みづらかったんですよね…

友人のすすめで「縦の解像度があると捗る」「ウルトラワイドはいいぞ」「曲がっているとかっこいい」との話を大量に浴び、気がついたら釣られて発注していました。

別に平面でもよかったのですが、曲面を試してみたかったのと平面は入荷が遅くてすぐに使うことができなかったので勢いで曲面ディスプレイを購入!(曲面で+1.5万円)

f:id:gensobunya:20200425094847j:plain
とにかくデカい

何が変わったか?

画面サイズの変化

f:id:gensobunya:20200425014508j:plain

Full HD(1980 x 1080)からUWQHD(3440 x 1440)へ、基本的に二分割して使うので実質的には1720 x 1440の2枚です。

縦方向のスペースが増えたことにより、文字を読み書きする作業効率が爆発的に向上しました。(プログラミング・ドキュメントを読む・Slack・Twitterなど…)

幅は狭くなりましたが、FHDでもブラウジング時は大抵のページの横幅は余白になっていますし、意外と不便は感じません。

デュアル→シングル

f:id:gensobunya:20200425014611j:plain
dual

f:id:gensobunya:20200425014642j:plain
single

モニターアームによる2画面から、1画面になったので体の正面に常にディスプレイがある状態になりました。

これにより、操作するメイン画面が変わるごとに起きる体の方向変化が起こらなくなり、不自然な体勢でいることが少なくなったように感じます。

どちらかを注視する場合はキーボードの位置をちょっとだけ調整しています。

画質

これが一番の変化ですが、ドットが小さくなったことで細かい模様や画像がわかりやすくなりました。 今までなんであの画質で我慢していたのか全くわかりません…小さいemojiもはっきりわかります、最高。

Webカメラの向き

今まではサブディスプレイにWebカメラC270を付けていたので、メイン画面をいじっている時は横顔になったりしていましたがそういうことがなくなりました。

リモートワークどうする?

以前の記事ではスイッチャーを使って、デュアルディスプレイの片方だけを共有していました。

このディスプレイは2系統入力があり、左右に分割してデュアルディスプレイと同じことができます。 当初は同じことを実践しようとしていたのですが、どうやらこれを行うと、同じ入力元でも色味が変わったりすることがあるとの体験談を聞いて、シンプルに1入力を切り替える方式に変更しました。

f:id:gensobunya:20200425095211p:plain
構成図

明確に仕事とプライベートが切り替わるようになったので、仕事が捗る(はず)。

おまけ

届いた日に新型が発表された

リフレッシュレート 60→100
+USB typeC input
+USB3.0 hub *2
+ -5000円
- IPS液晶→VN液晶

35インチの視野角でVN液晶はつらそうなので、平面34インチがよさげ?

自宅のインターネット回線が遅い人が今すぐ確認すること

f:id:gensobunya:20200423124005p:plain
これくらい速いと、捗ります

様々な会社がリモートワークに移行している中、自宅の回線が遅くて困っている人がTwitterで散見されます。

ビデオ会議ができないと、仕事もそうですがプライベートでのDiscord飲み・Zoom飲みにも影響があり著しく QOLを下げるご時世となっています。

固定回線引いてるのにインターネットが遅い!という方向けの、速度改善チェックポイントをつらつらと書いていきます。

なお、モバイル回線はスピードが早い場合でも、Ping値などのレイテンシが非常に大きく、対複数人のリアルタイムコミュニケーションに置いては論外のクオリティですので早めに固定回線を契約することをおすすめします。

主な要因

  1. 自宅の無線環境が悪い
  2. NTT地域局が混雑している
  3. 集合住宅内の回線キャパシティがいっぱいいっぱい

TL;DR

前提

  • 11ac対応ルーターを使って電波強度は十分確保されている
  • 自宅(もしくは自室)まで光ファイバーが配線されている
  • フレッツ系サービスを使っている(au光, eo光, NURO光などではない)

早見表

  • (集合住宅で)VDSLを使っている→引っ越せ
  • 何も考えずプロバイダと契約している→V6プラスを契約しろ、対応ルーターを買え
  • 光回線だけどもV6プラスが提供されてない→諦めるかプロバイダを変えろ
  • (集合住宅で)V6プラスだけど最近遅くなってきた→戸建てプランを引くか、管理会社に回線増強を交渉する

改善の前提

2~3はフレッツの光回線が自宅(もしくは自室)まで引かれていることを前提とします。

VDSL(部屋に直接LANコネクタが埋め込まれている場合)は人権がない回線形態なので遅い場合はどうしようもありません、大家に光配線方式への変更か回線増強を交渉しましょう。それでも地域局が混雑していた場合は改善しないかもしれません。

1. 自宅の無線環境が悪い

2.4GHz帯の無線(IEEE 802.11b/g)を利用している場合、Bluetoothや電子レンジと干渉します(流石にもう少ないとは思いますが…)

IEEE 802.11ac対応の無線LANルーターに交換しましょう。 対応ルーターを使っていても、ルーターは初期設定だと11b/gのアクセスポイントも使っているので、接続しているノートPCやスマートフォンが11acのアクセスポイントに接続しているかどうかも確認してください。

複数人で同時に利用する場合は、無線LANの最大速度も必要になるので上位モデルも検討してください。

自宅が大きくて仕事場とルーターが離れている場合、無線LANの電波が届いていない場合も考えられます。5GHz帯の電波は2.4GHz帯と比べて回り込む力に欠けているので、中継機やメッシュWiFi機器の購入をおすすめします。

2.NTT地域局が混雑している

一番よくあるパターンだと思います。簡単に言うとIPv4接続を行うための接続が混雑していてNTT地域局でトラフィックが砂時計みたいな状態になっている状態です。

IPv6であるだけではなく、IPv4接続をIPv6接続上で行う IPv4 over IPv6 と呼ばれるサービスを使わないと全体的な改善はされません

プロバイダによって名前は様々ですが、殆どのプロバイダーでは 「V6プラス」 という名前でオプションが提供されています。

このサービスを受けるためには、オプションの契約以外にもDS-Lite or MAP-Eと呼ばれる規格に対応しているルーターも必要となります。先程のNEC WG1200HS2は対応している最安クラスの製品です。

大抵の人はこれで爆速回線を手に入れることができます。やったね!

おまけ追記

一部のプロバイダ(nifty)でv6プラスのユーザーに帯域制限をかけているとかなんとか…

3. 集合住宅内の回線キャパシティがいっぱいいっぱい

この場合は厄介です。

いわゆるフレッツなどのマンションプランでは、集合住宅全体で1つの太い回線を共有しており、全員で同時接続するとどうしても1軒あたりの速度が低下します。

大本の回線のキャパシティを越えてしまうと、管理会社に交渉して回線を増強することとなります。住民の理事会などに掛け合うしか有りませんね…

飛び道具として、マンションタイプではなくホームタイプの回線を契約することで、専有回線を使うことができるので回線費用は嵩みますが自己解決することができます(物件側がホームタイプ回線を許可されていることが前提)

振り返り

  • (集合住宅で)VDSLを使っている→引っ越すか、回線増強を交渉
  • 何も考えずプロバイダと契約している→v6プラスを契約する、v6プラス対応ルーターを買う
  • 光回線だけどもV6プラスが提供されてない→諦めるかプロバイダを変える
  • (集合住宅で)v6プラスだけど最近遅くなってきた→戸建てプランを引くか、管理会社に回線増強を交渉する

在宅環境を改善してこの難局を乗り切りましょう。

どんなに頑張っても100Mbps出ない場合

LANケーブルの規格が古い可能性があります。経路のどこかでうっかり100Mbps上限のLANケーブルを使っていないか確認しましょう。

リモートワーク用に自宅の備品を会社PCと共有できるようにした

自宅PCはデスクトップPCを使っており、デュアルディスプレイ体制になっています。

昨今の事情に伴って、2月末からテレワークになっていた弊社ですが、ディスプレイやらキーボードをデスクトップPC本体から付け外しするのは非常に面倒なので会社のノートPCはそのまま使っていましたが、不便さをいい加減耐えられなくなりイケてるARCHISSのキーボードM570t、自然な体勢で使えるディスプレイで仕事をすることを決意しました。

自宅と会社PC両方でUSB type-Cが使えれば、ドックに全ての周辺機器を集約して適宜ドックとの接続を切り替えるという構成が組めたのですが、残念なことに両者ともType-Cコネクタは有りません。

HDMIとUSBでつながっているそれぞれの周辺機器をスイッチできるようにセットアップします。なるべく安く…

古き良きスイッチャー

古の時代からあるボタン切替のスイッチャーをそれぞれ購入。

これらで、ディスプレイとキーボード・トラックボールを共有すべく、配線を分岐します。 ディスプレイはメインを共有して、サブはデスクトップ専用にすることで常にプライベートのDiscordやSlackを見るだけはできるようにしています

f:id:gensobunya:20200406141242p:plain
卓上構成

これで、卓上に2つあったM570tが1つになり、ノートPCの画面を覗き込むこともなくなりました。めでたしめでたし。 ディスプレイとUSBの切替が別になるのは少し不便かと思いましたが、ちょっとだけどちらかを操作したい時はUSBだけ切り替えればいいのでむしろ便利でした。

追加のHDMIケーブルは忘れず買いましょう。

追加で購入したAmazonベーシックのケーブルを含めて3000円程度でうまくやれました。

Material-UIのDrawerをこれ以上なくシンプルに使ってみる

サークルサイトを更新した際に、ReactのUIフレームワークであるMaterial-UIを使ってモバイル表示用にサイドバーをドロワー化して開閉できるようにしました。

公式サンプルは機能を十全にアピールするためにかなり複雑だったので、最低限のコードで済むようにシンプルな実装にしたものを備忘録として公開しておきます。

主な実装ファイルはこちら

github.com

React Hooksを利用して開閉状態を保持する

まずいきなりReact Hooksの知識が必要となります(Hooksについてはググってください)

const Sidebar: React.FC<HeaderProps> = ({ title }) => {
  const [drawerState, setDrawerState] = React.useState(false)

  const toggleDrawer = () => {
    setDrawerState(!drawerState)
  }

//後略

公式サンプルでは4つのドロワーを一度に表示しているのでドロワーの状態を4つ配列にしていますが、今回は1つでいいのでdrawerStateを開閉状態として定義します。初期値(アクセス時)は閉じていてほしいので初期値はfalseです。

toggleDrawer関数はメニューボタンクリック時やドロワーを閉じる際に起動する関数で、drawerStateを切り替えるだけのものです。

ドロワー本体を実装する

       <TitleGrid item sm={12} xs={12}>
          {/* モバイルドロワー部分開始 */}
          <Hidden smUp>
            <MenuButtonBox>
              <IconButton color="inherit" style={{ padding: 0 }}>
                <MenuOpen
                  fontSize="large"
                  aria-label="open drawer"
                  onClick={toggleDrawer}
                />
              </IconButton>
            </MenuButtonBox>
            <Drawer
              anchor="left"
              elevation={16}
              open={drawerState}
              onClose={toggleDrawer}
            >
              <DrawerGrid
                container
                onClick={toggleDrawer}
                onKeyDown={toggleDrawer}
              >
                <DrawerInnerGrid item alignItems="center" xs={12}>
                  <Externals />
                </DrawerInnerGrid>
                <DrawerInnerGrid item alignItems="center" xs={12}>
                  <Bio />
                </DrawerInnerGrid>
              </DrawerGrid>
            </Drawer>
          </Hidden>
          {/* モバイルドロワーここまで */}

モバイルアクセス時のみドロワーを使うので、ドロワー部分は<hidden>で囲みサイズに応じた表示属性を付与しておきます。

メニューボタンのonClick属性にtoggleDrawer関数を起動するよう設定して、<Drawer>opendrawerStateを指定することでdrawerStateによってドロワーの開閉が制御されるようになります。

あとはサンプルと同様にonClose,onKeyDown属性に状態変更の関数を指定しておくと、ドロワーのリンク以外の場所をクリックすればtoggleDrawerが起動して状態を変更、ドロワーが閉じるようになります。

ドロワーそのもののコンポーネントは自由に指定できます。

Gatsby.jsの翻訳を手伝ってみたら(肩書だけ)OSSのメンテナーになった話

お世話になっているGatsbyのドキュメントを和訳するプロジェクトが進行していたので、一部を手伝うことにしました。 こちらのリポジトリをフォークしてIssueで宣言した上で翻訳・マージすることになっています

github.com

準備までの手順

  1. Issueで翻訳する場所を宣言する、反映を確認
  2. リポジトリをフォークする(Github上でボタンポチ)
  3. git clone [my-folked-repository]
  4. cd gatsby-ja
  5. git switch -c docs/accessibility-statement(docs/accessibility-statement.mdを翻訳する場合)
  6. yarn install

環境構築でハマったとこ

gitのバージョンが古くてswitchが使えなかったのでアップデート

sudo add-apt-repository ppa:git-core/ppa
sudo apt install git`

yarn使わずnpmで生きてきたのでyarnを新規インストール

公式の通り

classic.yarnpkg.com

curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -
echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list
sudo apt update && sudo apt install yarn

翻訳

  1. ブランチを切る
  2. スタイルガイドに従って翻訳する
  3. pull requestを出してレビュー対応する

Githubを用いたチーム開発している人には慣れたものだと思いますが、自分は初めてだったのでかなり緊張しました。

報酬

github.com

いくつか翻訳したページの一つが無事Mergeされました!
PRのマージに連動して、メンテナーのGatsby.jsのOrganizationに追加され、公式グッズのバウチャーも頂けることになりました。

maintainerってグループに入れられたからメンテナー名乗ります ドキュメント翻訳のContributerってプロフィールに書いといた。

まさかこんな形でOSSメンテナーの肩書(ただし翻訳のみ)を手に入れられるとは…5つPRが採用されると更にグッズが貰えるようなので、意欲が刺激されますね。

Gatsby.jsでGraphQLのスキーマから型を生成して利用する

TypeScript導入時はコンポーネント内に自分でPropsの型を書いていましたが、全てのコンポーネントでこれを行うと非常に面倒かつ、GraphQLのスキーマとオリジナルの型で二重に型を生成することになるので、自動生成するプラグインを導入してコンポーネントから利用します。

gatsby-plugin-graphql-codegenの導入

npmでインストールした後、生成するtypesファイルの宛先と監視するディレクトリを指定します。 これらはGraphQLのクエリを生成する部分が指定してあればよいので、特に目立った構成変更をしていない自分の場合はREADMEの指定をそのまま利用しました。

{
      resolve: "gatsby-plugin-graphql-codegen",
      options: {
        fileName: "types/graphql-types.ts",
        documentPaths: [
          "./src/**/*.{ts,tsx}",
          "./node_modules/gatsby-*/**/*.js"
        ],
        codegenDelay: 200
      }
    },

出力先fileNameは監視するディレクトdocumentPathsと同じ場所にしてしまうと自分を参照して無限ループになるので注意。

これで、ローカルサーバーを起動した後にクエリに変更を行うとプロジェクト内で使える型データがtypes/graphql-types.tsに吐き出されます。

コンポーネント内で型を利用する

前回までは自分で型を書いていました。

interface StaticQueryProps {
  allMarkdownRemark: {
    edges: Edge[]
  }
}

interface Edge {
  node: {
    frontmatter: {
      date: string
      title: string
    }
    id: string
  }
}

const recentPost: React.FC = () => (
  <StaticQuery
    query={graphql`
      query RecentPostQuery {
        allMarkdownRemark(limit: 4, sort: { fields: frontmatter___date, order: DESC }) {
          edges {
            node {
              frontmatter {
                date(formatString: "YYYY/MM/DD")
                title
              }
              id
            }
          }
        }
      }
    `}
 // render

自動生成した型を使うために、import文を1行書いて型情報を読み込みます。 この場合、GraphQLのクエリに名称をつけておくと[Query名]Queryという名称で型情報が出力されます。

~Queryという名前をクエリにつけていたので、~QueryQueryという型にならないよう全て書き直しました…

//...import
import { RecentPostQuery } from "../../types/graphql-types"

const sportsPost: React.FC = () => {
  const data: RecentPostQuery = useStaticQuery(
    graphql`
      query RecentPost {
        allMarkdownRemark(
          sort: { fields: frontmatter___date, order: DESC }
          limit: 4
        ) {
          edges {
            node {
              frontmatter {
                date(formatString: "YYYY/MM/DD")
                title
                cover {
                  childImageSharp {
                    fluid {
                      src
                    }
                  }
                }
              }
              id
              fields {
                slug
              }
            }
          }
        }
      }
    `
  )
//render

f:id:gensobunya:20200204173243p:plain
vscode capture

VScodeの補完と参照もバッチリ効くので、もうPropsの中身を見る度にあっちこっちのコンポーネントを見る必要なし!

欠点

各Functionの返り値を明確に意識する必要が出てきます。本来なら当たり前ですが、Vanilla JSだとよしなに書いても問題なく動いてしまうので、最初は苦労しました…