« 2015年11月 | メイン | 2016年1月 »

2015年12月

2015年12月28日 (月)

Heroku2015年アップデートふりかえり

こんにちは、浅野です。

2015年もあと僅かということで、今回は2015年のHerokuアップデートで私自身が「これは」と思ったベスト3を紹介します。

第3位 GitHubインテグレーションのサポート

2015年の早い段階でパブリックベータになった機能。

提供する機能は、以下の3つ

  • リポジトリ内の任意のブランチをHerokuへ手動デプロイする
  • 予め指定したブランチに更新があると、自動的にHerokuへデプロイする
  • リポジトリに対するプルリクエストが作られると、そのプルリクエストのコードで新たなHerokuアプリケーションを立ち上げる(Review Apps)

プロジェクト内でデプロイおじさん的なロールをすることが多く、この機能は「あれ、まだパブリックベータだったのか…」と思うくらい重宝しておる機能です。

開発用ブランチにプルリクエストがマージされたらHeroku開発環境へ自動デプロイは、外部CIサービスとの連携で実現していた方が多くいらっしゃると思うのですが、Herokuが標準でサポートしてより楽に仕組みが作れるようになりました。

第2位 新料金プランへの切り替えとそれに伴う無料利用枠の制限変更

どちらかというとネガティブな印象で広まったHerokuの料金プラン変更の話。 元々は1ヶ月で750DynoHourの無料枠が設けられていたものが、2015年6月から無料で利用可能な範囲は1日18時間まで(6時間は必ず停止する)の仕組みに変わりました。

FlectブログでもHerokuの新料金はお得なのかで取り上げたり、日々の開発がどう変わる?を注視しておりました。 フタを開けてみると、開発にはあまり影響がなくFreeDynoの利用枠はよく考えられたものだな、と思いました。 ただ、こんな風に感じるのはエンタープライズ向けにHerokuを使用している(課金して利用している)からで、 個人利用されていた方への影響は結構大きいような気がしており、Herokuがエンタープライズ分野に舵取りを始めたタイミングはここかな、と感じた次第です。

第1位 PrivateSpacesの登場

「ついにTOKYOリージョンにHerokuキター!」とお祭り騒ぎしたアレです。 簡単に説明すると、「DynoとHeroku純正アドオン系のデータ(Postgres/Redis)を、AWSの任意リージョンのVPC内に構築する」という感じです。

TokyoリージョンのVPC上に構築することのメリットは

  • よく言われるレイテンシ問題(太平洋を横断する北米か、ユーラシア大陸を横断するヨーロッパか)が解決する
  • データストアがパブリッククラウドからVPC内にひっこむことによる安全性の向上

あたりでしょうか。特に後者は、お客様にHeroku利用を提案した際に「パブリッククラウドにデータ置くって大丈夫なの?」とよくご質問を受ける点だったりするので、 より安心してHerokuをお使いいただけるようになるのではないかと思っております。

特に2016年のエンタープライズでのHeroku利用シーンを考えると、 Herokuの中の方が

ともおっしゃっておりPrivateSpacesの利用が標準になると思われる、それくらい大きな出来事と理解しています。

まとめ

ということで、トップ3(私見)は以下のとおりでした。

  1. PrivateSpacesの登場
  2. 新料金プランへの切り替えとそれに伴う無料利用枠の制限変更
  3. GitHubインテグレーションのサポート

この他にも、パイプライン・Dockerサポート・Go言語のサポート・Heroku純正アドオンの追加(Redis、HerokuConnectデモ版)など色々な機能が追加されました。

ざっとChangelogを振り返ってみて「これも2015年からの機能か」と思うくらい1年前のHerokuよりも便利に使えるようになっています。 2016年もきっとより便利に使える仕組みが提供されると期待できます。 (個人的にはHerokuRouterの挙動が柔軟に制御できるようになると嬉しい)

それでは、みなさま良いお年を。

2015年12月21日 (月)

HerokuPrivateSpacesの使い方は紹介しないとまずいよね

はい、どうも。 最近、薄めの内容でブログを更新しております、おっぴーです。

カレンダーを見るともう12月なので、わたくしの更新は今年は最後ですね。

ということで、個人的には今年一番おおきなHerokuのアップデートであったとおもわれるPrivateSpacesのご紹介をしたいと思います。

今日は簡単に利用方法についてのご紹介です。 ということで、大事なことは3行で。

  • HerokuSpacesはToolbeltでもDashBoardでも簡単に作成できる
  • もともとSpaceの外側で作成していたアプリはforkを利用してもRegionを移動できない
  • Space内に作成したアプリはforkを利用してもSpaceの外のRegionに移動できない

使い方はのチュートリアルは、このページで紹介されています。

HerokuToolbletでも、HerokuDashBoradでも簡単にPrivate Spacesの機能が利用できることがわかります。 今回はDashBoardからのPrivateSpaceをつくってみましょう。

