nonocast

Stay Hungry, Stay Foolish.

来源:http://www.dfdaily.com/html/158/2012/12/20/914265.shtml

如果你想改变球队,你就必须问自己,两年以后的球队该是什么样的?然后根据这个想法来改变现在的球队。

全文如下,

赛前演讲:发挥想像力

我曾经听说一位教练这样开始他的赛前演说,“我起码已经和你们说了超过1000次的赛前指导了!”而他的球员们立刻回应道:“没错!1000次中有500次我们都是睡过去的!”其实,赛前演讲大部分的内容都是老生常谈。为了避免这一点,我喜欢利用自己的想像力讲一点不一样的故事。

一般情况下,我会说说我的期望,谈谈球员们的信仰以及信任之类的话题。我记得有一次去看安德烈·波切利(著名盲人歌唱家)的表演。我感觉这是我一生中上过的最经典的课程。我在看演出的时候想到了球员们之间的互相配合和团队协作,一种乐器开始演奏,另一种就悄无声息,这种此起彼伏的感觉棒极了!回去之后,我就把这段经历告诉了我的队员们,让他们明白什么样的球队才是最出色的。

至于安排球队首发阵容,我们从来不会当着全队的面宣布首发是谁,而是直到比赛当天才会公布。如果说比赛是下午3点开始,那我会在下午1点前和球员们单独谈谈,告诉他们我的决定。我一定会私下和他们交流,我知道被排除出球队出场阵容是一件非常痛苦的事。

技战术:抓住对方核心

战术这样的东西实际上是在不停变化的,你要根据不同的对手改变自己的策略。我在布置战术的时候喜欢把注意力集中在对方阵中的1到2名球员身上。我会想对方哪名球员会去主罚任意球?谁是掌控球队节奏的那个人?谁在指挥球队?你只要把握住对方阵中最有影响力的那一个人就成了。

剩下的时间我往往会想想自己球队的打法。比赛前的那个周五,我会和球员们一起通过比赛录像来分析我们的对手,他们的长处和弱点分别在哪里,他们的任意球采取什么样的战术,他们会在场上踢成什么样等等问题。

等到周六的时候,我们会给他们看一份更简明扼要的报告,其实就是昨天内容的一个简单复述。
  
continue reading...

来源: http://www.zhihu.com/question/20737561

我在大学的时候谈了一个女友。

女友总是说我幼稚。
她说她想要一个MP3听歌,给我发了几个淘宝链接问我哪个好。
我告诉她,你等等,我把自己最喜欢的ipod classic 擦干净装上自己心爱的歌,打包快递给她。
她大发雷霆,说你怎么这么不成熟。
我也不知道哪里不成熟了。

她问我今天化妆的好看么
我很认真地看了一会,给她说,其实你化妆不化妆在我眼里都是一样美的。
她生气了,甩了我手就走了,说跟你这种不会说话的小男孩谈恋爱真是气死我了。
我也不知道我怎么就小男生了。

在大街上我看到她就很开心地去牵起她的手。
她把我的手分开,事后很不开心地说,你什么时候能够稳重一点,真正男人都是等着女人挽着她的手的好么,你怎么这么不man。
虽然我记住了,但是下次散步我还是想牵她的手。

有一天我们去开房,我脱衣服的笨手笨脚惹她生气了
她说,你做事能不能麻利清楚一点?脱衣服也要我教你是么,你又不是我孩子!
我一边抱歉一边加快了手上动作,她更生气了,说我做事不温柔不体贴。
我想了想说,我们不弄了,没关系的,你别生气了。

continue reading...

仓鼠革命很薄,135页,这里下载,虽然很薄,不过有料。

COTA

COTA感觉是流程驱动,以客户为中心,具体理解如下,

  • Client, 强调输入(客户),所以我理解Input也是可以的,强调前期沟通和开发过程
  • Output,强调结果,这是组织产出,即资产管理
  • Team,强调规则和管理过程,针对人的管理,组织目标、绩效管理、会议既要、管理措施等等
  • Admin,强调支持辅助,比如公司资质、产品资料、办公室、旅游、财务、预算等等,反正我理解是归不进COT全部都是Admin,嘿嘿

根据COTA可以将结构调整为,

目前依然困扰我的问题包括,

  • 如何设计备份策略,如何构建Month-Package
  • 如何设计Personal结构,PAO感觉还不够好
  • 照片、音乐是否需要放入Personal目录中管理,还是荡在外面

ABC

扩展阅读:

先来看一个负面评价,超自恋,超强迫症,超无聊 (评论: 佐藤可士和的超整理术)

封面的男人照,真的很猥琐的感觉,缩在一角,头发很乱,不像被超整理过,像被超修理过。
  
