利用批处理生成前端单页或多页应用webpack40-vue20

批处理前端现在在做项目的时候大多数遇到的都是单页面应用,但有时需要做多页面的时候,会把单页拿过来修改成多页面,如果代码多了,对单页或多页的配置可能会混乱,那么有没有更好的方式能把单页面和多页面不同的配置代码分开,能更清楚的分辩他们的区别,这里是利用批处理对前端构建进行部署 git地址 目录分为三块 single //单页代码 share // 共用代码 many //多页代码只需要用到批处理对其中两者进行合并就能生成想要的单页或多页应用,提示需要安装国内的npm淘宝镜像 如果未安装的需要自行修改build.bat里的命令行call cnpm install为call npm install如下所示: 先选择存放路径,输入项目名,选择要生成的是单页还是多页 这里以单页为示例,其实就是简单的对文件进行复制,复制完成后会自动安装依赖 安装完依赖后还会自动运行项目 如上开启的项目端口为8080目录如下 webpack4 共同配置(share)这里用到了最新的webpack4.0,它简化了很多配置,多线程输出,更快的构建能力,大大提高了开发的效率首先看下配置文件config.js const path = require('path'), config = { //开发环境配置 dev: { port: 8080, // 接口代理 proxyTable: { '/v2': { target: 'https://api.douban.com', changeOrigin: true }, }, }, //生产环境配置 build: { packName: 'myProjcet', //项目打包后名称 outputPath: '', //打包后项目输出路径 templatePath: 'template.html', //html模版路径,基于根路径下 htmlShortPath: '/', //html文件输出路径, 基于outputPath resourcesPath: '', //最终打包路径 resourcesShortPath: 'resources', //资源目录 {packName}/resources }, switchVal: { to_rem: false, //是否开启px转rem to_eslint: false, //是否开启eslint语法检测 }, };//输出的目录config.build.outputPath = path.resolve(__dirname, '../../dist/', config.build.packName);//最终输出目录项目存放路径config.build.resourcesPath = path.join(config.build.outputPath, config.build.resourcesShortPath);module.exports = config;这里有开发环境下的接口代理, 生产环境的目录名称和路径 还有可选的是否转换页面字体为rem和eslint语法检测 eslint校验是默认的规则校验 它还有其它的三种通用规则 可根据自身喜好去设置 ...

June 27, 2019 · 5 min · jiezi

应用案例-Blink-有何特别之处菜鸟供应链场景最佳实践

本文授权转自阿里技术官方公众号(ali_tech):菜鸟供应链业务链路长、节点多、实体多,使得技术团队在建设供应链实时数仓的过程中,面临着诸多挑战,如:如何实现实时变Key统计?如何实现实时超时统计?如何进行有效地资源优化?如何提升多实时流关联效率?如何提升实时作业的开发效率? 而 Blink 能否解决这些问题?下面一起来深入了解。 背景菜鸟从2017年4月开始探索 Blink(即 Apache Flink 的阿里内部版本),2017年7月开始在线上环境使用 Blink,作为我们的主流实时计算引擎。 为什么短短几个月的探索之后,我们就选择Blink作为我们主要的实时计算引擎呢? 在效率上,Blink 提供 DataStream、TableAPI、SQL 三种开发模式,强大的 SQL 模式已经满足大部分业务场景,配合半智能资源优化、智能倾斜优化、智能作业压测等功能,可以极大地提升实时作业的开发效率;在性能上,诸如 MiniBatch&MicroBatch、维表 Async&Cache、利用 Niagara 进行本地状态管理等内部优化方案,可以极大地提升实时作业的性能;在保障上,Blink 自带的 Failover 恢复机制,能够实现线程级的恢复,可以做到分钟级恢复,配合 Kmonitor 监控平台、烽火台预警平台,可以有效地实现实时作业的数据保障。 接下来,我将结合供应链业务的一些业务场景,简要说明,Blink 如何解决我们遇到的一些实际问题。 回撤机制订单履行是供应链业务中最常见的物流场景。什么是订单履行呢?当商家 ERP 推单给菜鸟之后,菜鸟履行系统会实时计算出每笔订单的出库、揽收、签收等节点的预计时间,配送公司需要按照各节点的预计时间进行订单的配送。为了保证订单的准点履约,我们经常需要统计每家配送公司每天各个节点的预计单量,便于配送公司提前准备产能。 看似很简单的实时统计加工,我们在开发过程中遇到了什么问题呢?履行重算!当物流订单的上游某个节点延迟时,履行系统会自动重算该笔订单下游所有节点的预计时间。比如某个物流订单出库晚点后,其后的预计揽收时间、预计签收时间都会重算。而对于大部分的实时计算引擎来说,并不能很友好的支持这种变 Key 统计的问题。以前,数据量没那么大的时候,还可以通过 OLAP 数据库来解决这类场景,当量上来后, OLAP 方案的成本、性能都是很大的问题。 除了 OLAP 方案,我们提倡采用 Blink 已经内置的 Retraction 机制,来解决这类变 Key 统计的问题,这也是我们在2017年初就开始尝试 Blink 的重要原因。Blink 的 Retraction 机制,使用 State 在内存或者外部存储设备中对数据进行统计处理,当上游数据源对某些汇总 Key 的数据做更新时,Blink 会主动给下游下发一个删除消息从而“撤回”之前的那条消息,并用最新下发的消息对表做更新操作。 下面是一个简化后的案例,供了解 Blink Retraction 的内部计算过程: 对于上述案例,可以通过 Blink 提供的强大的、灵活的、简易的 SQL 开发模式来实现,只需要几行 SQL 即可完成。 ...