まずは、画面上部のSpaceを押してSpaceを作成します。

Private_space1

今回は「herok-test-space」という名前で、TokyoRegionのPrivateSpaceを作成します。

Private_space2

作成には7、8分程度かかります。画面に表示されるアドバイスのとおり、コーヒーでも飲みに行きましょう。

Private_space3

作成が完了すると、Spaceの一覧表示に、「herok-test-space」という名前のSpaceが表示されます。

Private_space4

さて、表示されたSpaceを押してみましょう。

Private_space5_2

そうすると、Space内にアプリケーションを作成する画面が表示されます。 アプリケーションを作成するSpaceを選択し、アプリケーションを入力して「Create App」を押下します。

Private_space6

以上で作成した「heroku-test-space」というSpaceの中に、「heroku-blog-test」というアプリケーションを作成できました。

さて、この次は、アプリケーションを作成して、deployをします。

今回、rails4系のアプリをHerokuのdevcenterで紹介されている手順でdeployしようとしたところ、

Push rejected, Region amazon-web-services::ap-northeast-1 is not supported on this plan

というエラーが発生し、デプロイができませんでした。 (原因調査まではしておりません。。。)

ということで、上記でご紹介したチュートリアルのビデオで紹介している、 Node.jsのアプリをデプロイしてみました。


## まずはgit cloneし、アプリケーションのディレクトリへ移動
git clone https://github.com/heroku/quick-fix.git
cd quick-fix
## 上記で作成したアプリのリポジトリをリモート情報に追加
heroku git:remote -a heroku-blog-test
## herokuにdeploy
git push heroku master

以上で、PrivateSpaceに作成したアプリケーションへのデプロイが完了しました。

ちなみに、Space内のアプリケーションは、HerokuToolbeltから作成可能です。


## アプリケーションの作成(--spaceで作成対象のSpaceを指定)
heroku create アプリケーション名 --space スペース名

ただし、チュートリアルのページで紹介されているSpaceの作成コマンドは、現時点(2015/12/20現在)で入力してもエラーになりました。 Heroku Toolbeltのバージョンが3.42.25で、おそらく最新のはずですなのですが、まだ利用できないようです。

また、作成したアプリケーションのRegion移動は簡単ではありません。 Herokuでは、通常、アプリケーションはforkというコマンド実行すると、環境すべてコピーすることできます。

しかしながら、Space外のアプリケーションを新たに作成したSpace内にforkすること、その逆にSpace内に作成したアプリを別のRegionにforkすること、の両方ができませんでした。 たとえば、アプリケーションをSpace外に作成し、regionにtokyoを指定してforkしようとすると


heroku fork --from Space外のアプリケーション --to 移動先でのアプリケーション名  --region tokyo
## 下記のエラーが出力
Apps outside spaces are not supported in this region.

上記のエラーが出力されます。 ようするに、TokyoRegionはSpace外にアプリケーションを作成できませんよ、というエラーになります。 それでは、forkコマンドでspaceを指定できるか、と試してみました。


heroku fork --from Space外のアプリケーション --to 移動先でのアプリケーション名  --space heroku-blog-test
## 下記のエラーが出力
Unexpected flag: --space

ようするに、forkコマンドはspaceなどというオプションには対応していないよ、というエラーになります。

さて、今度はSpace内にあるアプリケーションを元からあるUS Regionに指定してみましょう。


heroku fork --from Space内のアプリケーション --to 移動先でのアプリケーション名  --region us
## 下記のエラーが出力
Slug not compatible with space

ということで、Slugのspace間移動ができないようになっているようです。

以上にように、Space間の移動は単純にできないため、既存のアプリケーションをSpace内に移動する、ということを考えた場合は、forkコマンドが利用できず、アプリケーションを作成してpushするという流れが必要になるようです。

ちなみに、Rails4がdeployできなかった原因調査について、「いやいや、うごいたよ」という方がいらっしゃったら教えて下さい。

ではでは、少々、早いですがみなさま、良いお年を。

続きを読む "HerokuPrivateSpacesの使い方は紹介しないとまずいよね" »

2015年12月10日 (木)

react + redux + react-router のサーバサイドレンダリングを試してみた

こんにちは、ジャバスクリプターの三宅です。
react + redux + react-router を用いたアプリケーションのサーバサイドレンダリングの情報が見当たらなかったので試してみました。

React はご存知の通り、Facebookが開発を行っている、JavaScript フレームワークです。
React は View 部分のみのフレームワークとなり、フロントエンドアプリケーション全体は別途考える必要があります。
Facebook は Flux というアーキテクチャを提唱しており、Redux はその実装となります。
React Router は、React アプリケーションでルーティングを行うためのライブラリでです。
react や redux、react-router の基本的な使い方は、公式ドキュメントや様々なブログで紹介されているので今回は、サーバサイドレンダリングの部分に絞って解説します。

