Rss Feed

嘉瑜的知性探索

2011年梦想主色调：书、茶、咖啡、红酒、运动、日记、音乐、自制美食、干净明亮的房间

Archive for '学习'

如何挤出时间

September 6th, 2011 by , under 书房. No Comments

看了一篇文章《6 Ways to Find More Time for Yourself》，

1. 把你的安排写进日历中。老外说的calender不是我们通常意义的日历本身，而是说事件安排，Stack是《Find more time and leave your office earlier》一书的作者，他提到将自己要做的事写进日历里，这样可以防止它们被一些其它的意外而来的变化打断，你只需要说我现在还有事，没有人知道你是在床上冥想还是在公园里面看杂志。

2. 减少上网时间。要带着目的浏览网页，就象没有目的的逛超市，走行拖沓，漫无目的，东摸西捡，最后要不需要的东西最后没买到，不需要的东西最后拎回一堆。早做计划，目标明确，指哪打哪，速战速决。比如今天你主要要知道哪些方面的，其它的不要使用太多的时间，“Stack suggests you write a master list of everything you want to look up, and then do so at the end of the day.”对于其它一些东西，可以列出来，再找个你最没有工作学习状态的时候去看。对我来说，最耽误时间的就是游戏，发呆，无意义的在网上点击，看到哪是哪，拒绝思考，长时间沉浸在如何让邮件看上去准确表达并听起来合情合理不至于让人误解或有负面情绪。（题外话一下：LD对我的阴影肯定存在无误，在《潜行阻击》中，香港CIB警察在遇到大事后，都会停职一段时间，来接受心理治疗，我倒是觉得LD的事，我也需要接受心理治疗，写邮件或是打开邮箱时，现在经常脑中晃过Kent或Scott无理的回邮，而害怕。）

3. 少挑肥捡瘦。在选择的悖论 The paradox of choices 一书中，作者Barry Schwartz提到少给自己一些选择，不要老想着挑最好的，因为你根本没有办法确认你是不是找到了“最好”的，当然你如果花了大堆大堆的时间去在50个选择中挑一个最好的，也许是有可能的，但你挑到的东西，不值你选择过程中浪费的时间。正如我读书，我挑来挑去不知道哪本书值得读，最后发现这些挑选的时间，我大可以用来读上好几本书了。

4. Buy time, not stuff. 这与我这种节俭主义者相悖，购买时间，意指有的东西，买的是涂个方便省事又省时，时间比很多东西都值钱，我现在每天必须在路上耗费4小时，一个月交通上用掉的时间 = 半月工作时间 = 4天寿命。倘若这是行走的锻炼的时间，或是和知己聊天沟通的时间，那另当别论，问题是现在只是干坐到屁股疼罢了。好在这种情况不日后即可解决，就可终止我长达2年整的这种无意义的时间浪费了。

Tags:

我的阅读成就了什么

September 6th, 2011 by , under 书房. No Comments

这篇〈沈奇岚：你的阅读造就了什么〉是从战隼的学习探索（嘉瑜的知性探索也是采自此名）中看到的，每天一些零散的时间拿手机逛豆瓣，就会看到这样一些有意义又有趣的文章，这篇我读过三次，很适合自己现在看。最近洗手间放的书是〈少有人走的路〉，断断续续翻来翻去的看过好几次，每次也都看不全。在〈少有人走的路〉中，作者告诫我们必须承认生活大多数不如意，以及痛苦的必然性，并认为“承认痛苦”是提升自己的前提，因为我们必须要以提高心智成熟为终身的修行和目标，心智成熟所含方方面面，如果每一面算人生修炼的一门课程，那这种不断修炼实践的过程就是人生。

