小姜哥的2018年技术总结

前言

真的很快,又到了年根,说是年根儿真的很形象,一年就像是一颗树,消耗的就剩下根儿了说明一年快结束了。

今年打算公开,有一些东西不方便写,也不会太长。

主要会分成旧工作总结,新工作介绍,新技术及我的观点,其他方向技术能力扩展。所有都是从技术视角来写的,非技术会单独总结。

2018年最大的变动是换了一份工作,发生在4月末五月初。

阅读全文 »

你可能不知道的Node.js和NPM

前言的前言

这篇文章来自内部分享,目的是让大家会用并且用好Node.js和NPM,毕竟会用和用好还有很大的距离。

另外就是让大家从每天都打交道的工具中听出来新东西。

前言

今天跟大家分享一些实用但很少有资料一次性说清楚的知识,不限于Node.js和NPM,包含一些常识性的知识,会对大家工作学习有比较大的帮助。

希望达到的目标是大家能把Node.js和NPM用好。最不济的情况是遇到问题的时候能知道往哪个方向查。

先做一个小调查。

阅读全文 »

X Y Problem

定义

提问者问了一个自认为可以解决问题的方案,而不是直接提问实际要解决的问题。这实际上浪费了提问和提供帮助双方大量的时间。

  1. 某人想做X
  2. 他不知道怎么做X,但是他觉得Y是一个可行的方案
  3. 但是他也不知道Y怎么做
  4. 他找人问Y问题怎么解决
  5. 帮助他的人觉得Y问题很奇怪
  6. 在浪费的很多时间之后帮助他的人明白他实际想解决X,而Y方案实际上又解决不了X问题

例子

  1. 小明想获取文件的扩展名
  2. 小明认为截取文件名的最后三个字符就是文件扩展名
  3. 小明不知道如何截取最后三个字符
  4. 小明问大明如何截取最后三个字符
  5. 大明告诉了小明如何截取最后三个字符
  6. 小明程序运行不正确
  7. 小明觉得大明给的方案有问题
  8. 小明又来问大明
  9. 反复沟通后大明告诉了小明扩展名可能不止是最后三个字符
  10. 大明帮助小明正确的获取到扩展名

如何避免

  1. 告诉帮助你的人实际要解决的问题
  2. 给帮助你的人足够的信息
  3. 提供你尝试失败的方案给对方

来源

来自http://xyproblem.info,有修改。

Lua学习笔记(基础入门)

简介

  1. lua是一个轻量小巧的脚本语言,编译后一百多K
  2. 用标准C编写
  3. 以源码形式发布
  4. 设计目标是为了嵌入其他程序
  5. 支持面向对象
  6. 自动内存管理
  7. 可以扩展其他软件的能力,如nginx(openresty)

环境安装

mac

1
$ brew install lua

执行

1
$ lua test.lua

基本语法

注释

单行

1
-- 单行注释

阅读全文 »

web前端应届生技术图谱

上篇回顾

上一篇写了一些注意事项。

正文

这篇文章主要帮助应届生梳理一下应该具备的技能,希望可以帮助即将毕业的朋友们。面试找工作和考试不一样,没有大纲,也不是只学好学校书本上知识就OK。主要是下面这张图,后面会有适当的文字用来解释,方便大家理解。


阅读全文 »

使用cnpmjs.org搭建私有npm源

前言

淘宝NPM 让很多技术同学过上了爽快的日子,因为访问npmjs.com有时候真的很慢很慢,真的感叹阿里的财大气粗。而且cnpm还开源了,网址为cnpm/cnpmjs.org 。很多公司使用cnpmjs.org搭建了自己的私有npm源,如美团。也包括okcoin。下面简要的写一下步骤。

正题

首先要选择版本,选择的是2.19.4,是最新的稳定版。从tag来看alpha发到alpha 15版本,beta没发,但是npm上的最新版本的tag确实beta1,这里实在没明白。

cnpmjs需要数据库支持,我们选择MariaDB,安装什么的不说,现在假设已经有一台MySQL可用。

我们选择下载源码部署,把代码clone到本地,并从tag 2.19.4创建一个分支。

阅读全文 »

从零开始搭建一个前端资源自动化构建发布系统(下)

前言

接上篇从零开始搭建一个前端资源自动化构建发布系统(下)。

上一篇写到发布,还需要提供两个功能。

查看构建日志

查看构建日志是一个在正常不过的功能,既然能查看构建日志那么之前就要记录日志,记录日志起码得有程序执行到哪步,是执行成功了还是失败了。

查看日志提供一个web页面,方便使用者查看即可。

构建结果通知

这个是重点,及时反馈给用户是很重要的,通知的方式可以是钉钉、企业微信、邮箱,无论如何让用户实时知道结果。对接方式也不会太复杂,找到对应的API发消息给他即可。

阅读全文 »

从零开始搭建一个前端资源自动化构建发布系统(中)

前言

接上篇从零开始搭建一个前端资源自动化构建发布系统(上),本来想写一个长篇,这个世界好玩儿的东西太多,前段时间在干别的,上一篇在我的草稿箱躺了很久,所以分成了多篇。

上篇说到提交代码要进行构建和发布,前提是分支或者tag格式满足条件,但是不能不分青红皂白直接构建和发布,需要做一些检查。

构建前的检测

  1. 检测当前group是否开通了发布权限,这个是为了清楚的知道哪些用户在使用,方便以后有变更能清晰的知道应该通知哪些人。

    阅读全文 »

从零开始搭建一个前端资源自动化构建发布系统(上)

前言

前端在工程化这条路上已经走了很远了。我用了约两周的时间写出了一个构建发布系统,包括研究方案和解决问题,技术的世界就是这么神奇,想想很简单,动起手来才知道有坑。技术选型当然是JavaScript,放在Node.js这个runtime上执行。

之前写了使用gitlab ci实现前端资源自动发布,本文是算是第二季,所以根本就不是从零开始,标题党了一下。

好用的发布系统应该是什么样子的。

  1. 提交代码能自动构建并且部署到测试环境。
  2. 打tag可以自动构建并将静态资源发布到CDN,技术同学把对应的入口页面或者版本号拿去发布就可以了。

好处

  1. 可以省去技术或者测试同学去干一些重复的活。提交代码不算,这个现在来看必要的。
  2. 每个版本都保留了tag。我们应该为每个版本保留一个tag,这个是不应该省的。
  3. 将权限校验转嫁给了gitlab,因为你没权限提交不了代码嘛。

    阅读全文 »