Web前端工程师在Facebook API开发中常见问题汇总

对于一个熟练的PHP程序员或者JAVA Guru,开发一个Facebook App可能还是很容易的,毕竟Demo文档非常齐全。然而,对于同样渴望开发优秀App的前端工程师,入门的门槛可能还是要高一些。好在Facebook为我们提供了强大的文档,更好在,我,Aw,也是一名关注Web前端技术的开发者,归纳总结了一些个人的经验与大家分享:)

  1. 如何上手
    首先,我建议使用PHP的开发方式。没错,既然你是一个对服务器端编程一点都不懂的前端工程师,为什么要去花时间折腾文档和Demo较少的其他服务器端语言呢。我并不是PHP的“粉丝”,但范例最多、配置最快并且有Facebook官方支持的,似乎只有PHP了。
    然后去官方看这些内容,非常详细(但不太容易找到):
    App所具备的一些要素
    手把手叫你开发一个App
  2. Callback到底是什么
    Callback URL和ActionScript中的Call Back函数还是不太一样的。
    CallBack URL说白了,就是你自己的服务器的一个URL,比如,我的awflasher.com/someurl,在这个URL上,输出一些“相关内容”给Facebook的Canvas来进行渲染。关于这一套流程,强烈建议看这篇(翻到下面),也是在Wiki里面藏的特别深很难找到的:这么重要的问题,居然藏在一个“Random Questions”里面。也可以看这张“图”
  3.                            +------------------+
                               |   BROWSER        |
                               |                  |
                               |   +-------------+|
                               |   |Application  ||
                               |   |Canvas       ||
                               |   |             ||
                               |   |             ||
                               |   +-------------+|
                               |                  |
                               +---+----------+---+
                                   |          ^
                 1) Browser makes  |          | 5) Facebook Renders FBML to
                          request  v          |    HTML
                             +-----+----------+-----+
                             | FACEBOOK SERVER      |
                     +-------+                      |
                     |       |                      |
                     |       |                      |
                     |       |                      +<-------------+
                     |       |                      |              |
                     |       |                      |              |
                     |       |                      |              |
                     |       |                      |              |
                     |       |                      |      4) App Server
            2) FB Server Calls                      |       Returns FBML
              out to App Server---------+-----------+              |
                     |                  ^                          |
                     |                  | 3) App calls FB API      |
                     |                  v                          |
                     |        +---------+------------+             |
                     |        | YOUR APP SERVER      |             |
                     |        |                      |             |
                     |        |                      |             |
                     |        |                      |             |
                     +------->+    2.5) App server   +-------------+
                              |       composes API   |
                              |       calls          |
                              |                      |
                              |    3.5) App server   |
                              |       generates FBML |
                              |       from API results
                              +----------------------+
  4. 官方提供的PHP client包存在的一些细节问题

    我到现在也不知道官方提供了多少个PHP版本。似乎在Developer的App页面(简写为:apps.fb.com/dev和dev.fb.com)和Developers的Wiki页面有许多不同的范例。这其中有很多不规范的地方,例如:

    把<?php echo getFriends();?>写为<?=getFriends()=?>之类的“简写”。这对于刚配置好的PHP环境实在是让人无从调试(因为你想不到官方提供的代码可能有问题)

  5. PHP开发中常遇到的问题

    前端开发者的思路似乎更“粗糙”一些,我就有这个毛病。我在开发Facebook App的时候经常犯的错误就是把HTML和PHP内容混到一起了,例如:

    <?php echo ‘<p>test’.$somevar.'</p>’;

    <br>

    ?>

    这样的写法乍一看没问题,但实际上中间的<br>是PHP根本看不懂的。在大多数配置下,这个错误根本看不到(不像Flash那样会有一个Compliler帮你报错),遇到这种情况,如果是少量HTML,就给它echo出来;否则,就将PHP标签结束再输出,例如:

    <?php echo ‘<p>test’.$somevar.'</p>’;

    ?><br><?php … ?>

  6. FBML的设置

    最关键的setFBML是把FBML显示到用户个人主页的函数。在使用这个函数的时候,一定要确认用户已经“同意改变profile box”,这是安装App的几条协议中的一条。如果你自己调试期间不希望被别人看到而当时没选中,那么很可能是导致你多次无法看到相关内容出现的主要原因。

