早餐照例在麦当劳点烟肉蛋套餐。不同的是,小妹终于没拿奶包只递了糖包,并且还殷勤地冲我微笑,我居然很窘迫地避开目光接触,匆匆说了声谢谢就逃到二楼去了。


限行。地铁上看了这篇文章,想到爸妈在家的情景,不由得唰地出现了一幅如何能让自己随时远程在家的图景。

首先,最好是出现自己即时的全身像,等比例大小,这样才有“人在”的感觉。

然后,是要能自动视觉跟随,要等主动环顾,并提供一种“注视”的功能,摄像头最好是隐蔽的,只是通过全身电子影像来形成注视的体验。这样才有”人在“的感觉。

接着,还得能移动跟随,这样才有”陪伴“的感觉。这样的移动应该是在”人在“效果之上进行叠加,否则就很诡异,反而给人一种不安全感。当然,如果是宠物外形的机器人就没有这个问题,因为形成的心理暗示不同。但话说直接养条宠物不是更好?

最后就是要能主动说话,及时介入到当时场景里。主要通过远程视频模式即可。在这样的功能基础之上,其实老人们还可以利用来随时找人聊天,当然,对方也有一套系统才比较嗨。

嗯,还有一个附带的功能,就是帮老人使用电子仪器,比如各种越来越难以理解的遥控器。


这么说起来,相当于一部视频会议系统+等比例影像显示系统+能随行的扫地机器人+穿戴遥控的机械手。

感觉已经是C-3PO的原始原型了[偷笑] ……

原创文章,转载请注明: 转载自御风飞翔flying thru wind

本文链接地址: 陪伴机器人

版权声明:自由转载-非商用-非衍生-保持署名(创意共享3.0许可证)

何谓“正确的”?何谓“可行的”?

符合事实、道理或标准者,谓之为“正确的”。

行得通;可以实行,谓之为“可行的”。

一个是“行得正”,一个是“行得通”。其实很容易区别。

但往往具体到某个问题时,却不见得那么容易说清楚。

当我们说“健康”这个概念时,是“人的一切生理机能正常,没有疾病或缺陷”的意思。那么当我们说“数据健康”的时候,自然应该可以解释为“数据的一切生理机能正常,没有‘疾病’和缺陷”。

于是,我们有必要搞清楚三个概念如何映射到数据身上:

  1. 数据的生理
  2. 数据的机能
  3. 数据的疾病

“生理”是指“生物机体的生命活动和各个器官的机能”。数据有哪些“生命活动”和“器官”呢?简单看,可以从数据与其生命周期中的各种事物的交互中去界定。

套用COBIT考察IT治理能力中的四类“IT资源”作为参照物,考虑“数据与应用的交互”、“信息与数据的交互”、“架构与数据的交互”、“人与数据的交互”。

人与数据,无外乎“望、闻、问、切”。看数据看得懂,听数据听得真,问数据问得明,切数据切得在理。要“懂”得有语义一致性,要“真”要有完整性,要“明”要有可靠性,要“理”有准确性且合规。看的是数据的表现形式,听的是数据的蕴含语义,问的是数据的真相(可追溯、可稽核),想的是数据的有理有据、有法可依,无论看、听、问、想,都要安全可靠(safety & security)。

架构与数据的互动,当然这里必须是IT架构,数据是架构中举足轻重的一部分,不仅是架构中的基础部分,而且是架构的投影。待续。

应用与数据的交互,基本上可以从I/O来理解,当然,还得包括那些永远寄居于应用中的数据。待续。

“机能”是指“作用和活动能力”。数据有哪些“作用和活动能力”呢?待续。

这本书其实很早便相识。但似乎从来没有好好读过。

这次为了让手下新人有所了解,推荐同读,于是“再”翻。

这才发现,原来速读的根本指向是“图像阅读”。而我很长一段时间以来,一直断章取义,竟然是从忽略细节的角度去理解速读的。有些井蛙的味道了。

这是这次阅读的主要收获。至于笔记和思维导图的部分,反而觉得说得不到位。

写了一天的方法体系。最后发现啥都没说明。

 

健康与否,是相对的。必须要有标的。

数据的健康,还是要针对业务而言。但要想把“业务是否正常运行”说清楚,很难抽象出一个放之四方皆准的说明公式,似乎都需要结合具体业务展开刻画。

如果说数据可用,那么不同的业务对于“可用”的具体要求也各异,尽管可以抽象出一个公因数。于是,考虑对比的角度,从业务IT化是否完善的角度出发去寻找标尺。

可是,远看很饱满,近看却实在峥嵘。一整天,没找到一个合适角度。越写越陷在局促的泥潭里,找不到鸟瞰的跃迁点。

也许应该换个方向:先搭建一个简单的衡量体系,然后再包装高大上的堂皇。

 

