2019年1月24日木曜日

WebPが主要ブラウザで表示可能になりそうなので表示テストをしてみた

Firefox 65がWebPを採用するそうです。 ちなみにみんなご存知 I Can use ではIE/Safariなどが非対応になっている訳ですが、これはWebP画像単体で表示しようとするとダウンロード画面が出たりする理由にもよります。 実際にはHTML経由では表示可能という事が結構あります。 Firefoxも少し前から表示はできたみたいで、結局は各ブラウザで確認するしかない。 たぶんだいたい動くようになってきたので、そろそろWebPの採用に本腰を入れても良い頃合いではないかと思いました。

そんな訳でみんなご存知レナさんを使って表示テストを行ってみました。 実は私、レナさんの事をよく知らなかったんですが、元データはヌード画像だったらしい (参考: Wikipedia)。 今までヌード画像を弄っていたんだな、なんてこった。 オリジナルデータを使うと怒られてしまうので今回検証に利用するのは512x512のこちらのデータです。 これにcwebpコマンドで様々な圧縮をかけてどれくらいの圧縮率が良いかを確認してみます。 コマンドラインオプションはこの辺を参考に。 ただオプションが多過ぎて正直あまり設定したくない。わかりやすい -q オプションだけでいいや。


ファイルサイズは以下のようになりました。 -q 75がデフォルトで、Googleが想定している標準値になります。 PNGの圧縮ツールとして有名なpngquantやpngnqとも比較してみると、その凄さがよくわかる。 -q 100でも1/4のサイズになっているという。
  • 元画像: 473831
  • pngnq -s 1: 200698
  • pngquant --speed 1: 192141
  • -q 100: 134176
  • -q 75: 22926
  • -q 50: 15634
  • -q 25: 10002

お次は画像をどうぞ。
pngnq -s 1
pngquant --speed 1
-q 100
-q 75
-q 50
-q 25


…ほとんど見た目が変わらないなあ。少しぼやけたかなという感じはあるけどそれくらい。 画像をテキストと同レベルまで圧縮できてて凄いと思う。Google is GOD.

2019年1月21日月曜日

CSSフレームワーク比較: やはりBootstrapが良いかも

普段は Bootstrap を使っているのですが、 いつか別のものにする事もあるかも知れないので、仕様を比較したり、考え方をまとめてみました。 Bootstrap 以外では、Semantic UI, Materialize, Bulma, Foundation あたりが有名みたいですね。
そもそもなぜ CSS フレームワークを使うかというと、面倒を減らすためはもちろんだけど、 JavaScript で操作する時に style で操作するより className で操作するほうがパフォーマンスが良いところに源流があります。 だから className ベースの記法が主流になった訳だけど、Tailwind CSS みたく小さな単位の className だけで構成すると、 CSS を二度覚えているのと変わりません。 あと何となく俺々コンポーネントを自作するのと、アクセシビリティをきちんとしたコンポーネントを作るのは、ぜんぜん違います。 ほとんどの人はボタンや navbar といった利用頻度の高いコンポーネントベースのものを使ったほうが良いと思ってます。

そして CSS in JS lover な人や、完全なコンポーネントベース指向な人は Web Components ベースを推してきますが、 JavaScript のパースより CSS のパースのほうが圧倒的に早いので、それらは基本的にレンダリングが遅くなります。 また Shadow DOM を経由するとJavaScript の操作が面倒になる。 そして完璧な動作を目指すほど CSS が膨らみやすい。 このへんの問題を考えていくと、Web Components ベースの CSS フレームワークは必ずしも最善の選択肢ではなく、 現状では従来の CSS Framework が良い選択肢になることが多いと思う。 私はまだ普通のコンポーネントベースの CSS 派ですね (2020/12/23)。 Chakra UI とか MUI とか興味はありますが、まだ私が使うことはなさそう。

コンポーネントベースなら CSSフレームワークは何を使っても良いと思ってるのですが、先に述べたように普段はBootstrap を使っています。 Bootstrap が良いなと思う一番の理由は、ドキュメントが凄く読みやすいところ。 なぜ Bootstrap のドキュメントがこんなに読みやすいか考えてみると、 頻出コンポーネントだけ使う事を意識しているからと、実際によく使い込まれているからと思っている。



