creation

App Store 链接 经过很长时间的设计、开发，「BACK 4U」终于上架啦🎉。...

新版本的 Palette 发布了，这次有了中文标题和描述。 这次还增加了许多可配置的新 Block，其中主要包括一个 Color Mixing 的模块，其 Block 包含自己可以存储调色板的 Palette Block，和一些可供挑选颜色的 Block。 Palette on the App Store...

可能是 Blog 发布流程太长太麻烦，导致我总是不太经常写 Blog，但这次我发现「快捷指令」可以把「Working Copy」的 Commit、Push、Pull 等操作集成起来，而且也可以使用 Taio 动作，于是行动起来。 在 Taio 动作中我写了两个动作，分别是创建 Post 和创建 News，在运行这个快捷指令时可以选择创建 News 还是 Post，如果是 Post，那还需要选择类别，类别列表通过「Taio」的获取目录可以获得现有的类别，否则也可以新建类别。 创建 Post 的动作可以接受一个输入参数，即类别。 这个打开链接就是打开根目录的 README.md 文件，后面的文件指令才能找到正确的路径。 运行 大功告成～ 剩下就是发 Blog 然后等着 GitHub Actions 去处理啦 把这几个 Blog 操作合成一个小组件，简单易用～...

这是一款很随意的 app，但这也是一款可以用 iPad 制作出来并可维护的 app。 链接在这里 楔子 当我第一次吃惊地发现 iPad 居然可以用 Playground 写一个 app 并上架到 App Store 时，于是脑海里瞬间浮现出无数个想法，然后立马去试试。 那时我完全没有接触过 SwiftUI，但是在我尝试试着在 iPad 上写一些代码时，借助 Playground 里的 code snippet，我竟发现 SwiftUI 原来现在已经发展到可以如此便捷高效地构建一个 app。 然后我就决定写一个颜色转换再加上可以配色的超简洁的 app。 说起颜色转换，我不止一次开发跟颜色相关的项目，上次是在钟大的 JSBox 里写了一个颜色转换的 script。 几年前，我曾做过一个叫「今天的颜色」的 app，它的功能非常简单，就是生成一个颜色，每天一个不同的颜色，同时还会把 logo 改成当天的颜色。却也是因为功能太简单，被 App Store 拒绝上架。时到今日，today’s color 的 block 在这个 app 会在未来某个版本安排一下～纪念一下。 Just Do It 4 月末，我开始了这个项目，经历了十几个版本的测试，也就大概十几天，上架了 App Store，在前几天还因为 App Store Connect 的服务不稳定稍稍拖慢上架速度。 在 iPad 上开发过程中，还是给了我以下几点不方便的因素： 难以调试，只允许做一个非常简单的项目，一旦复杂起来遇到不好解决的 bug 就得去 mac 上调试 搜索功能不够强大 性能不够，遇到较复杂的语句就无法编译，有时候会导致整个 Playground 卡住（可能是 bug）（就算是 M1 的 iPad 也性能不够，跟 mac 上的 M1 应该是缩水了的） 无法做本地化 等等… iPad 上开发 app 还有许多需要改善的地方，但这样的思路的确是一个相当好的思路，试想一下如果未来的 iPad 可以允许我们每个人轻松做一个游戏然后上架，每个人都可以把自己的想象发挥到极致而无需担心实现的难度，Apple 官方提供一套无版权的人物角色模型，类似现在的 SF Symbol。下一个时代是人人创作者的时代。...

在此之前 Telegram Bot 简明教程 I - 注册与发消息 收指令 python-telegram-bot wiki 页面 介绍了如何使用 Python 脚本实现与 Bot 交互。 以下是根据这个 wiki 页面编写的例程。 接收 /start 指令 from telegram import Update from telegram.ext import Updater, CallbackContext, CommandHandler token = '2110628450:AAHQ78uj42ddtdsx0gKfaZGyFUhpnQ13vyM' def start(update: Update, context: CallbackContext): context.bot.send_message(chat_id=update.effective_chat.id, text="Let's start!") # 或 # update.message.reply_text("Let's start!") if __name__ == '__main__': updater = Updater(token=token, use_context=True) #1 start_handler = CommandHandler('start', start) #2 updater.dispatcher.add_handler(start_handler) #3 updater.start_polling() #4 updater.idle() #5 首先根据 token 创建一个 updater 对象； 定义 start 函数，在函数体中实现给发指令的那个 chat_id 发送消息「Let’s start!...

