20180728_ARTS_week05

Algorithm

/**
 * https://leetcode.com/problems/longest-palindromic-substring/description/
 * 
 * @param {string} s
 * @return {string}
 */

var longestPalindrome = function (s) {

    if (s === "") {
        return "";
    }

    let str = Array.from(s);
    let res = [-1, -1]; // [maxLen, index]
    str.forEach((ch, i) => {
        isPalindrom(str, i, i, res);     // a 一阶
        isPalindrom(str, i, i + 1, res); // aa 二阶
    });

    return s.substring(res[1], res[1] + res[0]);
};

function isPalindrom(str, left, right, res) {
    let cur = 0;
    while (right < str.length && left >= 0 && str[left] === str[right]) {
        cur = right - left + 1;
        if (cur > res[0]) {
            res[1] = left;
            res[0] = cur;
        }
        left--;
        right++;
    }
}

console.log(longestPalindrome("babad"))
console.log(longestPalindrome("cbbd"))

这题有点犯难，上面是 Discuss 中的一个解法，看了之后挺好理解的，要找回环字符串，就从 a 和 aa 一阶和二阶这两种形式往两边找，感觉特别巧妙。

学好算法不容易啊，手动捂脸。

Review

https://medium.freecodecamp.org/code-comments-the-good-the-bad-and-the-ugly-be9cc65fbf83

这篇文章主要讲的是代码注释相关的东西，包括老生常谈的 “Good code is self-documenting.”

题目叫做 Putting comments in code: the good, the bad, and the ugly. ，大意上，作者认为文档级的注释是 the good ，代码级的为了清晰逻辑的注释是 the bad ，而一些在代码注释里面抱怨吐槽或者发泄的就是 the ugly 。

个人觉得这样分过于粗暴了，文档级的注释如果在代码改动之后没有及时更新注释也是很容易产生误导的，而代码级的，为了说清楚业务逻辑变更或者一些难以理解的逻辑也是挺好的。

除此之外，作者也说起个好名字很重要，这点我很赞同，起名是个学问，一个好名字很容易达到 Good code is self-documenting.

Tip

分享一下 ES6 中的箭头函数。

箭头函数内会绑定上一层的 this。看一个例子：

function Person () {
    this.age = 0;    
    setInterval(function growUp () {
        // `this.age` is undefined
        // this function has declared its own scope
        // different from the Person scope
        this.age += 1;
    }, 1000)
}

一般情况下这样做是错的，因为 growUp 函数的 this 并不是 Person 的 this。

不用箭头函数，一般的解法是另外用一个变量比如 that 在函数外保存 this，或者用 bind 函数改变上下文：

// store the `this` scope in 
// a variable to reuse
function Person () {
    var that = this;
    that.age = 0;
    setInterval(function growUp () {
        that.age += 1;
    }, 1000)
}

// bind the function's `this`
function Person () {
    this.age = 0;
    setInterval(function growUp () {
        this.age += 1;
    }.bind(this), 1000)
}

有了箭头函数，就清晰多了：

function Person () {
    this.age = 0;
    setInterval(() => {
        this.age += 1;
    }, 1000)
}

Share

2018年7月25日， Mislav Marohnić 发了一条推文：

We’re finally finished removing jQuery from http://GitHub.com frontend. What did we replace it with? No framework whatsoever:
• querySelectorAll,
• fetch for ajax,
• delegated-events for event handling,
• polyfills for standard DOM stuff,
• CustomElements on the rise.

大意就是宣布 GitHub.com 前端已经完全不依赖 jQuery 了，并且没有使用其它框架，而是用的原生 API。

这也让我想起了初见 jQuery 时的激动。 第一次接触 JavaScript 是在大学的时候，当时那门课是讲 PHP 的，附带讲了一点点 JavaScript 的知识，dom 操作非常的不方便。直到一个偶然的机会，知道了有 jQuery 这个库，那时候对什么框架啊，库啊，都还是懵懵懂懂的，总觉得能叫框架或者库的东西都很牛逼。

于是自己简单了解了下 jQuery，当时就被它迷人又性感的链式调用和选择器给震撼了，然后去学校图书馆找了本《锋利的jQuery》细细研读，直到今天我依然觉得这是一本用来系统了解 jQuery 的好书。

之后的若干年，jQuery 基本上是前端标配，Twitter 开源的 Bootstrap 附带了众多 jQuery 插件，这个时候我觉得是 jQuery 的鼎盛时期。

前端这个时候也迎来了历史性的发展机会，网速越来越快，上网越来越普及，只要有网的地方，就离不开前端。这也造成前端涌入大量人力，jQuery 把这个门槛降到一个非常低的地步，通过分发 jQuery 武器，很快就可以上手前端了。

但是，移动时代 HTML5 的到来改变了 jQuery 的霸主地位，更丰富更良好的原生 API 支持，还有移动时代 jQuery Mobile 遭遇的滑铁卢，随着时代变迁，jQuery 的应用场景似乎越来越少，移动时代都是 webkit 内核，不用从 api 上各种兼容 IE 了，手机的网络和性能不如 PC，加载的库不能太大。

以及新一代 web 框架 Angular， React，Vue 的出现，jQuery 已经不完全是网站的第一选择了。

即使今天 jQuery 已经变得不那么流行，我还是建议初入门的前端 程序员 去了解了解它，包括原生 JavaScript API 以及 dom 操作，毕竟框架是会经常变的，而原始的东西是不常变的。如果一上来就学 Angular、React、Vue 而不去了解其背后的原理，那就会『知其然而不知其所以然』。

时光如白驹过隙，即使 jQuery 现在依然在支持着数以万计的网站，但它终将谢幕，而前端技术的发展史上，定将留下它浓墨重彩的一笔。

碎碎念

记录一些所思所想，写写科技与人文，写写生活状态，写写读书心得，主要是扯淡和感悟。 欢迎关注，交流。

微信公众号：程序员的诗和远方

公众号ID : MonkeyCoder-Life