ウェブサービス企画書供養その1: Facecards

VALUというサービスをTechCrunchで発見し、共感すると共に以前コンペ(就活)で企画を練ってた関連しそうなウェブサービスを思い出したので供養ついでに公開。

シナリオ例やビジネスモデルは完全に忘れてたけど、今読んでも結構面白かった(自画自賛)。今突っ込めと言われた死ぬほど突っ込めるけれど…。

ちょこっとスライド紹介

背景

要はこの頃クラウドファンディングが流行ってたんだけど、自分は紐付きじゃないお金が欲しかったので考えた(ゲス)。&ソシャゲのカードは仮想価値だけどたくさん投資されてるよね&それをもっと個人をエンパワーするために使っていこう&若い世代へ価値を転化してもいいのでは。

f:id:anoworl:20170604013016p:plain

ユーザシナリオ

個人を応援するという意味ではVALUに似ている。カードなのはソシャゲから。

f:id:anoworl:20170604013106p:plain

ビジネスモデル

1はJASRAC儲かってていいな!っていう感じで書いてた。

f:id:anoworl:20170604013233p:plain

SlideShare

おわりに

企画書のフォーマットに落とすと結構考えるので良いなと言う想い!企画書やっていきましょう✊

実在する人間のBOTを作る方法序説

前置き

この記事はDark - Developers at Real Kommunity Advent Calendar 2015 - Adventarに寄せる9日目の記事です。昨日はarataさんのDarkを支える技術 #3 テスト編 - 日頃の行いでした。この記事は《闇》【Dark】を意識して書かれたものです。

この記事では実在する人間のBOTをSlack上に作り、一年間にわたってメンテナンス、運用した実例をご紹介します。

この記事で分かること

  • 実在する人間のBOTの一年にわたる運用例

この記事で分からないこと

なぜ作ったか

インターネットにへんてこさんという人物がいます。その人物が発する言葉はあらゆる文脈に適用可能で汎用性があり、またユーモアに長けていました。それはまるで磨き抜かれた珠玉がほろほろとネット上に紡ぎだされているようでした。私はその零れ落ちた珠玉が流れ去ってしまうのを見過ごしてしまうことが出来ず、その珠玉を拾い集め再利用する術を探し、BOTを作成するに至りました。

どうやって作ったか

本人に許諾を得る

対象となる人物をコンテンツ化することになるので、本人にまず許諾を取りました。これもただ許諾を取ったら終わりではなく、BOTに手を加える際には対象となる人物が嫌ではないか一度考えてから行うようにしています。

複数人による発言のキュレート、保存

このBOTを作るのに必要なのは、何よりその人物が紡ぎだす珠玉です。それを集めなければなりません。当初は私がへんてこさんの発言を手作業でキュレートしたものを使っていました。全ての発言を強引に取得し使うことも出来たのですが、へんてこさんも人間であり全ての発言において汎用性がある訳ではありません。そこで、汎用性のある発言を私という人の手を介し選別していました。

しかしこの選別にも限度があり、私が忙しい時、またやる気の無い時に発生した珠玉を集めることが出来ません。また私という見識の浅い一人の人間に依拠してしまうと、取りこぼされてしまう珠玉が存在するという問題もありました。そこでSlackに珠玉を集約するチャンネルを作り、他の人間にも手伝って貰うようにしました。これにより、一人ではモチベート出来ない作業も競争原理でモチベートされると共に、時間ややる気の制約から珠玉の集約作業を切り離し、安定化させることが出来ました。

キュレートにおけるルールの策定

複数人でキュレートを行うと発生するのがキュレートの妥当性です。ここでは実在する人間に許諾を取りその人物を模したBOTを作ったということもあって、その人物が発した発言以外は認めないという方針を取りました。ただその人物が発した発言であればSlackはもちろん、Twitterでも現実世界でも可としました。発言が集約されるチャンネルには、他の人間がソースを確認できるよう、必須ではありませんがソース元のURLやどういった場で発言されたものか付記する文化が醸成されました。

ランダム発言BOTの作成

肝心の集めた発言の使い方です。前述したように発言には汎用性があったので、数時間に一回のペースでランダムに発言を行うようにしました。またこの際一手間加えており、最近キュレートされた発言ほど発言される確率が高くなるように設定しました。これにより内輪ウケはもちろん、キュレートした人のモチベート向上にも繋がったと思います。

雑談APIの使用

ランダムな発言だけではBOTに色が付かないので、NTTドコモの雑談対話APIを使い会話を行えるようにしました。