Telegram Bot，简而言之就是运行在 Telegram 上的可交互的「机器人」，你可以给它发送指令让它完成操作或是实现一些功能（付钱、游戏等等），或者可以在 Channel 或 Group 中发送特定消息。 这是 官方介绍。它的主要原理就是开发者通过调用 Telegram Bot API 来实现接收指令、发消息以及实现各种功能。 注册 与 @BotFather 对话，发送指令 /start 开始，/newbot 申请一个新的 Bot 账号。 接着，BotFather 会要求你输入这个 Bot 的名字和 ID。创建完成后，BotFather 会同时给你一个 token，记住这个 token。 此时，已经可以和这个 Bot 互动了，但是想要这个 Bot 也可以主动发消息，这时就要建立一个 Channel，并把这个 Bot 设置为管理员。这个 Channel 如果是 public，其链接可以自定义。这里以 private 为例。 由于 Channel 是 private，我们需要这个 Channel 的 ID 来操作，这里可以通过将 Channel 内的消息转发给 @JsonDumpBot 来查看。可以看到此 Channel 的 ID 是 -1001790411176。 发消息 在官方文档的 Making requests 介绍中讲到，可以使用 GET 或 POST 请求以下 URL。...

从写好第一篇多图大图的 blog 那一刻起，我就一直在思考访问者如何快速加载这些图片提高阅读体验，因为这些图片动辄几兆甚至几十兆，而我又不希望压缩这些图片导致质量下降。 所以在以往的多图 blog 中，访问者往往要等待很久的加载时间。 既然是图片大小导致的「硬伤」，加载这些图片几乎都取决于访问者的网速，那么有没有办法从图片本身的角度出发，来优化这种加载时间？ 什么是渐进式 JPEG（Progressive JPEG） 我们知道，JPEG 格式是目前兼容性最高，使用范围最广的图片有损压缩格式。而其中的编码方式分为多种，这里主要讨论两种：Baseline JPEG 和 Progressive JPEG。 对于 Baseline JPEG，图片是从上到下一行行顺序存储的，因此在加载图片的时候能看到图片从上到下慢慢显现出来。 而 Progressive JPEG，图片会由模糊到清晰渐进式地分多次存储，因此在加载图片时看到的图片是由模糊到清晰渲染的。 图片来自「简书」 这种渐进式 JPEG 显然可以在图片未加载完全的时候就能看到它的「预览」，而且渐进式 JPEG 的文件大小要略小于 Baseline JPEG。不过渐进式 JPEG 在 Windows 7 以前的 IE 等浏览器不受支持，会在完全加载完成后才显示图片。 目前多图 blog 之所以加载时间很长，是因为这些图片存储的编码方式都是 Baseline JPEG。 🎬 于是，我在之前的 GitHub Actions 配置文件中补充了将这些图片转换为 Progressive JPEG 的命令，当前的 blog 在合并入主干分支后 GitHub Actions 会先使用 hugo 命令创建 HTML1，然后 Progressive JPEG 命令再将所有 JPEG 图片批量处理。 在 Linux 中，使用 ImageMagick 处理图片。其中的 -interlace 选项有提供将图片转换为 Progressive JPEG。...

