投稿

診断メーカービューアの今後について

ずっとメンテナンスしてきた 診断メーカービューア ですが、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

Mastodon(Docker環境)でElasticsearchを有効にした時のメモ

この記事は、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

Mastodon v3.2.0 アップデートメモ (S3+CloudFront環境)

この記事は、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=

Macを買ってmikutterを入れたときのメモ

イメージ
おひさです。転職したら前よりお金が入るようになったのでMacBook Air (2020)を買ってしまいました。 さて、新しいマシンを買ったときにすることと言えば、 mikutter のインストールですね! 買って半年くらいしてそろそろやるかという気持ちになったので、トライしてみました。 前提条件 インストール作業時の私の環境はこんな感じ。先にTissueの開発環境を作ったり、Objective-Cを触って遊んでいたので既に色々入っている。 macOS Catalina 10.15.7 Xcode 12.0.1 インストール済 homebrew インストール済 XQuartz インストール済 mikutterのダウンロード 私はdevelop版を常用しているので、mikutterのbrew formulaは完全に無視して直接git clone。場所は適当にホームの下のどこかに。 作業時に使ったリビジョンはmikutter 4.1.1リリース直前の d97f09b918d92624a4e76fce7d6a17cef9aedb4e でした。 依存関係を何とかする mikutterをX無しで使用するのは、地獄というか無理であることが Akkiesoft氏のブログ によって知られています。実際試してみたんですが、TLのレンダリングが汚いとか、画像プレビューがまともに描画されないとか、そのウィンドウを閉じたらrubyごとクラッシュしたとか、散々でした。 先のブログではMacPortsを使っていますが、私の環境には既にhomebrewが入っています。あまりこれらを共存させたくないので、何とかbrewで押し切りたいところです。 幸い、 homebrewかつX11での環境構築の資料 があひる氏の手によってまとめられています。これをベースに…… あああ! homebrewがX11のサポートをやめている! ということで、何とかしてcairoとgtk+をX11サポートでビルドするよう、formulaにパッチを当てました……。 まず、cairoはXのヘッダーを参照できるよう depends_on :x11 を追加した上で、configureの部分でXCBとXLibのサポートを有効にします。 system &quo

2019年の振り返り

2019年が終わってしまいますね。や〜今年も頑張った。 後で思い出してそんなこともあったなぁと思えるように、どこかに書いておこうと思ったので久々にブログを書くことにしました。 Yukari 3.0 7月に、長い間 Yukari Next (2.1) として温めてきた バージョン 3.0 をリリース しました。 マルチサービスに対応するため、コアプログラムの大改修を行い、2013〜2014年頃に書いたプログラムを相当量捨てる結果となりました。昔書いたプログラムも相当ひどいですが、今書いても苦労するあたり、Androidプログラミングの腕が鈍ってしまったなぁと感じます。 実際にやったことといえば、サービスに依存しない"投稿"を表現する抽象型を定義したり、それを受けて適切な具象実装に送りこむプログラムを用意したり、今までその場で適当にAPIを呼んでいた部分を全部先述のプログラムを通るようにしたり……かなり地味でしたね。TL部分は、今までマイナーな機能として存在していたフィルタTLを全面的に採用することで少し楽ができました。(挙動の非互換でご迷惑おかけしてます) 年の後半からはTissueの開発を主にやっていたのと、転職活動があったのとで全然開発ができなくて、バグ修正が何もできていないのがつらい所です。 Tissueのコミッタが増えた Tissueではリポジトリを shikorism というOrganizationに置いています。 大した理由もなくそうしていたのですが、今年からは えあい さん に参加してもらうこととなりました。 彼は精力的にMetadataResolverの新規実装や修正、またフロント寄りの部分を改良してくださっていて、非常に助かっています。 他にも様々な方にご協力いただいております。shikorism organizationには他にも参加者が若干いますが、なんかPrivateなので触れないでおきます。ともかく、皆様ありがとうございます。 mikutterのコミッタになった mikutter 3.9.5 - mikutter blog にて紹介されましたが、夏にmikutterのコミッタの一員となりました。 一ユーザ、一プラグイン開発者として付き合い続けてここまで来るのは、ちょっと感慨深いものがあ

Yukari 5周年によせて

お久しぶりです。すっかりブログを書く習慣がなくなってしまいました。 さて、表題の通りですがYukari for Androidはとうとう5周年を迎えました。 これは、Play ストアで最初に公開した日である2013年12月22日から数えたものです。 (開発自体は2013年8月から。) 使っていただける人がいたから、ここまで続けることができました。 自分だけが使うものだったら、もうとっくに飽きていたと思います。 どうかお礼を言わせてください。本当にありがとうございます。 今年の振り返り Yukari 2.1 linkage の開発 昨年末にブランチを開始した次期バージョンは、 Mastodonへの対応 とそれに伴うタイムラインプログラムの整理を目標として開始しました。 Yukariにとってベストな形でMastodon対応を行うため、これまでのようなTwitterに依存しないシステムになるよう大幅なコードの書き直しを強いられているために、進行は非常に緩やかになっています。 そのため、今年は正式リリースできる状態には到達できませんでした。 ただし、自分だけでは拾いきれないバグを探すために評価版はリリースしました。 Mastodon上で「 Yukari Next 」と称して配布しています。 こちらは2018年8月に初回のリリースを行ってから、本稿時点で12回のリリースを行いました。 スマートフォンの画面も、私たちの時間も限られたものです。TwitterとMastodonを通しで閲覧できる環境のひとつの形を何とか最良の形にできたらと思います。 既にいくつかのクライアントが対応を完了させていますが、YukariはYukariらしい見え方を提示していきます。 正式版のリリースを待ってくださっている方は、申し訳ありませんが今しばらくお待ちください。 UserStreamの終わり Yukari 2.1をゆっくりと開発している最中、TwitterのUserStreamがとうとう終わってしまいました。 利用者の層と、それに見合わない負荷を考えれば商業上仕方ない判断かなとは思っています。 あまりスケールしなさそうな雰囲気がありますし、何より広告で食っているのに広告が流せないのに資源を延々使い潰されるわけですからね……。 とはいえ、私