もう少し定量的に比較してみます。

機能比較

その他の様々なCSSフレームワークのドキュメントをサラッと眺めた感じでは、 機能的に Bootstrap を大きく上回ってるのは Semantic UI, UIkit の2つに見える。 Foundation, Bulma, Materialize は同等くらいかな。 私が現状で Bootstrap 以外のCSSフレームワークを選ぶとしたらこの中のどれかだと思う。
他のCSSフレームワークはちょっと機能不足を感じました。 例えばNavigationすらなかったりすると、面倒臭そうだなと感じてしまう。 Bootstrapの様々な機能を他のCSSフレームワークはどうやって実装するのかなと考えながらドキュメントを読んでいると感じるのですが、Bootstrapのドキュメントは突出してわかりやすいです。


テーマ比較

お金を掛けないでも多様なテーマがあるのは、たぶん BootstrapSemantic UIBulma だけです。 以下のサイトで色々なテーマが選べます。テーマは他のフレームワークもだいぶ進化してきて、だいぶ自由度が出てきましたが、この記事を最初に書いた時は Bootstrap 以外はなかなか使いにくかった。 お金を掛ければテーマを買えるフレームワークもあるのですが、あまりお金は掛けたくない。 テーマも色々あって、ガラッと中身を変えているタイプのものは、意外と使いにくかったりします。 細かなユーザビリティやアクセシビリティが重視される昨今、自分で弄ると結構な時間が掛かってしまう。 UI は格好良く作るのも大変ですが、アクセシビリティ対応も大変なんです。

初期テーマの使いやすさも重要と思ってます。 Bootstrap は平凡だけど凄く使いやすいテーマです。 その他のフレームワークは白基調のフラットテーマが多いんだけど、そういうのは意外と使いにくいと思ってる。 平凡なサイトなら確かに格好良くて良いけど、アプリに使おうとすると見にくくなりがち。 あと TailWind CSS のようにコンポーネントを別売りにするケースも出てきているのだけど、そこまでは使い込みたくない気持ちもあります。 たくさんアプリを作ってると、コンポーネントの統一性もほしいので…。 テーマがたくさんあって、Bootstrap の代替になり得そうなのは Semantic UIBulma かなあ。


ファイルサイズ比較

最小化したJavaScript/CSSのファイルサイズはレスポンスに影響があるので重要です。 重いと思っていたBootstrap が健闘している。 かなり意外な結果でした。 ちなみに Bulma はCSSのみで実現しているCSSフレームワークのようで、そうなるとイベント管理が難しい。 おそらく Bootstrap とサイズ的に大差はないと思います。 UIkit は高機能さから考えるとコスパの良いサイズになってる。

  • Semantic UI (2.4.1): 894KB
  • Materialize (1.0.0): 316KB
  • Foundation (6.5.1): 291KB
  • Bootstrap (4.2.1): 188KB
  • Bulma (0.7.2): 166KB
  • UIkit (2.27.5): 159KB

ところでCSSのファイルサイズに関しては、UnCSS, Criticalなどのツールで軽減できます。 これらを利用すれば不要なCSSを削除でき、レスポンス向上を目指す事ができる。 カスタムビルドに対応していると楽なのですが、そんなに提供されてないですからね。

Bootstrap に関して言えば私は 1/10 くらいのサイズで利用できています。 より重いCSSフレームワークは不要な CSS がもっと多いはずなので、効果はさらに大きいと思う。 CSS in JS でコテコテにするよりは、最初はこちらの方向性を目指したほうが、だいたい早くなるかと思います。 テクニックについてはこちらにまとめておきました


まとめ

この3つの比較で、私はBootstrap を今後も使おうと思いました。 次に良さそうなのは UIkit ですが、もう少しテーマが増えて欲しい気もします。 ただ実際に使ってみた事はない仕様面からの感想なので、使ってみると意外と良いかも知れません。 ファイルサイズを減らせれば Semantic UI も良いと思う。

