大多数肽计算器问错了问题。
它们问：<i>你添加了多少水？</i>
但实际上，你真正知道的是你的 <i>小瓶大小</i> 和你的 <i>目标剂量</i>。
水的量应该是 <i>输出</i>，而不是 <i>输入</i>。
它还应该使你的剂量落在真实的注射器刻度上，而不是像17.3单位这样的数字。
我开发了一个以这种方式工作的肽计算器：
<a href="https://www.joyapp.com/peptides/" rel="nofollow">https://www.joyapp.com/peptides/</a>
有什么不同：
- 你选择小瓶大小和目标剂量 → 重新配制会为你计算
- 剂量与实际注射器刻度对齐
- 每种肽都有常见的剂量预设
- 在移动设备上运行良好（通常在这里进行操作）
- 支持混合物和化合物（例如 GLOW 或 CJC-1295 + Ipamorelin）
- 你可以保存你的小瓶，无需注册账户。
欢迎反馈或提出值得支持的特殊情况。
返回首页
一周热榜
我之前看到Remotion Claude技能的发布，老实说，尽管一些结果让我感到惊讶，但我最终没有尝试使用Claude代码，因为我知道我需要设置Remotion、打包工具等。如果我已经要做这些，我想不如把它变成一个网站，让任何人都可以写消息并生成视频，而不需要任何前置条件。
我也知道Claude代码并不是每个人都有，设置Remotion也很麻烦。从这整个经历中我学到的一个重要教训是，即使有技能，Opus在设计任务上其实并不是那么出色。我现在使用Gemini来进行Framecall，甚至在某些情况下，Flash（快速模式）产生的结果有时比Opus更好，这让人感到惊讶，考虑到成本差异。
我还了解到，动态视频与编写优质代码或使用Claude代码作为气氛编码器与了解所使用框架的人之间存在相同的“问题”。如果你只是说“制作一个关于X的漂亮视频”，最终结果是否优秀通常是个赌注，就像你说“用Claude代码给我做一个X应用”一样。你需要对设计有敏锐的眼光，并掌握一些术语，以明确你想要实现的目标。
K2.5、ZLM和大多数开源模型在制作视频方面表现得相当糟糕，即使有技能，所以我最终没有将它们作为选项添加。
定价的原因是，结果显示每个动画需要2-5千个以上的代码输出，再加上1-2千个用于Remotion技能的输入，这样的成本确实不低。我本来希望能把这个作为一个免费的产品提供，因为我本来就是为了好玩而做的，但没办法。
在工作中，我需要使用 Teams。它支持一些 Markdown 功能，但对于长消息的编辑体验并不顺畅。因此，我经常在 nvim 中写作，然后在浏览器中预览，再复制粘贴到 Teams。这个工具帮助我省去了审查和复制的步骤。
<p>使用 Rust 和 Claude Code 构建。已在 Windows 和 Mac 上测试，应该也能在 Ubuntu 上运行。
<p>注意事项：仍然需要粘贴的应用程序来处理 HTML 剪贴板内容。
在过去的几个月里，我一直在开发一个受到Flutter启发的TUI框架，使用Dart编写。<p>该API的设计模仿了Flutter，包括StatefulComponent、setState()、Row、Column、Expanded和ListView等组件。<p>最近关于TUI性能的讨论增多，我认为Dart实际上是编写TUI的一个很棒的语言。它可以编译成快速的本地代码，支持跨平台，并且具有良好的开发者体验。开发时使用JIT编译（支持热重载），生产环境则使用AOT编译。<p>非常酷的是状态热重载。如果你对文件进行了修改并保存，Nocterm会实时更新TUI，而无需重启。<p>在底层实现方面：<p>- 差异渲染：虚拟终端缓冲区，仅重绘已更改的单元格<br>
- 声明式组件模型（与Flutter相同）：组件 → 元素 → 渲染对象管道<br>
- 45个以上的组件：布局、滚动、文本输入、Markdown、动画、鼠标支持<br>
- 内置测试框架：推动组件、发送按键、断言终端状态<br>
- 主题支持：6个内置主题，自动检测终端的深色/浅色模式<p>示例：<p>```dart
void main() async {
await runApp(Counter());
}
class Counter extends StatefulComponent {
int _count = 0;
Component build(BuildContext context) {
return Focusable(
onKeyEvent: (event) {
if (event.logicalKey == LogicalKey.space) {
setState(() => _count++);
return true;
}
return false;
},
child: Center(child: Text('Count: $_count')),
);
}
}
```<p>我尝试过几个现有的TUI框架，但缺少我所喜爱的Flutter开发体验，因此我自己构建了一个（无论好坏……）。<p>我一直在使用Nocterm来构建vide_cli（<a href="https://github.com/Norbert515/vide_cli" rel="nofollow">https://github.com/Norbert515/vide_cli</a>），这是一个终端中的编码助手。<p>还有一些很酷的功能即将推出，比如在替代屏幕模式下的虚拟文本选择。由于TUI应用程序接管了终端，正常的文本选择会失效。这个功能在框架层面重新实现，使用户可以自然地选择和复制文本。<p>代码库：<a href="https://github.com/Norbert515/nocterm" rel="nofollow">https://github.com/Norbert515/nocterm</a><p>欢迎对架构、热重载实现或其他任何问题进行提问。
大家好，
我开发了一个计算器，可以以熟悉的图形形式显示和编辑公式，具有所见即所得（WYSIWYG）编辑器，能够处理任意大小的数字，支持物理单位，并且还有许多其他功能。
该项目有在线版和桌面版（适用于Linux和Windows）。
项目是开源的，包含以下组件：
- [Yutovo Editor](https://github.com/denprog/yutovo-editor) — 一个文本和公式编辑器，输出到自定义窗口。完全从零开始构建，没有依赖其他编辑器。使用C++和Boost。
- [Yutovo Desktop](https://github.com/denprog/yutovo-desktop) — 基于Qt的桌面应用程序。
- [Yutovo Web](https://github.com/denprog/yutovo-web) — 基于Vue.js和Quasar的在线版本。其余组件编译为Wasm。
- [Yutovo Calculator](https://github.com/denprog/yutovo-calculator) — 基于boost.spirit的字符串表达式计算器。
- [Yutovo Server](https://github.com/denprog/yutovo-server) — 基于Drogon的网页服务器。
- [Yutovo Solver](https://github.com/denprog/yutovo-solver) — 一个计算器代理。使用C++。
- [Yutovo Logger](https://github.com/denprog/yutovo-logger) — 基于spdlog的日志记录器。
该项目提供Flatpak、Snap、Debian和Windows版本。您可以在注册后在网站上保存您的文档。
欢迎任何意见、bug、缺陷或建议。
我一直在使用 cron，但每个现代替代品都让我在仪表盘上点击或写 50 行 YAML。因此，我构建了 crnd（发音为“crowned”）——这只是一个命令行工具，按照你的指令执行。
主要特点：没有提示，没有交互式向导。只有可以在脚本中运行的命令。
`crnd schedule -n backup -s "0 2 * * *" -- rsync -a ~/docs ~/backup`
就这样。任务保存在一个热重载的 toml 文件中。守护进程作为一个真实的操作系统进程运行，而不是某种容器抽象。
还支持一次性调度任务，这是 cron 无法做到的：
`crnd schedule -n reminder -i 5m -- say "stretch break"`
主要是因为我在使用 AI 编码代理，而它们总是无法处理交互式提示。现在它们可以直接解析 --json 输出并调度任务。
没有云，没有 Docker，没有账户。只有一个单一的二进制文件。
<a href="https://github.com/ysm-dev/crnd" rel="nofollow">https://github.com/ysm-dev/crnd</a>
非常希望得到反馈，特别是如果你正在使用脚本或代理自动化某些事情。
近年来的叙述是科技是邪恶的。那么，有哪些软件技术的好例子仍然能让你感到乐观呢？
这真是太奇怪了。谷歌要求每个人在使用YouTube之前都必须创建一个频道。多年来一切都很好，但现在我的频道被终止了，而我甚至不知道它的存在，且从未上传过视频，现在我完全无法使用YouTube。申诉也失败了。这简直没有道理。我怎么会失去一个从未使用过的频道呢？有没有办法恢复我的频道订阅，或者在没有频道的情况下使用YouTube？
我看到的许多用户界面问题并不是视觉上的问题，而是对用户的未经过检验的假设。<p>我开发了一个小工具，可以捕捉用户界面的截图，并将这些假设明确列出，同时指出错误的风险。<p>这个工具旨在作为发布前的快速设计预评估或批评。<p>希望能得到反馈，看看这种批评用户界面的方法是否真的有用。