原文链接：http://www.bengreenberg.dev/posts/2023-…

人们在网上首先发现你的地方是哪里？也许你的社交媒体是人们搜索你时首先发现的东西，亦也许是你为自己创建的投资组合网站。然而，如果你使用GitHub来分享你的代码并参与开源项目，那么你的GitHub个人主页可能是人们为了了解你而去的第一个地方。

你希望你的GitHub个人主页说些什么？你希望如何以简明易读的方式向访客表达对你的重要性以及你是谁？无论他们是未来的雇主还是开源项目的潜在合作伙伴，你都必须拥有一个引人注目的个人主页。

使用GitHub Actions，你可以把一个静态的markdown文档变成一个动态的、保持对你最新信息更新的良好体验。那么如何做到这一点呢？

我将向你展示一个例子，告诉你如何在不费吹灰之力的情况下迅速做到这一点。在这个例子中，你将学习如何抓取一个网站并使用这些数据来动态更新你的GitHub个人主页。我们将在Ruby中展示这个例子，但你也可以用JavaScript、TypeScript、Python或其他语言来做。

GitHub个人主页如何运作

你的GitHub个人主页可以通过在网页浏览器中访问github.com/[你的用户名]找到。那么该页面的内容来自哪里？

它存在于你账户中一个特殊的仓库中，名称为你的账户用户名。如果你还没有这个仓库，当你访问github.com/[你的用户名]时，你不会看到任何特殊的内容，所以第一步是确保你已经创建了这个仓库，如果你还没有，就去创建它。

探索仓库中的文件

仓库中唯一需要的文件是README.md文件，它是你的个人主页页面的来源。

./

├── README.md

继续在这个文件中添加一些内容并保存，刷新你的用户名主页，你会看到这些内容反映在那里。

为动态内容添加正确的文件夹

在我们创建代码以使我们的个人主页动态化之前，让我们先添加文件夹结构。

在顶层添加一个名为.github的新文件夹，在.github内部添加两个新的子文件夹：scripts/和workflows/。

你的文件结构现在应该是这样的：

./

├── .github/

│   ├── scripts/

│   └── workflows/

└── README.md

制作一个动态个人主页

对于这个例子，我们需要做三件事：

• 在README中定义一个放置动态内容的地方
• 在scripts/中添加一个脚本，用来完成爬取工作
• 在workflows/中为GitHub Actions添加一个工作流，按计划运行该脚本

现在让我们逐步实现。

更新README

我们需要在README中增加一个部分，可以用正则来抓取脚本进行修改。它可以是你的具体使用情况所需要的任何内容。在这个例子中，我们将在README中添加一个最近博客文章的部分。

在代码编辑器中打开README.md文件，添加以下内容：

### Recent blog posts

现在我们有了一个供脚本查找的区域。

创建脚本

我们正在构建的示例脚本是用Ruby编写的，使用GitHub gem octokit与你的仓库进行交互，使用nokogiri gem爬取网站，并使用httparty gem进行HTTP请求。

在下面这个例子中，要爬取的元素已经被确定了。在你自己的用例中，你需要明确你想爬取的网站上的元素的路径，毫无疑问它将不同于下面显示的在 posts 变量中定义的，以及每个post的每个title和link。

下面是示例代码，将其放在scripts/文件夹中：

require 'httparty'

require 'nokogiri'

require 'octokit'



# Scrape blog posts from the website

url = "<https://www.bengreenberg.dev/blog/>"

response = HTTParty.get(url)

parsed_page = Nokogiri::HTML(response.body)

posts = parsed_page.css('.flex.flex-col.rounded-lg.shadow-lg.overflow-hidden')



# Generate the updated blog posts list (top 5)

posts_list = ["\n### Recent Blog Posts\n\n"]

posts.first(5).each do |post|

  title = post.css('p.text-xl.font-semibold.text-gray-900').text.strip

  link = "<https://www.bengreenberg.dev#{post.at_css('a')[:href]}>"

  posts_list << "* [#{title}](#{link})"

end



# Update the README.md file

client = Octokit::Client.new(access_token: ENV['GITHUB_TOKEN'])

repo = ENV['GITHUB_REPOSITORY']

readme = client.readme(repo)

readme_content = Base64.decode64(readme[:content]).force_encoding('UTF-8')



# Replace the existing blog posts section

posts_regex = /### Recent Blog Posts\n\n[\s\S]*?(?=<\/td>)/m

updated_content = readme_content.sub(posts_regex, "#{posts_list.join("\n")}\n")



client.update_contents(repo, 'README.md', 'Update recent blog posts', readme[:sha], updated_content)

正如你所看到的，首先向网站发出一个HTTP请求，然后收集有博客文章的部分，并将数据分配给一个posts变量。然后，脚本在posts变量中遍历博客文章，并收集其中的前5个。你可能想根据自己的需要改变这个数字。每循环一次博文，就有一篇博文被添加到post_list的数组中，其中有该博文的标题和URL。

最后，README文件被更新，首先使用octokit gem找到它，然后在README中找到要更新的地方，并使用一些正则： posts_regex = /### Recent Blog Posts\n\n[\s\S]*?(?=<\/td>)/m。

这个脚本将完成工作，但实际上没有任何东西在调用这个脚本。它是如何被运行的呢？这就轮到GitHub Actions出场了！

创建Action工作流

现在我们已经有了脚本，我们需要一种方法来按计划自动运行它。GitHub Actions 提供了一种强大的方式来自动化各种任务，包括运行脚本。在这种情况下，我们将创建一个GitHub Actions工作流，每周在周日午夜运行一次该脚本。

工作流文件应该放在.github/workflows/目录下，可以命名为update_blog_posts.yml之类的。以下是工作流文件的内容：

name: Update Recent Blog Posts



on:

  schedule:

    - cron: '0 0 * * 0' # Run once a week at 00:00 (midnight) on Sunday

  workflow_dispatch:



jobs:

  update_posts:

    runs-on: ubuntu-latest



    steps:

    - name: Check out repository

      uses: actions/checkout@v2



    - name: Set up Ruby

      uses: ruby/setup-ruby@v1

      with:

        ruby-version: 3.1



    - name: Install dependencies

      run: gem install httparty nokogiri octokit



    - name: Scrape posts and update README

      run: ruby ./.github/scripts/update_posts.rb

      env:

        GITHUB_TOKEN: $

        GITHUB_REPOSITORY: $

这个工作流是根据cron语法定义的时间表触发的，该时间表指定它应该在每个星期天的00:00（午夜）运行。此外，还可以使用workflow_dispatch事件来手动触发该工作流。

update_posts工作由几个步骤组成：

• 使用 actions/checkout@v2操作来签出仓库。
• 使用 ruby/setup-ruby@v1 操作来设置 Ruby，指定的 Ruby 版本为 3.1。
• 使用 gem install 命令安装所需的 Ruby 依赖（httparty、nokogiri 和 octokit）。
• 运行位于.github/scripts/目录下的脚本 update_posts.rb。GITHUB_TOKEN和GITHUB_REPOSITORY环境变量被提供给脚本，使其能够与仓库进行交互。

有了这个工作流程，你的脚本就会每周自动运行，抓取博客文章并更新README文件。GitHub Actions负责所有的调度和执行工作，使整个过程无缝且高效。

将所有的东西放在一起

如今，你的网络形象往往是人们与你联系的第一个接触点--无论他们是潜在的雇主、合作者，还是开源项目的贡献者。尤其是你的GitHub个人主页，是一个展示你的技能、项目和兴趣的宝贵平台。那么，如何确保你的GitHub个人主页是最新的、相关的，并能真正反映出你是谁？

通过利用 GitHub Actions 的力量，我们展示了如何将你的 GitHub 配置文件从一个静态的 Markdown 文档转变为一个动态的、不断变化关于你是谁的例子。通过本指南提供的例子，你已经学会了如何从网站上抓取数据，并利用它来动态更新你的 GitHub个人主页。虽然我们的例子是用Ruby实现的，但同样的原则也可以用JavaScript、TypeScript、Python或你选择的任何其他语言来应用。

回顾一下，我们完成了创建一个Ruby脚本的过程，该脚本可以从网站上抓取博客文章，提取相关信息，并更新你的README.md文件中的"最近博客文章"部分。然后，我们使用GitHub Actions设置了一个工作流，定期运行该脚本，确保你的个人主页中保持最新的内容。

但我们的旅程并没有就此结束。本指南中分享的技术和方法可以作为进一步探索和创造的基础。无论是从其他来源拉取数据，与API集成，还是尝试不同的内容格式，都有无限的可能性。

因此，行动起来让你的 GitHub 个人主页成为你自己的一个充满活力的扩展。让它讲述你的故事，突出你的成就，并邀请你与他人合作。

主题

不知觉间,写东西也坚持一年多了,这一年间歇性的思考、充斥着空杯吸收的忙碌和工作之外的尝试，最近一段和领导之间的思考有所共鸣，记录下来，希望能引起边界问题的思考吧。

负重与前行

去年的严冬渲染，在今年3~4月份达到了顶峰，去年的焦虑最重，我所得出来的结论是：“即便是有天大的本事，也失去了意义”，得出这个结论的前提是,我已经尽我所能的驱动自己全盘吸收，认真做事,在此之外不停的摸索第二种小范围的业务试水，成功了一部分，但远远达不到预期的效果。

“日中则昃，月盈则食”，也许是预期见底，觉得即便是见底了也没多大了不起的事情，心态上好像好听点叫背水一战、悲观一些叫预期见底,已然死猪不怕开水烫。

搁置争议

因为一些非我这个层级的事情，但莫名其妙的旁观参与，和领导有一番恳谈,最终的思路基本上也就归结为 “还年轻,最终能依靠的也就是自身的能力，这个能力既包含执行、学习速度、业务、当然也包含为人处事的灵活性，但最重要的是选择大于努力”,事实上,从程序员的角度来讲，我已不再年轻,但相较于领导还算年轻，可能是角度不同，认知稍微有些差别，但大的方向没有任何问题，偏重点有所不同，领导对 “业务和学习速度” 很推崇，“工作处事的机变” 差不多是基本要求了😵,至于选择，其实也已经没多大选择了。

于我而言,我的定位其实一直立足于 “执行” 这个层级,并觉得以此为根基，空杯心理去掌握业务、学习速度、文档、软件全周期等内容，这基本也是我一直以来的理念，近一年多，基本接触的形形色色厉害的人有许多，事务杂，内容多，各种杂七杂八的东西，但不妨碍近一年多逐渐的总结和认识不足，可见性的提升是巨大的。 边界的问题，基本上属于 “能力边界是公司给个体划定的边界，你必须符合这个水平线之上，但是个人应该是对自己不设边界，但可以划定阶段方向”,我就以实际的接触来谈。

之后，和相对能够听得进去的同事也有讨论,毕竟绝大多数都是 “鸵鸟心态,今日不忧明日事,大事临身心态蹦”,对互联网从业者，没有人会相信一个人可以在一个公司待一辈子，但即便是有规划者,也很难在局限中做出合适的选择，但总有一条，心中愈惧怕愈是自身欠缺的，也许是个排错的选项。

拉回正题，集中讨论的话题也在于语言发展和执行力的问题上，就软件执行力而言，以单端来说，执行力和责任心，均算不错，但基本有个问题就是人为设定自身边界和定位，导致的结果就是一直在舒适区画圈，也仅此而已，我技术上学习模型基本上属于 结果->解决->问题->资料->细节 ,但接触许多人，往往纯纯的就是依靠，总觉得有人能解决,以蒙混过关的心态解决问题,从来不会涉及一个问题以月为单位摸索，即便这个事情已经过去了。

认知上，年龄到了这个阶段，单纯的开发执行能力在一般的事务上没啥本质的竞争力，因为复杂度的上限就在哪里，同事们在去年的环境思想鞭挞中，已经充分的有了认知，最后的结论都落脚在到那一天再说，陡然之间，可能发生的事情已然有了时间线的征兆，似乎一下子有些不知所措。

所以？

愕然也好，有准备也罢，但于我而言，能力的认可和肯定以及自我的肯定，让我的内心,在逐步见好的招聘中,找到了意义,也期待第二个年头，更强大有底气的自我,后面的着力点也会往行业的宽泛性、汇报交流的表达能力、架构设计的层次化展现力上去争取提升,当然,软件的开发能力是绝对不能松懈的，至于时间和精力，谁说这段没有悄悄提升自己的生产力工具呢, 重复性开发工作和一些杂项，已然没啥提升诉求的工作，必然是要借助工具释放自身的生产力了，而我又该继续往感兴趣的方向去学习了...

容我吐槽

Github语言趋势分析系列貌似发布总是说有啥不符合规范，唉，总是在发布的时候遭退~~~。

另外最近感觉好多外头和工作的事情累加了好几项，心态越发的好了，事情推进的有条不紊的，相比于之前，万事靠自身，其实合作也不错。

PS

发现身边事儿、聊点周奇遇，我是沈二，期待奇遇的互联网灵魂~、一起聊天吹水，探索新的可能~wx:breathingss，入圈吧！

附录

• 💪 我有一刀，可斩全栈
• 💪35岁鞋不合脚的问题
• 💪所谓核心竞争力

本文基于 WWDC 2022 Session 10157 和 Session 10158 梳理，为了更方便没有 SF Symbols 经验的读者理解，也将往年的 SF Symbols 相关内容一并整理。本文从 SF Symbols 4 的新特性切入，讨论 SF Symbols 这款由系统字体支持的符号库有哪些优点以及该如何使用。在这次 WWDC 2022 中，除了符号的数量的增加到了 4000+ 之外，还有自动渲染模式、可变符号等新特性推出，让 SF Symbols 这把利器变得又更加趁手和锋利了。

• WWDC21 - SF Symbols 3 使用指南
• WWDC21 - 定制属于你的 Symbols
• WWDC22 - SF Symbols 4 使用指南

本文是 WWDC22 内参 的供稿。

什么是 SF Symbols

符号在界面中起着非常重要的作用，它们能有效地传达意义，它们可以表明你选择了哪些项目，它们可以用来从视觉上区分不同类型的内容，他们还可以节约空间、整洁界面，而且符号出现在整个视觉系统的各处，这使整个用户界面营造了一种熟悉的感觉。

符号的实现和使用方式多种多样，但设计和使用符号时有一个亘古不变的问题，那就是将符号与用户界面的另一个基本元素——「文本」很好地配合。符号和文字在用户界面中以各种不同的大小被使用，他们之间的排列形式、对齐方式、符号颜色、文本字重与符号粗细的协调、本地化配置以及无障碍设计都需要开发者和设计师来细心配置和协调。

为了方便开发者更便捷、轻松地使用符号，Apple 在 iOS 13 中开始引入他们自己设计的海量高质量符号，称之为 SF Symbols。SF Symbols 拥有超过 4000 个符号，是一个图标库，旨在与 Apple 平台的系统字体 San Francisco 无缝集成。每个符号有 9 种字重和 3 种比例，以及四种渲染模式，它们的默认设计都与文本标签对齐，同时这些符号是矢量的，这意味着它们是可以被拉伸的，使得他们在无论用什么大小时都会呈现出很好的效果。如果你想去创造具有相似设计特征或无障碍功能的自定义符号，它们也可以被导出并在矢量图形编辑工具中进行编辑以创建新的符号。

