TypeScript 初期設定

・node.jsをインストール

以下、Visual Studio Codeのターミナルで実行。

・インストール
npm install -g typescript

・利用方法

<script src=”script.js”></script>
のように指定し、
script.ts
という名前でファイルを作成し
tsc script.ts
とトランスパイルする。

・ウォッチ

監視したいフォルダに移動し、
tsc –init
を実行する。

tsconfig.json
が作成されたら、
Ctrl + Shift + B
でウォッチを指定する。

・フォーマット

Alt + Shift + F

VBA VBAからPOSTする方法

 

C# FFmpegにコマンド投げる③

以前も同じものを作ったのだけれど、もっと簡単に。

C# FFmpegにコマンド投げる①

C# FFmpegにコマンド投げる②

 

C# ガントチャート試作

C# DataGridView セルの結合

前回の記事でDataGridViewの結合を色々試しており、その流れで当初、進捗をセルの塗りつぶしで表現する感じのスケジュール管理用のソフトを作ろうかと考えていた。

作業の途中でふとセルの塗りつぶしではなくコントロールのLabelを置いたらどうだろうと思いついて、少し作業を進めてみた。

***

中小の製造業で工程表・計画表ってなるとだいたいガントチャートに類するもので管理するのが定番で、PERTのようなものが出てくることは少ない。
さらに製品マスタ(BOM)も整っていないことが多く、生産計画も手動計算か良くても半自動程度という場合が多い。

生産計画については、内示もなく多品種少量を短納期で作っているので、そもそも計画なんてできないという理由もある。

製品マスタ(BOM)がなく、短納期対応で頻繁に調整が必要な工程表・計画表なら、わざわざ専用ソフトではなくてエクセル+VBAの方が楽ということもあるようで、実際、VBAで魔改造した工程表が便利で乗り換えられないという話もあった。

C# DataGridView セルの結合

今回は標準ヘッダーを利用せず1行目2行目をヘッダーとして利用しており、試しに1行目の1列目2列目を擬似的結合してみた。

どこのサイトもだいたい同じ説明をしていて、CellPainting()で処理するのが基本という感じ。ちょっとつまづいたのが標準描画(セルの背景色とか文字列とか)で疑似的結合のRetangleが隠れてしまう現象で、回避するためにはe.Handled = trueで標準描画をキャンセルする必要があった。

例えば今回は利用しないけど、標準描画の一部をキャンセルする場合、e.Paint()で標準描画を呼び、e.Handled = trueで終了させる。
var p = e.PaintParts & ~DataGridViewPaintParts.Border;
e.Paint(e.ClipBounds, p);
e.Handled = true;
これでBorderの描画がキャンセルされる。

***

次は擬似的結合の範囲をループで動的に取得してみた。1行目1~5列目までは罫線Bottomを消すだけで、それ以降の1行目6列目以降(年月の部分)を疑似的結合している。

描画セル(1行目6列目)が画面から消えない(見えなくなることがない)作りならこれで問題ないのだけど、横スクロールなどで描画セルが画面から消えると疑似的結合のRectangleも消えて黒塗りになってしまうという厄介な問題が発生する。

スクロールの状態から描画セルを修正するような計算をすれば回避できるかもしれないけど、かなり面倒だしCellPainting()は頻繁に呼ばれているので、あまり複雑な計算もしたくない。

***

ちなみに、CellPainting()ではなくPaint()で処理することもできる。イベント引数からCellBoundsを取れないので、直接DataGridViewで指定するだけ。

***

色々考えたけど、結局、Rectangleの擬似的結合は止めて、CellPainting()では罫線だけ処理した。Alignmentで中央にできないし長い文字列も設定できないが、描画落ちするよりはいいかなという感じ。

***

数日後追記。

しばらく経ってから思いついたのが画像を利用するアイデアで、疑似的結合のサイズで動的に画像を生成して、それぞれのセルのサイズで抜き出して描画するという方法。

これだと見た目は結合されているけど、描画はセルごとなので黒塗りになってしまう問題も発生しない。

ただこの方法の場合、疑似的結合の範囲やサイズが固定なら問題ないけど、範囲やサイズが動的に変化するような仕様だとかなり複雑になってしまう。

 

C# DataGridView 操作基本

最近DataGridViewを扱う場合の流れ。

・内容の表示はモデルクラスのインスタンスをリスト化してバインドする。
入力内容をパースしたりする場合は、インスタンスのプロパティで処理。表示のスタイルについてはDataGridViewのセルで処理。

内部で保持するデータ型はstring型が多い。手入力される値はパースで弾いたときに空白に戻したいと思うことが多い。少し前はバインドせずパースの処理を間に入れていた。

ここでは試しにテキストボックスのバインド処理だけ。

・カラムとDBスキーマはリフレクションで連動させ、一箇所で指定。DBのテーブル作成もコード化しておく。
(ここでは記載していない)

・検索ボックスがある場合のクエリもリフクションで作る。
(ここでは記載していない)

・値が変更された行は色を変える。

・更新のときはスクロール位置を戻す。新規のときは一番下へスクロール。

・行を追加するときは1行のみの表示に切り替える。
更新処理はフラグ用のカラムを見て判断。

・マスタ化しているカラムは、クリック時にフォームを表示させる。
(ここでは記載していない)

C# 簡易インクリメンタルサーチ②

・カラムの表示/非表示、サイズ、並び順は上記と同じようにテキストファイルで指定できるようにする。(ここでは記載していない)
ユーザー側で変更したいであろう部分はテキストファイルで処理できるように。

