z****e
发帖数: 54598 | 1 继承现在已经很少用了
spring等framework的出现已经解决了这种强耦合的问题
从vert.x的impl中可以明显感觉到
java的很多idea，比其他语言尤其是脚本，要领先大概2-3个generation
其他脚本多数还停留在ejb2的那个年代
来制造并定义出各种恶心的接口和配置，跟ejb本质上是一样的
npm其实就是一个war
这些迟早都要被淘汰掉，我们可以把事情做得更简单 |
|
p*****2
发帖数: 21240 | 2 node讲究的就是npm
你说的还是static dynamic的区别 跟js没关系 |
|
d******e
发帖数: 2265 | 3 Developing Node Applications
Visual Studio Code is written in TypeScript/JavaScript and is powered by a
Node server. We use VSCode to create VSCode and as a result, you get a great
end-to-end development experience when building Node applications.
Node
Node is a platform for building fast and scalable server applications using
JavaScript. Node is the runtime (Node) and NPM is the Package Manager for
Node modules.
First things first, install Node for your platform.
https://code.visualstudio.com/d... 阅读全帖 |
|
z****e
发帖数: 54598 | 4 或者你想想如何整个postgresql的worker，这种流行db
应该npm上有很多人做过了，但是还是用postgresql在这里不是一个好idea |
|
|
l**********n
发帖数: 8443 | 6 "不过后来每次升级都会break以前的东西" => 这个很常见。
我一个简单的npm install都会break code。
node社区的问题是升级根本不考虑支持旧的版本 |
|
n*****t
发帖数: 22014 | 7 现在就是这样实现，npm start 的时候 build tree，存到 json，ajax 到 client 由
angular render 成 menu |
|
z*******3
发帖数: 13709 | 8 http://vertx.io/
3.0，目前支持四种语言，java，groovy，ruby和javascript
上次看说打算3.0一开始只支持java和javascript
但是这次出来多了另外两个，哦也
几个重要的features
1）官方web framework，可以直接当web server用了
2）rx和rx stream的支持，streaming的支持很重要
3）jdbc支持，现在不用为jdbc是同步的烦恼了，可以直接连db了
4）mongo和redis的支持，c*支持还在制作中
5）docker的支持，qa和operation应该喜欢这个
6）去掉了对gradle以及maven的依赖，不再需要这两个生成模板
可用可不用，对于不会用maven和gradle的笨蛋来说，是一个福音
7）去掉了对eclipse等ide的依赖，用vi一样可以可以很容易hello world
是不会用eclipse笨蛋的福音，当然你在ide中一样可以轻松debug
8）可以直接使用node.js的npm
9）metrics支持，这个没太看懂是啥，目前支持java，groovy和ruby
10）j... 阅读全帖 |
|
l**********n
发帖数: 8443 | 9 vertx和node什么关系？vertx能用npm吗？ |
|
|
T********i
发帖数: 2416 | 11 我现在bootstrap, jquery, node, react, redis, flux, npm都玩得比较顺手了
Programming其实就是stackoverflow search。真没啥搞头。
还是基本功重要。这个是搜不着的。 |
|
|
|
l**********n
发帖数: 8443 | 14 我用dotnet创建了一个web application，它直接用gulp了。 |
|
|
N********n
发帖数: 8363 | 16
有DLL/JAR HELL问题的语言才需要MAVEN之类工具。.Net在设计上就推
荐Strong Name Signing, 所以不需要额外复杂的PACKAGE管理。 |
|
a9
发帖数: 21638 | 17 .net配合的是nuget
不过nuget对javascript支持不太好。我一般用nuget+bower |
|
|
g*****g
发帖数: 34805 | 19 假定你做一个应用，使用了第三方类库A和B，A 依赖于类库C 1.0，B依赖于类库C 2.0
。1.0和2.0不兼容，Strong name怎么解决这个问题？ |
|
N********n
发帖数: 8363 | 20
类库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
发帖数: 34805 | 21 这东西只要一个第三方的不遵守你就挂了，看上去很美罢了。 |
|
l**********n
发帖数: 8443 | 22 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. |
|
g*****g
发帖数: 34805 | 23 我老人家虽然不写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 |
|
N********n
发帖数: 8363 | 24
对于开发.Net的来说SN属于入门级常识。这个都整不清楚的第三方也写
不出啥好类库来。 |
|
N********n
发帖数: 8363 | 25
向下兼容很简单。把RUNTIME按版本拆开，1.0, 2.0, 3.0...都有各自独
立的RUNTIME。代码如果对版本不敏感系统就用最新的RUNTIME执行。如
果敏感在编译时指定具体用哪个版的RUNTIME。加载代码时系统会根据设
定选择合适的RUNTIME。简单的DIVIDE & CONQUER模块化设计。像JAVA那
样从1.0到8.0全挤在一个RUNTIME里面互相制肘属于DESIGN FLAW。 |
|
g*****g
发帖数: 34805 | 26 你别逗了，不向下兼容这么一个简单事实，还要粉饰成这样。我一个应用，从.Net 1.0
到.Net 5.0各用了一个类库，结果就是部署到客户上，每个客户得哼唧哼唧地把.Net所
有版本下全了才能跑。这就你的divide and conquer? 我看实质上就是静态编译把所有
runtime一起打包。微软被秒得一塌糊涂不是没有原因的。 |
|
T********i
发帖数: 2416 | 27 大家侧重点不同罢了。
记得当年看webcast一个烙印解释了这么做的原因之一。同样的函数。在不同的.Net版
本上实现不一样。他还举了一个例子，某个程序的解决取决于两个函数并发执行完成的
先后顺序。
结果升级到高版本性能改进，latency变了，完成次序就变了。结果就不对了。给他们
指出来你原来的代码本来就有问题。人家说，我不care！
严格的runtime绑定确实能够解决这类问题。
我的系统，从IDE到version control到management console都是自己写的。dll hell就
根本不是问题了。
.0 |
|
N********n
发帖数: 8363 | 28
对呀，有错死撑不改的RUNTIME向下兼容性当然好了。
另外你自己的代码难道还不知道用那个版本.Net？既然知道在安装程序里
加上.Net版本的检测, 用户如果没有你的安装程序负责装载就完了。
一个简单DIVIDE & CONQUER思路就解决版本冲突了，JAVA还非要多个版本
全挤在一个RUNTIME里面。为啥JAVA加个FEATURE总那么难？就是因为要三
姑、四舅、五婶全挤在一个屋檐下, 加个新FEATURE得罪哪个都不行，作
茧自缚。典型的DESIGN FLAW，井底JAVA还要洗地。 |
|
l**********n
发帖数: 8443 | 29 GAC才是问题根源，private assembly没有版本问题，java更没有问题 |
|
g*****g
发帖数: 34805 | 30 你丫死撑倒是一把好手。一个程序不过十兆。结果装了2小时几个 G 的 runtime才能跑
，能有几个有那耐心。你软太垃圾，只能用这种土办法，还觉得牛逼了。 |
|
h******b
发帖数: 6055 | 31 说的是同时代产品，node要比也是go/scala这些。
node让前端人员能不学新语言玩full stack开发，加上mean/npm这套东西，彻底打开了
糙快猛javascript的大门。空前绝后，不亚于当年php/mysql的崛起。
php跟Windows一样，有了脸书，wordpress, magento, drupal, joomla这几个系统，要
死几乎不可能。
但新出来的东西基本上跟他没关系了。 |
|
m****l
发帖数: 71 | 32 兄弟在做这方面的开发，现接近完成上线，想和大家请教一下node.js安全上的问题。
我现在考虑的node.js 安全，主要是input validation, rate limitation什么的。
Input validation, 我找到了 node.js 有关的 validator 和它的两个sisiter npm,
express-validator 与 mongoose-validator.
StrongLoop 有相关的rate limitation, 包括基于ip 和API流量的，但它这部分好像不
是open source, 我在package 中没有找到。Google 了一下，也有几个，node-rate-
limiter等.
想和大牛请教一下，大家工作中常用的node.js express 安全module 是那些？除了
input validation, rate limitation之外我还需要注意哪些方面的问题，给几个
pointer 兄弟就万分感谢了。 |
|
|
z****e
发帖数: 54598 | 34
no
水平达不到，我怀疑这里有没有人有被vert.x组看上的实力
vert.x的作者很有实力，一般至少是apache top level project的lead吧
我看那几个core developers都是这个级别的 |
|
|
z****e
发帖数: 54598 | 36
我觉得vert.x的文档更出彩
不过他们的code里面有大量的注释
直接看javadoc其实就能看懂了 |
|
x*******6
发帖数: 262 | 37 请问赵老师vertx的application一般怎么在server上跑？看它的例子好像java -jar 就
可以运行了，查了下可以把一个jar打包成后台service跑，是这样吗 |
|
z****e
发帖数: 54598 | 38 http://github.com/vert-x3/vertx-examples/blob/master/README.ado
好几种方法
一种是设置path之后，用vertx命令行跑
简单说就是安装jdk，把jdk和vert.x的文件夹放到path里面去
然后vert.x run ***.java/groovy/ruby etc.
还有一种就是用代码方式调用，需要拿到Vertx的obj
然后从你的代码运行vert.x，怎么运行你自己的代码那就看你自己了
你可以写一个main函数，然后run
如果你想用java -jar的方式的话，需要把vert.x打包成jar
这个是x3新增的功能，你可以试试
这样做你可能需要maven或者gradel
但是不需要把vert.x的目录放到path中去了 |
|
c*******9
发帖数: 9032 | 39 如果是http web为主的项目，Vert.x3 和sevlet开发难易程度差不多吧， 能代替多少
struts＋spring＋hibernate的功能？ |
|
z****e
发帖数: 54598 | 40
struts现在已经没多少人在用了
我看struts一些子项目都停止开发了
基本上被spring mvc所取代
现在比较常见的common legacy组合应该是
spring + tomcat + hibernate
这几个都比较难替代，虽然vert.x效率要高点
但是legacy code应该都不会改
vert.x主要的竞争领域在于web service部分
以及将来很快就要到来的streaming部分
借用rxjava的推力，应该vert.x的应用领域会得到进一步的拓展
vert.x跟spring mvc, node.js, akka甚至ejb这些都有竞争
甚至还把手伸向了hdfs，script language support这种领域
但是又都不完全重合，所以vert.x的前景会比较看好
因为随便一个领域成功了，就会把其他部分给带动起来
当有人意识到用vert.x搞一整套eco有多么轻松之后
他们就不会在回到以前那种system integration的阶段去了
因为integration是比较折腾的一件事，要对付不同系统
要测试，要写代码，比较麻烦，vert.x简单很多 |
|
z****e
发帖数: 54598 | 41 hibernate的功能比较难直接替代
但是你自己用hibernate在vert.x中也不难
spring的话，这个社区正在讨论，要不要做di
java程序员呼声很高，但是其他语言程序员反对
所以暂时先放下，主要是其他语言无法实现di，缺乏jee那种标准
哪怕是spring都比较少见，所以暂时先不搞，而且fp很难di
clojure这种di就怪异了，tomcat和spring mvc暂时不会有激进的改变
就像对于node.js,akka这些也都暂时不会有太大的影响
但是会逐步蚕食这些东西的市场，迟早的事
不管怎样，用vert.x就走在所有人的前面
可以接触很多新的东西，比如rxjava, streaming，docker, nosql多有趣啊
spring那些都用了很多年了，程序员需要进步进步不是？
老用lamp也会腻的 |
|
|
|
c*******9
发帖数: 9032 | 44 Vert.x 和nosql 有什么关系？
要说服组里的人采用新东西不容易。 |
|
|
z****e
发帖数: 54598 | 46
vert.x做了一个简单的file system
理论上这个往上做的话，可以作出一个nosql db出来
就像hdfs -> hbase这种关系
或者cfs -> cassandra
另外一个关系就是vert.x对于nosql的支持比较重视
因为nosql大多数对于async的api提供得比较快
相对于db而言，所以vert.x比较快地跟nosql接轨起来
所以选择persistence的时候，选到了nosql的话
jvm上留给你的选择就不多了，比如传统的servlet+spring+hibernate这个
就不见得很合适，因为api都是同步的，vert.x都是异步的
vert.x不用马上替换，你可以一点一点加进去
vert.x3有一个很容易integrate到现有系统的方法
你看文档，只需要拿到Vertx vertx这个obj就可以做了 |
|
z****e
发帖数: 54598 | 47
官方已经有了mongo什么的api
正在做cassandra的官方驱动，稍等一段就有
这个是非官方的 |
|
|
z****e
发帖数: 54598 | 49
streaming就是适合那种结束边界不确定但是传入的data又比较同质化的datasource
像netflix搞的视频就很像这个东东，还有message
streaming应该在将来一段时间内会逐步流行开来
以前是storm在搞，再早一点是jms，不过jms主要是无状态的dataset
fp部分用来搞streaming会比较容易
常见的map，可以直接apply func到每一个elements上去
这样你就不用for loop了，因为for loop需要知道确切的结束边界
对于streaming，没有fp那么好用，listener+fp可以比较快速地开发出东西来
那rxjava就是为了adopt这种趋势而生的东东
vert.x的reactive部分，就是直接用了rxjava
rxjava不仅仅是java，其实所有jvm上的reactive都可以用
包括rxscala, rxclojure，当然scala clojure这种天生就是fp，不需要这个一样搞
但是api标准化总是好的，还有rxgroovy
作为游戏，我觉得每一局pvp的话，其实广播的部分可以搞成streaming
用... 阅读全帖 |
|
z****e
发帖数: 54598 | 50 所以我个人认为，技术革新已经逐步转移到了netflix这家公司上去
rxjava这种神奇的东西，不是google之类的做出来的
反而是netflix在搞，而且netflix很喜欢优化aws
做各种傻瓜化折腾aws的工具，我相信用不了多久
netflix的这些傻瓜化的工具会逐步流行开来
rxjava的接口什么比较标准，scala的很多东西就不那么标准
就这个差别，本质上原理是一样的
vert.x在rxjava的基础之上做了pump那些，不过我还没怎么用过
不确定这个到底怎么搞，只是听以前做scala的人提起，说大并发时候需要这个东西 |
|
