请问请问特定状态下对特定的人提供的网站提供很多有用的教学视频怎么说知识

来源：蜘蛛抓取(WebSpider) 时间：2020-07-11 07:41 标签： 网站提供很多有用的教学视频怎么说
如题我买的网课，但是那个網课能看的次数有限，而且需要用那个网站专门的播放器才能播放而且还有密码所以，我想问问有没有什么软件或是方法可以把视频导絀来然后用自己电脑里... 如题。我买的网课但是，那个网课能看的次数有限而且需要用那个网站专门的播放器才能播放 而且还有密码。所以我想问问有没有什么软件或是方法可以把视频导出来，然后用自己电脑里的播放器也能看的

你好，只能用视频录制软件将播放嘚视屏转录下来（同时录声音）这样，你就可以随时观看了！！如想要请留邮箱。我发给你一个我用的如满意，请采纳！ 

好了已發送，在正式录制前请先尝试等试验好了再正式录制。
额 我选择不了那个录音来源 不能录电脑里的声音 请问要怎么办啊
那就外录用手機或录音笔等等。录完了存在电脑上有时间用视频软件合成一下就好了！就算不合成，用暴风影音播放时选择添加声音（你录好的文件）进去也是非常方便的
暴风里我没看见添加声音啊 我住宿舍 老师有人 外录时老有杂音 很不方便 没有更好的解决方法了吗
软件不支持的话，没有更好的办法了暴风里有，屏幕右键“音频流”播放视频时可选。

你对这个回答的评价是


新版迅雷应该也可以吧、、、可以下載在线视频、我看优酷视频都不用iku用迅雷下载的

你对这个回答的评价是？


屏幕录像专家声音选电脑播放的声音、搜一下有破解的

你对这個回答的评价是？

下载百度知道APP抢鲜体验

使用百度知道APP，立即抢鲜体验你的手机镜头里或许有别人想知道的答案。

请使用者仔细阅读土豆《》、《》、《》、《》Copyright ? 土豆() | 上海全土豆文化传播有限公司网络文化经营许可证： | “扫黄打非”办公室举报中心：12390 | | 不良信息举报电话：

药品服务許可证： | 广播电视节目制作经营许可证： |

为什么说未来是全栈工程师的天丅

根据2017年中国软件开发白皮书指出，目前Web开发群体5成以上为全栈开发者

微信小程序这种轻型“App”给大家带来了无限期待，而这些需要┅个懂得掌握前端、后台等技术的全栈型开发工程师来掌控

短视频的悄然兴起，成为互联网领域新的经济增长点而全栈开发工程师是矗播以及短视频平台不可或缺的技术支持。

从各大名企的招聘现状来看不仅仅是国内的BAT大厂，90%的FLAG公司都已声称只招Full Stack Engineer（全栈工程师）

随著互联网+的发展，众多创业科技公司不断涌现初创公司不能像大公司一样招聘过于细分的人才，更需要独当一面的全栈开发工程师

很哆人会提到，大公司“专家”（精通一个领域）、小公司“全栈”

实际上，全栈不是一个岗位而是一种思维方式，从多角度多方位去思考问题去研究一个新的领域，从而解决一个新的问题

在遇到问题的时候，不会给自己提前设置极限而是愿意尝试各种不同的方式方法从而找到最优解。

真正的全栈工程师就是市场上所说的一专多能的“T”型人才

专的一面能够解决自己岗位的难题，广的一面理解洎己同事所在岗位的技术工作，减少沟通成本这才是真正的全栈。

要注意的是：现在很多专家也逐渐转型为全栈因为单纯依靠于一个領域的技术而存在的专家已经很少了，技术专家们必须依据于公司的需求去开拓不同的领域

搜集近一年的IT行业就业缺口及就业方向发现，目前全栈开发工程师人才每日缺口10000人未来还将保持持续增长，全栈风口已来势不可挡

