为什么需要深入研究GeoServer GeoServer是一个开源的、流行的、Java实现的可发布和共享地理信息数据的软件服务器，是WMS、WCS、WFS的标准实现，含WMTS GeoServer功能强大，但是我可能只会用到其中的一两个部分，比如坐标转换与WMTS服务。可以通过研究将其进行提取和重组，形成符合我要求的，更加精简方便的软件服务器 GIS后端开发绕不过去的知识点 如何进行研究 开发环境搭建 通过WMTS请求链接到源码 通过源码进行研究学习 … 未完待续…

前言 此为深入理解计算机系统（csapp）第一章的笔记，也算是一个开始了。 Hello程序 #include <studio.h> int main() { printf("hello world\n"); return 0; } 基本思想 系统中所有的信息——包括磁盘文件、内存中的程序、内存中存放的用户数据以及网络上传输的数据，都是由一串比特（bit）表示的。区分不同数据对象的唯一方法是我们读到这些数据对象时的上下文。比如，在不同的上下文中，一个同样的字节序列可能表示一个整数、浮点数、字符串或者机器指令。 要点 源程序实际上就是一个由0和1组成的位（或称为比特：bit）序列，8个位为一组，称为字节（byte）。 大部分的现代计算机系统都使用ASCII标准来表示文本字符，这种方式实际上就是用一个唯一的单字节大小的整数值来表示每个字符 hello.c程序是以字节序列的方式存储在文件中。每个字节都有一个整数值，对应于某些字符（注意：每个文本行都是以一个看不见的换行符“/n”来结束的） 只由ASCII字符构成的文件称为文本文件，所有其他文件都称为二进制文件 编译系统（compilation system）：编译的四个阶段 gcc -o hello hello.c hello.c（文本） —> 预处理器[cpp] —> hello.i（文本） —> 编译器[ccl] —> hello.s（文本） —> 汇编器[as] —> hello.o（二进制） —> 链接器[ld] —> hello（二进制） 预处理：预处理器处理#开头的命令，修改原始的C程序 编译：编译器将hello.i翻译为hello.s，即将源文件翻译为汇编语言。汇编语言是非常有用的，因为它为不同高级语言的不同编译器提供了通用的输出语言。例如，C编译器和Fortran编译器产生的输出文件用的都是一样的汇编语言 汇编：汇编器将hello.s翻译为机器语言指令，把这些指令打包成一种叫做可重定位目标程序（relocation object program）的格式，并将结果保存在目标文件hello.o中。hello.o是一个二进制文件（即将汇编内容翻译为机器语言指令，并将这些指令打包成一种叫做可重定位目标程序的格式） 链接：链接器用于处理合并。比如在hello程序中调用了printf函数，它是每个C编译器都提供的标准C库中的一个函数。printf函数存在于一个名为printf.o的单独的预编译好了的目标文件中，而这个文件必须以某种方式合并到hello.o程序中。链接器就负责处理这种合并。最终得到hello文件，它是一个可执行目标文件（或简称为可执行文件），可以被加载到内存中，由系统执行 shell是一个命令行解释器，它输出一个提示符，等待输入一个命令行，然后执行这个命令。如果该命令行的单词不是一个内置的命令，那么shell就会u假设这是一个可执行文件的名字，它将加载并运行这个文件。 系统的硬件组成 CPU：中央处理单元； ALU：算术/逻辑单元； PC：程序计数器； USB：通用串行总线 总线 贯穿整个系统的是一组电子管道，称做总线，它携带信息字节并负责在各个部件间传递。硬件之间进行信息交流需要有一个统一的标准，也就是二进制信息传递规则，为了高效考虑，通常总线被设计成传送定长的字节块，也就是字（word）。字中的字节数（即字长）是一个基本的系统参数，在各个系统中的情况都不尽相同。现在的大多数机器字长要么是4个字节（32位），要么是8个字节（64位）。 I/O设备 输入 / 输出（I/O）设备是系统与外部世界的联系通道。每个 I/O 设备都通过一个控制器或适配器与 I/O 总线相连。控制器与适配器之间的区别主要在于它们的封装方式。控制器是 I/O 设备本身或者系统的主印制电路板（通常称为主板）上的芯片组。而适配器则是一块插在主板插槽上的卡。无论如何，它们的功能都是在 I/O 总线和 I/O 设备之间传递信息。...

