最新

我刚接触工程学，编程已经一年了。我开发了一个小应用，现在有1500个用户。每次尝试构建新东西时，我都会感到焦虑，觉得自己对用户有责任，这让我很有压力。我注意到每次我构建新功能时，都想检查一切是否正常，看看用户的反应，担心自己是否让他们失望。这种感觉正常吗？会过去吗？我有点厌倦这种“通过代码取悦他人”的感觉。这个应用是免费的，所以我并没有从中赚取任何收入，但我仍然觉得不能让这些用户失望。你有什么建议可以让我放慢脚步，集中注意力吗？

我是一名经过培训的医生，目前在临床遗传学领域工作。同时，我已经间歇性地编程约五年，并在一家IT公司全职担任前端开发者超过两年。尽管我已经回到医学领域，但我始终感到被编程所吸引。我喜欢构建事物、解决技术问题以及与代码打交道。 我正在努力寻找未来的最佳方向。一个选择是离开医学，完全投入软件开发。但不将我的医学背景与技术技能结合起来，似乎是一种浪费。 我并不主要对数据分析师的路线感兴趣——如果可能的话，我更希望利用我的前端/全栈开发技能。 有没有职业道路能够让医学与软件开发有意义地交汇？这里有没有人走过类似的道路？

我创建µJS是因为我想要一种AJAX导航方式，而不想要HTMX的冗长或Turbo的开销。<p>它可以拦截链接和表单提交，通过AJAX获取页面，并交换DOM的片段。只需一个&lt;script&gt;标签，调用一次`mu.init()`。没有构建步骤，没有依赖。<p>主要特点：补丁模式（在一次请求中更新多个片段）、支持SSE、通过idiomorph进行DOM变形、视图过渡、悬停时预取、轮询，以及对任何元素的完整HTTP动词支持。<p>压缩后约5KB，比HTMX（16KB）和Turbo（25KB）更小，并且可以与任何后端兼容：PHP、Python、Go、Ruby，等等。<p>游乐场：<a href="https://mujs.org/playground" rel="nofollow">https://mujs.org/playground</a> 与HTMX和Turbo的比较：<a href="https://mujs.org/comparison" rel="nofollow">https://mujs.org/comparison</a> 关于项目创建的背景、原因和时间：<a href="https://mujs.org/about" rel="nofollow">https://mujs.org/about</a> GitHub：<a href="https://github.com/Digicreon/muJS" rel="nofollow">https://github.com/Digicreon/muJS</a><p>欢迎讨论这个项目。

一个使用 SvelteKit 制作的不错的应用程序，用于可视化 RAM 和其他 PC 组件的状况有多糟糕。<p>还包含了生产这些组件的公司的相关性图表。<p>我在寻找反馈（:

我在系统设计面试中屡屡失败，尽管我在LeetCode上表现出色。<p>问题不在于知识……而在于结构。<p>资源分散在各处，没有清晰的学习路径，也无法追踪我是否真正涵盖了所有内容。<p>因此，我建立了devwithsal.com，这是一个结构化的学习路线图，涵盖20个主题，按正确的学习顺序组织：<p>基础 → 核心构建模块 → 设计模式 → 完整系统设计<p>每个主题都有针对面试情境的深入解释、精心挑选的资源，以及一个自我评估问题，以测试真正的理解，而不是被动阅读。<p>前三个主题免费： https://devwithsal.com<p>欢迎讨论内容或方法。

嗨，HN，我之所以开发这个工具，是因为我总是推迟自己的身份和访问管理（IAM）审查。 模式总是一样：打开GCP控制台，面对200多个绑定，感到不知所措，关闭标签页，承诺下个月再做。如此反复。 虽然有扫描工具，但它们会给你500个问题，却没有工作流程。你可以将IAM配置粘贴到ChatGPT中，获得一个不错的分析，但下个月你又要从零开始。没有对你所做决定的记忆，也没有你接受的内容或标记的问题。 Qarapace做了两件事： 1. 结构化审查工作流程。它根据影响范围对身份进行排名，让你逐一审核：验证、标记、注释。可以想象成IAM风险的“收件箱清空”模式。 2. AI辅助分析。就像代码审查，但针对权限。它会标记出与最佳实践不符的问题，并解释某些内容为何存在风险。 与一次性AI分析的关键区别在于：决策是持久的。每次月度审查都是基于上次的增量。随着时间的推移，你将获得一条安全推理的审计轨迹，而不仅仅是一个快照。 技术栈：Angular、Firebase、Cloud Functions。每个客户提供自己的只读服务账户密钥（使用Cloud KMS加密，绝不以明文存储）。 目前还处于早期阶段，我是唯一的用户。希望能得到反馈，特别是来自那些进行（或避免）定期IAM审查的人。