对于开发者来说，这套 SF Symbols 无论是在 UIKit，AppKit 还是 SwiftUI 中都能运作良好，且使用方式也很简单方便，寥寥数行代码就可以实现。对于设计师来说，你只需要为符号只做三个字重的版本，SF Symbols 会自动地帮你生成其余 9 种字重和 3 种比例的符号，然后在 SF Symbols 4 App 中调整四种渲染模式的表现，就制作好了一份可以高度定制化的 symbol。

如何使用 SF Symbols

SF Symbols 4 App

在开始介绍如何使用 SF Symbols 之前，我们可以先下载来自 Apple 官方的 SF Symbols 4 App，这款 App 中收录了所有的 SF Symbols，并且记录了每个符号的名称，支持的渲染模式，可变符号的分层预览，不同语言下的变体，不同版本下可能出现的不同的名称，并且可以实时预览不同渲染模式下不同强调色的不同效果。你可以在这里下载 SF Symbols 4 App。

符号的渲染模式

通过之前的图片你可能已经注意到了，SF Symbols 可以拥有多种颜色，有一些 symbol 还有预设的配色，例如代表天气、肺部、电池的符号等等。如果要使用这些带有自定义颜色的符号，你需要知道，SF Symbols 在逻辑上是预先分层的（如下图的温度计符号就分为三层），根据每一层的路径，我们可以根据渲染模式来调整颜色，而每个 SF Symbols 有四种渲染模式。

单色模式 Monochrome

在 iOS 15 / macOS 11 之前，单色模式是唯一的渲染模式，顾名思义，单色模式会让符号有一个单一的颜色。要设置单色模式的符号，我们只需要设置视图的 tint color 等属性就可以完成。

let image = UIImage(systemName: "thermometer.sun.fill")

imageView.image = image

imageView.tintColor = .systemBlue



// SwiftUI

Image(systemName: "thermometer.sun.fill")

    .foregroundStyle(.blue)

分层模式 Hierarchical

每个符号都是预先分层的，如下图所示，符号按顺序最多分成三个层级：Primary，Secondary，Tertiary。SF Symbols 的分层设定不仅在分层模式下有效，在后文别的渲染模式下也是有作用的。

分层模式和单色模式一样，可以设置一个颜色。但是分层模式会以该颜色为基础，生成降低主颜色的不透明度而衍生出来的其他颜色（如上上图中的温度计符号看起来是由三种灰色组合而成）。在这个模式中，层级结构很重要，如果缺少一个层级，相关的派生颜色将不会被使用。

let image = UIImage(systemName: "thermometer.sun.fill")

let config = UIImage.SymbolConfiguration(hierarchicalColor: .lightGray)

imageView.image = image

imageView.preferredSymbolConfiguration = config



// SwiftUI

Image(systemName: "thermometer.sun.fill")

    .foregroundStyle(.gray)

    .symbolRenderingMode(.hierarchical)

调色盘模式 Palette

调色盘模式和分层模式很像，但也有些许不同。和分层模式一样是，调色盘模式也会对符号的各个层级进行上色，而不同的是，调色盘模式允许你自由的分别设置各个层级的颜色。

let image = UIImage(systemName: "thermometer.sun.fill")

let config = UIImage.SymbolConfiguration(paletteColors: [.lightGray, .cyan, .systemTeal])

imageView.image = image

imageView.preferredSymbolConfiguration = config



// SwiftUI

Image(systemName: "thermometer.sun.fill")

    .foregroundStyle(.lightGray, .cyan, .teal)

多色模式 Muticolor

在 SF Symbols 中，有许多符号的意象在现实生活中已经深入人心，比如：太阳应该是橙色的，警告应该是黄色的，叶子应该是绿色的的等等。所以 SF Symbols 也提供了与现实世界色彩相契合的颜色模式：多色渲染模式。当你使用多色模式的时候，就能看到预设的橙色太阳符号，红色的闹铃符号，而你不需要指定任何颜色。

let image = UIImage(systemName: "thermometer.sun.fill")

imageView.image = image

imageView.preferredSymbolConfiguration = .preferringMulticolor()



// SwiftUI

Image(systemName: "thermometer.sun.fill")

    .symbolRenderingMode(.multicolor)

自动渲染模式 Automatic

谈论完了四种渲染模式，可以发现每次设置 symbol 的渲染模式其实也是一件费心的事情。为了解决这个问题，在最新的 SF Symbols 中，每个 symbol 都有了一个自动渲染模式。例如下图的 shareplay 符号，你可以看到在右侧面板中，shareplay 符号的第二个模式（分层模式）的下方有一个空心小圆点，这意味着该符号在代码中使用时，假如你不去特意配置他的渲染模式，那么他将使用分层模式作为他的默认渲染模式。

你可以在 SF Symbols 4 App 中查询到所有符号的自动渲染模式。

可变颜色

在有的时候，符号并不单单代表一个单独的概念或者意象，他也可以代表一些数值、比例或者程度，例如 Wi-Fi 强度或者铃声音量，为了解决这个问题，SF Symbols 引入了可变颜色这个概念。

你可以在 SF Symbol 4 App 中的 Variable 目录中找到所有有可变颜色的符号，平且可以通过右侧面板的滑块来查看不同百分比程度下可变颜色的形态。另外你也可以注意到，可变颜色的可变部分实际上也是一种分层的表现，但这里的分层和上文提到的渲染模式使用的分层是不同的。一个符号可以在渲染模式中只分两层，在可变颜色的分层中分为三层，下图中第二个符号喇叭 speaker.wave.3.fill 就是如此。关于这里的分层我们会在后文如何制作可变颜色中详细讨论。

在代码中，我们只需要在初始化 symbol 时增加一个 Double 类型的 variableValue 参数，就可以实现可变颜色在不同程度下的不同形态。值得注意的是，假如你的可变颜色（例如上图 Wi-Fi 符号）可变部分有三层，那么这个 variableValue 的判定将会三等分：在 0% 时将不高亮信号，在 0%～33% 时，将高亮一格信号，在 34%～67 % 时，将高亮 2 格信号，在 68% 以上时，将会显示满格信号。

let img = NSImage(symbolName: "wifi", variableValue: 0.2)

可变颜色的可变部分是利用不透明度来实现的，当可变颜色和不同的渲染模式结合后，也会有很好的效果。

如何制作和调整可变颜色

在 SF Symbols 4 App 中，我们可以自定义或者调整可变颜色的表现，接下来我将带着大家以 party.popper 这个符号为基础制作一个带可变颜色的符号。

1. 首先我们打开 SF Symbols 4 App，在右上角搜索 party.popper，找到该符号后右键选择 复制为1个自定符号。推荐你在上方将符号的排列方式修改为画廊模式，如下图所示。

   
   

2. 可以注意到右下角的 层 这个板块，这个符号默认是由两个层级组成的，分别是礼花和礼花筒，同时我们也可以看到，礼花和礼花筒又分别是由更零碎的路径组成的，通过勾选子路径我们可以给每个层新增或者减少路径。那我现在想要给这个符号新增一层，我只需要在画廊模式下，将符号的某一部分拖拽到层里就可以。

   
   

3. 通过这样的操作，我们可以将这个符号整理为四层：礼花筒、线条礼花、小球礼花和大球礼花。为了可变颜色的效果，我们需要按照从下到上：礼花筒、线条礼花、大球礼花和小球礼花的顺序去放置层级，另外，我们可以切换到分层模式、调色板模式和多色模式里面去调整成自己喜欢的颜色来预览效果，我这里调整了多色模式中的配色，具体效果如下。

   
   

4. 接下来，我们将前三层，也就是除了礼花筒外的三层，最右侧的可变符号按钮选中，来表示这三层将可以在可变符号的变化范围内活动。接下来，只要点击颜色区域内的可变符号按钮，我们就可以拖动滑块来查看可变颜色的形态。

   
   

5. 至此，我们就完成了一个带可变颜色的自定义符号，我们可以在合适的地方使用这个符号。例如我的 App 有一个 4 个步骤的新手引导，这时候就可以给每一个步骤配备一个符号来让界面变得更加的活泼。
   
   

统一注释 Unified annotations

其实我们已经接触到了 Unified annotations 这个过程，它就是将符号的层级，路径以及子路径整理成在四个渲染模式下都能良好工作的过程，就如同上文彩色礼花筒的例子，我们通过统一注释，让彩色礼花筒符号在不同渲染模式、不同环境色、不同主题色下，都能良好的运作。

那一般来说，对于单色模式，不需要过多的调整，它就能保持良好的形态；对于分层模式和调色盘模式，我们需要在给每个层设定好哪个是 Primary 层、哪个是 Secondanry 层以及哪个是 Tertiary 层，这样系统就会按优先级给符号上合适的颜色；对于多色模式，我们可以根据喜好以及符号的意义，给它预设一个合理的颜色，另外还要注意的是，如果设计了可变颜色在符号中，那么要注意保持可变符号的效果在四个渲染模式上都表现正常。

除了这些之外，还有一些特别的地方需要注意，我们以 custom.heart.circle.fill 为例子。你可以注意到，这个垃爱心符号是有一个圆形的背景的，在这种情况下，假如我们按照原来的规则去绘制单色模式，会发现：背景的圆形和爱心的图案将会是同一个颜色，那我们就将看不见圆形背景下的图案了。

这时我们可以使用 Unified annotations 给我们提供的新功能，我们将上图在 层 板块的爱心，将它从 Draw 改成 Erase，这样，我们就相当于以爱心的形状镂空了这个白色的背景，从而使该图形展现了出来并且在单色模式下能够一直表现正常。同理，在分层模式和调色盘模式中，也有这个 Erase 的功能共大家调整使用。

字重和比例

SF Symbols 和 Apple 平台的系统字体 San Francisco 一样，拥有九种字重和三种比例可以选择，这意味着每个 SF Symbol 都有 27 种样式以供使用。

let config = UIImage.SymbolConfiguration(pointSize: 20, weight: .semibold, scale: .large)

imageView.preferredSymbolConfiguration = config



// SwiftUI

Label("Heart", systemImage: "heart")

    .imageScale(.large)

    .font(.system(size: 20, weight: .semibold))

符号的字重和文本的字重原理相同，都是通过加粗线条来增加字重。但 SF Symbols 的三种比例尺寸并不是单纯的对符号进行缩放。如果你仔细观察，会发现对于同一个字重，但是不同比例的符号来说，他们线条的粗细是一样的，但是对符号的整体进行了扩充和延展，以应对不一样的使用环境。

要实现这样的效果，意味着每个 symbol 的底层逻辑并不是一张张图片，而是由一组组的路径构成，这也是为什么在当你想要自定义一个属于自己的 symbol 的时候，官方要求你用封闭路径 + 填充效果去完成一个符号，而不是使用一条简单路径 + 路径描边（stroke）来完成一个符号。

更多关于如何制作一个 symbol 的内容，请移步 WWDC 21 内参：定制属于你的 Symbols。

除了字重和比例之外，SF Symbols 还在很多方面进行了努力来方便开发者的工作，例如：符号的变体、不同语言下符号的本地化、符号的无障碍化等，关于这些内容，以及其它由于篇幅原因未在本文讨论的细节问题，请移步 WWDC 21 内参：SF Symbols 使用指南。

总结

从上文介绍 SF Symbols 的特性和优点我们可以看到，它的出现是为了解决符号与文本之间的协调性问题，在保证了本地化、无障碍化的基础上，Apple 一直在实用性、易用度以及多样性上面给 SF Symbols 加码，目前已经有了 4000+ 的符号可以使用，相信在未来还会有更多。这些符号的样式和图案目前看来并不是那么的广泛，这些有限的符号样式并不能让设计师安心代替所有界面上的符号，但是有失必有得，在这样一个高度统一的平台上，SF Symbols 在规范化、统一化、表现能力、代码与设计上的简易程度，在今年都又进一步的提升了，达到了让人惊艳的程度，随着 SF Symbols 的继续发展，我相信对于部分开发者来说，即将成为一个最优的符号工具🥳。

更多资料

以下是这几年关于 SF Symbols 的资料：

• [ WWDC 22 ] What's new in SF Symbols 4
• [ WWDC 22 ] Adopt Variable Color in SF Symbols
• [ WWDC 21 内参 ] SF Symbols 使用指南
• [ WWDC 21 内参 ] 定制属于你的 Symbols
• [ Human Interface Guidelines ] SF Symbols
• [ Developer ] SF Symbols

以下是更早的 SF Symbols 资料：

• [ WWDC 21 ] What’s new in SF Symbols
• [ WWDC 21 ] SF Symbols in UIKit and AppKit
• [ WWDC 21 ] SF Symbols in SwiftUI
• [ WWDC 21 ] Explore the SF Symbols 3 app
• [ WWDC 21 ] Create custom symbols
• [ WWDC 20 ] SF Symbols 2
• [ WWDC 19 ] Introducing SF Symbols

由于今年工作中用得语言换成 Rust/OCaml/ReScript 啦，所以导致我现在写代码更倾向于写函数式风格的代码。

顺便试试 Swift 在函数式方面能达到啥好玩的程度。主要是我不会 Swift，仅仅为了好玩。

创建工程

随便创建个工程，小玩具就不打算跑在手机上了，因为我的设备是 ARM 芯片的，所以直接创建个 Mac 项目，记得勾上包含测试。

构建 MTKView 子类

现在来创建个 MTKView 的子类，其实我现在已经不接受这种所谓的面向对象，开发者用这种方式，就要写太多篇幅来描述一个上下文结构跟函数就能实现的动作。

import MetalKit



class MetalView: MTKView {

    required init(coder: NSCoder) {

        super.init(coder: coder)

        device = MTLCreateSystemDefaultDevice()

        render()

    }

}



extension MetalView {

    func render() {

        // TODO: 具体实现

    }

}

我们这里给 MetalView extension 了一个 render 函数，里面是后续要写得具体实现。

普通的方式画一个三角形

先用常见的方式来画一个三角形

class MetalView: MTKView {

    required init(coder: NSCoder) {

        super.init(coder: coder)

        device = MTLCreateSystemDefaultDevice()

        render()

    }

}



extension MetalView {

    func render() {

        guard let device = device else { fatalError("Failed to find default device.") }

        let vertexData: [Float] = [

            -1.0, -1.0, 0.0, 1.0,

             1.0, -1.0, 0.0, 1.0,

             0.0,  1.0, 0.0, 1.0

        ]



        let dataSize = vertexData.count * MemoryLayout<Float>.size

        let vertexBuffer = device.makeBuffer(bytes: vertexData, length: dataSize, options: [])

        let library = device.makeDefaultLibrary()

        let renderPassDesc = MTLRenderPassDescriptor()

        let renderPipelineDesc = MTLRenderPipelineDescriptor()

        if let currentDrawable = currentDrawable, let library = library {

            renderPassDesc.colorAttachments[0].texture = currentDrawable.texture

            renderPassDesc.colorAttachments[0].clearColor = MTLClearColor(red: 0.0, green: 0.5, blue: 0.5, alpha: 1.0)

            renderPassDesc.colorAttachments[0].loadAction = .clear

            renderPipelineDesc.vertexFunction = library.makeFunction(name: "vertexFn")

            renderPipelineDesc.fragmentFunction = library.makeFunction(name: "fragmentFn")

            renderPipelineDesc.colorAttachments[0].pixelFormat = .bgra8Unorm

            let commandQueue = device.makeCommandQueue()

            guard let commandQueue = commandQueue else { fatalError("Failed to make command queue.") }

            let commandBuffer = commandQueue.makeCommandBuffer()

            guard let commandBuffer = commandBuffer else { fatalError("Failed to make command buffer.") }

            let encoder = commandBuffer.makeRenderCommandEncoder(descriptor: renderPassDesc)

            guard let encoder = encoder else { fatalError("Failed to make render command encoder.") }

            if let renderPipelineState = try? device.makeRenderPipelineState(descriptor: renderPipelineDesc) {

                encoder.setRenderPipelineState(renderPipelineState)

                encoder.setVertexBuffer(vertexBuffer, offset: 0, index: 0)

                encoder.drawPrimitives(type: .triangle, vertexStart: 0, vertexCount: 3, instanceCount: 1)

                encoder.endEncoding()

                commandBuffer.present(currentDrawable)

                commandBuffer.commit()

            }

        }

    }

}

