Tychlog

最近有一个客户想在AWS EC2上安装SFTP服务，其实之前已经给他设置了AWS Transfer Family服务，可以直接为S3开通SFTP服务。不过这个客户觉得太贵，所以还是想在已经存在的EC2服务器上安装SFTP服务，并且连接到S3。本来以为很简单的事情，没想到花了一天时间，还差点把服务器弄坏了。

最近上了一个新项目，这个客户管理一个庞大的任务和团队集群，而不同流程所适用的系统也不太一样，比如salesforce，hubspots之类的。这次的新项目需要在另外两个平台之间做一些事情。目前只需要先封装其中之一的API，因此我们选定使用NodeJS的框架Nest.js来实现这套API。

最近刚在JavaScript Weekly看到了Remix.run(以下简称Remix)准备开源发布1.0版本。没过两天就看到Remix飙到Github Trending趋势榜第一了。感觉是已经火了啊，不知道后续跟Next.js比怎么样。不过看起来不算太复杂，很多东西都封装起来了，语法很轻。所以准备学习一下，顺便做点学习笔记。

很多人觉得，前后端的差异主要是分别承载了数据和样式，功能和皮肤。前端就是视觉方面的，后端是实质性的。追溯到很多年前，确实是这样的，所谓的前端只是由于后端MVC中的View过于复杂，为了提升用户体验，提高加载速度，以及降低服务器压力，所衍生出的一些优化技术。

相信大多数人都有过关于CSS的痛苦经历，从我加入公司到现在，不到两年的时间里，听到最多CSS相关的讨论就是‘很难调’。所以我也一直在探究这其中有怎样的问题，为什么很多人觉得CSS很难写，如何才能让其他人更优雅的写CSS。在Code Review的时候，我渐渐的发现了问题所在，其实很多人已经掌握了丰富的CSS知识，但却不知道如何分组属性写成class。最后只好在需要改变样式的元素上随意起个名字做class然后把所有要写的属性丢进这个class里，如果优先级不够，再把前面的选择器都加上。结果就是CSS代码不断堆积，重复和冗余不断增多，维护也变得举步维艰。

前一阵子在项目组中讲了一个关于CSS的Session，在讲之前我曾收到了许多意见，大部分是希望能讲讲CSS实用性的技术，比如盒模型，CSS3之类的。干货人人都喜欢，因为看得见摸得着，拿来就有用，但我最后还是决定讲一些”湿货“。因为在Code Diff的时候我发现了许多样式的问题不是由于不会写CSS导致的，而是由于在错误的地方使用了写在错误地方的样式。

其实CSS很简单，没有计算没有流程，只是一直描述，无论什么复杂的效果，你只要Google一下就知道怎么写了，甚至可以直接copy。但CSS又很复杂，一个元素的表现会受到它旁边的兄弟元素，也会受到内部的子元素影响，还会受到父元素影响，在这种多重影响下，一个元素的显示逻辑会变得错综复杂。有没有面对塌陷的块级元素而束手无策？无论怎么改它的属性就是得不到自己想要的，但看看似乎一模一样的示例程序却安然无恙，是不是恨得咬牙切齿？我想这就是本文所要解决的主要问题，让你学会如何优雅的写CSS。

作为最流行的MVVM（Model-View-View-Model）框架之一，相信大部分前端对AngularJS都不会陌生，我也一样久仰大名。不得不说，AngularJS所带来的改变是巨大的，被称为未来浏览器的模式一点也不为过，尤其是思维上的转变。

作为一个常年挥舞着jQuery去指挥无穷无尽的DOM的前端，初次接触AngularJS是有困难的，许多先贤警告我们不要在AngularJS中使用jQuery，不是没有道理的。即使AngularJS中带有jQlite对象，也仅仅是为了弥补一些地方AngularJS的局限性。AngularJS操作UI的方式与jQuery有着极大区别，在深入学习之后，我渐渐的发现了这点。过去使用jQuery的前端就像一个操纵提线木偶的傀儡师，而手握AngularJS的前端简直是不折不扣的魔法师。前端开发者不再需要根据数据去改变DOM，然后填入数据，我们所要做的仅仅是决定数据的表现形式后等待数据的注入。文档流中的元素就像活过来了一样，根据数据表现出了对应的样子。

这一切的核心除了匪夷所思的DOM监听机制，还有就是AngularJS的模板（template）以及其中多不胜数的内置指令（directive）了。因此，我将在本文中谈谈AngularJS的模板以及其思维模式。

很久没有写博客了，一是刚入职比较忙，二是因为总有学到新的有趣的东西，停不下脚步来总结一下。最近出差到了帝都，反而能挤出些时间来写点什么了，也正好趁着出差做的这个项目讨论一下CSS理论。

我现在面对的CSS基本上就是一个三头六臂的怪物，一点不夸张，因为真的是三头六臂，同一个样式在同一个element上作用了好几遍，而同一个样式又分散在4，5个class上，优先级有很多层。可以看得出这个怪物不是一个人造就的，早期的开发者选择了SCSS技术，但混乱的import导致了一些基本的样式被多次调用，而后面的开发者又为了摆脱之前的混乱引入了其他共用样式，但无济于事。原因出在HTML上，CSS依托于HTML没有被正确的抽象，而HTML又完全的依赖业务，所有class以业务取名，HTML和CSS基本没有复用，最终抽出的共用样式也仅仅是又一次的重复。CSS重构最难的地方在于没有脚手架，即测试。虽然有一些方法来测试，比如reftest，但还不够成熟。抱着有总比没好的心态，CSS被一层又一层的覆盖了上去。

Stylus似乎并不是很有名，以至于很多人不知道它是做什么的，但提到SASS相信有不少人听说过甚至使用过很长时间。其实无论是LESS、SASS还是Stylus甚至是Absurd这些预处理工具，都是对CSS的一种延伸和强化。出现这些工具的原因很简单，CSS本身只是一种描述性质的东西，甚至它不能算是语言而是样式表，所以我们需要一个有条件语句和变量甚至是函数的东西去动态生成CSS代码来达到提高效率和增强可维护性的目的。

本文主要以Stylus语法本身和简单的使用为主要内容，它的目的是介绍和简单指南。将不会过多涉及Javascript的API调用等问题。

介绍

官方的介绍非常简短而精炼：

Expressive, dynamic, robust CSS

有人说过程序员和码农的本质区别就是程序员会不断探索提高生产力的方法。思维模式的转变是提高生产力的最好方式，但打磨我们的工具也是十分有意义的事，本文将从开发环境，自动化开发，开发工具等几个方面针对前端开发效率的提升和代码质量的提高来展开讨论。

每件事都是一个程序，开发也像程序一样，每个步骤都是一段代码，当开发规模随着文档、代码、需求而增加时，重复的步骤变得越来越多。此时，如果可以像抽象代码一样抽象出一些相同操作就可以大大提升开发效率。因此，出现了更多更优质的工具来代替人工做一些不断重复的开发以减少程序员的工作量。