FC2ブログ

20181004 Azureで遊んでみる。

Yahoo! Geocitiesさんが長かった役目を終えてサービスを終了します。


むかーし作ったリンクが今もChromeのブックマークに存在しており、そこからこのブログへ飛ぶということでよく使っていたし(ブログのURLをブックマークしろよ)、中年らしく昔日を振り返りその恥辱に悶える記録を電子の海に散らせるのは忍びないため、せっかくながら勉強がてらちょっと遊んでみました。

0.過去のデータを落としてくる。
懐かしのGeocitiesへFTP接続してごっそりDL。よくアカウント覚えてたな自分。

1.せっかくだから「くらうど」ぎじゅつをつかってみようかと。
googleにすっか、Azureにするか悩んだけど、仕事柄Azureとの親和性が少しだけ高いのでそっちで。使い方を覚えてみたいのもある。

2.ではAzureでどうやってアップする?
を参考にすればなんてことはない。(ありがとうございます!)
WebAppとBLOBの方式があるようですけど、過去にBLOB触った時、気が付いたらいい金額が請求されてておっと困ったってことがあって怖いのでWebApp出やってみました。

・App Serviceから、「追加」
・WebAPPを選択。アプリ名がURLになるので、それっぽい名前を付けて、プランを「無料」を選ぶように。有料である必要全くないしな。
・あとは作成して完了。簡単簡単。

3.デプロイにOne Driveが使えるようになってるようで。
FTPでアップもできるけど、なんかせっかくだからOne Driveとリンクを張ってみました。
なお、OneDriveに初めてアクセスしました。
・作った、WebAppの画面を開く。
・デプロイオプションをメニューから選択。
・ソースを選択で、OneDriveを選択。認証の確認取られるので言われるがままに。
・気が付くと、OneDriveに以下のフォルダが作られてびっくり。
ファイル/Apps/Azure Web Apps/(webAppの名前)
・そこへドラッグアンドドロップでファイルをアップロード。ああ、そういえば個人的なアップローダとしてもつかってたな・・・ガラケーで買い物用の参考資料をアップしたな…

4.完了
しなかった。
OneDriveへアップしても、WebAppへ自動では更新されなかったので、アクセス許可されてへんで!とかそんなコンテンツあらへんで!とか返されちゃった。

(いつも素晴らしい記事ありがとうございます!!)

を見ると、自分で同期をしないといかんようなので
・Azureから該当のWebAppを開く。
・デプロイセンターを開く
・上記のバナーにある「同期」を選択。
・変更が少なけりゃすぐ終わる。
で同期完了。


移行できました。
しかし、一部のURLが相対パスじゃなかったので、リンク切れが起こる可能性が!!
だれだこれ作ったやつ!!(12年前の自分です)
で修正→OneDriveへドラッグアンドドロップ→Azureから同期で問題なく修正できましたん。

しっかし、つくってあるリンクが古いなぁ…しかも知人のサイトもほとんどGeo。存在すら忘れてるだろうし、みんな電子の藻屑と化すんだろうね。それはそれでさみしいものです。

スポンサーサイト

SmartUI。

たまに始まるプログラマ向け読書タイム。Smart UIというキーワードから初めて見た。
ドメイン駆動設計に出てくるアンチパターン(反面教師)。
またの名を画面駆動開発。動く画面は大量に素早く作れるが、統合するときに大体破たんするデスマの温床。

この約2年いじってるコードがまさにコレ。(何度も愚痴ってるけどな)
読んでた記事にそういった状況から抜け出そうと奮闘した記録を見つけ、それを読んでると結構、自分がやってる事と被るポイントが。
その中でも自分がこれはよかったと思ってるのは、Data Access Objectを作ること。
正直自分では、毎回SQLをコードに書いて、DataReaderから適切な値に変換することが嫌いで嫌いで、というか

var a = dr["FiledsName"]:

ってフィールド名打つときに絶対面倒くさいから、EDIの機能でコードコンプリートさせるために専用クラスを作るってところから始めており、正直ドメイン駆動開発のための技というわけではない。
が、やっぱり楽ですね。下準備すると。

あとはただ、ひたすらに記述量を減らそうと奮闘中。
同じような挙動をする部分があったら、イベントを共通化したりしてコードを減らしたり。
前は同じオブジェクトが30近く並んでて、そこにデータを「同じように」表示するのに、30回コピペされたコードを見て殺意を覚えたこともあったな。