然后是我们需要注册的 Shader 两个函数

#include <metal_stdlib>



using namespace metal;



struct Vertex {

    float4 position [[position]];

};



vertex Vertex vertexFn(constant Vertex *vertices [[buffer(0)]], uint vid [[vertex_id]]) {

    return vertices[vid];

}



fragment float4 fragmentFn(Vertex vert [[stage_in]]) {

    return float4(0.7, 1, 1, 1);

}

在运行之前需要把 StoryBoard 控制器上的 View 改成我们写得这个 MTKView 的子类。

自定义操作符

函数式当然不是指可以定义操作符，但是没有这些操作符，感觉没有魂灵，所以先定义个管道符

代码实现

precedencegroup SingleForwardPipe {

    associativity: left

    higherThan: BitwiseShiftPrecedence

}



infix operator |> : SingleForwardPipe



func |> <T, U>(_ value: T, _ fn: ((T) -> U)) -> U {

    fn(value)

}

测试管道符

因为创建项目的时候，勾上了 include Tests，直接写点测试代码，执行测试。

final class using_metalTests: XCTestCase {

    // ...



    func testPipeOperator() throws {

        let add = { (a: Int) in

            return { (b: Int) in

                return a + b

            }

        }

        assert(10 |> add(11) == 21)

        let doSth = { 10 }

        assert(() |> doSth == 10)

    }

}

目前随便写个测试通过嘞。

Functional Programming

现在需要把上面的逻辑分割成小函数，事实上，因为 Cocoa 的基础是建立在面向对象上的，我们还是没法完全摆脱面向对象，目前先小范围应用它。

生成 MTLBuffer

先理一下逻辑，代码开始是创建顶点数据，生成 buffer

fileprivate let makeBuffer = { (device: MTLDevice) in

    let vertexData: [Float] = [

        -1.0, -1.0, 0.0, 1.0,

         1.0, -1.0, 0.0, 1.0,

         0.0,  1.0, 0.0, 1.0

    ]

    

    let dataSize = vertexData.count * MemoryLayout<Float>.size

    return device.makeBuffer(bytes: vertexData, length: dataSize, options: [])

}

创建 MTLLibrary

接着是创建 MTLLibrary 来注册两个 shader 方法，还创建了一个 MTLRenderPipelineDescriptor 对象用于创建 MTLRenderPipelineState，但是创建的 MTLLibrary 对象是一个 Optional 的，所以其实得有两步，总之先提取它再说吧

fileprivate let makeLib = { (device: MTLDevice) in device.makeDefaultLibrary() }

抽象 map 函数

根据我们有限的函数式编程经验，像 Optional 这种对象大概率有一个 map 函数，所以我们自家实现一个，同时还要写成柯里化的（建议自动柯里化语法糖入常），因为这里有逃逸闭包，所以要加上 @escaping

func map<T, U>(_ transform: @escaping (T) throws -> U) rethrows -> (T?) -> U? {

    return { (o: T?) in

        return try? o.map(transform)

    }

}

处理 MTLRenderPipelineState

这里最终目的就是 new 了一个 MTLRenderPipelineState，顺带处理把程序的一些上下文给渲染管线描述器（MTLRenderPipelineDescriptor），譬如我们用到的着色器（Shader）函数，像素格式。
最后一行直接 try! 不处理错误啦，反正出问题直接会抛出来的

fileprivate let makeState = { (device: MTLDevice) in

    return { (lib: MTLLibrary) in

        let renderPipelineDesc = MTLRenderPipelineDescriptor()

        renderPipelineDesc.vertexFunction = lib.makeFunction(name: "vertexFn")

        renderPipelineDesc.fragmentFunction = lib.makeFunction(name: "fragmentFn")

        renderPipelineDesc.colorAttachments[0].pixelFormat = .bgra8Unorm

        return (try! device.makeRenderPipelineState(descriptor: renderPipelineDesc))

    }

}

暂时收尾

已经不想再抽取函数啦，其实还能更细粒度地处理，因为函数式有个纯函数跟副作用的概念，像 Haskell 里是可以用 Monad 来处理副作用的情况，这个主题留给后续吧。先把 render 改造一下

fileprivate let render = { (device: MTLDevice, currentDrawable: CAMetalDrawable?) in

    return { state in

        let renderPassDesc = MTLRenderPassDescriptor()

        if let currentDrawable = currentDrawable {

            renderPassDesc.colorAttachments[0].texture = currentDrawable.texture

            renderPassDesc.colorAttachments[0].clearColor = MTLClearColor(red: 0.0, green: 0.5, blue: 0.5, alpha: 1.0)

            renderPassDesc.colorAttachments[0].loadAction = .clear

            let commandQueue = device.makeCommandQueue()

            guard let commandQueue = commandQueue else { fatalError("Failed to make command queue.") }

            let commandBuffer = commandQueue.makeCommandBuffer()

            guard let commandBuffer = commandBuffer else { fatalError("Failed to make command buffer.") }

            let encoder = commandBuffer.makeRenderCommandEncoder(descriptor: renderPassDesc)

            guard let encoder = encoder else { fatalError("Failed to make render command encoder.") }

            encoder.setRenderPipelineState(state)

            encoder.setVertexBuffer(device |> makeBuffer, offset: 0, index: 0)

            encoder.drawPrimitives(type: .triangle, vertexStart: 0, vertexCount: 3, instanceCount: 1)

            encoder.endEncoding()

            commandBuffer.present(currentDrawable)

            commandBuffer.commit()

        }

    }

}

然后再调用，于是就变成下面这副鸟样子

class MetalView: MTKView {

    required init(coder: NSCoder) {

        super.init(coder: coder)

        device = MTLCreateSystemDefaultDevice()

        device |> map {

            makeLib($0)

            |> map(makeState($0))

            |> map(render($0, self.currentDrawable))

        }

    }

}

最后执行出这种效果

项目背景

闲来无事，在使用某云音乐听歌的时候发现一个侧滑展开的内页，交互效果还不错。

那么这一章节中，我们将使用SwiftUI搭建一个侧边展开页面交互。

项目搭建

首先，创建一个新的SwiftUI项目，命名为SlideOutMenu。

逻辑分析

首先我们来分析下基本的逻辑，一般的侧滑展开方式的交互是，在首页右上角有一个“更多”的按钮，点击按钮时，内页菜单从左往右划出，滑出至离右边20～30的位置停止。

然后首页背景将蒙上一个蒙层，点击蒙层时，侧滑展开的页面从右往左收起。

简单分析完逻辑后，我们来实现这个交互。

首页入口

首先，我们需要在首页搭建一个入口，示例：

// 顶部导航入口

private var moreBtnView: some View {

    Button(action: {

    }) {

        Image(systemName: "list.bullet")

            .foregroundColor(.black)

    }

}

然后，我们可以使用NavigationView和navigationBarItems创建顶部导航按钮样式，示例：

var body: some View {

    NavigationView {

        Text("点击左上角侧滑展开")

            .padding()

            .navigationBarTitle("首页", displayMode: .inline)

            .navigationBarItems(leading: moreBtnView)

    }

}

如此，首页入口部分我们就完成了。

左边菜单

接下来，我们来构建左侧菜单的内容。我们可以沿用之前设计过的“设置”页面的结构，我们先来构建栏目结构。示例：

// MARK: 栏目结构

struct listItemView: View {

    var itemImage: String

    var itemName: String

    var body: some View {

        Button(action: {

        }) {

            HStack {

                Image(systemName: itemImage)

                    .font(.system(size: 17))

                    .foregroundColor(.black)

                Text(itemName)

                    .foregroundColor(.black)

                    .font(.system(size: 17))

                Spacer()

                Image(systemName: "chevron.forward")

                    .font(.system(size: 14))

                    .foregroundColor(.gray)

            }.padding(.vertical, 10)

        }

    }

}

在我们构建侧滑展开的页面前，我们需要声明两个变量，一个是侧滑展开的页面的宽度，一个是当前这个页面的位置。示例：

@State var menuWidth = UIScreen.main.bounds.width - 60

@State var offsetX = -UIScreen.main.bounds.width + 60

我们设置的侧滑展开页面的宽度是屏幕宽度-60，而当前侧滑展开页面的位置是负位置，这样就可以在展示的时候先把页面隐藏起来。

而当我们点击顶部导航中的“更多”按钮时，将offsetX偏移量X轴坐标设置为0。示例：

// 顶部导航入口

private var moreBtnView: some View {

    Button(action: {

        withAnimation {

            offsetX = 0

        }

    }) {

        Image(systemName: "list.bullet")

            .foregroundColor(.black)

    }

}

然后，我们创建一个新视图来构建侧滑展开的页面内容，示例：

// MARK: 左侧菜单

struct SlideOutMenu: View {

    @Binding var menuWidth: CGFloat

    @Binding var offsetX: CGFloat



    var body: some View {

        Form {

            Section {

            }

            Section {

                listItemView(itemImage: "lock", itemName: "账号绑定")

                listItemView(itemImage: "gear.circle", itemName: "通用设置")

                listItemView(itemImage: "briefcase", itemName: "简历管理")

            }

            Section {

                listItemView(itemImage: "icloud.and.arrow.down", itemName: "版本更新")

                listItemView(itemImage: "leaf", itemName: "清理缓存")

                listItemView(itemImage: "person", itemName: "关于掘金")

            }

        }

        .padding(.trailing, UIScreen.main.bounds.width - menuWidth)

        .edgesIgnoringSafeArea(.all)

        .shadow(color: Color.black.opacity(offsetX != 0 ? 0.1 : 0), radius: 5, x: 5, y: 0)

        .offset(x: offsetX)

        .background(

            Color.black.opacity(offsetX == 0 ? 0.5 : 0)

                .ignoresSafeArea(.all, edges: .vertical)

                .onTapGesture {

                    withAnimation {

                        offsetX = -menuWidth

                    }

                })

    }

}

上述代码中，我们也对页面宽度menuWidth、偏移位置offsetX进行了声明，方便之后我们在ContentView视图中进行双向绑定。

我么使用Form表单和Section段落构建样式，这点就不说了。

值得说的一点是，我们设置了在页面展开的时候，也就是offsetX页面偏移量X轴坐标不为0，我们加了一个阴影，完善了侧滑展开页面的悬浮效果。

然后使用offset调整页面初始位置。背景部分，除了根据offsetX页面偏移量X轴坐标加了一个蒙层，而且当我们点击的背景的时候，我们将偏移位置offsetX重新赋值，这样就能实现收起的交互效果。

我们在ContentView视图中展示侧滑展开视图，示例：

var body: some View {

    ZStack {

        NavigationView {

            Text("点击左上角侧滑展开")

                .padding()

                .navigationBarTitle("首页", displayMode: .inline)

                .navigationBarItems(leading: moreBtnView)

        }

        SlideOutMenu(menuWidth: $menuWidth, offsetX: $offsetX)

    }

}

项目展示

恭喜你，完成了本章的全部内容！

快来动手试试吧。

一、一些迹象

逛社区，偶然看到了这张图片：

嗯……我眉头一皱，久久不语，心想，有这么夸张吗，假的吧？

突然想到，最近我在社区发了个前端招聘的信息，结果简历漫天纷飞，塞爆邮箱。

莫非，前端这个岗位真的不再是供不应求了？🤔

二、原因分析

我细想下，也差不多到时候了。

从16年到现在，算算，7年的时间了。

前端大火就是从16年开始的，多种原因，包括：

移动互联网的兴起，传统行业的数字化转型，大前端技术的普及等。

紧接着是Vue为代表的前端框架和工具的兴起，使得前端开发的门槛进一步降低，前端也成为进入互联网圈子的最快最容易的跳板，促使前端圈进一步繁荣。

然而，连王菲都知道，没有什么是长盛不衰的。

发展，稳定，衰落是亘古不变的事物发展规律。

各种迹象表明，无论是有意还是无意，目前互联网的发展似乎进入了平稳期，这也意味着岗位的需求也开始变得平稳，而涌入这个行业的新人却没有停止，这就必然导致到了某个时间点，前端从业人员会达到饱和，于是那些没有竞争力的人就会遇到求职困境。

遇困的人多了，在社区的声音多了，自然也就会出现“前端已死”这样的言论。

三、破局之道

想要改变这种现状，只能是下面两种方法。

一是烧香拜佛，祈祷互联网大环境好转，最好再来一波生产力或生产环境的变革，让前端行业再赶上一波发展的春风，催生更大的岗位需求，何愁就业？

但显然，寄希望于大环境是不靠谱的，生产力虽然一定是往上走的，但说不定不是助力行业的发展，而是革了行业的命。

比方说现在很火的chatGPT，你说是会增加前端岗位呢，还是空窗加倍绝绝子？

所以，要想前端碗端得稳，前端饭吃得香，还是得靠下面这个方法，也就是想办法提高个人的核心竞争力。

提高核心竞争力

所谓核心竞争力，说白了，就是你能干别人干不了的活，能做别人做不了的事情。

更直白一点，就是你能给团队创造比别人更多的价值。

很普通的一句话，对不对？但是意识到和意识不到，那可是天差地别。

最近虽然收到了很多简历，但是看完之后都只能无奈摇头，不能说一模一样嘛，可以说极其雷同，缺少区分度。

专业技能均是全覆盖，工作描述均是自己用了什么前端框架，做了什么什么工作。

没有任何吸引人的信息，给人感觉，就是个普通的前端从业人员，领导安排个需求，然后接受，排期，完成开发，上线，这种。

这就……对吧，不是不给机会，实在是给不了。

一百份简历竞争一个招聘HC，肯定是把面试机会留给那些有突出亮点的人的。

拿工作描述举例，你一个一个罗列你做的项目，用了哪些技术有什么用？所有投简历的人都有做项目，都有使用前端技术，你的这些描述完全就是废话，简历扔垃圾箱的那种。

不需要扯那么多，你就说你比别人牛在什么地方！

注意，这个牛，不一定就是技术水平或者业务成果，任何亮点都可以，只要是能够做到别人做不到的事情，同时是对团队有帮助的，都可以。

举几个例子：

– 我参与了团队所有项目的开发，“所有”就是亮点，隐约让人觉得你是可信任的。

– 我是团队下班最晚的，工作最积极的。也是亮点，可以提，工时越长，通常产出越多，性价比就越高。