雑談APIには特に大きなカスタマイズはせずそのまま使用しているのですが、その際にキャラクター設定を「赤ちゃん」にしました。これによりBOTの口調が特徴的なものになり、本人から離れた"BOT"というキャラクター象が生まれ、BOTへの愛着が各人に出来ました。この口調を真似するものも出てきており、BOTの人格形成という意味で非常に役に立ちました。

最後に

誇張ではなく、無くてはならないSlackの一員となるまでBOTは成長しました。今後の成長も期待しています。

カネの力でTwitterアイコンバッジ創るぞ!!!

前置き

この記事はhenteko Advent Calendar 2014の二日目です。昨日の記事は kubo39 さんのhenteko advent calender Day.1でした。

hentekoさんについて

へんてこさんのTwitter IDは @bilyakudan です。なぜ @henteko で無いのかと問うたところ、何か理由があった気がするのですが、忘れました。そのせいで、Twitterアカウントとリアルのへんてこさんが一致するのに時間がかかりました。

バッジを創った経緯

そんなへんてこさんしかり、私はTwitterアカウントとリアルの人を一致させるのが苦手です。そのため勉強会では、みんなの頭の上にTwitterアイコンが浮かんでいたらすっごい便利だなぁと思うことがよくあります。

ではまず自分からということで、勉強会でTwitterアイコンのバッジを付けることにしました。もちろん元々そんなのは持っていないので、カネの力で創りました。その始終がこの記事です。

カネの力でバッジを創る

バッジ屋さんとプランの選定

バッジ屋さんというのは探してみると意外にたくさんあります。料金体系は同人誌の印刷を印刷所さんにお願いすることを考えると想像しやすいです。 以下が選定の際に考慮する点となります。それぞれに注意点を付記しました。

  • 最低作製個数
    • 自分で付ける場合そんなにはいらないのですが、最低作製個数が決まっているところも多くあります。1個から作ってくれる所もあるのですが、1つあたりの値段が高かったり……。
  • 1つあたりの値段
    • 多く作れば作るほど安いです。
  • 送料
  • 形態
    • サイズ
      • だいたいの所が小さいものから大きなものまで複数のサイズを取り揃えています。
      • 丸がスタンダードで真四角に対応してくれている所もあります。私はTwitterアイコンは四角というイメージがあったので、四角にしました。
    • 裏側
      • スタンダードな安全ピン以外に、クリップピンにも対応してくれている所もあります。服に穴を空けたく無い場合はお勧めかもしれません。マグネットやストラップ、キーホルダーにしてくれる所もあります。
  • 納期
    • それぞれ違い、特急作製を行ってくれる所もあります。
  • 品質
    • サンプルを貰える所では貰って確かめるのも一つの手かもしれません。ただそんなに多くは無かった気がします。
    • 私もどうやって注意すれば良いのか分かりませんでしたが、サイト上の説明などを参考にはしました。
  • 対応
    • 名前で検索すると2chなどに口コミがあったりします。

私はsocondpressを選択しました。値段と特急作製の有無、サイトの説明で選びました。最低個数はこの際無視しました。ちなみにこの場合の見積例を以下に挙げます。

●お見積もり内容
・商品
四角形40mm缶バッジ                20個 @    85円 =    1700円
・オプション
特急製作料金                       1個 @   510円 =     510円
送料                               1個 @   850円 =     850円
_____________________________________________
小計                                             3060円
消費税                                            245円
合計                                             3305円

デザインデータの用意

上記を決めたらバッジのデザインを作成します。バッジ屋さんでテンプレートを用意してくれているので、そちらを開いて編集しましょう。だいたい、IllustratorPhotoshopのテンプレートが用意されている気がします。CMYKモードで作成することに気をつけましょう。JPEGに対応してくれている所もあります。

私が作成したデータを以下に示します。

f:id:anoworl:20141202115827p:plain

購入

ぽちぽちです。良い時代になったものです。

届いた

やった!

f:id:anoworl:20141118181803j:plain

自由に楽しみましょう

f:id:anoworl:20141202121159j:plain

後置き

明日は Amothic さんです!

(スープ)カレーはさいきょうのたべもの

前置き

この記事はカレー Advent Calendar 2013 23日目の記事です。昨日の記事はtan_go238さんの空堀の旧ヤム邸にカレーを食べに行ってきました。でした。

(スープ)カレーはさいきょうのたべもの

カレー!!私が自炊においてカレーが最強の食べ物だと確信した経緯をお話します。それは私が大学に入学し一人暮らしあーんど自炊を始めた頃のお話です・・・。

