みつのーと

(*・ω・)ノシ

LEOPOLD FC660Mの軸をピンク軸に換装した

お出かけ用として使ってるLEOPOLD FC660M(赤軸)のスイッチを、静音化目的でピンク軸に換装した。

今までは静電容量方式のFC660Cを2年ほど使っていたんだけど、個人的にCherry軸の方が打鍵感が好みなので、FC660Mを知った時に買い直していた。 ただ、赤軸になったことで打鍵感は改善された反面、打鍵音も大きくなってしまい、外出先(オフィスやコワーキングスペースとか)で使うにはちょっと…という感じになってしまった。

そんな折に、一緒に仕事してる方からピンク軸のことを教えてもらった。 ピンク軸は、動作点は赤軸とほぼ同じなまま、静音化されたモデルらしい。

cherryのサイトを見ると、黒軸の静音モデルもあるっぽい。

ピンク軸を手に入れる

少し探してみたけども、どうやら個人向けにピンク軸単体を売ってるとこはまだあんまりないっぽい。 あっても$4/個とか、やたら強気な価格設定だったりして厳しい(他の軸は大体$1/個な雰囲気)。

一応 €0,62/個 で売ってるとこがあったので買おうと思ったんだけど、送料だか関税だかで +€27 くらい掛かってしまい、66キー分買おうとすると8,000円を超えてしまうので、躊躇してしまった。

f:id:mitsu-ksgr:20171106045508p:plain
Shipping Costが厳しい

https://www.reichelt.com/pl/en/Keyboard-Accessories/CHERRY-MX3A-L1NN/3/index.html?ACTION=3&GROUPID=8099&ARTICLE=202572

どうするかな〜って思ってたとこに、メルカリでMajestouch 2 HAKUAのUSフルキーボードを8,000円で発見。

  • HAKUAを普通に買えば13,000円以上する
  • ピンク軸104個で8,000円と考えるとかなり安い(約77円/個)
  • 国内取引だからすぐ届く

ということで、最終的にメルカリで買うことにした。

HAKUAからピンク軸を取り出す

キーボードが届いたので、早速軸を取り外していく(早速といいつつ、予定が立て込んでて2週間ほど放置してた)。

f:id:mitsu-ksgr:20171106051301j:plain
フルキーボード、横に長い

f:id:mitsu-ksgr:20171106051950j:plain
キートップを全部外すと、ピンク色の可愛い軸が見えてくる。

ガワも全部外すと基板が見える。

f:id:mitsu-ksgr:20171106052825j:plain

黒ポッチが軸のケツなので、その付近のスイッチの足2本の半田を取っていく。

f:id:mitsu-ksgr:20171106053916j:plain

半田が取れれば、スイッチ側から取り外せる。

f:id:mitsu-ksgr:20171106054941j:plain

f:id:mitsu-ksgr:20171106055306j:plain
スイッチ上下の爪を押しつつ引っこ抜く感じ

この調子で全部のスイッチを外していく。 半田下手なので、全部外すのに1.5mの半田取り線を2リール半も消費した。

f:id:mitsu-ksgr:20171106060131j:plain
収穫

実はスイッチを外す途中で2個ほど足を折ってしまい不安になったので、この時点で一応全部導通チェックしておいた。

f:id:mitsu-ksgr:20171106060135j:plain
両足繋いでスイッチ押してピー鳴れば問題ない。

FC660Mのスイッチを交換してく

基本的にはhakuaと同じ手順でスイッチを外して、ピンク軸を実装していくだけ。

赤軸を外す

FC660Mも、HAKUAと同じように、ガワを外してスイッチを全部はずしていく。 こっちは66キーなので、HAKUAよりは楽だけど、それでも半田取り線を1リール半消費した。

LED付きのキーが2つあるので、そのキーはLEDも一緒に半田取りする必要がある。 LEDは引っこ抜けるので、ピンク軸でも同じように使えるよう取っておく。

f:id:mitsu-ksgr:20171106061354j:plain

ピンク軸を半田付けする

