Browsed by
标签:python

市场分析后的迷思

市场分析后的迷思

最近不太忙,于是花了点时间研究一下我们云SIP服务的市场情况。结果很出乎意料,很多结论与我们的预想是完全相反。

做云SIP服务的初衷是来自一些客户的反馈:MSS最小版本都支持20部SIP分机,而有一部分用户的场景中没有这么多分机,因此购买一套MSS软件稍显浪费。另外,有一些区域的用户,比如中国大陆,认为软件贵了点,希望能更便宜一些。

因此我们做了云产品,预计大部分用户会创建少量的资源(分机、外线等),同时也希望能吸引一些不太愿意为软件进行投资的用户。

经过基本的数据分析,我们得出以下一些结论:

1、不愿购买软件的人更加不会购买服务

云SIP服务不仅仅是产品,本质上更是服务,我们维护着整个VoIP网络系统的稳定,检查各种失败呼叫的情况,为客户排忧解难等等,这些都是对用户非常有价值。而数据表明,云SIP服务的客户范围与本地MSS软件的销售范围是高度重合的,仍然是以欧美客户为主,我们期待的拓展客户并没有出现。

不认可软件价值的人,也很难去认可服务的价值。

2、欧美客户更愿意购买服务

我们原先预想:部分对价格比较敏感的用户会使用我们的云SIP服务,另外用户熟悉过我们的云产品后,感觉满意的话,可能更愿意在本地部署自己的VoIP网络。而实际情况是:

(1)对价格敏感的客户更愿意选择本地SIP服务器版本。这部分客户通常是非欧美客户。

(2)我们的很多客户是已经购买了MSS软件,尝试了云SIP服务后,反而将本地VoIP网络迁移到云服务上。这部分用户更看重稳定的网络和专业的服务质量。当然也有部分用户与我们的预期是一致的,最终购买了软件。这部分客户通常来自欧美地区。

3、价格不是关键因素

云SIP服务虽然每资源定价很低,但是如果设置大量资源的话,总体成本会逐渐超过MSS软件的成本,因此我们预期用户不会添加太多的资源,这样也与MSS软件形成互补。然而让我们惊讶的是:大量客户设置的资源数(分机、外线、语音文件等)居然超过20!跟踪分析了其中一部分长期用户的数据,结果发现这部分用户支付的费用足够买好几套软件了。

显然,对这些高价值用户而言,价格肯定不是关键因素,至少不是决定性因素。专业化的服务、稳定的网络、简单易用的使用体验才是吸引他们的关键。因此我们进行设计时,无需过多考虑价格,而更应该关注产品本身。

4、个性化需求还有待挖掘

首先说一下结论:我们极少遇到个性化需求。少数几个提出个性化需求的客户最终也没有成为我们的长期客户。

云SIP服务一个让我们自鸣得意的特性就是对IVR-XML以及Python脚本业务的支持。这个特性非常有利于我们为客户提供或者适配个性化的通信业务。我们甚至预期大量的客户会提出此类需求,比如不同的IVR流程等。然而现实就是“并没有”,大家都还是在使用默认的各种业务和呼叫流程,这有点让人郁闷,感觉辛苦努力的东西其实是屠龙之技。

这点结论可能值得商榷,还需要继续观察。至少我个人仍然认为多数企业对自己的通信需求都会有个性化的地方,目前这个结论可能是我们没有真正了解到客户的需求造成的,也可能是我们的客户群还不够广泛造成。

python的小坑:%u

python的小坑:%u

最近在开发过程中,有一小处代码需要将一个无符号32位整数转成字符串,于是想当然地按照C格式化的方法,采用了类似写法:

print "a=%u"%-1

本来预期是输出内容为:

a=4294967295

实际结果并没有转化为无符号整数,仍然采用了有符号整数方式:

a=-1

作为一名C/C++程序员,对这个结果自然感到惊讶。很显然,python把%u和%d等同起来了。于是搜了一下python的文档,在字符串格式化章节中有这样的描述:

%u Obsolete type – it is identical to 'd'.

根据这文档中的内容,又进一步找到了PEP-0237,其中又强调了这点:

this means that '%u' becomes an alias for '%d'.  It will eventually be removed.

