きんみの投稿 - Crieit

ハッカー専用パズルゲームを作ったので全てネタバレする

2020-09-24T10:25:23+09:00

当記事はハッカー専用パズルゲームを作ったので全てネタバレするのクロス投稿です

💰作ったもの💰

@銀行口座をHackしたくてウズウズしている皆さん「違法行為はしたくないけどハッキングはしたい…」そんな貴方の悩みを解決するゲームをご用意しました。このゲームでは何をやっても合法です。是非、不正ログインしてみてください💰https://t.co/LyIpYLCRrP #UNLOCK_BANK
— きんみ | ツイッター大喜利サイト🎍ついぎり🎍作りました🙄 (@_kinmi) September 21, 2020

仕様

Account Number(数字8桁) と Password(数字4桁) によるログイン認証
Account Number は全て存在する(8桁なので全口座数は1億口)
Password を3回間違えるとロック(再試行不可)される
[裏設定] 銀行口座を模している為、もちろんパスワードが流出したら他者もログイン可能

ユーザーはどんな攻撃手法を用いても良い。
最近話題の1段階認証を突破してみようというパズルゲーム。

システム構成

JSフレームワーク: Nuxt.js 2.14.5(Vue.js 2.x)
トランスパイル: TypeScript 4.0
CSSフレームワーク: TailwindCSS
ホスティング: Vercel

お馴染みの構成を選択したが、Vue.jsの使用については少し後悔している（後述）

以下ネタバレ

基本的には以下の2つと考えている。
- ☠️リバースブルートフォース攻撃☠️
件の金融事件で脚光を浴びた攻撃手法。
暗証番号の総当たり(ブルートフォース攻撃)は一般的なシステムだと試行回数に制限を設けているが、ユーザーIDの様な公開情報については秘匿性が低いため無制限に試行できるシステムが多い。そこを突いてパスワードは固定のままIDの方を総当たりするという攻撃。
特に当ゲームのような、認証情報に数値しか許容していないシステムだと少ない試行回数で突破できるため致命的な脆弱性となる。

😈リバースエンジニアリング😈
JavaScriptのみで構成している為、コードを解析してパスワードの取得が可能。
当初はNode.jsサーバー等を用意して認証処理を隠蔽するつもりだったがガチ攻撃された場合、サーバーか私の財布が死ぬと思い断念。
しかし「ハッカー専用」と銘打っている以上、コードを覗くだけで突破されては面白くないので悪足掻きとして難読化を施している。

仕組みについて

🔐パスワード生成

仕様として、口座番号とパスワードの紐付きを作らないといけない（パスワードが流出したら誰でもログインできるように）
最初は愚直に1億口座分のパスワードマッピングを定数で用意しようと考えた。
しかし上述のコードを隠蔽できない事情によりリテラル値で持つのは避けたかった為、下記のライブラリを採用した。
seedrandom.js
これを用いてシード値から再現性のある乱数を生成(※1)する。

下記のように口座番号をシード値とした乱数を生成した後、整形してパスワードとしている。

const seedrandom = require('seedrandom')

function authenticated(account: string, password: string): boolean {
  const rng = seedrandom(account)
  const _pass = String(Math.round(rng() * 10000)).padStart(4, '0')
  return _pass === password
}

これで口座番号とパスワードの紐付きを再現している。

seedrandom.jsの使用感

🙆‍♂️ 良かった所
- 直感的に使える
- 複数の乱数アルゴリズムに対応している
- Math.random()をラップできる為、テストにも使えそう
🙅‍♂️ 頑張って〜
- 型定義がない(2020/09現在、issueにて対応中)

個人的には「再現性のある乱数を生成する処理」というのはバーコードバトラーライクのゲームを作る際に重宝するので、有難いライブラリ。

状態管理, 認証処理

本筋と外れるが、クライアントで認証処理を行う為に口座番号と暗証番号をグローバル管理する必要があった。
Vuexはオーバースペックなので状態をInjectするプラグインを自作してstoreとして使用した。

~/plugins/auth.ts

import Vue from 'vue'
import { Plugin } from '@nuxt/types'
import { Seedrandom } from '../types/seedrandom'
const seedrandom = require('seedrandom') as Seedrandom

type InjectTypeAuth = {
  /**
   * 口座番号
   */
  accountNumber: string
  /**
   * 暗証番号
   */
  password: string
  /**
   * 認証処理
   * seedから4桁の乱数(先頭0埋め)を生成し、passwordとの比較結果を返却する
   * @param {string} seed シード値となる値
   * @param {string} password パスワード
   */
  authenticated(seed: string, password: string): boolean
}

declare module '@nuxt/types' {
  interface Context {
    $auth: InjectTypeAuth
  }
  interface NuxtAppOptions {
    $auth: InjectTypeAuth
  }
}
declare module 'vue/types/vue' {
  interface Vue {
    $auth: InjectTypeAuth
  }
}

type State = {
  accountNumber: string
  password: string
}

/**********************************************
 * 認証情報プラグイン
 * @param {Context} ctx
 * @param {(key: string, value: any) => void} inject
 */
const AuthPlugin: Plugin = (_ctx, inject) => {
  /**
   * Observable properties
   */
  const state = Vue.observable({
    accountNumber: '',
    password: '',
  } as State)

  function authenticated(seed: string, password: string): boolean {
    const rng = seedrandom(seed)
    const _pass = String(Math.round(rng() * 10000)).padStart(4, '0')
    if (_pass === password) state.password = _pass
    return _pass === password
  }

  /**
   * Injection
   */
  inject('auth', {
    get accountNumber() {
      return state.accountNumber
    },
    set accountNumber(accountNumber: string) {
      state.accountNumber = accountNumber
    },
    get password() {
      return state.password
    },
    authenticated,
  })
}
export default AuthPlugin

※ 実際の乱数生成処理はもう少しノイズを入れてるので、このまま動かしても同じパスワードは生成されません

このauthenticatedをEnterボタン押下時と、直アクセスを防ぐ目的でログイン後ページ内のvalidate()hookでも呼び出して認証処理としている。

⚠️注意
当然ですが、フロントエンドでパスワードの一致チェック等の認証処理を行ってはいけません。

Vue3のRCが外れて正式リリースとなったが、Reactivity API等を活用したVuex(ver 5)のリリースはまだ先の様なので暫く状態管理はこの手法に落ち着きそう。

攻撃方法の紹介

以上を踏まえ、解法の一つであるリバースブルートフォース攻撃の実施方法を紹介していく。
尚、当ゲームでは外部からブラウザ操作しやすいように主要な要素に対してid属性を付与している。

前提知識: JavaScript の場合

「システム構成」の節でも触れたが、Vue.jsの採用を後悔したのはここ。

システムがHTML＋PureJSの構成であれば、ブラウザの開発者コンソールから下記の様に実行して入力値を動的に与える事が可能。

const digit1 = document.getElementById('digit1')
digit1.value = "1"

これは一般的な方法だし、私も当初このやり方を想定していた。
しかしVue.jsの場合、inputイベントを検知してVueインスタンス内に保有するデータを更新する。
直接input要素のvalue値を書き換えてもイベントは発火せず、データは更新されない。
この挙動を想定しておらず、ユーザーに無駄なハードルを与えることとなってしまった。

ではどうするのか。
当ゲームには数値をカウントアップ/カウントダウンするボタンを実装している。

金融システムって誰得UI多いよな という遊び心で実装したボタンだが、Vue内のデータを書き換えるイベントに直結している。
このボタンをプログラムからクリックすることが出来れば口座番号入力の自動化が可能となる。

ここから先の解説は、既にUNLOCK成功された@yoneappさんが記事を書かれている為、そちらに任せることとする。
リバースブルートフォース攻撃を使ってUNLOCK BANKの口座に不正ログインして優勝する(Zenn)
（改めて解説記事の執筆ありがとうございます🙇‍♂️）

前提知識: Vue.js の場合

Vue.jsには vue-devtools というデバッグ用のブラウザ拡張が存在する。
これを使えばコンポーネント構成を覗きつつ、各種データの書き換えやイベント発火が可能となるが通常はProduction環境で開けない。
しかし、開発者ツールを使いこれをこじ開ける方法がある。

本番公開されているサイトで Vue devtools を使う裏技(Qiita)

厳密にはソースの難読化を施してるのため上記記事と全く同じではないが、ソースを検索すればdevtoolというキーワードは見つかるはず。
あとはその後ろにブレークポイントを張り、_0x1bd719.devtools = true を実行すれば開発者ツールを開けることが可能。

図の状態(Devtoolsでコンポーネントを選択した状態)だと、開発者コンソール上で$vm0というオブジェクトが使用出来る。これは選択したコンポーネントのVueインスタンスであり、コンポーネント内に存在するデータやメソッドが全て内包されている。
あとはそこからアタリを付けて、自動化プログラムを組めば良い。
実際には下記をイジれば入力操作の自動化が可能となる。

$vm0.accountNumbers // 口座番号(1桁ずつ格納した配列)
$vm0.password // パスワード
$vm0.enter() // Enterボタン押下時の処理を実行

⚠️注意
初めてこれ(Productionでdevtoolsが使えること)を知った方はセキュリティ面に不安を覚えるかもしれませんが、それはお門違いです。
フロントエンドで保持するデータはユーザーから自由に改ざんされる前提であるべきです。

前提知識: Nuxt.js の場合