取り外したときと逆順で実装していけばいい。 LED付きだった部分は、ピンク軸の方にLEDをはめてから(LEDの向きに注意)、LED分も忘れずに半田付けする。

全部のスイッチを半田付けすれば完了!

f:id:mitsu-ksgr:20171106063706j:plain
うしろのスイッチは二軍落ちした赤軸たち


ひたすら半田取って半田付けて、みたいな感じなので、作業自体は簡単なんだけど、めっちゃ時間がかかった。 僕は不器用なので、全部終わるのに12時間くらいかかった。

ちなみに、最終的に半田取り線は4リール消費した。 はんだ吸取器苦手マンなので基本的に半田取り線をメインで使ったんだけど、失敗だったかも。

音に関しては、赤軸はもちろん、静電容量方式のFC660Cよりも静かになったので、静音化もちゃんと達成できた。 (最初は比較の動画でも撮ろうかと思ったんだけど、作業に疲れて面倒になってしまった。youtubeでピンク軸の動画さがせば音の雰囲気は分かると思う)

最後に、 wasdkeyboards.com で買っておいたキートップを付けて楽しい感じにした。

f:id:mitsu-ksgr:20171106065045j:plain
今気づいたけど、白系だと使ってく内に手垢が目立ちそう

ピンク軸がもっと流行れば、軸単体で手に入りやすくなるのかな?もっと手軽に購入出来ると嬉しい。

そういえば手元に赤軸x66、ピンク軸x36(と、HAKUAの基板)が残ってしまったけど、使い道が無いなぁ。

terminalでちょっとした計算をシュッとやりたい

というときに、今まではrepl使ったりアレコレしてたけど、

  • pythonのreplはexit()するときに()付けるのがめんどい
  • irbは起動がなんかちょっと遅くてめんどい
  • bcコマンド単体だとechoするのがめんどい

というのがあって、めんどかった。

ので、

というヤツを.zshrcなり.bashrcに書いておくと、

% calc "1599 * 112.48"
179855.52

とやれて便利になった。

bcコマンドなので、必要であれば変数やfor文とかも使えて便利!*1

% calc "
dquote> a = 123.45
dquote> for (i = 1; i <= 10; ++i) {
dquote>   a * i
dquote> }"
123.45
246.90
370.35
493.80
617.25
740.70
864.15
987.60
1111.05
1234.50

90日以上ブログ更新してなかったらしいので、書いた。

*1:今のところ必要になったことはない

OSXのプレビューからPDFを中綴じ印刷したくてスクリプト書いた

OSXのプレビューは、そのままだとPDFを中綴じ印刷出来ない(プリンター側が機能を提供していれば出来るらしい)。

中綴じ印刷のためだけに、別途ソフトを入れるのもアレなので、PDFをなんとかすることにした。

OSXのプレビューは、[印刷ダイアログ] > [レイアウト]から、

  • ページ数/枚(Pages per sheet): 2
  • レイアウト方向(Layout Direction): 左上 –> 右下
  • 両面(Two-Sided): 短辺とじ(Short-edged binding)

とすると、1枚あたり両面で4ページ印刷出来る。 ので、この設定で中綴じ印刷が出来るように、スクリプトでPDFのページを入れ替える。

スクリプトgithubに置いてある。

pypdf2を使っているので、インストールしてない場合は入れておく必要がある。

% pip install pypdf2


単一のスクリプトなので、スクリプトだけ落としてくればいい。

% curl https://raw.githubusercontent.com/mitsu-ksgr/pdf_saddle_stitcher_py/master/saddle_stitcher.py -O
% chmod 744 saddle_stitcher.py
% ./saddle_stitcher.py sample.pdf

とすると、中綴じ向けにページが入れ替えられたsample_saddlestich.pdfというファイルが生成される。 あとはこれをプレビューで開き、先の設定で印刷すればいい。

参考にさせて頂いたサイト:


PDF触るの初めてだったんだけど、PyPDF2がよく出来てて簡単にできた。

シンプルなAPIで使いやすくて、最初に書捨てたスクリプトは10分もかからず書けた。 (ページ数によっておかしくなる問題があったので、githubに上げるついでに修正・リファクタした)

