2016年4月15日 (金)

永和システムマネジメント様と合同勉強会を開催しました

@ucsmkyです。

突然ですが、先日永和システムマネジメント(以下ESM)様と合同勉強会を開催しました。

事のきっかけ

突然なんだという話ですが、事のきっかけは昨年12月のRubyKaigiのDrinkupでのことです。
ESMの伊藤さん(@koic)と話してた時、「最近永和さんいろんな会社さんと合同勉強会を開催されてますよねー」という話になってから、勢い余って私が「じゃあ今度一緒にやりましょうよ」と言った所伊藤さんも「よしやりましょう」、と。

因みに1月はDRECOM様との予定があるので、その次に、ということで取り敢えず予定だけ頂きました。
(因みにDRECOM様との開催はこちら

で、テーマについてですが、打ち合わせた結果、以下の内容で決まりました。

ワールドパブ「クラウド×Agile」

ワールドパブとは

ワールドパブというのはワールドカフェのアルコールあり形式のスタイルでファシリテーション手法の一種です。
ワールドパブとは

過去事例で言いますとクラスメソッド様とESM様の合同勉強会がその形式でした。
クラスメソッド様とESM様の合同勉強会

各々のテーブルごとにテーマを決めて意見交換を行うというスタイルです。
各テーブルごとにテーブルオーナーを決めておく必要があります。

テーマは最終的に以下の内容で決まりました。

テーマ

FLECT側

  • クラウド(AWS、Heroku)
  • フロントエンド

ESM様

  • 強いチーム
  • リモートワーク

各テーブルごとのディスカッション内容とまとめはESM様のサイトを参照していただければと思います

http://agile.esm.co.jp/news/2016-03-30-flect-esm-world-pub.html

参加してからの気付き

私はテーブルオーナーとして参加したので、他のテールブルの話題については実際に参加された方の意見を以下に抜粋します。

参加された方の意見

お酒と食べ物でリラックスしながらお話するのは、たのしいですね。 初対面の方とも和やか雰囲気でお話できて、大変、楽しかったです。

一方で、ほんとうの課題についてなかなか深掘りできない、という面もあったかもしれません。 ですが、ひとりで悩んだり、考えこんだりしているよりは、みんなに話して意見をもらう、というのは改めて課題の整理ができて、非常に良い経験でした。

たとえば、

  • リモートワークは今後より広がってゆくことが望ましいけど、業務量の制限やミーティングの調整などチームメンバーの文化が整えてゆくことが重要だなぁ
  • 強いチームになるには、メンバーがお互いに変な恐怖を抱かず意見がいえる環境が必要だなぁ
  • チームの状況と目的がまずはじめにあってそれからAWSやHerokuなどツールを選択することが重要だなぁ

など、当たり前のことながら、課題をクリアするための本質的な点を再確認できたことが良かったです。

これらの共通の課題は、「ロールにかかわらずメンバー同士が、互いをよく知っているか」という当たり前のことをチームがどれだけできているか、時間を割けているか、ということかなと思います。

メンバーのスキルセットをはじめとして、ときには「お子さんがまだ小さいくて送り迎えが必要」とか「今日は花粉症がひどくてだるい」など、スキルセット以外にも、仕事をするにあたり影響を及ぼす要素はたくさんあります。 また、こうした個人的な事情、というのはお互いに開示するまでそれなりに時間と信頼関係が必要なものなので、明示的な場や時間を取ることが必要だろうな、と感じました。

この方法の1つとして、アンゲームというのを最近、メンバーから教えてもらい、利用したのでご紹介します。 非常に簡単なルールと準備で、お互いの胸の内を話してゆく仕組みになっているゲームです。 プロジェクトの開始時や定期的なふりかえりで活用なさってはいかがでしょうか。

(by おっぴー、男:30代)

まとめ

私のテーブルのまとめをざっくりと上げますと以下の内容です。

Keep

クラウドを利用するにあたって、AWSとHerokuを活用するパターンをある程度提示できたかと思います。

  • エンジニア主体で進む(Heroku)か、DevOpsで進む(AWS)か
  • インフラエンジニア(サーバ側の事情に詳しいという大前提)の枠をチームに設ける(AWS)か、チームは全員開発に専念し、アドオンで解決する(Heroku)か

また、ESM様とFLECTの開発事例がどうなっているのかも情報交換が出来たかと思います。

  • 開発の基盤は、案件の引き合いの違いによるところが大きいという点
  • FLECT側はForce.comとのインテグレーションが多いのでHerokuを利用する事が多い
    • その代わりFLECTの開発は割りとバリエーションがある(開発言語は雑多)
    • ESM様はほぼRuby(0.5%ほどNode.js)

Problem

課題点として以下の点が挙げられました。

  • 議論の中心が定められなかった。(テーブルオーナーである@ucmskyの力不足です。。)
  • IaasとPaasの使い分けに関してコストの観点での境界がどのあたりになるのかの掘り下げが足りなかった。(@ucmskyの個人的な見解)
  • @koic様の「SIとインフラがどう絡むか?」の質問には上手く掘り下げることが出来なかったこと。

Try

個人的にやってみたかったこととして、オンプレのトラブル事例に対して、クラウドでどのような解決が可能かというディスカッションをやってみたかったです。 (某ショッピングサイトのトラブルの事例を後になって思い出したので時既に遅しでしたが。。) 逆にもしオンプレでなければならない事例があればその掘り下げも。

最後に

永和システムマネジメントの方々、ありがとうございました。是非また一緒に勉強会を開催させていただきたく思います。

続きを読む "永和システムマネジメント様と合同勉強会を開催しました" »

2016年3月11日 (金)

Mac on Macの環境構築をしてみました。

ご無沙汰しております、おっぴーです。

本日は、VirturalBoxを利用したMac On Macの環境作成方法について書いてみたいと思います。 弊社では大半の開発者はMacBook Proを利用していますので、OS Xの環境がほしい!ということはほとんどありません。

が、ハンズオンの資料を準備するために、「綺麗な状態のOS XにNode.jsの開発環境を作りたい」という要望がでてきたためVirtrualBoxを利用した環境構築をしてみました。 構築に利用した環境は、

  • Virtual Box 5.0.16 r105871
  • OS X El Capitan 10.11.3

です。

ということで、下記では

  • そもそもVitrualBoxでOS Xを起動してライセンス的に問題ないのか
  • VirtualBoxを動かすためのisoファイルの作り方
  • VirtualBoxの設定と起動方法

についてご紹介します。

そもそもVitrualBoxでOS Xを起動してライセンス的に問題ないのか

ソフトウェア開発においては、App Storeからダウンロードしたインストーラーを利用して、Mac上で2つまで環境構築をして良い、となっています。 下記が日本語の引用文です。よかった、よかった。

お客様が所有または管理する各Macコンピュータの仮想オペレーティングシステム環境内で、Appleソフトウェアの最大2つの追加コピーまたはインスタンスをインストールし、使用し、稼働させることができます。 これらは、(a)ソフトウェア開発、(b)ソフトウェア開発中の試験、(c)OS X Serverの使用、または(d)個人的、非営利的使用を目的として行うことができます。

Apple_regal


VirtualBoxを動かすためのisoファイルの作り方

これらの情報はいろいろあるのですが、下記が一番詳しい手順でした。

http://anadoxin.org/blog/creating-a-bootable-el-capitan-iso-image.html

まずは、AppStoreからEl Capitanのインストーラーをダウンロードします。 ダウンロードされたファイルは、/Application の配下に「Install OS X El Capitan.app」という名前で作成されます。 ちなみにファイルの大きさが6Gもあるので、ダウンロードが終わるまで気長に待ちましょう。

Create_iso1


つぎに、isoファイルを作成する作業に入ります。 各コマンドの詳しい内容は上記のURLを見て下さい。ここではざっとコマンドをご紹介します。

## App Storeからダウンロードしたインストーラーをマウント(/Volumes/esdが作成される)
hdiutil attach "/Applications/Install OS X El Capitan.app/Contents/SharedSupport/InstallESD.dmg" -noverify -nobrowse -mountpoint 

## isoファイルにするための仮ファイルを作成してマウント(ElCapitan3.cdr.dmgが作成される)
hdiutil create -o ElCapitan3.cdr -size 7316m -layout SPUD -fs HFS+J
hdiutil attach ElCapitan3.cdr.dmg -noverify -nobrowse -mountpoint /Volumes/iso

## インストーラーの情報をiso用の仮ファイルにリストア
asr restore -source /Volumes/esd/BaseSystem.dmg -target /Volumes/iso -noprompt -noverify -erase

## asrを実行して作成された/Volumes/OS X Base Systemの既存の内容を削除
rm /Volumes/OS\ X\ Base\ System/System/Installation/Packages

## マウントしたインストーラーの内容をasrコマンドで作成したディレクトリにコピー(すると、ElCapitan3.cdr.dmg にコピーされる)
cp -rp /Volumes/esd/Packages /Volumes/OS\ X\ Base\ System/System/Installation
cp -rp /Volumes/esd/BaseSystem.chunklist /Volumes/OS\ X\ Base\ System/
cp -rp /Volumes/esd/BaseSystem.dmg /Volumes/OS\ X\ Base\ System/

## マウントを解除
hdiutil detach /Volumes/esd
hdiutil detach /Volumes/OS\ X\ Base\ System

## 作成したファイルをiso用にUDTOフォーマットに変更(ElCapitan3.iso.cdrが作成される)
hdiutil convert ElCapitan3.cdr.dmg -format UDTO -o ElCapitan3.iso

##  作成したファイルをisoファイルにリネーム
mv ElCapitan3.iso.cdr ElCapitan.iso

以上で、VirtualBoxでインストールに利用するisoファイルの作成は完了です。

VirtualBoxの設定と起動方法

個人的なハマりどころは、VirtualBoxの設定です。

まずは、チップセットの設定を、PIIX3に変更することです。

http://apple.stackexchange.com/questions/198737/install-el-capitan-in-virtual-box-for-testing-purposes

設定を変えておかないと、VirtualBoxを起動しても、インストールが始まりませんでした。 設定方法は、画像を参考にしてください。

Setvb1


作成したisoファイルを設定した後、起動したらあとは通常のインストール方法と同様です。

Setvb2


ただし、AppleIDの認証がとおることは確認していません。 AppleIDが連携できるかは、適宜、確認してみてください。

また、VirtualBox上のOS Xからインターネットの接続ができない、という事象にも遭遇しました。 原因はしらべていませんが、その際は、システム環境設定→ネットワーク→アシスタント→診断を選択し、ネットワーク診断をすると正常にインターネットに接続できるようになりました。

以上で、VirtualBox上でOS X El Capitanを動作させられます。 需要があるのか謎ですね。

続きを読む "Mac on Macの環境構築をしてみました。" »

2016年3月 4日 (金)

JavaScriptの書き方をいろいろと試してみた

こんにちは、三宅です。
1月からのプロジェクトで開発しているアプリケーションでは、サーバサイドもクライアントサイドもJavaScriptを採用。
その中でソフトウェアアーキテクチャやコーディングスタイルなど、いろいろなことを試してみました。

アプリケーションの特徴

コンテンツ管理がメインユースケースのアプリケーションです。
現時点ではそれほど複雑な構造にはなっていませんが、タグ付けやユーザやロールに応じたアクセス権限を実装することが将来的にあるかもしれない、というようなものです。

開発の方針

開発に際して、以下の方針を立てました。

  • ドメイン層を明確に分離する
    • アプリケーションで扱う概念をモデルとして表現する
    • ドメイン層は特定のフレームワークやインフラに依存しない
  • クラスベースで記述する
    • ドメインモデルをクラスとして宣言的に定義したい
    • ECMAScript2015(ES6)でクラス定義や継承などが直感的に記述できるようになったため
  • サーバサイドとクラインとサイドは同じモデルを利用する
    • バリデーションなどはモデルに持たせ、それらのコードが分散することを防ぐ

また、一般的なことではありますが、できるだけコードの重複を防ぐ、外部の状態に依存するコードを書かない、ということを意識しました。

フレームワークやミドルウェア

MongoDB、Express、AngularJS、Node.jsといういわゆるMEANスタックを採用しました。

ORMとしてMongoose、テンプレートエンジンにはjadeを利用しています。
コードは基本的にES6で記述し、サーバサイドはBabelを用いてファイルごとにES5に変換、クライアントサイドはBrowserifyを利用し、画面ごとにファイルを生成するようにしました。

ビルドタスクやディレクトリ構成などは、Nodeyardをほぼそのまま利用しています。

試したこといろいろ

少しいろいろなレベル感の話が出てきてしまうかもしれませんが、開発の上で試してみて良さそうだったことを書いていきます。

constでの変数宣言

ES6では「let」と「const」という新しい変数宣言の方法が追加されました。参考

letとconstはブロックスコープです。そしてletは再代入が可能、constは再代入が不可能な変数となります。
可能な限りconstを用いることで、意図しない値の再代入を防ぐことができます。
また、varではなくletを用いることで、JavaScript特有のfor文の中などで宣言した変数の意図しない挙動を防ぐことができます。ただ、繰り返し処理は基本的にイテレータを使っているので、そこまでスコープを意識する機会はありませんが。

アローファンクションの利用

アローファンクションという記述で関数を宣言できるようになりました。

const sample = (a) => {
  return a + 1;
};

この記述は単なる「function」のショートハンドではなく、「this」のスコープがレキシカルスコープになるという大きな違いがあります。
JavaScriptのfunction内のthisはダイナミックスコープで、呼び出し元によって参照先が変わるという大きな特徴がありました。
アローファンクションを用いることで、例えばクラス内で定義した関数内のthisは常にクラスインスタンスになるため、挙動を予測しやすいコードになります。

オブジェクトリテラルの拡張

オブジェクトをリテラルで作成する際の構文が拡張されました。参考
その中でも、変数を設定する際のショートハンドを多用しました。

const name = req.body.name;
const password = req.body.password;

const params = { name, password };

上記のparamsは、以下のオブジェクトの宣言と同じです。

const params = {
  name: name, password: password
};

変数名を何回も書く必要がなく、タイポの可能性を低減することができます。

定義したモデルの拡張

モデルをクラスとして定義するのですが、画面表示名の取得メソッドなど、ビジネスロジック以外のメソッドが欲しくなることがあります。

そのようなメソッドはコアとなるクラス定義とは別に行うようにしました。
SwiftのExtensionsのようなイメージです。

/core/entities/a.js

class A {}

/extensions/entities/a.js

import A from '../core/entities/a.js';

A.prototype.getDisplayName = () => {
  return `A: ${this.name}`;
};

やっていることは、従来のJavaScriptでもあったプロトタイプ拡張です。
上記のように整理することで、コアのコードに特定の環境のみでしか利用しないメソッドを含めないようにすることができると考えています。

サーバサイドとクライアントサイドでのオブジェクトの共有

共有するモデルに対してシリアライザとデシリアライザを追加し、サーバでのレンダリング時に設定した初期値をブラウザの上で復元できるようにしました。

テンプレートをレンダリングする際に、以下のように初期値を渡すようにしました。

const initial = { user: user.seriallize() };
res.render('template', { initial });

script.
  window.__INITIAL__ = JSON.parse(unescape("!{escape(JSON.stringify(initial))}"));

window.INITIAL に初期値を代入する際に、XSSを防ぐためにエスケープしてレンダリングするようにしています。
今回はAngularJSを利用しましたが、Reactのサーバサイドレンダリングでも同様に初期値を渡すことができると思います。
渡された初期値をでシリアライズして利用します。

const user = User.deserialize(window.__INITIAL__.user);

今回はモデルごとに定義しましたが、シリアライザは少し工夫すれば汎用的な関数を作れそうな気がします。

MongooseのModelの継承

Mongooseには、discriminatorというModelの継承を行うための機能があります。
The model.discriminator() function
この機能を用いて、Userというモデルに対してManagementUser、SubscriptionUserのようなユーザの種類に応じたサブタイプを定義しました。
実際に保存されるデータにはサブタイプを識別するための項目が追加されるだけなのですが、サブタイプを宣言的に定義することができること、サブタイプを指定したクエリを実行できる点で採用しました。

インスタンスが特定のクラスのオブジェクトであるかの判定

あるクラスのオブジェクトをインスタンスを返却するメソッドがあり、そのインスタンスがどのサブクラスのオブジェクトであるかによって、処理を分けたいというような場面。
ES6のクラス定義は実際には継承とプロトタイプチェーンのシンタックスシュガーであるため、instanceofが使えます。
プロジェクトでは、インスタンスを判定するための関数を定義して利用しました。

const instanceOf = function(instance, ComparisonClass) {
  if (!(instance instanceof ComparisonClass)) {
    return false;
  } else {
    return true;
}

}

Errorクラスの継承

例えばApplicationErrorのような独自のエラーを定義して、そのエラーの時だけ処理を変えたい、というような場面。
クラス継承ができるのなら…と以下のように書いていたのですが、instanceofでErrorのインスタンスとしか判断することができませんでした。

class ApplicationError extends Error {
  constructor(message = 'ApplicationError', params = {}) {
    super(message);

    Object.keys(params).forEach((key) => {
      this[key] = params[key];
    });
  }
}

正確には、nodeコマンドで直接実行した場合はinstanceofでApplicationErrorと判定できるのですが、Babelで変換されたコードでは「error instanceof ApplicationError」でfalseが返されました。
暫定処理として、typeプロパティを生やしてそれで判断するようにしましたが、この部分は少し調べて見る予定です。


ざっと試してみたことを書きましたが、やはりJavaScriptではイミュータブルで型に基づくプログラミングには限界がある…という印象です。
継承によるサブクラスの利用はある程度使えるのですが、多重継承ができないこと、インタフェースの定義ができないことが、大きな足かせになります。
そのようなプログラミングスタイルを取るのであれば、TypeScriptを採用した方がいいということを実感しました。

また、クライアントサイドとサーバサイドでのオブジェクトの共有で、シリアライズする際にコンストラクタなどの情報を持っていないと、デシリアライズする際にサブクラスまで復元できないという問題もありました。今回はその部分は妥協して、基底クラスのオブジェクトとして復元して利用するような形をとりました。

サーバサイドだけであれば、TypeScriptで型に基づくたプログラミングができるのですが、クライアントサイドでもコードを共有するようなパターンだと、パラメータのみのインタフェースを定義し、それに準拠したオブジェクトを処理する関数を用意する、という方式の方が楽かもしれません。今後もそのあたりはいろいろと試してみたいと考えています。

2016年2月26日 (金)

CloudSearch使った時につまづいたところ パート2

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

最近お仕事でCloudSearchを利用する機会がありました。

CloudSearchはAWSが提供する検索サービスになります。

前回もご紹介したのですが、もう少し躓いたところがあるのでお話させてください。
では、色々つまづいた・誤解していた事です↓

 

複雑な検索もできるよ

Cloudsearch_01

クエリパーサーは4つ。
・simple・・・簡易テキスト検索
・structured・・・高度な検索(今回はこちらを利用)
・lucene(るしーん)・・・Apache Lucene クエリパーサーの構文を使用
・dismax・・・DisMax のクエリパーサーで定義された Apache Lucene のクエリパーサー構文の簡略化されたサブセットを使用

Apache Solrを知らなかったのですが、Solrを使っているシステムは移行が簡単そうにみえますね。

https://docs.aws.amazon.com/ja_jp/cloudsearch/latest/developerguide/searching.html


Boolean型ってないんだ・・

Cloudsearch_02

登録できるデータ型はテキスト、リテラル、数値、小数、日付、地理、配列です。
Booleanとして使いたかったものは、リテラル型にtrue,falseとか0,1を入れて対応しました。
テキスト型にはそれぞれ言語設定ができるよ。

 

 

ドキュメント消したいときはどうするの?

Cloudsearch_03

バッチでdeleteのJSON投げればOK
CloudSearch上はドキュメントIDで一意になるように指定します。

 

 

アップロードはcsvでできるの?できないの?

Cloudsearch_04

コンソール&コマンドラインツールからはcsvOK。ドキュメントバッチはJsonかXML形式だけです。1回の送信サイズ最大5Mになるように調整しよう。

https://docs.aws.amazon.com/ja_jp/cloudsearch/latest/developerguide/preparing-data.html#creating-document-batches

 

 

項目の設定でreturnにチェックをはずすと、コンソール画面から叩いても、結果がわからなくなったよ。

Cloudsearch_05

表示項目として利用しないものだったので、returnのチェックを外した所コンソール画面から検索したときに値の確認ができなくなりました。検索結果のjsonには、returnにチェックの入った項目しか返却されません。

コンソール画面からは確認できるのではないかと、思い込んでマシタ。

検索条件に指定することで値が設定されていることは確認できましたが、まずは全部returnチェックをして正しく登録されていることを確認してから、returnチェックを省いたほうがよかったかな。

 

項目にnullって登録できないの?

Cloudsearch_06

登録するjsonにて項目をブランクで登録した所、検索結果からは項目自体が抹消されてまいした。呼び出し側では項目がない場合の制御が必要ですね。

 

 

特定の項目だけ更新したかったのに

Cloudsearch_07

毎日特定の列だけ更新したいことがありました。よし、特定の項目だけ更新すればバッチの時間短縮だよね!と思っていたのですが、どうやら特定の項目だけ更新はできないようです。残念。

選択したフィールドだけを更新することはできません。ドキュメントは新しいバージョンで上書きされます

https://docs.aws.amazon.com/ja_jp/cloudsearch/latest/developerguide/preparing-data.html#adding-documents

 

 

日本語検索の仕様がわかりにくい

Cloudsearch_08

今までテキスト検索といったら、SQLのLIKE条件を使う程度でした。CloudSearchでは項目ごとに言語設定ができるんです。その設定によって、検索結果が変わってきます。

・Multiple Language ・・・ N-Gram検索(2文字ずつ区切る) 京都で検索すると、東京と京都がhitするもの

・Japanease ・・・ 日本語形態素解析 京都で検索すると京都しかhitしないもの 

 

どうやってインデックス作ってるの?

Cloudsearch_09

1.トークン分割・・・スペース・タブ・空白文字・ハイフン・記号(@)でも分割。下線、コロン、カンマは分割されない。キャメルケースも分割されず。
2.標準化・・・大文字→小文字

3.ステミング・・・インデックスに含まれる用語の数を減らす
4.ストップワード・・・インデックス作成時にも検索時にも無視される単語
5.シノニム・・・検索しているデータ内に存在する用語に対してシノニムを設定できます
※辞書の設定はコマンドから
http://docs.aws.amazon.com/ja_jp/cloudsearch/latest/developerguide/text-processing.html

検索するときにも同じテキスト処理をかけて検索するそうです。
プレフィックス検索だと検索用語でテキスト処理をしないそうです。
完全一致のみ利用するのであれば、リテラル型で定義すればよいそう。なるほど。

 

 

で、ドキュメント登録にどのぐらい時間がかかるの?

Cloudsearch_10

アップロードするドキュメントのサイズとインデックス作成する項目数によります。
今回ネックになったのは送信元となるjsonファイルの作成にかかった時間でした。cloudsearchに投げる前ですね。
jsonファイルができたら、並列投入することでオートスケールしてくれます。

公式ドキュメントには数十秒〜数分とかいてますが、そのとおりだと思います。

今回はここまで。

2016年2月12日 (金)

Crystal勉強会でFrostネタで登壇し、Herokuにデプロイするまでを纏める

ドーモ、読者=サン、ペンギン@ucmskyです。

結構ご無沙汰してますが、先日1月22日にクックパッドさんで、第3回Crystal勉強会が開催され、ありがたいことに15分のセッションの枠をいただくことになりました。

実際は20分以上喋り尽くしました。

そして先日、codeiq magazineさんに記事にしていただきました!
いえーい。ピースピース。
実践的なテーマの発表も増えた「東京Crystal勉強会」第3回の様子をレポート!

私のセッション資料は、こちらです。
CrystalでもRailsを使いたいですか?

「バグを見つけたら、”俺が直す”くらいのつもりで触れ」と僕はキメ顔でそう言った。

後、「Kemalはいいぞ」

Crystalの簡単な紹介

ここでざっとCrystalについて完結に説明させていただきます。
平たく言うと、Rubyライクな言語なのですが、以下の特徴を持っています。

  • ビルドしてLLVMバイナリを出力する
  • 静的型付け
  • マクロによるコードジェネレート

文法に関してはとりあえず以下の解説に目を通していただけると感覚は掴めると思います。

Crystal 入門

ご覧のとおりのRubyライクです。
ただしRubyとの大きい相違点として、メタプログラミングで使用するeval系のメソッドなどが使えなくなっています。(ですのでメタプログラミングRubyで記載されている内容になるともう全く、RubyとCrystalは別物と言って過言ではないです)
ただ、とりあえず動かしてみるような場合に関しては、Rubyの知識でも概ね問題はないと思います。(実際に僅かな読み替えで対応可能でした)

尚、去年のRubyKaigi2015でもCrystalを扱ったセッションもありました。

Introducing the Crystal Programming Language

Heroku社の中の人の@leinweberさんによるCrystal概論の発表です。

ぶっちゃけ私がRubyKaigi2015のLTのCFPに送った内容とほぼ全部被りました。

その他細かい点の解説、対応しているプラットフォームの情報、更新履歴などは公式サイトや、日本コミュニティのサイト(ドキュメントなどは日本語に翻訳しています)に記載されています。
URLはこちら。

なお、Latestバージョンは2016年2月4日時点で0.11.1となっています。

Crystalを取り巻くツール

ツールの開発も活発に行われています。Webで公開されているもので有志の人が纏めた一覧がこちらです。

awesome-crystal

DBアクセス用のツール、特にpostgresqlへのアクセスツールは前述のRubyKaigiで登壇された、@leinweberさんが作られました。

Web系のツールの開発も活発に行われていて、Rubyでよく使われるSinatra系のツールや、WebではおなじみのRuby on Railsライクなツールも出始めています。

Sinatraライクなツール Kemal

シンプルな構成になっているフレームワークですが、現時点でも高い品質となっています。 実際に公開されているアプリ開発にも使用されており、第3回Crystal勉強会でもWebアプリ開発事例としてKemalを使用したアプリが紹介されていました。

Crystal で実際のウェブサービスは作れるのか?

Frost as Crystal on Rails

そしてもう一つ関心を抱かれるのが、CrystalがRubyライクというなら、Railsのようなツールは無いのか? だと思うのですが、幾つか候補はあります。

一つがAmethyst、もう一つが今回取り上げるFrostです。
どちらもまだバージョンは0.2を超えるかどうかという始まったばかりのプロジェクトです。
Frostを取り上げた理由については

  • 全体的な枠組みが出来つつある
  • ActiveRecordライクなツールがある程度使える

という感じです。

サイトはこちら Frost

チュートリアルは同じリポジトリの
guides
に同梱されています。

Latestバージョンは2016年2月4日時点で0.2.1となっていますが、Crystal本体の破壊的変更(コアライブラリのファイル名やファイルパスがよく変わるので)の影響で動作しなくなっています。
(時間を見つけて私も調査してみます)

動作確認については、Crystal 0.10.2で確認している以下のリポジトリをcloneすると取り敢えず動きます。

frost_sample

チュートリアルでまだ書かれていない部分で、私が確認した点は以下のとおりです。

どんな感じのツールか

取り合えずRailsでいうところのrails new では以下のディレクトリなどが生成されます。

パッと見た感覚では、大枠の構想は固まっているように見えます。どこに何を配置するかは、そのままRailsの仕様に沿うようです。

Routing

公式サンプルでは以下のRoutingの設定が記載されています。


# config/routes.cr
Frost::Routing.draw do
  resources :posts, only: %i(show index) 
  (中略)
end

showとindexを使用していますが、onlyの設定を外すとエラーになります。(まだ幾つかのメソッドが実装されていないのが原因)
幾つか試した結果、newとcreateを追加することは出来ました。
(editとdeleteメソッドは無理の様子)


# config/routes.cr
Frost::Routing.draw do
  resources :posts, only: %i(show index new create)
  (中略)
end

ActiveRecord

ある意味一番気になる箇所となる、ActiveRecord的なO/Rマッパーの実装ですが、試した結果、検索系の幾つかと作成処理は使用可能でした。
FrostのDB処理を行っているコードを見る限りでは、削除系も定義はされていました。
(編集処理も同Frostのコードを見る限りでは普通にオブジェクトを扱うように行えるように見えました)

検索系

  • #{ModelName}.find(id)
  • #{ModelName}.find_by({column1: hoge , culumn2: huga })
  • #{ModelName}.all.pluck( column1 ) #未確認

レコード追加処理

  • hoge = Hoge.new
  • hoge.column1 = aa
  • hoge.column2 = bb
  • hoge.save

削除処理

全体的に未確認です。コードを見る感じでは以下の使い方は出来そうですが。。

  • #{ModelName}.delete_all
  • hoge = Hoge.find(id)
  • hoge.delete

Herokuで動かしてみる

勉強会までに間に合わなかったのですが、Herokuで動かすことも出来ます。というかFrostやKemalでも使えるように拡張build-packを作りました。(まだまだ動作が不安定ですが)

heroku-buildpack-crystal

作成にあたり、Elixirのビルドパックを多大に参考にさせていただきました。

ぶっちゃけElixirのbuildpackの8割コピペですが

heroku-buildpack-elixir

作り始める時点では実はビルドパックの構造を殆ど知らなくて、公式のビルドパックに少しずつ設定を足しながらの作業でした。 (compileファイル起動時に渡されるパラメータも知らなかったし、DATABASE_URLなどDBアクセスに必要な設定の渡し方も知らなかったほど)

Heroku Buildpackの作り方

使い方等は上記リポジトリのREADMEに記載していますが、ここでビルドパックにはどういう設定を記載すればいいのか簡単に説明します。

作り方の記載の全てはHeroku公式ドキュメントに記載されています。

Buildpack API

本ブログでも過去にビルドパックの作り方について解説している記事があります。(かれこれ2年以上前の記事ですが)

Herokuにバイナリを組み込むbuildpackを作成する

使用言語はbashであれば問題無いです。別にbashでなくてもよく、極端な話、herokuのDyno上で実行可能な言語であれば何でも構いません。実際に公式のRubyのビルドパックではRubyが使用されていたり、Groongaのビルドパックも同様にRubyで記載されています。

ビルドパックに必須となるファイルは以下の3つです。

  • detect
  • compile
  • release

上記3つのファイルをのカレントのbinディレクトリ以下に設置します。

detect

このビルドパックを適用する対象のプロジェクトかどうかを判断します。
Rubyの公式ビルドパックを参考にしますと、こんな感じになっています。


#!/bin/sh

if [ -f "$1/Gemfile" ]; then
  echo "Ruby"
  exit 0
else
  echo "no"
  exit 1
fi

Rubyのプロジェクトであるなら、ビルドパスのカレントにGemfileがあるはず、という判定をしています。
(ここでGemfileのパスに指定している$1がビルドパスを表しています(後述))
Crystalだとこれをshard.yml(ライブラリ管理ツールshardsが読み取る設定ファイル)に置き換えます。(v0.8以降のデファクト)

compile

多分一番処理が多くなる箇所であり、ビルドパックの中心となるファイルです。
ファイル名の通りプロジェクトのビルドを行うファイルですが、ビルドに必要となるコンパイラ、インタプリタ本体のダウンロード、ビルド、ビルド後の処理などは全てこのファイルで設定します。
実行時に3つの引数が渡されます。

  • 第1引数 ビルドパス
  • 第2引数 キャッシュディレクトリパス
  • 第3引数 環境変数の情報一覧を格納したディレクトリのパス

ビルドパスとはまさにアップロードするアプリが格納されるパスです。つまりビルド対象となるパスとなります。
キャッシュパスはビルドするツールを格納するパスです。CrystalならCrystal本体をダウンロードしてここに格納します。
Elixirの場合だとElixir本体とErlang本体、mixによってダウンロードされるパッケージなどもここに格納しています。
最後に環境変数一覧が格納された環境変数のパスが渡されます。
ここで言う環境変数とはHeroku側ですでに設定されている環境変数のことで、環境変数名の名前のファイルに環境変数の値が記載されたものが格納されたディレクトリとして渡されるようです。
FrostやKemalを動かそうとする場合、大体のケースでDBアクセスが必要になりますので、Heroku側で標準で用意されているPostgreSQLを利用する場合などにこのタイミングでアクセス先のDBの情報を読み取ります。
(Frostの場合、ActiveRecord的にDBのカラム名からメソッド名を解決している箇所があるので、ビルド時にDBにアクセスしに行けないとエラーになります)

Crystalのビルドパックではだいたい以下の流れで処理を行っています。

  • ユーザ指定のカスタムコンフィグを読み取る
  • Herokuの環境変数を読み取る
  • Crystal本体のダウンロードとインストール
  • shardsによる関連ライブラリのインストール
  • アプリのビルド
  • ビルド後に実行するコマンドがあれば実行(未実装)

公式のCrystalのビルドパックでは使用するCrystalのバージョンがハードコーディングされていたので、異なるバージョンのCrystalを使う場合都度ビルドパックを書き直す必要がありました。
それをユーザ指定できるようにしたかったので、これはこれで手間ですが、ビルドパスにHeroku用のビルドコンフィグファイルを用意してもらって(ちなみになければなくてデフォルトの設定が走ります)、それを読み取るようにしています。
大体設定しないといけないのがCrystalのバージョンと、ビルドコマンドです。 なんのファイルをビルドするのかも公式のビルドパックではハードコーディングしていました。app.crという名前だった気がしますが、その名前でファイルを作っていないとビルドできませんでした。
この状態だとFrostと激烈に相性が悪いので(Frostだとビルド対象のファイル名はそのままプロジェクト名となる)それも変えたかったので。
後は大体Elixirの流れをそのまま持ってきています。(Elixir固有の設定までベタ打ちしてたのは修正予定です)

release

一番最後に実行されるファイルです。 環境変数の設定とアドオン追加は初回のgit push時にのみ実行されるので、ビルドパスに.profile.dディレクトリを作ってその中にbashスクリプトを設置しておいたほうが柔軟に運用できると思います。 その他、Procfileがない場合の動作を設定できますが、Procfileで制御したほうがまず問題ないかと思います。
複数のビルドパックを指定した場合は、一番最後に実行されたビルドパックのreleaseが実行されます。 極端な話、このファイルに関しては設定があれば少し便利という具合です。

謝辞

最後に、登壇のお声掛けいただいた @pine613さんに感謝を。
RubyKaigi2015のLTのCFP提出するなど年末の行動力以外取り柄がなかった私ですが、初のLT以外のセッションで色々と緊張しっぱなしでした。
次回も何かやりますのでよろしくお願いいたします。

会場提供いただきましたクックパッド様、ありがとうございました。
セッションが始まったらやたら表示が途切れてしまった中対応してくださった、@mirakuiさんと@rosylillyさんには感謝です!
……元々いろいろケチってHDMIケーブルでつないでいたのをVGAアダプタに通してたのでマシンパワーが足りなさすぎでした。。
VGAケーブル用意しておきます。。

ビルドパック作成時にわたわたしてた時にいつもいい感じに援護射撃くださる @zundanさん、ありがとうございました。
またPRくださった、@5t111111さんと@HKDnetさん、まともなテストもできてないポンコツアプリをいい感じにしていただいて感謝です!
最後に、いっつもしょうもない質問に対応していただいているCrystal-JPコミュニティの皆様方、ありがとうございました。

続きを読む "Crystal勉強会でFrostネタで登壇し、Herokuにデプロイするまでを纏める" »

2016年1月29日 (金)

Herokuが東京にやってきた!(正式に)

 

Herokupart2_01

ついに、「Heroku?東京リージョンで使えるよ!」と大手を振って言える時が来ましたね!

 

 

Herokupart2_02

ふむふむ。

過去にもこの話題を紹介していましたねー。

 

 

Herokupart2_03

そうそう。

Heroku EnterpriseのPrivate SpacesがGAになりました!

ようするに、Heroku Enterpriseを利用されているすべての方は、東京リージョンを選択した運用が可能になるのです。

 

 

Herokupart2_04

まー、まー。

いいじゃないですか。

 

 

Herokupart2_05

Enterpriseといっても一般のユーザーも契約できるんですよ!!

 

 

Herokupart2_06

使いたい人は、salesforceの導入前のお問い合わせから質問するとよいかも。

 

 

Herokupart2_07

海外のサーバーですと、自社のセキュリティポリシーが適合しているか、などより多く悩んだりしますよね。

確認作業はゼロにはなりませんが、東京リージョンであれば検討もすこしは簡単になりますよ。

 

 

Herokupart2_08

やはりレスポンスが遅い、というのが気になったりしますよねー。

それも解決。

 

 

Herokupart2_09

Don’t worry! Heroku is in Tokyo!

 

 

Herokupart2_10

 実際にどれだけ費用がかかるのかなー、など調べて使ってみましょう。


作:おっぴー

絵:なかやま

 

関連)

