第2回 日本Seleniumユーザーコミュニティ勉強会に参加してみた
第2回 日本Seleniumユーザーコミュニティ勉強会 - connpass に参加しました!
「勉強会はブログを書くまで」ということで、ざっくりと感想まで。
ハッシュタグ「#seleniumjp」に勉強会中のツイートが流れてます。
Seleniumをもっと知るための本の話(玉川竜司さん)
エンジニアたるもの英語情報を読むといいよ、というお話。耳が痛いですね。
英語の技術書を読むには、このあたりを利用するとよいそうです。特に、Safari Books Onlineについては定額サービスで面白いですね。
脱・独自改造!GebでWebDriverをもっとシンプルに(玉川紘子さん)
Geb(じぇぶ)の紹介でした。
WebDriverをJavaで書くとDOMを操作するときのような煩雑さがあり、テストコードが長くなってしまいがち。Gebを利用すると、要素検索などをjQueryライクに記述でき、かなりスッキリとしたテストコードが書けるとのこと。
GebはGroovyで利用するライブラリで、Javaで利用する場合はFluentLeniumがあるようです。
海外のSeleniumカンファレンスではどんな発表がされているのか2014(伊藤望さん)
Selenium Conference に動画や資料が上がっているので、見てみると面白いよ、というお話。
いろいろおもしろいタイトルの発表があるようです(笑)。
ハイパフォーマンスSeleniumテスト@サイボウズ(宮田淳平さん)
Kintone中の人によるテスト自動化に関するお話。
Platformerということもあり、自動化には結構力が入っている感じでした。大規模なアプリケーションに対して、テストケースの軽量化、並列化を行って、テスト実行が30分以内で収めているところに並々ならぬ意気込みを感じました。
「テストコードの品質は製品のコードと同様に重要になってくる」
この言葉にはテスト自動化で苦労してきた重みを感じました。
社内勉強会で利用した書籍たち。
継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化
- 作者: David Farley,Jez Humble,和智右桂,高木正弘
- 出版社/メーカー: アスキー・メディアワークス
- 発売日: 2012/03/14
- メディア: 大型本
- 購入: 24人 クリック: 567回
- この商品を含むブログ (52件) を見る
実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects’Archive ソフトウェア開発の実践)
- 作者: Janet Gregory,Lisa Crispin,榊原彰,増田聡,山腰直樹,石橋正章
- 出版社/メーカー: 翔泳社
- 発売日: 2009/11/28
- メディア: 大型本
- 購入: 3人 クリック: 142回
- この商品を含むブログ (52件) を見る
クックパッドアプリの開発を支援するAppiumの話(松尾和昭さん)
クックパッド中の人によるモバイルアプリのテスト自動化に関するお話。
Appiumでテスト自動化する範囲、ユニットテストで自動化する範囲、人間系でテストする範囲を意識的に分けて、最適な分担を戦略的に考えているところは参考になりました。
Chatterが有効化されているか判定する
ChatterのプロファイルベースのロールアウトがSummer'14からGAとなりました(有効化するためにはサポートへの連絡が必要です)。
これによって、組織としてはChatterを有効化してもユーザレベルではChatterを無効化することができるようになりました。そのため、利用しているユーザがChatterを利用できるか判定するための方法が変わってきます。
ということで、Chatterが利用できるか判定する方法を調べてみました。
有効化していない場合
組織単位でChatterが有効化されているかチェックする
ConnectApi.OrganizationSettings o = ConnectApi.Organization.getSettings(); System.debug('Chatter=' + o.features.chatter);
有効化した場合
ユーザごとにChatterが有効化されているかチェックする
ConnectApi.UserSettings u = ConnectApi.Organization.getSettings().userSettings; System.debug('Chatter=' + u.hasChatter);
基本的には、ConnectApiを叩けば値を取得できます。UserSettingsクラスのhasChatterはChatterのプロファイルベースのロールアウトを有効化していない状態でも値を取得できましたので、有効化した場合の書き方をしておけば、どちらの状況でも対応できそうです。
ただ、UserSettingsのhasChatterはAPIレファレンスに載っていないようなので今後変更になるかもしれません。
Enjoy Chatter!
2014/8/17追記:APIリファレンスに掲載されていることを確認
Salesforce DUG [Tokyo] Meetup #6 で輪読発表してきました!
Salesforce DUG [TOKYO] #6 Meetup に参加してきました。
今回も会場は、株式会社セールスフォース・ドットコム社のセミナールームをお借りし、Pizza&Drinkもいただきました。いつもありがとうございます!
幹事メンバーは時間を過ぎて到着…。
ごめんなさい、ごめんなさい。次回はちゃんと会場設営手伝いますぅ。
ということで、御礼と謝罪が終わったとこで本題に。
全体の流れについては、なかやまろぐ
なかやまろぐ: Salesforce DUG [Tokyo] Meetup #6にいってきた!
を見てもらうとイラスト付きでわかりやすいので、そちらに譲ります。
Salesforce Summer'14がリリースされるので、新機能の輪読として「ISVforce」パートを担当しました。今回正式リリースになるUsage Metricsの落とし穴あたりを中心に発表しました。
さて、6/9のSalesforce1 Crowd Hack ChallengeのLTでは落選した挙句「安易に猫に逃げるのは…」と発想の陳腐さを斬り捨てられたわけですが、今回は「富豪プログラム…」との誹りを…。
うぅ…心が…。
でも、悪いことばかりじゃない。いいこともありました!
そう、@nakayama_sanにイラスト描いてもらえました!ありがとうございます!
Enjoy Meetup!
Salesforce Developer User Group [Tokyo] Meetup #5 のまとめ
5/19 に開催されたAppExchange Developers Meetingの帰りがけにS1 DevWeekのおみやげをゲットしました!ビニールを開けるのがめんどうだったので…。
(誰か郵送を頼んだ人いるのかな?)
せっかくブログを書くので、ついでにSalesforce Developer User Group Tokyo Meetup #5 の発表資料のまとめです。
Mobile HackChallengeエントリ紹介(1)
- pomu0325 Yaccl
- a_kuratani +Message(#寿司forceの楽しみ方)
Mobile HackChallengeエントリ紹介(2)
- stomita Salesforce1 最速経路
- i556 Inside Quizar
- yonet77 進捗どうですか?
6月の開発者向けイベントとスピーカーの公募のご案内
- mitsuhiro Salesforce1 Developer Week
LT
- Masato Setoyama Salesforceモバイル案件で経験した3つの難しい要件とその対応方法
- Masashi Nishiwaki Salesforce Mobile SDKにモノ申す!
6/9 には Salesforce1 Developers Community MAX が開催されます。Hack Challengeのテーマもこちらで発表されています。期間も短くテーマも多いので、高確率で賞金をゲットできるかもしれませんね!
Enjoy Hack Challenge!
Salesforce Developer User Group [Tokyo] Meetup #5で発表してきました!
技術的には話すことないので文字通りネタで埋め尽くしました(最後のページとか)。
少しだけ補足。
技術的に話すことはない、と書きましたが、ちょっとだけ補足しておきますと、AngularとForce.comを組合せて実装する上で困難な課題やトピックがなかったということです。
一昔前から考えると、Force.com上でごく普通の技術を適用してごく普通に作れたことは、昔からやっているエンジニアから見ると逆に衝撃的なことなのかもしれません。
最後に、AngularJSについて。
AngularJSの特徴ですが、DOM操作なしでコーディングできるので、個人的にはかなり気持ちいいコーディングでした。
View(HTML/CSS)、Controller(JavaScript)、API(Apex)という分割も分かりやすくてよかったです。
AngularJSは学習曲線が2段階になっていて途中の停滞期がある、と聞きますが、今回のアプリでは停滞期を超えるほどの技術を利用していないです。なので、ページ再描画の仕組みとか、難読化対応などはまだ理解してないのです。
ただでさえ起動の遅いSalesforce1のWebViewで、重たいAngularJSを使うことの是非はありそうなので、もっと軽量なものを使ってもいいかもしれません。
注記
上記のことは、標準画面では満足できないときの開発よりの話です。VisualforceタグやAuraはユーザ自身が簡単なページを準備したり、標準画面に組み込んだりするために利用されると思います。
Enjoy #寿司force!
AntでForce.comのソースコード中の文字列を置換する
Force.comでパッケージ開発しているリリース組織用に名前空間をセットしたり、開発用/テスト用/本番用で外部参照するURLを変えたり、スクリプトをキャッシュさせないためにURL末尾にユニーク文字列を追加したりしたくなることがあります。
そんなときは、Antのreplaceタスクで書き換えてしまうのがお手軽です。
前提とするファイル構成
ここでは下記のようなファイル構成となっているとします。
[プロジェクト] ├ build.properties ├ build.xml ├ [build](自動で作成する) ├ [resource] | ├ [SampleResource] | └ [...] └ [src] ├ [pages] | ├ SampleView.page | └ SampleView.page-meta.xml ├ [staticresources] | ├ SampleResource.resource | └ SampleResource.resource-meta.xml └ [...]
ソースコード中の文字列を置換する
ここでは名前空間を本番用に置換するためのビルドファイルをサンプルとしました。
そのまま書き換えてしまうとビルドのたびにソースコードが変更されてしまうので、一旦コピーして変換するようにします(ソースコード (1))。
その後、名前空間を本番用に変換します(ソースコード(2))。
ここでは、「NAMESPACE」という文字列を「sampleapp」という文字列に置き換えています。
最後に、ソースコードをデプロイします(ソースコード(3))。
<target name="release"> <echo message="release: ${now}" /> <echo message="username: ${sf.username}" /> <echo message="serverulr: ${sf.serverurl}" /> <!-- (1)前回のソースコードを削除してソースコードをコピーする --> <delete dir="${build.dir}/src" /> <copy todir="${build.dir}/src" preservelastmodified="true"> <fileset dir="${src.dir}" /> </copy> <!-- (2)ソースコードを変換する --> <replace dir="${build.dir}/src" token="NAMESPACE" value="sampleapp"> <exclude name="**/*.xml" /> </replace> <!-- (3)ソースコードをデプロイする --> <sf:deploy username="${sf.username}" password="${sf.password}" serverurl="${sf.serverurl}" maxPoll="${sf.maxPoll}" deployRoot="${build.dir}/src" /> </target>
まとめ
もうほとんどForce.comは関係なく、Antの話になってしまっていますが、Force.comのパッケージ開発でちょっとAntに詳しくなっておくとリリース作業を大幅に自動化できます。
他の高機能なビルドツールに比べてAntはお手軽に導入でき、学習コストも低いので個人的にはとてもオススメです。
Enjoy Deploying!
AntでForce.comのStatic Resourceファイルを作成する
Force.comで開発していく上で、Static Resourceファイルを作成するのは手動で行うには面倒です。
Static Resourceファイルはファイル拡張子だけ変更してアップロードしてしまう方法もありますが、そうしてしまうとどんどんファイル数が多くなってしまいので、ZIP圧縮でファイルを一つにまとめてしまったほうがすっきりします。
とはいえ、JavaScriptやCSSを変更するたびに手作業で 不要ファイルを除去→ZIP圧縮→ファイル名変更 するのはさすがに厳しいです。そこで、AntでStatic Resourceファイルを作成させてしまえばいいんじゃないか、というわけです。
前提とするファイル構成
ここでは下記のようなファイル構成となっているとします。
[プロジェクト] ├ build.properties ├ build.xml ├ [build](自動で作成する) ├ [resource] | ├ [SampleResource] | └ [...] └ [src] ├ [staticresources] └ [...]
Antの呼び出し部分
以下のようにarchiveタスクにリソース名(SampelResource)を指定すると、src/staticresource/SampelResource.resourceを作成するようにAntマクロを作成してみました。中間ファイルとしてbuild以下にZIP圧縮前のファイルをコピーしています。
<target name="make"> <archive resource="SampleResource" /> </target>
Antマクロ
実際にStatic Resourceファイルを作成しているAntマクロは下記のようになっています。属性として指定されたリソース名に基づいて処理を実行します。一旦build以下にStatic Resourceに含めたいファイルのみコピーしてからZIP圧縮していますので、不要なファイルを開発組織にデプロイすることもなくなります。
<macrodef name="archive"> <attribute name="resource" /> <sequential> <echo message="compress: @{resource}" /> <delete dir="${build.dir}/@{resource}" /> <copy todir="${build.dir}/@{resource}" preservelastmodified="true"> <fileset dir="${resource.dir}/@{resource}"> <patternset> <include name="**/*.gif"/> <include name="**/*.png"/> <include name="**/*.js"/> <include name="**/*.css"/> </patternset> </fileset> </copy> <zip basedir="${build.dir}/@{resource}" destfile="${src.dir}/staticresources/@{resource}.resource" /> </sequential> </macrodef>
元ファイルは こちら です。
まとめ
これでStatic Resourceファイルを手軽に作成できるようになりました。
本格的にやるのであればGruntなどを使ってもいいところですが、インストールするものが多くなってしまうので、Antでちゃちゃっとやるのもいいと思います。
Enjoy Deploying!