作者归档:白宦成

关于白宦成

独立开发者, 自由职业者, 写作者

MySQLDump 导出部分数据

MySQLDump 导出部分数据

MySQLDump 是非常常用的数据库导出工具。不过,大部分时候,我们使用的都是 mysqldump -uuser -p database_name > database_name.sql

这样可以提供数据导出功能,但导出的数据会是全表数据,我们在导出数据的时候,如果希望导出部分数据,就需要借助于其中的 --where Flag,来实现导出部分数据.

此外,由于导出的数据是部分数据,因此,就涉及到需要指定导出时的表名,才能实现导出相应的数据,需要满足如下格式

mysqldump [OPTIONS] database [tables]

举个例子来说,假设我们需要导出数据库 wordpress 的 wp-options 表中的 ID 小于 20 的数据,则需要执行如下命令:

mysqldump --where="id < 20" wordpress wp-options

上述命令就实现了从数据库中导出符合特定要求的数据。

Next.js 实现动态引入,实现对非 SSR 组件的支持

Next.js 实现动态引入,实现对非 SSR 组件的支持

在使用 Next.js 进行开发的时候,会遇到某些组件是不提供 SSR 支持的(很正常,毕竟 SSR 是一个相对比较小众的应用场景。此外,某些组件会依赖浏览器环境的上下文),在这种情况下,我们需要一种方式来实现对非 SSR 组件的支持。

一般而言, 有两种方式,一种是使用 useEffects 来控制组件的载入,从而实现只在客户端层面加载组件,服务端渲染的时候就不再加载该组件。

另外一种方式是可以考虑借助于 Next.js 自带的 Dynamic Import 的特性,来完成组件的引入。

在使用层面比较简单,引入组件的方式从直接引入改为最外层套一层 dynamic 函数即可

import dynamic from 'next/dynamic'

const DynamicComponentWithNoSSR = dynamic(
  () => import('../components/hello3'),
  { ssr: false }
)

function Home() {
  return (
    <div>
      <Header />
      <DynamicComponentWithNoSSR />
      <p>HOME PAGE is here!</p>
    </div>
  )
}

export default Home

总结

这个问题的解决让我再次激起了对于 Next.js 的兴趣。过去因为不确定如何解决在浏览器和客户端环境下的问题,对于 Next.js 有些畏难;如今问题已解决,可以继续放心的使用 Next.js 了。

参考阅读

https://nextjs.org/docs/advanced-features/dynamic-import

那些影响你前端开发体验的问题(1)

那些影响你前端开发体验的问题(1)

最近在研究和体验一些 GitHub 上的前端项目,遇到了一些让人体验不佳的点, 这里梳理一些我遇到的,一方面是留存,记录那些让我体验不好的事情。另一方面警示自己在开发前端项目的时候应该注意一下开发体验,确保不会让别人在开发的时候也遇到这些问题。

1. 项目应该有文档

这是不少 GitHub 上面项目的普遍问题。现有的文档要么是以 Framework 生成的 Readme 为主,要么直接没有文档。

但没有文档对于后来者的开发其实非常不友好,比如几个常见问题:

  1. 如何启动一个 Server & 如何设置后台 API 的 Prefix?
  2. 项目的组织结构是什么样的?
  3. 涉及到的第三方服务应该如何配置?

上面这些文档是帮助后来者快速使用你的项目所必需的(换句话说,如果你要做开源项目,想要打造开源社区,这也是必要的)。

2. 项目控制算法复杂度

我在开一些前端项目的时候,明显会感到浏览器的响应变慢了,我以为是我的 Mac Mini 2012 性能不行。但我打开自己的博客,依然如丝般顺滑,我就明白了。问题不在于我的电脑性能跟不上,而是这个前端页面加入了大量的有用或无用的代码,使得 CPU 需要大量的计算。

虽然进入 SPA 的时代以后,我们开始将算力的使用从服务端往客户端转移,但也建议各位工程师控制自己项目的复杂度,不要一开网页,风扇就呼呼的转。浏览体验不好,还凸显自己的技术不行。

3. 使用 debuuger 调试,而不只是 console.log

在编译型语言当中,使用 Debugger 来进行调试是一项基本技能,因为需要在运行时去看不同的变量的值,以此来完成调试。

爆炸的 Console

但在前端领域,因为 console.log 的过于好用,大家开始习惯于使用 console.log 来打印变量,但对于大型项目来说,大量的 console.log 也会让你的项目输出许多无意义的内容,让整个项目的调试和开发受到阻碍。

