第26回 Tokyo Atlassian ユーザーグループ に行ってきたメモ #augj

行ってきました。

途中参加かつ懇親会は都合がつかず、セッション２つ聞いて帰ってきました。

Confluenence/Jiraパフォーマンスチューニングポイント by 大中浩行

間に合わず。資料が公開されてたので貼っときます。

Confluence/Jira パフォーマンスチューニングポイント from グロースエクスパートナーズ株式会社/Growth xPartners Incorporated.

パフォーマンスと聞いてオンプレ版のことだろうと決めつけてたらやっぱりオンプレ版でした（弊社は Cloud 版）

Confluenceで組織を活性化させたかった話 by 南原 錦善

SES主力の会社でconfluence from Kinzen Nanbara

SES 主力の会社で Confluence Server を使って組織改善にチャレンジしたお話

• 株式会社ヒューマンネットワーク
  • エンジニア 75 名、営業、管理部 20 名
  • SES の常駐業務が主力
• 客先常駐なのでエンジニアはバラバラ
• 定時後帰社、社内活動 -> 社内への働きに対して大きなパワーが必要。効率化することが重要な課題
• 課題
  • 社内の活動の情報共有がしづらい (元desknets)
  • スキル情報を見る機会がない
  • 議事録、社内ルール、広報がワード、エクセル、PDF
  • やってる感が出ない（家で勉強してたとしても評価できないし、アピールの場がない）
• 導入までの3つの壁
  1. 社内の反対
     • 変化に対する抵抗
     • 費用対効果の不明さによる懸念
     • 自腹で導入し、良さをアピール
  2. ユーザ管理
     • AD 連携ができるけどうまくいかない→諦め
  3. 使い方指導
     • ハンズオンの実施
     • コメントで Tips 共有
     • チュートリアルを用意
• 利用状況を Google Analytics で取得
• DBから更新数、いいね数の取得
• 運用のポイントというか意識したポイント
  1. 使用方法に制限をかけない
  2. 毎日みんなの投稿に目を通しリアクションする
  3. フォロワー（サクラ）を作る
• 生きた情報は生きた組織を作る！

印象に残った話

• 費用対効果を説明するの面倒だから 1000円/月・10人分のライセンスを自腹で購入
• Paiza の問題のリンク集を作り、新人に問題を解かせた。また回答も Confluence に書かせた
  • → Java のコードを見るとコメントしたくてたまらない人達が集まってきた
• ポジティブな気持ちになれる偉人の名言を毎日投稿する人が出てきた

といったエピソードがありました。

弊社も Confluence に情報をまとめるのはだいぶ浸透してきたけど、開発というか業務にないことでも自由に発信するというのはできてないなー。

Making Software for the Software Makers "AtlassianはJIRAをどう使っているか" by Jason Wong

Jira Software プリシパルプロダクトマネージャーの Jason さんからの話。
Atlassian のチーム例 5 つを紹介。
Jira を徹底的に使いこなすための実践的 Tips というより、それぞれのチームで Jira をどう使っているかを通じて Atlassian のカルチャーみたいなものを感じることができて面白かったです。

• 世界中どこを探してもまったく同じチームはない。だから Jira Software の使い方もチームによって異なる
• アトラシアンの 5 つのチームの話
• 世界12箇所、20+ Jira インスタンス、337 プロジェクト、468 カスタムワークフロー

1. 時間的に厳しいアジャイル

• Identity CloudX チーム

• Jira に登録しつつ物理カンバン

• 見積り前提 -> NO!

  • 見積りより調査　早めにスパイクし始めよう！
  • QA 発表会
    • スプリントが終わったときにどんなソフトになっていてほしいか、スプリントの前に実施
• 改善をし続ける社内文化を支えるために新しい習慣を作ります
  • アジャイルスラム（大勢の人の前に立って経験したことを話す）
    • 詩人会の由来から
  • ウォールボード
  • 仕事と楽しみのバランス

2. 大量の experiment を行うシステム

• Atlassian 製品の実験的な取り組みを行うチーム？
• 会社から大量のIdeaがくる。さばききれない
• 自動化
  • optimizely, jira software, confluence をつなげるマイクロサービスMars
• 情報を一つの場所にまとめるサービスやプロセスを作るのはとても大切
  • Jira + Confluence
    • Jira を仕事のステータスより、仕事の文脈や背景や結果を詳しく共有できる

3. 端から端まで、開発の見通し

• Jira Software チーム（Jason さんが所属してるチーム）
• デザイン・開発・マーケ・プロダクトなどさまざまなチームごとにプロジェクト
  • 使い方もさまざま
