应用创意:好宝宝

想设计一款应用,用来规范儿童的业余娱乐。

在带孩子的日常中,我遇到一些问题:

  1. 孩子喜欢看动画片、玩游戏,作为打了30年游戏的老游戏迷,我认为这是合理的
  2. 但是时间不好控制,主要体现在两点:
    1. 单次时间。我也贪玩,也有时候工作,所以并没办法一直看着他,经常一玩就是1个小时,我回过神来才去把板板关掉。
    2. 多次时间。有时候会给他规定,每天玩一个小时,自己好好吃饭奖励半个小时,不收玩具罚没半个小时等。但执行起来不好好记账根本就忘完了……
  3. 除了看动画片,还有很多其它东西想限制,比如买玩具。因为只有一个宝宝,所以身边所有人都给他买玩具,很难限制住。

所以,我想做这样一款应用,暂名好宝宝,是一个记账类型的产品,不过记账的目的是限制小朋友的娱乐内容和时间。

初级版

初级版基于 Android 手机和定时器,大部分功能和高级版通用,只不过交互形式是图片文字动画。

分为家长端和宝宝端,最好能够局域网互通,实在不行再搞中央服务器。

家长端

  1. 可以对项目内容、数量进行设置,比如“看电视”,“1小时”,“每天恢复1小时”等
  2. 可以设置任务,比如“收玩具”,“奖励看电视1小时”等
  3. 可以给宝宝评价,每天一次,1~5星
  4. 可以设置大任务,比如“收玩具15天”,“攒够100颗星”等

宝宝端

  1. 可以看到当前还有哪些权益可以享受
  2. 开始享受后,计时,到时间自动提醒,比如半个小时或者时间耗尽
  3. 可以展示任务进度
  4. 可以查看自己的打分日历

高级版

高级版基于智能音箱和家电控制。用于这样的场景:

“宅叔叔,我今天还能看电视么?”
“可以,亲爱的,你还能看‘一个小时’。你想继续看《帮帮龙》么?”
“是的,我要看。”

或者:

“宅叔叔,我要玩火车游戏。”
“不行哦,你已经不能再玩了。不过你爸爸说,如果你能‘把作业做完’,就可以多玩‘半个小时’。”
(做完作业后)“我作业做完了。”
“好的,请拿给你爸爸检查吧。(片刻)好了,可以了,玩得开心些。”

青少年版

当孩子长大,开始领月规钱的时候,也可以用这个软件自动划拨。

重振旗鼓

体重重回120kg高位,准备减肥。

自从2105年年底查出糖尿病之后已经过去了2年半,一开始剩勇犹在,坚持着运动了半年,直到2015年天气转热,然后就懒了。接下来体重就开始慢慢反弹,现在已经重回120kg高位。

看着春节在海边拍的照片,我决定不能这样了!既然老天爷给了我一次重来的机会,我不能轻易放弃!

于是我计划在接下来的大半年时间里,好好计划一下,加强体育锻炼。第一步,为锻炼留出时间:

  1. 取关段子手和营销号,减少花在刷微博上的时间
  2. 每天只刷一次煎蛋
  3. 每天只刷一次 NGA
  4. 晚上12:30关电脑,1点之前关手机;争取把睡眠时间调整到12点之前

接下来,锻炼身体:

  1. 每周日上午打篮球——上午人比较少,球技退化的我心理压力比较小
  2. 办一张游泳卡,每周至少游泳两次
  3. 遛狗的时候听书,不看手机,这样可以走的快一些,也顺带帮姆伊锻炼身体。另外遛狗的路线要加长。
  4. 晚上吃完饭后日常沉蹲+卷腹+俯卧撑

为了能够有足够多的听书资源,鉴于已经删了得到,应该:

  1. 安装微信读书
  2. 开发上次提到的“稍后再听”

随时提起干劲,争取用高昂的工作热情促使身体释放糖分

同时,管住嘴,告别一切零食加餐,只吃正餐。

希望能坚持到明年这个时候。

应用创意:以后再听

