哆啦可视化大屏编辑器，是植根于浏览器的可视化平台。我们不难发现，哆啦的众多图表中，有多种实现方案。如，基于ECharts二次开发的BI图表，有基于Mapbox/leaflet等实现的地理图表，以及根据业务需要制作的基于Dom的内容、视频、图片等组件。 以ECharts为例，我们知道它的底层是基于zrender的。因此，ECharts也可以自由的切换渲染引擎。默认地，ECharts使用的是Canvas作为渲染器。如果你希望看到节点结构，你还可以使用下面的语句，用SVG作为渲染器。
根据MDN的表述，跨域资源共享（Cross-Origin Resource Sharing，简称CORS），一般也称为跨域请求，是一种基于 HTTP 头的机制，通过这种机制，服务器可以通知浏览器，允许非同源访问加载该服务器域内的资源。
其实这个表述还有一层隐含意思，就是如果服务器没告诉浏览器这些源可访问，那么浏览器就会禁止这个域访问该资源。
但是，有很多能够发起请求的客户端，比如命令行程序、比如 Postman，其实是可以随意的获取各个域名下的资源的。跨域资源获取，是一种浏览器的机制。如 Chrome ，也是可以关掉跨域限制的。
可视化项目中，经常会遇到绘制地图的需求。除了地图自身的寻路、标注等需求外，可视化地图应用还会将业务数据在地理信息上进行拆分，并通过某种方式在地图上进行呈现，从而揭示出业务数据与地理数据的相关性。
像上图所示，即为2011年香港18区的人口密度图。
这篇文章里，我们就来讨论下，一个符合常识的在线地图的绘制方案。在正式开始之前，我们先明确一点，由于地图绘制是一项严肃且异常严谨的工作。因此，规范使用地图，一点都不能错！。本文旨在揭示在线地图的技术原理，如在产品中使用，需使用合规地图，并应取得政府认可的审图号并在产品中进行展示。
浏览器领域，我们有如selenium和puppeteer这样的库，可以自动化控制浏览器执行自动化脚本，以完成自动化端对端测试、定时自动化任务等。随着持续集成、持续部署也就是CI/CD的需求日益增长，自动化也成为必不可少的一环。
对于日益增长的小程序开发需求，我们能不能自动化控制小程序，进而达成自动测试、自动发布等任务呢？
转眼年关切近，很多业务都会考虑做一些抽奖活动，而各大公司在年底也会考虑开办年会。年会中，一般会安排抽奖环节。抽奖程序一般接收一个抽奖人员列表，通过算法产生一个随机数，再通过某种对应关系，将列表中的某个人与这个随机数匹配。这个匹配的人就是中奖的幸运儿了。
不出意外的话，年底这一个多月，通常是一年中随机函数被调用最频繁的一段时间。
标题很绕口，不过确实是一个很常见的需求。
众所周知，NodeJS程序开发简便且容易实现跨平台。但是，当你开发了一个NodeJS程序，想要分发给其他人运行的时候，你会发现，你往往需要对方也来安装一个NodeJS环境。理想的方式是，我们可以把我们的程序打包成一个可执行文件，这样，就可以直接在对方的电脑上运行你的程序了；同时，我们将代码打成二进制形式，可以在一定程度上保护源代码以及API等处理的逻辑。
你在实际的开发中很可能遇到过这样的需求：实现一个可以拖拽的滑块，以实现范围选择、音量控制等需求。
除了直接用组件库，聪明的你肯定已经想到了多种解决办法。如在数据驱动框架React/Vue/Angular下，你可能会找到或编写对应的组件，通过相应数据状态的变更，完成相对复杂的交互；如在小快灵的项目下，用jQuery的Widget也是一个不错的选择；再或者，你可以点开你的HTML+JavaScript+CSS技能树，纯手工打造一个。这都是不难完成的任务。
当然，在完成之后，你可能会考虑对组件做一些提炼，下次再遇到同样的需求，你就可以气定神闲地“开箱即用”。
这里是Clair组件库对这个需求的封装。
我们不妨从这个层面再多想一步。其实由于HTML和CSS默认都是全局可见的，因此，尤其是纯手工打造的组件，其样式是很容易受到所在环境的干扰的；由于选择器在组件层没有统一的保护手段，也会造成撰写时候的规则可以被随意修改；事件的捕获和冒泡过程会和所在环境密切相关，也可能会引起事件管理的混乱。
根据一般意义上“封装”的概念，我们希望相对组件来讲，DOM和CSS有一定的隐藏性；如非必要，外部的变化对于内部的有一定的隔离；同时，外界可以通过且仅可以通过一些可控的方法来影响内部，反之亦然。
针对这些问题，其实浏览器提供了一种名叫Shadow DOM的解决方案。这个方案目前与 Custom Elements、HTML Templates、CSS changes和JSON, CSS, HTML Modules并列为Web Components标准。
在开发需要多个密切协作的软件包时候，我们往往将独立的功能块进行划分，使得各个功能独立的模块分别完成，以减少相互影响，完成有效的多人合作。但是，在模块协作时，经常会遇到一些问题：
一直以来，Windows的命令行的体验都不是特别的友好。由于Windows以图形界面交互为主，同时微软在一段时间内对命令行程序发展并不积极，以及Windows系统底层与*nix系列的不一致。造成Windows下的命令行开发与图形开发体验相去甚远：一方面工具链的不完整，一方面终端字体不甚美观，甚至默认的终端色域相对于Mac都是精简的。
