Loading...

事情起因是周五例行阅读阮一峰的《科技爱好者周刊》第 277 期,其中有一部分介绍 Apple 使用 iPhone15 Pro Max 拍摄宣传视频的文章。

本来这种事情苹果不是第一次做,依稀记得 iPhone 7 plus 第一次上双摄像头时,苹果也拍了类似的宣传视屏,只不过当时舔的人居多,而且本来就一个广告,大部分人也没太多较真其使用的专业设备中,iPhone 反而是最便宜的。

但这次,阮一峰在自己的文章中又拿 Apple 这件事鞭尸,感觉 Apple 这种作秀方式已经引起了大家的反感。

早期大家都认为 Apple 是创新标杆,它做的一定是未来。但随着这两年 Apple 的创新不足,加上国内手机厂商的崛起,人们看待 Apple 的滤镜逐渐消失,渐渐地发现 Apple 现在也只是一个普通公司了。

十几年前,没人会认为 Nokia 的手机业务会没落,就跟二十年前没人认为 Motorola 会没落一样,本质上就是创新不足,被颠覆性的事物给取代了。

继续阅读

研究这个事情的起因是产品的一个需求,要求对远程的接口抓包进行实时展示。一般做法都是通过 tcpdump 进行抓包,然后使用 Wireshark 进行可视化展示,但是产品要求是要“实时”,也就不能通过生成 pcap 文件下载让用户手动打开 Wireshark 的方式了。

1. 技术选型

接到这个需求后,我们就开始了技术选型。主要就两个方向,一个是前端做数据展示,另一个是通过调用 Wireshark 做数据展示。

前端实现的话,单单靠 JavaScript 是没法达到要求的,首先没有现成的 pcap 解析库,从头开始造轮子太耗时间,而且 JavaScript 的性能瓶颈在那,首先就排除了 JavaScript 实现的可能。

虽然 JavaScript 可能达不到性能要求,但是现代浏览器已经支持 WebAssembly (简称 WASM ),可以使用别的语言实现最消耗性能的部分。经过一番搜索,找到了一个开源的工具库: @goodtools/wiregasm ,一个将 Wireshark 的包分析器编译成 WASM 的库,NICE!

继续阅读

Axios 的“拦截器”想必大家都已经熟练使用了,通过“拦截器”,我们对发送请求前的 config 进行修改,对得到响应的结果进行处理,具体使用场景我今天不做讨论,单纯讨论下 Axios 拦截器实现请求重发的问题。 因为在我们公司中,页面请求使用的是我开发的一个请求库,其中也有类似于“拦截器”的接口,我称之为“中间件”(对,就是 NodeJS 框架中常说的中间件),使用的洋葱模型,实现请求重发相当简单。 但又一次,有人问我:Axios 的拦截器不能实现请求重发么?唉,问得好。先说结论,肯定是可以,但又不是完全可以,下面我们来详细说说。

1. 拦截器实现

因为我们的场景是请求重发,所以我们应该针对“非正常响应”进行响应拦截,根据响应状态码进行判断。流程图如下:

下面是代码示意:

继续阅读

虽然之前写的评论系统也有楼中楼的实现,但是因为账户并不是对接的第三方网站,用户评论还需要手动添加邮箱用户名什么的,也无法验证是否真实。 最关键的是,我还要注意 XSS 漏洞,写个博客还要花精力在 Web 安全上面,有点不值得。 所以想想,还是使用第三方的评论系统吧。市面上看了看,感觉就 giscus 的风格跟我现在的博客风格类似,那就决定是你了。

1. 什么是 giscus?

giscus 由 GitHub Discussions 驱动的评论系统,详细介绍大家看官网就行,我使用它的原因主要就下面两个:

开源免费。这个很重要? 使用 Github Discussion 作为存储后端,无需自行建立存储。

2. 配置 giscus

继续阅读

一般在用 OpenSSH 服务器的系统上进行 ssh 免密登录时,我们只需要在本地生成密钥对,将私钥留在本地,将公钥上传到目标服务器上的 .ssh/authorized_keys 就可以了。 然而 OpenWrt 上的 ssh 服务器却用的 Dropbear ,它是一种在较低内存和处理器资源的嵌入式系统中替代 OpenSSH 的软件,因此使用起来用诸多的不同。

1. 免密登录到 OpenWrt

如果本地是用 ssh-keygen 生成的密钥对,那么只需要将公钥上传到路由器的 /etc/dropbear/authorized_keys 中就行了:

cat ~/.ssh/id_rsa.pub | ssh root@192.168.1.1 'cat >> /etc/dropbear/authorized_keys'

2. 从 OpenWrt 登录到其他机器

继续阅读

原文地址: https://blog.tinned-software.net/change-ssh-port-in-centos-with-selinux/

Since version 4 of CentOS, SELinux is providing an additional layer of security to the Linux distribution. CentOS describes it like this: “Security-Enhanced Linux (SELinux) is a mandatory access control (MAC) security mechanism implemented in the kernel.” In other words, it controls with rules what a user or process is allowed to do.