前言 I have a dream too! 开源技术赋予我们站在巨人的肩膀上做到更高更强的可能，我想通过开源技术来构建一个地理信息的世界（such as: one personal cloud gis），愿给地理信息数据带来更多的使用价值。当前主要关注空间数据库、数据处理与应用以及数据渲染，由内到外，逐步构建。既然都说人类活动所接触、产生的信息80%以上都与地理空间位置有关，那么这些空间数据就应该很容易的被使用，而不是仅被围困在专业领域内，不是吗？ Fuyi Atlas（拂衣志），取自 《侠客行》、Cloud Atlas以及Discovery Atlas。愿自己也能行此间小事，而非蹉跎岁月。 Fuyi Atlas Website将会使用Hugo + Github Pages进行构建，本文用于记录Fuyi Atlas的初始构建过程。 HUGO是什么 Hugo is one of the most popular open-source static site generators. With its amazing speed and flexibility, Hugo makes building websites fun again. Hugo是一个使用GO语言编写的，开源的，静态站点生成器。 也就是说，你可以使用Hugo来快速构建你自己的静态站点。比如个人博客、知识库、产品介绍、文档等等。 我此前使用vuepress来构建我的个人站点，接触Hugo之后，更愿意使用Hugo。那么我将使用Hugo代替vuepress来构建我的个人站点。理由有那么几个： Hugo是一个纯粹的生成器 Hugo没有过多的生态依赖 Hugo更轻 据说更快，其LiveReload可以实现近实时的内容刷新 挺多可选的开源主题 使用更加简单 我也不是很喜欢node_modules Fuyi Atlas Site Build Hugo Install Hugo is available in two editions: standard and extended....

前言 拖延症真的存在！！！ 今天是2023年2月13日晚，我在此时写下本文的第二行内容。其实从年前就开始计划写一篇关于2022年的年终总结，无奈受到拖延病毒的威胁，一直拖到现在才暂时摆脱控制。 如题，本文将对2022年进行简要总结，同时对2023年做一个初步的展望（仅作记录）。 2022年大事记 第一个在外过的春节 受新冠疫情影响，2022年的春节是在杭州过的。还记得当时附近好几个地方都被划为了高风险，对整个区进行了管控。如果选择回家的话，得到将是14天的隔离，还不确定能否回来上班。因此便没有回去了。 好在所在的区域情况并没有那么的严重，还是可以去买菜的。领了消费券，再加上公司发的年货，也没有想象中的那么糟糕。 拂衣天气 集地理信息与天气预报为一体的天气预报类小程序，界面精美，使用便捷。【致敬：和风天气】 2022年，是我工作的第四个年头。受多方面的信息影响，我也想看看验证自己是否有进入全栈开发的能力。该项目从2022年1月12号正式启动，于2022年3月19日发布一阶段最终版本（1.1.9），总体耗时2个月零7天。从内容完整度以及界面友好程度来说，我给自己70分。 其实最开始是想基于webview来实现更多的地图方面的特性的，但webview对个人认证不开放。 在完成之后，本来计划是将拂衣天气完整的开发过程通过文章的方式记录下来，并将该项目开源出去，甚至还想将该项目提交给和风天气。但最后的结果就是：文章就完整了四篇，也就是一个开头，没啥实际内容。 那么原因是什么呢？经过深深的反思过后，主要的原因有那么几点： 拂衣天气的实现太乱了，本想借着文章梳理重构之后再开源 同阶段想要做的事情太多了 拖延症后期患者 对，都是借口，就是懒 WebGIS项目开发 我是2021年5月份进入的现在的这家公司，任职岗位是GIS开发工程师，主要负责服务端GIS内容的实现。从入职后到今年年初，一直在做一个小程序，算是公司的一个实验性产品，和已有产品的实际关联不大。 从3月份开始，将基于既有的产品实现，结合新项目的特性以及通用性要求，实现产品的升级。这对我来说，也算是一个重要的时间节点。因为自此我算是真正进入了WebGIS开发领域，以服务端开发为切入点。 项目部署工作 大概是22年的7-8月份，上面提到的WebGIS项目实现将作为基线产品的一部分，为后续的项目应用提供支持。而后面我将会同时负责WebGIS服务端的项目部署工作。 截至到2023年初，我已经经历了很多个项目。思来想去，我觉得这对我来说也是一个有意义的时间节点。从项目应用开发到基线产品，再到基线产品项目应用部署。一方面也算是证明了当初选择的路线，同时也更加坚定。另一方面，在疫情时代，公司能有项目那应该是好事，虽然我大抵是不喜欢做部署工作。 公司年会 对，这也是另一个重要的时间节点。2022年12月4号晚，发布了《杭州市关于优化调整疫情防控相关措施的通告》。2023年1月13日下午，公司举办了年会。这么结合起来看，是不是看起来明年会更好！ 今年其实发生了挺多的事情，自己在心态上也发生了一定的变化（主要指工作方面）。从3月的充满希望，到年底的身心俱疲。正好借年会的氛围想了想，我觉得可以换一种心态开启2023年。当初选择来这里，也就是因为自己的路线规划与公司的技术发展方向是基本一致的，到今天公司并没有发生较大的变化。那么既然是自己想要做的，那么就更应该去做好，主动去做，你是在借助公司的资源实现自我的目标，你甚至可以尝试去干预以符合你的目标。未来的岳父大人也给我说：有的时候，不要计较那么多，即使辛苦一点也没关系，但是你要清楚你在做什么。 做了再多，不如做好一个，这就是你最好的名片。——自我PUA 2023展望 技术 围绕地理信息，更加深入底层实现。以空间数据库为核心，以数据处理与使用为重点，以数据渲染为次重点，由内到外，逐步构建技术体系。 写作 2022年的成果惨淡，整整一年只有仅仅四篇文章，还都是拂衣天气的内容。 希望从2023年开始，可以实现一周双更，单更是底线。同时还要能够提高文字表达的能力。 生活 可以一夜暴富吗？ 后记 第一次更新：2023年2月13日晚，完成前言编写 第二次更新：2023年2月18日下午，完稿

