V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  libook  ›  全部回复第 212 页 / 共 247 页
回复总数  4932
1 ... 208  209  210  211  212  213  214  215  216  217 ... 247  
2019-01-31 16:37:29 +08:00
回复了 fourstring 创建的主题 JavaScript 请教一个关于 this 的问题
@no1xsyzy

其实我是没听说过“执行环境”这个术语,也不知道应该对应哪个英文名称,所以为了帮助楼主解决问题,只能根据楼主的描述进行推测:

楼主的“那么 a()执行时 this 的值应该是 getName 函数的环境对象”,显然楼主是期望 a 内部的 this 指向的是“ getName 函数的环境对象”即 object 对象,符合楼主预期的结果,输出应该是'object'字符串才对。
所以我的判断是楼主说的“执行环境”就是指的是 this 指向的对象,@fourstring 楼主可以自己解释一下这个“执行环境”究竟是想说的什么。

然后 Stack frame 应该指的是 JS 的 Call Stack 里的原理,我承认这方面我确实不懂,不过一方面我觉得楼主也未必能理解,另一方面楼主的问题在 ES 语法规范上应该就能解决,不至于挖掘到 JS 解释器的实现方式。
@Ritr 哈哈,在家里的台式机就是 WSL+Cygwin+XServer,不过 D-BUS 功能很局限,Systemd 用不了,所以我基本上就只是用它跑 Terminator 以及一些纯 CLI 软件。

@wangmeixin 顺便说一下,如果买 XPS 或 X1 之类的,推荐港行,国行平均要贵 4000 左右。毕竟是要用上几年的装备,稍微贵一些也没关系,现在基本上都可以走分期(不过信用额度确实是个坎),重要的是用得舒心。
楼主需求说得越详细,大家就能给出最合适的选择。

我来讲一下我的电脑如何选的了吧:
同样是开发,但是在两个不同阶段对开发设备要求不大一样。
第一个阶段,我是做 Node.js+Angular.js 开发,个人喜欢使用 Linux 系统,团队人少也不需要经常跑来跑去,开会也基本都是在工位上开。
主要是因为笔记本电脑在性能上的性价比比台式机查,对系统兼容感性要求高,所以决定攒一台台式机。
首先开发环境对于 CPU 和 GPU 没什么要求,当时( 2015 年)买了个 4790k 的 CPU,在那个时代属于不贵且性价比很高的 U,如果不是我想玩超频,用 4790+B97 或 H97 性能足够也能省一些钱。GPU 就先用核显,以后想玩游戏再加独显就好了(不久加了个 980TiOC ),因为 Node.js 和 Chrome 都是基于 V8 的,IDE 是基于 Java 的,这些在当时吃内存还是比较大的,所以配了 16G 内存(后来为了玩游戏又加了 16G ),搞了个 120G 的 Intel 的 SSD 先用着(日后为了玩游戏加了 PCI-E 通道的 256G SSD )。一开始是只开发用,所以装了 Arch Linux,跑起来没问题(台式机大厂硬件兼容性省心),后来有点钱了,想下班后在公司打游戏(单身狗),所以加了括号里说的那些硬件,装了 Win10+VirtualBox+Arch Linux,台式机性能不错,虚拟机里用 Linux 基本不卡,白天全屏虚拟机写代码,顺便还能在后台用 Win 开些迅雷百度网盘之类的东西传资料,晚上虚拟机直接暂停,然后开始打游戏,简直方便极了。

用了大概一年,公司团队规模上来了,自己也开始带小团队,开会的情况多了起来,而且因为人多了,也不便于在工位开会怕打扰别人,去会议室开会就体现出笔记本的好处了。我就买了笔记本,台式机拿回家专门打游戏用。
当时对 Linux 兼容比较好的基本也就是 XPS、ThinkPad X1 Carbon,而 MBP 的 Unix 环境也可以适应我的 Linux 使用习惯。
重新审视一下需求,以未来 5 年做规划的话,质量好、续航长、轻便这些都是需要考虑的点,几款电脑质量和轻便都不错,MBP 最贵,但相比之下 X1 和 XPS 的续航比 MBP 差得比较多,免息分期的话能接受,所以就入了 MBP,用到现在,之后应该至少还能用两年。优点续航确实好,白天从上班到下班一共差不多 10 个小时,满电上班没带充电器也能在下班后剩下 20%-30%的电,但就是键盘比较糟心(不过因为手腕损伤我早就换了外接分体式键盘)。

要是现在的话我并不推荐 MBP,因为键盘问题依然没什么改观,其他品牌在便携性、性能、续航也都有不少提升,所以可以按照自己的需求点进行一下对比再选择。

