AI가 초당 백만 개의 웹사이트를 크롤링할 때, 한 사람이 하루 종일 단 하나의 웹페이지를 들여다본다. 미친 짓인가? 아니다. 도자기 장인이 물레 앞에서 흙을 만지듯, 그는 HTML을 만진다. 한 줄 한 줄, 한 태그 한 태그. AI가 0.001초 만에 파싱하는 것을 그는 8시간 동안 음미한다. 왜? 여기서 침묵이 필요하다. 성급한 답변은 금물이다. ...
如果你读到这个系列到这里 你可能会有这样的想法。 “最终没有特别的技术讨论。” “也没有立即可用的营销技巧。” “反而一直在谈‘思考’。” 是的。 这个系列是故意这样构成的。 因为 在开发者品牌中最持久的东西 不是技术，平台或格式。 技术会改变， 思维会保留 想起你最初学的语言。 那种语言 可能至今仍在使用， 也可能不是。 但有一件事是肯定的。 解决问题的方式 设定结构的标准 处理复杂性的态...
品牌化的過程中 某個時刻開始看到數字。 追隨者數量 點擊率 喜歡數 分享次數 然後自然地 當這些數字不理想時 開始懷疑自己。 "我的文章很糟糕嗎？" "人們不感興趣嗎？" "品牌化不對勁嗎？" 但這裡 隱藏著一個很大的誤解。 追隨者是'看到的人'， 信任是'主動尋找的人' 追隨者多意味著 有很多看過你的人。 有信任意味著 有主動尋找你的人。 這兩者完全不同。 品牌的建立信號 在這樣的時刻出現...
當開發者決定進行品牌推廣時，許多人會這樣想。 “這裡也發一下，那裡也發一下，多曝光了就會成功。” 因此在博客上寫，也在X（推特）上寫，也在論壇上寫，也在LinkedIn上發布。 但是在某個時刻，奇怪的疲勞會湧上心頭。 “明明努力寫了...為什麼沒有留下什麼呢？” 品牌推廣不順利的原因不是因為“曝光不足” 在大多數情況下，問題不在於曝光，而在於結構。 如果將品牌推廣誤解為“讓人看到很多”，就會...
开发者文章无法阅读的最常见原因是内容错误。 在大多数情况下，是因为使用的语言不同。 开发者用技术语言说话，读者用生活语言理解。 如果无法跨越这个鸿沟，即使内容再好，也不会留给人们任何印象。 人们不记得代码 而是记得情境 你可能看过这样的文章。 “这个函数的时间复杂度为O(n)。” “这个结构具有良好的可扩展性。” “这种方法更有效率。” 这些说法并没有错。但几天后，几乎没有人记得这篇文章的内...
当谈论开发者品牌时， 很多人在这一点停下来。 “还没有展示出足够好的东西。” “稍微完善后再写吧。” “现在不完整，感到难为情。” 因此记录总是被推迟。 在完成之后， 在整理之后， 在可以展示给他人之前。 但讽刺的是 擅长个人品牌的开发者们 总是公开‘未完成之前’。 人们比成品更信任 ‘经历相同困惑的人’ 当有人展示出精美的成果时 我们会赞叹。 但我们并不 信任他们。 因为成果中 看不到过程...
为什么所有人都在使用React，我们却不需要使用它？—前端战争的历史和Hotwire的诞生原因 最近听到有关Web开发的讨论时，总是会听到同样的话语。 “前端应该用React。” “现在所有人都在用React。” “不学React就不是开发人员。” 但这是真的吗？ 不，准确来说，只有一半是正确的。 React是一个很好的库。 但问题是... React在“必要的情况”中实际上只占整个Web服...
天才般的新人和经验丰富的资深 一起使用Codex和Claude Code的感受 现在，“用AI编码”这句话已经不再特别了。 我在实际服务开发过程中也同时使用多个模型，其中Codex(gpt-5-codex high)和Claude Code(Opus)就像两位性格迥异的同事一样。 有趣的是，如果简单地将这两者比作“谁编码更好”，就会忽略本质。 这不是实力优劣的问题，而更接近于与开发者相似的性...
您创建的服务向世界公开的最佳方式 - DHH谈论的裸金属服务器和Kamal，以及“无构建”的哲学 学习Rails时，总会有这样的时刻。 “现在我也想把我做的服务真正放到互联网上。” 那时大多数人会这样想。 “要用AWS吗？” “GCP说很好” “构建Docker，创建CI，Kubernetes…？” 然后就会感到不知所措。 “部署比开发更难吧…?” 现在的云时代已经成为 强加给开发者过度复杂...
We'll email you when Bamchi Blog publishes new content.
Your email will only be used for new post notifications.