Nuxt.jsで作られたアプリケーションはwindow直下に$nuxtというオブジェクトが作られる。
そこには全ての情報が含まれており、上記のようにDevtoolsを開かずとも開発者コンソールからデータの書き換えやメソッドの実行が可能。
しかし内包する情報量が膨大な為、開発者ではない第三者が操作したい対象を探すのは一苦労かもしれない。
ちなみに当ゲームでは下記が自動化に必要な対象となる。

window.$nuxt.$children[1].$children[0].$children[0].accountNumbers
window.$nuxt.$children[1].$children[0].$children[0].password
window.$nuxt.$children[1].$children[0].$children[0].enter()

その他の手法

Selenium や Puppeteer 等を用いたブラウザ操作の自動化があげられる。
今のところ、これらを使ってUNLOCKしたという報告は観測していない。ブラウザの開発者ツールが万能すぎる。

⚠️注意
悪意が無くともサーバーに高負荷をかける行為は法律により罰せられる可能性があります。
しかし、当ゲームで行う分には問題ありません。存分に攻撃してください。

更にネタバレ

もしproduction環境でログイン後のページを確認する必要が出た場合を考慮して、
- Account Number: 1145-1419
- Password: 1919

と入力したら開発コンソールに上記口座のパスワードが出力されるようになっている。
攻撃するのは面倒くさいけどログインしてみたい、という方はどうぞ。

確率について

数値4桁のパスワードというのは 0000 ~ 9999 の1万パターンしかない。
パスワードを固定にして、口座番号を総当たりした場合の確率は下記で求められる。

1 - ( 9999 / 10000 )^x
x=試行回数

(間違ってたらご指摘ください)
確率を表にするとこうなる。

試行回数	HITする確率
3回	0.03%未満
10回	約0.1%
100回	約1%
1,000回	約10%
10,000回	約63%
100,000回	約99%

つまり、口座番号8桁(1億パターン)全て試行せずとも、10万回程度で1口座はUNLOCKできてしまう。
下5桁総当たりすればいい計算で、実際にTwitterでUNLOCKされた方の反応も「思ったより早かった」という声が多かった。
当ゲームはパスワードを乱数によって生成しているが、これが本当の銀行口座の場合、パスワードの偏りが生じるはずなので更にUNLOCKは容易となるだろう。

おわり

ネタのつもりで作ったんですが思いのほか反響があって、解説記事を書いて頂いたり、難読化をデコードしてリバースエンジニアリングまでやって下さってる方もいて、個人開発冥利に尽きるなと思いました。
他にも「こんなやり方あるよ」という方がいましたらご連絡ください。

注釈

※1: JavaScriptにはシード値から乱数を生成する機能が備わっていない

敗者のweb1week

2020-03-22T17:10:52+09:00

先週行われた web1week。
初開催にも関わらず50を超えるサービスが登場し、大盛況のうちに幕を閉じた。

経験者ならば理解を得られると思うが、個人開発という舞台には魔物が棲んでいる。
着手時点で思い描いた予定などペロリと喰われてしまう。

不意に削られる作業時間。
理想と妥協の狭間で揺れる要件。
技術仕様の落とし穴。
サービスの意義を自問自答し続ける日々。
リリース直後に訪れる無慈悲な障害。

これらを乗り越えローンチされた個人サービスの奥には、語られることのない物語が潜んでいる。
そんなサービスが50以上も並ぶweb1weekのボードは圧巻で、たとえHello Worldの様なサービスでも私の心を踊らせてくれる。
とても甲乙など付けられない。

しかし「敗者」は存在する。
「web1week楽しみ！」と方方で意気込みを語り、「やってみませんか？」と様々な人を勧誘した挙句、あろうことか最小限の機能でさえ1weekに間に合わず、最終的には要件すら満たせなかった。
紛うことなき「敗者」だ。
個人開発界隈ではよく「リリースすることが大事」と言われている。その通りだ。リリースさえすれば勝ちなのだ。

これは、そんな勝負に敗北を喫した男の記録である。

立案

月曜の午前0時、お題「Home」が発表された。
こじつけでも何でも「Home」を絡ませたWebサービスならクリアとのこと。
初学者でも参加し易いうえに、CGMやIoTを絡めたサービスも構想でき、かつ疫病の脅威に怯える時勢に寄り添った素晴らしいお題だと思った。
それと同時に頭を抱えた。
１週間で作り上げるとなると出来る事は限られている。ピンと来るアイディアが何も思い浮かばない。

「自分が実装してみたい機能」というアプローチで考えてみる。
我が家にはGoogle Nest Hubというガジェットが存在する。ディスプレイ付きスマートスピーカーというイロモノだ。
スマート家電のような贅沢品は存在しない我が家だが、昨年の私の誕生日に妻から贈ってもらっていた。しかし、動画を見るにはタブレットやテレビに転送で事足りるし、BGMをかける風習も無い。なかなか使う場面が訪れなかった。
これを何とか活用できないか。

玄関や冷蔵庫に貼ってるホワイトボード。これをNest Hubで代用できないかと考えた。
「いってらっしゃい」「おやつにわらび餅を冷蔵庫に入れてます」の様な、家族間のメッセージは手書きの方が嬉しかったりする。
しかし、ホワイトボードのデメリットはホワイトボードの場所へ行かないと書けないことだ。
仕事中に「冷蔵庫にわらび餅入れてるの忘れてた！」となった場合、LINEに頼るしかない。
スマホから手書きでメッセージを書き、玄関やリビングに置かれたNest Hubに表示されたらエモいのでは。

Nest Hubで表示するWebアプリについて調べてみる。
どうやらInteractive Canvasというフレームワークで実装するらしい。
しかし、基本的にVUI（音声ユーザーインターフェース）が前提となる作りで、ストアへ並べるにはGoogleの承認も必要となる。
今回の要件・納期では厳しい、、

方針を変える。
Nest HubにはGoogle Photosにあるアルバムを選択して、フォトフレームとして表示する機能がある。
Nest Hub側でメッセージ画像を入れたアルバムを選択して、Webサービス側ではそのメッセージ画像を更新すれば良いのはないだろうか。
調べてみた。さすがGoogle様。ちゃんとGoogle PhotosのAPIも存在する。

これでいこう。

WebサービスにGoogleアカウントでログイン
手書きUIのCanvasでメッセージを書く。
Nest Hub表示用のアルバムをGoogle Photosに作成
Canvasを画像化して3.のアルバムにアップロード
既にメッセージ画像が存在する場合は削除（アルバム内の画像は1枚のみとする）
Nest Hubで表示

OAuth2認証をクライアントで完結できれば、DBすら不要。
この程度なら1週間でいける。

市場調査もしてみた。

スマートディスプレイ（ディスプレイ付きスマートスピーカー）がどれぐらい普及してるのか気になるのでアンケお願いします！持ってるか持ってないか。押し入れで眠っててもOKです！
— きんみ | ツイッター大喜利サイト🎍ついぎり🎍作りました🙄 (@_kinmi) March 9, 2020

うん、Nest Hub専用サービスは良い感じのスキマ産業のようだ（強がり）

Nuxt.jsでプロジェクトを作成して今日の作業は終了。
この時点で月曜の夜。順調だ。

裏の目的

常々思っていたのが「もっと手軽に画像アップロード機能を作れないか」という事だった。
画像アップロードというのは、ストレージを用意して、アップされる画像の最適化処理を組み、著作権の侵害等を考慮して規約や同意UIの設計をしなければならない。
リリース後は不適切な画像が上がってないかウォッチする義務が発生するし、ストレージの残容量も気にしなければならない。
更に、増え続ける画像の管理方法（一定期間で削除するか、お金で解決するか）も検討しなければならない。
個人開発において、割とコストが高めの機能だ。

この課題はGoogle Photos等のユーザーが保有するクラウドストレージに公開状態で保存すれば解決するのではないかと考えた。
このご時世、Googleアカウントは誰でも持っている。アカウント登録時に自動で付与されるGoogle Photosの容量は高画質モードなら無制限だし、あくまで「画像を公開しているのはユーザー」という体裁を繕えるので著作権問題もグレーゾーンとなる（漫画村方式）
サービス側で保有するのは画像の静的URLのみだ。

今回、Google PhotosのAPIを使いこなせる様になれば今後の個人開発に幅を持たせることが出来るかもしれない。

ハマる

コロナ自粛の影響により勤務時間が削減され、個人開発の時間は比較的多めに取れた。
それでも間に合わなかったのは全てにハマったからだ。
全てだ。
時系列でハマりポイントを紹介していく。

JS ClientSDKが使いづらい

Google APIをWebで利用する場合、Google API Client Library for JavaScript（GAPI）というライブラリを利用する。
Initial Commitは2011年。それなりに年季の入ったライブラリだ。

NPMには登録されていない。

scriptタグで読み込む必要がある。
Nuxt.jsで外部スクリプトを使用する場合、$nextTicks()を用いてもスクリプトのロードが完了していない場合がある。
ロード状態を監視する必要があるので少し手間だ。

DiscoveryDocs

GAPIのスクリプトを読み込んだ時点ではinit()等、最低限の機能しか保有していない。
Getting Startedに記載されているが、API Key等を設定して初期化する際にDiscoveryDocsというURLを設定する。
DiscoveryDocsはAPI単位で用意されており、URLの先にあるJSONをGAPIでロードすれば機能として利用できる。
Google Photos APIのDiscoveryDocsは下記となる。
https://content.googleapis.com/discovery/v1/apis/photoslibrary/v1/rest
スクリプトの肥大化を防ぐための機構だろう。
ここまではまだ良い。手間を感じるがまだ許せる。

同期処理

