astamuse Lab

astamuse Labとは、アスタミューゼのエンジニアとデザイナーのブログです。アスタミューゼの事業・サービスを支えている知識と舞台裏の今を発信しています。

そうだAsta4dでWebアプリケーションを作ろう(第2回)

定期外ですが、月1くらいで書いて連載を終わらせようとしているnkgwです(ルール的に問題なし)。

前回は静的なページを表示することでAsta4Dのプロジェクトを作って表示するところまでをやりました。
第2回目は静的なページだけではWebアプリケーションとしては不完全です。
そんなわけで動的ページを表示させれるようにします。

動的ページを作る手順

動的ページを実際に作りながら説明します。

プロパティファイル書き込み

URLルールと同じようにSnippetクラスを置くパッケージ名を書きます。
ついでにcache機能をoffにしたいので、cacheの設定も書き込む事にします。
cache設定については開発中はoffにしておかないと直してもすぐに反映してくれないので、開発環境ではoffがおすすめです!(忘れたこと数知れず)

cacheEnable=false
snippetResolver.searchPathList=com.astamuse.blog_sample.snippet

cacheの設定はcacheEnabletrue falseのどちらかを設定します。
設定してない時はtrue扱いされるらしいです。

Snippetの場所はsnippetResolver.searchPathListにパッケージ名を入れます。
書かなくてもよいのですが、Snippetを大量に書くようになった時に面倒になるので設定を追加した方が良いと思います。
複数のパッケージに分ける場合は一番上のパッケージまでを書くようにすればオッケーです。
com.astamuse.blog_sample.snippet.patent com.astamuse.blog_sample.snippet.keywordみたいな構成ならcom.astamuse.blog_sample.snippetまでという意味です。

HTMLテンプレート作成

HTMLがないと話になりませんので、元となるHTMLファイルを作成します。
今回はサンプルなので、簡単なHTMLファイルを用意しました。

<html>
<head>
<meta charset="utf-8" />
</head>
<body>
<p class="text"></p>
</body>
</html>

今回はこのpタグにSnippetで何か書く事を目標にします。

HTMLテンプレートにSnippetを埋め込む

サーバーでレンダリングする際は、Snippetの概念的に分割したレンダリングをするべきとの考えなので、bodyタグ全体を一気にレンダリングさせずに必要な場所だけレンダリングするように印を埋め込みます。
埋め込み方については先に説明するのが難しいので、先にコードを見てから説明したいと思います。

<html>
<head>
</head>
<body>
<p afd:render="IndexSnippet:showRenderer" class="text"></p>
</body>
</html>
<html>
<head>
</head>
<body>
<afd:snippet render="IndexSnippet:showRenderer">
<p class="text"></p>
</afd:snippet>
</body>
</html>

埋め込み方的には大体この2パターンです。
afd:snippetタグで埋め込むか普通のhtmlタグ内に属性として埋め込むかですね。
必要な場所に埋め込むということで、両方とも今回対象となるpタグに対して効果がおよぶような記述としました。

埋め込む時のルールとしてはSnippetクラス名:メソッド名という形で書きます。
クラス名は省略不可で、プロパティファイルに記載したパッケージ名とここに書いた内容でクラス名が特定出来るようにしなければなりません。 なので、プロパティファイルにSnippetのベースパッケージを指定しない場合は以下のように書いてください。

render="com.astamuse.blog_sample.snippet.IndexSnippet:showRenderer"

上で面倒と書いたのは、com.astamuse.blog_sample.snippetの部分を毎回書くのは面倒ってことです。
本格的なWebアプリケーションになると沢山これを書くことになるので、さすがに毎回大量に書くのは思ったより骨です。
なんかしらの理由でパッケージ移動なんて起きた日には見るも無残なことになることうけあい。

メソッド名については省略可能ですが、省略してもあんまりよいことがないので個々で付けてください。

Snippetの実装

