tag: 掘金翻译计划

原文地址：Monitor Spring Boot microservices 使用 Micrometer、Prometheus 和 Grafana 为 Spring Boot 微服务构建全面的监控能力 作者：Tanmay Ambre 发布时间：2020 年 3 月 11 日 介绍 在使用微服务和事件驱动架构（EDA）时，包括监控、日志、追踪和警报等方面的可观察性是一个架构十分重要的关注点，主要是因为： 大规模的部署需要集中且自动化的监控与可观测能力 架构的异步性和分布式性质使得关联多个组件产生的指标变得困难 解决这个架构问题可以简化架构管理，并加快解决运行时问题的周转时间。它还有助于做出明智的架构、设计、部署和基础设施，以改善平台的非功能特性。此外，自定义指标的产出、收集和可视化可以为业务或运营带来其他有用的信息。 然而在实际的架构应用中，这个问题经常被忽略。本教程通过使用 Micrometer、Prometheus 和 Grafana 等开源工具对 Java 和 Spring Boot 微服务的可观察性进行监控，相信会成为该方面最佳的实践指南。 先决条件 在你开始本教程之前，你需要设置以下环境： 拥有 Docker Compose 工具的 Docker 环境 一个用于克隆和编辑 git repo 中的代码的 Java IDE 预计时间 完成本教程大约需要 2 个小时。 监控概述 监控工具的主要目标是： 监控应用程序性能 为利益相关者（开发团队、基础架构团队、运营用户、维护团队和业务用户）提供自助服务。 协助进行快速问题溯源分析（RCA） 建立应用程序的性能基线 如果使用云服务，提供云使用成本的监测能力，并以集成的方式监控不同的云服务 监控主要体现在以下四类行为：...

发表自 Google Play 的产品经理总监， Paul Bankhead 我们不遗余力地关注 Google Play Store 的安全性和隐私， 以确保 Android 用户拥有发现和安装他们喜欢的应用程序和游戏的积极体验。 我们定期更新我们的 Google Play 开发者条款 ， 今天引入了更强的控制和新的策略来保持用户数据的安全。 以下是一些更新： ...

