• 广州,我主要是做前端的,主要维护着一个 Rails 的商城项目。😂

  • 浅谈循环之硬件级实现 at 2019年03月05日

    向量化指令还没怎么看过,我稍后看一下,谢谢提醒。

  • 对的,已经更正。

  • 上京东看了一下这本书已经缺货了。🐄

  • 看着很不错,感谢分享。

  • 说得很有道理

    我之前的做法是预打包一个足够简单又足够通用的基础镜像,公司所有 Rails 项目都基于它来打包,以保证快速扩容时可以在集群的任何一台机器上快速部署

    我是否能把这理解成,COPY 前面的部分可以打包成一个基础镜像?然后其他的 Rails 项目都用同一个基础镜像?

  • 花时间清理这些倒也不是不行,不过区分了编译依赖还有运行依赖,并清理了之后其本质也是减少了容量而已吧?我当时考虑是清理这些似乎对减少容量没有太大的影响所以就把优先级放低了。

  • 感谢指正。那个最大的基础镜像不是基于 ubuntu 的,是我先入为主了,已经更正。ubuntu 的基础镜像确实只有几十 M,基础镜像是 buildpack-deps

    This tag is based off of buildpack-deps. buildpack-deps is designed for the average user of Docker who has many images on their system. It, by design, has a large number of extremely common Debian packages. This reduces the number of packages that images that derive from it need to install, thus reducing the overall size of all images on your system.
    
  • 谢谢,应该不会用 Docker Swarm 了,公司的运维都把 K8S 环境搭建好了,估计到时候会直接上 K8S。

  • 感谢,我稍后会去看看,最近公司也正准备做这个事情。目前我还停留在镜像打包的地步。

  • 我相当同意。所谓最佳实践应该是基于前人方法以及技术的较为通用解决方案的总结。通俗来讲应该是“道”层面上的东,不过现在很多地方都演化成“术”层面上的东西了。每个人的开发方式可能还有习惯都不太一样,把“术”都定死了难免让人觉得无所适从(当然团队协商结果就另当别论)。

  • [译] 提高编程能力的秘诀 at 2019年02月04日

    很有价值的一篇文章,已收藏。感谢分享。

  • 意见很中肯,其实我个人是不反对前后端分离的,好像许多读者都误解我的意思。我其实反对的只是两点 1. 不考虑实际情况盲目分离。2. 不考虑上手成本和代码可读性而不断堆积最新语法(当然似乎每个人都觉得只有自己的代码才是可读的,这就没办法了)。在有些场景我们其实也不得不分离吧,比如一个重交互的应用如果用 jQuery 去写是很闹腾的事情,这种时候我会考虑分离的。只不过如果是个人选择的话我会选择 Webpacker 这个 Gem,毕竟我觉得并不是所有场景都需要把整个站点去分离。

  • 哈哈,其实我也就用 Digital Ocean 的 api 来创了两个实例操作了一下而已,其实没遇到什么大坑,因为不够深入。

  • 曾经操作过这两个东西,用起来感觉很像 👀 。不过之前听一些朋友说 swarm 很多坑,具体没去考究,不知道是不是真的。

  • 虽然我们观点不合,但是也感谢你特地跑来捧场。😈 😈

  • 就你最能捧场,谢谢。😀

  • 谢谢,但是有时候这种平衡也不好把控,特别是在这个选择太多的时代,我们都倾向于把最新最酷的东西加进去。但是很多时候在后面才发现有些东西其实有点“鸡肋”了。个人能力有限很难把握好这种平衡,有时候太保守了也可能后面会觉得保守过头了,只能在项目演化的过程中不断调整脚步,并总结经验了。

  • 首先感谢你的长篇回复,至于统一写法是降低了技术成本还是提高了技术成本并不能单靠是否只需要学习一门语言来衡量。这个一个人说了不算,需要考虑到团队的情况,以及会带来的问题。

    至于后端会不会去看我的代码这个我没办法控制,我说的“前端工程师写的代码后端需要花费很大的力气才能够读懂的话”其实只是一种不太严谨的约束,其目的是为了不让项目脱离掌控,我的意思是就算前后端分离了,也应该从项目角度来全局考虑一个方案是否合适。我不会要求后端去看我的前端代码,但是我觉得让代码通熟易懂是很重要的,在某种程度可以尽量降低后端(可能前端也是)审阅代码的成本,因为这对我而言才是真正地降低了技术的成本。

    后端去限制前端的技术栈 请不要曲解我的意思,如果你认为让代码尽可能通熟易懂是一种对前端技术的限制那我也不好说什么了。

  • 前后端分裂 at 2019年01月26日

    OK thx

  • 前后端分裂 at 2019年01月26日

    @Rei 博客地址更换了吗?我最近想写文章想引用你这篇文章。

  • 有趣地寻找 Ruby 方法 at 2019年01月22日

    感谢。

  • 一时没反应过来,你说“我们”的时候。我就在想豆厂什么时候用过 erlang。

  • 同是前端,不过现在主要写 Ruby。业余时间会考虑试试 Haskell

  • 了不起。😃

  • 职业上使用 Erlang 和 JavaScript。现在国内有 Erlang 公司吗?好像很少的感觉。

  • 我比较好奇作为一个开发你是怎么学习设计,并提升审美的?我觉得让一个开发来设计产品是痛点 😂,感觉无论怎么设计都设计得不好。我看你 2010 年的博客跟今天的博客设计风格差别比较大,现在的博客看起来相当的舒服。

  • 2O - 分享生活价值 at 2019年01月21日

    好像要下载才能够体验了。

  • 设计看起来很舒服。

  • 感谢你的长文评论。你所说的观点我完全赞同,几乎都是我近期在反省的事情。当发现自己渐渐演变成螺丝钉的时候,或许应该考虑是不是哪些地方需要改善一下了。