Salesforce Developers Japan Blog・・

Heroku Private Spaces 正式リリース&関連リソース

Publickey・・

Herokuを東京リージョンで動かせる「Heroku Private Spaces」が正式稼働

マイナビニュース・・

セールスフォース、セキュリティ強化などHeroku Enterpriseを拡張

2016年1月13日 (水)

Herokuに関する疑問にお答え

こんにちは、三宅です。
ここ最近、Salesforceが提供するHerokuのトレーニングであるHeroku基礎プライベートトレーニングの講師を担当していました。
案件でHerokuの利用を検討している、またはすでに利用を始めているというお客様のところで、Herokuの特徴やアプリケーションを開発する上での基本的な考え方等について解説を行いました。
Heroku Enterpriseと銘打っているように、SalesforceはHerokuのエンタープライズでの利用を促進しています。Force.comとの連携が必要であったり、開発期間の短いような案件では、Herokuは有力な選択肢となりうると考えています。
ただ、HerokuにはPaaS(Platform as a Service)ならではの特徴があり、これまでオンプレミスのアプリケーションを開発していた人にとって戸惑う部分も多いと思います。今回は、Heroku基礎のプライベートトレーニングで出てきたそういった質問などを紹介していきます。

Herokuへのデプロイ方法

HerokuではGitを用いてアプリケーションをデプロイする仕組みとなっているが、別の方法はないのかという質問が出ました。
Subversionを用いてバージョン管理している場合などに、まず思いつく疑問だと思います。
「git push」以外にGitHub、Dropboxとの連携によるデプロイが可能ですが、GitHubでは結局Gitが必要であること、また共にセキュリティポリシー的に利用が難しい場合が多いでしょう。
Gitを用いたバージョン管理に移行するのが最も簡単ですが、それができない場合はバージョン管理は引き続きSubversionで行い、Gitはデプロイツールとしてのみ用いるという使い方が容易だと思います。
Gitによるバージョン管理の概念や詳細なコマンドを覚える必要がなく、最低限の学習コストですますことができます。