本文翻译自 https://medium.com/hackernoon/why-ai-is-here-to-stay-9c75b1868b9b ，本文的主旨是从人人交互过度到人际交互，帮助我们更好的理解什么是人工智能。但是不得不说，这篇文章是真的很难翻译，原文读起来大致可以理解，但是真想重新组织语言将文章翻译的有条有理真的好难啊，英语好的朋友可以自行阅读原文，之后我会努力提高自己的姿势水平，争取为大家带来更多优质的译文。 人机之间的沟通革命 如果你曾经参加过人工智能会议，我敢打赌你一定会遇到一个目光十分平静的镀铬机器人，这张图片是从一堆令人毛骨悚然的机器人图库中精心挑选的，以至于现如今，任何一个营销团队都无法拒绝在广告牌上贴出这张图。 很明显，我使用了玲珑蓝（octarine-blue）的科幻艺术配色来吸引疲惫的读者阅读我的博客，对此我感到十分抱歉。虽然这种方法十分奏效，不过遗憾的是，这些图像几乎与人工智能无关。 机器人技术令人振奋，但大多没有用处； 如今的人工智能大多无聊，但却非常有用。 也许你认为我们都应该为自己感到羞耻，但是不用担心，人工智能太有用了，以至于无论我们怎么喊“狼来了”，它都不会消失。理由如下。 人工智能为程序员提供了另一种方法，来告诉计算机要做什么事。 营销人员四处奔走，试图用科幻噱头来吸引你的注意力，但你长期在人工智能上消费的原因并不是因为这些噱头。真正的原因是与机器进行交流。 人工智能为程序员提供了另一种方法，来告诉计算机要做什么事。这种与机器交谈的新方式为何如此有用？为什么它会是一场技术革命？为了理解这些，让我们先暂时忘记计算机，然后把关注点放到人上面。我会摊开所有底牌，然后帮你揭开人工智能用途的层层迷雾。 人与人之间如何交谈 我们通过两种方式向别人表达我们的意愿。一个是通过明确的指令，另一个是通过举例。 如果你想学习如何预测我要点的星巴克订单，你可以在我的旅行中跟随我。你可能会注意到，我在美国机场会点一杯四盎司的浓缩咖啡，但是到了台北、孟买和内罗毕就变成了一杯拿铁。这是怎么回事？再举几个例子，你可能就能自己找出规律了。这就是人工智所要做的 —— 将实例转化为指令。如果你只看到我点了一两次星巴克（没有足够的数据），或者你只观察到 50 次我在街上同一个地方订购我常喝的卡布奇诺咖啡（无关紧要的数据，因为地点不是星巴克），那你将不可能把这些弄清楚。人工智能也是如此。 当然，我也可以把我的星巴克规则告诉你，因为表达起来非常容易：“如果他们有 B 奶（ half and half），点一中杯四盎司的浓缩咖啡，然后加满 B 奶（别批判我的喜好）。如果没有，那就点一份中杯拿铁。” Tips：星巴克的 B 奶是一半牛奶一半奶油的混合物，配方：是1份浓缩咖啡+0.75份热牛奶和0.75份鲜奶油混合+0.5份奶泡 这里的重点是，如果我教一个人类驴友，让他能够使用两种交流方式自然是非常好的。当明确的指令易于提出和表达时，我就可以像人们几十年来一直与电脑交谈一样为朋友编写程序：如果是这样的话，就那样做。 但如果我甚至不知道为什么我在纽约的某些日子点一杯卡布奇诺，而在其他日子点馥芮白呢？我不能给你公式，因为即使是我也不知道。但我想请你试试看，看你能不能找出规律。也许会有一个规律，也许没有，但你至少可以尝试着算出来，这很棒。没有机器学习或者人工智能，计算机就无法尝试找到一个模式。那样的话要么是明确的指示，要么就是失败。 人工智能是关于人类的自我表达。 也许你会发现在有些地凭方气味就能做到这些。你可能不知道为什么这样会有效（也许这种气味会引发一种与我父亲在去完剧院后喝卡布奇诺相关的感觉，但是你无法获得这些信息）但你会意识到，你能够准确预测我要做什么。最终，你会自信满满的说：“这次是白咖啡？我知道了。” 我会目瞪口呆地站在那里，因为我不知道你是怎么知道的。过一段时间我就不会担心了，我会相信你。只要我的偏好不变，你就会一直做对，即使我们都不知道为什么。 我给出明确指令这一过程是传统编程。我要求你学会从相关例子中学习,这才是机器学习和人工智能的本质。 所以这就是为什么人工智能并不是昙花一现：在现实生活中，如果我不能够聪明地提出指示，我就无法放弃依靠举例教学的能力。我很确定，当我在现实世界中磕磕绊绊时，我更多地是用例子而不是指令来与他人交流。 人工智能意味着我可以用第二种方式与电脑交流——通过例子——而不仅仅是指令，你是认真地要求我突然把自己的嘴塞住吗？请记住，在过去，我们必须主要依赖指令，只是因为我们不能用另一种方法来做，部分原因是，处理所有这些示例将使上世纪可怜的台式机的 CPU 不堪重负。 但是现在人类已经通过实例解锁了向机器表达自己的能力，为什么我们会突然完全放弃这个选择呢？这第二种与计算机交谈的方式太重要了，不能像昨日的垫肩那样抛弃掉。 我们应该放弃的是期望有一种通用的方式与计算机就每个问题进行通信。说出你的意愿，并以最佳方式说出来。有时你想要提供指令，有时你想要提供大量示例。 有些任务太复杂了，你无法记住它们的指令 因为人工智能允许你自动化处理那些无法言说的东西，就是在某些情况下我们只会做出唯一的选择，但我们却无法细化成特定的指令。你还不够聪明去弄清楚这些模式是什么意思，或者这些指令是如此的复杂以至于当你读到第七千行时你忘记了第一行。 计算机不介意记忆冗长乏味的示例集或指令手册。他们可以快速地浏览这些例子，即使这是一项你根本不想碰的任务。有些任务太复杂了，你无法记住它们的指令。当所有容易实现的任务都通过直接而明确的指令自动完成时，就需要处理复杂的任务。在那个领域，除了人工智能谁都做不了。 如果这些任务非常复杂，你可能无法完美地自动化它们，但是使用人工智能你仍然可以做得比什么都没做好（不要忘记建立安全网）。如果你确实获得了完美的表现，我的第一直觉就是想知道你的任务是否如此简单，以至于你真的应该以传统方式解决它。不要用人工智能转换美元和美分……说真的，你在做什么？！这就是你可能在面对复杂问题而求助于人工智能的老套路。这也是为什么人工智能的第一步是从任务开始，并反复检查没有人工智能你是否就不能解决它。这也是为什么人工智能的第一步是从任务开始，并反复检查没有人工智能你是否就不能解决它。 如果你渴望开始让 AI 对你有用，那么这里有一个指南，决策者应该在所有人甚至思考数据或技术细节之前阅读。

