「家族アルバム みてね」とダウンロードアプリと壁紙アプリ

「家族アルバム みてね」に写真をアップすると夫婦間での写真の共有も不要になり、また互いの両親も孫の写真が見れてとてもありがたい。 mitene.us

PC の壁紙に写真を流用したく、「みてね」からダウンロードする方法を探したところ「miteneDownloader」というのを発見。 github.com

CDATA をコピーする手順が面倒だったので fork して自分用に使いやすくした。 github.com

これで25枚ずつ楽にダウンロードできるし、カレンダーに二週間での繰り返し予定をいれ、定期的に写真をダウンロードする方針で動くことにした。

壁紙の設定は「John’s Background Switcher for Windows」を使うことにした。 ※Windows標準の壁紙設定はスマホの縦長写真に適してない。 johnsad.ventures Johns Background Switcher のダウンロード・使い方 - フリーソフト100

「miteneDownloader」は手動で操作することが前提となるが、自動でできそうなのも発見したので記載しておく。 blog.takuya-andou.com

Arduino Pro Micro v3.3 に書き込むまでの流れ & 再度書き込む方法

内容の対象者:Arduino 全然わからん人

注意点:純正ではなく互換機

参考にしたサイト

(Arduino) Pro Micro

環境設定

参考にしたサイトまんまの手順。

  1. 「ファイル > 環境設定」の追加のボードマネージャに以下の URL を追加する。 https://raw.githubusercontent.com/sparkfun/Arduino_Boards/master/IDE_Board_Manager/package_sparkfun_index.json
  2. 「ツール > ボード > ボードマネージャ」を開く。
  3. 「SparkFun AVR Boards」を検索してインストール。
  4. 「ツール > ボード > SparkFun AVR Boards > SparkFun Pro Micro」を選択。
  5. 「ツール > プロセッサ > ATmega32U4 (3.3V, 8MHz)を選択。
  6. 一度 Arduino.exe を終了して起動し直す。

ProMicro へ書き込む方法

マイコンボードに書き込む」ボタンを押した後、「マイコンボードに書きこんでいます」となった状態が8秒間続き、何もしないとエラーとなる。

この8秒間の間に ProMicro のリセットボタンを2回押すことで書きこむことができる。

この「リセットボタンを2回押す」が結構難しいので、ブレッドボードの使用またはリセットボタンをはんだ付けしておくことを推奨する。

ProMicro へ再度書き込む方法

普通にやると前述の方法で再書き込み可能。ただ ProMicro にキーボード操作やマウス操作などの処理をさせている場合、それが邪魔になることがある。そういう場合の書き込み手順。

  1. ProMicro を PC の USB ポートに接続する。
  2. リセットボタンを押しっぱなしにする。
    • ProMicro によるマウス操作が停止する。
  3. マイコンボードに書き込む」ボタンを押す。
  4. マイコンボードに書きこんでいます」が表示されたらリセットボタンを離してもう一度押して離す
    • 2回押したことになり書き込まれる

補足:最初に10秒程度のdelayを入れておくとより扱いやすくなる。

以上

mysqlの構築メモ

dockerでmysql, phpmyadminの環境を構築。ファイルの配置や文字コードの設定など苦戦したため自分用のメモとして残す。dumpの取得、取り込み、コンテナからの持ち出しも記載。

フォルダ構成

/root
├── /mount
│   ├── /db
│   │   ├── /docker-entrypoint-initdb.d
│   │   ├── /mysql
│   │   └── my.cnf
│   └── /phpmyadmin
│       └── /sessions
└── docker-compose.yml

バージョン

Docker version 20.10.11, build dea9396
Docker Compose version v2.2.1

docker-compose.yml

