「サービス」の記事 - Crieit

Scrapyはスクレイピング処理を構築するフレームワークで、かなり便利でした。
スクレイピングやるのにフレームワーク使ったのは初めてです。
個人的に便利だと感じたポイントです。
* クロールしたデータをローカルにキャッシュし、再クロール時はキャッシュを参照してくれる
* 開発時に何度もサイトにアクセスすることを防げます。
* もちろん保存期間は設定ファイルで自由に設定可能
* CSSセレクタでデータを取ってきて、データ加工して、保存するみたいな流れがFWで定義されていて、処理の共通化や追加が楽
* 個人的にPythonで書いたコードは読みやすい（対js比）

データのタギング

スクレイピングで取得したテキストデータからタグを抽出したいというものなのですが、ちょっと試行錯誤しました。

実験して没にしたもの

NTTコミュニケーションズ製のCOTOHAのキーワード抽出API

取得結果が私のほしいものに合わなかったので見送りました。

例：「【リモート可】アパレル業界から医療関係まで、お客様の「強み」を最大限に生かすシステムの受託開発をするバックエンドエンジニアを募集！」

取得したいタグ：
* エンジニア（または、バックエンドエンジニア）

COTOHA　APIだと↓
1. 募集
2. 強み
・・・

まあ、文章的には何かを募集する文章だから、「募集」が1番強いキーワードだよな、なるほどと思いました。用途が違う使い方のようです。

採用したやり方

スクレイピングしたテキストデータをmecab（neologd辞書利用）で形態素解析
形態素解析した結果の語をもとに2gramで語抽出
人力で用意した辞書（キーワードと付与するタグの一覧）のキーワードに、上記で抽出した語が完全一致でヒットした場合に、タグ付与

泥臭いやり方になってしまってますが、こんな感じで頑張ってみました。辞書は日々メンテナンスしています。

今思うと...、neologdは単語には強い一方で細かく分割されない特徴があります。今回は分割した語に対して、さらに2gramでくっつける処理を入れているので、形態素の段階では細かく分割された方がいいような気がしました。neologdやめたほうがいいかもな。

全文検索 ⇒ Elastic Search（Elastic Cloud）

私はケチなので、サービスの運用は無料にこだわっているのですが、ElasticCloudを採用しました。ElasticCloudに無料枠はありません。最低16ドル／月で利用できて、副業サーチの構成だと19ドル／月です。と言いますか、ElasticCloudはインスタンスを立てるリージョンを選択する必要があり、東京リージョンの最安構成が19ドル／月です。

Elastic Cloudを採用するまで

ケチなので、サービスのアイディアが浮かんだときからElasticCloud使ったろと考えたわけではありません。

firestoreで実現できないか試した

まずは、いつも使っているfirestoreでできないか考え、データを突っ込んで検索処理を動かして画面で確認するところまで実装してました。
Firestoreで全文検索を実装する方法は、こちらのQiita記事の方法を使ってます、

実現したいこと	実現可否	備考
全文検索	○	Qiitaの方法で実現可能
全文検索 + タグ絞り込み（and）	○	Qiitaの方法で実現可能
全文検索 + タグ絞り込み（or）	×	無理（or検索の仕組みがない）
全文検索 + ソート	×	無理（全組み合わせの複合インデックスが必要）
全文検索 + 関連タグ取得	×	悩んだがいい案思いつかない

実現したいことは以下

全文検索 + ソート
- 検索結果を新しい順（案件の公開日順）で表示したい
全文検索 + 関連タグ取得
- 検索ヒットしているデータについているタグを取得したい
- できれば、タグに紐づくデータの多い順で取得したい

実際にやりたいことを検証してみて、できないこと多かったので、厳しいなぁと感じました。

代替のサービスを探す

私は技術力が高くないので、自分でサーバを立てて、全文検索エンジンをインストールしてみたいなのは無理だと考え、最初から除外しました。サーバーレスでやれるサービスがないか検討しました。

そうなると、候補は以下2つしかない？のかなと
* Elastic Cloud
* Algolia

Algoliaは別サービスでも使った実績があったのですが、今回はElasticCloudにしました。理由は「料金が安い」と思ったからです。Algoliaは無料枠はあるのですが、無料枠使いきると従量課金で、レートがかなり高い..私のサービスでAlgolia使ってるものもありますが、検索がメインのサービスではなく補助機能で使っている程度なので、無料枠に収まってました。

しかし、今回のサービスは検索が命のサービス。無料枠に収まらなくなったら地獄だと考え、月19ドルを払う決心（と妻への説明）をしてElasticCloudを採用しました。ElasticCloudは14日間の無料体験ができるので、それを利用して、実現したいことが実際にできるか動かして試し、全部できるじゃん！と確認できたので採用となったわけです。

フロント（検索UI・記事） ⇒ Gridsome

あまり使ってる人を聞かないのですが、Vue.js製の静的サイトジェネレータ「Gridsome」を使ってみました。React製静的サイトジェネレータで人気のGatsbyのVue.js版のようなフレームワークです。

Gridsomeを見つけたきっかけは、運営者ギルドの方がGatsbyを紹介してくれてたことでした。Gatsbyによって静的サイトジェネレータの存在を知り、これは便利そうだなと調べてたところ、自分が普段使っているVue.js製のGridsomeを見つけたという流れです。

