Posts

今日は文化の日ですね。明治天皇の誕生日だそうです(調べた)。現在の上皇様の誕生日については平日になったりしてますが、日本はすでに祝日がめっちゃ多い国なので、これ以上増えてもなぁ、という。 そんなことはさておき、文化の日らしく？久し振りに新しいキーボードを作成しました。 <!–more–> 作ったやつ タイトルにもうがっつり書いていますが、claw44というキーボードになります。 公式から引用すると、特徴は 手を置いた時に自然な状態に落ち着くこと指の移動をスムーズにすること小指に優しく、親指をもっと活用してあげること だそうです。また、↑のページにあるような専用のキーキャップが用意されていたり(これの質感は非常にgoodでした)と、かなり力が入っています。 作ったのはこんな感じになりました。 親指キーキャップだけ、公式のショップで売られているものにしました。結構いいお値段したもので・・・。 ちなみに前利用していたのは Corne Cherryになります。多分遊舎工房が開く前に組み立てたやつなので、3年とか前ですかね。 購入したもの https://shop.dailycraft.jp/products/claw44 このキーボードの作者自身が運営しているショップで購入しました。上記でPro Microとかダイオードとか一通り入っているので、スイッチとキーキャップ、ケーブルだけあればOKです。 https://shop.dailycraft.jp/products/3dkeycaps_claw44 また、専用のキーキャップを購入しました。親指分のキャップが不足していたのと、3Dプリンタで作成されたものがどういう感じなのか気になったので。 なお、スイッチは前のキーボードから剥して再利用しています。親指部分はCherry MXの赤軸、それ以外は銀軸です。 銀軸については https://mag.nioufuku.net/2020/07/26/gadget/00067-cherrymx-silver-switch/ などが参考になります。個人的にRealforceの30gを利用していたくらいなので、押下圧は軽い方が好みです 組み立て難易度 (一気に作ったので途中の写真が無い・・・) 今回キーボードを作成した理由は、前使っていた自作キーボードのハンダが一部クラックしてしまったため & しばらく同じものを使っていたので別のものも使ってみたかった、という感じですね。 特にさっさと構築したかったのと、久しく半田付けをしていないのとめんどくさい表面実装を避けたかったので、普通のダイオードを利用できるこれにしました。 遊舎工房とかで結構見ましたが、最近出たようなものは大半が薄さを意識してか表面実装ダイオードでした。部屋で利用するものなので、多少分厚くても全然問題ないかなーと思います ソケット部分が多少めんどくさいですが、ダイオードが簡単だったり、左右の区別があるので間違えづらいなど、組み立て難易度としてはかなり簡単な方だと思います。これよりも簡単というか簡略化されているものとしては、Corne Cherry Lightなどかなーとは思いますね。ソケットが無いので、キーを取り替えるのが超めんどくさいですが、そもそもキーってそんなに入れ替えるのか？という話もあるので。 RGBとかそういうのは個人的にまったく不要なので、このくらいシンプルなものが好みです。 ファームウェア 元々corneで色々弄っていたので、これをできるだけ再利用しました。というかどっちもquantumを利用していたりするのは変わらないので、結果としてはレイアウトのところだけ弄ったら動きました。 https://github.com/derui/qmk_firmware/blob/master/keyboards/claw44/keymaps/derui/keymap.c なお、せっかくある親指キーのうち一つには特に割り振っていません。理由としては、 そこまで不足を感じていない 親指をそこまで広げると結構負荷を感じる 利用頻度の低いキーで単独で押したいものがあんまりない というのがあります。まぁ、なんか必要があったら追加します。 使用感 元々Corneを利用していたのですが、それよりもかなりダイナミックに薬指と小指に落差が設けられています。 そのため、最初はいつものとおりに打とうとしてキーの無い位置を叩くこともありました。ある程度慣れた現状だと、逆に小指をあんまり動かさなくても p とか q とかにアクセスしやすいので、逆にそれだけ手なりを動かしていたんだなぁ、という感覚です。 ただ、落差があったり斜めになっていたりと、タイピング向けの構成になっているので、ゲームでWASDを使うような感じにすると、逆に利用しがたい・・・みたいな感じですね。ただ、プログラミングとかする分にはまったく問題ないです。 専用のキーキャップもいい感じで、ちょっとフルセットにしとけばよかったか・・・と思ってるくらいには質感がよろしいです。余裕があれば是非お勧めします。 まとめ 久し振りにキーボードを作成して、まずは半田付けのやりかたを再度練習したりしてましたが、総じて満足です。実際にキーボードの半田がクラックしているのを見た瞬間は、HHKBを使うか・・・とかも思いましたが、ちょっといまさら分割していないやつを利用する気力もなかったので・・・。 HHKB自体は、その耐久性を生かして万が一のためのキーボードとして残してあります。まれに失敗してしまったりするともうHHKBしか頼れないので。 年末とかにむけて工作キットのノリでチャレンジしてみるのはいかがでしょうか。工具を買うのはな・・・って場合は遊舎工房などで貸出サービスもやってたりするようなので、行ける方はそちらを利用したりしてもよいと思います。 この文章はClaw44で書かれています。

