首 页
网站建设
微信商城
功能定制
资讯中心
常见问题
行业知识
新闻动态
联系我们
关于我们
服务热线：
13215994088
服务热线
13215994088
您当前的位置：
网站首页
> 资讯中心
资讯中心
新闻动态
行业知识
常见问题
资讯中心
更多 >
21
2017-06
Web开发在过去20多年时间里如何改变了我
web改变了，因而我的技术堆栈也变了。貌似我的堆栈变回到了roots。 20年前，我从HTML和JavaScript开始，再到使用VBScript的经典ASP。 2001年，我开始陶醉于ASP.NET和VB.NET，并用到了产品中，直到2006年底才不再这么干。2007年年底，我开始使用C#编写ASP.NET。HTML和JavaScript仍然参与其中，但多多少少被封装在第三方控件中，并且jQuery当时是JavaScript的别名。JavaScript的一切都是jQuery。ASP.NET WebForms感觉巨大又不是很灵活，但它能有效工作。后来——2010年——我用Silverlight、WinForms和WPF做了很多东西。 ASP.NET MVC出现了，web这个东西开始再次比ASP.NET WebForms感受更自然点。从一个ASP.NET开发人员的角度来看，web开始变得更好：更加干净、灵活、轻便和自然。 但也出现了一些新的东西。一些来自于ASP.NET世界之外的东西。强大的JavaScript库，如KnockOut、Backbone，以及后来的Angular和React。第一个单页应用程序框架(对不起，我不想提蹩脚的ASP.NET AJAX…)出现了，UI逻辑从服务器转移到了客户端。(好吧，我们确实在2005年搞回了一个很酷的SPA，但我们没有想过如何用它创建一个框架。) NodeJS通过在服务器上使用JavaScript再次改变了世界。你只需要两个不同的语言(HTML和JavaScript)，就可以来创建很酷的web应用。我不怎么对NodeJS感兴趣，除了在后端使用它，因为一些工具基于NodeJS。也许这是一个错误，谁知道呢; ) 现在我们有了ASP.NET Core，这感觉比传统的ASP.NET MVC更自然得多。所谓的自然在这种情况下，意味着和编写传统ASP的感觉几乎相同。这也就是说使用无状态的web工作，而不是试图修复它。使用Request和Response比传统的ASP.NET MVC工作起来更直接，比ASP.NET WebForms甚至就更直接得多。自然并不意味着你必须编写和传统Asp同样非结构化的废话。 ; ) 由于我们已经有了非常酷的客户端JavaScript框架。和简化了的、简约的服务器端框架，服务器部分就被减少到仅仅用于在REST服务上提供静态文件和数据。 正是这个时候，深入了解TypeScript变得有了意义。但是到这个时间点为止，它对我还没有意义。我用JavaScript编写代码大概有20年时间，但我从来没有在单个项目中写过这么多的JavaScript代码。之后，在过去几年时间里我开始使用AngularJS。Angular2是应该好好研究TypeScript的一个原因，因为现在的Angular2完全是用TypeScript写的。 几个星期前，我启动了我第一个真正的NodeJS项目：一个使用NodeJS来为用户提供高度灵活脚本运行时的桌面应用程序。NodeJS提供功能和UI给用户，所有都是用TypeScript写的，而不是普通的JavaScript。为什么?因为TypeScript有很多意想不到的好处： - 仍然可以编写JavaScript - 帮助编写小的模块和结构化的代码 - 帮助编写NodeJS兼容模块 - 一般说来，不需要为每个模块写所有的JavaScript代码 - 只要专注于所需要编写的功能 这就是为什么TypeScript对我来说是个大帮手。当然类型化的语言在很多情况下也是有用的，但是——使用JS工作了20年——我喜欢隐式的类型JavaScript语言的灵活性，并且我对它很熟。这意味着，从我的角度来看，有关TypeScript的优点是，我仍然能用TypeScript编写隐式的类型代码，并利用到JavaScript的灵活性。这就是为什么我说“仍然可以编写JavaScript”的原因。 Web技术改变了，我的技术堆栈也改变了，工具也是。所有这些东西都变得更为轻巧，连同工具一起。控制台回来了，IDE变回为它们的root：只不过是一些有着类似语法高亮和智能感知这些作用的文本编辑器。目前，我更喜欢根据我工作的项目类型使用有着“瑞士军刀”之称的Visual Studio Code或Adobe Brackets。两者都开始变得非常快速，包括一些不错的功能。 使用轻便的IDE令人愉悦。一切都很快，因为通过我需要开发的app可以使用机器的资源，而不必通过我需要使用来开发app的IDE。这使得发展速度快了很多。 现今启动一个IDE意味着启动cmder(Windows上我最喜爱的控制台)，改变项目文件夹，启动控制台命令，从而查看typescript文件，保存后编译。我可以启动另一个控制台来使用如NPM、gulp、typings、dotnet CLI、NodeJS等工具;以及启动我最喜欢的轻量级编辑器来编写代码! : )
21
2017-06
测试代码时你会犯的 11 个错误
1.没有测试 我们很容易毫无原因地掉入这个陷阱。从现在开始，制定计划添加测试到你现在正在处理的代码中，并添加测试到将来的项目中。 2.没有从项目一开始就启动测试 我们很难再回过头去添加测试，并且可能需要改变架构才能添加测试，这样做最终将需要你花更长的时间才能产出可信任的代码。从一开始就在项目的生命周期添加测试可以节省时间和精力。 3.编写失败的测试 TDD方法的普及将红—绿—重构的理念带到软件测试世界。这个理念常常被误认为应该“通过编写一个失败的测试开始”。其实并非如此。在写代码之前创建测试的目的是定义系统的正确行为应该是什么。在许多情况下，它是一个失败的测试(红色表示)，但它可能会通过一个非决定性的或未实现的测试来表示。 4.担心未实现测试 软件开发中的一个大问题就是，代码和任何关于系统实际上应该做什么的文档之间的沟壑。通过拥有一个名称中明确定义你最终想要实现的预期行为的测试，你将从测试中得到一定的价值，即使将怎么写测试目前还不得知。 5.没有很好地命名测试 命名软件这件事出了名的很难做好，这同样适用于测试。关于如何命名测试有几种流行的约定。无论你使用哪一种都没有关系，只要你能够一贯使用，并准确描述正在测试什么。 6.让测试做太多事情 又长又复杂的名字通常说明了你想同时测试多件事情。单个测试应该只测试一件事情。如果失败了也应该在代码中注明是什么地方出了错。你没有必要为了知道代码中出了什么问题而查看是哪部分测试失败。这并不意味着你不应该在测试中有多个断言，但这些断言应该紧密相关。例如，一个查看订单处理系统输出，并确认输出中是否有一个单一项目以及它是否包含具体项目的测试，是ok的。但一个验证相同系统的输出的测试，既创建一个特定项目，又记录到数据库中，还发送确认电子邮件，就不行了。 7.没有实际测试代码 经常可以看到测试新手创建过于复杂的模型以及不能实际测试代码的设置程序。他们可能会验证模拟代码是否正确，或者模拟代码是否和真正代码做相同的事情，或没有任何断言而只是执行代码。这样的“测试”都是白费力气，特别是如果它们的存在只是为了提高代码覆盖率水平的话。 8.担心代码覆盖率 代码覆盖率的理念很崇高，但往往实际价值有限。知道运行测试的时候有多少代码被执行应该是有用的，但因为它不考虑正在执行代码的测试的质量，因此就变得没有意义。代码覆盖率在它数值非常高或非常低的时候，是挺博人眼球的。如果非常高，就表明，比起带来的价值，过多的代码可能正在被测试。非常低的代码覆盖率表明有可能代码的测试不够。因为这样模棱两可的意思，有的人就不知道单一片段的代码是否应该进行测试。我用一个简单的问题来明确这一点：代码是否包含重大的复杂性?如果包含，那么你需要一些测试。如果没有的话，你就不需要。测试属性访问器不过是浪费时间。如果它们失败的话，那么比起你正在写的代码，你的代码体系出现了一些更根本的问题。如果你不用看一段代码，就立即知道一切，那么它就不重大。这不仅适用于代码，也适用于你写代码。如果我们在任意点重访代码，那么它就需要测试。如果在现有代码中发现过bug，那就说明这一块的代码对其复杂性没有进行充分的测试。 9.着眼于一种类型的测试 一旦你开始测试，很容易只纠结于一种风格的测试。这是一个错误。只用一种类型的测试，你就不能充分测试系统的所有部分。你需要单元测试来确认代码的各个组件是否能够正确工作。你需要集成测试来确认不同组件是否能够协同工作。你需要自动化UI测试来验证软件是否可以如预期使用。最后，你需要为任何不容易自动化的部分和探索性尝试进行手动测试。 10.着眼于短期测试 来自于测试的价值大多数会随着时间的推移而获得。测试不应该只存在用于确认事情是否正确写入，而应该随着时间的推移继续起作用，并且对于代码库做其他的改变。有回归错误或新的异常，那么测试应该重复运行以尽早发现问题，这将意味着错误和异常可以更快，更便宜和更容易被修复。没有变化(人为错误)可自动和快速执行的测试，是为什么编码测试如此有价值的原因。 11.作为一个开发者，依靠于别人来运行(或编写)测试 如果不运行，那么测试几乎没有价值。如果测试不能被运行，那么就可能遗漏bug。自动运行的测试(作为一个持续集成系统的一部分)是一个开始，但项目的任何一个人都应该能够随时运行测试。如果需要特殊设置，机器，权限，或配置来运行测试，那么这些将成为执行测试的壁垒。开发者需要能够在检查代码之前就运行测试，因此他们需要能够访问并有运行所有相关测试的权力。代码和测试应保持在同一个地方，并且所需的任何设置都应该写好脚本。关于这个方面我见过的最坏的例子是一个做的很糟糕的项目，在这个项目中测试人员的子团队定期取走开发人员正在处理的代码副本，他们修改代码以便他们能执行一系列测试，但这些测试是开发人员在特殊配置(无证)的机器上所无法访问的，然后测试人员再发送一个很大的邮件给所有的开发人员以说明他们找到的问题。这不仅是一个坏的测试方式，而且也是团队工作的糟糕方式。不要这样做。代码能够正确执行是专业开发人员的部分属性。要保证代码的准确性，方法是使用伴随它的适当测试。依靠其他人为你写的代码编写测试和运行测试，不会帮助你成为一个专业的开发人员。 如果以上这些都不属于你的情况，那么恭喜你!继续保持开发稳健又有价值的软件。 如果上面有一些确实发生在你身上，那么是时候做一些改变了。
21
2017-06
谷歌等公司重写OpenStack生命周期管理工具
虽然 OpenStack 已经成为受欢迎的开源云软件堆栈，但是另一方面，它的 DevOps 项目 Fuel 却在赢得用户方面遇到难题。现在，谷歌、英特尔和 Mirantis 正在重写以利用 Kubernetes 作为底层调度引擎。 聪明之举! 从 Fuel 原设计者的方方面面来看，这个工具从来就没有崛起。另一方面，Kubernetes 已经拥有了很多用户。 正如大多数人所知，Kubernetes 是一个容器管理和 DevOps 项目。在 OpenStack 上，Kubernetes 部署将利用 Docker 容器。基于 Kubernetes 的 Fuel 将提供单一平台让虚拟机、容器、裸机系统动态地控制 OpenStack 操作和生命周期管理。 该计划是提供一个持续集成/持续交付(CI/CD)通道。新的 Fuel 将让用户可以精细地控制服务部署和管理，可以推出更新，并让 OpenStack 控制面板能够自愈且更有弹性，而且这还将让创建基于容器的应用路径更加平滑。 这业界三巨头并不是第一次提出这个观点。Mirantis 和 CoreOS 从去年就开始致力于这个方向了，当时他们将 Kubernetes 引入了 OpenStack。这是该计划自然而然迈出的下一步。 毕竟，作为 Mirantis 首席运营官 Boris Renski 在声明中称：“随着 Docker 的兴起成为标准的容器图像格式，Kubernetes 成为容器调度的标准，我们终于看到人们处理分布式应用操作方式上的持续性。将 Kubernetes 与 Fuel 结合起来，这将打开 OpenStack 的一种新交付模式，让更新消耗地更快，帮助客户更快地得到结果。” 到目前为止，谷歌都还不是主流的 OpenStack 玩家，现在它也加入了 OpenStack 阵营，正如谷歌高级产品经理 Craig McLuckie 说：“在 Fuel 中利用 Kubernetes 将把 OpenStack 变成一个真正的微服务应用，弥合传统基础设施软件和下一代应用开发之间的差距。从使用容器和先进的集群管理作为实现弹性的、高度可扩展的基础设施打下基础，这将让很多企业受益。” 这是否有助于加速 OpenStack 的部署?我当然希望如此。OpenStack 是一个非常强大且有用的云计划，但也存在难以部署和维护的缺点。我认为将 Fuel 和 Kubernetes 结合起来正是 OpenStack 需要的。
21
2017-06
「能写代码」是愚公移山，「会写代码」是女娲补天
之所以提这个话题，跟前两天在微信群里的讨论有关，年后本该是跳槽、找工作的高峰月份，各公司面试邀约应该很多，但是听群里的反馈却是不太容易。从行业发展角度看，移动互联网连续火爆数年，已逐步走向稳定;从国家发展形势看，从去年开始，整个国家经济形势不景气，不只失业率增多，好多移动互联网公司裁员、倒闭;从程序员职业角度看，现今「挨踢」培训机构屡见不鲜，大都打着包学包会包分配，三俩月速成的口号忽悠人，导致很多学员没有打牢基础，就匆忙走上岗位，而且培训机构过分鼓吹使得学员们没有真正认清自身实际，没有正确定位! 建议大家这段时间不要裸辞，边工作，边寻找机会才是最好的选择。「裸辞」倘若一时找不到工作可能会导致心慌，没有安全感，甚至会产生「自我怀疑」和「自我否定」!如果在职场暂时迷茫也不要心慌，因为只有经历过了痛苦和绝望之后，才能够「浴火重生」，找到方向。 从本质上区分，一个是被动，一个是主动 由于近几年来移动互联网行业实在火爆，程序员这条路已经由10年前的「羊肠小道」，修成了「康庄大道」，跟高速公路似的，但是还是挤，拥挤的跟北京早晚高峰的地铁似的，涌入的人越来越多，感觉门槛似乎很低。很多人看准了计算机行业工资高，好就业，转行当程序员。其实不然，一个行业健康的发展是因为有很多有兴趣，有爱好的人涌入，这部分人由于兴趣和爱好，喜欢钻研，想要更深入的去了解底层知识和原理，所以容易提高，这就是优秀的程序员，而大部分人是被现实所逼迫，从而选择了一个职业，逼迫往往而导致被动，时间久了就会变得平庸。中国有句俗语叫「心随我动」，一旦从事了这个行业，时间久了，差距就会慢慢拉开，所以优秀和普通从根本上就有差别。 从能力上分，一个是搬运工，一个是设计者 「能写代码」是愚公移山 为什么说能写代码是愚公移山呢?我们中国大部分程序员都应该处于一个初级程序员的水平，怎么讲?只有少数的程序员处于中高级水平。愚公移山就是愚公为了有一条近道(可以形容为生存)，而不停的去挖山，子子孙孙重复的去做同一件事，就像我们编程，如果你一直在公司重重复复的当代码搬运工，天天就会写界面，这就是能写代码!即使你有10年的工作经历，但是经验就是刚当程序员那一年!十年如一日的做同一件事，你确实足够坚持，也不否认你有爆发的那一年，就像愚公一样需要中彩票的几率依靠两个大神帮你解决问题。 能写代码是一个基础水平，初级能力，要想走的高，看的远，不要「安于现状」，勇于攀岩和破冰，才能改变世界。中国现在的基础情况是不缺乏初级程序员，而是缺乏大部分中高级程序员，这就是为什么大部分公司在招聘的时候为什么喜欢3到5年工作经验的程序员了，喜欢归喜欢，这个限制只不过是提高了他们能招聘到中高级程序员的几率罢了，毕竟「十年如一日」的程序员占据了市场的大部分。 「会写代码」是女娲补天 女娲补天?这又怎么讲?优秀的程序员就像女娲一样，拥有极其强大的能力，不仅仅可以探索和创造，也能及时出手，写出如五彩石一样的漂亮，严谨的代码去补天，堵上天一样的大窟窿和大漏洞，还人类一个美丽的「天上人间」，保持程序「完美运行」。如果人间恶魔兴起，扰乱民心，她可以有的放矢，一招制敌。优秀的程序员就是如此，他不仅仅是能写代码，而是会写代码，这种高境界的水平，不仅仅是有经验，经历过大大小小的崩溃战争，而是在制敌中探索和学习，如何保卫程序稳定生长和运行，把恶魔消灭在萌芽般的象牙塔之内! 会写代码就是如此，他知道怎么去搭建架构，构建地基，把恶魔封印在程序之外。优秀的程序员会写代码更是会一直保持在「深度学习」之中，白天打仗提升实力，晚上「闭关修炼」提高自己。使自己打造的天上人间如仙境一般，越来越美，偶尔来了雾霾，也会如女娲补天一样，能轻松得召唤到西伯利亚的寒风，把它吹走。 总结：会写代码和能写代码的差距就是 - 我喜欢闭关修炼，你满足安于现状 - 我是兴趣驱动型，你是迫不得已型 - 同样都是坚持，我是坚持学习，你是坚持复制 - 我追求的是长远进步，你疲于奔命的挣钱(挣钱没有错，错的是眼光) 差距就是在这些不经意的细节中拉大的。你感觉复制粘贴完成任务就行，人家想的是如何更好的写出代码，提高效率。你按部就班，日复一日的使用同样的方法，人家总想着学习和进步，使用最新的技术完成功能，两年之后，你还是只会一种落后的方法，人家却是用更好的方式完成了任务，你这时可能感觉没什么?假如一年之后，官方突然宣布，不再支持你的旧方法，你是否会「怅然若失」?而人家可能会「欣喜若狂」的在想：那个破方法，早应该被淘汰了。你说不急，我现在再重新开始学习， 殊不知一大批使用新方法的毕业生正在来袭，而前卫的学习者说不定又在探索更新的技术。这就是这个行业现状。 最近在看书，不说了，说多了都是泪，我也是仅仅处于「能写代码」的水平。要努力!要争取向「会写代码」的方向努力!今赋此文，纯属有感而发，希望能与大家共勉。
21
2017-06
职场新人晋升全栈工程师的通关秘籍
什么是全栈工程师 全栈工程师一词，最早出现于Facebook工程师Calos Bueno的一篇文章 - Full Stack (需翻墙)。他把全栈工程师定义为对性能影响有着深入理解的技术通才。自那以后全栈这个词便流行起来，我看到过的就有全栈工程师，全栈设计师，全栈运维，全栈市场营销人员等等。而在很多针对互联网人才的招聘网站上，全栈工程师更是一跃成为热门招聘职位，其薪资水平也比一般的开发工程师职位要高出一截。那么，什么是全栈工程师，我们又应该如何定义一名全栈工程师呢? 百度百科对全栈工程师的定义是这样的：“掌握多种技能，并能利用多种技能独立完成产品的人”。我觉得这个定义还不够全面，我认为全栈工程师应该同时是一位资深开发工程师、架构师以及具有敏捷开发技能的程序员。全栈工程师对于软件开发的认识往往已经进化了，他们把特定的技术抛到了身后，明白技术的更新始终比计算机理论要快的道理，因此，他们注重强化自身的核心技能，关注并乐于实践其他技术。全栈工程师往往是某一方面的专家，同时通晓并善于在正确的场合运用其他语言、工具和技术。 全栈工程师的价值 随着时间的推移，全栈工程师的作用和价值在越来越多的产品或项目中得到了印证。那么，我们来看看全栈工程师对于个人或公司意味着什么。 - 个人价值及自由度的极大提升 —— 我曾看过一些介绍全栈工程师的文章，文中大多强调了全栈工程师对于公司与团队的价值。而我想说的是，没有一个优秀的全栈工程师是因为会对公司产生多大的利益，而努力学习各种技术的。我所认识的他们，都是那些有着一颗匠心，不断追求更高技能，并执着于做出更优秀产品的人。而当你成为一名真正的全栈工程师后，会感受到前所未有的个人价值与技术自由度的提升。试想当一个很好的创意出现时，你可以一个人或主导一个团队去实现并不断完善它，这是一件多么让人兴奋的事啊! - 全局思维与技术前瞻性 —— 由于具备了各个开发环节与技术领域的知识，全栈工程师往往具有更好的大局观和技术前瞻性，能够在项目初期就选择正确的技术，并很好地把控一个项目的整体方向。现代项目往往非常复杂，而全栈工程师往往能带来技术和质量上的保障，从而成为一个项目成功的关键人物。 - 降低沟通成本 —— 我经常听到有设计师抱怨前端工程师无法百分之百地还原他们的设计，而前端工程师又在抱怨后端工程师从接口返回的数据更本无法直接使用，后端工程师也在抱怨产品经理所提的需求根本无法完成。随着团队人数的上升，由于各自技能栈的不同，沟通成本一定会随之上升。全栈工程师除了能够独立完成前后端的开发(甚至包括设计)外，如果能够在项目初期提前介入，便能很好地规避技术风险，过滤不合理的需求，从而显著降低因不同技术差异导致的沟通问题，显著降低项目风险。 - 初创公司 —— 我们已经来到了一个万众创业，全民创新的时代。那些初创公司也如雨后春笋般不断涌现。初创公司往往都有了一个不错的创意，但经常会遇到“就缺一个程序员”的尴尬。我想说的是，他们其实并不是缺程序员，而是缺一位全栈工程师。初创公司往往资金有限，而一名优秀的全栈工程师能够帮助初创公司用最低的代价与最短的时间推出自己的产品。这是初创公司能够存活下来，拿到更多投资，甚至成为“独角兽”一员的最关键一步。 全栈工程师的技能栈 看到这里你一定会问，到底需要具备怎样的技能才能成为一名全栈工程呢?下面这张图来自Medium，作者将软件开发所涉及的各个方面分为层，又将每个层所包含的主要技术作为组件，制作了这张全栈技术图。 从上面这张图，我们不难发现，现在的技术体系是多么庞大，每一年又会有新的技术加入到这些层中，而已有的技术又在不断地更新。因此要掌握所有技术是根本不可能的，而成为全栈工程师也并不需要你真的掌握所有的技术，你应该将自己的精力聚焦于关键开发技能以及一些必须掌握的附加技能上。 关键开发技能(硬实力)： - Git / GitHub —— 你必须掌握如何使用Git来管理和分享你的代码。把Git作为关键技能的第一条，是因为它不仅仅是一个代码管理工具，更是一种推荐的工作方式。它使你能在任何地方进行开发，高效地管理任何大小的项目，通过Git你还能与其他团队成员进行分布式协作，大大提升工作效率。通过GitHub，还能将你与世界所有的开发者联系在一起。 - 至少一门编程语言 —— 你需要精通至少一门编程语言，JAVA 、PHP、C#、Python、Ruby、Perl 等，因为你的大多数核心业务处理都需要用这门语言来写。你既要掌握这门语言的语法，又需要非常熟悉如何基于这门语言进行项目的架构、设计、实现以及测试。如果你选择的是JAVA，那么你就需要掌握面向对象的设计和开发，设计模式的应用，基于J2EE各个组件的开发 等等。 - 运用开发框架和第三方库 —— 流行的开发语言，一般都伴有出色的开发框架，比如JAVA的Spring、MyBatis、Hibernate，Python的Django，PHP的 thinkphp、yin，nodeJs的 express 等等。这些开发框架往往都遵循软件开发领域的一些最佳实践，并由非常优秀的开发人员创建。熟练使用这些开发框架或第三方库能够避免重复发明轮子，使你的工作事半功倍。更重要的是这些优秀框架或第三方库的一般都得到持续的维护，是对你的产品或项目在质量与安全方便的最有效的保障。 - 前端技术 —— 之所以将前端技术独立出来，作为一项关键技术，是因为它在今天的项目和产品的研发过程中正变得越来越重要。一个产品除了实现所需的功能之外，是否好用(用户体验)也正在成为评判一个产品是否成功的重要标准。而这都依赖于前端技术的实现，你至少需要掌握 HTML5、CSS3、JavaScript 等基本前端技术，同时进一步学习 JQuery、LESS、SASS、AngularJS或REACT等前端框架或第三方库。 - 数据库与缓存 —— 任何产品或项目都需要一个数据库来存储数据。作为全栈工程师，你也需要至少掌握一到两个数据库，并知道怎样与数据库进行交互。目前流行的数据库主要有MySQL、MongoDB、Redis、Oracle、SQLServer等。MongoDB作为文档型数据库，在互联网产品中正被越来越多地使用，对于规模稍大一些的项目，我仍推荐使用MySQL或商用的Oracle作为后端数据库。而Redis这样的内存数据库则可以用于缓存，以提升系统的性能。 - 基本设计能力 —— 大部分关于全栈工程师的文章或讨论中，都不会将设计能力做为全栈工程师的关键技能，但我却认为这项技能非常重要。我曾被邀请评估一些软件工程师自己开发的产品，这些产品都有不错的创意，功能实现也很到位，但一看就不是一个好的产品，用户根本没有使用欲望，原因是这些产品的设计太差了，而往往那些开发者完全没有意识到问题的存在，比如色彩的不一致，排版的凌乱，不恰当的图标 等等。我所建议的基本设计能力，并不要求你像专业设计师那样能够P出神图、制作奇妙的视觉效果等，但你需要掌握最基本的UI设计原则，如 色彩的搭配，基本的排版，并具备良好的审美能力，和一些基本UI设计能力，这样你做的产品就不会太差了。 在掌握了这些核心技能之后，你可以根据自己的兴趣与发展方向，学习其他方面的技术。比如，如果你对数据处理感兴趣，那么你可以学习大数据方面的技术。如果你对移动互联网更感兴趣，那么你可以学习Swift，开发ios应用。知识总是相通的，在有了良好的技术基础后，学习其他知识将会变得非常容易。 附加技能(软实力)： - 沟通 —— 除非你是在做个人项目，对于稍大一些的项目，你总是需要与同事、干系人或是客户进行沟通的。而成功的沟通往往是获得有效需求，与建立团队信心的第一步。在项目的进行过程中，你更需要通过有效的沟通去确定方案，消除误解，与项目成员协同前进。良好的沟通能力将使你在团队中更具影响力，收到更多尊重和关注。 - 问题解决能力 —— 全栈工程师首先是一名工程师，他必须掌握工程化的方法来解决遇到的各种问题。我在职业生涯中的几乎所有亮点，都与解决问题相关，大到提供整个项目的架构方案，小到以最快的速度解决生产问题 等。其实有很多提高问题解决能力的方法，但没有一种比实践更有效。我所见到的优秀工程师，往往能够凭借直觉以最短的时间给出正确的解决方案，但你可能没有看到的是，在这背后其实是经过大量实践累积而来的经验。 - 时间管理 —— 作为全栈工程师，你可能会被安排同时在不同的项目中承担不同的角色。你需要合理地分配时间，保证所有的工作能够按时交付。同样在你的业余时间，你还需要花时间阅读和学习，同时你还可能会有自己的Side Project。因此，合理地进行时间分配，并对一些关键任务，进行计划是很重要的。你或许会感到一些压力，但这反而会激发你的创造力，并能让一切都有条不紊地进行。 - 好奇心 —— 对任何工作都抱有好奇心，并愿意不断学习和改善是那些优秀工程师的共同特性。软件开发领域汇集了世界上最聪明的人，各种类型的技术、产品、框架更是日新月异，层出不穷。优秀的全栈工程师需要不断地学习来抓住这些变化，跟上计算机领域发展的脚步。时常有人会问我，做计算机这一行一直会有新的东西产生，要去不断地学习，是不是会很累。我要说的是，对于将持续学习作为一种生活习惯的人来说，学习新东西并不会成为一种负担，反而是一种乐趣。 - 领导力 —— 优秀的全栈工程师往往会被赋予技术Leader甚至项目管理者的角色。成为管理者并不是让你去支配其他人，或让其他人替你做事。管理者需要理解你的团队成员的长处与不足，并知道如何以服务的态度使团队获得最大化的产出。我见过一些非常优秀的工程师，当他们被安排去管理团队时，他们是排斥的，他们往往更愿意独自工作。但我想说，成为管理者，将会使你更加睿智、可靠和值得他人信赖，也会对你未来的职业生涯带来极大的益处。因此，当机会到来时，请将它视为挑战，不要排斥它。 - 有经验的技术领导者在招聘时，往往会同时考察应聘者技术能力与上述附加技能，而对于初级程序员的招聘来说，那些附加技能往往更被优秀的技术公司所看重。开发技能是你的硬实力，而附加技能则可以看作是你的软实力，只有同时具备这两方面技能，才能成为一名优秀的全栈工程师。 优秀的全栈工程师需要走出去 优秀的全栈工程师不应局限于自己的工作，他更应该走出去，接触不同的技术，分享自己的经验和心得，认识更多的朋友。下面便是我的一些做法。 - 参加技术大会 —— InfoQ、CSDN、GITC、优设、TED 等网站都会定期举办各类技术大会。在这些大会上，你不仅能够听到技术大咖们带来的各自领域最佳技术实践，而且能认识很多行业内的朋友。这对你开拓思路，扩大技术社交圈都很有帮助。因此，如果公司没有安排你去参加这些技术大会的话，那就自己买票参加，作为对自己的一种投资吧。 - 作公开演讲 —— 全栈工程师并不需要是一个公开演讲者，但作为团队的核心成员，他一定需要在团队内部做技术、管理等方面的进行演讲。如果你是一个乐于分享的技术达人，那么也可以尝试录制个人课程(视频或音频)，并在慕课、网易课堂、优酷 或 像 荔枝、喜马拉雅 等各种媒体分享自己的技能和知识，不要因为自己并不是专家就不愿尝试，相信我，你用心制作的内容，会获得大家的认可，并收获一大批粉丝的。 - 个人博客 —— 每天进步一点点，一年以后你便会获得质的飞跃。优秀的全栈工程师懂得如何进行知识的积累，而技术博客就是一个很好的方式，将自己平时的实践、思考记录下来，配以tag标签方便日后的回顾。最有意思的是，当你在不断记录和更新你的博客同时，世界各地的程序员也会通过你的博客认识你。 - 参加线下活动 —— 与以前程序员总是宅在家里不同，现在的年轻程序员们更愿意分享和交流。很多网站也会组织不同技术主题的线下活动，在这些活动中你可以听到一些技术牛人的分享，还可以找到很多和你一样对技术富有激情的人。而我现在所做的开源项目中的很多团队成员，正是我在这些线下活动中结识的。 - 全栈工程师决不是一夜练成的，你需要打好技术基础，强化核心技能，并持续学习。相信有一天你也能像我一样，感受到自由地运用技术，开发出优秀产品所带来的乐趣的。
21
2017-06
HTML5要如何达到原生性能
编者按：HTML5应用被视为让本地软件云端化的利器，HTML5游戏也被视为一片新的蓝海，然而，HTML5远逊于原生的性能让众多开发者望而却步。本次InfoQ中文站便就此问题采访了英特尔(中国)开源技术中心负责crosswalk runtime和H5优化、硬件加速的两位工程师。 InfoQ：请先做个简单的自我介绍 余枝强：我是英特尔中国开源技术中心的软件技术经理余枝强，主要负责HTML5引擎 -Crosswalk在安卓平台的开发, 以及一些新兴Web技术的研发 顾扬：我是英特尔中国开源技术中心web研发经理顾扬，负责web图形相关功能(CSS, Canvas2D和WebGL等)的实现和优化 InfoQ:大家都很期待H5达到原生性能，那么从硬件层面和浏览器层面来说，H5能否达到原生性能呢? 余枝强：其实现在轻度、中度游戏/应用如果能够通过一些全栈式的优化(包括应用层，软件库，Web引擎层)，某些场景下可能还需要一些Hybrid实现， 这样，HTML5应用接近或达到类似原生应用的性能应该问题不大。但重度、计算量大的应用(比如复杂的3D游戏，包括物理引擎等)目前确实还是有不少差距的。 我这里可以分享几个例子，它们都是一开始性能有较大的差距，但通过相应的优化性能达到了质的提升。 其中一个例子是和腾讯Alloy团队合作的，针对HTML5图像处理库的优化。原先这个图像处理库在移动端性能不理想，比如说对一副图像实现一个木雕效果需要十几秒甚至几十秒的时间(其中涉及到较为复杂的计算)，后来我们在应用里引入并行 (WebCL, 它可以利用CPU 以及GPU中的多核的能力)，通过对图像处理库相应的部分用WebCL重新实现，另外在Crosswalk引擎里加入WebCL的支持以及相应优化，最后这个图像处理时间在安卓平台上从几十秒降低到2秒以内。 另外一个例子是和触控科技合作了， 针对一个游戏-“进击的小怪物”的 HTML5版本做优化，其中涉及到比较酷炫的消除/爆炸效果，而这些效果在最新的Chrome里跑只有十几的fps 。通过引入Crosswalk 的游戏模式，把上层相对耗时的API通过原生的实现再桥接到HTML5引擎中，使得酷炫效果的性能比Chrome好5倍左右。 另外最近我们在调研一种典型的用户场景：大规模的图片的加载和滑动的性能问题， 以及和原生应用的性能区别。经过初步的调研，我们发现性能的差距有几个方面的原因：没有做更好的缓存，没有利用系统服务，不必要的事件处理，不必要数据转换，以及大量的数据缺少高效的数据传输机制，这中间有很多开销，会影响到用户体验。我们打算做一个参考实现来解决这种类型应用的性能问题。 总结来说， HTML5的性能问题，可能是多重原因组成，比如应用本身设计不合理，加了不必要的事件，没有用更好的缓存等等，另一方面引擎也可能有问题，比如数据传递，比如没有利用上更好的硬件特性。再加上Javascript语言的动态性，相对不容易写出优化的代码。这些问题，如果能够有全局的角度出发做相应优化，性能会有机会提升非常明显。另外对应用开发者来说，尽量用一些成熟的框架，最好也要对对底层引擎有一定的了解从而避开javacript 里的坑。成熟的框架相对来说已做了一些Javascript层面的优化，再通过引擎本身针对应用的场景做相应优化，同时让Web引擎更好的利用到底层的硬件能力，这些层面做好了，就容易有好的体验。 顾扬：从我的理解来说，native应用直接跟硬件打交道，web应用则是通过web引擎跟硬件打交道，多了web引擎这个中间层。正因为这个中间层，带来了一些性能差异： 1， web引擎相对native发展来说还很年轻，对CPU，GPU这样的计算资源还不能充分应用。 2，web引擎是一种通用平台，日益增强的能力也带来了日益复杂的架构和更多的overhead。当然除却web引擎带来的性能损失，JS语言本身也有一些局限性，比如数据类型不明确，不支持多进程等。我们的优化主要针对web引擎的上述两个短板： 1， 充分发挥硬件，主要是CPU和GPU的能力。比如充分利用Intel CPU的特殊指令集，GPU的特殊extension。 2， 因为我们熟悉web引擎的各个阶段，通过对典型应用场景的性能评估，了解瓶颈所在，从而优化引擎逻辑。 InfoQ:顾扬可否再详细地介绍下你们所做的优化? 顾扬：目前的很多web引擎都是基于Chromium项目。我们的优化工作基本都是直接提交到Chromium，而且跟图形相关。具体涉及的软件仓库，主要是Skia和Chromium(Blink已经跟它融合)。 Skia方面优化 : 1，很多操作还是通过CPU进行的，Intel CPU有特殊指令集，用好这些指令集会有很多性能提升。 2，我们会做图形也是因为web的趋势是越来越多地用GPU而不是CPU来渲染。移动平台的GPU能力，近年来增长非常快，很多以前只有CPU能完成的任务，现在都能用GPU完成，而且性能更好。Skia代码中有些GPU的逻辑，要么有bug，要么还不够优化，我们消除了很多这样的正确性和性能问题，从而可以顺利的从CPU切换到GPU。 3，对路径渲染的一些优化。 4， CSS的很多优化，比如transform，box-shadow。 Chromium方面优化: 1，针对特殊场景的优化。比如Canvas2D被用在轻量级应用时，一些overhead可以忽略。但当用于一些heavy的游戏，比如一帧要画成百上千的东西时，引擎的一些overhead就突然成了瓶颈。 2，针对WebGL的各种优化，比如上传canvas/video到WebGL，GPU到GPU的纹理拷贝等。 3，一些场景下DOM操作的优化。 4，针对反锯齿效果性能的优化。 InfoQ:很多游戏厂商不使用现有的引擎，可能会选择自己写一个。对于这些开发者，有没有什么可以分享给他们的性能优化方法呢? 余枝强：的确有这个现象，有很多HTML5游戏引擎厂商都是自定义的一套 API，实现上其实是完全绕过了HTML5引擎，直接调到了底层的库。开发者就围绕这些API来开发，这在某些情况下的确有更好的性能，但也丧失了HTML5的一些优势，包括通用性，以及与HTML5 API的交互能力 (比如DOM)。不过这也是一种做法，但我觉得另一种可能更好的路是把HTML5 和 原生实现更高效的融合起来， 在把HTML5 本身的优势发挥出来，把标准的API以及丰富的HTML5 库利用起来，同时也能有和原生实现类似的性能。 InfoQ:对于浏览器而言，有无什么可从Web 引擎借鉴过来的优化理念? 余枝强：这个是有的。但首先我们要理解一下浏览器和独立的Web 引擎之间的区别。比如对于浏览器，你不知会访问哪个页面，所以为了防止潜在的恶意代码，在安全方面需要做很多检查，增加额外的开销，不同的页面也需要做相应的隔离。同时，浏览器需要更通用一点，来满足不同应用的需求，而通用也就意味着不容易做一些特定的优化。而作为一个独立应用，代码是可控的，场景是特定的，相对容易做一些针对性的优化。另外，在交互方面，比如浏览器里网页前进后退、手势，这些对于独立应用是不需要甚至有冲突的，这方面也是不小的区别。 但对于基础渲染，GPU加速等，浏览器和web引擎的基本是一致的. 还有，比如说把指令级的并行如SIMD带入到Web平台，这个也是通用的。SIMD.JS最先是在Crosswalk中有完整的实现，然后变成一个web标准，目前主流的浏览器厂商比如Google/Microsoft等都在加入相应支持。 InfoQ：因为IOS上无法使用第三方runtime，所以有开发者觉得使用runtime会减少很多用户。对于IOS这个问题，有没有什么解决办法? 余枝强：对于runtime会提供打包工具，可以将H5应用可选地打包成Android或IOS应用，所以不会减少用户。 只是在IOS上实际使用的是它自身的WKview引擎，而不是我们的加速引擎。但是考虑到IOS硬件不错，自带引擎加速也还可以，所以其实IOS上的H5性能问题没那么严重。 InfoQ:CSS和DOM操作算H5一个瓶颈吧?这方面的性能优化可否再具体讲讲? 顾扬：我们在这两块做的优化不算多，主要针对一些特殊场景。比如上面提到CSS有个效果是box-shadow，计算非常耗资源。我们通过cache机制，把中间相对通用的计算结果保存下来，这样很多后续运算就不需要从头来过，很好的提升了性能。当然，做好这样的优化，需要做大量实验，对数据的典型性有很好的把握，也要对Skia的cache机制有很好的了解，并做很多增强。DOM的一些优化也是针对某些场景。比如在packaged app里，可以节省一些cache获得很大的性能提升。 InfoQ：关于H5的优化和硬件加速，还有什么需要补充的吗? 顾扬：优化是很难做的，我们从12年开始做优化，碰到的最大问题不是怎么修复瓶颈，而是压根不知道哪是瓶颈。你想，H5有很多关于功能的标准，但却没有关于性能的。H5涉及的面很广，包括JS，CSS，Canvas2D，WebGL，Web Audio， Web Video等。这些领域在不同的硬件配置，比如CPU，GPU，内存，屏幕尺寸和分辨率上，表现都会有很大不同。怎么设计benchmark，既cover典型的应用场景，又能充分测出每个领域的瓶颈所在，是最难的事。我们从一开始就做好了长期作战的准备，比较系统的为优化做准备。我们收集，开发和评估各种benchmark，不断积累测试方法，自主开发一系列工具帮助我们自动化测试和明确问题。在这些benchmark帮我们明确了问题之后，就需要依赖我们对web引擎的了解，分析问题所在。有些问题是比较好解决的，比如有些局部代码写的不好，或者说有些regression，也就是说以前是好的，现在不好。另一些问题是比较系统性的，解决它们需要大量的改动，甚至改动底层架构。我们通常会积极跟upstream讨论，寻求最佳的解决方案。 这是我们整体做优化的一个思路，一个过程。优化不是一蹴而就的，需要长期的积累和很多很琐碎的工作。 InfoQ：再问一下，对于耗电，该如何优化? 顾扬：耗电和性能，很多时候是一对矛盾，需要很好的权衡。 有的时候很少的性能损失或者不损失，就能省很多电。比如通常的web应用，每帧的显示通常要经过CPU处理，然后交由GPU渲染。如果GPU是瓶颈，那么CPU再快也没有用。这个时候可以通过一些聪明的调度算法，减少CPU端的操作。再比如有些video的解码工作，交给GPU处理不仅快，还能大大节省整体耗电。 但决定并不是每次都这么容易。当省电的代价是比较大的性能损失时，就需要很好衡量了。有时可以在web引擎里面设置一些启发式规则，根据系统当时的情况，作出合适的选择。 InfoQ：对未来的展望? 顾扬：web发展很快，越来越多的人贡献idea和code。这些贡献主要在两方面，能力和性能。 能力方面，很多native的能力正在很快的加到web中，像蓝牙，NFC，AR，VR等。我们想要打通native和web的界线，native能做的，web都要做到。之前web是在追赶native的能力，今后要慢慢lead这些能力。世界不断发展，不断有新技术出现，这些新技术以后先在web还是先在native落地，则看谁基础更好，实现更经济了。哪边发展快，哪边就能引领行业发展。 第二类是性能。上面已经谈的比较多，主要是JS语言本身的性能，以及web引擎本身的性能。至于能不能达到native性能，坦白说很难，但可能有了足够好的性能之后，这个问题就不那么重要了。比如说web有个常用的指标FPS(一秒几帧)，对人眼来说60FPS就已足够好，再高人也不易察觉了。所以如果web可以达到60帧一秒，native可以到80帧，虽然web还是不如native，但已经足够好。这个时候，web在其他方面的优势，比如统一的标准，高效的开发，方便的更新等，将秒杀这些很小的劣势。web就会变成一个很适宜开发的成熟平台。所以性能发展的目标，不一定是要达到native，而是足够好。 InfoQ：有言论说，随着从C/S到B/S的转变，未来我们只需要浏览器就足够了，客户端软件会被浏览器上的云端软件取代，你怎么看? 顾扬：我做web这么多年，非常热爱web，也对它很有信心。但是我认为世界上的统一是不可能的，也是不适合发展的。总有需要native存在的领域，比如有些对性能要求非常高的地方。做个类比，我们看一下计算机语言的发展历史，高级语言在慢慢侵蚀低级语言的地盘，从汇编到C/C++，Java，以及很多的脚本语言，但低级语言并没有消失。在很多底层库中，还用了大量的汇编，C/C++有更多的领域在使用，更不用说Java之类了。 web的使命，不是彻底取代native，而是补充了多样性，把应用这个蛋糕做大了。以前的人，哪有这么多应用可以用。可预测的是，在经历了高速发展期后，它跟native的在应用中的比例会趋于一个稳定的状态，native仍会有相当可观的比例。 被访者简介 余枝强，目前是英特尔开源技术中心的软件技术经理。 主要负责HTML5 引擎 – Crosswalk 在安卓平台的开发，以及一些其他和Web有关的新兴技术的研发工作(如HTML5 并行技术, HTML5 游戏优化，3D Camera等)。他坚信Web是未来， 也非常希望和大家一起努力，让这个未来能够更快更好的到来。 顾扬，英特尔中国开源技术中心web研发经理，负责web图形相关功能(CSS, Canvas2D和WebGL等)的实现和优化。2013年硕士毕业于浙江大学，后加入Intel从事编译器开发5年，转而主攻web。在web领域，带领团队完成Android Chrome 32位到64位的移植，负责英特尔移动平台web支持，更是贡献400多个patch到Chromium Upstream (包括Chromium, Blink, Skia等)和Khronos Github，实现和优化图形相关功能。业余爱好羽毛球，曾任上海英特尔羽毛球俱乐部主席7年，获奖颇丰。
21
2017-06
Java程序员最亲睐的Web框架
这是关于Java的第二个调查,第一个调查是关于Java程序员使用的20多个大数据工具。 这一次，我们要讨论的是 web 框架。 只有少数几种语言像 Java 一样提供了各种各样的 web 框架，上面的统计图就是一个证据。下面是其他开发者所使用 web 框架列表： - Spring MVC/Spring Boot ：Spring 可以帮助各地的开发团队构建简单轻便、快捷灵活基于JVM 的系统和应用程序 - Vert.x ：一个用于在 JVM 上构建反应式应用程序的工具包 - JSF ：官方的 Java EE web 框架 - Play Framework ：更容易地使用 Java & Scala 构建可拓展的、快速又实时的 web 应用程序 - Grails ：Java 版本的 Ruby on Rails，建立在 Spring 和 Hibernate 之上，用 Groovy 编写 - Spark ： 一个受 Sinatra 启发的小型框架，帮助使用最小的努力在 Java 8 中创建 web 应用程序 - Apache Struts ：一个 MVC 框架，用于创建优雅的、现代化的 Java web 应用程序 - Dropwizard ：一个用于开发操作友好、高性能、REST 风格 web 服务的框架 - Vaadin ：一个服务器端框架，用于构建单个页面的 web 应用程序 - JHipster ：一个生成 Spring Boot+ AngularJS 项目的应用程序生成器 - Wicket ：使得简洁、分离关注点和简单化开发到一个全新水平的 web 应用程序框架 - JAX-RS ：JDK 的内部框架，用于创建 REST 风格的 web 服务 - Stripes ：让使用 Servlet 和 JSP 工作时变得轻松 - Sling ：一个使用 Java Content Repository，并得到 OSGIt 支持的 web 框架 - GWT ：Google 开发的一个框架，可以编译 Java 代码为 JavaScript 运行在浏览器中 - XSLT ：用于转换 XML 文档为另一种 XML 文档的语言 - Ratpack ：用于构建现代化 HTTP 应用程序的 Java 库系列 - Express ：这不是 Java web 框架，而是建立在 Node.js 上的 Javascript 框架 - Ninja framework ：全栈 web 框架，协同 GAE 工作很好 - Compojure ：用于 Ring 和基于 Clojure 的 web 应用框架的小型路由库 - ZK ：一个开源的 Java 框架，用于构建企业级 web 和移动 app - Symphony2 ：用于 web 开发的高性能 PHP 框架 - Java 企业版 ：是社区驱动企业软件的标准
21
2017-06
CSS 各种定位（position）方式的区别
static：静态定位是position的默认值，元素框正常生成，也就是没有定位时的正常显示。 relative：相对定位 用法一：元素相对自身的原位置偏移某个距离，但是原本的空间依旧保留，表现为空白。 用法二：把一个元素设置为position: relative; 可以使该元素的子元素相对该元素绝对定位。 absolute：绝对定位 元素从文档流删除，并相对于包含块定位。元素在原本的空间关闭。元素定位后生成一个块级框，不论它原来是行内元素还是块级元素。 包含块：最近的position值不是static的祖先元素(块级或行内)，一般会指定一个元素作为绝对定位元素的包含块，将其position设置为relative而且没有偏移。 fixed：固定定位 元素从文档流删除，并相对于浏览器视窗定位，因此不随文档滚动而移动。元素在原本的空间关闭。元素定位后生成一个块级框，不论它原来是行内元素还是块级元素。与绝对定位的区别仅仅是包含块不同。 包含块：浏览器视窗。 absolute/fixed和float对比 类似：元素都会从文档流删除，但是依旧会影响布局;都会生成一个块级框，无论原来是不是块级元素。 区别：float的包含块是最近的块级祖先元素。 偏移属性：top/right/bottom/left，初始值是auto。 采用position定位之后必须采用偏移属性定义偏移量，也就是相对包含块的偏移。注意应用于position值不是static的元素。 有时也需要定义width和heigth，但是可能会和偏移属性的定义冲突，因为四个偏移属性实际上已经定义了元素的大小。此时，根据width和left属性定义左右，根据top和height属性定义上下。 内容溢出overflow: visible/ hidden/ scroll /auto/ inherit，初始值是visible。 一个元素的大小固定，但是其内容放不下，就会导致溢出。overflow控制溢出部分的可见(visible)、不可见(hidden)、滚动可见(scroll)。 元素可见性visibility: visible/ hidden/ collapse/ inherit，初始值是visible。 visibility:hidden和display:none的区别：visibility:hidden设置元素不可见，但是元素依旧会影响布局，只是元素部分呈现为空白;display:none元素不显示并且从文档流中删除，对文档布局没有任何影响。
共22条 共3页 第2页
首页
上一页
1
2
3
下一页
尾页
版权所有 © 2017 郑州方果电子科技有限公司
做网站:方果科技
营业执照展示
豫ICP备16029994号