就数据本身而言?怎样算健康呢?界定清晰的、性质稳定的(自己不易串味)、变化总是有确定原因的、权属明确的、……然后再给每个方向找一个牵引方。

这个主意不错。

很久没到过西单了。

路过,发现这么多年,西单似乎没啥打变化。

一路向北,护国寺、新街口……发现从西单到新街口一带,街景看起来跟二十年前差不多。

也就是说,至少有十年没到西单逛过了,甚至更长。上一次来,应该也是去附近那个新华书店吧。

今天风很大,愈发显得宣武门外大街太宽。过马路要绕到很远的路口才有天桥。

越是宽阔的地方,于是需要绕远。直觉上很矛盾。想了想,说明这里不是生活街区,这里是显示某种庄严宝象之所,只需要远观,不需要接近。

这是也许可以是一个理解的角度,为啥很多国家的行政机关所处是很逼仄的场所。

因为要“虚假”地显得容易亲近吧。


不知道从什么时候开始,windows平台上的自动化测试工具开始叫做“自动流程机器人”了。仿佛带上“机器人”三个字就脱胎换骨了似的。然而……

原创文章,转载请注明: 转载自御风飞翔flying thru wind

本文链接地址: 到西单开会

版权声明:自由转载-非商用-非衍生-保持署名(创意共享3.0许可证)

正想着实习生作为的日志的事,想着后续如何引导。突然想到意识到一个问题:这个孩子的问题太少了。

我的第一个反应是,这应该是没有好奇心的表现。转念一想,主要是不懂的问自己问题。

然而,问出问题,跟好奇心,到底哪个驱动哪个?

如果套用左右脑模型,问出问题,是左脑的功能。那么好奇心是那边的功能?据说是右脑。

不过从“词用”的角度讲,其实是先有问题后有心的。因为人应该是先看到“问问题”这种现象,然后总结出“好奇心”这种性质的。

脑子有抽筋了一下:那么,“好奇心”跟“同理心”之间有关联性吗?

知乎上查,有个答案说得好有意思:“树丛中听到奇怪的声音,你不好奇,转眼你就被野兽吃掉……这种淡定的基因就悲惨地灭绝了”。这是本能说。那么,人都有好奇心,是脑子固有机制,只是不同人强弱不同。

慢着,应该是动物都有好奇心才对,因为按照上面说法,没有好奇心的动物应该早灭绝了。可是,好奇心并没有驱使这些动物都变得智慧啊?可见上面说的场景中,不仅仅有好奇心,还有“警觉性”这个因素在其中,甚至可以说是“恐惧心”更合适些![汗]

百度百科说:

好奇心是动物处于对某事物全部或部分属性空白时,本能的想添加此事物的属性的内在心理。表现为:1、对一些事物表示特别注意的情绪。2、喜欢探究不了解事物的心理状态。3、 对于怪诞的嗜好或热情。

了解到这儿,我就想,这好奇心的特质太重要了,招聘员工的时候,如何发现应聘者的好奇心重不重呢?于是再找答案,知乎有同类问题,说:可以反过来找。“怎样判断一个人对世界缺乏好奇心?”

嗯,是个好方法,但这个需要长期观察。有没有更简便直接的?同问中有人说可以使用“Curiosity and Exploration Inventory (CEI-II) (好奇心与探索清单)”

作者:YorN
链接:https://www.zhihu.com/question/60781615/answer/207631722
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

  1.  I actively seek as much information as I can in new situations.1. 遇到新情况时,我会尽可能地搜寻更多的信息。
  2.  I am the type of person who really enjoys the uncertainty of everyday life.2. 在日常生活中,我是那种真的会享受不确定性的人。
  3.  I am at my best when doing something that is complex or challenging.3. 在做一些复杂和有挑战的事情是,我的状态是最好的。
  4.  Everywhere I go, I am out looking for new things or experiences.4. 无论去到什么地方,我都会出门去寻求新的事物和体验。
  5.  I view challenging situations as an opportunity to grow and learn.5. 我将有挑战的处境视为成长和学习的机会。
  6.  I like to do things that are a little frightening.6. 我喜欢做那些让人感到有一点点恐惧的事情。
  7.  I am always looking for experiences that challenge how I think about myself and the world.7. 我一直在寻找那些能挑战我对自己和世界认知的体验。
  8.  I prefer jobs that are excitingly unpredictable.8. 我更偏爱令人兴奋的不可预测的工作。
  9.  I frequently seek out opportunities to challenge myself and grow as a person.9. 我经常寻找机会去挑战自我,使自己成长。
  10.  I am the kind of person who embraces unfamiliar people, events, and places.10. 我是那种会去拥抱不熟悉的人、活动和地方的人。

