Shoichi Matsuda's diary

このブログは移転しました。 https://shoma2da.net/ が新しいブログです。

【無料】herokuからメールを送信する

heroku Webサービス メール

お手軽でWebサービスが構築できてとても便利なheroku。
アドオンがとても充実していて無料でもかなり色々なことができます。

今回はそんなherokuでメールを送ってみたので手順をまとめておきます。
設定はとても簡単、しかも基本料無料です！

使用したアドオン

今回使用したのはSendGridのアドオンです。

f:id:shoma2da:20140301234712p:plain

選んだ理由は主に以下の２つです。

  • プロダクト名にBetaが付いていないので安定して動いてるのかなーと思い込み
  • 一日２００通のメールの送信までは無料

メールを送るまでの手順

アドオン登録

まずはSendGridのアドオン画面から登録を行うか、

f:id:shoma2da:20140302001257p:plain

もしくはプロジェクト内で以下のコマンドを使って

$ heroku addon:add sendgrid

でsendgridアドオンを登録します。

sendgrid内での設定

次にSendGridのページで設定作業を行います。（アドオン登録できていればherokuのアプリ詳細画面にリンクができています）
最初にこのページへ行くと×印が付いている個所があります。

f:id:shoma2da:20140302002053p:plain 

「Configure Account Settings」をクリックすると統計情報やテンプレートに関する設定が行えます。
僕は以下の設定で「Updating settings」しました。

f:id:shoma2da:20140302002253p:plain

これで全てのマークがチェック印に変わります。

sendgridパッケージの導入

ここからはローカルプロジェクトの設定です。
今回はNode.jsの場合で行っていきます。

その他の言語についてもherokuのドキュメントページで解説されていますのでそちらを参照してください。

Node.jsの場合の導入はnpm installを使って１コマンドです。

$ npm install sendgrid --save
コード記述

いよいよメールを送信していきます。
herokuのドキュメントページにもあるように以下のような記述をします。

var sendgrid  = require('sendgrid')(
  process.env.SENDGRID_USERNAME,
  process.env.SENDGRID_PASSWORD
);

sendgrid.send({
  to: 'receiver@domain',
  from: 'sender@domain',
  subject: "メールタイトル",
  text: "メール本文"
}, function(err, json) {
  callback(err);
});

あとはherokuにデプロイしてこのスクリプトを実行してみましょう。
上記の例だとreceiver@domain宛てにメールが送られます！

このスクリプトは基本的にはheroku上でしか動作しませんので注意です。
理由としてはprocess.env.SENDGRID_USERNAMEとprocess.env.SENDGRID_PASSWORDはherokuの環境上で設定される環境変数のため、ローカルでは値が用意できずにメール送信できません。（逆に言えばherokuにデプロイした状態でこれらの環境変数を直接見てソースを書き換えればローカルからでもメール送信できます。）

こんな使い方がおすすめ

無料枠の範囲ではユーザへのメール送信には向いていないような気がします。（一日２００件までなので）

そのため無料枠での有効なのはサーバの状態などを管理者にメール送信してお知らせするといった使い方に向いているのではないでしょうか。
例えば以下の様なシチュエーションです。

  • サーバが処理できなかったとき（５００エラー）
  • 定期的に動くような処理の実行結果（Heroku Scheduler）
  • herokuにデプロイされたことをメールでお知らせ

【Android】GunosyやSmartNewsからワンタップでPocket登録する

Android 効率化

GunosyやSmartNews、いまや毎日の情報収集には欠かせないアプリとなっている方も多いのではないでしょうか。

どちらも見やすく適度な量の情報が届けられる点が素晴らしいです。
 
しかしこれらのアプリ、僕にとっては重大な欠点があります。
「あとで読む」機能で有名なPocketへの連携がしづらいことです。

f:id:shoma2da:20140221214441p:plain

 
どちらのアプリにも共有メニューはあるもののPocketへの共有はすぐには出てきません。
（Gunosyに至ってはアプリから直接Pocketする方法がない？？）
 
