効率的な学習方法から導入までskonno2024-10-25以前[4]、同一アプリケーションをGo、Rust、C言語で実装し、各言語による実装効率と速度を評価しました。今回は、その経験をもとにRustの効率的な学習方法と導入についての見解をまとめてみます。Rustは生産性を実感するまでに学習期間が必要な言語とされています[5]。初期学習段階での離脱者が50%以上にのぼり、その多くが1ヶ月以内に挫折しているという統計[6]もあるため、まずは、効果的な初期学習が特に重要です。Rustコンパイラには(解決方法が明示されない)難解な解釈も多々あります[11]が、まずはRustコンパイラのエラー内容を理解し、対話できるまでの基礎力を身につけましょう。Rustは初級者向けの書籍や資料は溢れている[5]ものの、実践的な中級以上を対象とした資料に乏しい状況[5]は、なかなか改善されていません。結論としては、闇雲にコンパイラとの格闘するのではなく、まずは以下に示す一次資料である良質な学習教材での基礎力アップが、Rust習得の近道となるでしょう[7][8]。C/C++の熟練者の習得は容易である意見も散逸される[7][9][10]ので、Rustの有用性を深める意味でも、C/C++言語への理解を深めるのも、Rust習得の近道かもしれません。「Rustを学ぶ」のが目的であれば、この段階で目的は達成できているでしょう。Rustの難しさは、学習曲線の準備期を克服した後の、実践の難しさにあります[5][11][12][15]。結論から言えば、何かしらの実践的なプロジェクトに着手してみるのが、Rust学習としては効率的なようです[13][14]。Rustのセマンティクスに沿わない場合、他のプログラミング言語でのデザインパターン(経験)を直接的には持ち込めず[16]、試行錯誤が必要となります。既存言語との比較面では、以下のチュートリアルが参考になるでしょうか。2024に参加してきました。CESは、世界中から最新のテクノロジーとイノベーションを紹介するイベントであり、毎年多くの業界関係者やテクノロジーファンが集まります。ここでは、CESへの参加方法や、ラスベガス滞在で気がついた点をまとめています。今年のCES展示会の出展者は、公式アナウンスによると4000社以上と、かなりの規模です。意気込んではみても、効率面、体力面を考慮すると、全てのブースを隅から隅まで目を通すのは現実的ではありません。事前に、参加するブースの目星をつけておきましょう。各会場ではテーマが設定されている区画があります。各会場の特徴や出展者の状況、または目的の企業があれば、事前に、公式サイトや公式モバイルアプリで目星をつけておくのが良いでしょう。開催前日に、メディア向けの公開がありますので、その記事を目安にするのも良いでしょう。当日の展示会場布巾は、設備の問題か、混雑の影響か、通信状況あまり良くありません。公式サイトのアクセスも難しい状況も想定されますので、事前のスクリーンショットを取っておくのが無難かもしれません。CES会場へ参加するには、事前の登録に加えて、参加バッジの入手が必要です。展示会の当日、現地でも入手は可能ですが、開場時刻はかなりの混雑ですので、前日までに指定の場所での入手がおすすめです。Reid)国際空港や、Bellagionなどのラスベガスのホテルで入手ができます。CES事務局からも、公式アプリ通知や、登録メール経由で、事前バッジ入手の告知がありますので、開催当日の移動をスムーズにするために、事前に余裕を持って入手しておきましょう。Center)を中心に、会場が分散されて開催されます。メイン会場となるLVCCまで移動してから、分散している展示会場を巡るのが良いでしょう。LVCCのメイン会場は10時の開場となりますが、周辺の会場によっては9時会場の場合もあるので、精力的に巡るには開場時間の早い展示会場に足を運んでから、移動するのも良いでしょう。LVCCの展示会場には、モノレールやシャトルバスなどの、公共の移動が簡便です。宿泊するホテルについても、あらかじめ、公共のモノレールへのアクセスや、シャトルバスの有無などを確認してから選択するのが良いでしょう。MGMグランドを起点に、ストリップ沿いホテルの東側にモノレールの路線があります。起点となるMGMグランドからはホテル駐車場近辺に駅がありますが、ホテルから駅までの距離が短いようであれば、ぜひ利用しましょう。モノレールの切符については、乗車区間による料金設定はなく、一日乗車券がお勧めです。乗車券は、公式サイトや当日の駅の自動販売機やカウンターで購入できますので、当日の混雑を避けるために、事前入手がお勧めです。始発となるMGMグランド駅での購入は、展示会開催時刻には大変混雑しますので、公式サイトや早朝などの事前購入をお勧めします。CESの開催期間中には、主要ホテルに向けた、無料のシャトルバスが運行されます。モノレールへのアクセスが悪い場合には、こちらが第一の選択になるかと思います。moreDatabasePostgreSQLプロトコル実装に必要な柔軟性skonno2023-09-23最近、PostgresSQL互換サーバーを実装する目的で、Go言語向けのPostgreSQL互換サーバー構築用フレームワークである「go-postgresql」と、それを活用したマルチプロトコル/マルチモデルをコンセプトとする「PuzzleDB」を開発する過程で、PostgreSQLのプロトコル実装を調査しました。以前、RDBMSの代表的なPostgreSQL・MySQLの通信プロトコルの概要を調査[3]をしましたが、今回は、実装におけるポイントや、異なるクライアント実際についても考察し、PostgreSQLプロトコルの実装における柔軟性とその必要性について整理してみます。PostgreSQL仕様書では、データベースのクライアント側をフロントエンド(Frontend)、サーバー側をバックエンド(Backend)とした用語の定義があります[3]。PostgreSQLの通信プロトコルは、フロントエンドからの要求パケット、バックエンドからの応答パケットのいずれにおいても、基本的には、以下に示すパケット仕様に準じています[3]。body)長を示す共通ヘッダから始まります。後述するように、クライアントからのコネクション確立時においては、いくつかの例外があります。特徴としては、MySQL[1]やMongoDB[2]のようにメッセージの識別子および応答の識別子となるメッセージ番号(ID)が含まれないことです。そのため、基本的にはフロントエンドからのメッセージ要求順に、バックエンドからのメッセージを順次応答する形式となります。PostgreSQLプロトコルによる通信は、要求および応答共に複数のメッセージを合成的に組み合わせます。MySQLにおいては、その組み合わせは厳密に定義[7][8]されていますが、PostgreSQLでは厳密な定義はなく、順次要求されるメッセージおよび、それに対する応答メッセージは、各自の実装において、省略される場合があるのが特徴です。PostgreSQLのサーバー側のコネクション確立以降の基本フローについては、公式ドキュメント[4]に概要の説明があります。この公式ドキュメントから今回実装してみた、正常系の主要メッセージを整理すると、以下のような状態マシン図となります。Query)などのメッセージ要求を処理をして、待機(Ready)状態への遷移繰り返えすのが基本フローとなります。メッセージの共通形式には例外があり、歴史的な経緯[3]から、クライアントからのコネクション確立時の最初のメッセージはからは、メッセージ種別(Cmd)が省略されています。その例外として、以下に示す、スタートアップメッセージ(StartupMessage)と、SSL要求メッセージ(SSLRequest)があります。いずれも、共通形式と比較して、最初のメッセージ種別(Cmd)が省略されています。メッセージ種別(Cmd)はありませんが、スタートアップメッセージ(StartupMessage)はメッセージ内容とプロトコルバー順により可変ですが、SSL要求メッセージ(SSLRequest)は固定値であるため、SSL要求メッセージのヘッダ部で識別となります。SSL要求メッセージの長さは8で固定、SSL要求(Request)部は80877103(=04D2162F)、つまり、1234(0x04D2)と5679(0x162F)の2つのマジックナンバーの固定値による識別となります。いずれにしろ、ネクション確立後のスタートアップは、このような例外的な処理となります。Query)が定義されています。Query)は、SQL文を複数のステップに分割して送信するクエリー形式です。拡張クエリーにつき、公式ドキュメント[4]から今回実装してみた、正常系の主要メッセージを整理すると、以下のような状態マシン図となります。拡張クエリプロトコルは上記図の一連のコマンドで実現されますが、フライアント側はバックエンド側の応答を待たずに、一連のクエリを送信するパイプライン処理を可能とします。パイプラインの目的としてはメッセージ往復回数が削減があり[4]、実際の実装でもバックエンド側からの応答が省略される場合があります。Protocol」公式資料を参照しながら作業を進めます。言え、MySQLのように厳密な定義[7][8]はなく、RFC形式のような必須・推奨・任意の定義もなく、実装においては、解釈の余地があります。打鍵感との両立を求めてskonno2023-03-01オフィスだけでなく、リモートワークのオンラインミーティングで利用するキーボードは、打鍵感だけではなく、静音性も重要なポイントです。最近では、気分転換をかねて出社やコワーキングスペースの利用の機会も増えてきており、静音キーボードの見直しのため、打鍵感の良いタクタイルを中心に、静音スイッチを色々試してみました。静音キーボードの難しいところは、静音性と打鍵感がトレードオフになるところです。リモートワーク時代に求められるキーボードには、静音性を確保しつつ、打鍵感に疲労感を加えた3軸での最適化が必要となります。結論としては、許容できる静音性は、時間と場所により異なるため、一択になるまでは絞り込めませんでした。静音性の制約の中で、最適解となる複数の静音キーボードを準備して、使い分けるのが最善となりそうです。Bump系のタクタイル感の強いスイッチをメインとしています。打鍵感重視だとアーリータクタイル軸、軽快感重視だとクリッキー軸が好みといったところです。自宅でのメインスイッチを青色の背景として、一覧を以下に示します。いわゆるClackyやThockyに分類されるスイッチ[1][2][3]が好みですが、いずれもオフィスで利用するには静音性に課題があります。好みのキースイッチを一覧にしてみると、自宅では静音性は気にせずに、押下感のみを重視している事がわかります。自宅で利用しているスイッチを、クリッキーな軽快感と、タクタイル感による打鍵感の両軸で整理してみると、以下の図になります。Bump系の、タクタイル感の強いスイッチに比重を移しつつあるといった感じでしょうか。静穏化が最優先であれば、構造的にはリニア軸の選択が最適ですが、都度試してみても、相変わらずリニア軸の底打ち感や、押下圧の低いスイッチは苦手感があります。そのため、今回はリニア軸は対象外とし、相反する打鍵感と静穏化を両立を目的に、評判の良さそうな静音系のタクタイルスイッチ[4][5][6][7][8][9][10][11]をメインに試してみました。今回評価した静音スイッチの一覧を以下に示します。今回は、評価基準で示した青色背景のスイッチを基準として、評価する静音タクタイルスイッチを色々と探してみました。好みとする自宅環境を、如何にオフィスでも再現できるかを目的とした評価となります。結論としては、オフィスに持ち込むキーボードは、打鍵感と静音性、疲労感の3軸のトレードオフでの選択となり、一択になるまでは絞り込めませんでした。今回評価した各静音スイッチを、静音性と打鍵感の両軸で整理したのが、以下の図になります。タクタイルスイッチは、構造的に打鍵感と静音性が相反する性質であり、本質的には両立は難しい選択となります。評価すべき項目としては、疲労感があります。静音により打鍵音のフィードバックの減少は、打鍵感にも影響していそうです。疲労感を感じやすい静音スイッチは、図では赤丸で囲んでいます。MX静音赤軸は例外としても、基本的には静音性と打鍵感のみを追求していくと、それらを実現する押下圧やタクタイルポイントの性質により、疲労感に繋がりそうです。結論としては、疲労については慣れの要素がありつつも、タクタイル感を疲労がない範囲で打鍵感を求めつつ、静音性とのトレードオフでの選択となりました。以下に、評価した各静音スイッチの寸評を示します。C・Go言語実装との比較skonno2023-01-14Rustは、安全性と高速性の両立を目的にデザインされた言語[1]であり、近年では業務に採用されるプロフェッショナル言語としての、更なる飛躍が期待されています[3][8]。2021年のアンケート結果[3]でも、仕事での利用率は前年の42%から59%に大きく向上している反面、業界での採用実績面の少なさが、Rustの将来性の最大の懸念(38%)に挙げられており、現時点では実績不足な面は否めません。Lite)の2つ分野の同一アプリケーション実装を評価対象とし、Go言語やCなど他プログラミング言語での実装と比較することで、Rust実装の効率と性能評価を試みました。Cの観点からはGoがCの後継として最適と考えています。プログラミングの柔軟性に限界があります。反面、Goは実装の効率性と安定した性能で際立っており、汎用的なアプリケーションに安心して使える選択肢と判断しています。本評価は、データベース分野のRedis[19]仕様を同一アプリケーションとして、C言語、Rust、Goによる実装を評価します。Redisの公式実装[19]はC言語であり、RustおよびGo実装は非公式なサブセット実装になります。Rust実装はTokio[20]ライブラリの学習用として公開されたmini-redis[21]、Go実装は拙作のRedis互換データベース実装のgo-redis[23]のサンプル実装(go-redis-server)での評価となります。code)による実装効率評価はできず、性能評価のみとなります。評価したベンチマークプログラムは、Redis公式ベンチマークツールである「redis-benchmark」で実施しました。実行するベンチマークはフルセットではなく、SET/GETコマンドのみに限定し、標準の50スレッドにて10,000回毎繰り返した結果を用いています。基本的なSET/GETコマンドのみに限定されている理由は、mini-redis[21]がSET/GETコマンドなどの最小限のコマンド実装に留まっており、mini-redis[21]でのベンチマークパラメータ[22]を踏襲したためです。12.6」での評価となります。RESPの課題と現状についてskonno2022-07-31Redisは、インメモリのキーバリューストアとして2009年に登場し、現在でも活発に機能拡張が継続されているプロダクトです。3[2]として刷新され、大幅な機能拡張が実現されました。本家のRedis自信も進化を続けていますが、最近ではRedisと互換性のあるRESPプロトコルに対応した大規模なRedis互換プロダクトが相次いで登場しています[4][5]。Protocol)[1]の通信プロトコルを中心に、実装上の利点などや課題を踏まえて解説してみます。RESPは「実装が簡単」「解析が高速」「ヒューマンリーダブル」を設計思想[1]とする通信プロトコル仕様です。通信パケットの起点となる共通ヘッダは、メッセージ種別を示す1バイトのみで、CRLFをメッセージの終端とする、非常に単純な仕様です。Lite2から、Keychron[1]やDrop[2]の65%キーボードに移行できたので、その延長線上でKeychronのQ1を選んでみました。ALTの導入で解決[2]できたのですが、今回はMac環境の課題を解決するためのQ1の導入です。Mac環境についてはWindow環境ほどカスタマイズは必要なく、ほぼKeychronK2/K3への移行に満足していました[1]。ALTでのカスタマイズ[2]により、Fnキーの位置や、Fnキーを併用したWASDによるカーソルキーの配置など、Mac環境との操作性に差異が発生してきました。K2でも非公式なQMK対応はあるものの[3]、Q1はKeychron公式にQMK/VIA対応した製品です。今回のQ1の導入により、Window環境との差分[2]に加えて、電源(Power)キーがない不便[1]も解消できました。Q1については、現時点では通常版とノブ(Knob)版の2種類販売されており、今回購入した通常版については「キー打鍵時の金属音」や「キーキャップの互換性」が話題となっていました。現在では、Q1のノブ(Knob)版も登場しており、特にキーキャップの互換性は解消されていますが、自分も先人を参考に色々とカスタマイズを試してみました。購入当初は、打鍵時の金属音は気にならなかったのですが、キーキャップを交換している中で、相性の問題もあるのか、甲高い金属音が鳴るようになりました。そのため、已むを得ず、静穏化のカスタマイズとなりました。Modeと呼ばれる打鍵時の金属音の抑制のために、上下の金属ケースの接触面にラベルを貼る手法です。今回は、テープではなく、エーワン(A-one)の丸型9mmのラベルでの代用を試してみました。実践されているテープの厚みは0.1〜1.6mm程度で、重ねる枚数も人それぞれで異なります[3][4][5][6][7][8]。エーワン(A-one)の丸型ラベル1枚の厚みは0.1mmでしたが、組み立て後にケース上部を叩くと、明らかに1枚より2枚重ねの方が消音効果がありました。Modの効果は高く、ケース上部を叩いた時の金属音が、自転車で言えばアルミフレームが、カーボンフレームのような音に変わります。そのため、丸型ラベルは2枚重ね(0.2mm)としました。Lite2は、残念ながら2019年で廃盤となりました。ALTを試してみました。現時点では、Windows/Linux環境での移行の問題点が、ほぼ解消できている状況です。ALTを選択してみました。ALTを選んだ理由を列記してみます。KeychronのK6(65%)を購入してから気が付いたのですが、チルダ(~)キーが独立でないとWindows環境ではかなり不便です[1]。ALTは、公式にQMK対応でカスタマイスが可能です。複数台でのキーボード利用が前提となるために、個人的にはソフトウェアではなくハードウェアでの対応が必須です。現行のHHKBに移行できない理由は、カーソルキーの不備があります。K2/K3と同じく右SHIFTキーは1.75Uでやや特殊なものの、他のキーは標準サイズで、キーキャップの選択幅も広がりそうです。現時点では、Razerのキーキャップを試しています。Lite2は背面のネジを外すだけで分離でき、キーキャップ部が簡単に丸洗いできます。ALTは、さすがに丸洗は難しいものの、フローティングデザインで、ある程度は掃除はし易そうです。Lite2はUSBハブ機能がありましたが、現行のHHKBではUSBハブ機能が省かれています。Lite2は、残念ながら2019年で廃盤となりました。Lite2でしたが、ふと「HHKBに拘る必要はないのかも」と思い始め、移行先のキーボードとして標準的な英語配列のコンパクトキーボード、KeychronのK2/K3を試してみました。HHKB登場時はともかく、現在ではテンキーレス(TKL)80%以下の、コンパクトなキーボードは色々な選択肢があります。K2/K3への移行を試してみました。Lite2では、Windows(Linux)とMac環境で1台ずつ購入して使っていましたが、Keychronのキーボードは1台でMac/Windowsに対応しています。Windows/Macそれぞれのキーキャップも付属しているのも、有り難いところです。切り替えは、側面のスイッチで、簡単にMac/Windowsの切り替えが可能です。キーキャップの交換などの手間もあり、結局はLite2と同じくWindowsとMac環境で1台ずつの揃えることになりました。KeychronにはHHKBに近いキーボードとしてKeychronにもK6(65%)がありますが、チルダ(~)キーが独立ではありません。K6では、FNキーとESCの組み合わせでチルダ(~)キーの入力となります。実は、K6を購入してから気が付いたのですが、Macではまだ許容できるものの、Windowsでは言語切り替えにALTキーにチルダ(~)キーを多用するため、3重押しを回避するための、チルダ(~)キーのあるK2/K3に落ち着きました。現行のHHKBに移行できない理由は、カーソルキーの不備があります。HHKBも日本語キーボードにはカーソルキーがありますが、今まで英語キーボードメインだったので、ちょっとコスト感があります。Keychronは、右SHIFTキーが1.75U、スペースキー右横が1Uキー3個と標準からは若干変則的ですが、カーソルキーが標準で配置されています。Lite2はメンブレインでメカニカルな爽快感はないものの、押下圧55gでタクタイル感が強めです[1]。個人的には、HHKBのようの低めの押下圧や赤軸のリニア感が苦手な感があります。Lite2に移行する前は、職場と自宅共にIBMのキーボードをメインキーボードとしていましたので、Gateronの青軸、外出も考えて茶軸も選択して、原点回帰してみました。キーボードについては、自宅では有線接続、外出先では無線接続メインの利用環境です。Lite2から移行してみての感想をまとめてみたいと思います。今回購入したGateronの茶軸は、Lite2と同じ押下圧55gのタクタイルです。個人的には押し比べてみても違いは僅かで、茶軸については同じ感覚で全く違和感がありません。言え、打鍵感は、断然Gateronの青軸です。押下圧60gとやや重めになりますが、打鍵感は以前のIBMキーボードに近しく、やや軽い印象もありますが、非常に軽快です。打鍵音は、IBMキーボードのようなガチャ感のあるメカニカル音はせず、軽快で静かです。最初は、HHKBより1段上の位置にバックスペース(BS)キーがあるので、HHKBの感覚が抜けきれませんでした。単純に打ち間違いが多いのと、遠い違和感がなかなか抜けきれませんでした。Continuums)の概念についてskonno2020-06-06自己設計システムとは、システム内の選択可能なプリミティブから、データベースのワークロードとハードウェアに最適な組み合わせを自動的に生成するという概念のものです[1]。今回は、この自己設計システムのコンセプトの著者の、キーバリューストアを題材とした直近の論文を紹介してみます[2]。自己設計(Self-Design)は中世の原子論的に、基礎となる設計要素を組み合わせ、最適な組み合わせとなるシステムを構成する概念のものです。自己設計による最適化手法には、学習コストモデルを用いた最適化や機械学習が用いられ、新しい組み合わせが未知のアルゴリズムやデータ構造を生み出すことで、パフォーマンスを大幅に向上させる可能性があります[1][3]。本論文では、具体的な評価対象システムとしてキーバリューストアを題材に、自己設計(Self-Design)における手法を提案しています。キーバリューストアは、キーと値のペアを格納するデータ構造を実装したものです。キーバリューストアは、ソーシャルメディアのグラフ処理、アプリケーションデータのキャッシング、NoSQLストレージ、オンライントランザクション処理などの、多種多様なアプリケーションの基盤として活用されています[2]。キーバリューストアのデータ構造については、読み取り・書き込み・メモリ消費量には常にトレードオフが存在し、この3つ全てを最適とするデータ構造は存在しません[2]。結論としては各目的に応じたデータ構造が必要となるのですが、現時点で代表的なデータ構造として、B+Tree、LSMツリーなどが存在しています。B+Treeは、RDBMSやファイルシステムでも採用されている主要なツリー構造で、合理的なメモリ消費量で読み取りと書き込み性能のバランスに優れ、現在はOracleの製品であるBerkeleyDBや、近年でもMongoDBの標準ストレージエンジンとなったWiredTiger、FoundationDBなどのキーバリューストアに採用されています。CassandraやHBase、さらにはMySQLやSQLiteなどのRDBMSの主なキー管理などにも採用されています。B+ツリー構造より書き込み性能は優れますが、読み込み性能は悪化する場合があります。Hash-table)などの新しい構造もあります。アプリケーションに適切なパフォーマンスを提供するため、複数のデータ構造を排他的に提供する場合もあります。MongoDBのWireTigerでは、B+TreeとLSMツリー実装を排他的に個別にサポートしており、RocksDBでは部分的にハッシュテーブル構造を取り入れて最適化しています。多くの最新のキーバリューストアは、相互に排他的なスワップ可能なデータレイアウト設計のセットで構成され、多様なパフォーマンス特性を提供します。WiredTigerはBツリーとLSMツリーの実装を個別にサポートして読み取りまたは書き込みをそれぞれ最適化しますが、RocksDBファイルはソートされた文字列レイアウトまたはハッシュテーブルレイアウトをサポートして、範囲の読み取りまたはポイントをさらに最適化しますそれぞれ読み取ります。自己設計(Self-Design)の長期的な研究課題は、例えば前述のキーバリューストアの場合、対象の問題に最適なデータ構造を、簡単または自動的に選択できるかが重要な課題となります。Continuums)の概念を提唱しています。