May 29, 2019 · 2 min · jiezi

入门教程-5分钟从零构建第一个-Flink-应用

本文转载自 Jark’s Blog ,作者伍翀(云邪),Apache Flink Committer,阿里巴巴高级开发工程师。本文将从开发环境准备、创建 Maven 项目,编写 Flink 程序、运行程序等方面讲述如何迅速搭建第一个 Flink 应用。在本文中,我们将从零开始,教您如何构建第一个 Flink 应用程序。开发环境准备Flink 可以运行在 Linux, Max OS X, 或者是 Windows 上。为了开发 Flink 应用程序,在本地机器上需要有 Java 8.x 和 maven 环境。 如果有 Java 8 环境,运行下面的命令会输出如下版本信息: $ java -versionjava version "1.8.0_65"Java(TM) SE Runtime Environment (build 1.8.0_65-b17)Java HotSpot(TM) 64-Bit Server VM (build 25.65-b01, mixed mode)如果有 maven 环境,运行下面的命令会输出如下版本信息:$ mvn -versionApache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-18T02:33:14+08:00)Maven home: /Users/wuchong/dev/mavenJava version: 1.8.0_65, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk1.8.0_65.jdk/Contents/Home/jreDefault locale: zh_CN, platform encoding: UTF-8OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac"另外我们推荐使用 ItelliJ IDEA (社区免费版已够用)作为 Flink 应用程序的开发 IDE。Eclipse 虽然也可以,但是 Eclipse 在 Scala 和 Java 混合型项目下会有些已知问题,所以不太推荐 Eclipse。下一章节,我们会介绍如何创建一个 Flink 工程并将其导入 ItelliJ IDEA。创建 Maven 项目我们将使用 Flink Maven Archetype 来创建我们的项目结构和一些初始的默认依赖。在你的工作目录下,运行如下命令来创建项目: ...

May 22, 2019 · 2 min · jiezi

3分钟干货之批处理系统

批处理系统没有太多的用户操作,在该系统中,调度算法目标是保证吞吐量和周转时间(从提交到终止的时间)。1.1 先来先服务 first-come first-serverd(FCFS)按照请求的顺序进行调度。有利于长作业,但不利于短作业,因为短作业必须一直等待前面的长作业执行完毕才能执行,而长作业又需要执行很长时间,造成了短作业等待时间过长。1.2 短作业优先 shortest job first(SJF)按估计运行时间最短的顺序进行调度。长作业有可能会饿死,处于一直等待短作业执行完毕的状态。因为如果一直有短作业到来,那么长作业永远得不到调度。1.3 最短剩余时间优先 shortest remaining time next(SRTN)按估计剩余时间最短的顺序进行调度。

April 18, 2019 · 1 min · jiezi