HTMLに書いたSnippetをjavaで書いていきます。 今回はIndexSnippetクラスをcom.astamuse.blog_sample.snippet配下に作り、showRendererメソッドで書き込む事としまたので、その通りに実装していきます。

package com.astamuse.blog_sample.snippet;

import com.astamuse.asta4d.render.Renderer;

public class IndexSnippet {

    public Renderer showRenderer() {
        Renderer renderer = Renderer.create();
        renderer.add(".text", "Snippetで書いたテキストです");
        return renderer;
    }
}

実装しました。
メソッドの戻り値はRendererクラスでここにDOM対してのレンダリング処理を入れ込みます。
第一引数にselectorを指定(指定の仕方はjqueryなんかと同じです)、第二引数にvalueを指定です。
他にも指定の仕方が色々ありますが(これは次回で説明)、基本形としてはこのような指定をします。

1つのRendererで複数個所レンダリングしたい場合は、次々とaddしていけばオッケーです。
ただ、何回か書いているように分割したレンダリングとするべきなので、ある程度の粒度で

起動

http://localhost:8080/に接続すると、指定したvalueが表示されていると思います。

補足

今回、class名でレンダリングしましたが、class名でレンダリングする場合はプレフィックスルールを決めると良いです。 せっかくHTMLとレンダリングロジックが分離されているのに、競合してしまうと意味がありません。

次回予告

次回はもう少しSnippetについて深堀していきます。

関連URL

第1回:環境構築して静的ページを表示するまで
第2回:Snippetを使って動的ページを作ろう(今ここ)
第3回:少し複雑なSnippet
第4回:Handlerの役割と使い方
第5回:Global Handlerとattribute
第6回:Form Flowを使おう

プロトタイピングツールでデザインの作業効率を上げる

アスタミューゼデザイン部のMatsumotoです。
ここ最近astamuse.comastaIDのスマホ最適化の取り組みに合わせて、プロトタイピングツールを実験的に使い始めました。 ツールを使い始めてからまだあまり月日が経っていませんが、とにかく便利!
ストレスなく今までのデザインプロセスが改善しそう!
ということで、今回はプロトタイピングツールを使う利点や、実際のサービス開発において、どう作業効率がUPしたのかについて紹介させていただきます。

 目次

プロトタイピングツール概要

そもそもプロトタイピングとは何?

プロトタイピング(Prototyping)とは、実働するモデル(プロトタイプ)を早期に製作する手法およびその過程を意味する。その目的は、設計を様々な観点から検証する、機能やアイデアを形にすることでユーザーから早めにフィードバックを得るなど、様々である。

プロトタイピング - Wikipediaより

Webデザインで使うプロトタイピングツールとは、Webやスマホサイト・アプリを設計する際、チームで共有しながら、コードなしで、デザイン画面の画像のみでプロトタイプを効率的に作れるWebサービスのことです。
年々多くの便利なツールが登場してきているので、現在知っているだけでもすごい数ありますが、その中でもデザイナーの評価が高くて、多数の企業が使っているツールを試験的に使ってみました。

ツールを使用するようになった経緯

冒頭でふれましたが、astamuse/astaIDでは、現在スマホ最適化を進めています。
モバイルでの実機確認を手軽にしたかったので、ツールを使用し始めました。
リリース当初のターゲットユーザー像は、オフィスで仕事時間中に使うことを前提としていましたが、現在はスマホ・タブレットの普及やユーザー層の変化もあり、段階的にいくつかのコンテンツのスマホ対応を進めています。

f:id:astamuse:20160809174727p:plain
現在制作中 / marvelの画面

ツールを使う目的

私が主にツールを使い始めた目的は、以下4つです。

  1. モバイルでの実機確認したい
  2. ワイヤーフレームや画面遷移・トランジションの確認をしたい
  3. ボタンタップ後の動きインタラクション検討したい
  4. デザイナー・エンジニア間での共有&認識の相違をなくしたい

