为6月的电商大战贡献真金白银

这个6月电商界还真挺热闹的,其中之一就是几大书市都在大搞促销。

今天在amazon上下单买了5本书:

<<选择的悖论:用心理学解读人的经济行为>>

<<大数据时代:生活、工作与思维的大变革>>

<<程序员的数学>>

<<黑客与画家:硅谷创业之父Paul Graham文集>>

<<思考的乐趣:Matrix67数学笔记>>

发现这书目还是和工作,自己长期以来的兴趣最为有关。

 

python PIL在 mac 上安装

python-env

第一次想用python写个小程序,需要用到PIL,折腾了一晚上才安装好PIL.

期间在网上找过各种教程,综合后搞定:

  1. Install Xcode from the App Store.
  2. Open Xcode and open Xcode Preferences.
  3. Click on the Downloads tab, and you’ll see Command Line Tools. Click the Install button to install the Command Line Tools. (This provides gcc to compile PIL)
  4. 这时我的环境使用sudo pip install PIL出现如下错误:
    5f2d81ccae1ca1_
  5. 通过 sudo easy_install --upgrade pip 解决
  6. 这时pip 命令已经可以使用,但出现如下总是:
    unable to execute gcc-4.2: No such file or directory
  7. 这时 通过

    sudo ln -s /usr/bin/gcc /usr/bin/gcc-4.2  解决
  8. 最后sudo pip install PIL 成功

———————————————————————————————-

       此时在处理图片时,还会报以下的错误:

     decoder jpeg not available。。。。

     这是还没有安装jpeg, 但只是简单安装jpeg(brew install jpeg)后,还是会有同类问题。

    这和PIL的安装有关系了。这时我们应该通过下载source,并且通过修改其中的setup.py文件中JPEG_ROOT = None  => JPEG_ROOT = libinclude(“/usr/local”) 这一项来fix这问题。

  做完这一步后,可以通过 >>> import Image来验证,如果没再提示错误信息,表明ok了。

ref: http://www.pythonware.com/products/pil/  

服务他人,成就自己

服务他人,成就自己。这是对于目前火热的挖比特币,以及19世纪美国的西部淘金热现象的一个个人总结。

在淘金热中,有部分发财的人是为那些淘金者提供工具及各类其它服务的人。这一现象在比特币这一现象中也同样适用。去分析那些报道挖比特币的文章,很多里面都会提到花多少钱买装备这一事,并且有些装备还一直在涨价。前几天看到央视关于比特币的报道中,就有提到有人因为卖装备在短时间内挣上了上千万。

是不是可以这么说,市场总是在一层层地形成。当有一个大市场时,总会围绕它形成若干市场。

新浪那点事

新浪最近有两次较大股价波动,一是新许良杰在2月20确认加入新浪微博,二是这次的阿里投资新浪。如果从事件触发的投资来说,阿里投资新浪其实是给了我们机会的。做为参与的工程师,我们大致知道双方的合作内容要在什么时候上线,如果再多想远一点,就是能猜测出这些合作肯定是基于之前传的沸沸扬扬的阿里投资新浪微博已经八九不离十的确定性。

我想这次的事件也很有可能和上次一样,过不了几天又会跌回50$附近。针对这类由事件引起的投资机会,不需要太贪婪,达到一定的收益就可以收手。

附上雪球上看到的一个这次投资分析:

http://xueqiu.com/7062290132/23721605

2013年4月29日$新浪(SINA)$ 宣布阿里巴巴通过其全资子公司,以5.86亿美元购入新浪微博公司发行的优先股和普通股,占微博公司全稀释摊薄后总股份的约18%。但新浪微博同时又授予阿里巴巴一项期权。新浪新闻稿中是这样写的:

“SINA has also granted an option to Alibaba to enable Alibaba to increase its ownership in Weibo to 30% on a fully-diluted basis at a mutually agreed valuation within a certain period of time in the future.”

