Shirley娅迪

Shirley娅迪 查看完整档案

填写现居城市  |  填写毕业院校  |  填写所在公司/组织填写个人主网站
编辑
_ | |__ _ _ __ _ | '_ \| | | |/ _` | | |_) | |_| | (_| | |_.__/ \__,_|\__, | |___/ 该用户太懒什么也没留下

个人动态

Shirley娅迪 关注了标签 · 10月13日

微信小程序

微信小程序开发工具,技巧

关注 891

Shirley娅迪 关注了标签 · 10月12日

thinkphp6

thinkphp官方全新一代框架

关注 8

Shirley娅迪 关注了标签 · 10月12日

thinkphp

ThinkPHP是一个开源的PHP框架,是为了简化企业级应用开发和敏捷WEB应用开发而诞生的。最早诞生于2006年初,原名FCS,2007年元旦正式更名为ThinkPHP,并且遵循Apache2开源协议发布。早期的思想架构来源于Struts,后来经过不断改进和完善,同时也借鉴了国外很多优秀的框架和模式,使用面向对象的开发结构和MVC模式,融合了Struts的Action和Dao思想和JSP的TagLib(标签库)、RoR的ORM映射和ActiveRecord模式,封装了CURD和一些常用操作,单一入口模式等,在模版引擎、缓存机制、认证机制和扩展性方面均有独特的表现。

关注 643

Shirley娅迪 赞了文章 · 9月29日

不四:产品工程师的修炼之路

简介: 我是不四,毕业后一直在阿里和蚂蚁工作,不四是我在阿里的花名,社区中一般以另一个花名 “死马” 出现。每一个人的成长轨迹都不一样,一路上遇到的机遇也各不相同,这次分享也仅站在一个普通工程师的角度来分享我的成长经历和贯穿其中的一些个人习惯。

作者 | 死马

image.png
我是不四,毕业后一直在阿里和蚂蚁工作,不四是我在阿里的花名,社区中一般以另一个花名 “死马” 出现。工作这 8 年多来一直专注在 Node.js 和 Web 开发领域,也在社区参与了一些开源项目,包括 Koa、Egg 和 cnpm 等,非常幸运在 node 出生之初就开始参与其中,算是赶上了一波由 node 带来的大前端变革浪潮。每一个人的成长轨迹都不一样,一路上遇到的机遇也各不相同,这次分享也仅站在一个普通工程师的角度来分享我的成长经历和贯穿其中的一些个人习惯。

成长历程

image.png

实习

在 2011 年的夏天,大三暑假我来到了当时的淘宝数据平台实习。也不知道是运气好还是运气差,我是以 C++ 工程师的身份被招聘的,分配到的数据产品部却是一个做 Web 产品的团队,还是用刚刚出生的 Node.js 作为服务端开发语言,并在实践全栈研发,还记得那时候 node 的版本才 0.4,而我是一个连 JS 和 JSP 都分不清楚的菜鸟,大学三年只写过黑框框的 C++,连 HTTP 是什么都不知道,无比忐忑的开始闷头学习 JS 基础。

image.png

多年以后和当时看的入门教材作者成为了同事。

幸运的是,当时的团队大牛云集,国内第一批 Node.js 的布道者,node party 的发起人空无、清笃、玄澄,以及国内 node 社区一直以来的核心贡献者苏千和朴灵等等都集中在了这个团队。跟随着他们的脚步,我在大半年的实习时间内,顺利的将 C++ 给忘光了,成为了一名新手 JS 工程师。

数据产品部

12 年毕业后正式入职淘宝数据产品部,那是大数据最火热的年代,我们坐在淘宝数据平台的金山上,挖掘出来了数据魔方、淘宝指数、淘宝时光机等数据产品。随着我慢慢的深入业务,也逐渐理解了团队为什么选择 node 技术栈。大部分的数据产品本身的计算和业务逻辑相对不会太复杂,依赖大量后端数据源提供数据,是一个典型的 IO 密集型应用。而 JS 全栈也可以带来更高效的研发效率。

image.png
数据魔方

image.png
淘宝时光机

随着数据产品覆盖的场景越来越多,我们需要对接到阿里集团的各种内部系统。所以我们用 node 实现了内部的微服务框架、登录系统、配置系统等中间件。而随着 node 生态的越来越繁荣,搭建一个内部的 npm 包管理系统也提上了日程。我们尝试着用 npm 官方的解决方案搭建,但是难以运维,也不能完全满足需求,最后我们开发了 cnpm 用来搭建内部的 npm 包管理平台并提供了国内的 npm 镜像。后来的事实证明,一个快速的 npm 包管理平台对于促进 node 和大前端社区的繁荣起到了至关重要的作用。

刚毕业的这两年是我技术成长非常快的时候,一方面是团队有很多大牛可以学习,另一方面也赶上了一波 node 技术初生的福利期,我也在这里完成了工作后的第一次晋升,从 P4 晋升到 P5。

天猫前端

在 14 年中的时候,由于团队的一些变化,我转岗到了天猫前端团队。当时的天猫前端团队其实没有专职的 node 开发工程师,团队遇到的一个很大挑战是运营活动页面之前都是运行在 php 上,随着 php 工程师在阿里的逐渐减少,那套年久失修的 php 系统已经难以继续支撑流量越来越夸张的双十一活动了。所以我开始着手通过 node 实现新一代的页面渲染服务。