原文地址：From scratch to the first 10 customers: How I designed and launched a SaaS product 对于许多具有创业精神的程序员来说，创建一个成功的软件即服务（SaaS）产品是他们追求的梦想。在推出我自己的 SaaS 产品的过程时，我发现与其他创业者分享和探讨经验是必不可少的，如果没有这一点，我可能根本就不会想着去创建它。 在本文中，我将分享我从零开始创建 SaaS 产品的思路和实践过程，以及我是如何获得第一个付费客户的。无论是正在考虑创建一个新产品，还是已经推出了这个产品，你都可以通过对比自己的策略和文章中对我而言有效的策略，来调整适合你的策略 我每周会花 5 个小时研究其他创业者的经历。我一直在寻找新的想法以及避免错误的方法，评估新的策略可以帮助我获得具体的结果（即改进产品并增加客户满意度）。 出于这个原因，我决定以一种完全坦率和透明的方式工作，并分享我的道路上的一切 —— 包括什么已经起作用了，什么没有起作用 —— 目的是通过直接和理性的讨论互相帮助。 文章结构 这篇文章按时间顺序分为七个部分，下面是我所做的工作的每个阶段： 发现问题 量化问题 评估竞争对手和他们解决问题的方法 开发第一个原型 扔掉一切然后重新开始 获得第一个订阅 如何走得更远 我开发的 SaaS 产品是 Inspector，一个实时监控工具，可以帮助软件开发人员避免因程序技术问题而失去客户和资金。 发现问题 在过去的 10 年里，我一直与软件开发团队一起工作，在这期间，我意识到，对于开发人员来说，每天处理影响应用程序的技术问题非常复杂。开发团队与客户之间有着密切的关系，这对于生产软件的公司来说有很高的风险，因为一旦出现问题，你就会意识到这种联系是多么脆弱。 用户不喜欢出现问题！这是显而易见的，但这方面经常会被忽视。这是一个令人不安的事实。没有人喜欢遇到问题，本能的做法是把问题最小化。但如果你否认这一事实，你可能会惹恼客户，甚至会让他们重新考虑是否“应该”付钱给你。 客户是不会花时间向你报告问题和错误的。没有人会关心能否帮助我们解决 bug。它们只是退出我们的应用，可能要过好几年我们才能再见到他们。因此，我工作过的每个团队都使用最直观的方法来判断应用是否正常工作： “如果你的客户投诉你，就说明你的软件有问题。” 这并不是一个技术解决方案…… 紧迫、有限的预算，不断向客户、经理施压，这迫使开发人员必须顶着巨大的压力工作，采用权宜之计（暂时解决问题）这种生存策略。也许这看起来很荒谬，但只有深知项目内容的内部工作人员才会知道这些。这样的经历下工作了十年，我意识到这部分明显出现了问题。 量化问题 2019 年初，我刚刚完成了一些重要的项目，并希望能享受一段平静的时光。在过去的几年里，我利用这些时间寻找可以让我充分发挥自己技术才能的商机，希望以此找到合适的条件来启动我的商业想法。 作为一名开发人员，我的经验告诉我，通过简单而即时的监视工具足以帮助开发团队时刻了解应用程序最新的信息，不需要依赖客户的电话来知道软件什么时候出现了问题。另一方面，我不需要一个工具来监视每件事，因为并不是每件事都有意义。同时我也不希望它变得复杂——我不想仅仅为了这份工作而花一个月的时间学习它的工作原理，也不想为此雇佣专业的工程师。我的生活必须比以前更轻松。因此有必要准备一个随时可用的开发人员工具。 第一步是了解是否已经有尝试解决此问题的解决方案了，因此我谷歌了一下“application monitoring”，出现了 941,000,000 个结果：...

