利用Speech Recognition进行语音识别

首先说明一下,我用的是MacOS,多数命令Linux可用,但部分相关命令要进行调整。不建议用Windows。

1、安装环境

#安装pyaudio
brew install portaudio
pip install pyaudio

#安装Sphinx
pip install PocketSphinx

#安装tensorflow
pip install tensorflow

#安装SpeechRecognition
pip install SpeechRecognition

2、测试

#提示你进行语音输入
#默认用Google Speech Recognition
#所以需要梯子,才能用这个命令哦
python -m speech_recognition

3、建议大家看一下自带例子
https://github.com/Uberi/speech_recognition/tree/master/examples
这个库,可以支持多种语音引擎,只有PocketSphinx是离线的,其余都是在线的。
而PocketSphinx的识别率,实在是有些差,需要一些辅助才能达到较好的效果。

PS:
tensorflow需要2018年(3.8.1以后,不包括3.8.1)以后的版本才支持。

利用Face Recognition进行人脸识别

首先说明一下,我用的是MacOS,多数命令Linux可用,但部分相关命令要进行调整。不建议用Windows。

1、安装环境

#安装cmake
brew install cmake
#安装boost
brew install boost-python
#设置boost环境
export CMAKE_PREFIX_PATH="/usr/local:/usr/local/Cellar/boost/1.61.0:$PATH"
#安装pip
sudo easy_install pip
#安装fc
pip install face_recognition
#安装opencv
pip install opencv-python

2、测试

#将已知单人照片,放到iknow文件夹中,而且照片名称就是人名,比如zhangsan.jpg等
#将需要识别的照片,放到unknown文件夹中,照片可以是多人的
#tolerance是精确度,感觉默认的库是以欧美人标准进行训练的,不太适用于亚洲人,建议将tolerance设置到0.5-0.6之间
#命令行会通过iknow的照片,识别unknown中的图片,并输入每幅图片中有哪些人
face_recognition --tolerance 0.56 ./iknow/ ./unknown/

3、建议大家去看一下项目自带的example
https://github.com/ageitgey/face_recognition/tree/master/examples

4、建议大家去看一下作者写的文章,真的写的很通俗易懂
https://medium.com/@ageitgey

可能遇到的问题:
1、如果安装环境时,遇到下面的问题

OSError: [Errno 1] Operation not permitted: '/PATH/XXX-info'

解决步骤如下:
1.1、重启电脑,按command+R进入恢复模式
1.2、点击菜单【实用工具】,打开【终端】,输入csrutil disable,关闭System Integrity Protection
1.3、重启电脑,正常开机
1.4、打开【终端】输入csrutil status,验证配置已生效

如何通俗的解释MD5加盐

MD5自身是不可逆的,但是目前网路上有很多数据库支持反查询。如果用户密码数据库不小心被泄露黑客就可以通过反查询方式获得用户密码或者对于数据库中出现频率较高的hash码(即很多人使用的)进行暴力破解(因为它通常都是弱口令)。

盐值就是在密码hash过程中添加的额外的随机值,比如我的id是abc,密码是123456,存在数据库中的时候就可以对字符串123456idabc进行hash,而验证密码的时候也以字符串(要验证的密码)+idabc进行验证。

这样有另外一个用户密码是123456的时候,依然能构造出不同的hash值,并且能成功的验证,但这时候我的id就作为盐值为密码进行复杂hash了。

可见,盐值最大的作用之一就是减少数据库泄露带来的损失。

一对一会谈:清单对对碰



一对一会谈:清单对对碰

有关如何组织一对一会谈(即管理者与员工定期进行的面谈),比尔·坎贝尔曾经向我们推荐过一种比较独特的方法。管理者应当把最想在会谈中涉及的5件事写出来,员工也应该列一份这样的单子。把两张不同清单拿出来后,单子上十有八九会有几个条目是重复的。对于所有的一对一会谈而言,双方共同的目标都是为了解决问题,如果管理者和员工不能独立找出最需要两人共同解决的问题,那么摆在两人面前的问题就更不可忽视了。

除此之外,比尔还为我们推荐了一个好用的一对一会谈大纲,让我们在应用中受益匪浅。
1.工作表现
a.可以是销售数据
b.可以是产品交付情况或有关产品的重大进展
c.可以是消费者的意见或产品质量
d.可以是预算数目

2.与同事之间的关系(这对企业成员的团结一致非常关键)
a.产品人员和工程人员的关系
b.市场人员和产品人员的关系
c.销售人员和工程人员的关系

3.领导与管理
a.你有没有对你的人员起到指导和帮助的作用?
b.你有没有把“害群之马”清除出团队?
c.你有没有在人才招聘上下功夫?
d.你能否激励员工做出创举?

4.创新(最佳实践)
a.你是否一直在进步,是否一直思考着如何才能变得越来越好?
b.你是否经常对新的技术、新的产品及新的方案进行思考和评估?
c.你是否将业界或世界上最顶尖的人或企业作为对比标杆?