– 我在团队里做了很多看不见的工作。亮点，主动承担边缘工作不是所有人都可以做到的。

– 我是团队内分享（面授或文章都可以）次数第一。亮点，加分，帮助团队成长也是一种价值产出。

– 我连续获得四星五星荣誉，或者优秀员工称号，加分，公司的认可比自己在简历上吹上天都有用。

甚至是工作以外的特长都可以，我是钓鱼大佬，我是跑步达人，我是综艺专家，我是健身狂人，都可以，因为一个人能坚持自己的爱好并做到出众，也是不简单的。

可偏偏问题就在于，能够获得面试机会的亮点如此简单，很多人却没有，一个也没有。

因为在日常工作中就没有这种意识，就是我要做得比别人更好、我要强化我的优势、我要想办法让团队变得更好的意识。

平时工作就是浑浑噩噩的状态，等需求，写代码，上线，拿钱，一切都是在被动进行，仅把前端当作职业而非事业，总是希望干活少，拿钱多。

所以做事难以精益求精，也不会为了更好的未来努力让当下的自己变得更好，也不会主动做那些工作以外的对团队有帮助的事情，典型的被网上的躺平言论给忽悠瘸了。

弄错了因果，即，我给老板加班，又不会给我涨薪，我为什么要加班？我学习更底层的技术，平时又用不到，我为什么要学？我平时工作那么忙，还要我去写文档做分享，我为什么要做？

所以，找不到工作就不要怨天尤人了，也别说什么“前端已死”，前端行业好着呢，优秀的前端不知道多缺，年薪不知道有多高！

框架的能力

很多人做开发非常熟练，各种得心应手，于是就会觉得自己是个挺有竞争力的前端开发人员。

高启强没有说话，只是呵呵一笑。

这是不小心把框架的能力当作自己的能力了。

大家不妨冷静想一想，借助一个成熟的框架，开发出一个合格的Web应用，他的难度有多高？

更具体点，我们经常使用的各种小程序和快应用，让一个培训班里培训了3个月的新人，以及充足的时间，他能不能捣鼓出来？

答案显而易见，肯定可以，至少绝大多数人都可以。

因为使用一个东西的难度要比创造一个东西的难度低多了。

也就是，基于Vue等前端框架的开发，它是需要技术的，但是，它并不需要的很高的技术。

这种状态最容易迷惑人，所谓满瓶不动半瓶摇。

如果不能跳出自己所处的环境，正在更高的视角看待自己，非常容易对自己在行业所处的层次造成误判，譬如，我明明干活很利索，怎么没有面试机会，一定是我们这个行业出问题了。

这就是误判，有问题的不是行业，而是自己的竞争力不足。

我再说一遍，希望大家不要嫌啰嗦，使用工具的能力，并不能作为核心竞争力，因为现在学习资料很丰富，社区很活跃，什么问题都可以找到解决方案，你能做到的别人也能做到，没有任何优势，不属于竞争力。

反而是下面这些能力有足够的区分度。

• 比他人涉猎更广，例如音视频处理、图形表现实现或者Node开发有较多经验；
• JS、CSS等前端基本功扎实，积累深厚，各种API特性了然于心，最佳实践信手捏来；
• 具有设计审美或者产品嗅觉灵敏，开发的产品体验非常好，干活很细。

拥有这些能力或特质，并在简历上表现出来，最好有材料佐证，那找到一份满意的工作是非常轻松的事情。

就怕一年经验十年用，从此外卖天天送。

当然，不可否认，虽说框架与工具让很多人陷入了温床，但对于国家整个数字化转型和互联网的发展是做出了重大贡献的。

在巨大需求出现的时候，有足够多的人力迅速投身这个行业，带动整个行业的发展。

只是，潮水终会退去，只有那些真正会游泳的才能继续在大海中徜徉。

四、未来如何

常常有人问我，旭哥，我应该学什么才有前途？

每当看到这样的问题，我都会眉头紧锁，过于功利的心态，在技术这条路上注定难有大成。

这就有点类似于养殖业，比如说前两年养鲈鱼很赚钱，结果很多养殖户改养鲈鱼，造成今年鲈鱼泛滥，市场存量是过去数倍，根本卖不出价格，最后赔得裤衩都不剩了。

技术其实也是类似，有人一看前端就业形势大好，都去搞前端，结果“前端已死”。

技术栈也是一样，妄图学完之后自己就成了香饽饽，可能吗？人是趋利性的动物，就算你眼光独到，命运垂怜，抢得先机，但数年之后呢？

所以，其实重要的不是学了什么，而是学得怎么样。

心无旁骛，专注自身，无论学什么，从事哪个职业，只要自己足够有竞争力，都有前途。

无论是历史悠久的后端开发，还是巅峰期早已过去的客户端开发，亦或者是开始进入稳定期的前端开发，均是如此。

前端的未来

随着消费和广告行业的慢慢复苏，前端的就业情况会有所好转。但是……

首先，这个好转不会很快，而是很缓慢那种，因为当一个事物陷入低谷再要起来，前期都是缓慢的，需要升到某一个临界点之后，才会明显加速。

其次，就算前端的就业情况有所恢复，也不可能恢复到疫情之前的那种火热，那个时候遍地都是前端培训班，非常夸张。

至于前端是否会死，这个完全不要担心。

只要互联网还在，前端这个职业就不会消失，因为无论设备介质如何变化，用户的交互行为都不会消失，而前端就是一个处理人机交互的职业。

而人工智能的兴起，确实会对前端这个职业产生影响，是危机但也是机遇，如果你安于现状，则是危机，如果你勤于学习，则人工智能是机遇，会让你的产出更加高效。

这么看来，最核心的竞争力应该是学习的能力！

（完）

关于我

由于高中的游手好闲、不学无术，没有考上大学。去了一所专科学校，本以为自己能够浪子回头，在学校好好学习。可惜的是，来到一个陌生又充满诱惑的城市后，迅速的迷失了自己，天天埋头打游戏，学习的事情早已抛之脑后。

一晃眼，到了2020年，疫情的接踵而至，让我这个本来没有任何技术、学历的“闲散人士”更加雪上加霜。豪不夸张的说，当时去实习，就差跪着求人家要我，说自己不要薪资。经历过一个月后，也就是2020年5月底，我找到了一份前端开发工作，从此开启了我的前端开发工作之旅。

在专科学校里的时间，我并没有意识到社会市场的残酷，甚至天真的认为自己还是能够辛苦点的找到一份工作。可是，现实给了我当头一棒，没有技术、没有学历、疫情打击。那一段时间应该是真的认知自己的时间，家里也没什么闲钱供我去培训班，我也不知道我出去能干嘛。去看了一圈市场，与跟同学的了解，了解到了前端开发工作，所以就一股脑扎进这个行业当中。

求职之旅

跟大多数人一样，并不知道应该从何处下手，当时在我的认知当中就知道一个 JQuery，所谓的 MVVM 框架简直是一无所知。点开小破站，找到点击率最高的视频，开始自学起来。

了解到一点框架的皮毛、然后死记硬背一点基础，统统写进简历当中。

所以我的学习曲线是如图下所示

跟大多数人一样，我是直接通过框架起手学习的前端。导致了我对于问题的处理能力几乎为零，遇到问题直接就双手离开键盘。看不懂，是真的看不懂（如果有相同感受的可以在评论抠一个 1）。

对着视频学了十天左右，写了一个 demo，屁颠颠的去求职。结果也是可想而知，人家也不是傻子一眼识破。四处碰壁，简历丢出去，根本没人看。兜兜转转持续了一个月左右，终于有一家小公司愿意给一个面试机会，马不停蹄的出发去面试，坐了一个小时左右的地铁抵达一个破旧不堪的写字楼，当时要不是看到周围还有一个高校，我还以为我去了一个搞传销的地方。。。推开一个破旧的们，一个很小的房间，两个人坐在里面给我面试。我也很直白的说自己只会一点点皮毛，他们也很直白的告诉我：我们条件有限，相当于是各取所需。其实老实说，我挺感动的，没有给我画大饼，也很直白的说我图他们要我，他们图我不要啥钱。

最终，我也算是如愿找到了这份实习工作，一个月 2000。也算是不错的结果了。

实习项目开发

去到公司以后，也马不停蹄的开始了开发工作。首先就是让我从一个简单的后台管理系统开始入手。但是问题也来了，我根本不知道什么叫管理系统，连项目搭建我都不会，然后就是两眼一抹黑。不停的去百度，查看如何搭建一个后台管理系统。

老实说，我当时连路由是什么我都不清楚，更别说加一堆乱七八糟的功能在里面了。哪个过程可想而知，多么的折磨人。经历了半个月，模板被我折腾起来了一个简单的样子，对着人家的管理系统样子进行拙劣的模仿。但是 bug 满天飞也是避免不了的问题。并且没有丝毫的设计可言，纯纯的依托答辩。

最后的最后，实在是看不下去了（包括我自己），去网上扒了一个模板开始自己去折腾。为什么一开始不考虑使用模板呢？因为我看不懂代码，下不去手。

虽然最后跌跌撞撞的项目启动起来了，但是也算是我第一次项目开发的经历吧。后续持续的添加一些功能，改动一些简单的样式，还好老板也很佛系，没有为难我，基本上没有魔改模板。所以也算是顺利的完成了后台管理系统的开发任务。

小插曲

在实习工作的期间，在技术群中认识了一个很牛的大佬。经常我在群里问一些傻逼问题（因为自己基础太差了），但是他都会很耐心的给我讲解，甚至是下班后抽出时间给我远程讲课。也算是我的半个引路人吧，让我知道了如何去玩儿前端。在这里手动抠一个感谢🙏🙏🙏。

步入正轨

在经历过第一个项目开发后，也算是知道了框架应该如何去玩儿（也就是知道了框架的 api 如何去调用）。也知道了如何去学好前端，所以慢慢的回头去了解基前端的三大基础知识 js css html。

其实我相信很多人跟我一样，开始都是赶鸭子上架的形式去开发项目，遇到问题束手无策；遇到 bug 不知道如何去排查；遇到不知道如何去实现。。。最后我也总结出了问题所在，那就是基础的不扎实，学习顺序的问题，导致了这些问题。

啰嗦一句

哪怕是现在，我有时候跟网友聊天的时候也能听到一些让人不能理解的观点：前端那么简单有什么难度？前端不就是写写页面？前端。。。。

从我的观点出发而言，前端这个岗位确实是属于，宽进严出。想入行确实很容易，毕竟像我这样啥也不懂的，通过十来天的学习都能去做前端开发的事情。

但是，但是，但是，重要的话说三遍，前端的简单是因为它的入行门槛低。但是入门和会还是有本质的区别，绝大多数前端开发工作都是写 后台管理系统，这种开发，都是直接套用现成模板与组件就能够写。如果是定制化开发，脱离了后台管理系统的开发，那还是有手就行吗？

继续步入正轨

在工作的时间中，也认识了很多互联网大厂的大牛：滴滴、网易、腾讯等，经常厚着脸皮去请教他们。但是他们回应最多的是：多看基础，看书！

大佬们都这么说，那还等什么！直接开始行动。

• 绿宝书：犀牛书
• 红宝书：javascript高级程序设计
• 黄宝书：你不知道的js

直接搞起来！虽然我很讨厌看书，但是看到自己实习的 2k 工资，我还不动起来，那可能真就废了。

所以每天下班后，回家翻开书籍，开始看。果不其然，一看就打瞌睡，生涩、枯燥的知识内容。没办法，继续去请教如何看书学习，得到的答案就是：好记性，不如烂笔头。

然后读书的时候，边看边写，跟做笔记一样。效果果然好多了，没那么容易打瞌睡。而且我也买了一些零食（口香糖、耐嚼的肉干之类的）边看边吃，让自己集中注意力。总之是为了能够学到真知识，想尽了各种办法。

半个月后，看了几章节基础，感觉确实潜移默化的改变了一些。写代码的时候不会那么的茫然；反复调试的次数少了一些；知道了更多好用的 api ，代码质量有一定的提高。

读书笔记分享

读书笔记

在这里分享一篇，自己从零开始写的一些笔记。不过自己已经停更很久了。

实习总结

经过两个月的实习后，时间也来到了 2020年7月，我毕业了。我也学到了很多东西，但是我觉得，这样子的工作状态并不是我喜欢的。

回学校简单收拾了一下，也决定了辞职。去找一份更加有前途的工作，当然这里肯定有很多人疑惑：你凭什么啊？确实是如此，包括我的父母，也是很疑惑并且还质疑的问道：你上几个月班，忘了自己的实际情况了？

我也开始反思，自己真的就那么的蠢、那么的不堪吗？

果断辞职

经过我的深思熟虑后，还是在毕业后辞职了。在出租屋沉淀了一个月，这一个月基本上每天只睡了五六个小时，其余时间都花在了基础的夯实上面，狠狠的补充前端基础知识。每天醒来就是：看书、写 demo、请教大佬，每天如此，孜孜不倦。

一个月后，整理自己的简历，然后又开始了自己的求职之旅。

二次求职

求职之路，也并没有自己想的那么顺利。别人也没有因为我简历写的东西多了那么一点可怜的东西而青睐你。

我也在开始反思，自己的辞职是否正确。因为我的本质问题并没有解决：没有学历、没有经验。期间也在自我怀疑、自我安慰，也在凌晨的时候，抓耳挠腮，头发也在开始一大把一大把的掉。

就这样持续了一个月左右，我终于又收到了一份面试邀请。马不停蹄的前去面试，结果却出乎我的意料，他们并没有问我八股文，反而是对我所说的经历感兴趣。我也是添油加醋的说了一顿我的实习经历、辞职后的这一个月的学习经历。

最后的最后，他们通过了我的初试。给我说需要老大亲自面试，我开始很忐忑。但是见到老大后，他是一个很和蔼的老师，并没有刁难我，也没有问我刁钻问题，只是跟我谈了一下基本情况、了解了我的基本情况，就通过了我的二次面试。

二次求职之旅结果

我很幸运，因为，让我去打工的地方是一个资源丰富的高校。我的老大也是院长，初次面试的两位也是两位老师。我也如愿以偿的又有了一份新的工作，接触到了极其丰富的资源。

老师们也很愿意教授知识，让我的技术再次的突飞猛进。

开发项目：

• 北京冬奥会水立方保电系统
• 基于负荷聚合的园区能量态势感知与交易系统
• 电压暂降仿真模拟系统

薪资变化

毕业后，我的薪资也算是以每年翻倍的涨幅进步。也算是我的学习换来的回报吧。还是挺不错的～

现在

截至目前，经过三年零两个月的工作时间，也算是勉强迈入了初级前端开发的门槛吧。不断的学习中，也在积极的参与开源的贡献。

• Ray Template
• Vue3 Next QRcode
• Vue Hooks Plus

这些都是本人参与开发、贡献的项目，有兴趣可以点开看看。如果觉得有用也可以点一个小星星🌟～～～

最后

学习确实是一个枯燥的过程，也是一个很痛苦的过程。包括自己，如果不是那些大佬对我的帮助，我也不会那么快的进步。最后还是很衷心的感谢他们对我的帮助～

废话开篇：利用 UICollectionView 简单实现一个图片浏览效果。

一、效果展示

二、实现思路

1、封装 UICollectionViewLayout ，实现内部 UICollectionViewCell 的布局。

