かめあるき

プログラミング駄文。

【転職エントリ】SEを退職し、SWEになります。

新卒から2年半ほどお世話になったSIerを退社し、とあるスタートアップでソフトウェアエンジニアになります。

この度自分がSWEとして転職できたのは、恵まれた環境とすごい幸運の連続によるものです。

それでも何もしていなかったわけではないので、もしかしたら運気を上げる行動があったかもしれないと思い、書き残すことにしました(あと退職&転職エントリを書くというやつをやってみたかった)。

私自身、異職種のSEからSWEになろうと思ったとき、そっくり同じキャリアを歩まれた方の体験談等があまり見つからず、正直とても不安でした。

それでもSWEやその他異職種の方の就職・転職エントリは大変参考にさせていただきました。

私が公開する内容もどなたかの参考になれば幸いです。

略歴ときっかけ

私大文系卒、IT未経験でSIerに入社しました。

パソコンを触ること自体に拒否感は無い方でしたが、プログラミング経験やCS知識は皆無でした。社会・人文科学系だけど研究の一環でプログラミングに触れていた、ということも全くありませんでした。なんなら入社当初はブラインドタッチもできませんでした。

実はプログラミングをやろうとしたことはあるのですが、Webサイト作成で文字色を変えて飽きたり、変数・関数のような概念の理解ができなかったりですぐに挫折しました。また、お金を掛けて本を買ったり学習サービスを購読したりするほど熱意はありませんでした。

そのため、入社当初は開発部署でシステムエンジニアとしてIT知識をつけてから、給与が高そうなIT営業やコンサルタントの道に進もうと考えていました。

ところがいざ新卒研修でプログラミングに触れると、とても楽しくて夢中になりました。自分が思っていたより真剣に研修に臨み、業務時間外も次の日の研修の予習や自主学習をして過ごしました。

このときからすでに、周囲との技術に対する熱意の差異や期待されているキャリアとやりたいこととのギャップを感じていました。もとは自分も技術力だけで食っていくつもりではなかったので、当然といえば当然の状況でした。

技術力を高めることでキャリアアップしていく道はないかと調べたところ、「ソフトウェアエンジニア」という職種があることを知りました。また、なぜかインターネットにGoogleSWEの方を始めとして、多くのエンジニアの方々の転職エントリが気前よくごろごろ転がっているのを見つけました。

転職エントリを読み漁っていたところ、自分も例に漏れずLillianさんの転職エントリにぶち当たり、強く感銘を受けました。

note.com

ちゃらんぽらんな自分とLillianさんでは人生で積み上げてきたものからすでに大きく差があり、あの短期間でのあの勉強量も決して真似できるものでは無かったのですが、数年掛けて勉強すれば自分もソフトウェアエンジニアの肩書を得るくらいはできるのではないか?と思うようになりました。

こうして「ソフトウェアエンジニア」になるために、「CSを勉強する」という目標と行動指針ができました。漠然と30代に入る前にSWEになりたい、新卒3年目で一度就活に挑戦しよう、などと考えていました。

やったこと

勉強

いわゆるコーディングテスト対策もやったのですが、あまり強くないのと強い転職エントリがたくさんあるので割愛します。

どちらかというと非CS非ソフトウェアエンジニアとしてどんなことをしたかに焦点を当てて書いています。

資格取得

前職では資格手当が充実していたこともあって、勉強するのに資格取得をよく利用しました。ベンダー資格も含めて半期で1個以上、多いときは3個くらい取得していました。

資格取得には賛否両論ありますが、自分の状況には合っている勉強方法だと考えていました。

自分にとってのメリットは以下のとおりです。

  1. 申し込みさえすれば勉強に締切が設けられ、受験費用も安くないため、だらだら勉強することを避けられやすい。
  2. 体系的な勉強が必要になるので、自分の好みや経験で学習範囲が偏ることを防ぎやすい。
  3. 勉強した成果が資格として形に残るため、履歴書に記載するなどしてアピールしやすい(特に、学位や職歴がない自分でもCS分野を勉強したことが説明しやすかった)。
  4. 正直コードを書いているほうが楽しいので、避けがちな座学をきちんと勉強するいい機会になる。
  5. 勉強の練習になる。

有名所でいうと基本情報・応用情報がありますが、履歴書に書いておけば勝手に手に職ついたり、評価が上がったりするというのは幻想です。

しかしいくつか転職エントリなど読んでいたところ、CS学位がない方が基本情報・応用情報を通じてCSの基礎固めをした経験が綴られているのをいくつか見かけました。

実際自分もそのようにして面接に挑んだところ、面接官には一定の安心感を与えたようでしたし、自分の周囲では「起床試験」などとネットで揶揄されるほど評価が低い資格ではないようでした(意外でした)。

受験後、普段使わない知識はほとんど忘れてしまうのですが、一度勉強した経験があるだけでもハードルがかなり下がるので、時間の無駄だとも考えていません。

学習サービスの利用

はじめは教材にお金をかけることに抵抗があったのですが、ソフトウェアエンジニアになろうとおもってからは惜しまずバンバンお金を使うことにしました。

ぶっちゃけお金を払ったのにほとんど使わなかったものもあるのですが、出し惜しみせず学習環境を充実させることができたのはとても良かったです。職に就いていて実家暮らしで他の娯楽にお金をあまり使わずに済んだことも幸いしました。同じノリで技術書も山のように積んでいます。なんとかしたいです。

下記は思いつく限りの登録したサービス一覧です。

  • Progate
  • paiza ラーニング
  • PyQ
  • DataCamp
  • Recursion
  • educative
  • LeetCode
  • アルゴ式(無料)
  • AOJ(無料)
  • Ping-t
  • Udemy

あまり利用していないものもあるため各々の良し悪しには触れませんが、勉強するまでのリーチが短くて取り組みやすく続けやすいのが一番の利点でした。ただ楽すぎて自分で作った環境での勉強を怠ってきてしまったのが今の若干の課題です。

学習サービスではありませんが、ソフトウェアエンジニア面接対策のサイトもたくさん見ました。SEやいわゆるWeb系エンジニアなどとは面接形式が異なるため、経験や知識がなく聞ける人もいない状況でとても助かりました。コーディングテストはまだまだ苦手ですが、今後のためにも勉強を続けたいです。

github.com

github.com

AtCoderももちろん取り組みました。まだ茶色コーダーなので今後も続けていきたいです。