追記 2021-07-25: この記事を最初に書いたときからは Bulma のテーマが進化してきて、Bootstrap 並に使いやすくなってきました。 Semantic UI の更新が止まってしまったので、今なら BootstrapBulma のどちらか。 そんなに書き味は変わらないので、好みに分けて使えば良いと思ってます。 私は慣れの問題で Bootstrap を使ってます。 v5 でさらに軽量&高機能にもなったので、離れる理由がない感じ。



その他細々とした比較の追記:

追記 2019-02-09: Bootstrapがなぜこんなにコンパクトなのかと思っていたのですが、設計が素晴らしいからのようです。上記のファイルサイズの比較表ではわかりにくいですが、JavaScript部分が他ライブラリと比較して凄く小さい。コードをちょっと眺めてみれば、なぜ全体のサイズがこれだけ小さくなるのか、また他より小さくなる理由がすぐにわかるんじゃないかと思います。

追記 2019-03-08: Bulma を使ってみる機会があったので、non-JavaScriptなBootstrap と比較してみました。 non-JavaScriptなBootstrap はアニメーションが動かない事で色々と動かない機能が出てきます。 その動かない機能を動かすためにはclassのtoggleなどを実装する必要があるのですが、これはBulma で書くべきJavaScriptコードとほぼ一緒だったりします。 つまりnon-JavaScriptな BootstrapBulma は仕様やCSS、コンポーネントの差くらいしかない事になります。 私は Bootstrap を Vanilla JS で動かすことのほうが多いので、正直あまり差がない…。

2019年1月14日月曜日

JavaScriptのforループ内でイベント登録

JavaScriptのforループ内でイベント登録をしようとして、ハマった。 もう何十回もハマっている気がするけど、ハマるものはハマる。
var buttons = document.getElementsByTagName('button');
for (var i=0; i<buttons.length; i++) {
  $('#foo').on('click', function () {
    exec(buttons[i], options);  // not work
  });
}
forループ内でスコープが消えたものを後から実行しようとしても駄目。 上記の例では buttons[i] の中身が見れなくなってまう。 色々な書き方の対策があるけど、以下のように即時関数で丸めてしまうのが楽だ
var buttons = document.getElementsByTagName('button');
for (var i=0; i<buttons.length; i++) {
  (function() {
    $('#foo').on('click', function () {
      exec(buttons[i], options);  // work
    });
  }());
}
日本のサイトだとクロージャの引数にデータを渡す書き方をよく見かけていたのだけど、イベントだけを回すようにしてfor全体を即時関数でまとめるほうが、引数を考える必要がないぶん楽な実装かも知れない。

QRコード決済と過去の歴史

QRコード決済の記事がどんどん増えている。 QRコード決済はクレジットカードやPASMO、Suicaが実現してきた事と何ら変わらないと私は思ってるけど、インパクトの大きさの差はある。 一応は過去を振り返って、現状を整理してみようと思った。



まずなぜクレジットカードやPASMO、SuicaよりQRコードなのか。単純に値段の問題です。


1. クレジットカード

クレジットカードの加盟店手数料は色々な種類があるので一言では言えないけど、10%取られる事もあるらしい。 逆にコンビニでは1%らしいのでかなり不平等なシステムになっていると思う。 これに加えて決済手数料が3〜10%くらいらしい。ようするに最大20%くらい手数料を取られる。 逆に大手だとその半分以下は当たり前なのだろう。 仮に20%の手数料を取られてそこから何らかのロイヤリティで20%引かれるとすると、 それだけで利益の40%が持っていかれる事が確定する訳だ。 これでは個人事業者はまあ儲からん。入れてないところが多いのも当然ではある。

2. PASMO, Suica

PASMO, Suicaは導入費用が公開されていないんだけど、10万円掛かるとか。 詳細はよくわからない。加盟店手数料は3-4%らしい。決済手数料も調べても全然わからない。 確かな事は何も言えないんだけど、仮に決済ごとに3%の手数料が掛かると、平均6-7%ほど取られる計算になるが、クレジットカードと比較すれば大きな進化である。 他にも何かあるかなと思っていたら、増田がバズっていた。 確かに審査の厳しさなども課題の1つにはあったのかも知れない。QRコード決済は結構緩くなっている。