GraphQL 这个名词已经火了一段时间，但是一直没有体验过，无意中发现了一篇使用体验的文章，就想着翻译下分享给大家，如果翻译有问题的，还望批评指正。 原文地址：6 Months Of Using GraphQL 在使用 GraphQL 进行了 6 个月的后端项目开发后，我开始考量该技术是否适合在开发工作中使用。 首先 GraphQL 是一种实现 API 的查询语言，也是使用现有数据完成这些查询的运行时。GraphQL 为你的 API 中的数据提供了完整且易于理解的描述，并且让用户有权决定他们所需要的东西，仅此而已。 它由 Facebook 开发，作为其移动应用程序的内部解决方案，后来向社区开放了源代码。 优点 务实的数据交换 使用 GraphQL，可以为客户需要的字段指定一个查询，不多也不少。真的就是这么简单。如果前端只需要一个人的**名字和年龄字段，直接请求相应的字段就可以了。这个人的姓氏和地址**等其他字段不会返回在请求结果中。 使用数据加载器（Dataloaders）减少网络调用 虽然 Dataloaders 不是 GraphQL 库本身的一部分，但是它的确是一个很有用的第三方库，可以用来解耦应用程序中不相关的部分，同时不会牺牲批量数据加载的性能。虽然加载器提供了一个加载各个独立值的 API，但是所有并发请求都将被合并起来才分送给你的批处理加载函数。这使你的应用程序可以安全地在整个应用程序进行数据的分发与获取。 这方面的一个例子是，从另一个称为事务服务的服务中获取人的银行信息，后端可以从事务服务中获取银行信息，然后将结果与人的**姓名和年龄**结合起来后作为结果返回。 公开数据和数据库模型之间的解耦 GraphQL 的一大优点是可以将数据库建模数据和给用户公开的数据解耦。这样，在设计持久层时，我们可以专注于该层的需求，然后分别考虑如何采取最好的方式将数据暴露给使用者。这与 dataloader 的使用密切相关，因为你可以在将数据发送给用户之前将它们组合在一起，从而使得公开数据的设计模型变得非常容易。 忘记 API 的版本控制 API 的版本控制是一个常见问题，通常一个简单的解决方案是，在相同的 API 前面添加一个v2标识。但一旦有了 GraphQL，情况就不同了。虽然你仍然可以使用相同的解决方案，但这与 GraphQL 的理念不合。官方文档明确指出你应该改进你的 API，这意味着向已有端点添加更多的字段并不会破坏原有的 API。前端仍然可以使用相同的 API 进行查询，并且可以根据需要查询新字段。这种处理方式真的很巧妙。 在与前端团队协作时，这个特性非常有用。他们可以发出请求，并添加由于设计更改而需要的新字段，而后端可以轻松地添加该字段，同时不会破坏现有的 API。 独立团队 使用 GraphQL，前端和后端可以独立工作。因为 GraphQL 具有严格的类型化架构，因此两个团队可以并行工作互不影响。首先，前端无需查看后端代码即可轻松地生成数据模型，且生成的数据模型可以直接用于创建数据查询。其次，前端可以使用模拟（mock）出来的 API 来测试代码。这样便不会阻碍前后端的开发工作，大大的提升了程序员的开发体验。 缺点 并非所有的 API 都能改进 有时，会因业务或设计而产生一些变化，这需要对 API 的实现进行彻底更改。在这种情况下，你将不得不依靠旧的方式进行版本控制。...