• PM は様々な仕事をトラッキングするため Confluence のページでテーブル作った -> 情報がすぐ古くなる
• -> クロスプロジェクトボードを作る！
• 「ボードを歩く」Boardwalk
  • コミュニケーションの習慣
  • ストーリーテリング

4.

• SRE チーム
• IMA というマイクロサービス作った
  • HOT チケットができると Hipchat にルームができる
  • Bluejeans も
  • StatusPage: https://ja.atlassian.com/software/statuspage
  • 各サービスへのリンクを Jira の課題に集約（自動的に記載される）

5. 開発情報のボード

• Fusion Team (Jira Software と開発ツールの連携を作る)
• ブランチの進行と Jira のステータスを重ね合わせると状況がよくわかる
• development[pullrequests].all > 0
• カードの色と組み合わせて視覚的に

印象に残った話

1 つめのチームに関しては、物理カンバンを使っていて、タスクのふせんをなぜか一本の道のようにつなげてボードにしていたチームの話。
道は途中で枝分かれしたり合流したりで、要所要所になぜかポケモンが。
またポケモンボール型のマグネットも用意されていて、タスク消化していってポケモンのところまで到達したらポケモンボール使ってポケモン GET！
→ちょっとした達成感のお祝いでみんなでコーヒー飲んだりする
みたいな話をされてました。

また 2, 4 のチームにあるように、Atlassian では製品間をマイクロサービスでつなげて自動化を進めてるらしい。
StatusPage なんてサービスもやってたのか。

5 については、 JQL の development[xxx] というプロパティすら知らなかったんですが、やってみるとたしかにできました。
Bitbucket などと連携した状態で

development[pullrequests].open > 0

などとすると、「ひもづく PR でオープン状態のものがあるチケット」のような条件指定ができます。

お話では、キャプチャのようにかんばんのカードの色の条件にこれを使っていて、Jira のステータスとソースコードの状況に乖離がないかを可視化してるとのことでした。

また、3 のチームの話に出てくる Boardwalk ってのがどういった目的で、どれくらいの頻度でやるのかいまいち理解できてなかったんですが
懇親会の冒頭にお話を伺うことができました。

• 毎回のスプリント期間中に定期的に実施する。スプリントの真ん中あたりに設定してる
  • 前半はプランニング、後半はふりかえりがあるし
• バックロググルーミングと似てるんだけど、「バックロググルーミングのような細かい話まではしないかな」とのこと
• そのストーリーを「なぜやるか」というところを、デザイン・開発・マーケみんな集まったところで共有する
  • やる目的を共有し、全員が共感した状態で作らないとモチベーション上がらない

だいたいこんなような回答だったかと。
ググると Jason さんの記事が出てきますね。

また Jason さんからは他にも

• かんばんはデジタル（Jira）で管理してるところもアナログ（物理）で管理してるところも、あるいは併用してるところもある。傾向として若者が多いところだと物理かんばんが多い
• Face to Face のコミュニケーションってやっぱり大事。Jira や Confluence 上でもメンションつけてやり取りはたしかにできるけど。メンションつきで長文で重要な情報が頻繁にやり取りするようだと顔を突き合わせての対話が足りてないという兆しなんじゃないか

といった面白い話が聞けました。

総じて、対話によるコミュニケーションや、計画通りやるだけじゃなく仕事に楽しさを持たせるっていうのを大事にしてるんだなと感じました。

babel-preset-envの使い方（babel-preset-es2015からの移行）

はじめに

ES2015 の変換に babel-preset-es2015 を使っているプロジェクトで、npm install 時に

npm WARN deprecated babel-preset-es2015@6.24.1: 🙌  Thanks for using Babel: we recommend using babel-preset-env now: please read babeljs.io/env to update!

という警告が出ており、あーたしかに babel-preset-env を使った方がいいってどこかで聞いたなと思いつつ env の設定のしかたを調べられていなかったんですが、ようやく少し調べました。
そのときのメモ。

公式の

に加え、Qiita のこちらの記事も参考になりました。

注）この記事を書いた 2018/1/18 時点で Babel のバージョン 7 はベータ版だったので、6 系での設定です。
バージョン 7 での変更点は最後に書いてます。

最初にまとめ

• babel-preset-es2015 から babel-preset-env にただ切り換えるだけであれば、babel-preset-xxx 部分を置き換えるだけで済む
• babel-preset-env は何もオプションを指定しなければ、全部 ES5 の記法にトランスパイルする
• が、モダンなブラウザでは Class など ES2015+ の構文に対応しているので、サポート対象ブラウザに応じて必要なところまでトランスパイルするのが望ましい
• babel-preset-env では targets オプションで対象ブラウザを指定することが可能