採用した理由

今までいくつかサービスをリリースしてきましたが、どれもVue.js製でSSRなしで構築していました。Nuxt.jsも使った経験なし！

サービスを運用して毎回課題に感じるのが、SEOで弱いことです。

もちろんGoogleのクローラーはJavascriptの実行結果を評価しているというのを知っていますし、信じているのですが、事実としてSEO弱いと感じてます。（フレームワークの問題ではなく、私のサイトのコンテンツの問題な気もしますが）

この不安を今回は無くしたいと考え、静的サイトジェネレータ「Gridsome」に手を出しました。

といっても、検索部分は静的サイトじゃない。トップページと記事系のみ！

検索ページ以外が静的サイトになりました。
中途半端です。
しかし、記事系だけは完全に静的サイトになったので、ページの表示も速く満足しています。
トップページも静的サイトになっています。
SEOを意識した記事を追加していけば、なんとかなるはずだ。（記事が書ければ...）

記事系のページの表示は爆速になったので、ぜひ表示してみてくださいね！

でも、横断検索サービスのSEOって検索ページで狙うべきじゃね？って思うようになってきて、微妙な対応だったかなと思ったりしています。

記事のCMSはContentful

ヘッダレスCMSのContentfulを使ってマークダウンで書いてます。個人開発なら無料枠で大丈夫そうです。無料枠だと1アカウントしか作れないので、チームで運営する場合は問題になりそうです。
Contentfulの記事をGridsomeに連携する構築については、Qiitaのこちらの記事を参考にしました。

Gridsomeにしてどうだったか？

SEO効果は分かりませんが、ページの表示は速いので満足しています。

ただ、ビルドすると思った通りに動かないことがありました（ビルド前は問題ないのに!）。ビルドした後のテストがけっこう重要で、うまく動作しないパターンに慣れるまではそこが面倒かもなと思っています。

さいごに

色々と調べつつ利用する技術を選定して構築しました。今回は新しい技術けっこう使った気がするなぁ。
ElasticCloudとGridsomeはかなりいい選択だったのではないかと思ってます。運用してみて見えてくる点もあると思いますので、なにかあれば記事にしたいと思います。

それでは副業サーチをよろしくお願いします！

ドラフト風画像作成サービス「ドラフトなう！」を作りました

2019-10-21T09:22:17+09:00

ドラフト風画像作成サービス「ドラフトなう！」

「ドラフトなう」とは

ド　ラ　フ　ト　会　議　が　終　わ　っ　て　し　ま　い　ま　し　た　が、
フォームに必要な項目を埋めるとドラフト会議風の画面が作れます。
本家リポビタンDのサイトは12球団からしか選べないのでオリジナル球団から選べるといいなと思って作りました。

今回はキャンバスを使って画像化までは時間がなくて実装できなかったので、
現状スクリーンショットを撮って楽しんでいただければ幸いです。

製作に関して

使った技術

ReactJS
CreateReactApp

製作期間

2019/10/16(ドラフト会議前日)
- 仮リリース
2019/10/17(ドラフト会議終了後)
- レスポンシブ対応

苦労した点

仮リリースの段階では背景に作った画像を使っていたが、レスポンシブで意図した通りに拡大縮小できなかったため、スタイルで全て書き直した。
レスポンシブの実装をメディアクエリを使って行なったが、境界部分でUI崩れがなかなか解消できずに苦労した。
ブランドロゴはなかなかうまくできたと思ったが、これもレスポンシブ対応が厳しく、最終的に画像化した。

教訓

季節系のイベントサービスを作る時は事前にきちんと計画を立てましょう。
前日の朝にこれ作りたいなと思って案の定間に合いませんでした。

レスポンシブ対応がドラフト会議終了後の実装になってしまったため、
モバイルユーザがUI崩れでサイトを離れてしまった可能性がありました。

今回間に合わなかった機能

OGP芸
- バックエンドサーバを用意していないので、技術的に難しいかも。
画像化(Canvas描画)
SNSシェア機能

サービス10個作ったら、１個くらい一瞬バズると思って開発してる。

2019-07-02T14:44:18+09:00

最近Twitterをちょこちょこ利用するようになって、僕が想像していた以上に多くの人が自分のサービスを作っていることを知りました。

勉強がてら作った小さいサービスから、ハイクオリティで大きなサービスまで、本当に多種多様なサービスが公開されていました。ただ、自分が作ったサービスでお金を稼ごうと考えている人はそんなに多くないと感じました。

自分でプログラムが書ける人の最大のメリットは、0円で自分のサービスを作ることができるということだと僕は思っています。だから独学で僕はプログラミングを勉強したし、インターネット上にこれだけ多くのサービスが溢れているんだと思います。

僕は２年ほど前にHTMLすら知らない状態で漫画投稿サイトを運営してみたいと思い、web系の受託会社に見積もりを出したことがありますが、その時はざっくりと500万円くらいとの回答が返ってきました。また、搭載する機能は制限されますが、既存のオウンドメディア構築ツールをカスタマイズして簡単な漫画サイトを作ったとしても130万円ほどかかると言われました。