自炊を始めた最初の一週間では、手間の問題からまず素材(じゃがいもや肉、もやしなどを)を蒸すなりチンするなり焼くなりしてそのまま食べていました。しかしさすがに一週間かそこらで素材そのままの味ではキツくなっていきました。もやしを何も付けずに食べるのは非常に大変なものがあります・・・。

次に調味料を買い素材に付けるようになり、更に一週間ほど凌ぐことが出来ました。しかしこの頃調理が面倒になっていました。調理する時にずっと炒めるなりなんなり手を動かさないとならないのは非常に手間だと。

そこで次の一週間では煮込み料理であるポトフを作るようになりました。これは材料を洗って切って全部鍋にぶち込んで煮ればいいので簡単です。ただそれでも面倒なので、一週間分を作り冷蔵庫に入れて毎日少しずつ食べていました。一週間の終わりには飽きてきました。

そして満を持して私の食生活のベストプラクティスが次の一週間に見つかりました。

それは(スープ)カレーです。

一週間の始めにスープカレーを作り冷蔵庫に入れて少しずつ消費していきます。するとスープカレーは数日で水分が少なくなりまるでカレーのようになります。更に週の終わりには更に水分が少なくなりドライカレーのようになります。

スープカレー→カレー→ドライカレー

これが私の自炊における最高の方程式です。 ありがとうございました。

最高のカレーにしようぜ!

以下はせっかくなので今日食べたゴーゴーカレーですが、自分の作るカレーとは違い具が見当たりませんでした。自炊カレー食べたいなぁ・・・。

f:id:anoworl:20131223130031j:plain

後置き

明日はsyo_sa1982さんです!!

カッティングプロッタで羽の様な名刺を創ろう

前置き

FuniSaya Advent Calendar 2013 11日目です!昨日はкёкуさんの荒木良造・著「姓名の研究」を読んだので感想を書いてみた~FuniSaya Advent Calendar 2013 10日目でした!

はじめに

好きなモノは創りたい。私の行動原理。

過程

好きなモノ

これのみゲームのスクリーンショットユメミルクスリより転載。

f:id:anoworl:20131211232114j:plain

きっかけ

f:id:anoworl:20131211232228j:plain

ラフ

f:id:anoworl:20131211232243j:plain

デジタル

f:id:anoworl:20131211232316j:plain

パス化

f:id:anoworl:20131211232413j:plain

テスト出力

f:id:anoworl:20131211223611j:plain

名刺サイズ

f:id:anoworl:20131211232605j:plain

思いつき

f:id:anoworl:20131211232816j:plain

量産

f:id:anoworl:20131211232841j:plain

ふへへ

f:id:anoworl:20131211232913j:plain

かんせー!

f:id:anoworl:20131211232923j:plain

後置き

明日はUSAMI Kentaさんです!

Railsアプリケーションにおけるパフォーマンス測定について調査

背景

Heroku上でRuby on Railsを使い作成したウェブアプリケーションを運用している。しかしアプリケーションの一つの機能である画像のアップロードについてレスポンス時間が長く、ボタンの二度押しや複数同時アクセスがあった時に応答が返ってこないことやアップロードに失敗することがある。そこを解決するためにこのアプリケーションのパフォーマンスチューニングを行うが、定量的な測定が出来なければ改善したかどうかが施策後曖昧になってしまい、目標を達成できたのか(いつどこで施策をやめるのか)、どの施策が有効だったか分からず今後に活かせないことが考えられる。そこでここではRailsアプリケーションにおけるパフォーマンス測定について調査する。

他に参考にした記事

Rails アプリケーションのパフォーマンスについて RubyKaigi 2013 で発表しました | クックパッド開発者ブログ

RubyKaigi 2013で発表されたクックパッドの社員の方によるRailsアプリケーションチューニングについての資料。最近の資料でありRailsを大規模に使っているクックパッドの事例なので、とても資料価値が高いように思われる。

rails/rails-perftest

Rails 4にてgemに切りだされたパフォーマンス測定ライブラリ。

newrelic/rpm

New Relicでの測定が優れているという噂。Developer ModeとProduction Modeで表示される情報が違うらしい。

#368 MiniProfiler - RailsCasts

日本語の資料です。主にSQLクエリのプロファイリングを行うことができます。

#411 Performance Testing (pro) - RailsCasts

RailsCastsの有料記事です。

指標

チューニングする値について