// .babelrc（例）
{
  "presets": [
    ["env", {
      "targets": {
        "browsers": ["last 2 versions", "safari >= 7"]
      }
    }]
  ]
}

（2018/5/11追記）

上記の例の last 2 versions はあまりよくないらしい。という記事を読んだ。

last 2 versions - @jamiebuilds

（追記ここまで）

設定方法

babel-preset-env をインストール

babel-preset-es2015 をアンインストールして、かわりに babel-preset-env を入れます。

$ yarn remove babel-preset-es2015
$ yarn add -D babel-preset-env

.babelrc を修正

まずは単純に es2015 を env に置き換えます。

 {
-  "presets": ["react", ["es2015", { "modules": false }]],
+  "presets": ["react", ["env", { "modules": false }]],
   "plugins": [
     "transform-class-properties",
     "transform-object-rest-spread",
    "react-hot-loader/babel"
  ]
}

webpack で Tree Shaking をするための modules: false というオプションもそのままで大丈夫のようです。
（https://babeljs.io/docs/plugins/preset-env/#modules）

オプションで対象ブラウザを指定する

https://babeljs.io/docs/plugins/preset-env/#targets
targets というオプションで対象のブラウザを指定できます。
対象のブラウザを指定すると、そのブラウザで対応している構文についてはそのままでトランスパイルせず、未対応の構文のみトランスパイルするという挙動になるようです。

内部的には compat-table のデータを参照しているらしい。

targets の指定方法にはいくつか種類があって、

1) 対象ブラウザとバージョンを決め打ち

{
  "targets": {
    "chrome": 52
  }
}

2) targets.browsers を指定し、クエリを書く（内部的には browserslist を使っている）

"targets": {
  "browsers": ["last 2 versions", "safari 7"]
}

もしくはこれらを複数指定することができます。あとは node オプションで対象の Node のバージョンが指定できたり。
なお

Note, browsers’ results are overridden by explicit items from targets.

とあるので、 browsers の内容は個別に指定したものがあった場合上書きされます。

最終的にこうなった

というわけで、私は一旦こうしました。

// before
{
  "presets": ["react", ["es2015", { "modules": false }]],
  "plugins": [
    "transform-class-properties",
    "transform-object-rest-spread",
    "react-hot-loader/babel"
  ]
}

// after
{
  "presets": [
    "react",
    ["env", {
      "targets": {
        "browsers": ["last 2 versions"]
      },
      "modules": false
      }
    ]
  ],
  "plugins": [
    "transform-class-properties",
    "transform-object-rest-spread",
    "react-hot-loader/babel"
  ]
}

個人の適当なリポジトリで試しただけなので、対象ブラウザとかは深く考えてないです。

参考：

PR はこれ

Babel 7 での変更点

Babel 7 から babel-preset-env も Babel 本体のリポジトリに移動になったので、パッケージ名が @babel/preset-env に変わります。

参考：https://github.com/babel/babel/tree/master/packages/babel-preset-env

$ npm install @babel/preset-env --save-dev

targets の指定方法は変わってないぽいです。

IDDD本もくもく読書会メモ#5（第10章 集約）

メモが滞ってる。。。第10章「集約」のメモを。

過去メモ

• IDDD本もくもく読書会をやってみたメモ#1
• IDDD本もくもく読書会メモ#2（第3章 コンテキストマップ）
• IDDD本もくもく読書会メモ#3（第4章 アーキテクチャ）
• IDDD本もくもく読書会メモ#4（第6章 値オブジェクト）

教材

実践ドメイン駆動設計 (Object Oriented SELECTION)

CodeZine の記事 も第9章から更新が止まってしまっていてつらい。

メモ

10.2 ルール：真の不変条件を、整合性の境界内にモデリングする

• 不変条件：常に整合性を保っている必要のあるビジネスルールのこと
• 不変条件について議論する際の整合性は、トランザクション整合性のことを指す
• 集約はトランザクション整合性の境界

整合性の境界の論理的な意味は、「その内部にあるあらゆるものは、どんな操作をするにかかわらず、特定の不変条件のルールに従う」ということだ。

• 境界づけられたコンテキストを適切に設計すれば、どんな場合でも、ひとつのトランザクション内で変更する集約をひとつだけに絞り込める
  • -> ひとつのトランザクションではひとつの集約のインスタンスしか変更できないという制約

10.3 ルール：小さな集約を設計する