在人生每一个阶段课程都不尽相同，有一种就是问题驱动式或是错误驱动式的修炼，有问题发现不足，犯了错误，我们基于我们曾犯下的错误不计大小或是提出的疑惑和问题来制定我们当下的课程和科目，然后专攻修炼。有趣的事，在经过我之前的忽视和反复中，我发现很多这样的修炼，或是不及时，或是迟修，甚至拒绝修，若不是天赋异秉，那么结果通常就是，我必须要重新有时还会不断的遇到大同小异甚至一模一样的问题，也就容易出现心智水平远远低于生理年龄的问题。

在花花的丽江家住过一段时间，实言那是一段放弃自我思想，主动丢弃当下自己的三周，那三周中，我主动将当下的自己扔到一边，腾空大脑和思想，在完全陌生的环境中，我既找不到自己，也找不到自己存在的意义，所以我连最基本的感受都难以细心体察，虽然我有写日记，但回头发现，尽是一片空虚＼所言无物。回来后，自己的变化是看得到的，首先就是我有意无意的在追求一种自己制造的安定享乐的错觉中，做饭做菜，游戏电视，电影，中午和同事八卦些没有油水没有营养的转头即忘的话题，咖啡，逛超市，每天用去大量时间做一些我回过头来完全不记得的事，唱Ｋ下午茶，等等各种娱乐能寻就寻，断不会觉得时间的珍贵，隐隐觉得读书本身是没有用的，还是抓紧时间享受的好。一直到我前天在公车上翻看手时，看到这篇文章，看到这句：

善待自己的心灵，喂养自己的大脑

现代快节奏又媒介丰富的时代，是不是我对善待自己四个字茫然了，过去无非是简单的愿望得以满足就可雀跃如今凡事提不起劲来，我发现我越是“积极”寻找某种“愉悦轻松自然”的生活方式，越是容易迷失自己，因所有与这些相关的关键字在过往都与自己无关，然玩游戏和睡觉发呆，才是我的方法；我发现我越是与其他人相比，我越是远离“愉悦轻松自然”生活方式，觉得好女人应该十指白如葱，又能点化生食为美食，还能瑜珈运动打太极，偶与小资中产的同好事共谈风月。有的人，包括我自己这辈子怕也达不到此种境界，压进模子里最后可也会发现此生无趣，过的不是自己? 那么我应该是什么样子? 答，读书。

然前些时日读了一篇文章，出处也一时找不来，其中提到读书是好，可经常读书却未必就好，大脑长期处在不创造单一接受，容易使得智商降低，思维停滞。我一直想找一两个同好，共同聊读的书，头脑风暴的互相为不同意见争到面红，阅读-思考-批判-思辨-结论-循环，这样的过程才是将阅读价值化的过程。我自问在当下这样的网络和SNS时代，我居然连这样的同好都找不到? 无法进入某一个圈子，说明自己不够投入，并无其它原因，深了久了，自然有吸引力原则起作用，所以只能是阅读不够，思辨不足，思维肤浅，为读而读，此应该乃下乘的读书了。

我的阅读造就了什么，这两日特别有关注过自己平时read了一些什么，发现都只是蜻蜓点水的玩法，皆不够深入，尤其是看到好文，只待叫好，便转了去，一旦转了就自以为是自己的了，便扔至一边不再搭理。书和本、教学视频也是这般命运，学到啥转啥，要看啥就下载啥，控制下载和上网，捡值得读的批判文和思辨文，对比读，确认当前的研究方向，将战线稍微拉长，也许是一种方法。

Tags:

推荐《别让猴子跳回背上》读书笔记

September 6th, 2011 by , under 书房. No Comments

由于自己目前实际的工作一直是纯开发，在没有理论指导和人师的情况下，又单单只进行了几个月的项目经理的实践然后跌得鼻青脸肿，虽然在团队成员和经理的眼中，执行的过程中有不少受到了表扬，并称为是粘性最强的团队，大家的积极性能在这种拖沓的项目中仍能有弹性和热诚，我觉得并非只是因为自身，而是因为成员本身做事有热诚。

