本机使用.htaccess文件Apache配置

在本机调试PHP代码,使用.htaccess文件出现500 Internal Server Error的错误,修改Apache配置后即可正常使用,配置包含两部分:

1、开启rewrite_module

取消前面的注释。

LoadModule rewrite_module modules/mod_rewrite.so

2、设置AllowOverride属性

将你的目录或者别名配置中的AllowOverride修改为All。

AllowOverride All

修改完配置后重启Apache即可正常使用.htaccess文件。

互联网软件产品常见的免费加收费策略

互联网软件产品中,常常通过免费加收费的策略来经营,通过免费加收费相结合为企业带来可观的利润。免费加收费的策略有很多种,比较常见的有四种。

第一类是在限定的时间内免费,超过限定的时间则收取费用。

这类的免费加收费策略在我的记忆中最早始于共享软件中,一般先让用户免费试用一段时间,如果满足用户的需求,用户希望继续使用,则支付费用,目前的互联网产品中有很多采用这种方式来运营。从免费的时间上各有不同,多数以月及数月为周期,也有以年为周期。在收费上有基于一次性收取费用的,也有按月(年)收取费用的。

这种策略的优势是从产品的技术实现上来讲相对简单,仅仅考虑用户在产品免费使用时间周期上的限制,成本较低。比较适合以先行者身份杀入市场的企业使用。在同类竞品众多的情况下,使用这种策略的市场推广成本相对更大。用户对于产品的价格敏感度相对较高。

第二类是基础版本免费,高级版本收费

这种免费加收费的策略同样在共享软件中也存在,一般提供一个能满足大众使用的基础版本,在基础之上衍生一些高级功能形成高级版本,更有甚者会存在免费版(单机版)、VIP版、集团版、网络版等等。目前的互联网产品中同样也有不少采用这种方式来运营。

从产品技术实现上来讲相对于第一类比较复杂,常常需要基于产品功能进行不同用户的区分,甚至可能会存在维护多个版本产品的研发分支,成本相对较大。比较适合用户具有很强的成长性,在用户的成长中有转化为高级版本用户的需求。在产品基本版本与高级版本功能上的界定要求很高。一旦用户使用这类的产品,通常对于产品的价格敏感度比较低。

第三类是在限定的数量下免费,超出限定的数量则收费

这种策略应该属于第二类的特例,但又有不同,通常会通过限定产品中某些具有数量的属性来进行免费,但超过限定的数量则收费,比较常见的通常有限定用户数、限定存储空间等、限定每日业务数量等。超出限定数量收费有按照阶梯的,也有单一的。

从技术实现上通常比第二类简单,而且某些时候对于用户来讲可以按需使用,同样的比较适合用户具有成长性的领域,在期初的用户对于价格相对较敏感,随着用户的成长对于价格敏感度会逐步降低。

第四类是针对特定类别的用户免费,类别外的用户则收费

这种策略通常会对指定的用户类别提供免费产品,而不在此类的用户则收费。用户类别划分有基于规模的,有基于成立时间的,有基于性质的。比如规模大小,成立时间在免费周期内的,学生团队等,这种策略的产品更多是使用免费来对产品进行推广,或者就是占据市场主导地位的企业以体现其社会责任感提供的免费服务,同时有益在用户成长后的收费。这种策略不好的一点是相对难以验证用户类别。

采用免费加收费的策略的前提是从开始就界定要从产品本身收取费用,采用这些策略能在一定程度提高收费用户的转化率。策略根植于产品能为用户带来的价值,通过免费的方式更多是让用户通过介入产品来认可产品对自己所带来的价值,同时推进产品持续的发展。

产品设计与软件服务杂记

最近闲赋在家,在清明小长假开车长途跋涉3000多公里办完了家里的一件事情,这本身是一种锻炼,同时也让自己放松了一下。闲赋期间也与众多朋友进行沟通交流,同时也收到了一些电子产品的礼物,就对这些谈谈自己的看法。

沟通交流多涉及传统行业或正常业务想利用软件来拓展自己业务,跟随现在的热潮,这些沟通交流也多集中在电商方面,我对于电商是不懂的,没有这方面的从业经验。在沟通交流的过程中多数扮演倾听者的角色,倾听现有的业务如何开展电子商务的美好前景,如何大展宏图,趁着这波电商及移动电商热潮让公司的量级在提升一个台阶。另一种沟通交流涉及的是现有的业务希望能够使用一定的软件来辅助业务本身,期望用软件来提升服务质量,形成自己的独有竞争力。

沟通交流的后半阶段总会涉及到多少人多长时间能够完成这些想法,然后就有外包给团队完成这些的打算,给我的最直观的能够形容的就是这些想做的事情是一锤子的买卖,这也是我近两年碰到比较多的传统行业经营者比较普遍的想法。我对于此的一般建议是让其慎重考虑,主要集中在几点:

(1)这些预计投入建设的都是其核心业务,不在于做出来,而在于做出来后通过不断的运维,经历由营销指导系统建设到系统驱动营销;
(2)核心要做的事情和要形成独有竞争力的事情不宜外包,否则在很大程度上会陷于外包这个泥潭而很不好脱身;
(3)从长期来讲做这类的事情需要有自己的团队,而不是一锤子买卖,我要做这些,你做了这些就行了,这样做多半会夹生,最后不了了之,浪费资源不说,同时也不会有好的结果;
(4)应该有足够的耐心,当真的确定开始之后,这玩意在很长一段时间就是无底洞,看不到底,没有足够的耐心会让团队很茫然,在过程中就会分崩离析。

这些是跟我老本行相关的我的一些看法,我不懂电商,就是从系统建设方面的一些建议,更多的是给他们泼冷水,不是简单的找台服务器、架设电子商城系统或开发一个简单的软件从辅助业务开始形成独有竞争力,其实有时候看上去简单却不简单。

下面再说说朋友给的电子产品「收音机」,这东西是我有段时间问朋友索求的,最近一下子拿到了好几台,主要给母亲使用,这玩意在我的记忆中从来都没有非常火热过,从使用人群出发,记忆中最早家中会有大块头的收音机,仅仅留存在记忆中的这段时间会有「小喇叭什么什么的」,再往后就是在老人跟学生这个群体中使用,现在人们生活变好了,私家车多起来后,在开车中常会听听车载收音机,目前应该在老人跟司机群体中使用较多,至于年轻人可能就通过手机偶尔来听一听了。刨除车载收音机使用人群以外,可能老年人是一直在使用的一个群体而且是目前使用居多的人群。

最近拿到的几台收音机越发的精致跟小巧了,从使用者的特点来看,精致跟小巧是必要的,但是小巧的基础上应注使用人群的特点,比如现在的小按键、数字屏上小字体、小图标对于老年人来讲操作起来就有些不便了。功能操作的数字化这方面也需要一段时间来学习,当然这点我认为是值得的,都要与时俱进嘛,母亲最钟爱的还是「德生」老式收音机,是需要花一段时间来熟悉数字化带来的好处。

不管硬件产品的设计还是软件产品的设计,其受众特点都是需要在设计中考虑的重点之一,只有充分考虑了这些,最终的接口才会有良好的人际体验,就收音机这个电子产品,可能在不久的将来就会彻底消失,但电台会以另外一种方式传播。

「收音机的使用人群是不是我写的这样,下一回跟从事广播的朋友有待沟通确认!」

php学习练习(2)-微信版宝宝睡前故事

小的功能需求在生活的周围存在很多,这些功能需求的编程实现是学习的一种良好方式。对于给孩子读睡前故事是现阶段我这个家庭的需求,买了不少故事书,也有读,就想着将这些故事放到手机上也是一个不错的选择。

时下比较火热的「微信」是手机上呈现的一个不错的方式,于是着手规划这个小的功能需求,这个小的需求分为两部分,第一部分是服务器端对于故事的组织与管理;第二部分是服务器端与微信公众号之间的接口实现。

服务器端需要一个存储故事的数据库,用于存储故事数据,一组页面及其脚本来完成故事的管理,完成对应于数据库的ADU相关操作。剩下的就是与微信的接口部分,通过微信公众号的自定义菜单获取每日睡前故事,通过脚本依据当日信息组成微信公众号的图文信息,点击后展现故事。

最终的阅读操作如图所示「如果你也有这样的需求,可通过微信搜索smallsoftware关注即可使用,也可在微信中扫描本Blog右侧二维码直接关注」:

babystorys

微信接口这部分主要是从数据库中获得数据,然后组织成图文信息即可,根据微信自定义菜单的KEY完成组装即可。