3. QRコード決済

ではQRコード決済はどうかというと、もうサービスが増え過ぎて調べるのも面倒なんだけど、 PAY.JP, Origamiなどの競争力のある企業では、初期費用も加盟店手数料もなく、決済手数料3-4%だけで取引ができる。 ようするに20%→6-7%→3-4%と、かなり安い価格で取引できるようになったのだ。 Squareとかでも機材を用意すればこれくらいの価格で取引できたんだけど、QRコードになった事で機材も不要になった。 そして何より国際的にもメジャーだから、競争原理が働きAPIも価格もオープンになっており、現時点で最も安い決済手段になっていると思う。 QRコード決済に限らず、少額決済は海外の方が圧倒的に進んでおり、決済手数料3-4%で取引ができる。

4. 少額決済 (蛇足)

本来ならQRコード決済より前に小額決済が海外では普及していた。 しかし日本で少額決済が流行らなかったのは、日本では法律的に個人間送金ができない問題があったからだろうと思っている。 この特定商取引法に基づく表記の問題があるから、個人利用が意外と難しくてそこで困っていたのが少し前の話。

他にも少額決済は資金の移動が派生するから、決済事業者にとっても資金移動業の登録をしないといけなくて大変だったのだ。 Paypalが日本で個人間送金ができるようになったのはなんと2018/10/25から。日本展開にたぶん15〜20年は掛かってる。 このように世界の覇者Paypalでさえ苦労している国が日本なのだけど、気付いたら電通が主導するKyashとかの認知度も上がってきている。 Kyashは送金サービスではなく、個人間ポイント送信サービスである。 この肝は、いかにして送金じゃない事にするかという話である。 お金を送ると違法なので、お金を送らずポイントで送り、出金はできないようにしたりした。 日本の大企業が法律の穴を突付いてくるようになるとは、時代は変わったものだ。

そもそもKyashが出るより前の、もやもやとしている時にnoteとかBUYMAが出てきたけど、これらのスタイルが許容されているのは割と大きな進化ではあったように思う。 noteでは特定商取引法に基づく表記が不要なケースもあるBOOTHとかでもこの手の話はたまに上がるけど、昔のマインドよりは緩くなったような気もする。

5. 仮想通貨 (蛇足)

送金じゃない理論には他にも色々なものがあって、Bitcoinとかの仮想通貨も同じだと思う。 Bitcoinは通貨じゃないから個人間での交換ができたけど、証券業界が参入した事で通貨の価値が馬鹿みたいに上がって、送金手数料が馬鹿みたいに掛かるようになったりした。 価値もとんでもなく変動するし、通貨価値の証明やトランザクションの問題があり、通貨としての利用は難しいと私は思うのだが、ハッキング事件も含め数多くの闇を経て、暗号資産という名称に定着する事になった。 数多くの闇を抱えた割には大手の少額決済基盤にもあまり採用されておらず、普及していない印象がある。

6. 個人間取引

ここで改めて個人間取引についても言及しておこうと思う。 なんと個人間取引は消費税が非課税なのである。 だから多くの人がそこにこだわるのだろう。 これも個人間取引の課税強化議論というニュースもあって完璧なものではないのだけど、少なくとも現状では個人間取引を行う事によって、消費税ぶんだけの競争力を得る事ができるのは、割と大きなポイントだし、これによって仕事の効率化が進むのは良い事だと私は思っている。 ただ年間の売上が1000万円を超えると事業的規模になるので、特定商取引法にも関係してきて、事業者としての登録が必要になる。 儲かったらきちんと税金を払いましょう。


話が何度かそれたけど、QRコード決済が爆発的に増えたのは、クレジットカードやPASMO, Suicaと比較して、事業者にとって手数料が少なく利益に繋がりやすい (と思われている/思わせている) 点が大きかったのかなという気がする。 そして個人間取引によって行えば、消費税を掛けずに済むという税制上の利点も、個人の人気には繋がっていそうだ。 楽天のスタジアムでのキャッシュレス決済の原則化は象徴的に思う。 うまく個人委託すれば税金も安くなるし、作業時間が減れば売上も増える。 ただ現状のQRコード決済はちと手間が多いというか、色々な問題があるとは思っていて、それについてはまたいずれ書くつもりである。

