This is a "living" general document of noteworthy resources and information that I've found to be personally helpful.
Table of Contents generated with DocToc
- Architecture and Design
- Specifications
- Programming Languages
- Development Environments and Development Tools
- Web Development
- Cheat Sheets
- Books
- Cloud Architecture
This is a short request for comments (RFC) that I really like because it can be used to establish standards for keywords.
When designing and collaborating it's important to align on definitions so that everyone is working from the same mental model.
For example: Say you're desiging a rest api and saying it should perform specific functionality. How do you know that people reading understand the nuance of the specifications you're giving? This allows you the ability to point to an atomic description so you don't have to repeatedly explain.
I wouldn't give this too much thought, but it's very helpful to point to when you need to align on something during design.
This is a document that provides some design standards on how a code base and product should be developed for software-as-a-service-apps.
It is a very powerful tool to help guide how to think about design, and arguably, if followed will help foster a product that is incredibly flexible in development, deployment, and scalability.
I'm a very, very, big proponent of this way of thinking, as are many other engineers. However, I'll be the first to admit that I've come up short trying to adhere to it. It's very important when developing to take a step back and ask yourself how close you're getting to these principles.
If you're straying from them, it's important to reflect on the reasons for that and if it is a legitimate set of reasons.
This is an article from Martin Fowler on Blue Green deployment. I really enjoy it because it’s a brief high-level discussion about a specific deployment strategy.
This was written in 2010, so there’s actually a lot of technology now that supports this kind of deployment very easily. In particular, there is now a concept of architecture and resources being treated as cattle vs pets that makes this a really good idea to shoot for when configuring deployment.
I absolutely love this article. It takes a very enjoyable approach to engaging readers who want to participate in type system discussions and helps clear up aspects that they may not be familiar with.
Personally, I never had a chance in my undergraduate to build a compiler. I've tried multiple times since to get started on it, but time constraints, a lack of mentorship, and a lack of drive for a pet project left me with pieces project that never really came together.
I think regardless of who you are, if you're programming it's a fantastic article to read so you have at least a starting point to engage the discussion.
- Open API
- Open API Specification
TODO
This is a historical and enjoyable piece to help simplify the explanation about character encoding in modern systems.
This was written by Joel Spolsky who you might know as the co-founder and CEO of that small site Stack Overflow. He is pretty popular in the software industry. So enjoy it, but understand it's just a high-level discussion.
What Every Programmer Absolutely, Positively Needs to Know About Encodings and Character Sets to Work With Text
A VERY thorough and incredibly wonderful explanation about character encoding.
This is the main site for Python.
This is the Python style guideline created by the "benevolent-dictator" Guido van Rossum. I really like this because while it may not be the best to follow this word for word, there is a lot of value to be gained from it when trying to direct a team.
This is a popular, small zen write-up, that is well known for helping provide a nice way to approach Python development. It's pretty important on account that is succinct in describing how to treat the language without providing strict rigidity in its usage.
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
- https://www.typescriptlang.org/docs/home.html
- https://www.typescriptlang.org/docs/handbook/compiler-options.html
This is the main site for the, Microsoft developed, TypeScript.
This is a popular linter for TypeScript. In my experience it's very helpful for development.
This is a document that explains how to write git messages, and tends to be my initial kick off point for requesting how a team writes commit messages.
Most organizations and developers now use Git as the tool of choice for version control. Because of that there are now development considerations needed to be accounted for. For example: how to perform commit messages to align with organization standards.
Because Git commit history is essentially a graph of product evolutions notated with commit messages at each node, it's important to make sure that each commit provides incredibly clear insight to the changes that occurred. It's a "history book" detailing your product.
It's a lot like life. If you're messy about archiving photos, successes, and benchmarks it becomes incredibly difficult to gauge how you arrived at your specific location. If your git history is messy, you're not going to understand how your system grew either.
That's why I like to use this as a starting point for that discussion.
This is a site that lets you check browser support for CSS features you're trying to use. It's fantastic if you're trying to determine support and don't want to try hard in confirming anything.
These are cheat sheets to demonstrate how to use syntax and features of programming languages, without bogging you down in a lot of reading. They should be considered as a reference point to help your comprehension.
A quick disclosure.
There are a lot of things that are suggested in the software industry, that in my opinon I feel are a bit overstated. While I am recommending these books, I've found in my experience that their topics can be easily summarized and the contents of the book are just simple stories, experience, or data to re-iterate the points being discussed.
So, while I am suggesting these books, I don't feel like these are gospel. I do think they provide interesting discussion pieces that can be helpful in being more reflective about what it means to deliver software.
It's famous for coining the phrase mythincal man-month in order to describe tasks that are unpartitionable in order to articulate development bottlenecks. It has been also described using child birth as an example stating:
“The bearing of a child takes nine months, no matter how many women are assigned.”
There's a lot in here that is oriented towards management and soft skills. It uses a lot of stories from "back in the day". But, surprisingly it hold true regardless of the time period.
- See [the wikipedia article] for a summary.
This is honestly just an ok book for me. But, I think it's one of the few books that really gets at the idea of respecting software development as a craft. I agree with it by an large, but I think my biggest disagreements with it are its choice of analogies.
It does a great job articulating areas to emphasize as a software engineer, and it's always helpful to have something like this around to reflect against. It is my understanding there is a 2019 re-release/update on the way on the way.
This is a great book for organizations trying to get a better mindset for optimizing their software engineering efforts.
I really like this book when it's paired with Pragmatic Programmer. The reason for this is because Effective Engineer is focused a bit more on the process and less on the software engineer. However they overlap quite a bit.
This is a great book for organizations trying to get a better mindset for optimizing their software engineering efforts.
The Raft consensus algorithm is used for many solution. My experience with it has been using Docker Swarm and seeing how it builds general consensus across manager nodes in a Docker Swarm.
Being able to visually understand this algorithm is super helpful for engaging with it.
- https://docs.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven
- https://docs.microsoft.com/en-us/azure/architecture/patterns/category/messaging
- https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/multi-container-microservice-net-applications/integration-event-based-microservice-communications
- https://docs.microsoft.com/en-us/azure/architecture/patterns/
- https://docs.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker
- https://martinfowler.com/bliki/CircuitBreaker.html