新服务在 14 年双十一的时候在天猫首页进行验证,从性能和稳定性上比老的 php 服务高出很多。接下来我们开始基于新的服务上层实现了新的可视化页面搭建系统,非常完美的支持了 15 年的双十一,这套系统也一直服务到现在,当然已经进化的更加完备和复杂了。
image.png
当时给 php 和 Node.js 系统做的 benchmark

在天猫可以说是之前那段工作经历积累后的爆发期,用一个全新的技术栈实现了一个重要的业务系统,并取得了很大的业务价值,所以在 15 年的时候我也从 P5 晋升到了 P7。

蚂蚁体验技术部

可能还是有想做更底层一点技术的念头,我在 16 年初的时候决定从天猫前端团队转岗到蚂蚁的体验技术部给大前端团队做内部的 Web 框架和 BFF 研发模式的支持。其实在去蚂蚁之前,我也一直在维护者 Koa 和一些 Web 框架生态和中间件的服务,到蚂蚁之后参与做的第一件事情就是从当时蚂蚁的 Web 框架 Chair 中抽出来了 Egg.js,以统一阿里经济体各不同 BU 的大前端 Web 研发体系。Egg.js 也随后面向社区开源。

image.png
Egg.js 生态

通过两年多时间的发展,BFF 研发模式也慢慢的被蚂蚁、阿里经济体甚至是国内接受了。我也在这里晋升到了 P8。

语雀

随着一次内部组织架构调整的机会,我来到了语雀团队。它是蚂蚁体验技术部内部的一个创新孵化项目,为十万阿里人提供知识协同和文档管理的服务,18 年的时候,语雀也开始对外服务。兜兜转转的走了一圈,我又回到了使用 JS 全栈进行应用开发。在语雀团队,我们践行着产品工程师文化,高效的完成产品研发。

image.png
语雀产品工程师文化

简短的总结毕业后的这 8 年,我在一个公司内兜兜转转,但是一直专注在一个技术领域上,并在底层技术、基础服务、产品研发等不同的方向做探索。成长过程中可能有很多的幸运,你能遇到什么样的团队和老板,可以做什么样的事情,这些可能我们都很难完全控制,但是我们能够控制的是作为一个工程师,你如何提升自己的技术能力,做好抓住机会的准备。

工程师成长密码

回过头再来看这几年,我在工作和社区中养成了一些习惯,这些习惯可能是对我的技术成长影响非常大的。

坚持写代码

显而易见,作为一个工程师,我们最重要的职责就是写代码。熟能生巧,坚持写代码一定是工程师成长手册中最重要的一点。不论是在做技术项目还是带团队,写代码一定是我日常工作中最重要的一部分。
image.png
然而低质量的重复是毫无意义的,我们要坚持写代码,更要坚持写好代码。

什么是好的代码?这个问题可能不同的人眼中有不同的答案,对我而言,好的代码起码要满足这三个条件:

  1. 好的代码是简单的,简单的代码架构清晰,并且让编码变的更轻松;
  2. 好的代码是给人看的,绝大部分的应用都是要持续维护的,不给别人挖坑,也是不给未来的自己挖坑;
  3. 好的代码是可测试的,通过编写单元测试,既保障代码的逻辑完备,减少 Bug,也利于后期维护与重构。

保持代码简洁

先从简单说起,简单的代码是容易理解的,然而想要编写简单的代码,架构起来又是更复杂的。这是给自己提出更高的要求,不断优化重构,在这个过程中得到成长。当遇到一些复杂需求的时候,我始终坚信一点:如果一个逻辑我们作为实现者都很难梳理清楚,代码中一堆的 if else 条件判断,那用户也一定是无法理解的。

所以当遇到这种情况,我们需要从产品侧和架构侧去思考,到底是什么原因导致了复杂度?我们应该是去优化产品需求还是去优化底层架构。这也会迫使我们在产品和架构上有更深入的思考。

Code Review

另外一个我和团队一直在坚持的习惯是 Code Review。CR 是一个非常好的提升代码质量的方式,它是需要团队投入大量精力的事情,但是一定收获不菲。
image.png
我们直面 CR 的灵魂三问:

  1. 为什么要做 CR?业务催的那么紧,哪有时间做 CR?
  2. 谁来做 CR?是团队的主管、核心工程师才能帮别人 CR 吗?
  3. CR 是一件很费精力的事情,如何才能坚持下来呢?

image.png
Code Review 的主体是人, Review 的对象是代码

  • 对于代码提交者的人来说,当你知道你的代码会被其他人看到的时候,是肯定会更加注重代码质量的。我还记得我开始向社区成熟开源项目提交代码的时候感受到的巨大压力,它会让你在提交代码前更仔细的设计和编码。经过一次次的 CR 后,你会发现你的代码质量会飞速提升。
  • 对于评审人来说,每一次 CR 都可以增加你对整体代码库或者不同业务的熟悉程度,还可以传授经验、提升团队影响力。
  • 最后,通过 Code Review,我们可以提升项目代码的质量与可维护性,统一团队的代码风格,并让每一个业务逻辑都能尽量找到 back up。CR 是一件三赢的事情。

