三月开始重开公众号

从2017年下半年停止更新的微信公众号,又重新拿起来,经过一番思考,准备。找到自己合适的领域,专注于互联网,或者说专注于回忆互联网往事。不知不觉,1996年到上海电信去开通互联网账号,14.4k 的 modem,平均1-2k 的网速,看到了外面的世界,现在10M 的速度,有时候还嫌慢。从笨重的显示器、笨重的机箱,到如今薄薄的智能手机、4G 。时代进步的太快,我们是幸运的,目睹这一切。所以留一些问题和回忆。

“互联网的温度”

2019 春节将至

今年春节不早不晚,2018年跌宕起伏,圆了一些梦想,也是很多煎熬。

互联网金融的热潮终于过去,经历了最风光的大约 2015 2016 2017 三年,P2P 整个行业几乎一蹶不起。还好,公司始终居安思危,使得我们依然在支付、金融、科技等方面前行,而上市实在不容易,拉开了和竞争对手的差距。只是,前路依然不容易。诚惶诚恐者生存。

明天是春节前最后一个上班日,今天还是有一般的同事在,有些组到今天还有不少项目在开发,很辛苦。

2018年下半年开始,所谓互联网寒冬,而我真的觉得其实无所谓寒冬,或者任何时候都要做好过冬的准备。

新春快乐!大家快乐!

重新打理了一下本站

wordpress 5.0.2 的变化太大了,特别是在编辑文章方面,还不是太适应,但是已经感觉功能只强大。

今天1月1日,本来还是给自己排了一些例行工作,突然想稍微放松一下,让大脑休息一天,换点事情做做。

wordpress 的主题很久没有更换了,换一下,做了两张照片,点缀一下。

生活需要有点仪式感。年纪大了, 一些道理想的通透了。

年少的时候,说人生苦短,为赋新词强说愁。现在真的感觉,要抓紧每一天,时间的流逝,实在超过我的预期。

今年,女儿发给我的新年祝福中说:不要让自己太辛苦哦!

明年看来要多赚点钱,多旅行,再写点东西,做自己喜欢的事情!

Lazarus 1.8.0 发布

基于 freepascal 3.0.4 的 Lazarus 1.8.0 在12月初发布了。比较了 Delphi 之后的 GUI 开发工具,特别是在用 Python 的时候,也很不死心的想看看怎么样用 Python 来开发桌面应用,不管是基于 Qt,或者 Python 自带的 Tk,都一般吧。或许 Delphi 曾经太强大,已经超过了同时代的所有产品。VB 我已经要二十年不使用了,不知道如何,dotnet 架构现在应该也可以运行在 OSX 下了。

虽然 gdb 的安装还是很奔溃,Borland 当年的 Turbo C 2.0 横空问世现在想想是一件很恐怖的事情,在差不多20年前的电脑上,Delphi 可以几乎几秒就完成一个程序的编译。如果没有 IDE 的话,我们要耗费多少时间在安装、配置以及每次冗长的编译过程。其实 Delphi 还是占据了当前开发市场不小的份额,不过,太贵了。

偶尔如果需要写一些跨平台的小工具,那么 Lazarus 或许是不错的选择,Lazarus 的风格还是像一个增强版的 Delphi 7,不过也的确够用了。

最关键还是配合 Lazarus 和 FreePascal 背后的这些程序员、项目组织者,很不容易,坚持这么多年,逐步完善。

迁移“创意纪”的 blog 到这里

创意纪这个 blog,域名用了很多年,写了很多年。中间有一次从 mediatemple 迁移的时候,没有做好,2013年从头开始写了一些。陪伴我度过了生命中一段艰难的岁月。

不想维护太多blog,明日会目前使用了一段时间,还是国内的访问速度稳定。

准备用 wordpress 的 export 和 import 功能迁移一下数据,至少文字都能记录下来就好。

2017.8.21 由微信部分功能故障所想

像微信这样的程序以及背后的架构,是非常复杂,也非常牛 x 的,春节这么发红包都不会弄垮它。可惜,只要是人写的系统,总是会有意外发生。下午,有同事说微信不能转账了,后来看到新闻说下午微信部分功能不能使用,包括支付、公众号、分享等。下午四点十分左右,据说所有功能恢复。

作为信息中心的一员,每次遇到故障总是最令人揪心的,这也是最近几个月工作强度非常大的原因之一,为了让系统稳定健壮。

现在想起来,技术发展的空间的确还很大,服务器、数据库等技术这些年已经经历了几百倍甚至更多的性能的增加,而系统的复杂度也是大大增加了,记得以前 CS 架构、三层架构,基本就可以解决问题了。现在我们研究的是 micro service、serviceless、灰度、内存数据库、流式计算等等。有趣而烧脑。

重回明日会

很多年前申请的域名,一直没有好好用。借着测试公有云的机会,把域名从国外指向回了国内,经历了备案等一系列的事情,终于开张了。

还是关注自己喜欢的事情比较好,不知不觉,当年看着电视,学着 basic ,好像还是昨天。

忙碌的炎夏

这一个月,又是忙忙碌碌,一般来说半年前后和年底前总是最忙的,各类业绩充指标,各类项目告一段落,开始下一个里程碑。

没想到,大数据和机器学习发展的这么快,虽然不懂的东西很多,但是赶上了这个时间点,还是很高兴,公司这两年缓了过来,飞速的发展,真是不容易。

减肥第一阶段基本成功,瘦了十斤,不过同样有一个月左右徘徊不前了,天气又很热,走不动,也不太愿意锻炼,哈哈。

以前觉得这样忙忙碌碌有点不知道目的地在哪里,所谓瞎忙,现在感觉,每个人的努力虽然有限,但是合在一起还是巨大的能量,真的可以改变一些东西。甚至改变世界。

 