UICollectionViewLayout 在封装瀑布流的时候会用到，而且担负着核心功能的实现。其实从另一个角度也可以把 UICollectionViewLayout 理解成“数据源”，这个数据不是 UI 的展示项，而是 UI 的尺寸项。在内部进行预计算 UICollectionViewCell 的 frame。

UICollectionView 是 UIScrollView的子类，只不过，它里面子控件通过“重用”机制实现了优化，一些复用的复杂逻辑还是扔给了系统处理。开发过程中只负责对 UICollectionViewLayout 什么时候需要干什么进行自定义即可。

2、获取 UICollectionView 目前可见的 cells，通过进行缩放、旋转变换实现一些简单的效果。

3、自定义 cell ，修改锚点属性。

三、代码整理

1、PhotoBrowseViewLayout

这里有一点需要注意的，在 UICollectionViewLayout 内部会进行计算每一个 cell 的 frame，在计算过程中，为了更好的展示旋转变换，cell 的锚点会修改到 （0.5，1），那么，为了保证 UI 展示不变，那么，就需要将 y 增加 cell 高度的一半。

#import "PhotoBrowseViewLayout.h"



@interface PhotoBrowseViewLayout()



@property(nonatomic,strong) NSMutableArray * attributeArray;



@property(nonatomic,assign) CGFloat cellWidth;



@property(nonatomic,assign) CGFloat cellHeight;



@property(nonatomic,assign) CGFloat sep;



@property(nonatomic,assign) int showCellNum;





@end



@implementation PhotoBrowseViewLayout



- (instancetype)init

{

    if (self = [super init]) {

        self.sep = 20;

        self.showCellNum = 2;

    }

    return self;

}



//计算cell的frame

- (UICollectionViewLayoutAttributes *)layoutAttributesForItemAtIndexPath:(NSIndexPath *)indexPath

{

    if (self.cellWidth == 0) {

        self.cellWidth = **self**.collectionView.frame.size.width * 2 / 3.0;

    }

    if (self.cellHeight == 0) {

        self.cellHeight = self.collectionView.frame.size.height;

    }

    CGFloat x = (self.cellWidth + self.sep) * indexPath.item;

    //这里y值需要进行如此设置，以抵抗cell修改锚点导致的UI错乱

    CGFloat y = self.collectionView.frame.size.height / 2.0;

    UICollectionViewLayoutAttributes *attrs = [UICollectionViewLayoutAttributes layoutAttributesForCellWithIndexPath:indexPath];



    attrs.frame = CGRectMake(x, y, self.cellWidth, self.cellHeight);

    return attrs;

}



//准备布局

- (void)prepareLayout

{

    [super prepareLayout];

    NSInteger count = [self.collectionView numberOfItemsInSection:0];

    for (int i = 0; i <count; i++) {

        UICollectionViewLayoutAttributes *attris = [self layoutAttributesForItemAtIndexPath:[NSIndexPath indexPathForRow:i inSection:0]];

        [self.attributeArray addObject:attris];

    }

}



//返回全部cell的布局集合

- (NSArray *)layoutAttributesForElementsInRect:(CGRect)rect

{

    return self.attributeArray;

}



//一次性提供UICollectionView 的 contentSize

- (CGSize)collectionViewContentSize

{

    NSInteger count = [self.collectionView numberOfItemsInSection:0];

    CGFloat maxWidth = count * self.cellWidth + (count - 1) * self.sep;

    return CGSizeMake(maxWidth, 0);

}



- (NSMutableArray *)attributeArray

{



    if (!_attributeArray) {

        _attributeArray = [[NSMutableArray alloc] init];

    }

    return _attributeArray;

}



@end

2、PhotoBrowseCollectionViewCell

这里主要是进行了锚点修改（0.5，1），代码很简单。

#import "PhotoBrowseCollectionViewCell.h"



@interface PhotoBrowseCollectionViewCell()



@property(nonatomic,strong) UIImageView * imageView;



@end



@implementation PhotoBrowseCollectionViewCell





- (instancetype)initWithFrame:(CGRect)frame

{

    if (self = [super initWithFrame:frame]) {

        //设置（0.5，1）锚点，以底部中点为轴旋转

        self.layer.anchorPoint = CGPointMake(0.5, 1);

        self.layer.masksToBounds = YES;

        self.layer.cornerRadius = 8;

    }

    return self;

}



- (void)setImage:(UIImage *)image

{

    self.imageView.image = image;

}





- (UIImageView *)imageView

{



    if (!_imageView) {

        _imageView = [[UIImageView alloc] init];

        _imageView.contentMode = UIViewContentModeScaleAspectFill;

        _imageView.backgroundColor = [UIColor groupTableViewBackgroundColor];

        [self.contentView addSubview:_imageView];

    }

    return _imageView;

}



- (void)layoutSubviews

{

    [super layoutSubviews];

    self.imageView.frame = **self**.contentView.bounds;

}



@end

3、CollectPhotoBrowseView

CollectPhotoBrowseView 负责进行一些 cell 的图形变换。

#import "CollectPhotoBrowseView.h"

#import "PhotoBrowseCollectionViewCell.h"

#import "PhotoBrowseViewLayout.h"



@interface CollectPhotoBrowseView()<UICollectionViewDelegate,UICollectionViewDataSource>



@property(nonatomic,strong) UICollectionView * photoCollectView;



@end



@implementation CollectPhotoBrowseView



- (instancetype)initWithFrame:(CGRect)frame

{

    if (self = [super initWithFrame:frame]) {

        [self makeUI];

    }

    return self;

}



- (void)makeUI{

    //设置自定义 UICollectionViewLayout

    PhotoBrowseViewLayout * photoBrowseViewLayout = [[PhotoBrowseViewLayout alloc] init];

    self.photoCollectView = [[UICollectionView alloc] initWithFrame:self.bounds collectionViewLayout:photoBrowseViewLayout];

    self.photoCollectView.delegate = self;

    self.photoCollectView.dataSource = self;

    [self.photoCollectView registerClass:[PhotoBrowseCollectionViewCell class] forCellWithReuseIdentifier:@"CELL"];

    self.photoCollectView.showsHorizontalScrollIndicator = NO;

    [self addSubview:self.photoCollectView];

    //执行一次可见cell的图形变换

    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(0.0 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{

        [self visibleCellTransform];

    });

}



- (NSInteger)collectionView:(UICollectionView *)collectionView numberOfItemsInSection:(NSInteger)section

{

    return 20;

}



- (UICollectionViewCell *)collectionView:(UICollectionView *)collectionView cellForItemAtIndexPath:(NSIndexPath *)indexPath

{

    PhotoBrowseCollectionViewCell * cell = [collectionView dequeueReusableCellWithReuseIdentifier:@"CELL" forIndexPath:indexPath];

    [cell setImage: [UIImage imageNamed:[NSString stringWithFormat:@"fd%ld",indexPath.item % 3 + 1]]];

    return cell;

}



#pragma mark - 滚动进行图形变换

- (void)scrollViewDidScroll:(UIScrollView *)scrollView

{

    //滑动的时候，动态进行cell图形变换

    [self visibleCellTransform];

}



#pragma mark - 图形变化

- (void)visibleCellTransform

{

    //获取当前可见cell的indexPath集合

    NSArray * visibleItems =  [self.photoCollectView indexPathsForVisibleItems];

    //遍历动态进行图形变换

    for (NSIndexPath * visibleIndexPath in visibleItems) {

        UICollectionViewCell * visibleCell = [self.photoCollectView cellForItemAtIndexPath:visibleIndexPath];

        [self transformRotateWithView:visibleCell];

    }

}



//进行图形转换

- (void)transformRotateWithView:(UICollectionViewCell *)cell

{

    //获取cell在当前视图的位置

    CGRect rect = [cell convertRect:cell.bounds toView:self];

    //计算当前cell中轴线与中轴线的距离的比值

    float present = ((CGRectGetMidX(rect) - self.center.x) / (self.frame.size.width / 2.0));

    //根据位置设置选择角度

    CGFloat radian = (M_PI_2 / 15) * present;

    //图形角度变换

    CGAffineTransform transformRotate = CGAffineTransformIdentity;

    transformRotate = CGAffineTransformRotate(transformRotate, radian);

    //图形缩放变换

    CGAffineTransform transformScale = CGAffineTransformIdentity

    transformScale = CGAffineTransformScale(transformScale,1 -  0.2 *  fabs(present),1 - 0.2 * fabsf(present));

    //合并变换

    cell.transform = CGAffineTransformConcat(transformRotate,transformScale);

}



@end

四、总结与思考

UICollectionView 也是 View，只不过系统为了更好的服务于开发者，快速高效的实现某些开发场景，进行了封装与优化，将复杂的逻辑单独的封装成一个管理类，这里就是 UICollectionViewLayout，交给它去做一些固定且复杂的逻辑。所以，自定义复杂UI的时候，就需要将功能模块足够细化，以实现更好的代码衔接。代码拙劣，大神勿笑[抱拳][抱拳][抱拳]

1. 往事再回首

最近年中开部门总结会议，我向公司领导和同事总结了入职近三年以来，企业数字化转型的过程和成果。
我所在的企业是一家中华老字号企业，也是一家传统制造业企业，十几年前由国企转私营。入职前，有关领导和人事部门简要给我介绍了他们企业信息化系统实施情况，停下来大概仅有U8、OA这两个算拿得出手的信息系统，一个用来管理供应链一个用来作日常工作审批。其余像生产管理系统MES，立体库管理系统等都是找一些小公司或个人开发的系统，以长时间无人运维，这些项目甚至连公司、开发人员以及相关资料都找不到了。

未入职之前，公司已在准备相关的上市计划，企业数字化转型已迫在眉睫。企业数字化转型是IT部门打翻身仗的机会，我是顺应公司制定好的数字化转型战略计划后，招兵买马进来的，职责就是协助我的直系领导（CIO)组建一支专业能力足够强的IT团队，制定企业数字化转型战略目标和计划，通过招投标实施信息化项目，来满足企业转型的需求。

大部分中小企业发展到一定规模，都会面临着管理难题，然而，IT部门在老板眼里，往往又是一个不受重视的支出型的部门，大部分的中小型制造型企业的IT部门，活多事杂话语权少，往往充当着修电脑，修网络等等此类的基础设施运维角色。在入职后的前三个月，部门未招聘任何一名员工，只为摸清楚企业信息化的底细.....

三个月的时间，让我清晰的认识到，事情远远不及我想的那么简单，该企业因长期没有信息化项目的实施和开展，公司管理层甚至也是因为上市才有了信息化建设的初步想法，很多人也因为墨守成规，甚至连一些基本的信息化、常用办公软件操作的本领都没有，信息化素质有待提升，IT部门工作开展面临者不小的压力。

2. 工作成果总结

入职公司这三年多以来，我与诸位领导和IT部门的各位同事们，通过夜以继日的不懈奋斗，先后实施了诸多项目。其中包括公司位于广东某市的智能工厂项目（2022年10月正式投产），生产管理系统MES系统（2022年8月正式上线），以及ERP系统SAP（替代U8）（2023年1月1日正式上线），并引入了业务流程管理系统BPM（替代OA）（2022年1月18日正式上线）。

可以说，已经完成了企业在供应链生产制造端的初步转型，在办公自动化上初见成效。未来，我们将实施供应商和经销商协同平台，同时还要在销售端发力，拉起企业数字化转型的大网，覆盖上下游供应商、终端用户，以及企业内所有的员工。

3.反思和总结

3.1 企业如何进行数字化转型

中小企业在数字化转型过程中是十分渴望实现信息化、数字化的。然而，由于他们的信息化底子薄，信息化人才队伍建设难，以及企业文化等种种因素的影响，往往会导致信息化项目无法发挥出其真正的价值。 

 中小企业数字化转型是一项系统工程，需要全面考虑企业的战略目标、技术支持和组织变革，同时注重持续的管理和优化。企业数字化转型主要包含以下步骤。

明确目标：确定数字化转型的目标和期望效果，如提高生产效率、优化供应链管理、拓展新的市场渠道等。

评估现状：分析企业现有的信息化水平、IT基础设施、业务流程和人员能力，并识别存在的痛点和问题。

制定战略计划：根据目标和评估结果，制定详细的数字化转型战略计划，包括具体的项目和时间表。

技术选型与建设：选择适合企业需求的技术解决方案，如企业资源计划（ERP）系统、客户关系管理（CRM）系统、供应链管理系统等，并进行系统的规划、设计和实施。

数据整合与分析：确保各个系统之间的数据交互和共享，建立数据仓库或数据湖，通过数据分析和挖掘获得有价值的洞察。

组织变革与培训：调整组织结构和流程，培养员工适应数字化转型的能力，提供相关培训和支持。

监控与优化：建立监控机制，及时评估数字化转型的效果，并进行优化和调整，以保持持续改进。

在数字化转型过程中，中小企业需要关注以下几个重点：

项目管理：合理规划项目的范围、时间和资源，确保项目的顺利实施和交付。
数据安全：加强信息安全意识，采取有效的措施保护企业数据和客户信息的安全性。
风险管理：评估数字化转型可能面临的风险，制定相应的风险管理措施，并建立灵活应对的机制。
合作伙伴选择：选择可靠的技术供应商和合作伙伴，共同推动数字化转型的实施和成功。

3.2 IT部门如何打好数字化战役

当公司引入新系统、用户提出新需求时，IT部门要抓住这样的契机，推动公司对原有不合理的业务流程进行改造。然而，这是一场硬仗，弄不好可能会项目推进不力，还得罪人。所以要想打好这场仗，首先IT部门内部要统一思想，一致对"外"。明确好我们的使命和愿景，确定好我们工作的推进方法和节奏，保证信息在部门内得到完整的有效的传递。

 IT部门在企业转型过程中，担任十分重要的专业角色。我认为IT部门必须承担的使命，主要包括以下几项：

1、改变用户思维，培养用户习惯：这个过程考验IT部门成员对公司业务的熟悉程度、对行业标准化流程的理解程度，以及谈判能力能否说服用户接受所提出的改造方案。

2、抓住项目机遇，实现战略目标：通过项目的实施，技术的驱动，把原有的一些不合理业务从企业业务中重点拿出来讨论，并制定专业合规的方案，在兼顾业务发展的同时，又要考虑到后期如何监控（建立指标）该项业务改革后的成效。这是一件十分有挑战且对个人能力要求极高的事情，需要在公司各个系统实施前，做好系统信息交互的顶层设计，定好发展方向，才能把此事做好。

3、建立数据指标，监控实施效果：在项目转入运维后，能通过查看数据指标，掌握到设计好的业务方案实施是否成功，带来的效益如何。同时通过建立数据指标，可以辅助高层进行决策，让技术倒逼业务优化，实现技术与业务的双向驱动。

4. 评估数字化转型实施成果

以下是我的个人观点和总结：
我认为，制造型中小企业数字化转型，必须经历从 实现自动化到迈向数字化最后实现智能化的阶段。如何评估企业数字化转型成功与否？如何衡量此时企业数字化程度？

当前信息时代，数据是最重要的生产资源！数据在企业中流通的量级大，效率高，覆盖面广，是数据发挥价值大小的评判标准。企业数字化转型程度，取决于

