みつのーと

頑張ってます・・・

Kintone のレコード詳細画面でコメント欄を非表示にする chrome 拡張を書いた

kintone すごく便利で、シンプルなシステムならもう kintone でシュッとやれば良さそう、みたいな感じがあってすごい。

すごいんだけど、レコード詳細画面のコメント欄が邪魔だった。 ので、コメント欄を表示/非表示するだけな chrome 拡張をざっくり書いた。

だいぶざっくり書いたのであんまりソースは見られたくないんだけど、一応 github に置いてあるので、もし「コメント欄邪魔だなー」ってなってる人には少し役立つかも。

mitsu-ksgr/kintone-chat-view-toggle-switch

chrome://extensions/ を開いて、 Developer mode を ON にして適当に追加して使ってください。

使うとこんな感じになります。

f:id:mitsu-ksgr:20181119082549g:plain

孫の手プラグインなるものをオススメして頂いたんだけど（ありがとうございますっ）、コメント欄開閉のためだけに登録とかしたくなかったので、今回は結局試さなかった。 gusuku 使ってる人はこれを使うとよさそう。

https://docs.gusuku.io/plugin/magonote/

GPD-Pocket: Arch 4.17.3-1-ARCH にアップグレードすると無線LANが使えなくなる

GPD-Pocketに Hans氏のカスタムカーネル を入れて使っているんだけれど、pacman でシステムアップグレードしたところ、無線インターフェースを認識しなくなってしまった。

ちょっと前に arch 4.17.2 に上げたときも同じ現象になってしまったんだけど、その時は時間がなかったから、一旦カーネルをダウングレードしてその場しのぎをしていた。

そのことをうっかり忘れて、今朝またアップグレードしてしまい あーってなったんだけど、検索したら（暫定的な）対処法が見つかったので、なんとかなった。

Heads up: Broadcom WiFi driver crashes on 4.17.2 in Arch : GPDPocket

# 一応僕は、以下を実行するまえに /usr/lib/firmware/brcm/brcmfmac4356-pcie.bin, txt をバックアップした。
$ sudo curl -Lo /usr/lib/firmware/brcm/brcmfmac4356-pcie.bin "https://github.com/andir/nixos-gpd-pocket/blob/master/firmware/brcmfmac4356-pcie.bin?raw=true"
$ sudo curl -Lo /usr/lib/firmware/brcm/brcmfmac4356-pcie.txt "https://github.com/andir/nixos-gpd-pocket/blob/master/firmware/brcmfmac4356-pcie.txt?raw=true"

# リロードする
$ modprobe -r brcmfmac
$ modprobe brcmfmac

これで無線インターフェースが認識されてる（ハズ）。

最新のカーネルのファームウェアからBCM4356のアレがアレしてしまった感じっぽい（要するに細かい部分はよくわかってない）。

上のRedditの投稿で「次のファームウェアで修正されると思う」と言っているので、次のファームウェアを待つのもありかもしれない。 また、これらのファイルはファームウェアが更新されるタイミングで勝手に置き換えられるので、今回上書きしたことは（今後動き続ける限り）気にする必要はない。

もし今後のファームウェアアップデートで再度認識されなくなっても、またここらへんファイルをアレすれば何とかなりそう、という感じになれたので、多分よかった。

systemdが Failed to dissect: Input/output error って吐く

----- [2018/06/14 追記] -----

ArchWikiのGPD Pocketのページをよく見たら、ちゃんと載ってた。

ブートローダの設定をすればいいらしい。 さすがArchWiki、なんでも載っている…ッ！！

----- [追記ここまで] -----

systemctlを使ってserviceを enable/disable すると、enable/disable 自体はちゃんと成功しているんだけど、なんか見慣れないエラーが表示されてしまう。

$ sudo systemctl enable lightdm.service
Created symlink /etc/systemd/system/display-manager.service -> /usr/lib/systemd/system/lightdm.service.
[46494.337569] systemd-gpt-auto-generator[26889]: Failed to dissect: Input/output error

みたいな感じ。

結論からいうと、これはsystemd側の問題みたいで、すでにmasterに修正がmergeされている。 最新のv238にはまだこの修正は入っていないので、多分次の v239 になれば直ると思う。

enable/disable自体は動いているし（symlinkはちゃんと生成/破棄される）、ディスクのマウントもfstabの情報で問題なくできていて、現状はこれによって何か問題が起きてる、という感じはない。