如果想用 Linux 系统的话可以参考一下 Ubuntu 的这个认证列表,可以保证对 Linux 兼容最好。https://certification.ubuntu.com/desktop/
确认关系之前还是普通朋友的时候,就经常送女神一些可以带回家给加人分享的东西,比如家里特产食品,然后她家里人觉得好吃,就会问她关于我的一些事情。后台确认关系,也有多次委托女票送东西,她家人自然地就开始对我有些了解了。
双方已经对彼此有一些了解了,而且恰好双方都是务实的人,所以正式见面的时候压力也没有很大,有压力也是跟见面本身相关的,礼物方面心里就比较踏实,买了些在自己经济范围内觉得好的酒、食品,就过去了。
可能我比较幸运吧,到了家里对方其实对礼物并不是很关心,主要想了解我这个人怎么样。
一切挺顺利。

个人的心得是,通过女票作为桥梁,让双方在见面前对对方就能有一定的了解,可以让见面过程的可控性更高;见家人和面试是一样的,对方都希望了解到你最真实的样子(包括你的经济能力究竟如何),礼物不在壕,在于用心。

当然,不同人三观不同,不同人对女婿的要求也是不一样的,上面大多都只适用于我个人的情况,不过可以参考一下。
过程挺有趣的。

Google Play Store 上有个 Servers Ultimate,打折的时候入了,推荐给楼主,有些好想法可以更方便实现。
https://play.google.com/store/apps/details?id=com.icecoldapps.serversultimate&hl=zh
2019-01-31 13:03:09 +08:00
回复了 mortonnex 创建的主题 问与答 饮料推荐
很多饮料不能替代水,说一下自己了解到的情况吧:
自己曾经试过用牛奶来替代水,结果贵还不说,越喝越渴。。。
同事用碳酸饮料代替过水,结果肾结石,大夫说确实是碳酸饮料的锅,本来偶尔喝没啥问题,长期大量喝使得结石风险上升。据说肾结石疼得要命。

所以可能水基础上加点味道是一个比较靠谱的方向。

加糖(包括蜂蜜之类的)容易热量过多,加盐可能会加重心脏负担。
目前比较推荐茶,不用加多,稍微有点味道就行,不过要注意加强牙齿卫生,避免牙齿上出现茶渍和牙斑。
2019-01-31 12:24:39 +08:00
回复了 libook 创建的主题 程序员 [培训向]如何给学员讲明白一种算法不合适?
@cppgohan 感谢分享。

split 确实凑巧在处理 null 和 undefined 上面提供了一些便利。
返回的话也确实存在两种情况表现不一致的问题,要么就全返回原数组,修改也在原数组上修改,要么就全返回新数组,只要统一一种模式并在文档中写明就好多了。
入参检测是要注意,也相对比较容易讲明白。

@no1xsyzy 我其实就是跟他说让他去看 map😂。你举的反例一针见血。
2019-01-31 11:23:49 +08:00
回复了 libook 创建的主题 程序员 [培训向]如何给学员讲明白一种算法不合适?
@Vegetable 恩,之前想到了算法复杂度的问题,可读性这块确实是值得注意的。
2019-01-31 11:18:20 +08:00
回复了 libook 创建的主题 程序员 [培训向]如何给学员讲明白一种算法不合适?
@sherryqueen 你说的问题确实存在,输入没有做必要的校验,以及对于数组中元素的类型是否需要分类处理。
2019-01-31 11:13:13 +08:00
回复了 libook 创建的主题 程序员 [培训向]如何给学员讲明白一种算法不合适?
@Allianzcortex 好主意,这种算法会限制输入的数组当中任何一个元素转换成字符串后都不得出现逗号。
2019-01-31 10:52:34 +08:00
回复了 fourstring 创建的主题 JavaScript 请教一个关于 this 的问题
“每个函数执行时都会创建一个自己的执行环境”的前提是使用 new 指令来执行函数。

function a(){this.n=1;console.log(this.n);}

你直接执行 a()的时候,此时没有一个新的对象创建,this 默认指向全局作用域,就像你直接 var x=1 然后发现 x 变成了 global ( window )的属性,是一样的。
你执行 new a()的时候,依照 new 指令的原理,会创建一个新对象(类似于调用 Object.create(a.prototype)),然后再让 this 指向这个创建出来的对象,此时这个对象就是你所说的“自己的执行环境”。

为了方便理解,我上面说得比较浅显,具体你可以去网上搜一下 new 指令的功能,这个是原型和原型链的思想。
2019-01-31 10:20:19 +08:00
回复了 tg1108 创建的主题 Node.js 有没有啥 node.js 的异步编程模式优化的方法
先将 What 和 Why,再将 How。

需求背景(痛点)是什么?
接着上面的“碰撞”理论来说,你这个点子虽然新奇,但还是没解决撞库的问题,如果这种算法使用的人多了,那以后撞库的时候也完全可以撞算法,相比之下,不用统一的算法、变量来生成密码既简单又能彻底免疫撞库的情况,何乐不为。
Node.js 官方有 crypto module,基本上就是字符串转 Buffer,然后加密和散列,很方便,可以直接用。

https://nodejs.org/api/crypto.html

密码验证的原理根本上是碰撞,即你输入的密码(最终处理成的数据),和设置的密码(最终处理成的数据)一致,则认为验证通过。所以“可逆”并不是一个必须条件,除非你有其他的用途需要加密后的密文还能直接还原成原文。

