Whimsical开发第一个月总结

进度

项目已经启动了一个月了,编辑器部分的整体进度在15%左右,进度不是很快,当前核心内容已经有了雏形,主要实现了一下功能:

  • 编辑器Layout
  • 事件调度
  • 历史快照
  • 画布分层
  • 属性配置联动
  • 设计了logo

演示

record-1m.2022-11-11 16_58_33.gif

一些技术选型

这里部分内容借鉴了formily的编辑器designable,属性配置联动部分的表单更是选用了formily进行驱动。

但是在事件调度和状态管理上方案有所不同

  • 状态管理:mobx
    • 使用mobx是为了降低项目维护的复杂度
    • mobx使用了严格模式,不允许直接通过赋值进行状态改变
  • 事件调度:rxjs
    • 当前使用rxjs是为了不去仔细考虑这里的设计,将重点放在整体框架上
    • 因为仅使用了rxjs中的subject,后续可能会对该部分进行重写
  • 拖拽系统使用了react-DND
    • 为了能更快速的开发,干脆对react-DND进行了汉化,当前是用到什么汉化什么,预计今年内会将文档全部汉化

这里没有详细写技术选型中的思考,如果有需要可以私信我,我可以多水一篇文章。

感想

项目启动至今,基本每天会抽1个小时左右写一点代码,从现在的心态上来看还OK,很充实。 中间有一段时间还有一些功利心作祟,想着无论如何要提交些什么,为了提交而提交, 现在就很释然了,尽力而为,心态放松后好像效率反而更高了。 总体来说,是个不错的尝试,当前除了时间比较少,还没有什么太大的瓶颈。

11月也会努力更新,期待感兴趣的同学和我交流。

项目地址:https://github.com/gaofeiyu/whimsical

我有一个Whimsical的项目启动了

I have a Whimsical project started

Whimsical[ˈwɪmzɪkl] 是异想天开的、古怪的、怪诞的意思,在我准备做这个项目之前并不认识这个单词,只是在想用什么作为项目名字的时候,想找个npm包中没有的名字,无意中碰到了这个词,而这个词意外地和我做这件事的目标和可执行性有些贴合,且为我要做的这件事的半途而废找到了一个很好的后路,就很完美。

我想做的东西是一个以低(零)代码编辑器为中心辐射出的一套工具包。面对这个时间点的低代码发展情况,这个赛道已经是一块让个人难以耕耘的盐碱地了,而我想做的不是一个低代码的整体平台,而是平台中每一块的零件,为低代码平台的整体架构进行解构,对页面编辑器、debugTools、设计稿自动解析、PRD自动解析、数据层等等方面输出针对的工具包和思路。

我做低代码相关的工作已经有较长一段时间了,在技术职场中,低代码是一个大多数人都用过,技术团队总想要,但又被团队十分嫌弃的一个课题。尤其是在重业务的团队,低代码相关的开发者在搞出惊天动地的结果之前,都是一直要被否定和挑战的。

不过这些困难和实践让我产生了更多的思考,于是我便启动这个项目,想将我的一些思考和实践,且跟现有工作不直接相关的内容提炼出来,期望能在更开放的平台学习和产出,解决一些低代码的通用问题。

对我的意义

这是一个从利己角度出发,产出利他结果的项目。

为什么是利己?

我是一个互联网某厂的码工,工作节奏快且充实,而长时间投入在业务和实操让我对技术最原始的驱动力变得懒惰和迟缓,简单讲就是生锈了。

我想通过这个项目来给自己一些强制的训练,复习以前的知识,并跟进新的知识,因此我在该项目中不会考虑兼容性的问题,会使用一些我感兴趣的技术栈和方案。

项目会尽可能以开源项目的思路进行一边学习一边建设,因为还有本职工作,原则上是有时间就多做点没时间就少做点,但不会不做,且有时也会为了我现有的工作当做试验场。

利他的结果是什么?

虽然这是以“我”为中心任性的项目,但是我仍然想要产出的内容有附加价值,在项目出现里程碑结果的时候,我也会进行一些运营,把我认为好的内容分享给社区,即使我的项目只是一个试错的炮灰。

比如该项目的第一个课题即是一个通用的低代码编辑器,这个通用的目标是可以融合任何技术栈的组件库的可拖拽低代码编辑器。因为个人当前的知识储备优先,因此第一阶段只面向web端,随着时间和阅历的推移,我会以整个大前端平台为目标进行学习和推进。

具体要做个什么东西