• 企业内部是否建立起完整的数据传输链（数据在各系统之间共享）
• 能够完整的查询到某一项数据从进入系统开始，直至归档为止的完整链路（数据生命周期可追溯）
• 数据分析，数据可视化提供决策能力（充分发挥数据价值）

5.项目管理中的方法论

在项目管理和实施中，要善于使用管理方法和指导和总结项目工作，以下是常见的几种方法论：

5.1 8020原则

在公司现阶段，生产端数字化目标实现后，用户的需求猛增。此时我提出：利用8020原则，聚焦20%我们认为有价值的需求，把握用户提出需求的机会，对业务流程再进行进一步的完善和提升，剩余的80%需求可以暂缓甚至拒绝。我们目前完成生产端信息化改造后，企业用户也慢慢被我们培养出利用信息化手段和工具解决问题的思维习惯。

随之而来的，就是对IT部门的挑战，用户面对这些新系统，会不断提需求，期望IT部门满足他们。从我目前工作的经历来看，大部分的需求是来自于职员级别的，然而，他们提出的需求，往往是出于减少他们工作量以及出错概率的定位上来提的。

而企业的中层管理者，大都是沉默的，毕竟屁股决定脑袋。需求增多，面临就是开发工作的陡然增加，此时IT部门就要学会与用户斡旋，利用一些特殊的手段，来筛选需求。聚焦对业务有重点提升的需求，才能发挥出IT部门最大的价值！ 

5.2 PDCA循环

PDCA循环是一种连续改进的管理方法，它代表了Plan（计划）、Do（执行）、Check（检查）和Act（行动）四个阶段。它的目的是通过循环反复进行这四个阶段，不断完善和优化过程，实现持续的改善和提高。

通过PDCA循环，可以不断发现问题、改进流程和工作方式，提高质量和效率，逐步实现目标。它是一种有效的管理工具，能帮助组织在不断变化的环境中保持竞争力。

5.3 SWOT分析

SWOT分析是一种战略管理工具，用于评估一个组织或个人的优势（Strengths）、劣势（Weaknesses）、机会（Opportunities）和威胁（Threats）。通过进行SWOT分析，可以了解一个组织或个人在特定环境中的情况，并制定相应的战略。
下图是我总结的，我部门团队目前所处的形势： 

6.总结

中小企业数字化转型是一个历史必然的过程。随着信息技术不断发展和普及，企业要想保持竞争力和适应市场变化，数字化转型已成为一种必备的发展战略。在这个过程中，我们积累了许多宝贵的经验，也面临了一些需要注意的问题。

中小企业数字化转型还需要面对市场和竞争的问题。随着数字化转型的普及，市场竞争将变得更加激烈。企业需要及时调整自己的业务模式和市场策略，提高自身的竞争力。

首先，需要明确转型的目标和意义。中小企业进行数字化转型的目的通常是提高效率、降低成本、改善客户体验等。在实施过程中，我们要清楚地定义自己的转型目标，并为此付出努力。同时，也要理解数字化转型的意义，认识到它不仅仅是一次技术升级，更是一次全方位的组织变革。

其次，要注重组织文化和人员培养。数字化转型不仅仅是一项技术工作，更需要对组织文化进行调整和塑造。中小企业需要建立一个支持创新和变革的文化环境，激发员工的数字思维和创新能力。此外，投资人员培养和技能提升也是关键，因为他们将是数字化转型中的推动者和执行者。

此外，应该遵循逐步推进的原则。由于中小企业的资源有限，一次性完成全面的数字化转型可能会带来巨大的压力和风险。因此，我们建议采取渐进的方法，从一个具体的业务领域或流程开始，逐步迭代和扩展。这样可以确保转型的可控性和成功性，并在实施过程中不断调整和改进。

总之，中小企业数字化转型是一项具有重要意义的任务。通过数字化转型，企业可以实现更高效的运营和更好的市场竞争力。然而，数字化转型也需要企业面对一些挑战和问题。只有充分认识到这些问题并采取相应的措施，企业才能顺利地完成数字化转型，实现持续发展。

上一篇：项目进度管理工具:进度网络图

一些数字化转型的参考链接：

• 企业数字化的定义和意义
• 企业数字化的战略和转型
• 数字化转型的关键要素和挑战
• 企业数字化的案例研究和成功实践
• 企业数字化工具和技术

本文所述的经验总结仅表示个人经验和观点，希望能为中小企业的数字化转型提供一些借鉴和启示。

跨浏览器兼容性是前端开发中至关重要的概念。由于不同浏览器（如Chrome、Firefox、Safari等）在实现Web标准方面存在差异，网页在不同浏览器上可能会呈现不一致的结果。因此，确保网页在各种浏览器上都能正确显示和运行，是提供良好用户体验、扩大受众范围以及增强网站可访问性的关键。

兼容性测试工具和方法

自动化测试工具的使用 自动化测试工具能够帮助开发者更快速、高效地进行浏览器兼容性测试，以下是一些常用的自动化测试工具：

1. Selenium：Selenium是一个流行的自动化测试框架，用于模拟用户在不同浏览器上的交互。它支持多种编程语言，并提供了丰富的API和工具，使开发者可以编写功能测试、回归测试和跨浏览器兼容性测试。
2. TestCafe：TestCafe是一款基于JavaScript的自动化测试工具，用于跨浏览器测试。它不需要额外的插件或驱动程序，能够在真实的浏览器中运行测试，并支持多个浏览器和平台。
3. Cypress：Cypress是另一个流行的自动化测试工具，专注于现代Web应用的端到端测试。它提供了简单易用的API，允许开发者在多个浏览器中运行测试，并具有强大的调试和交互功能。
4. BrowserStack：BrowserStack是一个云端跨浏览器测试平台，提供了大量真实浏览器和移动设备进行测试。它允许开发者在不同浏览器上同时运行测试，以检测网页在不同环境中的兼容性问题。

手动测试方法和技巧 除了自动化测试工具，手动测试也是重要的一部分，特别是需要验证用户体验和视觉方面的兼容性。以下是几种常用的手动测试方法和技巧：

1. 多浏览器测试：在不同浏览器（如Chrome、Firefox、Safari）上手动打开网页，并检查布局、样式和功能是否正常。特别关注元素的位置、尺寸、颜色和字体等。
2. 响应式测试：使用浏览器的开发者工具或专门的响应式测试工具（如Responsive Design Mode）来模拟不同设备的屏幕尺寸和方向，确保网页在不同设备上呈现良好。
3. 用户交互测试：模拟用户操作，例如点击按钮、填写表单、滚动页面和使用键盘导航，以确保网页在各种用户交互场景下都能正常运行。
4. 边界条件测试：测试极端情况下的表现，例如超长文本、超大图片、无网络连接等。确保网页在异常情况下具备良好的鲁棒性和用户友好性。

设备和浏览器的兼容性测试 为了确保网页在不同设备和浏览器上的兼容性，以下是一些建议的测试方法：

1. 设备兼容性测试：

   • 使用真实设备：将网页加载到不同类型的设备上进行测试，例如桌面电脑、笔记本电脑、平板电脑和智能手机等。
   • 使用模拟器和仿真器：利用模拟器或仿真器来模拟不同设备的环境，并进行测试。常用的模拟器包括Android Studio自带的模拟器和Xcode中的iOS模拟器。

2. 浏览器兼容性测试：

   • 考虑常见浏览器：测试网页在主流浏览器（如Chrome、Firefox、Safari、Edge）的最新版本上的兼容性。
   • 旧版本支持：如果目标受众使用旧版浏览器，需要确保网页在这些浏览器上也能正常运行。可以使用Can I Use（caniuse.com）等工具来查找特定功能在不同浏览器上的兼容性。

3. 定期更新测试设备和浏览器：随着时间的推移，新的设备和浏览器版本会发布，因此建议定期更新测试设备和浏览器，以保持兼容性测试的准确性。

常见的前端兼容性问题

我在下面列举了一些常见的兼容性问题，以及解决办法。

1. 响应式布局兼容性问题：

   • 媒体查询失效：确保正确使用CSS媒体查询，并对不支持媒体查询的旧版浏览器提供备用样式。
   • 页面在不同设备上的布局错乱：使用弹性布局（Flexbox）、网格布局（Grid）和CSS框架（如Bootstrap）可以有效解决布局问题。

2. 图片兼容性问题：

   • 不支持的图片格式：使用WebP、JPEG XR等现代图片格式，同时提供备用格式（如JPEG、PNG）以供不支持的浏览器使用。
   • Retina屏幕显示问题：使用高分辨率（@2x、@3x）图片，并通过CSS的background-size属性或HTML的srcset属性适应不同屏幕密度。

3. 字体兼容性问题：

   • 不支持的字体格式：使用Web字体（如Google Fonts、Adobe Fonts）或@font-face规则，并提供备用字体格式以适应不同浏览器。
   • 字体加载延迟：使用字体加载器（如Typekit、Font Face Observer）来优化字体加载，确保页面内容在字体加载完成前有一致的显示。

4. JavaScript兼容性问题：

   • 不支持的ES6+特性：使用Babel等工具将新版本的JavaScript代码转换为旧版本的代码，以兼容不支持最新特性的浏览器。
   • 缺乏对旧版浏览器的支持：根据目标用户群体使用的浏览器版本，选择合适的JavaScript库或Polyfill进行填充和修复。

5. 表单兼容性问题：

   • 不同浏览器对表单元素样式的差异：使用CSS样式重置或规范化库来保证表单元素在各个浏览器上显示一致。
   • HTML5表单元素的不完全支持：使用JavaScript库（如Modernizr）来检测并补充HTML5表单元素的功能支持。

6. Ajax和跨域请求问题：

   • 浏览器安全策略导致的Ajax跨域问题：通过设置CORS（跨域资源共享）或JSONP（仅适用于GET请求）来解决跨域请求问题。
   • IE浏览器对XMLHttpRequest的限制：使用自动检测并替代方案（如jQuery的AJAX方法），或考虑使用现代的XMLHttpRequest Level 2 API（如fetch）。

CSS常见的兼容性问题

CSS兼容性问题是在不同浏览器中，对CSS样式的解析和渲染会存在一些差异。以下是一些常见的CSS兼容性问题以及对应的解决方案：

1. 
   

   盒模型：

   
   
   
   
   • 问题：不同浏览器对盒模型的解析方式存在差异，导致元素的宽度和高度计算结果不一致。
   
   
   • 解决方案：使用CSS盒模型进行标准化，通过设置box-sizing: border-box;来确保元素的宽度和高度包括边框和内边距。
   
   
   
   


2. 
   

   浮动和清除浮动：

   
   
   
   
   • 问题：浮动元素可能导致父元素的塌陷问题（高度塌陷）以及与其他元素的重叠问题。
   
   
   • 解决方案：可以使用清除浮动的技巧，如在容器元素末尾添加一个空的<div style="clear: both;"></div>元素来清除浮动，或者使用clearfix类来清除浮动（如.clearfix:after { content: ""; display: table; clear: both; }）。
   
   
   
   


3. 
   

   绝对定位和相对定位：

   
   
   
   
   • 问题：绝对定位和相对定位的元素在不同浏览器中的表现可能存在差异，特别是在z轴上的堆叠顺序。
   
   
   • 解决方案：明确设置定位元素的position属性（position: relative;或position: absolute;），并使用z-index属性来控制元素的堆叠顺序。
   
   
   
   


4. 
   

   样式重置与规范化：

   
   
   
   
   • 问题：不同浏览器对默认样式的定义存在差异，导致页面在不同浏览器中显示效果不一致。
   
   
   • 解决方案：引入样式重置或规范化的CSS文件，如Eric Meyer's Reset CSS 或 Normalize.css。这些文件通过将默认样式置为一致的基准值，使页面在各个浏览器上的显示效果更加一致。
   
   
   
   


5. 
   

   不同浏览器对CSS盒模型的解析差异：

   
   
   
   
   • 解决方案：使用box-sizing: border-box;样式来确保元素的宽度和高度包括内边距和边框。
   
   
   
   


6. 
   

   CSS选择器差异：

   
   
   
   
   • 解决方案：避免使用过于复杂的选择器，尽量使用普通的类名、ID或标签名进行选择。如果需要兼容旧版浏览器，请使用Polyfill或Shim库。
   
   
   
   


7. 
   

   浮动元素引起的布局问题：

   
   
   
   
   • 解决方案：使用清除浮动（clear float）技术，例如在容器的末尾添加一个具有clear: both;样式的空元素或使用CSS伪类选择器（如:after）清除浮动。
   
   
   
   


8. 
   

   CSS3特性的兼容性问题：

   
   
   
   
   • 解决方案：使用CSS前缀来适应不同浏览器支持的CSS3属性和特效。例如，-webkit-适用于Chrome和Safari，-moz-适用于Firefox。
   
   
   
   

除了以上问题，还可能存在字体、渐变、动画、弹性盒子布局等方面的兼容性问题。在实际开发中，可以使用CSS预处理器（如Less、Sass）来减少浏览器间的差异，并借助Autoprefixer等工具自动添加浏览器前缀，以确保在各种浏览器下的一致性。

JavaScript常见的兼容性问题

以下是几个常见的 JavaScript 兼容性问题及其解决方案：

1. 缺乏对新JavaScript特性的支持：

   • 问题：某些浏览器可能不支持最新的JavaScript特性、方法或属性。
   • 解决方案：在编写代码时，可以检查特定的JavaScript特性是否受支持，然后使用适当的替代方法或实现回退方案。可以使用Can I use (caniuse.com) 等网站来查看浏览器对特定功能的支持情况。

2. 事件处理程序兼容性问题：

   • 问题：不同浏览器对事件处理程序的绑定、参数传递和事件对象的访问方式存在差异。
   • 解决方案：使用跨浏览器的事件绑定方法（例如addEventListener），正确处理事件对象，并避免依赖事件对象的特定属性或方法。

3. XMLHttpRequest兼容性问题：

   • 问题：旧版本的IE浏览器（< IE7）使用ActiveX对象而不是XMLHttpRequest。
   • 解决方案：检查浏览器是否支持原生的XMLHttpRequest对象，如果不支持，则使用ActiveX对象作为替代方案。

4. JSON解析兼容性问题：

   • 问题：旧版本的浏览器可能不支持JSON.parse()和JSON.stringify()方法。
   • 解决方案：使用json2.js等JSON解析库来提供对这些方法的支持，或者在必要时手动实现JSON的解析和序列化功能。

5. DOM操作兼容性问题：

   • 问题：不同浏览器对DOM操作方法（如getElementById、querySelector等）的实现方式存在差异。
   • 解决方案：使用跨浏览器的DOM操作库（如jQuery、prototype.js）或使用feature detection技术来检测浏览器对特定DOM方法的支持，并根据情况使用不同的解决方案。

6. 跨域请求限制：

   • 问题：浏览器的同源策略限制了通过JavaScript进行的跨域请求。
   • 解决方案：使用JSONP、CORS（跨源资源共享）、服务器代理或 WebSocket等技术来绕过跨域请求限制。

总结

跨浏览器兼容性是网站和应用程序开发中至关重要的一环。由于不同浏览器对CSS和JavaScript的解析和渲染存在差异，如果不考虑兼容性问题，可能会导致页面在不同浏览器上显示不正确、功能不正常甚至完全无法使用的情况。这将严重影响用户体验，并可能导致流失用户和损害品牌声誉。

