Category Archives: 他山石

Hello World 他山石

defineProperty

2019 年 06 月 19 日 – 上午 10:49

学习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.jiangkl.com/2019/06/js_defineproperty

Tags , | Permalink | Comment (0)
Hello World 他山石

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

2013 年 09 月 27 日 – 上午 3:39

首字母变大写：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.jiangkl.com/?p=1454&preview=true

Tags | Permalink | Comment (0)
他山石

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

2013 年 07 月 08 日 – 下午 2:48

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

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

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

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

 

 

 

Tags | Permalink | Comments (5)
业界杂谈 他山石

关于WebKit的几个问题

2013 年 02 月 17 日 – 上午 6:37

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

 

Tags , | Permalink | Comment (0)
Hello World 他山石 点点滴滴

你真的会用javascript吗？

2013 年 01 月 10 日 – 上午 7:43

偶然在csdn看到几个js的小题，考察的都是很基础的知识，拿来分享一下
1.

1
2
3
4

if (!("a" in window)) {
  var a = 1;
}
alert(a);

开始，我以为是1，后来试了下，结果是undefined，仔细看看，也对：js在执行是，会首先提取所有var的新变量，让后给其赋值undefined，并将其加入到当前的执行环境总，比如这里，程序还没执行，实际就有了window.a=undefined，所以“(“a” in window)==true”
2.

1
2
3
4
5

var a = 1;
var b = function a(x) {
  return x*x;
};
alert(a);

一直以为这种写法会报错，汗颜的是，前段时间去某家公司面试，还碰上了类似的题目，回来也没写写试试。
实际试了下，这里的alert仍然是1，这种写法，a只在function a的内部是function，但是如果在a内部调用a(x)，会递归
3.

1
2
3
4
5

function a(x) {
    return x * 2;
}
var a;
alert(a);

呵呵，有了第一个题，这个就比较简单了，function
4.

1
2
3
4
5

function b(x, y, a) {
    arguments[2] = 10;
    alert(a);
}
b(1, 2, 3);

这个也简单，arguments[2]就是a的替身，a会被修改为10
5.

1
2
3
4

function a() {
    alert(this);
}
a.call(null);

这里考察的是call的使用，正常call的参数是什么，里面的this就是什么（我也是这么理解的），但是关于call还有一条说明：如果call的参数是null或者undefined，里面的this仍然是当前执行环境，即window
————-
参考:http://bbs.csdn.net/topics/390300541

Tags | Permalink | Comments (4)

« 上一页 — 下一页 »

« 上一页 — 下一页 »