最新

你好，我最近有一位家人去世，他有三个孩子和两个丈夫。这个人是指定的“家庭照片负责人”，考虑到家庭结构，分享这些照片并不像大家想象的那么简单。我想将他们所有的家庭照片进行数字归档（有很多纸质照片，可能还有一些底片和数字照片（iPhone拍摄）），并让家里的每个人都能访问。我想知道是否有人做过类似的事情，能分享一下哪些有效、哪些无效，或者你希望自己做得不同的地方等。 我目前的计划是： 1. 获取一台高质量的扫描仪（有推荐吗？） 2. 进行校准（有什么技巧吗？） 3. 扫描照片，可能还包括底片，格式为TIFF或RAW（需要特别的软件吗？我使用Linux，但如果需要的话会考虑换一台新机器） 4. 还要从他们的设备中找到最高质量的副本，如果找不到原始照片，可以从他们的社交媒体上提取照片等。 5. 为文件添加元数据（日期、地点、拍摄的人、事件）。我们可能会把大家聚在一起，尽量通过共同回忆来整理这些信息，尽量多回忆一些细节。 6. 对所有文件进行校验和检查 7. 保存到SSD，并刻录到M-DISC上（同时附上归档过程的说明、如何验证文件、家谱、家庭时间线等） 8. 给每个人一个SSD和两张M-DISC。 我还想创建某种在线访问方式。有没有低维护或无维护的解决方案？理想情况下，人们可以浏览家庭照片，获取低分辨率的副本以便通过Signal发送照片或上传到社交媒体，同时也能下载高分辨率的版本。也许可以考虑使用便宜的静态网站提供商？有什么建议吗？ 我现在还处于规划阶段，只想知道如何尽可能简化这个过程，同时取得最佳效果。这将是未来可预见的时间里“家庭照片”的权威数字档案，我真的希望能做到最好。

将 x.com 替换为 tweet.md，以将公开的 X 帖子、主题和文章转换为干净的 Markdown 格式。

嗨，HN， 我开发了JustBookmarks，这是一个小型桌面书签管理器，旨在为希望拥有一个独立于浏览器的书签管理解决方案的人们提供服务。我之所以制作它，是因为我经常切换浏览器：Vivaldi、Zen、Helium、Brave等。我想要一个集中管理书签的方式，而不依赖于任何单一的浏览器。结果我发现自己在不同的浏览器中导出了不同的书签文件，这些文件之间的状态各不相同，管理起来变得非常麻烦。因此，我查看了现有的工具，它们要么是在线的（如raindrop），要么是自托管但复杂得令人困惑（如linkwarden），而且在基本的书签管理功能（如文件夹）上仍然有所欠缺，反而专注于非标准化的分组方式（如标签）。 这些其他工具构建了自己的数据模型，以引入非标准功能，导致你需要导出为支持的文件格式，才能将书签导入到浏览器中。因此，我认为直接使用最通用的书签文件类型——Netscape书签文件格式，显得要简单得多。 基本理念是： - 直接使用Netscape书签HTML格式作为数据模型 - 只需管理一个.html文件 - 该文件可以直接导入到你使用的任何浏览器中 - 没有云服务、SaaS或其他繁琐的东西，这只是你电脑上的一个文件 功能： - 文件夹树 - 搜索（非常快速） - 拖放重新排序文件夹和书签 - 记住上次会话的状态 - 自动获取网站图标和标题 - 每次编辑自动保存 - 能够将多个书签文件合并为一个 - 直观的快捷键 ``` - ctrl+z 撤销，ctrl+shift+z & ctrl+y 重做 - ? 或 F1 打开帮助/快捷菜单 - Ctrl/Shift 鼠标或箭头键多选以进行批量操作 - F2 重命名 - 还有更多 ``` 它并不追求花哨。没有标签，没有同步平台或浏览器扩展。只有一个书签文件，你可以随意备份或同步。 我很希望能得到一些反馈，因为我觉得有点疯狂的是，我竟然找不到类似的工具。我相信它是存在的，只是我找不到，所以我决定在这里发布，希望将来有其他人能找到这个工具。 为什么选择Go和Svelte？主要是因为我不想花太多时间在这个项目上，我希望它能存在，以便我可以使用。Web技术栈确实很适合制作用户界面，但Electron在很多方面都很糟糕，因此我想选择一个替代方案。虽然Tauri可能是一个“更好”的选择，但Rust的工具栈相对较重，编译速度也慢，与Go相比。如果我想象未来的某个年份，有人试图拉取和构建代码，我认为Go会更容易。Wails采取了类似于Tauri的方法，只是使用Go而不是Rust，并且性能相当不错。至于Svelte？我就是喜欢它。开发速度快，性能也好。话虽如此，我正在考虑将前端重写为fyne，这样就可以全部使用Go，从而简化维护和构建栈。任何在Web栈/npm世界中的东西都有很多变动。

大家好！我们是Gary和Ian，我们正在构建Chert（<a href="https://www.trychert.com/">https://www.trychert.com/</a>），这是一个供企业大规模发送、接收和自动化iMessage对话的API。请查看我们的演示：<a href="https://www.youtube.com/watch?v=SRdwvVxMMoI" rel="nofollow">https://www.youtube.com/watch?v=SRdwvVxMMoI</a>。 我们最初是基于iMessage构建产品，因为蓝色气泡界面、输入指示和反应使得代理对话比SMS/RCS上的对话更具人性化。这些产品包括一个一键式iMessage代理构建器，在一周内吸引了2000名用户，以及一个自动化的iMessage外发序列器，每天发送数千条外发消息。 困难在于，iMessage没有像SMS/RCS那样的原生API。发送和接收iMessage需要一个单独的基础设施，这在设置和维护上都很困难，尤其是在大规模使用时。 随着我们与更多公司的交谈，我们意识到iMessage的高频使用案例并不是B2C代理或销售，而是客户服务、未接来电回复、购物车放弃和潜在客户捕获等场景，这些场景在家庭服务、直销品牌和物业管理等行业中产生了最高的使用量。 此外，这些公司通常需要额外的支持，例如自定义基础设施设置（如联系人卡、区号或本地工作人员会话）、与现有SMS/RCS或语音代理系统的集成支持，以及一种可靠的方式来随着时间的推移扩大其使用量。 我们构建Chert作为企业处理大规模iMessage对话的基础设施层。企业可以使用我们的API以编程方式发送和接收iMessage，将回复路由到人类或代理，并将对话集成到他们已经使用的系统中。 为了在外发和内发使用案例中保持稳定性，我们建立了电话线路健康检查和SMS/RCS备份系统。我们还与现有的SMS/RCS系统、语音代理、CRM（如Salesforce、HubSpot和Attio）以及Slack等工具进行集成。最后，我们让企业能够可靠地从少量测试线路扩展到数百条线路，采用自动化线路配置和基于使用量的定价结构。 我们正在与进行对话式消息传递的企业合作，涉及直销、体育项目、物业管理和家庭服务，规模达到数百条线路。 我们非常希望听到您对这一点以及其他类似领域的看法，iMessage在这些领域可能会有用。欢迎所有评论！