Earlier quoted context omitted.
That would be an insult (either to php or to the other project, depending on which).
Maybe. But I read it so often in the last years. Next.js? PHP! AWS Lambda? PHP! Zero? PHP!
Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown
241–250 of 256 posts
Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown
#242Who is this for? Is the goal to enable people who don't know what they're doing at all to make applications? Maybe at a glance that is a laudable goal, but surely there is a point where, if you need so much handholding, you should consider either sitting down and learning what you need or making someone else is build it for you. Newbies? I guess that is possible, but I personally think that actually learning to use y…
This might seem silly if all you're use to is working on some startup's big app with a dozen other people, but for small orgs that need to run small programs for a long time it's a mess to maintain that stuff over the long term and to count on lone coders in small engagements to get right.
> Handing the control of everything to some 3rd party component
In the cases I describe, this ^^ is a great idea. Keeps maintenance of the common stuff in a common place. Everyone freaked out in this thread about there being a way to get at files outside the project root. Well the author fixed that in one place and now it's fixed for everyone. How many times does an error like that come up and go undetected and uncorrected when even an experienced node coder has to copy pasta so much stock plumbing for the 1000th time to spin up a small service for a small org?
Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown
#243Earlier quoted context omitted.
Thank you for creating this! I often find I had an idea and then spend 1-2 hours doing NOTHING towards the idea trying to future-proof what I'm writing to the max. That is a trait of mine I need to work on by itself but "zero" should help let convince me to "just try it with zero before you setup TypeScript/Angular/Vue/React/Cordova/Express/etc...". I saw your other comment about making it Apache/PHP level easy and a…
Thanks! I will def move .ts up the list. It should be easy to add.
Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown
#244Rule 35: Every year, someone somewhere will reinvent PHP or CGI or some combination of the two.
Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown
#245Earlier quoted context omitted.
> Some might imagine it as eschewing heedless amateurism in favor of mature professionalism. I don't fully understand what you're advocating, so I apologize if I am misinterpreting or mischaracterizing your position. But I can't imagine "mature professionalism" including berating or embarrassing another developer for creating a security hole. Some people do need that, but most don't. Many devs I've worked with are ho…
Berating someone is never helpful. Setting out to embarrass someone is never helpful. The goal should never be to blame someone. The goal should always to educate someone on what has happened, what exploits have been enabled, and how this could cause harm. One issue is that full-throated encouragement coupled with suggestions of problems couched in uncertainty is the Dale Carnegie approach. I suspect you're using it…
> The Carnegie approach thus described makes it very easy for devs to notice the encouragement and ignore the suggestions of criticism.
This is definitely true, I've seen it too. Definitely something to watch out for.
I guess at the end of the day I think it comes down to "know your audience." Similar to the Principle of Least Privilege I like to follow (what I call) the Principle of Least Criticism. Don't use any more criticism than what is necessary, but (and I suspect this is where we will both agree) you need to use enough criticism that the person understands your point.
Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown
#246Earlier quoted context omitted.
This was fixed literally the minute it was commented here. Securing any project is always a long-term and continuous effort. This project is brand new, I posted the repo publicly this morning. I frankly think this subthread is an overreaction. I don’t get the hate.
> This project is brand new, I posted the repo publicly this morning. Are you implying that you don’t think it’s ready for production use? If so, maybe you should do like a lot of projects, and warn about it loud and clear in the docs. It’s not clear at all that users should expect the type of blatant security problems that were discovered here.
People are allowed to screw up: it's how we learn. They got comments that pointed out flaws, they fixed them and posted a follow-up regarding that fix, why the hate? This person tried to make something cool, they learned important security lessons, and now have a deeper insight into what they made, and the world it operates in. How is this possibly a bad thing we don't want to have happen on HN?
Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown
#247Earlier quoted context omitted.
Berating someone is never helpful. Setting out to embarrass someone is never helpful. The goal should never be to blame someone. The goal should always to educate someone on what has happened, what exploits have been enabled, and how this could cause harm. One issue is that full-throated encouragement coupled with suggestions of problems couched in uncertainty is the Dale Carnegie approach. I suspect you're using it…
Ok, I think I understand your position better, and if so I agree. > The Carnegie approach thus described makes it very easy for devs to notice the encouragement and ignore the suggestions of criticism. This is definitely true, I've seen it too. Definitely something to watch out for. I guess at the end of the day I think it comes down to "know your audience." Similar to the Principle of Least Privilege I like to follo…
With that said there might be some significant limitations on the approach. The principle one is that it relies on knowing the individuals involved fairly well. This is easy in a close-knit and small startup environment! It could perhaps be more difficult in a sizable enterprise or open source context where you don't know the other party, don't have time to build a relationship, and/or can't rely on a long conversation to slowly build up to the least amount of criticism required. There's also the question of how to handle groups or meetings in which different people have different thresholds. When one person's minimum required might be someone else's excessive negativity and they're both in the room, there might not be a winning outcome with this approach.
Knowing your audience is an excellent and wise maxim to live by. It might not always be as simple to live by as could be hoped.
Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown
#248Earlier quoted context omitted.
Student projects
When you're learning, you need to also learn security implications of what you're writing. Insecure projects should never be allowed to pass.