这十个条目被分为两类,第一类叫做Streching(1,3,5,7),是用于测量被试寻求新信息和新体验的动机;第二类叫做Embracing(2,4,6,8,10),用于测量被试在日常生活中拥抱新鲜、不确定和不可预测事物的意愿。

正式的量表不像网络上很多人自创的各种“心理测验”,随便一个人拿过来就可以测,如果真的要使用还要仔细阅读作者的原文[1][2][3],弄清楚使用的条件和限制。

类似的量表还有很多,比如用于测量社交过程中好奇心的量表 Social Curisotiy Measure[4],用于测量对知识好奇心的Epistemic Curiosity Inventory[5],有“好奇心”的人可以自己去慢慢研究。

参考文献:

1. Kashdan, T.B., Gallagher, M.W., Silvia, P.J., Winterstein, B.P., Breen, W.E., Terhar, D., & Steger, M.F. (2009). The Curiosity and Exploration Inventory-II: Development, factor structure, and initial psychometrics. Journal of Research in Personality, 43, 987-998.

2. Kashdan, T.B., McKnight, P.E., Fincham, F.D., & Rose, P. (2011). When curiosity breeds intimacy: Taking advantage of intimacy opportunities and transforming boring conversations. Journal of Personality, 79, 1369-1401.

3. Kashdan, T.B., Dewall, C.N., Pond, R.S., Silvia, P.J., Lambert, N.M., Fincham, F.D., Savostyanova, A.A., & Keller, P.S. (2013). Curiosity protects against interpersonal aggression: Cross-sectional, daily process, and behavioral evidence. Journal of Personality.

4. Renner, Britta. “Curiosity about people: The development of a social curiosity measure in adults.” Journal of personality assessment 87.3 (2006): 305-316.APA

5. Litman, Jordan A., and Charles D. Spielberger. “Measuring epistemic curiosity and its diversive and specific components.” Journal of personality assessment 80.1 (2003): 75-86.

列出这些参考文献,回头倒是可以找来仔细学习一下。毕竟研究者还分析出好奇心的成分:探索和尝试。

原创文章,转载请注明: 转载自御风飞翔flying thru wind

本文链接地址: 问问题

版权声明:自由转载-非商用-非衍生-保持署名(创意共享3.0许可证)

这篇微信公号文章说了一个观点:“概率统治世界”。

我倒是觉得,这个世界的本质,就是基于概率的运行体制,符合幂律分布,积累效应。

如此说来,宇宙中生命可能有很多,但智慧生命应该很少。

但是,作者得出的结论是:“你穷不仅仅是因为懒,更可能是你出卖了自己的概率权。”

有意思的启发点。作者的主张有以下几点:

  1. 选择稳定,等于放弃概率权
  2. 做大概率会赢的事,比如“坚持做价值投资”,比如“一辈子要好好读书”,比如“创业前要打好底子”,比如“最好去一线城市”。
  3. 避开大概率危机:失业、35岁之后生娃。

统计学真是人生最基础的知识。

原创文章,转载请注明: 转载自御风飞翔flying thru wind

本文链接地址: 概率统治世界

版权声明:自由转载-非商用-非衍生-保持署名(创意共享3.0许可证)

突然冥想了一下两者的区别。

每天都做饭的家庭,跟每天基本不做饭的家庭,氛围一定有很大不同。

就中国人而言,可以肯定,油烟味肯定是浓淡差别很大。就我的经验而言,厨房升火做饭的家里,总是让我隐隐有一种焦虑感,每到饭店就惶惶不可终日,因为做饭是一件压力很大的任务。

而家里基本不开火,那跟住旅馆很像,随时都属于想干嘛干嘛,随意得很。

于是,区别好像就是,责任感不同。

原创文章,转载请注明: 转载自御风飞翔flying thru wind

本文链接地址: 做饭不做饭

版权声明:自由转载-非商用-非衍生-保持署名(创意共享3.0许可证)

偶然在知乎上看到问题“腿长是什么感受”之类的,这种时候就常会遇到一类人来蹭话题热点,假借晒感受来晒腿长。于是就有人要从中挑出哪些假装腿长强晒感受的人

从中学到几个印象深刻的知识点:

  1. 屈膝抱腿坐时,膝盖距离肩膀的远近可以看出腿长不长,
  2. 手自然下垂时,腿长的人腕线是过裆的。
  3. 头长与身高比在7以上接近8是人中高个,
  4. 裆到脚根比身高接近45%,是人基本不会超过50%,甚至48%都是稀有。

感觉最后一点可以用来作为科幻片中识别机器人的梗了。

然后很诚实地坐在地上,学着林志玲把手掌按在身侧地上,发现两上肢能呈45°以上张角。

于是瞬间对自己的身材很满意。