为何产品要聚焦用户

聚焦用户,赚钱便水到渠成。如果你的用户不是你的客户,而你的客户又不认同你“聚焦用户”的观念,那么就很难做到这一点。

谷歌于2012年收购摩托罗拉,而乔纳森最先参加的摩托罗拉会议之一,就是一场长达3个小时的产品评估会。

会上,摩托罗拉的经理把公司每一款机型的特征和功能展示了一遍。他们反复提及客户需求,实际上却与手机用户的真正需求相去甚远,因此他们的话乔纳森大多并不赞同。

在会后午餐时,一位摩托罗拉的高管告诉乔纳森,在摩托罗拉,“客户”所指的并不是手机使用者,而是指公司真正的客户,也就是威瑞森通信(Verizon)以及AT&T公司等手机运营商。

这些运营商并没有时时聚焦用户。摩托罗拉的焦点也没有放在用户身上,而是对准了合作伙伴。

而摩托罗拉的结果,你懂的。

为何技术人员要懂业务



为何技术人员要懂业务
By NEOHOPE

技术是鞋子,业务是脚。先考虑技术,再考虑业务,往往会导致削足适履,让你怎么穿都别扭;不考虑技术,只考虑业务,会导致打赤脚或穿草鞋,让你天天肉痛。两者一起考虑,才能找到合适你的跑鞋、登山靴或轮滑。

不懂业务的技术人员,很难设计出一双适合用户的好鞋子;不懂技术的业务人员,至少知道用户要一双什么样的鞋子。所以,你不懂业务,技术再牛,也要听懂业务的。

一句话,除非你是搞理论研究或专业分工的,否则,脱离了业务说技术都在是耍流氓,脱离了业务谈架构同样是在耍流氓,脱离了业务天天扯一堆前沿名词就是大流氓。

工作笔记001

Hansen的工作笔记001

最近,根据工作安排的调整,参与了部分售前支持工作,发现了工作上的一些不足之处:
1、个人对公司产品的理解不够深入,对用户的最关心的痛点理解过于肤浅,对行业态势了解滞后,对竞争对手了解太少。
2、公司产品的相关文档太少,苦了售前、实施各位大哥大姐。
3、沟通时,技术性仍然太强。回想起来,用户、售前和销售人员居然表示可以理解,也太难为他们了。后面要做到,对方不懂技术,也可以讲明白。
4、有时候,过于急躁,看到自己写的“戒骄 戒躁 戒懒”的便利贴,还是脸红了一下。

改进措施:
1、多学习。就像前面和杨荣聊的,人懒了,放弃学习了,也就掉队了。你做软件,做不到35,除了自己谁也别怪,只能怪自己。
2、多沟通,多讨论。沟通和讨论,是一个很好的可以帮自己系统梳理思路的好方式,关键是不累心。
3、知识组成要多元化。团队成长到一定阶段,即需要专精人才,也需要综合性人才。要及时找到适合自己的路子。但即使你走专精的道路,也要让自己的知识构成多元化一些,才不至于闭门造车。
4、搭建了OpenKM,替代了没人用的Wiki。希望可以发挥一些作用。感谢陈燕婷的大力支持。
5、要逼着各位产品经理、技术经理补充缺失的文档。相信对他们也有很多好处。
6、加强个人非技术的沟通技巧,文档写的要让非开发人员可以读懂。

提高员工积极性的七个关键



提高员工积极性的七个关键
By 稻盛和夫

归纳一下,调动员工积极性的关键:
首先要把员工当作经营伙伴迎入公司;
要让员工从内心爱戴你、迷恋你;
要阐述工作的意义;
要树立高目标;
要确立具备大义名分的企业使命;
要不断讲述哲学;
以及经营者要提升自己的心性。

书中的另一种表述:
把员工当作经营伙伴,要去依靠他们
让员工爱戴你、迷恋你,要有领导气质
阐述工作的意义,让大家认可自己的工作
揭示高目标,让工作有挑战性
明确企业的使命,所有岗位都要揭示大义名分,让大家理解工作的意义
不断讲述哲学,让大家有凝聚力
提升自己的心性,企业才能进步

模拟京瓷的使命,我们公司的使命是:追求全体员工物质与精神两方面的幸福,为世界卫生事业进步发展做出贡献。

为什么需要使IT工作可视化并控制半成品



为什么需要使IT工作可视化并控制半成品
摘自《凤凰项目》

本书中我最喜欢的(也是唯一的)一张图表显示,等待时间是工作中心中某个资源忙碌程度的函数。埃瑞克用这张图表来说明为什么布伦特的30分钟的简单变更要耗费几个星期才能完成。原因显然是,作为所有工作的瓶颈,布伦特的使用率一直是100%甚至超过100%,因此,我们每次交给他的工作都只能在队列里枯等,如果不进行加速或升级处置,就永远不会完成。