从 CentOS 4 开始,SELinux 针对 Linux 发行版提供了一个额外的安全层。CentOS 描述其为:Security-Enhanced Linux(SELinux)是一种在内核中实现的强制访问控制(MAC)安全机制。换句话说,它通过规则控制用户或进程能都被允许做什么。

In my experience, keeping SSH on the default port 22 is a bad idea, as you will notice a lot of login attempts shortly after your server goes online. One of the actions (of course not the only one) to secure the server is to just change this port.

根据我的经验,让 SSH 服务使用默认的 22 端口是一个糟糕的主意,因为在你的服务器上线后不久你就会注意到非常多的尝试登录的记录。其中一种保护服务器安全的方式就是更换默认的 22 端口(当然你不止这一种方式)。

继续阅读

这道题曾经是谷歌的一道面试题,因为太过于经典,以至于谷歌取消了这道面试题。。。

1. 题目描述

给你 k 枚相同的鸡蛋,并可以使用一栋从第 1 层到第 n 层共有 n 层楼的建筑。

已知存在楼层 f ,满足 0 <= f <= n ,任何从 高于 f 的楼层落下的鸡蛋都会碎,从 f 楼层或比它低的楼层落下的鸡蛋都不会破。

每次操作,你可以取一枚没有碎的鸡蛋并把它从任一楼层 x 扔下(满足 1 <= x <= n)。如果鸡蛋碎了,你就不能再次使用它。如果某枚鸡蛋扔下后没有摔碎,则可以在之后的操作中 重复使用 这枚鸡蛋。

继续阅读

页面作为一种特殊的GUI软件,在前端工程中,很少提到自动化测试,业内也基本没有相对成熟的方案。 究其原因,主要是产品迭代速度实在太快,导致测试脚本无法跟上UI的快速变化,再加上人力原因,导致页面基本不做自动化测试。 虽然在产品快速迭代期,自动化测试无法落地,但是一旦进入稳定期,引入自动化测试还是能帮助较少开发成本。

1. 什么是测试?

测试其实就是在已经开发完成的软件之上采用人工或非人工的方式验证软件是否符合预期,是否会造成损失等潜在问题的一种方式。

多数情况下,前端代码都是研发手工自测,或是提测后由QA人员手工测试。

手工测试当然也是没有问题的,但是通过自动化的测试工具,可以更加快速高效且准确定位问题所在。

继续阅读

平时工作生活中基本都会接触到各种代理,nginx反向代理、v2ray正向代理,还有openwrt中FQ常说的透明代理。至于这三者有什么区别,下面逐一进行简单的介绍。

1. 正向代理(Forward Proxy)

首先,无特殊说明的情况下,正向代理 一般就是我们平时说的 代理。

正向代理服务器位于客户端与服务端之间,用于转发客户端请求,因此客户端需要做特殊配置。

继续阅读

作为一个博客爱好者,我是很喜欢RSS/Atom Feed的方式,可以很方便的订阅别人的博客、新闻等内容,经常浏览别人的博客,发现RSS Feed Reader都会显示一个添加订阅的图标,挺方便的。 但是作为一个前端开发,自己的博客居然没有RSS/Atom订阅,不能忍,果断花2小时加上再说。

1. 什么是RSS/Atom

引用维基百科的解释:

RSS (英文全称: RDF Site Summary 或 Really Simple Syndication),中文译作 简易资讯聚合 ,也称 聚合内容 ,是一种 消息来源 格式规范,用以聚合多个网站更新的內容并自动通知网站订阅者。使用RSS后,网站订阅者便无需再手动查看网站是否有新的內容,同时 RSS 可將多个网站更新的內容进行整合,以摘要的形式呈现,有助于订阅者快速获取重要信息,并选择性地点阅查看。 Atom 是一对彼此相关的标准。Atom供稿格式(Atom Syndication Format)是用于 网站消息来源 ,基于 XML 的文档格式;而Atom出版协定(Atom Publishing Protocol,简称AtomPub或APP)是用于新增及修改网络资源,基于 HTTP 的协议。 它借鉴了各种版本 RSS 的使用经验,被许多的聚合工具广泛使用在发布和使用上。Atom供稿格式设计作为RSS的替代品;而Atom出版协定用来取代现有的多种发布方式(如Blogger API和LiveJournal XML-RPC Client/Server Protocol)。 Google 提供的多种服务正在使用Atom。Google Data API(GData)亦基于Atom。

简单来说,就是RSS/Atom提供了一种统一的数据格式规范,网站可以将内容通过这种规范进行编码生成,订阅者通过RSS/Atom阅读器解析这些数据,就能实现在不打开网站的情况下实现网站内容的阅读。

继续阅读
  • 上一页
  • 1
  • 2
  • 3
  • 4
  • 5
  • ...
  • 14
  • 下一页