CR 是一件很有意义的事情,但是我们应该怎么去做呢?

第一步还是要从自己做起,通过自己的主动与坚持,带动团队一起参与。在提交代码的时候,写好 commit message,做好自测,注意代码的可读性。抽时间来 Review 团队其他人的代码,为每一行代码负责。
image.png
但是 CR 毕竟还是一个团队的事情,如何保持团队 CR 的质量呢?我们一定要严抓新人的第一次 CR。一般来说我们团队新人的第一个 PR 都会收到比较大的挑战。新人对代码不熟悉,编码风格也和团队可能不一致,第一次 CR 非常重要,需要让大家都对齐对代码质量的标准和要求。
image.png
对新人重拳出击

除了代码之外,更上层的设计与架构也需要做 Review,让每一次系统功能设计、架构升级都经过 Review,不仅可以让系统更稳定,也可以快速提升自己的系统架构能力。

Unit Tests

  • 你的代码质量如何度量?
  • 你是如何保证代码质量?
  • 你敢随时重构代码吗?
  • 你是如何确保重构的代码依然保持正确性?
  • 你是否有足够信心在没有测试的情况下随时发布你的代码?

如果对这些问题没有答案,或者没有 100% 的信心,那你需要给你的代码做单元测试。

现在说起单元测试,大家其实还是有体感的。然而在 12、13 年我刚工作的时候,单元测试还是一个相对陌生的概念,但是当时的 node 开源社区其实已经慢慢开始流行起来写单元测试了,当你给其他开源项目提交代码的时候,没有测试是不可能被合并的。当时高产的 TJ 不仅仅提供了 express connect 等 Web 框架,同时也提供了一系列底层配套的测试模块,包括测试用例驱动器 Mocha,断言库 should.js,http 请求测试库 supertest 等等。

跟随社区一起,我们很早就把单元测试引入了我们的工作中,基本上从我正式工作开始编写的第一行项目代码开始就在写单元测试了,这个习惯让我在 8 年的工作经历中保持了不错的代码质量,在没有测试工程师测试过我的代码的情况下,没有搞出重大故障被阿里开除。

说起对业务代码写单元测试,可能大家的第一反应还是哪有时间写单元测试啊?其实写单测真的没有那么耗时,只要你找对工具和方法。对于单元测试来说,只需要四个步骤:

  1. 创建一些初始数据;
  2. 对外部依赖进行 mock;
  3. 最小粒度的执行要测试的方法;
  4. 对结果做断言。

image.png
剩下的就是按照这个方式构造测试用例输入,尽可能的覆盖代码中的每一个分支和边缘场景。

Web 应用中的单元测试更加重要,在 Web 产品快速迭代的时期,每个测试用例都给应用的稳定性提供了一层保障。API 升级,测试用例可以很好地检查代码是否向下兼容。对于各种可能的输入,一旦测试覆盖,都能明确它的输出。代码改动后,可以通过测试结果判断代码的改动是否影响已确定的结果。我们在做 Egg.js 的时候,最重要的一件事情就是给它编写对应的测试框架,让业务方能够更简单、没负担的写单测来保障代码质量。

而把代码的覆盖率提高,看到测试覆盖率的报告全绿,不仅对上线代码更有信心了,同时也是一件很有成就感的事情。
image.png

持续分享

如果说坚持写代码是练习和输入,那另一个对我成长帮助很大的习惯就是分享,这看起来是一个对外的输出,但在我看来它更是一个非常好的学习机会。

在我刚工作在数据产品部的时候,我们团队组织了一个 Show Me The Code 的内部分享沙龙,是一个形式非常随意的分享会,不需要准备正式的 PPT,不需要很长的分享时长,就简单的分享一下最近学到的新知识,看到的有趣的代码。这个培养了我去分享的习惯。那时候经常为了找一个分享的话题,去主动研究一些新的模块,看他的源码,自己也会去造一些小的轮子来解决实际工作中遇到的重复性工作。而现在在语雀团队,我也在组织内部双周分享会,已经坚持了一年多的时间了。

image.png
再小的分享也会有收获

工作的这些年我也陆陆续续在外面的会议进行了不少的外部分享。基本上每一次分享,都需要自己先认真的对要分享的内容查漏补缺,并尝试着将它准备到浅显易懂。每一次演讲过后,都会让你对这个演讲主题的领域有更深的感受。
image.png
分享对我来说更多的是给我提供了一个非常好的阶段性总结的机会,最好的学习方法就是教会别人,因为谁也不想在台上出糗对吧。去听一场技术分享,听到的知识转眼就忘了,而你认真的去准备一场演讲,那场演讲收获最大的一定是你自己。

参与开源

对我的技术成长影响很大的另一个因素是开源,当然开源本质上也是一种分享。

现在是一个百花齐放的年代,开源世界的项目越来越多,根据 GitHub 的数据,2019 年有 4400 万个新项目被创建。每一个有技术追求的工程师可能都想过要去 GitHub 上写点什么。但是开源并不是指的在 GitHub 上提交代码,开源更多的是一种心态。

  1. 开源意味着你要将你的代码给所有的开发者审阅,就像前面 Code Review 的时候说的,把代码给别人看是一件很有压力的事情,更何况提交到 GitHub 后,所有人都能看到,你的同事、面试官都能看到。一定要认真的对待每一行代码,每一次提交。
  2. 同时当有人使用你的开源项目时,意味着你要承担起责任。尽管开源协议可能是很宽松的 MIT,但还是要对你写的代码负责。
  3. 开源应该让你感受到 “痛苦”,需要对开源代码提出更严格的要求,追求最优的代码架构,测试完备,描述清晰,编写高质量代码的过程会让你感受到痛苦,但是会有更快的成长。

