接纳自我 - 有感于演讲技巧培训

“Accept Yourself, Then You can Make a Difference.”

{:height=”300px” width=”400px”}

这篇文章主要起因于一个多月前参加的演讲技巧培训。那段经历不断的在脑海中回放,Sally老师的话至今让我记忆犹新,使我有种想表达的冲动。

通常在演讲的前10分钟我内心会十分紧张,甚至紧张的让我忘了词,这次也不例外。演讲结束后,Sally老师问:”Xianjing,紧张好不好?”。 我对Sally老师的问题感到奇怪,因为答案很明显么,紧张肯定不好。但Sally说,”紧张不是问题,紧张是因为我们内心的力量。Accept,将它转成正能量释放出来,带入你的演讲场,你会感染更多的人”。

Sally老师的话让我突然有股醍醐灌顶的感觉,原来这就是接纳。在后续的公众演讲中,虽然我仍然紧张,但已经不再害怕,因为我知道这是我与别人不同的地方。我有力量、有热情,可以通过手势、动作、问题等互动方式将紧张转化成我演讲的助力。

但,这并不是最大的收获。这个顿悟所带给我的更多的使自我认知。

先谈一下对接纳的理解。接纳是什么呢?

接纳是一种能欣然接受现实自我的一种态度,客观不评价,承认自己的不完美。它是朴素的、现实的,它不是心灵鸡汤。接纳的前提是认识自我。

Read More

Share Comments

should not start TDD if no tasking

没有做Tasking(开发任务分解)请不要开始写代码。

1. Preface

我在用户故事开发过程中,经常听到这样的对话:哎呀,这个用户故事开发了20多天,这个故事太大了,解决方案变来变去的;我也不知道做到哪儿了,今天应该做完吧(但实际上5天后才真正完成开发);哦,昨天我们部署环境挂了,修了一天部署脚本;啊,不知道,这个功能也包含在这个故事里?;我们昨天没有提交,一个测试还没写完。;showcase? 不行,我刚把后台接口做完,前台没做呢。每每听到这些,我都有些抓狂。同学,做任务分解了么?多少个任务?完成多少了?一个任务至少一次提交吧?没做任务分解咋写代码?啥啥,任务列表在哪儿?心里?好吧~~~

让我们来回顾一下开发任务分解以及它的专业范。

1. What’s Tasking in TDD

Tasking是指在用户故事开发之前针对需求进行的任务分解。它一定是为了开发的任务分解,不是单纯的需求分析,否则变成了用户故事拆分。尽管用户故事拆分可以是开发任务分解的一个副产品。

开发任务分解后会得到一系列的开发任务列表,该任务列表反映开发人员从技术解决方案角度对需求的理解;它指导开发人员进行编写代码;随着开发任务的逐一完成,用户故事的开发进度也清晰的展现;与此同时,开发人员对需求理解不断得到加深,从中实时调整开发任务,保证用户故事的顺利开发。

Read More

Share Comments

anglarjs翻译: $q

最近对英语文档的阅读理解遇到了一个瓶颈,感觉需要n遍重复的琢磨,受到公司同事的启发,尝试翻译下,也帮助和我有同样问题的小伙伴。

1. What’s $q

$q是从Kris Kowal的Q中获得灵感从而产生的一个promise/deffered实现。

CommonJS Promise方案描述了promise与代表异步操作结果的对象进行交互的操作规范,其中相应的异步操作可能在某一时刻结束,也有可能不结束。

从错误处理方面来看,deffered和promise APIs是针对异步编程模型,而try, catch和throw关键词则是针对同步编程模型。

下面这个例子中,我们假定变量$q和scope在当前上下文中可用,它们或者通过注入方式创建,或者直接传入。

Read More

Share Comments

玩转Grunt(三): JSHint静态代码检查

在这篇文章中让我们来看一下JShint静态代码检查工具以及它如何与Grunt集成。

1. 静态代码检查

静态程序分析(Static program analysis)是指在不执行计算机程序的条件下,进行程序分析的方法。-wikipedia

静态代码检查通过分析程序的语法、结构、调用流程等来检查正确性、是否满足编写规范,找出其中可能隐藏的错误与缺陷,比如错误的逻辑表达式,比如程序中不安全不明确模糊的调用部分,eval,比如无用的代码、比如死循环,比如复杂的代码嵌套等。统计证明,在整个软件开发生命周期中,30% ~ 70% 的代码逻辑设计和编码缺陷是可以通过静态代码分析来发现和修复的。

2. Javascript中静态代码检查工具

基于Javascript语言的特性,很多tricky的问题让人抓狂,不正确的使用会导致不可预测的bug,比如==比较操作,所以静态代码检查工具显得尤为重要。另外从代码规范检查角度来讲,可以有助于项目保持统一的编写风格。

在Javascript语言中谈到静态代码检查就不得不提到JSLint和JSHint,其中JSLint是Douglas Crockford编写的,将他认为的那些重要的js编程实践作为静态检查项,但是因为JSLint相关检查项过于严格,无法妥协,JSLint的使用程度并不如想象中的广泛。