最近はQRコード決済だけでなく少額決済もPaypalの時代からするとかなり整備されてきて、こちらも若干だけど賑わっているように思う。 QRコード決済の普及に伴って、日本でもようやく少額決済が流行るかも知れない。

レンタルサーバとVPSにおけるCGIの差は大きい

サービスの維持費を最初から極限まで切り詰める事を意識し、 レンタルサービスでサービスインできないか考えていたのですが、結局諦めてVPSにしました。 どのへんでレンタルサーバに詰まるかという事を、今後ハマらないようにメモしておきます。

まず今回のサービスはスタートからデータ容量が20GBくらいあってそれが結構増える予想だったので、 まずはそれを載せられるサーバでないといけなかった。VPSはディスク容量が弱いので意外と高く付く。 一番安かったのはロリポップ/スターサーバーの250円/月。 ちなみにクラウドストレージは容量だけでこれらの代金を超えかねない。


ただレンタルサーバによる運用は様々なつらみを伴う。さっそくサーバを設定しようとして、ハマりにハマったのがCGI。 普段はVPSしか使ってないため、もうCGIとかまったく使ってないので勘所を忘れていました。 最近はリバースプロキシでアプリを作るのが常識になってるので、その切り替えの簡単さから、手元のアプリもCGIにすぐ書き換えられるだろーとか思ってしまった。 しかし全然そんな事はなかった。

まず最初にハマったのは、PythonはCGIでHTTPヘッダを(たぶん)見れないという事でした。 RubyのCGIは環境変数にHTTPを入れるというトリッキーな実装をして回避してるけど、Pythonはたぶんそういうのない。 この実装差があるのでCGIを書くならまだRubyのほうが複雑な事に対応しやすい気がする。 HTTPヘッダを見れないと、例えば事前にgzip圧縮したファイルをCGI経由で表示できない。
ただHTTPヘッダを見ても事前にgzip圧縮したファイルのロードが難しいんだよなあ。 毎回ファイルI/Oを発生させるのは流石にあり得ず、生データをApacheにgzip化してもらうほうがマシである。 ようするにCGIじゃ駄目じゃん…と気が付いたり、久々のCGIには様々な苦行があった。 他にも安いプランのレンタルサーバではSSH, gcc, brotli, C/C++が使えないなど、つらみの連続である。


圧縮効率に話を戻すと、今回のサービスでは幸いにもCGIで送受信したいデータは小さく、 全体の静的データの通信量から見れば事前圧縮しないでもたいした問題は生じない事がわかった。 なのでライブラリはFastCGIでメモリに載る事を意識しながら、その他はファイルI/Oが発生しないように気を付ければ、 何とかならない気もしないでもなかった。

しかしまだまだ道程は遠い。CGIで少し高機能な事をしようとすると、当然ながらモジュールのロードが必要になってくる。 安いレンタルサーバにはSSHもホームディレクトリも存在しないため、ようするにWebルート上にライブラリを配置せざるを得なくなる。 これは当然セキュリティ的にアウトだし、そもそも実行できないようになってるんじゃないかな。 さて困ったという事になってしまう。
Rubyでも当然同じ事は起きるのだけど、Rubyのモジュール定義はディレクトリに依存しないので、 ライブラリをすべてシングルファイルに書き出して実行すればいけるのではと一瞬頭をよぎったのですが、そのようなライブラリがない状況下では悪魔的手法過ぎて、地獄感が半端なかったのでやめておきました。
一応少し高機能なCGIをでっち上げて動くかだけ確認してみたのですが、すぐに500エラーが出てしまって、うーんと思いながらこの辺りで利用を諦めました。 CGIのようにローカルで動いてもサーバの仕様に左右され過ぎて、リモートで動くかわからないのはちょっとな…。 SSHでホームディレクトリを弄れればもう少しまともな気がしますが、それだとディスク以外の点ではVPSと価格的に大差がないしなあ。