130万円であれば何とか払えない額ではありませんでしたが、HTMLも知らなかったため、運営している中で小さなデザインの変更でも業者に頼むことになることを考えると、プログラマーを雇うお金がない自分には無理と考え諦めました。

そこから、雇うことはできないけれど、無給で僕が作りたい漫画のサービスに共感し、手伝ってくれるプログラマーはいないものかと、様々なイベントに参加して探してみました。でも無給で一緒に手伝ってくれる人はいませんでした。みんなその場では「良いね！」と言ってはくれましたが、実際手伝ってくれるかというとみんな言葉を濁して去って行きました。

それでも自分の考えているサービスを作りたかったので悩んだ結果、「お金はないし作ってくれる仲間もいない、さてどうするか....」→「自分で作るしかない!」となり、自分でプログラミングの勉強を始め、サービスを作り始めました。

ここで自分でサービスを作る決断をしたことは今考えて本当によかったと思っています。 プログラミングを覚えて自分でサービスを作ることができれば、必要なのは自分の時間だけです(Time is moneyではありますが...)。ほぼ0円で自分の考えたサービスを形にできるため、何回でも失敗することができます。

サービスが当たる確率なんてものすごい低いです。自分が考えた１つめのサービスで当てるなんて神業だと思います。でも10個サービスを作ったら、１つくらい当たるとは思いませんが、一瞬バズったりすることはあるんじゃないかと思っています。

もちろん最初から失敗すると思いながら開発をしているわけではありませんが、失敗しても大丈夫なよう、リスク回避をすることは大事だと思います。今後もしばらくは広告費は最小限に抑え（ってかお金が単純にない）、コツコツサービスを作って、宣伝して、壊してを繰り返していこうと思っています。

また、今まで一人でサービスを開発してきましたが、やっぱり誰かと一緒に共同で開発するのもしてみたいです。個人開発は自分の好きなようにできる反面、モチベーションの維持が難しいですし、複数人での開発の方が新しいアイデアが生まれやすいです。誰か一緒に面白いサービスを作りたいという人がいましたらぜひ連絡ください。

それにしても、本当にTwitterをみてるといろんな個人開発のサービスがありますね。ただ、大部分のサービスが勉強の一環としてだったり、就職、転職のポートフォリオのために作ったサービスだったりして、作って終わりというパターンがとても多い気がします。

作るだけ作ってそのまま放置するようになる気持ちはめちゃめちゃわかります。自分もサービスを作るだけ作って、そこで満足してしまって放置してしまうことばかりやっています。

特にto C向けサービスはユーザーを集めるのが難しいと痛いほど感じています。宣伝にかける予算が豊富にあれば、まだユーザーの獲得はそこまで難しくないですが、予算がない、かつ、影響力もない個人にとってto C向けサービスの宣伝はこの上なく難しいです。

ただ、なんかどうしてももったいないなと思ってしまいます。作ったサービスを誰かが使ってくれたらそれだけでみんなめちゃくちゃ嬉しいはずです。でも現実は誰も使ってくれないから絶望して、宣伝をやめて放置することになっていく。「開発→宣伝→ユーザー集まらず絶望→放置」のループを出来るだけ抑えるように何とかできないものですかね。

開発会議のような個人開発を盛り上げるプラットフォームはありますが、まだまだそのようなプラットフォームの数が少ないように感じます。

開発会議

今後も個人開発で生まれたサービスはどんどん出てくると思うので、それらを積極的に宣伝してくれる場所がたくさん出てくれば嬉しいです。開発会議みたいなサービスがどんどん盛り上がり、個人開発がプログラマー界隈だけでなく、一般的にもっと認知度が広まれば良いなぁ！

セールサーチというサービスをリリースしました

2019-04-30T22:10:22+09:00

2019年4月30日。今日は平成最後の日です。そんな日に新しいWebサービスをリリースしました。
「セールサーチ」というサービスです。

セールサーチってどんなサービス？

楽天やAmazonなどのネットショップのセール情報を横断検索できるサービスです。カレンダー形式にも表示することができます。
「いつものお買い物をちょっと賢く」をテーマに、複雑なネットショッピングのセール情報を少しでも分かりやすくユーザーに提供できればなと思い開発しました。

実は本業で使えるなと思って作ったという理由もあります

わたしはEC関連のWebサービスベンチャーで企画を担当しています。セールサーチは本業でもあったら便利だなと思って作ったという側面もあります。

一般ユーザーはお買い物をする前にお得なセールやっているショップを探すという使い方を想定していますが、実は私は真逆の使い方をしたいなと思ってます。私の場合は、自社サイトのトラフィックの動きと他社ECのセール状況というのを関連付けて分析とかするシーンが割とあるので、その際に使いたいなと思ってます。つまり、事後に何があったかをパッと見で分かるというのがやりたいなと。それだけでなく、色々なECサイトがあの手この手で魅力的なセールを企画してきますので、その調査にもなるなと。そんな感じです。ただ、本業で使えるようにするには情報の蓄積が重要なので頑張って開発とか運営とかやっていきたいと思います。

今度こそグロースしたい