GitHubは必須か

HerokuのGitリポジトリはデプロイのためだけに利用するもので、バージョン管理は別のリポジトリで行う必要があります。
GitといえばGitHubというように取り上げられることも多いのですが、GitHub連携のデプロイを行わないのであれば、Bitbucketなどの別のホスティングサービスを利用したり、イントラネットにGitサーバを用意して利用するなどGitHubに限定されるわけではありません。
また、先ほどのHerokuへのデプロイ方法で述べたように、Suversionでバージョン管理を行うことができないというわけではありません。

ランタイムの選択

Javaランタイムの実装は何か、また選択は可能か、という質問をお客様から受けました。
HerokuのJavaランタイムはOpenJDKのみで、Oracleなどの別の実装を選択することはできません。また、Javaのバージョンは1.7及び1.8のみが利用できます。
Javaに限らず、Herokuでは言語ごとに利用可能なランタイムのバージョンが決まっており、それ以外のバージョンは利用することができません。
最初に利用する予定のライブラリや既存の資産が、Herokuで利用できるランタイムで動作するかの確認が必要になるでしょう。
各言語で利用できるバージョンやその指定方法は、公式ドキュメントのLanguagesに記載されています。

One-off Dynoの連続稼働時間

Herokuを初めてさわった人が戸惑うことの1つに、Dynoの1日1回の再起動が挙げられるでしょう。
レギュラーDyno、つまりリクエストを受け付けるWeb Dynoとバックグラウンドでタスクを実行するWorker Dyno、ともに1日に1回再起動が行われます。
Web Dynoではあまり問題にはならないとは思いますが、Worker Dynoでは時間を要するバッチなどを実行する場合などは気をつける必要があります。Herokuブログの以前のポストであるHerokuのWorker再起動問題を考えるも参考にしてみてください。
では、Heroku Schedulerなどで起動されたOne-off Dynoはどれくらい連続で稼働し続けるのか。
Schedulerの公式ドキュメントには、時間のかかるタスクはWorker Dynoを用いること、Schedulerにより起動されたDynoはスケジュールのインターバルより長い時間起動させることはできず、終了させられると記載されています。最長の期間が1日なので、1日を超えて起動させ続けることはできないと考えられます。
「heroku run」コマンドで起動したOne-off Dynoは自動でのリスタートを行わなため、明示的に接続を切らないと動作し続けると予想されますが、実際のサービスでの利用はとてもできないでしょう。
時間を要する処理がある場合は、適切な粒度に分割したジョブをキューに詰めて1件づつWorker Dynoで処理するなどの設計が必要となるでしょう。
キューを用いたバックグラウンドでの処理の実行の考え方について、Worker Dynos, Background Jobs and QueueingというHerokuの公式ドキュメントが公開されているので参考になると思います。

