前端部分，css是最缺乏标准的语言，不像html和js有着大量的规范标准，但是css你几乎找不到一个像他们一样的标准。
css的顶层样式表分为at-rule和qualified-rule 一个是at规则，一种是普通规则；
我们的at规则是由一个@发起，跟一个区块组成的，如果没有区块是以分号结束的；at规则是远远比普通规则少并且少用的，
所以大家可能会对at-rule比较陌生。

@charset ： https://www.w3.org/TR/css-syntax-3/
@import ：https://www.w3.org/TR/css-cascade-4/
@media ：https://www.w3.org/TR/css3-conditional/
@page ： https://www.w3.org/TR/css-page-3/
@counter-style ：https://www.w3.org/TR/css-counter-styles-3
@keyframes ：https://www.w3.org/TR/css-animations-1/
@fontface ：https://www.w3.org/TR/css-fonts-3/
@supports ：https://www.w3.org/TR/css3-conditional/
@namespace ：https://www.w3.org/TR/css-namespaces-3/

上面这么多，是已经整理好的at文档
下面我们给所有的at规则做一个解释和demo

@charset "utf-8" ---- 规定css文件的编码
@import "index.css" ---- 引入对应的css文件（除了编码都可以全部引入） ->
@import url("index.css") ->
@import [ | ]

    [ supports( [ <supports-condition> | <declaration> ] ) ]?
    <media-query-list>? ;

@media print { ---- 他能对设备做一些判断，此方法体是普通规则

body { font-size: 10pt }

}

---- @page，针对于分页媒体网页表现，除了设置页面本身自己，也可以设置周围其他盒

@page {
size: 8.5in 11in;
margin: 10%;

@top-left {

content: "Hamlet";

}
@top-right {

content: "Page " counter(page);

}
}

-- counter-style 它可以自定义列表前缀表现，具体的方法可以百度有详细的api
@counter-style triangle {
system: cyclic;
symbols: ‣;
suffix: " ";
}

@ support support --检查环境的特性，它与 media 比较类似。
@ namespace --用于跟 XML 命名空间配合的一个规则，表示内部的 CSS 选择器全都带上特定命名空间。
@ viewport --用于设置视口的一些特性，不过兼容性目前不是很好，多数时候被 html 的 meta 代替。

普通规则：由选择器和声明区块构建的；声明区块又由属性和值构建而成；
下面这张图，就能很好的解释选择器的优先级和权重问题

值得注意的是：我们在写属性的时候不要写两个--，否则会被当成css变量处理，与之配合的是var函数

:root {
--main-color: #06c;
--accent-color: #006;
}
/ The rest of the CSS file /

foo h1 {

color: var(--main-color);
}

css也支持一些计算属性：

calc() max() min() clamp() toggle() attr()

这些函数用的比较多的就是calc和max min函数，实际开发中我们可以用calc简单的计算出不同运算符加减乘除

test{

height:calc(50% - 10px)
}

ps: 这些变量我们再做运算的时候，一定要空格隔开

css的函数有很多，欢迎提出你日常中用到过的函数以及应用场景吧！

本文部分demo摘自winter老师的专栏

HTML5标签中增加了非常多的语义化标签，比如nav，footer诸如此类

但是这篇笔记，主要介绍这些语义化标签以及应用的场景

作为一个程序员，你肯定就在想，html非常的简单，是我们入门级别的语言

但是我想说：html是入门简单，精通非常难，可以完全和后端精通相媲美

因为难的指标就是：能够正确运用标签，可能会和自身的“文化”素养挂钩：

比如说：

语义类标签对开发者更为友好，使用语义类标签增强了可读性，即便是在没有的时候，开发者也能够清晰地看出网页的结构，也更为便于团队的开发和维护。除了对人类友好之外，语义类标签也十分适宜机器阅读。它的文字表现力丰富，更适合搜索引擎检索（SEO），也可以让搜索引擎爬虫更好地获取到更多有效信息，有效提升网页的搜索量，并且语义类还可以支持读屏软件，根据文章可以自动生成目录等等。

这是极客专栏上的一段话：但是我并不认为语义化标签能对开发造成良好的维护性，因为不是每一个前端工程师都精通语义化标签，这会造成累加更多的沟通成本

下面举一下比较简单的例子：ul是无序列表，ol是有序列表，可是在我们开发中，总是把一些相关性的信息列表做成ul，如果大量的使用此类代码，会对机器读码造成

肉眼开不见的压力，也会让你的代码变得更臃肿；

所以，对于语义标签，我的态度是：“用对”比“不用”好，“不用”比“用错”好。当然了，我觉得有理想的前端工程师还是应该去追求“用对”它们。

摘自极客专栏的一段话，作为一个优秀的前端工程师，不仅仅要考虑的是功能的实现，也要考虑你的标记语言是否在某个程度上是优雅的；

最后说一句话：标签语义化不是我们现在所担心的，因为它和你们的工作可能没任何关系，甚至可以继续使用div，span，都不影响，只是语义化是一个趋势，我们要改变这个风气。

koa2是express框架的原班人马打造，仅仅只有600 700行代码，可谓超轻量级做小程序，博客轻量级程序，可以不用express，koa2也是一个非常不错的选择；

