Category Archives: 业界杂谈

Hello World 业界杂谈

QCon琐记

上周有机会参加了一天半的QCon,虽然感觉QCon越来越水,但是还是有些收获的,这里简单记录下来

Nodejs

其实,这次QCon没有nodejs的主题[汗]…,正因为没有,反而说明nodejs的热度已经过去了。

曾经火了两年,现在,曾经感兴趣的都已经体验过了,估计和我感受一样,nodejs不过是前端工程师偶尔玩玩后端的玩具,真正适合用nodejs的项目并不多。

而从前端js迁移到后端nodejs的学习成本,并不亚于从0开始学php这类简单脚本语言!

除了学习成本高,nodejs其他两个让人不爽的地方:

  1. 异步,导致代码回调嵌套太深,而后来给出的解决方案又太麻烦,可操作性不强
  2. npm库太乱,很多工具包更新不及时

而所谓统一前后端语言,个人觉得也完全没有必要:分开前后端,让开发者更清楚Http的界限在哪儿 ,哪些是跑在你服务器里的,哪些将运行在用户浏览器里。前后端的工作方式差别太大,所以了解这些,对开发者很重要

不过瑕不掩瑜,碰到需要webscoket的地方,nodejs还是很有优势的,去年年初做的一个nodejs小项目现在跑的还很平稳

全栈开发

所谓“全栈开发”,现在还没有统一的定义,大部分人得理解,就是一个人可以解决前后端的所有开发,至于说还要解决UI、测试,甚至还要自己扛机器,那就纯粹扯淡了

全栈到底是好还是不好,个人觉得视实际的公司、项目而定,如果是有很多业务的新公司,总是会有各种探索性的小项目,那么全栈工程师的优势明显:机动灵活,节约人力成本。

反之,如果是已经成体系的“大”项目,那么还是将前后端分开的好,这样即便于维护、也可以让各端做的更精。

因为人的精力有限,能做到“全栈”,就意味着都不会太专业。

小之美好

这是一个妹子讲自己所做的公共插件的主题,大意是,将功能庞大的服务项目,解体成一个个单独功能的小服务,其实这也是近几年软件工程的主要方向

将一个个小服务做好、做精,各个小服务都可以单独修改、单独上线,这样就能更加机动灵活、提升开发效率,降低维护成本

创业团队

开发人员如何创业,或者说技术如何参与到创业团队中,由于本人刚刚参加过一个创业团队,所以对相关的一个讲座深有感触

讲座提到一个4个人的创业团队,一个前端,三个后端,前端除了负责前端开发,还要负责交互和视觉;后端除了负责后端开发,还要负责产品功能。这样的一个团队,做出来的产品,并不亚于有很多产品大牛主持的东西

这里并不是说要干掉产品经理,而是尽量让技术也能参与到产品的设计中

如何让技术可以全身心的投入到开发中,最简单的办法不是拼命压缩项目周期,而是让技术本身觉得是在做自己的项目,所谓“将士用命 士子用心 文不贪财 武不怕死”,这样不仅开发效率更高,开发质量也会比仅停留在“简单做事”层面高的多

水电工

这个不是QCon的主题,纯粹是自己的一点心得

虽然我自己经常自嘲开发工作就像建筑工人,但二者还是有本质差别的:一个房子,必然是一砖一瓦建起来的,但是一个项目,却不一定真的需要一个字符一个字符的敲到电脑上~~

如果非要做个类比,开发者更像装修中水电工。水电工布设的各种管线,最终会被瓷砖、墙漆盖上。专业,或者说有良心的水电工会按照规程去布设管线,即使它们后来被盖上了,再来一个水电工要修改线路的时候,或者说其他人需要在墙上做打孔操作的时候,只要看到线路的入口和出口,按照一般的规律,就可以轻易的判断出线路的走向

更有甚者,在你之前,比如房子建设阶段就已经埋设了一些管线。如果一个水电工发现了这些基础设施,并且能够正确使用它们,就可以大大节省业主的成本

