mou2xie (谢师傅)

从自己的需求出发，我写了个记单词的浏览器插件

mou2xie — Tue, 12 Dec 2023 23:43:01 +0800

需求来源

我前段时间备考雅思，为了提升单词量和阅读能力，我开始啃英语新闻。在阅读过程中，我迫切希望能有一个兼具翻译和记录功能的工具来帮助我记单词。

我的需求

能实现单词英译汉。
能播放单词读音。
翻译的同时不打断阅读。
不过多干扰原页面。
能记录单词。
操作简单。

我带着我的需求搜了下 chrome 商店，找到几个很不错的插件，使用了一阵，发现多多少少有不合心意的地方：

Burning Vocabulary

很有名气的老牌划词翻译软件，能划词翻译并记录单词。但是它每次翻译会自动记录单词，有些单词我只想看看意思，并不用记录下来；另外它会在单词下画很丑的波浪线，一篇文章如果标记得多，看着非常乱，影响阅读。
沉浸式翻译

这个不多说了，神器。但是它强于翻译，不太适合学英语这个场景。
侧边翻译

能翻译单词，侧边栏交互也深得我心。缺点就是操作有点不方便，也不能记录单词。

产品思路

最后我决定基于侧边栏特性自己做一个翻译工具，双击页面中的单词，唤出侧边栏显示释义，并可以选择是否标记单词。因为一篇文章，可能会频繁遇到生词，使用双击来触发翻译，足够快捷；侧边栏释义也能保证阅读不被打断，页面不受干扰。

开发

原型开发用了一个周末，过程倒没什么可说的，代码很粗放，也没有 UI，反正也就自己用，有字就行。后面空了就做一点 UI，优化一点逻辑，但因为又要上班又要学习，空闲时间少得可怜，进度一直很慢。直到考完试出了成绩，才好好抽时间捯饬了一下，最后发到线上。

后记

这个插件我自己用了小两月，雅思从 5.5 提到了 6.5，成功达到目标。我感觉这个插件也算有用吧（笑）。 chrome 商店地址：https://chromewebstore.google.com/detail/transider/iepaohcnkdejgafdmdifpepgpdbphhlo?hl=zh-CN&utm_source=ext_sidebar 欢迎试用和反馈。

又造了个 todo 的轮子

mou2xie — Mon, 22 May 2023 15:32:44 +0800

这两天给自己做了个小工具：just to do

这是一个简单（简陋）的 mac 桌面 todo 应用，用来随手记一下工作上的待办事项。

我是 flomo 和 notion 的用户，分别用来记录碎片化的思考和构建知识体系。在我的工作流中，刚好有一个 todo 的空缺。todo 类应用号称独立开发者的入门三件套（todo、记账、时钟）之一，appstore 上的 todo 应用可谓是汗牛充栋，其中有很多非常优秀的产品，但是对我来说，大部分产品都太重了，功能过剩。最后看来看去，我还是决定自己造个轮子。

（其实 google 的 keep 很对我胃口，可惜需要科学上网，不太稳定）

我的需求很简单：

1、只用做 todo，不用干别的。 2、小屏办公，空间有限，尽量不占屏幕空间。 3、就用来办公，不用分类、标签这些功能。 4、操作顺手。

产品需求简单，技术水平一般。开发用的 electron，不太熟，边学边做，好在大部分功能还是 web 实现的，没啥难度。稍微值得一说的是无意间搞出来的一个 feature——系统托盘显示/隐藏。

应用打开状态下，右上角工具栏会常驻一个小图标，只需要点击就能切换应用显示和隐藏状态，显示的时候还能自动获取输入框焦点，方便快速记录。我很喜欢这个小功能，算是超额实现了第二条需求。

这几天我自己用了一下，觉得挺顺手，如果有朋友和我一样，也需要一个简单的 todo 小工具，欢迎试试。

百度网盘链接: https://pan.baidu.com/s/17N10KH36SpN-5WpIgeKqmg?pwd=hv3o 提取码: hv3o

PS：目前只打包了 mac 平台，m1 和 m2 处理器的机器也许会有问题，要试试才知道；windows 我没法测试，不敢保证可用性。

有什么问题和建议，欢迎大家反馈。

微信小程序订阅消息避坑

mou2xie — Sat, 29 May 2021 22:16:29 +0800

微信小程序的订阅消息机制真的是一言难尽：当开发者申请向用户发送消息的时候，用户会收到一个弹窗，选择接收或者拒绝。但是每次申请，每次弹窗，对用户来说是一件很麻烦的事，于是微信官方贴心的加上了一个 “总是保持以上选择，不再询问” 的选项，当用户勾选这个选项之后，微信会保存用户的选择，之后会按照这个标准自动处理开发者的申请，对用户来说，省去了弹窗操作的步骤，是个好事儿；但是对开发者来说，麻烦就麻烦在这里。