封面后开场的图片,办公室的很震撼,干净到只能让你想起,这只有强迫症才能做到。最痛苦的是,佐藤可士和要求每个员工都整理自己的桌面,按他的说法,桌面整理不干净,思想就会被牵绊,这完全是无厘头推导,不需要论证,不需要逻辑,纯粹是用自己的经验代替别人的习惯。
  
整本书谈的案例,都怪怪的,他设计的LOGO,我很少共鸣,唯一喜欢的创意,是T恤店面的设计,很突破,这大概是强迫性整理的好处。有些案例,我个人觉得和整理的习惯没有关系。

反正就是感觉佐藤可士和够自恋,然后打死也不想给他的公司合作,因为太强迫症了,没有任何东西的桌面,我不会收敛思想,只会倍感无聊,我还是喜欢google办公室照片给我那自由自在的感觉。

我的理解是,当事情多到一个地步的时候,大脑就会被各种事情塞满,而且各种事情都以抢占的方式占用CPU,这个时候最需要的就是聚焦,8020,番茄,关注力都不断在讲这个道理,所以清空大脑,只保留当前目标。

这时候KASHIWA就一种近乎'强迫症'的方式清空自己的一切,只要最重要的事情放在大脑中,所以整理的不仅仅不是空间更是大脑,时刻保持一个清醒的思考空间,这才是关键。

  • 80/20给出的宏观原则
  • 番茄工作法给出了微观上时间维度的操作规则
  • 佐藤可士和的超整理术给出了空间、信息、思考3个维度的操作规则

记录一下比较重要的点,

  • 创造最佳的办公桌环境,因为唯有保持工作环境清爽,才能提升工作效率
  • 尝试空手,带来出乎意料的解放感
  • 文件或数据只保留最终版本
  • 计算机虚拟空间的原则还是简单至上,档案命名最为重要,
  • 必须要有舍弃的勇气

顺便看看断舍离,动手整理吧。

Git内部结构核心包括index, object, reference 3个部分,其中object包括blob, tree, commit和tag,而最重要的reference包括HEAD, branch。

Object包括Blob, Tree, Commit, Tag 4个实体类型,存储在.git/objects/下,分为松散对象和打包对象。Object文件的结构为deflate(type size\0content)。

Blob的职责是存储单一文件快照,3次修改则生成3个Blob对象,而Tree的职责则是目录快照,通过workspace的文件结构转化为Git内部对象引用,所以一个Tree内部就是多个Blob和Tree的引用,write-tree通过比对index创建新的tree对象,commit-tree则通过tree生成commit。

Blob和Tree已经构成了整个版本控制的核心数据,而commit的职责主要就是负责提交关联的相关信息和轨迹追踪,可以是多parent,表示多头分支合并。通过commit.parent可以构建整个graph。

Annotated tag因为有Tag信息所以被认定为实体存储在objects/下,而simple tag则只是一个指向commit的reference。

commit和branch绝对是整个体系中的关键所在,branch可以理解为chain of commits。而local, remote机制有些隐晦。本地master和远端master可以理解为仅名字相同而完全无关的分支而已,clone时会本地会默认创建master,此master复制origin/master所指向的commit,但后续提交commit完全不会影响origin/master,换句话说,branch是有作用域的,比如origin/master, nonocast/master, local/master也有用namespace来描述这个作用域的,只有当pull/push时根据config中的分支映射才会修改非本地branch的指向。

这个就不用解释了,branch就是一系列的commit,而commit指向tree,tree包含tree和blob,这就是这个逻辑结构了,HEAD中指向当前branch。

Index的职责可以理解为git内部和workspace外部间的桥梁,负责检查文件的CRUD。

我尝试通过CoffeeScript来解析git object和index,整个过程非常曲折,不过确实学到很多东西,可以在github查看其中代码,https://github.com/nonocast/inside-git

参考内容:

WPF在布局体系中首次采用2 pass模式,元素以树的形式进行组织,布局时首先自下而上提交自身期望的所需尺寸,然后再自下而上最终决定自元素的位置和尺寸。刚接触WPF一定骂,搞那么复杂,为什么需要自下而上呢? 有必要吗? 当然这个通过看source code后来才明白其中原委。


昨天在知乎看到帖子,
谷歌(Google)内部考核制度 OKR 是怎样的?

其中袁梦溪整理Rich Klau的回复如下,

演讲主要内容:什么是OKRs,在谷歌我们是如何实践它的,及如何把它运用到自己的公司。

历史故事:在 Google 未满一周岁时,作为投资人之一的 John Doerr 提出了一套称作 OKRs 的组织测评系统。它最初来自 Intel,为公司、团队、个人量身定制。