此文仅是抛砖引玉之文,因为也许我遇到的错误其他人又很容易地解决了,欢迎补充,我会保留链接。

【更新整理】Web前端工程师技能列表

我自己的公司正在招聘前端工程师,有兴趣者烦请移步此日志

要打造一流的Web产品开发团队,在团队成员基础能力上一定要下功夫。对于Web前端产品开发来说,仅仅掌握Web1.0时代简单的”网页套接”是完全不够的。我结合自己的团队配备,特此罗列了Web前端产品工程师所涉及的技能列表如下:

通过许多实际项目,个人认为一个完备的前端产品开发团队,必须拥有如下的人才配备,也希望大家补充:

  • 团队全体成员达到所有技能中的a级标准
  • 团队全体成员必须掌握两项技能中的b级标准,并保证所有的b级标准在该团队中有50%以上成员能达到
  • 团队全体成员必须掌握一项技能中的c级标准,并保证所有的c级标准在该团队中有25%以上成员能达到

具体技能描述:

  • 【必备】UserInterface
    1. PhotoShop/Fireworks Design
      a – 配合美工将草图形成具体的符合WebPage的设计
      b – 有快速制作分层高品质PSD、PNG的能力
      c – 能迅速将PSD、PNG的内容构思成div+css或者table等HTML代码
    2. Flash Design
      a – 基本动画效果
      b – 复杂的交互体系设计,了解第三方swf辅助设计软件
      c – 复杂的交互体系设计以及较强的对各类外埠资源(PNG、JPG、MP3、WAV等)的整合能力。精通部分第三方辅助设计软件(AE、SwishMax、Swift3D等)
  • 【必备】Browser-side (Web Application)
    1. XHTML/CSS
      a – 基本的layout实现
      b – 严格跨平台的layout实现以
      c – 优雅的HTML code,尽可能符合标准并有SEO的考虑因素。在任何平台、浏览器下基本保持一致。不要求了解各种CSS的hacks,但要求知道遇到问题应该如何查阅资料以在第一时间内解决。能够为JavaScript开发人员提供最好操作的DOM结构,让JS开发人员在开发的时候认为”一切都已经准备就绪了”,而不是”捉襟见肘”。
    2. JavaScript/Ajax/DOM
      a – 基本的DOM操作,了解AJAX,可以实现数据通信
      b – 基本的DOM操作,能写高效率的OOP代码,以降低维护成本
      c – 基于需求,进行不同的开发,选择合适的框架,做到代码效率最高,用户体验最好,代码下载量最小,并且可以在单独甚至更多产品线中最大限度重用代码
    3. Flash Developement
      a – 基于Timeline的ActionScript操作,能实现简单交互
      b – 掌握a外,能实现数据层通信(与服务器以及本地SharedObject)
      c – 精通AS1-3,能根据需求进行各类RIA开发。无论是要求支持FlashPlayer8的,还是FlashPlayer9的,都能做到开发效率最高、灵活性最大(比如对HTML层的接口设计,等等)。
  • 【必备】Client-side (Desktop Application)
    1. Apollo
      a – 产品级的封装,基本技术了解(如何打包、如何加入HTML和JavaScript等)
      b – 掌握a的同时,能利用Apollo的API独立设计、开发OS的文件I/O功能。
      c – 掌握基本技能的同时,对”3D概念体系”有所认知。这里”3D”即:Design(设计)、Development(开发)、Deploy(产品部署)。能用Apollo
    2. Windows Presentation Foundation、WPF/E(Silverlight)
      (待定,欢迎补充)
  • 【增补】Server-side (修改:经考虑,这个技能不参与评级)
    本来列举了”1、Server端简单的技术、脚本”和”2、MediaServer(Red5)接口”作为”Web前端工程师技能列表“的一种(服务器、数据逻辑层技能的)评判标准。但似乎很多朋友对于前端工程师是否应该掌握Server端技能的必要性表示怀疑。确实,要掌握好上述的展现层技能不是意见容易的事情,而且前端工程师的确非常辛苦。但是,站在另一方面来说,辛苦的原因是什么,我不知道在你日夜奋战div+CSS的时候思考过没有。就我的经验,前端的辛苦在于以下几个方面: 

    1. 重复劳动多,大量的div+css都是重复的,即便可以复制粘贴,但几千行的div海洋中去寻找一个入口恐怕都非常痛苦
    2. 需求变更多,往往你折腾几个小时终于把跨平台问题解决好了,而且在IE6、7和Firefox下面都能显示同样的效果了,甚至连JavaScript交互都已经快搞定了。突然上面说需求要变。这无疑是莫大的痛苦。

    也许表面上看,这跟Server端技能无关,但我觉得有好的Server端的意识,一定会有所帮助(当然不可能解决所有的问题)。毕竟信息结构和数据库是密切相关的,而Server是连接数据库的唯一渠道(至少大多数B/S应用是如此)。掌握Server端的基本技能,对于同逻辑层开发人员设计接口是非常重要的。而且HTML表现层在开发时与数据的分离,也与Server端的各种模板技术有关。例如PHP中的Smarty模板(我曾经用的)、jsp的model2概念等等。HTML结构如何设计,如何让HTML重用,甚至在HTML层进行OOP的开发(我现在在新产品线中设计的前端开发流程),都需要Server端的支持。最起码,你要告诉php程序员你需要什么。如果你完全对PHP一无所知的话,那也无从谈起了。
    此外,对于创业团队,往往人手非常有限。为了让运营成本降到最低,所有的技术人员都有义务对Server端技术有所了解。如果为了修改一个网页的标题还要跑去喊PHP程序员连接Remote Server的话,那实在是增加了整个公司的运营成本。
    总结:我认为,可以不了解技术细节,但应该知道原理,最好能掌握一两套设计思想(毕竟数据逻辑都在这里走,光看HTML和JavaScript,对人的见识还是有局限的,这种局限限制了我自己很久的时间),那将是一比宝贵的财富。

  • 【增补】Mobile-side(不参与评级)
    1. Flashlite
      (待定,欢迎补充)
    2. Java?
      (待定,欢迎补充)