资源获取时间

图表显示:横坐标轴上是工作中心中给定资源的忙碌百分比,纵坐标轴上是大致的等待时间(更确切地说是队列长度)。曲线的形状表明,当资源使用率超过80%时,等待时间就会直线上升。

本书中,比尔及其团队意识到,他们对项目管理办公室承诺的交付期会带来怎样的灾难性后果。


我告诉他们,埃瑞克在MRP-8对我说过,等待时间取决于资源使用率。“等待时间是‘忙碌时间百分比’除以‘空闲时间百分比’。也就是说,如果一个资源的忙碌时间是50%,那么它的空闲时间也是50%。等待时间就是50%除以50%,也就是一个时间单位。就说是一个小时吧。所以平均来说,一个任务在处理前的排队等待时间为一个小时。”

“另一方面,如果一个资源90%的时间是忙碌的,等待时间就是‘90%除以10%’,也就是9个小时。换言之,我们的任务排队等待的时间,将是资源有50%空闲时的9倍。”

我得出结论:“因此,对这个凤凰任务来说,假设我们有7个交接步骤,而且每一个资源都有90%的时间是忙碌的,那么任务排队等待的总时间就是9小时乘以7个步骤……”

“什么?只是排队等待的时间就要63个小时?”韦斯充满疑惑地说,“这不可能!”

帕蒂似笑非笑地说:“哦,当然了。因为输入字符只需要30秒,对不对?”

比尔及其团队意识到,他们那个30分钟的简单任务实际上需要7个交接步骤(也就是服务器团队、网络维护团队、数据库团队、虚拟化团队,当然还有布伦特、布伦特、布伦特)。假设所有工作中心都有90%的时间是忙碌的,那么这张图表告诉我们,在每一个工作中心的平均等待时间是9个小时。由于工作必须经过7个工作中心,总共等待时间就是7倍:63个小时。

也就是说,总的“有效时间”(有时候也称为“加工时间”)只有总交付周期的0.16%(30分钟除以63小时)。那就意味着,在总交付周期99.8%的时间里,工作只不过在排着队等待被执行(例如,在报修系统里等和在电子邮件里等)。

我的合著者乔治·斯帕福德和我同在华盛顿州立大学参加詹姆斯·霍尔特博士(在延伸阅读部分有更详细的介绍)的EM526约束管理课程时,我们首次见到了这张图,它如此出色地显示出,高资源使用率所导致的长时间排队的破坏性本质。

遗憾的是,我不知道这幅图的确切来历。有人和我一样相信,这幅图是立特尔法则的简化版本。根据这个法则,我们假定的是只有一个工作中心、均匀的工作队列(例如,所有任务需要的完成时间都相同)、工作之间没有延迟等。

在这幅图中,我相信“等待时间”其实代表着“队列长度”。也就是说,由于它不是所用时间,因此没有时间单位(也就是说,既不是分钟,也不是小时、天)。关于此书派生出来的最棒的讨论(及其合理性/不合理性)都可以在Linkedin网站上本书的页面看到。这些讨论尽管有时略显尖刻,但确实充满智慧。

我的看法是,科学的目标是用最少的原理来解释最多的现象,并揭示惊人的内涵。我认为这张图很能说明问题。它有效阐释了过度压榨IT工作者的灾难性后果,以及在IT运维部门使用传统项目管理方式的错误。

四种工作类型



四种工作类型
摘自《凤凰项目》

由于布置工作的途径比以往更多(例如电子邮件、电话、关于业务应用程序的中途会谈、短信、报修系统、会议等),我们希望直观地看到现有任务。

埃瑞克告诉比尔,IT从事着四种类型的工作。

业务项目

这是多数开发项目所包含的业务举措,通常隶属于项目管理办公室。项目管理办公室跟踪管理公司内的所有正式项目。

IT内部项目

包括可能由业务项目衍生出的基础架构或IT运维项目,以及内部生成的改进项目(例如创建新环境和部署自动化)。这些项目经常并非集中跟踪,而是属于预算所有者(例如数据库经理、存储管理经理和分布式系统经理)。

当IT运维成为瓶颈时,这会导致问题,因为不能轻易查明已经在内部项目中投放了多少生产能力。

变更

经常由上述两种类型的工作引起,往往在报修系统中被跟踪(例如IT运维补救、JIRA或者用于开发的敏捷计划工具)。事实上,在价值流的两个不同部分中存在两个工作跟踪系统,这会引起问题,尤其是在交接工作的时候。

偶然情况下,在一些兼具功能开发和服务交付职责的专门团队中,所有工作都处在同一个系统之中。这样做有一些好处,因为操作层面的故障会和功能缺陷以及新的特性功能一起,在存量工作和现行工作过程中显现。

计划外工作或救火工作

包括操作事故和操作问题,通常由上述三种类型的工作导致,而且往往以牺牲其他计划内工作为代价。