不格好エンジニア (引っ越しました)

wordpress.comから引っ越しました。

"Amazon.co.jp: Amazon Web Services パターン別構築・運用ガイド " Chapter1を読んだ

Amazon.co.jp: Amazon Web Services パターン別構築・運用ガイド: NRIネットコム株式会社, 佐々木 拓郎, 林 晋一郎, 小西 秀和, 佐藤 瞬: 本のChapter1を読んだメモ。

概要

本業以外のプロジェクトでインフラ構築も担当することとなり、本書を購入しました。 図解が豊富で、記述レベルが細かすぎず、要点をつかみやすい気がしました。 日進月歩で変わっていく領域なので、参考リンクが随所にあるのも嬉しい。

疑問

この章で気になったのは、Elastic Beanstalkのとこ。 フルセットでELBとか用意してくれるの、すごいじゃん! 良さそうに見えるが、あんまり活用している人が周りにいないのは何故だろう。。?

と思ったら、このあたりに詳しく書いてあった。

amazon web services - What is the difference between Elastic Beanstalk and CloudFormation for a .NET project? - Stack Overflow

WEB+DB PRESS Vol.77|技術評論社

のp.55辺りに詳しく書いてある。 Beanstalkは、アプリケーションコンテナを選択するだけで、フルセットの環境一式が準備できるが、Cloud formationと比較してフレキシブルではない、とある。

触ってみないとわからないけども、Elastic Beanstalkではミドルウェア導入済みのEC2インスタンスを使用するそうなので、技術選定(APサーバとか)の自由度は低くなるんじゃないかな。。。PaaSライクなものかな?

アプリサーバー対決 パート1:主なRubyアプリケーションサーバーの機能比較 [和訳] - Engine Yard Blog

Cloud formationの利点は、テンプレートが再利用できること。ステージングと本番で同一構成のシステムを複製したり、インフラ構成自体をバージョン管理したりすることも容易になる。

amazon web services - What is the difference between Elastic Beanstalk and CloudFormation for a .NET project? - Stack Overflow

まとめ

導入の容易さ

Elastic Beanstalk > Cloud formation

自由度

Elastic Beanstalk < Cloud formation

レアでモダンな 「iOS オールスターズ」を完全マスター

※個人的なまとめです。随時、追記していきます。

日本のiOS界隈を牽引するトップエンジニアが登壇する「iOSオールスターズ」に一般枠で参加してきました。

開催場所はOpenNetworkLab(代官山) 。参加申し込みは総勢370人。
企画・運営はdots様。受付に女性率が高く、柔らかい空気が印象的でした。

つかみの言葉は「本日はバレンタインデーでお忙しい中、お越し頂き、有り難うございます。」でした(笑)。メンタルの強さが問われる勉強会になりました。

Adaptive Collection View

登壇者:LINE株式会社 石川洋資氏


ishkawa (Yosuke Ishikawa) · GitHub

サンプルコードはこちら。

sandbox/Adaptive at master · ishkawa/sandbox · GitHub

まとめ

UICollectionViewでUITableViewを置き換える事で、同じソースコードでマルチデバイスに対応できるよ。
UICollectionView is a much more powerful set of classes that allow to modify almost every aspect of how your data will appear in screen, specially its layout,

Swift製ライブラリの良い書き方を考える

登壇者:株式会社ユビレジ 岸川克己氏


kishikawakatsumi/KeychainAccess · GitHub


まとめ

SwiftObjective-Cの違いを知る事が大切。
ライブラリにはPlaygroundを同時に提供してあげると良い。

You should know the difference between Swift and Objective-C.
Playground is helpful when you publish library code.

let UIWebView as WKWebView

登壇者:ヤフー株式会社 佐野 岳人氏

let UIWebView as WKWebView

こちらにも詳しく記載されています。


let UIWebView as WKWebView - Yahoo! JAPAN Tech Blog

WKWebViewとUIWebViewの違いについて、詳しく知りたい方はこちら。

WKWebViewとUIWebView

まとめ

WKWebViewを実装しながら、iOS7との互換性も考えて、下位互換としてUIWebViewも分岐して実装する方法。
WKWebViewはJSエンジンが高速、履歴を取得できるなどのメリットがあるので、積極的に使っていきたい。