250円/月の魅力が強過ぎて無駄に時間を掛けてしまいましたが、結局はCGIがつら過ぎて私は最終的に諦めてしまいました。 ただ最初にも書きましたが、レンタルサーバはディスク容量と通信容量から見るととにかく安い。 今回のサービスはVPSで提供するならどんなに安くしても600円/月掛かります。 ネットワークに不安がある100円/月とかのVPSは使えないし、600円以下のプランも在庫がなかった。 時間を掛けて調査した割には微妙な結論に…。

レンタルサーバももう少し制約が緩ければなあ。 今回ハマりまくった理由の大半はリバースプロキシが使えないせいにある。 Google App EngineみたいなリバースプロキシAPIを用意してくれれば、 たいていの設定がかなり簡単にできて割と流行る気がするんですが、どこか実装してくれないかなあ。

2019年1月8日火曜日

ファーストビューのインライン化で爆速サイトを作る

ファーストビューをインライン化し、少ないCSSでひとまず表示するようにすると体感速度が上がります。 最近はツールも出てきてUnCSS, Criticalの2つが有名みたいです。 他にもPurifyCSSPurgecssDropCSSなど、いくつか似たようなツールがあります。 単純な出力サイズだけを見るならCriticalにはminifyオプションがあるので強いのですが、2つほど注意しないといけない事があります。


1. ファーストビュー以降の処理による表示崩れに注意

これらのツールは非常に便利だけどあくまでファーストビューの最適化だという事には注意しないといけません。 ファーストビューで表示されない部分については、後で遅延ロードする必要がある。 Bootstrapを例に挙げると、modal, popoverあたりにインライン化ツールをそのまま適用すると、ファーストビューの判定外のCSSがたくさんあるので、きちんと動かなくなってしまいます。

この問題には、普通ならpreloadやloadCSSなどのライブラリを使って、本来必要なCSSを再読込して回避する事になるのだろうと思います。 ここでまず最初に注意するべきは、CSSの上書きによって表示が崩れないようにしないといけないという事です。 具体的には !important を付けたり、それでも対処できない部分はクラス名を変更するなどして、上書きされないようにする必要がある。

この !important回りが結構面倒で、Criticalはminifyオプションを付けていると!importantの宣言を書き換えてくるので、CSSを遅延ロードしようとすると表示が崩壊するのです。 これはオプションを指定しなければ済む話かも知れませんが、CLIだと設定できないのがちょっと微妙だなと思いました。 私はNode.jsをそんなに使ってないのでこれは困る。


2. 遅延ロードも最適化する事を考えるべき

ファーストビュー以降のCSSは、一般的にはオリジナルのCSSを読み込んで調整するものだと考えています。 しかし最近のCSSフレームワークのサイズは結構大きいので、不要なCSSだらけ。 本当に遅延ロードするべきなのかという問題もあります。 一部分のCSSを動かすためだけにすべてのCSSを遅延ロードするのはあまりセンスが良くない。

この問題はUnCSS, Criticalではignoreオプション、DropCSSでは回避処理を自前実装する事によって回避できます。 ignoreオプションは名前の通り、ファーストビューの判定から外すためのオプションです。 ファーストビューのインライン化時に、後で使うCSSを削除しないようにする事で、全体のCSSロード量を減らす事ができます。 これはセンスの良い機能だと私は思っていて、ignoreオプションがあるかどうかはインライン化ツールにおける大きな機能差だと思っています。



UnCSSのignoreオプションでどのような指定をするとどれくらいCSSの量を減らせるかを、Bootstrap 4.2.1を用いて確認してみた結果が以下です。 Bootstrapに関わるCSSのサイズを左に表示しています。
11771  -- uncss foo.css
12720  -- uncss foo.css --ignore /\.modal/
16631  -- uncss foo.css --ignore "/\.(modal|popover)/"
140936 (bootstrap.min.css)
BootstrapのCSSをそのまま読み込む場合と比較して1/10くらいのサイズのロードで済んでいる事がわかります。 UnCSSを使えば、使う機能のCSSだけロードできるので、かなり最適化がしやすくなりました。 なおCriticalは色々調整してみたけど表示が崩れてしまってうまくいきませんでした。 良い感じの実行オプションがあれば教えて欲しいです。

