Yet Run 的小站
0%

发表于

导言

首先分享一下最近看的两本书：

  • 《Deep Learning with Python》
  • 《Hands-On Machine Learning with Scikit-Learn, Keras & TensorFlow》

两本书都到第三版了，阅读时请认准英文原版。

其中第一本书 DLWP 我已经基本读完，第二本 HOML 正在阅读。你可以理解为前者主要在讲 Keras，而后者可以深入到 TensorFlow。这样的阅读顺序我觉得挺好。

言归正传，这篇文章我想谈谈 Keras 的自定义组件，其主要思想来源于 HOML 的第 12 章。具体来讲，涵盖：

  • 自定义 Initializer
  • 自定义 Regularizer
  • 自定义 Constraint
  • 自定义 Activation Function
  • 自定义 Loss
  • 自定义 Metrics
  • 自定义 Layer
  • 自定义 Model

在这里面，有一些可以归纳出的点：

  1. 大多数情况下，可以只传递一个函数进去，Keras 会自动帮你处理这一切；
  2. 或者可以继承对应的类，每种组件都有其对应的类，一般要实现其 __call__ 或者 call 方法；
  3. 在模型保存和加载的阶段，我们还要为每个组件实现 get_config 方法；
  4. Metrics、Layer、Model 这三者除了 call 方法之外，还有其他的方法需要实现。

总之，这里面有许多东西需要处理和记忆，初看之下还会有些混乱。这篇文章就是在梳理这些内容。

由于篇幅有限，我只捡重要的讲。除了宣导之外，还能帮助我记忆。

阅读全文 »

发表于 更新于

众所周知，相比于 Vue 2，Vue 3 对于 TypeScript 的支持更加完善；但是，依然有一些不够完善的地方。至于有哪些不完善的地方，也不是一下就能说得出来，好像插槽算一个。不管哪一个，对范型组件缺乏支持是它逃不掉的一点。

我们在使用 UI 组件库的时候，像 Select、List 这样的组件，它们天然地不支持范型。这会让你在编写代码时丢失一些必要的类型信息。

阅读全文 »

发表于 更新于

这几篇写的都是有关于 watch 监听的，殊不知计算属性也有监听的味道在里面。类似于 watchEffect，计算属性会自动计算依赖，并依据依赖变化自动更新变量值。

1
2
3
const firstName = ref('')
const lastName = ref('')
const fullName = computed(() => firstName.value + ' '  + lastName.value)

接下来通过一个菜单组件的例子，介绍计算属性的浅监听可能带来的问题，以及如何克服这样的问题。但文章最后还是提出一个困扰，关于 Vue 提供的深度监听的特性和函数式思维的抉择是我们开发上的一个难点。

阅读全文 »

发表于 更新于

watch 通常只能监听值的改变，也就是我们平常所说的“浅”监听。如果要监听深层次的属性，需要加一个选项 deep: true. 但这时，如果监听的变量本身值的改变，和内部属性值的改变，都会触发监听函数。如果我们要区分这两种情况，需要用到一些手段。

阅读全文 »

发表于 更新于

问题背景

当组件需要响应路由更新的时候，有人提到可以用 watch(route) 方法。这个方法可以监听路由的一切变化。比如，对于一个文章组件，我们可以通过监听路由来达到重新获取文章的目的：

1
2
3
4
5
// 监听路由的变化。当我们的路由从 `/articles/1` 跳转到 `/articles/2` 时，下面的执行逻辑是正确的。
watch(route, async () => {
  const articleId = route.params.id
  article.value = await fetchArticle(articleId)
})

但是，请千万别这么用。此时组件不仅监听了当前组件路由的变化，也监听了别的组件的路由变化。当路由跳转到不属于当前组件的路由时，上述 watch 响应可能会触发，从而导致错误的执行逻辑：

1
2
3
4
5
watch(route, async () => {
  // 如果跳转到别的路由，比如跳转到 `/users/1`，此时获取到的 articleId 是错误的。
  const articleId = route.params.id
  article.value = await fetchArticle(articleId)
})

所以，请避免使用 watch(route)，因为它可能会监听到不属于自身的路由变化。

阅读全文 »

发表于 更新于

现实中为 Rails 添加参数验证的 Gems 很多，添加 Swagger 文档生成的也不少，但能够同时支持参数验证、返回值渲染和 Swagger 文档生成的少之又少，而且将这些能力紧密结合在一起的就几乎没有了。

大家伙在团队开发中，是否会有过这些困惑：

  • 缺少一个比较详细的 API 文档，有些甚至没有文档。
  • 文档和实现往往不一致，明明文档中说有这个字段，结果在实际调用时发现没有这个字段，或者反之。
  • 文档很难实现规约，比如参数集的字段与返回值的字段需要区分开来，以及不同场景下返回值的字段也应有所区分。所以，现实中往往只能抛出一个大而全的字段表放在 API 文档中。
阅读全文 »

发表于 更新于

常用的 TODO 标记列举如下（摘自Ruby Coding Style Guides）：

  • 使用 TODO 来备注缺失的特性或者在以后添加的功能。
  • 使用 FIXME 来备注有问题需要修复的代码。
  • 使用 OPTIMIZE 来备注慢的或者低效的可能引起性能问题的代码。
  • 使用 HACK 来备注那些使用问题代码的地方可能需要重构。
  • 使用 REVIEW 来备注那些需要反复查看确认工作正常的代码。

使用其他自定义的关键字，如果你认为它是合适的，但是确保在你的项目的 README 或者其他的地方注明。

发表于 更新于

主流的开放方式分为两种：以前端为主的前后端分离模式和以后端为主的全栈开发模式。Rails（全称 Ruby on Rails）是一个全栈开发框架，自然要用 Ruby 语言做更多的事。我在应用 Rails 实践的过程中，发现它的开发模式并不是有多种，只有一种。这一种，就是“基于模型验证的方式”。

阅读全文 »