Sprint 4: End in Sight

I’m back again at the 4th sprint, which means we’re in the second half to our project’s deadline. This was a sprint in which I wasn’t able to work on for a week (as a reminder, our sprints are around two weeks long) due to circumstances, so I wasn’t able to contribute much this sprint. This week-long gap made me insecure in some ways, which I hope will be sorted out soon.

Aside from that, most of what I did during this week was finalizing one of the stories while simultaneously preparing to finalize another one. I was also messing around with Docker (again), since we can’t really say that our project deployment is complete. We haven’t prepared deployment for our front-end app, and there are still some settings missing from our current build.

I should at least mention that our project’s already shaping up quite a bit. The efforts of our team are definitely showing as the app slowly has more and more features. At this moment, I can’t say that we will definitely finish our project with complete features, but at least little things like this can help motivate the team to keep on pushing forward.

I can see it; the end.

It’s been a long journey, and I am really grateful that our team isn’t breaking. Two more sprints, 4 weeks left until the end of this project and I’m sure that our team will last til the end. But, as mentioned above, I still have a few insecurities, which popped up during my absence. I just hope I can go through the last two sprints without them bothering me.

Of course, as usual, here are stuff I learned up to the 4th sprint:

Test-Driven Development: Revisited

I wrote about TDD at the first sprint, but after 4 sprints, I’m pretty sure that I know a bit more than the me back then.

Along my side of the development, I had to face something which confused me before. The scenario goes like this:

1. Implement feature ‘A’ with TDD (Red, Green).
2. Add tests for feature ‘B’ (Red).
3. Implement feature ‘B’ (Green).
4. Break tests for feature ‘A’ (Green but not Green).

In other words, making tests fail due to change of specifications (although, in this case it was because I was trying to implement the features step by step without having foresight).

Obligatory picture of a true TDD Developer.

Anyways, from what I’ve read in this conveniently asked thread, to handle such a scenario either:

• Modify the tests, if the old tests are supposed to work but need to be adjusted to the new spec; or
• Delete the tests, if the old tests aren’t supposed to work as written previously.

An example for the former type of tests are tests that involve models with added fields; you would have to adjust the tests to include the new fields but the intention of the tests are virtually the same.

An example for the latter type of tests are tests that involve accessing data which previously was allowed, but currently not; the tests are no longer testing in accordance to our expected features, so said tests are invalid (must be deleted).

I thought it was interesting enough to share, as it is something I wouldn’t know unless faced with it.

Side-note: all modification and deletion of old tests are done during the Green commit.

Persona: Somewhat Like an Identity

I’ve only heard about personas in development from this course, but as I began to learn about it, it felt like it was an obvious thing to consider as a UI/UX designer. Well, I can’t really tell since I’ve never been a UI/UX designer, but it definitely is helpful to designing the project we have in hand.

So what is a persona? Personas are data which represent the target user for our project. These data help us figure out how to shape our project, since ultimately, our project is designed to be used by those target users. Personas are typically made from extensive user research, representing data of some majorities.

Example of a Persona.

As you can see from the example above, there are a few key aspects, namely the bio, motivations, goals, and frustrations.

• The bio is self-explanatory. It provides gender data, age data, location data, etc.
• The motivations explain the background of the persona on why he/she would want the app we’re developing.
• The goals explain what the persona expects of the app we’re developing.
• The frustrations explain what the persona would not like to see in the app we’re developing.

These aspects aren’t strictly named this way. Frustrations might be called ‘Pain Points’ in some other representation of a persona and Goals might be called ‘Needs’, but it doesn’t really matter as the aspects do not differ in terms of what it contains.

SLOVNEEK Persona; I stole this from my teammate’s blog.

The picture above is a persona for our project. From a slight glance, we can see that there are a few missing aspects, namely the goals and the motivations. Furthermore, this persona isn’t composed from user research. Instead, it was the data of an actual person who would use our project in the future. Although the person him/herself would use it, we would benefit more from data that represents the majority (there’s a chance that the above persona is an outlier).

This is probably all I can tell about personas. Again, as clarification, I have never been a UI/UX designer, so apologies if my knowledge is lacking.

Oh, and of course I didn’t forget about this cat:

Morgana from Persona 5

Refactoring, Best Practices & Design Pattern: Code Maintainability

The art of refactoring, maintaining best practices at all times and working with design patterns are all elements that contribute to better code. Although, since we’re using Django Rest Framework (DRF), there’s a big absence of logical/utility functions outside the expected functions from DRF.

Despite that, I’ve refactored a couple of minor stuff; appropriate renaming of certain test functions. I’ve also renamed a serializer to reflect on how much data it actually handles.

Speaking of serializers, they are part of what makes DRF easy to use. Although not official, the use of serializers, along with the use of viewsets for view functions are considered as DRF best practices. Our project, particularly the back-end side, relies heavily on DRF serializers and viewset, and these parts help readability and maintenance of the code.

Other than DRF best practices, since DRF/Django is based on Python, we also consider the best practices for Python, which include (but not limited to):

• Using snake_case for functions and variables
• Using CamelCase for class names
• Trailing commas in a multi-line list

And of course, there are your best practices for implementing a feature in a TDD style development. According to this article, there are 7 best practices for TDD:

1. Avoid functional complexity.
2. Focus on what you need to achieve.
3. Maintain code austerity.
4. Test repeatedly.
5. Maintain code sanctity.
6. Application knowledge.
7. Know when to use TDD.

And that’s the extent of what I did in the project in terms of refactoring, maintaining best practices and working with design patterns.

That’s all for this sprint, stay tuned for the next one~