前言 本文用于说明本次开发所使用的环境，以及环境的搭建过程。 操作系统 Windows 10 专业版 其实我当时使用的操作系统的Arch Linux，开发完成后才又重装回Windows。 现在又用回了Fedora 38 Workstation @time 2023.10.07 服务端 服务端使用Java语言进行开发，项目构建使用Maven(Gradle)，开发工具使用Idea，服务发布使用Docker，下面是具体的版本： JDK: OpenJDK 11 Gradle: 7.3.2 Maven: Idea: IntelliJ IDEA 2022.1.3 (Community Edition) Docker: Linx Docker Desktop Version 4.23.0 (120376) [Engine: 24.0.6] 小程序 首先需要自行完成小程序的注册，具体可以参考官方文档。 其次，下载并安装小程序开发工具，参见下载页面。 最后，调试基础库选择：2.24.6 参考 开发者工具中无法显示echart或显示异常 在MobaXterm进入ssh终端后，键入上下左右出现乱码 win10上修改docker的镜像文件存储位置 WSL2 迁移 Docker 镜像存储位置 说明 如有冒犯，我在这里先向您道歉，还请联系我进行处理 email: thread_zhou@126.com

前言 这是一个前后端分离的项目，后端使用Java进行开发，而前端通过微信小程序实现。 功能结构 可从上图得知，部分功能已去除： 消息 消息推送 紧急情况推送 用户 个人中心 模型设计 用户信息（UserInfo） id Long 主键 oid String OpenID uid String UnionID name String 昵称 phone_num String 手机号 avatar String 头像地址 authState String 登录状态 Silence 静默登录（目前程序的访问是需要存在登录态的） Authorized 已授权 createTime Timestamp 记录创建时间 updateTime Timestamp 记录更新时间 行政区划信息（DistrictInfo） 使用全国行政区划信息填充，含空间数据，数据粒度到区县。目前仅支持国内数据。 id Long 主键 name String 行政区名称 grade Integer 行政区级别 1：省级行政区 2：地级行政区 3：县级行政区 4：乡镇级行政区 code String 行政区代码 centerPoint Point 行政区中心点（空间数据） bounds Geometry 行政区边界（空间数据） 关注城市（FollowCity） id Long 主键 userId Long 用户ID districtId Long 行政区划ID districtName String 行政区划名称 districtCode String 行政区划编码 orderNum Integer 序号，自然数，从1开始 createTime Timestamp 记录创建时间 天气信息 由于天气数据均来自第三方，目前数据格式于和风天气对齐。...

