• Ruby Kaigi 2017 没人关注么... at 2017年09月21日

    还有个 Workshop 手把手教你写 PyCall,第二天的时候

  • Ruby Kaigi 2017 没人关注么... at 2017年09月19日

    我明天还要演讲,想想我又要睡不着了

  • 哇,这个图画得好高级

  • Ruby v2.4.2 Released at 2017年09月17日

    没用。。。我翻译版本发布记的时候看了下遇到的具体问题。。。 不过你这么一说我倒是可以试试这玩意,三年没维护这个 gem 了,有点虚。

  • Ruby v2.4.2 Released at 2017年09月17日

    提交了相关版本发布记中文翻译的 PR 了,修复的问题还挺。。。不容易触发的。如果项目不涉及 libgmp 和 jemalloc 可以平滑升级,如果涉及这两个库还要手动打一下补丁😅

  • 有一次在 Mac 上修改 OpenWRT 并编译的时候就遇到过这个问题,OpenWRT 的编译要求里就写了需要 case sensitive 的分区。把整个分区改了肯定会有兼容性问题,不好作死。我的方法比较暴力,搞了个虚拟磁盘文件,这个虚拟磁盘弄成 case sensitive 的分区,然后挂载上来就是了。

  • Common Lisp 不是有。。。Common Lisp Object System (CLOS) 嘛。。。像 Scheme 上的 Gauche、Meroon,还有 Guile 上的 GOOPS 都可以看作是受这玩意的启发在其它语言上的实践。call/cc 是真痛。。。很多时候只能靠 handler-bind 苟活一下😩

  • 哇,被光速嘲讽

  • 某些民营宽带供应商,为了降低与电信或联通等主干通讯的开销,可能会缓存一些静态资源。像长城宽带有一套非常复杂的缓存机制,但有时依然会误判缓存上了不该缓存的东西,很多后端开发都有过大受其害的经历吧。

  • 招募项目合伙人 at 2017年07月21日

    我觉得想怎么说都无所谓,只是能不能说服别人的问题。但一旦落到人身攻击了,就不好了。

  • 如何读文档? at 2017年07月19日
  • 如何读文档? at 2017年07月17日

    Spring 新的大版本更新我也是晕了,彻底写出了一种 Spark 的感觉

  • 如何读文档? at 2017年07月17日

    这就产生了一个很大的问题,为什么会产生那种只会 Rails CRUD 的熟练工,或者在 Java Spring 甚至连 PHP 上我们也有很多这样的程序员。Web 框架,特别是已经做好了 MVC 抽象的 Web 框架是一个巨大的黑盒,作者做得那么复杂是积累了大量的经验和想法,背后的实现非常复杂,光靠熟练是很难了解其根本的。这就是在 Getting Started 之后需要了解一个框架的大局,再去通过项目去熟练,去具体了解其细节的原因。

  • 如何读文档? at 2017年07月16日

    其实单从功能上来说 ActiveSupport 的 try 好像还是 &. 的超集。但这件事情就很奇怪,就好像一些人认为面向对象和面向接口甚至和函数式编程都可以是等价的,从数理上如此,但并不代表对人的感知上是如此的。所以 Ruby 放着一个已有的超集去实现一个子集,这其实就是 Ruby 平衡性的一个考量了。

  • 如何读文档? at 2017年07月16日

    我只是说类似啦。。。并不是说完全一样。try 还有一些奇怪的用法比如 Array#try(:[], key) 之类的。

  • 如何读文档? at 2017年07月16日

    我记错了,确实是 ActiveSupport 提供的。不过其实自己通过元编程也可以实现一个类似的。

  • Challenge 1 就是个 DP,Challenge 2 就是个 AC 自动机。而且这题目没有绕弯,基本上都是算法课涉及这两个算法最经典的例题了吧。。。

  • challenge #1 - #6 update 06/03 at 2017年07月08日

    对于 challenge 6 的 easy 来说,其实也挺不 easy 的。由于题目要求精确到小数点后 30 位,基本超出了浮点数的精确范围。如果不考虑这点的话,可能无论什么方法都很难做对。

    为了正确做对这道题,你需要定义一个自己的数据结构能够处理更多位的小数,比较方便的是定义成定点数,理论上定义个 100 位,做一个 30 位精确的题目应该是足够了。然后你需要实现这个数字的加减乘除运算。一旦这点做好,就有很多方法可以做对,无论是割圆法还是蒙特卡洛迭代,或者定义一个大正方形然后遍历每个点,应该都能算对。

    如果要收敛得比较快,那么比较常用的是梅钦公式。不过梅钦公式中有个 arctan,这对于才实现了加减乘除的自定义数据结构来说很不方便。但可以用泰勒级数展开这个 arctan,从而把问题转换成一个迭代问题。现代常用的计算圆周率的方法一般都是梅钦公式的改进,称为梅钦类公式。

    除了这些方法以外,另一个难点是,如何证明自己的程序已经收敛到前 30 位完全正确了。证明自己是对的这一点也挺有意思,特别是我们假设 30 位的圆周率还没有被人类算出来,我们需要自行证明自己是对的,而不是拿一个正确答案来比较。这一点对于梅钦公式来说比较容易,对于蒙特卡洛方法来说则很难。

  • challenge #1 - #6 update 06/03 at 2017年07月08日

    用 eval 相当于没写。。。背后的字符串解析完全没有碰到,而且还会遇到注入的问题,在非动态语言上也运行不起来。

    关于 nim game 的定义建议看英文的维基百科,中文的没有翻译完整。

    尼姆游戏开始前就需要知道每个堆的数量 nx。有一个特殊的变形,尼姆堆只有一个堆的时候,通常还需要限制最多能取 m 个子。这个变形是最好证明的,我可以给一个例子,当 n0 = 30,而 m = 4 的时候,后手必胜。因为 n0 是 5 的整倍数,当先手每次取 x 的时候,后手取 (5-x) 个。那么最后这个堆一定只剩下 5 个子,且是先手行动,这时候无论先手拿几个子,后手都可以把剩下的子全拿完。关于一个堆的所有数量都可以被很容易地证明。结论是 n0 是 (m+1) 的整倍数时,后手必胜,反之,先手必胜。你可以试一下。

    关于多个堆比较麻烦一些,用逻辑异或处理一下即可。英文维基百科给出了完整的证明。你看中文维基也写了 Nim Game 是一个无偏博弈。无偏博弈的特点之一就是完全信息博弈,双方都能完全看到局势,不可能存在「不会知道堆中含棋子的个数」的问题。

  • 量产型炮灰工程师 at 2017年07月07日

    elsif i % 15 == 0 puts 'FizzBuzz'不会执行 是因为 15 的余数已经被 3 的余数处理过了啊。。。怎么可能是因为 Ruby 不支持这么多分支。。。你用什么语言写都一样啊。。。

    • Debian 9
    • KDE Plasma
    • KWin
    • 物理机

    邪教徒😂

  • 100% 是把一个核心吃满还是把所有核心吃满了?如果是后者那肯定是 handle_thread 方法里线程相关的问题了。如果是前者我读了一圈觉得有几个可能出现死循环问题的地方,但这脚本不太方便部署调试。

  • 量产型炮灰工程师 at 2017年06月27日

    你怎么解决用人单位的要求和普通本科毕业生之间的最后一公里 这不是你口口声声 进高校说这个估计你会被群殴 的高校教育的问题吗?自学你想学理论学理论,想碰工程碰工程,根本没人拦着你。

    知道为啥ruby在国内发展的没有php火吗,就是这样的贵族思维在作怪 本来就是 Ruby 没有 PHP 好学啊。那全世界范围内 Ruby 都没 PHP 火啊,所以全世界 Ruby 工程师都是贵族思维;那 Haskell 也没 PHP 火啊,所以 Haskell 工程师也是贵族思维了?显然不是啊。一个语言的流行程度,要考虑到自身的奋斗,也要考虑到历史的进程,考虑到其设计目的和适合的场景。

    Ruby 社区从各种角度上来说都是新手友好的。达○、北○○鸟那样的机构去培训 Java、Objective-C、PHP 搞定招和校企合作,使中国 PHP 工程师的数量确实是 Ruby 的数倍甚至数十倍。这是因为 PHP 社区没有贵族思维产生的吗?如果是的话,那 Python 现在市场占有率越来越高已经超过 PHP 好几个百分点了,怎么这些培训机构还是在执着于 PHP 呢?

    这是由于 PHP 语言比起 Python 也好 Ruby 也好更容易教学,成为了这些培训班的选择。Ruby 这门语言根本就不会被这些市场选择到,它缺乏这种可以量产的基数,所以要有才会有那种全○培训营这种打着高端旗号收智商税的东西出来。

    但反过来问,数倍数十倍于 Ruby 的工程师,但国内的 PHP 社区贡献者的数量呢?国内绝大多数的 PHP 开发者与 PHP 社区本身完全是极大隔离的。这到底对 PHP 发展是好事还是坏事,这里多少 PHP 工程师是只能做重复劳动性的外包业务工作的,多少人是技术主管口中「天天做负功」的人?

    这些问题的原因怎么扯也扯不上什么「贵族思维」吧。

  • 量产型炮灰工程师 at 2017年06月27日

    没有懂 有经验的人自学 有什么冲突的地方,自学又不是闭门造车。我也不懂 压根儿不信明白吗你这想法太主观了 这两点哪个想法更主观。进高校说这个估计你会被群殴,只要不去武术学校,应该讲这个都没有什么问题。😩

  • 这个段子好冷啊。。。😂

  • 👍

  • 我有个问题:

    其实可以将尼特值简单理解为亮度值。白天,人的眼睛能适应亮度的值高于 3.4 尼特;夜晚,主体颜色接近 0.034 尼特,最亮元素低于 3.4 尼特的亮度眼睛会比较舒适。将尼特值换算成 HSB 颜色模式。也就是说主色调颜色(一般指背景色或最暗的颜色)的亮度不超过 20(0<B<20),避免使用极端颜色(纯黑),最亮的颜色亮度尽量不超过 50。

    这个 nit 到 brightness 的转换是怎么实现的。这是假定了屏幕亮度是 17.34 nits 吗?另外如果屏幕的对比度很差,特别是一些糟糕的 TN-TFT 屏幕的话,限定 B 在 20-50 会不会造成阅读的困难?

  • 申请删帖 at 2017年06月04日

    我百行的 WebSocket 就把 rfc6455 标准中提到的错误情况全处理了,只有一个 Continuous Frame 没有实现,并且在遇到时会抛出,也不会让程序 crash。你以为写个框架这几十页几百页的标准文档是不用看的?你看看 nginx 处理 WebSocket 长连接的部分,除了兼容试验性版本所以加了一堆代码,实际部分也就这么多代码。

    我 HTTP/1.1 标准已经几乎全部兼容了,除了标准中非 Web 服务器的部分。你要说「读完 Apache 的 Souce 你能一天写完吗」,答案当然是不能。但也没有就写了一天,就跑到论坛上各种帖子下回复我比你强比你棒的,你这不是拱火是什么?

    「我说的路由规则是指根据 URL 来反射对应的 Controller 处理」 你 URL 怎么处理的?你自己好意思说这句话吗。

  • 申请删帖 at 2017年06月04日

    我说的「当 TCP 包不能一次性读回来的时候」是正常的包,我甚至都没有在讨论「发了个错包」或者有意的攻击。你的包解析整个都是一片糊涂账,路由匹配啥都没有现在来说「我的路有我自己的规则」,你连 TCP 的规则都不遵守,现在连 HTTP 路由的规则也不遵守,你倒是继续规则啊。你不是还号称

    「我读过 Lighttpd / Nginx 的 sources」

    你写的这玩意像是读过 sources 的情况吗?

  • 申请删帖 at 2017年06月04日

    解析 TCP 包 crash 是由你 Objective-C 写的问题导致的,别没事就怪人家 C unsafe,人家提供的 API 好好的。

    「其实你并不知道,整个 Route 过程是对象反射,而不是 Sinatra 那样的捆绑。」

    路由匹配和你怎么 call 毫无关系,你现在的代码连路由匹配都没有你知道是什么意思吗?