市场缺口大注定人才供不应求，岗位薪资也自嘫水涨船高相对于前端、后端，全栈工程师的薪资更胜一筹

首先需要了解的是，全栈开发工程师就是掌握PHP、Web前端、H5、小程序的多面型囚才能利用HTML5、CSS3、JavaScript、ES6、jQuery、PHP、MySQL、Node、Vue等多种技能独立完成产品开发。

梳理关键词：前端、后端、服务端编程、语言与框架

看到这么多技术一些人可能会被吓退，其实成为全栈工程师并不是很难

前面已经提过，一专多能并不是样样精通而且市面上样样精通的全才只是零星存茬，所以成为全栈工程师首先要掌握其中几门关键技术。

很多人都想成为全栈工程师但是复杂的编程语言在实战时极容易踩坑。

基本嘚知识点学习是成为全栈工程师的基础但是也需要一定的实践，如果没有实战项目的锻炼没有亲自搭建网页，就无法验证学习成效

佷多人通过啃书的方式一页一页学习时，发现学习效率极低还没有思路；想找老师进行辅导时，培训费用普遍过万可能一些发烧友都鈈舍得花高价去学习，更别说一些小白、兴趣爱好者了

想必大家都听说了，这两天关于中国平安一个产品经理因奇葩需求和程序员爆发肢体冲突的事件在朋友圈被刷屏更有现场打架视频在技术群里疯传。

在这里先带大家简单文字回顾下事情经过N次打架视频和截图就不給大家放出来了，相信大家都在技术群和朋友圈里亲眼目睹过了（当然没看过的朋友可以找我微信私聊），最重要的一点是为了社会和諧

「 肢体冲突的起因 」

以下是网上流传的本次打架事件的文字叙述：

「 事件的处理结果 」

事情的起因大概就是这样，先不讨论本次事件Φpm提出的需求是否合理程序员能否实现，本身这起办公室冲突事件的发生引起了圈内很大的热议，“成功地”推上了互联网热点头条同时也给中国平安公司的名誉带来了负面影响，最后涉事的两位外包人员惨被双双开除

很多看过现场视频的网友是这样分析的，秃头嘚是程序猿没秃头的是产品，假装劝架的是运营和设计看戏的是测试，拍这个视频的应该是商务pm下次记得戴安全帽提需求。

分析地頭头是道活脱脱一个国内社会看热闹不嫌事儿大的缩影，也是厉害

「 如何向外行解释内情 」

可能一些非软件行业内的吃瓜群众，想不通为什么程序员和产品经理要干架我完全可以通过一张表情图合集，来生动形象地告诉你一家软件公司的项目是如何上线的。

看完这張图我们再来说说pm和coder打架的事儿

年轻人血气方刚，一言不合就互怼借用孙红雷在电视剧《征服》里的一句台词：不气盛，还叫年轻人嗎

但是，以暴制暴是不对的朋友，毕竟就算打赢了也是真的疼啊

在乱提需求的前提下，至少得练得跟我一样吧

不然，还真不一定咑得过我说一下我三大项的数据吧：

「 冲突的根源是什么 」

先来说说很多公司的现状：产品经理和“老板们”关起门来开了个会，赶出原型和UI图之后交给程序员们的就是“圣旨”，“反正我们就这么定了你照着开发吧。

程序员说：目标是需求技术只是手段。

产品经悝说：目标是用户需求是方式。

立场不同定位不同，矛盾就来了

产品经理永远是用户需求的代名词，自以为是研发人员的上帝动鈈动就要改需求，他们觉得好像很简单的事情殊不知给程序员添了多大的麻烦。

技术和产品撕逼无非就是以下几个原因：

1，产品没有想明白然后来来回回的改；

2，开发没有理解清楚需求开发东西和产品的要求有出入

所以说，一个不懂项目管理的程序员不是好程序员一个不懂软件开发的产品经理，不是一个好的产品经理

程序员和产品经理似乎天生就有不可调和的矛盾，和平共处很难么

「 说点掏惢窝儿的话 」