Web DynoへのリクエストをIPに基づいて制限する方法

調査した範囲内では、そのようなアドオンを発見することができませんでした。
RouterからWeb Dynoへのルーティングは完全にプラットフォームの制御下にあり、フックすることもできないため、Web Dynoにリクエストが到達してから、アプリケーション的に実装するしかないと考えられます。

負荷テストや侵入テスト

負荷テストについては明確なルールはないようで、フレクトではある程度アクセス数が想定されるようなアプリケーションについては、Herokuに対して事前通知などすることなく実施しています。
ただし、全国レベルのテレビ放送で紹介されるなど、プラットフォーム自体に影響があるレベルのアクセスが予想されるような場合は、テストの実施や放送日時などをHerokuへ知らせる必要があるでしょう。
逆に、侵入テストについてはPenetration Testing and Network Scanningに記載のように、事前に通知を送るように明確に定められています。
私はまだ実際にHerokuのアプリケーションに対して侵入テストを実施したことはないのですが。


今回のHerokuブログでは、Herokuのプライベートトレーニングで受けた主な質問を取り上げてみました。
実際の案件でHerokuを使う際の、設計・開発の参考にしていただければと思います。

2016年1月 8日 (金)

CloudSearch使った時につまづいたところ

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

最近お仕事でCloudSearchを利用する機会がありました。
CloudSearchはAWSが提供する検索サービスになります。

