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 生成,可能有误。

    编程与软件工程blog.miguelgrinberg.com

    Flask 大型教程

    The Flask Mega-Tutorial

    3次上首页
    9年跨度
    651累计得分
    183条评论

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

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

    导读

    这个页面是 Miguel Grinberg 的《Flask Mega-Tutorial》第一部分,从 Hello World 开始,带读者逐步用 Flask 构建 Web 应用。整套教程以步骤清晰、贴近实战著称,后续章节会扩展到更完整的应用结构、认证与部署等主题。

    为什么经久不衰:它把 Flask 的核心概念放进一个可跟着做的完整项目里,难度循序渐进且多年持续更新,至今仍是 Python 开发者转向 Web 开发的高质量起点。

    关键词 FlaskPythonWeb开发教程

    HN 评论精选

    建议用 requirements.txt 管理依赖,而不是逐条手动安装。

    我认为这是非常糟糕的建议。应该创建一个 requirements.txt 文件,把需要的库逐行列进去,然后用 `flask/bin/pip install -r requirements.txt` 安装。更多信息见 pip 文档。

    randomchars查看英文原文

    > If you are on Linux, OS X or Cygwin, install flask and extensions by entering the following commands, one after another I think this is a really bad advice. Instead create a file called requirements.txt and add the required livraries, one per line. Then you can install it with flask/bin/pip install - r requirements.txt Edit: More information in the documentation[0] [0]: http://www.pip-installer.org/en/latest/requirements.html

    分享了一套更集中管理路由、蓝图前缀、Alembic 迁移和分环境配置的项目组织方式。

    我更喜欢把路由放在单独文件里。不用 @app.route 装饰器,而是维护一个 routes 数组(如 ('/', endpoint='index', view_func=index)),这样所有路由集中一处,方便查找,也给每个 endpoint 显式命名。蓝图同理:每个蓝图有自己的 urls.py,且不写 URL 前缀(比如评论蓝图只定义 '/',而不是 '/comments'),前缀交给主应用通过 app.register_blueprint(comment, url_prefix='/comment') 注册。迁移方面我更喜欢 Alembic 而不是 SQL 迁移;它比直接用 SQLAlchemy 更简单,能根据模型定义自动生成迁移,增改模型后运行 Alembic 即可。配置上我维护 settings.py、dev_settings.py、prod_settings.py:settings.py 放公共配置,未指定环境时导入 dev_settings,否则按环境导入。我还喜欢把 BEFORE_REQUESTS、AFTER_REQUESTS、MIDDLEWARES、LOG_HANDLERS、TEMPLATE_FILTERS、CONTEXT_PROCESSORS、ERROR_HANDLERS 等放在配置里,在 main.py 中调用对应函数,这样不用到处翻代码。

    irahul查看英文原文

    I prefer keeping routes in a separate file. Instead of @app.route('/') def index(): pass I keep a routes array routes = [ ('/', endpoint='index', view_func=index) ... ] I find it a lot pleasant to look up all routes at the same place rather than guessing or searching. Also, I give an explicit name to all endpoints. I do the same with blueprints. Blueprints have their own urls.py, and blueprints don't specify the url prefix. For eg, a comment blueprint will define '/', rather than '/comments'. I leave the url prefix to the main application. app.register_blueprint(comment, url_prefix='/comment') For migrations, I prefer alembic to sql migrations - https://alembic.readthedocs.org/en/latest/tutorial.html I find Alembic simpler than SQLAlchemy(without compromising on power). Alembic can autogenerate migrations based on your model definitions. The way I work is I add a new model, and then run alembic to autogenerate the migration. Same goes for altering models. For settings, I maintain setting.py, dev_settings.py, prod_settings.py. settings.py contains all the common settings. If environment is not defined, I do a `from dev_settings import *`, else I do a relevant import for the environment. I also prefer having BEFORE_REQUESTS, AFTER_REQUESTS, MIDDLEWARES, LOG_HANDLERS, TEMPLATE_FILTERS, CONTEXT_PROCESSORS, ERROR_HANDLERS... in settings, and in main.py, call the relevant functions. That way, I don't have to hunt down the codebase. For blueprints, I define the same variables in __init__.py. Model forms are another time saver(use wtforms, or preferably flask-wtform) from flask.ext.wtf import Form from wtforms.ext.sqlalchemy.orm import model_form import models PostForm = model_form(models.Post, models.db.session, Form, field_args = { 'name': {'validators': []}, 'title': {'validators': []}, 'content': {'validators': []}, }) models.Post is flask-sqlalchemy model, models.db.session is sqlalcheymy session. You don't need to list all model fields for your model form. I find keeping models and forms in sync a pain. This way, I only keep the validations in sync(field_args isn't required - that's an example of adding validations). I use flask-debugtoolbar for basic profiling and debugging. flask-webassets is awesome for managing assets and dynamic compilation. flask-script for writing manage.py jobs(python manage.py get_deps, python manage.py db_createall etc etc)

    教程足以支撑实际 Flask 应用;Flask 心智模型清晰,但 WSGI 部署(如 Gunicorn)仍是主要门槛。

    我可以佐证 Miguel 的教程相当不错,足以用来构建 Flask 应用。多亏 Miguel(以及 Flask 官方文档),我现在有一些 Flask 应用已经连续运行好几年了。Flask 写起来非常容易,因为心智模型很好跟。当然里面也有魔法,但抽象看起来并不“漏”。相比之下我进入不了 Django,因为它似乎有太多魔法。使用 Python 做后端最糟糕的部分是部署:搭建 WSGI 服务器来托管 Python 应用有点痛苦。我想我选了 Gunicorn,但那里有一点学习曲线,我甚至不确定那是不是正确选择。

    sireat查看英文原文

    I can second that Miguel's tutorial is quite nice and sufficient to build Flask apps. Thanks to Miguel (and also official Flask docs) I have some Flask Apps running non stop for a few years by now. Flask is extremely easy to write in regards that the mental model is easy to follow. Sure there is magic there but the abstractions seem "non-leaky". By contrast I can't get into Django because it seems too much magic. The worst part of using Python for back end was deployment. Setting up WSGI server to host Python apps was a bit of a pain. https://flask.palletsprojects.com/en/2.1.x/deploying/ I think I went with Gunicorn but there was a bit of learning curve there. I am not even sure if that was the right choice

    更新版付费指南值得作为大型应用起点,但部分章节(如认证)并非生产级优化。

    Miguel 已经更新了这份指南(需要购买)。在我看来,作为构建较大 Flask 应用的起点,它每一分钱都值,但其中也有一些内容并未针对生产级 Flask 应用做优化(例如认证相关章节)。

    ryannevius查看英文原文

    Miguel has updated this guide (available for purchase). In my opinion, it's worth every penny as a starting point into building larger Flask apps, but does include some material that isn't optimized for production-ready Flask apps (e.g. the chapters on authentication).

    历次讨论

    同类还值得读

    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

    关注向阳乔木

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

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

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