因为加密算法是要在原有数据上“加”密,所以加密后的密文的大小一定是大于等于原文的,你也可以使用压缩算法,比如你加密后的密文是 0-9、a-f,36 进制,然后你可以把它映射成 0-9、a-f、A-F、~!@#$%^&*()_+`-={}[]:;"'<,>.?/|\这些,94 进制,这样你的密文可以无损缩短长度,由于无损压缩,所以可以完美还原,但也还是有限的,如果你的原文中有不可控长度的变量,比如网站域名,有 t.cn 这种的,也有 http://www.thisisthelongesteuropeandomainnameallovertheworldandnowitismine.eu/ 这样的,由于这种不可控性使得最终加密出来的密文的长度也是不可控的。
点子不错,不过会不会不同网站对密码格式的限制条件不同呢?
比如有的网站必须包含数字、字母小写、字母大写,但不支持符号;
有的网站要求必须包含数字、字母小写、字母大写、符号;
有的网站要求符号必须多于 3 个;
有的网站要求同一个字符在密码中不能出现超过 4 次……

这样你的算法要根据不同网站对密码格式的要求切换不同模式。
2019-01-30 12:11:48 +08:00
回复了 Cheez 创建的主题 问与答 请教各位 V 友, 1 万元该怎么理财?
鉴于理财产品通常都不是随用随取,所以建议银行卡里留几万现金,以便应急。

看你理财的目的,百万以下基本就不用考虑通过理财来赚钱了,保值顺便贴补一点通勤费用或餐费什么的会比较现实,可以考虑各大投资平台的“稳健”投资项目,一般年化利率超过 4%且过去时间比较稳定的就很好了。

钱多了又不需要攒钱买房之类的,可以划分出一定比例的资产用作风险高一些的投资,推荐不超过 30%。

理财有风险,投资需谨慎,特别是不要看见点红利就把所有财产都投了,以及不要在一棵树上吊死,多个平台均匀着投,出了风险也不至于直接破产。
2019-01-30 10:55:27 +08:00
回复了 TomVista 创建的主题 JavaScript js 0 1 负数和 Boolean 值的转换
看是否存在用 Array.prototype.includes,Array.prototype.indexOf 适用于真的想知道找到的东西的 index 的时候用。
相应的,想找一下数组中有没有一个值,如果有就取出来,用 Array.prototype.find

在 MDN 上刷一刷 Array 都有哪些方法,会发现 JS 好贴心,好多功能都有现成的了。。。
2019-01-29 16:24:47 +08:00
回复了 kulove 创建的主题 职场话题 因为安全问题和同事产生了冲突,真是多管闲事。
已 Block 那位键盘侠。。。

私以为权利和义务是分开的,发现问题即时通知相关负责人员,尽了应尽的义务,这是值得鼓励的的事情。
对方负责人有决定是否处理的自由,不越俎代庖,以示尊重。
一方面仁至义尽即可,另一方面明哲保身。

但如果自己和公司利益绑定,如果对方选择不处理,还是找对方领导推进一下事情的解决吧,总比出险了自己跟着遭殃要好。
还记得曾经全球第一大的赛门铁克 CA,因为签发不合规的信息安全问题导致一年内直接死翘翘。
2019-01-29 16:01:18 +08:00
回复了 foxyier 创建的主题 JavaScript 请教一下 jsfuck 代码如何解密
这个应该是 JS 版的 Brainfuck 解释器?

我还以为是这个:
https://github.com/alcuadrado/hieroglyphy
这个可以把任何数字或字符串转换成 Brianfuck 风格的 JS 原生代码。
2019-01-29 15:53:41 +08:00
回复了 cstome 创建的主题 JavaScript ES 中要用 await,上一层的函数都要是 async 的?
因为 A 必须依赖 B 执行完才可以继续执行,同时 B 也依赖 C 执行完才能继续执行,所以不管你用 callback 还是 Promise 还是 async,都逃不掉三者都做同步化处理:

callback 版本:

function A(resultFromB) {
let someData = resultFromB;
return someResult;
}

function B(resultFromC, cb) {
let someData = resultFromC;

//Some logic code
cb(someResult);
}

function C(cb) {
(new Promise()).then((result) => {
cb(result, A);
});
}

C(B);

Promise 版本:

function A(resultFromA) {
let someData = resultFromA;

return someData;
}

function B(resutlFromC) {
let someData = resutlFromC;

//Some logic code
return someResult;
}

function C() {
return new Promise();
}

C.then(B).then(A).then((resultFromA) => {
//Do something.
});

避免不了的,但是外层层都用 async 不是因为内层用了 async,而是因为外层关心内层执行完的结果,如果不关心的话完全可以不用 async。

function B() {
new Promise();
}

function A() {
B();//我不关心 B 执行完返回啥,就让他自生自灭吧
//继续执行其他的代码
}

A();
1 ... 208  209  210  211  212  213  214  215  216  217 ... 247  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1846 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 59ms · UTC 16:37 · PVG 00:37 · LAX 09:37 · JFK 12:37
Developed with CodeLauncher
♥ Do have faith in what you're doing.