Featured in this edition of Spotlight is Daniel Rotter (a.k.a. danrot), creator of Sulu—the Symfony CMS. Sulu helps content teams deliver complex sites and great user experiences.
Daniel is a lecturer at the University of Applied Sciences, Vorarlberg. He lives in Altach, Austria. He is an active member of the local developer community, and organizes local meetups and conferences.
What seeded the idea for Sulu?
While using Symfony for our projects at work, we realized there was no CMS completely based on the Symfony framework. This complete lack of options gave us the assurance that a potential market existed.
We decided to make the new CMS easy for developers to use and provide clear documentation.
Our years of experience from developing client projects at MASSIVE ART gave us a head start. Today, we can say that Sulu is a success—proven by the many developers using Sulu worldwide.
What do you have in mind for the short-term and long-term future of Sulu?
We released Sulu 2.0 very recently. We switched our complete frontend stack of administration from jQuery, AuraJS and Backbone to a modern React application.
We put a lot of effort into this, and now we have a full-blown data management solution which isn't restricted to CMS. Backend developers can build custom entities with business logic, and can configure afterwards how the administration interface should look like on the server side.
In the short-term, we are trying to fix bugs that might have appeared in Sulu 2.0, although it already feels stable because we used it in quite a few projects internally before release. Then, we will add a few more content-related features, like allowing users to nest content blocks in forms.
Long-term, we already have a few plans on what we want to do in the 3.0 release, which will be mainly about server-side, since we've put a lot of effort in the frontend part in Sulu 2.0. We think it makes sense—for a project of our size—to concentrate on only one end for each major release.
In 3.0, we want to improve a lot of our content storage mechanisms, and try to apply more Domain Driven Design principles in the general architecture of our server-side code.
How would you describe your problem-solving process?
Usually, I try to get a good understanding of the problem and split it into smaller sub-problems.
These sub-problems are easier to fix. Once I have solved one of them, I will commit my code, so I can start with a fresh mind again. This way, I know that everything I have done so far works as intended, and I don't have to keep track of all the changes that are not committed yet.
Having a lot of uncommitted changes in git is something that clutters my mind, which might be related to me being a minimalist (which is probably why I use software like ArchLinux and Neovim).
What is the one thing new developers need to learn?
In my opinion, the most important thing is to not only know the different concepts, but to know when it's the best time to apply them.
At Sulu, we always have to distinguish between our core product and client projects with different priorities. In client projects, it is more important to meet deadline and budget criteria, while on our product it is more important to deliver quality (otherwise it will cause you headaches for years).
For our product, it is also very important to have a lot of extension points, because people want to integrate their own functionality without touching your code. This is not a real requirement in a client project, since you are in full control of your entire code anyway. You usually don't need your code to be extensible, because if needed you can just change the code itself. This will result in easier understanding of the code.
What were some obstacles you faced while coding for Sulu?
I think developing Sulu 2.0 was one of the biggest obstacles I've faced so far. The problem was that we had no choice but to replace the full frontend stack.
In a client project, I would have decided to start by using the new framework—in our case, React—in just a few places, and try to convert other parts over time. However, this does not work for an open source project. If we had released a new version of our CMS, where you would need to use two different frontend stacks to extend anything, then I'm sure this would be a very negative argument in every technical evaluation.
So, we decided to go for the full rewrite, and of course it took us longer than we anticipated. However, I am really happy with the final result, and I am glad that we chose that path.
How important is testing for your project? What tools do you use to test?
Testing has a very high priority in our project.
We use all kind of automated testing tools, like PHPUnit and Jest for all kinds of automated tests. We use static code analyzers like PHPStan and Flow to avoid errors early. We use linters like ESLint to catch a lot of errors that are easily overseen by a human in a code review.
This results in shorter review cycles, because a lot of errors, namely code smells, are already solved before a reviewer gets to look at the code. And shorter review cycles also result in a shorter time-to-market.
What do you think is the best way for developers to network? What social media networks do you frequent?
My absolute favourite way to network is through real-world events (meet-ups and conferences). It is a lot nicer to get in contact with people in person, rather than over the internet. Nevertheless, I still get my quota of technical news from the people I follow on Twitter. It feels to me like most developers are active on Twitter, but not so much on Facebook, LinkedIn, or the like.
What do you wish more people would ask you about?
That's an interesting question. I think I would love to talk to more people about our Sulu 2.0 release, because that's something I am really excited about. Otherwise, I don't care a lot about what people ask me, I am glad if I can be of any help to anybody :-)
What are your productivity hacks?
Keep it minimal! I love doing stuff on the console, including using Neovim. I feel a lot faster on the console than clicking through dialogs.
Also, splitting a problem into smaller problems is a technique I love, because it is easier to get into my desirable flow state where I am undistracted.
We ❤️ open source. Fill out this form to get free, lifelong access to BrowserStack for your project's testing needs.
(Responses are edited for clarity).