原创文章,转载请注明: 转载自御风飞翔flying thru wind

本文链接地址: 腿长腿短

版权声明:自由转载-非商用-非衍生-保持署名(创意共享3.0许可证)

这一天很衰。

两台捆绑了IP用于采集数据的服务器发现都宕机了。

应该是已经有一阵子了,没发现。

结果本来兴致勃勃要调程序的,一点兴致都没有。

其实本来应该是立刻有兴致找解决方案的。


需要一个轻量级方案。

有个IP列表,表上IP既是攻方又是守方。

需要实现一个协议,用于双方握手。

向对方喊一声,以便确认彼此是否还在。所以这里应该有一个应答。相当于做一次http请求:“(我是X)你在?”,“在”。

但同时要求任意一方均可确认IP列表上的每一个都“在”,最简单的方式是,每个都问候一遍。不经济,但简单。

(暂停)

今天购买的49吋的sony电视终于顺利地让丈母娘用上了。

之前订购了65吋的小米电视,价格差不多,送货也快,可惜由于安装服务的人水平太水,居然不知道视频模拟信号是需要独立从机顶盒接入的,结果没能按老太太的需求把凤凰台给调处理。老太太想了几个理由,包括遥控器没有数字键、屏幕太大了头晕等,给退货了。

现在想想,其实订小米的65吋是自己的喜好,尽管也有考虑到小米的界面易操作的因素。但年纪再大一些的人确实有自己的使用习惯,从自己的角度出发,容易限于盲点。

不过根据实际体验,sony的屏幕确实更艳丽锐利,视觉效果要更舒服一些。只可惜,平时都看电视节目,分辨率不够的情况下,这点优势根本无法体现。

另外一点,就是现在的电视在互联网公司的冲击之下,确实大家都更重视内容了。

原创文章,转载请注明: 转载自御风飞翔flying thru wind

本文链接地址: 买电视

版权声明:自由转载-非商用-非衍生-保持署名(创意共享3.0许可证)

下午的时候,雨终于下了。到了快下班的时间点,眼看着雪渐渐大了起来,等我们九点多从公司离开时,都可以用鹅毛形容了。

所以,刚走出大楼,有一姑娘兴奋地站在这洋洋洒洒的雨夹雪中,平举双臂兴奋不已。

按说大家每天都是上下班,今天也是如此,可是就是堵得不行。平时30多分钟的行程,愣是要一个多小时。


本来安排今天下午三点中开始合版本,不过大家手头都有工作未完成,所以迟迟没法发布。六点多发出来之后,我立刻找到了感觉,可以比较清楚地想明白当前距离向用户交货还有哪些关键问题尚未解决。

所以如果要快速开发,更频繁地集成是非常必要的。集成的好处在于:

  1. 可以更明确地指明开发任务的基线,
  2. 可以更清晰地发现潜在的问题,
  3. 可以更准确地定义开发人员之间的接口。

比如今天一直在讨论的数据导入问题,在功能需要能在界面上被使用的情况下,驱动大家去直面任何跟这一目标有冲突的缺陷。当然,导入功能其实昨天就已经安排,只不过有个deadline的情况下,参与人更容易在倒计时中找到那些瓶颈点。

今后要坚持每周集成,并且应该把集成时间放在周中,这样可以有足够的余量来修正下一步的方向和步幅。

原创文章,转载请注明: 转载自御风飞翔flying thru wind

本文链接地址: 更频繁地集成

版权声明:自由转载-非商用-非衍生-保持署名(创意共享3.0许可证)

醒得早。

早出门,到公司附近吃完早饭,还不到七点半。

于是到了公司之后,还来得及在椭圆机上跑了二十分钟。

一身汗。

先处理了实习生的毕设课题进展中的问题,然后着重把近期项目的功能需求罗列盘点了一番。由于一直没有给出这个列表,导致开发取法一个总体概貌,在安排后续开发计划时,显得比较盲目。

等我列完,果然有了进一步的成果:一个简洁版的产品基线清楚地裸露出来。

不过,另一方面,也让我隐约感觉到,前期安排开发计划时,未能把握住产品的核心精髓所在。

基于“元模型驱动的开发一切”仍然是之后一波开发季中的扛鼎硬梗,应该坚决夯实,否则会再次走到“起早晚集”的境地。

原创文章,转载请注明: 转载自御风飞翔flying thru wind

本文链接地址: 一大早

版权声明:自由转载-非商用-非衍生-保持署名(创意共享3.0许可证)

好久不写影评了。

看着片子,一半是因为一篇吹得天花乱坠的软文,一半是因为最近实在没啥出色科幻制作。

但意外之喜是,这片子里浓浓的半边天味道,咋一看不起眼,好像是近来常见的商业电影中为取悦男性观众而刻意营造的女性色彩,但细一咂摸,却是种不可逆的强大潜流正在渐渐形成水面上的喧闹浪潮。