而专业的开发者正是需要这样的匠人精神:不见得什么东西都要自己从0做;自己做出的东西,也是对后续开发者友好的

轻应用

两、三年前,就在大家都忙着做所谓移动端“web app”的时候,却苦于找不到优秀的“母体”

使用普通手机浏览器?手机端浏览器种类比pc端更乱,兼容起来太难,而且不仅入口需要用户输入url,还需要注册之类的流程,用户入门门槛有点高

自己做app?自己能做app,干嘛还要搞体验要差一些的“web app”?

就在这时,微信公众平台很空出世,消息/扫码解决了入口问题,oauth解决了注册/登录问题,新出的jssdk,还可以实现很多普通web页无法实现的功能

可以预计,未来两年,基于微信的轻应用、小游戏会越来越多、越来越火

 

Hello World 业界杂谈

[转]别闯进Hybrid App的误区

【引言】

Hybrid App,一种开发模式,兼顾Web和Native的一种开发模式。有人说它把Web App扼杀在摇篮里,有人说它把Native App引向一个新阶段。我说,它是一把双刃剑,千万别闯进它的误区。本文是笔者在实践Hybrid App开发模式过程中总结出的一些经验教训,供读者参考。Hybrid App虽好,可万万不能仓促选择,盲目运用。

智能手机日益普及,移动互联网乱战日趋白热化,开发一个应用早就不是技术圈热议的话题,iOS和Android上的App已经成了每个互联网产品的标配。“唯快不破”也是中被移动互联网人尊为铁律,快速迭代,高效开发,低成本上线是每一个App开发团队追求的目标。同时,随着HTML 5的不断升温和智能手机硬件性能的提高,Hybrid App的概念应运而生。这种“Native搭台,HTML 5唱戏”的Hybrid App开发模式一时间受到各个开发团队追捧,快速进入了大量开发团队,成为主流开发模式。

Hybrid App优点众多,Web前端工程师0成本介入,不依赖版本的实时更新,快速实现跨平台需求,等等。而另一个方面,2012年Hybrid App的践行者Facebook决定大量弃用App中的HTML页面,转向更加Native化的方案。Facebook的这一举措也给Hybrid App方案的敲响了警钟,这似乎并不是一个完美的方案。

本文主要跟大家分享一下我团队和个人在Hybrid App的实践中遇到的问题,提醒大家不要闯进Hybrid App的误区。

误区一:为了HTML 5而Hybrid App。

HTML 5在Hybrid App模式中是一个最常被提起的概念。HTML 5作为一个HTML 4.0.1和XHTML 1.0的升级版,基于旧版本有更强大的表现功能,并加入了Local Storage等技术,确实为Web页面提供了更大的想象空间和更多的可能性。但HTML 5处在目前的发展阶段,受到浏览器兼容性和手机硬件性能水平的影响,它所能提供的功能与Native仍然有很大差距。

所以,我认为作为工程师要明确一款App采用Hybrid App模式的根本原因是什么。作为一款App其最根本的功能是满足使用者的需求,而并不是服务某项新技术。因此当决定采用Hybrid App去构建一款应用时,应该从应用本身功能特点和整个团队的开发资源配比统一考虑,是否有必要同时又有能力去驾驭一款“Native搭台,HTML唱戏”的Hybrid App。类似“HTML 5的时代已经到来,如果我们不这么做就变土鳖了,错过这场技术革新的大潮,终将被这个时代所淘汰”的话真不是一个有责任心的工程师应该发出的声音。

误区二:忽略关键因素

在谈到Hybrid App的场合我们更多提及的是它有诸多优点,如何架构一个Hybrid App,怎么让Web和Native和谐共处,然而Web开发中会被忽略的一些因素少被提起,这些因素又恰恰经常是一个Web页面能否正常运行在App中的决定性因素。

Web开发是基于PC的一种开发模式,开发者使用PC浏览器模拟App中的Web View进行调试。PC浏览器与手机Web View的区别是巨大的,能支配的CPU资源,最大占有的内存,运行的网络环境,鼠标操作与触控操作的区别,浏览器对CSS/JS的解析和对事件处理,等等。