How to use iOS WKWebView with UIWebView fallback.
You should use WKWebView if you want better performance and access to the latest web performance.

通信のパフォーマンス改善

登壇者:Wantedly inc 杉上洋平氏

iOS 通信のパフォーマンス改善 ・ iOSオールスターズ登壇資料

まとめ

NewRelic Mobile, PonyDebuggerで通信品質を分析した。
SDWebImageのメソッドをフル活用、WebP等を用いて通信のパフォーマンスを改善した。

How to improve communication performance.
NewRelic Mobile and PonyDebugger are useful to debug your application's network traffic.
Using webp, sd_cancelCurrentImageLoad, they improved communication performance.

効率的なアプリ開発のベストプラクティス

登壇者:グリー株式会社 矢口裕也氏

効率的なアプリ開発のベストプラクティス


WatchKit を実際にさわってみてわかったこと

登壇者:堤修一氏

WatchKitを実際にさわってみてわかったこと

長生きするために心臓に悪いリリースはもうやめよう

登壇者:長生きするために心臓に悪いリリースはもうやめよう


エンジニア戦記 ~ 小さなチーム 大きな未来 ~

登壇者:クラスメソッド株式会社 平井祐樹氏

エンジニア戦記 〜小さなチーム、大きな未来〜

まだiOSでリッチな演出に疲弊してるの?

登壇者:面白法人カヤック 布田隆介氏


Prottのご紹介

プロトタイピングツールProttのご紹介。
エンジニアの下川さんは気さくな方でした。またお話してみたいな。。
Prottに追加して欲しい機能についても、この機会にリクエストしてしまいました笑

関連情報


「iOSオールスターズ勉強会」に参加してきました #dotsios - Qiita


「iOS オールスターズ勉強会」に参加してきました - 強火で進め


ハッシュタグ

#dotsios - Twitter検索

Twitterまとめ
http://togetter.com/li/782943?page=16

所感

登壇者の方達だけでなく、参加しているエンジニアからも情報収集方法だったり、ちょっとしたTipsを教えて頂きました。余談ですが、会場で配布されたTech通信も面白かったです。
また次回、イベントに参加した場合にはレポートをシェアしたいと思います。

多分どこよりも早い ドッツサミット2015 レポート

dots.summit 2015とは?

フリークアウトのおしゃれオフィスでトップエンジニアによる講演を聞きながら、エンジニア同士の交流をはかる素晴らしいイベント。運営はインテリジェンスさんですね。それにしてもバスケットゴールやらビリヤード台やらがあって、遊び心いっぱいのオフィスでした。

『短納期&少人数でも実現できるCI』

株式会社LiB 米山諒氏

女性向け転職サイト、
キャリア女性のための会員制転職サービス | LiBz CAREER(リブズキャリア)を運営しているLiB 米山さんのお話です。
なんだかんだスピード優先されて、わやくちゃになるこのフェーズでも、CIやコードレビューを導入しているスタートアップのお話。すげーな。米山さん、いつ寝てるんだろう。確かまだ設立1年経ってないはず。。。LiBのエンジニアカルチャーを定義したり、コードレビューを行う文化だったり、エンジニアを大切にする風土が伝わってくるお話でした。

『1000万ダウンロードアプリ『メルカリ』を支える技術』

株式会社メルカリ 久保達彦氏

インフラチームが自作したツールOSS化しています。エンジニア魂あふれる人たち。

『SPEEDA/NewsPicksを支える技術の選定手法』

株式会社ユーザベース 竹内秀行氏

技術を選定する際に大切にしているポイント、というお話でした。
「ただそれを作りたいから作る」「ただ自分がその言語を使いたいから使う」という公私混同に陥ってはいけない。
「その技術はユーザに価値を届けているのか」、忘れがちな視点ではあるので、改めて肝に銘じたいと思います。

Gunosyを支えるGolang

株式会社Gunosy 松本勇気氏

ニュースキュレーションアプリ Gunosyを開発している松本さんのお話。サーバ側からのレスポンス(JSON)でアプリのUIを変更したり、Go言語を採用したり、技術的な取り組みも先端を走っている感があります。