そこでこちらのアプリの登場です。
かなり！！簡単にPocket連携することができます。便利です。
 
f:id:shoma2da:20140211171236p:plain
 

使い方

 

1.画面内に大きく表示されたボタンをタップ

 

f:id:shoma2da:20140221220406p:plain

 
初回であればこの時点でPocketへのログイン画面が出てきますのでログインしておきましょう。
 
ボタンがピンク色になればPocketへの連携が簡単になっています。
また、通知バーに使い方も表示されていることも合わせて確認しておきましょう。
 
準備はこれだけです。
 

2. URLをコピーしてPocket連携

Gunosy
ではまずはGunosyを開いてみましょう。
詳細記事を開いたら共有ボタンをタップします。

f:id:shoma2da:20140221221159p:plain

 

「URLをコピー」をタップします。

f:id:shoma2da:20140221221202p:plain

 

これだけでPocketへ登録できました。

f:id:shoma2da:20140221221204p:plain

 
SmartNews
続いてSmartNewsです。
こちらも同じように記事を開いて「共有ボタン→URLをコピー」です。

f:id:shoma2da:20140221221959p:plain

f:id:shoma2da:20140221222002p:plain

 

仕組みは？

toPocketでは設定がONになっている（通知バーに使い方が出ている）間はユーザがコピーした文字列を監視しています。
 
コピーした文字列がURLだった場合はPocket保存する、といった動作をしています。
 

自動化して楽になろう

いかがでしたでしょうか？
 
ニュースの収集は毎日のように行う人も多いでしょう。
toPocketのように何かしらの作業を自動化できるアプリを使えばより便利に、より楽しくスマホを使いこなせること間違いなしです！
 

toPocketをリリースしました！

Android リリース

どんなアプリ

AndroidユーザでPocket(formerly read it later)を使っているユーザ向けのアプリです。 Pocketへの投稿/登録を即座に行えるようになります。

f:id:shoma2da:20140211171328p:plain

Google Playからダウンロードもしくはtopocketで検索

使い方

アプリを起動しアイコン画像をタップしてONの状態にしておきます。

f:id:shoma2da:20140211170951p:plain

初回のみ認証があり、その後ステータスバーにtoPocketからお知らせが表示されます。

このお知らせが表示されている間にURLをコピーしてください。 自動的にURLの記事や動画などがPocketに投稿/登録されます。

作った理由

ものすごく単純です。 Gunosyを使っているのですがPocketへの連携が難しいな、と思いました。

これを改善しようと思いたち開発を始めました。

開発期間

できるだけスピードを意識したかったので期間的には１週間、実質の開発日数は３日程度（７〜８時間ぐらい？）でした。 エラーハンドリングなどかなりあまい気がしているので今後改善も進めていきます！

是非ともダウンロードをお願いします！

f:id:shoma2da:20140211171328p:plain

Google Playからダウンロードもしくはtopocketで検索

Travis CIならCIの導入コストを限りなく０に近づけられる

Travis CI CI Webサービス 継続的インテグレーション

対象者

  • githubを使っている方
  • CI用のサーバを用意するのが面倒な方
  • Jenkins構築につまづくことが多い方
  • Jenkinsのプラグイン管理などが面倒な方

はじめに

みなさんCIしてますか？

その際の環境はどのようにしているでしょうか？ VPSなどのレンタルサーバでJenkins構築、なんて方が多いのではないでしょうか。

僕もこのように構築していたのですが、サーバ用意が面倒だったりJenkins構築周りでつまづいたりしてとても憂鬱な作業でした。

そんな方向けに、今回はCIプラットフォームであるTravis CIの導入方法を解説していきます。

Travis CIとは

Travis CIとはGithub上のソースを対象にしてCIを実行できるWebサービスです。 Githubのソースコードがpublicであれば利用料は無料です！

非常に簡単な設定で自動ビルドやデプロイなど詳細な設定が可能です。 また、多数のプログラミング言語をサポートしており無料なことも相まって話題となっています。

Travis CI導入手順

はじめはpushする度にecho "hello world"を実行できるようにしていきます。

まずはログイン