当用户使用小程序的频率偏低的时候，一旦用户选择了 “保持以上选择，不再询问”，隔十天半个月再进来，谁还会记得上一次的选择是啥？更要命的是，万一这次用户需要提醒了，他甚至都看不到弹窗，无法更改之前的选择。PS：微信在小程序设置里提供了通知管理入口，但是在我对身边朋友（还是互联网圈内人士）的调研里，100% 的人都不知道，聊胜于无。

我觉得这很不合理，当程序自动处理开发者的申请时，应该告诉用户执行了什么操作；或者在拒绝时，给用户一个再次选择的机会。在参考了网上一些方案之后，我写了一套逻辑来处理这个问题，自觉得在功能和用户体验方面还算平衡得不错。

为了方便描述，用户在没有勾选 “保持以上选择” 的情况下选择接收或取决，我称之为一次性操作；反之，我称为持续性操作。

//订阅按钮绑定事件
subscribe:function(){
    let _this = this;
    //发起订阅请求
    wx.requestSubscribeMessage({
      tmplIds: ["Template_Id"],
      success:function(res){
        //返回操作结果
        if(res.Template_Id == "accept"){
          //当结果为“允许”时执行订阅消息方法
          _this.addUserToDatabase();
        }else if(res.Template_Id == "reject"){
          //当操作结果为“拒绝”时，有两种可能：一是用户一次性拒绝；二是持续性拒绝，要查看用户设置来分别处理
          wx.getSetting({
            withSubscriptions: true,
            success:function(res){
              if(res.subscriptionsSetting.itemSettings){
                //返回的subscriptionsSetting对象中如果存在itemSettings，说明用户对某些模版进行过持续性设置
                if(res.subscriptionsSetting.itemSettings.Template_Id){
                  //再看看itemSettings中有没有我们刚才请求的模板ID，如果有，说明用户对这个模板设置了持续性的reject，执行弹窗提醒
                  _this.openAuthorizeModal();
                }else{
                  //如果itemSettings中没有请求的模板ID，说明用户是一次性拒绝，反馈订阅失败
                  wx.showToast({
                    title: '订阅失败',
                    icon:"error"
                  });
                }    
              }else{
                //返回的subscriptionsSetting对象中不存在itemSettings，说明用户是一次性拒绝，反馈订阅失败
                wx.showToast({
                  title: '订阅失败',
                  icon:"error"
                });
              }
            }
          })
        }else{
          //当返回的操作结果为其他状态时统一提示订阅失败
          wx.showToast({
            title: '订阅失败',
            icon:"error"
          });
        }
      },
      fail:function(res){
        //如果用户关闭了消息主开关，将会通过fail返回，错误码20004
        if(res.errCode == 20004){
          //用户关闭了主开关，执行弹窗提醒
          _this.openAuthorizeModal();
        }
      }
    });
  }

  //订阅消息方法
  addUserToDatabase:function (){
    //订阅逻辑...
  }

  //打开提示弹窗
  openAuthorizeModal:function(){
    let _this = this;
    //打开弹窗
    wx.showModal({
      content:"您尚未开启消息订阅功能，是否去设置？",
      cancelText:"算了",
      confirmText:"设置",
      confirmColor:"#F64D46",
      cancelColor:"#9F9F9F",
      success:function(res){
        //用户点击“设置”，弹出设置面板
        if(res.confirm){
          wx.openSetting({
            withSubscriptions: true,
            success:function(res){
              //返回用户的设置结果
              if(res.subscriptionsSetting.mainSwitch){
                //如果消息主开关开启
                if(res.subscriptionsSetting.itemSettings){
                  //看看subscriptionsSetting中是否存在itemSettings，如果存在，说明用户对某些模版进行过持续性设置
                  if(res.subscriptionsSetting.itemSettings.Template_Id){
                    //看看itemSettings中是否有我们申请的模板，如果有，说明这个模板被用户进行过某种持续性设置
                    if(res.subscriptionsSetting.itemSettings.Template_Id == 'accept'){
                      //如果我们申请的模板的值是“accept”，说明用户持续性允许了接收该模版消息，提示用户去订阅
                      wx.showToast({
                        title: '请再次点击订阅按钮',
                        icon:"none"
                      })
                    }else{
                      //如果我们申请的模板的值不是“accept”，说明用户对模板设置了持续性不接收消息。表示理解，友好提示
                      wx.showToast({
                        title: '消息订阅未开启',
                        icon:"error"
                      });
                    }
                  }else{
                    //如果itemSettings中没有我们申请的模板，表示用户没有对我们申请的模板进行过任何持续性的设置，可以让用户去订阅
                    wx.showToast({
                      title: '请再次点击订阅按钮',
                      icon:"none"
                    })
                  }
                }else{
                  //如果subscriptionsSetting中不存在itemSettings，说明用户没有对任何模板进行过持续性设置，可以让用户去订阅
                  wx.showToast({
                    title: '请再次点击订阅按钮',
                    icon:"none"
                  })
                }
              }else{
                //如果消息主开关关闭，说明用户铁了心不想接收任何消息，保持风度，尊重用户的选择
                wx.showToast({
                  title: '消息订阅未开启',
                  icon:"error"
                });
              }
            }
          });
        }
      }
    })
  }