低代码是一个大课题,SaaS和aPaaS的低代码、流程图的低代码、页面搭建的低代码、低代码的上下游支撑,只从基本内容来看就能看出其建设成本之高往往让团队望而却步,这也是当前低代码相关建设被人主要诟病的原因,也是为什么很多大厂都在做低代码相关的付费服务。

如何将投入开发低代码的成本从逆差变成顺差,是每个相关开发团队需要解决的问题,这不免要进入鸡生蛋和蛋生鸡的扯皮循环。

那我想以我对低代码部分内容的理解,做出低代码整体建设中的零件,让相关团队在进行开发时少走一些弯路,或者可以直接使用我的部分成果为低代码的同僚们的KPI或OKR加把柴。

项目在当前主要涉及的内容包括:

主要内容

看到这里是不是觉得更加Whimsical了呢?

写在最后

我喜欢踢足球,但是不爱看球赛;我喜欢打dota,但是一个电竞选手都叫不出;我喜欢编程,但是已经很流行而我却不知道的技术和框架越来越多;我喜欢网上冲浪,但很少写文章,不知道看文章的你是不是像我一样,习惯把自己缩成一团。2022年里我接触了很多新东西,也尝试了不少,挫败感很多,但也总有新鲜的事物吸引我的注意力,而重要的是我舒展了自己,敢于去拥抱我自以为距离我很远的事物。

我想藉由这个项目,为我已经定型的脑袋敲出一些新花样,这篇文章可能短期不会有人能看到,但希望有那么一天会有人挖出这个文章来刺激一下未来的那个不争气的我,要么就不要异想天开,要么就坚持到底。

项目地址:https://github.com/gaofeiyu/whimsical

typescript路径映射踩坑

问题由来

我们通常引用一个npm模块,直接引用模块的名称就可以了,如 import module from 'module' 。
但是如果引用自己开发的模块,往往要使用相对路径的方式找到目标模块,如 import myComponent from '../../../components/myComponent' 。
这种方式可以正常开发,可以完成业务需求,但是维护起来就很难弄了,因为通过这种相对路径的方式你很难一下定位这个组件在哪里,在项目复杂的时候,可能会产生预期外的结果。

别名设置

其实这个问题的解决方案已经很成熟了,从各种构建工具及命令中都有相应的设置。
我这里只针对 typescript 做说明,因为他提供的工具集有点坑。

假如我想实现 import myComponent from '@components/myComponent' 。
而我的目录结构为

./
└── src
    ├── components
    └── views
          └── app.ts

