• [老板只给了一本ruby on rails web的书] , 老板如果一本都不给, 或者不给你来个1对1喂饭, 你就没办法了吧? 鬼斧神差是什么玩意? 类型的什么都没有, 你在讲笑话? 很奇怪某些人, 不爱一个玩意, 偏到这玩意的爱好者社区去发一些低级的牢骚, 究竟图的是啥?

  • 断断续续玩了好一阵子, 感觉 crystal 对我很有吸引力. 几点粗略感观:

    1. ruby 语法的简洁美观.
    2. crystal 本身是用 crystal 写的. 相比于 c, 研究源码更方便, 视角更高层. 对语言本身的开发和迭代更容易(待考).
    3. 静态类型, 但却不必指定类型, 大多数情况下会自我推断. union type (..|..), 比如不是整数就是字符串.
    4. 没有因为静态牺牲掉灵活性. macros 可以元编程.
    5. 可编译, 对于源码保护应该会很好. 部署会更方便.
    6. 并发, 确定在 roadmap 中. 看代码好像是有相关模块, 但在 roadmap 中没有显示已完成.
    7. 标准库整合了 spec, json, oauth, websocket 等功能.
    8. 性能, 快到离谱. fast as c 不算虚言. 8.* 对于 ruby 程序员来说, 天然都掌握了大半 crystal 语法.

    总结下, 这是一个语法优美, 性能强大, 面对对象的语言, 很多人特别是 js 方向的程序员, 可能认为函数式编程是未来, 不过我觉得面对对象对于解决软件复杂度问题还是大杀器. crystal 大多数情况下, 可以按动态语言的编程习惯, 来写出静态语言程序. 且 crystal 在静态类型的前提下, 没有牺牲掉灵活性. stdlib 对于流行技术做了内置, 可能是人称之为 modern stdlib 的原因? 并发被当做重点特性来对待, 处于 语言的 roadmap 中. 就网络程序的发展来看, 有后台 api 化, 重前端的趋势, 对于这类app, 后端的 framework 会追求轻量, 并发, 高速, 我觉得 crystal 还是很有发展潜力的. crystal 高速, 省内存, 高级语言的特点, 我觉得会比 ruby 适合于更多的领域. 只不过 crystal 正处于发展中, 有待时日吧.

  • 2.3 可以编译 bytecode. 记得看过个ko1的演讲, 好像是说能提高30%的启动速度. 数字记不大清了.

  • rubymine 和 atom 是两种东西. 前者 ide 后者 编辑器.

    atom 即便是未来, 也是编辑器的未来. atom 速度上不如sublimetext, 功能也没有什么独到之处. 不过 hackable 可以自定义极多的地方, 可以完全打造出适合自己的编辑器. 即便如此, 它也并不是 ide.

    而你要的功能是 ide 所具有的功能. atom 即便弄上 ctags 之类的, 也达不到 ide 中的水准. 诸如你说的跳转到定义, 以及自动打开该方法对应的文件, 且定位到该位置, 以及代码自动补全等功能, 都建立在对源码的 parse 上面.

    用编辑器的话, 我觉得把 difinition 放脑袋里, 加上适当的便于查找的组织结构会比较靠谱. 不同的东西, 不同的用法.

  • 就个人观感, 感觉你是做社会调查的, 还不如真到知乎问呢, 估计人更多点. 我觉得提问题, 首先对问题是否成立, 总得先做个研究吧, 无论你是做社会调查, 还是问技术问题. 很多国企程序员素质高, 你可有论证? 假设你的前提成立, 那么是否同样有很多, 甚至更多国企程序员素质低呢? 再假设这个鄙视链真实且普遍存在, 是否是大量低素质的国企程序员拉低了这个群体的观感呢? 如果是, 那么和该群体存在高素质人才就无关了.

  • 我觉得搞了两年ruby, 连个字符串翻转都不清楚, 可能稍微会有点问题吧. 我倒不觉得不了解这个知识本身能算多大问题, 而是感觉你在自身知识圈上的拓展做的有点不够. 比如说这个采集的工作, 基本上就是分析html结构和css结构, 然后对采集的内容可能会进行一定的操作, 也就是字符串操作. 按道理应该会对html, css, 以及字符串操作比较精通才对. 程序员有一定的视野, 对自身发展, 业务能力方面, 是绝对有好处的, 视野来自于自己对自己知识边界的拓展. 比如你说的前端, 深入一下, 学习成本并不会非常高, 收益还是较大的. 于其问现在自己值多少, 我觉得换个问题问问, 你觉得你自己还能提升的空间有多少? 二十几岁总的来说还属于积累的时候.

  • Ruby 类的问题 at 2016年07月15日

    实现的问题只能在 c 源码中得到解释. 要理解这个实现上的技术问题, 只能看源码. 源码包中的 class.c 应该能找到答案.

  • You Scored: 10 / 10 Ranking: Ruby expert! 好开心😆

  • filco 系列你说的三种轴我都用过. 我说下个人看法,仅供参考: 对于敲文字或代码, 青轴我觉得最差. 因为青轴的反弹最慢, 会有种键位弹起跟不上手速的感觉. 茶轴和红轴好很多, 反弹干脆快速, 无拖泥带水感. 茶轴和红轴, 手感都可以, 码代码两个都不可能是错误的选择, 差别是茶轴有点点段落感, 红轴由于触发键程短, 会更有蜻蜓点水的感觉.

  • 新手请你先学会看日志, 然后学会把关键信息贴到google搜下.