#Issue38
3 posts

Why I love trunk-based development (or pushing straight to master)

Earlier & better feedback, collective code ownership, fewer issues with merge conflicts, preservation of whole commit history,
Read more

Why I love trunk-based development (or pushing straight to master)

  • 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

How and why we switched from Erlang to Python

Mixpanel had coded one of their servers using Erlang. After 2 years, it became hard for them to debug downtime & performance issues. They switched to their de-facto language, Python. Having more code clarity & maintainability were the two main reasons for this move.
Read more

How and why we switched from Erlang to Python

  • 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

Will Kubernetes fall into the “shiny things” trap?

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.
Read more

Will Kubernetes fall into the “shiny things” trap?

  • 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