ITPub博客

在 2010 年的世界移动大会上，谷歌 CEO 埃里克施密特提出，设计师在产品设计中应该遵循“移动优先”的原则。 “移动优先设计”是什么意思？ 它为什么如此重要？ 如何制作？ 我将在下面的部分回答这 3 个问题。 两个相关联的概念： 1. Responsive Web Design (RWD)响应式网页设计是一种网页设计方法，它使网页能够自动适应不同设备的屏幕，以人们感觉舒适的方式显示内容

(1) yarn build:libs 这个命令行是完成本地 library 的构建。需要将近10分钟。 (2) 这个命令是完成 shell app 的构建。 yarn build —prod 命令行里出现的 40.76 来自 .env-cmdrc 文件： 需要将近3分钟。 (3) 使用如下命令进行服务器端 shell 应用的构建： yarn build:ss

如果配置得当，我们可以将所有的内容都在服务器端渲染，避免在浏览器端再次调用 API. 首先命令行安装 Angular Universal： ng add @nguniversal/express-engine 执行命令行 npm run build:ssr browser：是执行命令行 ng build — prod 之后的结果。 server folder: 是执行

postman 是程序员经常使用的一个接口测试和验证工具。 我们在 postman 里点击下图按钮，能够在 Code Snippet 里，看到该接口调用对应的不同编程语言里的实现代码。 比如自动生成对应的 jquery 代码： 但是这些自动生成的代码，我发现并不能够直接复制粘贴了就能用。 比如上图我用 postman 调用的接口，使用的 HTTP 方法是 POST. 自动生成的

var express = require('express') var app = express() app.get('/', function (req, res) { res.send('hello world') }) app.listen(3000) 上面是一个最简单的 express 应用的例子。Applic

glitch 的中文翻译是格利奇，小差错？？？ 使用 glitch 的一大便利之处是可以省去本地搭建 web 开发环境的步骤，完成代码的自动部署，以及方便的将项目分享给其他朋友。这一切都发生在浏览器里。 点击 join today，可以直接用 Github 的用户名和账号登录。 使用 Github 账号登录，每个月的 free quota 是 1000小时： 每当一个项目被编辑时，或者

下面是我用 Cypress 开发的端到端测试。click 调用里的 force:true 参数是我后来加上去的。 如果不添加，会遇到错误消息： 在方法 $Cy.ensureAttached 里面跑出来的，这个方法位于 runner/cypress_runner.js 下面。 我想知道这个 cypress_runner.js 的本地位置： 本地请求的 url：http://loc

当我们的 Angular 应用程序部署到生产环境时，我们经常会遇到与我们在开发过程中编辑的不同的代码。我们的代码在构建过程中会以各种方式进行修改和优化。 TypeScript 被 transpiled, minified 和 uglifed。生成的 JavaScript 包尽可能小，并且能够在浏览器中运行。 所有这些概念都很棒，因为它们提高了我们应用程序的性能。但是，这也给生产系统的故障排查

这个错误消息的分析和解决方案，可以参考 Cypress 的官方文档。 这个错误消息提示我们，我们编写的 Cypress 代码正在同一个“死去”的 DOM 元素交互。 显然，在真实的使用场景下，一个用户也无法同这种类型的 UI 元素交互。 看个实际例子： <body> <div id="parent"> <button>