🤔 当我们使用手机拍照时，按下快门的那一刻，程序会自动获取当前地理位置，并将其写入照片中。而当我们拥有海量包含地理位置并通过 iCloud 或者 NAS 管理的照片时，这些照片会被程序自动归类，因此可以省去大量整理照片的时间。 可是当拍照的设备转移到成像质量更好的相机时，我们却很难方便地获取地理位置信息，因为现在大多数的单反/无反相机都不带有 GPS 模块。因此目前这些相机的解决方案是通过手机蓝牙连接来获取 GPS 信息以写入照片。 在实际使用中，相机需要手机打开对应相机 App 并连接数秒才能更新正确位置，否则相机要么不会写入地理位置，要么写入一个老的地理位置。在拍照时如果总是需要用手机来连接，那一定相当影响拍摄体验。 于是经过一段时间的思考，找到了一个可行的方案：在拍照期间，可以用含有 GPS 模块的设备（例如手机）记录自己的轨迹信息，此后可以根据照片拍摄时间和这些轨迹信息计算拍摄的地点，因而写入照片 EXIF 信息中。 动手 起初，我打算自己实现通过轨迹信息计算拍摄地点的脚本。 首先通过手机上的轨迹记录软件得到一个 GPX 文件，GPX 文件的数据格式本质上是 XML。 <trk> <name>...</name> ... <trkseg> <trkpt lat="30.313094" lon="120.382447"> <ele>8.456302</ele> <extensions> <speed>0.059180</speed> </extensions> <hdop>14.278474</hdop> <vdop>10.027264</vdop> <course>-1.000000</course> <time>2021-05-08T13:31:10Z</time> </trkpt> <trkpt lat="30.313110" lon="120.382330"> <ele>9.418098</ele> <extensions> <speed>0.938084</speed> </extensions> <hdop>14.331614</hdop> <vdop>9.951165</vdop> <course>286.357989</course> <time>2021-05-08T13:32:06Z</time> </trkpt> </trkseg> </trk> 类似这样，每个 GPX 文件由 <trk> 标签对组成，<trk> 标签对又由 <trkseg> 标签对组成。事实上在 GPX 记录软件中可以通过暂停、继续在同一个 GPX 文件中记录多个轨迹。因此每个 GPX 文件可以解析出由 TrackSegment 为单位的多组数据。...

又进入了新的一月，又到了服务器续费的时候。由于我前些天把我的 travel blog 变成静态页面了，因此原本 serve 了它一段时间的服务器也可以注销掉了，不过服务器上还存有一些需要保留的文件，于是今天想把这些文件放到 Dropbox 中。 参照 官方安装页面，先运行以下命令下载并解压 Dropbox。 $ cd ~ && wget -O - "https://www.dropbox.com/download?plat=lnx.x86_64" | tar xzf - 然后在 home 目录就会产生一个 .dropbox-dist 目录，同样参照以上官方安装页面，运行这个目录下的 dropboxd 来启动 Dropbox 守护进程。 $ ~/.dropbox-dist/dropboxd 我在运行这句命令之后这段程序执行了一些指令后报错。（我使用的是 Ubuntu 20.04 LTS） 于是立马在 DigitalOcean 中找到答案，我缺少了一些依赖，运行以下命令解决此问题。 $ sudo apt install libc6 libglapi-mesa libxdamage1 libxfixes3 libxcb-glx0 libxcb-dri2-0 libxcb-dri3-0 libxcb-present0 libxcb-sync1 libxshmfence1 libxxf86vm1 安装依赖后，运行上述命令，得到以下输出： 根据提示需要打开 URL 登录自己的账号以绑定这台服务器。打开后界面如下。 如果自己的 Dropbox 账号是通过 Google 或者 Apple 登录的话，需要先登录自己的账号设置一个密码才能在这里登录。 登录之后，控制台会出现一句话，...

前情提要：在我的 travel blog 的仓库根目录下，有一个叫 gotravel 的文件，运行该文件即可自动生成网站，因此 GitHub Actions 只需要在我每次 push 之后运行这个文件再提交一次就可以了。 在 GitHub 仓库内点击菜单栏的 Actions，然后选择 set up a workflow yourself 然后就会跳转至新建文件页面，以及 GitHub 自动生成最初的 main.yml 文件。 # This is a basic workflow to help you get started with Actions name: CI # Controls when the workflow will run on: # Triggers the workflow on push or pull request events but only for the master branch push: branches: [ master ] pull_request: branches: [ master ] # Allows you to run this workflow manually from the Actions tab workflow_dispatch: # A workflow run is made up of one or more jobs that can run sequentially or in parallel jobs: # This workflow contains a single job called "build" build: # The type of runner that the job will run on runs-on: ubuntu-latest # Steps represent a sequence of tasks that will be executed as part of the job steps: # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it - uses: actions/checkout@v2 # Runs a single command using the runners shell - name: Run a one-line script run: echo Hello, world!...