Emacsの設定を色々いじった -その1-

いろいろ書くネタを探しているうちに4月になってしまったので、3月にやったEmacs改善について書いてみようかと思います。結構量が多くなったので、分割します。 <!–more–> なお、かなりの部分で Emacsモダン化計画 -かわEmacs編- を参考にさせていただきました。私の.emacs.dはGithubにおいてあります。 https://github.com/derui/dot.emacs.d doom-modeline + all-the-icons doom-modeline all-the-icons 最初に入れたパッケージです。modelineが一気にかっこよくなりました。all-the-iconsでは色々調べましたが・・・。 (use-package all-the-icons :custom (all-the-icons-scale-factor 1.0)) (use-package doom-modeline :commands (doom-modeline-def-modeline) :custom (doom-modeline-buffer-file-name-style 'truncate-with-project) (doom-modeline-icon t) (doom-modeline-major-mode-icon nil) (doom-modeline-minor-modes nil) :hook (after-init . doom-modeline-mode) :config (line-number-mode 0) (column-number-mode 0) (doom-modeline-def-modeline 'main '(bar workspace-number window-number evil-state ryo-modal xah-fly-keys matches buffer-info remote-host buffer-position parrot selection-info) '(misc-info persp-name debug minor-modes input-method major-mode process vcs checker))) なお、全体的にuse-packageを利用しています。 which-key which-key ...

April 4, 2019 · derui

all-the-iconsとCicaの組み合わせでアイコンがずれる

最近 Emacsモダン化計画 -かわEmacs編- を参考にしつつ、しばらくいじっていなかったEmacsをいじっています。しかし、all-the-iconsを導入したときに、アイコンが色々?な感じになってしまいました。 原因を探ったり何なりで解決できたので、備忘録として残しておきます。 <!–more–> 発生していた事象 普段Emacs上ではCicaフォントを使っています。以前はRictyを利用していましたが、Rictyよりもこちらのほうが好みだったので、1年くらい前から愛用しています。 https://github.com/miiton/Cica ところが、Cicaを利用している環境でall-the-iconsを有効にしたら、色々と問題が発生しました。スクショは撮っていなかったので画像はありませんが、次のような状態でした。 doom-modelineのアイコンが明らかにおかしい 保存アイコンが gopher になってたり、gopherのアイコン自体が違ってたり Gitのアイコンが地球儀になってたり アイコンのサイズが色々おかしい all-the-iconsのアイコンを全部表示すると、明らかに別のアイコンが表示されている という感じで、もう完全に何かが干渉していることは明らかでした。 調査 だいたいまずいのはフォント設定周りだろうと、使っているフォント設定自体を無効化すると、うまい具合に表示できました。これから、以下のような仮定を立てました。 追加で行っている設定では、 create-fontset-from-ascii-font で作ったものに set-fontset-font していた set-fontset-font の範囲は 'unicode だった=all-the-iconsで利用している範囲を上書きしていた? 仕様上、一回設定したものを上書きできないっぽい=Cica側の特徴に原因が? ここまでで、大体Cicaに設定されている絵文字部分とall-the-iconsが干渉している、と判断しました。 解決した 最終的には、Cicaから絵文字を除いたバージョンに切り替え、フォント設定を以下のようにしました。 (defun my:font-initialize () "Initialize fonts on window-system" (interactive) (cond ((eq window-system 'x) (let* ((size my:font-size) (asciifont "Cica") (jpfont "Cica") (h (round (* size 10))) (jp-fontspec (font-spec :family jpfont))) (set-face-attribute 'default nil :family asciifont :height h) (unless (string= asciifont jpfont) (set-fontset-font nil 'unicode jp-fontspec nil 'append)) (when (featurep 'all-the-icons) (set-fontset-font nil 'unicode (font-spec :family (all-the-icons-alltheicon-family)) nil 'append) (set-fontset-font nil 'unicode (font-spec :family (all-the-icons-material-family)) nil 'append) (set-fontset-font nil 'unicode (font-spec :family (all-the-icons-fileicon-family)) nil 'append) (set-fontset-font nil 'unicode (font-spec :family (all-the-icons-faicon-family)) nil 'append) (set-fontset-font nil 'unicode (font-spec :family (all-the-icons-octicon-family)) nil 'append) (set-fontset-font nil 'unicode (font-spec :family (all-the-icons-wicon-family)) nil 'append)) (message (format "Setup for %s with %f" asciifont size)))) (t (message "Not have window-system")))) この設定を、after-init-hookで実行しています。元々asciiとjpで異なるフォントを利用していた名残の設定だったので、整理しました。普通にset-face-attributeだけでいいんじゃないの?と思われるかもしれませんが、部屋のデスクトップと現場のラップトップでフォントサイズを切り替えられるようにしているので、若干複雑な設定をしています。 ...