ドキュメントのサンプルはthenチェーンで記載されている。
じゃあ・・・と思ってasync / awaitで書き直してみる。動かない。
そう、返却値はES6 Promiseじゃない。
goog.Thenableという独自インターフェースを継承したオブジェクトだ。
init().then(()=>{ }) の中でしかGAPIは動かない。同期的にいくつものAPIを使いたければthenのネストを深め続けるしかない。F*ck。

ES6が標準化されたのが2015年。このライブラリの開発当初ならスマートな仕様だったのだろう。
しかし、こちとら去年からJSを学び始めた身。
終始、この仕様に慣れず生産性が低下した。

認証で躓く

ユーザー管理にはFirebase Authenticationを採用した。
手軽に導入でき、「特定のユーザーには使わせない」といったセキュリティ対策も出来る。
Twitter API等、他社のAPIと連携する場合はトークンの保管といった一手間が必要になってくるが、今回はGoogle Platform内で連携するだけ。
簡単だろうと思った。

🙅 Firebase → Google API

以下の記事を参考に、Firebase UIでログイン→GAPIのイニシャライズを試みる。
Using Google APIs with Firebase Auth and Firebase UI on the Web

できない。
この記事ではFirebaseでログインした時点で GAPIの認証状態 : gapi.auth2.getAuthInstance().isSignedIn.get()が true になる想定だが false だ。
GAPIでもログインする必要があるのか？と思って試したがFirebaseとGAPIで二重ログインされてしまった。

記事のコメント欄に記載がされているが、現在はFirebaseでログインしてもGAPIでログイン状態を検知しない。
下記のissueにもその事が記載されており、ステータスはopenのままだ。
https://github.com/google/google-api-javascript-client/issues/561

🙆 Google API → Firebase

つまり現状、FirebaseとGAPIを連携するには認証順を逆にしないといけない。
GoogleAPIのサインイン : gapi.auth2.signIn()でログインした後、認証情報を取得して Firebaseの認証情報を使用したサインイン : firebase.auth().signInWithCredential()でもログインするフローとなる。
下記の記事を参考に実装した。
How to Use Google APIs on the Web

進捗：だめです

この時点で既に平日は終わっていた。残すところは土日のみ。
対応が長期化した要因は「出来ると書いてあったから」。
Firebase→GAPIの認証は不可能という可能性を考慮していなかった。
この考慮漏れが発生するとプログラマーの思考はどうなるか。
ひたすらタイポを探し続けるのである。

画像アップロードが用意されてない

まだ間に合う。
土曜にアップロード機能を実装。
日曜にデザインを微修正＆実機で動作確認。
ここまで盛大に躓いて尚、根拠なく「出来る」と盲信する。
進捗が遅れてるプログラマーにありがちな逆算スケジュールである。

🙅 GAPIで画像アップロード

ガイドラインを読んでみる。
https://developers.google.com/photos/library/guides/upload-media
どうやら画像をアップロードするには、二段階の手順を踏まないといけないようだ。

画像のバイナリデータをGoogleにアップロードする
上記返却値に含まれるアップロードトークンを用いてアルバムに追加する。

Google PhotosのDiscoveryDocsから該当のメソッドを探してみる。
無い。
何度検索しても「uploads」という処理は無い。
「なぜ無いのか」なんて考える余裕も無い。
（現在、不安になって再度探してみたがやっぱり無い）

GAPIじゃGoogleに画像をアップロード出来ない・・・？

🙅 axiosでリクエスト

悩んでいる暇は無い。もうクライアントSDKは捨てる。
ドキュメントにはエンドポイントが記載されているので、そこに対してaxiosでPOSTリクエストを投げてみる。

Network Error.

・・・久し振りに見たぜ。
has been blocked by CORS policy: No 'Access-Control-Allow-Origin'
CORSエラーだ。
おいおい、嘘だろ。CORSだと？
浅学だが、基本的にはAPI側での対応が必須だったと記憶している。詰んだか？

🙅 XMLHttpRequestでリクエスト

ドキュメントには「CORSもサポートしているよ」と書かれている。
How to use CORS to access Google APIs
クライアントSDKを用いれば回避できるよ。と。
使えねぇんだよチクショウが。
記事の最後にXMLHttpRequestを用いた例も記載されている。
存在は知っていたが初めて使うなこれ。
愚直に書いてある通り組んでみる。

has been blocked by CORS policy: No 'Access-Control-Allow-Origin'

泣く。

🙅 gapi.client.request()

まだだ。諦めない。
俺は長男だから我慢できたけど次男だったら我慢できなかった。

ドキュメントを漁り、もう１つの可能性を見つける。
クライアントSDKには標準で APIを叩く為のメソッド : gapi.client.request()が備わっている。
GoogleAPIのエンドポイントをベタ書きして引数に渡せば叩けるらしい。
クライアントSDKならCORSを回避できるんだろ？信じるぞ？
叩いてみる。

404

？？？
タイポ探しフェーズ（数時間）に入るも、やっぱり問題は無い。
リクエスト内容を確認した。POST先のURLが変わっている。
画像アップロードのエンドポイントはhttps://photoslibrary.googleapis.com/v1/uploadsだが、ドメイン部がcontent.googleapis.comに変わってる。
なんだこれは。
恐らく、クライアントSDKが書き換えていると推測。M*ther F*cker。

諦めた。

クライアントで完結することを。

🙆 Netlify Functions

ホスト先にNetlifyを利用している。
そこでクラウド関数を作れるNetlify Functionsを使ってみようと思い立った。
使った経験が無い機能だ。下記の記事を参考にHello Worldから始めてみる。
【入門】Netlify Functionsコトハジメ
そして「Googleに画像をアップロードしてアップロードトークン返すクラウド関数」を立ててみた。
うまくいった。
初めて使う機能なのに、ハマらず動く。ローカル環境もすぐ出来た。
感動した。モダン最高。

進捗：納期は昨日なので大丈夫です

この時点で日曜の夜。
軸となる機能は一通り完成したものの、「同名アルバムが存在していた場合」などのシチュエーションに応じた分岐は作れてないし、要件として「既にメッセージ画像が存在していた場合は更新する」といった機能も存在するが未実装だ。実機確認もやれてない。

「ごめんなさい」しつつ、月曜に出そう。
そう決めて床についた。

画像の削除/更新はできない

ベットに入った直後、悪寒がした。

見覚えがない。

散々GoogleAPIのドキュメントと格闘し続けたが、Google Photos内の写真を削除/更新するエンドポイントは見た記憶がない。
スマホを取り出し確認してみるも、やはり無い。

冗談だろ？クラウドストレージを操作するAPIのくせに削除/更新は出来ない？そんな馬鹿な話があるか。
調べてみる。
https://issuetracker.google.com/issues/109759781
結論：出来ないらしい

詰みです。お疲れ様でした。

過去画像を含めてランダム表示されるなんてホワイトボードじゃない。

「お手数ですがGoogle Photosを開いて、ご自身で過去の画像を削除してください。」
しょーもな。
サービスとして成立していない。

・・・いや、まだだ。

よし、譲ろう。

百歩譲ろう。

Google Driveなら削除/更新もAPIで可能じゃなかろうか。
Photosなんかより歴史あるクラウドストレージだ。
Google Driveへアップした写真をNest Hubで表示できれば問題無い。

Can I connect my Google Drive to my Google home hub?
結論：出来ないらしい

こうして私は、web1weekの敗者となった。

Safari対応（おまけ）

負け犬でも遠吠えぐらいは出来る。
「手書き画像をGoogle Photosへアップするサービス」としてローンチしよう。
そう決めて実機確認に入った。

CORSぞ

MacのChrome、Android Chromeは問題なく動作完了。
妻に「iPhoneでこれ使えるか確認してほしい」と依頼する。
返信は「画面が驚きの白さ」。
ここで初めてMacのSafariでも動作確認してみる。

has been blocked by CORS policy: No 'Access-Control-Allow-Origin'

CORSぞ。

何度立ちはだかれば気が済むのだCORSよ。
まぁ思い当たる節はあった。
GAPIが使い辛いので、下記のようにクラアントSDKを動的に読み込んでplugin化していたのだ。

export default async ({ $axios, store }, inject) => {
  // GAPIの読み込み
  const gapiScript = document.createElement('script')
  const src = await $axios.$get('https://apis.google.com/js/api.js')
  gapiScript.appendChild(document.createTextNode(src))
  document.head.appendChild(gapiScript)
  const gapi = window.gapi

  // ロード処理(Promise化)
  const clientLoad = new Promise((resolve, reject) => {
    gapi.load('client:auth2', () => {
      resolve()
    })
  })
  // GAPI初期化処理
  const init = () => {
    return clientLoad.then(() => {
      return gapi.client.init({
        apiKey: authConfig.Google.apiKey,
        clientId: authConfig.Google.clientId,
        discoveryDocs: authConfig.Google.discoveryDocs,
        scope: authConfig.Google.scopes.join(' ')
      })
    })
  }
  inject('gapi', gapi)
  inject('gapiInit', init)
}

不安はあったが、動いたのでそのままにしていた。
外部スクリプトを動的に読み込む場合、普通はCORSの問題が発生する。
素直にscriptタグで読み込むように変更した。

というか、なぜChromeでは読み込めたのか分からない。
同じGoogle製品だから？
プラットフォーマー恐るべし。

クロスサイトトラッキング

さて、初期表示までは問題なくSafariで動作した。
しかしGoogleへログインしても認証状態を検知しない。
プログラムが「ログイン中」と判断しないのだ。
こればっかりは思い当たる節も無い。