1月末くらいに平成年表というサービスをリリースしたのですが、残念ながらグロースさせることができず、平成も本日終わりを迎えてしまいました。やれることはいっぱいあったんだろうなと思うのですが、そこまでリソースを割くことをしなかった。ちょっと後悔です。
今回のセールサーチはグロースのために最低でも半年間は改善をやっていきたいと思っています。
平成年表は投稿型のサイトだったので、人気や注目を集める必要がありましたが、今回のセールサーチは検索サイトなのでデータと見せ方がすべてだと思っています。ユーザーが必要な情報をいかに集めて、ユーザーにどう見せるか。これを半年間突き詰めていきたいと思っています。そのためには掲載ショップを増やす、掲載情報の鮮度を新しくする、セール情報の分析や独自の評価やランキングを見せるなどやれることは大量にあると思っています。

現段階のセールサーチは完成形の1%程度でしかない

本気でそう思っています。だから現段階ではサービスの宣伝は普段お世話になっているCrieitと開発会議とTwitterだけにします。
まだ大規模に宣伝するフェーズではない。本当にそう思っています。
そもそも開発着手したのって、4月27日（土）です笑。最近お世話になっている3monthsServiceの集いの中で開発着手しました。GW暇だったのでガッツリ開発時間を確保することができ、リリースに至りました。今回もfirebase＋Vue.jsなので前のソースの流用ができるってのも大きかった。

それでもリリースしたのはなぜか？

ドメインの力をつけたい（Google検索のため）
自分のケツを叩きたい
理由としてはこれくらいです。現段階ではそこまで使われる状態にはないと思っています。このサービスは口コミというよりは検索で上位をとれないとグロースは難しいサービスだと思っています。コミュニティ形成ではなく、いかに多くの人の目に触れるかが重要なサービス。だから早めにリリースしてちょっとでもGoogleの評価を上げていくことが重要なはず。そう思ってリリースを急ぎました。

さいごに

今度こそ頑張ります！

ゲーム投稿サイト「unityroom」に使われている技術

2018-12-14T00:03:14+09:00

こちらはCrieitで開催されている「個人開発サービスに用いられている技術 Advent Calendar 2018」14日目の記事です。
昨日はnabettuさんの「cometsを支える技術」でした。cometsを使えば発表が楽しくなること間違い無しですね！

はじめに

こんにちは、@naichilabです。Unity製のゲームを投稿できるサイト、「unityroom」を開発・運用しています。

unityroom

すべてのゲームが無料で、PCとWebブラウザさえあれば遊べます。
数多くのゲームが投稿されてますのでぜひ遊びに来てください。

このサイトは2016年4月29日に公開しました。
あれから約2年半、おかげさまで公開されたゲームは3000を超え、非公開や限定公開も含めると4500を超える作品が投稿されています。

今日はアドベントカレンダーということで、このサービスにどのような技術が使われているかをご紹介したいと思います。

Ruby on Rails

Ruby on Railsは聞いたことある方も多いと思います。
Ruby用のアプリケーションフレームワークです。
分類的にはフルスタックフレームワークと呼ぶんでしょうか？大小様々なアプリが作れます。

unityroomもご多分に漏れず、大部分がRailsの標準機能で作られています。

なぜRails？

unityroomを作る前、前身として「うに部屋」（今はなきUnityWebPlayerの投稿サイト）を２年弱運用していました。
そのサイトはPHPとCakePHPを使って作りました。
CakePHPの入門書を手に取ってから二週間ぐらいでレンタルサーバーにデプロイできてしまい、あまりの手軽さに感動したのを今でも覚えています。

ただ、最初から最後までPHPが心から楽しいと思えませんでした。
普段はC#ばかり使っていたので、PHPのゆるゆるな感じが馴染めなかったのかもしれません。
（もちろん言語がダメというわけではなくなんとなく自分に合わなかっただけですよ！）

色々調べていくうちにRubyという言語やRuby on Railsというフレームワークがあることを知り、興味が湧いて次に何か作るときにはRailsを使ってみようと決めました。そしてRailsを勉強しながら最初に作ったサービスがこのunityroomです。

フロントエンド

フロント側を見てみましょう。

erb と slim

ビューテンプレートはRails標準のerbと、一部でslimを利用しています。
開発当初にslim良さそうじゃん〜と思って使い始めたものの、期間をあけて触ろうとすると構文調べることが多くて、結局シンプルなerbに戻そうとしていますw

CoffeeScript

スクリプトはRails標準のCoffeeScriptで書いてます。
CoffeeScriptで書いたものがRailsの機能でjsに変換されて出力されます。

Bootstrap4

CSSはBootstrap4を使っており、部分的に上書きしたりして使っています。

初期リリース時はBootstrap3 + 市販のテンプレート(買い切り$30)を使ってたんですが、市販テンプレートの機能が多すぎて素人の手には扱いきれませんでした。
その後リニューアル時にすべて切り捨ててBoostrap4のみにしました。
ゲームのサムネイルが並んでいるのも全てBootstrapのCardsです。

Bootstrapは非デザイナでもとりあえずWebサイトっぽくしてくれるので好きです。

とはいえCSSゼロから書けるの憧れる〜〜〜。
いずれはフルスクラッチでイケテルサイトを作ってみたいものです。

Vue.js

誰でもタグ編集画面だけVue.jsを使っています。

このページではvue-input-tagというライブラリを活用しています。