March 9, 2019 · derui

Create React App + TypeScriptにStorybookを追加してみる

タイトルの通り、CRA2 + TypeScriptのプロジェクトに、更にStorybookを追加してみました。 <!–more–> 前口上 いろいろ試すための個人プロジェクトを作って、色々なライブラリであったり、言語であったりを試しています。一応ツールとして利用したいと思って作っていはのですが、永遠に動くようにできないんじゃないかという懸念と戦いつつ実装しています。いつか日の目を見ることを祈りつつ・・・。 FrontendとしてはElectronで作っていて、Create React App + TypeScriptでGUIを作っています。今回、これにStorybookを追加することにしました。 Storybookとは Storybookの公式から、Storybookについてを引用します。 Storybook is a UI development environment and playground for UI components. The tool enables users to create components independently and showcase components interactively in an isolated development environment. https://storybook.js.org/basics/introduction/ Componentのカタログ(showcase)を作り、再利用を促しつつ、生きた例として提供する、という感じでしょうか。 なぜ追加するのか なんとなく+気になるから。 ・・・いつもどおりの理由ですが、実際コンポーネントベースの開発をしていると、 基底となるコンポーネント が欲しくなります。これがないと、同じようなものが量産されるというのを実際に経験してます。また、実際に動くものがあると、話がしやすいとかの効果もあるようです。デザイナーと協業とかしたことないので、デザイナーから見ても嬉しいのか?というのは実感できませんが・・・。 ただ、いきなりプロジェクトに投入するのはどうなんだ?ということで、どうとでもなる個人プロジェクトで試してみようという次第です。 追加する 今回使うプロジェクトの前提は以下のとおりです。 create-react-appの2.1以降 create-react-app公式の方法でTypeScriptを導入している まずはStorybookを追加します。Storybook公式の手順は npm ですが、私は yarn を利用しているので、以下はyarn前提です。 $ yarn add -D @storybook/react # もしかしたら下のコマンドはいらないかもしれない $ npx -p @storybook/cli sb init # TypeScript向けのlibraryを追加します $ yarn add -D @types/storybook__react $ yarn add -D @storybook/addon-info @types/storybook__addon-info react-docgen-typescript-webpack-plugin $ mkdir .storybook さて、これで追加自体はできるんですが、これだけだと動かないようで、issueが立てられています。この中で示されている解決策を導入してみます。 .storybook/webpack.config.js として以下の内容を追加します。 ...

February 23, 2019 · derui

zshからfishに移行してみた

一ヶ月くらいEucalyn配列でできるだけ生活していたら、CorneでQWERTYが全然打てなくなっててびっくりしました。ノートPCのキーボードではちょっと引っかかるけど普通なので、Corne用の脳領域が出来たようです。 それは置いておいて、つい最近zshからfishへ移行してみましたので、関連する諸々をメモしていこうかと思います。 <!–more–> fishや他のdotfilesは以下で管理しています。 https://github.com/derui/dotfiles 移行の動機 なんとなく。 いきなりこう書くのもどうかとは思いますが、実際↑の通りなので。元々はzshを5年くらい使っていましたが、ここ2年くらいはほとんどカスタマイズとかもすることなく、完全に惰性で利用している感じでした。 zshはemacs/vimのようにカスタマイズを極めれば最高なのは確かなんですが、その時間自体を取れなくなってきた、というのが主な理由です。それと、結構前からfish推しの声を聞いてきたので、試してみたいというのもありました。 移行プラン zshからfishに移行するにあたり、何が必要か?を洗い出してみました。 plugin manager fzf + ghq/historyの連携 各種補完 ・・・めっちゃ少なかった。ので、移行自体はさらっと行けました。 plugin manager zshではzplugを利用していましたが、fishではfisherを利用しました。次のような感じでインストールしました。 # install fisher if not functions -q fisher set -q XDG_CONFIG_HOME; or set XDG_CONFIG_HOME ~/.config curl https://git.io/fisher --create-dirs -sLo $XDG_CONFIG_HOME/fish/functions/fisher.fish fish -c fisher end # change location of packages installed by fisher set -g fisher_path ~/.config/fish/fisher-pkg set fish_function_path $fish_function_path[1] $fisher_path/functions $fish_function_path[2..-1] set fish_complete_path $fish_complete_path[1] $fisher_path/completions $fish_complete_path[2..-1] for file in $fisher_path/conf.d/*.fish builtin source $file ^ /dev/null end fzf + ghq/historyの連携 zshでは、どこかから拾ってきたfunctionをそのまま利用していたのですが、fishでも同じようにして探してきました。 ...