f:id:astamuse:20160809182003p:plain
現在制作中 / Prottのプレゼン用画面 ※背景画像、端末設定が細かく設定できるのが楽しい

使ってみた3つのサービス比較

基本機能はほとんど同じです。

  • プロトタイピング
  • モバイルでの実機確認
  • デザインレビュー
  • 複数メンバーとのプロジェクト共有
  • Slackとの連携
  • コメント付与

ただ、それぞれのサービスごとに、わずかですが機能の違いはあります。(下記表まとめ参照)

サービス [inVision]
f:id:astamuse:20160809105559p:plain:w120
[marvel]
f:id:astamuse:20160809105603p:plain:w120
[Prott]
f:id:astamuse:20160809105607p:plain:w120
会社場所 ニューヨーク ロンドン 東京
主な利用企業 twitter
UBER
Linkedin
salesforce
Evernote
sony
ustwo
M&S
DigitasLBi
GA
TransferWise
DICE
Yahoo!Japan
DeNA
RECRUIT
cookpad
GREE
IDEO
同期 Dropbox
Googledrive
Slack
Basecamp
Dropbox
Googledrive
Slack
Basecamp
Dropbox(自動更新なし)
Slack
ワイヤーフレーム作成機能 なし あり(無料) あり(有料)
インポートファイル形式 JPEG
GIF
PNG
PSD
ai
Sketch
JPEG
GIF
PNG
PSD
PDF
Sketch
JPEG
GIF
PNG
PSD
Sketch
シェア URL
Email
SMS
Embed
URL
Email
SMS
Embed
URL
Email
Embed
料金(月額) 無料(FREE)
$15(Starter)
$25(Professional)
$99(Team)
応相談(Enterprize)
無料(FREE)
$15(Pro)
$19(Plus)
$45(Company)
応相談(Enterprize)
※年間契約20%OFF
無料(Free)
1,900円(Starter)
3,900円(Pro)
7,400円(Team)
応相談(Enterprize)
※年間契約10%OFF 
その他特徴 -バージョン管理機能
-画面単位での進捗管理機能
-ユーザーテスト機能
-無料版でプロジェクト2つまで作成可能
-ユーザーテスト機能
-プレゼン機能(背景画像、端末設定)が細かく設定可
-日本語対応

2016/08/17時点まとめ

どのツールもUIが美しくて、直感的に操作できて、各種ツールの使い方もほとんど同じなので学習コストも低く、ほんと使いやすい!
こんな素晴らしいツールを提供してくれるなんて、制作&開発者に感謝です。

私個人的には、marvelのUIが好きです。UIのアニメーションの動きの気持ちよさや、色使い、アイコン、イラスト等、ポップな感じが使っていてとても楽しいです。ただ、今後デザインメンバーが増えてプロジェクト数が増えていくと、inVisionが使いやすいかなと思っています。(バージョン管理や進捗管理機能など充実)
どのツールを有料プランに切り替えて使い続けるかは、もう少し様子みて検討(+他メンバー&上司と相談)しようかなと思います。

何が変わった?

使い始めてからあまり月日が経っていないので、まだ使いこなせていない感はありますが、改善しはじめている点はいくつかあります。

デザインに対してエンジニアからのフィードバックが増えた

ツールを使う目的の1つである「デザイナー・エンジニア間での共有&認識の相違をなくしたい」と言う事が、プロトタイプを作って共有することで、エンジニアからの意見をもらいやすくなり、デザインラフの段階から、そのフィードバックを反映しやすくなった。

デザインレビューの回数&時間が短くなった

今まで1画面づつデザインの確認をしていましたが、画面遷移する複数ページをすべてまとめてレビューしてもらえるようになったので、レビューの回数&時間が総合的に短くなった。

フィードバックからのデザイン修正、共有のフローが楽になった

下図で詳細を記載していますが、これが一番うれしい。
今まで、4ステップだったのが、1ステップになった。かなりの効率アップ!