https://travis-ci.org/ に行って右上のログインボタンを押し、Githubアカウントでログインします。
[画像]

f:id:shoma2da:20140202192354p:plain

プロジェクトをCIの対象にする

https://travis-ci.org/profile からプロジェクトを有効(ON)にします。

f:id:shoma2da:20140202192434p:plain

プロジェクト内に.travis.ymlを作成する

今回はhello worldと表示できるようにしてみます。 Travis CIはこのymlファイルを見てリポジトリにpushする度に自動でコマンド実行などを行います。

$ cd PROJECT_ROOT

$ vim .travis.yml
#script:
# echo 'hello world!'
#と記述する

$ cat .travis.yml 
script:
  echo 'hello world!'

リポジトリにpushする

あとはpushするだけです。

$ git push YOUR_REMOTE_HOST YOUR_BRANCH

Travis CIの画面を確認してみましょう。 以下のように自動でスクリプトが実行されているはずです。

f:id:shoma2da:20140202192454p:plain

導入については以上で終了です。 たったこれだけでリポジトリにpushする度に簡単に自動ビルドなどを行うことが出来るようになりました。

ここからは公式ドキュメントなどを参照して.travis.ymlの書き方の詳細を把握していくといいと思います。

テストがないコードをどのようにテストしていくか

テスト tips

みなさんテスト書いてますか？
最近のプログラマ界隈ではテストや自動化の話題が非常に多くなっていますよね。
そんなことを言いつつ僕もつい最近テストについて発表しました。

テストが書けるようになってくると実装に自信が持てたり、変更を恐れなくなったりなど良いことが非常に多いです。

基本的には是非書いたほうが良いテストですが、実際の開発現場ではそう簡単にいくものではありません。
これまでに誰か（もちろん自分でも！）が書いたテストのないコードに手を入れていくことが非常に多いのではないでしょうか。

リーン開発の現場にこうしたレガシーコードについての戦略が記載してあったというのもありますが、自分自身もこのような状況に出くわすことが多いので今の思いをまとめておきます。

どうやってテストしていく？

実際にテストのないコードをテストしていこうとする場面を想像してみてください。
僕の知っている中では選択肢として以下の２パターンが挙がることが多いです。

  • チーム全体でテストを書くことを決意して、一気にテスト環境やテストを揃えていく
  • コードの修正や追加をしていく際に必ずテストを付けるようにして少しずつテスト環境やテストを揃えていく

結論を言うとほとんどの場合、後者がベターな選択肢ではないかと考えています。
そのように考えている理由を説明していきます。

この２パターンは「テストをすること」に関してははチーム全体の合意が取れている前提のものです。
名著レガシーコード改善ガイドでは「編集して祈る」か「保護して変更する」かという２パターンの方法ついて述べています。
しかしこれらはあくまで修正の方法論について述べているものですので上記とは意味合いが異なります。

それで、誰がテストに詳しいの？？

仮に先程述べたうちの前者、「チーム全体でテストを書くことを決意して、一気にテスト環境やテストを揃えていく」を選択したとします。

ではテストを書きましょう！となりますが、実際問題としてテストに詳しい開発者はそう多くないはずです。
（一方ではてなやクックパッドはテストに関してかなり先行していそうですね。すごい！！）

そのような状況でテストを初めてしまっても、そもそもテストの粒度や書き方を学ぶのに相当の時間的コストがかかってしまいます。

また、テストするということはプロダクトのコードにもほぼ必ず手を入れることになります。
（テスト不可能だったりそのままのプロダクトコードだと非常に複雑なテストを書かなければならない場合が出てくるため）

テストへの理解があやふやなまま、テストができるようにプロダクトコードを変える。
これは非常に危険なことではないでしょうか？

実装が非常に簡単、といった箇所であれば問題ないかもしれませんが「一気にテスト環境やテストを揃えていく」と決めるということは、そのような箇所だけではなく全ての箇所を見ていくことになります。

長い期間書けてテストを揃えたけど、プロダクトとしての動作を保てなかった...では全く意味がありませんよね。