新浪授予阿里巴巴集团一项期权,该期权使得阿里巴巴集团在将来某一确定时间,以相互认可的价值,按稀释摊薄的基准,将其在新浪微博的权益提高至30%。
通俗一点讲,就是阿里巴巴目前占新浪微博18%的权益,未来将会占到30%权益。那么占一个公司18%权益与30%的权益有何区别呢。一般而言,占一个公司权益20%以下,说明投资公司对被投资实体既不重大影响,也不属于重大控制。而超过20%权益,说明投资公司对被投资实体具有重大影响。依此规则,阿里巴巴占新浪微博18%的权益时,说明阿里巴巴并不会对新浪微博业务产生重大影响。而当阿里巴巴占新浪微博30%的权益时,说明阿里巴巴对新浪微博业务产生重大影响,阿里巴巴可以向新浪微博派驻董事,在一些重大事情上将享有一定投票权。
阿里巴巴投资新浪最令人费解的是option。新浪授予阿里巴巴的这项option,可以让阿里巴巴未来在微博的权益提高至30%。新浪在公告中并未对这项option做太多的解释。只是用了几个定语,“a certain period of time in the future”、“mutually agreed valuation”、“a fully-diluted basis”。从定语上可以看出,这项option与时间相关,另外option对应的价值已确定, mutually agreed。新浪并未明确这项option是否附条件,但从定语上看,这项option将会“随时间满足”。再从动词上看,“enable Alibaba to increase its ownership”。这个“enable”在此处显得有些含糊。新浪微博授予阿里巴巴的这项option,并未明确,阿里巴巴是否需要再拿钱出来认购。
这样的一个option的确有点令人匪夷所思。看起来只是一个时间问题,为啥阿里巴巴不直接认购新浪微博30%权益,而要费上半天劲,采用分步到位的形式。而且这个option并未明确阿里巴巴需不需要再花钱认购剩余的12%的股份。这是一份充满疑惑的option。当然,新浪在公告中已明确“阿里巴巴通过其全资子公司,以5.86亿美元购入新浪微博公司发行的优先股和普通股,占微博公司全稀释摊薄后总股份的约18%”。已就是说,现在的18%的权益是明确,而不明确的是剩余的那12%的权益。天下没有白费的午餐,剩余的那12%的权益,自然有其对价。当然,这样的对价可能不是通过认购的形式,而是以另外的一种方式,如服务、技术、资源等。
就在新浪宣布阿里巴巴投资新浪微博的同时,新浪公司同时宣布其子公司微博公司与阿里巴巴集团子公司阿里巴巴(中国)签署战略合作协议。双方将在用户账户互通、数据交换、在线支付、网络营销等领域进行深入合作,并探索基于数亿的微博用户与阿里巴巴电子商务平台的数亿消费者有效互动的社会化电子商务模式。这一战略合作预计在未来三年内给新浪微博带来大约3.8亿美元的营销和社会化电子商务的收入。
同样,这样的一则消息也是令人充满疑惑。基于目前的阶段,双方还只是刚刚达成社会化电子商务模式战略合作的阶段,而这样的一个阶段,双方竟然能准确预测新浪微博未来三年基于与阿里巴巴战略合作的社会化电子商务模式的收益,3.8亿美元。真是神算啊,连个区间的数据都不用给。这样的一个数字也被写进公告中。新浪如此信誓旦旦的提到3.8亿美元收益,那最大的可能就是阿里巴巴集团旗下子公司未来三年向新浪微博支付3.8亿美元的收益,如新浪公告中提到的“营销和社会化电子商务”。
听起来,阿里巴巴集团在下血本,先不问微博给阿里巴巴集团带来的营销效果,每年就直接给新浪微博1个多亿的收益。这似乎并不符合一般的商业规则。一向精明的阿里巴巴集团这会象是在倒贴似的。花5.8亿美元买微博18%的权益,还倒贴3.8亿美元。这事看起来,是不是有点蹊跷?
作为财务出身,有些时侯,我会有意无意的去演绎数据之间的关系。阿里巴巴以5.86亿美元购入新浪微博公司发行的优先股和普通股,占微博公司全稀释摊薄后总股份的约18%,由此可以计算出新浪估值约32.5亿美元。那么剩余的12%的权益,若以新浪现在的估值去计算的话,应当是3.9亿美元。这样的一个数字竟然与阿里巴巴集团旗下子公司未来三年向新浪微博支付3.8亿美元的收益非常的接近。这是偶合吗?还是这个与option相关的12%的权益与新浪微博的合作收益之间存在着某种关联?
匪夷所思的option与蹊跷的微博收益,阿里巴巴投资新浪微博究竟隐藏着什么?

05-01 21:10来自雪球举报