首先我们来看看koa2的入门demo吧，首先安装koa2，直接npm安装即可；

const koa = require('koa')
const app = new koa()

app.use(async(ctx,next)=>{
ctx.body = '1'
//下一个中间件
next();
//上下文
ctx.body = ctx.body+ '2'
})

app.use(async(ctx,next)=>{
ctx.body = '1'
//下一个中间件
next();
//上下文
ctx.body = ctx.body+ '2'
})

app.use(async(ctx,next)=>{
ctx.body = '1'
//下一个中间件
next();
//上下文
ctx.body = ctx.body+ '2'
})

app.listen('3000')

所谓的消息中间件的概念，就是一个类似洋葱圈的样子，我们从请求编译到结束，会从外层进入内层，再从内层穿过外层，执行next方法就会进入下一个中间件，
ctx是上下文对象；

我们可以写一个定时方法，然后使用await方法来进行等待中间件执行完毕；

app.use(async(ctx,next)=>{
ctx.body = '3'
await delay()
//下一个中间件
await next();
//上下文
ctx.body = ctx.body+ '4'
})

自己实现一个koa2的打印logger

module.exports=async(ctx,next)=>{
const start = new Date().getTime();
await next()
const end = new Date().getTime();

console.log(ctx.request.url,end-start,ctx.body.length)
}

打印请求路径，和运行时间，还有上下午字符串长度

我们直接在server.js中app.use使用这个logger，也别忘记了引入；

koa2的路由的2种实现方法

app.use(async(ctx,next)=>{
ctx.body = '1'
if(ctx.request.url == 'qitiandasheng'){
ctx.body = '齐天大圣'
}else if(ctx.request.url == '/'){
ctx.body = '首页'
}else{
ctx.body = '

404

第一种是利用上下文对象的request.url来在中间件中做判断来做出对应的显示；

还有一个比较正规的方法是利用koa2-router，首先我们安装它

router.get('/sun', (ctx, next) => {
ctx.body = '1'
next()
});

app
.use(router.routes())
.use(router.allowedMethods());

koa router地址：https://github.com/alexmingoia/koa-router

当我学习es6的时候，Promise是比较新的解决回调的方案，然后今年去年就比较流行asynac来解决咯；

首先回顾一下回调地狱是怎么形成的；

function ajax(fn){

setTimeout(()=>{
console.log('你好')
},1000)

}

//callback回调地狱
ajax(()=>{
console.log("执行结束")
ajax(()=>{
ajax(()=>{
ajax(()=>{
})
})
})
console.log("执行结束")
})

这个是比较经典的callback回调地狱啦，我们如果这样书写嵌套，一些参数可能会比较恼人，而且修改也不好修改

所以第一代解决方案Promise，意思就是一个承诺，拥有2个参数，一个是接受，一个是拒绝，然后用then方法接受，相对来说比较优雅：

function delay(word){
return new Promise((reslove,reject)=>{
setTimeout(()=>{
reslove(word)
},2000)
})
}

//Promise解决方案1
delay('孙悟空')
.then((word)=>{
console.log(word)
return delay('猪八戒')
})
.then((word)=>{
console.log(word)
return delay('沙悟净')
})
.then(word=>{
console.log(word)
})

这个相对于我们原始的方式，简直是太方便了，但是直到我看到asynac，直接傻瓜式的写法，也是很6了；

//asynac和await解决方案2
async function start(){
const word1 = await delay('孙悟空')
console.log(word1)
const word2 = await delay('猪八戒')
console.log(word2)
const word3 = await delay('沙悟净')
console.log(word3)
}

我们直接这样使用，await必须要跟它搭配使用，且必须存在于一个方法体，函数必须要asynac修饰，目的就是等待执行，就完美解决了异步回调造成的代码污染的情况；

下一章的koa的中间件就是利用asynac和await来实现的哟

这阵子，一个前端的vue项目已经结束了，也自己上线了，对自己提升很大，巧逢今天和导师聊天，聊到了工作。
我们的背景就是，大专的学历和2年的学习经历，同期的2位非常好的朋友经导师推荐去朋友小厂面试；
由于这层关系，也就是需要2个”码农“,几个月整一个后端管理系统，对技术要求不高（ssm会做增删改查）；
但是据说面试了一个月的应届生和培训出来的，没找到一个合适的，没有写出一个增删改查。

当时知道这个小厂对于我的2位朋友有着磨练的机会，所以今天就去了，结果3个小时之内，做到第二个小时就委婉的
让他们走了，我个人心里觉得有这样几个原因：

1.紧张（第一次这种环境下的机试）
据我所知，这两位朋友code功底蛮深的，不谈什么高大上的分布式线程熔断乱七八糟的技术，就光增删改查玩的还是很6的）
2.轻易相信的自己
我们的学校尤其是我们班都是以实战为主，2年不知道做过多少demo和项目练习，对自己的技术过于自信，没有认真准备，
导致轻视了这个机会，我相信他们一定会引以为戒

关于这个基础重要还是高大上的技术重要呢？
其实我的客观理解就是：深入java基础很重要，高大上技术是通过第三方的渠道了解到的，比如别人，视频，工作
所以为了我们这种即将春招的应届毕业生不要追求很多新潮的技术，也不要忘记了，不要轻信任何一个demo或者练习