プログラマーのメモ書き

伊勢在住のプログラマーが気になることを気ままにメモったブログです

Logicool M705 マウスの修理

こちらの記事で書いた、 Logicool M705 のマウス、使い勝手が良くて使っていたのですが、最近、ドラッグ&ドロップの途中で動きがおかしくなるなど、なんか挙動が怪しくなってきました。

ドラッグの途中で、ボタンを押しているのに、離したときのような挙動になるので、最初は電池がもうすぐなくなるのかな?と思い、電池交換とかしたのですが、治りません。

結構長く(6年強になりますね)使っていたので、そろそろ寿命かな?と思いつつ、念のため似たような現象ないかググってみると、いっぱいあります。

どうも、マウスの『チャタリング』と呼ばれる現象のようです。こんな名前がついてるのか、知らなかったー。

で、他にもいろいろと記事を見ていると、自分で修理もできるとのこと。長く使っていることもあり、失敗してもいいや、ということで、マウスの修理に挑戦しましたので、そのメモ書きです。

準備

さて、実際の作業の前に、道具を準備します。

  • 星型のドライバー(トルクスドライバー)
  • 接点復活材

後で写真載せているように M705 の場合、ネジがトルクスネジ(星型のネジ)になっていたので、近所の百円ショップでトルクスドライバーを買っておきます。あと、接点復活材は下記のものを購入しました。

で、道具が準備できたので、いよいよ分解です!

分解

分解は下記の記事などを参考に進めます。

こちらが、今回分解するマウスになります。

電池を外して内部を確認すると、ネジが一つあります。

あと、型番のシールが貼ってあり、それを見ると、 M-R0073 という番号になっていました。

下記の記事などを参考にすると、どうもこれは M705m という商品名で販売されていたものっぽいです。

logicool M705を買い替えたらモデルチェンジしていた - ドナドナされるプログラマのメモ

ネジの取り外し

上記の記事によると、電池のふたを外したところ以外にも、あと4か所隠れネジがあるようです。頑張って外します。

マウスの上側のネジ

まずは、マウスの上側のほうにある、マウスソール(というのかな?)を剥がします。が、これがなかなか剥がせない。

仕方ないので、写真のように、マイナスの精密ドライバーの小さい奴でこじって強引に剥がしました。あってんのかこれ?

左右とも剥がすとこんな感じになります。

拡大すると、

こんな感じです。

電池ケースの下

電池ケースの下にあるネジは、電池ケース底面のシールが邪魔になって確認できません。『シールをはがして外します。』という記事も見たのですが、不精なのとシールは残したいので、このあたりだろうとアテをつけて、ドライバーでつついていきます。

シールとネジの間に少し空洞があるようで、若干へこむところがあるので、思い切ってドライバーを刺してネジの頭を探すと、そのうちぴったりとはまりました。こんな調子で2本ともはずします。

外した後は、こんな感じになります。

カバーを外す

ネジが5本とも外れたら、カバーを外します。カバーは少し力を入れると簡単に外せます。

本来であれば、基盤とカバーをつないでいるコネクタを外したほうがいろいろと作業もしやすいし、断線するリスクもないんでしょうが、なんかうまく外せなかったので、強引ですがこのまま作業をすることにしました。

マウスボタンのスイッチ部分のカバーを外す

今回は、マウスの左ボタンの調子が悪いので、そのボタンの下にあるスイッチ部分のカバー(黒い箱状のもの)を外します。

で、これを外すのが一苦労です。黒いカバーの下に、2か所ほど隙間があるので、そちらにドライバを入れて外そうとしたんですが、なかなか外れません。

なんども試すうちに、前側の隙間からドライバーをスイッチの前方側に向かって入れて、力を入れたら、思いっきりカバーが飛んでいきました。

我ながら不器用にもほどがある・・・

焦りながら、あちこち探してみると、無事に一応カバーとスイッチ部分(白いパーツ)が見つかりました。

せっかくなので、カバーの写真を載せておきます。

スイッチ(白いやつ)

この白いやつがないと、マウスのボタンを押したときに反応しない(はず)なので、くれぐれも無くさないようにする必要があります。

修理

修理は簡単で、カバーが外れた後の金属部分に、接点復活スプレーを吹きかけるだけです(写真撮り忘れました)。

ノズルを使ってかけたのですが、結構広範囲に吹き付けられるようなので、作業時には周りに注意しましょう。

組み立て

あとは組み立てるだけです。組み立ては難しくはないのですが、さきほどの白いスイッチの部品をカバーにセットして、基盤にはめます。

白いスイッチの少し幅が大きくなっているほうを、黒いカバーの内側にして、白いスイッチの幅の狭いほうが、外側に出てっ来るようにします。この状態で、基盤にセットできればOKなはずです。

が、基盤を下側にしてはめようとすると、当然ながら、何も支えていない白いスイッチが落ちてきます。なので、基盤を上にして、黒いカバーを下側からはめ込んでやる必要があります。

最初の写真のように、カバーの中央付近に白いスイッチがみえていたら大丈夫っぽいです。

ここまでできたら、ネジを戻して終わりです。ちなみに電池カバーの部分は、ネジをつけるとこんな感じになりました。

