CSDN 软件开发 2.0 技术会议(1)

毛主席教导我们:要坚持以山寨风格报道技术会议!

好多朋友不喜欢我写流水帐,今天再破例一下。周三下午我们出了机场打车直奔小汤山九华山庄。没想到出租车司机不认识路,走了好一阵子才说自己没来过这地方,我们沿着京承高速一直狂奔,中间我还打电话问了一下朋友,最后看见路标写着”前方一公里牛栏山出口”,大家全晕了。接着往回绕,找到小汤山后又多走了一段冤枉路后总算到了九华山庄。

办理入住的时候发现旁边一高个子长发帅哥, 心说莫不是云风? 一问果然是他,真的巧。三句话不离本行,我办理手续时候听见他们已经开始讨论技术了。云风说他背来一个游戏,热情邀请晚上一起玩。

九华山庄办理入住手续非常雷人,几乎是全国最落后笨蛋低级的业务流程了。在无奈的等了 40 多分钟后,手续终于办完(没想到后面还留下好多麻烦)。

过了一会儿去找云风,凑齐了四个人玩他带来的桌上游戏,Race For The Galaxy(银河竞逐)很复杂,还好云风有足够耐心,听明白了之后开玩,挺有意思,一边玩一边问,就是有点困。好不容易一盘下来,已经过了零点了。休息不表。


4 号下午 1 点会议正式开始。美女开场舞蹈,然后是CSDN 老板蒋涛致辞,主持人依然是韩磊,我在叽歪大屏幕上调侃”站姿标准“,这次叽歪大屏幕只在一侧有,现场也没有大范围提供 Wi-Fi 热点,所以互动性不那么强,相比之下不如上次在上海的好玩。从登高那里得到了现场唯一的无线热点密码,算是抢占了有利地形,除了跑到外面聊天的间隔,一下午基本上算是占领了屏幕,差点惹起民愤。尤其是我调侃” 谷歌的展位太雷人了,没人看着,用户自助服务。莫非Google 有智能监控么?”

开场舞蹈(有些雷):
开场舞蹈
蒋涛发言中(我非常喜欢这张照片,动静相宜):
蒋涛发言过程一瞥
谷歌中国展台空无一人(不知道设置这个展台干啥):
Google 展台空无一人
Jacobson 题为 Be Smart 演讲:
Ivar Jacobson 的 Be Smart 演讲

其实大多数 Keynote 都是类似的,大家各取所需吧。有的主题演讲我没听到,倒是听了一下戴志康的演讲,个人评价还是挺诚恳的。

会场外面雷军在休息,不经意变成了小型座谈,吸引了大量人气,雷老板就是有号召力。

雷军"小型见面会"
最右边的周筠老师。


晚上去听了张银奎老师的《软件调试》的Session,很过瘾。张老师浸淫软件调试多年,三载成书,长达千页,而这次的技术演讲又是经过精心准备,幽默生动,富有激情。是我这次会议上的意外收获。结束后拿到张老师赠书一本,激动。

张银奎老师在演讲中
调试设备与生俱来:
调试设备与生俱来
EOF

SD 2.0 会议感兴趣的几个话题

晚上的飞机去北京。明天参加 CSDN 组织的 SD 2.0 技术会议。会议的话题林林总总,我仔细挑选了几个。相对一些业界名人味同嚼蜡的”宏观技术”演讲,我更喜欢参加在技术一线的技术人的分享,”技术含量” 是衡量技术会议质量的唯一标准。

选几个自己将参加的主题:

云风 — 高性能健壮系统中的内存管理

虽然和云风都在杭州,但是一直没机会见面。他的 Blog 我可是每篇必然精读,很有嚼头,这次在会上希望能得到更多的技术启迪。

程立 — 大规模SOA系统中的分布事务处理

程立是我支付宝的同事,可以负责任的说,他准备的东西很棒,在公司内部也多次交流过分布式事务的经验。”有技术含量”,这不是我一个人的评价,其他人都这么说。

周爱民 — JavaScript + Delphi + ErLang = ?

周爱民的大作 《JAVASCRIPT》在我们公司很受欢迎。不知道他最近在修炼什么。到时候就知道了。

钱宏武 — 如何诊断并且平滑升级大规模互动产品

他和黄冬,我听朋友介绍过多次了。这个话题我也比较感兴趣,希望有所收获。

除了这几位,还有张银奎老师的”感受和思考调试器的威力”,应该绝对有技术含量,但和我的技术领域有点偏差(担心听不懂),有时间还是要去助阵。阿朱的新书应该也能在会议上看到了吧。

因为自己关注领域有限,可不是说其他的演讲都没技术含量。有的技术话题,自己也懂点,而有些时间有冲突的或是同事或朋友,因为交流过,就不重复参加了。

对了,据说 CSDN 在九华山庄斥巨资拉了一条专线,没准儿我在会上来个 现场直播也说不定,请关注我的 Twitter 吧。

EOF

网站运维之道 之知识管理与积累

接上一篇《流程规范》,继续谈谈知识管理与知识积累的相关内容。

所谓”知识管理与知识积累”,其实有点绕,我们不如就说说”运维技术文档”的事儿吧,这样可能还直白一点。因为每次说起类似的话题,总有兄弟用不屑的语气说,不就是写写文档的事儿么?

运维友好的文档

不同的团队对文档要求可能都有不同的”风格”–更多的时候是运维主管要看着舒服。就运维来说,必须能够创建”运维人员友好”的文档。