1. 介绍

• 通常情况下，一个 Tomcat 站点由于可能出现单点故障及无法应付过多客户复杂多样的请求等情况，不能单独应用于生产环境下，所以我们需要一套更可靠的解决方案
• Nginx 是一款非常优秀的 http 服务器软件，它能够支持高达 5000 个并发连接数的响应，拥有强大的静态资源处理能力，运行稳定，并且内存、CPU 等系统资源消耗非常低
• 目前很多大型网站都应用 Nginx 服务器作为后端网站的反向代理及负载均衡器，来提升整个站点的负载并发能力.

小结：

• Nginx是一款非常优秀的HTTP服务器软件

• 支持高达50 000个并发连接数的响应

• 拥有强大的静态资源处理能力

• 运行稳定

• 内存，CPU等系统资源消耗非常低

1.1. Tomcat重要目录

1.2. 反向代理

 反向代理（Reverse Proxy）方式是指以代理服务器来接受 Internet 上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给 Internet 上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。

反向代理是为服务端服务的，反向代理可以帮助服务器接收来自客户端的请求，帮助服务器做请求转发，负载均衡等。

反向代理对服务端是透明的，对我们是非透明的，即我们并不知道自己访问的是代理服务器，而服务器知道反向代理在为他服务。

反向代理的优势：

• 隐藏真实服务器；
• 负载均衡便于横向扩充后端动态服务；
• 动静分离，提升系统健壮性。

Nginx配置反向代理的主要参数

• upstream服务池名{}
• 配置后端服务器池，以提供响应数据
2. proxy_pass http://服务池名
• 配置将访问请求转发给后端服务器池的服务器处理

1.3. 动静分离原理

服务端接收来自客户端的请求中，既有静态资源也有动态资源，静态资源由Nginx提供服务，动态资源Nginx转发至后端

服务端接收来自客户端的请求中，既有动态资源，也有静态资源。静态资源由ngixn提供服务。动态资源由nginx 转发到后端tomcat 服务器。

静态页面一般 有html,htm,css 等路径， 动态页面则一般是jsp ，php 等路径。nginx 在站点的location 中 通过正则，或者 前缀，或者 后缀等方法匹配。当匹配到用户访问路径中有 jsp 时，则转发给后端的处理动态资源的web服务器处理。如果匹配到的路径中有 html 时，则nginx 自己处理。 

1.4. Nginx 静态处理优势

1. Nginx处理静态页面的效率远高于Tomcat的处理能力
2. 若Tomcat的请求量为1000次，则Nginx的请求量为6000次
3. Tomcat每秒的吞吐量为0.6M，Nginx的每秒吞吐量为3 .6M
4. Nginx处理静态资源的能力是Tomcat处理的6倍

1.5. 吞吐量 / 吞吐率

吞吐量是指系统处理客户请求数量的总和，可以指网络上传输数据包的总和，也可以指业务中客户端与服务器交互数据量的总和。

吞吐率是指单位时间内系统处理客户请求的数量，也就是单位时间内的吞吐量。可以从多个维度衡量吞吐率：①业务角度：单位时间（每秒）的请求数或页面数，即请求数 / 秒或页面数 / 秒；②网络角度：单位时间（每秒）网络中传输的数据包大小，即字节数 / 秒等；③系统角度，单位时间内服务器所承受的压力，即系统的负载能力。

吞吐率（或吞吐量）是一种多维度量的性能指标，它与请求处理所消耗的 CPU、内存、IO 和网络带宽都强相关。

2. Nginx+Tomcat负载均衡、动静分离

1.部署Nginx 负载均衡器

关闭防火墙

systemctl stop firewalld

setenforce 0



安装

yum -y install pcre-devel zlib-devel openssl-devel gcc gcc-c++ make



useradd -M -s /sbin/nologin nginx



cd /opt

tar zxvf nginx-1.12.0.tar.gz -C /opt/



cd nginx-1.12.0/

./configure \

--prefix=/usr/local/nginx \

--user=nginx \

--group=nginx \

--with-file-aio \									#启用文件修改支持

--with-http_stub_status_module \					#启用状态统计

--with-http_gzip_static_module \					#启用 gzip静态压缩

--with-http_flv_module \							#启用 flv模块，提供对 flv 视频的伪流支持

--with-http_ssl_module								#启用 SSL模块，提供SSL加密功能

--with-stream



./configure --prefix=/usr/local/nginx --user=nginx --group=nginx --with-file-aio --with-http_stub_status_module --with-http_gzip_static_module --with-http_flv_module --with-stream



make && make install

ln -s /usr/local/nginx/sbin/nginx /usr/local/sbin/



vim /lib/systemd/system/nginx.service

[Unit]

Description=nginx

After=network.target

[Service]

Type=forking

PIDFile=/usr/local/nginx/logs/nginx.pid

ExecStart=/usr/local/nginx/sbin/nginx

ExecrReload=/bin/kill -s HUP $MAINPID

ExecrStop=/bin/kill -s QUIT $MAINPID

PrivateTmp=true

[Install]

WantedBy=multi-user.target



chmod 754 /lib/systemd/system/nginx.service

systemctl start nginx.service

systemctl enable nginx.service

2.部署2台Tomcat 应用服务器

systemctl stop firewalld

setenforce 0



tar zxvf jdk-8u91-linux-x64.tar.gz -C /usr/local/



vim /etc/profile

export JAVA_HOME=/usr/local/jdk1.8.0_91

export JRE_HOME=${JAVA_HOME}/jre

export CLASSPATH=.:${JAVA_HOME}/lib:${JRE_HOME}/lib

export PATH=${JAVA_HOME}/bin:${JRE_HOME}/bin:$PATH



source /etc/profile



tar zxvf apache-tomcat-8.5.16.tar.gz



mv /opt/apache-tomcat-8.5.16/ /usr/local/tomcat



/usr/local/tomcat/bin/shutdown.sh 

/usr/local/tomcat/bin/startup.sh



netstat -ntap | grep 8080

3.动静分离配置

（1）Tomcat1 server 配置

mkdir /usr/local/tomcat/webapps/test

vim /usr/local/tomcat/webapps/test/index.jsp

<%@ page language="java" import="java.util.*" pageEncoding="UTF-8"%>

<html>

<head>

<title>JSP test1 page</title>   #指定为 test1 页面

</head>

<body>

<% out.println("动态页面 1,http://www.test1.com");%>

</body>

</html>





vim /usr/local/tomcat/conf/server.xml

#由于主机名 name 配置都为 localhost，需要删除前面的 HOST 配置

<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false">

	<Context docBase="/usr/local/tomcat/webapps/test" path="" reloadable="true">

	</Context>

</Host>



/usr/local/tomcat/bin/shutdown.sh 

/usr/local/tomcat/bin/startup.sh 

4 Nginx server 配置

#准备静态页面和静态图片

echo '<html><body><h1>这是静态页面</h1></body></html>' > /usr/local/nginx/html/index.html

mkdir /usr/local/nginx/html/img

cp /root/game.jpg /usr/local/nginx/html/img



vim /usr/local/nginx/conf/nginx.conf

......

http {

......

	#gzip on;

	

	#配置负载均衡的服务器列表，weight参数表示权重，权重越高，被分配到的概率越大

	upstream tomcat_server {

		server 192.168.85.60:8080 weight=1;

		server 192.168.85.70:8080 weight=1;

		server 192.168.85.80:8080 weight=1;

	}

	

	server {

		listen 80;

		server_name http://www.wa.com;

	

		charset utf-8;

	

		#access_log logs/host.access.log main;

		

		#配置Nginx处理动态页面请求，将 .jsp文件请求转发到Tomcat 服务器处理

		location ~ .*\.jsp$ {

			proxy_pass http://tomcat_server;

#设置后端的Web服务器可以获取远程客户端的真实IP

##设定后端的Web服务器接收到的请求访问的主机名（域名或IP、端口），默认HOST的值为proxy_pass指令设置的主机名。如果反向代理服务器不重写该请求头的话，那么后端真实服务器在处理时会认为所有的请求都来自反向代理服务器，如果后端有防攻击策略的话，那么机器就被封掉了。

			proxy_set_header HOST $host;

##把$remote_addr赋值给X-Real-IP，来获取源IP

			proxy_set_header X-Real-IP $remote_addr;

##在nginx 作为代理服务器时，设置的IP列表，会把经过的机器ip，代理机器ip都记录下来

			proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

		}

		

		#配置Nginx处理静态图片请求

		location ~ .*\.(gif|jpg|jpeg|png|bmp|swf|css)$ {

			root /usr/local/nginx/html/img;

			expires 10d;

		}

		

		location / {

			root html;

			index index.html index.htm;

		}

......

	}

......

}

3. Nginx 负载均衡模式：

1. rr 负载均衡模式：

每个请求按时间顺序逐一分配到不同的后端服务器，如果超过了最大失败次数后（max_fails，默认1），在失效时间内(fail_timeout，默认10秒)，该节点失效权重变为0，超过失效时间后，则恢复正常，或者全部节点都为down后，那么将所有节点都恢复为有效继续探测，一般来说rr可以根据权重来进行均匀分配。

2. least_conn 最少连接：

优先将客户端请求调度到当前连接最少的服务器。

3. ip_hash 负载均衡模式：

每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题，但是ip_hash会造成负载不均，有的服务请求接受多，有的服务请求接受少，所以不建议采用ip_hash模式，session 共享问题可用后端服务的 session 共享代替 nginx 的 ip_hash（使用后端服务器自身通过相关机制保持session同步）。

4. fair（第三方）负载均衡模式：

按后端服务器的响应时间来分配请求，响应时间短的优先分配。

5. url_hash（第三方）负载均衡模式：

基于用户请求的uri做hash。和ip_hash算法类似，是对每个请求按url的hash结果分配，使每个URL定向到同一个后端服务器，但是也会造成分配不均的问题，这种模式后端服务器为缓存时比较好。

Nginx 四层代理配置：

./configure --with-stream



和http同等级：所以一般只在http上面一段设置，

stream {

	

    upstream appserver {

		server 192.168.80.100:8080 weight=1;

		server 192.168.80.101:8080 weight=1;

		server 192.168.80.101:8081 weight=1;

    }

    server {

        listen 8080;

        proxy_pass appserver;

    }

}



http {

......

7层代理与4层代理区别

总结

• Nginx 支持哪些类型代理？

1. 反向代理 代理服务端 7层方代理向代理 4层方向

2. 正向代理 代理客户端 代理缓存

3. 7层 基于 http,https,mail 等七层协议的反向代理

• 使用场景： 动静分离

• 特点：功能强大，但转发性能较4层偏低

• 配置： 在http块里设置 upstream 后端服务池： 在seever块里用location匹配动态页面路径，使用 proxy_pass http：//服务器池名 进行七层协议（http协议）转发

http {

    upstream backersrver [weight=   fail=   ...]

       server IP1: PORT1 [weight=   fail=   ...]

       ......

     }  



     server  {

         listen 80;

         server_name  XXX;

         location ~ 正则表达式 {

            proxy_pass  http：//backeserer;

            .......

            }

     }

     

}     

        

1. 4层 基于 IP+（tcp或者udp）端口的代理

• 使用场景： 负载均衡器 /负载调度器，做服务器集群的访问入口

• 特点：只能根据IP+端口转发，但转发性能较好

• 配置： 和http块同一层，一般在http块上面配置