自身最大的问题是，无法100%相信其他成员，凡是自己感兴趣的，都爱去插上一脚，很开心的想寻找挑战，凡是有些挑战的活，或是其他成员数日没有交上的工作，自己最后都是操刀上阵。有时界线不明，职责模糊不清，今天一早又有幸看到一篇文章，博主的文章总是节约了我们很多时间，读书笔记简要清楚。这篇文章中提到的别让猴子跳回背上，意指将任务分发出去，让目标自己能独立合格的完成工作，而不是继续要让任务又跳回自己的手上，这其中不是我之前凭直觉和“自以为”来凭空增加信任，而是提到了如何“喂养”，推荐一读。所以转来。

以下是原文：

花些时间总结一下《别让猴子跳回背上》，本书是从的《哈佛商业评论》的一篇同名文章扩充而来，因为跟我目前的环境而类似，花时间总结一下。第一次阅读记录：

#每天一本书#2011年7月6日,201天《别让猴子跳回背上》评分3分.本书是从《哈佛商业评论》中的同名文章扩充而来。

猴子定义：两人谈话结束时的下一个步骤；
猴子理论：主管的工作是将适当的猴子放在适当的部属身上，部属的责任是喂养猴子。

管理者可以运用的5个任务层次：

（5）独立行动，例行性报告；

（4）行动，但需要立即请示（意味着报告频率超过例行性报告）；

（3）建议，等待裁示再行动；

（2）请示要做什么；

（1）等待指示（最低级别）。

整本书就是讲要努力把下属提高到第五级，独立行动。核心内容是要从你的老板那里接受猴子，而不是从你的部属身上，让你的部属具备独立行动的能力。

备注：这书谈的就是时间管理中非常实用一个技巧，学会委托，有效的利用别人的时间，（呵呵，有些不道德，但非常有用）

这本书也是我推荐时间管理类图书豆列的中一本，如果你对时间管理有兴趣，一定要看一下这个豆列：知识分享–开始进行《时间管理》类图书主题阅读

部分书摘：

喂养猴子的六大规则：

（1）喂养或射杀它们，千万不要让它们活活饿死；

（2）只要你找到需要喂养的猴子，你的部属就要找出时间喂养它们，但猴子数量千万不要过量：与其遍地分派猴子而不管结果，不如对每只关注的猴子都有喂养计划（约定沟通的时间、频率和内容）。

（3）按照喂食进度表上的时间和地点喂养猴子是部属的责任，主管不必再沿途追逐即将饿死的猴子，胡乱的喂食：把临时发现的猴子归入系统性工作的猴子之中，不能做救火队员，不告诉他如何去喂，让部属自发的拿出系统性全局性的解决方案和实践行动。过细、过于频繁的后续追踪是骚扰。

组织实务上的基本原则便是，资深管理者不该在未知会直属部下之前，便绕过部属直接对后者的部属宣布指示（明显的例外是，攸关生死的情况）。这项原则一旦遭到破坏，便会导致所谓的越级监督，混淆了任务的优先次序，使管理者本人和接到指示的部属都费力不讨好。

违反喂食时间是很严重的问题，可以将一个部属发生此类错误的情况作为集体学习的机会，在集体会议上不点名批评，并强调重要意义，好过个别提醒的效果。

（4）如果有冲突发生，预定喂食猴子的时间可在任何一方的提议下做出变更，但不被视为延误；事情毫无进展不能作为重新安排喂食时间的借口。

无进度的喂食方式：应该达到什么进度，目前进展情况，为什么产生此情况及相关建议等内容。职责总是以时间为优先，而非准备就绪。总裁没有权利向股东要求更改喂食时间。

（5）无论何时，尽可能面对面地喂养猴子，否则便使用电话，绝对不要用信件。备忘录、电子邮件、传真和报告可以使用于喂食过程，但不能替代面对面的对话。