February 12, 2019 · derui

Angularのチュートリアルにngrxでstate管理を追加する

諸事情(主に会社の事情)で、AngularとState管理について評価する必要が出ました。ただ、今までそもそもAngularを触ったことがなかったため、Angular公式のTutorialをやることにしました。このTutorialが結構な分量なので、これにstate管理を追加すると丁度いいんでは?ということでやってみました。 <!–more–> Angular CLIのインストール まずはAngular CLIをインストールします。基本的にglobal installを推奨しているようですが、global installはめんどくさい時もあるので、今回はlocal installでなんとかならんかやってみます。 $ yarn add -D @angular/cli $ yarn ng new angular-tutorial --directory . --force $ yarn ng serve --open 一回CLIだけをaddしてから、無理やり上書きするというパワープレイでいけます。ここからは、Tutorialを普通に進めます。 Tutorialをやる(HTTP以外) Tutorialを進めていきます。集中してやれば、大体2〜3時間で終わるくらいのボリュームです。ただ、今回はstate managementをやるのが目的なので、HTTPが絡むような部分はstubにしておきます。 とりあえずTurorialが完了しただけの状態が以下のリポジトリです。masterブランチがその状態です。 https://github.com/derui/angular-tutorial-ngrx では、これにngrxを追加していってみましょう。 ngrxとは Angularを表す ng と、RxJSを表す rx がくっついているのでだいたい想像がつきますが、RxJSを前面に出したAngular用のstate management libraryです。公式ページでは次のように表現されています。 Store is RxJS powered state management for Angular applications, inspired by Redux. Store is a controlled state container designed to help write performant, consistent applications on top of Angular. ...

January 27, 2019 · derui

格子配列に適したかな入力を模索する