• モデルの一部分をエンティティとしてモデリングしたくなったらどうするか
  • その部分自体が今後も変わり続けるものなのか、あるいは変更したくなったときに丸ごと置き換えれば済むのか考える
  • 丸ごと置き換えられるならエンティティではなく値オブジェクト
• ユースケースを鵜呑みにするな
  • １つのトランザクションで複数の集約のインスタンスの整合性を保たないといけないようなときは本当にそうなのか疑ってかかる

10.4 ルール：他の集約への参照には、その識別子を利用する

• 集約の合成構造？
• 集約から別の集約（へのルート）への参照を持つのはOK
• １つのトランザクションで参照する側とされる側の両方を更新してはならない
• 集約そのものへのポインタではなく、一意な識別子へのポインタを保持する
  • Product ではなく ProductId （値オブジェクト）を持つ

10.5 ルール：境界の外部では結果整合性を用いる

• ひとつの集約上でコマンドを実行するときに、他の集約のコマンドも実行するようなビジネスルールが求められるのなら、その場合は結果整合性を使う
• 一方のインスタンスが変更されてから、もう一方のインスタンスが変更されるまでの遅延が、どの程度許容されるかをドメインエキスパートにたずねてみよう
• 現実的な手段としては、トランザクションの最後にドメインイベントを発行する
• 誰の役割かを考える
  • トランザクション整合性か結果整合性で迷ったときの話
  • ユースケースについて考えるときは、データの整合性を保つのが誰の役割なのかに注目する
    • ユースケースを実行するユーザー自身：トランザクション整合性
    • 別のユーザー（あるいはシステム）：結果整合性

10.6 ルールに違反する理由

• 複数の集約のインスタンスに対する変更を、あえて単一のトランザクションにまとめる場合の理由
  1. UI の利便性：一括処理など
  2. 技術的な仕組みの欠如：結果整合性が技術的にできない
  3. グローバルなトランザクション：二相コミット方式のトランザクションを強いられる場合もある
  4. クエリのパフォーマンス

10.7 発見による知見の獲得

• 例：バックログアイテム：タスク = 1 : n の関係にある
• 一般的な利用シナリオを頭に浮かべながら試算する、という話が書かれている
• バックログアイテムの状態とタスクの残作業の総計は結果整合性にすべきか？
  • -> タスクの数がどれだけあっても、バックログアイテムの状態が変わるのは、常に最後の見積もりになる
    • バックログアイテムの状態が変わらない限り version が変わらないので、結果整合性でなくロックしても問題ない
• メモリの消費

10.8 実装

• 集約のパーツは可能な限り、エンティティではなく値オブジェクトにする

public class Product extends ConcurrencySafeEntity {
    private Set<ProductBacklogItem> backlogItems;
    private String description;
    private String name;
    private ProductDiscussion ProductDiscussion; // VO
    private ProductId productId; // VO
    private TenantId tenantId; // VO
}

• デメテルの法則（最小知識の原則）：任意のオブジェクトが自分以外（サブコンポーネント含む）の構造やプロパティに対して持っている仮定を最小限にすべきである
• 命じろ、たずねるな（Tell, Don't Ask）：
  • 参考：Tell, Don't Ask [ 求めるな、命じよ ] - はむはむエンジニアぶろぐ
• 集約に依存性の注入は避けた方がいい？

Q

• 誰の役割かを考えてトランザクション整合性か結果整合性かを決める、というのは絶対なの？
  • -> あくまで指針の１つと捉えておくのが良い

資料

• IDDD本から理解するドメイン駆動設計連載一覧：CodeZine（コードジン）
• スライド
  • ドメイン駆動設計 基本を理解する
  • 「実践ドメイン駆動設計」社内読書会まとめ ～IDDD本難民に捧げる1章から7章～
• サンプルコード
  • DDD の Java EE 実装サンプル - Cargo Tracker を読み解く - Qiita
  • (GitHub)VaughnVernon/IDDD_Samples
• フロントエンド寄りの話
  • FrontEnd:DDD // Speaker Deck
  • Reduxにドメイン層を導入する - Qiita
• DDD、CQRS(+ES)まわりの実装、参考ページまとめ ｜ Developers.IO
• DDDで設計するならCQRSの利用を検討すべき - Qiita
• [New] Patterns for designing flexible architecture in node.js (CQRS/ES/Onion)

Nodeのバージョン管理をndenvにしたけどうまくバージョンが切り替わらなかったときのメモ

メモ。
これまでは Homebrew でインストールした Node を使っていたが、バージョンを上げたくて複数バージョン管理できるツールを取り入れることにした。
Node のバージョン管理ツールはちょっと調べた限り