春夏秋冬又一春

最近更新很少,主要是网站打开一直有点问题,也一直在纠结要不要迁移回mediatemple,不过后者看来也不怎么样,至少官网打开都有问题。

也可能是平时大多数时间在公司打开的关系,公司访问国外服务器网站是很有问题。

想来不能懒惰,不找理由,今天测试了一下,网站打开速度还是可以的,那么要继续梦想和情怀了。

每年五月,这位朋友会回到上海,这个我们曾经一起学习工作过,愤懑过,惆怅过,醉过,哭过的地方。

的确不是那么多美好的记忆,但又怎么样呢。

今朝有酒今朝醉,千金散尽还复来。

我从前遵循的很多所谓规矩,如今回头看看,很多只是一种禁锢以及逃避的理由。泰山崩于面前而不慌,多好。其他的,又怎么样呢。

以前无法理解国外一些人,怎么可以拼命工作拼命玩,原来这才是生活。

所以说,离别是为了更好的相聚。对朋友来说,如此,对自己来说,也是如此。

敏捷开发之四:主要流程

敏捷开发的目的是为了快速交付,通过精细化的项目管理来保证质量和开发的平衡。一个利用敏捷开发方式进行的项目多半是具有持续性的。 我们经过很多项目的实践的敏捷开发项目的大致流程如下,对于团队搭建、场地准备等先不多说了,这些最好另有专人在立项后决定用敏捷的时候就都准备好,防止后面的忙乱:

  1. 需求讨论。发起人是提出需求的BD、产品经理、研发团队的项目经理和主要的参与人员,包括UED、测试、QA和敏捷顾问(Scrum Master)。在时间资源允许的情况下,尽量早参加产品需求的各类讨论总有益处。需求讨论需要明确这次产品大约做什么功能,大致划分几个阶段。难点是需求和开发在时间上要取得共识。开发时间在敏捷中可以理解为固定的2-3周(一个Sprint),那么这2-3周的产出到底是多少,需要协商讨论。很多时候需求讨论都需要2-3次会议才能完成。需求讨论会议的重要性在于定好一个大的基调,甚至包括是否用敏捷开发方式。开会虽然也耗费资源,但是比起到了开发阶段推倒重来还是划算的太多了。需求讨论之后,产品需求文档、原型图等都要准备好了。
  2. Scrum周期。敏捷开发和瀑布开发在时间控制上不是循序渐进,而是平行开展的。在一个Scrum周期中,得到了确认了的产品需求文档和原型图等资料,就开始进行User Story分拆、UED页面设计、技术方案设计、测试用例编写等工作。因为基于Feature的最小颗粒度,所以分拆和执行的同步不会有太多问题。项目经理现在开始要成为主导,还有敏捷顾问。项目经理负责整个Scrum周期中每个Sprint的细化,敏捷顾问要从方法论上给予指导以及根据实际情况的微调。
  3. Sprint周期。Scrum中有若干个Sprint,在一个Sprint周期中,包括User Story拆分、UED设计、技术开发、单元测试、代码评审、功能测试、测试案例测试、生产测试、用户手册编写、质量评审、上线评审等环节,不一定都要,视情况而定,当然最基本的开发、测试、生产验收、QA、上线是不可能少的。
  4. 每天周期。每天的流程里面,站会(Stand up)是不可缺少的。对于认领任务在目前大部分的项目中都不太具有操作性,因为任务还是研发、测试等经理来派分的,效率还高一些。如果有晚上加班的,建议下午5点左右再开一次站会,避免问题累计。站会的细节之后另外详细叙述。项目经理白天要做大量的审核检查,对于分析、开发中、测试、完成等四个阶段的Issue查看细节,和上游需求提出方保持沟通,为第二天、当前Sprint、下一个Sprint等做各类前期工作。
  5. Issue的生命周期。一个Issue基本上会在四个阶段流转,每个Issue在不同的阶段属于不同的拥有人。测试岗位会产生新的Issue,通常我们称为Defect和Bug,这些Issues中如果是Defect,则会讨论一下是否在当前Sprint修改,Bug的话一般都是要在当前Sprint中解决。这就是为什么看一个Sprint的完成曲线,会在项目中后期进度发生回退的原因之一,因为新开出来不少Defect和Bug的缘故。需求方、产品经理、测试都会在项目过程中给到一些建议,敏捷开发是灵活的,因此对于这些建议是否被采纳,需要根据实际情况讨论,至少可以作为之后Sprint的基础,我们有时候称之为需求池。我是建议需求池中的Issue也先建立到系统中,这样产品经理可以直观的从数量和内容上有控制,敏捷开发中要旨之一就是可以不断迭代,而迭代的源泉这样逐渐出现会比集中完成要更接近实际。技术开发的重构不在上面说的行列,因为技术开发重构优化是为了适应未来需求的变化或者提高处理效率等,不是几个Issue可以解决的。
  6. Sprint和Scrum小结会。在这两个阶段结束,特别是Sprint上线或者发布之后,要开一个全体参加的小结会,时间不用长,半小时就可以了。要超过半小时的话,说明平时沟通有很大问题了。这个小结会是为了反映一些系统性的问题。对于Scrum来说,效率很重要,凡是影响效率的都是问题。在不同的Sprint周期,项目重点会不一样,之后还会说,Sprint完成也不一定是上线看得到,同时Sprint的beta测试等之间还是有一定关系的,一些系统性的问题不解决的,至少会被带到下一个阶段,甚至会被放大。所以小结会上要列出问题并且解决,除了BD、产品经理、项目经理、敏捷顾问等以外,有更高级别的主管参加是有益处的。