Threads for freeformz

    1. 7

      My uses Emacs to generate the HTML, and then nginx to serve it. I have used various systems through the years, but this is the one that really stuck with me. Emacs is flexible enough that I’m unlikely to outgrow it any time soon, and the language is convenient enough to script in. I really like it!

      1. 3

        how do you use emacs to generate html? I didn’t know it could do that. So you just literally put your html files onto a server and host it. So simple, I can’t believe I never thought of it.

        Thinking out loud here, what would be the steps to protect your identity in that situation?

        1. 43

          So you just literally put your html files onto a server and host it. So simple, I can’t believe I never thought of it.




        2. 9

          At one point in time the idea of generating HTML from a program seemed odd. It’s amazing that code gen for HTML is so obvious now that the idea of typing it out by hand is not. Surely there’s a word for this phenomenon?

          1. 9

            It’s it called “FrontPaging”?

          2. 1

            Analogous to machine/assembly code generation, I suppose, although I don’t think the idea of generating them was ever odd, given how difficult they are to work with.

            “Abstraction ignorance”?

            1. 1

              First, there were Frontpage, Dreamweaver, HomeSite like tools that were WYSIWYG, and “purists” used notepad. Then there were the CGI scripts (which typically hand rolled the dynamic content with string bashing), and included headers and footers, and people used SSI. Then, things in the vein of Blogger, MovableType and (probably many that I am forgetting! Including many Perl libraries that formed the basis of these things, surely) introduced “real” languages meant for the types of templates we know of today, that you didn’t have to be super nerdy to use and understand. It was certainly not immediately obvious to most people…

        3. 6

          HTML is just normal text, so emacs can just write a pile of bytes and if the file ends in html and the syntax is correct then you’re good to go.

          As far as identity stuff, the file itself doesn’t have any metadata about you in it (unless you added it), so you’ll just need to make sure your server isn’t broadcasting things about you it shouldn’t and that your domain records are through a company, friend, or privacy guard.

    2. 1

      I hope it works well, it doesnt really seem like many of the people i trust from the go team are working on it. I suppose google doesnt use a tool like this internally.

      1. 1

        I’m not sure where you heard that, but I’ve worked with several of the people on the team and they are excellent. I’m really excited for the tool.

        Google will either work from tip on every project (hence the support for aliasing, and the need to do large scale transformations across their multimillion line codebase), or use this tool for vendoring. They run Go betas and release candidates in production, there’s no reason they’d use a different or an adhoc tool.

        1. 1

          My concern is it won’t be supported to the same degree as the rest of Go, it mostly seems to be developed by Edward Muller (someone not at google), who may well be doing it on his hobby time.

          I looked at the contributor graph on the repo - Very few of the high ranking core team members on googles payroll have touched it much or at all (Russ Cox, Brad Fitz., Rob Pike, Robert Griesemer, Alan Donovan, Robert Griesemer, Andrew Gerrand …. etc), Even contributors I know who care about package management systems like Dave Cheney are not there (who wrote gb). I personally doubt google cares much because it has its own giant VCS repo where they vendor everything.

          1. 7

            Edward Muller here….

            dep is part of a project that started last year, largely by Peter Bourgon. I was asked to join the team working on this project due to my involvement in a different tool: godep the OG dependency management tool for Go, which I inherited maintenance of from Keith Rarick & my work @ Heroku serving our customers who use Go. The other members of the team, aside from myself and Peter, are Jessie Frazelle, Andrew Gerrand and Sam Boyer. Andrew is part of the Go team @ Google. Jessie works at Google and is involved in large Go projects such as Docker and Kubernetes, among others. Sam wrote and maintains gps the SAT solver powering glide and dep.

            This team has published a bunch of info about our progress over the course of our work:

            To date, various other tool authors and concerned parties have also been involved in different ways.

            In the end I’d say I’ve played a role in the development of dep, having contributed directly, indirectly by patching gps or via pairing sessions with other team members, but I would not say that the tool is being developed mostly by me in any way. My hope is that we can attract additional contributors to dep as soon as possible. As such I invite all Go users (especially the maintainers of other tools) to participate in the development by filing well researched issues, opening PRs and testing the tool on their own projects and repositories.

            FWIW: The hope is that this tool sets the ground work for things to come as part of the go language distribution in the future, something I’ve also made minor contributions to in the past,

            PS: I am not speaking for the Go team here, just myself.

            1. 1

              Thanks for the reply - How usable is the tool currently?

              edit: trying it now, the wording of the readme made me think it wasn’t even usable at all. “Typical usage on a new repo might be” made me think it wasn’t implemented yet.

              edit2: Really happy it worked out of the box with one of my projects. Neat.

              1. 1

                Great! It’s totally a work in progress. ;-)

          2. 4

            Heroku hat time (though, I don’t have one).

            Edward Muller, specifically works on this as the language maintainer of Go at Heroku. He spends time on it for these reasons, among others I can’t speak to:

            1. We have customers who would like to run Go apps on Heroku. Standard, accepted tooling reduces support burden and makes documentation, and support tooling much easier to maintain.
            2. Heroku uses Go heavily internally. From the implementation of orchestration, to the custom metrics/monitoring stack I help build and maintain, to the git server that you push to to deploy…and everything in between.
          3. 1

            If you look at the Go Packaging Proposal Process document, you’ll see that Andrew Gerrand, Dave Cheney, etc were all involved in the design.