Last Thursday, a swarm of eager Agile enthusiasts took over Socialbakers HQ. 60 people gathered to discuss whether or not it would be possible to operate Agile, and perhaps even Scrum, without having a full-time Scrum Master / Agile Coach role embedded in the process.
In just two days, three teams planned and designed three new projects.
Thanks to Socialbakers scrum masters Adam Sobotka and Martin Jarcik, and Co-Founder/Chief Science Officer Martin Homolka, 15 of Socialbakers’ most dedicated developers traveled to our Prague HQ for a two-day (and -night) Hackathon that yielded three functional projects, with the teams declaring a winner at the end. Did team Cookies, News, or APIs take the top prize?
In the previous article we were talking about our distributed platform for inter-product communication in our company (codename Hera). To keep this platform healthy, we need to know exactly what, when and how many times are certain events happening. The evolution of each metric is also important in a longer time period as it helps us to identify that some api/worker is getting overwhelmed and we need either to scale it or try to optimize the worker. This means that precise monitoring of the overall platform as well as each of the individual workers is an important thing. Continue reading
You can find a bunch of articles written about front-end optimization, focused on 60 FPS scroll, smooth animations, and so on. This article is a little bit different though. While developing Builder 3.0 we came across an interesting obstacle and we would like to share with you how we got around it.
In Socialbakers we have many teams that do similar tasks or cooperate on similar ideas. We have a team that grabs and stores all the raw data from the social networks. There is a team that aggregates and calculates metrics on top of all those gathered data. We have product teams developing specific products: Analytics, Builder etc. We have a data mining team that does research based on those data. There are teams that develop per-customer solutions with attention to the unique needs of each customer. We have single-purpose websites that display some data in a really specific manner (Engage conference, US elections, Cheermeter for Olympic Games, etc…). And all these teams need to cooperate, exchange data, identify customers – simply said, they need to communicate.
One of the things we wanted to do for a long time is to show what our engineers have been doing, which challenges we are facing and how we solve them…
And this blog is the result.
In the first article I want to give you a sense of all the systems and technologies that power Socialbakers as well as I want to introduce our thinking, principles and our tech stack. First on a high-level, but you can look forward to more in-depth posts in the near future.
This is our core principles (ideal state) that helps us to navigate which way we want to be heading:
- Keep it simple & scalable
- Use proven & solid technologies when possible, don’t reinvent the wheel.
- We want to deliver small things fast, test it fast and get feedback as early as possible.
- Blameless culture. Fails are things to learn from. Improve our environment to prevent fails is much more important than blaming individuals.
- Processes and technologies are our servants. Not vice versa.