ENGINEERING&RUN

26.2マイルを走る僕の旅

Railsにおける論理削除

今年はほそぼそとしたエントリーでもちゃんとブログを書く。
しっかりとした内容は学習記事にまとめていく。

Railsで論理削除をしたい

destroyメソッド物理的にレコードを削除してしまうと、後で復元ができなくなってしまうなどの弊害がある。
レコードに「削除しました」という情報を持たせ、論理的に削除するのが一般的。

※それでもSIer時代、大手生保システムでは物理削除をしており障害発生時の復元が面倒だったなどがあった。
物理的に削除しないとレコードが増えすぎててしまう、退会後の顧客情報を持ちたくないなどのときは物理削除をすることもある。 scaffold時のdestroyメソッドは物理削除をするので、論理削除に変えてみる。

  def destroy
    @hoge.destroy #物理削除
    respond_to do |format|
      format.html { redirect_to conversations_url, notice: 'Conversation was successfully destroyed.' }
      format.json { head :no_content }
    end
  end

まずdeleteフラグをカラム追加しmigrateする。
:hoge, :deleted_flg, :boolean, null: false, default: false

そしてcontrollerを論理削除に変える。

  def destroy
    @hoge.deleted_flg = true #削除フラグを立て論理削除
    @hoge.save
    respond_to do |format|
      format.html { redirect_to conversations_url, notice: 'Conversation was successfully destroyed.' }
      format.json { head :no_content }
    end
  end

削除されていないレコードかどうか、スコープを定義しておくと便利。
scope :active, where(deleted_flg: false)
アクティブなレコードを取り出すときはこう。
@hoges = Hoge.active

ちなみにparanoiaやkakurenboといったgemも出ているので使うのも手。

rubysherpas/paranoia · GitHub
alfa-jpn/kakurenbo · GitHub

ちなみに今回はフラグを持たせたが、deleted_atのような日付形式にし、Time.nowの値などを設定しておくとより便利。
いつ削除したのかログを見なくてもわかるし、障害発生時に「この日に誤って削除されたレコードを復元したい」のようなことも便利。

こんな形で初歩的な内容でも毎日書いていきたい。

自分で新しいサービスを作るにあたってのコツ

今まで何個も自分でWebサービスを作ってきたけど、完成までいくパターン、いかないパターンとあったのでメモとして残す。

f:id:eishis:20151219091609j:plain

失敗したパターン

完璧主義だった

きっちりしたコードを書いて、テストまで用意して…と張り切りたくなる気持ちはわかるが、小規模の開発であれば最低限の機能があれば良いし、リファクタリングの必要性もそこまでない。
本当に起業を考えている人であれば一回汚いものでも動くものを作って、作るエンジニアが入って来るか資金が入って外注し作りなおすほうが良い。
前にココナラの話を聞いたときにも、システムを全部作り直したとのことだった。

技術的に高度なことをしすぎた

技術を差別化ポイントとしているならまだしも、変に高度な技術を使う必要は全く無い。
複雑なアルゴリズムを使えばその分メンテナンスもしづらくなる。
インフラもロードバランサなんか最初はいらない。最初のユーザーなんて数人、数十人。
またフロントでもJavaScriptを使い過ぎないほうが良い。
ユーザーは別に自動スクロールやアニメーションをそこまで求めていない。
労力をかけすぎて疲れて開発を辞めてしまうことが一番のリスク。
何よりもリリースすることをゴールとしよう。

なんでも自作にこだわりすぎた

最初にデザインを凝りすぎて、でも結局納得いくデザインができなくて開発が止まってしまう。
そんな経験がある人も多いはず。
全部自作する必要はない。
外部のテーマサイトのテーマを使おう。
themeforestなどはものすごい数のテーマがある。
themeforest.net

有料テーマもコストパフォーマンスを考えると決して高くはないはず。
ロゴとかもココナラやfiverrを使って依頼してしまおう。
500円前後で簡単なロゴができてしまう。

coconala.com

www.fiverr.com

成功したパターン

周りに宣言をした

人は心が弱い生き物で、休みの日を使った開発だとなかなか続かない。
それは当然のことで「責任感」が無い為だ。
誰かにやらされるというよりは、「自分がやらねば」という意識だ。
そんなときは無理にでも周りに宣言をすると良い。こんなサービス作ってます〜とデザインだけでも見せたら良い。
そうすることで「嘘はつけない」という気持ちと責任感が働き、最後までやり切るモチベーションにもなる。

時間を決めて開発した