第一组镜头交待了故事背景:防化服、被询问的女人。这组镜头有些背光,我没认出女主是由那个演员扮演。后来我一直怀疑这是导演故意安排的,暗示着一种异常。

虽有第二组镜头交待了故事的起因:陨石异常降临。

然后通过一组细胞分裂的视频女主被介绍进入故事主线,一位生物学教授。然后一组剧情介绍女主离群索居有伤心故事,于是异常事件出现就容易理解。舒缓的剧情伴随着救护车和警察的吵杂鸣笛声似乎骤然加速。

接着介绍灵异现象也简单直接到可以说是不动声色。女主留在基地,认识了一些女兵,于是也就顺理成章地加入了行动。到此为止,半数以上的镜头都是女人的事实你也许还没意识到,但是接着……

五个端枪女兵雄赳赳气昂昂地杀进神秘地域。我才恍然大悟:当下已经不仅是女性顶半边天,而是正在快速滑向靠女性拯救世界的时代。影片给出了强烈的隐喻:光靠男性就能救世的日子已经一去不返,女人们来了。她们不仅智商高、才情高,武艺也高超。

然后,出现一个bug。不明白编剧为啥要安排一个4天空白期。一觉醒来,女兵们发现她们深入腹地,一个透着诡异变化的深处。这里搏想象力了,也是前面说的软文着力强调之处。不过很遗憾,有些过誉。但几处安排,尤其是那个help的梗,非常出彩。

结尾老套了。非常遗憾。

  • vbox版本是:5.2.8 r121009(Qt5.6.3)
  • centos用的是CentOS-7-livecd-GNOME-x86_64.iso缺省安装

一开始vbox从5.2.6升级到5.2.8就掉一个小坑里:extend没有相应升级。因为着急嘛。结果为了利用磁盘空间,使用vbox的共享目录功能时,编译VirtualBoxGuestAdditions死活过不去。一个下午到处找原因,现象是无论怎么处理,安装日志则提示selinux的某个设置有问题。一直就知道vbox extend包必须同版本升级,所以在尝试了半天找各种lib和repo之后,用vbox查看更新解决问题:检查更新之后,提示已经是最新版本,然后自动跳出提示是否更新extend。

但还是无法编译,反复提示kernel-devel和header的版本不对。狗屎运发作找到这篇文章给出了关键提示:需要设置环境变量“KERN_DIR”!然后这里又一小坑,后面的路径必须根据实际环境设置,因为版本不同。比如我的实际版本应该是设置为

/usr/src/kernels/3.10.0-693.21.1.el7.x86_64/build

一开始使用vbox的缺省配置8GB建的虚拟机,拷贝oracle安装文件时空间不够了。分别尝试了三种方法:

  • 建一个新的vdi,然后clone旧的;
  • 使用vboxmanager扩容旧的;
  • 使用vbox的全局工具扩展。

都不行。只能重新建一个新的虚拟机,把一次硬盘空间给足😓。

这篇oracle安装文章还是很到位,值得参考,全程基本靠它了。

建库的时候,遇到listener参数错误问题(ORA-00119和ORA-00130),这篇比价到位。

VSM在维基百科的解释,关注其提及的局限:

  1. 不适用于较长的文档,因为它的相似值不理想(过小的内积和过高的维数)。
  2. 检索词组必须与文档中出现的词组精确匹配;词语子字串可能会导致“假阳性”匹配。
  3. 语义敏感度不佳;具有相同的语境但使用不同的词组的文档不能被关联起来,导致“假阴性匹配”。
  4. 词组在文档中出现的顺序在向量形式中无法表示出来。
  5. 假定词组在统计上是独立的。
  6. 权重是直观上获得的而不够正式。

然而,这些局限中的多数能够通过集合各种方法来解决,包括数学上的技术(比如奇异值分解)和词汇数据库(比如WordNet)。

关联性开源资源中,SemanticVector是一个可以进一步了解的概念:“SemanticVectors语义向量索引,将随机投影算法(类似于潜在的语义分析)应用于Apache Lucene构建的文本词组矩阵。”

潜在语义分析(LatentSemanticAnaiysis,LSA)是一种用于自动地实现知识提取和表示的理论和方法,它通过对大量的文本集进行统计分析,从中提取出上下文的语义。以下部分来源自https://www.zybuluo.com/Hederahelix/note/102857

LSA的步骤如下:
1. 分析文档集合,建立Term-Document矩阵。
2. 对Term-Document矩阵进行奇异值分解。
3. 对SVD分解后的矩阵进行降维,保留前个特征值,后面个置零,也就是低阶近似。
4. 使用降维后的矩阵构建潜在语义空间,或重建Term-Document矩阵。新得到的Term-Document矩阵就是我们经过LSA模型提取低维隐含语义空间。该空间中,每个奇异值对应的是每个“语义”维度的权重,我们刚才将不太重要的权重置为零,只保留最重要的维度信息,因而可以得到文档的一种更优表达形式。

通过SVD可以进行LSA,把给定文档投影到语义空间,但其缺乏严谨的数理统计基础并且SVD分解非常耗时。

想象某个人要写篇文档,他需要确定每篇文档里每个位置上的词。假定他一共有个可选的主题,有个可选的词项,所以,他制作了面的“主题-词项”骰子,每个骰子对应一个主题,骰子每一面对应要选择的词项。然后,每写一篇文档会再制作一颗面的“文档-主题”骰子;每写一个词,先扔该骰子选择主题;得到主题的结果后,使用和主题结果对应的那颗“主题-词项”骰子,扔该骰子选择要写的词。他不停的重复如上两个扔骰子步骤,最终完成了这篇文档。重复该方法次,则写完所有的文档。在这个过程中,我们并未关注词和词之间的出现顺序,所以pLSA也是一种词袋方法。

在原始的pLSA模型中,我们求解出两个参数:“主题-词项”和“文档-主题”,但是我们并未考虑参数的先验知识;而LDA的改进之处,是对这俩参数之上分别增加了先验分布,相应参数称作超参数(hyperparamter)。

在pLSA原参数之上增加先验分布,其实就是用贝叶斯估计取代最大似然估计,具体要了解各种参数估计方法可以参考Heinrich论文的第二部分。

由于有积分的存在,贝叶斯估计常常会很难推算,这里我们就需要利用一种共轭先验(Conjugate Prior)的数学知识。在贝叶斯统计理论中,如果某个随机变量的先验分布和后验分布属于统一分布簇(简单说就是有同样的函数形式),则称先验分布和后验分布为共轭分布,先验分布是似然函数的共轭先验。

由于pLSA中参数“主题-词项”和“文档-主题”都服从多项分布,因此选择Dirichlet分布作为他们的共轭先验。

原创文章,转载请注明: 转载自御风飞翔flying thru wind

本文链接地址: VSM、LSA、LDA

版权声明:自由转载-非商用-非衍生-保持署名(创意共享3.0许可证)

知乎问题,我的答案在这里

这个话题挺有趣,不邀自答。
分几个角度。
[程序员]作为一种职业,要遵循所有职业共有的规矩。从业者存于市场,如同生物存于自然界。作为群体,有繁衍和灭绝。作为个体,有老少有四季。所以职业同样需要做好周期管理。不论是松鼠的过冬储备粮还是狗熊的一身膘,都是对自然律的主动适应。职业也一样,有经济周期有技术周期,从业者必须对此知冷热。如果题主所谓“纯靠技术”是指不考虑这些周期的话,那就得靠运气了,运气好的话,可以。比如你早年用C,后来转C++,又机缘巧合熟练objectC,那我估计在这个技术栈上还可以走很久。
[技术]仿佛从业十年之后不转管理就不算职业成功似的。然而,只要有分工就有价值链,如同有物种就有食物链。你搞技术如果一入行就在价值链低端,一生风险就重峦叠嶂。如果能逐步占据高端,最后就只有同类相侵,那自然保险。据说高级品酒师全国人数屈指可数,那真是平步江湖了。但技术再NB,还得有知名度,不然也会困顿而终。
[中年]但题主的“纯靠技术”显然不是说“成为高手”,而是“纯靠平庸技术”的意思。所以还是得说“储备粮”,二十岁为三十岁投资,三十岁为四十岁投资,四十岁为一辈子投资。如果你四十岁的时候没能用上你二三十岁时写下的代码,那恰好说明你的程序员人生基本失败。但恰恰是这点,作为程序员的职业教育中往往极度缺乏。导致大部分从业者完全没有意识到这点其实恰是程序员职业与其它行业、工种最大的不同。
综合以上,如果你从入行第一天开始就主动思考以下三个问题并付诸行动,那么我认为你有很大概率靠技术渡过中年危机:①怎样才能在明天的编程工作中使用今天的代码作为“助手”,②怎样才能在今天看清明天才会出现的技术,③找一个或者做一个同行社区并融入其中。
你瞧,以上三点,至少有一点看起来跟技术并不必然相关,所以不纯。

群组授权的定义:

  • 一个群组的权限是这个群组所有成员都可以使用的权限。
  • 一旦对群组赋权,则意味着每个成员都拥有该权限。
  • 若群组的某个成员缺失某个权限,则群组也失去该权限,但不影响群组的其他成员的授权,即该授权变成是基于个人的授权。