总结

最近看项目,总结了三条自己觉得影响体验的点,后续随着看的项目的深入,会逐渐总结出更多影响体验的点,引以为鉴。

如何迸发灵感 – 写作

如何迸发灵感 – 写作

我的博客能够保持日更,主要来说,是有两方面因素:

对于写作的预期没有那么高

很多时候,我的写作都是要先取悦自己。所以我对于一篇博客的要求没有那么高,达到最低标准,300 字即可(这个也是微信公众号原创文章的要求),所以我不会有太多的心理压力,担心一篇文章是否足够完美。

拥有充足的灵感

我每天会看到大量的文章内容,这些文章内容可以激发我自己思考,并产生出新的灵感,通过这些新的摄入诞生的很多灵感都不够深刻,但确实可以写下我对这个问题的思考,并在后续的时间沉淀下,不断的重新思考、再次思考。

我常用的信息输入的平台:

  • InoReader
  • V2ex
  • Newsletter

如果你发现自己没有灵感,不妨试一试。

番茄钟的原教旨主义者

番茄钟的原教旨主义者

最近重读《番茄工作法》和《番茄工作法图解》,有一种预感,大家可能都用错了。大部分人用番茄工作法关注的是 25 分钟工作 5 分钟休息。但在我看来,这个可能是整个番茄工作法中最不重要的了,不同的人不同。你应该根据自己的实际情况来调整你的工作时长和休息时长。倒是背后的几张表格可能更重要。

番茄工作法中,包括三张表:「今日待办」、「活动清单」、「记录表」

今日待办记录了今天要做的事情和突发的紧急事项,用于指导你在一天中的工作;活动清单则类似于 GTD 当中的 Inbox,收集了所有要做的事情;记录表则是存储了任务的元数据,可以用来对自己进行分析和指导。目前市面上大部分的工具都集中在如何做好定时器。对于记录表、今日待办和活动清单都没有做的特别好。 Session 算是比较好的,对于这些任务的数据有了展示。但在我看来,这个依然不够有效。主要是这里的数据其实是最基础的,对于形成反馈优化我们的时间和工作没有太多的帮助。

在我看来,番茄钟的基础是 25 + 5 的模式,来让你集中 & 放松。但想要保证 25 ,是需要「今日待办」中的「计划外和紧急活动」来保障的。不然待来的结果是要么 25 分钟费了,中间干别的了;要么是你 25 分钟倒是用好了,但计划外事项和紧急活动丢了。

至于活动清单,倒是相对简单一些,是 Inbox 以及进行任务的预估。Inbox 无需多说。任务的预估对于构建番茄钟的系统来说非常重要,你的精力是有限的,将精力用在有限的事情上需要你明确自己的精力状态和能做的事情,以及对要做的事情有明确的预估,才不会出现大面积 Delay 的情况。

记录表则用来追踪这些原始数据,并搭配着「今日待办」和「活动清单」一起来构建一个反馈系统,得出优化的结论。

上述的这些是现在的番茄钟工具大多没有关注到的。这些工具更加关注 25 分钟这个时间,但其实这是最没用的。

这也是为什么我现在又回到了纸笔的方式来使用番茄钟。不过我的做法可能过于原教旨主义了。明明这些事情用工具可以更好的解决,但我确实找不到更好的工具了。所以回归纸笔了。

WordPress Contact Form 7 的正确用法

WordPress Contact Form 7 的正确用法

Contact Form 7在实际使用过程中,有些人为了简化表单的设计和使用,会选择直接在多个地方使用同一个表单,并通过页面选择器来实现不同的样式(常见于基于 Elementor 构建的页面)。

但这样会造成长期的可维护性问题:

  1. 每个页面单独写样式选择器来控制样式,且在样式命名方面没有习惯的话, 会导致页面的样式混乱,修改成本较高。
  2. 不同的页面的样式采用了相同的类名,在进行样式修改时,交接性极差。

如果想要解决这个问题,有两个方式:

  1. 规范页面样式类规范:不同风格和样式的按钮采用不同的类名,如(.blueBtn.yellowBtn);
  2. 多处使用的表单,采用复制的方式,而不是使用同一个表单:Contact Form 7 提供了 Duplicate 功能,可以非常方便的复制一个表单,并根据表单的位置来命名。降低配置表单的成本。