毎日帰宅後1時間する!土日のどちらかは8時間開発にあてる!など、具体的な時間を決めて開発をすると継続しやすい。
開発のリズムを作らなければ継続はできない。
人の心は弱い。これを自分で理解したうえでサービスを作らなければいけない。

まず初日に何かしらの形に残した

手書きのデザインでも、テンプレートを作ったモックアップでも何でも良いので、初日に形に残してしまおう。
「一歩踏み出した感」がなければその後の開発には繋がりにくい。
一番効果があったのはランディングページを作ってしまうことだった。
ペライチなどのサービスを使って作り、公開日まで記載したうえで一歩踏み出してしまうのが良い。

peraichi.com

こんなとこだろうか。
但し、ここからユーザーが集まるかとか、あるいはマネタイズまでいけるかというのは別の話になる。
今後記事にしていきたいけど、個人のWebサービスでもできるプレスリリースや、拡散の方法もある。

とはいえ、何もものがないとユーザーが集まる以前だ。
下手なものでも作ることで仕事に繋がることもある。
実際にフリーランスになってはじめての仕事は自作Webサービスのおかげでもらえた仕事だった。

何個ものサービスを出した今でも、新規のサービスを作るときには心が折れそうになることがある。
そんな人達が励まし合い情報交換できる場があればいいのにと思う。
今後作っていくか、誰かが作ってくれればいいなーと淡い期待を抱いている。

大変やさしいBackbone.js 1回目

Backbone.jsのまとめ記事はたくさんあるが、敢えて超初心者向きの記事を書いてみる。 わかりやすくする為に噛み砕きまくるので少し語弊のある表現もあるかもしれない。

対象

JavaScriptを学び始めた。 フレームワークに手を出したいけど何ができるのか、そもそも概念もわからないような人たち。 他の言語もあまり知らないという前提。

Backbone.jsとは

f:id:eishis:20151217233633p:plain Backbone.jsとは、JavaScriptフレームワーク
ここでいうフレームワークとは、便利なパーツを集めてWebアプリケーションを作りやすくしてくれている便利ツールって思ってもらっても良い。
そしてBackbone.jsはJavaScriptを使って開発され、JavaScriptを使い利用できるフレームワークといえる。
他に代表的なフレームワークとしては、Rubyを使ったRuby on Railsや、PHPによるCakePHPなどがある。
フレームワークには便利なパーツや仕組みが用意されている為、割りとローコストで簡単にWebアプリケーションを開発することができる。
但し、デメリットとしては言語の勉強以外にフレームワークの勉強が必要だということ、またそのフレームワークというレールを脱線できない、つまりたくさんカスタマイズするには少々不便なところもある。

つまり、Backbone.jsとは何かと言われたら、JavaScriptを使ってWebアプリケーションを効率的に開発できるフレームワークツール、と最初は覚えてもらって良いと思う。

ふー、眠いので続きはまた明日。
第100回くらいまでにはまとめたい。

IBM Watsonを使って簡易版電子彼女的なものを作ってみる(設計編)

先日、IBMのWatsonを使ったハッカソンがあった。
入賞すればWatsonの無料券やスマートデバイスなどの副賞があったのだけど、残念ながら入賞できなかった。

watson-hack.strikingly.com

Watsonはつい先日、一部機能について日本語対応したので今後使われるシーンも出てくると思う。
なので簡単な活用法をご紹介したい。

 

まずWatsonとは

IBMのサイトを見るとこのように定義されている。

Watson(ワトソン)は、コンピューターでありながら、人と同じように情報から学び、経験から学習するコグニティブ・テクノロジーです。

 

 

www.ibm.com

 

世間では「人口知能」と呼ばれているが、IBMの方はコグニティブ(認識・思考)という表現を強調していた。

これには自分もすごく共感できる。やっぱり知能ではないかなと思う。

まぁ何を持って知能とすべきかみたいな話になると延々と終わらないので、要は画像や文章、音声を認識したうえで適切な答えを出し、またその為の学習を行うことができるシステムだと言える。

 

どんなことができるのか

 上記の通り、画像や文章、音声を認識することができる。
また大規模なデータ解析もIBM BluemixというWebプラットフォーム上で簡単に操作することができる。

BluemixはPaasでherokuみたいなもの。実際にherokuの技術を使っているみたい。

IBM developerWorks 日本語版 : IBM Bluemix

例えば、ピザのデリバリー注文チャットシステムや、音声でのブログ投稿システムなんていうものも割りと簡単に作ることができる。

実は使うことができるAPIはここで紹介されているだけで19種類にも及ぶ。

www.ibm.com

 