issueが上がっていた。
gapi auth2 issue on safari
同様の事象、かつオープンのままだ。
Safariの場合、Cookieを全削除するか、プライベートブラウズなら問題無いらしい。
マジかよ・・・
頑張れば何か対策できるのかもしれないが、負け犬にそんな根性は無い。
UserAgentから「Safari、もしくはiPhone/iPad」を判定して、該当する場合は長ったらしい注意文言を表示するようにした。

敗因

次回以降のweb1weekで勝つための敗因分析を行う。

PoC（概念実証）不足

一番の原因はこれ。
事前に「画像の削除/更新は出来ない」と知っていれば別案を採用していた。
とはいえ、1週間という過密スケジュールで検証工程を取れるかは疑問が残る。
少なくとも、

機能の洗い出し
実装に必要な外部インターフェースのドキュメントはちゃんと読む

まぁ、、当たり前のことはちゃんとしよう。ということ。

「出来ない」の判断が遅い

認証や画像アップロード等、ハマった際に「出来ない」という判断が出来ていない。
昨今の潤沢な開発環境に甘え、「出来ない事は無い」と思い込んでいる節がある。
確かに大抵の場合、ハマる原因は外部インターフェースの仕様変更、もしくはタイポが多い。
塩梅が難しいが、もっと早いタイミングでissueを探そう。

Google Photosを利用した画像アップローダーは作れるのか

冒頭に記した「裏の目的」について。
そもそもGoogle Photos APIの利用規約には「ホスティングサービスとして使うならCloud Storageを使え」と明記してある。
開発するサービスを「Google Photosへアップした写真の共有ギャラリー」という位置付けにするならグレーかな？と思ったが、
結論から言うと「多分、不可」だ。
少なくとも、そう言うサービスを作れるだけのAPIが提供されていない。

まず前述の通り、API経由での画像の削除/更新は出来ない。
あくまで画像のアップロードのみで、アルバム間の移動すら出来ない。

そして、更に致命的なことに静的なURLは取得できない。
写真のURLを取得するAPIは存在するが、一定期間が過ぎると無効化されるらしい。
これはGoogle Photosの「URLで共有する」と同じURLなのだろう。
URL先には静的な画像が埋め込まれているらしいが、それを取得するAPIは存在しない。
スクレイピングを駆使すれば取得できるかもしれないが、実用的では無いだろう。

「ユーザーのプライベートストレージを用いた画像アップローダー」は別サービスを検討した方が良さそうだ。

ゴミを公開する

これはweb1weekじゃない。
私が作りたかったものでもない。
ゴミだ。

Nest Board
https://nest-board.netlify.com/

Google APIは申請無しで使用できるが、Googleから承認されていない場合、ログイン時に警告画面が出る。
利用する際は注意文言を読んで頂きたい。

需要あるか分からないが、Nest Hub側で表示する際の手順も明記しておく。

1. スマホ（iPhone/Android）でGoogle Homeアプリを開く
Nest Hubの初期設定に必要なアプリなのでインストールされているはず。

2. 表示したいNest Hub > フォトフレームを編集 > Google フォトの順で選択

3. Nest Boardで作成したアルバムを選択する
初期値は「Nest Board」

4. 「フォトフレーム」画面の下部にある「個人的な写真の整理」を「リアルタイム共有アルバムのみ」にする
これを設定しないとNest Hubがフォトフレームに不向きな写真と判定して表示されない。
ハマりポイント。

以上の手順を踏めば、Nest Hubに手書きのメッセージ画像が表示される。

普段はソースコードを公開したりしないのだが、今回はリポジトリをpublicにした。
なぜなら敗者だからだ。
https://github.com/kin-mi/nest-board

おわり

次は勝つ。

私の経歴書

2019-12-25T17:06:57+09:00

この記事はcrieitのなんでも Advent Calendar 2019の20日目の記事です。

私がプログラミングを始めたのは中学生の時だった。

それほど裕福な家庭ではなかったが、作曲が趣味の母親が給与数ヶ月分を叩いてVAIOのデスクトップを買ってきた。
当時、私はパソコンのことはよく分からなかったが「色んなことが出来る機械」と漠然なイメージを持っていたのを覚えている。
なので当然、ゲームも出来るはず、と思い”Internet”と書かれてあるアイコンをクリックしてYahoo!を開き「ゲーム無料」で検索しては手当たり次第遊んでいた。
今思えば、身を削って購入した高級な端末を子供に触らせるなんて、母親は怖くなかったのかと思うが、特に何も言わず自由に使わせてくれた（ダイヤルアップ接続だった時期は「夜だけにしろ」とだけ言われていた）

創作欲と出会った話

中学校には私と同じようにパソコンゲームに興じる友人が2人いた。
俗に言うWeb1.0時代、無料で遊べるゲームは沢山あったが、私たちはブラウザだけで遊べるゲームにハマっていた。有名所であれば「箱庭諸島」や「バトルロワイヤル」といったゲームである。
ページ遷移でゲームが進行する形式で、ユーザー同士の対戦やチャット等、プレイヤー間でコミュニケーションを取れる機能が組み込まれていることが多かった。

そんな時代、私たちはVagoo（ヴァグー）というゲームに夢中になっていた。「うぇぶなげぇむ」という個人で運営されてるサイトにあったRPGだ（現在は閉鎖中）
上記に並べたゲームに比べるとマイナーで、モンスターと戦ってストーリーを進めるというシンプルな作りだが、キャラメイク機能やモンスターをペットに出来る機能など、クオリティの高いゲームだった。
索敵をするには一定時間待つ必要があり、その間ユーザーはゲーム内のチャットに集まる。ゲーム自体も面白かったが、そこで顔も知らない人達と夜通し会話をする体験が思春期の私にはとても刺激的で楽しかった。

そのゲームはコピーレフト（オープンソース）として配布されていた。
当時、GitHub等のリポジトリサービスは無く、zipファイルが直リンクで置かれているだけだった。
これを動かせば自分だけのゲームが作れるかもしれない。
動かし方を必死に調べた。

CGI/Perlで組まれているプログラムだが、それを動かせる無料レンタルサーバーというのは中々無い時代だった。
月数百円で運用出来るサーバーはあったが、中学生にはそれでもキツい。生まれて初めて「早く大人になりたい」という感情を抱いた。
調べていく内に、自分のPCをWebサーバーに出来ることを知った。幸い、母親が買ってきたこの端末は性能が良かったので問題無くApache HTTP Serverを導入出来た。僕は無敵になった。

自分のPCで動いているVagooを見て、とても感動した。
ソースコードの中身はよく分からないが"Vagoo"と書かれていた文字列を書き換えるとゲームタイトルが変わる。
時間を設定していそうな数値を書き換えると索敵の待機時間が変わる。
予測して、書き換えて、結果を確認する。
この循環がとても楽しかった。
この過程で条件分岐や反復処理、HTML/CSSなど基礎的な知識は身についた。

冒頭に「プログラミングを始めたのは中学生の時」と書いたが、当時の私には「始めた」という感覚は無く、無意識でノートの端に描く落書きと似たような感覚だった。
良く描けた落書きは人に見せたくなる。
また必死に調べながら、ポートを開放して、DNSを設定して、Webサーバとして稼働させて、友人に「ぼくのつくったVagoo」を見せて遊んでいた。

遊んでいる最中、管理者画面へ入るパスワードがテキストファイルに記載されていて、ファイル名さえ知っていればアクセス出来る状態だということに気が付いた。
ファイルのパーミッションを設定すれば良いだけだが「本家はどうなっているんだろう」と思って覗いてみるとアクセス出来てしまった。ゲーム内にはユーザー間のDMみたいな機能もあり、管理者画面に入るとそれも含め全ユーザーの情報を見ることが出来る。倫理観なんて無かった僕は友人に「あの人とDMしてたでしょw」と得意げに話してしまった。怒られた。謝った後、運営者に脆弱性の報告をした。
注）この行為は不正アクセス禁止法により処罰の対象となります

そういった経緯もあり「Vagoo2」の開発フェーズでテストプレイヤーに選ばれるぐらい僕は主要メンバーになっていた。
年齢関係無く大人達の仲間に入れる。そんな、インターネット上で遊んだり創作したりする時間が、僕にとっての快楽となっていた。

創作欲を封印した話

高校は偏差値の低い地元の工業高校へ進学した。
どこでだったか忘れたが「ホームページ制作は云十万かかる」というのを見て、既にHTML/CSSぐらい書けるようになっていた僕は「ITは楽に稼げる」と思った。他教科の勉強は時間の無駄、ひたすらプログラミングの勉強をしたいと考え、受験勉強せずとも入れる、情報系の学科を選択した。

プログラミングを学びたくて入学した高校に、プログラミングが出来る生徒はいなかった。それどころか、殆どの人はパソコンすら触ったことがなかった。地方の工業高校なんてそんなものだ。
周りの友人達は夜通し遊びに興じていた。入学当初は時間を見つけては自宅でプログラミングをしていたが、次第にその行為を「恥ずかしい」と思うようになってきた。中学生の頃は「ゲーム」という共通の話題の中でプログラミングを行う事が出来たが、今はそれすら無い。何か作って見せても「遊びの誘いを断ってこんなもの作ってるなんて、気持ち悪い」と思われるかもしれない。そういった恐怖心から僕は創作意欲を心の奥に閉じ込めるようになっていった。

卒業研究