$postStr = $GLOBALS["HTTP_RAW_POST_DATA"];
if(!empty($postStr)) {
  $postObj = simplexml_load_string($postStr, 'SimpleXMLElement', LIBXML_NOCDATA);
  $fromUser = $postObj->FromUserName;
  //详细请参看微信公众帐号开发接口文档
  //...
  $fromMsgType = $postObj->MsgType;
  //...
  if($fromMsgType == "event") {
    $formEvent = $postObj->Event;
    if($formEvent == "CLICK") {
      $eventKey = $postObj->EventKey;
      if($eventKey == 'YOUR_KEY') {
        //取数据
        //组织图文信息数据
        //输出
      } else { //... }
    }
  }
//......

服务器端包含故事的添加、修改、删除、查看,用于后台对于故事的管理。使用了Bootstrap前端框架的部分内容,具体的结构如下。

babystory archite

数据库类基于PDO,故事类继承数据库类,完成故事的数据相关操作封装及故事的展现,admin类完成权限和管理的封装,前端页面通过init入口完成对于数据的管理工作,init入口部分完成数据的初始化工作与上下交互操作。

没有其他可供的选择,每天一篇睡前故事,对于选择性故事的定制阅读及过往的查询不支持,对于用户阅读这部分的统计也没有完成,可以说留下了不少的坑等着填。

至于微信自定义菜单,根据其接口文档中的说明,先要由appid和secret通过一个URL用Get方式获得AccessToken,然后将准备好的菜单和获得的AccessToken通过一个URL用POST的方式提交数据,从而创建自定义菜单。

<!--?php
  class WechatMenu {
    private $_appid = "";  //你的appid
    private $_secret = ""; //你的secret
    function __construct($menu) {
      //先获得AccessToken
      $result = $this--->getAccessToken();
      if(array_key_exists('errcode', $result)) {
       throw new Exception($result['errmsg'], 1);
      } else {
         $url = "https://api.weixin.qq.com/cgi-bin/menu/create?access_token=" . $result['access_token'];
         $result = $this-&gt;Post($url, $menu);
         if($result['errcode'] == 0) {
           //ok
         } else {
           throw new Exception($result['errcode'], 1);
         }
      }
    }
    
    private function Post($url, $data) {
      $ch = curl_init();
      curl_setopt($ch, CURLOPT_URL, $url);
      curl_setopt($ch, CURLOPT_POSTFIELDS, $data);
      curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
      curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
      curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, FALSE);
      $data = curl_exec($ch);
      curl_close($ch);
      return json_decode($data,true);
    }

    private function Get($url) {
      $ch = curl_init();
      curl_setopt($ch, CURLOPT_URL, $url);
      curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
      curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
      curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, FALSE);
      $data = curl_exec($ch);
      curl_close($ch);
      return json_decode($data,true);
    }

    private function getAccessToken() {
      $grant_type = "client_credential";
      $appid = $this-&gt;appid;
      $secret = $this-&gt;secret;
      $url = "https://api.weixin.qq.com/cgi-bin/token?grant_type={$grant_type}&amp;appid={$appid}&amp;secret={$secret}";
      $result = $this-&gt;Get($url);
      return $result;
    }
  }
?&gt;

调用 (1) 生成json格式的菜单数据 (2)new WechatMenu($menu);

wechatmenu

-EOF-

一个游戏运营项目失败的思考

这是我对自己参与的一个项目失败的思考,有点马后炮的赶脚。仅仅代表个人的观点和看法,不一定正确,仅供记录我这个阶段的一些想法,积累下来以供将来重新的审视与提高。

先简要的介绍一下这个项目,这是一个网络游戏在海外运营的项目,促成这个项目的开始是出自同事以往行业内的从业经历,恰逢其会的是该同事具有前期能引流的人脉并且也愿意一番尝试,在技术上也具有在预期时间内完成基础平台建设的能力。在项目启动之初,可谓「天时、地利、人和」齐活了,一个比较完美的开始就这样诞生了,剩下的就是甩开膀子,在快速迭代试错中迈着小碎步向前奔跑,以成就一番事业。

「愿望总是美好的,现实总是残酷的」,我甚至不知道这个项目最终结束的具体时间,因为项目进行的中间我就已经离开这个游戏创业项目了,很短暂的开始,很短暂的结束,但当整个团队决定开始增加新方向的时候,这个项目终将结束在我看来也是必然的。

gameplatform

按照这个项目来说,项目的主体共有三方组成:游戏厂商、初始用户导入方、平台运营团队。三方各司其职,共同推进整个项目的发展。

(1)被选中且能够与我们开展合作的游戏厂商的主要工作是完成游戏的接入,游戏的升级维护及节日活动的推出与定制,另外就是三方的结算对账。
(2)初始用户导入方完成用户的引流工作,以及运营分成的财务结算对账,完成境外其他资源引流的合作洽谈,找出最佳的引流途径。
(3)平台运营团队就是我们了,主要负责运营平台的建设、游戏的筛选与签订合同、游戏接口与平台的接入、平台的充值及换算、后台数据分析与核对、游戏运营活动的策划与运营推广、游戏客服、「建立自己的用户资源」、与各方财务结算。

游戏厂商在整个进程中的配合是非常良好的,在发生问题的时候总是能及时得到反馈,在活动及游戏内资源的支持上也不遗余力,而且从洽谈的过程中,能明显的感觉到他们是乐意合作的。

