You can just use the web server that is already running on the machine.
You (normally) don't want downtime in your website, so you just let your regular webserver serve the acme challenge instead of stopping it.
897 karma · joined April 8, 2019
You (normally) don't want downtime in your website, so you just let your regular webserver serve the acme challenge instead of stopping it.
But now that you mention it, I wonder what's the opinion of security experts like tptacek on cert renewal automation.
Their FAQ [1] recommends exactly that: renewing every 60 days.
[1] https://letsencrypt.org/docs/faq/#what-is-the-lifetime-for-l...
LetsEncrypt renewal is supposed to be automated. [1]
I know of a company that hosted blogs for thousands of customers. They used LetsEncrypt, but the CTO considered automatic renewals a possible security risk, so they did it manually. Problem is, the expiration happened in a weekend and they "forgot" to update the certificates before that. Suffice to say that the next Monday wasn't pleasant. They automated after that.
> Temporary work around till the cert gets fixed: set "xpinstall.signatures.required" to false
> This is what's frustrating about trying to have this discussion (and it's covered in the article): "The problem, in this case, is that most programmers have limited experience, and haven’t tried a lot of languages."
Friend, this is completely uncalled for. A single HN answer doesn't say anything about my experience with multiple languages.
Instead of adding types gradually to a dynamic language (like Typescript sorta does with Javascript), we could add type-checking features that enable a kind of "statically-checked duck typing". Complete inference (like Elm, Crystal or Haskell) gets you halfway there – most of the time you don't have to write method/function signatures.
Then add structural typing like Extensible Rows [1] or Elm Records [2], or something that type-checks based on the structure instead of classes, and it allows you to have the compile-time type-checking of Interfaces or Generics/Templates without the extra typing. Then you can add explicit generics/templates later if you want.
Both Crystal and Elm get very close to that for me, but not 100%. I honestly think that this is a safer bet than gradual typing that could lead to very similar results, but I don't know how feasible or acceptable to mainstream programmers this is.
[1] https://github.com/tomprimozic/type-systems/tree/master/exte...
I could just say that every time the compiler refuses to compile my code due to a type error a bug is averted. Typos, wrong method signatures, interfaces not implemented correctly. All those things had the potential to be bugs. Small, detectable and perhaps even non-breaking, but it's still good to catch them early on.
And of course, most of the time a good enough test suite would catch them. But having the compiler warning you is so much faster! And much more reliable too, because I'm not perfect and sometimes I make mistakes in my tests.
I rarely use IDEs, but compile-time checks are super useful for me during refactoring.
Sometimes I need to rename a class, a method name or a method signature that is used all over the program. I could use tests, but the compiler is much faster and much more comprehensive. So I change everything in one go and then only run the tests after that.
The speed in itself is great, and helps me get much faster feedback than I can get with tests. It's also great during explorational programming, or during the prototype phase: some errors can be detected during compilation, so I'm not greeted with an easily avoidable runtime error.
As for an example of a bug that would have been prevented by compile-time checking, I had one happen just last week. It was in a project with 100% test coverage, but we had undetected refactoring errors due to a lack of integration testing: there were (good) unit tests with mocks, but we missed them during refactoring, triggering a runtime error in production. We fixed that by writing a few simple integration tests and fixed the code. This happened just last week. No biggie, but would be avoided by a compiler.
You can just open "index.html" in your browser and it will run fine, as longs as the paths inside your files are relative.
You might have to reconfigure your bundler. If you're using Parcel, just pass `--public-url .` as a command line option when building. For Webpack use the publicPath configuration, etc.
But remember that pages accessed via file:/// have limited permissions: you can't use localStorage, access some sites using CORS, can't capture audio/video, etc. But if you're not using these things then it's fine.
All those things are acceptable to most people who block ads, IMO.
It makes a lot of sense to decouple parsing from the rest of the compiler, if only purely from an engineering standpoint.
Editors, IDEs and other tools (transpilers, linters, formatters) already have to reimplement the parser, or at least hook into some API. Having them interact directly with the AST is a huge bonus. Sure, you'd have to rewrite your diffing algorithm to use a tree, but it seems minor compared to the cool things we'd get.
As long as you have a sane AST specification (the HARDEST part, IMO) you'd be able to have teams with people working in a Python-like syntax, others working with a LISP-like syntax, and so on, as long as internal semantics are the same (again, the hardest part).
Instead of having thousands of crappy compilers we'd have pluggable parsers emitting ASTs. This is much better for experimenting with Developer Experience and trying out new things.
Even the typing system could be decoupled: adding a borrow checker or dependent types wouldn't require writing a new language or forking an existing one, so they would be reusable, as long as the AST supports it. Running a linter during a compilation process would also be trivial.
And we would be able to reuse optimizations, code generation, interpreters.
We complain so much about "vendor lock in" but this has potential to remove the language lock-in that we have. Sure, we'd still be able to get locked-in to frameworks and libraries, but that's something to solve another time.
--
OT: I actually had a similar experience back in the 2000s when we had to convert a large VB.NET codebase to C#: we used the first crappy "convert VB.NET to C#" site we could find online and it did the job amazingly well. Fun times.
"Plan to Throw One Away"
Programming intent and vision is hard to communicate, so sharing code is always a compromise. It's much better to work with smaller units of code that communicate with each other using simple, clear and testable APIs.
Put non-coders to work under the chief programmer. Let them help instead of control.
Microsoft approach was more about having senior programmers telling juniors what and how to do their job, aka micromanagement.
Brooks is about having programmers actually coding (and documenting), and have other people handling and other important tasks such as clerical non-programming tasks, developing tools, language research, version management, doing adversarial testing, helping with documentation, etc. Some of the tasks he describe are obsolete these days, but the book is from the early 70s.
According to him, doing that "relieves programmers of clerical chores, systematizes and ensures proper performance of those oft neglected chores, and enhances the team's most valuable asset — its work-product".
This is similar to what Fred Brooks suggests in the "Surgical Team" chapter of "Mythical Man Month", although he's a bit harsh, I'll grant that:
> if a 200-man project has 25 managers who are the most competent and experienced programmers, fire the 175 troops and put the managers back to programming.
EDIT: We were also talking about it yesterday here at HN: https://news.ycombinator.com/item?id=19763562
And I don't think that having other members of the team supporting the vision of the leader is monopolizing the vision... it's just being focused on a single goal.
I'd change the headline to "1MB – Free and easy static website hosting and database".
That database is the edge you have compared to Netlify and Github pages people are asking for :)
The authentication part is a nice touch, too. Feels more like a community thing.
Checked out the API and you even have easy to setup database permissions. I like it.
-
Questions: do you plan to offer paid plans for people wishing to host more than 1MB, or having paid support? Maybe paid private login workspaces and SSO could be a paid feature too.
Git integration is like Heroku. The user types `git push 1mbsite master` and 1mbsite would publish it.
> Much as a surgical team during surgery is led by one surgeon performing the most critical work, while directing the team to assist with less critical parts, it seems reasonable to have a "good" programmer develop critical system components while the rest of a team provides what is needed at the right time.
Other team members perform other tasks, and some of those even administrative (!), but all of them supporting the "vision" of the surgeon.
IMO this is a healthier way of communicating roles, avoiding fights and training juniors. It's better than the "everyone is replaceable" mindset companies have this day.