cloudsearchを使って検索できるようにするにはざっくりと次のステップがあります。
1.検索ドメインを作る
2.データのアップロード

 


では、色々つまづいた・誤解していた事です↓

データをアップロードするたびに毎回10分かかると思ってた

Cloudsearch_01

検索ドメインを作ると利用できるまでに数10分かかります。

Cloudsearch_management_console_2

コンソール画面から検索ドメインを作ると流れでドキュメントのアップロードもできるのですが、ここでアップロードのたびに10分かかると勘違いしてしまいました。。

 

 

 

アップロードは直列登録しかできないと思ってた

Sketches_03

並列登録もできますよ!負荷がかかってくるとcloudsearch側でオートスケールしてくれます。

Cloudsearch_management_console_inst

画面上でもスケールしたことを確認できました。

 

 

 

アップロードすると504エラーが返ってくる

Sketches_08

アップするドキュメントサイズによってインスタンスを指定してあげましょう。インスタンスが小さいと高確率で504エラーになります。あとアップロードするサイズは5Mになるように調整すること。

https://docs.aws.amazon.com/ja_jp/cloudsearch/latest/developerguide/uploading-data.html#bulk-uploads

 

 

 

検索クエリの条件に指定できるのは1000個まで

Sketches_07

そこまで複雑な利用方法にはならないかと思いますが、念のため。