f:id:astamuse:20160810162726p:plain

まとめ

色々使っていて楽しいプロトタイピングツールですが、今現在に限っては、スマホ化対応のためだけに使用しています。通常のwebサイトの開発&改善の際は、今まで通り上記で述べているようなフロー(プロトタイピングツールを使用しないフロー)で進めている状態です。 プロトタイピングツールと言っても、ただ単にデザインレビューやデザインチェックツールとして、メンバーからの意見を反映しやすかったりと重宝しそうなので、積極的に使って、より効率的にプロジェクトを進めていきたいです。

アスタミューゼではサービスをより良くしていくため、一緒に働いてくれるデザイナー・エンジニアを募集しています。ご応募おまちしております!

参考サイト

クラウドにあるステージング環境のシステムコスト大幅削減を進めている話

こんにちは。並河(@namikawa)です。

このブログは持ち回り制にしているのですが、前回分でメンバーが一通り書き終えましたので、今日から2巡目になります。早いなぁ。

幸いにしてエキサイティングな毎日なので、ブログに書くようなネタはたくさんある(真顔)のですが、一緒に開発・デザインしてくれるメンバーが早くたくさん来てほしいと思う今日この頃です。

さて、今回の私のエントリは、タイトルの通り、弊社で持っているサービス群のステージング環境のシステムコストの削減を進めている話をします。

・・・本当は、弊社オフィスのある銀座近郊の美味しいラーメン屋を紹介するエントリとか書きたいんですけど、技術ブログという名目でありながら前回のエントリも技術っぽくない内容だったのと、おまえ会社のブログで何書いてるんだと上から怒られそうなので、ちゃんと真面目に(技術の話を)書こうかな、とw (冗談です。怒られません。)

その前に前提の話

少し話はそれますが、弊社のサービスの多くは所謂オンプレな環境で本番稼働しています。そして、私が入社した時点では、試験的な意味合いでステージング環境が AWS (Amazon Web Servoces) 上で動いていました。

その後、社内で検討を重ねた結果、サービス基盤の方向性として、 Google Cloud Platform (以下GCP) を利用する方針としました。なぜそうしたか、については話すと長くなりそうなので、またの機会に別途書こうかと思いますが、現状として、サービスのステージング環境を GCP (主にGCE) へと移行している段階です。

コスト削減をどのように行ったか

f:id:astamuse:20160810113214j:plain

で、ここから本題。セキュリティの都合上、書きにくいこともあるので、手法の一部は割愛しますが、

  • GCE (Google Compute Engine) を使うことにした
  • ステージング環境の稼働時間を平日日中だけにした
  • インスタンスのスペックを見直した

あたりをメインに見直しました。それぞれについて、簡単に説明します。

GCE (Google Compute Engine) を使うことにした

元々、ステージング環境は AWS で運用していましたが、前述の通り、本番環境をオンプレで運用している関係上、ステージング環境については Amazon EC2 をメインとして使っています。

気持ち的には、クラウドサービスを活用したサーバレスアーキテクチャだとかデータ解析基盤とか、こんな風に変えていきたいなーと色々考えましたが、大人の事情もあって、本番・ステージングともに、まずは現状の使い方の延長線上で考える方針としました。

それではと、単純に機能・コストを比較してみたときに、 AWS (EC2) よりは GCP (GCE) の方がコストメリットが出そうだという事がわかりました。

これは弊社サービスの特性上、それなりのデータ量を抱えたデータストアが多く、インスタンスのストレージコストでの差が大きく出た、という点が大きかったことに尽きます。 また、データがたくさんある以上、バックアップを保管する際にも、GCS の Nearline Storage のように安くてそこそこスペックの大容量ストレージがあることもポイントです。

機能的な面においても、比較的低スペックのインスタンスについても、他クラウドサービスと比べて、ネットワークスループットが良く、大量データをインサートするときなんかにもボトルネックになりづらい点も助かります。