気付いたら10月も終わりです。もう今年も残りは二ヶ月ということで、月日の流れは本当に速い。 さて、先日登場したParcel2.0を個人のプロダクトで試してみたので、それについてライトに書いてみます。 <!–more–> Parcelとは まずparcelとはなにか・・・ということですが、こちらについては公式ページを見てもらうのが一番早いです。あえてまとめるとすると out of the boxで動作するbundler dev server/hot reloadingなどが組み込み済 CSS/XML/JSONなどのbundleも組み込み済 minificationやimage optimizationなども実現 Rustで構築されているため、マルチコア利用かつ高速 という特徴があります。特にRustで構築されているということと、後述するようにtype checkingを省いているため、特にTypeScriptのビルドおよびbundleは特筆すべき速度です。 parcelで動かすようにしてみる https://github.com/derui/simple-planning-poker 犠牲となるのはこのリポジトリになります。元の構成はWebpack5でゼロから構築したものになります。 個人開発では、create-react-appとかNext.jsとかはあんまり使いたくない派閥です https://github.com/derui/simple-planning-poker/tree/parcel で、parcel化したものがこれになります。 parcelは、各種ツール(組み込まれているものに限る)の設定ファイルは自動的に読み込んでくれるので、設定ファイル群はそのまま残っています。 具体的な手順は以下のようになりました。 yarn add -D parcel @parcel/transformer-typescript-tsc tsc postcss.config.jsとかのJavaScriptで記述されていた設定をJSONに移行 TypeScriptと、tsconfig.jsonでpathsを利用していた場合、path設定を書き換える package.jsonのsourceでルートになるファイルを設定する webpackの利用をやめる TypeScriptを利用している場合の注意点 TypeScriptを利用しているとき、importでめっちゃ ../ のような相対パス表記が出るのを防ぐため、 paths に以下のような設定をしている場合があると思います。 { ..., basePath: "./", paths: { "@/*": ["src/ts/*"] } } 実はこの挙動ですが、TypeScriptのオリジナルコンパイラにおける独自拡張であり、Parcelでは動作しません。 parcel2.0のドキュメントではこのあたりの記述が存在しており、基本的には↓のような記述にする必要があります。 { ..., basePath: ".", paths: { "~*": ["./*"] } } こうしないと、bundle時に超大量のエラーが出て涙することになります。 実際JSによる設定レスでいけたのか？ 結果としては、若干書き換えは必要でしたが、 JSでの設定レス でビルドできることは確認しました。postcssとかeslintの設定に関しては、デフォルトの挙動で構わないのであれば、本当に設定レスで動かすことができるでしょう。 ...