とはいえ、自分も結局Smart UIで育ってきて、画面駆動開発アタマなのは自覚済みで、面倒くさいと途端にいつものコードかいているので注意が必要ですなー。というかね、だれかと確認しながら進めていきたいよ。自分のやってることが正しいのかわからない。

しかし、ただひたすらにコードを書いているおかげでいろいろ勉強はできてます。
コードを減らすために、せっかくC#を使っているんだからとC#の機能をいろいろ学んで、できる限り活用するようにしていく上で、Linqの概念がしっかり理解できたのはよかった。その感覚を足掛かりに関数型ライクな概念の勉強がそれなりにスムーズに理解できたりできて、その辺からテスト作りやすい作り方が見えてきたりと、そうね、もっと10年位前にこういう意識持ってたら、出遅れ感なんてなかったし、今まで作り続けてきたクソコードも、もう少しうまく動いたかもね…

で、最近になってpaizaで遊んでるけど(Dランクをサクサククリアして快感を得ている段階)
C#を選択してもLinqとCollection.GenericがデフォでUsingされてないのね…確かにDランクの課題なんぞLinqで一発で書けたりするから正直「そこをみたいんじゃねぇwww」って思われてるかもしれないけどねwwww

書きなぐり

今更勉強中。Scala で書く tetrix

やっとコードが読めるようになった気がするぜ…

なお、specs2がコンパイルで通らないってか、importが効かないって丸一日悩んでたけど、sbtのフォルダ構成を理解してなかっただけでした。
spece2のコードは/src/test/scalaに置かないと行けないのね…常識すぎてガイドにもかいてなかったね。

記憶のためにメモ。

あと仕事の愚痴。
課題管理の場所が何故か3種類に。
Excelファイル(自社作成)
Excelファイル(客先作成)
Bug Tracking Ssystem(自分と客先担当者利用中)
…たのむからBTSで統一させてよ!!

なお現在仕様書もBTS内のWIKIに書いてます。

印刷できるようにしてくれと社内に言われてます。PDFは吐けるよ!!!
(口語的表現が多数あるのが問題ですが、それは見直してる)
なお、客先担当者は、redmineのサイトが残ってればいいです。仕様書もそれで問題無いです。ってか紙とか邪魔ってスタンスです。物分りが良くて嬉しい。

というわけで、メンテしてないExcelファイルをメンテしますよー(^o^)

頭の整理のために吐き出す。

あと眠気覚まし。

■ソースコードを整理するの気持ちいい。
引き継いだプログラムのうち、最も重要な機能のプログラムがもうコード追っかけるのがあまりにも苦痛なためいろいろと整理をしている。C#でのWindowsフォームプログラムなんだが、メインのフォームにすべてが記述されていて、フォームのコードが17000行に登っていた。客先に言われてあとからあとから追加機能を実装していったのはわかるが、せめてコードの分離をして欲しかった。

フォーム変数で扱われる各種値。
何千行に渡るF10_Clickイベント
その中で幾度と無く繰り返される「同じような」コード。
何階層目かもわからないネスト。
何重にも囲われている。#region。

実際に処理を追っかけるとすげーイライラしてくる。いまのコードの位置が何をしているかわからない。だいたい、F10_Ckickか、txtCode_Validationのどこか。保存処理をしているんだろうけど、追加(Insert)なのか更新(Update)なのかで処理が分かれるが、単純にIf分岐してるだけで、どっちも同じ関数内。しかもそれぞれ処理が長大なので、結局いまなんの処理をしているかわからない。その上、同じような処理が繰り返し(微妙に違っているけど)書かれているため、更にどの処理をしてるか把握できない。

んー…自分の状況把握能力が良くないのかな?

一応、それぞれの処理ブロックを#regionで囲んでるけど、それを関数にしろよ。region展開しても、いまのコードの位置はF10_Clickなんだよ。ラベルは一番上にスクロールしないと見えないのに1000行近いコードがregionされてんだよ。わかんねーよ。

▼よくわかったこと。関数名って超重要。いや「名前」ってホント重要。

■ユニットテストを使うようになって。
テストし易いように設計するようになる。機能がいい具合に分割できるように考えられる。関数FにAを入力したら、Bが返されるって動きを基本に考えるようなった。副作用とかマジで邪魔と感じるようになってきた。やっと、関数型プログラミングが魅力的に見えるようになった気がする。あとは、動作確認が簡単。デバッグ開始→フォーム起動→(事前に必要なデータ登録)→ボタン押す→結果確認とかマウス触るのめんどくさい、メニューたどるのすら嫌じゃんとか思ってたけど、Ctrl+R , Ctrl+T→結果確認に。