各サービス内でコミュニティ機能があったり、自分でもTwitterをやっているのですが、エンジニアになりたくて勉強している人と繋がったりは結局あまりしませんでした。自分が消極的な性格であることもあると思うのですが、雰囲気が苦手であまり馴染めませんでした。一人ぼっちでもソフトウェアエンジニアになりたいことに変わりなかったので、特に困ったことはありませんでした。

ただ、実際にソフトウェアエンジニアとして働いている人が周りにおらず、客観的に自分がどう映るのか、どういった勉強が足りていないのか相談できる機会がなかったので、後述するBuild@Mercariのような機会でめちゃくちゃ自分語りしてアドバイスもらったり、MENTAでお金を払って相談してみたりしました。

転職サイト登録

あまり知識がなかった頃、ソフトウェアエンジニアという職は外資のイメージが強かったので、LinkedInは登録しました。実際に使っていると、国内のスタートアップやメガベンチャーがソフトウェアエンジニアの求人を出していることも多かったので、国内外問わずソフトウェアエンジニアを目指すのであればとりあえず登録しておくのが良いかもしれません。

資格を取得したときなど、こまめにプロフィールを更新していました。LinkedInのプロフィール項目は履歴書に似ているので、自分の履歴書の状態を確認したり、実際に履歴書を書くとき参考にしたりできました。学歴・職歴がどうしても弱くなるのがわかっていたので、履歴書を意識しながら数年かけて行動できたのはとても良かったと思います。投稿や他の人との交流はまったくしていませんでした。

またpaiza ラーニングを利用していたので、paizaのスカウトも受け取るようにしていました。paizaランクはAランクでした。

LinkedInのDMやpaizaのスカウトなどを受け取っていると、自分の履歴書だとどの程度のポジション・年収になるのか、楽に身の程を知ることができるのが良かったです。やはりCSなし・新卒SE数年程度だと、外資系ならサポートエンジニアやコンサルタント、国内だとSEやWeb系エンジニアのポジションで、年収はほぼ現状維持かそれ以下(外資は上がるポジションもあった)といった感じでした。

もちろんスカウトがこないから選考を受けられない・内定をもらえないというわけでは無いのですが、企業から自分がどういう人材に見えるのかの一つの指標にはなりました。

ちなみに転職先企業はLinkedInからお声がけいただきました。ソフトウェアエンジニアのポジションで給料もとてもあがるので、秒で内定承諾しました。

Build@Mercari

mercan.mercari.com

Webアプリケーション開発やハッカソンなどを通じた学習兼交流プログラムとメルカリでの就業型インターンシップの2階建てになっているプログラムです。メルカリが提供しているプログラムでインターン選考もあるというと気が引けてしまいそうですが、これは非エンジニアや非CSでも参加できる設計になっています。

似たようなプログラムにGoogle STEPプログラムがあるのですが、これは学生限定です。Build@Mercariは珍しく社会人でも参加可能で、まさに自分にピッタリのプログラムでした(実際には社会人の参加者はかなり少ないらしいのですが、特に困ったことはありませんでしたし、働きながら参加してると感心されることが多くとてもいい気分になりました)。非CS社会人が参加可能で、インターンシップのチャンスもあるというのはほぼ他にない機会と言えます。

毎年内容には変動があるようなのと、守秘義務があるので公開されている内容以上のことは言及できないのですが、他の参加者やメルカリ社員に質疑応答や交流ができる上、学習リソースも惜しまず提供していただけました。

自分は後半のインターンシップの選考は不合格で参加できなかったのですが、前半のトレーニングプログラムだけでもかなりためになりました。自分の周りにCSの人やソフトウェアエンジニアとして働いている人、エンジニアを目指している人がいなかったので、同じ課題に取り組んで刺激を受けたり、自分のキャリアを相談できたりして、繋がりができたのはとても良かったです。

やらなかったこと

社会人入学・プログラミングスクール

大学や大学院、プログラミングスクールに入ることはかなりギリギリまで迷っていたというか、大学(院)については今でも機会があれば…と考えています。

検討していた理由は、やはり学歴が欲しかったから、自分の能力だとひとりで勉強するのは限界があるのではと考えたからです。

大学(院)・プログラミングスクール共通で踏み切れなかった理由として、「無給かつ業務経験のない空白期間というリスクを許容できなかった」というのがあります。

自分でも意外だったのですが、自分は強い感情や過酷な環境に弱く、闘志が湧いてくるどころか、プレッシャーに押しつぶされてパフォーマンスが下がるタイプだとわかりました。まだ「やる気ないな」って思っているときのほうが手が動かせるのでマシです。また、「絶対なんとかなる」と思えるような才能も根拠も、根拠のない自信もなかったので、ついに踏み切れませんでした。

その意味で「最悪現職を維持しておけば路頭に迷うことはないな」と思いながら転職に挑戦するのは、精神衛生上とてもよく、落ち込んだときも復帰しやすかったです。

加えて大学(院)は現段階だと研究したり論文書いたりしたい!と思えるほどCSに対する解像度が高くなく、また一度大学を出てみてあまり研究が得意そうでもなかったのでなかなか決断できませんでした。ただ面接のフィードバックで「CS学位がないのはそんなに気にしなくていい」と言われてしまうくらい非CSコンプレックスを滲ませているらしいので、いつか…と思っています。

検討していたものの例として、大学は国内外の情報学部に加えてUoPeopleやCS50の有料受講、プログラミングスクールだと42Tokyoやコードクリサリスあたりが良さそうだと思っていました。

アプリ作成

これは正直「やらなきゃと思いつつ間に合わなかった」というのが実情です。

一応なくても問題ない(あるならないよりはいい?)と聞いていたことや、資格などで勉強量はアピールしようと思っていたこともあって、焦って作るということもしませんでした。

ただ、業務では触れなかった技術で履歴書に書きたいものについては、競プロのコードをGitHubに上げたりペラッペラのアプリを作ったりして形あるものを残したりはしました。

例えば「アプリをデプロイしたことはありますか?」「AWSを触ったことはありますか?」と聞かれたら「業務で扱わなかったのでないです!」とは言いたくなかったので、3の倍数と3がつく数字でアホになるだけのアプリをEC2でデプロイしたりしました。

おわり

自分としては一旦目標達成できたのですが、普通に未経験異職種0歳児なので、まだそもそもソフトウェアエンジニアとしてやっていけるのかどうかはわかりません。

最初は全然何もできないと思うのですが、これからも勉強を続けてはやく役に立てるようになりたいです。どうぞ今後もよろしくお願いします。

【読了】『かんたん理解 正しく選んで使うためのクラウドのきほん』

www.amazon.co.jp

これはぼくには一銭にもならないURL。 ちなみにAmazonには動画講座セットなるものがあるらしいですがKoboで読んだのでわたしは関係ありません。