使用 SVG 和 Vue.Js 构建动态树图 本文将会带你了解到我是如何创建一个动态树图的，该图使用 SVG（可缩放矢量图形）绘制三次贝塞尔曲线（Cubic Bezier）路径并通过 Vue.js 以实现数据响应。 在开始前，先让我们来看一个 demo。 基于 SVG 和 Vue.js 框架的强大功能，我们可以轻松创建基于数据驱动、可交互和可配置的图表与信息图。 该图是一个三次贝塞尔曲线的集合，它基于用户提供的数据，从单点出发，并在不同的点结束，且点和点之间的距离相同。 因此，该图会响应用户输入的内容。 我们将首先学习如何制作三次贝塞尔曲线，然后通过剪切蒙版在坐标系中尝试找到 <svg> 元素可用的 x 和 y 点。 我在这个案例中使用了很多视觉动画以保证趣味性。本文的主要思想是帮助你为类似的项目设计出自己的图表。 SVG Cubic Bezier 曲线是如何形成的？ 你在上面的 demo 中看到的曲线被称为三次贝塞尔曲线。我已在下面高亮显示了此曲线结构的每个部分。 它总共有 4 对坐标。第一对坐标 —— (x0, y0) —— 是起始锚点，最后一对坐标 —— (x3, y3) —— 是结束锚点，指示完成路径的位置。 中间的两对坐标是： 贝塞尔控制点 #1 (x1, y1) 和 贝塞尔控制点 #2 (x2, y2) 基于这些点实现的路径是一条平滑曲线。如果没有这些控制点，这条路径就是一条笔直的线！ 让我们把这四个坐标放入 SVG 语法的 <path> 元素中。 // 三次贝塞尔曲线的路径语法 <path D="M x0,y0 C x1,y1 x2,y2 x3,y3" /> 语法中的字母 c 代表三次贝塞尔曲线。小 c 表示相对值，而大写 C 表示绝对值。我用绝对值 C 来创建这个图。...

当所有的 flutter 开发人员都在制作可以在日常生活中被成千上万人使用的移动应用程序时，我呆坐在房间里，不禁陷入沉思，为何不做一款 flutter 的图标包呢 🤔 和平常一样，凌晨 3 点。我在网上搜索高质量的黑色主题包，想分享给一部分人，让他们觉得“嗯，你真厉害”。鉴于 GitHub 是新的社交媒体，我偶然发现了一个 “CSS” 库，我们学校最棒的一个程序员都曾给它点过赞（starred）。心想 “不妨深入地研究一下，看看这些字体是如何制作的。” 在浏览了几分钟资源文件夹中的文件后，我回想起有一次，我使用了一个名为 EvaIcons 的开源图标包。我访问了该包的 GitHub 地址，并开始阅读它的源码。和其他复杂的 flutter 包不同的是，这个 package 的结构相当简单。问题是，我应该看一个关于如何从 CSS 创建字体/图标并将其移植到 flutter 的教程吗？还是说我应该直接使用它，然后移植一小段代码看看是否有效? 开始 🏁 你需要做的第一件事就是找到一个包含 “.ttf” 文件的开源图标库。那 “.ttf” 是什么文件？ TTF 文件是由苹果公司创建的一种字体文件格式，但可以同时运行在 Macintosh 和 Windows 平台上。它可以调整到任何大小并且不会失真，而且打印出来的效果和在屏幕上显示的看起来是一样的。TrueType 字体是 Mac OS X 和 Windows 上最常用的字体格式。我不知道其他类似的格式如 “.svg”, “.eot” 或者 “.woff” 是否都可以使用。 我在 GitHub 上发现了一个名为 weather-icons 开源 CSS 图标库。这是一个包含了 222 个精美天气主题的图标库。 Flutter 包 📦 是时候来创建一个 flutter package 了。我们可以通过使用 Android Studio 这种老套而又略显笨拙的方法来创建一个 package，或者执行下面这个非常酷的命令。...