前言 俗话说：磨刀不误砍柴工。 我想做一个天气类别的小程序，以此进行全栈开发能力的试炼。我想这会是一个微信小程序、是一个可以正常使用的小程序，以Java进行服务端开发，以Mapbox实现天气数据可视化。 但是我是一个后端开发工程师，我不怎么会写页面，我特别的讨厌写CSS。我也没有接触过微信小程序开发，也仅仅知道过Mapbox可以实现好看的地图。所以我需要进行一定的预研，避免后期花费更大的精力用来调整本可以避免的问题。 下面是我计划实现的功能列表： 利用网络接口获取数据（昨日天气、当前天气、预报天气） 实现实时天气与预报数据查看 紧急情况推送 利用地图（mapbox）进行数据可视化 天气分享（图片分享，页面分享） 常用地址 消息推送 个人信息 登录授权 应用Promise进行异步网络请求 使用阿里巴巴矢量图标库作为图标数据源 echarts图标展示 接入疫情数据？ 预研对象 天气数据 天气数据需要是真实的、可用的。那么可以通过网络中提供的天气API进行获取。 通过一定的检索后，我选定了两个天气平台，分别是：和风天气、心知天气。 高德天气：大平台，但是目前服务类目比较少 彩云天气：免费接口几乎没有，收费又太贵 心知天气 心知天气试用版与开发者版开发产品几乎等同，且开发者版收费也不贵。最为关键的是，支持以经纬度方式进行天气查询。 和风天气 几乎可以免费使用其提供的所有 API，且同样支持经纬度方式进行天气查询。 小结 对比了这两者，发现至少都需要注册为开发者之后，才可以较好的使用其服务。且两者的开发者认证均需要实名。 关于天气API的选择，我最终选择了和风天气，倒不是因为它可以免费使用。其实，刚开始的时候我更倾向于使用心知天气，因为它还可以直接查昨天的天气（和风对于历史天气的查询比较麻烦）。但是和风天气首页结合了地图进行可视化，而且还提供有APP可以使用（方便参考）。再加上，我想了想，其实我并没有迫切的需要知道昨天的天气情况。 其实最重要的原因在于：我先注册了心知天气（需要审核），过了半天后再去注册了和风天气（需要审核），但是最先通过审核的是和风天气（耗时大概也就半天左右，我是在春节期间注册的）。 前端技术 我并没有想要精通前端技术，但是我需要比较体系的了解一下前端技术，方便进行小程序开发。所以我在B站找了两门前端视频学习（粗略的刷了一遍）： 【尚硅谷】Web前端零基础入门HTML5+CSS3基础教程丨初学者从入门到精通 千锋web前端开发项目教程_1000集完全零基础入门HTML5+CSS3+JS到精通 微信小程序 官方文档足以 Mapbox 这里存在一个遗憾，小程序原生并不支持使用如mapbox这样的第三方地图框架，初始想法是通过webview的方式使用mapbox，但是遗憾的是，webview并不对个人类型的小程序开放使用。 所以，退而求其次，选择腾讯地图（及其提供的样式）实现地图浏览。 UI UI部分参考和风天气APP，以及WEUI 总结 天气API使用和风天气（若有空余可考虑抽取一套统一的API，可组合或切换数据来源） 地图使用腾讯地图（微信小程序解决方案，主要在于个性化样式的使用） 基于自定义服务端实现天气代理以及小程序静默登录 UI参考和风天气APP实现 参考 最好的6个免费天气 API 接口对比测评 心知天气-价格方案 和风天气-FAQ H5+Javascript技术结构图 腾讯位置服务-微信小程序解决方案-个性化地图样式 说明 如有冒犯，我在这里先向您道歉，还请联系我进行处理 email: thread_zhou@126.com

