Category Archives: 他山石

他山石

几个简单的推荐算法图解(转)

1. 基于内容的推荐:

上图给出了基于内容推荐的一个典型的例子,电影推荐系统,首先我们需要对电影的元数据有一个建模,这里只简单的描述了一下电影的类型;然后通过电影的元数据发现电影间的相似度,因为类型都是“爱情,浪漫”电影 A 和 C 被认为是相似的电影(当然,只根据类型是不够的,要得到更好的推荐,我们还可以考虑电影的导演,演员等等);最后实现推荐,对于用户 A,他喜欢看电影 A,那么系统就可以给他推荐类似的电影 C。

2. 基于用户的协同过滤推荐(User-based Collaborative Filtering Recommendation)

上图示意出基于用户的协同过滤推荐机制的基本原理,假设用户 A 喜欢物品 A、物品 C,用户 B 喜欢物品 B,用户 C 喜欢物品 A 、物品 C 和物品 D;从这些用户的历史喜好信息中,我们可以发现用户
A 和用户 C 的口味和偏好是比较类似的,同时用户 C 还喜欢物品 D,那么我们可以推断用户 A 可能也喜欢物品 D,因此可以将物品 D 推荐给用户 A。

3. 基于项目的协同过滤推荐(Item-based Collaborative Filtering Recommendation)

上图表明基于项目的协同过滤推荐的基本原理,用户A喜欢物品A和物品C,用户B喜欢物品A、物品B和物品C,用户C喜欢物品A,从这些用户的历史喜好中可以认为物品A与物品C比较类似,喜欢物品A的都喜欢物品C,基于这个判断用户C可能也喜欢物品C,所以推荐系统将物品C推荐给用户C。
———
转自:https://www.zhihu.com/question/19971859

Hello World 他山石

defineProperty

学习VUE“双向绑定”的实现,DOM变化时,同步给js变量,这一层比较容易理解,使用DOM的事件绑定就好了;但是当js变量发送变化时,是如何监控到、然后更新到DOM的,这点就比较有意思的。
看VUE代码,里面使用了ES5新加入的“Object.defineProperty()”,属性拦截器

看名字就比较好理解,使用defineProperty定义的属性,可以针对getter,和setter操作做监控、拦截,比如下面:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
let o = {};
Object.defineProperty(o, 'b', {
  configurable: true,
  enumerable: true,
  get: function(){
    console.log('get run');     //log1
  },
  set: function(v){
    console.log('set run', v);  //log2
  }
});
 
setInterval(function(){
  o.b = new Date().toLocaleString();
  console.log('o.b, ', o.b);     //log3  undefined
}, 3000);

这样,每隔3秒,log2,o.b赋值时,log2,就会被打印出来
但是,下面的反应比较奇怪,getter也被拦截了,log3位置,打印出来的是“undefined”。。。
这是因为getter里没有返回值
但是如果你胆敢在getter“return this.b”,运行时就会死循环,因为如果this.b又会去调getger
(是的,这就是js。。。增加一个看似“美丽强大”的新特性的同时,还给你附加几个坑,等你往里跳。。。。。)
那么,还能不能让人好好使用这个拦截器哪?
当然可以,这里,我们可以加一个“中间变量”过渡,setter时,给中间变量赋值;getter时,return这个中间变量,就不会死循环了

当然,还可以借助经典的“function-Class”定义,对整个过程做封装,比如:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
function O1(){
  let v1;     //中间变量
 
  Object.defineProperty(this, 'v1', {
    get: function(){
      console.log('get run', v1);
      return v1;
    },
    set: function(v){
      v1 = v;
      console.log('set run', v);
    }
  });
}
 
var o1 = new O1();
 
setInterval(function(){
  o1.v1 = new Date().toLocaleString();
  console.log('o1.v1, ', o1.v1);
}, 3000);

———
转载请注明出处: http://www.jiangkunlun.com/2019/06/js_defineproperty

Hello World 他山石

[转]php字符串首字母转换大小写

首字母变大写:ucwords()

$foo = 'hello world!';
$foo = ucwords($foo); // Hello World!
$bar = 'HELLO WORLD!';
$bar = ucwords($bar); // HELLO WORLD!
$bar = ucwords(strtolower($bar)); // Hello World!

第一个词首字母变大写:ucfirst()

$foo = 'hello world!';
$foo = ucfirst($foo); // Hello world!
$bar = 'HELLO WORLD!';
$bar = ucfirst($bar); // HELLO WORLD!
$bar = ucfirst(strtolower($bar)); // Hello world!

第一个词首字母小写lcfirst()

$foo = 'HelloWorld';
$foo = lcfirst($foo); // helloWorld
 
$bar = 'HELLO WORLD!';
$bar = lcfirst($bar); // hELLO WORLD!
$bar = lcfirst(strtoupper($bar)); // hELLO WORLD!

字母变大写:strtoupper()

字母变小写:strtolower()

转自:http://www.jiangkunlun.com/?p=1454&preview=true

他山石

[转]前端开发的一些经验