书面内容可以使人更加慎重和认真，但也是将猴子转移的有效工具和不透露真相的掩饰，因此，将书面内容作为辅助和谈话大纲，保持面对面的对话和及时产生结果，确保真正的沟通和了解，以及猴子不会转移。

即使下一步骤应该由管理者完成，也应当与猴子的主人共同完成，避免猴子以此为契机更换宿主。

其它
1、猴子归属于谁，谁就要至始至终负责，不能推卸，不能跳跃。

2、领导可以给下属方向，可以提出建议，但猴子还是他的，如果没有及时可以给予答复，让他主动去找寻问题的答案，因为猴子在他的背上。

3、高效有序执行，需要人们主动或被动的维护遵守现有的规则，领导不能违反，下属也是。

4、领导不要直接对非直属下属给予指令，容易造成组织结构混乱，如有问题找到最近一级高级领导，让其决策、监督、执行，效果将更好。

5、领导要与下属面对面一同确认猴子数量、喂养时间、轻重缓急。以确保最佳的猴子还活着，适时放弃无效的猴子。上级不必在过程中进行督促管理。如有问题要当面解决不要遗留，不要等待下一次。

6、当领导接下下属身上的猴子，后果就是：1）让员工来监督你2）让他们不必做分内的事情。加重他们的挫败感

7、教练的目的在于培养部属自力更生的本事。自力更生是每个人经过自制、耐性与坚持，才能获得的后天特质。

8、内容再繁复也应该在一页的摘要中写清楚，以便展开立即的对话。

9、报告应该由主人保存，内容可以通过基于摘要基础上的对话来了解并探讨，避免管理者的延迟。

原文：http://www.read.org.cn/html/1563-monkey.html

Tags: ,

使用HtmlAgilityPack解析HTML

June 30th, 2011 by , under 学习. No Comments

近来老大给我找了点有趣的活，帮公司的人事部门做一个小项目，我负责将三大人才网（智联招聘，前程无忧和中华英才）的简历解析到数据库，09年倒是有用火车头去采过一些大大小小的人才网，不过这次因为需要使用C#来做HTML的解析，所以为此在网上一顿好找，最后托Stackoverflow和里面可爱又可敬的先行者们的福，找到了两个开源的三方HtmlAgilityPack和SharpQuery。

HtmlAgilityPack http://htmlagilitypack.codeplex.com/ 
在这篇回复的最佳答案中, 提到了如何在该三方中应用LINQ与XPath

SharpQuery http://code.google.com/p/sharp-query/
使用的是jQuery的CSS选择器的概念，所以可以很方便的定位HTML标识

做这个多少是个细致活，其实不需要用到太多技术，只需要了解基本的XPath即可，
关于XPath的一些有用链接，

  1. 这是XPath的语法说明 
  2. 觉得Resig这篇XPath与CSS的选择器的语法对比挺清楚的，其实在这儿可以发现SharpQuery没必要使用
  3. 其实这儿将XPATH的选择器讲得更明白，可惜还是不全
  4. w3cshools的权威吗? 仍然感觉不够全
  5. XPath 2.0的官方spec
  6. 挺不错的非官方API
  7. CPan.org的XPath 1.13

Tags: ,

MSS 2010 学习手记

June 15th, 2011 by , under 码农日记. No Comments

欠债，

  • MSS的配置方法

以下为MSS的相关资料

MSS API及SDK文档：

教学文档：

内容爬取相关：

记一次jQuery+WCF页面的离岸协作

March 12th, 2011 by , under 码农日记. 2 Comments

背景：与美国某公司的一个离岸外包中的一个页面，最后交付物为，20来多存储过程，4000行左右的C#代码量，2000行左右的JS代码量，数个文件，7个jQuery plugins，参与人员及职责：

  • BA一名（美国方），负责把握进度、控制风险、阐述需求、解答需求问题。
  • Application Developer（美国方技术接口人），负责建议/帮忙解决开发中出现的技术疑问，负责C#及SQL Code review，审核代码质量、安全性和性能，负责性能测试。
  • jQuery前端开发人员（美国方），是临时从另一个项目中调派过来的，负责所有前台的代码，包括jQuery及插件的使用和选择，与BA沟通确定方法接口，负责解决客户端有关的性能问题和BUG修复。初期稳定后，会撤离项目组。
  • C#和数据库（我），负责所有的C#、WCF和数据库相关开发，BUG修复，稳定后的维护工作。