複合クエリ: 最大 1024 の句を含めることができます。
https://docs.aws.amazon.com/ja_jp/cloudsearch/latest/developerguide/limits.html

 

 

 

クエリ1回につき取得できる件数の上限は10000件まで

Sketches_05

1回のリミットは10,000件だけど、URLパラメータにcursorつけることで次の10000件が取れるよ!最初に取得したcursorから30分かけて50回ほどクエリしたけど、問題なく取得できました。その間取得したレコードから削除のjson投げてますが、正常に全件取得・削除ができました。

https://docs.aws.amazon.com/ja_jp/cloudsearch/latest/developerguide/paginating-results.html#deep-paging

 

 

 

項目追加、型変更したらインデックス再作成しないといけない

Cloudsearch_10

よく見ると項目一覧の上の方にメッセージが表示されてました。

Cloudsearch_management_console

インデックスの再構築が必要のようです。「Run Indexing」ボタンを押して、しばらく待ったら使えるようになりました。登録されているドキュメントの数によっても時間は変わりそうですね。

 

 

 

料金の上限設定とかできない

Sketches_09

どの設定で動かしたか不明ですが、気付いたら10万円ぐらいつかってました。課金は稼働しているインスタンスが使われている時間がほぼ全てと言ってもいいぐらいかも。主に一括アップロードするときの並列処理のさせかたでガツンとスケールされてしまうので、最初の設定には気をつけましょう。

 

 

 