競争力を生み出す為に、メンバーが成長する為の仕掛けを色々と行っている点が印象的でした。
チームビルディングの部分では「Grow Your App」ではなく、「Grow Your Team」(個々人の成長が長期的には競争力になるのだ)、という視点は参考になりました。

『何故scalaを選んだのか? 〜 アドテクスタジオの場合 〜』

株式会社サイバーエージェント 神田勝規氏

20150207 何故scalaを選んだのか

スライドは、まだ公開されていないようで、残念。。。
scalaを採用した理由は、こちらにも詳しく書かれていますね。
http://careerlaboratory.jp/archives/742
Tech Talk ~ サイバーエージェントアドテクスタジオがScala言語を選んだ理由 | キャリア・ラボラトリー

Javaだと冗長になりすぎる所をシンプルに記述できたり、並列分散処理に優れていたり、といった点が好まれているようです。
トップダウンで導入した、というよりは社内勉強会を開いたり、新しい技術の習得に熱心な風土は素晴らしいですね。

『Dockerを活用したリクルートグループ開発基盤の構築』

株式会社リクルートテクノロジーズ 吉田尚弘氏

工事中。。。

『変わったUIを持つアプリ”へやくる!”』

株式会社ネクスト 大坪五郎氏

お題のアプリはこちらですね。FacebookのPaperを参考にしたというアプリです。

HOME'S へやくる!

HOME'S へやくる!

  • Next
  • ナビゲーション
  • 無料
かなり斬新なUIで、チャレンジングなアプリです。実装大変だっただろうな。。。
今度、ネクストさんの勉強会にもお邪魔したい!

大規模並列検索サービスGoogle BigQueryについて』

Google Inc. 佐藤一憲氏

ビジネスサイドからの
・ ディレクターの人でも解析、分析したい
・ブラウザから色々やりたい
といった要求にこたえやすいかもしれません。

Google BigQueryについては、こちらのスライドで丁寧に説明されています。

Google BigQueryを使ってみた!

Treasure Data と OSS

登壇者:トレジャーデータ株式会社 中川真宏氏

Treasure Data and OSS

FluentdなどOSSにコミットするエンジニアを多く抱えている会社さんなのですね。

『ビックデータ時代のビジュアライゼーション』

Tableau Japan 株式会社 飯塚桂子氏

http://eventdots.jp/eventreport/309318

『会員数180万人のマッチングサービスpairsの急成長を支える技術基盤』

株式会社エウレカ 森川拓磨氏

会員数180万人のマッチングサービスpairsの 急成長を支える技術基盤 ディレクターズカット版

インフラ構成などはここにも記載されています。


インフラエンジニア不在で120万人のユーザーを支える方法 | 株式会社エウレカ

『次世代のリアルマーケティングプラットフォームに挑戦するラクスルの開発体制について』

『ベストアプリW受賞を支える開発手法』

株式会社VASILY 今村雅幸氏


CTO対談!!

~ CEOが迫る!ヒットサービスを生み出す技術組織の作り方 ~
・モデレーター ランサーズ株式会社 代表取締役社長 秋好陽介氏
・株式会社VASILY 取締役CTO 今村雅幸氏
・株式会社ユーザベース 執行役員 竹内秀行氏

Q.CTOって何してるの?
A.広報とか技術戦略とか採用とか雑用とか。
コード書く時間は、やっぱり減った。

Q.成長するエンジニアとは?
A.ハングリーで、5分に1回くらい、サービスの成長につながる事を考えてるような人(僕は無理ですけどw)。組織に深くコミットして、終電とかになりながらも、でもインプットの時間もきちっと取れているような人。

Q.ダメなエンジニアを雇ってしまったら
A.今、思い返しても、そんな人いない。モチベーションの低い人を雇ってしまうと、全体としてレベルが下がる。入り口(採用)でどこまで慎重になれるか。どこまで本気度高くやれるかが大事です。VASILYではエンジニア10人呼んで、10対1で面接する事もあります。

そろそろ「パーフェクト Ruby on Rails」読んで本気出す ⊂('ω'⊂ )))Σ≡=─༄༅༄༅༄༅༄༅༄༅

筆者のスペック

Rails歴は1年ちょっとくらいです。お仕事ではiPhoneアプリとサーバサイドを行ったり来たりしています。

