Open ufologist opened 7 years ago
技术
常见的效果就是当页面滚动到某个元素时, 触发该元素的动画, 用于引起用户的关注并提升网站的交互. 实现这种效果的基本原理就是判断滚动条滚动的距离是否越过了元素在页面上的位置. ScrollReveal 最方便使用, 无需依赖动画样式 Animate 方便配合 animate.css 使用 ScrollWatch 只做滚动位置监听的, 这样就能更好的自定义滚动到某个元素位置时做什么事情
常见的效果就是当页面滚动到某个元素时, 触发该元素的动画, 用于引起用户的关注并提升网站的交互. 实现这种效果的基本原理就是判断滚动条滚动的距离是否越过了元素在页面上的位置.
即实现首屏内容高度的适配, 不管在哪种分辨率下, 首屏内容的高度刚好是一整屏的高度
一般通过 CORS 实现跨域请求, 会配置如下 HTTP Response Header Access-Control-Allow-Origin: * Access-Control-Allow-Headers: * Access-Control-Allow-Methods: GET, POST *但如果跨域请求时需要传 Cookie, 那么 Access-Control-Allow-Origin 必须准确设置为某个域名, 不能使用通配符() 而且还要设置 Access-Control-Allow-Credentials 为 true.** 例如 Access-Control-Allow-Origin: http://b.domain.com Access-Control-Allow-Credentials: true 因此需要设置的所有 HTTP Response Header 为 Access-Control-Allow-Origin: http://b.domain.com Access-Control-Allow-Credentials: true Access-Control-Allow-Headers: * Access-Control-Allow-Methods: GET, POST 发送 ajax 请求的代码示例如下 // jQuery $.ajax({ url: 'http://b.domain.com/api', xhrFields: { withCredentials: true } }); 参考 Requests with credentials By default, in cross-site XMLHttpRequest or Fetch invocations, browsers will not send credentials
一般通过 CORS 实现跨域请求, 会配置如下 HTTP Response Header
Access-Control-Allow-Origin: * Access-Control-Allow-Headers: * Access-Control-Allow-Methods: GET, POST
*但如果跨域请求时需要传 Cookie, 那么 Access-Control-Allow-Origin 必须准确设置为某个域名, 不能使用通配符() 而且还要设置 Access-Control-Allow-Credentials 为 true.**
例如
Access-Control-Allow-Origin: http://b.domain.com Access-Control-Allow-Credentials: true
因此需要设置的所有 HTTP Response Header 为
Access-Control-Allow-Origin: http://b.domain.com Access-Control-Allow-Credentials: true Access-Control-Allow-Headers: * Access-Control-Allow-Methods: GET, POST
发送 ajax 请求的代码示例如下
// jQuery $.ajax({ url: 'http://b.domain.com/api', xhrFields: { withCredentials: true } });
参考 Requests with credentials
By default, in cross-site XMLHttpRequest or Fetch invocations, browsers will not send credentials
很早以前 Web 开发是不区分前后端的，HTML 由服务器动态生成，项目部署只是服务器端的代码发布而已。 后来浏览器提供了越来越多的 API 支持，前端开发逐渐复杂起来。 于是诞生了专注于浏览器端程序开发的「前端」这个分支。 虽然现在前后端分离开发已经非常普遍，但是在很多古老的程序架构下，它们只是实现了开发人员的职责分离。 这种前后端混部的模式会带来巨大的风险。 后端发布的风险 前端的变更往往是小而频繁的，也许只是修改一个文案或一个颜色。 在前后端混部的情况下，这些变更都需要所有代码重新编译重新发布，发布过程的每个环节都是风险 服务器负载的风险 有一类前端页面是属于纯展示性的，完全不涉及数据交互。 而且出于营销等目的，它们的业务量会非常巨大，而且难以预估。 这类页面带来的流量很可能是服务器无法接受的 真正的前后端分离是后端完全 API 化，前后端分别开发和部署，互不干扰 前端更趋向于「资源型产出」，而不是后端那样的「运营型产出」。 举例来说就是一个项目的业务量增加了 100 倍，后端开发人员可能要一直调整架构变更方案，而前端开发人员可以和设计师一样完全使用同一套东西。 一般后端服务的机器数量与业务量是有关的，大多数程线性关系。 而资源类型的部署可以使用 CDN，对源站的压力只有 CDN 节点乘以资源量而已，这些都是常量 前端「零机器」部署方案的核心其实就是把前端项目完全部署在 CDN 上 由于 CDN 总是需要一个中心数据源，所以这个过程需要一个源服务器. 整个工作流畅大概有这么几个步骤： 发布系统将代码推送到 OSS 调用 CDN 的 API 清缓存 由于缓存被清空，CDN 被请求后回到 OSS 取资源 前端「零机器」部署方案中最关键的参数配置就是缓存时间了。 我们不仅要关心资源在客户端缓存多久，还得关心资源在 CDN 节点缓存多久 由于部署方案的数据流向是主动的，我们主动调用 CDN 的 API 来清缓存，所以 CDN 到 源站的缓存可以设非常大。 也就是 s-maxage 的取值非常大，可以设置个一年之类的时间。 至于客户端要缓存多久那就得看业务需求了。 如果前端项目构建时会自动给资源文件加版本号，那么我们可以针对 html 文件关闭缓存，对其它类型的资源文件开启一个非常大的缓存 前端「零机器」部署方案的难点并不是在部署上，而是对于前端项目的改造。 URL 路由 跨域 API 调用 前端项目依然会通过服务器代理来调用后端 API 以解决跨域问题。 如果前端项目完全在 CDN 上，CDN 是无法帮你代理调用 API 的 所以前端「零机器」部署方案中的前端项目需要完全跨域调用 API
很早以前 Web 开发是不区分前后端的，HTML 由服务器动态生成，项目部署只是服务器端的代码发布而已。 后来浏览器提供了越来越多的 API 支持，前端开发逐渐复杂起来。 于是诞生了专注于浏览器端程序开发的「前端」这个分支。
虽然现在前后端分离开发已经非常普遍，但是在很多古老的程序架构下，它们只是实现了开发人员的职责分离。 这种前后端混部的模式会带来巨大的风险。
后端发布的风险
前端的变更往往是小而频繁的，也许只是修改一个文案或一个颜色。 在前后端混部的情况下，这些变更都需要所有代码重新编译重新发布，发布过程的每个环节都是风险
服务器负载的风险
有一类前端页面是属于纯展示性的，完全不涉及数据交互。 而且出于营销等目的，它们的业务量会非常巨大，而且难以预估。 这类页面带来的流量很可能是服务器无法接受的
真正的前后端分离是后端完全 API 化，前后端分别开发和部署，互不干扰
前端更趋向于「资源型产出」，而不是后端那样的「运营型产出」。 举例来说就是一个项目的业务量增加了 100 倍，后端开发人员可能要一直调整架构变更方案，而前端开发人员可以和设计师一样完全使用同一套东西。
一般后端服务的机器数量与业务量是有关的，大多数程线性关系。 而资源类型的部署可以使用 CDN，对源站的压力只有 CDN 节点乘以资源量而已，这些都是常量
前端「零机器」部署方案的核心其实就是把前端项目完全部署在 CDN 上
由于 CDN 总是需要一个中心数据源，所以这个过程需要一个源服务器. 整个工作流畅大概有这么几个步骤：
前端「零机器」部署方案中最关键的参数配置就是缓存时间了。 我们不仅要关心资源在客户端缓存多久，还得关心资源在 CDN 节点缓存多久
由于部署方案的数据流向是主动的，我们主动调用 CDN 的 API 来清缓存，所以 CDN 到 源站的缓存可以设非常大。 也就是 s-maxage 的取值非常大，可以设置个一年之类的时间。
至于客户端要缓存多久那就得看业务需求了。 如果前端项目构建时会自动给资源文件加版本号，那么我们可以针对 html 文件关闭缓存，对其它类型的资源文件开启一个非常大的缓存
前端「零机器」部署方案的难点并不是在部署上，而是对于前端项目的改造。
跨域 API 调用
前端项目依然会通过服务器代理来调用后端 API 以解决跨域问题。 如果前端项目完全在 CDN 上，CDN 是无法帮你代理调用 API 的
所以前端「零机器」部署方案中的前端项目需要完全跨域调用 API
企业应用架构是指一整套软件系统的构建，通过合理的划分和设计组合在一起，支持企业方方面面的经营运作 本文将通过一个线下小型门店成长为多元化集团的发展历程，逐步向读者展示企业应用架构的演变和设计的理念。 完整的企业架构（EA，Enterprise Architecture）分析构建，包括业务架构、应用架构、技术架构、数据架构，本文聚焦应用架构，更加关注软件系统设计与公司经营管理的关系。不论是C端产品经理或者B端产品经理，理解应用架构的建设思路，能够帮助你更轻松的理解公司的业务运转，以及各个系统存在的目的与你所负责工作在整体团队中的定位和价值。 小门店的Excel管理之路 小超市的轻量级ERP之路 通过CRM拉近与客户的距离 中型连锁超市的架构之路 在线商城业务带来了互联网化管理 信息孤岛与主数据管理 抽离共性模块全面服务化建设 强健的底层架构快速支持新业务开展 通用企业应用架构图
企业应用架构是指一整套软件系统的构建，通过合理的划分和设计组合在一起，支持企业方方面面的经营运作
本文将通过一个线下小型门店成长为多元化集团的发展历程，逐步向读者展示企业应用架构的演变和设计的理念。
完整的企业架构（EA，Enterprise Architecture）分析构建，包括业务架构、应用架构、技术架构、数据架构，本文聚焦应用架构，更加关注软件系统设计与公司经营管理的关系。不论是C端产品经理或者B端产品经理，理解应用架构的建设思路，能够帮助你更轻松的理解公司的业务运转，以及各个系统存在的目的与你所负责工作在整体团队中的定位和价值。
微信iOS客户端将于3月1日前逐步升级为WKWebview内核，请网页开发者尽快做好各自网站的兼容检查，完成适配。 WKWebview是苹果为支持最新的Webkit功能，自iOS 8起引入的网页浏览控件。开发者可以在微信已发布的6.5.3版本客户端中，手动切换到WKWebview，再检查自己的网页表现是否正常。 由于本次升级影响了图片预览、Cookie使用、JSSDK鉴权等多项功能，我们强烈建议所有开发者根据《WKWebview网页开发适配指南》 完整排查，以确保升级后自身网页可以正常使用。
微信iOS客户端将于3月1日前逐步升级为WKWebview内核，请网页开发者尽快做好各自网站的兼容检查，完成适配。
WKWebview是苹果为支持最新的Webkit功能，自iOS 8起引入的网页浏览控件。开发者可以在微信已发布的6.5.3版本客户端中，手动切换到WKWebview，再检查自己的网页表现是否正常。
由于本次升级影响了图片预览、Cookie使用、JSSDK鉴权等多项功能，我们强烈建议所有开发者根据《WKWebview网页开发适配指南》 完整排查，以确保升级后自身网页可以正常使用。
首个使用 Weex 和 Vue 开发的 Hacker News 原生应用
RunKit is a node playground in your browser
产品
技术
产品