動作確認

組みあがったマウスの電源を入れて、PCにつないで使ってみます。ドラッグ’&ドロップしてみると、おぉ、スムーズに動きます。

一時はどうなるかと思ったけど、無事に治ったようです。

参考

作業が終わった後でしたが、下記の記事を見ると、マウスボタンのスイッチの構造について詳しく載ってました。

datyotosanpo.blog.fc2.com

あと、上記の記事でも紹介されていますが、チャタリングを判定してくれるサイトがあるようです。これ使って試せばよかったー。

service.webgoto.net

まとめ

工程としては、そんなに難しくない印象です。

が、この作業、老眼の身には非常につらいです。次も同じことがあったとしたらどうするかな?作業用ルーペでも買わないと自分ではできなさそうな雰囲気です。

でも、下記の記事などを見ると、スイッチの部分までは分解しなくてもよかったのかもしれません。これでいけるなら、十分やる価値ありますね。

マウスのドラッグが途切れる症状、チャタリングは自分で直せる!コンタクトスプレーの使い方 | 梨々コミ

なんにしても、老眼の方はお気をつけて。

Android Studio が重い

Android Stduio でアプリの改修作業を行っていたら、ある時突然 CPU 使用率が80%~90%超で推移して、フリーズするようになってしまいました。

結論としては・・・修正したコードに無限ループが含まれていたことが原因だったようです(トホホです)。

まあ、それがわかるまでに結構時間を使ってしまったので、一応やったことメモに残しておきます。

  • OS: WIndows 11 22H2
  • Android Studio : 2021.3.1 Dolphin Patch 1

異常発生

何も意識せずに、とあるプロジェクトの修正作業を行っていたところ、急に Android Studio が重くなり、フリーズしてしまいました。当然、何の操作もできなくなりました。

仕方ないので、何が起きたんだ?と思いつつ、タスクマネージャで落としてから、もう一度立ち上げても、しばらくすると同じ現象になります。

今度は、タスクマネージャをよく見ると、 CPU 使用率が非常に高いままになって、一向に下がりません。

どうも、何かトラブったようです。

やったこと

手始めにこんなことをやりました。

  • Android Studio の再起動
  • PC の再起動

これでも改善しません。プロジェクトを壊してしまったかな?と思ったので、一度、別のプロジェクトを開いてみます。なんと、問題なく開けますね。どうも、プロジェクト依存の問題のようです。

ということで、

  • プロジェクトのバックアップコピーをとっておき、 build, .idea, .gradle あたりをディレクトリごと削除して、Android Studio でオープン

としてみました。これやったとき、一時的に治ったかに見えたのですが、結局作業を始めると同じ現象になってしまいました。

そうこうするうちに、画面上に Analyzing... とでて止まっているのに気が付いたので、それでググると、似たような現象の記事がありました。

kotlin - Android Studio stuck at "Analyzing..." - Stack Overflow

それによると、Android Studio のキャッシュを消せ、とのこと。なので、

  • C:\Users\ユーザー名\AppData\Local\Google\AndroidStudio2021.3\cache を削除

とやってみましたが、再度試してもだめ。

困ったなーと思って、上記のディレクトリを眺めていると、 log というフォルダがあります。ここを見ると、いろいろとあるんですが、 idea.log というファイルが今試している更新日時になっています。これが、 Android Studio のログファイルっぽいぞ、とおもったので、エディタで開いてみると、今回のエラーが起きてる日時について、 OutOfMemory だの Low Memory だのというメッセージがたくさん見えます。

あ、これが原因だったのね。(最終的に、これは原因ではありませんでした。あとで、間違いに気づきます。)

対応策?

原因がわかれば、対応できます。

ヒープサイズエラーが出た時の対処方法 - Android アプリ開発「MATRIX」

Android Studio のメモリ不足(ヒープサイズエラー)は昔も対応やったな、と思いつつ、改めてググってみると、上記のような記事が出てきました。

早速、いったん、 Android Studio を閉じて、テキストエディタを開き、このプロジェクトの gradle.properties ファイルを開いて、 -Xmx2048m となっているこころを -Xmx4096m にしてみます。

その後、 Android Studio を起動します。これで、解決!

とおもいきや、状況が変わりません。あれれ?とおもって、さらに調べてみると、どうもこの設定は、一度プロジェクトをリビルドしないと有効にならないとのことです。

Configure Android Studio  |  Android Developers

まじか。。。

ということで、仕方ないので、編集中のファイルを一旦、スタッシュに退避させて、リポジトリを間違いなく動いていたところまで戻して、この状態で Android Studio を立ち上げます。

で、さきほどの gradle.properties を編集後、 rebuild をかけます。問題ないですね。

ここまで出来たら、リポジトリを元に戻して、さらにスタッシュに退避させていたものを反映させます。この状態で Android Studio を操作すると、おぉ、無事に動きます。

ついでに、上記の記事を元に、 IDE のメモリの上限も増やしておきました。

これで解決、と思ったのですが、しばらくすると、やっぱりフリーズします。新たに割り当てたメモリが足りないのかな?とおもいつつ、 2G -> 4G -> 8G -> 16G -> 32G あたりまで試しましたが、やっぱり落ちます。