App工程师,无论是iOS还是Android,最敏感的一个问题莫过于内存管理,而在Web开发则对这个问题没有过多注意。这就经常导致同一个功能界面Native实现中会通过一些技术手段,把内存容量控制在操作系统允许的范围内保证App正常运行。如果以Web方式接入App的页面没有一个明确的标准和严格的验收机制,相应的Web实现则不会过多考虑这方面的问题,而且浏览器也没有给前端工程师提供足够的Api支持处理内存问题,导致在某些条件下造成App无法正常运行,甚至Crash。

同样的问题会出现在网络环境方面,虽然现在wifi覆盖越来越广,3G网络也日益普及,但App运行的网络环境与PC相比仍然有着巨大差距,wifi和蜂窝网络的切换,基站变化等诸多因素都会导致网络间歇性断开。Web开发总是默认有一个稳定的网络环境,因此在对于不稳定网络环境问题的处理上也有所欠缺。没有明确的对于低速网络或不稳定网络访问的处理,在很多情况下这些页面也会非常不给面子。

误区三:富交互导致体验差

这里所谓的体验问题一分为二:一是与手机平台默认交互习惯不一致的体验,二是与同样功能Native界面存在的体验差距。

无论在Android还是iOS平台上,都有各自的一套交互习惯,包括视觉风格,界面切换,操作习惯等,与Web习惯完全不同。如果使用Web方式开发富交互的页面,或多页面功能就会出现这样的问题。

以iOS界面切换为例,系统风格是新界面自右向左推入,后退时界面自左向右推出,而旧界面保持状态。Web开发的默认习惯则是刷新页面,无论新载入页面或是后退,都会对页面进行刷新。因此使用Web模式开发多界面功能就面临这样的交互习惯差异,造成体验上的损失。当然Web方式也可模拟Native的交互方式,但这样的模拟首先提高了开发成本,有悖于最初的高效原则,从效果上看,也很难达到Native的流畅性。

另一个方面,也是上述提到的与Native相比,同样的功能在性能上存在巨大差距。Web界面上JS对HTML Node的操作需要消耗大量的CPU资源,手机CPU的性能还不能与PC相提并论,就算在智能手机之间,硬件水准也参差不齐,一个可以在iPhone 5上流畅运行的界面,跑到三星S III上很可能就卡住不动了。所以我们经常可以发现一些富交互页面上的操作无法达到令人满意的流畅度,而流畅度也正是用户评价一款App优劣的最直观因素。

误区四:跨平台

一次开发,跨平台运行是Web的优势,这也是很多App采用Hybrid模式的重要原因之一。兼容性问题在Web开发过程中往往不被关注,但当下智能手机的软硬件版本众多,兼容性绝对是一个不容忽视的问题。

以Android手机为例,诸多主流品牌都有各自定制过的操作系统,浏览器内核对JS和CSS的解析,事件处理等方面都存在区别。以HTC One为例重叠在一起的层在某些情况下会对点击事件透传,而其他多数平台则不存在这个问题。并且目前移动平台的开发框架还没有完全成熟,可以很好的解决兼容性问题。所以就要求开发者在开发过程中要对兼容性做充分测试,对于某些特殊版本进行特殊处理。

即使在相对统一的iOS平台,不同版本之间也存在较大差异。例如:在iOS 4.x版本中CSS甚至不支持position fix的属性,4英寸屏幕的设备无法很好的支持apple-mobile-web-app-capable属性,等等。

误区五:交互一致性。

交互一致性是一个非常容易被误读的概念,“一致性”经常被理解为同一个应用在各种平台和场景下要有一致性的体验。我认为在移动平台开发过程中,“一致性”应该是App视觉和交互习惯与其运行平台的习惯保持一致。而Web开发“一次开发,跨平台运行”的特性与此存在一定程度上的冲突。

以“返回上一页面”的操作为例,在iOS平台上在页面顶部始终存在一个44像素高的导航栏,左侧有一个返回按钮用于返回操作,而Android平台则习惯使用设备提供的返回键操作。这个返回按钮在iOS平台可以通过绝对地址的方式连接到任何其他页面,而在Android平台返回按钮和设备的返回键则可能指向不同的位置。