電子彼女を作ってみる

では本題に入って、簡易電子彼女的なものを作ってみる。

仕様としては以下の通りとする。

1. チャット形式で会話を行うことができる。
2. 最初はわからない単語が多くても少しずつ覚えていくことができる。
3. ユーザーに合わせた会話をすることができる。

 

ちなみに3が無いと悲しいことになる。
毎回名前を覚えてもらえず、不特定多数の男性に愛想を振りまく彼女なんて嫌すぎる。
今回は映画herのように各ユーザー毎のデータも中央制御されているようなことはないので、どんな会話をしても他のユーザーにばれることはない。

her.asmik-ace.co.jp

 

実現方法

今回は敢えてBluemixを使わず、Amazon Web Servicesで環境を構築し、Rubyで実装していく。

使うAPIは下記2つ。

・dialog

・Natural Language Classifier

 

dialogはその通り、会話をすることができるAPI
といっても何か考えながらではなく、予め設定しておいた文言を返すレベル。

本来であればその処理も「ゆらぎ」を感知することができる、構文解析→意味解析ができるのだけど、実は日本語版ではそこまでできない。

英語版のデモはこちら。ピザの注文に関するチャットをすることができる。

Dialog

 

完全一致で答えを入力しなければならないとなると、少なくとも数万以上の問答を教えなければいけなくなる。

そこで使うのがNatural Language Classifier(NLC)、つまりクラス分類処理のAPIだ。

これは、例えば何か質問したものに対して「〜について話されている可能性が〜%」という予測を返すことができる。

そしてそのパターンはある程度曖昧なものを学習させることができる。

つまり、ある程度パターンをNatural Language Classifierに学習させておき、そのパターンに合う回答さえdialogで設定してしまえば自然な会話をすることができるということ。

 

ちなみにNatural Language ClassifieerのインプットデータはCSVで入力する。シンプルにインプット、アウトプット(分類するクラス)の2カラムで設定する。

すごくざっくり書くとこんな感じ。

 

質問内容 分類内容

"休みの日は何してるの?","ask_hobbies"

"好きな食べものはなに?","ask_foods"

 

これで"休みの日は何するの?"や"お休みの日なにしてる?"といった表現の揺らぎについても、高確率で分類することができる。

そしてdialogのほうはその分類に対しての答えを定義する。
その為にはXMLで質問に対する回答を書かなければならない。

つまり、ユーザー→Natural Language Classifier→dialog→ユーザーという流れ。

少しまどろっこしいけどこれで表現を丸めることができる。

 

学習させる

NLCでは最低15,000以上の学習データが必要と言われている。
それを手作業で入れていくのはなかなかしんどい。
もちろん辞書データなど公開されているものから取ってくることもできるが、せっかくなのでそこも学習させていこう。

精度の関係もあり、NLC、dialogで拾えなかった表現を毎日チェックし、正解を教えるという教師あり学習で進めていく。

まぁ簡単なもので、会話の内容をNLCに対してpost処理を行うと、ステータスコードと現時点での一番自信のある回答を持ってきてくれる。そのステータスコードが拾えなかったものを指す場合にDBに質問を記録していく。
dialogも同様にできなかったものを拾っていく。

APIは割りと簡単に実装することができる。

www.ibm.com

そして集めた辞書に無いデータについて、管理画面から簡易入力フォームで正解を教えてあげれば良い。

フォームからNLCのCSVやdialogのXMLに日時でも即時でも更新処理をしていけば、段々と賢くなるという仕様。

 

インタフェースは悩むが、仕様自体は至極シンプル。
一日もあればできると思う。

とはいえ実際のソースが無いとなかなかイメージしづらいと思うので、よっぽどのことがあればソースをブログで公開したい。

 

FoodTechイベントでのRettyの機械学習システムの話が興味深かった

食事×テクノロジーのFoodTechイベントに参加してきた。

peatix.com

その中でRettyさんのやっている画像処理、自然言語処理が興味深かったのでまとめてみる。

Rettyは実名のレストラン口コミサイト。

retty.me

今年に入って10億円もの資金調達をするなど、乗りに乗っているスタートアップだと思う。

jp.techcrunch.com

今回、イベントで話されていたのはキーワード抽出と画像処理についてだった。 機械学習を取り入れるまでは全て人力でやっていたという。

キーワードを抽出について

これは下記のような流れで行っているとのこと。

  1. 投稿された口コミから形態素解析を行う
  2. キーワード候補を抽出する
  3. 内部で持っている辞書とマッチング