与角色不同的意义:

  • 权限切分的口径不同。

我在models中使用cast来获得更新数据:

@required_fields ~w(area_id biztype_id shop_name shop_addr code_3rdParty)
@optional_fields ~w(logo_url addr_lat addr_lon name_3rdParty)

def changeset(model, params \\ :empty) do
model |> cast(params, @required_fields, @optional_fields)
end

在controllers中的update是:

shop = Repo.get!(ProjTest.Shops, String.to_integer(id))
shop = ProjTest.Shops.changeset(shop, post_params})
case Repo.update(shop) do
{:ok, post} ->
json conn, post
# render(conn, “show.json”, post: post)
{:error, changeset} ->

……

结果始终无法执行update,打印changeset的结果为:

#Ecto.Changeset<action: nil, changes: %{}, errors: [], data: #ProjTest.Shops<>,
valid?: true>

百思不得其解。终于找到一贴:说“`Ecto.Changeset.cast/4` is deprecated”。于是尝试将model中的changeset改为:

@all_fields ~w(area_id biztype_id shop_name logo_url shop_addr addr_lat addr_lon code
_3rdParty name_3rdParty)

def changeset(model, params \\ %{}) do
model |> cast(params, @all_fields)
end

遂得到正常结果:

[debug] QUERY OK db=92.8ms
UPDATE `shop_info` SET `logo_url` = ? WHERE `id` = ? [“test_put Updated”, 387]
[info] Sent 200 in 126ms

在煎蛋网上看到这张照片,禁不住要收藏一下。一开始愣是没注意到倒过来之后两个字就解读不同了。这么设计出来得是什么样的脑回路呢。

中午饭后,我不知怎么想到了“开发软件应该首先对程序员友好”这个观点。这是从架构设计的出发的。如果对程序员不够友好,必然导致开发效率低下,自然会衍生出更多的bugs,软件对用户友好就谈不上了。

也许是这些天一直在看GenServer的缘故,文档中提及了mix和OTP的区别,前者提供开发一个project的工程便利性,后者提供运行一个application的调试便利性。

于是跟同事聊起来这个观点,话题漫游开去,谈到了遗传基因,让我意外的是,丹也随口提及诸多知识点,作为女生,至少比起苏菲来,理工类的阅读面甚广。

原创文章,转载请注明: 转载自御风飞翔flying thru wind

本文链接地址: 程序员友好性

版权声明:自由转载-非商用-非衍生-保持署名(创意共享3.0许可证)

头晚到,老师躲着不见面,让我比较意外。费心安排起居,虽说也是人之常情,但相形之下倒是反而显得有些小气。

客户倒是热情又随意,尽管看得出跟老师不是一般的相识,也能感到是一个性情中人。只可惜有线电视的国营体制,在互联网、流媒体等一众“江湖好汉”的兴风作浪之中,江河日下,已经颇有些门前冷落鞍马稀的萧索。加之又是前往日后作为备份的监控中心,破败之像更是显得欲盖拟彰。

不禁唏嘘。倒不是因为有线行业不可逆的颓势,而是因为看起来白跑一趟。

原创文章,转载请注明: 转载自御风飞翔flying thru wind

本文链接地址: 杭州行

版权声明:自由转载-非商用-非衍生-保持署名(创意共享3.0许可证)

今天终于把答应节前调整的界面搞定了,其中有各种小疏忽,还四处打扰正在忙碌的小伙伴。

事实证明,现在这个基于数据对象定义既创建数据库又创建交互界面的架构,在信息维护类的应用系统范畴内,真是方便。

尤其是在清晰定义了对象之间的关联关系的情况下,可以直接进行关联定义,并且任意一处的信息变动,在关联的各处看来都相应变化,让人心情愉悦。

当然,还是有一些值得再完善的地方,比如查询条件目前只能基于对象的属性进行,尚无法基于被关联的信息来查主对象。

下一步,可以开始关注如何替换数据采集部分的python程序了。

原创文章,转载请注明: 转载自御风飞翔flying thru wind

本文链接地址: 界面调整完毕

版权声明:自由转载-非商用-非衍生-保持署名(创意共享3.0许可证)

一早起来,开始按昨天晚上走通的方式,将新的数据接口替换成旧的接口格式,以便维持对端的程序兼容性。

昨天主要解决两个问题,一个Enum.map的使用,一个是map/struct如何实例化。关于Enum.map我一开始只是没有注意到,该函数实际上是直接将list做了返回的,后来偶然在某篇网文中注意到有个变量赋值是接收该函数的输出,才恍然大悟。

newlist = Enum.map(oldList, fn(x)-> … end)

另一个是map与struct的区别,实际上struct是基于map构造的,所以

%{}

表示一个空的map的情况下,struct是需要声明的

defmodule Astruct do