あと実際の運用では、Bootstrapの色々な機能を使ってると上記の指定だけではおそらく足りないと思います。 例えばnavbarはまず必要となるでしょう。 こういうのが積み重なっていくとそれなりのサイズになる事が多いと思われる。 なのでファーストビューではUnCSSのオプションなしのものを使って、後から必要な部分だけカスタム化したものをloadCSSなどで読み込むと、通信量とパース量が結構下がるんじゃないかと思います。 この時に同一プロパティを削除したりするとさらに下げられる。

ただそのような同一プロパティの削除によるコスト削減は、これまで理屈上ではわかっていても、それを簡単にできるツールがありませんでした。 しかしDropCSSを少し改良すると、実現できるようになります。 興味のある方は参照してみてください。

カスタムビルドがないようなフレームワークでは割と使えるテクニックかも知れない。

JavaScriptで#ifdef を使う

JavaScriptで#ifdefを使いたい要望はないのだろうか。 私は簡易的なコピーガードをよく入れているので、今回は #ifdef を使ってそれを管理してみようと思った。

StackOverflowでgppなるものが紹介されていたのでそれを使ってみる事にした。 aptで入れられるのもポイントが高い。 上記ページは使い方の説明がちょっと間違っていて、以下のように書くとproductionモードのみで機能する関数を定義できる。
#define release
#ifdef release
  copyGuard();
#else
  console.log(foo);
#endif

以下のコマンドを実行すると、#ifdef 周りを処理してくれたJavaScriptコードを生成してくれる。 あとはこのファイルを普段通り使えば良い。
gpp test.js -Drelease > test.release.js

地味にもう1つハマりポイントがあって、同一ファイルへの書き出しはできない。 以下のように別ファイルに書き出してから戻す必要がある。
gpp test.js -Drelease > test.js.gpp
mv test.js.gpp test.js

使い方がわかれば非常に良い感じに使えるツール。 JavaScript以外の #ifdef に対応していない言語にも使えるので、応用範囲も広い。

2019年1月4日金曜日

2chのAAをOSに依存せず綺麗に表示するCSSの設定方法 (非Windows対策版)

(注) この記事の内容は古いです。 ここに書かれている細かなテクニックは、ブラウザの実装の問題によるもので、今は治っています。 昔はブラウザのバグで大変だったねという歴史と、細かなテクニックを覚えておくために残していますが、歴史はどうでもいいから AA をすぐに表示したい人は、こちらをどうぞ

(以下保管用) 2chのAAをOSに依存せず綺麗に表示する方法を何回か記事にしたけど、直近1年でのブラウザの実装変化によって混沌としてしまったので、現時点で採用している方法を簡潔に書き直しました。 過去の歴史を見たい人は以下を参考にして欲しい。
簡潔と言ったからには結論から書いてしまう。今使ってるCSSはこんな感じです。 フォントは今まで通り、https://yamacraft.github.io/textar-font/ を利用している。
@font-face {
  font-family: 'Textar';
  font-style: normal;
  font-weight: normal;
  src: local('Textar'),
  url('/fonts/textar-min.woff') format('woff'),
  url('/fonts/textar-min.ttf') format('truetype'),
  url('/fonts/textar-min.svg') format('svg');
}

pre.aa {
  font-size: 1em;
  line-height: 1.1;
  font-family: '梅Pゴシック',Textar,sans-serif;
  white-space: pre;
  word-wrap: normal;
}
/* 今はもう以下の記述は不要です
   https://www.ryadel.com/en/css3-media-query-target-only-ie-ie6-ie11-firefox-chrome-safari-edge/
   https://jeffclayton.wordpress.com/2015/02/01/css-os-platform-specific-hacks/
   https://stackoverflow.com/questions/15190340/css-platform-specific-hacks
   http://browserhacks.com/
*/
/* IE8 */
@media \0screen {
  pre.aa { font-family: 'MS Pゴシック','MS PGothic','梅Pゴシック',Textar,sans-serif; }
}
/* IE9+ */
@media screen and (min-width:0\0) and (min-resolution: +72dpi) {
  pre.aa { font-family: 'MS Pゴシック','MS PGothic','梅Pゴシック',Textar,sans-serif; }
}
/* Edge */
@supports (-ms-ime-align:auto) {
  pre.aa { font-family: 'MS Pゴシック','MS PGothic','梅Pゴシック',Textar,sans-serif; }
}