stream {

    upstream backerserver  {

       server IP1:PORT1  [weight=   fail=   ...]

       server IP2:PORT2  [weight=   fail=   ...]

       .....

       }

       

       server {

         listen  80;

         server_name XXX;

         proxy_pass  backerserver;

}         

       

调度算法 6种

轮询 加权轮询 最少/小连接 ip_hash fair url_hash

会话保持
ip_hash url_hash 可能会导致负载不均衡
通过后端服务器的session共享来实现

Nginx+Tomcat 动静分离

• Nginx处理静态资源请求，Tomcat处理动态页面请求

怎么实现动态分离

• Nginx使用location去正则匹配用户的访问路径的前缀或者后缀去判断接受的请求是静态的还是动态的，静态资源请求在Nginx本地进行处理响应，动态页面通过反向代理转发给后端应用服务器

怎么实现反向代理？

• 先在http块中使用upstream模块定义服务器组名，使用location匹配路径在用porxy_pass http：//服务器组名 进行七层转发转发

反向代理2种类型

• 基于7层的协议http，HTTPS，mail代理
• 基于4层的IP+（TCP/UDP）PORT的代理

4层代理配置：

• 在http块同一层上面配置stream模块，在stream模块中配置upstream模块定义服务器组名和服务器列表，在stream模块中的server模块配置监听的IP：端口，主机名，porxy_pass 服务器组名

Nginx调度策略/负载均衡模式算法6种

 轮询rr    加权轮询weight     最少/小连接least     ip_hash      fair      url_hash    

配置在upstream 模块中        

Nginx如何实现会话保持

ip_hash     url_hash    

通过后端服务器session共享 

使用stick——cookie——insert基于cookie来判断    

通过后端服务器session共享实现        

为什么需要Optional

Swift中引入了可选项（Optional）的概念是为了解决在代码中对于某些变量或常量可能为nil的情况进行处理，从而减少了程序中的不确定性，使得程序更加稳定和安全。

什么是Optional

在Swift中，可选项的类型是使用?来表示的，例如String?即为一个可选的字符串类型，表示这个变量或常量可能为nil。而对于不可选项，则直接使用相应类型的名称，例如String表示一个非可选的字符串类型。

var str: String = nil

var str1: String? = nil 

Optional实现原理

Optional实际上是Swift语言中的一种枚举类型。在Swift中声明Optional类型时，编译器会自动将其转换成对应的枚举类型，例如：

var optionalValue: Int? = 10

// 等价于：

enum Optional<Int> {

    case none

    case some(Int)

}

var optionalValue: Optional<Int> = .some(10)

在上面的代码中，我们声明了一个Optional类型的变量optionalValue，并将其初始化为10。实际上，编译器会自动将其转换为对应的枚举类型，即Optional枚举类型的.some(Int)，其中的Int就是我们所声明的可选类型的关联值。

当我们在使用Optional类型的变量时，可以通过判断其枚举值是.none还是.some来确定它是否为nil。如果是.none，表示该Optional值为空；如果是.some，就可以通过访问其关联值获取具体的数值。

Optional的源码实现为：

@frozen public enum Optional<Wrapped> : ExpressibleByNilLiteral {

	case none

	case some(Wrapped)															 

}

• Optioanl其实是标准库里的一个enum类型
• 用标准库实现语言特性的典型
• Optional.none 就是nil
• Optional.some 就是包装了实际的值
• 泛型属性 unsafelyUnwrapped
• 理论上我们可以直接调用unsafelyUnwrapped获取可选项的值

Optional的解包方式

1. 可选项绑定（Optional Binding）

使用 if let 或者 guard let 语句来判断 Optional 变量是否有值，如果有值则解包，并将其赋值给一个非可选类型的变量。

var optionalValue: Int? = 10

// 可选项绑定

if let value = optionalValue {

    print("Optional value is \(value)")

} else {

    print("Optional value is nil")

}

可选项绑定语句有两个分支：if分支和else分支。如果 optionalValue 有值，if 分支就会被执行，unwrappedValue 就会被赋值为 optionalValue 的值。否则，执行 else 分支。

2. 强制解包(Forced Unwrapping)

使用!来获取一个不存在的可选值会导致运行错误，在使用!强制展开之前必须保证可选项中包含一个非nil的值

var optionalValue: Int? = 10

let nonOptionalValue = optionalValue!  // 解包optionalValue值

print(nonOptionalValue)                // 输出：10

需要注意的是，如果 Optional 类型的值为 nil，使用强制解包方式解包时，会导致运行时错误 (Runtime Error)。

3. 隐式解包（Implicitly Unwrapped Optionals）

在定义 Optional 类型变量时使用 ! 操作符，标明该变量可以被隐式解包。用于在一些情况下，我们可以确定该 Optional 变量绑定后不会为 nil，可以快捷的解包而不用每次都使用 ! 或者 if let 进行解包。

var optionalValue: Int! = 10

let nonOptionalValue = optionalValue // 隐式解包

print(nonOptionalValue) // 输出：10

需要注意的是，隐式解包的 Optional 如果 nil 的话，会导致 runtime error，所以使用隐式解包 Optional 需要确保其一直有值，否则还是需要检查其非 nil 后再操作。

总的来说，我们应该尽量避免使用强制解包，而是通过可选项绑定来处理 Optional 类型的值，在需要使用隐式解包的情况下，也要确保其可靠性和稳定性，尽量减少出现运行时错误的概率。

可选链（Optional Chaining）

是一种在 Optional 类型值上进行操作的方式，可以将多个 Optional 值的处理放在一起，并在任何一个 Optional 值为 nil 的时刻停止处理。

通过在 Optional 类型值后面跟上问号 ?，我们就可以使用可选链来访问该 Optional 对象的属性和方法。

class Person {

    var name: String

    var father: Person?

    init(name: String, father: Person?) {

        self.name = name

        self.father = father

    }

}

let father = Person(name: "Father", father: nil)

let son = Person(name: "Son", father: father)



// 可选链调用属性

if let fatherName = son.father?.name {

    print("Father's name is \(fatherName)") // 输出：Father's name is Father

} else {

    print("Son without father")

}



// 可选链调用方法

if let count = son.father?.name.count {

    print("Father's name has \(count) characters") // 输出：Father's name has 6 characters

} else {

    print("Son without father")

}

在上面的代码中，我们定义了一个 Person 类，并初始化了一个包含父亲（father）的儿子（son）对象。其中，父亲对象的father属性为nil。我们使用问号 ? 来标记 father 对象为 Optional 类型，以避免访问 nil 对象时的运行时错误。

需要注意的是，如果一个 Optional 类型的属性通过可选链调用后，返回值不是 Optional 类型，那么在可选链调用后，就不再需要加问号 ? 标记其为 Optional 类型了。

class Person {

    var name: String

    var age: Int?

    init(name: String, age: Int?) {

        self.name = name

        self.age = age

    }

    func printInfo() {

        print("\(name), \(age ?? 0) years old")

    }

}

let person = Person(name: "Tom", age: nil)



// 可选链调用方法后，返回值不再是 Optional 类型

let succeed = person.printInfo() // 输出：Tom, 0 years old

在上面的代码中，我们定义了一个 Person 类，并初始化了一个包含年龄（age）的人（person）对象。在可选链调用对象的方法——printInfo() 方法后，因为该方法返回值不是 Optional 类型，所以 returnedValue 就不再需要加问号 ? 标记其为 Optional 类型了。

Optional 的嵌套

将一个 Optional 类型的值作为另一个 Optional 类型的值的成员，形成嵌套的 Optional 类型。

var optionalValue: Int? = 10

var nestedOptionalValue: Int?? = optionalValue

在上面的代码中，我们定义了一个 Optional 类型的变量 optionalValue，并将其赋值为整型变量 10。然后，我们将 optionalValue 赋值给了另一个 Optional 类型的变量 nestedOptionalValue，形成了一个嵌套的 Optional 类型。

在处理嵌套的 Optional 类型时，我们需要特别小心，因为它们的使用很容易造成逻辑上的混淆和错误。为了解决这个问题，我们可以使用 Optional Binding 或者 ?? 操作符（空合并运算符）来降低 Optional 嵌套的复杂度。

var optionalValue: Int? = 10

var nestedOptionalValue: Int?? = optionalValue



// 双重可选项绑定

if let nestedValue = nestedOptionalValue, let value = nestedValue {

    print(value) // 输出：10

} else {

    print("Optional is nil")

}

// 空合并运算符

let nonOptionalValue = nestedOptionalValue ?? 0

print(nonOptionalValue) // 输出：Optional(10)

在上面的代码中，我们使用了双重可选项绑定来判断 nestedOptionalValue 是否可绑定，以及其嵌套的 Optional 值是否可绑定，并将该值赋值给变量 value，以避免 Optional 值的嵌套。另外，我们还可以使用 ?? 操作符（空合并运算符）来对嵌套的 Optional 值进行默认取值的操作。

需要注意的是，虽然我们可以使用 ?? 操作符来降低 Optional 值的嵌套，但在具体的实际应用中，我们应该在设计时尽量避免 Optional 值的嵌套，以便代码的可读性和维护性。如果对于某个变量来说，它的值可能为空，我们可以考虑使用默认值或者定义一个默认值的 Optional 值来代替嵌套的 Optional 类型。

学习 Swift，勿忘初心，方得始终。但要陷入困境时，也不要忘了最初的梦想和时代所需要的技能。

概述

这是一个关于业务模块与路由权限的管理方案，用于增强在模块化架构场景下，业务模块的健壮性。

• 通过对App生命周期的转发，来解除App入口与业务模块管理逻辑的耦合。
• 通过协议来管理API路由，通过注册制实现API的服务发现。

业务模块

重新组织后，业务模块的管理会变得松散，容易实现插拔复用。

协议

public protocol SpaceportModuleProtocol {

   var loaded: Bool { get set}

   /// 决定模块的加载顺序，数字越大，优先级越高

   /// - Returns: 默认优先级为1000

   static func modulePriority() -> Int

   /// 加载

   func loadModule()

   /// 卸载

   func unloadModule()



   /// UIApplicationDidFinishLaunching

   func applicationDidFinishLaunching(notification: Notification)

   /// UIApplicationWillResignActive

   func applicationWillResignActive(notification: Notification)

   /// UIApplicationDidBecomeActive

   func applicationDidBecomeActive(notification: Notification)

   /// UIApplicationDidEnterBackground

   func applicationDidEnterBackground(notification: Notification)

   /// UIApplicationWillEnterForeground

   func applicationWillEnterForeground(notification: Notification)

   /// UIApplicationWillTerminate

   func applicationWillTerminate(notification: Notification)

}

特性

• 实现模块加载/卸载保护，模块只会加载/卸载一次。
• 同一个模块的注册是替换制，新模块会替代旧模块。
• 提供模块优先级配置，优先级高的模块会更早加载并响应Application的生命周期回调。

最佳实践

@UIApplicationMain

class AppDelegate: UIResponder, UIApplicationDelegate {

   var window: UIWindow?

   func application(_ application: UIApplication, didFinishLaunchingWithOptionslaunchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {

       setupModules()

// ......

       return true

   }

 

   func setupModules() {

       var modules: [SpaceportModuleProtocol] = [

           LoggerModule(),             // 4000

           NetworkModule(),            // 3000

           FirebaseModule(),           // 2995

           RouterModule(),             // 2960

           DynamicLinkModule(),        // 2950

           UserEventRecordModule(),    // 2900

           AppConfigModule(),          // 2895

           MediaModule(),              // 2800

           AdModule(),                 // 2750

           PurchaseModule(),           // 2700

           AppearanceModule(),         // 2600

           AppstoreModule(),           // 2500

           MLModule()                  // 2500

       ]

#if DEBUG

       modules.append(DebugModule())   // 2999

#endif

       Spaceport.shared.registerModules(modules)

       Spaceport.shared.enableAllModules()

   }

}

协议路由

通过路由的协议化管理，实现模块/组件之间通信的权限管理。

最佳实践

实现API协议

protocol ResultVCRouterAPI {

   @MainActor func vc(from: ResultVCFromType, project: Project) throws -> ResultVC

   @MainActor func vcFromPreview(serviceType: EnhanceServiceType, originalImage:UIImage, enhancedImage: UIImage) async throws -> ResultVC

}



class ResultVCRouter: ResultVCRouterAPI {

   @MainActor func vc(from: ResultVCFromType, project: Project) throws -> ResultVC {

       let vc = ResultVC()

       vc.modalPresentationStyle = .overCurrentContext

       try vc.vm.config(project: project)

       vc.vm.fromType = from

       return vc

   }



   @MainActor func vcFromPreview(serviceType: EnhanceServiceType, originalImage:UIImage, enhancedImage: UIImage) async throws -> ResultVC {

       let vc = ResultVC()

       vc.modalPresentationStyle = .overCurrentContext

       try await vc.vm.config(serviceType: serviceType, originalImage: originalImage,enhancedImage: enhancedImage)

       return vc

   }

}

注册API协议

public class RouterManager: SpaceportRouterService {

   public static let shared = RouterManager()

   private override init() {}

   static func API<T>(_ key: TypeKey<T>) -> T? {

       return shared.getRouter(key)

   }

}



class RouterModule: SpaceportModuleProtocol {

   var loaded = false

   static func modulePriority() -> Int { return 2960 }

   func loadModule() {

     // 注册API

       RouterManager.shared.register(TypeKey(ResultVCRouterAPI.self), router:ResultVC())

   }

   func unloadModule() { }

}

使用协议

// 通过 RouterManager 获取可用API

guard let api = RouterManager.API(TypeKey(ResultVCRouterAPI.self)) else { return }

let vc = try await api.vcFromPreview(serviceType: .colorize, originalImage:originalImage, enhancedImage: enhancedImage)

self.present(vc, animated: false)

总结

我们的业务向模块化、组件化架构演化的过程中，逐步出现跨组件调用依赖嵌套，插拔困难等问题。

通过抽象和简化，设计了这个方案，作为后续业务组件化的规范之一。通过剥离业务模块的生命周期，以及统一通信的方式，可以减缓业务增长带来的代码劣化问题。

Git 是目前世界上最先进的分布式版本控制系统，而针对Git代码提交，我们一般对于记录描述怎么操作的呢？当我是个初入行的码农时，我希望你管我怎么提交，一般就几个字，我功能完成即可，例如：

git commit -m "调整修改"

当我开始变为资深码农，并且开始管理整个项目的代码质量以及规范时，看着年轻人提交的代码，你这都是个啥，啥叫调整修改。正如我们看着自己当年写的代码，充满怀疑，这竟然是我写的？

玩笑归玩笑，规范化的提交真是一个好习惯，在工作中一份清晰简介规范的 Commit Message 能让后续代码审查、信息查找、版本回退都更加高效可靠。

那么，快捷工具来了，commitizen/cz-cli。

Commit Message标准

标准包含Header，Body，Footer三个部分.

(): 

// ...



// ...

其中，Header 是必需的，Body 和 Footer 非必须。

1. Header
   Header 部分只有一行，包括三个字段：type（必需）、scope（可选）、subject（必需）

• type：用于说明类型。可分以下几种类型
• scope：用于说明影响的范围，比如数据层、控制层、视图层等等。
• subject：主题，简短描述。一行

• 
  
• Body

对 subject 更详细的描述。

• Footer

主要是对于issue的关联。

安装

官方意思验证了Node.js 12,14,16版本的Node，而我在18上无任何问题。

在本例中，我们将设置存储库以使用 AngularJS 的提交消息约定，也称为 traditional-changelog。还有其他适配器，例如cz-customizable。

• 首先，确保全局安装 Commitizen CLI 工具：

npm install commitizen -g

• 接下来，在项目中通过输入以下命令初始化以使用cz-conventional-changelog适配器:

# npm

commitizen init cz-conventional-changelog --save-dev --save-exact



# yarn

commitizen init cz-conventional-changelog --yarn --dev --exact



# pnpm

commitizen init cz-conventional-changelog --pnpm --save-dev --save-exact

注意: 如果要在已经配置过的项目里面覆盖安装，则可以应用强制参数--force。还要了解其它详细信息，只需运行 。commitizen help

上面的命令都干了什么呢：

• 安装了cz-conventional-changelog适配器模块
• 将下载配置保存到了package.json
• 将适配器配置也写入了package.json 

...

  "config": {

    "commitizen": {

      "path": "cz-conventional-changelog"

    }

  }

针对上面第三点适配器配置，你也可以建立一个.czrc文件，写入：

{

  "path": "cz-conventional-changelog"

}

• 使用

当我们提交代码时，就可以将`git commit`命令替换成`git cz`,或者别名`cz`,`git-cz`等等。

[扩展]在项目中本地安装

上边我们的操作其实可以看到，针对的是自己电脑本地项目，那么如果是多人项目，我们肯定希望每个人都能使用同样的规范，那么可以将命令集成到项目中，那么我们就不能全局安装了：

npm install --save-dev commitizen

在 npm 5.2+ 上，可以使用 npx 初始化适配器：

npx commitizen init cz-conventional-changelog --save-dev --save-exact

对于以前版本的 npm(< 5.2),使用项目内部命令即可：

./node_modules/.bin/commitizen init cz-conventional-changelog --save-dev --save-exact

然后，您可以在package.json文件中添加命令：

  ...

  "scripts": {

    "commit": "cz"

  }

这对所有项目使用人员比较统一化，如果他们想进行提交，他们需要做的就是运行npm run commit

[扩展]通过git commit强制提交

针对项目管理者，我们定了一个规范，但是没法指望别人会严格遵守，所以如何使用 git 挂钩和命令行选项将 Commitizen 合并到现有工作流中。这对项目维护者很有用，确保对不熟悉 Commitizen 的人的贡献强制执行正确的提交格式。

首先确保我们是采用项目中本地集成安装了commitizen，然后可以选取以下两种方式之一.

方法一：传统的 git hooks

针对自己使用，修改以下文件：.git/hooks/prepare-commit-msg

#!/bin/bash

exec < /dev/tty && node_modules/.bin/cz --hook || true

注意： 如果prepare-commit-msg文件是新建的，需要执行权限chmod 777 .git/hooks/prepare-commit-msg,否则：

方法二：husky

对于多用户，我们也可以借助husky来统一提交:

1. 安装husky

npm install husky -D



2. 初始化husky配置

npm pkg set scripts.prepare="husky install"

npm run prepare



3. 添加脚本，我们这边针对提交触发

npx husky add .husky/prepare-commit-msg "exec < /dev/tty && node_modules/.bin/cz --hook || true"

疑问： commitizen文档对于husky推荐利用package.json添加husky配置，但是我这边不起作用，后边研究一下原因。

注意： 一定慎重同时配置husky和本地git hooks，会重复执行。

全局安装

我们开发过程中，其实针对每个项目初始化适配器，不太友好，其实还可以全局配置。

全局安装commitizen和cz-conventional-changelog：

npm install -g commitizen



npm install -g cz-conventional-changelog

用户目录下创建配置文件（Mac下，Linux下同理）：

echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc

项目和全局都配置了适配器，将先以本地为主。

VS CODE

vs code中可以使用git-commit-plugin 插件，这里不过多扩展了。

访问原文

你的代码提交友好吗？ | DLLCNX的博客