#10 楼 @feng88724 那是因为你的服务器时间就是 UTC(+0) 时间,你把你服务器时区调成其他时区 (比如 +8 ) 试试就知道区别了。
:plus1:
哈哈,亲眼所见,确实拦不住,有东西分享,还拦不住的分享,是份幸事
确认昨天没有么,我昨天整个下午也不能访问
@nightire 求荐 ES6 的好书
帮顶!!
是要比 Ctrl + V 好用一些~~~,学习了, :)
我觉得 这个招聘的主要对象是:一个屌到渣的阉人,而且还是 Ruby 大牛。
是的,在中国这个盗版风行的社会里,软件价值 ~= 没有价值。 曾经做过一个项目,我们花大量时间研发产品,sales 卖出的产品目录里,硬件价格是成本的 200 倍,软件价格写的是附赠。 曾经有一个朋友,想将他传统公司业务也搬到互联网,问到我,我问他准备在这上面花多少钱,他说 5000 够不够,我嘴角动了动。
即使是对整个行业了解的,就如文章中说的那样,在国内,花 1000 块钱想做 20000 块钱的事,而且最关键的是,很难得到认可。
@greatghoul 棒棒哒~,加油~~
2010 年,刚步入外包行列,主要通过搜索引擎来搜索别人发布的需求。经过初期的尝试之后,我们果断放弃了两种类型的项目:
- 国内的项目
看到这里,我哈哈哈哈哈哈哈哈~~~~
哈哈,我知道天海翼,LOL,玩笑,误喷!
:), 只用到过两个~~~
哈哈,帮顶~
nginx 不能做 websocket 负载均衡的吧,apache 也是最近几个版本才支持 websocket 的负载均衡~~
可以参考 java,groovy 界的 gradle,可以将所有的依赖生成一个 dependency tree,一目了然~
好吧,珠海的,要顶一下
给他搭个 vm 环境,定期 pull。 前期告诉他大概更改哪些位置可生效 js, css,后期让他慢慢摸索,跟着学。磨合少不了的。
@flowerwrong Session Sticky 就是让同一个 user 的 request 始终 talk 到同一个 back end server,一般在 LB 上设置,比如 HAProxy, Nginx 或者是 AWS 的 ELB 都支持 Session Sticky.
另外我还少列了一种,
根据你项目的规模跟需求,选择不同的架构方式。比如规模,用户群都还不是很大,直接使用 Session Sticky,简单易用,不需额外的代码更改即可支持。复杂点,系统高性能,高安全性,高可扩展性,绝对不能 down 机,就用 Session Centralization。
Cluster 未必一定要用 session replication。
简单给你列几个解决方案:
Session sticky: 通过在 LB 上设置。 优点:开销最小,实现简单。缺点:其中一个 node down 了,session 将会直接丢失。
Session replication: 在不同 node 上进行 session 同步。 优点:效率比较高。缺点:当架构中 node 比较多的时候,session replication 所带了的 traffic 将会是你的噩梦,而且不易于扩展 node,因为 session replication 需要节点中的 node aware 所有的其他 node 节点,增加一台 node 需要更新其他所有 node 配置。
Session centralization: 将 session 存储到一个 server 上,所有的 node 都连接到这个 server 存取 session。 优点:node 易于管理,扩展。缺点:一般 session server 也需要做一个小的 cluster.
CQ 的,一定要頂~~~
不是说 论坛被查水表了吗,反而还快了?
现在没有两个屏幕才是受不了~~
哦哦哦,先赞一个,晚上回去慢慢看~
ruby, rails,groovy,grails,swift, node, 排名有分先后~
AWS Free Tier~~
广州什么时候开始有了,到时回去看下,赞!