ちなみに形態素解析MeCabを使用しているとのこと。 MeCabオープンソース形態素解析エンジン。使いやすく処理も早いほうだと思う。

MeCab: Yet Another Part-of-Speech and Morphological Analyzer

他にも形態素解析で有名なところだとYahoo!の日本語形態素解析だとか、言語郎といったものもある。

developer.yahoo.co.jp

gengoro.zoo.co.jp

一番使われているのは恐らくRosetteかな。

日本語 | Basis Technology

Rettyの話に戻ると、一旦形態素解析されたものから名詞だけを取り出しキーワード候補としている。 ただMeCabに無い新しい言葉や口語はどうしても揺れてしまうとのこと。

そして最後は内部で持っている辞書とマッチング処理をするらしい。 今までアルバイトの人たちがコツコツ人力で抽出した500,000もの単語が辞書になっているらしく、泥臭い作業の上に成り立っている。

もちろんこれだけでは拾えないものも多いので、管理画面のようなもので人力チェックをしているそう。

画像処理について

これは投稿された写真について、料理、内観、外観、メニューのどれについてのものか自動識別しているらしい。 8割の正答率は達成できているとのこと。

仕組みとしては、Deep LearningフレームワークであるChainerとAlexnetを使い、学習用画像を20,000枚使い覚えさせたらしい。 更に学習素材を増やす為、この20,000枚を反転させたり角度を変えるなどし、倍まで増やし覚えさせたとのこと。

ちなみに以前にYahoo!さんの話ではCaffeを使っていると話を聞いた。

Caffe | Deep Learning Framework

chainer.org

ちなみにAlexnetといえば、ILSVRC 2012でカナダのトロント大学がぶっちぎりの優勝をしたことで有名。 ここからDeep Learningによる革命が起きた。

http://www.nlab.ci.i.u-tokyo.ac.jp/pdf/asj20141215.pdf

Rettyでは正解、不正解を教え、それを100回繰り返す。 ただ、どうしてもメニュー写真に料理が映っていたりすると誤認識してしまう。 結局は人力のチェックが必要で、その承認処理がないことには表に出ないみたい。

今後

東京オリンピックに向けて海外の方に向けた展開をする為に、機械翻訳ができないか検討しているとのこと。 これは難しいだろうなと思う。Google翻訳ですら今の精度だから。

感じたこととして、何よりRettyさんは膨大なデータを内部で持っているのがすごい。 特にどこかをクロールして取ってきた情報ではなく、数年でこれだけの大規模なデータベースを持てている。 ユーザー数ももちろんだけど、やっぱりデータを持っているところは強い。もちろん宝の持ち腐れにしないようにしなければいけないし、それに備えた設計を最初からしなければならないと改めて感じた。

ちなみにこのイベントで食べたダチョウ肉は馬肉のような味だった。美味しかった。

WordPressとTwilioを連携させる

やりたいこと

  • WordPressの問い合わせフォームから来た問い合わせにSMSで返信したい

まずTwilioに登録する

無料で登録ができる。
通話のAPIも使えるみたい。
ただ実際にメールを送るのは有料。
Twilio | Try Twilio Free

番号を登録する

一応ここにテスト用のアカウントがある。SMSの送信はできないがデバッグができる。
Twilio Cloud Communications - APIs for Voice, VoIP, and Text Messaging 実際に送信したい場合はトップページ右上から番号を購入する。

プラグインをインストールする

APIが丁寧に開設されている為、自作でプラグインを作るのも難しくないが、今回はwp-twilio-coreを使う。
ja.wordpress.org

有効化後、設定からまずアカウント情報を登録する。
Twilioのアカウント情報のキーとトークンを入力する。
f:id:eishis:20151121140117p:plain
送りたい番号とメッセージを入力するだけ!
f:id:eishis:20151121140158p:plain

TwilioとWordPress連携の可能性

例えば美容院に予約あった場合、直前にSMSで内容確認メールを送ることもできる。
contact-form7のメールアドレス欄と予約日時をカスタムフィールドにしてしまえば、wp-cronでそのカスタムフィールドにtwilioから自動的にSMSを送ることができる。 通常のメールよりも開封率が高いため、予約確認などはSMSを使うと良いかもしれない。

自己管理用のWebサービス作ったら生産性が上がり仕事もいただけた

※3年以上前の記事だけど下書きにあったので公開してみた。


自己管理が得意でない自分がフリーランスになって3ヶ月。
Webサービスを開発し、だいぶ効率よく仕事をできるようになったうえ、数社からお仕事をいただけているのでそのまとめ。

作ったサービス

