http://blog.laiyonghao.com/2010/01/programming-tech-party/442参加了珠三角技术沙龙第五期,交作业,写篇 blog 分享之。:-)
------------------- ktrac ------------------听了社区大妈(Zoom.Quiet)在金山推行 ktrac 的介绍,深有感触。
http://py.kingsoft.net/http://trac-hacks.org/wiki/KTRACZoom.Quiet所在组,作为独立的“过程改进组”,给公司其他部门/小组统一提供 ktrac 服务。
我问了几个问题,列之。
1. 文档无法在 ktrac 上管理,为啥?(我们公司策划直接使用 svn,固有此一问)
答:产品同学未必会用或喜欢用 svn,所以产品同学还在用其他的、针对文档的管理系统。
2. ktrac 整体运用到大部分部门,花费了多少部署、学习时间?
答:最开始花了3个月,让好几个组用起来。然后其他组期望用的,再给他们开服务。
3. "过程改进组"一共有多少同事?(了解整个 ktrac 支持部门的运作成本)
答:11人。但 ktrac 所有仓库运维护、trac 插件编写,就一人负责。
4. 哪些组在使用 ktrac?(个人经验,非技术组用这个东西,学习成本有点高,比如给美术使用)
答:基本都是技术/开发组在用。
5. trac 是否支持权限管理?(trac 貌似很开放,支持某些成员只允许访问某些内容么?- -! 这个问题有点傻)
答:当然支持。
好像还有一两个问题来的,- -# 忘记了。
个人理解,使用 trac,是要求部门有现成的流程,而trac 只是把所有办公自动化了(OA?),而且 trac 可以通过 url link 跨仓库访问,方便整合不同部门的流程。对于无法简单用 trac 解决的,则需要为其专门开发(基于 trac 的二次开发)。
选用 trac,因为社区比较大,用的人比较多,而且 python 好学好用功能强大。关键在于公司层面上成立专门的小组来维护,并支持其推广。:-) 呵呵,我也想尝试推广下 trac 了。
------------------ RESTful RoR ------------------
小伍同学的 RESTful 演讲。
我对 web 方面不甚了解,RESTful 基本理解为更遵循 HTTP 标准,同时美化了 url 的方法。
其实重点都是在讨论 api 的设计问题(我觉得 url mapping 及分派到具体的处理函数,也就是 api 设计),如何保此设计的简洁,不要过度设计等等。:-) 这在所有开发上,基本原理都是互通的。Just KISS!
评论