有幸在好友的介绍下参加阿里举办的杭州前端线下交流会，半天下来收获还是不少。写篇文章总结一下，为了防止字数过多，所以将一篇文章通过上中下来写，减少每篇的字数。
在2.22那天从学校急匆匆地打的赶到滨江的阿里，这算是第一次来参观阿里的办公大楼，还是相当霸气威武的。
阿里巴巴目前在杭州的滨江地区，周六的滨江真的是路很宽，人很少，车很少，风挺大，各种林立的办公大楼与人烟一对比，难免让人联想到被媒体炒热的“鬼城”一词。
题外话说到这里，本次线下交流会是由阿里1688的前端团队主办的线下前端交流会，在阿里内部的岳麓书院（其实就是一个教室大小的房间）举行，到会的除了阿里系之外约有30人左右，聚会设置了13：30到场，14：00正式开始，在活动开始前在房间的一边设置了一些阿里前端的一些项目展示（这个在后文中会提到）；
教室里一共设了4张圆桌，用台签标明了四大主题：node.js,用户数据采集和行为分析，移动无线（大概是这个意思），前端集成开发环境。参加聚会的同学们可以按照自己的兴趣点挑选圆桌，那么对应圆桌的讨论议题也就是对应的台签。主持人是个帅帅的gg，他首先介绍了阿里1688的前端团队，指出了本次交流会的主旨在于改变其他交流会只是单独有人在上面讲下面人听的形式，让参加活动的每个人都能够有机会发表自己的看法或者是疑问，同时这些疑问可以被其他人所解决。包括阿里自身在团队在工作中也会遇到这样那样的困惑，希望能够通过交流获得一些启发。
14：15左右讨论正式开始，平均每张圆桌围坐了10人左右，其中大概有2-3个阿里系的员工进行话题的引出和相关的时间引导与安排，我首先在前端集成开发环境这个议题的圆桌坐下，通过自我介绍之后，可以发现与会的同学基本上来自杭州的IT公司的前端，零星包含着想我这样还在学校的学生。下面是讨论的一些笔记：
前端集成开发环境从流程上来说包含：本地开发->打包编译->测试->发布部署->线上监控这些环节。如果所有步骤都是由人工来进行按步操作就会导致前端人员的时间的大量浪费在重复性，非技术性的环节之中，而一个合适的集成开发环境能够节省时间，优化流程。在讨论过程中提到了国内外的一些方案：FIS http://fis.baidu.com— 百度web前端研发部提出的前端解决方案。Grunt http://gruntjs.com一个基于任务的JavaScript工程命令行构建工具,阿里的crox；
印象比较深刻的是通过md5的比较能够由机器自动识别改动，也就是一旦一个文件发生微小改动，整个工程就能通过md5识别出来，对于改动的内容如图片链接，就会自动加入新的时间戳，这个对于曾经有个需要自己在一定时间超出需要手动更新时间戳的经历来说无疑是一大便利。讨论中有同学提出了自己在开发过程中的一些疑惑，阿里的同学也提出了自己的看法，对于我个人来说，因为相关的工程经验比较少，更多地是了解了主流的发布流程以及一些国内外的解决方案以方便日后学习。
经过一小时的讨论后，进行了一个类似于一站到底的游戏进行互动。同时人员也再次进行了分配，我来到了用户数据采集和行为分析。这里的主讲师是之昊，相比于其他桌的偏于技术，之昊向我们展示了更多的是一种未来可能的趋势：
传统需求采集，通过获取用户对于在web页面上的操作行为如点击按钮，填写表单等每个行为作为一个数据进行采集到后端，经过后端服务器的大数据量的计算进行用户行为分析，如由两个表单填写间隔时间过长可以猜测表单提醒的引导性不够，进而转换为一个需求来进行页面改动。
而之昊认为这样一个需求由用户使用到更改的逻辑链过长，无法对于用户的实时使用进行改动，也就是我们的页面过于单板，不够智能。是否可以通过将用户的行为数据部门存于浏览器本地缓存，（类似于localstorage的概念）通过js的读取来实时地判断用户的行为，如：对于某一用户或者某一类用户某一表单填写等待时间过长，说明缺少引导这时候在页面上显示出新的引导，也就是对于不同人可能面对的就不是完全相同的代码了，当改动之后的用户采集数据得到了正反馈，进而这种大数据量的正反馈就会逐渐成为后端的一个规律，也就是之后如果用户遇到疑惑就会后台自动生成一段提示代码进行提示。 也就是由个体转为了规律。作为前端通过直接的数据读取，就可以降低后端服务器的数据处理需求，降低成本以及更好地利用服务器性能。