購入の経緯

とりあえず、日々の仕事については、ある程度こなせる様になって来ました。
ただ、Raisのベストプラクティスやイケてるスタートアップの開発フローと比較すると、色々と思うところがあり、Railsの世界観を学ぶため、本書を購入するに至りました。


Amazon.co.jp: パーフェクト Ruby on Rails: すがわら まさのり, 前島 真一, 近藤 宇智朗, 橋立 友宏: 本

こんな人にオススメ

  • 現職でRailsを使用している
  • Railsで簡単なTODOアプリとかなら、大体作れる
  • Modelが肥大化してきた時の対処法/設計指針を学びたい
  • TDDやってみたい
  • おすすめのgemとか教えてほしい
  • 環境構築 => 開発 => テスト => 本番環境構築 => デプロイという一連の工程をモダンな環境で行いたい

Rails初心者の方が、1冊めとして手に取る本ではない気がします。
Railsは全く初めて、という方であれば、こちらのチュートリアルを先にこなした方が良さそうです。


Ruby on Rails チュートリアル:実例を使って Rails を学ぼう

この分量、クオリティで無料ってすごい。

サンプルコード

こちらに、公開してくださっています。書籍のサポートページもあるようなので、そちらも併せてご参照下さい。

パーフェクト Ruby on Rails のサンプルアプリケーションを Github 上で公開しました - willnet.in


とりあえず、今の自分に必要そうな所だけ、丁寧に読みました。

第1章 Ruby on Railsの概要

環境構築方法や、Railsの設計思想に関するお話。
ActiveRecordの設計思想や、RESTのお話は、復習しておきたいですね。

第2章 Ruby on RailsMVC

MVCに関する記述は、意外と薄め。前提としてMVCって何なの?という知識は事前に必要な気がします。
REST、ルーティングについても、ここで復習できます。
StrongParametersについては、Rails4で導入されたものなので、現場の状況によっては知らない人もいるのかな?
variantsによるテンプレートの切り替え、特定のレイアウトを適用する方法は、次のお仕事でも使いそう。

第3章 アセット

必要な時に読み返せば済む領域だと考えているため、スキップしました。

第4章 Railsのロードパスとレイヤーの定義方法

MVCにあてはまらないモジュールをどのように管理するのか、その考え方について述べています。ロードパスとかもここで復習しました。MVCにあてはまらないレイヤーの設計指針については、第9章で更に掘り下げていきます。

第5章 開発を効率化するgem

Better Errorsとpryはさっそく使ってみたい。

第6章 Railsアプリケーション開発

実際にイベント告知アプリケーションを作成する過程を通して、知識を整理します。実務でRails経験のある人は、後回しにしてもよいかもしれません。

第7章 Railsアプリケーションのテスト

駆け足ではありますが、TDD、静的解析、CIまで一連の流れを解説してくれています。使用しているツールやサービスも実務でお目にかかる可能性の高いものだと思います。
本書とは直接、関係はありませんが、Rspec入門としては、こちらの記事がおすすめです。


Ruby - 使えるRSpec入門・その1「RSpecの基本的な構文や便利な機能を理解する」 - Qiita

第8章 Railsのインフラと運用

とてもコンパクトにまとまっています。が、インフラは扱う領域が幅広いので、個別のツールについては、別途掘り下げる時間が必要です。DevOpsやスタートアップに興味のある方は、ここにあるキーワードはおさえておくと良さそう。

第9章 より実践的なモデルの使い方

なぜ、バリデーションとコールバックをクラスに分離するのか、その必要性について納得いく形で答えてくれます。
サービスクラスの使いどころと、使用する際の注意点についても触れています。
業務で悩むのも、まさにこの「より実践的なモデルの使い方」だったりするので、今の自分にはぴったりだと思っています。
それなりに難しく、読み応えのある部分なので、何度も読み返したいです。

第10章 Railsを拡張する

タイトルからして明らかに上級者向きの内容ですね。会社でもOSSプロジェクトを立ち上げたいと考えているので、ゆくゆくは読ませていただきます!

まとめ

Railsエンジニアの2冊めとしておすすめ。みんなが勧めるのもよくわかる。
第9章は読み返したい。