高校のプログラミングの授業は面白かった。ビット演算や論理演算などの基本的な内容だが、独学では中々踏み込まなかった所だったからだ。同級生からは「何故かプログラミングの授業だけ点数が良いやつ」と思われていた。
もっと勉強したいし、やっぱり何か作りたいという欲が常にあった高校生活だったので大学へ進学した。基本教科の勉強はろくにしていなかったのと、附属高校だった為、受験勉強せずとも入学できる同系列の大学へ行った。

高校へ進学した時と同じ志望動機で大学を選択すれば、当然ながら周囲の環境も変わらない。僕は浅はかだった。
案の定、何も出来ない（やらない）時間だけが過ぎるキャンパスライフだった。

中学生時代に遊んだブラウザゲームは個人でも改造出来るレベルのものだったが今はどうなっているのだろう、と流行っているパソコンゲームを調べてみた。MMORPGと出会ってしまった。3Dで描画された世界を好きなだけ駆け巡り、他者と協力したり対戦できたりする。
クリエイターとしての私は絶望した。クオリティが高過ぎて、とても一個人が足を踏み入れられる世界じゃない。
ゲーマーとしての興奮は凄かった。私は夢中になり、ゲームをしながらご飯を食べ、パソコンの前で寝て、起きて、また世界を駆け回る。所謂、廃人になった。

こう書くと私は進路を後悔しているように見えるかもしれないが、私は高校・大学ともに行って良かったと今でも思っている。遊び呆ける体験も思春期には必要な時間だ。
ずっと心の奥底に何かが引っかかっている。その程度の違和感があり続けた、というだけの話だ。

この違和感を解消できるチャンスは「卒業研究」だけだと思っていた。
私は地元よりも就職活動の時期が早い東京で、早々に職を決めた。プログラミングの仕事なら何でも良い。それより卒業研究に励みたいと思っていた。「研究」より「制作」に近い研究室を意識的に選んだ。
研究内容は「ゲームを作る」今の私にピッタリだった。
研究室には僕の他にも数人の同期がいたが、プログラミングが出来るのは僕だけだった。もう、この事象に違和感は持たなくなっていた。「企画やゲームの素材画像、論文等は全てやってくれ。代わりにプログラムは全部俺が書く」という役割分担にした。ひたすらプログラミングをしたかった私にとっても、これが一番良い分担だった。
半年間ぐらいだったと思う。朝から大学が施錠される23時まで、ひたすら研究室に籠ってプログラムを書いた。ずっと一人作業ではあったが、それは幸福な時間だった。
世の中はiPhoneの登場に沸き立っている時期だったが、私たちの研究内容はガラケーのゲームだった。
出来上がったものはとてもチープなゲームで、ダウンロードURLも公開したが、恐らく遊んだのは研究室のメンバーだけだろう。それも数分程度。
しかし、私は大学から推薦され電子情報通信学会の成績優秀賞を頂いた。推薦されれば必ず授与される「頑張ったで賞」みたいなものだが、そういった経験がなかった私には自信を与えてくれた。

新社会人

私は上京して社会人になった。
就職活動を早く切り上げたい一心で選んだ企業は、中小のシステムエンジニアリングサービス会社で、大企業の開発プロジェクトへ派遣されて常駐するタイプの仕事だ。
変わらず「何か作りたい」という漠然とした欲は持ち続けており、初任給でデスクトップ端末を買って開発環境を構築したが、何を作ればいいのか分からなくなっていた。
絵を描くスキルの無い私がゲームを作ったところで、卒業研究以上にチープなものが出来上がるだけだろう。それを自分だけ遊ぶ？そんな虚しい趣味には興じれない。絵を描ける友人に「ゲーム開発しないか」と話を持ち掛けたことは何度もある。しかし、その度になぁなぁで終わっていた。ゲームの素材作成というのもまた、熱量のいる作業だし、社会人になって数年程度の若手だと私生活に割ける時間も少ない時代だった。

仕事の方は割と順調だった。
中小だが一次請けの案件が主で、二次請け三次請けのパートナー会社を管理する仕事だった。若手の頃にプログラマーとしての経験を積み、次第にチームやプロジェクトのリーダーとして管理職の経験を積む。
私は保守案件のチームリーダーや、受託開発プロジェクトのNo2ポジション、オフショアという海外へ開発を委託する手法が流行った時期は中国の子会社へ赴任するなど、低学歴の私からすると派手な経歴が連なってきていた。
私の中にあった「何かを作りたい」という欲求は、仕事を進める上での自動化ツール作成に置き換わっていた。これなら私が作ったものを誰かに使ってもらえる。

代わりに、私生活は堕落しきっていた。
創作欲は仕事で満たされてしまい、今あるスキルだけで仕事が成立するので独習などする必要も無い。
スマホでソーシャルゲームをしたり、ギャンブルしたり、毎晩の様に酒を飲みに行ったりしていた。大抵の娯楽は身を削るレベルでハマった。

転職

仕事は順調だったが、違和感を感じていた。
プログラミングをしたくて就いた会社で、プログラミングをさせてもらえなくなっていたからだ。「開発をしたい」と意を唱えたこともある。しかし、なし崩し的に管理職になっていく未来が見えていた。自分の生産性を上げることより、大勢を管理出来るスキルを磨く方が売り上げ的にも有利なことは明白だった。
堕落していた私生活を矯正する為にも、私は転職して地元へ帰る決断をした。

それが現職の会社となるのだが、30歳を超えた今でもプログラマーとして働けている。
業種や会社の形態は前職と変わらない為、管理職になるべきという圧は感じるが、まぁ自由に働けるようになったと思う。

2018年某日

中学生の頃からの夢だった「プログラミングで飯を食う」は達成された。
しかし、それでも私の心にはモヤがかかっていた。
キャリアパスを見据え、やりたい事だけやる生活を求め、年収を100万下げてまで転職した。しかし、やりたくない事を拒絶し続けた結果、そこには出来る事しか残っていなかった。もちろん、技術の移り変わりがあるが、そこのキャッチアップも含め私には「作業」となっていた。中学生時代に抱いていた知的好奇心の煌めきを感じられなくなっていた。
余談だがこの年、私は結婚した。人生のターニングポイントを迎えたことで今後の人生を具体的にイメージし始め、上記の様なことを考えていた気もする。

東京にいた頃とは打って変わり、業務中にも暇が出来るぐらい余裕のある生活となっていた。
私はよく技術記事投稿サイトQiitaを眺めるようになっていた。とくに何かを調べるわけでもなく暇潰しだったのだが、徐々に引き込まれていった。
Qiitaはトラブルシューティングや技術の紹介記事ばかりと思っていたが、この年は「個人でサービス立ち上げてみた/アプリを作ってみた」系の記事が多かったのだ。

開設後３週間で収益１０万円を得た個人開発サイトでやったことの全部を公開する
 ポエムでも何でも書けるQiitaの様なサービスを作った
 技術書ランキングサイトをQiita記事の集計から作ったら、約4000冊の技術本がいい感じに並んだ
 もっと気軽にアウトプットできる技術ブログサービス「Qrunch（クランチ）」をリリースした【個人開発】
Qiita版TweetDeck！？カラム形式でQiita記事をウォッチできるクライアントサービス「QiitaDeck」をリリースしました！
Web未経験から100日でリリース！初心者が「お笑い情報のアグリゲーションサイト」をつくりました【個人開発】

上記の記事もほんの一部で、この個人開発ブームを分析するような記事も出ていた。

ワイの選ぶ2018年個人開発サイトBEST5
【比較してみた】みんなが使っている個人開発（Webサービス）向けPaaS・ホスティングサービス

またQiitaでは、年末に各テーマに沿った技術記事を毎日誰かが投稿するアドベントカレンダーという企画がある。
前年までの私は気にも止めてなかったのだが、クソアプリ Advent Calenderという、無駄に技術で遊ぶカレンダーの存在にも気が付いた。

創作欲を閉じ込め続けていた私は、どの記事を読んでも心が躍った。世の中には個人で開発を楽しんでる人が沢山いる。私は製作者達のファンとなり、日々の活動も追いたいと思ってTwitterアカウントを作った。
最初に交流を計ったのはQiitaのコメント欄だった。送信後は柄にもなく、相当舞い上がっていた。「失礼にあたらないか」「的外れな事言ってないか」などを気にして仕事に手が付かない。恋する乙女のような心模様だった。31歳のおっさんが。恐らく相手もおっさんだ。
返信で「とても参考になる」と返ってきて更に興奮した。その日の晩、帰宅して妻に意気揚々とこの話をしたことを覚えている。

ここまで来たら何もせずにはいられない。妻に「来年は個人開発を頑張りたい」と申し出た。仕事を辞めるわけではないが、その分家事が出来なくなる、というお願いだ。快諾してくれた。

今年の話

ここから先の話はQiitaやCrieitに記事を残しているのでそちらに任せようと思う。

フロント明るくないおじさんがWebアプリ作った話【悟空語ジェネレーター】
なぜ大喜利サービスを作ったのか
 Nuxt.js＋Firebase＋GAEで作った個人サービスが半月で2万PV超えたので実績値を全て公開する
 ギャザをドローするクソアプリを作りました

この一年間、とにかく、ひたすら、開発をしていた。
昼休憩や仕事終わりはもちろん、休日や長期休暇は出来るだけ予定を入れずに朝から晩まで開発していた。
流石にもう歳なので学生時代よりは疲弊する。しかし苦痛を感じたこと一度もなかった。楽しかった。これまでの人生で抱えていたストレスを発散するかのような一年だった。