前言 天气小程序产生于2022年年初，目的是用于验证自己是否有进入全栈开发（仅前后端）的能力。该项目从2022年1月12号正式启动，于2022年3月19日发布一阶段最终版本（1.1.9），总体耗时2个月零7天。从内容完整度以及界面友好程度来说，我给自己70分。 完成内容 和风天气API接入，可实现实时天气、实时空气、24小时天气预报、7天天气预报 使用echarts for wechat进行24小时天气预报展示 通过腾讯位置服务提供的微信小程序解决方案实现地图个性化展示（目前使用风格：白浅） 通过自建服务实现小程序静默登录 通过自建服务实现关注城市的持久化管理 实现天气分享功能，通过生成一张图片进行分享，可直接分享给朋友或群组 默认通过定位获取所在位置的天气数据 天气数据均通过服务端代理进行获取，从而避免相关key直接暴露在客户端 提供通过经纬度查询所处行政区划的服务，提供行政区划查询服务，皆可获取对应行政区划中心点基于边界数据，数据坐标为4326 服务通过github action自动化进行docker构建，并推送到阿里云镜像服务仓库，而后在阿里云ecs中直接拉取docker进行部署 图片服务则是通过nginx实现反向代理，图片由docker容器内服务创建，通过docker文件映射功能映射到云主机，再通过nginx可实现图片的访问 服务与图片均实现域名访问，且均提供ssl证书 不足 未实现天气地图可视化，即基于mapbox进行地图可视化（webview需要企业认证资质） 未提供坐标转换功能，因目前使用的是腾讯地图（gcj02，即从地图获取的数据均为gcj02），行政区划数据为4326（wgs84），目前是直接将4326作为gcj02进行使用（因为数据的粒度为区县，所以差异不会很大，除非在行政区边界处可能会出现行政区显示错误问题） 未完整实现小程序朋友圈分享功能，因该功能需要所分享页面的数据可直接获取，且分享页面小程序登录功能已被限制，所以目前无法直接提供数据获取服务（需要进行登录态校验，考虑到被攻击的可能） 未完成天气预警数据接入与提示功能 未完成数据推送、个人主页、图层管理功能 分享图片中未实现天气云图叠加功能，仅获取了所在位置范围的影像图与相关注记 服务端代码封装度不够，且DDD的认知不足，导致实践乱七八糟 内容 我计划将拂衣天气开发的完整过程通过文章的方式记录下来，下面是我对该整体内容的编写计划： Name Key Words Summary 序章 前期调研 模型设计 开发环境准备 行政区划数据准备 小程序静默登陆实现 小程序开发（一） 说明主页布局构建，组件拆分情况，实现地图加载以及定位 小程序开发（二） 实现上下滑动功能开发，以及左右滑动组件封装 小程序开发（三） 实时天气栏卡片、文字描述、底部7天天气预报以及Footer部分开发 小程序开发（四） 完成echarts组件封装 天气代理服务开发 提供实时天气、实时空气质量、24小时天气预报、7天天气预报代理服务开发 小程序开发（五） 完成天气部分API对接 行政区划服务开发 提供行政区划查询服务 关注城市服务开发 提供对城市的关注与取消关注能力 小程序开发（六） 完成天气图片分享功能 小程序开发（七） 完成城市选择页面开发与数据API对接 Github Action服务发布 小程序服务发布 终篇 参考 注：拂衣天气小程序的界面设计与交互设计主要参考和风天气APP。当前所述拂衣天气小程序的开发主要用于学习。 致敬和风天气！ 和风天气 和风天气开发平台