难点：

  • 离岸协作，16小时时差，即美国上班时中国在睡觉，所以基本都是美国方在加班与我进行协作，通常都是他们晚上9~11点，我这儿中午12~1点。
  • 代码交付问题，尤其是前后端的衔接非常紧密，所以若有一方因为代码交付问题，另一方则会完全被stuck住，风险较难控制。
  • 由于使用典型的敏捷迭代，所以时间的要求上其实很急，规定上线时间根本没得商量，如果不能完成只能等下一次迭代。
  • 各种新技术：采用全新jQuery dataTables展现grid，后期使用线上数据库才发现性能完全不行。性能测试不足，出现之前没有预料的问题。
  • 沟通，我这边的老大曾经建议过直接onsite开发，不过美国方没有同意，这个页面因为需要无间的配合，所以对沟通的要求其实很高，我们后期是采用的每日~每两日一次会（会经常持续达半~1个半小时，有几次甚至达到了2小时，包括我和前端讲述头天已完成项，整理BUG完成情况，讲解新发现的BUG，指派新BUG的负责人，列出明日交付计划等等），每天必须使用邮件来更新开发进度并列出明天的计划和交付。倘若交付出问题（也确实出过），整体交付的日期会延迟。
  • 整个过程使用英语沟通。
  • 其它。

整体页面如下:

2011-03-12_183720

我们的协作方式：

  1. 由BA确定需求时，对方技术负责人告知前端与我的技术需求、扩展和重构，
    我之前从来没用过WCF，我需要在这期间做出WCF POC，更新我的auto-complete控件使之支持WCF，
    前端需要了解dataTables等相关技术。
    （耗时一周左右）
  2. 初步需求文档，列出主要web methods，当时一共只有15个，在这段过程中web methods的命名和需求往返超过不下于8次
    前端给出后台需返回的JSON结构及request参数等。
  3. 任务分解。
  4. 前端进行页面代码的初步编写和插件研究；我同步进行数据库设计，后台代码框架等，并做出几个初步的web methods，准确代码合并。
  5. 第一次代码合并是比较痛苦的，因为前端会改我的后台代码，他本身也懂C#，这样我们经常会有代码冲突，于是此时美国的技术接口人提出了协作原则，洋洋洒洒一大篇，即双方不允许互相修改对方代码。我补充说，希望每天有一次进度汇报，包括change log、明日计划、needs等。
  6. 第一次合并后，发现问题很多，比如我写的web method对方不能使用或出错，第二次我就开始做unit testing，每个方法都使用Nunit进行过单元测试，这样大大提高了我每日后台代码的交付质量。
  7. 在开发阶段，每天会有一次这样的报告，发现BUG会及时汇报，每日back and forth不下于5次，好在美国方总在晚上8~11点能联系到（即中国时间早10点~中午1点），所以这期间能clarify很多疑点，总之每天计划都能完成，第二天另一方会收到相应的代码更新。
  8. 开发近一周半后，第一个版本发布到DEV服务器上，初步测试开始，BA生成简单的excel文档记录BUG清单，excel包含2个sheet，一个列出bug，一个列出尚未实现或打算实现的功能。每天会有一次电话会议，来确定这些BUG的负责人，并写上计划完成日期，每日有更新。每日会有一次构建，都会在DEV服务器上发布新版本以供BA测试和检验BUG修复情况。新BUG仍然会有层出。这个BUG清单最后有80来条，各种大大小小包括performance和页面布局问题等。
  9. 第二次成熟版本发布后，对方使用线上数据库（dune版）来做性能测试。性能测试的结果，比如：loading会有timeout的错误，正式发布前都有处理。
  10. 全部的回归测试。
  11. 发布上线。从协作开发到第一版本上线一共耗时一个月整。