これは妙だな。なんか違うぞ。

Android Studio の再インストール

やる手がなくなってきたので、 Android Studio も再インストールしてみます。

2021.3.1 Dolphin Patch 1

を 2023.1.1 Patch 2

にしました。

で、結論は・・・やっぱり状況変わらずです。

原因発見!

何が原因だろうか?と思っていろいろと調べてみるけど、なかなか理由がわかりません。何かの際に、先ほどの AndroidStudio のログファイルを見直していたら、 OutOfMemory のところにスタックトレースが出ており、自分が修正したクラス名が出ているのがわかります。しかも、その後 HashMap でエラーが起きて止まってます。

ん? HashMap でエラー?なんか怪しいぞ。

と思ってコードをよく見ると、なんと、 HashMap に要素を追加する処理が無限ループになっています!

やっと見つけました。

単に処理中に無限ループがあるのではなく、運悪く既存の Layout クラスを extends して、独自のクラスを定義している時に、一部の初期化処理を static イニシャライザ( static の初期化ブロック)で行っており、その中に無限ループを入れ込んでいました。

static のため、プロジェクトを実行しなくても、このクラスを用いたレイアウトファイル(xml ファイル)を表示するだけで、初期化処理が動いて無限ループが呼ばれたようで、当然メモリが足りなくなり、落ちていたということのようです。

あー、こんなことが原因になるなんてな・・・

まとめ

結局、ヒープメモリ設定は悪くなく、上記のバグ修正後は元に戻しても快適に動いていました。思わぬところで OutOfMemory を引き起こしていましたね。こんなミスもあるよ、ということで、晒しておきます。何かの参考になれば幸いです。

にしても、最初に Android Studio のログ見たときに、もうちょっと注意していれば、解決が早かったように思えて、悔やまれます。ログの確認は大事ですね。

kintone の Javascript カスタマイズに関する雑多なあれこれ

kintone の Javascript カスタマイズの際に気がついた、いままで書いてない雑多なことをまとめておきます。

カスタマイズ関連のあれこれは下記にも書いてますので、こちらもご参考にしてください。

スペーステンプレート

スペーステンプレートを利用すると、簡単にスペースおよびそこに含まれるアプリのコピーを作ることができるので、移行の際には非常に便利です。

ただ、スペースやアプリの更新には使えず、常に新規作成になるので アプリ ID (スペース ID)が変わってしまうため、 Javascript カスタマイズとの相性はいまいちですが、まあ、便利です。

ポータルに画像を含む場合

で、このスペーステンプレートを利用して、ポータルが有効なスペースで、かつポータルに画像を設定しているスペースに対して、スペーステンプレートを作成したら、エラーとなったときがありました。

その時の状況としては、

  • 同一ドメインの別スペースで読み込んだ画像を設定しており、その後最初に読み込んだスペースを削除した場合に起きた
  • 詳細は条件は不明だが、アップロードした素材への参照が問題になることがあるようだ
  • エラーになった画像を、再アップロードしてポータルに設定したら問題なく作成できた

という感じでした。

スペーステンプレートを作成する際には、ちょっと気を付けたほうがいいかもしれませんね。

レコードの書き出しと読み込み

アプリを移行する場合、レコードの内容は移されません。なので、別作業で、レコードの書き出しと読み込みを行う必要があるかと思います。

この操作の時に、こんなことに気が付きました。

  • ルックアップのコピーフィールドは、書き出さなくても、読み込み時に適切に対応してくれる(ルックアップ元がある場合)
  • 読み込み時に、『一括更新のキー』として『レコード番号』にチェックがついていると、新規レコードの読み込みに失敗する

最初、2つ目の制限に気がつかなくて、ちょっと焦りました。結局、これは、下記

ファイルからレコードのデータをアプリに読み込む | kintone ヘルプ

のリファレンスの補足にも明記されていることになります。

ということで、アプリを移行するような場合(新規にレコードをコピーするような場合)には、『一括更新のキー』のチェックはなくても問題ないので、チェックを外した設定で読み込めば問題なく取り込めます。

ルックアップと変更イベント

ルックアップ(フィールド)を元に、ルックアップしたら何かしら行いたい、というカスタマイズがあると思います。ですが、ルックアップフィールド自体には、変更イベントが発生しません。

なので、こういう時は、ルックアップ取得時に一緒にコピーするフィールドを用意しておき、そのコピーフィールドに変更イベントを定義して、変更したことを分かるようにすれば対応できます。ちなみに、このコピーフィールドは、変更禁止にしておくとルックアップによる変更イベントのみを発生させて受け取ることができるようになります。

計算フィールドと変更イベント

で、これは聞いた話で自分ではまだ試してないんですが、同様のことが、計算フィールドでも起きるということだそうです(@kimiko0217 さんに教えていただきました)。

まとめ

ある程度カスタマイズしようとすると、こういった kintone の流儀を身に着けておかないと、なかなか効率があがりませんね。きっと、また別のところではまるでしょうが、とりあえずはこんなところで。

何かの参考になれば幸いです。