雑草

ずっとメンテナンスしてきた 診断メーカービューア ですが、2021年8月9日リリースのver2.32をもって正式にサポートを終了とさせていただきます。2013年8月15日のver1.00より、およそ8年もの間ご愛用いただき誠にありがとうございました。 今後は開発者の生活に余裕がある場合や、個人的な利用のために本家サイトの仕様変更に追従するアップデートが配信される可能性はありますが、リリースをお約束することはできません。 せっかくなので、このアプリをリリースした頃から振り返ってみたいと思います。(一部はPlayストアでのサポート終了のあいさつと重複しています) このアプリの開発を始めたのはgit logからの推定では2013年6月頃、まだ私が高校生だった頃です。当時の私が使っていたスマートフォンはSH-13C、Android 2.3の端末でした。 このスマートフォンは当時の水準から見てもローエンドに近い端末で、とにかく性能が貧弱でした。ストレージ容量だけは大きかったので、Xperia使いの友人がアプリを入れられずに苦しんでいるのを煽ることだけはできましたが……。 そのため、ブラウザを起動すれば立ち上がりだけで何秒も待たされますしページロードも重い、パズドラで遊ぼうとすればまともなフレームレートを維持できず操作すら困難、そんな端末でした。もちろん、これらのアプリを起動した後はバックグラウンドのアプリは全部リソース不足でkillされています。そして、アプリ切り替えで余計に待たされるわけです。つらいですね。 そんな中、Twitter中毒だった私は身内で流行っていた診断メーカーで遊ぶことが増えていました。ただ、診断メーカーはご存知の通りWebサービスですので、TLでクソみたいな診断を見つけたらブラウザを開かないと便乗して遊ぶことができません。 「えっ、このためだけに何秒も待って、あげくツイートした後TL戻ろうとしたらアプリkillされてんの……？ たかがクソ診断やぞ 」というもやもやした気持ちをよく抱えていた気がします。 とはいえ比較的単純なCGI的な動きをするサービスですので、ハックするのは簡単だろうという予想はすぐにできました。当時の開発のトレンドというか、そろそろ当たり前だろうとなりつつあったAndroid 4.0のHoloデザインに対応したアプリの開発を勉強したいとい

最近、家でどのポインティングデバイスを使おうかという事でそこそこ真剣に悩んでいます。 まず現状を説明したいのですが、数年前から公私ともにトラックボールをメインで使っています。 数機種転々としていますが、自宅では SlimBlade 、会社では Orbit Fusion を愛用しています。 ただ、最近会社では MX Master 3 というマウスも時折使用しているといった感じです。 このMX Master 3がなかなか良くて、セールスポイントとなっている特殊なホイールの操作感が格別ですね。 仕事では縦に長いページの多いWebシステムの面倒を見ているので、このマウスを使っている時はなかなか快適です。 そのせいでOrbit Fusionに戻れなくなってきた また、 せっかく下請け現場抜けたのに 社外から提供された仕様書で未だ半端に横に長いExcelファイルを見ることもあるので、横スクロールのためのホイールがあるのもプラスです。 ……といった感じで、最近はトラックボールに凝るばかりではなくマウスの価値も見直しつつある状態です。 話が分からなくなってきましたね、じゃあ何を悩んでいるのという話をしましょう。 最近、机の上がやたら汚くなってきたんですよ。物が多くて掃除がしにくいんですね。掃除は苦手です。 そのため、できれば机上の配線を減らして多少はホコリを取りやすくしたいなぁと思うようになりました。実家に居た時もそういった考えの傾向はあったんですが、引っ越してから最近まで何故か抜け落ちていました。 こうなると、真っ先に気になるのはキーボードとトラックボールです。キーボードは非常に気に入っているので変える気がありません。諦めます。 すると、有線接続であるトラックボール……SlimBladeをどうにか出来ないかと思うようになりました。 近い形状をしていて無線接続ができる ExpertMouse Wireless は悪くありませんが、私が持っている個体はスクロールリングがやや重いです。 これは割とつらくて、SlimBladeを購入した理由となっている程度には使う気が起きません。 Orbit Fusion を自宅に持ち帰ってくるのは割と有力だと思っています。ExpertMous

この記事は、2018/11/5 00:51にQrunchにて公開したエントリの 再公開版 となります。 内容は当時のままですので、古くなっているはずです。予めご了承ください。 基本的には以下の記事を参考にして作業した。 https://blog.theboss.tech/2018/04/01/elasticsearch-on-mastodon-docker/ 作業環境はこんな感じ。 EC2 t3.small Amazon Linux 2 Elasticsearchの有効化 docker-compose.yml のesサービスのコメントを解除する。 t3.smallくらいだとメモリが足りないので、ES_JAVA_OPTS は -Xms256M -Xmx256M くらいに落としたほうが安全かもしれない。 webサービス側に書かれている depends_on も忘れずに。 ボリュームマウントするディレクトリを作成。デフォルトで ./elasticsearch に作成されるが、所有者を 1000:1000 にしておく。 これでいけるわけがなく、一部は上記記事のトラブルシューティングと重なるのだが、がっつりハマってしまった。 vm.max_map_countの変更 このまま docker-compose up -d してもエラーが発生し、コンテナが正常に起動してくれなかった。 エラーログを残し忘れたが、vm.max_map_count の変更によって解決。 # 現在値を確認 $ sysctl -a | grep vm.max_map_count # ... 略 ... vm.max_map_count = 65530 # ... 略 ... # 十分な値を設定 $ sudo sysctl -w vm.max_map_count=262144 $ echo "vm.max_map_count=262144" | sudo tee -a /etc/sysctl.conf ファイルディスクリプタ上限の変更 これでいけると思っていたが、まだエラーが発生していた。ファイルディスクリプタの上限が低いとな……？ es_1

この記事は、2020/8/2 10:54にQrunchにて公開したエントリ https://qrunch.net/@shibafu528/entries/38YisAjxltKKMs8y の 再公開版 となります。 内容は基本的に当時のままですので、古くなっているはずです。予めご了承ください。 基本的には下記のリリース手順に従うだけ……なのはいつもの事。 https://github.com/tootsuite/mastodon/releases/tag/v3.2.0 ただし、今回は メディアを別サーバに置いている場合はCORSの設定が必要 との記載あり。どうやらv3.2.0で新しくなった音声プレイヤーが正しく動作するために必要らしい。 If you are serving user-uploaded files from a differet domain/subdomain than the one the Mastodon web UI is served from, please keep in mind that you need to return CORS headers on those files, otherwise the new audio player will not work. Here is an example of nginx directives for returning the appropriate CORS headers: ```nginx add_header 'Access-Control-Allow-Origin' '*'; ``` 私が管理しているertona.netではメディアをS3にアップロードし、CloudFrontを経由して配信しているので、下記の対応が必要だった。 S3のCORS設定 S3 Management Consoleを開き、「アクセス権限」→「CORSの設定」を開く。 続いて、CORS構成エディターに下記のような感じで設定を投入する。とりあえずS3はこれだけでも動いてくれる。 詳しくは ドキュメント 参照。 <?xml version="1.0" encoding=