アプリケーション全体のコードは、GitHub にアップロードしています。
動作サンプルのように、簡単なメモアプリケーションで、リクエスト時に初期値を生成して初回ロードに含めるような動作になります。
下の Heroku Button を使って、自身の Heroku アカウントにデプロイして動作を確認することができます。

Deploy

ローカルで動作させる場合は、リポジトリをクローンして、以下のコマンドを実行してください。

cd react-study
npm install
npm run-script build
npm start

環境

以下の環境やバージョンで動作を確認しています。
どのライブラリも開発が活発で、APIの変更を伴うバージョンアップも頻繁に行われています。
そのため、過去のサンプルコードが動かないということがよくあります。。

  • ランタイム
    • Node.js: v5.1.0
    • npm: 3.3.12
  • Babel関連
    • babel-core: 6.2.4
    • babel-polyfill: 6.2.4
    • babel-preset-es2015: 6.2.4
    • babel-preset-react: 6.2.4
    • babel-preset-stage-2: 6.2.4
  • React関連
    • react: 0.14.3
    • react-dom: 0.14.3
    • redux: 3.0.4
    • react-redux: 4.0.0
    • react-router: 1.0.1
    • history: 1.13.1

react-router が依存する history の最新バージョンは 1.15.0 ですが、react-router が deprecated の API を利用しており、Warning が発生するので上記のバージョンを利用しています。
react-router の v1.10 で対応が予定されているようです。
また、redux-router という、redux と react-router を接続するライブラリもあるのですが、まだ β 版である事、複雑な設定が必要である事から、今回は利用していません。

なぜサーバサイドレンダリング??

アプリケーションの説明の前に、なぜサーバサイドレンダリングが話題になっているのかについて少し触れたいと思います。
シングルページアプリケーションでは、サーバサイドでは API サーバとしてブラウザから要求されたデータを返す、クライアントサイドでは JavaScript を用いて DOM を構築する、という構成になりますが、以下の問題があります。

  • 初期ロード時間
    • JavaScript がブラウザにダウンロードされ、評価されてからレンダリングが開始される、また評価後にサーバにデータを取得してレンダリングを行うため、初回ロードがどうしても遅くなります。特に、非力なスマートフォンなどでは顕著になります。
  • SEO
    • Google はクローラが JavaScript を解釈してくれるため問題はありませんが、そうでないクローラに対してはコンテンツのない Web ページとしてインデックスされてしまします。

そのような問題を解決するために、React では URL やデータの状態に基づく HTML をサーバサイドでレンダリングし、ブラウザで動作するクライアントサイドのアプリに、その状態を引き継ぐことができるようになっています。
Ember.js も次のバージョンからサーバサイドレンダリングがサポートされ、Angular 2 にも取り入れようという話が出てきているようです。

サーバサイドで HTML の出力

Express のミドルウェアとして次のように定義しています。

import express from 'express';

import React from 'react';
import { renderToString } from 'react-dom/server';
import { match, RoutingContext } from 'react-router';
import { Provider } from 'react-redux';
import uuid from 'node-uuid';
import moment from 'moment';

import routes from '../../client/routes';
import configureStore from '../../client/store/configure-store';


var router = express.Router();

router.get('/', (req, res, next) => {

  match({
    routes,
    location: req.originalUrl
  }, (err, redirectLocation, renderProps) => {
    if (err) {
      next(err);
    } else if (redirectLocation) {
      res.redirect(302, redirectLocation.pathname + redirectLocation.search);
    } else if (renderProps) {
      const initialState = {
        memos: [{
          id: uuid.v4(),
          text: 'Initial Text',
          date: parseInt(moment().format('X'))
        }]
      };

      const store = configureStore(initialState);

      const markup = renderToString(
        <Provider store={store}>
          <RoutingContext {...renderProps} />
        </Provider>
      );

      res.render('main', {
        title: 'react-study',
        markup: markup,
        initialState: JSON.stringify(initialState)
      });
    } else {
      let err = new Error('Not Found');
      err.status = 404;
      next(err);
    }
  });

});


export default router;

match は react-router が提供するメソッドで、リクエストの URL と ルーティング定義に基づいた renderProps を算出してくれます。
RoutingContext に renderProps を渡すことで、URL の状態に一致したアプリケーションを取得することができます。
Provider は redux が提供するコンポーネントで、initialState が設定された store を与えることで、その store の状態に基づくアプリケーションを所得できます。
renderToString メソッドで HTML を取得し、jade のテンプレートに渡してレンダリングしています。

extends layout

block content
  div#app!= markup
  script.
    window.__INITIAL_STATE__ = !{initialState};
  script(src="/javascripts/bundle.js")