一般来说,运维文档应该具备如下特点:

  • 易读性 便于阅读,便于技术人员阅读。尤其是内容不应引起歧义、转码等。
  • 可搜索性 针对具体内容便于查找,便于发现。
  • 版本化控制 这里不是普通的 V1.0,V2.0 之类的简单标识版本,而是要能够获取所有的内容改变过程,便于回溯。
  • 通行格式 能够适应不同的操作系统平台。
  • 信息完备性 具备足够丰富的交叉引用,反复保存的时候不会丢失信息等。

可能还有其他特性没在这里一一列出。有的网友看了上面的描述,这不就是 Wiki 嘛! Bingo! 基于 HTML 的 Wiki 页面,绝对是对运维友好的,尤其是网站运维团队。 我见过很多团队用 Word 写文档,这是非常糟糕的事情。在版本化控制、可搜索性方面具备天生缺陷。或许书写运维报告用 Word 是好的选择,但是运维技术文档的积累绝对不能用 Word。

运维友好的 Wiki

你们的运维团队在用 Wiki 么?

一般来说,具备一顶的语言背景可能更喜欢用该语言开发的工具(嗯,我说的是”一般”),有一定 Java 背景的程序员可能会喜欢用 Confluence 之类的 Wiki 工具。而对运维人员来说呢,什么是他们的语言背景? Shell ? No ! Perl/Python/PHP ,一般运维人员可能都熟悉三者之中的东西。

我个人多少喜欢一点 TWiki ,尽管我对 Perl 不那么熟悉。而很多中小 Web 网站,可能是 PHP 为开发语言,搂柴火打兔子,捎带脚让程序员帮着定制一些功能就成了。这是不是有点扯远了? 什么是运维友好的 Wiki 呢? 我的意见是要能促进运维人员技能的 Wiki 软件,比如选用了 TWiki,那么在维护的时候,Perl 背景技能就能派上用场并能进一步促进,多少有点以战养战的意味在里面。

此外,应该强制运维人员提交 Wiki 标记化的文档,而不是简单上传一些 Word 文档、PPT 甚至 HTML 附件。Wiki 编辑器里别直接粘贴从 Word 文档 Copy 来得内容。

如果团队足够大,应该有人专门定期检查文档质量,乃至对新人做一些简单的示例或者培训什么的。写一份好的文档甚至比写一大段好的代码更重要。

知识管理与积累

Wiki 上都记录什么? 最佳实践、技术心得、配置文档、软硬件信息 … 乃至团队人员联系方式,随时记录是需要的,但保持更新更重要。

知识管理(KM, Knowledge Management)是干啥的? 这四个字说来话长,维基百科解释道:

... comprises a range of practices used in an organisation to identify, create, 
represent, distribute and enable adoption of insights and experiences.

用我的土话说,要把信息沉淀下来并传递给更多的人用。一个人写的文档,团队其他的人要能看明白,要理解,要能拿着这文档做事情。没有知识管理意识的团队,成员之间的信息交流或许也有些不顺畅,可能会在人员的使用上存在很多瓶颈,遇到一点技术上的小事情,原来负责的人不在场,其他人可能搞不定,这是风险!

有些团队对待知识管理的态度上是”拿来主义”但缺乏分享精神,比如复制大量网络上的信息到内部,但是不愿意对外分享团队的心得,这样不好!

积累,意味着这是一件长期的事情。不是一窝蜂搞一下就结束不管的。一份运维文档应该贯穿网站建设的始终,逐渐丰富完善。

后记:如果还有兴趣,写写关于《自动化维护》的话题? 要不算了吧。今天这个话题写的有点匆忙,因为不是对媒体供稿,所以行文语气很散,有待于收到反馈后更新吧…

EOF

代招聘 .NET 架构师一名

插播一条广告:帮朋友公司招聘 .NET 架构师一名。尽管是互联网寒冬,还是有的公司准备足了木头、煤来取暖的。

职责:

  • 1. 主要负责公司产品组件设计工作
  • 2. 负责产品开发技术研究及其实现方面的技术分析和架构
  • 3. 负责基于服务的接口定义和方案及其实现规划
  • 4. 带领和带动整个开发团队的技术学习并对编码人员进行指导
  • 5. 全局掌控和执行既定解决方案的实施
  • 6. 关注团队代码质量和规范化

要求:

  • 1. 熟悉面向对象的编程思想
  • 2. 7-10年以上软件行业工作经验(非必须)
  • 3. 计算机相关专业本科及以上学历
  • 4. 具有良好的沟通能力及团队协作能力,工作细致,能承受工作压力,富有责任心
  • 5. 拥有SOA系统的架构和设计能力,并且有实际的工作经验
  • 6. 具有3年以上大型ERP项目开发经验并产于架构工作(非必须)
  • 7. 了解微软主要企业应用技术和服务器:Biztalk,Message Queen(消息队列),Windows UDDI Server等相关技术
  • 8. 对WEB Service 有非常精通,特别要熟悉WCF,WWF等相关技术
  • 9. 注重在后台开发架构,而非页面操作方面的能力
  • 10. 对实现软件设计解偶的设计模式有相当经验
  • 11. 熟练掌握常见的多种设计模式
  • 12. 对系统性能的优化和评估有实际工作经验
  • 13. 有MVC设计方法有实际经验
  • 14. 对多层应用系统开发有3年以上实际经验
  • 15. 了解IOC 和AOP等等技术
  • 16. 有SSO单点认证或者通行证开发经验
  • 17. 拥有多系统集成项目实施经验。

描述的内容还不少。其实就是一个 .NET 架构师该做的事儿,倒也不必强求所有条件都符合(那两个”非必须”的标注是我加的),也别挑刺其中描述是否有过分的地方吧。

工作地点在杭州。

薪酬,年薪 + 期权。感兴趣的话请发简历到 [email protected] .,具体情况和招聘公司详谈,我知道的不比这个页面上描述的内容更多。

EOF