• nodebrew
• n
• ndenv

あたりがあったが、元々 Python のバージョン管理に pyenv を使っていた過去もあり同じような使い勝手の ndenv にした。
またこの機会に anyenv もインストールし、ndenv は anyenv 経由でインストールすることにした。

n も一瞬触ってみたが、「プロジェクトごとに Node のバージョンを固定してバージョンを自動的に切り替える」をやる方法がわからず ndenv に乗り換えた。

インストール手順

こちらの記事が詳しい。

anyenv と ndenv のインストール

$ git clone https://github.com/riywo/anyenv ~/.anyenv

で anyenv をインストールした後、 .zshrc に

export PATH="$HOME/.anyenv/bin:$PATH"
eval "$(anyenv init -)"

を追記しておく。今回のみシェルを再起動するため

$ exec $SHELL -l

を実行する。

最後に ndenv をインストールする。

$ anyenv install ndenv
$ exec $SHELL -l

ndenv で特定バージョンの Node をインストール

$ ndenv install -l
Available versions:
  v0.1.14
  v0.1.15
  v0.1.16
  ...

でインストールしたいバージョンを探し

$ ndenv install v8.9.3

のようにバージョンを指定してインストールする。

$ ndenv global v8.9.3
$ ndenv rehash
$ ndenv versions
  system
* v8.9.3 (set by /Users/yamazaki/.anyenv/envs/ndenv/version)

トラブルシューティング

$ ndenv versions
  system
* v8.9.3 (set by /Users/yamazaki/.anyenv/envs/ndenv/version)
$ node -v
v6.9.4

切り替わってない...？
（v6.9.4 は以前 Homebrew 経由でインストールしたバージョン）

$ which node
/usr/local/bin/node

Homebrew でインストールした Node が優先されているようだ。
似たような問題に遭遇している人がいた。

Homebrew をアップデートしたら ndenv の node が使えなくなった | WEBMAN

回避策として、記事に記載されている通り、Homebrew の Node をアンインストールした。

$ brew uninstall --ignore-dependencies node
$ exec $SHELL -l
$ which node
/Users/yamazaki/.anyenv/envs/ndenv/shims/node
$ ndenv versions
* v8.9.3 (set by /Users/yamazaki/.anyenv/envs/ndenv/version)

which node のパスが変わっているので無事にアンインストールできたっぽい。
また ndenv versions したときに system が表示されなくなった。

npm にまだ問題があった

$ which npm
/usr/local/bin/npm

npm コマンドが残っていた...

• homebrewでインストールしたnode.jsをアンインストールする | ひびテク
• javascript - How do I completely uninstall Node.js, and reinstall from beginning (Mac OS X) - Stack Overflow

あたりを参考に

$ npm uninstall -g npm
$ rm -rf /usr/local/lib/node_modules
$ brew prune

を実行してきれいになった。本来は Node より先に npm をアンインストールすべきだったらしい。

$ which npm
/Users/yamazaki/.anyenv/envs/ndenv/shims/npm

npm のパスが変わったのでこれでおそらく大丈夫。

# v6.9.4 は ndenv install 済みとして
$ ndenv local v6.9.4
$ node -v
v6.9.5
$ npm -v
3.10.10

$ ndenv local v8.9.3
v8.9.3
$ npm -v
5.5.1

[Salesforce]Packaging 2.0（第二世代パッケージ）を試してみた

この記事は Salesforce Platform Advent Calendar 2017 の 3 日目の記事です。

はじめに

アドベントカレンダーなので「私の Salesforce 情報収集術！（2017 年冬）」とかでお茶を濁そうと考えていたんですが
Winter'18 で Packaging 2.0 がベータ版となり、機能自体は誰でも試せるようになりました（リリースノート）。
というわけでやってみたレポです。

なお、最近 Salesforce DX 開発者ガイド が日本語版も公開されたため そこに書かれていることを一通りなぞっただけの記事になってしまいました。

開発者ガイドによると「第二世代パッケージ」と表現してるので、この記事でも以降そう呼びます。

事前準備

事前に必要な各種設定を行っていきます。

開発者ガイドで言うとここです。
組織の設定の確認 | Salesforce DX 開発者ガイド | Salesforce Developers

Salesforce DX CLI のインストール、Dev Hub 組織のサインアップ

第二世代パッケージは DX による開発を前提としています。
そのため、 sfdx コマンドおよび Dev Hub 組織を利用可能にしておく必要があります。

