見切り千両、損切り万両
ええ言葉や…
車の運転でよくこのことを僕は例える。アクセルを踏むのは誰でも出来る。車の運転で最も難しいのはブレーキング。ブレーキングのタイミング、力の入れ加減などによって車に与える影響は全然違うし、プロの世界ならタイムに大きく差が出る。
何かを始めるのは確かに難しいけど、撤退するのはもっと難しい。事業をやり始めてやっとアクセルが踏めるようになったのにブレーキを踏むのは嬉しくないことだし。突っ込んだお金のことや、想い入れなどが邪魔をするんだよねぇ…前職でもそうでした。
ま、そんなの関係ないけどね。いくら金を突っ込んだからもったいないとか、どうしてもやりたいから辞められへんとか、単なる感情論。また、「いくらの利益が出るまでやる」というのもズブズブになる。負ければ負けるほどアツくなる博打と同じ考え方。そうじゃなくて、「いくらの金を失ったら回収困難のため撤退」にするのが正しい。
そうは言っても赤字の事業を撤退することが正しいとは限らない。同業者がくたばってその分のシェアが流れてくるケースもある。もう1年引っ張っていたら黒字になった、なんてこともあり得る。最初は赤だったけどスケールメリットが効いてくるようになって黒になるとかもある。はじめから黒字になる事業なんて、ほとんど無いよね。
僕が一番得意なのは、見切ること。見切るというか、見極めるというのが適切かも。見切るかどうかの基準は簡単で、ROIがどこにあるのか。ROIってのは、それをやる意味があるかどうか。意味があるというのは、その仕事や事業に関わる全てのステークホルダーにメリットがあるのか。メリットが無いなら次に続かないんだから辞めちまえで終わり。
辞めまーすって宣言すると面白いもんで「いやいや、だったらこういう条件でいかがですか」って逆に提案頂けることも多かったり。続ける意味が、条件が変わることが出てくる。
色んな意味で、見切り千両損切り万両ってのは正しいなと思います。
WebAPI連携可能な販売管理ソフトが少なすぎる件
PCAクラウドぐらいしか知らない。
API連携無料で出来る販売管理システムがあれば、すげーいいと思うんだよね... 世の中の販売管理システムはLAN前提のクラサバアプリしか無いし、Kintoneで頑張るのは無理じゃん。Webアプリだったら無料で使えるのがたくさんあるけど、WebAPIが用意されていて無料で使えるのは皆無だった。
うーん、ニーズがないのかなぁ。我々みたいに不定形なサービスを販売する会社ならまだしも、モノを売る会社さんの場合は販売管理システムがなければどうしようもないはず。まぁ今後自分がやっていくビジネスの中で、「WebAPI連携が可能な販売管理システム」がどれぐらい求められているかは、注視していきたい。
Kintoneを触ってみたら想像上に出来ることが少なかった件
最近、仕事で使いたくてKintoneを触り始めています。想像をはるかに超えたレベルで、できることが少なくて驚いています。これでアプリ作って納品出来るんかな...
アプリについて
Kintoneではアプリを作ることが出来ます。このアプリと言われているものをぶっちゃけて言えば、マスタメンテしか作ることが出来ません。1つのアプリに1つの入力画面しか作ることが出来ない仕様になっています。入力画面と一覧/検索画面が各々1個ずつあるだけで、それ以上の画面を作ることが出来ません。
入力画面のことをKintone用語でフォームと言います。フォームには明細型のデータも保存できるので、header_detailな入力画面を作ることも可能です。でも、1個だけ。責務が違うなら別アプリに外出しする必要があります。
販売管理を作るのは無理ゲー
販売管理で受注登録することを考えると、下記の4つのアプリが必要になります。
- 受注入力
- 顧客管理
- 商品管理
- 単価管理
単価の管理と言ってるのは、B2Bでは同じ商品でも顧客によって卸単価が異なります。なので、商品と顧客をキーに最新の単価を取得しなければなりませんし、登録する時に単価を保存する必要があります。在庫の引当も必要です。JavaScriptでゴリゴリ頑張ってアプリ間連携をすればできるんでしょうけど、使い勝手がすごく悪くなるのが目に見えています。
アプリでレコードを登録する際に、別のアプリの操作が必要になることが多いのであれば、大量にカスタマイズされたJavascriptというWeb版Excelマクロが出来上がる恐れがあります。
検索条件は柔軟に設定できる
ここは文句ありませんでした。検索条件の保存もできるので、便利です。
集計もアプリ単位
集計も可能ですが、受注と顧客と商品をJOINして商品名がXXの6月の販売実績を顧客コード順でソート…というのは無理ゲーのようです。アプリ単位でしか集計不能です。それらのデータを1つのアプリのレコードとして保存すれば集計できますけど、正規化されていませんから顧客アプリ側で変更があったら終わりです。変更を検知する仕組みがありませんので、Javascriptで頑張るしかない。
業務系アプリでWPFを使うメリットがなかった件
非常によくわかるお話だった。特にここ。
MVVMの原則に従って一生懸命、コードビハインドからコードを追い出したところでほとんどメリットが感じられません。
業務系のアプリはデスクトップのテンキーをベースに操作ができることを求められるから、キー関連のイベントを拾わざるをえなくなり、結局コードビハインドは追い出せない。ボタンをクリックするの？Enterで検索開始すればいいじゃない、とかさ。
MVVMをやる時に一番困るのがコードビハインドからViewModelに処理を投げてそのViewModelからUIにメッセージを返すところ。ココがよくわからなかった。WPFのMVVMは敷居が高く、オレオレ実装でやると予期せぬバグを生み出す温床になります。同じデータなのにAさんとBさんで表示結果が1個のセルだけ違うというバグが...
WPFはWindowsFormの感覚で作ると火傷するということです。全く別物と考えていいでしょう。あと、画面がどうしても重たい。UIを仮想化している為だと思うがUserControlに色々コンポーネントを付け足していくスタイルだと仮想化されたUIが更に重くなる(JSでいうDOMみたいなやつ)みたいで、画面の描画がロースペックなマシンだと時間がかかる。これをチューニングするとなると、作り方を大きく変えないといけない。
WPFの利点にコントロールの外観を自由に変更できることがある。同じデータを円グラフとテーブルの表で表示する、なんてことは大得意。でも、そのメリットを享受できるケースは業務系のアプリにおいてとても限られている。
振り返ってみるとWPFの一番のメリットは画面サイズが固定でなくても良い所と、依存関係プロパティ、データバインディングの３つだった気がした。
WPFは画面サイズやウインドウサイズに応じて自動的に画面の再描画が走るので、相対配置に対応している。Windowsフォームは原則サイズ固定だけど、下記のやり方を使えばフレキシブルにできるみたい。
依存関係プロパティってのは、CSSのように html { font-size:20px;} って指定すると、全てのfont-sizeプロパティを持つUI(p,span,td...など)に変更が伝搬される仕組みのこと。Styleとコントロールは完全に独立されている設計だから。Windowsフォームでは出来なかった。やるとすれば親Formで再帰でループ回してfontsizeプロパティを持ってるなら変更する感じになるかな。別にこれじゃなくてもええけど、他にやり方を知らない。
データバインディングについてはWindowsフォームでも出来る。コードビハインドで画面のViewを内包したモデルを作ってインスタンス作ればいいだけ。多分オブジェクトのネストにも対応してくれるだろう。
WindowsFormsでの単項データバインドまわり | tocsworld
結局、Windowsフォームでもやりたいことはできるし、画面のコンポーネントがダサいというか古臭い所はあるだろうけど、WPFより操作は簡単で作りやすい。デスクトップアプリはWebアプリの３倍難しいのが僕の肌感。Web上に乗っかってるサンプルコードをちょいちょいで見様見真似で....っていうのは困難。GUIのハンドリングは実にめんどくさい。高い操作性を得るためなら、クライアントに配るライセンスがフリーのツールを買うのが最も正しい選択だなと、3ヶ月WPFをどっぷりやっておもいました。
おわり。
WPFのXPSDocumentの横向き印字
Programmer's Report: WPF で横長(Landscape)印刷をするを参考にしつつ。
こんなコードで横向き出来ました。
var printQueue = new LocalPrintServer().GetPrintQueue( "YOUR PRINTER NAME"); PrintTicket ticket = printQueue.DefaultPrintTicket; ticket.PageMediaSize = new PageMediaSize(PageMediaSizeName.ISOA4); ticket.PageOrientation = PageOrientation.Landscape; var xpsDocWriter = PrintQueue.CreateXpsDocumentWriter(printQueue); FixedDocument fixedDoc = new FixedDocument(); for (int i = 1; i <= invoice.totalPage; i++) { var fixedPage = new FixedPage(); fixedPage.Width = 11.69 * 96; fixedPage.Height = 8.27 * 96; var pageContent = new PageContent(); fixedPage.Children.Add(new MyUserControl()); ((IAddChild)pageContent).AddChild(fixedPage); fixedDoc.Pages.Add(pageContent); } xpsDocWriter.Write(fixedDoc, ticket);
- PrintTicketで横向きにする
- サイズを決め打ちでfixedPageに与える。
- XPSに書き込む時に、引数にTicketを与えておく。
以上です。
C#でプリンタの接続ステータスを拾う
こんな感じで拾えますので、どぞ。System.ManagementのDLLに参照を追加してImportしておいて下さい。
public static bool IsPrinterOffLine(string printerName = "") { ManagementScope scope = new ManagementScope("\\root\\cimv2"); scope.Connect(); // Select Printers from WMI Object Collections ManagementObjectSearcher searcher = new ManagementObjectSearcher("SELECT * FROM Win32_Printer"); foreach (ManagementObject printer in searcher.Get()) { if(printer.GetPropertyValue("DeviceID").Equals(printerName)) { return (Boolean)printer.GetPropertyValue("WorkOffline"); } } //プリンタが見つからないならtrue return true; }
Windowsアプリの自動テストはFriendlyが良さげ
WPFでデスクトップアプリを作りまして、画面操作のテストが非常にめんどくさい。Seleniumに該当するものが無いかを簡単に調べてみた。大きく分けてこの３つがあるようだ。
- UIAutomation
- Winium
- Friendly
UIAutomationというのはMSが標準で用意している画面操作のテストライブラリ。VisualStudioを起動して、そこにテストコードを書いていく。WiniumはSeleniumにインスパイアされたWindowsのデスクトップアプリを操作するライブラリで、UIAutomationのラッパーライブラリのようだ。どっちを使っても大差は無さそう。FindByXXXの呪縛からは逃れられない。
で、もう１つの選択肢がこちらのFriendly。
対象プロセス(端的に言えばテスト対象のアプリのexe)を別のプロセスから操作することができ、対象プロセスが保有するすべての属性や関数にアクセスすることが出来る。なぬ？ FindByXXが不要でUIテストのコードが書けるってこと？！それはしゅごい。それだけで心が動く。
APIを詳しく見ていないのですが、僕はXAMLに全然ElementNameを書いていない。MVVMではそんなもの原則不要。ボタンは全部ViewModelのコマンドにバインドしているので、バインドされているViewModelのコマンドをUIテストコードで直接キックできれば楽にテストが書ける...
え？出来ちゃうの？バインドしてるコマンドでボタンを特定してキック出来るっぽいコードが書いてある。なにそれすごい。
ishikawa-tatsuya.hatenablog.com
var app = new WindowsAppFriend(Process.Start("Target.exe"));
WindowControl main = WindowControl.FromZTop(app);
//ApplicationCommands.Closeの割り当たっているボタンを特定
var buttonClose = main.LogicalTree().ByType<Button>().ByCommand(ApplicationCommands.Close).Single();・・・GWの連休課題で試しに動かしてみたいと思います！