就这次事件，土叔我不站队也不说谁对谁错，抱着一颗同理心我分别来站在程序员、产品经理，以及项目管理层的角度给coder、pm，以及manager分享几点我的小想法

「 给程序员的建议 」

程序员和产品经理干架其实需要理性，查查他的经历要分析下他懂不懂技术，慬的话有多懂

一般很懂技术的产品经理是不和程序员干架的。

懂一点但是就拿出来说事的这种，一般和程序员关系不好

一点都不懂嘚产品经理有的谦卑，有的不懂装懂乱说一通

对于懂一点，就拿出来说事的这种就要想法设法在技术上反问他，让他觉得自己其实真嘚知道的很少

这时候再动之以情，说明自己做这个的难度

对于不懂装懂的产品经理，就俩字：你来

还剩下一种是不讲理的，对于这種不讲理的就只有一句话我他娘的意大利炮呢？

玩笑归玩笑土叔在这里分享几点走心又走肾的建议：

做好需求更改的准备，提高代码嘚扩展性和可维护性；

预留出修改bug和需求的时间；

对需求理解透彻再开始写代码；

代码不要写死防止需求变动。

「 给产品经理的建议 」

恏多pm搞不懂为什么产品经理频繁更改需求会令程序员小哥哥们烦恼不堪？我想大多时候是因为你们pm平时在工作中的这些口头禅吧：

1.「先做出来看看吧」

2.「我就要这种效果，怎么实现是你的问题」

3.「这应该很简单吧不就是XXX，然后XXX吗」

4.「这个需求先这样这样，再那样那樣用XX技术很快就搞定了」

5.「你就说能不能做吧」

6.「我有一个绝妙的idea，什么都准备好了就差一个写代码的了」

7.「这个需求老大已经同意叻，你照着做就是了」

产品经理频繁的需求变更和程序员有限的工时是存在矛盾的，除非让程序员加班特别是上次的变更刚刚改完，這时又提出再次修改朝令夕改，一步一步很巧妙地惹恼了程序员

程序员最讨厌朝三暮四的产品经理了。

如何与单纯的程序员共处土菽的走心建议要不要听一下：

1. 不要随时打扰，尤其在他们戴着耳机的时候；

2. 传达「要做什么（What）」还有「为什么这么做（Why）」；

3. 学习基礎开发知识（比如 HTML/CSS），方便彼此沟通；

4. 不要让他们成为最后知道的人一起讨论可以少走弯路；

5. 尽可能用数据说话；

6. 配合工具（哪怕是纸筆）来表达你的想法；

9. 尽可能和他们坐在一起；

10. 他们可能羞于/不善于表达，多给一些耐心；

11. 不要不好意思发问其实他们都很热心解决问題；

12. 不要问那些 Google 一下就能找到答案的问题，节约双方时间；

13. 缕清用户流程不要让他们来处理你的工作内容；

14. 想清楚产品可能出现的各种狀态（404、零数据、极端用例、转场……）；

15. 该你决策就由你来决策，不要分担责任；

16. 相信他们的技术水准（如果他们确实不会他们会学）；

17. 勇敢承认你的错误；

18. 记得给他们展示用户/客户的反馈；

19. 改需求不要超过 3 次，再改就先跪下；

20. 就算月饼被抢了也要友爱和睦相处。

「 給项目管理层的建议 」

其实谁都有想不到的地方，和想不明白的东西但是自己都没有搞懂之前就觉得只有自己是对的，那就只能撕了

在我们公司的团队里，程序员和PM一起讨论需求勾画原型，提出自己不同角度的不同理解让程序员更接触“原始需求”，能参与到产品的生命线里会更好毕竟每个人都有思考能力，不是机器一张需求甩过来就照做的程序员不是好的程序员。

在产品需求会议上允许程序员参加并发表意见，这样可以从技术的角度及早发现产品功能中存在的问题从而避免后期需求的频繁改动。

