Extending Django Import Export: our experience developing an Open Source package

Extending Django Import Export: our experience developing an Open Source package

In many software projects, sooner or later, there arises a need to reuse code. Sometimes such code can be extracted into a standalone package that can be maintained independently and easily plugged into other applications. If the package solves a common problem and could be useful to others, it may be worth open-sourcing it. This gives other developers the opportunity to adopt and use your library.

However, preparing open-source code—setting up the repository, CI, and workflows—may often  differ from a company’s internal standards. One of our implemented open source projects was an extension for the popular Django package django-import-export. Using it as an example, we’ll walk through all the steps needed to publish your own library.

Our Recipe for Developing Good Automated Tests

Our Recipe for Developing Good Automated Tests

Testing a new version of an application prior to release is non-negotiable. With every release, there is the possibility of introducing bugs. New features must be tested, but existing functionality (regression testing) should be tested as well to be sure that issues were not introduced when new features were added. With each new release, new test cases (unit/functional) are added to your test suite. The bigger the test suite, the more time-consuming regression testing becomes. Eventually, your QA team becomes swamped with hundreds of manual tests. This delays releases and slows down product development

What does “a lot of data” in a database mean?

What does “a lot of data” in a database mean?

How much data is considered “a lot”? Is it 100,000 records, 1 million, or even 100 million? Does it depend on whether it’s a gigabyte or a hundred gigabytes? When and why does the performance of a database start to “sag”? It is simply impossible to give a clear answer to these questions.