Press "Enter" to skip to content

刘建文 | Nakeman.cn Posts

Featured

2020年终总结(上)——综述

年终总结记录人成长和发展的历史,而,人有肉体和思想,只有思想的进展,我们才算有进步,才有历史可言。

而人的思想分为「能力」和「态度」两个方面,能力创造价值,态度调配价值。只有将创造出来的价值「合理调配」,才能成为是一身心健康的人。我们一直以追求着这个目标,找到能力和态度合理的调配点,成为健康的人。

我是个“不健康”的人

在2019以前,我一直被认为是一个“不健康”的人(包括我自己都这样认为,至少是个非主流),主要原因,对照上面的历史哲学的结论,我的社会生产能力没有达到一个合理的水平[注]上,创造的社会价值很小;态度方面,我自知问题所在,态度还是不错的,但由于生产能力不足,无价值可调配,从主流价值上看,综合起来,我依然是一个“不健康”的人。提高实际生产能力水平,迫在眉睫。

注:什么叫合理的水平,和合理的调配点,依然需要进一步分析,例如我不是没有能力,只是我的实际社会生产力和我的年纪不相匹配,个中有很复杂的个人,生物,和社会原因。

Featured

有效评估JS开发者软实力的十条面试题

为了顺利的再进职场,最近一个月来都在做有目的训练,训练自己的实操能力(因为这是我的一个弱项——前端项目经验薄弱,加上在特长上,编码和分析更倾向后者),而不是任意的自由的学习。然而,在具体的学习主题上,除了参考和对比常规面试题,找出一些基础主题外,对什么是“最有价值”的学习主题,我没有指引。

其实我一真很相信自己的直觉,但是难免有盲区,和价值冲突,我不清楚明天面对面的考官他希望我具备什么能力。我的担心不是没有原因的,因为软件开发技术岗位向来都是既难招亦难找,企业不知道怎么考核应聘者实力,求职者不知道学什么最重要。

这里边有一个推理,在面试和通过面试的情景里,假设把企业,和求职者分两类:

  • 企业 分为懂得评估技术岗位(C1),和缺乏评估技术的企业(C2)
  • 求职者分为有实力但不懂求职技巧的(P1),实力很弱但是刷题是高手(P2)

那么会出现四种面试情况:C1P1 C1P2 C2P1 C2P2

如果假设成立,那么通过面试的只有 C1P1 和C2P2,但是真正算成功面试只有C1P1,因为只有这种结合才是良性的。

Featured

JS开发者进阶的十项技能

有一种引人思索的事实,就是在职的开发者不必全知全会,就可入岗;这个事实存在合理性的前提是:

  • 第一,不完全掌握只影响效率(时效低,产品质量差),不代表无能;没有,你可以现学;不够不好,你可再改善;
  • 第二,软件工程复杂度超出单个人;
  • 第三,团队互补;

所以更实际的情景是,你的专业技能越来越完满(通过有效的学习),从团队的一个角色跃进到另一个角色。

作为一名JS入门者,如何进阶,从一个次要的角色转变为更有价值的角色,对他们来说非常重要。我以为  Ben McCormick的《Ten Things A Serious JavaScript Developer Should Learn》作了一个尝试,尝试列出了JS进阶的技能清单,我觉得很有趣,于是略译出来。

passport.js 本地策略 与 express app 集成步骤

web app 用户认证功能模块,是一个高级用户交互功能模块,也是很基础的功能模块。因为大部分web应用 有用户特定的私密的交互会话。

用户认证功能 ,从名字就可推知,它是在用户数据模块基础之上的应用。

本文记录了使用 passport.js 作为 开发用户认证功能模块任务 的工具,省下了一功夫,也将 用户认证功能模块 的处理逻辑 标准化。也为日后使用其他认证方式提供了扩展(例如 使用微信,微博等社区授权登录)。

关系数据库到MongoDB 迁移指南

本文摘译自MongoDB官方迁移白皮书《RDBMS to MongoDB Migration Guide》。