Special Thanks!


『パーフェクト Ruby on Rails』を読んだ - きにきじ

【本場でも通じるふりかえりテクニック】アンチパターンとその対策

本場ってどこやねん。。。

"改善MTG(ふりかえり)"あるある

プロジェクトの節目に行うふりかえりMTG、改善MTG
これって、盛り上がらなかったり、自然消滅してしまう事も多いですね。その原因となるアンチパターンや対策について考えてみました。
上からメセニストとしてではなく、自戒を込めて書いています。

ふりかえる必要性を感じているメンバーがいない

本当に、ふりかえる必要性を感じているメンバーがいないのであれば、そのチームは完全無欠で理想的な状態にあるのかもしれません。ただ、そんなチームあるのかな。。。

ふりかえった事がなくてキョドる

いきなり"ふりかえりMTGやりましょう"と言われたら、ほとんどの人がどうしていいかわからない。
ただ、ちゃんと探せば、やり方まとめてくれてる人がいるんですね。勉強しようっと。
下のリンクは、めっちゃわかりやすいです。

ふりかえり会のススメ(進捗会議編)
http://objectclub.jp/download/files/pf/RetrospectiveMeetingScenario.pdf

一度のみ振り返り

こういうものは、一度で効果が出る方がむしろ稀なので、繰り返さないと駄目ですね。そもそも一度だけ振り返っても効果が計測できないですし。
自戒を込めて書きました。

効果がない(改善案が生かされない、実行に移されない)

プロジェクトの最後にふりかえりを行ってしまうと、こうなりがちですね。
この手のMTGは、プロジェクトの途中、まさに問題に直面している過程で定期的に行う方が良さそうです。結果をどう生かすのか、まずメンバー間で共有してからMTGを始めなければいけないのだと、お仕事を通じて学びました。

どうやって進めればいいのかわからない

何となく改善MTGを導入すると、一人一人が反省点を口にして、何となく終わってしまう。未来につながるお話にならない。そこでKPT。「型」を導入する事で、進め方をまず共有する。

批判の応酬、責任のなすり付け合いになってしまった

これ、僕もやってしまった事があります。。。そもそも、うまくいっていないチームだと、こういう場を設けた時に、一気に不満が噴出する事があります。これは解決が難しそうですが。。。
まずMTGの始めに、"keep(これからも続けたい、良い取り組み)"を挙げて、自分たちの成長を認め合うこと。

あとは、"**のせい"という論調になりかけた時に、「自分ならどうする?」「これからはどうする?」と自責で、未来志向で考えられるように声がけを行う事でしょうか。不思議なもので、第三者がこういった声がけを行うだけで、ほとんどの発言者は無意識のうちに自責で考え、未来に向けた思考を行えるようになるものです。僕自身も、何度もこの言葉に救われた気がします。

言葉の持つ力を甘く見てはいけないですね。

また、不満を抱えているメンバーには、MTGが始まる前に個別にお話をして、ガス抜きをする事も重要かもしれません。

Keep飛ばし

いきなり"Problem(問題)"から言及して、みんなどよーんとする。お通夜MTGの幕開け。
対策は、まずMTGの始めに、"keep(これからも続けたい、良い取り組み)"を挙げて、自分たちの成長を認め合うこと。まずMTGの始めに、"keep(これからも続けたい、良い取り組み)"を挙げて、自分たちの成長を認め合うこと。大事な事なので、2度書きました。

メンバー大杉

聞いている時間の長いMTGは、集中力が薄れがち。メンバーをむしろ3,4人に絞った方が良いのかも。あとは、発言者の時間を強制的に区切るとか、ポストイットを使うとか。

ほとんどのメンバーが効果を感じていない or 楽しくない

では、なぜ、メンバーが効果を感じていないのか。効果が目に見えないから、もしくはフィードバックを受け取るまでのサイクルが長過ぎるからではないでしょうか。
効果が計測できて、フィードバックまでのサイクルを短くする事ができれば、やっているうちに楽しくなってくるはず。では、どうすれば可視化できるのか、フィードバックを短くできるのか。