1. 为什么 Java 需要运行时环境 1.1. Java 程序的启动方式 IDE中启动，比如：Eclipse、IntelliJ IDEA 构建为 jar，通过命令行的方式启动，比如：java -jar application.jar 使用构建工具（如：Gradle、Maven）启动，比如 SpringBoot 应用启动：gradle bootRun、mvn spring-boot:run 1.2. JRE 是什么 在这里引用极客时间课程Java核心技术面试精讲中的一段话 我们日常会接触到 JRE（Java Runtime Environment） 或者 JDK（Java Development Kit）。JRE，也就是 Java 运行时环境，仅包含运行 Java 程序的必须组件，包括 Java 虚拟机以及 Java 核心类库等。而 JDK 可以看作是 JRE 的一个超集，提供了更多工具，比如编译器、各种诊断工具等。 1.3. 为什么需要运行时环境 不是有这么一句话么，计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决。话说回来，Java 代码运行之所以需要运行时环境，主要是由于以下几个方面的原因： Java 语言语法非常复杂，抽象程度高，直接在硬件上运行这种复杂的程序并不现实（并不是不可以，但是这样造成与相应硬件的强耦合，且不便于抽象和复杂语法的实现。），所以需要在运行之前进行一番转换。 实现平台无关性、做到 “Write once, run anywhere”，获得跨平台的能力。这样便需要一个中间层进行解耦，达到上层统一编码、下层跨越平台、中间实现兼容（所以，Java 语言的跨平台特性是由 Java 运行时环境实现的。也就是在不同平台皆有与之相对应的 Java 运行时环境，实现相同定义、不同实现。这样的思想是不是很熟悉，当然，这仅是我的理解）。 提供托管环境（Managed Runtime），该托管环境可以代替我们处理一些通用的、容易出错的、高难度的行为，比如自动内存管理、垃圾回收、安全权限动态检测等。 2. Java 代码在虚拟机中是怎样运行的 2.1. 虚拟机视角 执行 Java 代码首先需要将它编译而成的 class 文件加载到 Java 虚拟机中，加载后的 Java 类会被存放到方法区中。实际运行时，虚拟机会执行方法区内的代码（需要将字节码翻译为机器码，在 HotSpot 实现中，有解释执行和即时编译两种）。...

前言 标准先行并不是一个新鲜玩意，不过是先制定事实标准，而后使用这些标准约束之后的行为。俗话说得好：“没有规矩，不成方圆”。在这里，我想说一下我认为的标准先行以及与持续交付的结合，希望不会对你产生误导。 为什么需要标准先行 我们可以先不去问为什么，而是反过来看这个问题。假设在我们的产物交付过程中，没有任何的标准，给你自由，会发生些什么问题。在一阵头脑风暴（抽搐）之后，我做出如下假设： 乱象百出，群魔乱舞。不论是正确的还是错误的产出，解释如此。比如，整体代码的可读性和可维护性直线下降；分支来回穿插，Commit 信息奇奇怪怪；开发、测试环境存在混用，测试数据过于随意；部署由心，同一个应用在不用的主机上存放位置可能还不同等等。 过程、阶段性产物不统一，且质量高低不齐，严重影响系统集成与交付。 高效完成，但前提是有着意见一致、理念相同、水平相当的一群人。 在我的假想中，自由带来的有好也有坏。但是我仍认为大部分的时候出现的都是坏的影响，毕竟要寻找到一群志同道合的人一起共事，就已经是一件很不容易的事了，且不说每个人都是单独的个体，其思想与灵魂亦是独一无二的。所以，不管在什么样的情况下，我们都需要制定标准来约束我们的行为。统一标准下的行为造成的影响几乎是一致的，那么即使是排错、修改时也是有迹可循。（在这里不会抬杠标准与自由的取舍，存在即是合理。但是从两者在大部分时候所能产生的影响来看，我会采取强标准，若自由的方式，但这绝非将两者置为对立关系。） 都有哪些标准先行 没有绝对通用的标准，任何的标准都是不同场景下最佳实践的总结，且需要持续的进行优化，是可以传承的宝贵知识集合。之所以扯这么一段话，我只是想说目前还处于实践阶段，但是这并不影响制定相关的标准。使用过 SpringBoot 开发的大佬都知道什么是约定优于配置，我认为标准亦是如此，即标准之上是约定。在这里，我将需要先行的标准分为了如下几个方面： 开发模式与分支策略（含 Commit 规范） 编码规范（Java、JavaScript） API 设计规范 数据库设计规范 环境隔离 部署规范 发布流水线标准 标准先行与持续交付 总结 参考文献 持续交付36讲 说明 我不是在卖课 本文大部分内容来源于极客时间以及网络博文节选，如有冒犯，我先向您道歉，另还请告知我进行处理，谢谢 邮箱：thread_zhou@126.com