spi在lucene中的应用

针对lucene-4713这个issue。梳理了下spi相关知识点以及它在lucene中的应用 。

 

4.2中solr对docvalues支持学习

From Evernote:

4.2中solr对docvalues支持学习

1. 入口:

          对solr来说,schema是任何新增数据类型支持的一个入口。

          对docvalues的支持也不例外,如果某个field是支持docvalues,应该是在schema中体现。

      实现的体现是:

   

 

   相比之前的field定义,这里多了 docValues=”true”这一property.

2. domain级别的支持

   描述这些property的类是:

    FieldProperties.java 

          protected  final  static int STORE_OFFSETS      = 0×00004000;

          添加了: protected final static int DOC_VALUES          = 0×00008000;

          这里采用了bit values for boolean field properties

          这比一般设计时采用的为每个boolean variable 采用一个field要好多了,节省了内存.同时在操作上也会更有灵活性。

   FieldType, SchemaField 这两个子类, schemaField这是一个为field各方面具体提供接口的类,因此肯定会有判断是否支持docvalues这类的方法。 schemaField 对应于schema文件中的field element.

              FieldType 及其子类 是具体的各个field描述。对应于schema文件中field type element。

              FieldType 一个重要功能是它会根据 schemaField生成,对应的value 生成 indexableField

              这一个方法 就把 solr中的schemaField, FieldType, lucene中的IndexableField这三者紧密地联系在了一起。

    

    DocumentBuilder 因为solr是在lucene之上做的,其本身有对filed的定义,document的定义,因此对schema中定义的改动,很容易触及到这个中间者的变化。

3. Add时的支持 

    

    提交的xml文件,包含一个document的信息,

==>对于每个field解释成SolrInputField(name , value, + boost)==> 组合成 SolrInputDocument ==> Docement (AddUpdateCommand-> DocumentBuilder(SolrInputDocument,IndexSchema))       这里一个关键信息是IndexSchema, 因为可以根据field name从index schema中取到 SchemaField
    进而可以得到这个field的type。 这部分业务对象的组织是和配置文件紧密结合在一志的。
    整个schema.xml文件对应于  <=====> IndexSchema
                 <=======> SchemaField
  <=======> FieldType 

      

    这个流程其实也和上述分析的domain修改有一定的内在联系。

    因此关键修改点就在 几个支持docvalues的 具体FieldType 的createField 方法 上。

    在这里一个关键动作就是把 solr FieldType上的配置信息 映射到 lucene级的 FieldType上。 

  note:

        在具体的fieldType的createFields方法中,如果当前field 支持docvalues,会生成两个IndexableField

        一个是无docvalues项的indexableField

        另一个是NumericDocValuesField , 为什么会这样处理呢?

4. query时的支持

    solr 通过父类拿到的都是 doc id

    几个关键点:

    如上述例子中,配置了 intdv为 int 并且支持docvalues,

    在一整个内部,如何来区分这些不同呢?

    也就是说如果在 一个query中,如果使用 intdv 进行sort, 这时对intdv是否支持docvalues放在哪一层?

    

    针对sort这场景, 关心的是对应docid 的doc 中intdv的值是多少, 如果不是docvalues,以之前的经验,这个 value是来自fieldcache,

   如果是docvalues呢?毫无疑问 这个值应该来自docvalues。

   可以考虑使用fieldcache的统一接口,但在返回值时,屏蔽掉是来自feildcach,还是单独的docvalues。

   在fieldCacheImpl的getLongs(…) , getFloats(…), getInts(….) 这些接口中,就是体现了这类设计。

   因此在fieldComparator中,引用就很方便,可以屏蔽底层细节了

   

    @Override

    public FieldComparator setNextReader(AtomicReaderContext context) throws IOException {
      // NOTE: must do this before calling super otherwise
      // we compute the docsWithField Bits twice!
      currentReaderValues = FieldCache.DEFAULT.getFloats(context.reader(), field, parser, missingValue != null);
      returnsuper.setNextReader(context);

    } 

facet场景:

  

关注下lucene/solr 4.2

在solr4.2中,一个重要feature就是增加了docvalues的支持。因为项目中要使用docvalues的特性,之前简单写过一点代码来支持docvalues。和之前对guava中eventbus的实现和项目中实现对比一样,这次打算详细写一blog来分析整个思路及本人在支持类似功能时的局限性。个人感觉写点类似的总结,对个人的技术感悟,提高还是有很大帮助的。

 