看到很多朋友留言说前端工程师没前途,我在想,同时掌握移动设备的技能是否也是拓展前途的一个必要性?这里再多说几句,关于技术人员的前途,目前在国内确实得用”惨淡”来形容。浮躁的氛围让技术人才往往过早放弃了自己的技术生涯,而尔虞我诈的整体道德水平也让单纯的技术人员痛不欲生(我身边太多了,恩,不说具体细节了,呵呵)。

作为一个技术人员,开发人员,在保持纯粹地敬业心态(这是前提,这么没有,啥也别谈)外,更要学会如何保护自己,如何壮大自身,社会不会同情你,只有你自己才能保护你自己。

调研结论:DIV+CSS为什么好?(更新)

DIV+CSS为什么好?
by aw(awflasher.com) 转载请注明出处 – http://www.awflasher.com/blog/archives/583

再论DIV+CSS (Updated Content)

虽然目前在公司相当忙,但是仍然有必要讨论一下div+css的问题。因为它已经不再是两年前那个新鲜的名词了。它正逐渐步入广大传统Web开发、设计人员的视野。它的好、他的坏,已经逐渐开始成为前端开发工程师争论的焦点。

今天偶然看到“一个有将近两年的div + CSS 开发经验和历史,曾经是Web标准绝对拥趸的同志”在自己的blog上发表放弃div+css的申明。我更深感一种悲哀——特别是当我苦口婆心地劝说公司的前端开发人员开始学习DIV+CSS的时候。

