谢邀
在团队士气低迷的时候,Leader 应该怎么提升整个团队的心理状态?
作为团队的负责人,有这个意识就很值得肯定。是的,Leader要为团队士气负责。
回到具体问题,先分析影响团队士气的主要原因,再谈谈如何团队提振士气。
一、首先解决目标问题
管理者最重要的工作就是为团队设定目标和并为目标赋予意义。
目标有三个关键:
二、其次解决路径问题
三、然后解决回报问题
每个周末的午后,把儿子送进EF读书,随后找个环境幽静的咖啡馆坐一会,这便是我一周中最放松的时光。
在咖啡厅的气氛和环境这两点上,我似乎有强迫症,比如装修主色调的运用,地上装饰是否比较体验文化气息,营造了一场视觉盛宴,尤其在比较细微的地方我会非常关注。
简单说,必须能让我一进门就迅速有耳目一新的感觉,要不然我就会转头离开。因为我觉得只有在这样的环境中,闲暇时能够更加放松和享受,写出的文章才会更带有情感。
如果这一天心情大好,也会和妻子点上一壶功夫茶,畅谈一些身边的先闻趣事。
毕竟和她谈话,能让我捕获很多的写作素材。
熟悉我的人都知道,我有位从事猎头工作的老婆,平时的工作是专为某些医疗、金融投资机构提供中、高级岗位职位人才招聘及相关咨询服务。
相比之下,这项工作对业务专业性与人脉关系要求较高,经常会被行业大咖问:“这家公司你觉得怎么样?和某某公司比,你觉得他们之间区别是啥?”
如果回答的不够专业,或者被对方感觉很水,不仅当场尴尬,而且会在信任上大打折扣。
对猎头这项工作来说,一旦失去了信任,就意味着确定性的消失,长此以往,这个圈子也就别想混了。
上周,我妻子手上的某候选人,在通过初试、复试后,最终被卡在了终面上。
这种高端VP岗位的夭折,显然让她十分郁闷。
我本想安慰她,没想到被瞪了一眼,说:“少跟我提这事!煮熟的鸭子都飞了,几十万佣金啊,就这么飞了!”
我一哆嗦,感受到怨愤之气已冲破了天空,立马话锋一转,“胜败乃兵家常事,没事的。”
“去你的兵家常事!我真火大着呢,少惹我!”
我很理解,毕竟业务的发展非常艰难,这给她的情绪带来了压力,笑了笑说:“好吧。那为什么终面被拒呢?”
“现在的客户真难伺候,招的是VP,问的全是与细节相关的问题,最终,候选人抱怨企业小瞧了他,企业则吐槽这哥们很水。”
她喝了口茶,抬起头问我。
“好像在你们技术圈里,这种事情还挺多见?”
这样的话题,曾经在技术圈内也争论了过一阵子。
我试图用几个例子来向他解释,还别说,这方面可是我的强项。
比如,当团队规模超过几十人以上,而且不止一条产品线,那就需要有一名技术总监来管理和协调各个产品线Leader,并负责搭建公共技术平台,提升开发效率,控制质
螺旋模型是一种演化软件开发过程模型,它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。螺旋模型最大的特点在于引入了其他模型不具备的风险分析,使软件在无法排除重大风险时有机会停止,以减小损失。同时,在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。螺旋模型更适合大型的昂贵的系统级的软件应用。[1]
1988年,巴利·玻姆(Barry Boehm)正式发表了软件系统开发的“螺旋模型”,它将瀑布模型和快速原型模型结合起来,强调了其他模型所忽视的风险分析,特别适合于大型复杂的系统。
螺旋模型(Spiral Model)采用一种周期性的方法来进行系统开发。这会导致开发出众多的中间版本。使用它,项目经理在早期就能够为客户实证某些概念。该模型是快速原型法,以进化的开发方式为中心,在每个项目阶段使用瀑布模型法。这种模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段,由这4个阶段进行迭代。软件开发过程每迭代一次,软件开发又前进一个层次。采用螺旋模型的软件过程如下图所示::
螺旋模型基本做法是在“瀑布模型”的每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制,它把软件项目分解成一个个小项目。每个小项目都标识一个或多个主要风险,直到所有的主要风险因素都被确定。
螺旋模型强调风险分析,使得开发人员和用户对每个演化层出现的风险有所了解,继而做出应有的反应,因此特别适用于庞大、复杂并具有高风险的系统。对于这些系统,风险是软件开发不可忽视且潜在的不利因素,它可能在不同程度上损害软件开发过程,影响软件产品的质量。减小软件风险的目标是在造成危害之前,及时对风险进行识别及分析,决定采取何种对策,进而消除或减少风险的损害。
螺旋模型沿着螺线进行若干次迭代,图中的四个象限代表了以下活动:
螺旋模型由风险驱动,强调可选方案和约束条件从而支持软件的重用,有助于将软件质量作为特殊目标融入产品开发之中。
Vuex 是实现组件全局状态(数据)管理的一种机制,可以方便的实现组件之间数据的共享。
当我们的应用遇到多个组件共享状态(数据)时,就可以用到Vuex了。
安装完VueX后,在项目的src目录下新建store文件夹,然后在store目录下新建index.js。(使用最新的Vue-CLI 4.x.x安装Vuex会自动配置好以下步骤)
在store/index.js中 导入 Vuex 包并创建 Store 对象
import Vue from 'vue'import Vuex from 'vuex'Vue.use(Vuex)export default new Vuex.Store({state: {},mutations: {},actions: {},getters:{}})
在main.js中将 store 对象挂载到 vue 实例中
import store from './store'//.....new Vue({render: h => h(App),// 将创建的共享数据对象,挂载到 Vue 实例中// 所有的组件,就可以直接从 store 中获取全局的数据了store,}).$mount('#app')
Vuex 中的主要核心概念如下:
State 提供唯一的公共数据源,所有共享的数据都要统一放到 Store 的 state 中进行存储。
export default new Vuex.Store({state: { num: 0 }})
然后我们在组件中访问 state 中数据的有两种方式:
this.$store.state.全局数据名称 //访问刚刚创建的num就是
this.$store.state.nu
$info = $model->user_info();if (isset($info['error'])) return $this->response($info);if (!isset($info['id'])) return $this->param_error('返回信息错误');$rs = $this->model->where('id', $this->id)->update(['cid' => $info['id']]);
打印出info的值
array ('id' => 1329389309362531,...}
保存后数据库的值
$rs = $this->model->where('id', $this->id)->update(['cid' => $info['id'].'']);
上面是使用laravel5.7,使用laravel5.5之后得到
而其他同事laravel5.5是正常的
在日常工作中,我们会有时会开慢查询去记录一些执行时间比较久的SQL语句,找出这些SQL语句并不意味着完事了,些时我们常常用到explain这个命令来查看一个这些SQL语句的执行计划,查看该SQL语句有没有使用上了索引,有没有做全表扫描,这都可以通过explain命令来查看。所以我们深入了解MySQL的基于开销的优化器,还可以获得很多可能被优化器考虑到的访问策略的细节,以及当运行SQL语句时哪种策略预计会被优化器采用。(QEP:sql生成一个执行计划query Execution plan)
mysql> explain select * from servers;+----+-------------+---------+------+---------------+------+---------+------+------+-------+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |+----+-------------+---------+------+---------------+------+---------+------+------+-------+| 1 | SIMPLE | servers | ALL | NULL | NULL | NULL | NULL | 1 | NULL |+----+-------------+---------+------+---------------+------+---------+------+------+-------+1 row in set (0.03 sec)
expain出来的信息有10列,分别是id、select_type、table、type、possible_keys、key、key_len、ref、rows、Extra,下面对这些字段出现的可能进行解释:
我的理解是SQL执行的顺序的标识,SQL从大到小的执行
CREATE TABLE `zb_interface_logs_35` (`id` int(10) unsigned NOT NULL AUTO_INCREMENT,`url` varchar(255) NOT NULL COMMENT '接口地址',`param` text NOT NULL COMMENT '提交参数',`response` longtext NOT NULL COMMENT '返回信息',`interface_type` tinyint(3) unsigned NOT NULL DEFAULT '0' COMMENT '接口类型:0.发送短信, 10.百度, 20.阿里, 30.纳米',`ip` varchar(45) NOT NULL DEFAULT '' COMMENT '请求ip',`created_at` timestamp NULL DEFAULT NULL,`updated_at` timestamp NULL DEFAULT NULL,PRIMARY KEY (`id`),KEY `interface_logs_35_interface_type_index` (`interface_type`)) ENGINE=InnoDB AUTO_INCREMENT=6910328 DEFAULT CHARSET=utf8
数据3718534条,13.52G
EXPLAIN SELECT id, created_at, response FROM `zb_interface_logs_31` WHERE interface_type=32 AND id BETWEEN 3484981 AND 3560959 LIMIT 3
EXPLAIN SELECT id, created_at, response FROM `zb_interface_logs_31` WHERE interface_type=32 AND id > 3484981 LIMIT 3
基于HTTP的长连接,是一种通过长轮询方式实现"服务器推"的技术,它弥补了HTTP简单的请求应答模式的不足,极大地增强了程序的实时性和交互性。
用通俗易懂的话来说,就是客户端不停的向服务器发送请求以获取最新的数据信息。这里的“不停”其实是有停止的,只是我们人眼无法分辨是否停止,它只是一种快速的停下然后又立即开始连接而已。
长连接、长轮询一般应用与WebIM、ChatRoom和一些需要及时交互的网站应用中。其真实案例有:WebQQ、Hi网页版、Facebook IM等。
如果你对服务器端的反向Ajax感兴趣,可以参考这篇文章 DWR 反向Ajax 服务器端推的方式:http://www.cnblogs.com/hoojo/category/276235.html
欢迎大家继续支持和关注我的博客:
http://blog.csdn.net/IBM_hoojo
也欢迎大家和我交流、探讨IT方面的知识。
email:hoojo_@126.com
轮询:客户端定时向服务器发送Ajax请求,服务器接到请求后马上返回响应信息并关闭连接。
优点:后端程序编写比较容易。
缺点:请求中有大半是无用,浪费带宽和服务器资源。
实例:适于小型应用。
长轮询:客户端向服务器发送Ajax请求,服务器接到请求后hold住连接,直到有新消息才返回响应信息并关闭连接,客户端处理完响应信息后再向服务器发送新的请求。
优点:在无消息的情况下不会频繁的请求,耗费资源小。
缺点:服务器hold连接会消耗资源,返回数据顺序无保证,难于管理维护。
实例:WebQQ、Hi网页版、Facebook IM。
长连接:在页面里嵌入一个隐蔵iframe,将这个隐蔵iframe的src属性设为对一个长连接的请求或是采用xhr请求,服务器端就能源源不断地往客户端输入数据。
优点:消息即时到达,不发无用请求;管理起来也相对方便。
缺点:服务器维护一个长连接会增加开销。
实例:Gmail聊天
Flash Socket:在页面中内嵌
作者:韩天峰
链接:https://www.zhihu.com/question/47994137/answer/131700752
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
性能上Swoole毕竟是C语言开发的,在某些地方如内存管理、数据结构、通信协议解析上肯定要比PHP开发的workerman高。
功能上swoole提供的高级特性很多,列举几个workerman没有的吧,比如SSL/TLS隧道加密、http2.0、异步mysql驱动、异步redis驱动、异步的http/websocket客户端、process、lock、atomic、table。另外Swoole 2.0内置了PHP原生协程的支持,PHP代码也可以使用类似于Go语言的协程来实现高并发的网络服务器。
外部依赖上workerman需要依赖很多额外的第三方PHP扩展来实现,局限性比较大,这些扩展并非是PHP官方维护的,维护性方面良莠不齐,有些扩展连PHP7都不支持,数年没人维护。而Swoole基本上无依赖,底层的代码全部可控。
开发维护方面,Swoole的开发团队目前有大概18人左右,开发者基本上都是来自腾讯、百度、阿里、滴滴、微博等国内一线互联网企业,支持维护的团队更稳定。
当然workerman的优势是它完全使用PHP代码实现,开发者可以直接看它的源码。有特殊需求也可以直接改源码来实现。如果换成swoole就不是那么简单了。workerman做的事情更多一些,即是框架又是工具和完整的解决方案,对于没有太多后端编程功底的程序员也来说确实会容易很多。而swoole实际上只是一个底层库,不是拿来可用的完整产品,基于swoole有很多PHP的框架和程序,比如tsf、zan php framework、hprose-swoole、zphp、swoole/framework、blink、dorarpc、SwooleDistributed等等,普通开发者可以直接基于这些项目进行开发。
Swoole是给高手用的,门槛比较高,需要使用者有深厚的功底。你这里问的哪个更容易开发,这个没办法回答,这个要看你要开发什么、团队或个人
4个带宽峰值时间分别是8:55,9:45,10:15和10:25
5个并发峰值时间分别是9:00,9:45,10:15,10:25和10:45