一个在线收银系统,软件不复杂,但有模有样,还带出了一个硬件产品线。
http://www.phppointofsale.com/hardware.php


最近突然有了岁末年初的疲倦。连着两周,一场接一场的生病。身体似乎一下到了负荷的临界点。
目睹了太多的污秽与丑陋,只想关掉和世界连接的窗口找个地方静一静,休息休息。
前段时间老余问我,有没有在这种沸腾燃烧之后沉静下来想一想,自己又没有错过或失去什么。当然的我踌躇满志,意气风发的说,没有!
昨晚,一个人坐在沙发上,心神不宁的看着电影,突然发现,我已经很久都没有坐下来看一部电影了,这个我曾经自诩为人生最大的爱好的事我居然很久都没做了。
我用力奔跑着前进,来不及也顾不上看身边的风景,我得到了一些想要的,也得到了更多不想要的。
老余的问题是有深意的,是的,我想我已经失去了它们。
1月份过去了,这一个月学到的做到的感受到的比去年一年都多。记录一点感受在此:
1、1月份主要的业绩集中在一个高ARPU值的模块产品上,用户数减少,但收入增多。可见产品的定价策略很重要。定价可以传递出极其丰富的信息,对于产品的格调、筛选用户、提高收入、降低成本都有着非常重要的意义。
2、在销售方面,是否还要采取走量的销售模式值得思考。理想的方式是通过提高定价、丰富服务内容、丰富功能层级的方式包装出不同的价值的产品,销售给不同需求层次的用户。比如:基本版、升级版、黄金版等等。减少产品的销售量,提高每个用户的服务质量。
3、逼格非常重要,产品不必迎合所有人的胃口,而应该去寻找真正理解产品价值的用户,他们能把产品玩出花样,实现甚至提高产品的附加价值,这样也是间接为自己的产品树立了范例和标杆,是良性循环。
4、产品盗版问题,首先对于盗版产品,发现了应该给予坚决的回应,这个是一个维护自己声誉和原创精神的机会,借由这种回应可以做很多事件营销活动。一方面是博取公众的同理心和同情心,另外一方面是广告效应。其次要从技术方面去做防范,不要顾虑有人会见招拆招就不去做。技术上的防范可以让盗版商产生一定的忌惮心理,但最主要的是这样做是给已经付费的用户立一个姿态,你对于他们的权益是很重视的。
5、题外话:多和人聊天,在聊和交流的过程中会得出很多新的想法,碰撞出火花是一定的。另外应该思考,在团体合作的时候,如何能用机制去规避或防范人性的贪婪和欲望,虽然,这个可能是永远无解的难题。
最近发生了一些不大不小的事,老余说你应该写一写留作纪念,想想也是,站在黑漆漆的电脑屏幕前洞察到的人性,当然值得大书特书。
具体事情按下不表,得出的经验如下:
1、洞察人性最好的方法就是杀入商场,没有什么比利益的诱惑更能激发出人性的黑暗面。
2、天底下没有永远的朋友或永远的敌人,你看好的背后可能捅你刀子,你憎恨的也许反而有做事的边界。都不重要,重要的是你要想好自己的底牌和后招。
说白了,一切都是博弈。你推我挡,玩得一手好太极,不动声色之下牢牢握住自己的底牌和后招方为上策。
3、做人不能太贪婪,太贪婪什么都得不到,做人也不要太聪明,聪明反被聪明误。
4、凡做过必留下痕迹,墨菲定律是对的,你害怕它发生的往往最终会发生,所以做坏事之前自己先掂量掂量善后能不能做好,否则干脆别做。
5、渠道的力量不可忽视,不会借助别人力量来做事的人做不了大事,也永远无法成功。
一个企业,首先要知道的是为谁而生。企业的直接客户是谁,潜在客户是谁,客户的特征是什么,这是否是一块盐碱地,还是一片蓝海?
即使是传统成熟行业,作为一个新入者,如果他还有所追求,为谁而生这个问题一定是淌出来的,而不是想出来的。
不怕路远,路难,方向要对。为谁而生这个问题想对了,路就走对了,企业的价值观也会依附于它。而这个问题想错了,企业之路必然会更加崎岖不平。
X毕业一流大学,光学专业,从事的是照明行业。他的企业之路颇有意思。2年前他想做一件照明领域的工具产品,提供给别人用。却又发现如果做出来了,用户在哪里却不知道。于是转型,借着微信的东风专注于创建照明领域的内容开发,主要就是通过微信公众号,结合志愿者模式做内容传播,前半年主要靠自己,后来逐步有了影响力,开始有大量志愿者通过公众号平台聚集到一起,从事更多翻译和创造性的工作。有了这个基础,事业开始步入正轨。
照明行业,聚集了众多中小企业,从上游芯片厂商到中游设计到下游施工队,整体比较浮躁浅薄,国内产业以抄袭为主。鲜有人静心想为行业做点什么,内容贡献就更不用提。这便是X的机会。
建立行业影响力后,这些中小企业就增加了一个媒体渠道,这时候公司就能够有一些基本的现金流。但是,仅仅是媒体渠道,还不足以让体现一个公司的理想,一个有理想的公司,应该是能够变革行业的。下一步怎么走?玩法很多。
很久以前整理的,一直在更新。
github地址: https://github.com/justjavac/free-programming-books-zh_CN
来源:http://www.v2ex.com/t/143671
我在github上fork了一个分支:https://github.com/raywill/free-programming-books-zh_CN
在OceanBase0.5开源版本中,RPC其实是有一个层次的。自底向上,分别是:
Network Framework — libeasy,负责底层网络框架,packet级别
Client Manager — 负责跟libeasy交互,封装了回调逻辑、异步/同步逻辑
Rpc Stub — 封装了请求的序列化、反序列化逻辑,是应用代码与网络代码的粘合剂
应用代码直接使用Rpc Stub来使用网络最方便,跟调用本地函数区别不大。不需要关心序列化、反序列化过程中的内存问题。但是,应用层如果希望获得一些更为复杂的网络交互逻辑时Rpc Stub则不能提供。比如,希望在A函数post一个请求,然后希望在B函数里wait这个请求的返回值,rpc stub无能为力。
应用代码也可以直接用Client Manager,可以获得很大的灵活性。上一个例子中Rpc Stub搞不定的情况,Client Manager可以搞定。但是直接使用Client Manager会增加一些代码复杂度,例如:需要自己分配DataBuffer,如果追求高性能,还需要自己管理Thread Specific Buffer。
当业务逻辑的对网络需求的复杂度超过Client Manager能力范围时,可以直接用libeasy来解决问题。这是终极方案。在0.5中的SQL模块里用到了该方法,但使用经验证明这种方法可维护性很差,必须对其进行一定的封装。
思考是技术进步的阶梯
A向B机器发送一个plan执行的时候,随着plan本身还需要发送哪些结构?
分析:
OB0.5开源版中发送了SimpleScanParam,但这个参数并不是单独发送的,而是包装在了一个ObHuskTabletScan运算符中,在CS端根据运算符中的参数重新构造子Plan。
答案:
只需要发送plan本身即可。其余要发送的内容都应该封装到operator内部。
进一步发问:
operator内部要封装什么呢?
答案:
比如,读数据超时时间。在运行时用户可以通过命令修改读超时时间,需要将新的时间让plan知晓,以便序列化到B端。
再比如,读数据的版本号。随着时间流逝plan被反复执行,plan需要携带的版本号应该要随时间变化。
这些内容的变化,都应该封装到operator内部。具体做法可以是设置一个IParamProvider()给operator,operator可以随时通过IParamProvider获得最新的数据。IParamProvider的实现比较简单,它持有整个SQL Plan运行时环境的引用,可以随时从中获得最新的参数提供给operator。这个细节不需要scheduler关心。
结论: