最近的几天的主要工作就是朋友网V4版本推出的名片分享发feeds。因为前台是DIV+CSS展示，前台截图生成图片不是那么的容易。因而交给后台来处理。其实后台也不容易啊。需要一个字一个字的画上去，之前也做了相关的图片加文字的工作。现在需要做的就是把文字内容和图片内容(用户头像)拼到大背景上去。然而有几个难点：
a) 能得到的图片，包括用户的头像信息，和用户设置的自定义的图片信息都是url，图片是存储在存储平台那边的，当然浏览器端要获得相应的图片非常简单，请求链接即可返回图片数据，然后后台服务器就不是那么简单了，没有DNS等解析，无法通过链接得到相应的图片数据，直接IP不可能，那么多图片不是存储在一台服务器上。后来采取的解决方案是通过代理，用一台代理机器，有DNS等服务器去请求，再将数据返回，通过curl去下载图片到服务器，进而再进行相应的拼图操作。
b) 在上一步的操作中，从去请求下载图片到拼图这一整个过程完成，需要耗费不少时间，同步做肯定用户受不了，于是要做成异步的，还好公司有一个异步请求的框架SAPS，能够解决这一问题。
c) 实际的逻辑处理工作，就是取用户的基本信息，还有用户设置的名片等详细信息进行拼图，这个过程比较繁琐一点，虽然没有什么技术含量，要一个一个去试，到底怎样的位置比较好。取用户头像跟名片信息画在一个画布上，再作为整体画在大背景上。如果是完全透明处理，则不用建中间小名片的画布，直接将头像和名片信息印在大背景上。前台的坐标值跟后台拼图时的坐标值是不对应的。还有就是图片压缩，用户自定义的图片过大或者过小，都使得生成的图片不怎么标准，最后上传至用户的相册中进而发分享展示feeds就不那么美观了。
就这样，经过测试测试，测出了介绍的文字太长，我没有做截断处理。典型的边界问题，以后还得多注意。改后第一个版本就发出去了，然而后续相继出现了几个问题。首先遇到的一个问题就是，在预发布环境下，设置图片发分享等都OK。发布到外网就不行了。后来查是因为发分享时，分享的是一个跳转至用户名片页的链接，这个链接是相似的，仅仅用户的hash码不一致而已，因此就被安全中心个旁路了，因防止用户分享大量相似链接，这种链接包含广告等垃圾信息而采取的措施，解决方案就是周知安全中心，加白名单，因而能够顺利分享出去。还有一个问题是因为自己的疏忽造成的，拉去用户的头像图片和用户自定义的大背景图片到本地时，我都采取了以QQ号作为标志存储，然后却忽略了中间小名片，我都生成了一章相同文件名的临时文件。这样就悲剧了，高并发数据请求过来，生成的名片信息完全可能出现了，你的名片信息打印到了我的背景上面，本来是A分享出来的数据，结果上面的B的名片信息。还好当时安全中心旁路的原因没有给发出去，否则后果不堪设想啊。
因为开始安全中心旁路的原因，导致分享失败，滞留了两个多小时吧，在SAPS里面的消息队列里堵住了，滞留了10W+的用户请求，后来处理问题后加白名单，才慢慢看到用户分享出来的数据，当时晚上高峰期间，处理速度<请求速度，saps队列不断增长，最后可能导致宕机。可能采取的办法是增加saps服务器，后leader说先等一晚上处理后再说，第二天队列正常。
发布到外网后，还遇到了一个bug，就是如果用户设置完全透明，且是白色背景。点击设置名片模版，在这里可以设置，看不到名片信息。后来查是因为这个原因：
The two images will be merged according to pct which can range from 0 to 100. When pct = 0, no action is taken, when 100 this function behaves identically to imagecopy() for pallete images, while it implements alpha transparency for true colour images. |
即将 src_im 图像中坐标从 src_x，src_y 开始，宽度为 src_w，高度为 src_h 的一部分拷贝到 dst_im 图像中坐标为 dst_x 和 dst_y 的位置上。两图像将根据 pct 来决定合并程度，其值范围从 0 到 100。当 pct = 0 时，实际上什么也没做，当为 100 时对于调色板图像本函数和 imagecopy() 完全一样，它对真彩色图像实现了 alpha 透明。我在处理过程中，直接取了用户设置的透明度，忽略了前台CSS透明度和后台php函数处理参数不一致。
第一个版本发出去后，收到各种产品要说需求要变更，各种痛苦，难怪人人上有一个这样的状态
你TM再改，还让不让人睡觉了！！！转自张剑光.class: 需求又改了？改你妹，心里暗暗骂一句，骂完继续苦逼的改代码转自柴一平: 额~转自王丹:转自刘登科:转自段晴:转自刘科: 需求又改了？不如死了算了，一了百了。需求是魔鬼。转自邱从贤: 转自何亮: 转自瑞小熊~~♪:: 转自沈隆:【程序员遇车祸成植物人 需求改动将他唤醒】北京某互联网公司程序员王某遭遇车祸成植物人,医生说活下来希望只有万分之一,唤醒更为渺茫.他的Leader和亲人没放弃,他们根据王某视工作如命的作风,每天都在他身边念:“需求又改了,该干活了!你快来呀!”奇迹终于发生,王某醒过来了,第一句话:“需求又改了?” ——这是喜剧还是悲剧？？？？ ”
——深深体验到了这一点。
后来跟产品，开发等几个人碰头敲定，再改。这下要求产品给出明确的需求了，找设计商量好后，最后的效果到底要怎么样才算OK。给出了设计图，字体字号间距等都给了我。开发确实苦逼，按照设计师给的，还得给出效果图给她看，然后不满意，再改……呃，不过这个改让我也好受点儿嘛，至少不让前一个版本那样，需求一点都不明确，大小之类就由我拍板定，最后效果不满意还得自己慢慢改。下一个版本估计下周会发.这个版本把中途的小名片突出了下。
以前上项目管理的课的时候也提到过，需求等等一旦定下来，要开发啊产品啊等等签字确认OK，后面再改就没有话说了，现在公司的敏捷开发也用到了这个，比如要求开发自测，得在需求单上注明开发已经自测通过，产品也体验过，再转交测试……这样，也有证据了，再遇到什么问题，证据确凿，各自的环节出了问题也没有啥话可说了。
