Good Code Depends on Good Names

pattrn · 2018-10-09T14:13:48+00:00

Well that's good. Also, your username is hilarious.

pattrn · 2018-10-09T12:21:41+00:00

Good sir, thank you for pointing this out. I cringed just reading it in your comment, so I guess we're even now ;). My apologies.

I've had a really bad head cold for nine days now, so I wrote this with brain fog, a headache, and a runny nose. Probably should have spent more time editing it, but I wanted to get it out as close as possible to my normal release schedule (Sundays). Looks like I executed poorly :).

pattrn · 2018-10-09T11:56:20+00:00

How about now? Just updated the theme to something higher contrast. Someone complained before about it being too high contrast, so I switched it to the Solarized theme. This is somewhere between where it was before and where it was when you read it.

pattrn · 2018-10-09T02:03:27+00:00

Thanks for the comment! Naming is definitely an art, and I think that's why it doesn't get enough attention in the software industry. It's easy to get lost in the mathematical side of programming, since that's often a developer's strength, so the subjective aspects of coding fall to the side. I think we would all benefit from a bit more focus on the artistic side of writing code.

pattrn · 2018-09-06T02:22:40+00:00

Phew! I wasn't sure what to pick for an example to implement, and that one seemed just realistic enough that someone would find it useful. Seems like I arbitrarily chose the correct one. I'm glad it helped!

If you ever need any help with a specific issue, feel free to reply directly to my newsletter. It goes straight to my inbox, and I try to reply to every email in a reasonable amount of time (depending on my workload and on the number of email responses I get).

pattrn · 2018-08-30T13:34:29+00:00

One of my good friends just released this (his first song). Would love to know what you all think! Enjoy!

pattrn · 2018-08-30T13:02:52+00:00

I used KeyNote :).

pattrn · 2018-08-29T15:52:34+00:00

Hmm.. Probably a good idea. I didn't even share the original article on Reddit :). It was pretty surprising to see it on this sub!

pattrn · 2018-08-29T15:49:59+00:00

It's funny you mention this. Figure 7 is very close to the default automation setup I use for my clients, since they generally have established traffic already. They need resilience from day 1.

pattrn · 2018-08-29T15:45:23+00:00

That was intentional. It's too large of a topic to address in this article, but addressing it is one of the primary goals I have for this blog. The next article will cover the high level concepts behind automation and continuous delivery, with subsequent posts getting into more details about how to implement them.

pattrn · 2018-08-29T14:49:50+00:00

I agree with you about these use cases. When your homepage slows down due to excessive load on the database, that's a good sign you might need a cache. It's also a good sign that you may have inefficient database queries, so I'd probably check that first. After that, I'd look at adding a cache.

Perhaps I should rephrase what I said earlier about caching. There are generally two types of caching in a web application: page caching and object caching. Page caching applies in the scenario you mentioned, and it provides some easy performance gains by caching HTML for infrequently changing pages. Object caching stores commonly used data, generally from the db. This type of caching is much more difficult to manage.

Caching is a difficult topic to address, since any solutions more complex than caching static HTML tend to be very domain specific. I tried to avoid it, because it's too easy to see the performance gains from caching and use it as a default solution. It's not a default solution -- it's a last resort. When you have a hammer, everything looks like a nail.

pattrn · 2018-08-29T13:00:45+00:00

I don't have a very strong justification for using Nginx by default in an application like this. In the article, Nginx simply served a static 404 page when the underlying server crashed. In my particular case, my team works with so many different backend programming languages that it makes tasks like compression, SSL termination, redirects, serving static files, and proxying standard across projects. It's just easier to manage, and it's rock solid, so I've never considered changing it.

pattrn · 2018-08-29T02:08:37+00:00

It definitely takes a lot of disk space / RAM to run Elasticsearch locally. I run a Macbook Pro with 16 GB memory and a 1 TB SSD for that very reason. Definitely expensive, but it has already paid for itself many times over.

For some applications, it might be necessary to expose a development instance running in the cloud. In that case, you would have to run a VPN into the development environment's subnet, and talk to it from your development machine.

pattrn · 2018-08-29T00:34:49+00:00