一款类似于 “Read it later” 的语音听书应用,可能找时间做个原型出来。

以前有个应用叫以后再读,Read it later,后来改名为 Pocket,我现在还在用。不过我的需求是以后再“听”,因为很多时候用眼不方便,比如开车、遛狗,都要用眼;而且白天写代码,感觉眼睛也挺累的,时不时就干涩几天,也想让它俩歇歇。

所以就希望有这样一款应用:

  1. 包含 Android iOS 浏览器插件
  2. 手机端支持微博分享和微信分享,只需要分享网页
  3. 分享后,进入转换队列,可以加标签和提醒
  4. 服务器端下载网页,提取主要内容,然后分段转换成语音
  5. 全部转换完成后,合并文件,然后推送提醒
  6. 直接打开应用,可以查看收藏、转换进度,听,等等
  7. 可以有分享

刚才搜索了一下,暂时没发现符合标准的应用。如果找不到的话,我就打算自己做了,哈哈。

Vue 小贴士

1. 使用 Vue + Webpack 开发 2. 使用 CDN 加载依赖 3. 在开发阶段尽量不要使用压缩的文件,一边取得尽量全面的错误信息

书说简短:

  1. 使用 Vue + Webpack 开发
  2. 使用 CDN 加载依赖
  3. 在开发阶段尽量不要使用压缩的文件,一边取得尽量全面的错误信息

继续阅读“Vue 小贴士”

Safari 下 Date 不支持”2018-01-01 00:00:00“

Chrome 可以支持非标准格式时间如 2018-01-01 00:00:00,safari 不支持,所以有时会导致错误。

前两天发现一个小程序的问题,Android 正常,iPhone 出错。我们都知道,Debug 的关键在定位,如果是某些特殊环节,不常见的错误,就会浪费很多时间。

这个 Bug 也是如此,反复拉锯之后终于发现,问题出在下面这句:

let a = new Date(`${date} 00:00:00`);

date 是服务器端返回的值,我是把它和后面的 00:00:00 连起来,记作某天零点零刻,和今天的零点零刻做减法,计算日期差,并按照日期差来决定接下来的逻辑。这段代码在开发工具(包括 Mac)、Android 手机上运行都正常,只有在 iPhone 上不正常,于是我打开 Safari——苹果这点做得不错,桌面版 Safari 环境和 iOS 几乎没有差别,该出的问题一定会出——果然复现了这个问题。

按照规范,中国的日期格式是:“2018/01/01”,Safari 只支持这个格式。而 2018-01-012018-01-01T00:00:00 ISO 格式,Safari 也支持,但是会以格林威治时间为准,和我们有8小时的时差。Chrome 和 Android 内嵌的 WebView(基于 Blink 或者 Webkit)则都支持,所以在本地和 Android 手机上没有问题。

日本@九州@福冈

回到福冈,准备回家。福冈跟其它大城市差不多,体验也差不多,值得一提的是门司港的九州铁道博物馆,很值得一去。

转了一圈,我们又回到福冈。查看地图的话,我们的行程是逆时针在北九州转一圈;只是因为想乘坐“SL人吉”号,所以往南九州走了一小截。

福冈是九州最大的城市,基本上,大城市嘛,就那个样子。可能不太一样的地方,就是干净、整洁,交通文明(说到这个,刚回来两天真是路怒啊,各种瞎MB开的)。按照既定计划,我们要在福冈待三晚,主要任务是逛街,穿和服拍照。可惜汇率不给力,老婆的逛街热情被消磨殆尽,索性带着小朋友去观摩九州铁道博物馆。

九州铁道博物馆位于门司港,本来还想着能坐到“阿苏Boy”号特色火车,结果国庆节又突然改线路,只好坐普通火车去。门司港是 JR 九州分部创立的地方,不远处就是关门大桥,曾经是连接九州与本州的要道,后来修通海底隧道之后,变成一节阑尾样的断头路。从福冈过来最简单的走法是做山阳新干线,不过我们用北九州 JR Pass 是不行的,所以只有先坐到小仓,然后换乘短途电车,其实也很方便,同台换乘,冲过去就开车,免费送惊险刺激。

