声明式UI其实并不是近几年的新技术，但是近几年声明式UI框架非常的火热。单说移动端，跨平台方案有：RN、Flutter。iOS原生有：SwiftUI。android原生有：compose。可以看到声明式UI是以后的前端发展趋势。而状态管理是声明式UI框架的重要组成部分。
大报文问题，在京东物流内较少出现，但每次出现往往是大事故，甚至导致上下游多个系统故障。大报文的背后，是不同商家业务体量不同，特别是B端业务的采购及销售出库单，一些头部商家对京东系统支持业务复杂度及容量能力的要求越来越高。因此我们有必要把这个问题重视起来，从组织上根本上解决。
最近有项目需要使用js原生开发滑动组件，频繁要用到dom元素的各种属性，其中以各种类型的height和top属性居多，名字相近，含义也很容易搞混。因此特地总结归纳了一下常用的知识点，在文末我们来挑战实现一个简易的移动端Scroll组件。
采用依赖倒置原则后的分层架构和六边形架构，实际上都符合整洁架构设计理念。但是六边形架构中使用端口与适配器，让应用程序能够以一致的方式被用户、程序、自动化测试、批处理脚本所驱动，同时能够让应用程序边界更加清晰，从而能更好地防止领域层和应用层逻辑泄露到外层。
## 前言 笔者认为，一个博客网站，最核心的是阅读体验。 在开发StarBlog的过程中，最耗时的恰恰也是文章的展示部分功能。 最开始还没研究出来如何很好的使用后端渲染，所以只能先用Editor.md组件做前端渲染，过渡一下。前端渲染我是不满意的，因为性能较差，页面加载出来还会闪一下，有割裂感，影响
背景 我目前的配置是i5-8400，16G内存（两条威刚8G 2400） 然后在日常使用中，16G内存已经捉襟见肘了，无论是Android开发还是后端开发，每次编译都卡得很 正好双十一，就想着买条16G内存来扩容，组个32G的双通道。 某东看了一圈，2400的16G内存基本绝迹了，只能选择2666的
前言 最近有个项目到一段落，做个小结记录。 内容可能会多次补充，在博客上实时更新哈~ 如果是在公众号阅读这篇文章，可以点击「查看原文」访问最新版本~ 这个项目是前后端分离，后端为了快，依然用我的DjangoStarter框架。前端一开始是小程序，后面突然换成公众号H5的形式，还好我用了Taro，大差
## 前言 开发接口，是给客户端（Web前端、App）用的，前面说的RESTFul，是接口的规范，有了统一的接口风格，客户端开发人员在访问后端功能的时候能更快找到需要的接口，能写出可维护性更高的代码。 而接口的数据返回格式也是接口规范的重要一环，不然一个接口返回JSON，一个返回纯字符串，客户端对接
前言 随着团队的成长，要管理的项目或使用的内部系统越来越多，很多内部系统都没有域名，使用IP+端口，很难记。 为了解决这个痛点，我抽空写了个导航网站~ 目前用下来效果还不错，可以基本完美的解决这个问题。 项目名称是 SiteDirectory ，代码在 Github 开源了: https://git
Velocity是一个基于Java的Web页面模版引擎。十多年前，Velocity将Java代码从Web页面中分离出来，使得开发者能够并行网页开发和Java开发。随着十年前后端分离的浪潮涌动，回首再面对这些基于Velocity的旧系统，无论是后端还是前端人员维护，都会存在诸多问题
深夜档分享，给大家介绍一个黑白的、“惊悚”的网站！ 从名字来看（killed by microsoft），是不是猜到点端倪了？ 这个神奇的网站居然收录了微软寿终正寝的那些软件。这是一个免费的开放源码列表，其中列出了已停产的微软服务、产品、设备和应用程序。网站的目标是成为有关微软已死项目历史的真实信息
因为我本身没有参与过项目架构，所以为了避免后续的开发过程中项目无序，繁杂。所以在这里我要给我自己设定一个规范。 后端 目前采用的就是：Net6(长期支持)+仓储模式(类似三层架构) 虽然现在流行微服务，但我目前还没法自己完全去做，还得学啊！ 目前8的预览版已经出现，但是得申请，7的话是标准期限支持，
哈喽大家好，我是咸鱼 我相信大家在面试过程中或多或少都会被问到这样一个问题：你能解释一下什么是 socket 吗 我记得我当初的回答很是浅显：socket 也叫套接字，用来负责不同主机程序之间的网络通信连接，socket 的表现方式由四元组（ip地址：端口）组成 那么今天，咸鱼将跟大家打开 sock
一、触发器 触发器是与表有关的数据库对象，指在insert/update/delete之前或者之后，触发并执行触发器中定义的sql语句集合，触发器的这种特性可以协助应用在数据库端确保数据的完整性，日志记录，数据校验等操作。 使用别名old和new来引用触发器中发生变化的记录内容，这与其他的数据库是相
问题描述 在使用APIM提供API服务管理的场景中，遇见了客户端请求时候发送的请求Header中的Content-Type不满足后台服务器的要求，但是在客户端要求客户修改代码难度较高。 所以面对这样的情况，是否在APIM端修改为对请求的Content-Type进行覆写呢？ 问题解答 可以的。 API
部署完服务终将是为了访问，那么`kubernetes`中`service`和`ingress`都可以将集群内部的服务能够支持外部访问。`service`可以让一组 Pod（称为“后端”）为集群内的其他 Pod（称为“前端”）提供功能；`ingress`通过对集群中服务的外部访问进行管理，也可以提供负载均衡、SSL 终结和基于名称的虚拟托管。
webpack是什么 webpack是前端项目工程化的具体解决方案。 主要功能：提供了友好的前端模块化开发支持，已经代码压缩混淆（去除空格和注释，让文件体积更小），处理浏览器端JS的兼容性（将箭头函数转成低级实现，let->var实现，兼容版本低的浏览器），性能优化等。 让程序员把重心放到具体的功能
React Native特点 跨平台 使用js写出页面组件代码被React框架统一转成Virtual DOM树，Virtual DOM树是UI结构的一层抽象，可以被转换成任何支持端的UI视图。 ReactNative框架将Virtual DOM 转成原APP的UIView树。 热修复 ReactNa
一、介绍 今天突然想起之前工作上遇到的一个问题，在做Blazor 开发时后端给的一个接口请求方式是Post ，但是他需要携带多个参数，新建一个公共类又觉得麻烦，我就尝试着怎么在Post请求中携带多个参数，由于接触Asp .Net Core 的时间不够长，所以这些都不是太了解, 今天写下这篇文章做个记
为什么要使用微前端 微前端架构具备以下几个核心价值： 技术栈无关 主框架不限制接入应用的技术栈，微应用具备完全自主权 独立开发、独立部署 微应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新 增量升级在面对各种复杂场景时，我们通常很难对一个已经存在的系统做全量的技术栈升级或重构，而微前