中盤でも少し触れたが、私は私の人生を肯定している。個人開発には全ての経験が生きるからだ。出遅れた私は他の開発者の方々と、スキルや経験値の差を感じてばかりだが、それでも私にしか作れないものが必ずある。
今更、学歴に見合わない派手な経歴を増やそうとは考えていない。しかし、糧に出来ればそれが私の強みになる。過去も今年の経験も含めて発展させる、そんな経歴書を今後の人生で作っていきたい。

Nuxt.js＋Firebase＋GAEで作った個人サービスが半月で2万PV超えたので実績値を全て公開する

2019-10-04T17:10:28+09:00

Qiitaへ投稿した記事のクロス投稿になります。

こんなサービス作りました

【#拡散希望】🙌🎉🎊サービス開始🎊🎉🙌ボケをツイートして「いいね❤️」「リツイート🔁」の数でランキング！Twitter連動型大喜利サイト「ついぎり」サービス開始しました‼️#ついぎり https://t.co/bkXfzHyVSs
— ついぎり@公式アカウント (@twigiri_app) August 14, 2019

Twitterで大喜利するサービスです。
８月中頃にローンチしたのですが、有難いことに半月で約2.5万PVいきました。

開発に至ったポエム記事はCrieitに投稿しています。
なぜ大喜利サービスを作ったのか

この記事について

やっぱり公開直後は怖かったです。

そう、クラウド破産。
Firebaseの設定を間違えて72時間で300万円以上請求されてしまったウェブサービス
 BigQueryで150万円溶かした人の顔

上記以外にもネット上にはインパクトのある高額請求の記事がたくさんあり、
内容を確認すれば「なんだそんな事か」となるのですが、
実績値というのはセキュリティやNDAの関係からか、なかなか出回ってません。

個人開発ならそんなの関係ねぇ

って事で全て公開します。
使い方によって大きく変わる所かと思いますが、何かの参考（個人開発の後押し）になれば幸いです。

環境構成

Nuxt v2.8.1
- SSRモード
GAE
- standard
- runtime: nodejs10
- instance_class: F1
Firestore
- 改めて別記事書こうと思いますが一般的な構成だと思います
Cloud Functions for Firebase
- engine: node8
- ユーザー登録/脱会/ツイート/いいねRT集計/バックアップで使用
Cloud Storage for Firebase
- OGP画像の保存に使用
Regionは全てasia-northeast1

使用量

PV数

トータルで約2.5万PV。
デイリーだとローンチ直後の約5,500PVがMAXです。

割り当て

アクセス数に比例した増加は見られませんでした。

GCP Storage egress between NA and APAC
使用量: 3.59GB
一番費用が発生してるこれ、よく分かってません・・・
GAEのデプロイにかかる項目なのかな？と思ってます。

Cloud Firestore Entity Writes Japan
Cloud Firestore Read Ops Japan
Write: 480,077
Read: 606,253
Firestoreは1日単位で無料枠がリセットされるのですが、リリース直後はちょっと無料枠から足出た程度ですね。
21日辺りは障害等でデータいじってた・・・気がします。

諸経費

サーバー代

0円でした。
使用量として57円かかってるのですが、
GCPには1年間有効な$300のトライアルクレジットがあるので、そこに収まってます。
クレジットを$0.5消費しました。使い切れる自信がありません。

ドメイン代

1,600円です。
Google Domainsでappドメインを取りました。
appドメインはSSL証明書無しでは使えないという安全なドメインです。
GAEの場合、SSL証明はデフォルトで有効＆無料です。

収益

AdSense広告を導入しています。
キャプチャは載せて良いのか分からなかったので・・・
半月で約1,300円でした。

所感

環境構成について

一番びっくりしたのはNuxt.jsがF1インスタンスで落ちずに稼働していることです。
公式ドキュメントでもF2が推奨されてるのですが、F2では無料枠に収めることが難しいです。
バックエンド処理をFirebaseに任せてるおかげで負荷が少ない構成になってるのかなーと思います。

費用について

正直「バズった」と言える数値ではないと思ってるので「バズっても大丈夫」とは言えないです・・・
座布団数(ボケツイートのいいね/RT総数)も、現在のランキング1位は3桁です。
「バズっても大丈夫」と分かったら改めて記事書くので、誰かバズってください。

しかし、まぁバズが発生してない個人開発としてはそれなりのアクセス数だと思ってます。
それで数十円なので「そんなに怖くないよ！」とは言えるかと。

安心して使うために

GCPの課金アラートを設定する
Rulesはちゃんと書く

は最低限やっとくべきです。
ただ、Rulesはちゃんと書くと一般的なバックエンド処理と同レベルの規模になると思います。
最低限の尺度が難しいですが、認証/取得件数/タイムスタンプ比較辺りは最低でもやっておくべきです。

マネタイズについて

AdSenseに頼ったサービスの運営は凄く難しいという体験をしました。
PV落ちたら施策を打たないといけないので放置出来ないし、
収益率はAdSenseの匙加減１つで大きくブレそうです。

前作ではマネタイズしてなく、正直「もしバズったらお金かかるよな・・・」とアクセス数に対してネガティブになってました。
その経験を踏まえ、広告を貼りました。
結果、素直に「バズれ！」と思えるようになったので、それだけでも導入した価値はあったかと思います。

おわり

今後、この個人開発で得た知見で記事書こうと思ってます。

TwitterAPIがBANされた話
Firestoreの構成について
文字入れ画像を作るソースコード
オレオレアトミックデザイン

他に「ここ知りたい」等あれば公開しますし、ボリュームある内容であれば記事書きます！

ただ、一番書きたいのは「バズっても大丈夫だった件」です。

Twitter連動型大喜利サイト「ついぎり」

面白い投稿お待ちしてます😋

なぜ大喜利サービスを作ったのか

2019-10-01T17:53:19+09:00

お笑いは人並み程度の「好き」です。
劇場へ足を運んだことは無いし、常にチェックしているお笑いコンテンツがあるわけでもありません。
タイムラインで目に留まれば見ますし、笑います。

「ボケる」文化はどちらかと言えば苦手です。
「ここはボケるところやろ！なんで！？」
「スベってもえーからボケたろゆう姿勢は見せてーや！」
とか言う人、ちょっと苦手です。
マナーの強要というか。
「会話転がしてこ！？」とか知ったこっちゃねーです。
キャッチボールで勝手にカーブ投げてくるなって話です。

すみません、脱線しました。

こんな僕ですが、個人開発でこんなサービス作りました。

【#拡散希望】🙌🎉🎊サービス開始🎊🎉🙌ボケをツイートして「いいね❤️」「リツイート🔁」の数でランキング！Twitter連動型大喜利サイト「ついぎり」サービス開始しました‼️#ついぎり https://t.co/bkXfzHyVSs
— ついぎり@公式アカウント (@twigiri_app) August 14, 2019

大喜利サービスです。

つまり何が言いたかったかと言うと、
開発の動機に「お笑いコンテンツの課題を解決したい」とか
「こんなサービス欲しい」といったものは無かったのです。

そんな個人開発の動機やモチベーションを振り返ろうと思います。

個人開発はじめました

僕は約10年間、SESでサラリーマンプログラマーとして働いています。
その間、プライベートでプログラミングの勉強等はやってこなかったです。
しなくてもなんとかなる世界だったので。

そんなある日、~~業務が暇で暇で~~自己研鑽したくてQiitaを眺めてると下記の記事を見つけました。
開設後３週間で収益１０万円を得た個人開発サイトでやったことの全部を公開する
神記事として名高いので、一度は目にしたことあると思います。

捉え方は人それぞれだと思いますが、僕がこの記事を読んだ感想は
「ちょー気持ち良さそう」
でした。

僕がこれまでの人生で得た収入は全て「既存の商流に便乗する」ことで発生したものです。
まぁ普通な事だと思います。一般的なサラリーマンなら。
絵は描けない。作曲もできない。起業？独立？そんな勇気ない。
僕はPCに向かって文字打つ事しかできない。
他の選択肢なんて考えた事も無かったです。

そんな人生だからこそ「自分の中から生まれたもので収益を得る」ということに凄く魅力を感じました。
自己承認欲求だと思います。
月10万なんて収益を得られた日には半端無い快楽を得られるのではないか と思いました。

そんな気持ちで、まずは勉強がてら小さいアプリを作った話がこちらになります。
フロント明るくないおじさんがWebアプリ作った話【悟空語ジェネレーター】
これでなんとなく、Web開発の雰囲気は掴めました。

個人開発としてのPoC

上記アプリを作る過程でTwitterを始めたり、いつも以上にQiitaを眺めたりしました。
そこで個人開発としてのベストプラクティスやアンチパターンを沢山耳にしました。

Nuxt.js（Vue.js）＋Firebaseなら爆速でサービスを量産できる
GCP（Firebase）は基本無料の代わりにバズると怖い
個人で広告型マネタイズは厳しい
PV稼いで収益出すタイプのサービスは難しい、ニッチを狙うべき

僕は要領悪いので、体験を得ないことには納得できないタイプでして。
どれも言ってる事は分かるけど、ピンと来なかったです。

少なくとも、これを真に受けて次に進むと
「AdSense？wやめときなって。個人じゃ稼げないよ」
なんて知った風な顔で講釈を垂れる、ダサい男になる気がしました。
そんな親父にはなりたくない。

次にやる事が決まりました。
「今の自分が本気出したら、どれぐらいのPV（広告収益）を稼げるのか」
とりあえずバズっとけば大変さや運用費を体感できるでしょう。

