TL;DR style notes from articles I read today. I share these every weekday in my newsletter. You can sign up here to get these straight to your inbox.
Most common mistakes I’ve seen in Go projects
- Unknown enum value. Set the unknown value of an enum to 0 to avoid errors.
- Relying too much on pointers for speed. Passing a variable by value creates a copy of the variable but passing the pointer only passes the memory address, so it should be faster. However, by default, create functions to use variables. Use pointers only to share variables.
- Misunderstanding context. Context is composable and can carry a deadline, cancelation signal or another value across API boundaries. Make use of the fact that you can compose the context to both carry a signal and other values, and that multiple goroutines can share the same context (thus you can cancel all of them at once).
- Not using the -race option. Always enable this to reduce concurrency issues when testing.
- Using a filename as input. Make use of the io.Reader and io.Writer abstractions instead.
Full post here, 11 mins read
The pipeline-driven organization - enabling true continuous delivery
- Allow people to focus on strategic decision making by removing the burden of tactical decisions.
- Ask your pipelines to make most of the tactical day-to-day decisions about code - its functionality, quality, security, compliance - as well as environments, operations, and deployment.
- Decisions pipelines make are faster and more reliable for repetitive judgments.
- People should teach the pipelines how to make decisions automatically, by building in automated steps, scripts or quality gates.
- Ensure that a judgment result from a pipeline is always a pass or a fail, never ‘inconclusive’, and it is acted upon.
- To succeed at building a truly pipeline-driven organization, where pipelines run continuously all the way up to production, we need to develop pipeline-oriented dev, ops, testing and security skills among the team.
Full post here, 11 mins read
The rise of zero-trust architecture
- Zero trust architecture works on the philosophy of “never trust and always verify”.
- It utilizes micro-segmenting and reinforces perimeter cyber-security based on the user ID, location and other data permissions.
- It uses public-domain tools to identify & verify a user, their device and confirm permissions associated with that identity.
- It gives only application-layer access to the user, rather than network-wide access, typically using a whitelist of trusted apps on the user’s device.
- It is extensible to use with various environments and other security software due to the foundation of standards-based components.
- The design of a system like this is built to prevent threats from moving laterally through a network.
Full post here, 7 mins read
Top comments (0)