クラウドサービスを活用する以上、将来的には、マネジメントサービスをもっと活用していきたいとは思いますが、現状、 GCP は AWS ほどのバリエーションはないので、そこに関してはクラウドサービスの今後の動きを注視しつつ、見極めていきたいなと考えています。

ステージング環境の稼働時間を平日日中だけにした

コスト削減効果としては、これが一番大きいのですが、ステージング環境の稼働時間を、平日日中だけ、つまり関係者が働いている時間帯だけに限定しました。

皆さん、帰宅の際にオフィスに誰もいなかったら、オフィスの電気を消して帰ったりしますよね?あれと同じで誰も使っていない時間はサーバを落としましょう、という話です。

とは言え、最後の人が全インスタンスを落とすのは大変だし、オペミスの温床になる可能性もあるため、 Jenkins で自動化していて、具体的には、以下のような感じで運用しています。

  • 平日の9時45分頃からインスタンスを自動起動、同じく平日の22時頃にインスタンスを自動停止しています
  • インスタンスの自動起動/停止は、 Jenkins のジョブで行っています
  • 22時以降も利用するために延長したい場合は、開発メンバーが Jenkins ジョブのスケジュール設定を変更します



その他、注意点や工夫した点は、以下の通りです。

  • 月〜金の中には、祝日が含まれるタイミングがあるので、祝日はインスタンスを起動しないようにしました
    • こちらの祝日判定ライブラリを活用させていただきました
    • 年末年始休暇とか、会社特有の休日は、上記ライブラリだけだと不十分なので、別途自前で対応が必要です
  • インスタンス自動停止ジョブについては、急遽休日にインスタンスを起動した場合などでも落とし忘れがない様、平日に限らず毎日実行しています
  • 延長などで、 Jenkins ジョブのスケジュールを変更した場合、設定の戻し忘れを考慮して、毎朝ジョブの設定を元に戻す"ジョブ"を実行しています
  • ジョブの単位は、サービスごとであったり、データクラスタなど、依存関係や起動順序を意識すべきインスタンス類をまとめて作るようにしました

この結果、ステージング環境の稼働時間は、元々の3分の1程度になりました。クラウドサービスを使うとサーバインスタンスなどは時間単位の従量課金になるので、その分のコストが浮く事になります。

インスタンスのスペックを見直した

これは、リプレースや移行をするタイミングなどで、必ず検討する内容だとは思いますが、実際に使われているリソース量などをベースに、インスタンスのスペックを決めます。

ステージング環境の位置付けにもよりますが、アプリケーションの機能テストを行う場、だとすると、リソースに大きな余裕を持たせる必要もないかと思います。 また、モノにもよりますが、不必要に冗長になっている構成も一部削減したりなど、見直しを実施しています。

基本的には前述の通りですが、弊社のステージング環境は、毎日シャットダウンする前提ですので、その前提だとインスタンスのスケールアップ/ダウンも容易です。

このように、まずはスモールスペックでスタートし、実際に使いながら適宜必要なものを使っていくという考えがクラウドサービスを活用する上では必要かと思います。

結果

その結果、コストはどうなったか、という話ですが、残念ながらまだ移行の途中ではあるので、正確な before/after な数値は出ていません。ごめんなさい。

ですが、現状の手応えとシミュレーションの結果をあわせて考えると、システムの稼働時間を大きくカットしたことと、元々の使い方に少々無駄があったこともあり、必要コストは約 75% 〜 80% 程度カットできる見込みであることを報告しておきます。(あくまでステージング環境の、ですけどね。でも結構大きいのよ。)

・・・という見込みと大人な事情から、さっさと移行してしまって、もっと新しいことを進めていきたいので、色々とお手伝いしていただける方を大募集中です。是非、下部のバナーから(ry

それでは!=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

Copyright © astamuse company, ltd. all rights reserved.