芸能人でもインフルエンサーでも起業家でもない俺が、
それどころか個人開発トーシローの俺が、
バズるサービス作ってやる！

拡散力全振りサービスのアイデア

とはいえ、まだWeb開発駆け出しの身。
小難しいサービスは作れない自信があります。
WebサービスのFizzBuzz的な。ミニマムサイズで拡散力あるもの。

Twitterをやっていれば自然とここへ行き着きます。

Nuxt.js＋Firebaseで質問箱クローン作ってみようかな。…トランザクション的にFirebaseだとキツいかな。まぁやってみよう。
— きんみ / 🎍ついぎり🎍リリースしました🎉 (@_kinmi) March 15, 2019

ベースは質問箱でいこう。
まるでお手本の様なミニマムバズサービス。

クローン作るだけでもWeb開発の勉強にはなります。
しかし、何の検証にもなりません。
使う側からしたら「質問箱でええやん」終わり。です。
バズりません。
他にも類似サービスは沢山あります。
後出しのこっちは、バズる為のナニカが欲しいところ。

質問箱は「誰でも気軽に質問できる」を目指して作ったのでしょう。
しかし、こちらの目指すところは「めっちゃ拡散されて、バズ契機を増やす！！」
解決したい課題なんて無い。拡散ファースト。
いっそ 拡散されたか をシステムの機能として組み込めば・・・？
こんな感じで
「シェアツイートのいいね/RT数を使って何かする」
が決まります。

それから質問箱の回答ツイートを意識して見てると、割と大喜利やってるユーザーが多いことに気付きます。
僕自身も質問箱を始めたんですが、ネタ振りと捉えて回答することも多く
「ならいっそ、大喜利特化型の質問箱にしちゃおう」
こんな感じでアイデアは固まりました。

その他、検討段階で出てた案をここに供養しておきます。

ブログパーツ版質問箱
質問箱ベースで出たアイデア。
ブログに埋め込んでコメント欄として使ったら面白いんじゃないかなーと。
オーナーからの回答はツイートされる。
何かしらでランキングにしちゃえばブログの宣伝にも繋がる。
今でも割とアリだと思ってます。
Twitterで遊ぶRPG
「ツイートのいいね/RT数を使って何かする」ベースで出たアイデア。
一定時間経つと敵とエンカウント（自動ツイート）
ユーザーが気付けばそのまま戦える。
気付かなくてもフォロワーがツイートを「いいね」「RT」することで援護できる。
これはナシかなーと思ってます。
いいね/RTをする意味が変わるのでフォロワー的にウザそう。
（RTキャンペーンに近いネガティブイメージ持たれそう）

これ匿名投稿サービスなの？

既についぎりで遊んで頂いた方はそう思うのではないでしょうか。
実はこっそりマイページに「ユーザーに匿名でお題を出す」という機能はあります。
最初はこれとランキングだけでした。

しかし「誰からもお題が来ない」って状況が想像出来たので、誰でもお題を投稿＆取得できる「お題タンク」を作りました。
今では、ほとんどの投稿がお題タンク起因でスタートしてます。
当初の想定とは違う形になってますが、ユーザーの使い方やサービスの色に合わせて進化してる感じで運営者としても楽しいです。

モチベーション管理

構想からローンチまで半年近くかかりました。
ほぼ使ったことない技術（Nuxt.js、Firesotre（NoSQL）、GCP、Node.js、TwitterAPI、Bootstrap）だったので、
キャッチアップ含めの工期です。
平日・休日関係無しで時間があればやりました。
GWも夏季休暇も９連休でしたが、全て費やしました。

しかし、モチベが落ちることは無かったです。
イケると思ってたから。

「個人開発はモチベ維持が難しい」と言ってる人の大半は「結果イメージに自信が持てなくなる」に尽きるのかなーと思います。
それは数々の失敗を重ねてきたが故の、経験則から来るものだと思ってます。
再現性の無さを何度も肌で感じていて、いつでも足を止められる状況。
そこを走り続けるのだからモチベ管理は重要なことなのでしょう。

しかし、僕にはその経験がありません。
（悟空語ジェネレーターは一発ネタで、PV狙ってないので）
経験が浅く、失敗体験の少ないうちは「これはイケる」と、根拠無き自信が持てるモチベのボーナスタイムだと思います。
そして、その自覚がありました。なので、あえて妄想を膨らませてました。
「希望売却額は１億です。ただしSNSに金額を公表して良いなら5,000万でいいです」程度のことは妄想してました。
どうせ何も分からないのだから、不安よりポジティブになる事考えた方が得という判断です。

これから個人開発やってみたいなと思ってる方は
「自信なんて無いけど勉強目的だし・・・」で取り組むの、危険だと思います。
僕の観測範囲だと続かない人多いです（規模や工期によりますが）
もし僕が言語習得目的で個人開発していたら「質問箱クローン」を作っていたでしょう。
そしてローンチ出来たかは微妙です。途中で飽きそうです。
目標が言語習得ではなく「バズるサービスを作ること」だったのでクローンの先へ行けたし、ローンチまで漕ぎ着けられました。

知識なんて後からいくらでも付いてくるので、まずは一攫千金狙いましょう。
そのお金で何するかまでは具体的に想像しましょう。
それが「勉強」に繋がると思います。

検証結果

この記事では「なぜ作ったか」に留めておいて、
リリース直後の実績値については改めてQiitaに晒そうと思ってます。

ただ、まだ検証途中という意識が強いです。
開発してるうちに、もっと色々試したいという思いが強くなってきたので。
技術記事による集客効果だったり、
一般層に対するリーチ方法だったり、
boketeのような画像ボケ機能も導入して「個人開発における画像アップロード機能」も模索したいです。

おわり

「世の中の課題を解決したい」なんて大義名分は無い個人開発ですが、楽しいです。
本気で喜んだり、悩んだりしてます。
承認欲求だけでもモチベになるし、この経験を通して今までは遠目で見てた凄い方達と会話することが出来てます。
これほどコスパの良い取り組みは無いと思います。

リリース直後AdSenseコンソール見たら9円入ってました。
これ、普段の給与所得の比じゃないぐらい嬉しかったです。

フロント明るくないおじさんがWebアプリ作った話【悟空語ジェネレーター】

2019-09-29T11:28:32+09:00

2019年2月にQiitaへ投稿した記事のクロス投稿です。

はじめに

近年、個人開発がとても盛んになってきました。
クラウドサービスのリッチ化に伴い、個人でも簡単にWebサービスを運営できる時代となり、
個人開発者の熱意が更なる個人開発者の熱意を生む、素晴らしい連鎖が発生しています。

特に去年、2018年は爆発的な個人開発ブームでした。

「企業の一兵隊だった自分でも、何者かになれるんじゃないか」

「世界は俺のプルリクを待っているのではないか」

そう思わせてくれる1年でした。

かく言う私も、その熱意にあてられ去年1年間、
ひたすらQiitaを傍観していました。

私の業務はずっとサーバーサイドのJava開発。
フロント明るくないおじさんです。
はじめまして。きんみと申します。以後よろしくお願いします。

作ったもの

とは言え、私も兵隊の端くれ。
血湧き肉躍る開発は大好物なわけでして。
Web開発の真似事のような事はやっていました。年末頃から。
その集大成がこちらになります。

悟空語ジェネレーター
https://goku-lang.netlify.com/

日本語を入力すると、悟空語に変換します。
初回はブラックボックスなサービスとして遊んで頂きたいので、
変換ルールについては最後に書きます。

使った技術

Vue.js
JavaScript三大フレームワークの１つ。
公式ドキュメントの日本語がとても丁寧で、初学者の私でもとっつきやすいと感じたため使ってます。

kuromoji.js
JavaScript製形態素解析ライブラリ。
形態素とは文節の最小単位で、日本語文字列をこの単位で分解して、読み仮名や品詞情報を付与してくれます。
こちらのデモサイトが分かりやすいです。

Netlify
静的ホスティングサービス。
ちょー簡単にWEBサイト作れます。

ということで、このサービスは静的なサイトです。
冒頭に話した「リッチなクラウドサービス」は、ほぼ使ってません。
流行りのNetlifyを使ってますが、別にどこだろう動きます。
故・Yahoo!ジオシティーズでも多分動きます。

紆余曲折を経ての結果ですが、ちょっと後悔しています。
後述します。

仕組み

入力値をkuromoji.jsで形態素解析
各形態素の読み仮名情報をローマ字に変換
変換ルールに従い、正規表現でゴリゴリ変換
変換された形態素はひらがなへ戻す
変換されなかった形態素は元キーワードへ戻す
全形態素を文字列結合

たったこれだけです。

ハマったところ

1. フロントゼンゼンワカラナイ

学生時代にHP作った事ありましたし、少しですが業務でjQuery等をイジる事もあります。
しかし、いざ勉強をしてみるとそのカオスっぷりに腰が抜けました。
フロントなんて刺身にたんぽぽ乗せてるだけと思ってた自分を殴りたくなりました。

まずは基本となるHTML5、というより脱TABLEタグから入り、
ES6、Vue.js、React等の公式ドキュメントや入門記事をサーフィンして
Hello Worldな日々を4〜5日程続けました。
広く浅く現代の技術に触れて、無知の知を得る事に徹しました。

2. 形態素解析

React + Kuromoji を使ってブラウザ上で形態素解析
こちらを参考に、Vue.js上でkuromoji.jsを動かせるようにしました。