このあたりは Trailhead の App Development with Salesforce DX というモジュールに手順が書いてありますので割愛します。 または、先日そのハンズオン勉強会をやったときの日本語の資料が ここ にあるのでそちらを参照ください。

Dev Hub 組織で第二世代パッケージを有効化する

第二世代パッケージはベータ版機能のため、組織の設定で有効化する必要があります。 開発 > Dev Hub を開きます。

Dev Hub 組織の「私のドメイン」を有効化する

Dev Hub 組織の「私のドメイン」が有効でないと、この後の名前空間のリンクができないので有効にします。
30 日間のトライアル組織でも「私のドメイン」は有効になってないので忘れずにやります。

名前空間登録用の DE 組織をサインアップ

パッケージの名前空間を登録するために、なぜか専用の Developer Edition 組織が必要になります。 https://developer.salesforce.com/signup からサインアップします。

組織にログイン後、アプリケーション > パッケージマネージャ から登録できます。

ちなみに、名前空間の登録も Dev Hub 組織使えばいいじゃんって思ったんですができないようです。

Dev Hub 組織で名前空間組織をリンクする

先ほど作成した名前空間組織を Dev Hub 組織にリンクします。
再度 Dev Hub 組織を開き、「Namespace Registry」タブを開きます。

「名前空間をリンク」ボタンを押すとポップアップが開くので、そこで名前空間組織にログインしアプリケーションを許可します。
（このボタン、「私のドメイン」が無効だと表示されません）

開発

準備が整ったので、プロジェクトを作ってパッケージ作成を試してみます。

DX 用新規プロジェクトを作成

CLI でプロジェクトのひな形を作ります。

$ sfdx force:project:create -n my-first-package-2

my-first-package-2
├── README.md
├── config
│   └── project-scratch-def.json
├── force-app
│   └── main
│       └── default
│           └── aura
└── sfdx-project.json

sfdx-project.json に名前空間を設定する

 {
   "packageDirectories": [
     {
       "path": "force-app",
       "default": true
     }
   ],
-  "namespace": "",
+  "namespace": "zakiyama_test",
   "sfdcLoginUrl": "https://login.salesforce.com",
   "sourceApiVersion": "41.0"
 }

Scratch Org で開発する

第二世代パッケージの作成とは直接関係ありませんが、通常はこの後 Scratch Org を作成して開発を行っていくことになります。

なお、Scratch Org を作成する際に名前空間が正しくリンクされていないと下記のエラーがでます。

$ sfdx force:org:create -f config/project-scratch-def.json -a ScratchOrg -s
ERROR:  名前空間属性 foo に無効な値が指定されました。単純な Javascript 名にしてください。.

パッケージを作成する

開発が完了したという想定で、いよいよパッケージを作成します。
開発者ガイドではこのあたりです。
パッケージの作成 | Salesforce DX 開発者ガイド | Salesforce Developers

$ sfdx force:package2:create --name new_package --description "New Package" --containeroptions Unlocked
Successfully created a second-generation package (package2). 0Ho7F0000008OIASA2 0337F000000HWJrQAO
=== Ids
NAME                   VALUE
─────────────────────  ──────────────────
Package2 Id            0Ho7F0000008OIASA2
Subscriber Package Id  0337F000000HWJrQAO

成功すると Package2 Id と Subscriber Package Id という 2 つの ID 情報が表示されます。
Package2 Id はこの後すぐ使います。後者はなんだろう...

sfdx-project.json の packageDirectories にパッケージ ID などを追加する

ここが一番のハマりポイントでした。
sfdx-project.json ファイルでのパッケージの設定 | Salesforce DX 開発者ガイド | Salesforce Developers
によると

各パッケージの Salesforce DX プロジェクト設定ファイルにエントリを追加し、そのバージョンの詳細、連動関係、および組織設定を指定します。

各パッケージ説明には次の属性が含まれます。

{
    "path": "logic",
    "id": "0HoB00000004CFuKAM",
    "versionName": "v 1.2",
    "versionDescription": "ver 1.2 - anc = 1.1",
    "versionNumber": "1.2.0.NEXT",
    "ancestorId": "05iB00000004CIeIAM",
    "dependencies": [
        {
            "packageId": "0HoB00000004CFpKAM",
            "versionNumber": "1.2.0.LATEST"
        },
        {
            "packageId": "0HoB00000004CFkKAM",
            "versionNumber": "1.2.0.LATEST"
        }
    ],            
    "features": "MultiCurrency",
    "orgPreferences": {
        "enabled": [
            "S1DesktopEnabled",
            "Translation"
        ],
        "disabled": []
    }
}

