- 煙草を吸わないということについての考え
- それほどヘビーではないけどずっと吸ってきた人間としての意見
- 今は吸ってない
- アレン・カーの禁煙本とベイパーでちゃんとやめました
- 煙草を許容できるほど社会が寛容でなくなった、人は多すぎるし、世界は狭すぎる。不愉快なことが多いと、心はますますせまくなる。
- わかりやすい悪は滅びるべき、臭いし、不健康だし。
- ほんと息苦しい世の中になってしまった
- 煙草のいい点については語らない。ボケ防止とか頭がすっきりするとかなんとか。そんなものはない、でいい。
- ただ、嗜好品というだけでそれは、ある一部の人にとっては無条件で「いいもの」。そこを否定してはいけない。
- 煙草がまだ一部安く買える国はある。貧困な国。煙草がなぜあったか、いまもあるかというと、主に労働者のガス抜き。
- 煙草は健康を害するため社会保険の負担となる可能性がある。なので高福祉国家にとっては負担となる可能性が高い
- という話をきいたことがあるが、この言説にはおおいに疑問が残る
- 2018年基準。たばこ税は年間2兆円の税収
- 健康保険での医療支出は11.8兆円。だがただし、後期高齢者の医療費は5兆円で。それをのぞくと6兆円が社会的な医療に対する負担額。
- 乱暴な言い分だが後期高齢者なんて喫煙関係なくそもそも医療費はかかる
- あしたみながみな煙草をやめたとして5兆円の後期高齢者分の負担は減らず、6兆円の医療負担がいくら減るかはわからない。というか年々膨らんでいってる
- むしろもっと熱心にたばこ税、あつめたほうがいいんじゃないかな
- 陰謀論の流れとしては、たばこを吸うことは単純労働に対しては影響が少ないが、基本的に労働生産性をおとしている可能性が高いので禁止、抑圧する、そうした考えもありうる
- ただ、数値がでないと単なる憶測で意味があると思えない
- 禁煙もビジネスである 誰が儲かるって医者が儲かる。煙草産業がロビーしてることを批難するなら、逆もまたしかり。結局、国に利益があるのはどちらかで考えないといけない。個人的には医者に仕事よこすよりは、煙草税集めたほうがいい。
- 医者は世界各地にいる、巨大な煙草会社は限定的な国や地域にしか存在しない。医師という存在は社会的に権威を持つ。ゆえに真実がどうであれ禁煙サイドの方が有利。
- 健康にいいは金科玉条
- 医者が自らの禁煙ビジネスを確保するために国の税収の一個を根絶やしにしようとしているととらえられなくもない
- 結論としては禁煙するにしても、医師は遠のけたほうがいい。禁煙外来とかニコチンパッチとかまったく意味がないし高額なうえ社会負担(健康保険)になる。
- むしろ加熱煙草やヴェイパーで減らすと禁煙しやすいと思います。
- ここらへんも発がん性があるとか社会悪に誘導されてるのが怖い
- たばこはやめたほうがいいと思いますし、やめれますが、医者はそれで利益を得ているし、得ようとしていることを忘れない、ちゃんと把握しよう。そして善悪はともかくとして、たばこ産業より、健康産業の方が規模がでかい。
- わたしは誰に踊らされてるのか?しっかり自覚したい。
- 踊らされて無駄に金払ってないか?
- 禁煙には利点が多い、喫煙は中毒症状である
- たしかにそのとおりではあるが、中毒するものはおしなべて悪いというわけではない
- 悪いとすると、酒とたばこと大麻と自動車の排気ガスと焼肉の煙、どいつが一番悪いみたいな不毛な会話になってしまう
- その症状含めて嗜好と見做すことはできる
- たばこをやめるべき理由は、喫煙することによる、不利益や損失が大きくなりすぎているため。それが個人的に許容できる範囲なら別に煙草をやめる必要は個人的にはないと思う
- アレン・カーのアレは洗脳だけど利益のあるほうに誘導してくれるなら洗脳でも構わないと思います。
- 月間二万円の趣味はすでに今の日本では6割方の成人にとって高価すぎる
2019年5月20日月曜日
煙草をやめてというか、吸うほどの余裕が世の中になくなってきて禁煙について考えること
2019年5月17日金曜日
phpenvでphp-fpmを切り替える際のはまりどころ
- 一度うまく環境作って人に説明するとき忘れてたので数年ぶりで覚書。老化だな!
- php-envではphp-fpmなどのモジュール類もあわせて切り替えられる。(というかphp-env経由でインストールするとデフォルトで導入される)
- /home/vagrant/versions/に切り替え対象のバージョンで呼び出されるファイルや設定ファイル、リンクなどが入っている。
- php-fpmなどのモジュールを切り替える必要がある場合ここにファイルをリンクやら直接バイナリを置くなりで補ってるあげる必要がある
- そもそもOSレベルでの導入済のバージョンがある場合、切り替えようフォルダだけできてなにも入ってないケースがある。この場合phpそのものの切り替えはともかくモジュールの切り替えがうまくいかないことがあった
- この場合はversions/x.x.x/の下にbinディレクトリやsbinディレクトリを作ってシンボリックリンクを貼ってあげるとうまく切り替えてくれるようになる。php-fpmはsbin。phpizeとかphpそのものととかはbinの下にhogehoge。
- ただ切り替え後にphp-fpmをリスタートするとかはプロセス番号がかわるとかでうまくいかないのでそこは泥臭くkillとかしてあげる必要がある
- phpenvはどうしようもなく古いPHPのバージョンから7.2にあげたいとかいうケースでは使い方覚えた方がいいですね
2015年7月14日火曜日
太ったり太ったり太ったり、たまに痩せたり
小学生のあたりくらいにすこし甘やかしたらブクブク太ったので武道をはじめさせられた
大学生くらいまでは痩せてるといわないまでも、太ってはいませんでしたうん。
太ったのは社会にでてからですが28くらいまではなにをどうしても肥えるので、ある程度気を使っていました。スポーツジムとか通ったりですね。
スポーツジムって社交の場だと思うのですが社交性のない人にとっては、一人焼肉以上のつらさがありますよ。
その後1年間引き篭もっていろいろ諦めた結果、ものすごく肥えた。あとは自宅で運動して痩せたり太ったりの繰り返しで、これ痩せるのは、有酸素運動を継続してやる作業で繰り返すと基本体質的に太る。
半年も頑張れば30kgは落とした実績はある。でも半年かかるので億劫で続かないし、そんなの何にもならん。
病院はいってないけど健康診断では薬による体質改善を求められる感じに。やばいというかもう体質だよなあ、食べるのは好きだけどあまり食べまくるほうでもなし、酒もプライベートではのまないですし。
本日任天堂の岩田社長が亡くなったとのこと、少し不謹慎ですが個人的にお会いしたとかもないので、去年末あたりはお病気ですごくお痩せになっていたことを思いだす。ふるーい話ですが逸見政孝さんとか思い出しました。ご冥福をお祈りします。
スティーブジョブスも晩年そうだったけど、闘病期間も長かったし、悲壮感が軽減されてた感はある。岩田社長はほんと突然な話。
病気にならないためにも運動しないといけませんよね。
大学生くらいまでは痩せてるといわないまでも、太ってはいませんでしたうん。
太ったのは社会にでてからですが28くらいまではなにをどうしても肥えるので、ある程度気を使っていました。スポーツジムとか通ったりですね。
スポーツジムって社交の場だと思うのですが社交性のない人にとっては、一人焼肉以上のつらさがありますよ。
その後1年間引き篭もっていろいろ諦めた結果、ものすごく肥えた。あとは自宅で運動して痩せたり太ったりの繰り返しで、これ痩せるのは、有酸素運動を継続してやる作業で繰り返すと基本体質的に太る。
半年も頑張れば30kgは落とした実績はある。でも半年かかるので億劫で続かないし、そんなの何にもならん。
病院はいってないけど健康診断では薬による体質改善を求められる感じに。やばいというかもう体質だよなあ、食べるのは好きだけどあまり食べまくるほうでもなし、酒もプライベートではのまないですし。
本日任天堂の岩田社長が亡くなったとのこと、少し不謹慎ですが個人的にお会いしたとかもないので、去年末あたりはお病気ですごくお痩せになっていたことを思いだす。ふるーい話ですが逸見政孝さんとか思い出しました。ご冥福をお祈りします。
スティーブジョブスも晩年そうだったけど、闘病期間も長かったし、悲壮感が軽減されてた感はある。岩田社長はほんと突然な話。
病気にならないためにも運動しないといけませんよね。
2015年7月12日日曜日
遅れるプロジェクト(駄文)
1人でやるプロジェクトが多いのであまり仕事に遅延をだしたことがありません。
1人の責任で、開発計画を立てて、グラからUIからプログラムから音から全てやって、最短経路を通るためツールを作って時短したりですね、頭と図面の上に完成図がきちっとできていて、モチベをもってすればなかなか掌の上に収まる大きさでは仕事というのは遅れないものです。それは受託でも事業計画上の製品でも同じ。
当然それが出来れば、毎日あまりおコメを食べるのに困らない人です。みんなが、そのくらいがんばれば仕事は遅れないのです。だからがんばろー。とか頭に花が沸いてる女子高生みたいなことはいわない。
みんな立場や自負やこだわりや職責や辿ってきた経路や予算や横流しやバックマージンや、息抜きのための突然の京都旅行や同人活動とかがあって複数人のプロジェクトは回りますので、きみら悉く死んでしまえ。
基本として1人で全部できる君がプロジェクトを回す場合どうすればいいかというのを考えてみました。君が1人で全部できるやつじゃなかったら、やられる側の立場として読んで不快感を醸成しましょう。
①粛清
製品の中核業務であれば、あなたは自分でもできるはず、睡眠時間を削ってでも、仕事しないやつの仕事を次々に奪っていく。そのうえで間に合わせて、仕事遅らせたやつはつるしあげに躊躇わない。外注であれば契約違反を頻繁に訴え精神的に追い詰める。きちんとした発注側に有利で厳密な契約書は常に必要。
製品の中核外で君の手に収まらないものであれば、作業が遅れる気配を見せた時点で二箇所に発注をかけ、遅れた会社は即契約不履行とする。
仕事しなきゃ奪われるし、遅れれば、評価が駄々崩れに落ちるということは担当者各自が意識すべきで、世の中不景気で仕事がないので、やりたい人は探せばいるよ。
なお、あなたが責任者で部下から仕事を奪えるほどスキルがないというのであれば、あなたは責任者をおりて現場仕事のできる人間に任せて自分のできることをしましょう。 遅れない現場の話をしています。現場仕事のできない責任者はプロジェクトの遅延の最大要因で、あなたは現場を邪魔にならない方向で支援すべきです。
外注についての対応は、ブラックですね。でも仕事遅らせて、遅れた分金よこせとか、おっしゃられる外注さまが多すぎると思いますよ、実際。無駄金使わないためには訴訟上等でいくしかありません。どちらがどれだけブラックかという話ですよね。
②効率化
システムやプログラムにできることはシステムやプログラムに任せるべきで現代はシステムやプログラムの時代なんですよ奥様。これをシステムやプログラム作る人すら理解してない現場で何を効率化しろという話で、まずは全ての業務をシステムやプログラムで無駄をなくすことに注力すべきです。
さて、効率化できるのは繰り返し作業と大量のチェック作業、大量のオブジェクトの管理などでございます。
画像に1000枚、同じ加工いれましょうとかでPhotoshop持ち出したり、ソースコードを共有フォルダにいれておきましたとか、テキストを頭から読んで用語ぶれチェックしだすのとか、シナリオをワードファイルで納品するとかは駄目です。ただしく効率化すれば100倍効率差が出ます。ちゃんと効率化しないと効率化してるところに敗北します。
繰り返し作業はプログラムでやることで手間が省けるほか、再現性、可用性ができるという利点もあります。
1つの仕事を30回以上やる必要があり総工数が1時間を越える見込みがある時点でなんらかの効率化は考えるべきです。そして費用対効果に見合うのであれば実施しましょう。
1000回やる作業が1回1分かかるところを、効率化してボタンを押すだけで自動で処理されるようにすればそれは1000分の時短で、2日分稼げることになります。たいていそんな処理は1~4時間程度で組みあがります。やらなかったときに比べて最小でも4倍の効率化でそのほかにも継続的な利利点があります。
また社内はきちんと情報化しなくてはなりません。
メールチェック忙しくて出来ないメール多すぎるとかも聞きますが、それは職責の分散の問題となります。あなたが1人で管理しすぎで、あなたは職責の分散や対人関係のコントロールができてない人なのです。
でこれらは簡単なスクリプト言語と正規表現、テキストファイル処理、ソースコード管理システムの扱い、コミュニケーションツールの扱いくらい覚えれば中学生でもできるので、この程度覚えない人とか他人に押し付けようとする人は冷遇もしくはいろいろ検討する対象でいいんじゃないかな。この点は教育にもつながります。
③モチベーションの問題
よくみる失敗事例というか、これが発生するシステム系の会社やプロジェクトはこけるという話。
企画とシステム開発が分断していて、システム開発者が工数見積もりを出す状態。これは多くの場合、外注作業にも当てはまる。企画、システムを統合するプロマネが存在するか、企画がシステムのことを工数管理レベルでよくわかっている必要がある。
システム開発者は君ら企画が作りたいと思ってるもんなんて微塵も作りたくないですし、せいいっぱい手を抜きたいんですよ。なんでかっていえば、作られるものにも、プロジェクトの遅延にも予算にも微塵も興味ないから。
そこをして、宇宙人とか別世界の人みたいな感じで、いろいろなやりとりを諦めるので、会社が傾きます。興味とモチベのある企画者がシステムの開発つか工数管理程度までは興味もってやるべきなのです。
自分がエンジニアでもありますので言いようにいいますが、中小にいる、エンジニアなんて大抵糞ですよ。理系どころから文学部卒とか、◎京◎ード学園卒ですよ?
企画とエンジニアを別クランにするのにあまり意味はありません、相互に侵食してるべきだと思います。そうしてないとプロジェクトやノウハウの集積に重大な影響を及ぼします。プログラム使ったものでメシくってるかぎりこれは避けられません。
ただエンジニアについては研究職というのは検討されるべきです。モチベーションというか、企画とエンジニアの対立的な話になりましたがそれをさしおいてもモチベーションは大事でございます。
糞長い日記になりましたが、まあなんというか仕事が遅れるのはひとつに手前が仕事してない、効率化とか、必要な勉強してない。ということに落ちるのでございます。
忙しいあなたは忙しくなくなるありとあらゆる努力をしてなお忙しいのですか? 仕事は遅れるのは構わないのですが、そもそもこれに対して遅れるといえるまでの、詳細な予定はありましたか?外注さんの遅れる気配は中間地点で察して掌握するようにつとめましたか?
これはなんというか匿名ブログで偶然駄文を目にして不快に感じられてる方に申し上げてるわけではなく、どちらかというと自分自身にいってるのですよとかいうとお茶濁しになりますでしょうか。仕事を遅らせないよう頑張りましょう。
1人の責任で、開発計画を立てて、グラからUIからプログラムから音から全てやって、最短経路を通るためツールを作って時短したりですね、頭と図面の上に完成図がきちっとできていて、モチベをもってすればなかなか掌の上に収まる大きさでは仕事というのは遅れないものです。それは受託でも事業計画上の製品でも同じ。
当然それが出来れば、毎日あまりおコメを食べるのに困らない人です。みんなが、そのくらいがんばれば仕事は遅れないのです。だからがんばろー。とか頭に花が沸いてる女子高生みたいなことはいわない。
みんな立場や自負やこだわりや職責や辿ってきた経路や予算や横流しやバックマージンや、息抜きのための突然の京都旅行や同人活動とかがあって複数人のプロジェクトは回りますので、きみら悉く死んでしまえ。
基本として1人で全部できる君がプロジェクトを回す場合どうすればいいかというのを考えてみました。君が1人で全部できるやつじゃなかったら、やられる側の立場として読んで不快感を醸成しましょう。
①粛清
製品の中核業務であれば、あなたは自分でもできるはず、睡眠時間を削ってでも、仕事しないやつの仕事を次々に奪っていく。そのうえで間に合わせて、仕事遅らせたやつはつるしあげに躊躇わない。外注であれば契約違反を頻繁に訴え精神的に追い詰める。きちんとした発注側に有利で厳密な契約書は常に必要。
製品の中核外で君の手に収まらないものであれば、作業が遅れる気配を見せた時点で二箇所に発注をかけ、遅れた会社は即契約不履行とする。
仕事しなきゃ奪われるし、遅れれば、評価が駄々崩れに落ちるということは担当者各自が意識すべきで、世の中不景気で仕事がないので、やりたい人は探せばいるよ。
なお、あなたが責任者で部下から仕事を奪えるほどスキルがないというのであれば、あなたは責任者をおりて現場仕事のできる人間に任せて自分のできることをしましょう。 遅れない現場の話をしています。現場仕事のできない責任者はプロジェクトの遅延の最大要因で、あなたは現場を邪魔にならない方向で支援すべきです。
外注についての対応は、ブラックですね。でも仕事遅らせて、遅れた分金よこせとか、おっしゃられる外注さまが多すぎると思いますよ、実際。無駄金使わないためには訴訟上等でいくしかありません。どちらがどれだけブラックかという話ですよね。
②効率化
システムやプログラムにできることはシステムやプログラムに任せるべきで現代はシステムやプログラムの時代なんですよ奥様。これをシステムやプログラム作る人すら理解してない現場で何を効率化しろという話で、まずは全ての業務をシステムやプログラムで無駄をなくすことに注力すべきです。
さて、効率化できるのは繰り返し作業と大量のチェック作業、大量のオブジェクトの管理などでございます。
画像に1000枚、同じ加工いれましょうとかでPhotoshop持ち出したり、ソースコードを共有フォルダにいれておきましたとか、テキストを頭から読んで用語ぶれチェックしだすのとか、シナリオをワードファイルで納品するとかは駄目です。ただしく効率化すれば100倍効率差が出ます。ちゃんと効率化しないと効率化してるところに敗北します。
繰り返し作業はプログラムでやることで手間が省けるほか、再現性、可用性ができるという利点もあります。
1つの仕事を30回以上やる必要があり総工数が1時間を越える見込みがある時点でなんらかの効率化は考えるべきです。そして費用対効果に見合うのであれば実施しましょう。
1000回やる作業が1回1分かかるところを、効率化してボタンを押すだけで自動で処理されるようにすればそれは1000分の時短で、2日分稼げることになります。たいていそんな処理は1~4時間程度で組みあがります。やらなかったときに比べて最小でも4倍の効率化でそのほかにも継続的な利利点があります。
また社内はきちんと情報化しなくてはなりません。
メールチェック忙しくて出来ないメール多すぎるとかも聞きますが、それは職責の分散の問題となります。あなたが1人で管理しすぎで、あなたは職責の分散や対人関係のコントロールができてない人なのです。
でこれらは簡単なスクリプト言語と正規表現、テキストファイル処理、ソースコード管理システムの扱い、コミュニケーションツールの扱いくらい覚えれば中学生でもできるので、この程度覚えない人とか他人に押し付けようとする人は冷遇もしくはいろいろ検討する対象でいいんじゃないかな。この点は教育にもつながります。
③モチベーションの問題
よくみる失敗事例というか、これが発生するシステム系の会社やプロジェクトはこけるという話。
企画とシステム開発が分断していて、システム開発者が工数見積もりを出す状態。これは多くの場合、外注作業にも当てはまる。企画、システムを統合するプロマネが存在するか、企画がシステムのことを工数管理レベルでよくわかっている必要がある。
システム開発者は君ら企画が作りたいと思ってるもんなんて微塵も作りたくないですし、せいいっぱい手を抜きたいんですよ。なんでかっていえば、作られるものにも、プロジェクトの遅延にも予算にも微塵も興味ないから。
そこをして、宇宙人とか別世界の人みたいな感じで、いろいろなやりとりを諦めるので、会社が傾きます。興味とモチベのある企画者がシステムの開発つか工数管理程度までは興味もってやるべきなのです。
自分がエンジニアでもありますので言いようにいいますが、中小にいる、エンジニアなんて大抵糞ですよ。理系どころから文学部卒とか、◎京◎ード学園卒ですよ?
企画とエンジニアを別クランにするのにあまり意味はありません、相互に侵食してるべきだと思います。そうしてないとプロジェクトやノウハウの集積に重大な影響を及ぼします。プログラム使ったものでメシくってるかぎりこれは避けられません。
ただエンジニアについては研究職というのは検討されるべきです。モチベーションというか、企画とエンジニアの対立的な話になりましたがそれをさしおいてもモチベーションは大事でございます。
糞長い日記になりましたが、まあなんというか仕事が遅れるのはひとつに手前が仕事してない、効率化とか、必要な勉強してない。ということに落ちるのでございます。
忙しいあなたは忙しくなくなるありとあらゆる努力をしてなお忙しいのですか? 仕事は遅れるのは構わないのですが、そもそもこれに対して遅れるといえるまでの、詳細な予定はありましたか?外注さんの遅れる気配は中間地点で察して掌握するようにつとめましたか?
これはなんというか匿名ブログで偶然駄文を目にして不快に感じられてる方に申し上げてるわけではなく、どちらかというと自分自身にいってるのですよとかいうとお茶濁しになりますでしょうか。仕事を遅らせないよう頑張りましょう。
2015年7月4日土曜日
2015年7月3日金曜日
ソーシャルなお話
- いまさらソーシャルゲームなんて5年は遅れてるよね。
- そもそもDMMなんてどこがソーシャルというほどソーシャル性がないよね、あれはなんだ、ソシャゲーとよんでいいのか。
- 日本ではFaceBook並みにソーシャルゲームがちゃんとできる土壌ってmixiしかなかった。mixiは、あーなんでやめたんだろう。というかみんな離れてくとやめるよね。ソーシャルサイト。あと制御できないおかしな人。
- とにかくZuckerbergはゲームの作る莫大な金と、世界規模のソーシャルサイトを維持することによる支配力を天秤にかけて後者を選んだので賢明。というか後者を優先したことで結局両方手に入れてる。mixiは紆余曲折でゲーム分野で成功したかもしれないけど、うまくいってもその方向は和製Zyngaの道。というかソーシャル要素でなく、コンテンツ頼りなので多少寿命の長いゲームを持ったメーカーでしかない、楽に上澄みで金とれる立場から、アップル、Googleに美味しくいただかれる立場に。
- 残念ながら決着はついてる。日本でも、ソーシャルしようとしたら、もはやFb使うしか手立てがない
- というかmobage、greeもそうだったかもしれないけど、mobage、greeはソーシャルサイトとしてはちょっとあれだったよね。
- 結局あれじゃんゲーム内でつながりとかギルドとか作ってるじゃないか。
- そしてその仕組みのせいで大手の囲みこいが強烈に促進されてるんじゃないかね
- ゲーム内でつながり作るの禁止すればよかったと思います、長期的に見ればそっちの方が友達と遊ぶ、出会い系サイトとしては優秀
- いや出会い系になったらいけなかったんだっけ、ってあれソーシャルってなあに?
- われわれはFaceBookの学歴職歴入力欄を熱烈に忌避し、薄い繋がりを求めてTwitterに赴きそこで分散し希薄化するものだ
- ソーシャルなんてと作り手はみな心の隅っこで、作ってる本人たちも馬鹿にしてるが市場規模がアプリ含めるとコンシューマー100%として、250%になってる。ちなブラゲー全体とコンシューマー全体がトントン。
- 5年まえはまだ未成熟だったし、アプリのがいけると感じていたし、実際そうなったが、来年あたりからはHTML5のスマホでの表現力がWEBGLの標準化でえげつないことになるはずで、フロントエンジニアを殺害する気で頑張ればよいものができそう。
- というわけで、素人遊びの延長のウェブソーシャル事業がバカバカ潰れて、その後多少の余白をもってして、コンシューマーよりは参入しやすい程度の規模感で、またウェブ系のモバイル事業が回りだすんじゃないかなと愚考しております。
- ちな5年前からPCのブラウザはもうえげつないことになってた。
- 今の日本のブラゲーがひどいい方すれば、たいしたことないのは単純に作り手の問題。
- 海外のサイト検索すればすげえのがごろごろひっかかりますよ。技術デモといえばそれまでだけど。
- PCゲー並に作りこめるレベルにブラウザ技術はきているし、バックエンドに費用対効果が見合えば無制限のリソースを持つことができ、変更内容を即時更新もできるのだ。
2015年3月2日月曜日
Google App Engineの最近
- ここ半年くらいApp Engineをまた使ってサーバアプリを作ってる
- 値上がりから最近はまた値下げ
- こつをつかむとなんかとてもお安くアプリケーションサーバーというか、アクセスの激しいサイトを運営できてお得な感じだ。
- とりあえず今日理解したコツは大量のレコードを扱う処理はDataStore Small Operationsにおしこむようにすること。
- 有名なSlim3もでもそうなのだが、countのためにDataStore.getList().getSize()とやると、10万レコードある場合10万レコード分のDataStore Readになってしまい、これが課金に跳ね返る。DataStore.getKeyList().getSize()をカウントの代わりに使うと、これはSmall Operationなので無料。
- つまり、Slim3のModelListRefとかも課金に繋がるので、List<Key>とかList<String>をプロパティにして、必要な要素だけ取り出して、処理したほうが安あがりになる。
- 当時ではそれで構わない理由があった(DataStore.Readが十分安かった)などがあるはずで、あれだがまあ5年もたつと調べなおさないと色々損するなあという所感。
登録:
コメント (Atom)