可能我们有时候很难自己想到一个很好的想法,或者很难自己实现一个那么高质量的开源项目,不要着急,参与开源的门槛其实也没那么高。

第一步,挑选一个工作中可以用到的领域的高质量开源项目,为什么工作中可以用到很重要,因为这样你才能更好的找到改进的方向,找到痛点。例如我当时选择深入参与的开源项目是 Koa,因为我工作的重点也是在 Web 研发领域,而我觉得 Koa 当时基于 co 提供的那套异步编程模型一定是未来的趋势。

第二步,逐步参与进去,一开始可能只是修一下文档,找找 Bug 修复一下,补充几个测试用例。慢慢的随着你对代码和周边生态的完善,可以进一步去实现一些缺失的周边生态,尝试根据自己实际遇到的问题给项目提交一些功能改善。

国外有很多高质量的项目,我们也可以帮他们做文档的翻译。不要小瞧文档翻译,翻译一遍文档就意味着你要深入理解这个项目,其实也是一件很难并且很有收获的事情,还能够提升社区影响力。

开源是一个成就感驱动的事情,因为你无法从中获得看得着的收益。所以能够持续的参与开源最重要的一点是你要能够从中找到成就感。
image.png

和团队一起成长

说了这么多个人成长的事情,我还是想再稍微说一下团队。我们作为个人在团队中工作,只有帮助团队一起成长,拿到业务价值,才能将我们的技术成长 “变现”。而之前提到的 Code Review 亦或是单元测试,都是需要团队一起来配合的。

如果你的团队还没有内部的分享会,尝试着自己去组织一个定期的内部分享会;
从现在开始做 CR 和单测,用自己来影响团队;
尝试着在团队中建立契合团队的工程师文化。
前两点其实在之前的分享中都已经提及到了,这也是我们团队一直在坚持和倡导的。我想说一下语雀的团队文化,在语雀我们希望每一个工程师都是产品工程师,他是产品的技术合伙人,参与产品讨论、完成产品功能研发,同时他也是某一个具体领域的技术专家,例如前端 UI 组件、编辑器领域、服务端领域等等。在我们的工作流程中,所有的工程师都是以全栈的身份参与项目研发,跟进项目从产品设计、到系统分析、研发自测,CR 以及上线的全流程。通过产品工程师文化,我们鼓励每一个工程师都能够在业务和技术上找到自己的成长方向,并陪着团队和业务一起快速成长。

个人成长很重要,同时想要取得好的结果得到晋升,一定要将个人的成长和团队的成长绑定起来。通过把自己的事情做到极致,帮助团队创造业务价值,在这个过程中提升自己在团队内外的影响力。找到那个个人和团队双赢的点去发力,可以得到事半功倍的效果。

本文来自 蚂蚁集团高级前端技术专家 不四在前端早早聊成长晋升专场的分享。
查看原文

赞 8 收藏 3 评论 0

Shirley娅迪 赞了文章 · 9月22日

100+队伍逐鹿大奖,创新编程挑战赛秋季赛圆满落幕

就在上周末,SegmentFault 思否策划承办的RTE 2020 编程挑战赛秋季赛的决赛在线上圆满落幕了。本次秋季赛的赛题只有一个,参赛者可以根据自己的创意,基于声网Agora SDK、 声网Agora 实时消息 RTM SDK、云录制 SDK 等 SDK 实现实时互动应用,或在已有的项目中实现实时互动场景。

相对春季赛,尽管赛题减半,但参赛选手热情不减,仅一个赛道便有近 260 名开发者报名参赛,组成了 100+队伍,最终 20 个作品进入决赛答辩。

与春季赛一样,这次的决赛和颁奖都是通过 Agora Video Call App 在线上进行的,同时通过 B 站全程对外直播。

最终,决赛一共产生了一、二、三等奖各一支团队,还有两支团队分别获得了最佳创意奖和最佳实用奖。

获奖名单:


一等奖:Storyteller

二等奖:AR Assistance

三等奖:Codesync

最佳创意奖:Touch Fish Artifact

最佳实用奖:Post-it Notes

下面让我们一睹获奖作品的风采!

一等奖:Storyteller


这是一个交互式 Demo 的编辑器,借助了声网Agora SDK 的能力,实现了多人实时协同编辑以及云端录制音视频。

       

在传统的教学视频中,都会演示很多交互的步骤,比如完成某一步后点击哪个按钮,接着输入代码等。相对于其他演示 Demo 的方式的优缺点,参赛者也做了对比:       

Storytell 无需编写代码,任何人员可以使用,支持多人协同,而且可为交互式 Demo 添加多种特效。另外,基于声网 Agora 录制 SDK,还可以在为演示 Demo 录制以视频旁白。 

二等奖:AR Assistance