タスク管理&時間計測のサービス。
f:id:eishis:20151116001154p:plain 毎日どの作業に何時間当てるかをざっくり見積もり、実際に作業を計測する。
作業の時間は所属するプロジェクトごとに集計することができ、何にどれくらい時間を使ったか把握しやすい。
自分専用の為、そんなにUXも考えずに作った。

きっかけ

小さい頃からとにかく自己管理が苦手だった。
時間があればはてな2chまとめサイトを見てしまう。
togglやaTimeLoggerなど使ってきたが、togglは「予定を立てる」という使い方はできず、PCを常に使っている為にaTimeLoggerは使いづらく止めてしまった。

Toggl - Free Time Tracking Software

aTimeLogger 2

aTimeLogger 2

  • BGCI
  • 仕事効率化
  • ¥600

この課題解決の為、毎日どの作業に何時間当てるのか、また今どの作業にどれだけ時間を作っているのか可視化すればいいのではと思った。
そしてこの課題を解決するサービスを開発してから開業しようと決め、実際にそうした。

効果

こんな効果があった。

  1. 無駄な時間を「もったいない」と感じられるようになった。
  2. 無理な計画を立てないようになった。
  3. 新規サービス開発案件の依頼が来るようになった。

1についてはtogglを使っていても感じられたことだった。
はてなまとめサイトを見ている時間も計測してみると、こんな時間を費やしてたのか!と驚かされる。
また仕様上マルチタスクができない為、タスクを絞ったことで集中力が高まった。

2はtogglなどでは実現できないと思う。
今日は仕事を8時間してジム行って家事もして技術書読んで...と計画していくと24時間を超えてしまう。
時間を費やす分、他の何かから時間を持ってこなくてはいけない。
あれもこれもとタスクを詰め込む癖が無くなった。

3は意外な効果だった。
こんなサービス作ったんです〜とイベントや仕事で合った人に話すと、人や仕事を何回か紹介してもらえた。
やはり自分の内に秘めてても何も始まらないし、アウトプットの重要性を感じた。
特にただの開発ではなく、新規サービスの開発に企画から関われる話をもらえるようになった。

何よりも自分のサービスは作っていて楽しいし達成感がある!

機能

毎日の目標を設定

f:id:eishis:20151116002240p:plain
地味な機能だけど1日のテーマを決めることでモチベーションが上がるし、1日が終わった後に達成感がある。

プロジェクトを設定

f:id:eishis:20151116002245p:plain
家事や仕事などプロジェクトを追加する。
タスクはプロジェクトに属し、プロジェクト毎に1日、1週間で費やした時間やタスクを閲覧することができる。

目標を設定し、時間を計測

f:id:eishis:20151116002250p:plain
赤文字が目標。下の方に合計欄がある。
この合計が24時間を超えてしまう見積もりは当然間違っているので、24時間以内に目標時間を調整していく。
タスクは設定画面からルーチン化することで、毎日登録せずともタスク化される。

使った技術

インフラ

自分用サービスなのでローカルでも良かったが、スマホからのアクセスもする為、さくらVPSでサーバーを立てた。 vps.sakura.ad.jp

デザイン

色合いが好きなのでマテリアルデザインを採用した。
Introduction - Material Design
一部Bootstrapも使っているが、好きなデザインであればあるほど開発意欲が湧いてくるので。
デザイン重要! 今回は特にテンプレートは使ってないものの、テンプレートサイトは多いようなので今後使っていきたい。

言語やフレームワーク

Ruby on Railsを使用。
COBOLPHPRubyしか使えない。 今後サービスを量産していくにあたってRailsが使い勝手が良いと判断して使用した。

1年半ぶりだったのでRails Tutorialを再度やり直した。 railstutorial.jp

ユーザーは自分1人だけどユーザー認証の為にdeviseも導入した。 ここがわかりやすい。

www.digitalocean.com

ぶつかった壁と対策

開発面での壁

やはりStack Overflowが一番役に立つ。
あと意外と言ったら失礼だけどteratailに質問をするとすぐ回答が来るので重宝した。 stackoverflow.com teratail.com

精神面での壁

どうしても仕事が入ってきたりすると自分のサービスが後回しになってしまう。
自分の場合は「〜日までにこのサービス開発します」と宣言して自分を追い込んだ。

今後したいこと

レスポンシブの為スマホでも見れるが、アプリ化したい。
音声認識Apple Watch対応をすればより正確な時間計測ができると思う。

また、この時間管理サービス以外にも数個サービスを開発している。
今後も継続してサービスを開発したいし、そんな仕事がしたい。