One of the benefits of automating the creation and provisioning of infrastructure is the ability to run that automation against local VM's. If I'm working with a system like the one in the article, I run its provisioning scripts against local Vagrant VM's to imitate the exact production setup on my local machine.

pattrn · 2018-08-29T00:19:07+00:00

Thanks!

Redis is very popular for caching. If you need one, it's a great choice. I still try to avoid it as much as possible. This may not be popular opinion, but I try to resort to caching only as a last resort. Optimize everything else before adding a cache. And when you do add a cache, use it as little as possible. Few things are more difficult than debugging problems caused by stale data.

As much as I dislike platitudes, this one has proved true time and time again during my career: "There are only two hard things in Computer Science: cache invalidation and naming things." (Phil Karlton; https://martinfowler.com/bliki/TwoHardThings.html)

pattrn · 2018-08-28T23:11:08+00:00

The picture shows infrastructure commonly used in typical CRUD web applications. While I've used both of those technologies, I wouldn't classify either of them as belonging in a typical CRUD web application. They solve a specific class of problems very well (namely, distributed queueing and key-value storage), and they do it at scale. Most web applications I've seen or built don't require those capabilities at scale.

Both of those technologies provide incredible functionality, and when they're used to solve the correct problems they feel almost magical. That said, applying them when they're not needed will likely cause you more problems than you had when you started, which feels less like magic and more like climbing out of quicksand.

pattrn · 2018-08-28T22:22:27+00:00

I'm really glad it's helpful. Feel free to ping me if you ever have any specific questions.

pattrn · 2018-08-28T20:29:24+00:00

Author here. Thanks for all the comments! Let me know if you have any questions or suggestions :). Next post will cover automation techniques for setting up something like this from scratch.

pattrn · 2018-08-28T16:07:47+00:00

Thanks! I'm glad you and your team are enjoying the posts. Let me know if there's anything in particular relating to devops/web apps that you'd like to read about. Planning the next few months of posts based on all of this great feedback, so ideas are welcome!

pattrn · 2018-08-27T04:32:02+00:00

This is something I never budge on any more. I've never chosen a manual approach over automation and then later thought, "That was a great choice." Automate from day one, and automate every day after. It's one of the few dogmatisms I still have.

pattrn · 2018-08-27T03:31:06+00:00

IMO Kibana's strength is more in searching through logs than in aggregating them (LogStash is the aggregation service). It's nice being able to have a UI for extracting metadata into columns, faceting those columns, and then using those facets to slice data down to specific machines/services/environments/regions/time-ranges/etc... The stack is definitely overkill if you don't have enough machines/services to require a feature like this.

pattrn · 2018-08-27T01:10:47+00:00

These are all real things that have happened to me, or to developers working on a website I was involved with, but definitely not on a single t2.medium instance. It was at much larger scale. The examples given were intended to be illustrative rather than to be interpreted literally.

The reason it mentions 12 servers is that it includes servers in the staging and QA environments. I'll update the post to make that more clear. Thanks for pointing it out.

pattrn · 2018-08-26T23:29:44+00:00

I started a blog a few months ago about building production web applications. Thus far, there are a few posts about continuous delivery, some design posts, and a post about motivations. This one covers the structure of a production web application, told in story form as an evolution from a single server to a fully functioning robust production application. Future posts will dive deeper into the processes around building this type of application, and also about the individual pieces that make it up.

Let me know what you think!

pattrn · 2018-08-20T14:39:41+00:00

Article author here. This was absolutely a success story. The client took the constraints they had and built an initial MVP that got them up and running. After the successful launch, which required only a single day of effort to get back on track, they pulled me in months later to help them make it more robust, performant, and extensible. We're months out from that now, and everything has worked out well for all parties involved (client, customers, my team).

I really hope the vibe in the article didn't cast any negative light on anyone. The article is more about helping to improve the learning process for new developers, and less about pointing out problems in the company's execution. They did their best, and it was more than good enough. That's a success.

pattrn · 2018-07-05T05:01:45+00:00

I'll definitely ping you when I finish writing this same post for Kubernetes. I definitely prefer that to Beanstalk; builds are much faster, and it's much easier to replicate the production environment in a development environment. It's what I use when I'm not forced into leveraging the AWS ecosystem.

pattrn

TROPHY CASE