以前の記事で、薙刀配列を利用している、と書きましたが、色々思うところがあり、今は別の可能性を探っています。 <!–more–> 現在色々と提案されているカナ入力方式は、TRON配列を除くと、基本的に 一般的なJISキーボードに合わせて設計されています 。99%の人は、JISキーボードを利用しているであろうから、その課程は至極当然です。 しかし、Ergodoxを始めとする、通称 格子配列 とJISキーボードでは、押しやすいキーや指の可動範囲がかなり異なります。人差し指が担当する TYBN であったり、小指が担当する PQ は使い勝手が変わります。また、JISキーボードのようなRow-struggleなキーボードで押しやすいキー連接は、必ずしも格子配列で押しやすいとは限りません。 格子配列の特徴と個人の身体的特徴 格子配列には、次のような特徴があります。(個人的な感覚ですが) 列をまたいで指を移動するのが厳しい 同じ列内での移動はやりやすい また、これは私の身体的特徴ですが、 人差し指と小指がかなり短い 格子配列でT/Yに指を伸ばすのに若干気合が必要なくらい 手ごと移動すれば、指の不可は大分減りますが、今度は腕を持ち上げるという負荷がかかります P/Qは、手ごと移動しないと押せない という特徴があります。模索している配列では、これらをどう解決していくか?が肝になります。 シフトの設計 現在利用しているキーボードであるCrkbdには、そもそも42キーしかなく、親指以外の指に割り当たっているキーは36キーしか存在しません。このうち6キーはCtrlやShiftなので、事実上は30キーが物理的な限界です。 どのみちひらがなだけで50音あるので、必然的に何らかのシフト機構が必要になります。シフト機構にも色々ありますが、大別して次のようなものがあります。 前置きシフト JISかな、新JIS、親指シフト、月配列 同時シフト 蜂蜜小梅配列、新下駄配列、薙刀配列、飛鳥配列 他にも色々ありますが、要は シフトに順序性があるかどうか が大きな違いです。順序性がある場合、ロールオーバーが可能になりますが、ほぼ同時にキーを押下した場合、意図しない入力になる場合があります。順序性がない場合、ほぼ同時に押下しても問題ありませんが、その代わりに単打時の誤爆が起こりやすくなります。 また、どのキーをシフトとして利用するか?というのも重要です。 小指シフト JISかな 親指シフト NICOLA、蜂蜜小梅配列、薙刀配列、飛鳥配列 人差し指シフト 薙刀配列 中指シフト 月配列、新下駄配列 Crkbdに限って言うと、Layer切り替えがかなりの頻度で発生する上、SandS/Enterを親指に割り当てている都合上、これ以上負荷をかけるのはリスクがあります。実際、親指だけ痛くなったことがあるので。そうなると、弱い小指に負荷を与える小指シフトは論外として、人差し指/中指シフトが有力に思えます。月配列や新下駄配列を利用していても、あまり違和感は無かったので、個人的にも問題はありません。 清濁同置と清濁別置 新下駄配列や飛鳥配列では、清濁別置を選択することで、高効率を実現しています。しかしその分記憶負担が大きく、また運動記憶が確立するまでに時間がかかります。 蜂蜜小梅配列や薙刀配列では、濁音を入力する時に清音+シフトで入力するようにして、記憶負担を抑えて、連想記憶で思い出せるようにしています。新JISでは後置きで濁点を追加する方式です。 最終的には運動記憶に帰着するため、効率だけで言えば清濁別置の方で効率的なのは明らかです。ただ、滅多に利用しない濁音や半濁音も連想無しで覚えなければならないので、滅多に利用しないかなの入力時にはかなりスピードに影響することが想像できます。 行段系かどうか かな50音を、列=子音と行=母音に分解して、2打鍵で入力する方式です。けいならべ、かわせみ配列、Phoenix配列などが該当します。 行段系の利点としては次のような点が挙げられます。 記憶負担がちいさい 子音と母音だけ覚えればいい 左右交互打鍵にしやすい 大抵は子音と母音をそれぞれの手に配置するため、基本的左右交互打鍵になるケースが多いようです 対して、次のような欠点があります。 使用頻度による配置が難しい 規則的になる半面、各指の運動特性に準じた配置とかはかなり難しい つまり、効率をある程度犠牲にして、連想記憶などで思い出せるようにしたものです。基本的に一文字の入力に2打鍵かかるため、何らかの拡張を施さないと、ローマ字入力とさほど効率が変わりません。 実際に利用してみたところ、確かに記憶はすぐ出来ますが、やはり運動記憶にするまでに時間がかかります。また、どうしても2打鍵必要になるケースが多い、というのが結構気になります。 拗音拡張 最近の配列には、大抵拗音拡張が取り入れられています。拗音拡張を取り入れることで、やゆよの小文字を単独で入力する必要がなくなり、一動作で入力出来る文字数が増え、結果として効率が向上します。 ただ、拡張を取り入れることで、記憶負担の増加もまた避けられないため、各配列で覚えやすくするための工夫を取り入れています。 蜂蜜小梅配列 蜂蜜マトリックスという仕組みを起点として構築されている 新下駄配列 専用のシフトを割り当て、拗音拡張だけは規則的にしている かわせみ配列 子音+やゆよの入力で規則的な配置 薙刀配列 拗音の最初の文字+後ろに続く小文字で統一 記憶負担の増加にどう対処するか?というのが肝のようですが、利用できると効率が向上するので、出来れば使えるようにしたいところです。 ...

January 24, 2019 · derui

2018年のキーボードを振り返る