python久しぶり過ぎてコロン付け忘れまくるなどあったけど、end書かなくて済むので良い

ローカルでdocker-composeを操作するためのGUIツール書いた

ローカルでdocker-composeを操作するための簡単なGUIツールをElectronを使って書いた。 非エンジニアの人でも気軽に開発環境をローカルで動かせるように、といった気持ちで作った。

「エンジニアが作成したdocker-composeを使って、非エンジニアの人がローカルで動作確認する」といった用途をイメージしてる。

GitHubにソースと実行ファイル(zip)を置いてある。

mitsu-ksgr/swimmy: Swimmy is simply GUI client of docker-compose built on Electron. Release ver 0.2.0 · mitsu-ksgr/swimmy

名前はスイミーにした。

で、最初に思いついたのがスイミーで、あんまり考えずそれに決めた。彼は確か群れをまとめてうんぬんしてたし、割りとそれっぽいという思いはあった。 ただ魚介に詳しくないのでスイミーが何の魚か知らないため、いらすとやさんでそれっぽい魚の画像を探してアイコンにさせて頂いた。

で、これ書きながら気付いたんだけど、体が赤いのは群れのほうでスイミーは黒だった。スイミー目だもんね。 アイコンは赤い魚にしちゃったんだけど、修正するのも面倒なので赤のままにしてある。

使い方

基本的に、開発環境のdocker-composeを操作するイメージで作っているので、scaleやconfigなんかを使うケースは考慮してない。

使い方はREADMEのUsageに書いていこうと思う。

mitsu-ksgr/swimmy: Swimmy is simply GUI client of docker-compose built on Electron.

現時点では、

  1. プロジェクトのdocker-compose.ymlを選ぶ
  2. 再生ボタンを押すとdocker-compose up
    • stop後にexitした状態の時はdocker-compose start
  3. 一時停止ボタンでdocker-compose pause
    • リピートボタンでdocker-compose unpause
  4. 更新ボタンでdocker-compose restart
  5. ゴミ箱ボタンでdocker-compose down

といった感じ。

ボタンだけだと操作方法が微妙に分かりづらく、センスの無さが滲み出てきて辛い。ので誰か助けて欲しい。 (HTML/CSS書くのだるくて、最低限のことしかやってない)

これから追加したい機能

  • migrationとかの処理をするのにdocker execで処理を実行させる何らかの仕組みを用意したい
  • ログをもうちょい見やすくしたい(現状codeタグでくくってるだけ)
  • Portsの項目からブラウザを開けるようにしたい

普通に使えるくらい機能が揃ったらver1.0.0にしたいなと思ってる。

なんで作ったか

上にも書いたけど、非エンジニアの人でも気軽に開発環境をローカルで動かせるような環境を作りたかった。

Webサービス案件に携わるようになって、デザイナーやディレクターが「ローカルの開発環境の構築が上手くいかないから、確認しながら作業出来ない!」って困ってるところを何度か目にすることがあった(デザイナーはデザインの当て込み、ディレクターは文言変更や要素の配置を試したりで、ローカルで動作させたい需要は少なくないように思うけど、他の現場だとどうなんだろ?)。

この問題そのものは、開発環境をDockerで構築することである程度対応出来ると思ってる。 ただ、コンテナ1つのプロジェクトはそうそうないのでdocker-composeを使う事になると思うんだけど、現状Kitematicがdocker-composeに対応してない(いつか対応するのかな)。

docker-composeは簡単なコマンドで操作出来るんだけども、幾つかのコマンドを覚えてターミナルを1つ立ち上げるよりも、複数のウィンドウを開いてGUIで操作するほうが性に合うってタイプの人たちも一定数いるので、そういう人たちの選択肢の一つになれば嬉しい。

取り敢えず今携わってるプロジェクトはdockerを使って開発してるので、機会があれば使ってみてもらおうと思ってる。

Electron

Electronやnode.jsにあまり詳しくなくて、moduleの書き方とかぎこちない感じがあるので、もうちょっと色々書いたりなんだりして感覚を掴みたい。 とはいえ基本的にhtmlとjs書くだけなので、"取り敢えず動かす"ってとこまですぐにいけるのは、書いてて気持ちが軽やかで良い。