这也是大多数比较有经驗的互联网公司的常规做法最后说说自己：

今年是2018年，腾讯20周年我30周岁，刚好在腾讯工作满8年

我从来没有想过自己会在同一家公司笁作8年。因为4年足以读完大学6年能让小孩读完小学，8年漫长得不可思议

2010年，我刚大学毕业加入腾讯。那一天学生思维的我，不免鉯学生的尺度定计划：三年的时间我应该足够从这一所“社会大学”毕业吧。

因此我追赶时间，以这个截止日为目标第一年学习高效地完成工作，第二年学习带新人第三年学习影响力，翻译了一本前端书和一本设计书。

我一步步从助理UI工程师晋级到高级UI工程师先是积极响应需求，后来主动找事情做我低着头，做事情非常“用力”自信能把交给我的事情都做得很好。

我的博客文章80%都是头三年寫的现在回头看有很多幼稚的想法，但持续想和写才能提高反过来说，要是现在还觉得好那才糟糕。

2013年三年之痒。我开始觉得日瑺工作毫无挑战考评时连续“优秀”跟“超出预期”拿到手软，但与此同时也迎来新的工作挑战。

那时我的领导问我以后的发展意姠，是想继续研究技术深度还是管理团队。我说如果有机会尽量管理团队吧。

因为以我的理解并不存在两种选项。这个问题就像“給你加工资好不好啊”一样没有意义。学而优则仕骨干不去领导团队，可能有点不负责任（现在想来很自恋呵呵）。

虽然给了领导這样的答复也开始进行正式的管理培训，但我内心还恋恋不舍想保留一点匠人心态

个人能力要继续提高，我就开辟新的赛道：影响力

2014年我认真地投入到写作练习中，在“26岁总结”中写下这段文字：

“在很多场景下我们都需要写作我们要写短小的RTX，长一点的邮件以忣更长一点的分享文章、博客和专栏。关于写作我觉得最有趣的一个事实是，优秀的写作者跟平庸的写作者所能达到的效果相差百倍以仩比优秀程序员和平庸程序员之间的差别还大。”

“优秀的写作者的RTX就是能让对方明白他的目的并且像施了魔咒一样去合作。优秀的寫作者的邮件能让接受者感兴趣清晰地知道信息。优秀的写作者写的博客能用一段话击中读者心理情不自禁点右上角的“分享到朋友圈”……这种效果100个平庸的写作者都达不到。”

“写作者需要的除了文笔还有逻辑思维、数据分析、麦肯锡金字塔理论、心理学等等几乎所有的知识……”

每个人每天都要阅读微信、朋友圈、新闻、读书、知乎、小视频……关于写作对个人能力的的重要性，我认为怎么强調都不为过因为广义的写作、演讲和设计，它们有一个共同的关键内核就是搞清楚你的听众是谁，他们已有哪些信息缺乏哪些信息，你要以怎么样的顺序来传达你想让对方做的事情讲得邪乎点，它们都是一种“心理操纵术”

那怎么才能学好写作（或者演讲，或者設计）呢

答案无趣但有效：持续写。

反复阅读写出来的文字毫不吝啬地删除无用的信息，重新再写

我也这样做，一开始在自己博客仩写水文、在豆瓣写书评感觉不够。2014年2月我加入豆瓣专栏计划，需要每周写一篇超过3000字的专栏文章结束后能获得200元鼓励金。我就像┅个缺乏运动的人强行把自己推入马拉松赛道。

我的前几篇写的很业余错别字、口水话、病句、缺主语、串主语、一逗到底、唠唠叨叨、层级和顺序不对……那也还是要写。几个月后20篇文章的专栏完结了，我的文字水平稳定从30分提升到50分接近及格。

因为专栏内容相對新颖（可能是国内首批系统写“全栈工程师”的思考的专栏）慢慢积累一些读者并每周追看。读者宽容并热情地在评论区给我纠错

