libook 最近的时间轴更新
libook's repos on GitHub
JavaScript · 5 人关注
get_schools_from_renren
JavaScript · 4 人关注
AutoZoom
This chrome extension can automatically zoom in and scroll. Let me just see the whole area of main content.
Shell · 3 人关注
IdleBox
My shell toolkit.
JavaScript · 2 人关注
hexo-tag-real-time-calculator
A hexo plugin for inserting values which need to be calculated on real time.
JavaScript · 1 人关注
cvss-3.1-calculator
Common Vulnerability Scoring System Version 3.1 Calculator
HTML · 1 人关注
libook.github.io
libook`s home page
JavaScript · 1 人关注
pu221e
Puzzle. Hide secrets into a picture.
CSS · 0 人关注
2048
无聊洋葱
0 人关注
acronyms
Acronym dictionary for common knowledge (logic).
JavaScript · 0 人关注
blog
My blog.
JavaScript · 0 人关注
Chromium_Runner_Game
The runner game of chromium.
Rust · 0 人关注
coreutils
Core utils for UNIX/UNIX-like systems written in Rust
Python · 0 人关注
depot_tools
JavaScript · 0 人关注
esdoc-plugins
JavaScript · 0 人关注
Freshness-Server
This is a freshness timer manager for anything.
Vue · 0 人关注
Freshness-Web
This is a freshness timer manager for anything.
JavaScript · 0 人关注
ghxz-service-wxbot
JavaScript · 0 人关注
GuangheKaTaXHelper
A helper to translate text to KaTaX format for Guanghe projects.
Rust · 0 人关注
guess-numbers-rust
A guess numbers game written in Rust.
0 人关注
hexo-theme-icarus
A simple, delicate, and modern theme for the static site generator Hexo.
JavaScript · 0 人关注
hieroglyphy
Transform any javascript code to an equivalent sequence of ()[]{}!+ characters that runs in the browser!
JavaScript · 0 人关注
koa-pagination
A middleware to handle Range Pagination Headers using Range & Content-Range entity-headers.
0 人关注
libook
JavaScript · 0 人关注
mongoose-history
Keeps a history of all changes of a document.
0 人关注
music
electron跨平台音乐播放器;可搜网易云、QQ音乐、虾米音乐;支持QQ、微博、Github登录,云歌单; 支持一键导入音乐平台歌单
JavaScript · 0 人关注
pick-comments
Pick comments from source code
0 人关注
player-be
音乐湖 服务端
JavaScript · 0 人关注
proxy
Rust · 0 人关注
realworld-rust-rocket
Rust + Rocket RealWorld framework implementation
0 人关注
router
Router middleware for koa.
libook

libook

.... . ._.. ._.. ___
🏢  yangcong345.com / Full Stack Developer
V2EX 第 78834 号会员,加入于 2014-10-27 17:14:14 +08:00
今日活跃度排名 12846
不参与一切辩论、圣战,无意义。
如果你觉得我我说得好,点一下“感谢”我将荣幸至极;
如果你觉得我说的不好,仅一句嘲讽是没有人获益的;
什么?触碰到了你的信仰?那么请务必当我放屁~
正常回复 IP 被封了,求解封
反馈  •  libook  •  339 天前  •  最后回复来自 libook
3
在 WSL 中运行 GUI(如 IDEA)
分享创造  •  libook  •  338 天前  •  最后回复来自 libook
17
电子设备如何消毒?
硬件  •  libook  •  2020-04-29 23:13:30 PM  •  最后回复来自 ssqtctc
9
支付授权目录设置为第三方 URL 有哪些风险
程序员  •  libook  •  2019-03-28 17:38:30 PM  •  最后回复来自 airyland
1
自己写的实时演算插件
Hexo  •  libook  •  2019-02-18 17:26:07 PM  •  最后回复来自 libook
3
[培训向]如何给学员讲明白一种算法不合适?
程序员  •  libook  •  2019-01-31 12:24:39 PM  •  最后回复来自 libook
13
[北京] 有没有想学习 Node 服务端开发的实习生?
酷工作  •  libook  •  2018-11-21 13:18:08 PM  •  最后回复来自 defunct9
1
[北京] 有想学习 Node.js 服务端开发的实习生吗?
酷工作  •  libook  •  2018-11-16 10:18:49 AM  •  最后回复来自 wangsahala
17
今天可能要发布 Node10 的 LTS?
  •  1   
    Node.js  •  libook  •  2018-10-31 08:45:44 AM  •  最后回复来自 Acexihua
    9
    libook 最近回复了
    @mxT52CRuqR6o5 #118 是,TS 和 JS+doc 都能自动改。
    不了解具体什么需求,以前做类似的功能是在业务里判断,网关负责确定请求的人是谁,然后业务里用网关认证的身份信息来判断是否有权限。

    如果业务里涉及鉴权规则的地方也比较多,可以在业务层塞入一个鉴权层,可以把权限简单划分为公开、已登录用户、自己等类别,然后业务返回这个属于哪种鉴权类别,鉴权层再直接套用通用逻辑鉴权。
    @xd199153 #114 TS 重构的时候也是一样要改两个地方,一处类型声明、另一处代码声明,只不过这两个地方和 JS 的两个地方位置不一样而已。
    工具都是有好用和不好用之分的,VSCode 的代码分析和提示功能跟一些商业 IDE 比起来还是很弱,在 WebStorm 里,JS 即便不写 doc 做类型声明也会通过代码分析来推断类型,然后给画波浪线,提交的时候还会提示代码可能存在问题建议去修改(也可以忽略),花的钱其实也值在这里。
    无非是 TS 工具默认不忽略问题(你也可以 @ts-nocheck 忽略问题);这个对于 JS 工具来说也可以配置不忽略潜在问题,让 CI 直接失败。在这个问题上,不得不说 TS 技术栈给出的是一站式方案,包装成了现成的产品,开箱即用,而 JS 技术栈则依然十分灵活,按配置来实现需求。

    对象参数用 doc 来定义的话有多种方式,一种思路是直接在 saveUser 声明参数的时候写个对象结构声明:
    /**
    * Save a user.
    * @param {{nickname: string, age :number}} userObject
    * @returns
    */
    function saveUser(userObject) {
    return true;
    }

    另一种思路可以先声明对象类型,然后在 saveUser 声明参数的时候直接引用这个类型,同样这种方式可以给每个属性写描述:
    /**
    * @typedef {Object} User
    * @property {string} nickname
    * @property {number} age
    */

    /**
    * Save a user.
    * @param {User} userObject
    * @returns
    */
    function saveUser(userObject) {
    return true;
    }
    // 效果如此: https://imgtu.com/i/Wb9wY4


    JSDoc 和 ESDoc 是两种 doc 标准,前者主要针对原型写法,后者主要针对 class 写法(这么说也比较笼统),不过很多工具都是会同时集成两者,都可以直接用,也确实有很多人不知道有这个东西,在 TS 出现之前 JSDoc 是解决文档和辅助语法检查问题的主要方式之一。
    @kingwl #111 你的意思是说,在 TS 出现之前没有任何工具可以做到这个事情吗? VSCode 使用的方案同时是其他所有编辑器和 IDE 使用的方案吗?讨论的问题是 JSDoc 、ESDoc 能否帮助达到 TS 一样的效果,这几张图不足以说明吗?


    @xd199153 #110 仔细看我的图,用 doc 的方式除了能满足类型提示和检查以外还能加更多描述,很多时候团队协作为了写描述横竖都要写 doc,顺手写类型声明和 TS 的成本是一样的,也就只是写的位置不一样。

    我前面的回复已经说明了,代码提示和类型检查都是工具带来的,TS 离了工具也没法出提示(用纯净的 Vim 试试看),面向 JS 的相关工具也都有,精确不精确取决于工具水平怎么样,WebStorm 上的高水平工具不写 JSDoc 靠推论也能做精准的类型提示。

    工具链+语言,至少工具链方面 TS 并没有比 JS 多少优势,语言方面看你要约束还是要灵活,对于要灵活的情况来说,TS 的约束就是缺点。

    技术栈选型从来都不是选一个最好的,而是选一个最合适的,任何技术都有优点和缺点,没有完美的。
    @xd199153 #75 你这个例子不需要写 JSDoc,编辑器、IDE 能自己判断出有哪些属性或方法。https://imgtu.com/i/WH1KZF
    任何编辑器、IDE 在没有 TS 插件的时候也都做不到 TS 的提示功能,相应的 JSDoc 带来的提示功能也是由插件实现的,和 TS 一样,很多编辑器和 IDE 自带了 JSDoc 的插件,甚至在 TS 出现之前就已经存在了。

    其实更多区别还是在于类型声明上,这两张图就是个简单的对比,图一是 ESDoc 实现的,图二是 TS 实现的:
    https://imgtu.com/i/WH3Ulq
    https://imgtu.com/i/WH3Npn
    你猜怎么着,ESDoc 还能给参数加描述。

    建议看一下 JSDoc 和 ESDoc 的文档,在自己的编辑器或 IDE 上试试,花不了几分钟。

    我觉得 TS 也就那样,没必要神化,项目适合就用,不适合就不用,TS 再怎么🐂🍺也不敢脱离 ES 的基本范畴,因为它就指着 ES 生态来维持用户群;除非某一天浏览器集体支持 TS 原生引擎,但只要 TS 还是微软主导的,就基本没可能。
    以前 TS 火起来是因为比 JS 早先实现了 ES6 的语法,JS 是等 ES6 正式发布了之后才开始逐渐支持的。

    但现在 JS 已经追上 ECMA-262 的所有 proposal 了,所以私以为 TS 的优势没那么大。

    唯一比较有优势的是类型声明,然后做编译检查,但这些都是靠工具来完成的,同样靠工具也可以写 JSDoc 、ESDoc 然后用基于 doc 的代码分析工具来检查,效果差不多,我用 JetBrains 家的 IDE,在写的时候自动补全、类型提示、波浪线都很好用,体验就跟 TS 一样。

    或许从 C#转技术栈过来的会用着很舒服?都是微软家的东西,思路也会有所相似。

    任何一个技术都有好处也有坏处,有其最适合的场景,也有其不适合的场景,所以什么话都不能说死,因为除了会引战以外,过了一段时间回来看自己写的东西会很尬。

    JS 是极其灵活的语言,灵活的代价就是对开发者要求很高,没有语法约束来规避各种坑,在水平不足的时候就很容易摔倒,TS 的存在恰好是为了让 JS 没那么灵活,对于 JS 水平较高的人来说,TS 可能会影响发挥。

    但你猜怎么着,前端从来都不缺水平低下的人,对于团队协作来说,猪队友是十分致命的存在,那么 TS 的价值就出来了,能提升代码质量的同时提升开发效率。相应的 Go 火起来也是因为这个。

    所以做个人项目的话,我通常不会选择 TS,但团队合作最好是 TS 。
    2 天前
    回复了 JamesChen 创建的主题 问与答 国内有哪些原始意义上的 Hackers?
    终于有人讨论这个问题了。

    原教旨主义上来说,有这么三个概念比较容易被混淆:Hacker 、Cracker 、Script kiddie 。

    Hack 其实可以理解为钻研,特别是挑战一些无人能及的领域并有所成就,比如攻克了某技术难题。而且 Hacker 往往是有积极意义的,Hacker 的成果往往是为技术的发展做出贡献的。在计算机领域,Hacker 是对一个技术人员的最高评价。

    Crack 是破解,Cracker 就是破解者,指的是任何突破限制或封锁的人,顶级的 Cracker 往往在技术上也是有一些无人能及的成就,所以这些人既是 Cracker 又是 Hacker,更多的 Cracker 其实是做着没那么关键的、重复性的事情。Cracker 有黑帽和白帽之分,分别对应消极意义和积极意义。

    Script kiddie 就是拿着 Hacker 和 Cracker 的成果不做任何创新就直接用的人,特别是搞破坏,比如各种拿着现成破解工具来进行破解的人。

    网络安全攻防相关的其实是和 Cracker 直接相关,跟 Hacker 关系不大。

    Hack 是一种精神,Crack 是一种目的,Script kiddie 啥也不是。

    早先其实有人建议 Hacker 翻译成黑客,Cracker 翻译成骇客,Script kiddie 翻译成脚本小子,但媒体常常搞混,以至于大众以为三者都是 Hacker/黑客。

    除了计算机领域,Hacker 也可以用在其他领域,比如网上比较多的 Life Hacker 相关的内容,不得不说有一些还是很巧妙的。

    当然比较有名的还有 Geek,和 Hacker 相比,个人认为 Geek 更多是体现一个人有着极强的学习和动手能力,并且能让自己的生活与众不同。当然,Geek 和 Hacker 的交叉地带也是存在的。

    Hacker 在国外也是万中无一的,国内的 Hacker 也是存在的,在各个领域的科研先锋,比如山师的王小云,研究出了 MD5 碰撞算法。
    2 天前
    回复了 opengps 创建的主题 前端开发 后端如何学前端?不求精,求快就行
    JS 的问题其实不是奇葩,而是一方面自己不理解 JS 的一些基本原理,另一方面是 JS 是极其灵活的一门语言,特别是语法和类型上,语言不负责对开发人员的代码质量进行约束,对开发人员的水平要求很高。这个是类似于 C/C++的,不能说看不懂调不通就是语言本身的问题,比如也有人说 Java 的注解是奇葩语法,C/C++/Rust 的宏是奇葩语法,C#的委托是奇葩语法,Go 的异常处理是奇葩语法,但这些其实都是先入为主的问题。

    后端知识比较成体系以及环环相扣,而前端知识非常分散,而且例外情况很多,这其实是与各技术栈受环境因素的影响程度来决定的,比如后端程序会跑在统一可控的环境中,前端程序会跑在不统一、不可控的环境中,所以造成了这种差异。

    所以要学习前端技术,难以有速成方法,需要见多识广。

    简单给几条学习建议 ,MDN 上关于 Web 基本原理、JS 、CSS 、HTML 、BOM 、DOM 的文档都看一遍,然后就是去看 vue 、react 、angular 等框架极其相关思想的文档。
    @vindurriel #25 技术债也不是一定就要避免,或一定就要还清,这个还是得综合业务经营情况来看,有一些对于业务确实比较关键的节点甚至应该主动欠一些技术债务,来换取业务业务的保障,关键就是产品和技术双方达成一致。权责分离之后,出了问题该是哪边的责任就是哪边的责任,比如技术方已经通过正式的文档或邮件将成本和风险表达清楚了,产品经理在 ROI 低的时候一意孤行进行实施,那么最终的业务亏损要算在产品经理的头上。至于如何说服他人,这是一门学问,需要经验和技巧的。
    关于   ·   帮助文档   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   953 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 22:46 · PVG 06:46 · LAX 15:46 · JFK 18:46
    ♥ Do have faith in what you're doing.