博物馆不算大,不过玩的东西不少,对于小小火车迷来说各种火车头大火车小火车轨道车模拟驾驶仿古车厢,以及随便玩的火车玩具,简直如天堂一般。门票300日元,小朋友免费,也的确不贵。美中不足,就是我们完全不懂日文,本来当天有期间限定的“小小列车长”活动,小朋友们在整个博物馆寻找答题牌,答对问题盖章,然后就能获得纪念品,还能穿上专门制作的小号制服,去体验开火车的乐趣。这些不懂日文是玩不到了。不过小朋友不知道,其实也还好。

第二天就是和服拍照。到日本租和服拍照应该是常规项目,比较巧的是我们入住的酒店后面就有一家,通过邮件预订,到时候去就是了,大人4000,小朋友2500,做头发500,加起来7000日元,我觉得还可以。提供的和服也还不错,我觉得放到商场也得几千块。然则,走到櫛田神社,正准备大拍特拍,结果赶上本地望族办婚礼和相亲,到场的女士都穿着和服,年轻的姹紫嫣红,年长的黑底金丝刺绣,都特别漂亮,连小朋友的都很耀眼。比起来就是,我们好不容易穿上 Only 艾格,结果碰上穿 Chanel Prada 的……不知道租身那种档次的要多少钱。

晚上我还专门跑去吃有名的屋台。在河边,原本以为规模会很大,没想到翻来覆去就找到3家,而且似乎不打算接待外国游客,既没有中英文菜单,老板也完全不懂中英文的样子。于是我只是凑合点了几个关东煮、烧烤和拉面,味道还不错。


第二天,起床收拾一下,就回家咯,第一次日本之行,到此结束。

MySQL 的编码问题

解决字符集为 utf8_general_ci 的表里无法存储表情符号的问题。

前几天朋友的小程序遇到点问题,同样的代码,有些人就是注册不上,有些人就没问题。让我帮忙看。

看代码应该没问题,我自己试也没问题,很诡异。后来我发现,说注册不上的一个截图里,昵称里有一个雨滴的符号。我们知道,传统的编码是没有表情符号的,表情符号是 Unicode 后期才加进去的,那么会不会是数据库字段的问题?看了一眼,Laravel 默认创建的数据库,字符类型是 utf8mb4_unicode_ci,而他们数据库是 utf8_general_ci,Google 一下,找到下面这篇文章:

為什麼MYSQL要設定用UTF8MB4編碼 UTF8MB4_UNICODE_CI

里面提到:

當資料庫需要儲存或處理以下資料:emoji (手機端常用的表情字符)

应该使用 utf8mb4_unicode_ci,因为它会用更多的空间存储字符。基本锁定是字符集的问题。然后看到梦康大的一篇博文:直接使用 mysql utf8 存储 超过三个字节的 emoji 表情 ( 不使用 utf8mb4 ),决定参考他的方案,毕竟改库改表不是小事情。

不过时过境迁,梦康文中的 func_overload 已经可以用 mb_strlen($str, '8bit') 来替代,所以最后的代码大约是这样的:

// 替换
protected function encodeEmoji($input) {
  $length = mb_strlen($input, 'utf-8');
  $result = '';

  for ($i = 0; $i < $length; $i++) {
    $tmp = mb_substr($input, $i, 1, 'utf-8');
    if (mb_strlen($tmp, '8bit') >= 4) {
      $result .= '[[Emoji:' . rawurlencode($tmp) . ']]';
    } else {
      $result .= $tmp;
    }
  }
  return $result;
}

// 替换回
protected function decodeEmoji($nickname) {
  return preg_replace_callback('~\[\[Emoji:(.*?)\]\]~', function ($matches) {
    return rawurldecode($matches[1]);
  }, $nickname);
}

所以说,程序员心态要保持年轻,步调要跟年轻人保持一致,这样才更容易发现新问题,所以我的昵称已经改成“肉山🎩”了。