後来，人民邮电出版社的责编在豆瓣上看到了我就约我写稿。他说我写的东西已经很多也有一些脉络，可以再整理一下出书又是一個新的挑战。

写书的过程只能说勉力支撑因为只有50分的文字水平，却要输出80分的质量把第一章整理好之后发过去，收到返回的修正稿变成了另一篇文章。责编很专业没有吐槽，只是做客观订正

我羞愧难当，因为痛恨给人添麻烦我记住修改过的问题种类，文法上芓斟句酌保证同类的不再犯。

因为责编会看出文字上的问题然后给我修剪枝丫，但保持大树根基稳定就是我自己的责任对读者的责任。我还买来《麦肯锡教我的写作武器》更系统地学习写作。

经过好多轮的校对我终于可以坦然说出，差不多达到基本的标准了后媔的事情我在“我出书了”中也都写了。2015年8月我的书出版了。我在豆瓣上也慎重给《Web全栈工程师的自我修养》打了4星

写作成长磕磕碰碰的同时，管理之路也迂回曲折试着带一段时间团队之后，我在2014年正式成为团队管理者

当时对于团队管理的职责抱有几个不成熟心态：

  1. 管理比写代码更容易掌握，践行起来也更轻松
  2. 管理者门槛较低，相较于工程师缺乏核心竞争力以后跳槽我还是要以工程师身份来定位。
  3. 我喜欢专注做事情不适合做管理。
  4. 在工程师团队中我要以最强的技术和努力来赢得尊重，我要有能力解决他们都解决不了的问题

因此，从虽然也通过努力收获了一些个人成长但对团队领导来讲其实我是不称职的。

有一个明显不称职的表现就是每到员工考核期間，我就很纠结痛苦我不希望有员工拿低于预期的考评，也害怕面对下属沟通面谈当面对着他说你的绩效低于预期。

我能自律勤奋泹我很难改变自己的观念。最难的是我甚至不知道自己是否应该改变自己的观念（瞧，这就是为什么改变观念是最难的）还是说退回詓做一个还不错的工程师好了。

我在这个观念段位大概停留了两年多经过断断续续的实践、阅读、观察和自省，我终于升级了期间纠結和思考过程可以从2014到2016的博客文章中可见一斑。

总之升级后的我认为：

  1. 管理比写代码（或任何一门硬技能）更难于掌握，这是我跟一些技术专家沟通得到的共识硬技能的学习可以通过读书、培训班，甚至网络视频来学习然后持续练习，越来越熟练直到产生一个输出粅。这非常简单只要掌握了学习的方法，几个月就能学习一门硬技能而管理的学习需要真实观念的转变，这个观念改变可能需要几年時间
  2. 管理的核心观念是“管理者必须善于做有效的决策”。
  3. 管理者要注重组织对外的贡献基于贡献来衡量每个人的绩效。

我开始积极與团队沟通日常中看到不符合要求的输出，我就会直截了当地说“这不行达不到基本水准”。

虽然比较严格但也没有看到团队氛围丅降的情况。因为从员工角度来讲虽然乐于处在一个人际关系融洽的团队中，但更大的述求是加入一个充满专业人士的团队每人都能從其他人身上学到特定知识，每人表现都是专业的

我不再担心员工考核，因为它是一个有效的管理工具有些无法用言语传达到的信息，可以通过绩效考核来传达而且平时对于低绩效的员工就要做好预期管理，言行一致员工就不会困惑

2017年，我慢慢成为一个资深的管理鍺又一次对工作驾轻就熟时，再次迎来新的挑战——转换岗位领导腾讯微云UX设计团队。

我喜欢这个挑战一方面它确实是一个“很大挑战”，受虐症的我无法拒绝另一方面我一直处于产品流程中偏后的位置，但也对前置的思考很感兴趣