本来はもっとクラスに分散させているけど、今回は見やすいように1つのファイルに入れた。一部は流用しているので載っていない。

ここまで手動でやらなくても色々方法はあるのだろうけど、何だかんだ手作りで落ち着いた。

仕事に必要な文章について

小論文のような文章ではなく、メールや簡単な資料での文章についてメモ。

・パラグラフについて

パラグラフの先頭は字下げしない。
パラグラフごとに空白行を入れる。
パラグラフのサイズは小さくする。数センテンスで1つ。
パラグラフは1つのトピックセンテンスといくつかのサポートセンテンスで作られる。

・センテンスについて

センテンスは短くする。無駄な修飾はしない。

トピックセンテンスはいいたいこと。
トピックセンテンスを先頭にする。

サポートセンテンスはトピックセンテンスの補強。
サポートセンテンスの基本の3種類。

言い換える。 つまり~。
具体例を示す。 例えば~。
予測する。 ~だろう。

トピックセンテンスが意見ならサポートセンテンスで理由や実体験に、トピックセンテンスが事実ならサポートセンテンスを意見にしてもいい。

・プロット(パラグラフ構造)について

3段階の構成にする。

何か聞かれている場合
①聞かれたことに対する回答を示す。
②根拠や理由を示す。
③どうすればいいかを示す。

③は立場や知識量によって違う。提案の場合もあれば指示のような場合もある。

提案の場合
①起こっている事実を示す。
②分析を示す。
③どうしたいかを示す。

②か③に理由を入れる。

・実際の書き方

思いついたこと書きたいことを忘れないうちにどんどん書いていって、最後に並べ替える。書きたいことを箇条書きにするのではなく、センテンスとして使える形にまでしておくこと。

・結論

文章は伝わりやすく。内容は空気を読んで必要ならぼかしたりする。

VBA 表からカレンダー形式に変換

前回はJavascript/C#版で今回はVBA版

○○表という感じの帳票を作る場合、行が単位で列が明細というのが一般的。

明細の中に納期や出荷日など日付に関わる情報が入っていることも多く、そこで問題になるのが、この日付情報同士の関係性がパッと把握できないこと。

日付情報がおまけの場合はいいけど、日付情報が重要な場合は把握しやすいフォーマットに変換してみようということで、表からカレンダーに変換する機能を作成してみた。

ループが2重になるので、行数が多い場合は工夫したほうがいいかもしれない。行数が少なければ問題ないと思う。

Javascript/C# 手作りカレンダー

一般的にカレンダーを自作する必要性はないと思うけど、作る必要がでてきたのでとりあえずメモ。

C#(DataGridView)版

 

業務支援ソフトを作成するときに考えること

今回は業務支援ソフトを作成するときに考えていることを書いてみたいと思います。前提として、作成するのは本業プログラマではない私1人で、日数は数日~数週間程度かける規模。直接の利用者は数人程度としています。

・何を解決したいのか明確にする。
できれば1~2つ、できるだけ少なくする。とりあえずソフトを作れば色々よくなると考えている人が多いので注意する。

・解決したい内容を大きく2つに分類しながら考える。
1.管理精度を上げること。2.楽になること、という2つに分類しながら考える。社内環境にもよるだろうけど、個人的にはこの2つの違いは結構大きくて、かなり進め方が違ってくる。

・管理精度を上げることについて。
例えば、現在の予測精度や集計誤差などの精度を向上したい。あるいは、今までにはない集計や指標を導入したいなど。管理精度を上げることは管理者のためという場合が多く、作業者(ソフト利用者)は興味ないことが多いので、話をするときに作業者の要望を一緒に聞いても(無駄とは言わないが)視点が違っていることが多い。

・楽になることについて。
作業者が望むことはだいたいこれ。作業の手間を減らするなど、あらゆる面倒くさいと思う部分を減らしていく。

・管理精度を上げること、楽になることについて、当然どちら一つだけではなく両方に効果がある場合も多い。例えば、複数で管理しているような情報を一元化するば、管理精度も上がるし楽にもなる。

・作業者は具体的な方法が分からないことも多いので、開発するときにこうすれば楽だろうと想像する。

・素早く試作を作ってフィードバックもらう。
素早く試作(特に重要なのがUI)を作ってフィードバックをもとに修正という流れで作っていく。ソフトを利用する人はUIが重要で見えない部分に興味はない。

・正しい業務手順に軌道修正していく。
正しい業務手順に軌道修正していくか、既存の社内フローを踏襲するか悩むときは結構あるが、将来的に効果がありそうなら、少しずつでも正しい業務手順に軌道修正していく。

***

本末転倒な話ではあるけど、自分が作る程度(マクロレベル)の業務支援ソフトの場合、利用者側での業務改善の方がはるかに効果的なことが多い。誰も見ていない指標を計算するのに時間をかけていたり、手間のかかる承認フローだったり、簡単に改善できるポイントはたくさんある。

例えば、ある資料について作成に時間がかかっているから、システムで自動化という話はありがちだけど、そもそもその資料を作らないという話はまず出てこない。作らなくても業務上困らないのに、誰か1人でも欲しいなら止めれない。こういう状況はいたるところで見つけることができる。

結局、情報共有とか意思決定の高速化というとみんな喜ぶけど、価値のない情報をたくさん共有したり、思いつきと変わらない意思決定を高速にできるようにしても何も変わらない。