しかし、え?今更?恥ずかしいッて言われても仕方ないこと書いてるな。
恥ずかしいね。ちゃんと手法を勉強しなかった自分が。

■C#のイベントをひたすらまとめる。
既存コードに多いのがこれ。同じような処理やチェックが入るけど、コントロールごとに処理を書いている。数量チェックを行う場所が5こあったらその分、Validationイベント関数とチェック関数をかいてるし。C#のイベントには同じイベント関数を使えること知らない人が書いてたのか、そういう社内規約か知らんが。実際に10個のチェック関数が一つに、Validationも10個が一つに。20個の関数が一つにまとまったわけで。登録前の全体チェックもforeach使ってさっくりかけるわけで。コントロールを特別視しないようになった気がする。あるプログラムなんか20個の同じオブジェクトにそれぞれイベント割り振ってたからな。今なら

foreach(var ctl in TargetCtrools){
ctl += new EbentHandler(EventFunction);
}

でいい訳で。

■社内規則vs言語機能
既存コードみると結構あー規約でこう書けってなってんだなーというところが見受けられて。完全に言語機能を活用出来てないよねって思った。それなりに歴史ある会社っぽいから、いままで積み上げられた経験と技術の結晶なんだろうなと思うけど。もっと楽になる方法はあるよねーと思うわけで。今回の仕事で本格的にC#の言語仕様を勉強したけど、こいつは本当に「コードの量を少しでも減らすために」「コードが少ない=バグの入る余地がヘる」というああ、当然のことだよねってことがいかに重要でそのために如何なる工夫をしてきたか思い知ったわけでございます。前回のプロジェクトでLinqってほんとに有用なの?とか思ってたけどごめんなさい。今となってはLinqサイコーです。なんでおまえらIEnumerable実装してないの?Collectionなの?って気分です。
(そりゃその頃なかったからよ。)
とはいえ、今のところ一人プロジェクト(でも規模は最大級w)でコードも実装も設計も好き勝手し放題にやってるからこそ、そうやって気楽に言えるわけで、実際に他のメンバーに依頼したところなんかもう気持ち悪くて仕方ないから書き換えちゃってるからねー。またお願いって言ったら嫌がるだろうなー。

■とはいえ
こうやってガリガリとコード修正してますが、もちろんその新しいコードが正しいかはわかりません。
綺麗なコードになっているかもわかりません。あ、自分にはわかりやすい。
とはいえ、既に1年前のコードと今書くコードを比べるともう1年前が汚くってww

でもまぁ規模とやりたいこととやってることがわかってるからこそ、こうしたら、ああしたら、こうあるべきってのがわかるんですよね。
幾つか本を読んでると、「最初は捨てるつもりで作れ」って言うのがよく分かる。
2回作れるくらいの余裕を持つべきなんでしょうなー。宇宙兄弟でも月面ムーバー作るときにムッタがそんなこと言ってたね。

CausesValidationについて

自分向け開発メモ:.Net Framework
CausesValidationプロパティについて。
大雑把にいうと、「これがFalseのコントロールにフォーカスが移っても、元のコントロールのValidationイベントが発生しない」というプロパティ。

でも、FalseでもValidationイベントが発生していた。なぜだ。

http://d.hatena.ne.jp/dotnetmemo/20060702/1151839515

あと、PanelなどのコンテナのCausesValidationも影響するので注意が必要。要はPanelのCausesValidationがtrueになっているとその中のButtonのCausesValidationがfalseでもValidatingイベントが発生するということ。



それかー。確かにパネルの同プロパティいじったら想定通りの動きになった。
9年も前の記事に助けられた。.NETのドキュメントにそんなこと書いてあったか?

なお、改修前のプログラムでは、コードに直接検証が不要なコントロールをifの条件分に直接記入したメソッドを作成し、Validationイベント毎にそのメソッドを呼び出していた。せっかく同様の動きができるプロパティがあるなら使うほうがいいだろ。コード量削減的に。

しかし、マスタ1画面のコードを改修…というか書き直しするのにこの時間かかるとは…さすがに全画面でリニューアルは時間がかかりすぎるか?

 HOME TOP next>>