17studio
- 浏览: 203595 次
- 性别:
- 来自: 广州
-
最新评论
-
gurudk：
有很多好的产品也是集体智慧的结晶，不是带有个人色彩。
谈谈架构师 -
司马崖余：
2、编程提高
a. 基础知识
b. oop和设 ...
关于团队培训 -
司马崖余：
什么时候实施啊？期待中:D
寻求下一个阶段的团队爆发点 -
17studio：
ncache是在请求分发模块做的事情
分布式文件存储方案 -
17studio：
cpu是小事，中心数据做好同步，机器可以横向扩展，关键的扩展点 ...
resin 3.2 comet
文章列表
1. 数据访问冲突同步
2. object之间的通信调度冲突
3. 事件机制和业务处理的规模能力
4. 通信的即时性
5. 大规模连接
相比邮件系统的特点而言
1. 大规模连接
2. IO吞吐量
3. 服务安全性和稳定性
邮件系统其实更接近于类似银行类的业务处理系统
- 2008-10-17 11:59
- 浏览 946
- 评论(0)
erlang目前的问题
1、erlang承诺过它可以无限度扩容，这个明显是骗局，并不是所有系统都需要无限扩容，而且优化上面做得不好，扩容成本高，会和商业打架
2、大多数的底层系统，为了优化针对自己的业务，都需要牺牲对其他特性的支持，越是高层的东西，越受限制，erlang不是底层的东西，c/c++才是
3、面向函数式开发的成本很高很高。。。考虑一下人员招聘、培训、大规模生产等等商业决策对生产工艺的要求吧
回顾目前互联网的项目，也只有im和大规模在线网游，这两个东西，可以用erlang来做吧，但是大规模在线网游，需要持续的业务开发，erlang团队，能应付这样的环境么？
回顾目前erlang成功 ...
- 2008-10-17 11:30
- 浏览 1393
- 评论(0)
1. 应用无状态
2. 非即时
3. 交互通过数据交互完成
这些特点制造了很多开发框架，但是，我们可以知道，当潮流从B/S业务转移离开时，这些框架都会死掉
无休止追求框架和开发效率是没有意义的，追求极致成本高产出低，如果不是战略需要，适可而止
所以，通过提高熟练程度和降低学习成本，把一件事情做好即可，学会在能力和成绩之间取得平衡
- 2008-10-17 11:11
- 浏览 1269
- 评论(0)
1. 关键模块使用高性能方案实施
2. 业务开发插件化,应用化 (参考操作系统,eclipse和facebook的功能扩展)
3. 数据服务、应用服务开放化 (saas)
4. 后台业务越来越倾向于脚本话和数据驱动化 (响应即时，开发周期短)
5. 前端表现力持续增强
- 2008-09-30 22:43
- 浏览 1017
- 评论(0)
许久没有关注技术了
最近在悟市场和产品，对这两者有一个明悟后，才知道技术应该怎么做
作为带着个人思维、个人情绪的作品，软件，它本身就不可避免是一件艺术化的结晶
这样的东西，如果不领会个中灵魂，是做不出好的作品的
换位思考，同样的画，模仿者甚至还更会精雕细刻，为什么只有原作才是精品？
用业内的话来说，hibernate代码也没有多少，还有很多人可以给代码挑刺，为什么Gavin King能成为老大？
架构师，如果不知道如何赋予自己作品灵魂，就是一个失败的架构师
一些简单的问题：
1、每个数据库设计，都需要分布和海量数据吗？
2、单机性能从5k到1w，有意义吗？
3、我们的系统，是应该追 ...
- 2008-09-30 22:38
- 浏览 1115
- 评论(1)
身为技术主管应该考虑的几个问题
- 博客分类：
- 雕刻人生
1. 能不能提供一个稳定的支持，给外面的商务同事
2. 能不能锻造技术的核心竞争力 (成本、效率、核心技术)
3. 能不能根据商业策略持续发展
- 2008-09-23 07:44
- 浏览 903
- 评论(0)
我一直在思考一个问题，我们的团队水平，处于怎样的一个位置？如果我们公司成功了，但是我们整个技术团队，在互联网行业的水平，却处于一般的水平，那么公司的成功，并不代表我们技术部的成功，只是我们运气好，靠着其他部门吃香喝辣。
实际上这样的公司不少，如盛大，盛大的技术人员最终也无法成为公司的核心，也不会被重视。
如果我们希望被别人重视，成为公司的核心，我们还需要付出更多的努力和心血，比较一下google、微软这些靠技术吃饭的公司里面技术人员的水平，我们不得不对自己有更高的要求。
我们必须时刻保持好胜的心和勤奋的态度，像狼一样饥渴，这才是赶超比我们优秀的对手的必备素质。也只有这样，当某天我们站在巨人 ...
- 2008-09-17 14:29
- 浏览 827
- 评论(0)
不求生搬硬套，但求不断提高
2．标准划分— 摘自《使用软件工程》
CMM将软件分为5个等级：
1． 初始级(initial)
工作无序，项目进行过程中常放弃当初的规划
管理无章，缺乏健全的管理制度
开发项目的成效不稳定，产品的性能和质量依赖于个人能力和行为。
2． 可重复级(Repeatable)
管理制度化，建立了基本的管理制度和规程，管理工作有章可循
初步实现标准化，开发工作较好的实施标准
稳定课跟踪，新项目的计划和管理基于过去的实践经验，具有重复以前成功项目的环境和条件
3． 已定义级(Defined)
开发的过程，包括技术工作和管理工作，均已实现标准化， ...
- 2008-09-01 17:18
- 浏览 1924
- 评论(0)
1. 稳定、多点接入 (1 month) 8
a. 质量控制
b. 数据库优化
c. 接入网络优化
2. 分布、高负载 (2 month) 9
a. 关键点质量可靠 (JMS,MYSQL)
b. 业务无单点故障
c. 高负载
3. 高品质、国际化 (3 month) 10
a. 速度 ...
- 2008-07-31 23:53
- 浏览 994
- 评论(0)
我在2001年读微软开发团队相关书籍时（当时还是李开复推荐来自国外的翻译），微软团队中描述了一个成功项目团队中三个主要的管理者：
1、产品经理
2、项目经理
3、技术经理
时至今天，对上述角色的职责有进一步的体会和理解，在此记录
1、产品经理（保证所作的功能是市场需要的，是技术可以实施的）
2、项目经理（保证项目是可以完成的，提高质量，降低成本）
3、技术经理（提供团队技术人员的技能培训和技术支持及管理监督）
上述三者各有所长，职业技能也是差异极大，但是从从业情况来看
1、产品经理（可以是非技术人员，需要对技术有一定了解）
2、项目经理（建议是技术人员出身，但是需要进一步的项目管理技能 ...
- 2008-07-27 21:45
- 浏览 994
- 评论(0)
最近被头投诉，说我跟产品策划走得太近了，有些迷失
我为什么重视甚至参与产品策划？其实原因很简单
1. 缺乏安全感
假如产品策划是一个错误的决定，无论技术做到多优秀，最终的结果还是失败，方向错了，是达不到目的地的
2. 技术实施和产品策划息息相关
当产品策划连如何与技术实施沟通都不懂的时候，作为技术部的主管，我有必要培训我的团队
当项目实施处于求速不是求质的氛围下，上面的想法更是占据了我的主要注意力
真的很危险，人犯错，往往不是因为能力不足，反而是因为把危险习而不见，察而不看
- 2008-07-27 21:30
- 浏览 1208
- 评论(0)
产品策划属于工程学范畴
- 博客分类：
- 雕刻人生
1. 产品策划不属于市场范畴
2. 市场决定定位、目标消费人群
3. 产品策划负责完成市场定位的功能设计
4. 产品策划为了达到功能设计目标，使用了大量的科学手段（统计学、心理学）支持
一个简单的例子：邮件客户端软件（正在萎缩的市场）
市场完成定位，提出争取foxmail的用户
产品策划完成以下内容分析：
1. 为什么foxmail的用户会流失
2. foxmail的用户特点和不满
3. foxmail的功能列表
4. .....
上述可以看出：
1. 产品策划无法影响战略，市场才有因为决策对战略的影响
2. 产品策划和市场决策息息相关，双方有直接交界面
3. 产品策划不是拍脑子工程 ...
- 2008-07-27 21:06
- 浏览 902
- 评论(0)
学project management或operation management时可以看看的网站
http://www.maxwideman.com/papers/index.htm
http://www.projectperfect.com.au/info_agile_programming.php
http://www.agiledon.com/post/2008/07/Scrum-Practice-In-PM.aspx
有空看看曾国藩
学会把压力下放
学会解放自己的时间
把事情做细
对手下要有人情味，对手下要狠一点 （严师才能出高徒）
- 2008-07-24 22:02
- 浏览 752
- 评论(0)
曾经在过去的文章中，谈到团队建设的一些要点，现在进一步补充
1、资源管理 (控制成本, 涉及人员调配和项目任务安排)
2、品质管理 (优秀的产品, 涉及人员沟通和产品理解)
3、质量管理 (稳定的产品, 涉及生产流程和人员培训)
4、进度管理 (涉及前期沟通、工作量评估、进度检查等)
5、风险管理 (降低风险，保证可控程度)
6、效率管理 (优化所用技术，提高人员水平)
以前提到的：项目、技术、产品、人员，没有涉及到目标，只是入手的几个角度，上面的几点可以算是一些考虑的细节点
- 2008-07-24 21:55
- 浏览 1033
- 评论(0)