• 全栈营感想 at 2016年09月22日

    粗略的看了下, 你们的全栈, 并没有教 responsive, 也没有做资源优化等 web performance 方面的内容. 前端用的是 bootstrap, 连自己搭个东西学习的过程都省了, 且把 bootstrap 用成了所谓的 960px. 客户系统用的 meiqia.com, 也不是自己做的. 也没有看到针对 js 学习方面创作的 js 代码. 后台代码看不到, 就不说了. 在这坛子里也没亲没故, 不怕得罪人, 说句, 出 5 万块钱花 2 个月这么短的时间, 学到的东西既不扎实, 也不全面. 这世界上捷径是很少的, 特别是技术上来说. 奉劝搞培训的人, 请你们不要收贷款/砸锅卖铁/欠债来的学员. 虽然是经济社会, 太不讲良心说不好还是要遭罪的.

  • [老板只给了一本 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 搜下.

  • 题主的不就是 crud 么? 不过是带了 scope. 而且简单, 也仅和该 model 联系紧密, 也不涉及到跨 model 操作. 做个类放到 lib 不会过度了点?

  • controller 里面尽量少逻辑, 特别是这种没必要的. 把东西放到 model 里去, 外面使用类似 xxxxx.filter_by(参数) 这样不就成了. 另外类似这种其实只是匹配而不太逻辑的东西, 用动态方法也是可以的.

  • &. try 基本上用途都是对付对 nil 对象。a.b.c 这样的火车是 nil 的老窝。 代码中频繁出现 a.b.c.method, 违反 Demeter law. 我觉得需要认真思考类设计,并适当包装。 &. 和 try 在代码中到处出现的时候,可以用 null object 来解决很大一部分。

  • 有些 Gem 总是有问题 at 2016年06月30日

    建议以 rbenv,rvm 代替 sudo 和 system ruby。

  • 看了下,大概是全栈的样子,不过好像没看到对学员的要求和知识储备。主要内容大概是倾向于实操。 我觉得一个知识的学习,两部分都不可少的,知识理论和实操。文中有 ‘跳过枯燥的基础理论’ 字样,还真让人不放心。 如果是一个普通的没基础的人,两个月的时间,不吃不睡,最多也只能把大象的皮毛摸个遍。独立地做个产品,我估计够呛。 我真心建议, 对于普通人,自认自己仙风道骨、不是凡胎肉体的除外,将时间放大到 6 到 12 个月。可能性会大很多,也有时间来充分的思考,领悟知识点之间的联系。脑子不是大水缸,只要倒得多,倒得快,就能满得快。更像是个细脖子瓶,领悟是需要时间的。

  • 我觉得从 rails 来管理插件,但不负责异常处理,会不会稍微简单点。 做一个加载器,比如 initializer 中的 plugins_manager.rb. 管理插件的开关状态文件(plugins_state.yml),并根据此文件加载 plugins。 插件自负责异常,确保失败时要处理自身在 plugins_state.yml 中的设定,touch restart。

  • (貌似 BUG)奇怪,顺便报下:为什么「注册」和「api] 两个词连起来,「api」就不显示了。

  • 这是 google 的 geolocation: https://developers.google.com/maps/documentation/javascript/examples/map-geolocation,里面有示例。国内不翻墙可能用不了,需要注册 api key。

    整个流程是从 google 那边走的,你整合代码,配置好 api key 即可。和「mvc 之间的关系」好像并没有什么关系。

  • Ruby 2.4.0-preview1 发布啦 at 2016年06月23日

    刚测了下,2.4.0preview1 和 rails5 rc2 配合好像没什么问题。

  • 其实真心推荐搞个 hp gen8, 弄个 esxi,然后把这一团线扔出窗外。不过好像来不及了。

  • 问题如此模糊,感觉不怎么好回答吧,什么样叫「不重」?「必要组件」包含哪些?「兼容性好」到底要到哪个 ie 版本?「适合国内」单纯指国内浏览器兼容性还是另有所指? 虽然有 base、skeleton 等轻型框架,但好像并不符合「兼容性好」,「适合国内」的特点。基本都是 ie8+ 的起步,新的基本都是 ie9 起步。Semantic UI 之类的还是 ie10+。 自己写的话,抛弃 rem,加上各种 fallback,弄个 reset 起步应该是最灵活的。 要么就是 css 预处理 + bootstrap、foundation 等等来深度定制,切掉你不要的部分。

  • 个人对各种语言和技术都比较感兴趣,会去了解功能,特点以及应用范围等相关信息。至于语法等细节,则不会特意去学。倒不是说懒或者性价比低,而是不经常使用的东西,学了白学,还是会忘记的。

  • 下午一个 bundle 命令花了 2 个小时, 中间断了很多次。

  • 不会写前端感觉太痛苦了 at 2016年06月18日

    首先考虑必要性吧,这个工具的本质、生命周期,以及使用对象是否需要优越的设计。如果确实必要的话,对于设计方面有困难的,还是走极简流比较适合。