ので、とりあえず最新パッケージを待つので良さそう（Archであれば、AURのsytemd-git を使うって方法もありそうだけど、僕は待つことにした）。




修正済みだしどうせ待ってれば直るんだけど、せっかくググったりなんだりしたので、調べたことを自分用にメモしておく。 正直ほとんど理解できてないので、もしちゃんと知りたい場合は、IssueとPRを読みましょう…僕は何もわからん…何も…

発生する環境

  • eMMCモデルのマシン
  • systemd のversionが v238 以前
  • blkidがインストールされている

僕の場合はGPD Pocket にArchを入れたところで、この問題に遭遇した。 GPD PocketはeMMCを採用していて、2018/06/10時点でのArchのcoreリポジトリのsystemdはv238。

systemdのバージョンは、次のコマンドで調べられる。

$ systemd-cat --version
systemd 238
+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN +PCRE2 default-hierarchy=hybrid

発生原因

systemd-gpt-auto-generator がパーティションを検出するときに、eMMCのbootエリアとRPMBエリアまで余計に検出してしまい、それがエラーに繋がっている（らしい）。

ちなみに、systemd-gpt-auto-generatorは、システムのパーティションを自動的に検出・マウントしてくれるソフトウェア（らしい）。 ただ、どうしてenalbe/disableするときもこいつが動いているのかはよく分からなかった。

eMMCは通常のユーザーデータ領域の他に、bootエリア２つとRPMB(Replay Protected Memory Block)エリアをもっている。 eMMCのディスクをマウントしてるシステムでlsblkすると、

$ lsbkl -o name,type
 NAME           TYPE
 mmcblk0boot0   disk    # Boot Area Partition 1
 mmcblk0boot1   disk    # Boot Area Partition 2
 mmcblk0rpmb    disk    # RPMB Area
 mmcblk0        disk    # User Data Area
 ├─mmcblk0p1    part    #   Partition 1
 ├─mmcblk0p2    part    #   Partition 2
 └─mmcblk0p3    part    #   Partition 3

といった形で表示される。 mmcblk0boot*というのがbootエリアで、mmcblk0rpmbがRPMBエリア。

（ただ、なぜか今の僕のGPD-Pocketはmmcblk0rpmbが表示されない。Ubuntuだった頃は確かにあったんだけど…）

systemd-gpt-auto-generatorは内部でkernelが列挙するパーティションとblkidが列挙するパーティションの数を突き合わせている（ここらへん）。

このときに、blkidはユーザーデータのパーティションのみを列挙するのに対し、kernelはブロックデバイスをすべて列挙してしまう。 kernelが列挙してきたeMMCのbootエリア、RPMBエリアも合わせてカウントしてしまうため、bootエリア・rpmbエリアの数だけパーティション数にズレが生じ、件のエラーが吐かれていた。

修正PRでは、kernelが列挙したディスクに対して、eMMCのbootエリア・RPMBエリアを無視する対応が入っている。

dissect: Don't count RPMB and boot partitions by jprvita · Pull Request #8609 · systemd/systemd · GitHub

return (sysname && startswith(sysname, "mmcblk") &&
        (endswith(sysname, "rpmb") || endswith(sysname, "boot0") || endswith(sysname, "boot1")));



今までeMMCは、なんとなくスマホやタブレットに使われてるってイメージが強かったんだけど、小型PCだと普通に載るようになってきたし、chrome-bookもeMMCモデルが多いみたい。 そういえばeMMC上にlinuxディストロをインストールしたのは初めてな気がする、以前Chromebookでarchを使ったときは、sdカードから起動してたし。

RPMBについても色々調べてみたんだけど、「大体わかった」と「いまいち理解しきれない」の中間くらいの感覚で、うまくまとめられなかった。

参考

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

キーボード

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

今までは静電容量方式のFC660Cを２年ほど使っていたんだけど、個人的に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からピンク軸を取り出す

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

赤軸を外す

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

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

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

ピンク軸を半田付けする

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

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

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

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

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

音に関しては、赤軸はもちろん、静電容量方式の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）

とすると、１枚あたり両面で４ページ印刷出来る。 ので、この設定で中綴じ印刷が出来るように、スクリプトで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で構築することである程度対応出来ると思ってる。 ただ、コンテナ１つのプロジェクトはそうそうないのでdocker-composeを使う事になると思うんだけど、現状Kitematicがdocker-composeに対応してない（いつか対応するのかな）。

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

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

Electron

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

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

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