What is Schedule NurseⅢ (nurse-scheduling-software.com)
(日本語だとリダイレクトされます）
英語マニュアル
MSIXのインストール場所は、通常フォルダと異なり、書き込みをすることができません。
（作者である私自身もどこにインストールされたか分かりません。）
そうすると、problem.jsonの受け渡し、サンプルフォルダでのWriteが出来ないので、基点フォルダ別に設け
AppData→sugawara-systems→schedule_nurse→1.0.0.0
にしています。なので、インストール最初のフォルダは、ここになります。さらに、
英語版と日本語版でサンプルが異なりますので、上からさらに
Samples→Japanese→プロジェクトサンプル
でようやくサンプル場所に辿りつきます。
なお、AppDataは、通常隠しフォルダとなっているので、本来的に保存する場所ではないと思います。そのため、サンプルを保存する場合は、ドキュメントフォルダに移して保存してください。更新時に、名前を変えていても消去されるのではないかと思います。また、アンインストール時は、このフォルダは、消去されると思います。（未確認）
https://www.wangchucheng.com/en/docs/eureka/
というテーマを拝借して構築しています。最初マークダウンをtyporaで記述するようなイメージを持っていたのですが、
hugo server
で、ローカルに起動中に、mdファイルを書き換えると、即差にupdateされることが分かりtyporaを使用する必要はありません。単純にテキストエディタで記述しながら、画面表示を確認できます。
製作中のSnapshotです。
日本語ブラウザを検出してリダイレクトするようにしました。
リダイレクトされないようにするには、ブラウザを日本語以外にするか、OSの言語設定を日本語以外にします。
以下で、切り替えています。
RewriteEngine On RewriteCond %{HTTP:Accept-Language} ^ja [NC] RewriteRule ^$ https://japanese.nurse-scheduling-software.com/ [L,R=301]
1MBしか読み取れないのは、GetRawContentの仕様のようです。
blobsを使うと100MBまで出来るようになるよ、というご丁寧なエラーメッセージが出てきます。
131Cで問題を修正しました。
private DictionarySHA_MAP = new Dictionary (); public async void read_hiearachy() { try { SHA_MAP.Clear(); var github = new Octokit.GitHubClient(new Octokit.ProductHeaderValue("IshisakaSample")); string owner = richTextBox1.Text.Trim(); string repo = richTextBox2.Text.Trim(); treeView1.Nodes.Clear(); TreeNode rootNode = new TreeNode(repo); treeView1.Nodes.Add(rootNode); // ルート・ノードの追加 string branch_str = richTextBox3.Text.Trim(); var branch = await github.Repository.Branch.Get(owner, repo, branch_str);// "master"); var contents = await github.Git.Tree.GetRecursive(owner, repo, branch.Commit.Sha); foreach (var v in contents.Tree) { if (v.Path.Contains(".nurse3")) { if (v.Size >= 1024 * 1024) { SHA_MAP[v.Path] = v.Sha; } if (Thread.CurrentThread.CurrentUICulture.DisplayName.Contains("日本語")){ if (v.Path.Contains("Japanese")) { rootNode.Nodes.Add(v.Path); } }else if (v.Path.Contains("English")){ rootNode.Nodes.Add(v.Path); } } Debug.WriteLine(v.Path, v.Type); } rootNode.Expand(); } catch(Exception ex) { MessageBox.Show(ex.Message); } } private void button1_Click(object sender, EventArgs e) { read_hiearachy(); } private async void read(string filepath) { var github = new Octokit.GitHubClient(new Octokit.ProductHeaderValue("IshisakaSample")); string owner = richTextBox1.Text.Trim(); string repo = richTextBox2.Text.Trim(); if (SHA_MAP.ContainsKey(filepath)) { string sha = SHA_MAP[filepath]; var b64 = await github.Git.Blob.Get(owner, repo, sha); byte[] file=Convert.FromBase64String(b64.Content); form1.deserialize(file); } else { var file = await github.Repository.Content.GetRawContent(owner, repo, filepath); form1.deserialize(file); } }
そのまま、貼り付けるとXMLファイルとしてブラウザが認識してしまって上手くいきませんでした。
https://docs.microsoft.com/en-us/windows/msix/app-installer/installing-windows10-apps-web
のようにすると、インストーラとして認識してくれるようです。downloadのページに貼り付けていますが、未だテスト中です。
日本語環境とそれ以外の環境で、作ったプロジェクト間では、互換がありません。プロジェクトが日本語由来かどうかは、作成時に決まります。その後、国を変更するということは想定していません。
これは、Date関係の定義を変えているために起きる現象です。例えば、日 →Sun、今月→ThisMonth と言った具体にDate表現が異なり、それをベースにDay集合を定義しているためで、基本的には、日本語環境で作ったプロジェクトを英語圏に持っていっても動きません。Pythonを使っていれば、確実にエラーとなるので、分りやすいですが、使っていなければ一見動いているように見えるプロジェクトも多いです。
無用なトラブルを避けるために、Githubサンプルも英語と日本語に分けて、参照できないようにしています。英語環境では、Englishフォルダ下しか見えません
日本語環境では、Japaneseフォルダ下しか見えません。
となります。
行制約時間制約についてVector化記述に対応しました。
時間制約は、ソフト制約がありません。ハード制約しかない唯一の制約になります。また、原因解析でも時間制約が原因とすることは、現状ありません。性能上も整数制約に比べれば、一概には言えないのですが、理屈的には、数倍以上遅くなることがありえます。
従い、
■出来る限り、整数制約を使って頂く
■ソフト制約化は、整数制約を併用する
といった対応が必要になります。
諸事情によりZOOM MEETINGを廃止しました。また、購入ページをリニューアルしました。実質的には、何も変わっていませんが、有償・無償との違いを分かりやすくしました。
例えば、月で制約を切り替えるとします。通常月は、
Special月は、
勤務表ソフトではありますが、数独を汎用的にプログラムできれば、GUIを拡張できる能力の強力な証明になるので、搭載pythonで汎用的に書き直してみました。100x100までは、動作を確認しました。GUIでは、100x100結果は、表示しきれないので、ExcelにExportさせた結果が以下です。簡易的ですが、一応各行列の和が各々5050になっていることを確認しました。
import sc3
import math
if math.sqrt(len(AllDays)) !=math.sqrt(len(shiftdef)):
raise ValueError("AllDays and shiftdef are inconsistent")
blocks=int(math.sqrt(len(AllDays)))
for day in AllDays: #column
for shift in shiftdef.keys():
V=[]
for person in A_Member_in_All:
V.append(sc3.GetShiftVar(person,day,shift))
sc3.AddHard(sc3.SeqLE(1,1,V),'')
for person in A_Member_in_All: #row
for shift in shiftdef.keys():
V=[]
for day in AllDays:
V.append(sc3.GetShiftVar(person,day,shift))
sc3.AddHard(sc3.SeqLE(1,1,V),'')
for person in range(0,len(A_Member_in_All),blocks): #block
for shift in shiftdef.keys():
for day in range(0,len(AllDays),blocks):
V=[]
for i in range(blocks):
for j in range(blocks):
V.append(sc3.GetShiftVar(person+i,day+j,shift))
sc3.AddHard(sc3.SeqLE(1,1,V),'')
https://dmcommunity.org/challenge/challenge-apr-2020/
In a hospital, there has to be a doctor present at all times. In order to make sure this is the case, a planning is made for the next 7 days, starting on a monday. Each day consists of three shifts: an early shift, a late shift and a night shift.
Every shift needs to be assigned to a doctor. In total there are 5 doctors: every doctor has a list of available days, and some have special requirements. In general, the following rules apply:
■A doctor can only work one shift per day.
■A doctor should always be available for his shift (see table below)
■If a doctor has the night shift, they either get the next day off, or the night shift again.
■A doctor either works both days of the weekend, or none of the days.
■A planning should be made in which every requirement is fulfilled.
Name Available
Fleming Friday, Saturday, Sunday
Freud Every day early or late, never night
Heimlich Every day but neven the night shift on weekends
Eustachi Every day, every shift
Golgi Every day, every shift but at max 2 night shifts
という問題を解いてみます。
まずは、上の条件から、スタッフ数5人、シフト数 Early,Late,Night,PaidHolidayの4つ、
月曜から始まる1週間を考えればよいことが分かります。
■A doctor can only work one shift per day.
スケジュールナースは、Default状態でそうなっているので、何も記述する必要がありません。
■A doctor should always be available for his shift (see table below)
意味不明ですが、多分、Dr.毎、シフトは、条件があるのだと思います。テーブル参照。
■If a doctor has the night shift, they either get the next day off, or the night shift again.
Nightの後は、Nightかオフ（PaidHoliday)なので、その他のシフトを禁止すればよいことが分かります。他のシフトは、EarlyかLateしかないので、
Night→Early
Night→Late
を禁止すれば十分です。
■A doctor either works both days of the weekend, or none of the days.
週末の定義が不明ですが、土日と仮定すると、土日のうちの1日だけ働くことを禁止すればよいです。これは、排他的論理和(XOR)ですね。土曜日に働いたら日曜日禁止、日曜日に働いたら、土曜日禁止すれば、よいです。
■A planning should be made in which every requirement is fulfilled.
多分、全てのシフトで、1人以上（or 1人？）が必要だ、ということでしょう。列制約になります。
次にテーブル条件について考えます。
■Fleming Friday, Saturday, Sunday
金土日以外をPaidHolidayで予定を埋めてしまえばよいことが分かります。
■Freud Every day early or late, never night
夜勤以外というラベルを作って、全日予定を埋めます。
■Heimlich Every day but neven the night shift on weekends
夜勤以外というラベルを土日に埋め込みます。
■Golgi Every day, every shift but at max 2 night shifts
Nightシフト数を2以下に制限すればOKです。
非常に簡単なロジックで、実際的には、全然足りてないですが、スケジュールナースで行えば、多分世界最速で、モデル記述とグラフィック１０解を得ることが出来ます。初見1１分でした。（この文章を書いている時間の方が長い）
動画はこちら
国際環境で、AWS LAMBDAで同じような機能を提供するVendorはいるのでしょうか？いるとすれば、競合になります。二つヒットしました。
https://openrules.wordpress.com/2020/04/22/building-a-live-worker-scheduler/
OptaPlannerは、私が開発を始めたころからありました。100%JAVAで書かれているメタヒューリスティクスがベースになっています。ベルギーのGeoffrey De SmetさんがLeadであり論文や動画の投稿も沢山あります。オープンソースのビジネスモデルであり、RedHatがスポンサーのようです。
Openrulesは、毛色が変わっていますが、発想が面白いです。
日本の論文での言及は初めてではないかと思います。
https://www.jstage.jst.go.jp/article/pjsai/JSAI2020/0/JSAI2020_4Rin129/_pdf/-char/ja
スケジュールナースの目指している方向は、
１）求解速度
最適な解を求めるには、会話的に管理者の思いと、解の状況を見ながら、重みを調整します。そのためには、すぐに解が出ることが必要です。できれば、数秒、遅くても数十秒以内に実用的な解を提示できることが必要です。
２）超汎用性・柔軟性
どのようなルールも記述できること。少なくとも、人間が作り出し運用しているルールを記述できない、ということがないこと。大体はGUIベースで、非常にレアな制約でもPythonで記述可能です。
３）ルール化・モデル化支援
Integer Programmingのリテラシーが有るならモデル化してMIPに落とせるでしょう。しかし、毎月制約は変化するのが常です。しかも、モデルをつくり運用するのは、IT技術者でもITリテラシーに通じた人でもありません。制約の世界では、モデル化とメンテナンスの時間の方が、解を求める時間よりはるかにかかります。本来は、生産性向上が目的なのですが、
■自動化コスト＝モデル化（ルール記述・開発）＋求解時間＋メンテナンスコスト
■手書きコスト＝求解時間（作成時間）
フェアな比較では、モデル化とメンテナンスコストを論ずるべきと思いますが、そのような論文は、見たことがありません。実際、SC3の開発においては、この部分に多くの時間を注きました。https://patents.google.com/patent/JP6364638B1/ja
４）アカデミックとのGapを埋めること
http://www.econ.upf.edu/~ramalhin/Referencias/Kellog_2007.pdf
５）ベンチマークでトップ性能を維持すること
https://www.nurse-scheduling-software.com/tutorial/benchmarks.htm
開発から7年、上記の目的は、ほぼ達成できたと考えます。今後は、国際的にも主要な地位を目指すことを目標にしたいと思います。
そこで、次の二つの方向性を考えたいと思います。
１）デスクトップアプリのフリー化
ソフト自体にコストはかかりません。勤務表作成と月々のメンテナンスのみ有償になります。
２）特定業務・形態に絞ったアプリ化
企業向けにスケジューリングソルバ（AWS LAMBDA FUNCTION）を提供
国・分野を絞ることで、汎用性・柔軟性をなるべく維持しながら、より簡便なGUIを装備していただき自動最適化を実現。
年末年始は、次月にはなりますが、年始期間まで含んで休みを設定するところが多いと思います。
年末年始をPythonを使ってダイナミックに記述するのは、良いアイデアですが、年始の期間を新たに定義しなければいけないのが、どうも美しくない、と思いました。そこで、次月(SecondMonth)というのをPredifineすることにしました。
こうすると、制約終了日が決まれば、「次月」は、自動的に決まります。（通常月は、空集合になります。）今月部であって AND 次月部でない 部分が通常月の制約に対応します。これは、ユーザ定義で、集合演算で求めます。
こうすると、
１）年末年始では、制約終了日がSpecial
２）年末年始期間を絶対定義
以上の2点だけが、通常月と変わる部分で、後は、PythonがDynamicに制約を切り替えるので、面倒な部分を隠蔽してくれます。
Windows Sandboxを導入して拡張子msix/msibundleのテストを行いたかったのですが拡張子を認識してくれませんでした。仕方なく、Windows10 1903ISOを持ってきて(VisualStudio OS付ライセンス）Hyper-Vでテストすることにしましました。しかし、OSインストールが、動きませんでした。
同じ現象で、はまった方がおられましたので、その通りにしたら動きました。
https://qiita.com/saeki4n/items/b712cd5c9359f3b54dae
Hyper-Vの良いところは、Snapshotを取って、任意の時点に戻れることです。OS起動状態でスナップショットを取っておけば、何時でもCleanインストール状態から再現できます。
インストーラの拡張子は、見慣れないmsix/msibundleになります。Win10では、ダブルクリックするとインストーラが起動します。
下図は、Hyper-V上でのインストール時のスナップショットですが、デジタル著名が効いて、あの忌まわしいウィルスまがいのメッセージが出てきません。スケジュールナースでのサポートは、Windows10 x64のみVersion 1903以降になります。(現在は2004です。)
インストール後の起動は、デスクトップアイコンはありません。さ行のメニューからの起動となります。
対処方法
https://docs.microsoft.com/en-us/windows/msix/package/signing-known-issues
取得までの流れ
１）DUNS NUMBERの取得
２）代理店の選択
メールでいくつか英語を使う場面はありましたが、コールバックも日本語選択可能ですし、
英語メールに抵抗なければ、最安でも問題ないと思います。
３）Sectigoとのやり取り 日本語でした
法人番号を提示の依頼がありましたが、個人業者なのでない、と回答しました。
４）コールバック 日本語を選択
コンピュータによる自動コールバックで、6桁の数字を記します。
５）ORDER #xxxx - Your Code Signing Certificate is ready!
が着ます。リンクアドレスをインストールするPC上で、IEを起動します。
て、以下の手順で、pcxをExport
マニュアルの英文化を進めています。基本的には、DEEPLで日本文、DEEPL出力をGrammerlyに入力して校正していきます。全体で300ページ位あり、最初は、プロの翻訳者にお願いしていたのですが、上記方法に落ち着きました。DEEPL、翻訳者原稿どちらをGrammarlyに入力しても、受動態(PassiveVoice)の指摘が多いです。しっくりしないときは、自分で書き直して、再度Grammarlyにかけたり、元々の日本文から手直しします。Grammarlyは、有償版です。DeepLとGrammarlyの組み合わせが最強と実感しています。
以上の手順をもっと厳格に進めている方もおられました。
https://qiita.com/doikoji/items/d3b818dc2937bc34d579
BarrirerSolver(内点法）を実装したとのことで評価してみました。
WSL1では、MACアドレスは、変わらなかったのですが、今回環境はWSL2になっており、前回のMAC ADDRESSとは見かけ上異なるものとなり、ライセンスで弾かれてしまいました。
しかたなくWindowsVersionでの評価です。WindowsVersionでは、コマンドラインで_Underbarがスキップされてしまうので、これも仕方なくファイル名を手動で変更しました。結果は、こちらです。
確かに、大規模インスタンスでは、顕著に速くなっていることが分かります。ただし、Defaultでマルチスレッドになるらしくスレッド数は、4です。また、内点法では、Simplexみたいに、Resolveで速くなることもないのでその辺は割り引いて考える必要があります。
