HN user

davalapar

87 karma
Posts2
Comments15
View on HN

There are bunch of them, really.

But for general structure, using your end-user's user experience path (from start to end) as a guide and avoiding buzzwords as much as you can usually help. Think of Stripe's documentation, you want something as easily digestible as that.

- Software Design Patterns: https://en.wikipedia.org/wiki/Software_design_pattern

- Azure Application Architecture Guide: https://docs.microsoft.com/en-us/azure/architecture/guide/

- Azure Cloud Design Patterns: https://docs.microsoft.com/en-us/azure/architecture/patterns...

- Azure Architecture Framework: https://docs.microsoft.com/en-us/azure/architecture/framewor...

- Azure Cloud Adoption Framework: https://docs.microsoft.com/en-us/azure/cloud-adoption-framew...

- Cloud Computing Patterns: https://www.cloudcomputingpatterns.org/

- Microservice Architecture Patterns: https://microservices.io/patterns/index.html

- Amazon's Builders Library: https://aws.amazon.com/builders-library/

The sign-up requirement is a big onboarding hiccup.

Like yo, I don't even know what it really does yet, why are you asking me to create an account? Do you really expect your users to capture your value prop based on just screenshots alone?

Amazing inputs.

I'd also suggest a top-down approach where you start with a flexible end goal you'd want to achieve (e.g. be a full-stack dev), in which case you can start by babystepping a hands-on approach (e.g. learning javascript, learning client-side and server-side of things). Complimentary fundamental course outlines can also help, e.g. Comptia A+ gives you hardware fundamentals, Comptia Network+ gives you networking fundamentals, CloudAcademy can get you started on working with cloud providers like Azure/GCP/AWS, and so on and so forth.

It's easy to get lost in the theoretical side of things, being able to test them out in action as soon as you can could give you quite an ideal balance.

Lost it at page 4 figure 3 caption:

You can tell YOLOv3 is good because it’s very high and far to the left. Can you cite your own paper? Guess who’s going to try, this guy→[16]

This guy cites.

If the server got an issue with your request it can return 400 (Bad Request), which means that the server has received it successfully before acknowledging it as a bad one.

Even then, if the server returns 400 (Bad Request) the server can still attach a response body to that, in plain text/plain, application/octet-stream or even application/json, which could contain elaborate information.