あと、マルチプラットフォーム向けにパッケージングするときはelectron-userland/electron-packagerを使うとすごく手軽で便利だった。 最終的にはCIでパッケージングしてReleaseする感じに持っていきたいので、おいおいやっていきたい。


作ってる手前自分でもなるべく使うようにしてるけど、やっぱりコマンドそのまま打ったほうが楽ちんちんですね

Rails4のgenerate controllerでviewやassetsを生成しないオプション

rails g controllerしたときに「Asssets周りは要らないんだよなー」ってケースが割りとあった。 -hでヘルプみてもピンと来なかったんだけど、ググッてみたらちゃんと先人の方々が書いてくれていた。

各オプションとその結果の備忘録。

オプション無し

% rails generate controller piyo
Running via Spring preloader in process 3152
      create  app/controllers/piyo_controller.rb
      invoke  erb
       exist    app/views/piyo
      invoke  test_unit
      create    test/controllers/piyo_controller_test.rb
      invoke  helper
      create    app/helpers/piyo_helper.rb
      invoke    test_unit
      invoke  assets
      invoke    coffee
      create      app/assets/javascripts/piyo.coffee
      invoke    scss
      create      app/assets/stylesheets/piyo.scss

controllerだけでいいとき: --no-assets --no-helper --skip-template-engine

% rails generate controller piyo --no-assets --no-helper --skip-template-engine
Running via Spring preloader in process 5517
      create  app/controllers/piyo_controller.rb
      invoke  test_unit
      create    test/controllers/piyo_controller_test.rb

asset要らないとき: --no-assets

% rails generate controller piyo --no-assets
Running via Spring preloader in process 5187
      create  app/controllers/piyo_controller.rb
      invoke  erb
      create    app/views/piyo
      invoke  test_unit
      create    test/controllers/piyo_controller_test.rb
      invoke  helper
      create    app/helpers/piyo_helper.rb
      invoke    test_unit

helper要らないとき: --no-helper

% rails generate controller piyo --no-helper
Running via Spring preloader in process 5287
      create  app/controllers/piyo_controller.rb
      invoke  erb
      create    app/views/piyo
      invoke  test_unit
      create    test/controllers/piyo_controller_test.rb
      invoke  assets
      invoke    coffee
      create      app/assets/javascripts/piyo.coffee
      invoke    scss
      create      app/assets/stylesheets/piyo.scss

view要らないとき: --skip-template-engine

% rails generate controller piyo --skip-template-engine
Running via Spring preloader in process 5425
      create  app/controllers/piyo_controller.rb
      invoke  test_unit
      create    test/controllers/piyo_controller_test.rb
      invoke  helper
      create    app/helpers/piyo_helper.rb
      invoke    test_unit
      invoke  assets
      invoke    coffee
      create      app/assets/javascripts/piyo.coffee
      invoke    scss
      create      app/assets/stylesheets/piyo.scss

テストから逃げたいとき: --no-test-framework

% rails g controller piyo --no-test-framework
Running via Spring preloader in process 5795
      create  app/controllers/piyo_controller.rb
      invoke  erb
      create    app/views/piyo
      invoke  helper
      create    app/helpers/piyo_helper.rb
      invoke  assets
      invoke    coffee
      create      app/assets/javascripts/piyo.coffee
      invoke    scss
      create      app/assets/stylesheets/piyo.scss

Rails便利ですね、レールに沿って進むのは意外と難しいですが。

SublimeText3用のかな/カナ変換するプラグイン書いた

たまたま平仮名と片仮名を色々とごにょごにょする必要があったのと、Sublimeをここ数年ずっと使ってる割にプラグインを一つも書いたことないなーっていうのがあったので、今更ながらプラグインを書いてみた。

KanaKana

かな/カナの変換するのでKanaKanaという名前にした。 かな/カナ変換に作業効率を落としてる稀有な方がいれば、パッケージコントロールを開いてKanaKanaと入力するとインストールできる。

