As someone new to deployment this book was a great read. I learnt a breadth of new techniques (ssh, security (e.g. fail2ban, selinux, permissions), bash commands, dns and configuration of a vps) and i also liked, that the author gave advice on which tools could be helpful (e.g. Ansible).
The book however does not go into detail on these tools (ansible, terraform), its goal is to teach the basics of deploying an app on a linux vps.
Thanks for a nice review. The book is already long as it is, so I only provide some general ideas behind these tools. The path forward might be very different from person to person. Some will want to convert the Bash code to Ansible and some are already running Kubernetes clusters at work :)
> "The physical signals in wires and the electromagnetic waves are the basic building blocks of the link layer".
> So, what is a CPU anyway? A central processing unit (CPU) is your processor (or processor core).
> Nevertheless, making a thread-safe code unsafe is more than easy and so if your application works with threads in some ways, make sure things work as expected.
Cut the filler and just say what you're trying to say.
I hope the HN community will stop doing easy smackdown comments like this.
Someone spent a ton of time on this product. It's exciting and terrifying at the same time to post it on HN. That "terrifying" is completely unnecessary, and 100% caused by reactions like yours.
At the very least, please write a "shit sandwich" next time.
[Mandatory "Yada yada yada, I don't know the author, not affiliated to the product, bla bla" here.]
Without addressing deployment canaries, exponential deployments, exponential rollbacks, traffic steering, API load duplication to staging, IaaS/PaaS, 12factor apps, HA, scaling, fault injection, hot backups, cold (and tested) backups, DR/BCP, configuration management, CI/CD, monitoring, troubleshooting the entire stack, and SLAs, it doesn't seem to me like a professional-enough treatment to celebrate.
I got the impression that the book is oriented to solo entrepreneurs building their own Saas (perhaps I got that wrong). What you have described sure sounds like good standards to follow by an entire infrastructure team, but a bit too much for solo devs doing infra stuff.
This. The book was called Deployment for Makers before, but I am taking it in a more general direction now. I wrote about some of the things mentioned above, but had to choose where I spend the time (it's already a long book).
There is a reason it's called "from Scratch", because I cover starting out. Some things bootstrapping startups don't need (there are only nice-to-haves). I will update and improve the text based on feedback, though (including the comment above).
Ad 12-factor. Some makers are better off not to follow everything. For example, it's fine to use server disk space for a single server. So I don't want to include it as dogma.
Ad CI/CD. You either build it yourself (and the book gives you the technical knowledge to do it) or use a vendor (GitHub/GitLab/Circle CI). I actually want to do a bit more on CI/CD, but thinking how to approach it.
I have not read all the book yet, but it definitely talks about some of these things (12factor app, canaries, scaling, logging, etc.).
It is a review of the most fundamental tools and strategies in Red Hat flavored Linux distros. Things like troubleshooting the entire stack would be far too advanced and specific.
I talk about some of it (like push vs pull approach to server configuration, containers or not, single server or not), but most likely not to the extend you are probably thinking of.
As for high availability I discuss whether it's worth it or not in the Scaling chapter. I also show how to use NGINX as a load balancer. I currently don't have HA content written for PG and Redis, but there are planned (as a free update).
2. It's included in the distribution and enjoys security fixes.
3. It's included in the distribution and shipped with good SELinux profile.
4. Since I use it to explain reverse proxy, I don't have to go into explaining new syntax (and people don't have to learn two different tools just for the sake of it).
Most people will prefer the reasons above to a better performance in theory (in theory, because I doubt NGINX will be your bottleneck).
Interesting about the total requests, but the article does not test.. balancing load? In a perfect world, 1 lb in front of 4 app servers should be able to serve 4x the requests as 1 lb in front of 1 app server.
So I'd imagine 4x nginx back-end servers, and a baseline hitting 1 nginx directly?
That, and the fact that the nginx config is shorter, and the performance not terrible (though terrible next to envoy in this test admittedly) - does mean nginx shouldn't be ruled out.
I am working through the book right now. It touches a lot of things, albeit superficially, to get you up and running. I have done plenty of deployments in the past so I do not need half of the book, but it has been helpful to put into context holes in my education (SELinux, Systemd, firewalls, etc.)
@strzibny, it would be great if you can put some curated links or references at the end of the book so the reader know where to go if they want to go deeper in that particular topic. It would really improve the value that some of us get from the book.
I am Josef, a full-stack developer, a formal Ruby Linux packager at Red Hat, and an author of Deployment from Scratch (which is this post about!).
After working at Red Hat and technically leading a start-up (of which I was the primary production engineer), I decided to write down a resource I felt was missing on the market:
A book that gives you the confidence to deploy your first application focused on fundamental, transferable, and long-lasting skills rather than tools of the day:
* You'll learn about networking, Linux, systemd, deployment strategies, web servers, application servers, databases, and containers.
* You'll be able to deploy Rails or Django applications (or anything really) together with production PostgreSQL and Redis databases. All automated with just a few lines of Bash.
What's unique about this book:
* It's a comprehensive book where things are designed to work together. I take readers from general networking knowledge to databases and containers. It's for beginners, but I am not skipping anything, not even SELinux.
* There are no abstractions, just Bash. I believe in learning the actual thing rather than an abstraction. Abstractions are great once you know what they are abstracting.
* Everything is done on Enterprise Linux with full SELinux support. While I have happy readers using Ubuntu, I thought the market doesn't have a good CentOS/Rocky/RHEL book.
There are three scripted demonstrations, cheatsheets, and a security checklist, apart from the book content. The demonstrations include:
* A git-push deployment of a database-backed Ruby on Rails application with Encrypted Credentials and Action Cable
* A self-sufficient PostgreSQL cluster with automatic system upgrades, log rotation, and TLS
With these demonstrations, you can be up and running quickly and also save a lot of money on Heroku :)
Stats so far:
* Took me more than 3 years to write (1+ year of fulltime billable time)
* Built a mailing list of more than 600 interested people
p.s. You can use "showhn" discount code at checkout for 20% off as a thank you to this community that put my posts several times on the HN frontpage ;)
Released 1-2 weeks ago, but it looks to me like a promising future - the new format of books that are more interactive. Website allows to run snippets, do interactive assessments, and so on.
Not interested in this book, but maybe you find my opinion of any value:
Your website comes off as hustle to get money without content:
* The first section where you describe your product, you avoid all that the product is, making me think you don't actually have content which you want to show off(the book image is digital with no mention of it being an ebook, the description is about me and tehnologies, no preview, no list of concrete things I learn)
* In the next section you continue marketing a dream instead of the actual content, then you sell reviews, a story and others' opinion. Again, I conclude that you don't want me to form my own opinion of potentially bad content.
* "What I'll get" is meta content, things I should see after being sold the content. At that point I clicked off the website thinking it's a scam.
Before commenting this I went one more time to make sure I didn't miss anything and discovered that you actually do have chapters content and preview, just past the point where I clicked off.
It was clear to me the content I was supposed to get.
The only reason I didn't purchase is because the value proposition "save time managing your own side-project/startup deployment" is not smart, to me at least.
I decided to pay and outsource most of these things away in order to focus on differentiating software, marketing/sales and peace of mind.
Edit: I also think the "start a career in SRE" is quite a long stretch.
> the value proposition "save time managing your own side-project/startup deployment" is not smart
I would say it's not right for all. But it's 100% true (from my readers) that people learn self-hosting to cut costs. That part of the page targets these people.
> I decided to pay and outsource most of these things away in order to focus on differentiating software, marketing/sales and peace of mind
I want to say that the saving angle is only one of the reasons pointed out. If you want to know how things work and don't care about saving, it's still worth to learn it.
I think you are not the target audience, though, since you want to focus on other aspects of the business which you probably enjoy more. :)
> I also think the "start a career in SRE" is quite a long stretch
The book shows you lot of Linux content you can find in RHCSA and RHCE exams. If you would really learn what's in it, you can be hired on spot for a junior role.
Those are fair points, I agree this is subjective. That's why I said "to me at least".
I've done this kind of work in the past and would certainly enjoy learning more. Your book was inviting. I just won't have the time at this moment. Need to focus elsewhere, as I said.
When thinking about business, the initial scale is quite small and managed services are cheap (and a variable cost) compared to the time I'd spend on self-managed (high upfront, fixed cost).
Thanks a lot for your feedback. Happy you found the time to write it.
I agree I should clarify it's an ebook sooner in text. And I want to redo the chapters. But I get a lot of conflicting feedback so hard to know what's right.
The page has a good conversion, though. So something is working.
Based on the table of contents and the preview pages it looks like it has some pretty good content. Made me think of "the missing manual" book series.
I just don't think small startups or side-projects should spend so much time getting all the configuration and moving parts right compared to just Docker+Terraform+(IaaS of choice). Then if one is on a tight budget, then just run Docker Compose on a single host, or run on a computer at home being proxied by Cloudflare free account. If able to spend more, then use the IaaS managed services like for containers and databases.
I guess I feel that setting people up to deploy with bespoke Bash scripts is borderline irresponsible since they won't be easily, or automatically, updated in case there are any other issues, unlike something like Terraform. I can't tell that easily however because there is no architectural diagram to help understand what the book leads up to as how one should deploy things.
However it seems more like it would be a better guide as "Linux Servers from Scratch"? That would be something which would be good reading for someone new to tech. Before moving onto higher abstractions. Or being used as the from scratch guide on how to customize container images by more experienced programmers, but those missing the Linux admin fundamentals.
I really believe that what I put into the book should be a knowledge a person deploying production application should have.
> I just don't think small startups or side-projects should spend so much time getting all the configuration and moving parts right compared to just Docker+Terraform+(IaaS of choice).
It's the opposite actually! I show you how to avoid a lot of indirection and have a deploy script in 200 lines of Bash that you understand in an afternoon.
If you choose to use Docker, I have a full chapter of building containers, doing Docker networking, running containers with the Docker engine or with Podman like any other systemd service.
You can then write a small Bash script to install Docker and deploy your container or write an abstraction in a tool like Ansible. That's your choice and I think I present good arguments for both.
> deploy with bespoke Bash scripts is borderline irresponsible
Only like 5% of the book spends time talking about how to glue everything with Bash. Most is networking, permissions, configuration. The idea is to see how things are done with the most basic building block which is a shell.
The thing is shell code is how you interact with your operating system unless you are using C API. It's what most deployment tools use under the hood, not to mention that many tools are basically Bash (ruby-install, chruby) or based around executing it (Dockerfile).
> However it seems more like it would be a better guide as "Linux Servers from Scratch"?
I already renamed the book twice :). Not anymore, please ;). Most people actually told me they don't care for the name at all. Yes, there is a lot of Linux, but I named it after the intent. The intent is to deploy at the end. The fact that most of the deployment is configuration is implementation detail.
Fair enough. :-) Like I said, my impression is that the content seems good! What I can't tell, without reading it, is what the end state of the dev/ops architecture would be along with its maintenance requirements, to understand if it would be a good complete resource to refer to beginners in tech I can't assist myself.
The main idea is building a single server deployment in a secure and maintainable way... and then possibly taking it to 5-10 servers at which point the Bash-only approach is less than ideal (but possible). Then you can pick a better tool of your choice (Ansible, Docker Swarm), but learning it is outside the scope of the book.
The demonstrations are made alongside the indie hackers/early-stage startup mindset. Run a single server, or possibly single server with a dedicated database.
> I just don't think small startups or side-projects should spend so much time getting all the configuration and moving parts right compared to just Docker+Terraform+(IaaS of choice).
Hype aside, I'd add serverless. One can build a lot of stuff with very little hassle on top of AWS Lambda, API Gateway, DynamoDB and S3.
> Took me more than 3 years to write (1+ year of fulltime billable time)
It shows - very polished. Have you described your process for writing the book anywhere? Given the quality of the landing page and samples, I'd also be interested in that.
I'd love to give this a read from someone with a lot of experience in the source material, but given a $50 pricetag for a book I don't need to read I'm not into it. Who are your editors?
Would you be interested in giving it a read in exchange for your feedback? I might be open to that (DM me https://twitter.com/strzibnyj).
I already lost more then one year of earnings working on the book and I couldn't afford a professional editor. So editors are only volunteers, and therefore I don't have a single editor for the whole book.
(I know that as a potential customer you don't care about my excuses, I am just explaining my situation. Earning money on technical content is hard.)
The pricetag doesn't reflect just the PDF, though. If you deploy your own database with the demo, you might save way more money in a year. Other similar resources include less and charge more, or do you know one that's better value?
I didn't split it into tears (book, book+code, book+code+...), because I think it works better together. I do realize I am losing some customers this way.
I started with Markdown and gitbook initially (the old version of gitbook), and then switched to Pandoc & XeLaTex engine with the mixture of Markdown and LaTex. I only did the "cat" and "ref" boxes in LaTex, everything else is Markdown.
I also use some Ruby for preprocessing (when building other formats), previews, etc. Someone submitted my post on that to HN a while ago so there is some discussion here: https://news.ycombinator.com/item?id=28594863
deployment is always the one Ive struggled with. there so much tutorial about building a webapp and almost always all of them assumes you can deploy. and I could not find dedicated resources for deployment. thank you so much for this!
I actually think there are many resources online, but nothing that takes you from the beginning to the end. So unless you know what to search for, you won't find it.
This is especially true for security. How do you know things are secure once your deployment works?
I am just starting the process of migrating away from Heroku, so this is perfect timing. As a full stack dev, I've always done the bare minimum with deployment as I never found the process particularly enjoyable. In the past, I would always just copy-paste build configurations from past projects, or some online resources, and wouldn't spend much time digging into the details or really understanding the ins and outs of the build & deploy process.
Needless to say, I'm looking forward to this book.
Looks like a great work, not much to say, was long looking for such a comprehensive book. Exactly missed a single source which lists all deployment related topics, not too shallow, not too deep. In other words, saw it like an area map of the exact scale I was looking for. Bought instantly.
Book looks like it would have been very useful when starting out! I had to glean this information by watching more experienced devs and then bumping through different tutorials, and some of it (like security) is still hard to come by.
I want to know how to push only pre-configured dependencies without Docker. So no build tools in production, just pre-built binaries. (Specifically not building gems on the production server.)
I cover what most people do which is either using build tools on a production server or building containers without them. I understand where you are coming from, but I don't talk _specifically_ about this.
Basically you need to build your .so files beforehand and then copy them over. If you use the same system as your target you can just copy gems' files around.
A good approach (which we did at Red Hat) is to repackage gems as RPMs and then install them as other system packages. But it's a lot of work. Fedora has a whole default Rails stack packaged, though.
I would not suggest this book to people who want to practice professional software deployments in 2021. This book is setting you up with a limited set of skills that are over-complicated and not best practice. For instance:
Server configuration. You should not be monkeying around with OS configs. If you do, it should only be in something like a Docker container, which is an easily tested/updated versioned immutable repeatable closed environment that runs everywhere. Monkeying with server configuration is a quick path to becoming a systems administrator, introducing unnecessary bugs, and increasing complexity. Try to avoid using software that is platform-specific (see next point).
Services with systemd. You should probably not use systemd to manage services. The primary reason is that you might not fully control the system you run services on if it's a multi-user system, and you need to have system control to modify systemd. It's also generally not portable outside of a Linux system. In the cloud you would ideally be using a deployment or orchestration system which has its own configuration format and method to run services, obsoleting systemd. The most portable service manager you could learn to use would be runit (even Busybox has an implementation of it), and after that, whatever one you choose that you can run as an unprivileged user. You can then run your preferred service manager as a systemd service, or in a container, etc.
Databases. Try not to get into monkeying around with backups and restores. Find some kind of managed provider that can do simple snapshots before deployments and easily restore them. Doing it manually is painful, and automation could be done better by a managed provider than trying to roll it yourself. However, you should be familiar with Flyway-style database deployments.
SELinux. You should not have to learn how it works to deploy. But if you do, get a dedicated book on it.
Storage concerns. Don't use networked filesystems for production. You can, in the sense that you can toast bread in the bathtub, but I wouldn't recommend it.
Backups and restores. Use versioned immutable artifacts in an artifact repository. Use a managed backup service/tool/etc for whatever doesn't work that way.
I don't see mention of caching proxies, reverse proxies, or CDNs. These can get tricky, from being careful about headers to preserving source IPs to invalidating stale caches to load balancing and resource limits.
I don't see any mention about continuous deployment, continuous integration, the 12 Factor App, or Immutable Infrastructure. All these are core components of modern deployments.
And as much as I hate it, Kubernetes is slowly of eating the entire world of modern systems, so learning how deployments work on it is essential to working in modern professional settings.
There is not one single way to do deployments, and what you suggest leads people to vendor lock-ins, rather than the ability to self-host things on their own hardware later on (or if necessary). What I teach is actually a good approach for many, if not most people.
My intention wasn't writing a book on fancy-cloudy deploys for enterprises, but teaching people more about systems they use. I deploy my side projects the way I describe in the book, and I can tell you I have a good time, because everything is straightforward and easy-to-fix.
* Ad Server configuration: I explain deployment with and without containers. People can choose the right path for them. If you would read the book, you might have realized there is not all that much system configuration after all and it's easy to keep up.
* Ad Services with systemd: Hard disagree. systemd-based distributions (Fedora, CentOS, RHEL, Ubuntu, Debian) are eating the Linux world. systemd is an init system, so even if you don't write a systemd service on your own, you should understand how they work (your databases, firewalls, system services, and even Docker would be managed as a systemd service).
* Databases: This book is not an argument for running the database yourself, but about how you can do it with just 20 lines of Bash. People should decide themselves what's best for the project at hand.
* SELinux: You should absolutely learn it as it's a security layer of your Linux systems. Most resources skip it and then people don't feel confident running with SELinux, and thus deploy less secure systems.
...
I see your whole argument looks like let's run Kubernetes. I don't think it's the right choice for indie hackers and early startups (the target audience of my book).
If you want to go the path of Kubernetes, than my book gives you a great introduction to networking and Docker which are prerequisites for understanding and working with K8s. And SSH, Puma configs, encrypted backups, and other topics are same whether you have K8s or not.
I only use Kubernetes at work, and I prefer doing things without it.
I'm not sure there is one really, because deployment varies a lot depending on your technology stack, your architecture, your deployment model, your product. You sort of learn the fundamental concepts and then pick out the pieces that fit your use case.
A book on containers would be the next thing I'd learn very thoroughly. Whether you run them in Docker on a single host, or run them in a cloud orchestration system, doesn't matter really. Just having an app in a container provides the abstractions you want to enable rapid, reliable deployment on multiple platforms. Most deployments should be dead simple: pulling and starting a new container, pointing traffic at the new container, stopping the old one. Rollback is the same in reverse order of container. There should be a billion different services to manage this for you, but you can also do it yourself on a single Linux box easily.
Then a book on database migrations, which isn't really complicated once you get the jist of it. This teaches the idea that if you're using a database, you have to think hard about how you're using it in context of your code deployments, and gives you a model for how to handle both reliably.
Next, the tools Terraform and Packer are very useful for handling the "infrastructure" side of deployment. If you manage an actual VM that runs your apps, build the image with Packer and deploy it with Terraform. It's much better to use some managed provider that just runs your containers so you don't need to deal with this. But if you do need to manage a host OS, this will make it seamless and reliable to do the inevitable maintenance in a way that you can test first, and recover easily from failure.
Ensuring your app works along the methods of the 12 Factor App (it's just a website, no book) will make sure it fits into all the tools and methods. If you just look for the deployment piece of every part of 12FA, you'll build a very robust deployment system.
Finally, learn Bash and how to set up a web server like Nginx (and how to use it as a reverse proxy) and you will have basically all the skills you need to do modern best practice deployments.
I’m a netcup.eu customer as well. Can confirm, reliable and consistent performance and the lowest prices you’re liable to find anywhere for KVM instances..
I also have BuyVM.net instances as well. They are also excellent and have been around a long time.
(It's a joke, but as a Red Hat guy I yet have to see it in real life to believe it.)
My last Windows was XP, but I actually use Azure at work right now. If you want to mostly do cloudy things (use clouds for more than simple VMs), you might want to look into certifications[0].
I chose NGINX because it's what I use and have a good performance. I am curious, why are you interested in Apache in particular? Is that what you run now?
Web Protection by
Bitdefender
Dangerous page blocked for your protection
https://deploymentfromscratch.com/
Dangerous pages attempt to install software that can harm the device, gather personal information or operate without your consent.
TAKE ME BACK TO SAFETY
I understand the risks, take me there anyway
If you know this page is not dangerous, you can add it to your Exceptions list.
Be aware that you will not be warned about any threats existing on this pag
I don't use Bitdefender. I think it has some issue with how Netlify delivers content (sesing other Netlify issue with it). Likely a false positive, though.
Cool. Hopefully I didn't come off as mocking. I should have clarified that I meant that general type of false-positive flagging problem. I favorited the post if that tells you anything lol
I posted a personal project on reddit around a year ago that got highly upvoted and someone made a similar post with a bunch of "strange" comments that must be evidence of me astroturfing. I have to admit they were strange accounts, some who haven't commented in over a year, but I wasn't using any alt accounts or anything sketchy. Sometimes people just don't comment unless it's something they really like or are knowledgeable about, or maybe something else, I am not sure and couldn't explain it when it happened to me.
I'm not a frequent contributor to HN (except when I build a product and want to show it on HN). I genuinely commented because I like the book and saw this thread on HN.
I never talked to the author, I only follow him on Twitter.
Aside: Is HN so fragile that it requires end-users to police anomalous activity? Given the age and influence of the platform I'd assume dang and co. who moderate and maintain the board are old hands at staying on top of manipulation of the platform.
Could any mods comment on this? _Should_ we be keeping an eye out and calling out odd activity? It'd be nice to avoid posts like __blockcipher__'s; while well intentioned I could see such commentary having a chilling effect on discourse.
> Please don't post insinuations about astroturfing, shilling, brigading, foreign agents and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data.
That guideline makes sense to me. I was previously unaware of it [the guideline] but the justification is sound, doubly so because it turned out the comments were genuine* :) My apologies.
* Albeit at least one user presumably found the post via Twitter from following the author which is a little bit of a grey area
I was unaware of it as well, thanks for calling it out. I don't think you were wrong to call out your suspicions, I was just unaware of what controls or processes were in place (if any) to prevent the need for users to police stuff.
I don't think it's fragile, but astroturfing is a serious problem for any popular platform. I actually appreciate the time that end-users take to check for inappropriate behaviour.
I bought the book but I haven’t managed to go through it yet. What I can tell is that some real work went into the book. I don’t intend to deploy things myself as I use Heroku and Cloud 66 but sometimes one still has to understand how things work.
I suppose if the author asked a few folks to leave positive comments on the post thats not too crazy. I'd do the same thing if I was trying to promote something. I think I'd draw the line at something more programmatic, like some gray hat creating sock puppet accounts.
> Don't solicit upvotes, comments, or submissions. Users should vote and comment when they run across something they personally find interesting—not for promotion.
I believe that means that asking people to leave positive comments on a post is something the guidelines ask you not to do.
But I would agree that, for instance, just posting on your social media "I posted this on HN, check out the comments" by itself should probably be fine, and might result in the same behavior, it's kind of a fuzzy line.
Please don't actually ask people to leave positive comments though. Or post something that you hope people read-between-the-lines the same way.
> Please don't post insinuations about astroturfing, shilling, brigading, foreign agents and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data.
They should disclose that, though. Otherwise the feedback is indistinguishable from astroturfing.
Pretty much everything about this guy rubs me the wrong way. The usual cheesy testimonials / vague promises of content which never really gets previewed, the obvious astroturfing, which he continues to respond to as if they're organic genuine comments, etc. Just leaves a really bad taste in my mouth.
I am really sorry you feel that way. It's all pure feedback from people I don't know. All organic. And I am replying, because I promised I will be around for discussion.
Testimonials, podcasts appearances, and comments here were not solicited. People just did that on their own.
Jeremy from Software Engineering Radio actually really bought the alpha version, and his invitation to the podcast was out of the blue. Jason didn't buy my book (I think) but wanted to talk about it. Juan sent me his testimonial himself. And I wasn't their friend beforehand either.
> never really gets previewed
I linked two previews, one is a full chapter. I also have like 8 readable screens of good quality on the book page.
No problem, I know where you are coming from. I regularly get spammed with "we are not PH" and "we are on HN" posts from people I don't even know, and the hard truth is that for lot of these "marketers" it actually works in the end.
On the other side, I find your comment, and all the other comments that originated from yours, very distracting to the point that I didn't care anymore about the book itself but only about writing this (annoying and distracting) comment.
Show HN has a major problem with that these days. The comments that are just like "perfect timing! I have never seen a resource for this and I'm just learning it now" are really facile, no one actually interacts with people selling you things like this, and it's contrasted starkly with the one comment giving feedback on the page which is that it has no content at all unless you buy it.
I find it very hard to believe the ratio of happy purchasers already seeing value vs. questioners about what this really is being 5:1 or more. Sad to see.
> no one actually interacts with people selling you things like this
There's a whole successful social network (Goodreads) built on people's desire to talk about books, frequently in the form of effusive praise. I think being able to trace the product to a single individual (e.g. a book's author) helps make it particularly appealing to leave that sort of feedback: we know it feels great to hear that someone values a thing you've created, and we like the idea of giving that pleasure to the creators of things we like.
I somehow doubt it's in the form of 5:1 ratio of effusive praise to questioning/criticism outside of the true top books there, and then to see this on a random ad where the OP swears he's not contacted anyone about the Show HN and yet all his "happy" "lurking" "customers" pop up with really sweet words within an hour is comical
I understand people are nice sometimes, but it's clearly not organic here.
And yet it's 100% organic here. I was few times on the HN frontpage with my blog (that links my book) so I was hoping some of my readers actually hang out here. I postponed Show HN a few months to get a few hundreds customers first. But that's it.
I had the impression Goodreads was a link-farming book/warez site. Is it something real or apparent competing-with-the-Jones', Chef de Claque toxic positivity, whether human or bot?
I and many people I’ve met irl through book clubs etc use it; I find reading my friends’ reviews interesting and I’ve gotten good recommendations through it.
If you’re just looking at the top reviews for a book it’s more questionable; they tend toward the extremes: enraptured encomiums about how beautiful and important and bold the book is, or insult-laden rants where the book is a whipping post for the reviewer to show off what a biting sense of humor they have.
Comprehensive means going from networking to configuring NGINX as a load balancer. And everything in-between.
But to provide more value I chose certain language runtimes and databases, because writing only in general is not as useful and tangible. What it means is that a chapter on application servers goes through some options you want to look for, and after that discusses configuration of Puma and Gunicorn as examples.
So if you are running Node.js, I don't have (currently) specific configuration directives listed, but you would know what to look for.
I might add more to the current list, but obviously I can never cover everything.
The book however does not go into detail on these tools (ansible, terraform), its goal is to teach the basics of deploying an app on a linux vps.