经验分享_java经验分享 - CSDN
  • Unity内存优化经验分享

    万人学习 2018-10-22 21:38:03
    该课程主要是针对游戏开发过程中,包体的压缩,材质的压缩,效率的优化等一些技术点的讲解,以及编码过程中如何优化内存等。
  • 本来是没有打算做一个初试经验的,但是鉴于很多小伙伴都问了很多关于408方面的复习经验,虽然我的408分数不高,没有120分大佬那么厉害, 但总体还是有一些经验的(关于规划方面),不至于大家在复习时晕头转向,这里...

    B站视频地址

    https://www.bilibili.com/video/BV1UA411e7YR 有更多素材图片 更形象些~ 希望大家多多三连~

    初试经验

    本来是没有打算做一个初试经验的,但是鉴于很多小伙伴都问了很多关于408方面的复习经验,虽然我的408分数不高,没有120分大佬那么厉害, 但总体还是有一些经验的(关于规划方面),不至于大家在复习时晕头转向,这里总结一些经验给大家。

    408 经验

    对于所有的同学,我强烈建议你们最晚408从7月份就可以开始准备了,不要太晚(对于科班来说也是一样的, 408内容多),当你们看到这个经验之后,也是7月多份了,尽快的开始准备了!!

    当然,如果你是三四月份看到这条经验的话,那么你有较充足的时间去把王道的书和教材,多看仔细一些。

    资料准备

    以下是我复习所用全部资料资料和工具

    • 王道单科书 4本

    • 王道真题 + 模拟题

    • 教材 (tb买二手便宜)

      • 现代操作系统 第三版

      • 计算机网络 第七版 谢希仁

      • 计算机组成原理 第二版 唐硕飞

      • 数据结构 用面对对象方法与c++语言描述
        在这里插入图片描述

    • 模拟考试的答题纸, 划线笔 (画知识点)

    时间规划与复习方法

    我一共把408复习分为: 三轮王道单科书复习 + 两遍真题 + 模拟题测试

    三轮王道单科书复习 120天

    我们4科的复习顺序是计算机数据结构,计算机组成原理,操作系统和计算机网络。

    第一轮: 65天

    在看每复习一本王道之前,我们先翻到王道的目录,然后定一下每一天大概看多少页。大概一本王道花15-20天,计算机网络会稍少点时间。这就是你每天所看的章节的范围

    • 第1步先看教材,对应的范围讲到的教材的内容看完 (这是高分学长的一个玄学吧,因为王道它只是一个知识点的精华部分,但是真正考408的时候老师是拿教材出题的,所以你不要以为只看了王道就没关系了,因为它很多题目都是在教材中出现的细知识点,王道上提的很少,所以这就是第1轮复习看教材的原因,这一轮应该决定了你分数的上限
    • 第2步再看王道上面的知识点总结
    • 第3步做王道的选择题(对于大题这里要分科对待,像计算机网络、计算机组成原理、操作系统这一些大题它对于前后的知识都有联系,所以你可以暂时放下,或者只做你会的那部分,但是数据结构的话,对于那些算法题,你可以选作一下, 做单数题或者双数题,或者选几个题,因为它有时候题目会非常多,有五六十个题目,你如果一直做下去的话,耗费时间太长了),进行订正(如果是哪个知识点忘记了,可以在王道的前面对应知识点上,用红色的画线笔把相应的知识点画上,便于你后期再进行,知识点查看的时候,可以更好的注意到红色的地方是我错过的地方),不会的就看王道的解题视频,尽量每个不会题目都要搞懂

    注意: 写选择题的时候用铅笔写订正的时候用红色圈圈或者其它记号来标记错误的题目,做完后用铅笔擦掉,方便第2轮继续重新做。

    第二轮: 50天

    第2轮的话可以脱离教材,或者是不太懂的地方继续看教材书上没讲的清的地方看教材。

    在经过第1轮的复习后,我们对4科的知识框架都有一定的了解,所以这时候大题目我们是可以做的。对于第2轮复习,我们还是像第1轮一样复习每一本书之前先定好每天看多少页,但这个时候我们的速度可以加快,因为我们不需要继续看教材了。

    • 第1步先看王道单科书的知识点
    • 重做选择题和大题 (这里选择题有时间建议全部重做,因为你做的时候会发现有很多题目,之前做错了还是会做错,而且还可能会出现之前没做错的,现在反而做错了这种情况)
    • 订正好,用另外一个颜色的笔来标记错题,把所有的错题都搞清楚,用于方便第3轮作答,第2轮还是用铅笔。

    第三轮: 20天

    第3轮复习的话,我们只需要把全部的错题再做一遍,继续弄弄题目即可(这一步千万要做,因为按照我的经验,不管你前面两轮对错题,是看了视频做的笔记,前面两轮都做错的题目,第3轮还是会做错

    两轮真题复习 30天

    第一轮: 20天

    第1轮主要是真题模拟,抽一个完整的下午的时间,把10年真题完完整整的去模拟一遍,我将强烈建议你买一下考试模拟答题纸来制造一个仿真的环境。

    • 做真题 花一个下午的时间 用答题纸模拟
    • 订正真题, 标记错题, 以便第二次继续做
    • 对于经常错的地方, 从王道上进行巩固

    以上建议 两天一套, 第一天考试+ 订正 第二天找出错点和巩固(错的多的章节 可以连同王道单科书的错题一起在做一遍)

    第二轮:5-10天

    • 选择题可以重新做一遍, 主要关注错题, 做好标记
    • 大题 关注考点, 总结常考的题型。

    一轮模拟题模拟 15天

    和真题整体复习是一样的,尽量也进行模拟,用答题纸和完整的时间进行模拟

    • 模拟考试
    • 当天订正
    • 重做错题

    复习细节

    ​ 最后我想说的是,不要纠结于我上面所设定的时间,因为这也是按照从7月份开始进行复习的一个规划,如果你8月份、9月份再进行复习的话,你要对你的计划有相应的调整,其中后面的时间是相对重要的 ,如果你要改进的话,那么你可以适当的延长408的每天的复习时间,因为408毕竟也有150分,也就是说你真题必须要做两遍,这个是比较关键的地方

    ​ 但也不要因为过于追求进度追求快速而导致前面复习的不扎实,这样的话会给你后面的复习造成非常大的麻烦。对于一些,对于计划不要过于死板,对于学习经验也不要只听一个人的,可以尽力的去搜索一些经验(学长学姐,B站, 知乎),来使自己的复习更有效率,上面的经验只是我的个人经历和看法,大家辩证的去看待即可。

    ​ 最后祝各位考生,初试顺利,考上理想的分数, 励励前行,我们顶峰想见!

    小tip

    • 去图书馆/ 有人学习的地方
    • 找研友相互监督(无竞争关系最好)
    • 和舍友沟通好,搞好关系

    英语二 81分

    阅读:

    • 紧跟唐迟老师的阅读课 真题做三遍, 可以做好唐诗老师阅读课的笔记,做题的时候经常反过来,用具体的技巧的话,可以按照老师讲的就可以了。

      我觉得比较重要的经验、

      • 答案遵从主旨

    完型/新题型/ 英译汉:

    • 真题就够了,多磨几遍真题,技巧的话我当时是没有看,但是你可以看一些相关的技巧

    作文:

    • 总结模板可以在b站上找到一些模板 大作文和小作文

    政治和数学我的经验不多,就不进行分享了

    展开全文
  • 混迹于测试行业这么长时间了,一直想写一篇关于软件测试的经验分享的文章,但苦于工作原因迟迟未下笔。最近终于有了些闲余时间,遂决定把自己的心路历程及所感所想记录下来,与各位同行共勉。 软件测试究竟是做什么...

    混迹于测试行业这么长时间了,一直想写一篇关于软件测试的经验分享的文章,但苦于工作原因迟迟未下笔。最近终于有了些闲余时间,遂决定把自己的心路历程及所感所想记录下来,与各位同行共勉。
    软件测试究竟是做什么的呢?
    软件测试是为了发现错误而执行程序的过程。或者说,软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例(即输入数据及其预期的输出结果),并利用这些测试用例去运行程序,以发现程序错误的过程。
    简而言之就是证明程序的正确性,检察系统是否满足用户需求,发现bug,证明程序有错。(划重点:找bug不是改bug哦~)

    软件测试前景又如何?
    • 软件测试工程师行业前景好、职业寿命长:根据相关招聘网站发布的最新一期的IT职场人气排行榜,其中软件测试工程师、高级程序员、产品项目经理等高薪职位进入”三甲”,成为IT就业市场最新风向标。随着项目经验的增加,项目从业经验越久经历的项目越丰富,就更具有核心竞争力。
    •软件测试工程师职业空间大、发展方向多元化:顶测科技所培养的软件测试人员不仅仅局限于通信及互联网、应用软件二大行业,在金融及其他行业都占有一定的比量,行业范围非常广。同时由于工作的特殊性,测试人员不但需要对软件的质量进行检测,而且对于软件项目的立项、管理、售前、售后等领域都要涉及。向上可以发展成为测试经理、质量经理,横向可以发展成为项目经理等。
    好了说完了软件测试的概念和前景该说说自身了。
    自我定位
    在踏入软件测试行业的前几年,不少测试人员会陷入迷茫期,主要是对职业发展方向不清晰。网上很多谈软件测试人员职业发展方向及核心竞争力的文章,也确实能为各位测试同行提供不错的建议。作为一名软件测试从业者,也曾迷茫过,准确的说直至2016年才真正找准自我定位,在此就“自我定位”这个话题谈谈自己的一些看法。

    笔者曾接触不少测试同行,偶尔会听到测试人员抱怨没有得到应有的认可,主要体现在以下几个方面:
    1、被人觉得测试工作没有技术含量,相比开发,测试更像是一门体力活。
    2、测试人员缺乏相关的技术背景,慢慢形成了有事找开发的工作模式。
    3、大部分测试人员只专注于工作的完成度,缺乏更深度的思考和总结,比如如何提高测试效率、如何对业务进行连贯性总结等。

    以上三点,提到了两个关键词,“技术”和“业务”。结合《google软件测试之道》及看法,把测试人员的定位区分如下。
    功能测试:理论上说,该定位的测试人员应该是对业务需求理解最透彻的群体,专注于用户角度的测试,组织整体质量实践,分析测试运行结果,驱动测试执行。当然除了业务技能过硬,常用的测试工具也是必须掌握的。
    功能测试人员下一阶段的的发展轨迹一般是测试经理岗位,因为很多公司的测试经理并不要求具备很强的技术能力,测试经理更看重的是协调沟通、统筹全局、目标管理、执行管理等能力。
    性能测试:相比功能测试人员,性能测试人员对业务的理解相对没那么深入,其更偏向于技术的运用及数据分析,目的是找出系统瓶颈。性能测试是一个缺口比较大的岗位,最大的原因是由于对测试人员要求较高,市面上的优秀人才相对较少。我们不妨看看拉勾、猎聘、boss直聘等招聘网站对性能测试人员的常见要求。
    1、对经验尤为看重,一般要求3年以上的性能测试经验。
    2、熟练掌握主流的性能测试工具,Jmeter、LR等。
    3、掌握操作系统、数据库、网络知识等。
    4、能够独立规划和组织性能测试,搭建性能测试环境;能够设计性能测试场景,分析性能问题,定位系统瓶颈。
    结合自身的工作经历及调研,笔者整理了性能测试需具备的技能,欢迎各位同行拍砖。
    安全测试:提到这个岗位,估计很多童鞋也只是游离于“安全”两字的字面理解。但笔者想说的是,安全测试是异常复杂的,一个专业的安全测试专家在某种程度上来说就是一个全栈工程师,需具备以下专业素养(部分内容引用《为什么不推荐去做安全测试工程师》《致测试同仁们:让我们一起做安全测试吧》)。
    1、要使用别具一格的视角来审视需要测试的软件。
    2、要改变测试中模拟的对象。
    3、使用专用的测试工具。
    4、了解安全漏洞的原理。
    5、了解安全漏洞的测试方法及防范知识。
    6、掌握上图中“性能测试主要技能”的相关知识。
    笔者毕竟不是从事安全测试岗位的工作,以上理解也可能存在偏差,欢迎相关童鞋指正。
    测试开发:工作重心在可测试性和通用测试基础框架上,编写单元测试框架和自动化测试框架,关注质量的提升和测试覆盖率,持续集成实施等。除了具备业务技能,不同岗位对技术要求也不一样。

    测试架构师:可以说该岗位属于测试人员职业发展金字塔的顶端了,这也是笔者努力的方向。关于测试架构师所需具备的专业素养,有兴趣的童鞋可以拜读一下《一个测试架构师工作心得》这篇文章。总而言之,万丈高楼平地起,作为一名软件测试人员,只有不断的学习、积累,才能迈向金字塔顶端。
    另外,除了以上描述的发展定位,笔者经过多年的思索,感悟出了一套测试人员价值理论,越往上,价值越大,当然收入也会越高^_^,希望能对各位同行的发展有所帮助。
    1、基本技能,编写案例,发现bug等。每一个软件测试人员必须具备的,毋庸置疑。
    2、识别盲点,发现深层次的问题。这一层次更看重的是个人经验及思维方式,工作1年和工作5年的测试员对同一需求理解的深度和广度肯定有差距。
    3、发现痛点,提升团队效率。该层次更多是能站在团队角度思考,通过分析团队痛点,整合资源来改善团队工作模式,提升测试效率。笔者在文章《如何使用Jmeter提高接口测试效率》中提到的工作方法正是从提升团队效率角度出发。
    4、建立个人品牌,授人予渔,愚教于乐。该层次的人在某个领域已经具备了比较深度的知识体系,其通过博客、云课堂、线下培训等渠道面向大众传授知识,并挣取一定的费用,从而实现职业与财富自由。
    5、创新,整合资源,改善行业工作的方式。单凭个人的能力很难达到该层次,所以往往是指某些公司或组织。比如现在盛行的各类云测平台、DevOps等。
    广而不精,未能形成知识体系
    很多测试人员喜欢在简历上写着精通各类测试工具,比如Jmeter、selenium、robot framework等,结果面试的时候,自己却只能却只能游离于工具框架的基本使用,并没有深入去了解工具的精髓,这就是我们所讲的广而不精。
    一切工具的运用说到底是为了提高效率和保证质量,测试行业很推崇自动化测试,下面就以jmeter为例,来阐述如何建立知识体系。

    在开展这个话题前,我们先来简单说说有名的GROW模型,笔者的知识体系建立也是以该模型为基础。
    G(Goal setting):目标。
    R(Reality Check):现状分析。
    O(Options):解决方案。
    W(Way Forward):行动计划。
    16年跳槽到新公司后,本人确定了一个目标,那就是在测试组建立一体化测试管理体系(自动化测试+缺陷管理+案例管理集成)。通过对测试组工作内容(后台接口测试)及工作方式(传统手工测试)的分析,在对比postman、jmeter、soupui等接口测试工具的优劣势后,最终敲定使用jmeter作为测试组的自动化测试工具,主要原因是Jmeter支持外部jar包的方法调用,而笔者刚好有一定的java基础。依赖于jmeter提供的csv data config功能,我们采用数据驱动测试的模式,但是很快就碰到难题了,那就是jmeter的察看结果树对每个请求都是单独展现的,如果同时执行上百条测试案例,检查结果对测试人员来说无疑是个噩梦,于是,笔者致力于解决该问题,并把Jmter+jira+Testlink进行集成,最终我们形成了以下的测试体系。
    一体化测试管理体系的建立仅是笔者推广半自动化测试的开始,结合docker、moutebank等技术,笔者搭建了持续集成环境,进一步提升了回归测试的效率,同时高效地进行质量监控。
    以上笔者的经历更像一张横向的知识网,因为其中用到jenkins、docker、moutebank、java编程等,还需要花更多的精力去深入学习,当每项技能都能掌握到一定深度,才能称为一个完整的知识体系。

    展开全文
  • Git 工作流的一些经验分享

    万次阅读 2017-02-15 23:52:57
    Git 工作流的一些经验分享 笔者使用git有一段时间了,踩过不少坑,这里分享下我在git工作流方面的一些经验。 什么是Git工作流?Git工作流你可以理解为工作中团队成员遵守的一种代码管理方案,在Git中有以下几种工作...

    Git 工作流的一些经验分享

    笔者使用git有一段时间了,踩过不少坑,这里分享下我在git工作流方面的一些经验。

    什么是Git工作流?

    Git工作流你可以理解为工作中团队成员遵守的一种代码管理方案,在Git中有以下几种工作流方案作为方案指导:

    • 集中式工作流
    • 功能开发工作流
    • Gitflow工作流
    • Forking工作流

    下面针对性说下每个工作流可能使用到的场景和适用性:

    集中式工作流

    集中式工作流 | center

    这种工作方式跟svn类似,它只有一个master分支,开发者会先把远程的仓库克隆到本地,之后的修改和提交都在本地操作,直到在某个合适的时间点将本地的代码合入到远程master。这种工作流比较适合小团队,因为小团队可能不会太多的协作和合流的动作。

    功能开发工作流

    功能开发工作流

    这种工作流关注功能开发,不直接往master提交代码保证它是稳定并且干净的,而是从master拉取feature分支进行功能开发,团队成员根据分工拉取不同的功能分支来进行不同的功能开发,这样就可以完全隔离开每个人的工作。当功能开发完成后,会向master分支发起Pull Request,只有审核通过的代码才真正允许合入master,这样就加强了团队成员之间的代码交流,也就是我们常说的Code Review。

    Gitflow工作流

    Gitflow工作流

    这个工作流其实也是我们团队采用的工作流,这也是很多团队会采用的工作流,它会相对复杂一点,但它非常适合用来管理大型项目的发布和维护,后面笔者也会详细讲下这一块。贯穿整个开发周期,master和develop分支是一直存在的,master分支可以被视为稳定的分支,而develop分支是相对稳定的分支,特性开发会在feature分支上进行,发布会在release分支上进行,而bug修复则会在hotfix分支上进行。笔者也是花了不少时间才熟练掌握整个工作流,期间遇到不少坑,后面会跟大家分享下。

    Forking工作流

    Forking工作流

    Forking工作流对于开源项目贡献者一定不陌生了,它有一个公开的中央仓库,其他贡献者可以Fork(克隆)这个仓库作为你自己的私有仓库,开源项目维护者可以直接往中央仓库push代码,而代码贡献者只能将代码push到自己的私有仓库,只有项目维护者接受代码贡献者往中央仓库发起的pull request才会真正合入。

    小结一下

    上面已经大致讲了在git当中的四种比较常见的工作流,都是需要开发者去实践理解的。

    关于git工作流,只有选用最合适自己团队的工作流才能有效的提高开发效率,上面提到的一些工作流模式都有各自的适用场景,如何选用适合自己团队的工作流得结合团队成员的实际情况,看团队成员对于工作流的理解程度,还有对于工作流的执行程度。

    我们团队的一些实践

    现在讲下我们团队针对Gitflow的一些实践:

    master分支

    • 主分支
    • 保持稳定
    • 不允许直接往这个分支提交代码,只允许往这个分支发起merge request
    • 只允许release分支和hotfix分支进行合流

    develop分支

    • 开发分支
    • 相对稳定的分支
    • 用于日常开发,包括代码优化、功能性开发

    feature分支

    • 特性分支
    • 从develop分支拉取,用于下个迭代版本的功能特性开发
    • 功能开发完毕合并到develop分支

    release分支

    • 发布分支
    • 从develop分支拉取
    • 用于回归测试,bug修复
    • 发布完成后打tag并合入master和develop

    hotfix分支

    • 热更新分支
    • 从develop分支拉取
    • 用于紧急修复上线版本的问题
    • 修复后打tag并合入master和develop

    大家可能会发现我们这个跟标准的Gitflow工作流有些差别,其实也没有什么标准不标准的,前面说到要结合团队的实际情况,我们团队对于目前所采用的工作方式都是达成共识的,所以有一些差异并没有关系。

    说了这么久,还没有一句git命令,那就让大家感受一下吧(感谢Bugly小色熊整理):

    1). 首先将远程代码拉取到本地

        git clone xxx
        git checkout -b develop origin/develop
    

    2).新建feature分支

        git checkout -b feature 

    3).多人在feature上开发,如果中途需要将develop的变更合入feature,所有人需要将本地的代码变更提交到远程

        git fetch origin 
        git rebase origin/feature
        git push origin feature

    然后由feature负责人rebase develop分支,删除原来feature分支,重新新建feature分支;

        git fetch origin
        git rebase origin/feature
        git rebase develop
        git push origin :feature
        git push origin feature
    

    这样可以保证feature保持线性变更;

    4).feature开发完成后,所有人需要将本地的代码变更提交到远程

        git fetch origin 
        git rebase origin/feature
        git push origin feature
    

    然后由feature负责人rebase develop分支,然后将feature分支合入develop,删除feature;

        git fetch origin
        git rebase origin/feature
        git rebase develop
        git checkout develop
        git merge feature
        git push origin :feature

    这样可以保证develop保持线性变更,各feature的变更完整可追溯;
    5).合入feature后拉出对应的release/feature分支,后续bug修复在release/feature上

        git checkout develop
        git checkout -b release/feature
    

    release/feature分支的同步合并与feature分支相同
    6).release/feature分支bug修复完成后,拉取对应的tag推送远程进行发布

        git tag -a v1.0 -m 'feature发布'
        git push origin v1.0

    之后将release/feature合入develop分支,然后删除

        git rebase develop
        git checkout develop
        git merge release/feature
        git push origin :release/feature

    7).发布完成后将release合入master分支,保证master为最新稳定版本(实际操作为发起merge request)

    总结

    本篇文章主要针对笔者工作中对于git工作流的一些理解和实践,目前我们团队也是严格按照这样的工作流来完成日常的开发工作,一个让团队成员认可并且有效的工作流才是最适合我们的工作流,任何规则不是为了限制我们思考,而是为了让工作更加高效有序,尽量减少人为的失误。git是一个博大精深的东西,笔者也是不断在实际应用中去理解它,任何一门技术的学习也是这样,就像程序员常用来装逼的一首诗:

    纸上得来终觉浅,绝知此事要躬行。

    参考资料:http://blog.jobbole.com/76847/

    展开全文
  • 物联网入门经验分享

    千次阅读 2019-08-17 13:06:49
    物联网入门经验分享   物联网近年来的关注度一直在增加,相信万物互联会伴随人工智能和5G的发展以及各种标准和接口的完善而逐渐实现。作为业余爱好者,也想探一探物联网的世界,我把我的入门经验分享给大家。  ...

    物联网入门经验分享

      物联网近年来的关注度一直在增加,相信万物互联会伴随人工智能和5G的发展以及各种标准和接口的完善而逐渐实现。作为业余爱好者,也想探一探物联网的世界,我把我的入门经验分享给大家。

      起初,我只是想做个蓝牙控制的电灯开关,并没有意愿去涉及物联网。因为,我几年前在图书馆看过物联网的书,里面大多用的是ZigBee,经典的芯片是CC2530,到淘宝搜了一下,ZigBee相关的开发板略贵,而且,貌似入门难度比较高,不太适合只想玩玩的业余爱好者。

      我的蓝牙电灯开关设备端由单片机STM32F103和蓝牙模块HC-08组成,客户端是手机。起初,我用Android Studio开发了一个简易APP,可以实现蓝牙连接和通信。之后感觉APP控制还是有点麻烦,就搞了个微信小程序,实现同样的功能。
    STM32F103最小系统板STM32F103最小系统板
    HC-08蓝牙模块HC-08蓝牙模块

      之后,我想着何不让它联网,无论身处何地都可以控制。我现在的主控是STM32,联网最快捷的办法是买一个串口转WiFi模块接入。转念又想,单片机和蓝牙模块加起来已经30元左右了,再加上WIFI模块,成本略高呀。我仔细看了WIFI模块的资料,发现它是以ESP8266芯片为核心的,令人惊奇的是,ESP8266不光能连WiFi,它本身也是一个单片机,像端口输入输出,PWM,定时器啥的都有。于是,我决定用ESP8266代替STM32,既然能联网,在哪都能控制,蓝牙模块我也不要了。
    ESP8266开发板ESP8266开发板

      现在,设备端有ESP8266,客户端有手机,要实现联网控制,需要一个云端作为枢纽。这个云端,就是物联网开放平台。网上常用的有阿里巴巴的,中国移动的,还有机智云的。机智云专门做物联网,且开放程度更高一点,开发文档和教程也比较完善,于是云端我选择了机智云。机智云的设备端接入云端有两种方案,MCU和SOC,MCU方案就是我前面提到的单片机加WIFI模块,SOC方案是只用WIFI模块。个人认为,MCU方案灵活度高,可以选择不同的单片机和WIFI模块;SOC方案集成度高,一个板子搞定。我喜欢精巧的东西,就选了SOC方案。

      机智云的开发流程很清晰,在网上开发者平台,根据提示,一步步配置好芯片型号、联网方式、控制的数据点等等,然后,导出单片机的工程。我用的是ESP8266,所以IDE用的是AiThinker,用它打开导出的工程,WIFI通信等底层东西已经写好了,我们只需在用户接口函数中写自己要实现的功能,比如哪个端口输出高电平或低电平。写好之后,将程序用flash_download_tools烧进ESP8266即可。最后ESP8266通电,打开机智云给定的APP,按照提示给ESP8266连接WIFI。至此,设备端就接入云端了。

      接下来,就是客户端接入云端。可以直接用机智云给定的APP,就是上一步给ESP8266配网的那个,在APP里可以控制ESP8266。此外,机智云的开发者平台可以根据你之前的配置,导出一个Android Studio工程,这就是刚才给定APP的工程,你可以自定义UI界面,修改一些代码,制作自己的APP。机智云支持openAPI,也就是通过HTTP接口实现控制,正如我之前做的蓝牙控制,我自己做了个微信小程序,根据机智云的openAPI实现相同的功能。

      前段时间入手了小度音箱,就想着通过小度音箱控制我的物联网设备。我知道,这个要比前面的难一点,涉及的技术面也更广。所幸的是,我发现了blinker,懒人的物联网平台。使用blinker可以轻松将物联网设备接入小度音箱,天猫精灵和小爱同学等智能音箱。

      设备端接入云端这块,blinker比机智云还简单,单从IDE是Arduino的就可看出,将官方示例程序稍做更改,写入在blinker APP上申请的Secret Key(每个设备独有),再写入默认连接的WIFI名称和密码(后期可以通过blinker APP修改),烧入ESP8266即可。

      客户端现在是小度音箱,打开小度音箱APP,在智能家居部分,搜索blinker,进行账户授权即可。然后,给ESP8266那边通电,确保联网之后,就可以对小度音箱说“小度小度,开灯”。这样,就实现了物联网设备接入智能音箱。

      以上就是我的物联网入门经验,当然,只是业余的程度,供入门者参考,也请大佬指点!

    展开全文
  • 双非硕士的秋招经验分享

    千次阅读 2020-02-21 17:11:16
    既然是经验分享,那么我就开门见山地介绍一下自己的情况 本科学校:普通二本院校的一本专业 硕士学校:非985、非211学校的重点专业 前期准备 我在 7、8 月找了一份实习,虽然工作和自己的专业并不对口,但...
  • UEditor富文本编辑器整合经验分享(整合至SpringMVC)

    万次阅读 热门讨论 2018-01-02 17:49:50
    遇到了不少问题,困扰了不少时间,在整合过程中也参考了不少前辈们的文章收获良多,本文主要是谈谈自己在整合过程中遇到各种问题(或者网上甚少提到的)及UEditor自己的一些内部瑕疵,做为经验分享给大家,...
  • 陈晨-证券交易系统架构设计_挑战与实施经验分享 本次分享主要结合交易系统的研发过程和实践经验,介绍了传统证券交易所在系统架构层面的设计思路以及如何应对高可用、高性能等主要技术需求。其中会对交易系统...
  • 业务需求调研经验分享

    千次阅读 多人点赞 2019-06-21 18:18:41
    业务需求调研经验分享 作者:成晓旭 1.针对具体的工作内容,召集专题访谈启动会、访谈沟通会。由客户的项目负责人向涉及的相关部门或...
  • 2020暨南大学计算机考研经验分享-精品(含录取名单,学习等资料获取) 前期都是各位学长的帮助,真的非常感谢,尤其了知乎上分享经验的18级李学长,集中资料,创建了考研群,大家才能在各种够方便获取信息,帮助各位...
  • 1、2018年TI杯赛题 A:利用TI公司指定的高精度ADC芯片制作一个万用表,要求能够测量电流、电压、电阻。精度要求忘记了。...另外根据现场的经验分享,数据手册里面对某个信号要求稳定时间不低于5 us。 ...
  • Unity3D移动端实战经验分享

    万人学习 2018-10-22 21:38:02
    主要是围绕资源加载效率的优化,文本文件加载,比如xml序列化读取,protobuf文件序列化,以及消息事件封装及应用,shader的优化及运用,移动端实时阴影的绘制。
  • 高效研发管理五点经验分享

    万次阅读 2019-01-17 09:00:05
    研发管理核心五点谁应该看人可以少 但流程不能少任务要有负责人,执行要有计划明确绩效和惩罚措施,及时对研发进行激励建立研发人员的成长引导、能力培养和人才选拔机制。建立良好的团队文化 谁应该看 ...
  • 注册电气工程师发输变电基础考试通过经验分享 我本科毕业于天津大学电气工程专业,毕业后在一家设计院工作。工作的第二年参加考试,一次通过。因为单位里有考注册的传统,到我们这 一届时自然也不例外。 推荐...
  • 20年资深程序员编程经验分享 原文作者乔纳森·丹尼可(Jonathan Danylko)是一位自由职业的web架构师和程序员,编程经验已超过20年,涉足领域有电子商务、生物技术、房地产、医疗、保险和公用事业。   从11岁时,...
  • ACM/ICPC 比赛生涯总结+经验分享

    千次阅读 多人点赞 2019-05-05 19:53:09
    ACM/ICPC 比赛生涯总结+经验分享 个人获奖经历 时间 比赛 奖励 大一下 ACM陕西省赛 打铁 大一下 CCCC 团队二等奖 大二下 ACM/ICPC全国邀请赛 银奖 大二下 CCCC 团队...
  • 项目管理经验分享

    千次阅读 2018-08-17 10:11:53
    序言:项目管理经验,这篇文章根据实际出发,站在一个项目经理的角度,充分考虑甲乙双方利益,如何成功交付,如何保证质量,如何规避风险等等,不仅是给项目经理看的,也是给每个开发人员看的,开发有时候也需要具备...
  • Minecraft 多人在线服务器搭建经验分享
  • 程序员面试经验分享

    千次阅读 2013-05-09 12:56:52
    IT旅途——程序员面试经验分享 from  http://www.csdn.net/article/2013-05-09/2815198-programmer-interview  作者季红 程序员面试职业生涯 摘要:本文从IT人员的角度,一起分享面试...
  • 软件测试:一个Tester的经验分享

    千次阅读 2018-06-17 13:04:06
    项目回顾会议上,新入职场的一名 Tester 经历了2个测试项目后做出的测试经验分享: 所有的测试用例设计都应该能够追溯到测试需求; Test Leader、Test Manager、Development团队的Leader等应该能够尽早地和不断地...
1 2 3 4 5 ... 20
收藏数 348,186
精华内容 139,274
关键字:

经验分享