tsconfig.json

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@components/*": ["src/components/*"]
    }
  }
}

这里的关键配置是 baseUrl 和 paths 
具体说明可以参见文档
https://www.tslang.cn/docs/handbook/module-resolution.html#virtual-directories-with-rootdirs

webpack

假设有一个 webpack.config.js 文件在 ./ 下面

resolve: {
  alias: {
      '@components': path.resolve(__dirname, './src/components'),
  }
}

这个比较基础,直接查看webpack文档就可以了
https://www.webpackjs.com/configuration/resolve/#resolve-alias

通过tsc编译会产生的问题

该文章并不是要教你怎么使用别名,而是 typescript 的开发中有个坑。

用tsc编译的后,映射的路径不会处理,将导致编译后的代码找不到模块

比如上面的 import myComponent from '@components/myComponent' ,如果你使用 commonjs 模式编译后应该是 const myComponent require('@components/myComponent') ,结果就是找不到这个模块。

解决方案一:使用webpack等构建工具进行编译

可以通过 ts-loader 等组件进行编译,来规避掉这个问题

解决方案二:使用module-alias

我现在的场景是,就想使用 tsc -w 来进行开发,那么经过一番寻找,比较优秀的方案就是 module-alias 了。
https://www.npmjs.com/package/module-alias
最简单的用法就是将 const moduleAlias = require('module-alias') 放到你的项目入口处。
然后设置你的 package.json ,以前面的结构为例。

"_moduleAliases": {
  "@components" : "./src/components"
}

这样就可以达到 tsc 编译后,仍然可以找到设置别名的路径了。
至于 module-alias 的原理是什么可以看一下他的npm模块的描述,我就不擅自翻译,免得误人子弟。 

接口文档工具横向评测

评测还在继续…

评测对象

评测维度

  • 编写方式
  • UI
  • 与仓库关联
  • 监控仓库状态
  • 导出PDF
  • markdown
  • 兼容性
  • mock
  • 接口调试
  • 开源
  • 自动化测试
  • 插件

评测方式

通过以下方式得出评测结论

  • 网站简介
  • 提交频率
  • 更新频率
  • 产品示例
  • 舆论口碑

注意:因为没有精力一一部署去测试,所以该评测在一定程度上不够客观。

评测结果

APIDOCYAPINEI
录入接口方式
注释/在线编辑在线编辑在线编辑
UI/交互二次开发自带自带
与仓库关联GIT/SVNNN
监控仓库状态YNN
导出PDFhtml,markdown,jsonPDF
markdownYNN
数据兼容性postmanpostman/swagger/json貌似不支持导入
mock根据接口示例生成支持可编程mock支持可编程mock
接口调试Y 需要是可以访问apidoc服务器的机器才可以YY
自动化测试NYN
开源YYY
插件需要自行二次开发Y
社区维护现在仅有我们自己维护持续维护还有维护

评测总结

这里仅是根据上面数据的个人总结

  • 关于录入接口的方式
  • apidoc更全面更方便,更符合开发流程
  • YApi也可以,值得一提的是YApi支持的导入方式比较多,从某个角度来说也可以通过二次开发实现其他的录入方式
  • NEI仅支持在线录入方式
  • UI/交互
  • apidoc完全就是文档管理的界面交互,因为完全是公司的开发,很多细节还有待提高
  • YApi界面也还可以,满足基本需要
  • NEI的页面交互更像是一个项目管理的交互,而不是针对接口的
  • 与代码仓库的关系
  • 除了apidoc其他的平台都没有直接和代码仓库产生联系
  • YApi可以通过插件的方式,自己开发定时任务或者自己二次开发来跟仓库产生联系
  • 导入导出
  • apidoc支持基本的pdf导出和postman及注释文件的导入,正在规划对swagger的支持
  • YApi的导入导出支持的格式比较多
  • NEI仅支持导出PDF
  • mock
  • apidoc仅支持对文档中示例的基本数据mock
  • YApi支持可编程的mock
  • NEI在mock方面支持的非常好
  • 测试
  • apidoc仅支持数据结果的查看
  • YApi支持自动化测试
  • NEI支持单个或批量的接口测试
  • 其他功能
  • apidoc支持markdown的文档输入方式,除了写接口文档,也支持添加技术文档,甚至可以用来记笔记
  • YApi提供二次开发插件的功能,可根据自己的需要自己开发功能
  • NEI仅有当前提供的功能,因为是开源也可以二次开发,但是社区对二次开发的支持度不高
  • 社区维护
  • apidoc因为是个引擎,所以并没有什么社区维护,仅是根据当前的引擎做需要的开发
  • YApi现在的社区相对活跃,官方代码提交的频率也比较高
  • NEI的社区不是很活跃,代码提交频率也不是很高了,不知道会不会后面就没人维护了

写在最后

如果诉求是对文档进行维护和管理,当前内部开发的apidoc应该是首选,潜力也比较大。
但是要是说对接口本身和接口相关的体系进行管理,从外部开源的项目来看,NEI更优秀。
YApi虽然在两个方面都没有达到最好,但因为对插件开发的支持,以及灵活性,并不输NEI。
所以,如果需求只是对接口文档的管理,建议使用apidoc,同样的投入会得到更高的效果。
但是要对接口这边做全局的管理,可以用YApi+apidoc的方式。
下面提出一个思路以供参考:

  • 从代码中的注释生成文档
  • 然后为apidoc增加一个swagger的文档输出服务
  • 再通过一个定时同步服务,将apidoc输出的swagger直接同步给YApi
  • 这样,所有接口的文档部分由apidoc管理同步给YApi,接口的测试和MOCK能力由Yapi来处理

Mac 可设置环境变量的位置、查看和添加PATH环境变量

原文地址:http://elf8848.iteye.com/blog/1582137

Mac 启动加载文件位置(可设置环境变量

——————————————————-

(1)首先要知道你使用的Mac OS X是什么样的Shell,使用命令

echo $SHELL

如果输出的是:csh或者是tcsh,那么你用的就是C Shell。

如果输出的是:bash,sh,zsh,那么你的用的可能就是Bourne Shell的一个变种。

Mac OS X 10.2之前默认的是C Shell。

Mac OS X 10.3之后默认的是Bourne Shell。

 

(2)如果是Bourne Shell。

那么你可以把你要添加的环境变量添加到你主目录下面的.profile或者.bash_profile,如果存在没有关系添加进去即可,如果没有生成一个。

 

1./etc/profile   (建议不修改这个文件 )

全局(公有)配置,不管是哪个用户,登录时都会读取该文件。

 

2./etc/bashrc    (一般在这个文件中添加系统级环境变量)

全局(公有)配置,bash shell执行时,不管是何种方式,都会读取此文件。

我在这里加入mysqlstart、mysql和mysqladmin命令的别名,保证每一个用户都可以使用这3个命令。

 

3.~/.bash_profile  (一般在这个文件中添加用户级环境变量)

(注:Linux 里面是 .bashrc 而 Mac 是 .bash_profile)

若bash shell是以login方式执行时,才会读取此文件。该文件仅仅执行一次!默认情况下,他设置一些环境变量

我在这里:设置终端配色、

我在这里:设置命令别名alias ll=’ls -la’

我在这里:设置环境变量:export PATH=/opt/local/bin:/opt/local/sbin:$PATH

 

 

MAC 修改host文件 

——————————————————-

sudo vi /etc/hosts

 

 

linux下查看和添加PATH环境变量

==============================================

 

PATH的格式为:

——————————————————-

PATH=$PATH:<PATH 1>:<PATH 2>:<PATH 3>:——:<PATH N>   ,中间用冒号隔开。

 

 

 

添加PATH环境变量:

——————————————————-

[root@localhost u-boot-sh4]#export PATH=/opt/STM/STLinux-2.3/devkit/sh4/bin:$PATH

 

 

查看PATH环境变量:

——————————————————-

[root@localhost u-boot-sh4]#echo $PATH

/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin

 

 操作示例:

——————————————————-

通过编辑 启动文件 来改PATH,

# vim /etc/profile

在文档最后,添加:

export PATH=”/opt/STM/STLinux-2.3/devkit/sh4/bin:$PATH”

保存,退出。

 

立即生效请运行:

#source /etc/profile

不报错则成功。

 

如果想立刻生效,则可执行下面的语句:

$ source .bash_profile(这是文件名)

环境变量更改后,在用户下次登陆时生效。

前端开发工程师

什么是前端开发工程师

前端开发工程师是Web前端开发工程师的简称,是近五年才真正开始受到重视的一个新兴职业。

这个岗位的职能现在还存在很多争议,尤其是在互联网技术并不发达的地区,但不管如何争执,前端工程师都需要掌握以下几个技能。

  1. HTML
  2. CSS
  3. JavaScript

而争议就在于上面三个技能水平的不同,能做的事情不尽相同,而且其他岗位,如后端开发也要了解这些技能,一些设计也需要会这三个技能,导致了前端工程师的市场出现了一阵的混乱。

而现在,我们将这些可能造成混乱的岗位,根据岗位需要又进行了细分。

 

前端开发工程师的分类

  • 美工:从设计,到页面重构全包的岗位,对上面三个技能的要求都只是熟练而已,互联网行业发达的城市几乎看不到该岗位了;
  • 页面重构师:前两年比较标准的前端工程师,精通HTML、CSS,JavaScript是熟练级别能够很好的使用一些现成的类库和框架就好。
  • 高保真原型开发师:一些公司分工非常细,这个岗位不用写JavaScript,但是Html和Css可能是专家级别的,负责将设计稿高度还原成页面。
  • H5前端开发工程师(JS方向):这个方向的工程师是JavaScript的专家,他们可以不用会写页面,但是写JS是一把好手。
  • H5前端开发工程师:没有特殊说明的H5前端开发工程师,是三项技能都达到精通的开发者,这类开发者用的前端开发技术比较新,倾向于解决移动端开发方案。
  • 移动端前端开发工程师:很多公司以H5开发工程师来招募这个岗位的人员,然而其实H5开发工程师不一定是移动端开发,所以移动端前端开发工程师是专注移动端页面开发的人员,更了解手持设备。
  • 前端架构师:专家级别的js开发工程师,负责造轮子写公司前端UI架构和脚本架构。
  • 还有与设计和动画相关的前端开发岗位在这里就不赘述了…

 

前端工程师需要掌握的知识

上面说了3个基本技能,然而这3个基本技能并非像想象的那么简单,尤其是JavaScript,现在的受欢迎程度节节攀升,重要程度也不再是以前那个只做表单验证的被开发人员们嫌弃的语言。

另外前端作为中游开发,负责接收UI设计进行生产,之后产出给后台同学页面(现在一些开发模式不用给后台同学页面了,因为前端包办了后台模板开发的任务),所以前端作为枢纽,需要庞大的知识面,什么都要了解一些才能得心应手地做前端工作。

那么该掌握什么呢?

  1. 必须熟练掌握基本的web前端技术,比如:css、js、html 等等;
  2. 掌握一个到多个流行的类库(jQuery、zepto等)和框架(Angularjs、backbone、bootstrap等);
  3. 至少掌握或了解一门后端语言(JAVA、PHP、.Net);
  4. 必须掌握网站的性能优化、SEO、UE、服务器端、兼容性、存在的bug等;
  5. 学会用工具辅助开发;
  6. 有良好的代码规范编写习惯。

下面的图形象的说明了前端开发根本就是个百晓生…

35a85edf8db1cb131db54265dd54564e93584be3

做前端很简单,做前端很难

前端这个岗位在开发人员中,无疑是最具趣味性的,这得益于所见即所得的开发本质。

任何有一点代码基础的人,甚至不太懂代码的人都可以很快的写出一个页面,并让它运行在你的浏览器里面。

然而前端开发的学习曲线却是异常地陡峭,因此造成了现在市场上该岗位人才的两极分化,也是现在市场上前端开发供不应求的根本原因。

 

最后说说HTML5

H5前端开发是个奇怪的岗位,因为很多公司招募H5前端开发,其实并不是在用HTML5。

上海这边对稍微高端些的前端开发岗位,尤其是移动端,基本都叫H5开发了。

典型的岗位需求就是你要会一点Nodejs;

要会一个或多个MVVM或MVC框架;

最好会一点Hybrid开发;

能处理手持设备的兼容问题。

 

结语

 

智能手机大爆炸时代,移动端用户大暴涨时代,所有的开发应用势必会秉承移动优先的原则,作为专注移动端开发的HTML5,无疑将是未来开发领域的佼佼者。

几年内,HMTL5已经横跨所有智能平台,让我们拭目以待前端开发工程师多彩的未来。

 

VS下面的Emmet(ZenCoding)

新工作的开发环境倾向我并不是很熟悉的VS2012,代码习惯和快捷键也进入了新的环境。

经过了一番自定义以后,发现VS2012自带的类似ZenCoding的功能并不是很完整,于是…

可以去官网下载相应扩展,VS2012是最低的支持版本。

ZenCoding的新名字是Emmet(其实也不新了);

 

官方下载Emmet

 

直接在开发环境里面安装可以依据以下步骤

工具->扩展和更新->搜索Emmet 找到以后安装即可。

 

不过VS下面的快捷键不一样~

补全是Ctrl+1

还有我最爱的块选择是Ctrl+3和Ctrl+4

当然你也可以重新自定义,有兴趣的快去试试吧。

移动端做动画的一些坑

首先让我们假设手机性能并不是很好。

1、做位移动画translate比trbl更流畅;

2、通过backface-visibility可以开启gpu性能;

3、动画期间transform的属性应该是保持一致的,不然部分手机(小米3)只会做最后定义的动作;

4、在ios6的情况下如果动画不用translate3D,内容多了切换会出现花屏(更准确说应该是translateZ);
5、安卓部分机型不支持对:before元素的动画;

display和offset的关系

事情来自于lazyload的编写,这里以图片()为例:
1.display:none的图片同样会请求;
2.另外设置了display:none元素element.offsetTop 取不到值 
而 
$(selector).offset().top取到的值等于scollerTop的值 。
因此我们在做通过滚动判断图片是否在屏幕中的时候,要考虑标签切换时图片的读取状态和加载规则。

健壮自己的代码与粗心战斗

想说的其实就是个代码容错率的问题。

最近出现了一下几个问题:

  1. cookie明明已经存好了,却无论如何取不到—— 是后端同事传cookie的时候在属性名上加了空格;
  2. 判断页面状态出现错误(不详述)—— 是用indexOf截取判断url的时候关键字过于简单(比如只判断了indexOf(“10”)),导致url被加入其他参数的时候判断目的出错;
  3. 多条件判断逻辑要清晰 —— 经常出现判断遗漏条件、默认执行条件有问题的情况;

以上的问题,思考一下,然后想一些方案来解决。

 

如何应对:

  1. getCookie的时候要对属性名清空格;
  2. 关键字尽量完整,因为这是不可预估的问题,测试环境可以方便测试使用,建议生产环境上干脆使用其他方式来达到目的;
  3. 判断要靠图来解决了,画出逻辑图,可以直观看出各个条件节点,带着图和产品确认逻辑也可以将风险外包(笑);

大学时候软件工程学习了代码的健壮性,但是每个人自律的情况不一样,再加上经验的差异,往往出现各种不可预知的问题。

最近吃了不少亏,但从大方向讲收获更多,以上分享给朋友们。