HackerURLs

一次又一次被重新发现的经典。

同一个链接,相隔一年以上,一次又一次被人重新发现、再次冲上 Hacker News 首页。能经受住这种时间检验的,大多是值得一读再读的文章。每篇附中文标题,讨论最热的那些再加上中文导读和高赞评论翻译。

从名人堂开始
  • 4,700+篇经过时间检验的经典

Hall of fame

名人堂

在经典库里看全部精选

上首页次数最多、而且有中文导读的 30 篇。时间轴上每个黑点是一次上首页,空心点是一次没冲上去的投稿。

  1. 正在载入经典…

Archive

经典库

按第一次上首页的年份分布,点柱子筛选。

排序

    About

    这些经典是怎么挑出来的

    1. 01

      合并同一个链接

      读取 Hacker News 自 2006 年以来的全部链接投稿,把 http/https、www、跟踪参数等写法不同的同一篇文章合并成一条。

    2. 02

      只留经得起时间的

      同一链接至少两次拿到 50 分以上(约等于上首页),而且两次相隔一年以上;再由 AI 剔除状态页、产品首页和新闻事件。

    3. 03

      写导读、译评论

      上首页次数最多的 2,000 篇配上中文导读、"为什么经久不衰",并精选翻译 HN 高赞评论。导读由 AI 生成,可能有误。

    编程与软件工程mjt.me.uk编辑精选

    程序员对地址信以为真的谬误

    Falsehoods programmers believe about addresses

    3次上首页
    7年跨度
    410累计得分
    337条评论

    2013 — 2020,它一次次回到首页

    黑点是上首页(≥ 50 分)的那次投稿,空心点是没冲上去的投稿,点越大分数越高。

    导读

    这篇文章列举了程序员对“地址”的常见错误假设(如地址一定有街道名、邮编不会以零开头、地址一定存在于邮政数据库中等),说明现实世界的地址格式千奇百怪。它提醒开发者不要对地址数据做过强的结构化假设,否则会不断遇到反例。

    为什么经久不衰:地址系统的多样性随全球化业务持续暴露,这篇文章多年后仍是设计表单和数据模型时避免过度工程化的经典提醒。

    关键词 地址数据建模国际化表单设计

    HN 评论精选

    实践反例:完全自由文本的地址输入也会失败,分字段询问仍有必要。

    我很早就读了这篇文章并认真对待,于是不再分别询问地址、邮编、城市、州省,只放一个大文本框标注“完整地址”,让用户自由填写。结果 80% 的用户只填了街道地址,不填邮编、城市和州省——即使他们来自地址格式通常包含这些信息的国家。最后我们只好改回原来明确分字段询问的表单。

    FooBarWidget查看英文原文

    I read this article a long time ago and I took it seriously. So instead of asking for address, postal/zip code, city, state/province, I just put up a big text area labeled "Full address" so that people have complete freedom about what to fill in. 80% of the users ended up only filling in their street address, not their postal/zip code, city and state/province, even though they're from countries where (most?) addresses satisfy that format. We ended up reverting to the previous form where we explicitly asked for postal/zip code etc.

    依赖邮政数据库做地址校验会给非标准地址的用户带来真实麻烦。

    “地址会存在于国家邮政数据库中”这条我踩过坑——不是因为新楼或船屋,只是因为当地邮局两街区范围内不做上门投递,我们只能用邮政信箱。麻烦在于需要街道地址的商家用 USPS 数据库做地址校验:有的不寄送邮政信箱的网店会弹“你确定吗”的提示,有的直接拒绝。更糟的是,本地垃圾清运公司被大型区域公司收购后,路线规划软件显然用了 USPS 数据库,结果我们整条街的地址都被从收运路线中删掉了。

    edmccard查看英文原文

    "An address will exist in the country's postal service's database" This is the one that I've run afoul of -- not because I live in a brand-new building, or a houseboat, or 30 miles from anywhere on an unnamed road; it's just that there is no door-to-door delivery for houses within a 2-block radius of the local post office, so we have a PO box. The trouble happens when a business that needs my street address uses the USPS database for address verification. One example is online stores that don't ship to PO boxes. Some of these sites have a form with a sort of "Are you sure" prompt when my street address isn't recognized; others just refuse to accept it. Even worse was when the local company that picked up my trash was bought by one of the larger regional "waste management" operations, and all the drivers' routes were re-planned for "efficiency" (evidently using software that hit some USPS database); the upshot was that everyone on my street had their address removed from the pickup routes.

    有些地方的人根本没有可用的正式地址,这是更根本的假设错误。

    一个更遥远的谬误:人们根本“有地址”,或能清晰无歧义地描述自己的住所(哪怕用 GPS 坐标)。我曾住在一个完全无法指路的地方——贫穷国家的社区深处,街道没有名字,建筑没有编号,公寓也没有门牌。想收快递只能去快递公司的本地网点出示身份证代收。至于用于追责、起诉之类的“账单地址”,我基本认为不可能实现。

    hawkice查看英文原文

    A falsehood only distantly alluded to: That people have addresses at all, or can describe their residence in an unambiguous or clear way (even using GPS coordinates). I used to live in a place I couldn't even remotely give directions to. It was deep within a neighborhood of a poorer country, none of the streets had names, none of the buildings are numbered. I lived in an building where none of the apartments had numbers or names. If I wanted something delivered, I would go to a local shop for the company delivering it, and show my ID, and they would have it routed there if it wasn't in the building already. If you wanted a billing address for, I don't know, tracking me down, initiating lawsuits, something like that? I honestly just assume that's impossible.

    文章本身也有盲区:日本等非西方体系提供了更多反例。

    文章仍然以西方(尤其英国)为中心,更国际化的业务会发现更多反例。以日本为例:地址格式全国统一是错的(札幌有自己的体系,京都在标准体系上还有另一套);地址从最具体到最宽泛排列(如门牌号到邮编),日本恰好相反;地址体系不会变是错的(日本 1998 年改革过);门牌基于街道也是错的(日本基于街区)。日本标准地址基于行政区划,提供都道府县、区、町和街区号。京都允许用两条街道的交叉口加方位表示街区,因为有些区存在重名町;札幌则用距市中心的街区数加方向来定位。

    masklinn查看英文原文

    The article remains western- (and especially UK-) centric in outlook, a more international business will probably find plenty others. For instance japans disprove: * The address format is uniform across the country (Sapporo has its own, and Kyoto uses an alternative system on top of the standard one) * Addresses go from the most specific to least (e.g. flat number to postal code), japan is the exact opposite * Addressing systems don't change (Japan's was reformed in 1998) * Building numbers are street-based (Japan's are block-based) It also expands on things like "addresses will have a street": standard japanese addressing is subdivision-based so addresses provide the prefecture, the ward (~county), the district and the city block. Except for Sapporo and Kyoto (see 1): Kyoto allows an denoting blocks as the intersection of two streets and the position relative to the intersection (north, south, east or west). One reason is that some wards have multiple districts with the same name... Sapporo uses a system where blocks are addressed by their distance (in blocks) + direction from city center, so you might be told the address is "the 4th building, 3 blocks north and 5 blocks east".

    核心教训:避免过度工程化,用自由文本字段可规避大部分特例。

    最大的收获听起来很熟悉:不要过度设计数据模型。你对具体属性做的决定越多,需要处理的特例就越多(这会成为程序员和用户持续的挫败来源)。就地址而言,大多数问题都可以用自由文本字段代替街道、门牌、公寓、楼层、州、县、区等专用字段来避免。

    Udo查看英文原文

    The biggest takeaway for me here should sound familiar: don't overengineer your data model. The more decisions you make about specific properties, the more special cases you will need to handle (and those are a continuing source of frustration for both programmers and users down the line). In this case, most of these issues can be avoided by allowing a free text field instead of dedicated fields for street name, number, apartment, floor, state, county, district, and whatever.

    历次讨论

    同类还值得读

    1. 开源应用架构

      The Architecture of Open Source Applications

      《开源软件架构》(AOSA)是一本在线免费书,邀请知名开源项目的作者亲自剖析其内部设计,涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。

      编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选
    2. 编程语言简史:简短、不完整且多半错误

      A Brief, Incomplete, and Mostly Wrong History of Programming Languages

      一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章,用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。

      编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.com
    3. SQLite 是如何测试的

      How SQLite is tested

      SQLite 官方文档页,系统介绍 SQLite 的测试体系:多种测试方法(TCL 测试、模糊测试、回归测试、静态分析等)和海量测试用例,展示了这个小型开源项目如何靠极致测试获得…

      编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选
    4. 高级编程语言(2009)

      Advanced programming languages (2009)

      Matt Might 的经典文章,按用途推荐“高级编程语言”:如果追求就业就选主流语言,如果追求表达力、学术研究或创业,则推荐 Haskell、OCaml、Scala 等函数式语…

      编程与软件工程上首页 8 次 · 2009–2022matt.might.net
    5. 我的 Forth 与栈机器经历

      Yosefk - My history with Forth & stack machines

      作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程:既赞叹其简洁优雅、代码量小、可自举的优点,也坦率指出栈操作在实际编程中的痛苦,以及 Forth 社区文化中的问题。

      编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选

    打赏支持

    打赏二维码

    觉得有用,请作者喝杯咖啡。

    WeChat

    关注向阳乔木

    微信公众号「向阳乔木推荐看」

    微信公众号「向阳乔木推荐看」二维码

    微信扫一扫;在微信里打开本页时,长按二维码识别。