班会第 59 期

[ufologist]

• 技术

  • wdfe/wdui

    Mobile UI Components Library based on Vue 2.0 at Weidian(微店)

    遵循微店的设计规范，我们开发了一系列精美的移动UI组件，在满足不同功能操作体验的同时让界面更加规范、易用、美观。组件的设计兼具不同屏幕的适配，专为移动而生。

    包括控件设计的规范、产品设计过程中使用到的中英文字体、IconFont 字体文件等

    • 移动端组件库
    • 基于 REM 配合 lib-flexible 实现多终端适配

  • 百度技术学院

    Web技术介绍

    Web（World Wide Web）即全球广域网，也称为万维网，是一种基于超文本和超文本传输协议（HTTP）的、全球性的、动态交互的、跨平台的分布式图形信息系统。Web应用一般是指以浏览器作为通用客户端进行Web访问的应用程序，经常又被称为B/S（Browser/Server，浏览器-服务器）模式的应用，对于用户来说，更通俗的理解就是如何用浏览器来浏览网页。

    Web技术指的就是开发Web应用的技术总称，包括Web客户端技术和Web服务端技术。Web客户端技术的主要任务是展现Web应用的信息内容，涉及HTML、CSS、JavaScript等；Web服务端技术的主要任务则是通过集成Web服务器、操作系统、数据库、开发语言等来提供高效稳定可靠的Web服务，涉及LAMP（Linux+Apache+MySQL+PHP）、J2EE、ASP.Net、MEAN等多种架构。

  • 前端工程师做事的三重境界：我的进阶之路

    • 把事情做成
      • 告诉他做什么、怎么做，他所需要的是执行力和基础技能
    • 把事情做好
      • 对于业务需求有一定的前瞻性；能给出比较健壮的技术方案，能一次解决一类问题而不是一个问题，知道什么样的方案是不靠谱的
      • 自行找到问题的解决方案并落地实施
      • 通俗的说，面对具体的技术、业务问题，顾及到更多的点，想到更多的方案。需要的是努力、时间和经验的积累。
      • 做出好的东西先要知道好的东西长啥样。一方面，多读经典的书，仔细读高质量的文章，另外一方面，遇到问题要学会去搜索，找更多的解决方案，然后比较，融会贯通
    • 把事情做绝
      • 想成为前端工程师，要先成为工程师. 工程师应该具备怎样的能力？
      • 工程就是运用知识去设计、创建、维护、改进工具、系统、流程和组织的过程，而工程师是推动这个过程的最主要角色
      • 具备很强的学习能力，能掌握完整的知识体系. 扎实的计算机科学基础是基石。具体到前端领域，基本的数据结构和算法、设计模式和变成范式、网络、JS、CSS、浏览器、性能、设计，软件质量、可维护性、可扩展性，软件工程化（构建、部署、运维、监控）
      • 具备良好的抽象思维能力，有了抽象思维能力就能够快速建立起系统运行机制的思维模型，也能把现实世界的业务问题转化为了恰当的模型，然后用技术去解决。具体到前端领域，比如前端应用的典型信息架构，状态机、栈、队列这些数据结构在前端的应用
      • 具备良好的沟通能力，沟通能力的好坏决定了你是否能准确理解需求的本质，是否能把自己的的设计方案清晰的展示给同事，而沟通的形式就不那么重要了，可以是书面文字，可以是白板、思维导图，甚至是动画演示
      • 具备平衡取舍能力，知道在哪些地方只需要做成，哪些地方需要做好，哪些地方要做绝，因为工程的要义就是取舍，在商业和技术之间寻求平衡点，这往往是很多人所忽视的能力

  • ［译］帮助你成为一名成功的 Web 开发工程师的 21 步

    • 这是你真正热爱的吗?

      它的原意是 “一种强烈且无法控制的情感” 。热爱不是被动的去做：它是一种对行动的追求

    • 不仅仅是知道多少

      成功不在于你知道多少，而在于你能用所知道的东西做什么

    • 技能

      限制自己只学习某个编程语言是不对的。为了提高成功的机率，学习其他的像市场、谈判技巧、沟通以及社会技能等对你很重要。看看那些最成功的开发者们吧：他们的技术都很全面，也有着很好的天分，他们并没有把所有精力都用在编程上。

  • 一个节奏极快的创业公司的web前端持续交付心路历程

    这是一家节奏超快，风格强悍的公司。怎么说呢，就是说今天想出来的点子明天就想，哦不，不只是想！就是明天一定要上线验证的风格

    先来看看我们当时面临的状况：比如由于历史问题，我们的项目工程是一个多人维护的超大工程，并且每天上线好几次的更新速度使得我们只能走部分文件上线这条路（已经不敢全工程上线）. 但人工挑出上线文件这种方式的确也是人神共愤，比如有一次修改较多，有人修改了几十个文件，则这个人需要从大工程里手工挑出这几十个文件，出错概率非常大。所以当时上线之后马上补单的事情经常发生.

    • 产品节奏非常快，明天就要上线（这个刚才已经说过）
    • 前端只分为pc,mobile两个大工程，这两个平台的所有页面都在这里，耦合严重
    • 构建，部署测试环境和线上环境基本靠手工

    我们开发测试上线的流程

    • 前端项目全部通过ajax来和后端隔离，所以开发环境完全本地化，本地联调完，部署测试环境进行测试。
    • 运维同学很慷慨的提供了非常多套测试环境（test1~test100），为了安全，测试环境和开发机之间有跳板机（堡垒机）隔离。
    • 部署测试的时候通过grunt test1~tes100 生产测试包（2个包，一个页面包，一个静态资源包），copy到堡垒机，再copy到目标test环境相应目录（也是2个目录）。正式环境则grunt product出正式包，然后copy到跳板机，再copy到op指定机器的指定目录。然后有op(运维同学)操作上线。

    以上状况带来了我们在日程开发工作上造成很大的困扰，很多时间被浪费在了部署上

    • 代码耦合严重，多人维护统一工程加上超快的开发迭代节奏，最后上线的事情只能是刀耕火种，即工程并非能全量上线，每次上线只能手工挑出来本次上线哪些文件
    • 部署完全手工，先copy到跳板机，再到目标机器。重复体力劳动繁重。加上测试环境多，部署起来更是痛苦。
    • 多人维护的项目经常会将不该提交的代码提交或者由于本地构建忘记update而导致上线出问题
    • 测试环境测试过程中经常被覆盖，导致测试时间浪费

    为了解决这种问题，我们分几步做了以下优化,最终形成了我们的部署系统 ideploy

    • 用部署命令代替手工scp,减少重复体力劳动，告别刀耕火种
    • 平台初建，先解决现有问题
      • 命令行程序的维护问题，每次更新（有可能是部署目标机器变化等）需要确保每个人都更新版本
      • 只能全量更新
      • 本地构建带来一些代码不同步的问题
      • 部署系统会列出来从上次部署到本次部署期间，代码仓库有哪些文件是修改了的
    • 拆分项目，完善部署平台，让部署变得顺滑
      • 支持全量部署，不用挑选部署文件，当然也支持部分文件部署
        • 对项目进行拆分成多个子项目，各个子项目间无依赖，可以自行构建自行部署。并且在部署上提供多机器，多项目一键部署功能
      • 测试环境提测以后，有办法解决测试环境覆盖问题
        • 首先统一收拢部署入口，所有部署必须经过部署平台，然后在部署平台部署完成后给部署人一个选项，是否锁住不让别人部署，解决覆盖问题
      • 上线前需要了解本次上线都需要列出来，放心上线
        • 多人维护的项目，我们在部署的时候总是想确认那些人修改了哪些文件，避免遗漏我们通过提交日志和diff来给部署的同学非常清晰的说明
        • 在部署前的checkout这一步，我们把本次上线到上次上线间，每个成员的修改次数，修改记录，每个文件的变化都列出来，并且可以细致到每一次修改
      • 方便的添加项目，添加目标机器
      • 构建和部署无关化，支持项目自由选择技术栈

  • Nginx ngx_pagespeed nginx前端优化模块编译

    ngx_pagespeed speeds up your site and reduces page load time by automatically applying web performance best practices to pages and associated assets (CSS, JavaScript, images) without requiring you to modify your existing content or workflow

    • Image optimization: stripping meta-data, dynamic resizing, recompression
    • CSS & JavaScript minification, concatenation, inlining, and outlining
    • Small resource inlining
    • Deferring image and JavaScript loading
    • HTML rewriting
    • Cache lifetime extension

  • Flatdoc

    用来写简单的文档页面再好不过了, 你只需要写好 markdown 文档, 自动帮你渲染好页面

    Flatdoc is a small JavaScript file that fetches Markdown files and renders them as full pages. Essentially, it's the easiest way to make open source documentation from Readme files.

    • No server-side components
    • No build process needed

    Flatdoc.run({
      fetcher: Flatdoc.github('USER/REPO')
    });

    其他选择

    • Docco

      生成像 Backbone.js 那样的 Annotated Source 文档

    • DocumentUp

      也不错, Automatically generated documentation sites for your markdown files! http://documentup.com/username/repository, 例如: http://documentup.com/ufologist/puer-mock

• 产品

  • 基于企业标准色快速建立配色方案——HSB颜色模式

    当拿到企业标准色后，如何基于标准色快速的建立一套可行的界面设计配色方案，HSB色彩模式调节法是其中一个易上手且不容易出错的方法

    • 基础色的浅色系调节方法：降低饱和度，增加明度，色相调节值靠近60/180/300
    • 基础色的深色系调节方法：增加饱和度，降低明度，色相调节值靠近0（或360）/120/240