Duplicate 一个表单
从一封钓鱼邮件聊起:针对普通人的钓鱼邮件设计

从一封钓鱼邮件聊起:针对普通人的钓鱼邮件设计

收到了一封钓鱼邮件,刚好最近没有什么内容要写,就聊聊这一封钓鱼邮件。

我收到的这一封钓鱼邮件是这样的

接下来看看里面的钓鱼邮件设计的三个巧妙之处:

1. 针对独立域名的钓鱼邮件

我的对外的邮箱目前使用的是 bestony@linux.com 的邮件,而由于 Linux.com 邮箱设计,实际上并不会有一个邮箱给你使用,而是你可以选择一个邮箱地址,系统会将发送到这个地址的邮件自动转发给你,我将邮件转发到了我自己的 Google 邮箱当中。

所以实际上我收到的邮件有两种:以 gmail 地址收到的邮件和以 linux.com 地址收到的邮件。

可以看到,上面的这个邮件当中我的收信地址是 linux.com 的地址,而不是我的 gmail 地址。

这正是这封邮件设计的巧妙之处:为特定人群发送特定内容的钓鱼邮件。试问自己:如果你的 QQ 邮箱收到了上述的邮件,你会把他当成是企业给你发送的安全邮件么?显然不会,因为你知道, QQ 不会给你发送这样的邮件。

但如果你的邮箱刚好是一个自定义域名,且刚好你所在的企业的 IT 并没有拦截到这封邮件,那么这封邮件对于那些安全意识不高的人来说,马上就会中招。

2. 使用了一个内网的地址来降低警惕度

对于绝大多数人来说,可能对于内网地址和外网地址没感知。可能直接就点击进去了。但对于一些对于计算机网络略有耳闻的人来说,可能会熟记的一个地址是 192.168.0.1,这个地址被不少的路由器作为默认的地址和网关地址来使用,从而成为不少人的心中的安全地址。

邮箱中的 192.168.22.23 这个地址就会让一些人放下警惕,然后点击进去查看内容 —— 然后成功的掉进陷阱中。实际上邮件只是用内网地址来作为一个表面展示的文字,真正的链接地址是 http://szfdxled.com/function/uploadfile/20220412/20220412000529_78464.html#bestony@linux.com

这提醒了我们,如果邮件当中有链接,最好复制出来,而不是直接点进去(说不定别人替换了呢?)

3. 自动识别的邮箱域名

我点击链接进去以后注意到,他在顶部加入了对应的邮箱域展示和 Icon 的展示。设计的挺巧妙。

如果点击进去展示的是无关的域信息,可能你也不会点击进去查看。但如果展示的是你自己的邮件域,会进一步放松警惕(特别是你以为你点击进去的其实是 192.168.xxx.xxx 时)。