仕事の方で、GraphQLをちょっと検討しだした + 個人的にも興味は持っていたので、本格的に触ってみることにしました。 GraphQLをKotlin + SpringBootで利用する方法としては、大きく三つありそうです。 graphql-java-kickstar Domain Graph Service Spring GraphQL の三つがありそうです。どれもコアとしてはgraphql-javaを利用しているため、どのように統合するか？が焦点になっていますね。 Spring GraphQLは、記事の時点(2021/10)では1.0にむけてのマイルストーンを粛々と実装している、という状態です 今回は、graphql-spring-boot-starterを利用してみた感想をば。なお、そもそもGraphQLとは？については、 公式サイトを見ましょう。 <!–more–> セットアップ さて、まずはセットアップ・・・なんですが、実はこのセットアップが大分苦戦しました。なぜかというと、2021/10時点で検索できる記事だと、結構古いパッケージ構造になっているケースが多く、色々動かない・・・というのがあったためです。 現状、 graphql-java-tools graphql-spring-boot-starter graphql-java-servlet といった関連は、すべて graphql-java-kickstart というGitHub Organizationにまとめられているので、こっちを使うのが第一になるかと。 plugins { id("org.springframework.boot") } apply(plugin = "io.spring.dependency-management") dependencies { implementation("org.springframework.boot:spring-boot-starter-web") implementation("com.graphql-java-kickstart:graphql-spring-boot-starter:12.0.0") implementation("com.graphql-java-kickstart:graphql-java-tools:12.0.0") } 最小構成だと↑のような感じになります。バージョンなどはよしなに。 schemaとのマッピング graphql-java-toolsを利用するかしないか、で大分書きかたが異なりますが、基本的にはgraphql-spring-boot-starterを利用する場合は併用しておいた方がよさそうです。 GitHubにも書いていますが、必要なら↓のようなpropertiesを追記します。 graphql: tools: schema-location-pattern: "**/*.graphqls" # Enable or disable the introspection query. Disabling it puts your server in contravention of the GraphQL # specification and expectations of most clients, so use this option with caution introspection-enabled: true さて、マッピングについてはgraphql-java-toolsに準ずるので、Queryに関しては結構シンプルに書くことができます。 ...

10月になっても半袖で十分というのはどうなんだ、と思いつつ、でもようやく涼しくなるようになってきました。 リモートワークでも生活でもずーっと使っているデスク環境を更新したので、その話を書こうかと思います。 <!–more–> 元々のデスク環境 さて、そもそも以前のデスクはどんな感じだったのかというと。 こんな感じでした.これは実際にデスク周りを変更する直前なのでディスプレイとかは電源切ってます。 このデスクのスペックとデスクの上にあったものとして、 デスク( 幅160cm x 奥行60cm x 高さ70cm ) ディスプレイ2枚 27inch デスクトップスピーカー キーボード トラックボール コントローラー2個 PS5 ちょっとした物いれ がありました。PS5は右のディスプレイの影になってますね。左端にちょこっと見えてる台みたいなやつは、デスクトップPCのキャリアです。 前の構成の課題 このデスクは前の部屋でも使っていたものを持ってきたやつですが、新しい部屋で使ううちに色々課題が生まれてきました。 左側のデッドスペースが気になる デスクトップを入れているキャリアは、その上部空間がまるごと無駄になってます ゲームのコントローラーをしまう場所が無い 別にいいんですが、いつまでも剥き出しというのも・・・ というかこのデスクは仕事でも使うので、これはこれでどうなん？という 上下のスペースが活用できていない デスクの幅が160cmあるので、特に右側とかは上部に隙間がないという感じになってます。 これらの課題をどうしようかな、と考えてみました。 デスクの幅が広すぎるので、もうちょっと狭くしても問題ない 逆に、奥行がもうちょっとあってもよいかな、という考えにもなりました iPadが置いてある辺に、通常はノートPCが置いてあるので、若干奥行が微妙だったりします 右にあるディスプレイをPC台の上に持っていく 地震があったりするとちょっと怖いですが、エルゴトロンを信じて サイドデスク的なもので上下のスペースを活用する PS5とかをデスクの上に載せないで、別に載せる感じで 後、デスクはまだリモートワークが続きそうでもある & 生活のほぼすべてがこの周辺なので、立ちながらとかできるように、電動昇降デスクを検討しました。 劇的After さて、とりあえず更新してみました。 ジャーン。ちなみにこれはまだ配置を調整している最中なので、現在はもうちょっと調整されてます。 更新ポイントは以下のような感じです。 憧れの電動昇降デスクにした サブデスクを導入した ディスプレイの配置を変更した スピーカーの位置を調整した 電動昇降デスクとサブデスクは↓にしました。サブデスクというかメタルラックなんですけど、ちょうどいいやつがこれくらいしかなかったんです。 デスクは、調べてみるとFlexiSpotを利用している・・・というのがかなり多かったので、最初はそれを検討してました。しかし、それらの記事をよく読むと、半分くらいが FlexiSpotから提供を受けている ということがわかりました。 これはマーケティングの一環として行われていることだとは思いますので、それ自体はよいのですが、実際それ以外のレビューを見ていると、サポートとかに課題がありそうだった & とてもいいお値段がするので、ちょっとどうしようかなぁ・・・、となってしまいました。 結局は、同等の機能があって一応国内メーカーである 山善 製のものを選択しました。 デスク全部合わせても椅子より安いんですけどね ちなみに電動昇降デスクは、大人二人で1時間〜1時間半くらいかかる、ということでしたが、実際に大人一人でやってみたところ、始めたのを若干後悔するくらい時間がかかりました。腰をやらなくてよかったです。 で、どうなの？ まだ移行してから1日しか経過していませんが、左にあるマイクスタンドさえなんとかなれば・・・という感じです。現状ここ以外に置けないのですが、ここにあると左側のディスプレイがちょっと見えないんだけど・・・となってしまってます。 ...

