V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  jybox  ›  全部回复第 16 页 / 共 64 页
回复总数  1267
1 ... 12  13  14  15  16  17  18  19  20  21 ... 64  
2017-02-22 18:58:10 +08:00
回复了 Powered 创建的主题 程序员 分布式 CAP 理论的一个问题请教
可以设想一下,假设出现了分区( P ),就是你的服务器被分成了两个部分,每个部分内部可以通讯,也都可以分别对外服务,但两个部分之间不能通讯。这个时候你就必须做出一个选择:

1. 要么保证可用性( A ),继续允许读写操作,但因为两个部分无法同步数据,所以会出现不同步( C )
2. 或者保证一致性( C ),拒绝写入操作,直到两个部分恢复再允许写入,但这样就会出现服务不可用( A )

或者如果你可用性和一致性都需要的话,那你就无法满足分区容错性。
2017-02-20 10:46:32 +08:00
回复了 RihcardLu 创建的主题 程序员 编码、摘要、加密的区别
关于散列的进一步讨论可以看我的这篇文章: https://jysperm.me/2014/02/1476/ (三年前写的,可能有的地方不恰当,但刚刚我又看了一遍,大体没问题)。

其实我觉得「散列」这个意译要比「哈希」好很多,楼主的文章没有提到散列这个称呼。
2017-02-19 16:57:31 +08:00
回复了 ibegyourpardon 创建的主题 HTTP 今天才知道 HTTP/2 开始被人缩写成 h2 了 ……
@Chingim H5 主要是含义不明确吧, h2 指的就是 HTTP/2 的协议和支持情况。但 H5 指的并不只是 HTML5 (相信如果大家要指狭义的 HTML5 应该不会用 H5 这个缩写),而是指 HTML5 以及同时代的其他 W3C 标准( CSS 、 XHR 、 SVG 、触控和其他传感器)、 JavaScript 标准( ES6/7/8 )。而且 H5 隐含的意思还包括:不用 Flash 、可以在微信中运行、炫酷的交互效果、 Web App 等等。
2017-02-17 18:47:37 +08:00
回复了 murmur 创建的主题 健康 程序员也要爱护自己眼睛 再推荐一个眼药水 远离营销号
2017-02-17 18:44:46 +08:00
回复了 murmur 创建的主题 健康 程序员也要爱护自己眼睛 再推荐一个眼药水 远离营销号
我现在在用参天制药的「玻璃酸钠滴眼液(爱丽)」,是医生给开的, 5ml/0.1%,看包装上的标注成分和海露完全一样(只有玻璃酸钠),是否是楼主后面提到的不建议使用的那种?
2017-02-16 21:12:40 +08:00
回复了 vertigo 创建的主题 分享创造 [另类想法] 如何保证一条消息十几年后才能被读取
问题是一个很有趣的问题,不过楼主的想法有两个问题:

一是很多人已经提过了,散列算法的解不是唯一的,你其实可以选择一个对称加密算法来做这个事情。

二是散列和对称加密都是可以并行计算的,也就是说如果有人有足够的计算力,靠堆机器,也是可以提前求得解的,可以考虑使用一种无法并行破解的算法来进行加密,这样只有单个 CPU 的计算能力达到一定程度才能解密,更符合楼主的初衷。
2017-02-16 12:43:17 +08:00
回复了 noli 创建的主题 程序员 RESTful 有用吗? HTTP 有 GET POST 就足够了?
其实我的想法和楼主差不多(两年多以前我也在 V2EX 发过类似的帖子),即我是觉得 RESTful 并不能覆盖到所有的情况,硬要把不适合的业务对应到「资源」是个费力不讨好的事情。但确实如果能够顺着 RESTful 的思路的话,会有一些比较方便的工具可用,所以也没有必要非要「不遵守」 RESTful 。所以我觉得在做 API 设计的时候,最重要的是项目本身能够统一和自恰,适合 RESTful 的部分就用,不适合的情况也没必要硬往上靠。

RESTful 和 HTTP 本身的关系并没有那么密切,关于如何设计基于 HTTP 的 API 实际上不止 RESTful 一个方案。
@Balthild 其实把 JS/CSS 文件放在自己的网站上算不算「分发」本来就有些争议,我看 WordPress 的文档中有一段很有趣: If you are not distributing your software – for example, a theme used only by yourself or on your local machine – you do not need to adopt the GPL.

它没说「 on your server 」而是说了「 on your local machine 」。当然我只是随便一说,我的总体观点是 GPL 是个流氓协议,能不碰就不要碰。

