例えば、以下を見比べてみて欲しい。どちらの方がお買い得に見えるだろうか？ たったの３万円で１年間使い放題です。１日当たりたったの１００円以下で使い放題です。おそらく、ほとんどの方は後者の方がお得だと感じているだろう。このように、同じ商品でも伝え方を変えるだけでお客様に「お得感」を持ってもらうことができる。 このPAD効果は、継続性を持った商品であれば、会員権だけではなく様々な商品に適用することができる。例えば、以下のように、、、。 健康食品：１食当たり○○円サプリメント：１回当たり○○円マーケティングソフトウェア：１日当たり○○円コンサルティングサービス：１日当たり○○円英語教室：１回当たり○○円etc重要なのは、商品自体を安く見せることではなく、お客様が、「この価格で、これだけの効果が得られるなら安いものだ」と思って頂くということだ。つまり、商品を納得して買って頂く上で重要なのは、価格そ
本日、本家のmrubyに mrbgemsが pull-up されたので、mrbgemsの使い方について簡単にまとめておきます。 mrbgemsとは mrbgemsとは、mruby拡張ライブラリを簡単に組み込むことができる仕掛けです。crubyのgemと考え方は近いですが、mrubyの場合は機器やアプリへの組み込みが主体なので、ランタイムではなくビルドタイムに拡張ライブラリを組み込みます。 使い方 本家mrubyにmrbgemsが組み込まれはしましたが、現在のところ本機能はdefault disableになっています。mrbgemsを有効にするには、以下の箇所を書き換える必要があります。 Makefile(追加) export ENABLE_GEMS = trueinclude/mrbconf.h ... #define DISABLE_GEMS /* Package Manager mrb
Garbage Collection Advent Calendarの8日目(!!)の記事です。 gc.cの最初のほうのコミットを見るとCOPYRIGHTがあって、SIOD:Scheme In One Defunという処理系を参考にまつもとさんはCRubyのGCを実装されたみたいなんですね。 /gc.c - ruby-trunk - Ruby Issue Tracking System この当時はスッキリしたソースコードですね。 SIOD - Wikipedia, the free encyclopedia SIOD: Scheme in One Defun SIODは公式サイトなどを読むと1988年にリリースされ、最後のリリースが2007年、と。 30年も続いてんのかあ。 で、wikipediaには以下のように書かれていますね。Scheme In One Defun (or Scheme
前回の記事 MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか の続きです。 master : slave = 1 : 1 で参照を slave に分散してもまったく美味しくないわけですが、では参照の負荷分散を行いたい場合の slave は何台で構成するとよいのか考察してみます。具体的には slave 2台の場合と 3台の場合でどちらがお得か。 台数を増やすということは、どこかに障害が発生する確率が高まる、ということです。1台の slave に障害が発生してダウンした場合のことを考えてみます。 slave * 2 → 残り 1台で処理継続 生き残った1台あたりの処理が 2倍になる slave * 3 → 残り 2台で処理継続 生き残った1台あたりの処理が 1.5倍になる たとえば 1台あたり最大 1000qps の処理能力があるとします。sla
「ウェブオペレーションエンジニアはリリース前のソースコードのココを見る！」みたいな記事があればいいね — masahiro nagano (@kazeburo) November 20, 2012 ちょいと前にツイートしたこの件のまとめ。新規サービスのリリースや既存サービスに新しい機能が追加される際に、しばしばそのソースコードを確認しているのですが、僕がどんなところを見ているのかまとめてみました。 そのサービスへの導線とランディングページの確認 まず、そのサービスへの導線やランディングページを確認します。そしてその一番アクセスがあろうページ、一つか二つに確認対象を絞ります — masahiro nagano (@kazeburo) November 20, 2012 どんな素敵なサービスも、機能も適切な誘導がなければ使われる事はありません。また誘導次第では大量のアクセスが一度にサーバに対し
MySQLのmasterとslave 1:1にして参照をslave向けるのってやりたがる人多いみたいだけど、性能たいして上がらない割に可用性落ちるだけだからやめようキャンペーン 2011-06-19 00:16:30 via YoruFukurou MySQL はレプリケーションが簡単に構成できるのですが、時折 master 1台 に対して slave 1台、更新処理は master に、参照は slave に、という構成を目にします。 個人的にはこの構成はお勧めでないと思っているので、その理由を考察してみます。 1. 可用性が落ちる 当然ですが、master, slave のどちらが落ちても影響を受けるために可用性が低下します。 2. 全体の性能がほとんど上がらない master 1台ですべてのクエリを処理する場合と比べて、可用性が落ちる引き換えとして見合った性能向上が得られるか、という
2020年8月31日(月)をもちまして、nanapiに関わるすべてのサービスは終了いたしました。 nanapiは、2009年のサービス開始より「みんなで作る暮らしのレシピ」という考えのもと、ユーザーの皆さまに生活に関する様々な「ハウツー」を投稿していただく投稿型ハウツーサービスとして運営してまいりました。 約11年間にわたって皆さまからご支援をいただきサービスを継続できたこと、nanapi編集部一同、心より御礼申し上げます。 掲載されていたコンテンツなどのnanapiについてのお問い合わせは、nanapi@supership.jp までお願いいたします。 長きに渡りnanapiを応援してくださり、本当にありがとうございました。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