ポイントは5つ。
  1. CSSハックでLinuxにおけるMS Pゴシックの問題に対応する、JavaScriptでレンダリング処理するより高速だしJavaScriptを切っても動く
  2. CSSハックはIE/Edgeの判定で対応するのが無難 (バージョンアップで機能しなくなった時の影響が小さい、表示が崩れる事がない)
  3. @font-faceに条件を付けないと重そうだけど、PageSpeed Insightsには影響しない
  4. それどころか最近のブラウザではフォント処理は最適化されていてデバッガに表示されない=賢い処理をしてくれているからブラウザに任せたほうが良い
  5. 上記に伴ってスマホだけ読み込む判定処理も利点はなくなってきた (最初の1回の遅さを気にしなければ)
注意点も3つ書いておこう。 (1) @font-face に local('MS PGothic') を書いてはいけない。 LinuxにおけるMS Pゴシックの問題が生じる。 (2) CSSハックは不安定なものである事を忘れちゃ駄目。 このCSSを利用する際は、CSSハックがブラウザのバージョンアップ後にも動く事を、バージョンアップのたびに確認して使って欲しい。 (3) IE/Edge以外でWindowsを判定するCSSはない (昔は部分的にならあったけど) ので、Chrome/FirefoxなどではTextarで表示するようになっている。 これを不満と思えば以前示したようにJavaScriptで処理するか、フォント切り替えフォームを用意しよう。

上記3点にだけ注意すれば、AAの表示は上記のコードで今のところは万全と思う。 CSSの指定の意味とか、どのフォントが良いとか、フォントを切り替えられたほうがユーザビリティが良いかもとか、細かな点については過去の投稿を見て欲しい。

2019年1月1日火曜日

2018年発表作品で特に面白かったフリーゲーム

フリゲ2018が発表されていました。 2018年のランキングも結構予想外でしたが、やはり新説魔法少女が入ってきましたね。 私は無印をクリア済みだったので未プレイです。 ざくざくアクターズもさすがの人気でした。 EvaliceSagaも面白かったですが、実はまだ完全クリアしてない…。 上位ランキングにもいくつか知らない作品がありました。

私が2018年の発表作品で特に面白かったと思ったTop5は以下。
  1. Overnight Mare
  2. すっぽんクエスト (紹介記事)
  3. シューティングスターセブン (紹介記事)
  4. 人類滅亡後のPinocchia (紹介記事)
  5. ぶきあつめ ~なんでも武器になるRPG~ (紹介記事)

Overnight Mare は著作権的に紹介を自重したのですが、非常に完成度の高い作品でした。 ランキングに入ってくるかなと思ったのですが、入ってこなかった。 それでもイチオシはこれでしょうか。熱中度が凄かった。

2-5位の作品はブログでも紹介したものですが、1-3位は特に悩まずこれだなと選べました。 ADVで2位に食い込んでくる すっぽんクエスト は、改めて印象深かった作品でした。 シューティングスターセブン も凄くおすすめなのですが、認知されてないみたい。 4-10位くらいはどれも面白くて選ぶのが大変でしたが、熱中度を重視して選んでみました。





2018年は著作権や、様々な理由により紹介を自重した作品が多かったのですが、面白い作品がたくさん見つかりました。 グリム・ディエムの冒険録 あるいは忘れられた海の底で も非常に面白い作品で記事を書きたかったのですが、私の環境では画面がうまく表示されなかったので記事は書けませんでした。 2018年にプレイして記事化していないものでは、以下がおすすめの作品です。
エコー 体験版孤高のアオイロ が特におすすめ。