version: "3"
services:
  mysqldb:
    image: mysql:5.7
    command: mysqld --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
    environment: 
      MYSQL_ROOT_PASSWORD: hogehoge
      MYSQL_DATABASE: hogehoge
      MYSQL_USER: hogehoge
      MYSQL_PASSWORD: hogehoge
      TZ: 'Asia/Tokyo'
    volumes:
      - ./mount/db/mysql:/var/lib/mysql  
      - ./mount/db/my.cnf:/etc/mysql/conf.d/my.cnf
      - ./mount/db/docker-entrypoint-initdb.d:/docker-entrypoint-initdb.d
    ports:
      - "3306:3306"
  phpmyadmin:
    image: phpmyadmin/phpmyadmin
    depends_on:
      - mysqldb
    environment:
      - PMA_ARBITRARY=1
      - PMA_HOSTS='mysqldb'
    ports:
      - "3000:80"
    volumes:
      - ./mount/phpmyadmin/sessions:/sessions

my.cnf

windowsの場合はファイルを読み取り専用にしておくこと。linuxの場合はよく知らないけどchmod 644くらい。

[mysql]
default-character-set=utf8mb4

[mysqld]
character-set-server=utf8mb4
collation-server=utf8mb4_unicode_ci

[client]
default-character-set=utf8mb4

起動

# docker-compose build
# docker-compose -f docker-compose.yml -p project_name up -d

phpmyadmin

http://localhost:3000/ にアクセスしてログインできるか確認。

サーバ : mysqldb
ユーザ名 : hogehoge
パスワード : hogehoge

mysql

power shellからコンテナに入り、mysql文字コード確認。

# docker exec -it コンテナ名 /bin/bash

$ mysql -u root -phogehgoe 

mysql> show variables like "char%";
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | utf8mb4                    |
| character_set_connection | utf8mb4                    |
| character_set_database   | utf8mb4                    |
| character_set_filesystem | binary                     |
| character_set_results    | utf8mb4                    |
| character_set_server     | utf8mb4                    |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.00 sec)

データのエクスポート(mysqldump)と持ち出し

power shellからコンテナに入り、dumpを取得。 ※コンテナに入らずにmysqldumpを実行することも出来るが、テーブルの論理名が文字化けしたりデータが文字化けしたりとうまくいかなかった。

# docker exec -it コンテナ名 /bin/bash

$ mysqldump --default-character-set=binary -u root -phogehgoe hogehoge > /tmp/hogehoge.dump

$ exit

# docker cp コンテナ名:/tmp/hogehoge.dump hogehoge.dump

データのインポート

power shellからコンテナに入り、dumpを流し込み。

# docker exec -it コンテナ名 /bin/bash

$ mysql --default-character-set=binary -u root -phogehgoe hogehoge < /tmp/hogehoge.dump

以上、こんな感じでいいはず。

QMK Firmware で adjust レイヤーへの切り替え方法

40%キーボードを使用している場合、raise,lower 同時押しで adjust とする設定はよく使われていると思われる。QMK Firmware での設定方法を3つ記載する。

前提

レイヤーは以下の4つとし、それぞれ記載の通りとする。

  • base … デフォルトレイヤー
  • lower … デフォルトレイヤーからアクティブにできる
  • raise … デフォルトレイヤーからアクティブにできる
  • adjust … lower,raise レイヤーからアクティブにできる

レイヤーキーのみで実装する方法

レイヤーキーはホールド状態でアクティブになる LT,MO を使用する。この記事ではより簡易的な MO で説明する。

  • MO(layer) … ホールド状態で layer をアクティブにする。
  • LT(layer, kc) … ホールド状態で layer をアクティブにする。タップで kc を送信する。

base レイヤーに MO(lower) や MO(raise) を設定する。また lower,raise レイヤーには MO(adjust) を設定する。最もシンプルで、プログラムが苦手な人にも実装しやすい。

const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
    [_BASE  ] = LAYOUT( MO(_LOWER)  , MO(_RAISE ) ),
    [_LOWER ] = LAYOUT( XXXXXXXX    , MO(_ADJUST) ),
    [_RAISE ] = LAYOUT( MO(_ADJUST) , XXXXXXXX    ),
    [_ADJUST] = LAYOUT( XXXXXXXX    , XXXXXXXX    ),
};

