1. 16
    1. 4

      The article basically describes my own business and the last decade of my life. For every complex thing, I just ask “Why?” and “What’s the simplest possible thing that is required?”

      In my case, it’s allowed me to get away with some pretty simple moving parts. My servers handle 99% static files and have no 24/7 app server running as I use Ruby CGI scripts for anything dynamic. My “database” is a CSV on the filesystem. Almost all billing is outsourced to Stripe, a good example of punting completely on a necessarily complex dependency. In the end, each server costs me $5/mo and requires no regular maintenance. Every six months I tear down the oldest server and build a new server, which takes about 10 minutes.

    2. 2

      I like the idea of integrating comments via an external website (HN in this case, but lobste.rs would be suitable, too). I think it definitely adds some moderation as not all comments necessarily are relevant to your articles as they tend to drift off topic-wise a couple levels deep, but it would offload some maintenance and moderation to the link aggregator and the team.

      Now I am wondering whether it’s easy to access lobste.rs via an API… Or the mailing list mode or RSS feeds…

      1. 6

        You can simply append .json to current story URL to get JSON-formatted list of all comments:


        1. 1

          That’s cool, thank you for the hint!

    3. 1

      The biggest piece is minimizing your dependencies, and limiting them to ones that value backwards compatibility.

      This seems like an oversimplification. If you find yourself reinventing a rather complicated wheel, ask yourself if you would rather maintain your own reinvented wheel or risk being stuck with an old version of someone else’s. For professional projects, consider it is not only you who will have to live with this decision.

      1. 6

        Maintenance costs are remarkably low when upstream can’t break things due to CADT.

      2. 6

        I’ve been working on a 14-year-old ruby-on-rails project for the past three years.

        As far as dependencies go, I’ve learned to actively avoid dependencies unless they meet one of the following:

        • The core team of maintainers (who are not all employed at the same company) have clear process in place around release, compatibility, etc
        • The sole maintainer has a great track record of backwards compatibility
        • The project is unmaintained but is uses simple enough code that I can keep it updated

        Nearly every dependency in this app which does not meet one of those criteria has created more work in the past three years than simply writing the dependency from scratch would have.

        1. 2

          I don’t see how that’s the case when you can just fork them if you plan on doing your own maintenance.

          1. 3

            Occasionally I do have to fork to maintain. That’s typically the worst case though, and almost always has a higher TCO than having written something 10x smaller and simpler that only solves the problems my app has.

          2. 2

            then you still have the “discoverability problem” that when someone finds a security problem it will be scripted asap. If you have written your own, the attackers might never find it, unless you’re directly targeted or it’s easily wormable due to having something in common.

            I have no numbers but I’m pretty sure there’s a lot of XSS still running around in pages that have been online for 20 years where people use echo $_POST['name'], but nobody never stumbled over them, versus an old version of some, say, forum software with hundreds or thousands of installations.

      3. 5

        For professional projects, consider it is not only you who will have to live with this decision.

        Except that this article is explicitly about personal projects, mentioned at the start and the end.

        To quote Chelsea Troy, before giving critique:

        QUESTION #1: Is this piece for me?

        Consider that the article has clearly laid out its scope and context.

        Granted, careful choice of which wheels get reinvented is important, but these days, I do think the pendulum has mostly swung the way of using existing software in one form or another.

        1. 2

          I totally deserved this reply. I have spent a lot of time maintaining poorly reinvented wheels, so my reaction was a bit knee-jerk. I did read the first paragraph but I missed the last one.

          1. 1

            I do hope you’ve been able to find less poorly reinvented wheels to maintain of late.