【UiPath StudioXの遊びかた32】ちょいコラ〜StudioX自体が、もはや致命的なバグ( ´∀｀ ) 自称プロは、最初に人を疑い、職人は検証を繰り返し、開発環境を疑う〜やるならせめて、いきなりStudio（ガチな方）からやりなっせ( ´∀｀ )
前回、
で、Yahoo経済ニュースを抜ける機能を作ったので〜〜〜
今朝早速、経済ニュースのネタが増えてるだろうからと、ロボットを再実行してみたんだけど、
でも書いたとおり、
表抽出機能の致命的なバグ
（職場で使っていてもStudioのデータスクレイピング機能でも経験ありだし、他の人もゆーてる）
のせいなのか
組み込み時のパターンと実行時のパターンが裏側で何か不整合なのか
10回中１回もヒットしない。
12回くらい繰り返して、やっと取れた
＝組み込んだアクティビティのせいじゃない
＋
月１実行するロボットなら、年に１回成功したら良い方。
以外は、シートの書き込みも白紙のまま。
👉こんなもんロボットではないし、実行前に表抽出を取り直さないといけないのであれば、DXの旨みもないし。
こちらのミスなのか、何か悪いところがあるのか？
と検証してみたけどそれだけで小１時間かかってる
👉SwiftUIの記事が半分くらい書けるレベル
＝作業コストがデカすぎる
で結果、
同じもので実行のタイミングで取れる時は取れるが、
取れない時が圧倒的に多い
では意味がない。しかもスクレイピングしたデータは、
Studio：処理の前に、ローカルエリアでデータテーブルの中身を確認できる
StudioX：処理の前に、ローカルエリアがないからデータテーブルの中身が確認できない
ってことまで複合的に絡んでいるので、
結論：StudioXは使わない
これから先の作業は少なくともStudioでやった方がいいし、
Studioですら表抽出やセレクターの取り方に問題があるから、
UiPath自体をあまり使わない方がいい
ま、オイラみたいに、
インクリメンタルに何かを追加したらすぐに検証をして、期待値どおりに動いているか（＝インスペクション）を繰り返す
みたいな手法を日々実践してる＝アクション・リサーチ型の職人タイプじゃない自称、プロエンジニアは、頭で考えて、実際に細かい検証しないから、こーいった事象が起きても、
「それはあなたの組み込み方が悪い」
「知らないからだろ」
と、
開発環境を疑う前に、人を疑う
んだけどね🧐
こんな設計とか、それらしい機能なんかを組み込むだけで、
実は、成功率が著しく低いものを、100％出来るみたいに思い込んでUiPathAcademyなんかで解説し、きちんと検証もせずに、社内の研修なんかで、
これで出来る
みたいに教えてる企業は多いし、そうなると、当然、
・これ出来るんだ！
↓
・要求定義でYahoo経済ニュースを抜いてほしい。リリース後、自分たちで改修しやすいように、StudioXで！！！
↓
・完成後、リリース
↓
・10回に1回も成功しなくて、毎回、パターンを取り直さないといけなくて涙目😢
みたいなことになりかねないからね〜〜〜
ま、表形式じゃないと見做して、こんなことをやろうって思わないって人も多いかもしれないけど、
中にはそんな人も必ずいる
ってことで、、、、。
オイラは趣味でお金をかけずに動かしてるだけだからまだ良いけど、
これを業務で人件費とか予算組んで開発してたらどうだろうね🤔
こんな要求が出てくることはないかもしれないけど、こーやって記事にしとくから、もし万が一、同じような要求が来たときは、この記事を参考に
できなくはないが、精度が低い
って材料にでもしておくれやす。
ある意味、こーゆー情報を共有するために、
酒飲みながらとはいえ、今まであえて扱いにくいStudioXを使った記事にしてるので〜〜〜
このマガジンも最終回だねえ
StudioXはStudioに比べて、中途半端すぎて作業コストがデカすぎる
👉せめて、いきなりStudioから開発した方がいい
ま、今回普段仕事でやってる感覚で遊んでみて、
StudioXはクソ
ってわかっただけでも財産だわ( ´∀｀ )こんな詐欺レベルな致命的な欠陥を、
使えるなんて触れ込んでる企業が、
RPAのリードカンパニーを自称してるのに驚く( ´∀｀ )
お前ら理論とかだけで、様々なパターンで検証してないだろってね( ´∀｀ )
さてと、いつやるかはわからないけど、次回からは、やるとしても
ローカルを見れるようにプロファイルを切り替えて、
Studioでの開発
に移ろう。マガジンのタイトルは、
【いきなりStudio】
にでもしようかねえ🧐
まとめ
他の記事でも書いてるが、どのプログラミング言語でも、開発環境でも、
頭だけで動かして、検証しない自称、プロエンジニア（＝思い込み番長）にはご用心
自分が組み込んだ機能を組み込んだ時点であらゆるパターンで検証してみないとか、職人からしたら、
素人以下
なので〜〜〜。後から恥をかきたいのであれば、その自分のスタイルとやらで勝手にどうぞ〜〜〜🕺
それを会社レベルで、
10％以下の精度なものをそれで（理論的には）対応可能
とかゆーてるから、RPA自体がいまいち社会に浸透しないって気づきなされ〜〜〜
自称、プロだけが集まってる企業に至っては、これでさらに、UiPathのライセンスまで払って年間に数百万円とかドブに捨ててるようなものだからね( ´∀｀ )
裏を返すとこれが、
UiPath自体が、AppleやGoogle、Amazon、Facebookみたいなプラットフォーマーになれない理由。
さてと、
５連休の２日目だけど、UiPathの記事は連休中はもうやらない😤
あとは、
【じっくりSwiftUI】でSwiftUIにどっぷりハマります〜〜〜🕺
こんな作業コストがデカすぎるもんで連休ヤキモキしたくないし〜〜〜
私ごとだが、
１年２ヶ月くらい、現場で４本以上の新規と、70本以上の運用保守・改修をしてきて、UiPathには習熟してるとはいえ、
来月からは他の現場で、全く違う技術領域でのお仕事になるので〜〜〜
UiPathの記事はますます不定期で連載になりまする笑
ま、今回、今の現場を退職する経緯については、来月以降次の現場になってから、
に書くや〜〜〜。
こんな古典的な雇用詐欺見たことないレベルなお話( ´∀｀ )
どーいった状況で、どーいったことをしてたから、
そんな会社に巻き込まれて、
5ヶ月で今の現場を退職することになっても、
次の仕事が在職中に見つかったか
まで書くつもりなので〜〜〜🕺その知恵も皆に共有して、
今時、古典的な雇用詐欺を繰り返してる会社なんて、
わかった時点で退職して、市場から淘汰しちゃいましょ( ´∀｀ )
過去の【徒然IT就活】マガジンでは、
でも書いてるとおり、基本的には、
入社前にブラックITを見抜く方法
を書いてたんだけど、この記事は、番外編って感じで。
キーワード：
入社前のやり取りは全て文章として、記録に残しておけ。
記録に残すことに協力しない企業には、入社しなくて正解。
この記事が気に入ったらサポートをしてみませんか？