Vue自体とても分かりやすいですしもっと使いたいんですが、Railsとどう組み合わせていいか分からず横展開できてません。

Turbolinks(Railsの機能)はOFF

Rails標準機能にページ遷移を高速化するTurbolinksというものがあります。ページ遷移をフックすることで高速化する仕組みのようです。

しかしUnityWebGLのBGMがページ移動しても鳴り続けたりとよく分からない挙動をしたので安易にOFFにしました。（雑対応!!

バックエンド

続いてバックエンドです。

Heroku

ホスティングはHerokuを使っています。

リリース当初はConoHaのVPSにCentOSを入れて、Railsを入れて・・・ってやってたんですが、サーバー運用辛すぎてすぐに載せ換えました。多少出費はかさみますが時間を買ってると思えば安いもんです。

普段は Standard-1X dyno($25/月) ２つで運用しています。

スケールアップ・アウトの冗長構成とか自分じゃ組めないし組みたくもないです。覚える時間があったらサービス作りたいですね。

Heroku Postgres

データベースはHerokuアドインの Heroku Postgres ($9/月)を使っています。

これもちょっとお高いですがコマンド一行で定期バックアップの設定できたりと便利です。

Heroku Redis

Railsのキャッシュ保存先として、 Heroku Redis (無料)を使ってます。

Cloudflare

unityroom.com ドメインのDNSとして、またCDNとしてCloudflareを使っています。

無料で使ってますが、性能に不満を感じたことはないです。
認証とかあってもデフォルト設定でよしなにキャッシュしてくれてすごいなと思いますw

あとHerokuにホスティングすると標準ではネイキッドドメイン（ www. のつかないドメイン）で公開できないんですが、CloudflareのCNAME Flatteningという機能を使うことで www. なしを実現しています。

ConoHa オブジェクトストレージ

日々増えていくゲームファイルの保存先として、ConoHa オブジェクトストレージを使っています。

クラウドストレージで一番有名なのはAWS S3だと思いますが、ゲームはファイルサイズが大きくなりやすく、データ転送量に課金されると財布が死んでしまいます。ConoHaのデータ転送量無料に惹かれて使い始めました。一年ぐらい前はアクセスが集中するとアップロードエラーが出たりしていたのですが、最近は大丈夫そう。サーバー補強されたのかな？

S3と同じくOpenStackという仕様に準拠してるそうなのでfogというライブラリを使ってAPIを呼び出しています。

今日確認したら122GB使われてました！

バッチ処理

定期的に実行する処理はRails内にRakeタスクを作成し、Herokuアドインの Heroku Schedulerで定期実行しています。

ちょっとした工夫

ファイル転送

ファイルアップロードはデータ転送量が多いので、Railsを介さないような工夫をしています。

サーバー側でオブジェクトストレージのAPIを叩いてPUT可能な一時URLを取得
一時URLをクライアントに渡し、クライアントから直接オブジェクトストレージにアップロード

こうすることでRailsに負荷をかけずにアップロードすることができます。

前身の「うに部屋」ではPHPで作ったフォームでファイルをアップロードしていたので、ファイルサイズは100Mまで(Webサーバーの制限)、さらに数人が同時にアップロードするとタイムアウトするなど、ひどい作りでした。

この辺りはどうしても解決したいと思い、unityroomの開発を始める前によく調べました。

またダウンロードもiframeでオブジェクトストレージに公開したコンテンツを読み込んでるだけなので、データはRailsを経由していません。

テストとか

テストはRSpecで書いています。とはいっても書き方よく分からず書ききれていないです。
投稿者以外からは見えないこと とか 何時何分に公開されること といった手動でテストしづらいものを重点的に書いています。

デプロイ方法とか

ソースコードはGitHubで管理しており、開発チケットはIssueで管理しています。

基本的にGithub Flowと呼ばれるブランチ運用をしており、チケット単位で開発（かなり適当）し、プルリクエストを作成しています。

プルリクエストが作成されるとHeroku Review Appsという仕組みで検証環境が自動デプロイされます。（プルリクエストがマージされるか閉じられると自動で消えます）

それと同時にCircle CIがテストを実行してくれます。

ReviewAppを使うことでマージ前に実際の動作を確認できるのでレビュー作業がとっても楽です。

プルリクエストがマージされ、masterブランチが更新されると、ステージング環境に自動デプロイされます。
この環境は常に起動しており、実際のファイルアップロードとかもできるようにしてあります。

ステージング環境で最終確認をしたのち、Heroku上でPromoteボタンを押すと、やっと本番リリースです！

本番リリース時もHerokuがDynoを順繰りに更新してくれるので、ユーザーから見てダウンタイムはありません。（データベースマイグレーションが必要な場合は止めますが。）

紹介したReviewApp、ステージング、プロダクションといったものはすべてHeroku Pipelineの機能です。簡単な設定でめっちゃ便利になるのでみんなにオススメしたいです。

監視

死活監視

死活監視は特にしてません。連絡受けたら自分で見に行きますw

パフォーマンス計測

管理者としてログインしている時だけrack-mini-profilerを表示するようにしています。

発行されたSQLの詳細とか、レンダリングにかかった時間とかが表示できます。

無料ですし簡単に使えるので重宝しています。