获得第二名的团队中有一位开发者有多年的 AR 互动软件开发经验,并有多款 AR 应用和 Kinect 交互应用上线。所以这次他们的作品就是将 AR 与 RTC 结合到了一起,做了一个 AR Assistance。

AR Assistance 主要是为了进行实时远程协作而开发的。例如,当一些硬件设备出现故障的时候,往往需要有工程师或专家亲自跑过去现场进行指导或技术支持。

而通过 AR + RTC,则可以进行远程的辅助作业。除了可以进行视频交流,还可以通过 AR 在视频中实时标注出问题所在。

所以在这个作品中,他们不仅应用了声网 Agora SDK,还通过图像识别技术,定位并截取指定区域,对该区域进行点对点标注。 

三等奖:Codesync


在教学过程中,我们经常会看到投影。但当要演示代码,讲解其中一些关键点的时候,投影的问题就变得很明显了。分辨率低、字号小,只要学生做得考后,就很难看清。所以他开发了 Codesync 。

        

Codesync 是一个 VS Code 插件,单击右键菜单内的一个“开始代码同步”按钮,就可以利用声网Agora RTM SDK 的能力,实时将老师在 IDE 中修改的内容同步展示到 Web 浏览器端。同时,该插件会生成一个房间号和二维码,学生扫码或用房间号就可以加入房间,看到老师的操作。而且,学生在房间内还可以发送弹幕,实时交流。

最佳创意奖:Touch Fish Artifact


这个作品创意,源自于很多人日常都在做,却又不会公开承认的一件事——摸鱼。应用的首页为一个简单的lottie鱼游动的动画,点击任意位置进入主页面。然后,你就会进入一个视频会议,在这里正式进入“摸鱼”状态。

因为在这个九宫格显示的视频窗口里,除了你以外,其它的视频图像都是提前录好的。当你在这个状态下输入 B站或腾讯视频的网址后,你可以在右上角的视频窗口中浏览网页。(温馨提示,如果输入“Agora”,还会有彩蛋)

最佳实用奖:Post-it Notes


这个创意是源于在线上课记笔记而产生的。参赛团队基于声网 Agora SDK 开发了一个支持截图记笔记、点击查单词的在线课堂+笔记应用。这个应用分为学生端和教师端。教师可以在上课的时候分享屏幕。学生可以在上课时随时截图,并在图上标注笔记。

下课后,观看课程回放的时候,屏幕右侧会显示之前记下的笔记截图,点击截图,就会自动跳转到当时的课程画面。

以上就是本届 RTE 2020 编程挑战赛秋季赛的获奖作品及团队。

SegmentFault 思否 CTO 祁宁表示:这是我第二次作为评委参与到声网的编程挑战赛,这一次选手们的切入点都非常广泛,而且大多数作品的完成度都非常高。大家都利用了声网提供的强大的实时通讯能力,有些作品还结合了时下社会热点,是真真正正奔着解决问题而去的。祝贺那些取得好成绩的队伍,也期待他们能继续打磨产品。

获奖团队除了会得到本季度大赛奖金,还可以申请进入声网应聘快速通道。参与大赛的创业团队,还可通过声网Agora官网“400-6326626”咨询电话申请加入“Agora创业支持计划”(需保证使用声网产品的分钟数用量高于10000分钟/月)。

本次挑战赛的作品将开源在 Github:

https://github.com/AgoraIO-Co...

9 月 26 日,RTE 2020 算法挑战赛的决赛也将在线上举行,声网将在本周预告直播。关注深度学习、计算机视觉的小伙伴不要错过哦。


作为大赛的策划和承办方,SegmentFault 连续组织了声网春秋两季的编程挑战赛,即 RTC 2020 Innovation Challenge 编程挑战赛秋季赛,RTE 2020 Innovation Challenge 编程挑战赛秋季赛。

从开发者的角度,技术竞赛能够很大程度让开发者从日常任务中脱离出来,回归初心,通过动手打破现实系统的束缚,将创新想法变成现实。

SegmentFault 作为最早把黑客马拉松引入中国、中国最大的 Hackathon 组织者,在大陆、香港、台北、新加坡、美国硅谷等地参与或举办了上千场 Hackathon,覆盖了数万名 Hackers。如今我们将成熟的 Hackathon 组织经验提炼和升华,面向企业定制以推动技术创新为目的的企业内/外部技术竞赛 / Hackathon,希望更多企业和开发者可以参与进这场创新的革命,一起 Make Things Happen!

技术内训/技术活动合作:marketing@sifou.com

segmentfault公众号

查看原文

赞 17 收藏 2 评论 2

Shirley娅迪 赞了文章 · 9月10日

连接无限可能,华为 HarmonyOS 2.0 正式发布

今天(2020年9月10日),华为消费者业务 CEO 余承东又一次站在了松山湖华为开发者大会的主舞台上。今年,他带来了万众瞩目的华为鸿蒙 HarmonyOS 2.0。此次 HarmonyOS 的升级,不仅仅包括了分布式能力的全面提升,还为开发者提供了完整的分布式设备与应用开发生态,使能全场景智慧生态,引领移动产业的下一个 10 年。

开发者

三大核心能力升级,HarmonyOS 2.0为开发者掌灯

