g*r
2 楼
谢谢。
l*n
3 楼
方便吗？
J*n
4 楼
不是有卡号么，而且check in只要名字对上就行了吧
【在 f*******u 的大作中提到】
: spg住宿需要他们自己的会员卡么？申请信用卡的时候也没有给过这个spg的会员卡阿
【在 f*******u 的大作中提到】
: spg住宿需要他们自己的会员卡么？申请信用卡的时候也没有给过这个spg的会员卡阿
g*r
5 楼
谢谢。
z*e
6 楼
应该不行
java可以
用vert.x
java可以
用vert.x
f*i
7 楼
我是去年这个时候在北京面签的，取护照的地方选成中信的总行。周四上午签的，周五
晚上六点收到短信说可以拿了。
晚上六点收到短信说可以拿了。
l*n
8 楼
我用dotnet创建了一个web application，它直接用gulp了。
a9
9 楼
可以，为啥不行
【在 l**********n 的大作中提到】
: 方便吗？
【在 l**********n 的大作中提到】
: 方便吗？
B*r
10 楼
理论上讲什么都行，maven，ant，sbt，bower，npm。。。
真正试过的，msBuild有多傻逼不用我说了
【在 a9 的大作中提到】
: 可以，为啥不行
真正试过的，msBuild有多傻逼不用我说了
【在 a9 的大作中提到】
: 可以，为啥不行
N*n
11 楼
有DLL/JAR HELL问题的语言才需要MAVEN之类工具。.Net在设计上就推
荐Strong Name Signing, 所以不需要额外复杂的PACKAGE管理。
【在 B********r 的大作中提到】
: 理论上讲什么都行，maven，ant，sbt，bower，npm。。。
: 真正试过的，msBuild有多傻逼不用我说了
a9
12 楼
.net配合的是nuget
不过nuget对javascript支持不太好。我一般用nuget+bower
【在 N********n 的大作中提到】
:
: 有DLL/JAR HELL问题的语言才需要MAVEN之类工具。.Net在设计上就推
: 荐Strong Name Signing, 所以不需要额外复杂的PACKAGE管理。
不过nuget对javascript支持不太好。我一般用nuget+bower
【在 N********n 的大作中提到】
:
: 有DLL/JAR HELL问题的语言才需要MAVEN之类工具。.Net在设计上就推
: 荐Strong Name Signing, 所以不需要额外复杂的PACKAGE管理。
l*n
13 楼
oh.
【在 a9 的大作中提到】
: .net配合的是nuget
: 不过nuget对javascript支持不太好。我一般用nuget+bower
【在 a9 的大作中提到】
: .net配合的是nuget
: 不过nuget对javascript支持不太好。我一般用nuget+bower
g*g
14 楼
假定你做一个应用，使用了第三方类库A和B，A 依赖于类库C 1.0，B依赖于类库C 2.0
。1.0和2.0不兼容，Strong name怎么解决这个问题？
【在 N********n 的大作中提到】
:
: 有DLL/JAR HELL问题的语言才需要MAVEN之类工具。.Net在设计上就推
: 荐Strong Name Signing, 所以不需要额外复杂的PACKAGE管理。
。1.0和2.0不兼容，Strong name怎么解决这个问题？
【在 N********n 的大作中提到】
:
: 有DLL/JAR HELL问题的语言才需要MAVEN之类工具。.Net在设计上就推
: 荐Strong Name Signing, 所以不需要额外复杂的PACKAGE管理。
N*n
15 楼
类库C的1.0和2.0做成STRONG NAME SIGNED，名字看上去都是C.DLL，但
DIGITAL SIGNATURE不一样，其实就是俩不同的GUID。然后两个C.DLL加
载到系统的GLOBAL ASM CACHE中，在GAC中只认GUID不认名字。你的应
用程序在SETTINGS.XML中指明到底用哪个。如果1.0就给1的GUID，2.0
就2的GUID。
这个和编译原理的DECOUPLE重命名思路类似。编译器做分析时遇到代码
a = w + x; ... ...; a = y - z; 也是先DECOUPLE换名为a0 = w + x;
... ...; a1 = y - z; 之后再解决怎么优化。
【在 g*****g 的大作中提到】
: 假定你做一个应用，使用了第三方类库A和B，A 依赖于类库C 1.0，B依赖于类库C 2.0
: 。1.0和2.0不兼容，Strong name怎么解决这个问题？
g*g
16 楼
这东西只要一个第三方的不遵守你就挂了，看上去很美罢了。
【在 N********n 的大作中提到】
:
: 类库C的1.0和2.0做成STRONG NAME SIGNED，名字看上去都是C.DLL，但
: DIGITAL SIGNATURE不一样，其实就是俩不同的GUID。然后两个C.DLL加
: 载到系统的GLOBAL ASM CACHE中，在GAC中只认GUID不认名字。你的应
: 用程序在SETTINGS.XML中指明到底用哪个。如果1.0就给1的GUID，2.0
: 就2的GUID。
: 这个和编译原理的DECOUPLE重命名思路类似。编译器做分析时遇到代码
: a = w + x; ... ...; a = y - z; 也是先DECOUPLE换名为a0 = w + x;
: ... ...; a1 = y - z; 之后再解决怎么优化。
【在 N********n 的大作中提到】
:
: 类库C的1.0和2.0做成STRONG NAME SIGNED，名字看上去都是C.DLL，但
: DIGITAL SIGNATURE不一样，其实就是俩不同的GUID。然后两个C.DLL加
: 载到系统的GLOBAL ASM CACHE中，在GAC中只认GUID不认名字。你的应
: 用程序在SETTINGS.XML中指明到底用哪个。如果1.0就给1的GUID，2.0
: 就2的GUID。
: 这个和编译原理的DECOUPLE重命名思路类似。编译器做分析时遇到代码
: a = w + x; ... ...; a = y - z; 也是先DECOUPLE换名为a0 = w + x;
: ... ...; a1 = y - z; 之后再解决怎么优化。
l*n
17 楼
if an assembly depends on another assembly that is not strongly named, it
cannot be registered in the GAC. In cases where the code of the third-party
assembly is not in the programmer's possession, transforming the assembly to
be strongly named can in fact be impossible.
cannot be registered in the GAC. In cases where the code of the third-party
assembly is not in the programmer's possession, transforming the assembly to
be strongly named can in fact be impossible.
g*g
18 楼
我老人家虽然不写C#，猪走路看多了。这世界上本来就没有silver bullet。还看到一
条，这是连向下兼容都做不到呀。
By default, applications will only run with the version of the .NET
Framework used to compile it, which can cause the application to fail on
machines with newer versions of the .NET Framework installed — even when
the application would normally run properly with the newer version.
party
to
【在 l**********n 的大作中提到】
: if an assembly depends on another assembly that is not strongly named, it
: cannot be registered in the GAC. In cases where the code of the third-party
: assembly is not in the programmer's possession, transforming the assembly to
: be strongly named can in fact be impossible.
条，这是连向下兼容都做不到呀。
By default, applications will only run with the version of the .NET
Framework used to compile it, which can cause the application to fail on
machines with newer versions of the .NET Framework installed — even when
the application would normally run properly with the newer version.
party
to
【在 l**********n 的大作中提到】
: if an assembly depends on another assembly that is not strongly named, it
: cannot be registered in the GAC. In cases where the code of the third-party
: assembly is not in the programmer's possession, transforming the assembly to
: be strongly named can in fact be impossible.
N*n
19 楼
对于开发.Net的来说SN属于入门级常识。这个都整不清楚的第三方也写
不出啥好类库来。
【在 g*****g 的大作中提到】
: 这东西只要一个第三方的不遵守你就挂了，看上去很美罢了。
N*n
20 楼
向下兼容很简单。把RUNTIME按版本拆开，1.0, 2.0, 3.0...都有各自独
立的RUNTIME。代码如果对版本不敏感系统就用最新的RUNTIME执行。如
果敏感在编译时指定具体用哪个版的RUNTIME。加载代码时系统会根据设
定选择合适的RUNTIME。简单的DIVIDE & CONQUER模块化设计。像JAVA那
样从1.0到8.0全挤在一个RUNTIME里面互相制肘属于DESIGN FLAW。
【在 g*****g 的大作中提到】
: 我老人家虽然不写C#，猪走路看多了。这世界上本来就没有silver bullet。还看到一
: 条，这是连向下兼容都做不到呀。
: By default, applications will only run with the version of the .NET
: Framework used to compile it, which can cause the application to fail on
: machines with newer versions of the .NET Framework installed — even when
: the application would normally run properly with the newer version.
:
: party
: to
g*g
21 楼
你别逗了，不向下兼容这么一个简单事实，还要粉饰成这样。我一个应用，从.Net 1.0
到.Net 5.0各用了一个类库，结果就是部署到客户上，每个客户得哼唧哼唧地把.Net所
有版本下全了才能跑。这就你的divide and conquer? 我看实质上就是静态编译把所有
runtime一起打包。微软被秒得一塌糊涂不是没有原因的。
【在 N********n 的大作中提到】
:
: 向下兼容很简单。把RUNTIME按版本拆开，1.0, 2.0, 3.0...都有各自独
: 立的RUNTIME。代码如果对版本不敏感系统就用最新的RUNTIME执行。如
: 果敏感在编译时指定具体用哪个版的RUNTIME。加载代码时系统会根据设
: 定选择合适的RUNTIME。简单的DIVIDE & CONQUER模块化设计。像JAVA那
: 样从1.0到8.0全挤在一个RUNTIME里面互相制肘属于DESIGN FLAW。
到.Net 5.0各用了一个类库，结果就是部署到客户上，每个客户得哼唧哼唧地把.Net所
有版本下全了才能跑。这就你的divide and conquer? 我看实质上就是静态编译把所有
runtime一起打包。微软被秒得一塌糊涂不是没有原因的。
【在 N********n 的大作中提到】
:
: 向下兼容很简单。把RUNTIME按版本拆开，1.0, 2.0, 3.0...都有各自独
: 立的RUNTIME。代码如果对版本不敏感系统就用最新的RUNTIME执行。如
: 果敏感在编译时指定具体用哪个版的RUNTIME。加载代码时系统会根据设
: 定选择合适的RUNTIME。简单的DIVIDE & CONQUER模块化设计。像JAVA那
: 样从1.0到8.0全挤在一个RUNTIME里面互相制肘属于DESIGN FLAW。
T*i
22 楼
大家侧重点不同罢了。
记得当年看webcast一个烙印解释了这么做的原因之一。同样的函数。在不同的.Net版
本上实现不一样。他还举了一个例子，某个程序的解决取决于两个函数并发执行完成的
先后顺序。
结果升级到高版本性能改进，latency变了，完成次序就变了。结果就不对了。给他们
指出来你原来的代码本来就有问题。人家说，我不care！
严格的runtime绑定确实能够解决这类问题。
我的系统，从IDE到version control到management console都是自己写的。dll hell就
根本不是问题了。
.0
【在 g*****g 的大作中提到】
: 你别逗了，不向下兼容这么一个简单事实，还要粉饰成这样。我一个应用，从.Net 1.0
: 到.Net 5.0各用了一个类库，结果就是部署到客户上，每个客户得哼唧哼唧地把.Net所
: 有版本下全了才能跑。这就你的divide and conquer? 我看实质上就是静态编译把所有
: runtime一起打包。微软被秒得一塌糊涂不是没有原因的。
记得当年看webcast一个烙印解释了这么做的原因之一。同样的函数。在不同的.Net版
本上实现不一样。他还举了一个例子，某个程序的解决取决于两个函数并发执行完成的
先后顺序。
结果升级到高版本性能改进，latency变了，完成次序就变了。结果就不对了。给他们
指出来你原来的代码本来就有问题。人家说，我不care！
严格的runtime绑定确实能够解决这类问题。
我的系统，从IDE到version control到management console都是自己写的。dll hell就
根本不是问题了。
.0
【在 g*****g 的大作中提到】
: 你别逗了，不向下兼容这么一个简单事实，还要粉饰成这样。我一个应用，从.Net 1.0
: 到.Net 5.0各用了一个类库，结果就是部署到客户上，每个客户得哼唧哼唧地把.Net所
: 有版本下全了才能跑。这就你的divide and conquer? 我看实质上就是静态编译把所有
: runtime一起打包。微软被秒得一塌糊涂不是没有原因的。
N*n
23 楼
对呀，有错死撑不改的RUNTIME向下兼容性当然好了。
另外你自己的代码难道还不知道用那个版本.Net？既然知道在安装程序里
加上.Net版本的检测, 用户如果没有你的安装程序负责装载就完了。
一个简单DIVIDE & CONQUER思路就解决版本冲突了，JAVA还非要多个版本
全挤在一个RUNTIME里面。为啥JAVA加个FEATURE总那么难？就是因为要三
姑、四舅、五婶全挤在一个屋檐下, 加个新FEATURE得罪哪个都不行，作
茧自缚。典型的DESIGN FLAW，井底JAVA还要洗地。
【在 g*****g 的大作中提到】
: 你别逗了，不向下兼容这么一个简单事实，还要粉饰成这样。我一个应用，从.Net 1.0
: 到.Net 5.0各用了一个类库，结果就是部署到客户上，每个客户得哼唧哼唧地把.Net所
: 有版本下全了才能跑。这就你的divide and conquer? 我看实质上就是静态编译把所有
: runtime一起打包。微软被秒得一塌糊涂不是没有原因的。
l*n
24 楼
GAC才是问题根源，private assembly没有版本问题，java更没有问题
【在 N********n 的大作中提到】
:
: 对呀，有错死撑不改的RUNTIME向下兼容性当然好了。
: 另外你自己的代码难道还不知道用那个版本.Net？既然知道在安装程序里
: 加上.Net版本的检测, 用户如果没有你的安装程序负责装载就完了。
: 一个简单DIVIDE & CONQUER思路就解决版本冲突了，JAVA还非要多个版本
: 全挤在一个RUNTIME里面。为啥JAVA加个FEATURE总那么难？就是因为要三
: 姑、四舅、五婶全挤在一个屋檐下, 加个新FEATURE得罪哪个都不行，作
: 茧自缚。典型的DESIGN FLAW，井底JAVA还要洗地。
【在 N********n 的大作中提到】
:
: 对呀，有错死撑不改的RUNTIME向下兼容性当然好了。
: 另外你自己的代码难道还不知道用那个版本.Net？既然知道在安装程序里
: 加上.Net版本的检测, 用户如果没有你的安装程序负责装载就完了。
: 一个简单DIVIDE & CONQUER思路就解决版本冲突了，JAVA还非要多个版本
: 全挤在一个RUNTIME里面。为啥JAVA加个FEATURE总那么难？就是因为要三
: 姑、四舅、五婶全挤在一个屋檐下, 加个新FEATURE得罪哪个都不行，作
: 茧自缚。典型的DESIGN FLAW，井底JAVA还要洗地。
g*g
25 楼
你丫死撑倒是一把好手。一个程序不过十兆。结果装了2小时几个 G 的 runtime才能跑
，能有几个有那耐心。你软太垃圾，只能用这种土办法，还觉得牛逼了。
【在 N********n 的大作中提到】
:
: 对呀，有错死撑不改的RUNTIME向下兼容性当然好了。
: 另外你自己的代码难道还不知道用那个版本.Net？既然知道在安装程序里
: 加上.Net版本的检测, 用户如果没有你的安装程序负责装载就完了。
: 一个简单DIVIDE & CONQUER思路就解决版本冲突了，JAVA还非要多个版本
: 全挤在一个RUNTIME里面。为啥JAVA加个FEATURE总那么难？就是因为要三
: 姑、四舅、五婶全挤在一个屋檐下, 加个新FEATURE得罪哪个都不行，作
: 茧自缚。典型的DESIGN FLAW，井底JAVA还要洗地。
，能有几个有那耐心。你软太垃圾，只能用这种土办法，还觉得牛逼了。
【在 N********n 的大作中提到】
:
: 对呀，有错死撑不改的RUNTIME向下兼容性当然好了。
: 另外你自己的代码难道还不知道用那个版本.Net？既然知道在安装程序里
: 加上.Net版本的检测, 用户如果没有你的安装程序负责装载就完了。
: 一个简单DIVIDE & CONQUER思路就解决版本冲突了，JAVA还非要多个版本
: 全挤在一个RUNTIME里面。为啥JAVA加个FEATURE总那么难？就是因为要三
: 姑、四舅、五婶全挤在一个屋檐下, 加个新FEATURE得罪哪个都不行，作
: 茧自缚。典型的DESIGN FLAW，井底JAVA还要洗地。
相关阅读
魏老师这种才是得阿三的真传goodbug是大系统里的南郭先生而已为了不至于谬种流传我还是回应一下吧大型系统这些年魏老师要求谁质疑谁举证异步编程+FP的程序的可读性太差TeacherWei给说说c++的前景吧古德巴大牛，请看这个设计题这次Scala学Clojure有点不地道了魏老师的方案这行就是三天不学习，赶不上刘少奇周末上点有用的信息goodbug短短6行代码7个常识错误已经在家一个多月没去office了有游戏app经验的来说说，这个数据大概靠谱吗？微软就是毁在愚蠢的PGM上面了node太牛逼了，这次把Scala也给干了review了一下魏老师的原文，我发现我没有说错啊如果要做一个铁路售票网站学机械的也来设计火车票了！