バッチの課金が1回0.10 USDだと思ってた

Cloudsearch_11

1000回に付き0.10 USDですね。

バッチの課金は安いけど、並列で登録することでオートスケール(課金対象)されるので、登録時間に余裕があれば直列とかウェイトかましてもよいかもです。

 

 

 

セキュリティの設定

Cloudsearch_12

設定できるのは以下のパターンのみ。(テキストエリアで直接編集することも可能!)

後からでも変更できます。

Cloudsearch_management_console

  • 検索だけ誰でもOK
  • 検索も登録も誰でもOK(おすすめしないやつ)
  • IPで制限かける(カンマ区切りで複数OK)
  • 非公開(コンソールからの利用のみ)
  • 別のドメインからコピー

セキュリティグループの設定はなかったよ。(テキストを直接編集することでカスタマイズすることで利用できるようになるかも?。。調べきれてません)

 

 

 

数値項目の合計ができない!と思ったら、英語版の資料に書いてあった件

Sketches_02

日本語ドキュメントに頼りすぎた。

http://docs.aws.amazon.com/cloudsearch/latest/developerguide/retrieving-stats.html

 

使わないCloudsearchを休止できない

Sketches_06

deleteのみ。稼働している分だけ課金されるので、不要なものはバックアップとって削除しましょう。

 

 


インデックス作成には多少手間時間がかかるものの検索性能はすばらしいです!

(参考)

第15回 Solr勉強会 #SolrJP Amazon CloudSearch Deep Dive

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の使い方は紹介しないとまずいよね" »

採用情報

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

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

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

フレクト採用ページへ

会社紹介

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