用户进入设置面板返回之后，可以视操作结果用 modal 引导订阅。但是我不喜欢频繁出弹层，所以没这么做。

另外，订阅结果里动态键的主意是谁想出来的？我想和你聊聊，心平气和的，嗯。

原文发于个人博客：http://mou2xie.site

一个卑微产品经理的业余开发小总结

mou2xie — Mon, 23 Nov 2020 16:30:21 +0800

周末参加了咱们社区的线上聚会，认识了才貌兼备的大佬，聊得很开心，我也从各位独立开发前辈身上学到了很多东西。想到平时在社区潜水成性，没啥贡献，深感羞愧，于是来写个帖子，一来补充聚会分享时漏掉的东西，二来也算是自己的一个小总结。

我是个文科背景的产品经理，现在在北京上班，身在大公司，一直拧螺丝，已经拧了 8 年。上班嘛，拿钱干活。好处当然是收入稳定，活下去有保证；坏处就是你得听话懂事，把自己变成一个麻木的工作机器。于是当工作上无法带来很大的成就感的时候，我就开始合计自己可以做点啥去弥补这种失落。

可能是受《社交网络》这些电影的荼毒，我身上有点极客情结，但是不懂技术怎么极客？其实从读大学开始，我就断断续续学习过编程，但始终浅尝辄止，做了几个 flash 的小玩意儿，没啥实践运用。工作之后，有机会接触到更多的技术，前端后端，各种语言。瞅来瞅去，我决定从 web 前端入手开始系统学习。一是上手快，二是前端写了就能看见，更容易获得成就感。（更容易出去装逼）

说来惭愧，学了挺久，真正开始做东西，却是去年才开始的。

第一个项目，是个纯静态的小程序。因为结婚要做个请柬，看了网上很多一键生成的工具，都是套模板，千篇一律没意思，于是就决定自己写一个。这个小程序没啥可说的，特别简单，但这既是一小步，又是一大步。特别推荐下 Aseprite 这个软件，是个专门画像素画的工具，这个小程序里的插画全用这个软件画出来的，简单好用。

可能是因为平时工作中没有 “亲手” 做出东西的机会，一旦开始就好像嚼了炫迈口香糖。很快我就开始了第二个小程序的开发，这次我的目标是搞出一个前后端闭环的小程序，能上线就成。

这是个词典类小程序，做流行语释意。灵感来自于我妈，她听她学生说，却不知道意思，来问我，我解答。于是我合计把这个流程搬到线上，在小程序上提问，我在后台看到，解答之后发布一个词卡，在小程序上能看到，完事儿。说句题外话，这个功能其实完全不需要做产品去实现，微信里直接对话省时省力。从需求层面这个小程序是站不住的，我做出来纯粹是个人技术实践。（也不能说完全站不住，有兴趣的朋友可以看看小鸡词典这个微信小程序，他们用社区的方式做，也有声有色的。）

在这个小程序的开发过程中，我极大的拓展了自己的技术栈，为了实现服务端，我学习了 nodeJS、express；使用 mongoDB 作为数据库；第一次拥有了自己的服务器，也第一次体会到备案的麻烦。拜万能的 google 所赐，遇到的问题最后都顺利攻克了。顺带一提，小程序请求必须使用 https 协议，逼得我不得不去申请 https 证书，并且部署 Nginx 来做请求跳转，这两个环节倒是意料之外的工作。

最后这个小程序顺利上线了。目标完成，我当然心情大好，没运营几天就磨拳霍霍想迭代了。人心情好的时候难免判断力会减弱。这次迭代，我加了个答题挑战的功能。现在想起来其实有点无聊，当时可能真是杀疯了。

我搞了一套题库，分为简单、中等、困难三个等级，进去答题之后，会根据得分给出一个挑战结果。其实也很简单，但是当时自己觉得不得了极了。

流行语词典运营了一段时间，用户累计到大概 1000 个左右，之后过了不久就关停了，也是因为技术实践的目的达到了，产品本身没太大意思。这个项目出乎意料的一点就在于提问，后台还有挺多人向我提问的，说明这个产品成功传播了出去。所以有些事，不去做真不知道。

这之后过不多久就闹新冠了，过完年在家闲着没事，我又开始合计做个啥。这次的目标现实又俗气——能不能用产品赚点钱呢？