考えられる解決策としては、このあたりでしょうか。

  1. 可視化できるものを目標にする。
  2. フィードバックサイクルが長過ぎるものは、短く分割して、短期間にフィードバックを得られるようにする。

なげっぱなし、言いっぱなしのTry

誰が何時、何時までに、何をどうする。などより具体的で明確な内容に落とし込む。場合によっては、実行されたかどうかの確認方法まで盛り込む。
。。。。というより、こういう風に具体的に落とし込めないものは諦めて、本当に出来そうなものだけ、3つだけTryする、というのが良いかも。
短期間で、そんなに5個も10個もTryしながら、改善活動できない気がする。

【参考】

Project Facilitation From Hiranabe


アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE)

仕事を楽しくする【AWSを使わない】はてぶの記事をサムネイル付きでJSON配信する3ステップ

はじめに

類似するネタは、オンライン上に色々な方が書いて下さっているのですが、"サムネイルはAWS S3に保存しよう!"的なネタが多く、VPS一台で処理を完結したい自分にとっては、そのものズバリの記事がありませんでした。需要があるかどうかわかりませんが、書いてみたいと思います。

おおまかに実装方針を立てると、このようになります。

  • はてぶのAPIから記事を収集する(XMLをフェッチしてパース)
  • はてぶの記事URLからサムネイルを生成してDBに保存(dragonflyもしくはcarrierwaveを用います。どちらでも可能です)
  • 記事とサムネイルをJSON形式で配信する

今回は主要部分を抜粋してご紹介します。ソースコードはこちらに公開しております。

tjnet/geeknews-rails · GitHub

(1)はてぶのAPIから記事を収集する(XMLをフェッチしてパース)

まずはとにかく記事データが必要ということで、railsを用いて記事を収集します。データ収集に利用したのは以下のコードです。

#coding: utf-8
require 'pp'
require 'net/http'
require 'uri'
require 'rexml/document'

module Tasks
  class ArticlePicker
    # initialize article data
    def self.execute
      ActiveRecord::Base.connection.execute("TRUNCATE TABLE articles")
  
      feed_list = Feed.all
      articles = []
  
      feed_list.each do |feed|
        next if feed.url.blank?
        articles = fetch_and_parse(feed.url)
        save_articles(articles, feed.category_id)
      end
    end
  
    # save articles
    def self.save_articles(articles, category_id)
      return if articles.empty?
      pp '--'
      pp Time.now
  
      articles.each do |article|
      #pp sprintf('save %s of %d', article['title'], category_id)
      pp sprintf('save %s of %d', article['link'], category_id)

        Article.create!(
          :category_id => category_id,
          :title => article['title'], 
          :link => article['link'], 
          :description => article['description'], 
        )

      end
    end
  
    # return parsed articles
    def self.fetch_and_parse(url)
      res = fetch(url)
      articles = xml_to_array(res)
      pp articles
      articles
    end
  
  
    # fetch response from url
    def self.fetch(url)
      pp URI.escape(url)
  
      uri = URI.parse URI.escape(url)
      res = Net::HTTP.get uri
  
      res
    end
  
    # return parsed XML
    def self.xml_to_array(xml)
      items_rx = []
      doc = REXML::Document.new xml
      doc.elements.each('//item') do |e|
        i = Hash.new
        i["title"] = e.elements['title'].text
        i["link"] = e.elements['link'].text
        i["description"] = e.elements['description'].text
        items_rx << i
      end
  
      return items_rx
  
    end
  
  end
end

リトライ処理などは、別のスクリプトに切り出しています。

    begin
      pp "updating article ..."
      Tasks::ArticlePicker.execute
    rescue Exception => e
      pp "[ERROR] update_article #{e.message}"
      retry_count += 1
      retry if retry_count <= 5
      pp "retried 5 times so exit"
      exit
    end
    pp "updated article"

(2)はてぶの記事URLからサムネイルを生成してDBに保存(dragonflyもしくはcarrierwaveを用います。どちらでも可能です)