ざっと読みました。

クラウドの本を探していたとき、

  • AWS, Azure, GCP をまとめて概観できる
  • 平易な文章
  • クラウド特有の用語が解説されている
  • サービスごとの説明が載っている

などの条件に合いそうな本を探していました。

クラウド事業者公式ドキュメントの翻訳っぽいわけわからん文章についていけなかったわたしにはぴったりでした。

また、最近システムデザインの勉強をしていたこともあり、最近覚えた単語がポンポンでてきたのは「進研ゼミでやったところだ!」感があって楽しかったです。

すでにクラウドをバリバリ活用していたり、システムの設計経験がある人にはもうちょっと良い本がありそうな気がします。

比較的新しい本だと思いますが、クラウドサービスは変化が早いので、ちょこちょくサービス名などが古くなっている場所がありました。が、それを理解して読めば使い物にならないというほどではないと思います。

内容としては、

などがありました。

オンプレとの比較やクラウド特有の事情が散りばめられているのもよかったです。

とりあえずレンタルサーバーとの違いがよくわかりました。

おそらくこのままクラウドが扱えるようになるかというと、流石に不十分だと思います。

この本を糧にもっと詳しく勉強したり、自分でもシステム構成を考えたりできたらと思います!

システムデザインを勉強した【2周目/スケーラビリティ編】

前回

kame3xkame3.hatenablog.jp

前回よりもう少し細かく勉強しようと思ったら長くなりそうだったので、2周目はトピックで記事を分けました。

記事の流れはほぼsystem-design-primerの通りです。

まだ勉強中なので、ヤバそうな嘘があれば教えてください。

スケーラブルなシステムとは

スケーラブルなシステムをつくる上で、よく使われる設計原理や概念をまとめる。

ちなみにsystem-design-primerではここでCS75の動画を見ろと言っているが、10分くらい視聴して英語がわからないことがわかったので、飛ばしてググったり別の教材で補ったりした。

垂直スケーリングと水平スケーリング

  • 垂直スケーリング(Vertical Scaling)== スケールアップ(scale-up)
  • 水平スケーリング(Horizontal Scaling)== スケールアウト(scale-out)
  • 例えば手持ちのPCではパワー!が物足りないと思ったときで例えると、
    • よりスペックの高いPCに買い替えるのが垂直スケーリング(またはスケールアップ)。
    • もう一台増やして2台使うのが水平スケーリング(またはスケールアウト)。
  • 仕事が終わらなすぎる会社で例えると、
    • そもそもこの仕事をできる人が居ない!という話なら各社員の能力がもっと高ければいいとなる(垂直スケーリング・スケールアップ)。
    • どう考えても仕事が多すぎて人手が足りてない!という話なら、もっとたくさん人を雇おうとなる(水平スケーリング・スケールアウト)。
  • 実際の垂直スケーリング・スケールアップはCPUやメモリを追加で積み上げていくイメージなので、その雰囲気で名前を覚える。
  • 水平スケーリングは台数を増やして横並べにしていくイメージ(実際のサーバー室はラック使って縦方向にも並べている気がするがきにしない!)。
  • スケールアウトは、スケールアップのPC内部にいろいろ追加する方法に対して、PCの外で台数を増やしていって拡張するイメージ。
  • (名前とイメージが一般に想定されているものと一致しているかは確認できていない。)
  • 個人のPCならもっとスペックの高いPCを買って垂直スケーリングしよう!となるが、大規模システムでは、膨大なトラフィックを捌くために、サーバーを増やす水平スケーリングが一般的(もちろん状況に応じて適切な対策を講じる必要がある)。

垂直スケーリングのメリット/デメリット

メリット

  • サーバーの台数を増やさなくていいので、運用などの管理の手間が増えない。今まで通りの管理方法を変えなくて良い。
  • サーバーの台数を増やすより、サーバーのスペックを上げるほうが作業量が少ない(単純に作業対象のサーバーの台数が少ない)。

    デメリット

  • いいPCは費用が高い。
  • スペックの高さにも限界がある。「現代の最新技術をもってしても終わらない処理」とかがあると詰む。
  • サーバーを一度シャットダウンしたいとき、サーバーが1台しかないとその間システムにアクセスできない。

水平スケーリングのメリット/デメリット

メリット

  • 長期的に運用するならコスパが良い。
  • 役割ごとにサーバーを分けられる(アプリケーションとDBなど)ので、それぞれに適したスペックのサーバーを使ったり、対策を講じたりしやすい。
  • 複数のサーバーを同時に動かしていれば、一部のサーバーがダウンしてもシステムが動き続ける設計も可能。

デメリット

  • 初期投資の費用が高い。
  • 管理が複雑になる。
  • サーバーの台数を増やす作業量も多い。複数台で並列処理・分散処理をするためにシステム側のコード修正も必要になる。

クローン

  • スケーラブルなシステムは、複数のアプリケーションサーバーで構成されるグループ/クラスターに、ロードバランサーを介して通信する構成になっている。
  • ロードバランサーがリクエストを受け取り、負荷(ユーザーからのリクエスト)を適切なサーバーに分散させる。
  • レスポンスもロードバランサーを介してクライアントに返される。
  • クライアントのリクエストはどのサーバーで処理されても同じレスポンスを返されるし、リクエストがどのサーバーに送られるのか意識する必要がない。
  • 同じ処理を行うサーバーが複数あると、コードが変更されたときに全サーバーを更新する必要がある。
    • 自動デプロイツール(Capistranoなど)
    • イメージファイル(AMI - Amazon Machine Imageなど)

データベース

非正規化

  • 「正規化」の逆。
  • 正規化はデータベースのテーブルを分割してデータの重複を無くすこと。
  • 非正規化はデータベースのI/O(書き込み・読み込み)の速度を上げるために、あえてデータの重複を許すこと。
  • JOIN句を使うと速度が落ちるので、正規化してテーブルを増やさないようにする。

NoSQL

  • SQLを使うデータベースであるRDBMS(リレーショナルデータベース)「「「じゃないほうの」」」データベース全般のこと。
  • 種類は色々ある。
  • 概してRDBMSより構造がシンプルで、I/Oが早くなることが多い。

ほかのいろんな方法

  • フェデレーション
  • シャーディング
  • SQLチューニング