プラグインのソースはここにある。

プラグインの作成

SublimeTextのプラグインは、手軽に作り始める事ができる仕組みが整っているので、取っ掛かりやすかった。 以下の記事を参考にさせて頂きました。

あとは公式のドキュメント見て使えそうな機能探す感じで作っていった。

プラグイン自体は平仮名と片仮名を変換するだけなので、作ろうと思い立って調べ始めてから大体完成ってところまで、1時間も掛からないくらいだった。 それぐらいお手軽だった。

ただ言語がPythonなので、(AtomやVSCodeのプラグインがJSで書けるのを考えると)そこはちょっと人選ぶのかもなーという感じがした。 Pythonに慣れてれば癖がなくてとっても良い感じ。

注意点としては、ST2のプラグインはpython2系で書く必要があるので、Sublime Textの2と3に対応したい!ってなると、Pythonのソースも2と3に対応して書かなきゃならないので、色々厳しそう。 今回は面倒だし、そもそもST2なんてもう使ってないので、ST3のみの対応にした。

プラグインの配布

SublimeTextのプラグインは「Command PaletteからPackage Controlを使ってインストール」という手順が主流だと思う。 作った時は配布まで考えて無かったんだけど、せっかくだし配布したいなーと思ってきたので、配布までやってみた。

Package Cntrolのサイトのドキュメントの、パッケージについて書かれてるページを参考に作業した。

GitHubを使うことで、配布もお手軽に出来た。

ざっくり手順を並べるとこんな感じになる。

  1. 既に似たようなのが無いか検索して確認
  2. プラグインのパッケージ名に気をつけてプラグインを作成
  3. GitHubに公開する
  4. 最新バージョンのコミットに、SemVerに則ったバージョン番号のタグ付けをする
  5. Package Control Channelをフォークする
  6. repositoryディレクトリに、0-9.json[a-z].jsonがあるので、自分の作成したプラグインの先頭文字に対応するjsonに、パッケージ情報を追加する
  7. SublimeTextのPackageControlからChannelRepositoryToolsをインストールする
  8. コマンドパレットからChannelRepositoryTools: Test Default Channel commandを実行し、テストにパスすることを確認する
  9. 変更をコミットしプルリクを投げる(プルリクは投げっぱなしで大丈夫っぽい。僕はDescriptionもタグ付けもしなかった)
  10. 問題が無ければマージされ、公開される

注意点もいくつか(全部先のページに書いてあることだけど)。

  • パッケージ名には"sublime"っていうワードは使えない
  • リポジトリ.pycファイルは含めない
  • パッケージ情報にversion,url,dateのサブフィールドを含めない

ちなみにパッケージ情報はこんな感じで追記した。

{
    "name": "KanaKana",
    "details": "https://github.com/mitsu-ksgr/KanaKana",
    "labels": ["japanese", "text manipulation"],
    "releases": [
        {
            "sublime_text": ">=3000",
            "tags": true
        }
    ]
}

ラベルは他のプラグインを参考にして適当に決めた。

プルリクを送ってからマージされるまで、6時間くらいしか掛からなかった。結構頻繁にチェックしてるみたい。


ポストする時気付いたけど、前回ブログ書いたのが丁度1年前だった。 「これブログに書こうかな」なんて思う事はよくあるんだけど、生来の筆不精がたたってか、結局今日まで何も更新してなかったみたい。

最近は色々追い詰められてて、今回のプラグインも現実逃避の一環として書いてる節が多少あるので、次は余裕のある事してブログ書きたい。

Goの関数オブジェクトで再帰呼び出しする

型宣言付きで関数オブジェクトの変数を前方宣言しておけば再帰呼び出しが出来る

package main

import "fmt"

func main() {
    var factorial func(n int) int
    factorial = func(n int) int {
        if n == 1 {
            return 1
        }
        return n * factorial(n-1)
    }

    fmt.Println(factorial(5))
}

Go、基本的に良い感じだけど、三項演算子無かったり定数配列宣言出来なかったり、ちょこちょこ鬱陶しい感じもしなくもない

おわり(*・ω・)ノシ