去年推出的 HarmonyOS 1.0 版本,验证了终端分布式技术的可行性,这一技术也被应用到 EMUI 中,创新出多屏协同、畅连视频通话、华为 HiCar 等跨终端体验。HarmonyOS 2.0 则在分布式软总线、分布式数据管理和分布式安全三方面进行了全面提升。

分布式软总线让多设备融合为“一个设备“,带来设备内和设备间高吞吐、低时延、高可靠的流畅连接体验。分布式数据管理让跨设备数据访问如同访问本地,大大提升跨设备数据远程读写和检索等性能。

分布式安全确保正确的人、用正确的设备、正确的使用数据。当用户进行解锁、付款、登陆等行为时系统会主动拉出认证请求,并通过分布式技术可信互联能力,协同身份认证确保正确的人;HarmonyOS 能够把手机的内核级安全能力扩展到其他终端,提升全场景设备安全性,通过设备能力互助,共同抵御攻击,保障智能家居网络安全;HarmonyOS 通过定义数据和设备的安全级别,对数据和设备都进行了分类分级保护,确保数据流通安全可信。

赋能设备厂商,HarmonyOS 用软件定义新设备

当前,智能家居设备大多数面临联网率低、APP 安装率低、服务触达率低三座大山的困境。但在发布会中我们看到,华为已经与美的、九阳、老板等设备厂商达成了合作,搭载 HarmonyOS 2.0 的智能家居设备为我们带来了不一样的体验。当走进厨房,用手机碰一碰蒸烤一体机,极速设备联网,再也不担心设备不在线;手机碰一下料理机,分分钟实现无屏变有屏,还能结合智能手表,根据运动健康信息智能推荐最佳菜谱;碰一下抽油烟机,服务直达手机,清洗维修一站式服务更无忧……这样的体验,还会担心“智能设备不智能”吗?

面对广大的设备厂商,HarmonyOS 通过 SDK、源代码、开发板/模组和HUAWEI DevEco 等装备共同构成了完备的开发平台与工具链,让HarmonyOS 设备开发易如反掌。设备厂商可以选择不同的方式加入全场景智慧生态:通过使用分布式 SDK,已经有 1200 万+设备,获得畅连、HiCar等7大能力快速接入;此次发布会后,30+ 品类的 128MB 以下 IoT 设备整机也可以使用开源代码接入;对于 128MB 以上、4GB 以下的智能设备整机,HarmonyOS 已经通过申请定向代码开始招募伙伴加入。

为了让 HarmonyOS 智能设备开发者快速上手,HarmonyOS 为其提供了丰富的模组、开发板和解决方案。同时,HUAWEI DevEco 将为 HarmonyOS 设备带来一站式开发环境,支持家电、安防、运动健康等品类的组件定制、驱动开发和分布式能力集成。在用户开发过程中,不论设备是有屏还是无屏,HUAWEI DevEco 都可以为其提供一站式开发、编译、调试和烧录,组件可以按需定制,减少资源占用,开发环境内置安全检查能力,用户在开发过程中也可以进行可视化调试。

为了共建万物互联的全场景智慧生态,HarmonyOS 将源代码捐赠给开放原子开源基金会进行孵化,这一项目就是 OpenHarmony。目前,面向 RAM 在 128KB~128MB 的 IoT 智能硬件源代码已经开放;在明年 4 月前,RAM 在 128MB 到 4GB 间的终端设备,包括平板、低内存手机等在内的设备均可以获得相关的开源代码;到明年 10 月,HarmonyOS 源代码将会面向更多全场景终端设备开放。

应用创新升级,HarmonyOS 打造全新开发体验

应用创新是一款操作系统发展的关键,应用开发体验更是如此。在发布会中我们看到,搭载 HarmonyOS 2.0 之后,许多传统应用在开发者的手中被赋予新生。在办公室开会时,只需打开智慧屏上的 WPS 应用一扫,手机上 PPT 的材料便可快速分享到大屏,还能实时批注和文件分享;想要体验大屏多人体感游戏却苦于没设备?通过 Cocos,只需拿起华为手机便可接入智慧屏游戏,手机秒变手柄,家人同享大屏游戏;上网课屏幕太小?通过智慧屏和平板协同,VIPKid 能够让你大屏上课小屏互动,线上课堂一如现场教学。

image

完整的应用开发生态中,应用框架、编译器、IDE、API/SDK 都是必不可少的。为了赋能开发者,HarmonyOS 提供了一系列构建全场景应用的完整平台工具链与生态体系,助力开发者,轻松构筑全场景创新体验。

分布式应用框架能够将复杂的设备间协同封装成简单接口,可分可合可流转,轻松实现跨设备应用协同。开发者只需要关注业务逻辑,不必关心跨端调度与通信细节,减少代码和复杂度,大幅提升全场景体验开发效率。分布式应用框架 SDK/API 开发者 Beta 版已经同步上线,分步骤提供 13000 多个 API,支持开发大屏、手表、车机等应用。

编译器方面,HarmonyOS 采用了支持高性能多语言编译的方舟编译器。其能够消除跨语言交互开销,统一运行时;统一多语言前端,让开发者能够自由选择 Java、JavaScript 及其他语言;通过组件解耦实现多设备弹性部署;操作系统、运行时和开发框架协同设计,能够完成联合优化,提高代码执行效率。