まずはnpm install kuromojiした後、辞書を公開ディレクトリへコピー。

$ cd project-directory
$ cp -a node_modules/kuromoji/dict public/

下記のようにしてVue.js上でkuromoji.jsを動かしました。

ポイントは下記です。

var vm = this

通常、単一コンポーネント内ではthisでプロパティを参照するが、

builder内でも参照できるようにグローバル変数に格納する。

async / await

builder.build は非同期処理の為、async / awaitを使う。

vm.outputToken = token

形態素解析後のトークンをプロパティへ格納する。

この勘所が全く分からずハマり、Vue.js上でkuromoji.jsを動かす事は一度諦めて、下記を検討しました。

代替品としてRakuten MAの使用
GoogleCloudFunctions（GCF）にkuromoji.jsを置いてAPI化
GCFにPykakasi（Python製形態素解析ライブラリ）を置いてAPI化
MecabをPythonで叩くAPI作成
外部APIサービス（Yahoo!JAPAN テキスト解析WebAPI等）の使用

箇条書きで書きましたがそれぞれ、調査して、コードを書いて、ハマって、諦めてを繰り返してます。
1行につき1〜2日は費やしています。
もっと頑張れば、いずれも実現可能だったかもしれませんが、最終的に「ブラウザ上でkuromoji.jsを実行」に回帰しました。
選定した訳ではなく、現段階の私の技術力ではこれしか出来なかったのです。

3. ローマ字変換

今回の処理は、
入力値をローマ字に変換 → 解析 → ひらがなへ戻す
というフローになります。
便利なJS製のカナ/ローマ字変換ライブラリがいくつかありましたが、
どれもヘボン式で不可逆でした（とうきょう → tokyo → ときょ）
また、解析は正規表現で行うため[sa,shi,su,se,so]のような不規則な変化は避けたく
可逆なローマ字変換処理を自前で作成しました（とうきょう → toukyou）

4. CSSフレームワーク

このアプリはドラゴンボールのネタアプリです。
もちろん、CSSフレームワークはBulma（ブルマ）を使ってます（ﾄﾞﾔ

言いたかっただけです。特にハマってません。

BootstrapからjQuery依存を省いた軽量なCSSフレームワークです。
公式ドキュメントや、下記記事を参考にサクっと導入出来ました。素晴らしい。
CSSフレームワーク BULMA チュートリアル①

マーケティング

フロント技術の学習が目的だった為、開発以外の何かを行うつもりはなかったです。
しかし、せっかくWebアプリを公開するならば、使ってもらえるよう努力したい。
これもまたWebの学習。「やらない」はただの機会損失、と思い

悟空なりきりアカウントをフォローしてみました。

やったぜ！！！よろしくな！！ https://t.co/kVgRtneAMp
— きんみ / 🎍ついぎり🎍リリースしました🎉 (@_kinmi) 2019年1月21日

今のところ、使って頂いた形跡はありません。

2019/4追記
いつの間にかこちらのなりきりさん、アカウント削除されてました。。

しかし、Twitterで公開したことで、多くのフォロワーさんに使って頂き、バグ報告も多数頂戴しました。
テスト不足が露呈した結果ですが、ローカルで動かしていただけじゃ気付かず終わっていたと思います。
公開して得られる学びの多さを痛感しました。

公開後のバグ対応

① iPhoneでは表示されない問題

Twitterで公開した直後の出来事でした。

見れないです・・・iPhoneだからですかね(´・ω・｀)
— 無職やめ太郎（本名） (@Yametaro1983) 2019年2月2日

はい、Chromeでしかテストしてません。。。
Safariで開いてみたところ、ブランクページが表示されました。

変換処理で多用していた正規表現の「後読み」が原因でした。
2019/2現在、対応しているブラウザはChromeだけのようです。
ここでJSが落ち、レンダリング自体されない事態に陥ってました。

先読みは使えるとの事だったので下記を参考に、文字列を反転させてマッチさせるという荒技を使いました。
Javascriptでの正規表現の後読みの代替

② ぱい◯いでか美さん対応

ぱいぱいでか美 https://t.co/ESyx59epVx #悟空語ジェネレーターこれは「ぺぇぺぇでか美」にならへんのかいw
— 無職やめ太郎（本名） (@Yametaro1983) 2019年2月3日

想定外です。ワケが分からない。
ぱい系ワードは沢山テストしたのに、何故でか美さんだけ変換されないのか、、、

原因は「ぱいぱいでか」を識別不可なワードとして解析され、
本来カタカナである読み仮名情報がひらがなになっていました。
私の仕様把握不足です。
前提としていた仕様が崩れ、デスマーチが始まります。

やべぇ…でか美さん手強い…原因っぽいの直したら「ぺぇぱいでか美」ってなった、、どんな処理通ったらこうなるんや… pic.twitter.com/gwF0SffzKS
— きんみ / 🎍ついぎり🎍リリースしました🎉 (@_kinmi) 2019年2月3日

ぐあぁぁあ！！！ちくしょーーーー！！！ pic.twitter.com/oLCeRtNyD9
— きんみ / 🎍ついぎり🎍リリースしました🎉 (@_kinmi) 2019年2月3日

現在は正常に「ぺぇぺぇでか美」となるのでご安心ください。

やらなかった事/やれなかった事

1. バックエンド開発

当初の学習目標は「Firebase Hosting + Cloud Functionsを使ったサーバレス開発」でした。
しかし、結果としてはバックエンド処理の無い、文字通りのサーバレスとなってしまいました。

辞書ファイルをキャッシュするため、初回の変換は超絶重いうえに、挙動のクライアント環境依存が強すぎます。。
友人はスマホの速度制限が来ていたのか、５分かかったと言っていました。
別の友人はAndroid版Edgeなるものを使っていて「動かないよ」と言ってました。
やはり、コアな処理は裏に持たせるべきですね。

また、ユーザが変換したワードの収集が出来ません。
リリース後のメンテナンス作業を見越した場合、生きたデータは貴重です。
こんな小さなネタアプリでも、バックエンド処理は作るべきでした。

2. OGP作成

ここは捨てました。ついでにファビコンもVueデフォルトのままです。
作り出すと拘ってしまい、リリース延期に繋がると思ったからです。
バズを狙う場合は必須ですが、、、

ただ、こちらの記事を拝見して
Vue.jsとFirebaseでOGP画像生成系のサービスを爆速で作ろう
OGPとしてSNSに共有するのは技術的にも面白そうと思ったので、近いうち導入するかもしれません。

モチベーション管理

私のモチベ傾向として、完成までの道筋が見えたら熱が冷めます。
手探りでやっている時が一番楽しいんですよね。
過去にはリリースまで行かず、中途半端に終わったスマホアプリが幾つかあります。
今回も二の舞になるのではないか、という懸念があったので、
完成が見えた段階で@jabbaさん作のmobet を使いました。

週末振休含めて４連休なので٩(๑òωó๑)۶今お遊びで作ってる「悟空語ジェネレーター」を公開する。 https://t.co/Nuhjm7PCtp #モベット @_kinmiさんから
— きんみ / 🎍ついぎり🎍リリースしました🎉 (@_kinmi) 2019年1月23日

しかし、残念ながらこの４連休にインフルエンザにかかるという痛恨のミスを犯してしまい未達成です。
「未達成と判定するまで（期日から判定まで五日間の猶予があります）には完成させる」をモチベーションにリリースまで漕ぎ着けました。

変換ルール

最後に変換ルールです。
当アプリの発想は下記ブログエントリーからです。
野沢雅子語の活用けぇ（活用形）
変換ルールはこちらを肉付けした形になります。

1. 母音[a, i] + [i, e] => 母音[e] + 'ぇ'
e.g.) 最初 → さいしょ → saisyo → selesyo → せぇしょ

2. 品詞：動詞に含まれる 'る' => 'っ' 文末の場合は 'っぞ'
文末かつ、動詞＋助動詞の場合は後続の助動詞を削除しています。
kuromoji.jsでは単語の原型（サ行変格活用前、等）のワードも取得でき、そちらもチェックしています。
e.g.) するから → surukara → sultukara → すっから
します(する + ます) → suru → sultuzo → すっぞ
帰ります（かえる + ます） → kaeru → keleltuzo → けぇっぞ(ルール1と2の併用)

3. 一人称 => 「おら」、二人称 => 「おめぇ」
Wikipediaから一人称と二人称の一覧を作り、固定値で変換かけてます。
「貴様」が代名詞として判断されなかったので、「品詞＝代名詞」の条件はつけてません。
ベジータの台詞を悟空語に変換したかったので。

上記がデフォルト挙動であり、なまりレベル：普通です。
なまりレベル：強い/超は上記に加えて固有の変換ルールが加わります。

強い：母音[o] + [i, e] => 母音[e] + 'ぇ'
e.g.) におい → nioi → niele → にえぇ

超：3文字のローマ字(ltu 等)以外の母音全て => 母音[e]
e.g.) オッス！おら孫悟空！→ oltusu！orasongokuu！ → eltuse！eresengekee！ → えっせ！えれせんげけぇ！
(※1)

なまりレベル：超は文字だとよく分からないですが、声に出すと意外と読めます。
他のルール発見された方は教えてください！

おわり

次は、すげぇＷＥＢせぇとつくっぞ。
（次は、凄いWEBサイト作る。）(※2)

その他参考サイト

JavaScriptで正規表現（文字列置換え編）

※1 :「孫悟空」だと大丈夫ですが、「悟空」は「さとるそら」と読んでしまいます。
※2 : なまりレベル：強