【UiPath StudioXの遊びかた ちょいコラ】逐条編に入る前に①よく勘違いしてる人や組織が多いんだけど、、、
で別にノートブックみたいなパラメータファイルは、
プロジェクトごとにひとつずつ作らないといけない
訳じゃないからね～～～
ま、StudioXの場合、ノートブックが新規プロジェクトを作ると自動でプロジェクトファイルの中に作られちゃう構造だから、
誤解を招く作りになってんのが要因ではあるんだが、、、
例えば、
他のプロジェクトデモ同様に実現できた～～～
ただし、
前回の手法を取らないとメニューから消えないみたいなアホな構造
になってるみたいだから注意してね～～～
順番間違わないでね～～
なんで記事を分けたかとゆーと
と、前回が長くなったので書きそびれもあったってのもあったけど、
冒頭の入りのとおり、
UiPathStudioXにしろ、UiPathStudioにしろ、この手法を知らずに、当たり前に
１対１
で、ノートブック＝Configファイルを作っちゃってる現場が多すぎるから。ところがどっこい、
個人にしろ組織にしろ、ロボットを使う現場で使ってる業務ツールなんて多くてもたかだか10個くらいしかない＝人間の認知の限界でもあるから
目先の業務ごとに様々なロボットを作って、その度にConfigファイルを増やしていき、
組織全体でロボが300個になり、気が付けばConfigファイルも300個
☞管理が大変になり、Configファイルの命名規則なんかも作らないといけない
みたいな感じになってるところもあるからね
（どのプログラミング言語も同じだけど、、、）
で、蓋を開けてみると、非常に似通ったパスだったり、URLだったり、値だったりで俯瞰してみると、ただ
使いまわせばひとつで済むはずの無駄なファイルを増やして
サーバーに負担をかけてるだけ
みたいなことになってるからね～～～
☞ひとつの組織でロボットでよく使うアドレスやファイルなんて、
そんなに変わらないし、増えない
ま、そこで前回では、
何の入力フォルダか結局分からないし、
入力ファイルなんてひとつのロボットで山ほど使うし
そこでどのロボットで使ってるかなんて
＜ここら辺のネーミングセンスが如何に大事か＞
は、
でも書いてるつもりだからま、参考までに～～～
結局、ローコードツールにしろAIにしろ、通底する考え方は同じで、
でも書いたとおり、
作業全体を見渡して、後々の面倒くさいを減らすか＝怠惰さ
だからね👀💦
外出し出来るものは全て外に出して、
使いまわせるものはどんどん使いまわそう
☞それが普段の作業から意識しながらすぐに実践できてるか
で、5年後、10年後
てな感じで変わってくるからね～～～
組織単位、会社単位、部署単位なんかで定期的に、
Configファイルの情報でまとめられるものはないかで、同じファイルにまとめてしまうのもひとつ
同じ値しか使っていないファイルは複数要らない
UiPathStudioでRE-Frameworkでやるとしてもディクショナリは一意のキー名だけ守っておけば大丈夫
だし、ErrorMessage1とかInputFolder2とか何をしてるか一見分からないような名前を付ける＝ネーミングセンスと語彙力のなさ
キーとしての役割を自ら破綻させてるだけ
☞すべては思い込みが原因だし、
思い込みに支配されてる時点で、
エンジニア（に限らずかもしれないが）としてソイツが終わってるだけ
だからね～～～( ´∀｀ )
ビールうんま