• 暂时没法理解,暂时觉得怪怪的

  • @Rei

    这个说明看过,刚阅读了一下它附带的文章,关于 Monolith 的思想,我觉得,这是一种很小公司,自己就想一个人单干,然后自己想让自己变得壮观,不想用别的工具,不想复杂,不想残酷,只想用自己手头的巨石把它用好并且为自己扩展更大。

    我觉得,这是最典型的 Geek 思想。这是找不到工作的:

    https://ruby-china.org/topics/34079

    如果这块巨石作为自己的爱好,自己去创业,自己谋生,作为自己的全部,是很理想主义的。但是哪个公司不愿意长大?(其实我想说,要是公司发财了,业务变得越来越大,必须得开始逐渐拆分项目,拆分工程,如果你还是遮遮掩掩地不敢放手,老板可能会马上换方案)

    Perl 开发者总是觉得自己能抬起全部,what about Java developers?and nowa-Javascript developers,人家还会跟你抢饭碗。

    其实同样的例子,Linux Kernel,早期几乎掌握在 Linus 本人手上,GPL 不一定是非常好的东西,它不容纳厂商私藏,有时候,我们不能认为私藏是一件坏事,人家厂商就不喜欢你知道人家硬件设计怎么了。

    作为人际沟通,你要想人脉广,最基本的就是你得容纳各种性格的人。

    所以 FreeBSD 才会被用在 PlayStation macOS 作为 System 的其中的 layer。

    TED 访谈上,Linus 就嘲讽自己“我跟人接触要有一道 buffer 的”,我并不认为这是非常美好的一件事。

    但是后来他能与人接触,还是容纳了别人的驱动程序,说明他还是进步了,但是这就不是 Monolith 了。

  • 谢谢老人们的意见,让我对 Rails 更加理解,那我更清楚它的定位了

  • 看了一下,此 webpacker 非彼 webpack,而是被 Ruby 一层层包得好复杂呀,我自己的前端 lib 是独立写的,强烈建议不要揉在一起,尤其如果公司有独立的前端开发,前端的同事可能会觉得自己受约束。(反正不讨论别人,要是我的话我一定让他后端别抢我的逻辑)。

  • 感觉他挺辛苦的,维护那么多文档

  • Perl 不是书面 OOP 语言,而是非常独特的一种思想的语言,首先它是 C 那种模块式的,然后 Object 其实是 package 模拟的,当然你可以用 Moose 带上了很多 has 之类的 关键字 DSL,不好解释,但是你可以想象一下用 IE 年代的 JavaScript 进行 OOP 的感受。 它每一个变量本身就是 Scalar,是一种“多元体”,跟 PHP 的 Scalar 基本一样。它每个变量都为不同的数据类型开辟了空间,详情看 perltut 等等 man 文档 perldoc。

  • Catalyst 太大了,而且很多模块用了 C 实现,有些 Linux 发行版没有装一些模块,编译不过,我开始的时候自己也不会解决(上大一的时候),直到后来熟悉了 Linux C 之后,终于明白它少了依赖 lib,testing 不过,装上了终于通过了。东西很大,执行效率一般。

    适合企业级使用,成本也很高。

    所以要用的话,我还是用 Dancer。

  • 看到你的头像,跟 cpan 某个贡献者的似乎一样的,你该不会就是那个人吧?

  • 呃,Agile Web Development with Rails,看了一下历史订单,改过来了

  • YES,我说的是 DIY,马上改一下,改好了

  • 最近的一点小感悟 at 2017年10月31日

    撒,我怎么知道呢,我站在我的观点看,我是觉得,这样有利于展示吧。

    我和我的 tutor 也有不喜欢的地方,他喜欢快准狠,减肥药一样的,我喜欢把东西描述得很清晰,但他觉得啰嗦。

    就像 ObjC,长长一堆,一个简单的 variable 写出文章出来 还代码即注释,其实我挺喜欢的,这样很文学气质。但是有些人就不喜欢这样,他觉得又长又臭,耽误时间。

    我喜欢抽象一点,他喜欢浓缩一点,所以我喜欢用 Ruby / ObjC,他喜欢用 C++。

    然后当然也有非常庞大的那种,啰嗦得不得啰嗦的风格的,“写出 spark“ (引自 Delton 某个地方他提到的)的 Java 复杂型抽象。

    我不敢点评了,免得引来麻烦。

  • 最近的一点小感悟 at 2017年10月31日

    写写 DEMO 告诉大家,噢是这个原理,还是不错的,可以学习一下,但是他们又不喜欢 DRY。

    我表达的是:他们就应该 DRY,这样子大家可以了解原理。

    其实上面你的帖子提到 JIT 的时候,我想说 Rubinius,它 DRY 了一堆 Ruby implementation of Ruby,虽然这样效率有堪商榷,但是代码很利于学习。

    好啦好啦好啦,我不敢乱发帖子了,我会很乖的,我不臆断好了吧。

  • 最近的一点小感悟 at 2017年10月31日

    其实每个人都一样,每个人都有自己擅长的、观察到的方面,同时也有观察不到,没有了解的地方。

    你在 27 楼回复

    搜了下 Jazelle 这玩意不就是 JIT 么?

    我只是不打算纠结下去,所以

    你上知乎找 R 大讨论两个实现去

    每个人都有自己视觉范围的圈子,不能随便去否定别人说别人 Java 某些东西就不好了,或者 Ruby 什么 facility 不好。

    我并不是没有用 rack,在 15 年的时候,我用的是 Plack / PSGI,这玩意跟 rack 一毛一样。

    我的 style 明显就是喜欢重复制造齿轮,你会发现我的代码中很多冗余的实现,实际上很多余,很没必要,实际我是故意这么写的,我就不用社区包,我就希望我把整个世界重新写完。

    恨不得重新发明一门语言,然后重新从 Base Object 开始去实现。

  • 最近的一点小感悟 at 2017年10月31日

    那时候真心没办法,对 IO 还不够了解,Ruby 才刚接触,GIL 理解程度肯定就是刚上手,然后我换了职业找到了一位比较燥的 tutor,做了相关的东西后,学到了很多新的东西。

    顺便在社区很久都没帖子了,卖个萌而已。

  • 最近的一点小感悟 at 2017年10月31日

    噢,那路或多,我还真感谢那位在 GIL 帮我跳出 obj marking 坑的前辈

  • 最近的一点小感悟 at 2017年10月31日

    好啦好啦,你是在辩证 YARV 也不差,可以,这点我没有否定 YARV

    无论 Hotspot 和 YARV,都是先把这些序列化用的代码转一个个指令,执行的时候基本上就是流水线处理这批东西,所以还是屏蔽了原本垂直方式直接对 buffer 的处理。

    我觉得不应该我来和你讨论,你上知乎找 R 大讨论两个实现去,话说:

    另外 Ruby 本身强大的动态特性导致他绝大多数应用不需要在字节码、AST 层面执行,而 Java 不在这个层面很多事情非常难搞,比如 DI,即使对标的 C# 在 .Net 平台上也用不上 Spring 这样的框架。

    只要有运行时、虚拟机的语言,心脏都是动态的,Java 你可以随时在 reflect 的时候动态注入一些 attribute 和 method,ObjC 也如此,只是你在后面调用这些东西的时候,由于它静态的,没办法通过编译,要不然它就不静态了。

    你想说这个?

  • 最近的一点小感悟 at 2017年10月31日

    JS 跟 C++ 一样能处理字节流,就是很麻烦,转成 Array 处理 uint,Perl PHP Python Ruby 用 pack 来包数据,而且 PHP 的 pack 也是转 Array,Ruby 这里社区有一个帖子不也是 [] 运算符处理二进制其中序列某 byte,另外它的转换产出我记得也是个 Array。

    https://ruby-china.org/topics/34437

    只要你熟悉其中一个工具就够了,能做的功能基本上都能做,JS 只是受浏览器兼容制约,不同的浏览器对 ECMA 实现程度不一。反正吧,fill 一下 shim 一下,各种风格爱好的人也参差不齐。

    而且不能评价。因为不同的人有不同的价值观、趋向,所以不要下结论,喜欢用什么就用什么,就像商店那么多衣服,总不可能说买某一件才是最理智啥的,每个人有不同的判断观点,自己喜欢某一件就好。

    我在发表的观点里面有陈述:

    在某些方面并不比 Java 高效,大量的 new delete 等系统调用很耗,还不如 JVM 有对象池、GC 高效利用,在你开发大规模业务型程序的时候,你会发现 java 优势的明显。

    所以如果是做大数据、业务系统等方向的,还是选择 Java 好一些,如果公司有硬件方向需求的,比如 GPU 调用、一些设备调用的,就用 C++ (GPU 一般就是图形,这用在。。。我想说什么你们应该猜得到)。

    一般的情况下,你对硬件没有啥要求,你又不去频繁读写 fd,不去做 USB device IO,C++ 就发挥不了优势,templete for Object pool 委托,也就是上面他说的对象池,实际上并不是万能的,其实现代的方法应该是 dynamic pointers,但是据我所知,基本上 C++ 开发他们都不喜欢用这种,而是几乎尽可能静态、语法 scope,也就是限定在某个地方用,需要别的地方稍微调用一下的就引用(refenrece),因为这样效率高。

    我说的 new delete 只是一个方面,实际上系统调用还有很多,Linux API 书有多厚就有多少,Java 好处明显就是你不用去关心 System implementations,更不用把这些行为 behavior 的代码写到你的源码文件中,因为它已经帮你 wrapping 好了,你只需要把 Java 的这些对平台抽象的 API 接起来。

    所以,不仅仅是 GC,从【系统实现抽象】方面也是一个优势。

    .net 刚出现的时候,不是声称要做一套与系统无关的抽象平台吗?就这么回事~

    还有的就是,脚本语言都是动态的,它们的代码基本是靠上下文、具有一定强度的衔接,我不记得怎么表达了,假设 Ruby Perl 都是这个对象依赖另一个对象的某个方法,然后直接就调过去,如果另一个对象没这个东西,大不了也就是终止运行,就是错误没有静态语言那种首先声明好大家该怎么协调,然后再进行通讯的法则好。

    所以才会诞生 Crystal language,像 PHP 开发往往习惯性各种灵活的反射而数据结构变得很模糊,几乎只有写的那个人自己知道那个 scalar 是什么。

    JavaScript 的分流 TypeScript 也是为了实现这一种严格类型系统,确定类型。我觉得最大的好处还是方便查阅,别的开发者看到这个东西,就知道你这个 interface 接上我的 class 需要什么 data。

  • 最近的一点小感悟 at 2017年10月31日

    别森气,我只是提点想法

  • 最近的一点小感悟 at 2017年10月31日

    我当然知道 C++ 对象池,但是开发效率肯定没有 Java 从头到尾你不用担心这些的情况下更安心处理逻辑那样高,就像 ARC 引入了 ObjC 之后,你就可以从代码上少出现那种逻辑,更明了地去处理业务逻辑。

    蜀黍别生气~ 我知道我的东西也不见得不玩具。但是起码我不会这么做(笑),我目前还没有把它公开呀。

    【指令级内存操作】我指的是 Jazelle 可以通过指令集级别去进行优化中间代码,Ruby 好像没这个玩意吧,YARV 能跟它比吗。

    再换位思考下,你之前写 iOS 为啥要用 Cocoa 不学学 Facebook 从 CoreGraphics 绘制写起来?

    我最近确实在学习 OpenGL,正在做一个图形库,想取代 cocos(其实我又跑去招惹另一帮人了),所以很少在 ruby 社区卖萌了,噢对了,MooTive 部分控件确实有用 Core Graphics API draw 的。

    内存级数据序列化

    我想表达的是 struct 很轻,但是如果你把 IO 的 buffer 解析序列化成 Ruby Object 的时候,损耗很大。而且很依赖 C,还不如从头到尾用 C 写。

  • 最近的一点小感悟 at 2017年10月31日

    我在这个帖子 #18 楼回复了:

    https://ruby-china.org/topics/34188

    LZ 可以试一下加入 C++ 做几年服务端开发,你就知道原因了。

    很多 Rubyist 搬弄概念,作为 C++ 开发者、Java 稍微偏向 IO 实现的开发者是很清楚的,因为他们经常要用到直接的 IO 去传输二进制,用自定义的协议,就连 Android 也有 Parcelable,那是为了解决 Activity <=> Activity 等消息传递的 IO Buffer Object。然后怎么 IO 比较快,做了一段时间之后,我发现他们嘴巴根本几乎不提什么 EventMachine,也不会提 libevent,他们更倾向于直接用系统的 API。

    如果不想去考虑 IO 模型,可以直接用现成的而且实现得比较好的——Goroutine,或者 Erlang。

    但是大家认真看一下这些语言有一个优势——他们可以直接内存级数据序列化,就是 buffer => struct,struct => buffer。

    Ruby 本身就有一层 VM 对 struct 抽象成了 Object,而且 VM 还没有实现到 Hotspot 那种层面的指令级内存操作支持。加上一些损耗,效率怎么都比不上的,但是我倒是不理解他们还要往这方面跑。

    写写 DEMO 告诉大家,噢是这个原理,还是不错的,可以学习一下,但是他们又不喜欢 DRY。你们去看看 midori 有几行代码自己写的 IO,连模型都是用人家的模块引入进来实现的,然后就把别人模块(比如 EventMachine,那是别人用 C 先写好的模型,然后 Ruby 加了外壳包装)的概念搬到自己这里介绍。

    所以我才说有炒作之嫌,就是实际上是玩具,性能任何一个游戏服务器都比不上,先别说游戏级的,就普通的服务器框架比如腾讯的 Tars 都不如,不对,应该说根本提不上嘴,不足挂齿,说出来作者都有强烈羞耻感才对。

    估计是 Rubyist 过于浮躁,总想着出名吧。

    RoR 好歹是踏踏实实做他正在做的事情,哪怕 Twitter 不要它。但是 Ruby 在慢查询、一般条件需求的情况下,它在很认真的做事。

    吾认为,Elixir 不能和 Ruby 相提并论,Ruby 早期发明的时候参照了 Python,难不成 Python programmers 整天嘴边搭着 Ruby?

    心态很重要,你到底想要什么,想做什么。

    其实 C++ 在某些方面并不比 Java 高效,大量的 new delete 等系统调用很耗,还不如 JVM 有对象池、GC 高效利用,在你开发大规模业务型程序的时候,你会发现 java 优势的明显。

    所以如果是做大数据、业务系统等方向的,还是选择 Java 好一些,如果公司有硬件方向需求的,比如 GPU 调用、一些设备调用的,就用 C++ (GPU 一般就是图形,这用在。。。我想说什么你们应该猜得到)。

    请原谅我的言辞。

  • 这是样书吗,我上个月就看到有预定消息。挺想要这么本书的,Agile Web 看着很烧脑,吃得不够干净。

    已入:

    https://ruby-china.org/topics/34484

    Thank you for your translation.

  • 吐槽:

    1. 帖子跟实时通讯没有半毛钱关系
    2. midori 还不如用最简单的 select IO,高效点用 system API,比如 epoll,不知道是不是作者不会自己写,然后就用了别人的各种 libevent。就一个脚手架服务器,跟 puma 没有任何可比性,应该说,根本提不上,思想差太远。
    3. 多路复用是 IO 模型之一,不需要刻意用一些名词来掩盖它原本非常基础的本质。还 EventMachine,我再也不相信了。有时间多看看 C++ 的一些实现比如 asio,或者 Go 的 routine。

    Ruby 的性能还是适合用来写点简单的东西,但是没必要浮夸。你拿 C 写一下 IO rw,跟 Ruby 原生写一下,你会发现 C 都完成了,Ruby 还在等待,为何,因为 Ruby 一般把 IO 都写到(可以认为是 append / insert after / push_back)String buffer,对象消息损耗了一点。加上频繁的 GC,就很慢了。

    感觉你们社区涉嫌炒作,拿一些很简单的概念、小 gem 进行包装宣传,我已转 C++ & Tars。

  • TextMate 是不是淘汰了? at 2017年10月29日

    怎么说呢,其实 TEXT EDITORs 基本上都是喜欢写脚本的人发起的早期运动,他们觉得 IDE 给的东西太不明智,因为早期 IDE 只能给语法分析的提示,对于语义二层以上分析基本上当初早期的时候还是没有的,所以写着比较尴尬,毕竟动态的语言,你根本没法确定 a is A,b is B,而且还要是 currently is A and currently is B in this scope。复杂分析起来。。。还有点倾向于人工智能了。

    所以,我觉得 AI 未来在这语法分析领域一定很有用途。。。AI 作为助手帮你分析这些你写的语法结构、逻辑,甚至你的思想。

    扯太远了不好意思

  • TextMate 是不是淘汰了? at 2017年10月29日

    我之前也碰到这个问题,实际上是它的插件有 bug,打开 develop 模式就看到一堆 console 调用失败了,应该是 robocop 等插件没配好或者没正确、良好对接上,另外,你前面语法错了,后面语法继续写都是没法提示的。这个问题不知道修复没,反正很久没用它了(因为碰到这个问题)。其实正确配置后,是可以 parse 到你写的东西而且给予良好的语义提示的。

  • RubyConf China 2017 视频 at 2017年10月10日

    赞二楼的回复 😆

    顺便路过

  • 别介意~

    我没有别的意思,用什么无所谓,所有语言几乎都能解决同一个问题,就是运行速度(执行效率)、开发效率、平台特征等等比较而已,无论是哪个工具,存在即合理。

    “也许你是看不惯我贴了自己 Blog 的外链吧”,我没看到呀,现在才反应过来。我不介意,不过我看了原文,对比了一下,感觉你是不是把原文的东西改了一些?

  • 嗯,文中说了半天很基础的并行方案,到最后还是叫人家去用 Erlang 了。。。

    其实我是能理解的,因为我尝试过越过 GIL,后来发现这样还不如直接用别的语言来得快。

    这样的文章很灰色,也能加精。。。真的好吗?

    文中说的竞争的情况主要在 IO,然而 IO 是不由 GIL 堵塞的,在我另一个 @luikore 的讨论帖子中有陈述。另外就是,GIL 解决的是线程安全,保证这个时间只有一个线程去处理现场。竞争问题,我的观点是:它只是打乱了 Thread 们的执行规律,按照 priority 优先级执行。也许你对资源还没操作完,就已经下一个 Thread 开始执行了。

    这时候加锁会有帮助,让你把资源锁起来,先做完特定步骤后在让别的资源用,但是这样就堵塞了,因为在你锁住的时候,你把别人堵塞了就有点串行的味道了。

    无论怎么说,Ruby 还是有它挺有用处的地方,在 IO 密集的应用还是有优势的,但是我觉得 IO 密集的程序。。。反正我是碰不到,而且 GIL 本身已经有点减速的效果了,就算应对 IO 密集,也轮不到 Ruby 去处理。

    反正我个人觉得 MRI 是 Ruby 中规中矩的实现语言,其实它的语法糖还是挺好用的,重点是很舒适,特别喜欢。站在这点,你跟我比较它的并行、效率,我觉得牺牲这些去获得更高的使用体验也无所谓。

  • 另外还有一个问题,就是我坚持用 pthread 再注册能不能绕开 GIL?

  • 谢谢,我看这些在很多网站都找不到资源,也不知道怎么解决,不过你倒是帮我解决了这个问题,再次谢谢~

    其实当时我已经意识到没有 mark 那个变量,然后尝试各种手动删除,但是翻了半天没找到方案。

  • LZ fork 是指 Thread or Process?

    另外,在后端开发的编程观念里,业务逻辑用多线程是没有意义的(除非异步 IO,先返回后存储,或者除非你写服务器)。

    在一般场景中,因为你要 response 客户端,但是你开线程去执行的逻辑可能 request 已经 response 了,而 result 没拿到,结果 response 了没有 result 的结果。