Webアプリ開発などを中心としたITに関するメモのブログです。
Asset Studio で、Inkscape で作成した SVG 画像を扱うとき、Inkscape 特有のタグなどのせいでエラーが発生する場合は「プレーンSVG」として保存すれば良さそう。
ただ、この場合は Inkscape のデータが失われる。
参考:
グラデーションに関しては上記では解決せず、
例えば ic_launcher.svg などを Inkscape で作って Asset Studio でアップロードしようとすると
ERROR @ line 83: Gradient has no stop info
のようなエラーが出て、グラデーションが適用されない。
前のエントリでも紹介した node-archiver-zip-encryptable の開発では Prettier を適用したが、フォーマットの統一に注意を払わなくて済むのは非常に快適だった。
ルーツが何かは調べられていないが、過去の自分の経験の中で似たようなものには Golang の gofmt があった。
Java のプロジェクトでも適用できないものかと思ったが、 prettier-java は現在 Work in Progress の状態。
これもまた少し前の話になるが、vim スクリプトで簡単なタスク管理用スクリプトを作った。
結果は以下のようなイメージ。
~/.vimrc
タスク管理のツールは世の中に数え切れないほどあるが、自分の場合は以下のようなことが要件で、ちょうど良いものが見つからなかった。
少し前、従来のパスワードつきのZIP圧縮(Traditional PKWARE encryption)をNode.js (Lambda)で使いたかったが、ちょうどよいものが見当たらなかったので node-archiver-zip-encryptable というものを作成したので記録しておく。
これは node-archiver をベースにして、拡張機能的に付加することで利用する。
この archiver とその依存ライブラリが変わらない限りは、100% ピュア JavaScript の実装である。
今回の実装をするにあたり、そもそも普通に Windows で展開できるような(セキュリティ的には弱い)パスワードつきの圧縮というものに名前がついているのを知らず、調査に手間取った。
Golang での ZIP 圧縮ライブラリ alexmullins/zip にパスワード付与を実装している yeka/zip と、こちらの仕様を参考に実装。
https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT
自分で構築すればもっとシンプルで楽にできるのかもしれないが、長らくこのドメインでやってきていることもあり Blogger を続けようと思っている。
ただ、Blogger の「テンプレート」にはいろいろムダなものが入っていて、ページの表示が遅かったりする。ブログ再開を機に更新することにした。
Lighthouse の Chrome Extension での計測で、以下のように改善。
| 項目 | 変更前 | 変更後 |
|---|---|---|
| Performance | 75 | 90 |
| Progressive Web App | 58 | |
| Accessibility | 44 | 65 |
| Best Practices | 79 | 93 |
| SEO | 100 | 100 |
PageSpeed Insights だとモバイルが 91 点、PC が 100 点に改善した。
実際に表示した場合のあるときの数値は
69 リクエスト、652 KB、5.9 秒から
38 リクエスト、325 KB、3.1 秒に改善 (ばらつきはある)。
以下では、その改善のための変更内容について説明。
2017年以降 ブログ更新が停滞していたので、シンプル単語帳のアップデートを進める中での課題から。
アプリ内で使う小さい画像ファイルは DPI ごとに用意していて、より大きな解像度が登場すると作り直すようなことをしていたが、これをやらなくて済むようにするのと、アプリのサイズを少しでも減らせたらという思いで、今さらながら VectorDrawable を試した。
シンプル単語帳にナイトモードを導入してほしいリクエストがあり、確かにあったほうが良さそうだと思ったため実装している。
(現時点ではまだリリースしていない)
ただ、どうもアプリの起動が遅くなっているように見える。
各 Activity の onCreate でナイトモードを設定するような方法で実装。
前回のエントリ でふれた Concourse CI について。
チュートリアルを試したのだが、いくつか躓くポイントがあったため記録しておく。
※Concourse CI を批判するわけではなく、単なる記録。
しばらくブログを書いていないと思い、気がつけば 2 年近く更新が止まっていた…。2018 年も間もなく終わりだが、今年最初のエントリ。
頻度は低いものの、Android アプリの更新は続けている。
もう少し高頻度に開発したいが、どうしても時間がかかるのがテスト。特に最近は Kotlin に切り替えたり、各種のライブラリをアップデートしたりとテストを入念にしておきたい要素が多い。そうするとやはり CI の仕組みを整えたい。
まだやってなかったの？という感じはあるが、クラウドサービスだとプライベートリポジトリでは基本的に有料なためなかなか手が出せていなかった。
OSS として開発している場合には、Travis など各種の CI サービスが無料で使えることが多いので基本的に困らないのだが。かといって、CI サービスを無料で使うためにこのアプリのコードを公開するのは避けたい。
では PC 上でテストを流すので我慢しようというのも微妙だなぁと思うので、OSS の開発と同様に、Git リポジトリにコードを push するとインターネット上のどこかの環境で CI が実行されるような環境の整備を目指したい。費用はゼロとは言わないが、最小限に。
そんなモチベーションのもとで、個人開発のプライベートリポジトリに対して CI をするにはどんなやり方があるかを検討してみた。
SpringでField InjectionよりConstructor Injectionが推奨される理由 を読んで、Springにおいて@Autowiredをフィールドに付与するField Injection、普通に使ってしまっているなぁ…と考えつつ、Constructor Injectionの方が確かに良さそうなので試してみた。これ自体は補足することはないが、Spring 4.2以前+Gradle+Querydslという点で少し躓いたのでメモ。
各種バージョンなどは以下のとおり。(いずれも少し古い)