とありますが、これ実際には sfdx-project.json の packageDirectories プロパティの中に記述する必要がある みたいです。
（Dreamhouse アプリのリポジトリ 見てなんとかわかった...！）

 {
   "packageDirectories": [
     {
       "path": "force-app",
+      "id": "0Ho7F0000008OIASA2",
+      "versionNumber": "1.0.0.NEXT",
       "default": true
     }
   ],
   "namespace": "zakiyama_test",
   "sfdcLoginUrl": "https://login.salesforce.com",
   "sourceApiVersion": "41.0"
 }

この 2 つ以外にもバージョンや依存関係まわりのプロパティが多数あるようなんですが、今の時点では詳細はわかってません。

パッケージバージョンを作成する

作成したパッケージに対し、今度はバージョンを作成します。
パッケージを作成したときの Package2 Id を使って

$ sfdx force:package2:version:create -i 0Ho7F0000008OIASA2

とします。

成功すると

Package2 version creation request is InProgress. Run "sfdx force:package2:version:create:get -i 08c7F0000008OIKQA2" to query for status.

といったメッセージが表示されます。

（余談）

バージョン作成の部分、開発者ガイドでは

次のコマンドでパッケージバージョンを作成します。ディレクトリ名またはパッケージ ID を指定します。

と記載があり、 -d による対象ディレクトリ指定か -i による対象パッケージ Id 指定のいずれかでいけるようです。

が、どちらの場合も sfdx-project.json に id を指定しなくて良いわけではなく、以下のエラーが出ました。

ERROR:  The --package2id (-i) value [0Ho7F0000008OIASA2], doesn’t match the id value in any packageDirectories specified in sfdx-project.json.

正しい設定方法は未だによくわかっていません。。。

バージョン作成の進行状況を確認する

GUI から作成したときと同じく、パッケージバージョンの作成は少し時間がかかるようです。
作成コマンド実行時に表示された以下のコマンドで、状況を確認することができます。

$ sfdx force:package2:version:create:get -i 08c7F0000008OIKQA2
=== Package2 Version Create Request
NAME                            VALUE
──────────────────────────────  ──────────────────
ID                              08c7F0000008OIFQA2
Status                          InProgress
Package2 Id                     0Ho7F0000008OIASA2
Package2 Version Id
Subscriber Package2 Version Id
Tag
Branch
Created Date                    2017-12-04 03:59

結果

ｳｯ😇

今日はここまで。。。

おわりに：まだまだわからないことだらけ

というわけで、何とも消化不良な結果に終わってしまいました。。。
まあエラー自体はもう少し時間をかければなんとかなるんでしょうが。

今回やってみただけでは、以下のような点がいろいろとわかっておりません。

• バージョン作成時の正しい Package2 Id の指定のしかた
  • sfdx-project.json に埋め込んじゃうのが適切なの？
• バージョン指定用の各種プロパティ
  • https://developer.salesforce.com/docs/atlas.ja-jp.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_config.htm
  • どう書いておくのが正解？
• パッケージ作成時の --containeroptions の違い
  • https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_force_package2.htm?search_text=containeroptions#cli_reference_create
  • ↑によると Managed （デフォルト）、Unlocked、Locked らしい
• 各種 ID
  • https://developer.salesforce.com/docs/atlas.ja-jp.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_plan_pkg_types_pkg_ids.htm
  • パッケージ作成時に表示された Subscriber Package Id 以外に、要求 ID なども
  • 用語を整理したい

Salesforce DXのコマンドをzshで補完する

メモ。
Salesforce DX の CLI はコマンドが長いのでシェルで補完してくれる関数ないかなーと思っていたら公式ではないけどあった。

Salesforce DX aliases and shell completions for working with sfdx in zsh and vim · GitHub

これの sfdx_completion.zsh というファイルがそう。

（2018/9/13追記）

中の人が公開しているものもあった。

オプションの補完など、こちらの方が優秀そう。
インストール方法は README の通り。

（追記ここまで）

インストール手順

普通の zsh 補完関数と同じように設定すれば OK だが、やり方を知らなかったので備忘録として。
ここを読むといい。
https://github.com/zsh-users/zsh-completions/blob/master/zsh-completions-howto.org

まず、補完関数を格納するディレクトリを作成し、 fpath という変数に追加する。（ .zshrc に記載する）

$ mkdir -p ~/.zsh/completion

# ~/.zshrc
fpath=(~/.zsh/completion $fpath)

続いて、補完関数を用意する。
補間関数ファイルは、