そこってほんとに手を入れるべき？？

ソースにはどうしても「良く変更する箇所」と「全然変更しない箇所」が出てきます。

このうち「良く変更する箇所」については是非とも早めにテストを用意しておくべきでしょう。
変更ごとにテストを実行することによって安心してプロダクトに組み込んでいくことができます。

一方で「全然変更しない箇所」はどうでしょうか。
もう少し詳しく言うと「全然変更しないけど期待通り動いている箇所」です。
結論から言えばこうした箇所のテストは後回し、更にいえばそのままずっとテストなしでも問題ないのではないかと思っています。
（ここに対する意見は人それぞれ大きく異なりそうな気がしています）

冒頭に述べた後者の選択肢「コードの修正や追加をしていく際に必ずテストを付けるようにして少しずつテスト環境やテストを揃えていく」としていればこうした箇所は触れられることはなく、半自動的にテストされないままになります。

昨今のソフトウェア業界は以前にも増して更に加速度を増しています。
「今は修正の必要がないけどテストコードでより高い安全性を確保する」よりも「新機能の追加や既存の不具合を修正」を素早く行ってユーザに価値を届けていくことの方に基本的には重点を置くべきではないかと思います。
（テストを揃えておくことはもちろん大事ですよ！！念のため。）

YAGNIという言葉もありますし、過度な先読みは最終的には無駄な作業を生む可能性を考えると良いのではないでしょうか。

自動化も一緒にやる？？

テストを書いていくとJenkinsなどを使って自動化(CI)したくなってきます。
確かにコミットしただけでビルドやテスト、デプロイなどを自動で行えることは革命的に素晴らしいものです。

しかし、テストと合わせて自動化ツールもほぼ同時に導入しようとするのには少し考えなおした方が良いかもしれません。

テストを書いていくとテスト用のデプロイ環境やダミーの入力値の準備といった周辺環境の念入りな準備が必要になります。
自動化ツールはあくまで手動で実行できるものをトリガーのタイミングで実行させるだけのものです。

テスト自体の周辺環境があまり固まっていないのに自動化ツールを導入すると、 テストの周辺環境を変える→テストが通ることを確認する→!!自動化の設定を変える!!→!!自動化できているか確認する!! などと自動化に関する工程が増えてしまいます。

テスト自体に慣れてきていれば自動化の設定変更は苦にならないかもしれませんが、テスト自体があやふやなのに自動化についても気にしなければならない！となると精神的負担も非常に大きくなってしまいます。

楽になるための自動化ツールで苦しくなってしまっては元も子もありませんよね。

まとめ

テストのないコードに対するテストをどう行っていくかについて述べました。

一気にテスト環境を整えきろう！と意気込んでしまいがちですが、その方法ではスーパーエンジニアでもない限り失敗してしまうことが多いのではないでしょうか。

個人的には「コードの修正や追加をしていく際に必ずテストを付けるようにして少しずつテストの環境やテストを揃えていく」という選択がベターな気がしています。
テストを少しずつ書いていくことによってテスト自体（あるいはプロダクトの特徴など）に慣れ、それを続けていくことで環境が整い自動化していける、といった少しずつ前に進んでいく手順です。

是非みなさんも考え、実践してみてください。
また、より良い方法などあれば是非教えていただきたいです！

アプリ開発者じゃなくてもわかるクックパッドアプリ勉強会まとめ #potatotips #android #ios

勉強会 Android tips iOS

クックパッドでは月に一度、potatotipsという名で社外の開発者も招いてアプリ勉強会を行っています。 詳細としては発表者だけが参加できる、持ち時間1人5分のtips共有会です。発表内容はiOS/Androidに関するTipsとされています。 これまでに３度開催されました。

まとめ

早速まとめていきます。 発表内容とその簡易的な説明をしていきます。 各タイトルの頭にAndroidならA：、iOSならI：を付けます。

（詳細な資料があるもののみをまとめの対象とさせていただきます。）

第一回