虽然不是很理解为什么采取这种做法,但是很明显,在python代码中不应该再使用%u了,这个格式转换完全等同于%d,而且在后续的版本中有可能会被删除掉。

在空闲之余,又挖了一下python的代码,的确也反应了上述各项说明:

  • PyString_Format 函数中,’iduoxX’都按照 PyInt 处理;
  • 接着在 formatint 函数中,明确进行以下转换:
  • if (x < 0 && type == 'u') { 
        type = 'd'; 
    }
修正dropbox无法启动问题

修正dropbox无法启动问题

也许是Ubuntu系统升级补丁的原因,也许是dropbox升级遇到网络异常的原因,总之,今天忽然发现dropbox没有启动,在面板中看不到dropbox的小图标。

使用命令检查dropbox状态,的确没有启动:

dropbox status

手工强制启动dropbox:

dropbox start

提示以下错误:

VerificationError: ... : No module named _cffi__xa0c4f46bx1d95b4de

在网上搜到一个解决方案,其实就是重新安装dropbox。在此之前要先删掉.dropbox-dist目录。与网上文章不同的是,我是在用户目录下找到这个目录。

rm -fr .dropbox-dist/

删除完成后,重装dropbox即可。重装不会影响原有的同步目录。

dropbox start -i

备注:系统版本为 Kubuntu 13.10(x86_32); dropbox版本为2.6.27。

Debian 7与PyCharm3.1

Debian 7与PyCharm3.1

PyCharm无疑是相当杰出的Python IDE(而且提供免费的社区版本),可以运行在Debian7系统中。安装、运行都非常简单,下面简要说明步骤。需要说明的是,全部采用root用户进行操作。

step1:下载PyCharm

目前最新的版本是V3.1,直接从官网下载即可:

cd /opt
wget http://download-ln.jetbrains.com/python/pycharm-community-3.1.tar.gz

step2: 解压缩PyCharm

tar -xzf pycharm-community-3.1.tar.gz

step3: 创建软链接

ln -s /opt/pycharm-community-3.1/bin/pycharm.sh /usr/bin/pycharm

完成上述命令后,在console中直接输入pycharm即可启动。当然,也可以创建图形快捷方式: 右键点击“kickoff应用程序启动器”,选择“编辑应用程序”,选择一个菜单栏(例如“开发”)创建新的菜单项,指向pycharm即可。

2014-03-12 更新:

Kubuntu系统默认没有安装jdk,因此无法运行pycharm,需要先使用以下命令安装jdk:

sudo apt-get install default-jdk
Kubuntu12.04中python的一点变化

Kubuntu12.04中python的一点变化

最新的12.04版本中,默认携带的python版本是2.7版本,并且在Ubuntu的库中不再提供2.6版本,因此如果使用了python2.6的开发库的程序,在新版本中必须要进行相应的调整。

比较简单的办法是做符号链接,例如:

sudo ln -s /usr/include/python2.7 /usr/include/python2.6
sudo ln -s /usr/lib/libpython2.7.a /usr/lib/libpython2.6.a
sudo ln -s /usr/lib/libpython2.7.so /usr/lib/libpython2.6.so

Linux中共享库的实现方式,虽然采用版本号能解决windows系统常见的DLL冲突问题,但是也不完美,遇到版本库升级,应用程序都必须要改动:要么改动配置文件或者源码,要么改动符号链接等。

对于python而言,由于可以分目录安装,并且共享库也带版本号区分,完全可以2.6和2.7共存,不知道ubuntu是出于什么考虑,去掉了对2.6的支持。

还是要仔细看manual文档啊

还是要仔细看manual文档啊

今天花了很多时间在网上搜索Python与C之间交互的文章,想弄清楚大数据结构传递的问题。看了很多文章,大部分都是很久之前的经验记录,感觉不得要领。

后来仔细翻了翻Python的manual文档,赫然发现ctypes章节,写得非常详细,基本上把所有的概念和细节都讲清楚了。

http://docs.python.org/library/ctypes.html

看来自己的工作方法要不得啊。遇到问题首先google,其实也挺浪费时间。多花点时间研究manual,可能事半功倍,尤其是象Python的manual,写得真是不错。