JSHint就是在这样一种社区驱动的情况下出现的,是轻量级的JSLint,可以自定义检查选项,相对比较灵活。它的源代码是fork自JSLint,可在Github JSHint找到。它的检查选项主要分为四大类,语法约束、代码风格、代码复杂度和环境相关的选项(e.g.全局变量)。

Read More

Share Comments

JSHint在线文档翻译(二): 选项

JSHint 选项

这里介绍了JSHint的完整选项列表,如果你发现有任何选项缺失,请创建一个bug或者发邮件

1. Enforcing选项

当下列选项设置为true,JSHint会基于这些选项对代码产生更多的警告信息。

1.1 bitwise

这个选项禁止在javascript中使用位运算符,如 ^ (XOR), | (OR)。在javascript中位运算很少见,&与&&经常容易混淆,大多数情况下应该使用&&。

1.2 camelcase

这个选项允许代码块中的变量名用驼峰式或者用下划线连接的全大写.

1.3 curly

这个选项要求在循环和条件判断的代码块中总是使用大括号包围,即使是单行代码,否则极易引起错误:

javascript允许在单行语句的情况下不使用大括号,如下例所示:

Read More

Share Comments

JSHint在线文档翻译(一):基本介绍

文档

JSHint是一个用来标示在JavaScript程序中容易引起问题和困扰的代码,JShint包含了它的核心类库以及一个命令行程序,这个命令行程序作为一个npm模块进行分发。

更多的文档参见:JSHint选项CLI标志位创建JSHint报告FAQ

1. 基本用法

安装

将JSHint作为一个Node程序安装是最简单的使用方式,参加以下命令行:

jshint
1
npm install jshint -g

-g 指JSHint将安装在系统路径;如果没有这个参数,JSHint将只安装在当前路径。

Read More

Share Comments

玩转Grunt(二): Gruntfile 详解

Gruntfile.js是Grunt工具的项目配置文件,它主要用来定义需要运行的任务及配置信息、加载这些任务使用的插件和注册他们的运行顺序。要想读懂这个文件,首先需要了解Grunt 的运行机制以及配置。

1. How Grunt works

Grunt是基于nodejs平台开发和运行的,那么讨论grunt一切都离不开nodejs的模块机制。在Grunt中核心模块即是Grunt,它提供了grunt用到的的所有的公共方法和属性。当我们在命令行运行Grunt命令时,它会以node的require方式加载本地安装的grunt模块(包括内部api),并应用Gruntfile中的配置项,最后执行指定的任务或者缺省的任务列表。

以下几段代码也证实了这一点:

Read More

Share Comments

玩转Grunt(一): Minification

1. Preface

在上一期Grunt初探一文中提到,Grunt将Javascript项目的构建任务(合并压缩、单元测试、测试覆盖率、静态代码检查等)自动化,大大优化了前端开发的工作流。今天让我们来看一看Grunt是如何帮助我们在持续部署的环境下解决Minification的相关问题。

2. Minification

在开始Grunt集成之前,我们来看一下什么是Minification。Minification简单的说就是为了减小前端js/css文件大小,通过去掉多余的注释和换行缩进等,使得下载和运行更快,提高用户体验。

2.1. When minify under continous deployment

那么Minification需要解决哪些问题呢?

Read More

Share Comments

Test Automation

测试自动化是每个敏捷团队必须坚持的实践。

1. Why Test Automation

在敏捷开发中的迭代有两层含义。第一,迭代是交付式的,仅仅开发工作的完成是不够的,迭代结束时需要交付可工作的软件,从而能够部署上线并取得反馈。第二,迭代是增量式的。随着开发过程的进行,系统完成的功能点逐渐增多,每个迭代交付的内容除了本次迭代开发完成的工作,还需要包括以前所有迭代交付的内容。这也就意味着,每次迭代的测试不止要保证本次迭代增加的新内容得到验证,同时以前迭代交付的内容也必须得到验证,也即通过回归测试保证以前交付的历史功能不受到影响。

然,回归测试的工作量随着开发完成功能点的增多,往往是成指数级增长。用传统的人工测试方式已经不能够满足当下快速开发及交付的节奏,所以要想保证项目成功的交付,就必须进行测试自动化。

Read More

Share Comments

The Fact of User Story

1. Preface

很多时候,当做事迷失于细节,就会忘记了当时做这件事情的本来目的,做项目也是一样。

2. What’s User Story

用户故事描述的是用户想要在某一场景下达到的目标,即业务价值,用来作为需求的提示和制订计划。

3. Why User Story

当用户看到或使用软件后,通常会产生新想法

经验告诉我们,软件需求是易变的,不确定的,我们不可能很好的预测到将来需求的变化。用户在看到或使用软件后通常会产生新的想法。这种需求的不可控是软件项目中最大的风险与痛点,也正是这种不确定性的存在使得我们必须关注用户需求的核心目标,并且频繁的,以最快的速度将已工作的软件与用户进行沟通,及时捕获用户的新想法或新需求。

用户故事就是在这样一种大的环境下随着迭代式轻量级开发方法的出现而出现。

Read More

Share Comments