关键词：

  • 任务：任务分解、初期需求不必完美、过程控制、任务负责人清楚明确
  • 沟通：每日进度汇报及计划、快速跟进修复BUG、积极响应、频繁会议、清晰沟通、无情绪沟通
  • 测试：单元测试、性能测试、集成测试
  • 交付：严格遵循不修改对方代码、bug tracking、遵行每日计划交付目标、后期每日构建、允许迭代

遇到的技术难点：

  • 上线后，当即发现另一个性能问题，因为使用jQuery datatables我们当时并没有做服务器分页，所有filter和pagination全部客户端，即提交查询请求后，从数据库返回全部数据（比如5000行），形成庞大的json串会导致出现script无法响应强制终止脚本的提示。BA当即只能决定将先只返回800条查询数据，在第二次迭代中再想办法提升。
  • 另一个性能问题就是左侧层级列表，数据量不少，页面载入后，分别有左侧4个及右侧3个widgets的数据需要异步载入，第一次访问页面的速度很慢。使用cache也不能很好解决这个问题，只能将左侧jstree做成服务器端异步提交显示。
  • end-users的反馈很强烈，很多人使用得不习惯，很多抱怨和反馈纷至踏来。
  • 很多东西都必须改，第二次迭代开发开始。

我们开始第二次迭代：

  • 所有存储过程都需要分页，问题比较麻烦，因为存储过程和C#方法有27个之多，如果每个存储过程都必须加上7个参数（startFrom, limit, sortBy, totalCount, Archived totalCount, etc)，每个接口也必须如何加上7个参数，所有方法都需要动。
  • 左侧jstree需要改动。
  • 更多performance tunning。

我们开始第三次迭代：

  • 由于客户端已基本稳定，前端退出开发团队，我继续进行维护工作，并需要了解所有使用到的前端技术和jQuery插件等。客户反应渐好。

总结：

  • 深刻感受到西方的敏捷开发模式和沟通方式，很受启发，很喜欢。
  • 交付质量和承诺至关重要，否则一天的耽搁，可能会引起两到三天的延时，严重者会使进度失控。
  • 一个小遗憾：我做出的WCF其实并没有体现WCF data contract的优势，仍然返回JSON串，可是时间太紧，一直没有去解决这个问题。也是后期想要解决的。

Tags:

Stack exchange上的高投/趣题

March 10th, 2011 by , under 码农日记. No Comments

读书类

编程语言类

灵感类

应用 & daily work类

工具类

有趣的

面试

Tags:

2011.March Links

March 9th, 2011 by , under 码农日记. No Comments

趣读

架构

ASP.NET/数据库（后台）

MVC,  Castle

nHibernate,   StructureMap

团队、Scrumb

jQuery/脚本（前端）

其它（临时）

技术博客

关注图书

各种点滴：

  • 在此文中的评论看到一句“Also keep in mind that the .d is there for a reason. Avoiding unwrapped JSON arrays does legitimately defend against a certain class of cross-site attacks.”原来是这样… 当初总是不明显为何ASMX的JSON返回的总带着.d，原来是为了防止跨站攻击使用未经wrap的JSON串吗…有空研究研究，现在去sleep!
  • 工作中关于每日备份的问题是否有过思考呢？前段时间听闻老大提到system admin/ DBA有每日备份的习惯，倒是真的很想学一学，2年前曾看过一篇DBA注意事项大概是60条，里面有不少都谈到了每日备份和工作项目，还有译过（可惜没找着…）。 what r the daily responsibilities of u as a system administrator

静下心来思索，决定放下所有链接一个月，安静读本书。就读高效开发的那个？

Tags: ,