URLからサムネイルを作成するためにwkhtmltoimageを実行しています。
DBへの保存はcarrierwaveを用いています。

   # Generate and assign an image or set a validation error
    begin
      tempfile = temp_thumbnail_path
      cmd = "wkhtmltoimage --quality 40 --width 50 --height 50 \"#{self.link}\" \"#{tempfile}\""
         p "*** grabbing thumbnail: #{cmd}"
      system(cmd) # sometimes returns false even if image was saved
      
      self.photo = File.new(tempfile) # will throw if not saved
      self.save
    rescue => e
         p "*** thumbnail error: #{e}"
      self.errors.add(:base, "Cannot generate thumbnail. Is your URL valid?")
    ensure
    end

DBへのデータ保存が終われば、wkhtmltoimageで生成した一時ファイルは不要となりますので、modelのコールバックで後始末します。

 #Cleanup temp files when we are done
  after_save :cleanup_temp_thumbnail
   
  # Cleanup the temporary thumbnail image
  def cleanup_temp_thumbnail
    File.delete(temp_thumbnail_path) rescue 0
  end

(3)記事とサムネイルをJSON形式で配信する

ここまででDBに画像データを保存できました。後は、これをcontrollerからJSONとして配信します。

class Api::V1::ArticleController < ApplicationController
 # return articles
 def index
   render json: Article.list(request)
 end
end
 # 
 #= return articles as array of hash
 #
 def self.list(request)
   res = Array.new
   Article.all.each do |article|
     res.push({
       :category_id => article.category_id,
       :title => article.title,
       :link => article.link,
       :description => article.description,
       :image_url =>(article.photo.blank?) ? '' :  "#{request.protocol}#{request.host_with_port}#{article.photo.url}",
     })
   end
   res
 end

記事URLを生成するために、controllerからrequestを受け取っています。
もう少し簡潔に書けそうですが。。。

はまりどころ

うまく動かないときは、このあたりをチェックしてみて下さい。

  • サムネイルを一時的に保存するディレクトリのパーミッションなど
  • public/以下のディレクトリ構造
  • 本番環境だけで動かないときは、デプロイ設定やrackサーバの再起動が正常になされているか

TODO

次は、このあたりに取り組みたいですね。

  • cronの設定
  • サムネイルのクオリティを向上させる
  • 静的ファイルの配信を高速化

【VPSか、AWSか、Herokuか】結局、最後はさくらVPS+Unicorn+Rails+Capistranoに行き着いた【構築スクリプト付き】

お仕事以外にも色々手を出しています。
主に知り合いの方とサービス作ってみて頓挫したり、細々とiPhoneアプリを開発してみたり、、まったり作っていきたいと思います。

サーバを用意する際の選択肢について

自分のサービスやアプリを公開するとなった場合、どうしてもサーバが必要になります(僕の場合、自前のAPIと連携しないアプリって何となくモチベーションが湧かないのです。もちろん、既存のAPIを叩くだけでも、アプリを作成する事は可能ですが、はてなブックマークの記事を取得するだけのアプリでも、後からレコメンド機能を実装したり、記事を独自アルゴリズムで分類したり、、、やってみたいですよね。)

現実的な選択肢

みなさん、どんな観点でプラットフォームを選択されてるんでしょう。
ここでは、3つの観点から考えてみました。

  • 学習コスト
  • 技術的制約
  • ランニングコスト

学習コスト

まずAWSは、AWSそのものの作法を覚えなければならない為、(ベースになるLinuxの知識+AWSの知識)が必要となり、学習コストは最も高そうです。
さくらのVPSに関しては、色んな方が構築方法を公開されていて情報量も多く、ピュアなLinux単体の上に構築していくため、AWSと比較すれば、把握する範囲は比較的小さくなります。一定の水準でセキュリティを保つ設定が出来ていれば、なんとかなりそうですね。流れとしては、いったんは手動でLAMP環境を作ってはサーバを初期化して、、、といった事を繰り返してみるのが勉強になった気がしています。SSHの設定を間違えてログインできなくなり、泣く泣くサーバを初期化したのも、今となっては良い思い出。さすがに今は忙しくなって来たので、Ansibleで構築手順を半自動化しています。

AWSVPSでサービス開発を行う場合、手間がかかりそうな所といえば、デプロイ環境の構築でしょうか。手元のMacで開発=>本番のさくらVPSにデプロイ、といった構成にしたい場合は、自分でこれを設定しなければなりません。