IDE 方面,HarmonyOS 2.0 打造了全场景跨设备集成开发工具 Huawei DevEco Studio。其具有三大特色能力,在编程时开发者可以实时预览UI,实现编程所⻅即所得;提供 API 智能补全,实现高效编码;面对多设备测试难题,DevEco Studio 提供了高性能模拟仿真和实时调测。

华为面向广大开发者提供了 HarmonyOS 应用开发者官网、设备开发者官网、设备合作伙伴门户、开发者论坛 @华为开发者联盟等四大平台,持续对外发布相关技术,也让开发者们互通有无,共同陪伴 HarmonyOS 一路前行。

《孙子·谋攻篇》有云:“上下同欲者胜,以虞待不虞者胜”。 华为发布 HarmonyOS 并非仓促的决定,而是一次上下同心、准备充足的征程。 当前,已经有大批设备合作伙伴、应用合作伙伴和开发者社区合作伙伴加入了 HarmonyOS 全场景智慧生态,成为先行者。HarmonyOS 抓住了 IoT 产业崛起的历史机遇,共享先进平台,共建开源平台,同合作伙伴及开发者共同发力,共赢全场景智慧时代。

segmentfault 公众号

查看原文

赞 28 收藏 2 评论 8

Shirley娅迪 赞了文章 · 9月7日

HarmonyOS 2.0要来了!打破设备边界后,能预见多远的未来?

HarmonyOS 2.0

9 月 10 日,华为开发者大会 2020(Together)将在东莞松山湖举行。大会的官网也早早就为我们画出了今年的重点话题,鸿蒙操作系统 HarmonyOS 必然是其中最为璀璨的一个。

在 2019 年的华为开发者大会上,华为消费者业务 CEO 余承东正式对外发布了鸿蒙 HarmonyOS。过去的一年里,这个被开发者们寄予厚望却被大众“知之甚少”的操作系统,其实在不断的修炼内功。

在HDC2020 即将来临之际,我们正好可以在这个时间点来回顾一下 HarmonyOS 的过去、展望一下未来。

一、HarmonyOS 1.0:分布式技术打破设备边界

HarmonyOS 2.0

HarmonyOS 是一款面向未来的分布式操作系统。其能够支持不同硬件设备无缝接入,这正是通过分布式技术实现的。分布式技术可以解决多设备体验协同的问题,打破单一物理设备硬件能力的局限,让不同硬件之间的能力互补。往大了说就是用软件定义出新的产品形态,真正带来万物互联智慧生活的无缝衔接。

华为的分布式技术主要有四个核心点:硬件互助、资源共享;多端认证、分布安全;一次开发、多端部署;统一OS、弹性部署。

从技术实现层面来看, “超级虚拟终端”作为一个安全可信的整体,秉承的理念是让正确的人,通过正确的设备,正确地使用数据。在连接能力上,各设备间通过多智能终端间的高速公路 ——“分布式软总线”进行互联;为了降低开发者在“超级虚拟终端”上的分布式开发难度,华为提供了一次开发多端部署解决方案,仅需要开发一次代码,选择合适的运行设备,就可以实现跨设备的应用程序开发;统一OS、弹性部署技术,也为设备开发者提供了全套软硬件的技术方案。

从应用层面来说,分布式技术提供的能力就是打破多终端之间的硬件界限,把不同设备的硬件差异对应用进行屏蔽,让各终端硬件之间实现硬件互助,资源共享,进而实现在各个场景下充分发挥每个智能设备的能力,让万物互联体现出真正的价值。

分布式技术作为实现全场景数字生活服务的关键技术,即是HarmonyOS背后的“硬核武器“,也是华为正基于丰富的智能终端产品、超过7 亿终端用户并投入大量精力发展的技术方向。

二、发展中的HarmonyOS:面向未来追逐生态扩张

提到发展就一定离不开生态这一话题。

HarmonyOS 发布之初,定位就是一款面向未来、面向全场景的分布式操作系统,其不仅包含了华为的全场景终端产品,还可以支持各种 IoT 设备。覆盖范围如此之大,在发展 HarmonyOS 生态的道路上,华为没有选择也不可能一个人去战斗。

良性的产业发展,一定是开放与协同替代掉封闭和割裂,而华为想要做的正是如此。华为的产业主张就是开放、共建生态,在持续拓宽生态边界的同时,也在和全产业链上下游的生态伙伴一起探索全新的行业模式。

华为消费者业务 CEO 余承东在近期的一次会议中表示,华为在技术研发中投入巨大,经历了艰难的过程,现在华为将在智慧全场景时代发力,在操作系统、芯片、数据库、云服务、IoT 等标准生态逐渐构筑新能力,余承东说道,只有根深叶茂,才能让生态发展。

但无论软件还是硬件,构建与落地都需要整个生态的共同努力。华为在过去的一年中进行了很多成功的尝试,这也给了其自身和行业更多的信心。

另一方面,打造一款成功的操作软件最难的部分并不是研发过程,同样也是生态的打造。虽然华为是全世界唯一具备云、管、端、芯打通的公司,但如果没有吸引消费者的软件应用生态,操作系统和相关的硬件设备做的再棒也会被束之高阁。