キャッシュ

  • ここでは特に、「インメモリキャッシュ」のことを指す。
  • JSONPythonで言うところの辞書のように、Key-Valueの形式でデータをメモリに保持する。
  • メモリにあるデータは高速に取得できる。
  • アプリケーションとデータストレージの間に置いておいて、アプリケーションは欲しいデータがキャッシュにあればキャッシュから、なければデータストレージから取得することで全体的なアクセス速度を向上させることができる。
  • データをキャッシュする方法
    • データベースクエリのキャッシュ
      • Key → クエリをハッシュ化したもの
      • Value → クエリ実行結果のデータセット
      • デメリット:有効期限
        • あまり使われないような複雑なクエリをキャッシュする場合、いつ削除するか?
        • 複数のキャッシュに存在するとあるデータが変更された場合、対象のすべてのキャッシュを削除する必要がある。
    • オブジェクトのキャッシュ
      • 著者推奨。
      • データをオブジェクトとして扱う。
      • オブジェクトが生成されたらそのままキャッシュに保存する。
      • そのデータが変更されたらそのまま削除できる。
      • 非同期処理が可能。
  • どんなデータをキャッシュするか?
    • ユーザーセッション
    • ブログ記事
    • アクティビティストリーム
      • SNS上などでのユーザーの活動をリスト化して時系列で保持しているもの)
    • ユーザーとフレンドの関係性
  • 代表的なキャッシュ

非同期処理

  • リクエストを受けた直後になるはやで、以外のタイミングで処理してレスポンスすること。
  • 非同期の方法
    • その1
      • パン屋さんで例えると、「夜にパンを焼いて、朝に売る」形式。
      • 予め処理をしておいて、その結果を利用することで迅速なレスポンスを実現する。
      • 動的コンテンツを静的コンテンツに変換する場合などに適用される。
    • その2
      • パン屋さんで例えると、「注文を受けて、翌日以降に受け取ってもらう」形式。
      • リクエストをキューに送り、行列のように後ろに並ぶ。順番が来たら処理を行い、レスポンスを返す。
  • 非同期処理に関係する代表的なキュー
    • RabbitMQ

トレードオフ

パフォーマンス vs スケーラビリティ

  • パフォーマンス == 性能
  • スケーラビリティ == 拡張性
  • リソースが追加するごとにパフォーマンスが上がるシステムはスケーラブルである
  • (↑これはトレードオフなのか??)

レイテンシー vs スループット

可用性 vs 一貫性

