見出し画像

【UiPath StudioXの遊びかた21】逐条編 ⑱YouTubeで遊ぼう⑦～シート/範囲/テーブルをクリアで遊ぼう～書き込む前に初期化しとこう

M_Kaku堂

さてと、前回

でデータを抜いてくる

表抽出

まではやったので、今回は、書き込むExcelシートをクリアする

コイツ

をやってく( ´∀｀ )
んだば早速、


シート/範囲/テーブルをクリアアクティビティ

早速、操作を( ´∀｀ )

前回の表抽出の前に入れたいのでここにセット～～～

月に何回か処理を実行すると、毎回、クリアしたい処理シート名は変わる可能性があるので、

Ｍ_Kaku堂練習帳.Sheet(処理年月シート名)

にして、変数を使ってセット～～～

てな感じ

で、先頭行をヘッダーとするは、

前回やったみたいに、YouTubeでスクレイピングをすることもあれば、noteやYahoo!ニュースなど毎回、スクレイピングする項目が変動する可能性があるので、

ヘッダーは残さないように✓を入れない

んで、きちんと表を抽出の前にシートがクリアになっているかを確認するため、

メッセージボックスを入れてスクレイピング前で処理を止める
今回の種類が違うとヘッダー行が変わる説明のために入れたかっただけなので
noteのダッシュボードをスクレイピングは、コメントアウト

実行すると

ストップできた
処理シートはクリア出来てんね
ちゃんと４つ抜けて来てんね( ´∀｀ )
一番上の行のリンク先をコピペして
アクセスしてみると、
ちゃんとサイトに移動出来てんね( ´∀｀ )
☞しっかりURLも抜けてることを確認

一歩前へ：今回は簡単な操作アクティビティだったんだけど、、、

ここからは特に一緒に操作はしなくて良いので～～～
まあ、見といて( ´∀｀ )

で順番に操作をしてくと、
てな感じでテンプレートを選択しろが出てくる

一見テンプレートを指定する方が、毎回決まったデータを抜く定型処理だと、安全とか安心に見えるんだけど、処理シートとか抜く対象、WEBの構成なんかが変わった場合や、処理するシート名が変わる場合なんかで誤って指定すると、

バグの原因になりかねないから気を付けてね～～～( ´∀｀ )

ま、いないとは思うんだけど、

で開いて
今月の処理シートを指定して、確認を左クリック
ココだけではなく
実はここも指定されてしまう

さて、問題

来月から、スクレイピングの対象が今回と違って項目名が違ったらどうする？
☞離れてる場所にあって指定してるのに、気づかなかったら。
毎回UiPath StudioX で他のアクティビティでも練習帳で指定したいときに

テンプレートの選択

を促してくるんだけど、今回やりたい操作って

たかだか、処理の前に前回処理結果の値を消したいだけ

だからね( ´∀｀ )いらんやろこんな促しとか制御。

誰得なん( ´∀｀ )人の行動を考えろよ、UiPath( ´∀｀ )
☞ミスとかバグを誘発するだけだろ( ´∀｀ )

いらねーから、元に戻そ( ´∀｀ )

今回までのソース（リファクタリング後）

要らないものはどんどん削ってる( ´∀｀ )
残っていても混乱の素なので～～～

もう一歩前へ：フェーズ型（＝ウォーターフォール）でガッチガチな設計が好きな人からすると、、、

オイラのこのマガジンでの組み方に違和感とか反感を持つ人も居るかもしれないし、そーゆー人に限って、

設計＝建築で例える人が多い

んだけど、いくら、

要件定義（RFP）や要求事項なんかでガッチガチに整理する
それからソースを組む
＝理想

ではあるんだけど、いくら理想をゆーたところで、そもそも、

お客さん自身が全て設計や要件定義方法を熟知して慣れてるわけではなく、
ある程度カタチになってから本当の要求が出てくるのが人間の心理としては普通。

犬小屋を最初は作ろうって思ってたのに、ある程度出来て、よくよく考えたら、実は犬小屋じゃなくってペットサロンが作りたかった

みたいなことはよくある話。要求自体がコロコロ変わることに目くじら立てる暇があったら、要求が変わっても対応できるように、臨機応変に対応できるように、

可変性を高くしておく

ようにしておけばいいだけの話。

ま、そのためにも、変数にはめ込んで、シート名なんかを動的に取っておくことが大事になってくるんだよねえ( ´∀｀ )

フェーズ型よりもインクリメンタル型
セメスティックよりも、ヒューリスティックに
（『CODECOMPLETE』）

ま、だから結局、ガッチガチに最初から何を書くなんかを決めるよりも、思い付きでこれを今回書いたから、次はこれを書こうみたいに行き当たりばったりでやっていても、却って内容は充実してくるしね～～～( ´∀｀ )

それにいざ、書き始めてるみると、「あ、これもいるね」、「こっちを次は書いた方がいいね」ってことはザラにあるし、

前回のYouTubeの表抽出をいざやってみたら、実はパターンがいっぱい分かれてるから、単純に抜き方を教えるよりも、こんなときは単純な表抽出操作は通用しないってことを説明しとく方が重要だったりするしね～～～

要は、

プログラムとかソースの製造を建築に例えて、誤ったメタファーで変な先入観は持たないこと。

だって、所詮全て無料のオープンソースで開発環境すら無料で入手できる
☞PCさえあれば他には何も資材も要らない、在庫も残らない、趣味で学習してる限りは、納期自体がない

って状態でやってるだけだから、建築みたいに設計図が誤ってるとやり直す際に新たに資材が必要になるような3次元の世界でモノつくりしてるわけじゃないんだから( ´∀｀ )それが

ソフトウェアやロボット開発の最大の強み

なのに、わざわざ建築なんかに例えて、

簡単にやり直したり、機能を追加してより良いモノを作ればいい

だけのことに、作る前からガッチガチになって、柔軟性も可変性もないものを作ってどーするってだけの話( ´∀｀ )まさに、

最善は善の敵（『CODECOMPLETE』）

ま、そー言ったどの開発にも通底する考え方に触れたい人は、

で2年前にほぼ無料で書き切ってるから覗いてみてね～～～
30年以上前の本とかで、ネット上では古いなんて言われてる本も多いけど、
世界的なバイブルばかりで、その感想文を書いてるだけだから( ´∀｀ )

な割に、日本だとコードやソースとにらめっこするばかりでその考え方に触れもしない人が多くて、

いまだにその本に書いてることを実践できてない人ばっかりだから( ´∀｀ )

でも書いたとおりだけど、

理論と哲学は時代を経ても、いつまでも色あせない
ま、だからこそ、理論であり哲学なんだけどね。

CODECOMPLETEでコードベースでの開発がメインな時代の哲学は、
ソースメインなロボットやローコード開発でも通用する

だって、所詮は、人間がやってる営みに過ぎないからね
下手に、ウォーターフォールだアジャイルだってゆーてる
ソフトハウスの方が、急な要求変更や要件追加でおたおたしてる( ´∀｀ )
☞最新の理想な開発手法は、
「漸進的なモジュラーデザイン」

さてと、次回は、

YouTubeでの操作もスクレイピングまでは出来てきたんだけど、３～４行だと寂しいので、もう少し、他のパターンもスクレイピングして、同じシートに追記出来ないか

開始行/最終行を取得アクティビティ

をやってこ💃

YouTubeでのお遊びもあと数回くらいで先が見えてきたねえ( ´∀｀ )

いいなと思ったら応援しよう！