拿 python 做分布式和高并发的服务端?
很赞的构思~
不过工具傻瓜一键安装,我只信 bitnami
软广比硬广要容易生存的多了,哈哈
飞蛾这个玩意做的还不错,看起来比较清爽
大佬,我错了,我没描述清楚,我是想表达建索引的字段顺序……并不是来 diss 你,纯探讨而已,截图也是用来表明如果不是你们的提示我也没有认真去查清楚个中究竟……
以后你的帖子我一概不回了便是,免得被帽子压死~
1、5.7 前两天刚验证过,顺序是有影响的,导引列的重要性一直在被强调
3、in 是可以走索引,但是相比 exists 和少量 key 的 union,可以推荐放弃用 in
4、我一直理解 =、>=、<=存在会走索引,但是纯粹的> < !=是不行的,刚查了一下跟数据分布是有关系的,感觉 mysql 越来越像 oracle 了,统计信息在执行计划里面起的作用会越来越多
另外,除此之外,还有个隐式转换最坑爹了,估计基本所有关系数据库通杀吧~
QC 重在客户端和不能跨平台,但是其设计理念是最完善的
推荐书名:《浪潮之巅》、《人月神话》
推荐理由:没读过其他书,只看过这两本
推荐人群:除非你不做 IT,否则都要看一下,认清楚这里头运作的本质~
技术在你眼里也就是一些 coding skills 了吧
可以吐槽啊,我也觉得不好用,很多人都觉得不好用,主要原因如下:
所以讲一下我的思路:
我看重质效大于能效,因为质、效是一个制衡关系,找平衡点才是终极目标,一味追求效,只是某些厂子的行为,成熟企业大多不会接受的。
我自用,后面也会部分开源……跟你们这群奸商不一样,唱起来:我们不一样
消息系统才会用到 websocket,启动构建只需要 call jenkins 的 restapi 即可,只不过系统里多一些硬配置
至于 sonar 等,都是独立的 server,集成只跟 CI 平台(jenkins)集成,研发管理只需要给出配置和指令,否则耦合太多了
还有精准测试、web、app、接口、性能等测试平台接入集成吧
研发管理部、建生总临走前搞的……神兵嘛,我鸡道的
我照着 DPM 做的……现在你们是谁负责这个产品?gaoning 还是 licuifang~
木有木有,我只是仰慕一下蚂蚁高 P 的新工具,那架势要跟阿里云效一较高下
跟 jira 和 tuleap、testlink、redmine、qc 在某些方面都有点小相似
我听以前的一个小 MM 说,蚂蚁招了个曾在 MS 干掉质量部门的 P10 过去,搞了一套新的能效工具,很牛逼啊
业务测试、测试开发、产品开发,没有哪个心不累的,要想心不累,只有混日子捣糨糊了
这三个里面业务测试估计是心最累的,产品开发其次,因为都需要面对产品狗或者用户……
赞一个,不过有一条不是很能同意:
高昂的学习成本,这么复杂的脚本代码我还搞什么工具推广,工具面对的是小白怎么办
性能测试要做好,所需要的技能可能比安全测试还要宽、深(可能有些维度上深度会差异较大),这点学习成本,就不用给做性能测试的工程师们省了
平台的好处就是海纳百川,搜集足够多的信息,也能够灵活快速支持分布式压测,这都是很赞的~另外,如果从测试配置和执行、监控结果中挖掘一些基础的分析和调优建议倒是个不错的思路
那建议你还是坚持要求转业务测试吧,虽然会保持跟你做开发一样的 “压力大,太辛苦”,但是这样从业务测试转测试开发还可以体会到涨薪的快感
除了查 help 文档慢慢啃还有啥好办法吗
我觉得不知所措的都是没耐心仔细去上手去琢磨的,想着一步成为大神呢吧
今夜,我们都是文化人
同意,翻身做主人也是可以的,但是鸡汤有云:主人要有主人的态度,无论锅是谁的,自己没做好就得主动扛锅,不要纠结怎么甩锅……就算是别人的责任,也要想着帮别人改进,这才是主人
其实,我觉得领导可能在高层面前已经自己把锅给扛或者替小弟把锅甩给别人了,回过头来鞭策一下小弟也是有可能的,至于到底如何只能各自猜测了,这取决与大家自己的经历和心理阴暗程度了
那么,case 的确覆盖到了吗?
我合作过的 coder,最常犯的、最愚蠢的而且能反复错的问题:
1、循环外定义变量,内部不做初始化
2、不做 NPE 预处理,出了事就一脸懵逼反问测试会不会操作,换个数据给他立刻吃惊:还有这种骚操作?
3、catch exception 之后不在 finally 里面做事务完整性保护习惯性在 catch 里面做
……