もう9月も末で、涼しくなってきたなぁと思ったらいきなり暑くなったりと、季節があっちこっちいきますね。これも温暖化の影響でしょうか。 今回も小ネタで、最近やったfirebaseのrealtime databaseでローカルのテストをやる方法をサラッと書いてみます <!–more–> Realtime databaseをローカルで動かす Realtime databaseのテスト手法にはいくつかあると思いますが、基本的にはローカルで動作するemulatorを利用します。 https://firebase.google.com/docs/emulator-suite?authuser=0 β版とはいえ、かなりしっかりできている印象で、少なくともローカルでテストするレベルであれば必要十分です。さすがに実Databaseに比べると、レイテンシーがなさすぎて(そりゃそうだ)、実際にpublishして動かしたときに アレ？ ってなる可能性もありますが。 さて、このemulatorですが、firebaseコマンドで初期化するときに選択しているか、configで追加したら、後は以下のコマンドを叩くだけで起動します。 $ npx firebase emulators:start デフォルトでは localhost:4000 で起動し、 localhost:9000 とかでrealtime databaseが起動します。この状態でも、databaseには繋げることができるので、やろうと思えばテストを書けます。 emulators:start の問題 しかし、emulators:startにはいくつか問題があります。 そのなかでも大きな問題は、 backgroundでの起動ができない & テストに同期して落とすとかできない という点です。まぁそりゃそうなんですが。 emulators:exec を使おう そんなときに役立つのが、 emulators:exec というコマンドです。このコマンドは、引数で渡されたコマンドを実行する前後でemulatorのstart/stopをきちんとやってくれる、one-pathなemulatorの起動を提供してくれます。 なので、 $ npx firebase emulators:start npm run test のように書けば、テストが開始する前にemulatorが立ち上がって、テストが終了するとemulatorが終了します。 また、引数に渡したコマンドがwatchとかであれば、watchを C-c とかで落とすまでずっと立ち上がりっぱなしになるので、ずっとテストしてられます。 realtime databaseを使うIntegration test こんな塩梅のボイラープレートを書く必要があります。RulesTestEnvironmentは、 @firebase/rules-unit-testing で提供されている便利ツールです。firebaseと結合したテストを書く場合はこれを使っておくのがよさげかと思います。 let database: any; let testEnv: RulesTestEnvironment; beforeAll(async () => { testEnv = await initializeTestEnvironment({ projectId: "demo-project-1234", database: { host: "localhost", port: 9000, }, }); database = testEnv.authenticatedContext("alice").database(); }); afterAll(async () => { testEnv.cleanup(); }); afterEach(async () => { await testEnv.clearDatabase(); }); 若干の課題 多分私の書いてるソースがどっかおかしいんだと思いますが、実行されるタイミングとか順番によっては、うまくデータが初期化されていなかったりなんだりします。これは原因を探っているところではありますが、基本的にはかなりの速度で動作してくれるので、ある程度の数のテストがあっても問題はなさそうです。 ...