在 angular 中，通过不同的方式检测点击。 由于 click 是一个事件，因此在组件内部它是通过简单的事件绑定来检测的。 通过事件绑定在组件内进行检测的简单单击如下所示： @Component({ selector: "geeks", template: ` <h1 (click)="clicked()">{{ some_text

Angular 变化检测机制比 AngularJs 中的等效机制更透明且更易于推理。但是在某些情况下（例如在进行性能优化时），我们确实需要知道幕后发生了什么。因此，让我们通过以下主题深入了解变更检测： 如何实施变更检测？Angular 变化检测器是什么样子的，我能看到吗？默认的变更检测机制是如何工作的打开/关闭更改检测，并手动触发它避免变更检测循环：生产与开发模式什么是OnPush变化检测模

今年年初的时候，我收到了从 CSDN 社区寄出的这本台历：了不起的程序员 2021。 今天，这本厚厚的台历差不多已经快翻到封底了。2021 年的一天天就随着这一页页被翻去的台历而逝去了。又到了年底做年度总结的时候了。 这也是我连续第五年的年度总结。前四年的总结记录，在这四篇文章里： Jerry 的 2017, 编程与游泳 一个 SAP 开发人员的 2018 年终总结 一个 S

本文内容来自 SAP 社区博客：Calculation Engine (CE) Functions – Rest in Peace CE Function，即 Calculation Engine，是 HANA SPS02 中引入的一种机制，它允许直接访问 HANA 列存储。它们允许极其精确地控制如何精准投影、计算和聚合列。 事实上，它们是原始 HANA 列存储如何建模向量函数的直接表示。

SAP 再次荣获卓越职场颁发的「2020年大中华区最佳职场」奖项，也因为连续五年跻身这一榜单，SAP 由此摘取了「最佳职场」皇 冠上的宝石 —— 获得了「传奇企业」称号，成为在大中华区首批获此殊荣的公司之一。 作为在 SAP 研究院这个传奇企业内工作的开发工程师们，我们的工作和生活也当然同样精彩。 本文可以帮助大家了解一些 SAP 成都研究院小伙伴们的工作和生活片段。 下面是我以前的同事

我们在 Windows10 操作系统下，安装了 git 客户端之后，可以通过 git-bash.exe 打开一个 shell： 执行一些 linux 系统里的命令： 注意到上图紫色的 MINGW64. Mingw-w64 是原始 mingw.org 项目的改进版，旨在支持 Windows 系统上的 GCC 编译器。 它在 2007 年对它进行了分叉，以提供对 64 位和新 API 的支持

鼠标 hover 上去，看到提示信息：This test both passed and failed when retried within a run 何谓 Flaky test？Cypress 官网有如下定义： 当一个测试可以在多次重试尝试中通过和失败而没有任何代码更改时，它被认为是不稳定的。 例如，执行了一个测试并失败，然后再次执行该测试，代码没有任何更改，但这次它通过了。

(1) yarn install(2) 进到 storefrontapp-e2e-cypress 目录再次 yarn install(3) yarn build:libs 脚本命令： cypress run —config-file cypress.ci.json —record —key $CYPRESS_KEY —tag “2011,b2c,all,parallel” —par

分析入口，打开这个 build：有一个 build id 能查看到 Travis 上这个 build 有很多 job 组成： 我们查看其中名叫 E2E regression tests for B2B 的 job： 这个 job 定义在 .travis.yml 文件的 jobs 区域里： 我们在 travis 上点击这个 job 的超链接，打开 job 明细页面： htt

在 Github 项目文件夹下面添加 .travis.yml 文件。 为了运行构建，Travis CI 的系统将触发构建的存储库克隆到构建环境。 构建环境是一个隔离的虚拟机或 LXD 容器，一旦构建完成就会终止。 克隆仅在构建请求之后发生，因此仅适用于在 GitHub 设置中明确启用的存储库。 一个例子： 为了设置构建环境并准备构建，Travis CI 的系统从存储库和构建请求中明确指定

解释 Travis CI 的最简单方法是，每次提交到 GitHub 时它都会运行程序的测试（这可以通过多种方式进行配置，并且您始终可以在某些分支上禁用构建）。 这样做的重点是，你通常可以很快发现你的提交是否破坏了某些东西，并在它成为问题之前修复它。 我建议在每个有单元测试的 GitHub 存储库上运行 Travis CI，并且使用 Travis CI 支持的编程语言。 由于设置 Travis CI