TL;DR style notes from articles I read today.
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 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, 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
Top comments (1)
This article is from 2011, and nowadays is not so hard to find Erlang engineers or learn it, because we have more resource available, like lots of different worldwide conferences around the Erlang ecosystem, and they happen all year around.
But the main reason is that since Elixir was released, and gained traction, it brought Erlang along, thus being now more exposed to wider audience.
For the ones not aware Erlang was during a lot of years considered a secret weapon in their arsenal, by a lot of companies:
So no matter if you are browsing the Internet or doing just a phone call you have pretty good chances to be using an Erlang system ;).
Nowadays you even have an Erlang Ecosystem Foundation, that aims in their own words:
So the bottom line is that now 8 years have been passed from when they migrated, therefore the reason of that team to switch from Erlang to Python may have not been an issue today.