不过看看这个“好同志”放弃的理由的其中两条,不禁让我所心冷。

  • 公司领导及客户不关心这个,他们需要的是快速、高效的工作和花哨的页面
  • 所费功夫与收入不成正比,利用table可以大大减少工作量

确实,当今市场环境下,div+css对于一个财力一般的公司是一种奢侈。尤其是对于那种靠业务员疯狂跑业务而存活的(不打算上市)的公司,是一种莫大的浪费。我在广州曾见过许多“三天建站”的公司其中90%的人在外跑业务,然后10%的web开发设计人员把凌乱不堪的HTML代码片段一遍一遍的往table里面塞。

甚至可以这么说,一个公司对div+css的认同和投入,直接决定了这个公司的期望目标,比如上市。好在我现在所在的公司在这一点上是非常愿意付出代价的。

其实,在具体商业产品实现上,并非一定要把自己拘泥于“Web标准绝对拥趸”的角色。我们似乎应该静心思考为什么使用div+css,而不是如何实现某个细节。

我们公司面临的困境则是相反的。就是太拘泥于div+css、为了DIV+CSS而DIV+CSS。这样做是毫无意义的。如果为了实现一个效果而不顾策略强行使用一种技术,是非常失败的一种做法。当然,我觉得这需要设计人员与开发人员的共同努力和让步。尤其是在B/S架构下。设计者肯定要做出更多的让步。比如某个布局中1px的差距能节省3k的HTML文件size,哪怕放弃视觉上这1px的效果,我看都值得。更何况,大多数干扰DIV+CSS布局的设计本身也是极不美观的。

movivi.com的SEO我思考了很多。我觉得最大的问题就出在我们并没有足够吃透W3C上。

当时,当w3c刚出的时候,三大门户十分不屑。清一色的table遍布整个首页。可是这样导致的问题不久就暴露出来了。搜索引擎爬虫难以解析复杂的table,而样式的改版也极为难受。

div+css,这个布局中,div承载的是内容,而css承载的是样式。内容和样式的分离对于所见即所得的传统table编辑方式确实是一个很大的冲击,尤其是设计人员很难接受设计一个他们不能立即看到的样式。不过div+css的好处实在是太明显了:

1、搜索引擎亲和力:搜索引擎不会在意一个页面的设计或者构成。搜索引擎不可能“欣赏”设计漂亮新颖的页面;也不会去“排斥”颜色搭配丑陋的页面。它们只是默默地拿到它们需要的内容就离开。如果一个页面中涵盖了大量的table来描述构架,试想搜索引擎要花多大的代价才可以拿到真正有用的信息呢?
凭我自己的经验,一般来说,table构架描述的页面,样式结构和内容信息大小比可能达到1:1甚至更高。而CSS+DIV构架的页面,虽然在客户端看来下载一个复杂的CSS也要占用差不多的带宽,然而搜索引擎可以很方便的绕过这个css,而直接抓去div中的内容。这便是div的优势所在。带宽的稍多占用,完全显得微不足道,更何况一个冗余的table设计架构如果代码写的不好会占用更多的带宽。

2、重构页面的方便性
这个应用最经典的例子就是各大blog程序了。就如现在我用的LBS系统,以及流行的PJBLOG、php下面的WP、MT,都是采用div+css构架。内容和样式的分离导致我们在重构页面布局(更换皮肤)的时候,只用针对每一个div元素重新定义其具体位置、样式就行了。而在原来的table基础上进行改版,几乎必须改变所有的内容注入渠道,实在是太过于麻烦.
关于韩国风格网站难用div描述的问题,我个人认为在web2.0的大军冲击下,韩国的花哨流派很快会被简约派所代替。如果确实是优秀的设计,我个人认为用Flash来完成更好!

http://awards.cssmania.com/2006/07/07/css-world-awards-winners-2006.php
2006年CSS世界大赛得奖作品,看看什么叫做W3C下的完美艺术吧!看看人家的PR吧!