CAP理論

  • 分散システムにおいては、下記の3つのうち2つまでしか保証できない。
  • (2つは極論すぎ!そうともかぎらないよ!という記事を見つけた、未読。https://www.publickey1.jp/blog/13/capcap32.html
  • 一部のサーバーの障害のせいでシステム全体が使えないというのは困るので、分断耐性は必ず保証する
  • 創るシステムの要件に従って、CPかAPの適切な方を選ぶ。
  • (分散システムに限らなければCAも存在するし採用される。例:RDBMS

Consistency - 一貫性

  • 必ず最新の情報か、エラーを返す。
  • データの整合性を保持できること。

Availability - 可用性

  • 必ずレスポンスを返すが、最新だとは限らない。
  • いつでも使えること。

Partition Tolerance - 分断耐性

  • ネットワーク障害などで一部のサーバーとの通信が途絶えてもシステムが機能する。

CP

  • ○一貫性と分断耐性
  • ✕可用性
  • システムはいつでも機能していてレスポンスは常に正しい情報だが、必ずレスポンスがもらえるとは限らない(エラーになることがある)。
  • 銀行口座でAさんからBさんに1000円振り込むとき、
    • ①Aさんの口座から1000円減らして、②Bさんの口座に1000円足す。
    • ①か②のどちらか一方が失敗すると、銀行全体のお金の帳尻が合わなくなるので、①と②の両方をなかったコトにする == エラーになる。

AP

  • ○可用性と分断耐性
  • ✕一貫性
  • システムはいつでも機能していて必ずレスポンスが返ってくるが、レスポンスの情報は最新のものだとは限らない。
  • 情報がちょっと古くても、いつでも使えるようになっていること。

一貫性パターン

  • 分散システムなので、一部のシステムがダウンしてもシステムが機能する(= 分断耐性)ように、データの複製を用意し、同期しておく必要がある。
  • どうやってメインのデータの変更を複製に反映するか。
  • データの整合性と同期の速度がトレードオフになる。

弱い一貫性

  • 整合性は低いが同期は早い。
  • 更新した後、最新の情報が取得できたりできなかったりする。
  • 正確さよりもリアルタイム性が重視される場合に適している。
  • ボイスチャットなどのように、音声が途切れることが合っても、なるべく遅延が少ないほうがよい場合がある。

結果整合性

  • 同期にそこそこ時間がかかるが整合性は高い。
  • 更新した後、すこし遅延があるものの必ず変更が読み取れるようになる。
  • メールなどのように、間違いなく相手が読み取れる必要があって、多くのリクエストを捌く必要があるもの(ボイスチャットと違って、メールが届かないこともあるというのは困る)。

強い一貫性

  • 同期の速度より完璧な整合性。
  • 更新した後、どのデータベースからも必ず同じデータが読み取れる。
  • 銀行口座のように、AさんからもBさんからも振込が行われたことが確認できないといけない場合。
  • 一部のシステムがダウンしたために古いデータしか参照できず、先月の給与振込がなかったことになったら困る。

可用性パターン

  • 可用性を保証する方法は以下の2つ
    • フェイルオーバー(サーバーの可用性向上)
    • レプリケーション(データベースの可用性向上)

フェイルオーバー

  • サーバーを普段メインで動作しているものと、待機しているものに分ける。
  • メインのシステムやサーバーの一部で障害が発生したとき、待機しているシステムに自動で切り替える仕組みのこと。
  • 待機しているシステムが普段から利用されて動いているか・いないかで2種類のパターンがある。
    • アクティブ・パッシブ フェイルオーバー(普段は動いていない)
    • アクティブ・アクティブ フェイルオーバー(普段も動いている)
  • デメリット:
    • 複数のサーバーで構成されているので複雑さが増す。
    • サーバー間で更新を同期する前に障害等が発生すると、データの欠損が起こる可能性がある
アクティブ・パッシブ
  • 待機しているシステムは普段動いていない。
  • メインのサーバー(マスター)から「ちゃんと働いてます!」という周期信号が待機しているシステム(スレーブ)に送られる。
  • この信号が途絶えたら、なんらかの障害が起きたと考えて待機しているサーバーがサービスを再開する。
  • マスター・スレーブ」とも呼ばれる。
  • 待機しているシステムが常に起動している状態を「ホットスタンバイ」といい、切り替えが早い。
  • 待機しているシステムが切り替え時に起動されるものを「コールドスタンバイ」といい、切り替えは遅いがリソースは節約できる。
アクティブ・アクティブ
  • 複数のサーバーで同じ役割を担っていて、普段は仕事を分け合って負荷分散している。
  • サーバーのどれかがダウンしたら残りのサーバーでトラフィックを捌く。
  • 複数のサーバーで構成されている == それぞれに別々のパブリックIPアドレスが割り振られているので、DNSやクライアントとサーバーを中継するシステムはこれらの情報を把握している必要がある。
  • 全部のサーバーが普段から動いているので、「マスター・マスター」とも呼ばれる。

レプリケーション

  • Replication、複製。
  • フェイルオーバーのデータベースバージョン。
  • データベースを複製したレプリカを用意しておいて、データベースの障害に備える。
  • レプリカのデータベースに普段から書き込みがあるか・ないかで2種類の方法がある。
  • デメリット:
    • データベース間で書き込みの複製を行う前に障害等が発生すると、データの欠損が起こる場合がある。
    • 書き込みが多いと、複製に掛かる時間が増えて、読み込みが遅くなる。
    • データベースのレプリカの数が多いと、複製する数が増える→複製に掛かる時間が増える。
    • データベースへの書き込みは並列処理できても、複製は並列処理できないシステムがある。
    • 複数のデータベースで構成されているので、複雑さが増す。

感想

  • スケーラブルなシステムをつくるより具体的な手段がちょっとわかってきてよかった。
  • 「あっこれ覚えることがいっぱいあるやつだ」となってる。
  • system-design-primerにもAnkiあるけど、もっと簡単なレベルからやる自分用Ankiが必要そう…。
  • 応用情報までと被ってる内容もあるけど、応用情報はもう少し範囲が狭くて細かい用語が出た記憶、面接対策のシステムデザインはもう少し幅が広くて、適しているケースを考えたり具体的なツール名とかがよく出てくる感じ。
  • クラウドエンジニアじゃないからクラウドの勉強はまだいいや!と思ってたけどガンガン出てきそうな予感がしてチョト勉強してる…。

次の目標

  • 1周目でさらっと流した具体的なツール(DNSとかロードバランサーとか)をきちんと勉強したい。
  • できれば次の次で具体的な設計問題に取り掛かりたい…!

システムデザインを勉強した【1周目】

システムデザインについて勉強しました。

まだほぼ概要が理解できていない状態なので、厳密な説明や定義より平易な表現を選んでいる(というかそれしかできない)ものの、なにかマズそうな嘘が書いてあったら教えていただけると助かります。

現状

  • CSなし、崖っぷち応用情報技術者
  • システム設計の学習・経験無し。
  • system-design-primerをパッと見た感じあんまりよくわからなかった。

目標

  • とりあえず大まかな用語について意味を自分なりに噛み砕いて理解する。
  • 学習する内容の全容をざっくり把握する。
  • これからどんな内容を掘り下げる必要があるのかなんとなく把握する。

使用した教材

github.com

有名なシステムデザインのGitHubリポジトリだけど現状読むための実力もない気がする。日本語でも3回は読みたい。

qiita.com

比較的文調や内容がsystem-design-primerより読みやすそう(まだ読んでる途中)。

あとは随時ググった。

なぜSystem Designを学ぶ必要があるのか

  • たくさんのユーザーがたくさんアクセスしても快適に使えるシステムを構築するため。竸プロで計算量の考え方が大事になるように、システムにめちゃくちゃアクセスされたときに備えて工夫が必要。
  • 障害に備えてシステム構築できるようにするため。システムを🌹世界でたった1つのサーバー🌹で運用すると、そのサーバーがぶっ壊れたとき、誰もシステムが使えなくなったり、二度とデータが蘇らなくなったりする。
  • 快適で壊れないシステムを創るのは、実は結構難しいため。じゃあサーバーを増やそうとかつよつよサーバーを使えばいいとか、案外そういう単純な解決ができない。費用の問題もあるし、サーバーのお世話(運用)の手間が増える場合もある。サーバー同士が勝手に協働してくれたりもしないので、全体でうまく動作するように(整合性を維持できるように)仕組みづくりする必要もある。

System Designでは何を学ぶのか

スケーラビリティ

https://www.sophia-it.com/content/%E3%82%B9%E3%82%B1%E3%83%BC%E3%83%A9%E3%83%93%E3%83%AA%E3%83%86%E3%82%A3

  • 「拡張性」の意味。
  • いまよりたくさんのユーザーやアクセスが押し寄せても対応できるようにしてあれば「スケーラビリティが高い」という。
  • 逆にあまり使われなくなったらミニマルなシステム構成に変更できるようになっている状態も「スケーラビリティが高い」という。
  • つまり、システムの規模(サーバーの性能とか台数とか)を柔軟に変更できる度合いのことをスケーラビリティという。
  • スケーラビリティに関する考え方(原因・対策とか)を学ぶ。

トレードオフ

  • 「強化素材モリモリにしたから大丈夫」みたいな単純な話はない。
  • 何かを手に入れようとすると何かを失う…せつない…。
  • そのシステムに何が求められているのかを考えて、適切な手段を取捨選択する必要がある。
  • いろんな手段のいろんな特徴(なにができるのか、なにができないのか、カネはかかるのか、手間はかかるのか)を把握する必要がある。

分散システム

  • 英語だと「Distributed System」(ディストリビューテッドシステム)。
  • 結局どういうシステム構成にするのが良いかというと、1台のつよつよサーバーを使うのではなく、複数のふつうのサーバーを使おうという話になる事が多い。
  • 管理がめんどくさくなったりして課題は多いので、理解して対処する必要がある。

いろんな道具

容量・用法を守って正しく使う。

DNS

  • ドメインネームシステム(Domain Name System)。ディーエヌエス
  • Webページを見たり、友達にメールを送ったりするには、本当はネットワーク上の住所であるIPアドレス(「127.0.0.0」「192.168.0.0」みたいな数字)が必要。
  • 数字の羅列は人間には厳しいので、人間にやさしいドメインネーム(「www.google.com」「www.example.com」みたいな文字列)でもアクセスできるようになっている。
  • でもコンピュータはIPアドレスがわからないとアクセスできないので、ドメインネームをIPアドレスに変換してくれるDNSが必要。

CDN

  • コンテンツデリバリーネットワーク(Content Delivery Network)。シーディーエヌ。
  • 日本から日本のサーバーにあるWebページにアクセスするより、日本からアメリカのWebページにアクセスするほうが時間がかかる。遠いから。
  • 例えばログインするとき、ログインIDとパスワードが正しいかどうかはアメリカのサーバーにリクエストして処理する必要があるけど、次に表示するHTMLや画像はログインできたかどうかあまり関係なく使うので、切り離して別の場所においておいても問題ないかもしれない。
  • HTMLや画像のような静的コンテンツだけ、日本(あるいはアジア圏の他の国など、できるだけ近く)のデータセンターから取得すれば、早くWebページを表示できる。
  • 静的コンテンツをいろんな地域に置いておいて、アクセスされた場所に近いところからデータを取得できるように、いろいろよしなにしてくれるのがCDN

ロードバランサー

  • 同じ仕事をしているサーバーが複数あるとき、ドッと押し寄せたたくさんのアクセス(トラフィック)を受け止めて、「いい感じ」にサーバー達に仕事を振り分けてくれる。
  • 「いい感じ」がどんな感じなのかはいくつか種類があって状況に合わせて選ぶ(負荷分散アルゴリズムとか)。

リバースプロキシ

  • 窓口みたいな感じ
  • リバースプロキシにアクセスすれば、必要なシステムを呼び出して、結果だけ返してくれる。
  • クライアントはリバースプロキシだけ見ればいい。
  • サーバー側も内部を隠せるので、安全で変更がし易い。
  • (実はあまりロードバランサーとの違いがわかってないが、状況によって使い分けるらしい。)

データベース

  • RDBMSやNoSQLとかの、データを格納したり取り出したりできるシステム。
  • I/O(データの読み書き)の速度を上げるにはどうしたら良いか?
  • トラブルが起きたとき、システムを止めない・データが失われないようにするにはどうしたら良いか(耐障害性・冗長性)?
  • どんなシステムで、どんなデータベースを使うのが適切か?

キャッシュ

  • アクセスされたコンテンツを一定期間記憶しておいて、同じコンテンツにアクセスされたときにサーバーに問い合わせなくても素早く取り出して応答できる。
  • どのコンテンツを、どのくらいの期間、どのタイミングで覚えて(キャッシュして)おくか?

非同期処理(メッセージキューなど)

  • アクセスや処理を一時的にためておいて、サーバーが処理できるようになったタイミングで遅れて処理できるようにする仕組み。
  • ユーザーは処理結果が返ってくるまで作業を止められることはないが、リアルタイムで(即座に)処理結果を受け取ることができない(処理結果が反映されるまでに遅れがある)。

読後感

  • 詳しい部分はかなり読み飛ばしたが、ひとまず勉強する内容や単語をさらっとさらえた。
  • 一番大まかな用語の意味は理解できたと思うので、きちんと頭に定着させることと、メリット/デメリットとどんな状況で使うかくらいは2周目で理解できるようにしたい。
  • 上記で挙げた「いろんな道具」については、さらにそれぞれの道具について種類が豊富にあってベストプラクティスとかもあるみたいだが、3周目以降で理解できるようにしたい。

【ABC166】D - I hate Factorizationの理解

atcoder.jp

全探索で解ける問題だが、どこからどこまで全探索するかを考える必要がある問題。

公式解説読んでピンと来なかったので、僕でも理解できるように丁寧に追いかけてみた(嘘だったら教えてください)。


まず、制約から 1 <= x <= 109 であり、 x == A5 - B5 になるA, Bを探すので、単純に 1 <= A5 - B5<= 109 の範囲を調べたら十分そうである。

この上で、1 <= A5 - B5 <= 109 のとき、AとBにどんな数字が入るか考える。

A == B であることはなさそう。A == B なら A5 == B5なので、A5 - B5 == 0 になる。xは0ではない(1以上)ので、この状況はありえない。

さらに 1 <= A5 - B5<= 109 なので、A5 - B5 がマイナスになることはない、つまり A > B と考えて良さそうである。

ここまでで、AとBは異なる整数であり、Aのほうが大きいということが分かる。例えば A == n とするなら、0 <= B <= |n-1| になりそうである。


A == n 、0 <= B <= |n-1| とすると、例えば n5 - 15 より、n5 - (n-1)5 のほうが小さい数になるし、n5 - 15 と n5 - (n-1)5 で同じくらいの大きさの数を作ろうとするとnの絶対値がより大きい数になるのはn5 - (n-1)5の方である。

なので、1<= n5 - (n-1)5 <= x のときnがどんな数字をとるのか確かめれば、AとBを最大でどこからどこまで全探索すればいいかわかりそうである。

ここからは公式解説に載っているし計算すればわかるが、-118 <= A <= 119、-199 <= B <= 118 を調べれば良いらしい。

つまり、1 <= A5 - B5<= 109 のとき、-118 <= A <= 119、-199 <= B <= 118 であり、また問題文から、今回はこの中にxが存在することが保証されている。

https://img.atcoder.jp/abc166/editorial.pdf


簡単に計算するとは言ったものの、109超えてくるまで n5 - (n-1)5 を計算するのは面倒だと思うので、計算するためだけにこんな感じにプログラムを組めば確かめられる気がする。

x = 10**9
n = 1
while n**5 - (n-1)**5 < x:
    n += 1
n -= 1
# max A: 119 , max B: 118
print('max A:', n, ', max B:', n-1)
n = -1
while n**5 - (n-1)**5 < x:
    n -= 1
n += 1
# min A: -118 , min B: -119
print('min A:', n, ', max B:', n-1)

これで多分 102 * 102 = 104 くらいで求められる。

ただしこの考えだと結構計算量に余裕がありそうだし、ここまでコンテスト中に考えるのは大変なので、本番でここまで考察できなくても、もうちょっとざっくり当たりをつけて全探索しても解けるらしい。

【UHK】Ultimate Hacking Keyboardを買った話

要約:金と学習コストに糸目をつけないで、全てが完結するキーボードがほしいならオススメ!


2021年7月24日に購入した(らしい)Ultimate Hacking Keyboardが、先日2022年6月16日に届いた。

なんと1年未満で届いたので、クラファン時代にv1を待っていた先人たちと比べるとかなりスムーズに届いたことになる。

とはいえ、発送予定は何回も後ろ倒しになったし、あれがないこれがないと連絡が来てたのでやきもきはした。

まだ全然使いこなせていないものの、すでにすごく気に入ったので自慢。

ちなみに感想を偉そうに書いているものの、キーボードに関する知識は自分が購入するときに判断材料にする程度であり、嘘や主観が大いに入り混じっていると思うのでダメそうだったら教えてください。

これは何?

ultimatehackingkeyboard.com

Ultimate Hacking Keyboard.

左右分割・マウス操作可能・有線・プログラマブルキーボード。

ファームウェアとかキーマッピングソフトとかがOSSで開発されていて、

いろいろいじりたい人はいじっているらしい(どっかで無線にしようとしている猛者を見たことある気がする)。

製造販売しているのがハンガリーの会社らしく、DHLの配送状況を見る限りはるばるブダペストからやってきている。

もともとクラウドファンディングから始まり、いまは普通に公式サイトで購入できる。

現在は第2世代?のv2が最新モデルで、購入から手元に届くまでにそこそこ時間がかかる。

今ポチる人は1年近く待つことはないかもしれないが、まだ生産が安定してないし、注文が入ってから組み立てるらしいので明日届けてほしい人は多分無理。

キーボード本体だけでもマウス操作は可能だが、オプションでトラックボールタッチパッドの部品をつけることができる。

このパーツはv2と同時に発売されたらしいが、v1に適用することもできる。

諸々のパーツはつけ外しがかなり自由にできるので、好みや環境の変化にも耐えられる可能性が高い。

注文内容

黒以外のケースは一時期欠品してて、黒に切り替えるかどうか案内が来てた。

面倒くさマスタードで貫きたかったので待った。

結果待ってよかったと思う。かわいい。

今はあんまり関係なくどの色でも同じ時間かけて届くと思う。

注文方法

aotamasaki.hatenablog.com

negiuraroman.hatenablog.com

先人たちを参考にオロオロ注文した。

JCB使えなかったとあるが、確か同じ壁にぶつかった気がする(うろおぼえ)。

持ってるカード全部引っ張り出して海外決済手数料安いVISAカードを適当に使ったら、

数年眠らせてたカードをいきなり謎の海外サイトで数万円決済するという状況が怪しすぎたらしく、

めちゃくちゃカード止められて焦って何回も決済しようとしたので、あやうく複数のUHKをお迎えするところだった。

心配すぎてカード会社に半べそで電話して1回しか決済していないのを確認した。

カードの不正利用検知かしこい!と感心した。

手元に来るまで

注文した2021年7月は、v2の注文受付を開始したもののまだ誰のもとにもブツが発送されてない状況だったと記憶している。

最初は年内には届きそうみたいなことが書いてあったが、やれ品質に問題があっただの、やれ工場を移転しただの、やれカラーケースが欠品しただのでのびにのびて1年位はかかった。(うろ覚えなのと英語はふんわり読んでいるので認識があっているかどうかは不明)

発送してから家に配達されるまではかなりスムーズで、なんなら到着予定日より数日早く来た。

届いたときに関税を払ったらしい。

開封の儀

HHKBが何かを言いたそうにこちらを見ている。

パームレストもかなり立派な箱で届いたので、UHK2つ頼んじゃったのかと焦った。

幅はHHKBとほぼ一緒!ほんとにほぼ一緒でびっくりした。

ただ枠がUHKのほうが太め・キー間もUHKのほうが広めで、一つ一つのキートップはHHKBより小さく感じるし、何より例えば上一列はキー数がUHKのほうが1つ少ない。

そもそもパームレストつけるのでめちゃめちゃゴツくはなる。

HHKBの完全なる互換を探し求めている人はHHKB買ったほうがよい(あたりまえ体操)。

これ有線接続部分なんだけど挿しにく過ぎてびっくりした。付属のケーブルは太め硬めだからいいけど、細いやつだと断線しない?!ってくらい押さないと入らないし、挿さったのかどうかよくわからない。

あと開封してすぐは接続が不安定で、左側を認識しなかったり、モジュールが機能しなかったりした。ケーブルとかモジュールを抜き差ししたり、PC再起動したりしてるうちになんか直った。

キーと打鍵感

キートップの感触はHHKBよりすこしザラザラめ。印字?されている白い丸はバックライトを透かすようになっている(ので、多分印字ではなく素材が違う?)。バックライトの透かしが入っているのは、キーの役割によってライティングが変わったりするのを見やすくするためだと思う。ライティングも可愛いし良い。

HHKBはキーの傾斜がかなり付いているが、これはそこまででもない。多分キーボード自体に脚がついていて角度をつけられるので、困ることはない。

軸はいろいろ選べるが、今回は一番押下圧が軽くて一番静音性が高いKalih Silent Pink軸にした。

Cherry MX軸互換なので、キートップは好きなものに取り替えられる。HHKBはそういうのあんまりできない(不満ではないが)からちょっと遊んでみたい。

HHKB Professional2 Type-Sは押下圧45g、Silent Pink軸は押下圧35gfとなっている。

押下圧の単位が違うことに今気づき調べても違いがあんまりわからなかったが、とにかく触った感じもSilent Pink軸のほうが押下圧が軽く静音性が高い。

HHKB Professional2 Type-Sも底打ち音とかクリック音は小さい方だけど、なんというか、打鍵したときのプラスチック音?カチャカチャ音?みたいなのがとにかくこのSilent Pink軸のほうが小さい。底を叩いたときのカンカンする音もしない。これはメンブレンより静かまである。

外枠付近の大きいキーはほかと比べてちょっとカチャカチャ音が大きい気がする。個人的観測ではデフォで右シフト・左シフト・左コントロールに当たるキーがケースと擦れたみたいな音がする。でも今のところ気にはなっていないし打鍵感には影響はない。

打鍵感はHHKBと似ていて、いわゆる「スコスコ」と表現される感じ。青軸みたいなクリック感が欲しい人はまず物足りないけど、個人的には気持ちいい打鍵感で好き。

押下圧軽くてスコスコで打鍵音もめちゃめちゃ小さいので、具合が悪いときでも打てそうでよい。そうでなくても握力(指力?)ザコすぎるので、かなり負担が軽く打てる。疲れない。天使の羽根。

今のところ押下圧軽すぎてタイポしてしまうというような事象もあまり発生していない。まあこれは力 -chikara- がザコ故かタイピング能力がザコ故かわからないので個人的観測での話。

そしてこれはSilent Pink軸の話で、UHKは好きな軸を8種類選べて特徴はそれぞれなので、上記の特徴が気に食わなくても安心してポチってほしい。

割る

思ったよりすんなり分割↔結合ができて感動した。もっと破壊と隣合わせの恐怖にビビり散らかしながら力を込めて分割↔結合しなきゃいけないと思ってた。思ったよりはスルスルとシャコシャコできる。

断面もちょっとかっこいい、光るし。

親指オプションパーツはこの断面に同じ要領で分割↔結合できる。

左右をつなぐケーブルがこれなんだが、これがなんていうケーブルなのかわかっていない。

もし別売りの市販で買えるものなら買いたいと思っているので、詳しい人は教えてください。

分割したときに数字の6キーが左にくるのはなんでなん????????


追記(2022/07/18)

公式サイトをよく見たら、このキーボード間ケーブルの仕様がちゃんと書いてあるページを見つけた。

ultimatehackingkeyboard.com

ご親切にも類似品の購入先リンクが貼ってあったのですが、わざわざケーブル1本を海外から購入したくありません。

機械ヲタクのパパ親と一緒に解読したところ、「RJ-9・4極4芯・クロスのモジュラーケーブル」を買えばよいのではないかということがわかりました。

僕にはなんのことかさっぱりですが、受話器ケーブルのくるくるの大半はこれの類らしいです。

ざっと見た感じ送料込みで一番安そうなのを楽天で購入して届くのを待っています。

カールなし1メートル未満くらいのケーブルを探してたので動けばいい感じそうです!

item.rakuten.co.jp

これは朕には一銭も入らない楽天のリンク!

パームレスト

木。買ってよかった。

手首を冷やすと死ぬ病にかかっているが、今のところそこまでひんやりしていない気がする。答え合わせは冬にできる。

安くないけど、分割して使うつもりならあったほうが真価を発揮できる気がする。

オプションパーツ(モジュール)

親指用のパーツ。これでマウス操作ができるのでホームポジションがくずれないし、寝たままPC操作するときにマウスがいらない。やったね!

今回購入したのはトラックボールと左手用の追加キー付きトラックボールのモジュール。

他にもタッチパッドタイプのやつと、Think Padについてるぐにぐにするやつ(Track Point)がある。

トラックボールはスクロールを割り当てることもできるらしく、左手モジュールの方のトラックボールにはデフォルトでスクロールが割り当てられていた。

面倒くさいのでデフォのままにしているが、スクロールはMouseレイヤーのキー操作が優秀だと思う。

あと左手モジュールのキーも好きな軸が選べる。選択肢はキーボード本体と一緒で、キーボード本体と別の軸を選ぶこともできる。今回はここもSilent Pink軸にした。

予備でキーキャップがついていた。なんかこれだけ質感が違くてすべすべしている気がする。

右手用のトラックボール、赤なのがちょっと・・・と買うとき思っていたが、なんと黒とグレーのトラックボールが付属していた。ありがとう!満足してしまったので面倒になってまだ赤のままである。

キー配置

キーボード本体はHHKBがそう言われるようにかなりコンパクトでキー数も少なめだが、キーマップの変更はもちろん、マクロやショートカットが色々仕込めてなんでもできる。

レイヤーという概念があって、FnキーみたいなキーがほかにMod、Mouseと合計3種類あり、それだけたくさんキーやマクロを対応させることができる。

諸々の設定ができるソフトはUHKマニュアルページを順番に進めていって最後のページでダウンロードできる(ダウンロードページに至るまではマニュアルというかチュートリアルみたいになってて親切)。

ちなみにこのソフトを立ち上げたままタイピングしようとするとなぜか遅延など入力が狂う事象がめちゃめちゃ発生する。閉じてタイピングしよう!

u1.hatenablog.com

キーマッピングの変更も先人を参考にしたり、HHKBの好きなところを反映したり、自分好みにしたりした。これからまた変える可能性はある。

Base レイヤー

素の何も押して無いときのキーマップ。

一番上一列がHHKBより1つキーが少ないので、一番悩まされた。

流石に左上ESCは捨てられないと思い、泣く泣くチルダを右下に配置した。US配列だと日本語入力と半角英字入力の切り替えに使うので、慣れるしか無い。

Mod レイヤー

Modキーと同時押しで使えるキー。デフォルトだと分割スペースキーの左半分とかに配置してある。

デフォルトで矢印キーとかが設定されていたので、HHKBでFnキーとのショートカットで設定しているキーをいくつか設定した。

矢印の配置をHHKBでデフォルトの矢印と同じにしようかと思ったが、これを機にvimと同じhjklに割り振った。それに合わせてpgUp/Downとかも位置を変更した。

あとはPrint Screenをちょくちょく使うので馴染みの位置にした。

Fn レイヤー

Fnキー同時押し。まだあんまり設定していない。

強いて言うならHHKBで設定していた音量調整キーを同じ位置を設定している。あとCapsLock。再生・一時停止とかは使ったこと無いので適当にそのまま放置してる。

左上一列にズラッとあるのはキー配列をDvorakとかに一発で変えられるキーだが、慣れていないせいで間違えて押しまくっていて、すでに100万回死んでいる。使わないなら消しても良いかも。

Mouse レイヤー

これが一番目新しい機能かもしれない。マウス操作を担うレイヤー。デフォルトでタブ下にあるMouseキー同時押しで使える。HHKBで左コントロールはタブ下にないとイヤイヤなので、左下に移動した。

できることとしては左右中央クリック、縦横スクロール、縦横カーソル移動がある。

カーソル移動については、モジュールもあるし正直あんまり使わないと思う。垂直・水平方向のカーソル移動ができる。ある意味きっちり垂直・水平方向にカーソル移動したいという需要に応えることができる。

左右中央クリックもまあ、万が一マウスクリックが足りなくなったときとか、使ってたマウスのクリック感があんまり好きじゃないとか、中央クリックが無いときとかに使えるくらい。モジュールに指持っていくのすら嫌になったら有能ではある。

お気に入りなのはスクロール。これはモジュールでもやりづらい(割当はできる)のですごく便利。しかもスクロールのスピードを同時押しキー1つ追加で変更できる。これは本当に有能。

デフォルトで左スペースバーとその下の外枠キーにそれぞれスクロール速度調整キーが割り当てられていて、まだいじってない。多分変える。

感想

とりあえず思いついた感動を雑然と書いたが、総合的にすごく好き。ていうか最高。

ただHHKBよりも更に学習コスト高いし、送料関税もろもろかかるし、オプションつけまくるとだんだん高くなるし、届くまでのラグすごいし、サイトは全部英語だしで、敷居は高く感じるかもしれない。

でもマウス操作ができるモジュールとかキー操作は唯一無二感あるし、作りもしっかりしてるし、好きにカスタマイズしまくれるし、所有欲的なのはすごい満たされる。

幸い特殊なキーボードの割に日本語の口コミも多いので、あんまり困らないんじゃないかと思っている。

何より個人的な願望である寝たままPCには理想的な製品なので待ってよかった。とりあえずまだ不慣れなので使って慣れたい。

自分が買う前にあんまりわからなかった部分と届いて感動した部分は一通り書けて満足したので、誰かの役に立てば幸いです。