Last month, Eldarion launched the new Scaife Viewer for the Perseus Digital Library. Yesterday, I gave an online talk on the project, as part of the SunoikisisDC series of seminars on Digital Classics.
Eldarion is helping build the next version of Perseus.
The much anticipated Django 2.0 was recently released and we are updating Pinax apps, client projects, and our own sites. This offers the perfect opportunity to share our process and some of the most common issues.
Recently I updated
eldarion-ajax to have more robust tests along with 100% test coverage. I wanted to get to this point before I venture into some potentially aggressive refactoring.
For a long time, we used TravisCI and Coveralls for executing lint checkers and tests and tracking our code coverage. These are fine tools but we’ve recently switched to CircleCI and CodeCov. This is our default setup for projects.
It can be fairly common to have situations where your users need to quickly add
items to a list, edit those items, and perhaps even sort them. Ideally,
we can keep the user focused on their data and tasks rather than how to
navigate the software facilitating the work.
Code coverage is an important aspect of good engineering practice. Without it, you are flying a bit blind writing tests.
In the previous parts we have learned how to write stories, groom and point them. Everything up until now has been done to prepare us to be able to plan a sprint.
Before you add a story to a sprint it should be pointed. Pointing a story means
assigning a number that represents complexity to it. Metrics like velocity are
driven by these points.
It is important to constantly be refining your backlog. This is accomplished through time-boxed meetings where the team performs an activity called grooming.