CI/CDが好きな奴ちょっと来い
はじめに
2017年2月9日(肉の日)に株式会社チームスピリットで開催されたCI/CD NIGHTに参加&LTしてきました。CI/CDに関連する話題をLTする勉強会+懇親会でCIサービスの旬など面白い話題を聴くことができました。
LT発表
発表したLT資料はこちらになります。
www.slideshare.net
掻い摘んで内容を紹介すると、SeleniumでE2Eテストしたいのであれば、idやclassを適切に振ってあげましょう、という話です。
特に、React.jsではDOMを操作する意識をしなくて済むような仕組みになっています。そのため、意識してidやclassを付けてあげないとDOMベースのSeleniumとは相性が悪くなってしまいます。
そこの辛みを緩和するために、React.jsで作ってSeleniumでE2Eテストを自動化しようとしたときに苦労しないように、どこにidやclassを仕込んでおけばテスト自動化しやすくなるかリストを作ってみました。
あまり良い言葉でリストをまとめることができなかったですが、ブラッシュアップしていきたいと思いますので、優しいご意見・ご要望をお待ちしております。
むすび
CI/CDでどれくらい人が集まるのかと思いましたが、思いの外満員御礼でびっくりしました。登壇者について言えば、こんな感じでした。
「CI/CDが得意なフレンズなんだね!すご〜い!」
あと、懇親会ではピザと寿司が出て、美味しくいただきました!
「たのし〜!」
逆転の発想で考える2017新年会
最近、ブログ更新が滞っており、久しぶりの投稿です。
ちなみに、タイトルはホッテントリ―入りを目指して(ない)ホッテントリ―メーカーで作ってみました。
ということで、2017年1月25日に開催されたTokyo Salesforce Developer Group 2017新年会に参加&LTしてきました。
LTでは、昨年末に開催した Advent Calendar をふりかえりました。昨年は3投稿させてもらったのですが、1つはPodcast収録方法で、1つはPodcast配信で…。まぁ、それはいいや。
Salesforce App Cloud Advent Calendar でQiitaのいいねをもっとも集めた投稿(2017年1月25日時点)は、以下の2つでした。
- UI/UX変更の際に、サービス、ユーザ、実装者という3つの観点で気をつけていること(shokolatedayさん)
- 開発組織(Developer Edition)をサインアップした後にやることリスト(stomitaさん)
ただし、Qiitaではない外部のブログに記事を投稿してもらったものについては集計できないので、対象外になっています。外部のブログに書いてもらった記事も面白いものがたくさんありました。
LT資料はこちらです。
www.slideshare.net
今年もmigration.fmともどもよろしくお願いします!
一応、新年の抱負としてPodcast配信月一回ペースで、という話をしたので、もう少し頑張っていきたいと思います。
migration.fm
第3回 日本Seleniumユーザコミュニティ勉強会に参加してきた!
今日は久しぶりの日本Seleniumユーザコミュニティ勉強会の日!
調べてみたら、前回は2014年10月じゃないですか。ちなみに第2回の勉強会に参加した時のブログ投稿はこちら。
ということで、ヤフー株式会社にお邪魔してきました。
セッション
セッションの振り返りをざっくりと。詳細は後日資料が発表されるはずなので、そちらを確認するということで。
「Seleniumデザインパターン & ベストプラクティス」の勘所
発表者:太田健一郎さん & 玉川紘子さん (SHIFT)
- 自動テストを構築していくうえで、保守性を考えてレイヤーを分けて構築する必要がある
- 書籍「Seleniumデザインパターン & ベストプラクティス」では、順を追ってアーキテクチャーを組み立てていく手法が書かれている
- デザインパターン&ベストプラクティスを話しつつ、テストコードのLiveリファクタリングへ
- 作者: Satya Avasarala,Sky株式会社玉川竜司
- 出版社/メーカー: オライリージャパン
- 発売日: 2014/09/18
- メディア: 大型本
- この商品を含むブログ (5件) を見る
「Selenium実践入門」で学ぶテスト自動化の世界
発表者:伊藤望さん (TRIDENT)
Selenium実践入門 ―― 自動化による継続的なブラウザテスト (WEB+DB PRESS plus)
- 作者: 伊藤望,戸田広,沖田邦夫,宮田淳平,長谷川淳,清水直樹,Vishal Banthia
- 出版社/メーカー: 技術評論社
- 発売日: 2016/02/02
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
E2Eテストフレームワークを使用したテスト自動化事例
発表者:太田邦昭さん (ヤフー株式会社)
Azureを使って手軽にブラウザテストをはじめよう
発表者:小島直也さん
- 爽やかにテストエビデンスをごまかしたことによる悪循環を解説
- 頑張ってテスト自動化を進めた
- 自動テストに立ち向かう人がぶち当たるあるある話
- Azure上にWindowsServer立ち上げて、スクリーンショットを撮るように
- テストエビデンスを
Gebに実践入門するために
エビデンス取るのも自動化したい!
発表者:桑原雄一さん (Monocrea)
薄っすい話百八式
発表者:戸田広さん
- githubinaoのお話
- rebuild.fmで@naoyaさんが話してたやつ
- ポート番号にネタが仕込まれている、それも味わい深い
- CIの結果の通知は、「音声」で
- 仕事にもユーモアが大事
まとめ
出版された書籍の読みどころの紹介、実際の開発での活用方法から始まり、テストエビデンスにまつわる苦労と解決、事例に基づいた知見などなど盛りだくさんの勉強会で楽しかったです。特に、「自動テストを始めることは開発プロセスを変えること」という視点は、いろいろ考え始めてしまい発表に集中できないほど刺激を受けました。
発表していただいた方々、会場準備・運営していただいた方々、ありがとうございました。
おまけ
なんと、じゃんけん大会に勝ち残り、出版されたばかりの書籍&ステッカーをいただきました!
技術評論社さん、ありがとうございます!!!
※SeleniumJPステッカーは会場で配っているのをもらってきました
Lightning Componet でページ遷移する〜LightningRouter の提案〜
Lightning Component のページ遷移の問題点
LightningRouter の提案
サンプル実装
利用方法
GitHubリポジトリ
おわりに
SlackにTokyo Salesforce Developer GroupのTeamを作ってみた
毎年のようにサービス名が変わって毎年新鮮な気持ちで Advent Calendar に挑める今年も大盛り上がりの Salesforce App Cloud Advent Calendar 2015 ですが、1日埋まっていない日があるので代打しようとキーボードを叩いています。
とはいえ、Winter'16のアップデートを見てもLightning Componentの機能拡充も少なく諸先輩方の素晴らしい投稿がたくさんあり、なかなかネタが…。
じゃぁ、どうする?
そこで、Slackの登場です。
会社勤めをしているとなかなかFacebookアカウントを取りにくい人もいたりします。そんな方も気軽に参加して雑談できるスペースになればいいなぁ、という空想で自分を励ましながらSalesforce DUG JapanTokyo Salesforce Developer Groupのチームを作ってみました。
salesforcedugjapanはすでに使われていたけど、誰だろう…。
招待してもらわないと参加できないよね?
そんな声もあろうかと、Invite用のWebページも用意しました!
(但し、テストしていません!)
slackin-tokyosalesforcedg.herokuapp.com
URLからも分かるようにHerokuで動いています。なんとHeroku Buttonのおかげで調査から設置まで30分もあればできてしまいました(参照:参考文献)。Heroku、すごいですねぇ。もちろんFreeプランなので無料!
よって、30分すると寝ます!
一回アクセスすると起きてくるはずなので、少し間をとって再度アクセスしてもらえばInvite用のWebページが表示されるはずです。
ところで、何を話すの?
Slackでぶっちゃけ何をやるか決まっておりません。
Facebookページよりは話しやすい場になると思いますので、例えばリリースノートの感想を書き込んで雑談したり、テーマを決めて雑談したり、できればと考えております。
以上、Salesforce App Cloud Advent Calendar 2015 の12月20日分の代打投稿でした。
参考文献
Lightning Event は3度死ぬ
Lightning Event とは
Lightning Event とは、Lightning Component において、コンポーネント間でイベント処理を実行するための仕組みです。Lightning Event では、イベントを定義する、イベントを発火するコンポーネントに定義を記述する、イベントを受け取り処理するコンポーネントに定義を記述する、の3ステップが必要となります。
First Impact
問題点
それは、Lightning Component をまともにコンポーネント分割してコンポーネント間のイベント処理を Lightning Event で行おうとしたときに訪れます。
Lightning Event も Lightning Component などと同様にバンドルという単位で扱います。このバンドルにイベントの定義だけを記述します。問題はこのバンドルがすべて1階層内で管理されるため、まともにコンポーネントを分割し、イベント処理を書いていくとものすごい数のバンドルが作成されることになり、管理不能になっていきます。
対応策
対応策としては、下記の2つが考えられます。
- まとめにコンポーネントを分割しない
- Lightning Component はあくまでも外側とのI/Fの定義に徹して、内部は別ライブラリ(React.jsなど)を利用する
前者はコンポーネント志向を捨てることになるので、後者のほうが優れたやり方ではあります。ただし、モダンJavaScriptのスキルが必要となるので、JavaScriptが得意ではないエンジニアがいきなり採用するには少しハードルがあります。トレンドは、モダンJavaScriptを利用して開発する流れとなっているので、頑張って覚えていってもよいかもしれません。
Second Impact
問題点
それは、別のパッケージにある Lightning Component を Lightning Event で連携しようとしたときに訪れます。
Lightning Event は型付け言語に相応しく、ソースコード中にある場合は定義を参照してバリデーションしており、定義が見つからない場合はソースコードをSalesforce組織にデプロイすることができません。
そのため、他のパッケージ中にあるコンポーネントを参照すると、自動的に基本パッケージと拡張パッケージというような主従の関係となってしまいます。これは、 Lightning Event でも同様に機能しますので、他のパッケージの Lightning Event を呼び出すパッケージを作ろうとすると、呼び出し元のパッケージに依存するようになってしまい、単独ではインストールすることができなくなってしまいます。
対応策
対応策としては、Lightning Event を利用する場合は、直接的なイベントのワイヤリングを諦めるしかありません。それぞれのパッケージでは別々に Lightning Event を発火・受け付ける処理を作成し、2つのパッケージのコンポーネント間のイベントを受け渡すワイヤリング用のコンポーネントを作成することでやりたいことができるようになります。
自動的にイベントをワイヤリングできなくなってしまうところですが、このワイヤリングコンポーネントを2つのパッケージの拡張パッケージとして作成してやることで、コーディングする必要はなくなります。
2つのパッケージにある Lightning Component を Lightning App Builder で配置し、合わせてワイヤリングコンポーネントを配置してやることでイベントの受け渡しを実現できます。
Third Impact
もうすぐ ltng:sendMessage イベントが実装されるようです。
このイベントを利用すると、新しいイベントを定義せずに ltng:sendMessage イベントでメッセージ(JSON形式)をチャンネルを指定してイベント発火し、
ところが…
今Skipが居たのでフラっとltng:sendMessageをコンポーネント間のIFに使うのはアリかと聞いたら、結論からするとあんまりいいアーキテクチャじゃ無いよ、それ用に作って無いし、だそうです。(元々ltng:sendMessageはAppBuilderが使う事を想定)
— Mitsuhiro Okamoto (@mitsuhiro) September 21, 2015
んで、Lightning Eventをパッケージングした時の依存性問題に関しては、例えばイベントを別のイベントへ流す様なマッピングツールを提供するなど、今解決策を検討してるそうな。なのでProductionでComponent間連携やるのはもうちょい待った方が良さげ。
— Mitsuhiro Okamoto (@mitsuhiro) September 21, 2015
おぅ…。
希望の光と思われた ltng:sendMessage も解ではないと…。
問題として認識されて、解決に向けて対応中とのことなので、もう少し様子を見ましょう…。
Enjoy Lightning!