一周回顾(2013.3.4-3.10)

技术:

本周继续荒废,只是简单重温了几个guava功能,利用它重构了产品中一些urgely code。

私事:

在周四终于搞定了驾照

周四,周五也fix 了房贷申请上的资料不足问题,接下来就是等待结果了。这事的整个时间也真够长的,去年麦兜快一岁时确定了房子,6月初签了合同。

 投资:

A股还是一如既往的不景气

美股上的YY以13.6$入的,当时是想挣50%就出,但在这周想期待一下首份季报,期望收益能达到50%以上,结果是下跌了不少,目前停留在17.34$。下周想在18附近出掉yy,锁定利润。从长期来看,还是看好yy。

 

lucene4.0特性

From Evernote:

lucene4.0特性

Clipped from: http://blog.mikemccandless.com/2012/07/lucene-400-alpha-at-long-last.html

内容总体上来自 Mike McCandless 的  

Lucene 4.0.0 alpha, at long last!

当作一个温故而知新的过程,记录在此。

4.0 alpha有许多重要的改进,基本的是:

3.6.0中所有deprecated的APIS已经被删除了

3.0之前的索引已经不在支持

MIGRATE.TXT 描述了怎样去更改你的应用代码

4.0 alpha和4.0 GA版本之间的索引格式不会再改变(除非为了fix严重的bug而需要更改),但在4.0 beta前,APIS还是会有调整。

插件式的 Codec

 4.0最大的变化是新引入的插件式的Codec框架,这一架构能完全控制索引的所有元素(terms, posings, stored fields, term vectors, deleted documents,segments infos, field infos)是如何写入的。你可以创建你自己或使用现成的codecs,同时你也可以为每一个基本的字段自定义postings format。

有一些有意思的核心codecs:

lucene40 是4.0.0中默认的codec.

lucene3x(只读)能读取lucene 3.x 格式的任何索引

SimpleText 以纯文本方式保存任何信息(这对学习,debug很有帮助,如何应用到生产系统将是一声灾难).

MemoryPostingsFormat   以快速及压缩的FST保存所有postings(terms, documents, positions, offsets) 在RAM中,这对于有限的postings是很有效果的(如primary key (id) field, date field, etc.)

PulsingPostingsFormat 针对那些低频的terms直接内联进terms dictionary,这样就可以减少一次硬盘查找时间。

AppendingCodec 避免了在写的时候进行询盘,这对于如 Hadoop DFS这类文件系统是非常有必要的。

如果你创建自己的codec,这也是很容易来确定是否所有的Lucene/Solr 测试用例是否能通过。如果有测试用例失败了,很有可能就是你的Codec有bug!

一个新的 4-dimensional postings API(to read fields, terms, documents,postings)代替了之前的postings API.

灵活的打分(Flexble scoring)

Lucene的打分机制现在是完全插件式的,其中默认的是 TF/IDF 向量空间模型. 你也可以创建自己的scoring model,或者使用核心scoring models中的一个(BM25,Divergence from Randomness, Language Models, 和 Infomations-based models). 每个文档(document)的normalization 值 也不再被限制到一个字节。各种新的集合统计数据也能被提供出来.

这些改进是 2011 Google Summer of Code Project的一部分(thank you David!).

这两个改进是相当重要,因为他们扫除了后续继续创新的障碍。现在已经很方便尝试文件格式 或者 lucene scoring models的改变。 一个最近出来的类似创新就是这个 灵巧的codec(由Flax的开发完成),通过将postings通过key/value保存在Redis中做到field更新。

Document Values

新版的 docuement values API  为每个文档保存强类型单值field, 这意味着这是一个可能替换Lucene field cache的方案。 这些值是在index阶段事先计算好,以 column-stride(所有文档某字段所有的值被保存在一起,可以理解成类似于列存储?)格式保存于索引中,这使得它比起field cache,在搜索时的初始化时间大大得到提升。这些值可以是固定的8,16,32,64位 ints, 也可以是可变长的(packed)ints; 浮点值,双精度值;6种类型的 byte数组(固定大小 or 可变大小;反向引用【dereferenced】?; straight or sorted).

New Field APIs

