记录－交流－Web开发知识分享
px
px就是pixel像素的缩写，相对长度单位，网页设计常用的基本单位。像素px是相对于显示器屏幕分辨率而言的
em
em是相对长度单位。相对于当前对象内文本的字体尺寸（参考物是父元素的font-size）
如当前父元素的字体尺寸未设置，则相对于浏览器的默认字体尺寸
特点：
1. em的值并不是固定的；
2. em会继承父级元素的字体大小
rem
rem是CSS3新增的一个相对单位，rem是相对于HTML根元素的字体大小（font-size）来计算的长度单位
如果你没有设置html的字体大小，就会以浏览器默认字体大小，一般是16px
html{font-size: 62.5%} /* 10 ÷ 16 × 100% = 62.5% */
body{font-size: 1.4rem;} /* 1.4 × 10px = 14px */
/*在根元素中定义了一个基本字体大小为62.5%（也就是10px。设置这个值主要方便计算，如果没有设置，将是以“16px”为基准 ）*/
优点是，只需要设置根目录的大小就可以把整个页面的成比例的调好
rem兼容性：除了IE8及更早版本外，所有浏览器均已支持rem
em与rem的区别：…
is_user_logged_in()
说明
根据当前访问者是否登录返回布尔值true或false。
参数
该函数不接受任何参数。
用法
示例
根据当前访问者的登录情况，使用is_user_logged_in()函数在主题文件中展示不同输出结果。
…
git config --global http.sslverify false
…
在 2019 年，我想创建一个紧跟我们的定制设计并具有流畅动画和交互的网站。我看着UIkit（在新标签中打开），但我没有选择它有两个原因：
这导致我搜索其他框架，这些框架与 UIkit 不同，仅提供基本的 JavaScript 功能，允许您根据需要设置样式和动画。我什么也没找到。所以，很自然，我决定自己做（在新标签中打开）.
我正在与我正在开发的网站并行开发框架，这很棒。我能够使代码恰到好处并实现我需要的功能。我从 UIkit 中获得了一些灵感，但坚持我的主要想法。
后来发现效率不高，所以决定重构。但是因为我正在开发那个框架并同时使用它，所以我不仅要重新设计框架，还要重新设计网站。除此之外，我试图使这项工作适用于尽可能多的用例。如果你使用 React 会怎样？如果你不这样做呢？如果你使用 jQuery 会怎样？如果你连 JavaScript 都不太了解怎么办？
至此，我的热情开始慢慢消退。不知不觉中，我把自己置于一个想要解决尚不存在的问题并完美解决它们的位置。但我仍然相信，最终，它会是“值得的”。
然后，我们的团队开始壮大。我不再是唯一一个在那个网站上工作的人。因为它使用了我的框架，所以我不得不让新人使用它。这意味着我必须编写自述文件，然后是文档、示例用法等。尽管如此，我们仍然需要在 Slack 中清理一些东西。
因为我们的团队在成长，所以我们的工作量也在增加。这导致与网站并行的框架工作在周末和清晨过渡到框架工作。
不过，我继续。我有（并且到现在仍然有）放弃项目的习惯，所以我决定至少将框架简化为可以通过 npm 下载的有组织的小 JavaScript 片段。但是我是否使用自定义元素（在新标签中打开）
ffmpeg rtsp流转m3u8流
ffmpeg -rtsp_transport tcp -i "rtsp://admin:admin123@192.168.1.123:554/live/av0" -fflags flush_packets -max_delay 1 -an -flags -global_header -hls_time 1 -hls_list_size 3 -vcodec copy -s 216x384 -b 1024k -y test.m3u8
ffmpeg rtsp流转发
ffmpeg -rtsp_transport tcp -i "rtsp://admin:admin123@192.168.1.123:554/live/av0" -vcodec h264 -acodec aac -f …
随着全球软件开发人员数量的不断增加，增长热点（就开发人员而言）也在不断变化。正如我们在上一篇文章中所讨论的，2013 年大约有 1820 万软件开发人员，而这个数字只是 - 预计未来几年还会增加。
基于这些预测和从那时起最近的开发人员增长率，我们已经知道 2022 年的情况。
根据第 20 版开发者国情报告，截至 2021 年底，全球有2680 万活跃的软件开发者。 专家预测，到2030 年，开发者的数量将增长到 4500 万。这些令人印象深刻的数字证明了全球对 IT 专业人员的需求正在增长，并将继续增长。
今天来讲一讲TCP 的 TIME_WAIT 的问题。这个问题尽人皆知，不过，这次遇到的是不太一样的场景，前两天也解决了，正好写篇文章，顺便把 TIME_WAIT 的那些事都说一说。对了，这个场景，跟我开源的探活小工具 EaseProbe 有关，我先说说这个场景里的问题，然后，顺着这个场景跟大家好好说一下这个事。…
Shell作为Unix系操作系统当中最有魅力且不可或缺的组件，经过数十载的洗礼不仅没有被淘汰，而且愈加变得成熟稳健，究其原因，大概因为它是个非常稳固的粘合剂，能够把大量功能强大的组件任意配搭，总能很好很快地完成用户的任务。
本文的一些命令很可能看起来是“雕虫小技”，我们只好仰慕一下Shell大牛了，但是有些细节我会稍加发掘加以说明，遇到有趣的地方希望能博您一笑了。…
最近在测试环境部署服务的时候老是会有端口被占用情况用netstat/ss 查看后发现端口一直被占用
同另外一个ip 建立了tcp 连接，类似于这样：
ESTAB 0 0 192.168.103.169:12345 192.168.103.12:10261
当然这个问题也不是最近才遇到，之前也遇到过，不过之前都是很快这个连接就自动消失，我就可以欢快
的使用我自己喜欢的12345 端口，无奈这次一直连续好几天这个连接一直存在导致我一直无法使用这个端口。…
碰到各种奇葩的TCP相关问题，所以汇总记录一下。分析清楚这些问题的所有来龙去脉，就能帮你在TCP知识体系里建立几个坚固的抓手，让TCP知识慢慢在抓手之间生长和互通
一个黑盒程序奇怪行为的分析 listen端口上很快就全连接队列溢出了，导致整个程序不响应了
举三反一–从理论知识到实际问题的推导 服务端出现大量CLOSE_WAIT 个数正好 等于somaxconn（调整somaxconn大小后 CLOSE_WAIT 也会跟着变成一样的值）
活久见，TCP连接互串了 应用每过一段时间总是会抛出几个连接异常的错误，需要查明原因。排查后发现是TCP连接互串了，这个案例实在是很珍惜，所以记录一下。
案例：TCP传输速度案例分析（长肥网络、rt升高、delay ack的影响等）
就是要你懂TCP–最经典的TCP性能问题 Nagle和Delay ack
对ttl、identification等的运用
近期评论