看到 @大城小胖 做了个H5游戏：马踏棋盘，于是想起研究一下这个算法。
题目是这样的：国际象棋的棋盘为8*8的方格棋盘，将“马”放在任意指定的方格中，按照“马”走棋的规则将“马”进行移动。要求每个方格只能进入一次，最终使得“马”走遍棋盘64个方格。（N=8的情况）
我用python实现了这个算法，其中用到了回溯法，并用贪心法进行优化，以防递归深度太深而溢出。当找到一个解就停止递归。
不过这个解的最后一步与初始位置难以重合，而@大城小胖 的游戏中却要求马最后要回到初始位置，因此算法还要进化
Spotify的敏捷工程文化
Spotify是继Pandora之后，国外第二大音乐媒体网站。上一篇
Spotify的新型敏捷矩阵组织：部落、分队、分会和协会出了以后，很多人对Spotify的敏捷组织形式非常感兴趣。这里@申导 抢鲜给大家带来第二部分，关于Spotify的敏捷工程文化。
第一部分主要提到基于敏捷原则，将人按照小分队Squad的方式来组织，松耦合但紧密联盟(Align)。通过内部代码开源，鼓励“异花传粉”。通过架构解耦、特性开关等手段来做到频密的小规模发布。借助自助的发布和部署服务，减少人们之间的任务交接。所有一切都关于“人”，因此组织更加要关注激励、信任与社区文化，而非等级结构或控制。
第二部分讲的是关于失败，用Spotify的创始人Daniel的话说就是，“我们要比其它人更快地犯错误”。因为失败意味着学习，因此更快地失败就意味着更快地学习，更快地改进。
Python函数式编程
函数式编程
如果程序中的函数仅接受输入并产生输出，即输出只依赖于输入，内部数据不可变，避免保存程序状态，用同样的输入值反复调用可以得到相同的结果，那么这种编程范式就称为函数式编程(Functional Programming，简称FP，又称泛函编程)。
这种风格也称声明式编程(Declarative Programming)，与之相对的是指令式编程(Imperative Programming)，后者中的对象会不断修改自身状态。函数式编程强调程序的执行结果比执行过程更重要，倡导利用若干简单的执行单元让计算结果不断渐进，逐层推导复杂的运算，而不是设计一个复杂的执行过程。
函数编程语言最重要的基础是λ演算（lambda calculus），函数可以像数值一样被赋值于变量，还可以作为其他函数的输入（引数）和输出（传出值）进行传递。
函数式编程历史悠久，最古老的例子莫过于1958年被创造出来的LISP了。而随着程序结构复杂，面向对象编程大行其道。近年来，简洁而且特别适合计算任务的函数式编程又重新崛起，不仅仅是纯粹的函数式语言如Haskell、Clojure、Elixir等，各种流行语言javascripts、python、Objective-C、C#、Swift甚至Java都纷纷吸收函数式编程的部分形式。而且，不仅仅是计算任务，近年还出现了用FP编写的UI应用程序，如LightTable等。
Paul Graham在《黑客与画家》一书中写道：同样功能的程序，极端情况下，Lisp代码的长度可能是C代码的二十分之一。
本文作者@申导 主要采用Python语言为例，是因为它虽然不是纯粹的FP，但Python能够胜任各种编程形式，简洁优雅，通俗易懂，语法接近于Java/C++，特别适合从主流语言转过来的学习者。
天津IT公司大起底第#1弹--颐博游戏5Ebo
天津，简称津，中华人民共和国直辖市、中国国家中心城市、中国北方经济中心、环渤海地区经济中心、中国北方国际航运中心、中国北方国际物流中心、国际港口城市和生态城市、国际航运融资中心、中国中医药研发中心、亚太区域海洋仪器检测评价中心，同时也是夏季达沃斯论坛常驻举办城市。凭借着拥有中国北方最大的港口，天津以其丰富的海洋资源和四通八达的便利交通资源，辐射着京、冀、鲁、豫、内蒙等多个省市、自治区，在传统行业特别是制造业和物流方面中占据着重要的地位，堪称“老龙头”。
管理3.0工作坊在QClub天津软件沙龙成功举办
2014年8月31日，由QClub冠名、天津软件沙龙承办的管理3.0工作坊成功举办。
同时，“洛宽庭”也提供了优雅的场地和爽口的西瓜给大家。
很多基层人员认为敏捷不需要管理，觉得敏捷和所谓的“管理”相差太远，所以对即将到来的敏捷热烈拥抱，自组织了嘛，不用管了。很多管理人员认为敏捷只是“压迫”员工的另一种手段而已，他们觉得敏捷不是“快”吗，不管用什么方法，更少的人员投入，更多的功能产出，在限定的时间内就是好的。但他们在团队应用敏捷的过程中发现他们的管理工作量也变大了。
可以说基层和管理人员都错了，我们大家只能接受我们希望看到得内容。但究竟什么是敏捷管理？敏捷管理对管理者或团队有何期望？有何挑战？管理3.0会给出一些答案。
你准备好面对了吗？
认证敏捷技术实践CSD公开课成功交付
我们的CSD暨敏捷技术实践课程已在北京、杭州、深圳、成都等多个城市开 展。多家国内外知名企业的学员参加后赞不绝口,纷纷向身边的朋友推荐。 2014年8月8日我们成功将公开课带到上海交付,希望能将我们的知识与经验分享给更多的朋友。(Cerfified Scrum Developer, 由Scrum Alliance认证)
敏捷教练与管理3.0
我们的团队具有亲身经历的多年敏捷实战经验，完整体验过从开发工程师、SM直至研发经理的不同角色与挑战。
另外，我们推崇管理3.0思维，以复杂性思维来应对敏捷时代进行管理的不确定性。
在这个充满变化的时代，我们希望通过外部教练与内部变革领导者共舞，帮助企业建立应对变化的敏捷性，从价值入手，改善交付速度，提高质量和效率。
软件产品及其团队是一个复杂网络系统，唯有通过不断地检视与调整，缩短反馈周期，加速进化。
作为敏捷教练，我们将与客户共同成长。除了将业界先进实践经验带给客户形成一些改变，我们更愿意和重视利用教练和引导技术，结合上下文，让蜕变在客户身上发生。改变只是表面和一时的，而蜕变意味着理念与价值观的革新，意味着当教练离场时，团队仍会继续自我进化，不断改进。
另外，我们知道，进化在自然界并非连续发生的。根据“间断平衡”论，每个系统都处于某种稳定态，具有抗扰动的能力。要想形成蜕变，需要借助足够的外力让系统脱离稳态的惯性，重组系统参数，直至进入新的平衡。这里的外力不仅仅是外部教练的指导，更多来自企业内在变革的动力，特别是管理者的支持。敏捷管理者的职责不再是设计组织，而是创造一个容许失败的多样性环境，让敏捷团队自行生长出来。毕竟，“人是环境的产物”。
Scrum Gathering 2014 组织者见闻
今年有幸受到路宁等社区朋友的举荐，以及炫姐姐的邀请，加入到麦兜团队，担任话题内容的总体制作人，负责第二天整天以及第三天上午的内容。
虽然在社区做了几年的活动，但在大会担任制作人，而且是负责所有的话题track，还是第一次。足见大家对我的信任。
Scope-Question-Assumption需求梳理会（需求澄清预习PK）
关于需求的讨论
最近在辅导敏捷团队和教授Scrum课程中，发现团队提出的很多的问题现象可以归结为迭代前需求梳理（Refinement/Grooming）讨论不充分所导致。
根据自己多年亲身实践的敏捷经验，如果在迭代的计划会议上，团队来不及做到澄清和一致理解需求，而是在迭代过程中再进行需求澄清，那么往往导致“迭代紧张、测试不充分、估算不准确、精神面貌不良”等表面现象。
因此，对需求的充分理解应该是迭代的入口条件，应该成为Definition of Done （也有同学喜欢称之DoR, 笔者认为DoR也是DoD的一部分） 的一部分，来确保迭代能够健康地开始。
然后，更深入的根源则是团队不了解如何进行一场高效充分的讨论。
敏捷是一种辅助实现交付价值的手段，不应该过于繁重。下面就根据@申导 早年在诺基亚西门子通信工作时所学到的一种简洁讨论法：Scope-Question-Assumption（简称SQA）讨论会。