在Steven Levy的叙述谷歌发展初期故事的《in the plex》中提到OKRs几个重要的点:

  1. OKRs要是可量化的(时间&数量),比如不能说“使gmail达到成功”而是“在9月上线gmail并在11月有100万用户”
  2. 目标要是有野心的,有一些挑战的,有些让你不舒服的。一般来说,1为总分的评分,达到0.6-0.7是较好的了,这样你才会不断为你的目标而奋斗,而不会出现期限不到就完成目标的情况。
  3. 每个人的OKRs在全公司都是公开透明的。比如每个人的介绍页里面就放着他们的OKRs的记录,包括内容和评分(等会会讲到如何评分)

John doerr关于OKRs实施的一个例子:

O:为OKRs组织测评系统建立一个可实施的模型

KRs:

  1. 按时完成介绍OKR的presentation
  2. 完成一个三个月的OKRs的案例
  3. 让管理部门同意并制定一个3个月的测试机制

为什么用OKRs,好处是?

  1. 促使我们思考,主要目标会随之浮现;
  2. 沟通会更顺畅,让每个人都知道什么是最重要的;
  3. 能找到一个衡量过程的指标
  4. 能让我们集中地为某件事而努力。

尤其是刚刚起步的公司,有很多事情挤在一块,必须要找出优先级

其中第2点沟通上的帮助有个例子:Klau 曾经负责为 YouTube 建立主页。他的同事一度希望通过在http://YouTube.com 上传视频,来推广产品。他们先是查看了 Klau 的 OKRs,看是否与他们的想法有契合点,再决定是否提出主页上推广的想法,或者争取打动他,将这一想法加入到下一季的新 OKRs 里。

实施的关键流程:从上至下,目标的设立顺序应该是公司到部门到组到个人。

个人自己想做什么,和管理者想他做什么一般来说是不会完全相同的。那他可以通过先查阅上层的目标,在自己想做的事情范围内找到能对公司目标有利的部分,将他拿出来和自己的管理者进行讨论,做权衡取舍。某种情况下,很有可能这个自己想做的东西,会变成公司今后改变的发展方向。(比如gmail的例子)

沟通的问题:

分两种方式。

  1. 一对一的交流,即个人和他的管理者沟通。尤其是在一季度结束,另一季度开始时,要协商好关键结果是什么。因为不仅个人能说明自己想做什么,也是上面表达他想要你做什么,最好的情况是两者得到结合。
  2. 全公司的meeting,以team的形式进行,各team的learder参加并介绍自己组的OKRs,最终大家一起打分评估。

一些基本的要求:

  1. 最多5个O,每个O最多4个KRs。
  2. 百分之六十的O最初来源于底层。下面的人的声音应该被听到,这样大家工作会更有动力。
  3. 所有人都必须协同,不能出现任何命令形式。
  4. 一页写完最好,两页是最大限值了。
  5. OKRs并不是绩效评估的工具。对个人来说,它起到很好的回顾作用。能快速明了地让自己看到我做了什么,成绩是怎么样。
  6. 分数0.6-0.7是不错的表现,因此0.6-0.7将是你的目标。如果分数低于0.4,你就该思考,那个项目究竟是不是应该继续进行下去。要注意,0.4以下并不意味着失败,而是明确什么东西不重要及发现问题的方式。分数永远不是最重要的,除了是作为一个直接的引导作用。
  7. 只有在KRs仍然很重要的情况下,才持续为它而努力。
  8. 有个联合会组织来保证每个人都朝同样的目标行进。(事实上OKRs实施过程中,你能够获得大家的认可和帮助,这是很有趣的事情)

OKRs的关键:

  1. 每个季度和年度都有OKRs,并保持这样一个节奏的。年度的OKRs不是一下就敲定了的。比如你在12月设了下季度和年度的OKRs,往后集中精力在实施季度OKRs上,毕竟这是眼前的目标。而过了一段时间,你可以验证年度OKRs是不是正确的,并不断修订它。年度的OKRs是指导性的,并不是约束。
  2. 可量化的
  3. 个人、组、公司层面上均有
  4. 全公司公开
  5. 每个季度都打分

continue reading...

在Windows上以service运行Node貌似有以下几种方法,

iisnode

iisnode通过IIS Handler的形式连接IIS和Node,可以说这个方式我个人认为是最简单容易理解的,缺点是额外附送了IIS的复杂度,这个是后话。

tjanczuk/iisnode指导下,基本上5分钟就能搞定,以我机器(Windows 8+IIS 8)为例,

  • 确认已安装node,并将node.exe放入%PATH%
  • 确认已安装IIS和URL Rewrite 2
  • 下载iisnode并安装
  • 进入iisnode安装目录,右键以管理员运行setupsamples.bat
  • Win+X以管理员身份打开命令行,运行%windir%\system32\inetsrv\appcmd unlock config -section:system.webServer/handlers,目的是下级web.config可以修改handler section,否则无法使用iisnode handler

访问http://localhost/node就可以浏览iisnode所提供的samples。

来看hello world,
npm install esp, 然后vi app.coffee

esp = require 'esp'
esp.route ->
	@get '/', -> @html "<h1>hello world</h1>"
	@get '/api/x', -> @html "<h1>/api/x</h1>"
	@get '/api/y', -> @html "<h1>/api/y</h1>"

esp.run process.env.PORT

continue reading...

Grunt是一个构建工具(Build Tool),从功能上来说大致等同于Make, Cake, Rake, Jake, Ant, Maven。

意图

  • 基于Node实现跨平台,Make只能支撑*uix
  • 从外部DSL转移至内部DSL,尤其是配合CoffeeScript
  • 开放的插件体系,建立良好生态环境 (grunt-contrib开头表示官方维护的插件,目前数量已经超过2500)

Grunt赢在插件体系,这点和Node很像,感觉很简单,而插件让你欲罢不能。

起步

来看hello world,
npm install -g grunt-cli
grunt-cli只是一个引导,在任意目录下找到最近的grunt实体,require进来后run,因为可能不同pkg会采用不同版本的grunt,所以不推荐-g install grunt。

新建一个project(test),
mkdir test && cd $_
npm init
一路回车,生成package.json
npm install grunt --save-dev
安装grunt到test/node_modules目录下,同时记录到package.json中devDependenices下,

{
  "name": "test",
  "version": "0.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "grunt": "~0.4.4"
  }
}

vi Gruntfile.coffee

module.exports = (grunt) ->
  grunt.registerTask 'default', (arg) ->
    grunt.log.write('hello world...').ok

continue reading...

Git Blob Object的文件格式如下,
zlib.deflate( blob + <space> + <ascii decimal size> + + <binary object data>)
假设有文件hello, echo 'hello world' > hello
那么Git保存后应该是zlib.deflate(blob 11\0hello world)

Stream + CoffeeScript

#! /usr/bin/env coffee
fs = require 'fs'
zlib = require 'zlib'

class BlobWrapper extends require('stream').Transform
  constructor: (@filename) ->
    super()
    p = "blob #{fs.statSync(@filename).size}"
    @header = new Buffer p.length + 1
    @header.fill 0x00
    @header.write p

  @::_transform = (chunk, encoding, done) ->
    if @header
      chunk = @write_header chunk
      delete header

    done null, chunk

  write_header: (chunk) ->
    chunk = Buffer.concat [@header, chunk], @header.length + chunk.length

filename = 'hello'

fs.createReadStream(filename)
  .pipe new BlobWrapper(filename)
  .pipe zlib.createDeflate()
  .pipe fs.createWriteStream(filename+'.z')
  .on 'finish', -> console.log 'done'

ok, 来看读取header,

#! /usr/bin/env coffee
async = require 'async'
_ = require 'lodash'
fs = require 'fs'
zlib = require 'zlib'

# usage
# ./reader.coffee <file1> <file2> <file3>
# find .git/objects -type f | xargs ./reader.coffee
# cat <file> | ./reader.coffee

option = highWaterMark: 1024
argv = process.argv.slice 2
if argv.length > 0
  sources = (fs.createReadStream argv[i], option for i in [0..argv.length-1])
else
  sources = [ process.stdin ]

async.each sources,
  (source, callback) ->
    source.on 'error', (err) -> callback err
    source.pipe zlib.createInflate()
      .on 'readable', ->
        source.unpipe()
        chunk = @read()
        return unless chunk?

        sp = _.findIndex chunk, (x) -> x is 0x00

        return unless sp?
        header = new Buffer sp
        header.fill 0x00
        chunk.copy header, 0, 0, sp
        console.log source.path if source.path?
        console.log '  ' + header.toString()
        callback null
    (err) -> if err? then console.log err else console.log '-- done --'

运行得到,

➜  test git:(master) ✗ ./reader.coffee hello.z
hello.z
  blob 12
-- done --
➜  test git:(master) ✗ cat rfc2612.z | ./reader.coffee
  blob 37468
-- done --
➜  test git:(master) ✗ find .git/objects -type f | xargs ./reader.coffee
.git/objects/3b/18e512dba79e4c8300dd08aeb37f8e728b8dad
  blob 12
.git/objects/90/4bd2e3f6b83420f20130aa5055edfbacc9454d
  blob 37468
.git/objects/cd/9038b116d0907572340d29203f3e2a21c30974
  tree 68
.git/objects/fe/284e81747fc14d569b0456df315f74c993eee5
  commit 166
-- done --

上述代码着重通过stream控制内存,包括pipe和transform,至于如何进一步解析git object我们放在后面,enjoy!


Powered by WordPress © 2014 nonocast   沪ICP备09095148号 Design by SRS Solutions