上上周百度技术沙龙的是前端开发专题,第二场,来自豆瓣的前辈王克军所讲的“工程之美”给我留下了深刻的印象,以下ppt节选

  • 业务逻辑复杂时,通用和业务代码的分离、复杂度控制
  • 需求多变时,大而全的通用组件无用武之地,轻量的,功能单一的更便于复用
  • 工具防止人做愚蠢的事,也阻碍人干聪明的事
  • 工具不是越强大越好,而是简单有效最好
  • 工具不是越傻瓜越好,要留给他人发挥的空间
  • 前端开发,80%是工程问题,20%是技术问题
  • 模块要完全独立(借助工具实现)
  • 通用代码中绝不混杂业务逻辑
  • 代码逻辑复杂时,应该按业务拆分,不是按展现拆分
  • 代码架构借鉴SOLID原则(职能分离、开闭、里斯替换、接口分离、依赖反转)
  • 从实际开发中积累形成生态体系
  • 技术问题上开放,工程问题上保守
  • 在完成的基础上追求完美
  • 工具要简单,配置要简单
  • 工具是可以替换的,而且总是多变的,不要成为工具的努力
  • 对于复杂的问题,不断进行才接直到足够简单
  • 学点原研哉的Exformation哲学
  • 更多的时间做有趣的事!

“我们的发明常常是漂亮的工具,只是吸引我们的注意力,使我们离开了严肃的事物。”—-卢梭《瓦尔登湖》

更多精彩,请关注现场视频(估计过几天会更新上来):http://www.infoq.com/cn/zones/baidu-salon/

 

 

 

业界杂谈 他山石

关于WebKit的几个问题

1. WebKit是什么?

WebKit是一个开源的Web浏览器引擎。
WebKit的HTML解析器和JavaScript解析器代码分别源自KDE的KHTML和KJS代码库。

2. 谁在使用WebKit?

“MacOS X系统的Safari、Dashboard、Mail和很多其他OS X程序”
这就是在说,WebKit是Safari背后的浏览器引擎。还需要补充的是,Apple在Safari里面使用了自己的Nitro JavaScript引擎(只用WebKit来渲染HTML)。

Google官方说明:Chromium使用WebKit做为渲染引擎。与其打造Chromium特有的实现方式,我们更希望去尽可能多的去为使用WebKit核心的浏览器做贡献。

这是说Chrome也在使用Nitro JS引擎?不,Chrome有他自己的V8 JavaScript引擎。简单的说,Chrome也使用WebKit,但是它也实现了自己的JavaScript处理方式。V8同时还是驱动Node.js的JavaScript引擎。

Opera会使用Chromium实现的WebKit,也会使用V8引擎。这就是说虽然Opera在宣称自己使用WebKit,但事实上它使用WebKit和Safari与其他浏览器使用的WebKit并不完全一样。如果你想客观了解现状,这是必须清楚的概念。

3. 现在WebKit究竟有多少分支?

所以我们知道现在WebKit正在驱动,或者将会驱动3个主流浏览器。但是WebKit还有多少其他类型的实现?
确实还有很多很多WebKit的变种,特别是在移动领域。他们都是WebKit的分支。

4. 这些WebKit的分支有多少差别?

有一种假设:因为这些浏览器都在使用WebKit,所以他们也会以同样的方式去支持相同的特性。
对于很多基本的特性来说,确实是这样。但是对于很多小众特性,就未必如此了。

举例来说,当Chrome开始支持游戏手柄API的时候,Safari不但还没开始支持,而且以后也不太可能支持。另一个例子是WebGL。做为在Chrome已经支持了很久的特性之一,Safari却才刚刚看到了曙光(而且还是在开发者选项里)。当然,这些还都是比较出名的例子。还有很多试验性的例子潜伏在大众的视野之下。

甚至很多基础的、日常的功能,在不同的代码分支下都有所不同。PPK完整的总结了这些WebKit的差异。

5. WebKit的逐步普及,对web开发有什么影响?

如果一个浏览器迁移到了WebKit,那是不是意味着(在编写代码的时候)可以少测试一个浏览器了?
不。每个浏览器都有它自己的怪异模式、性能差异、设计,和功能。所以每个浏览器都要测试。

当一个功能加入到WebKit的时候,是不是意味着在其他浏览器里就可以使用这功能了?
当然不是。比如游戏手柄API的例子。Paul Irish强调了这样一个事实:WebKit浏览器们可以挑选究竟把哪些API放入他们的版本。比如Chrome选择支持游戏手柄API。很多API在WebKit的层面就已经被实现了,但是WebKit项目书允许关闭这些功能。(编者注:Paul Irish是Google Chrome的员工,他曾在jQuery团队工作两年。)

如果所有的浏览器都使用相同的引擎,这对程序员来说意味着什么?
随着时间的流逝,他们会意识到尽管同是WebKit,也会有很多不同的东西。

6. 新特性如何加入到WebKit中,谁又来负责审核?

现在有许多公司正在为WebKit项目贡献自己的力量。

WebKit项目提交和审查页面提到只能有老的代码提交员和审核员才能提名新的新的代码提交员与审核员。这比较合理。然而,无论WebKit项目决定让谁参与进来,最终都还是要让Apple来做审核:
当有人被WebKit代码提交员成功提名后,Apple会处理发送代码提交员协议,在签署协议之后,Apple会继续开通SVN账户。

对于这一点并没有什么隐秘的动机,但这确实在告诉大家,WebKit和很多开源项目一样,并不是真正分散和民主的。权利是且必须是集中的——只有这样才能保证能做出决定,并且把事情做成。

7. 如何评价WebKit?

允许我们强调一下,WebKit是好的。它有开放的流程和强大的贡献者。我们只是想澄清一个当下被广泛接受的错误概念——一个WebKit等于所有WebKit,还有——如果所有浏览器都选择WebKit,那么对开发者来说,工作会变得更轻松。
我的意思是说,与众多独立的浏览器引擎会为市场带来多样性一样,WebKit在这一点来说,同样会表现的很棒。

—————

转自:http://www.infoq.com/cn/news/2013/02/webkit-history-and-now