セキュリティの設定、デプロイツールのセットアップをすっとばしたい、という場合はHerokuでしょうか。
デプロイに関しては、Herokuは圧倒的に簡単です。
手元のMacで開発したプロジェクト配下で"git push heroku master"とかやれば、デプロイ完了です。最も初速の出やすい開発プラットフォームではないでしょうか。

技術的制約

今回は、ニュースアプリの作成を予定しているため、サーバにサムネイルを一時保存したかったのですが、Heroku単体ではそれができない為、色々検証した結果、Herokuは選択肢から外しました。
次にAWS。スタートアップ界隈では実質業界標準になってきている(気がする)AWSには、正直何でも搭載されている感があります。スケールさせやすかったり、Herokuで出来ないファイル保存ができたり、、。ただ、趣味の開発でここまで必要なのか。。と言われると正直必要ない場面も多そうですね。色々有りすぎるために、把握しないといけない範囲が増えて手が止まるのは嫌ですね。
さくらのVPSは、AWSみたいにポチポチインスタンス増やしてスケールさせたりは出来ません。ただ、ピュアなLinuxであり、root権限も付与されているため、1台にNginx+(Unicorn+Rails)+MySQL全部盛り、みたいな構成にするならVPSで十分ですね。

ランニングコスト

ちょっとした検証用のWebアプリケーションであれば、Herokuで十分な事もあるかもしれません。
ただ、DBは無料で使用できるレコード件数に上限があったり、重めのバッチ処理を走らせると課金されてたり、意外と制約が多いな、、、という印象です。というより、少し課金体系がわかりにくいです。
また、AWSに関しては、「いつのまにか結構課金されとる。。」という状態に陥りがちなので、サービスがスケールされる道筋が見えていない現状では選択肢から外しました(インスタンス立ち上げっぱなしで忘れてた自分が悪いのですが)。
さくらのVPSは月額定額なので、わかりやすさでは一番ですね。

開発環境/本番環境を構築する上での前提

  • 手元のMacが壊れても、開発環境を再現できる
  • 本番環境(さくらVPS)の設定はすべてAnsibleを通す

というあたりを意識して作りました。個人開発なら、Ansibleで自動化するのが、おすすめですよ。

開発環境

Ansibleを用いてvagrant上に(CentOS+Unicorn+Rails)の環境を構築します。サーバサイドの開発はVagrant上で完結します。
こちらの記事なども、参考になりそうです^^

【5分で学べる】Vagrant上にRailsをAnsibleでかんたんクッキング(CentOS6, MySQL, Rails4, Unicorn) - 不格好エンジニア (引っ越しました)

サーバ設定などのアップデート

開発環境/本番環境を問わず、すべてAnsibleを通して行っています。実際にCentOS+MySQL+Unicorn+Railsを導入するための構築スクリプトは、こちらに公開しています。

tjnet/vagrant_sakuravps_rails · GitHub

本番へのデプロイ

Railsプロジェクトのリポジトリにデプロイスクリプトを入れています。具体的にはCapistrano3(capistrano3-unicorn)を導入しています。
実際にはAnsibleでもデプロイは出来るのですが、Capistranoの方がRailsとの相性は良さそうです。staginやproductionといった複数環境へのデプロイに対応していたり、bundle、migration、unicornとの連携も考慮されており、使いやすいと思います。

作成中のサービスにCapistranoを導入した事例はこちら(config/deploy.rbのあたりは見よう見まねで、おかしい所が多々あるかもしれません)。


tjnet/geeknews-rails · GitHub


デプロイ設定をGitHubで公開するかどうかは、少し悩みました。ただ、ローカル(vagrant)のHostsファイルに本番環境のIPアドレスを記述するようにすれば、具体的なサーバの情報をGitHubに公開してしまう事もありません。アドバイスを頂けるチャンスもあるかもしれないですし、こんな情報でも誰かの役に立つかもしれないので、積極的にシェアしていきたいと考えています。

かかるコスト

かかるコストですが、シンプルに使ったサーバ台数x使用したVPSの月額料金です。

今後やりたいこと

  • CI環境の構築
  • TDD (後からでもテスト書こう)
  • 監視ツールの導入

今の構成がベストではないと思うので、まだまだ改善したいと思います。日々、勉強ですね!