例如这样的一个流程:首页->列表->筛选->刷新过的列表,此时的返回操作被期望是导向首页,则页面上的返回按钮可以通过绝对链接的方式实现,而Android设备的返回键则只能返回上一个筛选页面,再次返回是筛选前的列表页。

Hybrid App方案是一把双刃剑,一方面它平衡了Native App和Web页面的优缺点,一定程度上解决了Native App开发过程中迭代慢,版本依赖,Native开发资源不足的问题,但另一个方面过度依赖Hybrid方案会造成Web前端开发成本快速上升,甚至造成App整体体验下降,甚至造成功能缺失。

不要为了Hybrid而Hybrid,控制好方案中Native与Web的边界。

扩展阅读

较早Mobtest针对Facebook的iOS App专门做的一片评测文章,阐述了使用大量HTML页面的App出现的问题:http://blog.mobtest.com/2012/05/heres-why-the-Facebook-ios-app-is-so-bad-uiwebviews-and-no-nitro/

资深开发者@李秉骏 在InfoQ发表的《Hybrid App实战》,阐述了Hybrid模式的优势与劣势,并简单介绍了开发Hybrid App所需的技术储备,供读者参考。:http://www.infoq.com/cn/articles/hybrid-app-development-combat

资深开发者@唐巧 较早对Hybrid App主流框架PhoneGap的分析文章,笔者非常同意对PhoneGap框架的态度,PhoneGap虽好,可不要贪杯哟:http://blog.devtang.com/blog/2012/03/24/talk-about-uiwebview-and-phonegap/

————–
转自infoq:http://www.infoq.com/cn/articles/hybridapp-misunderstanding

Hello World 业界杂谈 微信开发

微信公众平台的新功能

在犹抱琵琶半遮面了N久以后,小伙伴们期待已久的新版微信公众平台后台终于上线了,这次上线的,不仅有页面的改版,更带来很多实用的新功能

比如统计功能,可以统计用户、消息的各种数据
再比如商户功能里支付测试支持,以及对浏览次数和成交量的统计

当然啦,对于开发者来说,最吸引我们的还是伴随而来的新开发的各种接口以及姗姗来迟的调试功能

“微信公众平台接口调试工具”是一个很好用的功能,可以让我们在不使用服务器的情况下就可以调用各种接口,估计以后会很常用