传统关系数据库被替代

关系数据库作为企业数据管理系统的技术基础已经有四十年了。但是,我们今天构建和运行应用程序的方式,加上新数据源和用户负载的持续增长,正在 将关系数据库推向超出其极限。这会抑制业务敏捷性,限制可扩展性,并使预算紧张,迫使越来越多的组织迁移到替代方案。

迁移的根本是数据模型的设计

从关系数据库迁移到MongoDB过程中最根本的变化是「数据建模」的方式的改变。

与任何数据建模练习一样,每个用例都是不同的,但是对于大多数Schema迁移项目,有一些一般的考虑事项。

K.O.《算法导论》——寻找算法真正入门路径

算法 对编程专业 很重要大家都认可,但怎么个重要法?算法好难学,怎么入门?这些问题则是对大家来说更为有意义的一个问题。

很多人,和专家都推荐《算法导论》这本书,有点捧为经书的意味。我读了一下以后,我觉得,名不符实。叫导论实有误导的嫌疑,更不能算入门书。我个人认为此书有以下一特点(不足):

  • 第一,数学内容过多;
  • 第二,行文不友好,中文翻译生硬;
  • 第三,深入方向不对,也不浅出;
  • 第四,内容组织不合理,不符合由基础到应用的认知自然规律;

好书应该行文流畅,深入浅出,这两条此书都不合格。就深入浅出而言,浅出是绝没有的,深入的话,深入到哪里去?数学内容这么多,可是算法的核心是数学(数学证明)吗?这一本书由几位从事计算机科学教学研究的应用数学家编著的,不是算法专业(也没有这个专业)的专家,也不是教育家,阅读体验可想而知。(以上只是个人初步的分析,或许有偏颇)

如何写年终总结

写年终总结已经成了我一年一度的功课,自2008年起已经写了12年,但即使听起来很有写总结的经验,但对于写年终总结,我依然有一些困惑。主要有两个困惑,第一,要不要写,值不值得写,这个问题在今年年终我特别忙的时刻反思了好久;第二个问题是,有没有写作的技术。

要不要写年终总结

其实第一个的问题,我默认的答案是肯定的,所以我在12月第一天就提醒自己注意分配时间,因每年写总结都是收获巨大的,无一例外,但是我最近时间很紧张让我产生了犹豫,我需要更多确切的证据来说服自己写总结。

现在我已经把今年的年终整理下来了,我的新理据是,如果一年里「发散性探索」太多,不作一次综合性总结,那这些探索有可能白费。因为人会淡忘,下一年有下一年的任务,上下文切换成本很高,回看一下两年三年的年终总结和对应的研究碎片就会有体会(这里揭示了写总结的策略或技术,就是写什么,多久总结一次,后面小结)。这种自学经历有大量发散性思考的话,都需要有一次总结,不然自学不完整。一句话,收获过去,并以此为基础开展新的未来,总结是我们成长的成果,也是美好未来的基石。无论多忙,总结还是要抽时间写。

webpack与项目构建再认识

webpack 这个工具在前端社区异常的流行,以至于我在一年前就简单的研究过(看这里 ,和这里 ),当时发现webpack在无意中提出了「Web模块」的概念——任何web app组成都可以是模块(JS模块是一种),对其进行依赖跟踪,当在发布时可解释最新依赖后打包出最新版本。「Web模块」的概念确让人耳目一新,不过由于一直没有参加具体商业项目,对 Wepback 没有多少经验,也谈不上有太深刻的认识(包括本质和意义)。

最近正在着手做一些实验项目,开始触及项目构建。读了《Setting up an ES6 Project Using Babel and webpack》,发现 webpack 的目标就是 给现代JS项目开发引入 构建 一步( introduce a build step into your process),这个观点我觉得很关键,和深刻。

webpack 与 现代web项目开发流程