创建document fields 的API也已经改变了: Fieldable 和AbstractField 已经被删除, 从Field 类中重构出来的新的 FieldType,这包含field的值应该怎样被indexed。具体的经常使用到的新类已经事先创建好了:

StringField 索引string为一个单一的token, 没有norms 。例如可以把 primary key (id) field, 或者想进行排序的字段设置为StringField。

TextField 索引了完全tokenized String, 带上norms,同时也包括docs,term frequencies 和 positions.

StroredField 表示这个field的值只是保存使用。

XXXDocValuedsField 创建强类型的文档级别值的fields.

IntField,FloatField,LongField,DoubleField 为有效的范围查询和过滤器创造数字类型的字段。

如果这些feild 类没有一个可以应用的,你也可以创建你自己的FieldType, 然后构造一个Field通过传递一个名字,FieldType和值 。

 

note:原来那些老的APIs(使用index,store,termvector enums) 还是存在的(只不过已经是deprecated),为了方便迁移。

这些改变 是 2011 Google Summer of Code Project的一部分(thank you Nilola!).

其它主要改进(Other big changes)

lucene的terms 现在已经是二进制(byte[]); 默认情况下无边无际 UTF-8 编码的Strings, 以Unicode 排序顺序排列。但是Analyzer 是可以自由产生任意byte[]的token.(如CollationKeyAnalyzer就是这样做的).

新的DirectSpellChecker查找提示可以直接从任何一个lucene 索引,这样这避免了维护一个额外的spellchecker 索引。它使用了和FuzzyQuery一样的 fast Levenshtein automata(6+1 2013-2-17)。

Term offsets(term开始结束字符所在的位置)现在可以保存于postings,通过在索引字段时使用FieldInfo.IndexOption.Docs_AND_OFFSETS来实现。期望这对于不需要term vector而能快速highlighting有帮助。

新的AutomatonQuery匹配所有包含了提供的自动机中任一term的文档。WildQuery和RegexpQuery都是简单地构造出相关的自动机,然后再转到AutomatonQuery. 经典的QueryParse会r产生一个RegexpQuery如果你输入的是 filedName:/expression/ 或者 /expression against default field/.

优化(optimizations)

降了这些有趣的新特性以外,也还有一个惊人的性能提升。

如果你使用FuzzyQuery, 针对适度大小的索引你会看到 100-200倍的速度提升。

如果你搜索时使用Filter, 你也可以获取 X3的速度(这取决于filter的密度和query的复杂度),这得感谢于一个改变:filter的使用和删除文档保持一致。(6+1 2013-2-17)

如果在indexing时使用多线程,你将会看到吞吐率的提升,这是因为采用了 concurrent flushing. 现在你也可以使用大于2048M的 IndexWriter RAM buffer.

新的默认Terms dictionary BlockTree只需更少的RAM来保存terms index, 并且有时在terms不存在的情况下可以避免向disk进行查询。另外,field cache 也使用更少的RAM,这主要是不再为每个document保存一个单独的object,而是把character data 打包成共享的byte[] 块。 这直接减少了搜索时73%的内存使用量。

IndexWriter现在buffer term 数据使用byte[]而不是 char[], 这针对ASCII terms 将会少使用一半内存。

MultiTermQuery 现在重写了per-segment,并且cache 每个term的metadata 信息,这样可以在scoring时减少再次的查询。

如果一个BooleanQuery只包含Must TermQuery 条件,这时一个特定的ConjunctionTermScorer会被使用,可以得到25%的速度提升。

减少merge IO影响(reducing merge IO impact)

Merging是一个对IO,cpu相当敏感的操作,这很容易影响到正在进行的搜索。在4.0.0中我们通过两种方式来减少这方面的影响:

Rate-limit merge时的IO,这可以调用FSDirectory.setMaxMergeWriteMBPerSec

使用新的NativeUnixDirectory,针对所有merge 引发的IO,它会跳过操作系统的 IO cache层,而使用direct IO. 这会保证merge不会evict搜索使用的热门pages.

记得在linux上要设置swappiness为0,如果你想最大提升搜索的响应时间。

打开一个input 或者output文件的APIs(Directory.openInput and Directory.createOutput)现在要带上一个IOContext,用来描述需要怎样做(flush 还是merge),因此你可以创建自己的Directory,根据IOContext来改变相应接口的行为。