Blog

  • 电话收款的完美方案

    客户电话订货,他把信用卡信息告诉我们,我们通过虚拟终端收款;我们的软硬件都不够安全等级,不适宜保存客户信用卡资料;客户再次订货时,我们通常又得问一遍信用卡信息。这很烦人,客户有时也觉得烦,大大咧咧的客户更觉得我们保存信用卡资料比每次问要好。我觉得以现有的软硬件设施来保存客户信用卡资料是不合法的,但我们不能做的事情,我们的Payment Service Provider可以替我们做到啊。

    这个问题我已经想了很久了:客户能把信用卡资料告诉我们一次,也能把信用卡资料告诉我们两次;我们能从客户卡上划出一镑钱,也能从他卡上划出两镑钱。这个前提是客户给与我们充分的信任。如果我们是诚信经营的,那么客户把信用卡资料告诉我们一千次也无妨,反之,哪怕一次也是祸害。

    从理论上讲,Payment Service Provider是支付网关,当它的虚拟终端被我们使用一次以后,它就保存有客户的信用卡资料,以后同个客户再来付款,它就没必要让我们再从客户嘴里套问一遍信用卡资料。

    但事实就是这么残酷。对于老客户的电话订单,一直以来我们总是反复问同一个客户几个同样的问题:持卡人姓名、账单地址、邮编、卡号、到期日、安全码…

    直到本周我们新换了PayPal做我们的Payment Services Provider,我的牛劲上来了,追着PayPal Support问:能不能有一种结合Virtual Terminal(能电话收款)和Recurring Payments(能定期收款)两个产品特点的新产品,能在客人每次下电话订单的时候收款,但不用每次套问信用卡资料?说实话,我本以为PayPal不会有一个现成的方案,我只是想建议他们推出这么个新产品,可以方便广大商家。

    不知道是PayPal Support笨,还是我表达得不够清楚,抑或是PayPal根本不想推广这个方案,我跟PayPal Support一来一去足足有四个来回才知道他们有现成的方案(藏这么好干吗?),前三个来回都是答非所问。

    现成方案就叫“New Reference Payment” ,就在每笔Virtual Terminal Payment的Details里找。

  • The Power of PivotTable

    突然发现 Pivot (数据透视表)很强大。

    我找了一份learning-pivot-table,方便我自己和对Pivot感兴趣的人学习。

  • What is vmware server default login?

    vmware server login page
    vmware server login page

    今天升级了 Vmware Server 到 2.0.0-122956。Vmware Server 2.0.0 给我一种耳目一新的感觉,我准备花些时间好好学习。安装完成以后,Vmware Server 的登录账号也出乎意料,google了一下才知道竟然是 Windows 的系统管理员账号(任何管理员权限的账号,不限于”administrator”)。

  • More About WordPress Uploads

    昨天写了一篇Migrating WordPress Uploads,我意犹未尽。

    每上传一个文件,WordPress会把它放在”Store uploads in this folder”指定的目录,但在post中都已转化成绝对路径来记录 Path 和 URL 。我不欣赏这种做法,因为这对服务器环境养成依赖。

    WordPress核心对”Store uploads in this folder” 和 “Full URL path to files (optional)” 不重视,造成某些插件也无视这两个options的存在。比如WP Shopping Cart,根本不去探测这两个值,直接就把产品图片等文件保存位置设定为wp-content/uploads/wpsc/… 。

    为了让WP Shopping Cart能够按照我的要求摆放文件,我只好修改了wp-shopping-cart.php,在 $upload_path 和 $upload_url 被调用之前,给它赋予正确的值。

    $myuploads = wp_upload_dir();
    $upload_path = $myuploads [‘basedir’];
    $upload_url = $myuploads [‘baseurl’];

  • Migrating WordPress Uploads

    我的blog迁移过一次,上次主要是为了更换domain name。今天我又成功地迁移了两个blog,这次主要是为了享受WordPress 一次安装,多处使用 带来的方便。

    但我不得不承认,WordPress迁移不是件容易的事。大部分的迁移工作是更该数据库里uploads文件的路径,这些值都是用绝对路径保存在数据库了。必须一一更改这些值(我喜欢export-replace all-import),否则文件位置的变动将导致链接失效。

    WordPress用了两个options来设置Upload Path & Upload URL,为什么不基于这两个值用相对位置来管理上传文件?相对位置的好处是:如果移动或改名了uploads文件夹,就只要修改两个options,而不必在posts和postmeta两张表里大动干戈了。

  • The First VirtualHost Is The Default

    今天在apache上搞基础建设,为一个小小的问题排错排了很长时间,事后想想,不就是一个简单的VirtualHost默认值的问题嘛!排完以后我才想来,其实以前已经碰到过这个问题,在一个问题绊住两次脚,浪费了一天,真是不应该!

    每个VirtualHost里有一个ServerName,还可以有零个及以上ServerAlias。假设一个 domain name example.com 的 ip address 是 201.202.203.204,  如果 example.com 在 .conf 文件里找不到同时匹配的 VirtualHost 和 ServerName (或ServerAlias),那么 example.com 将使用首个匹配的 VirtualHost (通常是 *:80 或 201.202.203.204:80)的设置。

    我把apache VirtualHost的心得写下来,免得以后再绊脚。

  • WordPress Commerce

    在WordPress基础上建设网店不是不可以,但毕竟blog和e-Commerce各有侧重。要做e-Commerce,自然而然就要求设置产品属性,相关产品链接,库存管理,价格管理,客户管理,销售报告等等。WordPress装个插件,如Instinct Entertainment e-Commerce plugin (WP Shopping Cart) for WordPress,做得相当不错,能完成基本的e-Commerce需求。

    但WP Shopping Cart只能是个轻量级的e-Commerce解决方案。它至少无法:

    1. 批处理
    2. 动态过滤产品 (按自定义属性)
    3. 产品套装模型
    4. 复杂价格政策
    5. 客户分组
    6. 自定义报告

    在WP Shopping Cart基础上改进一下,让它完成以上功能也不是不可能的。但我认为,如果你有以上需求,选择WP Shopping Cart就是个错误(谨记:WP Shopping Cart只能是个轻量级的e-Commerce解决方案)。

    此外,我在考虑:装了WP Shopping Cart plugin,所有的产品页面都是通过一个WordPress页面 (默认叫product-page) 调用,产品页面都是product-page子页面,本身不利于搜索引擎优化。而且,WordPress自身或WordPress SEO Plugins带来的搜索引擎友好的众多特性,产品页面无法享受到。虽然WP Shopping Cart针对SEO做了很多考虑,但WordPress SEO是众人拾柴,WP Shopping Cart SEO features无法与WordPress SEO features匹敌。

    其实大部分企业网站并没有购物车需求,只是一个简单得不能再简单的产品或服务展示厅(brochure site or showrooms)。如果WordPress category, tag, cusom field, search应用得恰当,不借助于e-Commerce plugin,也能用WordPress组建一个brochure site。如想要SEO,一个post对应一个产品是最佳方案。设计一个brochure theme就够了。

    找来找去,我没找到一个像样的 (适合摆放产品的) brochure theme。

  • An Ideal Way to Take Repeat Payments for Phone and Mail Orders

    We have lots of regular customers place orders over the phone. I am looking for a solution which can satisfy:
    1. We would not like ask credit card details every time;
    2. We can not store credit card details;
    3. It looks like a combination of Virtual Terminal and Recurring Payments, but these recurring payments do not have a fixed date and fixed amount;
    4. If possible, we create profiles for our regular customers. So, we, the mechant, can enjoy the facility of express checkout.

    Does PayPal, WordPay, or any other payment providers offer this solution?

  • Use Google App Mail In Corporation

    这里我只是想谈谈企业和个人在使用email中冲突,以及如何有效地应用Google App Mail来避免冲突。

    员工一录用,很多企业都会给员工一人一个企业域名、个人名字前缀的邮箱。作为对外业务联系的邮箱,应该保持稳定,但员工跳槽是普遍现象,英国人更喜欢跳槽,造成企业邮箱地址更新频繁。试想以下两个情景:

    情景一:企业开有 paypal 帐号以及多个银行帐号,由会计人员负责,每个帐号都会要求一个或一个以上联系人的电子邮件。会计人员换动,要一一更新这些帐号里的电子邮件地址吗?

    情景二:企业对网上业务的依赖度很高,企业对网上业务进行了细分,并有多名专员各自负责某项业务。网上业务对应的活动会直接通知到专员的邮箱。专员离职或岗位调动都要在网上业务的后台程序进行调整专员的电子邮件地址吗?

    我们很难找到一个现成的工具能在情景一和二快速、批量地修改电子邮件地址。

    也有企业干脆用sales, accounts之类的position 描述作为邮箱前缀,对外进行业务沟通。我不喜欢这样,发自sales@company.com的邮件给客户的第一感觉是冷冰冰,缺少personal contact的感觉。

    我们需要在稳定性和个性化之间取得一个平衡。My best practices are –

    1. 创建基于个人名字(personal.name@company.com)的邮件帐号
    2. 创建基于岗位名称(position.name@company.com)的邮件列表
    3. 把员工邮件帐号添加到他的岗位的邮件列表(基于这种目的创建的邮件列表通常只有一个邮件帐号,但一个邮件帐号可以加入多个邮件列表)
    4. 情景一和二采用position.name@company.com注册和发布联系人地址
    5. 发邮件时,发件人显示personal.name@company.com
    6. 客人第一次联系,如果是通过填写网上询价单的方式,业务的信息通过position.name@company.com的列表送达了personal.name@company.com,回信就没必要再通过position.name@company.com。
    7. 因为position通常比personal稳定,在情景一和二时,我们所要做的,就是在Google App Mail, Manage this domain, User accounts, Mail list里更新邮件列表
    8. User accounts, Nickname 方法 alias position.name to personal.name 也可以取得跟Mail list类似的管理效率,但如果position.name@company.com是一个nickname,如果要改变它的归属,就必须先删除position.name@company.com,然后到别人名下再创建一次nickname,虽然这过程最快可以在几秒钟完成,但在几秒钟内仍存在丢失发给 position.name@company.com的邮件的可能。用mail list就很完美(可以先添后删)
  • Wait 15 Seconds Problem Solved

    Upgraded phone plan以后,Orange给我一个新手机和一个新SIM卡,原来SIM同时也失效了。我搞不懂延续同一个号码为什么一定要换一个SIM?我对新手机不感兴趣,就把新卡插在了原来的SPV M600上,却发现不能收发短信,但拨打接听电话没有问题。

    新卡用在老机上发短信时,会出现”Your phone is not ready. Please wait 15 seconds and try again.”的提示。当然这个提示不能准确地指出问题所在,就算等上15天也是毛病依旧。打电话给Orange 150也于事无补,他们重复发一些SIM update的信息到手机上,其实SIM早就update过了。

    我一直在没有短信的日子过了近两个月。直到昨晚静下心在google上做了搜索,权衡出一个我认为成功率最高的方案——我把问题定位于2G手机无法使用3G SIM的部分功能,于是只要更新手机的radio version即可。整个更新过程很简单,下载最新的radio version,在电脑上运行一遍(当然activesync先),1分钟搞定。手机会自动重启,但还不能收发短信,还得手动把Phone Off and On一次。

    我试着给自己发了条短信,几秒钟后收到,真是开心,有重见天日的感觉。