解决搬瓦工磁盘满载的问题

  已经很久没有关注自己的博客了,待回来细看时,发现文章下面自己写的评论服务已经挂了。虽然之前的大部分功能并没有完全完成,但作为一个有追求的developer,怎么能坐视不管呢。接下来就大致简单复现一下发现和解决问题的过程。

使用 AWS China 的几个坑

  在没有使用AWS China(Beijing Region)之前,我还天真的认为它只是亚马逊云服务的一个中国区延伸,会延续AWS所有的服务。但是在这两天的使用之后,发现AWS China和AWS其他Region的服务差距还是挺大的,所以简单罗列一下,这两天使用它时发现的几个坑(后续也可能还会增加)。

DevOpsDays有感 - DevOps概谈

  有幸参与了3月18号在北京举办的DevOpsDays活动,这也是DevOpsDays这个全球性的DevOps聚会第一次落地中国。官方给出的数据是,大会吸引了将近1200名参会者。在此期间,也有机会见到了被业界称为“DevOps之父”的Patrick,以及《持续交付》的中文译者乔梁。从火热程度、嘉宾阵容以及票价上来说,这样的技术活动可算是较为盛大了,但是从一个开发者的角度来说说,会议中的“干货”才是我最期望看到的内容。本文将会从个人角度来回顾这个会议中的一些内容,并针对其中DevOps相关内容给出一些自己的认识,如有不正之处,还望各位读者指正。

[译]方法的长度

本文翻译自老马(Martin Fowler)的博客文章,该译文现已被博客原文收录在其下方中文翻译处。

  在我的职业生涯期间,我曾听过很多关于一个方法(或者说函数,本文针对两者将不做区分)应当有多长的争论。这其实引申到另一个更加重要的问题上:我们应该在什么时候把代码封装在它自己的方法内?有些准则会基于方法的长度,比如方法的长度不应该超出屏幕可以容纳的范围。有些会基于复用,即任何被使用超过两次的代码都应该抽出自己单独的方法,而只在一个地方使用过的代码就应当保留在行内。然而,于我而言,最合乎情理的还是这种论点:那就是意图和实现的分离。如果你不得不费点精力查看一段代码,才能弄清楚它具体做了什么,那你就需要把它抽出成一个方法,并且用“它具体做了什么”来为其命名。这样当你再次读到它的时候,这个方法的意图对你来说便一目了然,并且大多数时候你将不再需要关心这个方法是如何实现它的意图的(也就是这个方法的内容)。