https://developer.wordpress.org/themes/getting-started/wordpress-licensing-the-gpl/#do-i-need-to-license-my-themes-under-the-gpl
2017-02-08 22:00:08 +08:00
回复了 lgpqdwjh 创建的主题 程序员 关于定时任务管理
2017-02-08 21:52:23 +08:00
回复了 angetchao 创建的主题 分享发现 主流邮箱评测
outlook 、 icloud 、 fastmail
2017-02-06 23:47:46 +08:00
回复了 moonmagian 创建的主题 程序员 一个关于程序员的简单的调查问卷
可以考虑在收集完成后,把统计结果和分析发给有兴趣的参与者。
2017-02-02 01:51:53 +08:00
回复了 lizheming 创建的主题 GitHub Github 可以给 repo 添加 topic 了
据说(图中)这是基于机器学习和自然语言处理的智能提示。

不过似乎目前这个功能和 star 什么的联动还有点弱,希望以后能改善,很多人一直都希望可以给 star 加 tag (也有很多第三方来做这个功能)。
2017-02-01 16:24:00 +08:00
回复了 m31271n 创建的主题 程序员 请教:关于 RESTful API 中状态码的疑惑
可供参考:

422 Unprocessable Entity 语义错误,适用大部分客户端错误的情况
409 Conflict 冲突,适用需要用户解决冲突并重新提交的情况(用户名已被使用)

其实除了一些非常常见的错误代码,其他的错误代码大家都没有很明确的共识,所以死扣哪个代码更合理意义并不大。
2017-01-27 23:00:44 +08:00
回复了 ZE3kr 创建的主题 SSL 发现了强制 HTTPS 后的另一个好处
其实这应该算是 HTTP 302 重定向的坑,应该使用 307 (或 303 )代替 302 。
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/307
2017-01-26 17:36:46 +08:00
回复了 steley 创建的主题 互联网 2333,反社交的邮箱, 0.5 元/封
有一个叫 Hashcash 的反垃圾邮件策略,要求发信人在发送邮件前进行特定的 CPU 密集的计算(类似 Bitcoin 的挖矿,一般花几十秒)来证明自己的诚意。详见 https://en.wikipedia.org/wiki/Hashcash
2017-01-24 23:18:36 +08:00
回复了 jybox 创建的主题 分享创造 抛砖引玉:如何实现绝对公平的年会抽奖程序
@takashiki 我这个算法是要等人齐了才会开始抽的。

@cunkouwdy007 @loading @lhbc random.org 么?其实还是解决不了我一开始提出的问题:既然随机数是在一台设备上产生的,如何确定这个设备(编译器、浏览器、 HTTP Client )没有被做过手脚呢。

@MOxFIVE 使用股票、比特币、福利彩票的结果应该算是实践上最简单可行的了。不过我们之所以认为他们可以信任,其实还是因为相比于一个年会抽奖,他们的体量太大了,去操纵的难度太大了,而不是说他们从理论上不可能被操纵。
@echo1937 用国产的芯片就可以了,有些设备的国行版本就是搭载国产的 TPM 的
2017-01-21 19:29:33 +08:00
回复了 wly19960911 创建的主题 JavaScript 冒昧提问关于 ES6 的 promise 的一些问题
建议先了解 Node 的事件循环,异步能力本身是由引擎(或者 Node.js 里的 C++ Addon )提供的,引擎会在进行 IO 操作时接受一个回调函数,然后再在 IO 完成时调用它。如果不借助引擎的能力, JS 本身是做不到异步和并发的。

Promise 只是帮助开发者更好地管理异步任务(我认为最大的价值是简化了异常处理),是可以用纯 JavaScript 来实现的, ES2015 把 Promise 加入了标准中。
2017-01-20 23:29:27 +08:00
回复了 sophos 创建的主题 分享发现 程序员的工作究竟有多复杂?
这篇文章里的例子很有趣,但感觉说得不是很尽兴。

如果是厨师来做这道菜的话,应该都可以逐一对这些细节问题做出判断。但程序员的工作是把这个做菜的过程自动化,不再需要人对每个细节把关(因为人力成本高、人可能会失误、可能不够客观),所以程序员要设计出一套可以被反复执行的、考虑到各种边界情况的代码。而且更为复杂的是,写这个做菜的程序员不光要写好代码,还要懂如何做菜(了解要解决的问题本身),而且还要考虑每一个细枝末节的问题,虽然这个过程中可能有产品经理做指导。

我只是针对这个例子随便说一下,如果真的对「为什么复杂」感兴趣,建议看下知乎的这个问题 https://www.zhihu.com/question/22508677
1 ... 12  13  14  15  16  17  18  19  20  21 ... 64  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5428 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 59ms · UTC 08:57 · PVG 16:57 · LAX 00:57 · JFK 03:57
Developed with CodeLauncher
♥ Do have faith in what you're doing.