発表内容一覧 です。

  • A：No More 手書きViewHolder
    →Andoridのリスト表示の際にはパフォーマンス向上のための"おなじみの仕組み"を毎回実装することが多いがこれを簡単にする方法について

  • I：No More いろんなサイズの画像(スノーマンから始めよう)
    →ユーザの端末（iPadやiPhoneなど）の画面サイズはそれぞれ違うのでいろいろな大きさの画像が必要になってしまう。この問題に対する文字のパスを取得し、ベクター画像のように扱う方法の提示

  • I：Downloadable Storyboards!
    →iOSアプリの見た目を作成するためのファイル（通常はアプリに含まれます）をアプリの実行時にダウンロードして使う方法

  • I：5分で分かるiBeacon
    →Bluetoothを使った位置や距離感をつかむための最新技術について、その概要や実装について

  • I：UINavigationBarの隅々までタップしたい
    →通常、iPhoneの上部のバーのタップ領域は限られているが、この領域の拡張方法とライブラリ化について説明

  • A：Anroid Design Guide 3つのポイント
    →Androidの画面デザインについて。色、部品の大きさ、文字

  • I：ユーザービリティ向上ネタ
    →アプリを提供する上でのユーザビリティ向上策について１１個。画像取得タイミングやタイトル表示、階層の行き来の仕方など

  • A：Development, Staging, Production...
    →アプリの配布環境ごとのビルドの自動化についてその実例

  • I：Switching Icon.png depending on each enviroment
    →本番用と開発用のアプリのアイコンを変える試みとスクリプトによる自動化

  • I：Debugger の Tips
    →デバッグ時に使用するコンソールを便利に使うための設定

  • I：iOS 7 compatibility issues (UITextView)
    →iOS7のテキスト表示部品に残っているバグに対する対処方法。また、拡張されたテキスト表示部品の実装と公開

  • I：AVSpeechSynthesizerとロケール
    →音声読み上げの際の簡単な言語判定方法

  • A：Android SDK Toolsのおさらい
    →Android開発環境に含まれるコマンド24個について

  • I：５分でわかるiOS7のiAdとTips
    →iOSで使える広告iAdの使い方

  • I：iOSでジオコーディング
    →緯度経度と住所の変換方法。サーバサイドの負荷に注意。

  • A：New Android Bootstrap
    →Webでは有名なBootstrap、そのAndroid版について設定方法や実装方法について

第二回

発表内容一覧です。

  • I：Xcode 5 & iOS 7でカバレッジを取る話
    →最新の開発環境を使ったテストカバレッジの取得

  • A：ActiveAndroidの初期化にかかる時間を4分の1にする
    →DB入出力に係る時間コストを抑える方法

  • I：Objective-CでRAII便利最高 →オブジェクトとリソース管理のパターンについて

  • I：XXXKit ~ それははしかのような物 ~
    →画像をグリッジ（画面のチラツキ）させるライブラリの紹介と、Objective-Cのカテゴリ機構について

  • A：ViewStickerを作りました
    →iOSと同様なリストセクションの表示ができるようになるライブラリの作成

  • I：～時には起こせよエクセプション
    →例外処理をさまざま試すことでクラッシュを防ぐコードを書いていこうという試み

  • A：Custom Lint Check
    →不具合を発見するためのツールにおける設定を自作

第三回

