TL;DR style notes from articles I read today.
- Earlier and better feedback, while the code is being written, from your pair partner.
- Collective code ownership by the team and strong team style, since it is no one’s sole responsibility or brainchild.
- You can have actual continuous integration with small changes locally tested and then pushed out, without problem ignored till later.
- Fewer issues with merge conflicts since your whole team is up to date on small changes every time.
- High visibility of team members’ work so you can easily (and early) spot where a teammate needs help.
- You can preserve the whole commit history, which is an advantage for future developers working on the same codebase.
Full post here, 15 mins read
- Mixpanel had coded one of their servers using Erlang because of performance requirements.
- After 2 years, it became hard for them to debug downtime & performance issues because they didn't have any Erlang experts on their team.
- They switched to their de-facto language, Python. Having more code clarity & maintainability were the two main reasons for this move.
- For the framework and networking library to scale, Mixpanel used eventlet’s raw WSGI library (instead of Python’s asynchronous I/O) since its”green threads” resemble Erlang’s “actors”.
- For the JSON library they used simplejson coded in C, for roughly a ten times better performance.
- Using the right Python libraries avoided adding more servers horizontally.
Full post here, 5 mins read
- New & shiny can also mean immature.
- Developers must be cautious about excessive reliance on new technologies.
- Do not ask simply how to leverage Kubernetes at scale, ask how to use a single abstraction to cover Kubernetes, on-premises visualization and the entire IT landscape.
- To be cloud-native, you may need to rewrite your existing tech as containerized microservices.
- Build your version for full compatibility with other vendors instead of complete portability and abstraction across environments.
Full post here, 6 mins read