Naiz
Naiz is one of the leading online platforms for newspapers & media of the Basque Country with news and general information updated all year round, 24/7.
Naiz is a massive online platform aggregating multiple publications - ranging from local magazines to National newspapers - and all of their content. It is built on a bespoke Ruby on Rails CMS called Ubiquo by a company called GNuine.
When GNuine closed down, Naiz required another development provider, and they contacted us.
Currently, we're providing full-stack development services, as well as general consulting, code audits, and training to their internal team. We are working shoulder to shoulder, after all these years.
During the first two years of the project, we were in charge of maintaining and evolving the entire platform. Such a big platform requires a high technical expertise and a long-term strategy to ensure the maintainability of the codebase while the platform keeps evolving.
The first year was spent mostly fixing bugs and developing some missing functionalities that the platform needed to keep up with the times. As the platform was - and still is - very complex, we adopted the following approach: always leave code better than when you found it. This way, whenever we touched new classes and methods, we always squeezed in some refactoring.
Throughout 2016, however, we tackled the upgrade of the platform to the newest version of Ruby (at that time). The main challenge here was to not break any existing feature while performing such important upgrades to the platform. Remember that we inherited this platform from a previous provider, and therefore we don't always have the holistic vision of all the parts of the architecture or the code and they're not there to answer any questions if we need them.
In parallel with the upgrades of Ruby and Rails, we also found time to develop new functionalities. Some of the biggest challenges include the newsletter system, or when we had to make the responsive version of the site and its circa 150 widgets.
Through the years, we've also helped Naiz with integrations with AI systems, creating their multi-language content strategy and composition of technical documentation for requesting government funds.
Project tech stack
Ruby on Rails
Ruby on Rails is a server-side web application framework written in Ruby under the MIT License.PostgreSQL
PostgreSQL is a free and open-source relational database management system emphasizing extensibility and SQL compliance.Solr
Solr is an open-source enterprise-search platform for full-text search, hit highlighting, faceted search, real-time indexing, dynamic clustering & more.Sass
Sass is the most mature, stable, and powerful professional grade CSS extension language in the world.In such a big project, communication is key. Let us explain how we coordinate with the Naiz development team every week.
First of all, the client's tech team create the cards with the tasks for the week ahead on our shared Trello board. As it is the case with most clients, we use Trello to coordinate the tasks and milestones of the project, and Basecamp to keep track of all the decisions and keep all discussions centralised on the same platform.
Once this is done, we conduct a weekly standup of 30 minutes with the client through videocall, to discuss the newly created cards and their prioritisation. We, then, move the cards to the corresponding milestones.
It is worth noting, that a lot of coordination is required when two teams are working on the same project, so we established a set of rules to separate concerns and responsibilities:
The client's team is responsible for defining new features and creating cards in the Inbox list.
We develop only in the development stage, and when we're done, we merge them to the develop branch.
We are responsible for dragging the cards between milestones, or to the Done list when we've finished.
The client's team controls every pull request to the master branch.
The client's team is responsible for taking the cards on the Done list to the different stages (staging, production, etc.)
The client's team is responsible for all the deploys and creates a PR for each one of them.
This distribution of the responsibilities helped to avoid blocking tasks and ensures that everyone has a clear understanding of the scope of his task and responsibilities.
Also, we defined these workflows as per the client's request: they wanted us to develop for them, but they would retain the ownership of the platform. Therefore, we set up Capistrano such that they could be the only ones deploying to their own servers.