【いきなりStudio５】メッセージをログでガチろう～ガチラー（Studioで遊ぶ人）は、ロボットとの対話に、メッセージボックスなんざ使わない。型無しと型破りは違う( ´∀｀ )
連投スマぬ💦（だったら毎週書いとけって話( ´∀｀ )）。さてと、前回
で、
UiPath Studioのクラシックへの切り替えと起動
まで出来たところで～今回は～～～
実際に、
UiPath Studio Community版でも、期待どおりに動くのか
の確認も兼ねて、
メッセージをログでガチってく
ここでポイント①：StudioXで動いてたからって、Studioでも実際に動くって思い込んでないか👀❓
そ、大前提過ぎるんだけど、これまでの記事を読んでもらえれば分かるんだが、
オイラまだ最近のStudio環境で一回も、プロジェクト実行してないからね。
☞StudioXでは動いてたからって、同じPCで、Studioでも動くなんて誰が決めたの？＝実際に実行してみないと分からないでしょ( ´∀｀ )
理論だけで考えて、頭でっかちに動かしもせずに動くって思い込むのは簡単なんだけど、
実際動かしてみたら、
動かなかった
動いたが、想定通りの動きになってなかった
なんてことは山ほどあるし、そんな大前提のやればすぐに出来る確認をせずに、いきなり、Studioでも動く想定で、
予算とかプロジェクト開発のスケジュールをタイトに組む
☞いざ、キックオフしてみたら動かないことが判明し、、、
なんてアホなことになってるプロジェクトをいくつも知ってる( ´∀｀ )だから、以前の記事でも
頭でコードを書くな、ソースを組むな
どんな当たり前と思うことも、思い込まずに実際に動かして確認する
☞検証の重要性
をゆーてきてるからね。なぜなら、
あたりでもたしか出てきてるんだけど、世の中の
バグ（とか障害）の79～84％
が、
組織やエンジニアの単なる思い込みか連携不足
だから。
日本人が大好きな統計とランキングで30年前の本でも実証されてる
のに、未だに素直にそれを理解しようとしないばかりに
今日もどこかでバグや障害を生み出してるからねえ( ´∀｀ )
☞プロジェクト開発で一番大事なのは、
コードの修正
ではなく、そのバグを生み出した人や組織の
やり方、考え方＝プロジェクト管理方法の修正
なんだけどね( ´∀｀ )
StudioXで遊ぼう系の記事ロボットとの対話については、
なんかで、
メッセージボックスかWriteLine
でやるって書いたけど、あれは、
開発者に✓を入れない＝StudioX純正の機能
しか使わない前提の話だったから( ´∀｀ )
あんなもんStudioでわざわざ使って確認後、
メッセージボックスを消し忘れて、
Orchestrator（以下、OC）にパブリッシュ
しようもんなら、
ロボットがそこで停止して、
DXによる完全自動化の意味がないからね( ´∀｀ )
バグや障害を誘発しかねない
しかも、わざわざStudioXで開発者に✓を入れて、
Studioの機能を部分的に組み込むくらいなら、
なんかでも書いたとおり、
StudioX自体がなし崩し的に機能を追加していって、
中途半端な開発環境になってる
ので、
変な癖が付く前に、最初から、
【いきなりStudio】
でやった方がいい( ´∀｀ )
からね。さてと、んだば今回も早速、本題に～～～
メッセージをログアクティビティ
で書いてるとおりなんで、ここでは余計なことは書かずに知識としてはこれを読んでもらうとして、
早速、操作
"ロボットの処理開始"
名前を変更を選んで～～～
ここでポイント②：名前にアクティビティ名まで普通は入れない
これは各現場の作法によりけりではあるんだけど、現場によっては、
何のアクティビティを使っているか
を分かるようにする
みたいなことをやってるところもあるんだけど、、、
【入れない理由】
わざわざこれに、アクティビティ名を頭に入れると、
そもそも何故、アクティビティ名を変更するのか
理由は簡単で、
そのアクティビティが何をしてるのか
ロボットを実行しなくても、
見れば分かるようにするため
アクティビティ名なんざそもそも、
右上のプロパティの一番最初に必ず表示される
☞そこで確認すればいい
わざわざそこを見れば分かるプロパティ名を書くのと、
処理を明記してみれば分かるようにするのは、
どっちが大事
って話。
そ、つまり何の処理をしてるかだけを
はっきり明確にしかも短文で書く
（説明書じゃないんだから、敬語すら要らない）
ここでポイント③：注釈でやればいいじゃん
て人も居るとは思うけど、
わざわざクリックしないといけないからね
一目瞭然でしょ👀💦
ここでポイント④：じゃあ注釈は何に使うの👀❓
注釈は、開発履歴を残すために使う
いつ、誰が、何をしたか
が、
第三者が見たときにぱっと見分かるでしょ。
UiPath のロボットもそうなんだけど、プロジェクトファイルってゆーくらいなので、、、
自分ひとりしか未来永劫そのソースは触らない
から、
こんな作法は不要
って短絡的に思う人も居るかもしれないけど、
例えば、本当に自分しか触らないとしても、すっげ～～長くなったソースを組んでいて、
数か月とか数年後に、
何でこんなソースを組んだか
どこに何のソースがその処理をしてるのか
を全部常に覚えておけるかなんて自信のある人は何人いるかだし、これもよく誤ったプロだの職人像を抱いてる自称さんがどこの現場でもいるんだけど、どんな仕事でも
「３日後の自分は他人」
って格言があるくらい、
覚えておかなくてもいいモノは覚えないに越したことはないし、
忘れてもいいように、最初から分かるようにしておく
☞そのソースに初めて触れる第三者が見ても分かるようにしておけば、数年後の自分の首を絞めなくて済むからね。
やれば出来る簡単なことを面倒くさがって、
わざわざ自分で自分の仕事を難しくしてる人を職人とは言わない
ここでもう一回ポイントをまとめると、
ここまでのポイントまとめ
アクティビティ名：そのアクティビティで何をしてるかを短文で書く
注釈：いつ、誰が、何で追加したかだけを短文で書く
だけで、
めっちゃシンプルイズビューティフル
でしょ👀❓ところがどっこい、こーいった風に説明せずに、このポイントだけを箇条書きで書いちゃうと、「そんな簡単なこと言われなくても誰でもやってる」くらいで読み流して、結局、やっちゃうんだよね、、、💦なぜかと言えば、
具体例で比較できないのと、理由付けが分からないから
ま、ここまで書いても、
オリジナリティ＝「自分なりに～、自分的には～」
で、第三者を意識＝客観性がない人は結局、やらかしちゃうんだけど、
ここまで書いてやるのは自己責任だし、後は自分が自分の首を絞めちゃうだけなんでオイラには関係ないし( ´∀｀ )
って感じで最低限の作法もおさらいしたところで～～～実際に
同じ要領で～～～
出力パネルの左上の🕒マークをクリックすると、
今回は以上( ´∀｀ )
UiPath 公式
さてと、次回は
UiPath Studioの真骨頂で、オブジェクト指向言語の醍醐味でもあるソースを再利用する際にも使えるし、Configファイルの読み込みの大前提になる、
ワークフローファイルを呼び出しアクティビティ
をやってく💃
キーワードは、
Mainには、ロボットごとの主処理や余計なアクティビティは組まない
StudioXでは、ワークフローファイルを呼び出しアクティビティがないからMainにいきなりアクティビティを組んでいただけ( ´∀｀ )
結局、今回も長文になったけど、
「実際の開発現場ではこんなことを意識してやってるんだ👀！」
てな感じで考え方とか当たり前の作法に触れてもらって、
民主化された誰でも簡単に使える開発環境を
下手に難しくしてるのは結局、自分（組織とか個人）
てことが肌感覚で分かってもらえれば充分なんで～～～。ま、どーとでも組めるようになってる開発環境なんで、
正解なんざない＝好きに組めばいい
んだけど、メッセージをログアクティビティを好きに組むにしても
基本の型（＝作法、考え方）がなく、動けばいいでソースを組む：型無し
基本の型（＝作法、考え方）を身に付けて、最適なソースを組む：型破り
な違いがあるからね( ´∀｀ )ま、
動けばいいやだけなら好きにしなされ。
オイラの責任になるわけでもなし( ´∀｀ )
んだば今日は新聞もまだ読んでないし、午後から散髪に行くので、
また時間が出来たときに～～～