下面,我们来盘点一下微信公众平台对普通公众号开发的接口们

  • 1. 基础接口
    1. a. 服务器配置的验证
      这里,是你在设置服务器url时,微信会验证这个服务器的正确性,具体的,包括代码回复格式的正确性,以及对应的微信号是否正确
      b. access_token的获取
      “access_token是公众号的全局唯一票据,公众号调用各接口时都需使用access_token”,有效期两个小时
      特别注意,是“唯一”,比如对于同一个工作号,一个项目里先申请了一个access_token,另一个项目里又申请了一个,则在第一个项目里的access_token就已经失效了(即便没有超过两个小时的时限)
  • 2. 消息相关
    1. a. 接受消息
      在微信开发平台后台配置了“服务器配置”的url后,再有用户给公众号发送信息,就需要你的服务器来回复信息了
      接受消息包括文本、图片、语音、视频、地理位置,以及链接
      在这里,服务器收到的数据是xml,我们回复的,也需要是xml
      b. 语音识别结果
      “开通语音识别功能”,可以将语音信息对应的文本信息一起发送给服务器,可以那它语言搜索内的功能,如果再和上面的“上报地理位置”结合,就更有想象空间了~~
      c. 主动向用户发送消息
      之前,要主动向特定用户发送消息,只能使用微信的模板消息,使用起来相当复杂
      有了这个主动消息接口,问题就简单多了,“当用户主动发消息给公众号的时候”,开发则既可以在24小时内,给该用户发送消息,包括文本、图片、音视频、图文
      从这里开始,消息的数据格式变成了json
      d. 上传下载多媒体文件
      如果你要给用户回复、发送语音、图片、视频等内容,这个接口是非常必要的
      接口返回media_id,在3天之内,便可以随便使用这个media_id来使用你的多媒体信息
  • 3. 自定义菜单相关
    1. a. 自定义菜单的增删改查
      微信终于全面开发了自定义菜单的功能,有了自定义菜单,才有可能以微信为平台构建我们的“轻App”
      b. 自定义菜单事件
      微信的自定义菜单,可以是一个链接,也可以是发送给服务器的一个事件消息,然后服务器回复对应的消息,回复的格式同上面第2部的“接受消息”
  • 4. js api
    1. 当用户在微信内置浏览器访问我们的页面时,我们可以通过jsapi做下面的事情
      a. 获取用户网络状态,包括wifi、2G、3G
      b. 隐藏右上角分享按钮、隐藏网页底部导航栏,让你的页面更像原生应用
  • 5. 地理位置相关
    1. a. 上报地理位置
      “开通了上报地理位置接口的公众号,用户在关注后进入公众号会话时,会弹框让用户确认是否允许公众号使用其地理位置”,弹框只在关注后出现一次
      “进入时上报地理位置”,”每5秒上报一次地理位置”,这又是一个看起来很牛x的功能,我们可以围绕它做出类似导航、购物搜索的功能
  • 6. 用户信息
    1. a. 分组管理
      通过服务器增删改查分组信息,比如,可以将关注用户划分成主动向公众好发送过信息、发送过地理位置信息、回复过xx信息等等

      b. 获取用户基本消息
      “关注者与公众号产生消息交互后”,公众号既可以获得该用户的基本信息,包括昵称、头像、城市、性别等

      c. OAuth2.0
      当用户在微信内置浏览器访问我们的页面时(不需要必须关注公众号),我们就可以获得访问者的openId,以及用户的其他基本信息
      如果你执行获得访问者openId,通过几次redirect,和普通的OAuth过程是一样的
      如果要获得用户基本信息,微信就会弹出授权界面,并且每次重新再试图获取用户信息是,微信都会弹出授权界面

      d. 获取关注者列表
      终于有了同步所有关注用户列表的接口了!

      e. 扫描带参数二维码
      这是一个相当强大的功能,可以让用户扫码后自动关注你的公众号(需要用户点一下“确定”),同时你还可以给用户回复一条欢迎信息

上面只说了微信开发接口的功能,具体的接口地址、参数什么的,同志们可以自己到公众平台的开发者文档里去查询

———
参考:微信公众平台开发者文档

业界杂谈

微信

虽然微信已经出来2年了,作为一个对新鲜事物不甚敏感的人,我是从三个月前,因为要为公司做微信相关的项目,才开始关注微信的
开始的时候,还以为微信api就像微博一样,也就是发发微博之类的功能,但仔细看了微信公众账号的api以后,最大的感觉就是:哇塞,这玩意好牛逼~~~微信并没有说自己可以干什么,却也没说自己不能干什么~~~微信就是一个一对一的交流平台(当然,也可以一对多),可以文字、图片、位置、语音~~就像两个人聊天一样,所以能通过聊天做的事,通过微信也能做

昨天的腾讯合作伙伴大会,下午的微信专场里,除了介绍5.0的新功能意外,还有十个来自各行业的微信公众账号做经验介绍,这其中,既有各类企业用户,也有如广东公安这样的政府部门,在他们的使用中,大概包括了下面的功能

1. 客户服务
基于微信的一对一交互,客服平台是最常见的微信功能,甚至不需要对它做什么开发,直接使用腾讯自身的微信后台就可以完成这个功能
2. 营销
虽然腾讯并不想让微信成为营销工具,并且给群发功能加了很多限制,但却也挡不住用户从微博上继承来的习惯,不过效果怎么样,就很难说了
3. 查询
比如说,在做了账号关联后,查询订单信息,查询信用卡账户信息,查询的介质,可以是文字,也可以是语音、图片、以及位置
4. 替代APP,完成更加复杂的功能
对于界面要求不高的应用,完全可以使用微信公众账号替代APP,比如生活服务类的应用 出门问问,完全没有APP,通过微信实现所有的文字、语音的问询服务等功能