对于我这种没啥商业资源、运营不强，技术能力也弱的，只能做点简单粗暴的业务，一筛选下来，最后我注意到了淘宝客。这里我先简单介绍下淘宝客的模式。淘宝客是带货拿佣金的玩法。在淘宝联盟注册之后，你可以分发商品的链接或者淘口令，这些商品会带上你的标识。当有用户通过你分发的链接或淘口令购买成功之后，经过一定的结算期，你就可以获得佣金，作为你帮忙推广商品的酬劳。淘宝客也有等级，如果你的业绩好，升到了高级之后，返佣也会相当可观。

因为在微信里传播淘宝商品容易遇到限制，稳妥起见，这次我选择了做支付宝小程序。支付宝小程序和微信小程序写起来几乎一样，开发过程中没遇到什么问题。值得一说的是在这个小程序上我尝试了 serverless，用了淘宝提供的小程序云开发功能（云函数、云数据库），免去了配置服务器、备案、环境调试的麻烦，很适合个人开发者和轻业务场景，推荐尝试。

小程序很快做好了，就一个商品列表页，一个商品详情页，能满足商品展示和复制淘口令的需求。一开始还规划接淘宝联盟的接口，实现商品自动上架，后面因为战线有点长，就砍掉了。取而代之，我用 VUE 简单写了个本地后台，能够实现通过 excel 上传和编辑商品，前期也够用。

这里还有个小插曲，既然没有接淘宝联盟的接口，我也没有必要用自己的淘宝客账号了。为了多赚钱，我直接用朋友的高佣账号搞商品在我这上架，这条路后面被证明是不通的，而且付出了沉重的代价。

差不多在这个产品上线的同时，噩耗传来，我们复工了。工作的时光总是愉快而又短暂，不知不觉过去了一周。某个晚上，我正在玩游戏，突然收到短信，一笔收入进账。（朋友给我开了个子渠道，并且做了短信提醒）我很诧异，想了好久才想起来，于是登陆后台看了看数据，出乎我的意料。这个小程序在完全没有任何推广的情况下，日访问用户竟然有 200 左右，全是通过支付宝搜索进来的。收入虽然微薄，但毕竟是睡后收入，自己的动力也变得充足了。从这天开始一直到下架，我一直记录着产品的数据，也每天维护产品的上新。

美好的日子注定短暂。不久之后的一天，朋友突然让我把所有商品全下了。淘宝冻结了他的账号，后面详细看规则才了解到，我这种（公然）挂羊头卖狗肉的行为是不允许的，被逮到了，只能认栽。惨重的是我损失了迄今为止所有收入（还没提现），朋友也被连带没收了一个月的收入。我很难过，主要是因为连累了朋友，太过意不去了。

接下来，老老实实用自己的账号做，我的是初级账号，收入少了很多，但好在心安理得。这期间和朋友吃饭，给他们看小程序，发现在某些 iphone 手机上，淘口令竟然无法复制！这可是个重大 bug，回家我立即修复了这个问题，然后提审。没想到竟然给我打回来了，说 “小程序命名过于宽泛”。我很纳闷，为啥第一次提审的时候你不说呢？我去修改名字，说有产品在审核中不让改。一气之下我把线上版本下架，重新提审，结果又说产品必须在线上才能修改名字，但是我一提审又因为名字问题给我打回来。这下我就很尴尬了。和客服纠缠了一段时间未果，正好这时公司有一个紧急项目，我必须全力以赴去做，于是我的支付宝小程序，就这样莫名其妙 “被下架” 了。

这一段经历也挺有趣，一来是支付宝小程序的流量意外的还不错，最高的一天竟然有 2400+UV。我至今也不知道都是谁在搜索、谁在使用，可能是疫情期间，很多人使用健康宝，培养起来了搜索小程序的习惯，才带来这么多流量。二是我想我找到了收入少的原因。在运营期间，我小程序列表页到详情页的转化只有可怜的 10% 左右，大部分用户没有进入详情页。我又回头看了列表页的停留时间，在 20 秒上下。由于我常年推荐的商品在 30 个左右，我自己试了试，浏览完这 30 商品差不多就是 20 秒，也就是说，用户是有浏览意愿的，但看完了列表也没找到心仪的商品，于是就走了，看来以后需要在选品、推荐环节加强一些，当然商品数量也需要更多点。最后，IOS 的 bug 造成的损失有多少，我没有仔细追查，但肯定也有影响。

现在，公司的项目基本告一段落，我也已经开始新小程序开发，这次邀请了一个后端的小伙伴加盟，短板得到了补足，祝我顺利吧。

这篇文章就先到这里，成文仓促，请各位海涵，有值得分享的东西我再同步，欢迎留言交流。