jade のテンプレートは上記のようになっています。
生成した HTML である markup と initialState を渡すようにしています。
通常の変数の渡し方だとエスケープされてしまうので、!= を用いてエスケープされないようにしています。

ブラウザでの初期値の設定

initialState の値をもとに、サーバサイドレンダリングされた HTML と、ブラウザのアプリケーションの状態を一致させます。

import React from 'react';
import { render } from 'react-dom';
import { Router } from 'react-router';
import { createHistory } from 'history';
import { Provider } from 'react-redux';

import routes from '../../client/routes';
import configureStore from '../../client/store/configure-store';


const initialState = window.__INITIAL_STATE__;
const store = configureStore(initialState);

render(
  <Provider store={store}>
    <Router history={createHistory()} routes={routes} />
  </Provider>,
  document.getElementById('app')
);

サーバサイドで生成された HTML には react によってチェックサムが設定されており、ブラウザで render メソッド実行時にアプリケーションの状態、すなわち DOM が一致しているかどうかの確認が行われます。
もし、不一致があれば、ブラウザが保持するアプリケーションの状態に再レンダリングされます。

サーバサイドとクライアントサイドのソースの共通化

今回のサンプルでは、react に関連するアプリケーションは /src/client 以下にまとめています。
react-dom のメソッド - サーバ上では renderToString 、ブラウザ上では render - の実行部分以外では、サーバサイドとクライアントサイドは完全に同じソースコードを利用しています。
今回は記述していませんが、UI コンポーネントのテストも容易に行うことができるようになると思います。

まとめ

非常に簡単なアプリケーションですが、react + redux + react-router を用いたアプリのサーバサイドレンダリングを解説してみました。
今回クライアントサイドのアプリケーションはサーバから初期値を受け取った後は独立して動くようにしていますが、どのタイミングでクライアントサイドとサーバサイドのデータを一致させるかは、React アプリを構築する上で重要な部分になってくると思います。
また、アプリケーションが保持するデータをすべてピュアなオブジェクトとしています。もし、immutable.js を使うのであれば、immutable オブジェクトのシリアライズ、デシリアライズを実装する必要があるでしょう。

実際に React を用いたアプリケーション開発で考えるべきことについては、今後も検証を進めていきたいと思います。

2015年12月 4日 (金)

Javaの勉強会にいってきたよ!

こんにちは、なかやまです。

先月Javaの勉強会に遊びにいってきたので、そのアウトプットです。

1

 

最近はSalesforceと、Playframework(Java)の開発を半分ずつしてます。

2

 

11月にJavaの大きなイベントがあるようなので、行ってみたくなりました!

3

 

去年まではiPadでお絵かきして、ブログにアップしていたのですが、今年はノートスタイルに切り替えました。勉強会で机がある席だとめちゃくちゃ嬉しいです。

4

 

まずは、11/14の JavaOne報告会から!

5

Javaone_1

ダークカナリアリリース、こんな仕組みがあるんですね。本番に影響でないテスト環境。すばらしい。

 

Javaone_2

 最近はSalesforceばっかりやってたので、コンパイルとか懐かしい。

Javaone_3

JavaOneの写真をちら見しましたが、楽しそうでした!

 

次に11/28のJJUG!

6

 

イベントは午後からだと思っていたので、基調講演を聴き逃しました。。

Jjug_1

jstackつかってみます! 

Jjug_2

Jjug_3

 

Jjug_4

Java歴浅くても聴きやすいセッションが多かったので、来年はがっつり参加したい。

 

 

 

最後にお知らせ。

会社の勉強会を12/22に企画してます!

7

1回目はハンズオンでモクモクしましたが、今回はHeroku・IoT周りのお話になりそうです。興味がある方は遊びにきませんか!

8

・flectのDoorkeeper

https://flect.doorkeeper.jp/

イベントページは鋭意作成中です、来週には出来上がるはず。

もう少しお待ちください!

採用情報

株式会社フレクトでは、事業拡大のため、
Salesforce/Force.comのアプリケーション
開発
HerokuやAWSなどのクラウドプラッ
トフォーム上でのWebアプリケーション開発

エンジニア、マネージャーを募集中です。

未経験でも、これからクラウドをやってみた
い方、是非ご応募下さい。

フレクト採用ページへ

会社紹介

株式会社フレクトは、
認定コンサルタント
認定上級デベロッパー
認定デベロッパー
が在籍している、
セールスフォースパートナーです。
heroku partnersにも登録されています。
herokuパートナー
株式会社フレクトのSalesforce/Force.com
導入支援サービス
弊社の認定プロフェッショナルが支援致します。
・Visualforce/Apexによるアプリ開発
・Salesforceと連携するWebアプリ開発
も承っております。
セールスフォースご検討の際は、
お気軽にお問合せください。
Powered by Six Apart