对于意识不太强,或者平时不常使用网页版的人来说,可能真的就直接输入账号密码登录了。我还试了试,如果把 URL 后缀的邮箱域修改了,还会自动替换邮箱域和对应的 icon(应该是抓的 favicon,但不知道为啥抓到的是这个。

不过,也有一些设计的比较蠢的地方

1. 用了 Reply To 的字段暴露了自己的信息

在看这封邮件的时候,我注意到他设定了 Reply To 字段。Reply To 当中暴露了自己的 QQ 邮箱。

然后我搜了一下,发现能搜到这个人,看起来似乎还像是正常使用的 QQ 号。。。如果是一个经验丰富的 Cracker ,可能会选择使用一个更加安全的沟通方式。

总结

这封钓鱼邮件中给我不少的启发,里面的一些设计也很有意思。但对于有充足安全意识的人来说,这些问题确实都可以规避掉,从而不受诈骗的影响。此外,Cracker 的产品设计值得我们学习,一些好的设计,确实可以帮助用户更省事。

灵感:信用卡助手

灵感:信用卡助手

我在听《知行小酒馆》第 35 期《E35 信用卡是危险的陷阱,还是好玩的工具?》时,听到了傅少爷的信用卡表单,突然有了一个灵感 —— 一个给个人的场景化信用卡助手。

现状

其实有很多不同的信用卡助手,比如 51用卡助手、微信自带的信用卡提醒等常见的信用卡管理软件。但大多核心关注几个功能:

  1. 免息期:帮你计算卡片的免息期,告知你不同的卡片的免息期是多少天?
  2. 还款日期:你的卡片的帐期是哪天、还款日是哪天、提前一天提醒你。

通过上面的功能,来实现尽可能的晚还款 & 尽可能的享受免息期。

问题

我自己过去用这些信用卡助手是非常方便的,因为对我来说,我只关注是否是在还款日期还款就行,对于免息期等没那么在意。在我看来,计算那些优惠属实是太麻烦了。但在听了这一期节目后,确实让我打开眼界。主卡副卡、不同场景下使用不同场景的卡,这些点确实是我之前没有考虑过的。

所以,能不能有一个按照场景来做卡片管理的信用卡管理工具?

需求

回到我的问题,那就推导出这个工具应该具备以下一些特性:

  1. 可以根据场景录入 & 推荐卡片:其实很多卡片是有自己适合的使用场景的 —— 比如 12306 的联名卡、山姆会员店的联名卡。在这些地方使用对应的联名卡,可以更好的获得优惠;因此这个工具应该可以根据一些方式快速筛选场景,然后推荐当前拥有的卡片。当然,如果卡多了,如何做的更简单好用也是一个问题。
  2. 记录免年费的条件,并提醒用户去消费:我自己其实信用卡不多,之前办的几张卡后续都直接退掉了。核心原因是我懒得记录这些免年费的条件,但如果有个工具帮我记录免年费的条件,并在场景推荐的时候,推荐使用还没有免年费的卡片来进行消费,那我就无需再记录免年费,可以同时拥有更多的卡片,合理规划卡片的用法。
  3. 自动计算免息期:这个确实是一个最常见且几乎所有卡片的管理软件都有的软件。我提这个功能更多是从一个更加场景化的用法来考虑:我们追求最大免息期是为了让现金尽可能最大化收益。而小额支出其实对于免息期没有那么高的要求。在这种情况下,我们可以针对大额支出自动推荐最适合的卡片,享受免息期最长的(这部分也需要平衡卡片的优惠,比如大额支出 + 场景优惠就需要优先推荐优惠覆盖范围内免息期最长的卡片)。

其他特性

剩下的这些特性,就属于不是那么的重要,但可以有的功能:

  1. 卡片筹划:比如在某些特定场景下,某些卡片就是有优势,但你确实没有,这种情况下可以看看推荐一些卡片。
  2. 帐期规划:各行的卡片的帐期其实是可以调整的,因此,可以由软件统一规划 & 调整帐期,选择将帐期分配到不同的时间段或集中在同一个时间段。从而可以实现还款日的集中 or 分散(对应着发工资后还款 or 每天都有一个最适合帐期的功能)。
  3. 积分规划 & 兑换:不同银行的积分的价值不同,可兑换的商品不同。可以定期提醒用户更新一次积分(每月),并推荐各银行值得兑换的商品。
  4. 活动推荐:爬虫爬取各卡片的优惠活动,并展示在工具内部。

商业模式

商业模式很重要,决定了这个事情能不能长期做下去。这个功能一看就不是一个小事 & 涉及到了长期更新数据。因此,一个合理的商业模式可以让这件事持续的做下去。

免费版

  1. 免费加入 2 张卡;
  2. 不提供活动推荐 & 积分筹划

付费版(一次性解锁)

  1. 无限卡片。

数据更新(月度订阅)

  1. 自动更新每月的积分兑换的商品 & 优惠活动。
关于 To B & To C 账号体系的设计问题

关于 To B & To C 账号体系的设计问题

钉钉账号是个人所有的么?

答案是「否」,钉钉账号表面上是你自己的账号,但在企业的逻辑当中,这是「企业授权给你使用的」,本质上,这些都是企业的资产,企业是有权处置这些资源的。你所说的、所看的、所做的,都是企业提供的资产,企业可以根据自己的需求来调整这些资源的所在位置。

为什么钉钉和我们使用的微信、QQ 不同?

这是钉钉的不同的一点,在钉钉当中,任何一个账号,都是有对应的租户的(除了你的个人租户)。租户才是资源的所有者,我们只不过是使用者。 而我们使用的微信、QQ 其实也不是我们的,在微信的用户协议当中写明了,我们所拥有的不过是微信账号的使用权。只不过,因为腾讯离我们很远,我们可以认为不会对我们执行任何操作(当然,实际上如果你发一些不和谐的内容,也会被设置为内容自见),但在钉钉中,租户的管理员可能就是我们身边的同事,在这种情况会更有「隐私」和企业所有的对比。

7.1.2 微信帐号的所有权归腾讯公司所有,用户完成申请注册手续后,仅获得微信帐号的使用权,且该使用权仅属于初始申请注册人。同时,初始申请注册人不得赠与、借用、租用、转让或售卖微信帐号或者以其他方式许可非初始申请注册人使用微信帐号。非初始申请注册人不得通过受赠、继承、承租、受让或者其他任何方式使用微信帐号。

综上所述,你的账号,并不属于你。

To D 是个什么鬼?

To D 是个什么鬼?

一直以来,创业圈都有 To B 和 To C 的两个赛道。而对于我目前所从事的事情来说,我愿意将之称之为 To Dev 业务(简称 To D)。

为什么是 To D?

在过去,很多时候企业的产品要么是针对 C 端用户,直接卖用户给广告商,我们称之为 To C;也有很多企业是通过为其他企业提供资源,来获取收益,我们称之为 To B 。

To Dev 的业务本质上都是 To B 的生意,因为 To Dev 本质上是在要求开发者背后的企业来进行相应的费用支付。

但 To B 往往会让人误以为这个场景很大,所以我常说 To Dev(或者是 To 小B)。

To B 走的是上层建设的路线,产品往往是由上层确认,下发至业务团队,业务团队直接使用。举个例子来说,小米使用的是阿里云,原因是从集团层面看到阿里云很好用,所以我们批量采购,大家直接使用。

To Dev(To 小B)则是一个相反的路线,走的是农村包围城市。通过提供优质的产品,来促使开发者使用产品、离不开产品、为产品付费。

为什么会是这个路线?

过去,我们看到大量的大企业在使用 To B 产品。但随着 To B 时长的不断发展,越来越多的企业已经完成了 To B 的业务的采购,在这个时候,再想通过 To B 的方式来完成资源的购买,是十分困难的,因为已经被占位了。

在这种情况下,我们就要开始去观察那些还在成长的市场,比如初创团队、新产品团队。对于这些团队来说,他们一方面依然可以采用之前采购的资源。但同时,之前采购的资源可能有着这样或者那样的问题,让团队成员困扰。而新的解决方案可以更加简单的解决问题之时,这样的团队便有动力去试用这样的产品。

而这样的团队注定是如繁星一遍,遍布各个地区,传统 To B 场景下的销售就不适用了, ROI 太高。则需要在产品体验方面做到极致,让开发者可以更愿意选择自己的产品。

为什么我不看好 ClubHouse 模式

为什么我不看好 ClubHouse 模式

我因为 NESHouse 为不少人所知,而我播客主播的身份让不少人找我问,你怎么看 ClubHouse?

我的一贯观点是,这种临场感很好,但也是一种限制,要求我必须在特定的时间点到达特定的地点。

而之前在飞聊中沟通过,我不认为 ClubHouse 模式是可以与播客之类的相对抗,核心原因是其中的内容没有经过精心设计,在制作上很难产出精良的作品。

今天刚好看到了一个明确的案例:

知乎会将站内的信息组织成一个知乎周刊,而下面的截图就是知乎的一个周刊的截图。整个周刊看起来组织的井然有序,但当你真正的点开周刊的内容,却充满了不适。

比如说,「我比较同意李楠的看法」,那「李楠的看法」在哪里?读者看到这句话,丈二和尚摸不着头脑,又如何很好的读下去呢?

为什么硬件产品总有遗憾?

为什么硬件产品总有遗憾?

在做软件产品时,我们会无限的追求极致,希望将产品的体验、用法等各个方面全部做到最好,因为软件的交付成本低于硬件的交付成本,我们只需要一个命令,就可以将旧版的软件升级到新版。因此,我们可以通过不断的软件迭代,来将一个不完美的软件,迭代到完美的状态下。 而硬件则不同,硬件涉及到两个问题:

  1. 硬件存在供应链和备货的问题:这就会要求你必须提前采购物料,并进行研发。物料是实体的,必然会存在出问题的可能,因而会让我们的硬件设备出现各种各样奇奇怪怪的问题,天然就不太可能完美。
  2. 硬件存在升级成本的问题:硬件和软件的一个很不同的是,硬件往往是很难做到很好的升级的,想要升级,就不得不重新购买,而购买是需要花费金钱的。不是每个人都能购买新的设备的。而从厂商的角度来看,假设他做了一款完美的产品,他就无法再继续售卖同类型的产品,自然也没有动力去推出一款「完美」的产品

上述两个原因,导致我们永远不可能买到完美的硬件产品。