此文章旨在帮助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)的博客文章,该译文现已被博客原文收录在其下方中文翻译处。
在我的职业生涯期间,我曾听过很多关于一个方法(或者说函数,本文针对两者将不做区分)应当有多长的争论。这其实引申到另一个更加重要的问题上:我们应该在什么时候把代码封装在它自己的方法内?有些准则会基于方法的长度,比如方法的长度不应该超出屏幕可以容纳的范围❶。有些会基于复用,即任何被使用超过两次的代码都应该抽出自己单独的方法,而只在一个地方使用过的代码就应当保留在行内。然而,于我而言,最合乎情理的还是这种论点:那就是意图和实现的分离。如果你不得不费点精力查看一段代码,才能弄清楚它具体做了什么,那你就需要把它抽出成一个方法,并且用“它
继续阅读 »