因此,华为将过去多年在 ICT 领域积累的经验和核心技术免费向开发者开放,并以此聚集起来更多的开发者、合作伙伴和用户,也为产业的发展注入了新的源动力。因为开放,所以强大,所以让HarmonyOS 的生态建设在一年内取得长足的发展,也让我们更加期待,即将到来的 HarmonyOS 2.0 能给行业带来哪些新变化。

三、HarmonyOS 2.0:创新体验的未来探索

HarmonyOS 2.0

根据各种层面的消息来看,此次华为开发者大会2020上可能会推出 HarmonyOS 2.0,那HarmonyOS 2.0 有哪些值得期待的创新与升级呢?

首先是我们提到的分布式技术。相信通过一年时间的技术落地实践,在即将到来的 2020 华为开发者大会中,分布式技术一定也会相较之前在能力和服务两方面进行全面的升级。

其次会是各类分布式设备在不同应用场景中的互联互通。在硬件产品接入 HarmonyOS之后,是否会有新的生活场景实现互联互通?在医疗、工业、农业、交通等各个大的行业层面来讲,是否会有新的的解决方案?在平衡用户的刚性需求面前,HarmonyOS的分布式安全能力是否会有更大的提升?这些很快就可以见分晓。

另外,便是HarmonyOS相关的技术链路升级。在HarmonyOS 1.0的技术体系中,还包含方舟编译器、分布式软总线、多终端开发IDE等硬核技术与能力,这些技术在过去的一年中均有不同程度的迭代与更新,当这些改良后的技术产品再次聚集,全新的Harmony 2.0,绝对会让我们再次眼前一亮。

站在现在的时间节点来看,HarmonyOS 正如预期的一样,慢慢地走着一条独特的道路。软件和硬件存在很大的不同,软件的发展和落地相较硬件有着明显的滞后性。再强大的软件能力更新也需要一年或者两年的时间来推广、被大众接受。HarmonyOS 具备的能力在业内人士来看绝对是一个“面向未来”的产品,面前的想象空间也非常巨大。

作为一年一度秀肌肉的时间,期待HarmonyOS 2.0 给我们带来更多的惊喜,但也希望华为在特殊时期可以抗住压力,稳扎稳打,为消费者提供更好的服务和产品、为行业生态创造更多的价值。

segmentfault思否

查看原文

赞 7 收藏 1 评论 3

Shirley娅迪 关注了标签 · 9月4日

关注 19

Shirley娅迪 赞了文章 · 8月15日

开源这么难,怎么办?8月16日Apache给你答案

clipboard.png

欢迎各位开发者到现场参加活动,讨论如何解决开源过程中的实际问题,点击下方报名链接报名吧!https://www.bagevent.com/even...

ALC是Apache Local Community的缩写,是全世界范围的 Apache 开源爱好者本地群组。因为是本地组织,ALC 是按照城市或地区的方式进行划分的,类似的机构还有 GDG (Google Developer Group), Facebook Developer Circles, Mozilla Reps 等。任何 Apache 开源爱好者都可以代表自己所在的城市向 ALC 提出申请创建本地的组织。

作为全球最大开源消费国, ASF 在国内有广泛的群众基础,如何将这些开源项目用户发展转换成为社区的贡献者、开发者, 甚至成为开源项目的发起者、维护者是一个值得深思的问题。

基于对这个问题的思考,我们创建了 ALC-Beijing,并且致力于通过(但不限于)下述行动帮助开源爱好者更好的在 Apache 社区生根发芽:

  • 举办线上和线下沙龙,将本地的开发者与用户聚焦在一起。
  • 通过分享开源开发经验,鼓励更多的人参与到 ASF 的项目开发中来。
  • 为 ASF 的项目寻找相互合作的机会,让这些项目能够更加茁壮的成长。
  • 介绍 ASF 管理和运作开源项目的成功之道,帮助大家更好地运作开源项目。

然而,在8月16日,ALC Beijing的首次线下沙龙就要举办了。SegmentFault 思否作为一个纯粹的开发者社区,一直非常重视开源文化以及开源生态的传播与建设,本次作为合作媒体,诚邀社区开发者参与本次会议,共同打造开源生态,解决开源过程中的实际问题~

倒数第1天,我们一起认识一下在开源界叱诧风云的圆桌嘉宾们。

clipboard.png

clipboard.png

clipboard.png

clipboard.png

clipboard.png

圆桌探讨的问题:

1、什么契机参与到开源项目当中?
2、刚开始参与开源Community,遇到过什么困难?是如何解决的?
3、Apache社区/项目和非Apache开源Community/项目 有何异同?
4、作为开源Community里的老司机,觉得参与或推动开源Community的最大难点在哪里,为什么?可否有解决之道?
5、为何你的项目选择加入 ASF? Apache社区/项目和非Apache开源Community/项目 有何异同?
6、加入 ASF 之后,在项目和个人成长有什么不一样的地方吗?
7、如何打造自身的开源Community影响力?


欢迎来到现场提问,点击下方报名链接,一起加入讨论吧!
https://www.bagevent.com/even...

图片描述

查看原文

赞 8 收藏 0 评论 0

认证与成就

  • 获得 0 次点赞
  • 获得 0 枚徽章 获得 0 枚金徽章, 获得 0 枚银徽章, 获得 0 枚铜徽章

擅长技能
编辑

(゚∀゚ )
暂时没有

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 2月26日
个人主页被 103 人浏览