最初的JS项目开发是比较简单的,纯手工,开发和构建(编译)混在一起。但显然,当项目规模增大,手工需要转向自动化。 然而,什么东西需要自动化呢?这个问题针对JS项目(Web程序结构很复杂),初学者具有异常的困难。所以学习使用 wepback 一开始是不容易的。

首先明白一点,编译(将一种码转为另一种码)只是构建的一步,模块打包也是一步而已,而自动化构建的具体任务(WHAT)和过程顺序(ORDER),根据项目性质的不同,工作流(WORKFLOW)不同会有不同。例如,项目使用了不同CSS架构方法,那「CSS样式开发」的流程就会不同。

编程模式新解

我们爱有经验,尤其是丰富经验,包括生活经验,和工作经验。因为经验能扫除阴暗、未知和危险,能给人安全和幸福。然,什么是经验?丰富经验如何获得?最近的学习发现,原来 我们开发者社区常讨论的 「模式」 就是工作经验的一种表现。掌握某种作业模式,就是获得了某种经验。「经验」的元知识,转向了「模式」的元知识。

那什么是模式呢?我们可以从一些常见的「模式观」来看看当下的通识。

在开发者社区最流行的「模式讨论」莫过于 设计模式了。但是其实 设计模式 只是编程模式(编程经验)的一种,不代表所有。而且我发现设计模式的常识理解不够准确。这里,我们先从设计模式的一般定义开始,再经 代码模式,语用模式 等特例,尝试总结一下,什么是模式,从而了解获得编程经验的可能捷径。

如何选择TypeScript 或是 JavaScript?

JavaScript的基础打得够扎实了,开始关注 TypeScript。在读到一些对比文章和图书导论后,我的第一直觉是,TypeScript和JavaScript的关系就像,OOP和FP,CSS 里 flexbox和NP的关系相似,它们不是互相吃掉谁的关系,是完成同一种任务的两种特别设计的工具。也就是说,TypeScript不是替代JS,而是用来开发不适宜使用JS开发的项目。这里理解的关键是,编程语言作为一个工具(一种比 编程范式更高级别的工具)是可以如何被设计的,就像编程范式的两种不同设计思想,产生OOP和FP编程。

编程语言作为一种工具,它有一个类型系统(typing)的属性,这个属性影响你以何种方式编程(编程算法的分析和表达),这个工具属性影响你编写程序(任务)的效率和效果,包括设计,分析,开发和维护等任务。

我觉得这篇文章(《TypeScript vs JavaScript: A Fight for the Web》)比较精简,略译出来。

前端开发者的专业任务涵盖什么内容?

工程就是由专业分工不同的工程师协作完成的,每个专业都有自己的专业技能要求,和专职任务。那,我们平时常说的前端开发者,他的专业技能是什么呢?又负责怎么样的专业任务呢?这个问题非常重要,它对求职者准确定位自己的学习目标,和面试官准确锁定合格候选人都有重大意义。

源起

写作前文《不参加工作获得“三年经验”的一些策略》的契机,是我花了很长时间为前端开发打下基础,结果却被一个“缺乏项目经验”拒于门外后,反思如何获得所谓经验,并且开始发现那两本书很有参考价值,故作一分析和推荐。不过,那两本书虽然很薄,消化读通并不容易(后续会写文章介绍)。而,更关键的问题,那两本书的内容在丰富我们的开发经验上起到怎样的作用,这还要进行一步的分析和归纳。

关于面试官想要的“经验”,我在前一文给出一个初步的定义,还给出一些没法参加工作情况下获得与“三年经验”相当能力提升的策略[em]。然则,前一文其实还没有探讨完毕,例如 面试官想要什么样的经验,什么叫三年经验,经验可以用时间来衡量吗?

其实面试官要求所谓“丰富经验”是指,你作为专业开发者,能完成甚至最好高效高质量的完成自己的专业任务,只是由技术岗的困难而出现种刁难求职者的现象。所以,核心问题还是说,辨清前端开发者的专业任务,和完成它的专业技能。在有了这个前提之下,我们才有评估“丰富经验”的可能性。