パフォーマンス計測その２

無料プランのNew Relicも入れてあります。

エラー発生時にどこのメソッドでどういうエラーが出てたかとか遡って確認できます。

無料だとスロークエリとか見れないのが難点ですが、そこは rack-mini-profiler で補ってます。

今後の目標

今はまだ 開発者が使う投稿サイト という感じなのでアクセス数も大したことありません。

これだけ多くのゲームを投稿してくれた開発者の皆さんに恩返しするためにも、
ゲームが遊べるサイト としてゲーム開発者以外のユーザーに使ってもらう必要があります！

機能追加や使い勝手の改善、デザイン改修などやりたいことは山ほどあるんですが全然作業時間が取れていません。

もしゲーム作りが好きでunityroomを一緒に開発したいぜ〜！みたいな人がいたらぜひお声がけください。
特にデザインできる人が手伝っていただけるとめっちゃ嬉しいです。（報酬は相談させてくださいね）

もっとアクセス増やして稼いで皆さんにどんどん還元したい！

まとめ

非常に長い記事になってしまいました。思い入れのあるサービスなのでまだまだ書けそうですがこの辺にしておきましょう。

naichiさんって本業はWeb屋さんですか？って結構聞かれるんですが、全然違うんです。
残念ながらゲーム作りもWeb開発も趣味でやっているので、全然時間が足りません。

とはいえ純粋に「楽しい！」を第一に考えて作れるのは趣味プログラミングのいいところですね。

ゲーム開発もWeb開発もですが、ああしよう、こうしようと考えたり話し合ったりするのはとても好きです。
なので意見・感想・要望などがあればドシドシお寄せください！！

みんな楽しく開発しましょう〜〜〜！

ここまでお読みいただきありがとうございました。それではまた！！

明日はSugiKentさんの記事です。お楽しみに〜

Android, iOSアプリを100本くらいリリースしたのでいろいろ振り返ってみる

2018-12-11T17:57:33+09:00

こちらはCrieitの個人開発サービスに用いられている技術 Advent Calendar 2018の12日目の記事です。
前日はかしい@お笑いSNS作成中さんのブログSNS『Tumblr』を無理やりユーザー投稿型メディアとして運営した話についてでした！

あんた誰？

どうもこんにちはTeccoです。
主に Android, iOSアプリ を作っています。

会社でもいっぱい作ったんですが、元々は個人開発でアプリを作っていました。
リリースした本数が100本(※)を超えたので、数えるのをやめました＼(^o^)／

Android -> https://play.google.com/store/apps/developer?id=Tecco's+Project
iOS -> https://itunes.apple.com/jp/developer/makoto-nishimoto/id896702438

せっかくの機会なので どのような技術を今まで使ってきたか を振り返ってみます。

※公開を停止したもの含めます。

使ってきた技術一覧

集計してみます。 ※Android, iOS同名アプリは別アプリとして集計

フロントエンド

技術	本数
ネイティブ	約100本
Cordova	1本
Cocos2dx	1本
Unity	2本

バックエンド

技術	本数
なし	約90本
自前API	2本
他社API	8本
Firebase	7本

かなりテキトーな仕分けですがこんな感じです。
数だけあっていろんな分布を期待した方ごめんなさい。

見てもらったらわかるように基本的には ネイティブ × なし が圧倒的な数を占めます。

技術の選定

基本的に個人開発で心がけていることは 以下の5つ です。

シンプルイズザベスト
3日以内を制限時間とする
運用に負担がかかるものはやらない
アプリ一本にこだわりすぎない
デフォルトを愛する

詳しくは人生でたった一本だけ書いた僕のQiitaに書いてあるので興味があればどうぞ。
個人で30本スマホアプリをリリースしたときのコツ5つを紹介してみるよ

やっぱり開発者として、 メルカリみたいな、SHOWROOMみたいな、LINEみたいな、アプリが作りたい！！ っていうのはわかるんですが、自分は一人なのを最前提で考えなければいけません。

もし、自分一人でLINEの機能を全部実装して完成した10年後には
「スマホアプリとか化石かよ！ポケベルのがまだ風情があるわ！」 とか言われる日がくるかもしれません←ぇ

個人開発スタイル(アイディア編)

普段から生活してる際に、何か不満をおもったら、 アプリで解決できないか？ って考えるのがクセになってます。

例)
事象: 北海道出身のTeccoさんは駅の土地勘が全く無く、電車が停止しましたが、混雑していて電光掲示板が見えません。さらにヘビーロックを爆音で聞いているのでアナウンスも聞こえません。降りれば良いのか数秒で判断できなくて人生つらい。

要求: 一秒でも早く自分が今いる駅を知りたい。

結論: アプリでワンタップで現在地から一番近い駅を取得したい。