本文翻译自Data Visualization with Bokeh in Python, Part III: Making a Complete Dashboard 有时我会利用数据科学来解决特定问题。 其他时候， 我会尝试一种新工具， 比如说 Bokeh ， 因为我在 Twitter 上看到一些很酷的项目， 就会想： “那看起来很棒。 虽然我不确定什么时候会用到， 但迟早会有用的。 ”几乎每次我都这么说， 但是我最终都会找到这个工具的用途。 数据科学需要你掌握许多不同方面的知识， 你永远不会知道下一个你将使用的想法将来自哪里! 作为一名数据科学研究人员， 在试用了几个星期之后， 我终于在 Bokeh 的例子中找到了一个完美的用例。 我的研究项目 涉及利用数据科学提高商业建筑的能源效率。 在最近的一次会议上， 我们需要用一种方法来展示我们使用的众多技术的成果。 通常情况下都建议使用 powerpoint 来完成这项任务， 但是效果并不明显。 大多数在会议中的人在看到第三张幻灯片时， 就已经失去耐心了。 尽管我对 Bokeh 还不是很熟悉， 但我仍然自愿尝试利用这个库做一个交互式应用程序， 我认为这会扩展我的技能， 创造一个吸引人的方式来展示我们的项目。 安全起见， 我们团队准备了一个演示的备份， 但在我向他们展示了一部分初稿之后， 他们便给予了全部支持。 最终的交互式仪表板在会议中脱颖而出， 未来我们的团队也将会使用： 为我的研究构建的 Bokeh 仪表盘的例子 虽然说并不是每一个你在 Twitter 上看到的想法都可能对你的职业生涯产生帮助， 但我可以负责的说， 了解更多的数据科学技术不会有什么坏处。 沿着这些思路， 我开始了本系列文章， 以展示 Bokeh 的功能， Bokeh 是 Python 中一个强大的绘图库， 他可以让你制作交互式绘图和仪表盘。 尽管我不能向你展示有关我研究的仪表盘， 但是我可以使用一个公开的数据集展示在 Bokeh 中构建可视化的基础知识。 第三篇文章是我的 Bokeh 系列文章的延续， 第一部分着重于构建一个简单的图 ， 第二部分展示如何向 Bokeh 图中添加交互。 在这篇文章中， 我们将看到如何设置一个完整的 Bokeh 应用程序， 并在您的浏览器中运行可访问的本地 Bokeh 服务器!...