• 1 行目に補完対象となるコマンドを #compdef sfdx という形式で記載する
• ファイル名は _sfdx のように、 _[補完対象のコマンド] にする

というルールがあるらしいが、今回は gist の sfdx_completion.zsh の内容をコピーし、_sfdx というファイル名でディレクトリに格納すればいい。

保存したら

$ source ~/.zshrc

で補完が効くようになる。

結果

まだ本格的に試してないけどよさげ。

懸念

Salesforce が公式で提供しているものでもないし（Author も中の人ではなさそう）、どうやってこの補間関数を生成したのかわからないので
今後の CLI のバージョンアップに追従してくれるかどうかは謎。

[Salesforce]フロー（Visual Workflow）でルックアップ項目を実現する

メモ。
SWTT 2017 のミニハック で個人的に宿題になってたやつです。

課題はこれ。

どういった問題があったか

課題では「候補者（Contestant）」と「投票（Vote）」という2つのオブジェクトを用意し、主従関係でひもづけた後
子にあたる「投票」オブジェクトのレコード作成画面をフローで実装した。

ここで、レコード作成には親となる「候補者」のIDが必要だが
フローの入力項目には標準画面のようなルックアップ項目が用意されておらず
ミニハックのときは「Lightning ページに埋め込み、レコード ID を直接渡す」方式で回避することにした。
参考：Salesforce World Tour Tokyo 2017 ミニハック解答速報

ただ、これはおそらく正攻法ではないので一般的なやり方を知りたいなあ、と思った次第。

フローで主従関係や参照関係のようなルックアップ項目を実現する方法

フローの「レコードの検索」機能を使えば実現できそう。
公式ドキュメントだとここかな。

Flow Record Lookup Element | Visual Workflow Guide | Salesforce Developers

以下、設定手順。
はじめにフローの全体図を載せる。

上から順に以下のような処理を行っている。

1. ユーザに、ルックアップの検索条件となる値を入力させる
2. ユーザからの入力値を条件として、「レコードの検索」を実行する。検索結果を ID だけ変数に格納する
3. ID を格納した変数を使い、「レコードの作成」を実行する

ステップ 1

以下のような画面入力としている。

ここで重要なのは必須項目に指定した「候補者名」の値で、ここでは ContestantName という変数に格納している。

ステップ 2「レコードの検索」

検索対象のオブジェクトを指定した後、「次の条件と一致します。」の下で具体的な検索条件を指定する。

今回は「候補者」オブジェクトの Name 項目に対して部分一致で検索したかったのでキャプチャのような設定になった。
（演算子は「次の文字列を含む」）
値には先ほどのステップで格納した ContestantName を指定する。

Name 以外を検索条件としたければここの条件を自由にカスタマイズすれば良い。

また、「レコードの項目を変数に割り当ててフローで参照します。」のところでは
検索結果のうち、レコードの作成に必要なのは ID 項目なのでそれだけ別の変数（ここでは Contestant）に割り当てている。

ステップ 3「レコードの作成」

ステップ 2 で変数に格納した ID を、子レコードの主従関係／参照関係項目（ここでは Contestant__c）にマッピングしている。

これで親レコードの参照が必要なレコード作成であっても実現できたことになる。

問題点

親レコードを検索する、という要件は満たせたが、標準画面のように「入力値に対する検索結果を自分の目で確認して、正しいレコードを選ぶ」といったことはできていないため
ユーザビリティという観点ではやや標準の項目に劣る。特に複数件ヒットしたとき。

また、レコードが見つからなかった場合の考慮がされていないので
主従関係項目の場合はハンドリングされていないエラーが発生するし、参照関係項目の場合は親にひもづかないレコードが作成されてしまっている、といったことが起きそう。

これを回避するためには、ステップ2 で「レコードが検出されない場合、Null 値を変数に割り当てます。」にチェックを入れ
ステップ2 と 3 の間に条件分岐ロジックなどをはさみ、Null だったら画面にエラー表示して終了、みたいなことを自分で構築しておく必要があると思われ。

なお「レコードが検出されない場合〜」オプションについては、ドキュメントによると

By default, the variable’s values are left unchanged.

ということなので変数が未使用ならチェックは必ずしも必要ではないかも。

余談

というところまで調べた後で、海外のデベロッパーがずいぶん前に同じトピックでブログ書いてたことに気づいた。

どうもこれによると、「レコードの検索」のかわりに「動的レコード選択肢」を使っており、
これを使うとラジオボタンや選択リストで検索結果を表示し、ユーザに選択させることができるので
こちらの方がより良い解決方法だと思う。