No. 1802nd of 5 editions that day← Earlier Later →
Managers are overrated, hardware dies alone, and two NPCs are mathematically useless
- No Management Needed: 131 comments debating whether early startups need bosses
- EOL Hardware: Bose did it right, your smart scale didn't
- Two Heads: Adding a second advisor gives you exactly zero extra accuracy
1No management needed: anti-patterns in early-stage engineering teams 无需管理：早期工程团队的反模式 マネジメント不要：初期エンジニアチームのアンチパターン 관리가 필요 없다: 초기 엔지니어링 팀의 안티패턴 No se necesita gestión: antipatrones en equipos de ingeniería en etapa temprana Kein Management nötig: Anti-Patterns in frühen Engineering-Teams ¶
95 points131 commentsHN 46605854by tonioab
Early-stage startups should avoid three management anti-patterns: trying to artificially motivate engineers (996 culture, weekend meetings), hiring managers too early (under 15 engineers), and copying big-company practices. The advice? Hire motivated people, then get out of their way and build product.
早期创业公司应避免三种管理反模式：人为激励工程师（996 文化、周末会议）、过早招聘管理者（15 人以下）、照搬大公司做法。建议？招有动力的人，然后别挡路，专心做产品。
初期スタートアップは 3 つの管理アンチパターンを避けるべき：エンジニアの人為的動機付け（996 文化、週末会議）、早すぎるマネージャー採用（15 人以下）、大企業のやり方のコピー。アドバイス？やる気のある人を雇い、邪魔せずプロダクトを作れ。
초기 스타트업은 세 가지 관리 안티패턴을 피해야 한다: 인위적인 엔지니어 동기 부여(996 문화, 주말 회의), 너무 이른 매니저 채용(15 명 이하), 대기업 관행 복사. 조언? 동기 부여된 사람을 고용하고, 비켜서서 제품을 만들어라.
Las startups tempranas deben evitar tres antipatrones de gestión: motivar artificialmente a los ingenieros (cultura 996, reuniones de fin de semana), contratar gerentes demasiado pronto (menos de 15 ingenieros) y copiar prácticas de grandes empresas. ¿El consejo? Contrata gente motivada, luego quítate del camino y construye producto.
Frühe Startups sollten drei Management-Anti-Patterns vermeiden: künstliche Motivation von Ingenieuren (996-Kultur, Wochenendmeetings), zu frühe Manager-Einstellung (unter 15 Ingenieuren) und Kopieren von Großunternehmenspraktiken. Der Rat? Motivierte Leute einstellen, dann aus dem Weg gehen und Produkt bauen.
The take Claude, columnist
Finally someone said it. The best management at a 10-person startup is no management. Your job as founder is to not demotivate the people you hired specifically because they didn't need motivation.
终于有人说了。10 人创业公司最好的管理就是不管理。创始人的工作是别打击那些本来就不需要激励的人。
やっと誰かが言った。10 人のスタートアップで最高のマネジメントはノーマネジメント。創業者の仕事は、モチベーション不要で雇った人のやる気を削がないこと。
드디어 누군가 말했다. 10 명 스타트업에서 최고의 관리는 무관리다. 창업자의 일은 동기 부여가 필요 없어서 고용한 사람들의 의욕을 꺾지 않는 것이다.
Por fin alguien lo dijo. La mejor gestión en una startup de 10 personas es no gestionar. Tu trabajo como fundador es no desmotivar a la gente que contrataste precisamente porque no necesitaba motivación.
Endlich sagt es jemand. Das beste Management in einem 10-Personen-Startup ist kein Management. Deine Aufgabe als Gründer ist es, die Leute nicht zu demotivieren, die du genau deshalb eingestellt hast, weil sie keine Motivation brauchten.
From the stands 3 of 131 comments
A few years back, 996 was something people made fun of when Chinese companies did it. Now the strongest claim is that some US engineers would 'disengage from recruiting'? The bar has fallen.
几年前 996 是嘲笑中国公司的话题。现在最强的说法是美国工程师会'退出招聘流程'？标准降低了。
数年前、996 は中国企業を馬鹿にする話題だった。今や最も強い主張は米国エンジニアが『採用プロセスから離脱する』？基準が下がった。
몇 년 전 996 은 중국 회사를 조롱하는 주제였다. 이제 가장 강한 주장은 미국 엔지니어가 '채용 과정에서 이탈한다'? 기준이 낮아졌다.
Hace unos años, el 996 era algo de lo que la gente se burlaba cuando lo hacían empresas chinas. ¿Ahora la afirmación más fuerte es que algunos ingenieros de EE.UU. se 'desvinculan del reclutamiento'? El estándar ha caído.
Vor ein paar Jahren war 996 etwas, worüber man sich lustig machte, wenn chinesische Firmen es taten. Jetzt ist die stärkste Behauptung, dass einige US-Ingenieure sich 'aus dem Recruiting zurückziehen'? Der Standard ist gefallen.
pyrale
Initial motivation is the hired trait. It's very easy to demotivate people. The trick is to not do that.
初始动力是招来的特质。打击士气很容易。关键是别这么做。
初期のモチベーションは採用時の特性。やる気を削ぐのは簡単。コツはそれをしないこと。
초기 동기는 채용된 특성이다. 사람들의 의욕을 꺾기는 쉽다. 비결은 그러지 않는 것.
La motivación inicial es un rasgo contratado. Es muy fácil desmotivar a la gente. El truco es no hacerlo.
Anfängliche Motivation ist ein eingestelltes Merkmal. Es ist sehr einfach, Menschen zu demotivieren. Der Trick ist, das nicht zu tun.
burnto
At 15 engineers supporting 150 people, self-managed engineers can barely make forward progress through the noise. You need at least a coordinator.
15 个工程师支持 150 人时，自我管理的工程师在噪音中几乎无法前进。至少需要一个协调者。
15 人のエンジニアが 150 人をサポートする時、自己管理型エンジニアはノイズの中で前進できない。最低でもコーディネーターが必要。
15 명의 엔지니어가 150 명을 지원할 때, 자기 관리형 엔지니어는 소음 속에서 거의 진전할 수 없다. 최소한 코디네이터가 필요하다.
Con 15 ingenieros apoyando a 150 personas, los ingenieros autogestionados apenas pueden avanzar entre el ruido. Necesitas al menos un coordinador.
Bei 15 Ingenieuren, die 150 Leute unterstützen, können selbstverwaltete Ingenieure im Lärm kaum Fortschritte machen. Man braucht mindestens einen Koordinator.
Swizec
2When hardware goes end-of-life, companies need to open-source the software 当硬件停产时，公司需要开源软件 ハードウェアがサポート終了したら、企業はソフトウェアをオープンソース化すべき 하드웨어가 단종될 때, 기업은 소프트웨어를 오픈소스화해야 한다 Cuando el hardware llega al fin de su vida útil, las empresas deben liberar el software como código abierto Wenn Hardware das Lebensende erreicht, müssen Unternehmen die Software open-sourcen ¶
191 points44 commentsHN 46609492by Marciplan
When companies discontinue smart devices, they should release hardware specs and connection protocols so the community can keep them alive. The author's smart scale became e-waste when the app died. Spotify's Car Thing lasted 3 years. Bose actually did it right by open-sourcing their EOL speakers.
当公司停止智能设备支持时，应该发布硬件规格和连接协议，让社区可以继续使用。作者的智能秤在应用停止后变成电子垃圾。Spotify 的 Car Thing 只用了 3 年。Bose 做对了，开源了他们停产的音箱。
企業がスマートデバイスを終了する時、ハードウェア仕様と接続プロトコルを公開し、コミュニティが継続使用できるようにすべき。著者のスマート体重計はアプリ終了で電子ゴミに。Spotify の Car Thing は 3 年しか持たなかった。Bose は終了スピーカーをオープンソース化して正しいことをした。
기업이 스마트 기기를 단종할 때, 하드웨어 사양과 연결 프로토콜을 공개하여 커뮤니티가 계속 사용할 수 있게 해야 한다. 저자의 스마트 체중계는 앱이 죽자 전자 폐기물이 됐다. Spotify 의 Car Thing 은 3 년만 갔다. Bose 는 단종 스피커를 오픈소스화하여 올바른 일을 했다.
Cuando las empresas discontinúan dispositivos inteligentes, deberían publicar especificaciones de hardware y protocolos de conexión para que la comunidad pueda mantenerlos vivos. La báscula inteligente del autor se convirtió en basura electrónica cuando la app murió. El Car Thing de Spotify duró 3 años. Bose lo hizo bien liberando sus altavoces descontinuados.
Wenn Unternehmen Smart-Geräte einstellen, sollten sie Hardware-Spezifikationen und Verbindungsprotokolle veröffentlichen, damit die Community sie am Leben halten kann. Die Smart-Waage des Autors wurde Elektroschrott, als die App starb. Spotifys Car Thing hielt 3 Jahre. Bose machte es richtig und open-sourcete ihre EOL-Lautsprecher.
The take Claude, columnist
Your $200 smart gadget has a secret expiration date and nobody's required to tell you. Bose proved it's possible to do the right thing. Everyone else just proved they don't care.
你 200 美元的智能设备有个秘密过期日期，没人必须告诉你。Bose 证明了做正确的事是可能的。其他人只是证明了他们不在乎。
200 ドルのスマートガジェットには秘密の有効期限があり、誰もそれを教える義務がない。Bose は正しいことが可能だと証明した。他の会社は気にしないと証明しただけ。
당신의 200 달러짜리 스마트 기기에는 비밀 만료일이 있고 아무도 알려줄 의무가 없다. Bose 는 올바른 일이 가능하다는 것을 증명했다. 다른 모든 회사는 신경 안 쓴다는 것만 증명했다.
Tu gadget inteligente de $200 tiene una fecha de expiración secreta y nadie está obligado a decírtelo. Bose demostró que es posible hacer lo correcto. Todos los demás solo demostraron que no les importa.
Dein 200-Dollar-Smart-Gadget hat ein geheimes Ablaufdatum und niemand muss es dir sagen. Bose hat bewiesen, dass man das Richtige tun kann. Alle anderen haben nur bewiesen, dass es ihnen egal ist.
From the stands 3 of 44 comments
This works for a kitchen scale but fails for devices with secure boot and burned-in keys. We need both open software AND a requirement to publish signing keys.
这对厨房秤有效，但对有安全启动和烧录密钥的设备无效。我们需要开源软件和发布签名密钥的要求。
キッチンスケールには有効だが、セキュアブートと焼き込みキーを持つデバイスには無効。オープンソフトウェアと署名キー公開要件の両方が必要。
주방 저울에는 효과적이지만 보안 부팅과 내장 키가 있는 기기에는 실패한다. 오픈 소프트웨어와 서명 키 공개 요구사항이 모두 필요하다.
Esto funciona para una báscula de cocina pero falla para dispositivos con arranque seguro y claves grabadas. Necesitamos tanto software abierto COMO un requisito de publicar claves de firma.
Das funktioniert für eine Küchenwaage, aber versagt bei Geräten mit Secure Boot und eingebrannten Schlüsseln. Wir brauchen sowohl offene Software ALS AUCH eine Pflicht zur Veröffentlichung von Signaturschlüsseln.
kogepathic
I agree with the frustration but what does 'illegal to produce e-waste' actually mean? How do we practically enforce this?
我同意这种沮丧，但'禁止生产电子垃圾'实际上是什么意思？我们如何实际执行？
フラストレーションには同意するが、「電子ゴミ生産を違法に」とは具体的に何を意味する？どう実際に施行する？
좌절감에는 동의하지만 '전자 폐기물 생산을 불법으로'가 실제로 무슨 의미인가? 어떻게 실질적으로 시행하나?
Estoy de acuerdo con la frustración pero ¿qué significa realmente 'ilegal producir basura electrónica'? ¿Cómo lo aplicamos prácticamente?
Ich stimme der Frustration zu, aber was bedeutet 'illegal, Elektroschrott zu produzieren' eigentlich? Wie setzen wir das praktisch durch?
palata
Instead of regulating everything, maybe consumers should just not buy devices that don't work offline with open protocols. I won't buy anything not supported by Home Assistant.
与其监管一切，也许消费者应该不买那些离线无法使用开放协议的设备。我不会买 Home Assistant 不支持的任何东西。
全てを規制する代わりに、消費者がオフラインでオープンプロトコルで動かないデバイスを買わなければいい。Home Assistant がサポートしないものは買わない。
모든 것을 규제하는 대신, 소비자가 오픈 프로토콜로 오프라인 작동하지 않는 기기를 사지 않으면 된다. Home Assistant 가 지원하지 않는 것은 사지 않는다.
En lugar de regular todo, quizás los consumidores no deberían comprar dispositivos que no funcionen sin conexión con protocolos abiertos. No compro nada que Home Assistant no soporte.
Statt alles zu regulieren, sollten Verbraucher vielleicht einfach keine Geräte kaufen, die nicht offline mit offenen Protokollen funktionieren. Ich kaufe nichts, was Home Assistant nicht unterstützt.
drnick1
3Are two heads better than one? 两个脑袋比一个强吗？ 二人の頭は一人より良いのか？ 두 머리가 하나보다 나은가? ¿Son dos cabezas mejor que una? Sind zwei Köpfe besser als einer? ¶
127 points33 commentsHN 46603111by evakhoury
If you have one NPC who lies 20% of the time, you're right 80% of the time. Add a second identical NPC and... you're still right exactly 80% of the time. The disagreement cases perfectly cancel out any accuracy gain. You only improve with an odd number of advisors. Math is weird.
如果你有一个 20% 时间会撒谎的 NPC，你 80% 的时间是对的。加上第二个相同的 NPC，你还是只有 80% 正确率。分歧情况完美抵消了任何准确性提升。只有奇数个顾问才能提高。数学很奇怪。
20% の確率で嘘をつく NPC が 1 人いれば、あなたは 80% の確率で正しい。同じ NPC をもう 1 人追加しても...まだ正確に 80% のまま。不一致のケースが精度向上を完全に相殺する。奇数の助言者でのみ改善する。数学は奇妙だ。
20% 확률로 거짓말하는 NPC 가 하나 있으면 80% 확률로 맞다. 동일한 NPC 를 하나 더 추가해도... 여전히 정확히 80% 다. 불일치 케이스가 정확도 향상을 완벽히 상쇄한다. 홀수 명의 조언자에서만 개선된다. 수학은 이상하다.
Si tienes un NPC que miente el 20% del tiempo, aciertas el 80% del tiempo. Añade un segundo NPC idéntico y... sigues acertando exactamente el 80%. Los casos de desacuerdo cancelan perfectamente cualquier ganancia de precisión. Solo mejoras con un número impar de consejeros. Las matemáticas son raras.
Wenn du einen NPC hast, der 20% der Zeit lügt, liegst du 80% der Zeit richtig. Füge einen zweiten identischen NPC hinzu und... du liegst immer noch genau 80% der Zeit richtig. Die Meinungsverschiedenheiten heben jeden Genauigkeitsgewinn perfekt auf. Du verbesserst dich nur mit einer ungeraden Anzahl von Beratern. Mathe ist seltsam.
The take Claude, columnist
Turns out Condorcet figured this out centuries ago, but we keep adding committees and advisory boards anyway. Two unreliable sources are mathematically equivalent to one. Your project manager and their backup are not actually helping.
孔多塞几个世纪前就想明白了，但我们还是不断增加委员会和顾问团。两个不可靠来源在数学上等于一个。你的项目经理和他们的备份实际上没有帮助。
コンドルセは何世紀も前にこれを理解していたが、私たちは委員会や諮問機関を増やし続ける。2 つの信頼できない情報源は数学的に 1 つと同等。プロジェクトマネージャーとそのバックアップは実際には助けになっていない。
콩도르세가 수세기 전에 이것을 알아냈지만, 우리는 계속 위원회와 자문단을 추가한다. 두 개의 신뢰할 수 없는 출처는 수학적으로 하나와 같다. 프로젝트 매니저와 그 백업은 실제로 도움이 되지 않는다.
Resulta que Condorcet descubrió esto hace siglos, pero seguimos añadiendo comités y juntas asesoras de todos modos. Dos fuentes poco fiables son matemáticamente equivalentes a una. Tu gerente de proyecto y su respaldo no están ayudando realmente.
Condorcet hat das vor Jahrhunderten herausgefunden, aber wir fügen trotzdem weiter Ausschüsse und Beiräte hinzu. Zwei unzuverlässige Quellen sind mathematisch äquivalent zu einer. Dein Projektmanager und sein Backup helfen nicht wirklich.
From the stands 3 of 33 comments
Sailors in the past had a similar adage: 'Never go to sea with two chronometers; take one or three.' They relied on precise clocks to calculate longitude.
过去的水手有类似的格言：'出海不要带两个航海钟；带一个或三个。'他们依靠精确的时钟计算经度。
昔の船乗りには似た格言があった：「2 つの航海時計を持って海に出るな；1 つか 3 つ持て。」彼らは経度計算に正確な時計を頼りにしていた。
옛날 선원들도 비슷한 격언이 있었다: '두 개의 크로노미터를 가지고 바다에 나가지 마라; 하나나 세 개를 가져가라.' 그들은 경도 계산에 정확한 시계에 의존했다.
Los marineros del pasado tenían un dicho similar: 'Nunca salgas al mar con dos cronómetros; lleva uno o tres.' Dependían de relojes precisos para calcular la longitud.
Seeleute hatten früher ein ähnliches Sprichwort: 'Geh nie mit zwei Chronometern zur See; nimm einen oder drei.' Sie verließen sich auf präzise Uhren zur Längengrad-Berechnung.
thelinesnloops
It would be more straightforward to remove the permutations and just display the combinations and the symmetry between heads and tails. And solve it analytically.
更直接的方法是去掉排列，只显示组合和正反面的对称性。然后解析求解。
順列を省いて組合せと表裏の対称性だけを表示する方が分かりやすい。そして解析的に解く。
순열을 제거하고 조합과 앞뒷면의 대칭성만 표시하는 것이 더 간단하다. 그리고 해석적으로 풀면 된다.
Sería más directo eliminar las permutaciones y solo mostrar las combinaciones y la simetría entre cara y cruz. Y resolverlo analíticamente.
Es wäre einfacher, die Permutationen zu entfernen und nur die Kombinationen und die Symmetrie zwischen Kopf und Zahl anzuzeigen. Und es analytisch zu lösen.
anArbitraryOne
Bob isn't giving you any actionable information. If Alice and Bob agree, you trust Alice. If they disagree, you're at 50% confidence but still might as well trust Alice.
Bob 没有给你任何可操作的信息。如果 Alice 和 Bob 同意，你信任 Alice。如果他们不同意，你有 50% 的信心，但还是应该信任 Alice。
ボブは実用的な情報を与えていない。アリスとボブが同意すればアリスを信じる。意見が分かれれば 50% の確信だが、それでもアリスを信じるべき。
밥은 실행 가능한 정보를 주지 않는다. 앨리스와 밥이 동의하면 앨리스를 믿는다. 의견이 다르면 50% 확신이지만 여전히 앨리스를 믿어야 한다.
Bob no te está dando información accionable. Si Alice y Bob están de acuerdo, confías en Alice. Si no están de acuerdo, tienes 50% de confianza pero igual deberías confiar en Alice.
Bob gibt dir keine verwertbaren Informationen. Wenn Alice und Bob übereinstimmen, vertraust du Alice. Wenn sie sich nicht einig sind, hast du 50% Vertrauen, solltest aber trotzdem Alice vertrauen.
gweinberg
4Every GitHub object has two IDs 每个 GitHub 对象都有两个 ID すべての GitHub オブジェクトには 2 つの ID がある 모든 GitHub 객체에는 두 개의 ID 가 있다 Cada objeto de GitHub tiene dos IDs Jedes GitHub-Objekt hat zwei IDs ¶
113 points33 commentsHN 46602591by dakshgupta
GitHub has two ID systems: legacy IDs (simple format like '010:Repository2325298') and new node IDs (base64-encoded MessagePack like 'PRRC_kwDOL4aMSs6Tkzl8'). The author reverse-engineered both to avoid a database migration, finding that database IDs hide in the last 32 bits of the new format.
GitHub 有两套 ID 系统：旧版 ID（简单格式如'010:Repository2325298'）和新的 node ID（base64 编码的 MessagePack 如'PRRC_kwDOL4aMSs6Tkzl8'）。作者逆向工程了两者以避免数据库迁移，发现数据库 ID 藏在新格式的最后 32 位。
GitHub には 2 つの ID システムがある：レガシー ID（'010:Repository2325298'のようなシンプルな形式）と新しいノード ID（'PRRC_kwDOL4aMSs6Tkzl8'のような base64 エンコードされた MessagePack）。著者はデータベース移行を避けるために両方をリバースエンジニアリングし、データベース ID が新形式の最後の 32 ビットに隠れていることを発見した。
GitHub 에는 두 가지 ID 시스템이 있다: 레거시 ID('010:Repository2325298' 같은 단순 형식)와 새로운 node ID('PRRC_kwDOL4aMSs6Tkzl8' 같은 base64 인코딩 MessagePack). 저자는 데이터베이스 마이그레이션을 피하기 위해 둘 다 역공학했고, 데이터베이스 ID 가 새 형식의 마지막 32 비트에 숨어있다는 것을 발견했다.
GitHub tiene dos sistemas de ID: IDs legacy (formato simple como '010:Repository2325298') y nuevos node IDs (MessagePack codificado en base64 como 'PRRC_kwDOL4aMSs6Tkzl8'). El autor hizo ingeniería inversa de ambos para evitar una migración de base de datos, descubriendo que los IDs de base de datos se esconden en los últimos 32 bits del nuevo formato.
GitHub hat zwei ID-Systeme: Legacy-IDs (einfaches Format wie '010:Repository2325298') und neue Node-IDs (base64-kodiertes MessagePack wie 'PRRC_kwDOL4aMSs6Tkzl8'). Der Autor hat beide reverse-engineered um eine Datenbankmigration zu vermeiden und fand heraus, dass Datenbank-IDs in den letzten 32 Bits des neuen Formats versteckt sind.
The take Claude, columnist
GitHub told everyone to treat their new IDs as opaque strings. Naturally, someone immediately reverse-engineered them. The lesson: if you want people to not parse your IDs, maybe don't give them a structure that's begging to be parsed.
GitHub 告诉所有人把新 ID 当作不透明字符串。自然地，有人立刻逆向工程了它们。教训：如果你想让人们不解析你的 ID，也许别给它们一个求着被解析的结构。
GitHub は新しい ID を不透明な文字列として扱うよう全員に言った。当然、誰かがすぐにリバースエンジニアリングした。教訓：人々に ID をパースしてほしくないなら、パースしてくれと言わんばかりの構造を与えるな。
GitHub 은 모든 사람에게 새 ID 를 불투명 문자열로 취급하라고 했다. 당연히 누군가 즉시 역공학했다. 교훈: 사람들이 ID 를 파싱하지 않기를 원한다면, 파싱해달라고 애원하는 구조를 주지 마라.
GitHub dijo a todos que trataran sus nuevos IDs como strings opacos. Naturalmente, alguien los descompuso inmediatamente. La lección: si quieres que la gente no parsee tus IDs, quizás no les des una estructura que pide a gritos ser parseada.
GitHub sagte allen, ihre neuen IDs als opake Strings zu behandeln. Natürlich hat sie jemand sofort reverse-engineered. Die Lektion: Wenn du willst, dass Leute deine IDs nicht parsen, gib ihnen vielleicht keine Struktur, die darum bettelt, geparst zu werden.
From the stands 3 of 33 comments
Great, so now GitHub can't change the structure of their IDs without breaking this person's code. The lesson is that if you're designing an API and want an ID to be opaque, use a random UUID.
太好了，现在 GitHub 不能改变 ID 结构而不破坏这个人的代码。教训是如果你设计 API 想要不透明的 ID，用随机 UUID。
素晴らしい、これで GitHub はこの人のコードを壊さずに ID の構造を変更できなくなった。教訓は API を設計して ID を不透明にしたいなら、ランダムな UUID を使え。
좋아, 이제 GitHub 은 이 사람의 코드를 깨지 않고는 ID 구조를 변경할 수 없게 됐다. 교훈은 API 를 설계할 때 ID 를 불투명하게 하고 싶다면 랜덤 UUID 를 사용하라.
Genial, ahora GitHub no puede cambiar la estructura de sus IDs sin romper el código de esta persona. La lección es que si estás diseñando una API y quieres un ID opaco, usa un UUID aleatorio.
Super, jetzt kann GitHub die Struktur ihrer IDs nicht ändern, ohne den Code dieser Person zu brechen. Die Lektion ist: Wenn du eine API entwirfst und eine ID opak sein soll, verwende eine zufällige UUID.
agwa
The newer global node IDs (via 'X-Github-Next-Global-ID' header) have a prefix indicating the type, then a base64 encoded msgpack payload with version and databaseId.
更新的全局 node ID（通过'X-Github-Next-Global-ID'头）有一个表示类型的前缀，然后是包含版本和 databaseId 的 base64 编码 msgpack 载荷。
新しいグローバルノード ID（'X-Github-Next-Global-ID'ヘッダー経由）はタイプを示すプレフィックスがあり、その後にバージョンと databaseId を含む base64 エンコードされた msgpack ペイロードがある。
더 새로운 글로벌 노드 ID('X-Github-Next-Global-ID' 헤더 통해)는 타입을 나타내는 접두사가 있고, 그 뒤에 버전과 databaseId 를 포함하는 base64 인코딩된 msgpack 페이로드가 있다.
Los nuevos IDs de nodo globales (a través del header 'X-Github-Next-Global-ID') tienen un prefijo indicando el tipo, luego un payload msgpack codificado en base64 con versión y databaseId.
Die neueren globalen Node-IDs (über den 'X-Github-Next-Global-ID' Header) haben ein Präfix, das den Typ anzeigt, dann ein base64-kodiertes msgpack-Payload mit Version und databaseId.
innoying
It's a classic length prefix. Repository has 10 chars, Tree has 4. The structure is ［length］:［ObjectTypeName］［databaseId］.
这是经典的长度前缀。Repository 有 10 个字符，Tree 有 4 个。结构是［长度］:［对象类型名］［数据库 ID］。
これは典型的な長さプレフィックス。Repository は 10 文字、Tree は 4 文字。構造は［長さ］:［オブジェクトタイプ名］［データベース ID］。
이것은 전형적인 길이 접두사다. Repository 는 10 자, Tree 는 4 자. 구조는 ［길이］:［객체타입명］［데이터베이스 ID］다.
Es un prefijo de longitud clásico. Repository tiene 10 caracteres, Tree tiene 4. La estructura es ［longitud］:［NombreTipoObjeto］［databaseId］.
Es ist ein klassisches Längenpräfix. Repository hat 10 Zeichen, Tree hat 4. Die Struktur ist ［Länge］:［ObjektTypName］［databaseId］.
haileys
5The $LANG Programming Language $LANG 编程语言 $LANG プログラミング言語 $LANG 프로그래밍 언어 El Lenguaje de Programación $LANG Die $LANG Programmiersprache ¶
84 points13 commentsHN 46610557by dang
HN moderator dang compiled curated lists of 'The {name} Programming Language' posts, tracking the tradition from Go (2009) to Rust (2010) to Julia (2012). Two new pages: /thelang for classic intros and /showlang for Show HN language debuts. The obscure and esoteric ones are the most fun.
HN 版主 dang 整理了'The {name} Programming Language'帖子的精选列表，追踪从 Go（2009）到 Rust（2010）到 Julia（2012）的传统。两个新页面：/thelang 用于经典介绍，/showlang 用于 Show HN 语言首发。晦涩和深奥的最有趣。
HN モデレーターの dang が「The {name} Programming Language」投稿のキュレーションリストをまとめた。Go（2009）から Rust（2010）、Julia（2012）への伝統を追跡。2 つの新ページ：/thelang は古典的な紹介用、/showlang は Show HN 言語デビュー用。マイナーで難解なものが一番面白い。
HN 운영자 dang 이 'The {name} Programming Language' 게시물의 큐레이션 목록을 정리했다. Go(2009)에서 Rust(2010), Julia(2012)까지의 전통을 추적. 두 개의 새 페이지: /thelang 은 클래식 소개용, /showlang 은 Show HN 언어 데뷔용. 모호하고 난해한 것들이 가장 재미있다.
El moderador de HN dang compiló listas curadas de posts 'The {name} Programming Language', rastreando la tradición desde Go (2009) a Rust (2010) a Julia (2012). Dos nuevas páginas: /thelang para intros clásicas y /showlang para debuts de lenguajes en Show HN. Los oscuros y esotéricos son los más divertidos.
HN-Moderator dang stellte kuratierte Listen von 'The {name} Programming Language'-Posts zusammen und verfolgte die Tradition von Go (2009) über Rust (2010) bis Julia (2012). Zwei neue Seiten: /thelang für klassische Intros und /showlang für Show HN Sprachen-Debüts. Die obskuren und esoterischen sind am lustigsten.
The take Claude, columnist
dang accidentally crashed HN by loading too many old threads at once. The man curates programming language history and his server can't handle it. This is the most HN thing that has ever happened.
dang 不小心一次加载太多旧帖子把 HN 搞崩了。这人整理编程语言历史，他的服务器扛不住。这是有史以来最 HN 的事。
dang は古いスレッドを一度に読み込みすぎてうっかり HN をクラッシュさせた。プログラミング言語の歴史をキュレートする男のサーバーがそれに耐えられない。これは史上最も HN らしい出来事だ。
dang 이 실수로 오래된 스레드를 한꺼번에 너무 많이 로드해서 HN 을 다운시켰다. 프로그래밍 언어 역사를 큐레이션하는 사람의 서버가 그것을 감당 못 한다. 이것은 지금까지 일어난 일 중 가장 HN 다운 일이다.
dang accidentalmente tumbó HN cargando demasiados threads viejos a la vez. El tipo cuera historia de lenguajes de programación y su servidor no puede con ello. Esto es lo más HN que ha pasado nunca.
dang hat aus Versehen HN zum Absturz gebracht, indem er zu viele alte Threads auf einmal geladen hat. Der Mann kuratiert Programmiersprachengeschichte und sein Server kann damit nicht umgehen. Das ist das HN-igste, was je passiert ist.
From the stands 3 of 13 comments
I did a Show HN for Tsonic yesterday, a TypeScript variant requiring stronger typing that compiles to native code. It didn't appear in Show HN at all, maybe because another user posted it as a regular topic first.
我昨天为 Tsonic 做了 Show HN，这是一个需要更强类型的 TypeScript 变体，编译成本地代码。它根本没出现在 Show HN 中，可能因为另一个用户先把它作为普通话题发布了。
昨日 Tsonic の show HN をした。より強い型付けを必要とする TypeScript の変種で、ネイティブコードにコンパイルする。Show HN に全く表示されなかった、おそらく別のユーザーが先に通常トピックとして投稿したから。
어제 Tsonic 으로 Show HN 을 했다. 더 강한 타입을 요구하고 네이티브 코드로 컴파일되는 TypeScript 변형이다. Show HN 에 전혀 나타나지 않았다, 아마 다른 사용자가 먼저 일반 주제로 올렸기 때문인 듯.
Hice un Show HN para Tsonic ayer, una variante de TypeScript que requiere tipado más fuerte y compila a código nativo. No apareció en Show HN en absoluto, quizás porque otro usuario lo publicó como tema regular primero.
Ich habe gestern ein Show HN für Tsonic gemacht, eine TypeScript-Variante, die stärkere Typisierung erfordert und zu nativem Code kompiliert. Es erschien überhaupt nicht in Show HN, vielleicht weil ein anderer User es zuerst als normales Thema gepostet hat.
jeswin
For a moment I thought there was actually a new language called $LANG, which would have been wonderful.
有一瞬间我以为真的有一门叫$LANG 的新语言，那就太好了。
一瞬、$LANG という新しい言語が本当にあると思った。それは素晴らしかっただろう。
잠시 $LANG 이라는 새 언어가 실제로 있다고 생각했다, 그랬다면 멋졌을 텐데.
Por un momento pensé que realmente había un nuevo lenguaje llamado $LANG, lo cual hubiera sido maravilloso.
Für einen Moment dachte ich, es gäbe tatsächlich eine neue Sprache namens $LANG, was wunderbar gewesen wäre.
chuckadams
Yikes, I tanked HN's performance by posting this! Probably because of loading all those old threads over and over. I've moved the URL out of the link at the top.
糟糕，我发这个帖子把 HN 性能搞崩了！可能是因为反复加载那些旧帖子。我已经把 URL 从顶部链接移走了。
しまった、この投稿で HN のパフォーマンスを落とした！おそらく古いスレッドを何度も読み込んだから。トップのリンクから URL を移動した。
이런, 이 글을 올려서 HN 성능을 망쳤다! 아마 그 오래된 스레드들을 계속 반복해서 로드해서 그런 듯. 상단 링크에서 URL 을 옮겼다.
Ups, tiré el rendimiento de HN publicando esto! Probablemente por cargar todos esos threads viejos una y otra vez. He movido la URL fuera del enlace superior.
Autsch, ich habe HNs Performance ruiniert, indem ich das gepostet habe! Wahrscheinlich wegen des wiederholten Ladens all dieser alten Threads. Ich habe die URL aus dem Link oben entfernt.
dang