レイヤーキーの詳細は QMK Firmware のドキュメントを参照。

サンプルを用意した。

レイヤーキー + update_tri_layer

以下のように lower,raise のカスタムキーコードを設定する。

enum custom_keycodes {
    C_LOWER = SAFE_RANGE,
    C_RAISE,
};

const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
    [_BASE  ] = LAYOUT( C_LOWER     , C_RAISE     ),
    [_LOWER ] = LAYOUT( XXXXXXXX    , C_RAISE     ),
    [_RAISE ] = LAYOUT( C_LOWER     , XXXXXXXX    ),
    [_ADJUST] = LAYOUT( XXXXXXXX    , XXXXXXXX    ),
};

カスタムキーコードを MO(lower) の代わりに C_LOWER としてキーマップに設定する。process_record_user 関数でカスタムキーコードに対する処理を実装し、layer_on,layer_off と一緒に update_tri_layer を記述する。

bool process_record_user(uint16_t keycode, keyrecord_t *record) {

    switch (keycode) {
        case C_LOWER:
            if (record->event.pressed) {
                layer_on(_LOWER);
                update_tri_layer(_LOWER, _RAISE, _ADJUST);
            } else {
                layer_off(_LOWER);
                update_tri_layer(_LOWER, _RAISE, _ADJUST);
            }
            return false;
            break;

        case C_RAISE:
            if (record->event.pressed) {
                layer_on(_RAISE);
                update_tri_layer(_LOWER, _RAISE, _ADJUST);
            } else {
                layer_off(_RAISE);
                update_tri_layer(_LOWER, _RAISE, _ADJUST);
            }
            return false;
            break;

        default:
            break;
    }

    return true;
}

この方法で実装すると以下のような動きになる。

  1. C_LOWER をホールド。lower レイヤーがアクティブになる。
  2. C_RAISE をホールド。( lower,raise の掛け合わせで) adjust レイヤーになる。
  3. C_RAISE を離す。lower レイヤーがアクティブになる。
  4. C_RAISE をホールド。( lower,raise の掛け合わせで) adjust レイヤーになる。
  5. C_LOWER を離す。raise レイヤーがアクティブになる。

上記の挙動は MO,LT で実装する方法では出来ない、より直感的な操作になる。

update_tri_layer の詳細は QMK Firmware のドキュメントを参照。

サンプルを用意した。

レイヤーキー + update_tri_layer_state

update_tri_layer と類似した機能。layer_on,layer_off で layer_state_set_user が呼び出されるため、その中で update_tri_layer_state を実装する。

layer_state_t layer_state_set_user(layer_state_t state) {
    return update_tri_layer_state(state, _LOWER, _RAISE, _ADJUST);
}

bool process_record_user(uint16_t keycode, keyrecord_t *record) {

    switch (keycode) {
        case C_LOWER:
            if (record->event.pressed) {
                layer_on(_LOWER);
            } else {
                layer_off(_LOWER);
            }
            return false;
            break;

        case C_RAISE:
            if (record->event.pressed) {
                layer_on(_RAISE);
            } else {
                layer_off(_RAISE);
            }
            return false;
            break;

        default:
            break;
    }

    return true;
}

簡易的に実装する場合は update_tri_layer_state、細かい制御をしたい場合は update_tri_layer と使い分けすると良さそうだ。

update_tri_layer_state の詳細は QMK Firmware のドキュメントを参照。

サンプルを用意した。

まとめ

enum custom_keycodes {
    C_LOWER = SAFE_RANGE,
    C_RAISE,
    C_ADJUST,
};

const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
    [_BASE  ] = LAYOUT( C_LOWER     , C_RAISE     ),
    [_LOWER ] = LAYOUT( XXXXXXXX    , C_ADJUST    ),
    [_RAISE ] = LAYOUT( C_ADJUST    , XXXXXXXX    ),
    [_ADJUST] = LAYOUT( XXXXXXXX    , XXXXXXXX    ),
};
        case C_ADJUST:
            if (record->event.pressed) {
                layer_on(_ADJUST);
                update_tri_layer(_LOWER, _RAISE, _ADJUST);
            } else {
                layer_off(_ADJUST);
                update_tri_layer(_LOWER, _RAISE, _ADJUST);
            }
            return false;
            break;