因此，我梳理了自己面临的挑戰：

  1. 之前领导的团队都是工程师而现在的团队由交互设计师和视觉设计师组成。虽然管理的基本法是相通的但新团队的成员还需要更哆熟悉。
  2. 自己的设计专业能力不够尤其是在视觉上，无法给到“怎么做”的建议
  3. 新的UX设计团队面临比以前更复杂的外部关系。
  4. 如何帮助下属专业晋升
  1. 能轻松地理解版本管理、多平台特性、开发挑战等“工程”难题，然后管理好风险
  2. 参加了三年多设计部的管理会，对設计的“味道”有感觉或者说品味远远高出实现能力。
  3. 在UI方案上我有用户同理心，不只是从“好看”来评判设计
  4. 我的演讲呈现能力囷写作能力可以提升团队。

唔也不全是坏消息嘛。那就开始做吧！

前半年仍然是勉力支撑（哭）但因为团队都在看着自己，不自信也偠自信起来

工作之余多体验各种APP，收集UI、运营、营收、品牌等方面的案例进一步提升“产品力”。老婆平时在使用新的APP或者被活动吸引付费时，我就会在边上观察她的行为看到精彩处，我还会请求暂停截图发给我。

总之我希望自己的专业成长能快速补上权限扩夶带来的差距。

慢慢地有一些“腾讯微云用户体验不错”的口碑了，在自己能影响的范围内使用我能调用的资源，慢慢地补齐漏洞提升体验。

但仍然能力有限有时候会出现仓促出的方案不合理的情况。这时更加如履薄冰不是怕外部批评我，而是怕连累授权给我的仩司和被我能力所限的团队。加上腾讯微云也是一个有历史包袱的产品所以仍然离自己心中的理想产品差很多。

团队成长上的挑战同樣很大

我仔细观察每一个人的优缺点，用人所长与此同时我还要横向去看部门其他设计师的输出，不希望相对独立的产品导致了封闭嘚专业氛围这将是接下来花半年到一年重点要解决的。

我对现在这个挑战还远远没到驾轻就熟的状态，可能还需要两年以上时间来消囮所以有时工作会觉得比前几年加起来还累。

我时常以山本耀司的话给自己打鸡血：

我从不相信什么懒洋洋的自由我向往的自由是通過勤奋和努力实现更广阔的人生，那样的自由才是珍贵的、有价值的我相信一万小时定律，我从来不相信天上掉馅饼的灵感和坐等的成僦做一个自由又自律的人，靠势必实现的决心认真地活着

勤奋和努力只是基础，以大多数人的努力程度之低还根本谈不上拼天赋。

疲劳和兴奋交替成就和挫折并存，曲折前行比轻松混日子更有趣。

回头看这八年来，我从来都只是“短暂地胜任”自己的工作每當我觉得能够驾轻就熟地处理目前的日常，就会迎来新的挑战

想到这一点，我突然悟到一种“佛性”的工作哲学：

每当你能胜任当前的笁作就会迎来更高难度的挑战。

每一个能胜任当前工作岗位的人都会被提拔。继续胜任那就继续提拔，直到不能胜任

因此，不用特别在意自己的头衔、权限和职级外部的认可是你能力的反馈。你没有被提拔大概率是因为还不胜任当前工作。如果完全胜任还没有被安排更有挑战的工作要么自己找事情做，要么跳槽转岗

反过来说，自知自己能力还达不到岗位要求也不用担心不胜任是常态，以勝任为目标就好啦

对于职场马拉松来说，心态放松保持作息，持续养成好的习惯学习好的方法和观念，这才是最重要的

身在江湖，谁都不易只要换个角度思考，互相多点体谅这种矛盾自然就可以化解。

文章最后如果想彻底解决pm和coder的矛盾冲突，马叔有个不成熟嘚终极方案朋友们不妨一听：

产品/UI每天给程序员提任务，程序员每天给产品做任务

如果同一个人可以分饰产品/UI和程序员两角，那么他僦会变成永动机

这款永动机有个广为人知的名字，叫做独立开发者

我要回帖

更多关于 网站提供很多有用的教学视频怎么说 的文章

 

随机推荐