この記事は、OpenStream Advent Calendar 2018 の2日目の記事です。昨日は miyatay さんの CognitoxAlexaアカウントリンクが大変だった話 でした。 さて、本当はOCamlの話を書きたいところでしたが、ぶっちゃけネタがなかったので、今年いろいろ進展があったキーボードや日本語入力まわりについて書こうかと思います。 <!–more–> プログラマーとして一番良く触るものは何か?と聞かれた時、大半の方はまず キーボード と答えると思います。もしかしたらマウスのほうが触っている時間が長い、という方もいるかもしれませんが。一日の大半をともに過ごすキーボードは、PCとのインターフェースでもあります。そんなキーボードについてちゃんと考えることは重要ではないかと思うんです。 道具にこだわるのは2流、とか言う意見 私も割といろいろキーボードを変えたり買ったりしていました。今まで買ったキーボードを古い順に時系列で並べると、こんな感じになりました。 HappyHackingKeyboard Pro Realforce Kinesis Ergodox EZ * 2 Iris Crkbd Ergodox EZが×2になっているのは、家用と仕事用に買ったからです。こう見ると結構買ってますね。 最近はあまり聞かなくなりましたが、少し前は、常駐先とかで配られるキーボード以外を使っていると、 なんでキーボードなんかにお金かけるの? と言われるときもありました。これは、道具に拘泥するな、という意味で言っていたと思います。 直近で書いた記事にも書きましたが、最近はつぎのように考えています。 仮にもプロフェッショナルなのであれば、自分が一番良く使う道具にお金をなんでかけないの?と逆に聞きたいです。スポーツでも職人でも、自分が使う道具は、自分の性能を100%発揮できるように調整したり変えたりするはずです。 弘法筆を選ばず かもしれませんが、弘法が自分で選んだ筆を使ったほうがいいものを書ける確率が上がるのは自明でしょう。 自作キーボードが増えてきた 今年は特に、日本での自作キーボード熱が盛り上がった年だと思います(個人の観測範囲では)。その理由としては、よく言われるように次のような要因が上げられると思います。 QMK Firmwareが事実上のデファクト化、高機能化 個人がPCBなどの設計をある程度気軽に行える環境が整ってきた 3Dプリンターやレーザーカッターを利用するハードルが下がった 個人販売をサポートするプラットフォームがある程度充実してきた 今年私が作ったIris/Crkbdは、どちらも開発者の方が自分のEnd gameを目指して試行錯誤された結果出来たものです。無論、あくまでその開発者の人にとってのEnd gameを目指したものである以上、万人受けはしません。 ですが、各種設計がオープンソースとなっているので、元のキーボードに触発された個人がまた新しいキーボードを派生させていく様はみていて面白いです。 2018年のキーボードと配列 最近は左右分離+少キー構成がマイブームです。ErgodoxからIris/Crkbdに変えたのも、結局利用しづらいキーが多く、有効利用できなかったというのがあります。 あるキーボードを特徴づけるのは、キーの物理的な配列とキースイッチです。かつ、QMK Firmwareなどを利用しているキーボードでは、キーの論理配列=キーマップの自由度が、市販のキーボードとは比較出来ないほど高いです。 キーマップによっては、元々のキーボードとは全く違うものになる場合すらあります。 元々キーの論理配列と言えば、QWERTY配列を代表として、QWERTY配列から派生したColemak/Workmanや、Dvorak配列など色々ありますが、あくまでアルファベット部分の配列を指していました。それらも、キーボード自体がそういう配列になっているというわけではなく、何らかのツールで実現されていました。 そういった配列変更をキーボード単体で完結させることが出来るようになり、かつ他にも様々な機能を付加することも出来るようになりました。2018年の12月現在、私が利用しているCrkbdの配列はこんな感じになっています。 const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = { [_QWERTY] = LAYOUT_kc( \ //,-----------------------------------------. ,-----------------------------------------. TAB, Q, W, E, R, T, Y, U, I, O, P, BSPC,\ //|------+------+------+------+------+------| |------+------+------+------+------+------| LCTL, A, S, D, GUIF, G, H, GUIJ, K, L, SCLN, QUOT,\ //|------+------+------+------+------+------| |------+------+------+------+------+------| LSFT, Z, X, C, V, B, N, M, COMM, DOT, SLSH, RSFT,\ //|------+------+------+------+------+------+------| |------+------+------+------+------+------+------| M_EISU,LOWER,SFT_SPC, SFT_ENT, RAISE,M_KANA\ //`--------------------' `--------------------' ), [_LOWER] = LAYOUT_kc( \ //,-----------------------------------------. ,-----------------------------------------. ESC, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, DEL,\ //|------+------+------+------+------+------| |------+------+------+------+------+------| CTLTB, LCTL, LSFT, LALT, LGUI, XXXXX, XXXXX, RGUI, RALT, RSFT, RCTL, F11,\ //|------+------+------+------+------+------| |------+------+------+------+------+------| LSFT, F1, F2, F3, F4, F5, F6, F7, F8, F9, F10, F12,\ //|------+------+------+------+------+------+------| |------+------+------+------+------+------+------| M_EISU,LOWER, SFT_SPC, SFT_ENT, RAISE,M_KANA \ //`--------------------' `--------------------' ), [_RAISE] = LAYOUT_kc( \ //,-----------------------------------------. ,-----------------------------------------. ESC, EXLM, AT, HASH, DLR, PERC, CIRC, AMPR, ASTR, LPRN, RPRN, BSPC,\ //|------+------+------+------+------+------| |------+------+------+------+------+------| CTLTB, XXXXX, XXXXX, XXXXX, XXXXX, XXXXX, MINS, EQL, LCBR, RCBR, PIPE, GRV,\ //|------+------+------+------+------+------| |------+------+------+------+------+------| LSFT, XXXXX, XXXXX, XXXXX, XXXXX, XXXXX, UNDS, PLUS, LBRC, RBRC, BSLS, TILD,\ //|------+------+------+------+------+------+------| |------+------+------+------+------+------+------| M_EISU,LOWER,SFT_SPC, SFT_ENT, RAISE,M_KANA \ //`--------------------' `--------------------' ), [_NAGINATA] = LAYOUT_kc( \ //,-----------------------------------------. ,-----------------------------------------. TAB, Q, W, E, R, T, Y, U, I, O, P, JA_AT,\ //|------+------+------+------+------+------| |------+------+------+------+------+------| LCTL, A, S, D, F, G, H, J, K, L, SCLN,JA_CLN,\ //|------+------+------+------+------+------| |------+------+------+------+------+------| LSFT, Z, X, C, V, B, N, M, COMM, DOT, SLSH, RSFT,\ //|------+------+------+------+------+------+------| |------+------+------+------+------+------+------| M_EISU,LOWER, NSS, NSE, RAISE,M_KANA \ //`--------------------' `--------------------' ), [_ADJUST] = LAYOUT_kc( \ //,-----------------------------------------. ,-----------------------------------------. RST, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, DEL,\ //|------+------+------+------+------+------| |------+------+------+------+------+------| XXXXX, LCTL, LSFT, LALT, LGUI, XXXXX, LEFT, DOWN, UP, RGHT, XXXXX, F11,\ //|------+------+------+------+------+------| |------+------+------+------+------+------| LSFT, F1, F2, F3, F4, F5, F6, F7, F8, F9, F10, F12,\ //|------+------+------+------+------+------+------| |------+------+------+------+------+------+------| M_EISU, LOWER,SFT_SPC, SFT_ENT,RAISE, M_KANA \ //`--------------------' `--------------------' ) }; Crkbd/Irisなどで利用されている QMK Firmware では、=layer= という概念を追加することで、物理的に42キーしか無いキーボードでも、 ...

December 2, 2018 · derui

crkbdを作った

前々から作ってみたかった crkbd が、Corne Cherryとしてキットが発売されたので、速攻で入手して作ってみました。 なお、私が作ったのは マットブラック です。ボトムプレートはアクリルです。 <!–more–> 以前のcrkbdは、以前作ったirisと同じダイオード式でしたが、Corne Cherryは 表面実装ダイオード を利用するようになっています。今回はこいつとPCBソケットが課題となりました。 色々購入 表面実装ダイオードを利用するというのはもうわかっていたので、逆作用ピンセットを購入しました。 それ以外は、 遊佐工房 さんから購入しました。今回のキースイッチは Kailh Speedの銀軸にしました。キーキャップは、irisを作った時に余ったものと、Ergodox EZから引っ剥がして使いました。 今回、Corne Cherryのキットと遊佐工房で注文したものが、どちらもクリックポストで届きました。そのおかげで、どちらも受け取りを心配せずともよく、非常に助かりました。ポストに入れるだけって手軽ですね。 他にはTRRSケーブルを購入しました。工具類は前回買ったものだけで足りました。 事前準備 Pro Microとかのほうが先に届いたので、前回同様にモゲ対策をします。撮ったはずなんですが画像が無かった・・・。大体irisのやつと見た目は一緒です。 組み立て キットの中はこんな感じです。前述の通りアクリルなので、ボトムプレートにはシールが貼ってあります。 そしてこっちが噂の表面実装ダイオードです。ガチで米粒よりも小さいので、これはピンセットが必須とされるのがわかります。 組み立て自体は、公式のビルドログがあるのであまり迷いませんでした。写真は取り忘れましたが、道中色々ギリギリな部分がありました。 ハンダが上手く盛れない やりすぎて隣のパッドにまでいったり、妙に少なくて上手くくっつかず、と・・・ やってみた感じからすると、ダイオードは過大にならなければ、あまり盛る量に神経質になる必要はなさそうでした PCBソケット難しい 付けるタイミング的に、Pro Microとかを付けた後になるんですが、そうなるとPCBが並行にならないので、ピンセットとかで押さえるのが超難易度でした ホルダー的なものがあると楽そうでしたなくてもとりあえず行けましたが。 後、一番ギリギリなのは半田の量でした。残り20cmくらいでなんとかなったのは奇跡的。 途中、Pro Microにファームを書き込んだりなんだりして、とりあえずスイッチまで入れたのがこれです。 実は、ボトムプレートの向きを勘違いしていて、裏を見るとCorneのマークが見えないという(爆笑)。基本的にずっと置きっぱなしなので、まぁとりあえずは置いておきます・・・。 使っていたIrisと比較すると、やはり一行少ないのと、iris比較で0.5cmほど薄いので、非常にコンパクトに見えます。後、ステンレスではないぶん軽いです。ただ、その分強度が落ちてるはずなので、満員電車での持ち運びがちょっと怖いです。 キーマップは? デフォルトから改変していますが、とりあえず日本語入力とかは移植しました。フォントの分最初から増えているので、サイズ的にはかなりギリギリです。 後、更にキーが少なくなったのもあって、日本語入力が恐ろしくギリギリです。親指同時打鍵をやめればおそらく問題ない範囲だとは思いますが・・・。ただ、今更ローマ字入力になるのもなんか癪に障るので、なんとかならないか考えてみようかと思います。 地味に、タイル型WMを利用していて、数字キーを結構な頻度で利用していることに気づきました。環境が変わると気づきが有りますね。 結び iris、crkbdと来たので、恐らくしばらくはキーマップの整備が主な作業になるとおもいます。キーマップについてはまたブログにします。 よく、 弘法筆を選ばず だから何でもいけるはず、という意見があります。一応私も職業上はそういったプロではあるので、別段ノートPCのキーボードでも作業は出来ます。ただ、プロであるのであれば、自分の性能を引き出せる道具を用意するのもまた当然ではないかと思います。プロのスポーツ選手で、そこらへんで売ってるようなものを利用していないのと同じ理屈です。 キーボードは、人によって好みが異なるので、ぜひ市販されてるものも含め、自分にぴったりなものを探してみてください。

December 1, 2018 · derui

OCamlでClean Architectureもどき

このところOCamlでアプリケーションをほそぼそと作っているのですが、その過程でClean Architectureっぽいものを採用してみました。 <!–more–> 作っているアプリケーション自体は、完全に趣味の領域のものなのでまだ公開していません。ただ、OCamlであってもなんであっても、ある程度の規模になったらなんらかの方法論は必要かな、と思い始めました。 packageそのものがいっぱいある moduleもいっぱいある どことどこが関連してるかよくわからなくなってくる これはもしかしたらmodule/packageの分割方法自体が問題か・・・? ある程度Clean Architectureっぽいことも出来るようになってきたので、自分の知識を整理する上でも書いてみます。 Clean Architectureとは? ググってもらうのが一番早いのですが、それは流石に不親切すぎるので・・・。 Clean Architectureは、 http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html が原典とされ、 Robert C. Martin によって提唱されたアーキテクチャです。 Onion Architecture/Hexagonal Architectureなど、過去のアーキテクチャも参考にしながら作成されたものになり、それらの特徴も一部受け継いでいます。 Clean Architectureは、以下のような制約を導入します。 ある層は、それより外側の層に依存してはならない ある層は、それより内側の層にのみ依存する これがClean Architectureにおける唯一の制約です。層としては、基本形として以下を提唱しています。 Entities いわゆるドメインモデルです Use Cases アプリケーションロジックです。Domain Logicよりは特殊化されていますが、サブシステムとかがないアプリケーションだと、大体がここにロジックがある感じになるそうです Interface Adapter/Gateway/Presenter UIやData Storeなど、外部との連携を行うための層です。 APIをGatewayとして実装する、UIの情報をPresenterから返す、とかいろいろあります Frameworks and Drivers Framework specificな処理とかです APIをFrameworkの機能を利用して作成する、とかであればここになります ただ、これ以外にも 層を 追加することは可能です。唯一の制約である、層の間にある依存方向を守る限り、層の増減は自由です。 OCamlでの課題(自分的に) OCamlである程度の規模のアプリケーションを作成する場合、恐らくある程度の単位でパッケージを作成する場合が多いと思います。最近は dune を利用すると思いますが、使わない場合であったり、一パッケージに全ファイルを置くのは色々問題があります。 module名がめっちゃ長くなる 1ファイル1moduleとかやると、ファイル名もめちゃくちゃ長いですが、そのmoduleを利用するときにすごく面倒になります 一般的なモジュール名がかぶる 特に被るのが Types とかの名前です 1ファイルに複数のmoduleを書くと見通しが悪い 1データ型1module主義とかやると、単純にファイルの中身がかなり長くなります OCamlerはあまりその辺は恐れないようですが。 この辺はfoldとかをうまく使えばいいのかもしれません 特に、頻繁に使うmodule名が長いと色々だれますし、毎回aliasを書くのもしんどいです。以前よりもmoduleを明示しなければならないケースは少なくなりましたが、一級moduleを利用しているとやっぱりきついです。 パッケージを分ける上での基準も厄介です。大抵は機能とか役割別だと思いますが、結構分けづらい感じになっていったりで・・・。 そこで、パッケージを分ける基準として Clean Architecture を使ってみました。 OCaml on Clean Architecture とはいっても、基本的には各層ごとになるようにパッケージを分割するだけです。そうすると、dependenciesの方向制御も簡単になります。私は、 domain, usecase, gateway, binary と分けています。こうすると、OCamlの制約とduneの機能で、以下のような利点を自動的に得られます。 ...

November 4, 2018 · derui

Spring Boot + Gradle + AssertJでAssertJ generatorを実行するTips

最近別のプロジェクトに0.5で参加することになりました。人生初の0.5です。おかげで?ガッツリ開発するケースが少なくなりそうで、それはそれで・・・と思う日々です。 それはともあれ、それぞれのプロジェクトでSpring Bootを触ることになりました。これまた人生初です。そんなときになかなか解決しなかったことについて書きます。 <!–more–> 今回やりたいことは以下のような感じです。他にもいろいろありますが、今回は絞っています。 Spring Boot 2系列 というかSprint Initializrで作ったプロジェクト テストのAssertionライブラリとして AssertJ を使いたい Custom Assertionを Assertion Generator でやりたい こんなことをやりたかったんです。 最初のbuild.gradle buildscript { ext { springBootVersion = '2.0.6.RELEASE' } repositories { mavenCentral() } dependencies { classpath("org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}") } } apply plugin: 'java' apply plugin: 'eclipse' apply plugin: 'org.springframework.boot' apply plugin: 'io.spring.dependency-management' group = 'com.example' version = '0.0.1-SNAPSHOT' sourceCompatibility = 1.10 ext { assertjGeneratorVersion = '2.0.0' } repositories { mavenCentral() } configurations { assertj } dependencies { implementation('org.springframework.boot:spring-boot-starter-web') testImplementation('org.springframework.boot:spring-boot-starter-test') assertj "org.assertj:assertj-assertions-generator:${assertjGeneratorVersion}" assertj project } // configuration and tasks for assertj sourceSets { test { java { srcDir 'src/test/java' srcDir 'src-gen/test/java' } } } def assertjOutput = file('src-gen/test/java') task assertjClean(type: Delete) { delete assertjOutput } task assertjGen(dependsOn: assertjClean, type: JavaExec) { doFirst { if (!assertjOutput.exists()) { logger.info("Creating `$assertjOutput` directory") if (!assertjOutput.mkdirs()) { throw new InvalidUserDataException("Unable to create `$assertjOutput` directory") } } } main 'org.assertj.assertions.generator.cli.AssertionGeneratorLauncher' classpath = files(configurations.assertj) workingDir = assertjOutput args = ['foo.bar'] } compileTestJava.dependsOn(assertjGen) args にある foo.bar はパッケージ名と思ってもらえれば。 ...

October 23, 2018 · derui