defstruct attr1: nil, attr2: “defaultValue”

end

则新的struct可以以下方式表示

%Astruct{}

这里面一开始我对于匿名函数如何写也很困惑(现在依然困惑),但搜索网文是某篇文章时看到一句话“函数总是以最后一行的输出作为返回值”,还是帮了我不少忙。


晚饭后外出散步,陪苏菲去SM广场转转。总是经过,却似乎就没进去转过,126路三站就到,幸好方便。先到一期,走进去才发现人头攒动,人气旺盛,显然是消费升级依然完成的局面。其实去年回来的时候,万达广场那边也就是类似情况。

从一期连接二期的廊桥走到“新生活广场”这侧,有个生鲜超市让我们很意外,榨果汁、煎三文鱼、烤牛排、滤咖啡……在货架间安排了一些可以现做现吃的摊位,这样的形式显然是我们以前逛超市没有想到的,算是年轻人生活时尚带来的新消费方式?

嗯,忘了拍照了,回头想办法补上。

到家的第一天。先支起小桌子把工作环境建起来,开始继续研究如何将mysql的timestamp类型在ecto无法直接转换成string的情况下,从query结果的map里取出来做处理。缺省情况下,ecto将naive_datetime类型转换成一个结构,如下:

{{y,m,d},{h,m,s,ms}}

然后ecto缺省的json封装接口poison无法正确处理这个结构,必须手工处理。一天功夫,终于摸索出方法:

shops = Enum.map(shops, fn x -> %{id: x[:A_ID], item_name: x[:P_ITEM_NAME], begin_time: transform(x[:P_BEGIN_TIME]), end_time: transform(x[:P_STOP_TIME])]}

defp transform({{y,m,d},_}) do
Integer.to_string(y) <> “-” <> Integer.to_string(m) <> “-” <> Integer.to_string(d)
end

函数式写起来还是很畅快的。

一早起来,开始整理以“gra”作为前缀的几个近期开发的项目。发现

  • graMeta
  • graForm
  • graGit
  • graFlow

这样一套“graX”组合起来,确实可以很灵活地处理掉一堆的MIS类问题。设计目标实际上初步是达成了,只不过后续还有一堆的优化问题。

原创文章,转载请注明: 转载自御风飞翔flying thru wind

本文链接地址: GraX

版权声明:自由转载-非商用-非衍生-保持署名(创意共享3.0许可证)

今天的时间也是安排得很紧。一早起来先去超市买菜,然后赶着去接上苏菲,再去拜会丈母娘。下午还得赶着回公司讨论需求。

原本倒是没这么赶,只是吃早饭的时候临时通知,董事长临时出现在公司了,同事约好下午可以讨论一下需求。

实际上也没有真正解决问题,依旧是敷于表面。我们实际上希望在业务层面深入讨论,但老师显然习惯思维是如何布局项目建设。

于是,回到家,我尽快补充了资源预算,以便可以在节前来得及交作业。

今天在现场忙了一天,我主要是给juyou重写接口程序,没人打扰,进展较快。

Chen则忙着部署。显示环境各种连不上,然后是各种缺软件,下午中午部署成功了,却没有将行方指定的数据库采集过来。

从行里回到宾馆,大概六点左右。顺着采集数据的事情,一路聊到我们为什么要循着元数据的思路做采集。

接着Chen抛出大问题:前天大家讨论问题的时候,一开始可以跟上,但后来大家开始进行数据模型设计的时候,发现思路跟不上,听不懂了,心理很挫败,感觉通过漫漫讨论就可以很快抽象出数据结构很厉害。

我一想,首先这不奇怪。这些人都是十几年的工作经验,何况大家之前还都不同程度地接触过jBPM,所以能快速给出process management的模型在我看来很正常。甚至我觉得太过于收到jBPM的影响反而不美。

给Chen分析了一下,提出需要“从业前的知识准备”的观点,简称“职前知识准备”。1、凭兴趣最好,否则也需要如何锻炼身体一般,机械性地广泛了解这个行业的相关历史或者了解都有哪些专业领域。当然也需要结合工作本身,否则一个行业大小领域几乎不胜枚举。2、不仅宽泛,也必须有坚持有某一两领域是专精的,否则缺乏有方向的牵引力和有穿透力的观察力。3、建立职前知识体系也是一个建立一个信息取舍规则的过程,看得多不是为了懂得多,而是为了更擅于识别。建立起自己的去芜存菁的规则体系。实际上,这个取舍体系有了,职前知识准备也基本就具备了。

知识体系本身是需要不断更新的。联系自身,职业经历中有过两次较大的变更。但两次都不彻底,如果说第一次还是无意识中不能深入的话,那么后一次则直接是有些主动回避了。

难怪职业道路有越走越窄的感觉。