発表内容一覧です。

  • I：下位互換コード隠蔽のストイシズム
    →バージョン対応のコードをいかにして自然に実装するか

  • A：アプリの評価を良くするということについて考える →Android/iOSのストア評価について。ライブラリの紹介など

  • I：便利なSyntax及びUnicodeを使ってアイコンを出す方法
    →便利なブロック文法説明、Unicodeでアイコン表示、三項演算子の使用方法について

  • A：アプリでもオブジェクト指向エクササイズ ★おすすめ！★
    →オブジェクト指向を身につけるための強力なコーディング規約について紹介

  • I：Provisioning Profileファイルを活用してみる！Tips
    →アプリを端末に入れる際に必須である設定ファイルの便利な活用方法について

  • I：iOS 7 なMessage Appの作り方
    →LINEのようなアプリをiOSでどのような実装で作れるかの紹介

  • A：ちょっと優しい入力項目
    →決定ボタンを押した際の挙動など、こまかな入力項目に関する実装方法

  • I：やはりお前らのiOS7対応は間違っている
    →多く語られるiOS7の対応方法についての誤解と好ましい実装方法について

  • I：Secrets of launch arguments
    →実行時の引数を便利に渡す方法の紹介

  • A：TDDでアプリ開発。カバレッジ8%を目指せ（消費税連携！？）
    →全解像度、全OS、全CPUに対応した自動テストについて

  • I：xctestコマンドを知っていますか？
    →最新の開発環境におけるテスト用のコマンドについて紹介

  • A：KotlinでAndroidアプリ開発！(後編)
    →Android開発は通常Javaだが、Kotlinという言語を使った開発の紹介

  • I：死んだオブジェクトの生まれ故郷を探す
    →オブジェクトのメモリ使用についてのログを見ることでオブジェクトの生成から破棄までを追う

  • A：Gradleの共通ルーチンをテストする（後編）
    →Android開発は通常Javaだが、Groovyという言語を使った開発の紹介とビルドシステムを使ったテストについて

  • I：mogeneratorでモデルクラス作成
    →クラスを作成するためのツールの紹介と使い方

  • A：AndroidのHTTPライブラリってどれがいいんでしょうか
    →多数あるHTTPリクエストの実装方法について３つを提示して比較

詳細を知りたい方は

iOS

Android

【SF傑作漫画！】プラネテス一巻のあらすじ

漫画

今年は月に一つは漫画を読むことが目標です。

今月のお題はこちら。

せっかく読むので内容を残しておこうと思います。
（著作権的に問題などありましたら連絡ください。すぐに対応します。）
プラネテス（１） (モーニングKC (735))

プラネテス（１） (モーニングKC (735))

 

 

あらすじ

2070年代の人類を描いた漫画です。

人々は宇宙に飛びとは月面での開発を進め、火星や木星への探索計画も進んでいました。

（ここからは各ストーリーについてあらすじをご紹介していきます。）

星屑の夜 

2068年、とある夫婦が旅行用の宇宙船に乗っていた。
宇宙船が珍しくなくなっているこの時代。
妻はいまだに宇宙に恐怖心を持っており、お守りとしてコンパスを持っていた。
夫が飲み物を取りに席を立ったとき、妻のすぐ横にあったガラスに大きなひびが…
 
それから６年後、デブリ（宇宙空間を漂うゴミ）回収業者としてハチマキとユーリたちは宇宙空間で働いていた。
ユーリはことあるごとに宇宙の暗黒空間を見つめつづけている。
同僚のハチマキはユーリが何者なのかが少し気になっていた。
 

地球外少女 

仕事中のちょっとしたミスで足を骨折してしまったハチマキ。
しばらく月面の病院に入院することになった。
宇宙では地球との様々な環境の違いによって病気になる人々が大勢いる。
 
その中にはキャリア20年以上の航宙士ローランドや、12年もの長い間宇宙で暮らし続けるノノがいた。
彼らの苦悩や人生を目の当たりにしてハチマキは何を思うのか。　
 

ロケットのある風景

久々に地球に戻ったハチマキ、ユーリ、フィーの三人。
ハチマキとユーリはハチマキの実家を訪れた。
そこにいたのはハチマキの弟の九太郎。
 
九太郎は14歳ながら本気で船乗りへの道を目指し、ロケット打ち上げに挑んでいるのだった。
ユーリはロケットのアドバイスをしようと手伝うが、打ち上げに失敗してしまい妻の形見のコンパスを壊してしまう。
後日それがユーリにとってこの上なく大切なものだと知った九太郎。
謝ろうとユーリのもとへ急ぐが、そこには穏やかな表情のユーリが待っていて…
 

点火

デブリ回収中だったハチマキ。
ミスやトラブルが重なり少しの間宇宙空間に取り残されてしまう。
月の影となり放射線の影響を避けられたことから九死に一生を得るも、その心の奥底には深い傷が残っていて…。