• apifox 最近用了一下,感觉其实还好,但是性能堪忧,特别是 desktop 版本,卡顿的厉害。

  • 直播没录。

  • 有一段时间做封闭式开发,我就直接 B 站开着直播写代码(做了脱敏),每天平均两小时左右,持续了一个月。说实话,直播写真实项目看热闹的多,能看懂的人极少,还有几个不懂装懂在聊天室里当“指导员”的就纯当乐子了。

    想想也是,真能和你在差不多技术层面上沟通和交流的人哪儿有那个功夫去看直播,还不如约一下 pair 走起来得舒服。

  • Postman 相信不少人都用过吧?印度班加罗尔三个工程师做出来的东西,一开始界面丑陋功能简单,现在进化成了一个标杆产品。目前估值 56 亿美金,几轮融资金额已经超过 4 亿美金。

    喜欢做给程序员用的东西并没有什么问题,实际上做任何领域都没有问题,真正的问题还是自己能不能够做得好。

  • 不要总是凭“感觉”下判断,对于第三方库的封装,React 的确要比 Ember 的多——这很正常,本身 React 的用户就多。但是 Ember 的用户相对都更“自主”一些,不晓得你能否理解我的意思。

    React(包括 Vue)的用户大部分都是那种做一个项目主要以“拿来就用”为宗旨的,而 Ember(包括 Angular)则相反,它们的主要用户都是要做那种“拿来就用”的东西通常没办法完全满足需求的项目。当然我并不是说二者是互斥的,两种类型的项目换对方的框架一样也能做(这全看用工具的人而不是工具本身),但是呢,React / Vue 做到像 Ember / Angular 适合的那种项目,需要在它们身上下的功夫是只会比直接用后者更多。

    对这种事情我是比较有经验的,因为我们两类项目和两类框架全都做过很多很多,感同身受。从我的角度来看,选择一个工具固然要看所谓“生态圈”,但这个在以复杂 UI 和交互为主的应用前提下并不是很重要的考量因素。

  • 没想到现在还有人看到呢,我看了一下那时候写得很多东西现在也都过时了。比如说我们已经全面写了两年的 TypeScript 了(当然是用 Ember.js)等等。

  • hey.com 所用到的技术栈 at 2020年06月30日

    @apexy 对,我也正想提这个,因为已经有了类 Phoenix LiveView 的东西了,所以如果 New Magic 也就是这个的话,那么 Magic 也就不过如此罢了。

  • 像 rails 这种注重人性化,注重程序员感受的技术,很难再冒出来了。

    LZ 应该是认为 Ruby/Rails 是优美的,这没有问题吧?除非“人性化,注重程序员感受”这些点不是优美语言的特质,这楼主也不会同意的。

    现在资本说哪个语言优美,哪个语言就优美,敢说它不优美的要么眼光不行,要么就是没有真的懂这个语言,没有评价资格。就像皇帝新装里的那些成年人,没有人敢说黄帝没穿衣服,谁说出这个真相谁就是“愚蠢”的人。

    这句话的意思总结一下就是:资本控制下宣称的优美的语言都是虚假的,只有那些敢于说真的话的才是“眼光行,真的懂”。但是资本控制很强权,没人敢说出真相。

    挺佩服王垠的,他敢说 golang 不优美。

    而第三句就是 LZ 甩出的论据:因为王垠不代表资本,代表的是“眼光行,真的懂”的个体,所以他敢说 Go 不优美这是值得 LZ 佩服的。换言之——LZ 是相信王垠的眼光和判断的。

    以上是我对主楼的语言逻辑的分析,我自己觉得没什么问题,如果有你不妨点出来就好。

    那么在此分析之下很显然 LZ 的言语是自相矛盾的,因为他相信和佩服的王垠并非只是 diss 了 Go,他也一样 diss 了 Ruby/Python/JavaScript 等等语言。特别是 LZ 他又认为 Ruby 是优美的,那……要不然 LZ 先和王垠探讨一下达成一个共识?

    我之前回复有问题的地方在于我默认 LZ 会觉得王垠认为 Ruby 优美并且不会 diss Ruby 的,因为只有这样他拿王垠 diss Go 的论据出来才对他的论点有足够的支撑。但显然我错了,因为王垠 diss 其他语言的时候压根就没想过是不是要和资控言论唱反调,人家只是出于自己的判断想 diss 就 diss 了。OK,我的错我承认。@gaicitadie 抱歉的确是我多虑了。

    不过 LZ 这个论点是不是也不应该拿王垠的言论来充当论据呢?因为王垠的出发点很显然不是 LZ 想要表达的事情。

  • 套用最近流行的嘴子:有饭圈内味儿了。

  • hey.com 所用到的技术栈 at 2020年06月28日

    这还是用 stimulus 实现的一个 ui pattern,不是原推文提到的 NEW MAGIC,据说过段时间会开源的,届时才清楚它到底是什么。

  • @brookepowell 谢谢关注哈,视频一直在陆陆续续做着,不过都是出于业余的爱好,一旦受工作制约就没办法保障更新频次了。

  • 除了吐槽之外,再给你看几句引述,都来自于你佩服的王垠:

    很多 JavaScript 程序员也盲目地鄙视 Java,而其实 JavaScript 比 Python 和 Ruby 还要差。……Python 凑合可以用在不重要的地方,Ruby 是垃圾,JavaScript 是垃圾中的垃圾。原因很简单,因为 Ruby 和 JavaScript 的设计者,其实都是一知半解的民科。


    Python 的变量定义和赋值不分,所以你需要访问全局变量的时候得用 global 关键字,后来又发现如果要访问“中间层”的变量,没有办法了,所以又加了个 nonlocal 关键字。Ruby 先后出现过四种类似 lambda 的东西,每个都有自己的怪癖…… 有些人问我为什么有些语言设计成那个样子,我只能说,很多语言设计者其实根本不知道自己在干什么!


    今天我来谈一下另外一种错误的倾向,这种倾向也导致了很多错误,并且继续在导致错误的产生。今天我要说的错误倾向叫做“试图容纳世界”。这个错误导致了 Python,Ruby 和 JavaScript 等“动态语言”里面的一系列问题。

    我不评价王垠说的到底有没有道理,因为我觉得不够资格,引用这些只是为了告诉你,diss 之前也是要做做功课的,至少王垠并不如你“幻想”的那样认为 Ruby/Rails 很优美。

    再多送一段我个人觉得比较有意思的:

    所以初学者要想事半功倍,就应该从一种“合理”的,没有明显严重问题的语言出发,掌握最关键的语言特性,然后由此把这些概念应用到其它语言。哪些是合理的入门语言呢?我个人觉得这些语言都可以用来入门:Scheme、C、Java、Python、JavaScript……

  • 咦?你不是专职 diss JavaScript 的吗?怎么转换战场了,跳槽了吗?

  • 可别一概而论,实际上 person 是有两种复数形式的。一般来说,当我们引述相对于“动物”或“东西”的“人”的概念,并为了概括一个不确定数量的群体时,用的是 people;而当引述特定数量范围的独立个体时,用的是 persons。通常 persons 多用于法律法规之类的地方,比如说法院指代犯罪嫌疑人等的时候(因为犯罪嫌疑人的数量总是确定的,你不能给可能存在或不存在的人定罪吧?)就会用 persons。

    韦氏词典里有如下阐述,比我说的更专业一些:

    Many usage guides over the years have suggested that there is a clear distinction between these two words; people is used when referring to a collective group or indeterminate number, and persons serves better when referring to individuals (or a number of individuals). There are many instances in which this difference may be observed, often when the two words are side by side.

  • 去 Github 找 chrominum 项目,然后在里面搜索 importNode,在 document.cc 文件里。这个文件有点大,我现在打开了会把浏览器搞崩,所以只能告诉你地方自己去看吧。

    另外,DOM 是有 specification 的,跟着标准走其实任何语言都能实现。

  • 这应该不难理解吧?我用 JavaScript 举例,典型的链式调用是这样:

    o.foo().bar();
    

    如果你把它分解成两段,那无非就是:

    let n = o.foo();
    n.bar();
    

    换言之,o.foo 所返回的结果必然是一个拥有 bar 方法的对象,不然的话你怎么接着就调用 .bar() 呢?

    o.foo 所返回的那个对象也应该是自己(this),这样才能让链式调用中链条上的每一个环节(方法)所处理的上下文(this)都是一致的。理论上你当然可以让 o.foo 返回其他的对象而不是 this,并且只要那个对象自身也有 bar 方法,那么这个链式调用的形式依然可以得到维持,但这种链式调用的意义不大,因为方法调用的上下文不断在变化,这既没有太大的现实意义,又使得代码晦涩难懂。如果一定要更换上下文,那不如分成不同的语句来调用(就像前面的例子一样),保证代码的可读性远比形式主义的“链式调用”更为重要。

    另外举一个经典的例子,比方说 jQuery 就是以链式调用的 API 为它的特色的,你可以去读 jQuery 的源码,所有支持链式调用的方法,它们返回的必然还是 $(也就是链式调用最初封装好的 jQuery 选择器,它就是 jQuery 的 this)。

    我们可以把:

    $('#test').addClass('show').removeClass('hide')
    

    写成:

    let el = $('#test');
    el = el.addClass('show');
    el = el.removeClass('hide');
    

    当然,后面两次对于 el 的重新赋值都是没必要的(但这么写也不会错,道理便是如此),因为 addClassremoveClass 方法返回的对象就是 el 自己,所以你完全可以把它们连起来,这就成了“链式调用”。

  • 为什么有人会信 XD?这是我自 2012 年知道这个人之后一直都觉得费解的问题。一个从来都不是专注于技术的人却在技术圈子里拥有一些莫名其妙的 credits,这是值得深思的现象。

  • 在混合范式语言里,比如 JavaScript,你说的这个就是基操。链式调用的精髓是方法自身要返回 this,至于方法是继承来的还是 mixin 混入的并没有什么区别。

    @darkbaby123 提到继承和 mixin,是想说如果考虑“关注分离”(concern separation) 的话 FP 和 OO 的区别,特别是 explicitly 和 implicitly 的区别。

    至于你问的用继承或 mixin 来组织代码可以把 pipeline 变成 chainable,这是可行的,但不是一定的。通过继承或 mixin 得到的 methods 需要返回对象自身,满足这个前提那么就是 chainable methods。而 pipeline 不存在这个限制,这也是 @darkbaby123 说它更灵活一些的根本原因。

    另外在混合范式的语言里,FP 和 OO 的特性经常是可以“互利互惠”的,比如说 JavaScript 的 pipeline operator 允许你这么来实现 mixin:

    // without pipeline operator:
    class Article extends Sharable(Editable(Model)) {
    }
    
    // with pipeline operator:
    class Article extends Model |> Editable |> Sharable {
    }
    

    这是因为 JavaScript 的 mixin 本身就是一个 Function,它接收一个对象,返回扩展/修改后的新对象,而基于原型的 JavaScript 只需要一个对象就可以 extends(继承),于是就这样把 OO 和 FP 的特点都发挥出来了。

    P.S. JavaScript 的 pipeline operator 目前还处于 proposal stage 1 的阶段,但可以使用 babel 来支持。FireFox 已经开始支持这一特性。

  • 啧啧啧,难道这篇帖子不是后端对前端的敌意?你既全世界?你找不到靠谱的前端所以全天下的前端都是垃圾?

  • Ruby 3 咋样了 at 2019年05月28日

    这图应该是搜索热度,跟性能没关系。

  • Ember SEO 如何使用多语言? at 2019年04月22日

    你定义 computed property 的时候,用 intl.primaryLocale 或者 intl.locale 作为 dependency key,这样才能在当前语言变化的时候更新。

    不要用你那个 head-title 的办法,多此一举。(就算要用也应该定义成 Object-Based Helper,然后定义 compute 方法来动态更新。)

  • Ember SEO 如何使用多语言? at 2019年04月18日

    Sorry,昨天有事没有继续关注这个帖子。你后来的解法是对的。

  • Ember SEO 如何使用多语言? at 2019年04月17日

    ember-intl 有一个 IntlService,把它注入到你定义 seo meta tags 的地方,通常是路由或另外一个服务,然后调用 this.intl.t 就可以了,用法和在模板上的 {{t ...}} 一样(传参相同)。

  • Ru2sbty China 正式成立,预祝大会圆满成功!

  • 也不尽然啊,如果说你只考虑做项目/产品的公司或团队协作,这么说还有情可原。可开发者并不只局限于此啊。比如说有那种独立开发者,一两个人做一个或几个商业软件出售的,人的确就不是/没有专职的产品经理,用户有什么反馈都是直接 email 或者通过别的 online support 途径来诉求,学会理解客户的需求对他们来说就是功课之一。

    还有那种专职做开源软件的,可能某种意义上他们没有(或少有)商业客户,但是他们作品的使用者(大部分也是开发者)其实也是客户啊,提交 issue 或者 feature requests 本质上也是客户需求,他们往往就是自己的产品经理。

    限定了工作类型的话,你的说法有道理,不过原文并没有局限“你是哪种开发者”,所以考虑到现实世界的多元性,顶多说那是可选的,仅供参考,但未必是不可行的。

  • 不用联系我了,我只是点一下需求里不明确的地方,我个人是没有空闲时间做这些的。

  • 它这个 API 是做插件用的 API,而不是搜索有哪些插件的 API,你说的搜索应该是要搜索有哪些插件可用吧?

  • 如果 sketchup 那边有 API(这我不清楚),纯 client 就可以做了,没看明白一定要 ruby 中转一下是为了什么。

  • 没有的,只有第三章。

  • 嗯?我看到的是第三章,真的好无趣就跟看字典差不多。你是想说精彩的在后面?