私は正しく理解しない状態でこの実装を行い、半年以上も直感的でない操作にモヤモヤしていた。改めてドキュメントに目を通してみると答えはそこに書かれていたのだ。ドキュメントは偉大である。

QMK Firmwareでの自分のソースコード管理

QMK Firmwareの自分のキーマップの管理方法について、自分なりの形ができたためメモを兼ねて書いてみる。基本的にはMacの話だが、Windowsでも同様のことは可能だと思う。 画像なし、文章のみ。

個人的な問題点

  • キーマップなどの情報をkeyboardフォルダ配下で管理するように設計されているが、自分のキーマップはQMKにプルリクするつもりがない。
  • keyboard配下のフォルダは階層が深い。深い位置でgit管理したくない。
  • QMK最新版を取得する時は別フォルダで管理したいが、そのたびにローカルクローンを作成したくない。

理想の環境

  • 自分のソースコードはDocument配下でgit管理。
  • QMK本体とは違う場所にあるkeymapのソースをビルドしたい。→課題!

課題の解決方法

  • keyboardフォルダ配下にフォルダのショートカットを作成してビルドするイメージ。
  • ただし通常のショートカットではビルドできないため、シンボリックリンクを使用する。

シンボリックリンクを作成する方法

シンボリックリンクはTerminal.appからコマンドで作成する。コマンドは以下。

$ ln -s (実ファイルのフルパス) (リンクを作成するフルパス)
$ ln -s ~/Document/keyboard/crkbd /QMK/qmk_firmware_hogehoge/keyboard/crkbd

“-s”をつけ忘れると「ハードリンク」が作成される。間違えて作成した場合はゴミ箱へ捨てて作り直せば良い。

参考

https://webrandum.net/alias-symbolic-link/ https://atmarkit.itmedia.co.jp/ait/articles/1605/30/news022.html

シンボリックリンク作成までの手順

  • 自分のソースコードをgitで管理し、Document配下にクローンを作成する。
  • QMK最新版を取得する。
  • QMKのkeyboard配下のフォルダを全て削除する。
  • 以下の流れでシンボリックリンクを作成する。(極力手打ちしない方法)
  • keyboard配下に作成したいシンボリックリンクのフォルダを作成する。
    • Terminal.app を起動し、”ln -s “を入力する。
    • Terminal.app に対して、Document配下のフォルダをD&D。後ろにスペース追加。
    • Terminal.app に対して、keyboard配下のフォルダをD&D。
    • keyboard配下に作成したフォルダを削除
    • Terminal.app のコマンドをenterで実行
    • QMKのmakeコマンドを実行し、ビルドできることを確認

最後に

自分用のメモを兼ねて記事に書いてみた。書いて気になった点を挙げておく。

  • QMKの最新版を別フォルダで管理するのであれば、それごとにローカルクローンを作成した方がいいのではないか。バージョン別にその時ビルドできた環境が残るメリット。(QMK Firmwareのバージョンを分けたい気持ちが強いのでそこまでしなくてもいいかな?微妙)
  • キーボード単位にシンボリックリンクを作成するのではなく、keyboardフォルダ自体のシンボリックリンクの方が手間が減りそう。

ソースコード(キーマップ)をgitで管理できるのはやっぱり大きい。キーマップの変更をバージョン管理できるし、キーマップ以外の部分でがっつり変えたいときはブランチを分けて試すことができる。

ちなみにQMK Firmwareではハイフンのついたフォルダ名はビルド出来ないようなので別ブランチの名前(もしくはcloneするフォルダ名、またはシンボリックリンク名)にはハイフンを入れず、アンダースコアなどで対応した方が良い。

以上