初始用户的引流工作虽然是资源方乐意尝试的,但不是其主营,这点上可能力度有待进一步加强,这些可以通过沟通来解决,还有就是对于引流的效果应该由我们结合引流方式给予资源方一定的支持,当然这些是要依据一定的数据方式,比如在游戏中做一些有奖励的调查问卷来获得其大部分的来源途径,其实这些在资源方那边是可以统计出来的。

我主要负责技术这块,并且参与跟游戏厂商的洽谈接触,在初始系统基础上安排设计人员和开发人员进一步定制以后基本上满足开始的运营需求,整个平台就这样开始运营了。我一直认为在一件事开始之后,专注与围绕专注开展工作是一个前提,就这个平台开始运营之初,构成其未来的主要工作集中在两部分:「其一是运营推广,这是重中之重,其长期努力的方向是建立自己的用户资源;其二是围绕运营推广提供强劲持久的技术驱动力,持续发展运营平台及其周边增值服务,保证给不同类别的用户持续输出富有娱乐性的游戏」。

围绕这两部分开展工作就是基础,刚开始运营其实从数据上来看还是比较符合预期的,在差不多一个月单游戏单区的情况下,用户注册数、每日在线数、充值数、日注册及活跃增长数及用户留存率上来看还相对符合预期,下面是一个月的部分充值记录。

paysummary

有了一个好的开始,但随后突然就放下了,主要的工作没有行之有效的开展,或者说没有足够的努力。危机意识不强,对技术长期驱动力的价值也不太认可,加上团队成员的实际生活问题等诸多因素的影响下,又有了开展其他行业新业务想法。在这种情况下,我最终选择了离开,因为我没有更多的资金投入开展新的业务,同时我也不认为当时的团队与投入能够有精力同时开展两条线的业务。

至于说主要的工作没有行之有效的开展是我个人的观点,对于我这个初次涉足游戏行业的人来说,在开始到离开这段时间其实有不少的想法,比如说在通过资源方引流的原始用户基础上,通过怎样的策划与推广,带来新的朋友用户,能不能制订积分体系加物质激励来完成?能不能通过游戏虚拟物品激励来完成,平台自己是否增加用户推荐体系并给予满足条件的推荐用户以激励?围绕游戏如何建立社区论坛?能否增加周边商城拓展游戏增值服务?满足这些运营平台应怎样重新架构? 诸如此类的想法有不少,但是这些想法没有成文后与团队成员进行充分的沟通,虽然这些想法对于初涉游戏行业的我显得比较稚嫩,但至少也应该跟团队成员讨论一下,在讨论过后相信自己也能获得长足的提高,增加对这个行业的认知。

危机意识不强的很大一部分原因是被这开始的充值额冲昏了头脑,按照一款游戏一个区来计算,想来多款游戏多个区就能达到预期,从我后来离开后的间断性关注中,先后上线了新的两款游戏,并且增加了新开区,但是充值及用户增长却一度中断,中间我没有看到任何针对这些不好影响的调整。这段时间我的猜测是人力资源不能跟进以保证用户的使用引导及足够的支持工作,由于新开展的其他行业新项目占据太多的精力,导致迟迟没有建立初步的用户服务机制、用户引入机制、用户激励机制、用户参与机制等。且在整个行业的发展中,游戏的变化也是急剧的,缺少对端游、页游、手游这些不同类型游戏的持续性关注。

再往后就没有往后了,却留下了诸多的不良影响,影响之一是在合作过程中给其他两方留下了一定的印象;影响之二是给玩过一阵的玩家留下了一定的印象,进而导致资源方也给玩家留下了足够的印象;影响之三是给所有团队成员留下来一定的印象。那么收获呢?

对于我来说这个短暂的创业经历有几点收获:

(1)要一直专注,所有要做的事情都要围绕最初设定的目标来做,尝试能够尝试的一切方法只为向目标迈进或者由目标衍生的新目标,直至结束,在未终止前我们其实没有更多的精力同时专注两件事;
(2)要有危机感,要给自己设定尽量涵盖全范围的最差的情况,然后设法找到解决方式,时刻保持危机感能促使专注;
(3)运营是重中之重,运营始终需要强力的技术作为保障,从这个角度来讲,技术是运营的支撑,技术是驱动力,要尽量获得团队成员对技术的认可,运营平台系统的建设不是一锤子买卖,需要长时间的演变,从功能到架构;
(4)要设定退场时对各方影响的补偿机制,用户从开始使用提供服务的第一天就会投入情感,任何时候不要让用户失望,说不定结束前小小的沟通就能超出用户的预期;
(5)人在任何时候都是关键,保持足够的沟通能够增加互相的了解,比较理想的是在没明确结束前,大家都能全力的参与其中;
(6)多少人做多少事,我们往往太过相信自己能够做的更多,可往往我们并不能做更多的事情,我们往往过高估计自己。