生存報告
WeChat Mini Program、 XML でビューを定義して JS でコード書けるってもう完璧にクロスプラットフォームアプリフレームワークじゃん
あっ img.azyobuzi.net にリソース回せってことですね!(そろそろ Instagram API 申請バトルしなきゃかなぁ……)
img.azyobuzi.net の負荷が高くてミラーお願いしてた頃は CGI だったのが悪かったので、今はかなり落ち着いている
@upsilon 恒常的にアクセスはあるので Function より普通にサーバーがあったほうがお得なような気もしますがどうなんでしょう? あと本当に負荷はすごく小さくなっているので、全部うちの VPS に向けてもらっても大丈夫なはずです(僕の設定ミスで即死するアベイラビリティの低さはありますが)
僕のところへのリクエストが月200万ということは、単純に2バイト考えると400万。つまり 22.4x3 で 67.2 円か。メモリ使用量による課金の方はどう計算したらいいんだろう
@upsilon 確かに安く抑えられそうな気もしてきました。ただ、キャッシュの置き場所がないとただの攻撃サーバーになってしまうので、追加でなにか必要ではありますよね
@upsilon CDN にやらせるという発想はなかった!(いけそうですか?)
KVS 置くのに関しては、コストが VPS より安くなることはなさそうというお気持ちがあります
Functions、触るの DreamSpark サブスクリプションではダメっぽいので、通常サブスクリプション確保して、ついでに無料枠で1ヶ月 VPS 代浮かせるか
Progress、 IProgress で受け取った側が Report するけど、 Progress 作った側は Report しないので妥当な設計に見えるが
ストレージ 20GB の環境ね、最初は余裕だけど、気づくといつ入れたかわからないパッケージで圧迫されているので、ビルド環境は作らないなどの制約を持って構築すればいけるいける
僕の ConoHa 鯖、ストレージ使用量が 28GB/50GB だった。もう何が入ってるのかさっぱりわからんが、ひとつ言えるのは、外部ストレージを使っていないので、あんなデータやこんなデータなどが 5GB 以上占めていること
リードオンリーだけど IList 実装したいから、変更を加える操作は非 public で throw NotSupportedException とかあるし、インターフェイスと public メンバーが違うのは許容できる選択だと思ってる
Progress<T> が SynchronizationContext 使うことにぶち切れた結果などがある https://github.com/CoreTweet/CoreTweet/blob/265bbe8e18cfa10a008bc02a7fbee319be77f32c/CoreTweet.Shared/Internal/SimpleProgress.cs
SynchronizationContext に関する扱い、大体 GUI アプリからの使い心地方向に倒されているので、ライブラリ作る側からするといつ罠が潜んでいるかビクビクする
逆に Twitter なんて大規模サービスが API を 1 個追加した日には、それを 5 年以上は保守しなきゃいけないので、簡単にサードパティ―に API なんて公開できない
オレンジが言いたいこととしては、外向きのAPIがどうのとかに限った話じゃなく、あらゆるプログラミングの要素は、互換性とその維持の為の将来性を考えながらプログラミングするべきだし、克服不可能あるいは困難な非互換が生じてしまったら土下座するつもりで望むべき!>< みたいな心構えがみたいな・・・・><
互換性を維持するべきかどうかは、そのプロダクトにどのくらい責任を負っているか次第だと思ってる。客がいっぱいいる、変更で信頼を失うなら意地でも維持するべきだし、そうでなければ利用者に負担を押し付けていく。
互換性を維持するには誰かが負担を背負っていかなければいけないんだけれども、もう自分は使わないから捨てたいって言っている人が背負う必要はなく、使いたい人が背負うのが正常ではないかと。特に自由ソフトウェアならば
ちょっと自宅サーバーとかわからないのでうちには http://akizukidenshi.com/catalog/g/gM-11954/ しかないですね……