手机浏览 RSS 2.0 订阅 膘叔的简单人生 , 腾讯云RDS购买 | 超便宜的Vultr , 注册 | 登陆
浏览模式: 标准 | 列表2010年08月7日的文章

ThinkInLamp聚会记录

说起来,上次参加聚会到现在已经过去两个月时间了,ThinkInLamp聚会是每个月的第一周的周末举办,这是我第二次参加,在安居客公司的会议室里。
与会者嘛,还是安居客的开发占了大部分,毕竟天时地利人和啊。确实,如果有这样的聚会放在公司里,一来可以让单位的开发人员进行学习二来也可以了解认识一下其他开发人员,对于公司来说几乎没有任何投入成本,但所获颇多(毕竟真要请人来培训花的钱更多。。)
这次聚会其实就三个内容,一团队,二求职,三敏捷开发
从上个月的聚会开发stingchen就开始有他的分享了,可惜7月份无缘参加,(那次还有逍遥冰心讲的领域驱动方面的内容,也没有听到。惋惜,所以这次我怎么样也得来了。)sting介绍了团队建设方面的一些要点,以及注意事情,引起了很多人的共鸣,看来很多人在工作中遇到过类似问题啊(看来领导们很多)
板子介绍的是不要让工作外的事情来影响工作。总结起来就是有一颗平常心,不以物喜不以已悲,了解自己的真实想法做下去,不要频繁跳槽。
最后的敏捷开发就是讲的如何让工作变得更有效率。在讲之前做了一个游戏,每组8个人,每组中又有不同的分工,一个客户,一个客户老板,三个经理,每个经理下面有一个工人。然后分组开始数硬币(当然是有一定的规则)。客户将硬币交给工人时,客户与客户老板同时开始计时,当第一个工人开始翻硬币时,对应的经理开始计时。当第一个工作完成任务后,把硬币交给第二个工人时,第二个工人对应的经理开始计时。当第一个工人全部把硬币给了第二个工人时,第一个工人对应的经理停止计时。客户在收到第三个工人第一枚硬币时结束计时。当最后一枚硬币到达客户手里时,客户经理停止计时。然后做了五次不同方式的游戏,比如从左手到右手再到两只手一起,等等。DannelTeng的意思就是想让我们把工作能够细分,而且并不是在细分全部结束后再下达任务,这样的工作效率会有提高。
突然想起几件事,一小时学的语文课文里有个统筹方法,好象与此类似。还有就是在夜大学习的工商管理中的管理学,都有涉及类似方面。工厂运作本来就与程序开发有类似之处,毕竟理论是一样的,只是在实现的方法中有不同的方式而已,就如那句:戏法人人会变,手法各有不同。当然,如果没有经过培训过的人,可能在工作过程中也会摸索出类似的方式,但如果经过事先培训,岂不是会更加增加工作效率 ?

最后再做一个广告,锅巴哥哥准备在10月份左右举办一次数据库的专题会,他说到时候会请一些数据库方面的专家来与大家分享和讨论数据库设计方面的事情。也坦言在PHP开发中,其实DBA处于一个很尴尬的地位,即DBA在开发中几乎是没有介入开发中的机会,往往数据库的设计都是由开发人员自行设计,这导致在遇到问题时无法进行调优。而这次分享会上,就是请不同行业的专家们来分享如何更好的设计数据库,以及一些调优方法 。
顺便,锅巴哥哥说的原来从最初设计MYSQL时就是为了电信级的应用。我承认我真不了解这个背景,我想,恐怕80%的PHP开发者不了解MYSQL设计的背景吧。了解的最多的恐怕就是开源、免费。想着MYSQL被我们用成这样,不知道那些数据库设计人员是否会很郁闷。
估计,下一周就会有今天分享的PPT和视频出现在thinkinlamp官方网站了。你也可以到官网查看往期的分享(官网:www.thinkinlamp.com)。

Tags: lamp, 聚会, 分享

知道分子:这个版本太新了

知道分子的这个事例事实也经常遇到过。只是谁都没有提出来当成一回事
在自己的机器上,各种不同版本的PHP一直存在着,或许,相对稳定的也就apache和mysql吧?每次要升级前都看着changelog,但即使这样,也会有或多或少的问题发生,然而,在公司的版本库里,测试机里等等中早就存在着不同版本的PHP,只是可能从来就没有注意过罢了。

升还是不升这是个问题,但如果真的版本不对了,出现的问题也就稀奇古怪了,所以,保证版本号一致还是有着非常重要的作用(如果为了新特性需要升级,那就通知所有的人一起升,最终仅保留一台两台有明显记号的,旧版本的服务器专门用来调试,开发人员有虚拟机的也通通升级到统一的版本号里,一切为了稳定 )

下面是知识分子的内容:这个版本太新了

以前偶尔听到同事 A 问同事 B,某软件出新版本了,我们要不要升级?同事 B 果断地回答,这个版本太新了,我们还是别急着升级吧。同事 A 深以为然,刚出来的版本就升级,万一出个故障谁负责?何况现在这个软件跑得好好的,没事最好别折腾。后来 A、B 两人都忘了这件事,也就没有了下文。

 
再后来,同事 C 在另一处需要用到该软件,去官方网站上下载了“最新稳定版”(也就是前面那个“太新了”的版本),用着没问题。又过了一段时间,这个软件又出新版本,同事 D 问同事 E,我们要不要升级?同事 E 说,这个版本太新了,你懂的。于是同事 D 拈花微笑,信受奉行。
 
如此循环往复,同样一个软件,在开发/测试/生产环境里运行着无数个“太新了”的不同版本。
 
先不谈管理成本,“这个版本太新了”是否构成不升级的理由,颇值得解析一番。为什么要出新版本?不外乎安全漏洞 修补、bug 修正、新功能三者(或混合)。安全漏洞显然是要尽早尽快修补的,明知有安全漏洞而不及时修补,无异于后门洞开等待爆菊,有受虐倾向。整体或所调用部分相关 的 bug 也是要修补的,紧急程度视 bug 可能造成的损失大小而定。新功能则要看未来是否会用到,才决定要不要升级。
 
“这个版本太新了”之所以被接受,其中也有一定的合理成分。“太新了”指的是新版本没有经过完整的兼容性、稳定性和性能测试,也许会对现有应用造成影响。这个意思永远是对的,或者不客气地说,就是一句废话。任何一个新版本软件都一样,不去做测试你怎么知道有没有影响?
 
同一个软件,不同的版本,随意分布在多个环境中,这无疑增加了管理的复杂度,当然也有人认为,这体现了“个性 化”。复杂度也好,“个性化”也罢,都是效率的大敌。标准化的高效运维,应该是同一个软件、同一个版本,并且有统一机制进行追踪、测试、升级,保证安全漏 洞、bug 得到及时修补,新功能尽在掌握。

Tags: 版本