此文章旨在帮助java开发者快速了解并使用Go. 最开始我们引入一些java开发者容易熟知的特性，然后在给出一些关于go语言构建模块的详细解释，最后给出一个在java语言中没有直接对应的结构的例子
概述
原文链接：Go for Java programmers
继续阅读 »
面试或被面试时基本都会涉及到这个最原始的 JavaScript 基础问题，试想一下您有没有在某些时候向别人解释这些概念时，把自己给绕进去了；网络上偶遇一篇英文文章，细读之后觉得有参考价值，文章不长，就顺手翻译了一下，希望某些同学可以用的上。
原文文中的 Scope 翻译成中文是“变量作用域”，译文某些地方直接简称为“作用域” ，Closure 翻译后是“闭包”。Rebort Nyman 的原文是 Explaining JavaScript Scope And Closures，某些不清楚的地方可以直接参考原文。
以下是译文
背景
很多文章或博客都在试着解释作用域和闭包，但大多数都没有解释的很清楚（crystal-clear）
继续阅读 »
更新日志
英文原文出处：http://amattn.com/p/arc_best_practices.html
一些可选背景故事：
相关文档：迁移至ARC版本说明
Mike Ash 在他的 Friday Q&As 也有一篇关于ARC的文章。
深入的技术文档在 LLVM 项目的 CLANG 网站上。
假设你正在使用 iOS 5 或者更高版本，而不是 4。实际上，弱指针是 ARC 中的一个重要工具，所以我不建议在 iOS 4 中使用 ARC。
更新注意事项
这份文件自从2011年发布以来，一直在不断更新。最后一次微小的修订是在 2013年发布 iOS 7。
继续阅读 »
本文翻译自老马(Martin Fowler)的博客，该译文现已被博客原文收录在其下方中文翻译处。
“基础设施即代码”是一种通过代码来定义计算和网络基础设施的方法，它可以应用于任何软件系统中。这样的代码放在代码版本控制系统中，具有可审查性、可重用性，并且符合测试惯例，还完全遵从持续交付的原则。该方法已经在过去的十年内广泛应用于快速增长的云计算平台中了，而且也将会成为接下来管理计算机基础设施的主要方式。
继续阅读 »
翻译前言
被原作者认真研究——煮鸡蛋这么琐碎的问题——的精神感动了，于是斗胆（擅自）翻译成中文。
原文为日语，虽说尽力而为，无奈本人 N6 水平，难免错漏，担心被译文带坑里的读者，请移步原文
继续阅读 »
本文译自 Dmitry A. Soshnikov 的文章 ECMA-262-3 in detail. Chapter 2. Variable object.
参考了一些译文，作为自己学习 ECMAScript 的一点积累。
概要
创建应用程序的时，总免不了要声明变量和函数。然而，解析器（interpreter）是如何以及从哪里找到这些数据（变量，函数）的，当我们引用一个变量时，在解析器内部又发生了什么？
许多 ECMAScript 程序员都知道变量与执行上下文密切相关：
```js
var a = 10; // 全局上下文中的变量
(function () {
var b = 20; // 函数上下文中的局部变量
}
继续阅读 »
文/Robin
本文由币乎社区（bihu.com）内容支持计划奖励。
本站推广
币安是全球领先的数字货币交易平台，提供比特币、以太坊、BNB 以及 USDT 交易。
币安注册: https://accounts.binancezh.pro/cn/register/?ref=11190872
邀请码: 11190872
这是「区块链技术指北」的第 8 篇文章。
如果对我感兴趣，想和我交流，我的微信号：Wentasy，加我时简单介绍下自己，并注明来自「区块链技术指北」。同时我会把你拉入微信群「区块链技术指北」。BTW，李笑来老师也加入了我的知识星球，文末有加入方式。
在上一篇译文 「译」保护你的个人资产 中，有多达 20
继续阅读 »
开发安卓APP的过程中，肯定有不少人遇见过 Activity Not Found 错误和 Activity State Loss 错误，前者是由于启动的目标 intent 对应的 activity 不存在，后者则是由于在 activity onSaveInstanceState 函数被调用之后进行了 fragment transaction，关于后者有一篇文章{:target="_blank"}总结得非常到位，这一篇译文{:target="_blank"}翻译得也还不错，建议看看。本文则主要介绍我的一个开源库 SafelyAndroid{:target="_blank"}，其中整合了解决这两类问题的最佳实践，让我们一起利用它打造鲁棒
继续阅读 »
本文翻译自老马(Martin Fowler)的博客文章，该译文现已被博客原文收录在其下方中文翻译处。
在我的职业生涯期间，我曾听过很多关于一个方法(或者说函数，本文针对两者将不做区分)应当有多长的争论。这其实引申到另一个更加重要的问题上：我们应该在什么时候把代码封装在它自己的方法内？有些准则会基于方法的长度，比如方法的长度不应该超出屏幕可以容纳的范围❶。有些会基于复用，即任何被使用超过两次的代码都应该抽出自己单独的方法，而只在一个地方使用过的代码就应当保留在行内。然而，于我而言，最合乎情理的还是这种论点：那就是意图和实现的分离。如果你不得不费点精力查看一段代码，才能弄清楚它具体做了什么，那你就需要把它抽出成一个方法，并且用“它
继续阅读 »