その時1時間くらいで作ったアプリがこちらです。(公開は停止中

こんな感じで普段の生活からアイディアを抽出することは可能です。

個人開発スタイル(実装編)

アプリとしては現在地をGoogle Places APIにぶん投げて、リストの一番目を取得してるだけです。
まぁ、お察しの通りクソアプリなのでDLは200いかないくらいです。

たとえばこのアプリもリッチに考えればいろいろできて

複数の駅表示に対応
道案内機能を実装
駅までの方向を実装

いっぱい考えられると思うのですが、そんなの「Google Mapに任せとけよ」って話なので、個人開発でもう一つ気をつけなければならないのは、 リッチにすると先駆者がそれ以上のものを作っている可能性が高い という点です。

これは普通のプロダクト開発でも言えることですが、機能が増えるほど メイン機能を阻害する機能が増えて、ユーザーが何をすれば良いのかわからなくなるという現象 が起きがちです。

これは心がけていても、自分でもよくやってしまう失敗なのでやっかいではあります。

個人的におもう個人開発のメリット

僕が個人開発でできるメリットは 単機能でリリースできること だと思っています。
どうしても会社規模の売上やユーザー規模を獲得するには、アプリに滞在させたり、巡回させる方法を考えなければなりません。(初期のYoみたいな例外はあると思いますが

僕は自分のアプリを紹介するときに、 ○○するだけのアプリです 、って紹介を良くします。

たとえばこちらが、Amazonのディスカウント率で検索するだけのアプリです。
Amazon割引ショッピングアプリ

こちらも初回リリースは3日で行っていますが、合計50万DLほどされています。

これは本家Amazonにももちろんある機能ですが、本家は機能が多い分埋もれてしまっています。
なので 大手のサブ機能をメイン機能に持ってくるだけ で、これくらいの需要があるってこともあります。
(ちなみにこちらのアプリはAmazonさんからも了承いただいております

そろそろ書くのが疲れてきたので orz 質問ベースでの回答をいくつかしておきます。

よく聞かれる質問

Q. そんなに出してて管理めんどくさくないの？
A. 他社のAPIのバージョンアップがたまーにと、Androidのバージョンアップで動かなくなったものの対応以外はメンテなしでいけるようにしてるので、半年に一回くらい1,2日メンテくらいで済んでます。

Q. 両OS出すの面倒くさくない？
A. どっちもある程度わかってくると頭の中で仕様はコンバートできるので、片方のOS作ってしまえばもう片方がほぼ何も考えなくてもできます。

Q. クロスプラットフォーム系のやつどう思う？
A. ネイティブでどちらも書いているので、個人的にはあまりメリットは感じられないし、学習コストが高い・本家OSバージョンについていけてない気がする。しかし、ゲームを作るならUnityの恩恵はでかすぎるのでUnityで良いと思う。(あくまで個人のスキルセットに依存するので違うケースも多々あると思います

Q. 正直個人開発って儲かるの？
A. アプリの量と質は間違いなく上がっているし、大企業が本気だしてきてるのでアプリを認知させるのが難しくなっているのでユーザー数の獲得は難しい。しかし、ユーザー1人あたりの広告単価や課金量は上がっているので認知されればお小遣いくらいなら割と可能。

Q. コストはどれくらいかかるの？
A. ライセンス費はAndroidは25ドルで永久、iOSは年に100ドルくらい。アプリ自体に使ってるサーバもすべて無料枠なのでタダ。ただし、宣伝用のWebページなどのサーバは持ってるので月1000円くらい。月換算で2000~3000円くらいなので、月1回の飲み会を断れば余裕で賄えるかな、と。

Q. AndroidとiOSどちらから始めればいいの？
A. コスト面では年に100ドル払いたくないならAndroid一択。市場面では海外(特にヨーロッパ)狙いたいならAndroid, 日本のJKとかビジョンが日本マーケット狙いたいならiOS。KotlinもSwiftもとっても書きやすいので、その点ではどちらもおすすめ。個人的にはKotlinが超大好きだし、最終的には好み。

最後に

久しぶりにブログを書きました(ﾟДﾟ)
こんな機会を与えてくれたアドベントカレンダーと開発者のだらさんには感謝(｀・ω・´)/

良かったらTwitterでもフォローしてください -> @tecco_master
直近リリースしたアプリはこちら -> 匿名チャットアプリ mimicha

さて、明日はnabettuさんです！
実はいろいろインターネット上でお世話になっていいるので期待(ﾟДﾟ)

Nyaaanを支える技術

2018-12-02T08:57:46+09:00

こちらはCrieitの個人開発サービスに用いられている技術 Advent Calendar 2018の2日目の記事です。
前日はなべさんの日本語のフリーフォントを一度に試せる「ためしがき」に用いられている技術についてでした！

11/5にNyaaanというWebサービスをリリースしました。

そこで

どのような技術を使ってるのか
どういう知見が得られたのか

を書いていこうと思います！

どういうサービスかは以下の記事を読んでいただけたらと思います！

https://blog.haramishio.xyz/entry/service-nyaaan

使用している技術

ざっくりな構成でいうと

フロントエンド
- Nuxt.js
Webホスティング
- Netlify
バックエンド
- Firebase

です。

Nuxt.js

Nuxt.jsはVue.jsアプリケーションを作るためのフレームワークです。
ちょっと大きめのVue.jsアプリを作る際に必要なVuexやVue Routerなどが入ってるのでNuxtをインストールすればすぐにWebアプリが作れます。
今回はSSR（サーバーサイドレンダリング）を行わないため、SPAモードで利用しています。

Netlify

Webホスティングはさまざまな種類がありますが、今回はNetlifyを選択しました。
選択した理由としては・・・

ビルドを勝手にやってくれる（npm run build がビルドコマンドよ！ってNetlifyに登録しとくだけでいい)
ビルドしたらデプロイもやってくれる
他のホスティングサービスと比較して無料枠の制限が少ない

Firebase

APIやDBが必要になったのですが、すべてFirebaseで行いました。
主要なFirebaseサービスはHostingとML Kit以外使いました。

それぞれの用途としては・・・

Authentication
- Twitter認証のため利用
Firestore
- ユーザ投稿データやユーザデータを保存
Functions
- Twitter APIに問い合わせる処理やユーザ削除機能で利用
Storage
- ユーザのアイコンの保存で利用

得られた知見

Firestoreのクエリーのクセ

FirestoreはNoSQLです。RDBのような柔軟なクエリーを書くことは出来ません。
その制限にひっかかってちょっと苦しんだ事例があるので共有します。

Nyaaanでは「有効期限」という機能があり
これを設定すると1時間または1日経つと、鳴き声（つぶやきみたいなもの）が見れなくなるというものです。

その鳴き声テーブルはこんな感じになってます（本当はもっとカラムあります）

カラム	型
ID	string
鳴き声	string
本音	string
有効期限	timestamp
作成時間	timestamp

Nyaaanにはタイムラインがあり、鳴き声は作成時間の降順でソートしたいです。
なので・・・

// カラム名はわかりやすく日本語にしてます
mewRef.where("有効期限", ">", now).orderBy("作成時間", "desc").limit(10).get()

としたかったのですがこれはNG。
範囲フィルタ(>や>=)を使う場合は、orderByの最初の要素はその範囲フィルタで使用したカラムしか指定できません。
Cloud Firestore でのデータの並べ替えと制限

RDBならこういうのは普通にできますが、NoSQLはこういう制限があるのかと勉強になりました。

結局どうしたかというと、後述するバッチ的なもので有効期限をチェックして削除してます。

FirebaseでCron的なことをしたいとき

上述したバッチ的なものの話です。

サービスを作っていくとバッチが必要になる場面があるとおもいます。
なにかしらの処理を定期的に動かすとなるとCronを使ったりJenkinsを使ったり色々あると思います。
これらはサーバーが必要になりますよね。
すでに持ってる人はそれを使えば良いんですが、僕はお金をかけたくないのでどうにかしてサーバーレスにしたいです。

さて、FirebaseのFunctionsはHTTPSフックで起動することが出来ます。
つまりcronでcurlを定期実行すればバッチみたいなことができるわけです！

そして世の中には外形監視のために定期的に指定したURLを叩いてくれるサービスがあります。
cron-job.orgやUptime Robotがそれです。

これを利用してFunctionsを定期的にトリガーするようにしてバッチ処理をサーバーレスで実現しました。

懸念点として、Functionsの実行を外部からできるようにしてしまっているのでセキュリティ的に問題ないのか？という点ですが
今回の場合はリクエスト時にGETパラメーターでアクセストークンを渡しており、そのアクセストークンじゃないとアクセス拒否するようにコーディングしています。
それでも攻撃されて突破されるリスクもなくはないので、センシティブなことをしたい場合はやめたほうがいいと思います。

Functionsの様々なトリガー

Fucntionsのトリガーは色々あります。

トリガー	内容
HTTPS	URLを叩くだけ
onCall	クライアントから直接呼び出し
Authentication	ユーザの登録/削除で呼び出し
Firestore	ドキュメントの登録/更新/削除で呼び出し
Storage	オブジェクトの登録/更新/削除で呼び出し
Pub/Sub	Cloud Pub/SubのPublishで呼び出し

NyaaanではHTTPSとAuthenticationのトリガーを使用してます。
特にAuthenticationトリガーは便利で、以下のようにFunctionsに書くだけで簡単に書くことが出来ます。

// ユーザが削除されたら実行されるFunction
exports.removeUser = functions.region('asia-northeast1').auth.user().onDelete(function(user, context) {
~~~
});

Nyaaanではユーザ削除されると今までの鳴き声が消えるようになってます。
クライアントでそこまでやると重いので、クライアントではAuthenticationのユーザだけ削除してレスポンスをすぐ返し、
FunctionsのAuthenticationトリガーで非同期で削除処理を走らせてます。

Netlifyのリダイレクト設定

Nuxt.jsのSPAモードを使用していて、Netlifyでホスティングしていたのですが
ルートパス以外を直接呼び出すと404エラーになってしまいます。(例: https://nyaaan.haramishio.xyz/top)

SPAではルートパス以外でアクセスされたらindex.htmlへリダイレクト処理をする必要があります。

Netlifyはリダイレクトの機能があり、デプロイするディレクトリのトップに _redirects を配置しそこにリダイレクト設定を記述するとリダイレクトしてくれます。

/*    /index.html   200

この話をもうちょいちゃんと説明したのがこちらの記事になります。
Netlifyを使ってたらルートパス以外が404になった話とその解決方法

最後に

ということでNyaaanの使用技術とそこから得た知見を書きました！
この記事でみなさんの開発のヒントになれれば幸いです！

さて、明日はこのアドベントカレンダーが開催されているCrieitの運営者のだらさんです！