效率回归,工具库之美「GitHub 热点速览」

刚开源就变成新星的 igl,不仅获得了 2k+ star,也能提高你开发游戏的效率,摆平一切和图形有关的问题。如果这个没有那么惊艳的话,还有 The-Art-of-Linear-Algebra,重燃了我学习线性代数的自信心;htmx 则是一个被称为“后端工程师的前端库”,可以让人安心用 HTML 搞定页面,同样的 Web 应用技术还能用到的有 reflex,这个老牌的 Python 工具,常做 Web 开发的人一定不陌生。

【manim动画教程】-- 坐标系

没有引入坐标系之前,在绘制图形时,也有一个隐含的坐标系,它和屏幕的像素相关。 比如,我们之前示例中的各个图形,屏幕的中心就是坐标原点([0, 0]), 横轴坐标的范围大概是 [-3.5, 3.5],纵轴的坐标范围大概是 [-4, 4],这个范围与设置的视频分辨率有关,分辨率设置的越高的话,坐标范围越

React报错之Function components cannot have string refs

总览 当我们在一个函数组件中使用一个字符串作为ref时,会产生"Function components cannot have string refs"错误。为了解决该错误,使用useRef()钩子来得到一个可变的ref对象,这样你就可以在组件中作为ref使用。 这里有个示例用来展示错误是如何发生的

React报错之Too many re-renders

总览 产生"Too many re-renders. React limits the number of renders to prevent an infinite loop"错误有多方面的原因: 在一个组件的渲染方法中调用一个设置状态的函数。 立即调用一个事件处理器,而不是传递一个函数。 有一

React报错之Element type is invalid

总览 产生"Element type is invalid -- expected a string (for built-in components) or a class/function (for composite components) but got"错误有多个原因: 在导入组件时,将默

React报错之React.Children.only expected to receive single React element child

总览 当我们把多个子元素传递给一个只期望有一个React子元素的组件时,会产生"React.Children.only expected to receive single React element child"错误。为了解决该错误,将所有元素包装在一个React片段或一个封闭div中。 这里有个

Solution -「LOJ #3310」丁香之路

首先有两个前置技巧:1) 两点间的最短距离就是直接连接两点的边的长度;2) 遍历一个子图的最小花费是最小生成树的边权之和乘二。原问题让我们找出一条最短且必经过钦定边的 \(( s, i )\) 路径,那么我们先将 \(\lang s , i \rang\) 连上,问题就变成了找出一条最短且必经过钦定

Cesium渲染模块之概述

渲染是前端可视化的核心,本文描述Cesium的渲染模块概述

Cesium渲染模块之Buffer

渲染是前端可视化的核心,本文描述Cesium渲染模块的Buffer

Cesium渲染模块之VAO

渲染是前端可视化的核心,本文描述Cesium渲染模块的VAO

Cesium渲染模块之Shader

渲染是前端可视化的核心,本文描述Cesium渲染模块的Shader

Cesium渲染模块之Texture

渲染是前端可视化的核心,本文描述Cesium渲染模块的Texture

Cesium渲染模块之FBO与RBO

渲染是前端可视化的核心,本文描述Cesium渲染模块的FBO

Cesium渲染模块之Command

渲染是前端可视化的核心,本文描述Cesium渲染模块的Command

从零做软件开发项目系列之一——综论软件开发项目

介绍了软件项目从申请到开发实施到结项的整个过程,在这个过程中,根据项目或公司的大小,会有不同的职位参与,如果是小的公司,可能一人兼任了很多职位,很多过程也会简化或省略。一般大一些公司,人员多,职位会设置的比较全,流程也会多一些。

从零做软件开发项目系列之二——需求调研

在接到软件开发任务之后,第一件要做的事情就是进行需求调研工作,基于前期的沟通以及合同向用户了解具体需求,从而有针对性地开展后续工作。整个调研过程分为调研准备,调研实施,需求分析。

软件设计模式系列之一——设计模式概述

软件设计模式就是在进行软件开发的过程中,需要遵循的一些套路,这些套路经过了实践的检验,针对不同的设计场景,采用不同的设计模式,可以很好的解决相应的问题。

软件设计模式系列之二———抽象工厂模式

抽象工厂模式是一种创建型设计模式,它提供了一种创建一组相关或相互依赖对象的方式,而无需指定它们的具体类。该模式以一组抽象接口为核心,包括抽象工厂接口和一组抽象产品接口,每个具体工厂类负责创建特定产品家族,保证这些产品之间的兼容性。客户端代码通过与抽象工厂和抽象产品接口交互,可以轻松地切换不同工厂来创建不同系列的产品。

软件设计模式系列之四——简单工厂模式

简单工厂模式(Simple Factory Pattern)是一种创建型设计模式,用于对象的创建,它属于工厂模式的一种。简单工厂模式的主要目标是封装对象的创建过程,使客户端代码与具体类的实例化解耦,从而提高代码的可维护性和可扩展性。

软件设计模式系列之五——建造者模式

建造者模式是一种对象创建型设计模式,它将一个复杂对象的构建过程与其表示分离。这意味着你可以使用相同的构建过程来创建不同类型的对象,而不必关心每个对象的内部细节。