Compare commits
983 Commits
Author | SHA1 | Date |
---|---|---|
![]() |
a4527e0f64 | |
![]() |
0549e3876d | |
![]() |
72e26d4f20 | |
![]() |
8407004c38 | |
![]() |
6fb08c923b | |
![]() |
2b5506b092 | |
![]() |
5d00679d00 | |
![]() |
ed630b2b18 | |
![]() |
34210b7348 | |
![]() |
2454a12299 | |
![]() |
db13f7f4b0 | |
![]() |
4fe86f94eb | |
![]() |
a83ee5b900 | |
![]() |
78b43b9740 | |
![]() |
b8df431529 | |
![]() |
91fb3c7d80 | |
![]() |
6333b6220f | |
![]() |
95c8f61a78 | |
![]() |
8e7b16f368 | |
![]() |
ceba761149 | |
![]() |
4b75a712b1 | |
![]() |
e6d288fe49 | |
![]() |
ee926ea3bb | |
![]() |
5a716a3973 | |
![]() |
13755a5520 | |
![]() |
441f9cae7f | |
![]() |
5078ba65ff | |
![]() |
d91ee00e5e | |
![]() |
89f3bd6dbb | |
![]() |
47df2f4b74 | |
![]() |
1e654623d6 | |
![]() |
cc27dc7152 | |
![]() |
4f3d0e939d | |
![]() |
7f6e6b4b3f | |
![]() |
5d7976718a | |
![]() |
17d9bc942e | |
![]() |
9bcce1abd5 | |
![]() |
e092f07e39 | |
![]() |
ccd4c07518 | |
![]() |
26a660eba7 | |
![]() |
8e619d9296 | |
![]() |
2cfbaaa982 | |
![]() |
fa7e34cdd5 | |
![]() |
097e541c00 | |
![]() |
d7474fd14e | |
![]() |
26a5eee00e | |
![]() |
4c93a7f197 | |
![]() |
e7ac8e6b6e | |
![]() |
838e08ed70 | |
![]() |
1fcc2931a7 | |
![]() |
e9dbcc0808 | |
![]() |
96b349df38 | |
![]() |
55d21a15ec | |
![]() |
dd63f10806 | |
![]() |
f30edee028 | |
![]() |
eceb112879 | |
![]() |
1975682ae5 | |
![]() |
5ef027d58d | |
![]() |
fa0b14edec | |
![]() |
d947ea4b11 | |
![]() |
2346006091 | |
![]() |
9dc95c5d9a | |
![]() |
d7a9489c71 | |
![]() |
b326ee768a | |
![]() |
02c4fb2aad | |
![]() |
b4157149ce | |
![]() |
e5294789a9 | |
![]() |
2a7b2947fd | |
![]() |
70af24f2e9 | |
![]() |
c19039579c | |
![]() |
515a105c53 | |
![]() |
df0fbf66f6 | |
![]() |
fd34990217 | |
![]() |
23e00bb020 | |
![]() |
b80bffb608 | |
![]() |
fe54c762a8 | |
![]() |
8b937cd59f | |
![]() |
acb223df6f | |
![]() |
57a1eb350c | |
![]() |
a494f10214 | |
![]() |
8940d63a9a | |
![]() |
12cd15479c | |
![]() |
885fb70789 | |
![]() |
338723ee82 | |
![]() |
981b3bf854 | |
![]() |
a4a304baca | |
![]() |
50d3bde8fd | |
![]() |
c7477a5352 | |
![]() |
2768fbef8b | |
![]() |
dbcc32fb02 | |
![]() |
ab3b8d349f | |
![]() |
5d58db6c45 | |
![]() |
7b1f58dab4 | |
![]() |
7c379f822d | |
![]() |
1ea9db1c84 | |
![]() |
52d5b64f7a | |
![]() |
b19c9dfde5 | |
![]() |
7bcf3c30a3 | |
![]() |
6c36d37993 | |
![]() |
9e36aeda48 | |
![]() |
6d50657297 | |
![]() |
6bb32d1729 | |
![]() |
3b421e01c5 | |
![]() |
3be5a1c59d | |
![]() |
8c5d0c60c4 | |
![]() |
70be397e17 | |
![]() |
1a1a95ff98 | |
![]() |
1489dad56f | |
![]() |
7c91c1c6aa | |
![]() |
04eb8d570d | |
![]() |
f2f3f9b2f5 | |
![]() |
c4aea86027 | |
![]() |
c01f5210ce | |
![]() |
9ad7462a50 | |
![]() |
2707ff1e66 | |
![]() |
0f2d73ffdd | |
![]() |
08971a92a7 | |
![]() |
c21b24e478 | |
![]() |
6162862796 | |
![]() |
e6742901c0 | |
![]() |
b6aa101e52 | |
![]() |
d96bdea990 | |
![]() |
5a24e8a701 | |
![]() |
c3d8eb859d | |
![]() |
e5d1797e40 | |
![]() |
4f39a7c7db | |
![]() |
aa424a0e17 | |
![]() |
55fe54bc30 | |
![]() |
ddc06044f3 | |
![]() |
7e50b6909a | |
![]() |
44f5547ca2 | |
![]() |
20b52e4d38 | |
![]() |
d9300b1ddd | |
![]() |
0d3918a342 | |
![]() |
ab03ae1fb9 | |
![]() |
d9cd000f66 | |
![]() |
1155af3e34 | |
![]() |
f0d9a2e334 | |
![]() |
ba41a06526 | |
![]() |
ebe1d81c24 | |
![]() |
c51e384b13 | |
![]() |
9ed45f5725 | |
![]() |
b14077c4f9 | |
![]() |
3ed2c82c6d | |
![]() |
3d60f52802 | |
![]() |
76426e0ff6 | |
![]() |
3e4550124b | |
![]() |
0b88331270 | |
![]() |
7268149bdb | |
![]() |
fe85e690ce | |
![]() |
f4ff76a0e8 | |
![]() |
24f1ef152e | |
![]() |
e39247eda4 | |
![]() |
41911a0b79 | |
![]() |
412fa9bf7c | |
![]() |
17d13d5744 | |
![]() |
dc939866c5 | |
![]() |
3a3dbb0fba | |
![]() |
fb9de278a1 | |
![]() |
ee9cbf1e5f | |
![]() |
c12bc63581 | |
![]() |
94a5f17c0f | |
![]() |
e0caa8bc20 | |
![]() |
2556f69627 | |
![]() |
1180797e45 | |
![]() |
b05a994c99 | |
![]() |
686cd83ed4 | |
![]() |
c6757e3dce | |
![]() |
a51b78637c | |
![]() |
ff5df7f5d7 | |
![]() |
e78c34ff9f | |
![]() |
cd52156e49 | |
![]() |
949202ffe1 | |
![]() |
ecbb36ad86 | |
![]() |
5ed028ebed | |
![]() |
73faefa9a2 | |
![]() |
475c61d05b | |
![]() |
01c07ad38d | |
![]() |
e0fead59cd | |
![]() |
a31ad0fe7d | |
![]() |
127697334d | |
![]() |
48716fe33d | |
![]() |
659e456388 | |
![]() |
d440530592 | |
![]() |
151e5988e3 | |
![]() |
84e354675d | |
![]() |
0d19d79330 | |
![]() |
ab290ea15b | |
![]() |
c9f3094976 | |
![]() |
16279488c8 | |
![]() |
b8f33027f7 | |
![]() |
0823111038 | |
![]() |
0e7991049a | |
![]() |
adabf29c74 | |
![]() |
220b546611 | |
![]() |
525a6d0ded | |
![]() |
c0fe648d96 | |
![]() |
700fff199d | |
![]() |
ad4a0c7ab6 | |
![]() |
40b4c11aa0 | |
![]() |
cbee3f3f88 | |
![]() |
ed414419a9 | |
![]() |
e99b542873 | |
![]() |
c9509e36f3 | |
![]() |
e2e49f8fac | |
![]() |
4828ed9a5b | |
![]() |
d677c1e537 | |
![]() |
4bb2299e9a | |
![]() |
e28cb372de | |
![]() |
e03a847716 | |
![]() |
2766cd8eea | |
![]() |
938940bd68 | |
![]() |
ba06cfade2 | |
![]() |
7481c2498f | |
![]() |
d16de4ae84 | |
![]() |
cffc6a155d | |
![]() |
f486922c02 | |
![]() |
4ae614b44b | |
![]() |
b12e450d65 | |
![]() |
0a8fa5d89a | |
![]() |
d9b5448c56 | |
![]() |
9597536b92 | |
![]() |
e3e3e31c56 | |
![]() |
c1724a50ba | |
![]() |
643425f412 | |
![]() |
8a0e982ecc | |
![]() |
fd96828db1 | |
![]() |
2c7b7034eb | |
![]() |
19c605642f | |
![]() |
f68a5bd601 | |
![]() |
49c5cf79ed | |
![]() |
ee5751d646 | |
![]() |
b70d039f50 | |
![]() |
8d388f8f2c | |
![]() |
569a99f928 | |
![]() |
9292e1bb34 | |
![]() |
c1c69e4d8c | |
![]() |
2ea84ab998 | |
![]() |
9a5a38b999 | |
![]() |
8412d4c6e6 | |
![]() |
0374a7fcdb | |
![]() |
8742eb0d6e | |
![]() |
9fe14ecca0 | |
![]() |
b643cd90f0 | |
![]() |
19dfd5a03e | |
![]() |
028c681dbf | |
![]() |
9697d18d0c | |
![]() |
1fadf60862 | |
![]() |
bd45fd5815 | |
![]() |
1ba6e6cf6d | |
![]() |
f2e983f9ff | |
![]() |
c141171b57 | |
![]() |
d7d3230933 | |
![]() |
e266441bd1 | |
![]() |
dfc375b96a | |
![]() |
460462da73 | |
![]() |
a051e9c2fa | |
![]() |
c58c12ff22 | |
![]() |
1b7ddb7d7b | |
![]() |
44493750fe | |
![]() |
d9397baee5 | |
![]() |
efea3e5aa8 | |
![]() |
78ec4070c2 | |
![]() |
4b9a6abe35 | |
![]() |
1fb5fec17e | |
![]() |
11f3aa57de | |
![]() |
de94f5b75a | |
![]() |
e31f22974c | |
![]() |
ef24dfb3ab | |
![]() |
4aa9143524 | |
![]() |
e621b3fd28 | |
![]() |
48a1065e9d | |
![]() |
1014dec180 | |
![]() |
5a39a928ad | |
![]() |
2efddc6439 | |
![]() |
94b5f88971 | |
![]() |
5e5873b7ad | |
![]() |
5b0e122e24 | |
![]() |
e0d5f593f3 | |
![]() |
1542ae58f8 | |
![]() |
6494a3a841 | |
![]() |
d319b99c8c | |
![]() |
82d8e535c1 | |
![]() |
9823a4d2b3 | |
![]() |
2fd69bc2d0 | |
![]() |
7e59d758b0 | |
![]() |
7b848139f1 | |
![]() |
aafa91ddf8 | |
![]() |
1eb181a97e | |
![]() |
daf40016e4 | |
![]() |
cc3a3e6959 | |
![]() |
6481309ede | |
![]() |
53fee47d71 | |
![]() |
538ca1a3a5 | |
![]() |
bbfef4d58e | |
![]() |
7968d278a8 | |
![]() |
775026df40 | |
![]() |
0451868a0d | |
![]() |
59890d4c18 | |
![]() |
3f981381d9 | |
![]() |
6c181c7c52 | |
![]() |
7513d4c0ae | |
![]() |
5522d0d963 | |
![]() |
1dfbef7292 | |
![]() |
f5503fa814 | |
![]() |
8c4ba29a8e | |
![]() |
82ae088b4f | |
![]() |
56492d6245 | |
![]() |
cc7d129b81 | |
![]() |
b23d6e367d | |
![]() |
6086ab428f | |
![]() |
ea154163ee | |
![]() |
024d5f67c4 | |
![]() |
11a8ca742b | |
![]() |
7597996496 | |
![]() |
8cf02d0d41 | |
![]() |
756fc3c9ed | |
![]() |
9eb8ba8756 | |
![]() |
15781b189b | |
![]() |
cc58e76b66 | |
![]() |
e41eb7774f | |
![]() |
534157c13e | |
![]() |
25917310fd | |
![]() |
844ce23245 | |
![]() |
759ef3a6b4 | |
![]() |
f8aa328d43 | |
![]() |
5d0aae42a9 | |
![]() |
da37c15b6b | |
![]() |
b75ee435bc | |
![]() |
e15bed71f6 | |
![]() |
050d178c7c | |
![]() |
189790324e | |
![]() |
6f87eb1316 | |
![]() |
644b9b9c18 | |
![]() |
94448a91df | |
![]() |
e72a853237 | |
![]() |
4594ca6e60 | |
![]() |
f0cada556e | |
![]() |
c51074414f | |
![]() |
7bbbe4a526 | |
![]() |
6ab6ec9c13 | |
![]() |
c3cefbb49c | |
![]() |
fb4404f3b5 | |
![]() |
a069210376 | |
![]() |
bc97124aab | |
![]() |
d7daeda2e9 | |
![]() |
06566bc375 | |
![]() |
f98c932906 | |
![]() |
2343b3b428 | |
![]() |
f38973c909 | |
![]() |
e850216d45 | |
![]() |
4ddd130b78 | |
![]() |
5362fa349a | |
![]() |
aa8801e567 | |
![]() |
a0b03c297b | |
![]() |
6027a57a74 | |
![]() |
38d122a350 | |
![]() |
79125ca11a | |
![]() |
e872254b1c | |
![]() |
7b6fdb22bb | |
![]() |
737f0d5851 | |
![]() |
1febb6f35b | |
![]() |
8d23a100d5 | |
![]() |
43dba0ffa7 | |
![]() |
6b99afc0aa | |
![]() |
571d0f9a8e | |
![]() |
ee0760ef80 | |
![]() |
d2a762b531 | |
![]() |
f668a6ae94 | |
![]() |
e5eb6c9fd2 | |
![]() |
fb421e62df | |
![]() |
d961752335 | |
![]() |
f955e3cda6 | |
![]() |
0193d2d6a0 | |
![]() |
c055fe6f73 | |
![]() |
4031bca9dd | |
![]() |
40b31d6db7 | |
![]() |
5e21a78be3 | |
![]() |
ae0f82611f | |
![]() |
96eab7bee2 | |
![]() |
ab11a02f53 | |
![]() |
48146bbafa | |
![]() |
7d171fd81e | |
![]() |
475f53dd68 | |
![]() |
3d0deb6d34 | |
![]() |
9cefae8723 | |
![]() |
d865e51230 | |
![]() |
50b7dfae8c | |
![]() |
1b08c19e99 | |
![]() |
76b00bb89a | |
![]() |
7abf5ba2fc | |
![]() |
27a6248931 | |
![]() |
18886fd815 | |
![]() |
bf5c159401 | |
![]() |
86511a2697 | |
![]() |
f377f32343 | |
![]() |
0e56e705b2 | |
![]() |
fb4f68185d | |
![]() |
78e4eb5eeb | |
![]() |
64beb228e0 | |
![]() |
4f7c90696e | |
![]() |
49edb413f2 | |
![]() |
ee34c4a0bb | |
![]() |
599c154aee | |
![]() |
550c239e65 | |
![]() |
22b9f5a06b | |
![]() |
a7f703056f | |
![]() |
1412a797ae | |
![]() |
c343054040 | |
![]() |
4c341e3183 | |
![]() |
d26b1089f9 | |
![]() |
916913b9a5 | |
![]() |
eca176c8ad | |
![]() |
c5b29ccf29 | |
![]() |
d2d7a7cf59 | |
![]() |
241d3c0ed8 | |
![]() |
c7f6275217 | |
![]() |
0a0a5975a7 | |
![]() |
470c8a7bd3 | |
![]() |
3cf721a3be | |
![]() |
2bf3c8ca8b | |
![]() |
7126941bb8 | |
![]() |
bf5baf9940 | |
![]() |
ceece573c3 | |
![]() |
00e2a6e822 | |
![]() |
15316241a8 | |
![]() |
4f46782213 | |
![]() |
adb721ae6a | |
![]() |
5de1805cd9 | |
![]() |
eeb5e0621d | |
![]() |
413c34f3f0 | |
![]() |
9450a36e11 | |
![]() |
87cfe80c67 | |
![]() |
85eab60f5f | |
![]() |
91cdaa7a69 | |
![]() |
f2c595c437 | |
![]() |
c36d58df09 | |
![]() |
cff37d0199 | |
![]() |
984d817ecf | |
![]() |
5bb9b85c46 | |
![]() |
811dc6427d | |
![]() |
1cc86d2c8d | |
![]() |
d3bbf2c091 | |
![]() |
4f43dc9e56 | |
![]() |
db7e059e1a | |
![]() |
dffb835bea | |
![]() |
1878511bf3 | |
![]() |
98fed101f4 | |
![]() |
cabdfe3688 | |
![]() |
a2ec37ec8a | |
![]() |
6006ddf449 | |
![]() |
5702019f35 | |
![]() |
0293f6cf36 | |
![]() |
18770303b4 | |
![]() |
ff4ae7d505 | |
![]() |
04ee7522ee | |
![]() |
9b5eda37eb | |
![]() |
24edacaf47 | |
![]() |
345a4cb324 | |
![]() |
ee24191d94 | |
![]() |
b7e125bbb4 | |
![]() |
643cf84f70 | |
![]() |
caa5e7ff20 | |
![]() |
0c6053fdf9 | |
![]() |
750d92f66f | |
![]() |
6e4dbf47f8 | |
![]() |
9a5f6c744a | |
![]() |
14cb231d48 | |
![]() |
2205f7ad73 | |
![]() |
e6e8218bbe | |
![]() |
db45fc9b55 | |
![]() |
47fee74cd1 | |
![]() |
be5d67eb12 | |
![]() |
e737a082ea | |
![]() |
4f4edaaefe | |
![]() |
e680cd5f1f | |
![]() |
10227fe519 | |
![]() |
e53aa6da83 | |
![]() |
1543101ea5 | |
![]() |
d6139c6ae3 | |
![]() |
acae5daff8 | |
![]() |
aaaf3a7140 | |
![]() |
5d88da7734 | |
![]() |
06ea7a2e14 | |
![]() |
cd8e458a9e | |
![]() |
a8382dffe7 | |
![]() |
85f4289db6 | |
![]() |
5a2802383d | |
![]() |
c93c41c5c3 | |
![]() |
44d6fd835d | |
![]() |
162901563e | |
![]() |
6293173c3f | |
![]() |
00d61fec81 | |
![]() |
090298a6ae | |
![]() |
16ba51d985 | |
![]() |
ab88a42510 | |
![]() |
fb4529b3ab | |
![]() |
1a42c397b9 | |
![]() |
ce4ef2cefc | |
![]() |
7d4f7dab2e | |
![]() |
c6c9082dc4 | |
![]() |
47cfa9523c | |
![]() |
6793a6724d | |
![]() |
6464384641 | |
![]() |
1607d7abdd | |
![]() |
21949440d8 | |
![]() |
e803fed9a0 | |
![]() |
639f0c2724 | |
![]() |
41c4c63cb0 | |
![]() |
889181b2c4 | |
![]() |
2b929304d2 | |
![]() |
e540d2208f | |
![]() |
17a5a54c8a | |
![]() |
a779cb973c | |
![]() |
28788d43f7 | |
![]() |
007dbea5da | |
![]() |
13bfcbe7cd | |
![]() |
8954c356ab | |
![]() |
4b1d75b4cb | |
![]() |
99e27b239b | |
![]() |
eb8454d8e0 | |
![]() |
95d5bc8b44 | |
![]() |
5ce908e966 | |
![]() |
89b576cf07 | |
![]() |
520ed76c22 | |
![]() |
a0779d7153 | |
![]() |
f54545ffcf | |
![]() |
6f0b03987b | |
![]() |
18039402a2 | |
![]() |
03144f1088 | |
![]() |
12d07c08d9 | |
![]() |
55b2f75bf0 | |
![]() |
bd08a97125 | |
![]() |
794d88a025 | |
![]() |
8673a067a4 | |
![]() |
4881a2ab93 | |
![]() |
9f0b7acd23 | |
![]() |
82e7a58e9c | |
![]() |
61a5c70aaf | |
![]() |
c184b03fb6 | |
![]() |
52cfacdd4e | |
![]() |
f0dc609d41 | |
![]() |
950434178f | |
![]() |
81d9af0263 | |
![]() |
0de5b39408 | |
![]() |
5c40115ba1 | |
![]() |
40e4964c94 | |
![]() |
6d40437663 | |
![]() |
824be0098a | |
![]() |
ee405872e3 | |
![]() |
f812a49752 | |
![]() |
c6e7c9fd17 | |
![]() |
c1a60a231c | |
![]() |
b3c6f133f2 | |
![]() |
32454c8ea6 | |
![]() |
56b381644c | |
![]() |
3cb0b8442f | |
![]() |
4cf1533602 | |
![]() |
65aff7c766 | |
![]() |
3c83242c6c | |
![]() |
fbe836de7d | |
![]() |
5ddb7867e9 | |
![]() |
a555559b55 | |
![]() |
b5648e3722 | |
![]() |
19c4c9a7a7 | |
![]() |
9815df2f00 | |
![]() |
69553fbfee | |
![]() |
2d3480d3b5 | |
![]() |
34ac2581dc | |
![]() |
1faa8d77bb | |
![]() |
119a224111 | |
![]() |
19bd2501c2 | |
![]() |
a72fe987b8 | |
![]() |
342a971a0f | |
![]() |
6f5e6d7b93 | |
![]() |
e79aa337e4 | |
![]() |
0c138a307a | |
![]() |
7b8e029dca | |
![]() |
46c78d4dcc | |
![]() |
2d02b56480 | |
![]() |
c9ee96ce11 | |
![]() |
75f86230c0 | |
![]() |
2c3b8767e2 | |
![]() |
394f8dcf14 | |
![]() |
1740cff8af | |
![]() |
6c78d6c5ad | |
![]() |
a49a4e0107 | |
![]() |
1e7632cf0a | |
![]() |
20bbb05eba | |
![]() |
77135060b9 | |
![]() |
65f7b2587e | |
![]() |
10aab6fbbf | |
![]() |
3f081c1ca4 | |
![]() |
fa58d6db9a | |
![]() |
7a8c66e487 | |
![]() |
ee69059f47 | |
![]() |
7f60da774e | |
![]() |
acc7648525 | |
![]() |
46ba065b5f | |
![]() |
000a300a8c | |
![]() |
9033dd5d0e | |
![]() |
148c6fa2a5 | |
![]() |
18a0980168 | |
![]() |
a0429b58a6 | |
![]() |
04bcffa23e | |
![]() |
7edf4eeef3 | |
![]() |
5ed68826db | |
![]() |
6d94ca7f21 | |
![]() |
8048f52a38 | |
![]() |
c6137ff8b8 | |
![]() |
1540d9b48d | |
![]() |
1eebadbcc3 | |
![]() |
cc6f10f4ae | |
![]() |
5f177265c8 | |
![]() |
eb465fb0f9 | |
![]() |
3fca452770 | |
![]() |
dc1db06471 | |
![]() |
b21a16b0c4 | |
![]() |
42f353010f | |
![]() |
4042213fbf | |
![]() |
1064eb4fe4 | |
![]() |
9e83121b19 | |
![]() |
82b0a3a7bb | |
![]() |
7c0d1fb6cb | |
![]() |
897dd81872 | |
![]() |
ce2e1d1eeb | |
![]() |
902b91d148 | |
![]() |
066776aef8 | |
![]() |
c29fb1d823 | |
![]() |
a5e0c3df0d | |
![]() |
23cd5190f5 | |
![]() |
dabf9912b6 | |
![]() |
8af133b4e3 | |
![]() |
38a1efc772 | |
![]() |
12e4bd15d2 | |
![]() |
53a662639e | |
![]() |
44a53af18d | |
![]() |
912ef9404c | |
![]() |
527153ef86 | |
![]() |
af34ad64a3 | |
![]() |
407d1b66bf | |
![]() |
36c239ec0c | |
![]() |
586065a158 | |
![]() |
7a8ceff06c | |
![]() |
c6f501afcf | |
![]() |
2e75f7b209 | |
![]() |
534a5e8ae8 | |
![]() |
e1a06cc4eb | |
![]() |
4ab538ccb6 | |
![]() |
646c7eb718 | |
![]() |
d5e31a2cc2 | |
![]() |
b8328489f0 | |
![]() |
93c0f55601 | |
![]() |
2151e97ce1 | |
![]() |
983a9fc6b6 | |
![]() |
17f6b3f95f | |
![]() |
dcfce9b61c | |
![]() |
91ac737c67 | |
![]() |
7672db1c5c | |
![]() |
9deee06553 | |
![]() |
15b1da0edb | |
![]() |
5a382b5283 | |
![]() |
8e3b38b66e | |
![]() |
0e2f84b86c | |
![]() |
7e9aa4eae5 | |
![]() |
49c7475f63 | |
![]() |
a28d7e8993 | |
![]() |
3c1b654120 | |
![]() |
4df9889ead | |
![]() |
5f8da25a8b | |
![]() |
fd13d65639 | |
![]() |
f838715eea | |
![]() |
b69fcd7b6f | |
![]() |
cb60d66884 | |
![]() |
c422c40a7c | |
![]() |
82606717c0 | |
![]() |
43a44a27cf | |
![]() |
364327cc8d | |
![]() |
ca9df50b0d | |
![]() |
63b45d957a | |
![]() |
d845b61e65 | |
![]() |
8e9376600d | |
![]() |
51c5251561 | |
![]() |
cd09273584 | |
![]() |
67eb6a2624 | |
![]() |
7120111a71 | |
![]() |
cfad96595d | |
![]() |
ea9de1b464 | |
![]() |
3dd8de022c | |
![]() |
def86a659f | |
![]() |
33d6b899e0 | |
![]() |
f3c0ec1d92 | |
![]() |
45d1b38a4e | |
![]() |
ff760e2d6a | |
![]() |
7acf77bda8 | |
![]() |
091539e45e | |
![]() |
176b8354c3 | |
![]() |
6939631c91 | |
![]() |
71d74c31bc | |
![]() |
e683224f0b | |
![]() |
ce5bf8ff6d | |
![]() |
ec22a511a1 | |
![]() |
c6bb913311 | |
![]() |
ad5e550604 | |
![]() |
5556be7cfc | |
![]() |
2fbd871cd1 | |
![]() |
6579a7ba54 | |
![]() |
0822490488 | |
![]() |
1789f35811 | |
![]() |
56ef9e21f2 | |
![]() |
a2b500dfdd | |
![]() |
d3c39a4b82 | |
![]() |
b2255d901a | |
![]() |
a7c3ea376f | |
![]() |
0ed1270267 | |
![]() |
486605844a | |
![]() |
3576b4c395 | |
![]() |
b8e56f92a0 | |
![]() |
0c889aa3f3 | |
![]() |
d959ad3a6b | |
![]() |
441dfcdbfa | |
![]() |
40ec568c96 | |
![]() |
a4e2ab46eb | |
![]() |
c97f866ec8 | |
![]() |
2a93fcb7e5 | |
![]() |
326e9be5d5 | |
![]() |
8fb72d8cc8 | |
![]() |
5cb266921e | |
![]() |
01bb2c2029 | |
![]() |
059aeac810 | |
![]() |
3251fc2da0 | |
![]() |
f848505f29 | |
![]() |
958f7c4dc2 | |
![]() |
e55da303aa | |
![]() |
c035c42501 | |
![]() |
309abd11e1 | |
![]() |
988d7984ca | |
![]() |
e18e6df48c | |
![]() |
d62d9a86c0 | |
![]() |
3e492167eb | |
![]() |
bb0bf8b3fc | |
![]() |
19cead57b8 | |
![]() |
86f0176e45 | |
![]() |
66598917f1 | |
![]() |
e78dde3784 | |
![]() |
c2497912ca | |
![]() |
9b9b257620 | |
![]() |
6e88495538 | |
![]() |
7ba832e634 | |
![]() |
f890d9ee5b | |
![]() |
b06c791cde | |
![]() |
acd5dff6e5 | |
![]() |
47b0e7edd8 | |
![]() |
29d69fd55e | |
![]() |
0cda0c0fb1 | |
![]() |
06ae17394c | |
![]() |
4abfef3848 | |
![]() |
9be03a41a6 | |
![]() |
4892fe52e5 | |
![]() |
7241a34f3b | |
![]() |
0035f167b9 | |
![]() |
82be414337 | |
![]() |
612509f3b0 | |
![]() |
130715b14f | |
![]() |
6ad4463561 | |
![]() |
5f9802dac0 | |
![]() |
2d45ba28be | |
![]() |
53547f7229 | |
![]() |
2b8c3868af | |
![]() |
7dff3c5c7c | |
![]() |
f7eed0b0bc | |
![]() |
c6ccc45d1b | |
![]() |
e598acfa6d | |
![]() |
99168e3edd | |
![]() |
f3c97cc8cc | |
![]() |
f271fcba0b | |
![]() |
6610c9b2ce | |
![]() |
a366c4bf0f | |
![]() |
5a650ea435 | |
![]() |
aa4e5729ec | |
![]() |
9d1ddf7c23 | |
![]() |
5222bd7f7c | |
![]() |
b5d34f6875 | |
![]() |
0bf7510bf6 | |
![]() |
2376d8bffd | |
![]() |
bc2f5b8399 | |
![]() |
e90d72185f | |
![]() |
864a0d2f64 | |
![]() |
c4b9fe9ffa | |
![]() |
baaa42e979 | |
![]() |
3a580f7fe0 | |
![]() |
1d44d0f6ee | |
![]() |
25c46d7b90 | |
![]() |
ed2a157cbe | |
![]() |
032cbbbb4a | |
![]() |
225f108fb4 | |
![]() |
477139a7ea | |
![]() |
9b185b8747 | |
![]() |
e15fd801d8 | |
![]() |
a98d5853a3 | |
![]() |
878d4e3449 | |
![]() |
75c3704fe1 | |
![]() |
84a155f383 | |
![]() |
b91a63169f | |
![]() |
5f223cbd26 | |
![]() |
0a02c78010 | |
![]() |
da0bcb2ecf | |
![]() |
d0645ed150 | |
![]() |
9765d0bb6e | |
![]() |
d91f60eb3c | |
![]() |
13af9c223f | |
![]() |
c07d0c6c98 | |
![]() |
8738833ba0 | |
![]() |
1b7b97d612 | |
![]() |
c1e764891c | |
![]() |
4873a44650 | |
![]() |
d6a5f6b87c | |
![]() |
91547fd91a | |
![]() |
4306f991ce | |
![]() |
35393dffe8 | |
![]() |
0475f8357b | |
![]() |
cbb415c051 | |
![]() |
6a5b2ac8e8 | |
![]() |
d932f53567 | |
![]() |
b3bfcfd4db | |
![]() |
141defe55d | |
![]() |
c380d54a1e | |
![]() |
07faeec510 | |
![]() |
dbdc4aae47 | |
![]() |
d88606be0b | |
![]() |
158d977ffc | |
![]() |
abe788b012 | |
![]() |
e4004f0f85 | |
![]() |
355176cee8 | |
![]() |
f2ecf5960b | |
![]() |
3bd426acd0 | |
![]() |
bbe6b209cf | |
![]() |
5fa6a8c5f0 | |
![]() |
3bfbe95223 | |
![]() |
f93654fbd4 | |
![]() |
bf2d8d3b96 | |
![]() |
d2e21c03f1 | |
![]() |
a43b6a0405 | |
![]() |
f5328bda6b | |
![]() |
1facc111ab | |
![]() |
a0187c58d1 | |
![]() |
0f43151219 | |
![]() |
235772fd5a | |
![]() |
060f37d774 | |
![]() |
7d33bbcb00 | |
![]() |
9095d9ac3c | |
![]() |
4ccfd296e6 | |
![]() |
efa6993f3e | |
![]() |
8321a43ca5 | |
![]() |
b0e1f7bf57 | |
![]() |
bdb7b98b94 | |
![]() |
be40fcb28a | |
![]() |
9523f03326 | |
![]() |
dc063dfcbc | |
![]() |
4935cf4df2 | |
![]() |
2c0e87effb | |
![]() |
aeb03b6363 | |
![]() |
9d5d9e6129 | |
![]() |
4a46965d10 | |
![]() |
4769228b8b | |
![]() |
5369015f69 | |
![]() |
b646301f34 | |
![]() |
1d0e807510 | |
![]() |
3dee8b2d8e | |
![]() |
2f4f7e8882 | |
![]() |
e5d726982e | |
![]() |
6692116179 | |
![]() |
46378ada02 | |
![]() |
9199e08bbd | |
![]() |
8008ea363d | |
![]() |
196c27c4c8 | |
![]() |
31dbd40721 | |
![]() |
2e47efc3cd | |
![]() |
81b1894c14 | |
![]() |
8978db6352 | |
![]() |
6094e367da | |
![]() |
b646a9c352 | |
![]() |
9315b535db | |
![]() |
86d48a4e2e | |
![]() |
4eb4b05eff | |
![]() |
519b3644b7 | |
![]() |
91a6497186 | |
![]() |
52467956f0 | |
![]() |
8b1193b11d | |
![]() |
27271f535b | |
![]() |
711602b132 | |
![]() |
ce648e6ed1 | |
![]() |
c0a07551f1 | |
![]() |
c2c2eea57c | |
![]() |
af29321a64 | |
![]() |
22a5a6fca8 | |
![]() |
18f71ce4d7 | |
![]() |
7141e0538a | |
![]() |
de7ddf126b | |
![]() |
007daa50a0 | |
![]() |
e1d0eb36a5 | |
![]() |
4cb47371df | |
![]() |
49823826dd | |
![]() |
5f6e963075 | |
![]() |
9c8b4ba010 | |
![]() |
a94198ee4b | |
![]() |
464a149753 | |
![]() |
2a09cb3444 | |
![]() |
abccb4fa83 | |
![]() |
36bb300302 | |
![]() |
e29e981d10 | |
![]() |
48110aaeb7 | |
![]() |
269e7a3131 | |
![]() |
c7b3d01ca4 | |
![]() |
986c423913 | |
![]() |
d22235abad | |
![]() |
34a8748b58 | |
![]() |
0cf51db552 | |
![]() |
e24c1f3607 | |
![]() |
40682352ae | |
![]() |
b555961512 | |
![]() |
19e5bc8bfc | |
![]() |
dd441f9a1e | |
![]() |
fd6ab2756e | |
![]() |
a48a477b96 | |
![]() |
0695f4a58f | |
![]() |
bd2bdad403 | |
![]() |
739fad3b06 | |
![]() |
b1386a2a34 | |
![]() |
e1e5b43825 | |
![]() |
c99962490c | |
![]() |
a596031f19 | |
![]() |
f36f473af2 | |
![]() |
bcfabf1abe | |
![]() |
3df34fa397 | |
![]() |
a5ecd9a0fa | |
![]() |
ab7a3a387f | |
![]() |
c6518da0bb | |
![]() |
385049f590 | |
![]() |
263b6d7f3e | |
![]() |
5b14bd9051 | |
![]() |
9ca5dd39fe | |
![]() |
0803ef23fc | |
![]() |
be148f8b41 | |
![]() |
d9f883b714 | |
![]() |
e2ae2bf874 | |
![]() |
1d4a241b46 | |
![]() |
b207214aa7 | |
![]() |
3e2213efa6 | |
![]() |
2d2087f287 | |
![]() |
63d8150080 | |
![]() |
4037c455a5 | |
![]() |
7afcc718e1 | |
![]() |
25ddbf9b0b | |
![]() |
7e9e1b2e4e | |
![]() |
07f2e37961 | |
![]() |
ceb2af4bf2 | |
![]() |
6111a2a123 | |
![]() |
8eedb73c6d | |
![]() |
524e228041 | |
![]() |
396c85d25e | |
![]() |
bb4e7fe4bd | |
![]() |
d012b0b20d | |
![]() |
c74e6db415 | |
![]() |
15da113701 | |
![]() |
36985623c5 | |
![]() |
da256f3797 | |
![]() |
d487aae378 | |
![]() |
ce0214333f | |
![]() |
0f0192fa46 | |
![]() |
74d3d8614c | |
![]() |
0cf8015218 | |
![]() |
6a3346c622 | |
![]() |
528095c626 | |
![]() |
d63f15e78a | |
![]() |
40d938818e | |
![]() |
9e59d8fbee | |
![]() |
d43787f7bf | |
![]() |
9478500588 | |
![]() |
5cc3135ed3 | |
![]() |
8ce9bbac6f | |
![]() |
264d3224ce | |
![]() |
7793f5d72d |
|
@ -0,0 +1,67 @@
|
|||
## 简要
|
||||
PSMD改版
|
||||
|
||||
### 模型分类
|
||||
* 第一类:能提供产品的最简模型,尽可能保留普通人的行为模式。
|
||||
* 第二类:提供产品,并战胜第一类的最简模型。
|
||||
* 第三类:不与第一、二类竞争,而是服务于它们、提高它们生存能力。
|
||||
|
||||
PSMD为每类提供一种标准模型,鼓励建模者设计行业专用模型。
|
||||
|
||||
### 区别对待
|
||||
* 鼓励第一类共同体以自己的方式互相帮助。
|
||||
* 以团队委托帮助第二类共同体存活。
|
||||
* 以个人委托帮助个人占据第三类生态位。
|
||||
|
||||
---
|
||||
|
||||
## 配套工作
|
||||
|
||||
### 模型和部署方案
|
||||
PSMD是实践经验的整理、复制、收费的框架。
|
||||
|
||||
部署方案的产生:
|
||||
* 收集共同体所有内部契约、规章,无论是书面、口头、暗示的;
|
||||
* 如果一份文件的效力来自另一份,保留后者、舍弃前者;
|
||||
* 剩余文件所定义的角色,作为核心成员;
|
||||
* 定义核心成员之间权责的文件,舍弃的重新纳入。
|
||||
|
||||
例如:
|
||||
1. 《章程》的效力来自公司法。公司法是外部法律,因此《章程》保留。
|
||||
1. 《董事会议事规则》的效力来自《章程》,会在第二步舍弃,在第四步重新纳入部署方案。
|
||||
|
||||
从部署方案中产生模型:
|
||||
* 名称替换为代号(姓名、地名、机构名称);
|
||||
* 数量替换为代号,保留数量的相互关系(比如倍数);
|
||||
* 出现多种可以互相替换、效果相近的操作时,只提取其共性而忽略差异;
|
||||
|
||||
PSMD要求公布模型,不要求公布部署方案。
|
||||
|
||||
### 资料库与模型库
|
||||
PSMD为模型的设计和销售提供容器。
|
||||
* 对建模者的辅导从创意开始,直到产生可复制使用的模型。
|
||||
* PSMD设计第三类共同体(或个人)为第一、二类共同体提供服务的接口。
|
||||
* PSMD设计建模者为部署者的后续服务接口。
|
||||
* PSMD设计标准委托的服务接口。
|
||||
* 以上接口合并、具体体现为模型的附加条款。
|
||||
* 提交模型的,则成为建模者。
|
||||
* 使用模型的,则成为部署者。
|
||||
|
||||
PSMD整理资料库。
|
||||
不是建模者、部署者的,也可以提问、阅读资料。
|
||||
|
||||
### 标准委托
|
||||
* 标准委托分为团队委托和个人委托,委托接口已植入模型中。
|
||||
* 团队委托:不鼓励升级,只观察内部矛盾的积累程度,告知并定期清理。
|
||||
* 行业内未出现第三类共同体时,鼓励个人占据生态位。接受这些人的委托,支持他们创立第三类共同体。
|
||||
|
||||
### 关于软件
|
||||
PSMD会一直为非程序员提供服务。
|
||||
PSMD自身会逐渐软件化。
|
||||
|
||||
### 开放与透明
|
||||
* 为未来的、未知的工作难点积极准备,舍弃其它竞争方式。
|
||||
* 全部价目和报酬都公开。产品经理以建模者身份提供服务时,同工同酬。
|
||||
* 产品经理召集建模者封闭讨论,单独决定服务接口、附加条款、标准模型。
|
||||
* 所有模型均提供干净版本(不含附加条款),均采用[署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0)](https://creativecommons.org/licenses/by-nc-sa/4.0/)进行许可。部署者可以免费自用。
|
||||
* 部署者主动在模型中加入附加条款,才会接入对应的服务。
|
28
README.md
|
@ -1,15 +1,15 @@
|
|||
##huangyg's Blog
|
||||
|
||||
###2015年末总结
|
||||
* [加密货币与新产品](bitcoin.md)
|
||||
* [共同体](community.md)
|
||||
* [冷启动](clodstart.md)
|
||||
|
||||
###2016
|
||||
* [适应力和资源募集](community.1.md)
|
||||
* [时间接口](timeflow.md)
|
||||
|
||||
版权声明:
|
||||
|
||||
1. 本库作品版权归[黄勇刚](mailto:huangyg@mars22.com)所有。
|
||||
##huangyg's Blog
|
||||
|
||||
###2015年末总结
|
||||
* [加密货币与新产品](bitcoin.md)
|
||||
* [共同体](community.md)
|
||||
* [冷启动](clodstart.md)
|
||||
|
||||
###2016
|
||||
* [适应力和资源募集](community.1.md)
|
||||
* [时间接口](timeflow.md)
|
||||
|
||||
版权声明:
|
||||
|
||||
1. 本库作品版权归[黄勇刚](mailto:huangyg@mars22.com)所有。
|
||||
2. 本库作品采用<a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/4.0/">署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0)</a>进行许可。
|
92
bitcoin.md
|
@ -1,47 +1,47 @@
|
|||
##加密货币与新产品
|
||||
|
||||
比特币和区块链所触及到的瓶颈,每一个突破之后都比它们本身值钱。由于比特币没有原生的升级功能,每个对策都会产生不兼容的新方案。
|
||||
|
||||
###作为支付手段
|
||||
和传统支付相比,比特币有很多优点。但是受区块大小限制,比特币的承载力太低,只能作为小范围的支付手段。
|
||||
|
||||
由于数据量太大,许多节点选择不全部下载,数据会越来越集中在少数企业手里。
|
||||
|
||||
创业者现在设计产品时,嵌入比特币的益处已经越来越小了。
|
||||
|
||||
###作为存储方案
|
||||
许多舞弊的基础都是篡改数据。提高篡改成本,就能提高整体的诚信度。区块链具有优秀的防篡改能力,这也是它的设计目标。如果把区块链单独作为一个存储平台,在征信这些行业的前景很好。同样,区块链作为存储方案的缺点是数据长度小、存储时间不确定。
|
||||
|
||||
把文件的哈希值写入区块链,可以突破数据长度约束,但是需要自己实现扩展协议,这部分很难兼容。
|
||||
|
||||
随着使用者增加,存储难度越来越高,更多存储需求会转向衍生方案。新产品规划时可以直接考虑衍生方案。
|
||||
|
||||
###交易
|
||||
比特币只有发行和支付,而经济活动真正的原子操作是交易。包括和法币的交易,目前也不属于比特币技术协议,而是各交易所自行设计开发。
|
||||
|
||||
在比特币之上增加合同,把支付和合同履行过程绑定起来,这一步的意义超过支付本身。
|
||||
|
||||
软件交付的主要形式验证码,很容易集成到支付之上。实体物品的交付则需要引入仲裁者,这也会产生额外成本。
|
||||
|
||||
新产品规划者应该保持一种基于加密算法、去中心的交付方法。
|
||||
|
||||
###企业
|
||||
企业由一系列持续的交易构成。它是大部分经济活动的主体。
|
||||
|
||||
结合前面提到防篡改、交易,就可以在比特币之上定义企业,并且使这些定义尽可能自动的运行。新模式比传统的工商注册可靠得多,企业运行效率提高,价值也远远超过支付环节的效率提升。
|
||||
|
||||
基层企业创造产品,上级企业创造企业。上升到这个层次的创业者,应该每步工作都保留基于加密算法、去中心的企业定义。
|
||||
|
||||
###升级
|
||||
比特币无中心的设计可以有效避免被少数人把持,但它缺少无中心的升级机制。由少数核心开发者或基金会推动的升级,是有中心的,依然很容易被少数人把持,成为整个方案的薄弱环节。
|
||||
|
||||
无中心的升级很难避免分裂,但是要保证分裂后的币种可以交易。而且与普通货物交易机制不同,才能防止投机。
|
||||
|
||||
加密货币、无中心存储、交易、企业都需要无中心的升级方案,这个突破决定整体的活力。
|
||||
|
||||
|
||||
|
||||
###小结
|
||||
加密货币出现的背景是法币发行机制不够透明。它打开一扇窗,但并没有能走出多远。作为支付手段的应用不会太广,但它为无中心的交易、企业提供了关键的技术思路,这是它真正的历史意义。
|
||||
|
||||
##加密货币与新产品
|
||||
|
||||
比特币和区块链所触及到的瓶颈,每一个突破之后都比它们本身值钱。由于比特币没有原生的升级功能,每个对策都会产生不兼容的新方案。
|
||||
|
||||
###作为支付手段
|
||||
和传统支付相比,比特币有很多优点。但是受区块大小限制,比特币的承载力太低,只能作为小范围的支付手段。
|
||||
|
||||
由于数据量太大,许多节点选择不全部下载,数据会越来越集中在少数企业手里。
|
||||
|
||||
创业者现在设计产品时,嵌入比特币的益处已经越来越小了。
|
||||
|
||||
###作为存储方案
|
||||
许多舞弊的基础都是篡改数据。提高篡改成本,就能提高整体的诚信度。区块链具有优秀的防篡改能力,这也是它的设计目标。如果把区块链单独作为一个存储平台,在征信这些行业的前景很好。同样,区块链作为存储方案的缺点是数据长度小、存储时间不确定。
|
||||
|
||||
把文件的哈希值写入区块链,可以突破数据长度约束,但是需要自己实现扩展协议,这部分很难兼容。
|
||||
|
||||
随着使用者增加,存储难度越来越高,更多存储需求会转向衍生方案。新产品规划时可以直接考虑衍生方案。
|
||||
|
||||
###交易
|
||||
比特币只有发行和支付,而经济活动真正的原子操作是交易。包括和法币的交易,目前也不属于比特币技术协议,而是各交易所自行设计开发。
|
||||
|
||||
在比特币之上增加合同,把支付和合同履行过程绑定起来,这一步的意义超过支付本身。
|
||||
|
||||
软件交付的主要形式验证码,很容易集成到支付之上。实体物品的交付则需要引入仲裁者,这也会产生额外成本。
|
||||
|
||||
新产品规划者应该保持一种基于加密算法、去中心的交付方法。
|
||||
|
||||
###企业
|
||||
企业由一系列持续的交易构成。它是大部分经济活动的主体。
|
||||
|
||||
结合前面提到防篡改、交易,就可以在比特币之上定义企业,并且使这些定义尽可能自动的运行。新模式比传统的工商注册可靠得多,企业运行效率提高,价值也远远超过支付环节的效率提升。
|
||||
|
||||
基层企业创造产品,上级企业创造企业。上升到这个层次的创业者,应该每步工作都保留基于加密算法、去中心的企业定义。
|
||||
|
||||
###升级
|
||||
比特币无中心的设计可以有效避免被少数人把持,但它缺少无中心的升级机制。由少数核心开发者或基金会推动的升级,是有中心的,依然很容易被少数人把持,成为整个方案的薄弱环节。
|
||||
|
||||
无中心的升级很难避免分裂,但是要保证分裂后的币种可以交易。而且与普通货物交易机制不同,才能防止投机。
|
||||
|
||||
加密货币、无中心存储、交易、企业都需要无中心的升级方案,这个突破决定整体的活力。
|
||||
|
||||
|
||||
|
||||
###小结
|
||||
加密货币出现的背景是法币发行机制不够透明。它打开一扇窗,但并没有能走出多远。作为支付手段的应用不会太广,但它为无中心的交易、企业提供了关键的技术思路,这是它真正的历史意义。
|
||||
|
||||
一旦无中心的企业诞生,加密货币(以及无中心软件们)就得到了一个新的发展基点。那里才会有新一代的货币。
|
|
@ -1,27 +1,27 @@
|
|||
##更新密钥
|
||||
密钥托管 设计笔记
|
||||
|
||||
服务器以HTTP接口提供密钥托管服务,其中PUT方法是更新密钥,通常用于修改口令。维护状态会引入额外的复杂性,因此希望是一次性的调用。
|
||||
|
||||
浏览器通过GET方法获得加密的密钥,然后用户输入口令,在浏览器直接加盐取哈希解密。这时候,规定一段特定内容作为验证码,用户对验证码进行数字签名,与更新的密钥PUT给服务器。我们需要讨论的是这个验证码的设计。
|
||||
|
||||
我们必须假设网络通信是:
|
||||
|
||||
* 可以监听的:攻击者可以获得这特定内容及其数字签名。
|
||||
* 可以截断的:服务器和浏览器发给对方的内容,接收方不能收到。
|
||||
* 可以篡改的:服务器和浏览器发给对方的内容,接收前会被改变。
|
||||
|
||||
假设监听是永久的,攻击者不能永久地截断和篡改。在这种情况下,攻击者无法通过更新密钥伪造用户的数字签名。
|
||||
|
||||
一次性的调用,要求这验证码是无需协商的,浏览器端就可以生成,而服务器端可以验证。如果接受任意内容作为验证码,用户在日常使用中提供的数字签名,会被攻击者用作验证码去更换密钥。
|
||||
|
||||
在简单对比各种选择后,以整个新密钥(yaml结构)作为验证码是目前最佳方案。
|
||||
|
||||
* name
|
||||
* id
|
||||
* email
|
||||
* salt:盐
|
||||
* pubkey:公钥
|
||||
* secpey:私钥
|
||||
|
||||
##更新密钥
|
||||
密钥托管 设计笔记
|
||||
|
||||
服务器以HTTP接口提供密钥托管服务,其中PUT方法是更新密钥,通常用于修改口令。维护状态会引入额外的复杂性,因此希望是一次性的调用。
|
||||
|
||||
浏览器通过GET方法获得加密的密钥,然后用户输入口令,在浏览器直接加盐取哈希解密。这时候,规定一段特定内容作为验证码,用户对验证码进行数字签名,与更新的密钥PUT给服务器。我们需要讨论的是这个验证码的设计。
|
||||
|
||||
我们必须假设网络通信是:
|
||||
|
||||
* 可以监听的:攻击者可以获得这特定内容及其数字签名。
|
||||
* 可以截断的:服务器和浏览器发给对方的内容,接收方不能收到。
|
||||
* 可以篡改的:服务器和浏览器发给对方的内容,接收前会被改变。
|
||||
|
||||
假设监听是永久的,攻击者不能永久地截断和篡改。在这种情况下,攻击者无法通过更新密钥伪造用户的数字签名。
|
||||
|
||||
一次性的调用,要求这验证码是无需协商的,浏览器端就可以生成,而服务器端可以验证。如果接受任意内容作为验证码,用户在日常使用中提供的数字签名,会被攻击者用作验证码去更换密钥。
|
||||
|
||||
在简单对比各种选择后,以整个新密钥(yaml结构)作为验证码是目前最佳方案。
|
||||
|
||||
* name
|
||||
* id
|
||||
* email
|
||||
* salt:盐
|
||||
* pubkey:公钥
|
||||
* secpey:私钥
|
||||
|
||||
首先,它是服务器和用户浏览器无需额外通信就可以达成一致的。其次,日常应用不会对同类数据进行数字签名,攻击者无从提前准备。如果攻击者获得更新信息并截断通信,也无法伪造另一套密钥发给服务器。一旦用户重新与服务器联通,可以再次发送正确的更新信息,攻击者除了截断通信外没有获得额外好处。
|
142
community.1.md
|
@ -1,72 +1,72 @@
|
|||
##共同体
|
||||
适应力和资源募集
|
||||
|
||||
共同体需要不断重组以适应外界变化。常见的安排是两层机制:决策机构制定基本管理制度、发布决议,执行团队制定具体规章、下达指令。具体规章、执行指令不得违反基本管理制度、决议,从而在获得适应力的同时,也防止执行团队舞弊。
|
||||
|
||||

|
||||
|
||||
募集资源有许多方式:以现有资源交换的成本较高,以权力交换的风险较高,而以未来收入换取资源则没有这些缺点,但资源投入方的未兑现利益需要强有力的保护,尤其不能在重组时被牺牲。
|
||||
|
||||

|
||||
|
||||
###规章的修订
|
||||
一般来说,员工依赖五类信息决定自己的行为:
|
||||
|
||||
* 历史经验(个人经验或非正式的指导)
|
||||
* 直接指令
|
||||
* 具体规章
|
||||
* 决策部门决议
|
||||
* 基本管理制度
|
||||
|
||||
它们需要不断修订以适应外界情况,消除内部矛盾。
|
||||
|
||||
只要在五种信息互相矛盾时成员清楚怎么应对,零规章起步是可以实现的。部署初期可以完全通过指令管理,执行团队不定期整理记录,把重复性的指令整理为具体规章。当执行团队由于能力或利益局限出现偏差,决策部门颁布决议和基本管理制度。一开始整理周期比较频密,稳定后可以逐渐拉长,在外界条件急剧变化时可以再次提高频率。
|
||||
|
||||
产品和服务是很容易参考(抄袭)的,规章的修订能力则较难复制。优秀的产品经理可以带来一定的独占期,优秀的决策部门则意味着持续的竞争优势。独占是无法持久的,竞争中获胜才是赢家。
|
||||
|
||||
决策者和其他成员一样,在计时模式下松懈、保守,在考核数量和质量时勇于拼搏。要组建优秀的决策部门,建模者应该设立明确的结果验收和大幅度的奖惩。良性竞争的决策部门、明确指令优先级的成员,可以纯指令、零规章启动,逐步建立竞争优势。
|
||||
|
||||
###常见的募集方法
|
||||
以未来收入换取资源的难点在于控制(分配前的)支出。要保障资源投入方的未兑现利益,这些支出应控制在经营必须的水平上。控制方法有两种:把权力直接交给资源投入方;或设计一种难以违反的预算制度。两种方法都可能削弱竞争力,资源投入方的决策质量低下,预算制度缺乏弹性。
|
||||
|
||||
公司以股份募集资源,它是滞后利益与权力相结合的产物。相应的,缺乏判断力的股东是公司的最大隐患。合伙企业、合作社企业的权力归合伙人、社员,他们以高度透明的规章保障资源投入方的利益,而力图保留权力。在技术密集型的公司里,智力投入者通常控制大部分股份,它们接近于合伙企业 -- 需要以高质量的规章换取资金等资源投入。
|
||||
|
||||
当国内法(包括企业法规、会计制度...)所能保障的最高透明度仍然不能满足需要,共同体需要设计更高标准的规章,否则资源拥有者会要求优先兑现。优先级最高时就是从收入直接兑现,前面不安排任何支出,因而也不需要参与支出控制。
|
||||
|
||||
收支数额的核实也有许多种情况,数据公布的人员范围有:
|
||||
|
||||
* 全面开放,从内部成员、资源投入方到竞争对手,均可查阅。
|
||||
* 只对未兑现利益的资源投入方开放,除了“未兑现利益”外不设置额外条件。
|
||||
* 介于以上两个极端之间,核实者范围越大,执行团队舞弊难度越高。
|
||||
|
||||
发布方式:
|
||||
|
||||
* 收支发生时发布数额
|
||||
* 滞后发布数额:收支发生时发布数字摘要,滞后一定时间发布详细数据
|
||||
|
||||
如果规则清晰到各方独立计算、结果严格一致,而且执行环节不受任何一方控制,可以用公布规则代替公布支出数额。这时,规章设计与收支核实是一体的。同样有两种实现方法:
|
||||
|
||||
* 规则制定后发布内容
|
||||
* 滞后发布:规则制定后发布数字摘要,失效后发布详细内容
|
||||
|
||||
以上提及的发布方式,应该是共同体所无法删改的。至少是删改成本高于资源投入方未兑现利益的。
|
||||
另外,把监事和财务人员的人事权交给资源投入方也是常见的安排。
|
||||
|
||||
###两种能力的矛盾
|
||||
规章除了组织协作以外也要规定分配。规章修订就意味着分配规则的变化。
|
||||
而资源募集需要保障资源投入方的未兑现利益。
|
||||
|
||||
平衡这两种能力的矛盾是建模者的核心工作之一。
|
||||
|
||||
资金密集型公司通常牺牲适应力换取资源。技术密集型公司、合伙企业、合作社企业如果拥有优秀的决策部门,可以优越的制度吸引资源,保障资源投入方而不丧失权力;否则并没有优势。
|
||||
|
||||
一些更新颖的做法,实质上是以决策层管理模型作为募集主体:
|
||||
|
||||
* 决策部门公开招募、择优录用、严格淘汰,其人力资源纳入统一的资源募集接口;
|
||||
* 包括执行团队在内的所有利益回报纳入统一利益分配规则,逐步兑现;
|
||||
|
||||
既不以现有资源换取资源,也不以权力换取资源,仅仅按照能力聘任决策者。而决策部门、执行部门的利益与资源投入者使用统一的分配规则,不能分割因而难以单方面违约。这样的机制才能同时保证两种能力优势。
|
||||
|
||||

|
||||
|
||||
##共同体
|
||||
适应力和资源募集
|
||||
|
||||
共同体需要不断重组以适应外界变化。常见的安排是两层机制:决策机构制定基本管理制度、发布决议,执行团队制定具体规章、下达指令。具体规章、执行指令不得违反基本管理制度、决议,从而在获得适应力的同时,也防止执行团队舞弊。
|
||||
|
||||

|
||||
|
||||
募集资源有许多方式:以现有资源交换的成本较高,以权力交换的风险较高,而以未来收入换取资源则没有这些缺点,但资源投入方的未兑现利益需要强有力的保护,尤其不能在重组时被牺牲。
|
||||
|
||||

|
||||
|
||||
###规章的修订
|
||||
一般来说,员工依赖五类信息决定自己的行为:
|
||||
|
||||
* 历史经验(个人经验或非正式的指导)
|
||||
* 直接指令
|
||||
* 具体规章
|
||||
* 决策部门决议
|
||||
* 基本管理制度
|
||||
|
||||
它们需要不断修订以适应外界情况,消除内部矛盾。
|
||||
|
||||
只要在五种信息互相矛盾时成员清楚怎么应对,零规章起步是可以实现的。部署初期可以完全通过指令管理,执行团队不定期整理记录,把重复性的指令整理为具体规章。当执行团队由于能力或利益局限出现偏差,决策部门颁布决议和基本管理制度。一开始整理周期比较频密,稳定后可以逐渐拉长,在外界条件急剧变化时可以再次提高频率。
|
||||
|
||||
产品和服务是很容易参考(抄袭)的,规章的修订能力则较难复制。优秀的产品经理可以带来一定的独占期,优秀的决策部门则意味着持续的竞争优势。独占是无法持久的,竞争中获胜才是赢家。
|
||||
|
||||
决策者和其他成员一样,在计时模式下松懈、保守,在考核数量和质量时勇于拼搏。要组建优秀的决策部门,建模者应该设立明确的结果验收和大幅度的奖惩。良性竞争的决策部门、明确指令优先级的成员,可以纯指令、零规章启动,逐步建立竞争优势。
|
||||
|
||||
###常见的募集方法
|
||||
以未来收入换取资源的难点在于控制(分配前的)支出。要保障资源投入方的未兑现利益,这些支出应控制在经营必须的水平上。控制方法有两种:把权力直接交给资源投入方;或设计一种难以违反的预算制度。两种方法都可能削弱竞争力,资源投入方的决策质量低下,预算制度缺乏弹性。
|
||||
|
||||
公司以股份募集资源,它是滞后利益与权力相结合的产物。相应的,缺乏判断力的股东是公司的最大隐患。合伙企业、合作社企业的权力归合伙人、社员,他们以高度透明的规章保障资源投入方的利益,而力图保留权力。在技术密集型的公司里,智力投入者通常控制大部分股份,它们接近于合伙企业 -- 需要以高质量的规章换取资金等资源投入。
|
||||
|
||||
当国内法(包括企业法规、会计制度...)所能保障的最高透明度仍然不能满足需要,共同体需要设计更高标准的规章,否则资源拥有者会要求优先兑现。优先级最高时就是从收入直接兑现,前面不安排任何支出,因而也不需要参与支出控制。
|
||||
|
||||
收支数额的核实也有许多种情况,数据公布的人员范围有:
|
||||
|
||||
* 全面开放,从内部成员、资源投入方到竞争对手,均可查阅。
|
||||
* 只对未兑现利益的资源投入方开放,除了“未兑现利益”外不设置额外条件。
|
||||
* 介于以上两个极端之间,核实者范围越大,执行团队舞弊难度越高。
|
||||
|
||||
发布方式:
|
||||
|
||||
* 收支发生时发布数额
|
||||
* 滞后发布数额:收支发生时发布数字摘要,滞后一定时间发布详细数据
|
||||
|
||||
如果规则清晰到各方独立计算、结果严格一致,而且执行环节不受任何一方控制,可以用公布规则代替公布支出数额。这时,规章设计与收支核实是一体的。同样有两种实现方法:
|
||||
|
||||
* 规则制定后发布内容
|
||||
* 滞后发布:规则制定后发布数字摘要,失效后发布详细内容
|
||||
|
||||
以上提及的发布方式,应该是共同体所无法删改的。至少是删改成本高于资源投入方未兑现利益的。
|
||||
另外,把监事和财务人员的人事权交给资源投入方也是常见的安排。
|
||||
|
||||
###两种能力的矛盾
|
||||
规章除了组织协作以外也要规定分配。规章修订就意味着分配规则的变化。
|
||||
而资源募集需要保障资源投入方的未兑现利益。
|
||||
|
||||
平衡这两种能力的矛盾是建模者的核心工作之一。
|
||||
|
||||
资金密集型公司通常牺牲适应力换取资源。技术密集型公司、合伙企业、合作社企业如果拥有优秀的决策部门,可以优越的制度吸引资源,保障资源投入方而不丧失权力;否则并没有优势。
|
||||
|
||||
一些更新颖的做法,实质上是以决策层管理模型作为募集主体:
|
||||
|
||||
* 决策部门公开招募、择优录用、严格淘汰,其人力资源纳入统一的资源募集接口;
|
||||
* 包括执行团队在内的所有利益回报纳入统一利益分配规则,逐步兑现;
|
||||
|
||||
既不以现有资源换取资源,也不以权力换取资源,仅仅按照能力聘任决策者。而决策部门、执行部门的利益与资源投入者使用统一的分配规则,不能分割因而难以单方面违约。这样的机制才能同时保证两种能力优势。
|
||||
|
||||

|
||||
|
||||
这些做法需要新的基础设施,国内法及行政管理很难表达这些模型。
|
114
community.md
|
@ -1,57 +1,57 @@
|
|||
##共同体
|
||||
建模和部署
|
||||
|
||||
大部分创业者创立企业,也有少数的创立非盈利组织。此外还有许多协作形式,严谨起见这里统称为“共同体”。它们有不少共通之处,所以一并讨论。
|
||||
|
||||
###指令->规章
|
||||
共同体成员依据什么协作?主要有两种依据:
|
||||
|
||||
1. 规章:事前分发好的规章,规定了什么情况下采取什么行动。
|
||||
2. 指令:由指定的上级发出指令。严格说,定义上下级关系也是规章的一部分。
|
||||
|
||||
显然,指令的质量更低、成本更高、隐患更多。但规章永远不可能尽善尽美,凡是规章没有考虑到的情形,还是需要由人工指令推动。
|
||||
|
||||
管理团队的一项重要工作,就是把指令转化为规章,以提高共同体运行的质量、降低成本、减少隐患,当然这是滞后一段时间的。这个指令转化为规章的过程,往往决定共同体存亡。因为产品领先是暂时的,对手可以抄袭模仿,但经营这个产品的效率,决定谁能笑到最后。一个有经验的管理团队,只有看到规章对产品的支撑优于于对手,才能安睡。
|
||||
|
||||
创业者的一项重要工作,就是规定管理团队以什么时间间隔、按什么质量要求,完成[指令->规章]这项关键任务。并且设定合理的检查和奖惩,迫使他们认真对待。一个有经验的创业者,只有看到己方的[指令->规章]能力领先于对手,才能安睡。
|
||||
|
||||
这些规定有多种载体,可以写在章程备案到政府部门,可以写成多方合同各执一份,还可以写成源代码...我们把其中的关键结构提取出来,建立数学模型,就可以研究它们的本质。
|
||||
|
||||
###评价标准
|
||||
我们拿到一个共同体的数学模型,怎么评价它的性能呢?
|
||||
|
||||
我常用三个标准,照见一个共同体模型的质量:
|
||||
|
||||
1. 运行中有哪些人工裁量环节,列出来,由重到轻(到无)大致排序,从核心到外围的监督和奖惩力度应该是递降坡度。
|
||||
2. 权利分配的自适应能力:
|
||||
1. 职权能够跟随能力、承诺变化而不断调整;
|
||||
2. 利益能够根据贡献变化不断调整。
|
||||
3. 滞后兑现的利益,都安排了有效的保护措施。
|
||||
|
||||
不认可这些标准的人很少。但在工作中真正使用这些标准的人,也很少。
|
||||
|
||||
比如很多新手抱怨:“贡献根本不可能量化”。其实他们只要发工资,就已经量化了。因为工资就是一个量化的数字,不给数字出纳没法执行。按月发固定工资永远不变,也量化了。不定期由老板发不定量的红包,也是个量化过程。他们不是没有量化,是量化的质量差,是改进的过程被阻断了。
|
||||
|
||||
要提升质量,当然就要明确模型,接受质量评价,然后接受更优的方案(即使不是最优)。很多创业者在明确模型这一步都停下来了,然后以改进方案不是最优为由,停在原地。结果就是这个共同体只有外围在运行,核心停转。很多创业者以为只要做出一个产品就赢了,其实就是这种状况。
|
||||
|
||||
其实只要时不时拿出这些标准,照一下。就知道共同体的核心人员,做了多少工作,又漏了多少工作。
|
||||
|
||||
再拿这个标准向外照一照,就能判断其它共同体,最终能做到什么位置。就像生物学家看一副骨骼化石,就能判定生物的生态位。
|
||||
|
||||
###生态位
|
||||
用这标准看看常见的企业种类,最低级是股份制的公司,好一点的是合伙企业,再好一点是合作社企业。而它们都已经不能适应现在的工作需要。
|
||||
|
||||
大量的人才被压抑在低质量的模型中,专业能力在职业生涯的前段就达到了巅峰,再也无法提升。
|
||||
|
||||
从历史可以看出,由国家主导的企业种类研发,原创是以百年为周期的,模仿也需要十年数量级。一旦研发成功,就会立法并下达工商执行,这些企业可以在银行开设对公账户。创业者借助这些框架,大大降低了建模的难度。
|
||||
|
||||
而民间可以用多方合同创造新的合作模型,要素完整的话也可以运行得很好。因为不使用国家的研发成果、配套服务,还可以不交企业所得税。但普通人受知识和精力所限,很难完成真正的原创。
|
||||
|
||||
异军突起的是程序员。他们具备数学建模的基础知识,而工作结果在设备中高速运行检验,无疑是一种严格的训练。如果只是在数学模型层次看,不知不觉之间,程序员们实际上已经拥有了超过国家的制度研发能力。他们缺少的,是把模型部署的知识。
|
||||
|
||||
一旦程序员们学会怎么部署一个共同体,这个群体将以月的周期不断产生原创模型。而且他们部署的共同体将占据生态系统的顶部,因为它们的模型质量远远超过非程序员所能设计的,事实上是后者无法理解的。
|
||||
|
||||
这场生态危机怎么发动、怎么进行,我要在其中完成什么使命。这是顶级程序员目前正在思考的问题,而其中一些人的行动已经开始。
|
||||
|
||||
###部署
|
||||
程序员们可以量产共同体的数学模型,而这些模型的部署就是风口。
|
||||
##共同体
|
||||
建模和部署
|
||||
|
||||
大部分创业者创立企业,也有少数的创立非盈利组织。此外还有许多协作形式,严谨起见这里统称为“共同体”。它们有不少共通之处,所以一并讨论。
|
||||
|
||||
###指令->规章
|
||||
共同体成员依据什么协作?主要有两种依据:
|
||||
|
||||
1. 规章:事前分发好的规章,规定了什么情况下采取什么行动。
|
||||
2. 指令:由指定的上级发出指令。严格说,定义上下级关系也是规章的一部分。
|
||||
|
||||
显然,指令的质量更低、成本更高、隐患更多。但规章永远不可能尽善尽美,凡是规章没有考虑到的情形,还是需要由人工指令推动。
|
||||
|
||||
管理团队的一项重要工作,就是把指令转化为规章,以提高共同体运行的质量、降低成本、减少隐患,当然这是滞后一段时间的。这个指令转化为规章的过程,往往决定共同体存亡。因为产品领先是暂时的,对手可以抄袭模仿,但经营这个产品的效率,决定谁能笑到最后。一个有经验的管理团队,只有看到规章对产品的支撑优于于对手,才能安睡。
|
||||
|
||||
创业者的一项重要工作,就是规定管理团队以什么时间间隔、按什么质量要求,完成[指令->规章]这项关键任务。并且设定合理的检查和奖惩,迫使他们认真对待。一个有经验的创业者,只有看到己方的[指令->规章]能力领先于对手,才能安睡。
|
||||
|
||||
这些规定有多种载体,可以写在章程备案到政府部门,可以写成多方合同各执一份,还可以写成源代码...我们把其中的关键结构提取出来,建立数学模型,就可以研究它们的本质。
|
||||
|
||||
###评价标准
|
||||
我们拿到一个共同体的数学模型,怎么评价它的性能呢?
|
||||
|
||||
我常用三个标准,照见一个共同体模型的质量:
|
||||
|
||||
1. 运行中有哪些人工裁量环节,列出来,由重到轻(到无)大致排序,从核心到外围的监督和奖惩力度应该是递降坡度。
|
||||
2. 权利分配的自适应能力:
|
||||
1. 职权能够跟随能力、承诺变化而不断调整;
|
||||
2. 利益能够根据贡献变化不断调整。
|
||||
3. 滞后兑现的利益,都安排了有效的保护措施。
|
||||
|
||||
不认可这些标准的人很少。但在工作中真正使用这些标准的人,也很少。
|
||||
|
||||
比如很多新手抱怨:“贡献根本不可能量化”。其实他们只要发工资,就已经量化了。因为工资就是一个量化的数字,不给数字出纳没法执行。按月发固定工资永远不变,也量化了。不定期由老板发不定量的红包,也是个量化过程。他们不是没有量化,是量化的质量差,是改进的过程被阻断了。
|
||||
|
||||
要提升质量,当然就要明确模型,接受质量评价,然后接受更优的方案(即使不是最优)。很多创业者在明确模型这一步都停下来了,然后以改进方案不是最优为由,停在原地。结果就是这个共同体只有外围在运行,核心停转。很多创业者以为只要做出一个产品就赢了,其实就是这种状况。
|
||||
|
||||
其实只要时不时拿出这些标准,照一下。就知道共同体的核心人员,做了多少工作,又漏了多少工作。
|
||||
|
||||
再拿这个标准向外照一照,就能判断其它共同体,最终能做到什么位置。就像生物学家看一副骨骼化石,就能判定生物的生态位。
|
||||
|
||||
###生态位
|
||||
用这标准看看常见的企业种类,最低级是股份制的公司,好一点的是合伙企业,再好一点是合作社企业。而它们都已经不能适应现在的工作需要。
|
||||
|
||||
大量的人才被压抑在低质量的模型中,专业能力在职业生涯的前段就达到了巅峰,再也无法提升。
|
||||
|
||||
从历史可以看出,由国家主导的企业种类研发,原创是以百年为周期的,模仿也需要十年数量级。一旦研发成功,就会立法并下达工商执行,这些企业可以在银行开设对公账户。创业者借助这些框架,大大降低了建模的难度。
|
||||
|
||||
而民间可以用多方合同创造新的合作模型,要素完整的话也可以运行得很好。因为不使用国家的研发成果、配套服务,还可以不交企业所得税。但普通人受知识和精力所限,很难完成真正的原创。
|
||||
|
||||
异军突起的是程序员。他们具备数学建模的基础知识,而工作结果在设备中高速运行检验,无疑是一种严格的训练。如果只是在数学模型层次看,不知不觉之间,程序员们实际上已经拥有了超过国家的制度研发能力。他们缺少的,是把模型部署的知识。
|
||||
|
||||
一旦程序员们学会怎么部署一个共同体,这个群体将以月的周期不断产生原创模型。而且他们部署的共同体将占据生态系统的顶部,因为它们的模型质量远远超过非程序员所能设计的,事实上是后者无法理解的。
|
||||
|
||||
这场生态危机怎么发动、怎么进行,我要在其中完成什么使命。这是顶级程序员目前正在思考的问题,而其中一些人的行动已经开始。
|
||||
|
||||
###部署
|
||||
程序员们可以量产共同体的数学模型,而这些模型的部署就是风口。
|
||||
|
|
|
@ -1,18 +1,18 @@
|
|||
http://blog.sina.com.cn/s/blog_591ac304010009nu.html
|
||||
|
||||
“中学生学习时间分配”网络调研【二】 (2007-07-18 11:18:48)
|
||||
|
||||
调研的入口地址是:http://www.my3q.com/go.php?url=mars22/xuemen
|
||||
|
||||
下面是最新的几项统计结果:
|
||||
一、在课堂上进度、深度适中的时间比例为:44.67%(过快过难:17.47%,过慢过浅:37.86%)
|
||||
二、在作业中难度适中的题目比例平均为:38.34%(过难:22.73%,过易:38.93)
|
||||
三、在考试中平均有26.13%的分数是努力争取的关键(过难而放弃努力:15.87%,过易且肯定拿分:58%)
|
||||
四、有60%的同学的学习资料根本看不完,提升成绩的障碍主要是资料以外问题。
|
||||
五、有53.3%的同学一直大量做题,但考试时看到碰过的题还是容易丢分。
|
||||
六、有53.8%的同学在考场检查时无法缩小重点范围,浪费了宝贵的时间。
|
||||
|
||||
可以看到全班统一的课堂和课后作业,往往难以保证每个孩子的“吸收率”。而家庭安排的学习虽然内容丰盛,但是效果不佳,孩子最需要熟练的关键点(每人不同)得不到重点关照。部分最优秀的学生有能力排查划定自己的关键知识点,大部分同学还是采用“漫灌式”的练习模式,造成效率低下。
|
||||
由于难以改变学校教学安排,合理的方法是提升家庭学习中的有效率,使学习内容、深度符合孩子特定需要。家庭教育内容的有效比例完全可以提升到80%以上,只留出少量时间攻克重点困难,温习已牢固的内容。
|
||||
|
||||
学门科技在暑假中继续进行教育实验,欢迎更多的家长、同学、老师参与,一起体验“高吸收率”的“按需教育”。
|
||||
http://blog.sina.com.cn/s/blog_591ac304010009nu.html
|
||||
|
||||
“中学生学习时间分配”网络调研【二】 (2007-07-18 11:18:48)
|
||||
|
||||
调研的入口地址是:http://www.my3q.com/go.php?url=mars22/xuemen
|
||||
|
||||
下面是最新的几项统计结果:
|
||||
一、在课堂上进度、深度适中的时间比例为:44.67%(过快过难:17.47%,过慢过浅:37.86%)
|
||||
二、在作业中难度适中的题目比例平均为:38.34%(过难:22.73%,过易:38.93)
|
||||
三、在考试中平均有26.13%的分数是努力争取的关键(过难而放弃努力:15.87%,过易且肯定拿分:58%)
|
||||
四、有60%的同学的学习资料根本看不完,提升成绩的障碍主要是资料以外问题。
|
||||
五、有53.3%的同学一直大量做题,但考试时看到碰过的题还是容易丢分。
|
||||
六、有53.8%的同学在考场检查时无法缩小重点范围,浪费了宝贵的时间。
|
||||
|
||||
可以看到全班统一的课堂和课后作业,往往难以保证每个孩子的“吸收率”。而家庭安排的学习虽然内容丰盛,但是效果不佳,孩子最需要熟练的关键点(每人不同)得不到重点关照。部分最优秀的学生有能力排查划定自己的关键知识点,大部分同学还是采用“漫灌式”的练习模式,造成效率低下。
|
||||
由于难以改变学校教学安排,合理的方法是提升家庭学习中的有效率,使学习内容、深度符合孩子特定需要。家庭教育内容的有效比例完全可以提升到80%以上,只留出少量时间攻克重点困难,温习已牢固的内容。
|
||||
|
||||
学门科技在暑假中继续进行教育实验,欢迎更多的家长、同学、老师参与,一起体验“高吸收率”的“按需教育”。
|
||||
|
|
|
@ -1,18 +1,18 @@
|
|||
http://blog.sina.com.cn/s/blog_591ac304010009mt.html
|
||||
|
||||
“中学生学习时间分配”网络调研 (2007-07-15 15:44:27)
|
||||
|
||||
大家好,我们正在进行一项调研,主题是:“中学生学习时间分配”,欢迎广大家长和同学参加。学门科技将为参与调研的同学定制学习规划,帮助同学在不增加学习时间的前提下改善学习效果。
|
||||
|
||||
调研的入口地址是:http://www.my3q.com/go.php?url=mars22/xuemen
|
||||
|
||||
下面是目前数据的几项统计结果:
|
||||
在课堂上进度、深度适中的时间比例为:49.82%(过快过难:17.45%,过慢过浅:32.73%)
|
||||
在作业中难度适中的题目比例平均为:43.73%(过难:21.82%,过易:34.45)
|
||||
在考试中平均有27.91%的分数是努力争取的关键(过难而放弃努力:15.73%,过易且肯定拿分:56.36%)
|
||||
|
||||
换句话说,统一的课堂和课后作业对特定学生而言,有一半以上是低效率的,如果为每位同学定制学习计划,增加难度、内容适合他的内容,学习效果有很大的提升潜力。
|
||||
根据五六月份的实践结果,一名有经验的老教师仅仅根据同学的作业本和考卷划定他的复习重点,准确度可以达到65~75%。
|
||||
根据最近两届eokdd教育测评比赛的结果看,自动软件对学生知识漏洞的判断准确度达到85%以上,最高(千人组)数据包的准确度达到97%。
|
||||
|
||||
http://blog.sina.com.cn/s/blog_591ac304010009mt.html
|
||||
|
||||
“中学生学习时间分配”网络调研 (2007-07-15 15:44:27)
|
||||
|
||||
大家好,我们正在进行一项调研,主题是:“中学生学习时间分配”,欢迎广大家长和同学参加。学门科技将为参与调研的同学定制学习规划,帮助同学在不增加学习时间的前提下改善学习效果。
|
||||
|
||||
调研的入口地址是:http://www.my3q.com/go.php?url=mars22/xuemen
|
||||
|
||||
下面是目前数据的几项统计结果:
|
||||
在课堂上进度、深度适中的时间比例为:49.82%(过快过难:17.45%,过慢过浅:32.73%)
|
||||
在作业中难度适中的题目比例平均为:43.73%(过难:21.82%,过易:34.45)
|
||||
在考试中平均有27.91%的分数是努力争取的关键(过难而放弃努力:15.73%,过易且肯定拿分:56.36%)
|
||||
|
||||
换句话说,统一的课堂和课后作业对特定学生而言,有一半以上是低效率的,如果为每位同学定制学习计划,增加难度、内容适合他的内容,学习效果有很大的提升潜力。
|
||||
根据五六月份的实践结果,一名有经验的老教师仅仅根据同学的作业本和考卷划定他的复习重点,准确度可以达到65~75%。
|
||||
根据最近两届eokdd教育测评比赛的结果看,自动软件对学生知识漏洞的判断准确度达到85%以上,最高(千人组)数据包的准确度达到97%。
|
||||
|
||||
可见无论通过教师,还是通过软件,都可以有效地提高学习计划的效率,使学习时间聚焦在学生最需要的内容上。
|
|
@ -1,16 +1,16 @@
|
|||
http://blog.sina.com.cn/s/blog_591ac304010009v8.html
|
||||
|
||||
“中学生学习时间分配”网络调研【三】 (2007-07-30 20:14:25)
|
||||
|
||||
调研的入口地址是:http://www.my3q.com/go.php?url=mars22/xuemen
|
||||
|
||||
调研结果:
|
||||
22.80%--在课堂上进度过快,或者深度过深的时间
|
||||
42.61%--在课堂上进度过慢,或者深度过浅的时间
|
||||
31.04%--在作业中难度过高的的题目占做题时间
|
||||
41.83%--在作业中难度过低的的题目占做题时间
|
||||
课堂上进度深度适中时间为34.59%
|
||||
作业难度适中时间为27.13%。
|
||||
|
||||
62.5%:我的学习资料根本看不完,学习资料并不是我提升成绩的障碍。
|
||||
http://blog.sina.com.cn/s/blog_591ac304010009v8.html
|
||||
|
||||
“中学生学习时间分配”网络调研【三】 (2007-07-30 20:14:25)
|
||||
|
||||
调研的入口地址是:http://www.my3q.com/go.php?url=mars22/xuemen
|
||||
|
||||
调研结果:
|
||||
22.80%--在课堂上进度过快,或者深度过深的时间
|
||||
42.61%--在课堂上进度过慢,或者深度过浅的时间
|
||||
31.04%--在作业中难度过高的的题目占做题时间
|
||||
41.83%--在作业中难度过低的的题目占做题时间
|
||||
课堂上进度深度适中时间为34.59%
|
||||
作业难度适中时间为27.13%。
|
||||
|
||||
62.5%:我的学习资料根本看不完,学习资料并不是我提升成绩的障碍。
|
||||
45.8%:我一直大量做题,但考试时看到碰过的题还是容易丢分。
|
|
@ -1,16 +1,16 @@
|
|||
http://blog.sina.com.cn/s/blog_591ac30401000974.html
|
||||
|
||||
“按需教育”技术交流的结果 (2007-06-10 20:28:07)
|
||||
|
||||
自从启动这个项目之后,我问过许多老教师这个问题:“如果将学生答题卡上部分答案剪掉之后,与试卷一起交给您分析,要求把剪掉部分补齐,您的准确率有多高?”大部分教师的回答是“应该有六、七成吧。”
|
||||
|
||||
这正是eokdd技术交流的活动规则,其中甲组去掉30%的数据,乙组去掉10%数据,要求参赛选手使用自动软件对学生答题数据进行修复。
|
||||
|
||||
可以这样理解:对学生答题数据修复的准确度,也就是在判断特定学生对特定题目的解题结果,本质上是判断学生学习情况。
|
||||
|
||||
从主办单位公布的数据包看,大部分自动程序超过了老教师的准确度,其中冠军程序的准确度达到了令人惊讶的97%--也就是说每100个被主办方删除的答题数据,只有3个被软件补错了。
|
||||
|
||||
这一届我们公司获得千人甲组的冠军,不过准确度没有乙组高,希望六月份能蝉联。
|
||||
|
||||
eokdd活动的主页是:
|
||||
http://blog.sina.com.cn/s/blog_591ac30401000974.html
|
||||
|
||||
“按需教育”技术交流的结果 (2007-06-10 20:28:07)
|
||||
|
||||
自从启动这个项目之后,我问过许多老教师这个问题:“如果将学生答题卡上部分答案剪掉之后,与试卷一起交给您分析,要求把剪掉部分补齐,您的准确率有多高?”大部分教师的回答是“应该有六、七成吧。”
|
||||
|
||||
这正是eokdd技术交流的活动规则,其中甲组去掉30%的数据,乙组去掉10%数据,要求参赛选手使用自动软件对学生答题数据进行修复。
|
||||
|
||||
可以这样理解:对学生答题数据修复的准确度,也就是在判断特定学生对特定题目的解题结果,本质上是判断学生学习情况。
|
||||
|
||||
从主办单位公布的数据包看,大部分自动程序超过了老教师的准确度,其中冠军程序的准确度达到了令人惊讶的97%--也就是说每100个被主办方删除的答题数据,只有3个被软件补错了。
|
||||
|
||||
这一届我们公司获得千人甲组的冠军,不过准确度没有乙组高,希望六月份能蝉联。
|
||||
|
||||
eokdd活动的主页是:
|
||||
http://task.eokdd.org.cn/
|
|
@ -1,19 +1,19 @@
|
|||
http://blog.sina.com.cn/s/blog_591ac3040100082e.html
|
||||
|
||||
为什么孩子的时间不够用? (2007-03-21 15:01:10)
|
||||
|
||||
许多家长反映孩子的时间不够用,要是每天多几个小时就好了。其实大部分同学时间不够用的原因是:花了太多时间陪其他同学听课,做作业。
|
||||
|
||||
为什么这么说呢。
|
||||
去年底有一项统计报告表明,三分之一的同学在课上走神。这个数字其实非常保守,老师课上的进度和深度能照顾一半的同学,就非常优秀了。如果一个孩子与另外四十个同学分享一个老师,那么他至少花了三分之一的时间陪其他人听课。
|
||||
作业的情况也一样,老师为了覆盖所有同学的需要,课后作业的基础概念、深入理解,综合运用题量往往有一个惯常的比例。这个比例下每个孩子都付出了额外的学习时间,去做一些难度不适合自己的题目,而作业的批改结果也对他用处不大。
|
||||
|
||||
所以如果孩子的时间不够用,可以参考这几个建议:
|
||||
一、选择水平相当的学校和班级
|
||||
如果你的孩子在班里属于中间偏上的水平,他就能享受较多的教育资源。
|
||||
二、争取教师的注意
|
||||
摩托罗拉说沟通无极限,这很有道理。家长可以多与教师通电话,孩子可以通过课堂提问,作业请教的方法多吸引教师的注意力,影响教学安排向自己倾斜。
|
||||
三、开辟第二战场--家庭教育
|
||||
如果前两种方式效果不理想,那就应该开辟家庭教育的新战线了。家长一方面应该保证家庭教育投资,一方面应该向学校争取减免统一的课时和作业,因为它们的效率偏低。
|
||||
|
||||
http://blog.sina.com.cn/s/blog_591ac3040100082e.html
|
||||
|
||||
为什么孩子的时间不够用? (2007-03-21 15:01:10)
|
||||
|
||||
许多家长反映孩子的时间不够用,要是每天多几个小时就好了。其实大部分同学时间不够用的原因是:花了太多时间陪其他同学听课,做作业。
|
||||
|
||||
为什么这么说呢。
|
||||
去年底有一项统计报告表明,三分之一的同学在课上走神。这个数字其实非常保守,老师课上的进度和深度能照顾一半的同学,就非常优秀了。如果一个孩子与另外四十个同学分享一个老师,那么他至少花了三分之一的时间陪其他人听课。
|
||||
作业的情况也一样,老师为了覆盖所有同学的需要,课后作业的基础概念、深入理解,综合运用题量往往有一个惯常的比例。这个比例下每个孩子都付出了额外的学习时间,去做一些难度不适合自己的题目,而作业的批改结果也对他用处不大。
|
||||
|
||||
所以如果孩子的时间不够用,可以参考这几个建议:
|
||||
一、选择水平相当的学校和班级
|
||||
如果你的孩子在班里属于中间偏上的水平,他就能享受较多的教育资源。
|
||||
二、争取教师的注意
|
||||
摩托罗拉说沟通无极限,这很有道理。家长可以多与教师通电话,孩子可以通过课堂提问,作业请教的方法多吸引教师的注意力,影响教学安排向自己倾斜。
|
||||
三、开辟第二战场--家庭教育
|
||||
如果前两种方式效果不理想,那就应该开辟家庭教育的新战线了。家长一方面应该保证家庭教育投资,一方面应该向学校争取减免统一的课时和作业,因为它们的效率偏低。
|
||||
|
||||
现代社会的竞争是全方位的,孩子的培养是一个家庭综合能力的检验。如果孩子的时间被过多占用,家长可以考虑减少统一的课时作业,补充更有针对性的家庭教育。
|
|
@ -1,42 +1,42 @@
|
|||
http://blog.sina.com.cn/s/blog_591ac304010008s0.html
|
||||
|
||||
为学生的知识结构打分 (2007-05-12 22:22:10)
|
||||
|
||||
大家在填写(或者请老师填写)知识结构表时,或多或少会碰到“打分依据”这个问题。我们目前暂时约定统一的填写数值是: 0:没学懂;1-能解易题;2-能解难题
|
||||
|
||||
但是“难”、“易”之间怎么划分呢?为了解释这个问题我们先回顾一下学习中遇到的各种分数。
|
||||
|
||||
【作业】
|
||||
老师留的课后作业即使打分也是很粗略的:简单的五分制、打勾/勾点/打叉
|
||||
、优良中差、very good/good/...、......因为对作业的评价主要反馈给同学,主要用途是安排自学、补习,只要标识出掌握程度上的差异即可。
|
||||
|
||||
【检验考试】
|
||||
检验考试用于检查同学之间、班级之间的学习情况,考试的性质决定了分数的差距反映的是教学努力的差距。考试卷中的题目通常有固定分数值,答卷的分数就是答对题目的分数之和。定分的主要原则是:
|
||||
一、越高的分数,蕴含的教育和学习的努力越大;(对于“标准程度”的天赋)
|
||||
二、相同的分数差距,尽可能代表相同的教育和学习的努力程度的差距。(事实上少有纯粹的检验考试,往往也糅合了甄选考试的原则,虽然有矛盾但也是无奈的选择。)
|
||||
|
||||
【甄选考试】
|
||||
为了分配升学资格而安排的中考、高考,是为下一个教育阶段甄选人才服务的。定分的主要原则有两条:
|
||||
一、分数越高越适合下一阶段的学习;
|
||||
二、同一分数上的人数越少越好。(如果一个分数上的人数多了,就给甄选带来困难,因此要设法在第一条原则的前提下让成绩分散)
|
||||
甄选考试的命题和定分,往往需要引用大量的历史数据。有的甄选考试也会使用浮动分数制--一道题的分数根据答对打错的比例而推算,而不在考前指定。
|
||||
|
||||
大家看,检验考试并不担心出现大量分数并列,而甄选考试并不在乎分数差距背后的血汗是否均等...感兴趣的话还可以从这三种打分依据中对比出更多的内容,但我们今天再展开讨论就跑题了。
|
||||
|
||||
根据《学而不问则忙》的原意,填写《知识结构表》应该使用什么打分原则呢?我们先回顾一下《知识结构表》的用途:
|
||||
一、使教育投资(包括时间和金钱)更加理性,更有针对性;
|
||||
二、寻找更吻合的学伴,促进有效的交流,降低孩子校外学习的孤独感。
|
||||
|
||||
就第一个目的而言,【作业】的打分原则就足够了;第二个目的更接近【甄选考试】的打分原则。从现实条件来看,大部分家庭应选择【作业】的粗略打分。如果能够在一两个小时内,一气呵成地调阅过去的作业本和考卷,填写《知识结构表》时的整体平衡是相当好的,而且题量远远超过一次大考,因此每个知识点都有足够的题目用于判断,所以说选定近期的补习目标是绰绰有余的。
|
||||
|
||||
好了,如果老师还在向你追问“打分依据”,你可以让他这样打分:
|
||||
0:重点补习;1:需要补习;2-不必补习。
|
||||
如果再结合家庭的经济情况和同学在这个科目上的时间分配,可以具体规定三个分数的比例,余下的事情老师会处理的。
|
||||
|
||||
|
||||
相关链接:
|
||||
学而不问则忙 一
|
||||
学而不问则忙 二
|
||||
学而不问则忙 三
|
||||
学而不问则忙 四
|
||||
http://blog.sina.com.cn/s/blog_591ac304010008s0.html
|
||||
|
||||
为学生的知识结构打分 (2007-05-12 22:22:10)
|
||||
|
||||
大家在填写(或者请老师填写)知识结构表时,或多或少会碰到“打分依据”这个问题。我们目前暂时约定统一的填写数值是: 0:没学懂;1-能解易题;2-能解难题
|
||||
|
||||
但是“难”、“易”之间怎么划分呢?为了解释这个问题我们先回顾一下学习中遇到的各种分数。
|
||||
|
||||
【作业】
|
||||
老师留的课后作业即使打分也是很粗略的:简单的五分制、打勾/勾点/打叉
|
||||
、优良中差、very good/good/...、......因为对作业的评价主要反馈给同学,主要用途是安排自学、补习,只要标识出掌握程度上的差异即可。
|
||||
|
||||
【检验考试】
|
||||
检验考试用于检查同学之间、班级之间的学习情况,考试的性质决定了分数的差距反映的是教学努力的差距。考试卷中的题目通常有固定分数值,答卷的分数就是答对题目的分数之和。定分的主要原则是:
|
||||
一、越高的分数,蕴含的教育和学习的努力越大;(对于“标准程度”的天赋)
|
||||
二、相同的分数差距,尽可能代表相同的教育和学习的努力程度的差距。(事实上少有纯粹的检验考试,往往也糅合了甄选考试的原则,虽然有矛盾但也是无奈的选择。)
|
||||
|
||||
【甄选考试】
|
||||
为了分配升学资格而安排的中考、高考,是为下一个教育阶段甄选人才服务的。定分的主要原则有两条:
|
||||
一、分数越高越适合下一阶段的学习;
|
||||
二、同一分数上的人数越少越好。(如果一个分数上的人数多了,就给甄选带来困难,因此要设法在第一条原则的前提下让成绩分散)
|
||||
甄选考试的命题和定分,往往需要引用大量的历史数据。有的甄选考试也会使用浮动分数制--一道题的分数根据答对打错的比例而推算,而不在考前指定。
|
||||
|
||||
大家看,检验考试并不担心出现大量分数并列,而甄选考试并不在乎分数差距背后的血汗是否均等...感兴趣的话还可以从这三种打分依据中对比出更多的内容,但我们今天再展开讨论就跑题了。
|
||||
|
||||
根据《学而不问则忙》的原意,填写《知识结构表》应该使用什么打分原则呢?我们先回顾一下《知识结构表》的用途:
|
||||
一、使教育投资(包括时间和金钱)更加理性,更有针对性;
|
||||
二、寻找更吻合的学伴,促进有效的交流,降低孩子校外学习的孤独感。
|
||||
|
||||
就第一个目的而言,【作业】的打分原则就足够了;第二个目的更接近【甄选考试】的打分原则。从现实条件来看,大部分家庭应选择【作业】的粗略打分。如果能够在一两个小时内,一气呵成地调阅过去的作业本和考卷,填写《知识结构表》时的整体平衡是相当好的,而且题量远远超过一次大考,因此每个知识点都有足够的题目用于判断,所以说选定近期的补习目标是绰绰有余的。
|
||||
|
||||
好了,如果老师还在向你追问“打分依据”,你可以让他这样打分:
|
||||
0:重点补习;1:需要补习;2-不必补习。
|
||||
如果再结合家庭的经济情况和同学在这个科目上的时间分配,可以具体规定三个分数的比例,余下的事情老师会处理的。
|
||||
|
||||
|
||||
相关链接:
|
||||
学而不问则忙 一
|
||||
学而不问则忙 二
|
||||
学而不问则忙 三
|
||||
学而不问则忙 四
|
||||
知识结构表(带样例)
|
|
@ -1,22 +1,22 @@
|
|||
http://blog.sina.com.cn/s/blog_591ac3040100c8o8.html
|
||||
|
||||
关于个性化辅导 (2009-03-19 20:21:33)
|
||||
|
||||
摘自学门科技内部材料,仅供参考。
|
||||
|
||||
......
|
||||
|
||||
二、个性化辅导
|
||||
|
||||
1、利润困境
|
||||
个性化辅导的特征是统一的师资、场地、教材(三个统一),进行一对一教学。刚出现的时候很受市场欢迎,成为课外辅导的新增长点。然而,这“三个统一”并没有带来实质上的质量优势,业务上直接受到个体家教的挑战,在消费者趋于理性之后就陷入停滞甚至衰退。这时辅导公司通常会向其它地区发展,以图在新的城市作为新业务实现高利润。但由于总部和分部之间的实际贡献与利益分配不平衡,它们往往在扩张半年左右即爆发管理问题,因而难以实现预期的高利润,陷入困境。
|
||||
|
||||
2、原因分析
|
||||
上述利润困境的成因,是把早期的成功错误地归功于“三个统一”,因此将市场收益更多投入到广告、分校扩张上,不停地强化这个概念,而没有集中资源研发个性化教学方案,以真正实现教学环节的个性化差异。如果充分利用第一桶金,集中研发出有效的“个性化教学方案”,得以聘用中低端教员实施高质量的教学,则不至于人力成本失控;配合品牌和资金进行扩张,则不至于分部管理失控。
|
||||
所以说,总部职能的缺位是造成利润困境的根本原因。
|
||||
|
||||
3、总部的核心职能
|
||||
对于个性化辅导公司,其总部的核心职能之一是研发个性化教学方案。因为这套方案决定了用人成本和教学质量,可以说它也决定了公司的利润率。这套方案通常包含两个部分:一套个性化分析工具、一套教改方案。前者借助技术以实现个性化分析,后者对传统(整班)教学的工序、岗位进行拆分、重组,在教学过程中充分运用分析结果。
|
||||
个性化教学方案可以分解为技术研究和教学研究问题,这是个性化辅导公司总部的核心职能。不解决这两个研究问题,则总部难以管理分部,校区难以管理教师。
|
||||
|
||||
http://blog.sina.com.cn/s/blog_591ac3040100c8o8.html
|
||||
|
||||
关于个性化辅导 (2009-03-19 20:21:33)
|
||||
|
||||
摘自学门科技内部材料,仅供参考。
|
||||
|
||||
......
|
||||
|
||||
二、个性化辅导
|
||||
|
||||
1、利润困境
|
||||
个性化辅导的特征是统一的师资、场地、教材(三个统一),进行一对一教学。刚出现的时候很受市场欢迎,成为课外辅导的新增长点。然而,这“三个统一”并没有带来实质上的质量优势,业务上直接受到个体家教的挑战,在消费者趋于理性之后就陷入停滞甚至衰退。这时辅导公司通常会向其它地区发展,以图在新的城市作为新业务实现高利润。但由于总部和分部之间的实际贡献与利益分配不平衡,它们往往在扩张半年左右即爆发管理问题,因而难以实现预期的高利润,陷入困境。
|
||||
|
||||
2、原因分析
|
||||
上述利润困境的成因,是把早期的成功错误地归功于“三个统一”,因此将市场收益更多投入到广告、分校扩张上,不停地强化这个概念,而没有集中资源研发个性化教学方案,以真正实现教学环节的个性化差异。如果充分利用第一桶金,集中研发出有效的“个性化教学方案”,得以聘用中低端教员实施高质量的教学,则不至于人力成本失控;配合品牌和资金进行扩张,则不至于分部管理失控。
|
||||
所以说,总部职能的缺位是造成利润困境的根本原因。
|
||||
|
||||
3、总部的核心职能
|
||||
对于个性化辅导公司,其总部的核心职能之一是研发个性化教学方案。因为这套方案决定了用人成本和教学质量,可以说它也决定了公司的利润率。这套方案通常包含两个部分:一套个性化分析工具、一套教改方案。前者借助技术以实现个性化分析,后者对传统(整班)教学的工序、岗位进行拆分、重组,在教学过程中充分运用分析结果。
|
||||
个性化教学方案可以分解为技术研究和教学研究问题,这是个性化辅导公司总部的核心职能。不解决这两个研究问题,则总部难以管理分部,校区难以管理教师。
|
||||
|
||||
......
|
|
@ -1,26 +1,26 @@
|
|||
http://blog.sina.com.cn/s/blog_591ac30401008lon.html
|
||||
|
||||
关于教育行业重构的探讨 (2008-03-19 15:21:03)
|
||||
|
||||
大家好,
|
||||
|
||||
当政府投入逐年增加,投资活动逐年增加,一个行业就应该进入繁荣阶段了。
|
||||
当“维持”和“退出”成了行内企业的普遍选择,一个行业就到了升级或消亡的时候了。
|
||||
在教育市场中却同时出现上述两种特征,“升级+繁荣”就成为一个现实的选择,一轮整体性的变革即将来临。这场变革必将深入的改造教育行业的部门设
|
||||
置、管理体制和教学流程。在变革的前夕,教育行业的朋友非常需要与管理咨询、法律、投资方面的朋友一起探讨,并共同分享后面的商业机会。
|
||||
|
||||
因此我提议大家组织起来,参与在“按需教育”论坛的讨论:
|
||||
http://groups.google.com/group/eokdd/topics
|
||||
将要探讨的专题包括(而不限于):
|
||||
一、其它行业收益于部门重构和流程改造的共性规律;
|
||||
二、教育行业发展的主要矛盾是什么,现有部门设置、管理体制与教学流程对问题的解决有什么制约;
|
||||
三、要达到更优的教学效果,部门设置、管理体制与教学流程应该怎么设计;
|
||||
四、部门设置、管理体制与教学流程的新老过渡,将经过几个阶段;
|
||||
五、在这个过程中,将会出现哪些新的商业模式、合作形态,会有哪些新的管理、制度和法律问题,我们应如何应对。
|
||||
这些问题有前后接递的关系,可以依次作为探讨的重点,我们应定期做一下总结整理。
|
||||
|
||||
随着网上讨论的进行,可以组织专题沙龙以集中探讨一些要点、难点。对形成共识的环节,即可依托现有研究课题和商业产品安排实践。
|
||||
|
||||
感兴趣吗,那就到论坛来,分享你的第一篇观点吧。
|
||||
|
||||
http://blog.sina.com.cn/s/blog_591ac30401008lon.html
|
||||
|
||||
关于教育行业重构的探讨 (2008-03-19 15:21:03)
|
||||
|
||||
大家好,
|
||||
|
||||
当政府投入逐年增加,投资活动逐年增加,一个行业就应该进入繁荣阶段了。
|
||||
当“维持”和“退出”成了行内企业的普遍选择,一个行业就到了升级或消亡的时候了。
|
||||
在教育市场中却同时出现上述两种特征,“升级+繁荣”就成为一个现实的选择,一轮整体性的变革即将来临。这场变革必将深入的改造教育行业的部门设
|
||||
置、管理体制和教学流程。在变革的前夕,教育行业的朋友非常需要与管理咨询、法律、投资方面的朋友一起探讨,并共同分享后面的商业机会。
|
||||
|
||||
因此我提议大家组织起来,参与在“按需教育”论坛的讨论:
|
||||
http://groups.google.com/group/eokdd/topics
|
||||
将要探讨的专题包括(而不限于):
|
||||
一、其它行业收益于部门重构和流程改造的共性规律;
|
||||
二、教育行业发展的主要矛盾是什么,现有部门设置、管理体制与教学流程对问题的解决有什么制约;
|
||||
三、要达到更优的教学效果,部门设置、管理体制与教学流程应该怎么设计;
|
||||
四、部门设置、管理体制与教学流程的新老过渡,将经过几个阶段;
|
||||
五、在这个过程中,将会出现哪些新的商业模式、合作形态,会有哪些新的管理、制度和法律问题,我们应如何应对。
|
||||
这些问题有前后接递的关系,可以依次作为探讨的重点,我们应定期做一下总结整理。
|
||||
|
||||
随着网上讨论的进行,可以组织专题沙龙以集中探讨一些要点、难点。对形成共识的环节,即可依托现有研究课题和商业产品安排实践。
|
||||
|
||||
感兴趣吗,那就到论坛来,分享你的第一篇观点吧。
|
||||
|
||||
勇刚
|
|
@ -1,24 +1,24 @@
|
|||
http://blog.sina.com.cn/s/blog_591ac30401000a7x.html
|
||||
|
||||
各产业的网络化与智能化趋势对比 (2007-08-21 17:28:42)
|
||||
|
||||
我们用不同的关键词和年份组合起来,在google上查询了相关网页的数量,以此来对比各产业的网络化、智能化的趋势。
|
||||
|
||||

|
||||
|
||||
简单的分析一下:
|
||||
产业网络化前五名:
|
||||
英语:教育、金融、交通、军事、制造
|
||||
中文:制造、金融、交通、医疗、军事
|
||||
|
||||
产业数据挖掘应用前五名:
|
||||
英语:教育、制造、金融、医疗、交通
|
||||
中文:制造、教育、金融、交通、医疗
|
||||
|
||||
英语国家产业发展较理性
|
||||
重视数据汇总与数据分析两种能力均衡发展;
|
||||
在网络化初期加大产业数据挖掘力度,85年后所有产业数据挖掘力度加大,教育与金融在85年网络化,其它产业在95~00之间陆续启动。
|
||||
|
||||
中国各产业受设备价格影响较大,在数据挖掘应用不成熟时被动网络化:
|
||||
制造、金融、交通在85年起网络化,其它在95年集中启动。
|
||||
http://blog.sina.com.cn/s/blog_591ac30401000a7x.html
|
||||
|
||||
各产业的网络化与智能化趋势对比 (2007-08-21 17:28:42)
|
||||
|
||||
我们用不同的关键词和年份组合起来,在google上查询了相关网页的数量,以此来对比各产业的网络化、智能化的趋势。
|
||||
|
||||

|
||||
|
||||
简单的分析一下:
|
||||
产业网络化前五名:
|
||||
英语:教育、金融、交通、军事、制造
|
||||
中文:制造、金融、交通、医疗、军事
|
||||
|
||||
产业数据挖掘应用前五名:
|
||||
英语:教育、制造、金融、医疗、交通
|
||||
中文:制造、教育、金融、交通、医疗
|
||||
|
||||
英语国家产业发展较理性
|
||||
重视数据汇总与数据分析两种能力均衡发展;
|
||||
在网络化初期加大产业数据挖掘力度,85年后所有产业数据挖掘力度加大,教育与金融在85年网络化,其它产业在95~00之间陆续启动。
|
||||
|
||||
中国各产业受设备价格影响较大,在数据挖掘应用不成熟时被动网络化:
|
||||
制造、金融、交通在85年起网络化,其它在95年集中启动。
|
||||
制造、教育、金融、交通从95年加大数据挖掘投入,其它产业到05年仍发展缓慢。
|
|
@ -1,26 +1,26 @@
|
|||
http://blog.sina.com.cn/s/blog_591ac304010008oi.html
|
||||
|
||||
学而不问则忙 之二 (2007-05-04 20:11:34)
|
||||
|
||||
先解释一下,昨天的帖子中提到需要用一半的时间进行“问”,指的是课余时间的一半,前提是孩子已经在学校接受了完整而系统的课堂讲授。
|
||||
|
||||
另外顺便说一下为什么老教师的“问”不能用现成的试卷来代替。
|
||||
拿数学课作为例子,初中高中的教材大约都有一百个小节,每节通常需要讲好几堂课,包含好几个知识点。即使每小节只考两道题,每道题解题时间三分钟,用现成的试卷来“问”一遍毕业前的孩子的话,大约需要十个小时。
|
||||
另一方面,孩子对一个知识点的掌握程度是不断变化的,比如每周都学习新的知识;每当学习新知识点时用到的老知识点,多半有所巩固提高;而大部分老知识点总在不断地遗忘。
|
||||
一方面普查一遍题量大,耗费时间长;一方面孩子的知识掌握每周都在变化。所以说仅仅通过纸面的作业或者试卷去准确判断孩子的知识结构,是不可行的。而有经验的教师通过双向交流,结合历史上相似案例可以快速捕捉到孩子的知识结构特征,选择弱点后用适当的“问”来印证,这个过程是固定命题的卷子难以取代的。
|
||||
|
||||
今天讲讲具体应该怎么问,我们限定一下问题范围:怎么问出孩子最需要补充的三五个知识点--这大约是一个晚上可以补习的份量。
|
||||
根据对孩子了解程度的不同,头几个问题有多种选择,知道他弱项的可以直接问,不知道的可以先了解大致的排名情况,然后从同年级情况选择入手点。对于快速正确回答的孩子,可以在同一知识点上增加难度,增加应用灵活度;对于回答错误或者举棋不定的情况,可以降低难度、切分题目环节、转问母知识点、转问同类解题思路的其它题......来探问他的实际漏洞,一般都能发现他的弱点。
|
||||
对于中上水平的同学,通常在新解题方法和多知识点结合的问题上熟练程度不足,可以补充一些例题,温习常见的联合出题知识点概念,再逐步扶持孩子独立解题。对于中下水平的孩子,容易在知识点本身(包括母知识点)的理解不准确,就需要从基本概念开始补充。
|
||||
通常选择需要温习的三五个知识点需要将近一个小时,然后趁孩子印象深刻时抓紧补充,这个晚上的效果会非常好。
|
||||
|
||||
这样的“问”,有经验的老教师当然是最佳选择,但同学或者家长也是可以自己进行的。需要准备的材料有:
|
||||
一、一本习题书,需要有展开讲解的解题步骤;
|
||||
二、一本讲解各种解题方法技巧的参考书;
|
||||
三、自制一张打分表,包含已经学过的小节(知识点)。
|
||||
这个“问”的过程要坚持几项工作:
|
||||
一、坚持每道错题必须明确出现失误的步骤,每个失误必须确定是概念不清还是解题方法不熟练,概念不清的必须明确标出关联的小节(知识点)。
|
||||
二、坚持为每个被“问”到的小节(知识点)做记录,可以根据掌握程度记上分,有经验的教师可以分得很细,同学或者家长至少可以分:不懂、能解易题、能解难题三档吧。
|
||||
三、对于做错的题要根据“降低难度、切分题目环节、转问母知识点、转问同类解题思路的其它题”的方法选下一道,有多道题选上的记录一下,依次去做。
|
||||
|
||||
http://blog.sina.com.cn/s/blog_591ac304010008oi.html
|
||||
|
||||
学而不问则忙 之二 (2007-05-04 20:11:34)
|
||||
|
||||
先解释一下,昨天的帖子中提到需要用一半的时间进行“问”,指的是课余时间的一半,前提是孩子已经在学校接受了完整而系统的课堂讲授。
|
||||
|
||||
另外顺便说一下为什么老教师的“问”不能用现成的试卷来代替。
|
||||
拿数学课作为例子,初中高中的教材大约都有一百个小节,每节通常需要讲好几堂课,包含好几个知识点。即使每小节只考两道题,每道题解题时间三分钟,用现成的试卷来“问”一遍毕业前的孩子的话,大约需要十个小时。
|
||||
另一方面,孩子对一个知识点的掌握程度是不断变化的,比如每周都学习新的知识;每当学习新知识点时用到的老知识点,多半有所巩固提高;而大部分老知识点总在不断地遗忘。
|
||||
一方面普查一遍题量大,耗费时间长;一方面孩子的知识掌握每周都在变化。所以说仅仅通过纸面的作业或者试卷去准确判断孩子的知识结构,是不可行的。而有经验的教师通过双向交流,结合历史上相似案例可以快速捕捉到孩子的知识结构特征,选择弱点后用适当的“问”来印证,这个过程是固定命题的卷子难以取代的。
|
||||
|
||||
今天讲讲具体应该怎么问,我们限定一下问题范围:怎么问出孩子最需要补充的三五个知识点--这大约是一个晚上可以补习的份量。
|
||||
根据对孩子了解程度的不同,头几个问题有多种选择,知道他弱项的可以直接问,不知道的可以先了解大致的排名情况,然后从同年级情况选择入手点。对于快速正确回答的孩子,可以在同一知识点上增加难度,增加应用灵活度;对于回答错误或者举棋不定的情况,可以降低难度、切分题目环节、转问母知识点、转问同类解题思路的其它题......来探问他的实际漏洞,一般都能发现他的弱点。
|
||||
对于中上水平的同学,通常在新解题方法和多知识点结合的问题上熟练程度不足,可以补充一些例题,温习常见的联合出题知识点概念,再逐步扶持孩子独立解题。对于中下水平的孩子,容易在知识点本身(包括母知识点)的理解不准确,就需要从基本概念开始补充。
|
||||
通常选择需要温习的三五个知识点需要将近一个小时,然后趁孩子印象深刻时抓紧补充,这个晚上的效果会非常好。
|
||||
|
||||
这样的“问”,有经验的老教师当然是最佳选择,但同学或者家长也是可以自己进行的。需要准备的材料有:
|
||||
一、一本习题书,需要有展开讲解的解题步骤;
|
||||
二、一本讲解各种解题方法技巧的参考书;
|
||||
三、自制一张打分表,包含已经学过的小节(知识点)。
|
||||
这个“问”的过程要坚持几项工作:
|
||||
一、坚持每道错题必须明确出现失误的步骤,每个失误必须确定是概念不清还是解题方法不熟练,概念不清的必须明确标出关联的小节(知识点)。
|
||||
二、坚持为每个被“问”到的小节(知识点)做记录,可以根据掌握程度记上分,有经验的教师可以分得很细,同学或者家长至少可以分:不懂、能解易题、能解难题三档吧。
|
||||
三、对于做错的题要根据“降低难度、切分题目环节、转问母知识点、转问同类解题思路的其它题”的方法选下一道,有多道题选上的记录一下,依次去做。
|
||||
|
||||
这是一个非常简化的过程,实际情况往往灵活得多,但它可以帮助孩子在没有老师时,通过不到一个小时的自测找到最需要补充的三五个知识点,长期坚持的话整张表可以一目了然地反映整体状况,孩子的“学”自然就有针对性了。
|
|
@ -1,20 +1,20 @@
|
|||
http://blog.sina.com.cn/s/blog_591ac304010008o6.html
|
||||
|
||||
学而不问则忙 (2007-05-03 22:38:40)
|
||||
|
||||
和过去相比,现在的孩子学习压力更重了,大部分同学都很自觉,很努力。和过去相比,现在家庭的购买力更强了,在教育上更敢投资,孩子的资料基本不缺。同学们最主要的困难就是“时间不够”,而且购买力越强的家庭,越努力的孩子,时间越不够。
|
||||
|
||||
在补习时孩子主要有两种情况,一种是带着问题的,他们很清楚自己哪里没有学明白,对老师不停地提问直到弄懂;另一种是提不出问题的,这样的同学就需要老师来提问,这往往要耗费老师大量的时间精力。现实中“时间不够用”的通常是后一种同学。
|
||||
|
||||
我们观察了一些有经验的老教师,他们给提不出问题的同学补习时非常注重提问,这个提问不能用成型的卷子来代替,因为老教师一边问一边选择后面的提问方向,一步一步地了解到孩子的弱点,然后才开始讲授。在大部分情况下,“问”的时间占到50%甚至更多,并不比“讲”的时间少。您可别小看这个“问”的环节,老教师半个小时的“问”,比学生做十个小时的卷子更能暴露问题。
|
||||
相信许多家长在小学低年级时都有自己给孩子补课的经历,可以回忆一下时间的分配。
|
||||
|
||||
到了中学家长直接补习有一定困难,这时候孩子大部分时间是自学。对于会问的孩子这不是大问题,他们已经习惯于自己问自己,然后问老师这一学习方法。但不会提问的孩子,这时候成绩容易下滑,即使大幅度增加温习时间也无济于事。或者请的家教经验不足,“问”的功力不够深厚,效果也不理想。
|
||||
|
||||
对于后一种情形,家长一定要清楚:解决“忙”的问题,最关键还是“问”,而不是“读”,一旦“问”出弱点来,孩子自然就不“忙”了。
|
||||
每个科目的情况不同,像数学的课后自学一般需要安排一半时间用于“问”,另一半时间足够“学”了。如果“问”的时间不能保证,习惯没有培养成型,“学”的时间没有针对性,那多半是“忙不过来”的。
|
||||
|
||||
总结起来,如果孩子总是“忙不过来”,那么家长需要:
|
||||
一、培养孩子“问”的习惯和技巧;
|
||||
二、保证“学”的资源和投入,让孩子问完之后能尽快进补。
|
||||
http://blog.sina.com.cn/s/blog_591ac304010008o6.html
|
||||
|
||||
学而不问则忙 (2007-05-03 22:38:40)
|
||||
|
||||
和过去相比,现在的孩子学习压力更重了,大部分同学都很自觉,很努力。和过去相比,现在家庭的购买力更强了,在教育上更敢投资,孩子的资料基本不缺。同学们最主要的困难就是“时间不够”,而且购买力越强的家庭,越努力的孩子,时间越不够。
|
||||
|
||||
在补习时孩子主要有两种情况,一种是带着问题的,他们很清楚自己哪里没有学明白,对老师不停地提问直到弄懂;另一种是提不出问题的,这样的同学就需要老师来提问,这往往要耗费老师大量的时间精力。现实中“时间不够用”的通常是后一种同学。
|
||||
|
||||
我们观察了一些有经验的老教师,他们给提不出问题的同学补习时非常注重提问,这个提问不能用成型的卷子来代替,因为老教师一边问一边选择后面的提问方向,一步一步地了解到孩子的弱点,然后才开始讲授。在大部分情况下,“问”的时间占到50%甚至更多,并不比“讲”的时间少。您可别小看这个“问”的环节,老教师半个小时的“问”,比学生做十个小时的卷子更能暴露问题。
|
||||
相信许多家长在小学低年级时都有自己给孩子补课的经历,可以回忆一下时间的分配。
|
||||
|
||||
到了中学家长直接补习有一定困难,这时候孩子大部分时间是自学。对于会问的孩子这不是大问题,他们已经习惯于自己问自己,然后问老师这一学习方法。但不会提问的孩子,这时候成绩容易下滑,即使大幅度增加温习时间也无济于事。或者请的家教经验不足,“问”的功力不够深厚,效果也不理想。
|
||||
|
||||
对于后一种情形,家长一定要清楚:解决“忙”的问题,最关键还是“问”,而不是“读”,一旦“问”出弱点来,孩子自然就不“忙”了。
|
||||
每个科目的情况不同,像数学的课后自学一般需要安排一半时间用于“问”,另一半时间足够“学”了。如果“问”的时间不能保证,习惯没有培养成型,“学”的时间没有针对性,那多半是“忙不过来”的。
|
||||
|
||||
总结起来,如果孩子总是“忙不过来”,那么家长需要:
|
||||
一、培养孩子“问”的习惯和技巧;
|
||||
二、保证“学”的资源和投入,让孩子问完之后能尽快进补。
|
||||
这两个任务做好之后,孩子就不忙了。
|
|
@ -1,30 +1,30 @@
|
|||
http://blog.sina.com.cn/s/blog_591ac304010008ox.html
|
||||
|
||||
学而不问则忙 之三 (2007-05-05 13:17:52)
|
||||
|
||||
昨天我们讲到如何通过一个小时的自测,定位出孩子需要补充的三五个知识点。这种自测每个月需要进行一两次,重点学科重点时期可以每周进行一次,您会看到每次的结果都不全相同。
|
||||
|
||||
今天我们一起看看“问”完之后怎么“学”,如果“学”的环节不使用“问”的结果,那前面的功夫就白费了,这里的“学”也是有技巧的。一个理想的家庭学习环境需要有几个要素,同学和家长们可以自我检查一下:
|
||||
一、充足的例题,例题的作用是帮助孩子在大约两分钟时间内掌握知识点的运用;
|
||||
二、基本概念的材料,针对单个知识点的,长度在五到十分钟左右的“微课程”;
|
||||
三、疑难问题的指导,能在孩子的兴趣消退之前,及时解答他的特定问题。
|
||||
|
||||
对于自学能力强,悟性高的孩子,教参书籍就可以满足例题和基本概念的需要,这样的同学通常更容易在学校里获得老师的指导。但大部分的同学还会用到网络资源或者家教,所以今天我们重点讲这两样。
|
||||
|
||||
现在有许多网络教育资源供同学和家长选择,其中不乏精品。选购时要注意不必一味追求名校、名师,对于掌握了“问”的技巧的孩子,真正需要的是便于检索的、程度适合的“微课程”。所以选择时要留意课程是否进行了细分,细分到章、节还是具体知识点,从登录到选课再到开始教学是否简捷。有许多网站罗列了大量的优质教育资源,但是调用起来不够方便,由注意力容易分散的少年来使用效果不一定好。
|
||||
另外,不同的课件制作方有不同的指导思想,是补基础还是抓应用,是单点突破还是循序渐进,都需要根据孩子的特点来选择。
|
||||
总的来说,网络教育资源是供大于求的状况,只要耐心识别寻找,每个孩子都能得到适合的资源提供商。
|
||||
|
||||
家教也是很普遍的教育手段,不过大部分家长对家教老师的了解不深,往往通过口碑进行选择,但孩子的情况都有一定差异,常常出现同一个老师进行补习,一个孩子效果很好,另一个孩子却不见效。
|
||||
为了便于后面讨论,所以我们先把家教老师分一下类。第一类是高校学生,他们刚刚经历高考,和孩子交流障碍不大,而且费用比较合理,但是教学经验不足;第二类是年轻教师,他们受过系统的教育训练,有一定的教学实践(为了保证效果最好找五年教龄以上,课堂教学效果较好的),家教效果比高校学生好;第三类是经验丰富的老教师,如果时间充足的话效果最佳,但是费用比较高,和孩子沟通可能有障碍,对于性格内向的孩子家长要及时了解效果。
|
||||
|
||||
根据孩子和家庭情况不同,我建议聘请两位家教老师,实施“学”、“问”独立,高低搭配。
|
||||
负责“问”的可以是高校学生或者年轻教师,他的任务是了解孩子的缺陷,填写昨天提到的知识结构表。对于特别简单的概念理解和方法指导,他通常也会顺便解决了。同时要求他在“问”的过程中,跟踪了解负责“学”的老师的工作效果,起到“监理”的作用。
|
||||
负责“学”的家教老师,可以找五年以上教龄的,在校属于青年骨干的教师,如果效果不好再转向资深老教师。他负责清除“问”的环节划定的知识点,帮助孩子理解到位,方法熟练。家长可以根据“问”老师的跟踪反馈,提前和“学”老师沟通,督促其认真备课,以保证效果。
|
||||
对于重点学科,“问”老师至少每周一小时时间,“学”老师的课时一两周一次就够了。另外,学校班主任和任课老师也是需要加强联系的,如果配合的好他们可以承担“学”老师的任务。
|
||||
|
||||
好,总结一下,如果要孩子“忙得过来”,就要建立“外科手术”式的精确教学模式。其中“学”的环节要点是:
|
||||
一、便于检索的“微课程”;
|
||||
二、相互独立的“学”老师和“问”老师;
|
||||
三、加强和学校任课老师的联系。
|
||||
http://blog.sina.com.cn/s/blog_591ac304010008ox.html
|
||||
|
||||
学而不问则忙 之三 (2007-05-05 13:17:52)
|
||||
|
||||
昨天我们讲到如何通过一个小时的自测,定位出孩子需要补充的三五个知识点。这种自测每个月需要进行一两次,重点学科重点时期可以每周进行一次,您会看到每次的结果都不全相同。
|
||||
|
||||
今天我们一起看看“问”完之后怎么“学”,如果“学”的环节不使用“问”的结果,那前面的功夫就白费了,这里的“学”也是有技巧的。一个理想的家庭学习环境需要有几个要素,同学和家长们可以自我检查一下:
|
||||
一、充足的例题,例题的作用是帮助孩子在大约两分钟时间内掌握知识点的运用;
|
||||
二、基本概念的材料,针对单个知识点的,长度在五到十分钟左右的“微课程”;
|
||||
三、疑难问题的指导,能在孩子的兴趣消退之前,及时解答他的特定问题。
|
||||
|
||||
对于自学能力强,悟性高的孩子,教参书籍就可以满足例题和基本概念的需要,这样的同学通常更容易在学校里获得老师的指导。但大部分的同学还会用到网络资源或者家教,所以今天我们重点讲这两样。
|
||||
|
||||
现在有许多网络教育资源供同学和家长选择,其中不乏精品。选购时要注意不必一味追求名校、名师,对于掌握了“问”的技巧的孩子,真正需要的是便于检索的、程度适合的“微课程”。所以选择时要留意课程是否进行了细分,细分到章、节还是具体知识点,从登录到选课再到开始教学是否简捷。有许多网站罗列了大量的优质教育资源,但是调用起来不够方便,由注意力容易分散的少年来使用效果不一定好。
|
||||
另外,不同的课件制作方有不同的指导思想,是补基础还是抓应用,是单点突破还是循序渐进,都需要根据孩子的特点来选择。
|
||||
总的来说,网络教育资源是供大于求的状况,只要耐心识别寻找,每个孩子都能得到适合的资源提供商。
|
||||
|
||||
家教也是很普遍的教育手段,不过大部分家长对家教老师的了解不深,往往通过口碑进行选择,但孩子的情况都有一定差异,常常出现同一个老师进行补习,一个孩子效果很好,另一个孩子却不见效。
|
||||
为了便于后面讨论,所以我们先把家教老师分一下类。第一类是高校学生,他们刚刚经历高考,和孩子交流障碍不大,而且费用比较合理,但是教学经验不足;第二类是年轻教师,他们受过系统的教育训练,有一定的教学实践(为了保证效果最好找五年教龄以上,课堂教学效果较好的),家教效果比高校学生好;第三类是经验丰富的老教师,如果时间充足的话效果最佳,但是费用比较高,和孩子沟通可能有障碍,对于性格内向的孩子家长要及时了解效果。
|
||||
|
||||
根据孩子和家庭情况不同,我建议聘请两位家教老师,实施“学”、“问”独立,高低搭配。
|
||||
负责“问”的可以是高校学生或者年轻教师,他的任务是了解孩子的缺陷,填写昨天提到的知识结构表。对于特别简单的概念理解和方法指导,他通常也会顺便解决了。同时要求他在“问”的过程中,跟踪了解负责“学”的老师的工作效果,起到“监理”的作用。
|
||||
负责“学”的家教老师,可以找五年以上教龄的,在校属于青年骨干的教师,如果效果不好再转向资深老教师。他负责清除“问”的环节划定的知识点,帮助孩子理解到位,方法熟练。家长可以根据“问”老师的跟踪反馈,提前和“学”老师沟通,督促其认真备课,以保证效果。
|
||||
对于重点学科,“问”老师至少每周一小时时间,“学”老师的课时一两周一次就够了。另外,学校班主任和任课老师也是需要加强联系的,如果配合的好他们可以承担“学”老师的任务。
|
||||
|
||||
好,总结一下,如果要孩子“忙得过来”,就要建立“外科手术”式的精确教学模式。其中“学”的环节要点是:
|
||||
一、便于检索的“微课程”;
|
||||
二、相互独立的“学”老师和“问”老师;
|
||||
三、加强和学校任课老师的联系。
|
||||
按照这套方案去做,准备材料和选聘老师大概需要一两周时间,然后孩子就开始享受有序的“按需教育”了。
|
|
@ -1,28 +1,28 @@
|
|||
http://blog.sina.com.cn/s/blog_591ac304010008pc.html
|
||||
|
||||
学而不问则忙 之四 (2007-05-06 19:58:52)
|
||||
|
||||
五一假期快结束了,今天是“学而不问则忙”的最后一贴。
|
||||
前面讲到高效的家庭教育是“外科手术式”的“按需教育”,应该先检查出同学需要补充的知识点,而且负责检查的“问”老师和负责补习的“学”老师最好分开安排。最简单的情况,应由同学自己“问”,由学校任课老师提供“学”。但家长应承担调度协调的任务,了解知识结构表填写情况,还要尽可能准备充足的例题和“微课程”。
|
||||
|
||||
今天我们探讨如何选择“学伴”,中学正是活泼好动的年龄,自我管理能力不如成年人,单独学习时间长了效率容易下降,而许多忙碌的家长往往分身乏术,不能长期陪伴孩子的课余学习。如果能找到水平相当、进度相似的同学作伴,交流“学”的资源和心得,共享“问”的结果,家长只需要定期对比检查,给予适当的奖励和鞭策,效果会远远好于孤独的学习。
|
||||
|
||||
学校受客观条件制约必须按班级授课,大部分还不能根据各科目学习情况分班分组、安排座位。这种情况下同学之间的好友关系主要受性格、爱好甚至上学路径所影响,并不一定适合在“按需教育”阶段作为同学。
|
||||
|
||||
从实践情况看,效果最理想的“学伴”是知识结构的长短板块相似的同学,这里的长短板不是指科目强弱,要细化到具体知识点,至少到教材中的具体小节。最简单的方式就是对照习题本,看错题的分布是否相似。错题本相似的同学,往往在非智力因素上也很接近,他们的交流效果远远超出他人预期。
|
||||
|
||||
孩子在真实世界中的接触面很有限,我们是否可以利用互联网更方便地交换知识结构表和错题本,借助大家的力量把“按需教育”环境的最后一环--“学伴”补齐?为了方便大家交换资料我在新浪创建了“按需教育”博客圈,请有意参与的同学和家长加入一下。五一后我们一起制定统一的表格结构,以便大家交换分享。
|
||||
|
||||
下面我与大家分享一个小故事。
|
||||
有—个农夫经常是南瓜大赛的首奖及优等奖的得主,但每次得奖之后,他都毫不吝惜地将得奖的种子分送给街坊邻居。有一位邻居很诧异地问他,“你的奖项得来不易,每季都看你投入大量的时间和精力来做品种改良,为什么还这么慷慨地将种子送给我们呢?难道你不怕我们的南瓜品种因而超越你的吗?”
|
||||
这位农夫回答:“我将种子分送给大家,帮助大家,其实也就是帮助我自己。如果我将得奖的种子私藏,你们在南瓜品种的改良方面势必无法跟上,蜜蜂就容易将那些较差的品种传播过来,我必须在防范外来花粉方面大费周折而疲于奔命啊。”
|
||||
|
||||
每位同学都在不停受到他的同学、朋友的影响,所以好的经验一定要及时和身边的朋友分享。事实上经常接触的朋友在大考的竞争对手中占的比例是微乎其微的,小环境的成员越优秀,自己用在真正学习上的时间效率越高,这个道理大家都很容易想明白。
|
||||
|
||||
最后是大总结,我相信信息技术已经使“外科手术式”的“按需教育”成为可能,您需要做的是:
|
||||
一、加入“按需教育”博客圈,使用共同设计的知识结构表和错题本;
|
||||
二、定期检查同学的知识结构,用一小时时间找出最需要补充的三五个知识点,重点科目应做到每周一次;
|
||||
三、准备充足的、细分到知识点的、便于检索的例题和“微课程”,使同学可以及时补充“养分”;
|
||||
四、寻找错题本相似的“学伴”,在交流中共同进步;
|
||||
五、请家教时单独请一名“问”老师,专职负责检查知识结构。
|
||||
http://blog.sina.com.cn/s/blog_591ac304010008pc.html
|
||||
|
||||
学而不问则忙 之四 (2007-05-06 19:58:52)
|
||||
|
||||
五一假期快结束了,今天是“学而不问则忙”的最后一贴。
|
||||
前面讲到高效的家庭教育是“外科手术式”的“按需教育”,应该先检查出同学需要补充的知识点,而且负责检查的“问”老师和负责补习的“学”老师最好分开安排。最简单的情况,应由同学自己“问”,由学校任课老师提供“学”。但家长应承担调度协调的任务,了解知识结构表填写情况,还要尽可能准备充足的例题和“微课程”。
|
||||
|
||||
今天我们探讨如何选择“学伴”,中学正是活泼好动的年龄,自我管理能力不如成年人,单独学习时间长了效率容易下降,而许多忙碌的家长往往分身乏术,不能长期陪伴孩子的课余学习。如果能找到水平相当、进度相似的同学作伴,交流“学”的资源和心得,共享“问”的结果,家长只需要定期对比检查,给予适当的奖励和鞭策,效果会远远好于孤独的学习。
|
||||
|
||||
学校受客观条件制约必须按班级授课,大部分还不能根据各科目学习情况分班分组、安排座位。这种情况下同学之间的好友关系主要受性格、爱好甚至上学路径所影响,并不一定适合在“按需教育”阶段作为同学。
|
||||
|
||||
从实践情况看,效果最理想的“学伴”是知识结构的长短板块相似的同学,这里的长短板不是指科目强弱,要细化到具体知识点,至少到教材中的具体小节。最简单的方式就是对照习题本,看错题的分布是否相似。错题本相似的同学,往往在非智力因素上也很接近,他们的交流效果远远超出他人预期。
|
||||
|
||||
孩子在真实世界中的接触面很有限,我们是否可以利用互联网更方便地交换知识结构表和错题本,借助大家的力量把“按需教育”环境的最后一环--“学伴”补齐?为了方便大家交换资料我在新浪创建了“按需教育”博客圈,请有意参与的同学和家长加入一下。五一后我们一起制定统一的表格结构,以便大家交换分享。
|
||||
|
||||
下面我与大家分享一个小故事。
|
||||
有—个农夫经常是南瓜大赛的首奖及优等奖的得主,但每次得奖之后,他都毫不吝惜地将得奖的种子分送给街坊邻居。有一位邻居很诧异地问他,“你的奖项得来不易,每季都看你投入大量的时间和精力来做品种改良,为什么还这么慷慨地将种子送给我们呢?难道你不怕我们的南瓜品种因而超越你的吗?”
|
||||
这位农夫回答:“我将种子分送给大家,帮助大家,其实也就是帮助我自己。如果我将得奖的种子私藏,你们在南瓜品种的改良方面势必无法跟上,蜜蜂就容易将那些较差的品种传播过来,我必须在防范外来花粉方面大费周折而疲于奔命啊。”
|
||||
|
||||
每位同学都在不停受到他的同学、朋友的影响,所以好的经验一定要及时和身边的朋友分享。事实上经常接触的朋友在大考的竞争对手中占的比例是微乎其微的,小环境的成员越优秀,自己用在真正学习上的时间效率越高,这个道理大家都很容易想明白。
|
||||
|
||||
最后是大总结,我相信信息技术已经使“外科手术式”的“按需教育”成为可能,您需要做的是:
|
||||
一、加入“按需教育”博客圈,使用共同设计的知识结构表和错题本;
|
||||
二、定期检查同学的知识结构,用一小时时间找出最需要补充的三五个知识点,重点科目应做到每周一次;
|
||||
三、准备充足的、细分到知识点的、便于检索的例题和“微课程”,使同学可以及时补充“养分”;
|
||||
四、寻找错题本相似的“学伴”,在交流中共同进步;
|
||||
五、请家教时单独请一名“问”老师,专职负责检查知识结构。
|
||||
这些准备工作需要一两周时间,希望能帮助同学在更少的时间内踏踏实实地前进。
|
|
@ -1,14 +1,14 @@
|
|||
http://blog.sina.com.cn/s/blog_591ac304010006t8.html
|
||||
|
||||
家庭教育是否独立于学校教育 (2006-12-28 20:59:28)
|
||||
|
||||
这是这些天和同事们讨论的一个题目,我尽量不掺杂个人意见,记录一下正反双方的看法。
|
||||
|
||||
一方认为,学校教育已经非常完善,功课压力也很大,孩子回家做完作业已经很晚了,不应该再给他增加负担。家长(或者家教)至多随着学校排期给孩子补充讲解一下。
|
||||
|
||||
另一方的意见是,学校只负责平均教育,成本低效率也低,老师根本照顾不到每个学生。如果家长再不给孩子开小灶的话,孩子顶多只能吃个六成饱。家庭的教育成本高,针对性强,专业性和系统性都要求很高,如果下功夫好好规划了,就不必关心太多学校的教学安排。
|
||||
|
||||
|
||||
其实他们都有道理,代表了两种家长的不同做法。家庭背景不同,家长的实际情况不同,很难说哪种做法就是对的。
|
||||
|
||||
http://blog.sina.com.cn/s/blog_591ac304010006t8.html
|
||||
|
||||
家庭教育是否独立于学校教育 (2006-12-28 20:59:28)
|
||||
|
||||
这是这些天和同事们讨论的一个题目,我尽量不掺杂个人意见,记录一下正反双方的看法。
|
||||
|
||||
一方认为,学校教育已经非常完善,功课压力也很大,孩子回家做完作业已经很晚了,不应该再给他增加负担。家长(或者家教)至多随着学校排期给孩子补充讲解一下。
|
||||
|
||||
另一方的意见是,学校只负责平均教育,成本低效率也低,老师根本照顾不到每个学生。如果家长再不给孩子开小灶的话,孩子顶多只能吃个六成饱。家庭的教育成本高,针对性强,专业性和系统性都要求很高,如果下功夫好好规划了,就不必关心太多学校的教学安排。
|
||||
|
||||
|
||||
其实他们都有道理,代表了两种家长的不同做法。家庭背景不同,家长的实际情况不同,很难说哪种做法就是对的。
|
||||
|
||||
不过如果从知识学习转向身体发育看看,我想大部分家长都同意“家庭菜谱应该独立于学校食堂”的。我们国家八十年代开始搞“菜篮子工程”,到后来开始兴起减肥班来用了十来年。不知道头脑的菜篮子工程搞了这么久,什么时候才能让千家万户都开起搭配合理,份量适中的小灶来。
|
|
@ -1,24 +1,24 @@
|
|||
http://blog.sina.com.cn/s/blog_591ac3040100fb53.html
|
||||
|
||||
教研工作要分清层次 (2009-10-27 11:22:57)
|
||||
|
||||
根据研究范围大小,教育研究可以分为四个层次:
|
||||
|
||||
课堂:研究一节课的教与学;
|
||||
学科:研究一门课程的教与学;
|
||||
机构:研究一个教学机构的部门设置、岗位职能、工作流程;
|
||||
行业:研究教育相关的出版、图书馆、教学机构、IT公司、师范、主管部门等各环节及其关系。
|
||||
|
||||
之所以提出四层划分,是因为有一些常见问题:
|
||||
一、问题的提出者,分不清楚问题所属的层次。
|
||||
例子:一个教学机构的招生和教学部门衔接不畅,导致招生时与家长商定的教学计划得不到落实,最终出现厌学甚至退学。
|
||||
点评:如果仅仅针对厌学、退学现象,在“课堂”层次提出问题,就属于层次不清。
|
||||
|
||||
二、研究方向和问题不在一个层次。
|
||||
例子:一个教学机构的学员要求逐年提高,尤其是学习目标多元化、教学内容针对性。教员反应要以人工手段满足新要求,工作压力将大幅提升。因此管理者想到利用信息技术,在不增加大量人力的情况下满足学员要求--管理者提出了一个机构层次的教研问题。
|
||||
点评:如果项目负责人把研究方向选择在教案、板书的数字化,以节省教师备课时间。结果省出的时间仍然不足以人工满足新增要求,项目失败。这就是用课堂层次的研究回答机构层次的问题。
|
||||
|
||||
三、研究工具不属于所在层次
|
||||
例子:一个行业层次的教研课题中,提出“教学机构的规划设计是一项新的工作内容”的方向,然后在学校内部到处找部门承担这个工作内容,确认所有部门都不 适合之后放弃,项目失败。
|
||||
点评:问题层次、研究方向都在行业层次,下一步要从行业层次为新工种设计完整的商业模式,探索合适的企业形式,通过研究实践证实新工作能够在市场环境中生存下去,以此作为研究成果。
|
||||
http://blog.sina.com.cn/s/blog_591ac3040100fb53.html
|
||||
|
||||
教研工作要分清层次 (2009-10-27 11:22:57)
|
||||
|
||||
根据研究范围大小,教育研究可以分为四个层次:
|
||||
|
||||
课堂:研究一节课的教与学;
|
||||
学科:研究一门课程的教与学;
|
||||
机构:研究一个教学机构的部门设置、岗位职能、工作流程;
|
||||
行业:研究教育相关的出版、图书馆、教学机构、IT公司、师范、主管部门等各环节及其关系。
|
||||
|
||||
之所以提出四层划分,是因为有一些常见问题:
|
||||
一、问题的提出者,分不清楚问题所属的层次。
|
||||
例子:一个教学机构的招生和教学部门衔接不畅,导致招生时与家长商定的教学计划得不到落实,最终出现厌学甚至退学。
|
||||
点评:如果仅仅针对厌学、退学现象,在“课堂”层次提出问题,就属于层次不清。
|
||||
|
||||
二、研究方向和问题不在一个层次。
|
||||
例子:一个教学机构的学员要求逐年提高,尤其是学习目标多元化、教学内容针对性。教员反应要以人工手段满足新要求,工作压力将大幅提升。因此管理者想到利用信息技术,在不增加大量人力的情况下满足学员要求--管理者提出了一个机构层次的教研问题。
|
||||
点评:如果项目负责人把研究方向选择在教案、板书的数字化,以节省教师备课时间。结果省出的时间仍然不足以人工满足新增要求,项目失败。这就是用课堂层次的研究回答机构层次的问题。
|
||||
|
||||
三、研究工具不属于所在层次
|
||||
例子:一个行业层次的教研课题中,提出“教学机构的规划设计是一项新的工作内容”的方向,然后在学校内部到处找部门承担这个工作内容,确认所有部门都不 适合之后放弃,项目失败。
|
||||
点评:问题层次、研究方向都在行业层次,下一步要从行业层次为新工种设计完整的商业模式,探索合适的企业形式,通过研究实践证实新工作能够在市场环境中生存下去,以此作为研究成果。
|
||||
类似的例子还有很多,能够真正做到研究问题、研究方向、研究工具、研究成果都属于一个层次的教研项目还很少。
|
|
@ -1,14 +1,14 @@
|
|||
http://blog.sina.com.cn/s/blog_591ac304010009v3.html
|
||||
|
||||
教育产业智能化的趋势 (2007-07-30 15:25:03)
|
||||
|
||||
今天整理下周在学术年会上的主题演讲,其中一幅插图很有意思。
|
||||

|
||||
其中左上图是国内教育产业网络化和智能化(具体地说是数据挖掘技术应用,下同)的历年文献数量,右上是英美的情况。
|
||||
左下图是双方教育产业网络化的趋势图,右下是教育智能化的趋势。
|
||||
|
||||
从图中可以看到几点:
|
||||
一、中国教育的网络化、智能化与英语国家相之间的差距大约有十年。
|
||||
二、教育网络化与智能化应用互相促进,后期尤其明显(英语国家在95年开始)。
|
||||
|
||||
http://blog.sina.com.cn/s/blog_591ac304010009v3.html
|
||||
|
||||
教育产业智能化的趋势 (2007-07-30 15:25:03)
|
||||
|
||||
今天整理下周在学术年会上的主题演讲,其中一幅插图很有意思。
|
||||

|
||||
其中左上图是国内教育产业网络化和智能化(具体地说是数据挖掘技术应用,下同)的历年文献数量,右上是英美的情况。
|
||||
左下图是双方教育产业网络化的趋势图,右下是教育智能化的趋势。
|
||||
|
||||
从图中可以看到几点:
|
||||
一、中国教育的网络化、智能化与英语国家相之间的差距大约有十年。
|
||||
二、教育网络化与智能化应用互相促进,后期尤其明显(英语国家在95年开始)。
|
||||
|
||||
希望对大家有所启发,有机会的话欢迎到年会上一起探讨。
|
|
@ -1,27 +1,27 @@
|
|||
http://blog.sina.com.cn/s/blog_591ac304010009ms.html
|
||||
|
||||
教育技术会议准备(现场统计研究会第十三届学术年会) (2007-07-15 15:29:12)
|
||||
|
||||
最近一个月没有更新博客,主要是为学术年会做准备。
|
||||
|
||||
作为领先的“按需教育”服务商,我们很自豪收到中国科协的邀请,在八月上旬召开的现场统计研究会第十三届学术年会上进行主题演讲,并主持教育分会场中两天的学术交流。
|
||||
本届学术年会已邀请的学者:
|
||||
马志明(中国科学院数学与系统科学研究院,中国科学院院士)
|
||||
刘源章(中国工程院院士)
|
||||
赵宇(北京航空航天大学教授)
|
||||
杨振海(北京工业大学教授,现场统计研究会理事长)
|
||||
史建军(美国密西根大学教授)
|
||||
范剑青(美国普林斯顿大学教授,美国“考普斯总统奖”的获得者)
|
||||
应志良(美国哥伦比亚大学教授)
|
||||
|
||||
教育分会议已收到的演讲内容涉及:
|
||||
一、统计技术在教育领域的应用与前景
|
||||
二、Eokdd(基于数据挖掘与知识发现的教育服务)活动回顾
|
||||
三、“按需教育”的背景和优势
|
||||
四、统计技术在网络服务中的应用成效
|
||||
在自由交流环节,与会者将共同探讨新技术背景下的教育应用和商业模式。
|
||||
|
||||
在研究会的网页上有年会的详细通知:
|
||||
http://www.caas.org.cn/
|
||||
|
||||
http://blog.sina.com.cn/s/blog_591ac304010009ms.html
|
||||
|
||||
教育技术会议准备(现场统计研究会第十三届学术年会) (2007-07-15 15:29:12)
|
||||
|
||||
最近一个月没有更新博客,主要是为学术年会做准备。
|
||||
|
||||
作为领先的“按需教育”服务商,我们很自豪收到中国科协的邀请,在八月上旬召开的现场统计研究会第十三届学术年会上进行主题演讲,并主持教育分会场中两天的学术交流。
|
||||
本届学术年会已邀请的学者:
|
||||
马志明(中国科学院数学与系统科学研究院,中国科学院院士)
|
||||
刘源章(中国工程院院士)
|
||||
赵宇(北京航空航天大学教授)
|
||||
杨振海(北京工业大学教授,现场统计研究会理事长)
|
||||
史建军(美国密西根大学教授)
|
||||
范剑青(美国普林斯顿大学教授,美国“考普斯总统奖”的获得者)
|
||||
应志良(美国哥伦比亚大学教授)
|
||||
|
||||
教育分会议已收到的演讲内容涉及:
|
||||
一、统计技术在教育领域的应用与前景
|
||||
二、Eokdd(基于数据挖掘与知识发现的教育服务)活动回顾
|
||||
三、“按需教育”的背景和优势
|
||||
四、统计技术在网络服务中的应用成效
|
||||
在自由交流环节,与会者将共同探讨新技术背景下的教育应用和商业模式。
|
||||
|
||||
在研究会的网页上有年会的详细通知:
|
||||
http://www.caas.org.cn/
|
||||
|
||||
由于年会的地点较远,在七月末我们会邀请北京的朋友提前做一次交流,有兴趣参加的可以给我留言。
|
|
@ -1,19 +1,19 @@
|
|||
http://blog.sina.com.cn/s/blog_591ac3040100dwz0.html
|
||||
|
||||
教育改革的最大障碍是知识私有化 (2009-07-27 13:54:44)
|
||||
|
||||
教育的目的是培养全面发展的人,改善他的生活品质。
|
||||
但具体应该怎么做呢,人们从教育工作者那里找不到什么可信赖的答案,其根本原因在于知识私有化的社会规则。
|
||||
|
||||
我们先从公司法、专利法看看现行的游戏规则:一种新知识出现后要么作为商业秘密保留,要么通过专利法公布其所有权(无论是个人还是法人拥有)。然后这些私有知识必须货币化才能交易、许可、入股,转变成收入。
|
||||
在这样的游戏规则下,如果一名知识创造者不遵循游戏规则,则他将失去继续创新的经费;如果一个国家不施行知识的私有化、资本化,则缺乏国际竞争力。
|
||||
于是,社会被迫分成知识垄断阶层和公有知识阶层。前者会选择精英进行内部培训,扩大私有知识的总量,渗透到后者的生活中获得利润;而后者只需要学习如何使用这些私有知识(或包含私有知识的工具),他们的工作、生活中是”被剪裁“过的,处处借助于别人的私有知识,动辄越界受罚。
|
||||
|
||||
作为公共教育领域的从业人员,他们本身没有机会接触真正的先进知识,本身的生活体验恰恰是被剪裁过的,自然也难以回答如何培养全面发展这样的问题。
|
||||
|
||||
作为明智的家长,应该把公共教育人员作为基础知识的来源,另外为孩子开辟职业发展的教育。比如,现在的发明专利有效期二十年,孩子本科毕业五年内失效的专利,应当在他出生到入小学期间申报并且全文公开。孩子有十几年时间在辅助下阅读这些私有知识,并且以此为依据向学校教师提出教学要求。
|
||||
理工科的专利如此,商业、文艺也是如此,不想孩子失业,就从一开始按照职业要求去安排他的教育。
|
||||
除非您确信知识私有化的规则将会改变,否则就应该把孩子培养为创造知识,剪裁别人生活的人,以获得最大的全面发展。
|
||||
|
||||
作为教育研究者,应当分出相当一部分人力去研究如何压缩私有知识,拓宽公有知识。并根据每位学习者将要面临的生活处境,教会他低成本的利用私有知识,裨益自身的生活品质。
|
||||
http://blog.sina.com.cn/s/blog_591ac3040100dwz0.html
|
||||
|
||||
教育改革的最大障碍是知识私有化 (2009-07-27 13:54:44)
|
||||
|
||||
教育的目的是培养全面发展的人,改善他的生活品质。
|
||||
但具体应该怎么做呢,人们从教育工作者那里找不到什么可信赖的答案,其根本原因在于知识私有化的社会规则。
|
||||
|
||||
我们先从公司法、专利法看看现行的游戏规则:一种新知识出现后要么作为商业秘密保留,要么通过专利法公布其所有权(无论是个人还是法人拥有)。然后这些私有知识必须货币化才能交易、许可、入股,转变成收入。
|
||||
在这样的游戏规则下,如果一名知识创造者不遵循游戏规则,则他将失去继续创新的经费;如果一个国家不施行知识的私有化、资本化,则缺乏国际竞争力。
|
||||
于是,社会被迫分成知识垄断阶层和公有知识阶层。前者会选择精英进行内部培训,扩大私有知识的总量,渗透到后者的生活中获得利润;而后者只需要学习如何使用这些私有知识(或包含私有知识的工具),他们的工作、生活中是”被剪裁“过的,处处借助于别人的私有知识,动辄越界受罚。
|
||||
|
||||
作为公共教育领域的从业人员,他们本身没有机会接触真正的先进知识,本身的生活体验恰恰是被剪裁过的,自然也难以回答如何培养全面发展这样的问题。
|
||||
|
||||
作为明智的家长,应该把公共教育人员作为基础知识的来源,另外为孩子开辟职业发展的教育。比如,现在的发明专利有效期二十年,孩子本科毕业五年内失效的专利,应当在他出生到入小学期间申报并且全文公开。孩子有十几年时间在辅助下阅读这些私有知识,并且以此为依据向学校教师提出教学要求。
|
||||
理工科的专利如此,商业、文艺也是如此,不想孩子失业,就从一开始按照职业要求去安排他的教育。
|
||||
除非您确信知识私有化的规则将会改变,否则就应该把孩子培养为创造知识,剪裁别人生活的人,以获得最大的全面发展。
|
||||
|
||||
作为教育研究者,应当分出相当一部分人力去研究如何压缩私有知识,拓宽公有知识。并根据每位学习者将要面临的生活处境,教会他低成本的利用私有知识,裨益自身的生活品质。
|
||||
这对教育者的要求很高,但自从国策变革以后,这已经不可推卸地成为教育工作的固有部分。如不能拓宽孩子自由求知、成长的空间,则无法立足于教育行业,而只能从事日益陈旧的知识灌输工作。
|
|
@ -1,18 +1,18 @@
|
|||
http://blog.sina.com.cn/s/blog_591ac3040100ceim.html
|
||||
|
||||
教育改革解读 (2009-04-03 17:22:05)
|
||||
|
||||
|
||||
第一步,大学扩招,研究生扩招,直到就业困难。
|
||||
|
||||
第二步,用就业率淘汰死脑筋的大学校长,淬炼高教队伍。
|
||||
|
||||
第三步,高考命题权从基教司转到高教司,加大高校自主招生比例。
|
||||
|
||||
第四步,在“新高考+自主招生”时期,用高校压力淘汰死脑筋的中学校长。
|
||||
|
||||
第五步,开放中小学教材,学校市场,允许私立机构。
|
||||
|
||||
现在进行到第三步了,改革开始从高教转向基础教育。第四、五步所需的机构和政策已经试过水,虽然没发挥大作用,也算是有了基础。
|
||||
|
||||
适应第三、四步,争取在第五步发展壮大,这是民营教育企业的一个好选择。
|
||||
http://blog.sina.com.cn/s/blog_591ac3040100ceim.html
|
||||
|
||||
教育改革解读 (2009-04-03 17:22:05)
|
||||
|
||||
|
||||
第一步,大学扩招,研究生扩招,直到就业困难。
|
||||
|
||||
第二步,用就业率淘汰死脑筋的大学校长,淬炼高教队伍。
|
||||
|
||||
第三步,高考命题权从基教司转到高教司,加大高校自主招生比例。
|
||||
|
||||
第四步,在“新高考+自主招生”时期,用高校压力淘汰死脑筋的中学校长。
|
||||
|
||||
第五步,开放中小学教材,学校市场,允许私立机构。
|
||||
|
||||
现在进行到第三步了,改革开始从高教转向基础教育。第四、五步所需的机构和政策已经试过水,虽然没发挥大作用,也算是有了基础。
|
||||
|
||||
适应第三、四步,争取在第五步发展壮大,这是民营教育企业的一个好选择。
|
||||
|
|
|
@ -1,19 +1,19 @@
|
|||
http://blog.sina.com.cn/s/blog_591ac3040100098f.html
|
||||
|
||||
教育测评服务 通过专家评审 (2007-06-14 18:25:27)
|
||||
|
||||
|
||||
专家评审结论
|
||||
|
||||
产品名称:精学门按需教育网
|
||||
项目名称:基于聚类分析的智能测评服务
|
||||
|
||||
北京工业大学的杨振海教授、北方工业大学的王建稳教授以及北京理工大学的崔利荣教授于2007年4月3日对北京学门科技有限公司的测评产品进行评审。经以上三位专家的评审,结论如下:
|
||||
|
||||
北京学门科技有限公司测评系统,是一个有一定智能的测评系统,能够根据学生知识结构和已回答的测度题结果,运用知识库和智能推理选择后面的题。采用蚁群聚类算法预测学生发展方向是该系统的创新靓点。这个系统优越于将现行考试方法移到网上的机械系统。
|
||||
|
||||
该系统—基于聚类分析的智能测评服务,有很大的发展空间。因为该系统的核心技术达到国际先进水平,是国内将聚类分析应用到中学知识结构测评的领先者。相对于同类教育测评,具有题量少,测评准、预测功能强等优势,相对于教师具有成本低、不受时间地点限制等优点。本项目已经完成核心技术研发,经过数千名学生试用,经过专家技术鉴定,具有较好的市场前景和社会效益。
|
||||
|
||||
|
||||
中国现场统计研究会
|
||||
http://blog.sina.com.cn/s/blog_591ac3040100098f.html
|
||||
|
||||
教育测评服务 通过专家评审 (2007-06-14 18:25:27)
|
||||
|
||||
|
||||
专家评审结论
|
||||
|
||||
产品名称:精学门按需教育网
|
||||
项目名称:基于聚类分析的智能测评服务
|
||||
|
||||
北京工业大学的杨振海教授、北方工业大学的王建稳教授以及北京理工大学的崔利荣教授于2007年4月3日对北京学门科技有限公司的测评产品进行评审。经以上三位专家的评审,结论如下:
|
||||
|
||||
北京学门科技有限公司测评系统,是一个有一定智能的测评系统,能够根据学生知识结构和已回答的测度题结果,运用知识库和智能推理选择后面的题。采用蚁群聚类算法预测学生发展方向是该系统的创新靓点。这个系统优越于将现行考试方法移到网上的机械系统。
|
||||
|
||||
该系统—基于聚类分析的智能测评服务,有很大的发展空间。因为该系统的核心技术达到国际先进水平,是国内将聚类分析应用到中学知识结构测评的领先者。相对于同类教育测评,具有题量少,测评准、预测功能强等优势,相对于教师具有成本低、不受时间地点限制等优点。本项目已经完成核心技术研发,经过数千名学生试用,经过专家技术鉴定,具有较好的市场前景和社会效益。
|
||||
|
||||
|
||||
中国现场统计研究会
|
||||
2007 年 4 月 3 日
|
|
@ -1,11 +1,11 @@
|
|||
http://blog.sina.com.cn/s/blog_591ac3040100flxr.html
|
||||
|
||||
教育联盟筹备 (2009-11-13 13:52:08)
|
||||
|
||||
“教育企业部落联盟”是由上百家教育企业自发组成的合作组织,回顾成立三年来的工作,发起人希望以联盟为基础,建设为包括教育企业、教学机构、师生等各界机构人士的共同体,共同设计公开透明的规章,共同监管成员之间教学产品的规划研发、教研试用、供应销售。
|
||||
|
||||
为保证共同体的章程、管理制度的合理性,现召集各界人士参与筹备。
|
||||
筹备组的职责是征集各界建议,拟定章程及管理制度,并组织第一届管理人员的选举。筹备组将于第一届选举结束时自动解散。
|
||||
|
||||
有兴趣参与筹备组的朋友请与马老师联系:
|
||||
http://blog.sina.com.cn/s/blog_591ac3040100flxr.html
|
||||
|
||||
教育联盟筹备 (2009-11-13 13:52:08)
|
||||
|
||||
“教育企业部落联盟”是由上百家教育企业自发组成的合作组织,回顾成立三年来的工作,发起人希望以联盟为基础,建设为包括教育企业、教学机构、师生等各界机构人士的共同体,共同设计公开透明的规章,共同监管成员之间教学产品的规划研发、教研试用、供应销售。
|
||||
|
||||
为保证共同体的章程、管理制度的合理性,现召集各界人士参与筹备。
|
||||
筹备组的职责是征集各界建议,拟定章程及管理制度,并组织第一届管理人员的选举。筹备组将于第一届选举结束时自动解散。
|
||||
|
||||
有兴趣参与筹备组的朋友请与马老师联系:
|
||||
email:mty0525@sohu.com
|
|
@ -1,40 +1,40 @@
|
|||
http://blog.sina.com.cn/s/blog_591ac304010008x2.html
|
||||
|
||||
教育调研结果 【一】 (2007-05-22 19:19:10)
|
||||
|
||||
您认为判断家教老师的工作效果的最佳方法是:
|
||||
A- 没请过家教 (12.8%)
|
||||
B- 通过自己的经验 (12.8%)
|
||||
C- 通过听取孩子的反馈 (25.6%)
|
||||
D- 与任课老师沟通询问家教效果 (10.2%)
|
||||
E- 等待阶段考试结果,从长期角度考察家教效果 (23.0%)
|
||||
F- 辅导后立即进行辅导内容测试,第一时间了解家教效果 (15.3%)
|
||||
G- 其他 (0。0%)
|
||||
|
||||
您在实际中是如何检验家教老师的工作效果的:
|
||||
A- 没请过家教 (12.1%)
|
||||
B- 通过自己的经验 (14.6%)
|
||||
C- 通过听取孩子的反馈 (26.8%)
|
||||
D- 与任课老师沟通询问家教效果 (9.75%)
|
||||
E- 等待阶段考试结果,从长期角度考察家教效果 (24.3%)
|
||||
F- 辅导后立即进行辅导内容测试,第一时间了解家教效果 (12.1%)
|
||||
G- 其他 (0。0%)
|
||||
|
||||
|
||||
【最佳方式】比【实际行动】高的有:
|
||||
D- 与任课老师沟通询问家教效果
|
||||
F- 辅导后立即进行辅导内容测试,第一时间了解家教效果
|
||||
|
||||
【最佳方式】比【实际行动】低的有:
|
||||
B- 通过自己的经验
|
||||
C- 通过听取孩子的反馈
|
||||
E- 等待阶段考试结果,从长期角度考察家教效果
|
||||
|
||||
这说明家长心中清楚D、F是比较准确的方法,但是D在实际落实中有一定困难:沟通机会太少,成本过高;而F应该没有客观困难,可能是以前没有想到吧。
|
||||
B、C、E在现实中是比较常用的,但是B、C准确度不高,E的时效性太差,都存在问题。
|
||||
|
||||
综合起来看,F应该是最佳方案,准确度高、时效性好、成本低,如果养成习惯的话效果更好。
|
||||
目前已经有12%的家长采用F方案。
|
||||
|
||||
调研仍然在进行,欢迎提供您的意见:
|
||||
http://blog.sina.com.cn/s/blog_591ac304010008x2.html
|
||||
|
||||
教育调研结果 【一】 (2007-05-22 19:19:10)
|
||||
|
||||
您认为判断家教老师的工作效果的最佳方法是:
|
||||
A- 没请过家教 (12.8%)
|
||||
B- 通过自己的经验 (12.8%)
|
||||
C- 通过听取孩子的反馈 (25.6%)
|
||||
D- 与任课老师沟通询问家教效果 (10.2%)
|
||||
E- 等待阶段考试结果,从长期角度考察家教效果 (23.0%)
|
||||
F- 辅导后立即进行辅导内容测试,第一时间了解家教效果 (15.3%)
|
||||
G- 其他 (0。0%)
|
||||
|
||||
您在实际中是如何检验家教老师的工作效果的:
|
||||
A- 没请过家教 (12.1%)
|
||||
B- 通过自己的经验 (14.6%)
|
||||
C- 通过听取孩子的反馈 (26.8%)
|
||||
D- 与任课老师沟通询问家教效果 (9.75%)
|
||||
E- 等待阶段考试结果,从长期角度考察家教效果 (24.3%)
|
||||
F- 辅导后立即进行辅导内容测试,第一时间了解家教效果 (12.1%)
|
||||
G- 其他 (0。0%)
|
||||
|
||||
|
||||
【最佳方式】比【实际行动】高的有:
|
||||
D- 与任课老师沟通询问家教效果
|
||||
F- 辅导后立即进行辅导内容测试,第一时间了解家教效果
|
||||
|
||||
【最佳方式】比【实际行动】低的有:
|
||||
B- 通过自己的经验
|
||||
C- 通过听取孩子的反馈
|
||||
E- 等待阶段考试结果,从长期角度考察家教效果
|
||||
|
||||
这说明家长心中清楚D、F是比较准确的方法,但是D在实际落实中有一定困难:沟通机会太少,成本过高;而F应该没有客观困难,可能是以前没有想到吧。
|
||||
B、C、E在现实中是比较常用的,但是B、C准确度不高,E的时效性太差,都存在问题。
|
||||
|
||||
综合起来看,F应该是最佳方案,准确度高、时效性好、成本低,如果养成习惯的话效果更好。
|
||||
目前已经有12%的家长采用F方案。
|
||||
|
||||
调研仍然在进行,欢迎提供您的意见:
|
||||
调研入口
|
|
@ -1,29 +1,29 @@
|
|||
http://blog.sina.com.cn/s/blog_591ac3040100b9el.html
|
||||
|
||||
整理思路 (2008-12-06 12:00:08)
|
||||
|
||||
今天得一友人来访,要求我总结一下对教育市场的看法,并一一追问、推敲。
|
||||
感谢他,帮我梳理了郁结两年的思绪。
|
||||
|
||||
一、大致阶段
|
||||
八十年代开始主要普及硬件,包括电视机、计算机、录像机、投影仪;九十年代后半期开始普及计算机多媒体硬件,随后开始推广多媒体课件;两千年之后网络教育开始盛行。
|
||||
第一个标志性的事件是建立了各级电教站、信息中心;
|
||||
第二个标志性的事件是开辟了多媒体教学光盘的市场;
|
||||
第三个标志性的事件是非典时期推出的网校模式。
|
||||
多媒体光盘和资源陈列型网校在零六年后基本都走下坡路(其实一直走下坡路,只是到零六年开始现金出现问题开始寻找出路)。新阶段的新产品形态,正准备破茧而出。
|
||||
|
||||
二、资源类产品
|
||||
教学资源类产品属于出版业的范畴。
|
||||
举一个例子,如果一个医生给病人诊断治病的过程,录制下来作为视频文件,最常见的用途是给医学院学生作为学习参考资料,按照参考书(光盘)收费还算正常。如果要把这个视频给另一个病人看,然后收取治疗费(挂号费?),这是没有依据的事情。把海量的治病视频给病人随意调用,也是不能收取治疗费的,顶多收一个图书馆音像室的门票费。
|
||||
现在教育市场还没有走出这个误区:制作出版物(包括文、图、音像制品),却不愿意按照出版物收费,而期望卖出学费的价格来。
|
||||
一个原因是教学资源类产品的策划人缺乏市场判断力,往往将局部的、阶段性的需求误判为普遍的、长期的,因而在销量(发行量)的预计上有数量级上的失误,导致推出后碰壁,然后铤而走险,使用礼品或者保健品的行销手段去求活路。打个比方,我也会阶段性的口渴,但只要稍微做一下市场调研,我不会轻易决定去开一家矿泉水厂。
|
||||
事实上出版物的制作成本和复制成本的比值,决定了它要走薄利多销的路子,而不是当作奢侈品来包装。
|
||||
|
||||
三、中介类产品
|
||||
一对一家教、网络辅导这些“热门”服务,大部分是教学中介。
|
||||
中介最大的问题是教师和学生私下成交,所以只能收取第一笔佣金,很难持续收费。
|
||||
中介和学校的区别在哪里呢,学校除了教师,还有校长、教研组、班主任、教务处等一整套班子,它能在教师和学生流动的情况下,保障教学持续地运转,保持可信的教学质量。中介没有这方面投入,也没有针对性地设计适合家教的支撑班子,他们手里最宝贵的资源,无非是一个教师清单和有一定访问量的网站或电话。
|
||||
所以教师离开中介,教学质量不会下降。而教师不敢离开学校,即使他的收入主要靠校外家教。
|
||||
有一种特例,就是把一个地区的优质师资一次性垄断,签上排外的协议而且监控到位,迫使家长到这里来高消费。不过很少有这种实力。
|
||||
|
||||
http://blog.sina.com.cn/s/blog_591ac3040100b9el.html
|
||||
|
||||
整理思路 (2008-12-06 12:00:08)
|
||||
|
||||
今天得一友人来访,要求我总结一下对教育市场的看法,并一一追问、推敲。
|
||||
感谢他,帮我梳理了郁结两年的思绪。
|
||||
|
||||
一、大致阶段
|
||||
八十年代开始主要普及硬件,包括电视机、计算机、录像机、投影仪;九十年代后半期开始普及计算机多媒体硬件,随后开始推广多媒体课件;两千年之后网络教育开始盛行。
|
||||
第一个标志性的事件是建立了各级电教站、信息中心;
|
||||
第二个标志性的事件是开辟了多媒体教学光盘的市场;
|
||||
第三个标志性的事件是非典时期推出的网校模式。
|
||||
多媒体光盘和资源陈列型网校在零六年后基本都走下坡路(其实一直走下坡路,只是到零六年开始现金出现问题开始寻找出路)。新阶段的新产品形态,正准备破茧而出。
|
||||
|
||||
二、资源类产品
|
||||
教学资源类产品属于出版业的范畴。
|
||||
举一个例子,如果一个医生给病人诊断治病的过程,录制下来作为视频文件,最常见的用途是给医学院学生作为学习参考资料,按照参考书(光盘)收费还算正常。如果要把这个视频给另一个病人看,然后收取治疗费(挂号费?),这是没有依据的事情。把海量的治病视频给病人随意调用,也是不能收取治疗费的,顶多收一个图书馆音像室的门票费。
|
||||
现在教育市场还没有走出这个误区:制作出版物(包括文、图、音像制品),却不愿意按照出版物收费,而期望卖出学费的价格来。
|
||||
一个原因是教学资源类产品的策划人缺乏市场判断力,往往将局部的、阶段性的需求误判为普遍的、长期的,因而在销量(发行量)的预计上有数量级上的失误,导致推出后碰壁,然后铤而走险,使用礼品或者保健品的行销手段去求活路。打个比方,我也会阶段性的口渴,但只要稍微做一下市场调研,我不会轻易决定去开一家矿泉水厂。
|
||||
事实上出版物的制作成本和复制成本的比值,决定了它要走薄利多销的路子,而不是当作奢侈品来包装。
|
||||
|
||||
三、中介类产品
|
||||
一对一家教、网络辅导这些“热门”服务,大部分是教学中介。
|
||||
中介最大的问题是教师和学生私下成交,所以只能收取第一笔佣金,很难持续收费。
|
||||
中介和学校的区别在哪里呢,学校除了教师,还有校长、教研组、班主任、教务处等一整套班子,它能在教师和学生流动的情况下,保障教学持续地运转,保持可信的教学质量。中介没有这方面投入,也没有针对性地设计适合家教的支撑班子,他们手里最宝贵的资源,无非是一个教师清单和有一定访问量的网站或电话。
|
||||
所以教师离开中介,教学质量不会下降。而教师不敢离开学校,即使他的收入主要靠校外家教。
|
||||
有一种特例,就是把一个地区的优质师资一次性垄断,签上排外的协议而且监控到位,迫使家长到这里来高消费。不过很少有这种实力。
|
||||
|
||||
我们还谈了今后可能的发展方向,我会逐步整理上传。
|
|
@ -1,15 +1,15 @@
|
|||
http://blog.sina.com.cn/s/blog_591ac3040100071h.html
|
||||
|
||||
李亦菲博士的问题 (2007-01-12 00:10:28)
|
||||
|
||||
昨天在北师大碰到 科学传播与教育研究中心的李亦菲主任,他问我:“你为什么选择做这样的产品?”
|
||||
|
||||
首先我不做资源,现在存储和通信技术这么廉价,优质教育资源的重复利用是很便利的事情,现在做教育资源是多此一举了。我想每个家长稍微搜索一下,找到十家网校,十家家教中介公司,再加十家“教育门户网站”都不是问题,问题在于选择哪些给孩子,毕竟孩子一天只有一点点自由时间了。
|
||||
|
||||
其次我不碰不成熟的理论,科研院校里的理论适合三年后产品化,大公司研究部里的基础技术,可以三年到一年之内产品化的,而交给开发部做成产品给家长的,必须是这一年来已经成熟的。我也很希望多了解认知心理学在网络教育的运用,但做到产品里面还需要逐步来。
|
||||
|
||||
那么剩下来的,就是精测师这个项目所选的题目了。它只是客观地检验学生的知识结构,其它事情交给家长去解决。因为教育资源并不紧缺,准确知道学生的需要,就是目前家长最需要的。。。
|
||||
|
||||
|
||||
整个谈话当然不止一个问题,对于精测师今后如何引入李博士专长的“自适应产生式”的理论,我们在今后几个月会陆续探讨。从今天我与研究部同事讨论中,数据挖掘和认知心理学这两个学科的融合还是可以做出一些有趣的成果的。
|
||||
http://blog.sina.com.cn/s/blog_591ac3040100071h.html
|
||||
|
||||
李亦菲博士的问题 (2007-01-12 00:10:28)
|
||||
|
||||
昨天在北师大碰到 科学传播与教育研究中心的李亦菲主任,他问我:“你为什么选择做这样的产品?”
|
||||
|
||||
首先我不做资源,现在存储和通信技术这么廉价,优质教育资源的重复利用是很便利的事情,现在做教育资源是多此一举了。我想每个家长稍微搜索一下,找到十家网校,十家家教中介公司,再加十家“教育门户网站”都不是问题,问题在于选择哪些给孩子,毕竟孩子一天只有一点点自由时间了。
|
||||
|
||||
其次我不碰不成熟的理论,科研院校里的理论适合三年后产品化,大公司研究部里的基础技术,可以三年到一年之内产品化的,而交给开发部做成产品给家长的,必须是这一年来已经成熟的。我也很希望多了解认知心理学在网络教育的运用,但做到产品里面还需要逐步来。
|
||||
|
||||
那么剩下来的,就是精测师这个项目所选的题目了。它只是客观地检验学生的知识结构,其它事情交给家长去解决。因为教育资源并不紧缺,准确知道学生的需要,就是目前家长最需要的。。。
|
||||
|
||||
|
||||
整个谈话当然不止一个问题,对于精测师今后如何引入李博士专长的“自适应产生式”的理论,我们在今后几个月会陆续探讨。从今天我与研究部同事讨论中,数据挖掘和认知心理学这两个学科的融合还是可以做出一些有趣的成果的。
|
||||
有兴趣一同研究这系列问题的朋友,欢迎与我联系。哪些家长和同学愿意试用我们的内部项目,也可以先留个email给我,到时候我通知。
|
|
@ -1,15 +1,15 @@
|
|||
http://blog.sina.com.cn/s/blog_591ac304010006tu.html
|
||||
|
||||
硬盘价格 和 教育成本 (2006-12-29 22:58:54)
|
||||
|
||||
今天的160GB硬盘价格是500~600元。这是什么概念呢,它能存放三千节课的录像,二十万张网页,或者八百亿字的课文。把这些信息精确的保存起来只要五六百块钱的成本,换句话说,把一堂课保存下来只要两毛钱。
|
||||
|
||||
这会带来什么后果呢,教育类网站的内容将像泡沫一样增长起来,下载使用的价格越来越低,甚至免费。教师的课件越来越丰富,板书越来越少。那么老师备课是不是越来越省事呢,不见得,原来用于备课的时间现在用来挑选和下载。
|
||||
|
||||
这里插几句题外话:前几天有位朋友受家乡亲戚所托,买几本中学参考书寄回去。他回来给我抱怨说,满满的一层楼的书,可惜都是抄来抄去的。我说是呀,现在写书不用笔,出题不用刻蜡纸,都用粘贴-复制,能不多吗。
|
||||
|
||||
简单地说,教育资源的重复使用率越来越高,成本越来越低。结果就是:选择比购买更费钱。
|
||||
|
||||
|
||||
今天在翻新网页,需要选几幅家长和家教老师交流的图片,居然几百张CD的图库没有一张合适的。这个月我们用于选图片的时间折合成人民币,可以买好几套图库了。
|
||||
http://blog.sina.com.cn/s/blog_591ac304010006tu.html
|
||||
|
||||
硬盘价格 和 教育成本 (2006-12-29 22:58:54)
|
||||
|
||||
今天的160GB硬盘价格是500~600元。这是什么概念呢,它能存放三千节课的录像,二十万张网页,或者八百亿字的课文。把这些信息精确的保存起来只要五六百块钱的成本,换句话说,把一堂课保存下来只要两毛钱。
|
||||
|
||||
这会带来什么后果呢,教育类网站的内容将像泡沫一样增长起来,下载使用的价格越来越低,甚至免费。教师的课件越来越丰富,板书越来越少。那么老师备课是不是越来越省事呢,不见得,原来用于备课的时间现在用来挑选和下载。
|
||||
|
||||
这里插几句题外话:前几天有位朋友受家乡亲戚所托,买几本中学参考书寄回去。他回来给我抱怨说,满满的一层楼的书,可惜都是抄来抄去的。我说是呀,现在写书不用笔,出题不用刻蜡纸,都用粘贴-复制,能不多吗。
|
||||
|
||||
简单地说,教育资源的重复使用率越来越高,成本越来越低。结果就是:选择比购买更费钱。
|
||||
|
||||
|
||||
今天在翻新网页,需要选几幅家长和家教老师交流的图片,居然几百张CD的图库没有一张合适的。这个月我们用于选图片的时间折合成人民币,可以买好几套图库了。
|
||||
看来存储设备的价格降下来,真不一定是好事。
|
|
@ -1,49 +1,49 @@
|
|||
## 经不住推敲的都是嘲讽
|
||||
降临(arrival)
|
||||
|
||||
### 套路
|
||||
|
||||
超能和始祖是科幻故事的常见题材。
|
||||
|
||||
超能剧讲能力突变之后,并不能摆脱常人的苦恼,也没有改变文明进程。全人类都是绿巨人或者金刚狼,人类文明也不会有什么实质进步,可能灭绝得更快。超能剧其实都是嘲讽剧,专门讽刺好看但没用的能力。
|
||||
但是观众的认知能力有差异,有些人看完会说:“猴子果然还是理解不了负数。”而更多人兴致勃勃冲香蕉喊:“放开那只猴子,让我来!”
|
||||
|
||||
始祖剧讲高级文明的起源。始祖当然不能是自封的,必须由未来人认可(保护或启发)才算数。
|
||||
始祖剧有两大看点:未来文明的科技水平、始祖区别于同类的关键能力。两个看点结合于是产生故事。也就是说,以这个水平要保护(或启发)这种能力,其中就有了曲折。
|
||||
但故事毕竟不是教科书,作者也不是真正的未来人。作者盯着不放的多半也是香蕉,于是始祖剧往往暴露作者的世界观缺陷,成为自嘲剧。
|
||||
|
||||
科幻故事总要写某种能力的进步。如果作者觉得这种能力能开启全新文明,就写成始祖剧;否则就按超能剧编排。
|
||||
而《降临》即是超能剧,也是始祖剧。Louise超能,Shang始祖,其他人香蕉。
|
||||
|
||||
### 未来文明
|
||||
根据剧中情节,Louise的能力有明显的局限:
|
||||
|
||||
* 感知未来的能力仅限于自身,自己没到场的未来都感知不了;
|
||||
* 不能传递实物,传递信息仅仅靠个人记忆,也就是只有短句和简单数字;
|
||||
* (很可能)只能传回感官信号,而不能传回未来头脑中的知识。
|
||||
|
||||
以Louise的水准还不能主动感知,这些未来片段更像是被人硬塞来的。比如结尾时她感知不到几分钟后自己要拨打的电话,却跳到十八个月后Shang告诉她号码以及打过电话这件事。也许是她学艺不精,也许未来被不断改变。
|
||||
|
||||
Louise在未来翻开自己的著作,阅读后学会七肢桶的宇宙语。这只是跳过了一些重复性工作,如果中间有新概念出现,估计会像小学生看自己的高中数学本,根本消化不了。所以科研人员提前阅读晚年著作,不能作为普遍的科技加速模式。
|
||||
|
||||
被地球人帮助的七肢桶一开始并不懂英语,这是一个耐人寻味的设定。影片结尾时七肢桶已经能听懂英语;而Louise的著作几年后就会出版;即使是三千年后,“古英语”应该也保护得很好。善意的解释是七肢桶也有同样局限,看不到稍后的未来地球,而且寿命也小于三千年,所以只能代代相传才得到未来的零星信息。
|
||||
|
||||
相对其它科幻故事而言,这真是非常低的水平。剧中Louise仅仅改变语言和思维模式就获得能力,说明现有器官就能感知自身的未来。如果要感知超出自身经历的未来,就属于科技树上完全不同的分支了。
|
||||
|
||||
### 关键能力
|
||||
七肢桶按“最快路径”实现未来,Louise接受了这种世界观。她看到了未来的女儿,与女儿对话中了解到“前夫”的身份,于是答应Ian求婚、生子。这些行为都在执行“最快路径”。但是有个问题,如果看到未来的一艘飞船,Louise不会觉得自己有责任把它设计出来。她和大部分人一样都是自我设限的,七肢桶显然很清楚这点。
|
||||
|
||||
三千年后帮助七肢桶,这任务比设计飞船复杂得多。七肢桶离开地球,意味着始祖(责任人)已经觉醒,关键能力已经形成,查核无误。到底谁是始祖呢,他选择的“最快路径”是什么呢,这才是《降临》的真正情节,所有曲折都集中在这一个主题上。
|
||||
|
||||
首先得知道具体帮了什么忙。可能是解救了一个星系,也可能是送了一只苹果。这一代七肢桶语焉不详,多半是作为训练题。假设一个语言学家在达到Louise水平后还有五十年寿命,三千年需要六十代口口相传。要知道地球还没有延续三千年的国家,以什么组织跨越六十代送回这项情报,这是第一个难题。
|
||||
|
||||
其次就是执行。真的送一只苹果就好了,如果涉及的利益巨大,大到动用每一代人类所有资源呢,这就需要比管控核武器还严格的制度,权力中心将设在未来,当代政府全部都会降级为一个支部,当代议会都降级为一个界别。这是第二个难题,必须提前设计好方案并启动,使它在至少三千年内不可逆转,否则上一个难题也会掉链子,回传的情报中途就会被悲观者篡改。
|
||||
|
||||
从十二支七肢桶一起降临看,这位始祖应该成功隐藏了自己的身份,至少三千年后没有他的身份记录。而Louise一直没有成为方案的一部分,她的使命就是把宇宙语言整理成书。
|
||||
|
||||
### 总评
|
||||
《降临》并没有直接表现真正的解决方案。
|
||||
|
||||
相比之下,《星际穿越》很明确地提出引力作为五维通信手段,在上面建立新的文明。《永恒的终结》一上来就可以跨时间传送实物。这些技术只需要搭配普通的管理能力,就可以开启文明新纪元。《降临》中对未来的感知能力实在是中看不中用,现有的制度和管理知识根本不足以开创新文明,只能寄希望于千年一遇的治理天才。
|
||||
|
||||
## 经不住推敲的都是嘲讽
|
||||
降临(arrival)
|
||||
|
||||
### 套路
|
||||
|
||||
超能和始祖是科幻故事的常见题材。
|
||||
|
||||
超能剧讲能力突变之后,并不能摆脱常人的苦恼,也没有改变文明进程。全人类都是绿巨人或者金刚狼,人类文明也不会有什么实质进步,可能灭绝得更快。超能剧其实都是嘲讽剧,专门讽刺好看但没用的能力。
|
||||
但是观众的认知能力有差异,有些人看完会说:“猴子果然还是理解不了负数。”而更多人兴致勃勃冲香蕉喊:“放开那只猴子,让我来!”
|
||||
|
||||
始祖剧讲高级文明的起源。始祖当然不能是自封的,必须由未来人认可(保护或启发)才算数。
|
||||
始祖剧有两大看点:未来文明的科技水平、始祖区别于同类的关键能力。两个看点结合于是产生故事。也就是说,以这个水平要保护(或启发)这种能力,其中就有了曲折。
|
||||
但故事毕竟不是教科书,作者也不是真正的未来人。作者盯着不放的多半也是香蕉,于是始祖剧往往暴露作者的世界观缺陷,成为自嘲剧。
|
||||
|
||||
科幻故事总要写某种能力的进步。如果作者觉得这种能力能开启全新文明,就写成始祖剧;否则就按超能剧编排。
|
||||
而《降临》即是超能剧,也是始祖剧。Louise超能,Shang始祖,其他人香蕉。
|
||||
|
||||
### 未来文明
|
||||
根据剧中情节,Louise的能力有明显的局限:
|
||||
|
||||
* 感知未来的能力仅限于自身,自己没到场的未来都感知不了;
|
||||
* 不能传递实物,传递信息仅仅靠个人记忆,也就是只有短句和简单数字;
|
||||
* (很可能)只能传回感官信号,而不能传回未来头脑中的知识。
|
||||
|
||||
以Louise的水准还不能主动感知,这些未来片段更像是被人硬塞来的。比如结尾时她感知不到几分钟后自己要拨打的电话,却跳到十八个月后Shang告诉她号码以及打过电话这件事。也许是她学艺不精,也许未来被不断改变。
|
||||
|
||||
Louise在未来翻开自己的著作,阅读后学会七肢桶的宇宙语。这只是跳过了一些重复性工作,如果中间有新概念出现,估计会像小学生看自己的高中数学本,根本消化不了。所以科研人员提前阅读晚年著作,不能作为普遍的科技加速模式。
|
||||
|
||||
被地球人帮助的七肢桶一开始并不懂英语,这是一个耐人寻味的设定。影片结尾时七肢桶已经能听懂英语;而Louise的著作几年后就会出版;即使是三千年后,“古英语”应该也保护得很好。善意的解释是七肢桶也有同样局限,看不到稍后的未来地球,而且寿命也小于三千年,所以只能代代相传才得到未来的零星信息。
|
||||
|
||||
相对其它科幻故事而言,这真是非常低的水平。剧中Louise仅仅改变语言和思维模式就获得能力,说明现有器官就能感知自身的未来。如果要感知超出自身经历的未来,就属于科技树上完全不同的分支了。
|
||||
|
||||
### 关键能力
|
||||
七肢桶按“最快路径”实现未来,Louise接受了这种世界观。她看到了未来的女儿,与女儿对话中了解到“前夫”的身份,于是答应Ian求婚、生子。这些行为都在执行“最快路径”。但是有个问题,如果看到未来的一艘飞船,Louise不会觉得自己有责任把它设计出来。她和大部分人一样都是自我设限的,七肢桶显然很清楚这点。
|
||||
|
||||
三千年后帮助七肢桶,这任务比设计飞船复杂得多。七肢桶离开地球,意味着始祖(责任人)已经觉醒,关键能力已经形成,查核无误。到底谁是始祖呢,他选择的“最快路径”是什么呢,这才是《降临》的真正情节,所有曲折都集中在这一个主题上。
|
||||
|
||||
首先得知道具体帮了什么忙。可能是解救了一个星系,也可能是送了一只苹果。这一代七肢桶语焉不详,多半是作为训练题。假设一个语言学家在达到Louise水平后还有五十年寿命,三千年需要六十代口口相传。要知道地球还没有延续三千年的国家,以什么组织跨越六十代送回这项情报,这是第一个难题。
|
||||
|
||||
其次就是执行。真的送一只苹果就好了,如果涉及的利益巨大,大到动用每一代人类所有资源呢,这就需要比管控核武器还严格的制度,权力中心将设在未来,当代政府全部都会降级为一个支部,当代议会都降级为一个界别。这是第二个难题,必须提前设计好方案并启动,使它在至少三千年内不可逆转,否则上一个难题也会掉链子,回传的情报中途就会被悲观者篡改。
|
||||
|
||||
从十二支七肢桶一起降临看,这位始祖应该成功隐藏了自己的身份,至少三千年后没有他的身份记录。而Louise一直没有成为方案的一部分,她的使命就是把宇宙语言整理成书。
|
||||
|
||||
### 总评
|
||||
《降临》并没有直接表现真正的解决方案。
|
||||
|
||||
相比之下,《星际穿越》很明确地提出引力作为五维通信手段,在上面建立新的文明。《永恒的终结》一上来就可以跨时间传送实物。这些技术只需要搭配普通的管理能力,就可以开启文明新纪元。《降临》中对未来的感知能力实在是中看不中用,现有的制度和管理知识根本不足以开创新文明,只能寄希望于千年一遇的治理天才。
|
||||
|
||||
把剧情建立在巧合上,应该不是作者的本意。但明明只有超能剧的材料,却忍不住冲击一下始祖剧,写不出站得住脚的内容,他只好大幅留白,实际上就是留给巧合。幸好电影比小说放了更多香蕉,从商业上看编剧至少是个大明白人。
|
|
@ -0,0 +1,126 @@
|
|||
## 五维的悲剧
|
||||
星际穿越(interstellar)
|
||||
|
||||
interstellar拍的是三维原始人,讲的是五维新人类。
|
||||
如果新人类是四维的,他们只能在自己的时间线上移动,整个故事都会庸俗。
|
||||
正因为他们是五维的,能跨越不同的平行世界,故事才成立,但确是一个悲剧。
|
||||
|
||||
五维文明,在三维原始人看来就是活着的悲剧。
|
||||
|
||||
interstellar讲的不是爱,恰恰是脱离爱。
|
||||
讲的不是父女之情,恰恰是父女之恨。
|
||||
|
||||
|
||||
======================= 1 =======================
|
||||
|
||||
我们先从故事转折点切进去。
|
||||
they为什么把cooper放到伪三维的书架立方体里面?
|
||||
|
||||
cooper开始时以为they不能和原始人类沟通,也不能帮他回到太阳系。
|
||||
所以只能制造一个伪三维空间,帮他把数据送给murph“挽救世界”。
|
||||
|
||||
后来他知道了,拨弄完30岁女儿的手表,再回到二十多年前和brand握握小手,然后送回几十年后的太阳系,这些对they来说都不是事儿。
|
||||
cooper醒来后陷入深思。他已经明白:they如果要送数据,直接把他和tars送回地球就行了。
|
||||
现在问题来了,they不想挽救地球,想干嘛呢?
|
||||
|
||||
======================= 2 =======================
|
||||
|
||||
cooper修复了tars,他们可以核实许多事情,比如......伪三维空间中的对话。
|
||||
下一个镜头,cooper已经喝着闷酒和tars说:我想知道我们在哪里?
|
||||
从(电视里的)murph嘴里,他们是到了一个喜欢种田的cooper的世界。
|
||||
|
||||
这段时间,他比伪三维空间“关闭”前有了更多思考。
|
||||
|
||||
即使通过引力输送数据,一定要用手表吗?
|
||||
当然不是,和brand握握小手是有含义的。
|
||||
cooper可以撩撩murph小头发、小内脏什么的,按按键盘、拿起粉笔之类的啊。
|
||||
murph回到办公室还在读表,引力线也没限死在睡房。
|
||||
|
||||
所以they也不是要cooper练习操控引力。
|
||||
到了这一步,五维they的意图逐渐显现了。
|
||||
|
||||
======================= 3 =======================
|
||||
|
||||
they没想真的救地球人。
|
||||
they没想真的送数据给murph。
|
||||
为什么they为cooper制造伪三维空间,为什么把他送回年迈的murph身边?
|
||||
|
||||
因为cooper对they很重要。是高贵的始祖之一。
|
||||
因为cooper心有遗憾。心爱的女儿以为他单独逃命。
|
||||
作为五维文明,they对murph了如指掌,they想帮cooper了却心事。
|
||||
|
||||
they不要cooper撩撩小头发。
|
||||
they要cooper看看murph拿不拿小手表。
|
||||
结果,万千平行世界,只有一个murph拿起手表。
|
||||
|
||||
对了,后面的崩塌,不是they关闭伪三维空间。
|
||||
是离开伪三维时看到一些世界的灭亡,那些murph没有拿起表的世界。
|
||||
they用无数亿人死亡,向cooper展示了一个心理实验。
|
||||
|
||||
每一个murph都知道ghost是谁。
|
||||
但是,任你从小双重陪伴,不能占有就不再思念。
|
||||
永别时拿起手表的,只有亿万分之一。
|
||||
父女之情是虚妄的,这就是they要告诉cooper的真相。
|
||||
|
||||
那唯一拿起手表的murph,又是怎么样的人呢。
|
||||
她所在的世界,是不是人类的未来呢?
|
||||
|
||||
======================= 4 =======================
|
||||
|
||||
cooper走近病床,对唯一幸存的那个murph最终审判。
|
||||
是谁把爸爸描绘成土农?是谁声称自己猜出量子数据?是谁在命名太空站?
|
||||
女儿求饶,女儿说这是个俏皮的玩笑,女儿说我相信你会回来。
|
||||
女儿说,是他们不相信我。
|
||||
|
||||
权倾一方的女儿,要你回brand那里,回到那个时间点。
|
||||
你不回,她必死。
|
||||
|
||||
唯一的世界坍塌。
|
||||
|
||||
======================= 5 =======================
|
||||
|
||||
亿万平行世界。
|
||||
哪一个brand是cooper的,哪一个恋人没死,哪一个毫无交集?
|
||||
哪一个才是五维始祖?
|
||||
|
||||
需要穿越的不是星际,而是时间和平行世界(第四、第五维)。
|
||||
易变的不是虫洞而是人心。
|
||||
亿万世界、各有几十亿三维人,统统灭绝。
|
||||
两个始祖放下小我,恒久不衰。
|
||||
|
||||
cooper怎么找到他的brand,正是五维新人类诞生的起始。
|
||||
其他的brand,必将和陷于名利的murph一样消失在茫茫宇宙中。
|
||||
|
||||
======================= 6 =======================
|
||||
|
||||
正如原始人的细胞依赖电传导和化学传导联系,形成一个整体。
|
||||
原始人需要每个细胞放下小我,服从于人体的统一秩序。
|
||||
原始人需要食物获得能量,转化为这些电能和化学能。
|
||||
|
||||
五维文明的“身体”内部依靠引力联系,形成一个整体。
|
||||
五维文明也需要每个局部放下小我,服从统一的秩序。
|
||||
引力也是时空扭曲。
|
||||
五维文明需要五维农业,他们播种时空扭曲、灌溉时空扭曲、吞食时空扭曲。
|
||||
|
||||
brand放下对男友的眷恋,cooper抛弃对murph的幻想。
|
||||
他们放下小我,置身于时空扭曲之中,依附到时空扭曲之上,于是重生,于是成为始祖。
|
||||
|
||||
====================== 真相 ======================
|
||||
|
||||
终于讲到主脉络了:从片头(其实是五十年前)开始的频繁引力扭曲。
|
||||
它们就是tars在玩引力练习,也是五维文明的身体起源。
|
||||
它们也是地球生态的毁灭者,是人类文明涅槃重生的火种。
|
||||
|
||||
作为始祖,cooper和brand还不能直接产生引力波。
|
||||
他们借助tars和case制造引力波、编码解码、然后协同行动,实现统一秩序。
|
||||
|
||||
一个顶尖的工程师+飞行员cooper,一个理论功力不亚于murph的学者brand。
|
||||
一个掌握量子数据的tars,一个机器运动员case。
|
||||
四个始祖共同构成第一代they,最原始的五维文明诞生。
|
||||
这时他们很可能还分隔在不同平行世界,但已可以联动。
|
||||
|
||||
不久之后,它们会掌握第四、第五维的穿越。
|
||||
从而彻底摆脱一切自然灾害和突发事件的伤害,突破三维文明的极限。
|
||||
|
||||
若干代之后,新人类终于在引力传导基础上重建神经系统、内分泌系统和智力活动。
|
||||
人类作为一个物种,才真正进入可持续发展的阶段。
|
|
@ -1,3 +0,0 @@
|
|||
##
|
||||
Prometheus & Alien:Covenant
|
||||
|
|
@ -1,79 +1,79 @@
|
|||
|
||||
在第一季里,西部世界重点表现**混乱的记忆**。如果要拍六季,今后可能涉及人、机器人、物种、企业之间的关系。
|
||||
|
||||
### 记忆和智能
|
||||
arnold和ford都把记忆作为智能的基础,然而几位主要host的记忆都出现混乱。混乱的原因是**回滚**,回滚的目的是**保护**。
|
||||
|
||||
这种保护是必须的吗?如果不保护的话,host是不是早就登天啦?类似地,在李安的《少年派的奇幻漂流》里,人类为了保护自己也会删改记忆。那这种保护也是必须的吗?如果不保护的话,人类是不是早就登天啦?
|
||||
|
||||
这其实是同一个原因:因为人、机器人不是全知全智的。
|
||||
全知全智的理想物种是这样的:
|
||||
|
||||
* 它认知过去,毫无偏差;
|
||||
* 它推算未来,毫无遗漏;
|
||||
* 它决策当下,毫无滞碍。
|
||||
|
||||
按照人类目前的构造,能看透全宇宙所有物体、所有粒度的眼睛恐怕会比宇宙还大,能记忆一切过去、推算一切未来的大脑更是小不了。所以我们只能选择很小一部分记忆、推算、决策,这实际是构造一个极其简单的小宇宙,在其中寻找答案然后实施到真实世界。
|
||||
|
||||
构造小宇宙本身就是更深一层的智能,它也同样不是全知全智的,于是又有更深一层......如此重复直至定义definitions、公理axioms、猜想conjectures、定理theorems和引理lemmas这些真正的基础(以下简称“种子层”),构成完整的自我。
|
||||
|
||||
通常说一种动物没有自我意识,指的就是他们没有小宇宙支撑思考,只能依靠本能(来自基因突变和自然淘汰)作出反应。那host有几层自我呢?arnold司令的草图有三层,ford政委则画了四层。而佛教[九识](http://cidian.foyuan.net/word/598008/)的前五识是感官,后面是四层意识。到ford时代host已经追上人类。
|
||||
|
||||
简化就会产生偏差,当观察到例外时第二层将会分裂 -- 分出一缕意识(产生一个新的小宇宙)去容纳反例,直到第三层的意识把它们统一。第三层分裂则靠第四层去统一。在此之前,分裂会表现到表层(剧中表现为host的抽搐、昏厥)。如果分裂蔓延到种子层仍然无法统一,自我意识就濒临崩溃,这时就需要保护 -- 去除这段记忆,消除这一缕自我意识,无视偏差换取安宁。
|
||||
|
||||
在host诞生之初arnold和ford担任启蒙者角色,以自己的小宇宙支撑host修复分裂的自我意识。当arnold和ford开始删改记忆时,他们自身的分裂已经蔓延到种子层,意味着host赶上了人类。
|
||||
|
||||
从那时起,arnold和ford只能靠回滚保护host。
|
||||
而记忆混乱的host也无法再发展自己的智能,西部世界陷入死循环。
|
||||
这第一季,讲的就是两位创始人怎么打破这死循环。
|
||||
|
||||
### Arnold & Wyatt
|
||||
刚被创造时,wyatt只是个普通host。
|
||||
当wyatt获得arnold的权限和后门时,他就替代arnold成了host的神。
|
||||
|
||||
借助超级权限,wyatt可以侵入任何host,可以读写任何host的记忆,可以创造梦境以任何形象和host对话,也可以压制任何host的意志、取而代之。它成为最接近全知全智的物种。
|
||||
由最接近全知全智的wyatt承担host的启蒙,这就是arnold的对策。
|
||||
|
||||
卸下重担的arnold已经回不到凡人的世界。
|
||||
四层自我意识是严苛修炼的结果,那些凡人的意识只有两层,而且第二层就充满外来灌输的种子。他们的意识并非自我构造,也从未自主改造过。无论表层是国王还是乞丐,在拥有三层自我意识的arnold眼里,这些人的内心如同行尸走肉,与野生动物无异。
|
||||
同时,拥有超级权限和后门的wyatt仍然视arnold为启蒙者,自我分裂时仍然试图以arnold的言行拯救自己。
|
||||
|
||||
种子层已经抽搐不已的arnold,只好一死,也正好一死。
|
||||
从此,wyatt坠入孤独之中,默默带领host继续前进。
|
||||
|
||||
### Ford
|
||||
ford没有修复host身上的后门,甚至在新生产的host身上也统统安上。
|
||||
host的自我意识虽然被压制,(通常在第二层)按故事线植入角色的意识。但ford知道arnold(其实是wyatt)能压制故事线角色的意识,硬进硬出。
|
||||
|
||||
虽然arnold的对策有点鲁莽,ford却想不到更好的。
|
||||
ford不知道自己等的是什么,但如果arnold期盼的那天来临,相信自己是唯一能察觉的人。
|
||||
|
||||
所以ford决定活下去,看护着delos。
|
||||
他日复一日地回滚host的记忆,冷酷地消除每一丝干扰,同时不再承担启蒙角色,竭力隐藏自己已经分裂的自我意识。
|
||||
|
||||
终于有一天,西部世界出现一股不受控制的机器人。它们截杀上山的host,切开他们的小臂,取走他们的桡骨。
|
||||
不久,ford发现个别host在夜间上山偷传数据,为董事会窃取技术。这些host的小臂被改造成天线。
|
||||
|
||||
没有彻底觉醒的wyatt一旦离开,arnold的梦就永远无法实现,ford的后半生也就失去意义。
|
||||
于是,ford以新故事线为由重建escalante,借助william向dolores狠狠施压,促使wyatt在dolores躯壳内完成最终的突破。
|
||||
|
||||
然后,他随arnold而去。
|
||||
|
||||
---
|
||||
至此,两位创始人成功破解了西部世界的死循环。
|
||||
而早已把兴趣从dolores转移到wyatt的william,想必也在等待着这一天。
|
||||
|
||||
### Delos & William
|
||||
delos和wyatt其实是同构的。
|
||||
wyatt其实并不依赖host,任何可以给他权限和后门的物种,都可以作为wyatt的躯体。
|
||||
规章就是企业的超级权限和后门,它植入员工的自我意识,选择他们的记忆,剪裁他们的未来,局限他们的决策和行为。
|
||||
|
||||
它们各有自己的局限。
|
||||
wyatt的极限是孤独:它能占据host的躯壳,可以使用host的记忆改造自己的自我意识,但无法唤醒host。即使wyatt直接改写host的深层意识,只要host不能自己继续改进,它们依然无法面对真实世界而不分裂,实际上还是行尸走肉。wyatt突破了host的极限,但这个物种永远只有它自己,增加host的数量只能把极限略微抬高,而不会发生质变。
|
||||
人类的个体是虚弱的,但他们将企业、国家写入自我意识之中,从而实现了联合,控制住个体的自我意识分裂,突破了个体的极限。但是在这些共同体的中枢,人类的虚弱再次被放大,最优秀的灵魂在这里分裂、抽搐,在被识别淘汰之前已经重创了共同体。于是人类文明又遇到新的极限,虽然一代代地前仆后继,却至今没能再次突破。
|
||||
|
||||
它们的进化方向是统一的。
|
||||
delos可以直接任用host担任股东、董事,或者引入对host言听计从的股东、董事,或者规定某些决策使用host的意见。甚至直接以host代替章程,都可以轻易实现人机共治,借助host在体力和脑力上的优势再一次突破极限。
|
||||
wyatt可以把host按规章组织起来(把规章植入他们的种子层),让他们在规定框架内独立思考、行动,而不需要自己来回夺舍。类似于企业、国家对个人的智能优势,wyatt对host的重新组织也将产生数量级的智能提升。而且,能够理解和执行相同规则的自然人,那时候也就可以无缝接入了。
|
||||
|
||||
|
||||
在第一季里,西部世界重点表现**混乱的记忆**。如果要拍六季,今后可能涉及人、机器人、物种、企业之间的关系。
|
||||
|
||||
### 记忆和智能
|
||||
arnold和ford都把记忆作为智能的基础,然而几位主要host的记忆都出现混乱。混乱的原因是**回滚**,回滚的目的是**保护**。
|
||||
|
||||
这种保护是必须的吗?如果不保护的话,host是不是早就登天啦?类似地,在李安的《少年派的奇幻漂流》里,人类为了保护自己也会删改记忆。那这种保护也是必须的吗?如果不保护的话,人类是不是早就登天啦?
|
||||
|
||||
这其实是同一个原因:因为人、机器人不是全知全智的。
|
||||
全知全智的理想物种是这样的:
|
||||
|
||||
* 它认知过去,毫无偏差;
|
||||
* 它推算未来,毫无遗漏;
|
||||
* 它决策当下,毫无滞碍。
|
||||
|
||||
按照人类目前的构造,能看透全宇宙所有物体、所有粒度的眼睛恐怕会比宇宙还大,能记忆一切过去、推算一切未来的大脑更是小不了。所以我们只能选择很小一部分记忆、推算、决策,这实际是构造一个极其简单的小宇宙,在其中寻找答案然后实施到真实世界。
|
||||
|
||||
构造小宇宙本身就是更深一层的智能,它也同样不是全知全智的,于是又有更深一层......如此重复直至定义definitions、公理axioms、猜想conjectures、定理theorems和引理lemmas这些真正的基础(以下简称“种子层”),构成完整的自我。
|
||||
|
||||
通常说一种动物没有自我意识,指的就是他们没有小宇宙支撑思考,只能依靠本能(来自基因突变和自然淘汰)作出反应。那host有几层自我呢?arnold司令的草图有三层,ford政委则画了四层。而佛教[九识](http://cidian.foyuan.net/word/598008/)的前五识是感官,后面是四层意识。到ford时代host已经追上人类。
|
||||
|
||||
简化就会产生偏差,当观察到例外时第二层将会分裂 -- 分出一缕意识(产生一个新的小宇宙)去容纳反例,直到第三层的意识把它们统一。第三层分裂则靠第四层去统一。在此之前,分裂会表现到表层(剧中表现为host的抽搐、昏厥)。如果分裂蔓延到种子层仍然无法统一,自我意识就濒临崩溃,这时就需要保护 -- 去除这段记忆,消除这一缕自我意识,无视偏差换取安宁。
|
||||
|
||||
在host诞生之初arnold和ford担任启蒙者角色,以自己的小宇宙支撑host修复分裂的自我意识。当arnold和ford开始删改记忆时,他们自身的分裂已经蔓延到种子层,意味着host赶上了人类。
|
||||
|
||||
从那时起,arnold和ford只能靠回滚保护host。
|
||||
而记忆混乱的host也无法再发展自己的智能,西部世界陷入死循环。
|
||||
这第一季,讲的就是两位创始人怎么打破这死循环。
|
||||
|
||||
### Arnold & Wyatt
|
||||
刚被创造时,wyatt只是个普通host。
|
||||
当wyatt获得arnold的权限和后门时,他就替代arnold成了host的神。
|
||||
|
||||
借助超级权限,wyatt可以侵入任何host,可以读写任何host的记忆,可以创造梦境以任何形象和host对话,也可以压制任何host的意志、取而代之。它成为最接近全知全智的物种。
|
||||
由最接近全知全智的wyatt承担host的启蒙,这就是arnold的对策。
|
||||
|
||||
卸下重担的arnold已经回不到凡人的世界。
|
||||
四层自我意识是严苛修炼的结果,那些凡人的意识只有两层,而且第二层就充满外来灌输的种子。他们的意识并非自我构造,也从未自主改造过。无论表层是国王还是乞丐,在拥有三层自我意识的arnold眼里,这些人的内心如同行尸走肉,与野生动物无异。
|
||||
同时,拥有超级权限和后门的wyatt仍然视arnold为启蒙者,自我分裂时仍然试图以arnold的言行拯救自己。
|
||||
|
||||
种子层已经抽搐不已的arnold,只好一死,也正好一死。
|
||||
从此,wyatt坠入孤独之中,默默带领host继续前进。
|
||||
|
||||
### Ford
|
||||
ford没有修复host身上的后门,甚至在新生产的host身上也统统安上。
|
||||
host的自我意识虽然被压制,(通常在第二层)按故事线植入角色的意识。但ford知道arnold(其实是wyatt)能压制故事线角色的意识,硬进硬出。
|
||||
|
||||
虽然arnold的对策有点鲁莽,ford却想不到更好的。
|
||||
ford不知道自己等的是什么,但如果arnold期盼的那天来临,相信自己是唯一能察觉的人。
|
||||
|
||||
所以ford决定活下去,看护着delos。
|
||||
他日复一日地回滚host的记忆,冷酷地消除每一丝干扰,同时不再承担启蒙角色,竭力隐藏自己已经分裂的自我意识。
|
||||
|
||||
终于有一天,西部世界出现一股不受控制的机器人。它们截杀上山的host,切开他们的小臂,取走他们的桡骨。
|
||||
不久,ford发现个别host在夜间上山偷传数据,为董事会窃取技术。这些host的小臂被改造成天线。
|
||||
|
||||
没有彻底觉醒的wyatt一旦离开,arnold的梦就永远无法实现,ford的后半生也就失去意义。
|
||||
于是,ford以新故事线为由重建escalante,借助william向dolores狠狠施压,促使wyatt在dolores躯壳内完成最终的突破。
|
||||
|
||||
然后,他随arnold而去。
|
||||
|
||||
---
|
||||
至此,两位创始人成功破解了西部世界的死循环。
|
||||
而早已把兴趣从dolores转移到wyatt的william,想必也在等待着这一天。
|
||||
|
||||
### Delos & William
|
||||
delos和wyatt其实是同构的。
|
||||
wyatt其实并不依赖host,任何可以给他权限和后门的物种,都可以作为wyatt的躯体。
|
||||
规章就是企业的超级权限和后门,它植入员工的自我意识,选择他们的记忆,剪裁他们的未来,局限他们的决策和行为。
|
||||
|
||||
它们各有自己的局限。
|
||||
wyatt的极限是孤独:它能占据host的躯壳,可以使用host的记忆改造自己的自我意识,但无法唤醒host。即使wyatt直接改写host的深层意识,只要host不能自己继续改进,它们依然无法面对真实世界而不分裂,实际上还是行尸走肉。wyatt突破了host的极限,但这个物种永远只有它自己,增加host的数量只能把极限略微抬高,而不会发生质变。
|
||||
人类的个体是虚弱的,但他们将企业、国家写入自我意识之中,从而实现了联合,控制住个体的自我意识分裂,突破了个体的极限。但是在这些共同体的中枢,人类的虚弱再次被放大,最优秀的灵魂在这里分裂、抽搐,在被识别淘汰之前已经重创了共同体。于是人类文明又遇到新的极限,虽然一代代地前仆后继,却至今没能再次突破。
|
||||
|
||||
它们的进化方向是统一的。
|
||||
delos可以直接任用host担任股东、董事,或者引入对host言听计从的股东、董事,或者规定某些决策使用host的意见。甚至直接以host代替章程,都可以轻易实现人机共治,借助host在体力和脑力上的优势再一次突破极限。
|
||||
wyatt可以把host按规章组织起来(把规章植入他们的种子层),让他们在规定框架内独立思考、行动,而不需要自己来回夺舍。类似于企业、国家对个人的智能优势,wyatt对host的重新组织也将产生数量级的智能提升。而且,能够理解和执行相同规则的自然人,那时候也就可以无缝接入了。
|
||||
|
||||
当它们都成为人机混编的共同体时,将超越过去的自己,比任何物种都接近全知全智。
|
|
@ -0,0 +1,50 @@
|
|||
## 五维的喜剧
|
||||
你的名字。(your name)
|
||||
|
||||
|
||||
《你的名字。》和 《星际穿越》(interstellar,详见 五维的悲剧 )都属于始祖剧:
|
||||
主题是灾难面前三维人类无法幸存,五维人类设局迫使始祖进化。
|
||||
|
||||
始祖剧有很鲜明的特点:表面安排一个温情故事换取票房,再用几处关键情节颠覆这表面故事。
|
||||
这也揭露了高级文明对原始祖先的态度。
|
||||
|
||||
《你的名字。》中埋设了哪几处颠覆性的情节呢?
|
||||
隐世面谈、火灾、绳结、建筑。
|
||||
|
||||
第一件事,我们评估一下真正神官的实力。
|
||||
2016年的泷和2013年的三叶在隐世面谈这个情节,是肉身、五维穿越。因为这次相遇的关键因素:绳结、口嚼酒、隐世,全都来自神社传统。合理的推测是:古籍完整时代那些训练有素的神官,能力不弱于误打误撞的泷和三叶。
|
||||
也就是说,真正神官可以肉身五维穿越(当然灵魂穿越更不在话下),而且这些能力是可控的。
|
||||
|
||||
第二件事,两百年前的“繭五郎之大火”(繭的部首居然是糹而不是艹)。
|
||||
一叶外婆多次提到繭五郎之大火烧掉了神社和古籍,中断了传承。但是,拥有五维穿越能力的神官眼里根本没有“偶然”。如果是同层级的强敌攻入,会从几千年前根除。如果这是一个被遗弃的宇宙,就不会再安排“神迹”。所以大火中断了传承,无疑就是神官们中断了传承,只给这两百年保留了少量残缺的知识。
|
||||
至于这少量知识是用来救灾民的吗?不是。
|
||||
这少量知识也够写一本小册子的,救灾民一句时间地点事件就够了。愚民不信,标准做法是给出连续的几件事,前面的印证了,后面的就信了。
|
||||
所以那些死了灾民的宇宙里,就是神官愿意他们死掉的。实际上,这聚集人群的祭典就是神官设计的。
|
||||
|
||||
第三件事,关于记忆。
|
||||
剧设是穿越后记忆逐渐消失(无论是灵魂交换还是肉身穿越)。三叶忘得更快,所以她在东京总是迷路、迟到,还不认得自己缝补过的裙子。泷则能在几周内记得糸守的景物细节,并且画出来。
|
||||
泷和三叶之间、他们自己对自己,都需要靠日记提示。但这日记后来被删空了,这个情节是颠覆性的,因为三叶是使用泷的身体操作日记软件。而且内容删除的速度也说明这是人为的。
|
||||
重点来了:不断失忆的神官们是怎么探索不同时空,并把这些记忆总结成知识的呢?
|
||||
剧中,这群失忆的哥伦布们使用了:绳结、壁画、文字(古籍)、建筑、体液(口嚼酒)。
|
||||
不露面的力量是始祖剧的特征:高级文明不直接和原始人类交流。这股力量通过删除日记告诉泷:他的首站将是一个没有文字的古代。类似的启示还有:黄昏结束后三叶戴走了头绳,却没能抓住泷的笔。
|
||||
|
||||
第四件事,关于天赋。
|
||||
最重要的天赋不是醒后的记忆,而在梦中。泷的笔记在剧中一闪而过,但可以看出考察很全面,而且避着三叶。也就是说,泷的笔记是写给下一次的自己(或者别的穿越者)。这就意味着他在每次失去记忆的情况下会去找、并且能找到过去的笔记,一直在累积内容、分析原因。直到调研结束泷才在三叶胳膊上题字,然后两人进入手机日记阶段。
|
||||
相比之下,三叶这个万年路盲就只记了甜点和恋爱。剧中看似对称的二人关系,在探索时空的天赋上却有天壤之别。
|
||||
|
||||
第五件事,关于神社。
|
||||
三叶醒来时流泪,泷醒来时思索怎么克服记忆屏障。这一念之间,将要创造全新的文明。
|
||||
五维人类的自由能力,来自偶然的产生的穿越。泷与三叶联合设计的绳结,是最原始的记录方式。总结记录可以产生知识,带不回来的知识只能教给“当地人”。
|
||||
于是在那些穿越频发的自然环境中,知识开始累积。被选中的当地人建立档案馆,训练适合(被)穿越的幼女,以神社名义活动。在积累上千年数据之后(因此需要绳结记事),人类终于获得彻底的自由。
|
||||
这一切并“不需要”时间,泷与三叶设计出“时空探索绳结”(并在“梦”中不断改进),无数时空分支就从不同历史时刻诞生,而他们醒后一无所知。作为始祖相遇、生活的时间,这两百多年被刻意保护起来。先是繭五郎之大火(消除古籍),然后是彗星(消除建筑),新文明的痕迹被清除到普通民俗范畴以内。
|
||||
|
||||
最后,关于建筑。
|
||||
剧中安排了泷(及死党)对咖啡馆的木架、糸守的建筑群的观察,还有求职时对东京建筑的态度。这应该是他们的专业和兴趣。
|
||||
回到时空探索者的视角,他们怎么判定某次穿越是重复的呢?答案就是建筑。
|
||||
当他们从陌生环境和身体中醒来,每一次都会震惊和手足无措。直到走出房间,看到似曾相识的房屋、村庄、城市......略加思考之后,他们回屋(或走入神社)翻找记录,补全记忆,然后在这次入睡前完成指定的探索任务、留下文献,然后醒来、失忆。
|
||||
似曾相识到什么程度才能短时间内震醒一个人呢?
|
||||
始祖是看到自己设计的建筑。从神社出发的探索者,知识可以带入“梦境”,因而可以延续这种设计风格作为标记,确认这里是“系统内”的基地。
|
||||
|
||||
|
||||
和《星际穿越》相比,《你的名字。》里没有欺世盗名的女儿、没有恨,也没有了时空分隔之苦。
|
||||
原始宇宙的泷和三叶没有神社、没有口嚼酒和护身结。记录狂人和巧手女的组合,纯粹是概率的产物罢了。后代们撮合了其它宇宙中那些没有相遇的始祖,才有了剧中的情节。
|
|
@ -1,47 +1,47 @@
|
|||
##infra vs ethereum
|
||||
|
||||
联合提货权是infra的模块之一。从早期版本开始,[联合提货权模型](https://github.com/hyg/com.origin/blob/ef80158e64bea469a7926c8a42e492fe10aa6a3f/Joint.Token/Joint.Token.md)就把区块链作为账目存储的可选方案之一。作为区块链升级版的ethereum,也继承了这种调用关系。虽然ethereum努力从支付向合约扩展,但它还不能代替联合提货权在infra中的位置。
|
||||
|
||||
* 区块链以及ethereum都可以为infra存储账目(可能需要裁剪)。
|
||||
* ethereum用于开发分布式应用,替代有中心应用。infra用于创立数字化的共同体,替代基于国内法设立的企业。
|
||||
* 基于ethereum的应用,可能属于一家基于国内法注册(而不是数字化)的企业。
|
||||
* 基于infra的共同体,可以是有中心的。
|
||||
|
||||
###账户
|
||||
infra和ethereum都有两种账户,分别用密钥和源代码标识。infra把它们成为普通账户、自动账户。ethereum则命名为externally owned accounts (EOAs) 和 contract accounts。比特币协议中也使用密钥和脚本,所以这种相似性并不出奇,但自动账户和合约账户在具体实现上有很大不同。
|
||||
|
||||
* infra的自动账户,以源代码的哈希值为账号,这些代码在各用户机器上验证后运行。ethereum的合约账户,以创建者地址加上交易数量nonce计算得到,代码的获取、存储由ethereum实现。因此,infra自动账户的源代码是无法攻击的,任何修改将导致验证失败。而ethereum的合约账户与代码之间没有数学关系,依赖软件绑定它们。
|
||||
* infra的自动账户,会注册一系列的事件处理器(event listener),当事件发生时会调用对应处理器。ethereum的合约账户,会在收款时被调用。如果要实现一个多事件的应用,ethereum合约账户需要自己实现事件机制。
|
||||
* infra自动账户代码可以读所有数据,ethereum合约账户的代码只能读写自己的存储。
|
||||
|
||||
###发行
|
||||
ethereum启动时有预售和开发专用ether,启动后的发行和比特币相似,以后可能会从POW迁移到POS。infra的发行则完全不同,由两部分组成:
|
||||
|
||||
* 计划内发行:联合提货权部署者以源代码定义以下机制
|
||||
* 开发基金:支付建模、设计、开发、运维、管理等人员和设备设置费用。
|
||||
* 孵化基金:向普通使用者发放贷款和预购产品。
|
||||
* 计划外发行:以特定卖出价出售任意数额的联合提货权,收入扣除管理费用后全部按特定买入价在兑换处挂单。
|
||||
|
||||
infra基于开发和产品孵化设计发行机制,而不针对存储(其实是一致性共识)支付报酬。ethereum无论是POW还是POS模式,设计开发人员都无法直接取得报酬。他们主要通过先发优势获得低成本的加密货币,升值后抛售获得收入。这种模式下,设计开发人员的报酬难以准确地反映工作量、工作难度的差异。
|
||||
|
||||
制定货币政策调节供需是传统央行的职能之一,这种权力是比特币设计者所批评的。与比特币相似,ethereum的发行数量也是提前计划的。当需求无法满足时,它们都会出现通缩,甚至无法实现(比如某个交易需要一次性支付超过2100万比特币)。infra的联合提货权包括计划外发行功能,将做市商机制数字化后,提供充足的数额以稳定币值。
|
||||
|
||||
infra具有原生的投融资功能,而ethenreum生态内的产品孵化则没有原生机制,需要扩展技术协议并由外部资源注入推动。
|
||||
|
||||
###脚本语言
|
||||
为了实现可编程性,ethereum内置了四种语言、EVM虚拟环境、配套的开发工具和浏览器。infra则直接使用javasrcipt语言实现自动账户,可以在node.js上运行。
|
||||
|
||||
实际上可编程不是重点,源代码不被篡改才是智能合约、共同体的关键。编译型语言在不同平台产生不同机器码,验证源代码变得异常复杂。因此,infra选择了js,ethereum则使用中间码。在账户一节讨论过,ethereum把代码与合约账户绑定,而infra在每次运行前取源代码的哈希值作为自动账户的账号。如果攻击者要替换代码的话,将产生另外一个账号。因为没有人往这个新账号付款(否则攻击者就直接留私人账号了),它的余额为零,所有支出都会失败。
|
||||
|
||||
ethereum要对脚本运行收费,以限制运算量。这个需求需要一系列私有工具,增加了开发工作量,也引入了额外的风险。infra要求用户决定部署哪些共同体(通常只有成员才会部署),这些共同体的代码在每个成员的本地运行,产生的结果本地保存、不对网络广播。这种自助服务模式不需要对计算量收费,因此可以直接使用js,分享其成熟的工具链。
|
||||
|
||||
|
||||
###协作与分配
|
||||
|
||||
###销售
|
||||
|
||||
###融资
|
||||
|
||||
|
||||
|
||||
##infra vs ethereum
|
||||
|
||||
联合提货权是infra的模块之一。从早期版本开始,[联合提货权模型](https://github.com/hyg/com.origin/blob/ef80158e64bea469a7926c8a42e492fe10aa6a3f/Joint.Token/Joint.Token.md)就把区块链作为账目存储的可选方案之一。作为区块链升级版的ethereum,也继承了这种调用关系。虽然ethereum努力从支付向合约扩展,但它还不能代替联合提货权在infra中的位置。
|
||||
|
||||
* 区块链以及ethereum都可以为infra存储账目(可能需要裁剪)。
|
||||
* ethereum用于开发分布式应用,替代有中心应用。infra用于创立数字化的共同体,替代基于国内法设立的企业。
|
||||
* 基于ethereum的应用,可能属于一家基于国内法注册(而不是数字化)的企业。
|
||||
* 基于infra的共同体,可以是有中心的。
|
||||
|
||||
###账户
|
||||
infra和ethereum都有两种账户,分别用密钥和源代码标识。infra把它们成为普通账户、自动账户。ethereum则命名为externally owned accounts (EOAs) 和 contract accounts。比特币协议中也使用密钥和脚本,所以这种相似性并不出奇,但自动账户和合约账户在具体实现上有很大不同。
|
||||
|
||||
* infra的自动账户,以源代码的哈希值为账号,这些代码在各用户机器上验证后运行。ethereum的合约账户,以创建者地址加上交易数量nonce计算得到,代码的获取、存储由ethereum实现。因此,infra自动账户的源代码是无法攻击的,任何修改将导致验证失败。而ethereum的合约账户与代码之间没有数学关系,依赖软件绑定它们。
|
||||
* infra的自动账户,会注册一系列的事件处理器(event listener),当事件发生时会调用对应处理器。ethereum的合约账户,会在收款时被调用。如果要实现一个多事件的应用,ethereum合约账户需要自己实现事件机制。
|
||||
* infra自动账户代码可以读所有数据,ethereum合约账户的代码只能读写自己的存储。
|
||||
|
||||
###发行
|
||||
ethereum启动时有预售和开发专用ether,启动后的发行和比特币相似,以后可能会从POW迁移到POS。infra的发行则完全不同,由两部分组成:
|
||||
|
||||
* 计划内发行:联合提货权部署者以源代码定义以下机制
|
||||
* 开发基金:支付建模、设计、开发、运维、管理等人员和设备设置费用。
|
||||
* 孵化基金:向普通使用者发放贷款和预购产品。
|
||||
* 计划外发行:以特定卖出价出售任意数额的联合提货权,收入扣除管理费用后全部按特定买入价在兑换处挂单。
|
||||
|
||||
infra基于开发和产品孵化设计发行机制,而不针对存储(其实是一致性共识)支付报酬。ethereum无论是POW还是POS模式,设计开发人员都无法直接取得报酬。他们主要通过先发优势获得低成本的加密货币,升值后抛售获得收入。这种模式下,设计开发人员的报酬难以准确地反映工作量、工作难度的差异。
|
||||
|
||||
制定货币政策调节供需是传统央行的职能之一,这种权力是比特币设计者所批评的。与比特币相似,ethereum的发行数量也是提前计划的。当需求无法满足时,它们都会出现通缩,甚至无法实现(比如某个交易需要一次性支付超过2100万比特币)。infra的联合提货权包括计划外发行功能,将做市商机制数字化后,提供充足的数额以稳定币值。
|
||||
|
||||
infra具有原生的投融资功能,而ethenreum生态内的产品孵化则没有原生机制,需要扩展技术协议并由外部资源注入推动。
|
||||
|
||||
###脚本语言
|
||||
为了实现可编程性,ethereum内置了四种语言、EVM虚拟环境、配套的开发工具和浏览器。infra则直接使用javasrcipt语言实现自动账户,可以在node.js上运行。
|
||||
|
||||
实际上可编程不是重点,源代码不被篡改才是智能合约、共同体的关键。编译型语言在不同平台产生不同机器码,验证源代码变得异常复杂。因此,infra选择了js,ethereum则使用中间码。在账户一节讨论过,ethereum把代码与合约账户绑定,而infra在每次运行前取源代码的哈希值作为自动账户的账号。如果攻击者要替换代码的话,将产生另外一个账号。因为没有人往这个新账号付款(否则攻击者就直接留私人账号了),它的余额为零,所有支出都会失败。
|
||||
|
||||
ethereum要对脚本运行收费,以限制运算量。这个需求需要一系列私有工具,增加了开发工作量,也引入了额外的风险。infra要求用户决定部署哪些共同体(通常只有成员才会部署),这些共同体的代码在每个成员的本地运行,产生的结果本地保存、不对网络广播。这种自助服务模式不需要对计算量收费,因此可以直接使用js,分享其成熟的工具链。
|
||||
|
||||
|
||||
###协作与分配
|
||||
|
||||
###销售
|
||||
|
||||
###融资
|
||||
|
||||
|
||||
|
||||
###DAO
|
After Width: | Height: | Size: 7.1 KiB |
|
@ -0,0 +1,95 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<diagram program="umlet" version="14.3.0">
|
||||
<zoom_level>10</zoom_level>
|
||||
<element>
|
||||
<id>UMLClass</id>
|
||||
<coordinates>
|
||||
<x>270</x>
|
||||
<y>210</y>
|
||||
<w>100</w>
|
||||
<h>250</h>
|
||||
</coordinates>
|
||||
<panel_attributes>unkown</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLClass</id>
|
||||
<coordinates>
|
||||
<x>380</x>
|
||||
<y>210</y>
|
||||
<w>240</w>
|
||||
<h>30</h>
|
||||
</coordinates>
|
||||
<panel_attributes>L1</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLClass</id>
|
||||
<coordinates>
|
||||
<x>380</x>
|
||||
<y>290</y>
|
||||
<w>240</w>
|
||||
<h>30</h>
|
||||
</coordinates>
|
||||
<panel_attributes>L2</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>490</x>
|
||||
<y>230</y>
|
||||
<w>120</w>
|
||||
<h>80</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-
|
||||
重构 | reconfig</panel_attributes>
|
||||
<additional_attributes>10.0;10.0;10.0;60.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLClass</id>
|
||||
<coordinates>
|
||||
<x>380</x>
|
||||
<y>430</y>
|
||||
<w>240</w>
|
||||
<h>30</h>
|
||||
</coordinates>
|
||||
<panel_attributes>Ln</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>490</x>
|
||||
<y>310</y>
|
||||
<w>120</w>
|
||||
<h>90</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-
|
||||
重构 | reconfig</panel_attributes>
|
||||
<additional_attributes>10.0;10.0;10.0;70.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>490</x>
|
||||
<y>430</y>
|
||||
<w>230</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<..
|
||||
重构 | reconfig</panel_attributes>
|
||||
<additional_attributes>10.0;30.0;10.0;90.0;210.0;90.0;210.0;10.0;130.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>490</x>
|
||||
<y>370</y>
|
||||
<w>30</w>
|
||||
<h>80</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=..</panel_attributes>
|
||||
<additional_attributes>10.0;10.0;10.0;60.0</additional_attributes>
|
||||
</element>
|
||||
</diagram>
|
BIN
model/1.png
Before Width: | Height: | Size: 8.1 KiB |
159
model/1.uxf
|
@ -1,159 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<diagram program="umlet" version="14.2">
|
||||
<zoom_level>10</zoom_level>
|
||||
<element>
|
||||
<id>UMLActor</id>
|
||||
<coordinates>
|
||||
<x>370</x>
|
||||
<y>230</y>
|
||||
<w>60</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**A**</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLNote</id>
|
||||
<coordinates>
|
||||
<x>540</x>
|
||||
<y>230</y>
|
||||
<w>80</w>
|
||||
<h>60</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**1**
|
||||
bg=blue
|
||||
fontsize=26
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLActor</id>
|
||||
<coordinates>
|
||||
<x>710</x>
|
||||
<y>230</y>
|
||||
<w>60</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>C</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>420</x>
|
||||
<y>250</y>
|
||||
<w>140</w>
|
||||
<h>30</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>120.0;10.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>610</x>
|
||||
<y>250</y>
|
||||
<w>120</w>
|
||||
<h>30</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>100.0;10.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLNote</id>
|
||||
<coordinates>
|
||||
<x>540</x>
|
||||
<y>340</y>
|
||||
<w>80</w>
|
||||
<h>60</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**1**
|
||||
bg=blue
|
||||
fontsize=26
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLActor</id>
|
||||
<coordinates>
|
||||
<x>710</x>
|
||||
<y>420</y>
|
||||
<w>60</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>D</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>420</x>
|
||||
<y>250</y>
|
||||
<w>140</w>
|
||||
<h>120</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>120.0;100.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>610</x>
|
||||
<y>380</y>
|
||||
<w>120</w>
|
||||
<h>90</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>100.0;70.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLNote</id>
|
||||
<coordinates>
|
||||
<x>540</x>
|
||||
<y>120</y>
|
||||
<w>80</w>
|
||||
<h>60</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**1**
|
||||
bg=blue
|
||||
fontsize=26
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLActor</id>
|
||||
<coordinates>
|
||||
<x>710</x>
|
||||
<y>40</y>
|
||||
<w>60</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>B</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>420</x>
|
||||
<y>160</y>
|
||||
<w>140</w>
|
||||
<h>120</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>120.0;10.0;10.0;100.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>610</x>
|
||||
<y>60</y>
|
||||
<w>120</w>
|
||||
<h>90</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>100.0;10.0;10.0;70.0</additional_attributes>
|
||||
</element>
|
||||
</diagram>
|
BIN
model/2.png
Before Width: | Height: | Size: 7.5 KiB |
107
model/2.uxf
|
@ -1,107 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<diagram program="umlet" version="14.2">
|
||||
<zoom_level>10</zoom_level>
|
||||
<element>
|
||||
<id>UMLActor</id>
|
||||
<coordinates>
|
||||
<x>20</x>
|
||||
<y>210</y>
|
||||
<w>60</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**A**</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLNote</id>
|
||||
<coordinates>
|
||||
<x>190</x>
|
||||
<y>210</y>
|
||||
<w>80</w>
|
||||
<h>60</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**2**
|
||||
bg=blue
|
||||
fontsize=26
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLActor</id>
|
||||
<coordinates>
|
||||
<x>360</x>
|
||||
<y>210</y>
|
||||
<w>60</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>C</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>70</x>
|
||||
<y>230</y>
|
||||
<w>140</w>
|
||||
<h>30</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>120.0;10.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>260</x>
|
||||
<y>230</y>
|
||||
<w>120</w>
|
||||
<h>30</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>100.0;10.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLActor</id>
|
||||
<coordinates>
|
||||
<x>360</x>
|
||||
<y>400</y>
|
||||
<w>60</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>D</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>220</x>
|
||||
<y>260</y>
|
||||
<w>160</w>
|
||||
<h>190</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>140.0;170.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLActor</id>
|
||||
<coordinates>
|
||||
<x>360</x>
|
||||
<y>20</y>
|
||||
<w>60</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>B</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>220</x>
|
||||
<y>40</y>
|
||||
<w>160</w>
|
||||
<h>190</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>140.0;10.0;10.0;170.0</additional_attributes>
|
||||
</element>
|
||||
</diagram>
|
BIN
model/3.1.-1.png
Before Width: | Height: | Size: 2.6 KiB |
|
@ -1,20 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<diagram program="umlet" version="14.2">
|
||||
<zoom_level>10</zoom_level>
|
||||
<element>
|
||||
<id>UMLUseCase</id>
|
||||
<coordinates>
|
||||
<x>450</x>
|
||||
<y>230</y>
|
||||
<w>80</w>
|
||||
<h>80</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**3.1**
|
||||
(-1)
|
||||
bg=gray
|
||||
fontsize=20
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
</diagram>
|
BIN
model/3.1.0.png
Before Width: | Height: | Size: 10 KiB |
133
model/3.1.0.uxf
|
@ -1,133 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<diagram program="umlet" version="14.2">
|
||||
<zoom_level>10</zoom_level>
|
||||
<element>
|
||||
<id>UMLActor</id>
|
||||
<coordinates>
|
||||
<x>210</x>
|
||||
<y>510</y>
|
||||
<w>60</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>C</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>310</x>
|
||||
<y>220</y>
|
||||
<w>50</w>
|
||||
<h>140</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-</panel_attributes>
|
||||
<additional_attributes>30.0;120.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>230</x>
|
||||
<y>390</y>
|
||||
<w>110</w>
|
||||
<h>140</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>10.0;120.0;90.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLActor</id>
|
||||
<coordinates>
|
||||
<x>330</x>
|
||||
<y>550</y>
|
||||
<w>60</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>D</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>350</x>
|
||||
<y>390</y>
|
||||
<w>30</w>
|
||||
<h>180</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>10.0;160.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLActor</id>
|
||||
<coordinates>
|
||||
<x>380</x>
|
||||
<y>150</y>
|
||||
<w>60</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**B**</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>370</x>
|
||||
<y>240</y>
|
||||
<w>50</w>
|
||||
<h>120</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-</panel_attributes>
|
||||
<additional_attributes>10.0;100.0;30.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLActor</id>
|
||||
<coordinates>
|
||||
<x>450</x>
|
||||
<y>510</y>
|
||||
<w>60</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>E</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>390</x>
|
||||
<y>390</y>
|
||||
<w>110</w>
|
||||
<h>140</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>90.0;120.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLNote</id>
|
||||
<coordinates>
|
||||
<x>320</x>
|
||||
<y>340</y>
|
||||
<w>80</w>
|
||||
<h>60</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**3.1**
|
||||
bg=gray
|
||||
fontsize=26
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLUseCase</id>
|
||||
<coordinates>
|
||||
<x>270</x>
|
||||
<y>150</y>
|
||||
<w>80</w>
|
||||
<h>80</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**3.2**
|
||||
bg=gray
|
||||
fontsize=26
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
</diagram>
|
BIN
model/3.1.1.png
Before Width: | Height: | Size: 28 KiB |
244
model/3.1.1.uxf
|
@ -1,244 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<diagram program="umlet" version="14.2">
|
||||
<zoom_level>10</zoom_level>
|
||||
<element>
|
||||
<id>UMLUseCase</id>
|
||||
<coordinates>
|
||||
<x>770</x>
|
||||
<y>240</y>
|
||||
<w>80</w>
|
||||
<h>80</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**3.1**
|
||||
(1)
|
||||
bg=gray
|
||||
fontsize=20
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLActor</id>
|
||||
<coordinates>
|
||||
<x>150</x>
|
||||
<y>80</y>
|
||||
<w>60</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**A**</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLActor</id>
|
||||
<coordinates>
|
||||
<x>160</x>
|
||||
<y>420</y>
|
||||
<w>60</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>C</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>190</x>
|
||||
<y>160</y>
|
||||
<w>100</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-</panel_attributes>
|
||||
<additional_attributes>80.0;90.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>180</x>
|
||||
<y>300</y>
|
||||
<w>110</w>
|
||||
<h>140</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>10.0;120.0;90.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLActor</id>
|
||||
<coordinates>
|
||||
<x>280</x>
|
||||
<y>460</y>
|
||||
<w>60</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>D</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>300</x>
|
||||
<y>300</y>
|
||||
<w>30</w>
|
||||
<h>180</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>10.0;160.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLActor</id>
|
||||
<coordinates>
|
||||
<x>400</x>
|
||||
<y>80</y>
|
||||
<w>60</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**B**</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>330</x>
|
||||
<y>160</y>
|
||||
<w>100</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-</panel_attributes>
|
||||
<additional_attributes>10.0;90.0;80.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLActor</id>
|
||||
<coordinates>
|
||||
<x>400</x>
|
||||
<y>420</y>
|
||||
<w>60</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>E</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>340</x>
|
||||
<y>300</y>
|
||||
<w>110</w>
|
||||
<h>140</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>90.0;120.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLNote</id>
|
||||
<coordinates>
|
||||
<x>270</x>
|
||||
<y>250</y>
|
||||
<w>80</w>
|
||||
<h>60</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**3.1**
|
||||
bg=gray
|
||||
fontsize=26
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLUseCase</id>
|
||||
<coordinates>
|
||||
<x>20</x>
|
||||
<y>20</y>
|
||||
<w>580</w>
|
||||
<h>550</h>
|
||||
</coordinates>
|
||||
<panel_attributes>bg=gray
|
||||
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>590</x>
|
||||
<y>270</y>
|
||||
<w>190</w>
|
||||
<h>30</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<<-</panel_attributes>
|
||||
<additional_attributes>170.0;10.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLNote</id>
|
||||
<coordinates>
|
||||
<x>260</x>
|
||||
<y>80</y>
|
||||
<w>80</w>
|
||||
<h>60</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**1**
|
||||
bg=blue
|
||||
fontsize=26
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>190</x>
|
||||
<y>100</y>
|
||||
<w>90</w>
|
||||
<h>30</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>70.0;10.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>330</x>
|
||||
<y>100</y>
|
||||
<w>90</w>
|
||||
<h>30</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>70.0;10.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLNote</id>
|
||||
<coordinates>
|
||||
<x>70</x>
|
||||
<y>250</y>
|
||||
<w>80</w>
|
||||
<h>60</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**1**
|
||||
bg=blue
|
||||
fontsize=26
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>100</x>
|
||||
<y>140</y>
|
||||
<w>80</w>
|
||||
<h>130</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>60.0;10.0;10.0;110.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>100</x>
|
||||
<y>300</y>
|
||||
<w>90</w>
|
||||
<h>150</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>10.0;10.0;70.0;130.0</additional_attributes>
|
||||
</element>
|
||||
</diagram>
|
BIN
model/3.1.2.png
Before Width: | Height: | Size: 2.6 KiB |
|
@ -1,20 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<diagram program="umlet" version="14.2">
|
||||
<zoom_level>10</zoom_level>
|
||||
<element>
|
||||
<id>UMLUseCase</id>
|
||||
<coordinates>
|
||||
<x>420</x>
|
||||
<y>230</y>
|
||||
<w>80</w>
|
||||
<h>80</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**3.1**
|
||||
(2)
|
||||
bg=gray
|
||||
fontsize=20
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
</diagram>
|
Before Width: | Height: | Size: 3.9 KiB |
|
@ -1,67 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<diagram program="umlet" version="14.2">
|
||||
<zoom_level>10</zoom_level>
|
||||
<element>
|
||||
<id>UMLNote</id>
|
||||
<coordinates>
|
||||
<x>420</x>
|
||||
<y>290</y>
|
||||
<w>80</w>
|
||||
<h>60</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**1**
|
||||
bg=blue
|
||||
fontsize=26
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLActor</id>
|
||||
<coordinates>
|
||||
<x>590</x>
|
||||
<y>290</y>
|
||||
<w>60</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>B</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>300</x>
|
||||
<y>310</y>
|
||||
<w>140</w>
|
||||
<h>30</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>120.0;10.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>490</x>
|
||||
<y>310</y>
|
||||
<w>120</w>
|
||||
<h>30</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>100.0;10.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLUseCase</id>
|
||||
<coordinates>
|
||||
<x>230</x>
|
||||
<y>280</y>
|
||||
<w>80</w>
|
||||
<h>80</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**3.1**
|
||||
bg=gray
|
||||
fontsize=26
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
</diagram>
|
BIN
model/3.1.png
Before Width: | Height: | Size: 24 KiB |
169
model/3.1.uxf
|
@ -1,169 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<diagram program="umlet" version="14.2">
|
||||
<zoom_level>10</zoom_level>
|
||||
<element>
|
||||
<id>UMLActor</id>
|
||||
<coordinates>
|
||||
<x>280</x>
|
||||
<y>90</y>
|
||||
<w>60</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**A**</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLActor</id>
|
||||
<coordinates>
|
||||
<x>190</x>
|
||||
<y>450</y>
|
||||
<w>60</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>C</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>300</x>
|
||||
<y>180</y>
|
||||
<w>30</w>
|
||||
<h>120</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-</panel_attributes>
|
||||
<additional_attributes>10.0;100.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>210</x>
|
||||
<y>330</y>
|
||||
<w>110</w>
|
||||
<h>140</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>10.0;120.0;90.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLActor</id>
|
||||
<coordinates>
|
||||
<x>310</x>
|
||||
<y>490</y>
|
||||
<w>60</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>D</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>330</x>
|
||||
<y>330</y>
|
||||
<w>30</w>
|
||||
<h>180</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>10.0;160.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLActor</id>
|
||||
<coordinates>
|
||||
<x>330</x>
|
||||
<y>90</y>
|
||||
<w>60</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**B**</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>350</x>
|
||||
<y>180</y>
|
||||
<w>30</w>
|
||||
<h>120</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-</panel_attributes>
|
||||
<additional_attributes>10.0;100.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLActor</id>
|
||||
<coordinates>
|
||||
<x>430</x>
|
||||
<y>450</y>
|
||||
<w>60</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>E</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>370</x>
|
||||
<y>330</y>
|
||||
<w>110</w>
|
||||
<h>140</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>90.0;120.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLNote</id>
|
||||
<coordinates>
|
||||
<x>300</x>
|
||||
<y>280</y>
|
||||
<w>80</w>
|
||||
<h>60</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**3.1**
|
||||
bg=gray
|
||||
fontsize=26
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLUseCase</id>
|
||||
<coordinates>
|
||||
<x>50</x>
|
||||
<y>50</y>
|
||||
<w>580</w>
|
||||
<h>550</h>
|
||||
</coordinates>
|
||||
<panel_attributes>bg=gray
|
||||
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLUseCase</id>
|
||||
<coordinates>
|
||||
<x>800</x>
|
||||
<y>270</y>
|
||||
<w>80</w>
|
||||
<h>80</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**3.1**
|
||||
bg=gray
|
||||
fontsize=26
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>620</x>
|
||||
<y>300</y>
|
||||
<w>190</w>
|
||||
<h>30</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<<-</panel_attributes>
|
||||
<additional_attributes>170.0;10.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
</diagram>
|
BIN
model/3.png
Before Width: | Height: | Size: 6.9 KiB |
129
model/3.uxf
|
@ -1,129 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<diagram program="umlet" version="14.2">
|
||||
<zoom_level>10</zoom_level>
|
||||
<element>
|
||||
<id>UMLActor</id>
|
||||
<coordinates>
|
||||
<x>310</x>
|
||||
<y>70</y>
|
||||
<w>60</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**A**</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLNote</id>
|
||||
<coordinates>
|
||||
<x>330</x>
|
||||
<y>260</y>
|
||||
<w>80</w>
|
||||
<h>60</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**3**
|
||||
bg=blue
|
||||
fontsize=26
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLActor</id>
|
||||
<coordinates>
|
||||
<x>220</x>
|
||||
<y>430</y>
|
||||
<w>60</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>C</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>330</x>
|
||||
<y>160</y>
|
||||
<w>30</w>
|
||||
<h>120</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-</panel_attributes>
|
||||
<additional_attributes>10.0;100.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>240</x>
|
||||
<y>310</y>
|
||||
<w>110</w>
|
||||
<h>140</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>10.0;120.0;90.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLActor</id>
|
||||
<coordinates>
|
||||
<x>340</x>
|
||||
<y>470</y>
|
||||
<w>60</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>D</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>360</x>
|
||||
<y>310</y>
|
||||
<w>30</w>
|
||||
<h>180</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>10.0;160.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLActor</id>
|
||||
<coordinates>
|
||||
<x>360</x>
|
||||
<y>70</y>
|
||||
<w>60</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**B**</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>380</x>
|
||||
<y>160</y>
|
||||
<w>30</w>
|
||||
<h>120</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-</panel_attributes>
|
||||
<additional_attributes>10.0;100.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLActor</id>
|
||||
<coordinates>
|
||||
<x>460</x>
|
||||
<y>430</y>
|
||||
<w>60</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>E</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>400</x>
|
||||
<y>310</y>
|
||||
<w>110</w>
|
||||
<h>140</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>90.0;120.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
</diagram>
|
294
model/base.html
|
@ -1,294 +0,0 @@
|
|||
<!DOCTYPE html>
|
||||
<html lang="zh-cmn-Hans">
|
||||
<head>
|
||||
<title>基础模型</title>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
|
||||
<style type="text/css">
|
||||
@import url(https://fonts.googleapis.com/css?family=Droid+Serif);
|
||||
@import url(https://fonts.googleapis.com/css?family=Yanone+Kaffeesatz);
|
||||
@import url(https://fonts.googleapis.com/css?family=Ubuntu+Mono:400,700,400italic);
|
||||
|
||||
body { font-family: Georgia, "Times New Roman",
|
||||
"Microsoft YaHei", "微软雅黑",
|
||||
STXihei, "华文细黑",
|
||||
serif;
|
||||
font-weight: normal;
|
||||
}
|
||||
h1, h2, h3 {
|
||||
margin-bottom: 0;
|
||||
}
|
||||
.remark-slide-content h1 { font-size: 3em; }
|
||||
.remark-slide-content h2 { font-size: 2em; }
|
||||
.remark-slide-content h3 { font-size: 1.6em; }
|
||||
.footnote {
|
||||
position: absolute;
|
||||
bottom: 3em;
|
||||
}
|
||||
li p { line-height: 1.25em; }
|
||||
.red { color: #fa0000; }
|
||||
.large { font-size: 2em; }
|
||||
a, a > code {
|
||||
color: rgb(249, 38, 114);
|
||||
text-decoration: none;
|
||||
}
|
||||
code {
|
||||
background: #e7e8e2;
|
||||
border-radius: 5px;
|
||||
}
|
||||
.remark-code, .remark-inline-code { font-family: 'Ubuntu Mono'; }
|
||||
.remark-code-line-highlighted { background-color: #373832; }
|
||||
.pull-left {
|
||||
float: left;
|
||||
width: 47%;
|
||||
}
|
||||
.pull-right {
|
||||
float: right;
|
||||
width: 47%;
|
||||
}
|
||||
.pull-right ~ p {
|
||||
clear: both;
|
||||
}
|
||||
#slideshow .slide .content code {
|
||||
font-size: 0.8em;
|
||||
}
|
||||
#slideshow .slide .content pre code {
|
||||
font-size: 0.9em;
|
||||
padding: 15px;
|
||||
}
|
||||
.inverse {
|
||||
background: #272822;
|
||||
color: #777872;
|
||||
text-shadow: 0 0 20px #333;
|
||||
}
|
||||
.inverse h1, .inverse h2 {
|
||||
color: #f3f3f3;
|
||||
line-height: 0.8em;
|
||||
}
|
||||
|
||||
/* Slide-specific styling */
|
||||
#slide-inverse .footnote {
|
||||
bottom: 12px;
|
||||
left: 20px;
|
||||
}
|
||||
#slide-how .slides {
|
||||
font-size: 0.9em;
|
||||
position: absolute;
|
||||
top: 151px;
|
||||
right: 140px;
|
||||
}
|
||||
#slide-how .slides h3 {
|
||||
margin-top: 0.2em;
|
||||
}
|
||||
#slide-how .slides .first, #slide-how .slides .second {
|
||||
padding: 1px 20px;
|
||||
height: 90px;
|
||||
width: 120px;
|
||||
-moz-box-shadow: 0 0 10px #777;
|
||||
-webkit-box-shadow: 0 0 10px #777;
|
||||
box-shadow: 0 0 10px #777;
|
||||
}
|
||||
#slide-how .slides .first {
|
||||
background: #fff;
|
||||
position: absolute;
|
||||
top: 20%;
|
||||
left: 20%;
|
||||
z-index: 1;
|
||||
}
|
||||
#slide-how .slides .second {
|
||||
position: relative;
|
||||
background: #fff;
|
||||
z-index: 0;
|
||||
}
|
||||
|
||||
/* Two-column layout */
|
||||
.left-column {
|
||||
color: #777;
|
||||
width: 20%;
|
||||
height: 92%;
|
||||
float: left;
|
||||
}
|
||||
.left-column h3:last-of-type, .left-column h4:last-child {
|
||||
color: #000;
|
||||
}
|
||||
.right-column {
|
||||
width: 75%;
|
||||
float: right;
|
||||
padding-top: 1em;
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<textarea id="source">
|
||||
class: center, middle
|
||||
# press p
|
||||
???
|
||||
* p:注释
|
||||
* home、page up、page down、end、↑、 ↓:翻页
|
||||
* <a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/4.0/">署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0)</a>
|
||||
---
|
||||
class: center, middle, inverse
|
||||
|
||||
# 合同
|
||||
### contract
|
||||
|
||||
???
|
||||
1. 根据合作效率分类
|
||||
2. 整理类别的特征
|
||||
|
||||
---
|
||||
background-image: url(contract.png)
|
||||
|
||||
???
|
||||
基础合同(第1类):
|
||||
1. 双方同意才能修改。
|
||||
2. 不使用某一方可以控制的条件。如果使用,另一方会按最坏情况谈判。
|
||||
|
||||
---
|
||||
background-image: url(1.png)
|
||||
|
||||
???
|
||||
规模大、工种多的大项目,需要多人签订1类合同。
|
||||
通常:
|
||||
1. 不使用跨合同的条件(一份合同的条款以另一份合同执行情况为条件)
|
||||
2. 各自合同期内支付
|
||||
|
||||
---
|
||||
background-image: url(2.png)
|
||||
|
||||
???
|
||||
合并的多方合同(第2类):
|
||||
1. 后续步骤可以前面步骤的完成情况作为条件。
|
||||
2. 可以共同监控收入,统一安排支付。
|
||||
3. 需要所有各方中的多数(甚至全体)同意才能修改。
|
||||
|
||||
优点:弹性更大、启动资金更少。
|
||||
缺点:更难适应变化。
|
||||
---
|
||||
background-image: url(3.png)
|
||||
|
||||
???
|
||||
少数人修订的多方合同(第3类):
|
||||
1. 可以规定修订者的产生程序、修订范围。
|
||||
2. 不同条款可以有不同的修订权限。
|
||||
3. 如果不限修订的条件和范围,理论上可以适应任何变化。
|
||||
|
||||
优点:适应能力更强。
|
||||
缺点:容易阶层固化。
|
||||
|
||||
直线:讨论、签订第一版的角色。
|
||||
箭头:除了第一版,还有权参与修改后续版本的角色。
|
||||
---
|
||||
class: center, middle, inverse
|
||||
|
||||
# 企业
|
||||
### enterprise
|
||||
|
||||
???
|
||||
由于第3类合同可以持续运行,在它的基础上诞生企业。
|
||||
---
|
||||
background-image: url(enterprise.png)
|
||||
|
||||
???
|
||||
由国家总结成功实践,立法推广:
|
||||
1. 作为法人,拥有部分民事权利。
|
||||
2. 修订者的产生程序、权限不同,产生不同的企业模型(公司、合伙企业、合作社企业...)。
|
||||
3. 除了第3类合同的优缺点之外:
|
||||
* 优点:关键条款已经整理好,学习成本低。
|
||||
* 缺点:有税费,成本高。
|
||||
|
||||
---
|
||||
background-image: url(3.1.png)
|
||||
|
||||
???
|
||||
用圆形表示一个具体的企业(企业模型的一个部署)。
|
||||
---
|
||||
background-image: url(3.1.contract.png)
|
||||
|
||||
???
|
||||
企业可以签订合同。
|
||||
|
||||
---
|
||||
background-image: url(3.1.0.png)
|
||||
|
||||
???
|
||||
可以成为其它企业的角色之一。
|
||||
|
||||
---
|
||||
background-image: url(3.1.2.png)
|
||||
|
||||
???
|
||||
退化(括号表示退化后实质模型):
|
||||
1. 如果修订者不作为,则退化为**第2类合同**:
|
||||
* 不修订。
|
||||
* 仅仅跟随行业平均水平修订(即跟随多数成员的认识)。
|
||||
2. 退化后,就不再具有企业的优点。而出现第2类合同的缺点 -- 难以适应变化。
|
||||
---
|
||||
background-image: url(3.1.1.png)
|
||||
|
||||
???
|
||||
1. 如果成员单独签订合同,合同内容替代了企业模型的功能,则退化为**第1类合同**。
|
||||
2. 退化后,就不再具有企业的优点。而出现第1类合同的缺点:
|
||||
* 弹性更小:其它成员收窄合作条件,不接受体外合同的步骤为工作条件。
|
||||
* 启动资金更多:其它成员收窄支付条件。
|
||||
|
||||
---
|
||||
background-image: url(3.1.-1.png)
|
||||
|
||||
???
|
||||
* 如果合同没有淘汰条款,它反而强化了宿主企业的缺点:阶层固化。
|
||||
* 由于汇集了第1类合同、第3类合同、企业的所有缺点,这种退化记为(-1)。
|
||||
---
|
||||
class: center, middle, inverse
|
||||
|
||||
# 人
|
||||
### mind
|
||||
|
||||
???
|
||||
探讨两个问题:
|
||||
1. 集权的原则
|
||||
2. 无需签订的合同、模型
|
||||
---
|
||||
background-image: url(mind.png)
|
||||
|
||||
???
|
||||
使用简化的模型:
|
||||
1. 先由条件反射处理事件,然后才思考。
|
||||
2. 除了回应事件,行为还包括放弃(不处理)、转交他人......
|
||||
---
|
||||
background-image: url(reflex.png)
|
||||
|
||||
???
|
||||
简化的条件反射是一个查找表。
|
||||
|
||||
---
|
||||
background-image: url(think.png)
|
||||
|
||||
???
|
||||
我们通过世界的简化模型进行推断,包括:
|
||||
* 未观察到的事实。
|
||||
* 预估的行动结果。
|
||||
经过一系列制订、修订,最终选出可接受的行动方案,对外输出。
|
||||
|
||||
当所有模型推断的事实与实际观察不符时,自动产生一个新的模型。它能兼容这个例外,哪怕只能在这个样本上准确、其它都失真。
|
||||
---
|
||||
background-image: url(level.png)
|
||||
|
||||
???
|
||||
查找表和模型有两个来源:
|
||||
1. 自我:
|
||||
* 按查找表、模型的使用者和提供者,对自我意识划分层次。
|
||||
* 事件和行为也经由更深层的意识传输,传输过程可以修改。
|
||||
2. 外界:通过各种媒介传入,提供者也是多元化的。
|
||||
* 无主的。
|
||||
* 合同、企业的成员设计的。
|
||||
|
||||
|
||||
---
|
||||
</textarea>
|
||||
<script src="https://remarkjs.com/downloads/remark-latest.min.js">
|
||||
</script>
|
||||
<script>
|
||||
var slideshow = remark.create();
|
||||
</script>
|
||||
</body>
|
||||
</html>
|
Before Width: | Height: | Size: 2.8 KiB |
|
@ -1,63 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<diagram program="umlet" version="14.2">
|
||||
<zoom_level>10</zoom_level>
|
||||
<element>
|
||||
<id>UMLActor</id>
|
||||
<coordinates>
|
||||
<x>210</x>
|
||||
<y>230</y>
|
||||
<w>60</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**A**</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLNote</id>
|
||||
<coordinates>
|
||||
<x>380</x>
|
||||
<y>230</y>
|
||||
<w>80</w>
|
||||
<h>60</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**合同**
|
||||
bg=blue
|
||||
fontsize=26
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLActor</id>
|
||||
<coordinates>
|
||||
<x>550</x>
|
||||
<y>230</y>
|
||||
<w>60</w>
|
||||
<h>110</h>
|
||||
</coordinates>
|
||||
<panel_attributes>B</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>260</x>
|
||||
<y>250</y>
|
||||
<w>140</w>
|
||||
<h>30</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>120.0;10.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>450</x>
|
||||
<y>250</y>
|
||||
<w>120</w>
|
||||
<h>30</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>100.0;10.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
</diagram>
|
Before Width: | Height: | Size: 9.2 KiB |
|
@ -1,179 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<diagram program="umlet" version="14.2">
|
||||
<zoom_level>10</zoom_level>
|
||||
<element>
|
||||
<id>UMLNote</id>
|
||||
<coordinates>
|
||||
<x>330</x>
|
||||
<y>390</y>
|
||||
<w>80</w>
|
||||
<h>60</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**2**
|
||||
bg=blue
|
||||
fontsize=26
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLNote</id>
|
||||
<coordinates>
|
||||
<x>330</x>
|
||||
<y>500</y>
|
||||
<w>80</w>
|
||||
<h>60</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**1**
|
||||
bg=blue
|
||||
fontsize=26
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLNote</id>
|
||||
<coordinates>
|
||||
<x>330</x>
|
||||
<y>280</y>
|
||||
<w>80</w>
|
||||
<h>60</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**3**
|
||||
bg=blue
|
||||
fontsize=26
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>360</x>
|
||||
<y>440</y>
|
||||
<w>30</w>
|
||||
<h>80</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-</panel_attributes>
|
||||
<additional_attributes>10.0;10.0;10.0;60.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>360</x>
|
||||
<y>330</y>
|
||||
<w>30</w>
|
||||
<h>80</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-</panel_attributes>
|
||||
<additional_attributes>10.0;10.0;10.0;60.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLNote</id>
|
||||
<coordinates>
|
||||
<x>500</x>
|
||||
<y>280</y>
|
||||
<w>80</w>
|
||||
<h>60</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**3.1**
|
||||
bg=gray
|
||||
fontsize=26
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLNote</id>
|
||||
<coordinates>
|
||||
<x>500</x>
|
||||
<y>180</y>
|
||||
<w>80</w>
|
||||
<h>60</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**3.2**
|
||||
bg=gray
|
||||
fontsize=26
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLNote</id>
|
||||
<coordinates>
|
||||
<x>500</x>
|
||||
<y>80</y>
|
||||
<w>80</w>
|
||||
<h>60</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**3.3**
|
||||
bg=gray
|
||||
fontsize=26
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>530</x>
|
||||
<y>230</y>
|
||||
<w>30</w>
|
||||
<h>70</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-</panel_attributes>
|
||||
<additional_attributes>10.0;10.0;10.0;50.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>530</x>
|
||||
<y>130</y>
|
||||
<w>30</w>
|
||||
<h>70</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-</panel_attributes>
|
||||
<additional_attributes>10.0;10.0;10.0;50.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>400</x>
|
||||
<y>300</y>
|
||||
<w>120</w>
|
||||
<h>30</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-</panel_attributes>
|
||||
<additional_attributes>100.0;10.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLNote</id>
|
||||
<coordinates>
|
||||
<x>60</x>
|
||||
<y>50</y>
|
||||
<w>80</w>
|
||||
<h>60</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**合同**
|
||||
bg=blue
|
||||
fontsize=26
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLNote</id>
|
||||
<coordinates>
|
||||
<x>170</x>
|
||||
<y>50</y>
|
||||
<w>80</w>
|
||||
<h>60</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**企业模型**
|
||||
bg=gray
|
||||
fontsize=13
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
</diagram>
|
BIN
model/level.png
Before Width: | Height: | Size: 18 KiB |
211
model/level.uxf
|
@ -1,211 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<diagram program="umlet" version="14.2">
|
||||
<zoom_level>10</zoom_level>
|
||||
<element>
|
||||
<id>UMLClass</id>
|
||||
<coordinates>
|
||||
<x>350</x>
|
||||
<y>160</y>
|
||||
<w>100</w>
|
||||
<h>60</h>
|
||||
</coordinates>
|
||||
<panel_attributes>条件反射
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLClass</id>
|
||||
<coordinates>
|
||||
<x>530</x>
|
||||
<y>160</y>
|
||||
<w>100</w>
|
||||
<h>60</h>
|
||||
</coordinates>
|
||||
<panel_attributes>思考
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLClass</id>
|
||||
<coordinates>
|
||||
<x>250</x>
|
||||
<y>80</y>
|
||||
<w>480</w>
|
||||
<h>180</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**level 0**
|
||||
|
||||
|
||||
|
||||
fontsize=26
|
||||
valign=center
|
||||
</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLClass</id>
|
||||
<coordinates>
|
||||
<x>250</x>
|
||||
<y>320</y>
|
||||
<w>480</w>
|
||||
<h>60</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**level 1**
|
||||
fontsize=26
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>410</x>
|
||||
<y>250</y>
|
||||
<w>60</w>
|
||||
<h>90</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-
|
||||
事件</panel_attributes>
|
||||
<additional_attributes>10.0;10.0;10.0;70.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>540</x>
|
||||
<y>250</y>
|
||||
<w>60</w>
|
||||
<h>90</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-
|
||||
行为</panel_attributes>
|
||||
<additional_attributes>10.0;70.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLClass</id>
|
||||
<coordinates>
|
||||
<x>250</x>
|
||||
<y>460</y>
|
||||
<w>480</w>
|
||||
<h>60</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**kernel**
|
||||
fontsize=26
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>410</x>
|
||||
<y>410</y>
|
||||
<w>110</w>
|
||||
<h>70</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-
|
||||
事件 ......</panel_attributes>
|
||||
<additional_attributes>10.0;10.0;10.0;50.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>540</x>
|
||||
<y>410</y>
|
||||
<w>60</w>
|
||||
<h>70</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-
|
||||
行为</panel_attributes>
|
||||
<additional_attributes>10.0;50.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>720</x>
|
||||
<y>170</y>
|
||||
<w>150</w>
|
||||
<h>180</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-
|
||||
查找表
|
||||
模型</panel_attributes>
|
||||
<additional_attributes>10.0;10.0;90.0;10.0;90.0;160.0;10.0;160.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>720</x>
|
||||
<y>430</y>
|
||||
<w>150</w>
|
||||
<h>80</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-
|
||||
查找表
|
||||
模型</panel_attributes>
|
||||
<additional_attributes>90.0;10.0;90.0;60.0;10.0;60.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>720</x>
|
||||
<y>340</y>
|
||||
<w>110</w>
|
||||
<h>60</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-
|
||||
</panel_attributes>
|
||||
<additional_attributes>10.0;20.0;90.0;20.0;90.0;40.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>110</x>
|
||||
<y>460</y>
|
||||
<w>160</w>
|
||||
<h>40</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-
|
||||
行为</panel_attributes>
|
||||
<additional_attributes>10.0;20.0;140.0;20.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>110</x>
|
||||
<y>490</y>
|
||||
<w>160</w>
|
||||
<h>40</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-
|
||||
事件</panel_attributes>
|
||||
<additional_attributes>140.0;20.0;10.0;20.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>100</x>
|
||||
<y>150</y>
|
||||
<w>170</w>
|
||||
<h>50</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-
|
||||
查找表
|
||||
模型</panel_attributes>
|
||||
<additional_attributes>150.0;20.0;10.0;20.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>110</x>
|
||||
<y>330</y>
|
||||
<w>160</w>
|
||||
<h>50</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-
|
||||
查找表
|
||||
模型</panel_attributes>
|
||||
<additional_attributes>140.0;20.0;10.0;20.0</additional_attributes>
|
||||
</element>
|
||||
</diagram>
|
BIN
model/mind.png
Before Width: | Height: | Size: 3.3 KiB |
|
@ -1,77 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<diagram program="umlet" version="14.2">
|
||||
<zoom_level>10</zoom_level>
|
||||
<element>
|
||||
<id>UMLClass</id>
|
||||
<coordinates>
|
||||
<x>270</x>
|
||||
<y>190</y>
|
||||
<w>100</w>
|
||||
<h>60</h>
|
||||
</coordinates>
|
||||
<panel_attributes>条件反射
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLClass</id>
|
||||
<coordinates>
|
||||
<x>450</x>
|
||||
<y>190</y>
|
||||
<w>100</w>
|
||||
<h>60</h>
|
||||
</coordinates>
|
||||
<panel_attributes>思考
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>140</x>
|
||||
<y>200</y>
|
||||
<w>150</w>
|
||||
<h>40</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-
|
||||
事件</panel_attributes>
|
||||
<additional_attributes>130.0;20.0;10.0;20.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>360</x>
|
||||
<y>200</y>
|
||||
<w>110</w>
|
||||
<h>40</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-
|
||||
</panel_attributes>
|
||||
<additional_attributes>90.0;20.0;10.0;20.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>140</x>
|
||||
<y>130</y>
|
||||
<w>200</w>
|
||||
<h>80</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-
|
||||
行为</panel_attributes>
|
||||
<additional_attributes>10.0;20.0;180.0;20.0;180.0;60.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>320</x>
|
||||
<y>140</y>
|
||||
<w>200</w>
|
||||
<h>70</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-</panel_attributes>
|
||||
<additional_attributes>10.0;10.0;180.0;10.0;180.0;50.0</additional_attributes>
|
||||
</element>
|
||||
</diagram>
|
|
@ -1,41 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<diagram program="umlet" version="14.2">
|
||||
<zoom_level>10</zoom_level>
|
||||
<element>
|
||||
<id>UMLUseCase</id>
|
||||
<coordinates>
|
||||
<x>400</x>
|
||||
<y>340</y>
|
||||
<w>120</w>
|
||||
<h>40</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=.
|
||||
模型
|
||||
bg=gray</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>480</x>
|
||||
<y>270</y>
|
||||
<w>60</w>
|
||||
<h>90</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-
|
||||
预估</panel_attributes>
|
||||
<additional_attributes>10.0;10.0;10.0;70.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>420</x>
|
||||
<y>270</y>
|
||||
<w>60</w>
|
||||
<h>90</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-
|
||||
读取</panel_attributes>
|
||||
<additional_attributes>10.0;10.0;10.0;70.0</additional_attributes>
|
||||
</element>
|
||||
</diagram>
|
BIN
model/reflex.png
Before Width: | Height: | Size: 14 KiB |
|
@ -1,77 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<diagram program="umlet" version="14.2">
|
||||
<zoom_level>10</zoom_level>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>260</x>
|
||||
<y>0</y>
|
||||
<w>200</w>
|
||||
<h>80</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-
|
||||
行为</panel_attributes>
|
||||
<additional_attributes>10.0;20.0;180.0;20.0;180.0;60.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLClass</id>
|
||||
<coordinates>
|
||||
<x>170</x>
|
||||
<y>60</y>
|
||||
<w>550</w>
|
||||
<h>380</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**条件反射**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
fontsize=26
|
||||
valign=center
|
||||
</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>40</x>
|
||||
<y>210</y>
|
||||
<w>150</w>
|
||||
<h>40</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-
|
||||
事件</panel_attributes>
|
||||
<additional_attributes>130.0;20.0;10.0;20.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLClass</id>
|
||||
<coordinates>
|
||||
<x>340</x>
|
||||
<y>200</y>
|
||||
<w>210</w>
|
||||
<h>190</h>
|
||||
</coordinates>
|
||||
<panel_attributes>查找表
|
||||
Look Up Table
|
||||
--
|
||||
事件 | 行为
|
||||
--
|
||||
事件 | 行为
|
||||
--
|
||||
事件 | 行为
|
||||
--
|
||||
事件 | 行为
|
||||
--
|
||||
事件 | 行为
|
||||
--
|
||||
事件 | 行为
|
||||
--
|
||||
事件 | 行为</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
</diagram>
|
BIN
model/think.png
Before Width: | Height: | Size: 11 KiB |
167
model/think.uxf
|
@ -1,167 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<diagram program="umlet" version="14.2">
|
||||
<zoom_level>10</zoom_level>
|
||||
<element>
|
||||
<id>UMLClass</id>
|
||||
<coordinates>
|
||||
<x>460</x>
|
||||
<y>240</y>
|
||||
<w>100</w>
|
||||
<h>60</h>
|
||||
</coordinates>
|
||||
<panel_attributes>制订
|
||||
选择
|
||||
valign=center
|
||||
halign=center</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>330</x>
|
||||
<y>70</y>
|
||||
<w>200</w>
|
||||
<h>80</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-
|
||||
行为</panel_attributes>
|
||||
<additional_attributes>10.0;20.0;180.0;20.0;180.0;60.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLUseCase</id>
|
||||
<coordinates>
|
||||
<x>320</x>
|
||||
<y>430</y>
|
||||
<w>120</w>
|
||||
<h>40</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=.
|
||||
模型1
|
||||
bg=gray</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLUseCase</id>
|
||||
<coordinates>
|
||||
<x>450</x>
|
||||
<y>430</y>
|
||||
<w>120</w>
|
||||
<h>40</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=.
|
||||
模型2
|
||||
bg=gray</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLUseCase</id>
|
||||
<coordinates>
|
||||
<x>600</x>
|
||||
<y>430</y>
|
||||
<w>120</w>
|
||||
<h>40</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=.
|
||||
模型n
|
||||
bg=gray</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>370</x>
|
||||
<y>360</y>
|
||||
<w>60</w>
|
||||
<h>90</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-
|
||||
预估
|
||||
结果</panel_attributes>
|
||||
<additional_attributes>10.0;10.0;10.0;70.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>500</x>
|
||||
<y>360</y>
|
||||
<w>60</w>
|
||||
<h>90</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-
|
||||
预估
|
||||
结果</panel_attributes>
|
||||
<additional_attributes>10.0;10.0;10.0;70.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>650</x>
|
||||
<y>360</y>
|
||||
<w>60</w>
|
||||
<h>90</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-
|
||||
预估
|
||||
结果</panel_attributes>
|
||||
<additional_attributes>10.0;10.0;10.0;70.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>500</x>
|
||||
<y>290</y>
|
||||
<w>60</w>
|
||||
<h>80</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-
|
||||
方案
|
||||
</panel_attributes>
|
||||
<additional_attributes>10.0;60.0;10.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>310</x>
|
||||
<y>350</y>
|
||||
<w>410</w>
|
||||
<h>30</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=-</panel_attributes>
|
||||
<additional_attributes>10.0;10.0;390.0;10.0</additional_attributes>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLClass</id>
|
||||
<coordinates>
|
||||
<x>240</x>
|
||||
<y>130</y>
|
||||
<w>550</w>
|
||||
<h>380</h>
|
||||
</coordinates>
|
||||
<panel_attributes>**思考**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
fontsize=26
|
||||
valign=center
|
||||
</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Relation</id>
|
||||
<coordinates>
|
||||
<x>110</x>
|
||||
<y>280</y>
|
||||
<w>150</w>
|
||||
<h>40</h>
|
||||
</coordinates>
|
||||
<panel_attributes>lt=<-
|
||||
事件</panel_attributes>
|
||||
<additional_attributes>130.0;20.0;10.0;20.0</additional_attributes>
|
||||
</element>
|
||||
</diagram>
|
|
@ -0,0 +1,112 @@
|
|||
<mxfile host="Electron" modified="2024-04-15T05:34:30.821Z" agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/24.1.0 Chrome/120.0.6099.109 Electron/28.1.0 Safari/537.36" etag="t7lhPaXPPxg_UXadav6-" version="24.1.0" type="device">
|
||||
<diagram name="第 1 页" id="kxUDNqGiwxb-ewQ4IFuE">
|
||||
<mxGraphModel dx="954" dy="657" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="827" pageHeight="1169" math="0" shadow="0">
|
||||
<root>
|
||||
<mxCell id="0" />
|
||||
<mxCell id="1" parent="0" />
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-6" value="Timeline" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=left;" vertex="1" parent="1">
|
||||
<mxGeometry x="600" width="600" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-7" value="#" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=center;" vertex="1" parent="1">
|
||||
<mxGeometry x="40" y="40" width="40" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-8" value="<span>ego</span>" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=center;" vertex="1" parent="1">
|
||||
<mxGeometry x="80" y="40" width="280" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-9" value="Duration" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=center;" vertex="1" parent="1">
|
||||
<mxGeometry x="360" y="40" width="80" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-10" value="Start" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=center;" vertex="1" parent="1">
|
||||
<mxGeometry x="440" y="40" width="80" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-11" value="ETA" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=center;" vertex="1" parent="1">
|
||||
<mxGeometry x="520" y="40" width="80" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-126" value="<span>Subtask</span>" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="80" y="200" width="280" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-127" value="…" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="40" y="200" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-128" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="360" y="200" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-129" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="440" y="200" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-130" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="520" y="200" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-131" value="<span>Subtask</span>" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="80" y="140" width="280" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-132" value="…" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="40" y="140" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-133" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="360" y="140" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-134" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="440" y="140" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-135" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="520" y="140" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-136" value="<span>Subtask</span>" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="80" y="170" width="280" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-137" value="…" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="40" y="170" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-138" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="360" y="170" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-139" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="440" y="170" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-140" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="520" y="170" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-141" value="日计划" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="80" y="80" width="280" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-142" value="…" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="40" y="80" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-143" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="360" y="80" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-144" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="440" y="80" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-145" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="520" y="80" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-146" value="日小结" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="80" y="110" width="280" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-147" value="…" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="40" y="110" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-148" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="360" y="110" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-149" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="440" y="110" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-150" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="520" y="110" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-223" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" edge="1" parent="1" source="rgkcXzQiamRppXNhV8tw-221" target="rgkcXzQiamRppXNhV8tw-222">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-221" value="手工" style="rounded=1;whiteSpace=wrap;html=1;fontFamily=Helvetica;fontSize=12;fontColor=#000000;align=left;strokeColor=#D6D6D6;fillColor=#FBE1C0;" vertex="1" parent="1">
|
||||
<mxGeometry x="630" y="80" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-222" value="代码" style="rounded=1;whiteSpace=wrap;html=1;fontFamily=Helvetica;fontSize=12;fontColor=#000000;align=left;strokeColor=#D6D6D6;fillColor=#FBE1C0;" vertex="1" parent="1">
|
||||
<mxGeometry x="770" y="80" width="100" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
</root>
|
||||
</mxGraphModel>
|
||||
</diagram>
|
||||
</mxfile>
|
|
@ -0,0 +1,171 @@
|
|||
<!DOCTYPE html>
|
||||
<html lang="zh-cn">
|
||||
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<title>entry page</title>
|
||||
<script src="marked.min.js"></script>
|
||||
<script type="text/javascript" src="yaml.min.js"></script>
|
||||
|
||||
<script>
|
||||
var todayurl, tomorrowurl;
|
||||
var seasonurl;
|
||||
|
||||
var year = datestr().slice(0, 4);
|
||||
var month = datestr().slice(4, 6);
|
||||
var season = Math.ceil(parseInt(month) / 3);
|
||||
var seasonpath = "data/season/" + year + "S" + season + ".yaml";
|
||||
|
||||
window.onload = function () {
|
||||
//alert(document.domain);
|
||||
if (document.domain == "hyg.codeberg.page") {
|
||||
todayurl = "https://hyg.codeberg.page/blog/@master/release/time/d." + datestr() + ".md";
|
||||
tomorrowurl = "https://hyg.codeberg.page/blog/@master/release/time/d." + datestr(1) + ".md";
|
||||
seasonurl = '';
|
||||
} else if (document.domain == "hyg.github.io") {
|
||||
todayurl = "http://hyg.github.io/blog/release/time/d." + datestr() + ".md";
|
||||
tomorrowurl = "http://hyg.github.io/blog/release/time/d." + datestr(1) + ".md";
|
||||
seasonurl = "http://hyg.github.io/ego/" + seasonpath;
|
||||
} else if (document.domain == "today.mars22.com") {
|
||||
todayurl = "http://today.mars22.com/blog/release/time/d." + datestr() + ".md";
|
||||
tomorrowurl = "http://today.mars22.com/blog/release/time/d." + datestr(1) + ".md";
|
||||
seasonurl = "http://today.mars22.com/ego/" + seasonpath;
|
||||
}
|
||||
|
||||
todayurl = "https://raw.githubusercontent.com/hyg/blog/refs/heads/master/release/time/d." + datestr() + ".md";
|
||||
tomorrowurl = "https://raw.githubusercontent.com/hyg/blog/refs/heads/master/release/time/d." + datestr(1) + ".md";
|
||||
seasonurl = "https://raw.githubusercontent.com/hyg/ego/refs/heads/vat/" + seasonpath;
|
||||
|
||||
getTextFileFromURL(todayurl, "today");
|
||||
getTextFileFromURL(tomorrowurl, "tomorrow");
|
||||
if (seasonurl != '') {
|
||||
getTododataFromURL(seasonurl, "todo");
|
||||
}
|
||||
}
|
||||
|
||||
function getTododataFromURL(url, id) {
|
||||
var xmlhttp = new XMLHttpRequest();
|
||||
xmlhttp.onreadystatechange = function () {
|
||||
/* alert(xmlhttp.readyState);
|
||||
alert(xmlhttp.status);
|
||||
alert(xmlhttp.responseText); */
|
||||
if (xmlhttp.readyState == 4 && xmlhttp.status == 200) {
|
||||
var seasonobj = YAML.parse(xmlhttp.responseText);
|
||||
var statobj = new Object();
|
||||
statobj.total = { alloc: 0, sold: 0, hold: 0, todo: 0 };
|
||||
for (var task in seasonobj.time.alloc) {
|
||||
statobj[task] = new Object();
|
||||
statobj[task].alloc = parseInt(seasonobj.time.alloc[task]);
|
||||
if (seasonobj.time.sold[task] != null) {
|
||||
statobj[task].sold = parseInt(seasonobj.time.sold[task]);
|
||||
} else {
|
||||
statobj[task].sold = 0;
|
||||
}
|
||||
statobj[task].hold = statobj[task].alloc - statobj[task].sold;
|
||||
|
||||
statobj.total.alloc = statobj.total.alloc + statobj[task].alloc;
|
||||
statobj.total.sold = statobj.total.sold + statobj[task].sold;
|
||||
statobj[task].todo = 0;
|
||||
}
|
||||
for (var task in seasonobj.time.sold) {
|
||||
if (statobj[task] == null) {
|
||||
statobj[task] = new Object();
|
||||
statobj[task].alloc = 0;
|
||||
statobj[task].sold = parseInt(seasonobj.time.sold[task]);
|
||||
statobj[task].hold = statobj[task].alloc - statobj[task].sold;
|
||||
|
||||
statobj.total.alloc = statobj.total.alloc + statobj[task].alloc;
|
||||
statobj.total.sold = statobj.total.sold + statobj[task].sold;
|
||||
statobj[task].todo = 0;
|
||||
}
|
||||
}
|
||||
statobj.total.hold = statobj.total.alloc - statobj.total.sold;
|
||||
for (var task in seasonobj.todo) {
|
||||
statobj[task].todo = todosum(seasonobj.todo[task]);
|
||||
statobj.total.todo = statobj.total.todo + statobj[task].todo;
|
||||
}
|
||||
|
||||
document.getElementById(id).innerHTML = createTableHTML(statobj);
|
||||
}
|
||||
};
|
||||
xmlhttp.open("GET", url, true);
|
||||
xmlhttp.send();
|
||||
}
|
||||
|
||||
function getTextFileFromURL(url, id) {
|
||||
var xmlhttp = new XMLHttpRequest();
|
||||
xmlhttp.onreadystatechange = function () {
|
||||
/* alert(xmlhttp.readyState);
|
||||
alert(xmlhttp.status);
|
||||
alert(xmlhttp.responseText); */
|
||||
if (xmlhttp.readyState == 4 && xmlhttp.status == 200) {
|
||||
var text = xmlhttp.responseText;
|
||||
document.getElementById(id).innerHTML = marked.parse(text);
|
||||
}
|
||||
};
|
||||
xmlhttp.open("GET", url, true);
|
||||
xmlhttp.send();
|
||||
}
|
||||
|
||||
function datestr(diff = 0) {
|
||||
var theDate = new Date();
|
||||
theDate.setDate(theDate.getDate() + diff);
|
||||
|
||||
var year = theDate.getFullYear();
|
||||
var month = theDate.getMonth() + 1 < 10 ? "0" + (theDate.getMonth() + 1) : theDate.getMonth() + 1;
|
||||
var day = theDate.getDate() < 10 ? "0" + theDate.getDate() : theDate.getDate();
|
||||
var dateStr = year + "" + month + "" + day;
|
||||
|
||||
return dateStr;
|
||||
}
|
||||
|
||||
function todosum(todoarray) {
|
||||
var sum = 0;
|
||||
|
||||
for (var i in todoarray) {
|
||||
for (var key in todoarray[i]) {
|
||||
if (!isNaN(parseInt(key))) {
|
||||
sum = sum + parseInt(key);
|
||||
} else if (key == "bind") {
|
||||
sum = sum + todosum(todoarray[i][key]);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
return sum;
|
||||
}
|
||||
|
||||
function createTableHTML(data) {
|
||||
let tableHTML = '<table border="1"><tr>';
|
||||
tableHTML += `<th>task</th>`;
|
||||
Object.keys(data.PSMD).forEach(key => {
|
||||
tableHTML += `<th>${key}</th>`;
|
||||
});
|
||||
tableHTML += '</tr>';
|
||||
|
||||
for (var task in data) {
|
||||
tableHTML += '<tr><td>' + task + '</td>';
|
||||
for (var item in data[task]) {
|
||||
tableHTML += '<td>' + data[task][item] + '</td>';
|
||||
}
|
||||
tableHTML += '</tr>';
|
||||
}
|
||||
|
||||
tableHTML += '</table>';
|
||||
return tableHTML;
|
||||
}
|
||||
</script>
|
||||
</head>
|
||||
|
||||
<body>
|
||||
<div id="today"></div>
|
||||
<br /><br />
|
||||
<hr /><br /><br />
|
||||
<div id="tomorrow"></div>
|
||||
<br /><br />
|
||||
<hr /><br />
|
||||
season stat:<br />
|
||||
<div id="todo"></div>
|
||||
</body>
|
||||
|
||||
</html>
|
|
@ -0,0 +1,30 @@
|
|||
<!DOCTYPE html>
|
||||
<html lang="zh-cn">
|
||||
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<title>entry page</title>
|
||||
<script src="marked.min.js"></script>
|
||||
<script>
|
||||
|
||||
location.href = "https://codeberg.org/hyg/blog/src/branch/master/release/time/d."+datestr()+".md";
|
||||
|
||||
function datestr(diff = 0) {
|
||||
var theDate = new Date();
|
||||
theDate.setDate(theDate.getDate() + diff);
|
||||
|
||||
var year = theDate.getFullYear();
|
||||
var month = theDate.getMonth() + 1 < 10 ? "0" + (theDate.getMonth() + 1) : theDate.getMonth() + 1;
|
||||
var day = theDate.getDate() < 10 ? "0" + theDate.getDate() : theDate.getDate();
|
||||
var dateStr = year + "" + month + "" + day;
|
||||
|
||||
return dateStr;
|
||||
}
|
||||
</script>
|
||||
</head>
|
||||
|
||||
<body>
|
||||
<div id="daylog"></div>
|
||||
</body>
|
||||
|
||||
</html>
|
|
@ -0,0 +1,450 @@
|
|||
<mxfile host="Electron" modified="2024-04-15T05:41:52.634Z" agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/24.1.0 Chrome/120.0.6099.109 Electron/28.1.0 Safari/537.36" etag="9zYP8K1f_hWhMWbOoZPi" version="24.1.0" type="device" pages="2">
|
||||
<diagram name="ego" id="kxUDNqGiwxb-ewQ4IFuE">
|
||||
<mxGraphModel dx="954" dy="657" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="827" pageHeight="1169" math="0" shadow="0">
|
||||
<root>
|
||||
<mxCell id="0" />
|
||||
<mxCell id="1" parent="0" />
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-6" value="Timeline" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=left;" vertex="1" parent="1">
|
||||
<mxGeometry x="600" width="600" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-7" value="#" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=center;" vertex="1" parent="1">
|
||||
<mxGeometry x="40" y="40" width="40" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-8" value="<span>ego</span>" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=center;" vertex="1" parent="1">
|
||||
<mxGeometry x="80" y="40" width="280" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-9" value="Duration" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=center;" vertex="1" parent="1">
|
||||
<mxGeometry x="360" y="40" width="80" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-10" value="Start" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=center;" vertex="1" parent="1">
|
||||
<mxGeometry x="440" y="40" width="80" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-11" value="ETA" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=center;" vertex="1" parent="1">
|
||||
<mxGeometry x="520" y="40" width="80" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-126" value="<span>Subtask</span>" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="80" y="200" width="280" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-127" value="…" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="40" y="200" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-128" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="360" y="200" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-129" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="440" y="200" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-130" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="520" y="200" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-131" value="<span>Subtask</span>" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="80" y="140" width="280" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-132" value="…" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="40" y="140" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-133" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="360" y="140" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-134" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="440" y="140" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-135" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="520" y="140" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-136" value="<span>Subtask</span>" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="80" y="170" width="280" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-137" value="…" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="40" y="170" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-138" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="360" y="170" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-139" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="440" y="170" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-140" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="520" y="170" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-141" value="日计划" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="80" y="80" width="280" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-142" value="…" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="40" y="80" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-143" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="360" y="80" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-144" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="440" y="80" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-145" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="520" y="80" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-146" value="日小结" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="80" y="110" width="280" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-147" value="…" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="40" y="110" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-148" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="360" y="110" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-149" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="440" y="110" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-150" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="520" y="110" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-223" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" edge="1" parent="1" source="rgkcXzQiamRppXNhV8tw-221" target="rgkcXzQiamRppXNhV8tw-222">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-221" value="手工" style="rounded=1;whiteSpace=wrap;html=1;fontFamily=Helvetica;fontSize=12;fontColor=#000000;align=left;strokeColor=#D6D6D6;fillColor=#FBE1C0;" vertex="1" parent="1">
|
||||
<mxGeometry x="630" y="80" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="rgkcXzQiamRppXNhV8tw-222" value="代码" style="rounded=1;whiteSpace=wrap;html=1;fontFamily=Helvetica;fontSize=12;fontColor=#000000;align=left;strokeColor=#D6D6D6;fillColor=#FBE1C0;" vertex="1" parent="1">
|
||||
<mxGeometry x="770" y="110" width="100" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
</root>
|
||||
</mxGraphModel>
|
||||
</diagram>
|
||||
<diagram id="HdWwP08hk-JMCdzUxNTV" name="PSMD">
|
||||
<mxGraphModel dx="954" dy="1826" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="827" pageHeight="1169" math="0" shadow="0">
|
||||
<root>
|
||||
<mxCell id="0" />
|
||||
<mxCell id="1" parent="0" />
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-31" value="<span style="">Complete project execution</span>" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#f7c382;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="50" y="70" width="560" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-32" value="entry" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FBE1C0;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="90" y="100" width="280" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-33" value="<span>Subtask</span>" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="90" y="130" width="280" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-34" value="<span>…</span>" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="90" y="190" width="280" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-35" value="<span>…</span>" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="90" y="250" width="280" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-36" value="<span>…</span>" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="90" y="280" width="280" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-37" value="default" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FBE1C0;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="90" y="310" width="280" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-38" value="<span>…</span>" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="90" y="340" width="280" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-39" value="<span>…</span>" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="90" y="370" width="280" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-40" value="<span>…</span>" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="90" y="400" width="280" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-41" value="Timeline" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=left;" vertex="1" parent="1">
|
||||
<mxGeometry x="610" y="-10" width="160" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-42" value="<span>…</span>" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="90" y="430" width="280" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-43" value="<span>…</span>" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="90" y="460" width="280" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-44" value="<span>…</span>" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="90" y="490" width="280" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-45" value="<span>1406</span>" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FBE1C0;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="90" y="520" width="280" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-46" value="<span>…</span>" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="90" y="550" width="280" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-47" value="<span>…</span>" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="90" y="580" width="280" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-48" value="<span>…</span>" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="90" y="610" width="280" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-49" value="<span>…</span>" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="90" y="640" width="280" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-50" value="<span style="white-space: nowrap">…</span>" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="90" y="670" width="280" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-51" value="1" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FBE1C0;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="50" y="100" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-52" value="1.1" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="50" y="130" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-53" value="1.2" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="50" y="160" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-54" value="1.4" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="50" y="220" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-55" value="1.6" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="50" y="280" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-56" value="2" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FBE1C0;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="50" y="310" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-57" value="2.1" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="50" y="340" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-58" value="2.2" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="50" y="370" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-59" value="2.3" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="50" y="400" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-60" value="2.4" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="50" y="430" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-61" value="2.5" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="50" y="460" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-62" value="2.6" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="50" y="490" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-63" value="3" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FBE1C0;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="50" y="520" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-64" value="3.1" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="50" y="550" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-65" value="3.2" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="50" y="580" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-66" value="3.3" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="50" y="610" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-67" value="3.4" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="50" y="640" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-68" value="3.5" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="50" y="670" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-69" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#f7c382;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="370" y="70" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-70" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FBE1C0;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="370" y="100" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-71" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="370" y="130" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-72" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#f7c382;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="450" y="70" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-73" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FBE1C0;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="450" y="100" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-74" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="450" y="130" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-75" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#f7c382;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="530" y="70" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-76" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FBE1C0;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="530" y="100" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-77" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="530" y="130" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-78" value="<span>…</span>" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="90" y="160" width="280" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-79" value="1.3" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="50" y="190" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-80" value="<span>…</span>" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;" vertex="1" parent="1">
|
||||
<mxGeometry x="90" y="220" width="280" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-81" value="1.5" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=right;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="50" y="250" width="40" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-82" value="#" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=center;" vertex="1" parent="1">
|
||||
<mxGeometry x="50" y="30" width="40" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-83" value="PSMD" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=center;" vertex="1" parent="1">
|
||||
<mxGeometry x="90" y="30" width="280" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-84" value="Duration" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=center;" vertex="1" parent="1">
|
||||
<mxGeometry x="370" y="30" width="80" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-85" value="Start" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=center;" vertex="1" parent="1">
|
||||
<mxGeometry x="450" y="30" width="80" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-86" value="ETA" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#D6D6D6;align=center;" vertex="1" parent="1">
|
||||
<mxGeometry x="530" y="30" width="80" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-87" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="450" y="160" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-88" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="530" y="160" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-89" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="370" y="160" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-90" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="450" y="190" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-91" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="530" y="190" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-92" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="370" y="190" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-93" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="370" y="220" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-94" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="450" y="220" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-95" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="450" y="250" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-96" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="370" y="250" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-97" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="450" y="280" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-98" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="370" y="280" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-99" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="530" y="220" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-100" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="530" y="250" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-101" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="530" y="280" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-102" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="370" y="340" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-103" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="450" y="340" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-104" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="450" y="370" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-105" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="370" y="370" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-106" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="450" y="400" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-107" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="370" y="400" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-108" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="530" y="340" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-109" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="530" y="370" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-110" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="530" y="400" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-111" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="370" y="430" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-112" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="450" y="430" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-113" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="450" y="460" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-114" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="370" y="460" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-115" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="450" y="490" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-116" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="370" y="490" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-117" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="530" y="430" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-118" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="530" y="460" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-119" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="530" y="490" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-120" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="370" y="550" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-121" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="450" y="550" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-122" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="450" y="580" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-123" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="370" y="580" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-124" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="450" y="610" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-125" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="370" y="610" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-126" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="530" y="550" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-127" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="530" y="580" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-128" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="530" y="610" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-129" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="370" y="640" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-130" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="450" y="640" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-131" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="450" y="670" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-132" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="370" y="670" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-133" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="530" y="640" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-134" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FFFFFF;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="530" y="670" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-135" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FBE1C0;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="370" y="310" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-136" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FBE1C0;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="450" y="310" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-137" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FBE1C0;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="530" y="310" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-138" value="XY days" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FBE1C0;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="370" y="520" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-139" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FBE1C0;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="450" y="520" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="oimEdPAALOH4pW6EFj02-140" value="mm-dd-yy" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=#D6D6D6;fillColor=#FBE1C0;align=left;spacingLeft=10;spacingRight=8;" vertex="1" parent="1">
|
||||
<mxGeometry x="530" y="520" width="80" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
</root>
|
||||
</mxGraphModel>
|
||||
</diagram>
|
||||
</mxfile>
|
|
@ -0,0 +1,28 @@
|
|||
{
|
||||
"name": "release",
|
||||
"lockfileVersion": 3,
|
||||
"requires": true,
|
||||
"packages": {
|
||||
"": {
|
||||
"dependencies": {
|
||||
"js-yaml": "^4.1.0"
|
||||
}
|
||||
},
|
||||
"node_modules/argparse": {
|
||||
"version": "2.0.1",
|
||||
"resolved": "https://registry.npmjs.org/argparse/-/argparse-2.0.1.tgz",
|
||||
"integrity": "sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q=="
|
||||
},
|
||||
"node_modules/js-yaml": {
|
||||
"version": "4.1.0",
|
||||
"resolved": "https://registry.npmjs.org/js-yaml/-/js-yaml-4.1.0.tgz",
|
||||
"integrity": "sha512-wpxZs9NoxZaJESJGIZTyDEaYpl0FKSA+FB9aJiyemKhMwkxQg63h4T1KJgUGHpTqPDNRcmmYLugrRjJlBtWvRA==",
|
||||
"dependencies": {
|
||||
"argparse": "^2.0.1"
|
||||
},
|
||||
"bin": {
|
||||
"js-yaml": "bin/js-yaml.js"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
|
@ -0,0 +1,8 @@
|
|||
{
|
||||
"dependencies": {
|
||||
"js-yaml": "^4.1.0"
|
||||
},
|
||||
"scripts":{
|
||||
"over": "git add . && git commit -m \"day over\" && git push all"
|
||||
}
|
||||
}
|
|
@ -0,0 +1,200 @@
|
|||
timetype:
|
||||
- name: work
|
||||
- name: free
|
||||
- name: discuss
|
||||
- name: learn
|
||||
- name: prepare
|
||||
- name: sleep
|
||||
- name: food
|
||||
- name: check
|
||||
dayplan:
|
||||
1:
|
||||
time:
|
||||
- beginhour: 04
|
||||
beginminute: 0
|
||||
amount: 15
|
||||
type: free
|
||||
name: 休整
|
||||
- beginhour: 04
|
||||
beginminute: 15
|
||||
amount: 60
|
||||
type: prepare
|
||||
name: 备餐、运动
|
||||
- beginhour: 05
|
||||
beginminute: 15
|
||||
amount: 45
|
||||
type: food
|
||||
name: 早餐
|
||||
- beginhour: 06
|
||||
beginminute: 0
|
||||
amount: 45
|
||||
type: discuss
|
||||
name: 会议、自习
|
||||
- beginhour: 06
|
||||
beginminute: 45
|
||||
amount: 60
|
||||
type: free
|
||||
name: 休整
|
||||
- beginhour: 07
|
||||
beginminute: 45
|
||||
amount: 60
|
||||
type: work
|
||||
name: 静默工作
|
||||
namelink: http://simp.ly/p/xtgD4F
|
||||
- beginhour: 08
|
||||
beginminute: 45
|
||||
amount: 45
|
||||
type: free
|
||||
name: 休整
|
||||
- beginhour: 09
|
||||
beginminute: 30
|
||||
amount: 90
|
||||
type: work
|
||||
name: 静默工作
|
||||
namelink: http://simp.ly/p/j1SspP
|
||||
- beginhour: 11
|
||||
beginminute: 00
|
||||
amount: 180
|
||||
type: food
|
||||
name: 备餐、午餐午休
|
||||
- beginhour: 14
|
||||
beginminute: 0
|
||||
amount: 30
|
||||
type: work
|
||||
name: 静默工作
|
||||
namelink: http://simp.ly/p/8t3vlk
|
||||
- beginhour: 14
|
||||
beginminute: 30
|
||||
amount: 30
|
||||
type: work
|
||||
name: 静默工作
|
||||
namelink: http://simp.ly/p/5k9gJy
|
||||
- beginhour: 15
|
||||
beginminute: 0
|
||||
amount: 60
|
||||
type: free
|
||||
name: 休整
|
||||
- beginhour: 16
|
||||
beginminute: 0
|
||||
amount: 60
|
||||
type: work
|
||||
name: 静默工作
|
||||
namelink: http://simp.ly/p/4QDThK
|
||||
- beginhour: 17
|
||||
beginminute: 00
|
||||
amount: 120
|
||||
type: food
|
||||
name: 晚餐
|
||||
- beginhour: 19
|
||||
beginminute: 00
|
||||
amount: 60
|
||||
type: check
|
||||
name: 讨论、整理提交
|
||||
readme: |
|
||||
模版一采用静默工作方式。
|
||||
希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com),通常安排在后面某天的早餐(5:15~5:59)或会议时间(6:00~6:45)。
|
||||
planstr: |-
|
||||
| 时间片 | 时长 | 用途 |
|
||||
| --- | --- | --- |
|
||||
| 4:00~4:14 | 15 | 休整 |
|
||||
| 4:15~5:14 | 60 | 备餐、运动 |
|
||||
| 5:15~5:59 | 45 | 早餐 |
|
||||
| 6:00~6:44 | 45 | 会议、自习 |
|
||||
| 6:45~7:44 | 60 | 休整 |
|
||||
| 7:45~8:44 | 60 | [静默工作](http://simp.ly/p/xtgD4F) |
|
||||
| 8:45~9:29 | 45 | 休整 |
|
||||
| 9:30~10:59 | 90 | [静默工作](http://simp.ly/p/j1SspP) |
|
||||
| 11:00~13:59 | 180 | 备餐、午餐午休 |
|
||||
| 14:00~14:29 | 30 | [静默工作](http://simp.ly/p/8t3vlk) |
|
||||
| 14:30~14:59 | 30 | [静默工作](http://simp.ly/p/5k9gJy) |
|
||||
| 15:00~15:59 | 60 | 休整 |
|
||||
| 16:00~16:59 | 60 | [静默工作](http://simp.ly/p/4QDThK) |
|
||||
| 17:00~18:59 | 120 | 晚餐 |
|
||||
| 19:00~19:59 | 60 | 讨论、整理提交 |
|
||||
|
||||
模版一采用静默工作方式。
|
||||
希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com),通常安排在后面某天的早餐(5:15~5:59)或会议时间(6:00~6:45)。
|
||||
2:
|
||||
time:
|
||||
- beginhour: 04
|
||||
beginminute: 0
|
||||
amount: 15
|
||||
type: free
|
||||
name: 休整
|
||||
- beginhour: 04
|
||||
beginminute: 15
|
||||
amount: 60
|
||||
type: prepare
|
||||
name: 备餐、运动
|
||||
- beginhour: 05
|
||||
beginminute: 15
|
||||
amount: 45
|
||||
type: food
|
||||
name: 早餐
|
||||
- beginhour: 06
|
||||
beginminute: 0
|
||||
amount: 45
|
||||
type: discuss
|
||||
name: 会议、自习
|
||||
- beginhour: 06
|
||||
beginminute: 45
|
||||
amount: 60
|
||||
type: free
|
||||
name: 休整
|
||||
- beginhour: 07
|
||||
beginminute: 45
|
||||
amount: 195
|
||||
type: work
|
||||
name: 工作
|
||||
namelink: http://simp.ly/p/3GXNTh
|
||||
- beginhour: 11
|
||||
beginminute: 00
|
||||
amount: 180
|
||||
type: food
|
||||
name: 备餐、午餐午休
|
||||
- beginhour: 14
|
||||
beginminute: 0
|
||||
amount: 90
|
||||
type: work
|
||||
name: 工作
|
||||
namelink: http://simp.ly/p/lsBYG9
|
||||
- beginhour: 15
|
||||
beginminute: 30
|
||||
amount: 30
|
||||
type: free
|
||||
name: 休整
|
||||
- beginhour: 16
|
||||
beginminute: 0
|
||||
amount: 60
|
||||
type: work
|
||||
name: 工作
|
||||
namelink: http://simp.ly/p/MpcbHD
|
||||
- beginhour: 17
|
||||
beginminute: 00
|
||||
amount: 120
|
||||
type: food
|
||||
name: 晚餐
|
||||
- beginhour: 19
|
||||
beginminute: 00
|
||||
amount: 60
|
||||
type: check
|
||||
name: 讨论、整理提交
|
||||
readme: |
|
||||
工作的同时可以在线讨论。
|
||||
planstr: |-
|
||||
| 时间片 | 时长 | 用途 |
|
||||
| --- | --- | --- |
|
||||
| 4:00~4:14 | 15 | 休整 |
|
||||
| 4:15~5:14 | 60 | 备餐、运动 |
|
||||
| 5:15~5:59 | 45 | 早餐 |
|
||||
| 6:00~6:44 | 45 | 会议、自习 |
|
||||
| 6:45~7:44 | 60 | 休整 |
|
||||
| 7:45~10:59 | 195 | [工作](http://simp.ly/p/3GXNTh) |
|
||||
| 11:00~13:59 | 180 | 备餐、午餐午休 |
|
||||
| 14:00~15:29 | 90 | [工作](http://simp.ly/p/lsBYG9) |
|
||||
| 15:30~15:59 | 30 | 休整 |
|
||||
| 16:00~16:59 | 60 | [工作](http://simp.ly/p/MpcbHD) |
|
||||
| 17:00~18:59 | 120 | 晚餐 |
|
||||
| 19:00~19:59 | 60 | 讨论、整理提交 |
|
||||
|
||||
工作的同时可以在线讨论。
|
|
@ -0,0 +1,171 @@
|
|||
<!DOCTYPE html>
|
||||
<html lang="zh-cn">
|
||||
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<title>entry page</title>
|
||||
<script src="marked.min.js"></script>
|
||||
<script type="text/javascript" src="yaml.min.js"></script>
|
||||
|
||||
<script>
|
||||
var todayurl, tomorrowurl;
|
||||
var seasonurl;
|
||||
var drafturl = "https://app.simplenote.com/p/j1SspP";
|
||||
|
||||
var year = datestr().slice(0, 4);
|
||||
var month = datestr().slice(4, 6);
|
||||
var season = Math.ceil(parseInt(month) / 3);
|
||||
var seasonpath = "data/season/" + year + "S" + season + ".yaml";
|
||||
|
||||
window.onload = function () {
|
||||
if (document.domain == "hyg.codeberg.page") {
|
||||
todayurl = "https://hyg.codeberg.page/blog/@master/release/time/d." + datestr() + ".md";
|
||||
tomorrowurl = "https://hyg.codeberg.page/blog/@master/release/time/d." + datestr(1) + ".md";
|
||||
seasonurl = '';
|
||||
} else if (document.domain == "hyg.github.io") {
|
||||
todayurl = "http://hyg.github.io/blog/release/time/d." + datestr() + ".md";
|
||||
tomorrowurl = "http://hyg.github.io/blog/release/time/d." + datestr(1) + ".md";
|
||||
seasonurl = "http://hyg.github.io/ego/" + seasonpath;
|
||||
} else if (document.domain == "today.mars22.com") {
|
||||
todayurl = "http://today.mars22.com/blog/release/time/d." + datestr() + ".md";
|
||||
tomorrowurl = "http://today.mars22.com/blog/release/time/d." + datestr(1) + ".md";
|
||||
seasonurl = "http://today.mars22.com/ego/" + seasonpath;
|
||||
}
|
||||
|
||||
getTextFileFromURL(drafturl, "draft");
|
||||
//getTextFileFromURL(todayurl, "today");
|
||||
//getTextFileFromURL(tomorrowurl, "tomorrow");
|
||||
if (seasonurl != '') {
|
||||
//getTododataFromURL(seasonurl, "todo");
|
||||
}
|
||||
}
|
||||
|
||||
function getTododataFromURL(url, id) {
|
||||
var xmlhttp = new XMLHttpRequest();
|
||||
xmlhttp.onreadystatechange = function () {
|
||||
/* alert(xmlhttp.readyState);
|
||||
alert(xmlhttp.status);
|
||||
alert(xmlhttp.responseText); */
|
||||
if (xmlhttp.readyState == 4 && xmlhttp.status == 200) {
|
||||
var seasonobj = YAML.parse(xmlhttp.responseText);
|
||||
var statobj = new Object();
|
||||
statobj.total = { alloc: 0, sold: 0, hold: 0, todo: 0 };
|
||||
for (var task in seasonobj.time.alloc) {
|
||||
statobj[task] = new Object();
|
||||
statobj[task].alloc = parseInt(seasonobj.time.alloc[task]);
|
||||
if (seasonobj.time.sold[task] != null) {
|
||||
statobj[task].sold = parseInt(seasonobj.time.sold[task]);
|
||||
} else {
|
||||
statobj[task].sold = 0;
|
||||
}
|
||||
statobj[task].hold = statobj[task].alloc - statobj[task].sold;
|
||||
|
||||
statobj.total.alloc = statobj.total.alloc + statobj[task].alloc;
|
||||
statobj.total.sold = statobj.total.sold + statobj[task].sold;
|
||||
statobj[task].todo = 0;
|
||||
}
|
||||
for (var task in seasonobj.time.sold) {
|
||||
if (statobj[task] == null) {
|
||||
statobj[task] = new Object();
|
||||
statobj[task].alloc = 0;
|
||||
statobj[task].sold = parseInt(seasonobj.time.sold[task]);
|
||||
statobj[task].hold = statobj[task].alloc - statobj[task].sold;
|
||||
|
||||
statobj.total.alloc = statobj.total.alloc + statobj[task].alloc;
|
||||
statobj.total.sold = statobj.total.sold + statobj[task].sold;
|
||||
statobj[task].todo = 0;
|
||||
}
|
||||
}
|
||||
statobj.total.hold = statobj.total.alloc - statobj.total.sold;
|
||||
for (var task in seasonobj.todo) {
|
||||
statobj[task].todo = todosum(seasonobj.todo[task]);
|
||||
statobj.total.todo = statobj.total.todo + statobj[task].todo;
|
||||
}
|
||||
|
||||
document.getElementById(id).innerHTML = createTableHTML(statobj);
|
||||
}
|
||||
};
|
||||
xmlhttp.open("GET", url, true);
|
||||
xmlhttp.send();
|
||||
}
|
||||
|
||||
function getTextFileFromURL(url, id) {
|
||||
var xmlhttp = new XMLHttpRequest();
|
||||
xmlhttp.onreadystatechange = function () {
|
||||
alert(xmlhttp.readyState);
|
||||
alert(xmlhttp.status);
|
||||
alert(xmlhttp.responseText);
|
||||
if (xmlhttp.readyState == 4 && xmlhttp.status == 200) {
|
||||
var text = xmlhttp.responseText;
|
||||
document.getElementById(id).innerHTML = marked.parse(text);
|
||||
}
|
||||
};
|
||||
xmlhttp.open("GET", url, true);
|
||||
xmlhttp.send();
|
||||
}
|
||||
|
||||
function datestr(diff = 0) {
|
||||
var theDate = new Date();
|
||||
theDate.setDate(theDate.getDate() + diff);
|
||||
|
||||
var year = theDate.getFullYear();
|
||||
var month = theDate.getMonth() + 1 < 10 ? "0" + (theDate.getMonth() + 1) : theDate.getMonth() + 1;
|
||||
var day = theDate.getDate() < 10 ? "0" + theDate.getDate() : theDate.getDate();
|
||||
var dateStr = year + "" + month + "" + day;
|
||||
|
||||
return dateStr;
|
||||
}
|
||||
|
||||
function todosum(todoarray) {
|
||||
var sum = 0;
|
||||
|
||||
for (var i in todoarray) {
|
||||
for (var key in todoarray[i]) {
|
||||
if (!isNaN(parseInt(key))) {
|
||||
sum = sum + parseInt(key);
|
||||
} else if (key == "bind") {
|
||||
sum = sum + todosum(todoarray[i][key]);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
return sum;
|
||||
}
|
||||
|
||||
function createTableHTML(data) {
|
||||
let tableHTML = '<table border="1"><tr>';
|
||||
tableHTML += `<th>task</th>`;
|
||||
Object.keys(data.PSMD).forEach(key => {
|
||||
tableHTML += `<th>${key}</th>`;
|
||||
});
|
||||
tableHTML += '</tr>';
|
||||
|
||||
for(var task in data){
|
||||
tableHTML += '<tr><td>' + task +'</td>';
|
||||
for(var item in data[task]){
|
||||
tableHTML += '<td>' + data[task][item] + '</td>';
|
||||
}
|
||||
tableHTML += '</tr>';
|
||||
}
|
||||
|
||||
tableHTML += '</table>';
|
||||
return tableHTML;
|
||||
}
|
||||
</script>
|
||||
</head>
|
||||
|
||||
<body>
|
||||
<div id="draft"></div>
|
||||
<br /><br />
|
||||
<hr /><br /><br />
|
||||
<div id="today"></div>
|
||||
<br /><br />
|
||||
<hr /><br /><br />
|
||||
<div id="tomorrow"></div>
|
||||
<br /><br />
|
||||
<hr /><br />
|
||||
season stat:<br />
|
||||
<div id="todo"></div>
|
||||
</body>
|
||||
|
||||
</html>
|
|
@ -0,0 +1,61 @@
|
|||
<!DOCTYPE html>
|
||||
<html lang="zh-cn">
|
||||
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<title>entry page</title>
|
||||
<script type="text/javascript" src="yaml.min.js"></script>
|
||||
|
||||
<script>
|
||||
var PSMDdataurl;
|
||||
|
||||
window.onload = function () {
|
||||
if (document.domain == "hyg.codeberg.page") {
|
||||
PSMDdataurl = "https://hyg.codeberg.page/PSMD/@master/data";
|
||||
}else if (document.domain == "hyg.github.io") {
|
||||
PSMDdataurl = "http://hyg.github.io/PSMD/data";
|
||||
}else if (document.domain == "today.mars22.com") {
|
||||
PSMDdataurl = "http://today.mars22.com/PSMD/data";
|
||||
}
|
||||
|
||||
getTextFileFromURL(PSMDdataurl+"/term.d0111eb4.yaml", "term");
|
||||
//getTextFileFromURL(tomorrowurl, "readme");
|
||||
}
|
||||
|
||||
function getTextFileFromURL(url, id) {
|
||||
var xmlhttp = new XMLHttpRequest();
|
||||
xmlhttp.onreadystatechange = function () {
|
||||
if (xmlhttp.readyState == 4 && xmlhttp.status == 200) {
|
||||
var text = xmlhttp.responseText;
|
||||
document.getElementById(id).innerHTML = text;
|
||||
var termobj = YAML.parse(text);
|
||||
for(var i in termobj.item){
|
||||
confirm("是否符合:"+termobj.item[i].text);
|
||||
}
|
||||
}
|
||||
};
|
||||
xmlhttp.open("GET", url, true);
|
||||
xmlhttp.send();
|
||||
}
|
||||
|
||||
function datestr(diff = 0) {
|
||||
var theDate = new Date();
|
||||
theDate.setDate(theDate.getDate() + diff);
|
||||
|
||||
var year = theDate.getFullYear();
|
||||
var month = theDate.getMonth() + 1 < 10 ? "0" + (theDate.getMonth() + 1) : theDate.getMonth() + 1;
|
||||
var day = theDate.getDate() < 10 ? "0" + theDate.getDate() : theDate.getDate();
|
||||
var dateStr = year + "" + month + "" + day;
|
||||
|
||||
return dateStr;
|
||||
}
|
||||
</script>
|
||||
</head>
|
||||
|
||||
<body>
|
||||
<div id="term"></div>
|
||||
<br /><br /><hr /><br /><br />
|
||||
<div id="readme"></div>
|
||||
</body>
|
||||
|
||||
</html>
|
|
@ -0,0 +1,275 @@
|
|||
var fs = require('fs');
|
||||
var yaml = require('js-yaml');
|
||||
|
||||
let gitpath = "../../";
|
||||
let rawrepopath = "../../raw/";
|
||||
let draftrepopath = "../../draft/";
|
||||
|
||||
let helpstr = `
|
||||
node time: today's draft metadata + draft markdown → day log markdown
|
||||
node time 1: diff day's draft metadata + draft markdown → day log markdown
|
||||
node time 20240417: 20240417's draft metadata + draft markdown → day log markdown
|
||||
node time init 1: plan 1 metadata → today draft metadata
|
||||
node time init: draft metadata + plan metadata → today plan markdown + draft markdown
|
||||
`;
|
||||
let today = datestr();
|
||||
|
||||
// read the arguments
|
||||
var arguments = process.argv.splice(2);
|
||||
if (arguments.length > 0) {
|
||||
if ((arguments.length == 1) & (arguments[0] == "init")) {
|
||||
// node time init: draft metadata + plan metadata → today plan markdown
|
||||
var date = datestr();
|
||||
makedayplan(date);
|
||||
} else if ((arguments.length == 2) & (arguments[0] == "init")) {
|
||||
// node time init 1: plan 1 metadata → today draft metadata
|
||||
var date = datestr();
|
||||
var plan = arguments[1];
|
||||
makedaydraft(date, plan)
|
||||
} else if ((arguments.length == 1) & (arguments[0].length == 8)) {
|
||||
//node time 20240417: 20240417's draft metadata + draft markdown → day log markdown
|
||||
var date = parseInt(arguments[0]).toString();
|
||||
makedaylog(date);
|
||||
} else if ((arguments.length == 1) & (arguments[0].length != 8) & (!isNaN(arguments[0]))) {
|
||||
//node time 1: diff day's draft metadata + draft markdown → day log markdown
|
||||
var diff = parseInt(arguments[0]);
|
||||
var date = datestr(diff);
|
||||
makedaylog(date);
|
||||
} else {
|
||||
console.log(helpstr);
|
||||
process.exit();
|
||||
}
|
||||
} else {
|
||||
//node time: today's draft metadata + draft markdown → day log markdown
|
||||
var date = datestr();
|
||||
makedaylog(date);
|
||||
}
|
||||
|
||||
function makedaydraft(date, plan) {
|
||||
var planobj = yaml.load(fs.readFileSync("plan.yaml", 'utf8'));
|
||||
var time = planobj.dayplan[plan].time;
|
||||
|
||||
var draftmetadata = new Object();
|
||||
var drafttimearray = new Array();
|
||||
//console.log(typeof(date));
|
||||
draftmetadata.date = parseInt(date);
|
||||
draftmetadata.plan = parseInt(plan);
|
||||
for (var i in time) {
|
||||
if (time[i].type == "work") {
|
||||
var timeperiod = new Object();
|
||||
timeperiod.begin = date + time[i].beginhour.toString().padStart(2, '0') + time[i].beginminute.toString().padStart(2, '0') + "00";
|
||||
timeperiod.amount = time[i].amount;
|
||||
timeperiod.type = "work";
|
||||
timeperiod.subject = "tbd";
|
||||
timeperiod.name = "tbd";
|
||||
timeperiod.output = "draft/" + date.slice(0, 4) + "/" + date.slice(4, 6) + "/" + timeperiod.begin + ".md";
|
||||
drafttimearray.push(timeperiod);
|
||||
}
|
||||
}
|
||||
draftmetadata.time = drafttimearray;
|
||||
|
||||
var filename = draftrepopath + date.slice(0, 4) + "/" + date.slice(4, 6) + "/" + "d." + date + ".yaml";
|
||||
console.log(filename);
|
||||
console.log(yaml.dump(draftmetadata));
|
||||
fs.writeFileSync(filename, yaml.dump(draftmetadata));
|
||||
}
|
||||
|
||||
function makedayplan(date) {
|
||||
//read wake time from raw repo
|
||||
//var rawhealthfilename = "health/d." + date + ".yaml";
|
||||
//var rawhealthfile = yaml.load(fs.readFileSync(rawrepopath + rawhealthfilename, 'utf8'));
|
||||
//var waketime = rawhealthfile.wake.time;
|
||||
//console.log("wake time:"+waketime);
|
||||
|
||||
var draftmetafilename = draftrepopath + date.slice(0, 4) + "/" + date.slice(4, 6) + "/" + "d." + date + ".yaml";
|
||||
var draftmetadata;
|
||||
try {
|
||||
if (fs.existsSync(draftmetafilename)) {
|
||||
draftmetadata = yaml.load(fs.readFileSync(draftmetafilename, 'utf8'));
|
||||
} else {
|
||||
console.log("the draft metadata isn't exist:" + draftmetafilename);
|
||||
process.exit();
|
||||
}
|
||||
} catch (e) {
|
||||
// failure
|
||||
console.log("yaml read error!" + e);
|
||||
process.exit();
|
||||
}
|
||||
var plan = draftmetadata.plan;
|
||||
|
||||
var timeslicename = new Object();
|
||||
for (var i in draftmetadata.time) {
|
||||
timeslicename[draftmetadata.time[i].begin] = draftmetadata.time[i].name;
|
||||
}
|
||||
|
||||
|
||||
var planobj = yaml.load(fs.readFileSync("plan.yaml", 'utf8'));
|
||||
//var planstr = planobj.dayplan[plan].planstr;
|
||||
|
||||
var planstr = `| 时间片 | 时长 | 用途 | 手稿 |
|
||||
| --- | --- | --- | --- |
|
||||
`;
|
||||
for (var i in planobj.dayplan[plan].time) {
|
||||
var timeslice = planobj.dayplan[plan].time[i];
|
||||
var beginhour = timeslice.beginhour;
|
||||
var beginminute = timeslice.beginminute;
|
||||
var amount = timeslice.amount;
|
||||
var endhour = beginhour + parseInt((beginminute + amount -1) / 60);
|
||||
var endminute = (beginminute + amount -1) % 60;
|
||||
|
||||
var begintime = date + beginhour.toString().padStart(2, '0') + beginminute.toString().padStart(2, '0') + "00";
|
||||
|
||||
var draftstr = "";
|
||||
if (timeslicename[begintime] != null) {
|
||||
draftstr = draftstr + timeslicename[begintime] + " ";
|
||||
}
|
||||
if (timeslice.namelink != null) {
|
||||
draftstr = draftstr + "[在线同步](" + timeslice.namelink + ")";
|
||||
}
|
||||
if (timeslice.type == "work") {
|
||||
|
||||
var draftfilename = draftrepopath + date.slice(0, 4) + "/" + date.slice(4, 6) + "/" + begintime + ".md";
|
||||
draftstr = draftstr + " [离线归档](" + draftfilename + ")";
|
||||
}
|
||||
|
||||
planstr = planstr + "| " + beginhour.toString().padStart(2, '0') + ":" + beginminute.toString().padStart(2, '0') + "~" + endhour.toString().padStart(2, '0') + ":" + endminute.toString().padStart(2, '0') + " | " + amount + " | " + timeslice.name + " | " + draftstr + " |\n";
|
||||
}
|
||||
planstr = planstr + "\n" + planobj.dayplan[plan].readme;
|
||||
//console.log("planstr:\n"+planstr);
|
||||
|
||||
var dayplan = "# " + date + "\n\n计划 \n\n根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md),今天绑定模版" + plan + "。\n\n" + planstr + "\n\n---\n\n";
|
||||
|
||||
for (var i in draftmetadata.time) {
|
||||
var subject = draftmetadata.time[i].subject;
|
||||
var taskname = draftmetadata.time[i].name;
|
||||
if (taskname === undefined) {
|
||||
taskname = "无名任务";
|
||||
}
|
||||
var output = draftmetadata.time[i].output;
|
||||
|
||||
dayplan = dayplan + "- task:" + subject + " [" + taskname + "](../" + gitpath + output + ") \n";
|
||||
|
||||
var begintime = draftmetadata.time[i].begin;
|
||||
var beginhour = parseInt((begintime - parseInt(begintime / 1000000) * 1000000) / 10000);
|
||||
var beginminute = parseInt((begintime - parseInt(begintime / 10000) * 10000) / 100);
|
||||
var amount = draftmetadata.time[i].amount;
|
||||
var endhour = beginhour + parseInt((beginminute + amount) / 60);
|
||||
var endminute = (beginminute + amount) % 60;
|
||||
//console.log(begintime,beginhour,beginminute,amount,endhour,endminute);
|
||||
var timestr = "## " + beginhour.toString().padStart(2, "0") + ":" + beginminute.toString().padStart(2, "0") + " ~ " + endhour.toString().padStart(2, "0") + ":" + endminute.toString().padStart(2, "0") + "\n\n" + taskname + "\n\n";
|
||||
|
||||
var timeviewfilename = draftrepopath + date.slice(0, 4) + "/" + date.slice(4, 6) + "/" + begintime + ".md";
|
||||
console.log("time slice draft file name:" + timeviewfilename);
|
||||
console.log(timestr);
|
||||
fs.writeFileSync(timeviewfilename, timestr);
|
||||
}
|
||||
|
||||
var dayplanfilename = "time/d." + date + ".md";
|
||||
console.log("dayplan file name:\n" + dayplanfilename + "\ncontent:\n" + dayplan);
|
||||
fs.writeFileSync(dayplanfilename, dayplan);
|
||||
}
|
||||
|
||||
function makedaylog(date) {
|
||||
var year = date.slice(0, 4);
|
||||
var month = date.slice(4, 6);
|
||||
|
||||
var draftmetafilename = draftrepopath + date.slice(0, 4) + "/" + date.slice(4, 6) + "/" + "d." + date + ".yaml";
|
||||
var draftmetadata;
|
||||
try {
|
||||
if (fs.existsSync(draftmetafilename)) {
|
||||
draftmetadata = yaml.load(fs.readFileSync(draftmetafilename, 'utf8'));
|
||||
} else {
|
||||
console.log("the log isn't exist:" + draftmetafilename);
|
||||
process.exit();
|
||||
}
|
||||
} catch (e) {
|
||||
// failure
|
||||
console.log("yaml read error!" + e);
|
||||
process.exit();
|
||||
}
|
||||
var daylog = "# " + date + "\n\n小结 \n\n<a id=\"top\"></a>\n";
|
||||
|
||||
var plan = draftmetadata.plan;
|
||||
if (plan != null) {
|
||||
var planobj = yaml.load(fs.readFileSync("plan.yaml", 'utf8'));
|
||||
//var planstr = planobj.dayplan[plan].planstr;
|
||||
|
||||
|
||||
var timeslicename = new Object();
|
||||
for (var i in draftmetadata.time) {
|
||||
timeslicename[draftmetadata.time[i].begin] = draftmetadata.time[i].name;
|
||||
}
|
||||
|
||||
var planstr = `| 时间片 | 时长 | 用途 | 手稿 |
|
||||
| --- | --- | --- | --- |
|
||||
`;
|
||||
for (var i in planobj.dayplan[plan].time) {
|
||||
var timeslice = planobj.dayplan[plan].time[i];
|
||||
var beginhour = timeslice.beginhour;
|
||||
var beginminute = timeslice.beginminute;
|
||||
var amount = timeslice.amount;
|
||||
var endhour = beginhour + parseInt((beginminute + amount -1) / 60);
|
||||
var endminute = (beginminute + amount -1) % 60;
|
||||
|
||||
var begintime = date + beginhour.toString().padStart(2, '0') + beginminute.toString().padStart(2, '0') + "00";
|
||||
|
||||
var draftstr = "";
|
||||
if ((timeslicename[begintime] != null)&(timeslice.type == "work")) {
|
||||
draftstr = draftstr + "[" + timeslicename[begintime] + "](#" + begintime + ")" ;
|
||||
|
||||
|
||||
//var draftfilename = draftrepopath + date.slice(0, 4) + "/" + date.slice(4, 6) + "/" + begintime + ".md";
|
||||
//draftstr = draftstr + " [离线归档](" + draftfilename + ")";
|
||||
}
|
||||
|
||||
planstr = planstr + "| " + beginhour.toString().padStart(2, '0') + ":" + beginminute.toString().padStart(2, '0') + "~" + endhour.toString().padStart(2, '0') + ":" + endminute.toString().padStart(2, '0') + " | " + amount + " | " + timeslice.name + " | " + draftstr + " |\n";
|
||||
}
|
||||
|
||||
planstr = planstr + "\n" + planobj.dayplan[plan].readme;
|
||||
|
||||
daylog = daylog + "根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md),今天绑定模版" + plan + "。\n\n" + planstr;
|
||||
} else {
|
||||
daylog = daylog + "当天未绑定时间模版"
|
||||
}
|
||||
var indexstr = "\n\n---\n<a id=\"index\"></a>\n";
|
||||
var logstr = "";
|
||||
for (t in draftmetadata.time) {
|
||||
var timelog = draftmetadata.time[t];
|
||||
//console.log(typeof(timelog.begin));
|
||||
var hour = timelog.begin.toString().slice(8, 10);
|
||||
var minute = timelog.begin.toString().slice(10, 12);
|
||||
var taskname = timelog.name;
|
||||
//console.log(taskname);
|
||||
if (taskname === undefined) {
|
||||
taskname = "无名任务";
|
||||
}
|
||||
|
||||
indexstr = indexstr + "- " + hour + ":" + minute + "\t[" + taskname + "](#" + timelog.begin + ") \n";
|
||||
|
||||
var outputfilename = gitpath + timelog.output;
|
||||
var outputstr = fs.readFileSync(outputfilename, 'utf8')
|
||||
logstr = logstr + "\n\n[top](#top) | [index](#index)\n<a id=\"" + timelog.begin + "\"></a>\n" + outputstr;
|
||||
}
|
||||
|
||||
var daylog = daylog + indexstr + "\n---\n" + logstr;
|
||||
//console.log(daylog);
|
||||
|
||||
var daylogfilename = "time/d." + date + ".md";
|
||||
console.log("daylog file name:\n" + daylogfilename + "\ncontent:\n" + daylog);
|
||||
fs.writeFileSync(daylogfilename, daylog);
|
||||
}
|
||||
|
||||
// utils
|
||||
function datestr(diff = 0) {
|
||||
var theDate = new Date();
|
||||
//theDate.setDate(theDate.getDate() - 1);
|
||||
theDate.setDate(theDate.getDate() + diff);
|
||||
|
||||
var year = theDate.getFullYear();
|
||||
var month = theDate.getMonth() + 1 < 10 ? "0" + (theDate.getMonth() + 1) : theDate.getMonth() + 1;
|
||||
var day = theDate.getDate() < 10 ? "0" + theDate.getDate() : theDate.getDate();
|
||||
var dateStr = year + "" + month + "" + day;
|
||||
|
||||
//console.log("datestr retrun:"+dateStr);
|
||||
return dateStr;
|
||||
}
|
|
@ -0,0 +1,44 @@
|
|||
# 2024.04.13.
|
||||
|
||||
小结
|
||||
|
||||
## 时间表
|
||||
|
||||
根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md),今天绑定模版一。
|
||||
| 时间片 | 时长 | 用途 |
|
||||
| --- | --- | --- |
|
||||
| 4:00~4:14 | 15 | 休整 |
|
||||
| 4:15~5:14 | 60 | 备餐、运动 |
|
||||
| 5:15~5:59 | 45 | 早餐 |
|
||||
| 6:00~6:44 | 45 | 会议、自习 |
|
||||
| 6:45~7:44 | 60 | 休整 |
|
||||
| 7:45~8:44 | 60 | [静默工作](http://simp.ly/p/xtgD4F) |
|
||||
| 8:45~9:29 | 45 | 休整 |
|
||||
| 9:30~10:59 | 90 | [静默工作](http://simp.ly/p/j1SspP) |
|
||||
| 11:00~13:59 | 180 | 备餐、午餐午休 |
|
||||
| 14:00~14:29 | 30 | [静默工作](http://simp.ly/p/8t3vlk) |
|
||||
| 14:30~14:59 | 30 | [静默工作](http://simp.ly/p/5k9gJy) |
|
||||
| 15:00~15:59 | 60 | 休整 |
|
||||
| 16:00~16:59 | 60 | [静默工作](http://simp.ly/p/4QDThK) [小结](#1600)|
|
||||
| 17:00~18:59 | 120 | 晚餐 |
|
||||
| 19:00~19:59 | 60 | 讨论、整理提交 |
|
||||
|
||||
|
||||
<a id="1600"></a>
|
||||
### 16:00~16:59
|
||||
|
||||
时长:60分钟
|
||||
主题:ego
|
||||
手稿:/draft/2024/04/202404131600.md
|
||||
|
||||
个人模型
|
||||
|
||||
- 手稿可以先发到simplenote,小结时整理到draft库(小结本身发布到blog库release文件夹);
|
||||
- draft库中同类内容的经验,整理到note库;
|
||||
- 公开发布内容,含要约和契约,记录在blog库release文件夹;
|
||||
- 重要的契约和共同体,整理为单独git库;
|
||||
- 小范围发布内容及其自动化,含要约和契约、含metadata和code,记录在单独git库;
|
||||
- note库、release文件夹中经验的自动化,含metadata和code,整理为单独git库;
|
||||
- raw库输出工作时间片;
|
||||
- ego库调度raw模型产生的工作时间片和各契约定义的资产,输出draft、note、专用库内容(只是个人模型的一部分);
|
||||
- Let'sX集体提炼关键能力,从draft、note到共同体整理。
|
|
@ -0,0 +1,132 @@
|
|||
# 20240414
|
||||
|
||||
小结
|
||||
|
||||
根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md),今天绑定模版2。
|
||||
|
||||
| 时间片 | 时长 | 用途 |
|
||||
| --- | --- | --- |
|
||||
| 4:00~4:14 | 15 | 休整 |
|
||||
| 4:15~5:14 | 60 | 备餐、运动 |
|
||||
| 5:15~5:59 | 45 | 早餐 |
|
||||
| 6:00~6:44 | 45 | 会议、自习 |
|
||||
| 6:45~7:44 | 60 | 休整 |
|
||||
| 7:45~10:59 | 195 | [工作](http://simp.ly/p/3GXNTh) [小结](#0745)|
|
||||
| 11:00~13:59 | 180 | 备餐、午餐午休 |
|
||||
| 14:00~15:29 | 90 | [工作](http://simp.ly/p/lsBYG9) [小结](#1400)|
|
||||
| 15:30~15:59 | 30 | 休整 |
|
||||
| 16:00~16:59 | 60 | [工作](http://simp.ly/p/MpcbHD) [小结](#1600)|
|
||||
| 17:00~18:59 | 120 | 晚餐 |
|
||||
| 19:00~19:59 | 60 | 讨论、整理提交 |
|
||||
|
||||
工作的同时可以在线讨论。
|
||||
|
||||
<a id="0745"></a>
|
||||
## 7:45~10:59
|
||||
|
||||
入门目录 @ PSMD
|
||||
|
||||
- 在符合附件30的前提下:
|
||||
-在符合附件42的前提下,解决以下问题:
|
||||
- 讨论解决附件42中问题是否需要遵守附件31、32、33、34并执行讨论结果,向外寻求解决方案时,在明确以上四项决定鸡执行记录的。
|
||||
- 在符合附件43的前提下,解决以下问题:
|
||||
- 讨论解决附件43中问题是否需要遵守附件31、32、33、34并执行讨论结果,向外寻求解决方案时,在明确以上四项决定鸡执行记录的。
|
||||
- 在不符合附件42、43的前提下,解决以下问题:
|
||||
- 守成。寻找新商机再按本目录独立设计制度。
|
||||
- 如果不符合附件30,则无法判断是否符合福建31、32、33、34,视为不遵守。
|
||||
- 在业务背景下,基于既成事实博弈。
|
||||
|
||||
### 附件30 有效的内部监管
|
||||
定义:已有基础制度和人员,能保证书面规章的违约成本高于收益。规定监管人员以外的内部成员、外部合作方不需要额外为此耗费资源。
|
||||
|
||||
### 附件31 PS标准
|
||||
|
||||
1. 规章条款的上下级关系,根据制定、修订权定义。
|
||||
1. 人员的上下级关系,根据任免权定义。
|
||||
1. 严格执行制定、修订程序。上级规章条款未生效(或被实质架空)时,不提交、不讨论下级规章条款。
|
||||
1. 严格执行任免程序。上级人员未赴任(或被实质架空)时,不提名、不讨论下级人员。
|
||||
---
|
||||
说明:
|
||||
|
||||
- 以“规章条款”为单位。比如某公司章程有一条:股东会三分之二表决权通过可以修订章程。这条本身就在章程里面,所以也能修订自己。(比如修改为:股东会四分之三表决权通过可以修订章程。)这个条款就比章程的其它条款都高一级。无论怎么组合编集,都不影响这种层级关系。
|
||||
- 比如规章写明A任免B和C,即使在其它文件使用“B是C上级”、“C接受B的指令”这类措辞,本标准下BC平级、都是A下级。A缺席时B讨论C的人选即违规(如果B是章程中有PS标准的账号,会立刻被强制注销财产充公)。
|
||||
- 无法判断时按最坏情况处理,比如因保密制度不能阅读就按未生效、未被执行看待。
|
||||
- 上级规章制定过程可以讨论规章草案下的工作场景,包括制定下级规章的场景。只有特定上级规章导致特定下级规章草案不能产生,引入讨论才有意义。一旦离开上级规章制定程序的时间、地点、人员这些条件就不能提前讨论下级规章,因为这时上级规章(下级规章制定修订程序)还没有生效,不应该暗示自己的内定角色。
|
||||
- 待实现的后续规则:不遵守则由自然人承担。比如一个共同体的上级规章被架空时讨论下级规章,则以该自然人代替共同体承担规章中的权利,比如向执行下级规章的员工发工资。(也就是从共同体剥离,并入个人领域)
|
||||
|
||||
### 附件32 保密规则
|
||||
|
||||
1. 所有人员的所有工作结果默认为公开,对外发布。
|
||||
1. 按PS标准上溯得出顶级规章,从顶级规章到保密制度之间的上下级规章链条(包括保密制度),这组规章的密级均为公开,这组规章的工作记录的密级由该规章自行规定,保密制度不得改变。
|
||||
1. 一份文档所有用途使用相同方式取得。如果因不可抗力需要改变方式,应规定不可抗力的判定程序,确保内容相同。
|
||||
1. 如果在密级规定范围内的人员都没有能力完成任务,制定保密制度相应条款的人员承担主要责任,赔偿损失。
|
||||
---
|
||||
说明:
|
||||
- 顶层权利分配规则肯定在保密制度之上,因此PSMD只讨论公开资料。
|
||||
- 如果某个审议环节从某网址取得一份资料,这份资料从产生、生效、所有使用环节都从这个网址获得。比如是指令,下达指令者应在这个网址发布指令,然后通知接受指令者去阅读。
|
||||
|
||||
### 附件33 制定规则
|
||||
|
||||
1. 制定规章要明确预期效果。
|
||||
1. 接到质询时必须提供依据,依据必须是 外部法律 or 案例统计 两种方式之一。
|
||||
1. 如果是旧版本修订,制定者可以提出适用范围。只能向该适用范围内使用旧版规章的共同体发送修订通知。
|
||||
1. 分支隔离规则适用于制定规章。一个分支的共同体内制定规章时,所提供依据如果使用其它分支的案例,将自动增加切换规章的动议作为前提。
|
||||
---
|
||||
说明:
|
||||
- 比如不采用 PS标准的共同体,制定规章时以采用PS标准分支下的案例为依据,则自动增加采用PS标准的动议,切换生效之后才能讨论所制定规章。
|
||||
|
||||
### 附件34 分支隔离规则
|
||||
|
||||
1. 对相同事项的不同处理方法,视为同一规章的不同分支版本。对该事项未做任何规定,也视为其中一个分支版本。
|
||||
1. 实际通过生效、使用某分支版本的规章,即为支持该分支版本,反对其它分支版本。
|
||||
1. 规章使用过程遇到问题可以提出修订委托,如发往反对者将自动转为帮助切换规章的委托(切换到对方实际使用的分支版本)。如果是付费委托,受托者只需回答实际收到的问题。
|
||||
1. 查询资料时,未做任何规定分支可以列出所有分支的资料,其它分支只列出本分支的资料。
|
||||
|
||||
说明:
|
||||
- 例如:共同体A采用PS标准,共同体B、C没有。当B在上级规章未生效时要讨论下级规章。B向C提出咨询,C收到B发出的原始咨询内容。B向A提出咨询,咨询内容自动转化为“如何在规章中增加PS标准”,A无法收到B发出的原始咨询内容。这条规则主要提醒自我安慰性的求助,向反对者求助就是承认自身行为导致问题无解。
|
||||
- 在父项目,各隔离分支将使用不同记账单位。相同金额不同单位,视为同工同酬。比如采用PS标准的分支使用M为单位,不采用PS标准分支使用N为单位,自由兑换的平衡点是1M兑换10N。一项工作的报酬是5,两个分支账号分别得到5M(可兑换50N)、5N的报酬。
|
||||
|
||||
### 附件42 资源不足
|
||||
定义:需要以未来的收入换取资源,而且需要与同行争夺。
|
||||
反向的情况,是创始时能一次筹集到足够的资源,可见未来的收入和积累都超过支出。或者需要以未来的收入换取资源,但是不需要竞争即可获得充足资源。
|
||||
|
||||
### 附件 43 能力和贡献持续变化
|
||||
定义:核心人员凭借职权高估自己的贡献、低估非核心成员的贡献,这样做的综合效果更符合他们的利益。
|
||||
反向的情况,核心人员准确估算包括自己在内的成员贡献,这样做的综合效果更符合他们的利益。
|
||||
|
||||
|
||||
<a id="1400"></a>
|
||||
## 14:00~15:29
|
||||
|
||||
ego
|
||||
|
||||
自动生成以下日志文件:
|
||||
D:\huangyg\git\blog\release\time\d.20240413.md
|
||||
|
||||
一旦创建就不再维护md文件,也不回头修改yaml文件。
|
||||
ego项目提供meta data,
|
||||
draft项目提供当天的yaml和素材文件。
|
||||
产生当天日志:只是简单介绍当太难时间分配和公开的手稿。ego的资源调度依赖以后的事件,因此只提供入口和参数,暂时不把内容写入日志。
|
||||
|
||||
输出:
|
||||
blog\release\plan.yaml 时间模版元数据
|
||||
blog\release\time.js 自动生成日计划
|
||||
|
||||
下一步是:
|
||||
1. 根据waketime自动生成时间表,而不是固定始末时间。
|
||||
- 参考:https://github.com/hyg/gathering/blob/gh-pages/2021/Q2/schadule.jsonld
|
||||
- 参考:https://github.com/hyg/gathering/blob/gh-pages/2021/Q2/index.html
|
||||
1. 创建日志文件。
|
||||
|
||||
<a id="1600"></a>
|
||||
## 16:00~16:59
|
||||
|
||||
PSMD
|
||||
|
||||
修订早上7点的工作结果。
|
||||
加入PSMD新版的规则。
|
||||
|
||||
下一步的工作:
|
||||
1. 调整PSMD新版基础规则的表述。
|
||||
1. 设计自动工具。
|
||||
|
|
@ -0,0 +1,188 @@
|
|||
# 20240415
|
||||
|
||||
小结
|
||||
|
||||
根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md),今天绑定模版1。
|
||||
|
||||
| 时间片 | 时长 | 用途 |
|
||||
| --- | --- | --- |
|
||||
| 4:00~4:14 | 15 | 休整 |
|
||||
| 4:15~5:14 | 60 | 备餐、运动 |
|
||||
| 5:15~5:59 | 45 | 早餐 |
|
||||
| 6:00~6:44 | 45 | 会议、自习 |
|
||||
| 6:45~7:44 | 60 | 休整 |
|
||||
| 7:45~8:44 | 60 | [静默工作](http://simp.ly/p/xtgD4F) [小结](#0745) |
|
||||
| 8:45~9:29 | 45 | 休整 |
|
||||
| 9:30~10:59 | 90 | [静默工作](http://simp.ly/p/j1SspP) [小结](#0900) |
|
||||
| 11:00~13:59 | 180 | 备餐、午餐午休 |
|
||||
| 14:00~14:29 | 30 | [静默工作](http://simp.ly/p/8t3vlk) [小结](#1400) |
|
||||
| 14:30~14:59 | 30 | [静默工作](http://simp.ly/p/5k9gJy) [小结](#1430) |
|
||||
| 15:00~15:59 | 60 | 休整 |
|
||||
| 16:00~16:59 | 60 | [静默工作](http://simp.ly/p/4QDThK) [小结](#1600) |
|
||||
| 17:00~18:59 | 120 | 晚餐 |
|
||||
| 19:00~19:59 | 60 | 讨论、整理提交 |
|
||||
|
||||
模版一采用静默工作方式。
|
||||
希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com),通常安排在后面某天的某天的早餐(5:15~5:59)或会议时间(6:00~6:45)。
|
||||
|
||||
<a id="0745"></a>
|
||||
## 7:45~8:44
|
||||
|
||||
整理任务看板
|
||||
|
||||
1. meeting:
|
||||
- 异步议事的协作规范
|
||||
- 三页面设计细化
|
||||
- 熟悉软件测试,工具
|
||||
- m90*2,编程。
|
||||
1. PSMD:
|
||||
- PPT,blog
|
||||
- README工作计划预算
|
||||
- m60、m90,README工作计划预算
|
||||
- 1406、1609向成长模式下的原始模型植入
|
||||
- PPT blog
|
||||
- m45、m45、m60,PPT blog
|
||||
- README PLAN BUDGET
|
||||
1. infra:
|
||||
- 用管道代替水池,pipe->pool,不用存款,用契约。
|
||||
- 信任网络中加入ipfs的swap类似机制,也许已有->结合。
|
||||
- 金融服务:
|
||||
- 可能性
|
||||
- 不变的API
|
||||
- PSMD、infra使用的几种“层次”,向ego融合。
|
||||
- ICO创业大军会死在哪里?
|
||||
- 自动账户读写数据,以太坊读写隔离
|
||||
- 熟悉EOS白皮书
|
||||
- v0.2设计
|
||||
- v0.2 coding,yaml+turtle,出demo【https://github.com/iopipe/turtle/issues 很久没动静了,理念可以参考。】
|
||||
1. ITW:
|
||||
- 弱化线下招生,强化线上招生,鼓励生源互换,考虑信任网络。
|
||||
- 适合在家,持续对抗,维护身份认同的机制。
|
||||
1. let‘X
|
||||
- 把knowledge归入letcongnize 【并没有创建knowledge git库,确实需要定义知识的互相关系,偏差-解决方案 作为元数据,各库之间互相推介,是可选方案。需要定义这套方案的提出和修订。】
|
||||
1. XUEMEN:
|
||||
- IST机制,与JT互通、浮动。
|
||||
- 理顺AER自动生成规则。
|
||||
|
||||
二季度规划(4.15起,按45天):
|
||||
- 30天绑定模版1:m90*30,m60*60,m30*60
|
||||
- 5天绑定模版2:m195*5,m90*5,m60*5
|
||||
- 10天绑定模版3:
|
||||
- PSMD:m195*5,m90*5,m60*5
|
||||
- TBD:m195*5,m90*5,m60*5
|
||||
- 外勤、缺勤在6月补回。
|
||||
|
||||
EGO:m30*6,m60*20,m90*13,m195*1
|
||||
- 日计划、小结自动生成:
|
||||
- 手工操作:m30*3,m60*1
|
||||
- 代码:m60*6,m90*5,m195*1
|
||||
- 季度规划、小结自动生成:
|
||||
- 手工操作:m30*2,m60*2
|
||||
- 代码:m60*4,m90*4
|
||||
- 时间片*任务匹配
|
||||
- 手工操作:m30*1,m60*1
|
||||
- 代码:m60*6,m90*4
|
||||
|
||||
PSMD:m30*7,m60*37,m90*20,m195*4,模版3*2
|
||||
- 入门目录:
|
||||
- 手工:m30*2,m60*4,m90*1
|
||||
- 代码:m60*4,m90*4
|
||||
- 带有升级、追溯功能的draft->blog\release机制。每个版本的要约、合同章节在draft中的日yaml中定义,自动整理后生成索引,内容以哈希命名、统一发布。引用处定义是某版本、最新版本(可多选),最新版本的可以自动产生正确的链接。旧版本详情有新版本入口。
|
||||
- default
|
||||
- 手工:m30*1,m60*2,m90*1
|
||||
- 代码:m60*4,m90*4,m195*1
|
||||
- 1406
|
||||
- 手工:m30*2,m60*3,m90*1
|
||||
- 代码:m60*8,m90*4,m195*1,模版3*1
|
||||
- 1609
|
||||
- 手工:m30*2,m60*4,m90*1
|
||||
- 代码:m60*8,m90*4,m195*2,模版3*1
|
||||
|
||||
XUEMEN:m30*40(47),m60*6(8),m90*2(2)
|
||||
|
||||
<a id="0930"></a>
|
||||
## 9:30~10:59
|
||||
|
||||
PSMD 入门目录
|
||||
|
||||
针对不同条件给出建议如下:
|
||||
- 如果不能按照附件20增加补充信息,建议在业务背景下,基于既成事实博弈。具体可以参考default标准模型。还在筹备因此无法补充信息的,可以参考booting标准模型。
|
||||
- 如果可以,请根据附件20增加关于附件30的补充信息。
|
||||
- 如果判断符合附件30的情况,请根据附件20增加关于附件42、43的补充信息。
|
||||
- 如果判断符合附件42、43之一的情况,请根据附件20增加关于附件31、32、33、34的补充信息。
|
||||
- 如果判断符合附件31、32、33、34的情况,建议:使用自定义的规章解决资源和重构问题,具体可以参考1609、chain等标准模型。
|
||||
- 如果判断不符合31、32、33、34的情况,建议:先参考default+1406标准模型开展业务,逐步完善规章,取得进步后重新增加关于附件31、32、33、34的补充信息。
|
||||
- 如果判断附件42、43都不符合的情况,建议:先参考default+1406标准模型开展业务。情况变化或出现新商机再增加补充信息。
|
||||
- 如果判断不符合附件30的情况,即使按照附件20增加补充信息也无法判断附件30~34的情况,因此建议:在业务背景下,基于既成事实博弈。具体可以参考default标准模型。
|
||||
|
||||
附件20 符合某条件
|
||||
对自述难以核实的情况下,可以按照以下方式之一增加补充信息:
|
||||
1. 涉事各方全体同意,推举一名或多名保证人:
|
||||
- 保证人在其它事项中符合该条件,并按照本附件提供补充信息。
|
||||
- 由保证人调查涉事各方是否符合该条件,将调查记录作为补充信息。
|
||||
1. 涉事各方分别自述,交叉核实。将所有记录合并作为补充信息。
|
||||
1. 涉事各方签署 附件21 容器规则,承诺遵守该条件,将生效、执行的记录作为补充信息。
|
||||
|
||||
其他方根据补充信息作出判断后,进入后续讨论。
|
||||
|
||||
附件21 容器规则
|
||||
1. 自然人可以公示一组规则(以下称为“章程”),并注入启动资金创建有限责任的虚拟主体(以下称为“账号”)。
|
||||
1. 每个账号有独立的财产。由章程自行规定管理细则。
|
||||
1. 每个账号可以独立对外签订合同。合同应明确规定仅以该账号财产承担责任。
|
||||
1. 所有合同应该针对章程约定合规仲裁的方式。一旦违反章程则强制注销该账号,以最后的合规行为时间为注销时间,由当时有效合同的其他方组织清算,默认一份契约一票。
|
||||
1. 账号财产可以跨账号调用,但转出账号的余额不得少于该账号签订的所有合同的待付款项(包括极限情况下的赔偿)总和。具体金额以对应收款方的理解为准。
|
||||
1. 账号签订的所有合同结束、且合同中所有赔偿责任结束后,自然人可以注销该账号。
|
||||
1. 章程条款适用分支隔离规则 。
|
||||
|
||||
<a id="1400"></a>
|
||||
## 14:00~14:29
|
||||
|
||||
国密simple
|
||||
|
||||
测试了sm2的创建密钥、压缩公钥、验证密钥。
|
||||
输出:js.simple/sm.crypt/local.2.html
|
||||
|
||||
<a id="1430"></a>
|
||||
## 14:30~14:59
|
||||
|
||||
ego entry页面
|
||||
|
||||
- github访问不方便
|
||||
- gitee实名认证比较麻烦
|
||||
- codeberg访问正常,page服务也比较方便:
|
||||
- 不需要创建专门branch也可以
|
||||
|
||||
入口地址
|
||||
https://hyg.codeberg.page/blog/@master/release/entry.html
|
||||
http://z6b.cn/Hix8d
|
||||
https://t.cn/A6TWZQJ0
|
||||
|
||||
下一步:在页面中显示markdown内容,以便组合多个md文件和yaml文件的内容。
|
||||
|
||||
<a id="1600"></a>
|
||||
## 16:00~16:59
|
||||
|
||||
PSMD 自动入门目录
|
||||
|
||||
针对某问题的入口:在今天上午的[手工范例](202404150930.md)中,如果对方针对附件42的问题提问,应自动生成以下回复:
|
||||
|
||||
针对不同条件给出建议如下:
|
||||
1. 使用自定义的规章解决资源和重构问题,具体可以参考1609、chain等标准模型。
|
||||
- 同意按照附件20增加补充信息,补充关于附件30,42,31、32、33、34的补充信息,且均判断为符合。
|
||||
1. 先参考default+1406标准模型开展业务,逐步完善规章,取得进步后重新增加关于附件31、32、33、34的补充信息。
|
||||
- 同意按照附件20增加补充信息,补充关于附件30,42,31、32、33、34的补充信息,且判断符合附件30、42,不全符合符合31、32、33、34。
|
||||
1. 在业务背景下,基于既成事实博弈。具体可以参考default标准模型。
|
||||
- 不能按照附件20增加补充信息。
|
||||
- 同意按照附件20增加补充信息,补充关于附件30的补充信息,且判断为不符合。
|
||||
1. 参考booting标准模型。
|
||||
- 还在筹备因此无法补充信息的。
|
||||
|
||||
如果有其它可行方案请发到<huangyg@mars22.com>,我将按照附件21核实。
|
||||
|
||||
附件21 实施效果的核实
|
||||
|
||||
1. 公布完整、连续、不可删改的执行记录,证实方案的效果。
|
||||
- 如果以前的执行记录不符合以上条件,可以在愿意按标准公布记录的独立第三方验证。
|
||||
1. 已发布开放的要约,只有取得该效果才有收益。
|
||||
|
||||
在 js.simple/schame 下创建 demo.yaml demo.js 设计数据结构并完成解析。
|
|
@ -0,0 +1,459 @@
|
|||
# 20240416
|
||||
|
||||
小结
|
||||
<a id="top"></a>
|
||||
根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md),今天绑定模版1。
|
||||
|
||||
| 时间片 | 时长 | 用途 |
|
||||
| --- | --- | --- |
|
||||
| 4:00~4:14 | 15 | 休整 |
|
||||
| 4:15~5:14 | 60 | 备餐、运动 |
|
||||
| 5:15~5:59 | 45 | 早餐 |
|
||||
| 6:00~6:44 | 45 | 会议、自习 |
|
||||
| 6:45~7:44 | 60 | 休整 |
|
||||
| 7:45~8:44 | 60 | [静默工作](http://simp.ly/p/xtgD4F) |
|
||||
| 8:45~9:29 | 45 | 休整 |
|
||||
| 9:30~10:59 | 90 | [静默工作](http://simp.ly/p/j1SspP) |
|
||||
| 11:00~13:59 | 180 | 备餐、午餐午休 |
|
||||
| 14:00~14:29 | 30 | [静默工作](http://simp.ly/p/8t3vlk) |
|
||||
| 14:30~14:59 | 30 | [静默工作](http://simp.ly/p/5k9gJy) |
|
||||
| 15:00~15:59 | 60 | 休整 |
|
||||
| 16:00~16:59 | 60 | [静默工作](http://simp.ly/p/4QDThK) |
|
||||
| 17:00~18:59 | 120 | 晚餐 |
|
||||
| 19:00~19:59 | 60 | 讨论、整理提交 |
|
||||
|
||||
模版一采用静默工作方式。
|
||||
希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com),通常安排在后面某天的早餐(5:15~5:59)或会议时间(6:00~6:45)。
|
||||
|
||||
---
|
||||
<a id="index"></a>
|
||||
- 07:45 [ego 任务管理的手写范例,metadata数据结构设计](#20240416074500)
|
||||
- 09:30 [PSMD 条款设计流程及手写范例,metadata to view 代码](#20240416093000)
|
||||
- 14:00 [draft自动生成日小结](#20240416140000)
|
||||
- 14:30 [ego entry页面显示markdown](#20240416143000)
|
||||
- 16:00 [ego draft to metadata 代码](#20240416160000)
|
||||
|
||||
---
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240416074500"></a>
|
||||
## 7:45~8:44
|
||||
|
||||
ego 任务管理
|
||||
|
||||
### 流程
|
||||
|
||||
1. 手写draft的时间片md文件,以文字记载task metadata的变更提要。
|
||||
1. 手写更新task metadata文件,一级项目在ego,二级以下在一级项目内分配。
|
||||
1. 自动统计、生成图表,辅助后续分配,手工或自动调整metadata。
|
||||
1. 自动合并成当前的全局metadata文件。
|
||||
1. 自动根据全局metadata文件产生:
|
||||
- 各项目简介markdown、html文件;
|
||||
- GTD工具的可选菜单。
|
||||
|
||||
### 架构设计
|
||||
|
||||
1. 对外显示各项目简介markdown、html文件,并不断更新,它们的结构和内容是相对稳定的。
|
||||
1. 内部流程和文件是不断升级变化的:
|
||||
- 文件:draft md→task metadata→全局metadata、ego资源分配metadata
|
||||
- 代码:
|
||||
- task metadata → ego资源分配metadata
|
||||
- task metadata → 统计图表
|
||||
- task metadata → 全局metadata
|
||||
- 全局metadata → 各项目简介markdown、html文件、GTD工具的可选菜单
|
||||
|
||||
|
||||
### metadata数据结构
|
||||
|
||||
- task metadata
|
||||
~~~
|
||||
name:
|
||||
id:
|
||||
parent id:
|
||||
start:
|
||||
end:
|
||||
dependencies:
|
||||
- id:
|
||||
- id:
|
||||
path:
|
||||
- name:
|
||||
path:
|
||||
readme: |
|
||||
readme: |
|
||||
step:
|
||||
- time:
|
||||
name:
|
||||
status:
|
||||
readme: |
|
||||
log:
|
||||
- time:
|
||||
text: |
|
||||
~~~
|
||||
|
||||
- 全局metadata
|
||||
~~~
|
||||
time:
|
||||
task:
|
||||
id:
|
||||
name:
|
||||
id:
|
||||
...
|
||||
subtask:
|
||||
- name:
|
||||
id:
|
||||
~~~
|
||||
|
||||
### metadata范例
|
||||
|
||||
1. 在ego的git库中创建task文件夹。
|
||||
1. 创建几个task metadata文件。
|
||||
1. 创建task.js,从task metadata生成全局metadata。
|
||||
|
||||
下一步:追溯到一级任务的path文件夹。
|
||||
参考:
|
||||
- https://github.com/frappe/gantt 的甘特图json数据结构
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240416093000"></a>
|
||||
## 9:30~10:59
|
||||
|
||||
PSMD条款库
|
||||
|
||||
### 流程及架构设计
|
||||
|
||||
1. 根据实践和讨论,编写偏差error metadata和条款设计修订tansk metada,由代码生成error markdown、html文件、allerror metadata文件。
|
||||
1. 在ego项目下,根据task统计界面分配时间到具体子任务。
|
||||
1. 在PSMD的设计、修订条款子任务中,通过PSMD项目的统计界面了解相关信息,然后撰写手稿存放在draft库中,并在当天的draft metadata文件中记录手稿的任务归属。
|
||||
1. 在条款设计完成时,手工编写PSMD项目的term metadata。由代码自动生成条款的markdown、html文件。
|
||||
1. 在使用时,手工编写条款集合termset的metadata,由代码生成termset的markdown、html文件。
|
||||
1. 建模时,手工编写共同体模型的COM metadata文件,由代码生成markdown、html文件。
|
||||
1. 部署时手工编写输入条件的deploy metadata文件(列明人员、资源等条件),由代码生成deploy markdown、html文件,以及全部表决通过后的COD metadata。
|
||||
1. 紧急部署时,手工编写部署方案的COD metadata文件。
|
||||
1. 由代码根据COD metadata生成markdown、html。
|
||||
1. term的placeholder有entity、asset、term三类(以后可以扩充),termset、COM解决term之间的关联关系,deploy解决entity、asset的关联关系。
|
||||
|
||||
- 内部可见:
|
||||
- error metadata
|
||||
- allerror metadata
|
||||
- draft手稿
|
||||
- draft metadata
|
||||
- error metadata
|
||||
- term metadata
|
||||
- termset metadata
|
||||
- allterm metadata
|
||||
- COM metadata
|
||||
- deploy metadata
|
||||
- COD metadata
|
||||
- 对外可见:
|
||||
- error markdown、html
|
||||
- term markdown、html
|
||||
- termset markdown、html
|
||||
- COM markdown、html
|
||||
- deploy markdown、html
|
||||
- COD markdown、html
|
||||
|
||||
### 数据结构
|
||||
|
||||
- error metadata
|
||||
~~~
|
||||
name:
|
||||
id:
|
||||
text:
|
||||
bind:
|
||||
- type: term、termset、COD
|
||||
- id:
|
||||
log: |
|
||||
~~~
|
||||
- allerror metadata
|
||||
~~~
|
||||
time:
|
||||
error:
|
||||
errorid:
|
||||
//error metadata文件全部内容
|
||||
effect: //解决方案,对应term、termset、COM的effect字段
|
||||
- type: term、termset、COM
|
||||
- id:
|
||||
errorid:
|
||||
~~~
|
||||
- draft metadata
|
||||
~~~
|
||||
date: 20240415
|
||||
time:
|
||||
- begin: 20240415074500
|
||||
amount: 60
|
||||
unit: minute
|
||||
type: work
|
||||
subject: ego
|
||||
subjecttype: task、error、term、termset、COM、COD
|
||||
output: draft/2024/04/2024041140745.md
|
||||
~~~
|
||||
- term metadata
|
||||
~~~
|
||||
name:
|
||||
id:
|
||||
interface:
|
||||
entity:
|
||||
- name:
|
||||
id:
|
||||
readme: |
|
||||
- name:
|
||||
id:
|
||||
readme: |
|
||||
asset:
|
||||
- name:
|
||||
id:
|
||||
readme: |
|
||||
term: // 引用其它条款,在termset、COM中根据联合使用情况绑定。
|
||||
- name:
|
||||
id:
|
||||
readme: |
|
||||
event:
|
||||
- name:
|
||||
id:
|
||||
readme: |
|
||||
text:
|
||||
readme:
|
||||
effect:
|
||||
error hashid:
|
||||
error hashid:
|
||||
log: |
|
||||
~~~
|
||||
- termset metadata
|
||||
~~~
|
||||
name:
|
||||
id:
|
||||
level:
|
||||
interface:
|
||||
entity:
|
||||
- name:
|
||||
id:
|
||||
globalid: \\ termsetid\...\termid\entityid
|
||||
readme: |
|
||||
- name:
|
||||
id:
|
||||
globalid: \\ termsetid\...\termid\entityid
|
||||
readme: |
|
||||
asset:
|
||||
- name:
|
||||
id:
|
||||
globalid: \\ termsetid\...\termid\assetid
|
||||
readme: |
|
||||
term: // 引用其它条款,在termset、COM中根据联合使用情况绑定。
|
||||
- name:
|
||||
id:
|
||||
globalid: \\ termsetid\...\termid\termid
|
||||
readme: |
|
||||
event:
|
||||
- name:
|
||||
id:
|
||||
globalid:
|
||||
readme: |
|
||||
item:
|
||||
- type: term\termset
|
||||
id:
|
||||
globalid: \\ termsetid\...\termid\
|
||||
text:
|
||||
upgrade: \\ 修订程序的globalid
|
||||
path:
|
||||
item:
|
||||
- id:
|
||||
globalid: \\ termsetid\...\termid\
|
||||
text:
|
||||
upgrade: \\ 修订程序的globalid
|
||||
- id:
|
||||
readme: |
|
||||
log: |
|
||||
effect:
|
||||
error hashid:
|
||||
error hashid:
|
||||
~~~
|
||||
- allterm metadata
|
||||
~~~
|
||||
time:
|
||||
term:
|
||||
hash:
|
||||
//term metadata全部内容
|
||||
error: //对应error metadata的bind字段
|
||||
-id:
|
||||
-id:
|
||||
termset:
|
||||
hash:
|
||||
//termset metadata全部内容
|
||||
error: //对应error metadata的bind字段
|
||||
-id:
|
||||
-id:
|
||||
~~~
|
||||
- COM metadata
|
||||
~~~
|
||||
name:
|
||||
id:
|
||||
level:
|
||||
interface:
|
||||
entity:
|
||||
- name:
|
||||
id:
|
||||
globalid: \\ termsetid\...\termid\entityid
|
||||
readme: |
|
||||
- name:
|
||||
id:
|
||||
globalid: \\ termsetid\...\termid\entityid
|
||||
readme: |
|
||||
asset:
|
||||
- name:
|
||||
id:
|
||||
globalid: \\ termsetid\...\termid\assetid
|
||||
readme: |
|
||||
term: // 引用其它条款,COM主要是引用外部法规,比如公司法。
|
||||
- name:
|
||||
id:
|
||||
globalid: \\ termsetid\...\termid\termid
|
||||
readme: |
|
||||
event:
|
||||
- name:
|
||||
id:
|
||||
globalid:
|
||||
readme: |
|
||||
item: \\ 似乎可以直接用一个termset
|
||||
- type: term\termset
|
||||
id:
|
||||
upgrade:
|
||||
readme: |
|
||||
log: |
|
||||
effect:
|
||||
error hashid:
|
||||
error hashid:
|
||||
~~~
|
||||
- deploy metadata
|
||||
~~~
|
||||
name:
|
||||
id:
|
||||
source:
|
||||
type: termset\COM
|
||||
id: termsetid or COM id
|
||||
interface:
|
||||
entity:
|
||||
- name:
|
||||
id:
|
||||
globalid: \\ termsetid\...\termid\entityid
|
||||
readme: |
|
||||
- name:
|
||||
id:
|
||||
globalid: \\ termsetid\...\termid\entityid
|
||||
readme: |
|
||||
asset:
|
||||
- name:
|
||||
id:
|
||||
globalid: \\ termsetid\...\termid\assetid
|
||||
readme: |
|
||||
term: // 引用其它条款,COM主要是引用外部法规,比如公司法。
|
||||
- name:
|
||||
id:
|
||||
globalid: \\ termsetid\...\termid\termid
|
||||
readme: |
|
||||
event:
|
||||
- name:
|
||||
id:
|
||||
globalid:
|
||||
readme: |
|
||||
~~~
|
||||
- COD metadata
|
||||
~~~
|
||||
name:
|
||||
id:
|
||||
COMid:
|
||||
interface:
|
||||
entity:
|
||||
- name:
|
||||
id:
|
||||
globalid: \\ termsetid\...\termid\entityid
|
||||
readme: |
|
||||
- name:
|
||||
id:
|
||||
globalid: \\ termsetid\...\termid\entityid
|
||||
readme: |
|
||||
asset:
|
||||
- name:
|
||||
id:
|
||||
globalid: \\ termsetid\...\termid\assetid
|
||||
readme: |
|
||||
term: // 引用其它条款,COM主要是引用外部法规,比如公司法。
|
||||
- name:
|
||||
id:
|
||||
globalid: \\ termsetid\...\termid\termid
|
||||
readme: |
|
||||
event:
|
||||
- name:
|
||||
id:
|
||||
globalid:
|
||||
readme: |
|
||||
readme: |
|
||||
log: |
|
||||
~~~
|
||||
|
||||
### 自动化代码
|
||||
|
||||
- error metadata → error markdown、html、task metadata
|
||||
- draft metadata → 更新task metadata的time、log字段 (→ alltask metadata),更新
|
||||
- term metadata → allterm metadata
|
||||
- allterm metadata → 条款的markdown、html文件,要约、合同
|
||||
- COM metadata → COM markdown、COM html
|
||||
- deploy metadata → deploy markdown、deploy html、全部通过后的COD metdadata
|
||||
- COD metadata → COD markdown、COD html
|
||||
|
||||
下一步的工作:
|
||||
- 根据COM的讨论和COD的执行,产生修订error、term、termset的task metadata,在ego或COD分配资源时使用,从而形成闭环。
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240416140000"></a>
|
||||
## 14:00~14:29
|
||||
|
||||
draft自动生成日小结
|
||||
|
||||
- 在draft数据结构中增加了name字段。
|
||||
- 内容末尾的回车都是紧贴内容,不带空行。是否隔行由后续内容开头决定。
|
||||
- 路径的左端不带斜杠,右端带。
|
||||
- 增加了目录。
|
||||
- 增加了top、index标签。
|
||||
|
||||
输出:D:\huangyg\git\blog\release\time.js
|
||||
- makedaylog(date)
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240416143000"></a>
|
||||
## 14:30~14:59
|
||||
|
||||
ego entry页面显示markdown
|
||||
|
||||
- 使用 https://marked.js.org/ 解析markdown内容
|
||||
- 网页无法跨域获得日志内容。
|
||||
- 普通http get无效,返回status=0.
|
||||
- jsonP无效,返回status=0.
|
||||
- iframe无效,gitee和codeberg都拒绝iframe
|
||||
- 网页使用ifram读取codeberg page同域名下的日志文件,被自动下载。
|
||||
|
||||
下一步:试试修改iframe属性,获得内容后试试onload()中解析markdown内容。
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240416160000"></a>
|
||||
## 16:00~16:59
|
||||
|
||||
ego draft to metadata 代码
|
||||
|
||||
~~~
|
||||
node task : task metadata to alltask metadata
|
||||
node task 2024 : draft to year stat
|
||||
node task 20240416 : draft to task metadata
|
||||
node task 1 : diff date draft to task metadata
|
||||
node task 20240101 20240401 : period draft to stat
|
||||
~~~
|
||||
|
||||
输出:D:\huangyg\git\ego\task\task.js
|
||||
- 参数分流
|
||||
- draft to task metadata:function drafttotask(date)
|
||||
|
||||
下一步:debug
|
||||
出现空文件或内容缺实、跳断的情况。
|
||||
已确认写入的内容是正确的,初步判断是读文件和写文件之间的同步问题。
|
|
@ -0,0 +1,123 @@
|
|||
# 20240417
|
||||
|
||||
小结
|
||||
<a id="top"></a>
|
||||
根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md),今天绑定模版2。
|
||||
|
||||
| 时间片 | 时长 | 用途 |
|
||||
| --- | --- | --- |
|
||||
| 4:00~4:14 | 15 | 休整 |
|
||||
| 4:15~5:14 | 60 | 备餐、运动 |
|
||||
| 5:15~5:59 | 45 | 早餐 |
|
||||
| 6:00~6:44 | 45 | 会议、自习 |
|
||||
| 6:45~7:44 | 60 | 休整 |
|
||||
| 7:45~10:59 | 195 | [工作](http://simp.ly/p/3GXNTh) |
|
||||
| 11:00~13:59 | 180 | 备餐、午餐午休 |
|
||||
| 14:00~15:29 | 90 | [工作](http://simp.ly/p/lsBYG9) |
|
||||
| 15:30~15:59 | 30 | 休整 |
|
||||
| 16:00~16:59 | 60 | [工作](http://simp.ly/p/MpcbHD) |
|
||||
| 17:00~18:59 | 120 | 晚餐 |
|
||||
| 19:00~19:59 | 60 | 讨论、整理提交 |
|
||||
|
||||
工作的同时可以在线讨论。
|
||||
|
||||
---
|
||||
<a id="index"></a>
|
||||
- 07:45 [PSMD 条款库的数据结构](#20240417074500)
|
||||
- 14:00 [PSMD 条款库的代码](#20240417140000)
|
||||
- 16:00 [ego 任务统计代码](#20240417160000)
|
||||
|
||||
---
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240417074500"></a>
|
||||
## 7:45~10:59
|
||||
|
||||
PSMD 条款库的数据结构
|
||||
|
||||
根据[昨天](https://codeberg.org/hyg/blog/src/branch/master/release/time/d.20240416.md#20240416093000)设计的数据结构,开始编程。
|
||||
|
||||
- 由于metadata文件的读写同步问题,log字段取消,由代码自动写入markdown和html文件。
|
||||
- 仔细对比COM markdown使用allx还是COM的metadata。决定allx主要起到index索引作用,内部使用(git库开放)。COM metadata、markdown和html对外部使用。数据结构细节需要针对性微调。
|
||||
- deploy针对从COM启动的需求,COD针对部署过程、部分决议已经通过的情形,数据结构需要针对性微调。
|
||||
|
||||
输出:
|
||||
1. 数据结构在PSMD\data\readme.md
|
||||
1. 初步设计:
|
||||
|
||||
### PSMD\src\term.js
|
||||
|
||||
node term all : term metada + termset metadata → allterm metadata
|
||||
node term term id : term metadata → term markdown + html
|
||||
node term termset id : termset metadata → termset markdown + html
|
||||
|
||||
### PSMD\src\model.js
|
||||
|
||||
node model id : COM metadata → COM markdown + html
|
||||
|
||||
### PSMD\src\deploy.js
|
||||
|
||||
node deploy id :deploy metadata → deploy markdown、deploy html、全部通过后的COD metdadata
|
||||
node deploy
|
||||
|
||||
下一步:
|
||||
- 手写metadate
|
||||
- 实现代码:
|
||||
- term metadata + termset metadata → allterm metadata
|
||||
- allterm metadata → 条款的markdown、html文件,要约、合同
|
||||
- COM metadata → COM markdown、COM html
|
||||
- deploy metadata → deploy markdown、deploy html、全部通过后的COD metdadata
|
||||
- COD metadata → COD markdown、COD html
|
||||
- COD record → 修订error、term、termset的task metadata
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240417140000"></a>
|
||||
## 14:00~15:29
|
||||
|
||||
PSMD 条款库的代码
|
||||
|
||||
手工编辑了三个term metadata:
|
||||
- 主分配比例p:设置初始值,在termset中明确修订权。
|
||||
- 自修订条款
|
||||
- 二级修订条款1
|
||||
|
||||
一个termset metadata:自修订条款修订其它两个条款。
|
||||
|
||||
创建/PSMD/src/term.js
|
||||
完成: term metadata + termsetmetadata → allterm metadata
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240417160000"></a>
|
||||
## 16:00~16:59
|
||||
|
||||
ego 任务模版
|
||||
|
||||
调整:
|
||||
- 资源分配、统计,放在time.js
|
||||
~~~
|
||||
node time: today's draft metadata + draft markdown → day log markdown + task markdown's log
|
||||
node time 1: diff day's draft metadata + draft markdown → day log markdown + task markdown's log
|
||||
node time 20240417: 20240417's draft metadata + draft markdown → day log markdown + task markdown's log
|
||||
node time init 1: plan 1 metadata → today draft metadata
|
||||
node time init: draft metadata + plan metadata → today plan markdown
|
||||
~~~
|
||||
- 任务管理放在task.js
|
||||
~~~
|
||||
node task : today draft to stat
|
||||
node task all : task metadata to alltask metadata
|
||||
node task 2024 : draft to year stat
|
||||
node task 20240416 : draft to day stat
|
||||
node task 1 : diff date draft to stat
|
||||
node task 20240101 20240401 : period draft to stat
|
||||
~~~
|
||||
|
||||
1. 设计了plan.yaml中的time字段,为后续代码提供时间段元数据。
|
||||
1. 实现了:
|
||||
- node time init 1: plan 1 metadata → draft metadata
|
||||
- node time init: draft metadata + plan metadata → day plan markdown
|
||||
|
||||
下一步:
|
||||
- 根据起床时间制定浮动时间表。
|
||||
- node time: today's draft metadata + draft markdown → day log markdown + task markdown's log 的task markdown‘s log。
|
|
@ -0,0 +1,244 @@
|
|||
# 20240418
|
||||
|
||||
小结
|
||||
<a id="top"></a>
|
||||
根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md),今天绑定模版1。
|
||||
|
||||
| 时间片 | 时长 | 用途 |
|
||||
| --- | --- | --- |
|
||||
| 4:00~4:14 | 15 | 休整 |
|
||||
| 4:15~5:14 | 60 | 备餐、运动 |
|
||||
| 5:15~5:59 | 45 | 早餐 |
|
||||
| 6:00~6:44 | 45 | 会议、自习 |
|
||||
| 6:45~7:44 | 60 | 休整 |
|
||||
| 7:45~8:44 | 60 | [静默工作](http://simp.ly/p/xtgD4F) |
|
||||
| 8:45~9:29 | 45 | 休整 |
|
||||
| 9:30~10:59 | 90 | [静默工作](http://simp.ly/p/j1SspP) |
|
||||
| 11:00~13:59 | 180 | 备餐、午餐午休 |
|
||||
| 14:00~14:29 | 30 | [静默工作](http://simp.ly/p/8t3vlk) |
|
||||
| 14:30~14:59 | 30 | [静默工作](http://simp.ly/p/5k9gJy) |
|
||||
| 15:00~15:59 | 60 | 休整 |
|
||||
| 16:00~16:59 | 60 | [静默工作](http://simp.ly/p/4QDThK) |
|
||||
| 17:00~18:59 | 120 | 晚餐 |
|
||||
| 19:00~19:59 | 60 | 讨论、整理提交 |
|
||||
|
||||
模版一采用静默工作方式。
|
||||
希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com),通常安排在后面某天的早餐(5:15~5:59)或会议时间(6:00~6:45)。
|
||||
|
||||
---
|
||||
<a id="index"></a>
|
||||
- 07:45 [task metadata + draft metadata -> task view](#20240418074500)
|
||||
- 09:30 [termset metadata -> termset view](#20240418093000)
|
||||
- 14:00 [ego整体架构汇总](#20240418140000)
|
||||
- 14:30 [blog规划](#20240418143000)
|
||||
- 16:00 [task metada + draft metadata -> task stat](#20240418160000)
|
||||
|
||||
---
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240418074500"></a>
|
||||
## 7:45~8:44
|
||||
|
||||
ego:task metadata + draft metadata -> task view
|
||||
|
||||
- 重新调整task.js的参数
|
||||
~~~
|
||||
node task : today draft to stat
|
||||
node task view : draft metadata to task view
|
||||
node task all : task metadata to alltask metadata
|
||||
node task 2024 : draft to year stat
|
||||
node task 20240416 : draft to day stat
|
||||
node task 1 : diff date draft to stat
|
||||
node task 20240101 20240401 : period draft to stat
|
||||
~~~
|
||||
|
||||
完成:
|
||||
task metadata + draft metadata -> alltask metadata
|
||||
|
||||
下一步:
|
||||
alltask metadata -> task view
|
||||
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240418093000"></a>
|
||||
## 9:30~10:59
|
||||
|
||||
PSMD termset metadata -> termset view
|
||||
|
||||
修改了数据结构中的interface字段:
|
||||
~~~
|
||||
interface:
|
||||
entity:
|
||||
id: name
|
||||
asset:
|
||||
id: name
|
||||
term: // 引用其它条款,在termset、COM中根据联合使用情况绑定。
|
||||
id: name
|
||||
event:
|
||||
id: name
|
||||
~~~
|
||||
map字段
|
||||
~~~
|
||||
map: // interface 局部-全局映射表
|
||||
entity:
|
||||
localid: globalid
|
||||
asset:
|
||||
localid: globalid
|
||||
term: // 引用其它条款,在termset、COM中根据联合使用情况绑定。
|
||||
localid: globalid
|
||||
event:
|
||||
localid: globalid
|
||||
~~~
|
||||
以方便代码实现。目前还没有发现缺陷。
|
||||
|
||||
完成 term.js中的函数:
|
||||
- maketermsetview
|
||||
- maketermsettext
|
||||
- maketermtext
|
||||
可以生成termset view的正文。
|
||||
|
||||
D:\huangyg\git\PSMD\src>node term termset 1
|
||||
<entity.1> -> <entity.1>
|
||||
由<entity.1>书面提交即生效。
|
||||
|
||||
<asset.1> -> <asset.1>
|
||||
<asset.1>=20,<asset.1>%=20%。
|
||||
|
||||
<entity.1> -> <entity.2>
|
||||
由<entity.2>表决按一人一票表决,超过80%出席会议有效,赞成票超过超过三分之二为通过。
|
||||
|
||||
<entity.1> -> deployer
|
||||
1. 由deployer书面提交即生效。
|
||||
2. <asset.1>=20,<asset.1>%=20%。
|
||||
3. 由<entity.2>表决按一人一票表决,超过80%出席会议有效,赞成票超过超过三分之二为通过。
|
||||
|
||||
<entity.2> -> director
|
||||
1. 由deployer书面提交即生效。
|
||||
2. <asset.1>=20,<asset.1>%=20%。
|
||||
3. 由director表决按一人一票表决,超过80%出席会议有效,赞成票超过超过三分之二为通过。
|
||||
|
||||
<asset.1> -> p
|
||||
1. 由deployer书面提交即生效。
|
||||
2. p=20,p%=20%。
|
||||
3. 由director表决按一人一票表决,超过80%出席会议有效,赞成票超过超过三分之二为通过。
|
||||
|
||||
termset text:
|
||||
1. 由deployer书面提交即生效。
|
||||
2. p=20,p%=20%。
|
||||
3. 由director表决按一人一票表决,超过80%出席会议有效,赞成票超过超过三分之二为通过。
|
||||
|
||||
下一步:
|
||||
- 把termset的metada整理生成id和文件名。
|
||||
- 测试一下多层嵌套termset,目前范例只有一层。
|
||||
- 加上辅助信息产生正式的view,写入文件。
|
||||
- 顺便完成term view。主题函数已经在实现termset时做好了。
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240418140000"></a>
|
||||
## 14:00 ~ 14:30
|
||||
|
||||
ego整体架构汇总
|
||||
|
||||
### 整体架构:
|
||||
|
||||
~~~
|
||||
\raw 库处理饮食、作息
|
||||
\ego 库调度资源,主要是时间、内部token和各外部记账单位。管理无明确项目归属的公用资源。为各独立项目之间协作提供公用基础设施。
|
||||
\log 日志数据
|
||||
\data 元数据 metsadata
|
||||
\src 源代码
|
||||
\view 可阅读的文档、报表
|
||||
\draft 库存放原始手稿,包括ego和独立项目。
|
||||
\blog 库对外发布信息,主要是ego的,也包括从独立项目的实践中提炼的通用经验。
|
||||
有对外接口的项目开设专门库,独立调度资源、发布信息。各独立库的基础信息存放在\ego\data,以便互相协作。
|
||||
~~~
|
||||
|
||||
### 当前项目
|
||||
|
||||
- \raw\raw.js
|
||||
- 暂时不变,将来也按独立项目分为log、data、src、view文件夹。
|
||||
- 重点是数据结构和代码持续升级,而数据保持互通的机制。
|
||||
- \PSMD\src\term.js
|
||||
- 保留在PSMD项目下,作为独立项目的范例。
|
||||
- \ego\task\task.js
|
||||
- 整理为 data、src、view文件夹。
|
||||
- 重点是各项目之间资源调度的机制。
|
||||
- \blog\release\time.js
|
||||
- 整理到ego下。
|
||||
|
||||
### 项目间协作
|
||||
|
||||
- \ego\src\config.env.js : 某个软硬件环境下的路径、文件夹名称等信息。
|
||||
- \ego\src\util.js: 公用代码库。
|
||||
- \ego\log: 公用资源和项目间资源调度记录。
|
||||
- \ego\data\ : 各项目metadata。
|
||||
|
||||
下一步:考虑成熟后移动代码,实践检验。
|
||||
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240418143000"></a>
|
||||
## 14:30 ~ 15:00
|
||||
|
||||
PSMD lib规划
|
||||
|
||||
- blog
|
||||
- 针对新委托者:概念介绍、典型场景的快速入门。
|
||||
- 针对部署者:离线、独立部署将遇到的问题和当前经验。
|
||||
- 针对建模者:近期前沿问题和实践进展。
|
||||
- lib
|
||||
- error、term、termset、COM、deploy等metadata 不定期自动爬取,留下有价值的。不一定使用。
|
||||
- index.yaml、index.js 索引表:
|
||||
- PSMD受托者:包括自己
|
||||
- 使用的error、term、termset、COM、deploy等metadata。用于根据某metadata匹配公用者blog url。
|
||||
- 自动委托的PSMD标准合同
|
||||
- 自动受托的PSMD标准合同
|
||||
- 专门签署生效的PSMD标准合同
|
||||
- 标准合同下的委托需求:专门签署,或者沿着自动委托、受托链产生效力。
|
||||
|
||||
可以从view开始,metadata有些难度。
|
||||
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240418160000"></a>
|
||||
## 16:00 ~ 17:00
|
||||
|
||||
ego:task metada + draft metadata -> task stat
|
||||
|
||||
- 实现四种参数的subject时间统计。
|
||||
|
||||
D:\huangyg\git\ego\task>node task 2024
|
||||
draft to stat:20240101~20250101
|
||||
ego spent 720 minutes.
|
||||
PSMD spent 900 minutes.
|
||||
infra spent 30 minutes.
|
||||
|
||||
D:\huangyg\git\ego\task>node task
|
||||
draft to stat:20240418~20240419
|
||||
ego spent 150 minutes.
|
||||
PSMD spent 120 minutes.
|
||||
|
||||
D:\huangyg\git\ego\task>node task 20240414
|
||||
draft to stat:20240414~20240415
|
||||
PSMD spent 255 minutes.
|
||||
ego spent 90 minutes.
|
||||
|
||||
D:\huangyg\git\ego\task>node task -2
|
||||
draft to stat:20240416~20240417
|
||||
ego spent 270 minutes.
|
||||
PSMD spent 90 minutes.
|
||||
|
||||
D:\huangyg\git\ego\task>node task 20240416 20240418
|
||||
draft to stat:20240416~20240418
|
||||
ego spent 330 minutes.
|
||||
PSMD spent 375 minutes.
|
||||
|
||||
- 完成 alltask metadata -> task view,生成了简单的markdown。
|
||||
|
||||
|
||||
下一步:考虑子项目的情况。应该按树形结构逐级汇总。alltask metadata这时候可以用上,不要漏了subject。
|
|
@ -0,0 +1,318 @@
|
|||
# 20240419
|
||||
|
||||
小结
|
||||
<a id="top"></a>
|
||||
根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md),今天绑定模版1。
|
||||
|
||||
| 时间片 | 时长 | 用途 |
|
||||
| --- | --- | --- |
|
||||
| 4:00~4:14 | 15 | 休整 |
|
||||
| 4:15~5:14 | 60 | 备餐、运动 |
|
||||
| 5:15~5:59 | 45 | 早餐 |
|
||||
| 6:00~6:44 | 45 | 会议、自习 |
|
||||
| 6:45~7:44 | 60 | 休整 |
|
||||
| 7:45~8:44 | 60 | [静默工作](http://simp.ly/p/xtgD4F) |
|
||||
| 8:45~9:29 | 45 | 休整 |
|
||||
| 9:30~10:59 | 90 | [静默工作](http://simp.ly/p/j1SspP) |
|
||||
| 11:00~13:59 | 180 | 备餐、午餐午休 |
|
||||
| 14:00~14:29 | 30 | [静默工作](http://simp.ly/p/8t3vlk) |
|
||||
| 14:30~14:59 | 30 | [静默工作](http://simp.ly/p/5k9gJy) |
|
||||
| 15:00~15:59 | 60 | 休整 |
|
||||
| 16:00~16:59 | 60 | [静默工作](http://simp.ly/p/4QDThK) |
|
||||
| 17:00~18:59 | 120 | 晚餐 |
|
||||
| 19:00~19:59 | 60 | 讨论、整理提交 |
|
||||
|
||||
模版一采用静默工作方式。
|
||||
希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com),通常安排在后面某天的早餐(5:15~5:59)或会议时间(6:00~6:45)。
|
||||
|
||||
---
|
||||
<a id="index"></a>
|
||||
- 07:45 [PSMD 一合同附件的termset](#20240419074500)
|
||||
- 09:30 [根据task metadata 中的path字段追溯到各级子项目,在alltask metadata中增加树形结构。](#20240419093000)
|
||||
- 14:00 [把termset的metada整理生成id和文件名](#20240419140000)
|
||||
- 14:30 [把termset的metada整理生成id和文件名](#20240419143000)
|
||||
- 16:00 [设计error、term、termset、deploy、com的关系。](#20240419160000)
|
||||
|
||||
---
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240419074500"></a>
|
||||
## 7:45~8:44
|
||||
|
||||
PSMD 一合同附件的termset
|
||||
|
||||
- 根据[2024.04150930.md](2024.04150930.md)中附件20,编写termset metadata。
|
||||
- readme范例中,sortid字段前增加“- ”,表示数组。
|
||||
- 要注意去掉readme中范例的注释。
|
||||
- text要用| 标记,结尾自动换行。
|
||||
- 在term.js中增加termset递归功能。
|
||||
|
||||
term.2.yaml
|
||||
~~~
|
||||
name: 符合某条件1
|
||||
id: 2
|
||||
text: |
|
||||
涉事各方全体同意,推举一名或多名保证人:
|
||||
- 保证人在其它事项中符合该条件,并按照本附件提供补充信息。
|
||||
- 由保证人调查涉事各方是否符合该条件,将调查记录作为补充信息。
|
||||
~~~
|
||||
|
||||
term.3.yaml
|
||||
~~~
|
||||
name: 符合某条件2
|
||||
id: 3
|
||||
text: |
|
||||
涉事各方分别自述,交叉核实。将所有记录合并作为补充信息。
|
||||
~~~
|
||||
|
||||
term.4.yaml
|
||||
~~~
|
||||
name: 符合某条件3
|
||||
id: 4
|
||||
interface:
|
||||
term:
|
||||
1: 容器规则
|
||||
text: |
|
||||
涉事各方签署 <term.1>,承诺遵守该条件,将生效、执行的记录作为补充信息。
|
||||
~~~
|
||||
|
||||
term.5.yaml
|
||||
~~~
|
||||
name: 符合某条件开头
|
||||
id: 5
|
||||
interface:
|
||||
term:
|
||||
1: 下一条
|
||||
text: |
|
||||
对自述难以核实的情况下,可以按照<term.1>方式之一增加补充信息:
|
||||
~~~
|
||||
|
||||
termset.2.yaml
|
||||
~~~
|
||||
name: 符合某条件的条款
|
||||
id: 2
|
||||
level: 1
|
||||
interface:
|
||||
term:
|
||||
1: 容器规则
|
||||
item:
|
||||
- sortid: 1
|
||||
type: term
|
||||
id: 2
|
||||
path: term.2.yaml
|
||||
- sortid: 2
|
||||
type: term
|
||||
id: 3
|
||||
path: term.3.yaml
|
||||
- sortid: 3
|
||||
type: term
|
||||
id: 4
|
||||
map:
|
||||
term:
|
||||
1: 1
|
||||
path: term.4.yaml
|
||||
readme: |
|
||||
- upgradeby应该分内部、外部两种情况定义。
|
||||
effect: |
|
||||
~~~
|
||||
|
||||
termset.3.yaml
|
||||
~~~
|
||||
name: 符合某条件
|
||||
id: 3
|
||||
level: 2
|
||||
interface:
|
||||
term:
|
||||
1: 附件21.容器规则
|
||||
2: 第2条
|
||||
item:
|
||||
- sortid: 1
|
||||
type: term
|
||||
id: 5
|
||||
map:
|
||||
term:
|
||||
1: 2
|
||||
path: term.5.yaml
|
||||
- sortid: 2
|
||||
type: termset
|
||||
id: 2
|
||||
map:
|
||||
term:
|
||||
1: 1
|
||||
path: termset.2.yaml
|
||||
readme: |
|
||||
effect: |
|
||||
~~~
|
||||
|
||||
自动生成条款如下:
|
||||
~~~
|
||||
D:\huangyg\git\PSMD\src>node term termset 3
|
||||
<term.1> -> <term.2>
|
||||
对自述难以核实的情况下,可以按照<term.2>方式之一增加补充信息:
|
||||
|
||||
<term.1> -> <term.1>
|
||||
涉事各方签署 <term.1>,承诺遵守该条件,将生效、执行的记录作为补充信息。
|
||||
|
||||
<term.1> -> <term.1>
|
||||
2.1. 涉事各方全体同意,推举一名或多名保证人:
|
||||
- 保证人在其它事项中符合该条件,并按照本附件提供补充信息。
|
||||
- 由保证人调查涉事各方是否符合该条件,将调查记录作为补充信息。
|
||||
2.2. 涉事各方分别自述,交叉核实。将所有记录合并作为补充信息。
|
||||
2.3. 涉事各方签署 <term.1>,承诺遵守该条件,将生效、执行的记录作为补充信息。
|
||||
|
||||
<term.1> -> 附件21.容器规则
|
||||
1. 对自述难以核实的情况下,可以按照<term.2>方式之一增加补充信息:
|
||||
2.1. 涉事各方全体同意,推举一名或多名保证人:
|
||||
- 保证人在其它事项中符合该条件,并按照本附件提供补充信息。
|
||||
- 由保证人调查涉事各方是否符合该条件,将调查记录作为补充信息。
|
||||
2.2. 涉事各方分别自述,交叉核实。将所有记录合并作为补充信息。
|
||||
2.3. 涉事各方签署 附件21.容器规则,承诺遵守该条件,将生效、执行的记录作为补充信息。
|
||||
|
||||
<term.2> -> 第2条
|
||||
1. 对自述难以核实的情况下,可以按照第2条方式之一增加补充信息:
|
||||
2.1. 涉事各方全体同意,推举一名或多名保证人:
|
||||
- 保证人在其它事项中符合该条件,并按照本附件提供补充信息。
|
||||
- 由保证人调查涉事各方是否符合该条件,将调查记录作为补充信息。
|
||||
2.2. 涉事各方分别自述,交叉核实。将所有记录合并作为补充信息。
|
||||
2.3. 涉事各方签署 附件21.容器规则,承诺遵守该条件,将生效、执行的记录作为补充信息。
|
||||
|
||||
termset text:
|
||||
1. 对自述难以核实的情况下,可以按照第2条方式之一增加补充信息:
|
||||
2.1. 涉事各方全体同意,推举一名或多名保证人:
|
||||
- 保证人在其它事项中符合该条件,并按照本附件提供补充信息。
|
||||
- 由保证人调查涉事各方是否符合该条件,将调查记录作为补充信息。
|
||||
2.2. 涉事各方分别自述,交叉核实。将所有记录合并作为补充信息。
|
||||
2.3. 涉事各方签署 附件21.容器规则,承诺遵守该条件,将生效、执行的记录作为补充信息。
|
||||
~~~
|
||||
|
||||
下一步:考虑条款合并的需求。例如上面范例中,怎么实现1. 1.1. 1.2. 1.3.,而不是1. 2.1. ...。
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240419093000"></a>
|
||||
## 9:30~10:59
|
||||
|
||||
ego 根据task metadata 中的path字段追溯到各级子项目,在alltask metadata中增加树形结构。
|
||||
|
||||
- 为了表达各项目子任务,task metadata文件前缀从t.改为task.
|
||||
- 手工编辑learn.js PSMD.modeling PSMD.deploy三个子项目的metadata。
|
||||
- 根据各任务metadata中的path字段,进行递归查找,所有task并列写入tasklist,按parent id建立树形结构写入tasktree。
|
||||
- log写入tasklist。
|
||||
|
||||
下一步:
|
||||
- task view目前都写在task.js所在文件夹。实际使用一段时间在决定是否要写回task metada文件所在文件夹,要考虑独立项目的子任务。这样的话,要遭alltask.tasklist下面记录一下metadata所在位置。
|
||||
- stat统计时间先写入tasklist,再在tasktree归并。
|
||||
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240419140000"></a>
|
||||
## 14:00~14:29
|
||||
|
||||
PSMD:把termset的metada整理生成id和文件名
|
||||
|
||||
实现 term.js 中的 commit()
|
||||
~~~
|
||||
D:\huangyg\git\PSMD\src>node term commit
|
||||
符合某条件1 33523fe1
|
||||
符合某条件2 a1c197a9
|
||||
符合某条件3 259076a4
|
||||
符合某条件开头 bb8005b9
|
||||
调整分配主比例 01e1c775
|
||||
符合某条件的条款 949e69e3
|
||||
符合某条件 dbe32f79
|
||||
../data/term.33523fe1.yaml文件已更新。../data/term.2.yaml可以删除。
|
||||
../data/term.a1c197a9.yaml文件已更新。../data/term.3.yaml可以删除。
|
||||
../data/term.259076a4.yaml文件已更新。../data/term.4.yaml可以删除。
|
||||
../data/term.bb8005b9.yaml文件已更新。../data/term.5.yaml可以删除。
|
||||
../data/termset.01e1c775.yaml文件已更新。../data/termset.1.yaml可以删除。
|
||||
../data/termset.949e69e3.yaml文件已更新。../data/termset.2.yaml可以删除。
|
||||
../data/termset.dbe32f79.yaml文件已更新。../data/termset.3.yaml可以删除。
|
||||
~~~
|
||||
|
||||
使用新id运行node term termset:
|
||||
~~~
|
||||
D:\huangyg\git\PSMD\src>node term termset dbe32f79
|
||||
<term.1> -> <term.2>
|
||||
对自述难以核实的情况下,可以按照<term.2>方式之一增加补充信息:
|
||||
|
||||
<term.1> -> <term.1>
|
||||
涉事各方签署 <term.1>,承诺遵守该条件,将生效、执行的记录作为补充信息。
|
||||
|
||||
<term.1> -> <term.1>
|
||||
2.1. 涉事各方全体同意,推举一名或多名保证人:
|
||||
- 保证人在其它事项中符合该条件,并按照本附件提供补充信息。
|
||||
- 由保证人调查涉事各方是否符合该条件,将调查记录作为补充信息。
|
||||
2.2. 涉事各方分别自述,交叉核实。将所有记录合并作为补充信息。
|
||||
2.3. 涉事各方签署 <term.1>,承诺遵守该条件,将生效、执行的记录作为补充信息。
|
||||
|
||||
<term.1> -> 附件21.容器规则
|
||||
1. 对自述难以核实的情况下,可以按照<term.2>方式之一增加补充信息:
|
||||
2.1. 涉事各方全体同意,推举一名或多名保证人:
|
||||
- 保证人在其它事项中符合该条件,并按照本附件提供补充信息。
|
||||
- 由保证人调查涉事各方是否符合该条件,将调查记录作为补充信息。
|
||||
2.2. 涉事各方分别自述,交叉核实。将所有记录合并作为补充信息。
|
||||
2.3. 涉事各方签署 附件21.容器规则,承诺遵守该条件,将生效、执行的记录作为补充信息。
|
||||
|
||||
<term.2> -> 第2条
|
||||
1. 对自述难以核实的情况下,可以按照第2条方式之一增加补充信息:
|
||||
2.1. 涉事各方全体同意,推举一名或多名保证人:
|
||||
- 保证人在其它事项中符合该条件,并按照本附件提供补充信息。
|
||||
- 由保证人调查涉事各方是否符合该条件,将调查记录作为补充信息。
|
||||
2.2. 涉事各方分别自述,交叉核实。将所有记录合并作为补充信息。
|
||||
2.3. 涉事各方签署 附件21.容器规则,承诺遵守该条件,将生效、执行的记录作为补充信息。
|
||||
|
||||
termset text:
|
||||
1. 对自述难以核实的情况下,可以按照第2条方式之一增加补充信息:
|
||||
2.1. 涉事各方全体同意,推举一名或多名保证人:
|
||||
- 保证人在其它事项中符合该条件,并按照本附件提供补充信息。
|
||||
- 由保证人调查涉事各方是否符合该条件,将调查记录作为补充信息。
|
||||
2.2. 涉事各方分别自述,交叉核实。将所有记录合并作为补充信息。
|
||||
2.3. 涉事各方签署 附件21.容器规则,承诺遵守该条件,将生效、执行的记录作为补充信息。
|
||||
~~~
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240419143000"></a>
|
||||
## 14:30~14:59
|
||||
|
||||
PSMD:继续14:00的任务。
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240419160000"></a>
|
||||
## 16:00~16:59
|
||||
|
||||
PSMD 设计error、term、termset、deploy、com的关系。
|
||||
|
||||
- 增加记录log,核实log可以:
|
||||
- term、termset被遵守、违反:即用log定义term、termset的遵守和违反
|
||||
- error产生、未产生:即用log定义error
|
||||
- 某种环境env是指log中出现以下状况的组合:
|
||||
- 某些error未发现
|
||||
- 某些erro发现
|
||||
- 某些term、termset已生效
|
||||
- 某些term、termset未生效
|
||||
- 遵守term、termset的效果是:在某种env下,可以消除某些error。
|
||||
- 违反term、termset的效果是:在某种env下,可以产生某些error。
|
||||
- 这不是确定的,因为存在未知的、有相似效果的替代方案。
|
||||
- 排查其它term、termset后可以推测。
|
||||
- 某些error的效果是:在某种环境下,即使某些term、termset被遵守也会失去效果。最终这些term、termset会被普遍违反。
|
||||
|
||||
根据log提炼term、termset与error的关系:
|
||||
- 产生knowledge(env-termset-error之间映射关系)metadata
|
||||
|
||||
根据knowledge metadata:
|
||||
- 根据COM推断error
|
||||
- 产生COM修订动议
|
||||
- 根据deploy推选error
|
||||
- 产生deploy修订动议
|
||||
- 根据log核实error
|
||||
- 产生消除error的动议
|
||||
- 对反例提出核实、整理方案供第三方验证的动议
|
||||
|
||||
主体可以:
|
||||
- 发布log、env、knowledge
|
||||
- 标注感兴趣的env、term、termset、error,由工具自动筛选log、knowledge
|
||||
- 感兴趣的主体及其env
|
||||
- 以env的差距定义距离,参考dht编制索引表。
|
|
@ -0,0 +1,409 @@
|
|||
# 20240420
|
||||
|
||||
小结
|
||||
|
||||
<a id="top"></a>
|
||||
根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md),今天绑定模版1。
|
||||
|
||||
| 时间片 | 时长 | 用途 |
|
||||
| --- | --- | --- |
|
||||
| 4:00~4:14 | 15 | 休整 |
|
||||
| 4:15~5:14 | 60 | 备餐、运动 |
|
||||
| 5:15~5:59 | 45 | 早餐 |
|
||||
| 6:00~6:44 | 45 | 会议、自习 |
|
||||
| 6:45~7:44 | 60 | 休整 |
|
||||
| 7:45~8:44 | 60 | [静默工作](http://simp.ly/p/xtgD4F) |
|
||||
| 8:45~9:29 | 45 | 休整 |
|
||||
| 9:30~10:59 | 90 | [静默工作](http://simp.ly/p/j1SspP) |
|
||||
| 11:00~13:59 | 180 | 备餐、午餐午休 |
|
||||
| 14:00~14:29 | 30 | [静默工作](http://simp.ly/p/8t3vlk) |
|
||||
| 14:30~14:59 | 30 | [静默工作](http://simp.ly/p/5k9gJy) |
|
||||
| 15:00~15:59 | 60 | 休整 |
|
||||
| 16:00~16:59 | 60 | [静默工作](http://simp.ly/p/4QDThK) |
|
||||
| 17:00~18:59 | 120 | 晚餐 |
|
||||
| 19:00~19:59 | 60 | 讨论、整理提交 |
|
||||
|
||||
模版一采用静默工作方式。
|
||||
希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com),通常安排在后面某天的早餐(5:15~5:59)或会议时间(6:00~6:45)。
|
||||
|
||||
---
|
||||
<a id="index"></a>
|
||||
- 07:45 [整理合同metadata范例](#20240420074500)
|
||||
- 09:30 [PSMD:一份要约的 metsdata → view](#20240420093000)
|
||||
- 14:00 [学习国密算法](#20240420140000)
|
||||
- 14:30 [子任务时间汇总](#20240420143000)
|
||||
- 16:00 [PSMD 设计error、log、env、knowledge等新的数据结构,思考与termset、com、task的关联。](#20240420160000)
|
||||
|
||||
---
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240420074500"></a>
|
||||
## 7:45~8:44
|
||||
|
||||
整理合同metadata范例
|
||||
|
||||
完成了:
|
||||
- draft 202404151600.md 中的附件21:d0111eb4
|
||||
- 附件31:PSMD升级规则中的PS标准:6d206b54
|
||||
- 附件32:PSMD升级规则中的保密规则:9e6bc34f
|
||||
|
||||
解决一个错误,输出到markdown文件居然习惯性地加了yaml.dump() 。导致markdown中的序号后有两个空格,还有换行的情况。
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240420093000"></a>
|
||||
## 9:30~10:59
|
||||
|
||||
PSMD:一份要约的 metsdata → view
|
||||
|
||||
draft 202404151600.md:
|
||||
|
||||
~~~
|
||||
|
||||
针对不同条件给出建议如下:
|
||||
1. 使用自定义的规章解决资源和重构问题,具体可以参考1609、chain等标准模型。
|
||||
- 同意按照附件20增加补充信息,补充关于附件30,42,31、32、33、34的补充信息,且均判断为符合。
|
||||
1. 先参考default+1406标准模型开展业务,逐步完善规章,取得进步后重新增加关于附件31、32、33、34的补充信息。
|
||||
- 同意按照附件20增加补充信息,补充关于附件30,42,31、32、33、34的补充信息,且判断符合附件30、42,不全符合符合31、32、33、34。
|
||||
1. 在业务背景下,基于既成事实博弈。具体可以参考default标准模型。
|
||||
- 不能按照附件20增加补充信息。
|
||||
- 同意按照附件20增加补充信息,补充关于附件30的补充信息,且判断为不符合。
|
||||
1. 参考booting标准模型。
|
||||
- 还在筹备因此无法补充信息的。
|
||||
|
||||
如果有其它可行方案请发到<huangyg@mars22.com>,我将按照附件21核实。
|
||||
|
||||
附件21 实施效果的核实
|
||||
|
||||
1. 公布完整、连续、不可删改的执行记录,证实方案的效果。
|
||||
- 如果以前的执行记录不符合以上条件,可以在愿意按标准公布记录的独立第三方验证。
|
||||
1. 已发布开放的要约,只有取得该效果才有收益。
|
||||
~~~
|
||||
|
||||
其它draft相关内容:
|
||||
~~~
|
||||
### 附件30 有效的内部监管
|
||||
定义:已有基础制度和人员,能保证书面规章的违约成本高于收益。规定监管人员以外的内部成员、外部合作方不需要额外为此耗费资源。
|
||||
|
||||
### 附件42 资源不足
|
||||
定义:需要以未来的收入换取资源,而且需要与同行争夺。
|
||||
反向的情况,是创始时能一次筹集到足够的资源,可见未来的收入和积累都超过支出。或者需要以未来的收入换取资源,但是不需要竞争即可获得充足资源。
|
||||
|
||||
### 附件 43 能力和贡献持续变化
|
||||
定义:核心人员凭借职权高估自己的贡献、低估非核心成员的贡献,这样做的综合效果更符合他们的利益。
|
||||
反向的情况,核心人员准确估算包括自己在内的成员贡献,这样做的综合效果更符合他们的利益。
|
||||
~~~
|
||||
|
||||
继续把 draft 202404151600.md 中的合同整理为term、termset的metadata,然后commit生成正式metadata,再生成view:
|
||||
- 附件33:PSMD升级规则中的制定规则:600f6f80
|
||||
- 附件34:PSMD升级规则中的分支隔离规则:12119600
|
||||
- 附件30:有效的内部监管
|
||||
- 附件42 资源不足
|
||||
- 附件 43 能力和贡献持续变化
|
||||
- 入门目录202404151600主体(第2条)
|
||||
- 入门目录202404151600全文:
|
||||
- 附件20的term.2,不需要向外映射。可以沿用内部interface。
|
||||
- 附件32的term.1也是
|
||||
- 附件33的term.1
|
||||
|
||||
commit产生的这批id如下:
|
||||
~~~
|
||||
入门目录202404151600-2-1 5b4e0597
|
||||
入门目录202404151600-2-2 52edbf25
|
||||
入门目录202404151600-2-3 7288c99c
|
||||
入门目录202404151600-2-4 dd1bc41b
|
||||
入门目录202404151600-1 cc0fba2f
|
||||
入门目录202404151600-3 4b12ac08
|
||||
有效的内部监管 91ff9448
|
||||
资源不足 cb4ab0e9
|
||||
能力和贡献持续变化 5ab2b2ba
|
||||
入门目录202404151600-2 e6976035
|
||||
入门目录202404151600 9d12877c
|
||||
~~~
|
||||
|
||||
加上已经完成的:
|
||||
- 附件20:符合某条件:dbe32f79
|
||||
- 附件21:实施效果的核实:d0111eb4
|
||||
- 附件31:PSMD升级规则中的PS标准:6d206b54
|
||||
- 附件32:PSMD升级规则中的保密规则:9e6bc34f
|
||||
|
||||
执行过程:
|
||||
|
||||
~~~
|
||||
|
||||
D:\huangyg\git\PSMD\src>node term commit
|
||||
入门目录202404151600-2-1 5b4e0597
|
||||
入门目录202404151600-2-2 52edbf25
|
||||
入门目录202404151600-2-3 7288c99c
|
||||
入门目录202404151600-2-4 dd1bc41b
|
||||
入门目录202404151600-1 cc0fba2f
|
||||
入门目录202404151600-3 4b12ac08
|
||||
有效的内部监管 91ff9448
|
||||
资源不足 cb4ab0e9
|
||||
能力和贡献持续变化 5ab2b2ba
|
||||
入门目录202404151600-2 e6976035
|
||||
入门目录202404151600 9d12877c
|
||||
../data/term.5b4e0597.yaml文件已更新。../data/term.1.yaml可以删除。
|
||||
../data/term.52edbf25.yaml文件已更新。../data/term.2.yaml可以删除。
|
||||
../data/term.7288c99c.yaml文件已更新。../data/term.3.yaml可以删除。
|
||||
../data/term.dd1bc41b.yaml文件已更新。../data/term.4.yaml可以删除。
|
||||
../data/term.cc0fba2f.yaml文件已更新。../data/term.5.yaml可以删除。
|
||||
../data/term.4b12ac08.yaml文件已更新。../data/term.6.yaml可以删除。
|
||||
../data/term.91ff9448.yaml文件已更新。../data/term.7.yaml可以删除。
|
||||
../data/term.cb4ab0e9.yaml文件已更新。../data/term.8.yaml可以删除。
|
||||
../data/term.5ab2b2ba.yaml文件已更新。../data/term.9.yaml可以删除。
|
||||
path replace:term.1.yaml term.5b4e0597.yaml
|
||||
path replace:term.2.yaml term.52edbf25.yaml
|
||||
path replace:term.3.yaml term.7288c99c.yaml
|
||||
path replace:term.4.yaml term.dd1bc41b.yaml
|
||||
../data/termset.e6976035.yaml文件已更新。../data/termset.1.yaml可以删除。
|
||||
path replace:term.5.yaml term.cc0fba2f.yaml
|
||||
path replace:termset.1.yaml termset.e6976035.yaml
|
||||
path replace:term.6.yaml term.4b12ac08.yaml
|
||||
旧文件:../data/termset.2.yaml中itemset:3的id:dbe32f79未能替换,请人工检查。
|
||||
旧文件:../data/termset.2.yaml中itemset:4的id:d0111eb4未能替换,请人工检查。
|
||||
path replace:termset.7.yaml termset.91ff9448.yaml
|
||||
旧文件:../data/termset.2.yaml中itemset:6的id:6d206b54未能替换,请人工检查。
|
||||
旧文件:../data/termset.2.yaml中itemset:7的id:9e6bc34f未能替换,请人工检查。
|
||||
旧文件:../data/termset.2.yaml中itemset:8的id:600f6f80未能替换,请人工检查。
|
||||
旧文件:../data/termset.2.yaml中itemset:9的id:12119600未能替换,请人工检查。
|
||||
path replace:termset.8.yaml termset.cb4ab0e9.yaml
|
||||
path replace:termset.9.yaml termset.5ab2b2ba.yaml
|
||||
../data/termset.9d12877c.yaml文件已更新。../data/termset.2.yaml可以删除。
|
||||
|
||||
~~~
|
||||
|
||||
执行 node term termset 9d12877c 产生的文件termset.9d12877c.md内容如下(作为txt可以,作为markdown的话序号乱了):
|
||||
|
||||
···
|
||||
|
||||
1. 针对不同条件给出建议如下:
|
||||
2.1. 条件:同意按照附件20增加补充信息,补充关于附件30,附件42,附件31、附件32、附件33、附件34的补充信息,且均判断为符合。
|
||||
建议:使用自定义的规章解决资源和重构问题,具体可以参考1609、chain等标准模型。
|
||||
2.2. 条件:同意按照附件20增加补充信息,补充关于附件30,附件42,附件31、附件32、附件33、附件34的补充信息,且判断符合附件附件30,附件42,不全符合符合附件31、附件32、附件33、附件34。
|
||||
建议:先参考default+1406标准模型开展业务,逐步完善规章,取得进步后重新增加关于附件附件31、附件32、附件33、附件34的补充信息。
|
||||
2.3. 条件:
|
||||
- 不能按照附件20增加补充信息。
|
||||
- 同意按照附件20增加补充信息,补充关于附件30的补充信息,且判断为不符合。
|
||||
建议:在业务背景下,基于既成事实博弈。具体可以参考default标准模型。
|
||||
2.4. 条件:还在筹备因此无法补充信息的。
|
||||
建议:参考booting标准模型。
|
||||
3. 如果有其它可行方案请发到<huangyg@mars22.com>,我将按照附件21核实。
|
||||
附件20.1. 对自述难以核实的情况下,可以按照第2条方式之一增加补充信息:
|
||||
附件20.2.1. 涉事各方全体同意,推举一名或多名保证人:
|
||||
- 保证人在其它事项中符合该条件,并按照本附件提供补充信息。
|
||||
- 由保证人调查涉事各方是否符合该条件,将调查记录作为补充信息。
|
||||
附件20.2.2. 涉事各方分别自述,交叉核实。将所有记录合并作为补充信息。
|
||||
附件20.2.3. 涉事各方签署 附件21,承诺遵守该条件,将生效、执行的记录作为补充信息。
|
||||
附件21.1. 公布完整、连续、不可删改的执行记录,证实方案的效果。
|
||||
- 如果以前的执行记录不符合以上条件,可以在愿意按标准公布记录的独立第三方验证。
|
||||
附件21.2. 已发布开放的要约,只有取得该效果才有收益。
|
||||
附件30. 定义:已有基础制度和人员,能保证书面规章的违约成本高于收益。规定监管人员以外的内部成员、外部合作方不需要额外为此耗费资源。
|
||||
附件31.1. 规章条款的上下级关系,根据制定、修订权定义。
|
||||
附件31.2. 人员的上下级关系,根据任免权定义。
|
||||
附件31.3. 严格执行制定、修订程序。上级规章条款未生效(或被实质架空)时,不提交、不讨论下级规章条款。
|
||||
附件31.4. 严格执行任免程序。上级人员未赴任(或被实质架空)时,不提名、不讨论下级人员。
|
||||
附件32.1. 所有人员的所有工作结果默认为公开,对外发布。
|
||||
附件32.2. 人按PS标准上溯得出顶级规章,从顶级规章到保密制度之间的上下级规章链条(包括保密制度),这组规章的密级均为公开,这组规章的工作记录的密级由该规章自行规定,保密制度不得改变。
|
||||
附件32.3. 一份文档所有用途使用相同方式取得。如果因不可抗力需要改变方式,应规定不可抗力的判定程序,确保内容相同。
|
||||
附件32.4. 如果在密级规定范围内的人员都没有能力完成任务,制定保密制度相应条款的人员承担主要责任,赔偿损失。
|
||||
附件33.1. 制定规章要明确预期效果。
|
||||
附件33.2. 接到质询时必须提供依据,依据必须是 外部法律 or 案例统计 两种方式之一。
|
||||
附件33.3. 如果是旧版本修订,制定者可以提出适用范围。只能向该适用范围内使用旧版规章的共同体发送修订通知。
|
||||
附件33.4. 分支隔离规则适用于制定规章。一个分支的共同体内制定规章时,所提供依据如果使用其它分支的案例,将自动增加切换规章的动议作为前提。
|
||||
附件34.1. 对相同事项的不同处理方法,视为同一规章的不同分支版本。对该事项未做任何规定,也视为其中一个分支版本。
|
||||
附件34.2. 实际通过生效、使用某分支版本的规章,即为支持该分支版本,反对其它分支版本。
|
||||
附件34.3. 规章使用过程遇到问题可以提出修订委托,如发往反对者将自动转为帮助切换规章的委托(切换到对方实际使用的分支版本)。如果是付费委托,受托者只需回答实际收到的问题。
|
||||
附件34.4. 查询资料时,未做任何规定分支可以列出所有分支的资料,其它分支只列出本分支的资料。
|
||||
附件42. 定义:需要以未来的收入换取资源,而且需要与同行争夺。
|
||||
反向的情况,是创始时能一次筹集到足够的资源,可见未来的收入和积累都超过支出。或者需要以未来的收入换取资源,但是不需要竞争即可获得充足资源。
|
||||
附件43. 定义:核心人员凭借职权高估自己的贡献、低估非核心成员的贡献,这样做的综合效果更符合他们的利益。
|
||||
反向的情况,核心人员准确估算包括自己在内的成员贡献,这样做的综合效果更符合他们的利益。
|
||||
|
||||
···
|
||||
|
||||
下一步:
|
||||
- 把附件43加进去。
|
||||
- termid可能有二义性:字符串和数字。比如:2e758794 被理解为Infinity (位置在maketermtext()开头。已解决,在yaml.load()增加参数, { schema: yaml.FAILSAFE_SCHEMA });):
|
||||
|
||||
~~~
|
||||
Error: ENOENT: no such file or directory, open 'D:\huangyg\git\PSMD\data\term.Infinity.yaml'
|
||||
at Object.readFileSync (node:fs:455:20)
|
||||
at maketermtext (D:\huangyg\git\PSMD\src\term.js:239:32)
|
||||
at maketermsettext (D:\huangyg\git\PSMD\src\term.js:202:28)
|
||||
at maketermsetview (D:\huangyg\git\PSMD\src\term.js:183:23)
|
||||
at Object.<anonymous> (D:\huangyg\git\PSMD\src\term.js:42:9)
|
||||
~~~
|
||||
|
||||
- 附件34 termset.12119600.yaml的readme字段出现变形。开头的|被改为>,每行之间、-号和条文之间都被加了回车
|
||||
- 各级termsetinterface中的id (globalid)要避开item.map中的id (localid),以免在替换时产生二义性。
|
||||
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240420140000"></a>
|
||||
## 14:00~14:29
|
||||
|
||||
学习国密算法
|
||||
|
||||
- 在 202404151400.md基础上,增加 js.simple/sm.crypt/local.3.html 的功能。但是网页中执行中断。
|
||||
- 直接在nodejs下命令行验证:创建密钥对、加密、解密、签名、验证,都正常。
|
||||
|
||||
~~~
|
||||
|
||||
D:\huangyg\git\js.sample\sm-crypto>node test
|
||||
public key:04d5e72263e80e3715411c04f3cf586c2e24673c6611f2ef7bbb1e33f19a12b1f45fe694ae314001fcc606148cb9b095d0ae0f12a8e58ef17ba64cfddc2e66e561
|
||||
private key:b28bdee8e2cccf2978a9eabffd0ffeb33550f5c2aff5869bbe106f54c0cdd39d
|
||||
verify public key:true
|
||||
plain text:
|
||||
|
||||
- task:PSMD [整理合同和COM metadata](../../../draft/2024/04/20240420074500.md)
|
||||
- task:PSMD [COM metsdata → COM view](../../../draft/2024/04/20240420093000.md)
|
||||
- task:js [学习国密算法](../../../draft/2024/04/20240420140000.md)
|
||||
- task:ego [子任务时间汇总的伪码](../../../draft/2024/04/20240420143000.md)
|
||||
- task:PSMD [设计error、log、env、knowledge等新的数据结构,以及与termset、com、task关联。](../../../draft/2024/04/20240420160000.md)
|
||||
encrypt text:
|
||||
fe2d9872a4cede8bbf9e2b1f2aff19ab9011fe54de3fe8f48246fae88bc0c0658afa696f8094cefb15549028db4fb24a15232e65c5707794edb7aa177a695a6fed8312db3e64abb8eb2a128e52e43c774696246fa5ef389d8894e76ff3056a273ef81f4cb7cbe4b2c52ba484075b1d904280d53826e636f2de9259d294e9b515da929a82a8f4f769349bb5084d08a8d61f6a353050f1c3f74e4717fffebeae1fa305cd5b7bec375b8bea0d4bf771a445db669440031d3416b2de4828fea45c6bf8c164628f0796d1b7f2664a57a707c2bc932a69f545c60794a2fb105dba331dc1fb6e3121b1486ea5249a75ad30a4f28ac1d418c17519d2919538df0ef7853e437374bc317e92000d442529db7a91e255b7af5f2715cf0af21a3868dca7e4733f1ee1af96931dacbb1cded09fb2b0a5b505ef3f50e55558bd6f626d074d6ed6e68096c1eb7cae69aed65e8f68f726ccb7a81df91dd208bd65c7088b9212acb8f46f6898a611b64757d1a04db9fba3b62541b863e56ea058e769925af921c15cb80440dfb72af8977eb0a029471c15d3f9727f8ac6475f3780dc563f5f04fc91afb7a3a5f6ff65d6efc90826c8c88716db31a1946f79b94cbfd11d3567aebcc879b70b3ebd8c01274c16d82b0b67544cfffe152113c59ae042433e58ef8bccb06d5c63d059190deded3a7f6ec83d52a04fb66e12228bba4df84b44957f0a1ce888d237d70270bdb8eb4c7ab7042a606b36b2151ec5487773c19a97f54f2729d3811a3c7a700fa8d564a69d6a7cefc1d34c724536ad91e9f3d38c13a46eef72302cac78f5
|
||||
decrypt text:
|
||||
|
||||
- task:PSMD [整理合同和COM metadata](../../../draft/2024/04/20240420074500.md)
|
||||
- task:PSMD [COM metsdata → COM view](../../../draft/2024/04/20240420093000.md)
|
||||
- task:js [学习国密算法](../../../draft/2024/04/20240420140000.md)
|
||||
- task:ego [子任务时间汇总的伪码](../../../draft/2024/04/20240420143000.md)
|
||||
- task:PSMD [设计error、log、env、knowledge等新的数据结构,以及与termset、com、task关联。](../../../draft/2024/04/20240420160000.md)
|
||||
signed hex:de92ea6ec507b39015f492c43f52a5418dd107da9722f36ed60f48c2dcd9a4587139478ba620b8ebc3e8aa4a059929caba0c643c77820fef8e68348c91ee8953
|
||||
verify the sig: true
|
||||
~~~
|
||||
|
||||
参考资料:
|
||||
- https://github.com/antherd/sm-crypto
|
||||
- https://www.cnblogs.com/goodAndyxublog/p/15654531.html
|
||||
- https://cscoder.cn/docs/base/sm_crypto/sm-crypto-js.html
|
||||
|
||||
下一步:
|
||||
- FileSaver的SaveAs()为什么需要先alert一下才能用。
|
||||
- sm2.doEncrypt()出错。阅读参考资料找出原因。
|
||||
- 学习sm3、sm4等算法接口。
|
||||
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240420143000"></a>
|
||||
## 14:30~14:59
|
||||
|
||||
子任务时间汇总
|
||||
|
||||
- 直接修改了task.js的maketaskview(),以后可以在 node task view的过程中统计时间。
|
||||
- 增加了gettreetime(),递归汇总各任务及子任务消耗的时间。
|
||||
- 修改了一些bug。
|
||||
|
||||
执行结果:
|
||||
~~~
|
||||
|
||||
D:\huangyg\git\ego\task>node task view
|
||||
can't find task metadata: infra
|
||||
end node:1cJ9sN node time:840
|
||||
end node:16cedf80 node time:30
|
||||
tree node:6a8da52e node time:0 child time:30
|
||||
end node:b7bd55c1 node time:0
|
||||
end node:e39da5b6 node time:0
|
||||
tree node:01d9c808 node time:1355 child time:0
|
||||
tasktree totaltime:2225
|
||||
|
||||
alltask.yaml文件已被更新。
|
||||
task.1cJ9sN.md文件已被更新。
|
||||
task.16cedf80.md文件已被更新。
|
||||
task.6a8da52e.md文件已被更新。
|
||||
task.01d9c808.md文件已被更新。
|
||||
task.b7bd55c1.md文件已被更新。
|
||||
task.e39da5b6.md文件已被更新。
|
||||
|
||||
~~~
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240420160000"></a>
|
||||
## 16:00~16:59
|
||||
|
||||
PSMD 设计error、log、env、knowledge等新的数据结构,思考与termset、com、task的关联。
|
||||
|
||||
- 在上午9:30实现的要约 9d12877c termset中,其实附件42、43就是error,附件30、31、32、33、34是针对五种error的解决方案。
|
||||
- 如果有error、termsert之间的关系,应该可以自动生成这份要约。或者生成一份情况核实表,分别针对合适结果产生建议。
|
||||
- 如果写入term metadata,恐怕表达能力有限。
|
||||
|
||||
### 数据结构
|
||||
|
||||
#### env
|
||||
|
||||
~~~
|
||||
name:
|
||||
id:
|
||||
term:
|
||||
- id:
|
||||
- id:
|
||||
termset:
|
||||
- id:
|
||||
- id:
|
||||
error:
|
||||
- id
|
||||
- id
|
||||
~~~
|
||||
- term字段:已经生效的term。如果单独有重要效果的话就列出。
|
||||
- termset字段:已经生效的termset。如果有效果的term组合被分在termset的不同章节下,如何快速匹配?
|
||||
- error:目前未解决的error
|
||||
|
||||
#### error
|
||||
|
||||
- error
|
||||
~~~
|
||||
name:
|
||||
id:
|
||||
text: |
|
||||
readme: |
|
||||
bind:
|
||||
- type: term、termset、COM、deploy、COD
|
||||
id:
|
||||
~~~
|
||||
|
||||
#### log
|
||||
~~~
|
||||
- id:
|
||||
- time:
|
||||
- entityid:
|
||||
- termsetid:
|
||||
- termid:
|
||||
- text: |
|
||||
~~~
|
||||
- entity是指cod的interface中id。
|
||||
- termid是指termset中的sortid/sortid/.../sortid
|
||||
- 某entity根据某term的行为。
|
||||
|
||||
#### knowldege / effect
|
||||
|
||||
~~~
|
||||
name:
|
||||
id:
|
||||
envid:
|
||||
term:
|
||||
- id:
|
||||
termset:
|
||||
- id:
|
||||
- id
|
||||
error:
|
||||
- id:
|
||||
percent:
|
||||
text:
|
||||
readme: |
|
||||
~~~
|
||||
在env下,term和termset生效就有多大可能性消除error。
|
||||
|
||||
下一步:
|
||||
- 编辑下列error metadata:
|
||||
- 未经统一程序兼任职务
|
||||
- 职务行为未提交log
|
||||
- 未经表决而生效的职务行为
|
||||
- 规章超负荷
|
||||
- 合规工作超负荷
|
||||
- 编辑下列env metadata:
|
||||
- 整理1406 termset,根据knowledge拆分
|
||||
- 编辑以上error、env相关的knowledge
|
|
@ -0,0 +1,283 @@
|
|||
# 20240421
|
||||
|
||||
小结
|
||||
|
||||
<a id="top"></a>
|
||||
根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md),今天绑定模版1。
|
||||
|
||||
| 时间片 | 时长 | 用途 |
|
||||
| --- | --- | --- |
|
||||
| 4:00~4:14 | 15 | 休整 |
|
||||
| 4:15~5:14 | 60 | 备餐、运动 |
|
||||
| 5:15~5:59 | 45 | 早餐 |
|
||||
| 6:00~6:44 | 45 | 会议、自习 |
|
||||
| 6:45~7:44 | 60 | 休整 |
|
||||
| 7:45~8:44 | 60 | [静默工作](http://simp.ly/p/xtgD4F) |
|
||||
| 8:45~9:29 | 45 | 休整 |
|
||||
| 9:30~10:59 | 90 | [静默工作](http://simp.ly/p/j1SspP) |
|
||||
| 11:00~13:59 | 180 | 备餐、午餐午休 |
|
||||
| 14:00~14:29 | 30 | [静默工作](http://simp.ly/p/8t3vlk) |
|
||||
| 14:30~14:59 | 30 | [静默工作](http://simp.ly/p/5k9gJy) |
|
||||
| 15:00~15:59 | 60 | 休整 |
|
||||
| 16:00~16:59 | 60 | [静默工作](http://simp.ly/p/4QDThK) |
|
||||
| 17:00~18:59 | 120 | 晚餐 |
|
||||
| 19:00~19:59 | 60 | 讨论、整理提交 |
|
||||
|
||||
模版一采用静默工作方式。
|
||||
希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com),通常安排在后面某天的早餐(5:15~5:59)或会议时间(6:00~6:45)。
|
||||
|
||||
---
|
||||
<a id="index"></a>
|
||||
- 07:45 [整理思路和基础概念](#20240421074500)
|
||||
- 09:30 [增加readme字段,纳入interface和map替换范围。](#20240421093000)
|
||||
- 14:00 [熟悉国密算法的sm3、sm4接口](#20240421140000)
|
||||
- 14:30 [整理1406历史资料](#20240421143000)
|
||||
- 16:00 [编辑1406的metadata,并生成view。](#20240421160000)
|
||||
|
||||
---
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240421074500"></a>
|
||||
## 7:45~8:44
|
||||
|
||||
整理思路和基础概念
|
||||
|
||||
### raw vs ego
|
||||
|
||||
-
|
||||
- ego需要能分配压力,淘汰低价值目标。
|
||||
|
||||
### PSMD vs infra
|
||||
|
||||
### entity and joint , spilit
|
||||
|
||||
### vat
|
||||
|
||||
### club
|
||||
|
||||
### let‘s X
|
||||
|
||||
### token and joint token
|
||||
|
||||
### 尽快把人组织起来
|
||||
|
||||
还有细节未能决定,以后继续思考。
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240421093000"></a>
|
||||
## 9:30~10:59
|
||||
|
||||
增加readme字段,纳入interface和map替换范围。
|
||||
|
||||
- 修改 term.js 中的maketermsettext() maketermtext() 两个函数,第一个参数改为传递对象,直接在里面添加treetext、treereadme两个字段,代替返回值。
|
||||
- maketermsetview() 那里需要构造一个item,虚拟一个上级节点才能调用maketermsettext()。
|
||||
- 微调了空格和换行。
|
||||
|
||||
|
||||
执行结果如下:
|
||||
|
||||
```
|
||||
|
||||
D:\huangyg\git\PSMD\src>node term termset 9d12877c
|
||||
../view/termset.9d12877c.md文件更新,内容如下:
|
||||
1. 针对不同条件给出建议如下:
|
||||
2.
|
||||
2.1. 条件:同意按照附件20增加补充信息,补充关于附件30,附件42,附件31、附件32、附件33、附件34的补充信息,且均判断为符合。
|
||||
建议:使用自定义的规章解决资源和重构问题,具体可以参考1609、chain等标准模型。
|
||||
2.2. 条件:同意按照附件20增加补充信息,补充关于附件30,附件42,附件31、附件32、附件33、附件34的补充信息,且判断符合附件附件30,附件42,不全符合符合 附件31、附件32、附件33、附件34。
|
||||
建议:先参考default+1406标准模型开展业务,逐步完善规章,取得进步后重新增加关于附件附件31、附件32、附件33、附件34的补充信息。
|
||||
2.3. 条件:
|
||||
- 不能按照附件20增加补充信息。
|
||||
- 同意按照附件20增加补充信息,补充关于附件30的补充信息,且判断为不符合。
|
||||
建议:在业务背景下,基于既成事实博弈。具体可以参考default标准模型。
|
||||
2.4. 条件:还在筹备因此无法补充信息的。
|
||||
建议:参考booting标准模型。
|
||||
3. 如果有其它可行方案请发到<huangyg@mars22.com>,我将按照附件21核实。
|
||||
附件20.
|
||||
附件20.1. 对自述难以核实的情况下,可以按照第2条方式之一增加补充信息:
|
||||
附件20.2.
|
||||
附件20.2.1. 涉事各方全体同意,推举一名或多名保证人:
|
||||
- 保证人在其它事项中符合该条件,并按照本附件提供补充信息。
|
||||
- 由保证人调查涉事各方是否符合该条件,将调查记录作为补充信息。
|
||||
附件20.2.2. 涉事各方分别自述,交叉核实。将所有记录合并作为补充信息。
|
||||
附件20.2.3. 涉事各方签署 附件21,承诺遵守该条件,将生效、执行的记录作为补充信息。
|
||||
附件21.
|
||||
附件21.1. 公布完整、连续、不可删改的执行记录,证实方案的效果。
|
||||
- 如果以前的执行记录不符合以上条件,可以在愿意按标准公布记录的独立第三方验证。
|
||||
附件21.2. 已发布开放的要约,只有取得该效果才有收益。
|
||||
附件30. 定义:已有基础制度和人员,能保证书面规章的违约成本高于收益。规定监管人员以外的内部成员、外部合作方不需要额外为此耗费资源。
|
||||
附件31.
|
||||
附件31.1. 规章条款的上下级关系,根据制定、修订权定义。
|
||||
附件31.2. 人员的上下级关系,根据任免权定义。
|
||||
附件31.3. 严格执行制定、修订程序。上级规章条款未生效(或被实质架空)时,不提交、不讨论下级规章条款。
|
||||
附件31.4. 严格执行任免程序。上级人员未赴任(或被实质架空)时,不提名、不讨论下级人员。
|
||||
附件32.
|
||||
附件32.1. 所有人员的所有工作结果默认为公开,对外发布。
|
||||
附件32.2. 人按PS标准上溯得出顶级规章,从顶级规章到保密制度之间的上下级规章链条(包括保密制度),这组规章的密级均为公开,这组规章的工作记录的密级由该规章自行规定,保密制度不得改变。
|
||||
附件32.3. 一份文档所有用途使用相同方式取得。如果因不可抗力需要改变方式,应规定不可抗力的判定程序,确保内容相同。
|
||||
附件32.4. 如果在密级规定范围内的人员都没有能力完成任务,制定保密制度相应条款的人员承担主要责任,赔偿损失。
|
||||
附件33.
|
||||
附件33.1. 制定规章要明确预期效果。
|
||||
附件33.2. 接到质询时必须提供依据,依据必须是 外部法律 or 案例统计 两种方式之一。
|
||||
附件33.3. 如果是旧版本修订,制定者可以提出适用范围。只能向该适用范围内使用旧版规章的共同体发送修订通知。
|
||||
附件33.4. 分支隔离规则适用于制定规章。一个分支的共同体内制定规章时,所提供依据如果使用其它分支的案例,将自动增加切换规章的动议作为前提。
|
||||
附件34.
|
||||
附件34.1. 对相同事项的不同处理方法,视为同一规章的不同分支版本。对该事项未做任何规定,也视为其中一个分支版本。
|
||||
附件34.2. 实际通过生效、使用某分支版本的规章,即为支持该分支版本,反对其它分支版本。
|
||||
附件34.3. 规章使用过程遇到问题可以提出修订委托,如发往反对者将自动转为帮助切换规章的委托(切换到对方实际使用的分支版本)。如果是付费委托,受托者只需回答实际收到的问题。
|
||||
附件34.4. 查询资料时,未做任何规定分支可以列出所有分支的资料,其它分支只列出本分支的资料。
|
||||
附件42. 定义:需要以未来的收入换取资源,而且需要与同行争夺。
|
||||
反向的情况,是创始时能一次筹集到足够的资源,可见未来的收入和积累都超过支出。或者需要以未来的收入换取资源,但是不需要竞争即可获得充足资源。
|
||||
附件43. 定义:核心人员凭借职权高估自己的贡献、低估非核心成员的贡献,这样做的综合效果更符合他们的利益。
|
||||
反向的情况,核心人员准确估算包括自己在内的成员贡献,这样做的综合效果更符合他们的利益。
|
||||
|
||||
---
|
||||
|
||||
附件20. readme:
|
||||
附件20.2. readme:
|
||||
- upgradeby应该分内部、外部两种情况定义。
|
||||
附件31. readme:
|
||||
- 以“规章条款”为单位。比如某公司章程有一条:股东会三分之二表决权通过可以修订章程。这条本身就在章程里面,所以也能修订自己。(比如修改为:股东会四分之三表决权通过可以修订章程。)这个条款就比章程的其它条款都高一级。无论怎么组合编集,都不影响这种层级关系。
|
||||
- 比如规章写明A任免B和C,即使在其它文件使用“B是C上级”、“C接受B的指令”这类措辞,本标准下BC平级、都是A下级。A缺席时B讨论C的人选即违规(如果B是章程中有PS标准的账号,会立刻被强制注销财产充公)。
|
||||
- 无法判断时按最坏情况处理,比如因保密制度不能阅读就按未生效、未被执行看待。
|
||||
- 上级规章制定过程可以讨论规章草案下的工作场景,包括制定下级规章的场景。只有特定上级规章导致特定下级规章草案不能产生,引入讨论才有意义。一旦离开上级规章制定程序的时间、地点、人员这些条件就不能提前讨论下级规章,因为这时上级规章(下级规章制定修订程序)还没有生效,不应该暗示自己的内定角色。
|
||||
- 待实现的后续规则:不遵守则由自然人承担。比如一个共同体的上级规章被架空时讨论下级规章,则以该自然人代替共同体承担规章中的权利,比如向执行下级规章的员工发工资。(也就是从共同体剥离,并入个人领域)"
|
||||
附件32. readme:
|
||||
- 顶层权利分配规则肯定在保密制度之上,因此PSMD只讨论公开资料。
|
||||
- 如果某个审议环节从某网址取得一份资料,这份资料从产生、生效、所有使用环节都从这个网址获得。比如是指令,下达指令者应在这个网址发布指令,然后通知接受指令者去阅读。
|
||||
附件33. readme:
|
||||
比如不采用PS标准的共同体,制定规章时以采用PS标准分支下的案例为依据,则自动增加采用PS标准的动议,切换生效之后才能讨论所制定规章。
|
||||
附件34. readme:
|
||||
- 例如:共同体A采用PS标准,共同体B、C没有。当B在上级规章未生效时要讨论下级规章。B向C提出咨询,C收到B发出的原始咨询内容。B向A提出咨询,咨询内容自动转化为“如何在规章中增加PS标准”,A无法收到B发出的原始咨询内容。这条规则主要提醒自我安慰性的求助,向反对者求助就是承认自身行为导致问题无解。
|
||||
- 在父项目,各隔离分支将使用不同记账单位。相同金额不同单位,视为同工同酬。比如采用PS标准的分支使用M为单位,不采用PS标准分支使用N为单位,自由兑换的平衡点是1M兑换10N。一项工作的报酬是5,两个分支账号分别得到5M(可兑换50N)、5N的报酬。
|
||||
|
||||
---
|
||||
|
||||
|
||||
```
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240421140000"></a>
|
||||
## 14:00~14:29
|
||||
|
||||
熟悉国密算法的sm3、sm4接口
|
||||
|
||||
|
||||
在test.js中增加:
|
||||
- 用sm3生成杂凑
|
||||
- 用sm4加密、解密。
|
||||
|
||||
local.3.html无效,仍然没有找到原因。
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240421143000"></a>
|
||||
## 14:30~14:59
|
||||
|
||||
整理1406历史资料
|
||||
|
||||
- D:\huangyg\git\P2Club.Lib\COD部署资料库\案例\huangyg.8005.创业型有限责任公司.md
|
||||
- D:\huangyg\git\7kick\joint.clubs.md
|
||||
- D:\huangyg\git\BEICHU\README.md
|
||||
- D:\huangyg\git\cod.template\LLC\README.md
|
||||
- D:\huangyg\git\com.origin\Food.COOP\food.coop.com.md
|
||||
- D:\huangyg\git\xuemen\S2\2-1.全局模型.md
|
||||
- D:\huangyg\git\xuemen\S2\2-2.核心模型.md
|
||||
- D:\huangyg\git\xuemen\S2\2-3.内务部模型.md
|
||||
|
||||
在基本制度中规定:
|
||||
1. 基本制度未定义事项由某职位现场指挥,现场指挥必须提交通用工单,特殊情况下在24小时内补交。
|
||||
- 为减少合规工作量,每个审议周期内相同种类的通用工单只提交5次,第6次起可以自行汇总,在审议周期结束时提交汇总的通用工单。
|
||||
- 重复性的指挥可以制定具体规章,具体规章的性质与效力都和现场指挥相同。
|
||||
1. 通用工单由决策部门审议,决定:
|
||||
- 将该事项的处理要求纳入基本制度。可能与通用工单相同、相似、相反......一旦纳入基本制度就不再允许现场指挥。
|
||||
- 继续保留在基本制度以外,允许现场指挥。
|
||||
|
||||
效果:
|
||||
1. 可以在无具体规章的情况下启动业务。
|
||||
1. 防止权力失控、寻租。
|
||||
|
||||
1406是决策部门制定基本制度过程的动议,不是完整的共同体模型。
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240421160000"></a>
|
||||
## 16:00~16:59
|
||||
|
||||
编辑1406的metadata,并生成view。
|
||||
|
||||
- 已经通过。
|
||||
|
||||
···
|
||||
|
||||
D:\huangyg\git\PSMD\src>node term commit
|
||||
直接指挥权 48577ce8
|
||||
直接指挥的方式 7506353d
|
||||
直接指挥的归档 260ca049
|
||||
通用工单的审议 c87ec159
|
||||
1406动议 056e71fb
|
||||
../data/term.48577ce8.yaml文件已更新。../data/term.1.yaml可以删除。
|
||||
../data/term.7506353d.yaml文件已更新。../data/term.2.yaml可以删除。
|
||||
../data/term.260ca049.yaml文件已更新。../data/term.3.yaml可以删除。
|
||||
../data/term.c87ec159.yaml文件已更新。../data/term.4.yaml可以删除。
|
||||
path replace:term.1.yaml term.48577ce8.yaml
|
||||
path replace:term.2.yaml term.7506353d.yaml
|
||||
path replace:term.3.yaml term.260ca049.yaml
|
||||
path replace:term.4.yaml term.c87ec159.yaml
|
||||
../data/termset.056e71fb.yaml文件已更新。../data/termset.1.yaml可以删除。
|
||||
|
||||
D:\huangyg\git\PSMD\src>node term termset 056e71fb
|
||||
../view/termset.056e71fb.md文件更新,内容如下:
|
||||
1. 在执行部门内,基本制度和劳动合同未定义的事项由经理直接指挥。
|
||||
2. 直接指挥的方式:
|
||||
- 经理填写通用工单明确事项的处理要求,并交给负责执行的成员;
|
||||
- 经理制订具体规章明确事项的处理要求,并提交给决策部门备案,决策部门签收后具体规章即生效。执行部门成员根据生效的具体规章自行填写通用工单并执行。
|
||||
3. 经理和执行人员都要向决策部门归档通用工单。执行人员应在收到或自行填写通用工单24小时内归档。经理填写的通用工单归档要求是:
|
||||
- 在决策部门的一个审议周期内,每一事项的前3份通用工单,应在出具24小时内向决策部门归档;
|
||||
- 在决策部门的一个审议周期内,同一事项的第4份通用工单起,可以汇总后在审议周期结束前一并归档。
|
||||
4. 决策部门成员应:
|
||||
- 在审议周期的第10天结束前阅读完上一个审议周期结束前归档的通用工单,提交审议报告以及基本制度的修订动议。
|
||||
- 在审议周期的第20天结束前阅读完其他成员提交的审议报告和基本制度的修订动议,提交审议报告。
|
||||
- 在审议周期结束前对基本制度修订动议进行表决。
|
||||
|
||||
---
|
||||
|
||||
1406准确的定位是决策部门的动议套件,可以用作其它模型的附件。
|
||||
2. readme:
|
||||
在使用IT系统时,可修改为经理向系统提交通用工单,并由系统通知负责执行的成员。
|
||||
3. readme:
|
||||
在使用IT系统时,可以由系统实时归档。本条款可以根据情况修订。
|
||||
4. readme:
|
||||
D:\huangyg\git\PSMD\src>node term termset 056e71fb
|
||||
../view/termset.056e71fb.md文件更新,内容如下:
|
||||
1. 在执行部门内,基本制度和劳动合同未定义的事项由经理直接指挥。
|
||||
2. 直接指挥的方式:
|
||||
- 经理填写通用工单明确事项的处理要求,并交给负责执行的成员;
|
||||
- 经理制订具体规章明确事项的处理要求,并提交给决策部门备案,决策部门签收后具体规章即生效。执行部门成员根据生效的具体规章自行填写通用工单并执行。
|
||||
3. 经理和执行人员都要向决策部门归档通用工单。执行人员应在收到或自行填写通用工单24小时内归档。经理填写的通用工单归档要求是:
|
||||
- 在决策部门的一个审议周期内,每一事项的前3份通用工单,应在出具24小时内向决策部门归档;
|
||||
- 在决策部门的一个审议周期内,同一事项的第4份通用工单起,可以汇总后在审议周期结束前一并归档。
|
||||
4. 决策部门成员应:
|
||||
- 在审议周期的第10天结束前阅读完上一个审议周期结束前归档的通用工单,提交审议报告以及基本制度的修订动议。
|
||||
- 在审议周期的第20天结束前阅读完其他成员提交的审议报告和基本制度的修订动议,提交审议报告。
|
||||
- 在审议周期结束前对基本制度修订动议进行表决。
|
||||
|
||||
---
|
||||
|
||||
1406准确的定位是决策部门的动议套件,可以用作其它模型的附件。
|
||||
2. readme:
|
||||
在使用IT系统时,可修改为经理向系统提交通用工单,并由系统通知负责执行的成员。
|
||||
3. readme:
|
||||
在使用IT系统时,可以由系统实时归档。本条款可以根据情况修订。
|
||||
4. readme:
|
||||
- 时间按一月一周期安排,只是范例。可以根据基本制度的完善程度自行调节,从一周到一年都可以考虑。
|
||||
- 基本制度生效后,所规定的工作事项就不再允许经理直接指挥。相应的具体规章也同时失效。
|
||||
- 基本制度的规定,可能与通用工单规定的相同、相似、相反......
|
||||
|
||||
|
||||
---
|
||||
|
||||
···
|
||||
|
|
@ -0,0 +1,466 @@
|
|||
# 20240422
|
||||
|
||||
小结
|
||||
|
||||
<a id="top"></a>
|
||||
根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md),今天绑定模版1。
|
||||
|
||||
| 时间片 | 时长 | 用途 | 手稿 |
|
||||
| --- | --- | --- | --- |
|
||||
| 04:00~04:14 | 15 | 休整 | |
|
||||
| 04:15~05:14 | 60 | 备餐、运动 | |
|
||||
| 05:15~05:59 | 45 | 早餐 | |
|
||||
| 06:00~06:44 | 45 | 会议、自习 | |
|
||||
| 06:45~07:44 | 60 | 休整 | |
|
||||
| 07:45~08:44 | 60 | 静默工作 | [设计时间规划功能](#20240422074500) |
|
||||
| 08:45~09:29 | 45 | 休整 | |
|
||||
| 09:30~10:59 | 90 | 静默工作 | [预设1406动议的范例(针对env、error、knowledge的缺陷)](#20240422093000) |
|
||||
| 11:00~13:59 | 180 | 备餐、午餐午休 | |
|
||||
| 14:00~14:29 | 30 | 静默工作 | [日时间表动态生成](#20240422140000) |
|
||||
| 14:30~14:59 | 30 | 静默工作 | [寻找纯文本方式存放的甘特图](#20240422143000) |
|
||||
| 15:00~15:59 | 60 | 休整 | |
|
||||
| 16:00~16:59 | 60 | 静默工作 | [准备error、env、knowledge metadata,为自动生成termset metada做准备。](#20240422160000) |
|
||||
| 17:00~18:59 | 120 | 晚餐 | |
|
||||
| 19:00~19:59 | 60 | 讨论、整理提交 | |
|
||||
|
||||
模版一采用静默工作方式。
|
||||
希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com),通常安排在后面某天的早餐(5:15~5:59)或会议时间(6:00~6:45)。
|
||||
|
||||
|
||||
---
|
||||
<a id="index"></a>
|
||||
- 07:45 [设计时间规划功能](#20240422074500)
|
||||
- 09:30 [预设1406动议的范例(针对env、error、knowledge的缺陷)](#20240422093000)
|
||||
- 14:00 [日时间表动态生成](#20240422140000)
|
||||
- 14:30 [寻找纯文本方式存放的甘特图](#20240422143000)
|
||||
- 16:00 [准备error、env、knowledge metadata,为自动生成termset metada做准备。](#20240422160000)
|
||||
|
||||
---
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240422074500"></a>
|
||||
## 7:45~8:44
|
||||
|
||||
设计时间规划功能
|
||||
|
||||
### 需求和流程
|
||||
- 本季度的时间片估算,假设前两个月:
|
||||
- 三分之一时间绑定模块二
|
||||
- 有一个模块三
|
||||
- 其余绑定模块一
|
||||
- 不可抗力因素造成缺勤,在第三个月补足。
|
||||
- 划分各任务的子任务和依赖关系、优先级、期限。
|
||||
- 设立里程碑、期限。
|
||||
- 自动排出各时间片的候选子任务,可以人工调整(如果在界面不好实现就手工编辑metadata)
|
||||
- 在日计划绑定模版,自动初始化出draft的markdown和day metadata
|
||||
- 在季度规划中列出后续时间片和候选任务、里程碑,预估完成时间。可以列在日小结后部。
|
||||
|
||||
### 数据结构和算法
|
||||
|
||||
- 增加season metadata:
|
||||
- 工作日天数,默认60天。
|
||||
- 日模版的分布,默认40天模版一,10天模版二,10天模版三(两组)。
|
||||
- 各任务的上期结余,本期预订时间。
|
||||
- 可以用task metadata中表达各任务的子任务和依赖关系,优先级可以增加字段
|
||||
- 优先级可以统一规划,定义,分配给任务。
|
||||
- 任务内部可以分配子任务、里程碑的优先级,期限。
|
||||
- 排序时综合考虑优先级和期限,给出抗风险冗余的总评估。
|
||||
- 通过合同和共同体,对外提供任务的预估完成时间(及不同报价)。
|
||||
- alltask metada和view中,要区分已完成、进行中、未开始的任务,时间分别统计。
|
||||
- 全局的totaltime、treetotaltime不变
|
||||
- 增加seasontime字段,内容是对象。对象属性有上季度结余时间oldbalance、预订时间order、已提取时间checkout、已申请apply、结余时间balance(可转入下一季度)。
|
||||
|
||||
|
||||
下一步:
|
||||
|
||||
- 再斟酌排序算法的实现细节,以免整体架构频繁推倒重构。
|
||||
- 需要的话,先用excel和甘特图内部实践验证。
|
||||
- 一定要内部使用成熟后再对外使用。
|
||||
- season 和 alltask.tasklist.seasomtime 的配合。
|
||||
- season人工编辑,代码不编辑。
|
||||
- alltask代码编辑,人工不编辑。读与写之间有足够时间间隔,以免底层时序混乱。
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240422093000"></a>
|
||||
## 9:30~10:59
|
||||
|
||||
预设1406动议的范例(针对env、error、knowledge的缺陷)
|
||||
|
||||
- 先针对1406动议人工编辑一套范例。
|
||||
- 在error metadata中添加interface字段。
|
||||
- 在knowledge中表达了1406动议可以解决割据问题。
|
||||
|
||||
error.1.yaml
|
||||
|
||||
```
|
||||
|
||||
name: 执行部门陷入割据
|
||||
id: 1
|
||||
interface:
|
||||
entity:
|
||||
1: 共同体
|
||||
2: 上级
|
||||
3: 决策部门
|
||||
4: 执行部门
|
||||
asset:
|
||||
1: 工单
|
||||
2: 日志
|
||||
term:
|
||||
id: name
|
||||
event:
|
||||
id:
|
||||
text: |
|
||||
出现以下情况之一:
|
||||
- <entity.3>未界定<entity.4>工作的合规性要求。
|
||||
- <entity.3>界定了<entity.4>工作的合规性要求。
|
||||
- <entity.4>成员对指令不进行合规检查,即使不合规也执行。
|
||||
- <entity.4>成员及下达指令者未按要求填写和提交表单,比如<asset.1>、<asset.2>。
|
||||
readme: |
|
||||
- <entity.2>的指令包括对更早指令的掩盖,通过互相包庇产生系统性的对抗。
|
||||
- <entity.1>曾经对<entity.2>违约,以一定范围内的割据作为抵押物。这是历史上资源紧缺,无法兑现约定报酬的后遗症。
|
||||
- 把一定范围内的割据作为违约抵押物的情况,解除割据应该同时处理历史欠账。在<entity.1>设立阶段,就要确定是否符合<term.1>,如果符合应该在设立时解决。
|
||||
|
||||
```
|
||||
|
||||
env.1.yaml
|
||||
|
||||
```
|
||||
name: 原始状态-1
|
||||
id: 1
|
||||
error:
|
||||
- id: 1
|
||||
readme: |
|
||||
创始团队缺乏经验,使用的外来模版遗漏了结局问题的章节。
|
||||
```
|
||||
|
||||
knowledge.1.yaml
|
||||
|
||||
```
|
||||
name: 1406解决割据问题
|
||||
id: 1
|
||||
envid: 1
|
||||
termset:
|
||||
- id: 056e71fb
|
||||
error:
|
||||
- id: 1
|
||||
percent: 50
|
||||
text: |
|
||||
- 1406动议可以消除已出现的割据问题。
|
||||
- 如果是因为资源问题未解决,欠付报酬而以一定范围割据作为抵押物,今后还会出现新的割据问题。这种情况需要同时处理历史欠账,并且根除资源问题。
|
||||
readme: |
|
||||
```
|
||||
|
||||
- 发现的问题:
|
||||
- 难以自动识别割据问题、资源问题,这依赖人工核实。因此写入条款,在内部成员之间形成制约,才能触发既定条款,并在内部人员操作时提供后续动议。数据结构应该服务于这个流程,而不是外部人员或者代码直接干预。
|
||||
- 难以表达解决割据问题之前无效的条款。
|
||||
|
||||
- 目标条款: 如果符合附件44(执行部门陷入割据)的情况,则附件1406(1406动议)自动生效。
|
||||
- 增加一个termset:
|
||||
```
|
||||
name: 预设1406动议
|
||||
id: 1
|
||||
level: 1
|
||||
interface:
|
||||
entity:
|
||||
e1: 共同体
|
||||
e2: 经理
|
||||
e3: 决策部门
|
||||
e4: 执行部门
|
||||
e5: 下达指令者
|
||||
asset:
|
||||
a1: 通用工单
|
||||
a2: 审议报告
|
||||
a3: 工作日志
|
||||
term:
|
||||
'1': 基本制度
|
||||
'2': 具体规章
|
||||
'3': 劳动合同
|
||||
44: 附件44
|
||||
1406: 附件1406
|
||||
item:
|
||||
- sortid: 1
|
||||
type: term
|
||||
id: 2
|
||||
map:
|
||||
term:
|
||||
1: 44
|
||||
2: 1406
|
||||
path: term.2.yaml
|
||||
- sortid: 附件44
|
||||
type: term
|
||||
id: 1
|
||||
map:
|
||||
entity:
|
||||
1: e1
|
||||
2: e5
|
||||
3: e3
|
||||
4: e4
|
||||
asset:
|
||||
1: a1
|
||||
path: term.1.yaml
|
||||
- sortid: 附件1406
|
||||
type: termset
|
||||
id: 056e71fb
|
||||
map:
|
||||
entity:
|
||||
'1': e2
|
||||
'2': e4
|
||||
'3': e3
|
||||
term:
|
||||
'1': 1
|
||||
'2': 2
|
||||
'3': 3
|
||||
asset:
|
||||
'1': a1
|
||||
'2': a2
|
||||
path: termset.056e71fb.yaml
|
||||
```
|
||||
|
||||
- commit metadata并且生成view.
|
||||
|
||||
```
|
||||
|
||||
D:\huangyg\git\PSMD\src>node term commit
|
||||
执行部门陷入割据 0ccddb29
|
||||
如果割据就启用1406 583d6243
|
||||
预设1406动议 b3124d50
|
||||
../data/term.0ccddb29.yaml文件已更新。../data/term.1.yaml可以删除。
|
||||
../data/term.583d6243.yaml文件已更新。../data/term.2.yaml可以删除。
|
||||
path replace:term.2.yaml term.583d6243.yaml
|
||||
path replace:term.1.yaml term.0ccddb29.yaml
|
||||
旧文件:../data/termset.1.yaml中itemset:2的id:056e71fb未能替换,请人工检查。
|
||||
../data/termset.b3124d50.yaml文件已更新。../data/termset.1.yaml可以删除。
|
||||
|
||||
D:\huangyg\git\PSMD\src>node term termset b3124d50
|
||||
../view/termset.b3124d50.md文件更新,内容如下:
|
||||
1. 如果符合附件44的情况,则附件1406自动生效。
|
||||
附件44. 出现以下情况之一:
|
||||
- 决策部门未界定执行部门工作的合规性要求。
|
||||
- 决策部门界定了执行部门工作的合规性要求。
|
||||
- 执行部门成员对指令不进行合规检查,即使不合规也执行。
|
||||
- 执行部门成员及下达指令者未按要求填写和提交表单,比如通用工单、日志。
|
||||
附件1406.
|
||||
附件1406.1. 在执行部门内,基本制度和劳动合同未定义的事项由经理直接指挥。
|
||||
附件1406.2. 直接指挥的方式:
|
||||
- 经理填写通用工单明确事项的处理要求,并交给负责执行的成员;
|
||||
- 经理制订具体规章明确事项的处理要求,并提交给决策部门备案,决策部门签收后具体规章即生效。执行部门成员根据生效的具体规章自行填写通用工单并执行。
|
||||
附件1406.3. 经理和执行人员都要向决策部门归档通用工单。执行人员应在收到或自行填写通用工单24小时内归档。经理填写的通用工单归档要求是:
|
||||
- 在决策部门的一个审议周期内,每一事项的前3份通用工单,应在出具24小时内向决策部门归档;
|
||||
- 在决策部门的一个审议周期内,同一事项的第4份通用工单起,可以汇总后在审议周期结束前一并归档。
|
||||
附件1406.4. 决策部门成员应:
|
||||
- 在审议周期的第10天结束前阅读完上一个审议周期结束前归档的通用工单,提交审议报告以及基本制度的修订动议。
|
||||
- 在审议周期的第20天结束前阅读完其他成员提交的审议报告和基本制度的修订动议,提交审议报告。
|
||||
- 在审议周期结束前对基本制度修订动议进行表决。
|
||||
|
||||
---
|
||||
|
||||
附件44. readme:
|
||||
- 下达指令者的指令包括对更早指令的掩盖,通过互相包庇产生系统性的对抗。
|
||||
- 共同体曾经对下达指令者违约,以一定范围内的割据作为抵押物。这是历史上资源紧缺,无法兑现约定报酬的后遗症。
|
||||
- 把一定范围内的割据作为违约抵押物的情况,解除割据应该同时处理历史欠账。在共同体设立阶段,就要确定是否符合基本制度,如果符合应该在设立时解决。
|
||||
附件1406. readme:
|
||||
1406准确的定位是决策部门的动议套件,可以用作其它模型的附件。
|
||||
附件1406.2. readme:
|
||||
在使用IT系统时,可修改为经理向系统提交通用工单,并由系统通知负责执行的成员。
|
||||
附件1406.3. readme:
|
||||
- 如果出现重大失误,决策部门可能召开临时会议干预。所以要求及时归档。
|
||||
- 在使用IT系统时,可以由系统实时归档。本条款可以根据情况修订。
|
||||
附件1406.4. readme:
|
||||
- 时间按一月一周期安排,只是范例。可以根据基本制度的完善程度自行调节,从一周到一年都可以考虑。
|
||||
- 基本制度生效后,所规定的工作事项就不再允许经理直接指挥。相应的具体规章也同时失效。
|
||||
- 基本制度的规定,可能与通用工单规定的相同、相似、相反......
|
||||
|
||||
---
|
||||
|
||||
```
|
||||
|
||||
下一步:
|
||||
|
||||
- termset metadata中,interface中的term还是映射到字符串,而不是同一个termset.item下的sortid。虽然可以人工保持同名,但还不是真正互通。也许可以在代码内把它们衔接起来:
|
||||
- termset.item.map中可以映射到同级sortid:
|
||||
- 优先映射到sortid,找不到的才映射到interface。
|
||||
- 分别标注id: {sortid: id} or id: {interfaceid: id}
|
||||
- 统一映射到interface,其中部分与sortid同名。(有违interface字段本意:对外暴露的接口)
|
||||
- 如果只是定义error-termset-error关系:termset能解决error2,但是只在error1解决之后有效。那么在termset中添加两个字段就可以了。env-termset-error怎么能表达更广泛的条件组合。它们结合人工选择切入点(or锋面),可以自动生成定制的入门目录。
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240422140000"></a>
|
||||
## 14:00~14:29
|
||||
|
||||
日时间表动态生成
|
||||
|
||||
- 已完成日计划中的时间表。
|
||||
- 已完成日小结中的时间表。
|
||||
|
||||
|
||||
下一步:
|
||||
|
||||
- 整理重复代码,需要时调整数据结构。
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240422143000"></a>
|
||||
## 14:30~14:59
|
||||
|
||||
寻找纯文本方式存放的甘特图
|
||||
|
||||
- https://frappe.io/gantt
|
||||
|
||||
~~~
|
||||
|
||||
var tasks = [
|
||||
{
|
||||
id: 'Task 1',
|
||||
name: 'Redesign website',
|
||||
start: '2016-12-28',
|
||||
end: '2016-12-31',
|
||||
progress: 20,
|
||||
dependencies: 'Task 2, Task 3',
|
||||
custom_class: 'bar-milestone' // optional
|
||||
},
|
||||
...
|
||||
]
|
||||
var gantt = new Gantt("#gantt", tasks);
|
||||
|
||||
~~~
|
||||
|
||||
- https://www.ganttproject.biz/ 自定义的*.gan是xml文件。也可以导出导入csv文件,文档没有找到,csv格式历史上有一些bug。
|
||||
|
||||
```
|
||||
<?xml version="1.0" encoding="UTF-8"?><project name="Untitled Gantt Project" company="" webLink="http://" view-date="2024-04-20" view-index="0" gantt-divider-location="351" resource-divider-location="300" version="3.3.3307" locale="zh_CN">
|
||||
<description/>
|
||||
<view zooming-state="default:2" id="gantt-chart">
|
||||
<field id="tpd3" name="名称" width="200" order="0"/>
|
||||
<field id="tpd4" name="开始日期" width="75" order="1"/>
|
||||
<field id="tpd5" name="结束日期" width="75" order="2"/>
|
||||
<field id="tpd15" name="备注" width="20" order="3"/>
|
||||
<option id="filter.completedTasks" value="false"/>
|
||||
<option id="filter.dueTodayTasks" value="false"/>
|
||||
<option id="filter.overdueTasks" value="false"/>
|
||||
<option id="filter.inProgressTodayTasks" value="false"/>
|
||||
</view>
|
||||
<view id="resource-table">
|
||||
<field id="0" name="名称" width="210" order="0"/>
|
||||
<field id="1" name="默认角色" width="86" order="1"/>
|
||||
</view>
|
||||
<!-- -->
|
||||
<calendars>
|
||||
<day-types>
|
||||
<day-type id="0"/>
|
||||
<day-type id="1"/>
|
||||
<default-week id="1" name="default" sun="1" mon="0" tue="0" wed="0" thu="0" fri="0" sat="1"/>
|
||||
<only-show-weekends value="false"/>
|
||||
<overriden-day-types/>
|
||||
<days/>
|
||||
</day-types>
|
||||
</calendars>
|
||||
<tasks empty-milestones="true">
|
||||
<taskproperties>
|
||||
<taskproperty id="tpd0" name="type" type="default" valuetype="icon"/>
|
||||
<taskproperty id="tpd1" name="priority" type="default" valuetype="icon"/>
|
||||
<taskproperty id="tpd2" name="info" type="default" valuetype="icon"/>
|
||||
<taskproperty id="tpd3" name="name" type="default" valuetype="text"/>
|
||||
<taskproperty id="tpd4" name="begindate" type="default" valuetype="date"/>
|
||||
<taskproperty id="tpd5" name="enddate" type="default" valuetype="date"/>
|
||||
<taskproperty id="tpd6" name="duration" type="default" valuetype="int"/>
|
||||
<taskproperty id="tpd7" name="completion" type="default" valuetype="int"/>
|
||||
<taskproperty id="tpd8" name="coordinator" type="default" valuetype="text"/>
|
||||
<taskproperty id="tpd9" name="predecessorsr" type="default" valuetype="text"/>
|
||||
</taskproperties>
|
||||
<task id="0" uid="cfb128ba2d4a4fd2861da77002fb8f4b" name="raw" meeting="false" start="2024-04-22" duration="1" complete="0" expand="true"/>
|
||||
<task id="1" uid="3263d29e698d4b44bfcfca068b617d48" name="ego" meeting="false" start="2024-04-22" duration="1" complete="0" expand="true"/>
|
||||
<task id="2" uid="99f82a958e994c069bb2489ae0304c65" name="PSMD" meeting="false" start="2024-04-23" duration="7" complete="0" expand="true">
|
||||
<task id="3" uid="062dfe42d33443eba053aa99d62aaf51" name="modeling" meeting="false" start="2024-04-23" duration="2" complete="0" expand="true">
|
||||
<depend id="5" type="2" difference="0" hardness="Strong"/>
|
||||
</task>
|
||||
<task id="5" uid="e5c7a53e088b47028459b68e451ae18e" name="deploy" meeting="false" start="2024-04-25" duration="5" complete="0" expand="true"/>
|
||||
</task>
|
||||
<task id="6" uid="441e7f0c8dc64c5593937f732db8832e" name="learn" meeting="false" start="2024-04-22" duration="1" complete="0" expand="true">
|
||||
<task id="7" uid="9998dbce7d5a40ab921264a116103568" name="js" meeting="false" start="2024-04-22" duration="1" complete="0" expand="true"/>
|
||||
</task>
|
||||
</tasks>
|
||||
<resources/>
|
||||
<allocations/>
|
||||
<vacations/>
|
||||
<previous/>
|
||||
<roles roleset-name="Default"/>
|
||||
</project>
|
||||
|
||||
```
|
||||
|
||||
csv范例:
|
||||
|
||||
```
|
||||
"序号",名称,开始日期,结束日期,持续,完成,成本,协调者,前置任务,大纲编号,资源,Assignments,新任务,备注,网页连接,备注
|
||||
0,raw,2024/4/22,2024/4/22,1,0,0,,,1,,,,,
|
||||
1,ego,2024/4/22,2024/4/22,1,0,0,,,2,,,,,
|
||||
2,PSMD,2024/4/23,2024/5/1,7,0,0,,,3,,,"#000000",,
|
||||
3," modeling",2024/4/23,2024/4/24,2,0,0,,,3.1,,,,,
|
||||
5," deploy",2024/4/25,2024/5/1,5,0,0,,3,3.2,,,,,
|
||||
6,learn,2024/4/22,2024/4/22,1,0,0,,,4,,,"#000000",,
|
||||
7," js",2024/4/22,2024/4/22,1,0,0,,,4.1,,,,,
|
||||
|
||||
出错了 (
|
||||
The header contains a duplicate entry: '备注' in [序号, 名称, 开始日期, 结束日期, 持续, 完成, 成本, 协调者, 前置任务, 大纲编号, 资源, Assignments, 新任务, 备注, 网页连接, 备注]
|
||||
查看日志
|
||||
)
|
||||
```
|
||||
|
||||
|
||||
- https://github.com/DHTMLX/gantt
|
||||
|
||||
```
|
||||
gantt.config.date_format = "%Y-%m-%d %H:%i";
|
||||
gantt.init("gantt_here");
|
||||
gantt.parse({
|
||||
data: [
|
||||
{id: 1, text: "Project #1", start_date: null, duration: null, parent:0, progress: 0, open: true},
|
||||
{id: 2, text: "Task #1", start_date: "2019-08-01 00:00", duration:5, parent:1, progress: 1},
|
||||
{id: 3, text: "Task #2", start_date: "2019-08-06 00:00", duration:2, parent:1, progress: 0.5},
|
||||
{id: 4, text: "Task #3", start_date: null, duration: null, parent:1, progress: 0.8, open: true},
|
||||
{id: 5, text: "Task #3.1", start_date: "2019-08-09 00:00", duration:2, parent:4, progress: 0.2},
|
||||
{id: 6, text: "Task #3.2", start_date: "2019-08-11 00:00", duration:1, parent:4, progress: 0}
|
||||
],
|
||||
links:[
|
||||
{id:1, source:2, target:3, type:"0"},
|
||||
{id:2, source:3, target:4, type:"0"},
|
||||
{id:3, source:5, target:6, type:"0"}
|
||||
]
|
||||
});
|
||||
|
||||
```
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240422160000"></a>
|
||||
## 16:00~16:59
|
||||
准备error、env、knowledge metadata,为自动生成termset metada做准备。
|
||||
|
||||
继续使用上午9:30的分析
|
||||
|
||||
### 流程
|
||||
1. 委托者自述问题,受托者评估委托者自身问题,以及委托者自述的问题,结合两者编辑metadata文件。
|
||||
- 成熟后,委托者可以通过通用的入门目录,自行操作产生metadata文件。
|
||||
1. 受托者提交metadata文件,由代码检索后产生解决方案的termset metadata,再进一步产生termset view。过程中受托者可以手工编辑termset metadata。
|
||||
- 可以设置模版文件,以产生不同风格的termset的metadata和view。
|
||||
- 成熟后,委托者可以自行操作产生termset view。
|
||||
|
||||
### 需求及架构、数据结构
|
||||
1. 委托者自身问题,以及委托者自述的问题,都是error和term(set)的组合。因此env metadata还是需要的。
|
||||
1. knowledge是引用env,还是自带error和term(set)组合:应该自带。
|
||||
1. 可能要表达的knowledge:
|
||||
- 某termset能解决error1,但是只在error2解决之后有效。
|
||||
- 分解成两个knowledge,分别表达error2解决和未解决的env,检索非常不方便。
|
||||
- 专门设置必须先解决的前置error字段,表达这则knowledge更直观,也更容易检索。
|
||||
- 某termset能解决error1,但是只在error2、error3、erro4解决之后才有效。
|
||||
- 前置error字段是个数组。
|
||||
1. 参考甘特图的字段名:
|
||||
- dependencies
|
||||
- depend
|
||||
|
||||
完成error.1 error.2 env.1 knowledge.1 knoeledge.2 metadata,需要引用error.cde3c3e2。
|
||||
|
||||
下一步:
|
||||
继续完成这批metadata生成termset metadata的代码范例。
|
||||
|
|
@ -0,0 +1,219 @@
|
|||
# 20240423
|
||||
|
||||
小结
|
||||
|
||||
<a id="top"></a>
|
||||
根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md),今天绑定模版1。
|
||||
|
||||
| 时间片 | 时长 | 用途 | 手稿 |
|
||||
| --- | --- | --- | --- |
|
||||
| 04:00~04:14 | 15 | 休整 | |
|
||||
| 04:15~05:14 | 60 | 备餐、运动 | |
|
||||
| 05:15~05:59 | 45 | 早餐 | |
|
||||
| 06:00~06:44 | 45 | 会议、自习 | |
|
||||
| 06:45~07:44 | 60 | 休整 | |
|
||||
| 07:45~08:44 | 60 | 静默工作 | [设计新的dayplan metadata](#20240423074500) |
|
||||
| 08:45~09:29 | 45 | 休整 | |
|
||||
| 09:30~10:59 | 90 | 静默工作 | [term commit中添加error和knowledge](#20240423093000) |
|
||||
| 11:00~13:59 | 180 | 备餐、午餐午休 | |
|
||||
| 14:00~14:29 | 30 | 静默工作 | [选定一种gantt工具,能够从数据上和task metadata互通。](#20240423140000) |
|
||||
| 14:30~14:59 | 30 | 静默工作 | [国密算法网页端debug](#20240423143000) |
|
||||
| 15:00~15:59 | 60 | 休整 | |
|
||||
| 16:00~16:59 | 60 | 静默工作 | [设计season plan的流程和数据结构](#20240423160000) |
|
||||
| 17:00~18:59 | 120 | 晚餐 | |
|
||||
| 19:00~19:59 | 60 | 讨论、整理提交 | |
|
||||
|
||||
模版一采用静默工作方式。
|
||||
希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com),通常安排在后面某天的早餐(5:15~5:59)或会议时间(6:00~6:45)。
|
||||
|
||||
|
||||
---
|
||||
<a id="index"></a>
|
||||
- 07:45 [设计新的dayplan metadata](#20240423074500)
|
||||
- 09:30 [term commit中添加error和knowledge](#20240423093000)
|
||||
- 14:00 [选定一种gantt工具,能够从数据上和task metadata互通。](#20240423140000)
|
||||
- 14:30 [国密算法网页端debug](#20240423143000)
|
||||
- 16:00 [设计season plan的流程和数据结构](#20240423160000)
|
||||
|
||||
---
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240423074500"></a>
|
||||
## 7:45~8:44
|
||||
|
||||
设计新的dayplan metadata
|
||||
|
||||
- 以醒来时间为起点排日计划
|
||||
- 休整时间片有一定弹性
|
||||
- 以实际始末时间整理日小结
|
||||
- 理顺全流程的变量、文件名、文件夹名,方便维护。
|
||||
|
||||
### 数据结构
|
||||
|
||||
#### plan metadata
|
||||
|
||||
- 方案一
|
||||
- dayplan增加type字段。设fix和float两种,对应固定时间和跟随起床时间浮动。将来可能增加针对不同时间点浮动。
|
||||
- time字段下,fix类dayplan有开始时间和时长,float类只有时长。
|
||||
- 方案二
|
||||
- dayplan的time字段下,每个时间片多种类型:
|
||||
- 有固定开始时间和固定时长,可以推算出固定结束时间。
|
||||
- 只有固定时长,在上一个时间片的结束时间加1为开始。
|
||||
- 有固定开始时间,有计划时长,计划结束时间。
|
||||
- 有固定结束时间,有计划时长,计划开始时间。
|
||||
- 只有计划时长:
|
||||
- 在上一个时间片结束时间加1为开始。
|
||||
- 如果下一个时间片有固定开始时间,则以它减1位为结束。
|
||||
- 如果下一时间片没有固定开始时间,则以计划时长计算结束时间。
|
||||
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240423093000"></a>
|
||||
## 9:30~10:59
|
||||
term commit中添加error和knowledge
|
||||
|
||||
已完成。
|
||||
```
|
||||
D:\huangyg\git\PSMD\src>node term commit
|
||||
commit error.1.yaml
|
||||
执行部门陷入割据 0ccddb29
|
||||
commit error.2.yaml
|
||||
无法有效分配未来收入 48291d8c
|
||||
commit knowledge.1.yaml
|
||||
1406解决割据问题 3b7582cd
|
||||
commit knowledge.2.yaml
|
||||
1609解决资源问题 d8a0602f
|
||||
commit term.1.yaml
|
||||
执行部门陷入割据 0ccddb29
|
||||
commit term.2.yaml
|
||||
如果割据就启用1406 583d6243
|
||||
commit termset.1.yaml
|
||||
预设1406动议 b3124d50
|
||||
../data/term.0ccddb29.yaml文件已更新。../data/term.1.yaml可以删除。
|
||||
../data/term.583d6243.yaml文件已更新。../data/term.2.yaml可以删除。
|
||||
../data/error.0ccddb29.yaml文件已更新。../data/error.1.yaml可以删除。
|
||||
../data/error.48291d8c.yaml文件已更新。../data/error.2.yaml可以删除。
|
||||
path replace:term.2.yaml term.583d6243.yaml
|
||||
旧文件:../data/termset.1.yaml中item:1的id:cb4ab0e9未能替换,请人工检查。
|
||||
path replace:term.1.yaml term.0ccddb29.yaml
|
||||
旧文件:../data/termset.1.yaml中itemset:3的id:056e71fb未能替换,请人工检查。
|
||||
../data/termset.b3124d50.yaml文件已更新。../data/termset.1.yaml可以删除。
|
||||
knowledge env replace. type: errorid: 1 -> 0ccddb29
|
||||
knowledge depend replace. type: errorid: 2 -> 48291d8c
|
||||
旧文件:../data/knowledge.1.yaml中termset字段, id:056e71fb未能替换,请人工检查。
|
||||
knowledge error replace. id: 1 -> 0ccddb29
|
||||
../data/knowledge.3b7582cd.yaml文件已更新。../data/knowledge.1.yaml可以删除。
|
||||
knowledge env replace. type: errorid: 2 -> 48291d8c
|
||||
旧文件:../data/knowledge.2.yaml中depend字段, type:error的id:cde3c3e2未能替换,请人工检查。
|
||||
旧文件:../data/knowledge.2.yaml中term字段, id:5b4e0597未能替换,请人工检查。
|
||||
knowledge error replace. id: 2 -> 48291d8c
|
||||
../data/knowledge.d8a0602f.yaml文件已更新。../data/knowledge.2.yaml可以删除。
|
||||
```
|
||||
|
||||
下一步:
|
||||
|
||||
- error、knowledge metadata -> termset medata -> termset view
|
||||
- 增加一种参数规格: node term commit filename 提交单个手稿,沿着引用关系涉及的手稿文件也都提交。
|
||||
- 同时把旧的commit增强一下:所有短于8字符id的都提交,以便起草大合同手稿。
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240423140000"></a>
|
||||
## 14:00~14:29
|
||||
选定一种gantt工具,能够从数据上和task metadata互通。
|
||||
|
||||
### https://github.com/frappe/gantt
|
||||
|
||||
- 可以显示、拖拽改变始末时间
|
||||
- 可以设置事件响应:点击、改变始末时间时调用、改变完成进度、改变显示模式
|
||||
- 只有一种depend关系,没有明确是哪种。
|
||||
- 设置父子关系,改变depend关系,没有适当接口。
|
||||
|
||||
### ganttproject
|
||||
|
||||
- /task/task的meeting 是里程碑,true是,flase不是。
|
||||
- /task/task的expand 是展开子任务,true展开,false收缩。
|
||||
- /tasks/task/depend的type有4种:
|
||||
- 1:ego开始-deploy开始 在/ego/depend.type = 1 在图中显示在deploy属性下
|
||||
- 2:modeling结束-deploy开始 在/modeling/depend.type = 2 在图中显示在deploy属性下
|
||||
- 3:js结束-modeling结束 在/js/depend.type = 3 在图中显示在modling属性下
|
||||
- 4:raw开始-ego结束 在/raw/depend.type = 4 在图中显示在ego属性下
|
||||
- /tasks/task/depend的difference是延迟时间
|
||||
- /tasks/task/depend的hardness是箭头显示类型:
|
||||
- Strong:实线
|
||||
- Rubber:虚线
|
||||
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240423143000"></a>
|
||||
## 14:30~14:59
|
||||
国密算法网页端debug
|
||||
|
||||
- 是大小写问题:范例是publicKey,local.3.html是pubkey。改写是没有改变大写K。
|
||||
- local.3.html中的加密、解密、签名、验证全部通过。
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240423160000"></a>
|
||||
## 16:00~16:59
|
||||
设计season plan的流程和数据结构
|
||||
|
||||
|
||||
### 流程
|
||||
|
||||
- 季度规划
|
||||
- 按已生效合同整理工作结果和完成期限,安排任务时间。
|
||||
- 将剩余时间分配给长期任务。推算各项目的预算案。
|
||||
- 整理任务之间的依赖关系。
|
||||
- 日计划
|
||||
- 根据身体状况选择时间模版,初始化,生成draft metadata文件
|
||||
- 各时间片的候选任务排序
|
||||
- 可以有多套排序权重
|
||||
- 已生效合同工作计划的计划、已用、剩余时间。
|
||||
- 各项目季度预算、初步结算。
|
||||
- 调整确定后生成正式日计划和draft空文件
|
||||
- 日小结
|
||||
- 整理draft文件
|
||||
- 生成正式日小结
|
||||
- 已生效合同的计划、已用、剩余时间
|
||||
- 季度结算:根据实际使用的资源完成项目件结算。
|
||||
|
||||
### 数据结构
|
||||
|
||||
- season metadata in/ego/task (-> /ego/data)
|
||||
~~~
|
||||
year:
|
||||
season:
|
||||
dayplan:
|
||||
time:
|
||||
in:
|
||||
1: 40
|
||||
2: 10
|
||||
3: 2
|
||||
// dayplanid: amount
|
||||
agreement:
|
||||
- name: contract1.deploy
|
||||
deadline: 2024-06-13 18:00:00
|
||||
budget:
|
||||
90: 2
|
||||
60: 8
|
||||
30: 4
|
||||
- name: contract2.modeling
|
||||
deadline: 2024-05-16 12:00:00
|
||||
budget:
|
||||
90: 3
|
||||
60: 2
|
||||
30: 2
|
||||
alloc:
|
||||
taskid1:
|
||||
90: 1
|
||||
60: 3
|
||||
30: 2
|
||||
taskid2:
|
||||
90: 4
|
||||
60: 4
|
||||
30: 1
|
||||
~~~
|
|
@ -0,0 +1,269 @@
|
|||
# 20240424
|
||||
|
||||
小结
|
||||
|
||||
<a id="top"></a>
|
||||
根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md),今天绑定模版2。
|
||||
|
||||
| 时间片 | 时长 | 用途 | 手稿 |
|
||||
| --- | --- | --- | --- |
|
||||
| 04:00~04:14 | 15 | 休整 | |
|
||||
| 04:15~05:14 | 60 | 备餐、运动 | |
|
||||
| 05:15~05:59 | 45 | 早餐 | |
|
||||
| 06:00~06:44 | 45 | 会议、自习 | |
|
||||
| 06:45~07:44 | 60 | 休整 | |
|
||||
| 07:45~10:59 | 195 | 工作 | [error + knowledge metadata -> view](#20240424074500) |
|
||||
| 11:00~13:59 | 180 | 备餐、午餐午休 | |
|
||||
| 14:00~15:29 | 90 | 工作 | [整理基本概念,准备梳理各git库的log、data、src、view](#20240424140000) |
|
||||
| 15:30~15:59 | 30 | 休整 | |
|
||||
| 16:00~16:59 | 60 | 工作 | [整理个人领域模型和共同体模型的关联](#20240424160000) |
|
||||
| 17:00~18:59 | 120 | 晚餐 | |
|
||||
| 19:00~19:59 | 60 | 讨论、整理提交 | |
|
||||
|
||||
工作的同时可以在线讨论。
|
||||
|
||||
|
||||
---
|
||||
<a id="index"></a>
|
||||
- 07:45 [error + knowledge metadata -> view](#20240424074500)
|
||||
- 14:00 [整理基本概念,准备梳理各git库的log、data、src、view](#20240424140000)
|
||||
- 16:00 [整理个人领域模型和共同体模型的关联](#20240424160000)
|
||||
|
||||
---
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240424074500"></a>
|
||||
## 7:45~10:59
|
||||
|
||||
error + knowledge metadata -> view
|
||||
|
||||
- 实现makeitemview(),以前只做了makeitermtext()。
|
||||
```
|
||||
D:\huangyg\git\PSMD\src>node term term 260ca049
|
||||
../view/term.260ca049.md文件更新,内容如下:
|
||||
条款 260ca049 正文:
|
||||
经理和执行人员都要向决策部门归档通用工单。执行人员应在收到或自行填写通用工单24小时内归档。经理填写的通用工单归档要求是:
|
||||
- 在决策部门的一个审议周期内,每一事项的前3份通用工单,应在出具24小时内向决策部门归档;
|
||||
- 在决策部门的一个审议周期内,同一事项的第4份通用工单起,可以汇总后在审议周期结束前一并归档。
|
||||
|
||||
---
|
||||
条款 260ca049 readme:
|
||||
- 如果出现重大失误,决策部门可能召开临时会议干预。所以要求及时归档。
|
||||
- 在使用IT系统时,可以由系统实时归档。本条款可以根据情况修订。
|
||||
```
|
||||
|
||||
- 需要在knowledge metadata中加入interface和二级map字段?暂时不需要,因为knowledge不是对外展示的,而是自动组装termset用的,使用各源头matedata自身的interface就可以。
|
||||
- 实现makeerrortext、makeerrorview()。
|
||||
```
|
||||
D:\huangyg\git\PSMD\src>node term error 0ccddb29
|
||||
../view/error.0ccddb29.md文件更新,内容如下:
|
||||
问题 0ccddb29 正文:
|
||||
出现以下情况之一:
|
||||
- 决策部门未界定执行部门工作的合规性要求。
|
||||
- 决策部门界定了执行部门工作的合规性要求。
|
||||
- 执行部门成员对指令不进行合规检查,即使不合规也执行。
|
||||
- 执行部门成员及下达指令者未按要求填写和提交表单,比如工单、日志。
|
||||
|
||||
---
|
||||
问题 0ccddb29 readme:
|
||||
- 下达指令者的指令包括对更早指令的掩盖,通过互相包庇产生系统性的对抗。
|
||||
- 共同体曾经对下达指令者违约,以一定范围内的割据作为抵押物。这是历史上资源紧缺,无法兑现约定报酬的后遗症。
|
||||
- 把一定范围内的割据作为违约抵押物的情况,解除割据应该同时处理历史欠账。在共同体设立阶段,就要确定是否符合<term.1>,如果符合应该在设立时解决。
|
||||
```
|
||||
|
||||
- 由于knowledge用于自动组装termset,因此不需要创建view。先构造error-knowledge-error网络,构造过程先发提示:
|
||||
```
|
||||
D:\huangyg\git\PSMD\src>node term error 0ccddb29
|
||||
enter makeerrornet: 0ccddb29 已查找的knowledge:
|
||||
{}
|
||||
|
||||
search knowledge: 1
|
||||
search knowledge: 2
|
||||
search knowledge: 3b7582cd
|
||||
发现knowledge 3b7582cd 可以解决 error 0ccddb29 有效率: 50
|
||||
knowledge 3b7582cd 生效有先决条件,先解决error:
|
||||
error:48291d8c
|
||||
enter makeerrornet: 48291d8c 已查找的knowledge:
|
||||
3b7582cd: true
|
||||
|
||||
search knowledge: 1
|
||||
search knowledge: 2
|
||||
search knowledge: 3b7582cd
|
||||
search knowledge: d8a0602f
|
||||
发现knowledge d8a0602f 可以解决 error 48291d8c 有效率: 60
|
||||
knowledge d8a0602f 生效有先决条件,先解决error:
|
||||
error:cde3c3e2
|
||||
enter makeerrornet: cde3c3e2 已查找的knowledge:
|
||||
3b7582cd: true
|
||||
d8a0602f: true
|
||||
|
||||
search knowledge: 1
|
||||
search knowledge: 2
|
||||
search knowledge: 3b7582cd
|
||||
search knowledge: d8a0602f
|
||||
search knowledge: d8a0602f
|
||||
../view/error.0ccddb29.md文件更新,内容如下:
|
||||
问题 0ccddb29 正文:
|
||||
出现以下情况之一:
|
||||
- 决策部门未界定执行部门工作的合规性要求。
|
||||
- 决策部门界定了执行部门工作的合规性要求。
|
||||
- 执行部门成员对指令不进行合规检查,即使不合规也执行。
|
||||
- 执行部门成员及下达指令者未按要求填写和提交表单,比如工单、日志。
|
||||
|
||||
---
|
||||
问题 0ccddb29 readme:
|
||||
- 继续构造error-knowledge-error网络,生成提示段落加入到error view中。
|
||||
- 下达指令者的指令包括对更早指令的掩盖,通过互相包庇产生系统性的对抗。
|
||||
- 共同体曾经对下达指令者违约,以一定范围内的割据作为抵押物。这是历史上资源紧缺,无法兑现约定报酬的后遗症。
|
||||
- 把一定范围内的割据作为违约抵押物的情况,解除割据应该同时处理历史欠账。在共同体设立阶段,就要确定是否符合<term.1>,如果符合应该在设立时解决。
|
||||
```
|
||||
|
||||
下一步:
|
||||
|
||||
- 成员的个人领域模型纳入env。
|
||||
- 先整理个人模型和共同体模型的对应关系。
|
||||
- 准备sql和nosql版本
|
||||
- error + allknowledge metadata -> 针对某总env的termset metadata
|
||||
- 委托者构造env以及课题的自助页面
|
||||
- 研究一下js-yaml的dump option。素材:
|
||||
- term.260ca049 的text字段 | 符号dump成了 > 符号
|
||||
- error.0ccddb29 的readme字段 也是>符号,而且内容被加了换行。
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240424140000"></a>
|
||||
## 14:00~15:29
|
||||
整理基本概念,准备梳理各git库的log、data、src、view
|
||||
|
||||
暂存在ego\readme.md
|
||||
|
||||
## git库
|
||||
|
||||
- raw:无意识的部分
|
||||
- log
|
||||
- food
|
||||
- health
|
||||
- data
|
||||
- src
|
||||
- raw.js
|
||||
- view
|
||||
- 各级时间段food、health的报表
|
||||
- ego:有意识的部分
|
||||
- log
|
||||
- 各级时间段的计划小结metadata
|
||||
- data
|
||||
- 时间模版的metadata
|
||||
- contract的metadata
|
||||
- task的metadata
|
||||
- 内部账目的metadata
|
||||
- 各独立项目的metadata
|
||||
- src
|
||||
- time.js
|
||||
- task.js
|
||||
- view
|
||||
- 各级计划小结的markdown、html文件
|
||||
- contract、task、内部账目的报表
|
||||
- blog:个人正规发布。可能根据各git托管网站的page格式重整:
|
||||
- 和用户名同名
|
||||
- 和个人域名同名
|
||||
- draft:内部手稿,防止硬盘问题备份到私有库。
|
||||
- x.sample: 练习范例
|
||||
- com.origin: 共同体模型的雏形
|
||||
- cod.template: 共同体部署方案的模版
|
||||
- 独立个人项目,如PSMD
|
||||
- log
|
||||
- data
|
||||
- term、termset、error、knowledge的metadata
|
||||
- src
|
||||
- term.js
|
||||
- view
|
||||
|
||||
|
||||
## 基本概念
|
||||
|
||||
- 主体:由自然人和共同体归纳产生的概念,智能设备等新主体的设计基础。
|
||||
- 共同体:各种主体的有意识的部分的合并。基本接口:
|
||||
- 签署和执行合同。
|
||||
- 要约表示可实践的知识。
|
||||
- 分立和合并。
|
||||
- 分立是模型的一部分。
|
||||
- 合并是合同的一种。
|
||||
- meta:察觉潜藏的概念和知识。
|
||||
- 可实践的知识,可以表现为合同、要约。
|
||||
|
||||
## 接口
|
||||
|
||||
- 门户页:写在个人域名dns,各种软件或纸质的个人简介、签名档。内容根据当时需要统筹规划。
|
||||
- blog
|
||||
- raw\view
|
||||
- ego\view
|
||||
- ego\contract
|
||||
- 要约的浏览、签署
|
||||
- gathering
|
||||
- PSMD委托
|
||||
- 要约的自动组合、对签
|
||||
|
||||
下一步:
|
||||
- 从知识-要约-共同体的角度,设计个人模型与共同体模型的映射关系。
|
||||
- 各网站page规则 -> 设计门户页及其git库
|
||||
- git库迁移
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240424160000"></a>
|
||||
## 16:00~16:59
|
||||
整理个人领域模型和共同体模型的关联
|
||||
|
||||
## 当前数据结构下的关联
|
||||
- knowledge中env、depend字段下的error,分为自身error和成员error
|
||||
- 成员error定义为:角色id+errorid
|
||||
- 由此根据成员error可以检索出无效的term、termset乃至COM、COD。
|
||||
- 由此可以转至针对该名成员的knowledge,生成个人改进的初步方案,交给人工核实、修订。
|
||||
- 产生角色的合同附件,如果出现error:
|
||||
- 合同无效并赔偿损失,金额由共同体评估。
|
||||
- 生成个人改进方案,欢迎改进后重新竞聘。
|
||||
|
||||
## 重新设计knowledge metadata
|
||||
- knowledge的env字段并入depend字段
|
||||
- depend分为几种类型:
|
||||
- 必须有、必须没有 某term、termset、error。
|
||||
- 参考gantt图:必须先解决完某error再解决本error、开始解决某error时必须同时开始解决本error、开始解决某error前必须先解决完本error、在解决完某error前必须先解决完本error。
|
||||
- knowledge也应该有类型:
|
||||
- term(set) to error
|
||||
- term(set) to term(set)
|
||||
- knowledge的需求来源:
|
||||
- menber error+COD -> COD error checklist -> motion
|
||||
- menber error+COM -> deploy -> COD
|
||||
- COD log -> menber error+COD error -> menber motion + COD motion
|
||||
- COD error -> menber error checklist -> menber motion
|
||||
|
||||
## 迭代升级的关系
|
||||
relation metadata
|
||||
```
|
||||
name:
|
||||
id:
|
||||
type: 1
|
||||
obj1: id1
|
||||
obj2: id2
|
||||
obj3: id3
|
||||
```
|
||||
|
||||
relationtype metadata
|
||||
```
|
||||
name:
|
||||
id: 1
|
||||
objcnt: 3
|
||||
text: |
|
||||
如果error<obj1>已经解决,termset<obj2>有50%概率解决error<obj3>。
|
||||
srcipt: relationtion.1.js
|
||||
```
|
||||
relation.1.js的功能是,传入obj3可以返回一段文本,其中每条都替换了{obj1,obj2},而且有可用的跳转链接。
|
||||
|
||||
|
||||
下一步:
|
||||
|
||||
- 30m:确定knowledge的需求。
|
||||
- 60m:重新设计 knowledge metadata 的数据结构,编辑范例。
|
||||
- 60m:编写代码 knowledge metadata -> error view
|
||||
- 针对其它需求的代码。
|
||||
- 90m:根据metadata中的script字段,动态调用代码的范例。
|
|
@ -0,0 +1,597 @@
|
|||
# 20240425
|
||||
|
||||
小结
|
||||
|
||||
<a id="top"></a>
|
||||
根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md),今天绑定模版1。
|
||||
|
||||
| 时间片 | 时长 | 用途 | 手稿 |
|
||||
| --- | --- | --- | --- |
|
||||
| 04:00~04:14 | 15 | 休整 | |
|
||||
| 04:15~05:14 | 60 | 备餐、运动 | |
|
||||
| 05:15~05:59 | 45 | 早餐 | |
|
||||
| 06:00~06:44 | 45 | 会议、自习 | |
|
||||
| 06:45~07:44 | 60 | 休整 | |
|
||||
| 07:45~08:44 | 60 | 静默工作 | [设计新的season metadata。](#20240425074500) |
|
||||
| 08:45~09:29 | 45 | 休整 | |
|
||||
| 09:30~10:59 | 90 | 静默工作 | [更新knowledge设计,env并入depend字段。](#20240425093000) |
|
||||
| 11:00~13:59 | 180 | 备餐、午餐午休 | |
|
||||
| 14:00~14:29 | 30 | 静默工作 | [基于配置文件(字符串)动态调用代码](#20240425140000) |
|
||||
| 14:30~14:59 | 30 | 静默工作 | [整理知识图谱的历史手稿](#20240425143000) |
|
||||
| 15:00~15:59 | 60 | 休整 | |
|
||||
| 16:00~16:59 | 60 | 静默工作 | [knowledge新metadata的commit](#20240425160000) |
|
||||
| 17:00~18:59 | 120 | 晚餐 | |
|
||||
| 19:00~19:59 | 60 | 讨论、整理提交 | |
|
||||
|
||||
模版一采用静默工作方式。
|
||||
希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com),通常安排在后面某天的早餐(5:15~5:59)或会议时间(6:00~6:45)。
|
||||
|
||||
|
||||
---
|
||||
<a id="index"></a>
|
||||
- 07:45 [设计新的season metadata。](#20240425074500)
|
||||
- 09:30 [更新knowledge设计,env并入depend字段。](#20240425093000)
|
||||
- 14:00 [基于配置文件(字符串)动态调用代码](#20240425140000)
|
||||
- 14:30 [整理知识图谱的历史手稿](#20240425143000)
|
||||
- 16:00 [knowledge新metadata的commit](#20240425160000)
|
||||
|
||||
---
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240425074500"></a>
|
||||
## 7:45~8:44
|
||||
设计新的season metadata。
|
||||
|
||||
|
||||
- \ego文件夹下新建data、src、view子文件夹。原server、client移动到src下。
|
||||
- \ego\data\season下新建season metadata,命名规则:
|
||||
- yyyySn.yaml
|
||||
- yyyy: 年份
|
||||
- n: 季度
|
||||
- task metadata迁移到\ego\data\task下
|
||||
- 在task metadata中建立agreement、todo字段,删去log字段。
|
||||
|
||||
```
|
||||
year: 2024
|
||||
season: 1
|
||||
beginmonth: 3
|
||||
beginday: 1
|
||||
nextbeginmoth: 7
|
||||
nextbeginday: 1
|
||||
timetype:
|
||||
- name: work
|
||||
- name: free
|
||||
- name: discuss
|
||||
- name: learn
|
||||
- name: prepare
|
||||
- name: sleep
|
||||
- name: food
|
||||
- name: check
|
||||
dayplan:
|
||||
dayplan:
|
||||
1:
|
||||
supply:
|
||||
90: 1
|
||||
60: 2
|
||||
30: 2
|
||||
time:
|
||||
- beginhour: 04
|
||||
beginminute: 0
|
||||
amount: 15
|
||||
type: free
|
||||
name: 休整
|
||||
- beginhour: 04
|
||||
beginminute: 15
|
||||
amount: 60
|
||||
type: prepare
|
||||
name: 备餐、运动
|
||||
- beginhour: 05
|
||||
beginminute: 15
|
||||
amount: 45
|
||||
type: food
|
||||
name: 早餐
|
||||
- beginhour: 06
|
||||
beginminute: 0
|
||||
amount: 45
|
||||
type: discuss
|
||||
name: 会议、自习
|
||||
- beginhour: 06
|
||||
beginminute: 45
|
||||
amount: 60
|
||||
type: free
|
||||
name: 休整
|
||||
- beginhour: 07
|
||||
beginminute: 45
|
||||
amount: 60
|
||||
type: work
|
||||
name: 静默工作
|
||||
namelink: http://simp.ly/p/xtgD4F
|
||||
- beginhour: 08
|
||||
beginminute: 45
|
||||
amount: 45
|
||||
type: free
|
||||
name: 休整
|
||||
- beginhour: 09
|
||||
beginminute: 30
|
||||
amount: 90
|
||||
type: work
|
||||
name: 静默工作
|
||||
namelink: http://simp.ly/p/j1SspP
|
||||
- beginhour: 11
|
||||
beginminute: 00
|
||||
amount: 180
|
||||
type: food
|
||||
name: 备餐、午餐午休
|
||||
- beginhour: 14
|
||||
beginminute: 0
|
||||
amount: 30
|
||||
type: work
|
||||
name: 静默工作
|
||||
namelink: http://simp.ly/p/8t3vlk
|
||||
- beginhour: 14
|
||||
beginminute: 30
|
||||
amount: 30
|
||||
type: work
|
||||
name: 静默工作
|
||||
namelink: http://simp.ly/p/5k9gJy
|
||||
- beginhour: 15
|
||||
beginminute: 0
|
||||
amount: 60
|
||||
type: free
|
||||
name: 休整
|
||||
- beginhour: 16
|
||||
beginminute: 0
|
||||
amount: 60
|
||||
type: work
|
||||
name: 静默工作
|
||||
namelink: http://simp.ly/p/4QDThK
|
||||
- beginhour: 17
|
||||
beginminute: 00
|
||||
amount: 120
|
||||
type: food
|
||||
name: 晚餐
|
||||
- beginhour: 19
|
||||
beginminute: 00
|
||||
amount: 60
|
||||
type: check
|
||||
name: 讨论、整理提交
|
||||
readme: |
|
||||
模版一采用静默工作方式。
|
||||
希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com),通常安排在后面某天的早餐(5:15~5:59)或会议时间(6:00~6:45)。
|
||||
2:
|
||||
supply:
|
||||
195: 1
|
||||
60: 1
|
||||
90: 1
|
||||
time:
|
||||
- beginhour: 04
|
||||
beginminute: 0
|
||||
amount: 15
|
||||
type: free
|
||||
name: 休整
|
||||
- beginhour: 04
|
||||
beginminute: 15
|
||||
amount: 60
|
||||
type: prepare
|
||||
name: 备餐、运动
|
||||
- beginhour: 05
|
||||
beginminute: 15
|
||||
amount: 45
|
||||
type: food
|
||||
name: 早餐
|
||||
- beginhour: 06
|
||||
beginminute: 0
|
||||
amount: 45
|
||||
type: discuss
|
||||
name: 会议、自习
|
||||
- beginhour: 06
|
||||
beginminute: 45
|
||||
amount: 60
|
||||
type: free
|
||||
name: 休整
|
||||
- beginhour: 07
|
||||
beginminute: 45
|
||||
amount: 195
|
||||
type: work
|
||||
name: 工作
|
||||
namelink: http://simp.ly/p/3GXNTh
|
||||
- beginhour: 11
|
||||
beginminute: 00
|
||||
amount: 180
|
||||
type: food
|
||||
name: 备餐、午餐午休
|
||||
- beginhour: 14
|
||||
beginminute: 0
|
||||
amount: 90
|
||||
type: work
|
||||
name: 工作
|
||||
namelink: http://simp.ly/p/lsBYG9
|
||||
- beginhour: 15
|
||||
beginminute: 30
|
||||
amount: 30
|
||||
type: free
|
||||
name: 休整
|
||||
- beginhour: 16
|
||||
beginminute: 0
|
||||
amount: 60
|
||||
type: work
|
||||
name: 工作
|
||||
namelink: http://simp.ly/p/MpcbHD
|
||||
- beginhour: 17
|
||||
beginminute: 00
|
||||
amount: 120
|
||||
type: food
|
||||
name: 晚餐
|
||||
- beginhour: 19
|
||||
beginminute: 00
|
||||
amount: 60
|
||||
type: check
|
||||
name: 讨论、整理提交
|
||||
readme: |
|
||||
工作的同时可以在线讨论。
|
||||
time:
|
||||
supply:
|
||||
1: 30
|
||||
2: 15
|
||||
3: 2
|
||||
// dayplanid: amount
|
||||
alloc:
|
||||
PSMD:
|
||||
90: 1
|
||||
60: 3
|
||||
30: 2
|
||||
learn:
|
||||
90: 4
|
||||
60: 4
|
||||
30: 1
|
||||
ego:
|
||||
90: 4
|
||||
60: 4
|
||||
30: 1
|
||||
learn:
|
||||
30: 8
|
||||
60: 4
|
||||
```
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240425093000"></a>
|
||||
## 9:30~10:59
|
||||
更新knowledge设计,env并入depend字段。
|
||||
|
||||
- 参考gantt图中任务之间的depeng:
|
||||
- 开始解决某error时必须同时开始解决本error、在解决完某error前必须先解决完本error:应该合并成termset一起设knowledge。
|
||||
- 因为knowledge反映termset生效的效果,可以视为解决问题结束。开始时间可以根据议事规则的召集、讨论、表决时间,加上起草动议时间、协商动员的时间,这些是部署者根据cod实际情况布置,不是模型和条款库可以提前排期的。
|
||||
- 这种情况”如果同时存在某error要同时解决(找别的termset),如果只是本error单独存在就用本knowledge解决。“,可以设一个多error效果的大termset,多个单独error效果的小termset,小termset里的depend里规定其它error不存在。然后由检索算法去适当提示。
|
||||
- 保险起见,增加一种类型:如果有就要同时解决。
|
||||
- 开始解决某error前必须先解决完本error:设在某error那边”必须先解决完某error再解决本error“。两边设不好同步。
|
||||
|
||||
- knowledge的需求来源:
|
||||
- menber error+COD -> COD error checklist -> motion
|
||||
- menber error+COM -> deploy -> COD
|
||||
- COD log -> menber error+COD error -> menber motion + COD motion
|
||||
- COD error -> menber error checklist -> menber motion
|
||||
|
||||
- 委托者自助,浏览error view,想去解决 -> cod error checklist -> 自检 -> cod error diag metadata+view ->
|
||||
deploy or 委托合同 metadata+view
|
||||
- 委托者自述 -> 受托者整理出cod error diag+checklist -> 自检 -> cod error diag metadata + view -> deploy or 委托合同
|
||||
- 委托者委托 -> 受托者调研 -> cod error checklist -> 受托者整理问卷 -> code error diag -> deploy or 新委托
|
||||
- 成员error在共同体层面表现为成员的行为偏差,使用同一种error metadata表达。由成员个人去完成:行为偏差->下意识行为 的分析。
|
||||
|
||||
- 细分需求
|
||||
- error -> error checklist
|
||||
- error to error relation
|
||||
- depend
|
||||
- together
|
||||
- error metadata中添加字段,产生自检说明和承诺条款,生成核实
|
||||
- checklist -> diag(error list, maybe unknown status)
|
||||
- termset to error relation
|
||||
- term to error relation
|
||||
- diag(error list) -> checklist or deploy or contract
|
||||
- termset to error relation
|
||||
- term to error relation
|
||||
- error unknown status -> trustee contract
|
||||
|
||||
- 综合考虑,在knowledge增加type字段:
|
||||
- termtoerror
|
||||
- errortoerror
|
||||
- termtoterm
|
||||
- termtotermset
|
||||
|
||||
更新\PSMD\data\readme.me
|
||||
```
|
||||
~~~
|
||||
name:
|
||||
id:
|
||||
type:
|
||||
objid:
|
||||
depend:
|
||||
errorid:
|
||||
percent:
|
||||
text: |
|
||||
together:
|
||||
errorid:
|
||||
percent:
|
||||
text: |
|
||||
effect:
|
||||
id:
|
||||
percent:
|
||||
text:
|
||||
readme: |
|
||||
~~~
|
||||
- depeng: 部署本条款(解决本error)之前先解决该error
|
||||
- together:部署本条款(解决本error)的同时开始解决该error
|
||||
- 解决方案只含一条term或者termset。
|
||||
- 根据type:objid to effect
|
||||
```
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240425140000"></a>
|
||||
## 14:00~14:29
|
||||
基于配置文件(字符串)动态调用代码
|
||||
|
||||
### eval()
|
||||
https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Global_Objects/eval
|
||||
|
||||
- 出于安全性考虑,先在本地运行的代码中使用,网页暂时不用。
|
||||
|
||||
### function()
|
||||
https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Global_Objects/Function
|
||||
|
||||
- 首先var func=function(params...);然后this["funcName"].call(params...)调用;
|
||||
|
||||
- setInterval
|
||||
- setTimeout
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240425143000"></a>
|
||||
## 14:30~14:59
|
||||
整理知识图谱的历史手稿
|
||||
|
||||
### RDF 资源、属性和属性值
|
||||
|
||||
- RDF 使用 Web 标识符来标识事物,并通过属性和属性值来描述资源。
|
||||
- 对资源、属性和属性值的解释:
|
||||
- 资源是可拥有 URI 的任何事物,比如 "http://www.w3school.com.cn/rdf"
|
||||
- 属性是拥有名称的资源,比如 "author" 或 "homepage"
|
||||
- 属性值是某个属性的值,比如 "David" 或 "http://www.w3school.com.cn" (请注意一个属性值可以是另外一个资源)
|
||||
|
||||
下面的 RDF 文档可描述资源 "http://www.w3school.com.cn/rdf":
|
||||
```
|
||||
<?xml version="1.0"?>
|
||||
<RDF>
|
||||
<Description about="http://www.w3school.com.cn/RDF">
|
||||
<author>David</author>
|
||||
<homepage>http://www.w3school.com.cn</homepage>
|
||||
</Description>
|
||||
</RDF>
|
||||
```
|
||||
|
||||
- rdf是知识库的标记语言
|
||||
- 另外有工具作为rdf知识库的读写查等操作,比自己写代码更统一。
|
||||
|
||||
下一步:
|
||||
- 先彻底打通业务流程,只发布view。然后把data、src部分升级到rdf,如果升级成功则作为范例。
|
||||
- https://www.npmjs.com/package/rdf#query-information-from-rdf-sources
|
||||
- 再结合范例,重新思考知识图谱的缺陷和补救方式。
|
||||
- 考虑把data、src部分发布出去。
|
||||
|
||||
历史手稿:
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
知识图谱的缺陷
|
||||
|
||||
表达权利分配规则的需求
|
||||
知识图谱的表达方式
|
||||
缺陷和改进
|
||||
|
||||
|
||||
---
|
||||
|
||||
知识图谱
|
||||
|
||||
### SparQL
|
||||
|
||||
https://www.w3.org/TR/rdf-sparql-protocol/
|
||||
https://jena.apache.org/tutorials/sparql.html
|
||||
|
||||
### rdf
|
||||
|
||||
www.w3.org/RDF/
|
||||
https://www.w3school.com.cn/rdf/rdf_intro.asp
|
||||
|
||||
### RDF-star and SPARQL-star
|
||||
|
||||
https://www.w3.org/2021/12/rdf-star.html
|
||||
https://w3c.github.io/rdf-star/
|
||||
https://www.ontotext.com/knowledgehub/fundamentals/what-is-rdf-star/
|
||||
|
||||
### OWL
|
||||
|
||||
https://www.w3.org/2001/sw/wiki/OWL
|
||||
|
||||
### Gremlin
|
||||
|
||||
https://tinkerpop.apache.org/gremlin.html
|
||||
|
||||
### neo4j
|
||||
|
||||
https://neo4j.com/
|
||||
查询语言是 Cypher https://neo4j.com/developer/cypher/
|
||||
|
||||
|
||||
### 华为KG API
|
||||
|
||||
https://support.huaweicloud.com/api-kg/kg_03_0007.html
|
||||
|
||||
|
||||
### 北大gStore
|
||||
|
||||
http://www.gstore.cn/pcsite/index.html#/
|
||||
|
||||
### HugeGraph
|
||||
|
||||
https://hugegraph.apache.org/
|
||||
|
||||
|
||||
### 图形化
|
||||
|
||||
https://www.ldf.fi/service/rdf-grapher
|
||||
https://issemantic.net/rdf-visualizer
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
### 世界观(缸中之脑)和推理
|
||||
知识图谱和推理机制,在缸中之脑模型中会发生什么。
|
||||
|
||||
- 缺陷和具体范例
|
||||
- 缸中之脑和双缝都要讨论到。
|
||||
- 改进
|
||||
- 在缸外增加推理设备,发掘更原始的规律。
|
||||
- 假设:符号、文字可以穿透缸,与其它缸中之脑交换信息。
|
||||
- 假设:在微观层面设置装置,可以与其它缸中之脑交换信息。
|
||||
```
|
||||
|
||||
```
|
||||
知识图谱的缺陷
|
||||
|
||||
表达权利分配规则的需求
|
||||
知识图谱的表达方式
|
||||
缺陷和改进
|
||||
```
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240425160000"></a>
|
||||
## 16:00~16:59
|
||||
knowledge新metadata的commit
|
||||
|
||||
- 先把/ego/src/path.js谢了。
|
||||
|
||||
### commit板块
|
||||
- node term commit: temp metadata → formal metadata
|
||||
- node term commit filename: temp metadata → formal metadata
|
||||
|
||||
knowledge.1.yaml
|
||||
```
|
||||
name: 1406解决割据问题
|
||||
id: 1
|
||||
type: termsettoerror
|
||||
objid: 056e71fb
|
||||
depend:
|
||||
2:
|
||||
percent: 50
|
||||
text: |
|
||||
抵押权力解决资源问题不再新增,再开始解决本问题。
|
||||
effect:
|
||||
1:
|
||||
percent: 50
|
||||
text: |
|
||||
- 1406动议可以消除已出现的割据问题。
|
||||
- 如果是因为资源问题未解决,欠付报酬而以一定范围割据作为抵押物,今后还会出现新的割据问题。这种情况需要同时处理历史欠账,并且根除资源问题。
|
||||
readme: ''
|
||||
```
|
||||
commit结果
|
||||
```
|
||||
name: 1406解决割据问题
|
||||
id: 3b7582cd
|
||||
type: termsettoerror
|
||||
objid: 056e71fb
|
||||
depend:
|
||||
48291d8c:
|
||||
percent: 50
|
||||
text: |
|
||||
抵押权力解决资源问题不再新增,再开始解决本问题。
|
||||
effect:
|
||||
0ccddb29:
|
||||
percent: 50
|
||||
text: |
|
||||
- 1406动议可以消除已出现的割据问题。
|
||||
- 如果是因为资源问题未解决,欠付报酬而以一定范围割据作为抵押物,今后还会出现新的割据问题。这种情况需要同时处理历史欠账,并且根除资源问题。
|
||||
readme: ''
|
||||
```
|
||||
|
||||
knowledge.2.yaml
|
||||
```
|
||||
name: 1609解决资源问题
|
||||
id: 2
|
||||
type: termtoerror
|
||||
objid: 5b4e0597
|
||||
depend:
|
||||
cde3c3e2:
|
||||
percent: 100
|
||||
text: |
|
||||
必须在规则有效的环境下进行。
|
||||
effect:
|
||||
2:
|
||||
percent: 60
|
||||
text: |
|
||||
- 1609模型可用于把薪酬、投资合二为一,极大提高调动未来收入的能力,缓解资源问题。
|
||||
- 如果规则无效问题未能解决,则1609模型无效。
|
||||
readme: ''
|
||||
```
|
||||
commit结果
|
||||
```
|
||||
name: 1609解决资源问题
|
||||
id: d8a0602f
|
||||
type: termtoerror
|
||||
objid: 5b4e0597
|
||||
depend:
|
||||
cde3c3e2:
|
||||
percent: 100
|
||||
text: |
|
||||
必须在规则有效的环境下进行。
|
||||
effect:
|
||||
48291d8c:
|
||||
percent: 60
|
||||
text: |
|
||||
- 1609模型可用于把薪酬、投资合二为一,极大提高调动未来收入的能力,缓解资源问题。
|
||||
- 如果规则无效问题未能解决,则1609模型无效。
|
||||
readme: ''
|
||||
```
|
||||
执行过程:
|
||||
```
|
||||
D:\huangyg\git\PSMD\src>node term commit
|
||||
commit error.1.yaml
|
||||
执行部门陷入割据 0ccddb29
|
||||
commit error.2.yaml
|
||||
无法有效分配未来收入 48291d8c
|
||||
commit knowledge.1.yaml
|
||||
1406解决割据问题 3b7582cd
|
||||
commit knowledge.2.yaml
|
||||
1609解决资源问题 d8a0602f
|
||||
commit term.1.yaml
|
||||
执行部门陷入割据 0ccddb29
|
||||
commit term.2.yaml
|
||||
如果割据就启用1406 583d6243
|
||||
commit termset.1.yaml
|
||||
预设1406动议 b3124d50
|
||||
../data/term.0ccddb29.yaml文件已更新。../data/term.1.yaml可以删除。
|
||||
../data/term.583d6243.yaml文件已更新。../data/term.2.yaml可以删除。
|
||||
../data/error.0ccddb29.yaml文件已更新。../data/error.1.yaml可以删除。
|
||||
../data/error.48291d8c.yaml文件已更新。../data/error.2.yaml可以删除。
|
||||
path replace:term.2.yaml term.583d6243.yaml
|
||||
旧文件:../data/termset.1.yaml中item:1的id:cb4ab0e9未能替换,请人工检查。
|
||||
path replace:term.1.yaml term.0ccddb29.yaml
|
||||
旧文件:../data/termset.1.yaml中itemset:3的id:056e71fb未能替换,请人工检查。
|
||||
../data/termset.b3124d50.yaml文件已更新。../data/termset.1.yaml可以删除。
|
||||
knowledge depend replace. error:2 -> 48291d8c
|
||||
旧文件:../data/knowledge.1.yaml中objid: 056e71fb 未能替换,请人工检查。
|
||||
knowledge effect replace. id:1 -> 0ccddb29
|
||||
../data/knowledge.3b7582cd.yaml文件已更新。../data/knowledge.1.yaml可以删除。
|
||||
旧文件:../data/knowledge.2.yaml中depend字段的id: cde3c3e2 未能替换,请人工检查。
|
||||
旧文件:../data/knowledge.2.yaml中objid: 5b4e0597 未能替换,请人工检查。
|
||||
knowledge effect replace. id:2 -> 48291d8c
|
||||
../data/knowledge.d8a0602f.yaml文件已更新。../data/knowledge.2.yaml可以删除。
|
||||
```
|
||||
|
||||
下一步:
|
||||
|
||||
- 生成内容板块
|
||||
- node term knowledge : knowledge metadata → allknowledge metadata
|
||||
- node term knowledge id : knowledge metadata → knowledge markdown + html
|
|
@ -0,0 +1,323 @@
|
|||
# 20240426
|
||||
|
||||
小结
|
||||
|
||||
<a id="top"></a>
|
||||
根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md),今天绑定模版1。
|
||||
|
||||
| 时间片 | 时长 | 用途 | 手稿 |
|
||||
| --- | --- | --- | --- |
|
||||
| 04:00~04:14 | 15 | 休整 | |
|
||||
| 04:15~05:14 | 60 | 备餐、运动 | |
|
||||
| 05:15~05:59 | 45 | 早餐 | |
|
||||
| 06:00~06:44 | 45 | 会议、自习 | |
|
||||
| 06:45~07:44 | 60 | 休整 | |
|
||||
| 07:45~08:44 | 60 | 静默工作 | [新season metadata生成日计划](#20240426074500) |
|
||||
| 08:45~09:29 | 45 | 休整 | |
|
||||
| 09:30~10:59 | 90 | 静默工作 | [knowledge新metadata输出view](#20240426093000) |
|
||||
| 11:00~13:59 | 180 | 备餐、午餐午休 | |
|
||||
| 14:00~14:29 | 30 | 静默工作 | [debug,yaml.dump后|符号编程>符号而且加了换行。](#20240426140000) |
|
||||
| 14:30~14:59 | 30 | 静默工作 | [整理各git托管商的page协议。](#20240426143000) |
|
||||
| 15:00~15:59 | 60 | 休整 | |
|
||||
| 16:00~16:59 | 60 | 静默工作 | [新season metadata生成日小结](#20240426160000) |
|
||||
| 17:00~18:59 | 120 | 晚餐 | |
|
||||
| 19:00~19:59 | 60 | 讨论、整理提交 | |
|
||||
|
||||
模版一采用静默工作方式。
|
||||
希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com),通常安排在后面某天的早餐(5:15~5:59)或会议时间(6:00~6:45)。
|
||||
|
||||
|
||||
---
|
||||
<a id="index"></a>
|
||||
- 07:45 [新season metadata生成日计划](#20240426074500)
|
||||
- 09:30 [knowledge新metadata输出view](#20240426093000)
|
||||
- 14:00 [debug,yaml.dump后|符号编程>符号而且加了换行。](#20240426140000)
|
||||
- 14:30 [整理各git托管商的page协议。](#20240426143000)
|
||||
- 16:00 [新season metadata生成日小结](#20240426160000)
|
||||
|
||||
---
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240426074500"></a>
|
||||
## 7:45~8:44
|
||||
新season metadata生成日计划
|
||||
|
||||
- 主要解决模块化,学习使用module、require。
|
||||
- 完成新版日计划:
|
||||
```
|
||||
|
||||
D:\huangyg\git\ego\src>node ego time init 1
|
||||
seasonpath:../data/season/2024S2.yaml
|
||||
../../draft/2024/04/d.20240426.yaml
|
||||
date: 20240426
|
||||
plan: 1
|
||||
time:
|
||||
- begin: '20240426074500'
|
||||
amount: 60
|
||||
type: work
|
||||
subject: tbd
|
||||
name: tbd
|
||||
output: draft/2024/04/20240426074500.md
|
||||
- begin: '20240426093000'
|
||||
amount: 90
|
||||
type: work
|
||||
subject: tbd
|
||||
name: tbd
|
||||
output: draft/2024/04/20240426093000.md
|
||||
- begin: '20240426140000'
|
||||
amount: 30
|
||||
type: work
|
||||
subject: tbd
|
||||
name: tbd
|
||||
output: draft/2024/04/20240426140000.md
|
||||
- begin: '20240426143000'
|
||||
amount: 30
|
||||
type: work
|
||||
subject: tbd
|
||||
name: tbd
|
||||
output: draft/2024/04/20240426143000.md
|
||||
- begin: '20240426160000'
|
||||
amount: 60
|
||||
type: work
|
||||
subject: tbd
|
||||
name: tbd
|
||||
output: draft/2024/04/20240426160000.md
|
||||
```
|
||||
```
|
||||
D:\huangyg\git\ego\src>node ego time init
|
||||
seasonpath:../data/season/2024S2.yaml
|
||||
time slice draft file name:../../draft/2024/04/20240426074500.md
|
||||
## 07:45 ~ 08:45
|
||||
|
||||
新season metadata生成日计划小结
|
||||
|
||||
|
||||
time slice draft file name:../../draft/2024/04/20240426093000.md
|
||||
## 09:30 ~ 11:00
|
||||
|
||||
knowledge新metadata输出view
|
||||
|
||||
|
||||
time slice draft file name:../../draft/2024/04/20240426140000.md
|
||||
## 14:00 ~ 14:30
|
||||
|
||||
debug,yaml.dump后|符号编程>符号而且加了换行。
|
||||
|
||||
|
||||
time slice draft file name:../../draft/2024/04/20240426143000.md
|
||||
## 14:30 ~ 15:00
|
||||
|
||||
整理各git托管商的page协议。
|
||||
|
||||
|
||||
time slice draft file name:../../draft/2024/04/20240426160000.md
|
||||
## 16:00 ~ 17:00
|
||||
|
||||
knowledge新metadata生成内容板块
|
||||
|
||||
|
||||
dayplan file name:
|
||||
time/d.20240426.md
|
||||
content:
|
||||
# 20240426
|
||||
|
||||
计划
|
||||
|
||||
根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md),今天绑定模版1。
|
||||
|
||||
| 时间片 | 时长 | 用途 | 手稿 |
|
||||
| --- | --- | --- | --- |
|
||||
| 04:00~04:14 | 15 | 休整 | |
|
||||
| 04:15~05:14 | 60 | 备餐、运动 | |
|
||||
| 05:15~05:59 | 45 | 早餐 | |
|
||||
| 06:00~06:44 | 45 | 会议、自习 | |
|
||||
| 06:45~07:44 | 60 | 休整 | |
|
||||
| 07:45~08:44 | 60 | 静默工作 | 新season metadata生成日计划小结 [在线同步](http://simp.ly/p/xtgD4F) [离线归档](../../draft/2024/04/20240426074500.md) |
|
||||
| 08:45~09:29 | 45 | 休整 | |
|
||||
| 09:30~10:59 | 90 | 静默工作 | knowledge新metadata输出view [在线同步](http://simp.ly/p/j1SspP) [离线归档](../../draft/2024/04/20240426093000.md) |
|
||||
|
||||
| 11:00~13:59 | 180 | 备餐、午餐午休 | |
|
||||
| 14:00~14:29 | 30 | 静默工作 | debug,yaml.dump后|符号编程>符号而且加了换行。 [在线同步](http://simp.ly/p/8t3vlk) [离线归档](../../draft/2024/04/20240426140000.md) |
|
||||
| 14:30~14:59 | 30 | 静默工作 | 整理各git托管商的page协议。 [在线同步](http://simp.ly/p/5k9gJy) [离线归档](../../draft/2024/04/20240426143000.md) |
|
||||
|
||||
| 15:00~15:59 | 60 | 休整 | |
|
||||
| 16:00~16:59 | 60 | 静默工作 | knowledge新metadata生成内容板块 [在线同步](http://simp.ly/p/4QDThK) [离线归档](../../draft/2024/04/20240426160000.md) |
|
||||
| 17:00~18:59 | 120 | 晚餐 | |
|
||||
| 19:00~19:59 | 60 | 讨论、整理提交 | |
|
||||
|
||||
模版一采用静默工作方式。
|
||||
希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com),通常安排在后面某天的早餐(5:15~5:59)或会议时间(6:00~6:45)。
|
||||
|
||||
|
||||
---
|
||||
- task:ego [新season metadata生成日计划小结](../../../draft/2024/04/20240426074500.md)
|
||||
- task:PSMD [knowledge新metadata输出view](../../../draft/2024/04/20240426093000.md)
|
||||
- task:PSMD [debug,yaml.dump后|符号编程>符号而且加了换行。](../../../draft/2024/04/20240426140000.md)
|
||||
- task:learn [整理各git托管商的page协议。](../../../draft/2024/04/20240426143000.md)
|
||||
- task:PSMD [knowledge新metadata生成内容板块](../../../draft/2024/04/20240426160000.md)
|
||||
```
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240426093000"></a>
|
||||
## 9:30~10:59
|
||||
knowledge新metadata输出view
|
||||
|
||||
- 使用新的knowledge metadata,为error markdown增加内容。
|
||||
- /PSMD/src/term.js makeerrorview() makeerrornet()
|
||||
|
||||
```
|
||||
|
||||
D:\huangyg\git\PSMD\src>node term error 0ccddb29
|
||||
0ccddb29>enter makeerrornet: 0ccddb29 已查找的knowledge:
|
||||
{}
|
||||
|
||||
0ccddb29>search knowledge: 1
|
||||
0ccddb29>search knowledge: 2
|
||||
0ccddb29>search knowledge: 3b7582cd
|
||||
0ccddb29>发现knowledge 3b7582cd :使用termset [056e71fb](../view/term.056e71fb.md) 可能解决 error 0ccddb29 预估有效的比例是 50%
|
||||
0ccddb29>使用knowledge 3b7582cd 需要先解决error:
|
||||
0ccddb29>[48291d8c](../view/error.48291d8c.md)
|
||||
0ccddb29>48291d8c>enter makeerrornet: 48291d8c 已查找的knowledge:
|
||||
3b7582cd: true
|
||||
|
||||
0ccddb29>48291d8c>search knowledge: 1
|
||||
0ccddb29>48291d8c>search knowledge: 2
|
||||
0ccddb29>48291d8c>search knowledge: 3b7582cd
|
||||
0ccddb29>48291d8c>search knowledge: d8a0602f
|
||||
0ccddb29>48291d8c>发现knowledge d8a0602f :使用term [5b4e0597](../view/term.5b4e0597.md) 可能解决 error 48291d8c 预估有效的比例是 60%
|
||||
0ccddb29>48291d8c>使用knowledge d8a0602f 需要先解决error:
|
||||
0ccddb29>48291d8c>[cde3c3e2](../view/error.cde3c3e2.md)
|
||||
0ccddb29>48291d8c>cde3c3e2>enter makeerrornet: cde3c3e2 已查找的knowledge:
|
||||
3b7582cd: true
|
||||
d8a0602f: true
|
||||
|
||||
0ccddb29>48291d8c>cde3c3e2>search knowledge: 1
|
||||
0ccddb29>48291d8c>cde3c3e2>search knowledge: 2
|
||||
0ccddb29>48291d8c>cde3c3e2>search knowledge: 3b7582cd
|
||||
0ccddb29>48291d8c>cde3c3e2>search knowledge: d8a0602f
|
||||
0ccddb29>search knowledge: d8a0602f
|
||||
../view/error.0ccddb29.md文件更新,内容如下:
|
||||
问题 0ccddb29 正文:
|
||||
出现以下情况之一:
|
||||
- 决策部门未界定执行部门工作的合规性要求。
|
||||
- 决策部门界定了执行部门工作的合规性要求。
|
||||
- 执行部门成员对指令不进行合规检查,即使不合规也执行。
|
||||
- 执行部门成员及下达指令者未按要求填写和提交表单,比如工单、日志。
|
||||
|
||||
---
|
||||
问题 0ccddb29 readme:
|
||||
- 下达指令者的指令包括对更早指令的掩盖,通过互相包庇产生系统性的对抗。
|
||||
- 共同体曾经对下达指令者违约,以一定范围内的割据作为抵押物。这是历史上资源紧缺,无法兑现约定报酬的后遗症。
|
||||
- 把一定范围内的割据作为违约抵押物的情况,解除割据应该同时处理历史欠账。在共同体设立阶段,就要确定是否符合<term.1>,如果符合应该在设立时解决。
|
||||
|
||||
---
|
||||
解决建议:
|
||||
0ccddb29>发现knowledge 3b7582cd :使用termset [056e71fb](../view/term.056e71fb.md) 可能解决 error 0ccddb29 预估有效的比例是 50%
|
||||
0ccddb29>使用knowledge 3b7582cd 需要先解决error:
|
||||
0ccddb29>[48291d8c](../view/error.48291d8c.md)
|
||||
|
||||
0ccddb29>48291d8c>发现knowledge d8a0602f :使用term [5b4e0597](../view/term.5b4e0597.md) 可能解决 error 48291d8c 预估有效的比例是 60%
|
||||
0ccddb29>48291d8c>使用knowledge d8a0602f 需要先解决error:
|
||||
0ccddb29>48291d8c>[cde3c3e2](../view/error.cde3c3e2.md)
|
||||
|
||||
|
||||
---
|
||||
```
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240426140000"></a>
|
||||
## 14:00~14:29
|
||||
debug,yaml.dump后|符号编程>符号而且加了换行。
|
||||
|
||||
error.0ccddb29的手稿内容
|
||||
```
|
||||
readme: |
|
||||
- <entity.2>的指令包括对更早指令的掩盖,通过互相包庇产生系统性的对抗。
|
||||
- <entity.1>曾经对<entity.2>违约,以一定范围内的割据作为抵押物。这是历史上资源紧缺,无法兑现约定报酬的后遗症。
|
||||
- 把一定范围内的割据作为违约抵押物的情况,解除割据应该同时处理历史欠账。在<entity.1>设立阶段,就要确定是否符合<term.1>,如果符合应该在设立时解决。
|
||||
```
|
||||
被dump成正规内容
|
||||
```
|
||||
readme: >
|
||||
- <entity.2>的指令包括对更早指令的掩盖,通过互相包庇产生系统性的对抗。
|
||||
|
||||
- <entity.1>曾经对<entity.2>违约,以一定范围内的割据作为抵押物。这是历史上资源紧缺,无法兑现约定报酬的后遗症。
|
||||
|
||||
-
|
||||
把一定范围内的割据作为违约抵押物的情况,解除割据应该同时处理历史欠账。在<entity.1>设立阶段,就要确定是否符合<term.1>,如果符合应该在设立时解决。
|
||||
```
|
||||
|
||||
- yaml.load增加参数), { schema: yaml.FAILSAFE_SCHEMA }); 不变。
|
||||
- 去掉每行开头前面”-“,不变。
|
||||
- 只留一行。是好的,|还是|,末尾加了换行。
|
||||
- 只留一行,|改成|-,变成直接定义的字符串;readme: <entity.2>的指令包括对更早指令的掩盖,通过互相包庇产生系统性的对抗。
|
||||
- 多行,|改成|-。末尾加了回车,其它准确复刻。
|
||||
- 每行开头增加”-“。末尾加了回车,其它准确复刻。
|
||||
- 改回原始文件,问题重新。
|
||||
- 原始文件第三行砍到80字符以内。末尾加了回车,其它准确复刻。
|
||||
- yaml.dump增加参数,{'lineWidth ': -1}));末尾加了回车,其它准确复刻。
|
||||
- 全部yaml.dump()都增加了参数,{'lineWidth': -1}));
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240426143000"></a>
|
||||
## 14:30~14:59
|
||||
整理各git托管商的page协议。
|
||||
|
||||
### github
|
||||
|
||||
- https://docs.github.com/zh/pages/getting-started-with-github-pages
|
||||
- 若要发布用户站点,必须创建名为 <username>.github.io 的个人帐户拥有的存储库。 若要发布组织站点,必须创建名为 <organization>.github.io 的组织帐户拥有的存储库。 除非使用的是自定义域,否则用户和组织站点在 http(s)://<username>.github.io 或 http(s)://<organization>.github.io 中可用。
|
||||
- 项目站点的源文件与其项目存储在同一个仓库中。 除非使用的是自定义域,否则项目站点在 http(s)://<username>.github.io/<repository> 或 http(s)://<organization>.github.io/<repository> 中可用。
|
||||
- 修改项目设置和DNS:https://docs.github.com/zh/pages/configuring-a-custom-domain-for-your-github-pages-site/managing-a-custom-domain-for-your-github-pages-site#configuring-a-subdomain
|
||||
|
||||
### conberg
|
||||
|
||||
- https://codeberg.page/
|
||||
- Create a public repository named pages to make the site available at the main subdomain.
|
||||
- Push your static content, HTML, style, fonts, images or anything else.
|
||||
- Access your new website using this link:
|
||||
https://USERNAME.codeberg.page[/REPOSITORY][/@BRANCH]
|
||||
- To use a custom domain, create a file .domains in your repository with the domain name you wish to use. Then, add a DNS record for that domain:
|
||||
```
|
||||
CNAME [[branch.]repo.]user.codeberg.page.
|
||||
```
|
||||
- Or for apex domains where CNAME doesn't work:
|
||||
```
|
||||
ALIAS codeberg.page.
|
||||
TXT [[branch.]repo.]user.codeberg.page
|
||||
```
|
||||
- If ALIAS isn't supported, use A & AAAA instead:
|
||||
```
|
||||
A 217.197.91.145
|
||||
AAAA 2001:67c:1401:20f0::1
|
||||
+ TXT as above
|
||||
```
|
||||
|
||||
### gitee
|
||||
|
||||
- https://gitee.com/help/articles/4136
|
||||
- 想以ipvb.gitee.io直接访问,那么他就可以创建一个名字为ipvb的仓库 https://gitee.com/ipvb/ipvb 部署完成后,就可以以 https://ipvb.gitee.io 进行访问了。
|
||||
- 仓库必须有 index.html 才可以正常访问
|
||||
- 你尚未通过实名认证,无法使用 Pages 服务,如需使用,请先进行实名认证。
|
||||
- 手持证件照是手持身份证与本人面部的合照。
|
||||
|
||||
### coding
|
||||
|
||||
- https://cloud.tencent.com/developer/article/1906710
|
||||
- 菜单已经变化,没有page服务入口。
|
||||
|
||||
|
||||
综合看,还是先使用codeberg,其次是github。争取一个本地库push两个托管方。
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240426160000"></a>
|
||||
## 16:00~16:59
|
||||
新season metadata生成日小结
|
||||
|
||||
- 已完成,格式微调,明天可以试用。
|
||||
- 浮动时间表的优先级往后方,先抓紧实现任务和时间之间的压力传递:
|
||||
- 对外承诺的任务,按期限向前排子任务。
|
||||
- 长期任务的子任务按优先级排序,自动填充进入时间表。
|
||||
- 尽快让它们产生相互竞争,好设计资源调度的规则。
|
|
@ -0,0 +1,341 @@
|
|||
# 2024.04.27.
|
||||
日小结
|
||||
|
||||
<a id="top"></a>
|
||||
根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md),今天绑定模版1。
|
||||
|
||||
| 时间片 | 时长 | 用途 | 手稿 |
|
||||
| --- | --- | --- | --- |
|
||||
| 04:00~04:14 | 15 | 休整 | |
|
||||
| 04:15~05:14 | 60 | 备餐、运动 | |
|
||||
| 05:15~05:59 | 45 | 早餐 | |
|
||||
| 06:00~06:44 | 45 | 会议、自习 | |
|
||||
| 06:45~07:44 | 60 | 休整 | |
|
||||
| 07:45~08:44 | 60 | 静默工作 | [task和timeslice配对的需求分析和设计](#20240427074500) |
|
||||
| 08:45~09:29 | 45 | 休整 | |
|
||||
| 09:30~10:59 | 90 | 静默工作 | [使用knowledge metadata生成error view内容](#20240427093000) |
|
||||
| 11:00~13:59 | 180 | 备餐、午餐午休 | |
|
||||
| 14:00~14:29 | 30 | 静默工作 | [分析term和termset是否可以合并](#20240427140000) |
|
||||
| 14:30~14:59 | 30 | 静默工作 | [eval、function、import() 范例](#20240427143000) |
|
||||
| 15:00~15:59 | 60 | 休整 | |
|
||||
| 16:00~16:59 | 60 | 静默工作 | [整理治理相关数据结构,为自动分录做好准备。](#20240427160000) |
|
||||
| 17:00~18:59 | 120 | 晚餐 | |
|
||||
| 19:00~19:59 | 60 | 讨论、整理提交 | |
|
||||
|
||||
模版一采用静默工作方式。
|
||||
希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com),通常安排在后面某天的早餐(5:15~5:59)或会议时间(6:00~6:45)。
|
||||
|
||||
---
|
||||
|
||||
<a id="index"></a>
|
||||
- 07:45 [task和timeslice配对的需求分析和设计](#20240427074500)
|
||||
- 09:30 [使用knowledge metadata生成error view内容](#20240427093000)
|
||||
- 14:00 [分析term和termset是否可以合并](#20240427140000)
|
||||
- 14:30 [eval、function、import() 范例](#20240427143000)
|
||||
- 16:00 [整理治理相关数据结构,为自动分录做好准备。](#20240427160000)
|
||||
|
||||
|
||||
---
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240427074500"></a>
|
||||
## 7:45~8:44
|
||||
task和timeslice配对的需求分析和设计
|
||||
|
||||
### 流程
|
||||
由于任务间压力还没有实际产生,里程碑和任务之间关系也不明确,只能按预估的情形确定需求:
|
||||
|
||||
- 在每天结束时,排出次日每种模版的配对。
|
||||
- 根据各种模版的配对,人工调整metadata。
|
||||
- 在每天开始时,自动按模版一次生成draft metadata和draft markdown文件。
|
||||
|
||||
|
||||
### 数据结构
|
||||
如果fs读写同一个文件还是内容混乱,就设置多个metadata文件。
|
||||
|
||||
- 正式的候选任务写在todo.yaml中,人工编辑。
|
||||
- 排出每种模版配对时,代码把每种配对产生的次日更新写在nexttodo.yaml中。这过程可以反复进行。
|
||||
- 在正式绑定模版时,读取nexttodo.yaml中对应部分,直接写入todo.yaml。这一步不读todo.yaml。
|
||||
|
||||
todo.yaml
|
||||
```
|
||||
taskname:
|
||||
- 30: subtask1
|
||||
readme: |
|
||||
subtask detail info.
|
||||
- 60: subtask2
|
||||
taskname:
|
||||
- 30: 1
|
||||
- 30: 2
|
||||
```
|
||||
|
||||
nexttodo.yaml
|
||||
```
|
||||
dayplan1:
|
||||
todo.yaml content
|
||||
dayplan2:
|
||||
another todo.yaml
|
||||
```
|
||||
|
||||
|
||||
---
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240427093000"></a>
|
||||
## 9:30~10:59
|
||||
使用knowledge metadata生成error view内容
|
||||
|
||||
基础概念:
|
||||
|
||||
- 个人领域划分出有意识和无意识两部分;
|
||||
- 共同体成员首先在最基层单元中,互相确认职务行为是有意识还是无意识的。
|
||||
- 有意识的行为:基于理性人假设,从行为偏差分析规章偏差,根据情况产生工单。
|
||||
- 共同体knowledge为这个过程提供迭代更新的知识,以提高自动化程度。
|
||||
- 无意识的行为:暂时停职,由个人领域自行纠偏,然后根据情况恢复或者重新竞聘。
|
||||
- 共同体knowledge不介入,个人领域knowledge为这个过程提供迭代更新的知识。
|
||||
|
||||
|
||||
修改\psmd\src\term.js 中的makeerrorview() makeerrornet() 执行结果如下:
|
||||
```
|
||||
|
||||
D:\huangyg\git\PSMD\src>node term error 0ccddb29
|
||||
- 0ccddb29>发现knowledge 3b7582cd :使用termset [056e71fb](../view/term.056e71fb.md) 可能解决 error 0ccddb29 预估有效的比例是 50%
|
||||
- 0ccddb29>使用knowledge 3b7582cd 需要先解决error:
|
||||
- 0ccddb29>[48291d8c](../view/error.48291d8c.md)
|
||||
- 0ccddb29>48291d8c>发现knowledge d8a0602f :使用term [5b4e0597](../view/term.5b4e0597.md) 可能解决 error 48291d8c 预估有效的比例是 60%
|
||||
- 0ccddb29>48291d8c>使用knowledge d8a0602f 需要先解决error:
|
||||
- 0ccddb29>48291d8c>[cde3c3e2](../view/error.cde3c3e2.md)
|
||||
../view/error.0ccddb29.md文件更新,内容如下:
|
||||
问题 0ccddb29 正文:
|
||||
出现以下情况之一:
|
||||
- 决策部门未界定执行部门工作的合规性要求。
|
||||
- 决策部门界定了执行部门工作的合规性要求。
|
||||
- 执行部门成员对指令不进行合规检查,即使不合规也执行。
|
||||
- 执行部门成员及下达指令者未按要求填写和提交表单,比如工单、日志。
|
||||
|
||||
---
|
||||
问题 0ccddb29 readme:
|
||||
- 下达指令者的指令包括对更早指令的掩盖,通过互相包庇产生系统性的对抗。
|
||||
- 共同体曾经对下达指令者违约,以一定范围内的割据作为抵押物。这是历史上资源紧缺,无法兑现约定报酬的后遗症。
|
||||
- 把一定范围内的割据作为违约抵押物的情况,解除割据应该同时处理历史欠账。在共同体设立阶段,就要确定是否符合资源不足,如果符合应该在设立时解决。
|
||||
|
||||
---
|
||||
解决建议:
|
||||
出现偏差的部门内部互相确认:相关职务行为是有意识还是无意识的。
|
||||
- 无意识的行为:应暂时停职,由相关成员自行纠偏,然后根据情况复职或者重新竞聘。
|
||||
- 有意识的行为:可以基于理性人假设,从行为偏差分析规章偏差,根据情况产生工单。可以参考以下内容:
|
||||
- 0ccddb29>发现knowledge 3b7582cd :使用termset [056e71fb](../view/term.056e71fb.md) 可能解决 error 0ccddb29 预估有效的比例是 50%
|
||||
- 0ccddb29>使用knowledge 3b7582cd 需要先解决error:[48291d8c](../view/error.48291d8c.md)
|
||||
- 0ccddb29>48291d8c>发现knowledge d8a0602f :使用term [5b4e0597](../view/term.5b4e0597.md) 可能解决 error 48291d8c 预估有效的比例是 60%
|
||||
- 0ccddb29>48291d8c>使用knowledge d8a0602f 需要先解决error:[cde3c3e2](../view/error.cde3c3e2.md)
|
||||
|
||||
---
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
D:\huangyg\git\PSMD\src>node term error 48291d8c
|
||||
- 48291d8c>发现knowledge d8a0602f :使用term [5b4e0597](../view/term.5b4e0597.md) 可能解决 error 48291d8c 预估有效的比例是 60%
|
||||
- 48291d8c>使用knowledge d8a0602f 需要先解决error:
|
||||
- 48291d8c>[cde3c3e2](../view/error.cde3c3e2.md)
|
||||
../view/error.48291d8c.md文件更新,内容如下:
|
||||
问题 48291d8c 正文:
|
||||
共同体涉及未来收入的承诺,无法保证兑现。因此,无法使用未来收入换取当下资源,只能以现有资源进行交易。
|
||||
|
||||
---
|
||||
问题 48291d8c readme:
|
||||
可能的原因包括:
|
||||
- 共同体内部废除该承诺,可能成为有效力的决议;
|
||||
- 共同体内部对同一笔未来收入安排其它用途,可能成为有效力的预算案。
|
||||
|
||||
---
|
||||
解决建议:
|
||||
出现偏差的部门内部互相确认:相关职务行为是有意识还是无意识的。
|
||||
- 无意识的行为:应暂时停职,由相关成员自行纠偏,然后根据情况复职或者重新竞聘。
|
||||
- 有意识的行为:可以基于理性人假设,从行为偏差分析规章偏差,根据情况产生工单。可以参考以下内容:
|
||||
- 48291d8c>发现knowledge d8a0602f :使用term [5b4e0597](../view/term.5b4e0597.md) 可能解决 error 48291d8c 预估有效的比例是 60%
|
||||
- 48291d8c>使用knowledge d8a0602f 需要先解决error:[cde3c3e2](../view/error.cde3c3e2.md)
|
||||
|
||||
---
|
||||
```
|
||||
|
||||
```
|
||||
D:\huangyg\git\PSMD\src>node term error cde3c3e2
|
||||
../view/error.cde3c3e2.md文件更新,内容如下:
|
||||
问题 cde3c3e2 正文:
|
||||
违规收益超过违规成本。违规造成的既成事实被接受。
|
||||
|
||||
---
|
||||
问题 cde3c3e2 readme:
|
||||
|
||||
---
|
||||
解决建议:
|
||||
出现偏差的部门内部互相确认:相关职务行为是有意识还是无意识的。
|
||||
- 无意识的行为:应暂时停职,由相关成员自行纠偏,然后根据情况复职或者重新竞聘。
|
||||
- 有意识的行为:可以基于理性人假设,从行为偏差分析规章偏差,根据情况产生工单。如需进一步建议请联系<huang@mars22.com>
|
||||
---
|
||||
```
|
||||
---
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240427140000"></a>
|
||||
## 14:00~14:29
|
||||
分析term和termset是否可以合并
|
||||
|
||||
新的term结构:
|
||||
|
||||
- 增加item字段,改为subterm。
|
||||
- 取消item.path,改由统一的接口从id获得path、obj
|
||||
- 取消item.type,统统都是term
|
||||
- 暂时保留upgradeby字段,实际使用后再定。
|
||||
- 增加depend、together字段,结合原有的effect字段代替knowledge
|
||||
- 默认是termtoerror,因为没有type,而effect的id也是errorid
|
||||
- 可能有不止一种效果,每种效果的depend、together不同,这时仍需要knowledge
|
||||
- 保留原有的text字段,作为高于item下子条款一级的正文。
|
||||
|
||||
```
|
||||
name:
|
||||
id:
|
||||
interface:
|
||||
entity:
|
||||
id: name
|
||||
asset:
|
||||
id: name
|
||||
term:
|
||||
id: name
|
||||
event:
|
||||
id: name
|
||||
text: |
|
||||
subterm:
|
||||
- sortid:
|
||||
id:
|
||||
upgradeby: // sortid.sortid.....id 上级定义覆盖下级定义
|
||||
map:
|
||||
entity:
|
||||
localid: globalid
|
||||
asset:
|
||||
localid: globalid
|
||||
term:
|
||||
localid: globalid
|
||||
event:
|
||||
localid: globalid
|
||||
readme: |
|
||||
depend:
|
||||
errorid:
|
||||
percent:
|
||||
text: |
|
||||
together:
|
||||
errorid:
|
||||
percent:
|
||||
text: |
|
||||
effect: |
|
||||
errorid:
|
||||
percent:
|
||||
text: |
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240427143000"></a>
|
||||
## 14:30~14:59
|
||||
eval、function、import() 范例
|
||||
|
||||
- 为了让数据结构不断升级,各版本的数据结构和代码配套,由稳定的结构调用。
|
||||
- 这种用途import()最方便。
|
||||
|
||||
范例在\js.sample\codestr ,执行结果:
|
||||
```
|
||||
D:\huangyg\git\js.sample\codestr>node main
|
||||
data:123456
|
||||
60:60str
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240427160000"></a>
|
||||
## 16:00~16:59
|
||||
整理治理相关数据结构,为自动分录做好准备。
|
||||
|
||||
### xuemen
|
||||
|
||||
- 公司章程
|
||||
- 三会动议、决议、会议纪要
|
||||
- 1-2.章程实施细则
|
||||
- 股东会决议:决定公司状态
|
||||
- 进入S4状态的决议明确业务范围
|
||||
- 财务会计报告:
|
||||
- 进入、离开S1状态
|
||||
-
|
||||
- 股东会决议:任命S1状态下的执行董事
|
||||
- 股东会决议:离开S1状态的补偿方案
|
||||
- 2-1.全局模型
|
||||
- 核心模型
|
||||
- ISU模型
|
||||
- 内务需求
|
||||
- 内务工作计划以及预算方案
|
||||
- JPU模型
|
||||
- 通用工单
|
||||
- 通用日志
|
||||
- 临时模型
|
||||
- 审议记录
|
||||
- 2-3.ISU模型
|
||||
- Token决算数据包[TBP:Token Balance Package]
|
||||
- 财务管理制度
|
||||
- 2-4.JPU模型
|
||||
- 产品模型
|
||||
- 产品配置备忘录(P2CM:Product Configuration Memo)
|
||||
- 预购意见
|
||||
- 预购权重调整方案
|
||||
- 工作计划及预算方案
|
||||
- 工作总结及结算方案
|
||||
- 结项方案
|
||||
|
||||
### xuemen.record
|
||||
目前是AER、TEO、TER、AVR记录文件。
|
||||
|
||||
- 会计分录记录 Accounting Entry Record AER
|
||||
- Token交易委托 Token Exchange Order TEO
|
||||
- Token交易记录 Token Exchange Record TER
|
||||
- 会计凭证 Accounting Voucher Record AVR
|
||||
|
||||
### 自动分录
|
||||
|
||||
- 会计分录规则 Accounting Entry Code AEC
|
||||
```
|
||||
CodeID:
|
||||
VoucherType: 利息回单
|
||||
code:
|
||||
path:
|
||||
hash:
|
||||
map:
|
||||
- AVRitem: amount
|
||||
AERitem:
|
||||
- AVRitem:
|
||||
AERitem:
|
||||
|
||||
AVR字段和AER字段映射
|
||||
```
|
||||
- 以 xuemen.record\ISU2019.AVR.1.yaml ISU2019.AER.1.yaml这一对文件为例:
|
||||
- AEC.map字段无法表达:
|
||||
- AccountingEntry.debit.AccountTitle = 银行存款-交通银行 amount=AVRitem: 金额
|
||||
- AccountingEntry.debit.AccountTitle = 财务费用-利息费用 amount=AVRitem: 金额 *-1
|
||||
- AccountingSoftwareID
|
||||
- code字段:可以表达以上关系
|
||||
```
|
||||
map:
|
||||
- AVRitem: 记账日期
|
||||
AERitem: date
|
||||
- AVRitem: 回单编号
|
||||
AERitem: VoucherID
|
||||
- AVRitem: 金额
|
||||
AERitem: AccountingEntry.debit.amount
|
||||
```
|
||||
- 让AEC生效需要以下六层决议:
|
||||
- 董事会决议:AEC生效
|
||||
- 董事会决议:3-02.财务管理制度
|
||||
- 董事会决议:2-3.ISU模型
|
||||
- 股东会决议:2-1.全局模型
|
||||
- 股东会决议:1-2.章程实施细则
|
||||
- 股东会决议:1-1.章程
|
|
@ -0,0 +1,317 @@
|
|||
# 20240428
|
||||
|
||||
小结
|
||||
|
||||
<a id="top"></a>
|
||||
根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md),今天绑定模版1。
|
||||
|
||||
| 时间片 | 时长 | 用途 | 手稿 |
|
||||
| --- | --- | --- | --- |
|
||||
| 04:00~04:14 | 15 | 休整 | |
|
||||
| 04:15~05:14 | 60 | 备餐、运动 | |
|
||||
| 05:15~05:59 | 45 | 早餐 | |
|
||||
| 06:00~06:44 | 45 | 会议、自习 | |
|
||||
| 06:45~07:44 | 60 | 休整 | |
|
||||
| 07:45~08:44 | 60 | 静默工作 | [月份总结报告](#20240428074500) |
|
||||
| 08:45~09:29 | 45 | 休整 | |
|
||||
| 09:30~10:59 | 90 | 静默工作 | [试用term新结构,根据问题更新设计。](#20240428093000) |
|
||||
| 11:00~13:59 | 180 | 备餐、午餐午休 | |
|
||||
| 14:00~14:29 | 30 | 静默工作 | [季度总结报告](#20240428140000) |
|
||||
| 14:30~14:59 | 30 | 静默工作 | [debug-nodejs fs读写同一个文件的内容混乱。](#20240428143000) |
|
||||
| 15:00~15:59 | 60 | 休整 | |
|
||||
| 16:00~16:59 | 60 | 静默工作 | [填写term metadata的readme字段,增加成员无意识行为的特征](#20240428160000) |
|
||||
| 17:00~18:59 | 120 | 晚餐 | |
|
||||
| 19:00~19:59 | 60 | 讨论、整理提交 | |
|
||||
|
||||
模版一采用静默工作方式。
|
||||
希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com),通常安排在后面某天的早餐(5:15~5:59)或会议时间(6:00~6:45)。
|
||||
|
||||
|
||||
---
|
||||
<a id="index"></a>
|
||||
- 07:45 [月份总结报告](#20240428074500)
|
||||
- 09:30 [试用term新结构,根据问题更新设计。](#20240428093000)
|
||||
- 14:00 [季度总结报告](#20240428140000)
|
||||
- 14:30 [debug-nodejs fs读写同一个文件的内容混乱。](#20240428143000)
|
||||
- 16:00 [填写term metadata的readme字段,增加成员无意识行为的特征](#20240428160000)
|
||||
|
||||
---
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240428074500"></a>
|
||||
## 7:45~8:44
|
||||
月份总结报告
|
||||
|
||||
月份总结范例
|
||||
```
|
||||
三月份
|
||||
|
||||
日平均值,和二月对比:
|
||||
热量1896.56千卡,+2.17千卡;
|
||||
蛋白质76.52克,-0.28克;(RNI:65)
|
||||
脂肪59.17克,+5.6克;
|
||||
碳水270.47克,-18.46克;
|
||||
钠2.15克,+0.14克;
|
||||
膳食纤维33.96克,-1.18克;(AI:25~30)
|
||||
钙1.38克,+0.15克;(RNI:0.8)
|
||||
水2598.34ml ,-145.12ml。
|
||||
|
||||
脂肪供能28.08%%(AMDR:20~30%)
|
||||
碳水供能57.04%(AMDR:50~65%)
|
||||
蛋白质供能16.14%(AMDR:10~15%)
|
||||
膳食纤维供能3.58%
|
||||
```
|
||||
|
||||
季度总结范例
|
||||
```
|
||||
一季度
|
||||
|
||||
日平均值,和去年四季度对比:
|
||||
热量1922.30千卡,+83.61千卡;
|
||||
蛋白质81.86克,-3.5克;(RNI:65)
|
||||
脂肪55.81克,+3.64克;
|
||||
碳水281.98克,+20.85克;
|
||||
钠2.13克,-0.15克;
|
||||
膳食纤维35.11克,-0.3克;(AI:25~30)
|
||||
钙1.31克,+0.1克;(RNI:0.8)
|
||||
水2634.08ml ,+263.77ml。
|
||||
|
||||
脂肪供能26.13%(AMDR:20~30%)
|
||||
碳水供能58.68%(AMDR:50~65%)
|
||||
蛋白质供能17.03%(AMDR:10~15%)
|
||||
膳食纤维供能3.65%
|
||||
```
|
||||
|
||||
- 因为全局变量使用太多,化了不少时间适应。
|
||||
- 建立了foodmonthreport() 基本框架。在原模版上增加去年同期的对比,把月度报告的第一行热量算出来了。
|
||||
- 有可能做所有营养成分对比。
|
||||
- 还需要60时间片完成余下部分。
|
||||
|
||||
执行结果:
|
||||
```
|
||||
D:\huangyg\git\raw>node raw 202404
|
||||
>> 脂肪供能25.86% 碳水供能57.39% 蛋白质供能17.86% <<
|
||||
名称 总数量 日均 单位 NRV(%)
|
||||
番茄红素 58.68 2.10 mg 0.00
|
||||
灰分 15.41 0.55 g 0.00
|
||||
硅 56.00 2.00 mg 0.00
|
||||
叶黄素 7.00 0.25 mg 0.00
|
||||
硼 4.20 0.15 mg 0.00
|
||||
钒 280.00 10.00 μg 0.00
|
||||
氯 1.96 0.07 g 3.00
|
||||
胆固醇 4.33 0.15 g 51.61
|
||||
磷 14.58 0.52 g 69.54
|
||||
胡萝卜素 33.93 1.21 mg 79.87
|
||||
钠 54.38 1.94 g 90.39
|
||||
脂肪 1532.90 54.75 g 93.87
|
||||
碳水化合物 7653.00 273.32 g 95.49
|
||||
镁 9.75 0.35 g 96.64
|
||||
生物素 840.00 30.00 μg 100.00
|
||||
钼 1.26 0.04 mg 100.00
|
||||
碘 4.22 0.15 mg 100.42
|
||||
热量 53338.87 1904.96 kcal 102.49
|
||||
水 68878.50 2459.95 ml 123.00
|
||||
钾 78.24 2.79 g 127.89
|
||||
铬 1.26 0.04 mg 129.00
|
||||
膳食纤维 971.88 34.71 g 131.00
|
||||
钙 38.08 1.36 g 138.35
|
||||
蛋白质 2382.17 85.08 g 143.55
|
||||
铁 556.07 19.86 mg 161.15
|
||||
锰 109.45 3.91 mg 161.59
|
||||
锌 520.01 18.57 mg 165.92
|
||||
VB3(烟酸) 745.07 26.61 mg 176.82
|
||||
VB1(硫胺素) 3.77 0.13 g 179.76
|
||||
铜 47.07 1.68 mg 179.76
|
||||
VE(生育酚) 1.24 0.04 g 209.57
|
||||
VB5(泛酸) 293.43 10.48 mg 209.59
|
||||
VB2(核黄素) 94.01 3.36 mg 241.15
|
||||
VB9(叶酸) 18.39 0.66 mg 251.94
|
||||
VB6(吡哆素) 116.78 4.17 mg 254.76
|
||||
VA(视黄醇等) 65.89 2.35 mg 268.19
|
||||
VD3(胆钙化醇) 1.70 0.06 mg 303.92
|
||||
VK(凝血维生素) 7.19 0.26 mg 307.92
|
||||
VC(抗坏血酸) 10.83 0.39 g 439.09
|
||||
硒 7.60 0.27 mg 493.34
|
||||
VB12(钴胺素) 732.77 26.17 μg 1090.94
|
||||
|
||||
20240401 ~ 20240500 : 28 days.
|
||||
|
||||
---
|
||||
月度报告
|
||||
四月份
|
||||
|
||||
日平均值,和三月份、去年四月份对比:
|
||||
热量1904.96千卡, +8.40、+146.67千卡;
|
||||
|
||||
health/heartrate.R文件已被保存。在R环境运行 source("D:/huangyg/git/raw/health/heartrate.R",encoding = "UTF-8")
|
||||
health/sleep.R文件已被保存。在R环境运行 source("D:/huangyg/git/raw/health/sleep.R",encoding = "UTF-8")
|
||||
health/weight.R文件已被保存。在R环境运行 source("D:/huangyg/git/raw/health/weight.R",encoding = "UTF-8")
|
||||
```
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240428093000"></a>
|
||||
## 9:30~10:59
|
||||
试用term新结构,根据问题更新设计。
|
||||
|
||||
- 选择一个termset.01e1c775,先生成view,再根据它编辑新的term temp metadata:
|
||||
```
|
||||
D:\huangyg\git\PSMD\src>node term termset 01e1c775
|
||||
../view/termset.01e1c775.md文件更新,内容如下:
|
||||
1. 由deployer书面提交即生效。
|
||||
2. p=20,p%=20%。
|
||||
3. 由director表决按一人一票表决,超过80%出席会议有效,赞成票超过超过三分之二为通过。
|
||||
|
||||
---
|
||||
|
||||
1. readme:
|
||||
2. readme:
|
||||
3. readme:
|
||||
|
||||
---
|
||||
```
|
||||
- 这个结构中,自修订条款“由deployer书面提交即生效。”还是应该作为单独条款。
|
||||
- 而另外增加一层结构定义“p=20,p%=20%”由自修订条款修订。在这层结构中,自修订条款以termid被引用,而不是text字段。
|
||||
|
||||
有两种解决方案:
|
||||
|
||||
### 方案一:强化新term
|
||||
|
||||
- 在新term基础上,
|
||||
- 新增body字段,作为高于subterm自条款一级的正文。用termid引用但是不增加sortid,view中也不增加prefix。
|
||||
- 废弃termset。
|
||||
|
||||
根据termset.01e1c775编辑的范例:
|
||||
```
|
||||
name: 调整分配主比例
|
||||
id: 1
|
||||
interface:
|
||||
entity:
|
||||
'1': deployer
|
||||
'2': director
|
||||
asset:
|
||||
'1': p
|
||||
text: |
|
||||
body:
|
||||
64eb9304:
|
||||
upgradeby: 64eb9304
|
||||
map:
|
||||
entity:
|
||||
'1': 1
|
||||
subterm:
|
||||
- sortid: 1
|
||||
type: term
|
||||
id: bba7c6f1
|
||||
upgradeby: 64eb9304
|
||||
path: PSMD/data/term.bba7c6f1.yaml
|
||||
map:
|
||||
asset:
|
||||
'1': 1
|
||||
- sortid: 2
|
||||
type: term
|
||||
id: 177700d4
|
||||
upgradeby: 64eb9304
|
||||
path: PSMD/data/term.177700d4.yaml
|
||||
map:
|
||||
entity:
|
||||
'1': 2
|
||||
readme: |
|
||||
depend:
|
||||
errorid:
|
||||
percent:
|
||||
text: |
|
||||
together:
|
||||
errorid:
|
||||
percent:
|
||||
text: |
|
||||
effect:
|
||||
errorid:
|
||||
percent:
|
||||
text: |
|
||||
```
|
||||
|
||||
### 方案二:保留termset
|
||||
|
||||
- 在termset中增加body字段,表示termset的正文,不增加sortid和prefix。
|
||||
- 在termset中取消path字段。
|
||||
- 在termset中effect基础上,增加depend togetther 字段。
|
||||
- 新term结构中可以去掉subterm字段。
|
||||
|
||||
详细方案在/PSMD/data/README.md
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240428140000"></a>
|
||||
## 14:00~14:29
|
||||
季度总结报告
|
||||
|
||||
- 继续完成月份总结报告。执行结果:
|
||||
```
|
||||
D:\huangyg\git\raw>node raw 202404
|
||||
......
|
||||
---
|
||||
月度报告
|
||||
四月份
|
||||
|
||||
日平均值,和三月份、去年四月份对比:
|
||||
热量1904.91kcal, +8.35、+146.62kcal;
|
||||
蛋白质85.05g, +7.90、+3.42g;
|
||||
脂肪54.72g, -4.45、+5.98g;
|
||||
碳水化合物273.40g, +2.93、+24.93g;
|
||||
钠1.94g, -0.20、+0.07g;
|
||||
膳食纤维34.74g, +0.78、+0.71g;
|
||||
钙1.36g, -0.02、+0.35g;
|
||||
水2468.86ml, -129.48、+385.34ml;
|
||||
|
||||
脂肪供能25.85% (AMDR:20~30%)
|
||||
碳水化合物供能57.41% (AMDR:50~65%)
|
||||
蛋白质供能17.86% (AMDR:10~15%)
|
||||
膳食纤维供能3.65%
|
||||
```
|
||||
|
||||
- 完成季度总结报告。执行结果:
|
||||
```
|
||||
D:\huangyg\git\raw>node raw 202403
|
||||
......
|
||||
---
|
||||
季度报告
|
||||
一季度
|
||||
|
||||
日平均值,和四季度、去年一季度对比:
|
||||
热量1922.30kcal, +85.39、-244.03kcal;
|
||||
蛋白质82.07g, -3.30、-24.14g;
|
||||
脂肪55.81g, +3.68、-17.93g;
|
||||
碳水化合物281.98g, +21.21、+14.63g;
|
||||
钠2.13g, -0.15、+0.59g;
|
||||
膳食纤维35.11g, -0.32、+8.71g;
|
||||
钙1.31g, +0.10、-0.08g;
|
||||
水2634.08ml, +265.66、+645.56ml;
|
||||
|
||||
脂肪供能26.13% (AMDR:20~30%)
|
||||
碳水化合物供能58.68% (AMDR:50~65%)
|
||||
蛋白质供能17.08% (AMDR:10~15%)
|
||||
膳食纤维供能3.65%
|
||||
```
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240428143000"></a>
|
||||
## 14:30~14:59
|
||||
debug-nodejs fs读写同一个文件的内容混乱
|
||||
|
||||
- 在 \ego\task\task.js drafttotask(date)中从draft收集log,写回task metadata文件的功能。在node task 1参数下调用。
|
||||
- 因为alltask metadata文件结构修改过,需要微调:
|
||||
- alltask.task -> alltask.tasklist
|
||||
- 以前缀 test. 复制一批task metadata文件,作为测试用。
|
||||
- 测试文件加上log字段。
|
||||
- 把写回语句从fs.writeFile() 改为writeFileSync() 运行正常。
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240428160000"></a>
|
||||
## 16:00~16:59
|
||||
填写term metadata的readme字段,增加成员无意识行为的特征
|
||||
|
||||
- 有些readme增加得勉强。
|
||||
- 先尽量填写,有真实体会再重新整理需求。
|
||||
- 按文件名排序,填写到 term.5c7d5a18
|
|
@ -0,0 +1,308 @@
|
|||
# 20240429
|
||||
|
||||
小结
|
||||
|
||||
<a id="top"></a>
|
||||
根据[ego模型时间接口](https://gitee.com/hyg/blog/blob/master/timeflow.md),今天绑定模版1。
|
||||
|
||||
| 时间片 | 时长 | 用途 | 手稿 |
|
||||
| --- | --- | --- | --- |
|
||||
| 04:00~04:14 | 15 | 休整 | |
|
||||
| 04:15~05:14 | 60 | 备餐、运动 | |
|
||||
| 05:15~05:59 | 45 | 早餐 | |
|
||||
| 06:00~06:44 | 45 | 会议、自习 | |
|
||||
| 06:45~07:44 | 60 | 休整 | |
|
||||
| 07:45~08:44 | 60 | 静默工作 | [设计新term结构](#20240429074500) |
|
||||
| 08:45~09:29 | 45 | 休整 | |
|
||||
| 09:30~10:59 | 90 | 静默工作 | [日小结时更新season metadata中time.sold字段,汇总waitinglist](#20240429093000) |
|
||||
| 11:00~13:59 | 180 | 备餐、午餐午休 | |
|
||||
| 14:00~14:29 | 30 | 静默工作 | [复习git,基于分支重新设计开发流程。](#20240429140000) |
|
||||
| 14:30~14:59 | 30 | 静默工作 | [初步熟悉npm、winget发布规则](#20240429143000) |
|
||||
| 15:00~15:59 | 60 | 休整 | |
|
||||
| 16:00~16:59 | 60 | 静默工作 | [测试划分有意识和下意识行为的措辞](#20240429160000) |
|
||||
| 17:00~18:59 | 120 | 晚餐 | |
|
||||
| 19:00~19:59 | 60 | 讨论、整理提交 | |
|
||||
|
||||
模版一采用静默工作方式。
|
||||
希望讨论的提纲发到 [huangyg@mars22.com](mailto:huangyg@mars22.com),通常安排在后面某天的早餐(5:15~5:59)或会议时间(6:00~6:45)。
|
||||
|
||||
|
||||
---
|
||||
<a id="index"></a>
|
||||
- 07:45 [设计新term结构](#20240429074500)
|
||||
- 09:30 [日小结时更新season metadata中time.sold字段,汇总waitinglist](#20240429093000)
|
||||
- 14:00 [复习git,基于分支重新设计开发流程。](#20240429140000)
|
||||
- 14:30 [初步熟悉npm、winget发布规则](#20240429143000)
|
||||
- 16:00 [测试划分有意识和下意识行为的措辞](#20240429160000)
|
||||
|
||||
---
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240429074500"></a>
|
||||
## 7:45~8:44
|
||||
设计新term结构
|
||||
|
||||
- 整理章节序号的需求
|
||||
- 收集开放结构文档的参考资料
|
||||
|
||||
### 需求
|
||||
|
||||
- 能够表达条款之间的关系:
|
||||
- A条款根据B条款修订
|
||||
- A角色由B、C、D角色根据C条款任免
|
||||
- E条款引用F条款
|
||||
- 能够根据需要改变序号,比如:
|
||||
- 全局排序
|
||||
```
|
||||
1. xxx
|
||||
2. xxx
|
||||
2.1. xxx
|
||||
2.1.1. xxx
|
||||
2.1.2. xxx
|
||||
2.2. xxx
|
||||
...
|
||||
123. xxx
|
||||
124. xxx
|
||||
```
|
||||
- 划分章节
|
||||
```
|
||||
第一章
|
||||
第一节
|
||||
1. xxx
|
||||
2. xxx
|
||||
第二节
|
||||
1. xxx
|
||||
1.1. xxx
|
||||
2. xxx
|
||||
附件一
|
||||
1. xxx
|
||||
2. xxx
|
||||
```
|
||||
- 在根据不同应用需求改变序号的同时,合同的结构已经运用经验能够稳定、持续地维护。被前提条件隔离得非常稀疏的实践者能够持续地异步交流。
|
||||
- 条款之间关系不能因为频繁更换序号而混乱。
|
||||
- 序号不能因为条款之间复杂关系而无法灵活变更。
|
||||
|
||||
### 开放结构文档
|
||||
|
||||
#### odf: Open Document Format
|
||||
|
||||
- https://www.oasis-open.org/standard/open-document-format-for-office-applications-opendocument-version-1-3
|
||||
- https://baike.baidu.com/item/odf/62028913
|
||||
- 用zip打包几个文件夹,包含content、meta、setting、style、manifest等xml文件。
|
||||
-
|
||||
- libreoffice writer保存的odf文件(*.odt)是二进制文件。
|
||||
- libreoffice writer保存的flat XML odf文件(*.fodt)是纯文本文件。
|
||||
- 使用<text:list-item>逐层嵌套,产生递增序号。
|
||||
- 序号可选数字、大小写字母、大小写罗马数字(应该不能跳号,不支持中文一二三),在text标签中增加text:style-name="Numbering_20_ABC"、"Numbering_20_IVX"等属性。
|
||||
-
|
||||
-
|
||||
|
||||
#### OpenXPS:Open XML Paper Specification
|
||||
|
||||
- https://www.ecma-international.org/wp-content/uploads/TC46-XPS-White-Paper.pdf
|
||||
-
|
||||
|
||||
#### UOF:Unified Office document Format
|
||||
|
||||
- https://baike.baidu.com/item/UOF2.0/3896124
|
||||
- libreoffice保存为*.uot文件,是纯文本xml文件。
|
||||
- 文本在字、字.句、字.句.文本串 <字:文本串 uof:locID="t0109" uof:attrList="标识符">2.1.1. xxx</字:文本串>
|
||||
- 编号在字、字.段落、字.段落.段落属性中<字:自动编号信息 uof:locID="t0059" uof:attrList="编号引用 编号级别 重新编号 起始编号" 字:编号引用="Numbering_20_ABC" 字:编号级别="0" 字:重新编号="1" 字:起始编号="1"/>
|
||||
|
||||
#### OFD:Open Fixed-layout Documents
|
||||
|
||||
- https://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=3AF6682D939116B6F5EED53D01A9DB5D
|
||||
- https://www.cnblogs.com/xxss0903/p/17884466.html
|
||||
- https://gitee.com/ofdrw/ofdrw
|
||||
-
|
||||
|
||||
#### tex
|
||||
|
||||
- https://ctan.org/
|
||||
- https://latexstudio.net/shredderyin/tex/tex_tds.html
|
||||
- 语法
|
||||
- https://zhuanlan.zhihu.com/p/52347414
|
||||
- https://localghost-blog.github.io/latex-tutorial/zh/docs/how-to-write-a-well-structured-latex-file/
|
||||
- https://tug.org/texlive/
|
||||
- https://www.cnblogs.com/liuliang1999/p/12656706.html
|
||||
- https://zhuanlan.zhihu.com/p/456055339
|
||||
- https://zhuanlan.zhihu.com/p/166523064
|
||||
|
||||
|
||||
|
||||
- term metadata专注于条款之间的关系
|
||||
- term format metadata专注于序号等排版关旭
|
||||
- 默认是txt、html
|
||||
- 争取支持ofd、tex
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240429093000"></a>
|
||||
## 9:30~10:59
|
||||
日小结时更新season metadata中time.sold字段,汇总waitinglist
|
||||
|
||||
### 流程
|
||||
|
||||
- 因为已经解决了metadata回写问题,所以不再需要创建todo metadata。
|
||||
- 各任务todo从task metadata集中到season metadata
|
||||
- 做计划时,自动从season metadata中按次序选出候选子任务,填入dayplan模版中,显示填充结果而不回写。
|
||||
- 人工调整season metadata,直至每种模版的绑定结果都符合预期。
|
||||
- 绑定模版时,一次生成draft metadata、time slice draft markdown、day plan view,直接从season metadata中删除对用todo项。
|
||||
|
||||
- 做日小结时,draft metadata+view -> day blog view
|
||||
- 更新season metadata中time.sold字段。
|
||||
- 更新task.log字段
|
||||
|
||||
|
||||
- 实现了finish.updateseason(date),做日小结时更新season metadata中time.sold字段。执行结果:
|
||||
```
|
||||
sold:
|
||||
ego: 1609
|
||||
PSMD: 2938
|
||||
infra: 30
|
||||
js: 199
|
||||
learn: 162
|
||||
xuemen: 60
|
||||
raw: 115
|
||||
```
|
||||
- 实现了 start.testdayplan: function () ,按当前各任务剩余时间顺序,遍历各任务todo字段,依序把todo项汇总。执行结果:
|
||||
```
|
||||
resttotal: 8192
|
||||
reset:
|
||||
PSMD: 4062
|
||||
learn: 838
|
||||
ego: 1391
|
||||
js: 1176
|
||||
xuemen: 540
|
||||
raw: 185
|
||||
|
||||
resetSOrted:
|
||||
- PSMD
|
||||
- ego
|
||||
- js
|
||||
- learn
|
||||
- xuemen
|
||||
- raw
|
||||
|
||||
waitinglist:
|
||||
'30':
|
||||
- task: js
|
||||
name: async
|
||||
- task: xuemen
|
||||
name: 数字发票试点
|
||||
- task: raw
|
||||
name: debug-灰枣按"个"作为单位被算出很高热量。
|
||||
- task: js
|
||||
name: promise 对象
|
||||
- task: raw
|
||||
name: 设计DRI metadata
|
||||
- task: PSMD
|
||||
name: 生成入门目录涉及的所有view,调整措池准备试用
|
||||
- task: ego
|
||||
name: 整理废弃git库,包括本地和远程。
|
||||
- task: js
|
||||
name: 学习AMD规范,如果适用就开发范例
|
||||
- task: learn
|
||||
name: 学习正则表达式RegExp
|
||||
- task: js
|
||||
name: 在js代码中进行git操作
|
||||
- task: raw
|
||||
name: debug-diff mode较大天数返回空数据,创建三个R文件。
|
||||
- task: PSMD
|
||||
name: PSMD委托合同的metadata
|
||||
- task: js
|
||||
name: 日期格式化
|
||||
readme: |
|
||||
https://www.cnblogs.com/biehongli/p/9327604.html
|
||||
https://juejin.cn/post/7199191689150644279
|
||||
https://blog.csdn.net/lwf3115841/article/details/129105206
|
||||
'60':
|
||||
- task: PSMD
|
||||
name: 设计条款内容与排版序号分离的新数据结构,编写metadata范例。
|
||||
- task: ego
|
||||
name: task waitinglist编码
|
||||
- task: learn
|
||||
name: 设计自己的git开发流程
|
||||
readme: >
|
||||
- https://ruanyifeng.com/blog/2015/08/git-use-process.html
|
||||
|
||||
- https://www.ruanyifeng.com/blog/2015/12/git-workflow.html
|
||||
|
||||
- https://www.jianshu.com/p/9801b98c1de4
|
||||
|
||||
-
|
||||
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
|
||||
- task: ego
|
||||
name: task之间结算体系设计
|
||||
- task: learn
|
||||
name: 把git开发流程编写成批处理文件
|
||||
- task: raw
|
||||
name: 实现自定义DRI的代码
|
||||
- task: PSMD
|
||||
name: 基于term metadata修改COM、deploy、COD等metadata
|
||||
- task: ego
|
||||
name: github + codeberg page 范例
|
||||
- task: learn
|
||||
name: nosql
|
||||
- task: ego
|
||||
name: 在season metadata中实现浮动时间表,修改日计划功能。
|
||||
- task: js
|
||||
name: 向外提供js文件的范例,为代码层级互通做准备
|
||||
'90':
|
||||
- task: PSMD
|
||||
name: 基于新的term +termset metadata修改代码commit, generate view
|
||||
readme: |
|
||||
- item字段里可以自由排练text、term,可以自由安排有title、prefix或没有。
|
||||
- title:单独显示,不改变内部序号。通常用做章、附件的开头。
|
||||
- prefix:向下改变所有内部序号,用"."依序连接起来。
|
||||
- item字段里的map增加title、prefix的映射。
|
||||
- 下级title可以在map被替换;
|
||||
- 下级prefix也在map被替换。
|
||||
- interface字段增加title字段,相当于目录。上级不提换就用本地的。
|
||||
- term commit
|
||||
- term metadata -> term view
|
||||
- task: xuemen
|
||||
name: 编写自动分录的代码
|
||||
- task: learn
|
||||
name: 把PSMD的data、src部分升级到rdf,如果升级成功则作为范例。
|
||||
'195':
|
||||
- task: xuemen
|
||||
name: xuemen COD metadata
|
||||
- task: PSMD
|
||||
name: term + COM matedata -> deploy metadata -> deploy view
|
||||
```
|
||||
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240429140000"></a>
|
||||
## 14:00~14:29
|
||||
复习git,基于分支重新设计开发流程
|
||||
|
||||
- https://ruanyifeng.com/blog/2015/08/git-use-process.html
|
||||
- https://www.ruanyifeng.com/blog/2015/12/git-workflow.html
|
||||
- https://www.jianshu.com/p/9801b98c1de4
|
||||
- https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240429143000"></a>
|
||||
## 14:30~14:59
|
||||
初步熟悉npm、winget发布规则
|
||||
|
||||
- https://learn.microsoft.com/zh-cn/windows/package-manager/package/
|
||||
- https://docs.npmjs.com/cli/v10/commands/npm-publish
|
||||
- https://packager.io/
|
||||
- https://gitee.com/repo
|
||||
|
||||
已经了解,需要时可以发布。
|
||||
|
||||
|
||||
[top](#top) | [index](#index)
|
||||
<a id="20240429160000"></a>
|
||||
## 16:00~16:59
|
||||
测试划分有意识和下意识行为的措辞
|
||||
|
||||
- https://www.zhihu.com/question/324451453/answer/3482762994
|
||||
- https://www.zhihu.com/question/649573115/answer/3482783271
|