サーバ側でチューニング可能な、リクエストが最後までサーバに辿り着いてから、サーバがレスポンスをクライアントに向けて送信し始めるまでの時間のチューニングを行う。ここではDOMのレンタリング時間や複数のコネクションを張ることによる遅延時間は対象に含めない。またクライアントから送られるデータのサイズによるネットワークの遅延時間も対象とならない。

レスポンスタイム(応答時間)の定義について

例えばクックパッドでは200ms以下にレスポンスタイムを抑える目標を持っていますが、この「レスポンスタイム」とはどのように計測したものなのか、まず考察しました。どうやら先日行われたRubyKaigi 2013でのIssei Narutaさんのスライドを見るに、前項での定義と同じだと思いました。よってここでもその定義に従おうと思います。 ただ一部でクライアントがレスポンスを受信するまでの時間と定めている記事があり、これはネットワークでのデータ送受信にかかる時間が含まれ前述のレスポンスタイムの定義とは異なることから、各々の記事でどのようにレスポンスタイムが定義されているかについては、意識しなければならないと思いました。(情報処理試験における定義ISO/IEC9126における定義についても面白かったです)

実際

Apache JMeterで規定のリクエストを30回行い、サーバ側でレスポンスタイムを測ると共にJMeerでサンプルタイムを測り、それらの値をグラフ化及び平均化し比較及びチューニングを行った。

HerokuのRequest queuingについて調査

背景

Heroku上のRailsアプリで容量の大きい画像をアップロードする際、ボタンを連打するとレスポンスが全然返ってこなくなりました。New Relicを見てみると、Request queueingという処理に50秒ほど取られていることが判明。その解決方法を調べるため、文献を調査しました。

主に参考にした記事

Dynos and the Dyno Manager | Heroku Dev Center

Dynos and requests

A single dyno can serve thousands of requests per second, but performance depends > greatly on the language and framework you use.

A single-threaded, non-concurrent web framework (like Rails 3 in its default configuration) can process one request at a time. For an app that takes 100ms on average to process each request, this translates to about 10 requests per second per dyno, which is not optimal.

Single threaded backends are not recommended for production applications for their inefficient handling of concurrent requests. Choose a concurrent backend whenever developing and running a production service.

Multi-threaded or event-driven environments like Java, Unicorn, EventMachine, and Node.js can handle many concurrent requests. Load testing your app is the only realistic way to determine request throughput.

推測

要はUnicornに切り替えれば良い気がしました。

以下は他に参考にした文献です。結構面白い。

他に参考にした記事

HTTP Routing | Heroku Dev Center

Request queueing

Each router maintains an internal per-app request queue. For Cedar apps, routers limit the number of active requests per dyno to 50 and queue additional requests. There is no coordination between routers however, so this request limit is per router. The request queue on each router has a maximum backlog size of 50n (n = the number of web dynos your app has running). If the request queue on a particular router fills up, subsequent requests to that router will immediately return an H11 (Backlog too deep) response.

Simultaneous connections

The herokuapp.com routing stack allows many concurrent connections to web dynos. For production apps, you should always choose an embedded webserver that allows multiple concurrent connections to maximize the responsiveness of your app. You can also take advantage of concurrent connections for long-polling requests.

Almost all modern web frameworks and embeddable webservers support multiple concurrent connections. Examples of webservers that allow concurrent request processing in the dyno include Unicorn (Ruby), Goliath (Ruby), Puma (JRuby), Gunicorn (Python), and Jetty (Java).

Request Timeout | Heroku Dev Center

Request queueing efficiency

Request timeouts can also be caused by queueing of TCP connections inside the dyno. Some languages and frameworks process only one connection at a time, but it’s possible for the routers to send more than one request to a dyno concurrently. In this case, requests will queue behind the one being processed by the app, causing those subsequent requests to take longer than they would on their own. You can get some visibility into request queue times with the New Relic addon. This problem can be ameliorated by the following techniques, in order of typical effectiveness:

  • Run more processes per dyno, with correspondingly fewer dynos. If you’re using a framework that can handle only one request at a time (for example, Ruby on Rails), try a tool like Unicorn with more worker processes. This keeps your app’s total concurrency the same, but dramatically improves request queueing efficiency by sharing each dyno queue among more processes.
  • Make slow requests faster by optimizing app code. To do this effectively, focus on the 99th percentile and maximum service time for your app. This decreases the amount of time requests will spend waiting behind other, slower requests.
  • Run more dynos, thus increasing total concurrency. This slightly decreases the probability that any given request will get stuck behind another one.

Heroku | Better Queuing Metrics With Updated New Relic Add-On

Heroku Queuing Time, Part1: Problem | Railsware Blog