本文翻译自Frontend vs Backend: Which One Is Right For You?，如有疑问可在公众号「01二进制」后台回复「微信」和我联系 经常会有初学者来问我刚开始学习编程的时候应该学些什么？问这个问题就跟一个医学生询问应该专注研究哪个领域一样。根本没有一个标准答案。但我还是想提供一些指导，并就这个问题提出一些自己的看法。希望这篇文章可以给刚开始职业生涯的你一些值得思考的东西。 定义 在刚开始学习软件开发的时候，首先要经历的心理斗争就是我应该把关注点放在哪，前端还是后端？在我们深入了解两个领域的特征之前，我们先来看看它们的定义。 前端 指的是网站的表示层以及它与后端数据的交互方式。例如 HTML、CSS、JavaScript 和 Angular 等。 后端 指的是应用程序的数据处理层。这一层负责与数据库通信，并确定将哪些信息发送到要显示的前端。例如 Ruby、Rails、Python、Java 等。 好的，现在我们知道它们是什么了，但是你又该如何选择哪一个作为职业的方向呢？老实说，它取决于你的个人喜好以及你选择成为一个开发者的初衷。 职业满足感 如果你选择成为一名开发人员是因为你想获得职业满足感，并做一些你喜欢的事情，那么我的建议是，当你开始时，前后端都要做。同时涉猎前端和后端，这样你就能感受到你更喜欢的是什么。这么做会很辛苦吗？当然会，但是这也会极大地增加你找到喜欢做的事情的机会。 在前端和后端生态系统中，仍然有许多你可以选择并且能做得非常出色的专业。当你开始的时候，试着去了解一些基本的东西，不要太担心会沉迷其中。试一试水，看看当你用它的时候，其中一个方向是否真的能吸引到你。同时，你要意识到，无论你选择哪个，一开始都会很困难。我想说的是，在你决定要把重点放在哪里之前，给自己一年或两年的时间来研究整个流程。这将给你足够的时间来解决最初的“哇，这太糟糕了，因为它很难”的问题，同时还能让你真正评估它是否是你喜欢使用的技术。 虽然每个人都有不同的品味，但是看看其他开发人员喜欢使用哪些语言和技术也是很有趣的。2019 年 StackOverflow 调查了最受欢迎的语言。 前后端通吃的另一个好处是，你可以了解它们之间是如何协同工作的。无论你决定在未来关注哪个方面，这都非常有用。如果你了解另一半的工作原理，那么你就可以在项目中创建更好的代码和接口。 最后，当你在工作时横跨前后端，你可能会决定不进行选择了！你可能希望通吃前后端，并成为一个全栈工程师。这也是完全可以的！ 工资/稳定性 如果你从事开发的职业动机是为了工资和稳定，那么同时学习这两个方向可能是在浪费你的时间。如果你想尽快从事一行职业，那么就对你想从事的领域做一些调查。找出前端和后端的工资趋势。此外，尝试找出市场上最需要哪种类型的开发人员。 我不知道前端和后端哪个工资更高，但有一些调查试图回答这个问题。我们可以看看 2019 年 StackOverflow 的调查，该调查将开发者的薪资按类型进行了细分。 全球 全栈工程师 $57k 后端工程师 $56k 前端工程师 $52k 美国 后端工程师 $116k 全栈工程师 $110k 前端工程师 $103k 此外，它还根据技术细分了薪资。下面是每项调查的样本。 全球 Clojure $90k Go $80k Python $63k Swift $59k JavaScript $56k HTML/CSS $55k 美国 Scala $143k Clojure $139k Go $136k Swift $120k Python $116k JavaScript $110k HTML/CSS $105k 需要注意的是，这些工资和趋势可能会因你的工作地点和是否在寻找远程工作而有所不同。因此，你需要自己做好调查。这很简单，只需要查看求职公告板并搜索后端和前端技术，看看都有哪些。...

通过我的讲座和研讨会在与很多学生和开发人员亲自交流后， 我意识到他们中很多人都对 Flutter 和应用程序开发有共同的问题， 甚至还有误解。 因此我决定去写一篇文章来解释这些普遍的疑惑。 注意， 这篇文章旨在解释一些问题， 而不是对每个方面的详细表述。 为简洁起见， 我可能没有涉及到一些例外情况。 请注意， Flutter 本身也有一个针对各种背景下的常问问题页面 flutter.io， 在这里我将更多地关注我经常看到的问题。 虽然其中一些也包含在 Flutter 常见问题解答中， 但是我还是尝试着去给出我的观点。 布局文件在哪里？ / 为什么 Flutter 没有布局文件？ 在 Android 框架中， 我们将 Activity 分为布局和代码。 因此， 我们需要引用视图以在 Java 中使用它们。 （当然 Kotlin 可以避免这种情况。 ）布局文件本身用 XML 编写， 包含 Views 和 ViewGroups。 Flutter 使用一种全新的方法， 而不是视图， 使用 Widget。 在 Android 中， View 就是布局的一个组件， 但在 Flutter 中， Widget 几乎就是一切。 从按钮到布局结构， 所有的这些都是一个 Widget。 他在这里的优势是可定制性。 想象一下 Android 中的一个按钮。 它具有文本等属性， 可让你向按钮添加文本。 但 Flutter 中的按钮不会将标题作为字符串， 而是另一个 widget。 这意味着， 在按钮内部， 您可以拥有文本， 图像， 图标以及您可以想象的任何内容， 并且不会破坏布局约束。 这也让你可以很容易地制作自定义 Widget， 而在 Android 中制作自定义 view 是一件相当困难的事情。 ...