在5.0的微信,还将加入微信支付的功能,这样,一大批电商就可以直接在微信里卖东西了

关于使用微信的一些使用建议,@青龙老贼 给出建议最有参考价值:互动塑造品牌,服务创造价值,走原创化精品化专业化的道路

Hello World 业界杂谈

nodejs-express初体验

上次文章提到,正在用nodejs做一个小项目,现在总算是做完了

学习/搞着玩是一回事,虽然两年前就开始接触nodejs,做实际要用到项目里是另一回事,经过两周的折腾,我这里不想夸,也不想踩,只想说一下我真实的感受,给准备用nodejs的朋友一点参考

整体来讲,nodejs+express的开发模式,感觉还可以,既不像前端大牛们说的一样好,也不像另一些人说的那样一无是处,下面针对几个关键点分别说一下

1. express

早就听人说过,express是个“优秀”的web框架,我这次的使用体验,却让我没有这种感觉。大概是用惯了cakephp那种规约编程/傻瓜化的web框架的缘故,我觉得一个框架最应该做的,就是让使用者不要过多感觉到框架的存在,以最简单的方式获取请求参数/调取model/lib/以及向view层传递显示,可以让人将所有的精力都投入到业务逻辑中~~要不我还用你框架干嘛?

对express,最别扭的一点,就是它的routes配置~~居然每一个请求的url都要去做配置,让我一下想到了java/spring mvc的那个xml~~懒婆娘的裹脚布也不过如此

另一个sb的地方,是它的logger~~本来不想重写日志类的,特别是access日志,服务器能自动记录最好,找了好久,才找到如何设置express 日志的格式,可是设置好以后,发现日志时间记录的不对,格式也不好看,一查原码才发现,logger里用的是date.toUTCString~~UTC啊,尼玛我看日志的时候,还得想着和实际时间差8小时。。。

最关键的一点是,express官方的api极其“简约”,很多东西不得不去翻框架原码才能发现一些“隐藏”的功能

最后,作为一个web框架,居然没有filter,虽然app.use可以部分实现filter的功能,但用起来还是感觉很不爽

2. npm

npm真TMD乱,很多好名字都被占了,占着茅坑不拉屎

比如thrift,装上以后发现根本不能用,版本太老,仔细一看,居然2年没维护了

再比如email,居然没看见在哪儿设置邮件服务器~~太TM扯淡了

3. 模板引擎

express默认的jade就不提了,稍微复杂点的页面,就会搞得一团糟

我用的是ejs,不好不坏,只能说“可用”。我比较喜欢view层代码,后端程序和前端html/js可以一目了然,所以我使用<%作为格式符,然后用jsp编辑器打开ejs文件~~哈哈,一目了然

ejs比较不好用的一点是对于变量的判断过于严格:如果试图输出没往view层传递的变量,页面居然会直接抛500错误~~太较真了吧,你当空串处理不久行了吗?

4. nodejs

不好意思,上面说了3点,大部分都是在踩,现在该说点好的了

js&node,本身还是一款很不错的组合,虽然异步编程需要一些时间来适应,但却给高并发和快速影响带了了天生支持;另外,js语法简单自由,也可以带来很高的开发效率

对于所谓的“前后端共用代码”,我倒是觉得不太有必要~~毕竟,前后端执行环境差异巨大,写这种“公用代码”的维护成本,还不如直接copy一份给前端用

最后,给自己留一个问题:下次你还会选nodejs吗?

以前写过一个简单的前端mvc框架,jLeaf,基本思路是模仿cake和spring来做的,node出来后,曾经想顺势再写一个后端框架,名字就叫jRoot,可惜因为工作忙,也因为人懒,没能实际做出来,看到express这么难用,真想现在就把jRoot做出来,可惜现在更忙了~~~希望后面能有时间把它搞出来,也希望node能有其它更好用的web框架出来