今回は超小ネタです。 <!–more–> 最近はEmacs上でのcompletionとして、orderlessなどの標準のcompletion-readなどに則ったものを利用してます。Emacsの標準補完は、実はかなり柔軟性に富んでいて、様々なカスタマイズが可能になっています。 completion-readのカスタマイズでは、 completion-category-overrides という変数で、completion-readによるマッチング方法を categoryごとに 変更することができます。 このcategory、 completion-metadata という関数で取得できるmetadataから取得することができます。 (completion-metadata-get (completion-metadata "" table nil) 'category) このtableとは、(私の理解だと)completion-readの第二引数として渡す関数です。この関数は、第３引数としてactionを取り、このactionに 'metadata というシンボルが渡された場合は、metadataを返す必要があります。 completion-metadata-getはこれらのmetadataから、特定の情報を取得するものです。なので、あるパッケージの補完をカスタマイズしたいときは、これを調べればカスタマイズできます。 ・・・が、場合によってはcompletion-readの呼び出しでlambdaを利用していて、 completion-metadata が使えないケースがあります。 実際、org-roam-node-findではlambdaで渡されており、categoryを知るためには結局その中身まで見る必要がありました そういう場合は、しかたがないのでパッケージの中を completion-read で検索してみると大体見付かります。 そんな場合もあるんだよ、というメモでした。

涼しかったのも終わり、相変わらずの厳しい残暑が戻ってきてしまいました。日が出ていないのに36℃とか勘弁して欲しいですほんと。 今回は、ひょんなことからガッと作ったアプリケーションで、Recoil.jsを使ってみたのでその話をしようかと思います。 <!–more–> 作ったもの これです。といってもまだ若干イケていないところがあるので、画面とかはないですが。 https://github.com/derui/simple-planning-poker 複数人で一つのゲームを開催できる 全員がカードを選択したらその平均値を表示できる 表示し終わったら次のゲームを直ぐに開始できる カードの選択、show downなどはリアルタイムで同期されます。 今日時点で9daysなので、大体1週間ちょっと(平日の夜 + 土日の日中)ですね。 なんで作ったん？ チームではスクラムっぽいことをやっていて、そのなかで見積もり手法としてプランニングポーカーを利用しています。 で、最初はアナログな手法でやっていたのですが、リモートが長く続くこともあり、 https://planningpokeronline.com/ というサイトを利用するようになっていました。 で、↑のサイトを使っていたときに、チームの中から(自分が言い出したかもしれん)、 これってFirebaseを使えば割と簡単に出来るんじゃない？ という話が出ました。 そういえば、Firebaseって使ったことねーなー。 と思ったので、じゃあやってみんべ、と作ってみました。 state管理ライブラリの選定 さて、今回はガッと作ろうと決めていたので、フロントは慣れている React.js + TypeScriptを使うことにしました。react-routerとかも使ってます。が、あんまりまともに使ったことがないのでreact-routerはいつも迷いどころ・・・。 ただ、state管理として Redux を使うかどうか・・・というのはちょっと迷っていました。いくらガッと作ると言っても、趣味プログラミングならばちょっとは冒険してみたいところ。 と調べていたら、 Recoil.js という新しめのstate管理ライブラリを見つけました。 A state management library for React と謳っていることもあり、完全にReact専用です。なんといってもHookを前提にしているので、Reactじゃないとそもそも動作しません。Reduxは別にReactに閉じるものでもないことを考えると、汎用性があるわけではないなーとは思ったんですが、まぁ使ってみるか、とやってみました。 Recoilの基本 基本的なものは、公式サイトを見るのが一番わかりやすいと思うんですが、簡単に紹介します。 Recoilの基本は、 atom と selector の二つの概念です。といっても、 atom = state で、 selector = atomから情報を取得したり加工して情報を返す という区別があります。 const textState = atom({ key: 'textState', // ユニークなID。atom/selector全部を通じてユニークでなければならない default: '', // デフォルトの値 }); const quotedText = selector({ key: 'quotedText', // ユニークなID。atom/selector全部を通じてユニークでなければならない get: ({get}) => { const text = get(textState); return '"' + text '"'; } }); みたいな感じです(例が思いつかなかった)。recoilは、selector/atomの間にデータフローを作成し、atomが更新された場合はそのatomを利用しているselectorを更新する、という形になっているようです。 ...

気付いたら8月です。猛暑というか酷暑というかですが、台風が来てくれると多少熱が持っていかれるので、多少は過ごしやすくなってくれるといいんですが。 少しは別のこともやらんとなぁ、ということで、久し振りにRustを使ってちゃんとしたツールというのを作ってみました。 <!–more–> 何を作ったのか https://github.com/derui/org-roam-protocol-installer こんなのを作りました。今、個人なナレッジの蓄積としてorg-roamを利用しています。org-modeには、org-protocolという、外部からorg-modeに対してcaptureを行わせることができる仕組みが存在しています。 org-roamにはこれを独自に拡張した、org-roam-protocolというものがあります。これを利用すると、webページとかをお手軽にorg-roamにcaptureする・・・ということができます。 が、リンク先のドキュメントを見てもらえばわかるのですが、ファイルを作ったりなんだりと、別段複雑ではないものの、多少手順が必要だったりして、これはこれでなぁ・・・みたいなことを考えました。特にmacOSがめんどくさい。 ということで、じゃあこれをインストールするだけのツールを作ればいいんでない？ということを思いつき、ついでにRustの勉強(実際には以前使っていたので復習)がてら、Rustで作ってみることにした、という次第です。 使ったcrate Cargo.tomlを見たらわかりますが、今回はきちんと？crateを利用しました。 clap CLIのフレームワーク。サブコマンドの定義とか色々可能 dirs HOMEとか特殊なディレクトリとかにアクセスするため tempfile 一時ファイルを適切に作成するため ソースは見てないけど、挙動的にdropすると削除されるようになってる quick-xml 高速な低レベルXMLライブラリ。Info.plistの編集で使ってます 常日頃OCamlをよく利用している側としては、一つの処理に対して色々なcrateがあってすげーなぁ、と思うと同時に、どれを選んだらいいのかわからない問題も起きがちだなぁ、というのはやっぱりありますね。 苦労した点 私はmacOSを個人では保有していないので、macOSでのインストール作業をどう自動化するか？を結構悩みました。 Script EditorをApplescriptで起動して保存させる・・・？ ApplescriptをApplicationとして保存しなければならないのですが、そのためにはScript Editorしか使えなさそうに見えた そもそもApplescriptで↑ができる・・・？ とか考えましたが、最終的には osacompile というコマンドの存在を知り、これでええやんってことになりました。このあたり、独自形式を突っ走るmacOSがめんどくさいですね・・・。 所有権とかは苦労していないの？ Rustでよく言われる所有権とかborrow checkerですが、そこまで苦労はしませんでした。というか、普通にプログラムを作っていったら、一つの中で書きこみと読みこみを同時にやる、とか基本的にそこまでしないはずなので。 ライフタイムとかを考え始める = structにオブジェクトを含めるようになると、めんどくさくなるのが目に見えてますが、今回はそこまで必要なかったというのもあります どちらかというと、 File::open と File::create の違い(Cとか他の言語だと、大抵はopenに引数を付けてwriteとかappendとかにする)とか、traitを渡すためにはどうすればいいか、とかの方がよほど苦労しました・・・。 エラーメッセージが大分親切になっているので、そこまで困らなくなったように思います。 あらためてRustでよいなと思った点 Testが統合されている Rustはtest用のモジュールを、それぞれのモジュールに含めることができるので、かなり細かいテストまで作成できる、という点はやはりよい点ではあります。 ただ、これには負の点もあって、内部実装を細かくテストしすぎると、リファクタリングとかがめんどくさくなります(private methodをテストするのと同様のことができてしまうので)。 ポインタの心配がない Null dereferenceとかの心配が無いのはよいです。まぁ、その代わりにmutとかborrow checkerとかを確認しなければならない、ということでもあるんですが。 CとかC++とかで生ポインタを触る場合は、super powerを手にしているのと同じようなものなので、注意しなければならない、というのを思い返させてくれますね。 crateが豊富 上でも書きましたが、直近のえらい盛り上がりに比例して、crate数がものすごいことになっています。当然ながらそうなると玉石混交にもなるんですが、やりたいことに対してcrateが見つかるというのは気楽です。 OCamlとかだと、下手したら存在しないから自分で書く羽目になる、とか、メンテナンスが進んでいないやつしかない・・・とかにもなりえます。最近は少なくなってきましたが。 targetを変更してビルドしやすい OCamlでは結構めんどくさいので、これはうらやましい点ですね。まぁ、前提や設計された時代背景がそもそも違うので、単純に比較するとそれはそれで無知をさらけ出すことになりますが・・・。 解決できていない点 Linuxでは動作を確認できているんですが、macOSにおいては、Gatekeeperを突破する方法がいまいちわからず、ダウンロードしたものをそのまま利用することができない状態です。 正当な手段は、Apple Developer IDを取得してきちんと署名する、ということだと思うんですが・・・。 高い Macを保有していないし、macOS向けになにをするわけでもないのに年間$99も払えません プロセスが複雑になる とかなので、基本的には色んなところで配布されているCLIを参考にしてバイパスできるようにしようと思います。 ツールを作ることでの学習 久し振りに簡単なツールを作りきりましたが、やはり簡単でもいいので作りきるということは、個人的に進歩するなぁ、という実感があります。 ...

今週はワクチン接種とwelcomeランチで、とてつもなく久し振りに何日か連続で部屋のある地域から出ました。すっかりリモートに順応してはいますが、やっぱりリアルで会話すると、人間は五感で会話しているんだなぁ、ってのがよくわかります。 以前AZIK + SKKを利用している、という記事を書きましたが、今回はちょっとそれから色々アップデートをかましたので、それについて書きます。 <!–more–> AZIK + SKKの問題 大分AZIK自体には慣れたのですが、あんまり一貫性のない拡張は利用せず、必要最低限の拡張だけを利用するようにしています(覚えられないとも言う)。 しかし、やはりSKKと利用していると色々な問題があり・・・。 SKKの標準で利用するキーとバッティングする sticky keyとの相性がよろしくない これは後述します SKKを利用していない環境のAZIKと少しずつ異なっているので、体を合わせるのが結構大変 この中でも、sticky keyが色々問題がありました。なのでちょっとそれに対して深掘ります。 SKKのsticky keyで利用されるキー さて、SKKの実装には大抵sticky shiftを実現するためにsticky keyを定義できるようになっています。 少なくとも、私が利用しているddskkとAquaSKKには存在しています これをどのように設定しているのか？を調べてみると、以下のような感じが多そうでした。 セミコロン 変換・無変換キー F + Jなどの同時押し このうち、私が試したことがあるのはセミコロンと変換・無変換キーです。同時押しは、かな入力であればよいと思いますが、SKKで要求される頻度でそれを行うと、まず間違いなく打鍵数がとても増えてしまいます。 変換・無変換キーと親指Enter/SandS 私の利用しているキーボードは、今も変わらず crkbd ですが、このような系統ではEnter/Spaceを親指に割り当てたうえで、レイヤーの切り替えも親指で行うのが大勢となっています。それに加えて、SandSを長いこと利用しているので、それも設定しています。また、日本語・英数の切り替えも親指です。そうすると、親指が担当する機能というのは・・・ レイヤー切り替え Enter Space SandS(実際にはSandEnterも設定してます) Alt/Command 日本語・英数切り替え ・・・というくらいまで拡張されています。普通のUSやJISキーボードであればSpaceとかAltしかないと思いますが、このキーボードでは親指がかなり酷使されます。よく、親指はタフな指なので〜みたいな言説がありますが、実際には親指は支持するための指であり、タフでありますが運動性は高くありません。また、支持が目的であるため、キーボードにおいては他の指と力の入れかたが異なります。そのため、親指に機能を割り当てすぎると、今度は親指の負担が大きくなりすぎる、という問題になります。 ちょうど、無変換にsticky keyを設定してしばらく運用してみたのですが、親指があまりに動きすぎるため、手もブレるし痛みもでやすい、ということがわかったため、これは却下しています。 SandSでやればいいんじゃないの？ SandSを設定しているからsticky keyは使っていない、というのも見ましたが、これはあくまで一般的なキーボードを利用しているケースです。↑にあるように、親指に多数の機能が割り当てられているときに、SKKの頻度でSandSをやってしまうと、これまた親指の酷使になります。 じゃあどうするのか ここでの問題は、AZIKにおいては促音「っ」を入力するためにセミコロンが潰されている、という点にあります。 ＡＺＩＫでは「っ」の入力は常に「；」キーを使います。「あっ、ピカッ」などという入力がとても楽になります。 http://hp.vector.co.jp/authors/VA002116/azik/azikinfo.htm さて、実際に色々文章を入力していると、このような文章を入力する機会はかなり少ないです。正直、このくらいなら xtu で入力しても問題ない・・・。AZIKでは、これで潰した元々の促音入力である tt kk pp ss などに拡張が割り振られています。しかし、これらの拡張は利用頻度を考えると相当少なく、かつ促音を単独キーで入力するときと、結果として打鍵数は同一です。 そこで、以下のようにしてみました。 セミコロンはsticky keyにするので、AZIKの定義から削除 tt ss kk pp などの拡張を削除 結果としては大分シンプルですが、AZIKそのものよりもローマ字入力との互換性が向上したのと、セミコロンというsticky keyに最適な場所を利用できるため、体感的な効率としてはかなり改善しています。そもそもddskk上のAZIKはオリジナルと変わっているので、むしろ拡張しない側にもっていくのは簡単でした。 ddskkだとこんな感じで設定できます。 ...

7月も半ばに差し掛かりつつありますね。今年はオリンピックのために4連休なので、このタイミングで小旅行に行く予定です。 今回も大分ライトな話題で、swayに今利用しているアプリケーションのタイトルを出したいという話です。 <!–more–> swayとswaybar swayには、swaybarという最上部にあるbarを表示するためのアプリケーションが付属しています。これはi3にあるi3barとほぼ同様の機能を提供しています。 ・・・が、このswaybarには一つ不足している機能があり、 アプリケーションのタイトルを表示する という機能が無いのです。 https://manpages.debian.org/experimental/sway/sway-bar.5.en.html 個人的に、 https://github.com/takaxp/org-onit を利用して時間を計測するようなワークフローになっているため、タイトルが出ていると非常に助かります。 モードラインに出せば？という意見もあると思いますが、モードラインはすでに色々な情報で一杯なので、これ以上増やしてもなー、というのがあります swaybarの代替探し swaybarの代替としては、自前でスクリプトを書くというのもありますが、代替もあります。 その中で一番使われている(と思う)のが、waybarです。 https://github.com/Alexays/Waybar swayのみならず、wlrootをベースとしたcompositerで利用できるようになってます。 こいつだと、タイトル以外にも、色々と表示させることができますし、カスタマイズ性もかなり高いです。というわけで、これを使ってみることにしました。 waybarのカスタマイズ さて、waybarには二つの設定ファイルがあります。一つはwaybar自体の挙動 = 表示する位置やモジュールの種類、位置や設定を設定するためのJSON、そしてスタイリングをするためのCSS、という設定ファイルがあります。 { "layer": "top", "modules-left": ["sway/workspaces", "sway/mode"], "modules-center": ["sway/window"], "modules-right": ["temperature", "memory", "clock"], "sway/window": { "max-length": 50 }, "memory": { "interval": 10, "format": "{used:0.1f}GiB/{total:0.1f}GiB" }, "clock": { "interval": 5, "format-alt": "{:%4Y/%2m/%2d %H:%M:%2S}" }, "temperature": { "hwmon-path": "/sys/class/hwmon/hwmon1/temp1_input", "critical-threshold": 80, "format": "{temperatureC}°C" } } 設定ファイルはこんな感じにしています。temperatureのところは個々人で違いますが、私の場合はCPUの全体的な温度となっています。これ以外にもGPUの温度を出したりもできるはずです。 CSSですが、これはかなり巨大なので、 https://github.com/derui/dotfiles/blob/master/waybar.style.css を参照してもらった方がよいかと・・・。ちなみに、変更点としてはbar全体の高さやフォントの設定くらいです。 カスタマイズしていきましょう せっかくlinuxやswayを利用しているのであれば、かなり自分の好みに合わせて変更していくことができます。これはMac/Windowsにはない利点です。当然ながらそのためには色々調べたりしないといけないですが、その結果として自分のやりやすいようにできていけば、それはそれでよいんではないでしょうか。 ちなみに私は結構デフォルトで満足してしまう(最近はデフォルトでも十分なケースが多い)方ですが、やりづらい場所はできるだけ改善していきたいなぁ、と思ってます。